diff --git a/docs/mantis/CR0000.md b/docs/mantis/CR0000.md new file mode 100644 index 0000000000000000000000000000000000000000..5dba7b2e672dae19213078c5661838f3daa1fa71 --- /dev/null +++ b/docs/mantis/CR0000.md @@ -0,0 +1,331 @@ + + + + + + + + + + + + + ETSI's Bug Tracker + + + + + + +Logo etsi + + + + + + +

ETSI's Bug Tracker

 +
+ + +
Main | My View | View Issues | Change Log | Roadmap
  

APPLICATION ERROR #1100

Issue 0 not found.

Please use the "Back" button in your web browser to return to the previous page. There you can correct whatever problems were identified in this error or select another action. You can also click an option from the menu bar to go directly to a new section.


+
+
MantisBT 1.2.14 [^] +
Copyright © 2000 - 2024 MantisBT Team
+		 +
Powered by Mantis Bugtracker
+
+ + diff --git a/docs/mantis/CR0354.md b/docs/mantis/CR0354.md new file mode 100644 index 0000000000000000000000000000000000000000..5678fae8aa60ba56b98fc582ba14df53c86a516d --- /dev/null +++ b/docs/mantis/CR0354.md @@ -0,0 +1,429 @@ + + + + + + + + + + + + + 0000354: TimedTTCN-3 - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0000354Part 01: TTCN-3 Core LanguageNew Featurepublic22-11-2006 13:5512-12-2008 11:57
ReporterStephan Schulz 
Assigned To 
PrioritylowSeverityfeatureReproducibilityalways
StatusclosedResolutionsuspended 
PlatformOSOS Version
Product Versionv2.2.1 (published 2003-02) 
Target Versionv3.1.1 (published 2005-06)Fixed in Version 
Clause Reference(s)6, 6.3.4, 14.2.2, 18, 19.3, 22.1, 22.4, 24, 25.1, 25.2, 27.1, A.1.5, A.1.6
Source (company - Author) Helmut Neukirchen, Institute for Telematics, University of Luebeck
Summary0000354: TimedTTCN-3
DescriptionThis CR is intended to make TTCN-3 applicable to the (hard) real-time domain.
+Since the snapshot semantics was not designed for real-time testing and even timers cannot be used for real-time requirements which are distributed between several test components, current TTCN-3 cannot be applied for specifying real-time test cases.
+A TTCN-3 real-time extension has been developed in the context of the European research project INTERVAL. This change request reflects these extension which solve the described problems of using TTCN-3 for real-time.
+The proposed extension is based on the introduction of clocks which are local to test components, on a formalised logfile handling and on the notion of a testrun.
+
Steps To Reproduce
Additional InformationThis document describes the changes which are needed in order to extend the TTCN-3 Core Language by the concepts needed for specifing real-time tests. The changes have to be applied to the ETSI Standard ES 201 873 1 V2.2.0 (2002-03).
+
+1. Clause 6 (�Types and Values�): Add to Table 3 two rows on �Special testrun types�:
+with entries �testrun� and �logfile�.
+Furthermore, add:
+�The special testrun types testrun and logfile can be used to refer to the outcome of a test execution (see clause reference to clause on logfile operations and reference to clause on module control part).�
+2. Clause 6.3.4 (�Enumerated type and values�): Add:
+�The identifier timezones is a reserved identifier for defining an enumeration type which can be used to assign symbolic names to different clock synchronisation timezones. The values of the enumeration type timezones can be passed as parameter to the execute and create statement. The self.timezone statement returns a value of type timezones. A value of name none, which represents no clock synchronisation, is implicitly member of the enumeration type timezones.�
+3. Between Clause 14.2.2 (�Templates for acceptiong procedure invokations�) and Clause 14.3 (�Template matching mechanisms�): Add a new clause �Templates for sorting logfile entries�:
+�A template used in a .first logfile operation defines a sorting key. The symbol ? defines the field element which is used as sorting key, all other template fields have to set to -. A sorting key shall be of a type which allows relational operators to be applied to.
+EXAMPLE:
+// timestamp type definition
+type record MyTimestampType
+{
+  float field1,
+  timezones field2,
+  integer field3
+}
+
+// a sorting key template might be
+template MyTimestampType MyTemplate:=
+{
+  field1 := ?,
+  field2 := -,
+  field3 := -
+}
+�
+4. Clause 18 (�Overview of program statements and operations�): Add to table 11 several rows:
+Add section �Statements for real-time handling�: �Wait ; resume ; ; Yes�, �Read local clock ; self.now ; ; Yes�, �Get timezone of test component ; self.timezone ; ; Yes�.
+In section �Verdict Operations�: �Set testrun verdict ; setverdict ; Yes ; Yes (see note 2)�, �Get testrun verdict ; getverdict ; Yes ; Yes (see note 2)�
+Add section �Logfile operations�: �Get logfile of testrun ; getlog ; Yes ; Yes (see note 2)�, �Sort logfile and move to first entry ; first ; Yes ; Yes (see note 2)�, �Move to next entry ; next ; Yes ; Yes (see note 2)�, �Move to previous entry ; previous ; Yes ; Yes (see note 2)�, �Retrieve entry at current position; first ; retrieve ; Yes (see note 2)�
+5. Clause 19.3 (�The Log statement�): Replace clause by:
+�The log statement provides means to write values of arbitrary data types to some local logging device associated with test control or the test component in which the statement is used. For example:
+log(�Line 248 in PTC_A�);
+// The string �Line 248 in PTC_A� is written to some log device of the test system
+log(MyTimestampType:{self.now, self.timezone,1});
+// A structured value which contains local time, local time zone and the integer 1 is written to some log device of the test system
+The logfiles may be subject of further processing (see clause reference to clause on logfile operations).
+NOTE: The mechanisms for storing and maintaining logfiles are considered to be implementation specific and are outside the scope of the present document.�
+6. Clause 22.1 (�The Create operation�): Add:
+�The create operation may be called with an optional parameter of enumerated type timezones. In this case the test implementation has to take care that all test components which are created with the same timezones value (the timezones value of the MTC may be specified as an optional parameter of the execute operation) have synchronised clocks.
+NOTE 1: The concrete mechanism for clock synchronisation of test components is tool specific and therefore outside the scope of the present document.
+NOTE 2: If clock synchronisation cannot be established, the error verdict will be set.
+EXAMPLE:
+
+    :
+type enumerate timezones {
+  zone1, zone2, zone3
+}
+  :
+var MyComponentType MyNewComponent;
+  :
+MyNewComponent := MyComponentType.create(zone1); // create component in timezone zone1
+  :
+�
+7. After Clause 22.4 (�The MTC, System and Self operations�): Add a new clause �The self.timezone operation�:
+�The timezone of a test component may be retrieved using the self.timezone operation which returns a value of enumerated type timezones. If the self.timezone operation is called within a test component which has no clock synchronisation, the value none is returned.
+ EXAMPLE:
+
+    :
+var timezones MyTimezone;
+  :
+MyTimezone := self.timezone; // Retrieve timezone of component
+  :
+    ï¿½
+8. After Clause 24: Add a new clause �Real-time operations�:
+�TTCN-3 supports two operations which operate on the absolute value of a test components local clock.
+
+Subclause The self.now operation
+The self.now operation is used to read the absolute value of a test components clock. It is assumed that each test component has its own local clock. Further synchronisation of different test components may be specified by a timezone parameter passed to the execute and create statement (see clause reference to clause on Enumerated type and values, The Create operation and Execution of test cases). The return type of the self.now operation is of type float and represents local time by seconds elapsed since a fixed point in time.
+NOTE: The present document does not define a fixed starting point for time measurement, but requires a starting point which is at least older than the point in time when a testrun has been started.
+
+Subclause The resume operation
+The resume operation allows a test component to suspend execution and resume at a certain absolute point in time with respect to the test components local clock. This absolute value is passed as a parameter of type float and represents local time as returned by the self.now operation.
+
+EXAMPLE:
+
+  :
+var float myTime;
+  :
+myTime:=self.now; // Read local clock
+resume(myTime+5.0); // Wait for five seconds
+  :
+�
+9. Clause 25.1 (�Test case verdict�): Replace �This verdict is not accessible to the getverdict and setverdict operations� by �This verdict is not accessible to the getverdict and setverdict operations within a test component, but by the setverdict and getverdict operations which can be applied in the module control part to a testrun handle for further processing of a global verdict (see clause reference to new clause on testrun handles). �
+Remove sentence �If the returned verdict is not explicitly saved in the control part (e.g. assigned to a variable) then it is lost.�
+10. Clause 25.2 (�Verdict values and overwriting rules�): Replace �The verdict can have five different values: pass, fail, inconc, none and error� by �The verdict can have six different values: pass, fail, inconc, conf, none and error�.
+Add �NOTE 2: conf means a verdict which indicates conformance with respect to pure functional behaviour, but a failure with respect to non-functional behaviour.�
+ Replace Table 21 (�Overwriting rules for the verdict�) by:
+Current value of verdict New verdict assignment value
+    pass conf inconc fail none
+Pass pass conf inconc fail pass
+Conf conf conf inconc fail conf
+Inconc inconc inconc inconc fail inconc
+Fail fail fail fail fail fail
+None pass conf inconc fail none
+
+11. Clause 27.1 (�Execution of test cases�): Replace �As the result of the execution of a test case a test verdict of either none, pass, inconclusive, fail or error shall be returned and may be assigned to a variable for further processing.� by �As the result of the execution of a test case, a testrun handle shall be returned and may be used for further evaluation of a testrun (see clause reference to clause on testrun handles).�
+Add:
+�A further, optional parameter of enumerated type timezones allows to specify a synchronisation timezone for the local clock of the main test component.
+If a timezone parameter is passed to the execute statement, the test implementation has to take care that all parallel test components which are created with the same timezone value as the main test component have synchronised clocks.
+NOTE: The concrete mechanism for clock synchronisation of test components is tool specific and therefore outside the scope of the present document.�
+Replace example by:
+�execute(MyTestcase1()); // executes MyTestCase1, without storing the returned testrun handle and without time supervision nor clock synchronisation timezone
+
+MyTestrunHandle := execute(MyTestCase2()); // executes MyTestCase2 and stores the returned testrun handle in variable MyTestrunHandle.
+
+MyTestrunHandle := execute(MyTestCase3(),5E-3); // executes MyTestCase3 and stores the returned testrun handle in variable MyTestrunHandle. If the test case does not terminate within 5ms, MyVerdict will get the value �error�.
+
+MyTestrunHandle := execute(MyTestCase4(),zone1); // executes MyTestCase3 and stores the returned testrun handle in variable MyTestrunHandle. The clock synchronisation timezone of the MTC is set to value �zone1�.
+
+MyTestrunHandle := execute(MyTestCase5(),5E-3,zone1); // executes MyTestCase3 and stores the returned testrun handle in variable MyTestrunHandle. The clock synchronisation timezone of the MTC is set to value �zon1�. If the test case does not terminate within 5ms, MyVerdict will get the value �error�.
+�
+12. After Clause 27.1: Add clause �Testrun handle�:
+�The value which shall be returned by the execute statement shall be of type testrun. Values of this type may be used to handle the outcome of a testrun, e.g. pass it to a function for further evaluation of a testrun. Three operations which may be applied to a testrun handle are defined:
+
+Testrun operation
+Statement Associated keyword
+Get logfile getlog
+Get global verdict getverdict
+Set global verdict setverdict
+
+The getlog operations retrieves the global logfile of type logfile which is build when test execution finishes, i.e. the main test component terminates. The global logfile is merged from the local logfiles which are associated to test control or the test (see clause reference to clause on logfile operations).
+
+NOTE: The order in which entries of the local logfiles are initially merged is tool specific and therefore outside the scope of the present document. An ordering of entries of a particular type may be explicitly requested by applying the first operation to a logfile variable.�
+
+The global verdict which is calculated when each test component finishes execution may be accessed by the getverdict and setverdict operations which may be applied to a variable of type testrun.
+
+EXAMPLE:
+control {
+  var testrun myTestrun; // Variable for testrun handling
+  var logfile myLog; // Variable for testlog handling
+  var verdicttype myVerdict // Variable for verdict handling
+  myTestrun := execute(MyTestCase()); // Execute testcase
+  myVerdict := myTestrun.getverdict; // Retrieval of testrun verdict
+  myLog := myTestrun.getlog; // Retrieval of testrun log
+    :
+  myTestrun.setverdict(fail); // Change of testrun verdict
+}
+�
+13. After Clause 27: Add new clause �Logfile operations�:
+�Five operations are defined for processing the logfiles which are created by test control and test components.
+
+Logfile operation
+Statement Associated keyword
+Get logfile of a testrun testrunhandle.getlog
+Get logfile of test control or test component self.getlog
+Select entries from logfile, sort them and move cursor to first matching entry first
+Move cursor to the next matching entry next
+Move cursor to the previous matching entry previous
+Retrieve entry from the current logfile cursor position retrieve
+
+
+A test component or test control may call self.getlog operation to get its own logfile which is of type logfile.
+When test execution finishes, i.e. the main test component terminates, the local logfiles are merged into a global logfile of type logfile, which may be retrieved from within test control by applying the getlog operation to a testrun handle (see clause reference to clause Testrun handle).
+
+Further postprocessing of logfiles has to be initiated by applying the first operation on variables of type logfile. A search template shall be used as the first parameter of operation first to select entries from the logfiles by their type and to sort them. The type of the search template is used to select entries which are regarded by further next, previous and retrieve operations. The second parameter is used to move an internal cursor in the logfile to the first entry that matches this parameter. Templates may be used to avoid to restrictive search patterns. If no matching entry is found, the cursor position is undefined and operation first returns value false, otherwise value true.
+The operations next and previous may be applied to a logfile in order to move the logfiles cursor to the next or previous respectively entry which matches the search pattern which is given as parameter. If no matching entry is found, the cursor position remains unchanged and operation first returns value false, otherwise value true.
+If the logfiles cursor is at a defined position, the retrieve operation may be applied to a logfile in order to retrieve the logfile entry at the current cursor position. Otherwise, an undefined value will be returned. The type of the returned value is determined by the type of the search template specified as first parameter of operation first.
+
+NOTE: The mechanisms for storing, maintaining and processing logfiles are considered to be implementation specific and are outside the scope of the present document.
+
+EXAMPLE:
+control {
+  var testrun myTestrun; // Variable for testrun handling
+  var logfile myLog; // Variable for testlog handling
+  var MyTimestampType MyTimestamp;
+  myTestrun := execute(MyTestCase(),Berlin); // Execute testcase
+  
+  myLog := myTestrun.getlog; // Retrieval of testrun log
+  if (myLog.first(MyTimestampType:{?,-,-},MyTimestampType{?,Berlin,?})) {
+                                      // Select logfile entries of type
+                                      // MyTimestampType and sort them
+                                      // ascending with respect to the
+                                      // first field element. Set cursor to
+                                      // the first entry with second field
+                                      // element of value Berlin.
+    if (myLog.next(MyTimestampType:{?,Berlin,?})) {
+                                      // Advance cursor to next matching
+                                      // entry with second field element of
+                                      // value Berlin.
+
+      MyTimestamp := myLog.retrieve; // If first and next operation were
+                                      // successful, retrieve value at
+                                      // cursor position.
+        :
+    }
+  }
+}
+�
+14. Annex A.1.5 (�TTCN-3 terminals�): Add to Table A.3:
+�conf, first, getlog, logfile, next, now, previous, resume, retrieve, testrun, timezone, timezones
+�
+15. Annex A.1.6 (�TTCN-3 syntax BNF productions�): Change according to the following diffs:
+
+Old 187. TestcaseInstance ::= ExecuteKeyword "(" TestcaseRef "(" [TestcaseActualParList] ")" ["," TimerValue] ")"
+New 187. TestcaseInstance ::= ExecuteKeyword "(" TestcaseRef "(" [TestcaseActualParList] ")" ["," TimerValue] ["," Expression] ")" /* STATIC SEMANTICS � Expression must evaluate to timezones enumeration type */
+
+Old 272. ControlStatement ::= TimerStatements |
+               BasicStatements |
+               BehaviourStatements |
+               SUTStatements
+New 272. ControlStatement ::= TimerStatements |
+               BasicStatements |
+               BehaviourStatements |
+               SUTStatements |
+               SetGlobalVerdict
+
+Old 288. ConfigurationOps ::= CreateOp | SelfOp | SystemOp | MTCOp | RunningOp
+New 288. ConfigurationOps ::= CreateOp | SelfOp | SelfTimezoneOp | SelfNowOp | SelfGetLogOp| SystemOp | MTCOp | RunningOp
+
+Old 289. CreateOp ::= ComponentType Dot CreateKeyword
+New 289. CreateOp ::= ComponentType Dot CreateKeyword ["(" Expression] ")" /* STATIC SEMANTICS � Expression must evaluate to timezones enumeration type */
+
+New 291b. SelfTimezoneOp ::= "self" Dot "timezone"
+
+New 291c. SelfNowOp ::= "self" Dot "now"
+
+New 291d. SelfGetLogOp ::= "self" Dot "getlog"
+
+Old 408. PredefinedType ::= BitStringKeyword |
+               BooleanKeyword |
+               CharStringKeyword |
+               UniversalCharString |
+               CharKeyword |
+               UniversalChar |
+               IntegerKeyword |
+               OctetStringKeyword |
+               ObjectIdentifierKeyword |
+               HexStringKeyword |
+               VerdictTypeKeyword |
+               FloatKeyword |
+               AddressKeyword |
+               DefaultKeyword |
+               AnyTypeKeyword
+New 408. PredefinedType ::= BitStringKeyword |
+               BooleanKeyword |
+               CharStringKeyword |
+               UniversalCharString |
+               CharKeyword |
+               UniversalChar |
+               IntegerKeyword |
+               OctetStringKeyword |
+               ObjectIdentifierKeyword |
+               HexStringKeyword |
+               VerdictTypeKeyword |
+               FloatKeyword |
+               AddressKeyword |
+               DefaultKeyword |
+               AnyTypeKeyword |
+               TestrunKeyword |
+               LogfileKeyword
+
+New 423b. TestrunKeyword ::= "testrun"
+
+New 423c. LogfileKeyword ::= "logfile"
+
+Old 444. VerdictTypeValue ::= "pass" | "fail" | "inconc" | "none" | "error"
+New 444. VerdictTypeValue ::= "pass" | "conf" | "fail" | "inconc" | "none" | "error"
+
+Old 445. EnumeratedValue ::= EnumerationIdentifier
+New 445. EnumeratedValue ::= EnumerationIdentifier | "none" /* STATIC SEMANTICS � implicit value "none" only for enumeration types of name "timezones" */
+
+Old 509. VerdictStatements ::= SetLocalVerdict
+Old 509. VerdictStatements ::= SetLocalVerdict | SetGlobalVerdict
+
+New 511b. SetGlobalVerdict ::= TestrunIdentifier Dot SetVerdictKeyword "(" SingleExpression ")"
+
+Old 540. BasicStatements ::= Assignment | LogStatement | LoopConstruct | ConditionalConstruct
+New 540. BasicStatements ::= Assignment | LogStatement | LoopConstruct | ConditionalConstruct | ResumeStatement
+
+Old 568. OpCall ::= ConfigurationOps |
+               VerdictOps |
+               TimerOps |
+               TestcaseInstance |
+               FunctionInstance |
+               TemplateOps |
+               ActivateOp
+New 568. OpCall ::= ConfigurationOps |
+               VerdictOps |
+               TimerOps |
+               TestcaseInstance |
+               FunctionInstance |
+               TemplateOps |
+               ActivateOp |
+               TestlogOp |
+               TestrunOp
+
+Old 577. LogStatement ::= LogKeyword "(" [FreeText] ")"
+New 577. LogStatement ::= LogKeyword "(" [TemplateInstance] ")"
+
+New 578b. ResumeStatement ::= ResumeKeyword "(" Expression ")" /* STATIC SEMANTICS: expression must resolve to value of type float */
+
+New 578b. ResumeKeyword ::= "resume"
+
+New heading: A.1.5.2.6 Testrun and Testlog Operations
+
+New 406b. TestlogOps ::= FirstOp | NextOp | PreviousOp | RetrieveOp
+
+New 406c. FirstOp ::= TestlogIdentifier Dot FirstKeyword "(" TemplateInstance "," TemplateInstance ")"
+
+New 406d. FirstKeyword ::= "first"
+
+New 406e. NextOp ::= TestlogIdentifier Dot NextKeyword "(" TemplateInstance ")"
+
+New 406f. NextKeyword ::= "next"
+
+New 406g. PreviousOp ::= TestlogIdentifier Dot PreviousKeyword "(" TemplateInstance ")"
+
+New 406h. PreviousKeyword ::= "previous"
+
+New 406i. RetrieveOp ::= TestlogIdentifier Dot RetrieveKeyword
+
+New 406j. RetrieveKeyword ::= "retrieve"
+
+New 406k. TestlogIdentifier ::= FunctionInstance | VariableRef
+
+New 406l. TestrunOps ::= GetlogOp | GetGlobalVerdictOp
+
+New 406m. GetlogOp ::= TestrunIdentifier Dot GetlogKeyword /* STATIC SEMANTICS: may only be applied in module control part */
+
+New 406n. GetlogKeyword ::= "getlog"
+
+New 406o. GetGlobalVerdictOp ::= TestrunIdentifier Dot GetverdictKeyword /* STATIC SEMANTICS: may only be applied in module control part */
+
+New 406p. TestrunIdentifier ::= FunctionInstance | VariableRef
+
+
TagsNo tags attached.
Relationships
related to 0000355closed  TimedGFT 
related to 0004483closed Jens Grabowski New Concepts to Test Real Time Properties 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
22-11-2006 13:55Stephan SchulzNew Issue
22-11-2006 13:55Stephan SchulzClause Reference(s) => 6, 6.3.4, 14.2.2, 18, 19.3, 22.1, 22.4, 24, 25.1, 25.2, 27.1, A.1.5, A.1.6
22-11-2006 13:55Stephan SchulzSource (company - Author) => Helmut Neukirchen, Institute for Telematics, University of Luebeck
22-11-2006 13:55Stephan SchulzNote Added: 0000283
22-11-2006 13:58Stephan SchulzStatusnew => closed
22-11-2006 13:58Stephan SchulzNote Added: 0000284
22-11-2006 13:58Stephan SchulzResolutionopen => suspended
22-11-2006 13:58Stephan SchulzFixed in Version => Edition 3.1.1
24-11-2006 13:38Stephan SchulzRelationship addedrelated to 0000355
12-12-2008 11:57Ina SchieferdeckerProduct Version => Edition 2.2.1
12-12-2008 11:57Ina SchieferdeckerFixed in VersionEdition 3.1.1 =>
12-12-2008 11:57Ina SchieferdeckerTarget Version => Edition 3.1.1
12-12-2008 11:57Ina SchieferdeckerAdditional Information Updated
12-12-2008 12:06Ina SchieferdeckerRelationship addedrelated to 0004483
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0000283) +
+ Stephan Schulz    +
+ 22-11-2006 13:55    +
+ 		+ + + + +
+ The usage of this extension was presented as a paper at Testcom 2002. This paper contains a complete example and shows the interworking of the individual extensions provided in this change request. Thus it is recommonded to read this paper. It can be downloaded via:
+http://www.itm.mu-luebeck.de/pubs/single_pub/index.php?lang=en&pub_nr=183 [^]
+
+
+
+ + + + + + + + + + +
+ (0000284) +
+ Stephan Schulz    +
+ 22-11-2006 13:58    +
+ 		+ + + + +
+ Will be addressed in the continuation project for STF213
+
+ + diff --git a/docs/mantis/CR0355.md b/docs/mantis/CR0355.md new file mode 100644 index 0000000000000000000000000000000000000000..49f215fa41747ec54555669e07445bf3b8c48800 --- /dev/null +++ b/docs/mantis/CR0355.md @@ -0,0 +1,102 @@ + + + + + + + + + + + + + 0000355: TimedGFT - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0000355Part 01: TTCN-3 Core LanguageNew Featurepublic22-11-2006 14:0312-12-2008 11:52
ReporterStephan Schulz 
Assigned To 
PrioritylowSeverityfeatureReproducibilityalways
StatusclosedResolutionwon't fix 
PlatformOSOS Version
Product Versionv2.2.1 (published 2003-02) 
Target Versionv3.1.1 (published 2005-06)Fixed in Version 
Clause Reference(s) 6, 6.3.4, 14.2.2, 18, 19.3, 22.1, 22.4, 24, 25.1, 25.2, 27.1, A.1.5, A.1.6
Source (company - Author)Zhen Ru Dai, Institute for Telematics, University of Luebeck
Summary0000355: TimedGFT
DescriptionThis CR is intended to make the graphical presentation of TTCN-3, GFT, applicable to the real-time domain.
+Since the snapshot semantics was not designed for real-time testing and even timers cannot be used for real-time requirements which are distributed between several test components, current TTCN-3 cannot be applied for specifying real-time test cases.
+A TTCN-3 real-time extension has been developed in the context of the European research project INTERVAL. This change request reflects these extension which solve the described problems of using TTCN-3 for real-time.
+Note, that the listed changes are based on the assumption that the necessary extensions are directly integrated into the core language. Another, less intrusive solution might be possible for most of the proposed extensions by using corresponding external function which should be standardised in some annex.
+The changes are based on the Change Request Form for TimedTTCN-3 (Issue 0000354)
+
Steps To Reproduce
Additional InformationSee attachment, since the solution is lengthy.
TagsNo tags attached.
Relationships
related to 0000354closed  TimedTTCN-3 
related to 0004483closed Jens Grabowski New Concepts to Test Real Time Properties 
Attached Filesdoc TimedGFTSolutionProposal.doc (137,216) 22-11-2006 14:03
http://oldforge.etsi.org/mantis/file_download.php?file_id=29&type=bug
Issue History
Date ModifiedUsernameFieldChange
22-11-2006 14:03Stephan SchulzNew Issue
22-11-2006 14:03Stephan SchulzFile Added: TimedGFTSolutionProposal.doc
22-11-2006 14:03Stephan SchulzClause Reference(s) => 6, 6.3.4, 14.2.2, 18, 19.3, 22.1, 22.4, 24, 25.1, 25.2, 27.1, A.1.5, A.1.6
22-11-2006 14:03Stephan SchulzSource (company - Author) => Zhen Ru Dai, Institute for Telematics, University of Luebeck
22-11-2006 14:04Stephan SchulzStatusnew => closed
22-11-2006 14:04Stephan SchulzNote Added: 0000285
22-11-2006 14:04Stephan SchulzResolutionopen => suspended
22-11-2006 14:04Stephan SchulzFixed in Version => Edition 3.1.1
22-11-2006 15:30Stephan SchulzNote Added: 0000288
24-11-2006 13:38Stephan SchulzRelationship addedrelated to 0000354
12-12-2008 11:52Ina SchieferdeckerResolutionsuspended => won't fix
12-12-2008 11:52Ina SchieferdeckerFixed in VersionEdition 3.1.1 =>
12-12-2008 11:52Ina SchieferdeckerTarget Version => Edition 3.1.1
12-12-2008 12:06Ina SchieferdeckerRelationship addedrelated to 0004483
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0000285) +
+ Stephan Schulz    +
+ 22-11-2006 14:04    +
+ 		+ + + + +
+ Will be addressed in the continuation project for STF213
+
+
+
+ + + + + + + + + + +
+ (0000288) +
+ Stephan Schulz    +
+ 22-11-2006 15:30    +
+ 		+ + + + +
+ This CR has been accidently field for Core Language. It should be really listed for GFT.
+
+ + diff --git a/docs/mantis/CR0356.md b/docs/mantis/CR0356.md new file mode 100644 index 0000000000000000000000000000000000000000..98ec3a258c3f44314d099175b129b7c5a6fab429 --- /dev/null +++ b/docs/mantis/CR0356.md @@ -0,0 +1,63 @@ + + + + + + + + + + + + + 0000356: Missing Predefined function hex2char - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0000356Part 01: TTCN-3 Core LanguageTechnicalpublic22-11-2006 14:0912-12-2008 11:57
ReporterStephan Schulz 
Assigned To 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionwon't fix 
PlatformOSOS Version
Product Versionv2.2.1 (published 2003-02) 
Target Versionv3.1.1 (published 2005-06)Fixed in Version 
Clause Reference(s)None
Source (company - Author)Maximilian Frey O2
Summary0000356: Missing Predefined function hex2char
DescriptionI have found a missing predefined function char2hex which the opposite of hex2char.
Steps To Reproduce
Additional InformationSee attachment
TagsNo tags attached.
Relationships
Attached Filesdoc CR_253 Resolution v1.doc (48,640) 22-11-2006 14:09
http://oldforge.etsi.org/mantis/file_download.php?file_id=30&type=bug
Issue History
Date ModifiedUsernameFieldChange
22-11-2006 14:09Stephan SchulzNew Issue
22-11-2006 14:09Stephan SchulzFile Added: CR_253 Resolution v1.doc
22-11-2006 14:09Stephan SchulzClause Reference(s) => None
22-11-2006 14:09Stephan SchulzSource (company - Author) => Maximilian Frey O2
22-11-2006 15:15Stephan SchulzStatusnew => closed
22-11-2006 15:15Stephan SchulzNote Added: 0000286
22-11-2006 15:15Stephan SchulzResolutionopen => won't fix
12-12-2008 11:57Ina SchieferdeckerTarget Version => Edition 3.1.1
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0000286) +
+ Stephan Schulz    +
+ 22-11-2006 15:15    +
+ 		+ + + + +
+ Concrete proposals for concrete conversion functions with established reason will be considered
+
+ + diff --git a/docs/mantis/CR0364.md b/docs/mantis/CR0364.md new file mode 100644 index 0000000000000000000000000000000000000000..4fd548a8e7b2cd614d240e5fd9efb21d4fb83501 --- /dev/null +++ b/docs/mantis/CR0364.md @@ -0,0 +1,81 @@ + + + + + + + + + + + + + 0000364: Add operations to the TciType Interface - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0000364Part 06: TTCN-3 Control InterfaceTechnicalpublic22-11-2006 15:2712-12-2008 11:38
ReporterStephan Schulz 
Assigned To 
PriorityhighSeveritymajorReproducibilityalways
StatusclosedResolutionwon't fix 
PlatformOSOS Version
Product Version 
Target Versionv3.2.1 (published 2007-02)Fixed in Version 
Clause Reference(s)7.2.2.1
Source (company - Author)Stephan Tobies, Nokia
Summary0000364: Add operations to the TciType Interface
DescriptionThe current interface of Type does not have support for the retrieval of the field names for structured types, and also no possibility to retrieve the type of a field. This makes is unnecessarily hard to, e.g., obtain attribute values for a types fields.
Steps To Reproduce
Additional Information7.2.2.1 Abstract TTCN-3 data types
+According to the present document TTCN-3 types, either predefined or user-defined, will be represented at the TCI interfaces using the abstract data type Type.
+For the abstract data type Type a set of operations is defined to:
+� reference predefined and user-defined TTCN-3 data types; and to
+� create and maintain TTCN-3 values.
+The following operations are defined for the abstract data type Type:
+TciModuleIdType getDefiningModule() Returns the module identifier of the module in which type is defined. Returns the distinct value null if type is a TTCN-3 base type, e.g. boolean, integer, etc.)
+TString getName() Returns the name of the type as defined in the TTCN-3 module
+TciTypeClassType getTypeClass() Returns the type class of the respective type. A value of TciTypeClassType can have one of the following constants: ADDRESS, ANYTYPE, BITSTRING, BOOLEAN, CHAR, CHARSTRING, COMPONENT, ENUMERATED, FLOAT, HEXSTRING, INTEGER, OBJID, OCTETSTRING, RECORD, RECORD_OF, SET, SET_OF, UNION, UNIVERSAL_CHARSTRING, UNIVERSAL_CHAR, VERDICT
+Value newInstance() Returns a freshly created value of the given type. This initial value of the created value is undefined
+TString getTypeEncoding() Returns the type encoding attribute as defined in the TTCN-3 module
+TString getTypeEncodingVariant() This operation returns the value encoding variant attribute as defined in TTCN-3, if any. If no encoding variant attribute is defined the distinct value null is returned
+
+TStringSeq getFieldNames() If the type is of type class SET, RECORD, or UNION, this operation returns the field names for that type. The empty sequence is returned, if the type is a record, set, or union with no fields. The distinct value null is returned if the type is of a different type class.
+
+Type getFieldType() If the type is of type class SET, RECORD, or UNION, this operation returns the type of the specified field of that type. The distinct value null is returned if the type is of a different type class or does not have a field of that name.
+
+Type getElementType() If the type is of type class RECORD OF, SET OF, ADDRESS, or ARRAY, this operation returns the type of the type's element type. The distinct value null is returned if the type is of a different type class.
+
TagsNo tags attached.
Relationships
related to 0000374closed  Request for adding tciGetModuleParType to the API 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
22-11-2006 15:27Stephan SchulzNew Issue
22-11-2006 15:27Stephan SchulzClause Reference(s) => 7.2.2.1
22-11-2006 15:27Stephan SchulzSource (company - Author) => Stephan Tobies, Nokia
22-11-2006 15:29Stephan SchulzStatusnew => closed
22-11-2006 15:29Stephan SchulzNote Added: 0000287
22-11-2006 15:29Stephan SchulzResolutionopen => won't fix
24-11-2006 13:41Stephan SchulzRelationship addedrelated to 0000374
12-12-2008 11:38Ina SchieferdeckerTarget Version => Edition 3.2.1
12-12-2008 11:38Ina SchieferdeckerAdditional Information Updated
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0000287) +
+ Stephan Schulz    +
+ 22-11-2006 15:29    +
+ 		+ + + + +
+ Rejected. If the problem still exists a CR with extension and generalization of the TCI type interface should be provided.
+
+ + diff --git a/docs/mantis/CR0369.md b/docs/mantis/CR0369.md new file mode 100644 index 0000000000000000000000000000000000000000..a6fe1e1a4998f8f95e6107019c257d1d1410012d --- /dev/null +++ b/docs/mantis/CR0369.md @@ -0,0 +1,63 @@ + + + + + + + + + + + + + 0000369: ++ and -- Operator - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0000369Part 01: TTCN-3 Core LanguageNew Featurepublic22-11-2006 15:4812-12-2008 12:04
ReporterStephan Schulz 
Assigned To 
PrioritynormalSeverityfeatureReproducibilityalways
StatusclosedResolutionwon't fix 
PlatformOSOS Version
Product Versionv3.1.1 (published 2005-06) 
Target Versionv3.2.1 (published 2007-02)Fixed in Version 
Clause Reference(s)None
Source (company - Author)Ina Schieferdecker FOKUS
Summary0000369: ++ and -- Operator
DescriptionFor ease of programming (e.g. in loops), an increment and decrement operator for integer would be very helpful.
Steps To Reproduce
Additional InformationTo include a ++ (increment by 1) and � (decrement by 1) operator for integers.
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
22-11-2006 15:48Stephan SchulzNew Issue
22-11-2006 15:48Stephan SchulzClause Reference(s) => None
22-11-2006 15:48Stephan SchulzSource (company - Author) => Ina Schieferdecker FOKUS
22-11-2006 15:49Stephan SchulzStatusnew => closed
22-11-2006 15:49Stephan SchulzNote Added: 0000290
22-11-2006 15:49Stephan SchulzResolutionopen => won't fix
12-12-2008 12:03Ina SchieferdeckerProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
12-12-2008 12:04Ina SchieferdeckerProduct Version => Edition 3.1.1
12-12-2008 12:04Ina SchieferdeckerTarget Version => Edition 3.2.1
12-12-2008 12:04Ina SchieferdeckerAdditional Information Updated
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0000290) +
+ Stephan Schulz    +
+ 22-11-2006 15:49    +
+ 		+ + + + +
+ Rejected since it is not a TTCN-3 -like operator
+
+ + diff --git a/docs/mantis/CR0370.md b/docs/mantis/CR0370.md new file mode 100644 index 0000000000000000000000000000000000000000..96edb3af747b03a1fa557363074b391fd42a0c24 --- /dev/null +++ b/docs/mantis/CR0370.md @@ -0,0 +1,75 @@ + + + + + + + + + + + + + 0000370: Component Parameters - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0000370Part 01: TTCN-3 Core LanguageTechnicalpublic22-11-2006 15:5512-12-2008 11:56
ReporterStephan Schulz 
Assigned To 
PriorityhighSeveritymajorReproducibilityalways
StatusclosedResolutionwon't fix 
PlatformOSOS Version
Product Versionv3.1.1 (published 2005-06) 
Target Versionv3.2.1 (published 2007-02)Fixed in Version 
Clause Reference(s)5.2.1.0
Source (company - Author)Ina Schieferdecker FOKUS
Summary0000370: Component Parameters
DescriptionComponent parameters are handled differently than port and timer parameters. The �architectural/configuration� objects should all be handled the same. Either they are considered to be references (then, all should be always in parameters) or they are considered to be objects (then, all should be always inout parameters). One of the choices should be taken but not a mix as it is currently done:
+5.2.1.0:
+By default, all actual parameters of basic types, basic string types, user-defined structured types, address type and component type are passed by value. This may optionally be denoted by the keyword in. To pass parameters of the mentioned types by reference the keywords out or inout shall be used.
+Timers and ports are always passed by reference and are identified by the keywords timer and port. The keyword inout may optionally be used to denote passing by reference
+
Steps To Reproduce
Additional InformationThe smallest change to TTCN-3 is to make component parameters also inout parameters:
+
+By default, all actual parameters of basic types, basic string types, user-defined structured types, and address type and component type are passed by value. This may optionally be denoted by the keyword in. To pass parameters of the mentioned types by reference the keywords out or inout shall be used.
+Timers Components, timers and ports are always passed by reference. Timer parameters and are identified by the keywords timer and port. The keyword inout may optionally be used to denote passing by reference.
+
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
22-11-2006 15:55Stephan SchulzNew Issue
22-11-2006 15:55Stephan SchulzClause Reference(s) => 5.2.1.0
22-11-2006 15:55Stephan SchulzSource (company - Author) => Ina Schieferdecker FOKUS
22-11-2006 15:56Stephan SchulzStatusnew => closed
22-11-2006 15:56Stephan SchulzNote Added: 0000291
22-11-2006 15:56Stephan SchulzResolutionopen => won't fix
12-12-2008 11:56Ina SchieferdeckerTarget Version => Edition 3.2.1
12-12-2008 11:56Ina SchieferdeckerDescription Updated
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0000291) +
+ Stephan Schulz    +
+ 22-11-2006 15:56    +
+ 		+ + + + +
+ For the following reasons, I recommend rejecting this CR:
+
+• The handling of component references is more comparable to the handling of values data types than the handling of ports and timers. It is allowed to have variables of component references, but it is not allowed to have variables of ports and timers. Therefore, component types should be handled more like data types than port types or timers.
+• The statement ports and timers are passed by reference is not completely correct. Correct is that names (= references) of ports and timers are passed in by constant value, i.e., you are not allowed to change the value (= references) of these names even within the called function (Note: setting or resetting a timer changes the status of a timer object but the name of the timer, which may be passed in, does not change), which is possible when passing in a variable of a component type or integer. In fact, timers and ports are more passed in like values than like references.
+• The call by value mechanism is a programming mechanism, which supports secure programming. I.e., it avoids the unwanted change of values as a side effect within a function. Disallowing, this mechanism for component references just because some people think that timers are closer to components than integer is very strange.
+
+ + diff --git a/docs/mantis/CR0371.md b/docs/mantis/CR0371.md new file mode 100644 index 0000000000000000000000000000000000000000..d8a103a2579978f7cbe9e4147e5afeacc241e1cf --- /dev/null +++ b/docs/mantis/CR0371.md @@ -0,0 +1,70 @@ + + + + + + + + + + + + + 0000371: Char is too allowing - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0000371Part 01: TTCN-3 Core LanguageTechnicalpublic22-11-2006 16:0112-12-2008 11:56
ReporterStephan Schulz 
Assigned To 
PriorityhighSeverityminorReproducibilityN/A
StatusclosedResolutionwon't fix 
PlatformOSOS Version
Product Versionv2.2.1 (published 2003-02) 
Target Versionv3.1.1 (published 2005-06)Fixed in Version 
Clause Reference(s)Annex A
Source (company - Author)dr. György Réthy, Ericsson
Summary0000371: Char is too allowing
DescriptionThe bnf production Char allows characters beyond ISO/IEC 10646 to include inside pairs double quotes, e.g. �abdỄï¿½ĎŞﻴﻺﻧ�. However this may cause problems when a test suite is transported between different platforms or machines installed with different language settings.
+This extra liberty is not needed to denote ISO/IEC 10646 characters as in string values the quadruple can be used while in patterns the \q{..} metacharacter can be applied(which contains ISO/IEC 646 graphical characters only).
+
Steps To Reproduce
Additional InformationAllow ISO/IEC 646 characters between pairs of double quotes:
+118. CharStringMatch ::= PatternKeyword Cstring
+448. CharStringValue ::= Cstring | Quadruple
+470. Cstring ::= """ {Char} """
+471. Char ::= /* REFERENCE - A character defined by the relevant CharacterString type. For charstring a character from the character set defined in ISO/IEC 646. For universal charstring a character from any character set defined in ISO/IEC 10646 */
+
TagsNo tags attached.
Relationships
Attached Filesdoc CR_327R3 Char is too allowing.doc (45,568) 22-11-2006 16:03
http://oldforge.etsi.org/mantis/file_download.php?file_id=31&type=bug
Issue History
Date ModifiedUsernameFieldChange
22-11-2006 16:01Stephan SchulzNew Issue
22-11-2006 16:01Stephan SchulzClause Reference(s) => Annex A
22-11-2006 16:01Stephan SchulzSource (company - Author) => dr. György Réthy, Ericsson
22-11-2006 16:03Stephan SchulzStatusnew => closed
22-11-2006 16:03Stephan SchulzNote Added: 0000292
22-11-2006 16:03Stephan SchulzResolutionopen => won't fix
22-11-2006 16:03Stephan SchulzFile Added: CR_327R3 Char is too allowing.doc
12-12-2008 11:56Ina SchieferdeckerProduct Version => Edition 2.2.1
12-12-2008 11:56Ina SchieferdeckerTarget Version => Edition 3.1.1
12-12-2008 11:56Ina SchieferdeckerDescription Updated
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0000292) +
+ Stephan Schulz    +
+ 22-11-2006 16:03    +
+ 		+ + + + +
+ STF solution: fix the available encodings in which TTCN-3 files in core notation may be stored.
+
+ + diff --git a/docs/mantis/CR0372.md b/docs/mantis/CR0372.md new file mode 100644 index 0000000000000000000000000000000000000000..64254a906ac837d85dc636d5afcb95c055cf33d6 --- /dev/null +++ b/docs/mantis/CR0372.md @@ -0,0 +1,31 @@ + + + + + + + + + + + + + 0000372: Add port parameters to operational semantics - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 04: TTCN-3 Operational Semantics
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0000372Part 04: TTCN-3 Operational SemanticsTechnicalpublic22-11-2006 16:0512-12-2008 11:42
ReporterStephan Schulz 
Assigned To 
PriorityhighSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv2.2.1 (published 2003-02) 
Target Versionv3.1.1 (published 2005-06)Fixed in Versionv3.1.1 (published 2005-06) 
Clause Reference(s)all
Source (company - Author)dr. György Réthy, Ericsson
Summary0000372: Add port parameters to operational semantics
DescriptionCurrently handling of port parameters is not covered by the operational semantics. To add this would be an important improvement, the more a simple technical solution exists.
Steps To Reproduce
Additional InformationAdd port parameters to altstep & function records. As port states are part of the module state, port parameters could simply be modelled as a name mapping:
+when a communication or port operation is executed the port name is first checked in the port-parameters section of the call record by a new function, e.g. retrievePort(portId) return realPortName; if no such section or the inPortName is not on the list, retrievePort returns NULL (i.e. the returned value can be disregarded), otherwise portId shall be changed to the real port name and continue operations as today.
+
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
22-11-2006 16:05Stephan SchulzNew Issue
22-11-2006 16:05Stephan SchulzClause Reference(s) => all
22-11-2006 16:05Stephan SchulzSource (company - Author) => dr. György Réthy, Ericsson
22-11-2006 16:06Stephan SchulzStatusnew => closed
22-11-2006 16:06Stephan SchulzResolutionopen => fixed
22-11-2006 16:06Stephan SchulzFixed in Version => Edition 3.1.1
12-12-2008 11:42Ina SchieferdeckerTarget Version => Edition 3.1.1
+
+ + + + +
+ There are no notes attached to this issue.
+ + diff --git a/docs/mantis/CR0373.md b/docs/mantis/CR0373.md new file mode 100644 index 0000000000000000000000000000000000000000..c5d4d1fff516898b4b9dd94521e9c95ef80c827c --- /dev/null +++ b/docs/mantis/CR0373.md @@ -0,0 +1,36 @@ + + + + + + + + + + + + + 0000373: Clarification of stop execute in operational semantics - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 04: TTCN-3 Operational Semantics
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0000373Part 04: TTCN-3 Operational SemanticsTechnicalpublic22-11-2006 16:0712-12-2008 11:41
ReporterStephan Schulz 
Assigned To 
PriorityhighSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv2.2.1 (published 2003-02) 
Target Versionv3.1.1 (published 2005-06)Fixed in Versionv3.1.1 (published 2005-06) 
Clause Reference(s)$9.49, $9.50
Source (company - Author)dr. György Réthy, Ericsson
Summary0000373: Clarification of stop execute in operational semantics
DescriptionTerms �stop component� and �stop execution� are not clarified (neither in the core nor in the OS). They are implicitly distinguished by the existence of a component reference in the statement. However, this is a pure syntactical matter and should not have any effect on the semantics (in the accompanying CR357 �Problems in the stop component operation in the operational semantics� a simple replacement stop -> self.stop is proposed for test cases, functions and altsteps).
+As the result currently stopping a test component is handled both by $9.49 and by $9.50 that is an unnecessary and disturbing duplication.
+
Steps To Reproduce
Additional InformationUse the following concept:
+- stop component means to stop the MTC (and as the consequence finishing the test case), a PTC or all PTCs (including both stopping itself and stopping by an another component)
+- stop execution means stopping the control part (namely execution of the test session).
+
+Once the above is accepted, subclause $9.50 can be considerably simplified as below.
+
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
22-11-2006 16:07Stephan SchulzNew Issue
22-11-2006 16:07Stephan SchulzClause Reference(s) => $9.49, $9.50
22-11-2006 16:07Stephan SchulzSource (company - Author) => dr. György Réthy, Ericsson
22-11-2006 16:08Stephan SchulzStatusnew => closed
22-11-2006 16:08Stephan SchulzResolutionopen => fixed
22-11-2006 16:08Stephan SchulzFixed in Version => Edition 3.1.1
12-12-2008 11:41Ina SchieferdeckerTarget Version => Edition 3.1.1
12-12-2008 11:41Ina SchieferdeckerDescription Updated
+
+ + + + +
+ There are no notes attached to this issue.
+ + diff --git a/docs/mantis/CR0374.md b/docs/mantis/CR0374.md new file mode 100644 index 0000000000000000000000000000000000000000..061fba23c4ed99cb9e5608bdba125f9cef5095a0 --- /dev/null +++ b/docs/mantis/CR0374.md @@ -0,0 +1,65 @@ + + + + + + + + + + + + + 0000374: Request for adding tciGetModuleParType to the API - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0000374Part 06: TTCN-3 Control InterfaceNew Featurepublic22-11-2006 16:0912-12-2008 11:37
ReporterStephan Schulz 
Assigned To 
PrioritynormalSeverityfeatureReproducibilityN/A
StatusclosedResolutionwon't fix 
PlatformOSOS Version
Product Version 
Target Versionv3.2.1 (published 2007-02)Fixed in Version 
Clause Reference(s)7.3.1.1.5, 7.3.1.2.4, 9.2
Source (company - Author)Iddo Bentov, www.hermonlabs.com
Summary0000374: Request for adding tciGetModuleParType to the API
DescriptionIf I want the let the user get the module parameters directly from the (SIP) test suite, instead of hardcoding the module parameters myself in the GUI, then I would also need to have a way to get the datatypes for the module parameters, in order to implement the tciGetModulePar callback correctly.
+Right now, it seems that it's only possible to get the datatype of a module parameter if it has a default value, and otherwise there's no way in the API to get the datatype of a module parameter.
+
Steps To Reproduce
Additional InformationIt'd be good if you could standardize this, by adding a function to the API, such as: TciType tciGetModuleParType(TciModuleParameterIdType parameterId);
TagsNo tags attached.
Relationships
related to 0000364closed  Add operations to the TciType Interface 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
22-11-2006 16:09Stephan SchulzNew Issue
22-11-2006 16:09Stephan SchulzClause Reference(s) => 7.3.1.1.5, 7.3.1.2.4, 9.2
22-11-2006 16:09Stephan SchulzSource (company - Author) => Iddo Bentov, www.hermonlabs.com
22-11-2006 16:11Stephan SchulzStatusnew => closed
22-11-2006 16:11Stephan SchulzNote Added: 0000293
22-11-2006 16:11Stephan SchulzResolutionopen => won't fix
24-11-2006 13:41Stephan SchulzRelationship addedrelated to 0000364
12-12-2008 11:37Ina SchieferdeckerTarget Version => Edition 3.2.1
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0000293) +
+ Stephan Schulz    +
+ 22-11-2006 16:11    +
+ 		+ + + + +
+ Rejected for same reason as issue 0000364
+
+ + diff --git a/docs/mantis/CR0375.md b/docs/mantis/CR0375.md new file mode 100644 index 0000000000000000000000000000000000000000..039c2b742f499b198d46ff5161bb038c75cfbff0 --- /dev/null +++ b/docs/mantis/CR0375.md @@ -0,0 +1,73 @@ + + + + + + + + + + + + + 0000375: Add memory management capabilities to the TCI - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0000375Part 06: TTCN-3 Control InterfaceTechnicalpublic22-11-2006 16:1412-12-2008 11:38
ReporterStephan Schulz 
Assigned To 
PriorityhighSeverityminorReproducibilityN/A
StatusclosedResolutionwon't fix 
PlatformOSOS Version
Product Version 
Target Versionv3.2.1 (published 2007-02)Fixed in Version 
Clause Reference(s)7.2.2.2.1, 8.2.4.1
Source (company - Author)Stephan Tobies, Nokia
Summary0000375: Add memory management capabilities to the TCI
DescriptionThe current version of the TCI does not make any statements about the lifetime of handles, which make memory management for languages without automatic memory management unnecessarily hard.
Steps To Reproduce
Additional InformationIn 7.2.2.2.1 The abstract data type Value .. add
+
+void release() Indicates that the invoking entity will no longer use this reference to a value.
+
+In 8.2.4.1 Value
+...
+Methods:
+...
+� There is no release() method. Memory management is automatic in Java and does not require explicit releasing of allocated memory.
+
+
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
22-11-2006 16:14Stephan SchulzNew Issue
22-11-2006 16:14Stephan SchulzClause Reference(s) => 7.2.2.2.1, 8.2.4.1
22-11-2006 16:14Stephan SchulzSource (company - Author) => Stephan Tobies, Nokia
22-11-2006 16:15Stephan SchulzStatusnew => closed
22-11-2006 16:15Stephan SchulzNote Added: 0000294
22-11-2006 16:15Stephan SchulzResolutionopen => won't fix
12-12-2008 11:38Ina SchieferdeckerTarget Version => Edition 3.2.1
12-12-2008 11:38Ina SchieferdeckerAdditional Information Updated
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0000294) +
+ Stephan Schulz    +
+ 22-11-2006 16:15    +
+ 		+ + + + +
+ Rejected to be aligned with TRI, where memory handling has been rejected too
+
+ + diff --git a/docs/mantis/CR0377.md b/docs/mantis/CR0377.md new file mode 100644 index 0000000000000000000000000000000000000000..bce540b1d3d8b7bdc0e5b5eba1a3ad5caa87c5a1 --- /dev/null +++ b/docs/mantis/CR0377.md @@ -0,0 +1,66 @@ + + + + + + + + + + + + + 0000377: Trigger operations for procedure based communication - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0000377Part 01: TTCN-3 Core LanguageNew Featurepublic23-11-2006 13:4212-12-2008 11:55
ReporterStephan Schulz 
Assigned To 
PrioritynormalSeverityfeatureReproducibilityN/A
StatusclosedResolutionwon't fix 
PlatformOSOS Version
Product Versionv2.2.1 (published 2003-02) 
Target Versionv3.1.1 (published 2005-06)Fixed in Version 
Clause Reference(s)none
Source (company - Author)Matti Kärki, Techinal Research Centre of Finland, VTT Electronics
Summary0000377: Trigger operations for procedure based communication
DescriptionCurrently only message based communication supports trigger operation which provides shorthand for an alt statement with only one alternative and therefore simplifies test behavior. Introducing trigger operations for procedure based communication provides the means to wait for the specified call or reply on that queue.
Steps To Reproduce
Additional InformationDefine triggercall operation which waits the specified call and removes the top calls from the associated incoming queue.
+Define triggerreply operation which waits the specified reply and removes the top replies from the associated incoming queue.
+The semantics are same as for message based trigger operation.
+
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
23-11-2006 13:42Stephan SchulzNew Issue
23-11-2006 13:42Stephan SchulzClause Reference(s) => none
23-11-2006 13:42Stephan SchulzSource (company - Author) => Matti Kärki, Techinal Research Centre of Finland, VTT Electronics
23-11-2006 13:42Stephan SchulzStatusnew => closed
23-11-2006 13:42Stephan SchulzNote Added: 0000305
23-11-2006 13:42Stephan SchulzResolutionopen => won't fix
12-12-2008 11:55Ina SchieferdeckerTarget Version => Edition 3.1.1
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0000305) +
+ Stephan Schulz    +
+ 23-11-2006 13:42    +
+ 		+ + + + +
+ Rejected. Rather deprecate trigger than further extend it.
+
+ + diff --git a/docs/mantis/CR0378.md b/docs/mantis/CR0378.md new file mode 100644 index 0000000000000000000000000000000000000000..8563e849367ba2c5e376fccf445a34727143072f --- /dev/null +++ b/docs/mantis/CR0378.md @@ -0,0 +1,110 @@ + + + + + + + + + + + + + 0000378: Return values of PTC behaviour functions - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0000378Part 01: TTCN-3 Core LanguageTechnicalpublic23-11-2006 13:4921-04-2008 09:03
ReporterStephan Schulz 
Assigned ToIna Schieferdecker 
PriorityhighSeverityminorReproducibilityN/A
StatusclosedResolutionwon't fix 
PlatformOSOS Version
Product Versionv2.2.1 (published 2003-02) 
Target Versionv3.4.1 (published 2008-09)Fixed in Version 
Clause Reference(s)$22, Annex A
Source (company - Author) dr. György Réthy, Ericsson Hungary Lim.
Summary0000378: Return values of PTC behaviour functions
DescriptionIn the standard no restriction applies to functions invoked by a start (test component) operation regarding the return clause. Such functions may have return clauses and specify return values like functions not invoked by start. This causes two problems:
+1) It is undefined how the return value shall be handled by the system; intuitively it is lost, but exact behavior is not specified.
+2) In several cases it is necessary to preserve variable values even when the PTC instance generating them has already ended its behaviour. For example when a PTC behaviour handles a complete incoming call and several outgoing calls wanted to be set-up using the same call reference afterwards; or on the contrary, values used by a (finished) PTC instance shall not be used again by subsequently started PTCs.
+Today the only way to preserve PTC variable values of finished PTCs is by sending coordination messages. This solution has several disadvantages:
+a) Coordination messages has to be caught by the addressee. This effects the addressee behaviour; as coordination messages may arrive in any moment, the most appropriate to use defaults to catch them; however, if the coordination message arrives when the addressee expects another receiving event(s), it causes an extra "side" snapshot and evaluation.
+b) There may be more than one addressee and addressee(s) is(are) not necessary known at the time when the sender PTC is started (so their references shall be sent by other co-ordination message(s)).
+c) In load tests unnecessary internal system load is generated decreasing the performance of the test system.
+d) Test suites become needlessly complicated difficult to maintain and logs are loaded with messages not related to the real test behaviour.
+
Steps To Reproduce
Additional InformationIt is proposed that the return value of a PTC behaviour function ? if any - is stored by the test system when the PTC behaviour is finished(aside the status of PTC references). Allow any other running component to request this return value from the system by using a newly defined operation. Introduction of a new operation is necessary to avoid effects on the use of the done operation in alt statements.
+As a result "distribution" of the return value is not controlled by the actually finishing PTC but obtained from the system by components wishing using it just at the moment of its use.
+See detailed proposal in the attachment.
+
TagsNo tags attached.
Relationships
related to 0000380closed Ina Schieferdecker Inout parameters for function in start test component operation 
Attached Filesdoc CR 224 Return values of PTC behaviour functions.doc (70,144) 23-11-2006 13:49
http://oldforge.etsi.org/mantis/file_download.php?file_id=32&type=bug
Issue History
Date ModifiedUsernameFieldChange
23-11-2006 13:49Stephan SchulzNew Issue
23-11-2006 13:49Stephan SchulzFile Added: CR 224 Return values of PTC behaviour functions.doc
23-11-2006 13:49Stephan SchulzClause Reference(s) => $22, Annex A
23-11-2006 13:49Stephan SchulzSource (company - Author) => dr. György Réthy, Ericsson Hungary Lim.
23-11-2006 13:53Stephan SchulzStatusnew => assigned
23-11-2006 13:53Stephan SchulzAssigned To => Stephan Schulz
23-11-2006 13:54Stephan SchulzAssigned ToStephan Schulz =>
23-11-2006 13:54Stephan SchulzAssigned To => user10
23-11-2006 13:54Stephan SchulzStatusassigned => acknowledged
23-11-2006 13:54Stephan SchulzStatusacknowledged => assigned
23-11-2006 13:54Stephan SchulzAssigned Touser10 => Stephan Schulz
23-11-2006 13:55Stephan SchulzAssigned ToStephan Schulz => Jens Grabowski
24-11-2006 15:08Stephan SchulzRelationship addedrelated to 0000380
15-10-2007 16:52Ina SchieferdeckerNote Added: 0003624
18-10-2007 14:26Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
18-10-2007 14:26Ina SchieferdeckerAdditional Information Updated
13-03-2008 15:37Ina SchieferdeckerAssigned ToJens Grabowski => Ina Schieferdecker
14-03-2008 09:17Ina SchieferdeckerNote Added: 0005230
14-03-2008 09:18Ina SchieferdeckerStatusassigned => closed
14-03-2008 09:18Ina SchieferdeckerResolutionopen => won't fix
21-04-2008 09:03Ina SchieferdeckerTarget VersionEdition 4.1.1 (not yet published) => Edition 3.4.1 (not yet published)
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0003624) +
+ Ina Schieferdecker    +
+ 15-10-2007 16:52    +
+ 		+ + + + +
+ to be considered in 2008 in the context of test configurations
+
+
+
+ + + + + + + + + + +
+ (0005230) +
+ Ina Schieferdecker    +
+ 14-03-2008 09:17    +
+ 		+ + + + +
+ This CR would require to know the return type at every possible place of invoking the done operation - for example, by defining a return type in the component type definition. This would add another form of passing information - which can however also be resolved by explicit communiction by the test component, which is currently being considered not being worth the effort.
+
+It might be reconsidered in the context of parallel execution and/or test configurations.
+
+ + diff --git a/docs/mantis/CR0379.md b/docs/mantis/CR0379.md new file mode 100644 index 0000000000000000000000000000000000000000..f60c1f81ae130a1fdd6a45320e7a3c61f02a5248 --- /dev/null +++ b/docs/mantis/CR0379.md @@ -0,0 +1,108 @@ + + + + + + + + + + + + + 0000379: Add triEndTestcase operation to TRI - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 05: TTCN-3 Runtime Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0000379Part 05: TTCN-3 Runtime Interface Technicalpublic23-11-2006 13:5712-12-2008 11:40
ReporterStephan Schulz 
Assigned To 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv3.2.1 (published 2007-02)Fixed in Versionv3.2.1 (published 2007-02) 
Clause Reference(s)Clause 5.2.2
Source (company - Author)Stephan Tobies, Nokia
Summary0000379: Add triEndTestcase operation to TRI
DescriptionThe current version of the TRI has no provision to inform the SA of the termination of a test case. This leads to the fact that the SA may attempt to communicate with components even after they have finished and/or may lock resources that should be released once the test case has finished.
Steps To Reproduce
Additional InformationAdd a TRI operation triEndTestcase to the SA-erlated operations that is invoked by the TE when a test case has finished. This will allow the SA to free resources and to cease communication with componenets reliably.
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
23-11-2006 13:57Stephan SchulzNew Issue
23-11-2006 13:57Stephan SchulzClause Reference(s) => Clause 5.2.2
23-11-2006 13:57Stephan SchulzSource (company - Author) => Stephan Tobies, Nokia
23-11-2006 13:58Stephan SchulzNote Added: 0000306
23-11-2006 13:58Stephan SchulzStatusnew => closed
23-11-2006 13:58Stephan SchulzResolutionopen => fixed
23-11-2006 13:58Stephan SchulzFixed in Version => Edition 3.2.1 (not yet published)
12-12-2008 11:40Ina SchieferdeckerTarget Version => Edition 3.2.1
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0000306) +
+ Stephan Schulz    +
+ 23-11-2006 13:58    +
+ 		+ + + + +
+ Proposed STF solution:
+
+
+Add the triEndTestcase to the TRI document as follows:
+
+Change Table 2:
+
+Table 2: Correlation between TTCN-3 and TRI Operation Invocations (* = if applicable)
+TTCN-3 Operation Name TRI Operation Name TRI Interface Name
+execute triExecuteTestCase
+triStartTimer*
+triEndTestCase TriCommunication
+TriPlatform
+TriCommunication
+…
+
+
+Make new 5.5.2.4:
+
+    5.5.2.4 triEndTestCase (TE  SA)
+Signature TriStatusType triEndTestCase()
+In Parameters n.a.
+Out Parameters n.a.
+Return Value The return status of the triEndTestCase operation. The return status indicates the local success (TRI_OK) or failure (TRI_Error) of the operation.
+Constraints This operation is called by the TE immediately after the execution of any test case.
+Effect The SA can free resources, cease communication at system ports and to test components.
+The triEndTestCase operation returns TRI_OK in case the operation has been successfully performed, TRI_Error otherwise.
+
+
+
+Add to 6.5.2.1 in the connection handling operations:
+
+    // Ref: TRI-Definition 5.5.2.4
+    public TriStatus triEndTestCase();
+
+
+
+Add to 7.2.4
+
+TriStatusType triEndTestCase() TriStatus triEndTestCase()
+
+
+
+Add to Annex A:
+
+    TriStatusType triEndTestCase();
+
+ + diff --git a/docs/mantis/CR0380.md b/docs/mantis/CR0380.md new file mode 100644 index 0000000000000000000000000000000000000000..a3b17a14687a6fe3997bcf1ff08a0e71c6200438 --- /dev/null +++ b/docs/mantis/CR0380.md @@ -0,0 +1,40 @@ + + + + + + + + + + + + + 0000380: Inout parameters for function in start test component operation - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0000380Part 01: TTCN-3 Core LanguageEditorialpublic23-11-2006 14:0212-03-2008 10:24
ReporterStephan Schulz 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv2.2.1 (published 2003-02) 
Target Versionv3.3.2 (published 2008-04)Fixed in Versionv3.3.2 (published 2008-04) 
Clause Reference(s)22.5 The Start test component operation
Source (company - Author)Ina Schieferdecker, FOKUS
Summary0000380: Inout parameters for function in start test component operation
DescriptionChange
+The following restrictions apply to a function invoked in a start test component operation:
+? If this function has parameters they shall only be in parameters, i.e. parameters by value.
+? This function shall have a runs on definition referencing the same component type as the newly created component.
+? Ports and timers shall not be passed into this function.
+
Steps To Reproduce
Additional InformationTo
+The following restrictions apply to a function invoked in a start test component operation:
+? If this function has parameters they shall only be in or inout parameters, i.e. parameters by value.
+? This function shall have a runs on definition referencing the same component type as the newly created component.
+? Ports and timers shall not be passed into this function.
+NOTE: Possible return values of the (optional) function return and of inout parameters (if present) have no effect when the test component terminates.
+
TagsNo tags attached.
Relationships
related to 0000378closed Ina Schieferdecker Return values of PTC behaviour functions 
Attached Files? CR-380-Return-Values-In-Start-Functions-Resolution (199,680) 20-11-2007 08:00
http://oldforge.etsi.org/mantis/file_download.php?file_id=1127&type=bug
doc CR-380-Return-Values-In-Start-Functions-Resolution-Revision1-071205.doc (203,776) 05-12-2007 14:15
http://oldforge.etsi.org/mantis/file_download.php?file_id=1216&type=bug
Issue History
Date ModifiedUsernameFieldChange
23-11-2006 14:02Stephan SchulzNew Issue
23-11-2006 14:02Stephan SchulzClause Reference(s) => 22.5 The Start test component operation
23-11-2006 14:02Stephan SchulzSource (company - Author) => Ina Schieferdecker, FOKUS
23-11-2006 14:02Stephan SchulzStatusnew => assigned
23-11-2006 14:02Stephan SchulzAssigned To => Jens Grabowski
24-11-2006 15:08Stephan SchulzRelationship addedrelated to 0000378
18-10-2007 14:32Ina SchieferdeckerTarget Version => Edition 3.3.1 (not yet published)
18-10-2007 14:32Ina SchieferdeckerDescription Updated
18-10-2007 14:32Ina SchieferdeckerAdditional Information Updated
20-11-2007 08:00Jens GrabowskiFile Added: CR-380-Return-Values-In-Start-Functions-Resolution
20-11-2007 08:01Jens GrabowskiAssigned ToJens Grabowski => Gyorgy Rethy
20-11-2007 08:01Jens GrabowskiResolutionopen => fixed
05-12-2007 11:44Jens GrabowskiAssigned ToGyorgy Rethy => Jens Grabowski
05-12-2007 14:14Jens GrabowskiFile Added: CR-421-Default-In-Interleave-Resolution-Revision1-071205.doc
05-12-2007 14:15Jens GrabowskiFile Deleted: CR-421-Default-In-Interleave-Resolution-Revision1-071205.doc
05-12-2007 14:15Jens GrabowskiFile Added: CR-380-Return-Values-In-Start-Functions-Resolution-Revision1-071205.doc
05-12-2007 14:15Jens GrabowskiAssigned ToJens Grabowski => Ina Schieferdecker
05-12-2007 14:15Jens GrabowskiStatusassigned => resolved
05-12-2007 17:50Ina SchieferdeckerStatusresolved => closed
05-12-2007 17:50Ina SchieferdeckerFixed in Version => Edition 3.3.1 (not yet published)
12-03-2008 10:22user10Fixed in VersionEdition 3.3.1 --will not be published, see 3.3.2 => Edition 3.3.2 (not yet published)
12-03-2008 10:24user10Target VersionEdition 3.3.1 --will not be published, see 3.3.2 => Edition 3.3.2 (not yet published)
+
+ + + + +
+ There are no notes attached to this issue.
+ + diff --git a/docs/mantis/CR0381.md b/docs/mantis/CR0381.md new file mode 100644 index 0000000000000000000000000000000000000000..6b5241d6a605f0edb54282a75879460f4386e91d --- /dev/null +++ b/docs/mantis/CR0381.md @@ -0,0 +1,99 @@ + + + + + + + + + + + + + 0000381: External Applications - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0000381Part 01: TTCN-3 Core LanguageNew Featurepublic23-11-2006 14:0620-04-2009 12:08
ReporterStephan Schulz 
Assigned ToJens Grabowski 
PrioritynormalSeverityfeatureReproducibilityN/A
StatusclosedResolutionwon't fix 
PlatformOSOS Version
Product Versionv2.2.1 (published 2003-02) 
Target Versionv4.2.1 (published 2010-07)Fixed in Version 
Clause Reference(s)-
Source (company - Author)Ina Schieferdecker
Summary0000381: External Applications
DescriptionTTCN-3 has an inability to define the execution of arbitrary test scripts which prevents potential users with an already existing stock of different test solutions from using TTCN-3. The possible translation of existing test scripts being defined for example in Perl, Python or Tcl is not feasible as there is no mapping available for every script language. Even if the mappings would have been available, the implementation of translators or migration tools would exceed current budgets allocated for testing.
+So, the overall goal is to provide a generic approach on how to integrate arbitrary scripts in a TTCN-3 execution environment. Extending the TTCN-3 language with the capability of external behaviours can be done with a new combination of existing concepts that respects the current architecture of TTCN-3 test systems as defined by TRI and TCI.
+
Steps To Reproduce
Additional InformationSee attachment for solution proposal
TagsNo tags attached.
Relationships
related to 0000413closed Jens Grabowski Static test configurations 
Attached Filesdoc CR_318 External Applications.doc (45,568) 23-11-2006 14:06
http://oldforge.etsi.org/mantis/file_download.php?file_id=33&type=bug
Issue History
Date ModifiedUsernameFieldChange
23-11-2006 14:06Stephan SchulzNew Issue
23-11-2006 14:06Stephan SchulzFile Added: CR_318 External Applications.doc
23-11-2006 14:06Stephan SchulzClause Reference(s) => -
23-11-2006 14:06Stephan SchulzSource (company - Author) => Ina Schieferdecker
23-11-2006 14:06Stephan SchulzStatusnew => assigned
23-11-2006 14:06Stephan SchulzAssigned To => Jens Grabowski
15-10-2007 16:52Ina SchieferdeckerNote Added: 0003623
18-10-2007 14:26Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
12-12-2008 09:25Ina SchieferdeckerNote Added: 0007669
12-12-2008 09:25Ina SchieferdeckerTarget VersionEdition 4.1.1 (not yet published) => Edition 4.2.1 (not yet published)
12-12-2008 09:25Ina SchieferdeckerRelationship addedrelated to 0000413
20-04-2009 12:08Ina SchieferdeckerStatusassigned => closed
20-04-2009 12:08Ina SchieferdeckerResolutionopen => won't fix
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0003623) +
+ Ina Schieferdecker    +
+ 15-10-2007 16:52    +
+ 		+ + + + +
+ to be considered in 2008 in the context of test configurations/deployment
+
+
+
+ + + + + + + + + + +
+ (0007669) +
+ Ina Schieferdecker    +
+ 12-12-2008 09:25    +
+ 		+ + + + +
+ To be discussed once the deployment and configuration package has been defined.
+
+ + diff --git a/docs/mantis/CR0382.md b/docs/mantis/CR0382.md new file mode 100644 index 0000000000000000000000000000000000000000..8551fd6f19f9c981fe6c90bc9cf200c561dee658 --- /dev/null +++ b/docs/mantis/CR0382.md @@ -0,0 +1,69 @@ + + + + + + + + + + + + + 0000382: Iterators for record of/set of structures - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0000382Part 01: TTCN-3 Core LanguageNew Featurepublic23-11-2006 14:0812-12-2008 11:49
ReporterStephan Schulz 
Assigned To 
PrioritynormalSeverityfeatureReproducibilityN/A
StatusclosedResolutionwon't fix 
PlatformOSOS Version
Product Versionv2.2.1 (published 2003-02) 
Target Versionv3.1.1 (published 2005-06)Fixed in Version 
Clause Reference(s)-
Source (company - Author) Ina Schieferdecker FOKUS
Summary0000382: Iterators for record of/set of structures
DescriptionFor ease of programming (e.g. in loops), an iteration operator for set and record of/set of structures would be very helpful.
Steps To Reproduce
Additional InformationThe following possible operators should be discussed:
+For_each: being an iterator on the elements of a record of/set of structure
+Map_list: taking a function that converts/transforms/� the record of/set of elements and returns a record of/set of structure containing the converted/transformed/� elements
+Filter_list: taking a boolean expression on the record of/set of elements and returns a record of/set of structure containing all those elements for which the boolean expression is true
+Reverse: gives the record of structure in reverse order (not sure, if that should be provided also for set of)
+If accepted, we will define how to include it into the standard.
+
TagsNo tags attached.
Relationships
related to 0000424closed Ina Schieferdecker operations on "record of" structures 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
23-11-2006 14:08Stephan SchulzNew Issue
23-11-2006 14:08Stephan SchulzClause Reference(s) => -
23-11-2006 14:08Stephan SchulzSource (company - Author) => Ina Schieferdecker FOKUS
23-11-2006 14:12Stephan SchulzStatusnew => closed
23-11-2006 14:12Stephan SchulzNote Added: 0000307
24-11-2006 15:05Stephan SchulzRelationship addedrelated to 0000424
12-12-2008 11:49Ina SchieferdeckerResolutionopen => won't fix
12-12-2008 11:49Ina SchieferdeckerTarget Version => Edition 3.1.1
12-12-2008 11:49Ina SchieferdeckerAdditional Information Updated
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0000307) +
+ Stephan Schulz    +
+ 23-11-2006 14:12    +
+ 		+ + + + +
+ Merged with issue 0000378
+
+ + diff --git a/docs/mantis/CR0383.md b/docs/mantis/CR0383.md new file mode 100644 index 0000000000000000000000000000000000000000..a811bcf80c9d80e971aae5ef38918903657f9492 --- /dev/null +++ b/docs/mantis/CR0383.md @@ -0,0 +1,559 @@ + + + + + + + + + + + + + 0000383: Error Cases of Predefined Functions - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0000383Part 01: TTCN-3 Core LanguageEditorialpublic23-11-2006 14:1612-03-2008 10:24
ReporterStephan Schulz 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv2.2.1 (published 2003-02) 
Target Versionv3.3.2 (published 2008-04)Fixed in Versionv3.3.2 (published 2008-04) 
Clause Reference(s)Main Document: C.1 to C.34 (mockup v2)
Source (company - Author)Ina Schieferdecker, FOKUS
Summary0000383: Error Cases of Predefined Functions
DescriptionThe error cases for the predefined functions are not provided. These should be added in order to give a more precise definition for these functions.
Steps To Reproduce
Additional InformationPlease add to the C.x sections a paragraph on the error cases:
+C.1 Integer to character
+?
+The following error cases will lead to an error at compile or runtime:
+? value is unitialized
+? value is not of integer type
+? value is less than 0 or greater than 127
+
+?
+C.2 Character to integer
+?
+The following error cases will lead to an error at compile or runtime:
+? value is unitialized
+? value is not of charstring type
+? lengthof(value) does not equal 1
+?
+C.3 Integer to universal character
+?
+The following error cases will lead to an error at compile or runtime:
+? value is unitialized
+? value is not of integer type
+? value is less than 0 or greater than 2147483647
+?
+C.4 Universal character to integer
+?
+The following error cases will lead to an error at compile or runtime:
+? value is unitialized
+? value is not of universal charstring type
+? lengthof(value) does not equal 1
+?
+C.5 Bitstring to integer
+?
+The following error cases will lead to an error at compile or runtime:
+? value is unitialized
+? value is not of bitstring type
+? the integer interpretation of the bitstring leads to an overflow
+
+NOTE: The possibility of integer overflow may make TTCN-3 code using this predefined function not portable between TTCN-3 environments having different integer ranges.
+?
+C.6 Hexstring to integer
+?
+The following error cases will lead to an error at compile or runtime:
+? value is unitialized
+? value is not of hexstring type
+? the integer interpretation of the hexstring leads to an overflow
+
+NOTE: The possibility of integer overflow may make TTCN-3 code using this predefined function not portable between TTCN-3 environments having different integer ranges.
+?
+C.7 Octetstring to integer
+?
+The following error cases will lead to an error at compile or runtime:
+? value is unitialized
+? value is not of octetstring type
+? the integer interpretation of the octetstring leads to an overflow
+
+NOTE: The possibility of integer overflow may make TTCN-3 code using this predefined function not portable between TTCN-3 environments having different integer ranges.
+?
+C.8 Charstring to integer
+?
+The following error cases will lead to an error at compile or runtime:
+? value is unitialized
+? value is not of charstring type
+? value contains non-numerical characters, being different to ?0?..?9?
+? the integer interpretation of the charstring leads to an overflow
+
+NOTE: The possibility of integer overflow may make TTCN-3 code using this predefined function not portable between TTCN-3 environments having different integer ranges.
+?
+C.9 Integer to bitstring
+?
+If the conversion yields a value with more bits than specified in the length parameter, then the bitstring shall be cut at position length-1.
+
+The following error cases will lead to an error at compile or runtime:
+? value or length is unitialized
+? value or length is not of integer type
+? value is less than zero
+
+NOTE: As TTCN-3 environments may support different integer ranges there is the possibility that TTCN-3 code using this predefined function is not portable.
+?
+C.10 Integer to hexstring
+?
+If the conversion yields a value with more hexadecimals than specified in the length parameter, then the hexstring shall be cut at position length-1.
+
+The following error cases will lead to an error at compile or runtime:
+? value or length is unitialized
+? value or length is not of integer type
+? value is less than zero
+
+NOTE: As TTCN-3 environments may support different integer ranges there is the possibility that TTCN-3 code using this predefined function is not portable.
+?
+C.11 Integer to octetstring
+?
+If the conversion yields a value with more octets than specified in the length parameter, then the octetstring shall be cut at position length-1.
+
+The following error cases will lead to an error at compile or runtime:
+? value or length is unitialized
+? value or length is not of integer type
+? value is less than zero
+
+NOTE: As TTCN-3 environments may support different integer ranges there is the possibility that TTCN-3 code using this predefined function is not portable.
+?
+C.12 Integer to charstring
+?
+The following error cases will lead to an error at compile or runtime:
+? value is unitialized
+? value is not of integer type
+
+NOTE: As TTCN-3 environments may support different integer ranges there is the possibility that TTCN-3 code using this predefined function is not portable.
+?
+C.13 Length of string type
+?
+The following error cases will lead to an error at compile or runtime:
+? value is unitialized
+? value is not of string type
+? the integer length of value leads to an overflow
+
+NOTE: The possibility of integer overflow may make TTCN-3 code using this predefined function not portable between TTCN-3 environments having different integer ranges.
+?
+C.14 Number of elements in a structured value
+?
+The following error cases will lead to an error at compile or runtime:
+? value is unitialized
+? value is not of record, record of, set, set of, objid or array type
+? the number of elements of value leads to an overflow
+
+NOTE: The possibility of integer overflow may make TTCN-3 code using this predefined function not portable between TTCN-3 environments having different integer ranges.
+?
+C.15 The IsPresent function
+?
+The following error cases will lead to an error at compile or runtime:
+? value is unitialized
+? value is not referring to a field in a data object of type record or set
+?
+C.16 The IsChosen function
+?
+The following error cases will lead to an error at compile or runtime:
+? value is unitialized
+? value is not referring to a field in a data object of type union
+?
+C.17 The Regexp function
+?
+The number of the group to be returned is specified by groupno, which shall be a non-negative integer. Group numbers are assigned by the order of occurrences of the opening bracket of a group and counted starting from 0 by step 1.
+?
+The following error cases will lead to an error at compile or runtime:
+? instr, expression, or groupno is unitialized
+? instr is not of charstring or universal charstring type
+? expression is not of charstring type
+? groupno is not of integer type
+? groupno is less than 0
+
+NOTE: As TTCN-3 environments may support different integer ranges there is the possibility that TTCN-3 code using this predefined function is not portable.
+?
+C.18 Bitstring to charstring
+?
+The following error cases will lead to an error at compile or runtime:
+? value is unitialized
+? value is not of base type bitstring
+?
+C.19 Hexstring to charstring
+?
+The following error cases will lead to an error at compile or runtime:
+? value is unitialized
+? value is not of base type hexstring
+?
+C.20 Octetstring to character string
+?
+The following error cases will lead to an error at compile or runtime:
+? value is unitialized
+? value is not of base type octetstring
+?
+C.21 Character string to octetstring
+?
+The following error cases will lead to an error at compile or runtime:
+? value is unitialized
+? value is not of base type charstring
+?
+C.22 Bitstring to hexstring
+?
+The following error cases will lead to an error at compile or runtime:
+? value is unitialized
+? value is not of base type bitstring
+?
+C.23 Hexstring to octetstring
+?
+The following error cases will lead to an error at compile or runtime:
+? value is unitialized
+? value is not of base type hexstring
+?
+C.24 Bitstring to octetstring
+?
+The following error cases will lead to an error at compile or runtime:
+? value is unitialized
+? value is not of base type bitstring
+?
+C.25 Hexstring to bitstring
+?
+The following error cases will lead to an error at compile or runtime:
+? value is unitialized
+? value is not of base type hexstring
+?
+C.26 Octetstring to hexstring
+?
+The following error cases will lead to an error at compile or runtime:
+? value is unitialized
+? value is not of base type octetstring
+?
+C.27 Octetstring to bitstring
+?
+The following error cases will lead to an error at compile or runtime:
+? value is unitialized
+? value is not of base type octetstring
+?
+C.28 Integer to float
+?
+The following error cases will lead to an error at compile or runtime:
+? value is unitialized
+? value is not of base type integer
+
+NOTE: As TTCN-3 environments may support different integer or float ranges there is the possibility that TTCN-3 code using this predefined function is not portable.
+?
+C.29 Float to integer
+?
+The following error cases will lead to an error at compile or runtime:
+? value is unitialized
+? value is not of base type float
+
+NOTE: As TTCN-3 environments may support different integer or float ranges there is the possibility that TTCN-3 code using this predefined function is not portable.
+?
+C.30 The random number generator function
+?
+The following error cases will lead to an error at compile or runtime:
+? (the optional) seed is unitialized
+? (the optional) seed is not of base type float
+
+NOTE: As TTCN-3 environments may support different float ranges there is the possibility that TTCN-3 code using this predefined function with the seed parameter is not portable.
+?
+C.31 The Substring function
+?
+The following error cases will lead to an error at compile or runtime:
+? value, index, or returncount is unitialized
+? value is not of base type charstring, universal charstring, bitstring, octetstring, or hexstring
+? index or returncount is not of base type integer
+? index is less than zero or greater than lengthof(value)
+? returncount is less than zero or greater than lengthof(value)
+? index+returncount is greater than lengthof(value)
+
+NOTE: As TTCN-3 environments may support different integer ranges there is the possibility that TTCN-3 code using this predefined function is not portable.
+?
+C.32 Number of elements in a structured type
+?
+The following error cases will lead to an error at compile or runtime:
+? value is unitialized
+? the type of value is not length-restricted
+? the declared number of elements of value leads to an overflow
+
+NOTE: The possibility of integer overflow may make TTCN-3 code using this predefined function not portable between TTCN-3 environments having different integer ranges.
+?
+C.33 Character string to float
+?
+The following error cases will lead to an error at compile or runtime:
+? value is unitialized
+? the format of value is different than defined above in this clause
+? the resulting float value leads to an overflow
+
+NOTE: The possibility of float overflow may make TTCN-3 code using this predefined function not portable between TTCN-3 environments having different float ranges.
+?
+C.34 The Decompose function
+?
+The following error cases will lead to an error at compile or runtime:
+? invalue, index, or count is unitialized
+? invalue is not of base type objid
+? index or count is not of base type integer
+? index is less than zero or greater than the number of components in value minus 1
+? count is less than zero or greater than the number of components in value minus 1
+? index+count is greater than the number of components in value minus 1
+
+NOTE: As TTCN-3 environments may support different integer ranges there is the possibility that TTCN-3 code using this predefined function is not portable.
+
TagsNo tags attached.
Relationships
related to 0004848closed Ina Schieferdecker No record of, set of and arrays are supported by sizeof 
Attached Filesdoc CR383_Part-7part_R2.doc (196,096) 19-10-2007 13:03
http://oldforge.etsi.org/mantis/file_download.php?file_id=1061&type=bug
doc CR383_notesFromGyorgy.doc (20,480) 19-10-2007 13:08
http://oldforge.etsi.org/mantis/file_download.php?file_id=1062&type=bug
zip STF_Solution_CR_383_424_1451_2137_2141_2142.zip (878,886) 19-10-2007 13:08
http://oldforge.etsi.org/mantis/file_download.php?file_id=1063&type=bug
zip STF_Solution_CR_383_424_1451_2137_2139_2141_2142_TD_a.zip (912,036) 04-12-2007 11:55
http://oldforge.etsi.org/mantis/file_download.php?file_id=1186&type=bug
zip CR_lengthof_sizeof_objid_part7.zip (107,019) 04-12-2007 11:55
http://oldforge.etsi.org/mantis/file_download.php?file_id=1187&type=bug
zip STF_Solution_CR_383_424_1451_2137_2139_2141_2142_TD_v3.zip (896,230) 06-12-2007 16:10
http://oldforge.etsi.org/mantis/file_download.php?file_id=1240&type=bug
Issue History
Date ModifiedUsernameFieldChange
23-11-2006 14:16Stephan SchulzNew Issue
23-11-2006 14:16Stephan SchulzClause Reference(s) => Main Document: C.1 to C.34 (mockup v2)
23-11-2006 14:16Stephan SchulzSource (company - Author) => Ina Schieferdecker, FOKUS
15-06-2007 19:20Stephan SchulzStatusnew => assigned
15-06-2007 19:20Stephan SchulzAssigned To => Ina Schieferdecker
13-10-2007 19:09Ina SchieferdeckerAssigned ToIna Schieferdecker => Gyorgy Rethy
18-10-2007 14:30Ina SchieferdeckerTarget Version => Edition 3.3.1 (not yet published)
18-10-2007 14:30Ina SchieferdeckerAdditional Information Updated
18-10-2007 18:33Gyorgy RethyFile Added: CR383_Part-7part.doc
19-10-2007 10:15Gyorgy RethyFile Added: CR383_Part-7part_R1.doc
19-10-2007 10:16Gyorgy RethyFile Deleted: CR383_Part-7part.doc
19-10-2007 10:24Gyorgy RethyFile Added: CR383_additional notes.doc
19-10-2007 13:03Gyorgy RethyFile Added: CR383_Part-7part_R2.doc
19-10-2007 13:06Gyorgy RethyFile Deleted: CR383_additional notes.doc
19-10-2007 13:06Gyorgy RethyFile Deleted: CR383_Part-7part_R1.doc
19-10-2007 13:08Gyorgy RethyFile Added: CR383_notesFromGyorgy.doc
19-10-2007 13:08Gyorgy RethyFile Added: STF_Solution_CR_383_424_1451_2137_2141_2142.zip
19-10-2007 13:11Gyorgy RethyResolutionopen => fixed
31-10-2007 16:11Thomas DeißFile Added: STF_Solution_CR_383_424_1451_2137_2141_2142_TD.zip
19-11-2007 10:51Thomas DeißFile Added: STF_Solution_CR_383_424_1451_2137_2139_2141_2142_TD.zip
19-11-2007 10:51Thomas DeißFile Deleted: STF_Solution_CR_383_424_1451_2137_2141_2142_TD.zip
19-11-2007 10:51Thomas DeißNote Added: 0003996
03-12-2007 14:22Jens GrabowskiAssigned ToGyorgy Rethy => Thomas Deiß
03-12-2007 14:22Jens GrabowskiNote Added: 0004233
04-12-2007 11:21Thomas DeißNote Added: 0004256
04-12-2007 11:22Thomas DeißNote Added: 0004257
04-12-2007 11:55Thomas DeißFile Added: STF_Solution_CR_383_424_1451_2137_2139_2141_2142_TD_a.zip
04-12-2007 11:55Thomas DeißFile Deleted: STF_Solution_CR_383_424_1451_2137_2139_2141_2142_TD.zip
04-12-2007 11:55Thomas DeißFile Added: CR_lengthof_sizeof_objid_part7.zip
04-12-2007 11:56Thomas DeißAssigned ToThomas Deiß => Gyorgy Rethy
06-12-2007 16:01Gyorgy RethyNote Added: 0004387
06-12-2007 16:03Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
06-12-2007 16:03Gyorgy RethyStatusassigned => resolved
06-12-2007 16:06Gyorgy RethyStatusresolved => feedback
06-12-2007 16:06Gyorgy RethyResolutionfixed => reopened
06-12-2007 16:06Gyorgy RethyNote Added: 0004388
06-12-2007 16:10Gyorgy RethyFile Added: STF_Solution_CR_383_424_1451_2137_2139_2141_2142_TD_v3.zip
06-12-2007 16:11Gyorgy RethyStatusfeedback => resolved
06-12-2007 18:00Ina SchieferdeckerStatusresolved => closed
06-12-2007 18:00Ina SchieferdeckerNote Added: 0004402
06-12-2007 18:00Ina SchieferdeckerResolutionreopened => fixed
06-12-2007 18:00Ina SchieferdeckerFixed in Version => Edition 3.3.1 (not yet published)
12-03-2008 10:22user10Fixed in VersionEdition 3.3.1 --will not be published, see 3.3.2 => Edition 3.3.2 (not yet published)
12-03-2008 10:24user10Target VersionEdition 3.3.1 --will not be published, see 3.3.2 => Edition 3.3.2 (not yet published)
13-02-2009 10:14Ina SchieferdeckerRelationship addedrelated to 0004848
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0003996) +
+ Thomas Deiß    +
+ 19-11-2007 10:51    +
+ 		+ + + + +
+ Resolution of CR2139 added.
+
+
+
+ + + + + + + + + + +
+ (0004233) +
+ Jens Grabowski    +
+ 03-12-2007 14:22    +
+ 		+ + + + +
+ Györgys resolutions to be checked by Thomas.
+
+
+
+ + + + + + + + + + +
+ (0004256) +
+ Thomas Deiß    +
+ 04-12-2007 11:21    +
+ 		+ + + + +
+ Solutions for CR 383, 1451, and 2137 checked.
+
+Where possible, corrections are made to file
+STF_Solution_CR_383_424_1451_2137_2139_2141_2142_TD_a.zip
+
+C.25: one error cause missing (str2int("1-1")) (corrected)
+C.29: sizeof should not be applied to objid, lengthof should be used (corrected)
+C.31, C.32: keywords in examples changed to boldface
+C.34: substr function: Templates with ? and * are allowed for string types only. Text extended and error cause added.
+
+C.33 (regexp) not yet handled!!!!!
+
+New open issue: shall str2float be extended to convert 'integer' strings, too? str2float("1") -> 1.0;
+
+
+
+ + + + + + + + + + +
+ (0004257) +
+ Thomas Deiß    +
+ 04-12-2007 11:22    +
+ 		+ + + + +
+ Reminder to cover also lengthof/sizeof and decompose/substr for objid
+
+
+
+ + + + + + + + + + +
+ (0004387) +
+ Gyorgy Rethy    +
+ 06-12-2007 16:01    +
+ 		+ + + + +
+ Thomas's comments are checked and accepted. In addition, substr handling binary string templates and record/set of templates has been clarified (only ? is allowed and the substring to be returned shall not contain matching). Also new issue on str2float is resolved
+
+
+
+ + + + + + + + + + +
+ (0004388) +
+ Gyorgy Rethy    +
+ 06-12-2007 16:06    +
+ 		+ + + + +
+ For some reason file uploaded is not appeared
+
+
+
+ + + + + + + + + + +
+ (0004402) +
+ Ina Schieferdecker    +
+ 06-12-2007 18:00    +
+ 		+ + + + +
+ Some typos fixed along the inclusion.
+
+lists now used instead of sequences
+
+"String operator" section renamed to "List operator"
+
+ + diff --git a/docs/mantis/CR0384.md b/docs/mantis/CR0384.md new file mode 100644 index 0000000000000000000000000000000000000000..373195edfddc32967f7f32adaf9822ab1ac2b740 --- /dev/null +++ b/docs/mantis/CR0384.md @@ -0,0 +1,71 @@ + + + + + + + + + + + + + 0000384: Replacing static semantics in the bnf - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0000384Part 01: TTCN-3 Core LanguageEditorialpublic23-11-2006 14:1812-12-2008 11:47
ReporterStephan Schulz 
Assigned ToIna Schieferdecker 
PriorityhighSeveritytextReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv3.3.2 (published 2008-04)Fixed in Versionv3.3.2 (published 2008-04) 
Clause Reference(s)Annex A
Source (company - Author)dr. György Réthy, Ericsson
Summary0000384: Replacing static semantics in the bnf
DescriptionCurrently numerous static semantic rules applied to different bnf productions. Some of them just repeat requirements in the textual part (e.g. static semantics to the production ValueOrRange), others put extra requirements not contained in the textual part (e.g. static semantics to the production PortElement) and in other cases rules contradict to requirements in the textual part (e.g. static semantics to the production SingleConsDef).
Steps To Reproduce
Additional Information1. All semantic rules shall have a single source in the standard. This source shall be the textual part only.
+
+Replace all static semantics in the bnf with a reference to the relevant clause in the text:
+- simply replace static semantic rules repeating requirements in the text with a reference(s) to the relevant clause(s)
+- in case of static semantic rules that add new requirements to the text, move the requirements to the relevant clause(s) and replace rules with relevant reference(s)
+- in case of static semantic rules that contradict to the requirements in the text, resolve contradiction, modify text if necessary and replace the rule with a reference to the relevant clause(s)
+
+2. As the standard also published in word format, the bnf and references to semantic rules could also contain hyperlinks to provide higher convenience for the user.
+
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
23-11-2006 14:18Stephan SchulzNew Issue
23-11-2006 14:18Stephan SchulzClause Reference(s) => Annex A
23-11-2006 14:18Stephan SchulzSource (company - Author) => dr. György Réthy, Ericsson
15-06-2007 19:20Stephan SchulzStatusnew => assigned
15-06-2007 19:20Stephan SchulzAssigned To => Ina Schieferdecker
13-10-2007 19:11Ina SchieferdeckerStatusassigned => resolved
13-10-2007 19:11Ina SchieferdeckerResolutionopen => fixed
13-10-2007 19:11Ina SchieferdeckerNote Added: 0003593
15-10-2007 15:07Ina SchieferdeckerStatusresolved => closed
12-12-2008 11:47Ina SchieferdeckerFixed in Version => Edition 3.3.2
12-12-2008 11:47Ina SchieferdeckerTarget Version => Edition 3.3.2
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0003593) +
+ Ina Schieferdecker    +
+ 13-10-2007 19:11    +
+ 		+ + + + +
+ This change has been done in v3.2.1 although not all static semantics could be removed from the BNF: in particular for expressions, the BNF is the only place where the details are given to define the static semantics meaningfully.
+
+ + diff --git a/docs/mantis/CR0385.md b/docs/mantis/CR0385.md new file mode 100644 index 0000000000000000000000000000000000000000..7038af389881cefe80b57a348c7cc79e0353a2ae --- /dev/null +++ b/docs/mantis/CR0385.md @@ -0,0 +1,100 @@ + + + + + + + + + + + + + 0000385: Special types not defined - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0000385Part 01: TTCN-3 Core LanguageTechnicalpublic23-11-2006 14:2212-03-2008 10:24
ReporterStephan Schulz 
Assigned ToIna Schieferdecker 
PriorityhighSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv3.3.2 (published 2008-04)Fixed in Versionv3.3.2 (published 2008-04) 
Clause Reference(s)$6, $9, $21
Source (company - Author)dr. György Réthy, Ericsson
Summary0000385: Special types not defined
DescriptionSpecial configuration types and the default are just mentioned but not specified in $6. While the nature of port, component and default types can be made out from other parts of the standard, there are several ambiguities regarding the address type.
+Is it a user-defined type with a pre-determined name or a built-in type with user-defined value structure? The only clause describing address ($8.6) is contradictory in theis respect: ?address is resolved either by an explicit type definition within the test suite? - so it is importable; ?Explicit SUT addresses shall only be generated inside a TTCN-3 module if the type is defined inside the module.? ? a built-in-like behaviour, though the bnf allows aliasing and hence importing. ?If the type is not defined inside the module, explicit SUT addresses shall only be passed in as parameters or be received in message fields or as parameters of remote procedure calls.).? ? as parameters to templates?
+In the former case the address type is importable (directly with the name ?address? and any name alias) while in the second case only name aliases are importable but not the address type definition itself. In both cases several address types may exist in a test suite (in some cases shall exist to be able to address different entities).
+In a port type definition all message types and procedure signatures shall be listed but the allowed address types are not mentioned.
+
Steps To Reproduce
Additional InformationAdd the new clause below:
+?6.8 Special configuration types and the default type
+6.8.1 The address type
+The address type is a special user defined type for use with port operations to address SUT entities. The actual data representation of address is resolved either by an explicit type definition within the test suite or externally by the test system (i.e. the address type is left as an open type within the TTCN-3 specification). This allows abstract test cases to be specified independently of any real address mechanism specific to the SUT. In addition, the special value null is available to indicate an undefined address, e.g. for the initialization of variables of the address type.
+EXAMPLE:
+    // Associates the type integer to the open type address
+    type integer address;
+     :
+    // new address variable initialized with null
+    var address MySUTentity := null;
+     :
+
+6.8.2 Port type
+<to be completed>
+6.8.3 Component type
+<to be completed>
+6.8.4 The default type
+<to be completed>
+
+8.6 Addressing entities inside the SUT
+An SUT may consist of several entities which have to be addressed individually. When used with to, from and sender the address data type shall only be used in receive and send operations of ports mapped to test system interface.
+Explicit SUT addresses shall only be generated inside a TTCN-3 module if the type is defined inside the module. If the type is not defined inside the module, explicit SUT addresses shall only be passed in as parameters or be received in message fields or as parameters of remote procedure calls.
+
+EXAMPLE:
+    // receiving an address value and assigning it to variable MySUTentity
+    PCO.receive(address:*) -> value MySUTentity;
+     :
+    // usage of the received address for sending template MyResult
+    PCO.send(MyResult) to MySUTentity;
+     :
+    // usage of the received address for receiving a confirmation template
+    PCO.receive(MyConfirmation) from MySUTentity;
+
+
TagsNo tags attached.
Relationships
Attached Filesdoc CR_385.doc (1,916,416) 25-10-2007 09:50
http://oldforge.etsi.org/mantis/file_download.php?file_id=1072&type=bug
Issue History
Date ModifiedUsernameFieldChange
23-11-2006 14:22Stephan SchulzNew Issue
23-11-2006 14:22Stephan SchulzClause Reference(s) => $6
23-11-2006 14:22Stephan SchulzSource (company - Author) => dr. György Réthy, Ericsson
23-11-2006 14:23Stephan SchulzStatusnew => assigned
23-11-2006 14:23Stephan SchulzAssigned To => Jens Grabowski
15-10-2007 16:49Ina SchieferdeckerAssigned ToJens Grabowski => developer_u
17-10-2007 12:41user10Assigned Todeveloper_u => Thomas Deiß
18-10-2007 12:15Ina SchieferdeckerTarget Version => Edition 3.3.1 (not yet published)
18-10-2007 12:15Ina SchieferdeckerDescription Updated
18-10-2007 12:15Ina SchieferdeckerAdditional Information Updated
25-10-2007 09:50Thomas DeißFile Added: CR_385.doc
25-10-2007 09:53Thomas DeißClause Reference(s)$6 => $6, $9, $21
25-10-2007 09:53Thomas DeißNote Added: 0003792
25-10-2007 09:53Thomas DeißAssigned ToThomas Deiß => Gyorgy Rethy
25-10-2007 09:53Thomas DeißResolutionopen => fixed
05-12-2007 15:37Ina SchieferdeckerAssigned ToGyorgy Rethy => Ina Schieferdecker
05-12-2007 15:37Ina SchieferdeckerStatusassigned => resolved
05-12-2007 18:15Ina SchieferdeckerStatusresolved => closed
05-12-2007 18:15Ina SchieferdeckerFixed in Version => Edition 3.3.1 (not yet published)
12-03-2008 10:22user10Fixed in VersionEdition 3.3.1 --will not be published, see 3.3.2 => Edition 3.3.2 (not yet published)
12-03-2008 10:24user10Target VersionEdition 3.3.1 --will not be published, see 3.3.2 => Edition 3.3.2 (not yet published)
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0003792) +
+ Thomas Deiß    +
+ 25-10-2007 09:53    +
+ 		+ + + + +
+ Text on type definition moved to clause 6 (from clauses 9 and 21). Remaining text in clause 9 polished a little bit. No further changes made. Especially, the restrictions on connections (clause 9: structural restrictions, clause 21: compatibility of port types) have not been merged.
+
+ + diff --git a/docs/mantis/CR0386.md b/docs/mantis/CR0386.md new file mode 100644 index 0000000000000000000000000000000000000000..59e9ba0fbca5b3172816e4f8044f8fcc3aa84151 --- /dev/null +++ b/docs/mantis/CR0386.md @@ -0,0 +1,428 @@ + + + + + + + + + + + + + 0000386: isbound() function - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0000386Part 01: TTCN-3 Core LanguageNew Featurepublic23-11-2006 14:2412-03-2008 10:24
ReporterStephan Schulz 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityfeatureReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv3.3.2 (published 2008-04)Fixed in Versionv3.3.2 (published 2008-04) 
Clause Reference(s)-
Source (company - Author)Csaba Koppany, Ericsson
Summary0000386: isbound() function
DescriptionIn many cases the declared variables are not initialized. Sometimes that is happen by mistake, or in same cases as a result of a decision. Normally it causing an error if an un-initialized variable is used. There is no mechanism in TTCN-3 to check if a variable has a value or it is unbound.
Steps To Reproduce
Additional InformationAdd a new predefine function:
+C.XX The IsBound function
+isbound (in any_type invalue) return boolean
+This function returns the value true if and only if the referenced variable or field of a variable has a value assigned. The value false is returned if the referenced variable or field of a variable is un-initialized. The argument of isbound shall be a variable, or field of a variable.
+
+EXAMPLE:
+var charstring v_myString := �Hello�;
+:
+if (isbound(v_myString))
+  {
+  log(v_myString)
+  }
+else
+  {
+  log(�Don�t know!�)
+  };
+
+
TagsNo tags attached.
Relationships
Attached Filesdoc STF_solution_CR386R3.doc (324,608) 19-10-2007 12:54
http://oldforge.etsi.org/mantis/file_download.php?file_id=1060&type=bug
doc STF_solution_CR386R4.doc (325,120) 05-12-2007 15:45
http://oldforge.etsi.org/mantis/file_download.php?file_id=1220&type=bug
doc STF_solution_CR386R5.doc (324,096) 05-12-2007 16:56
http://oldforge.etsi.org/mantis/file_download.php?file_id=1222&type=bug
doc STF_solution_CR386R6.doc (317,440) 05-12-2007 18:12
http://oldforge.etsi.org/mantis/file_download.php?file_id=1223&type=bug
doc STF_solution_CR386R7.doc (323,072) 06-12-2007 09:41
http://oldforge.etsi.org/mantis/file_download.php?file_id=1229&type=bug
doc STF_solution_CR386R8_JG_071206.doc (329,728) 06-12-2007 15:49
http://oldforge.etsi.org/mantis/file_download.php?file_id=1239&type=bug
doc STF_solution_CR386R8_JG_071206_a.doc (342,528) 06-12-2007 17:32
http://oldforge.etsi.org/mantis/file_download.php?file_id=1244&type=bug
doc STF_solution_CR386R9.doc (344,064) 06-12-2007 18:16
http://oldforge.etsi.org/mantis/file_download.php?file_id=1246&type=bug
doc STF_solution_CR386R10.doc (345,088) 07-12-2007 09:00
http://oldforge.etsi.org/mantis/file_download.php?file_id=1248&type=bug
Issue History
Date ModifiedUsernameFieldChange
23-11-2006 14:24Stephan SchulzNew Issue
23-11-2006 14:24Stephan SchulzClause Reference(s) => -
23-11-2006 14:24Stephan SchulzSource (company - Author) => Csaba Koppany, Ericsson
15-06-2007 19:19Stephan SchulzStatusnew => assigned
15-06-2007 19:19Stephan SchulzAssigned To => Ina Schieferdecker
13-10-2007 19:12Ina SchieferdeckerAssigned ToIna Schieferdecker => Gyorgy Rethy
17-10-2007 16:20Ina SchieferdeckerNote Added: 0003673
18-10-2007 11:33Ina SchieferdeckerTarget Version => Edition 3.3.1 (not yet published)
18-10-2007 11:33Ina SchieferdeckerAdditional Information Updated
18-10-2007 14:20Gyorgy RethyFile Added: STF_solution_CR386.doc
18-10-2007 14:53Gyorgy RethyFile Deleted: STF_solution_CR386.doc
18-10-2007 14:55Gyorgy RethyFile Added: STF_solution_CR386.doc
18-10-2007 15:44Gyorgy RethyFile Added: STF_solution_CR386R1.doc
18-10-2007 19:30Gyorgy RethyFile Deleted: STF_solution_CR386.doc
19-10-2007 09:58Gyorgy RethyFile Added: STF_solution_CR386R2.doc
19-10-2007 09:58Gyorgy RethyFile Deleted: STF_solution_CR386R1.doc
19-10-2007 12:54Gyorgy RethyFile Added: STF_solution_CR386R3.doc
19-10-2007 12:55Gyorgy RethyFile Deleted: STF_solution_CR386R2.doc
19-10-2007 13:15Gyorgy RethyResolutionopen => fixed
03-12-2007 14:28Jens GrabowskiAssigned ToGyorgy Rethy => Thomas Deiß
04-12-2007 18:05Thomas DeißAssigned ToThomas Deiß => Gyorgy Rethy
05-12-2007 11:21Jens GrabowskiNote Added: 0004330
05-12-2007 15:45Gyorgy RethyFile Added: STF_solution_CR386R4.doc
05-12-2007 15:48Gyorgy RethyNote Added: 0004338
05-12-2007 15:52Gyorgy RethyAssigned ToGyorgy Rethy => Thomas Deiß
05-12-2007 16:56Gyorgy RethyFile Added: STF_solution_CR386R5.doc
05-12-2007 16:58Gyorgy RethyNote Added: 0004347
05-12-2007 17:00Gyorgy RethyNote Edited: 0004347
05-12-2007 18:12Thomas DeißFile Added: STF_solution_CR386R6.doc
05-12-2007 18:14Thomas DeißNote Added: 0004353
05-12-2007 18:14Thomas DeißAssigned ToThomas Deiß => Ina Schieferdecker
05-12-2007 18:14Thomas DeißStatusassigned => resolved
06-12-2007 09:22Ina SchieferdeckerAssigned ToIna Schieferdecker => Gyorgy Rethy
06-12-2007 09:22Ina SchieferdeckerStatusresolved => feedback
06-12-2007 09:22Ina SchieferdeckerResolutionfixed => reopened
06-12-2007 09:22Ina SchieferdeckerNote Added: 0004358
06-12-2007 09:41Ina SchieferdeckerFile Added: STF_solution_CR386R7.doc
06-12-2007 09:42Ina SchieferdeckerAssigned ToGyorgy Rethy => Jens Grabowski
06-12-2007 09:42Ina SchieferdeckerStatusfeedback => assigned
06-12-2007 15:49Jens GrabowskiFile Added: STF_solution_CR386R8_JG_071206.doc
06-12-2007 15:51Jens GrabowskiNote Added: 0004383
06-12-2007 15:52Jens GrabowskiAssigned ToJens Grabowski => Thomas Deiß
06-12-2007 17:32Thomas DeißFile Added: STF_solution_CR386R8_JG_071206_a.doc
06-12-2007 17:33Thomas DeißNote Added: 0004399
06-12-2007 17:34Thomas DeißAssigned ToThomas Deiß => Gyorgy Rethy
06-12-2007 18:16Gyorgy RethyFile Added: STF_solution_CR386R9.doc
06-12-2007 18:17Gyorgy RethyNote Added: 0004404
06-12-2007 18:19Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
06-12-2007 18:19Gyorgy RethyStatusassigned => resolved
07-12-2007 08:59Ina SchieferdeckerStatusresolved => feedback
07-12-2007 08:59Ina SchieferdeckerNote Added: 0004409
07-12-2007 09:00Ina SchieferdeckerFile Added: STF_solution_CR386R10.doc
07-12-2007 09:00Ina SchieferdeckerStatusfeedback => resolved
07-12-2007 09:00Ina SchieferdeckerResolutionreopened => fixed
07-12-2007 09:21Ina SchieferdeckerStatusresolved => closed
07-12-2007 09:21Ina SchieferdeckerNote Added: 0004411
07-12-2007 09:21Ina SchieferdeckerFixed in Version => Edition 3.3.1 (not yet published)
12-03-2008 10:22user10Fixed in VersionEdition 3.3.1 --will not be published, see 3.3.2 => Edition 3.3.2 (not yet published)
12-03-2008 10:24user10Target VersionEdition 3.3.1 --will not be published, see 3.3.2 => Edition 3.3.2 (not yet published)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0003673) +
+ Ina Schieferdecker    +
+ 17-10-2007 16:20    +
+ 		+ + + + +
+ to be extended for templates, define the meaning of "uninitialized"
+
+
+
+ + + + + + + + + + +
+ (0004330) +
+ Jens Grabowski    +
+ 05-12-2007 11:21    +
+ 		+ + + + +
+ A new CR will be written by Ina about the usage of uninitialized values.
+
+
+
+ + + + + + + + + + +
+ (0004338) +
+ Gyorgy Rethy    +
+ 05-12-2007 15:48    +
+ 		+ + + + +
+ text revised, isbound allows templates; no words "initialized", uninitialized" is used ny more in the description just in the examples.
+
+
+
+ + + + + + + + + + +
+ (0004347) +
+ Gyorgy Rethy    +
+ 05-12-2007 16:58    +
(edited on: 05-12-2007 17:00)
+ 		+ + + + +
+ In STF_solution_CR386R5: Thomas's comments reviewed but not all accepted. definitio of initialized reviewed and a new definition "completely initialized" is added. Descriptions of valueof and isbound are simplified by using the term completely initialized.
+
+
+
+
+
+ + + + + + + + + + +
+ (0004353) +
+ Thomas Deiß    +
+ 05-12-2007 18:14    +
+ 		+ + + + +
+ agreed with Gyorgy to change 'specific value' to 'concrete value'. The other changes (compared to version R5 of the solution) also agreed with Gyorgy.
+
+
+
+ + + + + + + + + + +
+ (0004358) +
+ Ina Schieferdecker    +
+ 06-12-2007 09:22    +
+ 		+ + + + +
+ The restriction in clause 7 is too strict - there are usages of partially initialized values e.g. in assignments to variables of record of types.
+
+Therefore, weakening this restriction is proposed for clause 7 - and the more strict restriction is required for operators only.
+
+It needs though to be checked if now all cases are handled properly.
+
+
+
+ + + + + + + + + + +
+ (0004383) +
+ Jens Grabowski    +
+ 06-12-2007 15:51    +
+ 		+ + + + +
+ Please check the text! If ok, close the CR and assign it to Ina for inclusion into the text.
+
+
+
+ + + + + + + + + + +
+ (0004399) +
+ Thomas Deiß    +
+ 06-12-2007 17:33    +
+ 		+ + + + +
+ examples corrected
+examples suitable for isbound, but not suitable isvalue removed.
+Corrected that omit is used for elements.
+
+
+
+ + + + + + + + + + +
+ (0004404) +
+ Gyorgy Rethy    +
+ 06-12-2007 18:17    +
+ 		+ + + + +
+ Editorials and changing in expressions: shall be al least partially initialized; deleting no matching expressions from valueof restrictions (specific values are also defined as matching mechanism)
+
+
+
+ + + + + + + + + + +
+ (0004409) +
+ Ina Schieferdecker    +
+ 07-12-2007 08:59    +
+ 		+ + + + +
+ "shall be" instead of "may be" in clause 7.
+
+
+
+ + + + + + + + + + +
+ (0004411) +
+ Ina Schieferdecker    +
+ 07-12-2007 09:21    +
+ 		+ + + + +
+ Some wording improved.
+
+ + diff --git a/docs/mantis/CR0387.md b/docs/mantis/CR0387.md new file mode 100644 index 0000000000000000000000000000000000000000..275d5f6294596859b8be2691d84d8190bee924ed --- /dev/null +++ b/docs/mantis/CR0387.md @@ -0,0 +1,214 @@ + + + + + + + + + + + + + 0000387: Time-constraint send operation - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0000387Part 01: TTCN-3 Core LanguageEditorialpublic23-11-2006 14:2712-03-2008 10:27
ReporterStephan Schulz 
Assigned Todeveloper_u 
PrioritynormalSeverityfeatureReproducibilityN/A
StatusclosedResolutionwon't fix 
PlatformOSOS Version
Product Version 
Target Versionv3.3.2 (published 2008-04)Fixed in Versionv3.3.2 (published 2008-04) 
Clause Reference(s)Clause 23.2 (in 1); clause 9 (in 4)
Source (company - Author)Andreas Ulrich, Siemens AG
Summary0000387: Time-constraint send operation
DescriptionIn order to simplify the specification of a send operation followed by a time-constraint receipt operation similar to a blocking procedure-based call operation, an extension of the current send operation is proposed.
Steps To Reproduce
Additional Information23.2.4 Time-constraint send operation
+
+The send operation can be extended with a list of receive operations that are expected to occur after the message was sent to the SUT. The receive operations are guarded by an implicit timer, whose optional timeout value is set at the send operation. The syntax is similar to the call operation in procedure-based communication (see Clause 23.3.1.1). The time-constraint send operation is blocked until a matching receive message is received or the timer timed out.
+
+EXAMPLE:
+
+// The following expression?
+p.send(ReqMsgTemplate, 0.5) { // send a request message and wait at most 0.5 sec
+  [] p.receive(AckMsgTemplate) { // acknowledgement message received within time
+      setverdict(pass);
+     }
+  [] p.receive(NackMsgTemplate) { // or negative acknowledgement received
+      setverdict(fail);
+     }
+  [] p.catch(timeout) { // or no response received after 0.5 sec
+      setverdict(inconc);
+     }
+}
+// ?is a short form of
+timer t := 0.5;
+p.send(ReqMsgTemplate);
+t.start;
+alt {
+[] p.receive(AckMsgTemplate) {
+     t.stop; setverdict(pass);
+   }
+[] p.receive(NackMsgTemplate) {
+     t.stop; setverdict(fail);
+   }
+[] t.timeout { setverdict(inconc); }
+}
+
+The time-constraint send operation can be always resolved to a simple send operation followed by explicit timer operations and an alt expression that contains the list of possible receive operations. In particular, an activated default remains enabled when the list of alternative receipts is executed. (Note the difference to the blocking call operation with optional call body, clause 23.3.1.1).
+
+The receive operations allowed in a time-constraint send operation shall be restricted to receive, trigger, check, and catch(timeout). It is possible to perform receive operations on ports different to the port used for the send operation. The timeout catch expression shall refer to the same port as used for the send operation though. If it is desired to receive several messages that are all guarded by a single timer, then the simple send operation without the time-constraint and appropriate alt and/or interleave and timer expressions shall be used.
+
+If necessary, it is possible to enable/disable an alternative by means of a boolean expression placed between the '[ ]' brackets of the alternative. In order to avoid unexpected side effects, the same rules as for the Boolean guards in alt statements shall be applied (see clause 20.1.1).
+
+
+
+A.1.6.2.4 Port operations
+
+320. PortSendOp ::= SendOpKeyword "(" SendParameter ["," SendTimerValue] ")" [ToClause]
+                                                                         [PortSendBody]
+/* STATIC SEMANTICS PortSendBody shall be present only if SendTimerValue is used */
+xxx. SendTimerValue := TimerValue
+xxx. PortSendBody := BeginChar SendBodyStatementList EndChar
+xxx. SendBodyStatementList ::= {SendBodyStatement [SemiColon]}+
+xxx. SendBodyStatement ::= SendBodyGuard StatementBlock
+xxx. SendBodyGuard ::= AltGuardChar SendBodyOps
+xxx. SendBodyOps ::= ReceiveStatement | TriggerStatement | CheckStatement | CatchTimeoutStatement
+xxx. CatchTimeoutStatement ::= Port Dot PortTimeoutOp
+xxx. PortTimeoutOp ::= CatchOpKeyword "(" TimeoutKeyword ")"
+
+
+
+in part 4: Operational semantics?
+9.7 Replacement of time-constraint send operations
+
+The time-constraint send operation is a short form of a simple send operation followed by an alt expression that contains the alternative receive operations plus appropriate timer operations. The replacement shall be made at the syntactical level. The receive operations allowed in a time-constraint send operation shall be restricted to receive, trigger, check, and catch(timeout).
+
+EXAMPLE:
+
+// The time-constraint send operation?
+p.send(ReqMsgTemplate, TimeoutValue) {
+  [] p.receive(AckMsgTemplate) { ? }
+  [] ?
+  [] p.catch(timeout) { ? }
+}
+
+// ?shall be replaced by
+timer implicit_timer;
+:
+p.send(ReqMsgTemplate);
+implicit_timer.start(TimeoutValue);
+alt {
+ [] p.receive(AckMsgTemplate) { implicit_timer.stop; ? }
+ [] ?
+ [] implicit_timer.timeout { ? }
+}
+
+
+
+
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
23-11-2006 14:27Stephan SchulzNew Issue
23-11-2006 14:27Stephan SchulzClause Reference(s) => Clause 23.2 (in 1); clause 9 (in 4)
23-11-2006 14:27Stephan SchulzSource (company - Author) => Andreas Ulrich, Siemens AG
23-11-2006 14:28Stephan SchulzNote Added: 0000308
23-11-2006 14:28Stephan SchulzStatusnew => confirmed
15-06-2007 19:19Stephan SchulzStatusconfirmed => assigned
15-06-2007 19:19Stephan SchulzAssigned To => Ina Schieferdecker
13-10-2007 19:13Ina SchieferdeckerAssigned ToIna Schieferdecker => developer_u
15-10-2007 14:40Ina SchieferdeckerNote Added: 0003615
17-10-2007 12:12Ina SchieferdeckerStatusassigned => closed
17-10-2007 12:12Ina SchieferdeckerNote Added: 0003662
17-10-2007 12:12Ina SchieferdeckerResolutionopen => fixed
18-10-2007 13:51Ina SchieferdeckerStatusclosed => feedback
18-10-2007 13:51Ina SchieferdeckerResolutionfixed => reopened
18-10-2007 13:52Ina SchieferdeckerStatusfeedback => closed
18-10-2007 13:52Ina SchieferdeckerResolutionreopened => won't fix
18-10-2007 13:52Ina SchieferdeckerTarget Version => Edition 3.3.1 (not yet published)
18-10-2007 13:52Ina SchieferdeckerAdditional Information Updated
12-03-2008 10:27user10Fixed in Version => Edition 3.3.2 (not yet published)
12-03-2008 10:27user10Target VersionEdition 3.3.1 --will not be published, see 3.3.2 => Edition 3.3.2 (not yet published)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0000308) +
+ Stephan Schulz    +
+ 23-11-2006 14:28    +
+ 		+ + + + +
+ Agreed in principle
+
+
+
+ + + + + + + + + + +
+ (0003615) +
+ Ina Schieferdecker    +
+ 15-10-2007 14:40    +
+ 		+ + + + +
+ Should be considered also for raise and reply.
+
+
+
+ + + + + + + + + + +
+ (0003662) +
+ Ina Schieferdecker    +
+ 17-10-2007 12:12    +
+ 		+ + + + +
+ A timed send, timed raise and timed reply are syntactic sugar which do not add much ... more arguments will be provided by Thomas.
+
+ + diff --git a/docs/mantis/CR0388.md b/docs/mantis/CR0388.md new file mode 100644 index 0000000000000000000000000000000000000000..a412c01a3d4d143e0d649612876de6ab4faab8ff --- /dev/null +++ b/docs/mantis/CR0388.md @@ -0,0 +1,63 @@ + + + + + + + + + + + + + 0000388: Address not considered in operational semantics - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 04: TTCN-3 Operational Semantics
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0000388Part 04: TTCN-3 Operational SemanticsTechnicalpublic23-11-2006 14:3005-01-2008 12:30
ReporterStephan Schulz 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv2.2.1 (published 2003-02) 
Target Versionv3.3.1 (published 2008-04)Fixed in Versionv3.3.1 (published 2008-04) 
Clause Reference(s)-
Source (company - Author) dr. György Réthy, Ericsson
Summary0000388: Address not considered in operational semantics
DescriptionIn communication operations two addressing mechanisms complement each other: component reference in internal ports and address value at a mapped port. From the point of view of the operational semantics communication on a connect-ed and on a mapped port do not really differ: TSI is also like a test component.
Steps To Reproduce
Additional InformationAdd �or address value� after each occurance of �component reference�.
TagsNo tags attached.
Relationships
Attached Fileszip CR-388-418-Operational-Semantics-Resolution.zip (1,298,804) 19-10-2007 10:19
http://oldforge.etsi.org/mantis/file_download.php?file_id=1058&type=bug
Issue History
Date ModifiedUsernameFieldChange
23-11-2006 14:30Stephan SchulzNew Issue
23-11-2006 14:30Stephan SchulzClause Reference(s) => -
23-11-2006 14:30Stephan SchulzSource (company - Author) => dr. György Réthy, Ericsson
15-06-2007 19:19Stephan SchulzStatusnew => assigned
15-06-2007 19:19Stephan SchulzAssigned To => Ina Schieferdecker
13-10-2007 19:14Ina SchieferdeckerAssigned ToIna Schieferdecker => Jens Grabowski
15-10-2007 14:34Ina SchieferdeckerProjectPart 01: TTCN-3 Core Language => Part 04: TTCN-3 Operational Semantics
19-10-2007 10:19Jens GrabowskiResolutionopen => fixed
19-10-2007 10:19Jens GrabowskiAdditional Information Updated
19-10-2007 10:19Jens GrabowskiFile Added: CR-388-418-Operational-Semantics-Resolution.zip
19-10-2007 10:20Jens GrabowskiNote Added: 0003700
20-11-2007 08:08Jens GrabowskiAssigned ToJens Grabowski => Gyorgy Rethy
05-12-2007 15:55Gyorgy RethyAssigned ToGyorgy Rethy => Jens Grabowski
05-12-2007 15:55Gyorgy RethyStatusassigned => resolved
07-12-2007 10:15user10Target Version => Edition 4.1.1 (not yet published)
07-12-2007 10:17user10Target VersionEdition 4.1.1 (not yet published) =>
07-12-2007 10:46Ina SchieferdeckerStatusresolved => feedback
07-12-2007 10:46Ina SchieferdeckerResolutionfixed => reopened
07-12-2007 10:46Ina SchieferdeckerTarget Version => Edition 3.3.1 (not yet published)
07-12-2007 10:46Ina SchieferdeckerStatusfeedback => resolved
07-12-2007 10:46Ina SchieferdeckerResolutionreopened => fixed
05-01-2008 12:30Ina SchieferdeckerStatusresolved => closed
05-01-2008 12:30Ina SchieferdeckerFixed in Version => Edition 3.3.1 (not yet published)
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0003700) +
+ Jens Grabowski    +
+ 19-10-2007 10:20    +
+ 		+ + + + +
+ The file CR-388-418-Operational-Semantics-Resolution.zip has also been uploaded as part of the resolution of CR 418.
+
+ + diff --git a/docs/mantis/CR0389.md b/docs/mantis/CR0389.md new file mode 100644 index 0000000000000000000000000000000000000000..7516cf7e97b1d9a6f2e6542c56fcb67c385778f1 --- /dev/null +++ b/docs/mantis/CR0389.md @@ -0,0 +1,274 @@ + + + + + + + + + + + + + 0000389: allow templates in valuelist templates - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0000389Part 01: TTCN-3 Core LanguageTechnicalpublic23-11-2006 14:3712-03-2008 10:24
ReporterStephan Schulz 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv3.3.2 (published 2008-04)Fixed in Versionv3.3.2 (published 2008-04) 
Clause Reference(s)BNF, B1.2.1, B1.2.2
Source (company - Author)Stephan Tobies, Nokia
Summary0000389: allow templates in valuelist templates
DescriptionThere is a restriction that only constant expressions should be usable in a valuelist template. This is unnecessary and arbitrary templates should be usable.
Steps To Reproduce
Additional InformationB.1.2.1 Value list
+Value lists specify lists of acceptable incoming values. It can be used on values of all types. A template field that uses a value list matches the corresponding incoming field if, and only if, the incoming field value matches any one of the _templates_ in the value list. Each _template_ in the value list shall be of the type declared for the template field in which this mechanism is used.
+EXAMPLE:
+    template Mymessage MyTemplate:=
+    {
+        field1 := (2,4,6), // list of integer values
+        field2 := ("String1", "String2", _? length (20) ),_ // list of charstring values templates
+        :
+        :
+    }
+B.1.2.2 Complemented value list
+The keyword complement denotes a list of _templates_ that _the_ incoming values _shall not match_ (i.e. it is the complement of a value list). It can be used on all values of all types.
+Each _template_ in the list shall be of the type declared for the template field in which the complement is used. A template field that uses complement matches the corresponding incoming field if and only if the incoming field does not match any of the _templates_ listed in the value list. The value list may be a single _template_, of course.
+EXAMPLE:
+    template Mymessage MyTemplate:=
+    {
+            complement (1,3,5), // list of unacceptable integer values
+        :
+        field3 not(true) // will match false
+        <Sto: what is this?>
+        :
+    }
+
+B.1.3.3 Permutation
+Permutation is an operation for matching that shall be used only on values of record of types. Permutation is denoted by the keyword permutation. Permutation in place of a single element means that any series of elements is acceptable provided it __ matches the _template_ list in the permutation, though possibly in a different order. If both permutation and AnyElementsOrNone are used inside a value, the AnyElementsOrNone shall be evaluated first. Each element listed in the permutation shall be of the type declared inside the record of type.
+EXAMPLE:
+    type record of integer MySequenceOfType;
+
+    template MySequenceOfType MyTemplate1 := { permutation ( 1, 2, 3 ), 5 };
+    // any sequence of 4 integers that matches 1,2,3,5; 1,3,2,5; 2,1,3,5; 2,3,1,5; 3,1,2,5; or 3,2,1,5
+
+
+120. Complement ::= ComplementKeyword _ValueOrAttribList_
+xxx. PermutationMatch ::= PermutationKeyword _ValueOrAttribList_
+
TagsNo tags attached.
Relationships
Attached Filesdoc CR_389.doc (440,320) 19-10-2007 13:35
http://oldforge.etsi.org/mantis/file_download.php?file_id=1064&type=bug
Issue History
Date ModifiedUsernameFieldChange
23-11-2006 14:37Stephan SchulzNew Issue
23-11-2006 14:37Stephan SchulzClause Reference(s) => BNF, B1.2.1, B1.2.2
23-11-2006 14:37Stephan SchulzSource (company - Author) => Stephan Tobies, Nokia
24-11-2006 15:04Stephan SchulzNote Added: 0000333
15-06-2007 19:12Stephan SchulzStatusnew => assigned
15-06-2007 19:12Stephan SchulzAssigned To => Ina Schieferdecker
13-10-2007 19:30Ina SchieferdeckerAssigned ToIna Schieferdecker => developer_u
17-10-2007 12:41user10Assigned Todeveloper_u => Thomas Deiß
18-10-2007 12:11Ina SchieferdeckerTarget Version => Edition 3.3.1 (not yet published)
19-10-2007 13:35Thomas DeißFile Added: CR_389.doc
19-10-2007 13:37Thomas DeißNote Added: 0003706
19-10-2007 13:38Thomas DeißResolutionopen => won't fix
19-10-2007 13:39Thomas DeißNote Added: 0003707
19-10-2007 13:39Thomas DeißResolutionwon't fix => fixed
19-10-2007 13:40Thomas DeißAssigned ToThomas Deiß => Jens Grabowski
04-12-2007 13:41Jens GrabowskiAssigned ToJens Grabowski => Thomas Deiß
04-12-2007 16:40Thomas DeißNote Added: 0004284
04-12-2007 18:07Thomas DeißNote Added: 0004302
04-12-2007 18:07Thomas DeißAssigned ToThomas Deiß => Jens Grabowski
04-12-2007 18:30Thomas DeißNote Added: 0004303
04-12-2007 18:30Thomas DeißAssigned ToJens Grabowski => Ina Schieferdecker
04-12-2007 18:30Thomas DeißStatusassigned => resolved
05-12-2007 17:26Ina SchieferdeckerStatusresolved => closed
05-12-2007 17:26Ina SchieferdeckerFixed in Version => Edition 3.3.1 (not yet published)
12-03-2008 10:22user10Fixed in VersionEdition 3.3.1 --will not be published, see 3.3.2 => Edition 3.3.2 (not yet published)
12-03-2008 10:24user10Target VersionEdition 3.3.1 --will not be published, see 3.3.2 => Edition 3.3.2 (not yet published)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0000333) +
+ Stephan Schulz    +
+ 24-11-2006 15:04    +
+ 		+ + + + +
+ Using templates in other matching mechanisms should also be considered
+
+
+
+ + + + + + + + + + +
+ (0003706) +
+ Thomas Deiß    +
+ 19-10-2007 13:37    +
+ 		+ + + + +
+ solution proposed
+
+added to text that templates can be used in value list and complemented value lists.
+
+for subset, superset, permutation: these remain lists of values. no templates to be used.
+The real problem is the subset, which can be operationalized only if the valuelist is finite.
+
+
+
+ + + + + + + + + + +
+ (0003707) +
+ Thomas Deiß    +
+ 19-10-2007 13:39    +
+ 		+ + + + +
+ previous change of resolution was erroneous.
+
+
+
+ + + + + + + + + + +
+ (0004284) +
+ Thomas Deiß    +
+ 04-12-2007 16:40    +
+ 		+ + + + +
+ lists used superset, subset, and permutation shall not contain templates, because for superset and permutation it has to be checked whether all values denoted by the templates occur within the value to be matched. To check whether all valued occur would require to enumerate all values one by one and check them against. Enumerated the values of a give type is considered as too complicated for the tools, therefore no templates are allowed for superset and permutation.
+
+For subset there would actually not be a problem, but the same limitation as for superset was applied.
+
+
+
+ + + + + + + + + + +
+ (0004302) +
+ Thomas Deiß    +
+ 04-12-2007 18:07    +
+ 		+ + + + +
+ ok now?
+
+
+
+ + + + + + + + + + +
+ (0004303) +
+ Thomas Deiß    +
+ 04-12-2007 18:30    +
+ 		+ + + + +
+ checked by Jens
+
+ + diff --git a/docs/mantis/CR0390.md b/docs/mantis/CR0390.md new file mode 100644 index 0000000000000000000000000000000000000000..50869cc860bb2c7ed95db666c161744932ea84c8 --- /dev/null +++ b/docs/mantis/CR0390.md @@ -0,0 +1,70 @@ + + + + + + + + + + + + + 0000390: Operational semantics clarification for check statement - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0000390Part 01: TTCN-3 Core LanguageClarificationpublic24-11-2006 10:0112-03-2008 10:24
ReporterStephan Schulz 
Assigned ToIna Schieferdecker 
PrioritylowSeveritytextReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv2.2.1 (published 2003-02) 
Target Versionv3.3.2 (published 2008-04)Fixed in Versionv3.3.2 (published 2008-04) 
Clause Reference(s)23.4.0
Source (company - Author)Alexey Mednonogov, OpenTTCN Oy
Summary0000390: Operational semantics clarification for check statement
DescriptionThe current version of the core language standard defines flow control semantics for check statement in a misleading way, so that a conclusion might be drawn that the check statement has non-blocking semantics and if used as a standalone statement, it proceeds to the next statement even in case of a mismatch. Such conclusion is in conflict with TTCN-3 Operational Semantics document (Part 4 of the standard) which reasonably draws an analogy between check statement and any other receiving operation, receive statement in particular, and defines blocking semantics for check statement.
Steps To Reproduce
Additional InformationReplace the following phrase in the clause 23.4.0:
+
+?The check operation fails if the receiving operation fails i.e. the matching criteria are not fulfilled. In this case the copy of the top element of the queue is discarded and test execution continues in the normal manner, i.e. the next statement or alternative to the check operation is evaluated.?
+
+with:
+
+?The check operation fails if the receiving operation fails i.e. the matching criteria are not fulfilled. In this case the copy of the top element of the queue is discarded and test execution continues in the same manner as for any other receiving operation, i.e. the next alternative to the check operation is evaluated. If check is used as a standalone statement, it has blocking semantics, i.e. it is considered to be a shorthand for an alt statement with the only one alternative.?
+
TagsNo tags attached.
Relationships
Attached Filesdoc CR-390-Check-Statement-Resolution.doc (208,384) 20-11-2007 08:04
http://oldforge.etsi.org/mantis/file_download.php?file_id=1128&type=bug
Issue History
Date ModifiedUsernameFieldChange
24-11-2006 10:01Stephan SchulzNew Issue
24-11-2006 10:01Stephan SchulzClause Reference(s) => 23.4.0
24-11-2006 10:01Stephan SchulzSource (company - Author) => Alexey Mednonogov, OpenTTCN Oy
24-11-2006 10:02Stephan SchulzNote Added: 0000309
24-11-2006 10:02Stephan SchulzStatusnew => confirmed
15-06-2007 19:19Stephan SchulzStatusconfirmed => assigned
15-06-2007 19:19Stephan SchulzAssigned To => Ina Schieferdecker
13-10-2007 19:14Ina SchieferdeckerAssigned ToIna Schieferdecker => Jens Grabowski
18-10-2007 14:29Ina SchieferdeckerTarget Version => Edition 3.3.1 (not yet published)
18-10-2007 14:29Ina SchieferdeckerAdditional Information Updated
20-11-2007 08:04Jens GrabowskiFile Added: CR-390-Check-Statement-Resolution.doc
20-11-2007 08:05Jens GrabowskiAssigned ToJens Grabowski => Gyorgy Rethy
20-11-2007 08:05Jens GrabowskiResolutionopen => fixed
05-12-2007 11:41Jens GrabowskiAssigned ToGyorgy Rethy => Ina Schieferdecker
05-12-2007 11:41Jens GrabowskiStatusassigned => resolved
05-12-2007 17:41Ina SchieferdeckerStatusresolved => closed
05-12-2007 17:41Ina SchieferdeckerFixed in Version => Edition 3.3.1 (not yet published)
12-03-2008 10:22user10Fixed in VersionEdition 3.3.1 --will not be published, see 3.3.2 => Edition 3.3.2 (not yet published)
12-03-2008 10:24user10Target VersionEdition 3.3.1 --will not be published, see 3.3.2 => Edition 3.3.2 (not yet published)
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0000309) +
+ Stephan Schulz    +
+ 24-11-2006 10:02    +
+ 		+ + + + +
+ Accepted
+
+ + diff --git a/docs/mantis/CR0391.md b/docs/mantis/CR0391.md new file mode 100644 index 0000000000000000000000000000000000000000..1660d96dba66c3d8033de2a409691d052e484d1e --- /dev/null +++ b/docs/mantis/CR0391.md @@ -0,0 +1,29 @@ + + + + + + + + + + + + + 0000391: Errors in BNF productions CreateOp and KillTCStatement - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0000391Part 01: TTCN-3 Core LanguageTechnicalpublic24-11-2006 10:1112-12-2008 11:55
ReporterStephan Schulz 
Assigned To 
PriorityhighSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv2.2.1 (published 2003-02) 
Target Versionv3.1.1 (published 2005-06)Fixed in Versionv3.1.1 (published 2005-06) 
Clause Reference(s)A.1.6.2.3
Source (company - Author)Helmut Neukirchen , Uni Göttingen
Summary0000391: Errors in BNF productions CreateOp and KillTCStatement
DescriptionIn Final draft ETSI ES 201 873-1 V3.0.0 (2005-03), the BNF contains two errors in Clause A.1.6.2.3. In production 305. CreateOp: the reference to SingleExpession should probably be changed to SingleExpression In prodcution 338. KillTCStatement: the reference to ComponentIdentifierOrLiteral should probably be changed to ComponentReferenceOrLiteral
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Fileszip CR_390att Errors in BNF productions CreateOp and KillTCStatement.zip (648,868) 24-11-2006 13:25
http://oldforge.etsi.org/mantis/file_download.php?file_id=34&type=bug
Issue History
Date ModifiedUsernameFieldChange
24-11-2006 10:11Stephan SchulzNew Issue
24-11-2006 10:11Stephan SchulzClause Reference(s) => A.1.6.2.3
24-11-2006 10:11Stephan SchulzSource (company - Author) => Helmut Neukirchen , Uni Göttingen
24-11-2006 10:12Stephan SchulzStatusnew => closed
24-11-2006 10:12Stephan SchulzResolutionopen => fixed
24-11-2006 10:12Stephan SchulzFixed in Version => Edition 3.1.1
24-11-2006 13:25Stephan SchulzFile Added: CR_390att Errors in BNF productions CreateOp and KillTCStatement.zip
12-12-2008 11:55Ina SchieferdeckerProduct Version => Edition 2.2.1
12-12-2008 11:55Ina SchieferdeckerTarget Version => Edition 3.1.1
+
+ + + + +
+ There are no notes attached to this issue.
+ + diff --git a/docs/mantis/CR0395.md b/docs/mantis/CR0395.md new file mode 100644 index 0000000000000000000000000000000000000000..4eabf9128172f71348d89929d314bceae910853d --- /dev/null +++ b/docs/mantis/CR0395.md @@ -0,0 +1,63 @@ + + + + + + + + + + + + + 0000395: Functionality of FOR Loop - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0000395Part 01: TTCN-3 Core LanguageNew Featurepublic24-11-2006 13:2912-12-2008 11:53
ReporterStephan Schulz 
Assigned To 
PrioritynormalSeverityfeatureReproducibilityN/A
StatusclosedResolutionwon't fix 
PlatformOSOS Version
Product Versionv2.2.1 (published 2003-02) 
Target Versionv3.1.1 (published 2005-06)Fixed in Version 
Clause Reference(s)Reference to Section 19.7
Source (company - Author)Singh Arvinder , Flextronics Software Systems
Summary0000395: Functionality of FOR Loop
DescriptionHi, I have been using TTCN 3 for writing scripts and writing behaviour of different layers in UTRAN. I wish to clarify something from your side regarding TTCN3 Core Language ref : ETSI ES 201 873-1 It seems to me that in TTCN3 language , there is INCOMPLETE support for FOR loops. There is a limitation with the supported FOR statement. It does not support usage of multiple counters in the same FOR loop I want to enquire whether TTCN3 supports multiple index assignments/initialization and multiple check statements in the same FOR statement . For Example, for( i:=0, j:=0, k :=0; i< maxValue, j < maxValue, k < maxValue ; i := i+1, j:= j+1, k := k+1){ ... ... ... } does not compile in TTCN3. While the following code compiles. for( i:=0; i< maxValue; i := i+1){ ... ... ... } for( j:=0; j< maxValue; j:= j+1){ ... ... ... } for( k:=0; k< maxValue; k: = k+1){ ... ... ... }
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
24-11-2006 13:29Stephan SchulzNew Issue
24-11-2006 13:29Stephan SchulzClause Reference(s) => Reference to Section 19.7
24-11-2006 13:29Stephan SchulzSource (company - Author) => Singh Arvinder , Flextronics Software Systems
24-11-2006 13:30Stephan SchulzStatusnew => closed
24-11-2006 13:30Stephan SchulzNote Added: 0000311
24-11-2006 13:30Stephan SchulzResolutionopen => won't fix
12-12-2008 11:53Ina SchieferdeckerTarget Version => Edition 3.1.1
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0000311) +
+ Stephan Schulz    +
+ 24-11-2006 13:30    +
+ 		+ + + + +
+ Rejected. Would complicate the semantics significantly while considered to be a rare case
+
+ + diff --git a/docs/mantis/CR0396.md b/docs/mantis/CR0396.md new file mode 100644 index 0000000000000000000000000000000000000000..d94cb01d2acacaac651ad2c7d20c43bad6ea6a4a --- /dev/null +++ b/docs/mantis/CR0396.md @@ -0,0 +1,29 @@ + + + + + + + + + + + + + 0000396: Correction of Table - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0000396Part 01: TTCN-3 Core LanguageEditorialpublic24-11-2006 13:3312-12-2008 11:53
ReporterStephan Schulz 
Assigned To 
PrioritylowSeveritytextReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.1.1 (published 2005-06) 
Target Versionv3.2.1 (published 2007-02)Fixed in Versionv3.2.1 (published 2007-02) 
Clause Reference(s)6.0
Source (company - Author)Jens Grabowski , University of Goettingen
Summary0000396: Correction of Table
DescriptionTable 3 of the TTCN-3 standard still includes the objid-Type in the Simple basic types-class. All other references to this type have been moved to Part 7 of the TTCN-3 series of standards.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
24-11-2006 13:33Stephan SchulzNew Issue
24-11-2006 13:33Stephan SchulzClause Reference(s) => 6.0
24-11-2006 13:33Stephan SchulzSource (company - Author) => Jens Grabowski , University of Goettingen
24-11-2006 13:33Stephan SchulzStatusnew => closed
24-11-2006 13:33Stephan SchulzResolutionopen => fixed
24-11-2006 13:33Stephan SchulzFixed in Version => Edition 3.2.1 (not yet published)
12-12-2008 11:53Ina SchieferdeckerTarget Version => Edition 3.2.1
+
+ + + + +
+ There are no notes attached to this issue.
+ + diff --git a/docs/mantis/CR0397.md b/docs/mantis/CR0397.md new file mode 100644 index 0000000000000000000000000000000000000000..0653e0b78b3389d5e6b1b2f889ff4562d43eb703 --- /dev/null +++ b/docs/mantis/CR0397.md @@ -0,0 +1,131 @@ + + + + + + + + + + + + + 0000397: Superfluous port in logging (XML) of port start, stop, clear - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0000397Part 06: TTCN-3 Control InterfaceTechnicalpublic24-11-2006 13:3512-12-2008 11:35
ReporterStephan Schulz 
Assigned ToStephan Schulz 
PrioritylowSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.1.1 (published 2005-06) 
Target Versionv3.2.1 (published 2007-02)Fixed in Versionv3.2.1 (published 2007-02) 
Clause Reference(s)10.4.2, B.5
Source (company - Author)Thomas Deiss, Nokia
Summary0000397: Superfluous port in logging (XML) of port start, stop, clear
DescriptionThe XML mapping of the tli operations tliPClear, tliPStart, tliPStop, and tliPHalt refer to PortConfiguration as the XML type describing the port which is affected by the operation. But PortConfiguration describes exactly two ports, which does not make sense for these operations. The problem can be fixed by changing the minOccurs clause in the definition of PortConfiguration (in appendix B.5) of the second port from 1 to 0. In this way, PortConfiguration can describe either 2 or 1 ports.
Steps To Reproduce
Additional InformationAlternatively two types for PortConfiguration could be defined, one describing exactly one port and another one describing exactly two ports.
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
24-11-2006 13:35Stephan SchulzNew Issue
24-11-2006 13:35Stephan SchulzClause Reference(s) => 10.4.2, B.5
24-11-2006 13:35Stephan SchulzSource (company - Author) => Thomas Deiss, Nokia
24-11-2006 13:36Stephan SchulzNote Added: 0000313
24-11-2006 13:36Stephan SchulzStatusnew => confirmed
01-06-2007 17:51Ina SchieferdeckerNote Added: 0002130
15-06-2007 18:39Stephan SchulzStatusconfirmed => resolved
15-06-2007 18:39Stephan SchulzFixed in Version => Edition 3.2.1 (not yet published)
15-06-2007 18:39Stephan SchulzResolutionopen => fixed
15-06-2007 18:39Stephan SchulzAssigned To => Stephan Schulz
15-06-2007 18:39Stephan SchulzNote Added: 0002391
15-06-2007 18:51Stephan SchulzStatusresolved => closed
12-12-2008 11:35Ina SchieferdeckerTarget Version => Edition 3.2.1
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0000313) +
+ Stephan Schulz    +
+ 24-11-2006 13:36    +
+ 		+ + + + +
+ Accepted
+
+
+
+ + + + + + + + + + +
+ (0002130) +
+ Ina Schieferdecker    +
+ 01-06-2007 17:51    +
+ 		+ + + + +
+ has been resolved in 3.2.1 by using PortStatis in those operations instead.
+
+
+
+ + + + + + + + + + +
+ (0002391) +
+ Stephan Schulz    +
+ 15-06-2007 18:39    +
+ 		+ + + + +
+ has been resolved in 3.2.1 by using PortStatis in those operations instead
+
+ + diff --git a/docs/mantis/CR0398.md b/docs/mantis/CR0398.md new file mode 100644 index 0000000000000000000000000000000000000000..8b9edc5dad6cdc59b1586305edebf16c99201ab1 --- /dev/null +++ b/docs/mantis/CR0398.md @@ -0,0 +1,167 @@ + + + + + + + + + + + + + 0000398: Superfluous information in TLI XML type Id - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0000398Part 06: TTCN-3 Control InterfaceTechnicalpublic24-11-2006 13:4506-12-2007 11:44
ReporterStephan Schulz 
Assigned ToIna Schieferdecker 
PrioritylowSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.1.1 (published 2005-06) 
Target Versionv3.3.1 (published 2008-04)Fixed in Versionv3.3.1 (published 2008-04) 
Clause Reference(s)10.3.2.5
Source (company - Author)Thomas Deiss, Nokia
Summary0000398: Superfluous information in TLI XML type Id
DescriptionThe XML mapping of the type Id (clause 10.3.2.5) is defined as follows Each of the elements is mandatory. This type is used as definition of the TriTimerIdType (again in the XML mapping). But when looking at the definition of TriTimerId in part 5 of the standard, there is less information there. In IDL there is just a string, and in the C mapping there is a BinaryString. This can be seen as corresponding to the element ''name'' in the XML mapping of triTimerIdType, but there is nothing corresponding to the elements ''id'' and ''type''. The minOccurs of the elements ''id'' and ''type'' in the XML mapping of TriTimerIdType shall be chanded to 0.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Fileszip es_20187306v030301_CR398.zip (1,010,462) 04-12-2007 16:56
http://oldforge.etsi.org/mantis/file_download.php?file_id=1202&type=bug
Issue History
Date ModifiedUsernameFieldChange
24-11-2006 13:45Stephan SchulzNew Issue
24-11-2006 13:45Stephan SchulzClause Reference(s) => 10.3.2.5
24-11-2006 13:45Stephan SchulzSource (company - Author) => Thomas Deiss, Nokia
24-11-2006 13:45Stephan SchulzNote Added: 0000314
24-11-2006 13:45Stephan SchulzStatusnew => confirmed
15-06-2007 19:18Stephan SchulzStatusconfirmed => assigned
15-06-2007 19:18Stephan SchulzAssigned To => Ina Schieferdecker
18-10-2007 14:30Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
04-12-2007 16:47Ina SchieferdeckerNote Added: 0004286
04-12-2007 16:56Ina SchieferdeckerFile Added: es_20187306v030301_CR398.zip
04-12-2007 16:57Ina SchieferdeckerNote Added: 0004288
04-12-2007 16:57Ina SchieferdeckerResolutionopen => fixed
04-12-2007 16:58Ina SchieferdeckerAssigned ToIna Schieferdecker => Thomas Deiß
05-12-2007 15:48Ina SchieferdeckerTarget VersionEdition 4.1.1 (not yet published) => Edition 3.3.1 (not yet published)
05-12-2007 17:00Thomas DeißNote Added: 0004348
05-12-2007 17:00Thomas DeißAssigned ToThomas Deiß => Ina Schieferdecker
05-12-2007 17:00Thomas DeißStatusassigned => resolved
06-12-2007 11:44Ina SchieferdeckerStatusresolved => closed
06-12-2007 11:44Ina SchieferdeckerFixed in Version => Edition 3.3.1 (not yet published)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0000314) +
+ Stephan Schulz    +
+ 24-11-2006 13:45    +
+ 		+ + + + +
+ Accepted
+
+
+
+ + + + + + + + + + +
+ (0004286) +
+ Ina Schieferdecker    +
+ 04-12-2007 16:47    +
+ 		+ + + + +
+ The type is basically timer - but this is redundant information.
+
+Hence, minOccurs is set as proposed.
+
+
+
+ + + + + + + + + + +
+ (0004288) +
+ Ina Schieferdecker    +
+ 04-12-2007 16:57    +
+ 		+ + + + +
+ The resolution is using already the updated text from CR2000, CR2146, CR423, CR826, CR828, CR840, CR842, CR843, and CR1683.
+
+
+
+ + + + + + + + + + +
+ (0004348) +
+ Thomas Deiß    +
+ 05-12-2007 17:00    +
+ 		+ + + + +
+ checked by Thomas, ok.
+
+ + diff --git a/docs/mantis/CR0399.md b/docs/mantis/CR0399.md new file mode 100644 index 0000000000000000000000000000000000000000..44351c56dbd08dfcbe43f695de032a60b3a94eed --- /dev/null +++ b/docs/mantis/CR0399.md @@ -0,0 +1,245 @@ + + + + + + + + + + + + + 0000399: mixup of triParameterListType and tciParameterListType - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0000399Part 06: TTCN-3 Control InterfaceTechnicalpublic24-11-2006 13:4806-12-2007 12:53
ReporterStephan Schulz 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.1.1 (published 2005-06) 
Target Versionv3.3.1 (published 2008-04)Fixed in Versionv3.3.1 (published 2008-04) 
Clause Reference(s)Reference to clause(s) and/or subclause(s) related to CR
Source (company - Author)  Thomas Deiss, Nokia
Summary0000399: mixup of triParameterListType and tciParameterListType
DescriptionIn several of the TCI-TM and TCI-TL operations, the usage of triParameterListType and tciParaemterListType are mixed up. General rule should be that tciParameterListType is used for lists of unencoded parameterls and triParameterListType should be used for lists of encoded Parameters. Please have a look at the changes in the attached version of part 6 of the standard. The changes also needs to be done in Appendix B.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Fileszip CR_394att Mixup of triParameterListType and tciParameterListType .zip (1,211,637) 24-11-2006 13:48
http://oldforge.etsi.org/mantis/file_download.php?file_id=35&type=bug
zip es_20187306v030301_CR399.zip (1,145,586) 17-10-2007 19:47
http://oldforge.etsi.org/mantis/file_download.php?file_id=1042&type=bug
Issue History
Date ModifiedUsernameFieldChange
24-11-2006 13:48Stephan SchulzNew Issue
24-11-2006 13:48Stephan SchulzFile Added: CR_394att Mixup of triParameterListType and tciParameterListType .zip
24-11-2006 13:48Stephan SchulzClause Reference(s) => Reference to clause(s) and/or subclause(s) related to CR
24-11-2006 13:48Stephan SchulzSource (company - Author) => Thomas Deiss, Nokia
24-11-2006 13:48Stephan SchulzNote Added: 0000315
24-11-2006 13:48Stephan SchulzStatusnew => confirmed
01-06-2007 17:46Ina SchieferdeckerNote Added: 0002129
15-06-2007 18:40Stephan SchulzStatusconfirmed => resolved
15-06-2007 18:40Stephan SchulzFixed in Version => Edition 3.2.1 (not yet published)
15-06-2007 18:40Stephan SchulzResolutionopen => fixed
15-06-2007 18:40Stephan SchulzAssigned To => Stephan Schulz
15-06-2007 18:51Stephan SchulzStatusresolved => closed
15-10-2007 23:24Ina SchieferdeckerAssigned ToStephan Schulz => Ina Schieferdecker
15-10-2007 23:24Ina SchieferdeckerStatusclosed => feedback
15-10-2007 23:24Ina SchieferdeckerResolutionfixed => reopened
15-10-2007 23:24Ina SchieferdeckerNote Added: 0003635
17-10-2007 19:23Ina SchieferdeckerNote Added: 0003687
17-10-2007 19:24Ina SchieferdeckerStatusfeedback => closed
17-10-2007 19:24Ina SchieferdeckerNote Added: 0003688
17-10-2007 19:24Ina SchieferdeckerResolutionreopened => fixed
17-10-2007 19:24Ina SchieferdeckerFixed in VersionEdition 3.2.1 => Edition 3.3.1 (not yet published)
17-10-2007 19:45Ina SchieferdeckerStatusclosed => feedback
17-10-2007 19:45Ina SchieferdeckerResolutionfixed => reopened
17-10-2007 19:46Ina SchieferdeckerNote Deleted: 0003688
17-10-2007 19:47Ina SchieferdeckerFile Added: es_20187306v030301_CR399.zip
18-10-2007 12:04Ina SchieferdeckerFixed in VersionEdition 3.3.1 (not yet published) =>
18-10-2007 12:04Ina SchieferdeckerTarget Version => Edition 3.3.1 (not yet published)
18-10-2007 15:39Ina SchieferdeckerStatusfeedback => resolved
18-10-2007 15:39Ina SchieferdeckerResolutionreopened => fixed
18-10-2007 15:39Ina SchieferdeckerNote Added: 0003694
04-12-2007 17:17Ina SchieferdeckerAssigned ToIna Schieferdecker => Thomas Deiß
04-12-2007 17:17Ina SchieferdeckerStatusresolved => feedback
04-12-2007 17:17Ina SchieferdeckerResolutionfixed => reopened
04-12-2007 17:18Ina SchieferdeckerStatusfeedback => assigned
04-12-2007 17:18Ina SchieferdeckerResolutionreopened => fixed
04-12-2007 17:38Thomas DeißNote Added: 0004298
04-12-2007 17:38Thomas DeißAssigned ToThomas Deiß => Ina Schieferdecker
04-12-2007 17:38Thomas DeißStatusassigned => resolved
06-12-2007 12:53Ina SchieferdeckerStatusresolved => closed
06-12-2007 12:53Ina SchieferdeckerFixed in Version => Edition 3.3.1 (not yet published)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0000315) +
+ Stephan Schulz    +
+ 24-11-2006 13:48    +
+ 		+ + + + +
+ Accepted
+
+
+
+ + + + + + + + + + +
+ (0002129) +
+ Ina Schieferdecker    +
+ 01-06-2007 17:46    +
+ 		+ + + + +
+ fixed in 3.2.1
+
+
+
+ + + + + + + + + + +
+ (0003635) +
+ Ina Schieferdecker    +
+ 15-10-2007 23:24    +
+ 		+ + + + +
+ This is possibly be a mistake in the standard. TriParameterList is used for representing encoded parameters. Semantically it does not make sense to have a TriParameterList here because testcase parameters are never encoded.
+
+A change request about this issue was reported last year and was accepted in v3.2.1: http://ipt-bugs.dyndns.org/mantis/view.php?id=399 [^]
+
+But it seems that it was not complety merged in completly merged. For example tliTcStart() was updated to use TciParameterListType instead of TriParameterList but tliTcExecute() is still the same.
+
+
+
+ + + + + + + + + + +
+ (0003687) +
+ Ina Schieferdecker    +
+ 17-10-2007 19:23    +
+ 		+ + + + +
+ Indeed 7.3.4.1.1 were missing: tliTcExecute: TriParameterListType --> TciParameterListType
+
+In addition, in 9.4 the mappings for tliTcExecute and tliTcStart have to be updated
+
+Furthermore, the use of TriParameterListType (not TriParameterList) was inconsistent in 9.4 - now corrected
+
+Also, tliTcExecute in 10.4.2 corrected
+
+Finally, tliTcExecute in Annex A and B corrected
+
+
+
+ + + + + + + + + + +
+ (0003694) +
+ Ina Schieferdecker    +
+ 18-10-2007 15:39    +
+ 		+ + + + +
+ see resolution attachment
+
+
+
+ + + + + + + + + + +
+ (0004298) +
+ Thomas Deiß    +
+ 04-12-2007 17:38    +
+ 		+ + + + +
+ checked by Thomas, ok.
+
+ + diff --git a/docs/mantis/CR0400.md b/docs/mantis/CR0400.md new file mode 100644 index 0000000000000000000000000000000000000000..91551456014ed12c4dad63756dfc789e67ae3d23 --- /dev/null +++ b/docs/mantis/CR0400.md @@ -0,0 +1,97 @@ + + + + + + + + + + + + + 0000400: tliSLeave missing parameters - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0000400Part 06: TTCN-3 Control InterfaceTechnicalpublic24-11-2006 13:4912-12-2008 11:36
ReporterStephan Schulz 
Assigned ToStephan Schulz 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.1.1 (published 2005-06) 
Target Versionv3.2.1 (published 2007-02)Fixed in Versionv3.2.1 (published 2007-02) 
Clause Reference(s)Reference to clause(s) and/or subclause(s) related to CR
Source (company - Author)Thomas Deiss, Nokia
Summary0000400: tliSLeave missing parameters
DescriptionThe description of the TCI-TL operation SLeave (leave a scope unit) has a parameter for a return value, but there are no parameters for the parameter list of the scope unit. As such it will not be possible to log the values of out and inout parameters when leaving a scope unit. Solution would be to add such a parameter like in SEnter.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
24-11-2006 13:49Stephan SchulzNew Issue
24-11-2006 13:49Stephan SchulzClause Reference(s) => Reference to clause(s) and/or subclause(s) related to CR
24-11-2006 13:49Stephan SchulzSource (company - Author) => Thomas Deiss, Nokia
24-11-2006 13:50Stephan SchulzNote Added: 0000316
24-11-2006 13:50Stephan SchulzStatusnew => confirmed
01-06-2007 17:45Ina SchieferdeckerNote Added: 0002128
15-06-2007 18:41Stephan SchulzStatusconfirmed => resolved
15-06-2007 18:41Stephan SchulzFixed in Version => Edition 3.2.1 (not yet published)
15-06-2007 18:41Stephan SchulzResolutionopen => fixed
15-06-2007 18:41Stephan SchulzAssigned To => Stephan Schulz
15-06-2007 18:50Stephan SchulzStatusresolved => closed
12-12-2008 11:36Ina SchieferdeckerTarget Version => Edition 3.2.1
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0000316) +
+ Stephan Schulz    +
+ 24-11-2006 13:50    +
+ 		+ + + + +
+ Accepted
+
+
+
+ + + + + + + + + + +
+ (0002128) +
+ Ina Schieferdecker    +
+ 01-06-2007 17:45    +
+ 		+ + + + +
+ fixed in 3.2.1
+
+ + diff --git a/docs/mantis/CR0401.md b/docs/mantis/CR0401.md new file mode 100644 index 0000000000000000000000000000000000000000..ddb429c2a6167ed52d15c1246afd7baecaed83ad --- /dev/null +++ b/docs/mantis/CR0401.md @@ -0,0 +1,97 @@ + + + + + + + + + + + + + 0000401: tliGetReplyDetected is missing parameter list - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0000401Part 06: TTCN-3 Control InterfaceTechnicalpublic24-11-2006 13:5112-12-2008 11:36
ReporterStephan Schulz 
Assigned ToStephan Schulz 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.1.1 (published 2005-06) 
Target Versionv3.2.1 (published 2007-02)Fixed in Versionv3.2.1 (published 2007-02) 
Clause Reference(s)Reference to clause(s) and/or subclause(s) related to CR
Source (company - Author)Thomas Deiss, Nokia
Summary0000401: tliGetReplyDetected is missing parameter list
DescriptionThe TCI-TL operation tliGetReplyDetected_* do not have a parameter for the signature parameters of the reply. As such the encoded parameters (relevant for out and inout) used in the reply cannot be logged. Such a parameter is available for tliGetReplyMismatch_*. Solution: Add a parameter similar to tliGetReplyMismatch_*
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
24-11-2006 13:51Stephan SchulzNew Issue
24-11-2006 13:51Stephan SchulzClause Reference(s) => Reference to clause(s) and/or subclause(s) related to CR
24-11-2006 13:51Stephan SchulzSource (company - Author) => Thomas Deiss, Nokia
24-11-2006 13:51Stephan SchulzNote Added: 0000317
24-11-2006 13:51Stephan SchulzStatusnew => confirmed
01-06-2007 17:44Ina SchieferdeckerNote Added: 0002127
15-06-2007 18:41Stephan SchulzStatusconfirmed => resolved
15-06-2007 18:41Stephan SchulzFixed in Version => Edition 3.2.1 (not yet published)
15-06-2007 18:41Stephan SchulzResolutionopen => fixed
15-06-2007 18:41Stephan SchulzAssigned To => Stephan Schulz
15-06-2007 18:50Stephan SchulzStatusresolved => closed
12-12-2008 11:36Ina SchieferdeckerTarget Version => Edition 3.2.1
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0000317) +
+ Stephan Schulz    +
+ 24-11-2006 13:51    +
+ 		+ + + + +
+ Accepted
+
+
+
+ + + + + + + + + + +
+ (0002127) +
+ Ina Schieferdecker    +
+ 01-06-2007 17:44    +
+ 		+ + + + +
+ fixed in 3.2.1
+
+ + diff --git a/docs/mantis/CR0402.md b/docs/mantis/CR0402.md new file mode 100644 index 0000000000000000000000000000000000000000..6e43edce9e54afb05f5ce511094b49c299356bad --- /dev/null +++ b/docs/mantis/CR0402.md @@ -0,0 +1,29 @@ + + + + + + + + + + + + + 0000402: done should be killed - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0000402Part 01: TTCN-3 Core LanguageEditorialpublic24-11-2006 13:5412-12-2008 11:51
ReporterStephan Schulz 
Assigned To 
PrioritylowSeveritytextReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv2.2.1 (published 2003-02) 
Target Versionv3.1.1 (published 2005-06)Fixed in Versionv3.1.1 (published 2005-06) 
Clause Reference(s)22.11
Source (company - Author)gyorgy rethy, ericsson
Summary0000402: done should be killed
Description22.11 The Killed operation The killed operation allows to ascertain whether a different test component is alive or has been removed from the test system. The killed operation shall be used in the same manner as receiving operations. This means it shall not be used in boolean expressions, but it can be used to determine an alternative in an alt statement or as a stand-alone statement in a behaviour description. In the latter case a done operation is considered to be a shorthand for an alt statement with only one alternative, i.e. it has blocking semantics, and therefore provides the ability of passive waiting for the termination of test components.
Steps To Reproduce
Additional InformationSolution: ...In the latter case a killed operation is considered to be a shorthand...
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
24-11-2006 13:54Stephan SchulzNew Issue
24-11-2006 13:54Stephan SchulzClause Reference(s) => 22.11
24-11-2006 13:54Stephan SchulzSource (company - Author) => gyorgy rethy, ericsson
24-11-2006 13:54Stephan SchulzStatusnew => closed
24-11-2006 13:54Stephan SchulzResolutionopen => fixed
24-11-2006 13:54Stephan SchulzFixed in Version => Edition 3.1.1
12-12-2008 11:51Ina SchieferdeckerProduct VersionEdition 3.1.1 => Edition 2.2.1
12-12-2008 11:51Ina SchieferdeckerTarget Version => Edition 3.1.1
+
+ + + + +
+ There are no notes attached to this issue.
+ + diff --git a/docs/mantis/CR0403.md b/docs/mantis/CR0403.md new file mode 100644 index 0000000000000000000000000000000000000000..f7c8b8777d1a312e4a486608bf1459bef24b2d9c --- /dev/null +++ b/docs/mantis/CR0403.md @@ -0,0 +1,577 @@ + + + + + + + + + + + + + 0000403: Port type parameterisation of component types - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0000403Part 01: TTCN-3 Core LanguageNew Featurepublic24-11-2006 13:5720-04-2009 11:38
ReporterStephan Schulz 
Assigned ToGyorgy Rethy 
PriorityhighSeverityfeatureReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.1.1 (published 2005-06) 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)Reference to clause(s) and/or subclause(s) related to CR
Source (company - Author)Paul Baker, motorola
Summary0000403: Port type parameterisation of component types
DescriptionWe would like to extend the parameterisation of component types to allow port types. Thus allowing users to pass ports as parameters during test configuration set-up. This was allowed in TTCN-2 when a PTC was created, but is not currently allowed in TTCN-3.
Steps To Reproduce
Additional InformationThis issue seems to becoming more important (in some cases an issue) for a number of large TTCN-2 user groups that we are migrating to TTCN-3. Most of these groups use TTCN-2 for concurrency, hence, find this parameterisation useful. One case is TTCN-3 / UML 2.0 model co-simulation environments. In this use case we need to route messages from dynamically created UML components, which each have the same port, to TTCN-3 ports. The only way to achieve this currently with TRI is to use an array of ports whose index is defined when the TTCN-3 component is started. This is not very useful!
TagsNo tags attached.
Relationships
related to 0003011closed Ina Schieferdecker Remove type parameterization from BNF 
related to 0003955closed Ina Schieferdecker Text ""TTCN-3 supports value, template, timer and port parameterization” is misleading 
related to 0004275closed Ina Schieferdecker New Concepts to be defined via Packages 
Attached Filesppt General_Extension_status_13_08_08_type_parameterization.ppt (40,448) 14-08-2008 12:28
http://oldforge.etsi.org/mantis/file_download.php?file_id=1598&type=bug
doc CR_403_type_parameters_01.doc (322,560) 16-10-2008 15:20
http://oldforge.etsi.org/mantis/file_download.php?file_id=1706&type=bug
doc CR_403_type_parameters_02.doc (324,608) 24-11-2008 15:14
http://oldforge.etsi.org/mantis/file_download.php?file_id=1761&type=bug
doc CR_403_type_parameters_03.doc (312,320) 25-11-2008 07:53
http://oldforge.etsi.org/mantis/file_download.php?file_id=1762&type=bug
doc CR_403_type_parameters_04.doc (316,416) 27-11-2008 08:36
http://oldforge.etsi.org/mantis/file_download.php?file_id=1809&type=bug
doc CR_403_type_parameters_05.doc (495,616) 09-12-2008 13:19
http://oldforge.etsi.org/mantis/file_download.php?file_id=1870&type=bug
doc CR_403_type_parameters_06.doc (496,128) 09-12-2008 15:06
http://oldforge.etsi.org/mantis/file_download.php?file_id=1875&type=bug
doc CR_403_type_parameters_061.doc (496,640) 15-01-2009 07:07
http://oldforge.etsi.org/mantis/file_download.php?file_id=1954&type=bug
doc CR_403_type_parameters_062.doc (497,664) 15-01-2009 08:01
http://oldforge.etsi.org/mantis/file_download.php?file_id=1956&type=bug
doc CR_403_type_parameters_07.doc (325,632) 20-01-2009 07:18
http://oldforge.etsi.org/mantis/file_download.php?file_id=1966&type=bug
doc CR_403_type_parameters_07_ASN1.doc (99,840) 23-01-2009 14:12
http://oldforge.etsi.org/mantis/file_download.php?file_id=1970&type=bug
doc CR_403_type_parameters_071.doc (344,064) 23-01-2009 15:22
http://oldforge.etsi.org/mantis/file_download.php?file_id=1973&type=bug
doc CR_403_type_parameters_08_ASN1.doc (117,760) 23-01-2009 15:33
http://oldforge.etsi.org/mantis/file_download.php?file_id=1975&type=bug
doc CR_403_type_parameters_081.doc (361,472) 27-01-2009 09:28
http://oldforge.etsi.org/mantis/file_download.php?file_id=1978&type=bug
Issue History
Date ModifiedUsernameFieldChange
24-11-2006 13:57Stephan SchulzNew Issue
24-11-2006 13:57Stephan SchulzClause Reference(s) => Reference to clause(s) and/or subclause(s) related to CR
24-11-2006 13:57Stephan SchulzSource (company - Author) => Paul Baker, motorola
24-11-2006 15:04Stephan SchulzNote Added: 0000332
15-06-2007 19:13Stephan SchulzStatusnew => assigned
15-06-2007 19:13Stephan SchulzAssigned To => Ina Schieferdecker
13-10-2007 19:29Ina SchieferdeckerAssigned ToIna Schieferdecker => Jens Grabowski
15-10-2007 12:19Ina SchieferdeckerNote Added: 0003605
18-10-2007 14:29Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
18-07-2008 08:56Jens GrabowskiAssigned ToJens Grabowski => Thomas Deiß
14-08-2008 12:28Thomas DeißFile Added: General_Extension_status_13_08_08_type_parameterization.ppt
16-10-2008 15:20Thomas DeißFile Added: CR_403_type_parameters_01.doc
24-11-2008 10:54Ina SchieferdeckerRelationship addedrelated to 0003011
24-11-2008 15:14Thomas DeißFile Added: CR_403_type_parameters_02.doc
24-11-2008 15:15Thomas DeißNote Added: 0007389
25-11-2008 07:53Thomas DeißFile Added: CR_403_type_parameters_03.doc
25-11-2008 07:54Thomas DeißNote Added: 0007393
27-11-2008 08:36Thomas DeißFile Added: CR_403_type_parameters_04.doc
27-11-2008 08:37Thomas DeißNote Added: 0007465
28-11-2008 13:47Thomas DeißAssigned ToThomas Deiß => Ina Schieferdecker
09-12-2008 10:24Ina SchieferdeckerRelationship addedrelated to 0003955
09-12-2008 13:19Ina SchieferdeckerFile Added: CR_403_type_parameters_05.doc
09-12-2008 13:22Ina SchieferdeckerNote Added: 0007595
09-12-2008 13:22Ina SchieferdeckerAssigned ToIna Schieferdecker => Thomas Deiß
09-12-2008 13:22Ina SchieferdeckerResolutionopen => fixed
09-12-2008 14:54Thomas DeißFile Added: CR_403_type_parameters_06.doc
09-12-2008 15:05Thomas DeißNote Added: 0007601
09-12-2008 15:05Thomas DeißAssigned ToThomas Deiß => Ina Schieferdecker
09-12-2008 15:05Thomas DeißFile Deleted: CR_403_type_parameters_06.doc
09-12-2008 15:06Thomas DeißFile Added: CR_403_type_parameters_06.doc
09-12-2008 15:49Ina SchieferdeckerNote Added: 0007607
12-12-2008 09:04Ina SchieferdeckerRelationship addedrelated to 0004275
12-12-2008 09:20Ina SchieferdeckerNote Added: 0007668
12-12-2008 09:20Ina SchieferdeckerAssigned ToIna Schieferdecker => Gyorgy Rethy
15-01-2009 07:07Thomas DeißFile Added: CR_403_type_parameters_061.doc
15-01-2009 07:08Thomas DeißNote Added: 0007862
15-01-2009 08:01Thomas DeißFile Added: CR_403_type_parameters_062.doc
15-01-2009 08:02Thomas DeißNote Added: 0007864
20-01-2009 07:18Thomas DeißFile Added: CR_403_type_parameters_07.doc
23-01-2009 13:39Gyorgy RethyNote Added: 0007921
23-01-2009 14:11Gyorgy RethyNote Edited: 0007921
23-01-2009 14:12Gyorgy RethyFile Added: CR_403_type_parameters_07_ASN1.doc
23-01-2009 14:45Gyorgy RethyFile Added: CR_403_type_parameters_08_ASN1.doc
23-01-2009 14:46Gyorgy RethyFile Deleted: CR_403_type_parameters_08_ASN1.doc
23-01-2009 15:22Thomas DeißFile Added: CR_403_type_parameters_071.doc
23-01-2009 15:23Thomas DeißNote Added: 0007924
23-01-2009 15:25Gyorgy RethyFile Added: CR_403_type_parameters_08_ASN1.doc
23-01-2009 15:29Gyorgy RethyFile Deleted: CR_403_type_parameters_08_ASN1.doc
23-01-2009 15:33Gyorgy RethyFile Added: CR_403_type_parameters_08_ASN1.doc
23-01-2009 15:37Gyorgy RethyNote Added: 0007925
27-01-2009 09:28Thomas DeißFile Added: CR_403_type_parameters_081.doc
27-01-2009 09:30Thomas DeißNote Added: 0007940
10-03-2009 10:47Ina SchieferdeckerStatusassigned => resolved
10-03-2009 10:47Ina SchieferdeckerFixed in Version => Edition 4.1.1 (not yet published)
20-04-2009 11:38Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0000332) +
+ Stephan Schulz    +
+ 24-11-2006 15:04    +
+ 		+ + + + +
+ Type parameterization in general shall be discussed; This CR depends on the type parameterization discussion
+
+
+
+ + + + + + + + + + +
+ (0003605) +
+ Ina Schieferdecker    +
+ 15-10-2007 12:19    +
+ 		+ + + + +
+ This should be considered in the larger context of type parameterization for TTCN-3 and is therefore deferred to the STF in 2008
+
+
+
+ + + + + + + + + + +
+ (0007389) +
+ Thomas Deiß    +
+ 24-11-2008 15:15    +
+ 		+ + + + +
+ typo corrected. small extension on semantics.
+version 02 uploaded.
+
+
+
+ + + + + + + + + + +
+ (0007393) +
+ Thomas Deiß    +
+ 25-11-2008 07:54    +
+ 		+ + + + +
+ editorial corrections.
+Formal type parameters of nested type definitions removed for the sake of simplicity.
+
+
+
+ + + + + + + + + + +
+ (0007465) +
+ Thomas Deiß    +
+ 27-11-2008 08:37    +
+ 		+ + + + +
+ restriction for default values of parameters added. In this case the type must not be a type parameter.
+v04 uploaded
+
+
+
+ + + + + + + + + + +
+ (0007595) +
+ Ina Schieferdecker    +
+ 09-12-2008 13:22    +
+ 		+ + + + +
+ Added the C++ mapping part.
+
+Moved the annexes to the respective parts of TTCN-3.
+
+Did some rewording and reformatting.
+
+Please check.
+
+
+
+ + + + + + + + + + +
+ (0007601) +
+ Thomas Deiß    +
+ 09-12-2008 15:05    +
+ 		+ + + + +
+ C++ mapping not checked.
+
+Issue whether all or known types can be used as actual parameters.
+Actually this is not quite clear to me: "Any compatible type known in a module can be passed as actual parameter, i.e. actual type parameters are not limited to those types only known in the module containing the type parameterized definition itself"
+
+Which module is considered here: Is it the module where the actual parameters are provided, or is it the module containing the type parameterized definition? On first reading I thought it is the second one, which would lead to similar restrictions as in the use of the anytype. But on second reading, the actual intention might be that the really the known types of the module where the actual parameters are provided can be used. Maybe I had problems with this because this is somehow obvious: only what is known in a module can be provided as actual parameter. The usage of 'compatible' type is blurring the difference further.
+
+May I suggest to remove the 'known in a module' from the beginning of the first sentence: "Any compatible type can be passed as actual parameter, i.e. actual type parameters are not limited to those types only known in the module containing the type parameterized definition itself"
+
+
+
+ + + + + + + + + + +
+ (0007607) +
+ Ina Schieferdecker    +
+ 09-12-2008 15:49    +
+ 		+ + + + +
+ fine with me.
+
+
+
+ + + + + + + + + + +
+ (0007668) +
+ Ina Schieferdecker    +
+ 12-12-2008 09:20    +
+ 		+ + + + +
+ Please check.
+
+
+
+ + + + + + + + + + +
+ (0007862) +
+ Thomas Deiß    +
+ 15-01-2009 07:08    +
+ 		+ + + + +
+ language tag added, document numbers added.
+
+
+
+ + + + + + + + + + +
+ (0007864) +
+ Thomas Deiß    +
+ 15-01-2009 08:02    +
+ 		+ + + + +
+ tag corrected
+
+
+
+ + + + + + + + + + +
+ (0007921) +
+ Gyorgy Rethy    +
+ 23-01-2009 13:39    +
(edited on: 23-01-2009 14:11)
+ 		+ + + + +
+ I have the following comments:
+
+1) type compatibility
+Real type compatibility is defined for component types only (and there are two rules for component types), therefore to say in general, that the actual type shall be compatible with the formal type parameter is ambiguous. possible solutions:
+- allow type compatibility for component types only, runson compatibility rule only (Part-1 $6.3.3 item 2). This is mentioned, without the precise reference, in clause 5.4.1.5 restriction c), but not consistently required through the whole text. This would mean, that the formal type parameter name shall always be a component type.
+
+- In addition to component type names allow as formal type parameters built-in simple types In this case the actual type parameter simply has to be the same root type as the formal parameter. In case of structured types all fields of the formal type parameter shall resolve to built-in types (i.e. not constrained) and the actual type shall be type compatible acc. to part-1 6.3.2.2 and all fields shall resolve to the same root type as the correcponding field of the formal type parameter.
+
+I would go for the simpler solution at this stage, i.e. formal type parameter shall be either "type" or a component type name, and rather come back to the data type compatibility later, if a CR requires it.
+
+2) editorial
+$6.4 end of 2nd paragraph: *Part-1* clause 10.
+
+3)
+The package has also effect on ASN.1 to TTCN-3 mapping as allows importing ASN.1 definitions with value formal parameters. I uploaded a proposed text in CR_403_type_parameters_07_ASN1.doc
+
+4) In the header of table A.1 in clause 9.2 (new clause no 10.2 in the uploaded file) "Constants (TTCN 3 and external)" shall be "Constants" as external constants are deleted in Part-1.
+
+
+
+
+
+ + + + + + + + + + +
+ (0007924) +
+ Thomas Deiß    +
+ 23-01-2009 15:23    +
+ 		+ + + + +
+ Comments by Gyorgy and Jacob Wieland included. (Jacob commented on a few inconsistencies in the BNF)
+
+
+
+ + + + + + + + + + +
+ (0007925) +
+ Gyorgy Rethy    +
+ 23-01-2009 15:37    +
+ 		+ + + + +
+ New updated additions on importing ASN.1 parameterization is uploaded in CR_403_type_parameters_08_ASN1.doc. This new version aligns the structure between the 201 873 parts and the pparameterization package, namely importing ASN.1 parameterized definitions is moved to the package from Part-7.
+
+
+
+ + + + + + + + + + +
+ (0007940) +
+ Thomas Deiß    +
+ 27-01-2009 09:30    +
+ 		+ + + + +
+ Updated ASN clause from Gyorgy added.
+
+Comment by Jacob Wieland on usage of actual parameters in extended field reference. These make sense only when refering alternatives in a union (anytype). The BNF rule ExtendedFieldReference was changes accordingly.
+
+version 081 uploaded.
+
+ + diff --git a/docs/mantis/CR0404.md b/docs/mantis/CR0404.md new file mode 100644 index 0000000000000000000000000000000000000000..590dd53e455074f2d9335ecef1923c6a20f8d238 --- /dev/null +++ b/docs/mantis/CR0404.md @@ -0,0 +1,369 @@ + + + + + + + + + + + + + 0000404: Support for simulated time - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Perf & Real Time Testing (ES 202 782)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0000404Ext Pack: Perf & Real Time Testing (ES 202 782)New Featurepublic24-11-2006 13:5924-05-2011 17:43
ReporterStephan Schulz 
Assigned ToGyorgy Rethy 
PrioritylowSeverityfeatureReproducibilityN/A
StatusclosedResolutionwon't fix 
PlatformOSOS Version
Product Version 
Target Versionv1.2.1 (published 2014-06)Fixed in Version 
Clause Reference(s)7.3.3.1.29
Source (company - Author)Thomas deiss, nokia
TS version
Summary0000404: Support for simulated time
DescriptionSolution for testing with simulated time So far, most TTCN-3 test suites have been executed using a notion of real-time. Implementing simulated time in TTCN-3 is not straightforward. In the TT-Medal project, we have provided three possible implementations of simulated time for TTCN-3 by Nokia, Conformiq and Centrum voor Wiskunde en Informatica. Although working well for certain case studies, these solutions are ad-hoc and not always efficient. All the solutions share the following common functionality: detecting idleness (either of the test system or of the test system together with the SUT) and progressing time by updating active timers. Here we consider a system consisting of several entities or components running in parallel. Each of the entities can be either active or idle. An active entity becomes idle if it cannot proceed by receiving/sending messages/timeouts or computations. An idle entity is activated by receiving a message, or a timeout or a call. The whole system is idle if all entities are idle and there are no messages and timeouts pending in the network. In simulated time, time may progress when the whole system is idle. In order to facilitate idleness detection, we propose to introduce an operation tciAllAWait(TRIcounter1, TRIcounter2, TCIcounter1, TCIcounter2) where the first two counters show the number of messages/calls/replys/exception/timeouts respectively sent and received by a TE entity via TRI interface. The second pair of counters provides the same information about messages exchanged via TCI. This operation is called by a TE when it awaits an event for a new snapshot meaning the TE cannot proceed by computation/sending/receiving messages. The idleness of a single TE does not necessarily mean the idleness of the whole system. There still can be a message sent by the SUT pending, or one of TEs can still be active sending messages to other TEs and/or the SUT. To decide on the global idleness the CH entity uses the information provided by tciAllAWait calls of the underlying TEs. The information given by the tciAllAWait can be exploited to detect idleness of the test system. For example one of the existing distributed termination detection algorithms can be implemented by the CH in order to decide on the idleness of the distributed test system. After the idleness of the test system is detected by the CH entity, two ways are possible at least. If the SUT provides an interface informing the CH on the idleness of the SUT, the CH decides on the global idleness of the test system and the SUT and triggers time progression. Otherwise, the CH entity reports on the idleness of the test system to the SUT and the SUT decides on the global idleness and triggers time progression. If the SUT is not idle it just activates the test system by sending a non-timed message. Both ways have been implemented in the case studies carried by Nokia, Conformiq and Centrum voor Wiskunde en Informatica in the TT-Medal project. Testing with simulated time have been successfully applied to test systems from railway and telecommunication. The main advantage of introducing the new interface is that it shifts idleness detection within a TE entity to an implementation of TE Executable. That enables using the same test suites for testing with real time and for testing with simulated time.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0004483closed Jens Grabowski Part 01: TTCN-3 Core Language New Concepts to Test Real Time Properties 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
24-11-2006 13:59Stephan SchulzNew Issue
24-11-2006 13:59Stephan SchulzClause Reference(s) => 7.3.3.1.29
24-11-2006 13:59Stephan SchulzSource (company - Author) => Thomas deiss, nokia
15-06-2007 19:18Stephan SchulzStatusnew => assigned
15-06-2007 19:18Stephan SchulzAssigned To => Ina Schieferdecker
15-10-2007 17:09Ina SchieferdeckerNote Added: 0003626
18-10-2007 14:24Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
28-11-2008 12:31Ina SchieferdeckerRelationship addedrelated to 0004483
28-11-2008 12:32Ina SchieferdeckerNote Added: 0007500
28-11-2008 12:33Ina SchieferdeckerTarget VersionEdition 4.1.1 (not yet published) => Edition 4.2.1 (not yet published)
20-04-2009 12:16Ina SchieferdeckerAssigned ToIna Schieferdecker => Jens Grabowski
16-02-2010 14:37Jens GrabowskiNote Added: 0009224
18-03-2010 07:43Ina SchieferdeckerTarget VersionEdition 4.2.1 (not yet published) => Edition 5.1.1 (not yet published)
22-03-2010 17:25Gyorgy RethyAssigned ToJens Grabowski =>
22-03-2010 17:25Gyorgy RethyStatusassigned => new
23-03-2010 13:07Gyorgy RethyAssigned To => Gyorgy Rethy
23-03-2010 13:07Gyorgy RethyPrioritynormal => low
23-03-2010 13:07Gyorgy RethyStatusnew => assigned
26-03-2010 10:36Gyorgy RethyProjectPart 06: TTCN-3 Control Interface => Ext Pack: Perf & Real Time Testing (ES 202 782)
30-11-2010 13:29Gyorgy RethyNote Added: 0009843
30-11-2010 13:29Gyorgy RethyNote Added: 0009844
30-11-2010 13:30Gyorgy RethyNote Added: 0009845
30-11-2010 13:30Gyorgy RethyNote Added: 0009846
30-11-2010 13:30Gyorgy RethyNote Added: 0009847
03-12-2010 09:48Gyorgy RethyProduct VersionEdition 3.1.1 =>
03-12-2010 09:48Gyorgy RethyTarget VersionEdition 4.3.1 (not yet published) => v1.3.1
13-12-2010 12:53Gyorgy RethyTarget Versionv1.3.1 => v1.2.2 (interim)
24-05-2011 17:42Gyorgy RethyNote Added: 0010038
24-05-2011 17:43Gyorgy RethyStatusassigned => closed
24-05-2011 17:43Gyorgy RethyNote Added: 0010039
24-05-2011 17:43Gyorgy RethyResolutionopen => won't fix
26-05-2011 15:50Ina SchieferdeckerRelationship addedrelated to 0004275
26-05-2011 15:50Ina SchieferdeckerRelationship deletedrelated to 0004275
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0003626) +
+ Ina Schieferdecker    +
+ 15-10-2007 17:09    +
+ 		+ + + + +
+ to be deferred to the timing discussions for TTCN-3 in 2008
+
+
+
+ + + + + + + + + + +
+ (0007500) +
+ Ina Schieferdecker    +
+ 28-11-2008 12:32    +
+ 		+ + + + +
+ Resolution should consider the CR4483 resolution - hence targetted for v4.2.1
+
+
+
+ + + + + + + + + + +
+ (0009224) +
+ Jens Grabowski    +
+ 16-02-2010 14:37    +
+ 		+ + + + +
+ To be discussed for version 5.1.1.
+
+
+
+ + + + + + + + + + +
+ (0009843) +
+ Gyorgy Rethy    +
+ 30-11-2010 13:29    +
+ 		+ + + + +
+ STF discussion on 30/11/2010: postpone to 2011.
+
+
+
+ + + + + + + + + + +
+ (0009844) +
+ Gyorgy Rethy    +
+ 30-11-2010 13:29    +
+ 		+ + + + +
+ STF discussion on 30/11/2010: postpone to 2011.
+
+
+
+ + + + + + + + + + +
+ (0009845) +
+ Gyorgy Rethy    +
+ 30-11-2010 13:30    +
+ 		+ + + + +
+ STF discussion on 30/11/2010: postpone to 2011.
+
+
+
+ + + + + + + + + + +
+ (0009846) +
+ Gyorgy Rethy    +
+ 30-11-2010 13:30    +
+ 		+ + + + +
+ STF discussion on 30/11/2010: postpone to 2011.
+
+
+
+ + + + + + + + + + +
+ (0009847) +
+ Gyorgy Rethy    +
+ 30-11-2010 13:30    +
+ 		+ + + + +
+ STF discussion on 30/11/2010: postpone to 2011.
+
+
+
+ + + + + + + + + + +
+ (0010038) +
+ Gyorgy Rethy    +
+ 24-05-2011 17:42    +
+ 		+ + + + +
+ To be closed due to lack of input and interest.
+
+
+
+ + + + + + + + + + +
+ (0010039) +
+ Gyorgy Rethy    +
+ 24-05-2011 17:43    +
+ 		+ + + + +
+ Closed due to lack of input.
+
+ + diff --git a/docs/mantis/CR0405.md b/docs/mantis/CR0405.md new file mode 100644 index 0000000000000000000000000000000000000000..edf9e2f176b85e966d23617e375c2bcb4d26ea07 --- /dev/null +++ b/docs/mantis/CR0405.md @@ -0,0 +1,29 @@ + + + + + + + + + + + + + 0000405: Wrong BNF rule for multi-typed module parameters - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0000405Part 01: TTCN-3 Core LanguageTechnicalpublic24-11-2006 14:0112-12-2008 11:50
ReporterStephan Schulz 
Assigned ToStephan Schulz 
PrioritylowSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv2.2.1 (published 2003-02) 
Target Versionv3.1.1 (published 2005-06)Fixed in Versionv3.1.1 (published 2005-06) 
Clause Reference(s)A.1.6.1.12 Module parameter definitions
Source (company - Author)Ina schieferdecker, fokus
Summary0000405: Wrong BNF rule for multi-typed module parameters
DescriptionDescription The current BNF rule for multi-typed module parameters requires always an ending semicolon, even if that is superfluous because of a following closing parenthesis. In addition, a multi-type module parameter definition is not allowed to be empty, which is in conflict to the current language design, where all �elements� may have empty bodies. Proposed Solution Instead of 275. MultitypedModuleParList ::= { ModulePar SemiColon }+ Use 275. MultitypedModuleParList ::= { ModulePar [ SemiColon ] }+ This is consistent with the style the BNF is currently written (e.g. rule 10.) In order to allow empty multi-type module definitions, the following rule should be used: 275. MultitypedModuleParList ::= { ModulePar [ SemiColon ] }
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR_400 Wrong BNF rule for multi-typed module parameters.doc (50,176) 24-11-2006 14:06
http://oldforge.etsi.org/mantis/file_download.php?file_id=37&type=bug
Issue History
Date ModifiedUsernameFieldChange
24-11-2006 14:01Stephan SchulzNew Issue
24-11-2006 14:01Stephan SchulzClause Reference(s) => A.1.6.1.12 Module parameter definitions
24-11-2006 14:01Stephan SchulzSource (company - Author) => Ina schieferdecker, fokus
24-11-2006 14:02Stephan SchulzStatusnew => resolved
24-11-2006 14:02Stephan SchulzFixed in Version => Edition 3.1.1
24-11-2006 14:02Stephan SchulzResolutionopen => fixed
24-11-2006 14:02Stephan SchulzAssigned To => Stephan Schulz
24-11-2006 14:03Stephan SchulzStatusresolved => closed
24-11-2006 14:06Stephan SchulzFile Added: CR_400 Wrong BNF rule for multi-typed module parameters.doc
12-12-2008 11:50Ina SchieferdeckerProduct VersionEdition 3.1.1 => Edition 2.2.1
12-12-2008 11:50Ina SchieferdeckerTarget Version => Edition 3.1.1
12-12-2008 11:50Ina SchieferdeckerDescription Updated
+
+ + + + +
+ There are no notes attached to this issue.
+ + diff --git a/docs/mantis/CR0406.md b/docs/mantis/CR0406.md new file mode 100644 index 0000000000000000000000000000000000000000..bfed54758af156553faaa84cdebaa2b01eadb928 --- /dev/null +++ b/docs/mantis/CR0406.md @@ -0,0 +1,29 @@ + + + + + + + + + + + + + 0000406: Comma-separated list of identifiers for external constants - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0000406Part 01: TTCN-3 Core LanguageTechnicalpublic24-11-2006 14:0512-12-2008 11:51
ReporterStephan Schulz 
Assigned To 
PrioritylowSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv2.2.1 (published 2003-02) 
Target Versionv3.1.1 (published 2005-06)Fixed in Versionv3.1.1 (published 2005-06) 
Clause Reference(s)A.1.6.1.12 Module parameter definitions
Source (company - Author)ina schieferdecker, fokus
Summary0000406: Comma-separated list of identifiers for external constants
DescriptionDescription The current BNF rule for external constants does not allow to have a comma-separated list of identifiers. This is inconsistent to other parts of the language. Proposed Solution Instead of 271. ExtConstDef ::= ExtKeyword ConstKeyword Type ExtConstIdentifier 272. ExtConstIdentifier ::= Identifier Use 271. ExtConstDef ::= ExtKeyword ConstKeyword Type ExtConstIdentifierList 272. ExtConstIdentifierList ::= ExtConstIdentifier { '','' ExtConstIdentifier } 273. ExtConstIdentifier ::= Identifier This is consistent with the style the BNF is currently written.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR_401Comma-separated list of identifiers for external constants.doc (50,688) 24-11-2006 14:05
http://oldforge.etsi.org/mantis/file_download.php?file_id=36&type=bug
Issue History
Date ModifiedUsernameFieldChange
24-11-2006 14:05Stephan SchulzNew Issue
24-11-2006 14:05Stephan SchulzFile Added: CR_401Comma-separated list of identifiers for external constants.doc
24-11-2006 14:05Stephan SchulzClause Reference(s) => A.1.6.1.12 Module parameter definitions
24-11-2006 14:05Stephan SchulzSource (company - Author) => ina schieferdecker, fokus
24-11-2006 14:05Stephan SchulzStatusnew => closed
24-11-2006 14:05Stephan SchulzResolutionopen => fixed
24-11-2006 14:05Stephan SchulzFixed in Version => Edition 3.1.1
12-12-2008 11:51Ina SchieferdeckerProduct VersionEdition 3.1.1 => Edition 2.2.1
12-12-2008 11:51Ina SchieferdeckerTarget Version => Edition 3.1.1
+
+ + + + +
+ There are no notes attached to this issue.
+ + diff --git a/docs/mantis/CR0407.md b/docs/mantis/CR0407.md new file mode 100644 index 0000000000000000000000000000000000000000..fd16ea258254607210adee7465ef32b92d457289 --- /dev/null +++ b/docs/mantis/CR0407.md @@ -0,0 +1,286 @@ + + + + + + + + + + + + + 0000407: Handling of mixed ports in the TTCN-3 core language and in the operational semantics - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0000407Part 01: TTCN-3 Core LanguageTechnicalpublic24-11-2006 14:0812-03-2008 10:24
ReporterStephan Schulz 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.1.1 (published 2005-06) 
Target Versionv3.3.2 (published 2008-04)Fixed in Versionv3.3.2 (published 2008-04) 
Clause Reference(s)8.4.1
Source (company - Author)Jens Grabowski, STF
Summary0000407: Handling of mixed ports in the TTCN-3 core language and in the operational semantics
DescriptionMixed ports are not very well described in the core language and not at all handled in the operational semantics. The submitter does not know any application of mixed ports. The fact that until the publication of the TTCN-3 standard no-one asked for the resolution or clarification of simple questions like: �Is it allowed to connect or map a message- or procedure-based port with a mixed port?� leads to the conclusion that mixed ports are not used.
Steps To Reproduce
Additional InformationIn order to make the language simpler and to remove unused features, mixed ports should be added to the list of depreciated language features (ANNEX G) of ES 201 873-1 v3.1.1 and be removed in a future version of ES 201 873-1.
+
+Proposed Solution:
+No effort should be spent to handle mixed ports in the operational semantics. For the moment the description in clause 8.4.1 in ES 201 873-1 v3.1.1: �A mixed port in TTCN-3 is defined as a shorthand notation for two ports, i.e. a message-based port and a procedure-based port with the same name. At run-time the distinction between the two ports is made by the communication operations. Operations used to control ports (see clause 23.5) i.e. start, stop and clear shall perform the operation on both queues (in arbitrary order) if called with an identifier of a mixed port.� provide enough semantics until mixed ports will be deleted from the language.
+
TagsNo tags attached.
Relationships
Attached Filesdoc CR_407.doc (1,018,880) 19-10-2007 16:34
http://oldforge.etsi.org/mantis/file_download.php?file_id=1066&type=bug
doc CR_407_R1.doc (1,019,392) 05-12-2007 18:24
http://oldforge.etsi.org/mantis/file_download.php?file_id=1225&type=bug
zip CR_407_other_deprecated.zip (884,773) 05-12-2007 19:09
http://oldforge.etsi.org/mantis/file_download.php?file_id=1227&type=bug
doc CR_407_R2_JG_071206.doc (1,020,928) 06-12-2007 16:30
http://oldforge.etsi.org/mantis/file_download.php?file_id=1241&type=bug
Issue History
Date ModifiedUsernameFieldChange
24-11-2006 14:08Stephan SchulzNew Issue
24-11-2006 14:08Stephan SchulzClause Reference(s) => 8.4.1
24-11-2006 14:08Stephan SchulzSource (company - Author) => Jens Grabowski, STF
24-11-2006 14:08Stephan SchulzNote Added: 0000318
24-11-2006 14:08Stephan SchulzStatusnew => confirmed
15-06-2007 19:18Stephan SchulzStatusconfirmed => assigned
15-06-2007 19:18Stephan SchulzAssigned To => Ina Schieferdecker
13-10-2007 19:16Ina SchieferdeckerAssigned ToIna Schieferdecker => developer_u
17-10-2007 12:41user10Assigned Todeveloper_u => Thomas Deiß
18-10-2007 11:11Thomas DeißTarget Version => Edition 3.3.1 (not yet published)
18-10-2007 11:11Thomas DeißDescription Updated
18-10-2007 11:11Thomas DeißAdditional Information Updated
18-10-2007 11:32Thomas DeißFile Added: CR_407.doc
18-10-2007 12:03Thomas DeißNote Added: 0003691
19-10-2007 13:52Thomas DeißFile Deleted: CR_407.doc
19-10-2007 13:52Thomas DeißFile Added: CR_407.doc
19-10-2007 13:54Thomas DeißNote Added: 0003708
19-10-2007 13:54Thomas DeißResolutionopen => fixed
19-10-2007 13:54Thomas DeißAssigned ToThomas Deiß => Jens Grabowski
19-10-2007 16:34Thomas DeißFile Deleted: CR_407.doc
19-10-2007 16:34Thomas DeißFile Added: CR_407.doc
03-12-2007 13:36Jens GrabowskiAssigned ToJens Grabowski => Ina Schieferdecker
04-12-2007 16:40Ina SchieferdeckerStatusassigned => resolved
05-12-2007 10:52Jens GrabowskiAssigned ToIna Schieferdecker => Thomas Deiß
05-12-2007 10:52Jens GrabowskiStatusresolved => feedback
05-12-2007 10:52Jens GrabowskiResolutionfixed => reopened
05-12-2007 10:52Jens GrabowskiNote Added: 0004326
05-12-2007 18:24Thomas DeißFile Added: CR_407_R1.doc
05-12-2007 18:25Thomas DeißNote Added: 0004355
05-12-2007 18:25Thomas DeißStatusfeedback => assigned
05-12-2007 19:09Thomas DeißFile Added: CR_407_other_deprecated.zip
05-12-2007 19:11Thomas DeißNote Added: 0004357
05-12-2007 19:11Thomas DeißAssigned ToThomas Deiß => Jens Grabowski
05-12-2007 19:11Thomas DeißResolutionreopened => fixed
06-12-2007 16:30Jens GrabowskiFile Added: CR_407_R2_JG_071206.doc
06-12-2007 16:43Jens GrabowskiNote Added: 0004395
06-12-2007 16:44Jens GrabowskiAssigned ToJens Grabowski => Ina Schieferdecker
06-12-2007 16:44Jens GrabowskiStatusassigned => resolved
06-12-2007 18:34Ina SchieferdeckerStatusresolved => closed
06-12-2007 18:34Ina SchieferdeckerFixed in Version => Edition 3.3.1 (not yet published)
12-03-2008 10:22user10Fixed in VersionEdition 3.3.1 --will not be published, see 3.3.2 => Edition 3.3.2 (not yet published)
12-03-2008 10:24user10Target VersionEdition 3.3.1 --will not be published, see 3.3.2 => Edition 3.3.2 (not yet published)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0000318) +
+ Stephan Schulz    +
+ 24-11-2006 14:08    +
+ 		+ + + + +
+ Accepted
+
+
+
+ + + + + + + + + + +
+ (0003691) +
+ Thomas Deiß    +
+ 18-10-2007 12:03    +
+ 		+ + + + +
+ Proposed resolution added.
+
+Summary of change:
+
+mixed ports do not occur in part 2, 3, 4, 5, 6. Checked by searching for 'mixed'
+removed explanations and usage from text. Still in BNF and list of keywords.
+Added latest version to all deprecated features.
+
+
+
+ + + + + + + + + + +
+ (0003708) +
+ Thomas Deiß    +
+ 19-10-2007 13:54    +
+ 		+ + + + +
+ this fix contains also some editorial changes to the already existing clauses on deprecated features:
+mention the last version where the feature was supported
+weaken the statement that the feature is planned to be removed.
+
+
+
+ + + + + + + + + + +
+ (0004326) +
+ Jens Grabowski    +
+ 05-12-2007 10:52    +
+ 		+ + + + +
+ Check for all other deprecated features.
+
+
+
+ + + + + + + + + + +
+ (0004355) +
+ Thomas Deiß    +
+ 05-12-2007 18:25    +
+ 		+ + + + +
+ missed an occurrence of mixed in the explanation of the check operation, clause 22.4. Corrected in CR_407_R1.
+
+
+
+ + + + + + + + + + +
+ (0004357) +
+ Thomas Deiß    +
+ 05-12-2007 19:11    +
+ 		+ + + + +
+ Second solution file added, that removes explanation of deprecated features from the main text. The features are still in the BNF.
+
+the changes affect following clauses:
+group style of module pars: 8.2.1
+recursive import: 8.2.3
+inout all: 9.1
+
+
+
+ + + + + + + + + + +
+ (0004395) +
+ Jens Grabowski    +
+ 06-12-2007 16:43    +
+ 		+ + + + +
+ Ina, I crosschecked the text from Thomas. Both texts, i.e., the one in CR_407_other_deprecated.zip and CR_407_R2_JG_071206.doc have to be included in Part 1 of the standard.
+
+Thomas agreed already to the small changes I made in CR_407_R2_JG_071206.doc.
+
+ + diff --git a/docs/mantis/CR0408.md b/docs/mantis/CR0408.md new file mode 100644 index 0000000000000000000000000000000000000000..5cbdba7e739110c73991f3c72466a6cd42532c6d --- /dev/null +++ b/docs/mantis/CR0408.md @@ -0,0 +1,104 @@ + + + + + + + + + + + + + 0000408: System Exceptions - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 08: Using IDL with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0000408Part 08: Using IDL with TTCN-3New Featurepublic24-11-2006 14:1106-12-2007 14:51
ReporterStephan Schulz 
Assigned ToIna Schieferdecker 
PriorityhighSeverityfeatureReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.2.1 (published 2007-02) 
Target Versionv3.3.1 (published 2008-04)Fixed in Versionv3.3.1 (published 2008-04) 
Clause Reference(s)Clause 10, Annex A, Annex C
Source (company - Author)Thomas Deiss, nokia
Summary0000408: System Exceptions
DescriptionExceptions of (IDL) operations are mapped to corresponding exception clauses of TTCN-3 signatures. This way only user exceptions can be raised or caught. But it is not possible to raise or catch CORBA system exceptions, as this is not contained in the TTCN-3 signatures. The GIOP allows to transport also system exceptions, this is a technical prerequisite such that raising system exceptions in a test system makes sense at all. The CR consists of an extension of the mapping (Clause 10, Annex A) and a definition of a TTCN-3 type for system exceptions (Annex C)
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Fileszip es_20187308v030301_CR408.zip (107,549) 05-12-2007 14:53
http://oldforge.etsi.org/mantis/file_download.php?file_id=1217&type=bug
doc es_20187308v030301_CR408_a.doc (529,408) 06-12-2007 11:22
http://oldforge.etsi.org/mantis/file_download.php?file_id=1232&type=bug
Issue History
Date ModifiedUsernameFieldChange
24-11-2006 14:11Stephan SchulzNew Issue
24-11-2006 14:11Stephan SchulzClause Reference(s) => Clause 10, Annex A, Annex C
24-11-2006 14:11Stephan SchulzSource (company - Author) => Thomas Deiss, nokia
15-06-2007 19:17Stephan SchulzStatusnew => assigned
15-06-2007 19:17Stephan SchulzAssigned To => Ina Schieferdecker
18-10-2007 14:31Ina SchieferdeckerTarget Version => Edition 3.3.1 (not yet published)
05-12-2007 14:53Ina SchieferdeckerFile Added: es_20187308v030301_CR408.zip
05-12-2007 14:55Ina SchieferdeckerNote Added: 0004337
05-12-2007 14:55Ina SchieferdeckerResolutionopen => fixed
05-12-2007 15:41Ina SchieferdeckerAssigned ToIna Schieferdecker => Thomas Deiß
06-12-2007 11:22Thomas DeißFile Added: es_20187308v030301_CR408_a.doc
06-12-2007 11:24Thomas DeißNote Added: 0004368
06-12-2007 11:24Thomas DeißAssigned ToThomas Deiß => Ina Schieferdecker
06-12-2007 14:50Ina SchieferdeckerStatusassigned => resolved
06-12-2007 14:51Ina SchieferdeckerStatusresolved => closed
06-12-2007 14:51Ina SchieferdeckerFixed in Version => Edition 3.3.1 (not yet published)
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0004337) +
+ Ina Schieferdecker    +
+ 05-12-2007 14:55    +
+ 		+ + + + +
+ The sytem exceptions have been defined in claus 9. All signature definitions have been extended accordingly.
+
+In addition, the use of universal char has been fixed.
+
+Furthermore, the use of address has been fixed.
+
+
+
+ + + + + + + + + + +
+ (0004368) +
+ Thomas Deiß    +
+ 06-12-2007 11:24    +
+ 		+ + + + +
+ checked by Thomas. Additional union type on all system exceptions defined. This one to be crosschecked by Ina.
+
+Otherwise the solution is ok.
+
+
+ + diff --git a/docs/mantis/CR0409.md b/docs/mantis/CR0409.md new file mode 100644 index 0000000000000000000000000000000000000000..def059033a1296722dbdaa4526d61fd063b9992e --- /dev/null +++ b/docs/mantis/CR0409.md @@ -0,0 +1,63 @@ + + + + + + + + + + + + + 0000409: New TCI-TM required operation, tciStopTE - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0000409Part 06: TTCN-3 Control InterfaceNew Featurepublic24-11-2006 14:1212-12-2008 11:37
ReporterStephan Schulz 
Assigned To 
PrioritynormalSeverityfeatureReproducibilityN/A
StatusclosedResolutionwon't fix 
PlatformOSOS Version
Product Versionv3.1.1 (published 2005-06) 
Target Versionv3.2.1 (published 2007-02)Fixed in Version 
Clause Reference(s)Reference to clause(s) and/or subclause(s) related to CR
Source (company - Author)andreas nyberg, nokia
Summary0000409: New TCI-TM required operation, tciStopTE
DescriptionSupport for standardized shut down functionality for a test/TTCN-3 executable from a test management application. It would make sense to be able to shut down the TE over the TCI and at the same time allowing the TE to perform a gentle shut down.
Steps To Reproduce
Additional InformationAdd an operation tciStopTE to the TCI-TM required section of the TCI standard. Signature: void tciStopTE() Return Value: void Constraint: Shall only be used if the TE is up and running. Effect: tciStopTE indicates to the TE that is should invoke its shut down procedure immediately, which also includes stopping any executing test case.
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
24-11-2006 14:12Stephan SchulzNew Issue
24-11-2006 14:12Stephan SchulzClause Reference(s) => Reference to clause(s) and/or subclause(s) related to CR
24-11-2006 14:12Stephan SchulzSource (company - Author) => andreas nyberg, nokia
24-11-2006 14:13Stephan SchulzStatusnew => closed
24-11-2006 14:13Stephan SchulzNote Added: 0000319
24-11-2006 14:13Stephan SchulzResolutionopen => won't fix
12-12-2008 11:37Ina SchieferdeckerTarget Version => Edition 3.2.1
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0000319) +
+ Stephan Schulz    +
+ 24-11-2006 14:13    +
+ 		+ + + + +
+ Rejected. TCIStopTC and TCIStopControl already exist for gentle shut down
+
+ + diff --git a/docs/mantis/CR0410.md b/docs/mantis/CR0410.md new file mode 100644 index 0000000000000000000000000000000000000000..d42e97b70de1ec88818d52e9a2f4a39434d83394 --- /dev/null +++ b/docs/mantis/CR0410.md @@ -0,0 +1,30 @@ + + + + + + + + + + + + + 0000410: Adding select-case-statement to operational semantics - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 04: TTCN-3 Operational Semantics
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0000410Part 04: TTCN-3 Operational SemanticsTechnicalpublic24-11-2006 14:1712-12-2008 11:41
ReporterStephan Schulz 
Assigned To 
PriorityhighSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.1.1 (published 2005-06) 
Target Versionv3.1.1 (published 2005-06)Fixed in Versionv3.1.1 (published 2005-06) 
Clause Reference(s)all
Source (company - Author)Jens Grabowski, STF
Summary0000410: Adding select-case-statement to operational semantics
DescriptionThe select-case statement has been newly introduced into the TTCN-3 Core Language v3.1.1. The meaning of this new construct is not explained in the operational semantics.
Steps To Reproduce
Additional InformationProposed Solution:
+Introduce the select-case statement as a shorthand form for a set of nested if-else-statements.
TagsNo tags attached.
Relationships
Attached Filesdoc CR_413 Adding select-case-statement to operational semantics.doc (87,552) 24-11-2006 14:20
http://oldforge.etsi.org/mantis/file_download.php?file_id=38&type=bug
Issue History
Date ModifiedUsernameFieldChange
24-11-2006 14:17Stephan SchulzNew Issue
24-11-2006 14:17Stephan SchulzClause Reference(s) => all
24-11-2006 14:17Stephan SchulzSource (company - Author) => Jens Grabowski, STF
24-11-2006 14:17Stephan SchulzStatusnew => closed
24-11-2006 14:17Stephan SchulzResolutionopen => fixed
24-11-2006 14:17Stephan SchulzFixed in Version => Edition 3.1.1
24-11-2006 14:20Stephan SchulzFile Added: CR_413 Adding select-case-statement to operational semantics.doc
12-12-2008 11:41Ina SchieferdeckerTarget Version => Edition 3.1.1
+
+ + + + +
+ There are no notes attached to this issue.
+ + diff --git a/docs/mantis/CR0411.md b/docs/mantis/CR0411.md new file mode 100644 index 0000000000000000000000000000000000000000..f084402949499f152c0fed1bed950e67ed9ba2ff --- /dev/null +++ b/docs/mantis/CR0411.md @@ -0,0 +1,373 @@ + + + + + + + + + + + + + 0000411: Formal parameter default values (non-mandatory parameters) - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 04: TTCN-3 Operational Semantics
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0000411Part 04: TTCN-3 Operational SemanticsNew Featurepublic24-11-2006 14:2320-04-2009 11:42
ReporterStephan Schulz 
Assigned ToJens Grabowski 
PriorityhighSeverityfeatureReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.1.1 (published 2005-06) 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s) Annex A
Source (company - Author)dr. György Réthy, Ericsson
Summary0000411: Formal parameter default values (non-mandatory parameters)
DescriptionDevelopment of test suites and TTCN-3 libraries is normally an incremental process. In parallel with the development of the SUT, also "old" test suites has to be upgraded and new functionalities has to be added to library functions/altsteps. This very often requires adding of new formal parameters to existing templates, functions, altsteps or testcases. Today it is impossible add new parameters and preserve backward compatibility at the same time.
+Users consider this to be a significant drawback of TTCN-3 today.
+
+Currently two workarounds are used:
+1) Types of formal parameters are defined as records; parameterized objects have a single formal parameter of such record type; when a new parameter to be added, a new optional field is added to the related record type. This approach, though provides backward compatibility, has significant drawbacks: decreases coding efficiency and execution performance and increases code size. For almost all parameterized object an additional record type shall be added to the test suite. Syntax of actual parameter lists are more complex, access to the parameter values inside the object requires a more complex syntax and often extra assignments are needed (e.g. to assign a (received) value into a variable field of the formal parameter type before calling a template or function instead of passing it directly).
+2) Cloning: copying an existing parameterized object into a new definition, changing its name and adding new formal parameters. Often the copied objects are big but the needed changes are small. This workaround increases the code size significantly, hence decreases tool and execution efficiency and, on long term, leads to a so called "spaghetti" code that is difficult and very laborious to maintain (if something has to be changed in the merely-copied part of the code, it has to be changed in several cloned objects; but often it is even difficult to identify which objects are the clones). Some of our users decided to change from TTCN-2 to TTCN-3 because of this effect (and re-write the old code, but now they are facing the same situation).
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0000417closed Ina Schieferdecker Part 01: TTCN-3 Core Language Assignment notation in actual parameter lists 
Attached Filesdoc CR_406 Formal parameter default values (non-mandatory parameters).doc (66,048) 24-11-2006 14:23
http://oldforge.etsi.org/mantis/file_download.php?file_id=39&type=bug
ppt General_Extension_status_13_08_08_default_values.ppt (48,640) 14-08-2008 12:28
http://oldforge.etsi.org/mantis/file_download.php?file_id=1597&type=bug
doc CR_411_417_Formal_parameter_default_values_part1_01.doc (1,310,720) 17-10-2008 09:24
http://oldforge.etsi.org/mantis/file_download.php?file_id=1709&type=bug
doc CR_411_417_Formal_parameter_default_values_part4_01.doc (199,680) 17-10-2008 09:25
http://oldforge.etsi.org/mantis/file_download.php?file_id=1710&type=bug
doc CR_411_417_Formal_parameter_default_values_part6_01.doc (340,480) 17-10-2008 09:25
http://oldforge.etsi.org/mantis/file_download.php?file_id=1711&type=bug
doc CR_411_417_Formal_parameter_default_values_part1_02.doc (1,314,304) 26-11-2008 15:27
http://oldforge.etsi.org/mantis/file_download.php?file_id=1791&type=bug
doc CR_411_417_Formal_parameter_default_values_part4_02.doc (201,728) 26-11-2008 15:27
http://oldforge.etsi.org/mantis/file_download.php?file_id=1792&type=bug
doc CR_411_417_Formal_parameter_default_values_part4_03.doc (201,728) 27-11-2008 08:31
http://oldforge.etsi.org/mantis/file_download.php?file_id=1807&type=bug
doc CR_411_417_Formal_parameter_default_values_part1_03.doc (1,317,376) 27-11-2008 08:32
http://oldforge.etsi.org/mantis/file_download.php?file_id=1808&type=bug
Issue History
Date ModifiedUsernameFieldChange
24-11-2006 14:23Stephan SchulzNew Issue
24-11-2006 14:23Stephan SchulzFile Added: CR_406 Formal parameter default values (non-mandatory parameters).doc
24-11-2006 14:23Stephan SchulzClause Reference(s) => Annex A
24-11-2006 14:23Stephan SchulzSource (company - Author) => dr. György Réthy, Ericsson
24-11-2006 14:37Stephan SchulzRelationship addedrelated to 0000417
15-06-2007 19:16Stephan SchulzStatusnew => assigned
15-06-2007 19:16Stephan SchulzAssigned To => Ina Schieferdecker
13-10-2007 19:18Ina SchieferdeckerAssigned ToIna Schieferdecker => developer_u
15-10-2007 12:56Ina SchieferdeckerNote Added: 0003611
17-10-2007 11:48Ina SchieferdeckerNote Added: 0003660
17-10-2007 12:41user10Assigned Todeveloper_u => Thomas Deiß
18-10-2007 11:35Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
18-10-2007 11:54Ina SchieferdeckerNote Deleted: 0003611
14-08-2008 12:28Thomas DeißFile Added: General_Extension_status_13_08_08_default_values.ppt
17-10-2008 09:24Thomas DeißFile Added: CR_411_417_Formal_parameter_default_values_part1_01.doc
17-10-2008 09:25Thomas DeißFile Added: CR_411_417_Formal_parameter_default_values_part4_01.doc
17-10-2008 09:25Thomas DeißFile Added: CR_411_417_Formal_parameter_default_values_part6_01.doc
17-10-2008 09:26Thomas DeißAssigned ToThomas Deiß => Gyorgy Rethy
26-11-2008 15:18Gyorgy RethyFile Added: CR_411_417_Formal_parameter_default_values_part1_01 v2.doc
26-11-2008 15:19Gyorgy RethyFile Deleted: CR_411_417_Formal_parameter_default_values_part1_01 v2.doc
26-11-2008 15:26Gyorgy RethyNote Added: 0007452
26-11-2008 15:27Gyorgy RethyFile Added: CR_411_417_Formal_parameter_default_values_part1_02.doc
26-11-2008 15:27Gyorgy RethyFile Added: CR_411_417_Formal_parameter_default_values_part4_02.doc
26-11-2008 15:28Gyorgy RethyAssigned ToGyorgy Rethy => Thomas Deiß
26-11-2008 15:28Gyorgy RethyNote Edited: 0007452
27-11-2008 08:28Thomas DeißFile Added: CR_411_417_Formal_parameter_default_values_part1_03.doc
27-11-2008 08:28Thomas DeißFile Deleted: CR_411_417_Formal_parameter_default_values_part1_03.doc
27-11-2008 08:30Thomas DeißFile Added: CR_412_2012_BehaviourTypes_03.doc
27-11-2008 08:31Thomas DeißFile Added: CR_411_417_Formal_parameter_default_values_part4_03.doc
27-11-2008 08:31Thomas DeißFile Deleted: CR_412_2012_BehaviourTypes_03.doc
27-11-2008 08:32Thomas DeißFile Added: CR_411_417_Formal_parameter_default_values_part1_03.doc
27-11-2008 08:34Thomas DeißNote Added: 0007464
27-11-2008 08:34Thomas DeißAssigned ToThomas Deiß => Ina Schieferdecker
09-12-2008 18:01Ina SchieferdeckerNote Added: 0007610
09-12-2008 18:02Ina SchieferdeckerResolutionopen => fixed
09-12-2008 18:12Ina SchieferdeckerNote Added: 0007611
09-12-2008 18:12Ina SchieferdeckerAssigned ToIna Schieferdecker => Thomas Deiß
09-12-2008 18:13Ina SchieferdeckerNote Edited: 0007611
10-12-2008 07:37Thomas DeißNote Added: 0007616
10-12-2008 07:37Thomas DeißAssigned ToThomas Deiß => Ina Schieferdecker
10-12-2008 10:40Ina SchieferdeckerNote Added: 0007623
10-12-2008 10:40Ina SchieferdeckerAssigned ToIna Schieferdecker => Thomas Deiß
10-12-2008 10:56Thomas DeißNote Added: 0007625
10-12-2008 10:56Thomas DeißAssigned ToThomas Deiß => Ina Schieferdecker
10-12-2008 12:33Ina SchieferdeckerNote Added: 0007628
10-12-2008 12:33Ina SchieferdeckerAssigned ToIna Schieferdecker => Jens Grabowski
10-12-2008 12:33Ina SchieferdeckerProjectPart 01: TTCN-3 Core Language => Part 04: TTCN-3 Operational Semantics
10-03-2009 10:51Ina SchieferdeckerStatusassigned => resolved
10-03-2009 10:51Ina SchieferdeckerFixed in Version => Edition 4.1.1 (not yet published)
20-04-2009 11:42Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0003660) +
+ Ina Schieferdecker    +
+ 17-10-2007 11:48    +
+ 		+ + + + +
+ to be considered with CR 417 - deferred to 2008
+
+
+
+ + + + + + + + + + +
+ (0007452) +
+ Gyorgy Rethy    +
+ 26-11-2008 15:26    +
(edited on: 26-11-2008 15:28)
+ 		+ + + + +
+ Added: default values of component and default parameters shall be the null value. Some minor editorial changes (see the ~_02 versions).
+
+
+
+
+
+ + + + + + + + + + +
+ (0007464) +
+ Thomas Deiß    +
+ 27-11-2008 08:34    +
+ 		+ + + + +
+ part1
+references to type parameterization removed.
+default values of type default can just be 'null'
+default values of component types can just be null, system, mtc, self.
+
+part4: typo corrected
+
+v03 of part1 and part 4 uploaded
+
+
+
+ + + + + + + + + + +
+ (0007610) +
+ Ina Schieferdecker    +
+ 09-12-2008 18:01    +
+ 		+ + + + +
+ Part 1 edited according to the changes except of default values for type parameters as those go into the "Advanced parameterization package"
+
+
+
+ + + + + + + + + + +
+ (0007611) +
+ Ina Schieferdecker    +
+ 09-12-2008 18:12    +
(edited on: 09-12-2008 18:13)
+ 		+ + + + +
+ I propose that default values of parameters are to be resolved by the TE and would hence not be visible at the TCI. Therefore, no change to the TCI would be needed. Please check.
+
+
+
+
+
+ + + + + + + + + + +
+ (0007616) +
+ Thomas Deiß    +
+ 10-12-2008 07:37    +
+ 		+ + + + +
+ If it is not visible at the TCI whether a parameter is a default parameter or not, then for testcases the TCI-TM will have to consider all test case parameters as mandatory. The TM cannot know for which parameters it has to provide a value and for which other ones this is not needed (and would be provided by the TE).
+
+For the start test component operation there is no problem if the TCI-CH does not know whether a parameter has a default value or not, the calling component will provide values for all parameters.
+
+For me it would be ok to leave part6 untouched, it should not hurt the users if they have to provide actual parameters for each test case parameter.
+
+
+
+ + + + + + + + + + +
+ (0007623) +
+ Ina Schieferdecker    +
+ 10-12-2008 10:40    +
+ 		+ + + + +
+ Consider the statements
+
+"e) The expression of the default value has to be compatible with the type of the parameter. The expression shall not refer to elements of the component type of the optional runs on clause. The expression shall not refer to other parameters of the same parameter list. The expression shall not contain the invocation of functions with a runs on clause."
+
+and
+
+"d) The template instance has to be compatible with the type of the parameter. For type compatibility see clause 6.4. The template instance may refer to elements of the component type in a runs on clause. The template instance shall not refer to other parameters in the same parameter list."
+
+in CR_411_417_Formal_parameter_default_values_part1_03.doc
+
+However, expressions and template instances should basically be treated the same.
+
+
+Hence, to be changed to
+
+"d) The default template instance has to be compatible with the type of the parameter. The template instance shall not refer to elements of the component type in a runs on clause. The template instance shall not refer to other parameters in the same parameter list. The template instance shall not contain the invocation of functions with a runs on clause."
+
+Please check.
+
+
+
+ + + + + + + + + + +
+ (0007625) +
+ Thomas Deiß    +
+ 10-12-2008 10:56    +
+ 		+ + + + +
+ ok.
+
+
+
+ + + + + + + + + + +
+ (0007628) +
+ Ina Schieferdecker    +
+ 10-12-2008 12:33    +
+ 		+ + + + +
+ Jens, please add the changes to part 4.
+
+ + diff --git a/docs/mantis/CR0412.md b/docs/mantis/CR0412.md new file mode 100644 index 0000000000000000000000000000000000000000..137a46df0934aeba2b1340fdc7e2c75bdebb089d --- /dev/null +++ b/docs/mantis/CR0412.md @@ -0,0 +1,713 @@ + + + + + + + + + + + + + 0000412: Function reference - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0000412Part 01: TTCN-3 Core LanguageNew Featurepublic24-11-2006 14:2604-09-2009 09:43
ReporterStephan Schulz 
Assigned ToTibor Csöndes 
PriorityhighSeverityfeatureReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.1.1 (published 2005-06) 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.2.1 (published 2010-07) 
Clause Reference(s)several
Source (company - Author)dr. György Réthy, Ericsson
Summary0000412: Function reference
DescriptionTTCN-3 today still supports rigid behaviours, primarily props up conformance/function testing where the expected behaviour is known a-priory. To solve tasks, where the details of the behaviour are of secondary importance and changes dynamically during test execution, are cumbersome, not user friendly and leads to huge code, which is difficult to develop and maintain. One of the main problems is that TTCN-3 dynamic elements can not be parameterized with a dynamic behaviour (e.g. with a function or altstep).
+Two examples, where users do suffer from this limitation:
+1) Test configuration
+At the beginning of each test case the test configuration has to be set up. Typical test suites use very limited number ? one or two ? different test configurations which are established by calling a specific function. Today such functions can establish static test configuration only, all PTC behaviours shall be started from the test case. In typical test configurations behaviour of some PTCs depend on the test case, while others do not (e.g. routing, handling lower layer protocols etc.).
+Testers very often get configuration functions in libraries but they have to worry about starting all PTC behaviours. The complete and library-conform solution would be if they could just pass the functions to be started on test case-dependent PTCs to the (library) configuration function and all other actions are done by the library function.
+2) Flexible default handling
+Defaults depend on the state of the IUT/SUT. Therefore when the state changes often some defaults shall be de-activated and new ones activated. Functions called in a given state are often written in a protocol-independent way to increase re-usability, therefore they have no knowledge about the default to be activated. Hence it shall be passed in runtime, as parameter (testers often get function/altsteps ready that they have just to use. In principle passing in just the default reference could be a solution, however this would decrease the ?structured-ness? of the code and force the tester to handle default states that he/she should not if function reference existed).
+3) Load and robustness tests
+In both load and robustness tests, during test execution a vast number of entities (e.g. users, transaction sessions etc.) shall be emulated (the two types of testing mainly differs in their time profiles). The exact behaviour of an entity is unknown a-priory, e.g. it executes a state machine (calling a busy B-user or requesting info of an unregistered user are normal events in these cases). When e.g. a great number of entities shall be released, there is wrapper function handling the local release of an entity (in local databases, event queues etc.), while the exact message-level behaviour is described by an entity & state-dependent function. To solve the task efficiently the wrapper function should get the state-dependent function runtime, as parameter. Note, that several protocols may be involved in such scenarios. Therefore just passing the state of the entity into the wrapper function would result a very complex, unstructured, user-unfriendly and project-dependent code that is difficult to maintain and upgrade.
+4) Using libraries
+In the library approach there are horizontal and vertical splitting exists. Example of horizontal splitting is the libraries containing functions of different protocols? elementary behaviours. Vertical splitting means different levels of abstraction; examples are libraries containing more generic, protocol-independent functions (e.g. scheduling, mass releases, handling hashes etc.). Actual test cases shall be assembled from these libraries, where library functions can be used but cannot be changed by testers. As the generic functions shall be protocol-independent, it is quite obvious, that for many tasks the generic functions shall get the partial protocol behaviour runtime, as an actual parameter.
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0002012closed Gyorgy Rethy runs on self clause in function reference types 
related to 0004275closed Ina Schieferdecker New Concepts to be defined via Packages 
Attached Filesdoc CR_407 Function_reference.doc (118,272) 24-11-2006 14:26
http://oldforge.etsi.org/mantis/file_download.php?file_id=40&type=bug
doc CR_412_2012_BehaviourTypes_01.doc (392,704) 17-10-2008 10:13
http://oldforge.etsi.org/mantis/file_download.php?file_id=1712&type=bug
doc CR_412_2012_BehaviourTypes_02.doc (378,880) 25-11-2008 07:55
http://oldforge.etsi.org/mantis/file_download.php?file_id=1763&type=bug
doc CR_412_2012_BehaviourTypes_03.doc (382,976) 26-11-2008 13:59
http://oldforge.etsi.org/mantis/file_download.php?file_id=1788&type=bug
doc CR_412_2012_BehaviourTypes_04.doc (392,192) 28-11-2008 13:44
http://oldforge.etsi.org/mantis/file_download.php?file_id=1836&type=bug
doc CR_412_2012_BehaviourTypes_05.doc (420,864) 09-01-2009 12:07
http://oldforge.etsi.org/mantis/file_download.php?file_id=1939&type=bug
doc CR_412_2012_BehaviourTypes_06.doc (421,888) 09-01-2009 15:07
http://oldforge.etsi.org/mantis/file_download.php?file_id=1940&type=bug
doc CR_412_2012_BehaviourTypes_07.doc (425,984) 12-01-2009 16:08
http://oldforge.etsi.org/mantis/file_download.php?file_id=1945&type=bug
doc CR_412_2012_BehaviourTypes_071.doc (427,008) 14-01-2009 14:38
http://oldforge.etsi.org/mantis/file_download.php?file_id=1953&type=bug
doc CR_412_2012_BehaviourTypes_072.doc (512,000) 15-01-2009 07:08
http://oldforge.etsi.org/mantis/file_download.php?file_id=1955&type=bug
doc CR_412_2012_BehaviourTypes_073.doc (509,952) 15-01-2009 08:02
http://oldforge.etsi.org/mantis/file_download.php?file_id=1957&type=bug
doc CR_412_2012_BehaviourTypes_08.doc (530,432) 16-01-2009 15:10
http://oldforge.etsi.org/mantis/file_download.php?file_id=1959&type=bug
doc CR_412_2012_BehaviourTypes_081.doc (530,944) 26-01-2009 16:29
http://oldforge.etsi.org/mantis/file_download.php?file_id=1977&type=bug
doc es202785_BehaviourTypes_210409.doc (1,024,512) 21-04-2009 09:38
http://oldforge.etsi.org/mantis/file_download.php?file_id=2093&type=bug
doc es202785_BehaviourTypes_300609.doc (1,334,784) 30-06-2009 11:41
http://oldforge.etsi.org/mantis/file_download.php?file_id=2142&type=bug
doc es202785_BehaviourTypes_020909.doc (1,325,056) 04-09-2009 09:42
http://oldforge.etsi.org/mantis/file_download.php?file_id=2238&type=bug
Issue History
Date ModifiedUsernameFieldChange
24-11-2006 14:26Stephan SchulzNew Issue
24-11-2006 14:26Stephan SchulzFile Added: CR_407 Function_reference.doc
24-11-2006 14:26Stephan SchulzClause Reference(s) => several
24-11-2006 14:26Stephan SchulzSource (company - Author) => dr. György Réthy, Ericsson
15-06-2007 19:16Stephan SchulzStatusnew => assigned
15-06-2007 19:16Stephan SchulzAssigned To => Ina Schieferdecker
13-10-2007 19:19Ina SchieferdeckerAssigned ToIna Schieferdecker => developer_u
15-10-2007 13:22Ina SchieferdeckerNote Added: 0003613
17-10-2007 12:41user10Assigned Todeveloper_u => Thomas Deiß
18-10-2007 12:12Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
18-10-2007 12:12Ina SchieferdeckerDescription Updated
17-10-2008 10:13Thomas DeißFile Added: CR_412_2012_BehaviourTypes_01.doc
17-10-2008 10:16Thomas DeißNote Added: 0007114
17-10-2008 15:38Ina SchieferdeckerRelationship addedrelated to 0002012
25-11-2008 07:55Thomas DeißFile Added: CR_412_2012_BehaviourTypes_02.doc
25-11-2008 07:57Thomas DeißNote Added: 0007394
26-11-2008 13:59Thomas DeißFile Added: CR_412_2012_BehaviourTypes_03.doc
26-11-2008 14:00Thomas DeißNote Added: 0007448
28-11-2008 13:44Thomas DeißFile Added: CR_412_2012_BehaviourTypes_04.doc
28-11-2008 13:46Thomas DeißNote Added: 0007505
28-11-2008 13:46Thomas DeißAssigned ToThomas Deiß => Gyorgy Rethy
12-12-2008 09:04Ina SchieferdeckerRelationship addedrelated to 0004275
09-01-2009 12:07Gyorgy RethyFile Added: CR_412_2012_BehaviourTypes_05.doc
09-01-2009 12:09Gyorgy RethyNote Added: 0007808
09-01-2009 12:11Gyorgy RethyAssigned ToGyorgy Rethy => Thomas Deiß
09-01-2009 15:07Thomas DeißFile Added: CR_412_2012_BehaviourTypes_06.doc
09-01-2009 15:10Thomas DeißNote Added: 0007812
09-01-2009 15:11Thomas DeißNote Added: 0007813
09-01-2009 15:11Thomas DeißAssigned ToThomas Deiß => Ina Schieferdecker
12-01-2009 16:08Gyorgy RethyFile Added: CR_412_2012_BehaviourTypes_07.doc
12-01-2009 16:10Gyorgy RethyNote Added: 0007822
14-01-2009 14:38Thomas DeißFile Added: CR_412_2012_BehaviourTypes_071.doc
14-01-2009 14:40Thomas DeißNote Added: 0007839
15-01-2009 07:08Thomas DeißFile Added: CR_412_2012_BehaviourTypes_072.doc
15-01-2009 07:09Thomas DeißNote Added: 0007863
15-01-2009 08:02Thomas DeißFile Added: CR_412_2012_BehaviourTypes_073.doc
15-01-2009 08:02Thomas DeißNote Added: 0007865
16-01-2009 15:10Thomas DeißFile Added: CR_412_2012_BehaviourTypes_08.doc
16-01-2009 15:11Thomas DeißNote Added: 0007874
26-01-2009 16:29Thomas DeißFile Added: CR_412_2012_BehaviourTypes_081.doc
26-01-2009 16:31Thomas DeißNote Added: 0007932
10-03-2009 10:47Ina SchieferdeckerStatusassigned => resolved
10-03-2009 10:47Ina SchieferdeckerResolutionopen => fixed
10-03-2009 10:47Ina SchieferdeckerFixed in Version => Edition 4.1.1 (not yet published)
21-04-2009 09:24Ina SchieferdeckerFile Added: es202785_BehaviourTypes_210409.doc
21-04-2009 09:25Ina SchieferdeckerNote Added: 0008519
21-04-2009 09:25Ina SchieferdeckerStatusresolved => assigned
21-04-2009 09:25Ina SchieferdeckerAssigned ToIna Schieferdecker => Jens Grabowski
21-04-2009 09:26Ina SchieferdeckerNote Added: 0008520
21-04-2009 09:37Ina SchieferdeckerFile Deleted: es202785_BehaviourTypes_210409.doc
21-04-2009 09:38Ina SchieferdeckerFile Added: es202785_BehaviourTypes_210409.doc
30-06-2009 11:41Jens GrabowskiFile Added: es202785_BehaviourTypes_300609.doc
30-06-2009 11:42Jens GrabowskiNote Added: 0008798
30-06-2009 11:43Jens GrabowskiAssigned ToJens Grabowski => Gyorgy Rethy
01-09-2009 15:50Gyorgy RethyNote Added: 0008953
01-09-2009 15:51Gyorgy RethyNote Edited: 0008953
01-09-2009 15:51Gyorgy RethyAssigned ToGyorgy Rethy => Tibor Csöndes
02-09-2009 16:31Tibor CsöndesStatusassigned => closed
02-09-2009 16:31Tibor CsöndesNote Added: 0008964
02-09-2009 16:31Tibor CsöndesFixed in VersionEdition 4.1.1 Published 2009-06-02 => Edition 4.2.1 (not yet published)
04-09-2009 09:41Tibor CsöndesStatusclosed => feedback
04-09-2009 09:41Tibor CsöndesResolutionfixed => reopened
04-09-2009 09:42Tibor CsöndesFile Added: es202785_BehaviourTypes_020909.doc
04-09-2009 09:43Tibor CsöndesStatusfeedback => closed
04-09-2009 09:43Tibor CsöndesResolutionreopened => fixed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0003613) +
+ Ina Schieferdecker    +
+ 15-10-2007 13:22    +
+ 		+ + + + +
+ to be considered in 2008 only - what about pointers in general, how does it relate to defaulttype etc.
+
+
+
+ + + + + + + + + + +
+ (0007114) +
+ Thomas Deiß    +
+ 17-10-2008 10:16    +
+ 		+ + + + +
+ still open
+functions <-> function references
+(in)equality, null function (reference)
+operational semantics: just one example to show how it could be done. Needs to be repeated for other operations too
+TCI: BehaviourIdtype in IDL, needs to be reflected in language mappings, too. At least this needs to be checked.
+
+
+
+ + + + + + + + + + +
+ (0007394) +
+ Thomas Deiß    +
+ 25-11-2008 07:57    +
+ 		+ + + + +
+ editorial corrections.
+usage of prototypes in behaviour definitions removed for the sake of simplicity.
+subtypes of behaviour types removed for the sake of simplicity.
+null value and comparison added as requested by users.
+
+
+
+ + + + + + + + + + +
+ (0007448) +
+ Thomas Deiß    +
+ 26-11-2008 14:00    +
+ 		+ + + + +
+ problem in grammar corrected. The BNF should also be simpler now.
+The problem was to actually reach a defined function name in a function instance.
+v03 uploaded.
+
+
+
+ + + + + + + + + + +
+ (0007505) +
+ Thomas Deiß    +
+ 28-11-2008 13:46    +
+ 		+ + + + +
+ Proposal for review.
+Feedback is needed on
+a) the proposal itself (technical part)
+b) the proposal regarding clarity of description (more introduction needed?)
+c) usage of extension packages.
+
+
+
+
+ + + + + + + + + + +
+ (0007808) +
+ Gyorgy Rethy    +
+ 09-01-2009 12:09    +
+ 		+ + + + +
+ The file CR_412_2012_BehaviourTypes_05.doc contains minor technical and editorial corrections but as a whole it is OK.
+
+
+
+ + + + + + + + + + +
+ (0007812) +
+ Thomas Deiß    +
+ 09-01-2009 15:10    +
+ 		+ + + + +
+ some further (minor) editorial corrections.
+
+Usage of 'object' instead of 'value' to be checked.
+
+
+
+ + + + + + + + + + +
+ (0007813) +
+ Thomas Deiß    +
+ 09-01-2009 15:11    +
+ 		+ + + + +
+ all of us should review the extension package
+
+
+
+ + + + + + + + + + +
+ (0007822) +
+ Gyorgy Rethy    +
+ 12-01-2009 16:10    +
+ 		+ + + + +
+ ~07.doc: just a few editorials, changes are marked with yellow background. With these changes it is OK with me.
+
+
+
+ + + + + + + + + + +
+ (0007839) +
+ Thomas Deiß    +
+ 14-01-2009 14:40    +
+ 		+ + + + +
+ Gyorgy pointed out some cases where compatibility rules are misleading or could not be checked at compile time.
+It was agreed to make the compatibility rules more strict to avoid such problems. If a need is recognized later on, the rules could still be relaxed.
+
+
+
+ + + + + + + + + + +
+ (0007863) +
+ Thomas Deiß    +
+ 15-01-2009 07:09    +
+ 		+ + + + +
+ language tag added, Annex A moved to part 1 section, document numbers added.
+
+
+
+ + + + + + + + + + +
+ (0007865) +
+ Thomas Deiß    +
+ 15-01-2009 08:02    +
+ 		+ + + + +
+ tag corrected
+
+
+
+ + + + + + + + + + +
+ (0007874) +
+ Thomas Deiß    +
+ 16-01-2009 15:11    +
+ 		+ + + + +
+ ANSI C, Java language mapping added.
+Section headers extended by text of headers in the relevant parts.
+
+
+
+ + + + + + + + + + +
+ (0007932) +
+ Thomas Deiß    +
+ 26-01-2009 16:31    +
+ 		+ + + + +
+ Formal type parameters of nested behaviour definitions removed (noticed by Jacob),
+
+comments by Jens:
+layout of component definitions in examples improved
+values of behaviours are identifiers are identiers, not names
+explained that control parts are not behaviour definitions within this document.
+
+new version 081 uploaded
+
+
+
+ + + + + + + + + + +
+ (0008519) +
+ Ina Schieferdecker    +
+ 21-04-2009 09:25    +
+ 		+ + + + +
+ Added C++ and XML mapping, revision and editorial corrections
+
+
+
+ + + + + + + + + + +
+ (0008520) +
+ Ina Schieferdecker    +
+ 21-04-2009 09:26    +
+ 		+ + + + +
+ Semantics to be added
+
+
+
+ + + + + + + + + + +
+ (0008798) +
+ Jens Grabowski    +
+ 30-06-2009 11:42    +
+ 		+ + + + +
+ Operational semantics included. Assigned to György for proof reading.
+
+
+
+ + + + + + + + + + +
+ (0008953) +
+ Gyorgy Rethy    +
+ 01-09-2009 15:50    +
(edited on: 01-09-2009 15:51)
+ 		+ + + + +
+ Just a few editorial comments to the OS clause, handed over on paper. On correcting those, the draft shall be uploaded to MTS#49 urgently.
+
+
+
+
+
+ + + + + + + + + + +
+ (0008964) +
+ Tibor Csöndes    +
+ 02-09-2009 16:31    +
+ 		+ + + + +
+ Document send for approval to MTS#49
+
+ + diff --git a/docs/mantis/CR0413.md b/docs/mantis/CR0413.md new file mode 100644 index 0000000000000000000000000000000000000000..1fd2db6ed3c9a788ad15a227069c220fc8e45d5a --- /dev/null +++ b/docs/mantis/CR0413.md @@ -0,0 +1,399 @@ + + + + + + + + + + + + + 0000413: Static test configurations - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0000413Part 01: TTCN-3 Core LanguageNew Featurepublic24-11-2006 14:2916-02-2010 14:36
ReporterStephan Schulz 
Assigned ToJens Grabowski 
PriorityhighSeverityfeatureReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.1.1 (published 2005-06) 
Target Versionv4.1.1 (published 2009-06)Fixed in Version 
Clause Reference(s)TBD
Source (company - Author)dr. György Réthy, Ericsson
Summary0000413: Static test configurations
DescriptionThough TTCN-3 has been designed for automatic test execution, this is far not the only use of TTCN-3 in practice. The typical workflow is, that TTCN-3 test cases are developed for basic or function testing purposes, used (validated) in an interactive (semi-manual) way in the first test campaign and re-used later in automated regression testing. For the success of TTCN-3 it is essential to features to the language to support also interactive test execution. In this mode testers are executing test cases one-by-one or smaller groups and selects the next test to be elaborated depending on the result (determined by log analysis) of the executed one. Very often test cases are executed in different combinations and order and the SUT behaviour even monitored during test case execution.
+When executing TTCN-3 tests in real test environments (not only in interactive mode), in many cases it would be very important not to destroy the test configurations at the end of a test case. There are several reasons for that:
+- By destroying the test configuration all data collected during T execution is lost. At the beginning of the next test case there is no information about the SUT's status, user data (e.g. call/session references, SUT-assigned IDs etc.). Today this problem is solved by saving the data on disk at the end of each test case and re-loading it at the beginning of the next test case. This complicates the TTCN-3 code significantly (collecting data from all PTCs, saving it, then reading the data and distribute to new PTCs) and in case of test case errors all data received from the SUT during the given test case is lost.
+- In practice it is impossible to start test cases from a null state. The whole configuration of the SUT and other tools used for execution may take as long as 1/2 hour that can not be allowed for every test case. The actual status of the SUT may not be known without having this information from previous test cases.
+- SUTs often require keep-alive signals to avoid maintenance alarms or blocking signalling links. This requires keep-alive timers running and sending/receiving keep-alive signals between test cases. TTCN-3 is unable to provide this functionality today.
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0004275closed Ina Schieferdecker New Concepts to be defined via Packages 
related to 0000381closed Jens Grabowski External Applications 
related to 0002143closed Jens Grabowski Invoke test cases from/on test components 
related to 0002758closed Jens Grabowski Queueing of function calls 
Attached Filesdoc CR_408 Static test configurations.doc (58,368) 24-11-2006 14:29
http://oldforge.etsi.org/mantis/file_download.php?file_id=41&type=bug
ppt CR-0413-Static-Test-Configurations.ppt (109,568) 12-08-2008 16:28
http://oldforge.etsi.org/mantis/file_download.php?file_id=1588&type=bug
doc es_TTCN3PackageTemplate_Configuration-V1_JG_TD.doc (220,160) 13-01-2009 11:41
http://oldforge.etsi.org/mantis/file_download.php?file_id=1951&type=bug
doc es_TTCN3PackageTemplate_Configuration-V2-090115.doc (251,392) 15-01-2009 17:16
http://oldforge.etsi.org/mantis/file_download.php?file_id=1958&type=bug
ppt TRI and TCI for DeplConfig.ppt (62,976) 21-04-2009 11:58
http://oldforge.etsi.org/mantis/file_download.php?file_id=2094&type=bug
ppt TRI and TCI for DeplConfig_v2.ppt (61,952) 21-04-2009 18:18
http://oldforge.etsi.org/mantis/file_download.php?file_id=2101&type=bug
doc es202781_DeploymentConfiguration_220409.doc (588,288) 23-04-2009 14:41
http://oldforge.etsi.org/mantis/file_download.php?file_id=2114&type=bug
doc Deployment-Semantics-100120.doc (1,599,488) 21-01-2010 15:31
http://oldforge.etsi.org/mantis/file_download.php?file_id=2325&type=bug
zip es202781_DeploymentConfiguration-100121-complete.zip (674,924) 21-01-2010 17:10
http://oldforge.etsi.org/mantis/file_download.php?file_id=2326&type=bug
zip es202781_DeploymentConfiguration-100122-complete.zip (675,686) 22-01-2010 10:30
http://oldforge.etsi.org/mantis/file_download.php?file_id=2327&type=bug
Issue History
Date ModifiedUsernameFieldChange
24-11-2006 14:29Stephan SchulzNew Issue
24-11-2006 14:29Stephan SchulzFile Added: CR_408 Static test configurations.doc
24-11-2006 14:29Stephan SchulzClause Reference(s) => TBD
24-11-2006 14:29Stephan SchulzSource (company - Author) => dr. György Réthy, Ericsson
15-06-2007 19:16Stephan SchulzStatusnew => assigned
15-06-2007 19:16Stephan SchulzAssigned To => Ina Schieferdecker
13-10-2007 19:20Ina SchieferdeckerAssigned ToIna Schieferdecker => Jens Grabowski
15-10-2007 13:15Ina SchieferdeckerNote Added: 0003612
15-10-2007 15:22Ina SchieferdeckerNote Added: 0003617
18-10-2007 14:27Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
12-08-2008 16:28Jens GrabowskiFile Added: CR-0413-Static-Test-Configurations.ppt
12-08-2008 16:28Jens GrabowskiNote Added: 0006501
12-12-2008 09:04Ina SchieferdeckerRelationship addedrelated to 0004275
12-12-2008 09:25Ina SchieferdeckerRelationship addedrelated to 0000381
12-12-2008 09:26Ina SchieferdeckerRelationship addedrelated to 0002143
12-12-2008 09:27Ina SchieferdeckerRelationship addedrelated to 0002758
13-01-2009 11:41Ina SchieferdeckerFile Added: es_TTCN3PackageTemplate_Configuration-V1_JG_TD.doc
15-01-2009 17:16Jens GrabowskiFile Added: es_TTCN3PackageTemplate_Configuration-V2-090115.doc
21-04-2009 11:58Ina SchieferdeckerFile Added: TRI and TCI for DeplConfig.ppt
21-04-2009 11:58Ina SchieferdeckerNote Added: 0008524
21-04-2009 18:18Ina SchieferdeckerNote Added: 0008530
21-04-2009 18:18Ina SchieferdeckerFile Added: TRI and TCI for DeplConfig_v2.ppt
23-04-2009 14:40Ina SchieferdeckerNote Added: 0008551
23-04-2009 14:41Ina SchieferdeckerFile Added: es202781_DeploymentConfiguration_220409.doc
21-01-2010 15:31Jens GrabowskiFile Added: Deployment-Semantics-100120.doc
21-01-2010 15:32Jens GrabowskiNote Added: 0009163
21-01-2010 17:10Jens GrabowskiFile Added: es202781_DeploymentConfiguration-100121-complete.zip
21-01-2010 17:11Jens GrabowskiNote Added: 0009164
22-01-2010 10:30Jens GrabowskiFile Added: es202781_DeploymentConfiguration-100122-complete.zip
22-01-2010 10:31Jens GrabowskiNote Added: 0009165
16-02-2010 14:36Jens GrabowskiStatusassigned => closed
16-02-2010 14:36Jens GrabowskiNote Added: 0009223
16-02-2010 14:36Jens GrabowskiResolutionopen => fixed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0003612) +
+ Ina Schieferdecker    +
+ 15-10-2007 13:15    +
+ 		+ + + + +
+ to be considered together with CR 419
+
+
+
+ + + + + + + + + + +
+ (0003617) +
+ Ina Schieferdecker    +
+ 15-10-2007 15:22    +
+ 		+ + + + +
+ deferred to 2008
+
+
+
+ + + + + + + + + + +
+ (0006501) +
+ Jens Grabowski    +
+ 12-08-2008 16:28    +
+ 		+ + + + +
+ Slides for discussion uploaded!
+
+
+
+ + + + + + + + + + +
+ (0008524) +
+ Ina Schieferdecker    +
+ 21-04-2009 11:58    +
+ 		+ + + + +
+ Initial thoughts on the TRI/TCI support for the depl&conf. package as a basis for discussion.
+
+
+
+ + + + + + + + + + +
+ (0008530) +
+ Ina Schieferdecker    +
+ 21-04-2009 18:18    +
+ 		+ + + + +
+ Revision of the TRI/TCI interface after discussion:
+
+1. use dedicated TRI/TCI map/connect operations for static connections
+
+2. enable the handling of static configurations via TM in order to support the starting of test cases with static configurations from TM
+
+
+
+ + + + + + + + + + +
+ (0008551) +
+ Ina Schieferdecker    +
+ 23-04-2009 14:40    +
+ 		+ + + + +
+ Definition of TRI/TCI according to discussion:
+
+TRI:
+changes to triExecuteTestCase not to handle static maps
+changes to triUnmap to cope with static maps
+definition of triStaticMap
+
+Definition of Java, C, and C++ mapping
+
+TCI:
+extension to TciTestComponentKindType
+TCI TM required - definition of tciStartConfig and tciKillConfig
+TCI TM provided - definition of tciConfigStarted and tciConfigKilled
+TCI CH required - definition of tciStaticConnect and tciStaticMap
+                - tciDisconnect and TciUnmap to handle also static connections
+TCI CH provided - definition of tciStaticConnectReq and tciStaticMapReq
+                - tciDisconnectReq and TciUnmapReq to handle also static connections
+TCI-TL provided - definition of
+                  tliCStaticCreate, tliPStaticConnect, and tliPStaticMap
+                - definition of tliConfigStarted and tliConfigKilled
+
+Definition of Java, C, C++, and XML mapping
+
+
+
+ + + + + + + + + + +
+ (0009163) +
+ Jens Grabowski    +
+ 21-01-2010 15:32    +
+ 		+ + + + +
+ Deployment-Semantics-100120.doc includes the operational semantics of the static test configuration package as a delta to part 4 of the TTCN-3 standard.
+
+
+
+ + + + + + + + + + +
+ (0009164) +
+ Jens Grabowski    +
+ 21-01-2010 17:11    +
+ 		+ + + + +
+ es202781_DeploymentConfiguration-100121-complete.zip includes the Deployment and Configuration package including the operational semantics.
+
+
+
+ + + + + + + + + + +
+ (0009165) +
+ Jens Grabowski    +
+ 22-01-2010 10:31    +
+ 		+ + + + +
+ Update from 22 Jan 2010 includes a few editorial corrections.
+
+
+
+ + + + + + + + + + +
+ (0009223) +
+ Jens Grabowski    +
+ 16-02-2010 14:36    +
+ 		+ + + + +
+ First version of the package is completed and uploaded. The CR is closed for the moment.
+
+ + diff --git a/docs/mantis/CR0414.md b/docs/mantis/CR0414.md new file mode 100644 index 0000000000000000000000000000000000000000..e4f57a786fc22b6643a16aff1bb360c197709b82 --- /dev/null +++ b/docs/mantis/CR0414.md @@ -0,0 +1,239 @@ + + + + + + + + + + + + + 0000414: break and continue in loop constructs - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0000414Part 01: TTCN-3 Core LanguageNew Featurepublic24-11-2006 14:3112-03-2008 10:31
ReporterStephan Schulz 
Assigned ToIna Schieferdecker 
PriorityhighSeverityfeatureReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.1.1 (published 2005-06) 
Target Versionv3.3.2 (published 2008-04)Fixed in Versionv3.3.2 (published 2008-04) 
Clause Reference(s)-
Source (company - Author)dr. György Réthy, Ericsson
Summary0000414: break and continue in loop constructs
DescriptionIt is often a case that at some condition code execution shall leave a loop, exit from an altstep etc. or, on the contrary, shall continue with the execution of the next cycle. Users may use goto and label-s for this purpose, however this is often a pain that decreases efficiency: often a lots of unique labels shall be maintained, label names are not seen on the screen when the user writes the related goto statement, labels may be unintentionally shifted or after some time, testers are fear to delete labels not used any more etc.
Steps To Reproduce
Additional InformationAdd break operation to the standard; break can be called in bodies of all statements attracting a statement block, i.e. if-else, select case, for, while, do-while, alternatives of alt-s and altsteps. The break statement shall cause that code execution continues with the statement following the statement in which break has been reached. From this point of view select case and if-else are considered to be the statements in which break has been used, i.e. execution continues after the select case closing bracket or after the closing bracket of the if statement block (no else branch), of the else statement block or of the last elseif statement block in an if-elseif..-else chain.
+The continue operation, except statement blocks of alt & altstep alternatives, can be used in statement blocks of for, while and do-while sloops. This will cause the re-evaluation of the loop condition and start the next loop if the condition holds.
+
+Precise text proposal to be provided when the technical capabilities are agreed.
+
TagsNo tags attached.
Relationships
Attached Filesdoc CR_414_1917_break_continue_interleave_part4.doc (625,152) 19-11-2007 13:53
http://oldforge.etsi.org/mantis/file_download.php?file_id=1122&type=bug
doc CR_414_1917_break_continue_interleave_part1_02.doc (1,732,096) 26-11-2007 10:20
http://oldforge.etsi.org/mantis/file_download.php?file_id=1156&type=bug
zip CR_414_1917_break_continue_interleave_part1_Rev1_JG_071204.zip (282,511) 04-12-2007 10:20
http://oldforge.etsi.org/mantis/file_download.php?file_id=1184&type=bug
zip CR_414_1917_break_continue_interleave_part4_Rev1_JG_071204.zip (129,415) 04-12-2007 10:21
http://oldforge.etsi.org/mantis/file_download.php?file_id=1185&type=bug
zip CR_414_1917_break_continue_interleave_part1_Rev1_JG_RGy_071205.zip (288,528) 05-12-2007 19:39
http://oldforge.etsi.org/mantis/file_download.php?file_id=1228&type=bug
zip CR_414_1917_break_continue_interleave_part1_Rev1_JG_RGy_071206.zip (288,656) 06-12-2007 11:17
http://oldforge.etsi.org/mantis/file_download.php?file_id=1231&type=bug
zip CR_414_1917_break_continue_interleave_part1_Rev2_JG_RGy_JG_071206.zip (291,371) 06-12-2007 12:58
http://oldforge.etsi.org/mantis/file_download.php?file_id=1235&type=bug
zip CR_414_1917_break_continue_interleave_part4_Rev2_JG_071206.zip (129,457) 06-12-2007 12:59
http://oldforge.etsi.org/mantis/file_download.php?file_id=1236&type=bug
Issue History
Date ModifiedUsernameFieldChange
24-11-2006 14:31Stephan SchulzNew Issue
24-11-2006 14:31Stephan SchulzClause Reference(s) => -
24-11-2006 14:31Stephan SchulzSource (company - Author) => dr. György Réthy, Ericsson
15-06-2007 19:16Stephan SchulzStatusnew => assigned
15-06-2007 19:16Stephan SchulzAssigned To => Ina Schieferdecker
13-10-2007 19:22Ina SchieferdeckerAssigned ToIna Schieferdecker => developer_u
17-10-2007 12:41user10Assigned Todeveloper_u => Thomas Deiß
18-10-2007 12:11Ina SchieferdeckerTarget Version => Edition 3.3.1 (not yet published)
19-11-2007 13:52Thomas DeißNote Added: 0004003
19-11-2007 13:52Thomas DeißResolutionopen => fixed
19-11-2007 13:53Thomas DeißFile Added: CR_414_1917_break_continue_interleave_part1.doc
19-11-2007 13:53Thomas DeißFile Added: CR_414_1917_break_continue_interleave_part4.doc
19-11-2007 13:54Thomas DeißAssigned ToThomas Deiß => Gyorgy Rethy
26-11-2007 10:20Thomas DeißFile Deleted: CR_414_1917_break_continue_interleave_part1.doc
26-11-2007 10:20Thomas DeißFile Added: CR_414_1917_break_continue_interleave_part1_02.doc
26-11-2007 10:21Thomas DeißNote Added: 0004088
03-12-2007 14:17Jens GrabowskiNote Added: 0004231
03-12-2007 14:17Jens GrabowskiAssigned ToGyorgy Rethy => Jens Grabowski
04-12-2007 10:20Jens GrabowskiFile Added: CR_414_1917_break_continue_interleave_part1_Rev1_JG_071204.zip
04-12-2007 10:21Jens GrabowskiFile Added: CR_414_1917_break_continue_interleave_part4_Rev1_JG_071204.zip
04-12-2007 10:23Jens GrabowskiNote Added: 0004252
04-12-2007 10:23Jens GrabowskiAssigned ToJens Grabowski => Gyorgy Rethy
05-12-2007 18:34Gyorgy RethyFile Added: CR_414_1917_break_continue_interleave_part1_Rev1_JG_RGy_071205.doc
05-12-2007 18:38Gyorgy RethyNote Added: 0004356
05-12-2007 18:38Gyorgy RethyAssigned ToGyorgy Rethy => Jens Grabowski
05-12-2007 18:38Gyorgy RethyFile Deleted: CR_414_1917_break_continue_interleave_part1_Rev1_JG_RGy_071205.doc
05-12-2007 19:39Gyorgy RethyFile Added: CR_414_1917_break_continue_interleave_part1_Rev1_JG_RGy_071205.zip
06-12-2007 11:17Gyorgy RethyFile Added: CR_414_1917_break_continue_interleave_part1_Rev1_JG_RGy_071206.zip
06-12-2007 11:20Gyorgy RethyNote Added: 0004366
06-12-2007 12:58Jens GrabowskiFile Added: CR_414_1917_break_continue_interleave_part1_Rev2_JG_RGy_JG_071206.zip
06-12-2007 12:59Jens GrabowskiFile Added: CR_414_1917_break_continue_interleave_part4_Rev2_JG_071206.zip
06-12-2007 13:00Jens GrabowskiAssigned ToJens Grabowski => Ina Schieferdecker
06-12-2007 13:00Jens GrabowskiStatusassigned => closed
12-03-2008 10:27user10Target VersionEdition 3.3.1 --will not be published, see 3.3.2 => Edition 3.3.2 (not yet published)
12-03-2008 10:31user10Fixed in Version => Edition 3.3.2 (not yet published)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0004003) +
+ Thomas Deiß    +
+ 19-11-2007 13:52    +
+ 		+ + + + +
+ contains solution for CR1917,
+affects both part1 and part4
+
+
+
+ + + + + + + + + + +
+ (0004088) +
+ Thomas Deiß    +
+ 26-11-2007 10:21    +
+ 		+ + + + +
+ Resolution file for part1 replaced as I missed to add break/continue to two tables.
+
+
+
+ + + + + + + + + + +
+ (0004231) +
+ Jens Grabowski    +
+ 03-12-2007 14:17    +
+ 		+ + + + +
+ To be crosschecked by Jens and then by György.
+
+
+
+ + + + + + + + + + +
+ (0004252) +
+ Jens Grabowski    +
+ 04-12-2007 10:23    +
+ 		+ + + + +
+ Crosschecked by Jens and added some modifications already discussed with Thomas (see zip files).
+
+
+
+ + + + + + + + + + +
+ (0004356) +
+ Gyorgy Rethy    +
+ 05-12-2007 18:38    +
+ 		+ + + + +
+ break - except interleave - should also be allowed in alt statements and altsteps as required by the CR. Text on this is added to the part-1 file, if agreed, should also be added to the OS.
+Also minor editorial corections in the part-1 file.
+
+
+
+ + + + + + + + + + +
+ (0004366) +
+ Gyorgy Rethy    +
+ 06-12-2007 11:20    +
+ 		+ + + + +
+ As agreed in the STF discussion, allowing break in altsteps needs further study, hence shifted to next year. File CR_414_1917_break_continue_interleave_part1_Rev1_JG_RGy_071206.zip contains proposed text in which allowing break in altsteps is removed (allowed in loops, alt and interleave)
+
+ + diff --git a/docs/mantis/CR0415.md b/docs/mantis/CR0415.md new file mode 100644 index 0000000000000000000000000000000000000000..e7742fc2115aede04ea7a68ab0dcfec8f1c44380 --- /dev/null +++ b/docs/mantis/CR0415.md @@ -0,0 +1,328 @@ + + + + + + + + + + + + + 0000415: Definition IDs - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0000415Part 01: TTCN-3 Core LanguageNew Featurepublic24-11-2006 14:3324-04-2008 20:03
ReporterStephan Schulz 
Assigned ToIna Schieferdecker 
PriorityhighSeverityfeatureReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.1.1 (published 2005-06) 
Target Versionv3.4.1 (published 2008-09)Fixed in Versionv3.4.1 (published 2008-09) 
Clause Reference(s)-
Source (company - Author)dr. György Réthy, Ericsson
Summary0000415: Definition IDs
DescriptionIn real test activities - especially in basic and function tests - logging and information being logged is one of the most important features. It is of utmost importance to effectively debug the TTCN-3 code, to be absolutely aware of what is happening during test execution and to effectively debug the SUT behaviour. For this reason users are often writing functions that are using TTCN-3 user logs to output the specific information they need. However, some information they want to log is changing dynamically during TTCN-3 code development (e.g. line number of the code generating the actual user log event), while others could be written manually but this is inefficient, inconvenient and is a potential source of errors.
+
+The purpose of the feature is to introduce special TTCN-3 tokens beginning with a special ASCII character that is not used elsewhere in TTCN-3. The leading character shall be followed by an identifier from a predefined set.
+The special tokens shall be substituted with a literal charstring values based on the rules below.
+The tokens can appear anywhere in the TTCN-3 code where charstring literals are allowed (in expressions, log() statements, etc.). However, if the given token is not applicable in the corresponding context the compiler shall report an error. Substitution is not performed if the special token is given within a charstring value.
+
+List of predefined identifiers:
+
+Identifier Returns Applicable (type)
+%moduleId name of the actual TTCN-3 module everywhere (compile time)
+%fileName name of the actual TTCN-3 source file everywhere (compile time)
+%lineNumber act. line no. in source code everywhere (compile time)
+%definitionId name of function/altstep in functions& altsteps (compile time)
+%testcaseId name of the testcase everywhere (runtime)
+
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR415-DefinitionIDs-Resolution.doc (125,440) 21-04-2008 15:45
http://oldforge.etsi.org/mantis/file_download.php?file_id=1422&type=bug
doc CR415-DefinitionIDs-Resolution-V2.doc (126,464) 22-04-2008 11:35
http://oldforge.etsi.org/mantis/file_download.php?file_id=1426&type=bug
doc CR415-DefinitionIDs-Resolution-V3.doc (125,952) 22-04-2008 18:41
http://oldforge.etsi.org/mantis/file_download.php?file_id=1435&type=bug
doc CR415-DefinitionIDs-Resolution-V4.doc (133,120) 24-04-2008 19:52
http://oldforge.etsi.org/mantis/file_download.php?file_id=1456&type=bug
Issue History
Date ModifiedUsernameFieldChange
24-11-2006 14:33Stephan SchulzNew Issue
24-11-2006 14:33Stephan SchulzClause Reference(s) => -
24-11-2006 14:33Stephan SchulzSource (company - Author) => dr. György Réthy, Ericsson
24-11-2006 15:03Stephan SchulzNote Added: 0000331
15-06-2007 19:13Stephan SchulzStatusnew => assigned
15-06-2007 19:13Stephan SchulzAssigned To => Ina Schieferdecker
13-10-2007 19:28Ina SchieferdeckerAssigned ToIna Schieferdecker => Jens Grabowski
17-10-2007 16:05Ina SchieferdeckerNote Added: 0003669
18-10-2007 12:06Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
21-04-2008 15:45Jens GrabowskiNote Added: 0005477
21-04-2008 15:45Jens GrabowskiFile Added: CR415-DefinitionIDs-Resolution.doc
21-04-2008 15:46Jens GrabowskiAssigned ToJens Grabowski => Gyorgy Rethy
21-04-2008 19:57Gyorgy RethyNote Added: 0005483
21-04-2008 19:59Gyorgy RethyAssigned ToGyorgy Rethy => Jens Grabowski
22-04-2008 11:35Jens GrabowskiNote Added: 0005489
22-04-2008 11:35Jens GrabowskiFile Added: CR415-DefinitionIDs-Resolution-V2.doc
22-04-2008 11:36Jens GrabowskiAssigned ToJens Grabowski => Gyorgy Rethy
22-04-2008 11:37Jens GrabowskiNote Added: 0005490
22-04-2008 16:29Gyorgy RethyNote Added: 0005499
22-04-2008 16:30Gyorgy RethyAssigned ToGyorgy Rethy => Thomas Deiß
22-04-2008 18:41Thomas DeißFile Added: CR415-DefinitionIDs-Resolution-V3.doc
22-04-2008 18:43Thomas DeißNote Added: 0005507
22-04-2008 18:43Thomas DeißAssigned ToThomas Deiß => Ina Schieferdecker
23-04-2008 11:50Ina SchieferdeckerTarget VersionEdition 4.1.1 (not yet published) => Edition 3.4.1 (not yet published)
24-04-2008 19:52Ina SchieferdeckerFile Added: CR415-DefinitionIDs-Resolution-V4.doc
24-04-2008 20:03Ina SchieferdeckerStatusassigned => closed
24-04-2008 20:03Ina SchieferdeckerResolutionopen => fixed
24-04-2008 20:03Ina SchieferdeckerFixed in Version => Edition 3.4.1 (not yet published)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0000331) +
+ Stephan Schulz    +
+ 24-11-2006 15:03    +
+ 		+ + + + +
+ The metainformation name should be generalize to allow user-defined metainfo names.
+
+
+
+ + + + + + + + + + +
+ (0003669) +
+ Ina Schieferdecker    +
+ 17-10-2007 16:05    +
+ 		+ + + + +
+ candidate for a library - deferred to 2008
+
+
+
+ + + + + + + + + + +
+ (0005477) +
+ Jens Grabowski    +
+ 21-04-2008 15:45    +
+ 		+ + + + +
+ The attached proposal for resolution considers Definition IDs as preprocessor macros. This means a preprocessor can add the missing information before compilation. Runtime information can not be retrieved with this view. This means, that for example, the testcase ID or a call hierarchie of functions cannot be retrieved by this mechanism.
+
+
+
+ + + + + + + + + + +
+ (0005483) +
+ Gyorgy Rethy    +
+ 21-04-2008 19:57    +
+ 		+ + + + +
+ a) Let __SCOPE__ returns "control" or "<modulename>.control" in control part; think about a logging function that may be called from a function or from a control part by passing __SCOPE__ as an actual parameer. It would be more logical is logs "control", than just the name of the module the control part is within.
+b) Do we need double underscore? Wouldn't it be enough just one, like _SCOPE_?
+c) Would be better to call them something else as "preprocessor macros", though I do not have a good proposal just now.
+
+
+
+ + + + + + + + + + +
+ (0005489) +
+ Jens Grabowski    +
+ 22-04-2008 11:35    +
+ 		+ + + + +
+ Answer to <module name>.control:
+changed in new proposal
+
+Answer to double underscore question:
+No, we do not need a double underscore, but a double underscore is used for the same preprocessing macros in C. Therefore, I have chosen the same notation.
+
+Answer to name:
+I changed to preprocessing macro and explained the meaning of this term. in the beginning of the proposed new annex.
+
+
+
+ + + + + + + + + + +
+ (0005490) +
+ Jens Grabowski    +
+ 22-04-2008 11:37    +
+ 		+ + + + +
+ I forgot: We have to decide if the new annex should become normative or informative.
+
+
+
+ + + + + + + + + + +
+ (0005499) +
+ Gyorgy Rethy    +
+ 22-04-2008 16:29    +
+ 		+ + + + +
+ I propose to make it a new mandatory annex (otherwise user cannot count on using it in test suites) - causes that references to shifted informative annexes shall be checked and corrected.
+
+
+
+ + + + + + + + + + +
+ (0005507) +
+ Thomas Deiß    +
+ 22-04-2008 18:43    +
+ 		+ + + + +
+ __SCOPE__: <modulename>.control -> control
+The reason to have this more consistent with the other scope units (except the module itself), crosschecked with Gyorgy and Jens.
+
+Otherwise, fine for me.
+
+ + diff --git a/docs/mantis/CR0416.md b/docs/mantis/CR0416.md new file mode 100644 index 0000000000000000000000000000000000000000..afb2a3f23a340957940112cff82d1ac4bd68a506 --- /dev/null +++ b/docs/mantis/CR0416.md @@ -0,0 +1,231 @@ + + + + + + + + + + + + + 0000416: Passing omit to value formal parameters - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0000416Part 01: TTCN-3 Core LanguageClarificationpublic24-11-2006 14:3412-03-2008 10:24
ReporterStephan Schulz 
Assigned ToIna Schieferdecker 
PriorityhighSeverityblockReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.1.1 (published 2005-06) 
Target Versionv3.3.2 (published 2008-04)Fixed in Versionv3.3.2 (published 2008-04) 
Clause Reference(s)-
Source (company - Author)dr. György Réthy, Ericsson
Summary0000416: Passing omit to value formal parameters
DescriptionThe TTCN-3 standard today does not defines the term "value". In common sense value means "In computer science, a value may be a number, literal string, array and anything that can be treated as if it were a number. ... The exact definition varies across programming languages." (from the English Wikipedia, Value (computer science) item). "Nothing" is not a value, i.e. omit should not be considered as value in TTCN-3. This meaning is strengthened by the TTCN-3 standard, where omit is mentioned as a matching mechanism (though it can also be PART of a value, i.e. assigned to optional fields. Titan follows this approach and allows to pass real specific values to value parameters only but not omit. This provides a big advantage: it is sufficient to check the "value" of a value formal parameter when it is passed, no need for subsequent checks when it is used e.g. in expressions.
+However, in many cases it would be useful to allow formal parameters accepting specific values and omit, e.g. when this parameter is passed to optional template fields in sending operations.
+
Steps To Reproduce
Additional InformationIt is proposed to make a distinction between value formal parameters allowing omit and not allowing omit in the TTCN-3 language.
+
+Formal parameters
+To denote that the special value omit is allowed for a value formal parameter, the optional keyword shall be used in the formal parameter list of test cases, functions, altsteps or templates. In the testcase/function/altstep the optional parameter can be compared with omit to determine if a concrete value has been provided or omit was given when calling it.
+Example code:
+function f_MyFunc1 (optional integer par)
+{
+   if (par==omit) {
+      // omit was given for par
+   } else {
+      // value was provided for par
+   }
+}
+The parameters with default value (see CR 406) and optional parameters are independent features. The user can combine the two features,
+Example code:
+function f_MyFunc2(optional integer par1, optional integer par2 := omit, integer par3 := 5 )
+{ ... }
+
+Actual parameters
+Optional value parameters may be called with a concrete value or with omit as actual parameter.
+Example code:
+f_MyFunc1(11);
+f_MyFunc1(omit);
+f_MyFunc2(omit); // par1 & par2 will have the actual value omit,
+                 // par3 will have the actual value 5
+
+
TagsNo tags attached.
Relationships
Attached Fileszip CR_416_v2.zip (890,821) 06-12-2007 11:51
http://oldforge.etsi.org/mantis/file_download.php?file_id=1234&type=bug
zip CR_416_v3.zip (885,232) 06-12-2007 17:01
http://oldforge.etsi.org/mantis/file_download.php?file_id=1242&type=bug
zip CR_416_v4.zip (869,220) 06-12-2007 17:43
http://oldforge.etsi.org/mantis/file_download.php?file_id=1245&type=bug
zip CR_416_v5.zip (886,077) 06-12-2007 18:30
http://oldforge.etsi.org/mantis/file_download.php?file_id=1247&type=bug
Issue History
Date ModifiedUsernameFieldChange
24-11-2006 14:34Stephan SchulzNew Issue
24-11-2006 14:34Stephan SchulzClause Reference(s) => -
24-11-2006 14:34Stephan SchulzSource (company - Author) => dr. György Réthy, Ericsson
15-06-2007 19:15Stephan SchulzStatusnew => assigned
15-06-2007 19:15Stephan SchulzAssigned To => Ina Schieferdecker
13-10-2007 19:22Ina SchieferdeckerAssigned ToIna Schieferdecker => developer_u
17-10-2007 12:41user10Assigned Todeveloper_u => Thomas Deiß
18-10-2007 12:10Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
06-12-2007 11:51Thomas DeißFile Added: CR_416_v2.zip
06-12-2007 11:52Thomas DeißNote Added: 0004372
06-12-2007 11:52Thomas DeißAssigned ToThomas Deiß => Gyorgy Rethy
06-12-2007 11:52Thomas DeißResolutionopen => fixed
06-12-2007 11:52Thomas DeißTarget VersionEdition 4.1.1 (not yet published) => Edition 3.3.1 (not yet published)
06-12-2007 16:59Thomas DeißNote Added: 0004396
06-12-2007 17:01Thomas DeißFile Added: CR_416_v3.zip
06-12-2007 17:43Gyorgy RethyFile Added: CR_416_v4.zip
06-12-2007 17:45Gyorgy RethyNote Added: 0004401
06-12-2007 17:45Gyorgy RethyAssigned ToGyorgy Rethy => Jens Grabowski
06-12-2007 18:05Jens GrabowskiAssigned ToJens Grabowski => Thomas Deiß
06-12-2007 18:30Thomas DeißFile Added: CR_416_v5.zip
06-12-2007 18:34Thomas DeißNote Added: 0004407
06-12-2007 18:34Thomas DeißAssigned ToThomas Deiß => Ina Schieferdecker
07-12-2007 09:38Ina SchieferdeckerStatusassigned => resolved
07-12-2007 10:05Ina SchieferdeckerStatusresolved => closed
07-12-2007 10:05Ina SchieferdeckerNote Added: 0004417
07-12-2007 10:05Ina SchieferdeckerFixed in Version => Edition 3.3.1 (not yet published)
12-03-2008 10:22user10Fixed in VersionEdition 3.3.1 --will not be published, see 3.3.2 => Edition 3.3.2 (not yet published)
12-03-2008 10:24user10Target VersionEdition 3.3.1 --will not be published, see 3.3.2 => Edition 3.3.2 (not yet published)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0004372) +
+ Thomas Deiß    +
+ 06-12-2007 11:52    +
+ 		+ + + + +
+ solution provided (already checked by Gyorgy once)
+
+
+
+ + + + + + + + + + +
+ (0004396) +
+ Thomas Deiß    +
+ 06-12-2007 16:59    +
+ 		+ + + + +
+ New solution (R3). Introduce restrictions of templates, currently just one restriction is allowed (omit). 'template (omit)' can be shortened to omit. incorrect cases are not required to be detected at compile time, similar to type compatibility.
+
+
+
+ + + + + + + + + + +
+ (0004401) +
+ Gyorgy Rethy    +
+ 06-12-2007 17:45    +
+ 		+ + + + +
+ I basically agree both with the solution and handling it in the standard's text. Made some modifications to the text proposed.
+
+
+
+ + + + + + + + + + +
+ (0004407) +
+ Thomas Deiß    +
+ 06-12-2007 18:34    +
+ 		+ + + + +
+ Description made more restrictive (no hints on more general usage).
+Example added.
+Parentheses changed to curly brackets to avoid confusion with value lists.
+
+please check the additional comments in the BNF.
+
+
+
+ + + + + + + + + + +
+ (0004417) +
+ Ina Schieferdecker    +
+ 07-12-2007 10:05    +
+ 		+ + + + +
+ just little wording changes
+
+ + diff --git a/docs/mantis/CR0417.md b/docs/mantis/CR0417.md new file mode 100644 index 0000000000000000000000000000000000000000..cf24bccac95a07bce33cda13d38a554f9c0a1fbe --- /dev/null +++ b/docs/mantis/CR0417.md @@ -0,0 +1,110 @@ + + + + + + + + + + + + + 0000417: Assignment notation in actual parameter lists - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0000417Part 01: TTCN-3 Core LanguageNew Featurepublic24-11-2006 14:3612-12-2008 07:27
ReporterStephan Schulz 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityfeatureReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.1.1 (published 2005-06) 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)-
Source (company - Author)dr. György Réthy, Ericsson
Summary0000417: Assignment notation in actual parameter lists
DescriptionThis CR is closely related to the CR on "Formal parameter default values (non-mandatory parameters)". In testing of telecom systems we often face the long parameter list problem. When accepting CR 406, parameter lists may contain numerous parameters with default values. When the user wants to change the actual value of one or few last parameters in the list, he has to "dash-out" all other parameters preceding the one(s) with actual value(s). This is inconvenient and may easily lead to errors like miscalculating the number of dashes (especially if the parameter to which we pass the actual value erroneously is of the same time as the parameter to which we wanted to pass it - this kind of error may remain covered and causing misbehaviour).
+In the case of allowing assignment notation for formal parameters ? except mandatory ones - only non-mandatory parameters with an actual value should be listed. Each parameter present can be identified by the name of the corresponding formal parameter. Value list and assignment notations can be mixed within an actual parameter list with the following restriction: once an assignment notation is used, actual parameters in the same list following this one shall use the assignment notation.
+NOTE: This feature causes that the call of a template/function/altstep or testcase becomes dependent on the formal parameter names used.
+Example of various invocations of the function defined in the previous example code:
+var integer v_int := 10;
+template charstring tmpl_str := pattern "a??";
+
+f_MyFunction("abc");
+f_MyFunction("abc", par_3:= 5);
+
+
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0000411closed Jens Grabowski Part 04: TTCN-3 Operational Semantics Formal parameter default values (non-mandatory parameters) 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
24-11-2006 14:36Stephan SchulzNew Issue
24-11-2006 14:36Stephan SchulzClause Reference(s) => -
24-11-2006 14:36Stephan SchulzSource (company - Author) => dr. György Réthy, Ericsson
24-11-2006 14:37Stephan SchulzRelationship addedrelated to 0000411
15-06-2007 19:15Stephan SchulzStatusnew => assigned
15-06-2007 19:15Stephan SchulzAssigned To => Ina Schieferdecker
13-10-2007 19:23Ina SchieferdeckerAssigned ToIna Schieferdecker => developer_u
15-10-2007 12:54Ina SchieferdeckerNote Added: 0003610
17-10-2007 11:48Ina SchieferdeckerNote Edited: 0003610
17-10-2007 11:48Ina SchieferdeckerNote Edited: 0003610
17-10-2007 12:41user10Assigned Todeveloper_u => Thomas Deiß
18-10-2007 12:12Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
18-10-2007 12:12Ina SchieferdeckerDescription Updated
09-12-2008 18:15Ina SchieferdeckerNote Added: 0007612
09-12-2008 18:15Ina SchieferdeckerAssigned ToThomas Deiß => Ina Schieferdecker
09-12-2008 18:15Ina SchieferdeckerStatusassigned => resolved
09-12-2008 18:15Ina SchieferdeckerResolutionopen => fixed
12-12-2008 07:27Ina SchieferdeckerStatusresolved => closed
12-12-2008 07:27Ina SchieferdeckerFixed in Version => Edition 4.1.1 (not yet published)
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0003610) +
+ Ina Schieferdecker    +
+ 15-10-2007 12:54    +
(edited on: 17-10-2007 11:48)
+ 		+ + + + +
+ to be considered only in relation with the CR 411 on default values for formal parameters - deferred to 2008
+
+
+
+
+
+ + + + + + + + + + +
+ (0007612) +
+ Ina Schieferdecker    +
+ 09-12-2008 18:15    +
+ 		+ + + + +
+ Assignment notation fixed in part 1 along the CR411 resolution.
+
+ + diff --git a/docs/mantis/CR0418.md b/docs/mantis/CR0418.md new file mode 100644 index 0000000000000000000000000000000000000000..350286a37e5d06adb0c6827c1ebd61f03c6de078 --- /dev/null +++ b/docs/mantis/CR0418.md @@ -0,0 +1,213 @@ + + + + + + + + + + + + + 0000418: Stand-alone statement blocks - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0000418Part 01: TTCN-3 Core LanguageNew Featurepublic24-11-2006 14:3807-10-2008 05:52
ReporterStephan Schulz 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityfeatureReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.1.1 (published 2005-06) 
Target Versionv3.3.2 (published 2008-04)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)-
Source (company - Author)dr. György Réthy, Ericsson
Summary0000418: Stand-alone statement blocks
DescriptionStatement block is a scope unit that allows to declare local constants, templates, variables and timers. However statement blocks can be used as part of other statements only but not in a stand-alone way. This forces users to use a dummy if (true) {<statements >} or do {<statements >} while (false) workaround when they want to use temporary declarations. It is suggested to allow stand-alone statement blocks as well to avoid pointless workarounds.
+Example:
+function Myfunc () runs on MyCompType {
+  var integer vl_int;
+...
+  {
+    var integer vl_int2 := 5;
+    vl_int := vl_int2 + 3
+  }
+}
+
Steps To Reproduce
Additional InformationProposed Solution
+
+562. BasicStatements ::= Assignment | LogStatement | LoopConstruct | ConditionalConstruct | SelectCaseConstruct | StatementBlock
+
+
TagsNo tags attached.
Relationships
Attached Fileszip CR-418-Core-Language-Resolution.zip (864,866) 19-10-2007 10:07
http://oldforge.etsi.org/mantis/file_download.php?file_id=1055&type=bug
zip CR-388-418-Operational-Semantics-Resolution.zip (1,298,804) 19-10-2007 10:08
http://oldforge.etsi.org/mantis/file_download.php?file_id=1056&type=bug
Issue History
Date ModifiedUsernameFieldChange
24-11-2006 14:38Stephan SchulzNew Issue
24-11-2006 14:38Stephan SchulzClause Reference(s) => -
24-11-2006 14:38Stephan SchulzSource (company - Author) => dr. György Réthy, Ericsson
15-06-2007 19:15Stephan SchulzStatusnew => assigned
15-06-2007 19:15Stephan SchulzAssigned To => Ina Schieferdecker
13-10-2007 19:23Ina SchieferdeckerAssigned ToIna Schieferdecker => Jens Grabowski
18-10-2007 14:29Ina SchieferdeckerTarget Version => Edition 3.3.1 (not yet published)
19-10-2007 10:02Ina SchieferdeckerResolutionopen => fixed
19-10-2007 10:07Jens GrabowskiFile Added: CR-418-Core-Language-Resolution.zip
19-10-2007 10:08Jens GrabowskiFile Added: CR-388-418-Operational-Semantics-Resolution.zip
19-10-2007 10:09Jens GrabowskiNote Added: 0003699
19-11-2007 16:40Jens GrabowskiAssigned ToJens Grabowski => Gyorgy Rethy
05-12-2007 17:22Gyorgy RethyNote Added: 0004349
05-12-2007 17:22Gyorgy RethyAssigned ToGyorgy Rethy => Jens Grabowski
05-12-2007 17:22Gyorgy RethyStatusassigned => resolved
05-12-2007 18:05Jens GrabowskiStatusresolved => feedback
05-12-2007 18:05Jens GrabowskiResolutionfixed => reopened
05-12-2007 18:05Jens GrabowskiNote Added: 0004352
05-12-2007 18:06Jens GrabowskiAssigned ToJens Grabowski => Ina Schieferdecker
05-12-2007 18:06Jens GrabowskiStatusfeedback => resolved
05-12-2007 18:06Jens GrabowskiResolutionreopened => fixed
06-12-2007 09:07Ina SchieferdeckerStatusresolved => closed
06-12-2007 09:07Ina SchieferdeckerFixed in Version => Edition 3.3.1 (not yet published)
12-03-2008 10:22user10Fixed in VersionEdition 3.3.1 --will not be published, see 3.3.2 => Edition 3.3.2 (not yet published)
12-03-2008 10:24user10Target VersionEdition 3.3.1 --will not be published, see 3.3.2 => Edition 3.3.2 (not yet published)
01-09-2008 10:10Ina SchieferdeckerStatusclosed => feedback
01-09-2008 10:10Ina SchieferdeckerResolutionfixed => reopened
01-09-2008 10:10Ina SchieferdeckerNote Added: 0006672
07-10-2008 05:51Ina SchieferdeckerNote Added: 0007004
07-10-2008 05:52Ina SchieferdeckerStatusfeedback => closed
07-10-2008 05:52Ina SchieferdeckerResolutionreopened => fixed
07-10-2008 05:52Ina SchieferdeckerFixed in VersionEdition 3.3.2 => Edition 4.1.1 (not yet published)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0003699) +
+ Jens Grabowski    +
+ 19-10-2007 10:09    +
+ 		+ + + + +
+ Please note: CR-388-418-Operational-Semantics-Resolution.zip also includes the resolution to CR 388. The same file will be uploaded for the resolution of CR 388.
+
+
+
+ + + + + + + + + + +
+ (0004349) +
+ Gyorgy Rethy    +
+ 05-12-2007 17:22    +
+ 		+ + + + +
+ Jens: pls. add OS changes in Part-4 and assign the CR to Ina afterwards.
+
+
+
+ + + + + + + + + + +
+ (0004352) +
+ Jens Grabowski    +
+ 05-12-2007 18:05    +
+ 		+ + + + +
+ Operational semantics fixed.
+
+
+
+ + + + + + + + + + +
+ (0006672) +
+ Ina Schieferdecker    +
+ 01-09-2008 10:10    +
+ 		+ + + + +
+ The grammar rule for BasicStatements has not been changed as pointed out by Pavel Yakovenko, ISPRAS - this has still to be done.
+
+
+
+ + + + + + + + + + +
+ (0007004) +
+ Ina Schieferdecker    +
+ 07-10-2008 05:51    +
+ 		+ + + + +
+ This CR was only partially implemented in v3.4.1 - it has now being completed in v4.1.1
+
+ + diff --git a/docs/mantis/CR0419.md b/docs/mantis/CR0419.md new file mode 100644 index 0000000000000000000000000000000000000000..f7d47447b5b46d6e16d9fc6007df993be1f12fa9 --- /dev/null +++ b/docs/mantis/CR0419.md @@ -0,0 +1,155 @@ + + + + + + + + + + + + + 0000419: Identifying PTC host in create statements - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0000419Part 01: TTCN-3 Core LanguageNew Featurepublic24-11-2006 14:3918-07-2008 10:37
ReporterStephan Schulz 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityfeatureReproducibilityN/A
StatusclosedResolutionwon't fix 
PlatformOSOS Version
Product Versionv3.1.1 (published 2005-06) 
Target Versionv4.1.1 (published 2009-06)Fixed in Version 
Clause Reference(s)-
Source (company - Author)dr. György Réthy, Ericsson
Summary0000419: Identifying PTC host in create statements
DescriptionCurrently the TTCN-3 language is distinct from the execution environment. While this is acceptable in most cases, in some cases the test suite writer may want to put some limitations on the test configuration. For example, in embedded test configurations it is inevitable to create the upper tester PTCs on the tested system itself.
+It is suggested to allow the optional specification of a host ID at which the PTC has to be created as a second parameter of create operations. This second parameter shall be of charstring type and can be simply omitted if no host ID is being specified. If host ID should be present but no name is assigned to the PTC, the first parameter (PTC name) shall be skipped in the argument list by a dash.
+Please note the following:
+  - the interpretation of the host ID string still remains a tool option
+  - the reasonable user will use sound strings as host ID as module parameter, specific IP address (like 127.0.0.0) or e.g. return value of a function returning the name of a given host. No reason to believe that users will spoil test suite transport-ability by using hard-coded host names (or in this case they can spoil it by hard-coding many other values today).
+
+Example:
+testcase MyTC () runs on MyMTCType system MySytemType {
+  var MyPTCType vl_PTC [6];
+...
+  vl_PTC[0] := MyPTCType.create ("MyPTCwName");
+  vl_PTC[1] := MyPTCType.create ("MyPTCwName2",-);
+  vl_PTC[2] := MyPTCType.create ("MyPTCwNameAndLocation", "Myhost1");
+  vl_PTC[3] := MyPTCType.create (-, "Myhost2");
+  vl_PTC[4] := MyPTCType.create (-, "Myhost3") alive;
+  vl_PTC[5] := MyPTCType.create (-, "192.168.0.1") alive;
+...
+}
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0003794closed Ina Schieferdecker Support for deployment 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
24-11-2006 14:39Stephan SchulzNew Issue
24-11-2006 14:39Stephan SchulzClause Reference(s) => -
24-11-2006 14:39Stephan SchulzSource (company - Author) => dr. György Réthy, Ericsson
24-11-2006 15:03Stephan SchulzNote Added: 0000330
15-06-2007 19:13Stephan SchulzStatusnew => assigned
15-06-2007 19:13Stephan SchulzAssigned To => Ina Schieferdecker
13-10-2007 19:26Ina SchieferdeckerAssigned ToIna Schieferdecker => Jens Grabowski
15-10-2007 12:31Ina SchieferdeckerNote Added: 0003607
18-10-2007 11:35Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
18-07-2008 10:29Jens GrabowskiNote Added: 0006331
18-07-2008 10:30Jens GrabowskiAssigned ToJens Grabowski => Ina Schieferdecker
18-07-2008 10:30Jens GrabowskiResolutionopen => won't fix
18-07-2008 10:37Ina SchieferdeckerStatusassigned => closed
12-12-2008 16:01Ina SchieferdeckerRelationship addedrelated to 0003794
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0000330) +
+ Stephan Schulz    +
+ 24-11-2006 15:03    +
+ 		+ + + + +
+ To be discussed in respect of deployment in general
+
+
+
+ + + + + + + + + + +
+ (0003607) +
+ Ina Schieferdecker    +
+ 15-10-2007 12:31    +
+ 		+ + + + +
+ How does this parameter effect other parts of TTCN-3? It has relation to external PTCs, to invoke test cases, etc.
+
+If so, it should also be supported by execute.
+
+If so, it should also be added to TCI.
+
+It should be considered in the general area of test deployment/configuration - i.e. as wider scope and better to be considered in STF 2008.
+
+
+
+ + + + + + + + + + +
+ (0006331) +
+ Jens Grabowski    +
+ 18-07-2008 10:29    +
+ 		+ + + + +
+ The STF agreed that this CR won't fix. Deployment should be handled in a larger context. A general CR on support for deployment will be issued.
+
+ + diff --git a/docs/mantis/CR0420.md b/docs/mantis/CR0420.md new file mode 100644 index 0000000000000000000000000000000000000000..b9fd30e01bccf914a1d0543e7c95c0043fdd4330 --- /dev/null +++ b/docs/mantis/CR0420.md @@ -0,0 +1,82 @@ + + + + + + + + + + + + + 0000420: Semantics of optional statement blocks following altstep-branches - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0000420Part 01: TTCN-3 Core LanguageClarificationpublic24-11-2006 14:4112-03-2008 10:24
ReporterStephan Schulz 
Assigned ToIna Schieferdecker 
PrioritynormalSeveritytextReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.1.1 (published 2005-06) 
Target Versionv3.3.2 (published 2008-04)Fixed in Versionv3.3.2 (published 2008-04) 
Clause Reference(s)20.1.1
Source (company - Author)dr. György Réthy, Ericsson
Summary0000420: Semantics of optional statement blocks following altstep-branches
DescriptionOptional statement blocks have been allowed in altstep-branches of alt statements (CR 187). This addition has been introduced into the bnf but no semantic description has been inserted into the body the standard.
Steps To Reproduce
Additional Informationproppsed solution: Change text to ...
+
+20.1.1 Execution of alternative behaviour
+... (6th paragraph)
+An altstep-branch is selected if the Boolean guard is fulfilled. The selection of an altstep-branch causes the invocation of the referenced altstep, i.e. the altstep is invoked and the evaluation of the snapshot continues within the altstep. Altstep-branches may contain an optional block of statements and declarations. When an altstep-branch is selected, after executing the block of statements and declarations of the succeeding alternative of the altstep, the block of statements and declarations following the altstep call - if any - shall also be executed.
+...
+20.1.6 Invocation of altsteps as alternatives
+TTCN-3 allows the invocation of altsteps as alternatives in alt statements (see clause 16.2.3). When an altstep is explicitly invoked as an alternative, the block of statements and declarations optionally following the altstep call shall also be executed.
+EXAMPLE:
+     :
+    alt {
+      [] PCO3.receive { }
+      [] AnotherAltStep(){setverdict (inconc)};
+        // explicit call of altstep AnotherAltStep as alternative
+                            // of an alt statement with a block of statements and declarations following the altstep call.
+      [] MyTimer.timeout { }
+    }
+     :
+
+
TagsNo tags attached.
Relationships
Attached Filesdoc CR-420-Optional-Statementblock-Following-Altstep-Branches-Resolution.doc (227,328) 20-11-2007 08:09
http://oldforge.etsi.org/mantis/file_download.php?file_id=1129&type=bug
Issue History
Date ModifiedUsernameFieldChange
24-11-2006 14:41Stephan SchulzNew Issue
24-11-2006 14:41Stephan SchulzClause Reference(s) => 20.1.1
24-11-2006 14:41Stephan SchulzSource (company - Author) => dr. György Réthy, Ericsson
24-11-2006 14:41Stephan SchulzNote Added: 0000320
24-11-2006 14:41Stephan SchulzStatusnew => confirmed
15-06-2007 19:14Stephan SchulzStatusconfirmed => assigned
15-06-2007 19:14Stephan SchulzAssigned To => Ina Schieferdecker
13-10-2007 19:25Ina SchieferdeckerAssigned ToIna Schieferdecker => Jens Grabowski
18-10-2007 13:12Ina SchieferdeckerTarget Version => Edition 3.3.1 (not yet published)
20-11-2007 08:09Jens GrabowskiFile Added: CR-420-Optional-Statementblock-Following-Altstep-Branches-Resolution.doc
20-11-2007 08:10Jens GrabowskiAssigned ToJens Grabowski => Gyorgy Rethy
20-11-2007 08:10Jens GrabowskiResolutionopen => fixed
06-12-2007 18:30Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
06-12-2007 18:30Gyorgy RethyStatusassigned => resolved
07-12-2007 09:29Ina SchieferdeckerStatusresolved => closed
07-12-2007 09:29Ina SchieferdeckerFixed in Version => Edition 3.3.1 (not yet published)
12-03-2008 10:22user10Fixed in VersionEdition 3.3.1 --will not be published, see 3.3.2 => Edition 3.3.2 (not yet published)
12-03-2008 10:24user10Target VersionEdition 3.3.1 --will not be published, see 3.3.2 => Edition 3.3.2 (not yet published)
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0000320) +
+ Stephan Schulz    +
+ 24-11-2006 14:41    +
+ 		+ + + + +
+ Agreed in principle
+
+ + diff --git a/docs/mantis/CR0421.md b/docs/mantis/CR0421.md new file mode 100644 index 0000000000000000000000000000000000000000..cf72099a835d3b2e1538e5d6135160710ecb2929 --- /dev/null +++ b/docs/mantis/CR0421.md @@ -0,0 +1,100 @@ + + + + + + + + + + + + + 0000421: activated default within interleave - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0000421Part 01: TTCN-3 Core LanguageTechnicalpublic24-11-2006 14:4412-03-2008 10:24
ReporterStephan Schulz 
Assigned ToIna Schieferdecker 
PrioritylowSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.1.1 (published 2005-06) 
Target Versionv3.3.2 (published 2008-04)Fixed in Versionv3.3.2 (published 2008-04) 
Clause Reference(s)21.1
Source (company - Author)  Siemens
Summary0000421: activated default within interleave
DescriptionThere is no statement claiming that a default works within an interleave statement or not. Since the interleave statement can always be replaced with equivalent nested alt statements, the default mechanism should work within interleave in the same way. Otherwise both notations cannot be claimed to be identical.
+
+The default mechanism is invoked at end of an alt statement if due to the actual snapshot none of the specified aternatives could be executed. (21.1)
Steps To Reproduce
Additional InformationProposed Solution:
+The default mechanism should be invoked at end of an interleave statement. Its semantics should be defined such that it is in accordance with the equivalent statement using alt.
TagsNo tags attached.
Relationships
Attached Filesdoc CR-421-Default-In-Interleave-Resolution.doc (226,816) 19-11-2007 16:37
http://oldforge.etsi.org/mantis/file_download.php?file_id=1126&type=bug
doc CR-421-Default-In-Interleave-Resolution-Revision1-071205.doc (227,328) 05-12-2007 14:09
http://oldforge.etsi.org/mantis/file_download.php?file_id=1214&type=bug
Issue History
Date ModifiedUsernameFieldChange
24-11-2006 14:44Stephan SchulzNew Issue
24-11-2006 14:44Stephan SchulzClause Reference(s) => 21.1
24-11-2006 14:44Stephan SchulzSource (company - Author) => Siemens
24-11-2006 14:44Stephan SchulzNote Added: 0000321
24-11-2006 14:44Stephan SchulzStatusnew => confirmed
15-06-2007 19:14Stephan SchulzStatusconfirmed => assigned
15-06-2007 19:14Stephan SchulzAssigned To => Ina Schieferdecker
13-10-2007 19:25Ina SchieferdeckerAssigned ToIna Schieferdecker => Jens Grabowski
18-10-2007 13:11Ina SchieferdeckerTarget Version => Edition 3.3.1 (not yet published)
19-11-2007 16:37Jens GrabowskiFile Added: CR-421-Default-In-Interleave-Resolution.doc
19-11-2007 16:37Jens GrabowskiAssigned ToJens Grabowski => Stephan Schulz
19-11-2007 16:39Jens GrabowskiAssigned ToStephan Schulz => Gyorgy Rethy
19-11-2007 16:39Jens GrabowskiResolutionopen => fixed
05-12-2007 11:51Jens GrabowskiAssigned ToGyorgy Rethy => Jens Grabowski
05-12-2007 14:09Jens GrabowskiFile Added: CR-421-Default-In-Interleave-Resolution-Revision1-071205.doc
05-12-2007 14:10Jens GrabowskiAssigned ToJens Grabowski => Ina Schieferdecker
05-12-2007 14:10Jens GrabowskiStatusassigned => resolved
05-12-2007 17:48Ina SchieferdeckerStatusresolved => closed
05-12-2007 17:48Ina SchieferdeckerNote Added: 0004351
05-12-2007 17:48Ina SchieferdeckerFixed in Version => Edition 3.3.1 (not yet published)
12-03-2008 10:22user10Fixed in VersionEdition 3.3.1 --will not be published, see 3.3.2 => Edition 3.3.2 (not yet published)
12-03-2008 10:24user10Target VersionEdition 3.3.1 --will not be published, see 3.3.2 => Edition 3.3.2 (not yet published)
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0000321) +
+ Stephan Schulz    +
+ 24-11-2006 14:44    +
+ 		+ + + + +
+ Agreed in principle
+
+
+
+ + + + + + + + + + +
+ (0004351) +
+ Ina Schieferdecker    +
+ 05-12-2007 17:48    +
+ 		+ + + + +
+ Just little rewording to make the first additional note a bit easier to read.
+
+ + diff --git a/docs/mantis/CR0422.md b/docs/mantis/CR0422.md new file mode 100644 index 0000000000000000000000000000000000000000..3d55cad14e1e3fdf5c3ae83cc55f12e807cd03dd --- /dev/null +++ b/docs/mantis/CR0422.md @@ -0,0 +1,134 @@ + + + + + + + + + + + + + 0000422: sending templates with unassigned values via internal (connected) ports - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0000422Part 01: TTCN-3 Core LanguageNew Featurepublic24-11-2006 14:4615-07-2008 11:44
ReporterStephan Schulz 
Assigned ToJens Grabowski 
PrioritynormalSeverityfeatureReproducibilityN/A
StatusclosedResolutionwon't fix 
PlatformOSOS Version
Product Versionv3.1.1 (published 2005-06) 
Target Versionv4.1.1 (published 2009-06)Fixed in Version 
Clause Reference(s)14.1.1
Source (company - Author)Siemens
Summary0000422: sending templates with unassigned values via internal (connected) ports
DescriptionFor the send operation, the template shall be fully defined, i.e. all fields shall resolve to actual values. But for some reason, templates must be exchanged between different test components within the test system. Currently it is only allowed to use templates as parameters of a function, which could be used to start the behavior of a PTC. But there is no mechanism that allows the exchange of templates during runtime of the PTCs. We should allow send templates with undefined fields only for internal (connected) ports. For templates sent to SUT (mapped) ports, the template should remain fully defined.
+
+At the time of the send operation, the template shall be fully defined i.e. all fields shall resolve to actual values and no matching mechanisms shall be used in the template fields, neither directly nor indirectly. (14.1.1)
Steps To Reproduce
Additional InformationProposed Solution:
+It should be allowed that the a send template can contain matching values (*, ?, value lists, ranges, etc.) for internal (connected) ports. Matching rules to match matching values must be defined, e.g always use ? to match a matching value or * if the associated field is opional.
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
24-11-2006 14:46Stephan SchulzNew Issue
24-11-2006 14:46Stephan SchulzClause Reference(s) => 14.1.1
24-11-2006 14:46Stephan SchulzSource (company - Author) => Siemens
24-11-2006 14:47Stephan SchulzNote Added: 0000322
24-11-2006 14:47Stephan SchulzStatusnew => feedback
24-11-2006 15:02Stephan SchulzNote Added: 0000329
15-06-2007 19:14Stephan SchulzStatusfeedback => assigned
15-06-2007 19:14Stephan SchulzAssigned To => Ina Schieferdecker
13-10-2007 19:24Ina SchieferdeckerAssigned ToIna Schieferdecker => Jens Grabowski
18-10-2007 13:11Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
15-07-2008 11:43Ina SchieferdeckerNote Added: 0006274
15-07-2008 11:44Ina SchieferdeckerStatusassigned => closed
15-07-2008 11:44Ina SchieferdeckerResolutionopen => won't fix
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0000322) +
+ Stephan Schulz    +
+ 24-11-2006 14:47    +
+ 		+ + + + +
+ Waiting for providers response
+
+
+
+ + + + + + + + + + +
+ (0000329) +
+ Stephan Schulz    +
+ 24-11-2006 15:02    +
+ 		+ + + + +
+ We are expecting a more detailed description of the consequences, especially at the language level
+
+
+
+ + + + + + + + + + +
+ (0006274) +
+ Ina Schieferdecker    +
+ 15-07-2008 11:43    +
+ 		+ + + + +
+ could be done, but adds complexity to TTCN-3 which seems to be unneccessary as template passing could also be done via template parameters to test component functions
+
+ + diff --git a/docs/mantis/CR0423.md b/docs/mantis/CR0423.md new file mode 100644 index 0000000000000000000000000000000000000000..ddf54a182ee24c7ad95f4bd6a07a96126c67158a --- /dev/null +++ b/docs/mantis/CR0423.md @@ -0,0 +1,278 @@ + + + + + + + + + + + + + 0000423: Encode/Decode of empty record - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0000423Part 06: TTCN-3 Control InterfaceTechnicalpublic24-11-2006 14:4906-12-2007 11:11
ReporterStephan Schulz 
Assigned ToIna Schieferdecker 
PriorityhighSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.1.1 (published 2005-06) 
Target Versionv3.3.1 (published 2008-04)Fixed in Versionv3.3.1 (published 2008-04) 
Clause Reference(s)7.2.2.2.11
Source (company - Author)Siemens
Summary0000423: Encode/Decode of empty record
DescriptionCurrently there are three operations on RecordValue within TCI: getField, setField, and getFieldNames. There is however no operation that allows an empty record to be encoded/decoded. It should be also possible to encode/decode empty records. This extension is particularly helpful for quick-testing TTCN-3 code.
+
+Empty records are not handled in TCI, but can be specified in TTCN-3. (part 6: 7.2.2.2.11, part 1: 6.3.1.0)
Steps To Reproduce
Additional InformationProposed Solution:
+There should be one more operation that initializes an empty record of a certain "type" of data.
TagsNo tags attached.
Relationships
Attached Fileszip es_20187306v030301_CR423.zip (982,668) 04-12-2007 14:40
http://oldforge.etsi.org/mantis/file_download.php?file_id=1192&type=bug
Issue History
Date ModifiedUsernameFieldChange
24-11-2006 14:49Stephan SchulzNew Issue
24-11-2006 14:49Stephan SchulzClause Reference(s) => 7.2.2.2.11
24-11-2006 14:49Stephan SchulzSource (company - Author) => Siemens
24-11-2006 14:49Stephan SchulzNote Added: 0000323
24-11-2006 14:49Stephan SchulzStatusnew => feedback
24-11-2006 15:02Stephan SchulzNote Added: 0000328
15-06-2007 19:17Stephan SchulzStatusfeedback => assigned
15-06-2007 19:17Stephan SchulzAssigned To => Ina Schieferdecker
18-10-2007 13:10Ina SchieferdeckerTarget Version => Edition 3.3.1 (not yet published)
03-12-2007 15:40Thomas DeißNote Added: 0004243
04-12-2007 14:40Ina SchieferdeckerNote Added: 0004266
04-12-2007 14:40Ina SchieferdeckerFile Added: es_20187306v030301_CR423.zip
04-12-2007 14:41Ina SchieferdeckerNote Added: 0004267
04-12-2007 14:47Ina SchieferdeckerResolutionopen => fixed
04-12-2007 16:37Ina SchieferdeckerAssigned ToIna Schieferdecker => Thomas Deiß
04-12-2007 17:13Thomas DeißNote Added: 0004292
04-12-2007 17:13Thomas DeißStatusassigned => resolved
04-12-2007 17:14Thomas DeißStatusresolved => feedback
04-12-2007 17:14Thomas DeißResolutionfixed => reopened
04-12-2007 17:14Thomas DeißNote Added: 0004293
04-12-2007 17:15Thomas DeißAssigned ToThomas Deiß => Ina Schieferdecker
04-12-2007 17:15Thomas DeißStatusfeedback => resolved
04-12-2007 17:15Thomas DeißResolutionreopened => fixed
06-12-2007 11:11Ina SchieferdeckerStatusresolved => closed
06-12-2007 11:11Ina SchieferdeckerFixed in Version => Edition 3.3.1 (not yet published)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0000323) +
+ Stephan Schulz    +
+ 24-11-2006 14:49    +
+ 		+ + + + +
+ Waiting for providers comments
+
+
+
+ + + + + + + + + + +
+ (0000328) +
+ Stephan Schulz    +
+ 24-11-2006 15:02    +
+ 		+ + + + +
+ Provider to clarify if CreateNewInstance solves the problem
+
+
+
+ + + + + + + + + + +
+ (0004243) +
+ Thomas Deiß    +
+ 03-12-2007 15:40    +
+ 		+ + + + +
+ If a record type does not contain any fields, then obviously it is not possible to set a field to a specific value, nor set a field to be absent or present.
+
+But if a value of such a type is created, then it is uninitialized (see explanation of newInstance(), clause 7.2.2.1.).
+
+This means there is no means to create an initialized value of an empty record type. Hence, none can be used for encoding/decoding.
+
+I suggest to extend the TCI such that newly created instances of empty record and set types are considered initialized. Either a note could be added to the definition of newInstance() or to clause 7.2.2.11.
+
+Creating 'empty' records of arbitrary record types is not considered a good solution as mandatory fields would still have to be uninitialized.
+
+
+
+ + + + + + + + + + +
+ (0004266) +
+ Ina Schieferdecker    +
+ 04-12-2007 14:40    +
+ 		+ + + + +
+ Notes to both the NewInstance description and section 7.2.2.11 added
+
+
+
+ + + + + + + + + + +
+ (0004267) +
+ Ina Schieferdecker    +
+ 04-12-2007 14:41    +
+ 		+ + + + +
+ The resolution is using already the updated text from CR2000 and CR2146.
+
+
+
+ + + + + + + + + + +
+ (0004292) +
+ Thomas Deiß    +
+ 04-12-2007 17:13    +
+ 		+ + + + +
+ checked by Thomas, ok.
+
+
+
+ + + + + + + + + + +
+ (0004293) +
+ Thomas Deiß    +
+ 04-12-2007 17:14    +
+ 		+ + + + +
+ dummy action to assign CR properly
+
+ + diff --git a/docs/mantis/CR0424.md b/docs/mantis/CR0424.md new file mode 100644 index 0000000000000000000000000000000000000000..47435e1941a8c4a424906f9e1d64a6a0f09752b9 --- /dev/null +++ b/docs/mantis/CR0424.md @@ -0,0 +1,284 @@ + + + + + + + + + + + + + 0000424: operations on "record of" structures - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0000424Part 01: TTCN-3 Core LanguageNew Featurepublic24-11-2006 14:5112-03-2008 10:24
ReporterStephan Schulz 
Assigned ToIna Schieferdecker 
PriorityhighSeverityfeatureReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.1.1 (published 2005-06) 
Target Versionv3.3.2 (published 2008-04)Fixed in Versionv3.3.2 (published 2008-04) 
Clause Reference(s)6.3.3.0
Source (company - Author)Siemens
Summary0000424: operations on "record of" structures
DescriptionCurrently there are only limited operation on "record of" structures. It is rather clear that how could one element be added into the record of sturcure. But there is on explicit statement on how to remove certain element. It would be useful that the operations on "record of" could be explicitly defined.
+
+Currently only assignments to "record of" variables are possible, e.g.
+var MyRecordOf MyRecordVar := { 0, 1, 2, 3, 4 };
+// The assignment
+MyRecordVar := { 0, 1, -, 2, omit };
+// will change the value of MyRecordVar to { 0, 1, 2 <unchanged>, 2};
+// Note, that the 3rd element would be undefined if had had no previous assigned value. (6.3.3.0)
Steps To Reproduce
Additional InformationProposed Solution:
+The operations on "record of" should be explicitly defined. From the current situation we can only guess that the "omit" assignment to the 5th element in the list removes it. What happens if "omit" is assigned to an element in the middle of the list? Besides assignments, there should be operations to add/remove elements to/from a "record of" list, e.g. using the equivalent array notation:
+// add a new element
+MyRecordVar[sizeof(MyRecordVar)] := 5;
+// remove an element at the end of the list
+MyRecordVar[sizeof(MyRecordVar)-1] := omit;
+// remove an element in the middle of the list
+MyRecordVar[0] := omit; // ???
TagsNo tags attached.
Relationships
related to 0000382closed  Iterators for record of/set of structures 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
24-11-2006 14:51Stephan SchulzNew Issue
24-11-2006 14:51Stephan SchulzClause Reference(s) => 6.3.3.0
24-11-2006 14:51Stephan SchulzSource (company - Author) => Siemens
24-11-2006 14:51Stephan SchulzNote Added: 0000324
24-11-2006 14:51Stephan SchulzStatusnew => feedback
24-11-2006 15:01Stephan SchulzNote Added: 0000327
24-11-2006 15:05Stephan SchulzRelationship addedrelated to 0000382
15-06-2007 19:17Stephan SchulzStatusfeedback => assigned
15-06-2007 19:17Stephan SchulzAssigned To => Ina Schieferdecker
13-10-2007 19:17Ina SchieferdeckerAssigned ToIna Schieferdecker => developer_u
15-10-2007 13:32Ina SchieferdeckerNote Added: 0003614
17-10-2007 12:41user10Assigned Todeveloper_u => Thomas Deiß
18-10-2007 12:13Ina SchieferdeckerTarget Version => Edition 3.3.1 (not yet published)
19-10-2007 13:12Gyorgy RethyResolutionopen => fixed
19-10-2007 13:13Gyorgy RethyNote Added: 0003701
19-10-2007 13:13Gyorgy RethyNote Added: 0003702
03-12-2007 12:09Jens GrabowskiAssigned ToThomas Deiß => Ina Schieferdecker
04-12-2007 16:43Ina SchieferdeckerStatusassigned => resolved
06-12-2007 16:26Gyorgy RethyAssigned ToIna Schieferdecker => Thomas Deiß
06-12-2007 16:26Gyorgy RethyStatusresolved => feedback
06-12-2007 16:26Gyorgy RethyResolutionfixed => reopened
06-12-2007 16:26Gyorgy RethyNote Added: 0004390
06-12-2007 17:43Thomas DeißNote Added: 0004400
06-12-2007 17:44Thomas DeißAssigned ToThomas Deiß => Ina Schieferdecker
06-12-2007 17:44Thomas DeißStatusfeedback => resolved
06-12-2007 17:44Thomas DeißResolutionreopened => fixed
06-12-2007 18:05Ina SchieferdeckerStatusresolved => closed
06-12-2007 18:05Ina SchieferdeckerFixed in Version => Edition 3.3.1 (not yet published)
12-03-2008 10:22user10Fixed in VersionEdition 3.3.1 --will not be published, see 3.3.2 => Edition 3.3.2 (not yet published)
12-03-2008 10:24user10Target VersionEdition 3.3.1 --will not be published, see 3.3.2 => Edition 3.3.2 (not yet published)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0000324) +
+ Stephan Schulz    +
+ 24-11-2006 14:51    +
+ 		+ + + + +
+ Waiting for providers response
+
+
+
+ + + + + + + + + + +
+ (0000327) +
+ Stephan Schulz    +
+ 24-11-2006 15:01    +
+ 		+ + + + +
+ To separate problem is identified: - defining the semantics of omit in the contecx of record/set of; - predefined functions for inserting and removing elements to/from reocr/set of
+
+
+
+ + + + + + + + + + +
+ (0003614) +
+ Ina Schieferdecker    +
+ 15-10-2007 13:32    +
+ 		+ + + + +
+ To be considered in the broader context of operations on sequence-like types.
+
+
+
+ + + + + + + + + + +
+ (0003701) +
+ Gyorgy Rethy    +
+ 19-10-2007 13:13    +
+ 		+ + + + +
+ STF solution text is in the common file attached to CR383
+
+
+
+ + + + + + + + + + +
+ (0003702) +
+ Gyorgy Rethy    +
+ 19-10-2007 13:13    +
+ 		+ + + + +
+ STF solution text is in the common file attached to CR383
+
+
+
+ + + + + + + + + + +
+ (0004390) +
+ Gyorgy Rethy    +
+ 06-12-2007 16:26    +
+ 		+ + + + +
+ Functionality and example to be checked
+
+
+
+ + + + + + + + + + +
+ (0004400) +
+ Thomas Deiß    +
+ 06-12-2007 17:43    +
+ 		+ + + + +
+ The example is actually incorrect, omit cannot be used inside a record of. The example in the standard has been corrected.
+
+An element in a record of can be removed by using the function replace, which has been extend from strings to all list types.
+The solution is integrated into the solution of CR 383.
+
+ + diff --git a/docs/mantis/CR0425.md b/docs/mantis/CR0425.md new file mode 100644 index 0000000000000000000000000000000000000000..0714a40de2cf18bd0d012e365d9f686b7502ecae --- /dev/null +++ b/docs/mantis/CR0425.md @@ -0,0 +1,131 @@ + + + + + + + + + + + + + 0000425: Predefined function regexp - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0000425Part 01: TTCN-3 Core LanguageNew Featurepublic24-11-2006 14:5512-03-2008 10:24
ReporterStephan Schulz 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityfeatureReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.1.1 (published 2005-06) 
Target Versionv3.3.2 (published 2008-04)Fixed in Versionv3.3.2 (published 2008-04) 
Clause Reference(s)C.17
Source (company - Author)Testing Tech
Summary0000425: Predefined function regexp
DescriptionReplace current section on the regexp function
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Fileszip CR_421att Predefined function regexp.zip (586,181) 24-11-2006 14:55
http://oldforge.etsi.org/mantis/file_download.php?file_id=42&type=bug
doc STF_Solution_CR_425_v1.doc (300,032) 07-12-2007 13:52
http://oldforge.etsi.org/mantis/file_download.php?file_id=1250&type=bug
doc STF_Solution_CR_425_v1_a.doc (301,568) 07-12-2007 14:06
http://oldforge.etsi.org/mantis/file_download.php?file_id=1251&type=bug
Issue History
Date ModifiedUsernameFieldChange
24-11-2006 14:55Stephan SchulzNew Issue
24-11-2006 14:55Stephan SchulzFile Added: CR_421att Predefined function regexp.zip
24-11-2006 14:55Stephan SchulzClause Reference(s) => C.17
24-11-2006 14:55Stephan SchulzSource (company - Author) => Testing Tech
24-11-2006 15:00Stephan SchulzNote Added: 0000326
15-06-2007 19:15Stephan SchulzStatusnew => assigned
15-06-2007 19:15Stephan SchulzAssigned To => Ina Schieferdecker
13-10-2007 19:24Ina SchieferdeckerAssigned ToIna Schieferdecker => Gyorgy Rethy
18-10-2007 13:10Ina SchieferdeckerTarget Version => Edition 3.3.1 (not yet published)
07-12-2007 13:52Gyorgy RethyFile Added: STF_Solution_CR_425_v1.doc
07-12-2007 13:54Gyorgy RethyNote Added: 0004425
07-12-2007 13:54Gyorgy RethyAssigned ToGyorgy Rethy => Thomas Deiß
07-12-2007 13:54Gyorgy RethyResolutionopen => fixed
07-12-2007 14:06Thomas DeißFile Added: STF_Solution_CR_425_v1_a.doc
07-12-2007 14:07Thomas DeißNote Added: 0004426
07-12-2007 14:07Thomas DeißAssigned ToThomas Deiß => Ina Schieferdecker
07-12-2007 14:07Thomas DeißStatusassigned => resolved
09-12-2007 15:44Ina SchieferdeckerStatusresolved => closed
09-12-2007 15:44Ina SchieferdeckerFixed in Version => Edition 3.3.1 (not yet published)
12-03-2008 10:22user10Fixed in VersionEdition 3.3.1 --will not be published, see 3.3.2 => Edition 3.3.2 (not yet published)
12-03-2008 10:24user10Target VersionEdition 3.3.1 --will not be published, see 3.3.2 => Edition 3.3.2 (not yet published)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0000326) +
+ Stephan Schulz    +
+ 24-11-2006 15:00    +
+ 		+ + + + +
+ Two options discussed: either add as a new predefined function (old one to be corrected and completed with further examples) or allow in regexp both values and templates as "expression" parameter. Also the "expression" shall be of "character_string" type
+
+
+
+ + + + + + + + + + +
+ (0004425) +
+ Gyorgy Rethy    +
+ 07-12-2007 13:54    +
+ 		+ + + + +
+ STF proposal for internal review
+
+
+
+ + + + + + + + + + +
+ (0004426) +
+ Thomas Deiß    +
+ 07-12-2007 14:07    +
+ 		+ + + + +
+ checked by Thomas, ok. 2 Typos in the last example corrected.
+
+ + diff --git a/docs/mantis/CR0426.md b/docs/mantis/CR0426.md new file mode 100644 index 0000000000000000000000000000000000000000..41a9dc91e993315afdcf64f8c372ca850cf1fe25 --- /dev/null +++ b/docs/mantis/CR0426.md @@ -0,0 +1,63 @@ + + + + + + + + + + + + + 0000426: References in character patterns - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0000426Part 01: TTCN-3 Core LanguageClarificationpublic24-11-2006 14:5812-12-2008 11:45
ReporterStephan Schulz 
Assigned To 
PrioritynormalSeveritytextReproducibilityN/A
StatusclosedResolutionwon't fix 
PlatformOSOS Version
Product Versionv3.1.1 (published 2005-06) 
Target Versionv3.2.1 (published 2007-02)Fixed in Version 
Clause Reference(s)B.1.5.2
Source (company - Author)Testing Tech
Summary0000426: References in character patterns
DescriptionIncorrect wording used in reference expression clause.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Fileszip CR_422att References in character patterns.zip (587,561) 24-11-2006 14:58
http://oldforge.etsi.org/mantis/file_download.php?file_id=43&type=bug
Issue History
Date ModifiedUsernameFieldChange
24-11-2006 14:58Stephan SchulzNew Issue
24-11-2006 14:58Stephan SchulzFile Added: CR_422att References in character patterns.zip
24-11-2006 14:58Stephan SchulzClause Reference(s) => B.1.5.2
24-11-2006 14:58Stephan SchulzSource (company - Author) => Testing Tech
24-11-2006 14:59Stephan SchulzStatusnew => closed
24-11-2006 14:59Stephan SchulzNote Added: 0000325
24-11-2006 14:59Stephan SchulzResolutionopen => won't fix
12-12-2008 11:45Ina SchieferdeckerTarget Version => Edition 3.2.1
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0000325) +
+ Stephan Schulz    +
+ 24-11-2006 14:59    +
+ 		+ + + + +
+ Rejected. Correct single-double quote mark inconsistency through the whole close.
+
+ + diff --git a/docs/mantis/CR0427.md b/docs/mantis/CR0427.md new file mode 100644 index 0000000000000000000000000000000000000000..53b6bf9c030962224ffe527198100b18077c135f --- /dev/null +++ b/docs/mantis/CR0427.md @@ -0,0 +1,54 @@ + + + + + + + + + + + + + 0000427: Clarification of record/set of subtyping - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0000427Part 01: TTCN-3 Core LanguageClarificationpublic24-11-2006 15:1512-12-2008 11:48
ReporterStephan Schulz 
Assigned To 
PrioritynormalSeveritytextReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.1.1 (published 2005-06) 
Target Versionv3.2.1 (published 2007-02)Fixed in Versionv3.2.1 (published 2007-02) 
Clause Reference(s)6.2.3
Source (company - Author)dr. György Réthy, Ericsson
Summary0000427: Clarification of record/set of subtyping
DescriptionCurrently the standard gives a few examples on subtyping of record/set of types but no semantic description. This may lead to confusions in more complex cases, e.g. in record of record of types.
Steps To Reproduce
Additional InformationProposed solution - chnage text to:
+6.2.3 Records and sets of single types
+TTCN 3 supports the specification of records and sets whose elements are all of the same type. These are denoted using the keyword of. These records and sets do not have element identifiers and can be considered similar to an ordered array and an unordered array respectively.
+The length keyword followed by a value or a range within brackets and used between the record or set and the of keywords restricts the allowed lengths of the given record of or set of type.
+
+NOTE: Type restriction related to the innermost type is placed after the name of the newly defined type. Note that the innermost type can never be a set of or record of. Hence type restrictions related to record of or set of types are always placed between their record/set and of keywords.
+
+
+EXAMPLE 1:
+    type record length(10) of integer MyRecordOfType; // is a record of exactly 10 integers
+
+    type record length(0..10) of integer MyRecordOfType; // is a record of a maximum of 10 integers
+
+    type record length(10..infinity) of integer MyRecordOfType; // record of at least 10 integers
+
+    type set of boolean MySetOfType; // is an unlimited set of boolean values
+
+    type record length(0..10) of charstring StringArray length(12);
+    // is a record of a maximum of 10 strings each with exactly 12 characters
+
+    type record of record of charstring StringArray length(12);
+    // is a two-dimensional unlimited array of strings each with exactly 12 characters
+
+    type set length(5)of set length(6) of charstring StringArray length(12);
+    // is an unordered two-dimensional array of the size 5*6 of strings each with exactly 12 characters
+
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
24-11-2006 15:15Stephan SchulzNew Issue
24-11-2006 15:15Stephan SchulzClause Reference(s) => 6.2.3
24-11-2006 15:15Stephan SchulzSource (company - Author) => dr. György Réthy, Ericsson
24-11-2006 15:15Stephan SchulzStatusnew => closed
24-11-2006 15:15Stephan SchulzResolutionopen => fixed
24-11-2006 15:15Stephan SchulzFixed in Version => Edition 3.1.1
12-12-2008 11:48Ina SchieferdeckerFixed in VersionEdition 3.1.1 => Edition 3.2.1
12-12-2008 11:48Ina SchieferdeckerTarget Version => Edition 3.2.1
+
+ + + + +
+ There are no notes attached to this issue.
+ + diff --git a/docs/mantis/CR0567.md b/docs/mantis/CR0567.md new file mode 100644 index 0000000000000000000000000000000000000000..0acbd3655cbbb8b10c9dc6a357b9afadfafed2ca --- /dev/null +++ b/docs/mantis/CR0567.md @@ -0,0 +1,96 @@ + + + + + + + + + + + + + 0000567: Asymetry between sender and recipient addresses in muticast operations - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0000567Part 01: TTCN-3 Core LanguageTechnicalpublic19-01-2007 15:0712-03-2008 10:24
ReporterPavel Yakovenko 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.1.1 (published 2005-06) 
Target Versionv3.3.2 (published 2008-04)Fixed in Versionv3.3.2 (published 2008-04) 
Clause Reference(s)374
Source (company - Author)Pavel Yakovenko, ISPRAS
Summary0000567: Asymetry between sender and recipient addresses in muticast operations
DescriptionThere exists confusing asymmetry between sender and recipient addresses in multicast operations which doesn't allow specifying incompatible component references in multicast receive. Just compare ToClause(0000347) and FromClause(0000374) BNF rules.
+
+When sending data one may use ?(recipient1, recipient2, recipient3)? list of inline templates in multicast send. Since this is not a ?value list? all entries in this list may have different and incompatible types.
+
+For example:
+
+type component CT1 {
+  port PT P1
+}
+type component CT2 {
+  port PT P2
+}
+
+function f() {
+  var CT1 c1 := CT1.create;
+  var CT2 c2 := CT2.create;
+
+  P.send(1) to (c1, c2); //CORRECT, although C1 and C2 are not compatible
+}
+
+But when specifying valid senders in multicast receive we have to use ?value list? notation and all entries must have compatible types.
+
+function f() {
+  var CT1 c1 := CT1.create;
+  var CT2 c2 := CT2.create;
+
+  P.receive(1) from (c1, c2); //ILLEGAL, type error since CT1 and CT2 are incompatible
+}
+
+This issue may be resolved by changing BNF rule 0000374 to:
+
+FromClause ::= FromKeyword (AddressRef | AddressRefList | AnyKeyword ComponentKeyword)
+
+In this case "from any component" (or "from ?") has the same meaning as not specifying sender address at all but such notation may be used to make TTCN-3 code more clear to the reader.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR-567-Asymetry-Between-Sender-and-Recipient-Addresses-in-Muticast-Operations-Resolution.doc (1,084,928) 04-12-2007 15:43
http://oldforge.etsi.org/mantis/file_download.php?file_id=1197&type=bug
Issue History
Date ModifiedUsernameFieldChange
19-01-2007 15:07Pavel YakovenkoNew Issue
19-01-2007 15:07Pavel YakovenkoClause Reference(s) => 374
19-01-2007 15:07Pavel YakovenkoSource (company - Author) => Pavel Yakovenko, ISPRAS
15-06-2007 19:12Stephan SchulzStatusnew => assigned
15-06-2007 19:12Stephan SchulzAssigned To => Ina Schieferdecker
13-10-2007 18:45Ina SchieferdeckerAssigned ToIna Schieferdecker => Jens Grabowski
18-10-2007 13:07Ina SchieferdeckerTarget Version => Edition 3.3.1 (not yet published)
18-10-2007 13:07Ina SchieferdeckerDescription Updated
04-12-2007 15:43Jens GrabowskiFile Added: CR-567-Asymetry-Between-Sender-and-Recipient-Addresses-in-Muticast-Operations-Resolution.doc
04-12-2007 15:43Jens GrabowskiAssigned ToJens Grabowski =>
04-12-2007 15:44Jens GrabowskiAssigned To => Thomas Deiß
04-12-2007 15:44Jens GrabowskiResolutionopen => fixed
04-12-2007 17:03Thomas DeißNote Added: 0004290
04-12-2007 17:03Thomas DeißAssigned ToThomas Deiß => Ina Schieferdecker
04-12-2007 17:03Thomas DeißStatusassigned => resolved
05-12-2007 17:18Ina SchieferdeckerStatusresolved => closed
05-12-2007 17:18Ina SchieferdeckerFixed in Version => Edition 3.3.1 (not yet published)
12-03-2008 10:22user10Fixed in VersionEdition 3.3.1 --will not be published, see 3.3.2 => Edition 3.3.2 (not yet published)
12-03-2008 10:24user10Target VersionEdition 3.3.1 --will not be published, see 3.3.2 => Edition 3.3.2 (not yet published)
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0004290) +
+ Thomas Deiß    +
+ 04-12-2007 17:03    +
+ 		+ + + + +
+ checked by Thomas, ok.
+
+ + diff --git a/docs/mantis/CR0826.md b/docs/mantis/CR0826.md new file mode 100644 index 0000000000000000000000000000000000000000..acbcf682776a7fb4b80fa93d9a64f8f8515071f5 --- /dev/null +++ b/docs/mantis/CR0826.md @@ -0,0 +1,176 @@ + + + + + + + + + + + + + 0000826: setFieldOmitted() ANSI C mapping problem - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0000826Part 06: TTCN-3 Control InterfaceEditorialpublic12-03-2007 15:3006-12-2007 11:14
ReporterMateusz Pusz 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv3.3.1 (published 2008-04)Fixed in Versionv3.3.1 (published 2008-04) 
Clause Reference(s)9.2
Source (company - Author)Mateusz Pusz, Intel
Summary0000826: setFieldOmitted() ANSI C mapping problem
DescriptionVersion 3.2.1 defines incorect setFieldOmitted() ANSI C language mapping.
Steps To Reproduce
Additional InformationVersion 3.2.1 definition is:
+setFieldOmitted(String fieldName)
+
+The correct definition should look like:
+tciSetFieldOmmited(TciValue inst, String fieldName)
+
+It provides:
+- consistent naming convention with other functions
+- an object on which action should be taken
TagsNo tags attached.
Relationships
Attached Fileszip es_20187306v030301_CR826.zip (981,577) 04-12-2007 14:46
http://oldforge.etsi.org/mantis/file_download.php?file_id=1193&type=bug
Issue History
Date ModifiedUsernameFieldChange
12-03-2007 15:30Mateusz PuszNew Issue
12-03-2007 15:30Mateusz PuszClause Reference(s) => 9.2
12-03-2007 15:30Mateusz PuszSource (company - Author) => Mateusz Pusz, Intel
01-06-2007 17:41Ina SchieferdeckerNote Added: 0002126
15-06-2007 19:07Stephan SchulzStatusnew => assigned
15-06-2007 19:07Stephan SchulzAssigned To => Ina Schieferdecker
18-10-2007 13:07Ina SchieferdeckerTarget Version => Edition 3.3.1 (not yet published)
04-12-2007 14:45Ina SchieferdeckerNote Added: 0004268
04-12-2007 14:46Ina SchieferdeckerFile Added: es_20187306v030301_CR826.zip
04-12-2007 14:49Ina SchieferdeckerNote Added: 0004269
04-12-2007 14:49Ina SchieferdeckerResolutionopen => fixed
04-12-2007 16:37Ina SchieferdeckerAssigned ToIna Schieferdecker => Thomas Deiß
04-12-2007 17:19Thomas DeißNote Added: 0004295
04-12-2007 17:19Thomas DeißAssigned ToThomas Deiß => Ina Schieferdecker
04-12-2007 17:19Thomas DeißStatusassigned => resolved
06-12-2007 11:14Ina SchieferdeckerStatusresolved => closed
06-12-2007 11:14Ina SchieferdeckerFixed in Version => Edition 3.3.1 (not yet published)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0002126) +
+ Ina Schieferdecker    +
+ 01-06-2007 17:41    +
+ 		+ + + + +
+ right, inst is missing
+
+
+
+ + + + + + + + + + +
+ (0004268) +
+ Ina Schieferdecker    +
+ 04-12-2007 14:45    +
+ 		+ + + + +
+ The definition should be
+
+void setFieldOmitted
+ (TciValue inst, String fieldName)
+
+
+
+ + + + + + + + + + +
+ (0004269) +
+ Ina Schieferdecker    +
+ 04-12-2007 14:49    +
+ 		+ + + + +
+ The resolution is using already the updated text from CR2000, CR2146 and CR423.
+
+
+
+ + + + + + + + + + +
+ (0004295) +
+ Thomas Deiß    +
+ 04-12-2007 17:19    +
+ 		+ + + + +
+ checked by Thomas, ok.
+
+ + diff --git a/docs/mantis/CR0827.md b/docs/mantis/CR0827.md new file mode 100644 index 0000000000000000000000000000000000000000..b98a8f83cf7a0f43c772dba3324e8e03e515f5f9 --- /dev/null +++ b/docs/mantis/CR0827.md @@ -0,0 +1,63 @@ + + + + + + + + + + + + + 0000827: 3.2.1 PortStatusType definition - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0000827Part 06: TTCN-3 Control InterfaceClarificationpublic12-03-2007 15:3304-12-2007 14:51
ReporterMateusz Pusz 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionwon't fix 
PlatformOSOS Version
Product Version 
Target Versionv3.3.1 (published 2008-04)Fixed in Version 
Clause Reference(s)7.2.3.4
Source (company - Author)Mateusz Pusz, Intel
Summary0000827: 3.2.1 PortStatusType definition
DescriptionPortStatusType is defined in 3.2.1 standard but it seems to not be used anywhere.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
12-03-2007 15:33Mateusz PuszNew Issue
12-03-2007 15:33Mateusz PuszClause Reference(s) => 7.2.3.4
12-03-2007 15:33Mateusz PuszSource (company - Author) => Mateusz Pusz, Intel
01-06-2007 17:38Ina SchieferdeckerNote Added: 0002125
15-06-2007 19:07Stephan SchulzStatusnew => assigned
15-06-2007 19:07Stephan SchulzAssigned To => Ina Schieferdecker
18-10-2007 13:05Ina SchieferdeckerTarget Version => Edition 3.3.1 (not yet published)
04-12-2007 14:51Ina SchieferdeckerStatusassigned => closed
04-12-2007 14:51Ina SchieferdeckerResolutionopen => won't fix
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0002125) +
+ Ina Schieferdecker    +
+ 01-06-2007 17:38    +
+ 		+ + + + +
+ It is used in the logging interface of TCI
+
+ + diff --git a/docs/mantis/CR0828.md b/docs/mantis/CR0828.md new file mode 100644 index 0000000000000000000000000000000000000000..9506707687ef80a824ec442d24f2e6c7988f6776 --- /dev/null +++ b/docs/mantis/CR0828.md @@ -0,0 +1,176 @@ + + + + + + + + + + + + + 0000828: TciValue, TciValueTemplate, TciType not defined in ANSI C definition - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0000828Part 06: TTCN-3 Control InterfaceTechnicalpublic12-03-2007 15:4906-12-2007 11:20
ReporterMateusz Pusz 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv3.3.1 (published 2008-04)Fixed in Versionv3.3.1 (published 2008-04) 
Clause Reference(s)7.2.2.2
Source (company - Author)Mateusz Pusz, Intel
Summary0000828: TciValue, TciValueTemplate, TciType not defined in ANSI C definition
DescriptionTTCN standard does not define TciValue, TciValueTemplate, TciType types.
Steps To Reproduce
Additional InformationIf someone would like to create own TTCN-3 test environment (TM, TL, CH, CD, SA, PA) using ANSI C language mappings and he would like that solution to be TE provider independent than definitions of TciValue, TciValueTemplate, TciType would be necessary. Otherwise all libraries would not compile.
+
+I suggest using of following definitions:
+typedef void* TciValue;
+typedef void* TciValueTemplate;
+typedef void* TciType;
+
+That solution is portable. Using it by vendors will not be a big effort. It also supports creating vendor independent libraries that will compile with no problems.
TagsNo tags attached.
Relationships
Attached Fileszip es_20187306v030301_CR828.zip (983,784) 04-12-2007 15:05
http://oldforge.etsi.org/mantis/file_download.php?file_id=1194&type=bug
Issue History
Date ModifiedUsernameFieldChange
12-03-2007 15:49Mateusz PuszNew Issue
12-03-2007 15:49Mateusz PuszClause Reference(s) => 7.2.2.2
12-03-2007 15:49Mateusz PuszSource (company - Author) => Mateusz Pusz, Intel
04-05-2007 14:40Mateusz PuszNote Added: 0001687
14-05-2007 10:41Mateusz PuszNote Deleted: 0001687
15-06-2007 19:09Stephan SchulzStatusnew => assigned
15-06-2007 19:09Stephan SchulzAssigned To => Ina Schieferdecker
18-10-2007 13:05Ina SchieferdeckerTarget Version => Edition 3.3.1 (not yet published)
04-12-2007 15:04Ina SchieferdeckerNote Added: 0004270
04-12-2007 15:04Ina SchieferdeckerNote Added: 0004271
04-12-2007 15:05Ina SchieferdeckerFile Added: es_20187306v030301_CR828.zip
04-12-2007 15:06Ina SchieferdeckerNote Added: 0004273
04-12-2007 15:06Ina SchieferdeckerResolutionopen => fixed
04-12-2007 16:36Ina SchieferdeckerAssigned ToIna Schieferdecker => Thomas Deiß
04-12-2007 18:04Thomas DeißNote Added: 0004301
04-12-2007 18:04Thomas DeißAssigned ToThomas Deiß => Ina Schieferdecker
04-12-2007 18:04Thomas DeißStatusassigned => resolved
06-12-2007 11:20Ina SchieferdeckerStatusresolved => closed
06-12-2007 11:20Ina SchieferdeckerFixed in Version => Edition 3.3.1 (not yet published)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0004270) +
+ Ina Schieferdecker    +
+ 04-12-2007 15:04    +
+ 		+ + + + +
+ There is no TciValue in TCI - but just Value - its C mapping is defined in 9.2
+
+TciValueTemplate has been defined along the fixes for CR2000 - and is now being defined in 9.3
+
+There is no TciType in TCI - but just Type - its C mapping is defined in 9.2
+
+
+
+ + + + + + + + + + +
+ (0004271) +
+ Ina Schieferdecker    +
+ 04-12-2007 15:04    +
+ 		+ + + + +
+ All TciValue and TciType occurrences have been replaced by Value and Type respectively.
+
+
+
+ + + + + + + + + + +
+ (0004273) +
+ Ina Schieferdecker    +
+ 04-12-2007 15:06    +
+ 		+ + + + +
+ The resolution is using already the updated text from CR2000, CR2146, CR423, and CR826.
+
+
+
+ + + + + + + + + + +
+ (0004301) +
+ Thomas Deiß    +
+ 04-12-2007 18:04    +
+ 		+ + + + +
+ checked by Thomas, ok.
+
+ + diff --git a/docs/mantis/CR0829.md b/docs/mantis/CR0829.md new file mode 100644 index 0000000000000000000000000000000000000000..c9c1ac5aff5d5adad292a8ede407e74e5a0a3651 --- /dev/null +++ b/docs/mantis/CR0829.md @@ -0,0 +1,107 @@ + + + + + + + + + + + + + 0000829: C++ language mapping - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 05: TTCN-3 Runtime Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0000829Part 05: TTCN-3 Runtime Interface New Featurepublic12-03-2007 16:0312-12-2008 12:03
ReporterMateusz Pusz 
Assigned To 
PrioritynormalSeveritymajorReproducibilityN/A
StatusclosedResolutionsuspended 
PlatformOSOS Version
Product Versionv3.2.1 (published 2007-02) 
Target Versionv4.1.1 (published 2009-06)Fixed in Version 
Clause Reference(s)TCI, TRI
Source (company - Author)Mateusz Pusz, Intel
Summary0000829: C++ language mapping
DescriptionC++ language mapping will be welcomed
Steps To Reproduce
Additional InformationIn general current Java and ANSI C language looks like this:
+
+         JAVA | ANSI C
+good object oriented design | object oriented design simulation
+slow solution | very fast solution
+
+Java is very strong language for development. Its inteface is object oriented and well defined. The weakest point of Java solution is its performance.
+
+ANSI C solution should be very fast but it does not support object oriented design. Because of that there are many problems with memory management (it is not defined who allocates and who frees memory - it may be performance problem too), lack of constants (i.e. 'String' defined as 'char *' - library users can overwrite string and cause library to segfault; event when 'const' is used with TRI structs like 'BinaryString' all pointed values can be modified) and lack of abstract data typing (i.e. TciValue, TciType).
+
+It would be great to provide C++ language mapping. It will be strong solution that will contain best from existing definitions: it will be object oriented, safe in 'const' meaning, address all memory management problems and will be very fast.
TagsNo tags attached.
Relationships
related to 0003796closed Ina Schieferdecker Part 05: TTCN-3 Runtime Interface  C++ Mapping for TRI 
related to 0004253closed Ina Schieferdecker Part 06: TTCN-3 Control Interface C++ Mapping for TCI 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
12-03-2007 16:03Mateusz PuszNew Issue
12-03-2007 16:03Mateusz PuszClause Reference(s) => TCI, TRI
12-03-2007 16:03Mateusz PuszSource (company - Author) => Mateusz Pusz, Intel
15-06-2007 19:12Stephan SchulzStatusnew => assigned
15-06-2007 19:12Stephan SchulzAssigned To => Ina Schieferdecker
13-10-2007 18:47Ina SchieferdeckerAssigned ToIna Schieferdecker =>
13-10-2007 18:52Ina SchieferdeckerStatusassigned => new
18-10-2007 13:30Ina SchieferdeckerStatusnew => feedback
18-10-2007 13:32Ina SchieferdeckerNote Added: 0003693
13-08-2008 10:24Ina SchieferdeckerNote Added: 0006508
13-08-2008 10:24Ina SchieferdeckerStatusfeedback => closed
13-08-2008 10:24Ina SchieferdeckerResolutionopen => won't fix
12-12-2008 12:01Ina SchieferdeckerProjectTTCN-3 Change Requests => Part 05: TTCN-3 Runtime Interface
12-12-2008 12:02Ina SchieferdeckerResolutionwon't fix => suspended
12-12-2008 12:02Ina SchieferdeckerProduct Version => Edition 3.2.1
12-12-2008 12:02Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
12-12-2008 12:02Ina SchieferdeckerRelationship addedrelated to 0003796
12-12-2008 12:03Ina SchieferdeckerRelationship addedrelated to 0004253
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0003693) +
+ Ina Schieferdecker    +
+ 18-10-2007 13:32    +
+ 		+ + + + +
+ This would definitely be a useful extension, but it would only be included along a rather complete CR solution proposal by the submitter.
+
+
+
+ + + + + + + + + + +
+ (0006508) +
+ Ina Schieferdecker    +
+ 13-08-2008 10:24    +
+ 		+ + + + +
+ No feedback being received.
+
+ + diff --git a/docs/mantis/CR0830.md b/docs/mantis/CR0830.md new file mode 100644 index 0000000000000000000000000000000000000000..e487d6262336f450f7f5acf56458f666c758ea27 --- /dev/null +++ b/docs/mantis/CR0830.md @@ -0,0 +1,106 @@ + + + + + + + + + + + + + 0000830: Lack of 'const' usage - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0000830Part 06: TTCN-3 Control InterfaceTechnicalpublic12-03-2007 16:1106-12-2007 11:51
ReporterMateusz Pusz 
Assigned ToIna Schieferdecker 
PrioritynormalSeveritymajorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv3.3.1 (published 2008-04)Fixed in Versionv3.3.1 (published 2008-04) 
Clause Reference(s)9
Source (company - Author)Mateusz Pusz, Intel
Summary0000830: Lack of 'const' usage
DescriptionTCI interface does not use 'const' in its declarations.
Steps To Reproduce
Additional InformationTCI does not define ANSI C language mapping to be as fast and safe as TRI does. Pointers are not used namely. The problem is that there are some pointers 'hidden' by its types i.e.: String = char *.
+
+It is not safe. Vendor provided library can be easily crashed by user when accidentaly overwriting data pointed by 'String' type. Using 'const String' does not solve the problem because it defines 'char * const' which is different than 'const char *'.
+
+It can be major library stability issue.
TagsNo tags attached.
Relationships
Attached Filesdoc CR_830_solution.doc (878,592) 03-12-2007 14:57
http://oldforge.etsi.org/mantis/file_download.php?file_id=1179&type=bug
Issue History
Date ModifiedUsernameFieldChange
12-03-2007 16:11Mateusz PuszNew Issue
12-03-2007 16:11Mateusz PuszClause Reference(s) => 9
12-03-2007 16:11Mateusz PuszSource (company - Author) => Mateusz Pusz, Intel
15-06-2007 19:11Stephan SchulzStatusnew => assigned
15-06-2007 19:11Stephan SchulzAssigned To => Ina Schieferdecker
15-10-2007 17:15Ina SchieferdeckerAssigned ToIna Schieferdecker => developer_u
17-10-2007 12:42user10Assigned Todeveloper_u => Thomas Deiß
18-10-2007 12:09Ina SchieferdeckerTarget Version => Edition 3.3.1 (not yet published)
03-12-2007 14:57Thomas DeißNote Added: 0004238
03-12-2007 14:57Thomas DeißFile Added: CR_830_solution.doc
03-12-2007 14:58Thomas DeißAssigned ToThomas Deiß => Ina Schieferdecker
04-12-2007 16:35Ina SchieferdeckerStatusassigned => resolved
04-12-2007 16:35Ina SchieferdeckerResolutionopen => fixed
06-12-2007 11:51Ina SchieferdeckerStatusresolved => closed
06-12-2007 11:51Ina SchieferdeckerNote Added: 0004371
06-12-2007 11:51Ina SchieferdeckerFixed in Version => Edition 3.3.1 (not yet published)
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0004238) +
+ Thomas Deiß    +
+ 03-12-2007 14:57    +
+ 		+ + + + +
+ In the TCI interface most of the parameters are passed as values, whereas in the TRI interface most of the parameters are passed by reference. Therefore the usage of 'const' does not make a real difference for the TCI.
+
+Therefore no change will be done.
+
+When checking the CR a couple of typographical errors have been found, these will be corrected.
+
+
+
+ + + + + + + + + + +
+ (0004371) +
+ Ina Schieferdecker    +
+ 06-12-2007 11:51    +
+ 		+ + + + +
+ Value as to be used - instead of TciValue.
+The in direction for parameters is removed for the C mapping.
+
+ + diff --git a/docs/mantis/CR0831.md b/docs/mantis/CR0831.md new file mode 100644 index 0000000000000000000000000000000000000000..8a356ec845dd30c2da6cbd019f2fbf0e8aaf24dc --- /dev/null +++ b/docs/mantis/CR0831.md @@ -0,0 +1,63 @@ + + + + + + + + + + + + + 0000831: No memory management for ANSI C language mappings - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 05: TTCN-3 Runtime Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0000831Part 05: TTCN-3 Runtime Interface Technicalpublic12-03-2007 16:1604-12-2007 16:42
ReporterMateusz Pusz 
Assigned ToIna Schieferdecker 
PrioritynormalSeveritymajorReproducibilityN/A
StatusclosedResolutionwon't fix 
PlatformOSOS Version
Product Version 
Target Versionv3.1.1 (published 2005-06)Fixed in Version 
Clause Reference(s)TCI, TRI
Source (company - Author)Mateusz Pusz, Intel
Summary0000831: No memory management for ANSI C language mappings
DescriptionTTCN-3 standard does not define memory management for ANSI C language mappings.
Steps To Reproduce
Additional InformationThere are many ANSI C functions that for example pass or return names. It is not defined in TTCN-3 standard who allocates those strings and who is responsible for destroying them (and in what way: 'delete' or 'free'). It is a major issue and may cause memory leakage.
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
12-03-2007 16:16Mateusz PuszNew Issue
12-03-2007 16:16Mateusz PuszClause Reference(s) => TCI, TRI
12-03-2007 16:16Mateusz PuszSource (company - Author) => Mateusz Pusz, Intel
15-06-2007 19:11Stephan SchulzStatusnew => assigned
15-06-2007 19:11Stephan SchulzAssigned To => Ina Schieferdecker
18-10-2007 14:21Ina SchieferdeckerProjectTTCN-3 Change Requests => Part 05: TTCN-3 Runtime Interface
18-10-2007 14:23Ina SchieferdeckerTarget Version => Edition 3.1.1
04-12-2007 16:42Ina SchieferdeckerNote Added: 0004285
04-12-2007 16:42Ina SchieferdeckerStatusassigned => closed
04-12-2007 16:42Ina SchieferdeckerResolutionopen => won't fix
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0004285) +
+ Ina Schieferdecker    +
+ 04-12-2007 16:42    +
+ 		+ + + + +
+ There has been once a decision to leave memory management out of the TTCN-3 standard.
+
+ + diff --git a/docs/mantis/CR0834.md b/docs/mantis/CR0834.md new file mode 100644 index 0000000000000000000000000000000000000000..cc83f3240468077e6c1c0fe110dc11009bc3e94e --- /dev/null +++ b/docs/mantis/CR0834.md @@ -0,0 +1,65 @@ + + + + + + + + + + + + + 0000834: ANSI C Integer interface definition problem. - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0000834Part 06: TTCN-3 Control InterfaceTechnicalpublic12-03-2007 16:2418-10-2007 12:31
ReporterMateusz Pusz 
Assigned ToIna Schieferdecker 
PrioritynormalSeveritymajorReproducibilityhave not tried
StatusclosedResolutionwon't fix 
PlatformOSOS Version
Product Version 
Target Versionv3.3.1 (published 2008-04)Fixed in Version 
Clause Reference(s)9.2
Source (company - Author)Mateusz Pusz, Intel
Summary0000834: ANSI C Integer interface definition problem.
DescriptionTCI defines Integer interface in different ways for Java and ANSI C mapping. It will be welcomed to have easier interface for TTCN-3 Integer type.
Steps To Reproduce
Additional InformationANSI C interface of Integer is very complicated. It makes terrible overhead when someone wants to decode simple integers (i.e. IP Address). Someone must convert a value to 10-base string representation and pass it to TE. This is very low performance solution.
+
+I assume that it is a feature to support "infinity" values, but Java interface is simpler and as far as I know Java 'int' and 'Integer' class are also 4 bytes long.
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
12-03-2007 16:24Mateusz PuszNew Issue
12-03-2007 16:24Mateusz PuszClause Reference(s) => 9.2
12-03-2007 16:24Mateusz PuszSource (company - Author) => Mateusz Pusz, Intel
15-06-2007 19:11Stephan SchulzStatusnew => assigned
15-06-2007 19:11Stephan SchulzAssigned To => Ina Schieferdecker
15-10-2007 17:17Ina SchieferdeckerStatusassigned => closed
15-10-2007 17:17Ina SchieferdeckerNote Added: 0003628
15-10-2007 17:17Ina SchieferdeckerResolutionopen => fixed
18-10-2007 12:31Ina SchieferdeckerStatusclosed => feedback
18-10-2007 12:31Ina SchieferdeckerResolutionfixed => reopened
18-10-2007 12:31Ina SchieferdeckerStatusfeedback => closed
18-10-2007 12:31Ina SchieferdeckerResolutionreopened => won't fix
18-10-2007 12:31Ina SchieferdeckerTarget Version => Edition 3.3.1 (not yet published)
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0003628) +
+ Ina Schieferdecker    +
+ 15-10-2007 17:17    +
+ 		+ + + + +
+ The mapping should not be changed because of backward compatibility.
+
+ + diff --git a/docs/mantis/CR0840.md b/docs/mantis/CR0840.md new file mode 100644 index 0000000000000000000000000000000000000000..efa078a7faba038ed54bfe45d5d22355d4e3be18 --- /dev/null +++ b/docs/mantis/CR0840.md @@ -0,0 +1,133 @@ + + + + + + + + + + + + + 0000840: TciVerdictValue not defined in ANSI C mappings - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0000840Part 06: TTCN-3 Control InterfaceTechnicalpublic13-03-2007 07:5906-12-2007 11:21
ReporterMateusz Pusz 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv3.3.1 (published 2008-04)Fixed in Versionv3.3.1 (published 2008-04) 
Clause Reference(s)9.4
Source (company - Author)Mateusz Pusz, Intel
Summary0000840: TciVerdictValue not defined in ANSI C mappings
DescriptionTciVerdictValue type is not defined in TCI ANCI C language mappings.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Fileszip es_20187306v030301_CR840.zip (984,040) 04-12-2007 15:12
http://oldforge.etsi.org/mantis/file_download.php?file_id=1195&type=bug
Issue History
Date ModifiedUsernameFieldChange
13-03-2007 07:59Mateusz PuszNew Issue
13-03-2007 07:59Mateusz PuszClause Reference(s) => 9.4
13-03-2007 07:59Mateusz PuszSource (company - Author) => Mateusz Pusz, Intel
15-06-2007 19:10Stephan SchulzStatusnew => assigned
15-06-2007 19:10Stephan SchulzAssigned To => Ina Schieferdecker
18-10-2007 12:31Ina SchieferdeckerTarget Version => Edition 3.3.1 (not yet published)
04-12-2007 15:09Ina SchieferdeckerNote Added: 0004274
04-12-2007 15:12Ina SchieferdeckerFile Added: es_20187306v030301_CR840.zip
04-12-2007 15:13Ina SchieferdeckerNote Added: 0004275
04-12-2007 15:13Ina SchieferdeckerResolutionopen => fixed
04-12-2007 16:36Ina SchieferdeckerAssigned ToIna Schieferdecker => Thomas Deiß
04-12-2007 17:26Thomas DeißNote Added: 0004296
04-12-2007 17:26Thomas DeißAssigned ToThomas Deiß => Ina Schieferdecker
04-12-2007 17:26Thomas DeißStatusassigned => resolved
06-12-2007 11:21Ina SchieferdeckerStatusresolved => closed
06-12-2007 11:21Ina SchieferdeckerFixed in Version => Edition 3.3.1 (not yet published)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0004274) +
+ Ina Schieferdecker    +
+ 04-12-2007 15:09    +
+ 		+ + + + +
+ There is no TciVerdictValue in TCI - but just VerdictValue - its mapping is defined in 9.2.
+
+All occurrences of TciVerdictValue are being replaced by VerdictValue.
+
+
+
+ + + + + + + + + + +
+ (0004275) +
+ Ina Schieferdecker    +
+ 04-12-2007 15:13    +
+ 		+ + + + +
+ The resolution is using already the updated text from CR2000, CR2146, CR423, CR826, and CR828.
+
+
+
+ + + + + + + + + + +
+ (0004296) +
+ Thomas Deiß    +
+ 04-12-2007 17:26    +
+ 		+ + + + +
+ checked by Thomas, ok.
+
+ + diff --git a/docs/mantis/CR0841.md b/docs/mantis/CR0841.md new file mode 100644 index 0000000000000000000000000000000000000000..c45289a7a0bb69f47aef203b76284c97cfadb344 --- /dev/null +++ b/docs/mantis/CR0841.md @@ -0,0 +1,97 @@ + + + + + + + + + + + + + 0000841: ANSI C TCI logging interface problem - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0000841Part 06: TTCN-3 Control InterfaceTechnicalpublic13-03-2007 08:0806-12-2007 11:54
ReporterMateusz Pusz 
Assigned ToIna Schieferdecker 
PrioritynormalSeveritymajorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv3.3.1 (published 2008-04)Fixed in Versionv3.3.1 (published 2008-04) 
Clause Reference(s)9.3
Source (company - Author)Mateusz Pusz, Intel
Summary0000841: ANSI C TCI logging interface problem
DescriptionANSI C language mappings for TCI logging interface redefines tciIsAny() and tciGetTemplateDef() declarations.
Steps To Reproduce
Additional InformationAs it is ANSI C and not C++ language mapping function names should be unique.
TagsNo tags attached.
Relationships
Attached Filesdoc CR_841_part6.doc (321,024) 04-12-2007 08:33
http://oldforge.etsi.org/mantis/file_download.php?file_id=1181&type=bug
Issue History
Date ModifiedUsernameFieldChange
13-03-2007 08:08Mateusz PuszNew Issue
13-03-2007 08:08Mateusz PuszClause Reference(s) => 9.3
13-03-2007 08:08Mateusz PuszSource (company - Author) => Mateusz Pusz, Intel
15-06-2007 19:10Stephan SchulzStatusnew => assigned
15-06-2007 19:10Stephan SchulzAssigned To => Ina Schieferdecker
09-10-2007 11:54Anthony BaireNote Added: 0003527
18-10-2007 12:30Ina SchieferdeckerTarget Version => Edition 3.3.1 (not yet published)
04-12-2007 08:33Thomas DeißFile Added: CR_841_part6.doc
04-12-2007 08:37Thomas DeißNote Added: 0004247
04-12-2007 08:37Thomas DeißResolutionopen => fixed
04-12-2007 16:39Ina SchieferdeckerStatusassigned => resolved
06-12-2007 11:54Ina SchieferdeckerStatusresolved => closed
06-12-2007 11:54Ina SchieferdeckerFixed in Version => Edition 3.3.1 (not yet published)
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0003527) +
+ Anthony Baire    +
+ 09-10-2007 11:54    +
+ 		+ + + + +
+ the issue affects tciIsAll() as well
+
+
+
+ + + + + + + + + + +
+ (0004247) +
+ Thomas Deiß    +
+ 04-12-2007 08:37    +
+ 		+ + + + +
+ Suffix added to tciIsAny and tciGetTemplateDef for functions with NonValueTemplate (== component reference of to/from clause) as parameter. Suffix also added to tciIsAll for consistency reasons, although there is no name clash in this case.
+
+ + diff --git a/docs/mantis/CR0842.md b/docs/mantis/CR0842.md new file mode 100644 index 0000000000000000000000000000000000000000..ece2c6b7f54d738b0721461c99d5368281355888 --- /dev/null +++ b/docs/mantis/CR0842.md @@ -0,0 +1,102 @@ + + + + + + + + + + + + + 0000842: Some functions missing in ANSI C mappings of TCI-TL interface - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0000842Part 06: TTCN-3 Control InterfaceTechnicalpublic13-03-2007 08:1506-12-2007 11:25
ReporterMateusz Pusz 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv3.3.1 (published 2008-04)Fixed in Versionv3.3.1 (published 2008-04) 
Clause Reference(s)9.4
Source (company - Author)Mateusz Pusz, Intel
Summary0000842: Some functions missing in ANSI C mappings of TCI-TL interface
DescriptionANSI C mappings of TCI-TL interface does not define:
+- tliCAlive()
+- tliCKilledMismatch()
+- tliCKilled()
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Fileszip es_20187306v030301_CR842.zip (983,911) 04-12-2007 15:26
http://oldforge.etsi.org/mantis/file_download.php?file_id=1196&type=bug
zip es_20187306v030301_CR842_a.zip (983,935) 04-12-2007 18:32
http://oldforge.etsi.org/mantis/file_download.php?file_id=1208&type=bug
Issue History
Date ModifiedUsernameFieldChange
13-03-2007 08:15Mateusz PuszNew Issue
13-03-2007 08:15Mateusz PuszClause Reference(s) => 9.4
13-03-2007 08:15Mateusz PuszSource (company - Author) => Mateusz Pusz, Intel
15-06-2007 19:10Stephan SchulzStatusnew => assigned
15-06-2007 19:10Stephan SchulzAssigned To => Ina Schieferdecker
18-10-2007 12:30Ina SchieferdeckerTarget Version => Edition 3.3.1 (not yet published)
04-12-2007 15:26Ina SchieferdeckerFile Added: es_20187306v030301_CR842.zip
04-12-2007 15:28Ina SchieferdeckerNote Added: 0004276
04-12-2007 15:28Ina SchieferdeckerResolutionopen => fixed
04-12-2007 16:36Ina SchieferdeckerAssigned ToIna Schieferdecker => Thomas Deiß
04-12-2007 18:32Thomas DeißFile Added: es_20187306v030301_CR842_a.zip
04-12-2007 18:33Thomas DeißNote Added: 0004304
04-12-2007 18:33Thomas DeißAssigned ToThomas Deiß => Ina Schieferdecker
05-12-2007 08:56Ina SchieferdeckerStatusassigned => resolved
06-12-2007 11:25Ina SchieferdeckerStatusresolved => closed
06-12-2007 11:25Ina SchieferdeckerFixed in Version => Edition 3.3.1 (not yet published)
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0004276) +
+ Ina Schieferdecker    +
+ 04-12-2007 15:28    +
+ 		+ + + + +
+ Yes, see attached.
+
+The resolution is using already the updated text from CR2000, CR2146, CR423, CR826, CR828, and CR840.
+
+
+
+ + + + + + + + + + +
+ (0004304) +
+ Thomas Deiß    +
+ 04-12-2007 18:33    +
+ 		+ + + + +
+ A further function has been missing, tliCKill. Added already in file es_20187306v030301_CR842_a.zip.
+
+ + diff --git a/docs/mantis/CR0843.md b/docs/mantis/CR0843.md new file mode 100644 index 0000000000000000000000000000000000000000..aec7ca634e6fa73e7a22d0edc55e593bb882ac39 --- /dev/null +++ b/docs/mantis/CR0843.md @@ -0,0 +1,167 @@ + + + + + + + + + + + + + 0000843: getImportedModules() not defined in TCI-TM ANSI C language mappings - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0000843Part 06: TTCN-3 Control InterfaceTechnicalpublic13-03-2007 08:1806-12-2007 11:33
ReporterMateusz Pusz 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv3.3.1 (published 2008-04)Fixed in Versionv3.3.1 (published 2008-04) 
Clause Reference(s)9.4
Source (company - Author)Mateusz Pusz, Intel
Summary0000843: getImportedModules() not defined in TCI-TM ANSI C language mappings
DescriptionTCI-TM ANSI C language mappings does not declare getImportedModules().
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Fileszip es_20187306v030301_CR843.zip (984,531) 04-12-2007 15:52
http://oldforge.etsi.org/mantis/file_download.php?file_id=1198&type=bug
zip es_20187306v030301_CR843_a.zip (984,827) 04-12-2007 17:51
http://oldforge.etsi.org/mantis/file_download.php?file_id=1205&type=bug
Issue History
Date ModifiedUsernameFieldChange
13-03-2007 08:18Mateusz PuszNew Issue
13-03-2007 08:18Mateusz PuszClause Reference(s) => 9.4
13-03-2007 08:18Mateusz PuszSource (company - Author) => Mateusz Pusz, Intel
01-06-2007 17:33Ina SchieferdeckerNote Added: 0002123
15-06-2007 19:07Stephan SchulzStatusnew => assigned
15-06-2007 19:07Stephan SchulzAssigned To => Stephan Schulz
15-06-2007 19:08Stephan SchulzAssigned ToStephan Schulz => Ina Schieferdecker
18-10-2007 12:30Ina SchieferdeckerTarget Version => Edition 3.3.1 (not yet published)
04-12-2007 15:52Ina SchieferdeckerFile Added: es_20187306v030301_CR843.zip
04-12-2007 15:53Ina SchieferdeckerNote Added: 0004277
04-12-2007 15:53Ina SchieferdeckerResolutionopen => fixed
04-12-2007 16:36Ina SchieferdeckerAssigned ToIna Schieferdecker => Thomas Deiß
04-12-2007 17:51Thomas DeißFile Added: es_20187306v030301_CR843_a.zip
04-12-2007 17:52Thomas DeißNote Added: 0004299
04-12-2007 17:52Thomas DeißAssigned ToThomas Deiß => Ina Schieferdecker
04-12-2007 17:52Thomas DeißStatusassigned => resolved
06-12-2007 11:33Ina SchieferdeckerStatusresolved => closed
06-12-2007 11:33Ina SchieferdeckerNote Added: 0004370
06-12-2007 11:33Ina SchieferdeckerFixed in Version => Edition 3.3.1 (not yet published)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0002123) +
+ Ina Schieferdecker    +
+ 01-06-2007 17:33    +
+ 		+ + + + +
+ this function is also called inconcistently to the other TM functions - the tci prefix is missing ... could be fixed as well
+
+
+
+ + + + + + + + + + +
+ (0004277) +
+ Ina Schieferdecker    +
+ 04-12-2007 15:53    +
+ 		+ + + + +
+ Right, it was also missing in the Java mapping.
+
+The resolution is using already the updated text from CR2000, CR2146, CR423, CR826, CR828, CR840, and CR842.
+
+
+
+ + + + + + + + + + +
+ (0004299) +
+ Thomas Deiß    +
+ 04-12-2007 17:52    +
+ 		+ + + + +
+ checked by Thomas, ok. Except that a few occurrences of getImportedModules have not been changed to tciGetImportedModules. Corrected in file es_20187306v030301_CR843_a.zip
+
+
+
+ + + + + + + + + + +
+ (0004370) +
+ Ina Schieferdecker    +
+ 06-12-2007 11:33    +
+ 		+ + + + +
+ As all TCI operations have the tci prefix we decided along the review of this CR resolution to rename getImportedModules to tciGetImportedModules although this is a change to TM - but a minor one.
+
+ + diff --git a/docs/mantis/CR0887.md b/docs/mantis/CR0887.md new file mode 100644 index 0000000000000000000000000000000000000000..21aed6b57e640a164e345f9e4fe695176a812f5b --- /dev/null +++ b/docs/mantis/CR0887.md @@ -0,0 +1,64 @@ + + + + + + + + + + + + + 0000887: Incompatible str2oct and oct2str functions - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0000887Part 01: TTCN-3 Core LanguageTechnicalpublic19-03-2007 15:5312-03-2008 10:27
ReporterStephan Schulz 
Assigned ToGyorgy Rethy 
PriorityimmediateSeverityblockReproducibilityN/A
StatusclosedResolutionwon't fix 
PlatformOSOS Version
Product Version 
Target Versionv3.3.2 (published 2008-04)Fixed in Versionv3.3.2 (published 2008-04) 
Clause Reference(s)Annex C.20, 21, 35,36
Source (company - Author) ETSI Stephan Schulz
Summary0000887: Incompatible str2oct and oct2str functions
DescriptionIn edition 3.1.1 the semantics of str2oct and oct2str have been changed without any notice. This leads to tool incompatibility between tool supporting 3.1.1 and higher with ones supporting 2.2.1 and earlier.
+A new predefined function oct2char has been introduced in 3.1.1 which uses the behavior of str2oct etc had in 2.2.1.
Steps To Reproduce
Additional InformationWe strongly urge to change the semantics back to its orginal. Possibly swap names of str2oct and char2oct etc.
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
19-03-2007 15:53Stephan SchulzNew Issue
19-03-2007 15:53Stephan SchulzClause Reference(s) => Annex C.20, 21, 35,36
19-03-2007 15:53Stephan SchulzSource (company - Author) => ETSI Stephan Schulz
15-06-2007 19:10Stephan SchulzStatusnew => assigned
15-06-2007 19:10Stephan SchulzAssigned To => Ina Schieferdecker
13-10-2007 18:52Ina SchieferdeckerAssigned ToIna Schieferdecker => Gyorgy Rethy
17-10-2007 11:37Ina SchieferdeckerNote Added: 0003659
18-10-2007 12:17Ina SchieferdeckerResolutionopen => won't fix
18-10-2007 12:18Ina SchieferdeckerStatusassigned => closed
18-10-2007 13:46Ina SchieferdeckerProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
18-10-2007 14:03Ina SchieferdeckerStatusclosed => feedback
18-10-2007 14:03Ina SchieferdeckerResolutionwon't fix => reopened
18-10-2007 14:04Ina SchieferdeckerStatusfeedback => closed
18-10-2007 14:04Ina SchieferdeckerResolutionreopened => won't fix
18-10-2007 14:04Ina SchieferdeckerTarget Version => Edition 3.3.1 (not yet published)
12-03-2008 10:27user10Fixed in Version => Edition 3.3.2 (not yet published)
12-03-2008 10:27user10Target VersionEdition 3.3.1 --will not be published, see 3.3.2 => Edition 3.3.2 (not yet published)
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0003659) +
+ Ina Schieferdecker    +
+ 17-10-2007 11:37    +
+ 		+ + + + +
+ Change back to the original meaning would increase the confusion. So, we close that CR and do not change back, propose however a method to define the language version being used by a module. This will be handled in a new CR.
+
+ + diff --git a/docs/mantis/CR1164.md b/docs/mantis/CR1164.md new file mode 100644 index 0000000000000000000000000000000000000000..2f983650d918186137ee0622a6e3602f4f8fa25f --- /dev/null +++ b/docs/mantis/CR1164.md @@ -0,0 +1,79 @@ + + + + + + + + + + + + + 0001164: tciReset procedure - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0001164Part 06: TTCN-3 Control InterfaceTechnicalpublic25-04-2007 15:3904-12-2007 17:16
ReporterMateusz Pusz 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionno change required 
PlatformOSOS Version
Product Versionv3.1.1 (published 2005-06) 
Target Versionv3.3.1 (published 2008-04)Fixed in Version 
Clause Reference(s)11.4.1.1, 11.4.4.1
Source (company - Author)Mateusz Pusz, Intel
Summary0001164: tciReset procedure
DescriptionFigures 24 and 27 defines that tciStopTestComponent() is called by TCI_CH_Provided when tciResetReq() is received. It should be called only when
+tciStopTestComponentReq(). If there are running components when reset is received TE should stop them locally before reset.
+
+Figures should be modified in one of following ways:
+1. Call tciStopTestComponentReq() explicitly before calling tciResetReq()
+2. Do not call tciStopTestComponent() at all (it will be done locally on TEs)
Steps To Reproduce
Additional Information1. To perform such an operation CH does not need to monitor only active connections but also should be aware what test components are still alive. So it needs to duplicate what TE already does.
+2. Description of tciStopTestComponent() says that it is run only when tciStopTestComponentReq() is received by CH.
+3. tciStopTestComponentReq() is not used on any figure in specification
+4. tciResetReq() is ment to "transmit the reset request to all involeved TEs" according to its descritpion and not to perform stop call to running test components.
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
25-04-2007 15:39Mateusz PuszNew Issue
25-04-2007 15:39Mateusz PuszClause Reference(s) => 11.4.1.1, 11.4.4.1
25-04-2007 15:39Mateusz PuszSource (company - Author) => Mateusz Pusz, Intel
15-06-2007 19:09Stephan SchulzStatusnew => assigned
15-06-2007 19:09Stephan SchulzAssigned To => Ina Schieferdecker
18-10-2007 12:29Ina SchieferdeckerTarget Version => Edition 3.3.1 (not yet published)
04-12-2007 17:15Ina SchieferdeckerNote Added: 0004294
04-12-2007 17:16Ina SchieferdeckerStatusassigned => closed
04-12-2007 17:16Ina SchieferdeckerResolutionopen => no change required
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0004294) +
+ Ina Schieferdecker    +
+ 04-12-2007 17:15    +
+ 		+ + + + +
+ tciStopTestComponentReq() is not used in a figure of the specification as no case with an explicit myComponent.stop statement is shown.
+
+In such cases, the request is given to the CH which knows where the test component is being located, i.e. in which TE. The CH invokes then on the TE the respective tciStopTestComponent().
+
+Figure 24 is about terminating a test case or control, which is initiated by the tciResetReq(). This implies two things: the stopping of all test components and the resetting of all TEs. As the CH however keeps track of the status of all test components during a test run, it knows where to stop test components and has to issue the corresponding tciStopTestComponent() to those TEs where test components have to be stopped. First, the test components are stopped, then the TEs are resetted.
+
+Figure 27 is about terminating a test case after error - it is basically the same sequencing: tciResetReq() initiates the termination, then all test components are being stopped in the respective TEs (the CH knows which TEs to invoke with a tciStopTestComponent()) and finally all TEs are being resetted.
+
+To sum up: tciStopTestComponentReq() is an invocation on the CH in order to forward the tciStopTestComponent() to the correct TE. If however CH has the control, it can issue tciStopTestComponent() directly.
+
+ + diff --git a/docs/mantis/CR1448.md b/docs/mantis/CR1448.md new file mode 100644 index 0000000000000000000000000000000000000000..a30748ea66a8eaec522741a434633cf9863780b6 --- /dev/null +++ b/docs/mantis/CR1448.md @@ -0,0 +1,97 @@ + + + + + + + + + + + + + 0001448: Inappriate restrictions of the match operation - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0001448Part 01: TTCN-3 Core LanguageClarificationpublic29-05-2007 16:0412-03-2008 10:24
ReporterThomas Deiß 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv3.3.2 (published 2008-04)Fixed in Versionv3.3.2 (published 2008-04) 
Clause Reference(s)15.8
Source (company - Author)Nokia Siemens Networks - Thomas Deiß
Summary0001448: Inappriate restrictions of the match operation
DescriptionThe match operation is described with two restrictions: The types of the expression and the template have to be identical, and all fields of the template have to resolve to a single value. The first restriction contradicts the explanation of match. The second restriction implies that the match operation is just a comparison for equality between the expression and the template.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc match_restriction.doc (52,224) 29-05-2007 16:05
http://oldforge.etsi.org/mantis/file_download.php?file_id=681&type=bug
doc CR-1448-Inappriate-Restrictions-of-the-Match-Operation-Resolution.doc (198,144) 04-12-2007 13:05
http://oldforge.etsi.org/mantis/file_download.php?file_id=1189&type=bug
doc CR-1448-Inappriate-Restrictions-of-the-Match-Operation-Resolution_a.doc (198,144) 04-12-2007 14:31
http://oldforge.etsi.org/mantis/file_download.php?file_id=1190&type=bug
Issue History
Date ModifiedUsernameFieldChange
29-05-2007 16:04Thomas DeißNew Issue
29-05-2007 16:04Thomas DeißStatusnew => assigned
29-05-2007 16:04Thomas DeißAssigned To => Gyorgy Rethy
29-05-2007 16:05Thomas DeißFile Added: match_restriction.doc
29-05-2007 16:05Thomas DeißClause Reference(s) => 15.8
29-05-2007 16:05Thomas DeißSource (company - Author) => Nokia Siemens Networks - Thomas Deiß
29-05-2007 16:11Thomas DeißNote Added: 0002041
13-10-2007 18:58Ina SchieferdeckerAssigned ToGyorgy Rethy => Jens Grabowski
18-10-2007 13:46Ina SchieferdeckerProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
18-10-2007 14:03Ina SchieferdeckerTarget Version => Edition 3.3.1 (not yet published)
18-10-2007 14:35Thomas DeißNote Deleted: 0002041
04-12-2007 13:05Jens GrabowskiFile Added: CR-1448-Inappriate-Restrictions-of-the-Match-Operation-Resolution.doc
04-12-2007 13:06Jens GrabowskiNote Added: 0004258
04-12-2007 13:06Jens GrabowskiAssigned ToJens Grabowski => Thomas Deiß
04-12-2007 13:06Jens GrabowskiResolutionopen => fixed
04-12-2007 14:31Thomas DeißFile Added: CR-1448-Inappriate-Restrictions-of-the-Match-Operation-Resolution_a.doc
04-12-2007 14:32Thomas DeißNote Added: 0004263
04-12-2007 14:32Thomas DeißAssigned ToThomas Deiß => Gyorgy Rethy
05-12-2007 11:31Jens GrabowskiAssigned ToGyorgy Rethy => Ina Schieferdecker
05-12-2007 11:31Jens GrabowskiStatusassigned => resolved
05-12-2007 17:35Ina SchieferdeckerStatusresolved => closed
05-12-2007 17:35Ina SchieferdeckerFixed in Version => Edition 3.3.1 (not yet published)
12-03-2008 10:22user10Fixed in VersionEdition 3.3.1 --will not be published, see 3.3.2 => Edition 3.3.2 (not yet published)
12-03-2008 10:24user10Target VersionEdition 3.3.1 --will not be published, see 3.3.2 => Edition 3.3.2 (not yet published)
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0004258) +
+ Jens Grabowski    +
+ 04-12-2007 13:06    +
+ 		+ + + + +
+ To be crosschecked by Thomas.
+
+
+
+ + + + + + + + + + +
+ (0004263) +
+ Thomas Deiß    +
+ 04-12-2007 14:32    +
+ 		+ + + + +
+ Checked by Thomas. Ok, except that one sentence has been incomplete. Corrected in CR-1448-Inappriate-Restrictions-of-the-Match-Operation-Resolution_a.doc
+
+ + diff --git a/docs/mantis/CR1451.md b/docs/mantis/CR1451.md new file mode 100644 index 0000000000000000000000000000000000000000..d661d43afaa5cf6d1252c3193ae2fdcb1118a089 --- /dev/null +++ b/docs/mantis/CR1451.md @@ -0,0 +1,131 @@ + + + + + + + + + + + + + 0001451: predefined operations on templates - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0001451Part 01: TTCN-3 Core LanguageClarificationpublic29-05-2007 17:2112-03-2008 10:24
ReporterThomas Deiß 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.2.1 (published 2007-02) 
Target Versionv3.3.2 (published 2008-04)Fixed in Versionv3.3.2 (published 2008-04) 
Clause Reference(s)16.1,2, C28-C31.
Source (company - Author)Nokia Siemens Networks - Thomas Deiß
Summary0001451: predefined operations on templates
DescriptionThe domain of the predefined operations sizeof and sizeoftype is not defined precisely. There are discrepancies between clause 16.1 and Annex C.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc predefined_functions_on_templates_1.doc (142,848) 29-05-2007 17:21
http://oldforge.etsi.org/mantis/file_download.php?file_id=683&type=bug
Issue History
Date ModifiedUsernameFieldChange
29-05-2007 17:21Thomas DeißNew Issue
29-05-2007 17:21Thomas DeißFile Added: predefined_functions_on_templates_1.doc
29-05-2007 17:21Thomas DeißClause Reference(s) => 16.1,2, C28-C31.
29-05-2007 17:21Thomas DeißSource (company - Author) => Nokia Siemens Networks - Thomas Deiß
15-06-2007 19:08Stephan SchulzStatusnew => assigned
15-06-2007 19:08Stephan SchulzAssigned To => Ina Schieferdecker
06-09-2007 12:12Thomas DeißNote Added: 0003092
13-10-2007 19:06Ina SchieferdeckerAssigned ToIna Schieferdecker => Gyorgy Rethy
18-10-2007 12:28Ina SchieferdeckerTarget Version => Edition 3.3.1 (not yet published)
19-10-2007 13:16Gyorgy RethyNote Added: 0003703
19-10-2007 13:16Gyorgy RethyResolutionopen => fixed
06-12-2007 16:28Gyorgy RethyNote Added: 0004391
06-12-2007 16:28Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
06-12-2007 16:28Gyorgy RethyStatusassigned => resolved
06-12-2007 18:01Ina SchieferdeckerStatusresolved => closed
06-12-2007 18:01Ina SchieferdeckerFixed in Version => Edition 3.3.1 (not yet published)
12-03-2008 10:22user10Fixed in VersionEdition 3.3.1 --will not be published, see 3.3.2 => Edition 3.3.2 (not yet published)
12-03-2008 10:24user10Target VersionEdition 3.3.1 --will not be published, see 3.3.2 => Edition 3.3.2 (not yet published)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0003092) +
+ Thomas Deiß    +
+ 06-09-2007 12:12    +
+ 		+ + + + +
+ The CR contains one suggestion to clarify the discrepancy between 16.1.2 and Annex C regarding the ispresent function, namely to restrict the usage to values only. The alternative to correct Annex C such that ispresent could be applied to templates, would also be ok. The main issue is to have clause 16.1.2 and Annex C consistent with each other.
+
+
+
+ + + + + + + + + + +
+ (0003703) +
+ Gyorgy Rethy    +
+ 19-10-2007 13:16    +
+ 		+ + + + +
+ STF solution text is in the common file attached to CR383
+
+
+
+ + + + + + + + + + +
+ (0004391) +
+ Gyorgy Rethy    +
+ 06-12-2007 16:28    +
+ 		+ + + + +
+ Resolved together with CR424, solution is in the file attached to CR424.
+
+ + diff --git a/docs/mantis/CR1454.md b/docs/mantis/CR1454.md new file mode 100644 index 0000000000000000000000000000000000000000..2728035acc4937aeb5c3cce4be72980ccb1c00b4 --- /dev/null +++ b/docs/mantis/CR1454.md @@ -0,0 +1,98 @@ + + + + + + + + + + + + + 0001454: Description of TCI in Definitions is wrong - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 05: TTCN-3 Runtime Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0001454Part 05: TTCN-3 Runtime Interface Editorialpublic29-05-2007 17:3205-12-2007 16:03
ReporterThomas Deiß 
Assigned ToIna Schieferdecker 
PrioritynormalSeveritytextReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.2.1 (published 2007-02) 
Target Versionv3.3.1 (published 2008-04)Fixed in Versionv3.3.1 (published 2008-04) 
Clause Reference(s)3.1
Source (company - Author)Nokia Siemens Networks - Thomas Deiß
Summary0001454: Description of TCI in Definitions is wrong
DescriptionThe TCI is still described as a proprietary interface.
Steps To Reproduce
Additional InformationOriginally found by Edward Fondis, University of Dortmund.
TagsNo tags attached.
Relationships
Attached Filesdoc TCI_proprietary.doc (51,712) 29-05-2007 17:33
http://oldforge.etsi.org/mantis/file_download.php?file_id=686&type=bug
doc es_20187305v030301_CR1454.doc (65,024) 17-10-2007 20:03
http://oldforge.etsi.org/mantis/file_download.php?file_id=1043&type=bug
doc es_20187305v030301_CR1454_a.doc (60,416) 04-12-2007 17:09
http://oldforge.etsi.org/mantis/file_download.php?file_id=1203&type=bug
Issue History
Date ModifiedUsernameFieldChange
29-05-2007 17:32Thomas DeißNew Issue
29-05-2007 17:33Thomas DeißFile Added: TCI_proprietary.doc
29-05-2007 17:33Thomas DeißClause Reference(s) => 3.1
29-05-2007 17:33Thomas DeißSource (company - Author) => Nokia Siemens Networks - Thomas Deiß
29-05-2007 17:34Thomas DeißNote Added: 0002046
15-06-2007 19:08Stephan SchulzStatusnew => assigned
15-06-2007 19:08Stephan SchulzAssigned To => Ina Schieferdecker
17-10-2007 19:26Ina SchieferdeckerProjectPart 01: TTCN-3 Core Language => Part 05: TTCN-3 Runtime Interface
17-10-2007 20:03Ina SchieferdeckerFile Added: es_20187305v030301_CR1454.doc
18-10-2007 12:03Ina SchieferdeckerTarget Version => Edition 3.3.1 (not yet published)
19-10-2007 11:04Ina SchieferdeckerResolutionopen => fixed
04-12-2007 16:44Ina SchieferdeckerAssigned ToIna Schieferdecker => Thomas Deiß
04-12-2007 17:09Thomas DeißFile Added: es_20187305v030301_CR1454_a.doc
04-12-2007 17:10Thomas DeißNote Added: 0004291
04-12-2007 17:10Thomas DeißAssigned ToThomas Deiß => Ina Schieferdecker
04-12-2007 17:10Thomas DeißStatusassigned => resolved
05-12-2007 16:03Ina SchieferdeckerStatusresolved => closed
05-12-2007 16:03Ina SchieferdeckerFixed in Version => Edition 3.3.1 (not yet published)
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0002046) +
+ Thomas Deiß    +
+ 29-05-2007 17:34    +
+ 		+ + + + +
+ Obviously this belongs to part 5.
+There seem to be some difficulty in selecting the correct part of the standard in the bug tracking system. Sorry.
+
+
+
+ + + + + + + + + + +
+ (0004291) +
+ Thomas Deiß    +
+ 04-12-2007 17:10    +
+ 		+ + + + +
+ checked by Thomas, ok. (Except that TCI is actually 4 instead of 3 interfaces, corrected in newly uploaded file)
+
+ + diff --git a/docs/mantis/CR1467.md b/docs/mantis/CR1467.md new file mode 100644 index 0000000000000000000000000000000000000000..9d96d6d50a77b0359cc95604d5840ff27d654360 --- /dev/null +++ b/docs/mantis/CR1467.md @@ -0,0 +1,82 @@ + + + + + + + + + + + + + 0001467: Clarifying template parameters for sizeof and sizeoftype - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0001467Part 01: TTCN-3 Core LanguageTechnicalpublic31-05-2007 23:2212-03-2008 10:28
ReporterGyorgy Rethy 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionduplicate 
PlatformOSOS Version
Product Version 
Target Versionv3.3.2 (published 2008-04)Fixed in Versionv3.3.2 (published 2008-04) 
Clause Reference(s)C.29 & C.30
Source (company - Author)L.M.Ericsson
Summary0001467: Clarifying template parameters for sizeof and sizeoftype
DescriptionTextual descriptions in clause C.29 & C.30 allow using the functions to templates but neither the function proforma allows template input parameters nor handling of matching mechanisms described.
Steps To Reproduce
Additional InformationC.29 Number of elements in a structured value
+    sizeof(template any_type Value) return integer
+
+This function returns the actual number of elements of a module parameter, constant, variable or template of a record, record of, set, set of type or array (see note). The function is applicable to templates only if applying the sizeof predefined function to all values matching the template give the same result. In the case of record of and set of values, templates or arrays, the actual value to be returned is the sequential number of the last defined element (index of that element plus 1). In case of record and set values the number of mandatory fields plus the optional fields that are present in the actual value is returned. Dynamic test case error occurs if the template
+can match values with different sizes or the length restriction contradicts the number of elements in the template body.
+...
+    template MyPDU MyTemplate1
+        { field1 ?,
+          field2 5
+        };
+        
+    var integer numElements;
+
+    // then
+
+    numElements := sizeof(MyTemplate); // returns 1
+    numElements := sizeof(MyTemplate1); // returns 2
+
+
+<solution to C.30 is along the same line>
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
31-05-2007 23:22Gyorgy RethyNew Issue
31-05-2007 23:22Gyorgy RethyClause Reference(s) => C.29 & C.30
31-05-2007 23:22Gyorgy RethySource (company - Author) => L.M.Ericsson
15-06-2007 19:08Stephan SchulzStatusnew => assigned
15-06-2007 19:08Stephan SchulzAssigned To => Ina Schieferdecker
15-10-2007 16:37Ina SchieferdeckerStatusassigned => closed
15-10-2007 16:37Ina SchieferdeckerNote Added: 0003622
15-10-2007 16:37Ina SchieferdeckerResolutionopen => fixed
18-10-2007 12:27Ina SchieferdeckerStatusclosed => feedback
18-10-2007 12:27Ina SchieferdeckerResolutionfixed => reopened
18-10-2007 12:27Ina SchieferdeckerStatusfeedback => closed
18-10-2007 12:27Ina SchieferdeckerResolutionreopened => duplicate
18-10-2007 12:27Ina SchieferdeckerTarget Version => Edition 3.3.1 (not yet published)
12-03-2008 10:28user10Fixed in Version => Edition 3.3.2 (not yet published)
12-03-2008 10:28user10Target VersionEdition 3.3.1 --will not be published, see 3.3.2 => Edition 3.3.2 (not yet published)
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0003622) +
+ Ina Schieferdecker    +
+ 15-10-2007 16:37    +
+ 		+ + + + +
+ It is a duplicate of CR 1451
+
+ + diff --git a/docs/mantis/CR1683.md b/docs/mantis/CR1683.md new file mode 100644 index 0000000000000000000000000000000000000000..cd95b7736f5cabc9b457e470662fe49e158c7912 --- /dev/null +++ b/docs/mantis/CR1683.md @@ -0,0 +1,149 @@ + + + + + + + + + + + + + 0001683: Clarification about which entity should invoke operations described in the TCI-TL provided interface - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0001683Part 06: TTCN-3 Control InterfaceClarificationpublic12-07-2007 10:1306-12-2007 11:41
ReporterDavid Diaz (MTP) 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.2.1 (published 2007-02) 
Target Versionv3.3.1 (published 2008-04)Fixed in Versionv3.3.1 (published 2008-04) 
Clause Reference(s)7.3.4.1
Source (company - Author)David Díaz, Métodos y Tecnología
Summary0001683: Clarification about which entity should invoke operations described in the TCI-TL provided interface
DescriptionThe clauses 7.3.4.1.9, 7.3.4.1.10 and 7.3.4.1.11 from ?Part6: TTCN-3 Control Interface? describe the operations provided by the TL to log send operations.
+According to the ?Constraint? description field, these logging operations shall be called by the SA after the send operation is performed.
+
+But looking at the input parameters defined in the prototype description of these functions, we?ve found that some of them may be hard to be passed in by the System Adaptor. That?s the case of the source file of the test specification (and the number of line) under execution and, mainly, the msgValue parameter (defined as the value to be encoded and sent).
+
+Obviously, this information is well known in the TE environment, but it is not available within the SA scope.
+
+The standard should clarify the fact that the tliMSend_m, tliMSend_m_BC and tliMSend_MC log events are really called by the TE as within the SA.
+
+A complete review of clause ?7.3.4.1 TCI-TL provided? is recommended in order to clarify this, because this ?misunderstanding? is also present in all the event log operations that "Shall be called by [...]" other entities, like the CH, CD, PA and SA (as mentioned above).
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Fileszip es_20187306v030301_CR1683.zip (985,687) 04-12-2007 16:31
http://oldforge.etsi.org/mantis/file_download.php?file_id=1201&type=bug
Issue History
Date ModifiedUsernameFieldChange
12-07-2007 10:13David Diaz (MTP)New Issue
12-07-2007 10:13David Diaz (MTP)Clause Reference(s) => 7.3.4.1
12-07-2007 10:13David Diaz (MTP)Source (company - Author) => David Díaz, Métodos y Tecnología
13-10-2007 19:32Ina SchieferdeckerStatusnew => assigned
13-10-2007 19:32Ina SchieferdeckerAssigned To => Ina Schieferdecker
18-10-2007 12:26Ina SchieferdeckerTarget Version => Edition 3.3.1 (not yet published)
18-10-2007 12:26Ina SchieferdeckerDescription Updated
04-12-2007 16:20Ina SchieferdeckerNote Added: 0004280
04-12-2007 16:31Ina SchieferdeckerFile Added: es_20187306v030301_CR1683.zip
04-12-2007 16:32Ina SchieferdeckerNote Added: 0004282
04-12-2007 16:32Ina SchieferdeckerResolutionopen => fixed
04-12-2007 16:38Ina SchieferdeckerAssigned ToIna Schieferdecker => Thomas Deiß
06-12-2007 09:25Thomas DeißNote Added: 0004359
06-12-2007 09:25Thomas DeißAssigned ToThomas Deiß => Ina Schieferdecker
06-12-2007 09:25Thomas DeißStatusassigned => resolved
06-12-2007 11:41Ina SchieferdeckerStatusresolved => closed
06-12-2007 11:41Ina SchieferdeckerFixed in Version => Edition 3.3.1 (not yet published)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0004280) +
+ Ina Schieferdecker    +
+ 04-12-2007 16:20    +
+ 		+ + + + +
+ The intention of the logging is to log the events at the point in time when they so to say "leave the TTCN-3 based test system".
+
+Concerning your question, the additional information can be passed into TRI SA by the auxilary, user-definable parameter in TRI send.
+
+Furthermore, the additional information is optional - you may log it but you do not have to.
+
+Still we agreed to leverage the definition of TLI, so that the tool vendor may decide if the TE or the TRI/TCI adapter components invoke the logging interface.
+
+Please note, that having the logs in the adapter components give you more precise time stamps for the interaction with the SUT. This requires however to pass the additional information into the SA whenever you are interested in having it in the log.
+
+
+
+ + + + + + + + + + +
+ (0004282) +
+ Ina Schieferdecker    +
+ 04-12-2007 16:32    +
+ 		+ + + + +
+ The resolution is using already the updated text from CR2000, CR2146, CR423, CR826, CR828, CR840, CR842, and CR843.
+
+
+
+ + + + + + + + + + +
+ (0004359) +
+ Thomas Deiß    +
+ 06-12-2007 09:25    +
+ 		+ + + + +
+ checked by Thomas, ok.
+
+ + diff --git a/docs/mantis/CR1863.md b/docs/mantis/CR1863.md new file mode 100644 index 0000000000000000000000000000000000000000..4921edde8141096ab25ebba4b142f612fa4536e9 --- /dev/null +++ b/docs/mantis/CR1863.md @@ -0,0 +1,65 @@ + + + + + + + + + + + + + 0001863: remove some restrictions on accessing parts of templates in left hand sides of assignments. - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0001863Part 01: TTCN-3 Core LanguageClarificationpublic28-08-2007 11:0812-03-2008 10:24
ReporterThomas Deiß 
Assigned ToIna Schieferdecker 
PrioritynormalSeveritymajorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.2.1 (published 2007-02) 
Target Versionv3.3.2 (published 2008-04)Fixed in Versionv3.3.2 (published 2008-04) 
Clause Reference(s)15.6.2
Source (company - Author)Thomas Deiß, Nokia Siemens Networks
Summary0001863: remove some restrictions on accessing parts of templates in left hand sides of assignments.
DescriptionWhen accessing subfields of structured fields in a template of record type in the left hand side of an assignment, the restrictions when this can be done are too strict. If the field is set to omit or AnyValueOrNone this should cause an error, but this can be allowed without problems because in 2 consecutive assignments the field can be change first to AnyValue and then the actual assignment can be done. For usage at the right hand side, there is no change.
+
+Then, such an assignment is done, the text in the standard is misleading regarding the expansion of subfields not mentioned in the assignment. I suggest that actually the expansion has to be done by the tools and this includes even the leaves of the type hierarchy.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Fileszip templates_lhs_expansion_CR.zip (881,123) 28-08-2007 11:08
http://oldforge.etsi.org/mantis/file_download.php?file_id=887&type=bug
doc STF_solution_CR1863.doc (238,592) 17-10-2007 17:03
http://oldforge.etsi.org/mantis/file_download.php?file_id=1036&type=bug
doc STF_solution_CR1863_2.doc (238,592) 04-12-2007 09:00
http://oldforge.etsi.org/mantis/file_download.php?file_id=1183&type=bug
Issue History
Date ModifiedUsernameFieldChange
28-08-2007 11:08Thomas DeißNew Issue
28-08-2007 11:08Thomas DeißFile Added: templates_lhs_expansion_CR.zip
28-08-2007 11:08Thomas DeißClause Reference(s) => 15.6.2
28-08-2007 11:08Thomas DeißSource (company - Author) => Thomas Deiß, Nokia Siemens Networks
13-10-2007 19:08Ina SchieferdeckerStatusnew => assigned
13-10-2007 19:08Ina SchieferdeckerAssigned To => Jens Grabowski
15-10-2007 15:19Ina SchieferdeckerAssigned ToJens Grabowski => Gyorgy Rethy
17-10-2007 17:02Gyorgy RethyFile Added: STF_solution_CR1863.doc
17-10-2007 17:03Gyorgy RethyFile Deleted: STF_solution_CR1863.doc
17-10-2007 17:03Gyorgy RethyFile Added: STF_solution_CR1863.doc
18-10-2007 12:05Ina SchieferdeckerTarget Version => Edition 3.3.1 (not yet published)
19-10-2007 13:18Gyorgy RethyResolutionopen => fixed
03-12-2007 14:26Jens GrabowskiAssigned ToGyorgy Rethy => Thomas Deiß
04-12-2007 09:00Thomas DeißFile Added: STF_solution_CR1863_2.doc
04-12-2007 09:01Thomas DeißNote Added: 0004250
04-12-2007 09:01Thomas DeißAssigned ToThomas Deiß => Ina Schieferdecker
04-12-2007 16:45Ina SchieferdeckerStatusassigned => resolved
05-12-2007 17:05Ina SchieferdeckerStatusresolved => closed
05-12-2007 17:05Ina SchieferdeckerFixed in Version => Edition 3.3.1 (not yet published)
12-03-2008 10:22user10Fixed in VersionEdition 3.3.1 --will not be published, see 3.3.2 => Edition 3.3.2 (not yet published)
12-03-2008 10:24user10Target VersionEdition 3.3.1 --will not be published, see 3.3.2 => Edition 3.3.2 (not yet published)
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0004250) +
+ Thomas Deiß    +
+ 04-12-2007 09:01    +
+ 		+ + + + +
+ solution ok. Two articles added in the text.
+
+ + diff --git a/docs/mantis/CR1917.md b/docs/mantis/CR1917.md new file mode 100644 index 0000000000000000000000000000000000000000..7070983af51ef9381e52227d1c36d07410e40981 --- /dev/null +++ b/docs/mantis/CR1917.md @@ -0,0 +1,236 @@ + + + + + + + + + + + + + 0001917: Exit keyword for interleave statement - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0001917Part 01: TTCN-3 Core LanguageNew Featurepublic05-09-2007 11:1612-03-2008 10:31
ReporterLeopold Schwarz 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityfeatureReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.1.1 (published 2005-06) 
Target Versionv3.3.2 (published 2008-04)Fixed in Versionv3.3.2 (published 2008-04) 
Clause Reference(s)20.3
Source (company - Author)     
Summary0001917: Exit keyword for interleave statement
DescriptionThe interleave statement allows to specify in a simple way nested alt combinations. However, it is not possible to exit them in an error case when a specified event is missing.
+It is proposed to specify a keyword, which allows to exit it on request.
+
+Otherwise, the interleave is never ended and could therefore never been used.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filestxt CR_interleave_exit.txt (342) 05-09-2007 11:16
http://oldforge.etsi.org/mantis/file_download.php?file_id=916&type=bug
Issue History
Date ModifiedUsernameFieldChange
05-09-2007 11:16Leopold SchwarzNew Issue
05-09-2007 11:16Leopold SchwarzFile Added: CR_interleave_exit.txt
05-09-2007 11:16Leopold SchwarzClause Reference(s) => 20.3
05-09-2007 11:16Leopold SchwarzSource (company - Author) =>
05-09-2007 11:19Leopold SchwarzNote Added: 0003061
13-10-2007 19:07Ina SchieferdeckerStatusnew => assigned
13-10-2007 19:07Ina SchieferdeckerAssigned To => developer_u
15-10-2007 15:21Ina SchieferdeckerNote Added: 0003616
17-10-2007 12:41user10Assigned Todeveloper_u => Thomas Deiß
18-10-2007 12:14Ina SchieferdeckerTarget Version => Edition 3.3.1 (not yet published)
19-11-2007 13:51Thomas DeißNote Added: 0004002
19-11-2007 13:51Thomas DeißAssigned ToThomas Deiß => Gyorgy Rethy
19-11-2007 13:51Thomas DeißResolutionopen => fixed
03-12-2007 14:20Jens GrabowskiNote Added: 0004232
03-12-2007 14:20Jens GrabowskiAssigned ToGyorgy Rethy => Jens Grabowski
04-12-2007 10:26Jens GrabowskiNote Added: 0004253
04-12-2007 10:26Jens GrabowskiAssigned ToJens Grabowski => Gyorgy Rethy
06-12-2007 17:04Gyorgy RethyNote Added: 0004397
06-12-2007 17:04Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
06-12-2007 17:04Gyorgy RethyStatusassigned => closed
12-03-2008 10:26user10Target VersionEdition 3.3.1 --will not be published, see 3.3.2 => Edition 3.3.2 (not yet published)
12-03-2008 10:31user10Fixed in Version => Edition 3.3.2 (not yet published)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0003061) +
+ Leopold Schwarz    +
+ 05-09-2007 11:19    +
+ 		+ + + + +
+ Source: Siemens - Leopold Schwarz
+
+
+
+ + + + + + + + + + +
+ (0003616) +
+ Ina Schieferdecker    +
+ 15-10-2007 15:21    +
+ 		+ + + + +
+ to be considered together with CR 414
+
+
+
+ + + + + + + + + + +
+ (0004002) +
+ Thomas Deiß    +
+ 19-11-2007 13:51    +
+ 		+ + + + +
+ solved together with CR 414 (break, continue)
+
+
+
+ + + + + + + + + + +
+ (0004232) +
+ Jens Grabowski    +
+ 03-12-2007 14:20    +
+ 		+ + + + +
+ To be checked by Jens and afterwards by György.
+
+
+
+ + + + + + + + + + +
+ (0004253) +
+ Jens Grabowski    +
+ 04-12-2007 10:26    +
+ 		+ + + + +
+ Checked by Jens, see CR 414.
+
+
+
+ + + + + + + + + + +
+ (0004397) +
+ Gyorgy Rethy    +
+ 06-12-2007 17:04    +
+ 		+ + + + +
+ Resolved together with CR414; solution is in the file attached to CR414: new operation break will cause exiting an interleave
+
+ + diff --git a/docs/mantis/CR2000.md b/docs/mantis/CR2000.md new file mode 100644 index 0000000000000000000000000000000000000000..734089ae4374a8915f2dcdd4f7d640a72b666c05 --- /dev/null +++ b/docs/mantis/CR2000.md @@ -0,0 +1,250 @@ + + + + + + + + + + + + + 0002000: TCI Value instead of TriAddress is needed for matching addresses - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0002000Part 06: TTCN-3 Control InterfaceTechnicalpublic14-09-2007 14:2706-12-2007 10:10
ReporterAlexander Lorenz 
Assigned ToIna Schieferdecker 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.2.1 (published 2007-02) 
Target Versionv3.3.1 (published 2008-04)Fixed in Versionv3.3.1 (published 2008-04) 
Clause Reference(s)ETSI ES 201 873-6 V3.2.1 (2007-02),
Source (company - Author)Testing Technologies
Summary0002000: TCI Value instead of TriAddress is needed for matching addresses
DescriptionIn order to be able to match the recieved adress with the expected one it is necessary to use a TCI Value instead of TRiAddress, since the TriAddress is an encoded byte array and therefore cannot be compared to a TciValuTemplate.
+
+This concerns the following TLI methods:
+
+tliMReceive_m
+tliPrGetCall_m
+tliPrGetReply_m
+tliPrCatch_m
+
+tliMReceiveMismatch_m
+tliPrGetCallMismatch_m
+tliPrGetReplyMismatch_m
+tliPrCatchMismatch_m
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Fileszip es_20187306v030301_CR2000_v3.zip (991,002) 04-12-2007 11:56
http://oldforge.etsi.org/mantis/file_download.php?file_id=1188&type=bug
Issue History
Date ModifiedUsernameFieldChange
14-09-2007 14:27Alexander LorenzNew Issue
14-09-2007 14:27Alexander LorenzClause Reference(s) => ETSI ES 201 873-6 V3.2.1 (2007-02),
14-09-2007 14:27Alexander LorenzSource (company - Author) => Testing Technologies
14-09-2007 15:50Alexander LorenzNote Added: 0003279
13-10-2007 18:43Ina SchieferdeckerAssigned To => Ina Schieferdecker
13-10-2007 18:43Ina SchieferdeckerStatusnew => assigned
15-10-2007 12:31tepelmannNote Added: 0003606
15-10-2007 12:33tepelmannNote Edited: 0003606
18-10-2007 12:26Ina SchieferdeckerTarget Version => Edition 3.3.1 (not yet published)
18-10-2007 16:57Ina SchieferdeckerNote Added: 0003696
18-10-2007 16:57Ina SchieferdeckerResolutionopen => fixed
18-10-2007 16:58Ina SchieferdeckerFile Added: es_20187306v030301_CR2000.zip
18-10-2007 17:00Ina SchieferdeckerFile Deleted: es_20187306v030301_CR2000.zip
04-12-2007 11:56Ina SchieferdeckerFile Added: es_20187306v030301_CR2000_v3.zip
04-12-2007 16:38Ina SchieferdeckerAssigned ToIna Schieferdecker => Thomas Deiß
05-12-2007 16:55Thomas DeißNote Added: 0004346
05-12-2007 16:55Thomas DeißAssigned ToThomas Deiß => Ina Schieferdecker
05-12-2007 16:55Thomas DeißStatusassigned => resolved
06-12-2007 10:10Ina SchieferdeckerStatusresolved => closed
06-12-2007 10:10Ina SchieferdeckerNote Added: 0004363
06-12-2007 10:10Ina SchieferdeckerFixed in Version => Edition 3.3.1 (not yet published)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0003279) +
+ Alexander Lorenz    +
+ 14-09-2007 15:50    +
+ 		+ + + + +
+ The references in above mentioned standard document are:
+
+7.3.4.1.19 tliMReceive_m
+7.3.4.1.17 tliMMismatch_m
+7.3.4.1.31 tliPrGetCall_m
+7.3.4.1.43 tliPrGetReply_m
+7.3.4.1.55 tliPrCatch_m
+7.3.4.1.29 tliPrGetCallMismatch_m
+7.3.4.1.41 tliPrGetReplyMismatch_m
+7.3.4.1.53 tliPrCatchMismatch_m
+
+The respective XML Schema representation of these logging events in annex B.5 would also have to be changed accordingly.
+
+
+
+ + + + + + + + + + +
+ (0003606) +
+ tepelmann    +
+ 15-10-2007 12:31    +
(edited on: 15-10-2007 12:33)
+ 		+ + + + +
+ Furthermore there is also a need for the following send events:
+7.3.4.1.9 tliMSend_m
+7.3.4.1.11 tliMSend_m_MC
+7.3.4.1.21 tliPrCall_m
+7.3.4.1.23 tliPrCall_m_MC
+7.3.4.1.33 tliPrReply_m
+7.3.4.1.35 tliPrReply_m_MC
+7.3.4.1.45 tliPrRaise_m
+7.3.4.1.47 tliPrRaise_m_MC
+
+NOTE: In the multicast cases address value lists are needed.
+
+
+
+
+
+ + + + + + + + + + +
+ (0003696) +
+ Ina Schieferdecker    +
+ 18-10-2007 16:57    +
+ 		+ + + + +
+ The logging interface is not about matching!
+
+However, the proposal makes the named operations consistent to the other operation definitions
+
+Not only the XML mapping needs to be fixed, but also the C and the Java mapping - and annex A and B in addition.
+
+Furthermore, the duplicated TriAddressType definition in 10.3.2.13 has been removed.
+
+See attached fix
+
+
+
+
+
+ + + + + + + + + + +
+ (0004346) +
+ Thomas Deiß    +
+ 05-12-2007 16:55    +
+ 		+ + + + +
+ checked by Thomas.
+Take care of clauses 10.4.2 ff. In the solution they are just empty clauses as they are not relevant for this CR. In the revised text the clauses must have content.
+
+Clauses 11.3.8.2, 11.5.3.2, 11.5.4.2 contain a change, which is probably a find and replace error. system was changed to System. This must not be implemented.
+
+
+
+ + + + + + + + + + +
+ (0004363) +
+ Ina Schieferdecker    +
+ 06-12-2007 10:10    +
+ 		+ + + + +
+ Indeed 10.4.2 ff. has been a left over - only "TCI TL provided" is relevant as the XML mapping does only cope with this interface.
+
+It had been decided to get rid of the table structure in the mapping sections of TCI as all changes had to be made at several places which is errorprone - now, the operation mappings contain the C, Java or XML definitions only.
+
+ + diff --git a/docs/mantis/CR2012.md b/docs/mantis/CR2012.md new file mode 100644 index 0000000000000000000000000000000000000000..20e99d9cc7a08531c3dc4e76bfaf2ca379105030 --- /dev/null +++ b/docs/mantis/CR2012.md @@ -0,0 +1,528 @@ + + + + + + + + + + + + + 0002012: runs on self clause in function reference types - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0002012Part 01: TTCN-3 Core LanguageNew Featurepublic18-09-2007 10:5310-12-2009 10:05
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PriorityhighSeverityfeatureReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)new clause(s)
Source (company - Author)L.M.Ericsson - Gyorgy Rethy
Summary0002012: runs on self clause in function reference types
DescriptionFunction References (will) allow(s) calling testcases, functions and altsteps via their references (pointers) using the apply operation. In this case type compatibility is checked, and the type of the reference used in the apply operation shall be compatible with the runs on clause of the entity in which the apply operation is employed.
+When writing library functions, some details of the behaviour are use-case dependent and hence the user of the library shall be able to customize it (e.g. send out or wait for a co-ordination message at certain points, while other applications do not need this). This customization can be done by inserting hook points (see the if statement in the function f_LibraryFunctionNow in the example below) into the library functions/altsteps where user defined (so called callback ~) functions are called via reference, if the user stipulates so.
+However, the callback function type definition (see CallbackFunctionRefRunsonUserCT below) shall refer to a component type in its runs on clause, which causes a problem. Normally, each library is using its own component type definition, which declares all component constants, variables, timers and ports used by the library (see Library_CT definition in the example below). The user, when writing its own code, shall just extend the library component type(s) with its own constants, variables, timers and ports (see User_CT definition below). Several library component types can be extended simulaneously when defining the user component type. Callback function type definitions shall not use the Library_CT type in their runs on clauses as the user shall be able to use its own declarations within them and they are not defined in Library_CT but in User_CT.
+In principle, library functions could also extend a pre-defined (initially empty) user component type however, this is not a solution to the given problem. In this case all user and library components would be forced to run on one single component type throughout the whole test configuration that is very unpractical and resource-consuming; also, libraries have multiple levels (e.g. application libraries that are built on core libraries), where library functions on the higher level shall be able to see the library definitions of the lower library level. Hence, such kind of a turn-about component type extension is not realizable.
+In summary, the current runs on compatibility rules of the language do not support using callback functions.
+
+EXAMPLE 1: Using function/altstep references with runs on clauses
+module RunsOn_UserCT
+{
+// THIS MODULE DESCRIBES THE SITUATION TODAY, WITHOUT RUNS ON SELF
+
+type function CallbackFunctionRefRunsonUserCT () runs on User_CT;
+
+type component Library_CT
+{
+  var CallbackFunctionRefRunsonUserCT v_CallbackRef_UserCT := null;
+  var integer v_Lib;
+}
+
+type component User_CT extends Library_CT
+{
+  var integer v_User;
+  port COORDINATION_PT CP;
+}
+
+function f_MyCallbackFunction () runs on User_CT
+{/*application/dependent behaviour*/}
+
+function f_LibraryFunctionNow () runs on Library_CT
+{
+    if (v_CallbackRef_UserCT <> null)
+    {
+      // Calling the user callback function via reference causes semantic
+      // ERROR today as the callback function type is using runs on User_CT
+       v_CallbackRef_UserCT.apply()
+    }
+}// end f_LibraryFunction
+
+function f_MyUserFunctionNow () runs on User_CT
+{
+  v_CallbackRef_UserCT := refers (f_MyCallbackFunction);
+  f_LibraryFunctionNow();
+  
+}//end f_MyUserFunctionNow
+
+} // end of module
+
Steps To Reproduce
Additional InformationProposed solution:
+The solution in general is the following: function and altstep type definitions need not specify a concrete component type in their runs on clauses. This is identified by "runs on self" (this syntax uses no new TTCN-3 keyword!). In "normal" cases assignments are checked by inspecting the TYPE of the left and right hand values and their runs on clauses shall be the same or compatible. In the case the type of the left hand value is using "runs on self", the runs on clause of the right hand value's type is checked AGAINST the RUNS ON CLAUSE of the testcase/function/altstep in which the assignment is present.
+After this check this reference can safely be used within the given test component to call a function/altstep in any of the functions that is executed on this component (either library or user). No further check is needed at function invocation using the apply operation. See example 2 below.
+
+EXAMPLE 2: Using "runs on self"
+module RunsOn_Self
+{
+// THIS MODULE DESCRIBES THE PROPOSED SOLUTION WITH USING RUNS ON SELF
+
+//=========================================================================
+// Function Types
+//=========================================================================
+
+// Only function and altstep types may have "runs on self"; nor testcases,
+// neither function/altstep/testcase definitions shall have it
+type function CallbackFunctionRefRunsonSelf () runs on self;
+
+//=========================================================================
+//Component Types
+//=========================================================================
+type component Library_CT
+{
+  // These declarations are OK
+  var CallbackFunctionRefRunsonSelf v_CallbackRef_self := null;
+  var integer v_Lib;
+}
+
+type component User_CT extends Library_CT
+{
+  var integer v_User;
+}
+
+//=========================================================================
+// Functions
+//=========================================================================
+
+//-------------------------------------------------------------------------
+//EXAMPLE 2: WITH RUNS ON SELF
+//-------------------------------------------------------------------------
+
+//----------------------Solution-------------------------------------------
+
+function f_LibraryFunction () runs on Library_CT
+{
+  // Direct call of the callback function still would cause semantic ERROR
+  f_MyCallbackFunction();
+  
+  if (v_CallbackRef_self != null)
+  {
+    // Calling a function via reference that has a "runs on self" in its header
+    // is always allowed with the exception of functions/altsteps without runs
+    // on clause
+    v_CallbackRef_self.apply();
+  }
+}// end f_LibraryFunction
+
+function f_MyUserFunction () runs on User_CT
+{
+  // This is allowed as f_MyCallbackFunction has runs on clause compatible
+  // with the runs on clause of this function (f_MyUserFunction)
+  // The use of function/altstep references with "runs on self" in their
+  // headers is limited to call them on the given component instance; i.e.
+  // allowed: assignments, parameterization and activate (the actual function's
+  // runs on is compared to the runs on of the function in which
+  // the operation is executed)
+  // not allowed: start, sending and receiving
+  // no check is needed for apply!
+  v_CallbackRef_self := refers (f_MyCallbackFunction);
+  
+  // This is allowed as Library_CT is a parent of User_CT
+  // Pls. note, as the function is executing on a User_CT
+  // instance, it shall never cause a problem of calling
+  // a callback function with "runs on User_CT" from it.
+  f_LibraryFunction();
+  
+}//end f_MyUserFunctionNow
+
+function f_MyCallbackFunction () runs on User_CT
+{/*application/dependent behaviour*/}
+
+} // end of module
+However, the function/altstep reference value of a type using "runs on self" shall never leave the test component in which its actual value was assigned. Hence it is NOT allowed to:
+- assign it to a function/altstep reference (constant, template, variable, formal parameter) using a concrete component type in the runs on clause of its type definition;
+- start a PTC using a function reference with runs on self in its type definition;
+- sending and receiving of function/altstep references using runs on self (neither directly nor embedded in structured types).
+The detailed rules of using "runs on self" are given in the example below.
+
+EXAMPLE 3: Rules of using "runs on self"
+module RunsOn_Self_Rules
+{
+// THIS MODULE DESCRIBES THE PROPOSED SOLUTION WITH USING RUNS ON SELF
+
+//=========================================================================
+// Function Types
+//=========================================================================
+
+// Only function and altstep types may have "runs on self"; nor testcases,
+// neither function/altstep/testcase definitions shall have it
+type function CallbackFunctionRefRunsonLib () runs on Library_CT;
+type function CallbackFunctionRefRunsonUser () runs on User_CT;
+type function CallbackFunctionRefRunsonSelf () runs on self;
+
+//=========================================================================
+//Component Types
+//=========================================================================
+type component Library_CT
+{
+  // These declarations are OK
+  var CallbackFunctionRefRunsonSelf v_CallbackRef_self := null;
+  var CallbackFunctionRefRunsonLib v_CallbackRef_LibCT := null;
+  var integer v_Lib;
+}
+
+type component User_CT extends Library_CT
+{
+  var CallbackFunctionRefRunsonUser v_CallbackRef_UserCT := null;
+  var integer v_User;
+}
+
+//=========================================================================
+// Functions
+//=========================================================================
+
+//-------------------------------------------------------------------------
+//EXAMPLE 2: WITH RUNS ON SELF
+//-------------------------------------------------------------------------
+
+//-----------------------Rules of using runs on self-----------------------
+
+
+function f_Lib() runs on Library_CT
+{
+  log(v_Lib);
+}
+
+function f_User() runs on User_CT
+{
+  log(v_Lib);
+  log(v_User);
+}
+
+function f_LibParameterizedwLib (CallbackFunctionRefRunsonLib par_fRef)
+runs on Library_CT
+{}
+function f_LibParameterizedwUser (CallbackFunctionRefRunsonUser par_fRef)
+runs on Library_CT
+{}
+function f_LibParameterizedwSelf (CallbackFunctionRefRunsonSelf par_fRef)
+runs on Library_CT
+{}
+
+function f_UserParameterizedwLib (CallbackFunctionRefRunsonLib par_fRef)
+runs on User_CT
+{}
+function f_UserParameterizedwUser (CallbackFunctionRefRunsonUser par_fRef)
+runs on User_CT
+{}
+function f_UserParameterizedwSelf (CallbackFunctionRefRunsonSelf par_fRef)
+runs on User_CT
+{}
+
+
+function f_LibraryFunction2() runs on Library_CT
+{
+  var Library_CT vl_PTC_LibCT := Library_CT.create;
+
+// --------ASSIGNMENTS AND FUNCTION CALLS--------
+
+  // allowed by definition
+  f_Lib();
+  
+  // allowed because of the previous
+  v_CallbackRef_self := refers(f_Lib);
+  
+  // allowed by definition
+  v_CallbackRef_LibCT := refers(f_Lib);
+  
+  // semantic ERROR: NOT ALLOWED because it may refer to non-existent objects
+  f_User();
+  
+  // NOT ALLOWED because of the previous!!!
+  // One of the most important points of the proposal
+  v_CallbackRef_self := refers(f_User);
+  
+  // NOT ALLOWED because it refers to non-existent v_User
+  v_CallbackRef_LibCT := refers(f_User);
+  
+  // allowed by definition (even if it actually points to f_User)
+  v_CallbackRef_self.apply();
+  
+  // allowed by definition
+  v_CallbackRef_LibCT.apply();
+  
+  // allowed because of the previous
+  v_CallbackRef_self := v_CallbackRef_LibCT;
+  
+  // NOT ALLOWED because v_CallbackRef_LibCT can be exported from this
+  // component !!!
+  v_CallbackRef_LibCT := v_CallbackRef_self;
+
+// --------COMPONENT HANDLING--------
+  
+  // allowed by definition
+  vl_PTC_LibCT.start(f_Lib());
+  
+  // allowed by definition
+  vl_PTC_LibCT.start(derefers(v_CallbackRef_LibCT)());
+  
+  // NOT ALLOWED because f_User() refers to User_CT
+  vl_PTC_LibCT.start(f_User());
+  
+  // NOT ALLOWED by definition
+  // Another cardinal point of the proposal
+  vl_PTC_LibCT.start(derefers(v_CallbackRef_self)());
+
+// --------PARAMETERIZATION--------
+  // This is obviously OK as both the variable and the parameter type has
+  // the same type (using runs on Library_CT)
+  f_LibParameterizedwLib(v_CallbackRef_LibCT);
+  
+  // NOT ALLOWED as the parameter (of the type CallbackFunctionRefRunsonLib!)
+  // can be exported from the component within f_LibParameterizedwLib
+  f_LibParameterizedwLib(v_CallbackRef_self);
+  
+  // This is OK for the same reason as the assignment <v_CallbackRef_self :=
+  // v_CallbackRef_LibCT;> is allowed; note, use of the parameter is restricted
+  // within the function f_LibParameterizedwSelf;
+  f_LibParameterizedwSelf(v_CallbackRef_LibCT);
+  
+  // This is obviously OK as both the variable and the parameter type has
+  // the same type (using runs on self)
+  f_LibParameterizedwSelf(v_CallbackRef_self);
+  
+
+  // Makes no sense as no definition with runs on User_CT is known during
+  // writing library functions
+  f_LibParameterizedwUser(/*...*/)
+}
+
+function f_UserFunction() runs on User_CT
+{
+  var User_CT vl_PTC_UserCT := User_CT.create;
+  
+  // --------ASSIGNMENTS AND FUNCTION CALLS--------
+
+  // allowed because of compatibility
+  f_Lib();
+  
+  // allowed because of the previous
+  v_CallbackRef_self := refers(f_Lib);
+  
+  // allowed by definition
+  v_CallbackRef_LibCT := refers(f_Lib);
+  
+  // allowed by definition
+  v_CallbackRef_UserCT := refers(f_User);
+
+  // allowed by definition
+  f_User();
+  
+  // allowed because of the previous
+  v_CallbackRef_self := refers(f_User);
+  
+  // NOT ALLOWED because f_User() refers to User_CT and v_CallbackRef_LibCT's
+  // type refers to its parent, Library_CT
+  // Pls. note that v_CallbackRef_LibCT can be e.g. started on a PTC of the
+  // type Library_CT
+  v_CallbackRef_LibCT := refers(f_User);
+  
+  // allowed by definition
+  v_CallbackRef_self.apply();
+  
+  // allowed because of the previous
+  v_CallbackRef_self := v_CallbackRef_UserCT;
+
+  // allowed because of compatibility
+  v_CallbackRef_LibCT.apply();
+  
+  // allowed because of the previous
+  v_CallbackRef_self := v_CallbackRef_LibCT;
+  
+  // NOT ALLOWED because v_CallbackRef_self can refer to a function with
+  // runs on User_CT and v_CallbackRef_LibCT can be exported from this
+  // component
+  v_CallbackRef_LibCT := v_CallbackRef_self;
+  
+// --------COMPONENT HANDLING--------
+
+  // allowed because of compatibility
+  vl_PTC_UserCT.start(f_Lib());
+  
+  // allowed by definition
+  vl_PTC_UserCT.start(f_User());
+  
+  // NOT ALLOWED by definition
+  vl_PTC_UserCT.start(derefers(v_CallbackRef_self)());
+  
+  // allowed because of compatibility
+  vl_PTC_UserCT.start(derefers(v_CallbackRef_LibCT)());
+
+// --------PARAMETERIZATION--------
+  // This is obviously OK as both the variable and the parameter type has
+  // the same type (using runs on Library_CT)
+  f_UserParameterizedwLib(v_CallbackRef_LibCT);
+  
+  // NOT ALLOWED as the parameter (of the type CallbackFunctionRefRunsonLib!)
+  // can be exported from the component within f_UserParameterizedwLib
+  f_UserParameterizedwLib(v_CallbackRef_self);
+  
+  // This is OK for the same reason as the assignment <v_CallbackRef_self :=
+  // v_CallbackRef_UserCT;> is allowed; note, use of the parameter is
+  // restricted within the function f_UserParameterizedwSelf;
+  f_UserParameterizedwSelf(v_CallbackRef_UserCT);
+  
+  // This is obviously OK as both the variable and the parameter type has
+  // the same type (using runs on self)
+  f_UserParameterizedwSelf(v_CallbackRef_self);
+  
+
+  // NOT ALLOWED as the parameter (of the type CallbackFunctionRefRunsonUser!)
+  // can be exported from the component within f_UserParameterizedwLib
+  f_UserParameterizedwUser(v_CallbackRef_self)
+}
+
+function f_MyFunctionNoRunson()
+{
+  var Library_CT vl_PTC_LibCT := Library_CT.create;
+  var User_CT vl_PTC_UserCT := User_CT.create;
+  
+// --------ASSIGNMENTS AND FUNCTION CALLS--------
+
+  // allowed because of compatibility
+  vl_PTC_LibCT := vl_PTC_UserCT;
+  
+  // NOT ALLOWED
+  vl_PTC_UserCT := vl_PTC_LibCT;
+  
+  // allowed
+  var CallbackFunctionRefRunsonSelf vl_CallbackRef_self :=
+  refers(f_MyFunctionNoRunson);
+
+// --------COMPONENT HANDLING--------
+// No new case above those shown above
+
+// --------PARAMETERIZATION--------
+// Makes sense only in case of function/altstep references without runs on
+// clause that is out of scope of these examples
+
+}
+
+} // end of module
+
TagsNo tags attached.
Relationships
related to 0000412closed Tibor Csöndes Function reference 
Attached Filesdoc CR_Exx runs on self.doc (150,016) 18-09-2007 10:53
http://oldforge.etsi.org/mantis/file_download.php?file_id=983&type=bug
Issue History
Date ModifiedUsernameFieldChange
18-09-2007 10:53Gyorgy RethyNew Issue
18-09-2007 10:53Gyorgy RethyStatusnew => assigned
18-09-2007 10:53Gyorgy RethyAssigned To => Gyorgy Rethy
18-09-2007 10:53Gyorgy RethyFile Added: CR_Exx runs on self.doc
18-09-2007 10:53Gyorgy RethyClause Reference(s) => new clause(s)
18-09-2007 10:53Gyorgy RethySource (company - Author) => L.M.Ericsson - Gyorgy Rethy
19-09-2007 11:31Gyorgy RethySeveritymajor => feature
19-09-2007 11:31Gyorgy RethySummaryruns on self clause of function reefrrnce types => runs on self clause in function reference types
13-10-2007 18:54Ina SchieferdeckerAssigned ToGyorgy Rethy => Ina Schieferdecker
13-10-2007 18:54Ina SchieferdeckerAssigned ToIna Schieferdecker => developer_u
17-10-2007 11:22Ina SchieferdeckerNote Added: 0003656
17-10-2007 12:42user10Assigned Todeveloper_u => Thomas Deiß
18-10-2007 13:43Ina SchieferdeckerProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
18-10-2007 13:43Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
17-10-2008 15:38Ina SchieferdeckerRelationship addedrelated to 0000412
12-12-2008 09:50Thomas DeißNote Added: 0007674
12-12-2008 09:50Thomas DeißAssigned ToThomas Deiß => Gyorgy Rethy
10-03-2009 10:49Ina SchieferdeckerStatusassigned => resolved
10-03-2009 10:49Ina SchieferdeckerResolutionopen => fixed
10-03-2009 10:49Ina SchieferdeckerFixed in Version => Edition 4.1.1 (not yet published)
10-12-2009 10:05Gyorgy RethyStatusresolved => closed
10-12-2009 10:05Gyorgy RethyNote Added: 0009133
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0003656) +
+ Ina Schieferdecker    +
+ 17-10-2007 11:22    +
+ 		+ + + + +
+ To be considered together with CR 412 and also deferred to 2008
+
+
+
+ + + + + + + + + + +
+ (0007674) +
+ Thomas Deiß    +
+ 12-12-2008 09:50    +
+ 		+ + + + +
+ solution included in the one for CR412
+
+
+
+ + + + + + + + + + +
+ (0009133) +
+ Gyorgy Rethy    +
+ 10-12-2009 10:05    +
+ 		+ + + + +
+ Included into the Behaviour Types package, ES 202 785 V1.1.1
+
+ + diff --git a/docs/mantis/CR2025.md b/docs/mantis/CR2025.md new file mode 100644 index 0000000000000000000000000000000000000000..9d4af44cd8b4e316e9376c941227098ee8f62bf5 --- /dev/null +++ b/docs/mantis/CR2025.md @@ -0,0 +1,206 @@ + + + + + + + + + + + + + 0002025: Component synchronization operations - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0002025Part 01: TTCN-3 Core LanguageNew Featurepublic19-09-2007 11:2723-03-2010 13:11
ReporterGyorgy Rethy 
Assigned To 
PrioritynoneSeverityfeatureReproducibilityhave not tried
StatusclosedResolutionwon't fix 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Clause Reference(s)new
Source (company - Author)     
Summary0002025: Component synchronization operations
DescriptionCurrently test component synchronization is a complex task for the TS writer: test co-ordination messahes and internal ports shall be defined, in the dynamic behaviour ports shall be connected, co-ordination messages be sent/received. Especially, when several components shall be co-ordinated, this becomes complex and makes automatic test generation a more complex task. The purpose of the CR is to move these tasks from the tester to the test tools. This problem was reaised in 2004 already by Siemens and solving it is also supported by Ericsson. The Siemens paper on this topic is attached to this CR for information.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Fileszip Synchronization in TTCN-3.zip (70,915) 19-09-2007 11:27
http://oldforge.etsi.org/mantis/file_download.php?file_id=985&type=bug
ppt CR2025-Discussion-Jens-080716.ppt (266,752) 16-07-2008 14:53
http://oldforge.etsi.org/mantis/file_download.php?file_id=1553&type=bug
Issue History
Date ModifiedUsernameFieldChange
19-09-2007 11:27Gyorgy RethyNew Issue
19-09-2007 11:27Gyorgy RethyStatusnew => assigned
19-09-2007 11:27Gyorgy RethyAssigned To => Gyorgy Rethy
19-09-2007 11:27Gyorgy RethyFile Added: Synchronization in TTCN-3.zip
19-09-2007 11:27Gyorgy RethyClause Reference(s) => new
19-09-2007 11:27Gyorgy RethySource (company - Author) =>
13-10-2007 18:57Ina SchieferdeckerAssigned ToGyorgy Rethy => Jens Grabowski
17-10-2007 11:24Ina SchieferdeckerNote Added: 0003657
17-10-2007 11:28Ina SchieferdeckerNote Added: 0003658
18-10-2007 12:18Ina SchieferdeckerNote Deleted: 0003657
18-10-2007 13:46Ina SchieferdeckerProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
18-10-2007 13:57Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
16-07-2008 14:53Jens GrabowskiFile Added: CR2025-Discussion-Jens-080716.ppt
16-07-2008 14:55Jens GrabowskiNote Added: 0006296
12-12-2008 09:29Ina SchieferdeckerNote Added: 0007672
12-12-2008 09:29Ina SchieferdeckerTarget VersionEdition 4.1.1 (not yet published) => Edition 4.2.1 (not yet published)
16-02-2010 14:24Jens GrabowskiNote Added: 0009217
18-03-2010 07:35Ina SchieferdeckerTarget VersionEdition 4.2.1 (not yet published) => Edition 5.1.1 (not yet published)
22-03-2010 17:24Gyorgy RethyAssigned ToJens Grabowski =>
22-03-2010 17:24Gyorgy RethyStatusassigned => new
23-03-2010 13:11Gyorgy RethyNote Added: 0009261
23-03-2010 13:11Gyorgy RethyStatusnew => closed
23-03-2010 13:11Gyorgy RethyResolutionopen => won't fix
23-03-2010 13:11Gyorgy RethyTarget VersionEdition 4.3.1 (not yet published) =>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0003658) +
+ Ina Schieferdecker    +
+ 17-10-2007 11:28    +
+ 		+ + + + +
+ Deferred to 2008
+Issues:
+- global/local sync points
+- explicit subscription to sync points - which level of control is appropriate
+- relation to alive components
+
+
+
+ + + + + + + + + + +
+ (0006296) +
+ Jens Grabowski    +
+ 16-07-2008 14:55    +
+ 		+ + + + +
+ PPT presentation for discussion has been uploaded.
+
+Personal View of Jens Grabowski: Go for a synchronization library instead of introducing something new that can already be expressed in TTCN-3.
+
+
+
+ + + + + + + + + + +
+ (0007672) +
+ Ina Schieferdecker    +
+ 12-12-2008 09:29    +
+ 		+ + + + +
+ The synchronization library has to be developed. It may become part of the configuration and deployment package.
+
+
+
+
+ + + + + + + + + + +
+ (0009217) +
+ Jens Grabowski    +
+ 16-02-2010 14:24    +
+ 		+ + + + +
+ To be discussed again for version 5.1.1.
+
+
+
+ + + + + + + + + + +
+ (0009261) +
+ Gyorgy Rethy    +
+ 23-03-2010 13:11    +
+ 		+ + + + +
+ CR is closed as the feature is available in the IPv6 library and there is no clear need (stakeholder) to add this feature at the language & tool level.
+
+ + diff --git a/docs/mantis/CR2027.md b/docs/mantis/CR2027.md new file mode 100644 index 0000000000000000000000000000000000000000..e95d21254dcda10fe8b77a667bc58be4c47ea818 --- /dev/null +++ b/docs/mantis/CR2027.md @@ -0,0 +1,97 @@ + + + + + + + + + + + + + 0002027: ASN.1 (2007) to TTCN-3 mapping - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 07: Using ASN.1 with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0002027Part 07: Using ASN.1 with TTCN-3New Featurepublic19-09-2007 12:3102-02-2010 16:13
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PriorityhighSeverityfeatureReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.2.1 (published 2010-07)Fixed in Versionv4.2.1 (published 2010-07) 
Clause Reference(s)Part-7, all
Source (company - Author)     
Summary0002027: ASN.1 (2007) to TTCN-3 mapping
DescriptionThe current ASN.1 to TTCN-3 mapping standard (Part-7) is based on the ASN.1 (2002) series Recommendations. From that time several Ammendments and Corrigenda (e.g. in case of X680 Amendments 1 to 4 and Corrigenda 1) has been published by ITU-T, the newest ones i 2007. 3GPP requires the support of the latest ASN.1 to be able to use TTCN-3 for LTE conformance tests. Part-7 shall be amended to make it fully compatible with the latest revisions of the ITU-T ASN.1 Recommendations.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
child of 0005269closed Gyorgy Rethy Language specification for ASN.1:2009 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
19-09-2007 12:31Gyorgy RethyNew Issue
19-09-2007 12:31Gyorgy RethyStatusnew => assigned
19-09-2007 12:31Gyorgy RethyAssigned To => Gyorgy Rethy
19-09-2007 12:31Gyorgy RethyClause Reference(s) => Part-7, all
19-09-2007 12:31Gyorgy RethySource (company - Author) =>
19-09-2007 12:32Gyorgy RethySummaryASN.1 (2004) to TTCN-3 mapping => ASN.1 (2007) to TTCN-3 mapping
19-09-2007 12:32Gyorgy RethyDescription Updated
17-10-2007 11:15Ina SchieferdeckerNote Added: 0003654
18-10-2007 13:55Ina SchieferdeckerProjectTTCN-3 Change Requests => Part 07: Using ASN.1 with TTCN-3
18-10-2007 14:15Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
28-11-2008 12:41Ina SchieferdeckerProjectPart 07: Using ASN.1 with TTCN-3 => Part 09: Using XML with TTCN-3
28-11-2008 12:44Ina SchieferdeckerProjectPart 09: Using XML with TTCN-3 => Part 07: Using ASN.1 with TTCN-3
20-04-2009 12:17Ina SchieferdeckerTarget VersionEdition 4.1.1 (not yet published) => Edition 4.2.1 (not yet published)
13-07-2009 15:38Gyorgy RethyRelationship addedrelated to 0005269
08-09-2009 18:15Gyorgy RethyRelationship deletedrelated to 0005269
08-09-2009 18:16Gyorgy RethyRelationship addedparent of 0005269
08-09-2009 18:16Gyorgy RethyRelationship deletedparent of 0005269
08-09-2009 18:16Gyorgy RethyRelationship addedchild of 0005269
02-02-2010 16:13Gyorgy RethyNote Added: 0009188
02-02-2010 16:13Gyorgy RethyStatusassigned => closed
02-02-2010 16:13Gyorgy RethyResolutionopen => fixed
02-02-2010 16:13Gyorgy RethyFixed in Version => Edition 4.2.1 (not yet published)
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0003654) +
+ Ina Schieferdecker    +
+ 17-10-2007 11:15    +
+ 		+ + + + +
+ Considered in 2008
+
+
+
+ + + + + + + + + + +
+ (0009188) +
+ Gyorgy Rethy    +
+ 02-02-2010 16:13    +
+ 		+ + + + +
+ New ASN.1 types (ISO 8601-based time types, OID-IRI and relative ID-IRI) are added to the mapping.
+
+ + diff --git a/docs/mantis/CR2105.md b/docs/mantis/CR2105.md new file mode 100644 index 0000000000000000000000000000000000000000..6cdcb06567d11b06765348be4d4b02f9ad159bab --- /dev/null +++ b/docs/mantis/CR2105.md @@ -0,0 +1,651 @@ + + + + + + + + + + + + + 0002105: address should also be bind to port type - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0002105Part 01: TTCN-3 Core LanguageNew Featurepublic04-10-2007 18:1001-12-2010 14:37
Reportertepelmann 
Assigned ToIna Schieferdecker 
PrioritylowSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.3.1 (published 2011-06)Fixed in Versionv4.3.1 (published 2011-06) 
Clause Reference(s)9.1
Source (company - Author)Testing Technologies - Dirk Tepelmann
Summary0002105: address should also be bind to port type
DescriptionCurrently the address is bound module-wise, however in my opinion it should also be possible to bind the address type to a port type declaration as the port type defines the communication.
+This enables the usage of different address types port-type-wise.
+
+type port PortTypeIdentifier message "{"
+{ ( in | out | inout ) ( all | { MessageType [ "," ] }+ ) ";" }
+{ address { MessageType } ";" }
+"}"
+
+To reference the specific address type, the type should be retrievable via dotted notation based on the port type(similiar to the access of anonymous inline type definitions in structured types).
+
+var <port type>.address <varIdentifier> ":=" Expression
+
Steps To Reproduce
Additional InformationE.g.:
+
+type port P message { inout all; address integer; };
+type port Q message { inout all; address charstring; };
+
+function f() runs on C {
+  var P.address addr0 := 0;
+
+  p.send(AAA) to 0;
+  p.send(AAA) to addr0;
+
+  q.send(BBB) to "127.0.0.1";
+}
TagsNo tags attached.
Relationships
related to 0005417closed Ina Schieferdecker Support of parametrized map/unmap operation for full dynamic mapping 
related to 0005588closed Ina Schieferdecker Follow-up of CR2105 - Deprecating using addressing without explicit binding the addressing type to the port type 
related to 0005923closed Ina Schieferdecker BNF (rules 50 and 58) in appendix A and port type definition chapter 6.2.9 do not match 
Attached Filesdoc CR-2105-address-bound-to-port-type-Resolution-V1-081222.doc (189,440) 22-12-2008 12:36
http://oldforge.etsi.org/mantis/file_download.php?file_id=1924&type=bug
zip CR2105-Resolution-Jens-100630.zip (48,382) 30-06-2010 16:04
http://oldforge.etsi.org/mantis/file_download.php?file_id=2389&type=bug
zip CR2105-Resolution-Jens-100702.zip (49,161) 02-07-2010 11:32
http://oldforge.etsi.org/mantis/file_download.php?file_id=2401&type=bug
doc CR2105-Resolution-101201.doc (300,032) 01-12-2010 10:16
http://oldforge.etsi.org/mantis/file_download.php?file_id=2451&type=bug
doc CR2105-Resolution-101201a.doc (227,840) 01-12-2010 14:36
http://oldforge.etsi.org/mantis/file_download.php?file_id=2458&type=bug
Issue History
Date ModifiedUsernameFieldChange
04-10-2007 18:10tepelmannNew Issue
04-10-2007 18:10tepelmannStatusnew => assigned
04-10-2007 18:10tepelmannAssigned To => Gyorgy Rethy
04-10-2007 18:10tepelmannClause Reference(s) => 9.1
04-10-2007 18:10tepelmannSource (company - Author) => Testing Technologies - Dirk Tepelmann
13-10-2007 18:53Ina SchieferdeckerAssigned ToGyorgy Rethy => Jens Grabowski
17-10-2007 11:18Ina SchieferdeckerNote Added: 0003655
17-10-2007 11:18Ina SchieferdeckerCategoryTechnical => New Feature
18-10-2007 13:46Ina SchieferdeckerProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
18-10-2007 13:58Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
18-07-2008 09:51Jens GrabowskiNote Added: 0006327
22-12-2008 12:34Jens GrabowskiNote Added: 0007758
22-12-2008 12:36Jens GrabowskiFile Added: CR-2105-address-bound-to-port-type-Resolution-V1-081222.doc
22-12-2008 12:36Jens GrabowskiAssigned ToJens Grabowski =>
22-12-2008 12:36Jens GrabowskiAssigned To => Ina Schieferdecker
22-12-2008 12:37Ina SchieferdeckerNote Added: 0007759
22-12-2008 12:37Ina SchieferdeckerTarget VersionEdition 4.1.1 (not yet published) => Edition 4.2.1 (not yet published)
22-12-2008 12:48Ina SchieferdeckerAssigned ToIna Schieferdecker => Jens Grabowski
16-02-2010 14:23Jens GrabowskiStatusassigned => closed
16-02-2010 14:23Jens GrabowskiNote Added: 0009216
16-02-2010 14:23Jens GrabowskiResolutionopen => won't fix
16-02-2010 15:22tepelmannStatusclosed => feedback
16-02-2010 15:22tepelmannResolutionwon't fix => reopened
16-02-2010 15:22tepelmannNote Added: 0009225
18-03-2010 07:32Ina SchieferdeckerTarget VersionEdition 4.2.1 (not yet published) => Edition 5.1.1 (not yet published)
23-03-2010 13:06Gyorgy RethyPrioritynormal => low
24-03-2010 08:54Jacob Wieland - SpirentNote Added: 0009273
24-03-2010 08:56Jacob Wieland - SpirentRelationship addedrelated to 0005417
25-03-2010 09:08Gyorgy RethyNote Added: 0009294
25-03-2010 09:09Gyorgy RethyNote Edited: 0009294
26-03-2010 09:39Gyorgy RethyStatusfeedback => assigned
26-03-2010 09:41Gyorgy RethyNote Added: 0009321
26-03-2010 14:37Gyorgy RethyNote Edited: 0009294
30-06-2010 16:04Jens GrabowskiFile Added: CR2105-Resolution-Jens-100630.zip
30-06-2010 16:05Jens GrabowskiNote Added: 0009435
30-06-2010 16:05Jens GrabowskiAssigned ToJens Grabowski => Gyorgy Rethy
01-07-2010 10:37Gyorgy RethyNote Added: 0009443
01-07-2010 10:38Gyorgy RethyAssigned ToGyorgy Rethy => Jens Grabowski
02-07-2010 10:02Jens GrabowskiNote Added: 0009462
02-07-2010 10:02Jens GrabowskiAssigned ToJens Grabowski => Ina Schieferdecker
02-07-2010 10:02Jens GrabowskiStatusassigned => resolved
02-07-2010 10:02Jens GrabowskiResolutionreopened => fixed
02-07-2010 10:21Gyorgy RethyNote Added: 0009463
02-07-2010 10:21Gyorgy RethyStatusresolved => assigned
02-07-2010 10:21Gyorgy RethyNote Edited: 0009463
02-07-2010 11:10Gyorgy RethyAssigned ToIna Schieferdecker => Jens Grabowski
02-07-2010 11:32Jens GrabowskiFile Added: CR2105-Resolution-Jens-100702.zip
02-07-2010 11:33Jens GrabowskiNote Added: 0009469
02-07-2010 11:33Jens GrabowskiAssigned ToJens Grabowski => Gyorgy Rethy
01-12-2010 10:07Gyorgy RethyNote Added: 0009877
01-12-2010 10:15Gyorgy RethyNote Edited: 0009877
01-12-2010 10:16Gyorgy RethyFile Added: CR2105-Resolution-101201.doc
01-12-2010 10:16Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
01-12-2010 13:56Ina SchieferdeckerNote Added: 0009896
01-12-2010 13:57Ina SchieferdeckerFile Added: CR2105-Resolution-101201a.doc
01-12-2010 13:57Ina SchieferdeckerStatusassigned => resolved
01-12-2010 13:57Ina SchieferdeckerFixed in Version => Edition 4.3.1 (not yet published)
01-12-2010 14:36Ina SchieferdeckerFile Deleted: CR2105-Resolution-101201a.doc
01-12-2010 14:36Ina SchieferdeckerFile Added: CR2105-Resolution-101201a.doc
01-12-2010 14:37Ina SchieferdeckerStatusresolved => closed
14-12-2010 15:39Ina SchieferdeckerRelationship addedrelated to 0005588
29-09-2011 09:47Ina SchieferdeckerRelationship addedrelated to 0005923
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0003655) +
+ Ina Schieferdecker    +
+ 17-10-2007 11:18    +
+ 		+ + + + +
+ This CR is to be considered in the wider scope of test configuration and therefore considered in 2008 only.
+
+
+
+ + + + + + + + + + +
+ (0006327) +
+ Jens Grabowski    +
+ 18-07-2008 09:51    +
+ 		+ + + + +
+ CR is in principle OK. Proposed implementation in the standard needs to be refined.
+
+
+
+ + + + + + + + + + +
+ (0007758) +
+ Jens Grabowski    +
+ 22-12-2008 12:34    +
+ 		+ + + + +
+ The following problems arose when trying to implement this CR.
+
+(1) Clause 5.2.2 "Uniqueness of identifiers" will be violated because the keyword address (which is also the identifier of that type) may be bound to several types within one module. So far, TTCN-3 only allows dot notation to resolve ambiguities with identifiers only on module level (e.g., the module identifier is used to distinguish between local and imported definitions). Weakening this clause requires a larger discussion (why shall overloading only allowed for the address type?).
+
+(2) Implementing this CR requires larger changes in the BNF. Special rules have to be defined to allow the binding of the address type to a port and the dot notation with port type identifiers has to be introdruced for referenced types.
+
+The conclusion is that the CR looks simple and easy to implement, but needs a further discussion. Therefore, the CR should be moved to 2009.
+
+A proposal for the text implementing the CR in the clauses 6.2.9 and 6.2.12 is uploaded.
+
+
+
+ + + + + + + + + + +
+ (0007759) +
+ Ina Schieferdecker    +
+ 22-12-2008 12:37    +
+ 		+ + + + +
+ This CR requires more discussion
+
+
+
+ + + + + + + + + + +
+ (0009216) +
+ Jens Grabowski    +
+ 16-02-2010 14:23    +
+ 		+ + + + +
+ Issue was reported 3 years ago! After report no one again showed interest in this CR. Therefore, it is closed.
+
+
+
+ + + + + + + + + + +
+ (0009225) +
+ tepelmann    +
+ 16-02-2010 15:22    +
+ 		+ + + + +
+ Testing Technologies still claim interest for this CR.
+If any clarification or support can be provided, don't hesitate to contact us.
+
+
+
+ + + + + + + + + + +
+ (0009273) +
+ Jacob Wieland - Spirent    +
+ 24-03-2010 08:54    +
+ 		+ + + + +
+ The problems mentioned earlier with this CR are (in part) not valid anymore, as now the BNF already allows referencing parts of types for structured types. To enlarge the semantics to work on port-types as well (with the special field reference address which should be the address type specified in the port type, and only applicable if such an address type was specified). There is no overloading involved as the declarations would be local to the port type definition.
+
+However, this is not really necessary at all as one could always just reference the type of the address specification of the port directly.
+
+So, instead of
+
+var P.address x := 0;
+
+one could write
+
+var integer x := 0;
+
+The static semantics would need to reflect that the referenced address expressions used in to and from clauses are compatible with the address type of the port (if one is declared in its type).
+
+Thus, the only really necessary changes in the standard are the addition of the address declaration in the port type definition and the change in the description of the to/from clauses accordingly.
+
+
+
+ + + + + + + + + + +
+ (0009294) +
+ Gyorgy Rethy    +
+ 25-03-2010 09:08    +
(edited on: 26-03-2010 14:37)
+ 		+ + + + +
+ I agree that the addressing should be bound to the port type, as today no one can know that in case of which port implementations the address type should be supported and in which cases it is not needed (i.e. how to implement it in the adapter).
+
+1. I don't like the syntax, namely using the type keyword inside a port type definition. It looks like as if a new type had been defined, while this is not the case. The type has to be defined normally, as a global type (or is a built-in type) and the port type shall just denote that it wants to use that type definition for addressing purposes. I propose instead:
+type port MyPort
+message {
+  inout Tinky-winky,
+  address MyRecordType
+  }
+procedure {
+  inout Gipsy,
+  address integer
+}
+
+2. It should be made explicit that a port either using the global address type OR its own address binding, i.e. if a port type binds a global type for addressing, instances of that port type shall not use the global address type.
+
+
+
+
+
+ + + + + + + + + + +
+ (0009321) +
+ Gyorgy Rethy    +
+ 26-03-2010 09:41    +
+ 		+ + + + +
+ status feedback shall only be used when we are waiting for an external feedback.
+
+
+
+ + + + + + + + + + +
+ (0009435) +
+ Jens Grabowski    +
+ 30-06-2010 16:05    +
+ 		+ + + + +
+ Resolution version 1 uploaded, re-assigned to György for proofreading.
+
+
+
+ + + + + + + + + + +
+ (0009443) +
+ Gyorgy Rethy    +
+ 01-07-2010 10:37    +
+ 		+ + + + +
+ The proposed text is quite OK but I propose to make explicit address type declaration in port types mandatory; i.e. deprecate the feature of using to/from clauses on mapped ports without explicit address type declaration. This would allow using the predefined type name address further on (otherwise we would have backward compatibility problem) but would remove the problems we have today:
+- there is a strange implicit binding by declaring address and the port type within the same module that is not optimal for practical use (normally each port type is declared in a separate module to allow th user to select which ports he/she wants to use).
+- but if several port types are declared in the same module it is unclear today that in context of which addressing can be used and in context of which it shall not be used. This information is not given in the TTCN-3 code, thus the code has to be supplemented with an informal information specifying this (adapter implementation issue).
+
+The syntax, when using the address type:
+type port message {
+   address address,
+...
+looks a little bit strange, but I think this is some thing we can and have to live with...
+
+
+
+ + + + + + + + + + +
+ (0009462) +
+ Jens Grabowski    +
+ 02-07-2010 10:02    +
+ 		+ + + + +
+ Deprecating the address type should be proposed in a new CR which should be discussed with MTS and possibly the tool vendors. Removing the address type from the text requires some work.
+
+For the moment, I assign the CR to Ina, set the resolution to fixed and set the status to resolved.
+
+
+
+ + + + + + + + + + +
+ (0009463) +
+ Gyorgy Rethy    +
+ 02-07-2010 10:21    +
+ 		+ + + + +
+ The new restrictions that
+AddressRef shall not contain matching mechanisms
+is not correct. We allowed using templates in to/from clauses to support multicasting and be able to provide a list of addressees in form of a value list. But value list is a matching mechanism, so at least value list matching shall be allowed in both to and from clauses. But in fact in most cases addresses are not simple types but structured types, mostly records. Why disallow e.g.
+... from { connEP := ?, entity:= XYentity } ...?
+
+
+
+
+
+ + + + + + + + + + +
+ (0009469) +
+ Jens Grabowski    +
+ 02-07-2010 11:33    +
+ 		+ + + + +
+ New resolution text uploaded. Reassigned to György for proofreading.
+
+
+
+ + + + + + + + + + +
+ (0009877) +
+ Gyorgy Rethy    +
+ 01-12-2010 10:07    +
(edited on: 01-12-2010 10:15)
+ 		+ + + + +
+ I have noticed that the syntactical structures in clauses 22.2.1-22.4 contain AddressRef only (no AddressRefList and all|any component), so added a note to clarify this. Plus editorials. Pls. cross-check. See CR2105-Resolution-101201.doc
+
+
+
+
+
+ + + + + + + + + + +
+ (0009896) +
+ Ina Schieferdecker    +
+ 01-12-2010 13:56    +
+ 		+ + + + +
+ basically ok, some smaller corrections and simplifications only
+
+ + diff --git a/docs/mantis/CR2108.md b/docs/mantis/CR2108.md new file mode 100644 index 0000000000000000000000000000000000000000..1e07d6a4f1832c3767f2a5a09e3114e438350326 --- /dev/null +++ b/docs/mantis/CR2108.md @@ -0,0 +1,122 @@ + + + + + + + + + + + + + 0002108: Example uses function in template with out parameter - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0002108Part 01: TTCN-3 Core LanguageEditorialpublic05-10-2007 17:3112-03-2008 10:24
ReporterThomas Deiß 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.2.1 (published 2007-02) 
Target Versionv3.3.2 (published 2008-04)Fixed in Versionv3.3.2 (published 2008-04) 
Clause Reference(s)5.4.1.1, 16.1.4
Source (company - Author)Thomas Deiß
Summary0002108: Example uses function in template with out parameter
DescriptionExample 2 in clause 5.4.1.1 uses a function with an inout parameter inside a template definition. But this is not allowed according to clause 16.1.4. item j).
+
+Proposed resolution: change the template in the example to a function and adapt its usage (name changed from t_MyMessage to f_MyMessage)
+
+function f_MyMessage (integer p_int) return MyMessage {
+  var integer f1,f2;
+  f1 := f_mult2 (p_int),
+  // parameter p_int is passed on; as the parameter of the called function f_mult2 is
+  // defined as an inout parameter, it passes back the changed value for p_int,
+  f2 := p_int;
+  return {f1, f2};
+}
+
+...
+
+testcase tc_01 () runs on MTC_PT {
+    ...
+      P1.send (f_MyMessage(5))
+        // the value sent is { f1 := 9 , f2 := 10 }
+    ...
+    }
+
+
+
+
Steps To Reproduce
Additional InformationNote 1) The reason given that functions with inout parameters cannot be used do not apply in this case, for usage in boolean guards of alternatives they are fine. But inside a template changes do not propagate outside the template, so there should not be a problem of using them.
+Note 2) What is the evaluation order inside a template, is this fixed to be top down? Or what is the order in case of a modified template? If this is not fixed there might be unexpected results. Despite of note 1) it might be best to keep the restriction in item j) to avoid surprises.
TagsNo tags attached.
Relationships
Attached Filesdoc CR-2108-Example-Uses-Function-in-Template-with-out-Parameter-Resolution.doc (210,944) 04-12-2007 16:19
http://oldforge.etsi.org/mantis/file_download.php?file_id=1199&type=bug
Issue History
Date ModifiedUsernameFieldChange
05-10-2007 17:31Thomas DeißNew Issue
05-10-2007 17:31Thomas DeißClause Reference(s) => 5.4.1.1, 16.1.4
05-10-2007 17:31Thomas DeißSource (company - Author) => Thomas Deiß
13-10-2007 19:06Ina SchieferdeckerStatusnew => assigned
13-10-2007 19:06Ina SchieferdeckerAssigned To => Ina Schieferdecker
13-10-2007 19:06Ina SchieferdeckerAssigned ToIna Schieferdecker => Jens Grabowski
18-10-2007 12:25Ina SchieferdeckerTarget Version => Edition 3.3.1 (not yet published)
04-12-2007 16:19Jens GrabowskiFile Added: CR-2108-Example-Uses-Function-in-Template-with-out-Parameter-Resolution.doc
04-12-2007 16:20Jens GrabowskiNote Added: 0004281
04-12-2007 16:20Jens GrabowskiAssigned ToJens Grabowski => Thomas Deiß
04-12-2007 16:20Jens GrabowskiResolutionopen => fixed
04-12-2007 16:54Thomas DeißNote Added: 0004287
04-12-2007 16:54Thomas DeißAssigned ToThomas Deiß => Ina Schieferdecker
04-12-2007 16:54Thomas DeißStatusassigned => resolved
05-12-2007 17:11Ina SchieferdeckerStatusresolved => closed
05-12-2007 17:11Ina SchieferdeckerFixed in Version => Edition 3.3.1 (not yet published)
12-03-2008 10:22user10Fixed in VersionEdition 3.3.1 --will not be published, see 3.3.2 => Edition 3.3.2 (not yet published)
12-03-2008 10:24user10Target VersionEdition 3.3.1 --will not be published, see 3.3.2 => Edition 3.3.2 (not yet published)
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0004281) +
+ Jens Grabowski    +
+ 04-12-2007 16:20    +
+ 		+ + + + +
+ Resolution follows the proposal of the submitter. Assigned to Thomas for crosschecking.
+
+
+
+ + + + + + + + + + +
+ (0004287) +
+ Thomas Deiß    +
+ 04-12-2007 16:54    +
+ 		+ + + + +
+ checked by Thomas: Ok
+
+ + diff --git a/docs/mantis/CR2136.md b/docs/mantis/CR2136.md new file mode 100644 index 0000000000000000000000000000000000000000..a29fa16e59a8650adff7884a4402a8001000effa --- /dev/null +++ b/docs/mantis/CR2136.md @@ -0,0 +1,105 @@ + + + + + + + + + + + + + 0002136: Remove sizeoftype predefined function - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0002136Part 01: TTCN-3 Core LanguageTechnicalpublic12-10-2007 13:0612-03-2008 10:24
ReporterRoland Gecse 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityfeatureReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.2.1 (published 2007-02) 
Target Versionv3.3.2 (published 2008-04)Fixed in Versionv3.3.2 (published 2008-04) 
Clause Reference(s)C.30
Source (company - Author)L.M.Ericsson
Summary0002136: Remove sizeoftype predefined function
DescriptionThe sizeoftype predefined function is supposed to be applied to "values of types with length restriction" and return "the sequential number of the last element without respect to whether its value is defined or not".
+
+The return value depends on the length constraints of the type of the parameter. TTCN-3 subtype constraints are static and known at compilation time. The user is aware of these constraints when writing test cases w/o using sizeoftype. sizeoftype has thus no real contribution to TTCN-3.
+
+Besides, sizeoftype behavior is undefined for a parameter type with indefinite upper bound length restriction e.g.
+
+type set length(100..infinity) of integer whatever;
+
+since "infinity" is not a number. This deficiency also contributes to the proposal of eliminating sizeoftype from TTCN-3.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc STF_solution_CR2136R1.doc (286,720) 18-10-2007 19:27
http://oldforge.etsi.org/mantis/file_download.php?file_id=1053&type=bug
Issue History
Date ModifiedUsernameFieldChange
12-10-2007 13:06Roland GecseNew Issue
12-10-2007 13:06Roland GecseClause Reference(s) => C.30
12-10-2007 13:06Roland GecseSource (company - Author) => L.M.Ericsson
13-10-2007 19:04Ina SchieferdeckerStatusnew => assigned
13-10-2007 19:04Ina SchieferdeckerAssigned To => Gyorgy Rethy
15-10-2007 15:31Ina SchieferdeckerNote Added: 0003619
17-10-2007 17:01Gyorgy RethyFile Added: es_20187301v030201p_CR2136.doc
17-10-2007 17:02Gyorgy RethyFile Deleted: es_20187301v030201p_CR2136.doc
17-10-2007 17:02Gyorgy RethyFile Added: STF_solution_CR2136.doc
18-10-2007 12:06Ina SchieferdeckerTarget Version => Edition 3.3.1 (not yet published)
18-10-2007 19:27Gyorgy RethyFile Added: STF_solution_CR2136R1.doc
18-10-2007 19:28Gyorgy RethyFile Deleted: STF_solution_CR2136.doc
19-10-2007 13:17Gyorgy RethyResolutionopen => fixed
06-12-2007 18:28Gyorgy RethyNote Added: 0004406
06-12-2007 18:28Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
06-12-2007 18:28Gyorgy RethyStatusassigned => resolved
07-12-2007 09:24Ina SchieferdeckerStatusresolved => closed
07-12-2007 09:24Ina SchieferdeckerFixed in Version => Edition 3.3.1 (not yet published)
12-03-2008 10:22user10Fixed in VersionEdition 3.3.1 --will not be published, see 3.3.2 => Edition 3.3.2 (not yet published)
12-03-2008 10:24user10Target VersionEdition 3.3.1 --will not be published, see 3.3.2 => Edition 3.3.2 (not yet published)
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0003619) +
+ Ina Schieferdecker    +
+ 15-10-2007 15:31    +
+ 		+ + + + +
+ to be put as depreacted predefined function
+
+
+
+ + + + + + + + + + +
+ (0004406) +
+ Gyorgy Rethy    +
+ 06-12-2007 18:28    +
+ 		+ + + + +
+ Solution is in the file attached to CR424: function is removed.
+
+ + diff --git a/docs/mantis/CR2137.md b/docs/mantis/CR2137.md new file mode 100644 index 0000000000000000000000000000000000000000..b1f5b6d81041d0421f25b82f5500fd529b21fbd2 --- /dev/null +++ b/docs/mantis/CR2137.md @@ -0,0 +1,155 @@ + + + + + + + + + + + + + 0002137: Faulty examples in sizeof documentation - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0002137Part 01: TTCN-3 Core LanguageEditorialpublic12-10-2007 13:5212-03-2008 10:24
ReporterRoland Gecse 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.2.1 (published 2007-02) 
Target Versionv3.3.2 (published 2008-04)Fixed in Versionv3.3.2 (published 2008-04) 
Clause Reference(s)C.29
Source (company - Author)L.M.Ericsson
Summary0002137: Faulty examples in sizeof documentation
DescriptionSeveral syntactical/semantical faults appear in the examples given at the specification of sizeof predefined function.
+
+1) The template definition of MyTemplate is syntactically invalid and should be replaced.
+
+Faulty definition:
+
+template MyPDU MyTemplate { field1 omit, field2 5 };
+
+Corrected definition:
+
+template MyPDU MyTemplate := { field1 := omit, field2 := 5 };
+
+2.a) Editorial: Using the identifier MyRecordVar for a record of type variable is more than misleading:
+
+var MyList MyRecordVar;
+
+I would recommend to change it to e.g. MyRecordOfVar of MyListVar in all places.
+
+2.b) Semantical: The use of omit is not appropriate in MyRecordVar initializer as MyRecordVar resolves to a record of integer type, which must not contain optional elements, thus statement "The omit keyword shall not be used for mandatory fields." in section 6.2 invalidates the code:
+
+MyRecordVar := { 0, 1, omit, 2, omit };
+
+The intended content would probably be:
+
+MyRecordVar := { 0, 1, -, 2, - };
Steps To Reproduce
Additional InformationI remember seeing omit values appearing in other places in the Core Language specification, thus it might be worth reviewing all the examples.
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
12-10-2007 13:52Roland GecseNew Issue
12-10-2007 13:52Roland GecseClause Reference(s) => C.29
12-10-2007 13:52Roland GecseSource (company - Author) => L.M.Ericsson
13-10-2007 19:03Ina SchieferdeckerStatusnew => assigned
13-10-2007 19:03Ina SchieferdeckerAssigned To => Gyorgy Rethy
17-10-2007 18:39Gyorgy RethyFile Added: STF_solution_CR2137.doc
17-10-2007 18:41Gyorgy RethyFile Deleted: STF_solution_CR2137.doc
17-10-2007 18:44Gyorgy RethyFile Added: STF_solution_CR2137.doc
18-10-2007 12:05Ina SchieferdeckerTarget Version => Edition 3.3.1 (not yet published)
18-10-2007 16:47Gyorgy RethyFile Deleted: STF_solution_CR2137.doc
18-10-2007 19:30Gyorgy RethyNote Added: 0003697
19-10-2007 13:18Gyorgy RethyResolutionopen => fixed
19-10-2007 13:18Gyorgy RethyNote Added: 0003704
06-12-2007 16:38Gyorgy RethyNote Added: 0004393
06-12-2007 16:38Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
06-12-2007 16:38Gyorgy RethyStatusassigned => resolved
06-12-2007 18:02Ina SchieferdeckerStatusresolved => closed
06-12-2007 18:02Ina SchieferdeckerFixed in Version => Edition 3.3.1 (not yet published)
12-03-2008 10:22user10Fixed in VersionEdition 3.3.1 --will not be published, see 3.3.2 => Edition 3.3.2 (not yet published)
12-03-2008 10:24user10Target VersionEdition 3.3.1 --will not be published, see 3.3.2 => Edition 3.3.2 (not yet published)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0003697) +
+ Gyorgy Rethy    +
+ 18-10-2007 19:30    +
+ 		+ + + + +
+ STF solution of the CR is merged with the solutions of CRs 383, 424, 1451, 2141 and 2142
+
+
+
+ + + + + + + + + + +
+ (0003704) +
+ Gyorgy Rethy    +
+ 19-10-2007 13:18    +
+ 		+ + + + +
+ STF solution text is in the common file attached to CR383
+
+
+
+ + + + + + + + + + +
+ (0004393) +
+ Gyorgy Rethy    +
+ 06-12-2007 16:38    +
+ 		+ + + + +
+ Resolved together with CR424, solution is in the file attached to CR424.
+
+ + diff --git a/docs/mantis/CR2139.md b/docs/mantis/CR2139.md new file mode 100644 index 0000000000000000000000000000000000000000..62a90cdfa470de9c0c1846f3f94fc66775f12b4c --- /dev/null +++ b/docs/mantis/CR2139.md @@ -0,0 +1,100 @@ + + + + + + + + + + + + + 0002139: Forbid partial values in initializers - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0002139Part 01: TTCN-3 Core LanguageTechnicalpublic12-10-2007 16:1412-03-2008 10:27
ReporterRoland Gecse 
Assigned ToThomas Deiß 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionwon't fix 
PlatformOSOS Version
Product Versionv3.2.1 (published 2007-02) 
Target Versionv3.3.2 (published 2008-04)Fixed in Versionv3.3.2 (published 2008-04) 
Clause Reference(s)6.2, C.29
Source (company - Author)L.M.Ericsson
Summary0002139: Forbid partial values in initializers
DescriptionTTCN-3 allows for leaving certain elements of structured type values undefined at initialization. There are three cases when this can happen:
+
+1) Excluding certain elements when using the value assignment notation, e.g.:
+
+type record r { integer i optional, boolean b };
+var r v_r1 := { b := true };
+
+2) Explicitly marking the omission of some elements using the not used symbol in value assignment notation, e.g.:
+
+var r v_r2 := { a := -, b := true };
+
+3) Specifying undefined elements with the not used symbol in value list notation, e.g.:
+
+var r v_r3 := { -, true };
+
+Cases 1-3 result partial values, which are incomplete because these contain an unbound element.
+
+The recommendation is to forbid users to create partial values deliberately. Partial values should only be accepted as a consequence of some operations (e.g. indexing, assignment).
+
+Reasoning:
+
+A) De-referring a partial value is illegal and should cause error. For successful execution the missing unbound element must be set to contain some valid value anyway. The entire value content could be set at that time w/o the need of a partially pre-initialized value.
+
+B) If using partial value cannot be avoided -- with serious doubts if this could happen at all -- the user could still use assignments to set those fields, which need to have some value. E.g.:
+
+var r v_r4;
+v_r4.b := true; // partial value as consequence of assignment -> ok
+
+C) Incomplete values raise some issues related to other language constructions, such as sizeof, too. According to section C.29 the unbound value at the end of a record of/set of value does not count into the length, e.g.:
+
+type record of integer roi;
+var roi v1 := {1}, v2 := {1,-}, v3 := {1,-,-};
+
+What is the relationship between v1, v2 and v3? Are these all equal?
+Yes? Why do we have the not used symbols at the end?
+No? Don't these all have the same length and elements?
+
+I believe it would be very beneficial to cut this feature from TTCN-3 as it contributes to bad programming practices.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
12-10-2007 16:14Roland GecseNew Issue
12-10-2007 16:14Roland GecseClause Reference(s) => 6.2, C.29
12-10-2007 16:14Roland GecseSource (company - Author) => L.M.Ericsson
13-10-2007 19:03Ina SchieferdeckerStatusnew => assigned
13-10-2007 19:03Ina SchieferdeckerAssigned To => developer_u
17-10-2007 12:41user10Assigned Todeveloper_u => Thomas Deiß
18-10-2007 12:09Ina SchieferdeckerTarget Version => Edition 3.3.1 (not yet published)
03-12-2007 12:38Jens GrabowskiNote Added: 0004228
04-12-2007 16:59Thomas DeißStatusassigned => closed
04-12-2007 16:59Thomas DeißResolutionopen => won't fix
12-03-2008 10:27user10Fixed in Version => Edition 3.3.2 (not yet published)
12-03-2008 10:27user10Target VersionEdition 3.3.1 --will not be published, see 3.3.2 => Edition 3.3.2 (not yet published)
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0004228) +
+ Jens Grabowski    +
+ 03-12-2007 12:38    +
+ 		+ + + + +
+ Nothing shall change. The CR will be rejected.
+
+ + diff --git a/docs/mantis/CR2140.md b/docs/mantis/CR2140.md new file mode 100644 index 0000000000000000000000000000000000000000..61f7a302323595419404d70fc4682a7ab2087478 --- /dev/null +++ b/docs/mantis/CR2140.md @@ -0,0 +1,72 @@ + + + + + + + + + + + + + 0002140: Syntax of lengh restriction - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0002140Part 01: TTCN-3 Core LanguageTechnicalpublic12-10-2007 16:2312-12-2008 11:45
ReporterRoland Gecse 
Assigned ToThomas Deiß 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionwon't fix 
PlatformOSOS Version
Product Versionv3.2.1 (published 2007-02) 
Target Versionv3.3.2 (published 2008-04)Fixed in Version 
Clause Reference(s)6.1.2.3
Source (company - Author)L.M.Ericsson
Summary0002140: Syntax of lengh restriction
DescriptionThe syntax of length restriction deviates from the syntax of other subtype constraints, which appear in parentheses, e.g.:
+
+type integer i (0..9);
+type bitstring bs length(8);
+
+Why not have a concise and unified syntax, which would be in-line with ASN.1 subtype definitions, too? E.g.:
+
+type bitstring bs (length(8));
+
+The recommendation is to switch to the new syntax but keep the legacy notation as a deprecated feature for backward compatibility.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
12-10-2007 16:23Roland GecseNew Issue
12-10-2007 16:23Roland GecseClause Reference(s) => 6.1.2.3
12-10-2007 16:23Roland GecseSource (company - Author) => L.M.Ericsson
13-10-2007 19:01Ina SchieferdeckerStatusnew => assigned
13-10-2007 19:01Ina SchieferdeckerAssigned To => developer_u
17-10-2007 12:41user10Assigned Todeveloper_u => Thomas Deiß
17-10-2007 14:27Ina SchieferdeckerStatusassigned => closed
17-10-2007 14:27Ina SchieferdeckerNote Added: 0003665
17-10-2007 14:27Ina SchieferdeckerResolutionopen => fixed
18-10-2007 12:24Ina SchieferdeckerStatusclosed => feedback
18-10-2007 12:24Ina SchieferdeckerResolutionfixed => reopened
18-10-2007 12:24Ina SchieferdeckerStatusfeedback => closed
18-10-2007 12:24Ina SchieferdeckerResolutionreopened => won't fix
12-12-2008 11:45Ina SchieferdeckerTarget Version => Edition 3.3.2
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0003665) +
+ Ina Schieferdecker    +
+ 17-10-2007 14:27    +
+ 		+ + + + +
+ This is a small issue only - anyhow, length restrictions are specific in a language (i.e. IDL, ASN.1 and TTCN-3 use all different syntaxes) - changing the syntax would break existing test suites - having the parenthesis an optional syntax complicates the language unnecessarily - so it is closed
+
+ + diff --git a/docs/mantis/CR2141.md b/docs/mantis/CR2141.md new file mode 100644 index 0000000000000000000000000000000000000000..6ab2a110280d430eb2f97eab7750945154cd1985 --- /dev/null +++ b/docs/mantis/CR2141.md @@ -0,0 +1,106 @@ + + + + + + + + + + + + + 0002141: Why having both lengthof and sizeof? - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0002141Part 01: TTCN-3 Core LanguageTechnicalpublic12-10-2007 18:5312-03-2008 10:24
ReporterRoland Gecse 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.2.1 (published 2007-02) 
Target Versionv3.3.2 (published 2008-04)Fixed in Versionv3.3.2 (published 2008-04) 
Clause Reference(s)C.28, C.29
Source (company - Author)L.M.Ericsson
Summary0002141: Why having both lengthof and sizeof?
DescriptionThe semantics of predefined function lengthof could be extended to cover arguments of sizeof (i.e. support array/record [of]/set [of] in addition to *string types).
+
+Interesting:
+sizeof is the name of the predefined function getting the length,
+length is the name of the sub-type constraint restricting the length,
+lengthof cannot be used to get the length of a structured type value.
+
+The solution should keep sizeof as a deprecated function for compatibility.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0004848closed Ina Schieferdecker No record of, set of and arrays are supported by sizeof 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
12-10-2007 18:53Roland GecseNew Issue
12-10-2007 18:53Roland GecseClause Reference(s) => C.28, C.29
12-10-2007 18:53Roland GecseSource (company - Author) => L.M.Ericsson
13-10-2007 19:00Ina SchieferdeckerStatusnew => assigned
13-10-2007 19:00Ina SchieferdeckerAssigned To => developer_u
15-10-2007 16:02Ina SchieferdeckerNote Added: 0003620
17-10-2007 12:41user10Assigned Todeveloper_u => Thomas Deiß
18-10-2007 12:14Ina SchieferdeckerTarget Version => Edition 3.3.1 (not yet published)
19-10-2007 13:19Gyorgy RethyResolutionopen => fixed
19-10-2007 13:19Gyorgy RethyNote Added: 0003705
03-12-2007 12:08Jens GrabowskiAssigned ToThomas Deiß => Ina Schieferdecker
04-12-2007 16:40Ina SchieferdeckerStatusassigned => resolved
06-12-2007 18:02Ina SchieferdeckerStatusresolved => closed
06-12-2007 18:02Ina SchieferdeckerFixed in Version => Edition 3.3.1 (not yet published)
12-03-2008 10:22user10Fixed in VersionEdition 3.3.1 --will not be published, see 3.3.2 => Edition 3.3.2 (not yet published)
12-03-2008 10:24user10Target VersionEdition 3.3.1 --will not be published, see 3.3.2 => Edition 3.3.2 (not yet published)
13-02-2009 10:14Ina SchieferdeckerRelationship addedrelated to 0004848
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0003620) +
+ Ina Schieferdecker    +
+ 15-10-2007 16:02    +
+ 		+ + + + +
+ enable lengthof for all sequence like types
+
+deprecate sizeof
+
+
+
+ + + + + + + + + + +
+ (0003705) +
+ Gyorgy Rethy    +
+ 19-10-2007 13:19    +
+ 		+ + + + +
+ STF solution text is in the common file attached to CR383
+
+ + diff --git a/docs/mantis/CR2142.md b/docs/mantis/CR2142.md new file mode 100644 index 0000000000000000000000000000000000000000..e51660739671bad1a3e9276e6150a0811701ec9a --- /dev/null +++ b/docs/mantis/CR2142.md @@ -0,0 +1,134 @@ + + + + + + + + + + + + + 0002142: Better support for set of/record of values - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0002142Part 01: TTCN-3 Core LanguageNew Featurepublic12-10-2007 19:1012-03-2008 10:24
ReporterRoland Gecse 
Assigned ToIna Schieferdecker 
PrioritynormalSeveritymajorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.2.1 (published 2007-02) 
Target Versionv3.3.2 (published 2008-04)Fixed in Versionv3.3.2 (published 2008-04) 
Clause Reference(s)7.1.2, 7.1.7, C.34, C.35
Source (company - Author)L.M.Ericsson
Summary0002142: Better support for set of/record of values
DescriptionTTCN-3 has weak support for set of/record of values. It should be possible to manipulate (insert, remove, append, replace etc.) contents of these values.
+
+The proposal is thus (1) to extend functionality of concatenation and rotate operators to allow for set of/record of type operands and (2) extend the scope of substr and replace predefined functions to cope with these kinds of parameters.
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
12-10-2007 19:10Roland GecseNew Issue
12-10-2007 19:10Roland GecseClause Reference(s) => 7.1.2, 7.1.7, C.34, C.35
12-10-2007 19:10Roland GecseSource (company - Author) => L.M.Ericsson
13-10-2007 18:44Ina SchieferdeckerStatusnew => assigned
13-10-2007 18:44Ina SchieferdeckerAssigned To => Jens Grabowski
15-10-2007 16:13Ina SchieferdeckerNote Added: 0003621
15-10-2007 16:14Ina SchieferdeckerAssigned ToJens Grabowski => developer_u
17-10-2007 12:41user10Assigned Todeveloper_u => Thomas Deiß
18-10-2007 12:15Ina SchieferdeckerTarget Version => Edition 3.3.1 (not yet published)
31-10-2007 16:15Thomas DeißNote Added: 0003852
31-10-2007 16:15Thomas DeißAssigned ToThomas Deiß => Gyorgy Rethy
31-10-2007 16:15Thomas DeißResolutionopen => fixed
06-12-2007 16:42Gyorgy RethyNote Added: 0004394
06-12-2007 16:42Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
06-12-2007 16:42Gyorgy RethyStatusassigned => resolved
06-12-2007 18:03Ina SchieferdeckerStatusresolved => closed
06-12-2007 18:03Ina SchieferdeckerFixed in Version => Edition 3.3.1 (not yet published)
12-03-2008 10:22user10Fixed in VersionEdition 3.3.1 --will not be published, see 3.3.2 => Edition 3.3.2 (not yet published)
12-03-2008 10:24user10Target VersionEdition 3.3.1 --will not be published, see 3.3.2 => Edition 3.3.2 (not yet published)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0003621) +
+ Ina Schieferdecker    +
+ 15-10-2007 16:13    +
+ 		+ + + + +
+ should be considered together with CR 424
+
+
+
+ + + + + + + + + + +
+ (0003852) +
+ Thomas Deiß    +
+ 31-10-2007 16:15    +
+ 		+ + + + +
+ STF solution text is in the common file attached to CR383
+
+
+
+ + + + + + + + + + +
+ (0004394) +
+ Gyorgy Rethy    +
+ 06-12-2007 16:42    +
+ 		+ + + + +
+ Resolved together with CR424, solution is in the file attached to CR424. Other operators that included into the solution shall be requested in a separate CR with a detailed description.
+
+ + diff --git a/docs/mantis/CR2143.md b/docs/mantis/CR2143.md new file mode 100644 index 0000000000000000000000000000000000000000..f2a15371791128be8f3d1551ffb125162572b04e --- /dev/null +++ b/docs/mantis/CR2143.md @@ -0,0 +1,237 @@ + + + + + + + + + + + + + 0002143: Invoke test cases from/on test components - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0002143Part 01: TTCN-3 Core LanguageNew Featurepublic13-10-2007 19:4216-02-2010 14:20
ReporterIna Schieferdecker 
Assigned ToJens Grabowski 
PrioritynormalSeverityfeatureReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.2.1 (published 2010-07)Fixed in Version 
Clause Reference(s)Part 1
Source (company - Author)FOKUS
Summary0002143: Invoke test cases from/on test components
DescriptionSo far, TTCN-3 allows to start test cases only from the control part with the execute statement ... that execute statement has the semantics to create the MTC and to start the test case on the MTC.
+
+There is no reason, why a test component (MTC or PTC) shouldn't be able to invoke (i.e. call) the test cases like any other function - if the runs on type of the test case is compatible to the test component type and if the system type test component is compatible to the current system test component type.
+
+The same can be allowed for starting the test case on a test component - provided that the compatible rules hold.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0000413closed Jens Grabowski Static test configurations 
Attached Filesppt CR-2143-Calling-Test-Cases-From-Within-Test-Cases.ppt (86,528) 11-08-2008 14:10
http://oldforge.etsi.org/mantis/file_download.php?file_id=1587&type=bug
ppt CR2143_InvokingTestcases.ppt (26,624) 14-08-2008 06:21
http://oldforge.etsi.org/mantis/file_download.php?file_id=1595&type=bug
Issue History
Date ModifiedUsernameFieldChange
13-10-2007 19:42Ina SchieferdeckerNew Issue
13-10-2007 19:42Ina SchieferdeckerStatusnew => assigned
13-10-2007 19:42Ina SchieferdeckerAssigned To => Jens Grabowski
13-10-2007 19:42Ina SchieferdeckerClause Reference(s) => Part 1
13-10-2007 19:42Ina SchieferdeckerSource (company - Author) => FOKUS
15-10-2007 17:42Ina SchieferdeckerNote Added: 0003629
18-10-2007 13:46Ina SchieferdeckerProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
18-10-2007 14:02Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
27-03-2008 08:24Thomas DeißNote Added: 0005312
11-08-2008 14:10Jens GrabowskiFile Added: CR-2143-Calling-Test-Cases-From-Within-Test-Cases.ppt
11-08-2008 14:10Jens GrabowskiNote Added: 0006487
14-08-2008 06:21Ina SchieferdeckerFile Added: CR2143_InvokingTestcases.ppt
12-12-2008 09:26Ina SchieferdeckerRelationship addedrelated to 0000413
12-12-2008 09:26Ina SchieferdeckerNote Added: 0007670
12-12-2008 09:26Ina SchieferdeckerTarget VersionEdition 4.1.1 (not yet published) => Edition 4.2.1 (not yet published)
16-02-2010 14:19Jens GrabowskiNote Added: 0009213
16-02-2010 14:20Jens GrabowskiStatusassigned => closed
16-02-2010 14:20Jens GrabowskiNote Added: 0009214
16-02-2010 14:20Jens GrabowskiResolutionopen => fixed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0003629) +
+ Ina Schieferdecker    +
+ 15-10-2007 17:42    +
+ 		+ + + + +
+ to be considered more generally: parallel test cases, test case hierarchies, etc. - to be considered therefore in 2008
+
+
+
+ + + + + + + + + + +
+ (0005312) +
+ Thomas Deiß    +
+ 27-03-2008 08:24    +
+ 		+ + + + +
+ This should include cases, where one test case is started and continues to execute and other test cases ares started and stopped independently.
+
+
+
+ + + + + + + + + + +
+ (0006487) +
+ Jens Grabowski    +
+ 11-08-2008 14:10    +
+ 		+ + + + +
+ Uploaded slides discussing some issues related to this CR.
+
+
+
+ + + + + + + + + + +
+ (0007670) +
+ Ina Schieferdecker    +
+ 12-12-2008 09:26    +
+ 		+ + + + +
+ To be discussed once the deployment and configuration package has been defined.
+
+
+
+ + + + + + + + + + +
+ (0009213) +
+ Jens Grabowski    +
+ 16-02-2010 14:19    +
+ 		+ + + + +
+ (Partially) resolved by means of static test configurations. Issue is closed.
+
+
+
+ + + + + + + + + + +
+ (0009214) +
+ Jens Grabowski    +
+ 16-02-2010 14:20    +
+ 		+ + + + +
+ See last note!
+
+ + diff --git a/docs/mantis/CR2144.md b/docs/mantis/CR2144.md new file mode 100644 index 0000000000000000000000000000000000000000..5c8544567cf2cb59499ace05c28bf389554dc01a --- /dev/null +++ b/docs/mantis/CR2144.md @@ -0,0 +1,243 @@ + + + + + + + + + + + + + 0002144: TTCN-3 reserved words used in other languages - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0002144Part 09: Using XML with TTCN-3Technicalpublic15-10-2007 10:3520-04-2009 12:20
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)Parts 7,8,9,11
For STF discussion
Source (company - Author)L.M. Ericsson
Summary0002144: TTCN-3 reserved words used in other languages
DescriptionWhen mapping ASN.1/IDL/XSD etc. to TTCN-3 it often happens that TTCN-3 reserved words (keywords+predefined function&type names) are used in the other language as identifier. Today this situation is not handled in the mapping parts of the TTCN-3 standard.
+
Steps To Reproduce
Additional InformationThere are at least two options to solve this problem:
+- specify standard pre/post-fixes for TTCN-3 reserved words: simple solution but when adding new reserved words to the language elder TTCN-3 modules shall be also updated;
+- allow using TTCN-3 keywords as identifiers (still, predefined function&type names could be used as identifiers with limitation): modern tools are able to distinguish the role of a word based on the context.
TagsNo tags attached.
Relationships
Attached Filesdoc CR2144 - Resolution for Part-9.doc (84,992) 22-04-2008 11:42
http://oldforge.etsi.org/mantis/file_download.php?file_id=1427&type=bug
doc CR2144 - Resolution for Part-9 v2.doc (115,712) 21-10-2008 18:28
http://oldforge.etsi.org/mantis/file_download.php?file_id=1716&type=bug
Issue History
Date ModifiedUsernameFieldChange
15-10-2007 10:35Gyorgy RethyNew Issue
15-10-2007 10:35Gyorgy RethyStatusnew => assigned
15-10-2007 10:35Gyorgy RethyAssigned To => Gyorgy Rethy
15-10-2007 10:35Gyorgy RethyClause Reference(s) => Parts 7,8,9,11
15-10-2007 10:35Gyorgy RethySource (company - Author) => L.M. Ericsson
15-10-2007 17:44Ina SchieferdeckerAssigned ToGyorgy Rethy => Jens Grabowski
18-10-2007 13:46Ina SchieferdeckerProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
18-10-2007 14:01Ina SchieferdeckerTarget Version => Edition 3.3.1 (not yet published)
03-12-2007 13:46Jens GrabowskiProjectPart 01: TTCN-3 Core Language => Part 07: Using ASN.1 with TTCN-3
03-12-2007 13:47Jens GrabowskiNote Added: 0004229
03-12-2007 13:48Jens GrabowskiAssigned ToJens Grabowski => Gyorgy Rethy
03-12-2007 13:48Jens GrabowskiTarget VersionEdition 3.3.1 (not yet published) =>
10-03-2008 14:31Thomas DeißNote Added: 0005184
12-03-2008 14:55Ina SchieferdeckerAssigned ToGyorgy Rethy => Ina Schieferdecker
12-03-2008 15:00Ina SchieferdeckerNote Added: 0005213
21-04-2008 08:52Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
22-04-2008 11:41Gyorgy RethyNote Added: 0005491
22-04-2008 11:42Gyorgy RethyFile Added: CR2144 - Resolution for Part-9.doc
13-10-2008 14:45Gyorgy RethyNote Added: 0007042
21-10-2008 15:02Gyorgy RethyNote Deleted: 0007042
21-10-2008 18:28Gyorgy RethyFile Added: CR2144 - Resolution for Part-9 v2.doc
21-10-2008 18:30Gyorgy RethyNote Added: 0007140
21-10-2008 18:33Gyorgy RethyNote Edited: 0007140
28-11-2008 12:40Ina SchieferdeckerProjectPart 07: Using ASN.1 with TTCN-3 => ETSI Plugtest Test Reporting Tool
28-11-2008 13:27Ina SchieferdeckerNote Added: 0007503
28-11-2008 14:31user10ProjectETSI Plugtest Test Reporting Tool => Part 09: Using XML with TTCN-3
12-12-2008 09:47Ina SchieferdeckerAssigned ToIna Schieferdecker => Gyorgy Rethy
20-04-2009 12:20Ina SchieferdeckerStatusassigned => closed
20-04-2009 12:20Ina SchieferdeckerResolutionopen => fixed
20-04-2009 12:20Ina SchieferdeckerFixed in Version => Edition 4.1.1 (not yet published)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0004229) +
+ Jens Grabowski    +
+ 03-12-2007 13:47    +
+ 		+ + + + +
+ Is only an issue for the ASN.1 mapping as the IDL and the XSD mappings define rules for this. CR is moved to Part 7.
+
+
+
+ + + + + + + + + + +
+ (0005184) +
+ Thomas Deiß    +
+ 10-03-2008 14:31    +
+ 		+ + + + +
+ STF 349: Has been resolved in ASN.1, part 7 edition 3.3.1.
+clause 8.2: When TTCN-3 keywords are used as identifiers in ASN.1 modules, these identifiers shall be appended with a single underscore "_" character at import.
+
+Use the same solution for all language mappings.
+
+
+
+ + + + + + + + + + +
+ (0005213) +
+ Ina Schieferdecker    +
+ 12-03-2008 15:00    +
+ 		+ + + + +
+ Fixed in part 8, edition 3.3.1.
+
+Awaiting draft for part 9 to check it as well.
+
+
+
+ + + + + + + + + + +
+ (0005491) +
+ Gyorgy Rethy    +
+ 22-04-2008 11:41    +
+ 		+ + + + +
+ pls. see the uploaded doc for my proposal. Unfortunately, I missed to add it to v3.3.1. Nevertheless, this is not a backward-compatibility issue, as names that would result in TTCN-3 reserved words shall be renamed in XSD with v3.3.1
+
+
+
+ + + + + + + + + + +
+ (0007140) +
+ Gyorgy Rethy    +
+ 21-10-2008 18:30    +
(edited on: 21-10-2008 18:33)
+ 		+ + + + +
+ Version 2 of the proposed solution for Part-9 is uploaded. We should move this CR to Part-9 that people searching for Part-9 CRs also could see this one.
+
+
+
+
+
+ + + + + + + + + + +
+ (0007503) +
+ Ina Schieferdecker    +
+ 28-11-2008 13:27    +
+ 		+ + + + +
+ The rules seem to be ok except of that name clashes should be resolved with respect to a given scope only.
+
+ + diff --git a/docs/mantis/CR2146.md b/docs/mantis/CR2146.md new file mode 100644 index 0000000000000000000000000000000000000000..296405f791d1c301f5a533832a988ced4ad2a87a --- /dev/null +++ b/docs/mantis/CR2146.md @@ -0,0 +1,234 @@ + + + + + + + + + + + + + 0002146: XML schema for TLI is too strict - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0002146Part 06: TTCN-3 Control InterfaceTechnicalpublic15-10-2007 12:1206-12-2007 11:08
ReporterPavel Yakovenko 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv3.3.1 (published 2008-04)Fixed in Versionv3.3.1 (published 2008-04) 
Clause Reference(s)TCI, clause 10, W3C XML Mapping
Source (company - Author)ISPRAS, Pavel Yakovenko
Summary0002146: XML schema for TLI is too strict
DescriptionFew issues have been discovered in the XML schema for TLI->XML mapping. Some of them look like typos while others do not allow to create XML documents from good test suite executions that may be successfully validated against schema.
+
+Brief description of the discovered issues:
+
+1) Value, EnumeratedValue and UnionValue value lack "minOccurs" attribute. This is critical since instances of corresponding Template type definitions (i.e. instances of TciValueTemplate, EnumeratedTemplate and UnionTemplate) MUST have elements defined in the base type (i.e. values). In other words instance of UnionTemplate must have two elements - one from UnionValue type and one from UnionTemplate. Omitting UnionValue element gives invalid document.
+
+2) Some elements in the events (mostly communication events) lack minOccurs attribute while data may not be provided for these elements. The typical example is the mandatory returnValue element in procedure reply events. If signature doesn't return value then there is no way to create valid document. The alternative solution would be to add "null" element to Value and Template type definitions and use it in such cases.
+
+3) tliPrGetCall_c event (and only it) has mandatory "signatureTmpl" element. It should be either optional or removed at all.
+
+4) tliMReceive_c event (and only it) has "fromComp" element while all other events use "from" element for information about sender. Looks like a typo.
+
+5) TciValueTemplate complex type lacks "verdicttype" element although there exists "VerdictTemplate" type definition. Looks like a typo.
+
+6) RecordOf and SetOf complex types (and only them) lack "verdicttype" element. Looks like a typo.
+
+7) UnionValue, AnytypeValue and AddressValue (and only them) do not have "omit" and "null" elements. Without "omit" it's not possible to represent optional (and omitted) fields of above mentioned types nested within record or set type.
+
Steps To Reproduce
Additional InformationIn the attachment you may find ZIP archieve with fixed xsd files. All changes are marked with comments starting with YAK word and each comment gives short description of what has been changed.
+
TagsNo tags attached.
Relationships
Attached Files? XSD_fixed.zip (8,785) 15-10-2007 12:12
http://oldforge.etsi.org/mantis/file_download.php?file_id=1031&type=bug
zip es_20187306v030301_CR2146.zip (1,173,921) 04-12-2007 14:32
http://oldforge.etsi.org/mantis/file_download.php?file_id=1191&type=bug
zip es_20187306v030301_CR2146_a.zip (984,176) 05-12-2007 15:44
http://oldforge.etsi.org/mantis/file_download.php?file_id=1219&type=bug
Issue History
Date ModifiedUsernameFieldChange
15-10-2007 12:12Pavel YakovenkoNew Issue
15-10-2007 12:12Pavel YakovenkoStatusnew => assigned
15-10-2007 12:12Pavel YakovenkoAssigned To => Gyorgy Rethy
15-10-2007 12:12Pavel YakovenkoFile Added: XSD_fixed.zip
15-10-2007 12:12Pavel YakovenkoClause Reference(s) => TCI, clause 10, W3C XML Mapping
15-10-2007 12:12Pavel YakovenkoSource (company - Author) => ISPRAS, Pavel Yakovenko
15-10-2007 17:53Ina SchieferdeckerAssigned ToGyorgy Rethy => Ina Schieferdecker
18-10-2007 13:53Ina SchieferdeckerProjectTTCN-3 Change Requests => Part 06: TTCN-3 Control Interface
18-10-2007 13:54Ina SchieferdeckerTarget Version => Edition 3.3.1 (not yet published)
04-12-2007 14:31Ina SchieferdeckerNote Added: 0004262
04-12-2007 14:32Ina SchieferdeckerFile Added: es_20187306v030301_CR2146.zip
04-12-2007 14:32Ina SchieferdeckerNote Added: 0004264
04-12-2007 14:33Ina SchieferdeckerResolutionopen => fixed
04-12-2007 16:38Ina SchieferdeckerAssigned ToIna Schieferdecker => Thomas Deiß
05-12-2007 15:44Thomas DeißFile Added: es_20187306v030301_CR2146_a.zip
05-12-2007 15:54Thomas DeißNote Added: 0004339
05-12-2007 15:55Thomas DeißNote Added: 0004340
05-12-2007 15:55Thomas DeißAssigned ToThomas Deiß => Ina Schieferdecker
05-12-2007 16:26Ina SchieferdeckerNote Added: 0004345
05-12-2007 16:26Ina SchieferdeckerStatusassigned => resolved
06-12-2007 11:08Ina SchieferdeckerStatusresolved => closed
06-12-2007 11:08Ina SchieferdeckerFixed in Version => Edition 3.3.1 (not yet published)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0004262) +
+ Ina Schieferdecker    +
+ 04-12-2007 14:31    +
+ 		+ + + + +
+ Thank you for the proposals!
+
+1) is solved a bit differently: the cardinalities are defined directly for the TciValueTemplates, EnumeratedTemplates, etc., i.e. not in the values
+
+2) all tciPars, parsTmpl, and triPars set optional
+   all replValue, replTmpl, and repl set optional
+   all address and addressTmpl set optional
+   all excValue and excTmpl set optional
+
+3) this is a left-over and should be removed
+
+4) this is a left-over and now renamed to from
+
+5) ok
+
+6) ok
+
+7) ok
+
+
+
+ + + + + + + + + + +
+ (0004264) +
+ Ina Schieferdecker    +
+ 04-12-2007 14:32    +
+ 		+ + + + +
+ The resolution is using already the updated text from CR2000
+
+
+
+ + + + + + + + + + +
+ (0004339) +
+ Thomas Deiß    +
+ 05-12-2007 15:54    +
+ 		+ + + + +
+ Some of the problems, especially optionality of returnValues in replies, shows up in the C-mapping. Separate CR to be written.
+
+
+
+ + + + + + + + + + +
+ (0004340) +
+ Thomas Deiß    +
+ 05-12-2007 15:55    +
+ 		+ + + + +
+ checked by Thomas. All issues raised by Pavel solved. A few more found when checking the solution.
+
+
+
+ + + + + + + + + + +
+ (0004345) +
+ Ina Schieferdecker    +
+ 05-12-2007 16:26    +
+ 		+ + + + +
+ es_20187306v030301_CR2146_a.zip adds the verdicttype to the record, record of, set, set of, union and anytype templates and corrects two typos.
+
+ + diff --git a/docs/mantis/CR2147.md b/docs/mantis/CR2147.md new file mode 100644 index 0000000000000000000000000000000000000000..ff337ef3d523bd327fd99b7d06d21a15c9dc5bd6 --- /dev/null +++ b/docs/mantis/CR2147.md @@ -0,0 +1,324 @@ + + + + + + + + + + + + + 0002147: Implicit omit in templates - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0002147Part 01: TTCN-3 Core LanguageNew Featurepublic15-10-2007 12:1925-04-2008 11:14
ReporterGyorgy Rethy 
Assigned ToIna Schieferdecker 
PriorityurgentSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv3.4.1 (published 2008-09)Fixed in Versionv3.4.1 (published 2008-09) 
Clause Reference(s)$15
Source (company - Author)3GPP (CR provided by Gyorgy Rethy)
Summary0002147: Implicit omit in templates
DescriptionThe common way for conformance tests is to freeze test cases after their approval, i.e. an approved test case can be modified due to change request only. On the other hand there is the need to enhance existing (ASN.1) definitions to introduce and support new features:
+• Configuration primitives are upgraded by adding new - optional – fields:
+The optional fields are used in new implementations, existing implementations are kept unchanged
+• In the core spec definitions there are dummy fields as placeholders for downward compatibility only. These don’t have any meaning for a test case and therefore are normally skipped to improve readability.
+Due to the process of formal agreement and approval there is no chance to forget optional fields unintentionally.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc cr_2147_implicit_omit_solution_01.doc (225,280) 12-03-2008 11:09
http://oldforge.etsi.org/mantis/file_download.php?file_id=1369&type=bug
doc cr_2147_implicit_omit_solution_02.doc (258,560) 23-04-2008 10:07
http://oldforge.etsi.org/mantis/file_download.php?file_id=1438&type=bug
doc cr_2147_implicit_omit_solution_03.doc (267,776) 23-04-2008 11:05
http://oldforge.etsi.org/mantis/file_download.php?file_id=1439&type=bug
doc cr_2147_implicit_omit_solution_04.doc (268,288) 23-04-2008 19:43
http://oldforge.etsi.org/mantis/file_download.php?file_id=1450&type=bug
doc cr_2147_implicit_omit_solution_05.doc (268,288) 25-04-2008 11:14
http://oldforge.etsi.org/mantis/file_download.php?file_id=1457&type=bug
Issue History
Date ModifiedUsernameFieldChange
15-10-2007 12:19Gyorgy RethyNew Issue
15-10-2007 12:19Gyorgy RethyStatusnew => assigned
15-10-2007 12:19Gyorgy RethyAssigned To => Gyorgy Rethy
15-10-2007 12:19Gyorgy RethyClause Reference(s) => $15
15-10-2007 12:19Gyorgy RethySource (company - Author) => 3GPP (CR provided by Gyorgy Rethy)
15-10-2007 18:18Ina SchieferdeckerNote Added: 0003630
15-10-2007 18:29Ina SchieferdeckerNote Edited: 0003630
18-10-2007 13:46Ina SchieferdeckerProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
18-10-2007 14:01Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
07-12-2007 11:36Ina SchieferdeckerPrioritynormal => urgent
10-03-2008 13:28Thomas DeißNote Added: 0005183
12-03-2008 11:09Thomas DeißFile Added: cr_2147_implicit_omit_solution_01.doc
12-03-2008 11:16Thomas DeißNote Added: 0005206
26-03-2008 14:11user324Note Added: 0005309
21-04-2008 08:49Ina SchieferdeckerTarget VersionEdition 4.1.1 (not yet published) => Edition 3.4.1 (not yet published)
23-04-2008 10:07Gyorgy RethyNote Added: 0005511
23-04-2008 10:07Gyorgy RethyAssigned ToGyorgy Rethy => Thomas Deiß
23-04-2008 10:07Gyorgy RethyFile Added: cr_2147_implicit_omit_solution_02.doc
23-04-2008 11:05Thomas DeißFile Added: cr_2147_implicit_omit_solution_03.doc
23-04-2008 11:05Thomas DeißNote Added: 0005513
23-04-2008 14:59Thomas DeißNote Added: 0005519
23-04-2008 14:59Thomas DeißAssigned ToThomas Deiß => Ina Schieferdecker
23-04-2008 18:58Ina SchieferdeckerAssigned ToIna Schieferdecker => Gyorgy Rethy
23-04-2008 19:43Gyorgy RethyFile Added: cr_2147_implicit_omit_solution_04.doc
23-04-2008 19:45Gyorgy RethyNote Added: 0005544
23-04-2008 19:45Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
25-04-2008 11:14Ina SchieferdeckerFile Added: cr_2147_implicit_omit_solution_05.doc
25-04-2008 11:14Ina SchieferdeckerStatusassigned => closed
25-04-2008 11:14Ina SchieferdeckerResolutionopen => fixed
25-04-2008 11:14Ina SchieferdeckerFixed in Version => Edition 3.4.1 (not yet published)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0003630) +
+ Ina Schieferdecker    +
+ 15-10-2007 18:18    +
(edited on: 15-10-2007 18:29)
+ 		+ + + + +
+ Options
+
+1. work around with base templates
+
+2. implicit omit for ASN.1 templates and for ASN.1 types
+
+3. implicit omit for all TTCN-3 templates
+
+4. default values for TTCN-3 types (and fields) - which can be used then to set omit explicitly
+
+5. an additional template attribute, which indicates the implicit omit
+
+
+
+
+
+ + + + + + + + + + +
+ (0005183) +
+ Thomas Deiß    +
+ 10-03-2008 13:28    +
+ 		+ + + + +
+ STF 349: Solution will be provided along option 5.
+
+
+
+ + + + + + + + + + +
+ (0005206) +
+ Thomas Deiß    +
+ 12-03-2008 11:16    +
+ 		+ + + + +
+ STF 349, Thomas, solution proposal, to be discussed.
+Based on a new attribute 'optional' with two predefined values. Providing the attribute to a template will implicitly set optional fields to omit in the definition of the template. Setting the fields to omit is _not_ postponed to encoding a template before sending.
+Can be applied to templates and values.
+Cannot be applied to types, no introduction of default values.
+
+
+
+ + + + + + + + + + +
+ (0005309) +
+ user324    +
+ 26-03-2008 14:11    +
+ 		+ + + + +
+ Why is it explicitly forbidden to add the optional attribute to a type?
+
+If this were possible (with the meaning that all templates/values of that type that do not explicitly override that attribute inherit it from its type) would make the feature usable, as then all instances of that type (i.e. also variables) could profit from that attribute declaration, while with the current proposal, you may have a lot of unnecessary optional attribute declarations and you cannot add such declarations to variables (as far as I know)
+
+
+
+ + + + + + + + + + +
+ (0005511) +
+ Gyorgy Rethy    +
+ 23-04-2008 10:07    +
+ 		+ + + + +
+ In cr_2147_implicit_omit_solution_02.doc: clauses 10 (constants) and 15 (templates) are added and edited to allow implicit initialization of these language elements. Text in new clause 27.7 is edited to allow the optional attribute to modules and groups containing types (shall have no effect on types). Variables are removed for clause 27.7 as while constants, modulepars and templates definitions shall be complete, this can be checked compile time; there is no chance for that for variables. In case of templates, there still may be a problem if the user thinks he/she is working in an explicit omit environment but in fact there is an implicit omit attribute somewhere; he/she may write incomplete templates intentionally and completing them in modified templates; in this case missing fields may not be discovered
+
+
+
+ + + + + + + + + + +
+ (0005513) +
+ Thomas Deiß    +
+ 23-04-2008 11:05    +
+ 		+ + + + +
+ Feedback by Gyorgy crosschecked: Ok.
+Same note as for constants and templates also added to modulepar.
+
+
+
+ + + + + + + + + + +
+ (0005519) +
+ Thomas Deiß    +
+ 23-04-2008 14:59    +
+ 		+ + + + +
+ As discussed today morning: Implicit omit not applicable to types, awaiting CR for default values.
+
+
+
+
+ + + + + + + + + + +
+ (0005544) +
+ Gyorgy Rethy    +
+ 23-04-2008 19:45    +
+ 		+ + + + +
+ optional attribute is removed for imports, e.g. if assigned to a module it will have no effect on import statements.
+
+ + diff --git a/docs/mantis/CR2148.md b/docs/mantis/CR2148.md new file mode 100644 index 0000000000000000000000000000000000000000..d64510d53de5aea7c6e779c7b2e9b17920194ad7 --- /dev/null +++ b/docs/mantis/CR2148.md @@ -0,0 +1,352 @@ + + + + + + + + + + + + + 0002148: ASN.1 keyword DEFAULT - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 07: Using ASN.1 with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0002148Part 07: Using ASN.1 with TTCN-3New Featurepublic15-10-2007 12:3912-12-2008 11:34
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv3.3.2 (published 2008-04)Fixed in Versionv3.3.2 (published 2008-04) 
Clause Reference(s)Parts 6 & 7
Source (company - Author)3GPP (recorded by Gyorgy Rethy)
Summary0002148: ASN.1 keyword DEFAULT
DescriptionIn current test suites (TTCN-2) and the used ASN.1 codecs the test case specifies an 'OMIT' when the default value shall be applied, i.e. the IE shall not be sent at the air interface. When receiving a message the TTCN expects an OMIT instead of the default value (default value would be interpreted like a coding error).
Steps To Reproduce
Additional InformationThere is no explicit statement on DEFAULT handling in Part 7. Tools are handling ASN.1 RECORD/SET fields with DEFAULT value at least in two different ways: either like OPTINAL fields or like mandatory fields (in this case the default value is omitted in the encoded message by the codec).
+The following compromise solution is proposed:
+ Part 7 of the standard shall be updated to deal with fields using DEFAULT-s explicitly: they shall be handled at the abstract syntax level like the TTCN-2 semantics, i.e. allowing omit.
+ However, there is still a slight difference to OPTIONAL fields. In case of fields with DEFAULT, omit and the default value until know have had the same semantic meaning. For backward compatibility reasons encoders/decoders shall support two mandatory user options: if the field is set to the default value in TTCN-3, the field is either omitted or encoded with the default value at encoding; when the field with DEFAULT is omitted in the received encoded message, the decoder shall either set it omit or set it to the default value in TTCN-3 (i.e. all three variations, the <default>, omit or <default> ifpresent template fields will be valid in TTCN-3 for the default value).
+ TCI-CD shall be amended accordingly.
+
TagsNo tags attached.
Relationships
Attached Filesdoc es_20187307v030301_v1.doc (735,744) 05-12-2007 13:36
http://oldforge.etsi.org/mantis/file_download.php?file_id=1213&type=bug
doc es_20187307v030301_v2.doc (744,960) 05-12-2007 15:16
http://oldforge.etsi.org/mantis/file_download.php?file_id=1218&type=bug
doc es_20187307v030301_v2_a.doc (757,248) 06-12-2007 10:22
http://oldforge.etsi.org/mantis/file_download.php?file_id=1230&type=bug
doc es_20187307v030301_v3.doc (765,440) 06-12-2007 13:20
http://oldforge.etsi.org/mantis/file_download.php?file_id=1237&type=bug
Issue History
Date ModifiedUsernameFieldChange
15-10-2007 12:39Gyorgy RethyNew Issue
15-10-2007 12:39Gyorgy RethyStatusnew => assigned
15-10-2007 12:39Gyorgy RethyAssigned To => Gyorgy Rethy
15-10-2007 12:39Gyorgy RethyClause Reference(s) => Parts 6 & 7
15-10-2007 12:39Gyorgy RethySource (company - Author) => 3GPP (recorded by Gyorgy Rethy)
15-10-2007 18:43Ina SchieferdeckerNote Added: 0003632
18-10-2007 13:46Ina SchieferdeckerProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
18-10-2007 14:00Ina SchieferdeckerTarget Version => Edition 3.3.1 (not yet published)
05-12-2007 13:36Gyorgy RethyFile Added: es_20187307v030301_v1.doc
05-12-2007 13:36Gyorgy RethyNote Added: 0004333
05-12-2007 13:37Gyorgy RethyNote Added: 0004334
05-12-2007 15:16Gyorgy RethyFile Added: es_20187307v030301_v2.doc
06-12-2007 10:22Thomas DeißNote Added: 0004364
06-12-2007 10:22Thomas DeißFile Added: es_20187307v030301_v2_a.doc
06-12-2007 10:23Thomas DeißStatusassigned => resolved
06-12-2007 13:19Gyorgy RethyStatusresolved => feedback
06-12-2007 13:19Gyorgy RethyResolutionopen => reopened
06-12-2007 13:19Gyorgy RethyNote Added: 0004375
06-12-2007 13:20Gyorgy RethyFile Added: es_20187307v030301_v3.doc
06-12-2007 13:21Gyorgy RethyNote Added: 0004376
06-12-2007 13:21Gyorgy RethyStatusfeedback => resolved
06-12-2007 14:29Ina SchieferdeckerStatusresolved => feedback
06-12-2007 14:29Ina SchieferdeckerNote Added: 0004378
06-12-2007 14:30Ina SchieferdeckerProjectPart 01: TTCN-3 Core Language => Part 07: Using ASN.1 with TTCN-3
06-12-2007 14:30Ina SchieferdeckerStatusfeedback => resolved
06-12-2007 14:30Ina SchieferdeckerResolutionreopened => fixed
13-12-2007 10:09Gyorgy RethyStatusresolved => feedback
13-12-2007 10:09Gyorgy RethyResolutionfixed => reopened
13-12-2007 10:09Gyorgy RethyNote Added: 0004467
13-12-2007 10:09Gyorgy RethyNote Added: 0004468
13-12-2007 10:09Gyorgy RethyStatusfeedback => closed
13-12-2007 10:09Gyorgy RethyResolutionreopened => fixed
13-12-2007 10:09Gyorgy RethyTarget VersionEdition 3.3.1 (not yet published) =>
13-12-2007 10:31Gyorgy RethyStatusclosed => feedback
13-12-2007 10:31Gyorgy RethyResolutionfixed => reopened
13-12-2007 10:31Gyorgy RethyNote Added: 0004469
13-12-2007 10:32Gyorgy RethyNote Deleted: 0004469
13-12-2007 10:32Gyorgy RethyStatusfeedback => closed
13-12-2007 10:32Gyorgy RethyResolutionreopened => fixed
12-12-2008 11:34Ina SchieferdeckerFixed in Version => Edition 3.3.2
12-12-2008 11:34Ina SchieferdeckerTarget Version => Edition 3.3.2
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0003632) +
+ Ina Schieferdecker    +
+ 15-10-2007 18:43    +
+ 		+ + + + +
+ Try to resolve it via encoding attributes - do not touch the TCI-CD interface
+
+
+
+ + + + + + + + + + +
+ (0004333) +
+ Gyorgy Rethy    +
+ 05-12-2007 13:36    +
+ 		+ + + + +
+ Part-7, aligned with Core v3.3.1, also containing resolution of this CR is uploaded for checking by STF members.
+
+
+
+ + + + + + + + + + +
+ (0004334) +
+ Gyorgy Rethy    +
+ 05-12-2007 13:37    +
+ 		+ + + + +
+ Part-7, aligned with Core v3.3.1, also containing resolution of this CR is uploaded for checking by STF members.
+
+
+
+ + + + + + + + + + +
+ (0004364) +
+ Thomas Deiß    +
+ 06-12-2007 10:22    +
+ 		+ + + + +
+ refering to solution v2:
+clause 8.2: the suffix _field is fine for fields, but reads awkward for other ASN.1 elements such as values or elements in an enumeration. As both ASN.1 identifiers as well as type references must not contain a hyphen as last character, just an underscore as suffix will be sufficient.
+
+clause 9.1.2.1: two cases separated:
+a) a synonym of the NULL type is added.
+b) the NULL type is used inside a structured type.
+Reference changed from clause 7.2 to 8.2. (To me this makes more sense).
+
+A few (3 or 4) typos have been found.
+
+Otherwise, this is ok.
+
+the version should be 3.3.1, to align it with the other parts. So v 3.2.1 will be skipped.
+
+
+
+ + + + + + + + + + +
+ (0004375) +
+ Gyorgy Rethy    +
+ 06-12-2007 13:19    +
+ 		+ + + + +
+ Additional note on how to convert ASN.1 NULL type
+
+
+
+ + + + + + + + + + +
+ (0004376) +
+ Gyorgy Rethy    +
+ 06-12-2007 13:21    +
+ 		+ + + + +
+ New version ~_v3 containing additional note on conversion of the ASN.1 NULL type. Version accepted by the STF.
+
+
+
+ + + + + + + + + + +
+ (0004378) +
+ Ina Schieferdecker    +
+ 06-12-2007 14:29    +
+ 		+ + + + +
+ The resolution is now being done in Part 7 - the CR needs to be moved to Part 7 therefore.
+
+
+
+ + + + + + + + + + +
+ (0004467) +
+ Gyorgy Rethy    +
+ 13-12-2007 10:09    +
+ 		+ + + + +
+ draft of Part-7 v3.3.1 has been sent for MTS approval
+
+
+
+ + + + + + + + + + +
+ (0004468) +
+ Gyorgy Rethy    +
+ 13-12-2007 10:09    +
+ 		+ + + + +
+ draft of Part-7 v3.3.1 has been sent for MTS approval
+
+ + diff --git a/docs/mantis/CR2150.md b/docs/mantis/CR2150.md new file mode 100644 index 0000000000000000000000000000000000000000..3420e143bb259a567d531ce25cce88205ccdd94e --- /dev/null +++ b/docs/mantis/CR2150.md @@ -0,0 +1,410 @@ + + + + + + + + + + + + + 0002150: Encoder/Decoder Access - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0002150Part 01: TTCN-3 Core LanguageNew Featurepublic15-10-2007 13:1225-04-2008 14:10
ReporterGyorgy Rethy 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv3.4.1 (published 2008-09)Fixed in Versionv3.4.1 (published 2008-09) 
Clause Reference(s)Annex C
Source (company - Author)     
Summary0002150: Encoder/Decoder Access
DescriptionAlthough this can be done by using an external function, we prefer this to be added to the TTCN3 specification as a built in function. This will provide compiler independency, reduce maintenance and reduce the number of external functions required.
+function msg_decode(in bitstring p_EncodedMsg, in anytype p_ExpectedType) return anytype
+   Parameters:
+        p_EncodedMsg: Bitstring of the message to be decoded
+        p_ExpectedType: anytype having a dummy of the expected type assigned
+   returns an anytype having the decoded message assigned
+   (alternatively the 2nd parameter may be inout)
+
+function msg_encode(in anytype p_AnyType) return bitstring
+   Parameters:
+        p_AnyType: anytype having assigned the massage to be encoded
+   returns bitstring of the encoded message
+
+Problem:
+Different compilers may handle assignments to/from anytype in mutually exclusive different ways
+
+Example:
+
+  type record MyRecordType {
+    integer Int,
+    boolean Bool
+  };
+
+  function MyTest() {
+    var bitstring var_Bitstring1 := '010101'B;
+    var bitstring var_Bitstring2;
+    var MyRecordType var_MyRecord;
+    var anytype var_Any := {MyRecordType := var_MyRecord};
+    
+    var_Any := msg_decode(var_Bitstring1, var_Any);
+    var_MyRecord := var_Any.MyRecordType;
+
+    var_Bitstring2 := msg_encode({MyRecordType := var_MyRecord});
+  }
+
Steps To Reproduce
Additional InformationAdd the predefined functions below to TTCN-3 core language.
+
+NOTE: Using bitstring type for encoded messages in 3GPP examples need clarification; all known message encodings are producing integer number of octets, in our practice never bitstring or hexstring was used to treat encoded messages.
+Simple message encoding
+msg_encode(in any type p_msg) return octetstring;
+msg_encode(in any type p_msg) return charstring;
+
+These predefined functions have one in value parameter, which shall contain the TTCN-3 value to be encoded. The encoded message is obtained in the return value of the function. This enables using this type of encoding function directly i.e. in sending operations or at the right hand side of assignments.
+
+NOTE: Some encoded messages may contain universal charstring characters; these are stored on 1 to 4 charstring positions in the encoded message (depending on universal charstring character set and encoding). It is supposed that the encoding rule allows identifying these positions (for decoding).
+Please note the following:
+ The type of the message encoding (e.g. binary, text, BER, PER etc.) is determined by the encode and variant attributes of the actual in parameter’s type; therefore in case of ASN.1 types the encode and variant attributes shall be specified in the related import statement (in each TTCN-3 module where the predefine function is used).
+
+Fast message encoding
+msg_encode(in any type p_msg, out octetstring p_encMsg);
+msg_encode(in any type p_msg, out charstring p_encMsg);
+
+These predefined functions differ from the simple encode functions in that they have two value parameters: the first is an in parameter and it shall contain the TTCN-3 value to be encoded. The encoded message is returned in the second, out parameter of the function. These functions cannot directly be used i.e. in sending operations or right hand side of assignments, but allows higher runtime performance than the simple encoding functions.
+
+NOTE: Some encoded messages may contain universal charstring characters; these are not handled separately as they also can be stored on 1 to 4 charstring positions (depending on universal charstring character set and encoding).
+Please note the following:
+ The type of the message encoding (e.g. binary, text, BER, PER etc.) is determined by the encode and variant attributes of the actual in parameter’s type; therefore in case of ASN.1 types the encode and variant attributes shall be specified in the related import statement (in each TTCN-3 module the predefine function is used).
+
+Simple message decoding
+msg_decode(in octetstring p_encMsg, in charstring p_type) return any type;
+msg_decode(in charstring p_encMsg, in charstring p_type) return any type;
+
+These predefined functions have two in value parameters: the first, p_encMsg shall be used to pass the encoded message to the function and the second, p_type denotes the type hypothesis, based on which message decoding is attempted. The decoded message is obtained in the return value of the function.
+
+NOTE: Encoded messages containing universal charstring characters shall be converted to charstring values before calling this predefined function (i.e. universal charstring characters shall be stored on 1 to 4 charstring-s); it is supposed that the encoding rule allows identifying positions of universal charstring characters during decoding.
+Please note the following:
+ The type of the message decoding (e.g. binary, text, BER, PER etc.) is determined by the encode and variant attributes of the type denoted by p_type; therefore in case of ASN.1 types the encode and variant attributes shall be specified in the related import statement (in each TTCN-3 module the predefine function is used).
+ Message decoding failure results dynamic test case error (i.e. the REAL type of the message MUST be know apriori and p_encMsg MUST contain exactly one complete message).
+
+Fast message decoding
+msg_decode(in octetstring p_encMsg, out any type p_msg, in charstring p_type)
+                                 return integer;
+msg_decode(in charstring p_encMsg, out any type p_msg, in charstring p_type)
+                                 return integer;
+
+These predefined functions differ from simple decoding functions in that they have three value parameters and an integer return value. The first parameter, in parameter p_encMsg, shall be used to pass the encoded message to the function. The TTCN-3 value representing the decoded message is returned in second, out parameter p_msg. The third, in parameter p_type, denotes the type hypothesis, based on which message decoding is attempted. The returned integer value contains the result of the decoding as:
+• 0 (OK). Decoding was successful; the result is stored in the out parameter.
+• 1 (NOT_MY_TYPE). Decoding was unsuccessful because the input parameter does not contain a valid message of type p_type. The content of out parameter is undefined.
+NOTE: The error code is returned as an integer value for forward compatibility: it allows extending the list of error symptoms in the future. This is also aligns the return value type with the sliding message decoding predefined functions.
+
+NOTE: Encoded messages containing universal charstring characters shall be converted to charstring before calling this predefined function (i.e. universal charstring characters shall be stored on 1 to 4 charstring-s); it is supposed that the encoding rule allows identifying positions of universal charstring characters.
+Please note the following:
+ The type of the message decoding (e.g. binary, text, BER, PER etc.) is determined by the encode and variant attributes of the type denoted by p_type; therefore in case of ASN.1 types the encode and variant attributes shall be specified in the related import statement (in each TTCN-3 module the predefine function is used).
+ Message decoding result shall always be checked, as in case of decode failure the content of p_msg is undefined and would cause dynamic test case error with high probability (or even worth, a false test result).
+
+Sliding message decoding
+msg_decode_slide(inout octetstring p_encMsg, out any type p_msg,
+                 in charstring p_type) return integer;
+msg_decode_slide (inout charstring p_encMsg, out any type p_msg
+                 in charstring p_type) return integer;
+
+These predefined functions have three value parameters. The first, inout octetstring parameter p_encMsg shall be used to pass the encoded message to the function; when the function returns, it gives back the whole, part or nothing of the octetstring value passed to it in p_encMsg (see details below). The TTCN-3 value representing the decoded message is returned in the second, out parameter p_msg. The in value parameter p_type denotes the type hypothesis, based on which message decoding is attempted. The returned integer value contains the result of the decoding as:
+• 0 (OK). Decoding was successful; the result is stored in the out parameter. The decoded message was removed from the beginning of the inout parameter p_encMsg.
+• 1 (NOT_MY_TYPE). Decoding was unsuccessful because the inout parameter p_encMsg does not contain or start with a valid message of type denoted by p_type. The inout parameter p_encMsg remains unchanged. The content of out parameter p_msg is undefined.
+• 2 (INCOMPLETE_MESSAGE). Decoding was unsuccessful because the input stream does not contain a complete message (i.e. the end of the message is missing). The inout parameter p_encMsg remains unchanged. The content of out parameter p_msg is undefined.
+
+NOTE: Encoded messages containing universal charstring characters shall be converted to charstring before calling this predefined function (i.e. universal charstring characters shall be stored on 1 to 4 charstring-s); it is supposed that the encoding rule allows identifying positions of universal charstring characters.
+Please note the following:
+ The type of the message decoding (e.g. binary, text, BER, PER etc.) is determined by the encode and variant attributes of the type denoted by p_type; therefore in case of ASN.1 types the encode and variant attributes shall be specified in the related import statement (in each TTCN-3 module the predefine function is used).
+ Message decoding result shall always be checked as in case of failure the content of p_msg is undefined and would cause dynamic test case error with high probability (or even worth, a false test result).
+
TagsNo tags attached.
Relationships
Attached Filesdoc CR_2150_solution.doc (631,808) 04-12-2007 16:22
http://oldforge.etsi.org/mantis/file_download.php?file_id=1200&type=bug
doc CR_2150_Encoder_Decoder_access_solution_01.doc (498,176) 11-03-2008 09:28
http://oldforge.etsi.org/mantis/file_download.php?file_id=1366&type=bug
doc CR_2150_Encoder_Decoder_access_solution_02.doc (501,248) 11-03-2008 17:46
http://oldforge.etsi.org/mantis/file_download.php?file_id=1368&type=bug
doc CR_2150_Encoder_Decoder_access_solution_03.doc (469,504) 23-04-2008 16:43
http://oldforge.etsi.org/mantis/file_download.php?file_id=1442&type=bug
doc CR_2150_Encoder_Decoder_access_solution_04.doc (448,512) 23-04-2008 19:26
http://oldforge.etsi.org/mantis/file_download.php?file_id=1449&type=bug
doc CR_2150_Encoder_Decoder_access_solution_05.doc (448,000) 24-04-2008 17:26
http://oldforge.etsi.org/mantis/file_download.php?file_id=1455&type=bug
Issue History
Date ModifiedUsernameFieldChange
15-10-2007 13:12Gyorgy RethyNew Issue
15-10-2007 13:12Gyorgy RethyStatusnew => assigned
15-10-2007 13:12Gyorgy RethyAssigned To => Gyorgy Rethy
15-10-2007 13:12Gyorgy RethyClause Reference(s) => Annex C
15-10-2007 13:12Gyorgy RethySource (company - Author) =>
15-10-2007 13:14Gyorgy RethyAdditional Information Updated
18-10-2007 13:46Ina SchieferdeckerProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
18-10-2007 13:59Ina SchieferdeckerTarget Version => Edition 3.3.1 (not yet published)
04-12-2007 16:22Thomas DeißFile Added: CR_2150_solution.doc
04-12-2007 16:35Thomas DeißNote Added: 0004283
07-12-2007 11:07Ina SchieferdeckerTarget VersionEdition 3.3.1 (not yet published) => Edition 4.1.1 (not yet published)
07-12-2007 11:08Ina SchieferdeckerNote Added: 0004419
11-03-2008 09:28Thomas DeißFile Added: CR_2150_Encoder_Decoder_access_solution_01.doc
11-03-2008 09:30Thomas DeißNote Added: 0005195
11-03-2008 17:46Thomas DeißFile Added: CR_2150_Encoder_Decoder_access_solution_02.doc
11-03-2008 17:51Thomas DeißNote Added: 0005203
21-04-2008 08:50Ina SchieferdeckerTarget VersionEdition 4.1.1 (not yet published) => Edition 3.4.1 (not yet published)
23-04-2008 16:42Gyorgy RethyNote Added: 0005530
23-04-2008 16:42Gyorgy RethyAssigned ToGyorgy Rethy => Thomas Deiß
23-04-2008 16:43Gyorgy RethyFile Added: CR_2150_Encoder_Decoder_access_solution_03.doc
23-04-2008 19:26Thomas DeißFile Added: CR_2150_Encoder_Decoder_access_solution_04.doc
23-04-2008 19:28Thomas DeißNote Added: 0005543
23-04-2008 19:28Thomas DeißAssigned ToThomas Deiß => Gyorgy Rethy
24-04-2008 10:22Gyorgy RethyNote Added: 0005548
24-04-2008 10:22Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
24-04-2008 17:26Thomas DeißFile Added: CR_2150_Encoder_Decoder_access_solution_05.doc
24-04-2008 17:27Thomas DeißNote Added: 0005561
25-04-2008 14:10Ina SchieferdeckerStatusassigned => closed
25-04-2008 14:10Ina SchieferdeckerResolutionopen => fixed
25-04-2008 14:10Ina SchieferdeckerFixed in Version => Edition 3.4.1 (not yet published)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0004283) +
+ Thomas Deiß    +
+ 04-12-2007 16:35    +
+ 		+ + + + +
+ encode and decode builtin functions added as wrappers for the TCI functions encode and decode. Only bitstrings used as types for encoded values (agreed in 1st STF session).
+
+
+
+ + + + + + + + + + +
+ (0004419) +
+ Ina Schieferdecker    +
+ 07-12-2007 11:08    +
+ 		+ + + + +
+ This CR is not that urgent for 3GPP - external functions can be used instead.
+
+
+
+ + + + + + + + + + +
+ (0005195) +
+ Thomas Deiß    +
+ 11-03-2008 09:30    +
+ 		+ + + + +
+ Solution proposal. Two predefined functions (names to be discussed), allow to retrieve amount of consumed bits in decoding. Otherwise close to the TCI functions encode/decode.
+
+For discussion of names: 'encode' is used already as keyword in the context of attributes. So far, the names of predefined functions have not been keywords.
+
+
+
+ + + + + + + + + + +
+ (0005203) +
+ Thomas Deiß    +
+ 11-03-2008 17:51    +
+ 		+ + + + +
+ STF349, Thomas: Solution proposal updated:
+- simple reference to TCI operations might not be sufficient, as the codecs might change throughout execution. For encode, refer to the time of executing the operation. for decode this is more problematic and not mentioned.
+- return value of decode changed be a return code instaed of the amount of bits consumed.
+- possibility that RTS might not raise an error when encoding or decoding mentioned. This is out of scope of the standard.
+
+
+
+ + + + + + + + + + +
+ (0005530) +
+ Gyorgy Rethy    +
+ 23-04-2008 16:42    +
+ 		+ + + + +
+ In file CR_2150_Encoder_Decoder_access_solution_03.doc: as we discussed, I have copied the text to the newest standard version; hence I added comments to most of my changes (except trivial editorial).
+
+
+
+ + + + + + + + + + +
+ (0005543) +
+ Thomas Deiß    +
+ 23-04-2008 19:28    +
+ 		+ + + + +
+ clean up of the editorial changes.
+Name proposal: encvalue, decvalue
+2nd parameter of decvalue changed from out to inout. Otherwise there would be a successful function call, where an out parameter is undefined afterwards.
+
+
+
+
+
+ + + + + + + + + + +
+ (0005548) +
+ Gyorgy Rethy    +
+ 24-04-2008 10:22    +
+ 		+ + + + +
+ The version 04 (provided by Thomas) is reviewed by me; it is an agreed version between me and Thomas.
+
+
+
+ + + + + + + + + + +
+ (0005561) +
+ Thomas Deiß    +
+ 24-04-2008 17:27    +
+ 		+ + + + +
+ 2nd parameter of decvalue changed to 'out' (instead 'inout').
+Definition in case of unsuccessful behaviour slightly revised.
+
+ + diff --git a/docs/mantis/CR2151.md b/docs/mantis/CR2151.md new file mode 100644 index 0000000000000000000000000000000000000000..259337d1c3f6272dbdbcecca6f592656680d24a5 --- /dev/null +++ b/docs/mantis/CR2151.md @@ -0,0 +1,410 @@ + + + + + + + + + + + + + 0002151: Local Timers - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0002151Part 01: TTCN-3 Core LanguageClarificationpublic15-10-2007 13:4024-04-2008 19:45
ReporterGyorgy Rethy 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv3.4.1 (published 2008-09)Fixed in Versionv3.4.1 (published 2008-09) 
Clause Reference(s)$23
Source (company - Author)     
Summary0002151: Local Timers
DescriptionAccording to the TTCN-3 core spec “any timer.timeout” or “all timer.stop” within an activated default behaviour is not to be applied to a local timer. This is not obvious on the first view in the spec and not what a user with TTCN-2 background would expect.
+Example:
+altstep defaultBehaviour() runs on somePTC {
+  [] any timer.timeout {
+    all timer.stop;
+  }
+}
+
+function myFunction() runs on somePTC {
+    timer localTimer := 1.0;
+    alt {
+        [] somePCO.receive(ExpectedMsg)) {}
+    }
+}
+Function myFunction will wait forever when ExpectedMsg is not coming, even when defaultBehaviour is activated.
+ localTimer needs to be handled explicitly in myFunction:
+
+function myFunction() runs on somePTC {
+    timer localTimer := 1.0;
+    alt {
+        [] somePCO.receive(ExpectedMsg)) {}
+        [] localTimer.timeout {}
+    }
+}
+Note: misinterpretations in this case may lead to unexpected run-time behaviour and probably to compiler incompatibilities which may be hard to find.
+
Steps To Reproduce
Additional InformationOne possible solution, of course, would be using component timers for general guarding purposes and for protocol timers. When local timers are used, also a default has to be activated locally by passing the local timer as parameter to the default.
+
+However, existing TTN-2 code may not be written in this style and these restrictions can make conversion a difficult and resource-consuming task. Hence, we shall consider changing the TTCN-3 semantics (in fact the hypothetical model of timer handling). Namely, timer semantics could be similar to semantics of defaults: running and expired timer lists are lists of the component instance; to execute operations on timers individually still requires visibility of the timer’s name at the place of the operation, but any timer… and all timer… operations are executed on all timers on the list, independently where they have been declared. Note, that timers with the same name can be declared and started in a testcase, in different functions and altsteps; hence timer names shall be put on the list prefixed with the name of the entity is has been declared in (similarly to default variables).
+
+There are two options to carry out the changes in the text of the standards (beyond Part-1 also Part-4 may be affected):
+- if no tool vendor supports the current semantics, the standard(s) can simply be changed;
+- otherwise a new TTCN-3 language string shall be defined for the coming edition of TTCN-3, and an optional language clause shall be allowed for TTCN-3 modules (like module MyModule language "TTCN 3:2007" {…}). When a module is using this language string, the new semantics apply; if it is using an elder language string or not using a language string, the semantics defined today apply.
+
TagsNo tags attached.
Relationships
Attached Filesdoc CR-2151-Local-Timers-part-1-JG-080313.doc (186,368) 13-03-2008 14:16
http://oldforge.etsi.org/mantis/file_download.php?file_id=1377&type=bug
doc CR-2151-Local-Timers-part-1-RG-080422.doc (172,032) 22-04-2008 17:28
http://oldforge.etsi.org/mantis/file_download.php?file_id=1434&type=bug
doc CR-2151-Local-Timers-part-4-Resolution.doc (133,632) 24-04-2008 12:53
http://oldforge.etsi.org/mantis/file_download.php?file_id=1452&type=bug
doc CR-2151-Local-Timers-part-4-Resolution-v2.doc (133,632) 24-04-2008 15:02
http://oldforge.etsi.org/mantis/file_download.php?file_id=1453&type=bug
Issue History
Date ModifiedUsernameFieldChange
15-10-2007 13:40Gyorgy RethyNew Issue
15-10-2007 13:40Gyorgy RethyStatusnew => assigned
15-10-2007 13:40Gyorgy RethyAssigned To => Gyorgy Rethy
15-10-2007 13:40Gyorgy RethyClause Reference(s) => $23
15-10-2007 13:40Gyorgy RethySource (company - Author) =>
15-10-2007 19:08Ina SchieferdeckerNote Added: 0003633
15-10-2007 19:14Ina SchieferdeckerAssigned ToGyorgy Rethy => Jens Grabowski
18-10-2007 13:46Ina SchieferdeckerProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
18-10-2007 13:59Ina SchieferdeckerTarget Version => Edition 3.3.1 (not yet published)
03-12-2007 13:50Jens GrabowskiNote Added: 0004230
03-12-2007 13:50Jens GrabowskiTarget VersionEdition 3.3.1 (not yet published) => Edition 4.1.1 (not yet published)
13-03-2008 14:15Jens GrabowskiNote Added: 0005225
13-03-2008 14:16Jens GrabowskiFile Added: CR-2151-Local-Timers-part-1-JG-080313.doc
13-03-2008 18:19Ina SchieferdeckerNote Added: 0005228
14-03-2008 09:37Jens GrabowskiNote Added: 0005231
14-03-2008 09:53Ina SchieferdeckerNote Added: 0005232
21-04-2008 08:50Ina SchieferdeckerTarget VersionEdition 4.1.1 (not yet published) => Edition 3.4.1 (not yet published)
22-04-2008 17:28Gyorgy RethyFile Added: CR-2151-Local-Timers-part-1-RG-080422.doc
22-04-2008 17:30Gyorgy RethyNote Added: 0005504
24-04-2008 12:52Jens GrabowskiNote Added: 0005550
24-04-2008 12:53Jens GrabowskiFile Added: CR-2151-Local-Timers-part-4-Resolution.doc
24-04-2008 12:53Jens GrabowskiAssigned ToJens Grabowski => Thomas Deiß
24-04-2008 14:53Thomas DeißNote Added: 0005551
24-04-2008 14:54Thomas DeißAssigned ToThomas Deiß => Jens Grabowski
24-04-2008 15:01Jens GrabowskiNote Added: 0005552
24-04-2008 15:02Jens GrabowskiFile Added: CR-2151-Local-Timers-part-4-Resolution-v2.doc
24-04-2008 15:04Jens GrabowskiAssigned ToJens Grabowski => Ina Schieferdecker
24-04-2008 15:04Jens GrabowskiStatusassigned => resolved
24-04-2008 15:04Jens GrabowskiResolutionopen => fixed
24-04-2008 19:45Ina SchieferdeckerStatusresolved => closed
24-04-2008 19:45Ina SchieferdeckerFixed in Version => Edition 3.4.1 (not yet published)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0003633) +
+ Ina Schieferdecker    +
+ 15-10-2007 19:08    +
+ 		+ + + + +
+ The meaning of "local timer" here is a timer local to the enclosing scope - but not local to the default.
+
+
+
+ + + + + + + + + + +
+ (0004230) +
+ Jens Grabowski    +
+ 03-12-2007 13:50    +
+ 		+ + + + +
+ Question to the vendors about their implementation of any/all timer.timeout.
+
+
+
+ + + + + + + + + + +
+ (0005225) +
+ Jens Grabowski    +
+ 13-03-2008 14:15    +
+ 		+ + + + +
+ The attachment is a first draft of changes in part 1 if the CR is accepted.
+
+
+
+ + + + + + + + + + +
+ (0005228) +
+ Ina Schieferdecker    +
+ 13-03-2008 18:19    +
+ 		+ + + + +
+ Awaiting steering committee decision
+
+Check also clause 12
+
+
+
+ + + + + + + + + + +
+ (0005231) +
+ Jens Grabowski    +
+ 14-03-2008 09:37    +
+ 		+ + + + +
+ As part of the resolution of this CR also the lifetime of a timer object has to be clarified:
+
+- Option 1: A timer is destroyed when the scope unit is left.
+
+- Option 2: A timer is destroyed when a component is destroyed.
+
+Option 2 has implications on alive components.
+
+
+
+ + + + + + + + + + +
+ (0005232) +
+ Ina Schieferdecker    +
+ 14-03-2008 09:53    +
+ 		+ + + + +
+ The lifetime of a timer is already questioned in CR 2753 - the CRs should be resolved together
+
+
+
+ + + + + + + + + + +
+ (0005504) +
+ Gyorgy Rethy    +
+ 22-04-2008 17:30    +
+ 		+ + + + +
+ I propose to change just the place of the word "individual" in $23.1 Note2 in the file CR-2151-Local-Timers-part-1-RG-080422.doc
+
+
+
+ + + + + + + + + + +
+ (0005550) +
+ Jens Grabowski    +
+ 24-04-2008 12:52    +
+ 		+ + + + +
+ Attached resolution for part 4 includes the corrected figures that resolve the CR. Text need not to be changed in part 4.
+
+
+
+ + + + + + + + + + +
+ (0005551) +
+ Thomas Deiß    +
+ 24-04-2008 14:53    +
+ 		+ + + + +
+ proposal checked: ok.
+editorial: change timerID -> timerId
+
+
+
+ + + + + + + + + + +
+ (0005552) +
+ Jens Grabowski    +
+ 24-04-2008 15:01    +
+ 		+ + + + +
+ Editorial Changes Done!
+
+ + diff --git a/docs/mantis/CR2152.md b/docs/mantis/CR2152.md new file mode 100644 index 0000000000000000000000000000000000000000..e52da56b88e86d01d7b806a207271b034bfa048b --- /dev/null +++ b/docs/mantis/CR2152.md @@ -0,0 +1,361 @@ + + + + + + + + + + + + + 0002152: Initialisation of constants using internal/external functions - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0002152Part 01: TTCN-3 Core LanguageClarificationpublic15-10-2007 13:4409-12-2008 16:29
ReporterGyorgy Rethy 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)$10
Source (company - Author)     
Summary0002152: Initialisation of constants using internal/external functions
DescriptionAccording to the current version of the TTCN-3 spec, functions are not allowed for initialisation of constants. Nevertheless some compilers allow even external functions. On the other hand at least build-in functions seem to be useful within constant definitions (e.g. to initialise long bitstrings with ‘0’). Also the usage of TTCN-3 functions considering restrictions according to clause 16.1.4 “Restrictions for functions called from specific places” seem to be suitable.
+Anyway it would be helpful to give examples of constant definitions to illustrate what shall be allowed and what is not allowed.
+Compilers should generate at least a warning, when a constant declaration contains not allowed parts.
+
Steps To Reproduce
Additional InformationThe TTCN-3 standard core language is stating that the constant value shall be known at compile time. While this may be a clear requirement for compiler experts, may not be sufficient for most of the users. It shall explicitly be stated that in constant expressions only the following elements are allowed:
+• literal values,
+• constants,
+• predefined conversion functions (int2unichar, int2bit, int2hex, int2oct, int2str, int2float, float2int, char2int, char2oct, unichar2int, bit2int, bit2hex, bit2oct, bit2str, hex2int, hex2bit, hex2oct, hex2str, oct2int, oct2bit, oct2hex, oct2str, oct2char, str2int, str2oct, str2float), provided all their parameters are either literal values or constants;
+• predefined functions lengthof, sizeof, ispresent, ischosen, regexp, substr, replace and (decomp) provided their parameters are either literal values or constants.
+
+Thus, the predefined functions rnd and sizeoftype are not allowed. In principle, valueof could be considered BUT we think the gained feature does NOT pays of the complexity of the implementation (valueof non-parameterized templates that are using at maximum the above predefined functions and other non-parameterized templates or templates parameterized with literal or constant values and again using…).
+
TagsNo tags attached.
Relationships
related to 0004270closed Ina Schieferdecker Initialization expressions within component types 
Attached Filesdoc CR2152_SolutionOutline.doc (39,424) 13-03-2008 15:02
http://oldforge.etsi.org/mantis/file_download.php?file_id=1378&type=bug
zip es_20187301v040100_CR2152.zip (874,214) 13-03-2008 15:06
http://oldforge.etsi.org/mantis/file_download.php?file_id=1379&type=bug
zip es_20187301v040000_CR2152_v2.zip (875,567) 25-04-2008 13:06
http://oldforge.etsi.org/mantis/file_download.php?file_id=1461&type=bug
zip es_20187301v040000_CR2152_v3.zip (874,114) 14-08-2008 13:46
http://oldforge.etsi.org/mantis/file_download.php?file_id=1601&type=bug
zip es_20187301v040000_CR2152_v4.zip (851,675) 14-08-2008 15:24
http://oldforge.etsi.org/mantis/file_download.php?file_id=1604&type=bug
zip es_20187301v040000_CR2152_v5.zip (878,202) 17-08-2008 10:01
http://oldforge.etsi.org/mantis/file_download.php?file_id=1611&type=bug
zip es_20187301v040000_CR2152_v6.zip (859,685) 25-11-2008 13:51
http://oldforge.etsi.org/mantis/file_download.php?file_id=1777&type=bug
zip es_20187301v040000_CR2152_v7.zip (881,332) 26-11-2008 08:59
http://oldforge.etsi.org/mantis/file_download.php?file_id=1787&type=bug
Issue History
Date ModifiedUsernameFieldChange
15-10-2007 13:44Gyorgy RethyNew Issue
15-10-2007 13:44Gyorgy RethyStatusnew => assigned
15-10-2007 13:44Gyorgy RethyAssigned To => Gyorgy Rethy
15-10-2007 13:44Gyorgy RethyClause Reference(s) => $10
15-10-2007 13:44Gyorgy RethySource (company - Author) =>
15-10-2007 19:36Ina SchieferdeckerAssigned ToGyorgy Rethy => developer_u
17-10-2007 12:42user10Assigned Todeveloper_u => Thomas Deiß
18-10-2007 13:44Ina SchieferdeckerProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
18-10-2007 13:57Ina SchieferdeckerTarget Version => Edition 3.3.1 (not yet published)
03-12-2007 12:28Jens GrabowskiNote Added: 0004226
03-12-2007 12:29Jens GrabowskiTarget VersionEdition 3.3.1 (not yet published) => Edition 4.1.1 (not yet published)
12-03-2008 14:45Ina SchieferdeckerAssigned ToThomas Deiß => Ina Schieferdecker
13-03-2008 15:02Ina SchieferdeckerFile Added: CR2152_SolutionOutline.doc
13-03-2008 15:06Ina SchieferdeckerFile Added: es_20187301v040100_CR2152.zip
13-03-2008 15:06Ina SchieferdeckerAssigned ToIna Schieferdecker => Thomas Deiß
21-04-2008 08:51Ina SchieferdeckerTarget VersionEdition 4.1.1 (not yet published) => Edition 3.4.1 (not yet published)
25-04-2008 13:05Ina SchieferdeckerNote Added: 0005580
25-04-2008 13:06Ina SchieferdeckerFile Added: es_20187301v040000_CR2152_v2.zip
25-04-2008 13:07Ina SchieferdeckerTarget VersionEdition 3.4.1 (not yet published) => Edition 4.1.1 (not yet published)
25-04-2008 13:07Ina SchieferdeckerAssigned ToThomas Deiß => Gyorgy Rethy
14-08-2008 13:46Ina SchieferdeckerFile Added: es_20187301v040000_CR2152_v3.zip
14-08-2008 13:47Ina SchieferdeckerNote Added: 0006530
14-08-2008 15:24Gyorgy RethyFile Added: es_20187301v040000_CR2152_v4.zip
14-08-2008 15:30Gyorgy RethyNote Added: 0006536
14-08-2008 15:30Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
15-08-2008 09:22Ina SchieferdeckerNote Added: 0006540
15-08-2008 09:22Ina SchieferdeckerStatusassigned => resolved
15-08-2008 09:22Ina SchieferdeckerResolutionopen => fixed
15-08-2008 09:22Ina SchieferdeckerFixed in Version => Edition 4.1.1 (not yet published)
17-08-2008 10:00Ina SchieferdeckerNote Edited: 0006540
17-08-2008 10:01Ina SchieferdeckerFile Added: es_20187301v040000_CR2152_v5.zip
17-08-2008 10:02Ina SchieferdeckerAssigned ToIna Schieferdecker => Gyorgy Rethy
17-08-2008 10:02Ina SchieferdeckerStatusresolved => assigned
18-09-2008 04:06Thomas DeißNote Added: 0006834
25-11-2008 10:26Ina SchieferdeckerRelationship addedrelated to 0004270
25-11-2008 13:50Gyorgy RethyNote Added: 0007411
25-11-2008 13:51Gyorgy RethyFile Added: es_20187301v040000_CR2152_v6.zip
25-11-2008 13:51Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
26-11-2008 08:58Thomas DeißFile Added: CR4270_ConstantsInTypes_v2.doc
26-11-2008 08:58Thomas DeißFile Deleted: CR4270_ConstantsInTypes_v2.doc
26-11-2008 08:59Thomas DeißFile Added: es_20187301v040000_CR2152_v7.zip
26-11-2008 09:00Thomas DeißNote Added: 0007438
27-11-2008 13:26Thomas DeißNote Added: 0007470
09-12-2008 16:28Ina SchieferdeckerStatusassigned => resolved
09-12-2008 16:29Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0004226) +
+ Jens Grabowski    +
+ 03-12-2007 12:28    +
+ 		+ + + + +
+ Cannot be fixed in Version 3.3.1. Either test suites are invalidated or requires major changes in part 1 and part 4.
+
+
+
+ + + + + + + + + + +
+ (0005580) +
+ Ina Schieferdecker    +
+ 25-04-2008 13:05    +
+ 		+ + + + +
+ We propose to ease the constant handling by making constants run-time constants in general and to impose compile-time constant limitations only for those constants which are used in type definitions.
+
+
+
+ + + + + + + + + + +
+ (0006530) +
+ Ina Schieferdecker    +
+ 14-08-2008 13:47    +
+ 		+ + + + +
+ One more run through the resolution: the external contant BNF productions have to be kept - external constants are deprecated only.
+
+
+
+ + + + + + + + + + +
+ (0006536) +
+ Gyorgy Rethy    +
+ 14-08-2008 15:30    +
+ 		+ + + + +
+ There are some changes of the wording in ~v4, to be cross-checked.
+
+
+
+ + + + + + + + + + +
+ (0006540) +
+ Ina Schieferdecker    +
+ 15-08-2008 09:22    +
(edited on: 17-08-2008 10:00)
+ 		+ + + + +
+ See resolution v5:
+
+Extended sentence for clause 6.2.7 Arrays: "Constants used in the constant expressions shall meet with the restrictions in clause 10, see in particular restriction c)"
+
+Restr. g in 8.2.1: "g) Module parameters shall not be used in type or array definitions."
+
+Constant explaination in 10: "A value is assigned only once to a constant, which does not change its value during test execution."
+
+
+
+
+
+ + + + + + + + + + +
+ (0006834) +
+ Thomas Deiß    +
+ 18-09-2008 04:06    +
+ 		+ + + + +
+ clause 10, restriction b) The value of the ConstantExpression assigned to a constant shall be of the same type as the stated type for the constants.
+
+Isn't this too strict? Compatibility of the value with the type of the constant would be sufficient.
+
+
+
+ + + + + + + + + + +
+ (0007411) +
+ Gyorgy Rethy    +
+ 25-11-2008 13:50    +
+ 		+ + + + +
+ Deleted "dynamic" from 1st sentence of clause 10. Added, that constants shall be initialized at declaration to the "semantic description". BNF rule 576: static semantic rule is removed. My changes are in es_20187301v040000_CR2152_v6.zip. Otherwise OK with me.
+
+
+
+ + + + + + + + + + +
+ (0007438) +
+ Thomas Deiß    +
+ 26-11-2008 09:00    +
+ 		+ + + + +
+ one typo found.
+restriction that expression to initialize constant has to be of the same type removed. This is obvious.
+v7 uploaded.
+
+
+
+ + + + + + + + + + +
+ (0007470) +
+ Thomas Deiß    +
+ 27-11-2008 13:26    +
+ 		+ + + + +
+ Clause 6.2.1 contains the following sentence (end of first paragraph)
+
+"A constant that is of record type shall contain no variables or module parameters as field values, either directly or indirectly."
+
+This will be too strict. How a constant can be initialized will be defined anyway. This specific sentence can be removed.
+
+ + diff --git a/docs/mantis/CR2175.md b/docs/mantis/CR2175.md new file mode 100644 index 0000000000000000000000000000000000000000..fb44f9db4c6f419d54f605e08acfdb15bd4969cd --- /dev/null +++ b/docs/mantis/CR2175.md @@ -0,0 +1,69 @@ + + + + + + + + + + + + + 0002175: New pre-defined TTCN-3 function “enum2int” - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0002175Part 01: TTCN-3 Core LanguageNew Featurepublic18-10-2007 09:4612-03-2008 10:24
ReporterAndy Rauland 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv3.3.2 (published 2008-04)Fixed in Versionv3.3.2 (published 2008-04) 
Clause Reference(s)Annex C
Source (company - Author)Andy Rauland, Nokia Siemens Networks
Summary0002175: New pre-defined TTCN-3 function “enum2int”
DescriptionAccording chapter 6.2.4 each enumeration may optionally have assigned an integer value which is defined after the name of the enumeration in parentheses.
+In order to benefit further on such assignments, a mechanism is required to return the assigned integer value at run time. For this a new pre-defined TTCN-3 function is required.
+
+Syntax:
+enum2int(enumerated value) return integer
+
Steps To Reproduce
Additional InformationThis new pre-defined TTCN-3 function would avoid the implementation via an external function and simplify the TTCN-3 code exchange between different test tools.
+
TagsNo tags attached.
Relationships
Attached Filesdoc STF_Solution_CR2175.doc (280,064) 18-10-2007 17:32
http://oldforge.etsi.org/mantis/file_download.php?file_id=1051&type=bug
doc STF_Solution_CR2175_2.doc (280,576) 04-12-2007 08:47
http://oldforge.etsi.org/mantis/file_download.php?file_id=1182&type=bug
Issue History
Date ModifiedUsernameFieldChange
18-10-2007 09:46Andy RaulandNew Issue
18-10-2007 09:46Andy RaulandStatusnew => assigned
18-10-2007 09:46Andy RaulandAssigned To => Gyorgy Rethy
18-10-2007 09:46Andy RaulandClause Reference(s) => Annex C
18-10-2007 09:46Andy RaulandSource (company - Author) => Andy Rauland, Nokia Siemens Networks
18-10-2007 13:41Ina SchieferdeckerProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
18-10-2007 13:42Ina SchieferdeckerTarget Version => Edition 3.3.1 (not yet published)
18-10-2007 17:32Gyorgy RethyFile Added: STF_Solution_CR2175.doc
19-10-2007 13:29Gyorgy RethyResolutionopen => fixed
03-12-2007 14:24Jens GrabowskiAssigned ToGyorgy Rethy => Thomas Deiß
04-12-2007 08:47Thomas DeißFile Added: STF_Solution_CR2175_2.doc
04-12-2007 08:48Thomas DeißNote Added: 0004249
04-12-2007 08:48Thomas DeißAssigned ToThomas Deiß => Ina Schieferdecker
04-12-2007 16:43Ina SchieferdeckerStatusassigned => resolved
05-12-2007 16:54Ina SchieferdeckerStatusresolved => closed
05-12-2007 16:54Ina SchieferdeckerFixed in Version => Edition 3.3.1 (not yet published)
12-03-2008 10:22user10Fixed in VersionEdition 3.3.1 --will not be published, see 3.3.2 => Edition 3.3.2 (not yet published)
12-03-2008 10:24user10Target VersionEdition 3.3.1 --will not be published, see 3.3.2 => Edition 3.3.2 (not yet published)
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0004249) +
+ Thomas Deiß    +
+ 04-12-2007 08:48    +
+ 		+ + + + +
+ solution ok. One missing semicolon in example added.
+
+ + diff --git a/docs/mantis/CR2329.md b/docs/mantis/CR2329.md new file mode 100644 index 0000000000000000000000000000000000000000..8e5057f33c49e63c1b2c5ea9b672c998ca4728e4 --- /dev/null +++ b/docs/mantis/CR2329.md @@ -0,0 +1,68 @@ + + + + + + + + + + + + + 0002329: How can I change the SDU (max) size on the run so I will be able to test fragmentation in diffrent sizes?? - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 05: TTCN-3 Runtime Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0002329Part 05: TTCN-3 Runtime Interface Clarificationpublic12-11-2007 10:2112-12-2008 11:39
Reporteraltair reporter 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityfeatureReproducibilityhave not tried
StatusclosedResolutionno change required 
PlatformOSOS Version
Product Versionv3.2.1 (published 2007-02) 
Target Versionv3.3.1 (published 2008-04)Fixed in Version 
Clause Reference(s)Fragmentation, SDU size, burst size
Source (company - Author)Altair
Summary0002329: How can I change the SDU (max) size on the run so I will be able to test fragmentation in diffrent sizes??
DescriptionHow can I change the SDU max size on the run so I will be able to test fragmentation in diffrent sizes??
+
+The only place where I can control the SDU size is via WMx_Templates_16e.ttcn Is it possible to change it at under vc_simu before or after establishing service flow and how?
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
12-11-2007 10:21altair reporterNew Issue
12-11-2007 10:21altair reporterStatusnew => assigned
12-11-2007 10:21altair reporterAssigned To => Ina Schieferdecker
12-11-2007 10:21altair reporterClause Reference(s) => Fragmentation, SDU size, burst size
12-11-2007 10:21altair reporterSource (company - Author) => Altair
03-12-2007 14:57Ina SchieferdeckerNote Added: 0004239
03-12-2007 14:58Ina SchieferdeckerStatusassigned => closed
03-12-2007 14:58Ina SchieferdeckerResolutionopen => no change required
12-12-2008 11:39Ina SchieferdeckerTarget Version => Edition 3.3.1
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0004239) +
+ Ina Schieferdecker    +
+ 03-12-2007 14:57    +
+ 		+ + + + +
+ This is not a TTCN-3 issue as such - here, we handle only issues related to the TTCN-3 standard - not to its application such as the design or implementation of test suites. Please consult a TTCN-3 expert for this.
+
+Anyhow, please check component variables or module parameters - whatever you mean by "on the run"
+
+ + diff --git a/docs/mantis/CR2334.md b/docs/mantis/CR2334.md new file mode 100644 index 0000000000000000000000000000000000000000..423f23c67a6906642b6674f865bffed8a31e47c7 --- /dev/null +++ b/docs/mantis/CR2334.md @@ -0,0 +1,66 @@ + + + + + + + + + + + + + 0002334: How can we set BS & MS to work with variable size SDUs? - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 05: TTCN-3 Runtime Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0002334Part 05: TTCN-3 Runtime Interface Clarificationpublic12-11-2007 10:3512-12-2008 11:39
Reporteraltair reporter 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityfeatureReproducibilityhave not tried
StatusclosedResolutionno change required 
PlatformOSOS Version
Product Versionv3.2.1 (published 2007-02) 
Target Versionv3.3.1 (published 2008-04)Fixed in Version 
Clause Reference(s)Fragmentation, Packing, SDU size
Source (company - Author)     
Summary0002334: How can we set BS & MS to work with variable size SDUs?
DescriptionHow can we set BS & MS to work with variable size SDUs?
+I need to use this feature to test packing & fragmentation
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
12-11-2007 10:35altair reporterNew Issue
12-11-2007 10:35altair reporterStatusnew => assigned
12-11-2007 10:35altair reporterAssigned To => Ina Schieferdecker
12-11-2007 10:35altair reporterClause Reference(s) => Fragmentation, Packing, SDU size
12-11-2007 10:35altair reporterSource (company - Author) =>
03-12-2007 14:54Ina SchieferdeckerNote Added: 0004237
03-12-2007 14:55Ina SchieferdeckerStatusassigned => closed
03-12-2007 14:55Ina SchieferdeckerResolutionopen => no change required
12-12-2008 11:39Ina SchieferdeckerTarget Version => Edition 3.3.1
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0004237) +
+ Ina Schieferdecker    +
+ 03-12-2007 14:54    +
+ 		+ + + + +
+ This is not a TTCN-3 issue as such - here, we handle only issues related to the TTCN-3 standard - not to its application such as the design or implementation of test suites. Please consult a TTCN-3 expert for this.
+
+Anyhow, a possible direction could be to use record of type definitions or alike.
+
+ + diff --git a/docs/mantis/CR2387.md b/docs/mantis/CR2387.md new file mode 100644 index 0000000000000000000000000000000000000000..941ad2d780eab5e1323493171eecf24aa967568c --- /dev/null +++ b/docs/mantis/CR2387.md @@ -0,0 +1,98 @@ + + + + + + + + + + + + + 0002387: usage of quotes in charstrings - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0002387Part 01: TTCN-3 Core LanguageClarificationpublic21-11-2007 07:4012-03-2008 10:24
ReporterThomas Deiß 
Assigned ToIna Schieferdecker 
PrioritynormalSeveritytextReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv3.3.2 (published 2008-04)Fixed in Versionv3.3.2 (published 2008-04) 
Clause Reference(s)6.1.1
Source (company - Author)Hellen Griffith, ETSI TF 160
Summary0002387: usage of quotes in charstrings
DescriptionClause 6.1.1 in part1 has an example on the usage of quotes in charstrings. The examples is misleading in the way that the quotes around the example charstring are missing. So, a charstring literal with a quote as first character will be written with 3 starting quotes in TTCN-3 code. 1st quote: delimiter of the charstring, 2nd quote: escape character for quote, 3rd quote: the actual quote.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR_2387_quotes.doc (499,200) 26-11-2007 13:51
http://oldforge.etsi.org/mantis/file_download.php?file_id=1159&type=bug
Issue History
Date ModifiedUsernameFieldChange
21-11-2007 07:40Thomas DeißNew Issue
21-11-2007 07:40Thomas DeißStatusnew => assigned
21-11-2007 07:40Thomas DeißAssigned To => Thomas Deiß
21-11-2007 07:40Thomas DeißClause Reference(s) => 6.1.1
21-11-2007 07:40Thomas DeißSource (company - Author) => Hellen Griffith, ETSI TF 160
21-11-2007 07:59Thomas DeißProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
26-11-2007 13:51Thomas DeißFile Added: CR_2387_quotes.doc
26-11-2007 13:51Thomas DeißNote Added: 0004102
26-11-2007 13:51Thomas DeißTarget Version => Edition 3.3.1 (not yet published)
03-12-2007 11:56Jens GrabowskiAssigned ToThomas Deiß => Jens Grabowski
04-12-2007 10:55Jens GrabowskiNote Added: 0004255
04-12-2007 10:55Jens GrabowskiAssigned ToJens Grabowski => Gyorgy Rethy
05-12-2007 11:38Jens GrabowskiAssigned ToGyorgy Rethy => Ina Schieferdecker
05-12-2007 11:38Jens GrabowskiStatusassigned => resolved
05-12-2007 17:39Ina SchieferdeckerStatusresolved => closed
05-12-2007 17:39Ina SchieferdeckerResolutionopen => fixed
05-12-2007 17:39Ina SchieferdeckerFixed in Version => Edition 3.3.1 (not yet published)
12-03-2008 10:22user10Fixed in VersionEdition 3.3.1 --will not be published, see 3.3.2 => Edition 3.3.2 (not yet published)
12-03-2008 10:24user10Target VersionEdition 3.3.1 --will not be published, see 3.3.2 => Edition 3.3.2 (not yet published)
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0004102) +
+ Thomas Deiß    +
+ 26-11-2007 13:51    +
+ 		+ + + + +
+ Proposed Resolution
+
+
+
+
+ + + + + + + + + + +
+ (0004255) +
+ Jens Grabowski    +
+ 04-12-2007 10:55    +
+ 		+ + + + +
+ Crosschecked by Jens. OK!
+
+ + diff --git a/docs/mantis/CR2388.md b/docs/mantis/CR2388.md new file mode 100644 index 0000000000000000000000000000000000000000..0fbc2ea4c4fe803a58afe751ca680461f285aec6 --- /dev/null +++ b/docs/mantis/CR2388.md @@ -0,0 +1,100 @@ + + + + + + + + + + + + + 0002388: padding in BinaryString - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 05: TTCN-3 Runtime Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0002388Part 05: TTCN-3 Runtime Interface Clarificationpublic21-11-2007 07:5805-12-2007 16:12
ReporterThomas Deiß 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.2.1 (published 2007-02) 
Target Versionv3.3.1 (published 2008-04)Fixed in Versionv3.3.1 (published 2008-04) 
Clause Reference(s)7.2.2, 6.2.3.5
Source (company - Author)Nokia Siemens Networks, Thomas Deiß
Summary0002388: padding in BinaryString
DescriptionThe type definition of BinaryString in TRI leaves it open whether a non-octet aligned BinaryString is padded at the MSB or LSB. It is proposed to pad at the LSB. A binary string '1010 1100 111' will be contained in a BinaryString as follows
+'1010 1100 111x xxxx'
+MSB LSB
+and where x are arbitrary padding bits.
Steps To Reproduce
Additional InformationThe BinaryString is introduced as the definition of TriMessageType in the C-mapping. Actually, the padding has to be explained for this TriMessageType. As an additional problem, the Java mapping does not allow to access the exact number of bits in an object of TriMessageType.
TagsNo tags attached.
Relationships
Attached Filesdoc CR_2388_BinaryString.doc (476,160) 26-11-2007 11:32
http://oldforge.etsi.org/mantis/file_download.php?file_id=1157&type=bug
Issue History
Date ModifiedUsernameFieldChange
21-11-2007 07:58Thomas DeißNew Issue
21-11-2007 07:58Thomas DeißStatusnew => assigned
21-11-2007 07:58Thomas DeißAssigned To => Thomas Deiß
21-11-2007 07:58Thomas DeißClause Reference(s) => 7.2.2, 6.2.3.5
21-11-2007 07:58Thomas DeißSource (company - Author) => Nokia Siemens Networks, Thomas Deiß
26-11-2007 11:32Thomas DeißFile Added: CR_2388_BinaryString.doc
26-11-2007 11:33Thomas DeißNote Added: 0004093
26-11-2007 11:33Thomas DeißTarget Version => Edition 3.3.1 (not yet published)
04-12-2007 17:54Thomas DeißNote Added: 0004300
04-12-2007 17:54Thomas DeißAssigned ToThomas Deiß => Ina Schieferdecker
05-12-2007 15:46Ina SchieferdeckerStatusassigned => resolved
05-12-2007 15:46Ina SchieferdeckerResolutionopen => fixed
05-12-2007 16:12Ina SchieferdeckerStatusresolved => closed
05-12-2007 16:12Ina SchieferdeckerFixed in Version => Edition 3.3.1 (not yet published)
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0004093) +
+ Thomas Deiß    +
+ 26-11-2007 11:33    +
+ 		+ + + + +
+ Proposal for resolution added
+
+
+
+ + + + + + + + + + +
+ (0004300) +
+ Thomas Deiß    +
+ 04-12-2007 17:54    +
+ 		+ + + + +
+ needs checking
+
+ + diff --git a/docs/mantis/CR2564.md b/docs/mantis/CR2564.md new file mode 100644 index 0000000000000000000000000000000000000000..d9d0c0a7dbcc0fe8290d5f3830a13cd915acace8 --- /dev/null +++ b/docs/mantis/CR2564.md @@ -0,0 +1,71 @@ + + + + + + + + + + + + + 0002564: Use of unitialized values - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0002564Part 01: TTCN-3 Core LanguageTechnicalpublic05-12-2007 15:0618-07-2008 11:19
ReporterIna Schieferdecker 
Assigned ToIna Schieferdecker 
PrioritynormalSeveritymajorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)Part 1, Clause 11
Source (company - Author)FOKUS
Summary0002564: Use of unitialized values
DescriptionIn v3.1.1 an unneccessary limitation about the use of uninitialized values has been put into part 1, clause 11.1, Restrictions
+
+"d) Use of uninitialized or not completely initialized value variables at other places than the left hand side of assignments or as actual parameters passed to out formal parameters shall cause an error."
+
+This should be leveraged to
+
+"d) Use of uninitialized or not completely initialized value variables at other places than the left hand side of assignments or as actual parameters passed to formal parameters shall cause an error."
+
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
05-12-2007 15:06Ina SchieferdeckerNew Issue
05-12-2007 15:06Ina SchieferdeckerStatusnew => assigned
05-12-2007 15:06Ina SchieferdeckerAssigned To => Jens Grabowski
05-12-2007 15:06Ina SchieferdeckerClause Reference(s) => Part 1, Clause 11
05-12-2007 15:06Ina SchieferdeckerSource (company - Author) => FOKUS
05-12-2007 15:06Ina SchieferdeckerProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
05-12-2007 15:24Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
15-07-2008 13:55Ina SchieferdeckerNote Added: 0006279
17-07-2008 11:38Ina SchieferdeckerStatusassigned => resolved
17-07-2008 11:38Ina SchieferdeckerResolutionopen => fixed
17-07-2008 11:39Ina SchieferdeckerStatusresolved => assigned
17-07-2008 11:39Ina SchieferdeckerAssigned ToJens Grabowski => Ina Schieferdecker
17-07-2008 11:39Ina SchieferdeckerStatusassigned => resolved
17-07-2008 11:39Ina SchieferdeckerFixed in Version => Edition 4.1.1 (not yet published)
18-07-2008 11:19Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0006279) +
+ Ina Schieferdecker    +
+ 15-07-2008 13:55    +
+ 		+ + + + +
+ we can agree to leverage for inout parameters only: "d) Use of uninitialized or not completely initialized value variables at other places than the left hand side of assignments or as actual parameters passed to inout or out formal parameters shall cause an error."
+
+ + diff --git a/docs/mantis/CR2565.md b/docs/mantis/CR2565.md new file mode 100644 index 0000000000000000000000000000000000000000..3e2e13254b079900d47d08ce12670ea800f79132 --- /dev/null +++ b/docs/mantis/CR2565.md @@ -0,0 +1,151 @@ + + + + + + + + + + + + + 0002565: TTCN-3 Exceptions - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0002565Part 06: TTCN-3 Control InterfaceNew Featurepublic05-12-2007 15:1112-12-2008 15:40
ReporterIna Schieferdecker 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityfeatureReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)Part 1, Clause 24.1
Source (company - Author)     
Summary0002565: TTCN-3 Exceptions
DescriptionThe error handling in TTCN-3 is very weak - only an error verdict can be assigned. A more fine-grained solution as e.g. used in other technologies (for example CORBA system exceptions) could be used instead.
+
+This CR proposes to have predefined TTCN-3 system exceptions which may be raised by the runtime system, logged in the verdict (for example as a parameter to the error verdict) and in the logging file.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0003843closed Thomas Deiß Part 01: TTCN-3 Core Language Support C++ like Exception Handling mechanism 
Attached Filesdoc CR_2565_resolution_01.doc (168,960) 13-10-2008 15:12
http://oldforge.etsi.org/mantis/file_download.php?file_id=1682&type=bug
Issue History
Date ModifiedUsernameFieldChange
05-12-2007 15:11Ina SchieferdeckerNew Issue
05-12-2007 15:11Ina SchieferdeckerStatusnew => assigned
05-12-2007 15:11Ina SchieferdeckerAssigned To => Thomas Deiß
05-12-2007 15:11Ina SchieferdeckerClause Reference(s) => Part 1, Clause 24.1
05-12-2007 15:11Ina SchieferdeckerSource (company - Author) =>
05-12-2007 15:12Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
23-04-2008 18:13Thomas DeißNote Added: 0005536
11-08-2008 10:35Thomas DeißRelationship addedrelated to 0003843
13-10-2008 15:12Thomas DeißFile Added: CR_2565_resolution_01.doc
13-10-2008 15:17Thomas DeißNote Added: 0007044
13-10-2008 15:17Thomas DeißAssigned ToThomas Deiß => Ina Schieferdecker
14-10-2008 09:49Ina SchieferdeckerStatusassigned => resolved
14-10-2008 09:49Ina SchieferdeckerResolutionopen => fixed
14-10-2008 09:55Ina SchieferdeckerNote Added: 0007051
14-10-2008 09:56Ina SchieferdeckerNote Deleted: 0007051
14-10-2008 09:56Ina SchieferdeckerNote Added: 0007052
10-12-2008 08:59Ina SchieferdeckerProjectPart 01: TTCN-3 Core Language => Part 06: TTCN-3 Control Interface
12-12-2008 15:40Ina SchieferdeckerStatusresolved => closed
12-12-2008 15:40Ina SchieferdeckerFixed in Version => Edition 4.1.1 (not yet published)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0005536) +
+ Thomas Deiß    +
+ 23-04-2008 18:13    +
+ 		+ + + + +
+ 1) The TCI-CH has to be extended by tciError and tciErrorReq such that errors can be propagated to the TM in a distributed test system.
+2) tliSetverdict should be extended such that it can be called also when there is a dynamic error. tliInfo is not a suitable log event in this case.
+
+3) Erroneous situations shall not be _handled_ within the test system, but a user should be informed in a consistent manner.
+
+
+
+ + + + + + + + + + +
+ (0007044) +
+ Thomas Deiß    +
+ 13-10-2008 15:17    +
+ 		+ + + + +
+ Resolution:
+tliSetverdict may be called to report runtime error.
+
+corrections in constraints of TCI-CH operations because the start test component operation may call a function with out and inout parameters. Allow to use PTC_ALIVE as type in create test component.
+
+No change to parameter lists of operations, therefore no change to language mappings.
+
+
+
+ + + + + + + + + + +
+ (0007052) +
+ Ina Schieferdecker    +
+ 14-10-2008 09:56    +
+ 		+ + + + +
+ Had to correct also the tliSetVerdict operation in the C++ mapping:
+
+from
+
+"virtual void tliSetVerdict (const Tstring &am, const timeval ts, const Tstring &src, const Tinteger line, const TriComponentId *c, const VerdictValue *verdict)=0"
+
+to
+
+"virtual void tliSetVerdict (const Tstring &am, const timeval ts, const Tstring &src, const Tinteger line, const TriComponentId *c, const VerdictValue *verdict, const TString &reason)=0"
+
+The reason parameter was missing.
+
+ + diff --git a/docs/mantis/CR2566.md b/docs/mantis/CR2566.md new file mode 100644 index 0000000000000000000000000000000000000000..043c67dafc11b157e1e5b26edfd145d59d074f95 --- /dev/null +++ b/docs/mantis/CR2566.md @@ -0,0 +1,271 @@ + + + + + + + + + + + + + 0002566: Packages and namespaces - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0002566Part 09: Using XML with TTCN-3New Featurepublic05-12-2007 15:1914-02-2010 16:05
ReporterIna Schieferdecker 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityfeatureReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)Part 1, Clause 8
For STF discussion
Source (company - Author)     
Summary0002566: Packages and namespaces
DescriptionTTCN-3 has no support for packages and namespaces which makes large projects for test suites split into several modules - which are at best put into a logical hierarchy or directory tree - hard to handle. Therefore, a package concept is being proposed in order to ease the practical use of TTCN-3.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
parent of 0004613closed Gyorgy Rethy Part 09: Using XML with TTCN-3 Packages and namespaces 
parent of 0005474closed Ina Schieferdecker Part 08: Using IDL with TTCN-3 Packages and namespaces - Visibility of Imported Declarations from External Sources 
Attached Filesppt ModuleInterfaces.ppt (31,232) 13-10-2008 18:32
http://oldforge.etsi.org/mantis/file_download.php?file_id=1686&type=bug
ppt ModuleInterfacesImplementation.ppt (62,464) 14-10-2008 17:00
http://oldforge.etsi.org/mantis/file_download.php?file_id=1691&type=bug
doc CR2566_ModuleInterfaces.doc (1,127,424) 26-11-2008 14:35
http://oldforge.etsi.org/mantis/file_download.php?file_id=1789&type=bug
doc CR2566_ModuleInterfaces_v02.doc (1,164,288) 26-11-2008 17:15
http://oldforge.etsi.org/mantis/file_download.php?file_id=1794&type=bug
doc CR2566_ModuleInterfaces_v03.doc (1,142,272) 27-11-2008 13:51
http://oldforge.etsi.org/mantis/file_download.php?file_id=1814&type=bug
doc CR2566 Resolution Part-7.doc (198,656) 27-11-2008 13:52
http://oldforge.etsi.org/mantis/file_download.php?file_id=1815&type=bug
doc CR2566_ModuleInterfaces_v04.doc (1,145,344) 13-01-2009 11:30
http://oldforge.etsi.org/mantis/file_download.php?file_id=1950&type=bug
Issue History
Date ModifiedUsernameFieldChange
05-12-2007 15:19Ina SchieferdeckerNew Issue
05-12-2007 15:19Ina SchieferdeckerStatusnew => assigned
05-12-2007 15:19Ina SchieferdeckerAssigned To => Jens Grabowski
05-12-2007 15:19Ina SchieferdeckerClause Reference(s) => Part 1, Clause 8
05-12-2007 15:19Ina SchieferdeckerSource (company - Author) =>
05-12-2007 15:23Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
13-10-2008 18:31Ina SchieferdeckerNote Added: 0007049
13-10-2008 18:32Ina SchieferdeckerFile Added: ModuleInterfaces.ppt
14-10-2008 17:00Ina SchieferdeckerFile Added: ModuleInterfacesImplementation.ppt
26-11-2008 09:01Ina SchieferdeckerAssigned ToJens Grabowski => Ina Schieferdecker
26-11-2008 14:35Ina SchieferdeckerFile Added: CR2566_ModuleInterfaces.doc
26-11-2008 14:35Ina SchieferdeckerNote Added: 0007450
26-11-2008 14:35Ina SchieferdeckerAssigned ToIna Schieferdecker => Thomas Deiß
26-11-2008 14:35Ina SchieferdeckerResolutionopen => fixed
26-11-2008 17:15Thomas DeißFile Added: CR2566_ModuleInterfaces_v02.doc
26-11-2008 17:16Thomas DeißNote Added: 0007458
26-11-2008 17:16Thomas DeißAssigned ToThomas Deiß => Gyorgy Rethy
27-11-2008 13:51Gyorgy RethyFile Added: CR2566_ModuleInterfaces_v03.doc
27-11-2008 13:52Gyorgy RethyFile Added: CR2566 Resolution Part-7.doc
27-11-2008 13:53Gyorgy RethyNote Added: 0007471
27-11-2008 13:54Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
09-12-2008 15:33Ina SchieferdeckerStatusassigned => resolved
09-12-2008 15:33Ina SchieferdeckerFixed in Version => Edition 4.1.1 (not yet published)
09-12-2008 15:35Ina SchieferdeckerNote Added: 0007605
09-12-2008 15:35Ina SchieferdeckerStatusresolved => assigned
09-12-2008 15:35Ina SchieferdeckerAssigned ToIna Schieferdecker => Gyorgy Rethy
12-12-2008 09:35Ina SchieferdeckerProjectPart 01: TTCN-3 Core Language => Part 09: Using XML with TTCN-3
15-12-2008 10:29Gyorgy RethyNote Added: 0007703
15-12-2008 10:29Gyorgy RethyTarget VersionEdition 4.1.1 (not yet published) => Edition 4.2.1 (not yet published)
15-12-2008 10:29Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
16-12-2008 16:12Ina SchieferdeckerIssue cloned: 0004613
16-12-2008 16:12Ina SchieferdeckerRelationship addedparent of 0004613
16-12-2008 16:13Ina SchieferdeckerNote Added: 0007719
16-12-2008 16:13Ina SchieferdeckerStatusassigned => closed
16-12-2008 16:13Ina SchieferdeckerTarget VersionEdition 4.2.1 (not yet published) => Edition 4.1.1 (not yet published)
13-01-2009 11:30Ina SchieferdeckerFile Added: CR2566_ModuleInterfaces_v04.doc
14-02-2010 16:05Ina SchieferdeckerIssue cloned: 0005474
14-02-2010 16:05Ina SchieferdeckerRelationship addedparent of 0005474
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0007049) +
+ Ina Schieferdecker    +
+ 13-10-2008 18:31    +
+ 		+ + + + +
+ In order not to mix this CR up with the packaging of TTCN-3 as a language: this CR is rather about TTCN-3 libraries.
+
+
+
+ + + + + + + + + + +
+ (0007450) +
+ Ina Schieferdecker    +
+ 26-11-2008 14:35    +
+ 		+ + + + +
+ Uploaded a first draft - please check
+
+
+
+ + + + + + + + + + +
+ (0007458) +
+ Thomas Deiß    +
+ 26-11-2008 17:16    +
+ 		+ + + + +
+ some smaller issues found, nothing really serious.
+file with comments uploaded as version 02.
+Please check also.
+
+
+
+ + + + + + + + + + +
+ (0007471) +
+ Gyorgy Rethy    +
+ 27-11-2008 13:53    +
+ 		+ + + + +
+ In ~_v03: comment to module parameters deleted as discussed + plus editorial amendments. Also a sentence is added to Part-7 that all ASN.1 definitions are public. With those changes OK from my side.
+
+
+
+ + + + + + + + + + +
+ (0007605) +
+ Ina Schieferdecker    +
+ 09-12-2008 15:35    +
+ 		+ + + + +
+ Gyorgy, can you please add also a sentence to Part 9 for XML as the one you proposed for ASN.1
+
+We have to keep in mind that this should be added also to part 8 for IDL: if you did it for ASN.1 and XML, please move the CR to next year for the IDL change.
+
+
+
+ + + + + + + + + + +
+ (0007703) +
+ Gyorgy Rethy    +
+ 15-12-2008 10:29    +
+ 		+ + + + +
+ Done in parts 7 and 9. Moved to 2009 for part 8 (IDL).
+
+
+
+ + + + + + + + + + +
+ (0007719) +
+ Ina Schieferdecker    +
+ 16-12-2008 16:13    +
+ 		+ + + + +
+ Make a CR clone for the IDL handling - for the v4.1.1 this CR is closed.
+
+ + diff --git a/docs/mantis/CR2569.md b/docs/mantis/CR2569.md new file mode 100644 index 0000000000000000000000000000000000000000..be7ca353a7a3974cb957e6e387417696dad8059c --- /dev/null +++ b/docs/mantis/CR2569.md @@ -0,0 +1,63 @@ + + + + + + + + + + + + + 0002569: Character Set in a Module - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0002569Part 01: TTCN-3 Core LanguageNew Featurepublic05-12-2007 15:3409-12-2008 16:33
ReporterIna Schieferdecker 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)Part 1, Clause 5
Source (company - Author)     
Summary0002569: Character Set in a Module
DescriptionAlong the widespread use of TTCN-3 in various countries, we may reconsider to allow more general character sets in TTCN-3. This would also require to have an indication, which character set is being used in a module. Contrary we may stick to the solution that only comments are allowed to have free text only.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesppt CR_2569_2008-07-13.ppt (54,784) 14-08-2008 12:08
http://oldforge.etsi.org/mantis/file_download.php?file_id=1596&type=bug
doc CR2569 - resolution.doc (157,184) 27-11-2008 10:50
http://oldforge.etsi.org/mantis/file_download.php?file_id=1813&type=bug
Issue History
Date ModifiedUsernameFieldChange
05-12-2007 15:34Ina SchieferdeckerNew Issue
05-12-2007 15:34Ina SchieferdeckerStatusnew => assigned
05-12-2007 15:34Ina SchieferdeckerAssigned To => Jens Grabowski
05-12-2007 15:34Ina SchieferdeckerClause Reference(s) => Part 1, Clause 5
05-12-2007 15:34Ina SchieferdeckerSource (company - Author) =>
05-12-2007 15:35Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
15-07-2008 11:01Ina SchieferdeckerAssigned ToJens Grabowski => Gyorgy Rethy
14-08-2008 12:07Gyorgy RethyNote Added: 0006524
14-08-2008 12:08Gyorgy RethyFile Added: CR_2569_2008-07-13.ppt
27-11-2008 10:50Gyorgy RethyFile Added: CR2569 - resolution.doc
27-11-2008 10:51Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
09-12-2008 16:33Ina SchieferdeckerStatusassigned => resolved
09-12-2008 16:33Ina SchieferdeckerResolutionopen => fixed
09-12-2008 16:33Ina SchieferdeckerFixed in Version => Edition 4.1.1 (not yet published)
09-12-2008 16:33Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0006524) +
+ Gyorgy Rethy    +
+ 14-08-2008 12:07    +
+ 		+ + + + +
+ CR is discussed on 13/07/2008 based on slides in file CR_2569_2008-07-13.ppt; The discussion result is: if internationalization is introduced, is shall be UTF-8 with explicit transfer format identification. However, this may would have influence on existing tools -> ask tool vendors.
+
+ + diff --git a/docs/mantis/CR2571.md b/docs/mantis/CR2571.md new file mode 100644 index 0000000000000000000000000000000000000000..53e7ce8593d9aad7b6b1d6f4326d40c5868c4e80 --- /dev/null +++ b/docs/mantis/CR2571.md @@ -0,0 +1,109 @@ + + + + + + + + + + + + + 0002571: TCI operation in C mapping do not allow to leave out returnValues of replies - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0002571Part 06: TTCN-3 Control InterfaceTechnicalpublic05-12-2007 16:2312-12-2008 15:43
ReporterThomas Deiß 
Assigned ToIna Schieferdecker 
PrioritynormalSeveritymajorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.2.1 (published 2007-02) 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)9.2
Source (company - Author)     
Summary0002571: TCI operation in C mapping do not allow to leave out returnValues of replies
DescriptionIn the C mapping the operation
+void tciEnqueueReplyConnected
+ (TriPortId sender, TriComponentId receiver, TriSignatureId signature,
+  TciParameterListType parameterList, TciValue returnValue)
+requires to provide a returnValue. But how to do this for signatures that do not have a return value? There has to be a way to express that there is no returnValue.
+In IDL and Java, this can be handled by 'null'. But this does not seem to be possible in C.
+
+Proposed solution (which needs discussion) is to add an operator to TciValue to set a value to be absent. There is already an operation to check whether a value is present.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR_2571_TCI_operation_in_C_mapping_solution_01.doc (461,824) 13-03-2008 08:53
http://oldforge.etsi.org/mantis/file_download.php?file_id=1376&type=bug
Issue History
Date ModifiedUsernameFieldChange
05-12-2007 16:23Thomas DeißNew Issue
05-12-2007 16:23Thomas DeißStatusnew => assigned
05-12-2007 16:23Thomas DeißAssigned To => Thomas Deiß
05-12-2007 16:23Thomas DeißClause Reference(s) => 9.2
05-12-2007 16:23Thomas DeißSource (company - Author) =>
13-03-2008 08:53Thomas DeißFile Added: CR_2571_TCI_operation_in_C_mapping_solution_01.doc
13-03-2008 08:57Thomas DeißNote Added: 0005221
13-03-2008 08:57Thomas DeißAssigned ToThomas Deiß => Ina Schieferdecker
09-05-2008 10:35Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
16-10-2008 13:57Ina SchieferdeckerStatusassigned => resolved
16-10-2008 13:57Ina SchieferdeckerResolutionopen => fixed
12-12-2008 15:43Ina SchieferdeckerNote Added: 0007689
12-12-2008 15:43Ina SchieferdeckerStatusresolved => closed
12-12-2008 15:43Ina SchieferdeckerFixed in Version => Edition 4.1.1 (not yet published)
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0005221) +
+ Thomas Deiß    +
+ 13-03-2008 08:57    +
+ 		+ + + + +
+ STF 349, Thomas, solution proposal.
+Extend the value interface by two operations to explicitly set a value (of any type) to null and to check this.
+
+Alternatives:
+a) use omit instead of null (introduce an operation to set a value to omit), but this would mean to overload the meaning of omit.
+b) introduce a new type NULL, but this can be considered as more intrusive than the two additional operations.
+
+
+
+ + + + + + + + + + +
+ (0007689) +
+ Ina Schieferdecker    +
+ 12-12-2008 15:43    +
+ 		+ + + + +
+ ok
+
+ + diff --git a/docs/mantis/CR2576.md b/docs/mantis/CR2576.md new file mode 100644 index 0000000000000000000000000000000000000000..0b55198253b78289cbed9ae583f4f3ba3beb3bc3 --- /dev/null +++ b/docs/mantis/CR2576.md @@ -0,0 +1,99 @@ + + + + + + + + + + + + + 0002576: No separate section for recursive types - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0002576Part 01: TTCN-3 Core LanguageEditorialpublic06-12-2007 08:4212-03-2008 10:24
ReporterIna Schieferdecker 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv3.3.2 (published 2008-04)Fixed in Versionv3.3.2 (published 2008-04) 
Clause Reference(s)Part 1, Clause 6.2 and 6.2.8
Source (company - Author)FOKUS
Summary0002576: No separate section for recursive types
DescriptionSection 6 is about the various types in TTCN-3. It also has a section on recursive types - these are however not types as such - recursivity is just a property for structured types. Therefore I propose to move those two sentences from 6.2.8 to 6.2 so that it reads in 6.2:
+
+"The type keyword is also used to specify structured types such as record types, record of types, set types, set of types, enumerated types and union types. Where applicable structured type definitions may be recursive. The user, however, shall ensure that all type recursion is resolvable and that no infinite recursion occurs."
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
06-12-2007 08:42Ina SchieferdeckerNew Issue
06-12-2007 08:42Ina SchieferdeckerStatusnew => assigned
06-12-2007 08:42Ina SchieferdeckerAssigned To => Jens Grabowski
06-12-2007 08:42Ina SchieferdeckerClause Reference(s) => Part 1, Clause 6.2 and 6.2.8
06-12-2007 08:42Ina SchieferdeckerSource (company - Author) => FOKUS
06-12-2007 08:44Ina SchieferdeckerTarget Version => Edition 3.3.1 (not yet published)
06-12-2007 10:01Jens GrabowskiNote Added: 0004362
06-12-2007 10:01Jens GrabowskiResolutionopen => fixed
06-12-2007 10:03Jens GrabowskiAssigned ToJens Grabowski => Ina Schieferdecker
06-12-2007 15:35Ina SchieferdeckerStatusassigned => resolved
06-12-2007 15:35Ina SchieferdeckerStatusresolved => closed
06-12-2007 15:35Ina SchieferdeckerNote Added: 0004380
06-12-2007 15:35Ina SchieferdeckerFixed in Version => Edition 3.3.1 (not yet published)
12-03-2008 10:22user10Fixed in VersionEdition 3.3.1 --will not be published, see 3.3.2 => Edition 3.3.2 (not yet published)
12-03-2008 10:24user10Target VersionEdition 3.3.1 --will not be published, see 3.3.2 => Edition 3.3.2 (not yet published)
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0004362) +
+ Jens Grabowski    +
+ 06-12-2007 10:01    +
+ 		+ + + + +
+ Proposa is OK. For the procedure, please check with György, if 6.2.8 can be removed completely, or if it needs to be kept as empty section.
+
+
+
+ + + + + + + + + + +
+ (0004380) +
+ Ina Schieferdecker    +
+ 06-12-2007 15:35    +
+ 		+ + + + +
+ Discussed with Gyorgy: section can be removed.
+
+ + diff --git a/docs/mantis/CR2578.md b/docs/mantis/CR2578.md new file mode 100644 index 0000000000000000000000000000000000000000..48c8d97a6076233c5d5fb8ea7fbc87252adc93e1 --- /dev/null +++ b/docs/mantis/CR2578.md @@ -0,0 +1,211 @@ + + + + + + + + + + + + + 0002578: Break-like construct for altsteps - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 04: TTCN-3 Operational Semantics
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0002578Part 04: TTCN-3 Operational SemanticsNew Featurepublic06-12-2007 11:1720-04-2009 11:43
ReporterJens Grabowski 
Assigned ToGyorgy Rethy 
PrioritynormalSeveritymajorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)New Section on Break and Continue
Source (company - Author) University of Göttingen, Jens Grabowski
Summary0002578: Break-like construct for altsteps
DescriptionAn altstep is evaluated within an alt-statement. Currently it is not possible to leave the alt-statement from within the altstep. A construct which will allow this is more than a break-statement, because a break is an unconditional jump to a known place (i.e., a goto-label-construct).
+
+The technical study of a break-like construct for altsteps should consider that altsteps
+- are introduced/used as functions and not as macros,
+- have scope,
+- may have in, inout and out parameters,
+- can activated as defaults.
+
+This CR was originally part of CR 414.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR-2578-Break-for-altsteps-Resolution-V1.doc (384,000) 16-12-2008 16:50
http://oldforge.etsi.org/mantis/file_download.php?file_id=1904&type=bug
doc CR-2578-Break-for-altsteps-Resolution-V2.doc (386,560) 16-12-2008 20:23
http://oldforge.etsi.org/mantis/file_download.php?file_id=1905&type=bug
doc CR2578-Part-4-Break-like-construct-for-altsteps-Resolution-JG-V1.doc (448,000) 02-01-2009 15:09
http://oldforge.etsi.org/mantis/file_download.php?file_id=1933&type=bug
Issue History
Date ModifiedUsernameFieldChange
06-12-2007 11:17Jens GrabowskiNew Issue
06-12-2007 11:17Jens GrabowskiStatusnew => assigned
06-12-2007 11:17Jens GrabowskiAssigned To => Jens Grabowski
06-12-2007 11:17Jens GrabowskiClause Reference(s) => New Section on Break and Continue
06-12-2007 11:17Jens GrabowskiSource (company - Author) => University of Göttingen, Jens Grabowski
06-12-2007 11:35Jens GrabowskiProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
13-03-2008 18:13Thomas DeißNote Added: 0005227
21-04-2008 08:59Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
16-12-2008 16:50Jens GrabowskiFile Added: CR-2578-Break-for-altsteps-Resolution-V1.doc
16-12-2008 16:51Jens GrabowskiNote Added: 0007720
16-12-2008 16:52Jens GrabowskiAssigned ToJens Grabowski => Thomas Deiß
16-12-2008 16:52Jens GrabowskiStatusassigned => resolved
16-12-2008 20:22Thomas DeißNote Added: 0007721
16-12-2008 20:22Thomas DeißAssigned ToThomas Deiß => Jens Grabowski
16-12-2008 20:22Thomas DeißStatusresolved => assigned
16-12-2008 20:23Thomas DeißFile Added: CR-2578-Break-for-altsteps-Resolution-V2.doc
17-12-2008 07:39Ina SchieferdeckerAssigned ToJens Grabowski => Ina Schieferdecker
17-12-2008 07:39Ina SchieferdeckerResolutionopen => fixed
17-12-2008 09:31Ina SchieferdeckerNote Added: 0007726
17-12-2008 09:32Ina SchieferdeckerNote Added: 0007727
17-12-2008 09:32Ina SchieferdeckerProjectPart 01: TTCN-3 Core Language => Part 04: TTCN-3 Operational Semantics
17-12-2008 09:32Ina SchieferdeckerAssigned ToIna Schieferdecker => Jens Grabowski
17-12-2008 09:32Ina SchieferdeckerFixed in Version => Edition 4.1.1 (not yet published)
02-01-2009 15:04Jens GrabowskiFile Added: 2578-Part-4-Break-like-construct-for-altsteps-Resolution-JG-V1.doc
02-01-2009 15:05Jens GrabowskiFile Deleted: 2578-Part-4-Break-like-construct-for-altsteps-Resolution-JG-V1.doc
02-01-2009 15:09Jens GrabowskiFile Added: CR2578-Part-4-Break-like-construct-for-altsteps-Resolution-JG-V1.doc
02-01-2009 15:09Jens GrabowskiAssigned ToJens Grabowski => Gyorgy Rethy
10-03-2009 10:50Ina SchieferdeckerStatusassigned => resolved
20-04-2009 11:43Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0005227) +
+ Thomas Deiß    +
+ 13-03-2008 18:13    +
+ 		+ + + + +
+ check note in 19.10, about return statement in an altstep. A statement block after an altstep would still be executed. Check also part4 on the return statement.
+
+Thomas to produce some clarifying examples.
+
+
+
+ + + + + + + + + + +
+ (0007720) +
+ Jens Grabowski    +
+ 16-12-2008 16:51    +
+ 		+ + + + +
+ The attached file includes the changes required in part 1 for resolving this issue. I do find places in the BNF that need to be changed. This has to be cross-checked by someone else.
+
+
+
+ + + + + + + + + + +
+ (0007721) +
+ Thomas Deiß    +
+ 16-12-2008 20:22    +
+ 		+ + + + +
+ No change to BNF needed.
+
+Two issues for clarification found. Comments and proposals are in uploaded version V2.
+
+
+
+ + + + + + + + + + +
+ (0007726) +
+ Ina Schieferdecker    +
+ 17-12-2008 09:31    +
+ 		+ + + + +
+ Changes in part 1 done - as Jens proposes despite the comment by Thomas on altsteps as altsteps within loops should behave as alts within loops.
+
+
+
+ + + + + + + + + + +
+ (0007727) +
+ Ina Schieferdecker    +
+ 17-12-2008 09:32    +
+ 		+ + + + +
+ Changes in part 4 needed - hence moved there.
+
+ + diff --git a/docs/mantis/CR2580.md b/docs/mantis/CR2580.md new file mode 100644 index 0000000000000000000000000000000000000000..356797a9566a11d958c90b1185c377006ffe0f45 --- /dev/null +++ b/docs/mantis/CR2580.md @@ -0,0 +1,37 @@ + + + + + + + + + + + + + 0002580: char keyword/char useful type clash - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0002580Part 01: TTCN-3 Core LanguageEditorialpublic06-12-2007 13:1612-03-2008 10:24
ReporterIna Schieferdecker 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv3.3.2 (published 2008-04)Fixed in Versionv3.3.2 (published 2008-04) 
Clause Reference(s)Part 1, Annex D, D2.4.1
Source (company - Author)     
Summary0002580: char keyword/char useful type clash
Description"char" is both a keyword (to denote universal characters in universal character strings in quadruple form) and a useful type.
+
+Although there is an explicite note for this clash, the BNF is in conflict - it requires an identifier for type definitions and does not allow keywords.
+
+Therefore it is proposed to rename the useful type to char646:
+
+    type charstring char646 length (1);
+
+And to remove NOTE 1 in D2.4.1
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
06-12-2007 13:16Ina SchieferdeckerNew Issue
06-12-2007 13:16Ina SchieferdeckerStatusnew => assigned
06-12-2007 13:16Ina SchieferdeckerAssigned To => Jens Grabowski
06-12-2007 13:16Ina SchieferdeckerClause Reference(s) => Part 1, Annex D, D2.4.1
06-12-2007 13:16Ina SchieferdeckerSource (company - Author) =>
06-12-2007 13:17Ina SchieferdeckerTarget Version => Edition 3.3.1 (not yet published)
06-12-2007 15:53Jens GrabowskiAssigned ToJens Grabowski => Ina Schieferdecker
06-12-2007 15:53Jens GrabowskiStatusassigned => resolved
06-12-2007 15:53Jens GrabowskiResolutionopen => fixed
06-12-2007 16:03Ina SchieferdeckerStatusresolved => closed
06-12-2007 16:03Ina SchieferdeckerFixed in Version => Edition 3.3.1 (not yet published)
12-03-2008 10:22user10Fixed in VersionEdition 3.3.1 --will not be published, see 3.3.2 => Edition 3.3.2 (not yet published)
12-03-2008 10:24user10Target VersionEdition 3.3.1 --will not be published, see 3.3.2 => Edition 3.3.2 (not yet published)
+
+ + + + +
+ There are no notes attached to this issue.
+ + diff --git a/docs/mantis/CR2587.md b/docs/mantis/CR2587.md new file mode 100644 index 0000000000000000000000000000000000000000..640180ffb18675ef700152e9064c4dad68c7c744 --- /dev/null +++ b/docs/mantis/CR2587.md @@ -0,0 +1,65 @@ + + + + + + + + + + + + + 0002587: editorial corrections in text - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0002587Part 01: TTCN-3 Core LanguageEditorialpublic07-12-2007 09:0312-03-2008 10:24
ReporterThomas Deiß 
Assigned ToIna Schieferdecker 
PrioritylowSeveritytextReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv3.3.2 (published 2008-04)Fixed in Versionv3.3.2 (published 2008-04) 
Clause Reference(s)10.1, 16.1.3, 20.5, 20.5.1,
Source (company - Author)     
Summary0002587: editorial corrections in text
Descriptiona few typos found in the text.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Fileszip es_20187301v030201p_editorial.zip (880,197) 07-12-2007 09:03
http://oldforge.etsi.org/mantis/file_download.php?file_id=1249&type=bug
Issue History
Date ModifiedUsernameFieldChange
07-12-2007 09:03Thomas DeißNew Issue
07-12-2007 09:03Thomas DeißStatusnew => assigned
07-12-2007 09:03Thomas DeißAssigned To => Thomas Deiß
07-12-2007 09:03Thomas DeißFile Added: es_20187301v030201p_editorial.zip
07-12-2007 09:03Thomas DeißClause Reference(s) => 10.1, 16.1.3, 20.5, 20.5.1,
07-12-2007 09:03Thomas DeißSource (company - Author) =>
07-12-2007 09:05Thomas DeißAssigned ToThomas Deiß => Ina Schieferdecker
07-12-2007 09:05Thomas DeißResolutionopen => fixed
07-12-2007 10:12Ina SchieferdeckerProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
07-12-2007 10:12Ina SchieferdeckerTarget Version => Edition 3.3.1 (not yet published)
07-12-2007 10:45Ina SchieferdeckerStatusassigned => closed
07-12-2007 10:45Ina SchieferdeckerNote Added: 0004418
07-12-2007 10:45Ina SchieferdeckerFixed in Version => Edition 3.3.1 (not yet published)
12-03-2008 10:22user10Fixed in VersionEdition 3.3.1 --will not be published, see 3.3.2 => Edition 3.3.2 (not yet published)
12-03-2008 10:24user10Target VersionEdition 3.3.1 --will not be published, see 3.3.2 => Edition 3.3.2 (not yet published)
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0004418) +
+ Ina Schieferdecker    +
+ 07-12-2007 10:45    +
+ 		+ + + + +
+ Even, external constants cannot have array defs ... this also to be removed.
+
+The other corrections are implemented.
+
+ + diff --git a/docs/mantis/CR2589.md b/docs/mantis/CR2589.md new file mode 100644 index 0000000000000000000000000000000000000000..37a2381721c83cdca93d6aa19b75ad343cdfd715 --- /dev/null +++ b/docs/mantis/CR2589.md @@ -0,0 +1,448 @@ + + + + + + + + + + + + + 0002589: Arrays as types - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0002589Part 06: TTCN-3 Control InterfaceClarificationpublic07-12-2007 10:0912-12-2008 13:08
ReporterThomas Deiß 
Assigned ToIna Schieferdecker 
PrioritynormalSeveritymajorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.2.1 (published 2007-02) 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)6.2.7
Source (company - Author)     
Summary0002589: Arrays as types
DescriptionThere is a contradiction:
+
+Clause 6.2.7 states: In common with many programming languages, arrays are not considered to be types in TTCN‑3. Instead, they may be specified at the point of a variable declaration.
+
+But the BNF states
+48. SubTypeDef ::= Type (SubTypeIdentifier | AddressKeyword) [ArrayDef] [SubTypeSpec]
+
+It is unclear whether the
+module m {
+type integer I[2];
+}
+is correct or not.
+
+This has been discussed within STF 337 and it is proposed to consider arrays as types and that this should be introduced as shorthand notation for record of.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR_2589_Arrays_as_types_solution_part1_01.doc (1,803,264) 25-04-2008 12:54
http://oldforge.etsi.org/mantis/file_download.php?file_id=1458&type=bug
doc CR_2589_Arrays_as_types_solution_part6_01.doc (136,192) 25-04-2008 12:55
http://oldforge.etsi.org/mantis/file_download.php?file_id=1459&type=bug
pdf record_of_with_offset.pdf (141,217) 25-04-2008 12:55
http://oldforge.etsi.org/mantis/file_download.php?file_id=1460&type=bug
doc CR_2589_Arrays_as_types_solution_part1_02.doc (1,805,824) 15-08-2008 10:46
http://oldforge.etsi.org/mantis/file_download.php?file_id=1609&type=bug
doc CR_2589_Arrays_as_types_solution_part6_02.doc (250,880) 25-11-2008 09:59
http://oldforge.etsi.org/mantis/file_download.php?file_id=1767&type=bug
doc CR_2589_Arrays_as_types_solution_part6_03.doc (389,632) 25-11-2008 10:17
http://oldforge.etsi.org/mantis/file_download.php?file_id=1769&type=bug
doc CR_2589_Arrays_as_types_solution_part1_03.doc (1,809,408) 10-12-2008 15:41
http://oldforge.etsi.org/mantis/file_download.php?file_id=1883&type=bug
Issue History
Date ModifiedUsernameFieldChange
07-12-2007 10:09Thomas DeißNew Issue
07-12-2007 10:09Thomas DeißStatusnew => assigned
07-12-2007 10:09Thomas DeißAssigned To => Ina Schieferdecker
07-12-2007 10:09Thomas DeißClause Reference(s) => 6.2.7
07-12-2007 10:09Thomas DeißSource (company - Author) =>
07-12-2007 10:10Thomas DeißAssigned ToIna Schieferdecker => Thomas Deiß
07-12-2007 10:10Thomas DeißTarget Version => Edition 4.1.1 (not yet published)
25-04-2008 12:54Thomas DeißFile Added: CR_2589_Arrays_as_types_solution_part1_01.doc
25-04-2008 12:55Thomas DeißFile Added: CR_2589_Arrays_as_types_solution_part6_01.doc
25-04-2008 12:55Thomas DeißFile Added: record_of_with_offset.pdf
25-04-2008 12:57Thomas DeißNote Added: 0005577
25-04-2008 12:57Thomas DeißAssigned ToThomas Deiß => Gyorgy Rethy
15-08-2008 10:46Gyorgy RethyFile Added: CR_2589_Arrays_as_types_solution_part1_02.doc
15-08-2008 10:46Gyorgy RethyAssigned ToGyorgy Rethy => Thomas Deiß
15-08-2008 10:47Gyorgy RethyNote Added: 0006541
29-09-2008 06:48Thomas DeißNote Added: 0006919
25-11-2008 09:59Thomas DeißFile Added: CR_2589_Arrays_as_types_solution_part6_02.doc
25-11-2008 10:00Thomas DeißNote Added: 0007399
25-11-2008 10:00Thomas DeißAssigned ToThomas Deiß => Ina Schieferdecker
25-11-2008 10:17Thomas DeißFile Added: CR_2589_Arrays_as_types_solution_part6_03.doc
25-11-2008 10:18Thomas DeißNote Added: 0007401
10-12-2008 15:30Ina SchieferdeckerNote Added: 0007641
10-12-2008 15:31Ina SchieferdeckerResolutionopen => fixed
10-12-2008 15:31Ina SchieferdeckerFixed in Version => Edition 4.1.1 (not yet published)
10-12-2008 15:36Ina SchieferdeckerNote Edited: 0007641
10-12-2008 15:41Ina SchieferdeckerFile Added: CR_2589_Arrays_as_types_solution_part1_03.doc
10-12-2008 15:41Ina SchieferdeckerAssigned ToIna Schieferdecker => Thomas Deiß
11-12-2008 10:37Thomas DeißNote Added: 0007649
11-12-2008 10:37Thomas DeißAssigned ToThomas Deiß => Ina Schieferdecker
12-12-2008 07:42Ina SchieferdeckerNote Added: 0007664
12-12-2008 07:43Ina SchieferdeckerStatusassigned => resolved
12-12-2008 07:43Ina SchieferdeckerNote Added: 0007665
12-12-2008 07:43Ina SchieferdeckerProjectPart 01: TTCN-3 Core Language => Part 06: TTCN-3 Control Interface
12-12-2008 13:08Ina SchieferdeckerNote Added: 0007682
12-12-2008 13:08Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0005577) +
+ Thomas Deiß    +
+ 25-04-2008 12:57    +
+ 		+ + + + +
+ initial proposal,
+to be crosschecked. Some arguments _not_ to introduce offset notation for record of/set of.
+Part 6: Just state that an array is of type class RECORD_OF
+
+
+
+ + + + + + + + + + +
+ (0006541) +
+ Gyorgy Rethy    +
+ 15-08-2008 10:47    +
+ 		+ + + + +
+ Checked, there are some changes/comments to be cross-checked
+
+
+
+ + + + + + + + + + +
+ (0006919) +
+ Thomas Deiß    +
+ 29-09-2008 06:48    +
+ 		+ + + + +
+ Gyorgy's comments are fine for me.
+
+Following comment regarding part 6 received from TestingTech (Valentin):
+"Regarding the TCI, we think that the difference mentioned before should be visible also at this level, i.e. we would prefer to introduce a different type class for arrays. In addition, the interface RecordOfValue should provide a
+getOffset() method to access the offset in case of arrays. In case the value is a record of/set of, the method must return 0. Such a method is necessary for example for a logging implementation which wants to log arrays together with their indexes like they exist in TTCN-3. The two methods
+getField()/setField() may use for all 3 type classes indexes (RECORD_OF, SET_OF and ARRAY) from 0 to length-1, as proposed."
+
+
+
+ + + + + + + + + + +
+ (0007399) +
+ Thomas Deiß    +
+ 25-11-2008 10:00    +
+ 		+ + + + +
+ part 6 updated according to feedback by TestingTechnologies: separate type class for arrays introduced, operator getOffset for recordof, setof, array introduced.
+v02 uploaded.
+
+
+
+
+ + + + + + + + + + +
+ (0007401) +
+ Thomas Deiß    +
+ 25-11-2008 10:18    +
+ 		+ + + + +
+ new operation and new type class added to language mappings in part6.
+Needs to be done also for C++ language mapping.
+uploaded v03
+
+
+
+ + + + + + + + + + +
+ (0007641) +
+ Ina Schieferdecker    +
+ 10-12-2008 15:30    +
(edited on: 10-12-2008 15:36)
+ 		+ + + + +
+ Corrected example in 6.2.7:
+
+ "type record length (3) of integer MyRecordOfType1"
+
+etc.
+
+Extending the example with some compatibility hints:
+
+" type integer MyArrayType1[3]; // A type with 3 integer elements
+    type record length (3) of integer MyRecordOfType1; // The corresponding record of
+
+    var MyArrayType1 a1;
+    var MyRecordOfType1 r1:= a1; // MyArrayType1 and MyRecordOfType1 are compatible
+
+    var integer myArray1[3]:= r1; // Instantiates an integer array of 3 elements
+                                    // with the index 0 to 2
+                                    // being compatible to MyArrayType1 and MyRecordOfType1
+"
+
+Array type definition not needed as already included in SubTypeDef rule.
+
+Please check
+
+
+
+
+
+ + + + + + + + + + +
+ (0007649) +
+ Thomas Deiß    +
+ 11-12-2008 10:37    +
+ 		+ + + + +
+ Regarding the example:
+
+I suggest to add an initial value to the variable in the example.
+var MyArrayType1 a1 := { 7, 8, 9 };
+
+In the next line after the variable declaration, the variable a1 is used on the right hand side. This might raise questions if a1 is not initialized.
+
+Regarding the grammar:
+Without the specific rule there will be no nested array definitions. But this would be fine for me.
+
+
+
+ + + + + + + + + + +
+ (0007664) +
+ Ina Schieferdecker    +
+ 12-12-2008 07:42    +
+ 		+ + + + +
+ Also nested arrays are possible like in
+
+type record NR{
+ integer f1[3],
+ record {boolean b1, boolean b2} f2[5],
+ enumerated {red,blue} f3[10]
+}
+
+See
+
+23. StructFieldDef ::= (Type | NestedTypeDef) StructFieldIdentifier [ArrayDef] [SubTypeSpec]
+                       [OptionalKeyword]
+
+Hence, we do not need an additional definition for arrays.
+
+
+
+ + + + + + + + + + +
+ (0007665) +
+ Ina Schieferdecker    +
+ 12-12-2008 07:43    +
+ 		+ + + + +
+ Resolved in part 1, to be resolved also in part 6
+
+
+
+ + + + + + + + + + +
+ (0007682) +
+ Ina Schieferdecker    +
+ 12-12-2008 13:08    +
+ 		+ + + + +
+ One correction for part 6: the Java mapping for the offset is
+
+    public int getOffset() ;
+
+Added also the definition for the C++ mapping
+
+    virtual Tindex getOffset() const =0;
+
+And array constant for type class
+
+        TciTypeClass TCI_ARRAY
+        Type safe enumerated TCI_ARRAY
+
+ + diff --git a/docs/mantis/CR2590.md b/docs/mantis/CR2590.md new file mode 100644 index 0000000000000000000000000000000000000000..cd8f79cb298ce8bced74f19ff2578a6e5a48acb2 --- /dev/null +++ b/docs/mantis/CR2590.md @@ -0,0 +1,134 @@ + + + + + + + + + + + + + 0002590: parameterization of signatures - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0002590Part 01: TTCN-3 Core LanguageClarificationpublic07-12-2007 10:2024-11-2008 11:15
ReporterThomas Deiß 
Assigned ToIna Schieferdecker 
PrioritylowSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.2.1 (published 2007-02) 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)5.4
Source (company - Author)     
Summary0002590: parameterization of signatures
DescriptionThe table in 5.4 states that signatures can be parameterized dynamically. But signatures can be parameterized statically only, similar to types.
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0003955closed Ina Schieferdecker Text ""TTCN-3 supports value, template, timer and port parameterization” is misleading 
Attached Filesdoc CR_parameterization_of_signatures_solution_01.doc (169,472) 12-03-2008 16:28
http://oldforge.etsi.org/mantis/file_download.php?file_id=1371&type=bug
doc CR_parameterization_of_signatures_solution_01-3.doc (157,184) 14-08-2008 14:27
http://oldforge.etsi.org/mantis/file_download.php?file_id=1602&type=bug
doc CR_parameterization_of_signatures_solution_01-4.doc (157,696) 14-08-2008 14:40
http://oldforge.etsi.org/mantis/file_download.php?file_id=1603&type=bug
Issue History
Date ModifiedUsernameFieldChange
07-12-2007 10:20Thomas DeißNew Issue
07-12-2007 10:20Thomas DeißStatusnew => assigned
07-12-2007 10:20Thomas DeißAssigned To => Ina Schieferdecker
07-12-2007 10:20Thomas DeißClause Reference(s) => 5.4
07-12-2007 10:20Thomas DeißSource (company - Author) =>
07-12-2007 10:21Thomas DeißAssigned ToIna Schieferdecker => Thomas Deiß
07-12-2007 10:21Thomas DeißTarget Version => Edition 4.1.1 (not yet published)
12-03-2008 16:27Thomas DeißNote Added: 0005217
12-03-2008 16:28Thomas DeißFile Added: CR_parameterization_of_signatures_solution_01.doc
12-03-2008 16:28Thomas DeißAssigned ToThomas Deiß => Ina Schieferdecker
14-08-2008 14:27Ina SchieferdeckerNote Added: 0006534
14-08-2008 14:27Ina SchieferdeckerResolutionopen => fixed
14-08-2008 14:27Ina SchieferdeckerFile Added: CR_parameterization_of_signatures_solution_01-3.doc
14-08-2008 14:28Ina SchieferdeckerAssigned ToIna Schieferdecker => Thomas Deiß
14-08-2008 14:40Thomas DeißFile Added: CR_parameterization_of_signatures_solution_01-4.doc
14-08-2008 14:41Thomas DeißNote Added: 0006535
14-08-2008 14:41Thomas DeißAssigned ToThomas Deiß => Ina Schieferdecker
24-11-2008 11:14Ina SchieferdeckerStatusassigned => resolved
24-11-2008 11:15Ina SchieferdeckerStatusresolved => closed
24-11-2008 11:15Ina SchieferdeckerFixed in Version => Edition 4.1.1 (not yet published)
09-12-2008 10:24Ina SchieferdeckerRelationship addedrelated to 0003955
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0005217) +
+ Thomas Deiß    +
+ 12-03-2008 16:27    +
+ 		+ + + + +
+ STF 349, Thomas, proposed solution.
+Just get rid of a few references of parameters of signatures.
+
+
+
+ + + + + + + + + + +
+ (0006534) +
+ Ina Schieferdecker    +
+ 14-08-2008 14:27    +
+ 		+ + + + +
+ CR is ok, but propose to add a note about signatures to the table - see attachment.
+
+
+
+ + + + + + + + + + +
+ (0006535) +
+ Thomas Deiß    +
+ 14-08-2008 14:41    +
+ 		+ + + + +
+ Note to table changed together with Ina.
+New resolution uploaded
+
+ + diff --git a/docs/mantis/CR2743.md b/docs/mantis/CR2743.md new file mode 100644 index 0000000000000000000000000000000000000000..9d5634f5149d992eea6366c124ac59aec1c90012 --- /dev/null +++ b/docs/mantis/CR2743.md @@ -0,0 +1,124 @@ + + + + + + + + + + + + + 0002743: Editorial comments to Part-1 v3.3 on approval - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0002743Part 01: TTCN-3 Core LanguageEditorialpublic22-01-2008 12:0812-03-2008 16:53
ReporterGyorgy Rethy 
Assigned To 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv3.3.2 (published 2008-04)Fixed in Versionv3.3.2 (published 2008-04) 
Clause Reference(s)See descrition
Source (company - Author)Ericsson - Gyorgy Rethy
Summary0002743: Editorial comments to Part-1 v3.3 on approval
DescriptionClause 6.1.1, example 4 ; editorial
+The example may be misleading/insufficient as only the explanation is given but no TTCN-3 code. Add a TTCN-3 example, e.g.
+var charstring vl_char:= """ab""cd""";
+
+Clause 6.2.1.3, example; editorial
+Intendations of "outerField1" and "enumerated " are mismatched.
+
+Clause 6.2.10.1, editorial
+Bookmark to the figure number is missing.
+
+Clause 8.2.3.6, editorial
+References to Annex H should be Annex G
+
+Part-10 do not specify any language strings and Part-9 is currently a draft.
+
+Clause 9.2; editorial
+The bookmark to the clause number does not includes "2".
+
+Clause 19.3, restrictions; editorial
+Unneded double quote after SingleExpression
+
+Clause 19.12 The Break statement; editorial
+Word comment [RGy1] to be deleted
+
+Clause 9.12 The Continue statement; editorial
+Should be clause 19.13.
+
+Clause 20.2, Continue execution after the alt statement; editorial
+"and the the branch": one "the" to be deleted
+
+Clause 20.5.2, restriction a); editorial
+Clause reference (the bookmark referenced) is missing.
+
+Clause 21.2.1, Semantic Description; editorial
+Clause reference (the bookmark referenced) is missing.
+
+Clause 21.2.3, Semantic Description; editorial
+Wrong clause reference (shall be 24 instead of 25).
+The sentence after Note 2 ("The rules for the termination of test cases...") is out of context. Either delete is (proposed) or add as a new note after the paragraph "If the stopped test component is the MTC,…"
+
+Clause 23.5, Syntactical Structure; editorial
+"all timer" shall be "any timer"
+
+Clause 23.6, Syntactical Structure; editorial
+“running” shall be “timeout”
+
+Clause C.36; editorial
+Bookmark to the clause reference includes the last sentence of C.35 but does not include "6". This causes a mismatched sentence in clause 6.2.4
+
+Clause C.37; editorial
+The second sentence may be misleading, especially in case of templates. Replace “contains only concrete values” by “resolves to a specific value” (the proposed text is copied from the clause spefifying valueof). Templates are not values, hence cannot “contain” values. But even more important that “omit” in an optional field is not a value of the field (which is e.g. of integer type) but an attribute of the field itself. Also a few more examples are added showing templates that are matching a single value only by using other mathing mechanisms than specific value and isvalue is returning false (some explanations are also added to the examples). Also an example is added to the record-set examples, showing that
+
+Clause C.37, error causes text & EXAMPLE 4 ; editorials
+“Note that this rule apply for any levels of embedding.” -> “Note that this rule applies for any levels of embedding.”
+Example 4: Unneded spaces in “ts_ MyUnion” & “tr_ MyUnion” makes the example invalid; delete the spaces in all occuances.
+
+Annex G; editorial
+Add reference to ETSI ES 201 873-1 (V3.2.1).
+Add “draft” to the reference of ETSI ES 201 873-9.
+
+
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
22-01-2008 12:08Gyorgy RethyNew Issue
22-01-2008 12:08Gyorgy RethyClause Reference(s) => See descrition
22-01-2008 12:08Gyorgy RethySource (company - Author) => Ericsson - Gyorgy Rethy
22-01-2008 13:52user10ProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
22-01-2008 14:02user10Statusnew => resolved
22-01-2008 14:02user10Resolutionopen => fixed
22-01-2008 14:02user10Fixed in Version => Edition 3.3.2 (not yet published)
22-01-2008 14:02user10Target Version => Edition 3.3.2 (not yet published)
12-03-2008 16:53Ina SchieferdeckerStatusresolved => closed
12-03-2008 16:53Ina SchieferdeckerNote Added: 0005218
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0005218) +
+ Ina Schieferdecker    +
+ 12-03-2008 16:53    +
+ 		+ + + + +
+ As proposed
+
+ + diff --git a/docs/mantis/CR2744.md b/docs/mantis/CR2744.md new file mode 100644 index 0000000000000000000000000000000000000000..0ab7f2ef3ba66e79e44ace160ee2a9cbe86b0e96 --- /dev/null +++ b/docs/mantis/CR2744.md @@ -0,0 +1,81 @@ + + + + + + + + + + + + + 0002744: Technical comments to Part-1 v3.3 on approval - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0002744Part 01: TTCN-3 Core LanguageTechnicalpublic22-01-2008 12:1212-03-2008 16:54
ReporterGyorgy Rethy 
Assigned To 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv3.3.2 (published 2008-04)Fixed in Versionv3.3.2 (published 2008-04) 
Clause Reference(s)See description
Source (company - Author)Ericsson - Gyorgy Rethy
Summary0002744: Technical comments to Part-1 v3.3 on approval
DescriptionClause 6.3.2.2; minor technical
+Examples of MyVarA := MyVarB; and MyVarC := MyVarB; are incorrect, the new value of the fields "a" and "d" is omit and not <undefined>
+
+Clause 7 note, minor technical
+the term "concrete value" is not defined and may be misinterpreted in some cases (e.g. structured types of several hierarchies). Use the term completely initialized instead.
+
+Clause 8.2.3.6, minor technical
+The language string 'TTCN­3:2005' should not refer to "this" version but version v3.2.1. A new language string 'TTCN­3:2008' shall be specified for "this" version.
+
+Clause 15.9; minor technical
+Change the undefined term "concrete value" to "specific value".
+
+Clause E.1.2, figure E.3; technical
+The wrong figure is used for alive-type PTCs (the same as for non-alive PTCs). Also in v3.2.1 wrong figure was used, the figure from v3.1.1 is copied to the attached corrected version.
+
+General, technical
+Considering the proposed syntax for template restrictions we propose to use brackets () instead of curly brackets {}. Curly brackets are used for statement-blocks and alike (e.g. structured type & structured template/value bodies), while brackets are used for several purposes, among them type restrictions, value lists etc. that are more similar to template restriction. From the editing point of view changes are required in $$5.4.1.2(two places), 11.2 and annex A (rule 514).
+
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
22-01-2008 12:12Gyorgy RethyNew Issue
22-01-2008 12:12Gyorgy RethyClause Reference(s) => See description
22-01-2008 12:12Gyorgy RethySource (company - Author) => Ericsson - Gyorgy Rethy
22-01-2008 13:52user10ProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
22-01-2008 14:01user10Statusnew => acknowledged
22-01-2008 14:01user10Resolutionopen => fixed
22-01-2008 14:01user10Fixed in Version => Edition 3.3.2 (not yet published)
22-01-2008 14:01user10Target Version => Edition 3.3.2 (not yet published)
22-01-2008 14:01user10Statusacknowledged => resolved
22-01-2008 14:01user10Assigned To => user10
22-01-2008 14:03user10Assigned Touser10 =>
12-03-2008 16:54Ina SchieferdeckerStatusresolved => closed
12-03-2008 16:54Ina SchieferdeckerNote Added: 0005219
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0005219) +
+ Ina Schieferdecker    +
+ 12-03-2008 16:54    +
+ 		+ + + + +
+ As proposed.
+
+ + diff --git a/docs/mantis/CR2745.md b/docs/mantis/CR2745.md new file mode 100644 index 0000000000000000000000000000000000000000..d9f88a5d2e742d48acbed294366441a3f95501b9 --- /dev/null +++ b/docs/mantis/CR2745.md @@ -0,0 +1,78 @@ + + + + + + + + + + + + + 0002745: Editorial comments to Part-7 v3.3 on approval - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 07: Using ASN.1 with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0002745Part 07: Using ASN.1 with TTCN-3Editorialpublic22-01-2008 12:1812-03-2008 16:54
ReporterGyorgy Rethy 
Assigned To 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv3.3.2 (published 2008-04)Fixed in Versionv3.3.2 (published 2008-04) 
Clause Reference(s)See description
Source (company - Author)Ericsson - Gyorgy Rethy
Summary0002745: Editorial comments to Part-7 v3.3 on approval
DescriptionClause 4; editorial
+“This is This part of the standard”. Delete ““This is “.
+
+Clause 7.2.2; editorial
+Missing clause no. reference (bookmark is missing).
+
+Clause 7.2.4.3, first sentence; editorial
+“...for objid templates too,.” Delete comma.
+
+Clause , first sentence of last paragraph; editorial
+“When importing ASN.1 types, values and value sets, first they have to transformed...”; add “be” before “transformed”.
+
+Clause 10, first sentence; editorial
+“It is permitted to reference parameterized ASN.1 type and value definitions from with the TTCN-3 module.”; change “with” to “within”.
+
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
22-01-2008 12:18Gyorgy RethyNew Issue
22-01-2008 12:18Gyorgy RethyClause Reference(s) => See description
22-01-2008 12:18Gyorgy RethySource (company - Author) => Ericsson - Gyorgy Rethy
22-01-2008 13:52user10ProjectTTCN-3 Change Requests => Part 07: Using ASN.1 with TTCN-3
22-01-2008 14:04user10Statusnew => resolved
22-01-2008 14:04user10Resolutionopen => fixed
22-01-2008 14:04user10Fixed in Version => Edition 3.3.2 (not yet published)
22-01-2008 14:04user10Target Version => Edition 3.3.2 (not yet published)
12-03-2008 16:54Ina SchieferdeckerStatusresolved => closed
12-03-2008 16:54Ina SchieferdeckerNote Added: 0005220
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0005220) +
+ Ina Schieferdecker    +
+ 12-03-2008 16:54    +
+ 		+ + + + +
+ As proposed.
+
+ + diff --git a/docs/mantis/CR2753.md b/docs/mantis/CR2753.md new file mode 100644 index 0000000000000000000000000000000000000000..59350efdd0ea57947ecf4c970a0cc7afba844ff7 --- /dev/null +++ b/docs/mantis/CR2753.md @@ -0,0 +1,161 @@ + + + + + + + + + + + + + 0002753: Clarification on timer lifetime - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0002753Part 01: TTCN-3 Core LanguageClarificationpublic23-01-2008 08:4524-04-2008 12:01
ReporterThomas Deiß 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.2.1 (published 2007-02) 
Target Versionv3.4.1 (published 2008-09)Fixed in Versionv3.4.1 (published 2008-09) 
Clause Reference(s)part 1, clause 12; part 4 clause 9.40
Source (company - Author)Thomas Deiß, Nokia Siemens Networks
Summary0002753: Clarification on timer lifetime
DescriptionIt is unclear whether a timer declared and started in a scope unit such as e.g. a function does still exist after the function is left.
+
+Clause 12 contains a note stating: "Visibility of timer names follow the scoping rules given in clause 5. For example, the name of a timer defined locally in a function can be seen within that function only, though the timer is started on the component instance; on returning from that function the specific timer cannot be stopped directly, but only indirectly by an all timer.stop statement. Also, its timeout cannot be checked directly, but only indirectly by an any timer.timeout statement."
+
+This means that after executing the function f() as defined below
+
+function f() {
+  timer t := 5.0;
+  t.start;
+  return
+}
+
+the timer t would still be running and might cause a timeout in the statement
+
+ any timer.timeout;
+
+So, even if the scope unit in which the timer was declared has ceased to exist, the timer would still exist and might contribute to the test case.
+
+The note exists in both 3.2.1 and 3.3.x.
+
+On the other hand, if one is reading part 4, i.e. the operational semantics, this mentions quite explicitly that entering a new scope unit and declaring a timer in this scope unit means to create a new 'timer-binding' on a stack of timer-bindings. Leaving the scope unit means to destroy also this timer-binding, meaning that the timer ceases to exist. This is mentioned several times, e.g. in the definition of the semantics of the return statement (clause 9.40 of part4).
+
+This means that there is a contradiction between parts 1 and 4.
+
+Proposed solution: remove the note completely or change it to:
+"Timers declared and started in scope units such as functions cease to exist when the scope unit is left. They do not contribute to the behaviour once the scope unit is left."
+
+
Steps To Reproduce
Additional InformationOriginally, the issue has been found by Wolfgang Seka.
TagsNo tags attached.
Relationships
Attached Filesdoc CR-2753-Clarification-on-timer-lifetime.doc (124,928) 23-04-2008 15:51
http://oldforge.etsi.org/mantis/file_download.php?file_id=1441&type=bug
Issue History
Date ModifiedUsernameFieldChange
23-01-2008 08:45Thomas DeißNew Issue
23-01-2008 08:45Thomas DeißStatusnew => assigned
23-01-2008 08:45Thomas DeißAssigned To => Ina Schieferdecker
23-01-2008 08:45Thomas DeißClause Reference(s) => part 1, clause 12; part 4 clause 9.40
23-01-2008 08:45Thomas DeißSource (company - Author) => Thomas Deiß, Nokia Siemens Networks
12-03-2008 13:59Ina SchieferdeckerNote Added: 0005207
23-04-2008 11:20Ina SchieferdeckerTarget Version => Edition 3.4.1 (not yet published)
23-04-2008 15:43Jens GrabowskiAssigned ToIna Schieferdecker => Jens Grabowski
23-04-2008 15:51Jens GrabowskiFile Added: CR-2753-Clarification-on-timer-lifetime.doc
23-04-2008 15:52Jens GrabowskiNote Added: 0005522
23-04-2008 15:52Jens GrabowskiAssigned ToJens Grabowski => Thomas Deiß
23-04-2008 16:12Thomas DeißNote Added: 0005528
23-04-2008 16:12Thomas DeißAssigned ToThomas Deiß => Ina Schieferdecker
23-04-2008 16:12Thomas DeißStatusassigned => resolved
23-04-2008 16:12Thomas DeißResolutionopen => fixed
24-04-2008 12:01Ina SchieferdeckerStatusresolved => closed
24-04-2008 12:01Ina SchieferdeckerFixed in Version => Edition 3.4.1 (not yet published)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0005207) +
+ Ina Schieferdecker    +
+ 12-03-2008 13:59    +
+ 		+ + + + +
+ This note made it into v3.2.1 as result of reviewing the draft by ETSI members. We have not been careful when accepting the change: it is in conflict with the current part 4 semantics and with clause 23.1 in part 1.
+
+It relates to CR 2151.
+
+
+
+ + + + + + + + + + +
+ (0005522) +
+ Jens Grabowski    +
+ 23-04-2008 15:52    +
+ 		+ + + + +
+ The attached file implements the proposal of the CR.
+
+
+
+ + + + + + + + + + +
+ (0005528) +
+ Thomas Deiß    +
+ 23-04-2008 16:12    +
+ 		+ + + + +
+ STF 349, Thomas.
+Proposal checked: ok.
+
+ + diff --git a/docs/mantis/CR2754.md b/docs/mantis/CR2754.md new file mode 100644 index 0000000000000000000000000000000000000000..feef27805073bae8e93f8f7df91720282b4ea7b0 --- /dev/null +++ b/docs/mantis/CR2754.md @@ -0,0 +1,119 @@ + + + + + + + + + + + + + 0002754: all timer.running/all timer.timeout - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0002754Part 01: TTCN-3 Core LanguageEditorialpublic23-01-2008 08:5209-05-2008 11:46
ReporterThomas Deiß 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionduplicate 
PlatformOSOS Version
Product Versionv3.2.1 (published 2007-02) 
Target Versionv3.4.1 (published 2008-09)Fixed in Versionv3.3.2 (published 2008-04) 
Clause Reference(s)part1, clauses 23.5, 23.6
Source (company - Author) Thomas Deiß, Nokia Siemens Networks
Summary0002754: all timer.running/all timer.timeout
DescriptionThere are 2 editorial issues in clause 23:
+
+Clause 23.5 describes the syntactical structure of 'timer running' as
+Syntactical Structure
+( ( ( TimerIdentifier | TimerParIdentifier ) { "[" SingleExpression "]" } ) |
+      all timer )
+"." running
+This should 'any timer' instead of 'all timer'.
+There is also no explanation what 'any timer.running' should mean.
+
+Clause 23.6
+The syntactical structure for 'timer timeout'is given as
+Syntactical Structure
+( ( ( TimerIdentifier | TimerParIdentifier ) { "[" SingleExpression "]" } ) |
+      any timer )
+"." running
+
+This should be 'timeout' instead of 'running'.
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
23-01-2008 08:52Thomas DeißNew Issue
23-01-2008 08:52Thomas DeißStatusnew => assigned
23-01-2008 08:52Thomas DeißAssigned To => Ina Schieferdecker
23-01-2008 08:52Thomas DeißClause Reference(s) => part1, clauses 23.5, 23.6
23-01-2008 08:52Thomas DeißSource (company - Author) => Thomas Deiß, Nokia Siemens Networks
09-05-2008 11:35Ina SchieferdeckerNote Added: 0005671
09-05-2008 11:44Ina SchieferdeckerNote Added: 0005673
09-05-2008 11:45Ina SchieferdeckerResolutionopen => duplicate
09-05-2008 11:45Ina SchieferdeckerTarget Version => Edition 3.4.1 (not yet published)
09-05-2008 11:46Ina SchieferdeckerStatusassigned => closed
09-05-2008 11:46Ina SchieferdeckerFixed in Version => Edition 3.3.2
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0005671) +
+ Ina Schieferdecker    +
+ 09-05-2008 11:35    +
+ 		+ + + + +
+ This was fixed already in the approval phase for v3.3.2
+
+
+
+ + + + + + + + + + +
+ (0005673) +
+ Ina Schieferdecker    +
+ 09-05-2008 11:44    +
+ 		+ + + + +
+ See http://webapp.etsi.org/action%5CPU/20080415/es_20187301v030302p.pdf [^]
+
+and CR 2743
+
+
+
+ + diff --git a/docs/mantis/CR2756.md b/docs/mantis/CR2756.md new file mode 100644 index 0000000000000000000000000000000000000000..dccefe63a472e7fe568fa7930bffbb956da89f80 --- /dev/null +++ b/docs/mantis/CR2756.md @@ -0,0 +1,355 @@ + + + + + + + + + + + + + 0002756: further restricting record of/string types - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0002756Part 01: TTCN-3 Core LanguageClarificationpublic23-01-2008 09:4109-07-2009 10:32
ReporterThomas Deiß 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.2.1 (published 2007-02) 
Target Versionv4.2.1 (published 2010-07)Fixed in Versionv4.2.1 (published 2010-07) 
Clause Reference(s)part 1, 6.2.3
Source (company - Author)Thomas Deiß, Nokia Siemens Networks
Summary0002756: further restricting record of/string types
Description(applies also to edition 3.3.x)
+If a record of type is restricted, and this new type should be restricted further it is unclear which restrictions are allowed and what is there effect. Consider the following example:
+
+type record of charstring StringArray23 length(2 .. 3);
+type StringArray23 StringArray34 length(3 .. 4);
+
+The question is whether the restrictions used in the definition of the types StringArray34 are valid and what do these types actually mean.
+
+When restricting types by a value list (6.1.2.1) it is required explicitly that the value list is a true subtype of the base type, i.e. all the values in the list must be elements of the base type and the value list must not equal the base type. Does a similar restriction apply for record of or string types. If this would be the case than the example above would be invalid, as the length restriction length(3..4) contains values (records of with length 4) outside of StringArray23.
+
+One can assume that the meaning of StringArray34 are record of integer values with a length of exactly 3, satisfying both subtyping restrictions.
+
+If both subtyping restriction have to be satisfied instead of satisfying the innermost one (length (3..4)), and if there is no requirement similar to value lists, then it will be easily possible to declare empty types, i.e. types without a value. E.g.
+type StringArray23 StringArray56 length(5..6);
+would not contain any element.
+
+Although it is already possible to create empty types by mixing subtyping by patterns and the other subtyping mechanisms on character strings, I suggest to keep stricter subtyping for record of similar to value lists.
+Length restrictions of already restricted types have to be consistent with the already existing subtyping, independent of the subtyping mechanism used.
+
+Note, that even if these specific restrictions are considered as too strict, the issue has to be clarified in the standard in the one or other way.
+
+
+
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR2756_Subtyping.doc (348,160) 27-11-2008 15:22
http://oldforge.etsi.org/mantis/file_download.php?file_id=1823&type=bug
doc CR2756_Subtyping_02.doc (348,672) 28-11-2008 08:11
http://oldforge.etsi.org/mantis/file_download.php?file_id=1826&type=bug
doc CR2756_Subtyping_03.doc (32,256) 22-04-2009 13:55
http://oldforge.etsi.org/mantis/file_download.php?file_id=2106&type=bug
doc CR2756_Subtyping_04.doc (543,232) 02-07-2009 14:29
http://oldforge.etsi.org/mantis/file_download.php?file_id=2152&type=bug
doc CR2756_Subtyping_05.doc (560,128) 07-07-2009 17:29
http://oldforge.etsi.org/mantis/file_download.php?file_id=2180&type=bug
doc CR2756_Subtyping_06.doc (560,128) 09-07-2009 10:24
http://oldforge.etsi.org/mantis/file_download.php?file_id=2198&type=bug
Issue History
Date ModifiedUsernameFieldChange
23-01-2008 09:41Thomas DeißNew Issue
23-01-2008 09:41Thomas DeißStatusnew => assigned
23-01-2008 09:41Thomas DeißAssigned To => Ina Schieferdecker
23-01-2008 09:41Thomas DeißClause Reference(s) => part 1, 6.2.3
23-01-2008 09:41Thomas DeißSource (company - Author) => Thomas Deiß, Nokia Siemens Networks
09-05-2008 11:29Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
20-05-2008 15:58Thomas DeißNote Added: 0005761
27-11-2008 15:22Ina SchieferdeckerFile Added: CR2756_Subtyping.doc
27-11-2008 15:23Ina SchieferdeckerNote Added: 0007483
27-11-2008 15:23Ina SchieferdeckerAssigned ToIna Schieferdecker => Thomas Deiß
28-11-2008 08:11Thomas DeißFile Added: CR2756_Subtyping_02.doc
28-11-2008 08:11Thomas DeißNote Added: 0007488
28-11-2008 08:11Thomas DeißAssigned ToThomas Deiß => Ina Schieferdecker
28-11-2008 13:07Gyorgy RethyNote Added: 0007501
28-11-2008 13:07Gyorgy RethyTarget VersionEdition 4.1.1 (not yet published) => Edition 4.2.1 (not yet published)
09-12-2008 13:35Ina SchieferdeckerAssigned ToIna Schieferdecker => Gyorgy Rethy
20-04-2009 12:11Ina SchieferdeckerAssigned ToGyorgy Rethy => Tibor Csöndes
22-04-2009 13:55Tibor CsöndesFile Added: CR2756_Subtyping_03.doc
22-04-2009 13:58Tibor CsöndesNote Added: 0008535
22-04-2009 14:42Tibor CsöndesAssigned ToTibor Csöndes => Gyorgy Rethy
02-07-2009 14:22Gyorgy RethyNote Added: 0008815
02-07-2009 14:23Gyorgy RethyNote Edited: 0008815
02-07-2009 14:25Gyorgy RethyNote Edited: 0008815
02-07-2009 14:29Gyorgy RethyFile Added: CR2756_Subtyping_04.doc
02-07-2009 14:30Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
03-07-2009 13:41Gyorgy RethyNote Edited: 0008815
03-07-2009 13:42Gyorgy RethyNote Edited: 0008815
07-07-2009 17:28Ina SchieferdeckerNote Added: 0008856
07-07-2009 17:29Ina SchieferdeckerFile Added: CR2756_Subtyping_05.doc
07-07-2009 17:29Ina SchieferdeckerNote Edited: 0008856
07-07-2009 17:29Ina SchieferdeckerAssigned ToIna Schieferdecker => Gyorgy Rethy
09-07-2009 09:36Ina SchieferdeckerNote Edited: 0008856
09-07-2009 09:49Ina SchieferdeckerNote Added: 0008879
09-07-2009 09:50Ina SchieferdeckerFile Added: CR2756_Subtyping_06.doc
09-07-2009 10:23Ina SchieferdeckerFile Deleted: CR2756_Subtyping_06.doc
09-07-2009 10:24Ina SchieferdeckerFile Added: CR2756_Subtyping_06.doc
09-07-2009 10:31Ina SchieferdeckerResolutionopen => fixed
09-07-2009 10:32Ina SchieferdeckerStatusassigned => resolved
09-07-2009 10:32Ina SchieferdeckerFixed in Version => Edition 4.2.1 (not yet published)
09-07-2009 10:32Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0005761) +
+ Thomas Deiß    +
+ 20-05-2008 15:58    +
+ 		+ + + + +
+ Some types and questions:
+type record of charstring ro1
+  type record of ro1 ro2 length(3..5)
+  
+  type record of record of charstring ro3 length(3..5)
+  
+  type record of ro2 ro4 length(4..6)
+  
+  type record of ro1 ro5 ({"a", "b", "c"}, {"abc"})
+
+  type ro1 t1 length(3..5)
+  
+  type ro1 t2 [0..10] length(3..5)
+  type t2 t3 length(5..14)
+
+Given the types above, the part1 should provide their meaning:
+Is it correct that in 'ro3' the length restriction refers to the inner type (charstring)?
+The length restriction used in the definition of 'ro2', does it refer to the 'record of' or the charstring?
+A similar question can be asked for the defintion of type 't'.
+Eine ähnliche Frage stellt sich bei t1. In case the inner type is restricted, what does this imply for ro4: If there are several restrictions do all of them have to be valid, or does the outermost supersede the other ones.
+In case the outer type is restricted, is the type definiton for ro5 correct, can such a value list be used (I think so!).
+Then there is also clause 6.2.3, Note1: “Note that the innermost type can not be a set of or record of”, is this just misleading or what is the real meaning of this note.
+
+
+
+ + + + + + + + + + +
+ (0007483) +
+ Ina Schieferdecker    +
+ 27-11-2008 15:23    +
+ 		+ + + + +
+ First draft uploaded - please check.
+
+
+
+ + + + + + + + + + +
+ (0007488) +
+ Thomas Deiß    +
+ 28-11-2008 08:11    +
+ 		+ + + + +
+ editorial corrections, otherwise ok.
+
+
+
+ + + + + + + + + + +
+ (0007501) +
+ Gyorgy Rethy    +
+ 28-11-2008 13:07    +
+ 		+ + + + +
+ Discussion shall be shifted to 2009 as there is already note 1 in clause 6.2.3 saying that in case of record of something the type restriction placed after the name of the newly defined type is related to the innermost type and not to the record of.
+
+
+
+ + + + + + + + + + +
+ (0008535) +
+ Tibor Csöndes    +
+ 22-04-2009 13:58    +
+ 		+ + + + +
+ From CR2756_Subtyping_02.doc 6.3.5 copied to 6.2.13. Reference to table 3 and more examples added.
+
+
+
+ + + + + + + + + + +
+ (0008815) +
+ Gyorgy Rethy    +
+ 02-07-2009 14:22    +
(edited on: 03-07-2009 13:42)
+ 		+ + + + +
+ CR2756_Subtyping_04.doc:
+Proposed solution is essentially re-worked; examples agreed on the TTCN-3 CR resolution mtg. remained as they were, text and examples are added to cover all cases of subtyping of structured types and anytype (the reviewer to check this as well) and cleaned up (e.g. there were some mentioning of structured types subtyping in the clause about subtyping of basic types).
+All stuff about structured type and anytype subtyping is moved to a new clause 6.2.13.
+See CR2756_Subtyping_04.doc.
+PS: the bookmark to clause no. 6.1.2.6 is wrong, the last 6 is outside of the bookmark!
+
+
+
+
+
+ + + + + + + + + + +
+ (0008856) +
+ Ina Schieferdecker    +
+ 07-07-2009 17:28    +
(edited on: 09-07-2009 09:36)
+ 		+ + + + +
+ basically ok with one exception: need to discuss if empty types cause error or not
+
+some editorial changes
+
+
+
+
+
+ + + + + + + + + + +
+ (0008879) +
+ Ina Schieferdecker    +
+ 09-07-2009 09:49    +
+ 		+ + + + +
+ agreed that empty types lead to error
+
+ + diff --git a/docs/mantis/CR2757.md b/docs/mantis/CR2757.md new file mode 100644 index 0000000000000000000000000000000000000000..a2c23627764e44df9aac1a7291490710b64ac26b --- /dev/null +++ b/docs/mantis/CR2757.md @@ -0,0 +1,587 @@ + + + + + + + + + + + + + 0002757: accessing parts of received messages - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0002757Part 01: TTCN-3 Core LanguageNew Featurepublic23-01-2008 10:1210-03-2009 09:39
ReporterThomas Deiß 
Assigned ToIna Schieferdecker 
PriorityhighSeverityfeatureReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.2.1 (published 2007-02) 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)part 1, clause 15
Source (company - Author)Andy Rauland, Thomas Deiß, Nokia Siemens Networks
Summary0002757: accessing parts of received messages
Description(applies equally to 3.3)
+
+When several fields of received messages are used within a test case the message is often taken is taken apart by a series of assign statements using the dot notation to access the individual fields.
+
+This approach is fragile (changes in the message structure might have effects on the access using the dot notation) as well as cumbersome (the access is done field by field causing repetitive code).
+
+Templates provide already a compact way to define parts of a message, a similar approach could be used to access parts of a message in a compact way. The attached document contains two proposals how this could be achieved.
+
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0004849closed Ina Schieferdecker Misuse of the assignment operator 
Attached Filesdoc assigning_parts_of_messages_02.doc (136,192) 23-01-2008 10:12
http://oldforge.etsi.org/mantis/file_download.php?file_id=1298&type=bug
doc CR2757_proposed_solution_v1.doc (1,071,616) 15-08-2008 10:24
http://oldforge.etsi.org/mantis/file_download.php?file_id=1608&type=bug
doc CR2757_proposed_solution_v1_1.doc (1,073,664) 30-09-2008 01:10
http://oldforge.etsi.org/mantis/file_download.php?file_id=1666&type=bug
doc CR2757_proposed_solution_v1_2.doc (1,075,200) 13-10-2008 13:24
http://oldforge.etsi.org/mantis/file_download.php?file_id=1680&type=bug
doc CR2757_proposed_solution_v1_3.doc (1,079,296) 26-11-2008 15:54
http://oldforge.etsi.org/mantis/file_download.php?file_id=1793&type=bug
doc CR2757_proposed_solution_v1_4.doc (1,080,832) 26-11-2008 17:17
http://oldforge.etsi.org/mantis/file_download.php?file_id=1795&type=bug
doc CR2757_proposed_solution_v1_5.doc (1,080,320) 10-12-2008 14:41
http://oldforge.etsi.org/mantis/file_download.php?file_id=1882&type=bug
doc CR2757_proposed_solution_v1_6.doc (1,088,000) 12-01-2009 08:57
http://oldforge.etsi.org/mantis/file_download.php?file_id=1944&type=bug
doc CR2757_proposed_solution_v1_7.doc (1,094,656) 12-01-2009 17:54
http://oldforge.etsi.org/mantis/file_download.php?file_id=1946&type=bug
doc CR2757_proposed_solution_v1_8.doc (1,095,168) 12-01-2009 18:28
http://oldforge.etsi.org/mantis/file_download.php?file_id=1947&type=bug
doc CR2757_proposed_solution_v1_9.doc (1,094,656) 13-01-2009 08:28
http://oldforge.etsi.org/mantis/file_download.php?file_id=1948&type=bug
doc CR2757_proposed_solution_v1_10.doc (1,096,192) 10-03-2009 09:38
http://oldforge.etsi.org/mantis/file_download.php?file_id=2023&type=bug
Issue History
Date ModifiedUsernameFieldChange
23-01-2008 10:12Thomas DeißNew Issue
23-01-2008 10:12Thomas DeißStatusnew => assigned
23-01-2008 10:12Thomas DeißAssigned To => Ina Schieferdecker
23-01-2008 10:12Thomas DeißFile Added: assigning_parts_of_messages_02.doc
23-01-2008 10:12Thomas DeißClause Reference(s) => part 1, clause 15
23-01-2008 10:12Thomas DeißSource (company - Author) => Andy Rauland, Thomas Deiß, Nokia Siemens Networks
09-05-2008 10:36Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
15-07-2008 10:40Ina SchieferdeckerAssigned ToIna Schieferdecker => Gyorgy Rethy
14-08-2008 13:39Gyorgy RethyNote Added: 0006529
15-08-2008 10:24Gyorgy RethyFile Added: CR2757_proposed_solution_v1.doc
15-08-2008 10:25Gyorgy RethyAssigned ToGyorgy Rethy => Thomas Deiß
30-09-2008 01:10Thomas DeißFile Added: CR2757_proposed_solution_v1_1.doc
30-09-2008 01:11Thomas DeißNote Added: 0006930
30-09-2008 01:11Thomas DeißAssigned ToThomas Deiß => Gyorgy Rethy
13-10-2008 13:24Gyorgy RethyFile Added: CR2757_proposed_solution_v1_2.doc
13-10-2008 13:27Gyorgy RethyNote Added: 0007039
13-10-2008 13:27Gyorgy RethyAssigned ToGyorgy Rethy => Thomas Deiß
13-10-2008 13:39Thomas DeißNote Added: 0007040
13-10-2008 13:39Thomas DeißAssigned ToThomas Deiß =>
13-10-2008 13:41Thomas DeißAssigned To => Ina Schieferdecker
24-11-2008 16:56Ina SchieferdeckerNote Added: 0007391
24-11-2008 16:56Ina SchieferdeckerAssigned ToIna Schieferdecker => Gyorgy Rethy
26-11-2008 14:08Gyorgy RethyNote Added: 0007449
26-11-2008 14:10Gyorgy RethyAssigned ToGyorgy Rethy => Thomas Deiß
26-11-2008 15:54Thomas DeißFile Added: CR2757_proposed_solution_v1_3.doc
26-11-2008 15:54Thomas DeißNote Added: 0007454
26-11-2008 15:54Thomas DeißAssigned ToThomas Deiß => Gyorgy Rethy
26-11-2008 15:56Thomas DeißNote Edited: 0007454
26-11-2008 17:15Gyorgy RethyNote Added: 0007457
26-11-2008 17:16Gyorgy RethyNote Edited: 0007457
26-11-2008 17:17Gyorgy RethyFile Added: CR2757_proposed_solution_v1_4.doc
26-11-2008 17:17Gyorgy RethyAssigned ToGyorgy Rethy => Thomas Deiß
27-11-2008 07:49Thomas DeißNote Added: 0007463
27-11-2008 07:49Thomas DeißAssigned ToThomas Deiß => Ina Schieferdecker
10-12-2008 14:40Ina SchieferdeckerNote Added: 0007639
10-12-2008 14:41Ina SchieferdeckerFile Added: CR2757_proposed_solution_v1_5.doc
10-12-2008 14:41Ina SchieferdeckerAssigned ToIna Schieferdecker => Thomas Deiß
11-12-2008 10:46Thomas DeißNote Added: 0007651
11-12-2008 10:46Thomas DeißAssigned ToThomas Deiß => Ina Schieferdecker
12-12-2008 07:30Ina SchieferdeckerStatusassigned => resolved
12-12-2008 07:30Ina SchieferdeckerResolutionopen => fixed
12-12-2008 07:30Ina SchieferdeckerFixed in Version => Edition 4.1.1 (not yet published)
12-12-2008 07:31Ina SchieferdeckerStatusresolved => closed
12-01-2009 08:57Thomas DeißStatusclosed => feedback
12-01-2009 08:57Thomas DeißResolutionfixed => reopened
12-01-2009 08:57Thomas DeißNote Added: 0007818
12-01-2009 08:57Thomas DeißFile Added: CR2757_proposed_solution_v1_6.doc
12-01-2009 17:54Ina SchieferdeckerFile Added: CR2757_proposed_solution_v1_7.doc
12-01-2009 17:56Ina SchieferdeckerNote Added: 0007824
12-01-2009 17:56Ina SchieferdeckerStatusfeedback => assigned
12-01-2009 17:56Ina SchieferdeckerAssigned ToIna Schieferdecker => Thomas Deiß
12-01-2009 18:27Ina SchieferdeckerNote Added: 0007825
12-01-2009 18:28Ina SchieferdeckerFile Added: CR2757_proposed_solution_v1_8.doc
13-01-2009 08:28Thomas DeißFile Added: CR2757_proposed_solution_v1_9.doc
13-01-2009 08:29Thomas DeißNote Added: 0007826
13-01-2009 08:29Thomas DeißAssigned ToThomas Deiß => Ina Schieferdecker
10-03-2009 09:37Ina SchieferdeckerRelationship addedrelated to 0004849
10-03-2009 09:38Ina SchieferdeckerFile Added: CR2757_proposed_solution_v1_10.doc
10-03-2009 09:38Ina SchieferdeckerStatusassigned => resolved
10-03-2009 09:38Ina SchieferdeckerResolutionreopened => fixed
10-03-2009 09:39Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0006529) +
+ Gyorgy Rethy    +
+ 14-08-2008 13:39    +
+ 		+ + + + +
+ CR was discussed and it was decided to go for an unnamed list of assignmets allowing to redirect different parts of the received message, like [] P.receive(b_r_1(false)) -> value {vt_bool:=R.b1;vl_bool:=R.b2}.
+Detailed solution to be developed.
+
+
+
+ + + + + + + + + + +
+ (0006930) +
+ Thomas Deiß    +
+ 30-09-2008 01:11    +
+ 		+ + + + +
+ A few (minor) comments.
+Ok to restrict this to message based communication.
+
+
+
+
+ + + + + + + + + + +
+ (0007039) +
+ Gyorgy Rethy    +
+ 13-10-2008 13:27    +
+ 		+ + + + +
+ I propose to leave semicolon to separate the redirects, it is similar to assignments following each other within a block of statements. Can be stored to values or formal parameters, the latter is added to the text. Otherwise it could be approved.
+
+
+
+ + + + + + + + + + +
+ (0007040) +
+ Thomas Deiß    +
+ 13-10-2008 13:39    +
+ 		+ + + + +
+ v1-2 checked. Ok from my side.
+
+
+
+
+ + + + + + + + + + +
+ (0007391) +
+ Ina Schieferdecker    +
+ 24-11-2008 16:56    +
+ 		+ + + + +
+ Please check another syntax close to the param redirect.
+
+Also, the usage of the field type is not enough - consider to use the field name.
+
+
+
+ + + + + + + + + + +
+ (0007449) +
+ Gyorgy Rethy    +
+ 26-11-2008 14:08    +
+ 		+ + + + +
+ Regarding the syntax, the param redirect syntax is suitable, see example below.
+We could even define an analoguos explicit syntax for param redirect, e.g.
+MyPort.getcall(MyProc:{?, ?}) -> param (param1 -> MyPar1Var, param3 -> MyPar3Var);
+Pls. note that in this case no need to skip e.g. the in parameters in the list.
+The type is inough, as identifes the field unanomously. Pls. note, that the whole message may also be stored when a redirection list is specified, e.g
+MyPort.receive(MyType:?) -> value ( MyType -> MyPDUVar, MyType.messageId -> MyMessageIdVar )
+//..................................^----------------^stores the whole message
+//.....................................................^----------------^stores the messageId field.
+
+
+
+ + + + + + + + + + +
+ (0007454) +
+ Thomas Deiß    +
+ 26-11-2008 15:54    +
(edited on: 26-11-2008 15:56)
+ 		+ + + + +
+ syntax updated according to our discussion (no usage of the typename in the redirect).
+v1_3 uploaded.
+
+Should it be stated explicitly that also elements of record of messages can be accessed?
+
+
+
+
+
+ + + + + + + + + + +
+ (0007457) +
+ Gyorgy Rethy    +
+ 26-11-2008 17:15    +
(edited on: 26-11-2008 17:16)
+ 		+ + + + +
+ In the text the field reference is not starting with a dot, but ExtendedFieldReference does. Thus I changed bnf rule 380 to
+1. ValueSpec ::= ValueKeyword ( VariableRef | "(" [ (FieldReference | TypeDefIdentifier ) ExtendedFieldReference ] PortRedirectSymbol VariableRef [","] ")" )
+/*STATIC SEMANTICS – FieldReference shall not be ParRef and ExtendedFieldReference shall not be TypeDefIdentifier*/
+
+See version ~v1_4.
+
+Except this is OK with me.
+
+
+
+
+
+ + + + + + + + + + +
+ (0007463) +
+ Thomas Deiß    +
+ 27-11-2008 07:49    +
+ 		+ + + + +
+ fine for me.
+
+
+
+ + + + + + + + + + +
+ (0007639) +
+ Ina Schieferdecker    +
+ 10-12-2008 14:40    +
+ 		+ + + + +
+ Two corrections:
+
+Check operation: "Value, sender and parameter redirects are specified in the clauses of the related receiving operations" removed as it is not entirely true as e.g. sender can be checked without a receiving operation. Also, the sentence does not add information at this point.
+
+390. ValueSpec: { } added as several "redirects" can be given on field level
+
+Please check.
+
+
+
+ + + + + + + + + + +
+ (0007651) +
+ Thomas Deiß    +
+ 11-12-2008 10:46    +
+ 		+ + + + +
+ you are correct on both issues.
+
+
+
+
+ + + + + + + + + + +
+ (0007818) +
+ Thomas Deiß    +
+ 12-01-2009 08:57    +
+ 		+ + + + +
+ reopened to include result of email discussion with Jacob Wiegand.
+value redirection resembles more closely parameter redirection, if parts of the message are assigned.
+
+
+
+ + + + + + + + + + +
+ (0007824) +
+ Ina Schieferdecker    +
+ 12-01-2009 17:56    +
+ 		+ + + + +
+ Corrected the examples as the agreement was to use ":=" instead of "->" - see syntactical structure.
+
+Simplified the syntactical structure as it only gives an overview - the precise BNF rules are given however in annex A.
+
+See v1_7 and please check.
+
+
+
+ + + + + + + + + + +
+ (0007825) +
+ Ina Schieferdecker    +
+ 12-01-2009 18:27    +
+ 		+ + + + +
+ Had to adapt the text for receive to refer to ":=" and not to "->", see v1_8
+
+
+
+ + + + + + + + + + +
+ (0007826) +
+ Thomas Deiß    +
+ 13-01-2009 08:29    +
+ 		+ + + + +
+ changes ok.
+And one further use of '->' found in the Example 2 of the catch statement. corrected in v 0.9.
+
+
+ + diff --git a/docs/mantis/CR2758.md b/docs/mantis/CR2758.md new file mode 100644 index 0000000000000000000000000000000000000000..424eb41087b6b0058fe73794549361248063c1cd --- /dev/null +++ b/docs/mantis/CR2758.md @@ -0,0 +1,213 @@ + + + + + + + + + + + + + 0002758: Queueing of function calls - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0002758Part 01: TTCN-3 Core LanguageNew Featurepublic23-01-2008 10:4816-02-2010 14:21
ReporterThomas Deiß 
Assigned ToJens Grabowski 
PrioritynormalSeverityfeatureReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.2.1 (published 2007-02) 
Target Versionv4.2.1 (published 2010-07)Fixed in Version 
Clause Reference(s)part 1, 21.2.2
Source (company - Author)Thomas Deiß, Nokia Siemens Networks
Summary0002758: Queueing of function calls
DescriptionParallel test components can execute one function at a time. On alive components it is possible to execute several functions one after the other. Starting a function using the start statement on a PTC on which another function is executed already causes a runtime system error. Therefore the behaviour on the calling PTC has to check using the running or done statements whether a new function can be started.
+
+It would ease the definition of the calling behaviour if the start statements for consecutive functions on one specific component could be written one after the other without intermittent done statements. To be meaningful, the function calls have to be queued, i.e. execution of the second function starts only once the first function has terminated.
+
+This can be achieved in different ways:
+a) change the existing semantics. Instead of causing a dynamic error if a new function is started, queue this function.
+b) Define a new type of PTCs, could be done similar to 'alive' in the create statement:
+ptc.create queueing
+c) extend the start function statement by a directive to indicate that the function is to be queued.
+ptc.start(f(), queueing);
+d) allow to consider a TTCN-3 function as a TTCN-3 procedure that can be called in a call statement. To avoid that the code to accept the call has to be written manually, a new kind of component or a specific behaviour is needed that accepts such function calls and executes the corresponding functions.
+
+The alternatives have different advantages. These and further detail regarding d) are provided in the (yet to be) attached document.
Steps To Reproduce
Additional InformationApplies also to edition 3.3
+
+This CR has a strong relation to CR 224, return values of behaviour functions. These should be solved together in a consistent way.
TagsNo tags attached.
Relationships
related to 0000413closed Jens Grabowski Static test configurations 
Attached Filesdoc queueing_functions_02.doc (98,304) 13-02-2008 08:48
http://oldforge.etsi.org/mantis/file_download.php?file_id=1341&type=bug
ppt CR2758.ppt (140,800) 16-03-2008 11:31
http://oldforge.etsi.org/mantis/file_download.php?file_id=1387&type=bug
Issue History
Date ModifiedUsernameFieldChange
23-01-2008 10:48Thomas DeißNew Issue
23-01-2008 10:48Thomas DeißStatusnew => assigned
23-01-2008 10:48Thomas DeißAssigned To => Ina Schieferdecker
23-01-2008 10:48Thomas DeißClause Reference(s) => part 1, 21.2.2
23-01-2008 10:48Thomas DeißSource (company - Author) => Thomas Deiß, Nokia Siemens Networks
13-02-2008 08:48Thomas DeißFile Added: queueing_functions_02.doc
13-02-2008 08:49Thomas DeißNote Added: 0004945
10-03-2008 15:08Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
13-03-2008 15:32Ina SchieferdeckerNote Added: 0005226
16-03-2008 11:31Ina SchieferdeckerFile Added: CR2758.ppt
15-07-2008 13:11Ina SchieferdeckerNote Added: 0006277
24-11-2008 11:03Ina SchieferdeckerAssigned ToIna Schieferdecker => Jens Grabowski
12-12-2008 09:27Ina SchieferdeckerRelationship addedrelated to 0000413
12-12-2008 09:27Ina SchieferdeckerNote Added: 0007671
12-12-2008 09:27Ina SchieferdeckerTarget VersionEdition 4.1.1 (not yet published) => Edition 4.2.1 (not yet published)
16-02-2010 14:21Jens GrabowskiStatusassigned => closed
16-02-2010 14:21Jens GrabowskiNote Added: 0009215
16-02-2010 14:21Jens GrabowskiResolutionopen => fixed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0004945) +
+ Thomas Deiß    +
+ 13-02-2008 08:49    +
+ 		+ + + + +
+ File with explanation and proposals uploaded. To be discussed by STF.
+
+
+
+ + + + + + + + + + +
+ (0005226) +
+ Ina Schieferdecker    +
+ 13-03-2008 15:32    +
+ 		+ + + + +
+ The related CR is in Mantis CR 378: Return values of PTC behaviour functions
+
+
+
+ + + + + + + + + + +
+ (0006277) +
+ Ina Schieferdecker    +
+ 15-07-2008 13:11    +
+ 		+ + + + +
+ The solution to this CR may have implications on the solutions to the various test configuration CRs such as 381, 413, 2143, 2025
+
+
+
+ + + + + + + + + + +
+ (0007671) +
+ Ina Schieferdecker    +
+ 12-12-2008 09:27    +
+ 		+ + + + +
+ To be discussed once the deployment and configuration package has been defined.
+
+
+
+ + + + + + + + + + +
+ (0009215) +
+ Jens Grabowski    +
+ 16-02-2010 14:21    +
+ 		+ + + + +
+ Partially solved by static configurations.
+
+ + diff --git a/docs/mantis/CR2808.md b/docs/mantis/CR2808.md new file mode 100644 index 0000000000000000000000000000000000000000..44306aee73950d808ee4aef00174df09a115960f --- /dev/null +++ b/docs/mantis/CR2808.md @@ -0,0 +1,210 @@ + + + + + + + + + + + + + 0002808: Verdict reason - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0002808Part 01: TTCN-3 Core LanguageNew Featurepublic31-01-2008 12:1324-04-2008 12:34
ReporterGyorgy Rethy 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityfeatureReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv3.4.1 (published 2008-09)Fixed in Versionv3.4.1 (published 2008-09) 
Clause Reference(s)Part-1 cl.24, Part-6 cl.7.3.4
Source (company - Author)Ericsson
Summary0002808: Verdict reason
DescriptionToday the language does not gives any possibility to identify and handle the reason of assigning a given verdict, though this would be very useful at test execution (especially when the test development and execution are done by different testers).
Steps To Reproduce
Additional InformationSimilarly to the create operation, a second, optional charstring parameter should be introduced. This parameter is transparent for the language and the test system point of view. Except the implicit component verdict variable, also an implicit component verdict string variable shall be introduced. When a component verdict is overwritten (even with the same verdict value), the component verdict string is overriden as well. When the related setverdict operation contains a string parameter, the old string is overwritten by the new one. If the actual setverdict operation do not have a string parameter, the "old" string is deleted.
+The getverdict operation returns a single verdict value, hence cannot be used to retrieve the actual component verdict string value. Either the actual verdict string value is not retrievable or a new operation (e.g. getverdictstring shall be defined. We do not have a strong opinion on this.
+When component finishes, its verdict is sent to TM. Whith this improvement, except the final component verdict, also the final component verdict string is sent to TM. Unlike the verdict value, it is shall not be specified by the standard, how to handle the verdict strings of the different components (i.e. there is no test case verdict string).
TagsNo tags attached.
Relationships
Attached Filesdoc CR2808-Verdict-Reason-Part1-Resolution.doc (1,690,112) 21-04-2008 18:46
http://oldforge.etsi.org/mantis/file_download.php?file_id=1423&type=bug
doc CR2808-Verdict-Reason-Part6-Resolution.doc (381,952) 22-04-2008 10:40
http://oldforge.etsi.org/mantis/file_download.php?file_id=1425&type=bug
doc CR2808-Verdict-Reason-Part1-Resolution v2byGyorgy.doc (1,728,000) 22-04-2008 12:52
http://oldforge.etsi.org/mantis/file_download.php?file_id=1430&type=bug
doc CR2808-Verdict-Reason-Part6-Resolution_v1.doc (437,760) 23-04-2008 18:52
http://oldforge.etsi.org/mantis/file_download.php?file_id=1447&type=bug
doc CR2808-Verdict-Reason-Part1-Resolution v3.doc (1,730,560) 24-04-2008 12:24
http://oldforge.etsi.org/mantis/file_download.php?file_id=1451&type=bug
Issue History
Date ModifiedUsernameFieldChange
31-01-2008 12:13Gyorgy RethyNew Issue
31-01-2008 12:13Gyorgy RethyClause Reference(s) => Part-1 cl.24, Part-6 cl.7.3.4
31-01-2008 12:13Gyorgy RethySource (company - Author) => Ericsson
10-03-2008 16:06Thomas DeißNote Added: 0005193
10-03-2008 16:06Ina SchieferdeckerProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
10-03-2008 16:07Ina SchieferdeckerStatusnew => assigned
10-03-2008 16:07Ina SchieferdeckerAssigned To => Jens Grabowski
10-03-2008 16:07Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
21-04-2008 08:57Ina SchieferdeckerTarget VersionEdition 4.1.1 (not yet published) => Edition 3.4.1 (not yet published)
21-04-2008 18:46Jens GrabowskiNote Added: 0005480
21-04-2008 18:46Jens GrabowskiFile Added: CR2808-Verdict-Reason-Part1-Resolution.doc
21-04-2008 18:48Jens GrabowskiNote Added: 0005481
21-04-2008 18:49Jens GrabowskiAssigned ToJens Grabowski => Thomas Deiß
22-04-2008 10:40Thomas DeißFile Added: CR2808-Verdict-Reason-Part6-Resolution.doc
22-04-2008 10:42Thomas DeißNote Added: 0005486
22-04-2008 10:43Thomas DeißAssigned ToThomas Deiß => Gyorgy Rethy
22-04-2008 12:52Gyorgy RethyFile Added: CR2808-Verdict-Reason-Part1-Resolution v2byGyorgy.doc
22-04-2008 12:54Gyorgy RethyNote Added: 0005495
22-04-2008 12:54Gyorgy RethyAssigned ToGyorgy Rethy => Thomas Deiß
22-04-2008 14:36Thomas DeißAssigned ToThomas Deiß => Jens Grabowski
22-04-2008 15:42Jens GrabowskiAssigned ToJens Grabowski => Ina Schieferdecker
22-04-2008 15:42Jens GrabowskiResolutionopen => fixed
23-04-2008 18:44Ina SchieferdeckerFile Added: CR2808-Verdict-Reason-Part1-Resolution v3.doc
23-04-2008 18:52Ina SchieferdeckerFile Added: CR2808-Verdict-Reason-Part6-Resolution_v1.doc
23-04-2008 19:21Ina SchieferdeckerStatusassigned => resolved
24-04-2008 12:23Ina SchieferdeckerFile Deleted: CR2808-Verdict-Reason-Part1-Resolution v3.doc
24-04-2008 12:24Ina SchieferdeckerFile Added: CR2808-Verdict-Reason-Part1-Resolution v3.doc
24-04-2008 12:34Ina SchieferdeckerStatusresolved => closed
24-04-2008 12:34Ina SchieferdeckerFixed in Version => Edition 3.4.1 (not yet published)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0005193) +
+ Thomas Deiß    +
+ 10-03-2008 16:06    +
+ 		+ + + + +
+ Applies to fail, pass, inconc, none.
+The remaining verdict reasons should be as expressive as the arguments of the log statement.
+
+Using getverdict as reason returns the previous verdict, i.e. the verdict before the setverdict.
+
+reasons of the error verdict relate to CR 2565 'TTCN-3 exceptions'
+This CR and CR 2565 should be resolved consistently.
+
+
+
+ + + + + + + + + + +
+ (0005480) +
+ Jens Grabowski    +
+ 21-04-2008 18:46    +
+ 		+ + + + +
+ Attached a proposal for the resolution in Part 1. Changes related to Parts 5 and/or 6 will be done by Thomas. I assign the CR therefore now to Thomas.
+
+
+
+ + + + + + + + + + +
+ (0005481) +
+ Jens Grabowski    +
+ 21-04-2008 18:48    +
+ 		+ + + + +
+ Additional comment: In the BNF the change is only related to rule 535
+
+
+
+ + + + + + + + + + +
+ (0005486) +
+ Thomas Deiß    +
+ 22-04-2008 10:42    +
+ 		+ + + + +
+ STF 349, Thomas:
+Proposal for part 6 added. As the reason strings are not combined, they do not need to be exchanged across test components ==> no change to TCI-CH nor TCI-TM.
+
+The change is limited to extend the tliSetVerdict operation by an additional argument to hold the reason.
+
+
+
+ + + + + + + + + + +
+ (0005495) +
+ Gyorgy Rethy    +
+ 22-04-2008 12:54    +
+ 		+ + + + +
+ See my comments/changes in the document CR2808-Verdict-Reason-Part1-Resolution v2byGyorgy
+
+ + diff --git a/docs/mantis/CR2809.md b/docs/mantis/CR2809.md new file mode 100644 index 0000000000000000000000000000000000000000..4c72671a32604a120d199024410bd9fd165157dd --- /dev/null +++ b/docs/mantis/CR2809.md @@ -0,0 +1,141 @@ + + + + + + + + + + + + + 0002809: Getverdict in log statement - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0002809Part 01: TTCN-3 Core LanguageNew Featurepublic31-01-2008 12:2024-04-2008 19:13
ReporterGyorgy Rethy 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv3.4.1 (published 2008-09)Fixed in Versionv3.4.1 (published 2008-09) 
Clause Reference(s)Part-1 $19.11, Part-4, Part-6 $7.3.4
Source (company - Author)Ericsson
Summary0002809: Getverdict in log statement
DescriptionCurrently, acording to cl. 19.11, it is not possible to log a verdict value. Neither using getverdict within the log statement, nor saving the actual log into a variable and log the variable value. We consider this as an omission in the standard.
Steps To Reproduce
Additional InformationBoth the getverdict operation and identifiers of verdict-type values shall be allowed in the log statement. In the first case the component verdict value returned shall be logged, in the second case the actual value shall be logged.
TagsNo tags attached.
Relationships
Attached Filesdoc CR_2809_getverdict_in_log_statement_solution_01.doc (207,360) 11-03-2008 10:48
http://oldforge.etsi.org/mantis/file_download.php?file_id=1367&type=bug
doc CR_2809_getverdict_in_log_statement_solution_02.doc (190,976) 14-03-2008 08:13
http://oldforge.etsi.org/mantis/file_download.php?file_id=1380&type=bug
doc CR_2809_getverdict_in_log_statement_solution_03.doc (191,488) 23-04-2008 18:32
http://oldforge.etsi.org/mantis/file_download.php?file_id=1444&type=bug
Issue History
Date ModifiedUsernameFieldChange
31-01-2008 12:20Gyorgy RethyNew Issue
31-01-2008 12:20Gyorgy RethyClause Reference(s) => Part-1 $19.11, Part-4, Part-6 $7.3.4
31-01-2008 12:20Gyorgy RethySource (company - Author) => Ericsson
10-03-2008 15:48Thomas DeißNote Added: 0005192
10-03-2008 15:48Ina SchieferdeckerStatusnew => assigned
10-03-2008 15:48Ina SchieferdeckerAssigned To => Thomas Deiß
10-03-2008 15:49Ina SchieferdeckerProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
10-03-2008 15:50Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
11-03-2008 10:48Thomas DeißFile Added: CR_2809_getverdict_in_log_statement_solution_01.doc
11-03-2008 10:54Thomas DeißNote Added: 0005197
14-03-2008 08:13Thomas DeißFile Added: CR_2809_getverdict_in_log_statement_solution_02.doc
14-03-2008 08:14Thomas DeißNote Added: 0005229
14-03-2008 08:14Thomas DeißAssigned ToThomas Deiß => Ina Schieferdecker
21-04-2008 08:56Ina SchieferdeckerTarget VersionEdition 4.1.1 (not yet published) => Edition 3.4.1 (not yet published)
23-04-2008 18:32Ina SchieferdeckerFile Added: CR_2809_getverdict_in_log_statement_solution_03.doc
23-04-2008 18:32Ina SchieferdeckerResolutionopen => fixed
23-04-2008 19:22Ina SchieferdeckerStatusassigned => resolved
24-04-2008 19:13Ina SchieferdeckerStatusresolved => closed
24-04-2008 19:13Ina SchieferdeckerFixed in Version => Edition 3.4.1 (not yet published)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0005192) +
+ Thomas Deiß    +
+ 10-03-2008 15:48    +
+ 		+ + + + +
+ STF 349, getverdict should be added to table 13. Check whether other operations are missing, too.
+
+
+
+ + + + + + + + + + +
+ (0005197) +
+ Thomas Deiß    +
+ 11-03-2008 10:54    +
+ 		+ + + + +
+ Thomas: Solution proposal.
+valueof, and match operations have been missing, too. Whether there is much point in using them in a log statement is a different story, but there is no point in forbidding it.
+
+activate and create are missing, too. But these change the state of the test system and should not be used.
+
+There was a misspelling: UNITIALIZED -> UNINITIALIZED
+
+There is a restriction on the use of statements that can be used inside functions that can be used inside a log statement. I suggest to remove this limitation and just keep the guideline in the paragraph before.
+
+
+
+ + + + + + + + + + +
+ (0005229) +
+ Thomas Deiß    +
+ 14-03-2008 08:14    +
+ 		+ + + + +
+ STF349, Thomas, solution for revision.
+should -> shall,
+restriction is kept,
+list of usable statements replaced by references.
+
+ + diff --git a/docs/mantis/CR2817.md b/docs/mantis/CR2817.md new file mode 100644 index 0000000000000000000000000000000000000000..d1ebdf85721d406a687f5c539a901af9e67565c0 --- /dev/null +++ b/docs/mantis/CR2817.md @@ -0,0 +1,219 @@ + + + + + + + + + + + + + 0002817: Unclear handling of whitespace in documentation blocks between tag and identifier - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 10: TTCN-3 documentation tags
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0002817Part 10: TTCN-3 documentation tagsTechnicalpublic01-02-2008 15:2714-07-2008 14:17
ReporterStephan Schulz 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.2.1 (published 2007-02) 
Target Versionv3.4.1 (published 2008-09)Fixed in Versionv3.4.1 (published 2008-09) 
Source (company - Author)Stephan Schulz - ETSI
Summary0002817: Unclear handling of whitespace in documentation blocks between tag and identifier
DescriptionSection 5.2 of this standard discusses how the body of documentation blocks may be structured. The example used is the desc tag.
+We wonder how flexible the standard is about the whitespace between tags and identifier fields which are required example with param, member or verdict tags.
+
+Example:
+        /**
+          *
+          * @param
+          * p_xyz_ID The Id of the xyz
+          */
+                  function f_foo(integer p_xyz) {}
+
+Is the above ok accroding to the standard or must it be:
+
+        /**
+          *
+          * @param p_xyz_ID The Id of the xyz
+          */
+                  function f_foo(integer p_xyz) {}
+
+
+Maybe a clarifaction could be added in the next edition of the standard.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR2817 - Resolution.doc (77,312) 21-04-2008 20:14
http://oldforge.etsi.org/mantis/file_download.php?file_id=1424&type=bug
Issue History
Date ModifiedUsernameFieldChange
01-02-2008 15:27Stephan SchulzNew Issue
01-02-2008 15:27Stephan SchulzStatusnew => assigned
01-02-2008 15:27Stephan SchulzAssigned To => Gyorgy Rethy
01-02-2008 15:27Stephan SchulzSource (company - Author) => Stephan Schulz - ETSI
01-02-2008 15:32Stephan SchulzRelationship addedrelated to 0002783
10-03-2008 15:40Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
21-04-2008 08:56Ina SchieferdeckerTarget VersionEdition 4.1.1 (not yet published) => Edition 3.4.1 (not yet published)
21-04-2008 20:12Gyorgy RethyNote Added: 0005484
21-04-2008 20:12Gyorgy RethyStatusassigned => closed
21-04-2008 20:13Gyorgy RethyStatusclosed => feedback
21-04-2008 20:13Gyorgy RethyResolutionopen => reopened
21-04-2008 20:13Gyorgy RethyNote Added: 0005485
21-04-2008 20:14Gyorgy RethyFile Added: CR2817 - Resolution.doc
21-04-2008 20:14Gyorgy RethyStatusfeedback => closed
22-04-2008 10:57Gyorgy RethyNote Added: 0005487
22-04-2008 10:57Gyorgy RethyAssigned ToGyorgy Rethy => Thomas Deiß
22-04-2008 10:57Gyorgy RethyStatusclosed => assigned
22-04-2008 10:57Gyorgy RethyNote Added: 0005488
22-04-2008 12:36Thomas DeißNote Added: 0005493
22-04-2008 12:36Thomas DeißAssigned ToThomas Deiß => Gyorgy Rethy
22-04-2008 12:36Thomas DeißStatusassigned => resolved
22-04-2008 12:36Thomas DeißResolutionreopened => fixed
14-07-2008 14:17Ina SchieferdeckerStatusresolved => closed
14-07-2008 14:17Ina SchieferdeckerFixed in Version => Edition 3.4.1 (not yet published)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0005484) +
+ Gyorgy Rethy    +
+ 21-04-2008 20:12    +
+ 		+ + + + +
+ Whitespace will be allowed (to be ignored) between the tag the field following it (i.e. it will not be possible to push indentaton by using spaces, tabs etc. to the generated documents at the beginning of freetext). See attached file.
+
+
+
+ + + + + + + + + + +
+ (0005485) +
+ Gyorgy Rethy    +
+ 21-04-2008 20:13    +
+ 		+ + + + +
+ Reopened to upload file attachment
+
+
+
+ + + + + + + + + + +
+ (0005487) +
+ Gyorgy Rethy    +
+ 22-04-2008 10:57    +
+ 		+ + + + +
+ To be cross-checked
+
+
+
+ + + + + + + + + + +
+ (0005488) +
+ Gyorgy Rethy    +
+ 22-04-2008 10:57    +
+ 		+ + + + +
+ To be cross-checked
+
+
+
+ + + + + + + + + + +
+ (0005493) +
+ Thomas Deiß    +
+ 22-04-2008 12:36    +
+ 		+ + + + +
+ STF 349, Thomas. Checked, and ok.
+
+ + diff --git a/docs/mantis/CR2822.md b/docs/mantis/CR2822.md new file mode 100644 index 0000000000000000000000000000000000000000..e622413c7d1a61d347d7210293841940b0a7ebf5 --- /dev/null +++ b/docs/mantis/CR2822.md @@ -0,0 +1,177 @@ + + + + + + + + + + + + + 0002822: Remove uneccesary limitation - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0002822Part 01: TTCN-3 Core LanguageTechnicalpublic04-02-2008 10:4124-04-2008 12:11
ReporterGyorgy Rethy 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv3.4.1 (published 2008-09)Fixed in Versionv3.4.1 (published 2008-09) 
Clause Reference(s)Part-1 Annex A
Source (company - Author)Ericsson
Summary0002822: Remove uneccesary limitation
DescriptionAnnex A of Part-1 defines:
+106. FieldReference ::= StructFieldRef | ArrayOrBitRef | ParRef
+/* STATIC SEMANTICS - Within FieldReference ArrayOrBitRef can be used for record of and set of templates/template fields in modified templates only*/
+
+The reason disallowing the use of array index notation in (non-modified) templates is unclear. It is just a syntactical mean, it seems that it is being used to enforce semantical rules. On the other hand side, e.g. dash is allowed in record/set of templates:
+113. ArrayElementSpec ::= NotUsedSymbol | PermutationMatch | TemplateBody
+
+
Steps To Reproduce
Additional InformationPropopsal: Resolve this inconsistency: allow index notation and disallow dash in templates.
TagsNo tags attached.
Relationships
Attached Filesdoc CR_2822_Remove_unecessary_limitation-solution_01.doc (1,200,640) 22-04-2008 12:41
http://oldforge.etsi.org/mantis/file_download.php?file_id=1429&type=bug
doc CR_2822_Remove_unecessary_limitation-solution_02.doc (1,198,592) 23-04-2008 18:33
http://oldforge.etsi.org/mantis/file_download.php?file_id=1445&type=bug
Issue History
Date ModifiedUsernameFieldChange
04-02-2008 10:41Gyorgy RethyNew Issue
04-02-2008 10:41Gyorgy RethyClause Reference(s) => Part-1 Annex A
04-02-2008 10:41Gyorgy RethySource (company - Author) => Ericsson
10-03-2008 15:16Ina SchieferdeckerProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
10-03-2008 15:38Thomas DeißNote Added: 0005191
10-03-2008 15:38Ina SchieferdeckerStatusnew => assigned
10-03-2008 15:38Ina SchieferdeckerAssigned To => Thomas Deiß
10-03-2008 15:38Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
22-04-2008 12:41Thomas DeißFile Added: CR_2822_Remove_unecessary_limitation-solution_01.doc
22-04-2008 12:42Thomas DeißNote Added: 0005494
22-04-2008 12:42Thomas DeißAssigned ToThomas Deiß => Gyorgy Rethy
23-04-2008 18:33Gyorgy RethyFile Added: CR_2822_Remove_unecessary_limitation-solution_02.doc
23-04-2008 18:35Gyorgy RethyNote Added: 0005538
23-04-2008 18:35Gyorgy RethyAssigned ToGyorgy Rethy => Thomas Deiß
23-04-2008 18:50Thomas DeißNote Added: 0005540
23-04-2008 18:50Thomas DeißAssigned ToThomas Deiß => Ina Schieferdecker
23-04-2008 18:50Thomas DeißStatusassigned => resolved
23-04-2008 18:50Thomas DeißResolutionopen => fixed
23-04-2008 19:20Ina SchieferdeckerTarget VersionEdition 4.1.1 (not yet published) => Edition 3.4.1 (not yet published)
24-04-2008 12:11Ina SchieferdeckerStatusresolved => closed
24-04-2008 12:11Ina SchieferdeckerFixed in Version => Edition 3.4.1 (not yet published)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0005191) +
+ Thomas Deiß    +
+ 10-03-2008 15:38    +
+ 		+ + + + +
+ STF 349: Solution to be checked, examples would be helpful.
+
+The dash can be kept in the BNF.
+
+
+
+ + + + + + + + + + +
+ (0005494) +
+ Thomas Deiß    +
+ 22-04-2008 12:42    +
+ 		+ + + + +
+ STF349, Thomas:
+Proposal for crosschecking.
+
+
+
+
+ + + + + + + + + + +
+ (0005538) +
+ Gyorgy Rethy    +
+ 23-04-2008 18:35    +
+ 		+ + + + +
+ CR_2822_Remove_unecessary_limitation-solution_02.doc: small editorial changes in clause 6.2.3
+
+
+
+ + + + + + + + + + +
+ (0005540) +
+ Thomas Deiß    +
+ 23-04-2008 18:50    +
+ 		+ + + + +
+ I checked Gyorgy's comments modifications: Ok.
+The comment in the text by Gyorgy (on value list notation) is already taken care of by the comments in the example.
+
+ + diff --git a/docs/mantis/CR2842.md b/docs/mantis/CR2842.md new file mode 100644 index 0000000000000000000000000000000000000000..c247ef7ecf9aa71d538f6e65713ba0d1fea90e1f --- /dev/null +++ b/docs/mantis/CR2842.md @@ -0,0 +1,109 @@ + + + + + + + + + + + + + 0002842: hexadecimal notation for integers - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0002842Part 01: TTCN-3 Core LanguageNew Featurepublic07-02-2008 16:2112-12-2008 12:00
ReporterThomas Deiß 
Assigned To 
PrioritynormalSeverityfeatureReproducibilityN/A
StatusclosedResolutionwon't fix 
PlatformOSOS Version
Product Versionv3.3.2 (published 2008-04) 
Target Versionv4.1.1 (published 2009-06)Fixed in Version 
Clause Reference(s)6.1.0.a, A.1.6.4 (rule for integervalue)
Source (company - Author)Nokia Siemens Networks - Thomas Deiss
Summary0002842: hexadecimal notation for integers
DescriptionMany standards contain literal values for integers which are written in hexadecimal notation. To use the same literals also in a TTCN-3 test suite, they have to be enclosed in a call of hex2int. This can be cumbersome and test suites would become more compact if integer literals could be written in hexadecimal notation. E.g.
+const integer c_dummy := '01AB'H;
+instead of
+const integer c_dummy2 := hex2int('02CD'H);
+
+
Steps To Reproduce
Additional InformationThis CR corresponds to an issue of the ToR of STF 349.
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
07-02-2008 16:21Thomas DeißNew Issue
07-02-2008 16:21Thomas DeißClause Reference(s) => 6.1.0.a, A.1.6.4 (rule for integervalue)
07-02-2008 16:21Thomas DeißSource (company - Author) => Nokia Siemens Networks - Thomas Deiss
10-03-2008 15:15Thomas DeißNote Added: 0005188
10-03-2008 15:15Ina SchieferdeckerStatusnew => closed
10-03-2008 15:15Ina SchieferdeckerNote Added: 0005189
10-03-2008 15:15Ina SchieferdeckerResolutionopen => won't fix
12-12-2008 12:00Ina SchieferdeckerProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
12-12-2008 12:00Ina SchieferdeckerProduct Version => Edition 3.3.2
12-12-2008 12:00Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0005188) +
+ Thomas Deiß    +
+ 10-03-2008 15:15    +
+ 		+ + + + +
+ STF 349:
+In send statements on a port defined as
+port Pt message {out integer, hexstring};
+one cannot distinguish from the literal whether an integer or the hexstring would be send. The typecast will have to be used.
+
+If hexstring notation is allowed, so should be octet string and bitstring.
+
+Conclusion: The gain is marginal, this will not be included.
+
+
+
+ + + + + + + + + + +
+ (0005189) +
+ Ina Schieferdecker    +
+ 10-03-2008 15:15    +
+ 		+ + + + +
+ see note
+
+ + diff --git a/docs/mantis/CR2876.md b/docs/mantis/CR2876.md new file mode 100644 index 0000000000000000000000000000000000000000..85c7fc1a391f98bf8fdee5da8e574fddf8c5c7ae --- /dev/null +++ b/docs/mantis/CR2876.md @@ -0,0 +1,68 @@ + + + + + + + + + + + + + 0002876: incorrect english - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0002876Part 01: TTCN-3 Core LanguageEditorialpublic15-02-2008 10:2821-04-2008 08:55
ReporterThomas Deiß 
Assigned ToIna Schieferdecker 
PrioritylowSeveritytrivialReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.2.1 (published 2007-02) 
Target Versionv3.4.1 (published 2008-09)Fixed in Versionv3.4.1 (published 2008-09) 
Clause Reference(s)6.2.7
Source (company - Author)Nokia Siemens Networks, Thomas Deiß
Summary0002876: incorrect english
Description1st paragraph after Example 1 in clause 6.2.7. reads
+
+'Array elements are accessed by means of the index notation ([]), which must specify a valid index within the array's range. Individual elements of multi-dimensional arrays can access by repeated use of the index notation. Accessing elements outside the array's range will cause a compile-time or test case error'
+
+2nd sentence should be
+... can be accessed by ...
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
15-02-2008 10:28Thomas DeißNew Issue
15-02-2008 10:28Thomas DeißStatusnew => assigned
15-02-2008 10:28Thomas DeißAssigned To => Ina Schieferdecker
15-02-2008 10:28Thomas DeißClause Reference(s) => 6.2.7
15-02-2008 10:28Thomas DeißSource (company - Author) => Nokia Siemens Networks, Thomas Deiß
10-03-2008 15:00Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
12-03-2008 14:27Ina SchieferdeckerResolutionopen => fixed
12-03-2008 14:27Ina SchieferdeckerFixed in Version => Edition 4.1.1 (not yet published)
12-03-2008 14:28Ina SchieferdeckerStatusassigned => closed
12-03-2008 14:28Ina SchieferdeckerNote Added: 0005208
21-04-2008 08:55Ina SchieferdeckerFixed in VersionEdition 4.1.1 (not yet published) => Edition 3.4.1 (not yet published)
21-04-2008 08:55Ina SchieferdeckerTarget VersionEdition 4.1.1 (not yet published) => Edition 3.4.1 (not yet published)
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0005208) +
+ Ina Schieferdecker    +
+ 12-03-2008 14:28    +
+ 		+ + + + +
+ As proposed
+
+ + diff --git a/docs/mantis/CR2938.md b/docs/mantis/CR2938.md new file mode 100644 index 0000000000000000000000000000000000000000..0b907f6cf201868e0d2d4c65310d6b8a3987c0af --- /dev/null +++ b/docs/mantis/CR2938.md @@ -0,0 +1,66 @@ + + + + + + + + + + + + + 0002938: Port parameters are identified by the port type - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0002938Part 01: TTCN-3 Core LanguageEditorialpublic25-02-2008 13:0521-04-2008 08:54
ReporterGyorgy Rethy 
Assigned ToIna Schieferdecker 
PrioritynormalSeveritytextReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv3.4.1 (published 2008-09)Fixed in Versionv3.4.1 (published 2008-09) 
Clause Reference(s)Part 1 $5.4.1.4
Source (company - Author)L.M. Ericsson
Summary0002938: Port parameters are identified by the port type
DescriptionThe last sentence of the Semantic Description part of clause 5.4.1.4 says:
+"Formal port parameters are identified by the keyword port."
+
+It should be deleted as there is no specific identification of port formal parameters (identified by their types as e.g. data parameters).
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
25-02-2008 13:05Gyorgy RethyNew Issue
25-02-2008 13:05Gyorgy RethyClause Reference(s) => Part 1 $5.4.1.4
25-02-2008 13:05Gyorgy RethySource (company - Author) => L.M. Ericsson
10-03-2008 14:59Ina SchieferdeckerProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
10-03-2008 14:59Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
10-03-2008 15:09Ina SchieferdeckerStatusnew => assigned
10-03-2008 15:09Ina SchieferdeckerAssigned To => Ina Schieferdecker
12-03-2008 14:43Ina SchieferdeckerStatusassigned => resolved
12-03-2008 14:43Ina SchieferdeckerFixed in Version => Edition 4.1.1 (not yet published)
12-03-2008 14:43Ina SchieferdeckerResolutionopen => fixed
12-03-2008 14:43Ina SchieferdeckerNote Added: 0005212
12-03-2008 14:44Ina SchieferdeckerStatusresolved => closed
21-04-2008 08:54Ina SchieferdeckerFixed in VersionEdition 4.1.1 (not yet published) => Edition 3.4.1 (not yet published)
21-04-2008 08:54Ina SchieferdeckerTarget VersionEdition 4.1.1 (not yet published) => Edition 3.4.1 (not yet published)
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0005212) +
+ Ina Schieferdecker    +
+ 12-03-2008 14:43    +
+ 		+ + + + +
+ As proposed.
+
+ + diff --git a/docs/mantis/CR2975.md b/docs/mantis/CR2975.md new file mode 100644 index 0000000000000000000000000000000000000000..5bb77c9acbf01b6f00ae7073fdbd1b649d9b5107 --- /dev/null +++ b/docs/mantis/CR2975.md @@ -0,0 +1,266 @@ + + + + + + + + + + + + + 0002975: Allow specification of non-optional templates - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0002975Part 01: TTCN-3 Core LanguageNew Featurepublic04-03-2008 10:0124-04-2008 19:06
Reporteruser324 
Assigned ToIna Schieferdecker 
PrioritynormalSeveritymajorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv3.4.1 (published 2008-09)Fixed in Versionv3.4.1 (published 2008-09) 
Clause Reference(s)A.1.6.5, A.1.6.1.4, 11.2, 5.4.1.2, 16.1
Source (company - Author)Testing Technologies - Jacob Wieland
Summary0002975: Allow specification of non-optional templates
DescriptionAt the moment, it is not possible to declare a template parameter, template variable or template return type in such a way that it describes only templates which do not match the special value 'omit', i.e. templates which can only be used for non-optional fields.
+
+Since expressions containing matching mechanisms can only be passed to parameters with a template modifier, the type 'template T' must, at the moment be interpreted as: all expressions of type T which match values of type T or the value 'omit', so that they can be used to be assigned to optional fields. However, since there is no way to say that an arbitrary template expression does _not_ match 'omit', a compiler needs to produce a warning whenever a template parameter (or template variable or template return value) is assigned to a non-optional field, since this can lead to a runtime-error. Static checking to avoid this situation is nearly impossible and at best takes a very high computational effort (for a small gain).
+
+Therefore, the following solution is proposed to enhance the expressivity of the
+TTCN-3 type language:
+
+Allow the keyword 'ispresent' to be put (optionally) behind every occurrence of the keyword 'template'. The semantics of the type 'template ispresent T' would be all expressions of type T which do not match the special vaule 'omit'. This would mean that such a template can be safely used in an assignment to a non-optional field. Also, each non-optional field of a template would automatically have the type 'template ispresent T', if the field was declared as of type T.
+
+As far as I can see, the following rules have to be changed in the BNF in
+the following way:
+- TemplateRestriction ::= "(" OmitKeyword ")" | IsPresentKeyword
+- PreDefFunctionIdentifier ::= Identifier | IsPresentKeyword
+
+and one new rule introduced:
+
+- IsPresentKeyword ::= "ispresent"
+
+This approach would have the advantage that no new identifier needs to be reserved, causing minimal backward compatibility issues for old Testsuites, their semantics would stay unchanged.
+
+Alternatively, I would propose the new keyword 'present' instead of using 'ispresent'. This would have the drawback that a new keyword needs to be reserved (causing possible backward compatibility issues for old testsuites,
+i.e. maintenance overhead for converting them to newer TTCN-3). But, the
+PreDefFunctionIdentifier rule need not be changed in the BNF. For this alternative, change all 'ispresent' occurrences in the above description to 'present' and remove the change for the rule for PreDefFunctionIdentifier.
+
+The name of the new modifier ispresent/present was chosen to match the semantics of the already existing constructs 'ispresent(field)' and '<template> ifpresent', where 'present' always means 'not omit'. Thus, the semantics of the new construct would be easily understandable for users of TTCN-3.
Steps To Reproduce
Additional InformationSection 16.1. about functions also needs to be changed to align it with the BNF.
+In the section, only the keyword 'template' is allowed in the return clause, but the BNF states, that it also allows a 'RestrictedTemplate'.
+
TagsNo tags attached.
Relationships
Attached Filesdoc TemplateRestrictions.doc (31,744) 14-03-2008 12:23
http://oldforge.etsi.org/mantis/file_download.php?file_id=1383&type=bug
? PreciseTemplates.ttcn (7,076) 14-03-2008 16:03
http://oldforge.etsi.org/mantis/file_download.php?file_id=1385&type=bug
zip CR_2975_Allow_specification_of_non-optional_templates_02.zip (848,125) 22-04-2008 12:24
http://oldforge.etsi.org/mantis/file_download.php?file_id=1428&type=bug
zip CR_2975_Allow_specification_of_non-optional_templates_03.zip (831,254) 22-04-2008 16:15
http://oldforge.etsi.org/mantis/file_download.php?file_id=1433&type=bug
doc CR_2975_Allow_specification_of_non-optional_templates_04.doc (1,650,176) 22-04-2008 19:53
http://oldforge.etsi.org/mantis/file_download.php?file_id=1436&type=bug
? TemplateRestrictionsTest.ttcn (14,519) 22-04-2008 19:53
http://oldforge.etsi.org/mantis/file_download.php?file_id=1437&type=bug
doc CR_2975_Allow_specification_of_non-optional_templates_05.doc (1,660,928) 23-04-2008 19:18
http://oldforge.etsi.org/mantis/file_download.php?file_id=1448&type=bug
Issue History
Date ModifiedUsernameFieldChange
04-03-2008 10:01user324New Issue
04-03-2008 10:01user324Statusnew => assigned
04-03-2008 10:01user324Assigned To => Ina Schieferdecker
04-03-2008 10:01user324Clause Reference(s) => A.1.6.5, A.1.6.1.4, 11.2, 5.4.1.2, 16.1
04-03-2008 10:01user324Source (company - Author) => Testing Technologies - Jacob Wieland
10-03-2008 14:55Thomas DeißNote Added: 0005186
10-03-2008 14:55Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
14-03-2008 12:23Ina SchieferdeckerFile Added: TemplateRestrictions.doc
14-03-2008 16:03Thomas DeißFile Added: PreciseTemplates.ttcn
17-03-2008 09:47user324Note Added: 0005244
21-04-2008 08:54Ina SchieferdeckerAssigned ToIna Schieferdecker => Gyorgy Rethy
21-04-2008 08:54Ina SchieferdeckerTarget VersionEdition 4.1.1 (not yet published) => Edition 3.4.1 (not yet published)
22-04-2008 12:24Thomas DeißFile Added: CR_2975_Allow_specification_of_non-optional_templates_02.zip
22-04-2008 12:26Thomas DeißNote Added: 0005492
22-04-2008 15:58Gyorgy RethyFile Added: CR_2975_Allow_specification_of_non-optional_templates_03.zip
22-04-2008 16:15Gyorgy RethyFile Deleted: CR_2975_Allow_specification_of_non-optional_templates_03.zip
22-04-2008 16:15Gyorgy RethyFile Added: CR_2975_Allow_specification_of_non-optional_templates_03.zip
22-04-2008 16:17Gyorgy RethyNote Added: 0005497
22-04-2008 16:19Gyorgy RethyNote Added: 0005498
22-04-2008 16:19Gyorgy RethyAssigned ToGyorgy Rethy => Thomas Deiß
22-04-2008 19:53Thomas DeißFile Added: CR_2975_Allow_specification_of_non-optional_templates_04.doc
22-04-2008 19:53Thomas DeißFile Added: TemplateRestrictionsTest.ttcn
22-04-2008 19:56Thomas DeißNote Added: 0005509
22-04-2008 19:56Thomas DeißAssigned ToThomas Deiß => Ina Schieferdecker
23-04-2008 19:18Ina SchieferdeckerFile Added: CR_2975_Allow_specification_of_non-optional_templates_05.doc
23-04-2008 19:19Ina SchieferdeckerResolutionopen => fixed
23-04-2008 19:22Ina SchieferdeckerStatusassigned => resolved
24-04-2008 19:06Ina SchieferdeckerStatusresolved => closed
24-04-2008 19:06Ina SchieferdeckerFixed in Version => Edition 3.4.1 (not yet published)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0005186) +
+ Thomas Deiß    +
+ 10-03-2008 14:55    +
+ 		+ + + + +
+ related to introduction of restricted templates in edition 3.3.
+Potentially related to discussion of usage of valueof.
+
+
+
+ + + + + + + + + + +
+ (0005244) +
+ user324    +
+ 17-03-2008 09:47    +
+ 		+ + + + +
+ I have a problem with the PreciceTemplates example:
+
+template(omit) templates should also not be allowed to contain matching mechanisms (i.e. no ifpresent and no complement, as used in your examples), otherwise, you can pass such a template to a template(omit) parameter of a generic template(value) template and still get a runtime error if you send this 'value'.
+
+
+
+ + + + + + + + + + +
+ (0005492) +
+ Thomas Deiß    +
+ 22-04-2008 12:26    +
+ 		+ + + + +
+ STF349, Thomas:
+First draft for review. The major change is a new clause (15.8) on template restrictions, some other changes are in the BNF and in the explanation of template parameters.
+
+
+
+ + + + + + + + + + +
+ (0005497) +
+ Gyorgy Rethy    +
+ 22-04-2008 16:17    +
+ 		+ + + + +
+ Uploaded my comemnts in CR_2975_Allow_specification_of_non-optional_templates_03.zip. There are text enhancements only, no principal issues.
+
+
+
+ + + + + + + + + + +
+ (0005498) +
+ Gyorgy Rethy    +
+ 22-04-2008 16:19    +
+ 		+ + + + +
+ Thomas, I assigned it to you for review but Ina should also review it.
+
+
+
+ + + + + + + + + + +
+ (0005509) +
+ Thomas Deiß    +
+ 22-04-2008 19:56    +
+ 		+ + + + +
+ Removed irrelevant clauses, rules in BNF that need to be changed are highlighted, some minor corrections to changes proposed by Gyorgy.
+Supplementary TTCN-3 file uploaded, this can be seen as tests for this feature.
+
+After crosscheck by Ina, there should be another final crosscheck by Gyorgy.
+
+ + diff --git a/docs/mantis/CR2976.md b/docs/mantis/CR2976.md new file mode 100644 index 0000000000000000000000000000000000000000..9dc48f316b93ccdcbe0b3f48d3fa668c3f4bf43f --- /dev/null +++ b/docs/mantis/CR2976.md @@ -0,0 +1,108 @@ + + + + + + + + + + + + + 0002976: do not allow control characters in literal string denotation - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0002976Part 01: TTCN-3 Core LanguageClarificationpublic04-03-2008 10:1421-04-2008 08:53
Reporteruser324 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv3.4.1 (published 2008-09)Fixed in Versionv3.4.1 (published 2008-09) 
Clause Reference(s)6.1.1 d)
Source (company - Author)Testing Technologies - Jacob Wieland
Summary0002976: do not allow control characters in literal string denotation
DescriptionChange the following sentence in section 6.1.1 d)
+
+Values of charstring type shall be denoted by an arbitrary number (possibly zero) of characters from the relevant character set, preceded and followed by double quote (")
+
+into:
+
+Values of charstring type shall be denoted by an arbitrary number (possibly zero) of non-control characters from the relevant character set, preceded and followed by double quote (")
+
+This shall clarify what Note 5 already hints at, i.e. that control characters can ONLY be denoted via the char() or int2str() methods. Up to now, the standard is ambiguous. Either Note 5 does not make sense or the above (original) sentence allows too many characters to be put between the double quotes.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0003268closed Ina Schieferdecker Allowed content of a charstring is not completely degined 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
04-03-2008 10:14user324New Issue
04-03-2008 10:14user324Statusnew => assigned
04-03-2008 10:14user324Assigned To => Ina Schieferdecker
04-03-2008 10:14user324Clause Reference(s) => 6.1.1 d)
04-03-2008 10:14user324Source (company - Author) => Testing Technologies - Jacob Wieland
10-03-2008 14:49Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
10-03-2008 14:51Thomas DeißNote Added: 0005185
12-03-2008 14:41Ina SchieferdeckerStatusassigned => resolved
12-03-2008 14:41Ina SchieferdeckerFixed in Version => Edition 4.1.1 (not yet published)
12-03-2008 14:41Ina SchieferdeckerResolutionopen => fixed
12-03-2008 14:41Ina SchieferdeckerNote Added: 0005211
12-03-2008 14:42Ina SchieferdeckerStatusresolved => closed
21-04-2008 08:53Ina SchieferdeckerFixed in VersionEdition 4.1.1 (not yet published) => Edition 3.4.1 (not yet published)
21-04-2008 08:53Ina SchieferdeckerTarget VersionEdition 4.1.1 (not yet published) => Edition 3.4.1 (not yet published)
12-12-2008 16:01Ina SchieferdeckerRelationship addedrelated to 0003268
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0005185) +
+ Thomas Deiß    +
+ 10-03-2008 14:51    +
+ 		+ + + + +
+ Proposed solution:
+Literal values of type charstring can contain the 'Graphic characters' of ISO 646.
+
+Graphic characters: 32-126
+
+
+
+ + + + + + + + + + +
+ (0005211) +
+ Ina Schieferdecker    +
+ 12-03-2008 14:41    +
+ 		+ + + + +
+ As proposed.
+
+ + diff --git a/docs/mantis/CR3011.md b/docs/mantis/CR3011.md new file mode 100644 index 0000000000000000000000000000000000000000..924f03482bcfd5284ec30b1d51d5ccec1dc49310 --- /dev/null +++ b/docs/mantis/CR3011.md @@ -0,0 +1,345 @@ + + + + + + + + + + + + + 0003011: Remove type parameterization from BNF - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0003011Part 01: TTCN-3 Core LanguageEditorialpublic10-03-2008 10:2009-12-2008 16:08
ReporterThomas Deiß 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)Annex A
Source (company - Author)Nokia Siemens Networks - Thomas Deiß
Summary0003011: Remove type parameterization from BNF
DescriptionThe BNF still contains type parameterization for structured types. Both type definitions as well as references to types can have parameters according to the BNF. Type parameterization has been removed already some editions in the past, and clause 6 on type definitions does not mention type parameters. To avoid misunderstandings the BNF should be corrected.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0000403closed Gyorgy Rethy Port type parameterisation of component types 
Attached Filesdoc CR3011.doc (52,736) 12-03-2008 14:36
http://oldforge.etsi.org/mantis/file_download.php?file_id=1370&type=bug
doc CR3011_v2.doc (87,552) 09-12-2008 14:58
http://oldforge.etsi.org/mantis/file_download.php?file_id=1874&type=bug
Issue History
Date ModifiedUsernameFieldChange
10-03-2008 10:20Thomas DeißNew Issue
10-03-2008 10:20Thomas DeißClause Reference(s) => Apnnex A
10-03-2008 10:20Thomas DeißSource (company - Author) => Nokia Siemens Networks - Thomas Deiß
10-03-2008 14:44Thomas DeißAssigned To => Ina Schieferdecker
10-03-2008 14:44Thomas DeißStatusnew => assigned
10-03-2008 14:44Ina SchieferdeckerCategoryClarification => Editorial
10-03-2008 14:45Ina SchieferdeckerProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
10-03-2008 14:45Ina SchieferdeckerClause Reference(s)Apnnex A => Annex A
10-03-2008 14:45Ina SchieferdeckerFixed in Version => Edition 4.1.1 (not yet published)
10-03-2008 14:48Ina SchieferdeckerFixed in VersionEdition 4.1.1 (not yet published) =>
10-03-2008 14:48Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
12-03-2008 14:36Ina SchieferdeckerFile Added: CR3011.doc
12-03-2008 14:38Ina SchieferdeckerNote Added: 0005209
12-03-2008 14:38Ina SchieferdeckerAssigned ToIna Schieferdecker => Thomas Deiß
12-03-2008 14:38Ina SchieferdeckerStatusassigned => confirmed
12-03-2008 14:38Ina SchieferdeckerNote Added: 0005210
12-03-2008 15:05Thomas DeißNote Added: 0005214
12-03-2008 15:25Thomas DeißNote Edited: 0005214
12-03-2008 15:31Thomas DeißNote Added: 0005215
12-03-2008 15:31Thomas DeißStatusconfirmed => assigned
12-03-2008 15:31Thomas DeißAssigned ToThomas Deiß => Ina Schieferdecker
12-03-2008 15:53Ina SchieferdeckerNote Deleted: 0005209
12-03-2008 15:55Ina SchieferdeckerNote Added: 0005216
15-07-2008 13:12Ina SchieferdeckerNote Added: 0006278
24-11-2008 10:54Ina SchieferdeckerRelationship addedrelated to 0000403
28-11-2008 08:17Ina SchieferdeckerNote Added: 0007490
09-12-2008 14:58Ina SchieferdeckerFile Added: CR3011_v2.doc
09-12-2008 14:58Ina SchieferdeckerNote Added: 0007600
09-12-2008 14:58Ina SchieferdeckerAssigned ToIna Schieferdecker => Thomas Deiß
09-12-2008 14:58Ina SchieferdeckerResolutionopen => fixed
09-12-2008 15:14Thomas DeißNote Added: 0007603
09-12-2008 15:14Thomas DeißAssigned ToThomas Deiß => Ina Schieferdecker
09-12-2008 15:42Ina SchieferdeckerStatusassigned => resolved
09-12-2008 15:42Ina SchieferdeckerFixed in Version => Edition 4.1.1 (not yet published)
09-12-2008 15:43Ina SchieferdeckerStatusresolved => closed
09-12-2008 16:08Ina SchieferdeckerNote Added: 0007608
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0005210) +
+ Ina Schieferdecker    +
+ 12-03-2008 14:38    +
+ 		+ + + + +
+ Please check the resolution in the attached file.
+
+
+
+ + + + + + + + + + +
+ (0005214) +
+ Thomas Deiß    +
+ 12-03-2008 15:05    +
(edited on: 12-03-2008 15:25)
+ 		+ + + + +
+ Table 2 mentions type parameterization, check also the notes.
+clause 5.4.1, paragraph 2, mentions types.
+Note 2 within clause 5.4.1 is strange.
+clause 5.4.1.1, bullet 2 within semantics should be removed.
+clause 5.4.1.1, restriction, bullet b) ==> remove reference to types.
+
+
+
+
+
+ + + + + + + + + + +
+ (0005215) +
+ Thomas Deiß    +
+ 12-03-2008 15:31    +
+ 		+ + + + +
+ UnionDefBody ::= (StructTypeIdentifier [StructDefFormalParList] | AddressKeyword)
+                     "{" UnionFieldDef {"," UnionFieldDef} "}"
+
+
+
+ + + + + + + + + + +
+ (0005216) +
+ Ina Schieferdecker    +
+ 12-03-2008 15:55    +
+ 		+ + + + +
+ Just realizing that value parameters to types have not yet been removed in the past. Hence, we rather need a discussion if to remove or if to add explaination what type parameterization means.
+
+
+
+ + + + + + + + + + +
+ (0006278) +
+ Ina Schieferdecker    +
+ 15-07-2008 13:12    +
+ 		+ + + + +
+ Await the resolution to 403 and the general question of type parameterization in TTCN-3
+
+
+
+ + + + + + + + + + +
+ (0007490) +
+ Ina Schieferdecker    +
+ 28-11-2008 08:17    +
+ 		+ + + + +
+ Type parameterization will be defined explicitly in the new type parameterization package - see CR403.
+
+Hence, type parameterization is to be removed in part 1.
+
+
+
+ + + + + + + + + + +
+ (0007600) +
+ Ina Schieferdecker    +
+ 09-12-2008 14:58    +
+ 		+ + + + +
+ Please check.
+
+
+
+ + + + + + + + + + +
+ (0007603) +
+ Thomas Deiß    +
+ 09-12-2008 15:14    +
+ 		+ + + + +
+ ok.
+
+
+
+
+ + + + + + + + + + +
+ (0007608) +
+ Ina Schieferdecker    +
+ 09-12-2008 16:08    +
+ 		+ + + + +
+ Also in Table 8 on Possible local and referenced definitions of importable definitions, parameters for user-defined types had to be deleted.
+
+ + diff --git a/docs/mantis/CR3023.md b/docs/mantis/CR3023.md new file mode 100644 index 0000000000000000000000000000000000000000..4525dbe4c45cd37da41f706a9462d6588a4e4460 --- /dev/null +++ b/docs/mantis/CR3023.md @@ -0,0 +1,104 @@ + + + + + + + + + + + + + 0003023: Usage of "should" in part 1 - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0003023Part 01: TTCN-3 Core LanguageEditorialpublic13-03-2008 18:2813-08-2008 16:31
ReporterIna Schieferdecker 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)Whole Part 1
Source (company - Author)     
Summary0003023: Usage of "should" in part 1
Description"Should" is quite often used in part 1 - even at places where it means rather "shall".
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Fileszip es_20187301v040000_MasterCopy_180708.zip (882,397) 18-07-2008 11:34
http://oldforge.etsi.org/mantis/file_download.php?file_id=1568&type=bug
zip es_20187301v040000_MasterCopy_130808.zip (890,005) 13-08-2008 16:30
http://oldforge.etsi.org/mantis/file_download.php?file_id=1594&type=bug
Issue History
Date ModifiedUsernameFieldChange
13-03-2008 18:28Ina SchieferdeckerNew Issue
13-03-2008 18:28Ina SchieferdeckerStatusnew => assigned
13-03-2008 18:28Ina SchieferdeckerAssigned To => Ina Schieferdecker
13-03-2008 18:28Ina SchieferdeckerClause Reference(s) => Whole Part 1
13-03-2008 18:28Ina SchieferdeckerSource (company - Author) =>
21-04-2008 09:01Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
18-07-2008 11:34Ina SchieferdeckerFile Added: es_20187301v040000_MasterCopy_180708.zip
18-07-2008 11:35Ina SchieferdeckerNote Added: 0006337
18-07-2008 11:35Ina SchieferdeckerAssigned ToIna Schieferdecker => Thomas Deiß
18-07-2008 11:35Ina SchieferdeckerResolutionopen => fixed
18-07-2008 15:09Thomas DeißNote Added: 0006341
18-07-2008 15:09Thomas DeißAssigned ToThomas Deiß => Ina Schieferdecker
18-07-2008 15:09Thomas DeißResolutionfixed => open
13-08-2008 16:29Ina SchieferdeckerStatusassigned => resolved
13-08-2008 16:29Ina SchieferdeckerResolutionopen => fixed
13-08-2008 16:29Ina SchieferdeckerFixed in Version => Edition 4.1.1 (not yet published)
13-08-2008 16:30Ina SchieferdeckerFile Added: es_20187301v040000_MasterCopy_130808.zip
13-08-2008 16:31Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0006337) +
+ Ina Schieferdecker    +
+ 18-07-2008 11:35    +
+ 		+ + + + +
+ shall has been replaced where appropriate
+
+(note that the the uploaded resolution also contains other CR fixes - the resulution of this CR relates only to the handling of "should")
+
+
+
+ + + + + + + + + + +
+ (0006341) +
+ Thomas Deiß    +
+ 18-07-2008 15:09    +
+ 		+ + + + +
+ Almost ok.
+
+clause 15.6.1, line 1: font of 'substr' should be courier
+clause 19.11, paragraph before NOTE: font of 'log' should be courier. two instances of 'should' -> 'shall'
+
+After correction, no additional check needed.
+
+ + diff --git a/docs/mantis/CR3025.md b/docs/mantis/CR3025.md new file mode 100644 index 0000000000000000000000000000000000000000..aac5de996631b1378a66bf8ff3d918638435ec8f --- /dev/null +++ b/docs/mantis/CR3025.md @@ -0,0 +1,101 @@ + + + + + + + + + + + + + 0003025: return statement in altsteps - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0003025Part 01: TTCN-3 Core LanguageClarificationpublic14-03-2008 08:4209-05-2008 11:57
ReporterThomas Deiß 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv3.4.1 (published 2008-09)Fixed in Versionv3.4.1 (published 2008-09) 
Clause Reference(s)19.10
Source (company - Author)Nokia Siemens Networks - Thomas Deiß
Summary0003025: return statement in altsteps
DescriptionThe note in clause 19.10 can be understood that executing a return statement in an altsteps means to leave the enclosing alt statement. This is not the intention and should be written more clearly.
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR3025-Resolution-V1.doc (123,904) 22-04-2008 15:30
http://oldforge.etsi.org/mantis/file_download.php?file_id=1431&type=bug
Issue History
Date ModifiedUsernameFieldChange
14-03-2008 08:42Thomas DeißNew Issue
14-03-2008 08:42Thomas DeißStatusnew => assigned
14-03-2008 08:42Thomas DeißAssigned To => Thomas Deiß
14-03-2008 08:42Thomas DeißClause Reference(s) => 19.10
14-03-2008 08:42Thomas DeißSource (company - Author) => Nokia Siemens Networks - Thomas Deiß
14-03-2008 08:43Thomas DeißProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
14-03-2008 09:14Thomas DeißAssigned ToThomas Deiß => Jens Grabowski
22-04-2008 15:30Jens GrabowskiFile Added: CR3025-Resolution-V1.doc
22-04-2008 15:31Jens GrabowskiNote Added: 0005496
22-04-2008 15:32Jens GrabowskiAssigned ToJens Grabowski => Thomas Deiß
22-04-2008 20:24Thomas DeißNote Added: 0005510
22-04-2008 20:24Thomas DeißAssigned ToThomas Deiß => Ina Schieferdecker
22-04-2008 20:24Thomas DeißStatusassigned => resolved
22-04-2008 20:24Thomas DeißResolutionopen => fixed
09-05-2008 11:57Ina SchieferdeckerTarget Version => Edition 3.4.1 (not yet published)
09-05-2008 11:57Ina SchieferdeckerStatusresolved => closed
09-05-2008 11:57Ina SchieferdeckerFixed in Version => Edition 3.4.1 (not yet published)
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0005496) +
+ Jens Grabowski    +
+ 22-04-2008 15:31    +
+ 		+ + + + +
+ I tried to rephrase the Note.
+
+I believe that the note should become normal standard text.
+
+
+
+ + + + + + + + + + +
+ (0005510) +
+ Thomas Deiß    +
+ 22-04-2008 20:24    +
+ 		+ + + + +
+ STF 349, Thomas:
+checked and Ok.
+
+ + diff --git a/docs/mantis/CR3039.md b/docs/mantis/CR3039.md new file mode 100644 index 0000000000000000000000000000000000000000..e455196fe44912cd09bf9e65876e0382add657c2 --- /dev/null +++ b/docs/mantis/CR3039.md @@ -0,0 +1,217 @@ + + + + + + + + + + + + + 0003039: Unclear semantics of any/all port - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0003039Part 01: TTCN-3 Core LanguageClarificationpublic17-03-2008 09:3509-05-2008 11:53
ReporterThomas Deiß 
Assigned ToIna Schieferdecker 
PrioritynormalSeveritymajorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv3.4.1 (published 2008-09)Fixed in Versionv3.4.1 (published 2008-09) 
Clause Reference(s)part 1, part4
Source (company - Author)Nokia Siemens Networks - Thomas Deiß
Summary0003039: Unclear semantics of any/all port
DescriptionIn case that the actual test component is an extension of the runs on clause of the behaviour statement containing an any/all port operation, it is not clear whether the ports in the runs on clause or those of the actual test component shall be considered.
+The operational semantics refers in this case to a part of the state that is defined on the module level, i.e. global for the whole test case.
+The semantics needs to be checked and defined clearly.
Steps To Reproduce
Additional InformationIn part 1) this question is not touched. In clause 22.2.2 it is simply
+stated:
+Receive on any port
+To receive a message on any port, use the any port keywords.
+
+The operational semantics (part 4) explains the use of 'any port.receive' by refering to ALL-PORT-STATES, which is a global list of ports. In this case this is actually global per test case, not per module! At least this is my understanding. I assume that the intention is that this should be global per test component, but this is an assumption.
+
TagsNo tags attached.
Relationships
Attached Filesdoc CR-3039-Clearification-Any-All-Port.doc (131,584) 23-04-2008 15:19
http://oldforge.etsi.org/mantis/file_download.php?file_id=1440&type=bug
doc CR-3039-Corrections-to-part-4-related-to-the-use-of-any-and-all-port.doc (700,416) 27-04-2008 14:33
http://oldforge.etsi.org/mantis/file_download.php?file_id=1467&type=bug
Issue History
Date ModifiedUsernameFieldChange
17-03-2008 09:35Thomas DeißNew Issue
17-03-2008 09:35Thomas DeißStatusnew => assigned
17-03-2008 09:35Thomas DeißAssigned To => Jens Grabowski
17-03-2008 09:35Thomas DeißClause Reference(s) => part 1, part4
17-03-2008 09:35Thomas DeißSource (company - Author) => Nokia Siemens Networks - Thomas Deiß
22-04-2008 18:10Jens GrabowskiNote Added: 0005506
23-04-2008 11:02Jens GrabowskiNote Added: 0005512
23-04-2008 15:19Jens GrabowskiNote Added: 0005520
23-04-2008 15:19Jens GrabowskiFile Added: CR-3039-Clearification-Any-All-Port.doc
23-04-2008 15:21Jens GrabowskiAssigned ToJens Grabowski => Gyorgy Rethy
23-04-2008 18:49Gyorgy RethyNote Added: 0005539
23-04-2008 18:49Gyorgy RethyAssigned ToGyorgy Rethy => Jens Grabowski
24-04-2008 09:23Jens GrabowskiNote Added: 0005547
27-04-2008 14:32Jens GrabowskiNote Deleted: 0005547
27-04-2008 14:33Jens GrabowskiFile Added: CR-3039-Corrections-to-part-4-related-to-the-use-of-any-and-all-port.doc
27-04-2008 14:35Jens GrabowskiNote Added: 0005584
27-04-2008 14:37Jens GrabowskiAssigned ToJens Grabowski => Ina Schieferdecker
27-04-2008 14:37Jens GrabowskiStatusassigned => resolved
27-04-2008 14:37Jens GrabowskiResolutionopen => fixed
09-05-2008 11:50Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
09-05-2008 11:53Ina SchieferdeckerStatusresolved => closed
09-05-2008 11:53Ina SchieferdeckerFixed in Version => Edition 3.4.1 (not yet published)
09-05-2008 11:53Ina SchieferdeckerTarget VersionEdition 4.1.1 (not yet published) => Edition 3.4.1 (not yet published)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0005506) +
+ Jens Grabowski    +
+ 22-04-2008 18:10    +
+ 		+ + + + +
+ In the operational semantics ports are owned by a component. Each time when a new component is created, all ports specified by the component type are instantiated.
+
+Afterwards, the operational semantics does not care about the runs-on type, because the consistency of runs-on type and type of the created component can be checked by other means than the operational semantics.
+
+The operational semantics assumes that any port and all port are related to all ports of a component independent of whether they are known via a runs-on clause of a test case, function or altstep or not.
+
+This is in line with the latest changes to timers and the handling of defaults.
+
+This meaning has to be clearified in part 1 of the standard.
+
+
+
+ + + + + + + + + + +
+ (0005512) +
+ Jens Grabowski    +
+ 23-04-2008 11:02    +
+ 		+ + + + +
+ Disconnect and unmap operations have to be added in Table 21.
+
+
+
+ + + + + + + + + + +
+ (0005520) +
+ Jens Grabowski    +
+ 23-04-2008 15:19    +
+ 		+ + + + +
+ Find proposal enclosed. Instead of adding a note everywhere, I propose to add only one note to clause 22.6.
+
+
+
+ + + + + + + + + + +
+ (0005539) +
+ Gyorgy Rethy    +
+ 23-04-2008 18:49    +
+ 		+ + + + +
+ OK with me.
+
+
+
+ + + + + + + + + + +
+ (0005584) +
+ Jens Grabowski    +
+ 27-04-2008 14:35    +
+ 		+ + + + +
+ This CR has also been used for corrections in Part 4 related to the use of any and all for port and communication operations.
+
+The halt operation is not covered, because there is another CR on introducing the halt operation into the operational semantics.
+
+ + diff --git a/docs/mantis/CR3238.md b/docs/mantis/CR3238.md new file mode 100644 index 0000000000000000000000000000000000000000..1b462d12b07b6b554519fca08c011c2e3eb141d4 --- /dev/null +++ b/docs/mantis/CR3238.md @@ -0,0 +1,63 @@ + + + + + + + + + + + + + 0003238: Normative text shall use "shall" - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0003238Part 09: Using XML with TTCN-3Editorialpublic22-04-2008 12:1514-10-2008 17:33
ReporterGyorgy Rethy 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.1.1 (published 2009-06)Fixed in Version 
Clause Reference(s)all
For STF discussion
Source (company - Author)     
Summary0003238: Normative text shall use "shall"
DescriptionIn general, the text uses "is", "are" "will", "has to" and "needs to" when normative requirements are given. These shall be replaced by "shall be" throughout the text.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
22-04-2008 12:15Gyorgy RethyNew Issue
22-04-2008 12:15Gyorgy RethyStatusnew => assigned
22-04-2008 12:15Gyorgy RethyAssigned To => Ina Schieferdecker
22-04-2008 12:15Gyorgy RethyClause Reference(s) => all
22-04-2008 12:15Gyorgy RethySource (company - Author) =>
09-05-2008 10:32Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
13-10-2008 09:12Gyorgy RethyNote Added: 0007034
14-10-2008 17:33Gyorgy RethyStatusassigned => closed
14-10-2008 17:33Gyorgy RethyResolutionopen => fixed
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0007034) +
+ Gyorgy Rethy    +
+ 13-10-2008 09:12    +
+ 		+ + + + +
+ Done in version v3.3.2 (uploaded for the last MTS meeting. Pls. cross-check.
+
+ + diff --git a/docs/mantis/CR3241.md b/docs/mantis/CR3241.md new file mode 100644 index 0000000000000000000000000000000000000000..cbcc7684fb6484fbdbb2c5d283112360d05b70a2 --- /dev/null +++ b/docs/mantis/CR3241.md @@ -0,0 +1,31 @@ + + + + + + + + + + + + + 0003241: Optional statement block following altstep calls in alt statements - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 04: TTCN-3 Operational Semantics
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0003241Part 04: TTCN-3 Operational SemanticsTechnicalpublic22-04-2008 13:1720-04-2009 11:41
ReporterJens Grabowski 
Assigned ToGyorgy Rethy 
PrioritynormalSeveritymajorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)9.3.3
Source (company - Author)     Jens Grabowski (STF 347)
Summary0003241: Optional statement block following altstep calls in alt statements
DescriptionTTCN-3 allows optional statement blocks following altstep calls in alt statements. These optional statement blocks are executed if one of the alternative in the altstep has been executed.
+
+The handling of the optional statement block is not covered in the operational semantics.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR-3241-Optional-statement-block-following-altstep-calls-JG-V1.doc (96,768) 02-01-2009 09:46
http://oldforge.etsi.org/mantis/file_download.php?file_id=1931&type=bug
Issue History
Date ModifiedUsernameFieldChange
22-04-2008 13:17Jens GrabowskiNew Issue
22-04-2008 13:17Jens GrabowskiStatusnew => assigned
22-04-2008 13:17Jens GrabowskiAssigned To => Jens Grabowski
22-04-2008 13:17Jens GrabowskiClause Reference(s) => 9.3.3
22-04-2008 13:17Jens GrabowskiSource (company - Author) => Jens Grabowski (STF 347)
17-08-2008 09:36Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
02-01-2009 09:46Jens GrabowskiFile Added: CR-3241-Optional-statement-block-following-altstep-calls-JG-V1.doc
02-01-2009 09:47Jens GrabowskiAssigned ToJens Grabowski => Gyorgy Rethy
10-03-2009 10:51Ina SchieferdeckerStatusassigned => resolved
10-03-2009 10:51Ina SchieferdeckerResolutionopen => fixed
20-04-2009 11:41Ina SchieferdeckerStatusresolved => closed
20-04-2009 11:41Ina SchieferdeckerFixed in Version => Edition 4.1.1 (not yet published)
+
+ + + + +
+ There are no notes attached to this issue.
+ + diff --git a/docs/mantis/CR3242.md b/docs/mantis/CR3242.md new file mode 100644 index 0000000000000000000000000000000000000000..b7fba59ad15ea5c67c83eaec2bdf3a803527d269 --- /dev/null +++ b/docs/mantis/CR3242.md @@ -0,0 +1,39 @@ + + + + + + + + + + + + + 0003242: const pattern - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0003242Part 01: TTCN-3 Core LanguageEditorialpublic22-04-2008 13:4509-05-2008 09:59
ReporterThomas Deiß 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.3.2 (published 2008-04) 
Target Versionv3.4.1 (published 2008-09)Fixed in Versionv3.4.1 (published 2008-09) 
Clause Reference(s)Annex B.1.5.2
Source (company - Author)Nokia Siemens Networks - Thomas Deiss
Summary0003242: const pattern
DescriptionAn example on patterns defines a constant as a pattern. This is not possible according to the BNF.
+
+clause B.1.5.2, Example 2
+const charstring MyConst2 := pattern "ab";
+
+either remove 'pattern' (preferred) or change this to a template.
+If 'pattern' is removed, the example would be
+const charstring MyConst2 := "ab";
+template charstring RegExp1 := pattern "{MyConst2}";
+and this would match "ab".
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
22-04-2008 13:45Thomas DeißNew Issue
22-04-2008 13:45Thomas DeißStatusnew => assigned
22-04-2008 13:45Thomas DeißAssigned To => Ina Schieferdecker
22-04-2008 13:45Thomas DeißClause Reference(s) => Annex B.1.5.2
22-04-2008 13:45Thomas DeißSource (company - Author) => Nokia Siemens Networks - Thomas Deiss
09-05-2008 09:56Ina SchieferdeckerTarget Version => Edition 3.4.1 (not yet published)
09-05-2008 09:58Ina SchieferdeckerStatusassigned => resolved
09-05-2008 09:58Ina SchieferdeckerFixed in Version => Edition 3.4.1 (not yet published)
09-05-2008 09:58Ina SchieferdeckerResolutionopen => fixed
09-05-2008 09:59Ina SchieferdeckerStatusresolved => closed
+
+ + + + +
+ There are no notes attached to this issue.
+ + diff --git a/docs/mantis/CR3257.md b/docs/mantis/CR3257.md new file mode 100644 index 0000000000000000000000000000000000000000..b381cdd5e17e7fe02fe490df96a9aff68c37c5ad --- /dev/null +++ b/docs/mantis/CR3257.md @@ -0,0 +1,67 @@ + + + + + + + + + + + + + 0003257: Definition should not be a note - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0003257Part 01: TTCN-3 Core LanguageEditorialpublic23-04-2008 19:2609-05-2008 09:54
ReporterGyorgy Rethy 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv3.4.1 (published 2008-09)Fixed in Versionv3.4.1 (published 2008-09) 
Clause Reference(s)3.1
Source (company - Author)L.M.Ericsson
Summary0003257: Definition should not be a note
DescriptionIn the definition
+"completely initialized: values and templates of simple types are completely initialized if they are partially initialized
+NOTE: Values and templates of structured types and arrays are completely initialized if all their fields and elements are completely initialized. In case of record of and set of values and templates and arrays this means at least the first n elements shall be initialized, where n is the minimal length imposed by the type length restrictions or array definition (thus in case of n equals 0, the value "{}" also completely initializes a record of, set of or array)."
+the definition related to simple types is written as the definition's text, the definition related to structured types is written as a note. Just delete "NOTE:" and make both parts of the definition a "normal" text.
+Proposed to be merged with CR2147, as that CR is also dealing with issues related to initialization.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
23-04-2008 19:26Gyorgy RethyNew Issue
23-04-2008 19:26Gyorgy RethyStatusnew => assigned
23-04-2008 19:26Gyorgy RethyAssigned To => Ina Schieferdecker
23-04-2008 19:26Gyorgy RethyClause Reference(s) => 3.1
23-04-2008 19:26Gyorgy RethySource (company - Author) => L.M.Ericsson
09-05-2008 09:53Ina SchieferdeckerNote Added: 0005669
09-05-2008 09:53Ina SchieferdeckerTarget Version => Edition 3.4.1 (not yet published)
09-05-2008 09:54Ina SchieferdeckerStatusassigned => resolved
09-05-2008 09:54Ina SchieferdeckerFixed in Version => Edition 3.4.1 (not yet published)
09-05-2008 09:54Ina SchieferdeckerResolutionopen => fixed
09-05-2008 09:54Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0005669) +
+ Ina Schieferdecker    +
+ 09-05-2008 09:53    +
+ 		+ + + + +
+ Has been resolved in the context of CR2147
+
+ + diff --git a/docs/mantis/CR3263.md b/docs/mantis/CR3263.md new file mode 100644 index 0000000000000000000000000000000000000000..92cb0d6b119baa88012970e8daa4f234ade4ff99 --- /dev/null +++ b/docs/mantis/CR3263.md @@ -0,0 +1,29 @@ + + + + + + + + + + + + + 0003263: Halt operation in operational semantics - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 04: TTCN-3 Operational Semantics
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0003263Part 04: TTCN-3 Operational SemanticsTechnicalpublic24-04-2008 17:4820-04-2009 11:40
ReporterJens Grabowski 
Assigned ToGyorgy Rethy 
PriorityhighSeveritymajorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)22.5.1 in Part 1 of the TTCN-3 standard
Source (company - Author)Jens Grabowski (STF 347)
Summary0003263: Halt operation in operational semantics
DescriptionThe halt operation on ports has never been implemented in the operational semantics.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR3263-Halt-Port-Operation-Resolution-JG-V1.doc (412,672) 30-12-2008 11:25
http://oldforge.etsi.org/mantis/file_download.php?file_id=1929&type=bug
Issue History
Date ModifiedUsernameFieldChange
24-04-2008 17:48Jens GrabowskiNew Issue
24-04-2008 17:48Jens GrabowskiStatusnew => assigned
24-04-2008 17:48Jens GrabowskiAssigned To => Jens Grabowski
24-04-2008 17:48Jens GrabowskiClause Reference(s) => 22.5.1 in Part 1 of the TTCN-3 standard
24-04-2008 17:48Jens GrabowskiSource (company - Author) => Jens Grabowski (STF 347)
17-08-2008 09:36Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
30-12-2008 11:25Jens GrabowskiFile Added: CR3263-Halt-Port-Operation-Resolution-JG-V1.doc
30-12-2008 11:25Jens GrabowskiAssigned ToJens Grabowski => Gyorgy Rethy
10-03-2009 10:52Ina SchieferdeckerStatusassigned => resolved
10-03-2009 10:52Ina SchieferdeckerResolutionopen => fixed
20-04-2009 11:40Ina SchieferdeckerStatusresolved => closed
20-04-2009 11:40Ina SchieferdeckerFixed in Version => Edition 4.1.1 (not yet published)
+
+ + + + +
+ There are no notes attached to this issue.
+ + diff --git a/docs/mantis/CR3268.md b/docs/mantis/CR3268.md new file mode 100644 index 0000000000000000000000000000000000000000..5ae5c2d1cf583d0ae2eab249854d1b9895e6f50b --- /dev/null +++ b/docs/mantis/CR3268.md @@ -0,0 +1,142 @@ + + + + + + + + + + + + + 0003268: Allowed content of a charstring is not completely degined - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0003268Part 01: TTCN-3 Core LanguageClarificationpublic25-04-2008 13:1019-12-2008 13:59
ReporterGyorgy Rethy 
Assigned ToIna Schieferdecker 
PriorityhighSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)6.1.1 d), 6.1.1 e), B.1.5
Source (company - Author)     
Summary0003268: Allowed content of a charstring is not completely degined
DescriptionThe charstring definition today says:
+"d) charstring: are types whose distinguished values are zero, one, or more characters of the version of ISO/IEC 646 [11] complying with the International Reference Version (IRV) as specified in clause 8.2 of ISO/IEC 646 [11].
+NOTE 2: The IRV version of ISO/IEC 646 [11] is equivalent to the IRV version of the International Reference Alphabet (former International Alphabet No.5 - IA5), described in ITU-T Recommendation T.50 [16].
+    Values of charstring type shall be denoted by an arbitrary number (possibly zero) of characters from the relevant character set, preceded and followed by double quote (") or calculated using the predefined conversion function int2char with the positive integer value of their encoding as argument (see clause C.1).
+NOTE 3: The predefined conversion function is able to return single-character-length values only.
+    In cases where it is necessary to define strings that include the character double quote (") the character is represented by a pair of double quotes on the same line with no intervening space characters.
+EXAMPLE 4: The charstring "ab"cd" is written in TTCN-3 code as in the following constant declaration. Each of the 3 quote characters that are part of the string is preceeded by an extra quote character and the whole character string is delimited by quote characters, e.g.
+var charstring vl_char:= """ab""cd""";"
+The ISO646 clause 8.2 is attached to this CR for information. The use of control characters and DEL within the string is not specified (that are unvisible in most editors, except HT).
Steps To Reproduce
Additional InformationIt would make sense to allow control characters in the string (DEL is not a control character); they should not be part of the string value but tools could use them to format the string (e.g. breaking long pattern strings into lines). Alternatively control characters could be disallowed but introduce another formatting mechanism (e.g. concatenation) for string patterns.
TagsNo tags attached.
Relationships
related to 0002976closed Ina Schieferdecker do not allow control characters in literal string denotation 
Attached Filesjpg ISO646_IRV.jpg (382,670) 25-04-2008 13:16
http://oldforge.etsi.org/mantis/file_download.php?file_id=1462&type=bug
Issue History
Date ModifiedUsernameFieldChange
25-04-2008 13:10Gyorgy RethyNew Issue
25-04-2008 13:10Gyorgy RethyStatusnew => assigned
25-04-2008 13:10Gyorgy RethyAssigned To => Ina Schieferdecker
25-04-2008 13:10Gyorgy RethyClause Reference(s) => 6.1.1 e), 6.1.1 f), B.1.5
25-04-2008 13:10Gyorgy RethySource (company - Author) =>
25-04-2008 13:16Gyorgy RethyClause Reference(s)6.1.1 e), 6.1.1 f), B.1.5 => 6.1.1 d), 6.1.1 e), B.1.5
25-04-2008 13:16Gyorgy RethyAssigned ToIna Schieferdecker => Thomas Deiß
25-04-2008 13:16Gyorgy RethyFile Added: ISO646_IRV.jpg
09-05-2008 11:26Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
29-09-2008 07:32Thomas DeißNote Added: 0006920
29-09-2008 07:32Thomas DeißAssigned ToThomas Deiß => Gyorgy Rethy
12-12-2008 16:01Ina SchieferdeckerRelationship addedrelated to 0002976
18-12-2008 11:48Gyorgy RethyNote Added: 0007734
18-12-2008 11:48Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
19-12-2008 08:49Thomas DeißNote Added: 0007749
19-12-2008 13:59Ina SchieferdeckerStatusassigned => resolved
19-12-2008 13:59Ina SchieferdeckerResolutionopen => fixed
19-12-2008 13:59Ina SchieferdeckerFixed in Version => Edition 4.1.1 (not yet published)
19-12-2008 13:59Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0006920) +
+ Thomas Deiß    +
+ 29-09-2008 07:32    +
+ 		+ + + + +
+ CR 2976, resolved in edition 3.4.1 restricted literal values of charstring to contain non-control characters only. As such the literal values are completely defined.
+
+
+
+ + + + + + + + + + +
+ (0007734) +
+ Gyorgy Rethy    +
+ 18-12-2008 11:48    +
+ 		+ + + + +
+ The final wording of CR2976 is unclear to me. This one can be closed if the solution of CR2976 talks about graphical characters (even better to say "from SP (32) to TILDE (126)" explicitly) (non-graphical characters proposed by the CR originally would allow DEL that is in fact not allowed in TTCN-3 literal values).
+
+
+
+ + + + + + + + + + +
+ (0007749) +
+ Thomas Deiß    +
+ 19-12-2008 08:49    +
+ 		+ + + + +
+ Edition 3.4.1 states: 6.1.1.1.d: 'Values of charstring type shall be denoted by an arbitrary number (possibly zero) of non-control characters from the relevant character set, preceded and followed by double quote (")'
+
+For me it would be ok to make this more explicit as suggested by Gyorgy. E.g. as
+'Values of charstring type shall be denoted by an arbitrary number (possibly zero) of graphical characters from the relevant character set, preceded and followed by double quote ("). Graphical characters include the range from SP(32) to TILDE (126).'
+
+ + diff --git a/docs/mantis/CR3276.md b/docs/mantis/CR3276.md new file mode 100644 index 0000000000000000000000000000000000000000..36af87b1c740d418587b919876a55cba7eb2ffec --- /dev/null +++ b/docs/mantis/CR3276.md @@ -0,0 +1,141 @@ + + + + + + + + + + + + + 0003276: Reference to W3C "Namespaces: Namespaces in XML" is specific, ... - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0003276Part 09: Using XML with TTCN-3Clarificationpublic29-04-2008 15:2916-10-2008 12:05
Reporteruser10 
Assigned ToGyorgy Rethy 
PrioritynormalSeveritytextReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.3.1 (published 2008-04) 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)Clause 2
For STF discussion
Source (company - Author)     
Summary0003276: Reference to W3C "Namespaces: Namespaces in XML" is specific, ...
Descriptionin clause 2 the reference given for the W3C recommendation "Namespaces in XML" is specific to a version of the recommendation that's more than 9-year old (http://www.w3.org/TR/1999/REC-xml-names-19990114/ [^]).
+There's been many updates since Jan 1999.
+The URL below automatically points to the most recent version:
+http://www.w3.org/TR/REC-xml-names/ [^]
+
+Shouldn't this URL be used instead of the 1999 one?
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0004272closed Ina Schieferdecker Part 01: TTCN-3 Core Language Consolidation of normative and informative references 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
29-04-2008 15:29user10New Issue
29-04-2008 15:29user10Statusnew => assigned
29-04-2008 15:29user10Assigned To => Gyorgy Rethy
29-04-2008 15:29user10Clause Reference(s) => Clause 2
29-04-2008 15:29user10Source (company - Author) =>
09-05-2008 11:08Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
14-10-2008 09:40Gyorgy RethyNote Added: 0007050
15-10-2008 10:01Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
15-10-2008 10:01Gyorgy RethyResolutionopen => fixed
16-10-2008 09:44Ina SchieferdeckerRelationship addedrelated to 0004272
16-10-2008 09:47Ina SchieferdeckerNote Added: 0007088
16-10-2008 11:19Ina SchieferdeckerAssigned ToIna Schieferdecker => Gyorgy Rethy
16-10-2008 11:19Ina SchieferdeckerStatusassigned => resolved
16-10-2008 12:05Gyorgy RethyStatusresolved => closed
16-10-2008 12:05Gyorgy RethyNote Added: 0007093
16-10-2008 12:05Gyorgy RethyFixed in Version => Edition 4.1.1 (not yet published)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0007050) +
+ Gyorgy Rethy    +
+ 14-10-2008 09:40    +
+ 		+ + + + +
+ Proposed replace:
+[6] W3C Recommendation (1999): "Namespaces: Namespaces in XML", World Wide Web Consortium. NOTE: Available at http://www.w3.org/TR/1999/REC-xml-names-19990114, [^] http://www.w3.org/XML/Schema [^]
+with:
+[6] W3C Recommendation (2006): “Namespaces in XML 1.0 (Second Edition)”, World Wide Web Consortium.
+NOTE: Latest version is available at http://www.w3.org/TR/REC-xml-names/ [^]
+
+
+
+
+ + + + + + + + + + +
+ (0007088) +
+ Ina Schieferdecker    +
+ 16-10-2008 09:47    +
+ 		+ + + + +
+ Ok - please be so kind to check also the titles of the other W3C references - the links have been updated already in CR4272
+
+
+
+ + + + + + + + + + +
+ (0007093) +
+ Gyorgy Rethy    +
+ 16-10-2008 12:05    +
+ 		+ + + + +
+ Corrected in master copy
+
+ + diff --git a/docs/mantis/CR3307.md b/docs/mantis/CR3307.md new file mode 100644 index 0000000000000000000000000000000000000000..2ad7702cd8b102b4fab28a750bd7798721eda0c1 --- /dev/null +++ b/docs/mantis/CR3307.md @@ -0,0 +1,33 @@ + + + + + + + + + + + + + 0003307: BNF rule "TemplateBody" incorrect - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0003307Part 01: TTCN-3 Core LanguageTechnicalpublic06-05-2008 12:3809-05-2008 09:50
ReporterGyorgy Rethy 
Assigned ToIna Schieferdecker 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv3.4.1 (published 2008-09)Fixed in Versionv3.4.1 (published 2008-09) 
Clause Reference(s)Annex A
Source (company - Author)     
Summary0003307: BNF rule "TemplateBody" incorrect
DescriptionThe current BNF rule is:
+1. TemplateBody ::= (SimpleSpec | FieldSpecList | ArrayValueOrAttrib) | [ExtraMatchingAttributes]
+
+It should be (without alternative symbol before [ExtraMatchingAttributes]):
+1. TemplateBody ::= (SimpleSpec | FieldSpecList | ArrayValueOrAttrib) [ExtraMatchingAttributes]
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
06-05-2008 12:38Gyorgy RethyNew Issue
06-05-2008 12:38Gyorgy RethyStatusnew => assigned
06-05-2008 12:38Gyorgy RethyAssigned To => Ina Schieferdecker
06-05-2008 12:38Gyorgy RethyClause Reference(s) => Annex A
06-05-2008 12:38Gyorgy RethySource (company - Author) =>
09-05-2008 09:44Ina SchieferdeckerTarget Version => Edition 3.4.1 (not yet published)
09-05-2008 09:49Ina SchieferdeckerStatusassigned => resolved
09-05-2008 09:49Ina SchieferdeckerFixed in Version => Edition 3.4.1 (not yet published)
09-05-2008 09:49Ina SchieferdeckerResolutionopen => fixed
09-05-2008 09:50Ina SchieferdeckerStatusresolved => closed
+
+ + + + +
+ There are no notes attached to this issue.
+ + diff --git a/docs/mantis/CR3308.md b/docs/mantis/CR3308.md new file mode 100644 index 0000000000000000000000000000000000000000..e24de8d86c342fe0a8e0b9295e7bf38269c8dda5 --- /dev/null +++ b/docs/mantis/CR3308.md @@ -0,0 +1,179 @@ + + + + + + + + + + + + + 0003308: Module Names - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0003308Part 09: Using XML with TTCN-3Technicalpublic06-05-2008 13:0710-12-2008 15:39
Reporteruser363 
Assigned ToGyorgy Rethy 
PrioritynormalSeveritymajorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)5.1
For STF discussion
Source (company - Author)     
Summary0003308: Module Names
DescriptionThe mapping of XSD files and name spaces to TTCN-3 modules shall be handled analog to part 8 of the standard (IDL). I. e. in particular that the XSD file names shall have no influence on the mapping; the XSD namespaces shall be mapped (after some necessary name mangling) to TTCN-3 module names.
+
+Proposed text:
+
+"Every namespace used in an XSD Schema is mapped to a separate TTCN-3 module, containing the entities defined in the particular namespace. (The namespace URIs are mangled to syntactically correct TTCN-3 module names as described in clause 5.2.) This means that XSD import-statements (which allow the use of entities of another namespace) imply the generation of another module for the imported entities; XSD include-statements (which include entities, defined in another namespace, into the same namespace the include-statement appears in) lead to the generation of the included entities in the current module.
+No maintenance effort shall result from changes of the internal structure of an XSD Schema which does not change its outside appearance (interface)."
+
+Reasoning:
+
+(A) This approach has already been proven suitable in the IDL-to-TTCN-3 mapping (part 8 of the standard). Handling analog things differently is not intuitive for the user.
+
+(B) The XSD file names are part of the internal structure of a Schema; changes within this internal structure should not result in changes of the interface (e. g. TTCN-3 module names) of the generated TTCN-3 code as this would result in maintenance efforts for users of the generated code each time the internal structure of the Schema changes.
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesppt CR3308_3310_analysis_2008-07.ppt (62,464) 18-07-2008 09:23
http://oldforge.etsi.org/mantis/file_download.php?file_id=1556&type=bug
doc CR3308_3310-module names.doc (125,440) 27-11-2008 18:43
http://oldforge.etsi.org/mantis/file_download.php?file_id=1825&type=bug
doc CR3308_3310-module names v3.doc (130,560) 28-11-2008 14:28
http://oldforge.etsi.org/mantis/file_download.php?file_id=1837&type=bug
doc CR3308_3310-module names v7.doc (289,280) 10-12-2008 09:05
http://oldforge.etsi.org/mantis/file_download.php?file_id=1878&type=bug
Issue History
Date ModifiedUsernameFieldChange
06-05-2008 13:07user363New Issue
06-05-2008 13:07user363Clause Reference(s) => 5.1
06-05-2008 13:07user363Source (company - Author) =>
09-05-2008 11:13Ina SchieferdeckerAssigned To => Gyorgy Rethy
09-05-2008 11:13Ina SchieferdeckerStatusnew => assigned
09-05-2008 11:15Ina SchieferdeckerProjectTTCN-3 Change Requests => Part 09: Using XML with TTCN-3
09-05-2008 11:16Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
18-07-2008 09:23Gyorgy RethyFile Added: CR3308_3310_analysis_2008-07.ppt
18-07-2008 09:30Gyorgy RethyNote Added: 0006321
27-11-2008 18:43Gyorgy RethyFile Added: CR3308_3310-module names.doc
27-11-2008 18:43Gyorgy RethyAssigned ToGyorgy Rethy => Thomas Deiß
28-11-2008 08:39Thomas DeißNote Added: 0007492
28-11-2008 08:40Thomas DeißAssigned ToThomas Deiß => Gyorgy Rethy
28-11-2008 13:59Gyorgy RethyNote Added: 0007506
28-11-2008 14:03Gyorgy RethyNote Edited: 0007506
28-11-2008 14:28Gyorgy RethyNote Edited: 0007506
28-11-2008 14:28Gyorgy RethyFile Added: CR3308_3310-module names v3.doc
10-12-2008 09:05Gyorgy RethyFile Added: CR3308_3310-module names v4.doc
10-12-2008 09:05Gyorgy RethyFile Deleted: CR3308_3310-module names v4.doc
10-12-2008 09:05Gyorgy RethyFile Added: CR3308_3310-module names v7.doc
10-12-2008 15:39Gyorgy RethyNote Added: 0007643
10-12-2008 15:39Gyorgy RethyStatusassigned => closed
10-12-2008 15:39Gyorgy RethyResolutionopen => fixed
10-12-2008 15:39Gyorgy RethyFixed in Version => Edition 4.1.1 (not yet published)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0006321) +
+ Gyorgy Rethy    +
+ 18-07-2008 09:30    +
+ 		+ + + + +
+ Agreed in general: add naming rule for generated TTCN-3 modules; it shall be the name resulted by applying $5.2 on the target namespace (resolves also the multiple target namespace problem), if exists, or on the default module name "No_target_namespace", if no target namespace is at place.
+
+
+
+ + + + + + + + + + +
+ (0007492) +
+ Thomas Deiß    +
+ 28-11-2008 08:39    +
+ 		+ + + + +
+ In case of an XML schema including the other they will have the same target namespace. Hence they will have the same module name. By numerical suffixes the module names can be made unique. It should be clarified in which order the name resolution is applied. Including module first, then the included one?
+
+
+
+ + + + + + + + + + +
+ (0007506) +
+ Gyorgy Rethy    +
+ 28-11-2008 13:59    +
(edited on: 28-11-2008 14:28)
+ 		+ + + + +
+ OK, the sentence is misleading. In fact both the including schema and the included schema shall be available for the converter, thus no need to generate a third, "included" schema. But we do not know in which order they are processed. As XSD allows circular includes, the documents cannot be arranged in a canonical order, e.g. acc. to the include hierarchy. Therefore we have no mean to specify which one shall be processed first. I propose to add a note, encouraging tool providers to use the order in which the XSD documents are provided to the tool and then by the order of generating new TTCN-3 modules. See ~v3.
+
+
+
+
+
+ + + + + + + + + + +
+ (0007643) +
+ Gyorgy Rethy    +
+ 10-12-2008 15:39    +
+ 		+ + + + +
+ Final version agreed with Jacob is in the file CR3308_3310-module names v7.doc. Changes added to master copy (v3.3.4).
+
+ + diff --git a/docs/mantis/CR3309.md b/docs/mantis/CR3309.md new file mode 100644 index 0000000000000000000000000000000000000000..0fae55a26ef49e49407c4407d608e02eb52b504c --- /dev/null +++ b/docs/mantis/CR3309.md @@ -0,0 +1,78 @@ + + + + + + + + + + + + + 0003309: XSD-type "any" shall be mapped to TTCN-3-type "anytype" - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0003309Part 09: Using XML with TTCN-3Technicalpublic06-05-2008 13:1518-07-2008 09:35
Reporteruser363 
Assigned ToGyorgy Rethy 
PrioritynormalSeveritymajorReproducibilityN/A
StatusclosedResolutionwon't fix 
PlatformOSOS Version
Product Versionv3.3.1 (published 2008-04) 
Target Versionv4.1.1 (published 2009-06)Fixed in Version 
Clause Reference(s)7.7
For STF discussion
Source (company - Author)     
Summary0003309: XSD-type "any" shall be mapped to TTCN-3-type "anytype"
DescriptionThe first two sentences of clause 7.7 shall be replaced by the following text:
+
+"The XSD-type 'any' shall be mapped to the TTCN-3 type 'anytype'. A decoder which encounters a known and decodable (see below) type at the place the XSD-'any' was declared shall decode this type to the corresponding TTCN-3 value and place a value of this type in the field declared as TTCN-3-'anytype'.
+
+If the type is not known (because XSD-'any' can be used as an extension point and consequently be used for elements not known within the current Schema), the contents shall be decoded to a value of an XML string type.
+
+Also, if the type is not decodable (e. g. due to an encoding which does not allow the recognition of the type of a value), the value shall be decoded to a value of an XML string type."
+
+The examples below will have to be adjusted as well (replace "XSD.String" by "anytype").
+
+Reasoning:
+
+XSD-"any" often is used for elements declared in the same Schema, i. e. for known types. This is widely analog to the meaning of the TTCN-3 type "anytype". To leave the user with an unparsed XML string in such cases (as proposed by the draft) would pose a rather cumbersome solution and force the users to parse the unparsed XML themselves.
+
+The proposal also does not lead to any ambiguity or variability in the behavior of the decoder; only in the case of switching from one codec to another the behavior could change (if any or both codecs disallow decoding); but in this case the unparsed contents would change anyway if it stays undecoded, i. e. encoded in the one or the other code (which certainly are not alike).
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesppt CR3309_analysis_2008-07.ppt (73,216) 18-07-2008 09:30
http://oldforge.etsi.org/mantis/file_download.php?file_id=1557&type=bug
Issue History
Date ModifiedUsernameFieldChange
06-05-2008 13:15user363New Issue
06-05-2008 13:15user363Statusnew => assigned
06-05-2008 13:15user363Assigned To => Gyorgy Rethy
06-05-2008 13:15user363Clause Reference(s) => 7.7
06-05-2008 13:15user363Source (company - Author) =>
09-05-2008 10:55Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
18-07-2008 09:30Gyorgy RethyFile Added: CR3309_analysis_2008-07.ppt
18-07-2008 09:35Gyorgy RethyNote Added: 0006322
18-07-2008 09:35Gyorgy RethyStatusassigned => closed
18-07-2008 09:35Gyorgy RethyResolutionopen => won't fix
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0006322) +
+ Gyorgy Rethy    +
+ 18-07-2008 09:35    +
+ 		+ + + + +
+ Decided not to change current mapping. There are several reasons (see attached .ppt file) but the major one is that it would make the runtime behaviour of test suites tool-dependent.
+
+ + diff --git a/docs/mantis/CR3310.md b/docs/mantis/CR3310.md new file mode 100644 index 0000000000000000000000000000000000000000..302ed572eb680d27f6461d5f513f58085a0ed73f --- /dev/null +++ b/docs/mantis/CR3310.md @@ -0,0 +1,75 @@ + + + + + + + + + + + + + 0003310: Module Names - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0003310Part 09: Using XML with TTCN-3Technicalpublic06-05-2008 13:2615-07-2008 12:45
Reporteruser363 
Assigned ToGyorgy Rethy 
PrioritynormalSeveritymajorReproducibilityN/A
StatusclosedResolutionduplicate 
PlatformOSOS Version
Product Versionv3.3.1 (published 2008-04) 
Target Versionv4.1.1 (published 2009-06)Fixed in Version 
Clause Reference(s)5.1
For STF discussion
Source (company - Author)     
Summary0003310: Module Names
DescriptionThe mapping of XSD files and name spaces to TTCN-3 modules shall be handled analog to part 8 of the standard (IDL). I. e. in particular that the XSD file names shall have no influence on the mapping; the XSD namespaces shall be mapped (after some necessary name mangling) to TTCN-3 module names.
+
+Proposed text:
+
+"Every namespace used in an XSD Schema is mapped to a separate TTCN-3 module, containing the entities defined in the particular namespace. (The namespace URIs are mangled to syntactically correct TTCN-3 module names as described in clause 5.2.) This means that XSD import-statements (which allow the use of entities of another namespace) imply the generation of another module for the imported entities; XSD include-statements (which include entities, defined in another namespace, into the same namespace the include-statement appears in) lead to the generation of the included entities in the current module.
+
+No maintenance effort shall result from changes of the internal structure of an XSD Schema which does not change its outside appearance (interface)."
+
+Reasoning:
+
+(A) This approach has already been proven suitable in the IDL-to-TTCN-3 mapping (part 8 of the standard). Handling analog things differently is not intuitive for the user.
+
+(B) The XSD file names are part of the internal structure of a Schema; changes within this internal structure should not result in changes of the interface (e. g. TTCN-3 module names) of the generated TTCN-3 code as this would result in maintenance efforts for users of the generated code each time the internal structure of the Schema changes.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
06-05-2008 13:26user363New Issue
06-05-2008 13:26user363Statusnew => assigned
06-05-2008 13:26user363Assigned To => Gyorgy Rethy
06-05-2008 13:26user363Clause Reference(s) => 5.1
06-05-2008 13:26user363Source (company - Author) =>
09-05-2008 10:55Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
15-07-2008 12:45Ina SchieferdeckerNote Added: 0006275
15-07-2008 12:45Ina SchieferdeckerStatusassigned => closed
15-07-2008 12:45Ina SchieferdeckerResolutionopen => duplicate
15-07-2008 12:45Ina SchieferdeckerNote Deleted: 0006275
15-07-2008 12:45Ina SchieferdeckerNote Added: 0006276
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0006276) +
+ Ina Schieferdecker    +
+ 15-07-2008 12:45    +
+ 		+ + + + +
+ This is a duplicate of CR3308.
+
+ + diff --git a/docs/mantis/CR3311.md b/docs/mantis/CR3311.md new file mode 100644 index 0000000000000000000000000000000000000000..874c98a5403ad32471120769126cd13663f138c3 --- /dev/null +++ b/docs/mantis/CR3311.md @@ -0,0 +1,129 @@ + + + + + + + + + + + + + 0003311: Example for recursions of inner types to their outer type - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0003311Part 09: Using XML with TTCN-3Clarificationpublic06-05-2008 13:2702-10-2008 06:41
Reporteruser363 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.3.1 (published 2008-04) 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)7.6.2.1
For STF discussion
Source (company - Author)     
Summary0003311: Example for recursions of inner types to their outer type
DescriptionThe following shall be added to clause 7.6.2.1:
+
+Recursions of extending inner anonymous types to their outer type are realized using the dotted notation to name the inner type:
+
+    <xs:complexType name="X">
+     <xs:sequence>
+      <xs:element name="x" type="xs:string"/>
+      <xs:element name="y" minOccurs="0">
+       <xs:complexType>
+        <xs:complexContent>
+         <xs:extension base="X">
+          <xs:element name="z" type="xs:string"/>
+         </xs:extension>
+        </xs:complexContent>
+       </xs:complexType>
+      </xs:element>
+     </xs:sequence>
+    </xs:complexType>
+
+This translates to the TTCN-3 structure
+
+    type record X {
+      String x,
+      record {
+        String x,
+        X.y y optional,
+        String z
+      } y optional
+    }
+
+Reasoning:
+
+This is not straightforward as it needs to use the dotted notation to reference inner types. So a clarifying example shall avoid tool-depended interpretations of the standard.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesppt CR3311_analysis_2008-07.ppt (32,768) 18-07-2008 09:36
http://oldforge.etsi.org/mantis/file_download.php?file_id=1558&type=bug
Issue History
Date ModifiedUsernameFieldChange
06-05-2008 13:27user363New Issue
06-05-2008 13:27user363Statusnew => assigned
06-05-2008 13:27user363Assigned To => Gyorgy Rethy
06-05-2008 13:27user363Clause Reference(s) => 7.6.2.1
06-05-2008 13:27user363Source (company - Author) =>
09-05-2008 10:54Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
18-07-2008 09:36Gyorgy RethyFile Added: CR3311_analysis_2008-07.ppt
18-07-2008 09:37Gyorgy RethyNote Added: 0006323
18-07-2008 09:37Gyorgy RethyStatusassigned => resolved
18-07-2008 09:37Gyorgy RethyResolutionopen => fixed
02-10-2008 06:41Gyorgy RethyStatusresolved => closed
02-10-2008 06:41Gyorgy RethyNote Added: 0006967
02-10-2008 06:41Gyorgy RethyFixed in Version => Edition 4.1.1 (not yet published)
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0006323) +
+ Gyorgy Rethy    +
+ 18-07-2008 09:37    +
+ 		+ + + + +
+ Accepted with a minor change (see .ppt)
+
+
+
+ + + + + + + + + + +
+ (0006967) +
+ Gyorgy Rethy    +
+ 02-10-2008 06:41    +
+ 		+ + + + +
+ Added to draft
+
+ + diff --git a/docs/mantis/CR3312.md b/docs/mantis/CR3312.md new file mode 100644 index 0000000000000000000000000000000000000000..1b4a5bc82bde13ae43c2f083a808bcfc113dc0c7 --- /dev/null +++ b/docs/mantis/CR3312.md @@ -0,0 +1,72 @@ + + + + + + + + + + + + + 0003312: remove phrase "mutually exclusive" for union types - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0003312Part 09: Using XML with TTCN-3Clarificationpublic06-05-2008 13:3118-07-2008 09:52
Reporteruser363 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.3.1 (published 2008-04) 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)7.6.5
For STF discussion
Source (company - Author)     
Summary0003312: remove phrase "mutually exclusive" for union types
DescriptionThe text of clause 7.6.5 shall be stripped of the words "mutually exclusive".
+
+Reasoning:
+
+There is no need of this phrase as XSD-defined XML can specify explicitly which alternative of a choice has been chosen: XML Schema Part 2: Datatypes clause 2.5.1.3 specifies: "The order in which the memberTypes are specified in the definition (that is, the order of the <simpleType> children of the <union> element, or the order of the QNames in the memberTypes attribute) is significant. During validation, an element or attribute's value is validated against the memberTypes in the order in which they appear in the definition until a match is found. The evaluation order can be overridden with the use of xsi:type."
+
+In case of a chosen alternative which is ambiguous in its type, the standard defines that the order of the declaration of the type also specifies the priorities for the matching algorithm.
+
+So, it never is important to have "mutually exclusive" types.
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesppt CR3312_analysis_2008-07.ppt (53,248) 18-07-2008 09:37
http://oldforge.etsi.org/mantis/file_download.php?file_id=1559&type=bug
Issue History
Date ModifiedUsernameFieldChange
06-05-2008 13:31user363New Issue
06-05-2008 13:31user363Statusnew => assigned
06-05-2008 13:31user363Assigned To => Gyorgy Rethy
06-05-2008 13:31user363Clause Reference(s) => 7.6.5
06-05-2008 13:31user363Source (company - Author) =>
09-05-2008 10:39Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
18-07-2008 09:37Gyorgy RethyFile Added: CR3312_analysis_2008-07.ppt
18-07-2008 09:38Gyorgy RethyNote Added: 0006324
18-07-2008 09:38Gyorgy RethyStatusassigned => resolved
18-07-2008 09:38Gyorgy RethyResolutionopen => fixed
18-07-2008 09:52Gyorgy RethyStatusresolved => closed
18-07-2008 09:52Gyorgy RethyFixed in Version => Edition 4.1.1 (not yet published)
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0006324) +
+ Gyorgy Rethy    +
+ 18-07-2008 09:38    +
+ 		+ + + + +
+ Accepted, with a different wording.
+
+ + diff --git a/docs/mantis/CR3313.md b/docs/mantis/CR3313.md new file mode 100644 index 0000000000000000000000000000000000000000..ce560683240a0cd131c8f853f1e74e86df681c25 --- /dev/null +++ b/docs/mantis/CR3313.md @@ -0,0 +1,85 @@ + + + + + + + + + + + + + 0003313: XSD-type "all" shall be mapped to the TTCN-3 type "set" - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0003313Part 09: Using XML with TTCN-3New Featurepublic06-05-2008 13:3518-07-2008 09:45
Reporteruser363 
Assigned ToGyorgy Rethy 
PrioritynormalSeveritymajorReproducibilityN/A
StatusclosedResolutionwon't fix 
PlatformOSOS Version
Product Versionv3.3.1 (published 2008-04) 
Target Versionv4.1.1 (published 2009-06)Fixed in Version 
Clause Reference(s)7.6.4
For STF discussion
Source (company - Author)     
Summary0003313: XSD-type "all" shall be mapped to the TTCN-3 type "set"
DescriptionThe XSD-type "all" shall be mapped to the TTCN-3-type "set" (instead of "record"). Proposed text (replacing the two sentences at the start of 7.6.4):
+
+"An /all/ content structure defines an unordered collection of optional elements. This is translated in TTCN-3 as a set with optional elements:"
+
+The result of the mapping of the example below must be changed as well and shall be:
+
+type set E29
+{
+  XSD.Integer foo optional,
+  XSD.Float bar optional,
+  XSD.String ding optional
+}
+with
+{
+  variant "name ‘E29’ as uncapitalized";
+};
+
+Reasoning:
+
+Both types (XSD-all and TTCN-set) represent an unordered set of fields and are therefore alike in all matters of structure and meaning. To map XSD-"all" to TTCN-3-"record" is not intuitive for the user. The additional field containing the (per definition irrelevant) order of the elements, as proposed by the draft, makes the handling of the resulting TTCN-3 type even more cumbersome.
+
+As the mapping proposed by this CR seems to create doubts in Ericson whether this could raise problems in conjunction with special encodings like the PER, we want to point out that the codec may very well choose any fixed order it likes, e. g. the one given in the XSD files. Neither the XSD-"all" type nor the TTCN-3-"set" type regard the order of the elements as relevant, so any order must be okay by definition, and consequently the codec can choose any, also a fixed one.
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesppt CR3313_analysis_2008-07.ppt (62,976) 18-07-2008 09:39
http://oldforge.etsi.org/mantis/file_download.php?file_id=1560&type=bug
Issue History
Date ModifiedUsernameFieldChange
06-05-2008 13:35user363New Issue
06-05-2008 13:35user363Statusnew => assigned
06-05-2008 13:35user363Assigned To => Gyorgy Rethy
06-05-2008 13:35user363Clause Reference(s) => 7.6.4
06-05-2008 13:35user363Source (company - Author) =>
09-05-2008 10:39Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
18-07-2008 09:39Gyorgy RethyFile Added: CR3313_analysis_2008-07.ppt
18-07-2008 09:45Gyorgy RethyNote Added: 0006325
18-07-2008 09:45Gyorgy RethyStatusassigned => closed
18-07-2008 09:45Gyorgy RethyResolutionopen => won't fix
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0006325) +
+ Gyorgy Rethy    +
+ 18-07-2008 09:45    +
+ 		+ + + + +
+ Additional record of enumerated field is needed to control the order of elements in the encoded XML document explicitly (in case of XML encoding) or pass on the information transparently (i.e. in case of PER encoding) independently of the actually used codec type. Mapping to record is preserved for X.694 compatibility.
+
+ + diff --git a/docs/mantis/CR3314.md b/docs/mantis/CR3314.md new file mode 100644 index 0000000000000000000000000000000000000000..2698eb1452a94607b32e77bad2cbcb393402ccd6 --- /dev/null +++ b/docs/mantis/CR3314.md @@ -0,0 +1,202 @@ + + + + + + + + + + + + + 0003314: "mixed" shall be honored - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0003314Part 09: Using XML with TTCN-3Technicalpublic06-05-2008 13:3830-10-2008 14:10
Reporteruser363 
Assigned ToGyorgy Rethy 
PrioritynormalSeveritymajorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.3.1 (published 2008-04) 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)5.3 and one to be introduced
For STF discussion
Source (company - Author)     
Summary0003314: "mixed" shall be honored
DescriptionThe XSD-type-attribute "mixed" currently is declared as "unsupported". It shall be supported in the meaning that it shall be honored and modify the mapping of the attributed element in a way so that the text content between the element content is mapped to string fields.
+
+Proposed changes:
+
+- Clause 5.3 shall not list the current point d) anymore.
+
+- A new clause must be introduced to specify the following:
+
+"Mixed content
+
+An element which has the attribute 'mixed' may contain a starting text node before any maybe present element node it contains and a text node following each element node it contains. These text nodes (which might be the empty string) are stored in the element surrounding them in an array structure which is parallel to the array for the contained elements. Example:
+
+<complexType name="xmpl" mixed="true">
+  <sequence>
+    <element name="elem" type="string" maxOccurs="5"/>
+  </sequence>
+</complexType>
+
+This will be mapped thus:
+
+type record Xmpl
+{
+  record length(1..5) of record
+  {
+    XSD.String elem;
+  } sequence_list,
+  record length(2..6) of XSD.String mixed_content
+}
+with
+{
+  variant "name as uncapitalized";
+}
+
+Reasoning:
+
+The current draft specifies the feature "mixed" as "unsupported" which means that this information shall be neglected. In this case the strings (which are relevant as declared by the Schema) are not stored in the resulting TTCN-3 types. At compile time, this will not raise any problem but of course during runtime this behavior cannot be considered wished as it will either raise exceptions or drop relevant information. So the current version obfuscates problems.
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesppt CR3314_analysis_2008-07.ppt (69,632) 18-07-2008 09:45
http://oldforge.etsi.org/mantis/file_download.php?file_id=1561&type=bug
doc CR3314_mixedContent_solution.doc (183,296) 15-10-2008 09:56
http://oldforge.etsi.org/mantis/file_download.php?file_id=1693&type=bug
Issue History
Date ModifiedUsernameFieldChange
06-05-2008 13:38user363New Issue
06-05-2008 13:38user363Statusnew => assigned
06-05-2008 13:38user363Assigned To => Gyorgy Rethy
06-05-2008 13:38user363Clause Reference(s) => 5.3 and one to be introduced
06-05-2008 13:38user363Source (company - Author) =>
09-05-2008 10:38Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
18-07-2008 09:45Gyorgy RethyFile Added: CR3314_analysis_2008-07.ppt
18-07-2008 09:47Gyorgy RethyNote Added: 0006326
18-07-2008 09:47Gyorgy RethyResolutionopen => fixed
15-10-2008 09:55Gyorgy RethyNote Added: 0007067
15-10-2008 09:55Gyorgy RethyAssigned ToGyorgy Rethy => Thomas Deiß
15-10-2008 09:56Gyorgy RethyFile Added: CR3314_mixedContent_solution.doc
15-10-2008 16:47Thomas DeißNote Added: 0007078
15-10-2008 16:48Thomas DeißAssigned ToThomas Deiß => Gyorgy Rethy
30-10-2008 14:10Gyorgy RethyStatusassigned => closed
30-10-2008 14:10Gyorgy RethyNote Added: 0007222
30-10-2008 14:10Gyorgy RethyFixed in Version => Edition 4.1.1 (not yet published)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0006326) +
+ Gyorgy Rethy    +
+ 18-07-2008 09:47    +
+ 		+ + + + +
+ Agreed to add mapping of mixed to Part-9. Concrete mapping shall be aligned with X.694.
+
+
+
+ + + + + + + + + + +
+ (0007067) +
+ Gyorgy Rethy    +
+ 15-10-2008 09:55    +
+ 		+ + + + +
+ See proposed solution in CR3314_mixedContent_solution.doc; pls. cross-check
+
+
+
+ + + + + + + + + + +
+ (0007078) +
+ Thomas Deiß    +
+ 15-10-2008 16:47    +
+ 		+ + + + +
+ There's one typo in the first paragraph in clause 7.6.8, line 5: elemenys -> elements.
+Otherwise the proposal is ok.
+
+
+
+ + + + + + + + + + +
+ (0007222) +
+ Gyorgy Rethy    +
+ 30-10-2008 14:10    +
+ 		+ + + + +
+ Done in master copy (also typo corrected).
+
+ + diff --git a/docs/mantis/CR3315.md b/docs/mantis/CR3315.md new file mode 100644 index 0000000000000000000000000000000000000000..64e26e762490cbe4c8aa5aa479ce5adbbf8dee48 --- /dev/null +++ b/docs/mantis/CR3315.md @@ -0,0 +1,108 @@ + + + + + + + + + + + + + 0003315: Allow length matching attribute for value list and pattern matching mechanism - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0003315Part 01: TTCN-3 Core LanguageTechnicalpublic06-05-2008 15:3210-12-2008 09:06
ReporterGyorgy Rethy 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)$B.1.4.1
Source (company - Author)L.M.Ericsson
Summary0003315: Allow length matching attribute for value list and pattern matching mechanism
DescriptionCurrent text of paragraph 1 of $B.1.4.1 is:
+"The length restriction attribute is used to restrict the length of string values matching the template and the number of elements in a set of, record of or array structure. It shall be used only as an attribute of the following mechanisms: AnyValue, AnyValueOrNone, AnyElement and AnyElementsOrNone (but not inside permutation), permutation, superset and subset. It can also be used in conjunction with the complement matching mechanism and with the if present attribute. The syntax for length can be found in clauses 6.2.3 and 6.3.3."
+
+1) There is no reason to disallow (not to allow) using the length attribute for pattern matching; it would be useful in practice (e.g. match only strings of certain length from the set of strings matching the pattern).
+2) There is no reason to disallow the length attribute for value lists (pl. note, the value list may contain also templates);
+3) Editorial comment: ComplimentedList is a matching mechanism just like AnyValue etc., it should be listed with the other mechanisms instead of mentioning it in a separate sentence.
+4) Editorial comment:"(but not inside permutation)" should be added to permutation instead of AnyElementsOrNone
Steps To Reproduce
Additional InformationIt is proposed to amend the above paragraph as:
+"The length restriction attribute is used to restrict the length of string values matching the template and the number of elements in a set of, record of or array structure. It shall be used only as an attribute of the following matching mechanisms: ValueList, ComplementedList, AnyValue, AnyValueOrNone, AnyElement, AnyElementsOrNone, superset, subset, pattern and permutation (but not inside permutation). It can also be used in conjunction with the if present matching attribute. The syntax for length can be found in clauses 6.2.3 and 6.3.3."
+  NOTE: When the length attribute is used with a value list, elements of the list may be disabled by the attribute.
+
TagsNo tags attached.
Relationships
Attached Filesdoc CR3315_Allow_length_matching_for_value_list_and_pattern_01.doc (200,192) 27-11-2008 09:54
http://oldforge.etsi.org/mantis/file_download.php?file_id=1811&type=bug
Issue History
Date ModifiedUsernameFieldChange
06-05-2008 15:32Gyorgy RethyNew Issue
06-05-2008 15:32Gyorgy RethyStatusnew => assigned
06-05-2008 15:32Gyorgy RethyAssigned To => Ina Schieferdecker
06-05-2008 15:32Gyorgy RethyClause Reference(s) => $B.1.4.1
06-05-2008 15:32Gyorgy RethySource (company - Author) => L.M.Ericsson
09-05-2008 09:41Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
26-11-2008 15:03Ina SchieferdeckerAssigned ToIna Schieferdecker => Thomas Deiß
27-11-2008 09:54Thomas DeißFile Added: CR3315_Allow_length_matching_for_value_list_and_pattern_01.doc
27-11-2008 10:01Thomas DeißNote Added: 0007467
27-11-2008 10:01Thomas DeißAssigned ToThomas Deiß => Gyorgy Rethy
27-11-2008 14:10Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
27-11-2008 14:11Gyorgy RethyStatusassigned => resolved
27-11-2008 14:11Gyorgy RethyResolutionopen => fixed
27-11-2008 14:11Gyorgy RethyNote Added: 0007476
10-12-2008 09:06Ina SchieferdeckerStatusresolved => closed
10-12-2008 09:06Ina SchieferdeckerFixed in Version => Edition 4.1.1 (not yet published)
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0007467) +
+ Thomas Deiß    +
+ 27-11-2008 10:01    +
+ 		+ + + + +
+ Proposed solution is ok. (one editorial correction).
+Two examples corrected (unrelated to this CR)
+
+
+
+
+ + + + + + + + + + +
+ (0007476) +
+ Gyorgy Rethy    +
+ 27-11-2008 14:11    +
+ 		+ + + + +
+ Checked, OK.
+
+ + diff --git a/docs/mantis/CR3320.md b/docs/mantis/CR3320.md new file mode 100644 index 0000000000000000000000000000000000000000..be972bad5e6d2d17e47719ea81daa91ac842e4b1 --- /dev/null +++ b/docs/mantis/CR3320.md @@ -0,0 +1,151 @@ + + + + + + + + + + + + + 0003320: Introduce contained subtype type constraints - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0003320Part 01: TTCN-3 Core LanguageNew Featurepublic06-05-2008 18:4920-12-2008 15:16
ReporterGyorgy Rethy 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)Clause 6 & Annex A
Source (company - Author)L.M.Ericsson
Summary0003320: Introduce contained subtype type constraints
DescriptionTypes in general are sets of values. Subtypes are a limited (related to the parent type) set of values. Today it is allowed to use literals and constants in subtype definitions. However, in several cases, usability of the language would be significantly increased. The new type still shall be a subset of the parent type, but to define it another (even smaller) subsets could be used.
+Example:
+------------------------------------------------------
+Today, to define e.g. types for ISO 8601 date representations, several type definitions has to created in a flat manner, both for atomic and more complex formats; the types for the more complex formats mostly repeating patterns from the other types and patterns tend to grow too huge (n*100 characters). i.e.:
+
+type charstring ISO8601DateCalendarCompleteBasic ( pattern
+  "{century}({year}{month}{dayOfMonth}")
+
+type charstring ISO8601DateCalendarCompleteExtended ( pattern
+  "{century}{year}-{month}-{dayOfMonth}")
+
+type charstring ISO8601DateCalendarReducedBasic ( pattern
+  "{century}({year}(-{month})#(0,1))#(0,1)")
+
+type charstring ISO8601DateCalendarExpandedBasic ( pattern
+  "{centuryExpansion}{century}({year}(({month}{dayOfMonth})|(-{month}))#(0,1))#(0,1)")
+
+type charstring ISO8601DateCalendarExpandedExtended ( pattern
+  "{centuryExpansion}{century}{year}-{month}-{dayOfMonth}")
+
+//... further atomic date representations here
+
+//more complex definitions
+type charstring ISO8601DateBasic ( pattern
+  "{centuryExpansion}#(0,1){century}({year}(({month}{dayOfMonth})|({dayOfYear})|({week}({dayOfWeek})#(0,1))|(-{month}))#(0,1))#(0,1)")
+
+type charstring ISO8601DateExtended ( pattern
+  "{centuryExpansion}#(0,1){century}{year}-(({month}-{dayOfMonth})|({dayOfYear})|({week}(-{dayOfWeek})#(0,1)))")
+
+type charstring ISO8601Date ( pattern
+  "{centuryExpansion}#(0,1){century}({year}(({month}{dayOfMonth})|({dayOfYear})|({week}({dayOfWeek})#(0,1))|(-(({month}(-{dayOfMonth})#(0,1))|({dayOfYear})|({week}(-{dayOfWeek})#(0,1))))#(0,1))#(0,1))#(0,1)")
+
+------------------------------------------------------
+With the use of contained subtypes the structure could become hierarchical that would make complex definitions significantly simpler and without repetitions. This would decrease the development time and probability of errors and increase maintenability (e.g. in case of format changes only the simply types should be changed). i.e.:
+
+type charstring ISO8601DateBasic (
+  ISO8601DateCalendarCompleteBasic,
+  ISO8601DateCalendarReducedBasic,
+  ISO8601DateCalendarExpandedBasic,
+//...further atomic types listed here
+)
+type charstring ISO8601DateExtended (
+  ISO8601DateCalendarCompleteExtended,
+  ISO8601DateCalendarExpandedExtended,
+//...further atomic types listed here
+)
+type charstring ISO8601Date (
+  ISO8601DateBasic,
+  ISO8601DateExtended
+)
Steps To Reproduce
Additional InformationAs contained subtypes represent a subset of the parent type, it would be usable for all types.
+
+From semantical point of view list subtyping and contained subtypes are very similar: the difference is, that the first "lifts" a single value into the new type, the second "lifts" a set of values. Thus, the same subtype mixing rules could be applied as for list subtyping (e.g. can be mixed with other subtyping for integer and float and cannot be mixed for character strings).
TagsNo tags attached.
Relationships
Attached Filesdoc CR_3320_Introduce_contained_subtype_solution_01.doc (349,184) 29-09-2008 08:24
http://oldforge.etsi.org/mantis/file_download.php?file_id=1661&type=bug
doc CR_3320_Introduce_contained_subtype_solution_02.doc (343,040) 29-09-2008 08:32
http://oldforge.etsi.org/mantis/file_download.php?file_id=1662&type=bug
Issue History
Date ModifiedUsernameFieldChange
06-05-2008 18:49Gyorgy RethyNew Issue
06-05-2008 18:49Gyorgy RethyStatusnew => assigned
06-05-2008 18:49Gyorgy RethyAssigned To => Ina Schieferdecker
06-05-2008 18:49Gyorgy RethyClause Reference(s) => Clause 6 & Annex A
06-05-2008 18:49Gyorgy RethySource (company - Author) => L.M.Ericsson
09-05-2008 09:39Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
15-07-2008 12:54Ina SchieferdeckerAssigned ToIna Schieferdecker => Thomas Deiß
29-09-2008 08:24Thomas DeißFile Added: CR_3320_Introduce_contained_subtype_solution_01.doc
29-09-2008 08:31Thomas DeißNote Added: 0006922
29-09-2008 08:31Thomas DeißAssigned ToThomas Deiß => Gyorgy Rethy
29-09-2008 08:32Thomas DeißFile Added: CR_3320_Introduce_contained_subtype_solution_02.doc
18-12-2008 14:58Gyorgy RethyNote Added: 0007741
18-12-2008 14:58Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
18-12-2008 14:58Gyorgy RethyStatusassigned => resolved
18-12-2008 14:58Gyorgy RethyResolutionopen => fixed
18-12-2008 14:58Gyorgy RethyFixed in Version => Edition 4.1.1 (not yet published)
20-12-2008 15:16Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0006922) +
+ Thomas Deiß    +
+ 29-09-2008 08:31    +
+ 		+ + + + +
+ Example in CR (charstrings) can be written by defining corresponding templates first and then using pattern subtyping of charstrings.
+This is possible only for charstrings, this kind of subtyping would be reasonable for other types, too.
+
+Solution proposal uploaded for checking. (version 02 contains also rules on mixing subtyping)
+
+
+
+ + + + + + + + + + +
+ (0007741) +
+ Gyorgy Rethy    +
+ 18-12-2008 14:58    +
+ 		+ + + + +
+ OK with me.
+
+ + diff --git a/docs/mantis/CR3379.md b/docs/mantis/CR3379.md new file mode 100644 index 0000000000000000000000000000000000000000..cfb1b7dffb67c2c3015b8dc69285a247583e48d6 --- /dev/null +++ b/docs/mantis/CR3379.md @@ -0,0 +1,162 @@ + + + + + + + + + + + + + 0003379: Cyclic definitions - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0003379Part 01: TTCN-3 Core LanguageClarificationpublic16-05-2008 09:3118-07-2008 10:56
ReporterThomas Deiß 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)clauses 15, 10, 11, 8.2.1
Source (company - Author)Nokia Siemens Networks, Thomas Deiß
Summary0003379: Cyclic definitions
DescriptionIt is not clear from part1 to which cyclic definitions are erroneous.
+
+For types and functions/altsteps this is explicitly allowed. Whereas for component type extension and template modification it is explicitly forbidden.
+
+For constants, modulepars, variables, and templates in general this is not clear. Consider the following the example:
+
+module CyclicConstants {
+
+//const charstring x := "la" & y; //no finite value
+//const charstring y := x;
+  
+  type record ab {
+    integer a,
+    integer b
+  }
+
+  const ab AB := { a := 1, b := BA.a }; //{1,2}
+  const ab BA := { a := 2, b := AB.a }; //{2,1}
+}
+
+Obviously, the definition of x and y is incorrect as there is no corresponding finite value. But for AB and BA there are finite values as indicated.
+
+I suggest to add a restriction to the corresponding clauses for constants, modulepars, variables, and templates in general that cyclic definitions are not allowed and that cycles are determined on the level of the used identifiers. In the example above it would be checked whether there is a cycle AB -> BA -> AB.
+
+The restriction could be similar to the one for modified templates:
+clause 15.5, restriction a) a) A modified template shall not refer to itself, either directly or indirectly, i.e. recursive derivation is not allowed.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR-3379-Resolution-JG-080716.doc (160,256) 16-07-2008 12:08
http://oldforge.etsi.org/mantis/file_download.php?file_id=1552&type=bug
doc CR-3379-Resolution-JG-TD-080718.doc (148,480) 18-07-2008 08:40
http://oldforge.etsi.org/mantis/file_download.php?file_id=1555&type=bug
doc CR-3379-Resolution-JG-TD-IS-080719.doc (153,088) 18-07-2008 10:55
http://oldforge.etsi.org/mantis/file_download.php?file_id=1567&type=bug
Issue History
Date ModifiedUsernameFieldChange
16-05-2008 09:31Thomas DeißNew Issue
16-05-2008 09:31Thomas DeißStatusnew => assigned
16-05-2008 09:31Thomas DeißAssigned To => Thomas Deiß
16-05-2008 09:31Thomas DeißClause Reference(s) => clauses 15, 10, 11, 8.2.1
16-05-2008 09:31Thomas DeißSource (company - Author) => Nokia Siemens Networks, Thomas Deiß
16-05-2008 09:32Thomas DeißProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
16-05-2008 09:33Thomas DeißAssigned ToThomas Deiß => Ina Schieferdecker
20-06-2008 13:46Thomas DeißNote Added: 0006047
14-07-2008 15:23Ina SchieferdeckerAssigned ToIna Schieferdecker => Jens Grabowski
16-07-2008 12:08Jens GrabowskiFile Added: CR-3379-Resolution-JG-080716.doc
16-07-2008 12:09Jens GrabowskiNote Added: 0006295
16-07-2008 12:09Jens GrabowskiAssigned ToJens Grabowski => Thomas Deiß
18-07-2008 08:40Thomas DeißFile Added: CR-3379-Resolution-JG-TD-080718.doc
18-07-2008 08:42Thomas DeißNote Added: 0006318
18-07-2008 08:42Thomas DeißAssigned ToThomas Deiß => Ina Schieferdecker
18-07-2008 08:42Thomas DeißResolutionopen => fixed
18-07-2008 10:55Ina SchieferdeckerFile Added: CR-3379-Resolution-JG-TD-IS-080719.doc
18-07-2008 10:56Ina SchieferdeckerStatusassigned => closed
18-07-2008 10:56Ina SchieferdeckerFixed in Version => Edition 4.1.1 (not yet published)
18-07-2008 10:56Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0006047) +
+ Thomas Deiß    +
+ 20-06-2008 13:46    +
+ 		+ + + + +
+ Consider also the example, is this allowed or is this not allowed because the declarations can be considered as cyclic?
+
+type integer X (three, four);
+  
+const X three := 3;
+const X four := 4;
+
+
+
+ + + + + + + + + + +
+ (0006295) +
+ Jens Grabowski    +
+ 16-07-2008 12:09    +
+ 		+ + + + +
+ Proposal for Resolution attached.
+
+
+
+ + + + + + + + + + +
+ (0006318) +
+ Thomas Deiß    +
+ 18-07-2008 08:42    +
+ 		+ + + + +
+ CR will be resolved as new clause 5.5. First proposal updated accordingly.
+Reference to clause 5 to be added to each restriction.
+
+ + diff --git a/docs/mantis/CR3380.md b/docs/mantis/CR3380.md new file mode 100644 index 0000000000000000000000000000000000000000..8d074550fd43b8216be638f3acb24bde9911f70e --- /dev/null +++ b/docs/mantis/CR3380.md @@ -0,0 +1,195 @@ + + + + + + + + + + + + + 0003380: Renaming of component, port, address type - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0003380Part 01: TTCN-3 Core LanguageClarificationpublic16-05-2008 09:4412-12-2008 07:26
ReporterThomas Deiß 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)6.1.2
Source (company - Author)Nokia Siemens Networks, Thomas Deiß
Summary0003380: Renaming of component, port, address type
DescriptionFrom part1 it is unclear whether
+type Type1 Type2;
+would be valid if Type1 is a component or port types or if it is default, anytype, or address.
+
+Clause 6.1.2 states
+With user-defined types it is possible to create sub-types (such as lists, ranges and length restrictions) on basic types, structured types and anytype according to table 3.
+
+Table 3 does not allow subtyping of component, port, default, and address.
+I suggest to add a paragraph, that all types can be renamed. E.g.
+
+6.1.2.6 Type Renaming
+
+A type can be defined as a synonym to another type. This is applicable to all kinds of types.
+
+type MyType1 MyType2;
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0004851closed Ina Schieferdecker Editorials on Part-1 v4.0.4 
Attached Filesdoc CR3380_TypeRenaming.doc (24,064) 17-08-2008 10:22
http://oldforge.etsi.org/mantis/file_download.php?file_id=1612&type=bug
doc CR3380_TypeRenaming_02.doc (19,968) 18-08-2008 13:58
http://oldforge.etsi.org/mantis/file_download.php?file_id=1614&type=bug
doc CR3380_TypeRenaming_03.doc (24,576) 12-12-2008 07:23
http://oldforge.etsi.org/mantis/file_download.php?file_id=1885&type=bug
Issue History
Date ModifiedUsernameFieldChange
16-05-2008 09:44Thomas DeißNew Issue
16-05-2008 09:44Thomas DeißStatusnew => assigned
16-05-2008 09:44Thomas DeißAssigned To => Ina Schieferdecker
16-05-2008 09:44Thomas DeißClause Reference(s) => 6.1.2
16-05-2008 09:44Thomas DeißSource (company - Author) => Nokia Siemens Networks, Thomas Deiß
16-05-2008 09:44Thomas DeißProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
17-08-2008 09:35Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
17-08-2008 10:22Ina SchieferdeckerFile Added: CR3380_TypeRenaming.doc
17-08-2008 10:23Ina SchieferdeckerNote Added: 0006546
17-08-2008 10:24Ina SchieferdeckerAssigned ToIna Schieferdecker => Thomas Deiß
17-08-2008 10:24Ina SchieferdeckerResolutionopen => fixed
18-08-2008 13:58Thomas DeißFile Added: CR3380_TypeRenaming_02.doc
18-08-2008 14:01Thomas DeißNote Added: 0006560
18-08-2008 14:01Thomas DeißAssigned ToThomas Deiß => Ina Schieferdecker
18-08-2008 14:01Thomas DeißResolutionfixed => open
25-11-2008 15:11Ina SchieferdeckerNote Added: 0007416
25-11-2008 15:11Ina SchieferdeckerAssigned ToIna Schieferdecker => Thomas Deiß
25-11-2008 15:11Ina SchieferdeckerResolutionopen => fixed
26-11-2008 08:08Thomas DeißNote Added: 0007434
26-11-2008 08:08Thomas DeißAssigned ToThomas Deiß => Ina Schieferdecker
10-12-2008 12:28Ina SchieferdeckerStatusassigned => resolved
10-12-2008 12:28Ina SchieferdeckerFixed in Version => Edition 4.1.1 (not yet published)
12-12-2008 07:23Ina SchieferdeckerFile Added: CR3380_TypeRenaming_03.doc
12-12-2008 07:26Ina SchieferdeckerStatusresolved => closed
16-02-2009 05:26Ina SchieferdeckerRelationship addedrelated to 0004851
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0006546) +
+ Ina Schieferdecker    +
+ 17-08-2008 10:23    +
+ 		+ + + + +
+ Resolution uploaded: proposal to make type renaming clause a subclause to clause 6 and not only to subclause to 6.1.2 as this applies to all and not only to basic types.
+
+
+
+ + + + + + + + + + +
+ (0006560) +
+ Thomas Deiß    +
+ 18-08-2008 14:01    +
+ 		+ + + + +
+ checked: I suggest to leave out the part on type compatibility. According to the usual type compatibility rules, synonym types are compatible. Except for enumerations. Note that
+type enumeration A {a}
+type enumeration B {a}
+are _not_ compatible.
+Alternatively: if type compatibility should be mentioned, let's add this as a note , mentioning also the case of enumerations.
+I've uploaded a new resolution without mentioning type compatibility.
+
+
+
+ + + + + + + + + + +
+ (0007416) +
+ Ina Schieferdecker    +
+ 25-11-2008 15:11    +
+ 		+ + + + +
+ After discussion, synonym type should be compatible - this includes also enumerated types:
+
+type enumerated E { a, b, c }
+type E F;
+var E e;
+var F f;
+e:= f; // is ok
+
+To make this clear, clause 6.3.2.1 should be extended:
+
+"Enumerated types are only compatible to synonym types (see clause 6.4) and never compatible with other basic or structured types (i.e. for enumerated types strong typing is required)."
+
+
+
+ + + + + + + + + + +
+ (0007434) +
+ Thomas Deiß    +
+ 26-11-2008 08:08    +
+ 		+ + + + +
+ ok.
+
+ + diff --git a/docs/mantis/CR3381.md b/docs/mantis/CR3381.md new file mode 100644 index 0000000000000000000000000000000000000000..2da86ce4f34c71af5084e3e69b1276f04341a4a6 --- /dev/null +++ b/docs/mantis/CR3381.md @@ -0,0 +1,111 @@ + + + + + + + + + + + + + 0003381: scope unit of modulenames - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0003381Part 01: TTCN-3 Core LanguageClarificationpublic16-05-2008 10:0007-10-2008 07:07
ReporterThomas Deiß 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)5.2
Source (company - Author)Nokia Siemens Networks, Thomas Deiß
Summary0003381: scope unit of modulenames
DescriptionThe use of modulenames as identifiers is not 100% clear from part1:
+In the subsequent example, the declaration of ma as typeand of mb as local variable is not allowed because ma and mb are already used as modulenames and these are considered to be higher scope units. And then the general clause that identifiers of higher scope units must not be used in lower scope units applies. If that's the agreed understanding I suggest to add a paragraph mentioning to which scope unit a modulename belongs. ("The identifier of a module or of an imported module belongs to the scope unit of the module and cannot be used as identifier for other definitions inside the module.")
+
+module mb {
+  import from ma { type typA }
+  import from ma { type typB }
+
+  function plus1() return integer {
+    var integer mb := 1;
+    return mb;
+  }
+  
+  type boolean ma;
+}
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR3381_ModuleName.doc (31,232) 17-08-2008 10:38
http://oldforge.etsi.org/mantis/file_download.php?file_id=1613&type=bug
Issue History
Date ModifiedUsernameFieldChange
16-05-2008 10:00Thomas DeißNew Issue
16-05-2008 10:00Thomas DeißStatusnew => assigned
16-05-2008 10:00Thomas DeißAssigned To => Ina Schieferdecker
16-05-2008 10:00Thomas DeißClause Reference(s) => 5.2
16-05-2008 10:00Thomas DeißSource (company - Author) => Nokia Siemens Networks, Thomas Deiß
16-05-2008 10:01Thomas DeißProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
17-08-2008 09:35Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
17-08-2008 10:38Ina SchieferdeckerFile Added: CR3381_ModuleName.doc
17-08-2008 10:39Ina SchieferdeckerNote Added: 0006547
17-08-2008 10:39Ina SchieferdeckerAssigned ToIna Schieferdecker => Thomas Deiß
17-08-2008 10:39Ina SchieferdeckerResolutionopen => fixed
18-08-2008 13:53Thomas DeißNote Added: 0006559
19-08-2008 04:29Thomas DeißAssigned ToThomas Deiß => Ina Schieferdecker
07-10-2008 07:07Ina SchieferdeckerStatusassigned => resolved
07-10-2008 07:07Ina SchieferdeckerStatusresolved => closed
07-10-2008 07:07Ina SchieferdeckerFixed in Version => Edition 4.1.1 (not yet published)
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0006547) +
+ Ina Schieferdecker    +
+ 17-08-2008 10:39    +
+ 		+ + + + +
+ some rewording
+
+
+
+ + + + + + + + + + +
+ (0006559) +
+ Thomas Deiß    +
+ 18-08-2008 13:53    +
+ 		+ + + + +
+ checked: solution ok.
+
+ + diff --git a/docs/mantis/CR3382.md b/docs/mantis/CR3382.md new file mode 100644 index 0000000000000000000000000000000000000000..3305c4946051c78991769973192e2c4c29c9b8cd --- /dev/null +++ b/docs/mantis/CR3382.md @@ -0,0 +1,122 @@ + + + + + + + + + + + + + 0003382: cyclic import - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0003382Part 01: TTCN-3 Core LanguageClarificationpublic16-05-2008 10:0718-07-2008 10:54
ReporterThomas Deiß 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)8.2.3
Source (company - Author)Nokia Siemens Networks, Thomas Deiß
Summary0003382: cyclic import
DescriptionClause 8.2.3 states that cyclic imports are forbidden.
+It is unclear whether the example below qualifies as cyclic import.
+
+module a {
+  import from b { type x }
+  type record of x list_x;
+}
+
+module b {
+  type integer x;
+  import from a { type list_x }
+}
+
+
+I suggest to add a sentence to 8.2.3 that the cycles are considered on module level:
+"Cyclic imports are forbidden. Cycles are determined on module level"
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
16-05-2008 10:07Thomas DeißNew Issue
16-05-2008 10:07Thomas DeißStatusnew => assigned
16-05-2008 10:07Thomas DeißAssigned To => Ina Schieferdecker
16-05-2008 10:07Thomas DeißClause Reference(s) => 8.2.3
16-05-2008 10:07Thomas DeißSource (company - Author) => Nokia Siemens Networks, Thomas Deiß
14-07-2008 15:23Ina SchieferdeckerAssigned ToIna Schieferdecker => Jens Grabowski
15-07-2008 16:20Jens GrabowskiNote Added: 0006285
16-07-2008 09:37Jens GrabowskiAssigned ToJens Grabowski => Thomas Deiß
18-07-2008 08:44Thomas DeißNote Added: 0006319
18-07-2008 08:44Thomas DeißAssigned ToThomas Deiß => Ina Schieferdecker
18-07-2008 08:44Thomas DeißResolutionopen => fixed
18-07-2008 10:41Ina SchieferdeckerStatusassigned => closed
18-07-2008 10:41Ina SchieferdeckerFixed in Version => Edition 4.1.1 (not yet published)
18-07-2008 10:41Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
18-07-2008 10:54Ina SchieferdeckerFile Added: CR-3379-Resolution-JG-TD-IS-080719.doc
18-07-2008 10:55Ina SchieferdeckerFile Deleted: CR-3379-Resolution-JG-TD-IS-080719.doc
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0006285) +
+ Jens Grabowski    +
+ 15-07-2008 16:20    +
+ 		+ + + + +
+ Proposal for resolution:
+
+Delete restriction "h) Cyclic imports are forbidden" in Clause 8.2.3.1.
+
+Reasons:
+- The original reason for introducing this restriction was to avoid cyclic definitions. However, the problem of cyclic definitions has to be solved on module level. See CR 3379
+
+- Furthermore, originally the cyclic imports restriction was meant to work on definition level but could be misinterpreted as a restriction on module level. For example:
+module A imports const B-const of type integer from Module B
+module B imports const A-const of type integer from Module A
+can be interpretet as a cyclic import on module level (module A imports from B and B imports from A), but causes no problems at all.
+
+
+
+ + + + + + + + + + +
+ (0006319) +
+ Thomas Deiß    +
+ 18-07-2008 08:44    +
+ 		+ + + + +
+ Proposed solution (see previous note) is ok.
+
+ + diff --git a/docs/mantis/CR3383.md b/docs/mantis/CR3383.md new file mode 100644 index 0000000000000000000000000000000000000000..4ed341c68c8899cb1d1636ad2ff3f163b1add976 --- /dev/null +++ b/docs/mantis/CR3383.md @@ -0,0 +1,176 @@ + + + + + + + + + + + + + 0003383: Order of assignments of fields - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0003383Part 01: TTCN-3 Core LanguageClarificationpublic16-05-2008 10:2909-12-2008 14:33
ReporterThomas Deiß 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.3.2 (published 2008-04) 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)7, 16.1.1, 16.2.1,
Source (company - Author)Nokia Siemens Networks, Thomas Deiß
Summary0003383: Order of assignments of fields
DescriptionPart 1 does not define the order of assignments of fields or elements of structured types. Consider the following example:
+module assign {
+  type record t {
+    integer a,
+    integer b
+  }
+  
+  control {
+    var t x;
+    
+    x := {2, 3};
+    x := { a := 4, b := x.a }
+    log(x.b);
+    
+    x := {2, 3};
+    x := {4, x.a};
+    log(x.b);
+  }
+}
+
+Part 1 leaves it open in which order the individual fields are processed. I suggest to add a statement to clause 7 that operands in expressions, including fields in structured types are evaluated from left to right.
+
+A similar sentence should be added to the invocation of functions or altsteps: Actual parameters are evaluated from left to right.
+
+Part 4 does not resolve this issue either.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0004155closed Ina Schieferdecker Clarification on the order of assignments 
Attached Filesdoc CR3383_OrderOfAssignments.doc (110,592) 27-11-2008 14:29
http://oldforge.etsi.org/mantis/file_download.php?file_id=1817&type=bug
doc CR3383_OrderOfAssignments_02.doc (114,688) 28-11-2008 08:19
http://oldforge.etsi.org/mantis/file_download.php?file_id=1827&type=bug
doc CR3383_InoutParameterization.doc (24,576) 28-11-2008 10:57
http://oldforge.etsi.org/mantis/file_download.php?file_id=1834&type=bug
Issue History
Date ModifiedUsernameFieldChange
16-05-2008 10:29Thomas DeißNew Issue
16-05-2008 10:29Thomas DeißStatusnew => assigned
16-05-2008 10:29Thomas DeißAssigned To => Ina Schieferdecker
16-05-2008 10:29Thomas DeißClause Reference(s) => 7, 16.1.1, 16.2.1,
16-05-2008 10:29Thomas DeißSource (company - Author) => Nokia Siemens Networks, Thomas Deiß
17-08-2008 09:34Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
29-08-2008 04:30Thomas DeißNote Added: 0006647
18-09-2008 04:16Thomas DeißRelationship addedrelated to 0004155
27-11-2008 10:35Ina SchieferdeckerFile Added: CR3383_OrderOfAssignments.doc
27-11-2008 10:36Ina SchieferdeckerNote Added: 0007468
27-11-2008 10:36Ina SchieferdeckerAssigned ToIna Schieferdecker => Thomas Deiß
27-11-2008 10:36Ina SchieferdeckerResolutionopen => fixed
27-11-2008 14:28Ina SchieferdeckerFile Deleted: CR3383_OrderOfAssignments.doc
27-11-2008 14:29Ina SchieferdeckerFile Added: CR3383_OrderOfAssignments.doc
28-11-2008 08:19Thomas DeißFile Added: CR3383_OrderOfAssignments_02.doc
28-11-2008 08:20Thomas DeißNote Added: 0007491
28-11-2008 08:20Thomas DeißAssigned ToThomas Deiß => Ina Schieferdecker
28-11-2008 10:57Ina SchieferdeckerFile Added: CR3383_InoutParameterization.doc
09-12-2008 14:33Ina SchieferdeckerStatusassigned => resolved
09-12-2008 14:33Ina SchieferdeckerFixed in Version => Edition 4.1.1 (not yet published)
09-12-2008 14:33Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0006647) +
+ Thomas Deiß    +
+ 29-08-2008 04:30    +
+ 		+ + + + +
+ It should be further clarified whether expressions on the left hand side of an assignment are evaluated before or after those on the right hand side. Also the precedence of . and [] in comparison to the other operators is unclear.
+
+In the subsequent example it is actually quite unclear, what the result would be.
+
+module evaluation {
+  function inc(inout integer n) return integer {
+    n := n + 1
+    return n
+  }
+  
+  control {
+    var integer i := -1
+    var integer a[8] := {3, 6, 4, 9, 13, 0, 23, 66}
+    
+    a[inc(i)] := a[inc(a[inc(i)])] + (a[inc(i)] - a[inc(i)])
+
+    // a[0] := a[7] + (a[2] - a[3])
+    // a is now {3, 7, 4, 9, 13, 0, 23, 66}
+    // a[0] := 66 + (4 - 9)
+    // a[0] := 61
+  }
+}
+
+
+
+ + + + + + + + + + +
+ (0007468) +
+ Ina Schieferdecker    +
+ 27-11-2008 10:36    +
+ 		+ + + + +
+ please check
+
+
+
+ + + + + + + + + + +
+ (0007491) +
+ Thomas Deiß    +
+ 28-11-2008 08:20    +
+ 		+ + + + +
+ editorial corrections
+
+ + diff --git a/docs/mantis/CR3384.md b/docs/mantis/CR3384.md new file mode 100644 index 0000000000000000000000000000000000000000..ba5ca3dbc4ee1e8ddd10e536a67f24e21198b482 --- /dev/null +++ b/docs/mantis/CR3384.md @@ -0,0 +1,170 @@ + + + + + + + + + + + + + 0003384: Usage of declarations within component types - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0003384Part 01: TTCN-3 Core LanguageClarificationpublic16-05-2008 10:4210-12-2008 12:52
ReporterThomas Deiß 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.3.2 (published 2008-04) 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)5.2
Source (company - Author)Nokia Siemens Networks, Thomas Deiß
Summary0003384: Usage of declarations within component types
DescriptionClause 5.2 contains the following statement:
+Definitions made in a test component type may be used only in functions, test cases and altsteps referencing that component type or a consistent test component type (see clause 6.3.3) by a runs on-clause.
+
+This is basically a matter of interpreting the english sentence. But this could be understood that e.g. a constant declared in a component type cannot be used in another declaration of the same component type (or an extension of it). If such a strict interpretation is taken, the example below would be invalid.
+
+module m {
+  type component A {
+    const integer C1 := 1;
+  }
+  
+  type component B extends A {
+    const integer C2 := 2;
+    var integer ia[C1] := {C3};
+    var integer i := ia[0];
+    const integer C3 := C1 + C2;
+  }
+}
+
+I suggest to relax the statement to
+"Definitions made in a test component type may be used in the component type defintion, when extending the component type definition, and in functions, test cases and altsteps referencing that component type or a consistent test component type (see clause 6.3.3) by a runs on-clause."
+
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
16-05-2008 10:42Thomas DeißNew Issue
16-05-2008 10:42Thomas DeißStatusnew => assigned
16-05-2008 10:42Thomas DeißAssigned To => Ina Schieferdecker
16-05-2008 10:42Thomas DeißClause Reference(s) => 5.2
16-05-2008 10:42Thomas DeißSource (company - Author) => Nokia Siemens Networks, Thomas Deiß
17-08-2008 09:34Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
25-11-2008 15:17Ina SchieferdeckerNote Added: 0007417
25-11-2008 15:18Ina SchieferdeckerAssigned ToIna Schieferdecker => Thomas Deiß
25-11-2008 15:18Ina SchieferdeckerResolutionopen => fixed
26-11-2008 07:58Thomas DeißNote Added: 0007432
26-11-2008 07:58Thomas DeißAssigned ToThomas Deiß => Ina Schieferdecker
10-12-2008 12:51Ina SchieferdeckerNote Added: 0007629
10-12-2008 12:51Ina SchieferdeckerStatusassigned => resolved
10-12-2008 12:51Ina SchieferdeckerFixed in Version => Edition 4.1.1 (not yet published)
10-12-2008 12:52Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0007417) +
+ Ina Schieferdecker    +
+ 25-11-2008 15:17    +
+ 		+ + + + +
+ Just some rephrasing:
+
+"Definitions made in a test component type may be used in a component type extending this component type definition, and in functions, test cases and altsteps referencing that component type or a consistent test component type (see clause 6.3.3) by a runs on-clause."
+
+An example could be added:
+
+  type component MyComponentType {
+    const integer MyConst := 1;
+    ...
+  }
+  
+  type component MyExtendedComponentType extends MyComponentType {
+    var integer MyVar:= 2 * MyConst;
+    ...
+  }
+
+
+
+ + + + + + + + + + +
+ (0007432) +
+ Thomas Deiß    +
+ 26-11-2008 07:58    +
+ 		+ + + + +
+ The example clarifies the issue, so that's also ok for me.
+
+The solution uses 'consistent' instead of 'compatible'. There is a risk that CR 3951 is undone by this correction.
+
+
+
+ + + + + + + + + + +
+ (0007629) +
+ Ina Schieferdecker    +
+ 10-12-2008 12:51    +
+ 		+ + + + +
+ Reworded to "Definitions made in a test component type may be used in a component type extending this component type definition, and in functions, test cases and altsteps referencing that component type or a compatible test component type (see clause 6.3.3) by a runs on-clause."
+
+and example added.
+
+ + diff --git a/docs/mantis/CR3385.md b/docs/mantis/CR3385.md new file mode 100644 index 0000000000000000000000000000000000000000..5eece114a903ced197ef506bfc97412aa0d06c17 --- /dev/null +++ b/docs/mantis/CR3385.md @@ -0,0 +1,98 @@ + + + + + + + + + + + + + 0003385: Reset list of defaults on alive components - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0003385Part 01: TTCN-3 Core LanguageClarificationpublic16-05-2008 19:0917-12-2008 07:38
ReporterThomas Deiß 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.3.2 (published 2008-04) 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)part4, 9.49.2
Source (company - Author)Nokia Siemens Networks, Thomas Deiß
Summary0003385: Reset list of defaults on alive components
DescriptionThe default list is reset when starting new behaviour on an alive component. The test case pass if a tool implements this functionality correctly.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files? DefaultReset.ttcn (1,004) 16-05-2008 19:09
http://oldforge.etsi.org/mantis/file_download.php?file_id=1492&type=bug
doc CR-3385-Reset-list-of-defaults-Resolution-V1.doc (165,376) 16-12-2008 11:02
http://oldforge.etsi.org/mantis/file_download.php?file_id=1900&type=bug
Issue History
Date ModifiedUsernameFieldChange
16-05-2008 19:09Thomas DeißNew Issue
16-05-2008 19:09Thomas DeißStatusnew => assigned
16-05-2008 19:09Thomas DeißAssigned To => Thomas Deiß
16-05-2008 19:09Thomas DeißFile Added: DefaultReset.ttcn
16-05-2008 19:09Thomas DeißClause Reference(s) => part4, 9.49.2
16-05-2008 19:09Thomas DeißSource (company - Author) => Nokia Siemens Networks, Thomas Deiß
16-05-2008 19:23Thomas DeißProjectPart 01: TTCN-3 Core Language => @59@
17-08-2008 09:30Ina SchieferdeckerProject@59@ => Part 01: TTCN-3 Core Language
17-08-2008 09:31Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
17-08-2008 09:32Ina SchieferdeckerAssigned ToThomas Deiß => Jens Grabowski
16-12-2008 11:02Jens GrabowskiFile Added: CR-3385-Reset-list-of-defaults-Resolution-V1.doc
16-12-2008 11:05Jens GrabowskiNote Added: 0007713
16-12-2008 12:24Jens GrabowskiAssigned ToJens Grabowski => Thomas Deiß
16-12-2008 12:24Jens GrabowskiStatusassigned => resolved
16-12-2008 14:13Thomas DeißNote Added: 0007718
16-12-2008 14:13Thomas DeißAssigned ToThomas Deiß => Ina Schieferdecker
16-12-2008 14:13Thomas DeißStatusresolved => assigned
17-12-2008 07:35Ina SchieferdeckerResolutionopen => fixed
17-12-2008 07:38Ina SchieferdeckerStatusassigned => resolved
17-12-2008 07:38Ina SchieferdeckerFixed in Version => Edition 4.1.1 (not yet published)
17-12-2008 07:38Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0007713) +
+ Jens Grabowski    +
+ 16-12-2008 11:05    +
+ 		+ + + + +
+ In the operational semantics, the default list is cleared in the stop operation.
+
+
+
+ + + + + + + + + + +
+ (0007718) +
+ Thomas Deiß    +
+ 16-12-2008 14:13    +
+ 		+ + + + +
+ This is ok.
+(I had to change the status from resolved to assigned to be able to add note, therefore please consider the CR as resolved.)
+
+ + diff --git a/docs/mantis/CR3405.md b/docs/mantis/CR3405.md new file mode 100644 index 0000000000000000000000000000000000000000..2bd5d083321060c60c46f97b6b31e7e8a28904df --- /dev/null +++ b/docs/mantis/CR3405.md @@ -0,0 +1,46 @@ + + + + + + + + + + + + + 0003405: Editorials in modified template examples - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0003405Part 01: TTCN-3 Core LanguageEditorialpublic21-05-2008 16:2218-07-2008 11:20
ReporterGyorgy Rethy 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)$15.5
Source (company - Author)L.M.Ericsson
Summary0003405: Editorials in modified template examples
DescriptionCorrected parts:
+EXAMPLE1:
+    // Given
+    type record MyRecordType
+    {
+        integer field1 optional, //field->field1,
+                                         //referred to as optional later
+        charstring field2,
+        boolean field3
+    }
+EXAMPLE4:
+...
+    // then a modification could be
+        template MyRecordType MyTemplate2(integer MyPar) modifies MyTemplate1 :=
+    { // field1 is parameterized in Template1 and remains also parameterized in Template2
+        field2 := "A modified string" //->comma after the value
+    }
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
21-05-2008 16:22Gyorgy RethyNew Issue
21-05-2008 16:22Gyorgy RethyStatusnew => assigned
21-05-2008 16:22Gyorgy RethyAssigned To => Ina Schieferdecker
21-05-2008 16:22Gyorgy RethyClause Reference(s) => $15.5
21-05-2008 16:22Gyorgy RethySource (company - Author) => L.M.Ericsson
17-07-2008 10:53Ina SchieferdeckerStatusassigned => resolved
17-07-2008 10:53Ina SchieferdeckerResolutionopen => fixed
17-07-2008 10:53Ina SchieferdeckerFixed in Version => Edition 4.1.1 (not yet published)
17-07-2008 10:53Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
18-07-2008 11:20Ina SchieferdeckerStatusresolved => closed
+
+ + + + +
+ There are no notes attached to this issue.
+ + diff --git a/docs/mantis/CR3476.md b/docs/mantis/CR3476.md new file mode 100644 index 0000000000000000000000000000000000000000..f866b6b520493d2f05344e0536b7002d09de22f9 --- /dev/null +++ b/docs/mantis/CR3476.md @@ -0,0 +1,216 @@ + + + + + + + + + + + + + 0003476: Mistake in grammar rule TemplateBody - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0003476Part 01: TTCN-3 Core LanguageClarificationpublic30-05-2008 13:3314-08-2008 05:40
ReporterElena de Vega 
Assigned ToThomas Deiß 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv3.4.1 (published 2008-09)Fixed in Versionv3.4.1 (published 2008-09) 
Clause Reference(s)Grammar, templateBody
Source (company - Author) Elena de Vega - MTP
Summary0003476: Mistake in grammar rule TemplateBody
DescriptionI have analyzed the TTCN-3 grammar and I think there is a mistake.
+
+This mistake is in the rule 102, its name is TemplateBody:
+
+102. TemplateBody ::= (SimpleSpec | FieldSpecList | ArrayValueOrAttrib) | [ExtraMatchingAttributes]
+
+This rule is called from these other rules:
+
+94.- TemplateDef::= TemplateKeyword BaseTemplate [DerivedDef] AssignmentChar TemplateBody
+105.- FieldSpec::= FieldReference AssignmentChar TemplateBody
+115.- ArrayElementSpec::= NotUsedSymbol | PermutationMatch | TemplateBody
+136.- PermutationList::= "(" TemplateBody { "," TemplateBody } ")"
+139.- ValueOrAttribList::= "(" TemplateBody {"," TemplateBody }+ ")"
+150.- InLineTemplate::= [(Type | Signature) Colon] [DerivedRefWithParList AssignmentChar] TemplateBody
+294.- TempVarInitialValue::= TemplateBody
+578.- Assignment::= VariableRef AssignmentChar (Expression | TemplateBody)
+
+For example, the rule TemplateDef will match with “nothing” after AssignmentChar because you have the alternative [ExtraMatchingAttributes] in the rule TemplateBody, which is actually optional.
+
+For example the grammar matches:
+
+template MyMessageType MyTemplate:= ;
+
+or
+
+template MyMessageType MyTemplate:= length(8);
+
+
+The solution could be:
+
+TemplateBody ::= (SimpleSpec | FieldSpecList | ArrayValueOrAttrib) [ExtraMatchingAttributes]
+
+It’s the same rule without “|”. In this way the grammar will not match the template “template MyMessageType MyTemplate:= ;” or template MyMessageType MyTemplate:= length(8);
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
30-05-2008 13:33Elena de VegaNew Issue
30-05-2008 13:33Elena de VegaClause Reference(s) => Grammar, templateBody
30-05-2008 13:33Elena de VegaSource (company - Author) => Elena de Vega - MTP
14-07-2008 12:28Ina SchieferdeckerAssigned To => Ina Schieferdecker
14-07-2008 12:28Ina SchieferdeckerStatusnew => resolved
14-07-2008 12:28Ina SchieferdeckerResolutionopen => fixed
14-07-2008 12:28Ina SchieferdeckerProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
14-07-2008 12:28Ina SchieferdeckerCategoryTTCN-3 Core Language => Clarification
14-07-2008 12:28Ina SchieferdeckerFixed in Version => Edition 3.4.1 (not yet published)
14-07-2008 12:28Ina SchieferdeckerTarget Version => Edition 3.4.1 (not yet published)
14-07-2008 14:07Ina SchieferdeckerStatusresolved => assigned
14-07-2008 14:07Ina SchieferdeckerAssigned ToIna Schieferdecker => Thomas Deiß
15-07-2008 09:19Thomas DeißNote Added: 0006267
15-07-2008 09:21Thomas DeißNote Added: 0006268
28-07-2008 11:49Elena de VegaNote Added: 0006391
14-08-2008 05:40Thomas DeißNote Added: 0006517
14-08-2008 05:40Thomas DeißStatusassigned => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0006267) +
+ Thomas Deiß    +
+ 15-07-2008 09:19    +
+ 		+ + + + +
+ The change to rule TemplateBody is ok.
+
+What is not ok is the rule for IfPresentMatch:
+142. IfPresentKeyword ::= IfKeyword PresentKeyword
+143. PresentKeyword ::= "present"
+
+This will allow to put a blank between 'if' and 'present'.
+The rule for IfPresentKeyword should be changed to
+142. IfPresentKeyword ::= "ifpresent"
+
+PresentKeyword is still needed (for template restriction) and has to be added to the table of keywords in clause A.
+
+
+
+ + + + + + + + + + +
+ (0006268) +
+ Thomas Deiß    +
+ 15-07-2008 09:21    +
+ 		+ + + + +
+ In edition 3.2 the rule for IfPresentKeyword was ok,
+in edition 3.3 this was changed to "if present", which is incorrect. Note that there is a blank in the keyword.
+This incorrect keyword was continued in edition 3.4
+(This is just for information)
+
+
+
+ + + + + + + + + + +
+ (0006391) +
+ Elena de Vega    +
+ 28-07-2008 11:49    +
+ 		+ + + + +
+ I have checked the IfPresentKeyword rule in v3.2.1 and it's ok, but in the v3.3.2 there are the mistake that you have commented. This mistake is:
+
+141. IfPresentMatch ::= IfPresentKeyword
+142. IfPresentKeyword ::= "if present"
+
+In the rule 142 the two words are separated.
+
+
+
+ + + + + + + + + + +
+ (0006517) +
+ Thomas Deiß    +
+ 14-08-2008 05:40    +
+ 		+ + + + +
+ the subsequent issue on the split ifpresent will also be corrected in edition 3.4.1.
+
+ + diff --git a/docs/mantis/CR3485.md b/docs/mantis/CR3485.md new file mode 100644 index 0000000000000000000000000000000000000000..a02a77e71eb2411924e9c1a5f2153e77c8bd40c7 --- /dev/null +++ b/docs/mantis/CR3485.md @@ -0,0 +1,105 @@ + + + + + + + + + + + + + 0003485: ITU-T Recommendation Z.165 (13.11.2007) editorial problems - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 05: TTCN-3 Runtime Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0003485Part 05: TTCN-3 Runtime Interface Editorialpublic02-06-2008 15:1514-08-2008 13:18
Reporteruser10 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.3.1 (published 2008-04) 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)several different clauses
Source (company - Author)ITU-T
Summary0003485: ITU-T Recommendation Z.165 (13.11.2007) editorial problems
DescriptionThe attachement contains an email from the ITU-T editing team describing 9 issues found in the Runtime Interface.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filestxt ITU-T Recommendation Z.165 (13.11.2007) editorial problems.txt (4,465) 02-06-2008 15:15
http://oldforge.etsi.org/mantis/file_download.php?file_id=1501&type=bug
zip es_20187305v030402_MasterCopy.zip (254,653) 14-08-2008 13:11
http://oldforge.etsi.org/mantis/file_download.php?file_id=1600&type=bug
Issue History
Date ModifiedUsernameFieldChange
02-06-2008 15:15user10New Issue
02-06-2008 15:15user10Statusnew => assigned
02-06-2008 15:15user10Assigned To => Ina Schieferdecker
02-06-2008 15:15user10File Added: ITU-T Recommendation Z.165 (13.11.2007) editorial problems.txt
02-06-2008 15:15user10Clause Reference(s) => several different clauses
02-06-2008 15:15user10Source (company - Author) => ITU-T
02-06-2008 15:18user10Target Version => Edition 4.1.1 (not yet published)
14-07-2008 14:12Ina SchieferdeckerAssigned ToIna Schieferdecker => Thomas Deiß
18-07-2008 10:03Thomas DeißNote Added: 0006330
18-07-2008 10:03Thomas DeißAssigned ToThomas Deiß => Ina Schieferdecker
14-08-2008 13:10Ina SchieferdeckerNote Added: 0006527
14-08-2008 13:11Ina SchieferdeckerFile Added: es_20187305v030402_MasterCopy.zip
14-08-2008 13:14Ina SchieferdeckerNote Added: 0006528
14-08-2008 13:15Ina SchieferdeckerStatusassigned => resolved
14-08-2008 13:15Ina SchieferdeckerResolutionopen => fixed
14-08-2008 13:15Ina SchieferdeckerFixed in Version => Edition 4.1.1 (not yet published)
14-08-2008 13:16Ina SchieferdeckerNote Deleted: 0006528
14-08-2008 13:17Ina SchieferdeckerNote Edited: 0006527
14-08-2008 13:18Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0006330) +
+ Thomas Deiß    +
+ 18-07-2008 10:03    +
+ 		+ + + + +
+ reply to ITU and changes made on the document are ok.
+
+There is one further change to be made in 6.5.2.2:
+public void triEnqueueReply(TriPortId tsiPortId, TriAddress address, ...
+  address should be sutAddress.
+
+
+
+ + + + + + + + + + +
+ (0006527) +
+ Ina Schieferdecker    +
+ 14-08-2008 13:10    +
(edited on: 14-08-2008 13:17)
+ 		+ + + + +
+ issues fixed already in v3.4.1 - see attachment
+
+additional issue for enqueueReply resolved for v4.1.1 accordingly
+
+
+
+ + diff --git a/docs/mantis/CR3603.md b/docs/mantis/CR3603.md new file mode 100644 index 0000000000000000000000000000000000000000..0c1ba5c1ba969aa7141c9946d0a6bb46e0203775 --- /dev/null +++ b/docs/mantis/CR3603.md @@ -0,0 +1,63 @@ + + + + + + + + + + + + + 0003603: Clarify element's length in case of strings for AnyElement - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0003603Part 01: TTCN-3 Core LanguageEditorialpublic18-06-2008 17:1217-08-2008 10:12
ReporterGyorgy Rethy 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.3.2 (published 2008-04) 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)B.1.3.1
Source (company - Author)L.M.Ericsson
Summary0003603: Clarify element's length in case of strings for AnyElement
Description"The matching symbol "?" (AnyElement) is used to indicate that it replaces single elements of a string (except character strings), " -> add a reference to Table 4 in clause 6.1.2.3 to remove user ambiguity if "?" replaces a single hex digit or a pair of hex digits.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR3603_AnyElementInString.doc (26,112) 18-07-2008 10:34
http://oldforge.etsi.org/mantis/file_download.php?file_id=1564&type=bug
Issue History
Date ModifiedUsernameFieldChange
18-06-2008 17:12Gyorgy RethyNew Issue
18-06-2008 17:12Gyorgy RethyStatusnew => assigned
18-06-2008 17:12Gyorgy RethyAssigned To => Ina Schieferdecker
18-06-2008 17:12Gyorgy RethyClause Reference(s) => B.1.3.1
18-06-2008 17:12Gyorgy RethySource (company - Author) => L.M.Ericsson
18-07-2008 10:34Ina SchieferdeckerFile Added: CR3603_AnyElementInString.doc
18-07-2008 10:34Ina SchieferdeckerAssigned ToIna Schieferdecker => Gyorgy Rethy
18-07-2008 10:34Ina SchieferdeckerResolutionopen => fixed
18-07-2008 10:34Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
15-08-2008 11:03Gyorgy RethyNote Added: 0006543
15-08-2008 11:03Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
15-08-2008 11:03Gyorgy RethyStatusassigned => resolved
17-08-2008 10:12Ina SchieferdeckerStatusresolved => closed
17-08-2008 10:12Ina SchieferdeckerFixed in Version => Edition 4.1.1 (not yet published)
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0006543) +
+ Gyorgy Rethy    +
+ 15-08-2008 11:03    +
+ 		+ + + + +
+ Attached file checked, OK from my side
+
+ + diff --git a/docs/mantis/CR3614.md b/docs/mantis/CR3614.md new file mode 100644 index 0000000000000000000000000000000000000000..050d2ea7f90b3a881f7d7774b307f9255b736122 --- /dev/null +++ b/docs/mantis/CR3614.md @@ -0,0 +1,71 @@ + + + + + + + + + + + + + 0003614: negative operands for rotate/shift - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0003614Part 01: TTCN-3 Core LanguageClarificationpublic20-06-2008 13:4410-12-2008 08:56
ReporterThomas Deiß 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.3.2 (published 2008-04) 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)7.1.6., 7.1.7
Source (company - Author)Nokia Siemens Networks - Thomas Deiß
Summary0003614: negative operands for rotate/shift
DescriptionThe amount of shift units for the shift and rotate operators is defined as an integer. This operand is unrestricted. The standard does not specify the behaviour for negative operands and for operands larger than the length of the string.
+
+Proposed solution:
+for the rotate operators determine the amount of shift units modulo the length of the string (provided this is a non-empty string).
+
+for the shift operators: a negative operand is considered a noop. an operand larger than the length of the string means to fill it completely with 0.
+
+Alternative solution: forbid negative operands. If the shift amount is larger than the string length proceed as above.
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR3614 - shift and rotate.doc (154,624) 28-11-2008 08:46
http://oldforge.etsi.org/mantis/file_download.php?file_id=1831&type=bug
Issue History
Date ModifiedUsernameFieldChange
20-06-2008 13:44Thomas DeißNew Issue
20-06-2008 13:44Thomas DeißStatusnew => assigned
20-06-2008 13:44Thomas DeißAssigned To => Ina Schieferdecker
20-06-2008 13:44Thomas DeißClause Reference(s) => 7.1.6., 7.1.7
20-06-2008 13:44Thomas DeißSource (company - Author) => Nokia Siemens Networks - Thomas Deiß
14-07-2008 15:35Ina SchieferdeckerAssigned ToIna Schieferdecker => Gyorgy Rethy
17-08-2008 09:16Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
28-11-2008 08:46Gyorgy RethyFile Added: CR3614 - shift and rotate.doc
28-11-2008 08:46Gyorgy RethyAssigned ToGyorgy Rethy => Thomas Deiß
28-11-2008 12:13Thomas DeißNote Added: 0007498
28-11-2008 12:14Thomas DeißAssigned ToThomas Deiß => Ina Schieferdecker
28-11-2008 12:14Thomas DeißStatusassigned => resolved
10-12-2008 08:56Ina SchieferdeckerStatusresolved => closed
10-12-2008 08:56Ina SchieferdeckerResolutionopen => fixed
10-12-2008 08:56Ina SchieferdeckerFixed in Version => Edition 4.1.1 (not yet published)
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0007498) +
+ Thomas Deiß    +
+ 28-11-2008 12:13    +
+ 		+ + + + +
+ ok.
+
+ + diff --git a/docs/mantis/CR3615.md b/docs/mantis/CR3615.md new file mode 100644 index 0000000000000000000000000000000000000000..e0d526ceb143f90f2d262fc7defbb67c36dc0d1e --- /dev/null +++ b/docs/mantis/CR3615.md @@ -0,0 +1,34 @@ + + + + + + + + + + + + + 0003615: superfluous word - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0003615Part 01: TTCN-3 Core LanguageEditorialpublic20-06-2008 15:5118-07-2008 11:25
ReporterThomas Deiß 
Assigned ToIna Schieferdecker 
PrioritylowSeveritytextReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.3.2 (published 2008-04) 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)B.1.5.4
Source (company - Author)Nokia Siemens Networks - Thomas Deiß
Summary0003615: superfluous word
DescriptionIn the example
+
+template MyCharRange myTempPatt3 := pattern "\N { MyCharList }";
+    // myTempPatt3 and shall match strings "a" and "r" only
+    
+the first 'and' in the second line should be removed.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
20-06-2008 15:51Thomas DeißNew Issue
20-06-2008 15:51Thomas DeißStatusnew => assigned
20-06-2008 15:51Thomas DeißAssigned To => Ina Schieferdecker
20-06-2008 15:51Thomas DeißClause Reference(s) => B.1.5.4
20-06-2008 15:51Thomas DeißSource (company - Author) => Nokia Siemens Networks - Thomas Deiß
17-07-2008 10:42Ina SchieferdeckerStatusassigned => resolved
17-07-2008 10:42Ina SchieferdeckerResolutionopen => fixed
17-07-2008 10:42Ina SchieferdeckerFixed in Version => Edition 4.1.1 (not yet published)
17-07-2008 10:42Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
18-07-2008 11:25Ina SchieferdeckerStatusresolved => closed
+
+ + + + +
+ There are no notes attached to this issue.
+ + diff --git a/docs/mantis/CR3619.md b/docs/mantis/CR3619.md new file mode 100644 index 0000000000000000000000000000000000000000..118d76bf9d748194f381c5376bd1098d45a78ffd --- /dev/null +++ b/docs/mantis/CR3619.md @@ -0,0 +1,101 @@ + + + + + + + + + + + + + 0003619: whitespace in pattern metacharacters - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0003619Part 01: TTCN-3 Core LanguageEditorialpublic24-06-2008 09:0810-12-2008 10:52
ReporterThomas Deiß 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.3.2 (published 2008-04) 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)B.1.5
Source (company - Author)Nokia Siemens Networks - Thomas Deiss
Summary0003619: whitespace in pattern metacharacters
DescriptionClause B.1.5 (before table B.1) states that meta characters shall not contain whitespace. But the examples in B.1.5.4 on character references contain whitespace in the examples. This is contradicting and the whitespace should be removed from the examples.
+
+Clauses B.1.5.2. and B.1.5.4 on (character) references refer to templates, constants, variables, and module parameters. This can be understood such that only declared templates etc. as a whole can be referenced, but that fields of a template or variable cannot be referenced. But as the text mentions 'existing' templates it is not really clear whether fields of a template etc. would be disallowed. It should be clarified whether the reference has to be an identifier or whether it can be an expression. Expression could be reference to a field or could be a call of a template computing function. No preference in the one or other direction, main issue is to clarify this.
+
+Clause B.1.5.2 allows to reference a formal parameter, whereas Clause B.1.5.4 does not do so. This should be aligned, i.e. add formal parameter to the list of referable entities.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0003760closed Ina Schieferdecker correct usage of metacharacters 
related to 0003761closed Gyorgy Rethy Pattern concatenation 
Attached Filesdoc CRs3619_3760_3761_resolution_v1.doc (212,992) 15-08-2008 12:31
http://oldforge.etsi.org/mantis/file_download.php?file_id=1610&type=bug
doc CRs3619_3760_3761_resolution_v1_1.doc (214,528) 30-09-2008 00:43
http://oldforge.etsi.org/mantis/file_download.php?file_id=1665&type=bug
Issue History
Date ModifiedUsernameFieldChange
24-06-2008 09:08Thomas DeißNew Issue
24-06-2008 09:08Thomas DeißStatusnew => assigned
24-06-2008 09:08Thomas DeißAssigned To => Ina Schieferdecker
24-06-2008 09:08Thomas DeißClause Reference(s) => B.1.5
24-06-2008 09:08Thomas DeißSource (company - Author) => Nokia Siemens Networks - Thomas Deiss
14-07-2008 15:09Ina SchieferdeckerAssigned ToIna Schieferdecker => Gyorgy Rethy
15-08-2008 12:31Gyorgy RethyFile Added: CRs3619_3760_3761_resolution_v1.doc
15-08-2008 12:34Gyorgy RethyNote Added: 0006544
15-08-2008 12:35Gyorgy RethyAssigned ToGyorgy Rethy => Thomas Deiß
15-08-2008 12:37Gyorgy RethyRelationship addedrelated to 0003760
15-08-2008 12:37Gyorgy RethyRelationship addedrelated to 0003761
17-08-2008 09:01Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
30-09-2008 00:43Thomas DeißFile Added: CRs3619_3760_3761_resolution_v1_1.doc
30-09-2008 00:45Thomas DeißNote Added: 0006927
30-09-2008 00:45Thomas DeißAssigned ToThomas Deiß => Gyorgy Rethy
27-11-2008 10:13Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
27-11-2008 10:13Gyorgy RethyStatusassigned => resolved
27-11-2008 10:13Gyorgy RethyResolutionopen => fixed
10-12-2008 10:52Ina SchieferdeckerStatusresolved => closed
10-12-2008 10:52Ina SchieferdeckerFixed in Version => Edition 4.1.1 (not yet published)
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0006544) +
+ Gyorgy Rethy    +
+ 15-08-2008 12:34    +
+ 		+ + + + +
+ CR 3619 (this CR), 3760 and 3761 resolution are merged in one file (this). BNF for patterns still to be added (see CR3760/3761). To be checked if all other issues are handled (due to lack of time there was no time to cross-check)
+
+
+
+ + + + + + + + + + +
+ (0006927) +
+ Thomas Deiß    +
+ 30-09-2008 00:45    +
+ 		+ + + + +
+ Some (minor) editorial corrections, comment on sentence 'In effect...' added. New version CRs3619_3760_3761_resolution_v1_1.doc uploaded.
+
+ + diff --git a/docs/mantis/CR3620.md b/docs/mantis/CR3620.md new file mode 100644 index 0000000000000000000000000000000000000000..1bf9b8521ff36eb71276e0c5146fc578ec698f9e --- /dev/null +++ b/docs/mantis/CR3620.md @@ -0,0 +1,73 @@ + + + + + + + + + + + + + 0003620: incorrect example for referenced character set - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0003620Part 01: TTCN-3 Core LanguageTechnicalpublic24-06-2008 09:4413-08-2008 16:23
ReporterThomas Deiß 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.3.2 (published 2008-04) 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)B.1.5.4
Source (company - Author)Nokia Siemens Networks - Thomas Deiss
Summary0003620: incorrect example for referenced character set
DescriptionClause 1.5.4 contains the following declarations
+    type charstring MyCharRange ("a".."z");
+    type charstring MyCharList ("a", "z");
+
+    template MyCharRange myTempPatt3 := pattern "\N { MyCharList }";
+    // myTempPatt3 and shall match strings "a" and "r" only
+    
+    template MyCharList myTempPatt4 := pattern "\N { MyCharRange }";
+    // myTempPatt4 shall match strings "a" and "r" only
+
+According to the declarations the templates should match the characters "a" and "z" instead of "a" and "r".
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR3620.doc (26,624) 18-07-2008 10:35
http://oldforge.etsi.org/mantis/file_download.php?file_id=1565&type=bug
Issue History
Date ModifiedUsernameFieldChange
24-06-2008 09:44Thomas DeißNew Issue
24-06-2008 09:44Thomas DeißStatusnew => assigned
24-06-2008 09:44Thomas DeißAssigned To => Ina Schieferdecker
24-06-2008 09:44Thomas DeißClause Reference(s) => B.1.5.4
24-06-2008 09:44Thomas DeißSource (company - Author) => Nokia Siemens Networks - Thomas Deiss
18-07-2008 10:35Ina SchieferdeckerFile Added: CR3620.doc
18-07-2008 10:36Ina SchieferdeckerAssigned ToIna Schieferdecker => Thomas Deiß
18-07-2008 10:36Ina SchieferdeckerResolutionopen => fixed
18-07-2008 10:36Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
18-07-2008 15:11Thomas DeißNote Added: 0006342
18-07-2008 15:11Thomas DeißAssigned ToThomas Deiß => Ina Schieferdecker
13-08-2008 16:23Ina SchieferdeckerStatusassigned => resolved
13-08-2008 16:23Ina SchieferdeckerFixed in Version => Edition 4.1.1 (not yet published)
13-08-2008 16:23Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0006342) +
+ Thomas Deiß    +
+ 18-07-2008 15:11    +
+ 		+ + + + +
+ ok to remove example.
+
+ + diff --git a/docs/mantis/CR3627.md b/docs/mantis/CR3627.md new file mode 100644 index 0000000000000000000000000000000000000000..68b2c6551eaec93238a7ed3468645e7a907c184d --- /dev/null +++ b/docs/mantis/CR3627.md @@ -0,0 +1,293 @@ + + + + + + + + + + + + + 0003627: Bring "inout all" back with relaxed semantics - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0003627Part 01: TTCN-3 Core LanguageNew Featurepublic24-06-2008 12:5512-12-2008 11:43
ReporterPavel Yakovenko 
Assigned ToThomas Deiß 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionwon't fix 
PlatformOSOS Version
Product Versionv3.3.2 (published 2008-04) 
Target Versionv4.1.1 (published 2009-06)Fixed in Version 
Clause Reference(s)6.2.9, F.3
Source (company - Author)Pavel Yakovenko, ISPRAS
Summary0003627: Bring "inout all" back with relaxed semantics
DescriptionPropose:
+
+1) Clear "deprecated" notice from port "inout all" statement (clause F.3).
+2) Declare that "inout all" covers any arbitrary type (clause 6.2.9).
+
+Problem description:
+
+One of the approaches to map classes (C++, UML, etc) to TTCN-3 is to put every class into separate module and represent every class instance as a separate parallel component. Public class methods are mapped to signatures. Accesses to public class data members are translated into get/set signatures. At the same time we may want to hide communication operations into proxy functions that are not tied to a component (i.e. do not have runs on clause). Proxy function must have two additional parameters: a reference to accessed component instance and a reference to a port which is used to send procedure call and receive reply.
+
+The problem is in the set of ports that calling component must have to access other components. If class ClassA invokes methods from ClassB and ClassC then corresponding component for ClassA must declare two ports – one for ClassB and one for ClassC. The more different classes are used the more different ports component must declare.
+
+This issue could be solved if “inout all” in the port type declaration would cover all possible types defined in the whole test suite (not in the current module). This would eliminate the need to have lots of ports to access class methods and would also remove the necessity to pass port instance to a proxy function.
+
+Example:
+Suppose we have ClassA, ClassB and ClassC classes and ClassA inokes methods from opther two classes.
+
+class ClassB
+{
+  public: int f() {return 1;}
+}
+
+class ClassC
+{
+  public: int g() {return 2;}
+}
+
+class ClassA
+{
+  ClassB m_B;
+  ClassC m_C;
+
+  void h()
+  {
+     int v = m_B.f() + m_C.g();
+  }
+}
+
+Currently we need to put two ports into component declaration for ClassA and pass port instance to every proxy function (look at the Part1 in the attached InOutAll.ttcn)
+
+Having “inout all” cover any arbitrary type makes TTCN-3 code more structured. We may put port declaration to access class operations into a “root” component type and declare every component as an extension of the “root” one. Proxy functions are declared as running on “root” component hence we may remove port instance from the list of formal parameters (look at the Part2 in the attached InOutAll.ttcn).
+
+
Steps To Reproduce
Additional Information1) Making "inout all" to cover arbitrary types doesn't influence type checking in any way. All invoked signatures and templates still must be visible in the module.
+
+2) Keeping current semantics of "inout all" doesn't help.
+Yes, we may declare PT port type with "inout all" in every module and use one and the same port to invoke operations on every component. But still we must pass port reference to proxy function since component ClassA.CT and ClassB.CT are not compatible and we may not declare f_proxy with "runs on".
+
TagsNo tags attached.
Relationships
Attached Files? InOutAll.ttcn (3,871) 24-06-2008 12:55
http://oldforge.etsi.org/mantis/file_download.php?file_id=1528&type=bug
doc CR_3627_TD_18_July_2008.doc (61,952) 18-07-2008 14:41
http://oldforge.etsi.org/mantis/file_download.php?file_id=1573&type=bug
zip CR_3627_Bring_inout_all_back.zip (29,018) 13-08-2008 05:36
http://oldforge.etsi.org/mantis/file_download.php?file_id=1589&type=bug
Issue History
Date ModifiedUsernameFieldChange
24-06-2008 12:55Pavel YakovenkoNew Issue
24-06-2008 12:55Pavel YakovenkoStatusnew => assigned
24-06-2008 12:55Pavel YakovenkoAssigned To => Ina Schieferdecker
24-06-2008 12:55Pavel YakovenkoFile Added: InOutAll.ttcn
24-06-2008 12:55Pavel YakovenkoClause Reference(s) => 6.2.9, F.3
24-06-2008 12:55Pavel YakovenkoSource (company - Author) => Pavel Yakovenko, ISPRAS
18-07-2008 09:20Thomas DeißNote Added: 0006320
18-07-2008 09:20Thomas DeißAssigned ToIna Schieferdecker => Thomas Deiß
18-07-2008 09:20Thomas DeißStatusassigned => feedback
18-07-2008 11:33Pavel YakovenkoNote Added: 0006336
18-07-2008 14:40Thomas DeißNote Added: 0006339
18-07-2008 14:41Thomas DeißFile Added: CR_3627_TD_18_July_2008.doc
18-07-2008 14:42Thomas DeißNote Added: 0006340
18-07-2008 14:42Thomas DeißStatusfeedback => assigned
13-08-2008 05:33Thomas DeißNote Added: 0006503
13-08-2008 05:36Thomas DeißFile Added: CR_3627_Bring_inout_all_back.zip
13-08-2008 05:38Thomas DeißNote Added: 0006504
13-08-2008 05:38Thomas DeißStatusassigned => closed
13-08-2008 05:38Thomas DeißResolutionopen => won't fix
12-12-2008 11:43Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0006320) +
+ Thomas Deiß    +
+ 18-07-2008 09:20    +
+ 		+ + + + +
+ The proposal refers to the use of proxy functions and it is stated that these are not tied to component and therefore do not have a runs on clause. No reason is given in the proposal why the runs on clause should be avoided.
+
+Assuming that the proxy functions have a runs on clause, the problem could be solved quite simply: Assume there is a class A, providing a set of methods. A port type Port_A can be defined to call these methods and a corresponding component CT_A type with such a port pt_A can be defined too. The proxy function would then have clause 'runs on CT_A' allowing to access the port pt_A without having to pass it as parameter. The actual test component types used in behaviour functions would then be defined as extensions of CT_A and of other component types CT_B, CT_C, etc if methods of other classes would have to be invoked, too. Using this approach there would be no need to reintroduce 'inout all'.
+
+For further processing of the CR an explanation we need an explanation why the runs on clause has to be avoided.
+
+
+
+ + + + + + + + + + +
+ (0006336) +
+ Pavel Yakovenko    +
+ 18-07-2008 11:33    +
+ 		+ + + + +
+ Yes, that's what I propose but "runs on ROOT" instead of "runs on CT_A" (see example 2 in the InOutAll.ttcn).
+
+If we add "runs on CT_A" to a proxy function of class A then we must add CT_A component to the extension list of every component that calls any operation from class A. This is very inconvenient from my point of view especially when writing code manually. Imagine extensions lists with tens of elements in it.
+
+And it doesn't differ much from adding pt_A port to the body of the calling component. In fact what extension mechanism does for us in this case is that it hides from the user addition of pt_A to the body of calling component. But actually it does more job - it adds all the component elements from parent component to the extended one. As a result extended component contains lots of members that are never used (except communication port) but we need to pay attention to possible name clashes. That is we need to make ports, port types, and other component elements (like "this" varaible storing class members) globally unique. For example we must declare this_A in class A instead of simply "this" and this_B for class B, because if class C calls both A and B it must extend component CT_C with CT_A and CT_B and having two "this" members (from A and B) will result in compile error.
+
+Now imagine if we have ROOT component with "inout all" port. It has only one component member (instance of that dispatching port), all components extend ROOT component and may use that port to communicate between each other as long as "inout all" covers transmited signature. We do not need to put every communicated component into the extension list, we do not need to care about name clashes since they may not occur.
+
+
+
+ + + + + + + + + + +
+ (0006339) +
+ Thomas Deiß    +
+ 18-07-2008 14:40    +
+ 		+ + + + +
+ Ok, argument understood.
+
+One might have to use a more sophisticated mapping, actually one separating between the interface of a class from the implementation of a class, see the attached file CR_3627_TD_18_July_2008.doc. This should help to limit the amount of elements in the component types. And this should also help to avoid the name clashes among the 'this' component variables. Still, the extends clauses would be longer, agreed.
+
+
+
+ + + + + + + + + + +
+ (0006340) +
+ Thomas Deiß    +
+ 18-07-2008 14:42    +
+ 		+ + + + +
+ explanation from Pavel received. Discussion within STF can continue.
+
+
+
+ + + + + + + + + + +
+ (0006503) +
+ Thomas Deiß    +
+ 13-08-2008 05:33    +
+ 		+ + + + +
+ email from Pavel, August 12th, 2008:
+...
+Your suggestion to split interface and realization works well. I think increasing number of ports is an acceptable tradeoff over changing language semantics in this case. So let's close the case.
+...
+
+
+
+ + + + + + + + + + +
+ (0006504) +
+ Thomas Deiß    +
+ 13-08-2008 05:38    +
+ 		+ + + + +
+ Alternative mapping of classes to component types solves the original problem without reintroducing 'inout all'. Therefore the CR can be closed as won't fix. The attached zip file contains a more detailed explanation of the alternative mapping and some example.
+
+ + diff --git a/docs/mantis/CR3757.md b/docs/mantis/CR3757.md new file mode 100644 index 0000000000000000000000000000000000000000..b95ff6f8a1b8170ddcbc221c7acbf4f0b17cfd56 --- /dev/null +++ b/docs/mantis/CR3757.md @@ -0,0 +1,135 @@ + + + + + + + + + + + + + 0003757: XSD date/time patterns - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0003757Part 09: Using XML with TTCN-3Technicalpublic14-07-2008 12:5930-10-2008 15:35
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)$6.5, Annex A
For STF discussion
Source (company - Author)L.M. Ericsson
Summary0003757: XSD date/time patterns
DescriptionIn the current version patterns for the date and time types of XSD are missing or incomplete.
Steps To Reproduce
Additional InformationProposed solution is contained in the attached file. The patterns are tested, the test suite will also be provided to the TTCN-3 test library
TagsNo tags attached.
Relationships
related to 0003769closed Gyorgy Rethy Test suite to check XSD date/time patterns 
Attached Filesdoc XSD_dateTime_patterns.doc (161,792) 14-07-2008 12:59
http://oldforge.etsi.org/mantis/file_download.php?file_id=1543&type=bug
doc XSD_dateTime_patterns_v2.doc (163,840) 18-07-2008 14:22
http://oldforge.etsi.org/mantis/file_download.php?file_id=1571&type=bug
doc XSD_dateTime_patterns_v2_IS.doc (172,032) 16-10-2008 09:29
http://oldforge.etsi.org/mantis/file_download.php?file_id=1702&type=bug
Issue History
Date ModifiedUsernameFieldChange
14-07-2008 12:59Gyorgy RethyNew Issue
14-07-2008 12:59Gyorgy RethyStatusnew => assigned
14-07-2008 12:59Gyorgy RethyAssigned To => Gyorgy Rethy
14-07-2008 12:59Gyorgy RethyFile Added: XSD_dateTime_patterns.doc
14-07-2008 12:59Gyorgy RethyClause Reference(s) => $6.5, Annex A
14-07-2008 12:59Gyorgy RethySource (company - Author) => L.M. Ericsson
14-07-2008 15:00Ina SchieferdeckerAssigned ToGyorgy Rethy => Ina Schieferdecker
18-07-2008 14:22Gyorgy RethyFile Added: XSD_dateTime_patterns_v2.doc
18-07-2008 14:25Gyorgy RethyNote Added: 0006338
18-07-2008 14:27Gyorgy RethyNote Edited: 0006338
17-08-2008 09:13Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
16-10-2008 08:57Ina SchieferdeckerRelationship addedrelated to 0003769
16-10-2008 09:27Ina SchieferdeckerNote Added: 0007087
16-10-2008 09:29Ina SchieferdeckerFile Added: XSD_dateTime_patterns_v2_IS.doc
16-10-2008 09:29Ina SchieferdeckerAssigned ToIna Schieferdecker => Gyorgy Rethy
16-10-2008 09:29Ina SchieferdeckerResolutionopen => fixed
30-10-2008 15:29Gyorgy RethyStatusassigned => closed
30-10-2008 15:29Gyorgy RethyNote Added: 0007226
30-10-2008 15:29Gyorgy RethyFixed in Version => Edition 4.1.1 (not yet published)
30-10-2008 15:33Gyorgy RethyStatusclosed => feedback
30-10-2008 15:33Gyorgy RethyResolutionfixed => reopened
30-10-2008 15:35Gyorgy RethyNote Edited: 0007226
30-10-2008 15:35Gyorgy RethyStatusfeedback => closed
30-10-2008 15:35Gyorgy RethyResolutionreopened => fixed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0006338) +
+ Gyorgy Rethy    +
+ 18-07-2008 14:25    +
(edited on: 18-07-2008 14:27)
+ 		+ + + + +
+ XSD_dateTime_patterns_v2.doc contains patterns corrected after checking the first version. See also case 3769 for a test suite to check the patterns.
+
+
+
+
+
+ + + + + + + + + + +
+ (0007087) +
+ Ina Schieferdecker    +
+ 16-10-2008 09:27    +
+ 		+ + + + +
+ Just editorial corrections.
+
+
+
+ + + + + + + + + + +
+ (0007226) +
+ Gyorgy Rethy    +
+ 30-10-2008 15:29    +
(edited on: 30-10-2008 15:35)
+ 		+ + + + +
+ Done in master copy, incl. editorial changes from Ina. Also, note 2 is not added to the annex and patterns longer than a line are cut to pieces and concatenated as proposed.
+
+
+
+ + diff --git a/docs/mantis/CR3758.md b/docs/mantis/CR3758.md new file mode 100644 index 0000000000000000000000000000000000000000..a859df7cea0898e52bca383eb0f486214a3f317a --- /dev/null +++ b/docs/mantis/CR3758.md @@ -0,0 +1,258 @@ + + + + + + + + + + + + + 0003758: unclear operand limitations in write access to strings - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0003758Part 01: TTCN-3 Core LanguageClarificationpublic14-07-2008 13:2710-12-2008 12:31
ReporterThomas Deiß 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.3.2 (published 2008-04) 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)6.1.1.1
Source (company - Author) Nokia Siemens Networks, Thomas Deiß
Summary0003758: unclear operand limitations in write access to strings
DescriptionIn the following examples the standard leaves it open whether the assignments are allowed and if so what would be the meaning.
+MyBitStringA := '010'B;
+MyBitStringA[1] := '11'B;
+
+MyBitStringB := '1'B;
+MyBitStringB[4] := '1'B;
+
+MyBitStringC := ''B;
+MyBitStringC[0] := '1'B;
+
+Proposed resolution, all three cases should be disallowed. The index shall be limited to greater or equal than 0 and smaller than the length of the string on the lhs. The element to be assigned has to be a string of length exactly 1 and it has to be of the same kind as the string on the lhs.
+
+This applies to bitstring, hexstring, octetstring, charstring, and universal charstring. It does NOT apply to record of, set of, and array.
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR3758 - accessing individual string elements.doc (148,992) 28-11-2008 09:33
http://oldforge.etsi.org/mantis/file_download.php?file_id=1832&type=bug
doc CR3758 - accessing individual string elements_02.doc (144,896) 28-11-2008 12:17
http://oldforge.etsi.org/mantis/file_download.php?file_id=1835&type=bug
doc CR3758_-_accessing_individual_string_elements_03.doc (149,504) 09-12-2008 14:25
http://oldforge.etsi.org/mantis/file_download.php?file_id=1872&type=bug
doc CR3758_-_accessing_individual_string_elements_04.doc (145,920) 09-12-2008 15:10
http://oldforge.etsi.org/mantis/file_download.php?file_id=1876&type=bug
doc CR3758_-_accessing_individual_string_elements_05.doc (151,552) 10-12-2008 12:19
http://oldforge.etsi.org/mantis/file_download.php?file_id=1880&type=bug
Issue History
Date ModifiedUsernameFieldChange
14-07-2008 13:27Thomas DeißNew Issue
14-07-2008 13:27Thomas DeißStatusnew => assigned
14-07-2008 13:27Thomas DeißAssigned To => Ina Schieferdecker
14-07-2008 13:27Thomas DeißClause Reference(s) => 6.1.1.1
14-07-2008 13:27Thomas DeißSource (company - Author) => Nokia Siemens Networks, Thomas Deiß
14-07-2008 14:58Ina SchieferdeckerAssigned ToIna Schieferdecker => Gyorgy Rethy
17-08-2008 09:17Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
28-11-2008 09:08Gyorgy RethyNote Added: 0007494
28-11-2008 09:33Gyorgy RethyFile Added: CR3758 - accessing individual string elements.doc
28-11-2008 09:34Gyorgy RethyAssigned ToGyorgy Rethy => Thomas Deiß
28-11-2008 12:17Thomas DeißFile Added: CR3758 - accessing individual string elements_02.doc
28-11-2008 12:18Thomas DeißNote Added: 0007499
28-11-2008 12:19Thomas DeißAssigned ToThomas Deiß => Ina Schieferdecker
28-11-2008 12:19Thomas DeißResolutionopen => fixed
09-12-2008 14:25Ina SchieferdeckerFile Added: CR3758_-_accessing_individual_string_elements_03.doc
09-12-2008 14:26Ina SchieferdeckerNote Added: 0007599
09-12-2008 14:26Ina SchieferdeckerAssigned ToIna Schieferdecker => Thomas Deiß
09-12-2008 15:10Thomas DeißFile Added: CR3758_-_accessing_individual_string_elements_04.doc
09-12-2008 15:11Thomas DeißNote Added: 0007602
09-12-2008 15:11Thomas DeißAssigned ToThomas Deiß => Ina Schieferdecker
10-12-2008 12:19Ina SchieferdeckerFile Added: CR3758_-_accessing_individual_string_elements_05.doc
10-12-2008 12:19Ina SchieferdeckerNote Added: 0007626
10-12-2008 12:20Ina SchieferdeckerAssigned ToIna Schieferdecker => Thomas Deiß
10-12-2008 12:26Thomas DeißNote Added: 0007627
10-12-2008 12:26Thomas DeißAssigned ToThomas Deiß => Ina Schieferdecker
10-12-2008 12:31Ina SchieferdeckerStatusassigned => resolved
10-12-2008 12:31Ina SchieferdeckerFixed in Version => Edition 4.1.1 (not yet published)
10-12-2008 12:31Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0007494) +
+ Gyorgy Rethy    +
+ 28-11-2008 09:08    +
+ 		+ + + + +
+ MyBitStringA[1] := '11'B
+is clearly an error, the standard says in $6.1.1.1:"Individual elements in a string type may be accessed using an array-like syntax. Only single elements of the string may be accessed."
+I think no further clarification is needed.
+
+MyBitStringB[4] := '1'B;
+should be an error as the result would be an uninitialized value.
+
+MyBitStringC[0] := '1'B;
+should be allowed as te result is a fully initialized value;
+
+
+
+ + + + + + + + + + +
+ (0007499) +
+ Thomas Deiß    +
+ 28-11-2008 12:18    +
+ 		+ + + + +
+ explanation in one of the examples completed. Otherwise ok.
+
+
+
+ + + + + + + + + + +
+ (0007599) +
+ Ina Schieferdecker    +
+ 09-12-2008 14:26    +
+ 		+ + + + +
+ It should be length minus one. Otherwise ok.
+
+
+
+ + + + + + + + + + +
+ (0007602) +
+ Thomas Deiß    +
+ 09-12-2008 15:11    +
+ 		+ + + + +
+ It's even more complicated. The index is bound by length - 1 when retrieving an element from a string. And the index is bound by length when assigning an element to a string.
+
+Proposal updated and uploaded as v04.
+
+
+
+
+ + + + + + + + + + +
+ (0007626) +
+ Ina Schieferdecker    +
+ 10-12-2008 12:19    +
+ 		+ + + + +
+ Reworded and example added. Please check.
+
+
+
+ + + + + + + + + + +
+ (0007627) +
+ Thomas Deiß    +
+ 10-12-2008 12:26    +
+ 		+ + + + +
+ ok.
+
+
+ + diff --git a/docs/mantis/CR3759.md b/docs/mantis/CR3759.md new file mode 100644 index 0000000000000000000000000000000000000000..ca32955492d8c172f43b18bc0819db0d95df3778 --- /dev/null +++ b/docs/mantis/CR3759.md @@ -0,0 +1,76 @@ + + + + + + + + + + + + + 0003759: to strict limitation on AnyValueOrNone - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0003759Part 01: TTCN-3 Core LanguageClarificationpublic14-07-2008 13:3412-12-2008 11:43
ReporterThomas Deiß 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionwon't fix 
PlatformOSOS Version
Product Versionv3.3.2 (published 2008-04) 
Target Versionv4.1.1 (published 2009-06)Fixed in Version 
Clause Reference(s)Table 9, clause 15.7
Source (company - Author)Nokia Siemens Networks, Thomas Deiß
Summary0003759: to strict limitation on AnyValueOrNone
DescriptionConsider the following example:
+template integer ta := *
+template integer tb := ? if present
+
+var integer x := 7
+log(match(x, ta))
+log(match(x, tb))
+In Table 9 are two notes: MatchAnyValueOrNone? NOTE: When used, shall be applied to optional fields of record and set types only (without restriction on the type of that field). if present NOTE: When used, shall be applied to record and set fields only (without restriction on the type of that field).
+
+According to this note, the match operations would not be correct, although there is no point to forbid the usage of AnyValueOrNone as in the example above.
+
+Proposed solution: relax the restriction: When used within a template of a structured type, shall be applied to record and set fields only (without restriction on the type of that field).
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
14-07-2008 13:34Thomas DeißNew Issue
14-07-2008 13:34Thomas DeißStatusnew => assigned
14-07-2008 13:34Thomas DeißAssigned To => Ina Schieferdecker
14-07-2008 13:34Thomas DeißClause Reference(s) => Table 9, clause 15.7
14-07-2008 13:34Thomas DeißSource (company - Author) => Nokia Siemens Networks, Thomas Deiß
14-07-2008 14:47Ina SchieferdeckerAssigned ToIna Schieferdecker => Jens Grabowski
17-07-2008 09:43Jens GrabowskiNote Added: 0006300
17-07-2008 11:35Thomas DeißStatusassigned => closed
17-07-2008 11:35Thomas DeißResolutionopen => won't fix
12-12-2008 11:43Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0006300) +
+ Jens Grabowski    +
+ 17-07-2008 09:43    +
+ 		+ + + + +
+ Notes should not be changed to keep consistency with rules for mandatory fields even though the examples in the description would work with the relaxed notes.
+
+CR to be set to "won't fix"
+
+ + diff --git a/docs/mantis/CR3760.md b/docs/mantis/CR3760.md new file mode 100644 index 0000000000000000000000000000000000000000..544caaa229e69e13cc227f0c3a8217f0374c9b49 --- /dev/null +++ b/docs/mantis/CR3760.md @@ -0,0 +1,103 @@ + + + + + + + + + + + + + 0003760: correct usage of metacharacters - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0003760Part 01: TTCN-3 Core LanguageClarificationpublic14-07-2008 13:4506-10-2008 06:17
ReporterThomas Deiß 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.3.2 (published 2008-04) 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)B.1.5
Source (company - Author)Nokia Siemens Networks, Thomas Deiß
Summary0003760: correct usage of metacharacters
DescriptionSome metacharacters to be used within patterns consist of two characters, e.g. the metacharacter for reference expressions consists of a pair of curly brackets. Is it correct syntax if a pattern contains only one of these brackets, e.g. as in the example from clause B.1.5.2:
+template charstring RegExp4 := pattern "{Reg";
+
+Proposed resolution: Add a requirement that metacharacters within a pattern shall be complete. Following this resolution, the previously mentioned example can be removed and there is no longer the need to explain that patterns are to be evaluated only once. Note that this is a backwards incompatible change. The example mentioned before was correct code, now it would be considered incorrect TTCN-3.
+
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0003761closed Gyorgy Rethy Pattern concatenation 
related to 0003619closed Ina Schieferdecker whitespace in pattern metacharacters 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
14-07-2008 13:45Thomas DeißNew Issue
14-07-2008 13:45Thomas DeißStatusnew => assigned
14-07-2008 13:45Thomas DeißAssigned To => Ina Schieferdecker
14-07-2008 13:45Thomas DeißClause Reference(s) => B.1.5
14-07-2008 13:45Thomas DeißSource (company - Author) => Nokia Siemens Networks, Thomas Deiß
18-07-2008 10:33Ina SchieferdeckerNote Added: 0006332
18-07-2008 10:33Ina SchieferdeckerAssigned ToIna Schieferdecker => Thomas Deiß
18-07-2008 10:33Ina SchieferdeckerResolutionopen => fixed
15-08-2008 12:37Gyorgy RethyRelationship addedrelated to 0003619
17-08-2008 09:16Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
30-09-2008 00:47Thomas DeißNote Added: 0006928
30-09-2008 00:47Thomas DeißAssigned ToThomas Deiß => Ina Schieferdecker
06-10-2008 05:52Ina SchieferdeckerRelationship addedrelated to 0003761
06-10-2008 06:17Ina SchieferdeckerStatusassigned => closed
06-10-2008 06:17Ina SchieferdeckerFixed in Version => Edition 4.1.1 (not yet published)
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0006332) +
+ Ina Schieferdecker    +
+ 18-07-2008 10:33    +
+ 		+ + + + +
+ See attachment for CR3761
+
+
+
+ + + + + + + + + + +
+ (0006928) +
+ Thomas Deiß    +
+ 30-09-2008 00:47    +
+ 		+ + + + +
+ see CR 3761, issue in BNF found. \N{...} did not allow to refer to type.
+
+
+ + diff --git a/docs/mantis/CR3761.md b/docs/mantis/CR3761.md new file mode 100644 index 0000000000000000000000000000000000000000..078eb136fc88c5aef2d861818b59208d70aa08f0 --- /dev/null +++ b/docs/mantis/CR3761.md @@ -0,0 +1,102 @@ + + + + + + + + + + + + + 0003761: Pattern concatenation - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0003761Part 01: TTCN-3 Core LanguageNew Featurepublic14-07-2008 16:3806-10-2008 06:17
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv3.4.1 (published 2008-09) 
Clause Reference(s)B.1.5
Source (company - Author)     
Summary0003761: Pattern concatenation
DescriptionCurrently only pattern "<single pattern here>"; is allowed for charstring templates or template fields. This results that the complete pattern shall be in a single line, no line breaks and/or concatenation are allowed. This makes difficult to work with long patterns. It would increase code development efficiency if the pattern could be broken into lines. Syntactically it could be solved by different ways:
+- pattern "[a-z]#(,1){myReference}";//this is the currently allowed syntax
+- pattern ("[a-z]#","(,1){myReference}")//argument-list syntax
+- pattern "[a-z]#(,1)"&"{myReference}";//simple concatenation syntax
+- pattern ("[a-z]#(,1)"&"{myReference}");//argument-like concatenation syntax
+There is no strong preference regarding the syntax but the last two options are the most aligned with the existing string concatenation syntax.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0003619closed Ina Schieferdecker whitespace in pattern metacharacters 
related to 0003760closed Ina Schieferdecker correct usage of metacharacters 
Attached Filesdoc CR3760_CR3761_Grammar.doc (40,448) 18-07-2008 10:32
http://oldforge.etsi.org/mantis/file_download.php?file_id=1563&type=bug
doc CR3760_CR3761_Grammar_02.doc (40,448) 30-09-2008 00:13
http://oldforge.etsi.org/mantis/file_download.php?file_id=1663&type=bug
doc CR3760_CR3761_Grammar_03.doc (40,448) 30-09-2008 00:42
http://oldforge.etsi.org/mantis/file_download.php?file_id=1664&type=bug
Issue History
Date ModifiedUsernameFieldChange
14-07-2008 16:38Gyorgy RethyNew Issue
14-07-2008 16:38Gyorgy RethyStatusnew => assigned
14-07-2008 16:38Gyorgy RethyAssigned To => Ina Schieferdecker
14-07-2008 16:38Gyorgy RethyClause Reference(s) => B.1.5
14-07-2008 16:38Gyorgy RethySource (company - Author) =>
18-07-2008 10:32Ina SchieferdeckerFile Added: CR3760_CR3761_Grammar.doc
18-07-2008 10:32Ina SchieferdeckerAssigned ToIna Schieferdecker => Gyorgy Rethy
18-07-2008 10:32Ina SchieferdeckerResolutionopen => fixed
18-07-2008 10:32Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
15-08-2008 12:37Gyorgy RethyRelationship addedrelated to 0003619
30-09-2008 00:13Thomas DeißFile Added: CR3760_CR3761_Grammar_02.doc
30-09-2008 00:14Thomas DeißNote Added: 0006924
30-09-2008 00:42Thomas DeißFile Added: CR3760_CR3761_Grammar_03.doc
30-09-2008 00:43Thomas DeißNote Added: 0006926
06-10-2008 05:52Ina SchieferdeckerRelationship addedrelated to 0003760
06-10-2008 06:17Ina SchieferdeckerStatusassigned => closed
06-10-2008 06:17Ina SchieferdeckerFixed in Version => Edition 3.4.1 (not yet published)
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0006924) +
+ Thomas Deiß    +
+ 30-09-2008 00:14    +
+ 		+ + + + +
+ Two editorial corrections in BNF for patterns.
+
+
+
+ + + + + + + + + + +
+ (0006926) +
+ Thomas Deiß    +
+ 30-09-2008 00:43    +
+ 		+ + + + +
+ In BNF, \N{...} did not allow to refer to Type. New corrected version: CR3760_CR3761_Grammar_03.doc
+
+ + diff --git a/docs/mantis/CR3769.md b/docs/mantis/CR3769.md new file mode 100644 index 0000000000000000000000000000000000000000..6fd4adc888138fa221c17cef6e18adb895560cca --- /dev/null +++ b/docs/mantis/CR3769.md @@ -0,0 +1,199 @@ + + + + + + + + + + + + + 0003769: Test suite to check XSD date/time patterns - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0003769Part 09: Using XML with TTCN-3Clarificationpublic15-07-2008 16:2320-04-2009 09:37
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.1.1 (published 2009-06)Fixed in Version 
Clause Reference(s)
For STF discussion
Source (company - Author)
Summary0003769: Test suite to check XSD date/time patterns
DescriptionThe atached .zip file contains the TTCN-3 test cases to check the date/time patterns used in Part-9.
Steps To Reproduce
Additional InformationAs for the date of providing this CR, all test cases are executed and passed with Ericsson's Titan tool.
TagsNo tags attached.
Relationships
related to 0003757closed Gyorgy Rethy XSD date/time patterns 
Attached Fileszip XSD_DateTime_Patterns.zip (14,179) 18-07-2008 14:37
http://oldforge.etsi.org/mantis/file_download.php?file_id=1572&type=bug
zip XSD DateTime.zip (2,614) 13-08-2008 16:01
http://oldforge.etsi.org/mantis/file_download.php?file_id=1593&type=bug
txt Review_XSDDateTimeDefinitions.txt (375) 16-10-2008 08:46
http://oldforge.etsi.org/mantis/file_download.php?file_id=1699&type=bug
txt Corrections_XSD_DateTimePatterns_new_161008.txt (702) 16-10-2008 08:46
http://oldforge.etsi.org/mantis/file_download.php?file_id=1700&type=bug
zip XSD DateTime IS.zip (12,895) 16-10-2008 08:46
http://oldforge.etsi.org/mantis/file_download.php?file_id=1701&type=bug
Issue History
Date ModifiedUsernameFieldChange
15-07-2008 16:23Gyorgy RethyNew Issue
15-07-2008 16:23Gyorgy RethyFile Added: XSD_DateTime_Patterns_v1.zip
18-07-2008 13:00Gyorgy RethyFile Deleted: XSD_DateTime_Patterns_v1.zip
18-07-2008 14:37Gyorgy RethyFile Added: XSD_DateTime_Patterns.zip
11-08-2008 08:42Ina SchieferdeckerStatusnew => assigned
11-08-2008 08:42Ina SchieferdeckerAssigned To => Ina Schieferdecker
13-08-2008 16:01Ina SchieferdeckerNote Added: 0006515
13-08-2008 16:01Ina SchieferdeckerFile Added: XSD DateTime.zip
17-08-2008 09:10Ina SchieferdeckerProject@59@ => Part 09: Using XML with TTCN-3
17-08-2008 09:11Ina SchieferdeckerCategoryXSD mapping => Clarification
17-08-2008 09:11Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
17-08-2008 09:13Ina SchieferdeckerNote Added: 0006545
16-10-2008 08:44Ina SchieferdeckerNote Added: 0007086
16-10-2008 08:46Ina SchieferdeckerFile Added: Review_XSDDateTimeDefinitions.txt
16-10-2008 08:46Ina SchieferdeckerFile Added: Corrections_XSD_DateTimePatterns_new_161008.txt
16-10-2008 08:46Ina SchieferdeckerFile Added: XSD DateTime IS.zip
16-10-2008 08:47Ina SchieferdeckerAssigned ToIna Schieferdecker => Gyorgy Rethy
16-10-2008 08:47Ina SchieferdeckerResolutionopen => fixed
16-10-2008 08:57Ina SchieferdeckerRelationship addedrelated to 0003757
20-04-2009 09:31Gyorgy RethyNote Added: 0008509
20-04-2009 09:37Gyorgy RethyStatusassigned => closed
20-04-2009 09:37Gyorgy RethyNote Added: 0008510
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0006515) +
+ Ina Schieferdecker    +
+ 13-08-2008 16:01    +
+ 		+ + + + +
+ XSDDateTimeTypes.ttcn3 and XSDDateTimePatterns.ttcn3 have been corrected - those should become part of part 9, but not the examples or tests.
+
+
+
+ + + + + + + + + + +
+ (0006545) +
+ Ina Schieferdecker    +
+ 17-08-2008 09:13    +
+ 		+ + + + +
+ belongs to CR3757
+
+
+
+ + + + + + + + + + +
+ (0007086) +
+ Ina Schieferdecker    +
+ 16-10-2008 08:44    +
+ 		+ + + + +
+ Still some issues found - see attachment. Revision checked with TTworkbench (non-standard use of \t and \n however not corrected).
+
+
+
+ + + + + + + + + + +
+ (0008509) +
+ Gyorgy Rethy    +
+ 20-04-2009 09:31    +
+ 		+ + + + +
+ date/time paterns are added to part-9 v.4.1.1
+
+
+
+ + + + + + + + + + +
+ (0008510) +
+ Gyorgy Rethy    +
+ 20-04-2009 09:37    +
+ 		+ + + + +
+ Applied in Part-9 v4.1.1
+
+ + diff --git a/docs/mantis/CR3770.md b/docs/mantis/CR3770.md new file mode 100644 index 0000000000000000000000000000000000000000..678405bf40c214d28cff0ece383d72f1ebc6550d --- /dev/null +++ b/docs/mantis/CR3770.md @@ -0,0 +1,121 @@ + + + + + + + + + + + + + 0003770: Editorials in v3.3.1 - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0003770Part 09: Using XML with TTCN-3Editorialpublic15-07-2008 18:1018-07-2008 09:55
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.1.1 (published 2009-06)Fixed in Version 
Clause Reference(s)See description
For STF discussion
Source (company - Author)     
Summary0003770: Editorials in v3.3.1
DescriptionThe following editorial errors has been found in version 3.3.1 (es_20187309v030301p.doc):
+
+5.2.2 Identifier name conversion rules, example 2
+
+type enumerated State { off, off_1 }
+with { variant "name as uncapitalized";
+  variant "text 'off' as capitalized";
+  variant "text 'off_1' as 'off'"
+}
+
+
+6 Built-in data types, example
+type XSD.Integer E1
+with { variant "name 'as uncapitalized "};
+(superflouos simple quote)
+
+
+6.4.2 float
+type IEEE754float _ Float
+(superflouos underscore)
+
+6.2.8 IDREF
+type XSD.NcName IDREF with
+(Correct name is NCName)
+
+7.3 Element component
+template t_E16a:= {...}
+(type is missing, change to:
+template E16a t_E16a:=...)
+
+7.5.3 Derivation by union
+
+type record E21 e21a
+(e21a is superflouos)
+
+template t_E21a:={
+(type is missing, change to template E21a t_E21a)
+
+7.6.5.5, 7.6.6.1, 7.6.6.5, examples
+(correct intendation and delete extra empty lines)
+
+7.7 Any and anyAttribute, example
+type record E45b
+{
+  record of XSD.String attr
+} with
+{
+  variant "name as uncapitalized";
+  variant "anyAttributes 'attr from 'http://www.organization.org/ttcn/wildcard'"; [^]
+};
+(missing simple quote)
+
+6.2.13 Language
+Current pattern is:
+pattern "[a-zA-Z]#(1,8)(-[\w]#(1,8))#(0,)"
+
+Correct it to:
+pattern "[a-zA-Z]#(1,8)(-\w#(1,8))#(0,)"
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesppt CR3770_analysis_2008-07.ppt (53,248) 18-07-2008 09:54
http://oldforge.etsi.org/mantis/file_download.php?file_id=1562&type=bug
Issue History
Date ModifiedUsernameFieldChange
15-07-2008 18:10Gyorgy RethyNew Issue
15-07-2008 18:10Gyorgy RethyStatusnew => assigned
15-07-2008 18:10Gyorgy RethyAssigned To => Gyorgy Rethy
15-07-2008 18:10Gyorgy RethyClause Reference(s) => See description
15-07-2008 18:10Gyorgy RethySource (company - Author) =>
17-07-2008 13:46Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
18-07-2008 09:54Gyorgy RethyFile Added: CR3770_analysis_2008-07.ppt
18-07-2008 09:55Gyorgy RethyNote Added: 0006329
18-07-2008 09:55Gyorgy RethyStatusassigned => closed
18-07-2008 09:55Gyorgy RethyResolutionopen => fixed
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0006329) +
+ Gyorgy Rethy    +
+ 18-07-2008 09:55    +
+ 		+ + + + +
+ All comments are resolved acc. to CR.
+
+ + diff --git a/docs/mantis/CR3783.md b/docs/mantis/CR3783.md new file mode 100644 index 0000000000000000000000000000000000000000..bc690e231fcfb81252633db3acb7d95cc52be03d --- /dev/null +++ b/docs/mantis/CR3783.md @@ -0,0 +1,306 @@ + + + + + + + + + + + + + 0003783: Recursive references of record and set types shall be optional - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0003783Part 01: TTCN-3 Core LanguageTechnicalpublic17-07-2008 10:4309-07-2009 10:43
ReporterGyorgy Rethy 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.2.1 (published 2010-07)Fixed in Versionv4.2.1 (published 2010-07) 
Clause Reference(s)6.2.1.2, 6.2.2.2
Source (company - Author)     
Summary0003783: Recursive references of record and set types shall be optional
DescriptionRecursive references are not specified. such fields shall be optional for records and sets, otherwise no legal value can be written for the type.
+
Steps To Reproduce
Additional InformationProposed:
+Add a sentence to 6.2.1.2 and 6.2.2.2:
+Fields containing recursive reference, i.e. referencing to its type, shall be optional.
+EXAMPLE 2:<for the record clause only>
+    type record MyType
+    {
+        FieldType1 field1,
+        MyType field2 optional,
+         :
+        FieldTypeN fieldN
+    }
TagsNo tags attached.
Relationships
Attached Filesdoc CR-3783-Recursive-references-Resolution-V1.doc (150,528) 16-12-2008 12:53
http://oldforge.etsi.org/mantis/file_download.php?file_id=1901&type=bug
doc CR3783_RecursiveReference_RecordSet_v2.doc (143,360) 08-07-2009 10:45
http://oldforge.etsi.org/mantis/file_download.php?file_id=2183&type=bug
doc CR3783_RecursiveReference_RecordSet_v3.doc (144,384) 08-07-2009 11:12
http://oldforge.etsi.org/mantis/file_download.php?file_id=2186&type=bug
doc CR3783_RecursiveReference_RecordSet_v4.doc (146,944) 09-07-2009 10:37
http://oldforge.etsi.org/mantis/file_download.php?file_id=2199&type=bug
Issue History
Date ModifiedUsernameFieldChange
17-07-2008 10:43Gyorgy RethyNew Issue
17-07-2008 10:43Gyorgy RethyStatusnew => assigned
17-07-2008 10:43Gyorgy RethyAssigned To => Ina Schieferdecker
17-07-2008 10:43Gyorgy RethyClause Reference(s) => 6.2.1.2, 6.2.2.2
17-07-2008 10:43Gyorgy RethySource (company - Author) =>
18-07-2008 11:22Ina SchieferdeckerAssigned ToIna Schieferdecker => Jens Grabowski
17-08-2008 09:14Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
27-11-2008 12:45Thomas DeißNote Added: 0007469
16-12-2008 12:53Jens GrabowskiFile Added: CR-3783-Recursive-references-Resolution-V1.doc
16-12-2008 12:54Jens GrabowskiAssigned ToJens Grabowski => Thomas Deiß
16-12-2008 12:54Jens GrabowskiStatusassigned => resolved
16-12-2008 14:09Thomas DeißNote Added: 0007717
16-12-2008 14:09Thomas DeißAssigned ToThomas Deiß => Jens Grabowski
16-12-2008 14:09Thomas DeißStatusresolved => assigned
17-12-2008 09:35Ina SchieferdeckerNote Added: 0007728
17-12-2008 09:35Ina SchieferdeckerTarget VersionEdition 4.1.1 (not yet published) => Edition 4.2.1 (not yet published)
20-04-2009 12:01Ina SchieferdeckerAssigned ToJens Grabowski => Tibor Csöndes
08-07-2009 10:45Tibor CsöndesFile Added: CR3783_RecursiveReference_RecordSet_v2.doc
08-07-2009 10:51Tibor CsöndesNote Added: 0008863
08-07-2009 10:51Tibor CsöndesAssigned ToTibor Csöndes => Gyorgy Rethy
08-07-2009 11:12Gyorgy RethyFile Added: CR3783_RecursiveReference_RecordSet_v3.doc
08-07-2009 11:13Gyorgy RethyNote Added: 0008865
08-07-2009 11:13Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
08-07-2009 11:38Tibor CsöndesNote Added: 0008866
09-07-2009 10:36Ina SchieferdeckerNote Added: 0008880
09-07-2009 10:37Ina SchieferdeckerFile Added: CR3783_RecursiveReference_RecordSet_v4.doc
09-07-2009 10:43Ina SchieferdeckerResolutionopen => fixed
09-07-2009 10:43Ina SchieferdeckerStatusassigned => resolved
09-07-2009 10:43Ina SchieferdeckerFixed in Version => Edition 4.2.1 (not yet published)
09-07-2009 10:43Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0007469) +
+ Thomas Deiß    +
+ 27-11-2008 12:45    +
+ 		+ + + + +
+ The recursion might involve several definitions, in this case it remains open which field should be optional.
+
+Also, there is the possibility to break the recursion by using a union type.
+Also, for a recursive record of type the recursion could stop with an empty record.
+
+It will become difficult to guarantee that the recursion can be broken via syntactical constraints.
+
+
+
+ + + + + + + + + + +
+ (0007717) +
+ Thomas Deiß    +
+ 16-12-2008 14:09    +
+ 		+ + + + +
+ The text as such is ok for record and set.
+
+For unions it should be stated that there has to be an alternative with a different type.
+The unions U1 and U2 should not be allowed
+type union U1 {U1 u1}
+type union U2 {U2 v1, U2 v2}
+
+Nevertheless, for me it is still open whether we should have such a requirement at all. There are quite a number of recursive type definitions that do not have the restrictions stated, but still allow finite values. And therefore would be valid type definitions. Is it really worth to exclude a few cases that do not allow finite values?
+
+
+
+ + + + + + + + + + +
+ (0007728) +
+ Ina Schieferdecker    +
+ 17-12-2008 09:35    +
+ 		+ + + + +
+ This CR requires more discussion and hence moved to v4.2.1
+
+
+
+ + + + + + + + + + +
+ (0008863) +
+ Tibor Csöndes    +
+ 08-07-2009 10:51    +
+ 		+ + + + +
+ New version uploaded based on the previous comments. In case of record and set types to avoid the infinite recursions the suggestion is the optional field, for union types minimum one filed with different type (no recursion). Examples included for record and union types.
+
+
+
+ + + + + + + + + + +
+ (0008865) +
+ Gyorgy Rethy    +
+ 08-07-2009 11:13    +
+ 		+ + + + +
+ CR3783_RecursiveReference_RecordSet_v3.doc:
+OK with me, to be agreed with a wider audience
+
+
+
+ + + + + + + + + + +
+ (0008866) +
+ Tibor Csöndes    +
+ 08-07-2009 11:38    +
+ 		+ + + + +
+ I found a mistype:
+// Mistype
+type record MyRecord1
+    {
+        FieldType1 field1,
+        MyRecord1 field2 optional, FieldType3 field3
+    }
+// Correct
+type record MyRecord1
+    {
+        FieldType1 field1,
+        MyRecord1 field2 optional,
+        FieldType3 field3
+    }
+
+Example 6 and 7 should be merged, as it is in Example 5.
+
+
+
+ + + + + + + + + + +
+ (0008880) +
+ Ina Schieferdecker    +
+ 09-07-2009 10:36    +
+ 		+ + + + +
+ as proposed with some editorial changes
+
+ + diff --git a/docs/mantis/CR3784.md b/docs/mantis/CR3784.md new file mode 100644 index 0000000000000000000000000000000000000000..774454efec5cd8e4263806b46c6264577da4c792 --- /dev/null +++ b/docs/mantis/CR3784.md @@ -0,0 +1,74 @@ + + + + + + + + + + + + + 0003784: Field reference shall not point to itself - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0003784Part 01: TTCN-3 Core LanguageTechnicalpublic17-07-2008 10:5117-12-2008 09:42
ReporterGyorgy Rethy 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.3.2 (published 2008-04) 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)6.2.1.1, 6.2.2.1, 6.2.5.1
Source (company - Author)L.M.Ericsson
Summary0003784: Field reference shall not point to itself
DescriptionFields of structured types shall not refernce themselves.
Steps To Reproduce
Additional InformationAdd sentence to clauses 6.2.1.1, 6.2.2.1 and 6.2.5.1:
+Fields of (record|set|union) type definitions shall not reference themselves.
+EXAMPLE 2:
+type record MyType {
+   integer field1,
+   Mytype.field2 field2 optional, //this circular reference is disallowed
+   boolean field3
+}
TagsNo tags attached.
Relationships
Attached Filesdoc CR-3784-Field-reference-Resolution-V1.doc (152,576) 16-12-2008 13:30
http://oldforge.etsi.org/mantis/file_download.php?file_id=1902&type=bug
doc CR-3784-Field-reference-Resolution-V2.doc (100,864) 16-12-2008 14:01
http://oldforge.etsi.org/mantis/file_download.php?file_id=1903&type=bug
Issue History
Date ModifiedUsernameFieldChange
17-07-2008 10:51Gyorgy RethyNew Issue
17-07-2008 10:51Gyorgy RethyStatusnew => assigned
17-07-2008 10:51Gyorgy RethyAssigned To => Ina Schieferdecker
17-07-2008 10:51Gyorgy RethyClause Reference(s) => 6.2.1.1, 6.2.2.1, 6.2.5.1
17-07-2008 10:51Gyorgy RethySource (company - Author) => L.M.Ericsson
18-07-2008 11:21Ina SchieferdeckerAssigned ToIna Schieferdecker => Jens Grabowski
17-08-2008 09:14Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
16-12-2008 13:30Jens GrabowskiFile Added: CR-3784-Field-reference-Resolution-V1.doc
16-12-2008 13:31Jens GrabowskiAssigned ToJens Grabowski => Thomas Deiß
16-12-2008 14:00Thomas DeißNote Added: 0007716
16-12-2008 14:00Thomas DeißAssigned ToThomas Deiß => Jens Grabowski
16-12-2008 14:01Thomas DeißFile Added: CR-3784-Field-reference-Resolution-V2.doc
16-12-2008 17:13Jens GrabowskiAssigned ToJens Grabowski => Ina Schieferdecker
16-12-2008 17:13Jens GrabowskiStatusassigned => resolved
17-12-2008 09:39Ina SchieferdeckerResolutionopen => fixed
17-12-2008 09:39Ina SchieferdeckerFixed in Version => Edition 4.1.1 (not yet published)
17-12-2008 09:42Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0007716) +
+ Thomas Deiß    +
+ 16-12-2008 14:00    +
+ 		+ + + + +
+ I suggest to avoid text between the examples. The text should be before the examples. V2 uploaded.
+
+Otherwise ok.
+
+
+
+ + diff --git a/docs/mantis/CR3785.md b/docs/mantis/CR3785.md new file mode 100644 index 0000000000000000000000000000000000000000..6d44959facac970095347d17e2576da108392c41 --- /dev/null +++ b/docs/mantis/CR3785.md @@ -0,0 +1,29 @@ + + + + + + + + + + + + + 0003785: union is missing from the list of structured types - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0003785Part 01: TTCN-3 Core LanguageTechnicalpublic17-07-2008 10:5318-07-2008 11:18
ReporterGyorgy Rethy 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)6.2.1.3
Source (company - Author)     
Summary0003785: union is missing from the list of structured types
DescriptionIn the first sentence, within the brackets, union is missing from the list of structured types.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
17-07-2008 10:53Gyorgy RethyNew Issue
17-07-2008 10:53Gyorgy RethyStatusnew => assigned
17-07-2008 10:53Gyorgy RethyAssigned To => Ina Schieferdecker
17-07-2008 10:53Gyorgy RethyClause Reference(s) => 6.2.1.3
17-07-2008 10:53Gyorgy RethySource (company - Author) =>
18-07-2008 11:18Ina SchieferdeckerStatusassigned => closed
18-07-2008 11:18Ina SchieferdeckerResolutionopen => fixed
18-07-2008 11:18Ina SchieferdeckerFixed in Version => Edition 4.1.1 (not yet published)
18-07-2008 11:18Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
+
+ + + + +
+ There are no notes attached to this issue.
+ + diff --git a/docs/mantis/CR3794.md b/docs/mantis/CR3794.md new file mode 100644 index 0000000000000000000000000000000000000000..31fbb8df9c421063d080aba7de8c985b145a998f --- /dev/null +++ b/docs/mantis/CR3794.md @@ -0,0 +1,428 @@ + + + + + + + + + + + + + 0003794: Support for deployment - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0003794Part 01: TTCN-3 Core LanguageNew Featurepublic18-07-2008 10:3602-09-2010 11:11
ReporterJens Grabowski 
Assigned ToIna Schieferdecker 
PrioritylowSeverityfeatureReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.3.1 (published 2011-06)Fixed in Versionv4.3.1 (published 2011-06) 
Clause Reference(s)NONE
Source (company - Author)Jens Grabowski (STF 347)
Summary0003794: Support for deployment
DescriptionTTCN-3 does not support the deployment of test configurations. Several users asked for such a support. A limited attempt for deployment support was made in CR 419.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0000419closed Ina Schieferdecker Identifying PTC host in create statements 
Attached Filesdoc CR3794-part6.doc (181,760) 01-09-2010 15:04
http://oldforge.etsi.org/mantis/file_download.php?file_id=2424&type=bug
doc CR3794-part1.doc (55,808) 01-09-2010 15:40
http://oldforge.etsi.org/mantis/file_download.php?file_id=2425&type=bug
doc CR3794-part1-2-Rev-Jens.doc (59,904) 01-09-2010 16:25
http://oldforge.etsi.org/mantis/file_download.php?file_id=2427&type=bug
Issue History
Date ModifiedUsernameFieldChange
18-07-2008 10:36Jens GrabowskiNew Issue
18-07-2008 10:36Jens GrabowskiStatusnew => assigned
18-07-2008 10:36Jens GrabowskiAssigned To => Gyorgy Rethy
18-07-2008 10:36Jens GrabowskiClause Reference(s) => NONE
18-07-2008 10:36Jens GrabowskiSource (company - Author) => Jens Grabowski (STF 347)
18-07-2008 10:37Jens GrabowskiProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
17-08-2008 09:15Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
12-12-2008 16:01Ina SchieferdeckerRelationship addedrelated to 0000419
07-09-2009 10:18Gyorgy RethyAssigned ToGyorgy Rethy => Jens Grabowski
16-02-2010 14:25Jens GrabowskiNote Added: 0009218
22-03-2010 17:25Gyorgy RethyAssigned ToJens Grabowski =>
22-03-2010 17:25Gyorgy RethyStatusassigned => new
22-03-2010 17:25Gyorgy RethyTarget VersionEdition 4.1.1 Published 2009-06-02 => Edition 4.3.1 (not yet published)
23-03-2010 13:01Gyorgy RethyAssigned To => Jens Grabowski
23-03-2010 13:01Gyorgy RethyPrioritynormal => low
23-03-2010 13:01Gyorgy RethyStatusnew => assigned
31-08-2010 10:57Jens GrabowskiAssigned ToJens Grabowski => Jacob Wieland - Spirent
31-08-2010 12:50Jacob Wieland - SpirentNote Added: 0009664
31-08-2010 12:58Jacob Wieland - SpirentNote Added: 0009665
01-09-2010 10:07Jens GrabowskiNote Added: 0009668
01-09-2010 13:47Jacob Wieland - SpirentFile Added: CR3794-part1.doc
01-09-2010 13:47Jacob Wieland - SpirentNote Added: 0009675
01-09-2010 15:04Jacob Wieland - SpirentFile Added: CR3794-part6.doc
01-09-2010 15:09Jacob Wieland - SpirentNote Added: 0009679
01-09-2010 15:11Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Jens Grabowski
01-09-2010 15:40Jacob Wieland - SpirentFile Deleted: CR3794-part1.doc
01-09-2010 15:40Jacob Wieland - SpirentFile Added: CR3794-part1.doc
01-09-2010 16:25Jens GrabowskiFile Added: CR3794-part1-2-Rev-Jens.doc
01-09-2010 16:26Jens GrabowskiNote Added: 0009681
01-09-2010 16:27Jens GrabowskiAssigned ToJens Grabowski => Jacob Wieland - Spirent
01-09-2010 17:08Jacob Wieland - SpirentNote Added: 0009684
01-09-2010 17:10Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Ina Schieferdecker
01-09-2010 17:10Jacob Wieland - SpirentNote Added: 0009685
02-09-2010 11:10Ina SchieferdeckerNote Added: 0009695
02-09-2010 11:10Ina SchieferdeckerStatusassigned => resolved
02-09-2010 11:10Ina SchieferdeckerResolutionopen => fixed
02-09-2010 11:10Ina SchieferdeckerFixed in Version => Edition 4.3.1 (not yet published)
02-09-2010 11:11Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009218) +
+ Jens Grabowski    +
+ 16-02-2010 14:25    +
+ 		+ + + + +
+ To be discussed again for v5.1.1
+
+
+
+ + + + + + + + + + +
+ (0009664) +
+ Jacob Wieland - Spirent    +
+ 31-08-2010 12:50    +
+ 		+ + + + +
+ In principle, the proposal from CR419 is valid and would work:
+
+For this, as Ina mentioned, the following functions in TCI-CH need to be
+changed:
+
+tciCreateTestComponentReq()/tciCreateTestComponent() - add additional host parameter
+
+Likewise, the execute() statement should also get an additional optional parameter so that the MTC can also be started on a specific host.
+For this, also the following functions in TCI-CH need to be changed:
+
+tciExecuteTestCaseReq()/tciExecuteTestCase()
+
+In both cases, the CH implementation needs to be able to resolve the remote TE from the given host id in the -Req() functions and then relay those requests to that remote TE.
+
+The same approach would also work together with static configurations.
+
+Only in case that the additional parameter is given to the execute() or create() operations should the CH be asked to deploy the MTC/PTC on the given host, otherwise, it shall deploy as it sees fit (like before).
+===============================================================================
+
+Additionally, it could be allowed to declare a host type in the component type definition. In the create/execute operations, the given host expression (if any) would then have to be of the declared host type. If no host type is declared, the default host type should still be charstring.
+
+The syntax could look like this:
+
+type component C runs on hosttype {
+}
+
+(where hosttype must be a valid type reference)
+
+But, for component inheritance, rules to resolve clashes of host types must be considered. Several possibilities come to mind:
+
+- the host type is not inheritable, each component type MUST declare its own host type (and in case it does not, it is the default host type charstring)
+- the host type is inherited if all extended component types have the same host type, otherwise, it is the default host type. In this case, the host type can be overridden by the extending component type definition if it should be different.
+
+Personally, I favor option 1. In 99 % of cases the host type will be charstring anyway.
+
+
+
+ + + + + + + + + + +
+ (0009665) +
+ Jacob Wieland - Spirent    +
+ 31-08-2010 12:58    +
+ 		+ + + + +
+ Of course, the TLI must also be changed to include the host.
+
+The following events need a new sub-element:
+tliCCreate, tliTcExecute
+
+the element could look like this:
+
+<xsd:element name="host" type="Values:Value"/>
+
+
+
+ + + + + + + + + + +
+ (0009668) +
+ Jens Grabowski    +
+ 01-09-2010 10:07    +
+ 		+ + + + +
+ Ok, if everbody thinks that a charstring in a CREATE statement is enough support for deployment, then lets go for it.
+
+
+
+ + + + + + + + + + +
+ (0009675) +
+ Jacob Wieland - Spirent    +
+ 01-09-2010 13:47    +
+ 		+ + + + +
+ added necessary changes to part 1
+
+
+
+ + + + + + + + + + +
+ (0009679) +
+ Jacob Wieland - Spirent    +
+ 01-09-2010 15:09    +
+ 		+ + + + +
+ uploaded the added changes to TCI:
+
+only changes necessary were those for tciCreateTestComponentReq() as the CH then relays this request to the right remote TE (identified by the hostId) which does not need to get relayed the hostId. These changes have been made for all language mappings.
+
+tciExecuteTestCaseReq() does not need to be changed either because it is called after the MTC has already been created via tciCreateTestComponentReq()
+
+The tli interface does not really need to be changed either, because implicit deployment was also possible before and the information wasn't interesting before, either. But, we could of course still add the optional host id field in the tli.
+
+
+
+ + + + + + + + + + +
+ (0009681) +
+ Jens Grabowski    +
+ 01-09-2010 16:26    +
+ 		+ + + + +
+ Re-assigned to Jacob for cross-checking.
+
+
+
+ + + + + + + + + + +
+ (0009684) +
+ Jacob Wieland - Spirent    +
+ 01-09-2010 17:08    +
+ 		+ + + + +
+ review by Jens okay by me
+
+
+
+ + + + + + + + + + +
+ (0009685) +
+ Jacob Wieland - Spirent    +
+ 01-09-2010 17:10    +
+ 		+ + + + +
+ please review part 6
+
+
+
+ + + + + + + + + + +
+ (0009695) +
+ Ina Schieferdecker    +
+ 02-09-2010 11:10    +
+ 		+ + + + +
+ Ok with me. Implemented in Part 1 and Part 6 as proposed with one addition to TLI so that one can log the hostId in tliCCreate:
+
+    <xsd:complexType name="tliCCreate">
+        <xsd:complexContent mixed="true">
+            <xsd:extension base="Events:Event">
+                <xsd:sequence>
+                    <xsd:element name="comp" type="Types:TriComponentIdType"/>
+                    <xsd:element name="name" type="SimpleTypes:TString"/>
+                    <xsd:element name="hostId" type="Values:Value" minOccurs="0"/>
+                    <xsd:element name="alive" type="SimpleTypes:TBoolean"/>
+                </xsd:sequence>
+            </xsd:extension>
+        </xsd:complexContent>
+    </xsd:complexType>
+
+ + diff --git a/docs/mantis/CR3796.md b/docs/mantis/CR3796.md new file mode 100644 index 0000000000000000000000000000000000000000..5911eb1d2aafd38a47b22fc8b2beee2494129ddf --- /dev/null +++ b/docs/mantis/CR3796.md @@ -0,0 +1,63 @@ + + + + + + + + + + + + + 0003796: C++ Mapping for TRI - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 05: TTCN-3 Runtime Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0003796Part 05: TTCN-3 Runtime Interface Clarificationpublic18-07-2008 13:0712-12-2008 10:59
ReporterIna Schieferdecker 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityfeatureReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)New clause needed
Source (company - Author)Jesús Domínguez Colino, MTP, Spain
Summary0003796: C++ Mapping for TRI
DescriptionAccording to the MTS input by MTP, Spain the TRI will be extended with a C++ mapping.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0004253closed Ina Schieferdecker Part 06: TTCN-3 Control Interface C++ Mapping for TCI 
related to 0000829closed  Part 05: TTCN-3 Runtime Interface  C++ language mapping 
Attached Fileszip es_20187305v040000_withC++Mapping_180708.zip (303,769) 18-07-2008 13:08
http://oldforge.etsi.org/mantis/file_download.php?file_id=1570&type=bug
zip es_20187305v040000_MasterCopy.zip (291,365) 07-10-2008 05:55
http://oldforge.etsi.org/mantis/file_download.php?file_id=1674&type=bug
Issue History
Date ModifiedUsernameFieldChange
18-07-2008 13:07Ina SchieferdeckerNew Issue
18-07-2008 13:07Ina SchieferdeckerStatusnew => assigned
18-07-2008 13:07Ina SchieferdeckerAssigned To => Ina Schieferdecker
18-07-2008 13:07Ina SchieferdeckerClause Reference(s) => New clause needed
18-07-2008 13:07Ina SchieferdeckerSource (company - Author) => Jesús Domínguez Colino, MTP, Spain
18-07-2008 13:08Ina SchieferdeckerFile Added: es_20187305v040000_withC++Mapping_180708.zip
18-07-2008 13:08Ina SchieferdeckerProjectTTCN-3 Change Requests => Part 05: TTCN-3 Runtime Interface
18-07-2008 13:09Ina SchieferdeckerStatusassigned => resolved
18-07-2008 13:09Ina SchieferdeckerResolutionopen => fixed
18-07-2008 13:09Ina SchieferdeckerCategoryTRI => Clarification
18-07-2008 13:09Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
07-10-2008 05:53Ina SchieferdeckerNote Added: 0007005
07-10-2008 05:55Ina SchieferdeckerFile Added: es_20187305v040000_MasterCopy.zip
07-10-2008 05:58Ina SchieferdeckerRelationship addedrelated to 0004253
12-12-2008 10:59Ina SchieferdeckerStatusresolved => closed
12-12-2008 10:59Ina SchieferdeckerFixed in Version => Edition 4.1.1 (not yet published)
12-12-2008 12:02Ina SchieferdeckerRelationship addedrelated to 0000829
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0007005) +
+ Ina Schieferdecker    +
+ 07-10-2008 05:53    +
+ 		+ + + + +
+ Revision being done by Jesus and Ina
+
+ + diff --git a/docs/mantis/CR3802.md b/docs/mantis/CR3802.md new file mode 100644 index 0000000000000000000000000000000000000000..bfd45017d86bc75fa1063933d219334a488c762c --- /dev/null +++ b/docs/mantis/CR3802.md @@ -0,0 +1,29 @@ + + + + + + + + + + + + + 0003802: Clause reference is missing in $7.5.2 - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0003802Part 09: Using XML with TTCN-3Editorialpublic21-07-2008 18:5012-12-2008 11:33
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.3.1 (published 2008-04) 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)$7.5.2
For STF discussion
Source (company - Author) L.M.Ericsson
Summary0003802: Clause reference is missing in $7.5.2
DescriptionAt the end of the 2nd paragraph a clause reference is missing (bookmark error).
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
21-07-2008 18:50Gyorgy RethyNew Issue
21-07-2008 18:50Gyorgy RethyStatusnew => assigned
21-07-2008 18:50Gyorgy RethyAssigned To => Gyorgy Rethy
21-07-2008 18:50Gyorgy RethyClause Reference(s) => $7.5.2
21-07-2008 18:50Gyorgy RethySource (company - Author) => L.M.Ericsson
15-08-2008 06:38Gyorgy RethyStatusassigned => closed
15-08-2008 06:38Gyorgy RethyResolutionopen => fixed
15-08-2008 06:38Gyorgy RethyFixed in Version => Edition 4.1.1 (not yet published)
12-12-2008 11:33Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
+
+ + + + +
+ There are no notes attached to this issue.
+ + diff --git a/docs/mantis/CR3843.md b/docs/mantis/CR3843.md new file mode 100644 index 0000000000000000000000000000000000000000..5558a05978d46945b5885e1c4a1d2a49cb6d56de --- /dev/null +++ b/docs/mantis/CR3843.md @@ -0,0 +1,119 @@ + + + + + + + + + + + + + 0003843: Support C++ like Exception Handling mechanism - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0003843Part 01: TTCN-3 Core LanguageNew Featurepublic24-07-2008 08:4509-12-2008 10:22
Reporterwangguolong 
Assigned ToThomas Deiß 
PrioritynormalSeverityfeatureReproducibilityalways
StatusclosedResolutionwon't fix 
PlatformOSOS Version
Product Version 
Target Versionv4.1.1 (published 2009-06)Fixed in Version 
Clause Reference(s)NA
Source (company - Author)     
Summary0003843: Support C++ like Exception Handling mechanism
DescriptionIt is proposed to add one new features to the TTCN-3 core language standard that C++ like exception handling mechanism is supported in core language. Sometimes the errors in different level can be handled using scripts by users flexibly. This is realized and proved useful in real testing.
+
+Here is the example:
+
+try
+{
+    [block statment]
+}
+catch
+{
+    [block statment]
+     var charstring e:= "exception A";
+     throw (e);
+}
+
Steps To Reproduce
Additional Information1. try...catch... statment only catches the exception which caused by executor or internal error. The user defined exception is not supported and transferred.
+
+2. try...catch gives the control of the execution of test suites to the users when internal runtime error happens. Most times users did not want to terminate the automatic execution even if the runtime error happened. This statment gives them the way.
TagsNo tags attached.
Relationships
related to 0002565closed Ina Schieferdecker Part 06: TTCN-3 Control Interface TTCN-3 Exceptions 
Attached Filesppt TTCN-3_exceptions_02.ppt (206,848) 14-08-2008 12:34
http://oldforge.etsi.org/mantis/file_download.php?file_id=1599&type=bug
Issue History
Date ModifiedUsernameFieldChange
24-07-2008 08:45wangguolongNew Issue
24-07-2008 08:45wangguolongStatusnew => assigned
24-07-2008 08:45wangguolongAssigned To => Ina Schieferdecker
24-07-2008 08:45wangguolongClause Reference(s) => NA
24-07-2008 08:45wangguolongSource (company - Author) =>
11-08-2008 10:35Thomas DeißRelationship addedrelated to 0002565
11-08-2008 10:35Thomas DeißAssigned ToIna Schieferdecker => Thomas Deiß
11-08-2008 10:53Thomas DeißNote Added: 0006482
14-08-2008 12:34Thomas DeißFile Added: TTCN-3_exceptions_02.ppt
17-08-2008 09:10Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
09-12-2008 10:21Ina SchieferdeckerNote Added: 0007588
09-12-2008 10:22Ina SchieferdeckerStatusassigned => closed
09-12-2008 10:22Ina SchieferdeckerResolutionopen => won't fix
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0006482) +
+ Thomas Deiß    +
+ 11-08-2008 10:53    +
+ 		+ + + + +
+ Regarding CR 2565: The setverdict statement has been extended already such that a reason or cause for the verdict can be provided by the user. CR2565 will provide the corresponding extensions for the TRI such that the reason can also be passed to the TCI-TM.
+
+So far, STF 349 considers that user-defined exceptions do not extend the expressiveness of the language. Surely, some cases can be written in a more simple way. Would it be possible to get some more examples or use cases showing the benefit of introducing user-defined exceptions. (you can contact me directly at thomas.deiss@nsn.com).
+
+Catching runtime system errors and continueing test case execution would to some extend break the philosophy of TTCN-3. Once something went wrong in the test case - causing a runtime system error - the verdict would have been set to 'error' and further execution of the test case was considered meaningless. When catching runtime errors as exceptions, the verdict should not be set to 'error'.
+
+These are some initial thoughts by STF 349 on the CR. A more detailed analysis will be done.
+
+
+
+ + + + + + + + + + +
+ (0007588) +
+ Ina Schieferdecker    +
+ 09-12-2008 10:21    +
+ 		+ + + + +
+ For time being, the Maintenance STF decided not to introduce C++ like exceptions into TTCN-3. See also CR2565.
+
+ + diff --git a/docs/mantis/CR3867.md b/docs/mantis/CR3867.md new file mode 100644 index 0000000000000000000000000000000000000000..8f943b5d1aedbe0cd6e1b2a487646b1c065c8e8a --- /dev/null +++ b/docs/mantis/CR3867.md @@ -0,0 +1,103 @@ + + + + + + + + + + + + + 0003867: Actual template parameters - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0003867Part 01: TTCN-3 Core LanguageTechnicalpublic28-07-2008 16:4509-12-2008 17:23
ReporterGyorgy Rethy 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)$5.4.2
Source (company - Author)     
Summary0003867: Actual template parameters
Description$5.4.2 Restrictions a) says:
+a) ... If a formal template parameter is restricted, then only specific values or omit can be passed.
+
+This is true for the (omit) restriction only, but not for (present) and (value) restrictions.
Steps To Reproduce
Additional Informationchange restrictions to:
+a) The number of elements ... <current text without the last sentence>
+b) Restrictions on actual parameters passed to restricted formal template parameters described in clause 15.8 shall apply.
+c) <current restriction b) shifted, etc.>
TagsNo tags attached.
Relationships
Attached Filesdoc CR3867_ActualTemplateParameters.doc (31,744) 25-11-2008 16:34
http://oldforge.etsi.org/mantis/file_download.php?file_id=1779&type=bug
Issue History
Date ModifiedUsernameFieldChange
28-07-2008 16:45Gyorgy RethyNew Issue
28-07-2008 16:45Gyorgy RethyStatusnew => assigned
28-07-2008 16:45Gyorgy RethyAssigned To => Ina Schieferdecker
28-07-2008 16:45Gyorgy RethyClause Reference(s) => $5.4.2
28-07-2008 16:45Gyorgy RethySource (company - Author) =>
17-08-2008 09:11Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
25-11-2008 16:34Ina SchieferdeckerFile Added: CR3867_ActualTemplateParameters.doc
25-11-2008 16:34Ina SchieferdeckerNote Added: 0007422
25-11-2008 16:35Ina SchieferdeckerAssigned ToIna Schieferdecker => Gyorgy Rethy
25-11-2008 16:35Ina SchieferdeckerResolutionopen => fixed
25-11-2008 16:41Gyorgy RethyNote Added: 0007424
25-11-2008 16:41Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
25-11-2008 16:41Gyorgy RethyStatusassigned => resolved
09-12-2008 17:23Ina SchieferdeckerStatusresolved => closed
09-12-2008 17:23Ina SchieferdeckerFixed in Version => Edition 4.1.1 (not yet published)
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0007422) +
+ Ina Schieferdecker    +
+ 25-11-2008 16:34    +
+ 		+ + + + +
+ Please check.
+
+
+
+ + + + + + + + + + +
+ (0007424) +
+ Gyorgy Rethy    +
+ 25-11-2008 16:41    +
+ 		+ + + + +
+ Checked, it is OK with me.
+
+ + diff --git a/docs/mantis/CR3885.md b/docs/mantis/CR3885.md new file mode 100644 index 0000000000000000000000000000000000000000..af08b19dc95b42211248d8b4a31cb1c46457b5c1 --- /dev/null +++ b/docs/mantis/CR3885.md @@ -0,0 +1,151 @@ + + + + + + + + + + + + + 0003885: Mistake in grammar rule Value - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0003885Part 01: TTCN-3 Core LanguageClarificationpublic31-07-2008 13:1913-08-2008 16:19
ReporterElena de Vega 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionwon't fix 
PlatformOSOS Version
Product Version 
Target Versionv4.1.1 (published 2009-06)Fixed in Version 
Clause Reference(s)Grammar, Value
Source (company - Author) Elena de Vega - MTP
Summary0003885: Mistake in grammar rule Value
DescriptionGrammar rule Value problem:
+
+458. Value ::= PredefinedValue | ReferencedValue
+
+
+459. PredefinedValue ::= BitStringValue |
+                         BooleanValue |
+                         CharStringValue |
+                         IntegerValue |
+                         OctetStringValue |
+                         HexStringValue |
+                         VerdictTypeValue |
+                         EnumeratedValue |
+                         FloatValue |
+                         AddressValue |
+                         OmitValue
+466. EnumeratedValue ::= EnumerationIdentifier
+47. EnumerationIdentifier ::= Identifier
+
+
+
+478. ReferencedValue ::= ValueReference [ExtendedFieldReference]
+479. ValueReference ::= [GlobalModuleId Dot]
+                        ( ConstIdentifier | ExtConstIdentifier |
+                          ModuleParIdentifier )
+                        | ValueParIdentifier | VarIdentifier
+93. ConstIdentifier ::= Identifier
+273. ExtConstIdentifier ::= Identifier
+280. ModuleParIdentifier ::= Identifier
+292. VarIdentifier ::= Identifier
+506. ValueParIdentifier ::= Identifier
+
+The order of the rule Value doesn’t let access, with a simple identifier, to the rule ReferencedValue, this could cause confusion.
+
+This is because the rule EnumeratedValue of PredefinedValue matches with all simple identifiers.
+
+With the identifiers that use dot notation there isn’t problem because it always matches with ValueReference.
+
+The solution for this could be to change the two rules like:
+
+Value ::= ReferencedValue | PredefinedValue
+
+ But with this solution, if you use a simple identifier, it never matches with the rule EnumeratedValue. I think that it’s logical because the enumeration identifier is a simple identifier then it has to match with ReferencedValue.
+
+Then we can delete the rule EnumeratedValue from PredefinedValue and add the rule EnumerationIdentifier to ValueReference. This is the solution:
+
+
+458. Value ::= ReferencedValue | PredefinedValue
+
+
+459. PredefinedValue ::= BitStringValue |
+                         BooleanValue |
+                         CharStringValue |
+                         IntegerValue |
+                         OctetStringValue |
+                         HexStringValue |
+                         VerdictTypeValue |
+                         EnumeratedValue |
+                         FloatValue |
+                         AddressValue |
+                         OmitValue
+466. EnumeratedValue ::= EnumerationIdentifier
+
+478. ReferencedValue ::= ValueReference [ExtendedFieldReference]
+479. ValueReference ::= [GlobalModuleId Dot]
+                        ( ConstIdentifier | ExtConstIdentifier |
+                          ModuleParIdentifier )
+                        | ValueParIdentifier | VarIdentifier
+                        | EnumerationIdentifier
+93. ConstIdentifier ::= Identifier
+273. ExtConstIdentifier ::= Identifier
+280. ModuleParIdentifier ::= Identifier
+292. VarIdentifier ::= Identifier
+506. ValueParIdentifier ::= Identifier
+47. EnumerationIdentifier ::= Identifier
+
+
+In fact, ValueReference it’s only an Identifier Dot Identifier. I mean, you only match a simple identifier with the first non optional rule of the ValueReference.
+If you would like to do your grammar more efficient, you can change the rule ValueReference like:
+
+ValueReference = [Identifier Dot] Identifier
+
+This kind of change could be made in more grammar rules. But it probably needs a properly discussion.
+
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
31-07-2008 13:19Elena de VegaNew Issue
31-07-2008 13:19Elena de VegaClause Reference(s) => Grammar, Value
31-07-2008 13:19Elena de VegaSource (company - Author) => Elena de Vega - MTP
11-08-2008 08:41Ina SchieferdeckerAssigned To => Ina Schieferdecker
11-08-2008 08:41Ina SchieferdeckerStatusnew => assigned
13-08-2008 16:11Ina SchieferdeckerProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
13-08-2008 16:18Ina SchieferdeckerNote Added: 0006516
13-08-2008 16:19Ina SchieferdeckerStatusassigned => closed
13-08-2008 16:19Ina SchieferdeckerResolutionopen => won't fix
13-08-2008 16:19Ina SchieferdeckerCategoryTTCN-3 Core Language => Clarification
13-08-2008 16:19Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0006516) +
+ Ina Schieferdecker    +
+ 13-08-2008 16:18    +
+ 		+ + + + +
+ This CR correctly points at the issue of handling identifiers by the TTCN-3 BNF.
+
+However: the TTCN-3 BNF has been written in a human-readable form. One cannot create a parser directly out of it. This was not the intend of the BNF. Instead, readability was the goal. Therefore, one has to resolve various issues in the BNF to get a parser for it - identifiers are one of these issues.
+
+Hence, the maintenance team proposes not to fix this issue.
+
+ + diff --git a/docs/mantis/CR3942.md b/docs/mantis/CR3942.md new file mode 100644 index 0000000000000000000000000000000000000000..925669f4a1ff6a6e1ca6c1651d7e2e9d9f77df60 --- /dev/null +++ b/docs/mantis/CR3942.md @@ -0,0 +1,31 @@ + + + + + + + + + + + + + 0003942: Editorial for value range - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0003942Part 01: TTCN-3 Core LanguageClarificationpublic10-08-2008 08:4014-08-2008 12:52
ReporterIna Schieferdecker 
Assigned ToIna Schieferdecker 
PrioritynormalSeveritytrivialReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)B.1.2.5
Source (company - Author) Ina Schieferdecker
Summary0003942: Editorial for value range
DescriptionSection B.1.2.5 says currently "When used for values of integer or float types (and integer or float sub-types). A boundary value shall be either:..."
+
+It should be "When used for values of integer or float types (and integer or float sub-types), a boundary value shall be either: ..."
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
10-08-2008 08:40Ina SchieferdeckerNew Issue
10-08-2008 08:40Ina SchieferdeckerStatusnew => assigned
10-08-2008 08:40Ina SchieferdeckerAssigned To => Ina Schieferdecker
10-08-2008 08:40Ina SchieferdeckerClause Reference(s) => B.1.2.5
10-08-2008 08:40Ina SchieferdeckerSource (company - Author) => Ina Schieferdecker
13-08-2008 15:53Ina SchieferdeckerProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
13-08-2008 15:56Ina SchieferdeckerStatusassigned => resolved
13-08-2008 15:56Ina SchieferdeckerResolutionopen => fixed
13-08-2008 15:56Ina SchieferdeckerCategoryTTCN-3 Core Language => Clarification
13-08-2008 15:56Ina SchieferdeckerFixed in Version => Edition 4.1.1 (not yet published)
13-08-2008 15:56Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
14-08-2008 12:52Ina SchieferdeckerStatusresolved => closed
+
+ + + + +
+ There are no notes attached to this issue.
+ + diff --git a/docs/mantis/CR3943.md b/docs/mantis/CR3943.md new file mode 100644 index 0000000000000000000000000000000000000000..f461665aef88016ece71d2d73a4f3ea40c13fd0b --- /dev/null +++ b/docs/mantis/CR3943.md @@ -0,0 +1,140 @@ + + + + + + + + + + + + + 0003943: Ambiguity in component type extension - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0003943Part 01: TTCN-3 Core LanguageTechnicalpublic10-08-2008 12:3117-08-2008 10:07
ReporterGyorgy Rethy 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)$6.2.10.2
Source (company - Author)L.M.Ericsson
Summary0003943: Ambiguity in component type extension
DescriptionName clashes between the parent and the children comp. types are disallowed but the standard leaves ambiguity if names are clashing between the definitions in the different parent types (used in the same step of extension). E.g. in the case of
+type component X { timer T1:=1.0}
+type component Y { timer T1:=2.0}
+type component Z extends X,Y { timer T2; }
+function f() runs on Z {
+T1.start
+}
+what is the initial duration of timer T1?
Steps To Reproduce
Additional InformationAdd a new restriction b) in $6.2.10.2 (shift existing b) to c)):
+b) When defining component types by extending more than one parent types, there shall be no name clash between the definitions of the different parent types, i.e. there shall not be a port, variable, constant or timer identifier that is declared in any two of the parent types (directly or by means of extension).
TagsNo tags attached.
Relationships
Attached Filesdoc CR_3943_ambiguity_in_component_extension_resolution_01.doc (159,744) 13-08-2008 10:32
http://oldforge.etsi.org/mantis/file_download.php?file_id=1590&type=bug
Issue History
Date ModifiedUsernameFieldChange
10-08-2008 12:31Gyorgy RethyNew Issue
10-08-2008 12:31Gyorgy RethyStatusnew => assigned
10-08-2008 12:31Gyorgy RethyAssigned To => Ina Schieferdecker
10-08-2008 12:31Gyorgy RethyClause Reference(s) => $6.2.10.2
10-08-2008 12:31Gyorgy RethySource (company - Author) => L.M.Ericsson
11-08-2008 08:50Ina SchieferdeckerNote Added: 0006476
11-08-2008 08:51Ina SchieferdeckerAssigned ToIna Schieferdecker => Thomas Deiß
13-08-2008 10:32Thomas DeißFile Added: CR_3943_ambiguity_in_component_extension_resolution_01.doc
13-08-2008 10:34Thomas DeißNote Added: 0006509
13-08-2008 10:34Thomas DeißAssigned ToThomas Deiß => Gyorgy Rethy
13-08-2008 10:34Thomas DeißResolutionopen => fixed
15-08-2008 11:01Gyorgy RethyNote Added: 0006542
15-08-2008 11:01Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
15-08-2008 11:01Gyorgy RethyStatusassigned => resolved
17-08-2008 09:02Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
17-08-2008 10:07Ina SchieferdeckerStatusresolved => closed
17-08-2008 10:07Ina SchieferdeckerFixed in Version => Edition 4.1.1 (not yet published)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0006476) +
+ Ina Schieferdecker    +
+ 11-08-2008 08:50    +
+ 		+ + + + +
+ agreed in principle, but allow the diamond case for component type extension
+
+
+
+ + + + + + + + + + +
+ (0006509) +
+ Thomas Deiß    +
+ 13-08-2008 10:34    +
+ 		+ + + + +
+ resolution proposal for checking added.
+
+
+
+
+ + + + + + + + + + +
+ (0006542) +
+ Gyorgy Rethy    +
+ 15-08-2008 11:01    +
+ 		+ + + + +
+ Resolution proposal checked, OK from my side.
+
+ + diff --git a/docs/mantis/CR3945.md b/docs/mantis/CR3945.md new file mode 100644 index 0000000000000000000000000000000000000000..05728b97698c30660b02de1d3d702cae2ca4f935 --- /dev/null +++ b/docs/mantis/CR3945.md @@ -0,0 +1,91 @@ + + + + + + + + + + + + + 0003945: Empty statement blocks shall be allowed by BNF - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0003945Part 01: TTCN-3 Core LanguageTechnicalpublic11-08-2008 11:0114-08-2008 12:51
ReporterGyorgy Rethy 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)BNF rules 171-173
Source (company - Author)L.M.Ericsson
Summary0003945: Empty statement blocks shall be allowed by BNF
DescriptionIn fact two issues are raised by the CR:
+1) The current BNF rule
+
+172. FunctionStatementOrDefList ::= {FunctionStatementOrDef [SemiColon]}+
+
+disallows empty statement blocks, while it is not forbidden by the text, see for example note 3 to clause 5.2:
+"NOTE 3: Statement blocks may include declarations. They may occur as stand-alone statement blocks, embedded in another statement block or within compound statements, e.g. as body of a while loop."
+
+2) In clause 5.3 the textual part mandates that
+"Inside a statement block, such as a function body or a branch of an
+if-else statement, all declarations (if any), shall be made at the
+beginning of the statement block only."
+
+This rule is not reflected in the bnf:
+171. StatementBlock ::= "{" [FunctionStatementOrDefList] "}"
+172. FunctionStatementOrDefList ::= {FunctionStatementOrDef [SemiColon]}+
+173. FunctionStatementOrDef ::= FunctionLocalDef |
+                                FunctionLocalInst |
+                                FunctionStatement
+It is proposed to increase the clarity and usability of the standard by changing the bnf that it also indicates the above rule.
+
Steps To Reproduce
Additional InformationProposed new bnf productions:
+
+171. StatementBlock ::= "{" [FunctionDefList] [FunctionStatementList] "}"
+172. FunctionDefList ::= {(FunctionLocalDef | FunctionLocalInst) [SemiColon]}
+173. FunctionStatementList ::= {FunctionStatement [SemiColon]}
+
TagsNo tags attached.
Relationships
Attached Filesdoc CR_EmptyStatementBlock.doc (25,088) 13-08-2008 15:47
http://oldforge.etsi.org/mantis/file_download.php?file_id=1592&type=bug
Issue History
Date ModifiedUsernameFieldChange
11-08-2008 11:01Gyorgy RethyNew Issue
11-08-2008 11:01Gyorgy RethyStatusnew => assigned
11-08-2008 11:01Gyorgy RethyAssigned To => Ina Schieferdecker
11-08-2008 11:01Gyorgy RethyClause Reference(s) => BNF rules 171-173
11-08-2008 11:01Gyorgy RethySource (company - Author) => L.M.Ericsson
13-08-2008 15:46Ina SchieferdeckerNote Added: 0006514
13-08-2008 15:47Ina SchieferdeckerFile Added: CR_EmptyStatementBlock.doc
13-08-2008 15:48Ina SchieferdeckerAssigned ToIna Schieferdecker => Gyorgy Rethy
13-08-2008 15:48Ina SchieferdeckerResolutionopen => fixed
13-08-2008 16:08Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
13-08-2008 16:08Gyorgy RethyStatusassigned => resolved
14-08-2008 12:51Ina SchieferdeckerStatusresolved => closed
14-08-2008 12:51Ina SchieferdeckerFixed in Version => Edition 4.1.1 (not yet published)
14-08-2008 12:51Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0006514) +
+ Ina Schieferdecker    +
+ 13-08-2008 15:46    +
+ 		+ + + + +
+ In fact, statement blocks can be empty:
+171. StatementBlock ::= "{" [FunctionStatementOrDefList] "}"
+
+The ordering of definitions before statements should be added - see slight change in BNF proposal
+
+ + diff --git a/docs/mantis/CR3946.md b/docs/mantis/CR3946.md new file mode 100644 index 0000000000000000000000000000000000000000..b08c982032c64dd08aa0d4ea5488c9164261bbcb --- /dev/null +++ b/docs/mantis/CR3946.md @@ -0,0 +1,120 @@ + + + + + + + + + + + + + 0003946: Harmonize the semantics of assignments and parameterization - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0003946Part 01: TTCN-3 Core LanguageTechnicalpublic11-08-2008 11:4609-12-2008 14:36
ReporterGyorgy Rethy 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)L.M.Ericsson
Source (company - Author)     
Summary0003946: Harmonize the semantics of assignments and parameterization
DescriptionThe definition of out formal parameters says:
+" kind of parameterization where the value of the actual parameter (the argument) is not bound to the formal parameter when the parameterized object is invoked, but the value of the formal parameter is passed back to the actual parameter when the invoked object completes
+...
+NOTE 2: An out formal parameter is uninitialized (unbound) when the invoked object is entered."
+
+Therefore, if no value is assigned to the out formal parameter, it should make the content of the actual parameter uninitialized.
+
+On the other hand, note 1 of 5.4.1 says:
+"NOTE 1: Although out parameters can be read within the parameterized object, they do not inherit the value of their actual parameter; i.e. they should be set before they are read."
+
+There are two observations regarding this:
+1) Writing back the content of the out parameter to the actual parameter can be considered as reading the parameter
+2) Writing back the content of the out parameter is a kind of assignment; thus the two semantics should be harmonized (no unbound value is allowed on the right hand side of assignments); except language consistency this would simplify the language
+3) In TTCN-3 an already initialized variable should never be done uninitialized again, as this is increasing the probability of test case errors.
+
+Clarify the semantics of out formal parameters.
Steps To Reproduce
Additional InformationIn practical terms the only possible use of out parameterization is identical to inout parameterization plus new value assignment.
+EXAMPLE 1:
+function f(out integer p_int) runs oc Comp_CT {
+//trying to use p_int inside the function before initializition would
+//lead to an error (except passing on as actual parameter to an inout
+//or our parameter of another function, but this just shifts the problem
+p_int := 5;
+v_compVar := 2*5;
+}
+
+This results the same behaviour as:
+function f1(inout integer p_int) runs oc Comp_CT {
+p_int := 5;
+v_compVar := 2*5;
+}
+
+EXAMPLE 2:
+function f2(out integer p_int) runs oc Comp_CT {
+//p_int left unitialized
+}
+
+function f3(){
+var integer vl_int := 5;//initializetion here does not change the example;
+f2(vl_int);
+//at this point vl_int should be uninitialized; hence it shall be intialized (again) before using it in an expression
+vl_int := 10;
+...
+}
+
+This results the same behaviour as:
+function f4(inout integer p_int) runs oc Comp_CT {
+//p_int left unchanged
+}
+
+function f3(){
+var integer vl_int := 5;//initializetion here does not change the example;
+f2(vl_int);
+vl_int := 10;
+...
+}
+
TagsNo tags attached.
Relationships
Attached Filesdoc CR3946_OutParameterization.doc (24,576) 28-11-2008 08:24
http://oldforge.etsi.org/mantis/file_download.php?file_id=1828&type=bug
doc CR3946_OutParameterization v2.doc (24,576) 28-11-2008 10:21
http://oldforge.etsi.org/mantis/file_download.php?file_id=1833&type=bug
Issue History
Date ModifiedUsernameFieldChange
11-08-2008 11:46Gyorgy RethyNew Issue
11-08-2008 11:46Gyorgy RethyStatusnew => assigned
11-08-2008 11:46Gyorgy RethyAssigned To => Ina Schieferdecker
11-08-2008 11:46Gyorgy RethyClause Reference(s) => L.M.Ericsson
11-08-2008 11:46Gyorgy RethySource (company - Author) =>
11-08-2008 12:12Gyorgy RethyDescription Updated
17-08-2008 09:11Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
28-11-2008 08:24Ina SchieferdeckerFile Added: CR3946_OutParameterization.doc
28-11-2008 08:24Ina SchieferdeckerAssigned ToIna Schieferdecker => Gyorgy Rethy
28-11-2008 08:24Ina SchieferdeckerResolutionopen => fixed
28-11-2008 10:21Gyorgy RethyFile Added: CR3946_OutParameterization v2.doc
28-11-2008 10:21Gyorgy RethyNote Added: 0007497
28-11-2008 10:22Gyorgy RethyNote Edited: 0007497
28-11-2008 10:22Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
09-12-2008 14:36Ina SchieferdeckerStatusassigned => resolved
09-12-2008 14:36Ina SchieferdeckerFixed in Version => Edition 4.1.1 (not yet published)
09-12-2008 14:36Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0007497) +
+ Gyorgy Rethy    +
+ 28-11-2008 10:21    +
(edited on: 28-11-2008 10:22)
+ 		+ + + + +
+ Just minor editorial changes. OK with me. From my side it is OK to be implemented.
+
+
+
+ + diff --git a/docs/mantis/CR3948.md b/docs/mantis/CR3948.md new file mode 100644 index 0000000000000000000000000000000000000000..8e74c7fdb5f571b014639a001001298ba4f2a472 --- /dev/null +++ b/docs/mantis/CR3948.md @@ -0,0 +1,66 @@ + + + + + + + + + + + + + 0003948: Missing TTCN-3 terminals in A.1.5 - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0003948Part 01: TTCN-3 Core LanguageClarificationpublic12-08-2008 14:3313-08-2008 15:33
ReporterIna Schieferdecker 
Assigned ToIna Schieferdecker 
PrioritylowSeveritytrivialReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)A.1.5
Source (company - Author)Fraunhofer FOKUS
Summary0003948: Missing TTCN-3 terminals in A.1.5
DescriptionThe permuation and recursive keywords are missing in Table A.3.
+
+(Although recursive is a deprecated feature, it is part of the BNF in annex A like for other deprecated features.)
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR_3984_missing_keywords_resolution_01.doc (169,984) 13-08-2008 13:50
http://oldforge.etsi.org/mantis/file_download.php?file_id=1591&type=bug
Issue History
Date ModifiedUsernameFieldChange
12-08-2008 14:33Ina SchieferdeckerNew Issue
12-08-2008 14:33Ina SchieferdeckerClause Reference(s) => A.1.5
12-08-2008 14:33Ina SchieferdeckerSource (company - Author) => Fraunhofer FOKUS
13-08-2008 10:35Thomas DeißStatusnew => assigned
13-08-2008 10:35Thomas DeißAssigned To => Thomas Deiß
13-08-2008 13:50Thomas DeißFile Added: CR_3984_missing_keywords_resolution_01.doc
13-08-2008 13:52Thomas DeißNote Added: 0006511
13-08-2008 13:52Thomas DeißAssigned ToThomas Deiß => Ina Schieferdecker
13-08-2008 13:52Thomas DeißResolutionopen => fixed
13-08-2008 15:32Ina SchieferdeckerProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
13-08-2008 15:33Ina SchieferdeckerStatusassigned => resolved
13-08-2008 15:33Ina SchieferdeckerCategoryTTCN-3 Core Language => Clarification
13-08-2008 15:33Ina SchieferdeckerFixed in Version => Edition 4.1.1 (not yet published)
13-08-2008 15:33Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
13-08-2008 15:33Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0006511) +
+ Thomas Deiß    +
+ 13-08-2008 13:52    +
+ 		+ + + + +
+ list of keywords in table A3 and BNF checked against each other. No other keywords found missing in Table A3.
+
+
+ + diff --git a/docs/mantis/CR3951.md b/docs/mantis/CR3951.md new file mode 100644 index 0000000000000000000000000000000000000000..8b27c02d4cc1ac9f7017c3661825096d48199924 --- /dev/null +++ b/docs/mantis/CR3951.md @@ -0,0 +1,77 @@ + + + + + + + + + + + + + 0003951: Incorrect word used ( consistent instead what is correct compatible) - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0003951Part 01: TTCN-3 Core LanguageClarificationpublic13-08-2008 09:5113-08-2008 15:37
ReporterClaude Desroches 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.3.2 (published 2008-04) 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)Page 19: Section 5.2 ( in version 3.4.1)
Source (company - Author)BluKaktus-Claude Desroches
Summary0003951: Incorrect word used ( consistent instead what is correct compatible)
DescriptionConsistent test component type
+
+Page 19: Section 5.2
+
+What is meant by "consistent test component type"?
+
+I believe that the intent was to use the word “compatible”, instead of the word “consistent”.
+
+Implied is a component which is extended. A component which 'inherits' from another component type is compatible to the component it inherits from.
+
+Consistent and compatible are not synonyms.
+
+Solution: Replace the consistent with the word compatible.
+
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
13-08-2008 09:51Claude DesrochesNew Issue
13-08-2008 09:51Claude DesrochesStatusnew => assigned
13-08-2008 09:51Claude DesrochesAssigned To => Ina Schieferdecker
13-08-2008 09:51Claude DesrochesClause Reference(s) => Page 19: Section 5.2 ( in version 3.4.1)
13-08-2008 09:51Claude DesrochesSource (company - Author) => BluKaktus-Claude Desroches
13-08-2008 15:36Ina SchieferdeckerNote Added: 0006513
13-08-2008 15:36Ina SchieferdeckerStatusassigned => resolved
13-08-2008 15:36Ina SchieferdeckerResolutionopen => fixed
13-08-2008 15:36Ina SchieferdeckerFixed in Version => Edition 4.1.1 (not yet published)
13-08-2008 15:36Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
13-08-2008 15:36Ina SchieferdeckerDescription Updated
13-08-2008 15:37Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0006513) +
+ Ina Schieferdecker    +
+ 13-08-2008 15:36    +
+ 		+ + + + +
+ Agreed to change to: "Definitions made in a test component type may be used only in functions, test cases and altsteps referencing that component type or a compatible test component type (see clause 6.3.3) by a runs on-clause."
+
+ + diff --git a/docs/mantis/CR3955.md b/docs/mantis/CR3955.md new file mode 100644 index 0000000000000000000000000000000000000000..a1998bf5d1edd368aa96424969e8bd15dda8315f --- /dev/null +++ b/docs/mantis/CR3955.md @@ -0,0 +1,185 @@ + + + + + + + + + + + + + 0003955: Text ""TTCN-3 supports value, template, timer and port parameterization” is misleading - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0003955Part 01: TTCN-3 Core LanguageEditorialpublic13-08-2008 22:4912-12-2008 10:49
ReporterClaude Desroches 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.3.2 (published 2008-04) 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)Page 22, section 5.4
Source (company - Author)     BluKaktus - Claude Desroches
Summary0003955: Text ""TTCN-3 supports value, template, timer and port parameterization” is misleading
Description"TTCN-3 supports value, template, timer and port parameterization”
+
+This sentence seems to imply that the elements "value, template, timer, and port" may be parameterized.
+
+However, what is actually meant is that these ‘elements’ can be used as actual/formal parameters to the elements identified in table 2.
+
+This sentence should be changed so that the meaning is clear.
+
+Otherwise one might be led to believe that there is a contradiction between the above sentence, and the NOTE in table 2, which states that port definitions do not allow parameterization.
+
Steps To Reproduce
Additional InformationSuggested correction:
+
+Values, templates, timers, and ports may be used as actual and/or formal parameters where permitted by TTCN-3.
+
TagsNo tags attached.
Relationships
related to 0002590closed Ina Schieferdecker parameterization of signatures 
related to 0000403closed Gyorgy Rethy Port type parameterisation of component types 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
13-08-2008 22:49Claude DesrochesNew Issue
13-08-2008 22:49Claude DesrochesStatusnew => assigned
13-08-2008 22:49Claude DesrochesAssigned To => Ina Schieferdecker
13-08-2008 22:49Claude DesrochesClause Reference(s) => Page 22, section 5.4
13-08-2008 22:49Claude DesrochesSource (company - Author) => BluKaktus - Claude Desroches
14-08-2008 14:02Ina SchieferdeckerNote Added: 0006531
14-08-2008 14:04Ina SchieferdeckerAssigned ToIna Schieferdecker => Thomas Deiß
14-08-2008 14:04Ina SchieferdeckerResolutionopen => fixed
14-08-2008 14:04Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
14-08-2008 14:22Thomas DeißNote Added: 0006533
09-12-2008 10:24Ina SchieferdeckerRelationship addedrelated to 0002590
09-12-2008 10:24Ina SchieferdeckerRelationship addedrelated to 0000403
09-12-2008 10:27Ina SchieferdeckerNote Added: 0007589
12-12-2008 09:53Thomas DeißNote Added: 0007676
12-12-2008 09:53Thomas DeißAssigned ToThomas Deiß => Ina Schieferdecker
12-12-2008 10:49Ina SchieferdeckerStatusassigned => resolved
12-12-2008 10:49Ina SchieferdeckerFixed in Version => Edition 4.1.1 (not yet published)
12-12-2008 10:49Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0006531) +
+ Ina Schieferdecker    +
+ 14-08-2008 14:02    +
+ 		+ + + + +
+ To be changed to "TTCN-3 allows to parameterize modules, types, templates, functions, altsteps and testcases. Values, templates, timers, and ports may be used as actual parameters. A summary of which language elements can be parameterized and what can be passed to them as parameters is given in table 2."
+
+The CR has relations to CR2590 - see there.
+
+
+
+ + + + + + + + + + +
+ (0006533) +
+ Thomas Deiß    +
+ 14-08-2008 14:22    +
+ 		+ + + + +
+ The proposed text in the previous note is fine for me.
+I suggest to wait with closing the CR until CR403 on port type parameterization has been resolved. Depending on the resolution of CR403, the proposed text might have to be changed.
+
+
+
+ + + + + + + + + + +
+ (0007589) +
+ Ina Schieferdecker    +
+ 09-12-2008 10:27    +
+ 		+ + + + +
+ According to resolution of CR403 to be changed to
+
+"TTCN-3 allows to parameterize modules, templates, functions, altsteps and testcases. Values, templates, timers, and ports may be used as actual parameters. A summary of which language elements can be parameterized and what can be passed to them as parameters is given in table 2.
+
+NOTE: Type parameterization for TTCN-3 is defined in the optional package [xx]."
+
+
+
+ + + + + + + + + + +
+ (0007676) +
+ Thomas Deiß    +
+ 12-12-2008 09:53    +
+ 		+ + + + +
+ proposed solution (in note 7589) is ok.
+
+
+ + diff --git a/docs/mantis/CR3956.md b/docs/mantis/CR3956.md new file mode 100644 index 0000000000000000000000000000000000000000..ba13de899bd375ffbdf8ae85d8425ce2ed549cc0 --- /dev/null +++ b/docs/mantis/CR3956.md @@ -0,0 +1,65 @@ + + + + + + + + + + + + + 0003956: IIDL --> Type in: Figure 1: User's view of the core language and the various presentation formats - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0003956Part 01: TTCN-3 Core LanguageEditorialpublic13-08-2008 23:0214-08-2008 12:53
ReporterClaude Desroches 
Assigned ToIna Schieferdecker 
PrioritynormalSeveritytextReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.3.2 (published 2008-04) 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)4.1 Page 18
Source (company - Author)     BluKaktus - Claude Desroches
Summary0003956: IIDL --> Type in: Figure 1: User's view of the core language and the various presentation formats
DescriptionIn Figure 1, Replace IIDL with IDL
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
13-08-2008 23:02Claude DesrochesNew Issue
13-08-2008 23:02Claude DesrochesStatusnew => assigned
13-08-2008 23:02Claude DesrochesAssigned To => Ina Schieferdecker
13-08-2008 23:02Claude DesrochesClause Reference(s) => 4.1 Page 18
13-08-2008 23:02Claude DesrochesSource (company - Author) => BluKaktus - Claude Desroches
14-08-2008 12:43Ina SchieferdeckerNote Added: 0006526
14-08-2008 12:43Ina SchieferdeckerStatusassigned => resolved
14-08-2008 12:43Ina SchieferdeckerResolutionopen => fixed
14-08-2008 12:43Ina SchieferdeckerFixed in Version => Edition 4.1.1 (not yet published)
14-08-2008 12:43Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
14-08-2008 12:43Ina SchieferdeckerDescription Updated
14-08-2008 12:53Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0006526) +
+ Ina Schieferdecker    +
+ 14-08-2008 12:43    +
+ 		+ + + + +
+ done.
+
+also, the C/C++ mapping has been removed from the figure as this work has been termintad in MTS
+
+ + diff --git a/docs/mantis/CR3957.md b/docs/mantis/CR3957.md new file mode 100644 index 0000000000000000000000000000000000000000..f51836631e55a7f4ec60efc07ada0fb6ca18e3e5 --- /dev/null +++ b/docs/mantis/CR3957.md @@ -0,0 +1,73 @@ + + + + + + + + + + + + + 0003957: NOTE in Table 1: Overview of TTCN 3 language elements - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0003957Part 01: TTCN-3 Core LanguageEditorialpublic13-08-2008 23:0614-08-2008 12:53
ReporterClaude Desroches 
Assigned ToIna Schieferdecker 
PrioritynormalSeveritytextReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.3.2 (published 2008-04) 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)5 Page 19
Source (company - Author)     BluKaktus - Claude Desroches
Summary0003957: NOTE in Table 1: Overview of TTCN 3 language elements
DescriptionNOTE: The notions "definition" and "declaration" of variables, constants, types and other language elements are used interchangeable throughout the present document. The distinction between both notions is useful only for implementation purposes, as it is the case in programming languages like C and C++. On the level of TTCN 3, the notions have equal meaning.
+
+change to: (preferable)
+
+NOTE: The notions "definition" and "declaration" of variables, constants, types and other language elements are used interchangeably throughout the present document. The distinction between both notions is useful only for implementation purposes, as it is the case in programming languages like C and C++. On the level of TTCN-3, the notions have equal meaning.
+
+or to:
+
+NOTE: The notions "definition" and "declaration" of variables, constants, types and other language elements are interchangeable throughout the present document. The distinction between both notions is useful only for implementation purposes, as it is the case in programming languages like C and C++. On the level of TTCN 3, the notions have equal meaning.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
13-08-2008 23:06Claude DesrochesNew Issue
13-08-2008 23:06Claude DesrochesStatusnew => assigned
13-08-2008 23:06Claude DesrochesAssigned To => Ina Schieferdecker
13-08-2008 23:06Claude DesrochesClause Reference(s) => 5 Page 19
13-08-2008 23:06Claude DesrochesSource (company - Author) => BluKaktus - Claude Desroches
14-08-2008 12:30Ina SchieferdeckerNote Added: 0006525
14-08-2008 12:31Ina SchieferdeckerStatusassigned => resolved
14-08-2008 12:31Ina SchieferdeckerResolutionopen => fixed
14-08-2008 12:31Ina SchieferdeckerFixed in Version => Edition 4.1.1 (not yet published)
14-08-2008 12:31Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
14-08-2008 12:31Ina SchieferdeckerDescription Updated
14-08-2008 12:53Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0006525) +
+ Ina Schieferdecker    +
+ 14-08-2008 12:30    +
+ 		+ + + + +
+ changed to
+
+"NOTE: The notions "definition" and "declaration" of variables, constants, types and other language elements are used interchangeably throughout the present document. The distinction between both notions is useful only for implementation purposes, as it is the case in programming languages like C and C++. On the level of TTCN-3, the notions have equal meaning."
+
+ + diff --git a/docs/mantis/CR3958.md b/docs/mantis/CR3958.md new file mode 100644 index 0000000000000000000000000000000000000000..811058914f57df22a40e24ee37457e4e3e6c5687 --- /dev/null +++ b/docs/mantis/CR3958.md @@ -0,0 +1,86 @@ + + + + + + + + + + + + + 0003958: Incorrect grammar object-number agreement ( which is a misleading statement) - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0003958Part 01: TTCN-3 Core LanguageEditorialpublic13-08-2008 23:1214-08-2008 12:52
ReporterClaude Desroches 
Assigned ToIna Schieferdecker 
PrioritynormalSeveritytextReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.3.2 (published 2008-04) 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)5.2, Page 20
Source (company - Author)     BluKaktus - Claude Desroches
Summary0003958: Incorrect grammar object-number agreement ( which is a misleading statement)
DescriptionNOTE 1: Additional scoping rule for groups are given in clause 8.2.2.
+
+Change to: (intended)
+
+NOTE 1: Additional scoping rules for groups are given in clause 8.2.2.
+
+or to:
+NOTE 1: Additional scoping rule for groups is given in clause 8.2.2.
+---------------------------------
+
+NOTE 2: Additional scoping rule for counters of for loops are given in clause 19.4.
+
+Change to: (rule- should be plural)
+
+NOTE 2: Additional scoping rules for counters of for loops are given in clause 19.4.
+
+The changes are needed as it is unclear what the right statement is. Is there one or more scoping rules? A pedantic reader might assume that there might only be one scoping rule based on the existing text. Assumed are multiple scoping rules.
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
13-08-2008 23:12Claude DesrochesNew Issue
13-08-2008 23:12Claude DesrochesStatusnew => assigned
13-08-2008 23:12Claude DesrochesAssigned To => Ina Schieferdecker
13-08-2008 23:12Claude DesrochesClause Reference(s) => 5.2, Page 20
13-08-2008 23:12Claude DesrochesSource (company - Author) => BluKaktus - Claude Desroches
14-08-2008 10:31Ina SchieferdeckerNote Added: 0006522
14-08-2008 10:32Ina SchieferdeckerStatusassigned => resolved
14-08-2008 10:32Ina SchieferdeckerResolutionopen => fixed
14-08-2008 10:32Ina SchieferdeckerFixed in Version => Edition 4.1.1 (not yet published)
14-08-2008 10:32Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
14-08-2008 12:52Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0006522) +
+ Ina Schieferdecker    +
+ 14-08-2008 10:31    +
+ 		+ + + + +
+ Note 1 changed to
+
+"NOTE 1: Additional scoping rule for groups is given in clause 8.2.2."
+
+Note 2 changed to
+
+"NOTE 2: Additional scoping rule for counters of for loops are is given in clause 19.4."
+
+ + diff --git a/docs/mantis/CR3965.md b/docs/mantis/CR3965.md new file mode 100644 index 0000000000000000000000000000000000000000..ec06b262887ed2a5e3454c376bb0737426c21e22 --- /dev/null +++ b/docs/mantis/CR3965.md @@ -0,0 +1,119 @@ + + + + + + + + + + + + + 0003965: Inconsistency for inout and out parameters of functions started on test components - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0003965Part 01: TTCN-3 Core LanguageClarificationpublic14-08-2008 14:5717-08-2008 10:09
ReporterIna Schieferdecker 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)Part 1, clause 5.4.1.1 Restr. b and Part 6, clause 7.3.3.1.6 and clause 7.3.3.2.14
Source (company - Author) FOKUS
Summary0003965: Inconsistency for inout and out parameters of functions started on test components
DescriptionDifferent to clause 21.2.2 restr. b
+
+"Possible return values of a function invoked in a start test component operation, i.e. templates denoted by return keyword or inout and out parameters, have no effect when the started test component terminates."
+
+clause 5.4.1.1 restr. b says:
+
+"b) Formal value parameters of types, of templates, of functions started as test component behaviour (see clause 21.2.2) and of altsteps activated as defaults (see clause 20.5.2) shall always be in parameters."
+
+
+Clause 5.4.1.1 restr. b should be corrected to
+
+"b) Formal value parameters of types, of templates, and of altsteps activated as defaults (see clause 20.5.2) shall always be in parameters."
+
+
+Furthermore, part 6 has to be corrected:
+
+In clause 7.3.3.1.6 tciStartTestComponent and in clause 7.3.3.2.14 tciStartTestComponentReq the sentence
+
+"Since only in parameters are allowed for functions being started (ES 201 873 1 [1]), parameterList contains only in parameters."
+
+has to be deleted.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR_3965_inconsitency_resolution_01.doc (144,384) 14-08-2008 15:32
http://oldforge.etsi.org/mantis/file_download.php?file_id=1605&type=bug
doc CR_3965_inconsitency_resolution_02.doc (116,224) 15-08-2008 08:21
http://oldforge.etsi.org/mantis/file_download.php?file_id=1607&type=bug
Issue History
Date ModifiedUsernameFieldChange
14-08-2008 14:57Ina SchieferdeckerNew Issue
14-08-2008 14:57Ina SchieferdeckerStatusnew => assigned
14-08-2008 14:57Ina SchieferdeckerAssigned To => Thomas Deiß
14-08-2008 14:57Ina SchieferdeckerClause Reference(s) => Part 1, clause 5.4.1.1 Restr. b and Part 6, clause 7.3.3.1.6 and clause 7.3.3.2.14
14-08-2008 14:57Ina SchieferdeckerSource (company - Author) => FOKUS
14-08-2008 15:32Thomas DeißFile Added: CR_3965_inconsitency_resolution_01.doc
14-08-2008 15:33Thomas DeißClause Reference(s)Part 1, clause 5.4.1.1 Restr. b and Part 6, clause 7.3.3.1.6 and clause 7.3.3.2.14 => Part 1, clause 5.4.1.1 Restr. b and Part 6, clause 7.3.3.1.6 and clause 7.3.3.2.14
14-08-2008 15:33Thomas DeißNote Added: 0006537
14-08-2008 15:33Thomas DeißAssigned ToThomas Deiß => Ina Schieferdecker
15-08-2008 08:21Ina SchieferdeckerFile Added: CR_3965_inconsitency_resolution_02.doc
15-08-2008 08:21Ina SchieferdeckerProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
15-08-2008 08:24Ina SchieferdeckerNote Added: 0006539
15-08-2008 08:24Ina SchieferdeckerStatusassigned => resolved
15-08-2008 08:24Ina SchieferdeckerResolutionopen => fixed
15-08-2008 08:24Ina SchieferdeckerCategoryTTCN-3 Core Language => Clarification
15-08-2008 08:24Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
17-08-2008 10:09Ina SchieferdeckerStatusresolved => closed
17-08-2008 10:09Ina SchieferdeckerFixed in Version => Edition 4.1.1 (not yet published)
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0006537) +
+ Thomas Deiß    +
+ 14-08-2008 15:33    +
+ 		+ + + + +
+ Resolution proposal for part6 uploaded.
+This contains a few additional minor corrections on the TCI.
+
+
+
+
+ + + + + + + + + + +
+ (0006539) +
+ Ina Schieferdecker    +
+ 15-08-2008 08:24    +
+ 		+ + + + +
+ Some rewording.
+
+ + diff --git a/docs/mantis/CR3966.md b/docs/mantis/CR3966.md new file mode 100644 index 0000000000000000000000000000000000000000..ff025e49a052d81bfbf69ef7a27ea1a40d0646ce --- /dev/null +++ b/docs/mantis/CR3966.md @@ -0,0 +1,112 @@ + + + + + + + + + + + + + 0003966: all/any component in tciStopTestComponentReq - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0003966Part 06: TTCN-3 Control InterfaceClarificationpublic14-08-2008 15:2214-12-2008 10:57
ReporterThomas Deiß 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)part 6, 7.3.3.2.15
Source (company - Author) Nokia Siemens Networks -- Thomas Deiß
Summary0003966: all/any component in tciStopTestComponentReq
DescriptionThe operation tciStopTestComponentReq (TE->SA) has a triComponentId as parameter. But this operation could also be used to indicate that all components have to be stopped. It is unclear which entity should resolve this to individual operations to stop specific test components.
+
+This could either be the TE that contains the MTC or it could be the CH. In the latter case it is not quite clear how the information that all components are to be stopped is passed from the TE to the CH. A possibility in the second case is to use 'any' or 'all' as type name in the parameter of type triComponentId. Note that neither 'any' nor 'all' is a type name that can be defined in TTCN-3 code.
+
+The same problem occurs for the operations
+tciKillTestComponentReq (all)
+tciTestComponentAliveReq (any/all)
+tciTestComponentTerminatedReq (any/all)
+tciTestComponentRunningReq (any/all)
+tciTestComponentDoneReq (any/all)
+tciDisconnectReq (all)
+tciUnmapReq (all)
+
+If the TE containing the MTC has to resolve the TTCN-3 operation into individual calls, then the TE has to forward each operation indicating a change of the status of a component or connection to this specific TE.
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR3966_AnyAllComponent.doc (24,576) 12-12-2008 15:29
http://oldforge.etsi.org/mantis/file_download.php?file_id=1891&type=bug
Issue History
Date ModifiedUsernameFieldChange
14-08-2008 15:22Thomas DeißNew Issue
14-08-2008 15:22Thomas DeißStatusnew => assigned
14-08-2008 15:22Thomas DeißAssigned To => Ina Schieferdecker
14-08-2008 15:22Thomas DeißClause Reference(s) => part 6, 7.3.3.2.15
14-08-2008 15:22Thomas DeißSource (company - Author) => Nokia Siemens Networks -- Thomas Deiß
17-08-2008 09:09Ina SchieferdeckerProjectTTCN-3 Change Requests => Part 06: TTCN-3 Control Interface
17-08-2008 09:09Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
12-12-2008 15:29Ina SchieferdeckerFile Added: CR3966_AnyAllComponent.doc
12-12-2008 15:29Ina SchieferdeckerNote Added: 0007687
12-12-2008 15:29Ina SchieferdeckerResolutionopen => fixed
12-12-2008 15:29Ina SchieferdeckerAssigned ToIna Schieferdecker => Thomas Deiß
12-12-2008 20:06Thomas DeißNote Added: 0007697
12-12-2008 20:06Thomas DeißAssigned ToThomas Deiß => Ina Schieferdecker
14-12-2008 10:57Ina SchieferdeckerStatusassigned => resolved
14-12-2008 10:57Ina SchieferdeckerFixed in Version => Edition 4.1.1 (not yet published)
14-12-2008 10:57Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0007687) +
+ Ina Schieferdecker    +
+ 12-12-2008 15:29    +
+ 		+ + + + +
+ In order to enable an resolution of any/all within the CH, the CR should be resolved along the proposed solution as this requires no change to the execution interfaces in TTCN-3. The usage of TriComponentId should be extended as described. Please check.
+
+
+
+ + + + + + + + + + +
+ (0007697) +
+ Thomas Deiß    +
+ 12-12-2008 20:06    +
+ 		+ + + + +
+ ok.
+
+
+ + diff --git a/docs/mantis/CR3968.md b/docs/mantis/CR3968.md new file mode 100644 index 0000000000000000000000000000000000000000..45a91d469b8c28e262b4aa0a10cfd2fbc7ba883b --- /dev/null +++ b/docs/mantis/CR3968.md @@ -0,0 +1,86 @@ + + + + + + + + + + + + + 0003968: No value redirect in check operation - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0003968Part 01: TTCN-3 Core LanguageTechnicalpublic15-08-2008 09:0926-11-2008 14:55
ReporterGyorgy Rethy 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.3.2 (published 2008-04) 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)22.4
Source (company - Author)L.M.Ericsson
Summary0003968: No value redirect in check operation
DescriptionIn clause 22.4 the following syntactical structure is given:
+Syntactical Structure
+( Port | any port ) "." check
+[ "("
+( PortReceiveOp | PortGetCallOp | PortGetReplyOp | PortCatchOp ) |
+( [ from AddressRef ] [ "->" value VariableRef ][ sender VariableRef ] )
+")" ]
+
+According to the bnf it should be (no value redirect):
+( Port | any port ) "." check
+[ "("
+( PortReceiveOp | PortGetCallOp | PortGetReplyOp | PortCatchOp ) |
+( [ from AddressRef ] [ "->" sender VariableRef ] )
+")" ]
+All other value, sender and parameter redirects are part of the relevant receiving operation.
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
15-08-2008 09:09Gyorgy RethyNew Issue
15-08-2008 09:09Gyorgy RethyStatusnew => assigned
15-08-2008 09:09Gyorgy RethyAssigned To => Ina Schieferdecker
15-08-2008 09:09Gyorgy RethyClause Reference(s) => 22.4
15-08-2008 09:09Gyorgy RethySource (company - Author) => L.M.Ericsson
17-08-2008 09:08Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
26-11-2008 14:53Ina SchieferdeckerNote Added: 0007451
26-11-2008 14:54Ina SchieferdeckerResolutionopen => fixed
26-11-2008 14:55Ina SchieferdeckerStatusassigned => resolved
26-11-2008 14:55Ina SchieferdeckerFixed in Version => Edition 4.1.1 (not yet published)
26-11-2008 14:55Ina SchieferdeckerStatusresolved => closed
10-12-2008 14:05Ina SchieferdeckerNote Edited: 0007451
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0007451) +
+ Ina Schieferdecker    +
+ 26-11-2008 14:53    +
(edited on: 10-12-2008 14:05)
+ 		+ + + + +
+ That is right. The syntactical structure for check should be corrected accordingly:
+
+( Port | any port ) "." check
+[ "("
+        ( PortReceiveOp | PortGetCallOp | PortGetReplyOp | PortCatchOp ) |
+        ( [ from AddressRef ] [ "->" sender VariableRef ] )
+")" ]
+
+
+
+ + diff --git a/docs/mantis/CR3969.md b/docs/mantis/CR3969.md new file mode 100644 index 0000000000000000000000000000000000000000..6b6d51ab4b397dc68724089630cf53b197cba91c --- /dev/null +++ b/docs/mantis/CR3969.md @@ -0,0 +1,72 @@ + + + + + + + + + + + + + 0003969: Uncomplete formulation of the check operation - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0003969Part 01: TTCN-3 Core LanguageClarificationpublic15-08-2008 09:5110-12-2008 14:39
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionwon't fix 
PlatformOSOS Version
Product Versionv3.3.2 (published 2008-04) 
Target Versionv4.1.1 (published 2009-06)Fixed in Version 
Clause Reference(s)22.4
Source (company - Author)L.M.Ericsson
Summary0003969: Uncomplete formulation of the check operation
Description2nd paragraph of clause 22.4 says:
+"The receiving operations receive, getcall, getreply and catch together with their matching and assignment parts, are used by the check operation to define the condition that has to be checked and to extract the value or values of its parameters, if required."
+
+However, not only parameter but also value and sender redirects may be specified by the enclosed receiving operation. See additional information for a proposal.
Steps To Reproduce
Additional InformationThe receiving operations receive, getcall, getreply and catch together with their matching and value, sender or parameter storing parts, are used by the check operation to define the condition that has to be checked and the information to be optionally extracted.
+It is the top element of an incoming port queue that shall be checked (it is not possible to look into the queue). If the queue is empty the check operation fails. If the queue is not empty, a copy of the top element is taken and the receiving operation specified in the check operation is performed on the copy. The check operation fails if the receiving operation fails i.e. the matching criteria are not fulfilled. In this case the copy of the top element of the queue is discarded and test execution continues in the normal manner, i.e. the statement or alternative next to the check operation is evaluated. The check operation is successful if the receiving operation is successful. In this case the value, sender or parameter storing parts of the receiving operation, if any, are executed, i.e. the message and/or a part of it, the sender's address or component reference, the parameter(s) of the call or reply or the value of the exception are stored in the associated variables.
+
TagsNo tags attached.
Relationships
Attached Filesdoc CR3969_CheckOperation.doc (34,816) 24-11-2008 12:18
http://oldforge.etsi.org/mantis/file_download.php?file_id=1760&type=bug
Issue History
Date ModifiedUsernameFieldChange
15-08-2008 09:51Gyorgy RethyNew Issue
15-08-2008 09:51Gyorgy RethyStatusnew => assigned
15-08-2008 09:51Gyorgy RethyAssigned To => Ina Schieferdecker
15-08-2008 09:51Gyorgy RethyClause Reference(s) => 22.4
15-08-2008 09:51Gyorgy RethySource (company - Author) => L.M.Ericsson
17-08-2008 09:07Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
24-11-2008 12:17Ina SchieferdeckerNote Added: 0007388
24-11-2008 12:18Ina SchieferdeckerFile Added: CR3969_CheckOperation.doc
24-11-2008 12:19Ina SchieferdeckerResolutionopen => won't fix
24-11-2008 12:19Ina SchieferdeckerAssigned ToIna Schieferdecker => Gyorgy Rethy
26-11-2008 10:09Gyorgy RethyStatusassigned => closed
10-12-2008 14:38Ina SchieferdeckerNote Added: 0007638
10-12-2008 14:39Ina SchieferdeckerFile Added: CR2757_proposed_solution_v1_5.doc
10-12-2008 14:39Ina SchieferdeckerNote Deleted: 0007638
10-12-2008 14:39Ina SchieferdeckerFile Deleted: CR2757_proposed_solution_v1_5.doc
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0007388) +
+ Ina Schieferdecker    +
+ 24-11-2008 12:17    +
+ 		+ + + + +
+ The semantic description for the check operation refers to both the receiving and the assignment part of a receiving operation - the receiving part includes the address expression - the sender redirect is included in the assignment part - see 22.1.4.2.
+
+Hence, no change is needed.
+
+I just did two rephrasal - one in particular highlighting that not a single condition but all conditions defined by the receiving operation are to be checked.
+
+ + diff --git a/docs/mantis/CR3970.md b/docs/mantis/CR3970.md new file mode 100644 index 0000000000000000000000000000000000000000..efb45100fc76c690099683cc385b0644a33619d9 --- /dev/null +++ b/docs/mantis/CR3970.md @@ -0,0 +1,159 @@ + + + + + + + + + + + + + 0003970: Type compatibility not defined for union types - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0003970Part 01: TTCN-3 Core LanguageClarificationpublic15-08-2008 10:0009-12-2008 16:37
ReporterThomas Deiß 
Assigned ToIna Schieferdecker 
PrioritynormalSeveritymajorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)part 1, 6.3
Source (company - Author)Nokia Siemens Networks, Thomas Deiß
Summary0003970: Type compatibility not defined for union types
DescriptionPart 1 does not explain when a value of a union type is compatible with another union type. Neither does it state that union types are not compatible to each other.
+
+type union U {integer i};
+type union V {integer i, boolean b};
+
+...
+var U u := {i := 1};
+var V v := u; // correct??
+var anytype w := u; // correct??
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR3970_UnionCompatibility.doc (55,296) 24-11-2008 11:54
http://oldforge.etsi.org/mantis/file_download.php?file_id=1758&type=bug
doc CR3970_UnionCompatibility_02.doc (51,712) 27-11-2008 08:49
http://oldforge.etsi.org/mantis/file_download.php?file_id=1810&type=bug
Issue History
Date ModifiedUsernameFieldChange
15-08-2008 10:00Thomas DeißNew Issue
15-08-2008 10:00Thomas DeißClause Reference(s) => part 1, 6.3
15-08-2008 10:00Thomas DeißSource (company - Author) => Nokia Siemens Networks, Thomas Deiß
15-08-2008 10:01Thomas DeißStatusnew => assigned
15-08-2008 10:01Thomas DeißAssigned To => Ina Schieferdecker
17-08-2008 09:06Ina SchieferdeckerProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
17-08-2008 09:07Ina SchieferdeckerCategoryTTCN-3 Core Language => Clarification
17-08-2008 09:07Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
24-11-2008 11:54Ina SchieferdeckerFile Added: CR3970_UnionCompatibility.doc
24-11-2008 11:54Ina SchieferdeckerAssigned ToIna Schieferdecker => Gyorgy Rethy
24-11-2008 11:55Ina SchieferdeckerNote Added: 0007386
26-11-2008 13:48Gyorgy RethyNote Added: 0007447
26-11-2008 13:49Gyorgy RethyNote Edited: 0007447
26-11-2008 13:49Gyorgy RethyAssigned ToGyorgy Rethy => Thomas Deiß
27-11-2008 08:49Thomas DeißFile Added: CR3970_UnionCompatibility_02.doc
27-11-2008 08:53Thomas DeißNote Added: 0007466
27-11-2008 08:53Thomas DeißAssigned ToThomas Deiß => Ina Schieferdecker
09-12-2008 16:37Ina SchieferdeckerStatusassigned => resolved
09-12-2008 16:37Ina SchieferdeckerResolutionopen => fixed
09-12-2008 16:37Ina SchieferdeckerFixed in Version => Edition 4.1.1 (not yet published)
09-12-2008 16:37Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0007386) +
+ Ina Schieferdecker    +
+ 24-11-2008 11:55    +
+ 		+ + + + +
+ Please check.
+
+
+
+ + + + + + + + + + +
+ (0007447) +
+ Gyorgy Rethy    +
+ 26-11-2008 13:48    +
(edited on: 26-11-2008 13:49)
+ 		+ + + + +
+ I agree to add the clause to the standard, but... Is
+type union U1 {integer i};
+type union U2 {integer i (0..1), boolean b};
+
+function f( U1 p_u1) {
+    var U2 u2 := p_u1; // also correct?
+}
+We will know this only runtime. In this case either
+ - no need for identical fields for ALL fields of U1 in U2, enough if the selected field is compatible,
+or
+ - the type of all identical fields of U2 shall be the same or subtypes the corresponding fields in U2. I.e. the above example becomes incorrect, but we gain compile time check-ability. In this case the correct example is
+type union U1 {integer i(0..1)};
+type union U2 {integer i, boolean b};
+
+function f( U1 p_u1) {
+    var U2 u2 := p_u1; // also correct?
+}
+
+I vote for the 2nd solution and propose to change also existing compatibility rules accordingly.
+
+
+
+
+
+ + + + + + + + + + +
+ (0007466) +
+ Thomas Deiß    +
+ 27-11-2008 08:53    +
+ 		+ + + + +
+ I suggest to stick to the proposed solution with identical definitions. Otherwise the definitions on unselected fields would impact the type compatibility. Also, we would have to compare the type definitions to decide whether a value is compatible with a type.
+
+ + diff --git a/docs/mantis/CR4057.md b/docs/mantis/CR4057.md new file mode 100644 index 0000000000000000000000000000000000000000..e337e70b479b06e244f15af12d006a145d938f76 --- /dev/null +++ b/docs/mantis/CR4057.md @@ -0,0 +1,110 @@ + + + + + + + + + + + + + 0004057: unary + undefined - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0004057Part 01: TTCN-3 Core LanguageClarificationpublic29-08-2008 04:1410-12-2008 12:22
ReporterThomas Deiß 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)part 1, 7.1.1
Source (company - Author)Nokia Siemens Networks, Thomas Deiß
Summary0004057: unary + undefined
DescriptionThe meaning of the unary + operator is not defined in the standard (the unary minus is defined).
+
+In the example
+var integer x := -3;
+var integer y;
+y := +x;
+
+what is the value of y after the assignment? Is it 3 or is -3? I.e. does the unary + does have any effect?
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
29-08-2008 04:14Thomas DeißNew Issue
29-08-2008 04:14Thomas DeißStatusnew => assigned
29-08-2008 04:14Thomas DeißAssigned To => Ina Schieferdecker
29-08-2008 04:14Thomas DeißClause Reference(s) => part 1, 7.1.1
29-08-2008 04:14Thomas DeißSource (company - Author) => Nokia Siemens Networks, Thomas Deiß
19-09-2008 07:16Thomas DeißProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
25-11-2008 12:42Ina SchieferdeckerNote Added: 0007404
25-11-2008 12:43Ina SchieferdeckerAssigned ToIna Schieferdecker => Thomas Deiß
25-11-2008 12:43Ina SchieferdeckerResolutionopen => fixed
25-11-2008 12:43Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
26-11-2008 08:09Thomas DeißNote Added: 0007435
26-11-2008 08:09Thomas DeißAssigned ToThomas Deiß => Ina Schieferdecker
10-12-2008 12:22Ina SchieferdeckerStatusassigned => resolved
10-12-2008 12:22Ina SchieferdeckerFixed in Version => Edition 4.1.1 (not yet published)
10-12-2008 12:22Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0007404) +
+ Ina Schieferdecker    +
+ 25-11-2008 12:42    +
+ 		+ + + + +
+ In 7.1.1 Arithmetic operators, the following should be added:
+
+"In the case where plus (+) or minus (-) is used as the unary operator the rules for operands apply as well. The result of using the minus operator is the negative value of the operand if it was positive and vice versa."
+
+-->
+
+"In the case where plus (+) or minus (-) is used as the unary operator the rules for operands apply as well. The result of using the minus operator is the negative value of the operand if it was positive and vice versa. The result of using the plus operator is the value of the operand, i.e. a positive value if the operand value was positive and a negative value if the operand value was negative."
+
+
+
+ + + + + + + + + + +
+ (0007435) +
+ Thomas Deiß    +
+ 26-11-2008 08:09    +
+ 		+ + + + +
+ ok.
+
+ + diff --git a/docs/mantis/CR4076.md b/docs/mantis/CR4076.md new file mode 100644 index 0000000000000000000000000000000000000000..fa830ea4ecf08004d04b99214eb2cd0a815c1195 --- /dev/null +++ b/docs/mantis/CR4076.md @@ -0,0 +1,100 @@ + + + + + + + + + + + + + 0004076: TTCN-3 supports lower case hex digits - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0004076Part 09: Using XML with TTCN-3Technicalpublic02-09-2008 10:0817-10-2008 09:03
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)6.2.10
For STF discussion
Source (company - Author)     
Summary0004076: TTCN-3 supports lower case hex digits
DescriptionClause 6.2.10 Hexadecimal binary contains the following sentence:
+"A translation has to be aware of the fact that XSD hexBinary allows for the usage of lowercase letters (a, b, c, d, e, and f) for specification of values. These need to be converted to upper case for TTCN-3."
+
+According to clause 6.1.1 of Part-1, TTCN-3 supports both lower and upper case hexadecimal digits, hence the above requirements is superfluous. The above sentence should be deleted.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
02-09-2008 10:08Gyorgy RethyNew Issue
02-09-2008 10:08Gyorgy RethyStatusnew => assigned
02-09-2008 10:08Gyorgy RethyAssigned To => Gyorgy Rethy
02-09-2008 10:08Gyorgy RethyClause Reference(s) => 6.2.10
02-09-2008 10:08Gyorgy RethySource (company - Author) =>
15-10-2008 10:05Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
15-10-2008 13:48Ina SchieferdeckerNote Added: 0007069
15-10-2008 13:48Ina SchieferdeckerAssigned ToIna Schieferdecker => Gyorgy Rethy
15-10-2008 13:48Ina SchieferdeckerResolutionopen => fixed
15-10-2008 13:48Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
17-10-2008 09:03Gyorgy RethyStatusassigned => closed
17-10-2008 09:03Gyorgy RethyNote Added: 0007113
17-10-2008 09:03Gyorgy RethyFixed in Version => Edition 4.1.1 (not yet published)
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0007069) +
+ Ina Schieferdecker    +
+ 15-10-2008 13:48    +
+ 		+ + + + +
+ Proposed solution is ok and should be implemented.
+
+
+
+ + + + + + + + + + +
+ (0007113) +
+ Gyorgy Rethy    +
+ 17-10-2008 09:03    +
+ 		+ + + + +
+ CR implemented, sentence has been deleted from master copy
+
+ + diff --git a/docs/mantis/CR4102.md b/docs/mantis/CR4102.md new file mode 100644 index 0000000000000000000000000000000000000000..89abc8599824484773bd409a8e2801097cbdd8a2 --- /dev/null +++ b/docs/mantis/CR4102.md @@ -0,0 +1,201 @@ + + + + + + + + + + + + + 0004102: ITU Editorial Issues - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0004102Part 01: TTCN-3 Core LanguageClarificationpublic09-09-2008 03:4906-10-2008 05:50
ReporterIna Schieferdecker 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)Several
Source (company - Author)     
Summary0004102: ITU Editorial Issues
Description> *From: * Gachet, Christelle
+> *Sent: * 2008年8月26日 10:40
+> *To: * Yang, Xiaoya; Sebek, Boguslaw Georges
+> *Cc: * TSBSG17, ITU; PEPedit, ITU; Trabulsi, Sami; Ratta, Greg
+> *Subject: * [ref9265E] ITU-T Recommendation Z.161 (13.11.2007)
+> editorial problems
+> *Importance: * High
+>
+> Any news ...
+>
+>
+> ______________________________________________
+> *From: * Gachet, Christelle [_mailto:Christelle.Gachet@itu.int_]
+> *Sent: * jeudi, 3. juillet 2008 07:14
+> *To: * Yang, Xiaoya; Sebek, Boguslaw Georges
+> *Cc: * TSBSG17, ITU; PEPedit, ITU; Trabulsi, Sami; Ratta, Greg
+> *Subject: * [ref9265E] ITU-T Recommendation Z.161 (13.11.2007)
+> editorial problems
+>
+> Hello Xiaoya,
+>
+> 1) Clause 7, syntactical structure, a right parenthesis is missing:
+> /SingleExpression/ |
+> "{" { (/ FieldReference/ ":=" ( Expression | "-" ) [","] } "}" | //
+> compound expression
+> "{" [ { ( Expression | "-" ) [","] } ] "}"
+> // compound expression
+>
+> 2) Clause 9.2, ,syntactical structure, should the vertical lines be
+> placed after each instance? Same applies for clause 9.3
+>
+> *type** component*/ ComponentTypeIdentifier/ "{"
+> { (/ PortInstance/
+> |/ VarInstance/
+> |/ TimerInstance/
+> |/ ConstDef/ ) }
+> "}"
+>
+> 3) Clause 21.1.1, 2nd paragraph after semantic description, there's a
+> reference in parenthesis to clause 22.4. Is it the right one ?
+>
+> 4) Clause 21.2.5, syntactical structure, a left parenthesis is missing.
+> Same applies for clauses 21.2.6 to 21.2.8
+>
+> 5) Clause 22.3.1, syntactical structure, there's an extra right square
+> bracket. Is it ok ?
+>
+> 6) Table 20, is the heading of the table "Port operations" and not
+> "Timer operations" ?
+>
+> 7) Clause 26.1, semantic description, is the reference to clause 27.1
+> correct ?
+>
+> 8) Annex A, numbers were following in Z.140 (2006). In this version,
+> each definition starts with an "1". Is it correct ?
+>
+> 9) Annexes D and E are informative. If we follow the ITU-T Guide,
+> annexes are normative and Appendices are informative. Should these two
+> annexes be renamed as Appendices I and II ?
+>
+> 10) Figure E3 is the same as Figure E.2. Could you provide the right one?
+>
+> Thanks
+> Regards
+>
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Fileshtm RE ref9265E ITU-T Recommendation Z.161 (13.11.2007) editorial problems.htm (7,630) 09-09-2008 03:51
http://oldforge.etsi.org/mantis/file_download.php?file_id=1629&type=bug
Issue History
Date ModifiedUsernameFieldChange
09-09-2008 03:49Ina SchieferdeckerNew Issue
09-09-2008 03:49Ina SchieferdeckerStatusnew => assigned
09-09-2008 03:49Ina SchieferdeckerAssigned To => Ina Schieferdecker
09-09-2008 03:49Ina SchieferdeckerClause Reference(s) => Several
09-09-2008 03:49Ina SchieferdeckerSource (company - Author) =>
09-09-2008 03:51Ina SchieferdeckerFile Added: RE ref9265E ITU-T Recommendation Z.161 (13.11.2007) editorial problems.htm
09-09-2008 03:51Ina SchieferdeckerProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
09-09-2008 03:52Ina SchieferdeckerNote Added: 0006754
09-09-2008 03:52Ina SchieferdeckerAssigned ToIna Schieferdecker => Thomas Deiß
09-09-2008 03:52Ina SchieferdeckerResolutionopen => fixed
09-09-2008 03:52Ina SchieferdeckerCategoryTTCN-3 Core Language => Clarification
09-09-2008 03:52Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
30-09-2008 01:31Thomas DeißNote Added: 0006931
30-09-2008 01:31Thomas DeißAssigned ToThomas Deiß => Ina Schieferdecker
06-10-2008 05:50Ina SchieferdeckerNote Added: 0006996
06-10-2008 05:50Ina SchieferdeckerStatusassigned => closed
06-10-2008 05:50Ina SchieferdeckerFixed in Version => Edition 4.1.1 (not yet published)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0006754) +
+ Ina Schieferdecker    +
+ 09-09-2008 03:52    +
+ 		+ + + + +
+ Corrections to be checked by somebody else
+
+
+
+ + + + + + + + + + +
+ (0006931) +
+ Thomas Deiß    +
+ 30-09-2008 01:31    +
+ 		+ + + + +
+ issue 6: table with header 'port operations' vs. 'timer operations'. In edition 3.4, table 23. The 1st row should read 'port operations' instead of 'timer operations'. Incorrect answer provided to ITU.
+
+issue 8: In Annex A, there is only A.1, but no A.2. One could argue that one level of heading is superfluous.
+
+
+
+
+ + + + + + + + + + +
+ (0006996) +
+ Ina Schieferdecker    +
+ 06-10-2008 05:50    +
+ 		+ + + + +
+ Issue 6: it's a typo in the answer: I corrected into port operations ;-)
+
+Issue 8: I guess we should not change this as it is used like this for long time.
+
+ + diff --git a/docs/mantis/CR4153.md b/docs/mantis/CR4153.md new file mode 100644 index 0000000000000000000000000000000000000000..a3448eac4415a7f8450c0ba0a96f4930c7518e4f --- /dev/null +++ b/docs/mantis/CR4153.md @@ -0,0 +1,104 @@ + + + + + + + + + + + + + 0004153: no templates for signatures (misleading sentence) - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0004153Part 01: TTCN-3 Core LanguageEditorialpublic18-09-2008 03:3209-12-2008 19:37
ReporterThomas Deiß 
Assigned ToIna Schieferdecker 
PrioritylowSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.3.2 (published 2008-04) 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)part1, 15.3
Source (company - Author)Nokia Siemens Networks, Thomas Deiß
Summary0004153: no templates for signatures (misleading sentence)
DescriptionRestriction a) in clause 15.3 states:
+a) Templates may be specified for any TTCN 3 type defined in table 3 except for port and default types and for any procedure signature.
+
+This can be interpreted such that no templates can be written for procedure signature. I suggest to break the sentence in two parts:
+
+Templates may be specified for any TTCN 3 type defined in table 3 except for port and default types. Templates may be specified for any TTCN 3 procedure signature.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
18-09-2008 03:32Thomas DeißNew Issue
18-09-2008 03:32Thomas DeißStatusnew => assigned
18-09-2008 03:32Thomas DeißAssigned To => Ina Schieferdecker
18-09-2008 03:32Thomas DeißClause Reference(s) => part1, 15.3
18-09-2008 03:32Thomas DeißSource (company - Author) => Nokia Siemens Networks, Thomas Deiß
25-11-2008 13:23Ina SchieferdeckerNote Added: 0007408
25-11-2008 13:24Ina SchieferdeckerAssigned ToIna Schieferdecker => Thomas Deiß
25-11-2008 13:24Ina SchieferdeckerResolutionopen => fixed
25-11-2008 13:24Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
26-11-2008 09:05Thomas DeißNote Added: 0007439
26-11-2008 09:05Thomas DeißAssigned ToThomas Deiß => Ina Schieferdecker
09-12-2008 19:37Ina SchieferdeckerStatusassigned => resolved
09-12-2008 19:37Ina SchieferdeckerFixed in Version => Edition 4.1.1 (not yet published)
09-12-2008 19:37Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0007408) +
+ Ina Schieferdecker    +
+ 25-11-2008 13:23    +
+ 		+ + + + +
+ Corrected typos:
+
+"Templates may be specified for any TTCN-3 type defined in table 3 except for port and default types. Templates may also be specified for any procedure signature."
+
+
+
+ + + + + + + + + + +
+ (0007439) +
+ Thomas Deiß    +
+ 26-11-2008 09:05    +
+ 		+ + + + +
+ ok.s
+
+ + diff --git a/docs/mantis/CR4155.md b/docs/mantis/CR4155.md new file mode 100644 index 0000000000000000000000000000000000000000..a8755ac2b070c5154ab03a22d569797302c45217 --- /dev/null +++ b/docs/mantis/CR4155.md @@ -0,0 +1,135 @@ + + + + + + + + + + + + + 0004155: Clarification on the order of assignments - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0004155Part 01: TTCN-3 Core LanguageClarificationpublic18-09-2008 04:1409-12-2008 18:19
ReporterThomas Deiß 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.3.2 (published 2008-04) 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)part 1, 19.1
Source (company - Author)Nokia Siemens Networks, Thomas Deiß
Summary0004155: Clarification on the order of assignments
DescriptionClause 19.1 on assignments contains a statement "All assignments occur in the order in which they appear, that is left to right processing."
+
+Obviously, assignments occur in the order in which they appear. So, what is the intended meaning? Assignments are processed in the order in which they appear? Does this mean that the left hand side is processed before the right hand side?
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0003383closed Ina Schieferdecker Order of assignments of fields 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
18-09-2008 04:14Thomas DeißNew Issue
18-09-2008 04:14Thomas DeißStatusnew => assigned
18-09-2008 04:14Thomas DeißAssigned To => Ina Schieferdecker
18-09-2008 04:14Thomas DeißClause Reference(s) => part 1, 19.1
18-09-2008 04:14Thomas DeißSource (company - Author) => Nokia Siemens Networks, Thomas Deiß
18-09-2008 04:16Thomas DeißRelationship addedrelated to 0003383
25-11-2008 12:59Ina SchieferdeckerNote Added: 0007407
25-11-2008 12:59Ina SchieferdeckerAssigned ToIna Schieferdecker => Thomas Deiß
25-11-2008 12:59Ina SchieferdeckerResolutionopen => fixed
25-11-2008 12:59Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
26-11-2008 11:43Thomas DeißNote Added: 0007445
26-11-2008 11:43Thomas DeißAssigned ToThomas Deiß => Ina Schieferdecker
09-12-2008 18:19Ina SchieferdeckerNote Added: 0007613
09-12-2008 18:19Ina SchieferdeckerStatusassigned => resolved
09-12-2008 18:19Ina SchieferdeckerFixed in Version => Edition 4.1.1 (not yet published)
09-12-2008 18:19Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0007407) +
+ Ina Schieferdecker    +
+ 25-11-2008 12:59    +
+ 		+ + + + +
+ The sentence should be reworded into:
+
+"All assignments are processed in the order in which they appear, that is left to right processing obeying the operator precedence defined in Table 6."
+
+
+
+ + + + + + + + + + +
+ (0007445) +
+ Thomas Deiß    +
+ 26-11-2008 11:43    +
+ 		+ + + + +
+ ok.
+
+
+
+ + + + + + + + + + +
+ (0007613) +
+ Ina Schieferdecker    +
+ 09-12-2008 18:19    +
+ 		+ + + + +
+ Fixed along the resolution for CR3383.
+
+ + diff --git a/docs/mantis/CR4160.md b/docs/mantis/CR4160.md new file mode 100644 index 0000000000000000000000000000000000000000..cc1549a7567a1f9fe98e98e554980e0b1b5ab5f3 --- /dev/null +++ b/docs/mantis/CR4160.md @@ -0,0 +1,104 @@ + + + + + + + + + + + + + 0004160: start operation / in parameter - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0004160Part 01: TTCN-3 Core LanguageEditorialpublic19-09-2008 07:1509-12-2008 17:00
ReporterThomas Deiß 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)part 1, 5.4.1.1
Source (company - Author)Nokia Siemens Networks, Thomas Deiss
Summary0004160: start operation / in parameter
Descriptionrestriction b) in clause 5.4.1.1) states
+b) Formal value parameters of types, of templates, of functions started as test component behaviour (see clause 21.2.2) and of altsteps activated as defaults (see clause 20.5.2) shall always be in parameters.
+
+This limitation is no longer required in edition 3.4.1. There the out direction is simply ignored
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
19-09-2008 07:15Thomas DeißNew Issue
19-09-2008 07:15Thomas DeißStatusnew => assigned
19-09-2008 07:15Thomas DeißAssigned To => Ina Schieferdecker
19-09-2008 07:15Thomas DeißClause Reference(s) => part 1, 5.4.1.1
19-09-2008 07:15Thomas DeißSource (company - Author) => Nokia Siemens Networks, Thomas Deiss
19-09-2008 07:16Thomas DeißProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
25-11-2008 12:50Ina SchieferdeckerNote Added: 0007406
25-11-2008 12:50Ina SchieferdeckerAssigned ToIna Schieferdecker => Thomas Deiß
25-11-2008 12:50Ina SchieferdeckerResolutionopen => fixed
25-11-2008 12:50Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
26-11-2008 08:01Thomas DeißNote Added: 0007433
26-11-2008 08:01Thomas DeißAssigned ToThomas Deiß => Ina Schieferdecker
09-12-2008 17:00Ina SchieferdeckerStatusassigned => resolved
09-12-2008 17:00Ina SchieferdeckerFixed in Version => Edition 4.1.1 (not yet published)
09-12-2008 17:00Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0007406) +
+ Ina Schieferdecker    +
+ 25-11-2008 12:50    +
+ 		+ + + + +
+ Indeed, the limitation for start does not hold any more, the one for activate does - see 20.5.2.
+
+Hence, the restriction should say:
+
+"b) Formal value parameters of types, of templates, and of altsteps activated as defaults (see clause 20.5.2) shall always be in parameters."
+
+
+
+ + + + + + + + + + +
+ (0007433) +
+ Thomas Deiß    +
+ 26-11-2008 08:01    +
+ 		+ + + + +
+ ok.
+
+ + diff --git a/docs/mantis/CR4185.md b/docs/mantis/CR4185.md new file mode 100644 index 0000000000000000000000000000000000000000..022c2d1ed5a3a400b02c16d3c00189da966fa1ce --- /dev/null +++ b/docs/mantis/CR4185.md @@ -0,0 +1,71 @@ + + + + + + + + + + + + + 0004185: Clarify using length matchin attribute with charstrings - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0004185Part 01: TTCN-3 Core LanguageClarificationpublic25-09-2008 06:4410-12-2008 09:11
ReporterGyorgy Rethy 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)15.7, B.1.4.1
Source (company - Author)L.M. Ericsson
Summary0004185: Clarify using length matchin attribute with charstrings
DescriptionThough clauses B.1.3.1 and B.1.3.2 specify clearly that "?" and "*" do not have matching mechanism meaning within character strings (but within patterns), there are a few places in Part 1 causing confusions:
+- table 9 does not specify clearly the use of these matchings with char. strings
+- an example in clause B.1.4.1
+
+Also, the text of B.1.4.1 does not allow using length together with pattern, while this is allowed by Table 9 and also length restriction can be used with pattern subtyping.
Steps To Reproduce
Additional InformationSee attached file
TagsNo tags attached.
Relationships
Attached Filesdoc CRxxx-using length with patterns.doc (404,480) 25-09-2008 06:44
http://oldforge.etsi.org/mantis/file_download.php?file_id=1647&type=bug
Issue History
Date ModifiedUsernameFieldChange
25-09-2008 06:44Gyorgy RethyNew Issue
25-09-2008 06:44Gyorgy RethyStatusnew => assigned
25-09-2008 06:44Gyorgy RethyAssigned To => Ina Schieferdecker
25-09-2008 06:44Gyorgy RethyFile Added: CRxxx-using length with patterns.doc
25-09-2008 06:44Gyorgy RethyClause Reference(s) => 15.7, B.1.4.1
25-09-2008 06:44Gyorgy RethySource (company - Author) => L.M. Ericsson
07-10-2008 06:49Ina SchieferdeckerNote Added: 0007008
07-10-2008 06:50Ina SchieferdeckerStatusassigned => resolved
07-10-2008 06:50Ina SchieferdeckerResolutionopen => fixed
07-10-2008 06:50Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
10-12-2008 09:11Ina SchieferdeckerStatusresolved => closed
10-12-2008 09:11Ina SchieferdeckerFixed in Version => Edition 4.1.1 (not yet published)
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0007008) +
+ Ina Schieferdecker    +
+ 07-10-2008 06:49    +
+ 		+ + + + +
+ Changed the wording:
+
+field3 := "ab*ab" length(13),
+// never matches as the specific value is of length 5
+// and not of length 13
+
+ + diff --git a/docs/mantis/CR4204.md b/docs/mantis/CR4204.md new file mode 100644 index 0000000000000000000000000000000000000000..12f7bfc764175659fa20767c4c08201d7f735bda --- /dev/null +++ b/docs/mantis/CR4204.md @@ -0,0 +1,100 @@ + + + + + + + + + + + + + 0004204: multidimensional port arrays for TRI - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 05: TTCN-3 Runtime Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0004204Part 05: TTCN-3 Runtime Interface Technicalpublic29-09-2008 05:1912-12-2008 13:11
ReporterThomas Deiß 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.3.1 (published 2008-04) 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)part 5, clause 5.3.1
Source (company - Author)Nokia Siemens Networks, Thomas Deiß
Summary0004204: multidimensional port arrays for TRI
DescriptionPart 1 of the standard allows multidimensional port arrays at the test system interface. Part 5 has only a one-dimensional index for ports. Hence a multidimensional port at the test system interface cannot be properly addressed at the TRI. Actually it cannot be addressed at the TCI either as the TCI refers to the TriPortIdType from part 5.
+
+To my knowledge there is a (proprietary) solution by TestingTech by computing a one dimensional index from the multidimensional one. Bijective mappings are possible for this problem, hence this would solve the problem.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR4202_MultidimensionalPortArrays.doc (30,208) 12-12-2008 11:25
http://oldforge.etsi.org/mantis/file_download.php?file_id=1886&type=bug
Issue History
Date ModifiedUsernameFieldChange
29-09-2008 05:19Thomas DeißNew Issue
29-09-2008 05:19Thomas DeißStatusnew => assigned
29-09-2008 05:19Thomas DeißAssigned To => Ina Schieferdecker
29-09-2008 05:19Thomas DeißClause Reference(s) => part 5, clause 5.3.1
29-09-2008 05:19Thomas DeißSource (company - Author) => Nokia Siemens Networks, Thomas Deiß
12-12-2008 11:01Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
12-12-2008 11:25Ina SchieferdeckerFile Added: CR4202_MultidimensionalPortArrays.doc
12-12-2008 11:26Ina SchieferdeckerNote Added: 0007680
12-12-2008 11:26Ina SchieferdeckerAssigned ToIna Schieferdecker => Thomas Deiß
12-12-2008 11:26Ina SchieferdeckerResolutionopen => fixed
12-12-2008 11:26Ina SchieferdeckerFixed in Version => Edition 4.1.1 (not yet published)
12-12-2008 12:14Thomas DeißNote Added: 0007681
12-12-2008 12:14Thomas DeißAssigned ToThomas Deiß => Ina Schieferdecker
12-12-2008 13:10Ina SchieferdeckerStatusassigned => resolved
12-12-2008 13:11Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0007680) +
+ Ina Schieferdecker    +
+ 12-12-2008 11:26    +
+ 		+ + + + +
+ Please check
+
+
+
+ + + + + + + + + + +
+ (0007681) +
+ Thomas Deiß    +
+ 12-12-2008 12:14    +
+ 		+ + + + +
+ ok.
+
+
+ + diff --git a/docs/mantis/CR4228.md b/docs/mantis/CR4228.md new file mode 100644 index 0000000000000000000000000000000000000000..9c9fb6b00f75d150b22b892715fc7faadaed65d7 --- /dev/null +++ b/docs/mantis/CR4228.md @@ -0,0 +1,145 @@ + + + + + + + + + + + + + 0004228: Syntactical error in pattern example - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0004228Part 09: Using XML with TTCN-3Technicalpublic02-10-2008 05:2717-10-2008 10:40
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.3.1 (published 2008-04) 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)7.5.1
For STF discussion
Source (company - Author)L.M.Ericsson
Summary0004228: Syntactical error in pattern example
Descriptionthe example
+type XSD.String E18 (pattern "((ahi|eho|cre|dve)@(f|F)okus)#(1)")
+is syntactically incorrect (it should be either #(1,1) or #1) but the multiplyer is superflouos anyway.
+
+Proposed to change to
+type XSD.String E18 (pattern "(ahi|eho|cre|dve)@(f|F)okus")
+ 
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
02-10-2008 05:27Gyorgy RethyNew Issue
02-10-2008 05:27Gyorgy RethyStatusnew => assigned
02-10-2008 05:27Gyorgy RethyAssigned To => Gyorgy Rethy
02-10-2008 05:27Gyorgy RethyClause Reference(s) => 7.5.1
02-10-2008 05:27Gyorgy RethySource (company - Author) => L.M.Ericsson
15-10-2008 10:05Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
15-10-2008 14:11Ina SchieferdeckerNote Added: 0007070
15-10-2008 14:11Ina SchieferdeckerAssigned ToIna Schieferdecker => Gyorgy Rethy
15-10-2008 14:11Ina SchieferdeckerResolutionopen => fixed
15-10-2008 14:11Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
17-10-2008 10:40Gyorgy RethyStatusassigned => closed
17-10-2008 10:40Gyorgy RethyNote Added: 0007115
17-10-2008 10:40Gyorgy RethyFixed in Version => Edition 4.1.1 (not yet published)
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0007070) +
+ Ina Schieferdecker    +
+ 15-10-2008 14:11    +
+ 		+ + + + +
+ The proposed solution is ok, but please change the pattern into a more generic one:
+
+In 6.1.4 Pattern (please note also the typo in expression)
+------------------------
+
+EXAMPLE:
+<simpleType name="e6">
+    <restriction base="string">
+        <pattern value="(aUser|anotherUser)@(i|I)nstitute"/>
+    </restriction>
+</simpleType>
+
+Will be mapped to the following TTCN-3 expression:
+
+type XSD.String E6 (pattern "(aUser|anotherUser)@(i|I)nstitute")
+with {
+       variant "name as uncapitalized";
+};
+
+
+7.5.1 Derivation by restriction
+---------------------------------
+
+<simpleType name="e18">
+    <restriction>
+        <simpleType>
+            <restriction base="string"/>
+        </simpleType>
+        <pattern value="(aUser|anotherUser)@(i|I)nstitute"/>
+    </restriction>
+</simpleType>
+
+This will generate a mapping for the inner type and its restriction:
+
+type XSD.String E18 (pattern "(aUser|anotherUser)@(i|I)nstitute")
+with {
+     variant "name as uncapitalized ";
+};
+
+
+In addition, Table 4: Translation of quantifiers has to be corrected:
+
+{n} translates to #n (and not to #(n))
+
+
+
+ + + + + + + + + + +
+ (0007115) +
+ Gyorgy Rethy    +
+ 17-10-2008 10:40    +
+ 		+ + + + +
+ Implemented (pattern as roposed by Ina, Table 4 corrected as well. Added to master copy
+
+ + diff --git a/docs/mantis/CR4229.md b/docs/mantis/CR4229.md new file mode 100644 index 0000000000000000000000000000000000000000..03439c167a992cc7f307f95e4c44245849848b59 --- /dev/null +++ b/docs/mantis/CR4229.md @@ -0,0 +1,97 @@ + + + + + + + + + + + + + 0004229: Identify "XSD" where appropriate - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0004229Part 09: Using XML with TTCN-3Editorialpublic02-10-2008 05:3112-12-2008 11:32
ReporterGyorgy Rethy 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.3.1 (published 2008-04) 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)all
For STF discussion
Source (company - Author)L.M.Ericsson
Summary0004229: Identify "XSD" where appropriate
DescriptionAs both XML schema and TTCN-3 provide type systems (with type derivation, type restrictions etc.), it shall clearly be identified when the text is talking about "XSD <something>" and when about "TTCN-3 <something>".
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
02-10-2008 05:31Gyorgy RethyNew Issue
02-10-2008 05:31Gyorgy RethyStatusnew => assigned
02-10-2008 05:31Gyorgy RethyAssigned To => Gyorgy Rethy
02-10-2008 05:31Gyorgy RethyClause Reference(s) => all
02-10-2008 05:31Gyorgy RethySource (company - Author) => L.M.Ericsson
13-10-2008 09:28Gyorgy RethyNote Added: 0007035
13-10-2008 09:28Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
14-10-2008 17:37Gyorgy RethyNote Added: 0007063
14-10-2008 17:37Gyorgy RethyStatusassigned => closed
14-10-2008 17:37Gyorgy RethyResolutionopen => fixed
14-10-2008 17:37Gyorgy RethyFixed in Version => Edition 4.1.1 (not yet published)
12-12-2008 11:32Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0007035) +
+ Gyorgy Rethy    +
+ 13-10-2008 09:28    +
+ 		+ + + + +
+ Done in version 3.3.2, uploaded for the last MTS meeting
+
+
+
+ + + + + + + + + + +
+ (0007063) +
+ Gyorgy Rethy    +
+ 14-10-2008 17:37    +
+ 		+ + + + +
+ Done in version 3.3.2 provided to MTS#47; "TTCN-3" and "XSD" shall be idenfied where appropriate during further text additions as well.
+
+ + diff --git a/docs/mantis/CR4230.md b/docs/mantis/CR4230.md new file mode 100644 index 0000000000000000000000000000000000000000..7f34c31ddca8e9f16b2134ed2c7f0bb938cdeda4 --- /dev/null +++ b/docs/mantis/CR4230.md @@ -0,0 +1,110 @@ + + + + + + + + + + + + + 0004230: Clarify text on mapping of complexType containing extended simpleContent is unclear - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0004230Part 09: Using XML with TTCN-3Technicalpublic02-10-2008 07:1318-10-2008 16:01
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)7.6.1.1
For STF discussion
Source (company - Author)L.M.Ericsson
Summary0004230: Clarify text on mapping of complexType containing extended simpleContent is unclear
DescriptionThe text of the clause is:
+"When extending simpleContent further attributes may be added to the original type. The example below extends a built-in type by adding an attribute. The mapping result of an extended simpleContent type with added attributes is always a record containing the base type as a field referenced by the reserved name base.
+EXAMPLE:
+..."
+
+It is unclear what the mapping rule is. It is proposed:
+"When extending XSD simpleContent, further XSD attributes may be added to the original type. The base type of the extended simpleContent and the extension XSD attributes shall be mapped as individual fields of the TTCN-3 record type, generated for the enclosing XSD complexType. First the fields corresponding to the extension XSD attributes shall be generated in the order of their occurance in the XSD, followed by the field generated for the extended XSD base type. The field name of the latter shall be "base".
+EXAMPLE: The example below extends a built-in type by adding an XSD attribute
+..."
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
02-10-2008 07:13Gyorgy RethyNew Issue
02-10-2008 07:13Gyorgy RethyStatusnew => assigned
02-10-2008 07:13Gyorgy RethyAssigned To => Gyorgy Rethy
02-10-2008 07:13Gyorgy RethyClause Reference(s) => 7.6.1.1
02-10-2008 07:13Gyorgy RethySource (company - Author) => L.M.Ericsson
13-10-2008 09:31Gyorgy RethySummaryMapping of complexType containing extended simpleContent is unclear => Clarify text on mapping of complexType containing extended simpleContent is unclear
15-10-2008 10:02Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
15-10-2008 14:19Ina SchieferdeckerNote Added: 0007071
15-10-2008 14:19Ina SchieferdeckerAssigned ToIna Schieferdecker => Gyorgy Rethy
15-10-2008 14:19Ina SchieferdeckerResolutionopen => fixed
15-10-2008 14:19Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
18-10-2008 16:01Gyorgy RethyStatusassigned => closed
18-10-2008 16:01Gyorgy RethyNote Added: 0007120
18-10-2008 16:01Gyorgy RethyFixed in Version => Edition 4.1.1 (not yet published)
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0007071) +
+ Ina Schieferdecker    +
+ 15-10-2008 14:19    +
+ 		+ + + + +
+ The proposed solution is ok - just a bit of rewording:
+
+"When extending XSD simpleContent, further XSD attributes may be added to the original type. The base type of the extended simpleContent and the additional XSD attributes shall be mapped to fields of the TTCN-3 record type, which is generated for the enclosing XSD complexType. At first, the fields corresponding to the additional XSD attributes shall be generated in the order of their occurance in the enclosing XSD complexType definition, followed by the field generated for the original type. The field name of the latter shall be "base".
+
+EXAMPLE: ..."
+
+
+
+ + + + + + + + + + +
+ (0007120) +
+ Gyorgy Rethy    +
+ 18-10-2008 16:01    +
+ 		+ + + + +
+ Text including changes from Ina is implemented in master copy.
+
+ + diff --git a/docs/mantis/CR4231.md b/docs/mantis/CR4231.md new file mode 100644 index 0000000000000000000000000000000000000000..540025d6569ad8bfe8abb01575efccd0b25e9d32 --- /dev/null +++ b/docs/mantis/CR4231.md @@ -0,0 +1,101 @@ + + + + + + + + + + + + + 0004231: Sentence on simpleContent is unclear - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0004231Part 09: Using XML with TTCN-3Clarificationpublic02-10-2008 07:3530-10-2008 14:04
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)7.6.1
For STF discussion
Source (company - Author)L.M.Ericsson
Summary0004231: Sentence on simpleContent is unclear
Description$7.6.1 says:
+"A simpleContent component is translated to types that may only have a simpleType as base. It is possible to extend or restrict the base type and to add attributes, but not elements."
+
+The meaning of the sentence is unclear. It is proposed to replace with:
+"An XSD simpleContent component may extend or restrict an XSD simpleType, being the base type of the simpleContent, and may expand the base type with attributes but not with elements."
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
02-10-2008 07:35Gyorgy RethyNew Issue
02-10-2008 07:35Gyorgy RethyStatusnew => assigned
02-10-2008 07:35Gyorgy RethyAssigned To => Gyorgy Rethy
02-10-2008 07:35Gyorgy RethyClause Reference(s) => 7.6.1
02-10-2008 07:35Gyorgy RethySource (company - Author) => L.M.Ericsson
15-10-2008 10:04Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
15-10-2008 14:24Ina SchieferdeckerNote Added: 0007072
15-10-2008 14:24Ina SchieferdeckerAssigned ToIna Schieferdecker => Gyorgy Rethy
15-10-2008 14:24Ina SchieferdeckerResolutionopen => fixed
15-10-2008 14:24Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
30-10-2008 14:04Gyorgy RethyStatusassigned => closed
30-10-2008 14:04Gyorgy RethyNote Added: 0007221
30-10-2008 14:04Gyorgy RethyFixed in Version => Edition 4.1.1 (not yet published)
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0007072) +
+ Ina Schieferdecker    +
+ 15-10-2008 14:24    +
+ 		+ + + + +
+ The proposed solution is ok.
+
+
+
+ + + + + + + + + + +
+ (0007221) +
+ Gyorgy Rethy    +
+ 30-10-2008 14:04    +
+ 		+ + + + +
+ Done in master copy.
+
+ + diff --git a/docs/mantis/CR4232.md b/docs/mantis/CR4232.md new file mode 100644 index 0000000000000000000000000000000000000000..a9748a6ac7f3b47f561458d64c4f95d26e060074 --- /dev/null +++ b/docs/mantis/CR4232.md @@ -0,0 +1,185 @@ + + + + + + + + + + + + + 0004232: Clarify text on mapping of simpleContent derived by restriction - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0004232Part 09: Using XML with TTCN-3Clarificationpublic02-10-2008 07:5919-12-2008 14:52
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)7.6.1.2
For STF discussion
Source (company - Author)     
Summary0004232: Clarify text on mapping of simpleContent derived by restriction
DescriptionCurrent text says:
+"To restrict XSD simpleContent additional, more restrictive, facets are applied to the base type or to attributes of the base type. The whole type needs to be redefined in the restricted version, translating to a completely new type definition in TTCN 3.
+EXAMPLE:
+...."
+
+It is proposed to replace with:
+"An XSD simpleContent may restrict the base type or attributes of the base type by applying more restrictive facets than those of the base type (if any). Such XSD simpleContent shall be mapped to a sequence of fields, corresponding to the base type and its attributes and applying the restrictions of the given simpleContent to them (i.e. the base type shall not be references but copyed). First the fields corresponding to the base type attributes shall be generated in the order of their occurance in the XSD, followed by the field generated for the base type. The field name of the latter shall be "base"."
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
02-10-2008 07:59Gyorgy RethyNew Issue
02-10-2008 07:59Gyorgy RethyStatusnew => assigned
02-10-2008 07:59Gyorgy RethyAssigned To => Gyorgy Rethy
02-10-2008 07:59Gyorgy RethyClause Reference(s) => 7.6.1.2
02-10-2008 07:59Gyorgy RethySource (company - Author) =>
13-10-2008 09:30Gyorgy RethySummaryUnclear mapping of simpleContent derived by restriction => Clarify text on mapping of simpleContent derived by restriction
15-10-2008 10:02Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
15-10-2008 15:03Ina SchieferdeckerNote Added: 0007073
15-10-2008 15:03Ina SchieferdeckerAssigned ToIna Schieferdecker => Gyorgy Rethy
15-10-2008 15:03Ina SchieferdeckerResolutionopen => fixed
15-10-2008 15:03Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
20-10-2008 16:32Gyorgy RethyNote Added: 0007127
20-10-2008 16:32Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
12-12-2008 13:13Ina SchieferdeckerNote Added: 0007684
12-12-2008 13:13Ina SchieferdeckerAssigned ToIna Schieferdecker => Gyorgy Rethy
19-12-2008 14:52Gyorgy RethyStatusassigned => closed
19-12-2008 14:52Gyorgy RethyNote Added: 0007753
19-12-2008 14:52Gyorgy RethyFixed in Version => Edition 4.1.1 (not yet published)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0007073) +
+ Ina Schieferdecker    +
+ 15-10-2008 15:03    +
+ 		+ + + + +
+ The proposed solution is in principle ok, but as the base field is the last field in the record type, it should be mentioned after the attribute fields for better understanding. Also some more rewording:
+
+"An XSD simpleContent may restrict the base type or attributes of the base type by applying more restrictive facets than those of the base type (if any). Such XSD simpleContent shall be mapped to a record type containing fields corresponding to the attributes and to the base type. The restrictions of the given simpleContent shall be applied to the fields (i.e. the base type shall not be referenced but translated to a new type definition in TTCN-3). At first, the fields corresponding to the attributes shall be generated in the order of their occurance in the XSD simpleContent definition, followed by the field generated for the base type. The field name of the latter shall be "base"."
+
+
+
+ + + + + + + + + + +
+ (0007127) +
+ Gyorgy Rethy    +
+ 20-10-2008 16:32    +
+ 		+ + + + +
+ "Such XSD simpleContent shall be mapped to a record type containing fields corresponding to the attributes and to the base type."
+See the example:
+  <xs:complexType name="Laa-laa>
+    <xs:simpleContent>
+      <xs:extension base="xs:integer">
+        <xs:attribute name="country" type="xs:string" />
+      </xs:extension>
+    </xs:simpleContent>
+  </xs:complexType>
+
+The enclosing TTCN-3 record is generated from the enclosing XSD complexType tag and when processing the XSD simple content "only" the body, i.e. the fields of the enclosing record are added.
+For this reason the above text shall be: "Such XSD simpleContent shall be mapped to fields of the record type generated for the complexType (see clause 7.6), corresponding to the attributes and to the base type."
+Otherwise Ina's text in the previous note is OK with me.
+
+
+
+ + + + + + + + + + +
+ (0007684) +
+ Ina Schieferdecker    +
+ 12-12-2008 13:13    +
+ 		+ + + + +
+ ok
+
+
+
+ + + + + + + + + + +
+ (0007753) +
+ Gyorgy Rethy    +
+ 19-12-2008 14:52    +
+ 		+ + + + +
+ Amendments are done in the master copy
+
+ + diff --git a/docs/mantis/CR4233.md b/docs/mantis/CR4233.md new file mode 100644 index 0000000000000000000000000000000000000000..9445eb8006f875f6c6024c75d6a8187e152fb760 --- /dev/null +++ b/docs/mantis/CR4233.md @@ -0,0 +1,127 @@ + + + + + + + + + + + + + 0004233: Text describing XSD patterns mapping is unclear - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0004233Part 09: Using XML with TTCN-3Clarificationpublic02-10-2008 08:5530-10-2008 15:11
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.3.1 (published 2008-04) 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)6.1.4
For STF discussion
Source (company - Author)L.M.Ericsson
Summary0004233: Text describing XSD patterns mapping is unclear
DescriptionThe current text is unclear, mixes different terms, e.g. patterns and regular expressions and the mapping of the XSD quadruple pattern is missing.
+
+It is proposed instead:"For XSD types derived directly or indirectly from the XSD string type, pattern facets shall directly be mapped to TTCN-3 pattern subtyping. This facet is not supported for numerical and boolean types. As the syntax of XSD regular patterns differs from the syntax of the TTCN-3 pattern subtyping, a mapping of the pattern expression shall be applied. The symbols (, ), |, [, ], ^, - shall not be change and shall be translated directly. Other metacharacters shall be mapped according to tables 3 and 4.
+Table 3: Translation of metacharacters
+XSD TTCN-3
+. ?
+\s [\t\n\r]
+\S [^\t\n\t]
+\d \d
+\D [^\d]
+\w \w
+\W [^\w]
+\i [\w\d:]
+\I [^\w\d:]
+\c [\w\d.\-_:]
+\C [^\w\d.\-_:]
+&#xgprc \q{g,p,r,c}
+
+Table 4: Translation of quantifiers
+XSD TTCN-3
+? #(0,1)
++ #(1, )
+* #(0, )
+{n,m} #(n,m)
+{n} #(n)
+{n,} #(n, )
+
+Escaped characters in XSD shall be mapped to the appropriate character (e.g. '.', and '+') or, if this character has a metacharacter meaning in TTCN-3 patterns, to an escaped character in TTCN-3. The double quote character must be mapped to a pair of double quote characters in TTCN-3. Character categories and blocks (like \p{Lu} or \p{IsBasicLatin}) are not supported. The mapping shall result in a valid TTCN-3 pattern according to clause B.1.5 of ES 201 873 1 [1].
+EXAMPLE:
+..."
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR4233_Solution.doc (50,176) 15-10-2008 17:15
http://oldforge.etsi.org/mantis/file_download.php?file_id=1694&type=bug
Issue History
Date ModifiedUsernameFieldChange
02-10-2008 08:55Gyorgy RethyNew Issue
02-10-2008 08:55Gyorgy RethyStatusnew => assigned
02-10-2008 08:55Gyorgy RethyAssigned To => Gyorgy Rethy
02-10-2008 08:55Gyorgy RethyClause Reference(s) => 6.1.4
02-10-2008 08:55Gyorgy RethySource (company - Author) => L.M.Ericsson
13-10-2008 09:29Gyorgy RethySummaryXSD patterns mapping is unclear => Text describing XSD patterns mapping is unclear
15-10-2008 10:03Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
15-10-2008 17:15Ina SchieferdeckerNote Added: 0007079
15-10-2008 17:15Ina SchieferdeckerFile Added: CR4233_Solution.doc
15-10-2008 17:16Ina SchieferdeckerAssigned ToIna Schieferdecker => Gyorgy Rethy
15-10-2008 17:16Ina SchieferdeckerResolutionopen => fixed
15-10-2008 17:16Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
30-10-2008 15:11Gyorgy RethyStatusassigned => closed
30-10-2008 15:11Gyorgy RethyNote Added: 0007224
30-10-2008 15:11Gyorgy RethyFixed in Version => Edition 4.1.1 (not yet published)
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0007079) +
+ Ina Schieferdecker    +
+ 15-10-2008 17:15    +
+ 		+ + + + +
+ In principle ok - see attached solution.
+
+
+
+ + + + + + + + + + +
+ (0007224) +
+ Gyorgy Rethy    +
+ 30-10-2008 15:11    +
+ 		+ + + + +
+ Done in master copy, in line with the proposed solution but the order of the sentences. First defined for which types the facet is suppoerted and then the translation is described. One additional error is corrected in table 3 -> the XSD and TTCN-3 \n-s are not equivalent, the former denotes line feed (LF) only, the latter denotes any of LF, VT, FF & CR.
+
+ + diff --git a/docs/mantis/CR4253.md b/docs/mantis/CR4253.md new file mode 100644 index 0000000000000000000000000000000000000000..fde997902fef7e2004032325ecee96e77bf2fd80 --- /dev/null +++ b/docs/mantis/CR4253.md @@ -0,0 +1,63 @@ + + + + + + + + + + + + + 0004253: C++ Mapping for TCI - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0004253Part 06: TTCN-3 Control InterfaceClarificationpublic07-10-2008 05:5712-12-2008 10:59
ReporterIna Schieferdecker 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)new clause needed
Source (company - Author)Jesús Domínguez Colino, MTP, Spain
Summary0004253: C++ Mapping for TCI
DescriptionAccording to the MTS input by MTP, Spain the TCI will be extended with a C++ mapping.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0003796closed Ina Schieferdecker Part 05: TTCN-3 Runtime Interface  C++ Mapping for TRI 
related to 0000829closed  Part 05: TTCN-3 Runtime Interface  C++ language mapping 
Attached Fileszip es_20187306v040000_withC++Mapping.zip (1,040,084) 07-10-2008 05:59
http://oldforge.etsi.org/mantis/file_download.php?file_id=1675&type=bug
zip es_20187306v040000_MasterCopy.zip (1,041,530) 07-10-2008 06:01
http://oldforge.etsi.org/mantis/file_download.php?file_id=1676&type=bug
Issue History
Date ModifiedUsernameFieldChange
07-10-2008 05:57Ina SchieferdeckerNew Issue
07-10-2008 05:57Ina SchieferdeckerStatusnew => assigned
07-10-2008 05:57Ina SchieferdeckerAssigned To => Ina Schieferdecker
07-10-2008 05:57Ina SchieferdeckerClause Reference(s) => new clause needed
07-10-2008 05:57Ina SchieferdeckerSource (company - Author) => Jesús Domínguez Colino, MTP, Spain
07-10-2008 05:57Ina SchieferdeckerProjectTTCN-3 Change Requests => Part 06: TTCN-3 Control Interface
07-10-2008 05:58Ina SchieferdeckerRelationship addedrelated to 0003796
07-10-2008 05:59Ina SchieferdeckerFile Added: es_20187306v040000_withC++Mapping.zip
07-10-2008 05:59Ina SchieferdeckerNote Added: 0007006
07-10-2008 06:01Ina SchieferdeckerFile Added: es_20187306v040000_MasterCopy.zip
07-10-2008 06:02Ina SchieferdeckerStatusassigned => resolved
07-10-2008 06:02Ina SchieferdeckerResolutionopen => fixed
07-10-2008 06:02Ina SchieferdeckerCategoryTCI => Clarification
07-10-2008 06:02Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
12-12-2008 10:59Ina SchieferdeckerStatusresolved => closed
12-12-2008 10:59Ina SchieferdeckerFixed in Version => Edition 4.1.1 (not yet published)
12-12-2008 12:03Ina SchieferdeckerRelationship addedrelated to 0000829
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0007006) +
+ Ina Schieferdecker    +
+ 07-10-2008 05:59    +
+ 		+ + + + +
+ Revision being done by Jesus and Ina
+
+ + diff --git a/docs/mantis/CR4267.md b/docs/mantis/CR4267.md new file mode 100644 index 0000000000000000000000000000000000000000..51f8cc44379d23ec65b832e1a162e114628f5f2c --- /dev/null +++ b/docs/mantis/CR4267.md @@ -0,0 +1,97 @@ + + + + + + + + + + + + + 0004267: Systematic specification of encoding instructions - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0004267Part 09: Using XML with TTCN-3Clarificationpublic13-10-2008 08:5220-04-2009 09:26
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.3.1 (published 2008-04) 
Target Versionv4.1.1 (published 2009-06)Fixed in Version 
Clause Reference(s)Annex B
For STF discussion
Source (company - Author)L.M.Ericsson
Summary0004267: Systematic specification of encoding instructions
DescriptionDuring implementation it was realized that a systematic description of all encoding instructions would increase clarity and prevent possible misunderstandings and/or misinterpretations. A separate annex is proposed on this (see the attached file as example - it proposes the structure and desription of a few encoding instructions)
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc es_20187309v030303_annexB.doc (96,768) 13-10-2008 08:52
http://oldforge.etsi.org/mantis/file_download.php?file_id=1679&type=bug
doc es_20187309v030303_annexB_v2.doc (145,408) 17-12-2008 15:55
http://oldforge.etsi.org/mantis/file_download.php?file_id=1911&type=bug
Issue History
Date ModifiedUsernameFieldChange
13-10-2008 08:52Gyorgy RethyNew Issue
13-10-2008 08:52Gyorgy RethyStatusnew => assigned
13-10-2008 08:52Gyorgy RethyAssigned To => Gyorgy Rethy
13-10-2008 08:52Gyorgy RethyFile Added: es_20187309v030303_annexB.doc
13-10-2008 08:52Gyorgy RethyClause Reference(s) => Annex B
13-10-2008 08:52Gyorgy RethySource (company - Author) => L.M.Ericsson
12-12-2008 11:33Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
17-12-2008 15:55Gyorgy RethyFile Added: es_20187309v030303_annexB_v2.doc
17-12-2008 15:56Gyorgy RethyNote Added: 0007731
20-04-2009 09:26Gyorgy RethyStatusassigned => closed
20-04-2009 09:26Gyorgy RethyNote Added: 0008508
20-04-2009 09:26Gyorgy RethyResolutionopen => fixed
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0007731) +
+ Gyorgy Rethy    +
+ 17-12-2008 15:56    +
+ 		+ + + + +
+ The file es_20187309v030303_annexB_v2.doc by intention is a complete and consistent description of all encoding instructions used at explicit XSD to TTCN-3 mapping.
+
+
+
+ + + + + + + + + + +
+ (0008508) +
+ Gyorgy Rethy    +
+ 20-04-2009 09:26    +
+ 		+ + + + +
+ Annex B has ben added to v4.1.1
+
+ + diff --git a/docs/mantis/CR4268.md b/docs/mantis/CR4268.md new file mode 100644 index 0000000000000000000000000000000000000000..ecb94355cb9f2a6ee2aaa37ae166a4c96cab853d --- /dev/null +++ b/docs/mantis/CR4268.md @@ -0,0 +1,110 @@ + + + + + + + + + + + + + 0004268: Missing encoding instruction in $61.5 example2 - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0004268Part 09: Using XML with TTCN-3Technicalpublic13-10-2008 09:1030-10-2008 15:15
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)6.1.5
For STF discussion
Source (company - Author)     
Summary0004268: Missing encoding instruction in $61.5 example2
DescriptionThis example shows the mapping of an enumeration facet, where the restriction base is integer to a TTCN-3 enumerated type. In this case the enumeration names are artificial and the encoded XML component shall contain the integer values, not the TTCN-3 enumeration names. The encoder shall be instructed to do so.
+Change the TTCN-3 derivation from:
+    //Is mapped to the TTCN-3 type definition:
+    type enumerated Integer_0_5_10 {int0(0), int5(5), int10(10)}
+        with { variant "name as uncapitalized" }
+TO:
+    //Is mapped to the TTCN-3 type definition:
+    type enumerated Integer_0_5_10 {int0(0), int5(5), int10(10)}
+        with { variant "name as uncapitalized";
+               variant "use number"
+         }
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
13-10-2008 09:10Gyorgy RethyNew Issue
13-10-2008 09:10Gyorgy RethyStatusnew => assigned
13-10-2008 09:10Gyorgy RethyAssigned To => Gyorgy Rethy
13-10-2008 09:10Gyorgy RethyClause Reference(s) => 6.1.5
13-10-2008 09:10Gyorgy RethySource (company - Author) =>
15-10-2008 10:03Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
15-10-2008 17:38Ina SchieferdeckerNote Added: 0007080
15-10-2008 17:39Ina SchieferdeckerAssigned ToIna Schieferdecker => Gyorgy Rethy
15-10-2008 17:39Ina SchieferdeckerResolutionopen => fixed
15-10-2008 17:39Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
30-10-2008 15:15Gyorgy RethyStatusassigned => closed
30-10-2008 15:15Gyorgy RethyNote Added: 0007225
30-10-2008 15:15Gyorgy RethyFixed in Version => Edition 4.1.1 (not yet published)
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0007080) +
+ Ina Schieferdecker    +
+ 15-10-2008 17:38    +
+ 		+ + + + +
+ In principle ok, however, the additional encoding variant "use number" should be explained in clause 6.1.5:
+
+In this case the enumeration names are artificial and the encoded XML component shall contain the integer values, not the TTCN-3 enumeration names. The encoder shall be instructed to do so with the variant attribute "use number".
+
+
+
+ + + + + + + + + + +
+ (0007225) +
+ Gyorgy Rethy    +
+ 30-10-2008 15:15    +
+ 		+ + + + +
+ Done in master copy, including the sentence explaining the "use number" attribute.
+
+ + diff --git a/docs/mantis/CR4269.md b/docs/mantis/CR4269.md new file mode 100644 index 0000000000000000000000000000000000000000..4406ad426beedd3e770513818f8be7ecf39df9df --- /dev/null +++ b/docs/mantis/CR4269.md @@ -0,0 +1,131 @@ + + + + + + + + + + + + + 0004269: Allow dotted and index notation for result of function calls - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0004269Part 01: TTCN-3 Core LanguageClarificationpublic13-10-2008 10:5110-12-2008 12:53
Reportertepelmann 
Assigned ToIna Schieferdecker 
PrioritynormalSeveritymajorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)Annex A, 15.9, ...
Source (company - Author)tepelmann
Summary0004269: Allow dotted and index notation for result of function calls
DescriptionIn order to allow dotted and index notation to be applied also to results
+of valueof(), regexp(), replace() and results of function calls without
+having to assign these to variables first, the BNF should be changed
+in the following way.
+
+- Replace rule 592
+
+    UnaryExpression ::= [UnaryOp] Primary
+
+  by the following:
+
+    UnaryExpression ::= [UnaryOp] FieldReferenceOp
+
+- Add a new rule
+
+    FieldReferenceOp ::= Primary [ExtendedFieldReference]
+
+- To avoid ambiguity, change rule 457
+  
+    Value ::= PredefinedValue | ReferencedValue
+
+  to the following:
+
+    Value ::= PredefinedValue | ValueReference
+
+  and delete the rule 477
+
+    ReferencedValue ::= ValueReference [ExtendedFieldReference]
+
+This way, field selection and indexing is possible for all expressions,
+of course the static semantics for those operators remain the same, i.e.
+field selection should only be possible for expressions of
+record/set/union type with the appropriate field declaration,
+index operation should only be possible for expressions of
+record of/set of/array type.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0004402closed Ina Schieferdecker Unneeded restriction in referencing record/set fields 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
13-10-2008 10:51tepelmannNew Issue
13-10-2008 10:51tepelmannClause Reference(s) => Annex A, 15.9, ...
13-10-2008 10:51tepelmannSource (company - Author) => tepelmann
13-10-2008 18:28Ina SchieferdeckerStatusnew => assigned
13-10-2008 18:28Ina SchieferdeckerAssigned To => Thomas Deiß
14-10-2008 17:53Thomas DeißProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
24-11-2008 17:57Ina SchieferdeckerRelationship addedrelated to 0004402
24-11-2008 17:58Ina SchieferdeckerNote Added: 0007392
25-11-2008 11:10Thomas DeißAssigned ToThomas Deiß => Ina Schieferdecker
10-12-2008 12:53Ina SchieferdeckerNote Added: 0007630
10-12-2008 12:53Ina SchieferdeckerStatusassigned => resolved
10-12-2008 12:53Ina SchieferdeckerResolutionopen => fixed
10-12-2008 12:53Ina SchieferdeckerCategoryTTCN-3 Core Language => Clarification
10-12-2008 12:53Ina SchieferdeckerFixed in Version => Edition 4.1.1 (not yet published)
10-12-2008 12:53Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
10-12-2008 12:53Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0007392) +
+ Ina Schieferdecker    +
+ 24-11-2008 17:58    +
+ 		+ + + + +
+ Resolution for this CR is part of the resolution for CR4402
+
+
+
+ + + + + + + + + + +
+ (0007630) +
+ Ina Schieferdecker    +
+ 10-12-2008 12:53    +
+ 		+ + + + +
+ Resolution as defined in CR4402.
+
+ + diff --git a/docs/mantis/CR4270.md b/docs/mantis/CR4270.md new file mode 100644 index 0000000000000000000000000000000000000000..4ffa45afc532c54b7ce22486cba43b840d67c7a2 --- /dev/null +++ b/docs/mantis/CR4270.md @@ -0,0 +1,165 @@ + + + + + + + + + + + + + 0004270: Initialization expressions within component types - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0004270Part 01: TTCN-3 Core LanguageClarificationpublic13-10-2008 13:3409-12-2008 20:08
ReporterThomas Deiß 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.3.2 (published 2008-04) 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)6.1.2.1, 6.1.2.2, 6.2.3, 6.2.4, 6.2.7, 6.2.10.1
Source (company - Author)Nokia Siemens Networks, Thomas Deiß
Summary0004270: Initialization expressions within component types
DescriptionComponent type definitions may contain declarations of ports, timers, constants, and variables. Constants must have an initial value, timers and variables may have an initial value. The only kind of restriction on the expressions for these initial values is the limitation to 'ConstantExpression' in the BNF for the value of constants.
+
+For the default duration of timers and for the initial values of variables no restriction is given, neither in the next, nor in the BNF. When arbitrary expressions are allowed, this raises the question when the expressions are evaluated: at compile time, when 'loading' a module, when starting a test case, or when creating an instance of a component type.
+
+To resolve such questions, it is suggested that any value used in a type definition, is described by a constant expression (see CR2152). Such constant expression always evaluate to the same value.
+
+To each of the clauses for type definitions that contain values
+6.1.2.1 Lists of values
+6.1.2.2 Ranges
+6.2.3 Records and sets of single types
+6.2.4 enumerations
+6.2.7 Arrays
+6.2.10.1 Component types
+a restriction should be added that the values have to be defined by constant expressions.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0002152closed Ina Schieferdecker Initialisation of constants using internal/external functions 
Attached Filesdoc CR4270_ConstantsInTypes.doc (59,392) 25-11-2008 12:27
http://oldforge.etsi.org/mantis/file_download.php?file_id=1776&type=bug
doc CR4270_ConstantsInTypes_v2.doc (62,464) 26-11-2008 08:25
http://oldforge.etsi.org/mantis/file_download.php?file_id=1785&type=bug
Issue History
Date ModifiedUsernameFieldChange
13-10-2008 13:34Thomas DeißNew Issue
13-10-2008 13:34Thomas DeißStatusnew => assigned
13-10-2008 13:34Thomas DeißAssigned To => Ina Schieferdecker
13-10-2008 13:34Thomas DeißClause Reference(s) => 6.1.2.1, 6.1.2.2, 6.2.3, 6.2.4, 6.2.7, 6.2.10.1
13-10-2008 13:34Thomas DeißSource (company - Author) => Nokia Siemens Networks, Thomas Deiß
25-11-2008 10:26Ina SchieferdeckerRelationship addedrelated to 0002152
25-11-2008 11:21Ina SchieferdeckerNote Added: 0007403
25-11-2008 12:27Ina SchieferdeckerFile Added: CR4270_ConstantsInTypes.doc
25-11-2008 12:28Ina SchieferdeckerAssigned ToIna Schieferdecker => Thomas Deiß
25-11-2008 12:28Ina SchieferdeckerResolutionopen => fixed
25-11-2008 12:28Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
25-11-2008 14:17Gyorgy RethyNote Added: 0007413
26-11-2008 08:25Thomas DeißFile Added: CR4270_ConstantsInTypes_v2.doc
26-11-2008 08:26Thomas DeißNote Added: 0007436
26-11-2008 08:26Thomas DeißAssigned ToThomas Deiß => Ina Schieferdecker
09-12-2008 20:08Ina SchieferdeckerStatusassigned => resolved
09-12-2008 20:08Ina SchieferdeckerFixed in Version => Edition 4.1.1 (not yet published)
09-12-2008 20:08Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0007403) +
+ Ina Schieferdecker    +
+ 25-11-2008 11:21    +
+ 		+ + + + +
+ Indeed in the BNF all relevant grammar rules go down to constant expression or literals:
+
+arrays: singleconstexpr
+
+allowed values: constantexpr
+
+range: singleconstexpr
+
+length: singleconstexpr
+
+enumeration: literal
+
+In addition, the restrictions in clause 10 on the usage of constant expression within imply what is request by this CR - except for initial values within component type definitions - these however do not need to be further restricted.
+
+Some clarifying sentences could be added as it has been done already in CR2152 for arrays ... see uploaded solution.
+
+
+
+ + + + + + + + + + +
+ (0007413) +
+ Gyorgy Rethy    +
+ 25-11-2008 14:17    +
+ 		+ + + + +
+ In clause 6.2.10.1 "Constants used in the constant expressions of type declarations for variables, constants or ports ..." is unclear as formally no types are declared within components. I propose changing it to "Constants used in the constant expressions declaring sizes of variable, constant, port and timer arrays shall follow the restrictions in clause 10 specified for type and array declarations, however..."
+
+I propose not to add ", see in particular restriction c)"; it is sufficient to refer to "restrictions in clause 10" but item c) may change later to other letter while the reference is unchanged in the types clauses.
+
+Fine with me otherwise.
+
+
+
+ + + + + + + + + + +
+ (0007436) +
+ Thomas Deiß    +
+ 26-11-2008 08:26    +
+ 		+ + + + +
+ proposed solution as such is ok.
+Solution extended to remove also the restriction that subtypes have to be true subtypes (relevant for value list, pattern subtyping).
+v2 uploaded, please crosscheck extension.
+
+
+ + diff --git a/docs/mantis/CR4272.md b/docs/mantis/CR4272.md new file mode 100644 index 0000000000000000000000000000000000000000..829c5d669b7aa5427ae0a5b3a33950cfd90dda34 --- /dev/null +++ b/docs/mantis/CR4272.md @@ -0,0 +1,241 @@ + + + + + + + + + + + + + 0004272: Consolidation of normative and informative references - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0004272Part 01: TTCN-3 Core LanguageClarificationpublic13-10-2008 14:1809-12-2008 18:28
ReporterIna Schieferdecker 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)clause 2 of part 1, 2, 3, 5, 6, 9, and 10
Source (company - Author)     
Summary0004272: Consolidation of normative and informative references
DescriptionPart 1 enumerates a number of TTCN-3 parts as normative references although they are not "indispensable for the application of the present document" (part 1 in this case).
+
+Hence, the proposal is to consolidate the references of part 1 and of the other parts of TTCN-3 as outlined in the attached Word document.
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
parent of 0004573closed Gyorgy Rethy Part 10: TTCN-3 documentation tags Consolidation of normative and informative references 
related to 0003276closed Gyorgy Rethy Part 09: Using XML with TTCN-3 Reference to W3C "Namespaces: Namespaces in XML" is specific, ... 
Attached Filesdoc Consolidation of References for TTCN-3.doc (84,992) 13-10-2008 14:18
http://oldforge.etsi.org/mantis/file_download.php?file_id=1681&type=bug
doc Consolidation of References for TTCN-3_TD.doc (90,112) 13-10-2008 16:58
http://oldforge.etsi.org/mantis/file_download.php?file_id=1683&type=bug
doc Consolidation_of_References_for_TTCN-3_TD_IS.doc (90,112) 16-10-2008 09:53
http://oldforge.etsi.org/mantis/file_download.php?file_id=1703&type=bug
Issue History
Date ModifiedUsernameFieldChange
13-10-2008 14:18Ina SchieferdeckerNew Issue
13-10-2008 14:18Ina SchieferdeckerStatusnew => assigned
13-10-2008 14:18Ina SchieferdeckerAssigned To => Ina Schieferdecker
13-10-2008 14:18Ina SchieferdeckerFile Added: Consolidation of References for TTCN-3.doc
13-10-2008 14:18Ina SchieferdeckerClause Reference(s) => clause 2 of part 1, 2, 3, 5, 6, 9, and 10
13-10-2008 14:18Ina SchieferdeckerSource (company - Author) =>
13-10-2008 14:19Ina SchieferdeckerProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
13-10-2008 14:19Ina SchieferdeckerAssigned ToIna Schieferdecker => Thomas Deiß
13-10-2008 16:58Thomas DeißFile Added: Consolidation of References for TTCN-3_TD.doc
13-10-2008 17:00Thomas DeißNote Added: 0007046
13-10-2008 17:00Thomas DeißAssigned ToThomas Deiß => Ina Schieferdecker
13-10-2008 17:51Ina SchieferdeckerNote Added: 0007047
13-10-2008 18:24Ina SchieferdeckerNote Added: 0007048
13-10-2008 18:24Ina SchieferdeckerAssigned ToIna Schieferdecker => Gyorgy Rethy
16-10-2008 09:44Ina SchieferdeckerRelationship addedrelated to 0003276
16-10-2008 09:52Ina SchieferdeckerNote Added: 0007089
16-10-2008 09:53Ina SchieferdeckerFile Added: Consolidation_of_References_for_TTCN-3_TD_IS.doc
26-11-2008 09:13Gyorgy RethyNote Added: 0007440
26-11-2008 09:14Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
09-12-2008 18:22Ina SchieferdeckerResolutionopen => fixed
09-12-2008 18:22Ina SchieferdeckerCategoryTTCN-3 Core Language => Clarification
09-12-2008 18:22Ina SchieferdeckerProjectPart 01: TTCN-3 Core Language => Part 03: TTCN-3 Graphical presentation Format
09-12-2008 18:23Ina SchieferdeckerProjectPart 03: TTCN-3 Graphical presentation Format => Part 01: TTCN-3 Core Language
09-12-2008 18:26Ina SchieferdeckerIssue cloned: 0004573
09-12-2008 18:26Ina SchieferdeckerRelationship addedparent of 0004573
09-12-2008 18:28Ina SchieferdeckerNote Added: 0007614
09-12-2008 18:28Ina SchieferdeckerStatusassigned => resolved
09-12-2008 18:28Ina SchieferdeckerFixed in Version => Edition 4.1.1 (not yet published)
09-12-2008 18:28Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
09-12-2008 18:28Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0007046) +
+ Thomas Deiß    +
+ 13-10-2008 17:00    +
+ 		+ + + + +
+ One minor issue found
+One normative found that should be informative
+one informative found that should be normative
+
+
+
+ + + + + + + + + + +
+ (0007047) +
+ Ina Schieferdecker    +
+ 13-10-2008 17:51    +
+ 		+ + + + +
+ Like part 2 and 3, also part 10 needs to be updated later - they are not targetted for v4.1.1
+
+
+
+ + + + + + + + + + +
+ (0007048) +
+ Ina Schieferdecker    +
+ 13-10-2008 18:24    +
+ 		+ + + + +
+ Done for part 1, 5, and 6 - Gyorgy, could you please do it for part 9.
+
+
+
+ + + + + + + + + + +
+ (0007089) +
+ Ina Schieferdecker    +
+ 16-10-2008 09:52    +
+ 		+ + + + +
+ Update of the W3C XML Reference Titles.
+
+
+
+ + + + + + + + + + +
+ (0007440) +
+ Gyorgy Rethy    +
+ 26-11-2008 09:13    +
+ 		+ + + + +
+ I think reference to part-4 should be deleted from Part-2 (mentioned in the introduction only, sentence "The operational semantics are defined in ES 201 873-4 [2]." to be deleted from Introductin too.
+In part-9, to show availability I would rather use the link to "this version"; it guarantees that the rigth document is will always be found in the future.
+
+In part 10, for availabililty of RFcs the IETF RFC home shall be used, e.g. http://www.ietf.org/rfc/rfc4248.txt?number=4248 [^] for RFC 4248.
+
+
+
+ + + + + + + + + + +
+ (0007614) +
+ Ina Schieferdecker    +
+ 09-12-2008 18:28    +
+ 		+ + + + +
+ Resolved for part 1, 5, 6, and 9
+
+ + diff --git a/docs/mantis/CR4273.md b/docs/mantis/CR4273.md new file mode 100644 index 0000000000000000000000000000000000000000..84bb9e4e72f32be2269ba26b719d699f433dd249 --- /dev/null +++ b/docs/mantis/CR4273.md @@ -0,0 +1,34 @@ + + + + + + + + + + + + + 0004273: Editorial issues coming from Z.167 - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 07: Using ASN.1 with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0004273Part 07: Using ASN.1 with TTCN-3Editorialpublic13-10-2008 14:3812-12-2008 11:33
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)7.2, 8.1bis, E.2
Source (company - Author)L.M.Ericsson
Summary0004273: Editorial issues coming from Z.167
DescriptionA few editorial issues found:
+- Clause 7.2: title should be "The object identifier type" (de-capitalize first letters)
+- Clause 8.1bis, note 2: "ITU-TRecommendation X.208 [13] (Blue Book)." shall be "CCITT Recommendation X.208 [13] (Blue Book)."
+- "ITU-T Recommendation X.693/Amd. 1" change to "Amd. 1 to ITU-T Recommendation X.693"
+- Clause E.2: title should be "The Decompose function" (de-capitalize Decompose)
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
13-10-2008 14:38Gyorgy RethyNew Issue
13-10-2008 14:38Gyorgy RethyStatusnew => assigned
13-10-2008 14:38Gyorgy RethyAssigned To => Gyorgy Rethy
13-10-2008 14:38Gyorgy RethyClause Reference(s) => 7.2, 8.1bis, E.2
13-10-2008 14:38Gyorgy RethySource (company - Author) => L.M.Ericsson
14-10-2008 16:43Gyorgy RethyStatusassigned => closed
14-10-2008 16:43Gyorgy RethyResolutionopen => fixed
14-10-2008 16:43Gyorgy RethyFixed in Version => Edition 4.1.1 (not yet published)
12-12-2008 11:33Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
+
+ + + + +
+ There are no notes attached to this issue.
+ + diff --git a/docs/mantis/CR4275.md b/docs/mantis/CR4275.md new file mode 100644 index 0000000000000000000000000000000000000000..f24e9acdf3f3d204fce4899da8d325e357fdd142 --- /dev/null +++ b/docs/mantis/CR4275.md @@ -0,0 +1,269 @@ + + + + + + + + + + + + + 0004275: New Concepts to be defined via Packages - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0004275Part 01: TTCN-3 Core LanguageClarificationpublic13-10-2008 17:0626-05-2011 17:05
ReporterIna Schieferdecker 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)Part 1, 4, 5, and 6
Source (company - Author)Ina Schieferdecker, FOKUS
Summary0004275: New Concepts to be defined via Packages
DescriptionThe TTCN-3 Core Language is already quite complex.
+
+Hence, new concepts should be placed where possible into separate packages.
+
+STF 349 proposed the following principle approach:
+
+STF 349 identified the following candidate packages:
+
+1. type parameterization
+
+2. configuration and deployment support
+
+3. internationalization
+
+4. real-time and performance (might be separated)
+
+MTS #47 agreed to
+
+[START]
+...all participants agreed that extention packages should not be added as new parts of the ES 201 873 series. They should carry different ETSI numbers and their version numbers should not be linked to the TTCN-3 Standard's version numbers.
+
+MTS#47-D7 TTCN-3 extension packages will be described in new deliverables that will not belong to the TTCN-3 standard series (not part of the ES 201 873-x numbering scheme).The version numbers of new TTCN-3 extension packages will not be tied to the version numbers of the ES 201 873 series.
+[END]
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0000413closed Jens Grabowski Part 01: TTCN-3 Core Language Static test configurations 
related to 0000403closed Gyorgy Rethy Part 01: TTCN-3 Core Language Port type parameterisation of component types 
related to 0000412closed Tibor Csöndes Part 01: TTCN-3 Core Language Function reference 
related to 0005888closed Ina Schieferdecker Ext Pack: Extended TRI (ES 202 789) An alternative TRI to handle messages and objects directly 
related to 0005110closed Jens Grabowski Ext Pack: Continuous signal support (ES 202 786) Concepts to specify tests for continuous systems 
related to 0004483closed Jens Grabowski Part 01: TTCN-3 Core Language New Concepts to Test Real Time Properties 
Attached Filesppt LanguagePackaging.ppt (92,160) 13-10-2008 17:06
http://oldforge.etsi.org/mantis/file_download.php?file_id=1684&type=bug
doc es_TTCN3PackageTemplate_MasterCopy.doc (136,704) 13-10-2008 17:08
http://oldforge.etsi.org/mantis/file_download.php?file_id=1685&type=bug
doc es_TTCN3PackageTemplate_MasterCopy_update.doc (140,800) 14-10-2008 18:13
http://oldforge.etsi.org/mantis/file_download.php?file_id=1692&type=bug
doc es_TTCN3PackageTemplate_MasterCopy_update2.doc (145,408) 16-10-2008 06:42
http://oldforge.etsi.org/mantis/file_download.php?file_id=1696&type=bug
doc CR4275_packages_part1.doc (54,784) 16-10-2008 06:43
http://oldforge.etsi.org/mantis/file_download.php?file_id=1697&type=bug
doc CR4275_packages_part1_v2.doc (56,320) 21-11-2008 15:19
http://oldforge.etsi.org/mantis/file_download.php?file_id=1756&type=bug
doc es_TTCN3PackageTemplate_MasterCopy_update3.doc (146,944) 09-12-2008 13:27
http://oldforge.etsi.org/mantis/file_download.php?file_id=1871&type=bug
doc es_TTCN3PackageTemplate_MasterCopy_update4.doc (135,680) 26-05-2011 17:05
http://oldforge.etsi.org/mantis/file_download.php?file_id=2512&type=bug
Issue History
Date ModifiedUsernameFieldChange
13-10-2008 17:06Ina SchieferdeckerNew Issue
13-10-2008 17:06Ina SchieferdeckerStatusnew => assigned
13-10-2008 17:06Ina SchieferdeckerAssigned To => Ina Schieferdecker
13-10-2008 17:06Ina SchieferdeckerFile Added: LanguagePackaging.ppt
13-10-2008 17:06Ina SchieferdeckerClause Reference(s) => Part 1, 4, 5, and 6
13-10-2008 17:06Ina SchieferdeckerSource (company - Author) => Ina Schieferdecker, FOKUS
13-10-2008 17:08Ina SchieferdeckerFile Added: es_TTCN3PackageTemplate_MasterCopy.doc
14-10-2008 17:49Ina SchieferdeckerNote Added: 0007064
14-10-2008 18:13Ina SchieferdeckerFile Added: es_TTCN3PackageTemplate_MasterCopy_update.doc
16-10-2008 06:41Ina SchieferdeckerNote Added: 0007084
16-10-2008 06:42Ina SchieferdeckerFile Added: es_TTCN3PackageTemplate_MasterCopy_update2.doc
16-10-2008 06:43Ina SchieferdeckerFile Added: CR4275_packages_part1.doc
16-10-2008 06:44Ina SchieferdeckerProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
16-10-2008 06:45Ina SchieferdeckerAssigned ToIna Schieferdecker => Thomas Deiß
16-10-2008 06:45Ina SchieferdeckerResolutionopen => fixed
16-10-2008 06:45Ina SchieferdeckerCategoryTTCN-3 Core Language => Clarification
16-10-2008 06:45Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
21-11-2008 15:19Thomas DeißFile Added: CR4275_packages_part1_v2.doc
21-11-2008 15:20Thomas DeißNote Added: 0007383
21-11-2008 15:20Thomas DeißAssigned ToThomas Deiß => Ina Schieferdecker
09-12-2008 13:27Ina SchieferdeckerFile Added: es_TTCN3PackageTemplate_MasterCopy_update3.doc
09-12-2008 13:29Ina SchieferdeckerNote Added: 0007596
12-12-2008 08:11Ina SchieferdeckerNote Added: 0007666
12-12-2008 09:03Ina SchieferdeckerNote Edited: 0007666
12-12-2008 09:04Ina SchieferdeckerRelationship addedrelated to 0000413
12-12-2008 09:04Ina SchieferdeckerRelationship addedrelated to 0000403
12-12-2008 09:04Ina SchieferdeckerRelationship addedrelated to 0000412
12-12-2008 09:05Ina SchieferdeckerRelationship addedrelated to 0004483
12-12-2008 09:06Ina SchieferdeckerNote Added: 0007667
12-12-2008 09:07Ina SchieferdeckerStatusassigned => resolved
12-12-2008 09:07Ina SchieferdeckerFixed in Version => Edition 4.1.1 (not yet published)
12-12-2008 09:07Ina SchieferdeckerStatusresolved => closed
26-05-2011 15:46Ina SchieferdeckerFile Added: es_TTCN3PackageTemplate_MasterCopy_update4.doc
26-05-2011 15:48Ina SchieferdeckerRelationship addedrelated to 0005888
26-05-2011 15:50Ina SchieferdeckerRelationship addedrelated to 0000404
26-05-2011 15:50Ina SchieferdeckerRelationship deletedrelated to 0000404
26-05-2011 15:50Ina SchieferdeckerRelationship addedrelated to 0005110
26-05-2011 17:04Ina SchieferdeckerFile Deleted: es_TTCN3PackageTemplate_MasterCopy_update4.doc
26-05-2011 17:05Ina SchieferdeckerFile Added: es_TTCN3PackageTemplate_MasterCopy_update4.doc
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0007064) +
+ Ina Schieferdecker    +
+ 14-10-2008 17:49    +
+ 		+ + + + +
+ A compatibility clause to the versions of the TTCN-3 standard parts and to other packages should be added.
+
+
+
+ + + + + + + + + + +
+ (0007084) +
+ Ina Schieferdecker    +
+ 16-10-2008 06:41    +
+ 		+ + + + +
+ Added package identifiers and the conformance clause.
+
+Attach also an update for part 1 to address package identifiers.
+
+
+
+ + + + + + + + + + +
+ (0007383) +
+ Thomas Deiß    +
+ 21-11-2008 15:20    +
+ 		+ + + + +
+ proposal for part1 checked. Two editorial corrections. Otherwise ok.
+
+
+
+ + + + + + + + + + +
+ (0007596) +
+ Ina Schieferdecker    +
+ 09-12-2008 13:29    +
+ 		+ + + + +
+ Extensions to annexes of certain TTCN-3 parts are to be put into the respective clause on this part in the package definition.
+
+
+
+ + + + + + + + + + +
+ (0007666) +
+ Ina Schieferdecker    +
+ 12-12-2008 08:11    +
(edited on: 12-12-2008 09:03)
+ 		+ + + + +
+ TTCN-3 v4.1.1 will be defined together with three packages:
+
+Package 1: Configuration and Deployment Support - see CR413
+
+Package 2: Advanced Parameterization - see CR403
+
+Package 3: Behaviour Types - see CR412
+
+
+
+
+
+ + + + + + + + + + +
+ (0007667) +
+ Ina Schieferdecker    +
+ 12-12-2008 09:06    +
+ 		+ + + + +
+ Resolved in part 1 for v4.1.1
+
+The packages are defined in the respective CRs - see CR relationships.
+
+This CR has to be considered whenever a new package is to be defined - see e.g. CR 4482 in CR relationsships.
+
+ + diff --git a/docs/mantis/CR4281.md b/docs/mantis/CR4281.md new file mode 100644 index 0000000000000000000000000000000000000000..982fab45e44945c7ae40f7f9306b085fbdf742f1 --- /dev/null +++ b/docs/mantis/CR4281.md @@ -0,0 +1,101 @@ + + + + + + + + + + + + + 0004281: Multiple evaluation of expression in select case - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 04: TTCN-3 Operational Semantics
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0004281Part 04: TTCN-3 Operational SemanticsTechnicalpublic14-10-2008 11:1220-04-2009 11:43
ReporterThomas Deiß 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.3.1 (published 2008-04) 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)part 4, clause 7.7
Source (company - Author)Nokia siemens Networks, Thomas Deiss
Summary0004281: Multiple evaluation of expression in select case
DescriptionThe semantics of the select-case construct is defined by a textual replacement with nested if-then-else statements. As defined, the expression in the select part, is evaluated several times in the if-then-else statements. If the expression calls a function with side effects, this might not be what the user expects.
+
+It is suggested to to define the semantics as a statement block, where first a variable is declared and the value of the expression is assigned to the variable. In the if-then-else statements the variable would be used then.
+
+Note that this is a backward incompatible change.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR4281-Part-1-Multiple-Evaluation-Select-Case-Resolution-JG-V1.doc (148,992) 29-12-2008 14:41
http://oldforge.etsi.org/mantis/file_download.php?file_id=1926&type=bug
doc CR4281-Part-4-Multiple-Evaluation-Select-Case-Resolution-JG-V1.doc (68,608) 29-12-2008 14:41
http://oldforge.etsi.org/mantis/file_download.php?file_id=1927&type=bug
Issue History
Date ModifiedUsernameFieldChange
14-10-2008 11:12Thomas DeißNew Issue
14-10-2008 11:12Thomas DeißStatusnew => assigned
14-10-2008 11:12Thomas DeißAssigned To => Jens Grabowski
14-10-2008 11:12Thomas DeißClause Reference(s) => part 4, clause 7.7
14-10-2008 11:12Thomas DeißSource (company - Author) => Nokia siemens Networks, Thomas Deiss
12-12-2008 11:41Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
29-12-2008 14:40Jens GrabowskiNote Added: 0007763
29-12-2008 14:41Jens GrabowskiFile Added: CR4281-Part-1-Multiple-Evaluation-Select-Case-Resolution-JG-V1.doc
29-12-2008 14:41Jens GrabowskiFile Added: CR4281-Part-4-Multiple-Evaluation-Select-Case-Resolution-JG-V1.doc
29-12-2008 14:42Jens GrabowskiAssigned ToJens Grabowski => Gyorgy Rethy
12-01-2009 17:28Ina SchieferdeckerNote Added: 0007823
12-01-2009 17:29Ina SchieferdeckerStatusassigned => resolved
12-01-2009 17:29Ina SchieferdeckerResolutionopen => fixed
12-01-2009 17:29Ina SchieferdeckerFixed in Version => Edition 4.1.1 (not yet published)
20-04-2009 11:43Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0007763) +
+ Jens Grabowski    +
+ 29-12-2008 14:40    +
+ 		+ + + + +
+ The resolution of this CR requires an update of an example in Part 1. This update can be found in file "CR4281-Part-1-Multiple-Evaluation-Select-Case-Resolution-JG-V1.doc". The resolution for Part 4 can be found in "CR4281-Part-4-Multiple-Evaluation-Select-Case-Resolution-JG-V1.doc"
+
+
+
+ + + + + + + + + + +
+ (0007823) +
+ Ina Schieferdecker    +
+ 12-01-2009 17:28    +
+ 		+ + + + +
+ The solution is ok (just a typo in 'multiple'). Changes added to part 1.
+
+ + diff --git a/docs/mantis/CR4284.md b/docs/mantis/CR4284.md new file mode 100644 index 0000000000000000000000000000000000000000..2551c24f4974bd96ef5420c741e9b93034fa59e7 --- /dev/null +++ b/docs/mantis/CR4284.md @@ -0,0 +1,101 @@ + + + + + + + + + + + + + 0004284: Error in all content definition - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0004284Part 09: Using XML with TTCN-3Technicalpublic14-10-2008 12:2815-10-2008 18:15
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PriorityhighSeveritymajorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.3.1 (published 2008-04) 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)7.6.4
For STF discussion
Source (company - Author) L.M.Ericsson
Summary0004284: Error in all content definition
DescriptionThe standard claims that elements of a complex type with an "all" compositor are optional. However, this is not correct, they may be optional, if indicated explicitly, but by default the elements are mandatory. The Schema specification Part-1 second edition, $3.8.1 says:
+"(all) contain all and only exactly zero or one of each element specified in {particles}. The elements can occur in any order. In this case, to reduce implementation complexity, {particles} is restricted to contain local and top-level element declarations only, with {min occurs}=0 or 1, {max occurs}=1."
+and in $3.8.2:
+"{min occurs} The ·actual value· of the minOccurs [attribute], if present, otherwise 1.
+"
Steps To Reproduce
Additional InformationSee attached file.
TagsNo tags attached.
Relationships
Attached Filesdoc es_20187309v030303_allContentCR.doc (87,040) 14-10-2008 12:28
http://oldforge.etsi.org/mantis/file_download.php?file_id=1688&type=bug
doc es_20187309v030303_allContentCR_IS.doc (90,112) 15-10-2008 17:47
http://oldforge.etsi.org/mantis/file_download.php?file_id=1695&type=bug
Issue History
Date ModifiedUsernameFieldChange
14-10-2008 12:28Gyorgy RethyNew Issue
14-10-2008 12:28Gyorgy RethyStatusnew => assigned
14-10-2008 12:28Gyorgy RethyAssigned To => Gyorgy Rethy
14-10-2008 12:28Gyorgy RethyFile Added: es_20187309v030303_allContentCR.doc
14-10-2008 12:28Gyorgy RethyClause Reference(s) => 7.6.4
14-10-2008 12:28Gyorgy RethySource (company - Author) => L.M.Ericsson
15-10-2008 10:00Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
15-10-2008 17:47Ina SchieferdeckerFile Added: es_20187309v030303_allContentCR_IS.doc
15-10-2008 17:47Ina SchieferdeckerNote Added: 0007081
15-10-2008 17:48Ina SchieferdeckerAssigned ToIna Schieferdecker => Gyorgy Rethy
15-10-2008 17:48Ina SchieferdeckerResolutionopen => fixed
15-10-2008 17:48Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
15-10-2008 18:15Gyorgy RethyStatusassigned => closed
15-10-2008 18:15Gyorgy RethyNote Added: 0007082
15-10-2008 18:15Gyorgy RethyFixed in Version => Edition 4.1.1 (not yet published)
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0007081) +
+ Ina Schieferdecker    +
+ 15-10-2008 17:47    +
+ 		+ + + + +
+ In principle ok - see slight modifications in attached revision.
+
+
+
+ + + + + + + + + + +
+ (0007082) +
+ Gyorgy Rethy    +
+ 15-10-2008 18:15    +
+ 		+ + + + +
+ Added to master draft.
+
+ + diff --git a/docs/mantis/CR4287.md b/docs/mantis/CR4287.md new file mode 100644 index 0000000000000000000000000000000000000000..b3eb0cfe3a3963e5c59d9d69925e77e417efdd96 --- /dev/null +++ b/docs/mantis/CR4287.md @@ -0,0 +1,64 @@ + + + + + + + + + + + + + 0004287: start test component refers to value parameters - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 04: TTCN-3 Operational Semantics
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0004287Part 04: TTCN-3 Operational SemanticsClarificationpublic14-10-2008 16:5320-04-2009 11:39
ReporterThomas Deiß 
Assigned ToGyorgy Rethy 
PrioritylowSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.3.1 (published 2008-04) 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)part4, clause 9.46
Source (company - Author)Nokia Siemens Networks, Thomas Deiss
Summary0004287: start test component refers to value parameters
DescriptionClause 9.46 on start test component states 'In functions referenced in start component operations only value parameters are allowed'. out and inout parameters are considered in part4 as reference parameters. This sentence should be updated to 'Parameters in functions referenced in start component operations are treated as value parameters'. Or the sentence is simply dropped.
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR4287-Start-Test-Component-Refers-To-Value-Parameters-Resolution-JG-V1.doc (90,624) 29-12-2008 15:05
http://oldforge.etsi.org/mantis/file_download.php?file_id=1928&type=bug
Issue History
Date ModifiedUsernameFieldChange
14-10-2008 16:53Thomas DeißNew Issue
14-10-2008 16:53Thomas DeißStatusnew => assigned
14-10-2008 16:53Thomas DeißAssigned To => Jens Grabowski
14-10-2008 16:53Thomas DeißClause Reference(s) => part4, clause 9.46
14-10-2008 16:53Thomas DeißSource (company - Author) => Nokia Siemens Networks, Thomas Deiss
12-12-2008 11:40Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
29-12-2008 15:04Jens GrabowskiNote Added: 0007764
29-12-2008 15:05Jens GrabowskiFile Added: CR4287-Start-Test-Component-Refers-To-Value-Parameters-Resolution-JG-V1.doc
29-12-2008 15:05Jens GrabowskiAssigned ToJens Grabowski => Gyorgy Rethy
10-03-2009 10:52Ina SchieferdeckerStatusassigned => resolved
10-03-2009 10:52Ina SchieferdeckerResolutionopen => fixed
20-04-2009 11:39Ina SchieferdeckerStatusresolved => closed
20-04-2009 11:39Ina SchieferdeckerFixed in Version => Edition 4.1.1 (not yet published)
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0007764) +
+ Jens Grabowski    +
+ 29-12-2008 15:04    +
+ 		+ + + + +
+ Resolution follows the proposal to drop the sentence.
+
+ + diff --git a/docs/mantis/CR4288.md b/docs/mantis/CR4288.md new file mode 100644 index 0000000000000000000000000000000000000000..b3dd5b580ac42a0235970e0dc48e005941f0e76d --- /dev/null +++ b/docs/mantis/CR4288.md @@ -0,0 +1,149 @@ + + + + + + + + + + + + + 0004288: Embedding of line comments - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 04: TTCN-3 Operational Semantics
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0004288Part 04: TTCN-3 Operational SemanticsEditorialpublic14-10-2008 17:4916-10-2008 11:11
ReporterThomas Deiß 
Assigned ToIna Schieferdecker 
PrioritylowSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.3.1 (published 2008-04) 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)A.1.4
Source (company - Author)Nokia Siemens Networks, Thomas Deiß
Summary0004288: Embedding of line comments
DescriptionClause A.1.4 states 'Line comments may follow TTCN 3 program statements but they shall not be embedded in a statement.' This is not correct.
+
+const // some comment integer c := 1;
+  boolean b true;
+is correct, also the line comment is clearly embedded in the declaration.
+
+Proposal: 'Line comments may follow TTCN-3 program statements, but they cannot be embedded in a statement on the same line.'
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
14-10-2008 17:49Thomas DeißNew Issue
14-10-2008 17:49Thomas DeißStatusnew => assigned
14-10-2008 17:49Thomas DeißAssigned To => Ina Schieferdecker
14-10-2008 17:49Thomas DeißClause Reference(s) => A.1.4
14-10-2008 17:49Thomas DeißSource (company - Author) => Nokia Siemens Networks, Thomas Deiß
14-10-2008 18:12Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
14-10-2008 18:23Ina SchieferdeckerNote Added: 0007065
14-10-2008 18:28Ina SchieferdeckerAssigned ToIna Schieferdecker => Thomas Deiß
14-10-2008 18:28Ina SchieferdeckerResolutionopen => fixed
15-10-2008 09:25Thomas DeißNote Added: 0007066
15-10-2008 09:25Thomas DeißAssigned ToThomas Deiß => Ina Schieferdecker
16-10-2008 11:10Ina SchieferdeckerNote Added: 0007092
16-10-2008 11:10Ina SchieferdeckerStatusassigned => resolved
16-10-2008 11:11Ina SchieferdeckerStatusresolved => closed
16-10-2008 11:11Ina SchieferdeckerFixed in Version => Edition 4.1.1 (not yet published)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0007065) +
+ Ina Schieferdecker    +
+ 14-10-2008 18:23    +
+ 		+ + + + +
+ It is better to remove the sentence as it is still misleading, e.g. it is not only statements - but any kind of definition. Anyway, there is no real need to explain grazy cases of line comments?!
+
+Still, the example could point at the issue:
+
+EXAMPLE 3:
+    // The following is not legal
+    const // This is MyConst integer MyConst := 1;
+    // A block comment should have been used instead
+    const /* This is MyConst */ integer MyConst := 1;
+
+
+
+ + + + + + + + + + +
+ (0007066) +
+ Thomas Deiß    +
+ 15-10-2008 09:25    +
+ 		+ + + + +
+ Example is ok. Leaving out the sentence is also ok.
+
+
+
+ + + + + + + + + + +
+ (0007092) +
+ Ina Schieferdecker    +
+ 16-10-2008 11:10    +
+ 		+ + + + +
+ Added one more example:
+
+    // A line comment like this works as well
+    const // This is MyConst
+        integer MyConst := 1;
+
+ + diff --git a/docs/mantis/CR4291.md b/docs/mantis/CR4291.md new file mode 100644 index 0000000000000000000000000000000000000000..d3fcc2e2d68f96b6da18018a11fb09ad4ab0269a --- /dev/null +++ b/docs/mantis/CR4291.md @@ -0,0 +1,180 @@ + + + + + + + + + + + + + 0004291: tciparametertype tciparametertypetype errors - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0004291Part 06: TTCN-3 Control InterfaceTechnicalpublic14-10-2008 18:4514-12-2008 10:52
ReporterThomas Deiß 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.4.1 (published 2008-09) 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)part6, 8.2.2.3, 8.2.2.12, 9.5
Source (company - Author)Nokia Siemens Networks, Thomas Deiß
Summary0004291: tciparametertype tciparametertypetype errors
DescriptionThe tciparametertype and tciparameterlisttype are used in the TCI for actual parameter lists.
+The tciparametertypetype and tciparametertypelisttype are used in the TCI for formal parameter lists (of testcases).
+
+In the Java language mapping, the operation get on tciparametertypelisttype returns an object of the Java class tciparametertype, but this is not defined. Note that TciParameterType in Java would correspond to the IDL definition TciParameterTypeType (all the Java definitions skip the final 'type')
+
+In the C language mapping, tciparametertypelisttype is defined as an array over 'Type', but this would not contain the passing mode information. The definition of a C type TciParameterTypeType is missing.
+
+typedef struct TciParameterTypeType
+  {
+    TciParameterPassingModeType parPassMode;
+    Type parType;
+  } TciParameterTypeType;
+
+Name of parameter is not needed as this is also not contained in the IDL definition in Annex A.1
+  struct TciParameterTypeType {
+    Type parameterType;
+    TciParameterPassingModeType mode;
+  };
+
+In Section 8.2.2.3, the Java interface name is misspelled, an 'r' is missing: TciParameteList
+ 
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR4291_ParameterTypeType.doc (40,448) 12-12-2008 14:56
http://oldforge.etsi.org/mantis/file_download.php?file_id=1890&type=bug
Issue History
Date ModifiedUsernameFieldChange
14-10-2008 18:45Thomas DeißNew Issue
14-10-2008 18:45Thomas DeißStatusnew => assigned
14-10-2008 18:45Thomas DeißAssigned To => Ina Schieferdecker
14-10-2008 18:45Thomas DeißClause Reference(s) => part6, 8.2.2.3, 8.2.2.12, 9.5
14-10-2008 18:45Thomas DeißSource (company - Author) => Nokia Siemens Networks, Thomas Deiß
16-10-2008 14:21Ina SchieferdeckerNote Added: 0007096
16-10-2008 14:22Ina SchieferdeckerAssigned ToIna Schieferdecker => Thomas Deiß
16-10-2008 14:22Ina SchieferdeckerResolutionopen => fixed
16-10-2008 14:22Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
16-10-2008 15:17Ina SchieferdeckerNote Deleted: 0007096
16-10-2008 15:17Ina SchieferdeckerNote Added: 0007100
24-11-2008 10:52Thomas DeißNote Added: 0007385
24-11-2008 10:52Thomas DeißAssigned ToThomas Deiß => Ina Schieferdecker
12-12-2008 14:46Ina SchieferdeckerNote Edited: 0007100
12-12-2008 14:46Ina SchieferdeckerNote Edited: 0007385
12-12-2008 14:56Ina SchieferdeckerFile Added: CR4291_ParameterTypeType.doc
12-12-2008 14:57Ina SchieferdeckerStatusassigned => resolved
12-12-2008 14:57Ina SchieferdeckerFixed in Version => Edition 4.1.1 (not yet published)
12-12-2008 15:35Ina SchieferdeckerNote Added: 0007688
12-12-2008 15:35Ina SchieferdeckerAssigned ToIna Schieferdecker => Thomas Deiß
14-12-2008 10:52Ina SchieferdeckerAssigned ToThomas Deiß => Ina Schieferdecker
14-12-2008 10:52Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0007100) +
+ Ina Schieferdecker    +
+ 16-10-2008 15:17    +
(edited on: 12-12-2008 14:46)
+ 		+ + + + +
+ The C mapping for TciParameterTypeListType is:
+
+typedef struct TciParameterTypeListType
+{
+  long int length;
+  Type *parList;
+} TciParameterTypeListType;
+
+changed into
+
+typedef struct TciParameterTypeListType
+{
+  long int length;
+  TciParameterTypeType *parList;
+} TciParameterTypeListType;
+
+with TciParameterTypeType being defined as
+
+typedef struct TciParameterTypeType {
+    Type parameterType;
+    TciParameterPassingModeType mode;
+} TciParameterTypeType;
+
+
+The Java and C++ mapping are to be extended accordingly.
+
+
+
+
+
+ + + + + + + + + + +
+ (0007385) +
+ Thomas Deiß    +
+ 24-11-2008 10:52    +
(edited on: 12-12-2008 14:46)
+ 		+ + + + +
+ proposed change (in Note) for C mapping is ok.
+
+
+
+
+
+ + + + + + + + + + +
+ (0007688) +
+ Ina Schieferdecker    +
+ 12-12-2008 15:35    +
+ 		+ + + + +
+ Please check the uploaded resolution.
+
+ + diff --git a/docs/mantis/CR4299.md b/docs/mantis/CR4299.md new file mode 100644 index 0000000000000000000000000000000000000000..a764c43223678cbdbc12d9e6246a7f2212ac7733 --- /dev/null +++ b/docs/mantis/CR4299.md @@ -0,0 +1,435 @@ + + + + + + + + + + + + + 0004299: Various issues in the C mapping of the TCI - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0004299Part 06: TTCN-3 Control InterfaceTechnicalpublic15-10-2008 17:3014-12-2008 10:53
ReporterAnthony Baire 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.4.1 (published 2008-09) 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)Part 6 9.2 9.4 9.5 9.6
Source (company - Author)     
Summary0004299: Various issues in the C mapping of the TCI
DescriptionHere are various issues in the ANSI/C mapping of the TCI.
+
+Inconsistencies between the IDL definition and C mapping in:
+- tliPrCall_m
+- tliPrCall_c
+- tliPDisconnect
+- tliPUnmap
+
+Typos:
+- TciParamaterType -> TciParameterType
+- TciCharString -> TciCharStringValue
+- TciObjidElem -> TciObjidElemValue
+- TciUCType -> TciUCValue
+- TriSignatureIdType -> TriSignatureId
+- TciParameterList -> TciParameterListType
+- TciParamaterListType -> TciParameterListType
+- TciParameterList -> TciParameterListType
+- TriStatus -> TciStatus
+- TciStatus -> TriStatus
+
+Invalid C code:
+- java-like array definitions (eg: TciValueDifference[] -> TciValueDifference*)
+
+
+The proposed fixes are detailed below
+
+
+
+------------------------------------------------------------------------------------
+Value Interfaces
+
+
+Section 9.2 p124
+
+   void tciSetCStringValue
+    (Value inst, TciCharString value)
+   void tciSetCStringValue
+-> (Value inst, TciCharStringValue value)
+
+
+Section 9.5 p134
+
+   typedef struct TciValueDifferenceList
+   {
+    long int length;
+    TciValueDifference[] diffList;
+   } TciValueDifferenceList;
+   typedef struct TciValueDifferenceList
+   {
+    long int length;
+-> TciValueDifference* diffList;
+   } TciValueDifferenceList;
+
+
+Section 9.6 p134
+
+      typedef struct TciObjidValue
+      {
+        long int length;
+        TciObjidElem *elements;
+      } TciObjidValue;
+      typedef struct TciObjidValue
+      {
+        long int length;
+-> TciObjidElemValue *elements;
+      } TciObjidValue;
+
+
+      typedef unsigned char[4] TciUCValue
+-> typedef unsigned char TciUCValue[4]
+
+
+      typedef struct TciUCStringValue
+      {
+        unsigned long int length;
+        TciUCType *string;
+      } TciUCStringValue;
+      typedef struct TciUCStringValue
+      {
+        unsigned long int length;
+-> TciUCValue *string;
+      } TciUCStringValue;
+
+
+
+
+------------------------------------------------------------------------------------
+TCI-CH
+
+Section 9.4.3.1 p127
+
+   void tciReplyConnected
+    (TriPortId sender, TriComponentId receiver, TriSignatureIdType signature,
+     TciParameterListType parameterList, Value returnValue)
+   void tciReplyConnected
+-> (TriPortId sender, TriComponentId receiver, TriSignatureId signature,
+     TciParameterListType parameterList, Value returnValue)
+
+
+   void tciReplyConnectedBC
+    (TriPortId sender, TriSignatureIdType signature, TciParameterListType parameterList,
+     Value returnValue)
+   void tciReplyConnectedBC
+-> (TriPortId sender, TriSignatureId signature, TciParameterListType parameterList,
+     Value returnValue)
+
+
+   void tciReplyConnectedMC
+    (TriPortId sender, TriComponentIdList receivers, TriSignatureIdType signature,
+     TciParameterListType parameterList, Value returnValue)
+   void tciReplyConnectedMC
+-> (TriPortId sender, TriComponentIdList receivers, TriSignatureId signature,
+     TciParameterListType parameterList, Value returnValue)
+
+
+   void tciStartTestComponentReq
+    (TriComponentId component, TciBehaviourIdType behavior, TciParamaterListType parameterList)
+   void tciStartTestComponentReq
+-> (TriComponentId component, TciBehaviourIdType behavior, TciParameterListType parameterList)
+
+
+Section 9.4.3.2 p128
+
+   void tciEnqueueRaiseConnected
+    (TriPortId sender, TriComponentId receiver, TriSignatureIdType signature, Value exception)
+   void tciEnqueueRaiseConnected
+-> (TriPortId sender, TriComponentId receiver, TriSignatureId signature, Value exception)
+
+
+   void tciStartTestComponent
+    (TriComponentId component, TciBehaviourIdType behavior, TciParamaterListType parameterList)
+   void tciStartTestComponent
+-> (TriComponentId component, TciBehaviourIdType behavior, TciParameterListType parameterList)
+
+
+------------------------------------------------------------------------------------
+TCI-TL
+
+Section 9.4.4.1 p128
+
+   void tliTcExecute
+    (String am, int ts, String src, int line, TriComponentId c, TciTestCaseIdType tcId,
+     TciParameterList tciPars, TriTimerDuration dur)
+   void tliTcExecute
+    (String am, int ts, String src, int line, TriComponentId c, TciTestCaseIdType tcId,
+-> TciParameterListType tciPars, TriTimerDuration dur)
+
+
+   void tliPrCall_m
+    (String am, int ts, String src, int line, TriComponentId c, TriPortId at, TriSignatureId signature,
+     TciParameterListType tciPars, Value addrValue, TriStatus encoderFailure,
+     TriParameterListType triPars, TriAddress address, TciStatus transmissionFailure)
+   void tliPrCall_m
+-> (String am, int ts, String src, int line, TriComponentId c, TriPortId at, TriPortId to, TriSignatureId signature,
+-> TciParameterListType tciPars, Value addrValue, TciStatus encoderFailure,
+-> TriParameterList triPars, TriAddress address, TriStatus transmissionFailure)
+
+
+   void tliPrCall_m_BC
+    (String am, int ts, String src, int line, TriComponentId c, TriPortId at, TriPortId to,
+     TriSignatureId signature, TciParameterListType tciPars, TciStatus encoderFailure,
+     TriParameterListType triPars, TriStatus transmissionFailure)
+   void tliPrCall_m_BC
+    (String am, int ts, String src, int line, TriComponentId c, TriPortId at, TriPortId to,
+     TriSignatureId signature, TciParameterListType tciPars, TciStatus encoderFailure,
+-> TriParameterList triPars, TriStatus transmissionFailure)
+
+
+   void tliPrCall_m_MC
+    (String am, int ts, String src, int line, TriComponentId c, TriPortId at, TriPortId to,
+     TriSignatureId signature, TciParameterListType tciPars, TciValueList addrValues,
+     TciStatus encoderFailure, TriParameterListType triPars, TriAddressList addresses,
+     TriStatus transmissionFailure)
+   void tliPrCall_m_MC
+    (String am, int ts, String src, int line, TriComponentId c, TriPortId at, TriPortId to,
+     TriSignatureId signature, TciParameterListType tciPars, TciValueList addrValues,
+-> TciStatus encoderFailure, TriParameterList triPars, TriAddressList addresses,
+     TriStatus transmissionFailure)
+
+
+   void tliPrCall_c
+    (String am, int ts, String srcint line, TriComponentId c, TriPortId at, TriSignatureId signature,
+     TciParameterListType tciPars, TriStatus transmissionFailure)
+   void tliPrCall_c
+-> (String am, int ts, String srcint line, TriComponentId c, TriPortId at, TriPortId to, TriSignatureId signature,
+     TciParameterListType tciPars, TriStatus transmissionFailure)
+
+
+   void tliPrReply_m
+    (String am, int ts, String src, int line, TriComponentId c, TriPortId at, TriPortId to,
+     TriSignatureIdType signature, TciParameterListType tciPars, Value replValue,
+     Value addrValue, TciStatus encoderFailure, TriParameterListType triPars,
+     TriParameter repl, TriAddress address, TriStatus transmissionFailure)
+   void tliPrReply_m
+    (String am, int ts, String src, int line, TriComponentId c, TriPortId at, TriPortId to,
+-> TriSignatureId signature, TciParameterListType tciPars, Value replValue,
+-> Value addrValue, TciStatus encoderFailure, TriParameterList triPars,
+     TriParameter repl, TriAddress address, TriStatus transmissionFailure)
+
+
+   void tliPrReply_m_BC
+    (String am, int ts, String src, int line, TriComponentId c, TriPortId at, TriPortId to,
+     TriSignatureIdType signature, TciParameterListType tciPars, Value replValue,
+     TciStatus encoderFailure, TriParameterListType triPars, TriParameter repl,
+     TriStatus transmissionFailure)
+   void tliPrReply_m_BC
+    (String am, int ts, String src, int line, TriComponentId c, TriPortId at, TriPortId to,
+-> TriSignatureId signature, TciParameterListType tciPars, Value replValue,
+-> TciStatus encoderFailure, TriParameterList triPars, TriParameter repl,
+     TriStatus transmissionFailure)
+
+
+   void tliPrReply_m_MC
+    (String am, int ts, String src, int line, TriComponentId c, TriPortId at, TriPortId to,
+     TriSignatureIdType signature, TciParameterListType tciPars, Value replValue,
+     TciValueList addrValues, TriStatus encoderFailure, TriParameterListType triPars,
+     TriParameter repl, TriAddressList addresses, TciStatus transmissionFailure)
+   void tliPrReply_m_MC
+    (String am, int ts, String src, int line, TriComponentId c, TriPortId at, TriPortId to,
+-> TriSignatureId signature, TciParameterListType tciPars, TciValue replValue,
+-> TciValueList addrValues, TriStatus encoderFailure, TriParameterList triPars,
+     TriParameter repl, TriAddressList addresses, TciStatus transmissionFailure)
+
+
+   void tliPrGetReplyDetected_m
+    (String am, int ts, String src, int line, TriComponentId c, TriPortId at, TriPortId from,
+     TriSignatureId signature, TriParameterListType triPars, TriParameter repl, TriAddress address)
+   void tliPrGetReplyDetected_m
+    (String am, int ts, String src, int line, TriComponentId c, TriPortId at, TriPortId from,
+-> TriSignatureId signature, TriParameterList triPars, TriParameter repl, TriAddress address)
+
+
+   void tliPDisconnect
+    (String am, int ts, String src, int line, TriComponentId c, TriComponentId c1, TriPortId port1,
+     TriComponentId c2, TriPortId port2)
+   void tliPDisconnect
+-> (String am, int ts, String src, int line, TriComponentId c, TriPortId port1, TriPortId port2)
+
+
+   void tliPUnmap
+    (String am, int ts, String src, int line, TriComponentId c, TriComponentId c1, TriPortId port1,
+     TriComponentId c2, TriPortId port2)
+-> void tliPUnmap
+    (String am, int ts, String src, int line, TriComponentId c, TriPortId port1, TriPortId port2)
+
+
+   void tliTTimeout
+    (String am, int ts, String src, int line, TriComponentId c, TriTimerIdType timer,
+     TciNonValueTemplate timerTmpl)
+   void tliTTimeout
+-> (String am, int ts, String src, int line, TriComponentId c, TriTimerId timer,
+     TciNonValueTemplate timerTmpl)
+
+
+   void tliSEnter
+    (String am, int ts, String src, int line, TriComponentId c,QualifiedName name,
+     TciParameterList tciPars, String kind)
+   void tliSEnter
+    (String am, int ts, String src, int line, TriComponentId c,QualifiedName name,
+-> TciParameterListType tciPars, String kind)
+
+
+
+
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR4299_Solution.doc (357,376) 16-10-2008 13:43
http://oldforge.etsi.org/mantis/file_download.php?file_id=1705&type=bug
doc CR4299_Solution_v2.doc (360,448) 06-11-2008 17:26
http://oldforge.etsi.org/mantis/file_download.php?file_id=1736&type=bug
doc CR4299_Solution_v3.doc (360,448) 21-11-2008 15:09
http://oldforge.etsi.org/mantis/file_download.php?file_id=1755&type=bug
zip es_20187306v040000_MasterCopy.zip (1,354,246) 12-12-2008 15:31
http://oldforge.etsi.org/mantis/file_download.php?file_id=1892&type=bug
Issue History
Date ModifiedUsernameFieldChange
15-10-2008 17:30Anthony BaireNew Issue
15-10-2008 17:30Anthony BaireStatusnew => assigned
15-10-2008 17:30Anthony BaireAssigned To => Ina Schieferdecker
15-10-2008 17:30Anthony BaireClause Reference(s) => Part 6 9.2 9.4 9.5 9.6
15-10-2008 17:30Anthony BaireSource (company - Author) =>
16-10-2008 13:43Ina SchieferdeckerNote Added: 0007095
16-10-2008 13:43Ina SchieferdeckerFile Added: CR4299_Solution.doc
16-10-2008 13:44Ina SchieferdeckerAssigned ToIna Schieferdecker => Thomas Deiß
16-10-2008 13:44Ina SchieferdeckerResolutionopen => fixed
16-10-2008 13:44Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
06-11-2008 17:26Anthony BaireFile Added: CR4299_Solution_v2.doc
06-11-2008 17:28Anthony BaireNote Added: 0007272
21-11-2008 15:09Thomas DeißFile Added: CR4299_Solution_v3.doc
21-11-2008 15:11Thomas DeißNote Added: 0007382
21-11-2008 15:11Thomas DeißAssigned ToThomas Deiß => Ina Schieferdecker
12-12-2008 13:58Ina SchieferdeckerFile Added: es_20187306v040000_MasterCopy.zip
12-12-2008 14:03Ina SchieferdeckerFile Deleted: es_20187306v040000_MasterCopy.zip
12-12-2008 14:03Ina SchieferdeckerFile Added: es_20187306v040000_MasterCopy.zip
12-12-2008 14:07Ina SchieferdeckerNote Added: 0007686
12-12-2008 14:07Ina SchieferdeckerAssigned ToIna Schieferdecker => Thomas Deiß
12-12-2008 14:07Ina SchieferdeckerStatusassigned => resolved
12-12-2008 14:07Ina SchieferdeckerFixed in Version => Edition 4.1.1 (not yet published)
12-12-2008 15:30Ina SchieferdeckerFile Deleted: es_20187306v040000_MasterCopy.zip
12-12-2008 15:31Ina SchieferdeckerFile Added: es_20187306v040000_MasterCopy.zip
14-12-2008 10:53Ina SchieferdeckerStatusresolved => closed
14-12-2008 10:53Ina SchieferdeckerAssigned ToThomas Deiß => Ina Schieferdecker
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0007095) +
+ Ina Schieferdecker    +
+ 16-10-2008 13:43    +
+ 		+ + + + +
+ See solution attached.
+
+
+
+ + + + + + + + + + +
+ (0007272) +
+ Anthony Baire    +
+ 06-11-2008 17:28    +
+ 		+ + + + +
+ all the changes were not merged. Please check the new document CR4299_Solution_v2.doc
+
+
+
+ + + + + + + + + + +
+ (0007382) +
+ Thomas Deiß    +
+ 21-11-2008 15:11    +
+ 		+ + + + +
+ corrections ok from my side. One further typo found in 9.4.3.2 -> corrected in CR4299_Solution_v3.doc.
+
+After updating the master copy, I'll do a separate crosscheck for parameterlist(type) in whole part6.
+
+
+
+ + + + + + + + + + +
+ (0007686) +
+ Ina Schieferdecker    +
+ 12-12-2008 14:07    +
+ 		+ + + + +
+ added the resolution to the master copy
+
+removed objid completely from TCI as this goes into Part 7
+
+please check
+
+ + diff --git a/docs/mantis/CR4300.md b/docs/mantis/CR4300.md new file mode 100644 index 0000000000000000000000000000000000000000..198d9cca3eefb39ae2c0f42df38ad7af3f089c23 --- /dev/null +++ b/docs/mantis/CR4300.md @@ -0,0 +1,143 @@ + + + + + + + + + + + + + 0004300: Mismatch in definition of tliDecode - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0004300Part 06: TTCN-3 Control InterfaceClarificationpublic15-10-2008 17:3612-12-2008 15:05
ReporterAnthony Baire 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.4.1 (published 2008-09) 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)Part 6 7.3.4.1.79
Source (company - Author)     
Summary0004300: Mismatch in definition of tliDecode
DescriptionThe parameter order in the signature of tliDecode in 7.3.4.19 does not match the order in the IDL definition (as well as the C & Java mappings)
+
+
+   void tliDecode(in TString am, in TInteger ts, in TString src,
+                  in TInteger line, in TriComponentIdType c,
+                  in Value val, in TciStatusType decoderFailure,
+                  in TriMessageType msg, in TString codec)
+   void tliDecode(in TString am, in TInteger ts, in TString src,
+                  in TInteger line, in TriComponentIdType c,
+-> in TriMessageType msg, in TciStatusType decoderFailure,
+-> in Value val, in TString codec)
+
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR4300_Solution.doc (52,736) 16-10-2008 12:37
http://oldforge.etsi.org/mantis/file_download.php?file_id=1704&type=bug
Issue History
Date ModifiedUsernameFieldChange
15-10-2008 17:36Anthony BaireNew Issue
15-10-2008 17:36Anthony BaireStatusnew => assigned
15-10-2008 17:36Anthony BaireAssigned To => Ina Schieferdecker
15-10-2008 17:36Anthony BaireClause Reference(s) => Part 6 7.3.4.1.79
15-10-2008 17:36Anthony BaireSource (company - Author) =>
16-10-2008 12:37Ina SchieferdeckerFile Added: CR4300_Solution.doc
16-10-2008 12:37Ina SchieferdeckerNote Added: 0007094
16-10-2008 12:38Ina SchieferdeckerAssigned ToIna Schieferdecker => Thomas Deiß
16-10-2008 12:38Ina SchieferdeckerResolutionopen => fixed
16-10-2008 12:38Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
06-11-2008 17:29Anthony BaireNote Added: 0007273
21-11-2008 14:38Thomas DeißNote Added: 0007381
21-11-2008 14:38Thomas DeißAssigned ToThomas Deiß => Ina Schieferdecker
12-12-2008 15:05Ina SchieferdeckerStatusassigned => resolved
12-12-2008 15:05Ina SchieferdeckerFixed in Version => Edition 4.1.1 (not yet published)
12-12-2008 15:05Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0007094) +
+ Ina Schieferdecker    +
+ 16-10-2008 12:37    +
+ 		+ + + + +
+ Please check solution.
+
+
+
+ + + + + + + + + + +
+ (0007273) +
+ Anthony Baire    +
+ 06-11-2008 17:29    +
+ 		+ + + + +
+ fine!
+
+
+
+ + + + + + + + + + +
+ (0007381) +
+ Thomas Deiß    +
+ 21-11-2008 14:38    +
+ 		+ + + + +
+ ok from me.
+
+ + diff --git a/docs/mantis/CR4301.md b/docs/mantis/CR4301.md new file mode 100644 index 0000000000000000000000000000000000000000..53c33f27405f49757f8fa966be1c35fb74be2678 --- /dev/null +++ b/docs/mantis/CR4301.md @@ -0,0 +1,64 @@ + + + + + + + + + + + + + 0004301: References [11], [12] and [13] are incorrect - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0004301Part 09: Using XML with TTCN-3Editorialpublic15-10-2008 17:5112-12-2008 11:31
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.3.1 (published 2008-04) 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)2.1
For STF discussion
Source (company - Author)L.M.Ericsson
Summary0004301: References [11], [12] and [13] are incorrect
DescriptionReferences [11], [12] and [13] are incorrectly worded. They were meant to point to ITU-T Recomendations X.693 and 694.
+It is proposed to delete reference [11] as reference [4] already points to X.694 and delete [13] as amendments are integral parts of the Recomendations, need not be referenced on its own. Reference [12] thus will become [11] and shall be corrected.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
15-10-2008 17:51Gyorgy RethyNew Issue
15-10-2008 17:51Gyorgy RethyStatusnew => assigned
15-10-2008 17:51Gyorgy RethyAssigned To => Gyorgy Rethy
15-10-2008 17:51Gyorgy RethyClause Reference(s) => 2.1
15-10-2008 17:51Gyorgy RethySource (company - Author) => L.M.Ericsson
15-10-2008 18:16Gyorgy RethyStatusassigned => closed
15-10-2008 18:16Gyorgy RethyNote Added: 0007083
15-10-2008 18:16Gyorgy RethyResolutionopen => fixed
15-10-2008 18:16Gyorgy RethyFixed in Version => Edition 4.1.1 (not yet published)
12-12-2008 11:31Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0007083) +
+ Gyorgy Rethy    +
+ 15-10-2008 18:16    +
+ 		+ + + + +
+ Delete all 3 references in question as not being used in the document.
+
+ + diff --git a/docs/mantis/CR4397.md b/docs/mantis/CR4397.md new file mode 100644 index 0000000000000000000000000000000000000000..6085ec214f1fadf47abb179e9c2ad283406bdc8f --- /dev/null +++ b/docs/mantis/CR4397.md @@ -0,0 +1,113 @@ + + + + + + + + + + + + + 0004397: Allow referencing embedded fields in attribute qualifier - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0004397Part 01: TTCN-3 Core LanguageNew Featurepublic30-10-2008 19:3210-12-2008 13:20
ReporterGyorgy Rethy 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)Annex A
Source (company - Author)L.M.Ericsson
Summary0004397: Allow referencing embedded fields in attribute qualifier
DescriptionCurrently no attributes can be assigned to embedded fields like this:
+type record MyRec {
+  integer field1,
+  record {
+    integer eField1,
+    boolean eField2
+  } field2
+} with {
+  extension (field2.eField1) "colour blue"
+// ^------^ this is not allowed
+}
+
+Proposed solution:
+Change
+532. DefOrFieldRef ::= DefinitionRef | FieldReference | AllRef
+to
+532. DefOrFieldRef ::= DefinitionRef | FieldReference [ExtendedFieldReference] | AllRef
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR4397_AttributesForFields.doc (30,208) 25-11-2008 10:15
http://oldforge.etsi.org/mantis/file_download.php?file_id=1768&type=bug
doc CR4397_AttributesForFields v2.doc (32,256) 25-11-2008 14:57
http://oldforge.etsi.org/mantis/file_download.php?file_id=1778&type=bug
Issue History
Date ModifiedUsernameFieldChange
30-10-2008 19:32Gyorgy RethyNew Issue
30-10-2008 19:32Gyorgy RethyStatusnew => assigned
30-10-2008 19:32Gyorgy RethyAssigned To => Ina Schieferdecker
30-10-2008 19:32Gyorgy RethyClause Reference(s) => Annex A
30-10-2008 19:32Gyorgy RethySource (company - Author) => L.M.Ericsson
25-11-2008 10:15Ina SchieferdeckerFile Added: CR4397_AttributesForFields.doc
25-11-2008 10:15Ina SchieferdeckerNote Added: 0007400
25-11-2008 10:15Ina SchieferdeckerResolutionopen => fixed
25-11-2008 10:15Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
25-11-2008 10:16Ina SchieferdeckerAssigned ToIna Schieferdecker => Gyorgy Rethy
25-11-2008 14:57Gyorgy RethyFile Added: CR4397_AttributesForFields v2.doc
25-11-2008 14:58Gyorgy RethyNote Added: 0007414
25-11-2008 14:59Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
10-12-2008 13:20Ina SchieferdeckerStatusassigned => resolved
10-12-2008 13:20Ina SchieferdeckerFixed in Version => Edition 4.1.1 (not yet published)
10-12-2008 13:20Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0007400) +
+ Ina Schieferdecker    +
+ 25-11-2008 10:15    +
+ 		+ + + + +
+ Please check.
+
+
+
+ + + + + + + + + + +
+ (0007414) +
+ Gyorgy Rethy    +
+ 25-11-2008 14:58    +
+ 		+ + + + +
+ Two editorial changes in the first and last (on overriding) paragraphs; otherwise Ok with me.
+
+ + diff --git a/docs/mantis/CR4401.md b/docs/mantis/CR4401.md new file mode 100644 index 0000000000000000000000000000000000000000..22f251f5f91d7b6defc3260f8a0013e37680735f --- /dev/null +++ b/docs/mantis/CR4401.md @@ -0,0 +1,139 @@ + + + + + + + + + + + + + 0004401: Referencing nested types of record/set ofs - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0004401Part 01: TTCN-3 Core LanguageNew Featurepublic31-10-2008 12:3810-12-2008 11:04
ReporterGyorgy Rethy 
Assigned ToIna Schieferdecker 
PriorityhighSeverityfeatureReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.3.2 (published 2008-04) 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)6.3
Source (company - Author)L.M.Ericsson
Summary0004401: Referencing nested types of record/set ofs
DescriptionCurrently we have an unsymmetry in TTCN-3: it is allowed to reference types embedded in records and sets but we cannot refer to types nested in record ofs and set ofs. This issue has been raised by STF160 as there are many structured types are defined as nested types in the ASN.1 specs and in case of types nested in record/set ofs it is not possible to define values or templates of these types. See proposed text in the attached document. Regarding the syntax different options would be possible:
+- using the index notation and ignoring the index - unpreferred as suggests referring to an instance;
+- using the index notation without the index (empty square brackets) - preferred
+- using the dot notation - unpreferred as inconsistent with record/set of value notation and record/set of elements do not have names, i.e. referencing via several levels of embedding would result "empty" dots like const MyRecOf... c_integer := 5;
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CRxxxx - referencing types embedded to record_set ofs.doc (1,032,704) 31-10-2008 12:38
http://oldforge.etsi.org/mantis/file_download.php?file_id=1734&type=bug
doc CR4401_referencing_types_embedded_to_record_set_ofs_v2.doc (1,042,432) 25-11-2008 09:07
http://oldforge.etsi.org/mantis/file_download.php?file_id=1766&type=bug
Issue History
Date ModifiedUsernameFieldChange
31-10-2008 12:38Gyorgy RethyNew Issue
31-10-2008 12:38Gyorgy RethyStatusnew => assigned
31-10-2008 12:38Gyorgy RethyAssigned To => Ina Schieferdecker
31-10-2008 12:38Gyorgy RethyFile Added: CRxxxx - referencing types embedded to record_set ofs.doc
31-10-2008 12:38Gyorgy RethyClause Reference(s) => 6.3
31-10-2008 12:38Gyorgy RethySource (company - Author) => L.M.Ericsson
31-10-2008 13:39tepelmannNote Added: 0007236
25-11-2008 09:06Ina SchieferdeckerNote Added: 0007398
25-11-2008 09:07Ina SchieferdeckerFile Added: CR4401_referencing_types_embedded_to_record_set_ofs_v2.doc
25-11-2008 09:07Ina SchieferdeckerAssigned ToIna Schieferdecker => Gyorgy Rethy
25-11-2008 09:07Ina SchieferdeckerResolutionopen => fixed
25-11-2008 09:07Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
26-11-2008 15:30Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
26-11-2008 15:31Gyorgy RethyNote Added: 0007453
26-11-2008 15:31Gyorgy RethyStatusassigned => resolved
10-12-2008 11:04Ina SchieferdeckerStatusresolved => closed
10-12-2008 11:04Ina SchieferdeckerFixed in Version => Edition 4.1.1 (not yet published)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0007236) +
+ tepelmann    +
+ 31-10-2008 13:39    +
+ 		+ + + + +
+ As it is dereferencing a type and the "empty" bracket notation is used in other non-TTCN-3 contexts for declarations, we would propose a further solution:
+
+- using the index notation whereby the index is '-'
+  type MyRecordOfInt[-] MyInteger;
+
+'-' is used already in TTCN-3 for out parameters in call operations as 'placeholder', as it is in this case as well.
+
+
+
+ + + + + + + + + + +
+ (0007398) +
+ Ina Schieferdecker    +
+ 25-11-2008 09:06    +
+ 		+ + + + +
+ As it is about the type of the record of/set of element it is right to go via the elements - and as the element index is irrelevant here, the use of dash is an adequate choice.
+
+
+
+ + + + + + + + + + +
+ (0007453) +
+ Gyorgy Rethy    +
+ 26-11-2008 15:31    +
+ 		+ + + + +
+ Checked, OK.
+
+ + diff --git a/docs/mantis/CR4402.md b/docs/mantis/CR4402.md new file mode 100644 index 0000000000000000000000000000000000000000..fb8861b2c8ab219239313c570ff9a3823a2d687a --- /dev/null +++ b/docs/mantis/CR4402.md @@ -0,0 +1,167 @@ + + + + + + + + + + + + + 0004402: Unneeded restriction in referencing record/set fields - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0004402Part 01: TTCN-3 Core LanguageTechnicalpublic31-10-2008 12:5410-12-2008 12:39
ReporterGyorgy Rethy 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.3.2 (published 2008-04) 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)6.2.1.1
Source (company - Author)     
Summary0004402: Unneeded restriction in referencing record/set fields
DescriptionThe current text says:
+"Elements of a record shall be referenced by the dot notation TypeOrValueId.ElementId, where TypeOrValueId resolves to the name of a structured type or variable."
+It is unneeded to restrict the reference to variables only, it should be allowed for values (all kind) and templates.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0004269closed Ina Schieferdecker Allow dotted and index notation for result of function calls 
Attached Filesdoc CR4402_DotNotation.doc (28,672) 25-11-2008 08:26
http://oldforge.etsi.org/mantis/file_download.php?file_id=1764&type=bug
Issue History
Date ModifiedUsernameFieldChange
31-10-2008 12:54Gyorgy RethyNew Issue
31-10-2008 12:54Gyorgy RethyStatusnew => assigned
31-10-2008 12:54Gyorgy RethyAssigned To => Ina Schieferdecker
31-10-2008 12:54Gyorgy RethyClause Reference(s) => 6.2.1.1
31-10-2008 12:54Gyorgy RethySource (company - Author) =>
31-10-2008 14:03tepelmannNote Added: 0007237
31-10-2008 14:28Gyorgy RethyNote Added: 0007241
24-11-2008 17:57Ina SchieferdeckerRelationship addedrelated to 0004269
25-11-2008 08:26Ina SchieferdeckerFile Added: CR4402_DotNotation.doc
25-11-2008 08:29Ina SchieferdeckerNote Added: 0007395
25-11-2008 08:30Ina SchieferdeckerAssigned ToIna Schieferdecker => Thomas Deiß
25-11-2008 08:30Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
25-11-2008 11:08Thomas DeißNote Added: 0007402
25-11-2008 11:08Thomas DeißAssigned ToThomas Deiß => Ina Schieferdecker
10-12-2008 12:39Ina SchieferdeckerStatusassigned => resolved
10-12-2008 12:39Ina SchieferdeckerResolutionopen => fixed
10-12-2008 12:39Ina SchieferdeckerFixed in Version => Edition 4.1.1 (not yet published)
10-12-2008 12:39Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0007237) +
+ tepelmann    +
+ 31-10-2008 14:03    +
+ 		+ + + + +
+ Maybe this issue can be merged with issue#0004269, or is it a duplicate?
+
+
+
+ + + + + + + + + + +
+ (0007241) +
+ Gyorgy Rethy    +
+ 31-10-2008 14:28    +
+ 		+ + + + +
+ No, this issue differs from CR4269. While this one is a simple wrong wording that needs to be corrected (pls. note, the BNF allows using field/index references in constant expressions, template variables etc.), CR4269 requests for a new feature that needs to be discussed. Thus this CR can be resolved independent of CR4269.
+
+
+
+ + + + + + + + + + +
+ (0007395) +
+ Ina Schieferdecker    +
+ 25-11-2008 08:29    +
+ 		+ + + + +
+ Indeed, already now more is allowed for the dot notation than just variables - still, it is quite artificial not to allow function invocations as well. I uploaded a proposal which addresses both CRs - please check.
+
+
+
+ + + + + + + + + + +
+ (0007402) +
+ Thomas Deiß    +
+ 25-11-2008 11:08    +
+ 		+ + + + +
+ The resolution is ok.
+
+ + diff --git a/docs/mantis/CR4410.md b/docs/mantis/CR4410.md new file mode 100644 index 0000000000000000000000000000000000000000..fb2c898cd37f8fcb9aa318b40766edbbbfe5d9bf --- /dev/null +++ b/docs/mantis/CR4410.md @@ -0,0 +1,89 @@ + + + + + + + + + + + + + 0004410: Style of attributes in examples - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0004410Part 09: Using XML with TTCN-3Editorialpublic05-11-2008 14:0720-04-2009 11:45
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.3.1 (published 2008-04) 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)All
For STF discussion
Source (company - Author)L.M.Ericsson
Summary0004410: Style of attributes in examples
DescriptionCurrently 3 styles are used in the standard:
+type record Mytype {
+...
+} with {
+  variant ...
+}
+
+type record Mytype {
+...
+}
+with
+{
+  variant ...
+}
+and
+type record Mytype {
+...
+} with { variant ... }
+
+it it proposed to use the unique style (also consistent with the type definitions):
+type record Mytype {
+...
+}
+with {
+  variant ...
+}
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
05-11-2008 14:07Gyorgy RethyNew Issue
05-11-2008 14:07Gyorgy RethyStatusnew => assigned
05-11-2008 14:07Gyorgy RethyAssigned To => Gyorgy Rethy
05-11-2008 14:07Gyorgy RethyClause Reference(s) => All
05-11-2008 14:07Gyorgy RethySource (company - Author) => L.M.Ericsson
27-11-2008 14:26Gyorgy RethyStatusassigned => resolved
27-11-2008 14:26Gyorgy RethyResolutionopen => fixed
27-11-2008 14:26Gyorgy RethyNote Added: 0007478
12-12-2008 11:31Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
17-12-2008 09:38Ina SchieferdeckerFixed in Version => Edition 4.1.1 (not yet published)
20-04-2009 11:45Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0007478) +
+ Gyorgy Rethy    +
+ 27-11-2008 14:26    +
+ 		+ + + + +
+ minor editorial, to be implemented
+
+ + diff --git a/docs/mantis/CR4411.md b/docs/mantis/CR4411.md new file mode 100644 index 0000000000000000000000000000000000000000..9c711fd0eb26ff8c67bbdfda688b9c809a578122 --- /dev/null +++ b/docs/mantis/CR4411.md @@ -0,0 +1,187 @@ + + + + + + + + + + + + + 0004411: Use of field names in encoding instructions - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0004411Part 09: Using XML with TTCN-3Technicalpublic05-11-2008 14:1820-04-2009 11:44
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PriorityhighSeveritymajorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)All
For STF discussion
Source (company - Author)L.M.Ericsson
Summary0004411: Use of field names in encoding instructions
DescriptionCurrently in several examples the name of the field, to which an encoding instruction shall be associated, is included into the variant attribute; e.g.
+type record E17a {
+       XSD.Float bar optional,
+    XSD.Integer foo optional
+}
+with {
+  variant "attribute 'foo', 'bar'";
+  variant "name as uncapitalized ";
+}
+TTCN-3 provides a standard mechanism to associate attributes to fields which is already implemented in tools. Therefore this standard mechanism shall be used instead of the XSD-mapping specific one. This simplifies the implementation of TTCN-3 compilers. E.g. the example above becomes:
+type record E17a {
+       XSD.Float bar optional,
+    XSD.Integer foo optional
+}
+with {
+  variant "name as uncapitalized ";
+  variant (bar, foo) "attribute"
+}
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc es_20187309v030301p_comments.doc (937,984) 26-11-2008 07:43
http://oldforge.etsi.org/mantis/file_download.php?file_id=1784&type=bug
Issue History
Date ModifiedUsernameFieldChange
05-11-2008 14:18Gyorgy RethyNew Issue
05-11-2008 14:18Gyorgy RethyStatusnew => assigned
05-11-2008 14:18Gyorgy RethyAssigned To => Gyorgy Rethy
05-11-2008 14:18Gyorgy RethyClause Reference(s) => All
05-11-2008 14:18Gyorgy RethySource (company - Author) => L.M.Ericsson
25-11-2008 10:39Gyorgy RethyAssigned ToGyorgy Rethy => Thomas Deiß
26-11-2008 07:43Thomas DeißFile Added: es_20187309v030301p_comments.doc
26-11-2008 07:45Thomas DeißNote Added: 0007431
26-11-2008 07:45Thomas DeißAssigned ToThomas Deiß => Gyorgy Rethy
10-12-2008 10:00Gyorgy RethyNote Added: 0007619
10-12-2008 10:00Gyorgy RethyStatusassigned => resolved
10-12-2008 10:00Gyorgy RethyResolutionopen => fixed
10-12-2008 10:01Gyorgy RethyNote Added: 0007620
10-12-2008 10:01Gyorgy RethyNote Added: 0007621
12-12-2008 11:30Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
17-12-2008 09:39Ina SchieferdeckerFixed in Version => Edition 4.1.1 (not yet published)
20-04-2009 11:44Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0007431) +
+ Thomas Deiß    +
+ 26-11-2008 07:45    +
+ 		+ + + + +
+ Proposed change is ok for me.
+There was no solution file.
+I crosschecked part 9 where this change would be relevant. At least some of the occurrences are already handled by the other CRs.
+There are also a couple of other issues, please crosscheck in the attached commented version of part 9.
+
+
+
+
+ + + + + + + + + + +
+ (0007619) +
+ Gyorgy Rethy    +
+ 10-12-2008 10:00    +
+ 		+ + + + +
+ Changes to be done by cross-checking the master document after aother CRs are implemented.
+
+
+
+ + + + + + + + + + +
+ (0007620) +
+ Gyorgy Rethy    +
+ 10-12-2008 10:01    +
+ 		+ + + + +
+ Changes to be done by cross-checking the master document after aother CRs are implemented.
+
+
+
+ + + + + + + + + + +
+ (0007621) +
+ Gyorgy Rethy    +
+ 10-12-2008 10:01    +
+ 		+ + + + +
+ Changes to be done by cross-checking the master document after aother CRs are implemented.
+
+ + diff --git a/docs/mantis/CR4430.md b/docs/mantis/CR4430.md new file mode 100644 index 0000000000000000000000000000000000000000..4aae84c0b20205381ef1598b89b73174ee606c2c --- /dev/null +++ b/docs/mantis/CR4430.md @@ -0,0 +1,166 @@ + + + + + + + + + + + + + 0004430: TTCN-3 language tags and TTCN-3 standard versions should be consistent - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0004430Part 01: TTCN-3 Core LanguageClarificationpublic10-11-2008 13:4210-12-2008 09:29
ReporterIna Schieferdecker 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)Clause 8.2.3.6 and Annex H
Source (company - Author)Fraunhofer FOKUS - Ina Schieferdecker
Summary0004430: TTCN-3 language tags and TTCN-3 standard versions should be consistent
DescriptionThere is a mismatch of the TTCN-3 version (years) between clause 8.2.3.6 and annex H.
+
+Clause 8.2.3.6 on "Import definitions from other TTCN 3 editions and from non-TTCN 3 modules" defines:
+
+- "TTCN 3:2001" - to be used with modules complying with version 1.1.2 of the present document (see annex H).
+
+- "TTCN 3:2003" - to be used with modules complying with version 2.2.1 of the present document (see annex H).
+
+- "TTCN 3:2005" - to be used with modules complying with version 3.2.1 of the present document (see annex H).
+
+- "TTCN 3:2008" - to be used with modules complying with version 3.3.2 of the present document (see annex H).
+
+- "TTCN 3:2008 Amendment 1" - to be used with modules complying with version 3.4.1 of the present document (see annex H)
+
+
+
+Annex H Bibliography references
+
+• ETSI ES 201 873-1 (V1.1.2): "Methods for Testing and Specification (MTS); The Tree and Tabular Combined Notation version 3; Part 1: TTCN 3 Core Language", June 2001.
+• ETSI ES 201 873-1 (V2.2.1): "Methods for Testing and Specification (MTS); The Testing and Test Control Notation version 3; Part 1: TTCN 3 Core Language", June 2006.
+• ETSI ES 201 873-1 (V3.2.1): "Methods for Testing and Specification (MTS); The Testing and Test Control Notation version 3; Part 1: TTCN 3 Core Language", February 2007.
+• ETSI ES 201 873-1 (V3.3.2): "Methods for Testing and Specification (MTS); The Testing and Test Control Notation version 3; Part 1: TTCN 3 Core Language", April 2008.
+• ETSI ES 201 873-1 (V3.4.1): "Methods for Testing and Specification (MTS); The Testing and Test Control Notation version 3; Part 1: TTCN 3 Core Language", Sept. 2008.
+
+
+--> Years and versions are messed up: there are no 2003 and 2005 standard versions, but language tags. There are 2006 and 2007 standard versions but no language tags.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR4430_LanguageTags.doc (30,720) 24-11-2008 12:06
http://oldforge.etsi.org/mantis/file_download.php?file_id=1759&type=bug
Issue History
Date ModifiedUsernameFieldChange
10-11-2008 13:42Ina SchieferdeckerNew Issue
10-11-2008 13:42Ina SchieferdeckerStatusnew => assigned
10-11-2008 13:42Ina SchieferdeckerAssigned To => Gyorgy Rethy
10-11-2008 13:42Ina SchieferdeckerClause Reference(s) => Clause 8.2.3.6 and Annex H
10-11-2008 13:42Ina SchieferdeckerSource (company - Author) => Fraunhofer FOKUS - Ina Schieferdecker
10-11-2008 14:19Gyorgy RethyNote Added: 0007288
10-11-2008 14:20Gyorgy RethyNote Edited: 0007288
10-11-2008 14:21Gyorgy RethyNote Edited: 0007288
24-11-2008 12:06Ina SchieferdeckerFile Added: CR4430_LanguageTags.doc
24-11-2008 12:06Ina SchieferdeckerNote Added: 0007387
24-11-2008 12:07Ina SchieferdeckerProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
24-11-2008 12:07Ina SchieferdeckerResolutionopen => fixed
24-11-2008 12:07Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
26-11-2008 12:22Gyorgy RethyNote Added: 0007446
26-11-2008 12:22Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
26-11-2008 12:22Gyorgy RethyStatusassigned => resolved
10-12-2008 09:29Ina SchieferdeckerStatusresolved => closed
10-12-2008 09:29Ina SchieferdeckerFixed in Version => Edition 4.1.1 (not yet published)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0007288) +
+ Gyorgy Rethy    +
+ 10-11-2008 14:19    +
(edited on: 10-11-2008 14:21)
+ 		+ + + + +
+ The relationship is:
+TTCN-3 version | date of publication | lang. tag
+  1.1.2 | 2001-06 | 2001
+  2.2.1 | 2003-02 | 2003
+  3.1.1 | 2005-06 | 2005
+  3.2.1 | 2007-02 | 2007
+  3.3.1/2 | 2008-04 | 2008
+  3.4.1 | 2008-09 | 2008 Amendment1
+proposed to add the information to annex H.
+
+
+
+
+
+ + + + + + + + + + +
+ (0007387) +
+ Ina Schieferdecker    +
+ 24-11-2008 12:06    +
+ 		+ + + + +
+ Please check.
+
+
+
+ + + + + + + + + + +
+ (0007446) +
+ Gyorgy Rethy    +
+ 26-11-2008 12:22    +
+ 		+ + + + +
+ Checked, OK.
+
+ + diff --git a/docs/mantis/CR4437.md b/docs/mantis/CR4437.md new file mode 100644 index 0000000000000000000000000000000000000000..837f5aedf1c9dabd22511f222fa470cdf7e52f56 --- /dev/null +++ b/docs/mantis/CR4437.md @@ -0,0 +1,106 @@ + + + + + + + + + + + + + 0004437: Allow template references in permutation - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0004437Part 01: TTCN-3 Core LanguageNew Featurepublic11-11-2008 14:1610-12-2008 09:22
ReporterGyorgy Rethy 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.3.2 (published 2008-04) 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)B.1.3.3
Source (company - Author)L.M.Ericsson
Summary0004437: Allow template references in permutation
DescriptionThe problem has been raised by STF160: in some cases a record of record structure has to be checked, namely it has to be verified if one instance of the record is present in the list; moreover, the position of the record containing the field-to-be-checked is not known and not all fields of the given record has to be checked or even known. In another words, it has to be checked, if any elements of a record of record value is matching a record template or not.
+
+However, TTCN-3 today does not allow referencing templates within permutation; only expressions, ? and * are allowed. Thus, this is not allowed:
+{permutation(cr_MyRecordTemplate,*)}
+
+Proposed to allow referencing templates within permutation (see attached file).
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR - template refernce in permutation.doc (180,736) 11-11-2008 14:16
http://oldforge.etsi.org/mantis/file_download.php?file_id=1740&type=bug
doc CR - template refernce in permutation_02.doc (175,104) 25-11-2008 08:31
http://oldforge.etsi.org/mantis/file_download.php?file_id=1765&type=bug
Issue History
Date ModifiedUsernameFieldChange
11-11-2008 14:16Gyorgy RethyNew Issue
11-11-2008 14:16Gyorgy RethyStatusnew => assigned
11-11-2008 14:16Gyorgy RethyAssigned To => Ina Schieferdecker
11-11-2008 14:16Gyorgy RethyFile Added: CR - template refernce in permutation.doc
11-11-2008 14:16Gyorgy RethyClause Reference(s) => B.1.3.3
11-11-2008 14:16Gyorgy RethySource (company - Author) => L.M.Ericsson
24-11-2008 17:00Ina SchieferdeckerAssigned ToIna Schieferdecker => Thomas Deiß
25-11-2008 08:31Thomas DeißFile Added: CR - template refernce in permutation_02.doc
25-11-2008 08:33Thomas DeißNote Added: 0007396
25-11-2008 08:33Thomas DeißAssigned ToThomas Deiß => Gyorgy Rethy
25-11-2008 16:38Gyorgy RethyNote Added: 0007423
25-11-2008 16:39Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
25-11-2008 16:39Gyorgy RethyStatusassigned => resolved
25-11-2008 16:39Gyorgy RethyResolutionopen => fixed
10-12-2008 09:22Ina SchieferdeckerStatusresolved => closed
10-12-2008 09:22Ina SchieferdeckerFixed in Version => Edition 4.1.1 (not yet published)
10-12-2008 09:22Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0007396) +
+ Thomas Deiß    +
+ 25-11-2008 08:33    +
+ 		+ + + + +
+ changes in 1st paragraph clarify the semantics.
+changes in 2nd paragraph are editorial.
+This is for cross checking.
+uploaded v02.
+
+
+
+ + + + + + + + + + +
+ (0007423) +
+ Gyorgy Rethy    +
+ 25-11-2008 16:38    +
+ 		+ + + + +
+ OK with me.
+
+ + diff --git a/docs/mantis/CR4468.md b/docs/mantis/CR4468.md new file mode 100644 index 0000000000000000000000000000000000000000..dab3e4b1e72d3cb032d8ebdaafcd330b94f57d26 --- /dev/null +++ b/docs/mantis/CR4468.md @@ -0,0 +1,167 @@ + + + + + + + + + + + + + 0004468: Text describing mapping of XSD elements incomplete - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0004468Part 09: Using XML with TTCN-3Technicalpublic19-11-2008 17:0912-12-2008 11:30
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)7.3
For STF discussion
Source (company - Author)L.M.Ericsson
Summary0004468: Text describing mapping of XSD elements incomplete
DescriptionThe current text does not completely specify the mapping of XSD elements. See proposed text in the attached file.
+Pls. note, CRs 4468 to 4473 shall be read jointly as the text is mutually referncing each other.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR4468 - elements.doc (94,720) 25-11-2008 10:31
http://oldforge.etsi.org/mantis/file_download.php?file_id=1771&type=bug
doc CR4468 - elements_02.doc (95,232) 25-11-2008 17:00
http://oldforge.etsi.org/mantis/file_download.php?file_id=1780&type=bug
doc CR4468_-_elements_03.doc (95,232) 27-11-2008 14:29
http://oldforge.etsi.org/mantis/file_download.php?file_id=1818&type=bug
Issue History
Date ModifiedUsernameFieldChange
19-11-2008 17:09Gyorgy RethyNew Issue
19-11-2008 17:09Gyorgy RethyStatusnew => assigned
19-11-2008 17:09Gyorgy RethyAssigned To => Gyorgy Rethy
19-11-2008 17:09Gyorgy RethyClause Reference(s) => 7.3
19-11-2008 17:09Gyorgy RethySource (company - Author) => L.M.Ericsson
19-11-2008 17:29Gyorgy RethyDescription Updated
25-11-2008 10:31Gyorgy RethyFile Added: CR4468 - elements.doc
25-11-2008 10:31Gyorgy RethyAssigned ToGyorgy Rethy => Thomas Deiß
25-11-2008 17:00Thomas DeißFile Added: CR4468 - elements_02.doc
25-11-2008 17:01Thomas DeißNote Added: 0007425
25-11-2008 17:01Thomas DeißAssigned ToThomas Deiß => Gyorgy Rethy
27-11-2008 14:29Gyorgy RethyFile Added: CR4468_-_elements_03.doc
27-11-2008 14:30Gyorgy RethyStatusassigned => resolved
27-11-2008 14:30Gyorgy RethyResolutionopen => fixed
27-11-2008 14:30Gyorgy RethyNote Added: 0007479
10-12-2008 14:26Gyorgy RethyStatusresolved => closed
10-12-2008 14:26Gyorgy RethyNote Added: 0007631
10-12-2008 14:26Gyorgy RethyFixed in Version => Edition 4.1.1 (not yet published)
10-12-2008 14:27Gyorgy RethyNote Added: 0007632
12-12-2008 11:30Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0007425) +
+ Thomas Deiß    +
+ 25-11-2008 17:01    +
+ 		+ + + + +
+ two typos found, otherwise ok.
+version 02 uploaded.
+
+
+
+ + + + + + + + + + +
+ (0007479) +
+ Gyorgy Rethy    +
+ 27-11-2008 14:30    +
+ 		+ + + + +
+ To be added to master document (crosscheck is needed when all CRs are added to master)
+
+
+
+ + + + + + + + + + +
+ (0007631) +
+ Gyorgy Rethy    +
+ 10-12-2008 14:26    +
+ 		+ + + + +
+ Added to master copy (v3.3.4)
+
+
+
+ + + + + + + + + + +
+ (0007632) +
+ Gyorgy Rethy    +
+ 10-12-2008 14:27    +
+ 		+ + + + +
+ Added to master copy (v3.3.4)
+
+ + diff --git a/docs/mantis/CR4469.md b/docs/mantis/CR4469.md new file mode 100644 index 0000000000000000000000000000000000000000..d95206940ab77f543230ee73f5582dc4f2996861 --- /dev/null +++ b/docs/mantis/CR4469.md @@ -0,0 +1,168 @@ + + + + + + + + + + + + + 0004469: Clause describing mapping of attributes (of XSD elements) is incomplete - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0004469Part 09: Using XML with TTCN-3Technicalpublic19-11-2008 17:1312-12-2008 11:30
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)7.1
For STF discussion
Source (company - Author)L.M.Ericsson
Summary0004469: Clause describing mapping of attributes (of XSD elements) is incomplete
DescriptionDescription of the Ref atribute is incorrect and specification of the effects minOccurs, maxOccurs and nillable attributes is sporadic.
+See proposed text in attached file.
+Pls. note, CRs 4468 to 4473 shall be read jointly as the text is mutually referncing each other.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR4469 - XSD attributes v2.doc (224,768) 27-11-2008 14:38
http://oldforge.etsi.org/mantis/file_download.php?file_id=1820&type=bug
doc CR4469_-_XSD_attributes_v3 DT.doc (223,744) 27-11-2008 14:39
http://oldforge.etsi.org/mantis/file_download.php?file_id=1821&type=bug
doc CR4469_-_XSD_attributes_v4.doc (224,256) 27-11-2008 14:42
http://oldforge.etsi.org/mantis/file_download.php?file_id=1822&type=bug
Issue History
Date ModifiedUsernameFieldChange
19-11-2008 17:13Gyorgy RethyNew Issue
19-11-2008 17:13Gyorgy RethyStatusnew => assigned
19-11-2008 17:13Gyorgy RethyAssigned To => Gyorgy Rethy
19-11-2008 17:13Gyorgy RethyFile Added: CR - XSD attributes.doc
19-11-2008 17:13Gyorgy RethyClause Reference(s) => 7.1
19-11-2008 17:13Gyorgy RethySource (company - Author) => L.M.Ericsson
19-11-2008 17:29Gyorgy RethyDescription Updated
20-11-2008 08:31Gyorgy RethySummaryClause describing mapping of attributes to XSD elements is incomplete => Clause describing mapping of attributes (of XSD elements) is incomplete
25-11-2008 10:32Gyorgy RethyAssigned ToGyorgy Rethy => Thomas Deiß
26-11-2008 07:20Thomas DeißNote Added: 0007426
26-11-2008 07:20Thomas DeißAssigned ToThomas Deiß => Gyorgy Rethy
26-11-2008 07:20Thomas DeißRelationship addedrelated to 0004470
27-11-2008 14:33Gyorgy RethyFile Deleted: CR - XSD attributes.doc
27-11-2008 14:34Gyorgy RethyFile Added: CR4469 - attribute elements.doc
27-11-2008 14:35Gyorgy RethyFile Deleted: CR4469 - attribute elements.doc
27-11-2008 14:38Gyorgy RethyFile Added: CR4469 - XSD attributes v2.doc
27-11-2008 14:39Gyorgy RethyFile Added: CR4469_-_XSD_attributes_v3 DT.doc
27-11-2008 14:42Gyorgy RethyFile Added: CR4469_-_XSD_attributes_v4.doc
27-11-2008 14:44Gyorgy RethyNote Added: 0007480
27-11-2008 14:45Gyorgy RethyStatusassigned => resolved
27-11-2008 14:45Gyorgy RethyResolutionopen => fixed
27-11-2008 14:45Gyorgy RethyNote Added: 0007481
27-11-2008 14:46Gyorgy RethyRelationship deletedrelated to 0004470
10-12-2008 14:27Gyorgy RethyStatusresolved => closed
10-12-2008 14:27Gyorgy RethyNote Added: 0007633
10-12-2008 14:27Gyorgy RethyFixed in Version => Edition 4.1.1 (not yet published)
12-12-2008 11:30Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0007426) +
+ Thomas Deiß    +
+ 26-11-2008 07:20    +
+ 		+ + + + +
+ not checked separately. Solution of this CR seems to be included in the solution for CR 4470.
+
+
+
+
+ + + + + + + + + + +
+ (0007480) +
+ Gyorgy Rethy    +
+ 27-11-2008 14:44    +
+ 		+ + + + +
+ Actually file "CR4470 - XSD attributes v2.doc" was uploaded to CR4470 (and named CR4470...) erroneously, should have been uploaded here. Thomas's file with his comments is moved to this CR.
+
+
+
+ + + + + + + + + + +
+ (0007481) +
+ Gyorgy Rethy    +
+ 27-11-2008 14:45    +
+ 		+ + + + +
+ To be added to master docuent (to be crosschecked after all CRs added).
+
+
+
+ + + + + + + + + + +
+ (0007633) +
+ Gyorgy Rethy    +
+ 10-12-2008 14:27    +
+ 		+ + + + +
+ Added to master copy (v3.3.4)
+
+ + diff --git a/docs/mantis/CR4470.md b/docs/mantis/CR4470.md new file mode 100644 index 0000000000000000000000000000000000000000..a44dd8c9cb4c2b2b446974d94bb31701ea90e619 --- /dev/null +++ b/docs/mantis/CR4470.md @@ -0,0 +1,202 @@ + + + + + + + + + + + + + 0004470: Mapping of XSd attribute elements is incomplete - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0004470Part 09: Using XML with TTCN-3Technicalpublic19-11-2008 17:1612-12-2008 11:29
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)7.4
For STF discussion
Source (company - Author)L.M.Ericsson
Summary0004470: Mapping of XSd attribute elements is incomplete
DescriptionThe text describing mapping of global XSD attribute elements is incomplete and specification of mapping of global attributeGroup definitions is missing.
+See proposed text in attached file.
+Pls. note, CRs 4468 to 4473 shall be read jointly as the text is mutually referncing each other.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR-attribute elements.doc (110,080) 19-11-2008 17:16
http://oldforge.etsi.org/mantis/file_download.php?file_id=1750&type=bug
Issue History
Date ModifiedUsernameFieldChange
19-11-2008 17:16Gyorgy RethyNew Issue
19-11-2008 17:16Gyorgy RethyStatusnew => assigned
19-11-2008 17:16Gyorgy RethyAssigned To => Gyorgy Rethy
19-11-2008 17:16Gyorgy RethyFile Added: CR-attribute elements.doc
19-11-2008 17:16Gyorgy RethyClause Reference(s) => 7.4
19-11-2008 17:16Gyorgy RethySource (company - Author) => L.M.Ericsson
19-11-2008 17:30Gyorgy RethyDescription Updated
25-11-2008 10:33Gyorgy RethyFile Added: CR4470 - XSD attributes v2.doc
25-11-2008 10:33Gyorgy RethyAssigned ToGyorgy Rethy => Thomas Deiß
26-11-2008 07:20Thomas DeißRelationship addedrelated to 0004469
26-11-2008 07:23Thomas DeißFile Added: CR4470 - XSD attributes v3.doc
26-11-2008 07:25Thomas DeißNote Added: 0007427
26-11-2008 07:35Thomas DeißAssigned ToThomas Deiß => Gyorgy Rethy
27-11-2008 14:46Gyorgy RethyRelationship deletedrelated to 0004469
27-11-2008 14:47Gyorgy RethyNote Added: 0007482
27-11-2008 14:47Gyorgy RethyFile Deleted: CR4470 - XSD attributes v3.doc
27-11-2008 14:47Gyorgy RethyFile Deleted: CR4470 - XSD attributes v2.doc
27-11-2008 14:48Gyorgy RethyAssigned ToGyorgy Rethy => Thomas Deiß
27-11-2008 15:44Thomas DeißNote Added: 0007487
27-11-2008 15:44Thomas DeißAssigned ToThomas Deiß => Gyorgy Rethy
28-11-2008 08:16Gyorgy RethyStatusassigned => resolved
28-11-2008 08:16Gyorgy RethyResolutionopen => fixed
28-11-2008 08:16Gyorgy RethyNote Added: 0007489
10-12-2008 14:27Gyorgy RethyStatusresolved => closed
10-12-2008 14:27Gyorgy RethyNote Added: 0007634
10-12-2008 14:27Gyorgy RethyFixed in Version => Edition 4.1.1 (not yet published)
12-12-2008 11:29Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0007427) +
+ Thomas Deiß    +
+ 26-11-2008 07:25    +
+ 		+ + + + +
+ a few editorial corrections, otherwise ok. CR_4470_XSD_attributes_v3 uploaded.
+Is this actually the intended solution, there is also the file CR_attribute_elements?
+
+
+
+ + + + + + + + + + +
+ (0007482) +
+ Gyorgy Rethy    +
+ 27-11-2008 14:47    +
+ 		+ + + + +
+ Actually file CR4470 - XSD attributes v2doc was erroneously uploaded here, should have been uploaded to CR4469. The file ~v3 with Thimas's comments is moved to CR4469.
+
+
+
+ + + + + + + + + + +
+ (0007487) +
+ Thomas Deiß    +
+ 27-11-2008 15:44    +
+ 		+ + + + +
+ ok.
+
+
+
+ + + + + + + + + + +
+ (0007489) +
+ Gyorgy Rethy    +
+ 28-11-2008 08:16    +
+ 		+ + + + +
+ To add to master document (to be crosschecked when all CRs are added)
+
+
+
+ + + + + + + + + + +
+ (0007634) +
+ Gyorgy Rethy    +
+ 10-12-2008 14:27    +
+ 		+ + + + +
+ Added to master copy (v3.3.4)
+
+ + diff --git a/docs/mantis/CR4471.md b/docs/mantis/CR4471.md new file mode 100644 index 0000000000000000000000000000000000000000..b8f735d93047a8dea81f38c397d938dbab14e1ba --- /dev/null +++ b/docs/mantis/CR4471.md @@ -0,0 +1,134 @@ + + + + + + + + + + + + + 0004471: Mapping of complex types is incomplete and contains errors - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0004471Part 09: Using XML with TTCN-3Technicalpublic19-11-2008 17:2112-12-2008 11:29
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)7.6
For STF discussion
Source (company - Author)L.M.Ericsson
Summary0004471: Mapping of complex types is incomplete and contains errors
DescriptionRules of mapping XSD complexTypes is significantly incomplete and contains some errors (e.g. local attributes, attribute references and attribute groups shall be mapped jointly).
+See proposed text in the attached file.
+Pls. note, CRs 4468 to 4473 shall be read jointly as the text is mutually referencing each other.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR - complexTypes.doc (484,352) 19-11-2008 17:21
http://oldforge.etsi.org/mantis/file_download.php?file_id=1751&type=bug
doc CR4471 - complexTypes v2.doc (501,248) 25-11-2008 10:34
http://oldforge.etsi.org/mantis/file_download.php?file_id=1773&type=bug
doc CR4471 - complexTypes v3.doc (507,392) 26-11-2008 07:29
http://oldforge.etsi.org/mantis/file_download.php?file_id=1782&type=bug
doc CR4471_-_complexTypes_v4.doc (512,000) 27-11-2008 15:30
http://oldforge.etsi.org/mantis/file_download.php?file_id=1824&type=bug
Issue History
Date ModifiedUsernameFieldChange
19-11-2008 17:21Gyorgy RethyNew Issue
19-11-2008 17:21Gyorgy RethyStatusnew => assigned
19-11-2008 17:21Gyorgy RethyAssigned To => Gyorgy Rethy
19-11-2008 17:21Gyorgy RethyFile Added: CR - complexTypes.doc
19-11-2008 17:21Gyorgy RethyClause Reference(s) => 7.6
19-11-2008 17:21Gyorgy RethySource (company - Author) => L.M.Ericsson
19-11-2008 17:30Gyorgy RethyDescription Updated
25-11-2008 10:34Gyorgy RethyFile Added: CR4471 - complexTypes v2.doc
25-11-2008 10:34Gyorgy RethyAssigned ToGyorgy Rethy => Thomas Deiß
26-11-2008 07:29Thomas DeißFile Added: CR4471 - complexTypes v3.doc
26-11-2008 07:35Thomas DeißNote Added: 0007428
26-11-2008 07:35Thomas DeißAssigned ToThomas Deiß => Gyorgy Rethy
27-11-2008 15:30Gyorgy RethyFile Added: CR4471_-_complexTypes_v4.doc
27-11-2008 15:31Gyorgy RethyStatusassigned => resolved
27-11-2008 15:31Gyorgy RethyResolutionopen => fixed
27-11-2008 15:31Gyorgy RethyNote Added: 0007484
10-12-2008 14:29Gyorgy RethyStatusresolved => closed
10-12-2008 14:29Gyorgy RethyNote Added: 0007635
10-12-2008 14:29Gyorgy RethyFixed in Version => Edition 4.1.1 (not yet published)
12-12-2008 11:29Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0007428) +
+ Thomas Deiß    +
+ 26-11-2008 07:35    +
+ 		+ + + + +
+ editorial corrections only. v3 uploaded.
+The solution contains quite many changes. I suggest to review whole part 9 from scratch after applying the changes.
+
+
+
+ + + + + + + + + + +
+ (0007484) +
+ Gyorgy Rethy    +
+ 27-11-2008 15:31    +
+ 		+ + + + +
+ To be added to master copy (to be crosschecked when all CRs added to master document)
+
+
+
+ + + + + + + + + + +
+ (0007635) +
+ Gyorgy Rethy    +
+ 10-12-2008 14:29    +
+ 		+ + + + +
+ Added to master copy (v3.3.4)
+
+ + diff --git a/docs/mantis/CR4472.md b/docs/mantis/CR4472.md new file mode 100644 index 0000000000000000000000000000000000000000..b4c0199d44b7e495b39a22e95abbded310422f17 --- /dev/null +++ b/docs/mantis/CR4472.md @@ -0,0 +1,134 @@ + + + + + + + + + + + + + 0004472: Mapping of any and anyAttribute is incomplete - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0004472Part 09: Using XML with TTCN-3Technicalpublic19-11-2008 17:2512-12-2008 11:28
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)7.7
For STF discussion
Source (company - Author)L.M.Ericsson
Summary0004472: Mapping of any and anyAttribute is incomplete
DescriptionThe text describing the mapping of XSD any is incomplete. The mapping of anyAttribute is not specified at all.
+See proposed text in the attached file.
+Pls. note, CRs 4468 to 4473 shall be read jointly as the text is mutually referencing each other.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR - any & anyAttribute.doc (123,392) 19-11-2008 17:25
http://oldforge.etsi.org/mantis/file_download.php?file_id=1752&type=bug
doc CR4472 - any & anyAttribute v2.doc (123,392) 25-11-2008 10:36
http://oldforge.etsi.org/mantis/file_download.php?file_id=1775&type=bug
doc CR4472 - any & anyAttribute v3.doc (122,880) 26-11-2008 07:36
http://oldforge.etsi.org/mantis/file_download.php?file_id=1783&type=bug
Issue History
Date ModifiedUsernameFieldChange
19-11-2008 17:25Gyorgy RethyNew Issue
19-11-2008 17:25Gyorgy RethyStatusnew => assigned
19-11-2008 17:25Gyorgy RethyAssigned To => Gyorgy Rethy
19-11-2008 17:25Gyorgy RethyFile Added: CR - any & anyAttribute.doc
19-11-2008 17:25Gyorgy RethyClause Reference(s) => 7.7
19-11-2008 17:25Gyorgy RethySource (company - Author) => L.M.Ericsson
19-11-2008 17:31Gyorgy RethyDescription Updated
25-11-2008 10:35Gyorgy RethyFile Added: CR4470 - XSD attributes v2.doc
25-11-2008 10:35Gyorgy RethyFile Deleted: CR4470 - XSD attributes v2.doc
25-11-2008 10:36Gyorgy RethyFile Added: CR4472 - any & anyAttribute v2.doc
25-11-2008 10:37Gyorgy RethyAssigned ToGyorgy Rethy => Thomas Deiß
26-11-2008 07:36Thomas DeißFile Added: CR4472 - any & anyAttribute v3.doc
26-11-2008 07:36Thomas DeißNote Added: 0007429
26-11-2008 07:36Thomas DeißAssigned ToThomas Deiß => Gyorgy Rethy
27-11-2008 15:34Gyorgy RethyStatusassigned => resolved
27-11-2008 15:34Gyorgy RethyResolutionopen => fixed
27-11-2008 15:34Gyorgy RethyNote Added: 0007485
10-12-2008 14:30Gyorgy RethyStatusresolved => closed
10-12-2008 14:30Gyorgy RethyNote Added: 0007636
10-12-2008 14:30Gyorgy RethyFixed in Version => Edition 4.1.1 (not yet published)
12-12-2008 11:28Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0007429) +
+ Thomas Deiß    +
+ 26-11-2008 07:36    +
+ 		+ + + + +
+ editorial comments only. v3 uploaded.
+otherwise ok.
+
+
+
+ + + + + + + + + + +
+ (0007485) +
+ Gyorgy Rethy    +
+ 27-11-2008 15:34    +
+ 		+ + + + +
+ To be added to master copy (to be crosschecked when all CRs added to master document)
+
+
+
+ + + + + + + + + + +
+ (0007636) +
+ Gyorgy Rethy    +
+ 10-12-2008 14:30    +
+ 		+ + + + +
+ Added to master copy (v3.3.4)
+
+ + diff --git a/docs/mantis/CR4473.md b/docs/mantis/CR4473.md new file mode 100644 index 0000000000000000000000000000000000000000..8a4edd2f2b3e26e8943b4277612c305870568f1c --- /dev/null +++ b/docs/mantis/CR4473.md @@ -0,0 +1,133 @@ + + + + + + + + + + + + + 0004473: Mapping of global group definitions is missing - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0004473Part 09: Using XML with TTCN-3Technicalpublic19-11-2008 17:2712-12-2008 11:28
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)7
For STF discussion
Source (company - Author)L.M.Ericsson
Summary0004473: Mapping of global group definitions is missing
DescriptionMapping of global group definitions is missing.
+See proposed text in the attached file.
+Pls. note, CRs 4468 to 4473 shall be read jointly as the text is mutually referencing each other.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR4473 - mapping of groups.doc (84,992) 20-11-2008 08:37
http://oldforge.etsi.org/mantis/file_download.php?file_id=1753&type=bug
Issue History
Date ModifiedUsernameFieldChange
19-11-2008 17:27Gyorgy RethyNew Issue
19-11-2008 17:27Gyorgy RethyStatusnew => assigned
19-11-2008 17:27Gyorgy RethyAssigned To => Gyorgy Rethy
19-11-2008 17:27Gyorgy RethyClause Reference(s) => 7
19-11-2008 17:27Gyorgy RethySource (company - Author) => L.M.Ericsson
19-11-2008 17:31Gyorgy RethyDescription Updated
20-11-2008 08:37Gyorgy RethyFile Added: CR4473 - mapping of groups.doc
25-11-2008 10:37Gyorgy RethyAssigned ToGyorgy Rethy => Thomas Deiß
26-11-2008 07:37Thomas DeißNote Added: 0007430
26-11-2008 07:37Thomas DeißAssigned ToThomas Deiß => Gyorgy Rethy
27-11-2008 15:35Gyorgy RethyStatusassigned => resolved
27-11-2008 15:35Gyorgy RethyResolutionopen => fixed
27-11-2008 15:35Gyorgy RethyNote Added: 0007486
10-12-2008 14:30Gyorgy RethyStatusresolved => closed
10-12-2008 14:30Gyorgy RethyNote Added: 0007637
10-12-2008 14:30Gyorgy RethyFixed in Version => Edition 4.1.1 (not yet published)
12-12-2008 11:28Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0007430) +
+ Thomas Deiß    +
+ 26-11-2008 07:37    +
+ 		+ + + + +
+ ok.
+
+
+
+ + + + + + + + + + +
+ (0007486) +
+ Gyorgy Rethy    +
+ 27-11-2008 15:35    +
+ 		+ + + + +
+ To be added to master copy (to be crosschecked when all CRs added to master document)
+
+
+
+ + + + + + + + + + +
+ (0007637) +
+ Gyorgy Rethy    +
+ 10-12-2008 14:30    +
+ 		+ + + + +
+ Added to master copy (v3.3.4)
+
+ + diff --git a/docs/mantis/CR4483.md b/docs/mantis/CR4483.md new file mode 100644 index 0000000000000000000000000000000000000000..aa9bfd71749dc876ef8422ad78688768e90242f0 --- /dev/null +++ b/docs/mantis/CR4483.md @@ -0,0 +1,122 @@ + + + + + + + + + + + + + 0004483: New Concepts to Test Real Time Properties - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0004483Part 01: TTCN-3 Core LanguageClarificationpublic25-11-2008 10:1916-02-2010 14:30
ReporterJürgen Großmann 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.2.1 (published 2010-07)Fixed in Version 
Clause Reference(s)Part 1, 2, 3, 4, 5, 6
Source (company - Author)Jürgen Großmann (Fraunhofer FOKUS)
Summary0004483: New Concepts to Test Real Time Properties
DescriptionTTCN-3 already provides means to describe test cases that respect
+timing. Nevertheless, the means are restricted and have several disadvantages:
+
+- The use of a timer for the measurement of timing properties is not always
+  adequate/exact:
+  -- timers are not directly related to the communication but to the control
+     flow inside the test system
+  -- originally introduced to catch mid-term or long-term timeouts but not
+     intended to handle real time properties
+  -- not always intuitive
+- Snapshot semantics is affected by durations for decoding/matching etc.
+- Snapshot intervals depend on implementation related issues and are hard to
+  predict.
+
+Hence we propose to introduce:
+- A test case related clock, that starts with the execution of a test case and is available for dedicated (synchronized) components.
+
+- The "now" operator to access the actual time during test execution.
+
+- The "wait" (e.g. wait(10.0)) operation to resume the executuion of a component until a certain time point is reached.
+
+- The storage of the enqueue time of messages, procedure calls, Exceptions etc. by the test system
+
+- The "-> timestamp" operator to refer to the enqueue time from inside a test specification
+
+The proposed concepts are meant to be introduced as an additional TTCN-3 Package (see CR 0004275)
Steps To Reproduce
Additional InformationPlease refer to the attached slides for a more detailed description of the proposed concepts. We will provide you with a more formal description as soon as possible.
TagsNo tags attached.
Relationships
related to 0004275closed Ina Schieferdecker Part 01: TTCN-3 Core Language New Concepts to be defined via Packages 
related to 0000354closed  Part 01: TTCN-3 Core Language TimedTTCN-3 
related to 0000355closed  Part 01: TTCN-3 Core Language TimedGFT 
related to 0000404closed Gyorgy Rethy Ext Pack: Perf & Real Time Testing (ES 202 782) Support for simulated time 
Attached Filespptx TTCN-3 Real Time Concepts_III.pptx (480,289) 25-11-2008 10:19
http://oldforge.etsi.org/mantis/file_download.php?file_id=1770&type=bug
doc es_TTCN3PackageRT-TTCN-3.doc (260,096) 03-12-2009 12:08
http://oldforge.etsi.org/mantis/file_download.php?file_id=2277&type=bug
doc es_TTCN3PackageRT-TTCN-3-100121.doc (267,776) 21-01-2010 14:06
http://oldforge.etsi.org/mantis/file_download.php?file_id=2323&type=bug
Issue History
Date ModifiedUsernameFieldChange
25-11-2008 10:19Jürgen GroßmannNew Issue
25-11-2008 10:19Jürgen GroßmannFile Added: TTCN-3 Real Time Concepts_III.pptx
25-11-2008 10:19Jürgen GroßmannClause Reference(s) => Part 1, 2, 3, 4, 5, 6
25-11-2008 10:19Jürgen GroßmannSource (company - Author) => Jürgen Großmann (Fraunhofer FOKUS)
28-11-2008 12:31Ina SchieferdeckerProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
28-11-2008 12:31Ina SchieferdeckerCategoryTTCN-3 Core Language => Clarification
28-11-2008 12:31Ina SchieferdeckerTarget Version => Edition 4.2.1 (not yet published)
28-11-2008 12:31Ina SchieferdeckerRelationship addedrelated to 0000404
12-12-2008 09:05Ina SchieferdeckerRelationship addedrelated to 0004275
12-12-2008 12:06Ina SchieferdeckerRelationship addedrelated to 0000354
12-12-2008 12:06Ina SchieferdeckerRelationship addedrelated to 0000355
20-04-2009 11:32Ina SchieferdeckerStatusnew => assigned
20-04-2009 11:32Ina SchieferdeckerAssigned To => Jens Grabowski
03-12-2009 12:08user540File Added: es_TTCN3PackageRT-TTCN-3.doc
21-01-2010 14:06Jens GrabowskiFile Added: es_TTCN3PackageRT-TTCN-3-100121.doc
21-01-2010 14:08Jens GrabowskiNote Added: 0009162
16-02-2010 14:30Jens GrabowskiStatusassigned => closed
16-02-2010 14:30Jens GrabowskiNote Added: 0009221
16-02-2010 14:30Jens GrabowskiResolutionopen => fixed
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009162) +
+ Jens Grabowski    +
+ 21-01-2010 14:08    +
+ 		+ + + + +
+ The version from 21 Jan. 2010 adds port types with a realtime clauses to the package. Time measurements shall only be done on instances of port types with realtime clauses.
+
+
+
+ + + + + + + + + + +
+ (0009221) +
+ Jens Grabowski    +
+ 16-02-2010 14:30    +
+ 		+ + + + +
+ The finalization of this CR is merged with "CR 0005110: Concepts to specify tests for continuous systems"
+
+ + diff --git a/docs/mantis/CR4507.md b/docs/mantis/CR4507.md new file mode 100644 index 0000000000000000000000000000000000000000..500f76b533d5da6c1c7167d407aefaeb3b17e00a --- /dev/null +++ b/docs/mantis/CR4507.md @@ -0,0 +1,217 @@ + + + + + + + + + + + + + 0004507: omit in setof constant - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0004507Part 01: TTCN-3 Core LanguageClarificationpublic28-11-2008 14:0719-12-2008 13:51
ReporterThomas Deiß 
Assigned ToIna Schieferdecker 
PrioritynormalSeveritymajorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)part 1, 7.1.3, 6.2.3
Source (company - Author)Thomas Deiß, Nokia Siemens Networks
Summary0004507: omit in setof constant
DescriptionAn example to explain equality of set values with set of values uses a set of constant that itself contains 'omit' for one of its fields.
+
+const SetOf conSetOf1 := { 0, omit, 2 };
+
+The usage of 'omit' for within record of and set of values is not defined at all.
+
+It can be interpreted as deleting a value from a record of, set of, but this is nowhere explicitly defined.
+
+It has to be clarified
+a) whether omit can be used at all for record of/set of values
+b) whether omit or - can be used for constants of record of and set of types.
+
+I suggest to actually exclude case a)
+
+The concept of a partially initialized constant (case b) is somehow strange, but it would not hurt. So one could allow to use '-' in a constant.
Steps To Reproduce
Additional Informationfrom discussion with Elena de Vega, MTP.
TagsNo tags attached.
Relationships
Attached Filesdoc CR4507_Omit.doc (54,272) 09-12-2008 11:42
http://oldforge.etsi.org/mantis/file_download.php?file_id=1868&type=bug
doc CR4507_Omit_01.doc (54,784) 18-12-2008 15:46
http://oldforge.etsi.org/mantis/file_download.php?file_id=1916&type=bug
Issue History
Date ModifiedUsernameFieldChange
28-11-2008 14:07Thomas DeißNew Issue
28-11-2008 14:07Thomas DeißStatusnew => assigned
28-11-2008 14:07Thomas DeißAssigned To => Thomas Deiß
28-11-2008 14:07Thomas DeißClause Reference(s) => part 1, 7.1.3, 6.2.3
28-11-2008 14:07Thomas DeißSource (company - Author) => Thomas Deiß, Nokia Siemens Networks
28-11-2008 14:07Thomas DeißProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
28-11-2008 14:07Thomas DeißAssigned ToThomas Deiß => Ina Schieferdecker
09-12-2008 11:27Ina SchieferdeckerNote Added: 0007591
09-12-2008 11:42Ina SchieferdeckerFile Added: CR4507_Omit.doc
09-12-2008 11:43Ina SchieferdeckerNote Added: 0007592
09-12-2008 11:43Ina SchieferdeckerAssigned ToIna Schieferdecker => Thomas Deiß
09-12-2008 11:43Ina SchieferdeckerResolutionopen => fixed
09-12-2008 11:43Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
09-12-2008 12:33Thomas DeißNote Added: 0007593
09-12-2008 12:33Thomas DeißAssigned ToThomas Deiß => Ina Schieferdecker
09-12-2008 13:34Ina SchieferdeckerNote Added: 0007598
09-12-2008 13:34Ina SchieferdeckerAssigned ToIna Schieferdecker => Gyorgy Rethy
18-12-2008 15:40Gyorgy RethyNote Added: 0007742
18-12-2008 15:46Gyorgy RethyFile Added: CR4507_Omit_01.doc
18-12-2008 15:46Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
19-12-2008 13:51Ina SchieferdeckerStatusassigned => resolved
19-12-2008 13:51Ina SchieferdeckerFixed in Version => Edition 4.1.1 (not yet published)
19-12-2008 13:51Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0007591) +
+ Ina Schieferdecker    +
+ 09-12-2008 11:27    +
+ 		+ + + + +
+ The STF agreed that omit should not be used record of or set of values.
+
+However, "-" could be used which may lead to partially intialized values.
+
+
+
+ + + + + + + + + + +
+ (0007592) +
+ Ina Schieferdecker    +
+ 09-12-2008 11:43    +
+ 		+ + + + +
+ Please check
+
+
+
+ + + + + + + + + + +
+ (0007593) +
+ Thomas Deiß    +
+ 09-12-2008 12:33    +
+ 		+ + + + +
+ proposal is ok.
+
+Gyorgy wanted to have a look whether the BNF can be changed such that omit is not a value.
+
+
+
+ + + + + + + + + + +
+ (0007598) +
+ Ina Schieferdecker    +
+ 09-12-2008 13:34    +
+ 		+ + + + +
+ See note by Thomas.
+
+
+
+ + + + + + + + + + +
+ (0007742) +
+ Gyorgy Rethy    +
+ 18-12-2008 15:40    +
+ 		+ + + + +
+ OK with one amendment, in clause 7.1.3 only the set of example should be changed but not the set and record examples. In case of sets and records omit is allowed and makes the field initialized. The dash leaves an unitialized field uninitialized, thus is disallowed in constants (all examples in $7.1.3 are using constants. See changes in CR4507_Omit_01.doc
+
+ + diff --git a/docs/mantis/CR4508.md b/docs/mantis/CR4508.md new file mode 100644 index 0000000000000000000000000000000000000000..aa721841775aecf87f2c6a79abea0bd138962764 --- /dev/null +++ b/docs/mantis/CR4508.md @@ -0,0 +1,313 @@ + + + + + + + + + + + + + 0004508: type compatibility of relational operators - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0004508Part 01: TTCN-3 Core LanguageClarificationpublic28-11-2008 14:1420-12-2008 16:17
ReporterThomas Deiß 
Assigned ToIna Schieferdecker 
PrioritynormalSeveritymajorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.3.2 (published 2008-04) 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)part1, 7.1.2, 7.1.3
Source (company - Author)Thomas Deiß, Nokia Siemens Networks
Summary0004508: type compatibility of relational operators
DescriptionThe relational operators request that the operands are of compatible types. But in part 1 it is mostly defined what compatibility of a value with a type means. Compatibility of types is defined in only some cases.
+
+I suggest to clarify the type compatibility such that operands of relational operators have to be of the same root type. As a consequence values of different subtypes of integer can be compared, even if the subtypes have an empty intersection.
+
+Similarly for the list operator &, type compatibility of the operands is too strong. It is sufficient that the operands are of the same root type.
Steps To Reproduce
Additional InformationFrom discussion with Raul Alfonso Quintana, MTP
TagsNo tags attached.
Relationships
related to 0004850closed Ina Schieferdecker type compatibility of union does not coincide with union equality 
Attached Filesdoc CR4508_Expressions.doc (65,536) 09-12-2008 11:16
http://oldforge.etsi.org/mantis/file_download.php?file_id=1867&type=bug
doc CR4508_Expressions_02.doc (67,072) 09-12-2008 12:41
http://oldforge.etsi.org/mantis/file_download.php?file_id=1869&type=bug
doc CR4508_Expressions_03.doc (82,432) 18-12-2008 15:44
http://oldforge.etsi.org/mantis/file_download.php?file_id=1915&type=bug
doc CR4508_Expressions_04.doc (79,360) 19-12-2008 09:01
http://oldforge.etsi.org/mantis/file_download.php?file_id=1918&type=bug
doc CR4508_Expressions_05.doc (87,040) 20-12-2008 15:49
http://oldforge.etsi.org/mantis/file_download.php?file_id=1923&type=bug
Issue History
Date ModifiedUsernameFieldChange
28-11-2008 14:14Thomas DeißNew Issue
28-11-2008 14:14Thomas DeißStatusnew => assigned
28-11-2008 14:14Thomas DeißAssigned To => Thomas Deiß
28-11-2008 14:14Thomas DeißClause Reference(s) => part1, 7.1.2, 7.1.3
28-11-2008 14:14Thomas DeißSource (company - Author) => Thomas Deiß, Nokia Siemens Networks
28-11-2008 14:14Thomas DeißProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
28-11-2008 14:15Thomas DeißNote Added: 0007507
28-11-2008 14:15Thomas DeißAssigned ToThomas Deiß => Ina Schieferdecker
28-11-2008 14:15Thomas DeißProduct Version => Edition 3.3.2
09-12-2008 11:16Ina SchieferdeckerFile Added: CR4508_Expressions.doc
09-12-2008 11:17Ina SchieferdeckerNote Added: 0007590
09-12-2008 11:17Ina SchieferdeckerAssigned ToIna Schieferdecker => Thomas Deiß
09-12-2008 11:17Ina SchieferdeckerResolutionopen => fixed
09-12-2008 11:17Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
09-12-2008 12:41Thomas DeißFile Added: CR4508_Expressions_02.doc
09-12-2008 12:44Thomas DeißNote Added: 0007594
09-12-2008 12:44Thomas DeißAssigned ToThomas Deiß => Ina Schieferdecker
09-12-2008 12:44Thomas DeißResolutionfixed => open
09-12-2008 13:32Ina SchieferdeckerNote Added: 0007597
09-12-2008 13:32Ina SchieferdeckerAssigned ToIna Schieferdecker => Gyorgy Rethy
18-12-2008 14:46Gyorgy RethyNote Added: 0007740
18-12-2008 14:48Gyorgy RethyFile Added: CR4508_Expressions_03.doc
18-12-2008 14:49Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
18-12-2008 15:44Gyorgy RethyFile Deleted: CR4508_Expressions_03.doc
18-12-2008 15:44Gyorgy RethyFile Added: CR4508_Expressions_03.doc
19-12-2008 09:01Thomas DeißFile Added: CR4508_Expressions_04.doc
19-12-2008 09:03Thomas DeißNote Added: 0007750
20-12-2008 15:28Ina SchieferdeckerNote Added: 0007756
20-12-2008 15:29Ina SchieferdeckerFile Added: CR4508_Expressions_05.doc
20-12-2008 15:49Ina SchieferdeckerFile Deleted: CR4508_Expressions_05.doc
20-12-2008 15:49Ina SchieferdeckerFile Added: CR4508_Expressions_05.doc
20-12-2008 15:50Ina SchieferdeckerStatusassigned => resolved
20-12-2008 15:50Ina SchieferdeckerResolutionopen => fixed
20-12-2008 15:50Ina SchieferdeckerFixed in Version => Edition 4.1.1 (not yet published)
20-12-2008 16:16Ina SchieferdeckerNote Added: 0007757
20-12-2008 16:17Ina SchieferdeckerStatusresolved => closed
16-02-2009 05:49Ina SchieferdeckerRelationship addedrelated to 0004850
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0007507) +
+ Thomas Deiß    +
+ 28-11-2008 14:15    +
+ 		+ + + + +
+ also applicable to edition 3.4
+
+
+
+ + + + + + + + + + +
+ (0007590) +
+ Ina Schieferdecker    +
+ 09-12-2008 11:17    +
+ 		+ + + + +
+ Please check
+
+
+
+ + + + + + + + + + +
+ (0007594) +
+ Thomas Deiß    +
+ 09-12-2008 12:44    +
+ 		+ + + + +
+ some minor editorial corrections.
+
+There is one issue regarding equality of union values. As defined this does not fit to compatibility of union values. In that sense the text would be contradicting itself. To require that equality of union values also includes the choice of the alternative would be a backward incompatible change, hence I am not sure whether we should the specification in this way.
+
+Btw.: this CR is a quite late one, it should not hurt if that one is postponed to 2009.
+
+
+
+ + + + + + + + + + +
+ (0007597) +
+ Ina Schieferdecker    +
+ 09-12-2008 13:32    +
+ 		+ + + + +
+ Gyorgy, could you please check if we can resolve this in 4.1.1 or have to postpone it to a later CR.
+
+
+
+ + + + + + + + + + +
+ (0007740) +
+ Gyorgy Rethy    +
+ 18-12-2008 14:46    +
+ 		+ + + + +
+ I have made several comments and changed the text at the relevant places inside the file CR4508_Expressions_03.doc. If those changes are OK the CR can be included to v4.1.1, if not, I propose to move it to next year, i.e. v4.2.1
+
+
+
+ + + + + + + + + + +
+ (0007750) +
+ Thomas Deiß    +
+ 19-12-2008 09:03    +
+ 		+ + + + +
+ Gyorgy's changes are ok from my side.
+
+One editorial correction done in the text explaining equality of union values. ('the the' -> 'the').
+
+I did not check whether the use of root type/compatible type is now consistent in the whole part1.
+
+
+
+ + + + + + + + + + +
+ (0007756) +
+ Ina Schieferdecker    +
+ 20-12-2008 15:28    +
+ 		+ + + + +
+ Changes are ok - small editorial changes only in 05.
+
+
+
+ + + + + + + + + + +
+ (0007757) +
+ Ina Schieferdecker    +
+ 20-12-2008 16:16    +
+ 		+ + + + +
+ Checked the use of root and/or compatible type.
+
+ + diff --git a/docs/mantis/CR4573.md b/docs/mantis/CR4573.md new file mode 100644 index 0000000000000000000000000000000000000000..e7fcfb6589b9e15340f3671a3e33340f3c9bf94f --- /dev/null +++ b/docs/mantis/CR4573.md @@ -0,0 +1,102 @@ + + + + + + + + + + + + + 0004573: Consolidation of normative and informative references - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 10: TTCN-3 documentation tags
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0004573Part 10: TTCN-3 documentation tagsClarificationpublic09-12-2008 18:2620-04-2009 14:05
ReporterIna Schieferdecker 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.2.1 (published 2010-07)Fixed in Versionv4.2.1 (published 2010-07) 
Source (company - Author)     
Summary0004573: Consolidation of normative and informative references
DescriptionPart 1 enumerates a number of TTCN-3 parts as normative references although they are not "indispensable for the application of the present document" (part 1 in this case).
+
+Hence, the proposal is to consolidate the references of part 1 and of the other parts of TTCN-3 as outlined in the attached Word document.
+
Steps To Reproduce
Additional InformationFixed already for part 1, 5, 6, and 9 in v4.1.1 - overall resolution attached to parent CR4272 - see there.
+
+Also to be resolved in part 2, 3 and 10, when the documents will be revised.
TagsNo tags attached.
Relationships
child of 0004272closed Ina Schieferdecker Part 01: TTCN-3 Core Language Consolidation of normative and informative references 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
09-12-2008 18:26Ina SchieferdeckerNew Issue
09-12-2008 18:26Ina SchieferdeckerStatusnew => assigned
09-12-2008 18:26Ina SchieferdeckerAssigned To => Ina Schieferdecker
09-12-2008 18:26Ina SchieferdeckerClause Reference(s) => clause 2 of part 1, 2, 3, 5, 6, 9, and 10
09-12-2008 18:26Ina SchieferdeckerSource (company - Author) =>
09-12-2008 18:26Ina SchieferdeckerIssue generated from: 0004272
09-12-2008 18:26Ina SchieferdeckerRelationship addedchild of 0004272
09-12-2008 18:29Ina SchieferdeckerResolutionopen => fixed
09-12-2008 18:29Ina SchieferdeckerAdditional Information Updated
09-12-2008 18:29Ina SchieferdeckerProjectPart 01: TTCN-3 Core Language => Part 10: TTCN-3 documentation tags
12-12-2008 10:51Ina SchieferdeckerStatusassigned => resolved
12-12-2008 10:51Ina SchieferdeckerTarget Version => Edition 4.2.1 (not yet published)
12-12-2008 10:51Ina SchieferdeckerAdditional Information Updated
20-04-2009 11:46Ina SchieferdeckerStatusresolved => assigned
20-04-2009 11:46Ina SchieferdeckerAssigned ToIna Schieferdecker => Gyorgy Rethy
20-04-2009 14:04Gyorgy RethyNote Added: 0008513
20-04-2009 14:05Gyorgy RethyStatusassigned => closed
20-04-2009 14:05Gyorgy RethyNote Added: 0008514
20-04-2009 14:05Gyorgy RethyFixed in Version => Edition 4.2.1 (not yet published)
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0008513) +
+ Gyorgy Rethy    +
+ 20-04-2009 14:04    +
+ 		+ + + + +
+ In Part-10: RFC 1738 is moved from bibliography to informative references (in master doc). Bibliography is deleted (as become empty). Other references are used in the mandatory text, thus left untouched.
+
+
+
+ + + + + + + + + + +
+ (0008514) +
+ Gyorgy Rethy    +
+ 20-04-2009 14:05    +
+ 		+ + + + +
+ Implemented in master document.
+
+ + diff --git a/docs/mantis/CR4605.md b/docs/mantis/CR4605.md new file mode 100644 index 0000000000000000000000000000000000000000..c3788fff38dee87c87bbb14d2190fed75c1db48f --- /dev/null +++ b/docs/mantis/CR4605.md @@ -0,0 +1,97 @@ + + + + + + + + + + + + + 0004605: Objid TCI definitions to be put into part 7 - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 07: Using ASN.1 with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0004605Part 07: Using ASN.1 with TTCN-3Clarificationpublic14-12-2008 10:4515-12-2008 09:55
ReporterIna Schieferdecker 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)Various clauses in TCI
Source (company - Author)     
Summary0004605: Objid TCI definitions to be put into part 7
DescriptionWhen the objid type has been moved from part 1 to part 7, the according TCI definitions still remained in TCI. This has to be changed as proposed in the uploaded file.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc ObjidInTCI.doc (745,472) 14-12-2008 10:45
http://oldforge.etsi.org/mantis/file_download.php?file_id=1896&type=bug
Issue History
Date ModifiedUsernameFieldChange
14-12-2008 10:45Ina SchieferdeckerNew Issue
14-12-2008 10:45Ina SchieferdeckerFile Added: ObjidInTCI.doc
14-12-2008 10:45Ina SchieferdeckerClause Reference(s) => Various clauses in TCI
14-12-2008 10:45Ina SchieferdeckerSource (company - Author) =>
14-12-2008 10:46Ina SchieferdeckerNote Added: 0007698
14-12-2008 10:46Ina SchieferdeckerAssigned To => Gyorgy Rethy
14-12-2008 10:46Ina SchieferdeckerStatusnew => assigned
14-12-2008 10:47Ina SchieferdeckerProjectTTCN-3 Change Requests => Part 07: Using ASN.1 with TTCN-3
14-12-2008 10:47Ina SchieferdeckerCategoryASN.1 mapping => Clarification
14-12-2008 10:47Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
15-12-2008 09:55Gyorgy RethyNote Added: 0007702
15-12-2008 09:55Gyorgy RethyStatusassigned => closed
15-12-2008 09:55Gyorgy RethyResolutionopen => fixed
15-12-2008 09:55Gyorgy RethyFixed in Version => Edition 4.1.1 (not yet published)
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0007698) +
+ Ina Schieferdecker    +
+ 14-12-2008 10:46    +
+ 		+ + + + +
+ As discussed and agreed, all objid definitions should be part of the ASN.1 mapping. Please check the resolution.
+
+
+
+ + + + + + + + + + +
+ (0007702) +
+ Gyorgy Rethy    +
+ 15-12-2008 09:55    +
+ 		+ + + + +
+ Clause added to master copy (v.3.3.4)
+
+ + diff --git a/docs/mantis/CR4613.md b/docs/mantis/CR4613.md new file mode 100644 index 0000000000000000000000000000000000000000..1f7a655bfd878e48e7db5ca4ad16dc436c988581 --- /dev/null +++ b/docs/mantis/CR4613.md @@ -0,0 +1,97 @@ + + + + + + + + + + + + + 0004613: Packages and namespaces - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0004613Part 09: Using XML with TTCN-3New Featurepublic16-12-2008 16:1201-02-2010 08:43
ReporterIna Schieferdecker 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityfeatureReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.2.1 (published 2010-07)Fixed in Versionv4.2.1 (published 2010-07) 
Clause Reference(s)Part 1, Clause 8
For STF discussion
Source (company - Author)     
Summary0004613: Packages and namespaces
DescriptionTTCN-3 has no support for packages and namespaces which makes large projects for test suites split into several modules - which are at best put into a logical hierarchy or directory tree - hard to handle. Therefore, a package concept is being proposed in order to ease the practical use of TTCN-3.
Steps To Reproduce
Additional InformationHas to be done also for IDL. See notes in parent CR.
TagsNo tags attached.
Relationships
related to 0005275closed Gyorgy Rethy Transitive import is not supported from other languages 
child of 0002566closed Ina Schieferdecker Packages and namespaces 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
16-12-2008 16:12Ina SchieferdeckerNew Issue
16-12-2008 16:12Ina SchieferdeckerStatusnew => assigned
16-12-2008 16:12Ina SchieferdeckerAssigned To => Ina Schieferdecker
16-12-2008 16:12Ina SchieferdeckerClause Reference(s) => Part 1, Clause 8
16-12-2008 16:12Ina SchieferdeckerSource (company - Author) =>
16-12-2008 16:12Ina SchieferdeckerIssue generated from: 0002566
16-12-2008 16:12Ina SchieferdeckerRelationship addedchild of 0002566
16-12-2008 16:15Ina SchieferdeckerTarget Version => Edition 4.2.1 (not yet published)
08-05-2009 15:04Gyorgy RethyAssigned ToIna Schieferdecker => Gyorgy Rethy
01-09-2009 10:42Gyorgy RethyRelationship addedrelated to 0005275
01-09-2009 10:44Gyorgy RethyNote Added: 0008947
01-02-2010 08:41Gyorgy RethyNote Added: 0009168
01-02-2010 08:43Gyorgy RethyStatusassigned => closed
01-02-2010 08:43Gyorgy RethyResolutionopen => fixed
01-02-2010 08:43Gyorgy RethyFixed in Version => Edition 4.2.1 (not yet published)
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0008947) +
+ Gyorgy Rethy    +
+ 01-09-2009 10:44    +
+ 		+ + + + +
+ As both this CR and CR5275 are concerning the import clause in Part-9, a common text is provided to resolve both CRs. See at CR 5275.
+
+
+
+ + + + + + + + + + +
+ (0009168) +
+ Gyorgy Rethy    +
+ 01-02-2010 08:41    +
+ 		+ + + + +
+ CR5275 is implemented, thus this CR can be closed as well.
+
+ + diff --git a/docs/mantis/CR4640.md b/docs/mantis/CR4640.md new file mode 100644 index 0000000000000000000000000000000000000000..b892d2af2959ae7a019a5f5ac573ce2964bcda54 --- /dev/null +++ b/docs/mantis/CR4640.md @@ -0,0 +1,137 @@ + + + + + + + + + + + + + 0004640: TCI-CD Type interface not complete - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0004640Part 06: TTCN-3 Control InterfaceTechnicalpublic23-12-2008 11:5001-09-2010 14:11
ReporterAndrej Pietschker 
Assigned ToIna Schieferdecker 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionwon't fix 
PlatformOSOS Version
Product Versionv3.4.1 (published 2008-09) 
Target Versionv4.3.1 (published 2011-06)Fixed in Version 
Clause Reference(s)7.2.2.2.
Source (company - Author)    G&D - Andrej Pietschker, Peter Mittermaier
Summary0004640: TCI-CD Type interface not complete
DescriptionIn 7.3.2.2.1 the function decode is described and it should retrun the value if it is of a compatible type as the decodingHypothesis, else the distinct value null.
+
+If a type restriction is applied during the definition of a TTCN-3 type this information is not available during decoding.
+E.g. type charstring MyString length(3) then decoding "ABCD" as MyString should yield null. However a TCI interface function is missing to query such restrictions such as length, pattern, or value.
Steps To Reproduce
Additional InformationIn the proposal to 4.1.1 a function for arrays is introduced in 7.2.2.2.11: getOffset(). Similar functions are needed for other type restrictions.
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
23-12-2008 11:50Andrej PietschkerNew Issue
23-12-2008 11:50Andrej PietschkerStatusnew => assigned
23-12-2008 11:50Andrej PietschkerAssigned To => Ina Schieferdecker
23-12-2008 11:50Andrej PietschkerClause Reference(s) => 7.2.2.2.
23-12-2008 11:50Andrej PietschkerSource (company - Author) => G&D - Andrej Pietschker, Peter Mittermaier
12-01-2009 17:32Ina SchieferdeckerTarget Version => Edition 4.2.1 (not yet published)
09-12-2009 17:11Ina SchieferdeckerNote Added: 0009130
09-12-2009 17:11Ina SchieferdeckerTarget VersionEdition 4.2.1 (not yet published) => Edition 5.1.1 (not yet published)
01-09-2010 14:10Ina SchieferdeckerNote Added: 0009676
01-09-2010 14:11Ina SchieferdeckerStatusassigned => closed
01-09-2010 14:11Ina SchieferdeckerResolutionopen => won't fix
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009130) +
+ Ina Schieferdecker    +
+ 09-12-2009 17:11    +
+ 		+ + + + +
+ OpenTTCN suggest to base that extension on an existing interface extension they have. If time permits, the TCI extension can be developed in 2010:
+
+> Hello Dr Ina and dear tool smiths,
+
+> > Dear all,
+> >
+> > we have been asked by Giesecke&Devrient to extend the TCI-CD interface so
+> > that an inspection of the type restrictions would be possible at runtime -
+> > see http://t-ort.etsi.org/view.php?id=4640 [^]
+
+> OpenTTCN asnwers your questions:
+> > May we ask if
+> > 1. you have comparable use cases
+> yes.
+> > 2. you see the need for the described functionality in TCI-CD
+> yes.
+> > 3. you would welcome a respective interface extension to
+> become part of
+> > the standard
+> yes.
+>
+> OpenTTCN tool has an interface extension you have described, as our
+> extension to TCI-CD API. The documentation of ANSI C version
+> of this API
+> is publicly available at:
+> http://wiki.openttcn.com/docs/2.57.0/sdk4c/api/tci__cons_8h.html [^]
+> I think we wanted to make the interface as ANSI TCI-CD like
+> as possible.
+>
+> We are willing to submit a proposal for the interface extension, if
+> requested and time permits.
+>
+> Kind regards,
+> Vesa-Matti
+
+
+
+ + + + + + + + + + +
+ (0009676) +
+ Ina Schieferdecker    +
+ 01-09-2010 14:10    +
+ 		+ + + + +
+ Having reviewed and discussed the responses from the vendors and the OpenTTCN proposal, this CR will be rejected due to the following reasons:
+
+- TE as of today handles subtypes - via the decodingHypothesis these constraints are respected
+
+- it was discussed that type constraint reflection at CD would be of limited use - constraints can be treated sufficiently via the TE
+
+ + diff --git a/docs/mantis/CR4658.md b/docs/mantis/CR4658.md new file mode 100644 index 0000000000000000000000000000000000000000..159c3ce0b28aa852bcf353bdf7323760fb747d0a --- /dev/null +++ b/docs/mantis/CR4658.md @@ -0,0 +1,237 @@ + + + + + + + + + + + + + 0004658: superset with templates - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0004658Part 01: TTCN-3 Core LanguageTechnicalpublic07-01-2009 08:5409-12-2009 15:40
ReporterAxel Rennoch 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityfeatureReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.4.1 (published 2008-09) 
Target Versionv4.2.1 (published 2010-07)Fixed in Versionv4.2.1 (published 2010-07) 
Clause Reference(s)B.1.2.6
Source (company - Author)ETSI STF346/366
Summary0004658: superset with templates
DescriptionPlease remove the restriction that an argument of superset must not contain templates.
Steps To Reproduce
Additional InformationWe miss this feature while checking e.g. SIP header parameter list values.
TagsNo tags attached.
Relationships
Attached Filesdoc CR4658_resolution_v1.doc (144,896) 10-07-2009 09:53
http://oldforge.etsi.org/mantis/file_download.php?file_id=2203&type=bug
? Superset_v1.ttcn (3,204) 10-07-2009 09:55
http://oldforge.etsi.org/mantis/file_download.php?file_id=2204&type=bug
doc CR4658_resolution_v2.doc (159,232) 03-09-2009 15:52
http://oldforge.etsi.org/mantis/file_download.php?file_id=2233&type=bug
? Superset_v2.ttcn (5,763) 03-09-2009 15:52
http://oldforge.etsi.org/mantis/file_download.php?file_id=2234&type=bug
doc CR4658_resolution_v3.doc (159,744) 03-09-2009 18:09
http://oldforge.etsi.org/mantis/file_download.php?file_id=2235&type=bug
Issue History
Date ModifiedUsernameFieldChange
07-01-2009 08:54Axel RennochNew Issue
07-01-2009 08:54Axel RennochStatusnew => assigned
07-01-2009 08:54Axel RennochAssigned To => Ina Schieferdecker
07-01-2009 08:54Axel RennochClause Reference(s) => B.1.2.6
07-01-2009 08:54Axel RennochSource (company - Author) => ETSI STF346/366
07-01-2009 13:37Axel RennochNote Added: 0007782
12-01-2009 17:31Ina SchieferdeckerTarget Version => Edition 4.2.1 (not yet published)
20-04-2009 11:55Ina SchieferdeckerAssigned ToIna Schieferdecker => Gyorgy Rethy
10-07-2009 09:49Gyorgy RethyFile Added: Superset.ttcn
10-07-2009 09:53Gyorgy RethyFile Added: CR4658_resolution_v1.doc
10-07-2009 09:53Gyorgy RethyFile Deleted: Superset.ttcn
10-07-2009 09:55Gyorgy RethyFile Added: Superset_v1.ttcn
10-07-2009 10:19Gyorgy RethyNote Added: 0008884
03-09-2009 14:13Gyorgy RethyFile Added: Superset_v2.ttcn
03-09-2009 14:14Gyorgy RethyNote Added: 0008970
03-09-2009 15:52Gyorgy RethyFile Deleted: Superset_v2.ttcn
03-09-2009 15:52Gyorgy RethyFile Added: CR4658_resolution_v2.doc
03-09-2009 15:52Gyorgy RethyFile Added: Superset_v2.ttcn
03-09-2009 15:55Gyorgy RethyNote Added: 0008975
03-09-2009 15:55Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
03-09-2009 15:55Gyorgy RethyResolutionopen => fixed
03-09-2009 15:55Gyorgy RethyFixed in Version => Edition 4.2.1 (not yet published)
03-09-2009 18:09Gyorgy RethyNote Added: 0008976
03-09-2009 18:09Gyorgy RethyFile Added: CR4658_resolution_v3.doc
09-12-2009 15:24Ina SchieferdeckerNote Added: 0009124
09-12-2009 15:25Ina SchieferdeckerStatusassigned => resolved
09-12-2009 15:40Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0007782) +
+ Axel Rennoch    +
+ 07-01-2009 13:37    +
+ 		+ + + + +
+ References and formal parameters of type template should be allowed as arguments.
+
+
+
+ + + + + + + + + + +
+ (0008884) +
+ Gyorgy Rethy    +
+ 10-07-2009 10:19    +
+ 		+ + + + +
+ CR4658_resolution_v1.doc and Superset_v1.ttcn: first working draft and examples (not complete and not checked). Analysis started but not completed yet; Files uploaded at the end of the July STF session to have them available when continuing the analysis at the next session. Therefore, no solid proposal is made yet.
+Current status of the analysis: both superset and subset allow values only both in the text and in the BNF. Length matching attribute can be added to both subset and superset. They are in fact more compact syntax for some cases that could be handled by set of templates as well (but would be nasty or in practical terms almost impossible to handle). Templates could be allowed inside them as in many cases this would also allow much more compact code (that also creates the danger that users will not fully understand what they do are doing); further analysis needed if any cases exists that are not possible to handle by set of templates directly.
+Next: complete examples: value lists and complemented lists, more examples and cases are needed for AnyvalueOrNone.
+
+If allowing templates, description and many examples will be needed to specify the behaviour in the case of the different matchings inside subset and superset.
+
+
+
+ + + + + + + + + + +
+ (0008970) +
+ Gyorgy Rethy    +
+ 03-09-2009 14:14    +
+ 		+ + + + +
+ Superset_v2.ttcn: more examples, value set and complemented list are added.
+
+
+
+ + + + + + + + + + +
+ (0008975) +
+ Gyorgy Rethy    +
+ 03-09-2009 15:55    +
+ 		+ + + + +
+ CR4658_resolution_v2.doc: draft for CR resolution; ready for checking.
+
+
+
+ + + + + + + + + + +
+ (0008976) +
+ Gyorgy Rethy    +
+ 03-09-2009 18:09    +
+ 		+ + + + +
+ CR4658_resolution_v3.doc: "invalid" is replaced by "causes an error" in examples. No other change.
+
+
+
+ + + + + + + + + + +
+ (0009124) +
+ Ina Schieferdecker    +
+ 09-12-2009 15:24    +
+ 		+ + + + +
+ as proposed - only some editing.
+
+ + diff --git a/docs/mantis/CR4682.md b/docs/mantis/CR4682.md new file mode 100644 index 0000000000000000000000000000000000000000..b177e2015f3c6f2668870017b649f7a1bc488b65 --- /dev/null +++ b/docs/mantis/CR4682.md @@ -0,0 +1,67 @@ + + + + + + + + + + + + + 0004682: Wrong word is used in ifpresent description - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0004682Part 01: TTCN-3 Core LanguageEditorialpublic09-01-2009 10:3201-07-2009 15:21
ReporterGyorgy Rethy 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.4.1 (published 2008-09) 
Target Versionv4.2.1 (published 2010-07)Fixed in Versionv4.2.1 (published 2010-07) 
Clause Reference(s)B.1.4.2
Source (company - Author)L.M.Ericsson
Summary0004682: Wrong word is used in ifpresent description
DescriptionCurrent text is:"The ifpresent indicates that a match may be made if an optional field is present (i.e. not omitted). This attribute may be used with all the matching mechanisms, provided the type is declared as optional."
+
+It should be (See 2nd sentence, a type cannot be optional only a record/set field): :"The ifpresent indicates that a match may be made if an optional field is present (i.e. not omitted). This attribute may be used with all the matching mechanisms, provided the given field is declared as optional."
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
09-01-2009 10:32Gyorgy RethyNew Issue
09-01-2009 10:32Gyorgy RethyStatusnew => assigned
09-01-2009 10:32Gyorgy RethyAssigned To => Ina Schieferdecker
09-01-2009 10:32Gyorgy RethyClause Reference(s) => B.1.4.2
09-01-2009 10:32Gyorgy RethySource (company - Author) => L.M.Ericsson
12-01-2009 17:30Ina SchieferdeckerTarget Version => Edition 4.2.1 (not yet published)
01-07-2009 15:20Ina SchieferdeckerNote Added: 0008809
01-07-2009 15:20Ina SchieferdeckerResolutionopen => fixed
01-07-2009 15:20Ina SchieferdeckerStatusassigned => resolved
01-07-2009 15:20Ina SchieferdeckerStatusresolved => closed
01-07-2009 15:21Ina SchieferdeckerFixed in Version => Edition 4.2.1 (not yet published)
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0008809) +
+ Ina Schieferdecker    +
+ 01-07-2009 15:20    +
+ 		+ + + + +
+ One little change in wording:
+
+"The ifpresent indicates that a match may be made if an optional field is present (i.e. not omitted). This attribute may be used with all the matching mechanisms, provided this field is declared as optional."
+
+ + diff --git a/docs/mantis/CR4683.md b/docs/mantis/CR4683.md new file mode 100644 index 0000000000000000000000000000000000000000..c80a8a42512d101ccc58bafcb6c51a77836e0bcf --- /dev/null +++ b/docs/mantis/CR4683.md @@ -0,0 +1,68 @@ + + + + + + + + + + + + + 0004683: Misleading note to table 9 - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0004683Part 01: TTCN-3 Core LanguageClarificationpublic09-01-2009 10:4001-07-2009 15:29
ReporterGyorgy Rethy 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.2.1 (published 2010-07)Fixed in Versionv4.2.1 (published 2010-07) 
Clause Reference(s)15.7
Source (company - Author)L.M.Ericsson
Summary0004683: Misleading note to table 9
DescriptionNote 1 to table 1 talks about optional fields, while Note 2 talks about fields of record/set types. The reader could assume that ifpresent is applicable to non-optional fields as well, while this is not true.
+
+Clause 15.7.4:"• ifpresent: for matching of optional field values (if not omitted)."
+Clause B.1.4.2" "The ifpresent indicates that a match may be made if an optional field is present (i.e. not omitted). This attribute may be used with all the matching mechanisms, provided the type is declared as optional."
+
+Proposed: to delete NOTE2 and replace "2" with "1" at each "Yes" in the "IfPresent" column of table 9.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR4683_resolution.doc (96,768) 01-07-2009 15:26
http://oldforge.etsi.org/mantis/file_download.php?file_id=2149&type=bug
Issue History
Date ModifiedUsernameFieldChange
09-01-2009 10:40Gyorgy RethyNew Issue
09-01-2009 10:40Gyorgy RethyStatusnew => assigned
09-01-2009 10:40Gyorgy RethyAssigned To => Ina Schieferdecker
09-01-2009 10:40Gyorgy RethyClause Reference(s) => 15.7
09-01-2009 10:40Gyorgy RethySource (company - Author) => L.M.Ericsson
12-01-2009 17:20Ina SchieferdeckerTarget Version => Edition 4.2.1 (not yet published)
01-07-2009 15:26Ina SchieferdeckerNote Added: 0008810
01-07-2009 15:26Ina SchieferdeckerFile Added: CR4683_resolution.doc
01-07-2009 15:28Ina SchieferdeckerResolutionopen => fixed
01-07-2009 15:28Ina SchieferdeckerStatusassigned => resolved
01-07-2009 15:29Ina SchieferdeckerStatusresolved => closed
01-07-2009 15:29Ina SchieferdeckerFixed in Version => Edition 4.2.1 (not yet published)
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0008810) +
+ Ina Schieferdecker    +
+ 01-07-2009 15:26    +
+ 		+ + + + +
+ As proposed - see resolution.
+
+ + diff --git a/docs/mantis/CR4690.md b/docs/mantis/CR4690.md new file mode 100644 index 0000000000000000000000000000000000000000..012b45083a0638613a1aa7e3fa6ad838f327aae4 --- /dev/null +++ b/docs/mantis/CR4690.md @@ -0,0 +1,141 @@ + + + + + + + + + + + + + 0004690: BNF for permutation/length incorrect - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0004690Part 01: TTCN-3 Core LanguageTechnicalpublic13-01-2009 08:2307-07-2009 11:26
ReporterThomas Deiß 
Assigned ToIna Schieferdecker 
PrioritynormalSeveritymajorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.4.1 (published 2008-09) 
Target Versionv4.2.1 (published 2010-07)Fixed in Versionv4.2.1 (published 2010-07) 
Clause Reference(s)part1, B.1.3.3
Source (company - Author)   Nokia Siemens Networks , Thomas Deiss
Summary0004690: BNF for permutation/length incorrect
DescriptionThe text in clause B.1.3.3 contains the following example,
+type record of integer MySequenceOfType;
+
+template MySequenceOfType MyTemplate9 := { permutation ( 1, 2, *) length (3..5), 5 };
+
+but no way was found in the BNF to derive this template definition.
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR4690_BNF_for_Permutation_Length.doc (152,064) 02-07-2009 17:54
http://oldforge.etsi.org/mantis/file_download.php?file_id=2153&type=bug
doc CR4690_BNF_for_Permutation_Length_v1.doc (146,944) 07-07-2009 10:59
http://oldforge.etsi.org/mantis/file_download.php?file_id=2176&type=bug
Issue History
Date ModifiedUsernameFieldChange
13-01-2009 08:23Thomas DeißNew Issue
13-01-2009 08:23Thomas DeißStatusnew => assigned
13-01-2009 08:23Thomas DeißAssigned To => Ina Schieferdecker
13-01-2009 08:23Thomas DeißClause Reference(s) => part1, B.1.3.3
13-01-2009 08:23Thomas DeißSource (company - Author) => Nokia Siemens Networks , Thomas Deiss
13-01-2009 08:32Ina SchieferdeckerTarget Version => Edition 4.2.1 (not yet published)
20-04-2009 11:54Ina SchieferdeckerAssigned ToIna Schieferdecker => Tibor Csöndes
02-07-2009 17:54Tibor CsöndesFile Added: CR4690_BNF_for_Permutation_Length.doc
02-07-2009 18:02Tibor CsöndesNote Added: 0008821
02-07-2009 18:03Tibor CsöndesAssigned ToTibor Csöndes => Ina Schieferdecker
03-07-2009 12:17Gyorgy RethyNote Added: 0008829
07-07-2009 10:37Ina SchieferdeckerResolutionopen => fixed
07-07-2009 10:59Ina SchieferdeckerFile Added: CR4690_BNF_for_Permutation_Length_v1.doc
07-07-2009 11:00Ina SchieferdeckerNote Added: 0008853
07-07-2009 11:02Ina SchieferdeckerNote Edited: 0008853
07-07-2009 11:25Ina SchieferdeckerStatusassigned => resolved
07-07-2009 11:25Ina SchieferdeckerFixed in Version => Edition 4.2.1 (not yet published)
07-07-2009 11:26Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0008821) +
+ Tibor Csöndes    +
+ 02-07-2009 18:02    +
+ 		+ + + + +
+ According to the BNF the following structure is not allowed:{permutation(1,2,*)length(5)}, however B.1.4.1 support it. Based on the BNF the following structure is equivalent with the previous one: {permutation(1,2,* length(3))}. Therefore MyTemplate9 has deleted and B.1.4.1 modified according to the BNF.
+
+
+
+ + + + + + + + + + +
+ (0008829) +
+ Gyorgy Rethy    +
+ 03-07-2009 12:17    +
+ 		+ + + + +
+ OK with me, i.e. we align the text to the BNF (normally we try to avoid to have alternative syntax for the same thing)
+
+
+
+ + + + + + + + + + +
+ (0008853) +
+ Ina Schieferdecker    +
+ 07-07-2009 11:00    +
(edited on: 07-07-2009 11:02)
+ 		+ + + + +
+ the use of length for permutation has to be forbidden in B1.3.3 - see resolution v1
+
+note: the resolution removes the combined usage of permutation with length, which was allowed beforehand, and add the usage of length with * within permutation, which was forbidden beforehand in the main text - but these two changes make it consistent to the BNF
+
+
+
+ + diff --git a/docs/mantis/CR4703.md b/docs/mantis/CR4703.md new file mode 100644 index 0000000000000000000000000000000000000000..8cce382f7ac8fae445ba0f431110af5ca824e44a --- /dev/null +++ b/docs/mantis/CR4703.md @@ -0,0 +1,143 @@ + + + + + + + + + + + + + 0004703: Explaination of standalone receive - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0004703Part 01: TTCN-3 Core LanguageClarificationpublic15-01-2009 14:2601-07-2009 15:10
ReporterIna Schieferdecker 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.2.1 (published 2010-07)Fixed in Versionv4.2.1 (published 2010-07) 
Clause Reference(s)22.2.2
Source (company - Author)Wolfgang Seka, MCC160
Summary0004703: Explaination of standalone receive
DescriptionPart 1 explains for Stand-alone receive:
+
+The receive operation can be used as a stand-alone statement in a behaviour description. In this latter case the receive operation is considered to be shorthand for an alt statement with only one alternative, i.e. it has blocking semantics, and therefore provides the ability of waiting for the next message matching the specified template or value on that queue.
+
+The latter part on "waiting for the next message matching the specified template" can be misinterpreted, so that not only the top level messages can be matched.
+
+This is not true. The blocking semantics holds.
+
+Hence, a simplification is proposed to
+
+"The receive operation can be used as a stand-alone statement in a behaviour description. In this latter case the receive operation is considered to be shorthand for an alt statement with only one alternative."
+
+which removes the confusing part and makes clear, that the semantics of an alt statement applies
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR-4703-Explaination-of-standalone-receive-JG.doc (203,264) 21-04-2009 12:02
http://oldforge.etsi.org/mantis/file_download.php?file_id=2095&type=bug
Issue History
Date ModifiedUsernameFieldChange
15-01-2009 14:26Ina SchieferdeckerNew Issue
15-01-2009 14:26Ina SchieferdeckerClause Reference(s) => 22.2.2
15-01-2009 14:26Ina SchieferdeckerSource (company - Author) => Wolfgang Seka, MCC160
15-01-2009 14:27Ina SchieferdeckerProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
15-01-2009 14:27Ina SchieferdeckerAssigned To => Jens Grabowski
15-01-2009 14:27Ina SchieferdeckerStatusnew => assigned
15-01-2009 14:27Ina SchieferdeckerCategoryTTCN-3 Core Language => Clarification
15-01-2009 14:27Ina SchieferdeckerTarget Version => Edition 4.2.1 (not yet published)
21-04-2009 10:39Jens GrabowskiNote Added: 0008522
21-04-2009 12:02Jens GrabowskiFile Added: CR-4703-Explaination-of-standalone-receive-JG.doc
21-04-2009 12:03Jens GrabowskiNote Added: 0008525
21-04-2009 12:03Jens GrabowskiAssigned ToJens Grabowski => Ina Schieferdecker
01-07-2009 15:09Ina SchieferdeckerNote Added: 0008807
01-07-2009 15:09Ina SchieferdeckerResolutionopen => fixed
01-07-2009 15:10Ina SchieferdeckerStatusassigned => resolved
01-07-2009 15:10Ina SchieferdeckerFixed in Version => Edition 4.2.1 (not yet published)
01-07-2009 15:10Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0008522) +
+ Jens Grabowski    +
+ 21-04-2009 10:39    +
+ 		+ + + + +
+ The "confusing part" is used for the description of several stand-alone statements (e.g., done, trigger, timeout, killed). The simplification should be done for all statements/operations.
+
+
+
+ + + + + + + + + + +
+ (0008525) +
+ Jens Grabowski    +
+ 21-04-2009 12:03    +
+ 		+ + + + +
+ Proposal for resolution uploaded. Assigned to Ina for crosschecking.
+
+
+
+ + + + + + + + + + +
+ (0008807) +
+ Ina Schieferdecker    +
+ 01-07-2009 15:09    +
+ 		+ + + + +
+ Included as proposed.
+
+ + diff --git a/docs/mantis/CR4794.md b/docs/mantis/CR4794.md new file mode 100644 index 0000000000000000000000000000000000000000..cfc9e9fdc2c40eea053c7ab982bd1f9dfe46e56f --- /dev/null +++ b/docs/mantis/CR4794.md @@ -0,0 +1,419 @@ + + + + + + + + + + + + + 0004794: TTCN-3 white spaces - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0004794Part 01: TTCN-3 Core LanguageClarificationpublic04-02-2009 09:1906-07-2009 12:58
ReporterIna Schieferdecker 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.4.1 (published 2008-09) 
Target Versionv4.2.1 (published 2010-07)Fixed in Versionv4.2.1 (published 2010-07) 
Clause Reference(s)Annex A
Source (company - Author)Fraunhofer FOKUS - Ina Schieferdecker
Summary0004794: TTCN-3 white spaces
DescriptionThe TTCN-3 language definition is no explicit about white spaces such as blanks or line breaks. An enumeration of white spaces should be added for clarity.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Fileszip CR4794_resolution.zip (54,724) 21-04-2009 12:20
http://oldforge.etsi.org/mantis/file_download.php?file_id=2098&type=bug
ppt CR4794_discussionInput_v1.ppt (9,216) 22-04-2009 11:30
http://oldforge.etsi.org/mantis/file_download.php?file_id=2105&type=bug
zip CR4794_resolution v2.zip (54,724) 30-06-2009 14:54
http://oldforge.etsi.org/mantis/file_download.php?file_id=2143&type=bug
doc CR4794_resolution_part1 v3.doc (194,560) 01-07-2009 14:12
http://oldforge.etsi.org/mantis/file_download.php?file_id=2147&type=bug
doc CR4794_resolution_part1_v4.doc (196,096) 02-07-2009 18:04
http://oldforge.etsi.org/mantis/file_download.php?file_id=2154&type=bug
doc CR4794_resolution_part1_v5.doc (196,096) 03-07-2009 11:36
http://oldforge.etsi.org/mantis/file_download.php?file_id=2157&type=bug
doc CR4794_resolution_part1_v6.doc (194,560) 03-07-2009 13:28
http://oldforge.etsi.org/mantis/file_download.php?file_id=2161&type=bug
Issue History
Date ModifiedUsernameFieldChange
04-02-2009 09:19Ina SchieferdeckerNew Issue
04-02-2009 09:19Ina SchieferdeckerClause Reference(s) => Annex A
04-02-2009 09:19Ina SchieferdeckerSource (company - Author) => Fraunhofer FOKUS - Ina Schieferdecker
04-02-2009 09:20Ina SchieferdeckerProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
04-02-2009 09:21Ina SchieferdeckerAssigned To => Gyorgy Rethy
04-02-2009 09:21Ina SchieferdeckerStatusnew => assigned
04-02-2009 09:21Ina SchieferdeckerCategoryTTCN-3 Core Language => Clarification
04-02-2009 09:21Ina SchieferdeckerProduct Version => Edition 3.4.1 Published 2008-09-04
04-02-2009 09:21Ina SchieferdeckerTarget Version => Edition 4.2.1 (not yet published)
20-04-2009 16:40Gyorgy RethyNote Added: 0008515
20-04-2009 17:28Gyorgy RethyFile Added: CR4794_resolution_part1.doc
21-04-2009 11:56Gyorgy RethyFile Deleted: CR4794_resolution_part1.doc
21-04-2009 12:06Gyorgy RethyFile Added: CR4794_resolution_part1.zip
21-04-2009 12:14Gyorgy RethyNote Edited: 0008515
21-04-2009 12:16Gyorgy RethyFile Deleted: CR4794_resolution_part1.zip
21-04-2009 12:18Gyorgy RethyFile Added: CR4794_resolution_part1.zip
21-04-2009 12:19Gyorgy RethyNote Edited: 0008515
21-04-2009 12:19Gyorgy RethyFile Deleted: CR4794_resolution_part1.zip
21-04-2009 12:20Gyorgy RethyFile Added: CR4794_resolution.zip
21-04-2009 12:21Gyorgy RethyNote Edited: 0008515
22-04-2009 11:30Gyorgy RethyFile Added: CR4794_discussionInput_v1.ppt
22-04-2009 19:39Gyorgy RethyNote Added: 0008550
22-04-2009 19:39Gyorgy RethyResolutionopen => fixed
22-04-2009 19:46Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
30-06-2009 14:54Gyorgy RethyFile Added: CR4794_resolution v2.zip
01-07-2009 10:28Gyorgy RethyStatusassigned => resolved
01-07-2009 10:28Gyorgy RethyFixed in Version => Edition 4.2.1 (not yet published)
01-07-2009 10:28Gyorgy RethyNote Added: 0008802
01-07-2009 14:12Ina SchieferdeckerFile Added: CR4794_resolution_part1 v3.doc
01-07-2009 14:13Ina SchieferdeckerNote Added: 0008806
01-07-2009 14:55Ina SchieferdeckerStatusresolved => closed
02-07-2009 15:36Gyorgy RethyAssigned ToIna Schieferdecker => Gyorgy Rethy
02-07-2009 15:36Gyorgy RethyStatusclosed => feedback
02-07-2009 15:36Gyorgy RethyResolutionfixed => reopened
02-07-2009 15:36Gyorgy RethyNote Added: 0008816
02-07-2009 17:43Ina SchieferdeckerNote Added: 0008820
02-07-2009 18:04Gyorgy RethyFile Added: CR4794_resolution_part1_v4.doc
02-07-2009 18:09Gyorgy RethyNote Added: 0008822
02-07-2009 18:09Gyorgy RethyNote Added: 0008823
02-07-2009 18:09Gyorgy RethyStatusfeedback => assigned
02-07-2009 18:09Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
02-07-2009 18:10Gyorgy RethyNote Deleted: 0008823
03-07-2009 11:28Gyorgy RethyFile Added: CR4794_resolution_part1_v5.doc
03-07-2009 11:30Gyorgy RethyNote Added: 0008826
03-07-2009 11:31Gyorgy RethyNote Edited: 0008826
03-07-2009 11:36Gyorgy RethyFile Deleted: CR4794_resolution_part1_v5.doc
03-07-2009 11:36Gyorgy RethyFile Added: CR4794_resolution_part1_v5.doc
03-07-2009 13:28Ina SchieferdeckerFile Added: CR4794_resolution_part1_v6.doc
03-07-2009 13:29Ina SchieferdeckerNote Added: 0008832
03-07-2009 17:39Gyorgy RethyNote Added: 0008838
03-07-2009 17:39Gyorgy RethyStatusassigned => resolved
03-07-2009 17:39Gyorgy RethyResolutionreopened => fixed
06-07-2009 12:57Ina SchieferdeckerNote Added: 0008842
06-07-2009 12:58Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0008515) +
+ Gyorgy Rethy    +
+ 20-04-2009 16:40    +
(edited on: 21-04-2009 12:21)
+ 		+ + + + +
+ Terms "whitespace" and "newline" are used already clause B.1.5 (character pattern matching) and part-10. It is proposed to define whitespace and newline aligned with the existing terms. This shall cause no compatibility problem as normal text editors never use other controls than HT, SP, LF & CR, therefore "old" compilers will be able to read "new" TTCN-3 modules, just for "new" compilers there will be an exact and consistent rule.
+A new clause A.1.5.1 is proposed in part-1 and in Part-10 the reference has been changed from $B.1.5 to the new clause.
+See in file CR4794_resolution.zip.
+
+
+
+
+
+ + + + + + + + + + +
+ (0008550) +
+ Gyorgy Rethy    +
+ 22-04-2009 19:39    +
+ 		+ + + + +
+ Proposed solution is accepted by the STF in principle. Proposed text to be cross-checked.
+
+
+
+ + + + + + + + + + +
+ (0008802) +
+ Gyorgy Rethy    +
+ 01-07-2009 10:28    +
+ 		+ + + + +
+ Approved by CR resolution mtg.
+
+
+
+ + + + + + + + + + +
+ (0008806) +
+ Ina Schieferdecker    +
+ 01-07-2009 14:13    +
+ 		+ + + + +
+ Just one extension: keywords shall be separated by whitespace or newline.
+
+
+
+ + + + + + + + + + +
+ (0008816) +
+ Gyorgy Rethy    +
+ 02-07-2009 15:36    +
+ 		+ + + + +
+ some more correction is needed as newline is a subset of whitespace and no whitespace is needed between a special terminal and the neighbouring terminal
+
+
+
+ + + + + + + + + + +
+ (0008820) +
+ Ina Schieferdecker    +
+ 02-07-2009 17:43    +
+ 		+ + + + +
+ According to the text in A1.5.1, newline and whitespace are separated.
+
+It needs to be checked if alignment with B1.5.1 is needed.
+
+Furthermore, keywords, etc. are not only separated by whitespace or newline, but can also be separated by special characters like "(", "{", ";" etc.
+
+This needs to be added to the text.
+
+
+
+ + + + + + + + + + +
+ (0008822) +
+ Gyorgy Rethy    +
+ 02-07-2009 18:09    +
+ 		+ + + + +
+ CR4794_resolution_part1_v4.doc
+contains updates related to special terminal symbols as { } ( ) , ; := == etc. (may be but need not be separated by whitespace) and newline characters: a sequence of newline characters is just one end of line; needed because windows is using CRLF, but Unix is using just CR for a new line but both shall mean +1 line for the __LINE__ macro
+
+
+
+ + + + + + + + + + +
+ (0008826) +
+ Gyorgy Rethy    +
+ 03-07-2009 11:30    +
(edited on: 03-07-2009 11:31)
+ 		+ + + + +
+ CR4794_resolution_part1_v5.doc:
+The statement regarding the sequence of newline characters has been made more specific, namely the combination CRLF shall be taken as one end of line, other combinations are denote several new lines (e.g. CRVT is two lines).
+
+
+
+
+
+ + + + + + + + + + +
+ (0008832) +
+ Ina Schieferdecker    +
+ 03-07-2009 13:29    +
+ 		+ + + + +
+ Note 1 made part of the main text as it is not a hint but part of the specification. In addition, some rewording.
+
+
+
+ + + + + + + + + + +
+ (0008838) +
+ Gyorgy Rethy    +
+ 03-07-2009 17:39    +
+ 		+ + + + +
+ CR4794_resolution_part1_v6.doc
+Is OK with me.
+I have noticed, that not the whole new clause A.1.5.1 is shown as new text by word track changes markings just the last changes in the ~v6.doc. I suppose that the whole paragraph will be copied to the master document and will appear as new text. It will be important for the readers to find the few changes we make in the interim version quickly.
+
+
+
+ + + + + + + + + + +
+ (0008842) +
+ Ina Schieferdecker    +
+ 06-07-2009 12:57    +
+ 		+ + + + +
+ as proposed.
+
+ + diff --git a/docs/mantis/CR4847.md b/docs/mantis/CR4847.md new file mode 100644 index 0000000000000000000000000000000000000000..759c4217293d4f29740cdde9b9edb9f0a2f69c55 --- /dev/null +++ b/docs/mantis/CR4847.md @@ -0,0 +1,76 @@ + + + + + + + + + + + + + 0004847: What should lengthof return for arrays with indexing not started from zero - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0004847Part 01: TTCN-3 Core LanguageTechnicalpublic13-02-2009 07:4716-02-2009 05:34
ReporterGyorgy Rethy 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)C.28
Source (company - Author)L.M.Ericsson
Summary0004847: What should lengthof return for arrays with indexing not started from zero
DescriptionIn clause C.28 of part-1 the following sentence is ambiguous in the case of arrays, when indexing starts with a number different from zero:
+ 
+"For record of, set of, and array the value to be returned is the sequential number of the last initialized element (index of that element plus 1).
+ 
+E.g. in the following example:
+var integer v_intlist [3..5] := {0,0,0}
+var integer v_listnum := lengthof(v_intlist);
+ 
+shall lenghtof return 3 (the sequential number of the last element) or 6 (index of the last element plus 1) ?
+ 
+I propose that the "main text" is followed, i.e. the number of elements and the sentence is changed to:
+"For record of, set of, and array the value to be returned is the sequential number of the last initialized element (i.e. in case of record ofs, set ofs and arrays when the indexing starts from zero, the index of that element plus 1).
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
13-02-2009 07:47Gyorgy RethyNew Issue
13-02-2009 07:47Gyorgy RethyStatusnew => assigned
13-02-2009 07:47Gyorgy RethyAssigned To => Ina Schieferdecker
13-02-2009 07:47Gyorgy RethyClause Reference(s) => C.28
13-02-2009 07:47Gyorgy RethySource (company - Author) => L.M.Ericsson
13-02-2009 10:10Ina SchieferdeckerNote Added: 0008096
13-02-2009 10:10Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
13-02-2009 10:11Ina SchieferdeckerAssigned ToIna Schieferdecker => Gyorgy Rethy
16-02-2009 05:34Ina SchieferdeckerResolutionopen => fixed
16-02-2009 05:34Ina SchieferdeckerStatusassigned => resolved
16-02-2009 05:34Ina SchieferdeckerFixed in Version => Edition 4.1.1 (not yet published)
16-02-2009 05:34Ina SchieferdeckerStatusresolved => assigned
16-02-2009 05:34Ina SchieferdeckerAssigned ToGyorgy Rethy => Ina Schieferdecker
16-02-2009 05:34Ina SchieferdeckerStatusassigned => closed
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0008096) +
+ Ina Schieferdecker    +
+ 13-02-2009 10:10    +
+ 		+ + + + +
+ I propose to change into:
+
+For record of, set of, and array the value to be returned is the sequential number of the last initialized element: in case of record ofs and set ofs the index of that element plus 1. In case of arrays, lengthof should return the index of that last element minus the index of the first element plus 1.
+
+ + diff --git a/docs/mantis/CR4848.md b/docs/mantis/CR4848.md new file mode 100644 index 0000000000000000000000000000000000000000..6ac1afa0e9182268521b84830bab47b9522e07af --- /dev/null +++ b/docs/mantis/CR4848.md @@ -0,0 +1,65 @@ + + + + + + + + + + + + + 0004848: No record of, set of and arrays are supported by sizeof - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0004848Part 01: TTCN-3 Core LanguageTechnicalpublic13-02-2009 07:4813-02-2009 10:59
ReporterGyorgy Rethy 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)C.29
Source (company - Author)L.M.Ericsson
Summary0004848: No record of, set of and arrays are supported by sizeof
DescriptionIn the 1st paragraph the sentence " In the case of record of and set of values, templates or arrays, the actual value to be returned is the sequential number of the last defined element (index of that element plus 1)." shall be deleted.
+ 
+Reasons: In v3.3.2 of Part-1 the use of sizeof for record of, set of types and arrays has been deprecated. This was decided based on CR 2141. The new text of clause C.29 contained in CR383 (as a result of merging several CRs related to predefined functions) and in the text the above sentence is completely deleted. The existence of the above sentence in the published version of v3.3.2 is clearly an editorial error.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0002141closed Ina Schieferdecker Why having both lengthof and sizeof? 
related to 0000383closed Ina Schieferdecker Error Cases of Predefined Functions 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
13-02-2009 07:48Gyorgy RethyNew Issue
13-02-2009 07:48Gyorgy RethyStatusnew => assigned
13-02-2009 07:48Gyorgy RethyAssigned To => Ina Schieferdecker
13-02-2009 07:48Gyorgy RethyClause Reference(s) => C.29
13-02-2009 07:48Gyorgy RethySource (company - Author) => L.M.Ericsson
13-02-2009 10:14Ina SchieferdeckerRelationship addedrelated to 0002141
13-02-2009 10:14Ina SchieferdeckerRelationship addedrelated to 0000383
13-02-2009 10:59Ina SchieferdeckerNote Added: 0008097
13-02-2009 10:59Ina SchieferdeckerResolutionopen => fixed
13-02-2009 10:59Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
13-02-2009 10:59Ina SchieferdeckerStatusassigned => resolved
13-02-2009 10:59Ina SchieferdeckerFixed in Version => Edition 4.1.1 (not yet published)
13-02-2009 10:59Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0008097) +
+ Ina Schieferdecker    +
+ 13-02-2009 10:59    +
+ 		+ + + + +
+ Ok
+
+ + diff --git a/docs/mantis/CR4849.md b/docs/mantis/CR4849.md new file mode 100644 index 0000000000000000000000000000000000000000..a24c4ebe4b8c43420422c4f35a9ba97711e00ca1 --- /dev/null +++ b/docs/mantis/CR4849.md @@ -0,0 +1,123 @@ + + + + + + + + + + + + + 0004849: Misuse of the assignment operator - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0004849Part 01: TTCN-3 Core LanguageTechnicalpublic13-02-2009 10:2916-02-2009 05:07
ReporterGyorgy Rethy 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)22.2.2
Source (company - Author)L.M.Ericsson
Summary0004849: Misuse of the assignment operator
DescriptionIn clause 22.2.2 the assignment operator is re-used for storing parts of the received message. Normally, with the assignment symbol the rigth hand value is assigned to the entity on the left hand side of ":=". In this case the direction of the assignment is the opposite. This syntax causes really strange things like in the example of the draft "integer := MyIntegerVar".
+
+Use the storing symbol "->" to identify the parts to be stored.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0002757closed Ina Schieferdecker accessing parts of received messages 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
13-02-2009 10:29Gyorgy RethyNew Issue
13-02-2009 10:29Gyorgy RethyStatusnew => assigned
13-02-2009 10:29Gyorgy RethyAssigned To => Ina Schieferdecker
13-02-2009 10:29Gyorgy RethyClause Reference(s) => 22.2.2
13-02-2009 10:29Gyorgy RethySource (company - Author) => L.M.Ericsson
16-02-2009 05:02Ina SchieferdeckerNote Added: 0008100
16-02-2009 05:02Ina SchieferdeckerResolutionopen => fixed
16-02-2009 05:02Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
16-02-2009 05:07Ina SchieferdeckerStatusassigned => resolved
16-02-2009 05:07Ina SchieferdeckerStatusresolved => closed
16-02-2009 05:07Ina SchieferdeckerFixed in Version => Edition 4.1.1 (not yet published)
10-03-2009 09:37Ina SchieferdeckerRelationship addedrelated to 0002757
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0008100) +
+ Ina Schieferdecker    +
+ 16-02-2009 05:02    +
+ 		+ + + + +
+ Hello Ina and Gyorgy,
+
+after we discussed to some length whether it would be better to use '->' or ':=' I prefer to stick to the ':='. And in this case it would be sufficient to change the examples.
+
+Example 2 of 'catch' clause 22.3 should be changed, too:
+
+    MyPort.catch(MyProc, MyTemplate(5)) -> value (MyVarThree := f1 )
+                                           sender MyPeer;
+    // Catches an exception, assigns the value of its field f1 to MyVarThree and retrieves the
+    // address of the sender.
+
+Best regards
+
+Thomas
+
+>-----Original Message-----
+>From: ext Schieferdecker, Ina
+>[mailto:Ina.Schieferdecker@fokus.fraunhofer.de]
+>Sent: Friday, 13. February 2009 17:39
+>To: Deiss, Thomas (NSN - DE/Duesseldorf); ext Jens Grabowski
+>Cc: György Réthy
+>Subject: 0004849: Misuse of the assignment operator - Testing
+>- Online Reporting Tool
+>Importance: High
+>
+>Dear Thomas, dear Jens,
+>
+>this is an interesting one:
+>
+>http://t-ort.etsi.org/view.php?id=4849 [^]
+>
+>I think: when deciding to use := instead of -> it was
+>forgotten to switch the lhs and rhs in the examples.
+>
+>The syntax defines correctly that the variable reference is on the lhs.
+>
+>Can we agree to switch the lhs and rhs in the respective examples:
+>
+> MyPort.receive(MyType:?) -> value ( MyVar,
+>MyMessageIdVar := MyType.messageId )
+>
+>// The value of the received message is stored in the variable
+>
+>// MyVar and the value of the messageId field of the received
+>
+>// message is stored in the variable MyMessageIdVar.
+>
+> MyPort.receive(anytype:?) -> value ( MyIntegerVar := integer )
+>
+>// If the received value is an integer, it is stored in the variable
+>
+>// MyIntegerVar, a test case error otherwise.
+>
+>Thank you in advance for your fast response.
+>
+>With best regards,
+>
+>Ina
+>
+
+ + diff --git a/docs/mantis/CR4850.md b/docs/mantis/CR4850.md new file mode 100644 index 0000000000000000000000000000000000000000..77d94afadbaa0832115f6215a9fd177673f1019c --- /dev/null +++ b/docs/mantis/CR4850.md @@ -0,0 +1,925 @@ + + + + + + + + + + + + + 0004850: type compatibility of union does not coincide with union equality - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0004850Part 01: TTCN-3 Core LanguageTechnicalpublic13-02-2009 11:4926-02-2009 21:16
ReporterThomas Deiß 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)part1, 6.2., 7.1.3
Source (company - Author)Jacob Wieland, Testing Tech.
Summary0004850: type compatibility of union does not coincide with union equality
Descriptionreported by Jacob Wieland on draft of edition 4.1:
+
+I have a problem with the type compatibility of union types vs. the equality of union values in the current draft of the core language standard.
+
+As I understand it, a union type A is compatible to another union type B (meaning expressions of A can be used as expressions of B, I presume), if all its variants are also present in B - WITH THE SAME NAMES.
+
+In the section on relational operators, it is stated, that two union values that can be equal need not have the same variant names, just compatible types for 'counterparts' variants, (I guess, counterpart means the variant at the same place in the union types, judging from the examples, maybe this should be clarified further, as well).
+
+This means that two values of incompatible types can be equal in the case of unions. In my understanding, though, it is normally only allowed for compatible types to apply the comparison operators to. This seems to be a kind of contradiction or at least inconsistency, which could lead to a lot of confusion.
+
+Therefore, I would propose to either
+- change the union type compatibility in such a way that the existent comparison operator semantics can be applied, (i.e. by ignoring the field names and just regarding the order of the fields) OR
+- change the equality so that it is consistent with compatibility, i.e.
+the type of one of the compared values must be compatible with the type of the other one (which means the variants must be equally named and typed, but not in the same order, as I understand it), thereby getting equal union values if the variant with the same name is chosen in both and the variant values of both are equal.
+
+Although I like the second variant more, because I like the concept of union type compatibility that has been proposed, the change COULD cause backward incompatibilities in those cases where the current feature of name-independence and order-dependence for equality of union values was used. This is a question that should be asked if anyone knows of a test suite where this feature was used (which I actually doubt, cause it is a very strange definition of union equality in the first place).
+
+Therefore, I would vote for option 2, i.e. keeping the proposed type compatibility and changing the equality semantics.
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0004508closed Ina Schieferdecker type compatibility of relational operators 
Attached Filesdoc Resolution CR_4850.doc (158,208) 16-02-2009 11:55
http://oldforge.etsi.org/mantis/file_download.php?file_id=2001&type=bug
doc Resolution CR_4850_r1.doc (153,600) 16-02-2009 16:31
http://oldforge.etsi.org/mantis/file_download.php?file_id=2002&type=bug
doc Resolution CR_4850_r2.doc (155,136) 18-02-2009 08:29
http://oldforge.etsi.org/mantis/file_download.php?file_id=2004&type=bug
doc Resolution CR_4850_r3.doc (159,744) 20-02-2009 12:41
http://oldforge.etsi.org/mantis/file_download.php?file_id=2009&type=bug
doc Resolution_CR_4850_r4.doc (176,640) 20-02-2009 14:37
http://oldforge.etsi.org/mantis/file_download.php?file_id=2010&type=bug
doc Resolution_CR_4850_r5.doc (178,688) 20-02-2009 16:23
http://oldforge.etsi.org/mantis/file_download.php?file_id=2011&type=bug
doc Resolution_CR_4850_r6.doc (259,072) 26-02-2009 09:22
http://oldforge.etsi.org/mantis/file_download.php?file_id=2015&type=bug
doc Resolution_CR_4850_r7.doc (265,728) 26-02-2009 14:16
http://oldforge.etsi.org/mantis/file_download.php?file_id=2016&type=bug
doc Resolution_CR_4850_r8.doc (271,360) 26-02-2009 15:58
http://oldforge.etsi.org/mantis/file_download.php?file_id=2017&type=bug
Issue History
Date ModifiedUsernameFieldChange
13-02-2009 11:49Thomas DeißNew Issue
13-02-2009 11:49Thomas DeißStatusnew => assigned
13-02-2009 11:49Thomas DeißAssigned To => Ina Schieferdecker
13-02-2009 11:49Thomas DeißClause Reference(s) => part1, 6.2., 7.1.3
13-02-2009 11:49Thomas DeißSource (company - Author) => Jacob Wieland, Testing Tech.
13-02-2009 11:50Thomas DeißNote Added: 0008098
13-02-2009 12:49Thomas DeißTarget Version => Edition 4.1.1 (not yet published)
16-02-2009 05:46Ina SchieferdeckerNote Added: 0008102
16-02-2009 05:47Ina SchieferdeckerResolutionopen => fixed
16-02-2009 05:47Ina SchieferdeckerStatusassigned => resolved
16-02-2009 05:47Ina SchieferdeckerFixed in Version => Edition 4.1.1 (not yet published)
16-02-2009 05:49Ina SchieferdeckerRelationship addedrelated to 0004508
16-02-2009 05:50Ina SchieferdeckerStatusresolved => closed
16-02-2009 09:47Gyorgy RethyAssigned ToIna Schieferdecker => Thomas Deiß
16-02-2009 09:47Gyorgy RethyStatusclosed => feedback
16-02-2009 09:47Gyorgy RethyResolutionfixed => reopened
16-02-2009 09:47Gyorgy RethyNote Added: 0008106
16-02-2009 10:25Thomas DeißNote Added: 0008108
16-02-2009 10:26Thomas DeißAssigned ToThomas Deiß => Gyorgy Rethy
16-02-2009 10:26Thomas DeißStatusfeedback => assigned
16-02-2009 10:26Thomas DeißResolutionreopened => open
16-02-2009 10:29Ina SchieferdeckerNote Added: 0008109
16-02-2009 10:29Ina SchieferdeckerNote Edited: 0008109
16-02-2009 11:54Gyorgy RethyNote Added: 0008111
16-02-2009 11:55Gyorgy RethyFile Added: Resolution CR_4850.doc
16-02-2009 16:31Ina SchieferdeckerFile Added: Resolution CR_4850_r1.doc
18-02-2009 08:29Thomas DeißFile Added: Resolution CR_4850_r2.doc
20-02-2009 12:41Ina SchieferdeckerFile Added: Resolution CR_4850_r3.doc
20-02-2009 14:37Gyorgy RethyFile Added: Resolution_CR_4850_r4.doc
20-02-2009 14:46Gyorgy RethyNote Added: 0008167
20-02-2009 16:23Gyorgy RethyFile Added: Resolution_CR_4850_r5.doc
20-02-2009 16:28Gyorgy RethyNote Added: 0008171
24-02-2009 07:44Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
26-02-2009 09:22Gyorgy RethyFile Added: Resolution_CR_4850_r6.doc
26-02-2009 09:29Gyorgy RethyNote Added: 0008201
26-02-2009 14:16Gyorgy RethyFile Added: Resolution_CR_4850_r7.doc
26-02-2009 14:18Gyorgy RethyNote Added: 0008203
26-02-2009 15:58Gyorgy RethyFile Added: Resolution_CR_4850_r8.doc
26-02-2009 15:59Gyorgy RethyNote Added: 0008204
26-02-2009 21:15Ina SchieferdeckerStatusassigned => resolved
26-02-2009 21:15Ina SchieferdeckerResolutionopen => fixed
26-02-2009 21:16Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0008098) +
+ Thomas Deiß    +
+ 13-02-2009 11:50    +
+ 		+ + + + +
+ Discussion so far (email thread):
+Hello Gyorgy,
+
+Regarding this case 3: when checking the definition of equality again, I recognized that we avoided a general statement to require that equality can be applied to values of compatible types only. We defined equality type by type. Therefore we could also allow to compare arbitrary union values. Result in this specific case 3 would be false. Gyorgy, your proposal is then fine for me.
+
+I have added a specific proposal below:
+
+Current text in clause 7.1.3
+Two values of union types are equal if, and only if, the effective value structures of the union types are compatible, the selected fields in both values are the counterparts to each other, the types of the chosen fields are compatible and the actual values of the chosen fields are equal
+
+New proposal:
+Two values of union types are equal if, and only if, the both values are compatible with the type of the other value, the same alternative has been selected in both values, and the actual values of the chosen fields are equal.
+
+Best regards
+
+Thomas
+
+>-----Original Message-----
+>From: ext György Réthy [mailto:gyorgy.rethy@ericsson.com]
+>Sent: Thursday, 12. February 2009 11:39
+>To: Deiss, Thomas (NSN - DE/Duesseldorf); Schieferdecker, Ina; ext Jens
+>Grabowski
+>Cc: Jacob Wieland
+>Subject: RE: [MTS-GEN] Approval of TTCN-3 drafts for Edition 4.1.1
+>
+>Hi Thomas,
+>
+>In case 3) I would also always return false. Shortly, we are comparing
+>two values, u1 and u2. If the name of the selected alternative in both
+>values are the same AND the types of the selected alternatives are the
+>same (enumerated), compatible (structured types) or has the same root
+>type (basic types), comparision returns true, otherwise false.
+>
+>I think it would an unnecessary complication to separate the case type
+>union U1( integer a }; type union U2{integer a, integer b } from the
+>case type union U1( integer a }; type union U3{integer c, integer b }
+>
+>We also do allow comparing values of these integer subtypes, though it
+>is clear that they do not have a common subset, thus comparision can
+>never be true:
+>type integer I1 (0..2); type integer I2 (3..5);
+>
+>BTW. if the assignment in the example below could be reached, it would
+>cause test case error... but it can never be reached:
+>var I1 i1; var I2 i2;
+>... //some values are allocated to i1 and i2 if (i1 == i2) {i1 := i2}
+>
+>BR, Gyorgy
+>
+>
+>> -----Original Message-----
+>> From: Deiss, Thomas (NSN - DE/Duesseldorf)
+>> [mailto:thomas.deiss@nsn.com]
+>> Sent: 2009-február-12 11:07
+>> To: György Réthy; Schieferdecker, Ina; ext Jens Grabowski
+>> Cc: Jacob Wieland
+>> Subject: RE: [MTS-GEN] Approval of TTCN-3 drafts for Edition 4.1.1
+>>
+>> Hello Gyorgy,
+>>
+>> So, if there are two union types U1 and U2, and two values u1 and u2
+>> of type U1 and U2 respectively, then there are three cases:
+>>
+>> 1) If u1 is compatible with U2 and u2 is compatible with U1, then
+>> comparison is possible and if the same alternative is selected and
+>> holds the same value the result will be true, otherwise false.
+>> 2) If either u1 is compatible with U2 or u2 is compatible with U1,
+>> the comparison is allowed, but would always result in false.
+>> 3) If neither u1 is compatible with U2 nor u2 is compatible with U2,
+>> then this would be an error.
+>>
+>> Did I get your proposal correctly?
+>> If so, then this would be fine from my side.
+>>
+>> Best regards
+>>
+>> Thomas
+>>
+>> >-----Original Message-----
+>> >From: ext György Réthy [mailto:gyorgy.rethy@ericsson.com]
+>> >Sent: Wednesday, 11. February 2009 09:50
+>> >To: Deiss, Thomas (NSN - DE/Duesseldorf); Schieferdecker,
+>> Ina; ext Jens
+>> >Grabowski
+>> >Cc: Jacob Wieland
+>> >Subject: RE: [MTS-GEN] Approval of TTCN-3 drafts for Edition 4.1.1
+>> >Importance: High
+>> >
+>> >Hi Thomas,
+>> >
+>> >Your example will never fail with my union compatibility
+>> proposal! Once
+>> >the equality is true, in both values the same alternatives
+>> are chosen
+>> >and the asignment will be successful.
+>> >What I propose is, in fact, that the comparision "u1 == u2"
+>> >should not cause test case error; it should return false
+>> instead (thus
+>> >the assignment does not get control);
+>> >
+>> >As I wrote, I can see the situation here to be similar to e.g.
+>> >subtyped integers. See the examples:
+>> >type integer MyInt1 (0..1);
+>> >type integer MyInt2 (1..3);
+>> >type integer MyInt3 (2..3);
+>> >...
+>> >var MyInt1 int1; var MyInt2 int2; var MyInt3 int3; ...
+>> >int1 := int2; // may fail if int2 <> 1
+>> >int1 := int3; // will fail for sure
+>> >int3 := int1; // will fail for sure
+>> >if(int1 == int2) {int1 := int2; int2 := int1} //will never fail
+>> >if(int1 == int3) {int1 := int3; int3 := int1} //will never
+>> fail, just
+>> >the body of the if stmt. never executed
+>> >
+>> >I fact, looking at these examples, compatibility of (the
+>> >complete) union types should never be controlled at
+>> comparision, just
+>> >the compatibility of the selected alternatives (name and
+>field_type)
+>> >and always return false or true.
+>> >
+>> >BR, Gyorgy
+>> >
+>> >> -----Original Message-----
+>> >> From: Deiss, Thomas (NSN - DE/Duesseldorf)
+>> >> [mailto:thomas.deiss@nsn.com]
+>> >> Sent: 2009-február-11 8:31
+>> >> To: György Réthy; Schieferdecker, Ina; ext Jens Grabowski
+>> >> Cc: Jacob Wieland
+>> >> Subject: RE: [MTS-GEN] Approval of TTCN-3 drafts for Edition 4.1.1
+>> >>
+>> >> Hello Gyorgy,
+>> >>
+>> >> In my opinion, type compatibility and equality should be
+>> defined such
+>> >> that for two union variables u1, u2 of two different
+>types U1, U2,
+>> >> the following code never fails in the assignment.
+>> >> if (u1 == u2) {
+>> >> u1 := u2;
+>> >> ...
+>> >> Additionally, whereever u1 can be used in an operation or
+>> expression
+>> >> it is possible to use u2. This includes the usage of ischosen(),
+>> >> which could be used to check whether a different
+>> alternative than the
+>> >> currently chosen one has been chosen.
+>> >>
+>> >> This implies that the definition of equality is
+>> symmetrical, I think
+>> >> that just requiring that one union type is compatible with
+>> the other
+>> >> is not sufficient.
+>> >>
+>> >> Note that this property does not hold for record values
+>> (fieldnames
+>> >> are not considered in the check for equality), hence the strict
+>> >> definition above would be different to the definition of
+>> equality of
+>> >> other types.
+>> >>
+>> >> Best regards
+>> >>
+>> >> Thomas
+>> >>
+>> >> >-----Original Message-----
+>> >> >From: ext György Réthy [mailto:gyorgy.rethy@ericsson.com]
+>> >> >Sent: Tuesday, 10. February 2009 16:16
+>> >> >To: Deiss, Thomas (NSN - DE/Duesseldorf); Schieferdecker,
+>> >> Ina; ext Jens
+>> >> >Grabowski
+>> >> >Cc: Jacob Wieland
+>> >> >Subject: RE: [MTS-GEN] Approval of TTCN-3 drafts for
+>Edition 4.1.1
+>> >> >Importance: High
+>> >> >
+>> >> >Dear all,
+>> >> >
+>> >> >we also do support Jacob's proposal, i.e. option two,
+>namely that
+>> >> >compatibility of union values shall be based on equal field
+>> >> name and a
+>> >> >compatible value.
+>> >> >
+>> >> >But this second condition raises another question:
+>> >> >compatibility of union types, where the alternatives of
+>> one of the
+>> >> >types (call it A) is a subset of the alternatives in the
+>> >> another type
+>> >> >(call it B). In this case, a value of A could always be
+>> >> assigned to an
+>> >> >instance of B, i.e. A is compatible with B. This is fine in
+>> >> the case of
+>> >> >assignment( & alike) operations, but may cause problems in
+>> >> the case of
+>> >> >comparision (being defined as a symmetrical operation).
+>> >> >
+>> >> >What to do if a value of A (which is compatible with B) is
+>> >> compared to
+>> >> >an instance of B in which the selected alternative is
+>> >outside of the
+>> >> >common subset? Error or false? Error could be the principal
+>> >> answer but
+>> >> >false would be the practical one.
+>> >> >I feel this case to be similar to the case of comparing two
+>> >subtyped
+>> >> >integers, where the value sets of their types do not have
+>> a common
+>> >> >subset. Thus, I would say, if at least one of the union
+>values is
+>> >> >compatible to the type of the other value, comparision
+>> >should return
+>> >> >false in the above case.
+>> >> >
+>> >> >If you think this is a realistic use case, as one may want
+>> >> to restrict
+>> >> >the alternatives used in one message and allow the broader
+>> >> selection in
+>> >> >another message. As we do not have extensibility for
+>> types, the way
+>> >> >today is to define two - compatible - types (strictly for
+>> >> matching it
+>> >> >could be enough to define a base value set template, but
+>> >> this approach
+>> >> >would fail at the first case when the message or the union
+>> >> field has to
+>> >> >be passed as parameter).
+>> >> >
+>> >> >BR, Gyorgy
+>> >> >
+>> >> >> -----Original Message-----
+>> >> >> From: Deiss, Thomas (NSN - DE/Duesseldorf)
+>> >> >> [mailto:thomas.deiss@nsn.com]
+>> >> >> Sent: 2009-február-10 7:50
+>> >> >> To: Schieferdecker, Ina; ext Jens Grabowski; György Réthy
+>> >> >> Subject: FW: [MTS-GEN] Approval of TTCN-3 drafts for
+>> Edition 4.1.1
+>> >> >>
+>> >> >> Good morning together,
+>> >> >>
+>> >> >> Jacob raised an issue on compatibility of union types and
+>> >> equality of
+>> >> >> union values. I agree with Jacob's proposal to define
+>> >equality for
+>> >> >> two union values if the same alternative (indicated by
+>> >the name of
+>> >> >> the alternative) and the same value is chosen. As usual,
+>> >values of
+>> >> >> compatible union types can be compared against each other,
+>> >> they have
+>> >> >> the same alternatives and that the alternatives are defined
+>> >> >> identically.
+>> >> >>
+>> >> >> But this implies that there is a backwards incompatible
+>> >> change, see
+>> >> >> the example on equality of union values in clause
+>> 7.1.3. With the
+>> >> >> definitions above, some of the equal values would no
+>> >> longer be equal.
+>> >> >>
+>> >> >> What do you think, should we go for this change. If yes,
+>> >> then I could
+>> >> >> ask the tool vendors whether they are aware of any test
+>> >> suite where
+>> >> >> this would be a problem, and if ok propose the specific
+>> >> text. If no,
+>> >> >> then we probably should weaken the definition of type
+>> >> compatibility
+>> >> >> of union values such that it corresponds to this example:
+>> >> Two union
+>> >> >> types are compatible if they have the same number of
+>> >alternatives,
+>> >> >> and in the order of the definition, the types of the
+>> >> alternatives are
+>> >> >> compatible. Names of alternatives would not be relevant at all.
+>> >> >>
+>> >> >> I would also prefer Jacobs proposal.
+>> >> >>
+>> >> >> Best regards
+>> >> >>
+>> >> >> Thomas
+>> >> >>
+>> >> >> PS: Sorry for disturbing in case you received similar
+>> >> email already
+>> >> >> yesterday, but I had some problems with sending to MTS-GEN
+>> >> yesterday.
+>> >> >>
+>> >> >> >-----Original Message-----
+>> >> >> >From: Deiss, Thomas (NSN - DE/Duesseldorf)
+>> >> >> >Sent: Monday, 09. February 2009 10:11
+>> >> >> >To: 'Jacob Wieland'; MTS-GEN@LIST.ETSI.ORG
+>> >> >> >Subject: RE: [MTS-GEN] Approval of TTCN-3 drafts for
+>> >Edition 4.1.1
+>> >> >> >
+>> >> >> >Hello Jacob,
+>> >> >> >
+>> >> >> >Thanks for pointing this out.
+>> >> >> >
+>> >> >> >Yes, there is actually an inconsistency between 6.3.2.4 Type
+>> >> >> >compatibility of union types and 7.1.3. Relational Operators.
+>> >> >> >
+>> >> >> >I suggest also to use proposal 2). You are right, this
+>> >would be a
+>> >> >> >backward incompatible change. And you are also that the term
+>> >> >> >'counterpart' in 7.1.3 leaves room for interpretation
+>> >> (does it mean
+>> >> >> >same name or same position in the definition).
+>> >> >> >The example
+>> >> >> > conUniD1 == conUniE1;
+>> >> >> > // returns true
+>> >> >> >suggests that it is 'same position in the definition',
+>> >> >> independent of
+>> >> >> >the name of the alternative. Again, this would contradict the
+>> >> >> >definition of compatibility in clause 6.3.2.4.
+>> >> >> >Taking compatibility as in clause 6.3.2.4, 'counterpart'
+>> >> >> >should really mean that the same alternative (indicated
+>> >> by the same
+>> >> >> >name) is taken in both values.
+>> >> >> >
+>> >> >> >Best regards
+>> >> >> >
+>> >> >> >Thomas
+>> >> >> >
+>> >> >> >
+>> >> >> >
+>> >> >> >
+>> >> >> >>-----Original Message-----
+>> >> >> >>From: MTS_Gen [mailto:MTS-GEN@LIST.ETSI.ORG] On Behalf Of
+>> >> >ext Jacob
+>> >> >> >>Wieland
+>> >> >> >>Sent: Thursday, 05. February 2009 16:02
+>> >> >> >>To: MTS-GEN@LIST.ETSI.ORG
+>> >> >> >>Subject: Re: [MTS-GEN] Approval of TTCN-3 drafts for
+>> >> Edition 4.1.1
+>> >> >> >>
+>> >> >> >>Hello folks,
+>> >> >> >>
+>> >> >> >>I have a problem with the type compatibility of union
+>> >> >types vs. the
+>> >> >> >>equality of union values in the current draft of the
+>> >> core language
+>> >> >> >>standard.
+>> >> >> >>
+>> >> >> >>As I understand it, a union type A is compatible to another
+>> >> >> union type
+>> >> >> >>B (meaning expressions of A can be used as
+>expressions of B, I
+>> >> >> >presume),
+>> >> >> >>if all its variants are also present in B - WITH THE
+>> SAME NAMES.
+>> >> >> >>
+>> >> >> >>In the section on relational operators, it is stated, that
+>> >> >> two union
+>> >> >> >>values that can be equal need not have the same variant
+>> >> >names, just
+>> >> >> >>compatible types for 'counterparts' variants, (I guess,
+>> >> >counterpart
+>> >> >> >>means the variant at the same place in the union types,
+>> >> >> judging from
+>> >> >> >>the examples, maybe this should be clarified further,
+>> as well).
+>> >> >> >>
+>> >> >> >>This means that two values of incompatible types can be
+>> >> >> equal in the
+>> >> >> >>case of unions. In my understanding, though, it is
+>> >normally only
+>> >> >> >>allowed for compatible types to apply the comparison
+>> >> operators to.
+>> >> >> >>This seems to
+>> >> >> >>be a kind of contradiction or at least inconsistency, which
+>> >> >> >could lead
+>> >> >> >>to a lot of confusion.
+>> >> >> >>
+>> >> >> >>Therefore, I would propose to either
+>> >> >> >>- change the union type compatibility in such a way that
+>> >> >> the existent
+>> >> >> >>comparison operator semantics can be applied, (i.e. by
+>> >> >ignoring the
+>> >> >> >>field names and just regarding the order of the fields) OR
+>> >> >> >>- change the equality so that it is consistent with
+>> >> compatibility,
+>> >> >> >>i.e.
+>> >> >> >>the type of one of the compared values must be
+>> >> compatible with the
+>> >> >> >>type of the other one (which means the variants must be
+>> >> >> equally named
+>> >> >> >>and typed, but not in the same order, as I understand it),
+>> >> >> >thereby getting
+>> >> >> >>equal union values if the variant with the same name is
+>> >> >> >chosen in both
+>> >> >> >>and the variant values of both are equal.
+>> >> >> >>
+>> >> >> >>Although I like the second variant more, because I like the
+>> >> >> >concept of
+>> >> >> >>union type compatibility that has been proposed, the
+>> >> change COULD
+>> >> >> >>cause backward incompatibilities in those cases where
+>> >the current
+>> >> >> >feature of
+>> >> >> >>name-independence and order-dependence for equality of
+>> >> >union values
+>> >> >> >>was used. This is a question that should be asked if anyone
+>> >> >> knows of a
+>> >> >> >>test suite where this feature was used (which I actually
+>> >> >> doubt, cause
+>> >> >> >>it is a very strange definition of union equality in the
+>> >> >> first place).
+>> >> >> >>
+>> >> >> >>Therefore, I would vote for option 2, i.e. keeping the
+>> >> >> proposed type
+>> >> >> >>compatibility and changing the equality semantics.
+>> >> >> >>
+>> >> >> >>Best regards,
+>> >> >> >>
+>> >> >> >>Jacob Wieland
+>> >> >> >>
+>> >> >> >>--
+>> >> >>
+>> >>---------------------------------------------------------------
+>> >> >> >>----------
+>> >> >> >>Jacob Wieland
+>> >> >> >>Software Engineer
+>> >> >> >>
+>> >> >> >>Testing Technologies IST GmbH Michaelkirchstraße 17/18
+>> >> >> >>10179 Berlin, Germany
+>> >> >> >>
+>> >> >> >>Phone +49 30 726 19 19 34 Email
+>> >> >> wieland@testingtech.com
+>> >> >> >>Fax +49 30 726 19 19 20 Internet
+>> >> www.testingtech.com
+>> >> >>
+>> >>---------------------------------------------------------------
+>> >> >> >>----------
+>> >> >> >>
+>> >> >> >>UPCOMING EVENTS
+>> >> >> >>
+>> >> >> >>February 5, Free TTCN-3 Webinar
+>> >> >> >>TTCN-3 for Test Automation
+>> >> >> >>www.testingtech.com/services/ttcn3_webinar.php
+>> >> >> >>
+>> >> >> >>February 16-19, 2009, Mobile World Congress Barcelona,
+>> >> Spain, Hall
+>> >> >> >>2.1, Booth #B77 www.mobileworldcongress.com/
+>> >> >> >>
+>> >> >> >>February 18, 2009, sepp.med Expertensymposium Deutschland,
+>> >> >> >>Herzogenaurach www.seppmed.de/
+>> >> >> >>
+>> >> >>
+>> >>---------------------------------------------------------------
+>> >> >> >>----------
+>> >> >> >>Geschäftsführung: Theofanis Vassiliou-Gioles,
+>Stephan Pietsch
+>> >> >> >>Handelsregister HRB 77805, Amtsgericht Charlottenburg Ust
+>> >> >> ID Nr.: DE
+>> >> >> >>813 143 070
+>> >> >> >>
+>> >> >> >>This e-mail may contain confidential and privileged
+>> >> >> material for the
+>> >> >> >>sole use of the intended recipient. Any review, use,
+>> >> >> distribution or
+>> >> >> >>disclosure by others is strictly prohibited. If you
+>> are not the
+>> >> >> >>intended recipient (or authorized to receive for the
+>> >recipient),
+>> >> >> >>please contact the sender by reply e-mail and delete all
+>> >> copies of
+>> >> >> >>this message.
+>> >> >> >>
+>> >> >>
+>> >>
+>> >>-------------------------------------------------------------------
+>> >> >> >>Mail archive for MTS-GEN can be browsed at the
+>> following url :
+>> >> >> >> http://list.etsi.org/MTS-GEN.html [^]
+>> >> >>
+>> >>
+>> >>-------------------------------------------------------------------
+>> >> >> >>
+>> >> >> >
+>> >> >>
+>> >> >
+>> >>
+>> >
+>>
+>
+
+
+
+ + + + + + + + + + +
+ (0008102) +
+ Ina Schieferdecker    +
+ 16-02-2009 05:46    +
+ 		+ + + + +
+ 7.1.3 corrected as proposed: "Two values of union types are equal if, and only if, both values are compatible with the type of the other value, the same alternative has been selected in both values, and the actual values of the chosen fields are equal."
+
+
+
+ + + + + + + + + + +
+ (0008106) +
+ Gyorgy Rethy    +
+ 16-02-2009 09:47    +
+ 		+ + + + +
+ Unfortunately the proposed text would require that the types of the two values are completely identical and does not specify what should happen if two values of incompatible types (or a value compatible with the type of the other value) is compared (false or error)?
+
+
+
+ + + + + + + + + + +
+ (0008108) +
+ Thomas Deiß    +
+ 16-02-2009 10:25    +
+ 		+ + + + +
+ Seems that the 'if and only if' is not sufficient... Requested cased expressed explicitly.
+
+Two values of union types are equal if, and only if, both values are compatible with the type of the other value, the same alternative has been selected in both values, and the actual values of the chosen fields are equal. In case that the values are not compatible, a different alternative was chosen, or the actual values are different, the result shall be false.
+
+
+
+ + + + + + + + + + +
+ (0008109) +
+ Ina Schieferdecker    +
+ 16-02-2009 10:29    +
+ 		+ + + + +
+ An "if and only if" is content-wise expressive enough - I do not see a need to enumerate the other cases explicitly.
+
+
+
+
+
+ + + + + + + + + + +
+ (0008111) +
+ Gyorgy Rethy    +
+ 16-02-2009 11:54    +
+ 		+ + + + +
+ Pls. see my proposal for the text in the attached file.
+
+
+
+ + + + + + + + + + +
+ (0008167) +
+ Gyorgy Rethy    +
+ 20-02-2009 14:46    +
+ 		+ + + + +
+ Pls. find my additions in Resolution_CR_4850_r4.doc. Regarding the union stuff I have restored the sentence saying that comparing two union values shall not cause an error. It is important, as you can remember that the whole discussion on equality started with a mail on the TTCN-3 list (I think from Spain) asking, in which case comparision shall lead to error and in which case to false. So, it is important to be clear and explicit in this respect. Plus some editorials.
+
+I also added a new subclause on anytype compatibility. It differs slightly from union compatibility as in anytype type names are used as field identifiers. But while the name of a built-in TTCN-3 type denotes the same type in each module, two types with the same name defined in different modules denoting different types, thus shall not be "the same field name".
+
+
+
+ + + + + + + + + + +
+ (0008171) +
+ Gyorgy Rethy    +
+ 20-02-2009 16:28    +
+ 		+ + + + +
+ One more change in version ~r5.doc. The "root" type has nothing to do with type compatibility, therefore referencing to effective structures and clause 6.3 in the definition of root type is not correct; this is relevant only when defining which types are compatible within the whole set of a root type (e.g. which records are compatible and one are not).
+E.g.
+type integer I1 (0..2);
+type integer I2 (3..4);
+are not compatible (not a single instance of I1 is compatible with I2 and vice versa), still they have the same root type.
+
+
+
+ + + + + + + + + + +
+ (0008201) +
+ Gyorgy Rethy    +
+ 26-02-2009 09:29    +
+ 		+ + + + +
+ Pls. note:
+- I tried to apply the text proposed by Jens but did not copied it one-to-one.
+- I also copied and reviewede all uses of "root" in Part-1. I highlighted them with yellow for your convenience only, no other meaning behind.
+- I have also reviewed the definition of union type to remove inconsistency in the termilogy used in relation to unions and thus prevent misinterpretations.
+
+Good reading!
+
+
+
+ + + + + + + + + + +
+ (0008203) +
+ Gyorgy Rethy    +
+ 26-02-2009 14:18    +
+ 		+ + + + +
+ ~r7:
+- editorials are corrected, thank for the comments
+- three notes added, all of them are related to address; highlighted with blue background to make it easier to find them.
+
+
+
+ + + + + + + + + + +
+ (0008204) +
+ Gyorgy Rethy    +
+ 26-02-2009 15:59    +
+ 		+ + + + +
+ in ~r8:
+- Thomas's editorial comment is implemented
+- word comments are deleted
+
+ + diff --git a/docs/mantis/CR4851.md b/docs/mantis/CR4851.md new file mode 100644 index 0000000000000000000000000000000000000000..c64346f4bebe2167dbb8409e1b01baa1af03f63e --- /dev/null +++ b/docs/mantis/CR4851.md @@ -0,0 +1,78 @@ + + + + + + + + + + + + + 0004851: Editorials on Part-1 v4.0.4 - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0004851Part 01: TTCN-3 Core LanguageEditorialpublic13-02-2009 12:2716-02-2009 05:30
ReporterGyorgy Rethy 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)many
Source (company - Author)L.M.Ericsson
Summary0004851: Editorials on Part-1 v4.0.4
Description1) P. 19, figure 1: Other Types & Values box, index n is superflouos.
+2) $5.4.1.4 restrictions: first item is c)
+3) $5.4.1.2 restrictions: first item is h)
+4) $6.4 terminology "type renaming" is not really what we mean as not the name of the existing type is changed but an another type with another name is defined. Change the terminology to "type synonym" or "type alias".
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0003380closed Ina Schieferdecker Renaming of component, port, address type 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
13-02-2009 12:27Gyorgy RethyNew Issue
13-02-2009 12:27Gyorgy RethyStatusnew => assigned
13-02-2009 12:27Gyorgy RethyAssigned To => Ina Schieferdecker
13-02-2009 12:27Gyorgy RethyClause Reference(s) => many
13-02-2009 12:27Gyorgy RethySource (company - Author) => L.M.Ericsson
16-02-2009 05:26Ina SchieferdeckerRelationship addedrelated to 0003380
16-02-2009 05:29Ina SchieferdeckerNote Added: 0008101
16-02-2009 05:30Ina SchieferdeckerResolutionopen => fixed
16-02-2009 05:30Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
16-02-2009 05:30Ina SchieferdeckerStatusassigned => resolved
16-02-2009 05:30Ina SchieferdeckerFixed in Version => Edition 4.1.1 (not yet published)
16-02-2009 05:30Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0008101) +
+ Ina Schieferdecker    +
+ 16-02-2009 05:29    +
+ 		+ + + + +
+ 1) P. 19, figure 1: the index indicates that there can be more like there can be more presentation formats - changed however to n,m and k has the numbers of packages, language mappings and presentation formats can be different
+
+
+2) $5.4.1.4 restrictions: first item has to be a) --> changed
+
+3) $5.4.1.2 restrictions: first item has been a) --> not changed
+
+4) $6.4: clause 6.3.2.1 uses type synonym --> synonym used as follows:
+
+"6.4 Type synonym
+A type can be defined as a synonym to another type. Type synonyms can be defined for all kinds of types. Synonym types are compatible.
+EXAMPLE:
+    type MyType1 MyType2; // MyType2 is synonym to MyType1 "
+
+ + diff --git a/docs/mantis/CR4866.md b/docs/mantis/CR4866.md new file mode 100644 index 0000000000000000000000000000000000000000..a92d886af75a863a4558344235213508df6de964 --- /dev/null +++ b/docs/mantis/CR4866.md @@ -0,0 +1,77 @@ + + + + + + + + + + + + + 0004866: BNF ValueOrAttribList rule does not allow single-element lists - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0004866Part 01: TTCN-3 Core LanguageTechnicalpublic16-02-2009 10:5116-02-2009 15:50
ReporterPhilip Makedonski 
Assigned ToIna Schieferdecker 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.4.1 (published 2008-09) 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)Part1, A.1.6.1.3, Rule 139
Source (company - Author)P.M. Uni Goettingen
Summary0004866: BNF ValueOrAttribList rule does not allow single-element lists
DescriptionValueOrAttribList rule does not allow single-element lists, which results in broken compatibility with the ETSI IPv6 test suites, because of a change in the Complement rule:
+
+("+" denotes added rules, "-" denotes removed / substituted rules):
+
+(+)Complement ::= ComplementKeyword ValueOrAttribList
+(-)Complement ::= ComplementKeyword ValueList
+...
+ValueList ::= "(" ConstantExpression { "," ConstantExpression } ")"
+ValueOrAttribList ::= "(" TemplateBody { "," TemplateBody }+ ")"
+
+The problem is the "+" modifier in the ValueOrAttribList. The change to the Complement rule was introduced in v3.3.2 (with a misspelling of ValueOrAttribList as ValueOrAttribListValueList) and then corrected in v3.4.1. However the ValueOrAttribList rule itself has not been changed.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
16-02-2009 10:51Philip MakedonskiNew Issue
16-02-2009 10:51Philip MakedonskiStatusnew => assigned
16-02-2009 10:51Philip MakedonskiAssigned To => Ina Schieferdecker
16-02-2009 10:51Philip MakedonskiClause Reference(s) => Part1, A.1.6.1.3, Rule 139
16-02-2009 10:51Philip MakedonskiSource (company - Author) => P.M. Uni Goettingen
16-02-2009 15:46Ina SchieferdeckerNote Added: 0008117
16-02-2009 15:47Ina SchieferdeckerResolutionopen => fixed
16-02-2009 15:47Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
16-02-2009 15:47Ina SchieferdeckerStatusassigned => resolved
16-02-2009 15:47Ina SchieferdeckerFixed in Version => Edition 4.1.1 (not yet published)
16-02-2009 15:50Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0008117) +
+ Ina Schieferdecker    +
+ 16-02-2009 15:46    +
+ 		+ + + + +
+ This can be resolved by defining
+
+Complement ::= ComplementKeyword "(" TemplateBody {"," TemplateBody} ")"
+
+(ValueOrAttribList is needed as is for value list matching)
+
+ + diff --git a/docs/mantis/CR4904.md b/docs/mantis/CR4904.md new file mode 100644 index 0000000000000000000000000000000000000000..9d3f2ac5be98d4c648b3e44f21623407609a0e48 --- /dev/null +++ b/docs/mantis/CR4904.md @@ -0,0 +1,681 @@ + + + + + + + + + + + + + 0004904: top-level templates and inline-templates of type default are not allowed - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0004904Part 01: TTCN-3 Core LanguageClarificationpublic23-02-2009 14:5413-07-2009 07:23
ReporterJacob Wieland - Spirent 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.2.1 (published 2010-07)Fixed in Versionv4.2.1 (published 2010-07) 
Clause Reference(s)15.3, 15.4. 5.2
Source (company - Author)Testing Technology (Jacob Wieland)
Summary0004904: top-level templates and inline-templates of type default are not allowed
DescriptionIn the standard, it is explicitly forbidden to define templates of type 'default'.
+
+However, it is allowed to define constants, variables, even template variables (as I understand it), parameters and fields of type default.
+
+In the 3.4. version, it is even explicitly allowed to have parameters with default values of type default, even though only the default value 'null' is allowed. (This is also inconsistent, why should ? or other matching mechanisms not be allowed as default value for template parameters of default type?)
+
+Thus, it is possible to define a template of a record containing a default type field, but not a template of default type.
+
+I think this restriction is unnecessary, so I would propose to simply drop it from the standard.
+
+The other way to achieve consistency would be to forbid defaults also for constants and for everything that has to do with templates, i.e. it should not be possible to define templates of a type containing a default field.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesppt CR4904_discussionInput_v2.ppt (37,888) 22-04-2009 15:48
http://oldforge.etsi.org/mantis/file_download.php?file_id=2111&type=bug
zip CR4904_resolution_v1.zip (874,798) 09-07-2009 10:59
http://oldforge.etsi.org/mantis/file_download.php?file_id=2200&type=bug
zip CR4904_resolution_v2.zip (908,192) 13-07-2009 07:22
http://oldforge.etsi.org/mantis/file_download.php?file_id=2214&type=bug
Issue History
Date ModifiedUsernameFieldChange
23-02-2009 14:54Jacob Wieland - SpirentNew Issue
23-02-2009 14:54Jacob Wieland - SpirentStatusnew => assigned
23-02-2009 14:54Jacob Wieland - SpirentAssigned To => Ina Schieferdecker
23-02-2009 14:54Jacob Wieland - SpirentClause Reference(s) => 15.3, 15.4. 5.2
23-02-2009 14:54Jacob Wieland - SpirentSource (company - Author) => Testing Technology (Jacob Wieland)
27-02-2009 10:31Gyorgy RethyNote Added: 0008205
27-02-2009 13:25Jacob Wieland - SpirentNote Added: 0008206
27-02-2009 13:59Gyorgy RethyNote Added: 0008207
27-02-2009 14:01Gyorgy RethyNote Edited: 0008207
28-02-2009 10:31Jacob Wieland - SpirentNote Added: 0008208
03-03-2009 11:04Gyorgy RethyNote Added: 0008221
10-03-2009 10:22Ina SchieferdeckerTarget Version => Edition 4.2.1 (not yet published)
20-04-2009 11:48Ina SchieferdeckerAssigned ToIna Schieferdecker => Gyorgy Rethy
21-04-2009 15:04Gyorgy RethyFile Added: what can be of default type.doc
21-04-2009 15:07Gyorgy RethyFile Deleted: what can be of default type.doc
21-04-2009 15:07Gyorgy RethyFile Added: what can be of default type.doc
22-04-2009 11:06Gyorgy RethyFile Deleted: what can be of default type.doc
22-04-2009 11:13Gyorgy RethyFile Added: CR4904_discussionInput_v1.ppt
22-04-2009 11:14Gyorgy RethyNote Added: 0008531
22-04-2009 12:16Jacob Wieland - SpirentNote Added: 0008533
22-04-2009 12:17Jacob Wieland - SpirentNote Edited: 0008533
22-04-2009 14:14Gyorgy RethyFile Deleted: CR4904_discussionInput_v1.ppt
22-04-2009 14:14Gyorgy RethyFile Added: CR4904_discussionInput_v1.ppt
22-04-2009 14:19Gyorgy RethyNote Added: 0008538
22-04-2009 14:52Jacob Wieland - SpirentNote Added: 0008540
22-04-2009 15:07Gyorgy RethyNote Added: 0008541
22-04-2009 15:48Gyorgy RethyFile Added: CR4904_discussionInput_v2.ppt
22-04-2009 15:55Gyorgy RethyNote Added: 0008542
22-04-2009 16:46Jacob Wieland - SpirentNote Added: 0008545
22-04-2009 18:27Gyorgy RethyNote Added: 0008548
22-04-2009 18:27Gyorgy RethyFile Deleted: CR4904_discussionInput_v1.ppt
24-04-2009 12:01Jacob Wieland - SpirentNote Added: 0008552
07-07-2009 08:08Ina SchieferdeckerNote Added: 0008851
08-07-2009 16:17Ina SchieferdeckerNote Deleted: 0008851
09-07-2009 10:59Gyorgy RethyFile Added: CR4904_resolution_v1.zip
09-07-2009 11:02Gyorgy RethyNote Added: 0008881
09-07-2009 11:06Gyorgy RethyNote Edited: 0008881
09-07-2009 11:07Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
09-07-2009 11:07Gyorgy RethyResolutionopen => fixed
13-07-2009 07:22Ina SchieferdeckerFile Added: CR4904_resolution_v2.zip
13-07-2009 07:22Ina SchieferdeckerNote Added: 0008894
13-07-2009 07:23Ina SchieferdeckerStatusassigned => resolved
13-07-2009 07:23Ina SchieferdeckerFixed in Version => Edition 4.2.1 (not yet published)
13-07-2009 07:23Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0008205) +
+ Gyorgy Rethy    +
+ 27-02-2009 10:31    +
+ 		+ + + + +
+ default is not allowed for template variables: "11.2 Template variables
+A TTCN-3 template variable stores templates.". I.e. in this respect, the same restriction apply to template variables as to templates (they do differ from templates only in the dynamics of defining the content).
+
+If you think about the use of defaults, if would make no sense to allow defaults for templates; default variables store handles of activated defaults, which has local significance only and loose sense outside of the given component. Hence, default values are not know when writing global definitions and cannot be sent outside of a component.
+
+If this is not specified clearly enough in the text, the explanation shall be made more clear.
+
+
+
+ + + + + + + + + + +
+ (0008206) +
+ Jacob Wieland - Spirent    +
+ 27-02-2009 13:25    +
+ 		+ + + + +
+ Then why allow template parameters of type default (and restrict their default value explicitly to only 'null'?) This seems inconsistent (or maybe it is just a copy/paste error?).
+
+Also, you forget that templates can not only be used for sending/receiving messages. They can also used locally with the 'match' operation or with the 'select' statement. In that respect, a template that enumerates certain activated defaults could be a valid template.
+
+An example:
+
+function deactivateIfMatches(default d, template default dt) {
+  if (match(d, dt)) {
+     deactivate(d);
+  }
+}
+
+then suppose, you get passed a default parameter and you want to deactivate it only, if it is one of a list of defaults which you have stored in variables.
+
+deactivateIfMatches(d, (d1, d2, d3))
+
+The same could be true if you want to deactivate it unless it is one of the list:
+
+deactivateIfMatches(d, complement(d1, d2, d3))
+
+Of course, these scenarios may be far fetched, but if such things work for other data types, why should default be any different? I could understand a restriction that default values cannot be sent and therefore any receive operation using a template with defaults would make no sense, either. But, this should not be achieved by restricting the definition of templates of that type, but by restricting the communication statements.
+
+Sure, as globally, no default references are known, for global templates only the matching mechanisms which do not refer to any specific default instance are allowed (like ?, *, etc.), but, for generic or local templates, no such restriction is necessary.
+
+
+
+ + + + + + + + + + +
+ (0008207) +
+ Gyorgy Rethy    +
+ 27-02-2009 13:59    +
(edited on: 27-02-2009 14:01)
+ 		+ + + + +
+ The user do not need a template for that. Even if default is allowed in templates, only concrete values and the AnyValue matching would be possible to use, as the concrete default values are not known. But using AnyValue is the same as a non-null value or isvalue. Thus, the same use case can be coded by more than one alternative ways, e.g.
+
+type record of default RD;
+function deactivateIfMatches(default d, RD rd) {
+  for (var integer i := 0; i<lengthof(rd); i:=i+1) {
+    if (rd[i]==d) {deactivate(d)}
+  }
+}
+
+
+But allowing defaults in templates is too dangerouos and I cannot see a real use case for it, i.e. a problem, which cannot be solved by coding techniques available today. The same is true to the other examples you mention.
+
+Inconsistencies, of course, shall be removed. This will be the task of the next language maintenance project.
+
+
+
+
+
+ + + + + + + + + + +
+ (0008208) +
+ Jacob Wieland - Spirent    +
+ 28-02-2009 10:31    +
+ 		+ + + + +
+ The problem I have with this is the following:
+
+If it is so "dangerous" do define templates of type default, then why is it not forbidden also to define templates of a structured type that contains a default type element somewhere? Either this must also be forbidden (as it is as "dangerous" as defining a top-level default type template), or the top-level template must be allowed. The reason, as I see it is, that it is of course USEFUL to have structured types that can also contain default fields (as your alternative implementation of my example shows). If it were also forbidden, it would not even be possible to implement such a scenario as I have described.
+
+Thus, since such a restriction would be impractical, I still think that simply forbidding all communication operations to use templates that contain a default value, which can easily be checked statically, would avert the "danger" that you are talking about, as well.
+
+The benefit of this approach is, of course, that the powerful and elegant matching mechanisms that exist in the language can be used for all types, and it is not necessary to use the "cruder" means of iterating over arrays or suchlike.
+
+The same arguments can also be applied to component types, of course.
+
+
+
+ + + + + + + + + + +
+ (0008221) +
+ Gyorgy Rethy    +
+ 03-03-2009 11:04    +
+ 		+ + + + +
+ Component types do differ: component references are unique within the test system, while default references are unique within a test component only.
+
+I agree with you in that top-level default types and default fields shall be handled in the same way.
+
+For me it would be also fine to disallow any templates containing default (i.e. top-level or in embedded fields) in sending operations only.
+
+
+
+ + + + + + + + + + +
+ (0008531) +
+ Gyorgy Rethy    +
+ 22-04-2009 11:14    +
+ 		+ + + + +
+ The file CR4904_discussionInput_v1.ppt contains exactly what its name suggests: input for the discussion.
+
+
+
+ + + + + + + + + + +
+ (0008533) +
+ Jacob Wieland - Spirent    +
+ 22-04-2009 12:16    +
(edited on: 22-04-2009 12:17)
+ 		+ + + + +
+ Somehow, the discussion input presentation seems to ignore most of the discussion which took place before and also negates the compromise that seemed to have been reached.
+
+The question remains: Why forbid elegant means of matching (via match/select opterations) for one data type that is allowed for all other data types?
+Every unnecessary restriction makes the language harder to use (no one can keep all the restrictions in mind) and also harder to compile (every restriction must be checked which slows down the compiler). Both these things make developing test suites more expensive as it will take more time.
+
+The danger that a component-local default reference is passed outside its scope can also be averted by restricting the means of passing such references to other scopes (i.e. communication operations, starting of ptcs, maybe external functions).
+The advantage of this approach is
+a) it is understandable (and thus easier to keep in mind as the arbitrary restriction on templates)
+b) it is consistent with the handling of other data types that are only used locally,
+c) it is as easy/hard to check as the other proposed restriction.
+Thus, I think it is a better approach as it has not all of the drawbacks and some advantages over the other while still achieving the same goal of averting the aforementioned danger.
+
+
+
+
+
+ + + + + + + + + + +
+ (0008538) +
+ Gyorgy Rethy    +
+ 22-04-2009 14:19    +
+ 		+ + + + +
+ Pls. don't mix up persnal view with an STF discussion.
+Could you give a concrete example on
+- how to create a meaningful default template?
+- exactly what matching could be used on it that cannot be solved by using existing operations on values?
+
+
+
+ + + + + + + + + + +
+ (0008540) +
+ Jacob Wieland - Spirent    +
+ 22-04-2009 14:52    +
+ 		+ + + + +
+ That is beside the point. It is not necessary that I provide an example. Please address the issues I have raised and do not simply dismiss them as personal opinon.
+
+Of course, everything can be done with value operations. That is true for all other types, as well and we allow templates there nonetheless to allow short-hand notations for complex predicates. If templates could only be used for communication, I would see your point, but since that is not the case, I think it is invalid.
+
+Since there is an elegant syntax (like value-list, complement, subset, superset, ?) which enables you to write down very complicated things in a relatively short way, why forbid users to USE this syntax for this special type and force them to write the complicated algorithms themselves if they actually need such a complicated check. If I were a TTCN-3 user, I would wonder about such idiosyncracies. Just because you and I cannot think of a meaningful real-world example doesn't mean that there isn't one. Why restrict the language unnecessarily? That is my question.
+
+You want to reach a certain goal to avoid programming errors, fine. There are two (proposed) ways to reach that goal. Your proposal restricts the language more than necessary for reaching the goal because it restricts valid possible applications of the template mechanism. My proposal restricts the language exactly as necessary to reach the goal because it still allows templates containing default values to be used by match operations or select constructs.
+
+So, why is your proposal better? Shouldn't we keep the language as simple and flexible and usable as possible?
+
+
+
+ + + + + + + + + + +
+ (0008541) +
+ Gyorgy Rethy    +
+ 22-04-2009 15:07    +
+ 		+ + + + +
+ Hi Jacob,
+what I meant on personal opinion is my sentence from 3rd of March: "For me it would be also fine ..." etc.
+
+Your notes/comments are taken into consideration properly.
+
+You wrote: "It is not necessary that I provide an example.". As you are asking to change the language rules, a proper reason has to be provided. Either a use-case example that cannot be solved by the existing language features or the solution is over-complicated, or e.g. a language inconsistency issue. The reason you provided currently falls into the second category. So it can be solved both in the more strict or in the more loose directions. In TTCN-3 we prefer if more errors can be found compile time that hints the solution in the more strict direction.
+
+
+
+ + + + + + + + + + +
+ (0008542) +
+ Gyorgy Rethy    +
+ 22-04-2009 15:55    +
+ 		+ + + + +
+ In CR4904_discussionInput_v2.ppt: more analysis added on possible use of matching with defaults.
+
+
+
+ + + + + + + + + + +
+ (0008545) +
+ Jacob Wieland - Spirent    +
+ 22-04-2009 16:46    +
+ 		+ + + + +
+ Okay, sorry for the misunderstanding. I don't think that every language feature must be motivated by a now-existing real-world use-case. The consistency of the language is much more important in my view.
+
+I don't think that it can be argued that in one proposal more can be checked at compile time than in the other.
+
+The proposal to restrict the communication statements to only templates not containing values/fields of default type can also be checked at compile time as the type of the sent template is always known.
+
+The only exception is the anytype type where the contents are not known. However, the same problem occurs as well in your more restrictive variant, i.e. if all templates are forbidden for types that are/contain values of type default, this can be circumvented by using anytype instead (and using the anytype to encapsulate a value of type default).
+
+This obviously can only be checked at runtime (in either version).
+
+
+
+ + + + + + + + + + +
+ (0008548) +
+ Gyorgy Rethy    +
+ 22-04-2009 18:27    +
+ 		+ + + + +
+ STF discussion on 22/April/2009:
+- the inconsistency raised by the CR exists in the standard;
+- template formal parameters, template variables and function template returns are not forbidden to be of default type but table 10 prevents to assign them any content (even specific value);
+- the proposal of the STF is to consistently forbid all template-kind language elements to be of default type;
+- ask the tool vendors if there is any problem with the prposed changes;
+- check if this restriction can be done in a single place in the standard instead of spreading t over several clauses;
+- in addition check, if sending/receiving default values is forbidden explicitly
+
+
+
+ + + + + + + + + + +
+ (0008552) +
+ Jacob Wieland - Spirent    +
+ 24-04-2009 12:01    +
+ 		+ + + + +
+ For consistency's sake, if you want to forbid all templates for type default, then all templates for structured types that contain type default should also be forbidden.
+
+
+
+ + + + + + + + + + +
+ (0008881) +
+ Gyorgy Rethy    +
+ 09-07-2009 11:02    +
(edited on: 09-07-2009 11:06)
+ 		+ + + + +
+ CR4904_resolution_v1.doc:
+Resolution according to the CR resolution meeting decision. Not much text but spread almost all over Part-1. Therefore the whole Part-1 file is included, with modifications. To be checked.
+
+
+
+
+
+ + + + + + + + + + +
+ (0008894) +
+ Ina Schieferdecker    +
+ 13-07-2009 07:22    +
+ 		+ + + + +
+ editorial corrections - see v2
+
+ + diff --git a/docs/mantis/CR4934.md b/docs/mantis/CR4934.md new file mode 100644 index 0000000000000000000000000000000000000000..6658d466f6f1d2e9dbb35c11a041fdf142ba8d6a --- /dev/null +++ b/docs/mantis/CR4934.md @@ -0,0 +1,212 @@ + + + + + + + + + + + + + 0004934: valueof cannot return omit - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0004934Part 01: TTCN-3 Core LanguageClarificationpublic03-03-2009 11:1309-07-2009 11:31
ReporterGyorgy Rethy 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.2.1 (published 2010-07)Fixed in Versionv4.2.1 (published 2010-07) 
Clause Reference(s)15.10
Source (company - Author)L.M.Ericsson
Summary0004934: valueof cannot return omit
DescriptionThe question, if omit is a value or not is raised by users time-to-time. This point has been discussed within the STF several times, coming to the conclusion, that omit is not a value (i.e. var integer int := omit //causes error) but the text of the standard has not been changed. This question has also been raised by TF160, in relation to valueof().
+It is proposed to add the following example to clause 15.10:
+function f (template(omit) integer pl_int) {
+  var integer int := valueof(pl_int)
+  ...
+}
+...
+function f2 () {
+  f(5); //correct
+  f(omit);// will cause an error within f(), as omit is not a value, thus cannot be returned by valueof
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR4934_Valueof_omit.doc (131,584) 06-07-2009 11:57
http://oldforge.etsi.org/mantis/file_download.php?file_id=2167&type=bug
doc CR4934_Valueof_omit v2.doc (261,632) 06-07-2009 13:34
http://oldforge.etsi.org/mantis/file_download.php?file_id=2169&type=bug
doc CR4934_Valueof_omit v3.doc (270,848) 07-07-2009 09:44
http://oldforge.etsi.org/mantis/file_download.php?file_id=2175&type=bug
doc CR4934_Valueof_omit_v4.doc (271,360) 08-07-2009 15:26
http://oldforge.etsi.org/mantis/file_download.php?file_id=2192&type=bug
Issue History
Date ModifiedUsernameFieldChange
03-03-2009 11:13Gyorgy RethyNew Issue
03-03-2009 11:13Gyorgy RethyStatusnew => assigned
03-03-2009 11:13Gyorgy RethyAssigned To => Ina Schieferdecker
03-03-2009 11:13Gyorgy RethyClause Reference(s) => 15.10
03-03-2009 11:13Gyorgy RethySource (company - Author) => L.M.Ericsson
10-03-2009 10:21Ina SchieferdeckerTarget Version => Edition 4.2.1 (not yet published)
20-04-2009 11:49Ina SchieferdeckerAssigned ToIna Schieferdecker => Tibor Csöndes
06-07-2009 11:57Tibor CsöndesFile Added: CR4934_Valueof_omit.doc
06-07-2009 11:57Tibor CsöndesNote Added: 0008840
06-07-2009 11:58Tibor CsöndesAssigned ToTibor Csöndes => Gyorgy Rethy
06-07-2009 13:34Gyorgy RethyFile Added: CR4934_Valueof_omit v2.doc
06-07-2009 13:37Gyorgy RethyNote Added: 0008843
06-07-2009 13:38Gyorgy RethyNote Edited: 0008843
06-07-2009 13:39Gyorgy RethyAssigned ToGyorgy Rethy => Tibor Csöndes
06-07-2009 15:42Tibor CsöndesNote Added: 0008846
06-07-2009 15:42Tibor CsöndesAssigned ToTibor Csöndes => Ina Schieferdecker
07-07-2009 09:43Ina SchieferdeckerNote Added: 0008852
07-07-2009 09:44Ina SchieferdeckerFile Added: CR4934_Valueof_omit v3.doc
07-07-2009 09:44Ina SchieferdeckerResolutionopen => fixed
08-07-2009 15:25Gyorgy RethyNote Added: 0008875
08-07-2009 15:26Gyorgy RethyFile Added: CR4934_Valueof_omit_v4.doc
08-07-2009 15:26Gyorgy RethyStatusassigned => resolved
09-07-2009 11:30Ina SchieferdeckerStatusresolved => closed
09-07-2009 11:31Ina SchieferdeckerFixed in Version => Edition 4.2.1 (not yet published)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0008840) +
+ Tibor Csöndes    +
+ 06-07-2009 11:57    +
+ 		+ + + + +
+ According to the suggestion an initial version uploaded.
+
+
+
+ + + + + + + + + + +
+ (0008843) +
+ Gyorgy Rethy    +
+ 06-07-2009 13:37    +
(edited on: 06-07-2009 13:38)
+ 		+ + + + +
+ CR4934_Valueof_omit v2.doc:
+Description of omit is also cleaned up in clause 15.7 and in Annex B as there are too many unclarities and questions about omit, and the current text in the standard really can easily be misunderstood.
+
+
+
+
+
+ + + + + + + + + + +
+ (0008846) +
+ Tibor Csöndes    +
+ 06-07-2009 15:42    +
+ 		+ + + + +
+ Version v2 is OK with me!
+
+
+
+ + + + + + + + + + +
+ (0008852) +
+ Ina Schieferdecker    +
+ 07-07-2009 09:43    +
+ 		+ + + + +
+ some editorial changes
+
+
+
+ + + + + + + + + + +
+ (0008875) +
+ Gyorgy Rethy    +
+ 08-07-2009 15:25    +
+ 		+ + + + +
+ CR4934_Valueof_omit_v4.doc:
+Only editorial changes. OK with me.
+
+ + diff --git a/docs/mantis/CR4944.md b/docs/mantis/CR4944.md new file mode 100644 index 0000000000000000000000000000000000000000..d405e98a18511f26e770d4d53929e4dfe6fd7c6e --- /dev/null +++ b/docs/mantis/CR4944.md @@ -0,0 +1,187 @@ + + + + + + + + + + + + + 0004944: position index of field record type - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0004944Part 01: TTCN-3 Core LanguageEditorialpublic05-03-2009 16:5701-07-2009 15:41
ReporterElena de Vega 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.4.1 (published 2008-09) 
Target Versionv4.2.1 (published 2010-07)Fixed in Versionv4.2.1 (published 2010-07) 
Clause Reference(s)field record
Source (company - Author) MTP - Elena de Vega
Summary0004944: position index of field record type
DescriptionIn the core language document B.1.1 there is an example of a record type where the last field is an array.
+
+type record MyMessageType
+{
+  integer field1,
+  charstring field2,
+  boolean field3 optional,
+  integer[4] field4
+}
+
+The position index is located after the field type, although in the grammar, this index is located after the field identifier.
+
+StructFieldDef ::= (Type | NestedTypeDef) StructFieldIdentifier [ArrayDef] [SubTypeSpec] [OptionalKeyword]
+
+
+If the right position is after the field identifier then the example has to be changed, if not it would be the grammar the one to change.
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR4944_resolution_part-1.doc (137,728) 21-04-2009 09:32
http://oldforge.etsi.org/mantis/file_download.php?file_id=2092&type=bug
doc CR4944_resolution_part-1 v2.doc (130,048) 22-04-2009 19:34
http://oldforge.etsi.org/mantis/file_download.php?file_id=2113&type=bug
doc CR4944_resolution_part-1 v3.doc (131,072) 01-07-2009 15:40
http://oldforge.etsi.org/mantis/file_download.php?file_id=2150&type=bug
Issue History
Date ModifiedUsernameFieldChange
05-03-2009 16:57Elena de VegaNew Issue
05-03-2009 16:57Elena de VegaStatusnew => assigned
05-03-2009 16:57Elena de VegaAssigned To => Ina Schieferdecker
05-03-2009 16:57Elena de VegaClause Reference(s) => field record
05-03-2009 16:57Elena de VegaSource (company - Author) => MTP - Elena de Vega
10-03-2009 10:21Ina SchieferdeckerTarget Version => Edition 4.2.1 (not yet published)
20-04-2009 11:51Ina SchieferdeckerAssigned ToIna Schieferdecker => Gyorgy Rethy
20-04-2009 17:46Gyorgy RethyNote Added: 0008516
20-04-2009 18:17Elena de VegaNote Added: 0008517
21-04-2009 09:28Gyorgy RethyNote Edited: 0008516
21-04-2009 09:32Gyorgy RethyFile Added: CR4944_resolution_part-1.doc
21-04-2009 09:33Gyorgy RethyNote Edited: 0008516
22-04-2009 19:34Gyorgy RethyFile Added: CR4944_resolution_part-1 v2.doc
22-04-2009 19:36Gyorgy RethyNote Added: 0008549
22-04-2009 19:36Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
22-04-2009 19:36Gyorgy RethyStatusassigned => resolved
22-04-2009 19:36Gyorgy RethyResolutionopen => fixed
01-07-2009 15:39Ina SchieferdeckerNote Added: 0008811
01-07-2009 15:40Ina SchieferdeckerFile Added: CR4944_resolution_part-1 v3.doc
01-07-2009 15:41Ina SchieferdeckerStatusresolved => closed
01-07-2009 15:41Ina SchieferdeckerFixed in Version => Edition 4.2.1 (not yet published)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0008516) +
+ Gyorgy Rethy    +
+ 20-04-2009 17:46    +
(edited on: 21-04-2009 09:33)
+ 		+ + + + +
+ The example has to be corrected. See the attached file CR4944_resolution_part-1.doc. Elena, pls. note, this is not the decision, just my proposal from the analysis
+
+
+
+
+
+ + + + + + + + + + +
+ (0008517) +
+ Elena de Vega    +
+ 20-04-2009 18:17    +
+ 		+ + + + +
+ Hi Gyorgy,
+
+  You have forgoten to attach the file.
+
+Thanks
+
+
+
+ + + + + + + + + + +
+ (0008549) +
+ Gyorgy Rethy    +
+ 22-04-2009 19:36    +
+ 		+ + + + +
+ STF decision: correct the example. See CR4944_resolution_part-1 v2.doc
+
+
+
+ + + + + + + + + + +
+ (0008811) +
+ Ina Schieferdecker    +
+ 01-07-2009 15:39    +
+ 		+ + + + +
+ As proposed except of the optional keyword for field4 which is not needed. See v3.
+
+ + diff --git a/docs/mantis/CR4966.md b/docs/mantis/CR4966.md new file mode 100644 index 0000000000000000000000000000000000000000..dfb6180db3b800e90e3ffbaa3d9d5bf80f7640b7 --- /dev/null +++ b/docs/mantis/CR4966.md @@ -0,0 +1,70 @@ + + + + + + + + + + + + + 0004966: Editorials on Part-1 v4.0.6 - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0004966Part 01: TTCN-3 Core LanguageEditorialpublic12-03-2009 06:4020-04-2009 11:33
ReporterIna Schieferdecker 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)Several
Source (company - Author)     
Summary0004966: Editorials on Part-1 v4.0.6
DescriptionSee attached doc file
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc Readme es_20187301v040006m_Ina.doc (145,408) 12-03-2009 06:40
http://oldforge.etsi.org/mantis/file_download.php?file_id=2029&type=bug
Issue History
Date ModifiedUsernameFieldChange
12-03-2009 06:40Ina SchieferdeckerNew Issue
12-03-2009 06:40Ina SchieferdeckerStatusnew => assigned
12-03-2009 06:40Ina SchieferdeckerAssigned To => Ina Schieferdecker
12-03-2009 06:40Ina SchieferdeckerFile Added: Readme es_20187301v040006m_Ina.doc
12-03-2009 06:40Ina SchieferdeckerClause Reference(s) => Several
12-03-2009 06:40Ina SchieferdeckerSource (company - Author) =>
12-03-2009 06:41Ina SchieferdeckerStatusassigned => resolved
12-03-2009 06:41Ina SchieferdeckerResolutionopen => fixed
12-03-2009 06:41Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
12-03-2009 12:53Ina SchieferdeckerNote Added: 0008269
20-04-2009 11:33Ina SchieferdeckerStatusresolved => closed
20-04-2009 11:33Ina SchieferdeckerFixed in Version => Edition 4.1.1 (not yet published)
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0008269) +
+ Ina Schieferdecker    +
+ 12-03-2009 12:53    +
+ 		+ + + + +
+ Replace in E.1 Limitations
+
+
+    "Names of types added to this library shall be unique within the whole language and within the library (i.e. shall not be one of the names defined in annex C). Names defined in this library shall not be used by TTCN‑3 users as identifiers of other definitions than given in this annex."
+
+with
+
+"Names of types added to this library are to be unique within the whole language and within the library (i.e. are not be one of the names defined in annex C). Names defined in this library are not be used by TTCN‑3 users as identifiers of other definitions than given in this annex."
+
+ + diff --git a/docs/mantis/CR4967.md b/docs/mantis/CR4967.md new file mode 100644 index 0000000000000000000000000000000000000000..b23f83e840fb1c31f4463387d7b5cff625216bcd --- /dev/null +++ b/docs/mantis/CR4967.md @@ -0,0 +1,29 @@ + + + + + + + + + + + + + 0004967: Editorials on Part-6 v4.0.1 - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0004967Part 06: TTCN-3 Control InterfaceEditorialpublic12-03-2009 06:4320-04-2009 11:44
ReporterIna Schieferdecker 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)Several
Source (company - Author)ETSI Editorial Team
Summary0004967: Editorials on Part-6 v4.0.1
DescriptionSee attached doc file
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc ReadMe_es_20187306v040101m_Ina.doc (57,344) 12-03-2009 06:43
http://oldforge.etsi.org/mantis/file_download.php?file_id=2030&type=bug
Issue History
Date ModifiedUsernameFieldChange
12-03-2009 06:43Ina SchieferdeckerNew Issue
12-03-2009 06:43Ina SchieferdeckerStatusnew => assigned
12-03-2009 06:43Ina SchieferdeckerAssigned To => Ina Schieferdecker
12-03-2009 06:43Ina SchieferdeckerFile Added: ReadMe_es_20187306v040101m_Ina.doc
12-03-2009 06:43Ina SchieferdeckerClause Reference(s) => Several
12-03-2009 06:43Ina SchieferdeckerSource (company - Author) => ETSI Editorial Team
12-03-2009 06:45Ina SchieferdeckerStatusassigned => resolved
12-03-2009 06:45Ina SchieferdeckerResolutionopen => fixed
12-03-2009 06:45Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
20-04-2009 11:44Ina SchieferdeckerStatusresolved => closed
20-04-2009 11:44Ina SchieferdeckerFixed in Version => Edition 4.1.1 (not yet published)
+
+ + + + +
+ There are no notes attached to this issue.
+ + diff --git a/docs/mantis/CR4968.md b/docs/mantis/CR4968.md new file mode 100644 index 0000000000000000000000000000000000000000..532e334c0c1f94eee9028d039aaf00a6600647d8 --- /dev/null +++ b/docs/mantis/CR4968.md @@ -0,0 +1,63 @@ + + + + + + + + + + + + + 0004968: Editorials on Part-5 v4.0.1 - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 05: TTCN-3 Runtime Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0004968Part 05: TTCN-3 Runtime Interface Editorialpublic12-03-2009 06:4620-04-2009 11:43
ReporterIna Schieferdecker 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)Several
Source (company - Author)ETSI Editorial Team
Summary0004968: Editorials on Part-5 v4.0.1
DescriptionSee attached doc file
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc ReadMe_es_20187305v040101m_Ina.doc (67,072) 12-03-2009 06:46
http://oldforge.etsi.org/mantis/file_download.php?file_id=2031&type=bug
doc es_20187305v040000_C++Mapping.doc (458,752) 12-03-2009 06:47
http://oldforge.etsi.org/mantis/file_download.php?file_id=2032&type=bug
Issue History
Date ModifiedUsernameFieldChange
12-03-2009 06:46Ina SchieferdeckerNew Issue
12-03-2009 06:46Ina SchieferdeckerStatusnew => assigned
12-03-2009 06:46Ina SchieferdeckerAssigned To => Ina Schieferdecker
12-03-2009 06:46Ina SchieferdeckerFile Added: ReadMe_es_20187305v040101m_Ina.doc
12-03-2009 06:46Ina SchieferdeckerClause Reference(s) => Several
12-03-2009 06:46Ina SchieferdeckerSource (company - Author) => ETSI Editorial Team
12-03-2009 06:47Ina SchieferdeckerFile Added: es_20187305v040000_C++Mapping.doc
12-03-2009 06:48Ina SchieferdeckerNote Added: 0008266
12-03-2009 06:48Ina SchieferdeckerStatusassigned => resolved
12-03-2009 06:48Ina SchieferdeckerResolutionopen => fixed
12-03-2009 06:48Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
20-04-2009 11:43Ina SchieferdeckerStatusresolved => closed
20-04-2009 11:43Ina SchieferdeckerFixed in Version => Edition 4.1.1 (not yet published)
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0008266) +
+ Ina Schieferdecker    +
+ 12-03-2009 06:48    +
+ 		+ + + + +
+ The editorial reformatting of the C++ mapping clause was missing - see uploaded file.
+
+ + diff --git a/docs/mantis/CR4969.md b/docs/mantis/CR4969.md new file mode 100644 index 0000000000000000000000000000000000000000..af3d7c4f2036808e56f506a10682e89d4443b552 --- /dev/null +++ b/docs/mantis/CR4969.md @@ -0,0 +1,63 @@ + + + + + + + + + + + + + 0004969: Editorial comments/questions from Edithelp on Version ES 201 873-4 (V4.1.1) - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 04: TTCN-3 Operational Semantics
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0004969Part 04: TTCN-3 Operational SemanticsEditorialpublic12-03-2009 08:5307-12-2009 14:56
ReporterJens Grabowski 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)All
Source (company - Author)STF
Summary0004969: Editorial comments/questions from Edithelp on Version ES 201 873-4 (V4.1.1)
DescriptionSee attachment
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc ReadMe_es_20187304v040101m.doc (54,272) 12-03-2009 08:53
http://oldforge.etsi.org/mantis/file_download.php?file_id=2033&type=bug
doc Resolution-for-ReadMe_es_20187304v040101m.doc (89,088) 12-03-2009 08:55
http://oldforge.etsi.org/mantis/file_download.php?file_id=2034&type=bug
Issue History
Date ModifiedUsernameFieldChange
12-03-2009 08:53Jens GrabowskiNew Issue
12-03-2009 08:53Jens GrabowskiStatusnew => assigned
12-03-2009 08:53Jens GrabowskiAssigned To => Jens Grabowski
12-03-2009 08:53Jens GrabowskiFile Added: ReadMe_es_20187304v040101m.doc
12-03-2009 08:53Jens GrabowskiClause Reference(s) => All
12-03-2009 08:53Jens GrabowskiSource (company - Author) => STF
12-03-2009 08:55Jens GrabowskiFile Added: Resolution-for-ReadMe_es_20187304v040101m.doc
12-03-2009 08:55Jens GrabowskiNote Added: 0008267
12-03-2009 08:56Jens GrabowskiStatusassigned => closed
12-03-2009 08:56Jens GrabowskiResolutionopen => fixed
07-12-2009 14:56Ina SchieferdeckerFixed in Version => Edition 4.1.1 Published 2009-06-02
07-12-2009 14:56Ina SchieferdeckerTarget Version => Edition 4.1.1 Published 2009-06-02
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0008267) +
+ Jens Grabowski    +
+ 12-03-2009 08:55    +
+ 		+ + + + +
+ Resolution-attachment contains the answers to Edithelp.
+
+ + diff --git a/docs/mantis/CR4970.md b/docs/mantis/CR4970.md new file mode 100644 index 0000000000000000000000000000000000000000..926e4dddbe83693cc71bc3fd8fcb9fb575578abd --- /dev/null +++ b/docs/mantis/CR4970.md @@ -0,0 +1,133 @@ + + + + + + + + + + + + + 0004970: ITU Editorial Issues on Part 6 v3.4.1 - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0004970Part 06: TTCN-3 Control InterfaceEditorialpublic12-03-2009 12:5820-04-2009 11:44
ReporterIna Schieferdecker 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.1.1 (published 2009-06)Fixed in Versionv4.1.1 (published 2009-06) 
Clause Reference(s)Several
Source (company - Author)ITU Editing Team
Summary0004970: ITU Editorial Issues on Part 6 v3.4.1
DescriptionSeveral issues see attached txt file
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filestxt TTCN-3 part 6 ITU-T Recommendation Z.166 (13.11.2007) editorial problems.txt (3,408) 12-03-2009 12:58
http://oldforge.etsi.org/mantis/file_download.php?file_id=2035&type=bug
Issue History
Date ModifiedUsernameFieldChange
12-03-2009 12:58Ina SchieferdeckerNew Issue
12-03-2009 12:58Ina SchieferdeckerStatusnew => assigned
12-03-2009 12:58Ina SchieferdeckerAssigned To => Ina Schieferdecker
12-03-2009 12:58Ina SchieferdeckerFile Added: TTCN-3 part 6 ITU-T Recommendation Z.166 (13.11.2007) editorial problems.txt
12-03-2009 12:58Ina SchieferdeckerClause Reference(s) => Several
12-03-2009 12:58Ina SchieferdeckerSource (company - Author) => ITU Editing Team
12-03-2009 18:53Ina SchieferdeckerNote Added: 0008270
12-03-2009 18:53Ina SchieferdeckerStatusassigned => resolved
12-03-2009 18:53Ina SchieferdeckerResolutionopen => fixed
12-03-2009 18:53Ina SchieferdeckerTarget Version => Edition 4.1.1 (not yet published)
20-04-2009 11:44Ina SchieferdeckerStatusresolved => closed
20-04-2009 11:44Ina SchieferdeckerFixed in Version => Edition 4.1.1 (not yet published)
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0008270) +
+ Ina Schieferdecker    +
+ 12-03-2009 18:53    +
+ 		+ + + + +
+ Still relevant for v4.1.1 are:
+
+> 1) Clause 7.3.4.1.66, there's no definition for the "comp" parameter.
+
+the "comp" parameter is a left over - please remove it:
+
+void tliCDone (in TString am, in TInteger ts, in TString src,
+               in TInteger line, in TriComponentIdType c,
+               in TciNonValueTemplate compTmpl)
+
+> However in clause 7.3.4.1.67, the "comp" parameter is defined but does
+> not appear in the list of the "Signature".
+
+here it is really missing and should be added:
+void tliCKilledMismatch(in TString am, in TInteger ts, in TString src,
+                        in TInteger line, in TriComponentIdType c,
+                        in TriComponentIdType comp,
+                        in TciNonValueTemplate compTmpl)
+
+>
+> 2) Clause 8.2.2, there's a reference to ISO/IEC 10646-1. This standard
+> has been revised in 2003 and renumbered ISO/IEC 10646. Can we update ?
+
+yes, please
+
+>
+> 4) Clause 8.2.4.18, is the following edit correct:
+> // TCI IDL Verdict___Address_Value
+> package org.etsi.ttcn.tci;
+> public interface AddressValue {
+> public int getAddress() ;
+> public void setAddress(Value value) ;
+> }
+>
+
+Yes, it should be:
+
+// TCI IDL AddressValue
+
+
+> 5) Clause 8.3 last paragraph referring to component handling, the
+> constant TCI_ALIVE_COMP is missing?
+>
+
+Yes, please add:
+
+* org.etsi.ttcn.tci.TciTestComponentKind.TCI_ALIVE_COMP;
+
+>
+> 8) Clause 10.3.4.4, no mention of the desc attribute in the mapping of
+> TciValueDifference?
+
+Please correct into
+
+    <xsd:complexType name="TciValueDifference">
+        <xsd:sequence>
+              <xsd:element name="val" type="SimpleTypes:xpath"/>
+              <xsd:element name="tmpl" type="SimpleTypes:xpath"/>
+        </xsd:sequence>
+          <xsd:attributeGroup ref="Values:ValueAtts"/>
+        <xsd:attribute name="desc" type="SimpleTypes:TString"
+use="optional"/>
+    </xsd:complexType>
+
+
+>
+> 10) Bibliography, OMG Corba has been revised in 2004 as
+> version 3. Do we
+> have to update ?
+
+yes, please.
+
+ + diff --git a/docs/mantis/CR5054.md b/docs/mantis/CR5054.md new file mode 100644 index 0000000000000000000000000000000000000000..2ead9dc091ed98e4cb239aa26aee62db2dbbe330 --- /dev/null +++ b/docs/mantis/CR5054.md @@ -0,0 +1,68 @@ + + + + + + + + + + + + + 0005054: assignment of component variable, wrong wording - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005054Part 01: TTCN-3 Core LanguageClarificationpublic07-04-2009 12:0901-07-2009 15:42
ReporterAxel Rennoch 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.4.1 (published 2008-09) 
Target Versionv4.2.1 (published 2010-07)Fixed in Versionv4.2.1 (published 2010-07) 
Clause Reference(s)16.1.4, item (g)
Source (company - Author)     
Summary0005054: assignment of component variable, wrong wording
DescriptionChanging of component variables, i.e. using component variables on the right-hand side of assignments
+
+should be corrected to:
+-----------------------
+
+Changing of component variables, i.e. using component variables on the left-hand side of assignments
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
07-04-2009 12:09Axel RennochNew Issue
07-04-2009 12:09Axel RennochStatusnew => assigned
07-04-2009 12:09Axel RennochAssigned To => Ina Schieferdecker
07-04-2009 12:09Axel RennochClause Reference(s) => 16.1.4, item (g)
07-04-2009 12:09Axel RennochSource (company - Author) =>
20-04-2009 11:47Ina SchieferdeckerTarget Version => Edition 4.2.1 (not yet published)
01-07-2009 15:42Ina SchieferdeckerNote Added: 0008812
01-07-2009 15:42Ina SchieferdeckerResolutionopen => fixed
01-07-2009 15:42Ina SchieferdeckerStatusassigned => resolved
01-07-2009 15:42Ina SchieferdeckerStatusresolved => closed
01-07-2009 15:42Ina SchieferdeckerFixed in Version => Edition 4.2.1 (not yet published)
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0008812) +
+ Ina Schieferdecker    +
+ 01-07-2009 15:42    +
+ 		+ + + + +
+ as proposed
+
+ + diff --git a/docs/mantis/CR5084.md b/docs/mantis/CR5084.md new file mode 100644 index 0000000000000000000000000000000000000000..2ace8a73b2c4ad12f3cc320b78343b56f2a8bdcc --- /dev/null +++ b/docs/mantis/CR5084.md @@ -0,0 +1,363 @@ + + + + + + + + + + + + + 0005084: Use of the __SCOPE__ macro - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005084Part 01: TTCN-3 Core LanguageClarificationpublic16-04-2009 14:1215-07-2009 14:29
ReporterGyorgy Rethy 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.2.1 (published 2010-07)Fixed in Versionv4.2.1 (published 2010-07) 
Clause Reference(s)5.2, D.4
Source (company - Author)     
Summary0005084: Use of the __SCOPE__ macro
DescriptionAs currently defined, the __SCOPE__ TTCN-3 macro shall return the identifyer of the named scope unit it is used in. However, it raises the problem of using the macro in global templates. Global parameterized templates behave like scope units as formal parameter names are local names obeying to scoping rules. But parameterized templates are not defined as scope units today.
+
+As a consequence it is not possible to get the template name with the __SCOPE__ macro. See the example below:
+template myType t_MyTemplate (charstring p_char := __SCOPE__) { f1 := p_char,...}
+
+The module name can be obtained by using __MODULE__, therefore it would be practical if __SCOPE__ returned the name of the template and not the module name.
+
+Proposal: define (at least parameterized) templates as scope units and add templates to $D.4 as
+"...basic scope units of TTCN-3 are module definitions part, module control part, component types, functions, altsteps, test cases, statement blocks and templates. ...
+(g) a template name, if the lowest named scope is a template definition."
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0005268closed Ina Schieferdecker Definition prepocessing macro: __DEFINITION__ 
Attached Filesdoc CR5084_SCOPE_macro.doc (26,624) 22-04-2009 16:06
http://oldforge.etsi.org/mantis/file_download.php?file_id=2112&type=bug
doc CR5084_SCOPE_macro_v2.doc (247,296) 03-07-2009 15:07
http://oldforge.etsi.org/mantis/file_download.php?file_id=2162&type=bug
doc CR5084_SCOPE_macro_v3.doc (260,096) 06-07-2009 12:49
http://oldforge.etsi.org/mantis/file_download.php?file_id=2168&type=bug
ppt CR5084_SCOPE_macro_Figure.ppt (43,520) 08-07-2009 10:00
http://oldforge.etsi.org/mantis/file_download.php?file_id=2182&type=bug
? scope.ttcn3 (1,359) 08-07-2009 17:20
http://oldforge.etsi.org/mantis/file_download.php?file_id=2194&type=bug
? def.ttcn3 (1,371) 08-07-2009 17:21
http://oldforge.etsi.org/mantis/file_download.php?file_id=2195&type=bug
? scope_v2.ttcn3 (1,848) 10-07-2009 12:30
http://oldforge.etsi.org/mantis/file_download.php?file_id=2208&type=bug
doc CR5084_SCOPE_macro_v4.doc (295,936) 10-07-2009 12:36
http://oldforge.etsi.org/mantis/file_download.php?file_id=2209&type=bug
ppt CR5084_SCOPE_macro_Figure_v2.ppt (31,232) 10-07-2009 12:36
http://oldforge.etsi.org/mantis/file_download.php?file_id=2210&type=bug
doc CR5084_SCOPE_macro_v5.doc (298,496) 10-07-2009 14:44
http://oldforge.etsi.org/mantis/file_download.php?file_id=2212&type=bug
Issue History
Date ModifiedUsernameFieldChange
16-04-2009 14:12Gyorgy RethyNew Issue
16-04-2009 14:12Gyorgy RethyClause Reference(s) => 5.2, D.4
16-04-2009 14:12Gyorgy RethySource (company - Author) =>
20-04-2009 11:29Ina SchieferdeckerNote Added: 0008511
20-04-2009 11:30Ina SchieferdeckerProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
20-04-2009 11:30Ina SchieferdeckerAssigned To => Tibor Csöndes
20-04-2009 11:30Ina SchieferdeckerStatusnew => assigned
20-04-2009 11:30Ina SchieferdeckerCategoryTTCN-3 Core Language => Clarification
20-04-2009 11:30Ina SchieferdeckerTarget Version => Edition 4.2.1 (not yet published)
22-04-2009 16:06Tibor CsöndesFile Added: CR5084_SCOPE_macro.doc
22-04-2009 16:09Tibor CsöndesNote Added: 0008543
03-07-2009 15:07Tibor CsöndesFile Added: CR5084_SCOPE_macro_v2.doc
03-07-2009 15:10Tibor CsöndesNote Added: 0008833
03-07-2009 15:10Tibor CsöndesAssigned ToTibor Csöndes => Gyorgy Rethy
06-07-2009 12:49Gyorgy RethyNote Added: 0008841
06-07-2009 12:49Gyorgy RethyFile Added: CR5084_SCOPE_macro_v3.doc
06-07-2009 12:49Gyorgy RethyAssigned ToGyorgy Rethy => Tibor Csöndes
08-07-2009 09:59Tibor CsöndesNote Added: 0008858
08-07-2009 10:00Tibor CsöndesFile Added: CR5084_SCOPE_macro_Figure.ppt
08-07-2009 13:20Tibor CsöndesFile Added: CR5084_SCOPE.ttcn
08-07-2009 13:22Tibor CsöndesNote Added: 0008868
08-07-2009 15:08Ina SchieferdeckerNote Added: 0008874
08-07-2009 15:08Ina SchieferdeckerFile Added: CR5084_scope.ttcn3
08-07-2009 16:46Ina SchieferdeckerFile Deleted: CR5084_scope.ttcn3
08-07-2009 16:48Ina SchieferdeckerFile Added: scope.ttcn3
08-07-2009 17:02Tibor CsöndesRelationship addedrelated to 0005268
08-07-2009 17:13Ina SchieferdeckerFile Deleted: scope.ttcn3
08-07-2009 17:20Tibor CsöndesFile Deleted: CR5084_SCOPE.ttcn
08-07-2009 17:20Tibor CsöndesFile Added: scope.ttcn3
08-07-2009 17:21Tibor CsöndesFile Added: def.ttcn3
08-07-2009 17:21Tibor CsöndesNote Added: 0008877
09-07-2009 09:33Ina SchieferdeckerNote Deleted: 0008868
09-07-2009 09:33Ina SchieferdeckerNote Deleted: 0008874
10-07-2009 12:30Tibor CsöndesNote Added: 0008888
10-07-2009 12:30Tibor CsöndesFile Added: scope_v2.ttcn3
10-07-2009 12:35Tibor CsöndesNote Edited: 0008888
10-07-2009 12:36Tibor CsöndesFile Added: CR5084_SCOPE_macro_v4.doc
10-07-2009 12:36Tibor CsöndesFile Added: CR5084_SCOPE_macro_Figure_v2.ppt
10-07-2009 12:39Tibor CsöndesAssigned ToTibor Csöndes => Gyorgy Rethy
10-07-2009 14:08Gyorgy RethyNote Added: 0008890
10-07-2009 14:09Gyorgy RethyFile Added: CR5084_SCOPE_macro_v5.doc
10-07-2009 14:09Gyorgy RethyAssigned ToGyorgy Rethy => Tibor Csöndes
10-07-2009 14:09Gyorgy RethyResolutionopen => fixed
10-07-2009 14:44Gyorgy RethyFile Deleted: CR5084_SCOPE_macro_v5.doc
10-07-2009 14:44Gyorgy RethyFile Added: CR5084_SCOPE_macro_v5.doc
10-07-2009 14:46Tibor CsöndesNote Added: 0008891
10-07-2009 14:46Tibor CsöndesAssigned ToTibor Csöndes => Ina Schieferdecker
10-07-2009 14:46Tibor CsöndesStatusassigned => resolved
15-07-2009 14:29Ina SchieferdeckerStatusresolved => closed
15-07-2009 14:29Ina SchieferdeckerFixed in Version => Edition 4.2.1 (not yet published)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0008511) +
+ Ina Schieferdecker    +
+ 20-04-2009 11:29    +
+ 		+ + + + +
+ One could also think about types as scope units. All potential scope units need to be checked.
+
+
+
+ + + + + + + + + + +
+ (0008543) +
+ Tibor Csöndes    +
+ 22-04-2009 16:09    +
+ 		+ + + + +
+ Changes uploaded based on the proposal.
+Correct, standalone example:
+template charstring t_MyTemplate (charstring p_char := __SCOPE__) := p_char;
+
+
+
+ + + + + + + + + + +
+ (0008833) +
+ Tibor Csöndes    +
+ 03-07-2009 15:10    +
+ 		+ + + + +
+ Version 2 uploaded. Templates and structured types included as a new scope unit. Figure, "Hierarchy of scope units" redraw, examples included into __SCOPE__ macro section.
+
+
+
+ + + + + + + + + + +
+ (0008841) +
+ Gyorgy Rethy    +
+ 06-07-2009 12:49    +
+ 		+ + + + +
+ I'm at figure 1. Thinking about what to draw below Templates and Types. Template fields may be of structured typed as well but are they scope units? For conssitency they should be (though at this moment I cannot see a practical consequence, except more clarity).
+ 
+A structured type can be defined embedded within other structured types, this shall be drawn on the figure (just an embedded structured type below structured type, embedded structured type below embedded structured type, dashed line.
+
+Textual description of templates and types as scope units is missing from above the figure.
+
+See the rest in CR5084_SCOPE_macro_v3.doc.
+
+I noticed that the figure cannot be edited if embedded this way. This may be a pro or a cons. If we find a good place to store it for next editions, it is a pro. If not, they should be embedded as Powerpoint objects.
+
+
+
+ + + + + + + + + + +
+ (0008858) +
+ Tibor Csöndes    +
+ 08-07-2009 09:59    +
+ 		+ + + + +
+ It is possible to edit the figure because this is an embedded .ppt object: right click on the object -> Presentation Object -> Edit. In addition I have uploaded the original PowerPoint slide.
+
+
+
+ + + + + + + + + + +
+ (0008877) +
+ Tibor Csöndes    +
+ 08-07-2009 17:21    +
+ 		+ + + + +
+ Uploaded scope.ttcn3 and def.ttcn3 are working examples for __SCOPE__ and __DEF__ macro.
+
+
+
+ + + + + + + + + + +
+ (0008888) +
+ Tibor Csöndes    +
+ 10-07-2009 12:30    +
(edited on: 10-07-2009 12:35)
+ 		+ + + + +
+ After our discussion the decision is the following:
+- do not introduce __DEF__ macro only __SCOPE__
+- we will use unqualified names (only "control" and not "modulename.control")
+- new scope units: templates and user-defined types, i.e. basic types like integer, charstring are not scope units, but type restrictions of a basic type shall be a scope unit.
+
+Based on our discussion new examples (scope_v2.ttcn3) created and uploaded.
+New version (CR5084_SCOPE_macro_v4.doc) also uploaded.
+
+
+
+
+
+ + + + + + + + + + +
+ (0008890) +
+ Gyorgy Rethy    +
+ 10-07-2009 14:08    +
+ 		+ + + + +
+ CR5084_SCOPE_macro_v5.doc:
+Note 2 of D.4 deleted, Example 2 is extended to show also a default value of a formal parameter, plus a few editorials. Otherwise OK with me.
+
+
+
+ + + + + + + + + + +
+ (0008891) +
+ Tibor Csöndes    +
+ 10-07-2009 14:46    +
+ 		+ + + + +
+ It's OK with me!
+
+ + diff --git a/docs/mantis/CR5087.md b/docs/mantis/CR5087.md new file mode 100644 index 0000000000000000000000000000000000000000..c885a1a06ce96a220eb90096e62b0db76ecb264e --- /dev/null +++ b/docs/mantis/CR5087.md @@ -0,0 +1,210 @@ + + + + + + + + + + + + + 0005087: __LINE__ macro should return integer - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005087Part 01: TTCN-3 Core LanguageTechnicalpublic16-04-2009 16:0406-07-2009 17:49
ReporterGyorgy Rethy 
Assigned ToIna Schieferdecker 
PriorityurgentSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.2.1 (published 2010-07)Fixed in Versionv4.2.1 (published 2010-07) 
Clause Reference(s)D.3
Source (company - Author)L.M.Ericsson
Summary0005087: __LINE__ macro should return integer
DescriptionThe __LINE__ TTCN-3 macro is currently defined to return the line number as a charstring value. The macros (in general) were requested by 3GPP and the resolution of CR415 has chosen the names of the macros to be in line with the standard syntax and semantics of C/C++ preprocessors. However, in the latter __LINE__ is replaced by an integer value and not with a string value. See for example: http://gcc.gnu.org/onlinedocs/cpp/Standard-Predefined-Macros.html [^]
+
+Thus, currently TTCN-3 defines a semantics for __LINE__ that deviates from other languages.
+
+Proposal: change the return type of the __LINE__ macro to integer in $D.3.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR5087_LINE_macro.doc (24,064) 22-04-2009 14:19
http://oldforge.etsi.org/mantis/file_download.php?file_id=2110&type=bug
doc CR5087_LINE_macro_v2.doc (125,952) 01-07-2009 10:46
http://oldforge.etsi.org/mantis/file_download.php?file_id=2146&type=bug
doc CR5087_LINE_macro_v3.doc (126,976) 03-07-2009 11:40
http://oldforge.etsi.org/mantis/file_download.php?file_id=2158&type=bug
doc CR5087_LINE_macro_v4.doc (129,536) 06-07-2009 17:41
http://oldforge.etsi.org/mantis/file_download.php?file_id=2173&type=bug
Issue History
Date ModifiedUsernameFieldChange
16-04-2009 16:04Gyorgy RethyNew Issue
16-04-2009 16:04Gyorgy RethyClause Reference(s) => D.3
16-04-2009 16:04Gyorgy RethySource (company - Author) => L.M.Ericsson
16-04-2009 16:07Gyorgy RethyDescription Updated
20-04-2009 11:16Ina SchieferdeckerProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
20-04-2009 11:16Ina SchieferdeckerAssigned To => Tibor Csöndes
20-04-2009 11:16Ina SchieferdeckerStatusnew => assigned
20-04-2009 11:16Ina SchieferdeckerTarget Version => Edition 4.2.1 (not yet published)
22-04-2009 14:19Tibor CsöndesFile Added: CR5087_LINE_macro.doc
22-04-2009 14:21Tibor CsöndesNote Added: 0008539
01-07-2009 10:46Tibor CsöndesFile Added: CR5087_LINE_macro_v2.doc
01-07-2009 10:56Tibor CsöndesNote Added: 0008803
01-07-2009 10:58Tibor CsöndesAssigned ToTibor Csöndes => Gyorgy Rethy
03-07-2009 11:40Gyorgy RethyFile Added: CR5087_LINE_macro_v3.doc
03-07-2009 11:48Gyorgy RethyNote Added: 0008827
03-07-2009 12:20Tibor CsöndesNote Added: 0008830
03-07-2009 12:21Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
03-07-2009 12:21Gyorgy RethyStatusassigned => resolved
03-07-2009 12:21Gyorgy RethyResolutionopen => fixed
03-07-2009 12:21Gyorgy RethyFixed in Version => Edition 4.2.1 (not yet published)
06-07-2009 17:41Ina SchieferdeckerFile Added: CR5087_LINE_macro_v4.doc
06-07-2009 17:42Ina SchieferdeckerNote Added: 0008849
06-07-2009 17:49Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0008539) +
+ Tibor Csöndes    +
+ 22-04-2009 14:21    +
+ 		+ + + + +
+ Suggestion for change has been uploaded. We asked tool vendors oppinion, we are waiting for answers.
+
+
+
+ + + + + + + + + + +
+ (0008803) +
+ Tibor Csöndes    +
+ 01-07-2009 10:56    +
+ 		+ + + + +
+ According to the minutes of CR resolution meeting(49TD13r2)new suggestion uploaded.
+
+While v3.4.1 and v4.1.1 has defined __LINE__ macro as a charstring we have to inform tool vendors have already developed __LINE__ macro that their solution also compliant with the standard.
+
+
+
+ + + + + + + + + + +
+ (0008827) +
+ Gyorgy Rethy    +
+ 03-07-2009 11:48    +
+ 		+ + + + +
+ CR5087_LINE_macro_v3.doc:
+Referring to the end-of-line is moved from the note to the main text as it is essential from the point of view of the concrete number returned
+
+
+
+ + + + + + + + + + +
+ (0008830) +
+ Tibor Csöndes    +
+ 03-07-2009 12:20    +
+ 		+ + + + +
+ v3 Ok, with me!
+
+
+
+ + + + + + + + + + +
+ (0008849) +
+ Ina Schieferdecker    +
+ 06-07-2009 17:42    +
+ 		+ + + + +
+ end-of-line changed into newline
+
+first line has number 1
+
+editorial changes
+
+ + diff --git a/docs/mantis/CR5088.md b/docs/mantis/CR5088.md new file mode 100644 index 0000000000000000000000000000000000000000..eb28514d01e1d7bc88042f1c1c388f8744ccc052 --- /dev/null +++ b/docs/mantis/CR5088.md @@ -0,0 +1,186 @@ + + + + + + + + + + + + + 0005088: Clarification: formal parameters are equivalent to local variables - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005088Part 01: TTCN-3 Core LanguageClarificationpublic17-04-2009 11:4806-07-2009 16:56
ReporterWolfgang Seka 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.2.1 (published 2010-07)Fixed in Versionv4.2.1 (published 2010-07) 
Clause Reference(s)???
Source (company - Author)     
Summary0005088: Clarification: formal parameters are equivalent to local variables
DescriptionThere have been compiler problems when out or inout parameters are directly been forwarded to out or inout parameters of another function:
+Instead of
+function f_NasEmu_Decvalue(inout bitstring p_EncodedNasMessage,
+                           out NAS_UL_Message_Type p_NAS_UL_Message) return integer {
+    return decvalue(p_EncodedNasMessage, p_NAS_UL_Message);
+}
+it was necessary to declare variables and assign the parameters:
+    ...
+    var bitstring v_EncodedNasMessage := p_EncodedNasMessage;
+    var NAS_UL_Message_Type v_NAS_UL_Message;
+    var integer v_Result := decvalue(v_EncodedNasMessage, v_NAS_UL_Message);
+    p_EncodedNasMessage := v_EncodedNasMessage;
+    p_NAS_UL_Message := v_NAS_UL_Message;
+    ...
+
+=> There is no explicit statement in the standard to confirm that the short form is allowed
+
+
+
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR5088_FormalParameters.doc (64,512) 22-04-2009 14:14
http://oldforge.etsi.org/mantis/file_download.php?file_id=2109&type=bug
doc CR5088_FormalParameters v2.doc (67,072) 30-06-2009 17:13
http://oldforge.etsi.org/mantis/file_download.php?file_id=2145&type=bug
doc CR5088_FormalParameters_v3.doc (75,264) 03-07-2009 15:21
http://oldforge.etsi.org/mantis/file_download.php?file_id=2163&type=bug
doc CR5088_FormalParameters_v4.doc (78,336) 06-07-2009 13:42
http://oldforge.etsi.org/mantis/file_download.php?file_id=2170&type=bug
Issue History
Date ModifiedUsernameFieldChange
17-04-2009 11:48Wolfgang SekaNew Issue
17-04-2009 11:48Wolfgang SekaClause Reference(s) => ???
17-04-2009 11:48Wolfgang SekaSource (company - Author) =>
20-04-2009 11:13Ina SchieferdeckerProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
20-04-2009 11:14Ina SchieferdeckerAssigned To => Tibor Csöndes
20-04-2009 11:14Ina SchieferdeckerStatusnew => assigned
20-04-2009 11:14Ina SchieferdeckerTarget Version => Edition 4.2.1 (not yet published)
22-04-2009 14:14Tibor CsöndesFile Added: CR5088_FormalParameters.doc
22-04-2009 14:18Tibor CsöndesNote Added: 0008537
22-04-2009 14:41Tibor CsöndesAssigned ToTibor Csöndes => Gyorgy Rethy
30-06-2009 17:13Gyorgy RethyNote Added: 0008801
30-06-2009 17:13Gyorgy RethyFile Added: CR5088_FormalParameters v2.doc
30-06-2009 17:13Gyorgy RethyNote Edited: 0008801
30-06-2009 17:14Gyorgy RethyAssigned ToGyorgy Rethy => Tibor Csöndes
03-07-2009 15:21Tibor CsöndesFile Added: CR5088_FormalParameters_v3.doc
03-07-2009 15:22Tibor CsöndesNote Added: 0008835
03-07-2009 15:23Tibor CsöndesAssigned ToTibor Csöndes => Ina Schieferdecker
06-07-2009 13:41Ina SchieferdeckerNote Added: 0008844
06-07-2009 13:42Ina SchieferdeckerFile Added: CR5088_FormalParameters_v4.doc
06-07-2009 13:42Ina SchieferdeckerAssigned ToIna Schieferdecker => Tibor Csöndes
06-07-2009 15:40Tibor CsöndesAssigned ToTibor Csöndes => Ina Schieferdecker
06-07-2009 16:55Ina SchieferdeckerResolutionopen => fixed
06-07-2009 16:55Ina SchieferdeckerStatusassigned => resolved
06-07-2009 16:55Ina SchieferdeckerFixed in Version => Edition 4.2.1 (not yet published)
06-07-2009 16:56Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0008537) +
+ Tibor Csöndes    +
+ 22-04-2009 14:18    +
+ 		+ + + + +
+ As a clarification example included (5.4.1.1.Example 4).
+
+
+
+ + + + + + + + + + +
+ (0008801) +
+ Gyorgy Rethy    +
+ 30-06-2009 17:13    +
+ 		+ + + + +
+ Some editorial corrections + a question regarding the proposed new restrictions. See CR5088_FormalParameters v2.doc
+
+
+
+
+
+ + + + + + + + + + +
+ (0008835) +
+ Tibor Csöndes    +
+ 03-07-2009 15:22    +
+ 		+ + + + +
+ New, v3 uploaded. Comment in v2 is accepted therefore there is no changes in 5.4.1.2.
+
+
+
+ + + + + + + + + + +
+ (0008844) +
+ Ina Schieferdecker    +
+ 06-07-2009 13:41    +
+ 		+ + + + +
+ Some additional explaination and extension of the example - please check.
+
+ + diff --git a/docs/mantis/CR5089.md b/docs/mantis/CR5089.md new file mode 100644 index 0000000000000000000000000000000000000000..2e0ab30ffe762077a1a4da7310ecfc6d0ec36a6a --- /dev/null +++ b/docs/mantis/CR5089.md @@ -0,0 +1,481 @@ + + + + + + + + + + + + + 0005089: Include files (pre-compiler feature) - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005089Part 01: TTCN-3 Core LanguageNew Featurepublic17-04-2009 11:5517-07-2009 06:55
ReporterWolfgang Seka 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.2.1 (published 2010-07)Fixed in Versionv4.2.1 (published 2010-07) 
Clause Reference(s)???
Source (company - Author)     
Summary0005089: Include files (pre-compiler feature)
DescriptionCurrently there is no include mechanism in TTCN-3 (like e.g. in C).
+This can be helpful e.g. to deal with detailed import lists.
+(e.g. to specify a module's interface as import list)
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0005090closed Ina Schieferdecker Precompiler functionality: if or ifdef 
Attached Filespdf CR5089.pdf (85,240) 03-06-2009 16:35
http://oldforge.etsi.org/mantis/file_download.php?file_id=2132&type=bug
ppt Transitive Import.ppt (26,624) 03-07-2009 12:23
http://oldforge.etsi.org/mantis/file_download.php?file_id=2160&type=bug
doc CR5089_resolution_v1.doc (190,976) 06-07-2009 15:25
http://oldforge.etsi.org/mantis/file_download.php?file_id=2171&type=bug
doc CR5089_resolution_Part-1_v2.doc (247,808) 07-07-2009 15:58
http://oldforge.etsi.org/mantis/file_download.php?file_id=2179&type=bug
doc CR5089_resolution_Part-7_v1.doc (575,488) 07-07-2009 17:47
http://oldforge.etsi.org/mantis/file_download.php?file_id=2181&type=bug
doc CR5089_resolution_Part-1_v3.doc (265,216) 08-07-2009 11:07
http://oldforge.etsi.org/mantis/file_download.php?file_id=2185&type=bug
doc CR5089_resolution_Part-7_v2.doc (580,096) 08-07-2009 12:02
http://oldforge.etsi.org/mantis/file_download.php?file_id=2187&type=bug
doc CR5089_resolution_Part-7_v3.doc (139,264) 08-07-2009 14:13
http://oldforge.etsi.org/mantis/file_download.php?file_id=2189&type=bug
doc CR5089_resolution_Part-1_v4.doc (267,776) 09-07-2009 11:52
http://oldforge.etsi.org/mantis/file_download.php?file_id=2201&type=bug
ppt CR5089_ImportingRelations_v2.ppt (97,792) 10-07-2009 12:18
http://oldforge.etsi.org/mantis/file_download.php?file_id=2207&type=bug
doc CR5089_resolution_Part-1_v5.doc (269,312) 15-07-2009 14:50
http://oldforge.etsi.org/mantis/file_download.php?file_id=2215&type=bug
doc CR5089_resolution_Part-1_v6.doc (271,360) 17-07-2009 06:54
http://oldforge.etsi.org/mantis/file_download.php?file_id=2216&type=bug
Issue History
Date ModifiedUsernameFieldChange
17-04-2009 11:55Wolfgang SekaNew Issue
17-04-2009 11:55Wolfgang SekaClause Reference(s) => ???
17-04-2009 11:55Wolfgang SekaSource (company - Author) =>
20-04-2009 11:08Ina SchieferdeckerProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
20-04-2009 11:09Ina SchieferdeckerRelationship addedrelated to 0005090
20-04-2009 11:09Ina SchieferdeckerAssigned To => Ina Schieferdecker
20-04-2009 11:09Ina SchieferdeckerStatusnew => assigned
20-04-2009 11:09Ina SchieferdeckerTarget Version => Edition 4.2.1 (not yet published)
21-04-2009 16:58Ina SchieferdeckerNote Added: 0008529
03-06-2009 16:35Valentin ZaharescuFile Added: CR5089.pdf
03-07-2009 12:23Ina SchieferdeckerNote Added: 0008831
03-07-2009 12:23Ina SchieferdeckerFile Added: Transitive Import.ppt
06-07-2009 15:25Ina SchieferdeckerFile Added: CR5089_resolution_v1.doc
06-07-2009 15:25Ina SchieferdeckerNote Added: 0008845
06-07-2009 15:25Ina SchieferdeckerAssigned ToIna Schieferdecker => Gyorgy Rethy
07-07-2009 15:57Gyorgy RethyFile Added: CR5089_resolution_v2.doc
07-07-2009 15:57Gyorgy RethyFile Deleted: CR5089_resolution_v2.doc
07-07-2009 15:58Gyorgy RethyFile Added: CR5089_resolution_Part-1_v2.doc
07-07-2009 16:03Gyorgy RethyNote Added: 0008855
07-07-2009 17:47Gyorgy RethyFile Added: CR5089_resolution_Part-7_v1.doc
07-07-2009 17:56Gyorgy RethyNote Added: 0008857
08-07-2009 10:50Ina SchieferdeckerNote Added: 0008862
08-07-2009 11:07Ina SchieferdeckerFile Added: CR5089_resolution_Part-1_v3.doc
08-07-2009 12:02Ina SchieferdeckerNote Added: 0008867
08-07-2009 12:02Ina SchieferdeckerFile Added: CR5089_resolution_Part-7_v2.doc
08-07-2009 14:12Gyorgy RethyNote Added: 0008869
08-07-2009 14:13Gyorgy RethyFile Added: CR5089_resolution_Part-7_v3.doc
09-07-2009 11:51Ina SchieferdeckerNote Added: 0008882
09-07-2009 11:52Ina SchieferdeckerNote Edited: 0008882
09-07-2009 11:52Ina SchieferdeckerFile Added: CR5089_resolution_Part-1_v4.doc
10-07-2009 12:18Ina SchieferdeckerFile Added: CR5089_ImportingRelations_v2.ppt
10-07-2009 12:19Ina SchieferdeckerNote Added: 0008887
10-07-2009 12:45Gyorgy RethyNote Added: 0008889
15-07-2009 14:50Ina SchieferdeckerFile Added: CR5089_resolution_Part-1_v5.doc
15-07-2009 14:51Ina SchieferdeckerNote Added: 0008896
17-07-2009 06:54Ina SchieferdeckerNote Added: 0008897
17-07-2009 06:54Ina SchieferdeckerFile Added: CR5089_resolution_Part-1_v6.doc
17-07-2009 06:55Ina SchieferdeckerNote Edited: 0008897
17-07-2009 06:55Ina SchieferdeckerResolutionopen => fixed
17-07-2009 06:55Ina SchieferdeckerStatusassigned => resolved
17-07-2009 06:55Ina SchieferdeckerFixed in Version => Edition 4.2.1 (not yet published)
17-07-2009 06:55Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0008529) +
+ Ina Schieferdecker    +
+ 21-04-2009 16:58    +
+ 		+ + + + +
+ It should be investigated if transitive import could resolve the issue as well.
+
+
+
+ + + + + + + + + + +
+ (0008831) +
+ Ina Schieferdecker    +
+ 03-07-2009 12:23    +
+ 		+ + + + +
+ Example uploaded - please check.
+
+
+
+ + + + + + + + + + +
+ (0008845) +
+ Ina Schieferdecker    +
+ 06-07-2009 15:25    +
+ 		+ + + + +
+ Please check.
+
+
+
+ + + + + + + + + + +
+ (0008855) +
+ Gyorgy Rethy    +
+ 07-07-2009 16:03    +
+ 		+ + + + +
+ CR5089_resolution_Part-1_v2.doc:
+For changes see the file; amendments to other clauses (importing individual defs., kinds, groups) were also needed. Also, changes in Part-7 will be needed as ASN.1 exports all by default. Part-8 and Part-9 may also be effected, this still needs to be checked.
+
+
+
+ + + + + + + + + + +
+ (0008857) +
+ Gyorgy Rethy    +
+ 07-07-2009 17:56    +
+ 		+ + + + +
+ CR5089_resolution_Part-7_v1.doc:
+First draft of the part-7 resolution: transitive import os forbidden when importing from ASN.1; this is because otherwise we would need to define specific importing rules for each language supported by TTCN-3. It is better to import everything used in TTCN-3, first from the other languages to TTCN-3, and next use the TTCN-3 transitive import, if needed.
+
+
+
+ + + + + + + + + + +
+ (0008862) +
+ Ina Schieferdecker    +
+ 08-07-2009 10:50    +
+ 		+ + + + +
+ One more review: notes in table on importing definitions, addition of language spec compatibility, description of visibility of import statements, some editorial things
+
+
+
+ + + + + + + + + + +
+ (0008867) +
+ Ina Schieferdecker    +
+ 08-07-2009 12:02    +
+ 		+ + + + +
+ ASN.1 draft checked: it is confusing to explain ASN.1 visibility of definitions with TTCN-3 visibility defined in 8.2.5 - hence, reworded.
+
+
+
+ + + + + + + + + + +
+ (0008869) +
+ Gyorgy Rethy    +
+ 08-07-2009 14:12    +
+ 		+ + + + +
+ CR5089_resolution_Part-7_v3.doc:
+Superflouos parts of the file are removed: all changes are in clause 8.1bis.
+Title of 8.1bis.4 is edited. Otherwise the Part-7 stuff is OK with me.
+
+
+
+ + + + + + + + + + +
+ (0008882) +
+ Ina Schieferdecker    +
+ 09-07-2009 11:51    +
(edited on: 09-07-2009 11:52)
+ 		+ + + + +
+ added the case that the source module has no language specification - please check restriction h in 8.2.3.1 in resolution v4 for part 1
+
+
+
+
+
+ + + + + + + + + + +
+ (0008887) +
+ Ina Schieferdecker    +
+ 10-07-2009 12:19    +
+ 		+ + + + +
+ CR5089_ImportingRelations_v2.ppt discuss the various cases of direct and transitive import, which need to be reflected in the text. Just the import from non-TTCN-3 is already described and requires no change in part 1.
+
+
+
+ + + + + + + + + + +
+ (0008889) +
+ Gyorgy Rethy    +
+ 10-07-2009 12:45    +
+ 		+ + + + +
+ Result of the discussion on CR5089_ImportingRelations_v2.ppt: cases are agreed as proposed but one exception: all language spec. string not present cases shall be handled by tools, no error shall be caused due to not present language spec.
+
+
+
+ + + + + + + + + + +
+ (0008896) +
+ Ina Schieferdecker    +
+ 15-07-2009 14:51    +
+ 		+ + + + +
+ Defined the rules according to the principles given in CR5089_ImportingRelations_v2.ppt
+
+
+
+ + + + + + + + + + +
+ (0008897) +
+ Ina Schieferdecker    +
+ 17-07-2009 06:54    +
(edited on: 17-07-2009 06:55)
+ 		+ + + + +
+ Editorial changes in CR5089_resolution_Part-1_v6.doc
+
+
+
+ + diff --git a/docs/mantis/CR5090.md b/docs/mantis/CR5090.md new file mode 100644 index 0000000000000000000000000000000000000000..1f6d47b1fb677a27e3c6bff9913821e8d8fa2c51 --- /dev/null +++ b/docs/mantis/CR5090.md @@ -0,0 +1,65 @@ + + + + + + + + + + + + + 0005090: Precompiler functionality: if or ifdef - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005090Part 01: TTCN-3 Core LanguageNew Featurepublic17-04-2009 11:5922-04-2009 18:22
ReporterWolfgang Seka 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionwon't fix 
PlatformOSOS Version
Product Version 
Target Versionv4.2.1 (published 2010-07)Fixed in Version 
Clause Reference(s)???
Source (company - Author)     
Summary0005090: Precompiler functionality: if or ifdef
DescriptionWith a precompiler functionality like "#if" or "#ifdef" as well-know from C conditional compilation can be achieved.
+That is helpful e.g. in case of tool incompatibilities
+(actual example: handling of __LINE__9
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0005089closed Gyorgy Rethy Include files (pre-compiler feature) 
Attached Filesppt PreprocessorDirectives_CR5089_5090.ppt (50,688) 21-04-2009 18:20
http://oldforge.etsi.org/mantis/file_download.php?file_id=2102&type=bug
Issue History
Date ModifiedUsernameFieldChange
17-04-2009 11:59Wolfgang SekaNew Issue
17-04-2009 11:59Wolfgang SekaClause Reference(s) => ???
17-04-2009 11:59Wolfgang SekaSource (company - Author) =>
20-04-2009 10:55Ina SchieferdeckerProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
20-04-2009 11:06Ina SchieferdeckerAssigned To => Ina Schieferdecker
20-04-2009 11:06Ina SchieferdeckerStatusnew => assigned
20-04-2009 11:06Ina SchieferdeckerTarget Version => Edition 4.2.1 (not yet published)
20-04-2009 11:09Ina SchieferdeckerRelationship addedrelated to 0005089
21-04-2009 18:20Ina SchieferdeckerFile Added: PreprocessorDirectives_CR5089_5090.ppt
22-04-2009 18:22Ina SchieferdeckerNote Added: 0008547
22-04-2009 18:22Ina SchieferdeckerStatusassigned => closed
22-04-2009 18:22Ina SchieferdeckerResolutionopen => won't fix
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0008547) +
+ Ina Schieferdecker    +
+ 22-04-2009 18:22    +
+ 		+ + + + +
+ Along further discussions also with vendors, preprocessor directives will not be added to TTCN-3. They hinder clean test specifications.
+
+ + diff --git a/docs/mantis/CR5091.md b/docs/mantis/CR5091.md new file mode 100644 index 0000000000000000000000000000000000000000..b0956ae75368a98f7820640020ac415be5308876 --- /dev/null +++ b/docs/mantis/CR5091.md @@ -0,0 +1,153 @@ + + + + + + + + + + + + + 0005091: How to handle modified template parameters with (no) default value - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005091Part 01: TTCN-3 Core LanguageTechnicalpublic17-04-2009 14:3009-07-2009 11:08
ReporterGyorgy Rethy 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.2.1 (published 2010-07)Fixed in Versionv4.2.1 (published 2010-07) 
Clause Reference(s)15.5
Source (company - Author)L.M.Ericsson
Summary0005091: How to handle modified template parameters with (no) default value
DescriptionSee the example below:
+template MyType x ( integer p1, integer p2 := 20 ) := {
+        f1 := p1,
+        f2 := p2,
+        f3 := omit,
+        f4 := 40
+}
+
+template MyData y ( integer p1, integer p2 ) modifies x :=
+{
+        f3 := 30
+}
+
+In the modified template y the default value of p2, present in the parent template, is left out. According to the current text this is not forbidden:
+$15.5 Restrictions item b):
+"1) the derived template shall not omit parameters defined at any of the modification steps between the base template and the actual modified template;"
+
+But this raises the question: is p2 of y mandatory in this case or does it inherit the default value from p2 of x?
+
+Proposal: though there are arguments for both alternatives, it is proposed that default values of formal parameters have effect on the very parameter only it is applied to (i.e. not inherited by modified templates). This is more straighforward both for the users and the tools, prevents error situations and/or exception cases (e.g. different default values applied at the different steps of modification) and more flexible for the users. Whatever is the decision, it shall explicitly be stated in the standard.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR5091_resolution v1.doc (211,968) 06-07-2009 17:54
http://oldforge.etsi.org/mantis/file_download.php?file_id=2174&type=bug
doc CR5091_resolution v2.doc (215,552) 07-07-2009 12:17
http://oldforge.etsi.org/mantis/file_download.php?file_id=2177&type=bug
Issue History
Date ModifiedUsernameFieldChange
17-04-2009 14:30Gyorgy RethyNew Issue
17-04-2009 14:30Gyorgy RethyClause Reference(s) => 15.5
17-04-2009 14:30Gyorgy RethySource (company - Author) => L.M.Ericsson
20-04-2009 11:07Ina SchieferdeckerProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
20-04-2009 11:07Ina SchieferdeckerAssigned To => Ina Schieferdecker
20-04-2009 11:07Ina SchieferdeckerStatusnew => assigned
20-04-2009 11:07Ina SchieferdeckerTarget Version => Edition 4.2.1 (not yet published)
06-07-2009 13:45Ina SchieferdeckerAssigned ToIna Schieferdecker => Gyorgy Rethy
06-07-2009 17:54Gyorgy RethyFile Added: CR5091_resolution v1.doc
06-07-2009 17:55Gyorgy RethyNote Added: 0008850
06-07-2009 17:55Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
07-07-2009 12:16Ina SchieferdeckerNote Added: 0008854
07-07-2009 12:17Ina SchieferdeckerFile Added: CR5091_resolution v2.doc
07-07-2009 12:17Ina SchieferdeckerAssigned ToIna Schieferdecker => Gyorgy Rethy
08-07-2009 10:30Gyorgy RethyNote Added: 0008859
08-07-2009 10:30Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
08-07-2009 10:30Gyorgy RethyStatusassigned => resolved
08-07-2009 10:30Gyorgy RethyResolutionopen => fixed
08-07-2009 10:31Gyorgy RethyNote Added: 0008860
08-07-2009 10:38Gyorgy RethyNote Added: 0008861
09-07-2009 10:45Ina SchieferdeckerNote Deleted: 0008859
09-07-2009 10:45Ina SchieferdeckerNote Deleted: 0008861
09-07-2009 11:08Ina SchieferdeckerStatusresolved => closed
09-07-2009 11:08Ina SchieferdeckerFixed in Version => Edition 4.2.1 (not yet published)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0008850) +
+ Gyorgy Rethy    +
+ 06-07-2009 17:55    +
+ 		+ + + + +
+ CR5091_resolution v1.doc:
+First resolution draft.
+
+
+
+ + + + + + + + + + +
+ (0008854) +
+ Ina Schieferdecker    +
+ 07-07-2009 12:16    +
+ 		+ + + + +
+ made explicit that an error is caused whenever dash is used for a parameter without default
+
+and some editorial changes
+
+
+
+ + + + + + + + + + +
+ (0008860) +
+ Gyorgy Rethy    +
+ 08-07-2009 10:31    +
+ 		+ + + + +
+ Changes in text of CR5091_resolution v2.doc are checked, all OK.
+
+ + diff --git a/docs/mantis/CR5092.md b/docs/mantis/CR5092.md new file mode 100644 index 0000000000000000000000000000000000000000..491d138029edf1b158dead7762bf0d6744069c73 --- /dev/null +++ b/docs/mantis/CR5092.md @@ -0,0 +1,187 @@ + + + + + + + + + + + + + 0005092: String concatination is not possible for string templates - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005092Part 01: TTCN-3 Core LanguageClarificationpublic17-04-2009 16:1213-04-2010 13:18
ReporterWolfgang Seka 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionreopened 
PlatformOSOS Version
Product Version 
Target Versionv4.2.1 (published 2010-07)Fixed in Versionv4.2.1 (published 2010-07) 
Clause Reference(s)7.1.2
Source (company - Author)     
Summary0005092: String concatination is not possible for string templates
DescriptionString concatination is define in clause 7.1.2 "... concatenation of values of compatible string types ...";
+=> it is not possible to construct templates for strings by concatenating string templates.
+Example:
+// we expect an octetstring being received and the first N octets are out of interrest then there is a part to be checked and the rest is "don't care".
+
+var integer N := 8;
+var template octetstring v_Octetstring;
+var template octetstring v_LeadingOctets := ? length(N);
+var octetstring v_ExpectetPattern := "01234567"O
+
+v_Octetstring := v_LeadingOctets & v_ExpectetPattern & '*'O; // this is not allowed
+
+
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0005513closed Ina Schieferdecker resolution of CR5092 contains bogus examples for charstring 
Attached Filesdoc CR5092_resolution_v1.doc (174,080) 04-09-2009 09:38
http://oldforge.etsi.org/mantis/file_download.php?file_id=2237&type=bug
doc CR5092_resolution_v2.doc (172,032) 09-12-2009 15:13
http://oldforge.etsi.org/mantis/file_download.php?file_id=2309&type=bug
Issue History
Date ModifiedUsernameFieldChange
17-04-2009 16:12Wolfgang SekaNew Issue
17-04-2009 16:12Wolfgang SekaClause Reference(s) => 7.1.2
17-04-2009 16:12Wolfgang SekaSource (company - Author) =>
20-04-2009 10:51Ina SchieferdeckerProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
20-04-2009 10:54Ina SchieferdeckerAssigned To => Gyorgy Rethy
20-04-2009 10:54Ina SchieferdeckerStatusnew => assigned
20-04-2009 10:54Ina SchieferdeckerCategoryTTCN-3 Core Language => Clarification
20-04-2009 10:54Ina SchieferdeckerTarget Version => Edition 4.2.1 (not yet published)
03-09-2009 18:53Gyorgy RethyFile Added: CR5092_resolution_v1.doc
04-09-2009 09:38Gyorgy RethyFile Deleted: CR5092_resolution_v1.doc
04-09-2009 09:38Gyorgy RethyFile Added: CR5092_resolution_v1.doc
04-09-2009 09:39Gyorgy RethyNote Added: 0008977
04-09-2009 09:40Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
04-09-2009 09:40Gyorgy RethyResolutionopen => fixed
04-09-2009 09:40Gyorgy RethyFixed in Version => Edition 4.2.1 (not yet published)
09-12-2009 15:12Ina SchieferdeckerNote Added: 0009123
09-12-2009 15:13Ina SchieferdeckerFile Added: CR5092_resolution_v2.doc
09-12-2009 15:13Ina SchieferdeckerAssigned ToIna Schieferdecker => Gyorgy Rethy
16-02-2010 07:38Ina SchieferdeckerStatusassigned => resolved
16-02-2010 07:39Ina SchieferdeckerStatusresolved => closed
13-04-2010 12:42Jacob Wieland - SpirentStatusclosed => feedback
13-04-2010 12:42Jacob Wieland - SpirentResolutionfixed => reopened
13-04-2010 12:42Jacob Wieland - SpirentNote Added: 0009328
13-04-2010 13:18Gyorgy RethyNote Added: 0009329
13-04-2010 13:18Gyorgy RethyStatusfeedback => closed
14-04-2010 15:26Jacob Wieland - SpirentRelationship addedrelated to 0005513
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0008977) +
+ Gyorgy Rethy    +
+ 04-09-2009 09:39    +
+ 		+ + + + +
+ CR5092_resolution_v1.doc: draft for resolution; ready for review.
+
+
+
+ + + + + + + + + + +
+ (0009123) +
+ Ina Schieferdecker    +
+ 09-12-2009 15:12    +
+ 		+ + + + +
+ Only some rewording - please check v2
+
+
+
+ + + + + + + + + + +
+ (0009328) +
+ Jacob Wieland - Spirent    +
+ 13-04-2010 12:42    +
+ 		+ + + + +
+ In the examples for the resolution, the 'pattern' is missing for all char templates. Since pattern "a?b" has a different semantics than "a?b", I think this should be fixed.
+
+The question then is, has pattern a higher priority or has & the higher priority, I.e. do I have to write
+
+        pattern E1 & E1
+
+or
+        pattern E1 & pattern E1
+
+if E1 and E2 are two charstring literals which contain pattern matching symbols
+
+
+
+ + + + + + + + + + +
+ (0009329) +
+ Gyorgy Rethy    +
+ 13-04-2010 13:18    +
+ 		+ + + + +
+ Closed CRs should be re-opened by the submiter only. This CR is not about patterns, concatenation of patterns have solved earlier, in CR3761. This CR is about concatenating templates when its content is non-pattern.
+
+ + diff --git a/docs/mantis/CR5093.md b/docs/mantis/CR5093.md new file mode 100644 index 0000000000000000000000000000000000000000..2c10ed47687b4a93ef2013c09ad41f3711400434 --- /dev/null +++ b/docs/mantis/CR5093.md @@ -0,0 +1,239 @@ + + + + + + + + + + + + + 0005093: __FILE__ macro - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005093Part 01: TTCN-3 Core LanguageClarificationpublic20-04-2009 11:1806-07-2009 17:27
ReporterIna Schieferdecker 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.2.1 (published 2010-07)Fixed in Versionv4.2.1 (published 2010-07) 
Clause Reference(s)D.2
Source (company - Author)Hellen Griffiths, 3GPP
Summary0005093: __FILE__ macro
DescriptionI have (hopefully) a small request. The __FILE__ macro is currently defined to specify the filename in which the macro is used.
+ 
+But since we already have a large number of files, and intend to have a lot more, we've already created a number of directories to organise these files.
+ 
+Therefore would it be possible to extend the __FILE__ definition to provide the path, as well as the filename?
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR5093_FILE_macro.doc (30,208) 22-04-2009 13:59
http://oldforge.etsi.org/mantis/file_download.php?file_id=2107&type=bug
doc CR5093_FILE_macro_v2.doc (135,680) 03-07-2009 17:28
http://oldforge.etsi.org/mantis/file_download.php?file_id=2165&type=bug
doc CR5093_FILE_macro_v3.doc (136,192) 03-07-2009 17:46
http://oldforge.etsi.org/mantis/file_download.php?file_id=2166&type=bug
doc CR5093_FILE_macro_v4.doc (139,264) 06-07-2009 17:26
http://oldforge.etsi.org/mantis/file_download.php?file_id=2172&type=bug
Issue History
Date ModifiedUsernameFieldChange
20-04-2009 11:18Ina SchieferdeckerNew Issue
20-04-2009 11:18Ina SchieferdeckerStatusnew => assigned
20-04-2009 11:18Ina SchieferdeckerAssigned To => Tibor Csöndes
20-04-2009 11:18Ina SchieferdeckerClause Reference(s) => D.2
20-04-2009 11:18Ina SchieferdeckerSource (company - Author) => Hellen Griffiths, 3GPP
20-04-2009 11:19Ina SchieferdeckerProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
20-04-2009 11:19Ina SchieferdeckerCategoryTTCN-3 Core Language => Clarification
20-04-2009 11:19Ina SchieferdeckerTarget Version => Edition 4.2.1 (not yet published)
22-04-2009 13:59Tibor CsöndesFile Added: CR5093_FILE_macro.doc
22-04-2009 14:08Tibor CsöndesNote Added: 0008536
22-04-2009 14:40Tibor CsöndesAssigned ToTibor Csöndes => Gyorgy Rethy
14-05-2009 10:17Jacob Wieland - SpirentNote Added: 0008599
30-06-2009 15:56Gyorgy RethyAssigned ToGyorgy Rethy => Tibor Csöndes
30-06-2009 15:57Gyorgy RethyNote Added: 0008800
03-07-2009 17:10Tibor CsöndesFile Added: CR5093_FILE_macro_v2.doc
03-07-2009 17:14Tibor CsöndesNote Added: 0008837
03-07-2009 17:15Tibor CsöndesAssigned ToTibor Csöndes => Gyorgy Rethy
03-07-2009 17:22Tibor CsöndesFile Deleted: CR5093_FILE_macro_v2.doc
03-07-2009 17:28Tibor CsöndesFile Added: CR5093_FILE_macro_v2.doc
03-07-2009 17:46Gyorgy RethyFile Added: CR5093_FILE_macro_v3.doc
03-07-2009 17:47Gyorgy RethyNote Added: 0008839
03-07-2009 17:47Gyorgy RethyStatusassigned => resolved
03-07-2009 17:47Gyorgy RethyResolutionopen => fixed
06-07-2009 17:26Ina SchieferdeckerFile Added: CR5093_FILE_macro_v4.doc
06-07-2009 17:26Ina SchieferdeckerNote Added: 0008848
06-07-2009 17:27Ina SchieferdeckerStatusresolved => assigned
06-07-2009 17:27Ina SchieferdeckerAssigned ToGyorgy Rethy => Ina Schieferdecker
06-07-2009 17:27Ina SchieferdeckerStatusassigned => closed
06-07-2009 17:27Ina SchieferdeckerFixed in Version => Edition 4.2.1 (not yet published)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0008536) +
+ Tibor Csöndes    +
+ 22-04-2009 14:08    +
+ 		+ + + + +
+ New preprocessing __PATH__ macro introduced into D.5 which will give the full path of the directory where the file is located. Concatenation of __PATH_ and __FILE__ will give back the full path with filename.
+
+
+
+ + + + + + + + + + +
+ (0008599) +
+ Jacob Wieland - Spirent    +
+ 14-05-2009 10:17    +
+ 		+ + + + +
+ I think the standard is ambiguous here, it should state that __FILE__ already evaluates to the canonical full file path of the file, not just the base file name. This would be the same as a preprocessor evaluates __FILE__ and would of course solve the problem this CR is aimed at.
+
+
+
+ + + + + + + + + + +
+ (0008800) +
+ Gyorgy Rethy    +
+ 30-06-2009 15:57    +
+ 		+ + + + +
+ CR Resolution mtg has changed the STF proposal, draft to be aligned with the meeting decision
+
+
+
+ + + + + + + + + + +
+ (0008837) +
+ Tibor Csöndes    +
+ 03-07-2009 17:14    +
+ 		+ + + + +
+ Based on the decision from CR resolution meeting new version has been uploaded. In v2 __FILE__ macro contains the absolute path and a new __BFILE__ macro has been introduced for basic file names (without path).
+
+
+
+ + + + + + + + + + +
+ (0008839) +
+ Gyorgy Rethy    +
+ 03-07-2009 17:47    +
+ 		+ + + + +
+ CR5093_FILE_macro_v3.doc:
+minor editorial changes. Otherwise OK with me.
+
+
+
+ + + + + + + + + + +
+ (0008848) +
+ Ina Schieferdecker    +
+ 06-07-2009 17:26    +
+ 		+ + + + +
+ editorial changes only
+
+ + diff --git a/docs/mantis/CR5103.md b/docs/mantis/CR5103.md new file mode 100644 index 0000000000000000000000000000000000000000..4db1f1502f4ddc9baec16a618fbcc4498f9f1384 --- /dev/null +++ b/docs/mantis/CR5103.md @@ -0,0 +1,207 @@ + + + + + + + + + + + + + 0005103: Handling of nested types/values unclear in TCI type and value interface - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005103Part 06: TTCN-3 Control InterfaceClarificationpublic21-04-2009 12:3830-12-2010 17:11
ReporterStephan Schulz 
Assigned ToIna Schieferdecker 
PrioritylowSeveritymajorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.4.1 (published 2008-09) 
Target Versionv4.3.1 (published 2011-06)Fixed in Versionv4.3.1 (published 2011-06) 
Clause Reference(s)7.2.2
Source (company - Author)STF 370 - Stephan Schulz
Summary0005103: Handling of nested types/values unclear in TCI type and value interface
DescriptionFor the given type definition:
+
+      type record PEarlyMedia {
+          FieldName fieldName(P_EARLY_MEDIA_E),
+          record of charstring em_param
+      }
+
+We wonder how it is possible to query the type of the second field or similarly how to instantiate values of the second field.
+Currently section 7.2.2 has no explcit hints how to deal with nested types/values.
Steps To Reproduce
Additional InformationCore langaugae states for example:
+
+6.2.1.3 Nested type definitions for field types
+TTCN-3 supports the definition of types for record fields nested within the record definition. Both the definition of
+new structured types (record, set, enumerated, set of, record of, and union) and the specification of
+subtype constraints are possible.
TagsNo tags attached.
Relationships
related to 0005101closed Axel Rennoch SIP Library Inline type definition in early media heaader causes problems with TCI 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
21-04-2009 12:38Stephan SchulzNew Issue
21-04-2009 12:38Stephan SchulzStatusnew => assigned
21-04-2009 12:38Stephan SchulzAssigned To => Ina Schieferdecker
21-04-2009 12:38Stephan SchulzClause Reference(s) => 7.2.2
21-04-2009 12:38Stephan SchulzSource (company - Author) => STF 370 - Stephan Schulz
21-04-2009 12:41Stephan SchulzRelationship addedrelated to 0005101
04-01-2010 14:11Ina SchieferdeckerNote Added: 0009158
04-01-2010 14:12Ina SchieferdeckerTarget Version => Edition 5.1.1 (not yet published)
23-03-2010 13:00Gyorgy RethyPrioritynormal => low
01-09-2010 14:15Ina SchieferdeckerNote Added: 0009677
01-09-2010 14:15Ina SchieferdeckerNote Edited: 0009677
01-09-2010 14:15Ina SchieferdeckerAssigned ToIna Schieferdecker => Gyorgy Rethy
02-09-2010 16:53Ina SchieferdeckerNote Added: 0009701
03-09-2010 10:25Gyorgy RethyNote Added: 0009706
03-09-2010 10:25Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
03-09-2010 10:25Gyorgy RethyStatusassigned => resolved
03-09-2010 10:25Gyorgy RethyResolutionopen => fixed
30-12-2010 17:11Ina SchieferdeckerStatusresolved => closed
30-12-2010 17:11Ina SchieferdeckerFixed in Version => Edition 4.3.1 (not yet published)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009158) +
+ Ina Schieferdecker    +
+ 04-01-2010 14:11    +
+ 		+ + + + +
+ The TCI type interface defines:
+
+"TString getName() Returns the name of the type as defined in the TTCN 3 module."
+
+However, nested type definitions get implicit names only which are assigned by the TE.
+
+It needs to be discussed if there should be a standardized way to name/access nested type definitions or to make this a tool dependent feature.
+
+Postponed to 2010.
+
+
+
+ + + + + + + + + + +
+ (0009677) +
+ Ina Schieferdecker    +
+ 01-09-2010 14:15    +
+ 		+ + + + +
+ Proposal to resolve the CR as follows:
+
+------------
+TString getName()
+
+Returns the name of the type as defined in the TTCN‑3 module. If the type is a nested type without explicit name, the TE has to create an additional unique identifier for this type which is consistently used in TRI/TCI.
+------------
+
+Please check.
+
+
+
+
+
+ + + + + + + + + + +
+ (0009701) +
+ Ina Schieferdecker    +
+ 02-09-2010 16:53    +
+ 		+ + + + +
+ Proposal to give an example rule for the naming of nested types following the part 1 approach:
+
+----------------
+TString getName()
+
+Returns the name of the type as defined in the TTCN‑3 module. If the type is a nested type without explicit name, the TE has to create an additional unique identifier for this type which is consistently used in TRI/TCI.
+
+NOTE 1: The creation of identifiers for nested types is tool dependent.
+
+NOTE 2: The naming for a nested type without explicit name can follow the rules defined in $6.2.1.1 and $6.2.3.2 of part 1, e.g. TypeIdOrExpression.ElementId and TypeId[-], respectively.
+
+----------------
+
+
+
+ + + + + + + + + + +
+ (0009706) +
+ Gyorgy Rethy    +
+ 03-09-2010 10:25    +
+ 		+ + + + +
+ Reviewed, it's OK.
+
+ + diff --git a/docs/mantis/CR5104.md b/docs/mantis/CR5104.md new file mode 100644 index 0000000000000000000000000000000000000000..eb0653c076960301465da41f1125d21a8c5b44b9 --- /dev/null +++ b/docs/mantis/CR5104.md @@ -0,0 +1,78 @@ + + + + + + + + + + + + + 0005104: out template parameter mistype (inout -> out) - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005104Part 01: TTCN-3 Core LanguageEditorialpublic21-04-2009 13:5601-07-2009 15:52
ReporterTibor Csöndes 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.2.1 (published 2010-07)Fixed in Versionv4.2.1 (published 2010-07) 
Clause Reference(s)Part 1. TTCN-3 Core Language, 5.4.2
Source (company - Author)   Tibor Csöndes, LM Ericsson
Summary0005104: out template parameter mistype (inout -> out)
DescriptionSection 5.4.2 EXAMPLE 3: Inout and out parameters.
+Second example:
+    function MyFunction(out template boolean MyReferenceParameter){ … };
+    // MyReferenceParameter is an inout parameter, the inout keyword is
+    // mandatory
+should be changed to
+    function MyFunction(out template boolean MyReferenceParameter){ … };
+    // MyReferenceParameter is an out parameter, the out keyword is
+    // mandatory
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR5104_ActualParameters.doc (44,032) 22-04-2009 11:28
http://oldforge.etsi.org/mantis/file_download.php?file_id=2104&type=bug
doc CR5104_ActualParameters-v2.doc (44,544) 01-07-2009 15:50
http://oldforge.etsi.org/mantis/file_download.php?file_id=2151&type=bug
Issue History
Date ModifiedUsernameFieldChange
21-04-2009 13:56Tibor CsöndesNew Issue
21-04-2009 13:56Tibor CsöndesClause Reference(s) => 5.4.2
21-04-2009 13:56Tibor CsöndesSource (company - Author) => Tibor Csöndes, LM Ericsson
21-04-2009 14:13Tibor CsöndesClause Reference(s)5.4.2 => Part 1. TTCN-3 Core Language, 5.4.2
21-04-2009 18:00Tibor CsöndesStatusnew => assigned
21-04-2009 18:00Tibor CsöndesAssigned To => Tibor Csöndes
22-04-2009 11:28Tibor CsöndesFile Added: CR5104_ActualParameters.doc
22-04-2009 11:30Tibor CsöndesStatusassigned => resolved
22-04-2009 11:30Tibor CsöndesResolutionopen => fixed
22-04-2009 11:32Tibor CsöndesAssigned ToTibor Csöndes => Ina Schieferdecker
22-04-2009 11:32Tibor CsöndesStatusresolved => feedback
22-04-2009 11:32Tibor CsöndesResolutionfixed => reopened
22-04-2009 11:32Tibor CsöndesStatusfeedback => resolved
30-06-2009 10:30Ina SchieferdeckerProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
30-06-2009 10:30Ina SchieferdeckerTarget Version => Edition 4.2.1 (not yet published)
01-07-2009 15:50Ina SchieferdeckerFile Added: CR5104_ActualParameters-v2.doc
01-07-2009 15:52Ina SchieferdeckerNote Added: 0008813
01-07-2009 15:52Ina SchieferdeckerResolutionreopened => fixed
01-07-2009 15:52Ina SchieferdeckerStatusresolved => closed
01-07-2009 15:52Ina SchieferdeckerFixed in Version => Edition 4.2.1 (not yet published)
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0008813) +
+ Ina Schieferdecker    +
+ 01-07-2009 15:52    +
+ 		+ + + + +
+ As proposed.
+
+Modified in addition two comments:
+
+", the inout keyword is mandatory" removed since it is misleading: the inout keyword is not mandatory as such - but for sure needed if a parameter is inout - this is however clear from the context
+
+See resolution v2
+
+ + diff --git a/docs/mantis/CR5105.md b/docs/mantis/CR5105.md new file mode 100644 index 0000000000000000000000000000000000000000..f027fbeec800d0cd808bbbe6bc83c0f9e05047bc --- /dev/null +++ b/docs/mantis/CR5105.md @@ -0,0 +1,104 @@ + + + + + + + + + + + + + 0005105: Identify expected template content in formal parameters of predefined functions - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005105Part 01: TTCN-3 Core LanguageClarificationpublic21-04-2009 18:3801-07-2009 16:43
ReporterGyorgy Rethy 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.2.1 (published 2010-07)Fixed in Versionv4.2.1 (published 2010-07) 
Clause Reference(s)Annex A
Source (company - Author)     
Summary0005105: Identify expected template content in formal parameters of predefined functions
DescriptionThere are predefined functions that allow template parameters but restrict the content of the actual template pased in (e.g. encvalue). In these cases the template restrictions should be also identified in the signature of the predefined function, e.g.
+    encvalue (in template any_type inpar) return bitstring
+should be changed to
+    encvalue (in template(value) any_type inpar) return bitstring
+
+this would give at least two advantages: the restriction of the parameter's content is more visible; the error message on passing a template containing matching will be about wrong parameter content and not about ... <what?, today the error may also be raised by the codec>
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR5105_resolution.doc (304,128) 30-06-2009 15:32
http://oldforge.etsi.org/mantis/file_download.php?file_id=2144&type=bug
Issue History
Date ModifiedUsernameFieldChange
21-04-2009 18:38Gyorgy RethyNew Issue
21-04-2009 18:38Gyorgy RethyStatusnew => assigned
21-04-2009 18:38Gyorgy RethyAssigned To => Ina Schieferdecker
21-04-2009 18:38Gyorgy RethyClause Reference(s) => Annex A
21-04-2009 18:38Gyorgy RethySource (company - Author) =>
23-04-2009 15:38Ina SchieferdeckerAssigned ToIna Schieferdecker => Gyorgy Rethy
30-06-2009 10:29Ina SchieferdeckerTarget Version => Edition 4.2.1 (not yet published)
30-06-2009 15:32Gyorgy RethyFile Added: CR5105_resolution.doc
30-06-2009 15:35Gyorgy RethyNote Added: 0008799
30-06-2009 15:35Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
30-06-2009 15:36Gyorgy RethyNote Edited: 0008799
01-07-2009 16:42Ina SchieferdeckerNote Added: 0008814
01-07-2009 16:43Ina SchieferdeckerResolutionopen => fixed
01-07-2009 16:43Ina SchieferdeckerStatusassigned => resolved
01-07-2009 16:43Ina SchieferdeckerStatusresolved => closed
01-07-2009 16:43Ina SchieferdeckerFixed in Version => Edition 4.2.1 (not yet published)
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0008799) +
+ Gyorgy Rethy    +
+ 30-06-2009 15:35    +
(edited on: 30-06-2009 15:36)
+ 		+ + + + +
+ All predefined functions are checked, parameter direction and template restrictions are added where applicable. This shall be done consistently in signatures of predefined functions added in the future. CR is ready for checking.
+
+
+
+
+
+ + + + + + + + + + +
+ (0008814) +
+ Ina Schieferdecker    +
+ 01-07-2009 16:42    +
+ 		+ + + + +
+ as proposed
+
+ + diff --git a/docs/mantis/CR5107.md b/docs/mantis/CR5107.md new file mode 100644 index 0000000000000000000000000000000000000000..2bfc5d57a755531ecc57559cd4ff8890e816aae4 --- /dev/null +++ b/docs/mantis/CR5107.md @@ -0,0 +1,101 @@ + + + + + + + + + + + + + 0005107: Editorial on triUnmap - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 05: TTCN-3 Runtime Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005107Part 05: TTCN-3 Runtime Interface Clarificationpublic22-04-2009 11:3102-09-2009 11:59
ReporterIna Schieferdecker 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.2.1 (published 2010-07)Fixed in Versionv4.2.1 (published 2010-07) 
Clause Reference(s)5.5.2.3 triUnmap (TE --> SA)
Source (company - Author)Ina Schieferdecker, FOKUS
Summary0005107: Editorial on triUnmap
DescriptionThere is a copy&paste typo in 5.5.2.3 triUnmap (TE --> SA)
+
+It says "The operation should return TRI_OK in case no dynamic connections have to be established by the test system."
+
+but should say "The operation should return TRI_OK in case no dynamic connections have to be closed by the test system."
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
22-04-2009 11:31Ina SchieferdeckerNew Issue
22-04-2009 11:31Ina SchieferdeckerClause Reference(s) => 5.5.2.3 triUnmap (TE --> SA)
22-04-2009 11:31Ina SchieferdeckerSource (company - Author) => Ina Schieferdecker, FOKUS
22-04-2009 11:32Ina SchieferdeckerProjectTTCN-3 Change Requests => Part 05: TTCN-3 Runtime Interface
22-04-2009 11:33Ina SchieferdeckerNote Added: 0008532
22-04-2009 11:33Ina SchieferdeckerAssigned To => Gyorgy Rethy
22-04-2009 11:33Ina SchieferdeckerStatusnew => assigned
22-04-2009 11:33Ina SchieferdeckerResolutionopen => fixed
22-04-2009 11:33Ina SchieferdeckerCategoryTRI => Clarification
22-04-2009 11:33Ina SchieferdeckerTarget Version => Edition 4.2.1 (not yet published)
22-04-2009 11:33Ina SchieferdeckerDescription Updated
01-09-2009 16:10Gyorgy RethyNote Added: 0008956
01-09-2009 16:10Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
02-09-2009 11:58Ina SchieferdeckerStatusassigned => resolved
02-09-2009 11:58Ina SchieferdeckerFixed in Version => Edition 4.2.1 (not yet published)
02-09-2009 11:58Ina SchieferdeckerStatusresolved => assigned
02-09-2009 11:59Ina SchieferdeckerStatusassigned => closed
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0008532) +
+ Ina Schieferdecker    +
+ 22-04-2009 11:33    +
+ 		+ + + + +
+ Please check.
+
+
+
+ + + + + + + + + + +
+ (0008956) +
+ Gyorgy Rethy    +
+ 01-09-2009 16:10    +
+ 		+ + + + +
+ Ok as proposed.
+
+ + diff --git a/docs/mantis/CR5108.md b/docs/mantis/CR5108.md new file mode 100644 index 0000000000000000000000000000000000000000..8de2c5454e5c843a5ffc5feb9ae93bc02acd5d34 --- /dev/null +++ b/docs/mantis/CR5108.md @@ -0,0 +1,112 @@ + + + + + + + + + + + + + 0005108: Editorial on tciConnect and tciDisconnect - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005108Part 06: TTCN-3 Control InterfaceClarificationpublic22-04-2009 12:3102-09-2009 12:01
ReporterIna Schieferdecker 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.2.1 (published 2010-07)Fixed in Versionv4.2.1 (published 2010-07) 
Clause Reference(s)7.3.3.1.8 tciConnect, 7.3.3.1.9 tciDisconnect
Source (company - Author)Ina Schieferdecker, FOKUS
Summary0005108: Editorial on tciConnect and tciDisconnect
DescriptionThe constraints for tciConnect and tciDisconnect say
+
+"This operation shall be called by the CH at the local TE when at a remote TE a provided tciConnect has been called."
+
+and
+
+"This operation shall be called by the CH at the local TE when at a remote TE a provided tciDisconnect has been called."
+
+but should say
+
+"This operation shall be called by the CH at the local TE when at a remote TE a provided tciConnectReq has been called."
+
+and
+
+"This operation shall be called by the CH at the local TE when at a remote TE a provided tciDisconnectReq has been called."
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
22-04-2009 12:31Ina SchieferdeckerNew Issue
22-04-2009 12:31Ina SchieferdeckerClause Reference(s) => 7.3.3.1.8 tciConnect, 7.3.3.1.9 tciDisconnect
22-04-2009 12:31Ina SchieferdeckerSource (company - Author) => Ina Schieferdecker, FOKUS
22-04-2009 12:31Ina SchieferdeckerProjectTTCN-3 Change Requests => Part 06: TTCN-3 Control Interface
22-04-2009 12:32Ina SchieferdeckerNote Added: 0008534
22-04-2009 12:32Ina SchieferdeckerAssigned To => Gyorgy Rethy
22-04-2009 12:32Ina SchieferdeckerStatusnew => assigned
22-04-2009 12:32Ina SchieferdeckerResolutionopen => fixed
22-04-2009 12:32Ina SchieferdeckerCategoryTCI => Clarification
22-04-2009 12:32Ina SchieferdeckerTarget Version => Edition 4.2.1 (not yet published)
01-09-2009 16:05Gyorgy RethyNote Added: 0008955
01-09-2009 16:07Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
02-09-2009 12:01Ina SchieferdeckerStatusassigned => resolved
02-09-2009 12:01Ina SchieferdeckerFixed in Version => Edition 4.2.1 (not yet published)
02-09-2009 12:01Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0008534) +
+ Ina Schieferdecker    +
+ 22-04-2009 12:32    +
+ 		+ + + + +
+ Please check.
+
+
+
+ + + + + + + + + + +
+ (0008955) +
+ Gyorgy Rethy    +
+ 01-09-2009 16:05    +
+ 		+ + + + +
+ OK as proposed.
+
+ + diff --git a/docs/mantis/CR5110.md b/docs/mantis/CR5110.md new file mode 100644 index 0000000000000000000000000000000000000000..3118767f0d1e5f5f5f336c5ab5307585440542ae --- /dev/null +++ b/docs/mantis/CR5110.md @@ -0,0 +1,282 @@ + + + + + + + + + + + + + 0005110: Concepts to specify tests for continuous systems - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Continuous signal support (ES 202 786)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005110Ext Pack: Continuous signal support (ES 202 786)Clarificationpublic24-04-2009 18:2923-01-2012 21:30
Reporteruser540 
Assigned ToJens Grabowski 
PriorityhighSeverityfeatureReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv1.1.1 (published 2012-04)Fixed in Versionv1.1.1 (published 2012-04) 
Summary0005110: Concepts to specify tests for continuous systems
DescriptionEmbedded systems play an ever increasing role in the realization of
+complex control functions in many industrial domains. In particular software-based control systems have specific characteristics and
+the test technology used to test such systems has to address the different aspects of discrete behaviors for the communication sequences, continuous behaviors for the control sequences (i.e. control sequences in interaction with sensors/actuators, with other system components and the user). Actually TTCN-3 lacks support to test continuous systems. We propose to introduce such concepts to the language. In particular:
+
+- the notions of time and sampling,
+- the notions of streams, stream ports and stream variables, and
+- the definition of an automaton alike control flow structure to support the
+  specification of hybrid behavior.
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0004275closed Ina Schieferdecker Part 01: TTCN-3 Core Language New Concepts to be defined via Packages 
Attached Filespptx Continuous-TTCN3-Concepts_consolidated.pptx (649,439) 24-04-2009 18:29
http://oldforge.etsi.org/mantis/file_download.php?file_id=2116&type=bug
doc es_TTCN3Package C-TTCN-3.doc (580,096) 03-12-2009 11:58
http://oldforge.etsi.org/mantis/file_download.php?file_id=2275&type=bug
pptx Continuous-TTCN3-Concepts_final.pptx (531,460) 03-12-2009 11:59
http://oldforge.etsi.org/mantis/file_download.php?file_id=2276&type=bug
pptx Continuous-TTCN3-Concepts_V0.2.pptx (531,594) 07-12-2009 16:55
http://oldforge.etsi.org/mantis/file_download.php?file_id=2281&type=bug
doc es_TTCN3Package C-TTCN-3_V0.2.doc (836,096) 07-12-2009 16:55
http://oldforge.etsi.org/mantis/file_download.php?file_id=2282&type=bug
doc es_TTCN3PackageRT-TTCN-3-100121.doc (267,776) 16-02-2010 14:35
http://oldforge.etsi.org/mantis/file_download.php?file_id=2338&type=bug
doc es_TTCN3Package C-TTCN-3_V0.4.doc (891,904) 27-09-2011 16:20
http://oldforge.etsi.org/mantis/file_download.php?file_id=2564&type=bug
doc es_TTCN3Package C-TTCN-3_V0.6.doc (829,440) 01-12-2011 10:43
http://oldforge.etsi.org/mantis/file_download.php?file_id=2639&type=bug
zip es_TTCN3Package C-TTCN-3_V0.7.zip (393,993) 01-12-2011 12:44
http://oldforge.etsi.org/mantis/file_download.php?file_id=2640&type=bug
Issue History
Date ModifiedUsernameFieldChange
24-04-2009 18:29user540New Issue
24-04-2009 18:29user540File Added: Continuous-TTCN3-Concepts_consolidated.pptx
24-04-2009 18:29user540Clause Reference(s) => ??
24-04-2009 18:29user540Source (company - Author) =>
30-06-2009 09:42Ina SchieferdeckerProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
30-06-2009 09:43Ina SchieferdeckerStatusnew => assigned
30-06-2009 09:43Ina SchieferdeckerAssigned To => Jens Grabowski
30-06-2009 10:20Ina SchieferdeckerCategoryTTCN-3 Core Language => Clarification
30-06-2009 10:20Ina SchieferdeckerTarget Version => Edition 5.1.1 (not yet published)
03-12-2009 11:58user540File Added: es_TTCN3Package C-TTCN-3.doc
03-12-2009 11:59user540File Added: Continuous-TTCN3-Concepts_final.pptx
03-12-2009 12:00user540Note Added: 0009081
07-12-2009 16:55user540File Added: Continuous-TTCN3-Concepts_V0.2.pptx
07-12-2009 16:55user540File Added: es_TTCN3Package C-TTCN-3_V0.2.doc
16-02-2010 14:34Jens GrabowskiNote Added: 0009222
16-02-2010 14:35Jens GrabowskiFile Added: es_TTCN3PackageRT-TTCN-3-100121.doc
22-03-2010 17:27Gyorgy RethyAssigned ToJens Grabowski =>
22-03-2010 17:27Gyorgy RethyStatusassigned => new
23-03-2010 13:00Gyorgy RethyAssigned To => Jens Grabowski
23-03-2010 13:00Gyorgy RethyPrioritynormal => low
23-03-2010 13:00Gyorgy RethyStatusnew => assigned
29-06-2010 11:55Gyorgy RethyProjectPart 01: TTCN-3 Core Language => Ext Pack: Perf & Real Time Testing (ES 202 782)
30-11-2010 13:29Gyorgy RethyNote Added: 0009842
03-12-2010 09:49Gyorgy RethyProjectExt Pack: Perf & Real Time Testing (ES 202 782) => Ext Pack: Continuous signal support (ES 202 786)
07-12-2010 13:49Gyorgy RethyAssigned ToJens Grabowski =>
07-12-2010 13:49Gyorgy RethyTarget VersionEdition 4.3.1 (not yet published) => v1.1.1
25-05-2011 11:50Sebastian MuellersAssigned To => Ina Schieferdecker
25-05-2011 12:02Ina SchieferdeckerAssigned ToIna Schieferdecker => Jens Grabowski
26-05-2011 15:50Ina SchieferdeckerRelationship addedrelated to 0004275
29-06-2011 14:19Jens GrabowskiAssigned ToJens Grabowski => Jacob Wieland - Spirent
27-09-2011 16:20Jacob Wieland - SpirentFile Added: es_TTCN3Package C-TTCN-3_V0.4.doc
27-09-2011 16:23Jacob Wieland - SpirentNote Added: 0010252
27-09-2011 16:23Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Jens Grabowski
30-11-2011 13:39Gyorgy RethyPrioritylow => high
01-12-2011 10:43Jens GrabowskiFile Added: es_TTCN3Package C-TTCN-3_V0.6.doc
01-12-2011 10:45Jens GrabowskiNote Added: 0010463
01-12-2011 10:55Jens GrabowskiAssigned ToJens Grabowski => Jacob Wieland - Spirent
01-12-2011 12:44Jacob Wieland - SpirentFile Added: es_TTCN3Package C-TTCN-3_V0.7.zip
01-12-2011 12:45Jacob Wieland - SpirentNote Added: 0010476
01-12-2011 12:46Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent =>
01-12-2011 12:54Jens GrabowskiAssigned To => Jens Grabowski
23-01-2012 21:30Gyorgy RethyNote Added: 0010547
23-01-2012 21:30Gyorgy RethyStatusassigned => closed
23-01-2012 21:30Gyorgy RethyResolutionopen => fixed
23-01-2012 21:30Gyorgy RethyFixed in Version => v1.1.1
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009081) +
+ user540    +
+ 03-12-2009 12:00    +
+ 		+ + + + +
+ I've updated the slides describing the continuous concepts and added a new package description draft.
+
+
+
+ + + + + + + + + + +
+ (0009222) +
+ Jens Grabowski    +
+ 16-02-2010 14:34    +
+ 		+ + + + +
+ The resolution of this CR will become part of the Real Time Package. CR 4483
+ and this CR are merged into this CR. The Real Time Package Draft is uploaded into this CR.
+
+
+
+ + + + + + + + + + +
+ (0009842) +
+ Gyorgy Rethy    +
+ 30-11-2010 13:29    +
+ 		+ + + + +
+ STF discussion on 30/11/2010: propose a new WI on continuous signal testing; to be postponed to 2011.
+
+
+
+ + + + + + + + + + +
+ (0010252) +
+ Jacob Wieland - Spirent    +
+ 27-09-2011 16:23    +
+ 		+ + + + +
+ I've reviewed and re-structured the text according to the Syntactical Structure, Semantic Description, Restrictions, Example pattern and moved all BNF rules into the BNF annex.
+
+However, I'm not happy at all with the find/violates constructs as they don't seem to fit with the rest of the concepts (compositionally). I.e. it is unclear to me what their actual semantics shall be. Thus, I would propose to leave them out of the first version.
+
+
+
+ + + + + + + + + + +
+ (0010463) +
+ Jens Grabowski    +
+ 01-12-2011 10:45    +
+ 		+ + + + +
+ es_TTCN3Package C-TTCN-3_V0.6.doc is for a short internal review of the STF. After the review, the text will be restructured according to the structure of the other extension packages.
+
+
+
+ + + + + + + + + + +
+ (0010476) +
+ Jacob Wieland - Spirent    +
+ 01-12-2011 12:45    +
+ 		+ + + + +
+ corrected definitions of lengthof/sizeof to be in sync with core standard.
+
+Deleted superfluous chapter 8.
+
+Otherwise, ok with me.
+
+
+
+ + + + + + + + + + +
+ (0010547) +
+ Gyorgy Rethy    +
+ 23-01-2012 21:30    +
+ 		+ + + + +
+ Draft has been sent to TB MTS for approval
+
+ + diff --git a/docs/mantis/CR5159.md b/docs/mantis/CR5159.md new file mode 100644 index 0000000000000000000000000000000000000000..47bf0af57bf2e0b974b99841107231df2d1a71f2 --- /dev/null +++ b/docs/mantis/CR5159.md @@ -0,0 +1,250 @@ + + + + + + + + + + + + + 0005159: Inconsistent definition for TriSignature across the C/C++/Java/XML mappings - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 05: TTCN-3 Runtime Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005159Part 05: TTCN-3 Runtime Interface Clarificationpublic06-05-2009 16:5802-09-2010 16:41
ReporterAnthony Baire 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionwon't fix 
PlatformOSOS Version
Product Version 
Target Versionv4.3.1 (published 2011-06)Fixed in Version 
Clause Reference(s)Part 5 6.3.2.8 and Part 6 10.3.2.12, B.2
Source (company - Author)     
Summary0005159: Inconsistent definition for TriSignature across the C/C++/Java/XML mappings
DescriptionThe definition of TriSignature is not consistent across the different mappings of the TRI. It is defined :
+- as a QualifiedName in the C and C++ mappings
+- as a String in the Java and XML mappings
+
+=> the Java/XML mappings should be updated to use QualifiedName instead of String
+
+rationale: a signature is a ttcn3 object and it is identified by its module name and its object name
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesppt CR5159_v2.ppt (60,928) 01-09-2010 18:05
http://oldforge.etsi.org/mantis/file_download.php?file_id=2431&type=bug
doc CR5159_TCI.doc (39,936) 01-09-2010 18:13
http://oldforge.etsi.org/mantis/file_download.php?file_id=2432&type=bug
doc CR5159_TRI.doc (42,496) 02-09-2010 10:25
http://oldforge.etsi.org/mantis/file_download.php?file_id=2433&type=bug
doc CR5159_TRI-Jacob.doc (24,576) 02-09-2010 11:12
http://oldforge.etsi.org/mantis/file_download.php?file_id=2437&type=bug
Issue History
Date ModifiedUsernameFieldChange
06-05-2009 16:58Anthony BaireNew Issue
06-05-2009 16:58Anthony BaireClause Reference(s) => Part 5 6.3.2.8 and Part 6 10.3.2.12, B.2
06-05-2009 16:58Anthony BaireSource (company - Author) =>
30-06-2009 09:46Ina SchieferdeckerStatusnew => assigned
30-06-2009 09:46Ina SchieferdeckerAssigned To => Ina Schieferdecker
30-06-2009 10:19Ina SchieferdeckerProjectTTCN-3 Change Requests => Part 05: TTCN-3 Runtime Interface
30-06-2009 10:19Ina SchieferdeckerCategoryTRI => Clarification
30-06-2009 10:19Ina SchieferdeckerTarget Version => Edition 4.2.1 (not yet published)
30-06-2009 10:19Ina SchieferdeckerDescription Updated
15-02-2010 04:34Ina SchieferdeckerNote Added: 0009207
15-02-2010 04:35Ina SchieferdeckerTarget VersionEdition 4.2.1 (not yet published) => Edition 5.1.1 (not yet published)
30-06-2010 11:59Ina SchieferdeckerFile Added: CR5159.ppt
30-06-2010 12:00Ina SchieferdeckerNote Added: 0009427
01-09-2010 18:04Ina SchieferdeckerFile Deleted: CR5159.ppt
01-09-2010 18:05Ina SchieferdeckerFile Added: CR5159_v2.ppt
01-09-2010 18:13Ina SchieferdeckerFile Added: CR5159_TCI.doc
01-09-2010 18:13Ina SchieferdeckerNote Added: 0009689
02-09-2010 10:25Ina SchieferdeckerFile Added: CR5159_TRI.doc
02-09-2010 10:26Ina SchieferdeckerNote Added: 0009693
02-09-2010 10:27Ina SchieferdeckerNote Edited: 0009693
02-09-2010 10:27Ina SchieferdeckerAssigned ToIna Schieferdecker => Jacob Wieland - Spirent
02-09-2010 11:12Jacob Wieland - SpirentFile Added: CR5159_TRI-Jacob.doc
02-09-2010 11:14Jacob Wieland - SpirentNote Added: 0009696
02-09-2010 11:14Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Ina Schieferdecker
02-09-2010 16:41Ina SchieferdeckerNote Added: 0009700
02-09-2010 16:41Ina SchieferdeckerStatusassigned => closed
02-09-2010 16:41Ina SchieferdeckerResolutionopen => won't fix
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009207) +
+ Ina Schieferdecker    +
+ 15-02-2010 04:34    +
+ 		+ + + + +
+ QualifiedName is in TRI in the C mapping not only used for SignatureId but also for ComponentId, PortId, FunctionId and TestCaseId. To make this more consistent across the various mappings requires more discussion with the tool vendors. Hence moved to 2010.
+
+
+
+ + + + + + + + + + +
+ (0009427) +
+ Ina Schieferdecker    +
+ 30-06-2010 12:00    +
+ 		+ + + + +
+ Analysis shows further inconsistencies in the usage of qualified name across TRI/TCI
+
+
+
+ + + + + + + + + + +
+ (0009689) +
+ Ina Schieferdecker    +
+ 01-09-2010 18:13    +
+ 		+ + + + +
+ More fine-grained analysis - see ppt
+
+Draft proposal for TCI - see doc - the extension of Id seems to be the smallest change - still, it might be a too principal change - please check
+
+
+
+ + + + + + + + + + +
+ (0009693) +
+ Ina Schieferdecker    +
+ 02-09-2010 10:26    +
(edited on: 02-09-2010 10:27)
+ 		+ + + + +
+ The solution for the use of qualified name in the Java mapping for TRI could look like CR5159_TRI.doc. I am however not sure that this is worth the efforts as it breaks legacy code for the sake of consistency between TRI mappings - although code from different mappings will hardly be combined.
+
+Please check.
+
+
+
+
+
+ + + + + + + + + + +
+ (0009696) +
+ Jacob Wieland - Spirent    +
+ 02-09-2010 11:14    +
+ 		+ + + + +
+ interface declarations always need a body, even if it is empty
+
+otherwise, it seems to be consistent.
+
+Maybe some of the methods (where possible) should be kept for backward compatibility reasons to reduce breaking of existing code.
+
+
+
+ + + + + + + + + + +
+ (0009700) +
+ Ina Schieferdecker    +
+ 02-09-2010 16:41    +
+ 		+ + + + +
+ The discussion in the STF finally lead to the decision to reject the CR as the solution would break legacy code and would not bring much added value.
+
+ + diff --git a/docs/mantis/CR5164.md b/docs/mantis/CR5164.md new file mode 100644 index 0000000000000000000000000000000000000000..b21d69df329662c2cfa58d735b4922df2be4e367 --- /dev/null +++ b/docs/mantis/CR5164.md @@ -0,0 +1,105 @@ + + + + + + + + + + + + + 0005164: useorder and untagged should not be used together - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005164Part 09: Using XML with TTCN-3Clarificationpublic08-05-2009 15:4201-02-2010 09:37
ReporterGyorgy Rethy 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.2.1 (published 2010-07)Fixed in Versionv4.2.1 (published 2010-07) 
Clause Reference(s)7.9
For STF discussion
Source (company - Author)L.M.Ericsson
Summary0005164: useorder and untagged should not be used together
DescriptionX.693 amd1, 35.2.8 excludes using the useorder and the untagged encoding instructions together. In the last example in $7.9 they are used together. This has to be clarified in the text and the example has to be corrected.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR5164_resolution_v1.doc (152,064) 02-09-2009 17:28
http://oldforge.etsi.org/mantis/file_download.php?file_id=2231&type=bug
doc CR5164_resolution_v2.doc (155,648) 08-12-2009 12:26
http://oldforge.etsi.org/mantis/file_download.php?file_id=2290&type=bug
Issue History
Date ModifiedUsernameFieldChange
08-05-2009 15:42Gyorgy RethyNew Issue
08-05-2009 15:42Gyorgy RethyStatusnew => assigned
08-05-2009 15:42Gyorgy RethyAssigned To => Gyorgy Rethy
08-05-2009 15:42Gyorgy RethyClause Reference(s) => 7.9
08-05-2009 15:42Gyorgy RethySource (company - Author) => L.M.Ericsson
30-06-2009 10:28Ina SchieferdeckerTarget Version => Edition 4.2.1 (not yet published)
02-09-2009 11:41Gyorgy RethyFile Added: CR5164_resolution_v1.doc
02-09-2009 17:28Gyorgy RethyFile Deleted: CR5164_resolution_v1.doc
02-09-2009 17:28Gyorgy RethyFile Added: CR5164_resolution_v1.doc
02-09-2009 17:43Gyorgy RethyNote Added: 0008967
07-12-2009 16:21Gyorgy RethyFile Added: CR5164_resolution_v2.doc
07-12-2009 16:25Gyorgy RethyNote Added: 0009084
08-12-2009 12:24Gyorgy RethyFile Deleted: CR5164_resolution_v2.doc
08-12-2009 12:26Gyorgy RethyFile Added: CR5164_resolution_v2.doc
08-12-2009 12:26Gyorgy RethyNote Edited: 0009084
08-12-2009 12:27Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
01-02-2010 09:37Gyorgy RethyStatusassigned => closed
01-02-2010 09:37Gyorgy RethyResolutionopen => fixed
01-02-2010 09:37Gyorgy RethyFixed in Version => Edition 4.2.1 (not yet published)
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0008967) +
+ Gyorgy Rethy    +
+ 02-09-2009 17:43    +
+ 		+ + + + +
+ CR5164_resolution_v1.doc: first draft for resolution: description of the untagged encoding instruction (missing in published versions).
+
+The original question still needs to be clarified: are the useOrder and untagged instructions allowed together? When converting XSD Schemas, they may be used together in one case: both attached to the record type generated for a model group definition with the compositor <all>.
+
+ASN.1 forbids the joint use of USE-ORDER and UNTAGGED (in X.693) but X.694 ignores model groups with compositor <all>, therefore their combination simply never needed. TTCN-3 Part-9 differs in this from X.694.
+
+Generating a type for model groups with compositor <all> would be incorrect in the case if XSD allowed referencing more than one such model group within a single ComplexType content. In this case the order field (which is an additional record of enumerated) should combine all elements from all referenced groups. But it still needs to be checked if XSD allows this or not.
+
+
+
+ + + + + + + + + + +
+ (0009084) +
+ Gyorgy Rethy    +
+ 07-12-2009 16:25    +
(edited on: 08-12-2009 12:26)
+ 		+ + + + +
+ CR5164_resolution_v2.doc: clarified and updated: useOrder and untagged can be used together but name as and untagged should not (the rule to handle such cases is defined, thus should not cause an error); ready for review
+
+
+
+ + diff --git a/docs/mantis/CR5165.md b/docs/mantis/CR5165.md new file mode 100644 index 0000000000000000000000000000000000000000..9c8f8dd7d460c1394e0e07fd8241331907420417 --- /dev/null +++ b/docs/mantis/CR5165.md @@ -0,0 +1,175 @@ + + + + + + + + + + + + + 0005165: anyAttribute & anyElement should be attached to XSD.String in all cases - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005165Part 09: Using XML with TTCN-3Technicalpublic08-05-2009 15:5101-02-2010 08:58
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.2.1 (published 2010-07)Fixed in Versionv4.2.1 (published 2010-07) 
Clause Reference(s)7.7
For STF discussion
Source (company - Author)L.M.Ericsson
Summary0005165: anyAttribute & anyElement should be attached to XSD.String in all cases
DescriptionFor simple an "any" element or attribute a TTCN-3 XSD.String is generated and either the "anyAttribute" or "anyElement" TTCN-3 attribute is attached. When also a recurrence is defined in XSD (using the minOccurs and maxOccurs XSD attributes), a record of XSD.String field is generated in TTCN-3. In this latter case - this is the only exception in the mapping - the TTCN-3 attribute is not attached to the related type (XSD.String) but to the record of. This was specified in this way, because earlier versions of the Core did not allowed referring types embedded to record/set ofs. But v4.1.1 does allow this, hence this expetion shall be removed from Part-9. I.e. the example in $7.7 becomes:
+type record E46b {
+    record of XSD.String elem_list
+}
+with {
+    variant "name as uncapitalized";
+    variant(elem_list[-]) "anyElement except unqualified"
+}
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR5165_resolution v1.doc (152,576) 01-09-2009 15:23
http://oldforge.etsi.org/mantis/file_download.php?file_id=2227&type=bug
doc CR5165_resolution v2.doc (148,992) 08-12-2009 07:47
http://oldforge.etsi.org/mantis/file_download.php?file_id=2288&type=bug
Issue History
Date ModifiedUsernameFieldChange
08-05-2009 15:51Gyorgy RethyNew Issue
08-05-2009 15:51Gyorgy RethyStatusnew => assigned
08-05-2009 15:51Gyorgy RethyAssigned To => Gyorgy Rethy
08-05-2009 15:51Gyorgy RethyClause Reference(s) => 7.7
08-05-2009 15:51Gyorgy RethySource (company - Author) => L.M.Ericsson
08-05-2009 15:52Gyorgy RethySummaryanyAttribute & anyElement should be attached to the relevant type => anyAttribute & anyElement should be attached to XSD.String in all cases
30-06-2009 10:28Ina SchieferdeckerTarget Version => Edition 4.2.1 (not yet published)
01-09-2009 15:23Gyorgy RethyNote Added: 0008952
01-09-2009 15:23Gyorgy RethyFile Added: CR5165_resolution v1.doc
01-09-2009 15:24Gyorgy RethyNote Edited: 0008952
01-09-2009 15:24Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
01-09-2009 15:25Gyorgy RethyResolutionopen => fixed
02-09-2009 10:08Gyorgy RethyNote Added: 0008959
08-12-2009 07:46Ina SchieferdeckerNote Added: 0009092
08-12-2009 07:47Ina SchieferdeckerFile Added: CR5165_resolution v2.doc
08-12-2009 07:47Ina SchieferdeckerAssigned ToIna Schieferdecker => Gyorgy Rethy
08-12-2009 07:47Ina SchieferdeckerStatusassigned => resolved
01-02-2010 08:58Gyorgy RethyStatusresolved => closed
01-02-2010 08:58Gyorgy RethyNote Added: 0009170
01-02-2010 08:58Gyorgy RethyFixed in Version => Edition 4.2.1 (not yet published)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0008952) +
+ Gyorgy Rethy    +
+ 01-09-2009 15:23    +
(edited on: 01-09-2009 15:24)
+ 		+ + + + +
+ CR5165_resolution v1.doc: draft of the CR resolution; ready to be checked.
+
+
+
+
+
+ + + + + + + + + + +
+ (0008959) +
+ Gyorgy Rethy    +
+ 02-09-2009 10:08    +
+ 		+ + + + +
+ In case of anyAttribute, always a record of XSD.String is generated for an anyAttribute, therefore it is OK to attach the TTCN-3 attribute to the record of. It is only the XSD.String generated for an any element that normally is a simple XSD.String but shall be embedded into a record of in a specific case.
+
+
+
+ + + + + + + + + + +
+ (0009092) +
+ Ina Schieferdecker    +
+ 08-12-2009 07:46    +
+ 		+ + + + +
+ ok, some minor fixes only - see v2.
+
+
+
+ + + + + + + + + + +
+ (0009170) +
+ Gyorgy Rethy    +
+ 01-02-2010 08:58    +
+ 		+ + + + +
+ Implemented as in CR5165_resolution v2.doc
+
+ + diff --git a/docs/mantis/CR5168.md b/docs/mantis/CR5168.md new file mode 100644 index 0000000000000000000000000000000000000000..9015056911c495ab3973de68f154515c84325a7a --- /dev/null +++ b/docs/mantis/CR5168.md @@ -0,0 +1,110 @@ + + + + + + + + + + + + + 0005168: Unclear typing rules for communication operations - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005168Part 01: TTCN-3 Core LanguageClarificationpublic11-05-2009 12:5404-01-2010 12:08
ReporterGyorgy Rethy 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.2.1 (published 2010-07)Fixed in Versionv4.2.1 (published 2010-07) 
Clause Reference(s)6.3, 22
Source (company - Author)L.M.Ericsson
Summary0005168: Unclear typing rules for communication operations
DescriptionToday type compatibility says:
+"Generally, TTCN 3 requires type compatibility of values at assignments, instantiations and comparison." (instead of TTCN-3 allows...).
+
+In the clausse, e.g. describing send and received, the requirement is that the type shall be on the related list of the port.
+
+But no clear rule given for the case:
+type record MyRec {...}
+type MyRec MyRecAlias;
+
+template MyRecAlias t_MyRecAlias := {...}
+
+connect (myComp:P1 myComp:P2)//provided both types are on the lists
+P1.send (t_MyRecAlias);
+P2.receive ( MyRec:?); //shall receive be successful or not?
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR5168_resolution_v1.doc (32,768) 09-12-2009 16:25
http://oldforge.etsi.org/mantis/file_download.php?file_id=2310&type=bug
Issue History
Date ModifiedUsernameFieldChange
11-05-2009 12:54Gyorgy RethyNew Issue
11-05-2009 12:54Gyorgy RethyStatusnew => assigned
11-05-2009 12:54Gyorgy RethyAssigned To => Ina Schieferdecker
11-05-2009 12:54Gyorgy RethyClause Reference(s) => 6.3, 22
11-05-2009 12:54Gyorgy RethySource (company - Author) => L.M.Ericsson
09-12-2009 16:24Ina SchieferdeckerNote Added: 0009129
09-12-2009 16:25Ina SchieferdeckerFile Added: CR5168_resolution_v1.doc
09-12-2009 16:25Ina SchieferdeckerAssigned ToIna Schieferdecker => Gyorgy Rethy
09-12-2009 16:25Ina SchieferdeckerResolutionopen => fixed
09-12-2009 16:25Ina SchieferdeckerFixed in Version => Edition 4.2.1 (not yet published)
09-12-2009 16:25Ina SchieferdeckerTarget Version => Edition 4.2.1 (not yet published)
10-12-2009 13:15Gyorgy RethyNote Added: 0009145
10-12-2009 13:15Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
04-01-2010 12:07Ina SchieferdeckerStatusassigned => resolved
04-01-2010 12:08Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009129) +
+ Ina Schieferdecker    +
+ 09-12-2009 16:24    +
+ 		+ + + + +
+ Strong typing is required for communication operations. We may however add an example - see resolution v1
+
+
+
+ + + + + + + + + + +
+ (0009145) +
+ Gyorgy Rethy    +
+ 10-12-2009 13:15    +
+ 		+ + + + +
+ Its OK with me.
+
+ + diff --git a/docs/mantis/CR5171.md b/docs/mantis/CR5171.md new file mode 100644 index 0000000000000000000000000000000000000000..b25880b62a233f740fb729d7fb12d09420fe3c37 --- /dev/null +++ b/docs/mantis/CR5171.md @@ -0,0 +1,334 @@ + + + + + + + + + + + + + 0005171: function or macro to return name of the current test case ("__TESTCASE__") - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005171Part 01: TTCN-3 Core LanguageNew Featurepublic12-05-2009 12:3816-02-2010 07:20
ReporterWolfgang Seka 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.2.1 (published 2010-07)Fixed in Versionv4.2.1 (published 2010-07) 
Clause Reference(s)TTCN-3 Core Language: Annex C or D
Source (company - Author)    MCC160
Summary0005171: function or macro to return name of the current test case ("__TESTCASE__")
DescriptionFor some purposes it is necessary to assign values (e.g. in templates) depending on the test case but it may be unacceptable efford to hand through this information to each and every function or template.
+
+Note: in case of templates it is not possible to use global variables;
+only formal parameters, modulepars, constants or functions with no "runs on" may be used
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR5171_testcasename.doc (128,512) 01-07-2009 15:12
http://oldforge.etsi.org/mantis/file_download.php?file_id=2148&type=bug
doc CR5171_testcasename_v2.doc (136,192) 03-07-2009 11:11
http://oldforge.etsi.org/mantis/file_download.php?file_id=2155&type=bug
doc CR5171_testcasename_v3.doc (137,216) 03-07-2009 12:14
http://oldforge.etsi.org/mantis/file_download.php?file_id=2159&type=bug
doc CR5171_testcasename_v4.doc (203,776) 10-07-2009 11:00
http://oldforge.etsi.org/mantis/file_download.php?file_id=2205&type=bug
doc CR5171_testcasename_v5.doc (203,776) 10-07-2009 12:11
http://oldforge.etsi.org/mantis/file_download.php?file_id=2206&type=bug
Issue History
Date ModifiedUsernameFieldChange
12-05-2009 12:38Wolfgang SekaNew Issue
12-05-2009 12:38Wolfgang SekaClause Reference(s) => TTCN-3 Core Language: Annex C or D
12-05-2009 12:38Wolfgang SekaSource (company - Author) => MCC160
27-05-2009 14:53Gyorgy RethyNote Added: 0008663
27-05-2009 14:53Gyorgy RethyNote Added: 0008664
30-06-2009 09:37Ina SchieferdeckerProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
30-06-2009 09:37Ina SchieferdeckerStatusnew => assigned
30-06-2009 09:37Ina SchieferdeckerAssigned To => Tibor Csöndes
30-06-2009 10:21Ina SchieferdeckerTarget Version => Edition 4.2.1 (not yet published)
01-07-2009 15:12Tibor CsöndesFile Added: CR5171_testcasename.doc
01-07-2009 15:16Tibor CsöndesNote Added: 0008808
01-07-2009 15:16Tibor CsöndesAssigned ToTibor Csöndes => Gyorgy Rethy
03-07-2009 11:11Gyorgy RethyFile Added: CR5171_testcasename_v2.doc
03-07-2009 11:12Gyorgy RethyNote Added: 0008825
03-07-2009 11:13Gyorgy RethyAssigned ToGyorgy Rethy => Tibor Csöndes
03-07-2009 12:14Tibor CsöndesFile Added: CR5171_testcasename_v3.doc
03-07-2009 12:15Tibor CsöndesNote Added: 0008828
03-07-2009 12:15Tibor CsöndesAssigned ToTibor Csöndes => Ina Schieferdecker
10-07-2009 11:00Ina SchieferdeckerFile Added: CR5171_testcasename_v4.doc
10-07-2009 11:01Ina SchieferdeckerNote Added: 0008885
10-07-2009 12:11Gyorgy RethyFile Added: CR5171_testcasename_v5.doc
10-07-2009 12:13Gyorgy RethyNote Added: 0008886
10-07-2009 12:14Gyorgy RethyStatusassigned => resolved
10-07-2009 12:14Gyorgy RethyResolutionopen => fixed
16-02-2010 07:20Ina SchieferdeckerStatusresolved => closed
16-02-2010 07:20Ina SchieferdeckerFixed in Version => Edition 4.2.1 (not yet published)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0008663) +
+ Gyorgy Rethy    +
+ 27-05-2009 14:53    +
+ 		+ + + + +
+ From a mail received from Wolfgang:
+"along the discussions about value returning functions being used in templates I read in the spec again and found the following in 16.1.4:
+
+         
+        "Value returning functions can be called during communication operations (in templates, template fields or in-line
+        templates) ...
+        To avoid side effects ... the following operations shall not be used in functions called in the cases specified above:
+        ...
+        e) Calling external functions (see notes 4 and 6).
+        ...
+        NOTE 4: Calling of external functions, rnd, running, alive, read, setverdict, and writing to component
+        variables is illegal because it may lead to different results of subsequent evaluations of the same snapshot,
+        thus, e.g. rendering deadlock detection impossible.
+        ...
+        NOTE 6: Restrictions except the limitation on the use of out or inout parameterization apply recursively, i.e. it
+        is disallowed to use them directly, or via an arbitrary long chain of function invocations.
+        ..."
+
+That clashes with our current preliminary solution for the __TESTCASE__ issue:
+Here we have: Template calling TTCN function calling external function (the latter one returns the test case name).
+
+Now - acc. to my interpretation - this is not correct since indirectly an external function is used in the template.
+On the other hand is the argumentation as given above hard to follow in our case (our external fx_GetCurrentTestcaseName will never cause problems as mentioned)
+ 
+In any case we need a solution
+- either by allowing such kind of external functions (I would guess that most compilers will not cause problems anyway but I've not checked yet)
+- or by introducing a build-in function (which then needs to be quickly implemented by the tools)
+ 
+Since this issue is quite important for MCC160 I would suggest we add it to the agenda for the TTCN-3/Tools meeting next week."
+
+
+
+ + + + + + + + + + +
+ (0008664) +
+ Gyorgy Rethy    +
+ 27-05-2009 14:53    +
+ 		+ + + + +
+ From a mail received from Wolfgang:
+"along the discussions about value returning functions being used in templates I read in the spec again and found the following in 16.1.4:
+
+         
+        "Value returning functions can be called during communication operations (in templates, template fields or in-line
+        templates) ...
+        To avoid side effects ... the following operations shall not be used in functions called in the cases specified above:
+        ...
+        e) Calling external functions (see notes 4 and 6).
+        ...
+        NOTE 4: Calling of external functions, rnd, running, alive, read, setverdict, and writing to component
+        variables is illegal because it may lead to different results of subsequent evaluations of the same snapshot,
+        thus, e.g. rendering deadlock detection impossible.
+        ...
+        NOTE 6: Restrictions except the limitation on the use of out or inout parameterization apply recursively, i.e. it
+        is disallowed to use them directly, or via an arbitrary long chain of function invocations.
+        ..."
+
+That clashes with our current preliminary solution for the __TESTCASE__ issue:
+Here we have: Template calling TTCN function calling external function (the latter one returns the test case name).
+
+Now - acc. to my interpretation - this is not correct since indirectly an external function is used in the template.
+On the other hand is the argumentation as given above hard to follow in our case (our external fx_GetCurrentTestcaseName will never cause problems as mentioned)
+ 
+In any case we need a solution
+- either by allowing such kind of external functions (I would guess that most compilers will not cause problems anyway but I've not checked yet)
+- or by introducing a build-in function (which then needs to be quickly implemented by the tools)
+ 
+Since this issue is quite important for MCC160 I would suggest we add it to the agenda for the TTCN-3/Tools meeting next week."
+
+
+
+ + + + + + + + + + +
+ (0008808) +
+ Tibor Csöndes    +
+ 01-07-2009 15:16    +
+ 		+ + + + +
+ According to the minutes of CR resolution meeting (49TD13r2) a new pre-defined function has suggested (testcasename) and not a __TESTCASE___ macro.
+
+
+
+ + + + + + + + + + +
+ (0008825) +
+ Gyorgy Rethy    +
+ 03-07-2009 11:12    +
+ 		+ + + + +
+ In ~v2: editorial amendments and more example. The updated version is OK with me.
+
+
+
+ + + + + + + + + + +
+ (0008828) +
+ Tibor Csöndes    +
+ 03-07-2009 12:15    +
+ 		+ + + + +
+ Editorials changes, v3 uploaded.
+
+
+
+ + + + + + + + + + +
+ (0008885) +
+ Ina Schieferdecker    +
+ 10-07-2009 11:01    +
+ 		+ + + + +
+ As discussed:
+
+- added testcasename to 16.1.2
+
+- made testcasename returing "" if not testcase is executing
+
+- added qualified and unqualified name as definition
+
+- made testcasename returning unqualified name
+
+
+
+ + + + + + + + + + +
+ (0008886) +
+ Gyorgy Rethy    +
+ 10-07-2009 12:13    +
+ 		+ + + + +
+ OK, just a minor editorial, corrected in CR5171_testcasename_v5.doc: the dot is added between <module name> and <global definition name> in <module name>.<global definition name>.<local definition name>
+
+ + diff --git a/docs/mantis/CR5174.md b/docs/mantis/CR5174.md new file mode 100644 index 0000000000000000000000000000000000000000..82a011ac0a299896f44c81ee1fcf9c6b2dddf11d --- /dev/null +++ b/docs/mantis/CR5174.md @@ -0,0 +1,383 @@ + + + + + + + + + + + + + 0005174: Test case termination in case of fatal errors: function called by templates - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005174Part 01: TTCN-3 Core LanguageClarificationpublic12-05-2009 19:3425-03-2010 15:59
ReporterWolfgang Seka 
Assigned ToIna Schieferdecker 
PriorityhighSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.2.1 (published 2010-07)Fixed in Versionv4.2.1 (published 2010-07) 
Clause Reference(s)TTCN-3 Core Language: cl. 16.1.4 and 21.2
Source (company - Author)     MCC160
Summary0005174: Test case termination in case of fatal errors: function called by templates
DescriptionWhen there is a fatal error in function which is running on a component or called by a function running on a component the component may be terminated by "self.kill".
+But there are functions which may be used by templates as well.
+
+Typical use cases are conversion functions which may be used on different components as well as within templates.
+
+Currently acc. to the core language spec (cl. 16.1.4a)) a function cannot use "self.kill" when being used in a template and there is also no way to query whether the function is called by a template or another function.
+
+Possible solutions are
+1. introduction of a "running on a component" operation and allowing "self.kill" in case of not being in a template
+2. buidin function for immediate termination of the whole test case with verdict "error"
+
+Note: A test case writer providing a function might not be aware that this function may be used in a template (missing of "runs on" is no criteria) and a test case writer using a function in a template in general is not aware of whether the functions directly or indirectly uses e.g. "self.kill"
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc Resolution-CR5174-Part1-091209.doc (161,280) 09-12-2009 10:46
http://oldforge.etsi.org/mantis/file_download.php?file_id=2303&type=bug
doc Resolution-CR5174-Part4-091209.doc (276,480) 09-12-2009 10:47
http://oldforge.etsi.org/mantis/file_download.php?file_id=2304&type=bug
doc CR5174_part6.doc (131,584) 25-03-2010 07:10
http://oldforge.etsi.org/mantis/file_download.php?file_id=2355&type=bug
Issue History
Date ModifiedUsernameFieldChange
12-05-2009 19:34Wolfgang SekaNew Issue
12-05-2009 19:34Wolfgang SekaClause Reference(s) => TTCN-3 Core Language: cl. 16.1.4 and 21.2
12-05-2009 19:34Wolfgang SekaSource (company - Author) => MCC160
30-06-2009 09:39Ina SchieferdeckerProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
30-06-2009 09:40Ina SchieferdeckerStatusnew => assigned
30-06-2009 09:40Ina SchieferdeckerAssigned To => Jens Grabowski
30-06-2009 10:20Ina SchieferdeckerCategoryTTCN-3 Core Language => Clarification
30-06-2009 10:20Ina SchieferdeckerTarget Version => Edition 4.2.1 (not yet published)
09-12-2009 10:46Jens GrabowskiFile Added: Resolution-CR5174-Part1-091209.doc
09-12-2009 10:47Jens GrabowskiFile Added: Resolution-CR5174-Part4-091209.doc
09-12-2009 10:48Jens GrabowskiNote Added: 0009112
09-12-2009 10:49Jens GrabowskiAssigned ToJens Grabowski => Gyorgy Rethy
18-03-2010 07:34Ina SchieferdeckerTarget VersionEdition 4.2.1 (not yet published) => Edition 5.1.1 (not yet published)
22-03-2010 16:48Gyorgy RethyResolutionopen => fixed
22-03-2010 16:48Gyorgy RethyTarget VersionEdition 4.3.1 (not yet published) => Edition 4.2.1 (not yet published)
22-03-2010 16:51Gyorgy RethyNote Added: 0009245
22-03-2010 16:51Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
22-03-2010 16:51Gyorgy RethyStatusassigned => resolved
23-03-2010 12:56Gyorgy RethyNote Added: 0009259
23-03-2010 12:56Gyorgy RethyAssigned ToIna Schieferdecker => Jacob Wieland - Spirent
23-03-2010 12:56Gyorgy RethyStatusresolved => assigned
23-03-2010 12:58Gyorgy RethyPrioritynormal => high
23-03-2010 12:58Gyorgy RethyNote Edited: 0009259
23-03-2010 15:11Jacob Wieland - SpirentNote Added: 0009263
23-03-2010 15:13Jacob Wieland - SpirentNote Edited: 0009263
24-03-2010 14:40Ina SchieferdeckerNote Added: 0009283
24-03-2010 16:31Jacob Wieland - SpirentNote Added: 0009287
24-03-2010 16:46Gyorgy RethyNote Added: 0009289
24-03-2010 18:37Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Ina Schieferdecker
25-03-2010 07:10Ina SchieferdeckerFile Added: CR5174_part6.doc
25-03-2010 07:11Ina SchieferdeckerNote Added: 0009291
25-03-2010 07:12Ina SchieferdeckerNote Edited: 0009291
25-03-2010 07:13Ina SchieferdeckerAssigned ToIna Schieferdecker => Jens Grabowski
25-03-2010 07:13Ina SchieferdeckerFixed in Version => Edition 4.2.1 (not yet published)
25-03-2010 13:04Jens GrabowskiAssigned ToJens Grabowski => Ina Schieferdecker
25-03-2010 15:33Gyorgy RethyNote Added: 0009315
25-03-2010 15:33Gyorgy RethyStatusassigned => resolved
25-03-2010 15:59Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009112) +
+ Jens Grabowski    +
+ 09-12-2009 10:48    +
+ 		+ + + + +
+ Resolution follows proposal 2. in the CR description.
+
+Assigned to György for proofreading.
+
+
+
+ + + + + + + + + + +
+ (0009245) +
+ Gyorgy Rethy    +
+ 22-03-2010 16:51    +
+ 		+ + + + +
+ Proposed solution is OK with me.
+
+
+
+ + + + + + + + + + +
+ (0009259) +
+ Gyorgy Rethy    +
+ 23-03-2010 12:56    +
(edited on: 23-03-2010 12:58)
+ 		+ + + + +
+ Jacob to add TCI extensions needed to add the feature.
+
+
+
+
+
+ + + + + + + + + + +
+ (0009263) +
+ Jacob Wieland - Spirent    +
+ 23-03-2010 15:11    +
(edited on: 23-03-2010 15:13)
+ 		+ + + + +
+ In part 6 (TCI) description, we need to define two new operations:
+
+TciCDProvided.tciStopTestCaseReq(in TString message)
+in parameters: message - A string value, i.e. the message to be logged.
+return value: void
+description: Shall be called by the TE when the TTCN-3 statement testcase.stop() will be executed within the test case.
+
+TciCDRequired.tciStopTestCase(in TString message)
+in parameters: message - A string value, i.e. the message to be logged.
+return value: void
+description: This operation shall be called by the CH at the local TE of the MTC when at a remote TE a provided tciStopTestCaseReq has been called.
+The TE shall set the overall verdict to error with the given message as reason and stop the running behaviour on the MTC (which shall lead to the stopping of all ptcs, as well).
+
+Also, the table relating TTCN-3 operations with Tci-Methods needs two new entries and all the language mappings need two new entries for the mapped functions as well.
+
+
+
+
+
+ + + + + + + + + + +
+ (0009283) +
+ Ina Schieferdecker    +
+ 24-03-2010 14:40    +
+ 		+ + + + +
+ STF decided not to add additional CH operations as the testcase.stop functionality can be realized by the TE by setting error verdict, getting the MTC and stopping the MTC.
+
+In order to make that visible in the TLI log, an additional verdict constant is introduced: FATAL representing user-generated test case errors.
+
+In addition, the optional parameter of the testcase.stop goes to the reason parameter of the TLI setverdict operation.
+
+
+
+ + + + + + + + + + +
+ (0009287) +
+ Jacob Wieland - Spirent    +
+ 24-03-2010 16:31    +
+ 		+ + + + +
+ When the testcase.stop operation is invoked from the TE, the following actions need to be taken by the TE:
+- the overall verdict should be set to user_error with the message given to the invocation of the testcase.stop() operation as parameter as the verdict reason
+- a reference to the mtc should be obtained by invoking triGetMtcReq() in the CH interface
+- the mtc should be stopped by invoking triStopTestComponentReq() in the CH with the obtained reference to the mtc.
+
+
+
+ + + + + + + + + + +
+ (0009289) +
+ Gyorgy Rethy    +
+ 24-03-2010 16:46    +
+ 		+ + + + +
+ The new verdict constant should not be called FATAL (thi was rather an explanation from MC160, why they want this feature) but USER_ERROR. This is more expressive as in fact with the new operation we give the possibility to he user to invoke a testcase error from the code; but have no possibility to check if the cause is really fatal error from the test case logic point of view).
+
+
+
+ + + + + + + + + + +
+ (0009291) +
+ Ina Schieferdecker    +
+ 25-03-2010 07:11    +
(edited on: 25-03-2010 07:12)
+ 		+ + + + +
+ Part 1 implemented, part 6 resolved:
+
+- USER_ERROR defined as additional verdict
+
+- testcase.stop as a sequence of TCI operations explained
+
+- use of tliTcTerminated to log testcase.stop
+
+assigned to Jens for proofreading
+
+
+
+
+
+ + + + + + + + + + +
+ (0009315) +
+ Gyorgy Rethy    +
+ 25-03-2010 15:33    +
+ 		+ + + + +
+ Looked at, OK with me.
+
+ + diff --git a/docs/mantis/CR5175.md b/docs/mantis/CR5175.md new file mode 100644 index 0000000000000000000000000000000000000000..06f3f27b465a3a2d8eaf07dd3575998820673573 --- /dev/null +++ b/docs/mantis/CR5175.md @@ -0,0 +1,117 @@ + + + + + + + + + + + + + 0005175: Overloaded Function does NOT support - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005175Part 01: TTCN-3 Core LanguageNew Featurepublic13-05-2009 22:3607-12-2009 14:47
ReporterMing Shang 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionwon't fix 
PlatformOSOS Version
Product Versionv3.4.1 (published 2008-09) 
Target Versionv4.2.1 (published 2010-07)Fixed in Versionv4.2.1 (published 2010-07) 
Clause Reference(s)16.1
Source (company - Author)     
Summary0005175: Overloaded Function does NOT support
DescriptionWhen I define the first function with name `buildRegisterRequest` as follows:
+
+function buildRegisterRequest(
+  in integer StatusCode, in charstring ReasonPhrase) return integer
+
+ 
+But when I try to define another one with the same function name but with different parameter specification:
+
+function buildRegisterRequest(in integer StatusCode) return integer
+
+
+I got the following error:
+
+[ERROR]: 'buildRegisterRequest' is already declared
+
+
+It would be better that overloaded function just like in C++ is supported in TTCN.
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Fileszip OverloadingExamples.zip (2,913) 09-07-2009 09:05
http://oldforge.etsi.org/mantis/file_download.php?file_id=2196&type=bug
Issue History
Date ModifiedUsernameFieldChange
13-05-2009 22:36Ming ShangNew Issue
13-05-2009 22:36Ming ShangStatusnew => assigned
13-05-2009 22:36Ming ShangAssigned To => Ina Schieferdecker
13-05-2009 22:36Ming ShangClause Reference(s) => 16.1
13-05-2009 22:36Ming ShangSource (company - Author) =>
09-07-2009 09:05Gyorgy RethyFile Added: OverloadingExamples.zip
09-07-2009 09:10Gyorgy RethyNote Added: 0008878
09-07-2009 14:16Ina SchieferdeckerNote Added: 0008883
09-07-2009 14:16Ina SchieferdeckerResolutionopen => won't fix
09-07-2009 14:16Ina SchieferdeckerStatusassigned => closed
07-12-2009 14:47Ina SchieferdeckerFixed in Version => Edition 4.2.1 (not yet published)
07-12-2009 14:47Ina SchieferdeckerTarget Version => Edition 4.2.1 (not yet published)
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0008878) +
+ Gyorgy Rethy    +
+ 09-07-2009 09:10    +
+ 		+ + + + +
+ OverloadingExamples.zip:
+Contains some example overloaded functions and examples of calling them. Complications are self-explaining, though, the "ahhh, I have forgotten the last parameter" case is even not covered.
+
+
+
+ + + + + + + + + + +
+ (0008883) +
+ Ina Schieferdecker    +
+ 09-07-2009 14:16    +
+ 		+ + + + +
+ This CR is rejected because of the reasons given in the examples (see zip file).
+
+You may however consider to use function parameters with default values (see 5.4.1 for details) which provide a similar feature and could solve your issue, though in another way.
+
+ + diff --git a/docs/mantis/CR5208.md b/docs/mantis/CR5208.md new file mode 100644 index 0000000000000000000000000000000000000000..97ac17689c8ef2d349b9e3335b1f91b03f760191 --- /dev/null +++ b/docs/mantis/CR5208.md @@ -0,0 +1,63 @@ + + + + + + + + + + + + + 0005208: Wrong reference to X.680 pattern constraint - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 07: Using ASN.1 with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005208Part 07: Using ASN.1 with TTCN-3Editorialpublic28-05-2009 09:4407-12-2009 14:54
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.3.2 (published 2008-04) 
Target Versionv4.2.1 (published 2010-07)Fixed in Versionv4.2.1 (published 2010-07) 
Clause Reference(s)9.1
Source (company - Author)L.M.Ericsson
Summary0005208: Wrong reference to X.680 pattern constraint
DescriptionIn clause 9.1 item 4), the correct reference shall point to clause 47.9 "Pattern constraint" of X.680 (instead of clause 48.9).
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
28-05-2009 09:44Gyorgy RethyNew Issue
28-05-2009 09:44Gyorgy RethyStatusnew => assigned
28-05-2009 09:44Gyorgy RethyAssigned To => Gyorgy Rethy
28-05-2009 09:44Gyorgy RethyClause Reference(s) => 9.1
28-05-2009 09:44Gyorgy RethySource (company - Author) => L.M.Ericsson
28-05-2009 09:46Gyorgy RethyNote Added: 0008665
28-05-2009 09:46Gyorgy RethyStatusassigned => closed
28-05-2009 12:09Gyorgy RethyStatusclosed => feedback
28-05-2009 12:09Gyorgy RethyResolutionopen => reopened
28-05-2009 12:09Gyorgy RethyStatusfeedback => closed
28-05-2009 12:09Gyorgy RethyResolutionreopened => fixed
28-05-2009 12:09Gyorgy RethyFixed in Version => Edition 4.2.1 (not yet published)
07-12-2009 14:54Ina SchieferdeckerTarget Version => Edition 4.2.1 (not yet published)
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0008665) +
+ Gyorgy Rethy    +
+ 28-05-2009 09:46    +
+ 		+ + + + +
+ Implemented in master copy.
+
+ + diff --git a/docs/mantis/CR5209.md b/docs/mantis/CR5209.md new file mode 100644 index 0000000000000000000000000000000000000000..fd0709cafa0ea72b01ae1376b65c3e985ff23952 --- /dev/null +++ b/docs/mantis/CR5209.md @@ -0,0 +1,63 @@ + + + + + + + + + + + + + 0005209: Reference to note f is missing in table 4 (to open types) - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 07: Using ASN.1 with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005209Part 07: Using ASN.1 with TTCN-3Editorialpublic28-05-2009 09:5507-12-2009 14:53
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.3.2 (published 2008-04) 
Target Versionv4.2.1 (published 2010-07)Fixed in Versionv4.2.1 (published 2010-07) 
Clause Reference(s)9.1
Source (company - Author)L.M.Ericsson
Summary0005209: Reference to note f is missing in table 4 (to open types)
DescriptionThe reference to note f is missing in the first cell of row 15 (including the header row), "open type". Add "(see f)" to the cell.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
28-05-2009 09:55Gyorgy RethyNew Issue
28-05-2009 09:55Gyorgy RethyStatusnew => assigned
28-05-2009 09:55Gyorgy RethyAssigned To => Gyorgy Rethy
28-05-2009 09:55Gyorgy RethyClause Reference(s) => 9.1
28-05-2009 09:55Gyorgy RethySource (company - Author) => L.M.Ericsson
28-05-2009 09:57Gyorgy RethyNote Added: 0008666
28-05-2009 09:57Gyorgy RethyStatusassigned => closed
28-05-2009 12:10Gyorgy RethyStatusclosed => feedback
28-05-2009 12:10Gyorgy RethyResolutionopen => reopened
28-05-2009 12:11Gyorgy RethyStatusfeedback => closed
28-05-2009 12:11Gyorgy RethyResolutionreopened => fixed
28-05-2009 12:11Gyorgy RethyProduct Version => Edition 3.3.2
28-05-2009 12:11Gyorgy RethyFixed in Version => Edition 4.2.1 (not yet published)
07-12-2009 14:53Ina SchieferdeckerTarget Version => Edition 4.2.1 (not yet published)
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0008666) +
+ Gyorgy Rethy    +
+ 28-05-2009 09:57    +
+ 		+ + + + +
+ Implemented in master copy.
+
+ + diff --git a/docs/mantis/CR5210.md b/docs/mantis/CR5210.md new file mode 100644 index 0000000000000000000000000000000000000000..71fbbb0ac46c02c19045589a0223723a714c6520 --- /dev/null +++ b/docs/mantis/CR5210.md @@ -0,0 +1,63 @@ + + + + + + + + + + + + + 0005210: Wrong reference in clause A.2 - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 07: Using ASN.1 with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005210Part 07: Using ASN.1 with TTCN-3Editorialpublic28-05-2009 11:5607-12-2009 14:53
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.3.2 (published 2008-04) 
Target Versionv4.2.1 (published 2010-07)Fixed in Versionv4.2.1 (published 2010-07) 
Clause Reference(s)A.2
Source (company - Author)L.M.Ericsson
Summary0005210: Wrong reference in clause A.2
DescriptionReference to clause 11.18 of ITU-T Recommendation X.680 should be to clause 11.27 (which is listing the ASN.1 keywords.)
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
28-05-2009 11:56Gyorgy RethyNew Issue
28-05-2009 11:56Gyorgy RethyStatusnew => assigned
28-05-2009 11:56Gyorgy RethyAssigned To => Gyorgy Rethy
28-05-2009 11:56Gyorgy RethyClause Reference(s) => A.2
28-05-2009 11:56Gyorgy RethySource (company - Author) => L.M.Ericsson
28-05-2009 12:08Gyorgy RethyNote Added: 0008674
28-05-2009 12:08Gyorgy RethyStatusassigned => closed
28-05-2009 12:08Gyorgy RethyResolutionopen => fixed
28-05-2009 12:11Gyorgy RethyStatusclosed => feedback
28-05-2009 12:11Gyorgy RethyResolutionfixed => reopened
28-05-2009 12:12Gyorgy RethyStatusfeedback => closed
28-05-2009 12:12Gyorgy RethyResolutionreopened => fixed
28-05-2009 12:12Gyorgy RethyProduct Version => Edition 3.3.2
28-05-2009 12:12Gyorgy RethyFixed in Version => Edition 4.2.1 (not yet published)
07-12-2009 14:53Ina SchieferdeckerTarget Version => Edition 4.2.1 (not yet published)
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0008674) +
+ Gyorgy Rethy    +
+ 28-05-2009 12:08    +
+ 		+ + + + +
+ Corrected in master copy.
+
+ + diff --git a/docs/mantis/CR5212.md b/docs/mantis/CR5212.md new file mode 100644 index 0000000000000000000000000000000000000000..c14dba3cd2f8e59a71f48d6ac03cf0826ddb7bcb --- /dev/null +++ b/docs/mantis/CR5212.md @@ -0,0 +1,103 @@ + + + + + + + + + + + + + 0005212: Check numbers of changed core BNF productions in A.2 - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 07: Using ASN.1 with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005212Part 07: Using ASN.1 with TTCN-3Editorialpublic28-05-2009 12:1622-03-2010 17:13
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PriorityhighSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.3.2 (published 2008-04) 
Target Versionv4.2.1 (published 2010-07)Fixed in Versionv4.2.1 (published 2010-07) 
Clause Reference(s)A.2
Source (company - Author)L.M.Ericsson
Summary0005212: Check numbers of changed core BNF productions in A.2
DescriptionAt the final editing phase the numbers of the core BNF productions that are changed by Part-7 shall be cross-checked.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
28-05-2009 12:16Gyorgy RethyNew Issue
28-05-2009 12:16Gyorgy RethyStatusnew => assigned
28-05-2009 12:16Gyorgy RethyAssigned To => Gyorgy Rethy
28-05-2009 12:16Gyorgy RethyClause Reference(s) => A.2
28-05-2009 12:16Gyorgy RethySource (company - Author) => L.M.Ericsson
30-06-2009 10:23Ina SchieferdeckerTarget Version => Edition 4.2.1 (not yet published)
01-07-2009 11:05Gyorgy RethyNote Added: 0008804
18-03-2010 07:44Ina SchieferdeckerTarget VersionEdition 4.2.1 (not yet published) => Edition 5.1.1 (not yet published)
22-03-2010 16:28Gyorgy RethyPrioritynormal => high
22-03-2010 16:28Gyorgy RethyTarget VersionEdition 4.3.1 (not yet published) => Edition 4.2.1 (not yet published)
22-03-2010 17:12Gyorgy RethyNote Added: 0009246
22-03-2010 17:13Gyorgy RethyStatusassigned => closed
22-03-2010 17:13Gyorgy RethyResolutionopen => fixed
22-03-2010 17:13Gyorgy RethyFixed in Version => Edition 4.2.1 (not yet published)
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0008804) +
+ Gyorgy Rethy    +
+ 01-07-2009 11:05    +
+ 		+ + + + +
+ To be done in around November, when the final draft of Part-1 is available.
+
+
+
+ + + + + + + + + + +
+ (0009246) +
+ Gyorgy Rethy    +
+ 22-03-2010 17:12    +
+ 		+ + + + +
+ BNF rules
+51.ValueOrRange updated,
+144. LowerBound updated & -> 148. ,
+145. UpperBound -> 149.
+438. PredefinedType -> 455.
+459. PredefinedValue -> 474.
+Done in v4.1.5
+
+ + diff --git a/docs/mantis/CR5213.md b/docs/mantis/CR5213.md new file mode 100644 index 0000000000000000000000000000000000000000..a30c2ddea6825f0825c3e70dfee8182503602e73 --- /dev/null +++ b/docs/mantis/CR5213.md @@ -0,0 +1,63 @@ + + + + + + + + + + + + + 0005213: Wrong reference in clause 9.1 item 7 - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 07: Using ASN.1 with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005213Part 07: Using ASN.1 with TTCN-3Editorialpublic28-05-2009 12:2007-12-2009 14:53
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.3.2 (published 2008-04) 
Target Versionv4.2.1 (published 2010-07)Fixed in Versionv4.2.1 (published 2010-07) 
Clause Reference(s)9.1
Source (company - Author)L.M.Ericsson
Summary0005213: Wrong reference in clause 9.1 item 7
DescriptionReference to clause 32.5 of ITU-T Recommendation X.680 should be to clause 33.5.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
28-05-2009 12:20Gyorgy RethyNew Issue
28-05-2009 12:20Gyorgy RethyStatusnew => assigned
28-05-2009 12:20Gyorgy RethyAssigned To => Gyorgy Rethy
28-05-2009 12:20Gyorgy RethyClause Reference(s) => 9.1
28-05-2009 12:20Gyorgy RethySource (company - Author) => L.M.Ericsson
28-05-2009 12:22Gyorgy RethyNote Added: 0008676
28-05-2009 12:22Gyorgy RethyStatusassigned => closed
28-05-2009 12:22Gyorgy RethyResolutionopen => fixed
28-05-2009 12:22Gyorgy RethyProduct Version => Edition 3.3.2
28-05-2009 12:22Gyorgy RethyFixed in Version => Edition 4.2.1 (not yet published)
07-12-2009 14:53Ina SchieferdeckerTarget Version => Edition 4.2.1 (not yet published)
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0008676) +
+ Gyorgy Rethy    +
+ 28-05-2009 12:22    +
+ 		+ + + + +
+ Corrected in master copy
+
+ + diff --git a/docs/mantis/CR5214.md b/docs/mantis/CR5214.md new file mode 100644 index 0000000000000000000000000000000000000000..bcc6c6fb856f456aaf2206240ad143d57f11647e --- /dev/null +++ b/docs/mantis/CR5214.md @@ -0,0 +1,63 @@ + + + + + + + + + + + + + 0005214: Wrong reference in clause 9.1 item 9 - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 07: Using ASN.1 with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005214Part 07: Using ASN.1 with TTCN-3Editorialpublic28-05-2009 12:2707-12-2009 14:53
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.3.2 (published 2008-04) 
Target Versionv4.2.1 (published 2010-07)Fixed in Versionv4.2.1 (published 2010-07) 
Clause Reference(s)9.1
Source (company - Author)L.M.Ericsson
Summary0005214: Wrong reference in clause 9.1 item 9
DescriptionReference to clause 39.5 of ITU-T Recommendation X.680 should be to clause 40.5.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
28-05-2009 12:27Gyorgy RethyNew Issue
28-05-2009 12:27Gyorgy RethyStatusnew => assigned
28-05-2009 12:27Gyorgy RethyAssigned To => Gyorgy Rethy
28-05-2009 12:27Gyorgy RethyClause Reference(s) => 9.1
28-05-2009 12:27Gyorgy RethySource (company - Author) => L.M.Ericsson
28-05-2009 12:33Gyorgy RethyNote Added: 0008677
28-05-2009 12:33Gyorgy RethyStatusassigned => closed
28-05-2009 12:33Gyorgy RethyResolutionopen => fixed
28-05-2009 12:33Gyorgy RethyFixed in Version => Edition 4.2.1 (not yet published)
07-12-2009 14:53Ina SchieferdeckerTarget Version => Edition 4.2.1 (not yet published)
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0008677) +
+ Gyorgy Rethy    +
+ 28-05-2009 12:33    +
+ 		+ + + + +
+ Corrected in master version
+
+ + diff --git a/docs/mantis/CR5215.md b/docs/mantis/CR5215.md new file mode 100644 index 0000000000000000000000000000000000000000..7ff1a52484c3a1b26cf44e38deacf55b8998aa46 --- /dev/null +++ b/docs/mantis/CR5215.md @@ -0,0 +1,137 @@ + + + + + + + + + + + + + 0005215: Wrong references in clause 9.1 - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 07: Using ASN.1 with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005215Part 07: Using ASN.1 with TTCN-3Editorialpublic28-05-2009 12:3217-07-2009 15:59
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.3.2 (published 2008-04) 
Target Versionv4.2.1 (published 2010-07)Fixed in Versionv4.2.1 (published 2010-07) 
Clause Reference(s)9.1
Source (company - Author)L.M.Ericsson
Summary0005215: Wrong references in clause 9.1
DescriptionCheck the clause no.s in the references to X.680 clauses in transformation rule items.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
child of 0005269closed Gyorgy Rethy Language specification for ASN.1:2009 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
28-05-2009 12:32Gyorgy RethyNew Issue
28-05-2009 12:32Gyorgy RethyStatusnew => assigned
28-05-2009 12:32Gyorgy RethyAssigned To => Gyorgy Rethy
28-05-2009 12:32Gyorgy RethyClause Reference(s) => 9.1
28-05-2009 12:32Gyorgy RethySource (company - Author) => L.M.Ericsson
28-05-2009 12:39Gyorgy RethyNote Added: 0008678
28-05-2009 12:42Gyorgy RethyNote Added: 0008679
28-05-2009 12:42Gyorgy RethyNote Edited: 0008679
28-05-2009 12:43Gyorgy RethyNote Edited: 0008678
30-06-2009 10:23Ina SchieferdeckerTarget Version => Edition 4.2.1 (not yet published)
08-07-2009 14:43Gyorgy RethyRelationship addedchild of 0005269
17-07-2009 15:59Gyorgy RethyStatusassigned => closed
17-07-2009 15:59Gyorgy RethyNote Added: 0008900
17-07-2009 15:59Gyorgy RethyResolutionopen => fixed
17-07-2009 15:59Gyorgy RethyFixed in Version => Edition 4.2.1 (not yet published)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0008678) +
+ Gyorgy Rethy    +
+ 28-05-2009 12:39    +
(edited on: 28-05-2009 12:43)
+ 		+ + + + +
+ In item 8)
+ref. to clause 33.5 has been corrected to 34.5
+
+
+
+
+
+ + + + + + + + + + +
+ (0008679) +
+ Gyorgy Rethy    +
+ 28-05-2009 12:42    +
+ 		+ + + + +
+ In item 15)
+ref. to clause 36.2 is corrected to 37.2 and ref. to clause 36.4. to 37.4.
+
+
+
+
+
+ + + + + + + + + + +
+ (0008900) +
+ Gyorgy Rethy    +
+ 17-07-2009 15:59    +
+ 		+ + + + +
+ fixed in v4.1.2, all refernces in clause 9.1 are checked and corrected, if needed
+
+ + diff --git a/docs/mantis/CR5220.md b/docs/mantis/CR5220.md new file mode 100644 index 0000000000000000000000000000000000000000..5f848b6c35c29bce770f957b28c675865df057a1 --- /dev/null +++ b/docs/mantis/CR5220.md @@ -0,0 +1,372 @@ + + + + + + + + + + + + + 0005220: TCI C++ Mapping Issues - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005220Part 06: TTCN-3 Control InterfaceClarificationpublic02-06-2009 14:4418-03-2010 07:40
ReporterIna Schieferdecker 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.2.1 (published 2010-07)Fixed in Versionv4.2.1 (published 2010-07) 
Clause Reference(s)TCI C++ mapping clause
Source (company - Author)INRIA, France
Summary0005220: TCI C++ Mapping Issues
Description1. The C++ mapping introduced in this new version of the interface uses
+design conventions that are Java-like and are not easily interoperable
+with the C++ standard libraries.
+eg:
+
+> class TciModuleIdList {
+> public:
+> virtual ~TciModuleIdList();
+> virtual Tsize size () const =0;
+> virtual Tboolean isEmpty () const =0;
+--> should be virtual Tboolean empty() const =0;
+
+> virtual const std::vector< const TciModuleId * > & getComponents ()
+> const =0;
+--> this puts too much design constaints on the implementation of the interface
+    (especially the TciModuleId needs to be stored in a vector of pointers)
+
+> virtual const TciModuleId &get (Tsize p_index) const =0;
+--> should be :
+    virtual const TciModuleId &at (Tsize p_index) const =0;
+    virtual const TciModuleId operator[] (Tsize p_index) const =0;
+
+> virtual void clear ()=0;
+> virtual void add (const TciModuleId &comp)=0;
+--> should be :
+    virtual void push_back (const TciModuleId &comp)=0;
+
+> virtual Tboolean equals (const TciModuleIdList &midList) const =0;
+--> should be :
+    virtual Tboolean operator== (const TciModuleIdList &midList) const =0;
+
+> virtual TciModuleIdList * cloneModuleIdList () const =0;
+--> should be : virtual TciModuleIdList * clone () const =0;
+
+> virtual Tboolean operator< (const TciModuleIdList &midList) const =0;
+> }
+
+2. Section 10.5 is self-contradictory
+> Pure virtual classes have been used, following the concept of an interface.
+> The Standard Template Library (STL) has been used as it is a standardized
+> way of using container classes, and iterators, such as lists. All classes
+> define the operator "<" for easy insertion in STL containers.
+
+The STL containers require that the contained class is
+copy-constructible. However the classes in the C++ mapping are not
+copy-constructible (the are abstract base classes containing pure
+virtual functions), therefore they cannot be used in STL containers.
+Moreover, some STL containers require the operator '==' instead of '<'
+(eg: unordered_set and unordered_map)
+
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Fileszip es_20187306v040102.zip (1,317,758) 18-03-2010 07:40
http://oldforge.etsi.org/mantis/file_download.php?file_id=2340&type=bug
Issue History
Date ModifiedUsernameFieldChange
02-06-2009 14:44Ina SchieferdeckerNew Issue
02-06-2009 14:44Ina SchieferdeckerStatusnew => assigned
02-06-2009 14:44Ina SchieferdeckerAssigned To => Ina Schieferdecker
02-06-2009 14:44Ina SchieferdeckerClause Reference(s) => TCI C++ mapping clause
02-06-2009 14:44Ina SchieferdeckerSource (company - Author) => INRIA, France
05-06-2009 11:40Anthony BaireNote Added: 0008724
05-06-2009 11:52Anthony BaireNote Added: 0008725
08-06-2009 13:54Jesús DomínguezNote Added: 0008730
10-06-2009 18:44Anthony BaireNote Added: 0008738
15-06-2009 14:15Raul AlfonsoNote Added: 0008770
30-06-2009 10:21Ina SchieferdeckerProjectTTCN-3 Change Requests => Part 06: TTCN-3 Control Interface
30-06-2009 10:21Ina SchieferdeckerCategoryTCI => Clarification
30-06-2009 10:21Ina SchieferdeckerTarget Version => Edition 4.2.1 (not yet published)
06-07-2009 15:48Anthony BaireNote Added: 0008847
06-07-2009 15:48Anthony BaireNote Edited: 0008847
18-03-2010 07:39Ina SchieferdeckerStatusassigned => resolved
18-03-2010 07:39Ina SchieferdeckerResolutionopen => fixed
18-03-2010 07:39Ina SchieferdeckerFixed in Version => Edition 4.2.1 (not yet published)
18-03-2010 07:40Ina SchieferdeckerFile Added: es_20187306v040102.zip
18-03-2010 07:40Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0008724) +
+ Anthony Baire    +
+ 05-06-2009 11:40    +
+ 		+ + + + +
+ Here is a proposal for the replacement for the getComponents() function (and the similar function founds in other container classes)
+> virtual const std::vector< const TciModuleId * > & getComponents () const =0;
+
+As stated before, this function should be removed because it puts too much design constaints on the implementation of the interface (it mandates that the object stores the TciModuleId list in a vector of pointers).
+
+In order to provide similar features, all the interface classes that provide access to a list of elements should support the Range concept, i.e: provide the following definitions:
+
+    typedef ##implementation_defined## const_iterator;
+    const_iterator begin() const;
+    const_iterator end() const;
+
+    The type of const_iterator is implementation defined. It shall comply with the InputIterator concept (http://www.cplusplus.com/reference/std/iterator/InputIterator/ [^]) and the dereferencement operator shall return a const reference on the contained object.
+    eg: - TciModuleList::const_iterator::operator*() shall return const TciModuleId&
+        - TciModuleList::const_iterator::operator->() shall return const TciModuleId*
+    
+
+
+Supporting the range concept allows inspecting easily the content of the objects using itarators.
+    eg. using the boost foreach library
+        #include <boost/foreach.hpp>
+        ...
+        TciModuleIdList& m_list;
+        ...
+        BOOST_FOREACH (const TciModuleId& id, m_list) {
+            ...
+        }
+    eg. using the range-based loops in the upcoming version of the c++ standard
+        TciModuleIdList& m_list;
+        ...
+        for (const TciModuleId& id : m_list) {
+            ...
+        }
+
+
+
+ + + + + + + + + + +
+ (0008725) +
+ Anthony Baire    +
+ 05-06-2009 11:52    +
+ 		+ + + + +
+ Regarding section 10.5, the following text should be removed (or possibly replaced with a paragraphe about the Range concept above if accepted):
+
+> The Standard Template Library (STL) has been used as it is a standardized
+> way of using container classes, and iterators, such as lists. All classes
+> define the operator "<" for easy insertion in STL containers
+
+
+The rationale for the deletion is that this paragraph is confusing since it is not possible to insert objects that are not copy-constructible into STL containers.
+
+[Actually this would be useable with a poiner container (eg. http://www.boost.org/doc/libs/1_39_0/libs/ptr_container/doc/ptr_container.html [^]). But since pointer containers are not yet standardised, I think it's better just not to mention it and remove the paragraph]
+
+
+
+ + + + + + + + + + +
+ (0008730) +
+ Jesús Domínguez    +
+ 08-06-2009 13:54    +
+ 		+ + + + +
+ After discussion on the phone with Anthony we understand the following things were agreed:
+
+- method "isEmpty" should be renamed to "empty"
+
+- method "getComponents" should be removed
+
+- method "get" to be changed to return a pointer (to use NULL if "p_index" is out of bounds)
+virtual const TciModuleId *get (Tsize p_index) const =0;
+
+- method "add" to be renamed to "push_back"
+
+- method "equals" to be substituted with operator "=="
+virtual Tboolean operator== (const TciModuleIdList &midList) const =0;
+
+- method "cloneXXX" to be renamed to "clone"
+
+- section 10.5 to be changed to give a better explanation
+
+
+About the begin,end methods we don't agree with adding them. It was mentioned with the getComponents method that we should not add design constraints. But if we add the "begin","end" or more C++ standard library methods we will obly to implement them (they are pure virtual), making them exactly like the STL containers. Wouldn't it be easier in that case to make directly a typedef to an STL class?
+
+
+
+ + + + + + + + + + +
+ (0008738) +
+ Anthony Baire    +
+ 10-06-2009 18:44    +
+ 		+ + + + +
+ Hi Jesus,
+
+
+defining some iterators is not a design constraint is the sense that it does not dictate the internal structure of the class.
+
+
+For example to implement TciModuleIdList a developper will have to represent internally this module list. There are lots of different ways he may want to do that (depending on the internal design of his runtime system) for example:
+
+* by storing references to a TciModuleId base object
+        std::vector<TciModuleId*> mModuleIdList; // -> using a STL vector of pointers
+    boost::ptr_vector<TciModuleId> mModuleIdList; // -> using a pointer container
+
+* by storing objects inherited from TciModuleId (eg. MyModuleId)
+    std::vector<MyModuleId> mModuleIdList // -> using a STL vector of MyModuleId
+        std::vector<MyModuleId*> mModuleIdList; // -> using a STL vector of pointers
+    boost::ptr_vector<MyModuleId> mModuleIdList; // -> using a pointer container
+
+* also if he's concerned by the execution speed, he may want no to use the default allocator so as to optimise memory allocations
+      std::vector<MyModuleId, boost::fast_pool_allocator<MyModuleId> > mModuleIdList;
+
+This is the reason why the getComponent() function is a strong design constraint, because it forces the developer to store the list as a std::vector<TciModuleId*>
+
+
+By opposition the iterators can be flexibly defined regardless the internal design of the class, and they don't introduce any overhead in the execution.
+
+
+
+ + + + + + + + + + +
+ (0008770) +
+ Raul Alfonso    +
+ 15-06-2009 14:15    +
+ 		+ + + + +
+ Hi Anthony,
+
+getComponents() or iterators (begin & end) isn’t the issue. We’re agreed with you about design restrictions in getComponents methods and defining some iterators isn’t a design restriction, but we aren’t agreed with you about add iterators (and begin and end methods) to the interface. Why? If these methods are included we are forcing to implement them and we think that the tci-inteface should only have methods to use in tci context, not in other context (stl algorithms). We use these objects with stl algorithms, but other implementations of these interfaces may not use the stl algorithms. We think that we shouldn’t force to someone to implement this methods.
+
+
+
+ + + + + + + + + + +
+ (0008847) +
+ Anthony Baire    +
+ 06-07-2009 15:48    +
+ 		+ + + + +
+ getComponents() puts a constraint on the internal design of the class: this affects the operation of the class as a whole. Adding iterators does not affect the internal design of the class but only its interfaces: other operations are not affected.
+
+
+Anyway, just removing getComponents() and not adding the iterators is an acceptable solution for us.
+
+
+
+ + diff --git a/docs/mantis/CR5224.md b/docs/mantis/CR5224.md new file mode 100644 index 0000000000000000000000000000000000000000..417a676e699863cc236b356220e36ca3d92358a3 --- /dev/null +++ b/docs/mantis/CR5224.md @@ -0,0 +1,1501 @@ + + + + + + + + + + + + + 0005224: Introducing dual faced ports - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Config & Deployment Support (ES 202 781)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005224Ext Pack: Config & Deployment Support (ES 202 781)New Featurepublic03-06-2009 10:2214-05-2013 15:24
ReporterGyorgy Rethy 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv1.2.1 (published 2013-06)Fixed in Versionv1.2.1 (published 2013-06) 
Clause Reference(s)new
Source (company - Author)L.M.Ericsson
TS version
Summary0005224: Introducing dual faced ports
DescriptionReal testing projects very oftem meats the problem that the same ATS shall be used in different test environments, i.e. the SUT is embedded in a simulated HW/OS environment during functional testing and using the real HW/OS in integration testing. These test environments normally require different adapters and most often even the adapter interface (TTCN-3 ports) does differ. A similar situation arise, when the same message sequence has to be moved from one type of interface to another (e.g. from MTP to SCTP). Today, to prevent re-writing the test cases themselves, so called mapping components are used. Mapping components are receiving messages from the "behaviour" components on their "upper" ports, map the information to the "down" port type and sends them; and vice versa in the opposite direction. This approach has several problems: in complex systems, where the number of "behaviour" TCs is n*10, it boosts the number of test components; this increases development and maintenance cost; complicates debugging and log analysis by producing a lots of extra logs.
+
+The proposal is to introduce "dual faced" TTCN-3 test ports, where the "upper" port definition is the one seen by TTCN-3 connect, map and communication operations, and the "down" port is the one seen by the adaptor. If the two differ, a set of conversion functions shall be defined that makes the mapping between the types in the upper and down ports. These functions are called implicitly by the TE at receving/sending operations.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0005417closed Ina Schieferdecker Part 01: TTCN-3 Core Language Support of parametrized map/unmap operation for full dynamic mapping 
Attached Filestxt CR 5224 proposal.txt (6,461) 01-09-2010 09:55
http://oldforge.etsi.org/mantis/file_download.php?file_id=2420&type=bug
txt CR 5224.txt (7,722) 01-12-2010 16:30
http://oldforge.etsi.org/mantis/file_download.php?file_id=2459&type=bug
doc CR_5224-proposal.doc (1,868,288) 28-09-2011 16:06
http://oldforge.etsi.org/mantis/file_download.php?file_id=2569&type=bug
zip CR_5224-proposal_v2.zip (675,597) 29-11-2011 15:28
http://oldforge.etsi.org/mantis/file_download.php?file_id=2609&type=bug
zip CR_5224-proposal_v3.zip (662,682) 30-11-2011 17:07
http://oldforge.etsi.org/mantis/file_download.php?file_id=2625&type=bug
docx CR_5224-proposal_v4.docx (950,480) 01-12-2011 09:32
http://oldforge.etsi.org/mantis/file_download.php?file_id=2633&type=bug
docx CR_5224-proposal_v5.docx (878,561) 01-12-2011 09:53
http://oldforge.etsi.org/mantis/file_download.php?file_id=2634&type=bug
docx CR_5224-proposal_v6.docx (976,987) 10-08-2012 14:48
http://oldforge.etsi.org/mantis/file_download.php?file_id=2721&type=bug
docx CR_5224-proposal_v6_BNFmodified.docx (36,809) 10-12-2012 11:03
http://oldforge.etsi.org/mantis/file_download.php?file_id=2756&type=bug
docx CR_5224-proposal_v7.docx (997,629) 10-12-2012 16:05
http://oldforge.etsi.org/mantis/file_download.php?file_id=2760&type=bug
docx CR_5224-proposal_v8_delta.docx (72,080) 12-12-2012 15:24
http://oldforge.etsi.org/mantis/file_download.php?file_id=2773&type=bug
docx CR_5224-proposal_v9_delta.docx (129,295) 13-12-2012 08:35
http://oldforge.etsi.org/mantis/file_download.php?file_id=2776&type=bug
docx CR_5224-proposal_v10.docx (138,537) 13-12-2012 17:54
http://oldforge.etsi.org/mantis/file_download.php?file_id=2777&type=bug
docx CR_5224-proposal_v11.docx (78,102) 18-12-2012 16:20
http://oldforge.etsi.org/mantis/file_download.php?file_id=2788&type=bug
Issue History
Date ModifiedUsernameFieldChange
03-06-2009 10:22Gyorgy RethyNew Issue
03-06-2009 10:22Gyorgy RethyStatusnew => assigned
03-06-2009 10:22Gyorgy RethyAssigned To => Ina Schieferdecker
03-06-2009 10:22Gyorgy RethyClause Reference(s) => new
03-06-2009 10:22Gyorgy RethySource (company - Author) => L.M.Ericsson
09-12-2009 13:52Ina SchieferdeckerNote Added: 0009117
09-12-2009 13:53Ina SchieferdeckerTarget Version => Edition 5.1.1 (not yet published)
04-01-2010 13:52Ina SchieferdeckerRelationship addedrelated to 0005417
22-03-2010 17:21Gyorgy RethyAssigned ToIna Schieferdecker =>
22-03-2010 17:21Gyorgy RethyStatusassigned => new
23-03-2010 12:55Gyorgy RethyAssigned To => Jacob Wieland - Spirent
23-03-2010 12:55Gyorgy RethyPrioritynormal => low
23-03-2010 12:55Gyorgy RethyStatusnew => assigned
23-03-2010 16:06Jacob Wieland - SpirentNote Added: 0009266
24-03-2010 18:34Jacob Wieland - SpirentFile Added: CR 5224 proposal.txt
24-03-2010 18:37Jacob Wieland - SpirentNote Added: 0009290
24-03-2010 18:37Jacob Wieland - SpirentStatusassigned => feedback
24-03-2010 20:16Jacob Wieland - SpirentFile Deleted: CR 5224 proposal.txt
24-03-2010 20:16Jacob Wieland - SpirentStatusfeedback => assigned
25-03-2010 00:24Jacob Wieland - SpirentFile Added: CR 5224 proposal.txt
25-03-2010 00:25Jacob Wieland - SpirentStatusassigned => feedback
25-03-2010 08:16Jacob Wieland - SpirentFile Deleted: CR 5224 proposal.txt
25-03-2010 08:27Jacob Wieland - SpirentFile Added: CR 5224 proposal.txt
26-03-2010 09:39Gyorgy RethyStatusfeedback => assigned
26-03-2010 09:40Gyorgy RethyNote Added: 0009320
01-07-2010 09:55Gyorgy RethyNote Added: 0009442
01-07-2010 11:31Jacob Wieland - SpirentNote Added: 0009447
01-09-2010 09:54Jacob Wieland - SpirentFile Deleted: CR 5224 proposal.txt
01-09-2010 09:55Jacob Wieland - SpirentFile Added: CR 5224 proposal.txt
01-09-2010 11:05Jens GrabowskiNote Added: 0009670
02-09-2010 14:13Jacob Wieland - SpirentNote Added: 0009699
02-09-2010 18:13Jacob Wieland - SpirentNote Added: 0009703
03-09-2010 10:59Jacob Wieland - SpirentNote Added: 0009707
03-09-2010 11:03Jacob Wieland - SpirentNote Edited: 0009707
03-09-2010 11:10Jacob Wieland - SpirentNote Edited: 0009699
29-11-2010 16:22Jacob Wieland - SpirentNote Added: 0009833
29-11-2010 16:28Jacob Wieland - SpirentNote Added: 0009834
30-11-2010 13:23Gyorgy RethyNote Added: 0009841
01-12-2010 16:30Jacob Wieland - SpirentFile Added: CR 5224.txt
01-12-2010 16:31Jacob Wieland - SpirentNote Added: 0009902
01-12-2010 16:31Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
03-12-2010 10:15Gyorgy RethyProjectPart 01: TTCN-3 Core Language => Ext Pack: Config & Deployment Support (ES 202 781)
03-12-2010 10:17Gyorgy RethyTarget VersionEdition 4.3.1 (not yet published) => v1.2.2
27-09-2011 14:07Gyorgy RethyTarget Versionv1.2.2 (interim) => v1.3.1
28-09-2011 16:06Jacob Wieland - SpirentFile Added: CR_5224-proposal.doc
28-09-2011 16:09Jacob Wieland - SpirentNote Added: 0010283
29-11-2011 14:50Gyorgy RethyFile Added: CR_5224-proposal_v2.zip
29-11-2011 14:55Gyorgy RethyFile Deleted: CR_5224-proposal_v2.zip
29-11-2011 15:08Gyorgy RethyNote Added: 0010404
29-11-2011 15:22Gyorgy RethyNote Edited: 0010404
29-11-2011 15:23Gyorgy RethyFile Added: CR_5224-proposal_v2.zip
29-11-2011 15:28Gyorgy RethyFile Deleted: CR_5224-proposal_v2.zip
29-11-2011 15:28Gyorgy RethyFile Added: CR_5224-proposal_v2.zip
29-11-2011 15:29Gyorgy RethyAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
29-11-2011 18:16Jacob Wieland - SpirentFile Added: CR_5224-proposal_v3.doc
29-11-2011 18:17Jacob Wieland - SpirentFile Deleted: CR_5224-proposal_v3.doc
29-11-2011 18:17Jacob Wieland - SpirentFile Added: CR5347_resolution_v3.zip
29-11-2011 18:20Jacob Wieland - SpirentNote Added: 0010406
29-11-2011 18:20Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
30-11-2011 13:47Jacob Wieland - SpirentFile Deleted: CR5347_resolution_v3.zip
30-11-2011 13:47Jacob Wieland - SpirentFile Added: CR_5224-proposal_v3.zip
30-11-2011 14:01Jacob Wieland - SpirentAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
30-11-2011 17:05Jacob Wieland - SpirentFile Deleted: CR_5224-proposal_v3.zip
30-11-2011 17:07Jacob Wieland - SpirentFile Added: CR_5224-proposal_v3.zip
30-11-2011 19:06Jacob Wieland - SpirentFile Added: CR_5224-proposal_v4.zip
30-11-2011 19:15Jacob Wieland - SpirentFile Deleted: CR_5224-proposal_v4.zip
30-11-2011 19:17Jacob Wieland - SpirentFile Added: CR_5224-proposal_v5.zip
30-11-2011 19:17Jacob Wieland - SpirentNote Added: 0010453
30-11-2011 19:18Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
01-12-2011 09:32Gyorgy RethyFile Added: CR_5224-proposal_v4.docx
01-12-2011 09:32Gyorgy RethyFile Deleted: CR_5224-proposal_v5.zip
01-12-2011 09:33Gyorgy RethyNote Added: 0010457
01-12-2011 09:53Gyorgy RethyNote Added: 0010459
01-12-2011 09:53Gyorgy RethyFile Added: CR_5224-proposal_v5.docx
11-07-2012 09:26Gyorgy RethyAssigned ToGyorgy Rethy => Jens Grabowski
13-07-2012 09:35Gyorgy RethyAssigned ToJens Grabowski => Tomas Urban
13-07-2012 10:33Jacob Wieland - SpirentNote Added: 0010911
10-08-2012 14:48Tomas UrbanFile Added: CR_5224-proposal_v6.docx
10-08-2012 14:50Tomas UrbanNote Added: 0011034
10-12-2012 11:03Gyorgy RethyFile Added: CR_5224-proposal_v6_BNFmodified.docx
10-12-2012 11:06Gyorgy RethyNote Added: 0011203
10-12-2012 16:05Tomas UrbanFile Added: CR_5224-proposal_v7.docx
10-12-2012 16:18Tomas UrbanNote Added: 0011208
10-12-2012 17:14Tomas UrbanNote Added: 0011211
10-12-2012 17:15Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
11-12-2012 09:17Jacob Wieland - SpirentNote Added: 0011212
11-12-2012 11:02Gyorgy RethyNote Added: 0011217
11-12-2012 12:35Tomas UrbanNote Added: 0011219
11-12-2012 12:35Tomas UrbanNote Edited: 0011219
12-12-2012 15:24Gyorgy RethyFile Added: CR_5224-proposal_v8_delta.docx
12-12-2012 15:26Gyorgy RethyNote Added: 0011246
12-12-2012 15:26Gyorgy RethyAssigned ToGyorgy Rethy => Tomas Urban
13-12-2012 08:35Tomas UrbanFile Added: CR_5224-proposal_v9_delta.docx
13-12-2012 08:50Tomas UrbanNote Added: 0011251
13-12-2012 08:51Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
13-12-2012 12:22Jacob Wieland - SpirentNote Added: 0011252
13-12-2012 17:53Tomas UrbanNote Added: 0011258
13-12-2012 17:54Tomas UrbanFile Added: CR_5224-proposal_v10.docx
18-12-2012 16:19Gyorgy RethyNote Added: 0011284
18-12-2012 16:20Gyorgy RethyFile Added: CR_5224-proposal_v11.docx
18-12-2012 16:21Gyorgy RethyAssigned ToGyorgy Rethy => Jens Grabowski
18-12-2012 16:21Gyorgy RethyPrioritylow => normal
18-12-2012 16:21Gyorgy RethyStatusassigned => resolved
18-12-2012 16:21Gyorgy RethyFixed in Version => v1.2.1 (ongoing)
14-05-2013 15:24Gyorgy RethyStatusresolved => closed
14-05-2013 15:24Gyorgy RethyNote Added: 0011438
14-05-2013 15:24Gyorgy RethyResolutionopen => fixed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009117) +
+ Ina Schieferdecker    +
+ 09-12-2009 13:52    +
+ 		+ + + + +
+ Wait for concrete proposal and hence moved to 2010.
+
+
+
+ + + + + + + + + + +
+ (0009266) +
+ Jacob Wieland - Spirent    +
+ 23-03-2010 16:06    +
+ 		+ + + + +
+ I think to solve this issue at the TTCN-3 language level is the wrong way. The right place to solve this problem is by use of different test adaptations for the different scenarios.
+
+In one scenario, the same mapped port is adapted by an implementation that converts the sent value to a different protocol before sending it to one real-system port, while in another scenario, it is not converted and sent to a different real-system port. In the TTCN-3 code, this is totally transparent and no conversion functions are needed and no intermediate components in TTCN-3, either.
+
+
+
+ + + + + + + + + + +
+ (0009290) +
+ Jacob Wieland - Spirent    +
+ 24-03-2010 18:37    +
+ 		+ + + + +
+ added a proposal text to be discussed
+
+
+
+ + + + + + + + + + +
+ (0009320) +
+ Gyorgy Rethy    +
+ 26-03-2010 09:40    +
+ 		+ + + + +
+ status feedback shall only be used when we are waiting for an external feedback.
+
+
+
+ + + + + + + + + + +
+ (0009442) +
+ Gyorgy Rethy    +
+ 01-07-2010 09:55    +
+ 		+ + + + +
+ Real-life use cases, coming from everyday practice:
+
+1) User tests something above TCP transport and obviously using a TCP adapter. His/her test cases and test data are using the ASPs of the TCP adapter. Then the SUT changes and he/she has to execute the same test cases using e.g. SCTP transport. The SCTP adapter has different ASPs defined than the TCP adapter. In this case the mapping between the two sets of ASPs could be done in a dual-faced port, instead of re-writing the already verified and running test cases.
+2) Protocol A carries encoded messages of protocol B, for example a web application carried by SOAP carried by HTTP over TCP. The user is testing the application but from the point of view of the test system, HTTP (or SOAP in case of an HTTP adapter) is the "upper layer protocol", CD will encode/decode only HTTP (or SOAP) messages but not the Application messages. This means that from the point of view of the user no matching is possible by a receive statement (as he/she wants to match the Application messages, which are embedded in an encoded form in the received SOAP or HTTP messages). Dual-faced ports it can handle the whole encoding/decoding chain, i.e. mapping Application ASPs to SOAP/HTTP ASPs and calling external functions for message encoding/decoding, thus the user would be able to send/receive the Application messages directly in his/her test case code.
+
+This means the dual-faced ports shall not only define the two sets of interfaces between the inner and the outer port but also the type mapping (which inner port ASP/message maps to which outer port ASP/message) and also the functions that makes the mapping. The function is needed to allow the user to write them in TTCN-3 (would be a natural choice for a tester using TTCN-3 anyway) and be able to make static and dynamic checking.
+
+
+
+ + + + + + + + + + +
+ (0009447) +
+ Jacob Wieland - Spirent    +
+ 01-07-2010 11:31    +
+ 		+ + + + +
+ The type-mapping is implicitly given by the mapping-functions. Via the restrictions on the set of functions, the mapping is unambiguous.
+
+
+
+ + + + + + + + + + +
+ (0009670) +
+ Jens Grabowski    +
+ 01-09-2010 11:05    +
+ 		+ + + + +
+ Yes, can be done in the proposed way. I still have the problem that I do not think that this mapping should be done in TTCN-3 itself. Wouldn't it be enough to be able to select different kinds of adapters/coders/decoders?
+
+
+
+ + + + + + + + + + +
+ (0009699) +
+ Jacob Wieland - Spirent    +
+ 02-09-2010 14:13    +
(edited on: 03-09-2010 11:10)
+ 		+ + + + +
+ To solve the dual-faced port problem with the n-to-m message problem could also be done in the following way by some filtering attribute on port types.
+
+Just the semantics, not an actual syntax proposal:
+
+// Taken a type definition like this:
+
+type record TCPPacket {
+  ...
+  octetstring content
+  ...
+}
+
+// we could declare the following:
+
+type port FilteredHTTPPort message filtered {
+  in HTTP |> tcpInFilter; // filtered by tcpInFilter
+  out HTTP |> tcpOutFilter; // filtered by tcpOutFilter
+}
+
+function tcpInFilter(in bitstring input, out bitstring output)
+return integer // number of bits decoded
+{
+  if (transport == tcp) { // switch tcp transport on or off
+    var integer inputLen := lengthof(input);
+    var TCPPacket tcpPacket;
+    if (decvalue(input, tcpPacket) == 0) {
+      output := oct2bit(tcpPacket.content);
+      return inputLen - lengthof(input);
+    }
+    else {
+      return 0; // 0 bits have been decoded because of error or not enough input
+    }
+  }
+  else { // not filtered, just relay
+    output := input;
+    return lengthof(input);
+  }
+}
+
+function tcpOutFilter(in bitstring input, out bitstring output)
+return integer // number of bits read from the input
+{
+  if (transport == tcp) {
+    var TCPPacket tcpPacket;
+    var integer len := packIntoTCPPacket(input, tcpPacket);
+    if (len > 0) {
+      output := encvalue(tcpPacket);
+      return len;
+    }
+    else {
+      return 0;
+    }
+  }
+  else { // not filtered, just relay
+    output := input;
+    return lengthof(input);
+  }
+}
+
+function packIntoTCPPacket(in bitstring input, out TCPPacket tcpPacket)
+return integer // number of bits put into the packet
+{
+  if (isLongEnoughInput(input) {
+    tcpPacket := { ... }; // wrap some of the input into a TCP packet
+    return lengthof(oct2bit(tcpPacket.content));
+  }
+  else {
+    return 0;
+  }
+}
+
+
+The semantics would be that whenever data arrive from the test system, the in-filter function is invoked on the accumulated bitstring and if it returns a filtered bit number > 0, the output of the function is actually enqueued in the port queue.
+
+The reverse is true for sending, the encoded HTTP message is appended to the accumulated output bitstring and the output-filter function is invoked on that bitstring as many times as the result is > 0. The intermediary results are the messages actually sent to the SUT.
+
+
+
+
+
+ + + + + + + + + + +
+ (0009703) +
+ Jacob Wieland - Spirent    +
+ 02-09-2010 18:13    +
+ 		+ + + + +
+ The extended proposal from Gyorgy in the TCP/HTTP example would look like this:
+
+given the following types:
+
+type record HTTP { ... }
+type record TCP { ... }
+type port HTTPPort message { inout HTTP; in ASP1; out ASP2 }
+
+type port HTTPToTCPPort map to HTTPPort {
+  var octetstring inbuffer := ''O;
+  in HTTP from TCP httpFromTcp; // in-translation function for type HTTP
+  out HTTP to TCP tcpFromHTTP; // out-translation function for type HTTP
+}
+// the in types of this port from the component point of view are
+// still HTTP and ASP1
+// the out types of this port from the component point of view are
+// still HTTP and ASP2
+// the in types from the outside point of view (used for map/connect
+// statements) are TCP and ASP1
+// the out types from the outside point of view are TCP and ASP2
+
+// this function will be called whenever an HTTP message should be received
+// on port HTTPToTCPPort, it will be called by the test system until at least
+// one relay operation has been performed
+function httpFromTcp(in TCP tcpMsg)
+on port HTTPToTCPPort // this is needed for type-checking of input/output
+{
+  var HTTP httpMsg;
+  var integer len;
+  inbuffer := inbuffer & tcpMsg.data; // append data to the buffer
+  while (true) {
+    len := lengthof(inbuffer);
+    if (len > 0 and decvalue(inbuffer, httpMsg) == 0) {
+      port.relay(httpMsg); // this puts the httpMsg into the port queue
+                           // the type of the relayed message
+                           // the correctness of this type can be inferred
+                           // from the out HTTP to TCP declaration in
+                           // HTTPtoTCPPort
+    }
+    else {
+      break;
+    }
+  }
+}
+
+// this function is a one-on-one HTTP to TCP mapping without any buffering
+// it does not really need a relation to the port type for type checking
+function tcpFromHTTP(in HTTP httpMsg) return TCP {
+  var bitstring encodedHttp := encvalue(httpMsg);
+  var TCP tcpMsg;
+  // compute the tcpMsg using the information from httpMsg
+  // and embed the encodedHttp
+  ...
+  return tcpMsg; // here, the adapter still needs to encode
+                 // the TTCN-3 value before sending it to the system
+}
+
+// the alternative definition would be
+function tcpFromHTTP(in HTTP httpMsg) on port HTTPtoTCPPort {
+  var bitstring encodedHttp := encvalue(httpMsg);
+  var TCP tcpMsg;
+  // compute the tcpMsg using the information from httpMsg
+  // and embed the encodedHttp
+  ...
+  port.relay (tcpMsg); // the correctness of this type can be
+                       // inferred from the 'out HTTP to TCP' declaration
+                       // in HTTPtoTCPPort
+}
+
+
+
+ + + + + + + + + + +
+ (0009707) +
+ Jacob Wieland - Spirent    +
+ 03-09-2010 10:59    +
(edited on: 03-09-2010 11:03)
+ 		+ + + + +
+ I'm really not that happy with the whole explicit buffering and decoding/encoding and I think this should be hidden as much as possible from the user. So, I would propose to make the approach a bit more declarative and hide these details in the semantics (because this meta-code would look always the same for all such similar problems, as well):
+
+type port HTTPPort message { inout HTTP; in ASP1; out ASP2 }
+
+type port HTTPToTCPPort map to HTTPPort {
+  in HTTP fromTcp; // the from type can be inferred from fromTcp
+  out HTTP tcpFromHTTP; // the to type can be inferred from tcpFromHTTP
+}
+// the in types of this port from the component point of view are HTTP and ASP1
+// the out types of this port from the component point of view are HTTP and ASP2
+// the in types from the outside point of view are TCP and ASP1
+// the out types from the outside point of view are TCP and ASP2
+
+// Each such port has an inner port buffer and an outer port queue.
+// Messages arriving from the outside/SUT are enqueued into the outer port queue.
+// The results of the translations functions are appended to the inner port buffer.
+// For all types that do not have an in-translation function, i.e. ASPs that are not
+// transported, the messages are taken directly from the port queue
+// if the input buffer is empty.
+// Likewise, all types that do not have an out-translation function are
+// simply encoded and sent over the port like normal.
+
+// The in-translation function fromTcp will be called whenever an HTTP
+// message should be received on port HTTPToTCPPort and the inner buffer of
+// that port does not contain a full HTTP message and the outer port queue
+// contains at its head the TCP message tcpMsg.
+// The result will be appended to the inner buffer so that the port can
+// try to decode the HTTP message (if any) from the now longer buffer
+// otherwise, the process is repeated until either a HTTP message could
+// be decoded or no more TCP messages are in the outer queue.
+// If the buffer is non-empty and (even after translation) does not contain
+// even the beginning of an HTTP message, the decodiing of HTTP fails and
+// the next alternative must be tried. (This allows several different protocols
+// to be carried in the TCP).
+// As one can see, this function can be reused as in-translation functions
+// for all types carried over the TCP.
+function fromTcp(in TCP tcpMsg) return bitstring {
+{
+  return oct2bit(tcpMsg.data);
+}
+
+// The function tcpFromHTTP is invoked whenever an HTTP messages is to be
+// sent over HTTPtoTCPPort. It is called with both the abstract and the
+// encoded value of the HTTP message. Its result is the abstract TCP message
+// to be sent. This then is encoded by the port and actually sent.
+function tcpFromHTTP(in HTTP httpMsg, in bitstring encodedHttp) return TCP {
+  // assert encodedHttp == encvalue(httpMsg)
+  var TCP tcpMsg;
+  // compute the tcpMsg using the information from httpMsg
+  // and embed the encodedHttp
+  ...
+  return tcpMsg;
+}
+
+As one can see, the code is much shorter and the user can focus on the actual translation from or to tcp and does not need to worry about the whole encoding/decoding stuff.
+
+
+
+
+
+ + + + + + + + + + +
+ (0009833) +
+ Jacob Wieland - Spirent    +
+ 29-11-2010 16:22    +
+ 		+ + + + +
+ After discussing the last proposal the feedback was that a little bit more redundancy in the filter-port declaration would be more readable.
+
+So, I would propose this kind of syntax:
+
+type port HTTPToTCPPort map to HTTPPort {
+  in HTTP from TCP with fromTcp;
+  out HTTP to TCP with tcpFromHttp;
+}
+
+For the in-types, a list notation for all protocols carried over the TCP
+would also be possible:
+
+Example:
+
+type port HTTPOrSIPPort { inout HTTP, SIP }
+
+type port HTTPOrSIPToTCPPort {
+  in HTTP, SIP from TCP with fromTcp;
+  out HTTP to TCP with tcpFromHttp;
+  out SIP to TCP with tcpFromSip;
+}
+
+One possible usage scenario would be as follows (this could be added to the example in the standard):
+
+type component SystemType {
+  HTTPPort http;
+  HTTPToTCPPort tcpHttp;
+}
+
+type component MtcType {
+  HTTPPort http;
+}
+
+modulepar boolean useTCP := false;
+
+testcase TC() runs on MtcType system SystemType {
+  if (useTCP) {
+    map(mtc:http, system:tcpHttp);
+  } else {
+    map(mtc:http, system:http);
+  }
+  ...
+  http.send(HTTP:...);
+  ...
+  http.receive(HTTP:...);
+}
+
+
+
+ + + + + + + + + + +
+ (0009834) +
+ Jacob Wieland - Spirent    +
+ 29-11-2010 16:28    +
+ 		+ + + + +
+ Maybe a sensible restriction for this feature would be that ports of such mapped port types can only appear in system components, i.e. all component types referenced by runs on (or used in create statements) shall not have port of such mapped port types.
+
+
+
+ + + + + + + + + + +
+ (0009841) +
+ Gyorgy Rethy    +
+ 30-11-2010 13:23    +
+ 		+ + + + +
+ STF discussion on 30/11/2010: principles agreed, text to be written; shall be added to the configuration package
+
+
+
+ + + + + + + + + + +
+ (0009902) +
+ Jacob Wieland - Spirent    +
+ 01-12-2010 16:31    +
+ 		+ + + + +
+ added new proposal in plain text form
+
+
+
+ + + + + + + + + + +
+ (0010283) +
+ Jacob Wieland - Spirent    +
+ 28-09-2011 16:09    +
+ 		+ + + + +
+ uploaded proposal integrated into config&deployment package
+
+
+
+ + + + + + + + + + +
+ (0010404) +
+ Gyorgy Rethy    +
+ 29-11-2011 15:08    +
(edited on: 29-11-2011 15:22)
+ 		+ + + + +
+ Draft is amended quite significantly, see CR_5224-proposal_v2.zip. Some questions are need be discussed:
+
+(1) Syntactical structure allows:
+in InnerInType {"," InnerInType} from OuterInType with InFunction
+however, it is unclear how to declare InFunction that would be able to return more than one InnerInType-s
+
+(2) In some cases decoding functions are generated from the TTCN-3 code. In this cases there may be several InFunction-s, with different names and different InnerInType-s but all with an octetstring as OuterInType. In this case, when decoding the TTCN-3 octetstring (the outcome of decoding the bitstring received from TRI by the TE-CD decoding algorithm), these InFunction-s shall be tried sequentially until the decoding successful or no more attempt left. This procedure has been added to the draft.
+
+(3) Currently for a translation port at least 3 port definitions are required: InnerPortType, OuterPortType and the transation port; it should also be allowed to define two ports only: OuterPortType and the transation port, where the in/out/inout lists of the inner port are just the related lists of the translation port
+
+(4) Currently, when 3 port types are used to define the translation port, transparent relaying of messages are not defined in the translation port. It should be considered, for sefaty reasons, to request declaring transparent relaying explicitly – this would be denoted by InnerInType==OuterInType the null in the above draft.
+
+
+
+
+
+ + + + + + + + + + +
+ (0010406) +
+ Jacob Wieland - Spirent    +
+ 29-11-2011 18:20    +
+ 		+ + + + +
+ All issues have been addressed and the proposal changed accordingly. Two notes in the section Port composition have been left because I did not know what to make of them.
+
+Please review
+
+
+
+ + + + + + + + + + +
+ (0010453) +
+ Jacob Wieland - Spirent    +
+ 30-11-2011 19:17    +
+ 		+ + + + +
+ added support for address, map param and unmap param translation, please review
+
+
+
+ + + + + + + + + + +
+ (0010457) +
+ Gyorgy Rethy    +
+ 01-12-2011 09:33    +
+ 		+ + + + +
+ File CR_5224-proposal_v5.zip contained CR_5224-proposal_v4.docx, so I have deleted the .zip and uploaded the contained .docx instead.
+
+
+
+ + + + + + + + + + +
+ (0010459) +
+ Gyorgy Rethy    +
+ 01-12-2011 09:53    +
+ 		+ + + + +
+ The whole stuff become so overcomplicated that it is almost impossible to me to follow what should happen in a translational port in the different cases. How can we expect the users to understand it? The whole stuff shall be streamlined and simplified to the really required use cases (see CR_5224-proposal_v5.docx, but the simplifications are not done consistently in the whole document):
+- the translational port is part of the test component behaviour, thus there shall be no implicit behaviour there;
+- delete InnerInType list in port in message translation lists (only one InnerInType per inFunction) and the whole implicit decoding stuff in the InFunction prototypes; all encoding/decoding shall be explicit (and decvalue shall be called explicitly within inFunction, if needed)
+- delete InnerOutType list in out message translation clause (i.e. only one InnerOutType per OutFunction) and the related second prototype with two in parameters (I don't even understand the exact semantics of this second prototype).
+
+All these can be added later if really required, but not at this stage.
+
+The Cr can be added to the standard only if the whole concept is clear and simple enough that users really want to use and tool vendors really implements. I don't have this feeling at the moment. As our last session is ending now, I propose to shift this CR to 2012.
+
+
+
+ + + + + + + + + + +
+ (0010911) +
+ Jacob Wieland - Spirent    +
+ 13-07-2012 10:33    +
+ 		+ + + + +
+ Using simple solutions to complicated problems is a sure way to get problems in the future. If you introduce a non-composable dual-port construction (which seems to me what you are implying), this might be acceptable for simple use cases, but makes things overcomplicated for more complex situations (where you would have to explicitly gap the bridge between several protocol layers in the same way it should be done implicitly instead of simply composing several dual-ports).
+
+Letting the user deal with the whole encoding/decoding explicitly is also a way of making this feature unacceptable as it overcomplicates things for the user instead of the tool-vendor and makes the whole thing more error prone (the more the user has to do explicitly, the more they can do wrong).
+
+
+
+ + + + + + + + + + +
+ (0011034) +
+ Tomas Urban    +
+ 10-08-2012 14:50    +
+ 		+ + + + +
+ Temporary draft uploaded. The text contains resolutions to most of the issues that were discussed during the August STF session in Göttingen, but some details are still missing. E.g. address translation shall have two branches for in and out directions.
+
+
+
+ + + + + + + + + + +
+ (0011203) +
+ Gyorgy Rethy    +
+ 10-12-2012 11:06    +
+ 		+ + + + +
+ as agreed this morning, I was working on the BNF, pls. find and check my output in the file CR_5224-proposal_v6_BNFmodified.docx
+
+
+
+ + + + + + + + + + +
+ (0011208) +
+ Tomas Urban    +
+ 10-12-2012 16:18    +
+ 		+ + + + +
+ Updates in this version:
+1. Address translation: two kinds of functions (one for sending, other for receiving)
+2. BNF update including (simplified) György's changes
+3. TCI-TL update (function for port.setstate)
+4. Runs on clause forbidden in translation functions
+5. Corrections in examples (5.10.3 - wrong parameter types, syntax highlight missing)
+6. Translation functions for addresses don't use translation states (no need for fragmentation support or multiple types)
+7. New restriction: in case of fragmented messages, addresses of all fragments shall be equal
+
+
+
+ + + + + + + + + + +
+ (0011211) +
+ Tomas Urban    +
+ 10-12-2012 17:14    +
+ 		+ + + + +
+ György, please check the latest draft.
+
+
+
+ + + + + + + + + + +
+ (0011212) +
+ Jacob Wieland - Spirent    +
+ 11-12-2012 09:17    +
+ 		+ + + + +
+ I still think it is wrong or at least confusing/error-prone to have multiple out or in functions for the same type in one port definition (especially since up till now the order of the declarations in a port type definition has no meaning). This can lead to composition problems when mapping a port to an existing translation port. (A -> f1 -> B -> g1 C vs. A -> f2 -> D -> g2 E).
+Also, what order takes precedence when trying? The order of the inner port or the order of the outer port?
+
+What happens, if the inner port translates A to B with function f and then the outer port translates B to C with function g but fails?
+
+Also, I think that the multiple-case needs some more attention. What happens with the rest of the partially decoded message? Is the message split into decoded/undecoded part?
+
+
+
+ + + + + + + + + + +
+ (0011217) +
+ Gyorgy Rethy    +
+ 11-12-2012 11:02    +
+ 		+ + + + +
+ Hi Jacob,
+
+The typical real-life situaton is that the transport layer carries the upper layer's messages as octetstrings (or univ. charstrings); either a transort layer's field and/or the message itself contains a protocol and/or message identifier. The tool is not able to sort this out, because the location, the concrete form and the concrete ID values of this identifier is protocol-specific, but the user can. The typical algoritm of a translation function is: check if my message "manually" -> if not, return with unsuccess -> if yes, decode and return with success. So, the translation process is not ad-hoc at all, just controlled by the user, not by the tool. In rare cases the type of the message cannot be determined manually before decoding, in these cases the-try-and-see algorithm can be used just like the type hypothesis algorithm; but in practice these are the exceptional cases, not the normal ones!
+
+The order is specified in the proposal as the textual order of the from/to_with_function statements in the set of translation functions with the given type as in parameter. The rational behind this is that the user knows which messages are sent most frequently in the given protocol and - if performance matters - translation functons for these can be placed ahead of the list.
+
+"What happens, if the inner port translates A to B with function f and then the outer port translates B to C with function g but fails?" How is it possible? B is a valid value of its type, let me say BType. The same will happen if the coder received an instance of BType it is unable to encode (but I still don't understand how it would be possible, the instance should cause an error earlier than getting to the codec).
+
+You remember, due to the fragmented and multiple cases (streaming protocols) we have introduced the port variable, as we need something to store the undecode-able part of the outer message (e.g. the bits returned in the encoded_value parameter by the decvalue function called from a translation function). In the next translation round the new octets/bits are concatenated to the bits stored in the port variable and message decoding is tryed again.
+
+
+
+ + + + + + + + + + +
+ (0011219) +
+ Tomas Urban    +
+ 11-12-2012 12:35    +
+ 		+ + + + +
+ Hi Jacob,
+
+The current draft doesn't support protocol stacking, thus the situation you mentioned (multiple translation paths) cannot occur. We have a proposal for protocol stacking via several translation ports in our drawer (including translation path selection which solves the problem you described), but because of overall complexity of the issue, the current draft specifies support for direct translation only. The rationale behind it is very simple: the CR has existed for more than two years without finding its way to the standard, and becuase of that, the STF has decided to resolve the basic problem first and deal with complex issues later (in case it is requested by the community).
+
+Regarding partially decoded messages: There are actually two issues and I am not entirely sure if you meant not finished decoding of a message received in several fragments or an outer (envelope) message that contains several inner messages. Both cases are actually described in the draft. In case of a fragmented message, decoded fragments are removed from the outer queue and the user has to take care of buffering the data (using port variables) if not enough fragments have been received to put together an inner message. In case of multiple payloads in one envelope message, the envelope message stays in the outer queue until all data it contains has been passed to the inner queue. It is again up to the user to store all information about what part of the envelope message has been processed (such as reading positions).
+
+
+
+
+
+ + + + + + + + + + +
+ (0011246) +
+ Gyorgy Rethy    +
+ 12-12-2012 15:26    +
+ 		+ + + + +
+ I have reviewed the draft, see the result in CR_5224-proposal_v8_delta.docx (delta means that only the new and changed parts are left in the file, not the whole ES 202 781). Pls. check my changes and comments.
+
+
+
+ + + + + + + + + + +
+ (0011251) +
+ Tomas Urban    +
+ 13-12-2012 08:50    +
+ 		+ + + + +
+ I marked most of the changes as accepted and attached some comments. However, I changed several rules in the draft:
+
+1. I added the "Unset" state with description to the list describing all possible states
+
+2. "Multiple" state in case of sending: the in parameter should contain the original sent message of the InnerOutType in all translation calls. In most cases, it won't be of any use for the user, because he/she will encode the message in the first call and then store the unused part, but for consistency reasons it seems better to provide some value in the parameter rather than introducing a rule for uninitialized parameter values.
+
+3. "Multiple" state in case of receiving: as the result of the yesterday's discussion, the outer message is kept in the queue, becuase automatic decoding of all inner messages contained in the outer message is not possible during a single receive call (the type hypothesis is available for the first inner message only). I also added some explanatory text and a rule that the outer message is kept in the decoded form in the outer queue.
+
+4. I extended the BNF rules for OuterPortTypeSpec (adding type list and the connect to part)
+
+
+
+ + + + + + + + + + +
+ (0011252) +
+ Jacob Wieland - Spirent    +
+ 13-12-2012 12:22    +
+ 		+ + + + +
+ With this clarification, this is fine.
+
+The multi-layer thing is already present, though, because it is not disallowed to define a mapped port that maps to a mapped port (it is only restricted that the port to be mapped to shall not directly or indirectly be the mapped port, as far as I understood it). Thus, all problems presented by the multiple layers need already be addressed or such a restriction be introduced.
+
+
+
+ + + + + + + + + + +
+ (0011258) +
+ Tomas Urban    +
+ 13-12-2012 17:53    +
+ 		+ + + + +
+ I modified the draft according to results of today's discussion.
+I also added TCI changes and that were accidentally left out from the shortened version of the document.
+Please review.
+
+
+
+ + + + + + + + + + +
+ (0011284) +
+ Gyorgy Rethy    +
+ 18-12-2012 16:19    +
+ 		+ + + + +
+ Final version is in CR_5224-proposal_v11.docx: contains editorial corrections: some missing spaces added, "working" (Word) comments are deleted, names of states are changed to small first character (once they used in small later).
+
+In the notes in 5.10.5 and 5.10.6 (about the non-translated part shall be assigned to port variables), I removed the partially fragmented state: in this case it is enough to store the position, until which the outer message is decoded; In the last iteration, when the superflouos remaining (non-complete message)is processed, the final state will be fragmented.
+
+
+
+ + + + + + + + + + +
+ (0011438) +
+ Gyorgy Rethy    +
+ 14-05-2013 15:24    +
+ 		+ + + + +
+ Added to V1.2.1 of the standard
+
+ + diff --git a/docs/mantis/CR5243.md b/docs/mantis/CR5243.md new file mode 100644 index 0000000000000000000000000000000000000000..0ac2113da54951d71ec3d9a5a2e9119e2161552b --- /dev/null +++ b/docs/mantis/CR5243.md @@ -0,0 +1,370 @@ + + + + + + + + + + + + + 0005243: "iscconnected" to check whether a port is connected or not - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005243Part 01: TTCN-3 Core LanguageNew Featurepublic12-06-2009 15:5917-07-2011 09:34
ReporterWolfgang Seka 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.3.2 (interim 2011)Fixed in Versionv4.3.2 (interim 2011) 
Clause Reference(s)part1 21.1 or 22.5
Source (company - Author)     
Summary0005243: "iscconnected" to check whether a port is connected or not
DescriptionCurrently there is no implicit way in TTCN-3 to figure out whether a port is connected.
+An "isconnected" operation would allow simplicifation of TTCN-3 implementations
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc Resolution-5243-Part1-main-text-110630.doc (116,736) 30-06-2011 16:48
http://oldforge.etsi.org/mantis/file_download.php?file_id=2538&type=bug
doc Resolution-5243-Part1--AnnexE-110630.doc (99,328) 30-06-2011 16:49
http://oldforge.etsi.org/mantis/file_download.php?file_id=2539&type=bug
doc Resolution-5243-Part1-main-text-110701.doc (116,736) 01-07-2011 15:26
http://oldforge.etsi.org/mantis/file_download.php?file_id=2549&type=bug
Issue History
Date ModifiedUsernameFieldChange
12-06-2009 15:59Wolfgang SekaNew Issue
12-06-2009 15:59Wolfgang SekaClause Reference(s) => part1 21.1 or 22.5
12-06-2009 15:59Wolfgang SekaSource (company - Author) =>
30-06-2009 09:47Ina SchieferdeckerProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
30-06-2009 09:47Ina SchieferdeckerTarget Version => Edition 4.2.1 (not yet published)
30-06-2009 09:58Ina SchieferdeckerNote Added: 0008797
30-06-2009 09:59Ina SchieferdeckerStatusnew => assigned
30-06-2009 09:59Ina SchieferdeckerAssigned To => Jens Grabowski
16-02-2010 14:26Jens GrabowskiNote Added: 0009219
18-03-2010 07:33Ina SchieferdeckerTarget VersionEdition 4.2.1 (not yet published) => Edition 5.1.1 (not yet published)
22-03-2010 17:22Gyorgy RethyAssigned ToJens Grabowski =>
22-03-2010 17:22Gyorgy RethyStatusassigned => new
23-03-2010 12:54Gyorgy RethyNote Added: 0009258
23-03-2010 12:54Gyorgy RethyAssigned To => Jens Grabowski
23-03-2010 12:54Gyorgy RethyPrioritynormal => low
23-03-2010 12:54Gyorgy RethyStatusnew => assigned
30-11-2010 13:54Gyorgy RethyNote Added: 0009848
30-11-2010 13:59Gyorgy RethyNote Edited: 0009848
13-12-2010 12:52Gyorgy RethyTarget VersionEdition 4.3.1 (not yet published) => Edition 4.3.2 (interim)
13-12-2010 12:52Gyorgy RethyTarget VersionEdition 4.3.2 (interim) => Edition 4.3.1 (not yet published)
14-12-2010 07:49Gyorgy RethyTarget VersionEdition 4.3.1 (not yet published) => Edition 4.3.2 (interim)
24-05-2011 17:38Gyorgy RethyNote Added: 0010037
24-05-2011 19:34Gyorgy RethyPrioritylow => normal
29-06-2011 11:29Gyorgy RethyNote Added: 0010139
30-06-2011 16:48Jens GrabowskiNote Added: 0010165
30-06-2011 16:48Jens GrabowskiFile Added: Resolution-5243-Part1-main-text-110630.doc
30-06-2011 16:49Jens GrabowskiFile Added: Resolution-5243-Part1--AnnexE-110630.doc
30-06-2011 16:50Jens GrabowskiAssigned ToJens Grabowski => Gyorgy Rethy
01-07-2011 15:26Gyorgy RethyFile Added: Resolution-5243-Part1-main-text-110701.doc
01-07-2011 15:30Gyorgy RethyNote Added: 0010182
01-07-2011 15:30Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
17-07-2011 09:29Ina SchieferdeckerNote Added: 0010227
17-07-2011 09:33Ina SchieferdeckerStatusassigned => resolved
17-07-2011 09:33Ina SchieferdeckerFixed in Version => Edition 4.3.2 (interim)
17-07-2011 09:33Ina SchieferdeckerResolutionopen => fixed
17-07-2011 09:34Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0008797) +
+ Ina Schieferdecker    +
+ 30-06-2009 09:58    +
+ 		+ + + + +
+ Looks like a meaningful feature.
+
+IF so, we should however try to find a general way to cope with the status of active objects (components, timers, port connections, defaults) - and potentially make existing dedicated solutions for selected active objects (such as timer running) deprecated.
+
+Check also with other languages which concepts for reflection are supported.
+
+
+
+ + + + + + + + + + +
+ (0009219) +
+ Jens Grabowski    +
+ 16-02-2010 14:26    +
+ 		+ + + + +
+ To be rediscussed for version 5.1.1
+
+
+
+ + + + + + + + + + +
+ (0009258) +
+ Gyorgy Rethy    +
+ 23-03-2010 12:54    +
+ 		+ + + + +
+ As discussed, a more general solution would be more appropriate that allows getting the state of active TTCN-3 objects.
+
+
+
+ + + + + + + + + + +
+ (0009848) +
+ Gyorgy Rethy    +
+ 30-11-2010 13:54    +
(edited on: 30-11-2010 13:59)
+ 		+ + + + +
+ STF discussion on 30/11/2010: take the "predefined operation" approach, where the operation names are not keywords; but at this stage leave already defined keywords as keywords. Add the .state op., which will return the already defined states of active objects defined in annex E - in a consistent way with the log sttm. Also add isconnected, ismapped operations,
+
+
+
+
+
+ + + + + + + + + + +
+ (0010037) +
+ Gyorgy Rethy    +
+ 24-05-2011 17:38    +
+ 		+ + + + +
+ Define the new and move the existing boolean-returning status checking operations (timer.running, comp.alive) operations in a new mandatory clause and remove their names from the list of keywords. For backward compat. reasons the removed keywords shall be handled in the mapping parts separately.
+
+
+
+ + + + + + + + + + +
+ (0010139) +
+ Gyorgy Rethy    +
+ 29-06-2011 11:29    +
+ 		+ + + + +
+ Go for option 3.b), i.e.
+P1.checkstate(<restricted string>) -> returns boolean; The strings are defined in the mandatory part of the standard, but in Clause E (useful types) two restricted types (for ObjectStates, LinkStates) and constants of that types for each of the defined states shall be added. Refer to those useful types and constants from the clause defining the function and give only examples where these useful constants are used.
+
+
+
+ + + + + + + + + + +
+ (0010165) +
+ Jens Grabowski    +
+ 30-06-2011 16:48    +
+ 		+ + + + +
+ Proposal for the main text in part 1 and Annex E (useful types) can be found in the attached files. Still missing: BNF and operational semantics. While working on operational semantics, assigned to György for proofreading.
+
+
+
+ + + + + + + + + + +
+ (0010182) +
+ Gyorgy Rethy    +
+ 01-07-2011 15:30    +
+ 		+ + + + +
+ Resolution-5243-Part1-main-text-110630.doc and Resolution-5243-Part1--AnnexE-110630.doc are reviewed. Just two small editorial changes see in Resolution-5243-Part1-main-text-110701.doc.
+
+BNF CHANGES TO BE ADDED! When BNF is done, CR should be set to resolved, that we don't miss adding this extension to the interim version v4.3.2.
+
+Part-4 shall be amended later, for this I will submit a new CR.
+
+
+
+ + + + + + + + + + +
+ (0010227) +
+ Ina Schieferdecker    +
+ 17-07-2011 09:29    +
+ 		+ + + + +
+ Implemented as proposed.
+
+BNF:
+
+293. CommunicationStatements ::= SendStatement |
+                                 CallStatement |
+                                 ReplyStatement |
+                                 RaiseStatement |
+                                 ReceiveStatement |
+                                 TriggerStatement |
+                                 GetCallStatement |
+                                 GetReplyStatement |
+                                 CatchStatement |
+                                 CheckStatement |
+                                 ClearStatement |
+                                 StartStatement |
+                                 StopStatement |
+                                 HaltStatement |
+                                 CheckStateStatement
+
+
+372. CheckStateStatement ::= PortOrAllAny Dot CheckStateKeyword "(" SingleExpression ")"
+373. PortOrAllAny ::= PortOrAll | AnyKeyword PortKeyword
+374. CheckStateKeyword ::= "checkstate"
+
+ + diff --git a/docs/mantis/CR5261.md b/docs/mantis/CR5261.md new file mode 100644 index 0000000000000000000000000000000000000000..84ec8f27d923813953a42a9a3b803309096d9ef5 --- /dev/null +++ b/docs/mantis/CR5261.md @@ -0,0 +1,63 @@ + + + + + + + + + + + + + 0005261: T.61 shall be a mandatory reference - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 07: Using ASN.1 with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005261Part 07: Using ASN.1 with TTCN-3Editorialpublic01-07-2009 11:1107-12-2009 14:52
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.1.1 (published 2009-06) 
Target Versionv4.2.1 (published 2010-07)Fixed in Versionv4.2.1 (published 2010-07) 
Clause Reference(s)2.2, 9.1
Source (company - Author)L.M.Ericsson
Summary0005261: T.61 shall be a mandatory reference
DescriptionITU-T Recommendation T.61 is currently an informal reference. However, it is used in the conversion rule of TeletexString ASN.1 types, thus shall be a mandatory reference.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
01-07-2009 11:11Gyorgy RethyNew Issue
01-07-2009 11:11Gyorgy RethyStatusnew => assigned
01-07-2009 11:11Gyorgy RethyAssigned To => Gyorgy Rethy
01-07-2009 11:11Gyorgy RethyClause Reference(s) => 2.2, 9.1
01-07-2009 11:11Gyorgy RethySource (company - Author) => L.M.Ericsson
01-07-2009 11:14Gyorgy RethyStatusassigned => closed
01-07-2009 11:14Gyorgy RethyNote Added: 0008805
01-07-2009 11:14Gyorgy RethyResolutionopen => fixed
01-07-2009 11:14Gyorgy RethyFixed in Version => Edition 4.2.1 (not yet published)
07-12-2009 14:52Ina SchieferdeckerTarget Version => Edition 4.2.1 (not yet published)
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0008805) +
+ Gyorgy Rethy    +
+ 01-07-2009 11:14    +
+ 		+ + + + +
+ T.61 moved to mandatory references, all uses are updated to point to the new ref. no.
+
+ + diff --git a/docs/mantis/CR5262.md b/docs/mantis/CR5262.md new file mode 100644 index 0000000000000000000000000000000000000000..7f4f79f2cc9d47b11d6975584fec4474eb75baa5 --- /dev/null +++ b/docs/mantis/CR5262.md @@ -0,0 +1,634 @@ + + + + + + + + + + + + + 0005262: Partially constrained structured types - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005262Part 01: TTCN-3 Core LanguageNew Featurepublic01-07-2009 14:5130-11-2011 09:33
ReporterGyorgy Rethy 
Assigned ToIna Schieferdecker 
PrioritynormalSeveritymajorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.1.1 (published 2009-06) 
Target Versionv4.4.1 (published 2012-04)Fixed in Versionv4.4.1 (published 2012-04) 
Clause Reference(s)new 6.2.13
Source (company - Author)L.M.Ericsson
Summary0005262: Partially constrained structured types
DescriptionToday the standard allowes restricting structured types by a value list notation. This means that all the allowed concrete values shall be listed. Especially in case of record/set types with several fields it is not desired and not possible in practice. In these cases very often the need is just to limit the content of 1-2 fields. This could be easily achieved in the language if - borrowing the semantics of modified teplate bodies - the fields not listed in the values (of the subtype list) are considered not further restricted (i.e. any previous restriction is just inherited. Example:
+type record MyRec { integer int (0..255), charstring uname, charstring pswd }
+type MyRec MyRecRestricted ({uname := "rethy", pswd := "xyz"},{uname := "gyorgy", pswd := "zyx"})
+The type MyRecRestricted allows records with field int containing an integer between 0 and 255 and with the combined content of the string fields uname and pswd {rethy,xyz} and {gyorgy,zyx} only.
+
+Pls. note, that this extension would allow to put logical constraints on combinations of record/set fields that would be a powerfull mechanism in case of several real-life propotocols. This extension would also allow to transform ASN.1 table constraints that are ignored today.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0005938closed Gyorgy Rethy Type restriction by template list 
Attached Filesdoc CR5262_resolution_v1.doc (119,808) 27-09-2011 18:08
http://oldforge.etsi.org/mantis/file_download.php?file_id=2565&type=bug
Issue History
Date ModifiedUsernameFieldChange
01-07-2009 14:51Gyorgy RethyNew Issue
01-07-2009 14:51Gyorgy RethyStatusnew => assigned
01-07-2009 14:51Gyorgy RethyAssigned To => Ina Schieferdecker
01-07-2009 14:51Gyorgy RethyClause Reference(s) => new 6.2.13
01-07-2009 14:51Gyorgy RethySource (company - Author) => L.M.Ericsson
09-12-2009 15:42Ina SchieferdeckerNote Added: 0009125
09-12-2009 15:42Ina SchieferdeckerTarget Version => Edition 5.1.1 (not yet published)
22-03-2010 17:23Gyorgy RethyAssigned ToIna Schieferdecker =>
22-03-2010 17:23Gyorgy RethyStatusassigned => new
23-03-2010 12:52Gyorgy RethyAssigned To => Jacob Wieland - Spirent
23-03-2010 12:52Gyorgy RethyStatusnew => assigned
23-03-2010 19:03Jacob Wieland - SpirentNote Added: 0009270
31-08-2010 11:45Jacob Wieland - SpirentNote Added: 0009663
01-09-2010 16:57Jacob Wieland - SpirentFile Added: CR5262.doc
01-09-2010 17:05Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
01-09-2010 17:05Jacob Wieland - SpirentNote Added: 0009682
03-09-2010 10:17Gyorgy RethyNote Added: 0009705
03-09-2010 10:17Gyorgy RethyNote Edited: 0009705
03-09-2010 12:18Jacob Wieland - SpirentAssigned ToGyorgy Rethy => Ina Schieferdecker
03-09-2010 12:18Jacob Wieland - SpirentNote Added: 0009710
03-09-2010 13:17Jacob Wieland - SpirentStatusassigned => resolved
03-09-2010 13:17Jacob Wieland - SpirentFixed in Version => Edition 4.3.1 (not yet published)
03-09-2010 13:17Jacob Wieland - SpirentResolutionopen => fixed
14-12-2010 15:00Ina SchieferdeckerNote Added: 0009969
14-12-2010 15:25Ina SchieferdeckerAssigned ToIna Schieferdecker => Gyorgy Rethy
14-12-2010 15:25Ina SchieferdeckerStatusresolved => assigned
14-12-2010 15:25Ina SchieferdeckerFixed in VersionEdition 4.3.1 (not yet published) =>
14-12-2010 15:25Ina SchieferdeckerTarget VersionEdition 4.3.1 (not yet published) => Edition 4.3.2 (interim)
27-09-2011 14:07Gyorgy RethyTarget VersionEdition 4.3.2 (interim) => Edition 4.4.1
27-09-2011 17:59Gyorgy RethyNote Added: 0010258
27-09-2011 18:08Gyorgy RethyFile Added: CR5262_resolution_v1.doc
27-09-2011 18:10Gyorgy RethyAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
28-09-2011 11:18Jacob Wieland - SpirentNote Added: 0010260
28-09-2011 13:16Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
29-09-2011 09:38Gyorgy RethyNote Added: 0010288
29-09-2011 10:19Gyorgy RethyNote Added: 0010291
29-09-2011 12:37Gyorgy RethyNote Edited: 0010291
29-09-2011 12:39Gyorgy RethyNote Added: 0010298
29-09-2011 12:39Gyorgy RethyFile Deleted: CR5262.doc
29-09-2011 12:39Gyorgy RethyAssigned ToGyorgy Rethy => Jens Grabowski
30-09-2011 09:55Jens GrabowskiNote Added: 0010306
30-09-2011 09:56Jens GrabowskiAssigned ToJens Grabowski => Ina Schieferdecker
30-09-2011 11:10Gyorgy RethyStatusassigned => resolved
30-09-2011 11:10Gyorgy RethyNote Added: 0010308
30-11-2011 09:33Ina SchieferdeckerNote Added: 0010417
30-11-2011 09:33Ina SchieferdeckerStatusresolved => closed
30-11-2011 09:33Ina SchieferdeckerFixed in Version => Edition 4.4.1
10-07-2013 17:01Gyorgy RethyRelationship addedrelated to 0005938
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009125) +
+ Ina Schieferdecker    +
+ 09-12-2009 15:42    +
+ 		+ + + + +
+ A proposal has to be developed first - hence postponed to 2010.
+
+
+
+ + + + + + + + + + +
+ (0009270) +
+ Jacob Wieland - Spirent    +
+ 23-03-2010 19:03    +
+ 		+ + + + +
+ Proposal: allow templates also in SubtypeSpec
+
+The BNF needs to be changed in the following way:
+
+49 SubTypeSpec ::= AllowedValues [StringLength] | StringLength
+/* STATIC SEMANTICS - AllowedValues shall be of the same type as the field being subtyped */
+50 AllowedValues ::= "(" (ValueOrRange {"," ValueOrRange}) | CharStringMatch ")"
+51 ValueOrRange ::= RangeDef | ConstantExpression | Type
+
+to
+
+49 SubTypeSpec ::= AllowedValuesSpec [StringLength] | StringLength
+/* STATIC SEMANTICS - AllowedValuesSpec shall be of the same type as the field being subtyped */
+50 AllowedValuesSpec ::= "(" (TemplateOrRange {"," TemplateOrRange}) | CharStringMatch ")"
+51 TemplateOrRange ::= RangeDef | TemplateBody | Type
+
+Also, the text of 6.1.2.1 needs to be changed accordingly:
+
+6.1.2.1 Template List subtyping
+TTCN-3 permits the specification of a list of distinguished templates as listed in table 3. The templates in the list shall be valid templates for the type being constrained and the set of values matching at least one of these templates shall be a subset of the values defined by the type being constrained. The subtype defined by this list restricts the allowed values of the subtype to those values matched by the templates in the list. The templates in the list shall only (directly or indirectly) reference other templates or constant expressions. Constants used in the template expressions shall meet with the restrictions in clause 10.
+
+6.2.13.2 List subtyping of structured types and anytype
+List subtyping is possible when defining a new type based on an existing parent type, but not directly at the declaration of the first parent type (see table 3).
+Subtypes defined by a list subtyping restrict the allowed values of the subtype to the values matched by the templates in the list. In case of list subtyping of record, set, record of, set of, union and anytype types, the list may contain both templates and subtypes of the parent types of the type being constrained. The collection of templates denoted by the type(s) referenced in the list become instances of the new subtype. All expressions of the expanded list (i.e. after resolving the type references) shall be valid template expressions of the first parent type. The templates in the list shall only (directly or indirectly) reference other templates or constant expressions. Constants used in the template expressions shall meet with the restrictions in clause 10.
+
+Generally, all references to 'value list' in regard to the matching mechanism or subtyping should be replaced in the whole text by the more appropriate term 'template list' so it cannot be confused with the frequently used term 'value list notation'. Also, the 'value list' matching mechanism is already explicitely allowed to contain template expressions which is all the more reason to rename it properly.
+
+
+
+ + + + + + + + + + +
+ (0009663) +
+ Jacob Wieland - Spirent    +
+ 31-08-2010 11:45    +
+ 		+ + + + +
+ The changes I have proposed would allow the example given in the CR to be valid.
+
+In case of real-life protocols with lots of fields where only a few fields should be restricted, the following approach could be taken:
+
+given the following definition:
+
+type record PDU {
+  T1 f1,
+  ...
+  Tn fn
+}
+
+we would add these definitions:
+
+template PDU basePDU := ?;
+template PDU restrict(T1 f1 := -, ... Tn fn := -) modifies basePDU := {
+  f1 := f1,
+  ...
+  fn := fn
+}
+
+Then, we could define our restricted type(s) like this:
+
+type PDU RestrictedPDU (
+  restrict(...), // give the fields that should be restricted as parameters
+  restrict(...),
+  restrict(...),
+  ...
+  restrict(...)
+);
+
+If you don't want the additional generic template, you could also use inline templates:
+
+type PDU RestrictedPDU (
+  modifies basePDU := { ... },
+  modifies basePDU := { ... },
+  ...
+  modifies basePDU := { ... }
+)
+
+
+Of course, if these ways are seen as too clumsy, we could additionally define that in SubtypeSpec, all (implicitly) omitted fields are automatically ? or * for optional fields, yielding the same result.
+
+
+
+ + + + + + + + + + +
+ (0009682) +
+ Jacob Wieland - Spirent    +
+ 01-09-2010 17:05    +
+ 		+ + + + +
+ please review
+
+
+
+ + + + + + + + + + +
+ (0009705) +
+ Gyorgy Rethy    +
+ 03-09-2010 10:17    +
+ 		+ + + + +
+ STF discussion and agreement on 01-09:
+- Subtype constraint shall allow templates, resolvable at compile time (e.g. parameterzized templates shall be called with literal values and constains resolvable at comile time only)
+- Allow partial definition of subtype constraints
+- Fields missing in the subtype constraints are automatically and implicitly gets with ? and * constraint
+
+E.g. the following both will be legal (but have different semantical meaning):
+type MyRec MyRecRestricted ({uname := "rethy", pswd := "xyz"},{uname := "gyorgy", pswd := "zyx"})
+type MyRec MyRecRestricted ({uname := ("rethy","gyorgy"), pswd := ("xyz","zyx")})
+
+
+
+
+
+ + + + + + + + + + +
+ (0009710) +
+ Jacob Wieland - Spirent    +
+ 03-09-2010 12:18    +
+ 		+ + + + +
+ Please review.
+
+
+
+ + + + + + + + + + +
+ (0009969) +
+ Ina Schieferdecker    +
+ 14-12-2010 15:00    +
+ 		+ + + + +
+ Not yet finally agreed - shifted to 2011 for consideration
+
+
+
+ + + + + + + + + + +
+ (0010258) +
+ Gyorgy Rethy    +
+ 27-09-2011 17:59    +
+ 		+ + + + +
+ Types are static in TTCN-3 to allow as deep compile time checking as possible. Also type constraints shall be resolvable compile time. Therefore any template used in a type constraint should have similar limitations as constants used in type constraints: should use only literals and constants obeying restriction b) of clause 10, predefined functions except of rnd , operators specified in clause 7.17.1, and other templates obeying the previous limitations. And, of course, it could only use the specific value, value list, complemented value list, AnyValue or AnyValueOrNone matchings. Seems to be much ado for almost nothing: for simple types range and list notations solve this task on a sufficient level today.
+For structured types, in addition, this
+- would make the semantics of templates different when used in type constraints or elsewhere in the code, implicitly supposing ? and * when used in type constraints and
+- force the user to declare named templates unnecesarily, causing extra work and decreising readibility (the user cannot really see what the type definition is).
+
+See proposed resolution in CR5262_resolution_v1.doc
+
+
+
+ + + + + + + + + + +
+ (0010260) +
+ Jacob Wieland - Spirent    +
+ 28-09-2011 11:18    +
+ 		+ + + + +
+ I think you somehow misunderstood my proposal. To clarify:
+
+First, the restrictions implying compile-time resolvability are already in the proposal, I just did not want to re-iterate the same restrictions as for constants used in type definitions.
+
+Second, only literal compound expressions shall be interpreted as containing implicit ? or * fields (kind or as a shorthand notation for an inline-modifies construct). If actual named templates are used as a subtype constraint, they shall have the same semantics as everywhere else.
+
+Third, no one forces the user to define named templates. Everything can be done with inline constructs, if so desired. This allows exactly for the effects desired by the CR, but also much, much more.
+
+
+
+ + + + + + + + + + +
+ (0010288) +
+ Gyorgy Rethy    +
+ 29-09-2011 09:38    +
+ 		+ + + + +
+ This CR is submitted two years ago. Basically my proposal is to handle it in two steps: cover the requested functionality (basically something similar but not fully equivalent to the ASN.1 table constraint) by this CR and open a new CR for the constraints by templates part that still needs some work to do. This would prevent further delay in resolving the originally requested feature.
+
+
+
+ + + + + + + + + + +
+ (0010291) +
+ Gyorgy Rethy    +
+ 29-09-2011 10:19    +
(edited on: 29-09-2011 12:37)
+ 		+ + + + +
+ STF discussion 2011-09-29: de-couple the two features: type constraint by partially defined values and type constraints by template into separate CRs and try to resolve both for v4.4.1.
+
+
+
+
+
+ + + + + + + + + + +
+ (0010298) +
+ Gyorgy Rethy    +
+ 29-09-2011 12:39    +
+ 		+ + + + +
+ Resolution draft for the partially defined value part is in CR5262_resolution_v1.doc. Pls. review.
+
+(the file CR5262.doc is moved to CR5938 under the name "CR5938_initial_draft.doc")
+
+
+
+ + + + + + + + + + +
+ (0010306) +
+ Jens Grabowski    +
+ 30-09-2011 09:55    +
+ 		+ + + + +
+ Resolution is fine with me. Assigned to Ina for integration into core language.
+
+
+
+ + + + + + + + + + +
+ (0010308) +
+ Gyorgy Rethy    +
+ 30-09-2011 11:10    +
+ 		+ + + + +
+ Acc. to review the proposal is OK.
+
+
+
+ + + + + + + + + + +
+ (0010417) +
+ Ina Schieferdecker    +
+ 30-11-2011 09:33    +
+ 		+ + + + +
+ as proposed.
+
+ + diff --git a/docs/mantis/CR5263.md b/docs/mantis/CR5263.md new file mode 100644 index 0000000000000000000000000000000000000000..3e92227690b47fb3acd9c8c2f73d7b8245c2d3ec --- /dev/null +++ b/docs/mantis/CR5263.md @@ -0,0 +1,140 @@ + + + + + + + + + + + + + 0005263: TTCN-3 macros shall not be replaced in strings and comments - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005263Part 01: TTCN-3 Core LanguageClarificationpublic02-07-2009 16:2607-12-2009 14:45
ReporterGyorgy Rethy 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.2.1 (published 2010-07)Fixed in Versionv4.2.1 (published 2010-07) 
Clause Reference(s)Annex D, main text
Source (company - Author)L.M.Ericsson
Summary0005263: TTCN-3 macros shall not be replaced in strings and comments
DescriptionCurrently it is not specifies what "replaced by a ... before compilation" means. Are macros replaced within character string values and/or comments?
+
+- as macros (except __LINE__) are replaced by a charstring value, replacing them inside character strings would lead to non-eliminable syntactical errors (or at least unwanted quotation marks in the string). E.g. the raw TTCN-3 code:
+var charstring vchar := "My __MODULE__ is:";// raw TCN-3 code
+would become after preprocessing:
+var charstring vchar := "My "MyModule" is:";//invalid TTCN-3 code
+
+- comments are normally raw text that is skipped during all pre(processing) of the code (except when processed specifically for documentation purposes); hence macros shall not be replaced in comments either
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR5263_Macro_inside_string_comment.doc (131,584) 08-07-2009 10:53
http://oldforge.etsi.org/mantis/file_download.php?file_id=2184&type=bug
doc CR5263_resolution_v2.doc (131,584) 08-07-2009 14:33
http://oldforge.etsi.org/mantis/file_download.php?file_id=2190&type=bug
Issue History
Date ModifiedUsernameFieldChange
02-07-2009 16:26Gyorgy RethyNew Issue
02-07-2009 16:26Gyorgy RethyStatusnew => assigned
02-07-2009 16:26Gyorgy RethyAssigned To => Tibor Csöndes
02-07-2009 16:26Gyorgy RethyClause Reference(s) => Annex D, main text
02-07-2009 16:26Gyorgy RethySource (company - Author) => L.M.Ericsson
08-07-2009 10:53Tibor CsöndesFile Added: CR5263_Macro_inside_string_comment.doc
08-07-2009 10:54Tibor CsöndesNote Added: 0008864
08-07-2009 10:56Tibor CsöndesAssigned ToTibor Csöndes => Gyorgy Rethy
08-07-2009 14:33Gyorgy RethyNote Added: 0008870
08-07-2009 14:33Gyorgy RethyFile Added: CR5263_resolution_v2.doc
08-07-2009 14:33Gyorgy RethyAssigned ToGyorgy Rethy => Tibor Csöndes
08-07-2009 14:35Gyorgy RethyResolutionopen => fixed
08-07-2009 14:35Gyorgy RethyFixed in Version => Edition 4.2.1 (not yet published)
08-07-2009 15:35Tibor CsöndesAssigned ToTibor Csöndes => Ina Schieferdecker
13-07-2009 07:18Ina SchieferdeckerNote Added: 0008893
13-07-2009 07:19Ina SchieferdeckerStatusassigned => resolved
13-07-2009 07:19Ina SchieferdeckerStatusresolved => closed
07-12-2009 14:45Ina SchieferdeckerTarget Version => Edition 4.2.1 (not yet published)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0008864) +
+ Tibor Csöndes    +
+ 08-07-2009 10:54    +
+ 		+ + + + +
+ Suggestion uploaded.
+
+
+
+ + + + + + + + + + +
+ (0008870) +
+ Gyorgy Rethy    +
+ 08-07-2009 14:33    +
+ 		+ + + + +
+ CR5263_resolution_v2.doc:
+editorials only, otherwise solution is OK with me.
+
+
+
+ + + + + + + + + + +
+ (0008893) +
+ Ina Schieferdecker    +
+ 13-07-2009 07:18    +
+ 		+ + + + +
+ Implemented as "Preprocessing macros shall not be replaced inside literal charstring values and templates and not in TTCN-3 comments."
+
+ + diff --git a/docs/mantis/CR5264.md b/docs/mantis/CR5264.md new file mode 100644 index 0000000000000000000000000000000000000000..673d568e428223b1732d6ba8c4600e994db5f876 --- /dev/null +++ b/docs/mantis/CR5264.md @@ -0,0 +1,101 @@ + + + + + + + + + + + + + 0005264: Wrong wording for template variables - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005264Part 01: TTCN-3 Core LanguageClarificationpublic03-07-2009 15:1606-07-2009 17:52
ReporterIna Schieferdecker 
Assigned ToIna Schieferdecker 
PrioritylowSeveritytextReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.2.1 (published 2010-07)Fixed in Versionv4.2.1 (published 2010-07) 
Clause Reference(s)11.2 Template variables
Source (company - Author)Colin Willcock, NSN
Summary0005264: Wrong wording for template variables
Description"In excess to value variables, template variables may also store matching mechanisms (see clause 15.7)."
+
+should be
+
+"In addition to values, template variables may also store matching mechanisms (see clause 15.7)."
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
03-07-2009 15:16Ina SchieferdeckerNew Issue
03-07-2009 15:16Ina SchieferdeckerStatusnew => assigned
03-07-2009 15:16Ina SchieferdeckerAssigned To => Ina Schieferdecker
03-07-2009 15:16Ina SchieferdeckerClause Reference(s) => 11.2 Template variables
03-07-2009 15:16Ina SchieferdeckerSource (company - Author) => Colin Willcock, NSN
03-07-2009 15:16Ina SchieferdeckerProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
03-07-2009 15:17Ina SchieferdeckerResolutionopen => fixed
03-07-2009 15:17Ina SchieferdeckerCategoryTTCN-3 Core Language => Clarification
03-07-2009 15:17Ina SchieferdeckerTarget Version => Edition 4.2.1 (not yet published)
03-07-2009 15:17Ina SchieferdeckerNote Added: 0008834
03-07-2009 15:18Ina SchieferdeckerAssigned ToIna Schieferdecker => Gyorgy Rethy
03-07-2009 17:08Gyorgy RethyNote Added: 0008836
03-07-2009 17:08Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
03-07-2009 17:08Gyorgy RethyStatusassigned => resolved
06-07-2009 17:52Ina SchieferdeckerStatusresolved => closed
06-07-2009 17:52Ina SchieferdeckerFixed in Version => Edition 4.2.1 (not yet published)
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0008834) +
+ Ina Schieferdecker    +
+ 03-07-2009 15:17    +
+ 		+ + + + +
+ Please check - even, if it is trivial. Thanks
+
+
+
+ + + + + + + + + + +
+ (0008836) +
+ Gyorgy Rethy    +
+ 03-07-2009 17:08    +
+ 		+ + + + +
+ I agree, we shall change the wording as you proposed
+
+ + diff --git a/docs/mantis/CR5268.md b/docs/mantis/CR5268.md new file mode 100644 index 0000000000000000000000000000000000000000..e0342677ee302ba0d5291c6b3d7d5681c8936bb1 --- /dev/null +++ b/docs/mantis/CR5268.md @@ -0,0 +1,63 @@ + + + + + + + + + + + + + 0005268: Definition prepocessing macro: __DEFINITION__ - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005268Part 01: TTCN-3 Core LanguageClarificationpublic08-07-2009 11:1016-02-2010 07:08
ReporterTibor Csöndes 
Assigned ToIna Schieferdecker 
PriorityurgentSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.2.1 (published 2010-07)Fixed in Versionv4.2.1 (published 2010-07) 
Clause Reference(s)D.5
Source (company - Author)    Tibor Csöndes, L.M. Ericsson
Summary0005268: Definition prepocessing macro: __DEFINITION__
DescriptionA new preprocessing macro __DEFINITION__ is requested which shall substitute with the name of the top-level module definition that it is used in.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0005084closed Ina Schieferdecker Use of the __SCOPE__ macro 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
08-07-2009 11:10Tibor CsöndesNew Issue
08-07-2009 11:10Tibor CsöndesClause Reference(s) => D.5
08-07-2009 11:10Tibor CsöndesSource (company - Author) => Tibor Csöndes, L.M. Ericsson
08-07-2009 11:11Tibor CsöndesStatusnew => assigned
08-07-2009 11:11Tibor CsöndesAssigned To => Gyorgy Rethy
08-07-2009 17:02Tibor CsöndesRelationship addedrelated to 0005084
10-07-2009 14:48Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
10-07-2009 14:48Gyorgy RethyStatusassigned => resolved
10-07-2009 14:48Gyorgy RethyResolutionopen => fixed
10-07-2009 14:48Gyorgy RethyNote Added: 0008892
07-12-2009 14:46Ina SchieferdeckerProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
07-12-2009 14:46Ina SchieferdeckerCategoryTTCN-3 Core Language => Clarification
07-12-2009 14:46Ina SchieferdeckerTarget Version => Edition 4.2.1 (not yet published)
16-02-2010 07:08Ina SchieferdeckerStatusresolved => closed
16-02-2010 07:08Ina SchieferdeckerFixed in Version => Edition 4.2.1 (not yet published)
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0008892) +
+ Gyorgy Rethy    +
+ 10-07-2009 14:48    +
+ 		+ + + + +
+ Resolution se in CR5084.
+
+ + diff --git a/docs/mantis/CR5269.md b/docs/mantis/CR5269.md new file mode 100644 index 0000000000000000000000000000000000000000..1d993b9d2a426e210223d55ebd8e24aa76ad1818 --- /dev/null +++ b/docs/mantis/CR5269.md @@ -0,0 +1,204 @@ + + + + + + + + + + + + + 0005269: Language specification for ASN.1:2009 - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 07: Using ASN.1 with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005269Part 07: Using ASN.1 with TTCN-3Technicalpublic08-07-2009 13:5302-02-2010 16:25
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.1.1 (published 2009-06) 
Target Versionv4.2.1 (published 2010-07)Fixed in Versionv4.2.1 (published 2010-07) 
Clause Reference(s)8.1bis.1
Source (company - Author)L.M.Ericsson
Summary0005269: Language specification for ASN.1:2009
DescriptionA new version of the ASN.1 Recommendations is approved and going to be published by ITU-T. At the time of submitting this CR, the new version is still in a pre-published state, therefore it's final publication date is not known. But it can be expected to happen during 2009. As soon as the Recommendations are published, the related language specification strings shall be added to TTCN-3 Part-7.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
parent of 0005215closed Gyorgy Rethy Wrong references in clause 9.1 
parent of 0002027closed Gyorgy Rethy ASN.1 (2007) to TTCN-3 mapping 
Attached Filesdoc 00111-7_T3_ed421_asn1v413__interim_version.doc (875,520) 08-09-2009 18:17
http://oldforge.etsi.org/mantis/file_download.php?file_id=2250&type=bug
Issue History
Date ModifiedUsernameFieldChange
08-07-2009 13:53Gyorgy RethyNew Issue
08-07-2009 13:53Gyorgy RethyStatusnew => assigned
08-07-2009 13:53Gyorgy RethyAssigned To => Gyorgy Rethy
08-07-2009 13:53Gyorgy RethyClause Reference(s) => 8.1bis.1
08-07-2009 13:53Gyorgy RethySource (company - Author) => L.M.Ericsson
08-07-2009 14:42Gyorgy RethyNote Added: 0008871
08-07-2009 14:43Gyorgy RethyNote Added: 0008872
08-07-2009 14:43Gyorgy RethyRelationship addedparent of 0005215
08-07-2009 14:44Gyorgy RethyNote Added: 0008873
13-07-2009 15:38Gyorgy RethyRelationship addedrelated to 0002027
08-09-2009 18:15Gyorgy RethyResolutionopen => fixed
08-09-2009 18:15Gyorgy RethyTarget Version => Edition 4.2.1 (not yet published)
08-09-2009 18:15Gyorgy RethyRelationship deletedrelated to 0002027
08-09-2009 18:16Gyorgy RethyRelationship addedchild of 0002027
08-09-2009 18:16Gyorgy RethyRelationship deletedchild of 0002027
08-09-2009 18:16Gyorgy RethyRelationship addedparent of 0002027
08-09-2009 18:17Gyorgy RethyFile Added: 00111-7_T3_ed421_asn1v413__interim_version.doc
08-09-2009 18:19Gyorgy RethyNote Added: 0008989
02-02-2010 16:25Gyorgy RethyNote Added: 0009189
02-02-2010 16:25Gyorgy RethyStatusassigned => closed
02-02-2010 16:25Gyorgy RethyFixed in Version => Edition 4.2.1 (not yet published)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0008871) +
+ Gyorgy Rethy    +
+ 08-07-2009 14:42    +
+ 		+ + + + +
+ When changing the baseline version for the mapping, all ASN.1 clause numbers shall be checked as they may have changed.
+
+
+
+ + + + + + + + + + +
+ (0008872) +
+ Gyorgy Rethy    +
+ 08-07-2009 14:43    +
+ 		+ + + + +
+ When changing the baseline version for the mapping, all ASN.1 clause numbers shall be checked as they may have changed.
+
+
+
+ + + + + + + + + + +
+ (0008873) +
+ Gyorgy Rethy    +
+ 08-07-2009 14:44    +
+ 		+ + + + +
+ When changing the baseline version for the mapping, all ASN.1 clause numbers shall be checked as they may have changed.
+
+
+
+ + + + + + + + + + +
+ (0008989) +
+ Gyorgy Rethy    +
+ 08-09-2009 18:19    +
+ 		+ + + + +
+ 00111-7_T3_ed421_asn1v413__interim_version.doc: working document, NOT complete, upoladed for security reasons (to have a copy on the server) only!
+
+
+
+ + + + + + + + + + +
+ (0009189) +
+ Gyorgy Rethy    +
+ 02-02-2010 16:25    +
+ 		+ + + + +
+ Completed; Added:
+new ASN.1 types (ISO8601-based time types, OID-IRI and relative OID-IRI);
+mapping rules for pattern constraints, exclusive range bounds,
+language string for ASN.1:2008.
+Informative annex on top-level OID arcs is updated.
+Old deprecated features are removed.
+
+ + diff --git a/docs/mantis/CR5270.md b/docs/mantis/CR5270.md new file mode 100644 index 0000000000000000000000000000000000000000..06dbee3c310e1e23557303eda9887c4755c1e446 --- /dev/null +++ b/docs/mantis/CR5270.md @@ -0,0 +1,63 @@ + + + + + + + + + + + + + 0005270: Type of signature parameters - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005270Part 01: TTCN-3 Core LanguageTechnicalpublic09-07-2009 10:1216-02-2010 08:25
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.1.1 (published 2009-06) 
Target Versionv4.2.1 (published 2010-07)Fixed in Versionv4.2.1 (published 2010-07) 
Clause Reference(s)14
Source (company - Author)L.M.Ericsson
Summary0005270: Type of signature parameters
DescriptionCurrent clause 14 says no word about the allowed types of signature parameters. The BNF allows e.g. the default keyword as signature parameter type and also any named default type or a structured type default. As default values has any meaning inside the component (the local process) only, it shall be excluded.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR5270_resolution_v1.doc (32,768) 09-12-2009 14:52
http://oldforge.etsi.org/mantis/file_download.php?file_id=2308&type=bug
Issue History
Date ModifiedUsernameFieldChange
09-07-2009 10:12Gyorgy RethyNew Issue
09-07-2009 10:12Gyorgy RethyStatusnew => assigned
09-07-2009 10:12Gyorgy RethyAssigned To => Ina Schieferdecker
09-07-2009 10:12Gyorgy RethyClause Reference(s) => 14
09-07-2009 10:12Gyorgy RethySource (company - Author) => L.M.Ericsson
09-07-2009 10:21Gyorgy RethyDescription Updated
07-12-2009 14:48Ina SchieferdeckerTarget Version => Edition 4.2.1 (not yet published)
09-12-2009 14:52Ina SchieferdeckerNote Added: 0009122
09-12-2009 14:52Ina SchieferdeckerFile Added: CR5270_resolution_v1.doc
09-12-2009 14:52Ina SchieferdeckerAssigned ToIna Schieferdecker => Gyorgy Rethy
09-12-2009 14:52Ina SchieferdeckerResolutionopen => fixed
09-12-2009 14:52Ina SchieferdeckerFixed in Version => Edition 4.2.1 (not yet published)
16-02-2010 08:24Ina SchieferdeckerStatusassigned => resolved
16-02-2010 08:25Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009122) +
+ Ina Schieferdecker    +
+ 09-12-2009 14:52    +
+ 		+ + + + +
+ As proposed - see resolution v1 - please check
+
+ + diff --git a/docs/mantis/CR5271.md b/docs/mantis/CR5271.md new file mode 100644 index 0000000000000000000000000000000000000000..4ab97156be16c3f1977c1c0877de7360aac5aec9 --- /dev/null +++ b/docs/mantis/CR5271.md @@ -0,0 +1,63 @@ + + + + + + + + + + + + + 0005271: Wording: illegal and invalid - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005271Part 01: TTCN-3 Core LanguageEditorialpublic09-07-2009 14:3716-02-2010 07:19
ReporterIna Schieferdecker 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.2.1 (published 2010-07)Fixed in Versionv4.2.1 (published 2010-07) 
Clause Reference(s)Throughout Part 1
Source (company - Author)Ina Schieferdecker, FOKUS
Summary0005271: Wording: illegal and invalid
DescriptionPart 1 uses the words illegal and invald to describe cases that lead to error. The text would be more consistent, if just "causes an error" would be used.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
09-07-2009 14:37Ina SchieferdeckerNew Issue
09-07-2009 14:37Ina SchieferdeckerClause Reference(s) => Throughout Part 1
09-07-2009 14:37Ina SchieferdeckerSource (company - Author) => Ina Schieferdecker, FOKUS
31-08-2009 15:03Ina SchieferdeckerProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
31-08-2009 15:03Ina SchieferdeckerAssigned To => Ina Schieferdecker
31-08-2009 15:03Ina SchieferdeckerStatusnew => assigned
31-08-2009 15:03Ina SchieferdeckerCategoryTTCN-3 Core Language => Editorial
31-08-2009 15:03Ina SchieferdeckerTarget Version => Edition 4.2.1 (not yet published)
31-08-2009 17:36Ina SchieferdeckerNote Added: 0008941
31-08-2009 17:37Ina SchieferdeckerResolutionopen => fixed
31-08-2009 17:37Ina SchieferdeckerStatusassigned => resolved
31-08-2009 17:37Ina SchieferdeckerFixed in Version => Edition 4.2.1 (not yet published)
16-02-2010 07:19Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0008941) +
+ Ina Schieferdecker    +
+ 31-08-2009 17:36    +
+ 		+ + + + +
+ Change of invalid to illegal has been provided in v4.1.3 of part 1.
+
+ + diff --git a/docs/mantis/CR5275.md b/docs/mantis/CR5275.md new file mode 100644 index 0000000000000000000000000000000000000000..f76b4c9fd4336147e07a7bb902006a66ab52b15d --- /dev/null +++ b/docs/mantis/CR5275.md @@ -0,0 +1,132 @@ + + + + + + + + + + + + + 0005275: Transitive import is not supported from other languages - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005275Part 09: Using XML with TTCN-3Technicalpublic10-07-2009 12:2701-02-2010 08:39
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.2.1 (published 2010-07)Fixed in Versionv4.2.1 (published 2010-07) 
Clause Reference(s)5.1
For STF discussion
Source (company - Author)L.M. Ericsson
Summary0005275: Transitive import is not supported from other languages
DescriptionWhen importing from other languages, TTCN-3 does not support transitive import. This has to be checked in the case of XSD to TTCN-3 mapping. Part-9 currently says only that XSD imports shall be mapped to TTCN-3 imports. This shall be elaborated more and, if needed, shall be aligned with the generic concept.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0004613closed Gyorgy Rethy Packages and namespaces 
Attached Filesdoc CR5275_resolution v1.doc (88,576) 01-09-2009 09:49
http://oldforge.etsi.org/mantis/file_download.php?file_id=2223&type=bug
doc CR5275_resolution v2.doc (93,184) 01-09-2009 12:20
http://oldforge.etsi.org/mantis/file_download.php?file_id=2224&type=bug
doc CR5275_resolution v3.doc (95,744) 07-12-2009 17:03
http://oldforge.etsi.org/mantis/file_download.php?file_id=2283&type=bug
Issue History
Date ModifiedUsernameFieldChange
10-07-2009 12:27Gyorgy RethyNew Issue
10-07-2009 12:27Gyorgy RethyStatusnew => assigned
10-07-2009 12:27Gyorgy RethyAssigned To => Gyorgy Rethy
10-07-2009 12:27Gyorgy RethyClause Reference(s) => 5.1
10-07-2009 12:27Gyorgy RethySource (company - Author) => L.M. Ericsson
01-09-2009 09:49Gyorgy RethyFile Added: CR5275_resolution v1.doc
01-09-2009 09:55Gyorgy RethyNote Added: 0008944
01-09-2009 10:42Gyorgy RethyRelationship addedrelated to 0004613
01-09-2009 12:20Gyorgy RethyFile Added: CR5275_resolution v2.doc
01-09-2009 12:21Gyorgy RethyNote Added: 0008948
01-09-2009 12:22Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
07-12-2009 14:44Ina SchieferdeckerTarget Version => Edition 4.2.1 (not yet published)
07-12-2009 17:03Ina SchieferdeckerNote Added: 0009085
07-12-2009 17:03Ina SchieferdeckerFile Added: CR5275_resolution v3.doc
07-12-2009 17:03Ina SchieferdeckerAssigned ToIna Schieferdecker => Gyorgy Rethy
07-12-2009 17:03Ina SchieferdeckerResolutionopen => fixed
01-02-2010 08:39Gyorgy RethyStatusassigned => closed
01-02-2010 08:39Gyorgy RethyFixed in Version => Edition 4.2.1 (not yet published)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0008944) +
+ Gyorgy Rethy    +
+ 01-09-2009 09:55    +
+ 		+ + + + +
+ XSD import is similar to TTCN-3 import, not transitive, but components imported in schema B from e.g. schema A and referenced in schema B are visible in schema C as local elements or attributes of the schema B global definition, when schema C imports schema B.
+See text corrections and notes in the attached file CR5275_resolution v1.doc
+
+
+
+ + + + + + + + + + +
+ (0008948) +
+ Gyorgy Rethy    +
+ 01-09-2009 12:21    +
+ 		+ + + + +
+ In CR5275_resolution v2.doc: resolution for CR4613 is added. Also statements on handling selective import statements and importing definitions of the same kind are added. Ready for 1st review.
+
+
+
+ + + + + + + + + + +
+ (0009085) +
+ Ina Schieferdecker    +
+ 07-12-2009 17:03    +
+ 		+ + + + +
+ Seems to be ok ... some reformulations ... please check v3.
+
+ + diff --git a/docs/mantis/CR5278.md b/docs/mantis/CR5278.md new file mode 100644 index 0000000000000000000000000000000000000000..fe370d66cb3bb00fd78e420da7dd6bd9dab5483c --- /dev/null +++ b/docs/mantis/CR5278.md @@ -0,0 +1,114 @@ + + + + + + + + + + + + + 0005278: C.10 and C.26 have the same title - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005278Part 01: TTCN-3 Core LanguageEditorialpublic13-07-2009 11:0416-02-2010 07:15
ReporterGyorgy Rethy 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.1.1 (published 2009-06) 
Target Versionv4.2.1 (published 2010-07)Fixed in Versionv4.2.1 (published 2010-07) 
Clause Reference(s)C.10
Source (company - Author)L.M.Ericsson
Summary0005278: C.10 and C.26 have the same title
DescriptionIf following the convention, I think the title of C.10 should be "Character to octetstring" (string removed). However, a title reflecting more clearly the difference between char2<otherType> and str2<otherType> and vice versa would be even a better solution.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
13-07-2009 11:04Gyorgy RethyNew Issue
13-07-2009 11:04Gyorgy RethyStatusnew => assigned
13-07-2009 11:04Gyorgy RethyAssigned To => Ina Schieferdecker
13-07-2009 11:04Gyorgy RethyClause Reference(s) => C.10
13-07-2009 11:04Gyorgy RethySource (company - Author) => L.M.Ericsson
31-08-2009 17:31Ina SchieferdeckerNote Added: 0008940
31-08-2009 17:31Ina SchieferdeckerAssigned ToIna Schieferdecker => Gyorgy Rethy
31-08-2009 17:31Ina SchieferdeckerResolutionopen => fixed
31-08-2009 17:31Ina SchieferdeckerTarget Version => Edition 4.2.1 (not yet published)
02-09-2009 18:20Gyorgy RethyNote Added: 0008968
02-09-2009 18:21Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
02-09-2009 18:21Gyorgy RethyStatusassigned => resolved
02-09-2009 18:21Gyorgy RethyFixed in Version => Edition 4.2.1 (not yet published)
16-02-2010 07:15Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0008940) +
+ Ina Schieferdecker    +
+ 31-08-2009 17:31    +
+ 		+ + + + +
+ Currently, part 1 says
+
+"
+C.7 Integer to float
+    int2float(in integer invalue) return float
+...
+C.10 Character string to octetstring
+    char2oct(in charstring invalue) return octetstring
+...
+C.26 Character string to octetstring
+    str2oct(in charstring invalue) return octetstring
+..."
+
+Compatible to C7, C10 should indeed be "Character to octetstring"
+
+I think that this is enough to resolve the issue and to have minimal changes only.
+
+Please check.
+
+
+
+ + + + + + + + + + +
+ (0008968) +
+ Gyorgy Rethy    +
+ 02-09-2009 18:20    +
+ 		+ + + + +
+ Fine with me.
+
+ + diff --git a/docs/mantis/CR5279.md b/docs/mantis/CR5279.md new file mode 100644 index 0000000000000000000000000000000000000000..a5adc119fe1555645fe5e2c06a250d8fc5096fa1 --- /dev/null +++ b/docs/mantis/CR5279.md @@ -0,0 +1,133 @@ + + + + + + + + + + + + + 0005279: there is no pre-defined TTCN-3 function str2hex yet - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005279Part 01: TTCN-3 Core LanguageNew Featurepublic13-07-2009 12:3516-02-2010 07:18
ReporterWolfgang Seka 
Assigned ToTibor Csöndes 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.2.1 (published 2010-07)Fixed in Versionv4.2.1 (published 2010-07) 
Clause Reference(s)Part 1: Annex C
Source (company - Author)     
Summary0005279: there is no pre-defined TTCN-3 function str2hex yet
DescriptionFor completeness there shall be a pre-defined TTCN-3 function str2hex:
+
+str2hex shall be similar than str2oct but allow an input string with odd length and result in a hexstring rather than an octetstring.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR5279_str2hex.doc (193,536) 01-09-2009 14:01
http://oldforge.etsi.org/mantis/file_download.php?file_id=2226&type=bug
doc CR5279_str2hex v2.doc (194,048) 02-09-2009 09:57
http://oldforge.etsi.org/mantis/file_download.php?file_id=2229&type=bug
Issue History
Date ModifiedUsernameFieldChange
13-07-2009 12:35Wolfgang SekaNew Issue
13-07-2009 12:35Wolfgang SekaClause Reference(s) => Part 1: Annex C
13-07-2009 12:35Wolfgang SekaSource (company - Author) =>
31-08-2009 15:01Ina SchieferdeckerProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
31-08-2009 15:01Ina SchieferdeckerStatusnew => assigned
31-08-2009 15:01Ina SchieferdeckerAssigned To => Tibor Csöndes
31-08-2009 15:01Ina SchieferdeckerTarget Version => Edition 4.2.1 (not yet published)
01-09-2009 13:50Tibor CsöndesFile Added: CR5279_str2hex.doc
01-09-2009 13:53Tibor CsöndesNote Added: 0008949
01-09-2009 13:57Tibor CsöndesAssigned ToTibor Csöndes => Gyorgy Rethy
01-09-2009 14:01Tibor CsöndesFile Deleted: CR5279_str2hex.doc
01-09-2009 14:01Tibor CsöndesFile Added: CR5279_str2hex.doc
02-09-2009 09:56Gyorgy RethyNote Added: 0008958
02-09-2009 09:56Gyorgy RethyAssigned ToGyorgy Rethy => Tibor Csöndes
02-09-2009 09:57Gyorgy RethyFile Added: CR5279_str2hex v2.doc
02-09-2009 16:33Tibor CsöndesNote Added: 0008965
02-09-2009 16:35Tibor CsöndesStatusassigned => resolved
02-09-2009 16:35Tibor CsöndesResolutionopen => fixed
16-02-2010 07:18Ina SchieferdeckerStatusresolved => closed
16-02-2010 07:18Ina SchieferdeckerFixed in Version => Edition 4.2.1 (not yet published)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0008949) +
+ Tibor Csöndes    +
+ 01-09-2009 13:53    +
+ 		+ + + + +
+ First draft uploaded! (Editorial comment: please put it before str2oct.)
+
+
+
+ + + + + + + + + + +
+ (0008958) +
+ Gyorgy Rethy    +
+ 02-09-2009 09:56    +
+ 		+ + + + +
+ CR5279_str2hex v2.doc: editorial changes, otherwise OK with me.
+
+
+
+ + + + + + + + + + +
+ (0008965) +
+ Tibor Csöndes    +
+ 02-09-2009 16:33    +
+ 		+ + + + +
+ It's OK with me!
+
+ + diff --git a/docs/mantis/CR5280.md b/docs/mantis/CR5280.md new file mode 100644 index 0000000000000000000000000000000000000000..4a5e8038157c5b90b5393affc005cbd9e9b56031 --- /dev/null +++ b/docs/mantis/CR5280.md @@ -0,0 +1,133 @@ + + + + + + + + + + + + + 0005280: Misleading sentence - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005280Part 01: TTCN-3 Core LanguageEditorialpublic13-07-2009 13:4216-02-2010 07:13
ReporterGyorgy Rethy 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.1.1 (published 2009-06) 
Target Versionv4.2.1 (published 2010-07)Fixed in Versionv4.2.1 (published 2010-07) 
Clause Reference(s)C.26
Source (company - Author)L.M.Ericsson
Summary0005280: Misleading sentence
DescriptionThe last sentence before the error causes of C.26 says: "The resulting octetstring will have the same length as the incoming charstring." This is true for the "physical" lengths of the string but not to the length returned by lengthof(). In the latter case the octetstring's length will always be the half of the charstring length, due to the different units (pair of hex digits vs. characters)
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
13-07-2009 13:42Gyorgy RethyNew Issue
13-07-2009 13:42Gyorgy RethyStatusnew => assigned
13-07-2009 13:42Gyorgy RethyAssigned To => Ina Schieferdecker
13-07-2009 13:42Gyorgy RethyClause Reference(s) => C.26
13-07-2009 13:42Gyorgy RethySource (company - Author) => L.M.Ericsson
31-08-2009 17:43Ina SchieferdeckerNote Added: 0008942
31-08-2009 17:44Ina SchieferdeckerResolutionopen => fixed
31-08-2009 17:44Ina SchieferdeckerTarget Version => Edition 4.2.1 (not yet published)
31-08-2009 17:44Ina SchieferdeckerNote Added: 0008943
31-08-2009 17:44Ina SchieferdeckerAssigned ToIna Schieferdecker => Gyorgy Rethy
02-09-2009 18:24Gyorgy RethyNote Added: 0008969
02-09-2009 18:24Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
02-09-2009 18:24Gyorgy RethyStatusassigned => resolved
02-09-2009 18:24Gyorgy RethyFixed in Version => Edition 4.2.1 (not yet published)
16-02-2010 07:13Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0008942) +
+ Ina Schieferdecker    +
+ 31-08-2009 17:43    +
+ 		+ + + + +
+ Change "The resulting octetstring will have the same length as the incoming charstring." to
+
+"lengthof (see clause C.28) for the resulting octetstring will return half of lengthof of the incoming charstring."
+
+
+
+ + + + + + + + + + +
+ (0008943) +
+ Ina Schieferdecker    +
+ 31-08-2009 17:44    +
+ 		+ + + + +
+ Please check
+
+
+
+ + + + + + + + + + +
+ (0008969) +
+ Gyorgy Rethy    +
+ 02-09-2009 18:24    +
+ 		+ + + + +
+ Fine with me.
+
+ + diff --git a/docs/mantis/CR5281.md b/docs/mantis/CR5281.md new file mode 100644 index 0000000000000000000000000000000000000000..164144514cf8c1b51e2aa987ffeaba2efb4e12ac --- /dev/null +++ b/docs/mantis/CR5281.md @@ -0,0 +1,102 @@ + + + + + + + + + + + + + 0005281: different semantics for str2oct and hex2oct in case of input parameter of odd length - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005281Part 01: TTCN-3 Core LanguageClarificationpublic13-07-2009 15:2316-02-2010 07:10
ReporterWolfgang Seka 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.2.1 (published 2010-07)Fixed in Versionv4.2.1 (published 2010-07) 
Clause Reference(s)Part 1 Annex C.26
Source (company - Author)     
Summary0005281: different semantics for str2oct and hex2oct in case of input parameter of odd length
Descriptionacc. to C.18 it is allowed to hand over a hexstring of odd length to hex2oct:
+   hex2oct ('1D7'H)= '01D7'O // no error acc. to C.18
+whereas it is an error to hand over a charstring with odd length to str2oct:
+   str2oct ("1D7") // error acc. to C.26
+
+=> it may be check whether the same semantics can be applied for C.26 as for C.18
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR5281_hex2oct_str2oct.doc (132,608) 04-09-2009 09:53
http://oldforge.etsi.org/mantis/file_download.php?file_id=2239&type=bug
doc CR5281_hex2oct_str2oct v2.doc (133,120) 09-09-2009 10:58
http://oldforge.etsi.org/mantis/file_download.php?file_id=2251&type=bug
Issue History
Date ModifiedUsernameFieldChange
13-07-2009 15:23Wolfgang SekaNew Issue
13-07-2009 15:23Wolfgang SekaClause Reference(s) => Part 1 Annex C.26
13-07-2009 15:23Wolfgang SekaSource (company - Author) =>
31-08-2009 14:58Ina SchieferdeckerProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
31-08-2009 14:58Ina SchieferdeckerStatusnew => assigned
31-08-2009 14:58Ina SchieferdeckerAssigned To => Tibor Csöndes
31-08-2009 15:00Ina SchieferdeckerTarget Version => Edition 4.2.1 (not yet published)
04-09-2009 09:53Tibor CsöndesFile Added: CR5281_hex2oct_str2oct.doc
04-09-2009 09:54Tibor CsöndesNote Added: 0008979
04-09-2009 09:54Tibor CsöndesAssigned ToTibor Csöndes => Gyorgy Rethy
09-09-2009 10:58Gyorgy RethyFile Added: CR5281_hex2oct_str2oct v2.doc
09-09-2009 10:59Gyorgy RethyNote Added: 0008991
09-09-2009 10:59Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
09-09-2009 10:59Gyorgy RethyStatusassigned => resolved
09-09-2009 10:59Gyorgy RethyResolutionopen => fixed
09-09-2009 10:59Gyorgy RethyFixed in Version => Edition 4.2.1 (not yet published)
16-02-2010 07:10Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0008979) +
+ Tibor Csöndes    +
+ 04-09-2009 09:54    +
+ 		+ + + + +
+ First draft version uploaded.
+
+
+
+ + + + + + + + + + +
+ (0008991) +
+ Gyorgy Rethy    +
+ 09-09-2009 10:59    +
+ 		+ + + + +
+ CR5281_hex2oct_str2oct v2.doc: OK with me (just a minor editorial change).
+
+ + diff --git a/docs/mantis/CR5291.md b/docs/mantis/CR5291.md new file mode 100644 index 0000000000000000000000000000000000000000..ca5ae7e2c9a2ce4d5a36c99866cec349a1837f54 --- /dev/null +++ b/docs/mantis/CR5291.md @@ -0,0 +1,94 @@ + + + + + + + + + + + + + 0005291: BNF - friend definitions should have no visibility - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005291Part 01: TTCN-3 Core LanguageEditorialpublic27-07-2009 15:1117-08-2009 14:24
ReporterGyorgy Rethy 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.1.1 (published 2009-06) 
Target Versionv4.2.1 (published 2010-07)Fixed in Versionv4.2.1 (published 2010-07) 
Clause Reference(s)A.1.6.1.0 General
Source (company - Author)L.M.Ericsson
Summary0005291: BNF - friend definitions should have no visibility
DescriptionThe current BNF allows visibility for friend definitions, while the textual part (clause 8.2.4) does not:
+8.2.4 Definition of friend modules
+  Syntactical Structure
+  friend module ModuleIdentifier { "," ModuleIdentifier } ";"
+
+On the other hand side clause 8.2.5 says "(top level definitions) They are by default public except for imported definitions which are by default private."
+
+Thus friend definitions, according to $8.2.5, should be public. But, in fact, they have meaning for the given module only and they are not importable; hence, as a matter of fact, they are always private.
+-------------------
+Two solutions are possible:
+1) (preferred) Make the private keyword mandatory in $8.2.4:
+Syntactical Structure
+  private friend module ModuleIdentifier { "," ModuleIdentifier } ";"
+
+2) Modify the text in $8.2.5:
+"They are by default public except for imported definitions and friend definitions which are by default private.
+...
+The visibility of imported definitions and friend definitions are by default always private. All other module definitions are by default public."
+-------------
+Solution 1), though would introduce a mandatory syntax, which is optional for other definitions, is the preferred one, as solution 2) would introduce a new exception; users looking at a friend definitions without a visibility keyword could think that friend lists are also imported.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
27-07-2009 15:11Gyorgy RethyNew Issue
27-07-2009 15:11Gyorgy RethyStatusnew => assigned
27-07-2009 15:11Gyorgy RethyAssigned To => Ina Schieferdecker
27-07-2009 15:11Gyorgy RethyClause Reference(s) => A.1.6.1.0 General
27-07-2009 15:11Gyorgy RethySource (company - Author) => L.M.Ericsson
27-07-2009 15:50Gyorgy RethyDescription Updated
27-07-2009 16:02Gyorgy RethyDescription Updated
11-08-2009 06:44Ina SchieferdeckerNote Added: 0008922
17-08-2009 14:24Ina SchieferdeckerResolutionopen => fixed
17-08-2009 14:24Ina SchieferdeckerFixed in Version => Edition 4.2.1 (not yet published)
17-08-2009 14:24Ina SchieferdeckerTarget Version => Edition 4.2.1 (not yet published)
17-08-2009 14:24Ina SchieferdeckerStatusassigned => resolved
17-08-2009 14:24Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0008922) +
+ Ina Schieferdecker    +
+ 11-08-2009 06:44    +
+ 		+ + + + +
+ In analogy to groups, which can be public only, a solution can be:
+
+[ private ] friend module ModuleIdentifier { "," ModuleIdentifier } ";"
+
+Adding a restriction:
+
+In addition to the general static rules of TTCN 3 given in clause 5, the following restrictions apply:
+
+a) Only private visibility can be defined for friend definitions as they are always private.
+
+And extending 8.2.5 accordingly:
+
+Top-level module definitions and import statements have a visibility, which can be explicitly set. They are by default public except for imported and friend definitions. Import definitions are by default private. Friend definitions are private only. Group definitions are public only.
+
+ + diff --git a/docs/mantis/CR5294.md b/docs/mantis/CR5294.md new file mode 100644 index 0000000000000000000000000000000000000000..98cc252380533efb0ff9dfb982502e0b86fde259 --- /dev/null +++ b/docs/mantis/CR5294.md @@ -0,0 +1,81 @@ + + + + + + + + + + + + + 0005294: Wrong element name in an example - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005294Part 09: Using XML with TTCN-3Editorialpublic05-08-2009 12:2507-12-2009 14:45
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.3.1 (published 2008-04) 
Target Versionv4.2.1 (published 2010-07)Fixed in Versionv4.2.1 (published 2010-07) 
Clause Reference(s)7.6.2.1 Complex content derived by extending complex types
For STF discussion
Source (company - Author)L.M.Ericsson
Summary0005294: Wrong element name in an example
DescriptionIn Example3,
+<complexType name="e25cho">
+    <choice>
+        <element name="titleElemBase" type="string"/>
+        <element name="forenameElemBase" type="string"/>
+        <element name="forenameElemBase" type="string"/>
+    </choice>
+    <attribute name="genderAttrBase" type="string"/>
+</complexType>
+should be (see the 2nd occurance of "forenameElemBase" above)
+<complexType name="e25cho">
+    <choice>
+        <element name="titleElemBase" type="string"/>
+        <element name="forenameElemBase" type="string"/>
+        <element name="surnameElemBase" type="string"/>
+    </choice>
+    <attribute name="genderAttrBase" type="string"/>
+</complexType>
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
05-08-2009 12:25Gyorgy RethyNew Issue
05-08-2009 12:25Gyorgy RethyStatusnew => assigned
05-08-2009 12:25Gyorgy RethyAssigned To => Gyorgy Rethy
05-08-2009 12:25Gyorgy RethyClause Reference(s) => 7.6.2.1 Complex content derived by extending complex types
05-08-2009 12:25Gyorgy RethySource (company - Author) => L.M.Ericsson
01-09-2009 10:14Gyorgy RethyNote Added: 0008945
01-09-2009 10:14Gyorgy RethyStatusassigned => closed
01-09-2009 10:14Gyorgy RethyResolutionopen => fixed
01-09-2009 10:14Gyorgy RethyFixed in Version => Edition 4.2.1 (not yet published)
07-12-2009 14:45Ina SchieferdeckerTarget Version => Edition 4.2.1 (not yet published)
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0008945) +
+ Gyorgy Rethy    +
+ 01-09-2009 10:14    +
+ 		+ + + + +
+ Implemented in master copy: as proposed.
+
+ + diff --git a/docs/mantis/CR5314.md b/docs/mantis/CR5314.md new file mode 100644 index 0000000000000000000000000000000000000000..57c6baf9883840b994a7dfc401fb55ca0aafcc9f --- /dev/null +++ b/docs/mantis/CR5314.md @@ -0,0 +1,83 @@ + + + + + + + + + + + + + 0005314: BNF inconsistencies introduced in v4.1.1 (FriendModule & TemplateRestriction) - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005314Part 01: TTCN-3 Core LanguageTechnicalpublic01-09-2009 11:5908-09-2009 08:26
ReporterAnthony Baire 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.2.1 (published 2010-07)Fixed in Versionv4.2.1 (published 2010-07) 
Clause Reference(s)A.1.6 and 15.8
Source (company - Author)     
Summary0005314: BNF inconsistencies introduced in v4.1.1 (FriendModule & TemplateRestriction)
DescriptionSome BNF changes introduced in 4.1.1 are not well defined :
+
+
+1. FriendModuleDef ::= "friend" "module" TTCN3ModuleId {"," TTCN3ModuleId } [SemiColon]
+
+    - the 'TTCN3ModuleId' should be replaced with 'ModuleIdentifier' because TTCN3ModuleId allows to include a LanguageSpec
+    - the optional semicolon is superfluous and can cause conflicts since it is already allowed in the parent rule ModuleDefinitionList
+
+  --> FriendModuleDef ::= "friend" "module" ModuleIdentifier {"," ModuleIdentifier }
+
+
+2. TemplateRestriction ::= "(" OmitKeyword | ValueKeyword | PresentKeyword ")"
+
+    - the keyword list should be grouped within a parenthesis block because the concatenation has precedence over the '|' operator
+
+  --> TemplateRestriction ::= "(" ( OmitKeyword | ValueKeyword | PresentKeyword ) ")"
+
+      Note: the same fix should be applied in the section 15.8
+
+
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
01-09-2009 11:59Anthony BaireNew Issue
01-09-2009 11:59Anthony BaireClause Reference(s) => A.1.6 and 15.8
01-09-2009 11:59Anthony BaireSource (company - Author) =>
02-09-2009 12:14Ina SchieferdeckerProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
02-09-2009 12:15Ina SchieferdeckerAssigned To => Ina Schieferdecker
02-09-2009 12:15Ina SchieferdeckerStatusnew => assigned
02-09-2009 12:15Ina SchieferdeckerTarget Version => Edition 4.2.1 (not yet published)
02-09-2009 12:15Ina SchieferdeckerDescription Updated
08-09-2009 08:20Ina SchieferdeckerNote Added: 0008986
08-09-2009 08:21Ina SchieferdeckerResolutionopen => fixed
08-09-2009 08:21Ina SchieferdeckerFixed in Version => Edition 4.2.1 (not yet published)
08-09-2009 08:26Ina SchieferdeckerStatusassigned => resolved
08-09-2009 08:26Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0008986) +
+ Ina Schieferdecker    +
+ 08-09-2009 08:20    +
+ 		+ + + + +
+ Right. Resolved as proposed.
+
+ + diff --git a/docs/mantis/CR5319.md b/docs/mantis/CR5319.md new file mode 100644 index 0000000000000000000000000000000000000000..19dd31477073f7f0db6feff65c635a636842eb8f --- /dev/null +++ b/docs/mantis/CR5319.md @@ -0,0 +1,74 @@ + + + + + + + + + + + + + 0005319: Type is missing in example - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005319Part 09: Using XML with TTCN-3Editorialpublic02-09-2009 11:0102-09-2009 16:36
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.3.1 (published 2008-04) 
Target Versionv4.2.1 (published 2010-07)Fixed in Versionv4.2.1 (published 2010-07) 
Clause Reference(s)C.2
For STF discussion
Source (company - Author)L.M.Ericsson
Summary0005319: Type is missing in example
Description    template t_C1:= {
+        base :=-1,
+        a1 :=1,
+        a2 :=2.0
+    }
+should be
+    template C1 t_C1:= {
+        base :=-1,
+        a1 :=1,
+        a2 :=2.0
+    }
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
02-09-2009 11:01Gyorgy RethyNew Issue
02-09-2009 11:01Gyorgy RethyStatusnew => assigned
02-09-2009 11:01Gyorgy RethyAssigned To => Gyorgy Rethy
02-09-2009 11:01Gyorgy RethyClause Reference(s) => C.2
02-09-2009 11:01Gyorgy RethySource (company - Author) => L.M.Ericsson
02-09-2009 16:35Gyorgy RethyNote Added: 0008966
02-09-2009 16:36Gyorgy RethyStatusassigned => closed
02-09-2009 16:36Gyorgy RethyResolutionopen => fixed
02-09-2009 16:36Gyorgy RethyFixed in Version => Edition 4.2.1 (not yet published)
02-09-2009 16:36Gyorgy RethyTarget Version => Edition 4.2.1 (not yet published)
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0008966) +
+ Gyorgy Rethy    +
+ 02-09-2009 16:35    +
+ 		+ + + + +
+ Similar error are corrected in templates of C.2, C.3 and C.4
+
+ + diff --git a/docs/mantis/CR5326.md b/docs/mantis/CR5326.md new file mode 100644 index 0000000000000000000000000000000000000000..bf3ea3751c0dd1693d5813d575d613c30595701c --- /dev/null +++ b/docs/mantis/CR5326.md @@ -0,0 +1,136 @@ + + + + + + + + + + + + + 0005326: Conformance and compatibility clause is missing - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005326Part 09: Using XML with TTCN-3Clarificationpublic04-09-2009 12:1401-02-2010 08:52
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.3.1 (published 2008-04) 
Target Versionv4.2.1 (published 2010-07)Fixed in Versionv4.2.1 (published 2010-07) 
Clause Reference(s)4
For STF discussion
Source (company - Author)L.M.Ericsson
Summary0005326: Conformance and compatibility clause is missing
DescriptionIn the current version the "standard" conformance and compatibility clause (4.1) is missing.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR5326_resolution v1.doc (89,088) 04-09-2009 15:31
http://oldforge.etsi.org/mantis/file_download.php?file_id=2246&type=bug
Issue History
Date ModifiedUsernameFieldChange
04-09-2009 12:14Gyorgy RethyNew Issue
04-09-2009 12:14Gyorgy RethyStatusnew => assigned
04-09-2009 12:14Gyorgy RethyAssigned To => Gyorgy Rethy
04-09-2009 12:14Gyorgy RethyClause Reference(s) => 4
04-09-2009 12:14Gyorgy RethySource (company - Author) => L.M.Ericsson
04-09-2009 12:24Gyorgy RethyNote Added: 0008980
04-09-2009 12:24Gyorgy RethyFile Added: CR5326_resolution v1.doc
04-09-2009 12:24Gyorgy RethyNote Edited: 0008980
04-09-2009 12:25Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
04-09-2009 12:25Gyorgy RethyResolutionopen => fixed
04-09-2009 12:25Gyorgy RethyFixed in Version => Edition 4.2.1 (not yet published)
04-09-2009 12:25Gyorgy RethyTarget Version => Edition 4.2.1 (not yet published)
04-09-2009 15:26Gyorgy RethyFile Deleted: CR5326_resolution v1.doc
04-09-2009 15:26Gyorgy RethyFile Added: CR5326_resolution v1.doc
04-09-2009 15:30Gyorgy RethyFile Deleted: CR5326_resolution v1.doc
04-09-2009 15:31Gyorgy RethyFile Added: CR5326_resolution v1.doc
04-09-2009 15:33Gyorgy RethyNote Edited: 0008980
08-12-2009 07:36Ina SchieferdeckerNote Added: 0009091
08-12-2009 07:37Ina SchieferdeckerAssigned ToIna Schieferdecker => Gyorgy Rethy
08-12-2009 07:37Ina SchieferdeckerStatusassigned => resolved
01-02-2010 08:49Gyorgy RethyStatusresolved => feedback
01-02-2010 08:49Gyorgy RethyResolutionfixed => reopened
01-02-2010 08:49Gyorgy RethyNote Added: 0009169
01-02-2010 08:50Gyorgy RethyNote Edited: 0009169
01-02-2010 08:51Gyorgy RethyNote Edited: 0009169
01-02-2010 08:52Gyorgy RethyStatusfeedback => closed
01-02-2010 08:52Gyorgy RethyResolutionreopened => fixed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0008980) +
+ Gyorgy Rethy    +
+ 04-09-2009 12:24    +
(edited on: 04-09-2009 15:33)
+ 		+ + + + +
+ CR5326_resolution v1.doc: draft for CR resolution. Part-9 v4.2.1 is not compatible with earlier versions (e.g. with v4.1.1) because it talks about importing imports (its forbidden from XSD documents).
+Pls. review.
+
+
+
+
+
+ + + + + + + + + + +
+ (0009091) +
+ Ina Schieferdecker    +
+ 08-12-2009 07:36    +
+ 		+ + + + +
+ ok - except that I do not understand the previous import: import of imports is defined for TTCN-3 modules only, but not for imports from non-TTCN-3 artefacts. In other words, the new feature of imports of imports in TTCN-3 does not impact the language mappings.
+
+
+
+ + + + + + + + + + +
+ (0009169) +
+ Gyorgy Rethy    +
+ 01-02-2010 08:49    +
(edited on: 01-02-2010 08:51)
+ 		+ + + + +
+ Technically your comment is correct. But this is covered in CR5275; CR5275 clarifies that import of imports is not allowed in case of XSD mapping.
+
+
+
+ + diff --git a/docs/mantis/CR5327.md b/docs/mantis/CR5327.md new file mode 100644 index 0000000000000000000000000000000000000000..29357ac8fedb9f825842aaa2fa54a0bd60d0ba07 --- /dev/null +++ b/docs/mantis/CR5327.md @@ -0,0 +1,173 @@ + + + + + + + + + + + + + 0005327: Add a @reference tag - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 10: TTCN-3 documentation tags
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005327Part 10: TTCN-3 documentation tagsNew Featurepublic04-09-2009 13:3901-02-2010 14:23
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.4.1 (published 2008-09) 
Target Versionv4.2.1 (published 2010-07)Fixed in Versionv4.2.1 (published 2010-07) 
Source (company - Author)L.M.Ericsson
Summary0005327: Add a @reference tag
DescriptionCurrently there in no tag to document a reference for a test case, e.g. a standard clause. In many cases test cases are not developed in TTCN-3 in the standard, therefore this refernce is needed to bind the test case to the specification of the test.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0005798closed Gyorgy Rethy Add the @reference tag 
Attached Filesdoc CR5327_resolution_v1.doc (118,784) 09-09-2009 12:30
http://oldforge.etsi.org/mantis/file_download.php?file_id=2255&type=bug
doc CR5327_resolution_v2.doc (122,368) 07-12-2009 17:22
http://oldforge.etsi.org/mantis/file_download.php?file_id=2285&type=bug
doc CR5327_resolution_v3.doc (124,416) 08-12-2009 14:31
http://oldforge.etsi.org/mantis/file_download.php?file_id=2292&type=bug
Issue History
Date ModifiedUsernameFieldChange
04-09-2009 13:39Gyorgy RethyNew Issue
04-09-2009 13:39Gyorgy RethyStatusnew => assigned
04-09-2009 13:39Gyorgy RethyAssigned To => Gyorgy Rethy
04-09-2009 13:39Gyorgy RethySource (company - Author) => L.M.Ericsson
09-09-2009 12:30Gyorgy RethyFile Added: CR5327_resolution_v1.doc
09-09-2009 12:31Gyorgy RethyNote Added: 0008992
09-09-2009 12:31Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
07-12-2009 14:41Ina SchieferdeckerTarget Version => Edition 4.2.1 (not yet published)
07-12-2009 17:22Ina SchieferdeckerNote Added: 0009087
07-12-2009 17:22Ina SchieferdeckerFile Added: CR5327_resolution_v2.doc
08-12-2009 14:29Ina SchieferdeckerNote Added: 0009096
08-12-2009 14:31Ina SchieferdeckerFile Added: CR5327_resolution_v3.doc
08-12-2009 14:31Ina SchieferdeckerAssigned ToIna Schieferdecker => Gyorgy Rethy
08-12-2009 14:31Ina SchieferdeckerResolutionopen => fixed
08-12-2009 14:31Ina SchieferdeckerFixed in Version => Edition 4.2.1 (not yet published)
01-02-2010 14:23Gyorgy RethyNote Added: 0009181
01-02-2010 14:23Gyorgy RethyStatusassigned => closed
01-12-2010 10:40Gyorgy RethyRelationship addedrelated to 0005798
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0008992) +
+ Gyorgy Rethy    +
+ 09-09-2009 12:31    +
+ 		+ + + + +
+ CR5327_resolution_v1.doc: to be reviewed
+
+
+
+ + + + + + + + + + +
+ (0009087) +
+ Ina Schieferdecker    +
+ 07-12-2009 17:22    +
+ 		+ + + + +
+ The resolution proposes to
+(1) have documentation tags also for local definitions of component types and
+(2) have the reference tag.
+
+(1) is ok
+
+For (2) however, the relation to the @see tag is unclear - why to have two tags with similar meaning? Also, if at all, @reference should be optional only - for test process matters and for backward compatibility.
+
+This CR needs to be discussed.
+
+
+
+ + + + + + + + + + +
+ (0009096) +
+ Ina Schieferdecker    +
+ 08-12-2009 14:29    +
+ 		+ + + + +
+ Agreed to support documentation tags for local definitions of component types, but not add the @reference tag - see v3
+
+
+
+ + + + + + + + + + +
+ (0009181) +
+ Gyorgy Rethy    +
+ 01-02-2010 14:23    +
+ 		+ + + + +
+ Implemented acc. to Ina's note.
+
+ + diff --git a/docs/mantis/CR5328.md b/docs/mantis/CR5328.md new file mode 100644 index 0000000000000000000000000000000000000000..ae4fd40aeba2140fb594091a6bcdded325975dfd --- /dev/null +++ b/docs/mantis/CR5328.md @@ -0,0 +1,131 @@ + + + + + + + + + + + + + 0005328: Add a @requirement tag - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 10: TTCN-3 documentation tags
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005328Part 10: TTCN-3 documentation tagsNew Featurepublic04-09-2009 13:4201-02-2010 14:28
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.4.1 (published 2008-09) 
Target Versionv4.2.1 (published 2010-07)Fixed in Versionv4.2.1 (published 2010-07) 
Source (company - Author)L.M.Ericsson
Summary0005328: Add a @requirement tag
DescriptionCurrently there is no @requirement tag. test cases are often bound to requirements that shall also be documented in a clear way (i.e. not hidden in a remark)
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR5328_resolution_v1.doc (113,664) 09-09-2009 16:04
http://oldforge.etsi.org/mantis/file_download.php?file_id=2256&type=bug
doc CR5328_resolution_v2.doc (115,712) 07-12-2009 17:37
http://oldforge.etsi.org/mantis/file_download.php?file_id=2286&type=bug
Issue History
Date ModifiedUsernameFieldChange
04-09-2009 13:42Gyorgy RethyNew Issue
04-09-2009 13:42Gyorgy RethyStatusnew => assigned
04-09-2009 13:42Gyorgy RethyAssigned To => Gyorgy Rethy
04-09-2009 13:42Gyorgy RethySource (company - Author) => L.M.Ericsson
09-09-2009 16:04Gyorgy RethyFile Added: CR5328_resolution_v1.doc
09-09-2009 16:04Gyorgy RethyNote Added: 0008993
09-09-2009 16:04Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
07-12-2009 14:41Ina SchieferdeckerTarget Version => Edition 4.2.1 (not yet published)
07-12-2009 17:37Ina SchieferdeckerNote Added: 0009088
07-12-2009 17:37Ina SchieferdeckerFile Added: CR5328_resolution_v2.doc
08-12-2009 14:32Ina SchieferdeckerAssigned ToIna Schieferdecker => Gyorgy Rethy
08-12-2009 14:32Ina SchieferdeckerResolutionopen => fixed
08-12-2009 14:32Ina SchieferdeckerFixed in Version => Edition 4.2.1 (not yet published)
01-02-2010 14:28Gyorgy RethyNote Added: 0009182
01-02-2010 14:28Gyorgy RethyStatusassigned => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0008993) +
+ Gyorgy Rethy    +
+ 09-09-2009 16:04    +
+ 		+ + + + +
+ CR5328_resolution_v1.doc: ready for review
+
+
+
+ + + + + + + + + + +
+ (0009088) +
+ Ina Schieferdecker    +
+ 07-12-2009 17:37    +
+ 		+ + + + +
+ In principle ok. See v2 for some rewording incl. to make the tag an optional one.
+
+
+
+ + + + + + + + + + +
+ (0009182) +
+ Gyorgy Rethy    +
+ 01-02-2010 14:28    +
+ 		+ + + + +
+ Implemented acc. to CR5328_resolution_v2.doc.
+
+ + diff --git a/docs/mantis/CR5329.md b/docs/mantis/CR5329.md new file mode 100644 index 0000000000000000000000000000000000000000..84a766b96215d9ed43647a6a4746d27b7e5bca5a --- /dev/null +++ b/docs/mantis/CR5329.md @@ -0,0 +1,97 @@ + + + + + + + + + + + + + 0005329: Add a @priority tag - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 10: TTCN-3 documentation tags
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005329Part 10: TTCN-3 documentation tagsNew Featurepublic04-09-2009 13:4701-02-2010 14:53
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.4.1 (published 2008-09) 
Target Versionv4.2.1 (published 2010-07)Fixed in Versionv4.2.1 (published 2010-07) 
Source (company - Author)L.M.Ericsson
Summary0005329: Add a @priority tag
DescriptionToday the @status tag exists but this is more related to the lifecycle of objects - under development, verified, deprecated etc. It is also often required to document the priority of test cases (for example high priority ones are always executed, medium ones executed during function test, low priority ones during function tests if time allows). therefore a @priority tag is also needed.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR5329_resolution_v2.doc (109,056) 09-09-2009 11:41
http://oldforge.etsi.org/mantis/file_download.php?file_id=2253&type=bug
doc CR5329_resolution_v3.doc (111,104) 07-12-2009 17:10
http://oldforge.etsi.org/mantis/file_download.php?file_id=2284&type=bug
Issue History
Date ModifiedUsernameFieldChange
04-09-2009 13:47Gyorgy RethyNew Issue
04-09-2009 13:47Gyorgy RethyStatusnew => assigned
04-09-2009 13:47Gyorgy RethyAssigned To => Gyorgy Rethy
04-09-2009 13:47Gyorgy RethySource (company - Author) => L.M.Ericsson
09-09-2009 11:22Gyorgy RethyFile Added: CR5329_resolution_v1.doc
09-09-2009 11:23Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
09-09-2009 11:41Gyorgy RethyFile Added: CR5329_resolution_v2.doc
09-09-2009 11:41Gyorgy RethyFile Deleted: CR5329_resolution_v1.doc
07-12-2009 14:42Ina SchieferdeckerTarget Version => Edition 4.2.1 (not yet published)
07-12-2009 17:09Ina SchieferdeckerNote Added: 0009086
07-12-2009 17:10Ina SchieferdeckerFile Added: CR5329_resolution_v3.doc
08-12-2009 14:31Ina SchieferdeckerAssigned ToIna Schieferdecker => Gyorgy Rethy
08-12-2009 14:31Ina SchieferdeckerResolutionopen => fixed
08-12-2009 14:31Ina SchieferdeckerFixed in Version => Edition 4.2.1 (not yet published)
01-02-2010 14:51Gyorgy RethyNote Added: 0009183
01-02-2010 14:53Gyorgy RethyStatusassigned => closed
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009086) +
+ Ina Schieferdecker    +
+ 07-12-2009 17:09    +
+ 		+ + + + +
+ In principal ok - but made @priority an optional tag - not only from the test process perspective, but also for backward compatibility reasons. Please check v3.
+
+
+
+ + + + + + + + + + +
+ (0009183) +
+ Gyorgy Rethy    +
+ 01-02-2010 14:51    +
+ 		+ + + + +
+ "shall contain at most one @priority tag" means 0 or 1, i.e. the tag was optional according to the original proposal. Pls. note that acc. to error handling rules unrecognized tags shall be ignored, i.e. backward compatibility assured for all editions automaticaly. v3 is implemented taking this into account.
+
+ + diff --git a/docs/mantis/CR5330.md b/docs/mantis/CR5330.md new file mode 100644 index 0000000000000000000000000000000000000000..296b455af69b903834827f8dab2428e8ce6a2756 --- /dev/null +++ b/docs/mantis/CR5330.md @@ -0,0 +1,131 @@ + + + + + + + + + + + + + 0005330: Compatibility information is missing - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 10: TTCN-3 documentation tags
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005330Part 10: TTCN-3 documentation tagsClarificationpublic04-09-2009 13:4901-02-2010 14:21
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.4.1 (published 2008-09) 
Target Versionv4.2.1 (published 2010-07)Fixed in Versionv4.2.1 (published 2010-07) 
Source (company - Author)L.M.Ericsson
Summary0005330: Compatibility information is missing
Descriptionas agreed in TC MTS, in packages and parts also a compatibility statement shall be added. This is currently missing in part 10.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR5330_resolution_v1.doc (56,832) 04-09-2009 15:18
http://oldforge.etsi.org/mantis/file_download.php?file_id=2244&type=bug
doc CR5330_resolution_v2.doc (59,392) 07-12-2009 17:42
http://oldforge.etsi.org/mantis/file_download.php?file_id=2287&type=bug
Issue History
Date ModifiedUsernameFieldChange
04-09-2009 13:49Gyorgy RethyNew Issue
04-09-2009 13:49Gyorgy RethyStatusnew => assigned
04-09-2009 13:49Gyorgy RethyAssigned To => Gyorgy Rethy
04-09-2009 13:49Gyorgy RethySource (company - Author) => L.M.Ericsson
04-09-2009 14:16Gyorgy RethyFile Added: CR5330_resolution_v1.doc
04-09-2009 14:17Gyorgy RethyNote Added: 0008983
04-09-2009 14:17Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
04-09-2009 14:17Gyorgy RethyResolutionopen => fixed
04-09-2009 14:17Gyorgy RethyFixed in Version => Edition 4.2.1 (not yet published)
04-09-2009 14:17Gyorgy RethyTarget Version => Edition 4.2.1 (not yet published)
04-09-2009 15:18Gyorgy RethyFile Deleted: CR5330_resolution_v1.doc
04-09-2009 15:18Gyorgy RethyFile Added: CR5330_resolution_v1.doc
07-12-2009 17:42Ina SchieferdeckerNote Added: 0009089
07-12-2009 17:42Ina SchieferdeckerFile Added: CR5330_resolution_v2.doc
08-12-2009 14:32Ina SchieferdeckerAssigned ToIna Schieferdecker => Gyorgy Rethy
08-12-2009 14:32Ina SchieferdeckerStatusassigned => resolved
01-02-2010 14:20Gyorgy RethyStatusresolved => closed
01-02-2010 14:20Gyorgy RethyNote Added: 0009180
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0008983) +
+ Gyorgy Rethy    +
+ 04-09-2009 14:17    +
+ 		+ + + + +
+ CR5330_resolution_v1.doc: draft for CR resolution, ready for review.
+
+
+
+ + + + + + + + + + +
+ (0009089) +
+ Ina Schieferdecker    +
+ 07-12-2009 17:42    +
+ 		+ + + + +
+ In principle ok - just see some rewording in v2.
+
+
+
+ + + + + + + + + + +
+ (0009180) +
+ Gyorgy Rethy    +
+ 01-02-2010 14:20    +
+ 		+ + + + +
+ Implemented in master copy (v3.5.2)
+
+ + diff --git a/docs/mantis/CR5331.md b/docs/mantis/CR5331.md new file mode 100644 index 0000000000000000000000000000000000000000..f325592021d3f19f7ba0540e7e1a55cf6258e444 --- /dev/null +++ b/docs/mantis/CR5331.md @@ -0,0 +1,168 @@ + + + + + + + + + + + + + 0005331: Compatibility statement to be added - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 07: Using ASN.1 with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005331Part 07: Using ASN.1 with TTCN-3Clarificationpublic04-09-2009 13:5901-02-2010 15:46
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.1.1 (published 2009-06) 
Target Versionv4.2.1 (published 2010-07)Fixed in Versionv4.2.1 (published 2010-07) 
Clause Reference(s)4.1
Source (company - Author)L.M.Ericsson
Summary0005331: Compatibility statement to be added
DescriptionAs agreed by TC MTS, not all parts of the TTCN-3 standard ara published together but the ones containing changes and consequently a compatibility statement to be added to the parts and packages.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR5331_resolution_v1.doc (126,464) 04-09-2009 15:36
http://oldforge.etsi.org/mantis/file_download.php?file_id=2247&type=bug
doc CR5331_resolution_v2.doc (129,024) 08-09-2009 09:38
http://oldforge.etsi.org/mantis/file_download.php?file_id=2249&type=bug
Issue History
Date ModifiedUsernameFieldChange
04-09-2009 13:59Gyorgy RethyNew Issue
04-09-2009 13:59Gyorgy RethyStatusnew => assigned
04-09-2009 13:59Gyorgy RethyAssigned To => Gyorgy Rethy
04-09-2009 13:59Gyorgy RethyClause Reference(s) => 4.1
04-09-2009 13:59Gyorgy RethySource (company - Author) => L.M.Ericsson
04-09-2009 14:05Gyorgy RethyFile Added: CR5331_resolution_v1.doc
04-09-2009 14:06Gyorgy RethyNote Added: 0008981
04-09-2009 14:06Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
04-09-2009 14:06Gyorgy RethyResolutionopen => fixed
04-09-2009 14:06Gyorgy RethyFixed in Version => Edition 4.2.1 (not yet published)
04-09-2009 14:06Gyorgy RethyTarget Version => Edition 4.2.1 (not yet published)
04-09-2009 15:15Gyorgy RethyFile Deleted: CR5331_resolution_v1.doc
04-09-2009 15:15Gyorgy RethyFile Added: CR5331_resolution_v1.doc
04-09-2009 15:34Gyorgy RethyFile Deleted: CR5331_resolution_v1.doc
04-09-2009 15:35Gyorgy RethyNote Edited: 0008981
04-09-2009 15:36Gyorgy RethyFile Added: CR5331_resolution_v1.doc
08-09-2009 09:38Gyorgy RethyFile Added: CR5331_resolution_v2.doc
08-09-2009 09:40Gyorgy RethyNote Added: 0008987
08-12-2009 07:31Ina SchieferdeckerNote Added: 0009090
08-12-2009 07:32Ina SchieferdeckerAssigned ToIna Schieferdecker => Gyorgy Rethy
08-12-2009 07:32Ina SchieferdeckerStatusassigned => resolved
01-02-2010 15:46Gyorgy RethyStatusresolved => closed
01-02-2010 15:46Gyorgy RethyNote Added: 0009185
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0008981) +
+ Gyorgy Rethy    +
+ 04-09-2009 14:06    +
(edited on: 04-09-2009 15:35)
+ 		+ + + + +
+ CR5331_resolution_v1.doc: draft for resolution. Part-10 v4.2.1 is not compatible with earlier versions (e.g. with v4.1.1) because it talks about importing imports (its forbidden from ASN.1 modules).
+Pls. review. ready for review.
+
+
+
+
+
+ + + + + + + + + + +
+ (0008987) +
+ Gyorgy Rethy    +
+ 08-09-2009 09:40    +
+ 		+ + + + +
+ CR5331_resolution_v2.doc: dependency from part-10 is added due to the new date/time patterns
+
+
+
+ + + + + + + + + + +
+ (0009090) +
+ Ina Schieferdecker    +
+ 08-12-2009 07:31    +
+ 		+ + + + +
+ ok.
+
+
+
+ + + + + + + + + + +
+ (0009185) +
+ Gyorgy Rethy    +
+ 01-02-2010 15:46    +
+ 		+ + + + +
+ Implemented in master copy (v.4.1.4)
+
+ + diff --git a/docs/mantis/CR5334.md b/docs/mantis/CR5334.md new file mode 100644 index 0000000000000000000000000000000000000000..b1a49d633e22e64b791da8438b4cbcf3123ff108 --- /dev/null +++ b/docs/mantis/CR5334.md @@ -0,0 +1,63 @@ + + + + + + + + + + + + + 0005334: Sub-typing or subtyping - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005334Part 01: TTCN-3 Core LanguageEditorialpublic08-09-2009 18:0809-12-2009 13:50
ReporterTibor Csöndes 
Assigned ToIna Schieferdecker 
PrioritylowSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.2.1 (published 2010-07)Fixed in Versionv4.2.1 (published 2010-07) 
Clause Reference(s)in a number of cases in the core language, a good example is Clause 6.2.13
Source (company - Author) L.M. Ericsson - Tibor Csöndes
Summary0005334: Sub-typing or subtyping
DescriptionUsage of "sub-typing" and "subtyping" are mixed in the text, however it shall be consistent. Personally, I prefer "subtyping", but it's an open question.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
08-09-2009 18:08Tibor CsöndesNew Issue
08-09-2009 18:08Tibor CsöndesClause Reference(s) => in a number of cases in the core language, a good example is Clause 6.2.13
08-09-2009 18:08Tibor CsöndesSource (company - Author) => L.M. Ericsson - Tibor Csöndes
09-09-2009 10:12Ina SchieferdeckerProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
09-09-2009 10:13Ina SchieferdeckerAssigned To => Ina Schieferdecker
09-09-2009 10:13Ina SchieferdeckerStatusnew => assigned
09-09-2009 10:13Ina SchieferdeckerTarget Version => Edition 4.2.1 (not yet published)
09-12-2009 13:50Ina SchieferdeckerNote Added: 0009116
09-12-2009 13:50Ina SchieferdeckerStatusassigned => resolved
09-12-2009 13:50Ina SchieferdeckerResolutionopen => fixed
09-12-2009 13:50Ina SchieferdeckerFixed in Version => Edition 4.2.1 (not yet published)
09-12-2009 13:50Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009116) +
+ Ina Schieferdecker    +
+ 09-12-2009 13:50    +
+ 		+ + + + +
+ Resolved in favour of "subtype" in part 1.
+
+ + diff --git a/docs/mantis/CR5336.md b/docs/mantis/CR5336.md new file mode 100644 index 0000000000000000000000000000000000000000..c70e39c296c96d43dda358534559a4a6b5c75f5c --- /dev/null +++ b/docs/mantis/CR5336.md @@ -0,0 +1,203 @@ + + + + + + + + + + + + + 0005336: Add support for behaviour types to t3doc - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Behaviour Types (ES 202 785)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005336Ext Pack: Behaviour Types (ES 202 785)Technicalpublic09-09-2009 11:0613-12-2010 13:36
ReporterGyorgy Rethy 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv1.2.1 (published 2011-05)Fixed in Versionv1.2.1 (published 2011-05) 
Clause Reference(s)
Source (company - Author)L.M.Ericsson
Summary0005336: Add support for behaviour types to t3doc
DescriptionAdd support for behaviour types in the text where approriate.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR5336_resolution_v1.doc (104,448) 24-03-2010 16:28
http://oldforge.etsi.org/mantis/file_download.php?file_id=2350&type=bug
doc CR5336_resolution_v2.doc (102,912) 25-03-2010 16:10
http://oldforge.etsi.org/mantis/file_download.php?file_id=2375&type=bug
Issue History
Date ModifiedUsernameFieldChange
09-09-2009 11:06Gyorgy RethyNew Issue
09-09-2009 11:06Gyorgy RethyStatusnew => assigned
09-09-2009 11:06Gyorgy RethyAssigned To => Gyorgy Rethy
09-09-2009 11:06Gyorgy RethySource (company - Author) => L.M.Ericsson
07-12-2009 14:43Ina SchieferdeckerNote Added: 0009082
07-12-2009 14:43Ina SchieferdeckerTarget Version => Edition 4.2.1 (not yet published)
18-03-2010 07:30Ina SchieferdeckerTarget VersionEdition 4.2.1 (not yet published) => Edition 5.1.1 (not yet published)
24-03-2010 16:28Gyorgy RethyNote Added: 0009286
24-03-2010 16:28Gyorgy RethyNote Edited: 0009286
24-03-2010 16:28Gyorgy RethyFile Added: CR5336_resolution_v1.doc
25-03-2010 15:36Gyorgy RethyAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
25-03-2010 16:09Gyorgy RethyProjectPart 10: TTCN-3 documentation tags => Ext Pack: Behaviour Types (ES 202 785)
25-03-2010 16:10Gyorgy RethyFile Added: CR5336_resolution_v2.doc
25-03-2010 16:11Gyorgy RethyNote Added: 0009318
25-03-2010 16:12Gyorgy RethyNote Edited: 0009318
25-03-2010 16:13Gyorgy RethyAssigned ToJacob Wieland - Spirent => Jens Grabowski
25-03-2010 16:16Gyorgy RethyStatusassigned => resolved
25-03-2010 16:16Gyorgy RethyResolutionopen => fixed
26-03-2010 09:19Jens GrabowskiStatusresolved => closed
26-03-2010 09:19Jens GrabowskiNote Added: 0009319
13-12-2010 13:35Gyorgy RethyStatusclosed => feedback
13-12-2010 13:35Gyorgy RethyResolutionfixed => reopened
13-12-2010 13:36Gyorgy RethyNote Added: 0009957
13-12-2010 13:36Gyorgy RethyStatusfeedback => closed
13-12-2010 13:36Gyorgy RethyResolutionreopened => fixed
13-12-2010 13:36Gyorgy RethyFixed in Version => v1.2.1
13-12-2010 13:36Gyorgy RethyTarget VersionEdition 4.3.1 (not yet published) => v1.2.1
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009082) +
+ Ina Schieferdecker    +
+ 07-12-2009 14:43    +
+ 		+ + + + +
+ This should be done in the behavior types extension package.
+
+
+
+ + + + + + + + + + +
+ (0009286) +
+ Gyorgy Rethy    +
+ 24-03-2010 16:28    +
+ 		+ + + + +
+ Proposed solution is uploaded in file CR5336_resolution_v1.doc. To be reviewed.
+
+
+
+
+
+ + + + + + + + + + +
+ (0009318) +
+ Gyorgy Rethy    +
+ 25-03-2010 16:11    +
(edited on: 25-03-2010 16:12)
+ 		+ + + + +
+ CR5336_resolution_v2.doc: contains changes proposed by Jacob: at least we two agree on this version.
+
+
+
+
+
+ + + + + + + + + + +
+ (0009319) +
+ Jens Grabowski    +
+ 26-03-2010 09:19    +
+ 		+ + + + +
+ Implemented as proposed by the attachment.
+
+
+
+ + + + + + + + + + +
+ (0009957) +
+ Gyorgy Rethy    +
+ 13-12-2010 13:36    +
+ 		+ + + + +
+ Target version and fixed in version are added to CR.
+
+ + diff --git a/docs/mantis/CR5337.md b/docs/mantis/CR5337.md new file mode 100644 index 0000000000000000000000000000000000000000..f807b95a7f1c099220a4da26789433edede15e5a --- /dev/null +++ b/docs/mantis/CR5337.md @@ -0,0 +1,63 @@ + + + + + + + + + + + + + 0005337: Update of operational Semantics - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 04: TTCN-3 Operational Semantics
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005337Part 04: TTCN-3 Operational SemanticsTechnicalpublic09-09-2009 11:2816-02-2010 14:27
ReporterJens Grabowski 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.2.1 (published 2010-07)Fixed in Versionv4.2.1 (published 2010-07) 
Clause Reference(s)All
Source (company - Author)     
Summary0005337: Update of operational Semantics
DescriptionSome refactoring of the operational semantics need to be made to ease the semantics definition of the static configuration package. Basically, the module state needs to be structured into a control state (representing module control) and a configuration state (representing the actual test configuration).
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Fileszip CR-5337- resolution-v01-090909.zip (1,456,769) 09-09-2009 11:45
http://oldforge.etsi.org/mantis/file_download.php?file_id=2254&type=bug
zip CR-5337- resolution-v03-100121.zip (1,477,331) 21-01-2010 15:30
http://oldforge.etsi.org/mantis/file_download.php?file_id=2324&type=bug
Issue History
Date ModifiedUsernameFieldChange
09-09-2009 11:28Jens GrabowskiNew Issue
09-09-2009 11:28Jens GrabowskiStatusnew => assigned
09-09-2009 11:28Jens GrabowskiAssigned To => Jens Grabowski
09-09-2009 11:28Jens GrabowskiClause Reference(s) => All
09-09-2009 11:28Jens GrabowskiSource (company - Author) =>
09-09-2009 11:45Jens GrabowskiFile Added: CR-5337- resolution-v01-090909.zip
07-12-2009 14:42Ina SchieferdeckerTarget Version => Edition 4.2.1 (not yet published)
21-01-2010 15:30Jens GrabowskiFile Added: CR-5337- resolution-v03-100121.zip
16-02-2010 14:27Jens GrabowskiStatusassigned => closed
16-02-2010 14:27Jens GrabowskiNote Added: 0009220
16-02-2010 14:27Jens GrabowskiResolutionopen => fixed
16-02-2010 14:27Jens GrabowskiFixed in Version => Edition 4.2.1 (not yet published)
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009220) +
+ Jens Grabowski    +
+ 16-02-2010 14:27    +
+ 		+ + + + +
+ Implemented in next version of operational semantics.
+
+ + diff --git a/docs/mantis/CR5338.md b/docs/mantis/CR5338.md new file mode 100644 index 0000000000000000000000000000000000000000..fc5af1f0281e31913a31330cdc9f5da6e1ef3220 --- /dev/null +++ b/docs/mantis/CR5338.md @@ -0,0 +1,112 @@ + + + + + + + + + + + + + 0005338: Referencing group components is ambiguous - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005338Part 09: Using XML with TTCN-3Clarificationpublic09-09-2009 12:2301-02-2010 10:58
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.2.1 (published 2010-07)Fixed in Versionv4.2.1 (published 2010-07) 
Clause Reference(s)7.6.3
For STF discussion
Source (company - Author)L.M.Ericsson
Summary0005338: Referencing group components is ambiguous
DescriptionThe way of handling referenced model group definitions is ambiguous. partly, clauses 7.6.3. and 7.9 are contradicting. It is proposed that clause 7.9 is taken for the basis as it generates more compact code and reusable definitions (e.g. templates can be written for the model groups as well)
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR5338_resolution_v1.doc (84,480) 09-12-2009 08:53
http://oldforge.etsi.org/mantis/file_download.php?file_id=2298&type=bug
? groups.xsd (8,062) 09-12-2009 09:55
http://oldforge.etsi.org/mantis/file_download.php?file_id=2301&type=bug
? www_example_org_groups.ttcn (5,065) 09-12-2009 09:58
http://oldforge.etsi.org/mantis/file_download.php?file_id=2302&type=bug
doc CR5338_resolution_v2.doc (110,592) 17-12-2009 16:18
http://oldforge.etsi.org/mantis/file_download.php?file_id=2321&type=bug
Issue History
Date ModifiedUsernameFieldChange
09-09-2009 12:23Gyorgy RethyNew Issue
09-09-2009 12:23Gyorgy RethyStatusnew => assigned
09-09-2009 12:23Gyorgy RethyAssigned To => Gyorgy Rethy
09-09-2009 12:23Gyorgy RethyClause Reference(s) => 7.6.3
09-09-2009 12:23Gyorgy RethySource (company - Author) => L.M.Ericsson
07-12-2009 14:42Ina SchieferdeckerTarget Version => Edition 4.2.1 (not yet published)
08-12-2009 08:41Gyorgy RethyNote Added: 0009093
08-12-2009 08:41Gyorgy RethyFile Added: CR5338_resolution_v1.doc
09-12-2009 08:52Gyorgy RethyNote Edited: 0009093
09-12-2009 08:53Gyorgy RethyFile Deleted: CR5338_resolution_v1.doc
09-12-2009 08:53Gyorgy RethyFile Added: CR5338_resolution_v1.doc
09-12-2009 08:54Gyorgy RethyFile Added: groups.xsd
09-12-2009 09:08Gyorgy RethyNote Edited: 0009093
09-12-2009 09:10Gyorgy RethyNote Edited: 0009093
09-12-2009 09:32Gyorgy RethyNote Edited: 0009093
09-12-2009 09:35Gyorgy RethyFile Deleted: groups.xsd
09-12-2009 09:54Gyorgy RethyFile Added: www_example_org_groups.ttcn
09-12-2009 09:55Gyorgy RethyFile Added: groups.xsd
09-12-2009 09:55Gyorgy RethyFile Deleted: www_example_org_groups.ttcn
09-12-2009 09:58Gyorgy RethyFile Added: www_example_org_groups.ttcn
17-12-2009 16:18Gyorgy RethyFile Added: CR5338_resolution_v2.doc
01-02-2010 10:58Gyorgy RethyNote Added: 0009172
01-02-2010 10:58Gyorgy RethyStatusassigned => closed
01-02-2010 10:58Gyorgy RethyResolutionopen => fixed
01-02-2010 10:58Gyorgy RethyFixed in Version => Edition 4.2.1 (not yet published)
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009093) +
+ Gyorgy Rethy    +
+ 08-12-2009 08:41    +
(edited on: 09-12-2009 09:32)
+ 		+ + + + +
+ CR5338_resolution_v1.doc: first draft, to be discussed.
+
+When analysing the possible cases, there are 6 situations to be considered:
+(a) group reference is child of complexType, minOccurs=maxOccurs=1
+(b) group reference is child of complexType, minOccurs= 0, maxOccurs=1
+(c) group reference is child of complexType, minOccurs>=0, maxOccurs>1
+(d)(e)(f) group reference is child of <sequence> or <choice> and the above 3 combinations of minOccurs and maxOccurs are repeated; in this case the group reference may also be combined with other element declarations.
+See examples in file groups.xsd.
+
+There are two options to resolve all cases above:
+(1) keep the existing mapping rule (copy the elements of the referenced group) for case (a) and add new rules for cases (b) to (f); in case (d) a new mandatory and in cases (b) and (e) a new optional field shall be created; in cases (c) and (f) a new record of field shall be created; this means that four different rules shall be specified for group references.
+(2) unifying the mapping by saying that in all cases a new field has to be created, which type is the type generated for the referenced model groups; in this case only one rule needed, the mapping is simplified (handling of the different combinations o minOccurs and maxOccurs are already specified in clause 7.1.4). But this would also mean a non-backward compatible change in case (a).
+
+The attached first draft CR5338_resolution_v1.doc proposes the second alternative as this is more user friendly (single rule & changing minOccurs from 1 to 0 does not change the structure of the generated TTCN-3 code).
+
+
+
+
+
+ + + + + + + + + + +
+ (0009172) +
+ Gyorgy Rethy    +
+ 01-02-2010 10:58    +
+ 		+ + + + +
+ Implemented as in CR5338_resolution_v2.doc.
+
+ + diff --git a/docs/mantis/CR5339.md b/docs/mantis/CR5339.md new file mode 100644 index 0000000000000000000000000000000000000000..cfcaa85c81dbf53c9b7e32b7df1a712689734881 --- /dev/null +++ b/docs/mantis/CR5339.md @@ -0,0 +1,63 @@ + + + + + + + + + + + + + 0005339: Incorrect translation of the XSD float type - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005339Part 09: Using XML with TTCN-3Technicalpublic09-09-2009 17:0410-09-2009 10:05
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.2.1 (published 2010-07)Fixed in Versionv4.2.1 (published 2010-07) 
Clause Reference(s)6.4.2
For STF discussion
Source (company - Author)L.M.Ericsson
Summary0005339: Incorrect translation of the XSD float type
DescriptionThe XSD float type is converted today to a specific subset of the TTCN-3 float type (IEEE754float). However, this is not correct, as XSD also allows three specific values, positive and negative infinity and not-a-number. TTCN-3 float does not contain value notation for these 3 special values. The conversion shall be changed to allow these special values as well.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0005340closed Gyorgy Rethy Incorrect mapping of the XSD double type 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
09-09-2009 17:04Gyorgy RethyNew Issue
09-09-2009 17:04Gyorgy RethyStatusnew => assigned
09-09-2009 17:04Gyorgy RethyAssigned To => Gyorgy Rethy
09-09-2009 17:04Gyorgy RethyClause Reference(s) => 6.4.2
09-09-2009 17:04Gyorgy RethySource (company - Author) => L.M.Ericsson
09-09-2009 17:07Gyorgy RethyRelationship addedrelated to 0005340
10-09-2009 10:05Gyorgy RethyNote Added: 0008994
10-09-2009 10:05Gyorgy RethyStatusassigned => closed
10-09-2009 10:05Gyorgy RethyResolutionopen => fixed
10-09-2009 10:05Gyorgy RethyFixed in Version => Edition 4.2.1 (not yet published)
10-09-2009 10:05Gyorgy RethyTarget Version => Edition 4.2.1 (not yet published)
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0008994) +
+ Gyorgy Rethy    +
+ 10-09-2009 10:05    +
+ 		+ + + + +
+ RESOLUTION SEE AT CR5340!
+
+ + diff --git a/docs/mantis/CR5340.md b/docs/mantis/CR5340.md new file mode 100644 index 0000000000000000000000000000000000000000..85a357933284daeca77e19a49c16adebb87ffe7d --- /dev/null +++ b/docs/mantis/CR5340.md @@ -0,0 +1,280 @@ + + + + + + + + + + + + + 0005340: Incorrect mapping of the XSD double type - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005340Part 09: Using XML with TTCN-3Technicalpublic09-09-2009 17:0723-03-2010 09:11
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.2.1 (published 2010-07)Fixed in Versionv4.2.1 (published 2010-07) 
Clause Reference(s)6.4.3
For STF discussion
Source (company - Author)L.M.Ericsson
Summary0005340: Incorrect mapping of the XSD double type
DescriptionThe XSD float type is converted today to a specific subset of the TTCN-3 float type (IEEE754float). However, this is not correct, as XSD also allows three specific values, positive and negative infinity and not-a-number. TTCN-3 float does not contain value notation for these 3 special values. The conversion shall be changed to allow these special values as well.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0005339closed Gyorgy Rethy Part 09: Using XML with TTCN-3 Incorrect translation of the XSD float type 
related to 0005507closed Ina Schieferdecker Part 01: TTCN-3 Core Language Infinity is a real value 
child of 0005344closed Ina Schieferdecker Part 01: TTCN-3 Core Language Introduce range subtyping boundaries excluding the boundaries themselves 
Attached Filesdoc CR5340_resolution_P1_v3.doc (259,072) 11-12-2009 09:22
http://oldforge.etsi.org/mantis/file_download.php?file_id=2317&type=bug
doc CR5340_resolution_P7_v4.doc (161,280) 11-12-2009 09:26
http://oldforge.etsi.org/mantis/file_download.php?file_id=2318&type=bug
doc CR5340_resolution_P9_v3.doc (136,192) 12-12-2009 17:24
http://oldforge.etsi.org/mantis/file_download.php?file_id=2320&type=bug
Issue History
Date ModifiedUsernameFieldChange
09-09-2009 17:07Gyorgy RethyNew Issue
09-09-2009 17:07Gyorgy RethyStatusnew => assigned
09-09-2009 17:07Gyorgy RethyAssigned To => Gyorgy Rethy
09-09-2009 17:07Gyorgy RethyClause Reference(s) => 6.4.3
09-09-2009 17:07Gyorgy RethySource (company - Author) => L.M.Ericsson
09-09-2009 17:07Gyorgy RethyRelationship addedrelated to 0005339
11-09-2009 11:59Gyorgy RethyRelationship addedrelated to 0005344
11-09-2009 12:00Gyorgy RethyRelationship deletedrelated to 0005344
11-09-2009 12:00Gyorgy RethyRelationship addedchild of 0005344
11-09-2009 12:08Gyorgy RethyNote Added: 0008997
11-09-2009 12:08Gyorgy RethyFile Added: CR5340_resolution_P1_v1.doc
11-09-2009 12:09Gyorgy RethyFile Added: CR5340_resolution_P7_v1.doc
11-09-2009 12:09Gyorgy RethyFile Added: CR5340_resolution_P9_v1.doc
11-09-2009 12:16Gyorgy RethyNote Edited: 0008997
13-09-2009 17:03Gyorgy RethyFile Added: CR5340_resolution_P1_v2.doc
13-09-2009 17:03Gyorgy RethyFile Deleted: CR5340_resolution_P1_v1.doc
13-09-2009 17:10Gyorgy RethyFile Deleted: CR5340_resolution_P1_v2.doc
13-09-2009 17:11Gyorgy RethyFile Added: CR5340_resolution_P1_v2.doc
07-12-2009 14:38Ina SchieferdeckerTarget Version => Edition 4.2.1 (not yet published)
09-12-2009 17:13Gyorgy RethyFile Deleted: CR5340_resolution_P7_v1.doc
09-12-2009 17:14Gyorgy RethyFile Added: Backup of CR5340_resolution_P7_v2.wbk
09-12-2009 17:17Gyorgy RethyFile Deleted: Backup of CR5340_resolution_P7_v2.wbk
09-12-2009 17:17Gyorgy RethyFile Added: CR5340_resolution_P7_v2.doc
09-12-2009 17:51Gyorgy RethyFile Deleted: CR5340_resolution_P1_v2.doc
09-12-2009 17:51Gyorgy RethyFile Deleted: CR5340_resolution_P9_v1.doc
09-12-2009 18:05Gyorgy RethyFile Added: CR5340_resolution_P1_v3.doc
10-12-2009 08:39Gyorgy RethyFile Deleted: CR5340_resolution_P7_v2.doc
10-12-2009 08:40Gyorgy RethyFile Added: CR5340_resolution_P7_v3.doc
11-12-2009 09:20Gyorgy RethyFile Deleted: CR5340_resolution_P1_v3.doc
11-12-2009 09:21Gyorgy RethyFile Added: CR5340_resolution_P7_v4.doc
11-12-2009 09:21Gyorgy RethyFile Deleted: CR5340_resolution_P7_v3.doc
11-12-2009 09:22Gyorgy RethyFile Added: CR5340_resolution_P1_v3.doc
11-12-2009 09:24Gyorgy RethyFile Deleted: CR5340_resolution_P7_v4.doc
11-12-2009 09:26Gyorgy RethyFile Added: CR5340_resolution_P7_v4.doc
12-12-2009 17:23Gyorgy RethyFile Added: Backup of CR5340_resolution_P9_v3.wbk
12-12-2009 17:23Gyorgy RethyFile Deleted: Backup of CR5340_resolution_P9_v3.wbk
12-12-2009 17:24Gyorgy RethyFile Added: CR5340_resolution_P9_v3.doc
12-12-2009 17:28Gyorgy RethyNote Added: 0009149
12-12-2009 17:29Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
04-01-2010 12:04Ina SchieferdeckerNote Added: 0009151
04-01-2010 12:04Ina SchieferdeckerAssigned ToIna Schieferdecker => Gyorgy Rethy
01-02-2010 13:44Gyorgy RethyNote Added: 0009178
01-02-2010 15:13Gyorgy RethyNote Added: 0009184
01-02-2010 15:13Gyorgy RethyStatusassigned => closed
01-02-2010 15:13Gyorgy RethyResolutionopen => fixed
01-02-2010 15:13Gyorgy RethyFixed in Version => Edition 4.2.1 (not yet published)
23-03-2010 09:11Ina SchieferdeckerNote Added: 0009250
29-06-2010 09:35Ina SchieferdeckerRelationship addedrelated to 0005507
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0008997) +
+ Gyorgy Rethy    +
+ 11-09-2009 12:08    +
(edited on: 11-09-2009 12:16)
+ 		+ + + + +
+ CR5340_resolution_Px_v1.doc: first drafts for the resolution for part-1, 7 and 9.
+Open: how to handle exclusive range boundaries of constrained float types?
+  1) introduce exclusive boundaries in TTCN-3 as well (CR5344)
+  2) refer to some " minimal distinguishable real value", that is a) platform dependent; as the converter and the TTCN-3 tool may be used on different platforms, this may lead to different behaviours of different TTCN-3 tools b) not as exact as TTCN-3 should be.
+  3) define the "minimal distinguishable real value"; the real behaviour of tools still may be platform dependent and in some specific cases behaviours of all tools may be wrong (if the received value less by delta than the boundary but this delta is less than the "minimal distinguishable real value";
+
+
+
+
+
+ + + + + + + + + + +
+ (0009149) +
+ Gyorgy Rethy    +
+ 12-12-2009 17:28    +
+ 		+ + + + +
+ Ready for review. Solution relies upon the new exclusive boundary feature in the core for float, double and decimal types. Mapping of integer do not change. Also handling of date/time types is added, though the bounding facets applied to date/time types are ignored (but this is explicit now). Also text is extended to cover the different cases more precisely and explicitly, though technical change effects only the float/double/decimal types.
+
+
+
+ + + + + + + + + + +
+ (0009151) +
+ Ina Schieferdecker    +
+ 04-01-2010 12:04    +
+ 		+ + + + +
+ For sake of simplicity, I propose to use also for XML one rule for handling of exclusive boundaries and not to differentiate between float and integer types for that, i.e.
+
+Instead of
+
+<simpleType name="e12a">
+    <restriction base="positiveInteger">
+        <maxExclusive value="100"/>
+    </restriction>
+</simpleType>
+
+// Is mapped in TTCN-3 to:
+type XSD.PositiveInteger E12a (1 .. 99)
+with {
+    variant "name as uncapitalized"
+}
+
+we may define
+
+<simpleType name="e12a">
+    <restriction base="positiveInteger">
+        <maxExclusive value="100"/>
+    </restriction>
+</simpleType>
+
+// Is mapped in TTCN-3 to:
+type XSD.PositiveInteger E12a (1 .. !100)
+with {
+    variant "name as uncapitalized"
+}
+
+The proposals for Part 1 and Part 7 are ok.
+
+
+
+ + + + + + + + + + +
+ (0009178) +
+ Gyorgy Rethy    +
+ 01-02-2010 13:44    +
+ 		+ + + + +
+ Implemented in Part-9, according to Ina's proposal on the unified handling of integer and float/double types.
+
+
+
+ + + + + + + + + + +
+ (0009184) +
+ Gyorgy Rethy    +
+ 01-02-2010 15:13    +
+ 		+ + + + +
+ Implemented in Part-7 acc. to CR5340_resolution_P7_v4.doc.
+
+
+
+ + + + + + + + + + +
+ (0009250) +
+ Ina Schieferdecker    +
+ 23-03-2010 09:11    +
+ 		+ + + + +
+ Part 1 changes implemented with minor changes:
+
+In 7.1.3: "minus zero is less than plus zero, which represents zero"
+
+In 6.1.1: "NOTE 2: - not_a_number (i.e. minus not a number) is not to be used."
+
+
+In BNF:
+
+FloatValue ::= FloatDotNotation | FloatENotation | NaNKeyword
+
+--> FloatValue without InfinityKeyword as this is already part of the range definition
+
+ + diff --git a/docs/mantis/CR5341.md b/docs/mantis/CR5341.md new file mode 100644 index 0000000000000000000000000000000000000000..4a8a404a28ddb28c12a5a6ffaf38aec86d790dcb --- /dev/null +++ b/docs/mantis/CR5341.md @@ -0,0 +1,167 @@ + + + + + + + + + + + + + 0005341: Untagged attribute shall be used also when minOccurs and maxOccurs is used with model gruop references - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005341Part 09: Using XML with TTCN-3Technicalpublic10-09-2009 10:5701-02-2010 09:47
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.2.1 (published 2010-07)Fixed in Versionv4.2.1 (published 2010-07) 
Clause Reference(s)$7.1.4
For STF discussion
Source (company - Author)L.M.Ericsson
Summary0005341: Untagged attribute shall be used also when minOccurs and maxOccurs is used with model gruop references
DescriptionWhen the minOccurs and the maxOccurs attributes are used with model gruop references, and they specify a replication, the group reference is mapped to a record of <model group type> field. However, the name of this record of field is not used in encoding the XML values (just the names of the elements in the referenced model group), consequently an "untagged" TTCN-3 attribute shall be used for the record of field.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR5341_resolution_v1.doc (98,304) 10-09-2009 12:09
http://oldforge.etsi.org/mantis/file_download.php?file_id=2257&type=bug
doc CR5341_resolution_v2.doc (100,864) 07-12-2009 16:13
http://oldforge.etsi.org/mantis/file_download.php?file_id=2278&type=bug
doc CR5341_resolution_v3.doc (102,912) 07-12-2009 16:24
http://oldforge.etsi.org/mantis/file_download.php?file_id=2280&type=bug
Issue History
Date ModifiedUsernameFieldChange
10-09-2009 10:57Gyorgy RethyNew Issue
10-09-2009 10:57Gyorgy RethyStatusnew => assigned
10-09-2009 10:57Gyorgy RethyAssigned To => Gyorgy Rethy
10-09-2009 10:57Gyorgy RethyClause Reference(s) => $7.1.4
10-09-2009 10:57Gyorgy RethySource (company - Author) => L.M.Ericsson
10-09-2009 12:09Gyorgy RethyFile Added: CR5341_resolution_v1.doc
10-09-2009 12:09Gyorgy RethyNote Added: 0008995
10-09-2009 12:09Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
07-12-2009 14:40Ina SchieferdeckerTarget Version => Edition 4.2.1 (not yet published)
07-12-2009 16:13Gyorgy RethyFile Added: CR5341_resolution_v2.doc
07-12-2009 16:13Gyorgy RethyNote Edited: 0008995
07-12-2009 16:24Ina SchieferdeckerNote Added: 0009083
07-12-2009 16:24Ina SchieferdeckerFile Added: CR5341_resolution_v3.doc
07-12-2009 16:24Ina SchieferdeckerAssigned ToIna Schieferdecker => Gyorgy Rethy
07-12-2009 16:24Ina SchieferdeckerResolutionopen => fixed
08-12-2009 13:00Gyorgy RethyStatusassigned => resolved
08-12-2009 13:00Gyorgy RethyFixed in Version => Edition 4.2.1 (not yet published)
08-12-2009 13:00Gyorgy RethyNote Added: 0009094
01-02-2010 09:47Gyorgy RethyStatusresolved => closed
01-02-2010 09:47Gyorgy RethyNote Added: 0009171
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0008995) +
+ Gyorgy Rethy    +
+ 10-09-2009 12:09    +
(edited on: 07-12-2009 16:13)
+ 		+ + + + +
+ CR5341_resolution_v2.doc: updated draft for resolution, ready for review.
+
+
+
+
+
+ + + + + + + + + + +
+ (0009083) +
+ Ina Schieferdecker    +
+ 07-12-2009 16:24    +
+ 		+ + + + +
+ Is ok except of some typos - see v3
+
+
+
+ + + + + + + + + + +
+ (0009094) +
+ Gyorgy Rethy    +
+ 08-12-2009 13:00    +
+ 		+ + + + +
+ Checked, to be added to master copy
+
+
+
+ + + + + + + + + + +
+ (0009171) +
+ Gyorgy Rethy    +
+ 01-02-2010 09:47    +
+ 		+ + + + +
+ Added to master copy
+
+ + diff --git a/docs/mantis/CR5342.md b/docs/mantis/CR5342.md new file mode 100644 index 0000000000000000000000000000000000000000..7e2bd66f31ee2c70cd3f45ba3915711398499b8f --- /dev/null +++ b/docs/mantis/CR5342.md @@ -0,0 +1,63 @@ + + + + + + + + + + + + + 0005342: COMPONENTS OF transformation should be before subtype conversion - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 07: Using ASN.1 with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005342Part 07: Using ASN.1 with TTCN-3Technicalpublic10-09-2009 17:5123-03-2010 14:32
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PriorityhighSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.2.1 (published 2010-07)Fixed in Versionv4.2.1 (published 2010-07) 
Clause Reference(s)9.1
Source (company - Author)L.M.Ericsson
Summary0005342: COMPONENTS OF transformation should be before subtype conversion
DescriptionThe components of transformation should be before converting ASN.1 subtypes to TTCN-3 subtypes as is defined over ASN.1 components of SEQUENCE and SET types.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
10-09-2009 17:51Gyorgy RethyNew Issue
10-09-2009 17:51Gyorgy RethyStatusnew => assigned
10-09-2009 17:51Gyorgy RethyAssigned To => Gyorgy Rethy
10-09-2009 17:51Gyorgy RethyClause Reference(s) => 9.1
10-09-2009 17:51Gyorgy RethySource (company - Author) => L.M.Ericsson
07-12-2009 14:40Ina SchieferdeckerTarget Version => Edition 4.2.1 (not yet published)
18-03-2010 07:46Ina SchieferdeckerTarget VersionEdition 4.2.1 (not yet published) => Edition 5.1.1 (not yet published)
23-03-2010 12:51Gyorgy RethyPrioritynormal => high
23-03-2010 12:51Gyorgy RethyTarget VersionEdition 4.3.1 (not yet published) => Edition 4.2.1 (not yet published)
23-03-2010 14:32Gyorgy RethyNote Added: 0009262
23-03-2010 14:32Gyorgy RethyStatusassigned => closed
23-03-2010 14:32Gyorgy RethyResolutionopen => fixed
23-03-2010 14:32Gyorgy RethyFixed in Version => Edition 4.2.1 (not yet published)
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009262) +
+ Gyorgy Rethy    +
+ 23-03-2010 14:32    +
+ 		+ + + + +
+ Implemented in draft v4.1.5
+
+ + diff --git a/docs/mantis/CR5343.md b/docs/mantis/CR5343.md new file mode 100644 index 0000000000000000000000000000000000000000..d115964c21e18e792ed10130e226f9a7f8d3cb64 --- /dev/null +++ b/docs/mantis/CR5343.md @@ -0,0 +1,188 @@ + + + + + + + + + + + + + 0005343: small BNF issues - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005343Part 01: TTCN-3 Core LanguageClarificationpublic11-09-2009 10:0224-03-2010 17:31
ReporterIna Schieferdecker 
Assigned ToIna Schieferdecker 
PriorityhighSeveritytrivialReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.2.1 (published 2010-07)Fixed in Versionv4.2.1 (published 2010-07) 
Clause Reference(s)Annex A
Source (company - Author)Ina Schieferdecker, FOKUS
Summary0005343: small BNF issues
Description"" in PatternElement is because of the Pattern definition superfluous:
+
+Pattern ::= """ { PatternElement } """
+PatternElement ::=
+         ("\" ("?" | "*" | "\" | "[" | "]" | "{" | "}" | """ | "|" | "(" | ")" | "#" | "+" |
+               "d" | "w" | "t" | "n" | "r" | "s" | "b")) |
+         ("?" | "*" | "\" | "|" | "+") |
+         ("[" ["^"] [ {PatternChar ["-" PatternChar] } ] "]") |
+         ("{" ReferencedValue "}") |
+         ("\" "N" "{" (ReferencedValue | Type) "}") |
+         (""" """) |
+         ("(" PatternElement ")") |
+         ("#" (Num | ("(" Num "," [Num] ")") | ("(" "," Num ")"))) |
+         PatternChar
+
+TO
+
+Pattern ::= """ { PatternElement } """
+PatternElement ::=
+         ("\" ("?" | "*" | "\" | "[" | "]" | "{" | "}" | """ | "|" | "(" | ")" | "#" | "+" |
+               "d" | "w" | "t" | "n" | "r" | "s" | "b")) |
+         ("?" | "*" | "\" | "|" | "+") |
+         ("[" ["^"] [ {PatternChar ["-" PatternChar] } ] "]") |
+         ("{" ReferencedValue "}") |
+         ("\" "N" "{" (ReferencedValue | Type) "}") |
+         ("(" PatternElement ")") |
+         ("#" (Num | ("(" Num "," [Num] ")") | ("(" "," Num ")"))) |
+         PatternChar
+
+
+
+() in ValueSpec missing:
+
+
+ValueSpec ::= ValueKeyword ( VariableRef |
+                                 "(" { [ VariableRef [ AssignmentChar
+                                       (FieldReference | TypeDefIdentifier) ExtendedFieldReference ]
+                                       ] [","] }
+                                  ")" )
+
+TO
+
+ValueSpec ::= ValueKeyword ( VariableRef |
+                                ( "(" { [ VariableRef [ AssignmentChar
+                                       (FieldReference | TypeDefIdentifier) ExtendedFieldReference ]
+                                       ] [","] }
+                                  ")" ) )
+
+
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0005346closed Ina Schieferdecker Some more small BNF issues 
Attached Filesdoc CR5343_v1.doc (33,792) 04-01-2010 13:01
http://oldforge.etsi.org/mantis/file_download.php?file_id=2322&type=bug
Issue History
Date ModifiedUsernameFieldChange
11-09-2009 10:02Ina SchieferdeckerNew Issue
11-09-2009 10:02Ina SchieferdeckerStatusnew => assigned
11-09-2009 10:02Ina SchieferdeckerAssigned To => Gyorgy Rethy
11-09-2009 10:02Ina SchieferdeckerClause Reference(s) => Annex A
11-09-2009 10:02Ina SchieferdeckerSource (company - Author) => Ina Schieferdecker, FOKUS
13-09-2009 13:26Ina SchieferdeckerProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
13-09-2009 13:26Ina SchieferdeckerCategoryTTCN-3 Core Language => Clarification
13-09-2009 13:26Ina SchieferdeckerTarget Version => Edition 4.2.1 (not yet published)
10-12-2009 10:34Gyorgy RethyNote Added: 0009137
10-12-2009 10:34Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
04-01-2010 13:01Ina SchieferdeckerFile Added: CR5343_v1.doc
04-01-2010 13:05Ina SchieferdeckerNote Added: 0009153
04-01-2010 13:05Ina SchieferdeckerAssigned ToIna Schieferdecker => Gyorgy Rethy
04-01-2010 13:06Ina SchieferdeckerResolutionopen => fixed
04-01-2010 13:06Ina SchieferdeckerRelationship addedrelated to 0005346
16-02-2010 07:35Ina SchieferdeckerTarget VersionEdition 4.2.1 (not yet published) => Edition 5.1.1 (not yet published)
22-03-2010 16:30Gyorgy RethyPrioritylow => high
22-03-2010 16:30Gyorgy RethyTarget VersionEdition 4.3.1 (not yet published) => Edition 4.2.1 (not yet published)
24-03-2010 13:18Gyorgy RethyNote Added: 0009282
24-03-2010 13:19Gyorgy RethyStatusassigned => resolved
24-03-2010 13:19Gyorgy RethyStatusresolved => assigned
24-03-2010 13:20Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
24-03-2010 13:20Gyorgy RethyStatusassigned => resolved
24-03-2010 17:31Ina SchieferdeckerStatusresolved => closed
24-03-2010 17:31Ina SchieferdeckerFixed in Version => Edition 4.2.1 (not yet published)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009137) +
+ Gyorgy Rethy    +
+ 10-12-2009 10:34    +
+ 		+ + + + +
+ Regarding "Pattern definition superfluous": I agree; Pattern and PatternElement productions are superflouos; the string in pattern matching syntactically is a normal charstring value that is semantically processed in a special way due to the pattern keyword. "Pattern" should be replaced in "CharStringMatch" by "Cstring" plus a static semantics rule that only ISO646 characters are allowed; PetternElement, PatternChar, PatternQuadruple are to be deleted (I have checked, not used elsewhere).
+
+Regarding missing () in ValueSpec: the {...} groups all the stuff between the "(" and the ")", therefore I think no another grouping is needed (seems to be a compliated rule already, additional brackets would complicate it even more).
+
+
+
+ + + + + + + + + + +
+ (0009153) +
+ Ina Schieferdecker    +
+ 04-01-2010 13:05    +
+ 		+ + + + +
+ There is a misunderstanding on Pattern and PatternElement. The CR just says, that the alternative on (""" """) is superfluous - not the syntax definition for patterns.
+
+As for the missing parentheses. Indeed, concatenation binds stronger than alternatives. However, grouping eases the reading, see e.g. also http://greenbytes.de/tech/webdav/rfc5234.html [^] in 3.10 Operator Precedence
+
+I propose to add the binding power to the TTCN-3 BNF metanotation as proposed in the uploaded file.
+
+Note however that "(" and ")" have no special binding power in the BNF definition - in the metanotation they are just terminals.
+
+
+
+ + + + + + + + + + +
+ (0009282) +
+ Gyorgy Rethy    +
+ 24-03-2010 13:18    +
+ 		+ + + + +
+ CR5343_v1.doc: OK with me.
+
+ + diff --git a/docs/mantis/CR5344.md b/docs/mantis/CR5344.md new file mode 100644 index 0000000000000000000000000000000000000000..29d3eff89799c66fa81f3d6e2d809e41fded7491 --- /dev/null +++ b/docs/mantis/CR5344.md @@ -0,0 +1,98 @@ + + + + + + + + + + + + + 0005344: Introduce range subtyping boundaries excluding the boundaries themselves - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005344Part 01: TTCN-3 Core LanguageNew Featurepublic11-09-2009 10:2816-02-2010 07:04
ReporterGyorgy Rethy 
Assigned ToIna Schieferdecker 
PriorityhighSeveritymajorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.2.1 (published 2010-07)Fixed in Versionv4.2.1 (published 2010-07) 
Clause Reference(s)6.1.2.3
Source (company - Author)L.M.Ericsson
Summary0005344: Introduce range subtyping boundaries excluding the boundaries themselves
DescriptionBoth ASN.1 and XSD define a range subtyping, which includes anything between the ranges but not the boundaries themselves. In case of integer types it is easy to map to TTCN-3 but not in the case of float values. Currently Part-9 says e.g. such an upper boundary shall be translated the boundary minus "something very small". This is not exact and depends on the platform used; an external converter may be used on a different platform than the TTCN-3 tool.
+It is proposed to introduce exclusive boundaries to TTCN-3 as well.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
parent of 0005340closed Gyorgy Rethy Part 09: Using XML with TTCN-3 Incorrect mapping of the XSD double type 
related to 0005507closed Ina Schieferdecker Part 01: TTCN-3 Core Language Infinity is a real value 
Attached Filesdoc CR5344_resolution_v1.doc (51,712) 09-12-2009 13:45
http://oldforge.etsi.org/mantis/file_download.php?file_id=2306&type=bug
Issue History
Date ModifiedUsernameFieldChange
11-09-2009 10:28Gyorgy RethyNew Issue
11-09-2009 10:28Gyorgy RethyStatusnew => assigned
11-09-2009 10:28Gyorgy RethyAssigned To => Ina Schieferdecker
11-09-2009 10:28Gyorgy RethyClause Reference(s) => 6.1.2.3
11-09-2009 10:28Gyorgy RethySource (company - Author) => L.M.Ericsson
11-09-2009 11:59Gyorgy RethyRelationship addedrelated to 0005340
11-09-2009 12:00Gyorgy RethyRelationship deletedrelated to 0005340
11-09-2009 12:00Gyorgy RethyRelationship addedparent of 0005340
07-12-2009 14:39Ina SchieferdeckerTarget Version => Edition 4.2.1 (not yet published)
09-12-2009 13:45Ina SchieferdeckerNote Added: 0009115
09-12-2009 13:45Ina SchieferdeckerFile Added: CR5344_resolution_v1.doc
09-12-2009 13:46Ina SchieferdeckerAssigned ToIna Schieferdecker => Gyorgy Rethy
09-12-2009 13:46Ina SchieferdeckerResolutionopen => fixed
09-12-2009 13:46Ina SchieferdeckerFixed in Version => Edition 4.2.1 (not yet published)
09-12-2009 16:06Gyorgy RethyNote Added: 0009128
09-12-2009 16:06Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
09-12-2009 16:06Gyorgy RethyStatusassigned => resolved
16-02-2010 07:04Ina SchieferdeckerStatusresolved => closed
28-06-2010 16:31Ina SchieferdeckerRelationship addedrelated to 0005507
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009115) +
+ Ina Schieferdecker    +
+ 09-12-2009 13:45    +
+ 		+ + + + +
+ Exclusive boundaries are denoted by "!" - see resolution v1 - please check.
+
+
+
+ + + + + + + + + + +
+ (0009128) +
+ Gyorgy Rethy    +
+ 09-12-2009 16:06    +
+ 		+ + + + +
+ OK with me.
+
+ + diff --git a/docs/mantis/CR5346.md b/docs/mantis/CR5346.md new file mode 100644 index 0000000000000000000000000000000000000000..871da62b41869ca0f6f012b30e433c96b554ba10 --- /dev/null +++ b/docs/mantis/CR5346.md @@ -0,0 +1,151 @@ + + + + + + + + + + + + + 0005346: Some more small BNF issues - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005346Part 01: TTCN-3 Core LanguageClarificationpublic13-09-2009 13:2504-01-2010 13:11
ReporterIna Schieferdecker 
Assigned ToIna Schieferdecker 
PrioritylowSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.2.1 (published 2010-07)Fixed in Versionv4.2.1 (published 2010-07) 
Clause Reference(s)Annex A
Source (company - Author)     
Summary0005346: Some more small BNF issues
Description1. ValueSpec ::= ValueKeyword ( VariableRef |
+                                 "(" { [ VariableRef [ AssignmentChar
+                                       (FieldReference | TypeDefIdentifier) ExtendedFieldReference ]
+                                       ] [","] }
+                                  ")" )
+
+TO
+
+ValueSpec ::= ValueKeyword ( VariableRef |
+                                ( "(" { VariableRef [ AssignmentChar
+                                       (FieldReference | TypeDefIdentifier) ExtendedFieldReference ]
+                                      [","] }
+                                  ")" ) )
+
+// parentheses missin
+
+
+2. OpCall ::= ConfigurationOps |
+                VerdictOps |
+                TimerOps |
+                TestcaseInstance |
+                FunctionInstance [ ExtendedFieldReference ] |
+                TemplateOps [ ExtendedFieldReference ] |
+                ActivateOp
+
+TO
+
+OpCall ::= ConfigurationOps |
+                VerdictOps |
+                TimerOps |
+                TestcaseInstance |
+                ( FunctionInstance [ ExtendedFieldReference ] ) |
+                ( TemplateOps [ ExtendedFieldReference ] ) |
+                ActivateOp
+
+// parentheses missin
+
+
+3. FriendModuleDef ::= "friend" "module" ModuleIdentifier {"," ModuleIdentifier } [SemiColon]
+
+TO
+
+FriendModuleDef ::= "module" ModuleIdentifier {"," ModuleIdentifier } [SemiColon]
+
+// FriendKeyword - part of the optional visibility of a module definition
+
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0005343closed Ina Schieferdecker small BNF issues 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
13-09-2009 13:25Ina SchieferdeckerNew Issue
13-09-2009 13:25Ina SchieferdeckerStatusnew => assigned
13-09-2009 13:25Ina SchieferdeckerAssigned To => Gyorgy Rethy
13-09-2009 13:25Ina SchieferdeckerClause Reference(s) => Annex A
13-09-2009 13:25Ina SchieferdeckerSource (company - Author) =>
13-09-2009 13:26Ina SchieferdeckerProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
13-09-2009 13:27Ina SchieferdeckerCategoryTTCN-3 Core Language => Clarification
13-09-2009 13:27Ina SchieferdeckerTarget Version => Edition 4.2.1 (not yet published)
10-12-2009 11:36Gyorgy RethyNote Added: 0009143
10-12-2009 12:44Gyorgy RethyNote Edited: 0009143
10-12-2009 12:44Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
04-01-2010 13:06Ina SchieferdeckerRelationship addedrelated to 0005343
04-01-2010 13:08Ina SchieferdeckerNote Added: 0009154
04-01-2010 13:11Ina SchieferdeckerResolutionopen => fixed
04-01-2010 13:11Ina SchieferdeckerStatusassigned => resolved
04-01-2010 13:11Ina SchieferdeckerFixed in Version => Edition 4.2.1 (not yet published)
04-01-2010 13:11Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009143) +
+ Gyorgy Rethy    +
+ 10-12-2009 11:36    +
(edited on: 10-12-2009 12:44)
+ 		+ + + + +
+ 1. ValueSpec: I think no more bracket is needed, see CR5343.
+2. OpCall: I don't think that brackets are needed, normally "|" is also functioning as an implicit bracket (but it would be just superflouos but not disturbing in this case)
+3. FriendModuleDef: but "friend" is part of the definition here. Also friend modules can have "visibility instruction":
+private friend module ...
+that looks uggly, but allowed...
+
+
+
+
+
+ + + + + + + + + + +
+ (0009154) +
+ Ina Schieferdecker    +
+ 04-01-2010 13:08    +
+ 		+ + + + +
+ I rather say that grouping improves readability.
+
+As for the 3rd issue, you are right.
+
+ + diff --git a/docs/mantis/CR5347.md b/docs/mantis/CR5347.md new file mode 100644 index 0000000000000000000000000000000000000000..b3dbf204a8b94ad5cb047907e5465d2cbd4eb273 --- /dev/null +++ b/docs/mantis/CR5347.md @@ -0,0 +1,508 @@ + + + + + + + + + + + + + 0005347: Subtyping rules when referencing fields of structured types - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005347Part 01: TTCN-3 Core LanguageClarificationpublic14-09-2009 11:1501-07-2011 15:58
ReporterGyorgy Rethy 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.1.1 (published 2009-06) 
Target Versionv4.3.2 (interim 2011)Fixed in Versionv4.3.2 (interim 2011) 
Clause Reference(s)6.2.1.1, 6.2.2.1, 6.2.5.1
Source (company - Author)L.M.Ericsson
Summary0005347: Subtyping rules when referencing fields of structured types
DescriptionThis is not covered by the current text. Proposed rules are:
+-when referencing a field, the type constraint of the field shall be part of the new type; example:
+type record R { x integer optional (1,2), y integer optional (1,2)}
+type R.x X //=> R.x is defining the type integer X (1,2)
+
+- when referencing a field, any type constraint of the structured type shall be ignored; examples:
+1)
+type record R1 { x integer optional }
+type R1 R2 ( {}, { x := omit }, { x := 4 }, { x := 5 } )
+type R2.x X2;
+
+If the constraint of the record type would be "transformed back" to constraint of the referenced field, X2 would be:
+ X2 -> type integer X2 (<empty>, omit, 4, 5)
+that is not a valid type definition.
+
+2)If the constraint of the record type is "transformed back" to a constraint of the referenced field:
+
+type record R3 { x integer optional, y integer optional } ({x:=1,y:=2}, {x:= 2,y:=1}, {x:=omit, y:=2}, {x:=1, y:=omit})
+
+R3 should have the same value space as R. But it does not have.
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Fileszip CR5347.zip (735,241) 03-09-2010 13:11
http://oldforge.etsi.org/mantis/file_download.php?file_id=2442&type=bug
doc CR5347_resolution_v2.doc (110,592) 25-05-2011 14:38
http://oldforge.etsi.org/mantis/file_download.php?file_id=2485&type=bug
doc CR5347_resolution_v3.doc (71,680) 25-05-2011 14:56
http://oldforge.etsi.org/mantis/file_download.php?file_id=2486&type=bug
doc CR5347_resolution_v4.doc (73,216) 01-07-2011 15:56
http://oldforge.etsi.org/mantis/file_download.php?file_id=2551&type=bug
Issue History
Date ModifiedUsernameFieldChange
14-09-2009 11:15Gyorgy RethyNew Issue
14-09-2009 11:15Gyorgy RethyStatusnew => assigned
14-09-2009 11:15Gyorgy RethyAssigned To => Ina Schieferdecker
14-09-2009 11:15Gyorgy RethyClause Reference(s) => 6.2.1.1, 6.2.2.1, 6.2.5.1
14-09-2009 11:15Gyorgy RethySource (company - Author) => L.M.Ericsson
07-12-2009 14:37Ina SchieferdeckerTarget Version => Edition 4.2.1 (not yet published)
04-01-2010 13:49Ina SchieferdeckerNote Added: 0009156
04-01-2010 13:49Ina SchieferdeckerTarget VersionEdition 4.2.1 (not yet published) => Edition 5.1.1 (not yet published)
22-03-2010 17:23Gyorgy RethyAssigned ToIna Schieferdecker =>
22-03-2010 17:23Gyorgy RethyStatusassigned => new
23-03-2010 12:50Gyorgy RethyAssigned To => Gyorgy Rethy
23-03-2010 12:50Gyorgy RethyStatusnew => assigned
23-03-2010 15:37Jacob Wieland - SpirentNote Added: 0009265
24-03-2010 11:04Gyorgy RethyNote Added: 0009274
24-03-2010 11:06Gyorgy RethyNote Edited: 0009274
24-03-2010 12:21Gyorgy RethyAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
03-09-2010 13:11Jacob Wieland - SpirentFile Added: CR5347.zip
03-09-2010 13:14Jacob Wieland - SpirentNote Added: 0009711
03-09-2010 13:15Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Ina Schieferdecker
03-09-2010 13:15Jacob Wieland - SpirentStatusassigned => resolved
03-09-2010 13:15Jacob Wieland - SpirentFixed in Version => Edition 4.3.1 (not yet published)
03-09-2010 13:15Jacob Wieland - SpirentResolutionopen => fixed
14-12-2010 15:29Ina SchieferdeckerNote Added: 0009970
14-12-2010 15:29Ina SchieferdeckerAssigned ToIna Schieferdecker => Gyorgy Rethy
14-12-2010 15:29Ina SchieferdeckerFixed in VersionEdition 4.3.1 (not yet published) =>
14-12-2010 15:29Ina SchieferdeckerTarget VersionEdition 4.3.1 (not yet published) => Edition 4.3.2 (interim)
25-05-2011 11:39Gyorgy RethyStatusresolved => feedback
25-05-2011 11:39Gyorgy RethyResolutionfixed => reopened
25-05-2011 11:39Gyorgy RethyNote Added: 0010047
25-05-2011 11:40Gyorgy RethyStatusfeedback => assigned
25-05-2011 13:28Gyorgy RethyNote Edited: 0010047
25-05-2011 14:38Gyorgy RethyNote Edited: 0010047
25-05-2011 14:38Gyorgy RethyFile Added: CR5347_resolution_v2.doc
25-05-2011 14:40Gyorgy RethyNote Edited: 0010047
25-05-2011 14:40Gyorgy RethyNote Edited: 0010047
25-05-2011 14:56Jacob Wieland - SpirentFile Added: CR5347_resolution_v3.doc
25-05-2011 15:50Gyorgy RethyNote Added: 0010062
25-05-2011 15:51Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
25-05-2011 15:51Gyorgy RethyStatusassigned => resolved
01-07-2011 15:56Ina SchieferdeckerFile Added: CR5347_resolution_v4.doc
01-07-2011 15:57Ina SchieferdeckerNote Added: 0010186
01-07-2011 15:58Ina SchieferdeckerStatusresolved => closed
01-07-2011 15:58Ina SchieferdeckerResolutionreopened => fixed
01-07-2011 15:58Ina SchieferdeckerFixed in Version => Edition 4.3.2 (interim)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009156) +
+ Ina Schieferdecker    +
+ 04-01-2010 13:49    +
+ 		+ + + + +
+ We should discuss if defining a synonym for a nested type definition is a wanted feature of TTCN-3 or not.
+
+Depending on the outcome, (1) we may exclude type synonyms for nested type definitions or (2) we have to develop a solution. However this is not trivial as pointed out in the examples.
+
+Hence, postponed to 2010.
+
+
+
+ + + + + + + + + + +
+ (0009265) +
+ Jacob Wieland - Spirent    +
+ 23-03-2010 15:37    +
+ 		+ + + + +
+ For consistency, the type R.x should include all values that can be
+assigned to field x in type R. Thus, it should include all values
+described by the subtypeSpec of field x, as well as the special 'value' omit.
+
+For that, one would need (the idea of) a special type construct like
+
+    type integer X optional (1,2);
+
+Entities declared with this type automatically include the special value omit
+and thus can be used for the purpose of storing values the same values as
+field x.
+
+The problem with this solution is, of course, that suddenly, a type
+(which normally only describes non-special values), now also contains omit.
+That means that the semantics of the template restrictions for this type
+need clarification:
+- template(value) R.x => all values of R.x except omit
+  (as opposed to all of R.x for non-optional field x)
+- template(omit) R.x => all values of R.x including omit
+  (as opposed to all of R.x PLUS omit for non-optional field x)
+- template(present) R.x => the same as normally
+
+However, the beauty of the solution lies in the consistency:
+It is always possible to use an entity of type R.x to field x in R and the
+other way around which is the definition of a compatible type.
+If the 'optional' would disappear from the type definition, R.x would be
+compatible to field x, but field x would not be compatible to R.x.
+
+While in my opinion, it would be nice to define the above type X as written
+also in TTCN-3, it is not really necessary, as one can always just refer
+to R.x instead or define X as:
+
+    type R.x X;
+
+to arrive at the same semantics for X.
+
+If this solution is acceptable, the following needs to be done:
+
+- describe the semantics of R.x in the section describing dotted notation
+  on types
+
+- clarify the semantics of the different kinds of declarations,
+  especially var/const/parameter/template(value)/template(omit)
+
+- define the semantics of a StructFieldSpec with an optional type which does not have an optional modifier:
+  - either this has the same semantics as if the optional modifier were present
+  - or this situation is forbidden
+
+- arrays and record of/set of types of such an optional type should also be
+  - either forbidden or
+  - explicitly allowed with the expected semantics (i.e. that they can
+    contain omit as elements) to avoid confusion.
+
+- generelly, matching mechanisms for such a type include the same matching
+  mechanisms as those for field x, i.e. also omit, * and ifpresent.
+
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+
+If this solution is unacceptable, R.x could be X without the optional part
+(this is the proposed solution 1) from the CR)
+with the drawback that not all fields x can be used as R.x, i.e.
+R.x is compatible with field x, but not the other way around.
+
+Though this is somewhat confusing at first hand, it would still be a
+useful definition. It has the advantage that no additional clarifications
+or restrictions would need to be introduced, as now R.x can only contain values
+again.
+
+The proposed solution 2) from the CR is either not consistent or is alike to
+the first solution proposed here, therefore needs no further discussion.
+
+
+
+ + + + + + + + + + +
+ (0009274) +
+ Gyorgy Rethy    +
+ 24-03-2010 11:04    +
(edited on: 24-03-2010 11:06)
+ 		+ + + + +
+ Currently record/st fields have 3 ortogonal properties:
+- name
+- type (=valid value set)
+- optionality
+
+Optionality is the propoerty of the field itself and not of the type (of the field).
+
+What would happen if making optionality property of the type instead of property of the field?
+---------------
+In case of simple types:
+1) optionality would not be part of TTCN-3 built-in types, otherwise the "optional" in
+  type record MyRec ( integer f1 optional);
+  type integer MyOptInt optional;
+would not make sense
+but this would mean that the user defined type
+  type integer MyOptint optional;
+would extend the built in integer type with one more value that is strange and contradicts the current logic of TTCN-3 (sub)typing.
+
+2) "omit" is member of the built-in types and optional in the record/set field definition shows if omit is accepted in that field or not. Thus "optional" in fields would become a special form of subtyping. In this case
+type integer MyOptInt optional;
+would make no sense as "integer" already includes "omit".
+
+But what is worse, in
+  type record MyRec {integer f1};
+field f1 should also accept "omit" as omit is member of integer.
+
+This also would mean, that if someone wants to define a type without optional, he/she should write
+  type integer MyInt (-infinity..infinity);
+
+So, this alternative 2) would not be acceptable as would change the semantics of already existing codes.
+
+
+Looking at this from the another perspective:
+When using simple type variables/parameters in expressions and assigning them to record/set fields, tools today can check the type compile time and shall check if the value is bound runtime. If omit is made a value, tools shall also check that - if the value is bound - it does not contain an omit value (except when assigned to optional fields, where omit is allowed).
+
+This, in practical terms, would alomos double the runtime checks tools has to do, thus decreasing tool performance.
+
+-------------------
+In case of structured types:
+structured types are unlike the built-in simple types, do not contain any value by definition, the legal set of values are defined by the user. In another words, they are built-in type-construction mechanisms but not built-in types. Therefore, in case of structured types, if he users wants to include "omit" into the value set of his/her type, should specify it directly, like
+  type union MyUnion { integer a1, integer a2 } optional;
+
+However, this would not be consistent to the definition of simple types, where "optional" would be forbidden (as omit would already been included into the built-in types).
+
+========================
+So, to sum up: IF omit would be made a special value in the language, this would increase language complexity; I cannot see a consistent way to handle it; it would open the way for new kind of errors, that could be checked runtime only, thus causing test case error instead of compile time errors, increase tool complexity and as a consequence, decrease tool performance;
+Example error:
+  type record MyRec {integer f1 (-infinity..infinity)};
+...
+  var integer v_int := omit;
+  var MyRec v_MyRec;
+  v_MyRec.f1 := v_int;
+
+On the other hand the advantages would be minimal. Therefore I think that this is acceptable, hence we shall go the another way.
+========================
+
+When quoting e.g. a record field, only the type property of the field is referenced. E.g.
+  type record MyRec1 {integer f1 optional (-2..2) };
+  type record MyRec2 {integer F1 (-2..2) };
+
+Myrec1.f1 and MyRec2.F1 both denotes the type integer(-2..2), though both the name and the optionality propoerties of the referenced fields do differ (but as mentioned above, they are ortogonal to the type propoerty).
+
+All subtype specs. applied to the outer type are ignored as they are not property of the fields at all, it is a property of the outer type. E.g.
+  type record MyRec3 {integer f1 optional (-2..2), integer f2 } ({omit,1},{1,1});
+also denotes the type integer(-2..2), though, when this type is used in field f1 of MyRec3, it cannot take the value e.g. -2.
+
+But this is consistent of using named types in fields, e.g.
+ type integer MyInt (-2..2);
+ type record MyRec4 {MyInt f1 optional, integer f2 } ({omit,1},{1,1});
+When used in MyRec4, f1 cannot take the value e.g. -2 either, though the type MyInt contains -2 in it value set.
+
+
+
+
+
+ + + + + + + + + + +
+ (0009711) +
+ Jacob Wieland - Spirent    +
+ 03-09-2010 13:14    +
+ 		+ + + + +
+ please review the changes in the document, changes are in sections: 6.2.1.1, 6.2.2.1, 6.2.3.2 and 6.2.5.1
+
+
+
+ + + + + + + + + + +
+ (0009970) +
+ Ina Schieferdecker    +
+ 14-12-2010 15:29    +
+ 		+ + + + +
+ Not yet finally agreed - hence shifted to 2011 for consideration.
+
+
+
+ + + + + + + + + + +
+ (0010047) +
+ Gyorgy Rethy    +
+ 25-05-2011 11:39    +
(edited on: 25-05-2011 14:40)
+ 		+ + + + +
+ Reviewing resolution... see my changes in CR5347_resolution_v2.doc.
+
+I oppose to "track back" the contraint applied to the outer type to the inner type for the following reasons:
+
+1) would be backward incompatible; up to know this was not specified explicitly, there are tool implementations ignoring the constraints of the outer type; for the users of these tools the narrower approach would be a non-backward compatible change.
+
+2) According to the current mapping rules, ASN.1 table constraint is mapped to TTCN-3 but relation constraint is ignored. To be consistent with the narrower approach, relation constraint should also be mapped that would result smaller value sets than today, i.e. would be non-backward compatible.
+example:
+MY-CLASS ::= CLASS {
+&Argument OCTET STRING,
+&identifier INTEGER UNIQUE }
+WITH SYNTAX { INFORMATION &Argument WITH ID &identifier }
+
+myObject-1 MY-CLASS ::= {INFORMATION '00'H WITH ID 1}
+myObject-2 MY-CLASS ::= {INFORMATION 'FF'H WITH ID 2}
+
+MySET MY-CLASS ::= { myObject-1 | myObject-2 }
+
+MyMessage := SEQUENCE {
+  idField MY-CLASS.&identifier ( {MySET} ),
+  valueField MY-CLASS.&Argument ( {MySET} {@idField} )
+}
+This, in fact denotes the constraint ({1,'00'H},{2,'FF'H}) to the SEQUENCE.
+
+But its equivalent TTCN-3 type today is:
+type record { integer idField (1,2), octetstring valueField ('00'O,'FF'O)};
+this allowes the values {2,'00'O} and {1,'FF'O}, that are illegal values according to the ASN.1 spec. and are used for negative testing!
+
+3) types are often defined as embedded types and used later to define values/templates or other types. If using the narrower understanding, it is not possible to extend the set of values later, while with the broader understanding it is possible to resrict the derived type, if needed.
+example:
+type record MyRec1 { record { integer fInner (1..10)} fOuter }({{1}},{{2}})
+type MyRec1.fOuter MyRec2 //this type is a record with an integer (1..10) field
+type MyRec1.fOuter MyRec3 ({1},{2}) //this one is a record where the field can take the values 1 and 2 only
+
+But it is not possible the opposite way. Pls. note, often this is the only way to use parameterized ASN.1 types in TTCN-3 -> the parameterized type itself is not importable, but the embedding type using the parameterized type with an actual parameter is imported and, referencing its field, the given instance of the parameterized type can be used in TTCN-3.
+
+4) What about record of types? To be consistent, in case of record of record of-s, the length restriction applied to the outer record of should also be applied to the inner record of...
+example:
+type record length (5) of record of integer ConstrainedRecordOfInt;
+type ConstrainedRecordOfIntg[-] ConstrainedInt; //for consistency this should be a record of restricted to 5 elements...
+
+5) The omit and the record of length transition problem could be handled by extra rules and explanations in the standard, but this would, complicate the language unnecessarily, again something with several exception rules...
+
+
+
+
+
+ + + + + + + + + + +
+ (0010062) +
+ Gyorgy Rethy    +
+ 25-05-2011 15:50    +
+ 		+ + + + +
+ Reviewed by Gyorgy and Jacob, need a final GO from the STF.
+
+
+
+ + + + + + + + + + +
+ (0010186) +
+ Ina Schieferdecker    +
+ 01-07-2011 15:57    +
+ 		+ + + + +
+ Implemented basically as proposed.
+
+ + diff --git a/docs/mantis/CR5348.md b/docs/mantis/CR5348.md new file mode 100644 index 0000000000000000000000000000000000000000..f01e838d9f9ea014449cbf2c6e39b663e577a1af --- /dev/null +++ b/docs/mantis/CR5348.md @@ -0,0 +1,224 @@ + + + + + + + + + + + + + 0005348: Transforming set operations in subtype definitions - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 07: Using ASN.1 with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005348Part 07: Using ASN.1 with TTCN-3Clarificationpublic14-09-2009 11:2119-12-2012 13:42
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritylowSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.5.1 (published 2013-04)Fixed in Versionv4.5.1 (published 2013-04) 
Clause Reference(s)9.1
Source (company - Author)L.M.Ericsson
Summary0005348: Transforming set operations in subtype definitions
DescriptionASN.1 allows constructing subtypes using set operations; It shall be specified in the transformation rules, how to transform such constraints to TTCN-3.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0005938closed Gyorgy Rethy Part 01: TTCN-3 Core Language Type restriction by template list 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
14-09-2009 11:21Gyorgy RethyNew Issue
14-09-2009 11:21Gyorgy RethyStatusnew => assigned
14-09-2009 11:21Gyorgy RethyAssigned To => Ina Schieferdecker
14-09-2009 11:21Gyorgy RethyClause Reference(s) => 9.1
14-09-2009 11:21Gyorgy RethySource (company - Author) => L.M.Ericsson
07-12-2009 14:36Ina SchieferdeckerProjectPart 01: TTCN-3 Core Language => Part 07: Using ASN.1 with TTCN-3
07-12-2009 14:36Ina SchieferdeckerTarget Version => Edition 4.2.1 (not yet published)
07-12-2009 14:36Ina SchieferdeckerAssigned ToIna Schieferdecker => Gyorgy Rethy
18-03-2010 07:45Ina SchieferdeckerTarget VersionEdition 4.2.1 (not yet published) => Edition 5.1.1 (not yet published)
22-03-2010 17:28Gyorgy RethyAssigned ToGyorgy Rethy =>
22-03-2010 17:28Gyorgy RethyStatusassigned => new
23-03-2010 12:49Gyorgy RethyAssigned To => Gyorgy Rethy
23-03-2010 12:49Gyorgy RethyStatusnew => assigned
24-03-2010 12:23Gyorgy RethyPrioritynormal => low
03-12-2010 10:25Gyorgy RethyTarget VersionEdition 4.3.1 (not yet published) => Edition 4.3.2 (interim)
27-09-2011 14:07Gyorgy RethyTarget VersionEdition 4.3.2 (interim) => Edition 4.4.1
30-11-2011 12:23Gyorgy RethyAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
30-11-2011 13:10Jacob Wieland - SpirentNote Added: 0010443
30-11-2011 13:10Jacob Wieland - SpirentRelationship addedrelated to 0005938
30-11-2011 13:19Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
10-08-2012 14:29Gyorgy RethyNote Added: 0011033
10-08-2012 14:33Gyorgy RethyNote Edited: 0011033
10-08-2012 14:34Gyorgy RethyNote Edited: 0011033
10-08-2012 14:34Gyorgy RethyAssigned ToGyorgy Rethy => Tomas Urban
13-08-2012 12:56Jacob Wieland - SpirentNote Added: 0011036
10-12-2012 16:45Tomas UrbanNote Added: 0011209
10-12-2012 16:45Tomas UrbanAssigned ToTomas Urban => Ina Schieferdecker
10-12-2012 17:00Gyorgy RethyTarget VersionEdition 4.4.1 Published 2012-04-01 => Edition 4.5.1
11-12-2012 14:01Ina SchieferdeckerNote Added: 0011225
11-12-2012 14:01Ina SchieferdeckerAssigned ToIna Schieferdecker => Gyorgy Rethy
19-12-2012 13:42Gyorgy RethyStatusassigned => closed
19-12-2012 13:42Gyorgy RethyResolutionopen => fixed
19-12-2012 13:42Gyorgy RethyFixed in Version => Edition 4.5.1
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010443) +
+ Jacob Wieland - Spirent    +
+ 30-11-2011 13:10    +
+ 		+ + + + +
+ In ASN.1 there are basically three set operations to construct subtype constraints: UNION, INTERSECTION, EXCLUSION
+
+UNION can be mapped to the "value"-list construct:
+
+A UNION B -> (A, B)
+
+INTERSECTION could be mapped to the following
+(because A AND B == NOT (NOT A OR NOT B)):
+
+A INTERSECTION B => complement(complement(A), complement(B))
+
+EXCLUSION could be mapped to the following
+(because A EXCEPT B == A AND NOT B):
+
+A EXCEPT B => complement(complement(A), B)
+
+So, any set expression should be mappable by using combinations of value-list and complement matching mechanism symbols.
+
+This, of course, would preclude that value-list is in actuality template-list, i.e. that even in type definitions, template constructions beside values and ranges are permitted (see CR5938).
+
+
+
+ + + + + + + + + + +
+ (0011033) +
+ Gyorgy Rethy    +
+ 10-08-2012 14:29    +
(edited on: 10-08-2012 14:34)
+ 		+ + + + +
+ Considering the issue raised by the CR, my conclusion is that the way of handling set arithmetics doesn't need to be specified. Until the final result is the same, it shall be left as a tool implementation option. Therefore I just propose to add the paragraph below at the end of clause 9.1 (just after table 4):
+
+"ASN.1 allows using set arithmethics in subtype constraints. In many cases these set arithmetics expressions shall be calculated before the translation to be able to convert the ASN.1 subtype into its associated TTCN-3 type. However, in some cases expressions can be translated to TTCN-3 in different ways; e.g. a UNION of consequtive integer values can be translated into a list of values, into a value range or a mixture of the two, while all these forms denote the same set of values. This standard leaves this choice open for tool implementations. The only requirement is that the resulted associated TTCN-3 type shall conform to this clause and clause 6 of ES 201 873 1 [1]."
+
+Pls. review.
+
+
+
+
+
+ + + + + + + + + + +
+ (0011036) +
+ Jacob Wieland - Spirent    +
+ 13-08-2012 12:56    +
+ 		+ + + + +
+ sounds like a pragmatic approach
+
+
+
+ + + + + + + + + + +
+ (0011209) +
+ Tomas Urban    +
+ 10-12-2012 16:45    +
+ 		+ + + + +
+ I agree with the resolution proposed by György.
+Assigned to Ina for implementation.
+
+
+
+ + + + + + + + + + +
+ (0011225) +
+ Ina Schieferdecker    +
+ 11-12-2012 14:01    +
+ 		+ + + + +
+ I agree as well - assigned to the editor for implementation
+
+ + diff --git a/docs/mantis/CR5360.md b/docs/mantis/CR5360.md new file mode 100644 index 0000000000000000000000000000000000000000..a637851f458e1760fb42b55ee8569067de6b0e0b --- /dev/null +++ b/docs/mantis/CR5360.md @@ -0,0 +1,66 @@ + + + + + + + + + + + + + 0005360: Incorrect example - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005360Part 01: TTCN-3 Core LanguageEditorialpublic21-09-2009 16:5509-12-2009 13:57
ReporterGyorgy Rethy 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.1.1 (published 2009-06) 
Target Versionv4.2.1 (published 2010-07)Fixed in Versionv4.2.1 (published 2010-07) 
Clause Reference(s)C.27
Source (company - Author)L.M. Ericsson
Summary0005360: Incorrect example
DescriptionThe last example in C.27 is:
+    str2float("-0.0") // returns a float value equal to 0.0
+but it should be (mind the minus sign before 0.0 in the comment):
+    str2float("-0.0") // returns a float value equal to -0.0
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
21-09-2009 16:55Gyorgy RethyNew Issue
21-09-2009 16:55Gyorgy RethyStatusnew => assigned
21-09-2009 16:55Gyorgy RethyAssigned To => Ina Schieferdecker
21-09-2009 16:55Gyorgy RethyClause Reference(s) => C.27
21-09-2009 16:55Gyorgy RethySource (company - Author) => L.M. Ericsson
07-12-2009 14:34Ina SchieferdeckerTarget Version => Edition 4.2.1 (not yet published)
09-12-2009 13:54Ina SchieferdeckerNote Added: 0009118
09-12-2009 13:57Ina SchieferdeckerStatusassigned => resolved
09-12-2009 13:57Ina SchieferdeckerResolutionopen => fixed
09-12-2009 13:57Ina SchieferdeckerFixed in Version => Edition 4.2.1 (not yet published)
09-12-2009 13:57Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009118) +
+ Ina Schieferdecker    +
+ 09-12-2009 13:54    +
+ 		+ + + + +
+ as proposed.
+
+ + diff --git a/docs/mantis/CR5361.md b/docs/mantis/CR5361.md new file mode 100644 index 0000000000000000000000000000000000000000..fe50b1b9e19fc5156f2644a3d364e3aa7e740db3 --- /dev/null +++ b/docs/mantis/CR5361.md @@ -0,0 +1,80 @@ + + + + + + + + + + + + + 0005361: BNF does not allow templates in return statements - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005361Part 01: TTCN-3 Core LanguageTechnicalpublic23-09-2009 17:2808-12-2009 16:28
ReporterAnthony Baire 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.1.1 (published 2009-06) 
Target Versionv4.2.1 (published 2010-07)Fixed in Versionv4.2.1 (published 2010-07) 
Clause Reference(s)19.10 A.1.6.7
Source (company - Author)     
Summary0005361: BNF does not allow templates in return statements
DescriptionIt is possible to define TTCN-3 functions that return a template. However the current definition for return statements in the BNF does not allow returning a template:
+
+  ReturnStatement ::= ReturnKeyword [Expression]
+
+It should be replaced with the following:
+
+  ReturnStatement ::= ReturnKeyword [Expression | TemplateBody]
+  /* STATIC SEMANTICS - The Expression shall evaluate to an explicit value of a type compatible with the return type for functions returning a value and shall evaluate to an explicit value, template (literal or a template instance) or a matching mechanism compatible with the return type for functions returning a template. */
+
+Note that section 19.10 should be updated as well.
+
+
+
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
23-09-2009 17:28Anthony BaireNew Issue
23-09-2009 17:28Anthony BaireStatusnew => assigned
23-09-2009 17:28Anthony BaireAssigned To => Ina Schieferdecker
23-09-2009 17:28Anthony BaireClause Reference(s) => 19.10 A.1.6.7
23-09-2009 17:28Anthony BaireSource (company - Author) =>
07-12-2009 14:34Ina SchieferdeckerTarget Version => Edition 4.2.1 (not yet published)
07-12-2009 14:34Ina SchieferdeckerDescription Updated
08-12-2009 16:15Ina SchieferdeckerNote Added: 0009100
08-12-2009 16:27Ina SchieferdeckerNote Edited: 0009100
08-12-2009 16:28Ina SchieferdeckerStatusassigned => resolved
08-12-2009 16:28Ina SchieferdeckerResolutionopen => fixed
08-12-2009 16:28Ina SchieferdeckerFixed in Version => Edition 4.2.1 (not yet published)
08-12-2009 16:28Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009100) +
+ Ina Schieferdecker    +
+ 08-12-2009 16:15    +
(edited on: 08-12-2009 16:27)
+ 		+ + + + +
+ As proposed - just rewording the comment:
+
+Expression shall evaluate to a value of a type compatible with the return type for functions returning a value. It shall evaluate to a value, template (literal or template instance), or a matching mechanism compatible with the return type for functions returning a template.
+
+
+
+ + diff --git a/docs/mantis/CR5364.md b/docs/mantis/CR5364.md new file mode 100644 index 0000000000000000000000000000000000000000..b328ee3ae20efe93bab8b58211b36a6ec8419c72 --- /dev/null +++ b/docs/mantis/CR5364.md @@ -0,0 +1,66 @@ + + + + + + + + + + + + + 0005364: [BNF] optional semicolon missing in FunctionStatementList - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005364Part 01: TTCN-3 Core LanguageTechnicalpublic23-09-2009 17:5208-12-2009 16:32
ReporterAnthony Baire 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.1.1 (published 2009-06) 
Target Versionv4.2.1 (published 2010-07)Fixed in Versionv4.2.1 (published 2010-07) 
Clause Reference(s)A.1.6.1.4
Source (company - Author)     
Summary0005364: [BNF] optional semicolon missing in FunctionStatementList
Description177. FunctionStatementList::= {FunctionStatement}+
+
+
+---> FunctionStatementList::= {FunctionStatement [SemiColon] }+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
23-09-2009 17:52Anthony BaireNew Issue
23-09-2009 17:52Anthony BaireStatusnew => assigned
23-09-2009 17:52Anthony BaireAssigned To => Ina Schieferdecker
23-09-2009 17:52Anthony BaireClause Reference(s) => A.1.6.1.4
23-09-2009 17:52Anthony BaireSource (company - Author) =>
07-12-2009 14:33Ina SchieferdeckerTarget Version => Edition 4.2.1 (not yet published)
07-12-2009 14:33Ina SchieferdeckerDescription Updated
08-12-2009 16:32Ina SchieferdeckerNote Added: 0009101
08-12-2009 16:32Ina SchieferdeckerStatusassigned => resolved
08-12-2009 16:32Ina SchieferdeckerResolutionopen => fixed
08-12-2009 16:32Ina SchieferdeckerFixed in Version => Edition 4.2.1 (not yet published)
08-12-2009 16:32Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009101) +
+ Ina Schieferdecker    +
+ 08-12-2009 16:32    +
+ 		+ + + + +
+ as proposed
+
+ + diff --git a/docs/mantis/CR5365.md b/docs/mantis/CR5365.md new file mode 100644 index 0000000000000000000000000000000000000000..5fd3e670d4e9b6882db2474fdbce19cb8aad3c28 --- /dev/null +++ b/docs/mantis/CR5365.md @@ -0,0 +1,76 @@ + + + + + + + + + + + + + 0005365: [BNF] various issues in ValueSpec - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005365Part 01: TTCN-3 Core LanguageTechnicalpublic23-09-2009 18:0916-02-2010 07:00
ReporterAnthony Baire 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.1.1 (published 2009-06) 
Target Versionv4.2.1 (published 2010-07)Fixed in Versionv4.2.1 (published 2010-07) 
Clause Reference(s)A.1.6.2.4
Source (company - Author)     
Summary0005365: [BNF] various issues in ValueSpec
DescriptionThe new definition of ValueSpec has several issues:
+ - it is not consistent with the textual description of the feature in 22.2.2
+ - it is too loose (and thus not easy to parse)
+ - the presence of TypeDefIdentifier is superfluous because this rule is already included by FieldReference
+
+  ValueSpec ::= ValueKeyword ( VariableRef | "(" { [ VariableRef [ AssignmentChar (FieldReference | TypeDefIdentifier) ExtendedFieldReference ] ] [","] } ")" )
+
+
+Suggested replacement:
+
+  ValueSpec ::= ValueKeyword ( VariableRef | "(" SingleValueSpec { "," SingleValueSpec } ")" )
+  SingleValueSpec ::= VariableRef [ AssignmentChar FieldReference ExtendedFieldReference ]
+
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
23-09-2009 18:09Anthony BaireNew Issue
23-09-2009 18:09Anthony BaireStatusnew => assigned
23-09-2009 18:09Anthony BaireAssigned To => Ina Schieferdecker
23-09-2009 18:09Anthony BaireClause Reference(s) => A.1.6.2.4
23-09-2009 18:09Anthony BaireSource (company - Author) =>
07-12-2009 14:26Ina SchieferdeckerTarget Version => Edition 4.2.1 (not yet published)
07-12-2009 14:26Ina SchieferdeckerDescription Updated
14-02-2010 14:07Ina SchieferdeckerNote Added: 0009200
14-02-2010 14:07Ina SchieferdeckerStatusassigned => resolved
14-02-2010 14:07Ina SchieferdeckerResolutionopen => fixed
14-02-2010 14:07Ina SchieferdeckerFixed in Version => Edition 4.2.1 (not yet published)
16-02-2010 07:00Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009200) +
+ Ina Schieferdecker    +
+ 14-02-2010 14:07    +
+ 		+ + + + +
+ As proposed.
+
+ + diff --git a/docs/mantis/CR5366.md b/docs/mantis/CR5366.md new file mode 100644 index 0000000000000000000000000000000000000000..fd3c7533f2e449392cef5f0981b06840a6434a3e --- /dev/null +++ b/docs/mantis/CR5366.md @@ -0,0 +1,68 @@ + + + + + + + + + + + + + 0005366: [BNF] the first expression should not be optional in SUTStatements - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005366Part 01: TTCN-3 Core LanguageTechnicalpublic23-09-2009 18:1608-12-2009 17:57
ReporterAnthony Baire 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.1.1 (published 2009-06) 
Target Versionv4.2.1 (published 2010-07)Fixed in Versionv4.2.1 (published 2010-07) 
Clause Reference(s)A.1.6.7
Source (company - Author)     
Summary0005366: [BNF] the first expression should not be optional in SUTStatements
Description549 SUTStatements ::= ActionKeyword "(" [ActionText ] {StringOp ActionText} ")"
+
+
+Suggested replacement:
+
+--> SUTStatements ::= ActionKeyword "(" ActionText {StringOp ActionText} ")"
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
23-09-2009 18:16Anthony BaireNew Issue
23-09-2009 18:16Anthony BaireStatusnew => assigned
23-09-2009 18:16Anthony BaireAssigned To => Ina Schieferdecker
23-09-2009 18:16Anthony BaireClause Reference(s) => A.1.6.7
23-09-2009 18:16Anthony BaireSource (company - Author) =>
07-12-2009 14:23Ina SchieferdeckerTarget Version => Edition 4.2.1 (not yet published)
07-12-2009 14:23Ina SchieferdeckerDescription Updated
08-12-2009 17:57Ina SchieferdeckerNote Added: 0009105
08-12-2009 17:57Ina SchieferdeckerStatusassigned => resolved
08-12-2009 17:57Ina SchieferdeckerResolutionopen => fixed
08-12-2009 17:57Ina SchieferdeckerFixed in Version => Edition 4.2.1 (not yet published)
08-12-2009 17:57Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009105) +
+ Ina Schieferdecker    +
+ 08-12-2009 17:57    +
+ 		+ + + + +
+ as proposed.
+
+ + diff --git a/docs/mantis/CR5368.md b/docs/mantis/CR5368.md new file mode 100644 index 0000000000000000000000000000000000000000..406939cef047c6dc662056cff5434aaeb17ab9da --- /dev/null +++ b/docs/mantis/CR5368.md @@ -0,0 +1,168 @@ + + + + + + + + + + + + + 0005368: [BNF] FromClause is ambiguous and nonsensical - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005368Part 01: TTCN-3 Core LanguageTechnicalpublic24-09-2009 14:1304-01-2010 13:18
ReporterAnthony Baire 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionwon't fix 
PlatformOSOS Version
Product Versionv4.1.1 (published 2009-06) 
Target Versionv4.2.1 (published 2010-07)Fixed in Versionv4.2.1 (published 2010-07) 
Clause Reference(s)A.1.6.2.4
Source (company - Author)     
Summary0005368: [BNF] FromClause is ambiguous and nonsensical
DescriptionIn 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
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
24-09-2009 14:13Anthony BaireNew Issue
24-09-2009 14:13Anthony BaireStatusnew => assigned
24-09-2009 14:13Anthony BaireAssigned To => Ina Schieferdecker
24-09-2009 14:13Anthony BaireClause Reference(s) => A.1.6.2.4
24-09-2009 14:13Anthony BaireSource (company - Author) =>
07-12-2009 14:21Ina SchieferdeckerTarget Version => Edition 4.2.1 (not yet published)
07-12-2009 14:21Ina SchieferdeckerDescription Updated
08-12-2009 18:00Ina SchieferdeckerNote Added: 0009106
08-12-2009 18:00Ina SchieferdeckerStatusassigned => closed
08-12-2009 18:00Ina SchieferdeckerResolutionopen => no change required
08-12-2009 18:00Ina SchieferdeckerFixed in Version => Edition 4.2.1 (not yet published)
09-12-2009 10:30Anthony BaireStatusclosed => feedback
09-12-2009 10:30Anthony BaireResolutionno change required => reopened
09-12-2009 10:30Anthony BaireNote Added: 0009111
09-12-2009 11:19Ina SchieferdeckerNote Added: 0009114
04-01-2010 13:18Ina SchieferdeckerStatusfeedback => closed
04-01-2010 13:18Ina SchieferdeckerResolutionreopened => 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).
+
+ + diff --git a/docs/mantis/CR5369.md b/docs/mantis/CR5369.md new file mode 100644 index 0000000000000000000000000000000000000000..5c4441f878648f2f2965c440ea6518bd12ecea5e --- /dev/null +++ b/docs/mantis/CR5369.md @@ -0,0 +1,106 @@ + + + + + + + + + + + + + 0005369: [BNF] TemplateActualParList does not support the assignment notation - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005369Part 01: TTCN-3 Core LanguageTechnicalpublic24-09-2009 15:0114-02-2010 15:08
ReporterAnthony Baire 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.1.1 (published 2009-06) 
Target Versionv4.2.1 (published 2010-07)Fixed in Versionv4.2.1 (published 2010-07) 
Clause Reference(s)A.1.6.1.3
Source (company - Author)     
Summary0005369: [BNF] TemplateActualParList does not support the assignment notation
DescriptionTo keep consistency with function/testcases & altstep instances, template invocation should allow the assignment notation in the parameter list
+
+    TemplateActualParList ::= "(" TemplateActualPar {"," TemplateActualPar} ")"
+
+--> TemplateActualParList ::= "(" ( TemplateActualPar {"," TemplateActualPar} ) | ( TemplateActualParAssignment { "," TemplateActualParAssignment } ) ")"
+    TemplateActualParAssignment ::= TemplateInstanceAssignment
+
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
24-09-2009 15:01Anthony BaireNew Issue
24-09-2009 15:01Anthony BaireStatusnew => assigned
24-09-2009 15:01Anthony BaireAssigned To => Ina Schieferdecker
24-09-2009 15:01Anthony BaireClause Reference(s) => A.1.6.1.3
24-09-2009 15:01Anthony BaireSource (company - Author) =>
05-10-2009 17:41Anthony BaireNote Added: 0009041
07-12-2009 14:09Ina SchieferdeckerTarget Version => Edition 4.2.1 (not yet published)
14-02-2010 15:07Ina SchieferdeckerNote Added: 0009204
14-02-2010 15:08Ina SchieferdeckerStatusassigned => resolved
14-02-2010 15:08Ina SchieferdeckerResolutionopen => fixed
14-02-2010 15:08Ina SchieferdeckerFixed in Version => Edition 4.2.1 (not yet published)
14-02-2010 15:08Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009041) +
+ Anthony Baire    +
+ 05-10-2009 17:41    +
+ 		+ + + + +
+ The parenthesis are misplaced in the proposed resolution. Please use the following one
+
+--> TemplateActualParList ::= "(" ( TemplateActualPar {"," TemplateActualPar} | TemplateActualParAssignment { "," TemplateActualParAssignment } ) ")"
+
+
+
+ + + + + + + + + + +
+ (0009204) +
+ Ina Schieferdecker    +
+ 14-02-2010 15:07    +
+ 		+ + + + +
+ As proposed.
+
+ + diff --git a/docs/mantis/CR5370.md b/docs/mantis/CR5370.md new file mode 100644 index 0000000000000000000000000000000000000000..c8633fb6933dacf71faf1840a47790829f44e58e --- /dev/null +++ b/docs/mantis/CR5370.md @@ -0,0 +1,70 @@ + + + + + + + + + + + + + 0005370: [BNF] TemplateInstanceAssignment cannot be used with value parameters - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005370Part 01: TTCN-3 Core LanguageTechnicalpublic24-09-2009 15:1414-02-2010 14:16
ReporterAnthony Baire 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.1.1 (published 2009-06) 
Target Versionv4.2.1 (published 2010-07)Fixed in Versionv4.2.1 (published 2010-07) 
Clause Reference(s)A.1.6.1.3
Source (company - Author)     
Summary0005370: [BNF] TemplateInstanceAssignment cannot be used with value parameters
DescriptionActual value parameters are parsed as a TemplateInstance, however the assignment notation does not allow being used with value parameters.
+
+    TemplateInstanceAssignment ::= TemplateParIdentifier ":=" InLineTemplate
+
+--> TemplateInstanceAssignment ::= (ValueParIdentifier | TemplateParIdentifier) ":=" InLineTemplate
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0005378closed Ina Schieferdecker [BNF] the assignment notation in actual parameters is not usable with value, timer and port parameters 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
24-09-2009 15:14Anthony BaireNew Issue
24-09-2009 15:14Anthony BaireStatusnew => assigned
24-09-2009 15:14Anthony BaireAssigned To => Ina Schieferdecker
24-09-2009 15:14Anthony BaireClause Reference(s) => A.1.6.1.3
24-09-2009 15:14Anthony BaireSource (company - Author) =>
07-12-2009 14:15Ina SchieferdeckerTarget Version => Edition 4.2.1 (not yet published)
07-12-2009 14:17Ina SchieferdeckerRelationship addedduplicate of 0005378
14-02-2010 14:10Ina SchieferdeckerRelationship deleted0005378
14-02-2010 14:11Ina SchieferdeckerRelationship addedrelated to 0005378
14-02-2010 14:16Ina SchieferdeckerNote Added: 0009201
14-02-2010 14:16Ina SchieferdeckerStatusassigned => resolved
14-02-2010 14:16Ina SchieferdeckerResolutionopen => fixed
14-02-2010 14:16Ina SchieferdeckerFixed in Version => Edition 4.2.1 (not yet published)
14-02-2010 14:16Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009201) +
+ Ina Schieferdecker    +
+ 14-02-2010 14:16    +
+ 		+ + + + +
+ 152. TemplateInstanceAssignment ::= ( TemplateParIdentifier | ValueParIdentifier )
+                                      ":=" InLineTemplate
+/* STATIC SEMANTICS – if a value parameter is used, the inline template shall evaluate to a value */
+
+ + diff --git a/docs/mantis/CR5375.md b/docs/mantis/CR5375.md new file mode 100644 index 0000000000000000000000000000000000000000..68a9fe59b78539b35adb8eaa6b55b8dce0e5d8c5 --- /dev/null +++ b/docs/mantis/CR5375.md @@ -0,0 +1,82 @@ + + + + + + + + + + + + + 0005375: [BNF] template fields cannot be accessed - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005375Part 01: TTCN-3 Core LanguageTechnicalpublic02-10-2009 12:0514-02-2010 14:23
ReporterAnthony Baire 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.1.1 (published 2009-06) 
Target Versionv4.2.1 (published 2010-07)Fixed in Versionv4.2.1 (published 2010-07) 
Clause Reference(s)A.1.6.1.2 A.1.6.1.3
Source (company - Author)     
Summary0005375: [BNF] template fields cannot be accessed
DescriptionSections 15.6.2 and 15.6.3 explicitly state that template fields can be accessed using the dot or index notation:
+
+  Â« Both templates and template variables allow referencing sub-fields inside a template definition using the dot notation. »
+
+  Â« Both templates and template variables allow referencing elements of a record of or set of template or field using
+the index notation. »
+
+
+However the BNF allows such kind of references only on template variables and only when reading the content of the variable.
+
+Proposed changes:
+
+    SingleValueOrAttrib ::= MatchingSymbol | SingleExpression | TemplateRefWithParList
+--> SingleValueOrAttrib ::= MatchingSymbol | SingleExpression | TemplateRefWithParList [ExtendedFieldReference]
+
+    VariableRef ::= (VarIdentifier | ValueParIdentifier) [ExtendedFieldReference]
+--> VariableRef ::= (VarIdentifier | ValueParIdentifier | TemplateParIdentifier) [ExtendedFieldReference]
+
+
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
02-10-2009 12:05Anthony BaireNew Issue
02-10-2009 12:05Anthony BaireStatusnew => assigned
02-10-2009 12:05Anthony BaireAssigned To => Ina Schieferdecker
02-10-2009 12:05Anthony BaireClause Reference(s) => A.1.6.1.2 A.1.6.1.3
02-10-2009 12:05Anthony BaireSource (company - Author) =>
07-12-2009 14:14Ina SchieferdeckerTarget Version => Edition 4.2.1 (not yet published)
14-02-2010 14:22Ina SchieferdeckerNote Added: 0009202
14-02-2010 14:23Ina SchieferdeckerStatusassigned => resolved
14-02-2010 14:23Ina SchieferdeckerResolutionopen => fixed
14-02-2010 14:23Ina SchieferdeckerFixed in Version => Edition 4.2.1 (not yet published)
14-02-2010 14:23Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009202) +
+ Ina Schieferdecker    +
+ 14-02-2010 14:22    +
+ 		+ + + + +
+ As proposed.
+
+ + diff --git a/docs/mantis/CR5377.md b/docs/mantis/CR5377.md new file mode 100644 index 0000000000000000000000000000000000000000..8f8b6e8219ac56c0cc6aa65cf21603670a41b962 --- /dev/null +++ b/docs/mantis/CR5377.md @@ -0,0 +1,67 @@ + + + + + + + + + + + + + 0005377: Wrong timer declaration in example - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005377Part 01: TTCN-3 Core LanguageEditorialpublic05-10-2009 14:2209-12-2009 14:10
ReporterGyorgy Rethy 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.2.1 (published 2010-07)Fixed in Versionv4.2.1 (published 2010-07) 
Clause Reference(s)21.2.8
Source (company - Author)L.M.Ericcson
Summary0005377: Wrong timer declaration in example
DescriptionIn the example
+timer T(10.0); // create a timer
+
+Should be
+timer T := 10.0;
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
05-10-2009 14:22Gyorgy RethyNew Issue
05-10-2009 14:22Gyorgy RethyStatusnew => assigned
05-10-2009 14:22Gyorgy RethyAssigned To => Ina Schieferdecker
05-10-2009 14:22Gyorgy RethyClause Reference(s) => 21.2.8
05-10-2009 14:22Gyorgy RethySource (company - Author) => L.M.Ericcson
07-12-2009 14:12Ina SchieferdeckerTarget Version => Edition 4.2.1 (not yet published)
09-12-2009 14:10Ina SchieferdeckerNote Added: 0009119
09-12-2009 14:10Ina SchieferdeckerStatusassigned => resolved
09-12-2009 14:10Ina SchieferdeckerResolutionopen => fixed
09-12-2009 14:10Ina SchieferdeckerFixed in Version => Edition 4.2.1 (not yet published)
09-12-2009 14:10Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009119) +
+ Ina Schieferdecker    +
+ 09-12-2009 14:10    +
+ 		+ + + + +
+ as proposed.
+
+ + diff --git a/docs/mantis/CR5378.md b/docs/mantis/CR5378.md new file mode 100644 index 0000000000000000000000000000000000000000..16c9cb4f80e39cb4a75b2cf7c7dfb79fd3381ede --- /dev/null +++ b/docs/mantis/CR5378.md @@ -0,0 +1,80 @@ + + + + + + + + + + + + + 0005378: [BNF] the assignment notation in actual parameters is not usable with value, timer and port parameters - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005378Part 01: TTCN-3 Core LanguageTechnicalpublic05-10-2009 17:3714-02-2010 14:38
ReporterAnthony Baire 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.1.1 (published 2009-06) 
Target Versionv4.2.1 (published 2010-07)Fixed in Versionv4.2.1 (published 2010-07) 
Clause Reference(s)A.1.6.1.3 A.1.6.1.4
Source (company - Author)     
Summary0005378: [BNF] the assignment notation in actual parameters is not usable with value, timer and port parameters
DescriptionSuggested changes to be in adequation with the content of FunctionActualPar:
+
+    FunctionActualParAssignment ::= TemplateInstanceAssignment | ComponentRefAssignment
+--> FunctionActualParAssignment ::= TimerRefAssignment | TemplateInstanceAssignment | PortAssignment | ComponentRefAssignment
+
+    TemplateInstanceAssignment ::= TemplateParIdentifier ":=" InLineTemplate
+--> TemplateInstanceAssignment ::= ( ValueParIdentifier | TemplateParIdentifier ) ":=" InLineTemplate
+    /* STATIC SEMANTICS - When the corresponding formal parameter is not of template type the TemplateInstance production shall resolve to one or more SingleExpressions i.e. equivalent to the Expression production */
+
+
+New rules:
+
+--> TimerRefAssignment ::= TimerParIdentifier ":=" TimerRef
+
+--> PortAssignment ::= PortParIdentifier ":=" Port
+
+
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0005370closed Ina Schieferdecker [BNF] TemplateInstanceAssignment cannot be used with value parameters 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
05-10-2009 17:37Anthony BaireNew Issue
05-10-2009 17:37Anthony BaireStatusnew => assigned
05-10-2009 17:37Anthony BaireAssigned To => Ina Schieferdecker
05-10-2009 17:37Anthony BaireClause Reference(s) => A.1.6.1.3 A.1.6.1.4
05-10-2009 17:37Anthony BaireSource (company - Author) =>
07-12-2009 14:12Ina SchieferdeckerTarget Version => Edition 4.2.1 (not yet published)
07-12-2009 14:12Ina SchieferdeckerDescription Updated
07-12-2009 14:17Ina SchieferdeckerRelationship addedhas duplicate 0005370
14-02-2010 14:10Ina SchieferdeckerRelationship deletedhas duplicate 0005370
14-02-2010 14:11Ina SchieferdeckerRelationship addedrelated to 0005370
14-02-2010 14:36Ina SchieferdeckerNote Added: 0009203
14-02-2010 14:36Ina SchieferdeckerStatusassigned => resolved
14-02-2010 14:36Ina SchieferdeckerResolutionopen => fixed
14-02-2010 14:36Ina SchieferdeckerFixed in Version => Edition 4.2.1 (not yet published)
14-02-2010 14:38Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009203) +
+ Ina Schieferdecker    +
+ 14-02-2010 14:36    +
+ 		+ + + + +
+ As proposed.
+
+ + diff --git a/docs/mantis/CR5380.md b/docs/mantis/CR5380.md new file mode 100644 index 0000000000000000000000000000000000000000..e6fbd475e57380225c081a81a9387ff5c2c9caa3 --- /dev/null +++ b/docs/mantis/CR5380.md @@ -0,0 +1,65 @@ + + + + + + + + + + + + + 0005380: Character string compatibility is missing - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005380Part 01: TTCN-3 Core LanguageTechnicalpublic07-10-2009 21:3009-12-2009 14:12
ReporterGyorgy Rethy 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.1.1 (published 2009-06) 
Target Versionv4.2.1 (published 2010-07)Fixed in Versionv4.2.1 (published 2010-07) 
Clause Reference(s)6.3.1
Source (company - Author)L.M.Ericsson
Summary0005380: Character string compatibility is missing
DescriptionCharacter string compatibility rules for string of the *same* root type is missing. The text curently is: "For variables, constants, templates, etc. of simple basic types and bitsring, hexstring and octetstring types the value "b" is compatible to type "A" if type "B" resolves to the same root type as type "A" (e.g. integer) and it does not violate subtyping (e.g. ranges, length restrictions) of type "A"."
+But it shoud be:
+"For variables, constants, templates, etc. of simple basic types and basic string types the value "b" is compatible to type "A" if type "B" resolves to the same root type as type "A" (e.g. integer) and it does not violate subtyping (e.g. ranges, length restrictions) of type "A"."
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
07-10-2009 21:30Gyorgy RethyNew Issue
07-10-2009 21:30Gyorgy RethyStatusnew => assigned
07-10-2009 21:30Gyorgy RethyAssigned To => Ina Schieferdecker
07-10-2009 21:30Gyorgy RethyClause Reference(s) => 6.3.1
07-10-2009 21:30Gyorgy RethySource (company - Author) => L.M.Ericsson
07-12-2009 14:06Ina SchieferdeckerTarget Version => Edition 4.2.1 (not yet published)
09-12-2009 14:12Ina SchieferdeckerNote Added: 0009120
09-12-2009 14:12Ina SchieferdeckerStatusassigned => resolved
09-12-2009 14:12Ina SchieferdeckerResolutionopen => fixed
09-12-2009 14:12Ina SchieferdeckerFixed in Version => Edition 4.2.1 (not yet published)
09-12-2009 14:12Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009120) +
+ Ina Schieferdecker    +
+ 09-12-2009 14:12    +
+ 		+ + + + +
+ as proposed.
+
+ + diff --git a/docs/mantis/CR5388.md b/docs/mantis/CR5388.md new file mode 100644 index 0000000000000000000000000000000000000000..e4b25ac56953c3c77e0f507607d29b3104c03d08 --- /dev/null +++ b/docs/mantis/CR5388.md @@ -0,0 +1,131 @@ + + + + + + + + + + + + + 0005388: Order of union fields shall be specified - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005388Part 09: Using XML with TTCN-3Clarificationpublic09-10-2009 21:3101-02-2010 11:13
ReporterGyorgy Rethy 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.1.1 (published 2009-06) 
Target Versionv4.2.1 (published 2010-07)Fixed in Versionv4.2.1 (published 2010-07) 
Clause Reference(s)7.5.3
For STF discussion
Source (company - Author)L.M.Ericsson
Summary0005388: Order of union fields shall be specified
DescriptionThe mapping specifies that alternatives of XSD union types shall be mapped to TTCN-3 union fields, but the order of the fields is not defined. Thus a tool changing the textual order of the alternatives would conform. In XSD Part-2 $2.5.1.3 it is defined that when decoding XML elements, derived by union , the received value shall be matched in the textual order of the alternatives and the first matching alternative shall be selected. If changing the order during the conversion, it may not be possible to follow this rule during decoding the XML content.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR5388_resolution_v1.doc (88,064) 08-12-2009 14:26
http://oldforge.etsi.org/mantis/file_download.php?file_id=2291&type=bug
Issue History
Date ModifiedUsernameFieldChange
09-10-2009 21:31Gyorgy RethyNew Issue
09-10-2009 21:31Gyorgy RethyStatusnew => assigned
09-10-2009 21:31Gyorgy RethyAssigned To => Gyorgy Rethy
09-10-2009 21:31Gyorgy RethyClause Reference(s) => 7.5.3
09-10-2009 21:31Gyorgy RethySource (company - Author) => L.M.Ericsson
07-12-2009 14:05Ina SchieferdeckerTarget Version => Edition 4.2.1 (not yet published)
08-12-2009 14:26Gyorgy RethyFile Added: CR5388_resolution_v1.doc
08-12-2009 14:27Gyorgy RethyNote Added: 0009095
08-12-2009 14:27Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
01-02-2010 11:13Gyorgy RethyNote Added: 0009173
01-02-2010 11:13Gyorgy RethyStatusassigned => closed
01-02-2010 11:13Gyorgy RethyResolutionopen => fixed
01-02-2010 11:13Gyorgy RethyFixed in Version => Edition 4.2.1 (not yet published)
01-02-2010 11:13Gyorgy RethyNote Added: 0009174
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009095) +
+ Gyorgy Rethy    +
+ 08-12-2009 14:27    +
+ 		+ + + + +
+ CR5388_resolution_v1.doc: ready for review
+
+
+
+ + + + + + + + + + +
+ (0009173) +
+ Gyorgy Rethy    +
+ 01-02-2010 11:13    +
+ 		+ + + + +
+ Implemented as in CR5388_resolution_v1.doc.
+
+
+
+ + + + + + + + + + +
+ (0009174) +
+ Gyorgy Rethy    +
+ 01-02-2010 11:13    +
+ 		+ + + + +
+ Implemented as in CR5388_resolution_v1.doc.
+
+ + diff --git a/docs/mantis/CR5389.md b/docs/mantis/CR5389.md new file mode 100644 index 0000000000000000000000000000000000000000..c37ddfe56352870091a5ab1b2afc82721a5b27c3 --- /dev/null +++ b/docs/mantis/CR5389.md @@ -0,0 +1,38 @@ + + + + + + + + + + + + + 0005389: Wrong attribute name in the unnamed union example - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005389Part 09: Using XML with TTCN-3Editorialpublic10-10-2009 10:1408-12-2009 08:52
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.2.1 (published 2010-07)Fixed in Versionv4.2.1 (published 2010-07) 
Clause Reference(s)7.5.3
For STF discussion
Source (company - Author)L.M.Ericsson
Summary0005389: Wrong attribute name in the unnamed union example
DescriptionIn example 1:
+<xsd:simpleType name="e21named">
+    <xsd:union itemType="xsd:integer xsd:boolean"/>
+</xsd:simpleType>
+
+should be:
+<xsd:simpleType name="e21named">
+    <xsd:union memberTypes="xsd:integer xsd:boolean"/>
+</xsd:simpleType>
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
10-10-2009 10:14Gyorgy RethyNew Issue
10-10-2009 10:14Gyorgy RethyStatusnew => assigned
10-10-2009 10:14Gyorgy RethyAssigned To => Gyorgy Rethy
10-10-2009 10:14Gyorgy RethyClause Reference(s) => 7.5.3
10-10-2009 10:14Gyorgy RethySource (company - Author) => L.M.Ericsson
07-12-2009 14:04Ina SchieferdeckerTarget Version => Edition 4.2.1 (not yet published)
08-12-2009 08:52Gyorgy RethyStatusassigned => closed
08-12-2009 08:52Gyorgy RethyResolutionopen => fixed
08-12-2009 08:52Gyorgy RethyFixed in Version => Edition 4.2.1 (not yet published)
+
+ + + + +
+ There are no notes attached to this issue.
+ + diff --git a/docs/mantis/CR5393.md b/docs/mantis/CR5393.md new file mode 100644 index 0000000000000000000000000000000000000000..5faeb39cbd742a2a3c2c0742c17c0fb7ee21b398 --- /dev/null +++ b/docs/mantis/CR5393.md @@ -0,0 +1,207 @@ + + + + + + + + + + + + + 0005393: Follow-up: 0005291: BNF - friend definitions should have no visibility - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005393Part 01: TTCN-3 Core LanguageEditorialpublic13-10-2009 16:0108-12-2009 18:28
ReporterPhilip Makedonski 
Assigned ToIna Schieferdecker 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.1.1 (published 2009-06) 
Target Versionv4.2.1 (published 2010-07)Fixed in Versionv4.2.1 (published 2010-07) 
Clause Reference(s)A.1.6.1.0 General, Multiple
Source (company - Author)University of Göttingen
Summary0005393: Follow-up: 0005291: BNF - friend definitions should have no visibility
DescriptionSince I cannot reopen a closed issue, this issue is related to issue 0005291 and the visibility problems with friend modules, import statements and groups:
+
+
+(original text by Gyorgy Rethy, my comments in the bottom)
+
+The current BNF allows visibility for friend definitions, while the textual part (clause 8.2.4) does not:
+8.2.4 Definition of friend modules
+  Syntactical Structure
+  friend module ModuleIdentifier { "," ModuleIdentifier } ";"
+
+On the other hand side clause 8.2.5 says "(top level definitions) They are by default public except for imported definitions which are by default private."
+
+Thus friend definitions, according to $8.2.5, should be public. But, in fact, they have meaning for the given module only and they are not importable; hence, as a matter of fact, they are always private.
+-------------------
+Two solutions are possible:
+1) (preferred) Make the private keyword mandatory in $8.2.4:
+Syntactical Structure
+  private friend module ModuleIdentifier { "," ModuleIdentifier } ";"
+
+2) Modify the text in $8.2.5:
+"They are by default public except for imported definitions and friend definitions which are by default private.
+...
+The visibility of imported definitions and friend definitions are by default always private. All other module definitions are by default public."
+-------------
+Solution 1), though would introduce a mandatory syntax, which is optional for other definitions, is the preferred one, as solution 2) would introduce a new exception; users looking at a friend definitions without a visibility keyword could think that friend lists are also imported.
+
+======================================================
+
+(commment by Ina Schieferdecker)
+
+In analogy to groups, which can be public only, a solution can be:
+
+[ private ] friend module ModuleIdentifier { "," ModuleIdentifier } ";"
+
+Adding a restriction:
+
+In addition to the general static rules of TTCN 3 given in clause 5, the following restrictions apply:
+
+a) Only private visibility can be defined for friend definitions as they are always private.
+
+And extending 8.2.5 accordingly:
+
+Top-level module definitions and import statements have a visibility, which can be explicitly set. They are by default public except for imported and friend definitions. Import definitions are by default private. Friend definitions are private only. Group definitions are public only.
+
+======================================================
+
+(my comments)
+
+...and confusion ensues...
+
+Why does the description as "by default" keep being brought up in the context of import and friend definitions? The standard currently says "private only" and "always private" for imports and "public only" and "always public" for groups. What would "private by default" suggest in this context? That they can eventually be made friend or public?!
+
+I'd keep the wording consistent to avoid further confusion - either "public only" or "always public" in all instances, but adding "by default" to the mix is going to far if by that one of the former expressions is meant.. that is if I am not missing some part of the discussion..
+
+So to spell it out: Multiple adaptations will be necessary in text, to cover all the instances, but briefly:
+
+"Import and friend definitions cannot be imported and thus can be private only, group definitions can be public only. All other importable definitions are public by default."
+
+This would reflect the default visibility settings (in the case that the syntax is not changed so as to require that imports and friends are explicitly declared as private, although it will be necessary sooner or later).
+
+In any case, one proposal for the syntax will therefore be:
+
+{
+ (
+  ( [ "private" ]
+    ( ImportDef |
+      FriendDef
+    )
+  )
+ |
+  ( [ "public" ]
+    GroupDef
+  )
+ |
+  ( [ Visibility ] (
+      TypeDef |
+      ConstDef |
+      TemplateDef |
+      ModuleParDef |
+      FunctionDef |
+      SignatureDef |
+      TestcaseDef |
+      AltstepDef |
+      ExtFunctionDef
+  )
+ )
+ [ WithStatement ]
+ [ ";" ]
+}+
+
+, where the optionality of the "private" and "public" visibility modifiers may be dropped.
+
+Changes have to be propagated accordingly to all the relevant sections.
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
13-10-2009 16:01Philip MakedonskiNew Issue
13-10-2009 16:01Philip MakedonskiStatusnew => assigned
13-10-2009 16:01Philip MakedonskiAssigned To => Ina Schieferdecker
13-10-2009 16:01Philip MakedonskiClause Reference(s) => A.1.6.1.0 General, Multiple
13-10-2009 16:01Philip MakedonskiSource (company - Author) => University of Göttingen
07-12-2009 14:04Ina SchieferdeckerTarget Version => Edition 4.2.1 (not yet published)
08-12-2009 18:04Ina SchieferdeckerNote Added: 0009107
08-12-2009 18:12Ina SchieferdeckerNote Added: 0009108
08-12-2009 18:28Ina SchieferdeckerStatusassigned => resolved
08-12-2009 18:28Ina SchieferdeckerResolutionopen => fixed
08-12-2009 18:28Ina SchieferdeckerFixed in Version => Edition 4.2.1 (not yet published)
08-12-2009 18:28Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009107) +
+ Ina Schieferdecker    +
+ 08-12-2009 18:04    +
+ 		+ + + + +
+ In version 4.1.3, the import of imports has been introduced. Therefore it is required that import statements can be made visible - in order to enable their imports. They are private by default, which means that whenever no visibility is given the import statement is a private one. By giving a visibility explicitly, the visibility of imports can be overwritten.
+
+
+
+ + + + + + + + + + +
+ (0009108) +
+ Ina Schieferdecker    +
+ 08-12-2009 18:12    +
+ 		+ + + + +
+ It was agreed to make the various cases for visibility explicit in the BNF:
+
+ModuleDefinition ::= ( ([Visibility]
+                         ( TypeDef |
+                           ConstDef |
+                           TemplateDef |
+                           ModuleParDef |
+                           FunctionDef |
+                           SignatureDef |
+                           TestcaseDef |
+                           AltstepDef |
+                           ImportDef |
+                           ExtFunctionDef |
+                           ExtConstDef )
+                         ) |
+                         (["public"] GroupDef ) |
+                         (["private"] FriendModuleDef )
+                      ) [WithStatement]
+
+ + diff --git a/docs/mantis/CR5394.md b/docs/mantis/CR5394.md new file mode 100644 index 0000000000000000000000000000000000000000..9d6a0336cbf78d823157a8d036143724cc339884 --- /dev/null +++ b/docs/mantis/CR5394.md @@ -0,0 +1,127 @@ + + + + + + + + + + + + + 0005394: .NET framework mapping for TRI - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 05: TTCN-3 Runtime Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005394Part 05: TTCN-3 Runtime Interface New Featurepublic14-10-2009 13:1526-03-2010 18:09
ReporterAndrus Lehtmets 
Assigned ToIna Schieferdecker 
PriorityurgentSeveritymajorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.1.1 (published 2009-06) 
Target VersionFixed in Versionv4.2.1 (published 2010-07) 
Clause Reference(s)Part 5: TTCN-3 Runtime Interface (TRI)
Source (company - Author)Elvior
Summary0005394: .NET framework mapping for TRI
Description.NET framework mapping for TRI is missing in TTCN-3 specification. We have prepared relevant specification, see attachment.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0005395closed Ina Schieferdecker Part 06: TTCN-3 Control Interface .NET framework mapping for TCI 
Attached Filesdoc TRI_NET_mapping.doc (147,456) 14-10-2009 13:15
http://oldforge.etsi.org/mantis/file_download.php?file_id=2267&type=bug
doc CR5394_v1.doc (100,864) 26-03-2010 10:22
http://oldforge.etsi.org/mantis/file_download.php?file_id=2376&type=bug
Issue History
Date ModifiedUsernameFieldChange
14-10-2009 13:15Andrus LehtmetsNew Issue
14-10-2009 13:15Andrus LehtmetsStatusnew => assigned
14-10-2009 13:15Andrus LehtmetsAssigned To => Ina Schieferdecker
14-10-2009 13:15Andrus LehtmetsFile Added: TRI_NET_mapping.doc
14-10-2009 13:15Andrus LehtmetsClause Reference(s) => Part 5: TTCN-3 Runtime Interface (TRI)
14-10-2009 13:15Andrus LehtmetsSource (company - Author) => Elvior
15-02-2010 05:07Ina SchieferdeckerTarget Version => Edition 5.1.1 (not yet published)
23-03-2010 12:48Gyorgy RethyNote Added: 0009257
23-03-2010 12:48Gyorgy RethyPrioritynormal => urgent
23-03-2010 12:48Gyorgy RethyTarget VersionEdition 4.3.1 (not yet published) => Edition 4.2.2 (not yet published)
25-03-2010 11:38Ina SchieferdeckerRelationship addedrelated to 0005395
26-03-2010 10:22Ina SchieferdeckerFile Added: CR5394_v1.doc
26-03-2010 10:22Ina SchieferdeckerResolutionopen => fixed
26-03-2010 10:22Ina SchieferdeckerFixed in Version => Edition 4.2.1 (not yet published)
26-03-2010 18:08Ina SchieferdeckerNote Added: 0009323
26-03-2010 18:08Ina SchieferdeckerStatusassigned => resolved
26-03-2010 18:09Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009257) +
+ Gyorgy Rethy    +
+ 23-03-2010 12:48    +
+ 		+ + + + +
+ As agreed in the STF, the "urgent" priority will be used for MTS fast-track CRs.
+
+
+
+ + + + + + + + + + +
+ (0009323) +
+ Ina Schieferdecker    +
+ 26-03-2010 18:08    +
+ 		+ + + + +
+ Dear Ina,
+
+this is fine for us.
+
+Thanx!
+Andrus
+
+----- Original Message -----
+From: "Schieferdecker, Ina" <ina.schieferdecker@fokus.fraunhofer.de>
+To: "Andrus Lehtmets (gmail)" <andrus.lehtmets@elvior.ee>
+Cc: "György Réthy" <gyorgy.rethy@ericsson.com>; "Jens Grabowski"
+<grabowski@informatik.uni-goettingen.de>; "Jacob Wieland_Internet"
+<wieland@testingtech.com>; "Stephan Schulz" <stephan.schulz@conformiq.com>;
+"Sampo Ahokas" <sampo.ahokas@openttcn.fi>; "Vesa-Matti Puro OpenTTCN"
+<vesa-matti.puro@openttcn.fi>; <andres.kull@elvior.ee>;
+<Laurent.Vreck@ETSI.ORG>
+Sent: Friday, March 26, 2010 12:23 PM
+Subject: RE: Concerning .Net mapping
+
+
+Dear Andrus,
+
+thank you very much!
+
+May I ask respectively that you crosscheck as well the TRI part:
+
+http://t-ort.etsi.org/view.php?id=5394 [^] ==> CR5394_v1.doc
+
+Best regards,
+
+Ina
+
+ + diff --git a/docs/mantis/CR5395.md b/docs/mantis/CR5395.md new file mode 100644 index 0000000000000000000000000000000000000000..f4a6dcdb62f04e8df874380a126506a1e0ac7b6e --- /dev/null +++ b/docs/mantis/CR5395.md @@ -0,0 +1,215 @@ + + + + + + + + + + + + + 0005395: .NET framework mapping for TCI - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005395Part 06: TTCN-3 Control InterfaceNew Featurepublic14-10-2009 13:1726-03-2010 18:10
ReporterAndrus Lehtmets 
Assigned ToIna Schieferdecker 
PriorityurgentSeveritymajorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.1.1 (published 2009-06) 
Target VersionFixed in Versionv4.2.1 (published 2010-07) 
Clause Reference(s)Part 6: TTCN-3 Control Interface (TCI)
Source (company - Author)Elvior
Summary0005395: .NET framework mapping for TCI
Description.NET framework mapping for TCI is missing in TTCN-3 specifications. We have prepared relevant specifications, see attachments.
+
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0005394closed Ina Schieferdecker Part 05: TTCN-3 Runtime Interface  .NET framework mapping for TRI 
Attached Filesdoc TCI_NET_mapping.doc (491,008) 14-10-2009 13:17
http://oldforge.etsi.org/mantis/file_download.php?file_id=2268&type=bug
doc TCI_NET_mapping_for_objid.doc (26,112) 14-10-2009 13:18
http://oldforge.etsi.org/mantis/file_download.php?file_id=2269&type=bug
doc TCI_NET_mapping_rev2.doc (496,128) 18-03-2010 07:49
http://oldforge.etsi.org/mantis/file_download.php?file_id=2342&type=bug
doc CR5395_v1.doc (210,944) 25-03-2010 15:30
http://oldforge.etsi.org/mantis/file_download.php?file_id=2374&type=bug
Issue History
Date ModifiedUsernameFieldChange
14-10-2009 13:17Andrus LehtmetsNew Issue
14-10-2009 13:17Andrus LehtmetsStatusnew => assigned
14-10-2009 13:17Andrus LehtmetsAssigned To => Ina Schieferdecker
14-10-2009 13:17Andrus LehtmetsFile Added: TCI_NET_mapping.doc
14-10-2009 13:17Andrus LehtmetsClause Reference(s) => Part 6: TTCN-3 Control Interface (TCI)
14-10-2009 13:17Andrus LehtmetsSource (company - Author) => Elvior
14-10-2009 13:18Andrus LehtmetsFile Added: TCI_NET_mapping_for_objid.doc
15-02-2010 05:06Ina SchieferdeckerTarget Version => Edition 5.1.1 (not yet published)
18-03-2010 07:49Andrus LehtmetsFile Added: TCI_NET_mapping_rev2.doc
18-03-2010 07:51Andrus LehtmetsNote Added: 0009240
23-03-2010 12:47Gyorgy RethyNote Added: 0009256
23-03-2010 12:47Gyorgy RethyPrioritynormal => urgent
23-03-2010 12:48Gyorgy RethyTarget VersionEdition 4.3.1 (not yet published) => Edition 4.2.2 (not yet published)
25-03-2010 11:38Ina SchieferdeckerRelationship addedrelated to 0005394
25-03-2010 15:28Ina SchieferdeckerNote Added: 0009314
25-03-2010 15:30Ina SchieferdeckerFile Added: CR5395_v1.doc
25-03-2010 15:30Ina SchieferdeckerResolutionopen => fixed
25-03-2010 15:30Ina SchieferdeckerFixed in Version => Edition 4.2.1 (not yet published)
26-03-2010 18:09Ina SchieferdeckerNote Added: 0009324
26-03-2010 18:10Ina SchieferdeckerStatusassigned => resolved
26-03-2010 18:10Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009240) +
+ Andrus Lehtmets    +
+ 18-03-2010 07:51    +
+ 		+ + + + +
+ TCI_NET_mapping_rev2.doc contains minor corrections, please use this when updating TTCN-3 spec.
+
+
+
+ + + + + + + + + + +
+ (0009256) +
+ Gyorgy Rethy    +
+ 23-03-2010 12:47    +
+ 		+ + + + +
+ As agreed in the STF, the "urgent" priority is used for MTS fast-track CRs.
+
+
+
+ + + + + + + + + + +
+ (0009314) +
+ Ina Schieferdecker    +
+ 25-03-2010 15:28    +
+ 		+ + + + +
+ there are some high-level issues related to the .Net mapping. You proposed a .Net mapping including C#, Visual Basic, C++ and CLI mapping
+
+--> TTCN-3 typically defines language mappings, not platform/framework mappings - we tend to include language mappings only
+
+--> Visual Basic is a proprietary, but not standardized language - it should therefore not be included into TTCN-3
+
+--> the C++ mapping is different to the existing C++ mapping - if you have issues to use that mapping in a .Net environment related to the existing C++ mapping, let us fix it directly there
+
+
+What remains are the C# and the CLI mapping ... both are very close to each other ... so that we tend to include one of them only. We tend to go for C# referencing ECMA-334, C# Language Specification, 4th edition (June 2006)
+
+
+Furthermore, you propose interfaces for e.g. object instantiation and for TRI initialization. We agree that such interfaces are needed, however, as of today they are not part of TRI.
+
+--> if to adopt such concepts, they need to be resolved generically for all languages. May we ask you to come up with a general solution so that it can consistently be included into TRI/TCI?
+
+
+In summary, we propose to implemented in v4.2.1 (hopefully we will manage) the C# mapping to TRI/TCI without object instantiation and without TRI/TCI initialization.
+
+
+==> see CR5395_v1.doc
+
+
+
+ + + + + + + + + + +
+ (0009324) +
+ Ina Schieferdecker    +
+ 26-03-2010 18:09    +
+ 		+ + + + +
+ Dear Ina,
+
+this text is fine for us.
+
+BR,
+Andrus
+
+----- Original Message -----
+From: "Schieferdecker, Ina" <ina.schieferdecker@fokus.fraunhofer.de>
+To: "Andrus Lehtmets (gmail)" <andrus.lehtmets@elvior.ee>
+Cc: "György Réthy" <gyorgy.rethy@ericsson.com>; "Jens Grabowski"
+<grabowski@informatik.uni-goettingen.de>; "Jacob Wieland_Internet"
+<wieland@testingtech.com>; "Stephan Schulz" <stephan.schulz@conformiq.com>;
+"Sampo Ahokas" <sampo.ahokas@openttcn.fi>; "Vesa-Matti Puro OpenTTCN"
+<vesa-matti.puro@openttcn.fi>; <stephan.schulz@conformiq.com>;
+<andres.kull@elvior.ee>; <Laurent.Vreck@ETSI.ORG>
+Sent: Thursday, March 25, 2010 5:31 PM
+Subject: RE: Concerning .Net mapping
+
+
+Dear all,
+
+the draft for TCI is uploaded at
+
+http://t-ort.etsi.org/view.php?id=5395 [^] ==> CR5395_v1.doc
+
+Please have a look.
+
+Cheers, Ina
+
+ + diff --git a/docs/mantis/CR5405.md b/docs/mantis/CR5405.md new file mode 100644 index 0000000000000000000000000000000000000000..f09f4acf19f9297f9aa50f7be5ec6652d3621892 --- /dev/null +++ b/docs/mantis/CR5405.md @@ -0,0 +1,63 @@ + + + + + + + + + + + + + 0005405: ElementFormQualified & AttributeFormQualified shall be allowed for types and fields as well - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005405Part 09: Using XML with TTCN-3Technicalpublic21-10-2009 15:2808-12-2009 14:51
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionwon't fix 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Clause Reference(s)B.3.5, B.3.9
For STF discussion
Source (company - Author)L.M.Ericsson
Summary0005405: ElementFormQualified & AttributeFormQualified shall be allowed for types and fields as well
DescriptionElementFormQualified instructs the XML codec to use prefixed tag names. It is added to generated TTCN-3 modules when the elementFormDefault or attributeFormDefault - respectively - is qualified. But it shall also allow mapping of the form attribute of XSD elements and XSD attributes as well, thus shall be allowed for TTCN-3 types and fields of structured types too.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
21-10-2009 15:28Gyorgy RethyNew Issue
21-10-2009 15:28Gyorgy RethyStatusnew => assigned
21-10-2009 15:28Gyorgy RethyAssigned To => Gyorgy Rethy
21-10-2009 15:28Gyorgy RethyClause Reference(s) => B.3.5, B.3.9
21-10-2009 15:28Gyorgy RethySource (company - Author) => L.M.Ericsson
07-12-2009 13:58Ina SchieferdeckerTarget Version => Edition 4.2.1 (not yet published)
08-12-2009 14:50Gyorgy RethyNote Added: 0009097
08-12-2009 14:51Gyorgy RethyStatusassigned => closed
08-12-2009 14:51Gyorgy RethyResolutionopen => won't fix
08-12-2009 14:51Gyorgy RethyTarget VersionEdition 4.2.1 (not yet published) =>
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009097) +
+ Gyorgy Rethy    +
+ 08-12-2009 14:50    +
+ 		+ + + + +
+ The form attribute can be used for this purpose.
+
+ + diff --git a/docs/mantis/CR5412.md b/docs/mantis/CR5412.md new file mode 100644 index 0000000000000000000000000000000000000000..6607a55bcb6ca0b14efc98924baeec72efdfb8dc --- /dev/null +++ b/docs/mantis/CR5412.md @@ -0,0 +1,83 @@ + + + + + + + + + + + + + 0005412: inconsistence in usage of types in TRI ANSI C value mapping - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005412Part 06: TTCN-3 Control InterfaceClarificationpublic28-10-2009 16:1518-03-2010 07:42
Reportertepelmann 
Assigned ToIna Schieferdecker 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.1.1 (published 2009-06) 
Target Versionv4.2.1 (published 2010-07)Fixed in Versionv4.2.1 (published 2010-07) 
Clause Reference(s)9.2
Source (company - Author)     
Summary0005412: inconsistence in usage of types in TRI ANSI C value mapping
DescriptionIn the ANSI C language mapping different issues regarding the usage of "long int" and "unsigned long int" could be observed.
+1. In most of the tciSet/tciGet...Value(Value inst, ... position, ...) functions the parameter position is of type "unsigned long int". However in some "long int" is used, in some there is even a mix where for the set operation "unsigned long int" and for the get operation "long int" is used. As position should not be less then 0, "unsigned long int" should be appropriate here.
+
+2. The same applies also for some tciGet/tciSet... functions.
+
+3. TString[] is used where in the abstract data type type definition TStringSeq is defined. Also the mapping differs slightly. TString[] is mapped to "char**" where TStringSeq is mapped to "String*".
Steps To Reproduce
Additional InformationExamples for 1. and 2.:
+void tciSetCStringCharValue (Value inst, long int position, char value)
+char tciGetCStringCharValue (Value inst, long int position)
+
+int tciGetBStringBitValue (Value inst, long int position)
+void tciSetBStringBitValue (Value inst, unsigned long int position, int value)
+
+unsigned long int tciGetBStringLength(Value inst)
+void tciSetBStringLength (Value inst, long int len)
+
+long int tciGetHStringLength(Value inst)
+void tciSetHStringLength (Value inst, unsigned long int len)
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
28-10-2009 16:15tepelmannNew Issue
28-10-2009 16:15tepelmannStatusnew => assigned
28-10-2009 16:15tepelmannAssigned To => Ina Schieferdecker
28-10-2009 16:15tepelmannClause Reference(s) => 9.2
28-10-2009 16:15tepelmannSource (company - Author) =>
07-12-2009 13:57Ina SchieferdeckerTarget Version => Edition 4.2.1 (not yet published)
15-02-2010 04:10Ina SchieferdeckerNote Added: 0009206
18-03-2010 07:41Ina SchieferdeckerStatusassigned => resolved
18-03-2010 07:41Ina SchieferdeckerResolutionopen => fixed
18-03-2010 07:41Ina SchieferdeckerFixed in Version => Edition 4.2.1 (not yet published)
18-03-2010 07:42Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009206) +
+ Ina Schieferdecker    +
+ 15-02-2010 04:10    +
+ 		+ + + + +
+ There are no triSet/triGet functions - that inconcistency applies to TCI only.
+
+Also, String only (mapped to char *) is used in TRI only.
+
+The CR has been moved to TCI.
+
+ + diff --git a/docs/mantis/CR5413.md b/docs/mantis/CR5413.md new file mode 100644 index 0000000000000000000000000000000000000000..73742018215fc754a0bc8007bf5fc17998c359ac --- /dev/null +++ b/docs/mantis/CR5413.md @@ -0,0 +1,90 @@ + + + + + + + + + + + + + 0005413: TciTypeClassType modified without setting explicit values - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005413Part 06: TTCN-3 Control InterfaceClarificationpublic28-10-2009 16:3816-02-2010 06:59
Reportertepelmann 
Assigned ToIna Schieferdecker 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.1.1 (published 2009-06) 
Target Versionv4.2.1 (published 2010-07)Fixed in Versionv4.2.1 (published 2010-07) 
Clause Reference(s)9.5
Source (company - Author)     
Summary0005413: TciTypeClassType modified without setting explicit values
DescriptionObjid was removed from this part of the standard. Consequently also the TciTypeClassType was modified - TCI_OBJID_TYPE was removed.
+However as no values were given to the enum entries all the entries following the former entry TCI_OBJID_TYPE will have a new value now.
+If this was not intended, explicit values - like they exist in the Java mapping - should be applied. This can also be done for the IDL definition.
Steps To Reproduce
Additional InformationTCI_OBJID_TYPE had the implicit enum value 11, the following TCI_OCTETSTRING_TYPE the value 12. Without explicit value and removing the TCI_OBJID_TYPE, TCI_OCTETSTRING_TYPE will have the value 11.
+
TagsNo tags attached.
Relationships
parent of 0005475closed Ina Schieferdecker Some TCI constants without explicit values 
Attached Fileszip es_20187306v040102.zip (1,311,400) 15-02-2010 04:57
http://oldforge.etsi.org/mantis/file_download.php?file_id=2337&type=bug
Issue History
Date ModifiedUsernameFieldChange
28-10-2009 16:38tepelmannNew Issue
28-10-2009 16:38tepelmannStatusnew => assigned
28-10-2009 16:38tepelmannAssigned To => Ina Schieferdecker
28-10-2009 16:38tepelmannClause Reference(s) => 9.5
28-10-2009 16:38tepelmannSource (company - Author) =>
07-12-2009 13:56Ina SchieferdeckerTarget Version => Edition 4.2.1 (not yet published)
15-02-2010 04:55Ina SchieferdeckerNote Added: 0009208
15-02-2010 04:57Ina SchieferdeckerFile Added: es_20187306v040102.zip
15-02-2010 05:00Ina SchieferdeckerIssue cloned: 0005475
15-02-2010 05:00Ina SchieferdeckerRelationship addedparent of 0005475
15-02-2010 05:01Ina SchieferdeckerStatusassigned => resolved
15-02-2010 05:01Ina SchieferdeckerResolutionopen => fixed
15-02-2010 05:01Ina SchieferdeckerFixed in Version => Edition 4.2.1 (not yet published)
16-02-2010 06:59Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009208) +
+ Ina Schieferdecker    +
+ 15-02-2010 04:55    +
+ 		+ + + + +
+ There is also a gap between Boolean and Charstring and between Union and UniversalCharstring ... explicit values assigned as follows:
+
+  TCI_ADDRESS_TYPE = 0,
+  TCI_ANYTYPE_TYPE = 1,
+  TCI_BITSTRING_TYPE = 2,
+  TCI_BOOLEAN_TYPE = 3,
+  TCI_CHARSTRING_TYPE = 5,
+  TCI_COMPONENT_TYPE = 6,
+  TCI_ENUMERATED_TYPE = 7,
+  TCI_FLOAT_TYPE = 8,
+  TCI_HEXSTRING_TYPE = 9,
+  TCI_INTEGER_TYPE = 10,
+  TCI_OCTETSTRING_TYPE = 12,
+  TCI_RECORD_TYPE = 13,
+  TCI_RECORD_OF_TYPE = 14,
+  TCI_ARRAY_TYPE = 15,
+  TCI_SET_TYPE = 16,
+  TCI_SET_OF_TYPE = 17,
+  TCI_UNION_TYPE = 18,
+  TCI_UNIVERSAL_CHARSTRING_TYPE = 20,
+  TCI_VERDICT_TYPE = 21
+
+There has been also an inconcistency for the ARRAY type, which has been resolved in the Java mapping in favour of the IDL definition.
+
+A clone CR created to discuss if to make the values for parameter passing mode, for component kind and for verdics also explicit in all mappings.
+
+ + diff --git a/docs/mantis/CR5414.md b/docs/mantis/CR5414.md new file mode 100644 index 0000000000000000000000000000000000000000..b9d7d3d44222763f66305f46030861b3d8c8ea5c --- /dev/null +++ b/docs/mantis/CR5414.md @@ -0,0 +1,74 @@ + + + + + + + + + + + + + 0005414: Mappings for TCI_OBJID_TYPE missing - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 07: Using ASN.1 with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005414Part 07: Using ASN.1 with TTCN-3Clarificationpublic28-10-2009 16:5102-02-2010 14:53
Reportertepelmann 
Assigned ToGyorgy Rethy 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.1.1 (published 2009-06) 
Target Versionv4.2.1 (published 2010-07)Fixed in Versionv4.2.1 (published 2010-07) 
Clause Reference(s)missing
Source (company - Author)     
Summary0005414: Mappings for TCI_OBJID_TYPE missing
DescriptionTCI_OBJID_TYPE was fully removed from the core standard, however the different mapping and type definitions were not introduced in this package!
+As the objid is still a valid type in this part all the mappings should have been transfered here.
+
+- no abstract data type ObjidValue definition
+- no TciTypeClass enum entry anymore, neither a new equivalent like a constant definition
+  In chapter 7.2.7.1 there is still this:
+  "The TciTypeClass defined in clause 7.2.2.1 (Abstract TTCN 3 data types) of ES 201 873 6 [12] is extended with the constant OBJID."
+- no extension to TCI-CD required, etc.
+- no TCI mapping(Java, C, etc.)
+- in chapter 7.2.7.2 there is still this:
+  "The type hierarchy given in figure 4 in clause 7.2.2.2 (Abstract TTCN 3 values) of ES 201 873 6 [12] is extended by the ObjidValue abstract type."
+- etc., etc.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
28-10-2009 16:51tepelmannNew Issue
28-10-2009 16:51tepelmannStatusnew => assigned
28-10-2009 16:51tepelmannAssigned To => Gyorgy Rethy
28-10-2009 16:51tepelmannClause Reference(s) => missing
28-10-2009 16:51tepelmannSource (company - Author) =>
07-12-2009 13:55Ina SchieferdeckerTarget Version => Edition 4.2.1 (not yet published)
02-02-2010 14:53Gyorgy RethyNote Added: 0009187
02-02-2010 14:53Gyorgy RethyStatusassigned => closed
02-02-2010 14:53Gyorgy RethyResolutionopen => fixed
02-02-2010 14:53Gyorgy RethyFixed in Version => Edition 4.2.1 (not yet published)
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009187) +
+ Gyorgy Rethy    +
+ 02-02-2010 14:53    +
+ 		+ + + + +
+ All objid related text is moved from TCI v3.4.1 to Part-7 clause 7.2.7.
+
+ + diff --git a/docs/mantis/CR5415.md b/docs/mantis/CR5415.md new file mode 100644 index 0000000000000000000000000000000000000000..34039cc4c2a774cd27868655873dd2ca7fdca3bf --- /dev/null +++ b/docs/mantis/CR5415.md @@ -0,0 +1,100 @@ + + + + + + + + + + + + + 0005415: getNumberOfBits/setNumberOfBits missing in for TriAddressType, TriParameterType and TriExceptionType - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 05: TTCN-3 Runtime Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005415Part 05: TTCN-3 Runtime Interface Clarificationpublic28-10-2009 17:2225-03-2010 09:47
Reportertepelmann 
Assigned ToIna Schieferdecker 
PriorityhighSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.1.1 (published 2009-06) 
Target Versionv4.3.1 (published 2011-06)Fixed in Versionv4.2.1 (published 2010-07) 
Clause Reference(s)6.3.2
Source (company - Author)     
Summary0005415: getNumberOfBits/setNumberOfBits missing in for TriAddressType, TriParameterType and TriExceptionType
DescriptionFor TriMessageType the methods getNumberOfBits and setNumberOfBits were introduced. This should also apply for the TriAddressType, TriParameterType and TriExceptionType for the same reasons.
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
has duplicate 0005481closed Ina Schieferdecker Part 06: TTCN-3 Control Interface TriAddressType should have an additional attribute 'numberOfBits' 
has duplicate 0005480closed Ina Schieferdecker Part 06: TTCN-3 Control Interface TriMessageType is lacking attribute 'numberOfBits' 
Attached Filesdoc CR5415_v1.doc (79,360) 25-03-2010 09:13
http://oldforge.etsi.org/mantis/file_download.php?file_id=2357&type=bug
Issue History
Date ModifiedUsernameFieldChange
28-10-2009 17:22tepelmannNew Issue
28-10-2009 17:22tepelmannStatusnew => assigned
28-10-2009 17:22tepelmannAssigned To => Ina Schieferdecker
28-10-2009 17:22tepelmannClause Reference(s) => 6.3.2
28-10-2009 17:22tepelmannSource (company - Author) =>
15-02-2010 05:11Ina SchieferdeckerNote Added: 0009209
15-02-2010 05:12Ina SchieferdeckerTarget Version => Edition 5.1.1 (not yet published)
22-03-2010 15:36Gyorgy RethyRelationship addedhas duplicate 0005481
22-03-2010 15:36Gyorgy RethyRelationship addedhas duplicate 0005480
23-03-2010 12:46Gyorgy RethyPrioritynormal => high
25-03-2010 09:13Ina SchieferdeckerFile Added: CR5415_v1.doc
25-03-2010 09:14Ina SchieferdeckerNote Added: 0009295
25-03-2010 09:15Ina SchieferdeckerAssigned ToIna Schieferdecker => Jacob Wieland - Spirent
25-03-2010 09:15Ina SchieferdeckerResolutionopen => fixed
25-03-2010 09:15Ina SchieferdeckerFixed in Version => Edition 4.2.1 (not yet published)
25-03-2010 09:31Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Ina Schieferdecker
25-03-2010 09:47Ina SchieferdeckerStatusassigned => resolved
25-03-2010 09:47Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009209) +
+ Ina Schieferdecker    +
+ 15-02-2010 05:11    +
+ 		+ + + + +
+ There is an inconsistency between the Java and C++ mapping wrt. setNumberOfBits/getNumberOfBits (no such methods in C++), which should be resolved when adding additional setNumberOfBits/getNumberOfBits methods to the mapping. Hence moved to 2010.
+
+
+
+ + + + + + + + + + +
+ (0009295) +
+ Ina Schieferdecker    +
+ 25-03-2010 09:14    +
+ 		+ + + + +
+ See CR5415_v1.doc
+
+Assigned to Jacob for proofreading
+
+ + diff --git a/docs/mantis/CR5417.md b/docs/mantis/CR5417.md new file mode 100644 index 0000000000000000000000000000000000000000..ec38919b64184f5b6f90d3362633b71f8d5c9970 --- /dev/null +++ b/docs/mantis/CR5417.md @@ -0,0 +1,688 @@ + + + + + + + + + + + + + 0005417: Support of parametrized map/unmap operation for full dynamic mapping - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005417Part 01: TTCN-3 Core LanguageNew Featurepublic29-10-2009 15:3216-12-2011 05:42
Reportertepelmann 
Assigned ToIna Schieferdecker 
PriorityhighSeveritymajorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.3.1 (published 2011-06) 
Target Versionv4.4.1 (published 2012-04)Fixed in Versionv4.4.1 (published 2012-04) 
Clause Reference(s)missing
Source (company - Author)     
Summary0005417: Support of parametrized map/unmap operation for full dynamic mapping
DescriptionIn many situations in the testing world configuration parameters for connections are needed in the real world.
+In TTCN-3 the establishment of a connection is announced by using the map operation. This allows dynamic mapping inside the behaviour of a test and should be an advantage in comparison with TTCN-2.
+Currently this can be used in all cases where no additional configuration parameters are needed for establishing a connection(in the adaptation). In some cases static configuration parameters like property files are efficient enough, however for fully dynamic configuration and establishing of connections an extension to the existing map operation is needed.
+We propose to extend the existing map operation with an optional parameter containing a configuration value. Attached you will find the modified recommendation including proposals for the map statement and additionally for the port type declaration.
+The benefit of the proposal would be the full support of dynamic configuration!
+
+We include the modified recommendations for reference(including change bars).
Steps To Reproduce
Additional InformationA short example of our proposal:
+var MyConfigType MyConfig := { option := 1, lock := false};
+     :
+map(mtc:Port4, system:PCO2) param MyConfig);
+
+type port PortTypeIdentifier message "{"
+        { ( in | out | inout ) { MessageType [ "," ] }+ ";" }
+        [ map param "(" FormalPar {"," FormalPar} ")"]
+        [ unmap param "(" FormalPar {"," FormalPar} ")"]
+"}"
TagsNo tags attached.
Relationships
related to 0005224closed Jens Grabowski Ext Pack: Config & Deployment Support (ES 202 781) Introducing dual faced ports 
parent of 0005985closed Ina Schieferdecker Part 05: TTCN-3 Runtime Interface  Support of parametrized map/unmap operation for full dynamic mapping 
related to 0002105closed Ina Schieferdecker Part 01: TTCN-3 Core Language address should also be bind to port type 
related to 0005923closed Ina Schieferdecker Part 01: TTCN-3 Core Language BNF (rules 50 and 58) in appendix A and port type definition chapter 6.2.9 do not match 
Attached Fileszip es_20187305v040101p_cr_MapParam.zip (282,352) 29-10-2009 15:33
http://oldforge.etsi.org/mantis/file_download.php?file_id=2272&type=bug
zip es_20187306v040101p_crMapParam.zip (1,281,016) 29-10-2009 15:33
http://oldforge.etsi.org/mantis/file_download.php?file_id=2273&type=bug
zip es_20187301v040101p_crMapParam_v2.zip (900,534) 25-03-2010 14:52
http://oldforge.etsi.org/mantis/file_download.php?file_id=2372&type=bug
zip es_20187305v040101p_cr_MapParam_v2.zip (283,102) 25-03-2010 14:52
http://oldforge.etsi.org/mantis/file_download.php?file_id=2373&type=bug
zip CR5417-part1.zip (705,676) 03-09-2010 12:08
http://oldforge.etsi.org/mantis/file_download.php?file_id=2441&type=bug
zip es_20187301v040101p_crMapParam.zip (700,520) 25-05-2011 06:57
http://oldforge.etsi.org/mantis/file_download.php?file_id=2477&type=bug
? core.bnf (55,513) 26-05-2011 12:51
http://oldforge.etsi.org/mantis/file_download.php?file_id=2502&type=bug
zip es_20187305v040101p_cr_MapParam_v3.zip (252,255) 30-11-2011 12:48
http://oldforge.etsi.org/mantis/file_download.php?file_id=2619&type=bug
zip es_20187306v040101p_crMapParam_v2.zip (1,137,061) 30-11-2011 16:15
http://oldforge.etsi.org/mantis/file_download.php?file_id=2622&type=bug
zip es_20187306v040101p_crMapParam_v3.zip (1,131,555) 01-12-2011 09:26
http://oldforge.etsi.org/mantis/file_download.php?file_id=2632&type=bug
zip es_20187306v040101p_crMapParam_v4.zip (1,139,492) 01-12-2011 10:26
http://oldforge.etsi.org/mantis/file_download.php?file_id=2636&type=bug
zip es_20187305v040101p_cr_MapParam_v4.zip (252,774) 01-12-2011 10:26
http://oldforge.etsi.org/mantis/file_download.php?file_id=2637&type=bug
Issue History
Date ModifiedUsernameFieldChange
29-10-2009 15:32tepelmannNew Issue
29-10-2009 15:32tepelmannStatusnew => assigned
29-10-2009 15:32tepelmannAssigned To => Ina Schieferdecker
29-10-2009 15:32tepelmannFile Added: es_20187301v040101p_crMapParam.zip
29-10-2009 15:32tepelmannClause Reference(s) => missing
29-10-2009 15:32tepelmannSource (company - Author) =>
29-10-2009 15:33tepelmannFile Added: es_20187305v040101p_cr_MapParam.zip
29-10-2009 15:33tepelmannFile Added: es_20187306v040101p_crMapParam.zip
04-01-2010 13:52Ina SchieferdeckerRelationship addedrelated to 0005224
04-01-2010 13:53Ina SchieferdeckerNote Added: 0009157
04-01-2010 13:53Ina SchieferdeckerTarget Version => Edition 5.1.1 (not yet published)
22-03-2010 17:29Gyorgy RethyAssigned ToIna Schieferdecker =>
22-03-2010 17:29Gyorgy RethyStatusassigned => new
23-03-2010 12:45Gyorgy RethyAssigned To => Jacob Wieland - Spirent
23-03-2010 12:45Gyorgy RethyPrioritynormal => low
23-03-2010 12:45Gyorgy RethyStatusnew => assigned
23-03-2010 12:45Gyorgy RethySummarysupport of parametrized map/uinmap operation for full dynamic mapping => Support of parametrized map/unmap operation for full dynamic mapping
24-03-2010 08:56Jacob Wieland - SpirentRelationship addedrelated to 0002105
25-03-2010 14:52Jacob Wieland - SpirentFile Added: es_20187301v040101p_crMapParam_v2.zip
25-03-2010 14:52Jacob Wieland - SpirentFile Added: es_20187305v040101p_cr_MapParam_v2.zip
25-03-2010 14:53Jacob Wieland - SpirentNote Added: 0009310
25-03-2010 15:00Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
01-07-2010 09:43Gyorgy RethyNote Added: 0009441
01-07-2010 09:44Gyorgy RethyNote Edited: 0009441
01-07-2010 09:48Gyorgy RethyNote Edited: 0009441
02-09-2010 10:13Gyorgy RethyNote Added: 0009692
02-09-2010 10:13Gyorgy RethyAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
02-09-2010 11:27Jacob Wieland - SpirentNote Added: 0009697
03-09-2010 12:08Jacob Wieland - SpirentFile Added: CR5417-part1.zip
03-09-2010 12:08Jacob Wieland - SpirentNote Added: 0009709
03-09-2010 12:08Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Ina Schieferdecker
03-09-2010 12:11Jacob Wieland - SpirentStatusassigned => resolved
03-09-2010 12:11Jacob Wieland - SpirentFixed in Version => Edition 4.3.1 (not yet published)
03-09-2010 12:11Jacob Wieland - SpirentResolutionopen => fixed
14-12-2010 14:48Ina SchieferdeckerNote Added: 0009966
14-12-2010 14:49Ina SchieferdeckerNote Added: 0009967
14-12-2010 14:50Ina SchieferdeckerFile Added: core.bnf
14-12-2010 14:51Ina SchieferdeckerStatusresolved => closed
23-05-2011 08:46Ina SchieferdeckerStatusclosed => feedback
23-05-2011 08:46Ina SchieferdeckerResolutionfixed => reopened
23-05-2011 08:46Ina SchieferdeckerNote Added: 0010003
24-05-2011 17:09Gyorgy RethyNote Added: 0010036
24-05-2011 17:10Gyorgy RethyNote Edited: 0010036
24-05-2011 17:12Gyorgy RethyNote Edited: 0010036
24-05-2011 17:12Gyorgy RethyStatusfeedback => assigned
24-05-2011 19:33Gyorgy RethyPrioritylow => high
25-05-2011 06:33Jacob Wieland - SpirentFile Deleted: es_20187301v040101p_crMapParam.zip
25-05-2011 06:57Jacob Wieland - SpirentFile Added: es_20187301v040101p_crMapParam.zip
25-05-2011 07:36Jacob Wieland - SpirentFile Deleted: core.bnf
25-05-2011 07:36Jacob Wieland - SpirentFile Added: core.bnf
25-05-2011 07:41Jacob Wieland - SpirentNote Added: 0010042
26-05-2011 12:50Jacob Wieland - SpirentFile Deleted: core.bnf
26-05-2011 12:51Jacob Wieland - SpirentFile Added: core.bnf
26-05-2011 12:52Jacob Wieland - SpirentNote Added: 0010084
07-07-2011 12:40Jacob Wieland - SpirentNote Added: 0010213
07-07-2011 12:40Jacob Wieland - SpirentProduct VersionEdition 4.1.1 Published 2009-06-02 => Edition 4.3.1
27-09-2011 14:06Gyorgy RethyFixed in VersionEdition 4.3.1 =>
27-09-2011 14:06Gyorgy RethyTarget VersionEdition 4.3.1 => Edition 4.4.1
29-09-2011 09:45Ina SchieferdeckerRelationship addedrelated to 0005923
30-11-2011 12:47Ina SchieferdeckerNote Added: 0010441
30-11-2011 12:48Ina SchieferdeckerFile Added: es_20187305v040101p_cr_MapParam_v3.zip
30-11-2011 16:08Ina SchieferdeckerNote Added: 0010449
30-11-2011 16:15Ina SchieferdeckerFile Added: es_20187306v040101p_crMapParam_v2.zip
30-11-2011 16:17Ina SchieferdeckerAssigned ToIna Schieferdecker => Jacob Wieland - Spirent
01-12-2011 09:26Jacob Wieland - SpirentFile Added: es_20187306v040101p_crMapParam_v3.zip
01-12-2011 09:28Jacob Wieland - SpirentNote Added: 0010456
01-12-2011 09:28Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Ina Schieferdecker
01-12-2011 10:18Ina SchieferdeckerNote Added: 0010460
01-12-2011 10:26Ina SchieferdeckerFile Added: es_20187306v040101p_crMapParam_v4.zip
01-12-2011 10:26Ina SchieferdeckerFile Added: es_20187305v040101p_cr_MapParam_v4.zip
01-12-2011 11:08Ina SchieferdeckerNote Added: 0010466
01-12-2011 11:08Ina SchieferdeckerStatusassigned => resolved
01-12-2011 11:08Ina SchieferdeckerResolutionreopened => fixed
01-12-2011 11:08Ina SchieferdeckerFixed in Version => Edition 4.4.1
01-12-2011 11:09Ina SchieferdeckerStatusresolved => closed
16-12-2011 05:42Ina SchieferdeckerIssue cloned: 0005985
16-12-2011 05:42Ina SchieferdeckerRelationship addedparent of 0005985
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009157) +
+ Ina Schieferdecker    +
+ 04-01-2010 13:53    +
+ 		+ + + + +
+ Needs to be discussed in relation to 5224, hence postponed to 2010.
+
+
+
+ + + + + + + + + + +
+ (0009310) +
+ Jacob Wieland - Spirent    +
+ 25-03-2010 14:53    +
+ 		+ + + + +
+ uploaded corrected versions of part 1 and 3. No corrections for part 4 were necessary. Ready for integration into the standard, if approved.
+
+
+
+ + + + + + + + + + +
+ (0009441) +
+ Gyorgy Rethy    +
+ 01-07-2010 09:43    +
(edited on: 01-07-2010 09:48)
+ 		+ + + + +
+ It is OK up to know, some addition is needed: we specify all "parameterizable" objects and forms of parameterization in clause 5.4, this should also be included there.
+
+I haven't seen the statement the map and unmap operations shall have in value parameters only.
+
+CR5224 on dual-faced ports are set as a related CR but there is only a loose connection between them. CR5224 is about handling situations like this:
+1) User tests something above TCP transport and obviously using a TCP adapter. His/her test cases and test data are using the ASPs of the TCP adapter. Then the SUT changes and he/she has to execute the same test cases using e.g. SCTP transport. The SCTP adapter has different ASPs defined than the TCP adapter. In this case the mapping between the two sets of ASPs could be done in a dual-faced port, instead of re-writing the already verified and running test cases.
+2) Protocol A carries encoded messages of protocol B, for example a web application carried by SOAP carried by HTTP over TCP. The user is testing the application but from the point of view of the test system, HTTP (or SOAP in case of an HTTP adapter) is the "upper layer protocol", CD will encode/decode only HTTP (or SOAP) messages but not the Application messages. This means that from the point of view of the user no matching is possible by a receive statement (as he/she wants to match the Application messages, which are embedded in an encoded form in the received SOAP or HTTP messages). Dual-faced ports it can handle the whole encoding/decoding chain, i.e. mapping Application ASPs to SOAP/HTTP ASPs and calling external functions for message encoding/decoding, thus the user would be able to send/receive the Application messages directly in his/her test case code.
+
+These are real-life examples, coming from everyday practice. The problem is so real that Titan has implemented a vendor-specific solution for the problem.
+
+
+
+
+
+ + + + + + + + + + +
+ (0009692) +
+ Gyorgy Rethy    +
+ 02-09-2010 10:13    +
+ 		+ + + + +
+ Could you look at this pls.
+
+
+
+ + + + + + + + + + +
+ (0009697) +
+ Jacob Wieland - Spirent    +
+ 02-09-2010 11:27    +
+ 		+ + + + +
+ both in and out value parameters are allowed by the proposal. The restriction to value parameter unfortunately can only be seen in the BNF and syntactic description, so maybe this should still be added as a restriction.
+
+The relation to CR5224, though loose, is still there and thus needs to be considered (there), as for port composition, of course, the map/unmap parameters also need to be translated.
+
+
+
+ + + + + + + + + + +
+ (0009709) +
+ Jacob Wieland - Spirent    +
+ 03-09-2010 12:08    +
+ 		+ + + + +
+ added missing sentence
+
+
+
+ + + + + + + + + + +
+ (0009966) +
+ Ina Schieferdecker    +
+ 14-12-2010 14:48    +
+ 		+ + + + +
+ Implemented basically as proposed (just added the syntactic structure for unmap in 21.1.2)
+
+
+
+ + + + + + + + + + +
+ (0009967) +
+ Ina Schieferdecker    +
+ 14-12-2010 14:49    +
+ 		+ + + + +
+ extended the bnf - see uploaded bnf file
+
+
+
+ + + + + + + + + + +
+ (0010003) +
+ Ina Schieferdecker    +
+ 23-05-2011 08:46    +
+ 		+ + + + +
+ The handling of map/unmap parameters in TRI is not yet added. An agreement is needed how to do it.
+
+
+
+ + + + + + + + + + +
+ (0010036) +
+ Gyorgy Rethy    +
+ 24-05-2011 17:09    +
(edited on: 24-05-2011 17:12)
+ 		+ + + + +
+ in Part-1: change the BNF that address, map param, unmap param, in/out message lists could be in any order. Part-5 and part-6 portions to be completed.
+
+
+
+
+
+ + + + + + + + + + +
+ (0010042) +
+ Jacob Wieland - Spirent    +
+ 25-05-2011 07:41    +
+ 		+ + + + +
+ changed es_20187301v040101p_crMapParam.zip and core.bnf to allow Port Attributes in any order.
+
+added 3 new rules in core.bnf at the end (because of numbering), please use the tool to shift them to the right position (if possible)
+
+I designed the rules in a way that also easily allows adding additional port attributes to be added (i.e. the address type from CR2105)
+
+
+
+ + + + + + + + + + +
+ (0010084) +
+ Jacob Wieland - Spirent    +
+ 26-05-2011 12:52    +
+ 		+ + + + +
+ uploaded grammar with the right order/numbering
+
+
+
+ + + + + + + + + + +
+ (0010213) +
+ Jacob Wieland - Spirent    +
+ 07-07-2011 12:40    +
+ 		+ + + + +
+ I've changed the Product Version to 4.3.1 as 4.1.1 was obviously wrong (at least it cannot be found in 4.1.1 or 4.2.1, but can be found in 4.3.1.)
+
+I think we should include the still necessary changes also in 4.4.1 (or whatever the next interim version is called) as up till now this is inconsistent grammar-wise in the 4.3.1 version.
+
+
+
+ + + + + + + + + + +
+ (0010441) +
+ Ina Schieferdecker    +
+ 30-11-2011 12:47    +
+ 		+ + + + +
+ TRI extension implemented with small editorial changes.
+
+
+
+ + + + + + + + + + +
+ (0010449) +
+ Ina Schieferdecker    +
+ 30-11-2011 16:08    +
+ 		+ + + + +
+ TCI extension updated:
+
+- TCI operations take tciParameter
+- Logging operations log also potential encoder failures
+- parameter names unified: parameterList for tciParameterList and tciPars/triPars for logging operations
+
+Please check es_20187306v040101p_crMapParam_v2
+
+
+
+ + + + + + + + + + +
+ (0010456) +
+ Jacob Wieland - Spirent    +
+ 01-12-2011 09:28    +
+ 		+ + + + +
+ changed some references to TciParameterList to TciParameterListType according to the surrounding mapping.
+
+
+
+ + + + + + + + + + +
+ (0010460) +
+ Ina Schieferdecker    +
+ 01-12-2011 10:18    +
+ 		+ + + + +
+ STF decided to name the operations
+
+triMapParam and triUnmapParam in TRI
+
+and
+
+tciMapParamReq, tciMapParam, tciUnmapParamReq, tciUnmapParam in TCI
+
+
+
+ + + + + + + + + + +
+ (0010466) +
+ Ina Schieferdecker    +
+ 01-12-2011 11:08    +
+ 		+ + + + +
+ TRI updated and TCI extended accordingly
+
+ + diff --git a/docs/mantis/CR5436.md b/docs/mantis/CR5436.md new file mode 100644 index 0000000000000000000000000000000000000000..3b75e2e6c6d2957680ef1d96200937b054ff41ae --- /dev/null +++ b/docs/mantis/CR5436.md @@ -0,0 +1,115 @@ + + + + + + + + + + + + + 0005436: Clause 6.1.5 is difficult to understand - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005436Part 09: Using XML with TTCN-3Editorialpublic09-11-2009 10:5701-02-2010 11:47
ReporterGyorgy Rethy 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.2.1 (published 2010-07)Fixed in Versionv4.2.1 (published 2010-07) 
Clause Reference(s)6.1.5
For STF discussion
Source (company - Author)L.M.Ericsson
Summary0005436: Clause 6.1.5 is difficult to understand
DescriptionCurrent wording is correct, but difficult to understand. Re-word the text to be in-line with wording usede in the rest of the document and to increase readibility.
+
+Also, add a negative integer value to example 2 in clause 6.1.5, to increase clarity of the transformation rules:
+    <xsd:simpleType name="integer-0-5-10">
+        <xsd:restriction base="xsd:integer">
+            <xsd:enumeration value="0"/>
+            <xsd:enumeration value="5"/>
+            <xsd:enumeration value="-5"/>
+            <xsd:enumeration value="10"/>
+        </xsd:restriction>
+    </xsd:simpleType
+
+    //Is mapped to the TTCN-3 type definition:
+    type enumerated Integer_0_5_10 {int_5(-5), int0(0), int5(5), int10(10)}
+    with {
+        variant "name as uncapitalized";
+        variant "useNumber"
+    }
+ 
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR5436_resolution_v1.doc (93,696) 09-12-2009 11:11
http://oldforge.etsi.org/mantis/file_download.php?file_id=2305&type=bug
Issue History
Date ModifiedUsernameFieldChange
09-11-2009 10:57Gyorgy RethyNew Issue
09-11-2009 10:57Gyorgy RethyStatusnew => assigned
09-11-2009 10:57Gyorgy RethyAssigned To => Gyorgy Rethy
09-11-2009 10:57Gyorgy RethyClause Reference(s) => 6.1.5
09-11-2009 10:57Gyorgy RethySource (company - Author) => L.M.Ericsson
07-12-2009 13:50Ina SchieferdeckerTarget Version => Edition 4.2.1 (not yet published)
09-12-2009 11:11Gyorgy RethyFile Added: CR5436_resolution_v1.doc
09-12-2009 11:11Gyorgy RethyNote Added: 0009113
09-12-2009 11:12Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
01-02-2010 11:47Gyorgy RethyNote Added: 0009177
01-02-2010 11:47Gyorgy RethyStatusassigned => closed
01-02-2010 11:47Gyorgy RethyResolutionopen => fixed
01-02-2010 11:47Gyorgy RethyFixed in Version => Edition 4.2.1 (not yet published)
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009113) +
+ Gyorgy Rethy    +
+ 09-12-2009 11:11    +
+ 		+ + + + +
+ CR5436_resolution_v1.doc: ready to review
+
+
+
+ + + + + + + + + + +
+ (0009177) +
+ Gyorgy Rethy    +
+ 01-02-2010 11:47    +
+ 		+ + + + +
+ Implemented as in CR5436_resolution_v1.doc
+
+ + diff --git a/docs/mantis/CR5438.md b/docs/mantis/CR5438.md new file mode 100644 index 0000000000000000000000000000000000000000..225c7fd9162755e769cebfc5056567767bc32d3b --- /dev/null +++ b/docs/mantis/CR5438.md @@ -0,0 +1,166 @@ + + + + + + + + + + + + + 0005438: Error in display attribute example - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005438Part 01: TTCN-3 Core LanguageClarificationpublic11-11-2009 14:4904-01-2010 12:13
ReporterGyorgy Rethy 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.1.1 (published 2009-06) 
Target Versionv4.2.1 (published 2010-07)Fixed in Versionv4.2.1 (published 2010-07) 
Clause Reference(s)27.1.1
Source (company - Author)L.M.ericsson
Summary0005438: Error in display attribute example
DescriptionEXAMPLE 2:
+...
+    type record of integer MyRecOfInteger2
+    with { display ([0]) "colour red"
+    // the first element is displayed red
+
+record_of *types* do not have elements, they are rather construction mechanisms; only values and templates can have elements. It is proposed to change to (pls. note, the last closing "}" is missing in the original example):
+
+    const MyRecOfInteger c_MyRecordOfInt := { 0, 1, 2, 3 }
+    with { display ([0]) "colour red" }
+    // the first element is displayed red
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
11-11-2009 14:49Gyorgy RethyNew Issue
11-11-2009 14:49Gyorgy RethyStatusnew => assigned
11-11-2009 14:49Gyorgy RethyAssigned To => Ina Schieferdecker
11-11-2009 14:49Gyorgy RethyClause Reference(s) => 27.1.1
11-11-2009 14:49Gyorgy RethySource (company - Author) => L.M.ericsson
07-12-2009 13:49Ina SchieferdeckerTarget Version => Edition 4.2.1 (not yet published)
08-12-2009 18:37Ina SchieferdeckerNote Added: 0009109
08-12-2009 18:38Ina SchieferdeckerNote Edited: 0009109
08-12-2009 18:38Ina SchieferdeckerAssigned ToIna Schieferdecker => Gyorgy Rethy
08-12-2009 18:38Ina SchieferdeckerResolutionopen => fixed
08-12-2009 18:38Ina SchieferdeckerFixed in Version => Edition 4.2.1 (not yet published)
10-12-2009 13:02Gyorgy RethyNote Added: 0009144
10-12-2009 13:02Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
04-01-2010 12:13Ina SchieferdeckerNote Added: 0009152
04-01-2010 12:13Ina SchieferdeckerStatusassigned => resolved
04-01-2010 12:13Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009109) +
+ Ina Schieferdecker    +
+ 08-12-2009 18:37    +
(edited on: 08-12-2009 18:38)
+ 		+ + + + +
+ The missing "}" should be added.
+
+It should however be ok to apply the display attribute to the first element of any value of that MyRecOfInteger2 type. Please check
+
+
+
+
+
+ + + + + + + + + + +
+ (0009144) +
+ Gyorgy Rethy    +
+ 10-12-2009 13:02    +
+ 		+ + + + +
+ Yes, of course. It should be either
+
+ type record of integer MyRecOfInteger2
+    with { display ([-]) "colour red"
+    // integer elements are displayed red
+
+or
+
+    const MyRecOfInteger c_MyRecordOfInt := { 0, 1, 2, 3 }
+    with { display ([0]) "colour red" }
+    // the first element is displayed red
+
+OR both examples
+
+
+
+ + + + + + + + + + +
+ (0009152) +
+ Ina Schieferdecker    +
+ 04-01-2010 12:13    +
+ 		+ + + + +
+ Added as
+
+    type record of integer MyRecOfInteger2
+    with { display ([-]) "colour red" }
+    // integer elements are displayed red
+
+    const MyRecOfInteger c_MyRecordOfInt := {0, 1, 2, 3}
+    with { display ([0]) "colour redblue" }
+    // the first element is displayed redblue, the other elements are displayed red
+
+ + diff --git a/docs/mantis/CR5440.md b/docs/mantis/CR5440.md new file mode 100644 index 0000000000000000000000000000000000000000..e7c9946628eac921f1e8909b157becfe0659795f --- /dev/null +++ b/docs/mantis/CR5440.md @@ -0,0 +1,99 @@ + + + + + + + + + + + + + 0005440: whiteSpace attribute shall allow sending any whitespaces - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005440Part 09: Using XML with TTCN-3Technicalpublic17-11-2009 09:3801-02-2010 13:57
ReporterGyorgy Rethy 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.1.1 (published 2009-06) 
Target Versionv4.2.1 (published 2010-07)Fixed in Versionv4.2.1 (published 2010-07) 
Clause Reference(s)B.3.20
For STF discussion
Source (company - Author)L.M.Ericsson
Summary0005440: whiteSpace attribute shall allow sending any whitespaces
DescriptionCurrently part-9 requires that if the whiteSpace atribute applied, the encoder normalizes the content before sending. This restricts the test tool's capabilities. The whiteSpace attribute shall have no effect at sending, thus allowing the tester sending XML content with different whitespaces to the SUT.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR5440_resolution_v1.doc (67,584) 08-12-2009 17:06
http://oldforge.etsi.org/mantis/file_download.php?file_id=2296&type=bug
Issue History
Date ModifiedUsernameFieldChange
17-11-2009 09:38Gyorgy RethyNew Issue
17-11-2009 09:38Gyorgy RethyStatusnew => assigned
17-11-2009 09:38Gyorgy RethyAssigned To => Gyorgy Rethy
17-11-2009 09:38Gyorgy RethyClause Reference(s) => B.3.20
17-11-2009 09:38Gyorgy RethySource (company - Author) => L.M.Ericsson
07-12-2009 13:49Ina SchieferdeckerTarget Version => Edition 4.2.1 (not yet published)
08-12-2009 17:05Gyorgy RethyNote Added: 0009102
08-12-2009 17:06Gyorgy RethyNote Edited: 0009102
08-12-2009 17:06Gyorgy RethyFile Added: CR5440_resolution_v1.doc
08-12-2009 17:07Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
01-02-2010 13:57Gyorgy RethyNote Added: 0009179
01-02-2010 13:57Gyorgy RethyStatusassigned => closed
01-02-2010 13:57Gyorgy RethyResolutionopen => fixed
01-02-2010 13:57Gyorgy RethyFixed in Version => Edition 4.2.1 (not yet published)
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009102) +
+ Gyorgy Rethy    +
+ 08-12-2009 17:05    +
(edited on: 08-12-2009 17:06)
+ 		+ + + + +
+ CR5440_resolution_v1.doc: ready for review. Note, tat XML 1.1 requires normalization of attribute values in the receiving processor only.
+
+
+
+
+
+ + + + + + + + + + +
+ (0009179) +
+ Gyorgy Rethy    +
+ 01-02-2010 13:57    +
+ 		+ + + + +
+ Implemented acc. to CR5440_resolution_v1.doc
+
+ + diff --git a/docs/mantis/CR5443.md b/docs/mantis/CR5443.md new file mode 100644 index 0000000000000000000000000000000000000000..a2b952ec83f851fbf0e10c2c52e63b65d0b19584 --- /dev/null +++ b/docs/mantis/CR5443.md @@ -0,0 +1,105 @@ + + + + + + + + + + + + + 0005443: Missing friend module shall not cause an error - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005443Part 01: TTCN-3 Core LanguageTechnicalpublic17-11-2009 10:0616-02-2010 07:07
ReporterGyorgy Rethy 
Assigned ToIna Schieferdecker 
PriorityhighSeveritymajorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.1.1 (published 2009-06) 
Target Versionv4.2.1 (published 2010-07)Fixed in Versionv4.2.1 (published 2010-07) 
Clause Reference(s)8.2.4
Source (company - Author)L.M.Ericsson
Summary0005443: Missing friend module shall not cause an error
DescriptionCurrently the general semantic rules apply to friend module lists, i.e. TTCN-3 tools should cause an error if a friend module is not available in the test suite. However, friend module list is different from e.g. import, as it is more like a forward reference. For example, to test the "inner" functions of a library, the friend module lists of library modules shall also contain the names of the library-testing modules, but these are not part of the released version of the library, i.e. not available at the users.
+
+It is requested that the standard specify explicitly, that module names in friend module lists *may* be checked by tools but missing modules shall not cause an error.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
17-11-2009 10:06Gyorgy RethyNew Issue
17-11-2009 10:06Gyorgy RethyStatusnew => assigned
17-11-2009 10:06Gyorgy RethyAssigned To => Ina Schieferdecker
17-11-2009 10:06Gyorgy RethyClause Reference(s) => 8.2.4
17-11-2009 10:06Gyorgy RethySource (company - Author) => L.M.Ericsson
07-12-2009 13:49Ina SchieferdeckerTarget Version => Edition 4.2.1 (not yet published)
08-12-2009 18:46Ina SchieferdeckerNote Added: 0009110
08-12-2009 18:47Ina SchieferdeckerAssigned ToIna Schieferdecker => Gyorgy Rethy
08-12-2009 18:47Ina SchieferdeckerResolutionopen => fixed
09-12-2009 15:55Gyorgy RethyStatusassigned => resolved
09-12-2009 15:55Gyorgy RethyNote Added: 0009126
09-12-2009 15:56Gyorgy RethyStatusresolved => feedback
09-12-2009 15:56Gyorgy RethyResolutionfixed => reopened
09-12-2009 15:56Gyorgy RethyNote Added: 0009127
09-12-2009 15:56Gyorgy RethyNote Deleted: 0009127
09-12-2009 15:57Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
09-12-2009 15:57Gyorgy RethyStatusfeedback => resolved
09-12-2009 15:57Gyorgy RethyResolutionreopened => fixed
16-02-2010 07:06Ina SchieferdeckerStatusresolved => closed
16-02-2010 07:07Ina SchieferdeckerFixed in Version => Edition 4.2.1 (not yet published)
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009110) +
+ Ina Schieferdecker    +
+ 08-12-2009 18:46    +
+ 		+ + + + +
+ Extend the semantics definition in "8.2.4 Definition of friend modules" with
+ 
+"Missing friend modules shall not cause an error.
+
+NOTE: Friend modules can be checked by tools, however at most warning are to be issued if a friend module is missing."
+
+Please check
+
+
+
+ + + + + + + + + + +
+ (0009126) +
+ Gyorgy Rethy    +
+ 09-12-2009 15:55    +
+ 		+ + + + +
+ OK with me.
+
+ + diff --git a/docs/mantis/CR5447.md b/docs/mantis/CR5447.md new file mode 100644 index 0000000000000000000000000000000000000000..2744774231cf5ab5cc3d8e670a3b493f4974d3d8 --- /dev/null +++ b/docs/mantis/CR5447.md @@ -0,0 +1,97 @@ + + + + + + + + + + + + + 0005447: unique XSD element is not handled - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005447Part 09: Using XML with TTCN-3Technicalpublic02-12-2009 08:2801-02-2010 11:17
ReporterGyorgy Rethy 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.1.1 (published 2009-06) 
Target Versionv4.2.1 (published 2010-07)Fixed in Versionv4.2.1 (published 2010-07) 
Clause Reference(s)7
For STF discussion
Source (company - Author)L.M.Ericsson
Summary0005447: unique XSD element is not handled
DescriptionAn explicit statement on handling the unique XSD element is missing in the standard.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR5447_resolution_v1.doc (70,144) 08-12-2009 16:39
http://oldforge.etsi.org/mantis/file_download.php?file_id=2295&type=bug
Issue History
Date ModifiedUsernameFieldChange
02-12-2009 08:28Gyorgy RethyNew Issue
02-12-2009 08:28Gyorgy RethyStatusnew => assigned
02-12-2009 08:28Gyorgy RethyAssigned To => Gyorgy Rethy
02-12-2009 08:28Gyorgy RethyClause Reference(s) => 7
02-12-2009 08:28Gyorgy RethySource (company - Author) => L.M.Ericsson
07-12-2009 13:48Ina SchieferdeckerTarget Version => Edition 4.2.1 (not yet published)
08-12-2009 15:37Gyorgy RethyNote Added: 0009099
08-12-2009 15:38Gyorgy RethyFile Added: CR5447_resolution_v1.doc
08-12-2009 15:38Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
08-12-2009 15:51Gyorgy RethyAssigned ToIna Schieferdecker => Gyorgy Rethy
08-12-2009 15:52Gyorgy RethyFile Deleted: CR5447_resolution_v1.doc
08-12-2009 16:39Gyorgy RethyFile Added: CR5447_resolution_v1.doc
08-12-2009 16:40Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
01-02-2010 11:17Gyorgy RethyNote Added: 0009175
01-02-2010 11:17Gyorgy RethyStatusassigned => closed
01-02-2010 11:17Gyorgy RethyResolutionopen => fixed
01-02-2010 11:17Gyorgy RethyFixed in Version => Edition 4.2.1 (not yet published)
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009099) +
+ Gyorgy Rethy    +
+ 08-12-2009 15:37    +
+ 		+ + + + +
+ CR5447_resolution_v1.doc: ready for review
+
+
+
+ + + + + + + + + + +
+ (0009175) +
+ Gyorgy Rethy    +
+ 01-02-2010 11:17    +
+ 		+ + + + +
+ Implemented as in CR5447_resolution_v1.doc.
+
+ + diff --git a/docs/mantis/CR5449.md b/docs/mantis/CR5449.md new file mode 100644 index 0000000000000000000000000000000000000000..0307ac23b2c426330e06b470f14685a4afec6bb5 --- /dev/null +++ b/docs/mantis/CR5449.md @@ -0,0 +1,289 @@ + + + + + + + + + + + + + 0005449: Add mapping for parameterized ASN.1 types - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Advanced Parametrization (ES 202 784)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005449Ext Pack: Advanced Parametrization (ES 202 784)New Featurepublic08-12-2009 08:3016-12-2016 11:44
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritylowSeveritymajorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv1.6.1 (published 2017-04)Fixed in Versionv1.6.1 (published 2017-04) 
TS version
Clause Reference(s)new
Source (company - Author)L.M.Ericsson
Summary0005449: Add mapping for parameterized ASN.1 types
DescriptionTHIS CR IS RELATED TO THE ADVANCED PARAMETERIZATION PACKAGE.
+Currently mapping of parameterized ASN.1 types is not suppoorted, though with the publication of the advanced parameterization package the main obstacle was removed. Add this mapping to ES 202 784.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0006254closed Gyorgy Rethy Package compatibility should be changed to the latest published standards 
related to 0006253closed Gyorgy Rethy Old deleted text shall be deleted 
related to 0007356closed Gyorgy Rethy allow bounded formal type parameters also for non component types 
Attached Filesdoc CR5449_resolution_v1.doc (398,848) 10-08-2012 11:07
http://oldforge.etsi.org/mantis/file_download.php?file_id=2716&type=bug
doc CR5449_resolution_Part7_v2.doc (139,776) 10-08-2012 11:22
http://oldforge.etsi.org/mantis/file_download.php?file_id=2718&type=bug
doc CR5449_resolution_v2.doc (331,264) 15-11-2016 12:47
http://oldforge.etsi.org/mantis/file_download.php?file_id=3519&type=bug
Issue History
Date ModifiedUsernameFieldChange
08-12-2009 08:30Gyorgy RethyNew Issue
08-12-2009 08:30Gyorgy RethyStatusnew => assigned
08-12-2009 08:30Gyorgy RethyAssigned To => Gyorgy Rethy
08-12-2009 08:30Gyorgy RethyClause Reference(s) => new
08-12-2009 08:30Gyorgy RethySource (company - Author) => L.M.Ericsson
10-12-2009 08:51Gyorgy RethyTarget Version => Edition 5.1.1 (not yet published)
02-02-2010 16:31Gyorgy RethySummaryAdd mapping of parameterized ASN.1 types => Add mapping for parameterized ASN.1 types
02-02-2010 16:31Gyorgy RethyDescription Updated
22-03-2010 17:30Gyorgy RethyPrioritynormal => low
25-03-2010 08:43Gyorgy RethyNote Added: 0009292
25-03-2010 08:43Gyorgy RethyNote Added: 0009293
25-03-2010 08:45Gyorgy RethyNote Deleted: 0009293
25-03-2010 14:21Gyorgy RethyFile Added: CR5449_resolution_AdvParam_v1.doc
25-03-2010 14:22Gyorgy RethyFile Added: CR5449_resolution_Part7_v1.doc
25-03-2010 14:23Gyorgy RethyNote Added: 0009308
25-03-2010 15:04Gyorgy RethyNote Added: 0009311
25-03-2010 15:04Gyorgy RethyPrioritylow => high
25-03-2010 15:05Gyorgy RethyNote Edited: 0009311
25-03-2010 15:05Gyorgy RethyNote Edited: 0009311
25-03-2010 15:09Gyorgy RethyProjectPart 07: Using ASN.1 with TTCN-3 => Ext Pack: Advanced Parametrization (ES 202 784)
03-12-2010 10:26Gyorgy RethyProduct VersionEdition 4.1.1 Published 2009-06-02 =>
03-12-2010 10:26Gyorgy RethyTarget VersionEdition 4.3.1 (not yet published) => v1.2.2
24-05-2011 19:32Gyorgy RethyPriorityhigh => normal
27-09-2011 14:11Gyorgy RethyTarget Versionv1.2.2 (interim) => v1.3.1
08-08-2012 15:46Gyorgy RethyRelationship addedrelated to 0006254
08-08-2012 15:47Gyorgy RethyRelationship addedrelated to 0006253
10-08-2012 11:06Gyorgy RethyFile Deleted: CR5449_resolution_AdvParam_v1.doc
10-08-2012 11:07Gyorgy RethyFile Added: CR5449_resolution_v1.doc
10-08-2012 11:08Gyorgy RethyNote Added: 0011020
10-08-2012 11:22Gyorgy RethyFile Added: CR5449_resolution_Part7_v2.doc
10-08-2012 11:22Gyorgy RethyFile Deleted: CR5449_resolution_Part7_v1.doc
13-08-2012 13:22Jacob Wieland - SpirentNote Added: 0011037
08-07-2013 18:21Gyorgy RethyTarget Versionv1.3.1 (published 2013-04) => v1.4.1 (published 2014-06)
08-04-2014 08:57Gyorgy RethyTarget Versionv1.4.1 (published 2014-06) => v1.5.1 (published 2015-06)
06-11-2014 10:41Gyorgy RethyTarget Versionv1.5.1 (published 2015-06) => v1.6.1 (published 2017-04)
07-01-2016 08:52Gyorgy RethyPrioritynormal => low
18-03-2016 10:36Jacob Wieland - SpirentRelationship addedrelated to 0007356
18-07-2016 14:50Jens GrabowskiAssigned ToGyorgy Rethy => Kristóf Szabados
14-11-2016 16:37Jens GrabowskiAssigned ToKristóf Szabados => Jacob Wieland - Spirent
15-11-2016 12:47Jacob Wieland - SpirentFile Added: CR5449_resolution_v2.doc
15-11-2016 12:53Jacob Wieland - SpirentNote Added: 0014247
15-11-2016 12:53Jacob Wieland - SpirentStatusassigned => resolved
15-11-2016 12:53Jacob Wieland - SpirentFixed in Version => v1.6.1 (published 2017-04)
15-11-2016 12:53Jacob Wieland - SpirentResolutionopen => fixed
15-11-2016 12:53Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
16-12-2016 11:40Gyorgy RethyNote Added: 0014444
16-12-2016 11:40Gyorgy RethyStatusresolved => closed
16-12-2016 11:44Gyorgy RethyNote Edited: 0014444bug_revision_view_page.php?bugnote_id=14444#r348
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009292) +
+ Gyorgy Rethy    +
+ 25-03-2010 08:43    +
+ 		+ + + + +
+ Work started... As the case seems to be straighforward, no STF discussion is needed:
+- Part-7: add reference to ES 202 784 and a note saying that mapping of parameterized ASN.1 types requires supporting the Adv. Param package and the mapping is specified in that package.
+- ES 202 784: add the mapping: it is straighforward in case of ASN.1 type and value parameters, for IO/IOset parameters if they are used in ignored subtype constraints only (e.g. table constraint that is majority of the real cases) the parameter shall be ignored together with the constraint. If not, don't map.
+
+
+
+ + + + + + + + + + +
+ (0009308) +
+ Gyorgy Rethy    +
+ 25-03-2010 14:23    +
+ 		+ + + + +
+ CR5449_resolution_AdvParam_v1.doc & CR5449_resolution_Part7_v1.doc contain the first proposal to resolve the issue. They have to be re-thinked again during the next session with a "fresh mind".
+
+
+
+ + + + + + + + + + +
+ (0009311) +
+ Gyorgy Rethy    +
+ 25-03-2010 15:04    +
(edited on: 25-03-2010 15:05)
+ 		+ + + + +
+ On looking at the issue I have decided to raise the priorty to the bugfix level as there is an error/incompleteness in the Adv. Param. package regarding importing parameterized ASN.1 definitions.
+
+
+
+
+
+ + + + + + + + + + +
+ (0011020) +
+ Gyorgy Rethy    +
+ 10-08-2012 11:08    +
+ 		+ + + + +
+ Resolution draft is in the files CR5449_resolution_Part7_v1.doc and CR5449_resolution_v1.doc. Ready for review.
+
+
+
+ + + + + + + + + + +
+ (0011037) +
+ Jacob Wieland - Spirent    +
+ 13-08-2012 13:22    +
+ 		+ + + + +
+ 5.4.1.5. restriction c) states: Requiring type compatibility of the actual parameter with the formal parameter is possible for component types only.
+
+While I have never understood this restriction, I think you violate it in
+your examples and mapping by allowing such type compatibility between the type of the formal type parameter and the type of the actual type parameter.
+
+Thus, I think this restriction needs to be lifted for your mapping (specifically rule d) case two) and your examples for that mapping to work fully.
+
+Otherwise, I have no objections, just a few typos:
+
+resolvable compile time => resolvable at compile time
+
+contrain => constrain
+
+
+
+ + + + + + + + + + +
+ (0014247) +
+ Jacob Wieland - Spirent    +
+ 15-11-2016 12:53    +
+ 		+ + + + +
+ fixed the two typos
+
+changed one example from error to OK because integer IS a subtype of integer conceptually (they have the same root type and the same value set, obviously).
+
+Otherwise ok, dependent on acceptance of CR 7356.
+
+
+
+ + + + + + + + + + +
+ (0014444) +
+ Gyorgy Rethy    +
+ 16-12-2016 11:40    +
(edited on: 16-12-2016 11:44)
+ 		+ + + + +
+ Added to draft V1.5.2
+
+
+
+ + diff --git a/docs/mantis/CR5450.md b/docs/mantis/CR5450.md new file mode 100644 index 0000000000000000000000000000000000000000..e4dab163f9c1c52a196701690396e87dd7322bab --- /dev/null +++ b/docs/mantis/CR5450.md @@ -0,0 +1,165 @@ + + + + + + + + + + + + + 0005450: Form attribute IS supported - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005450Part 09: Using XML with TTCN-3Clarificationpublic08-12-2009 15:0718-03-2010 07:56
ReporterGyorgy Rethy 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.2.1 (published 2010-07)Fixed in Versionv4.2.1 (published 2010-07) 
Clause Reference(s)7.1.6
For STF discussion
Source (company - Author)L.M.Ericsson
Summary0005450: Form attribute IS supported
DescriptionThe first sentence of the clause contradicts to the content of the clause. Mapping of the form attribute is supported but it is not mapped to a TTCN-3 language constructs but to an encoding instruction.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR5450_resolution_v1.doc (84,992) 08-12-2009 15:16
http://oldforge.etsi.org/mantis/file_download.php?file_id=2293&type=bug
Issue History
Date ModifiedUsernameFieldChange
08-12-2009 15:07Gyorgy RethyNew Issue
08-12-2009 15:07Gyorgy RethyStatusnew => assigned
08-12-2009 15:07Gyorgy RethyAssigned To => Gyorgy Rethy
08-12-2009 15:07Gyorgy RethyClause Reference(s) => 7.1.6
08-12-2009 15:07Gyorgy RethySource (company - Author) => L.M.Ericsson
08-12-2009 15:16Gyorgy RethyFile Added: CR5450_resolution_v1.doc
08-12-2009 15:16Gyorgy RethyNote Added: 0009098
08-12-2009 15:16Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
08-12-2009 17:08Gyorgy RethyNote Added: 0009103
08-12-2009 17:08Gyorgy RethyTarget Version => Edition 5.1.1 (not yet published)
08-12-2009 17:08Gyorgy RethyNote Added: 0009104
01-02-2010 11:20Gyorgy RethyNote Added: 0009176
01-02-2010 11:20Gyorgy RethyStatusassigned => closed
01-02-2010 11:20Gyorgy RethyResolutionopen => fixed
01-02-2010 11:20Gyorgy RethyFixed in Version => Edition 4.2.1 (not yet published)
18-03-2010 07:56Ina SchieferdeckerTarget VersionEdition 5.1.1 (not yet published) => Edition 4.2.1 (not yet published)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009098) +
+ Gyorgy Rethy    +
+ 08-12-2009 15:16    +
+ 		+ + + + +
+ CR5450_resolution_v1.doc: ready for review
+
+
+
+ + + + + + + + + + +
+ (0009103) +
+ Gyorgy Rethy    +
+ 08-12-2009 17:08    +
+ 		+ + + + +
+ To be postponed to 2010.
+
+
+
+ + + + + + + + + + +
+ (0009104) +
+ Gyorgy Rethy    +
+ 08-12-2009 17:08    +
+ 		+ + + + +
+ To be postponed to 2010.
+
+
+
+ + + + + + + + + + +
+ (0009176) +
+ Gyorgy Rethy    +
+ 01-02-2010 11:20    +
+ 		+ + + + +
+ Implemented acc. to CR5450_resolution_v1.doc
+
+ + diff --git a/docs/mantis/CR5451.md b/docs/mantis/CR5451.md new file mode 100644 index 0000000000000000000000000000000000000000..00cb7afabbd8f234f802599df0543df63ac64f12 --- /dev/null +++ b/docs/mantis/CR5451.md @@ -0,0 +1,207 @@ + + + + + + + + + + + + + 0005451: Potential BNF Simplification - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005451Part 01: TTCN-3 Core LanguageEditorialpublic08-12-2009 17:1814-12-2010 06:14
ReporterIna Schieferdecker 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.3.1 (published 2011-06)Fixed in Versionv4.3.1 (published 2011-06) 
Clause Reference(s)Annex A
Source (company - Author)     
Summary0005451: Potential BNF Simplification
DescriptionIn addition to the various identifier renamings and the keyword definitions, the TTCN-3 BNF contains other kinds of non-terminals which are just translated into other single non-terminals, see e.g.
+
+ModuleDefinitionsPart ::= ModuleDefinitionsList
+
+This is superfluous. It was considered to ease the reading but it blows up the BNF unnecessarily: 49 of such rules exist (being almost 8% of the TTCN-3 BNF).
+
+It is proposed to remove these rules and resolve them in favour of the right-hand-side of the renaming BNF rule.
+
+For example:, for rule "ModuleDefinitionsPart ::= ModuleDefinitionsList" ModuleDefinitionsPart is replaced by ModuleDefinitionsList
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0005811closed Benjamin Zeiss Correction in BNF rules for template variables 
Attached Filesdoc NonterminalRenaming.doc (47,104) 08-12-2009 17:18
http://oldforge.etsi.org/mantis/file_download.php?file_id=2297&type=bug
zip ttcn3-bnfs-before-simplification.zip (37,942) 02-12-2010 09:09
http://oldforge.etsi.org/mantis/file_download.php?file_id=2462&type=bug
zip ttcn3-bnfs-after-simplification.zip (63,274) 02-12-2010 15:06
http://oldforge.etsi.org/mantis/file_download.php?file_id=2468&type=bug
? package-behaviour_types-before-simplification.bnf (3,395) 02-12-2010 15:13
http://oldforge.etsi.org/mantis/file_download.php?file_id=2469&type=bug
Issue History
Date ModifiedUsernameFieldChange
08-12-2009 17:18Ina SchieferdeckerNew Issue
08-12-2009 17:18Ina SchieferdeckerStatusnew => assigned
08-12-2009 17:18Ina SchieferdeckerAssigned To => Gyorgy Rethy
08-12-2009 17:18Ina SchieferdeckerFile Added: NonterminalRenaming.doc
08-12-2009 17:18Ina SchieferdeckerClause Reference(s) => Annex A
08-12-2009 17:18Ina SchieferdeckerSource (company - Author) =>
08-12-2009 17:19Ina SchieferdeckerProjectPart 09: Using XML with TTCN-3 => Part 01: TTCN-3 Core Language
09-12-2009 14:23Ina SchieferdeckerNote Added: 0009121
09-12-2009 14:23Ina SchieferdeckerTarget Version => Edition 5.1.1 (not yet published)
22-03-2010 17:30Gyorgy RethyAssigned ToGyorgy Rethy =>
22-03-2010 17:30Gyorgy RethyStatusassigned => new
23-03-2010 12:43Gyorgy RethyAssigned To => Benjamin Zeiss
23-03-2010 12:43Gyorgy RethyStatusnew => assigned
30-11-2010 14:31Gyorgy RethyNote Added: 0009849
30-11-2010 17:35Gyorgy RethyRelationship addedrelated to 0005811
02-12-2010 09:09Benjamin ZeissFile Added: ttcn3-bnfs-before-simplification.zip
02-12-2010 15:06Benjamin ZeissFile Added: ttcn3-bnfs-after-simplification.zip
02-12-2010 15:07Benjamin ZeissNote Added: 0009931
02-12-2010 15:13Benjamin ZeissFile Added: package-behaviour_types-before-simplification.bnf
02-12-2010 15:13Benjamin ZeissAssigned ToBenjamin Zeiss => Ina Schieferdecker
02-12-2010 15:27Benjamin ZeissNote Added: 0009932
14-12-2010 05:43Ina SchieferdeckerNote Added: 0009960
14-12-2010 05:44Ina SchieferdeckerStatusassigned => resolved
14-12-2010 05:44Ina SchieferdeckerResolutionopen => fixed
14-12-2010 05:44Ina SchieferdeckerFixed in Version => Edition 4.3.1 (not yet published)
14-12-2010 06:14Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009121) +
+ Ina Schieferdecker    +
+ 09-12-2009 14:23    +
+ 		+ + + + +
+ To discuss with MTS if there should be a general revision of the BNF - hence postponed to 2010.
+
+
+
+ + + + + + + + + + +
+ (0009849) +
+ Gyorgy Rethy    +
+ 30-11-2010 14:31    +
+ 		+ + + + +
+ STF discussion on 30/11/2010: Ina will give the BNF to be simplified with the tool to Benjamin this week; make the swap this week and implement final BNF changes on the simplified BNF.
+
+
+
+ + + + + + + + + + +
+ (0009931) +
+ Benjamin Zeiss    +
+ 02-12-2010 15:07    +
+ 		+ + + + +
+ Finished the simplification. Please review. Please note that the behaviour types file in the zip file "ttcn3-bnfs-before-simplification" is bogus and basically a duplicate of the configuration and deployment package. I'll attach a separate diff-able file.
+
+
+
+ + + + + + + + + + +
+ (0009932) +
+ Benjamin Zeiss    +
+ 02-12-2010 15:27    +
+ 		+ + + + +
+ Clarification: if you want to diff the behaviour types file, you should compare against the attached "package-behaviour_types-before-simplification.bnf" and not the "package-behaviour_types.bnf" in the ttcn3-bnfs-before-simplification.zip. Therefore, simply replace the file in the corresponding directory beforehand.
+
+
+
+ + + + + + + + + + +
+ (0009960) +
+ Ina Schieferdecker    +
+ 14-12-2010 05:43    +
+ 		+ + + + +
+ replaced the BNF in annex A of part 1 as proposed by Benjamin
+
+ + diff --git a/docs/mantis/CR5452.md b/docs/mantis/CR5452.md new file mode 100644 index 0000000000000000000000000000000000000000..91ce6df4803aa78d8b06064ce24ab17697494c20 --- /dev/null +++ b/docs/mantis/CR5452.md @@ -0,0 +1,131 @@ + + + + + + + + + + + + + 0005452: Allow inside matching symbols for objid templates - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 07: Using ASN.1 with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005452Part 07: Using ASN.1 with TTCN-3Technicalpublic09-12-2009 12:3601-02-2010 15:54
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.2.1 (published 2010-07)Fixed in Versionv4.2.1 (published 2010-07) 
Clause Reference(s)A.2
Source (company - Author)L.M.Ericsson
Summary0005452: Allow inside matching symbols for objid templates
DescriptionWhile clause 7.2.4.2 allows the inside matching symbols ? and * for objid templates, the BNF does not extends the corresponding rule of the core.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR5452_resolution_v1.doc (146,944) 09-12-2009 14:16
http://oldforge.etsi.org/mantis/file_download.php?file_id=2307&type=bug
Issue History
Date ModifiedUsernameFieldChange
09-12-2009 12:36Gyorgy RethyNew Issue
09-12-2009 12:36Gyorgy RethyStatusnew => assigned
09-12-2009 12:36Gyorgy RethyAssigned To => Gyorgy Rethy
09-12-2009 12:36Gyorgy RethyClause Reference(s) => A.2
09-12-2009 12:36Gyorgy RethySource (company - Author) => L.M.Ericsson
09-12-2009 14:16Gyorgy RethyFile Added: CR5452_resolution_v1.doc
09-12-2009 14:23Gyorgy RethyDescription Updated
09-12-2009 14:23Gyorgy RethyDescription Updated
10-12-2009 08:50Gyorgy RethyNote Added: 0009131
10-12-2009 08:51Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
04-01-2010 13:15Ina SchieferdeckerNote Added: 0009155
04-01-2010 13:16Ina SchieferdeckerAssigned ToIna Schieferdecker => Gyorgy Rethy
04-01-2010 13:16Ina SchieferdeckerStatusassigned => resolved
04-01-2010 13:16Ina SchieferdeckerResolutionopen => fixed
04-01-2010 13:16Ina SchieferdeckerFixed in Version => Edition 4.2.1 (not yet published)
04-01-2010 13:16Ina SchieferdeckerTarget Version => Edition 4.2.1 (not yet published)
01-02-2010 15:54Gyorgy RethyStatusresolved => closed
01-02-2010 15:54Gyorgy RethyNote Added: 0009186
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009131) +
+ Gyorgy Rethy    +
+ 10-12-2009 08:50    +
+ 		+ + + + +
+ CR5452_resolution_v1.doc: ready for review
+
+
+
+ + + + + + + + + + +
+ (0009155) +
+ Ina Schieferdecker    +
+ 04-01-2010 13:15    +
+ 		+ + + + +
+ ok - except that the font in the BNF are used differently (some are coloured, some are underlined) - this should be fixed.
+
+
+
+ + + + + + + + + + +
+ (0009186) +
+ Gyorgy Rethy    +
+ 01-02-2010 15:54    +
+ 		+ + + + +
+ Implemented in master copy, v4.1.4
+
+ + diff --git a/docs/mantis/CR5453.md b/docs/mantis/CR5453.md new file mode 100644 index 0000000000000000000000000000000000000000..ea6ba4c005b1b4eb109515cd4e63410e0f9195ad --- /dev/null +++ b/docs/mantis/CR5453.md @@ -0,0 +1,344 @@ + + + + + + + + + + + + + 0005453: Support of substitutionGroup attribute - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005453Part 09: Using XML with TTCN-3New Featurepublic09-12-2009 16:2917-12-2010 11:26
ReporterOlaf A. Bergengruen 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.1.1 (published 2009-06) 
Target Versionv4.3.1 (published 2011-06)Fixed in Versionv4.3.1 (published 2011-06) 
Clause Reference(s)new clause needed
For STF discussion
Source (company - Author)     
Summary0005453: Support of substitutionGroup attribute
DescriptionIMS Supplementary Services TS 24.163 define XML schemas to be used by the Supplementary Services
+Test cases for verifying UE Supplementary Services are specified in TS 34.229-1 clause 15.
+
+In order to use these schemas in TTCN test cases, the substitutionGroup attribute should be supported.
+
+Attached the schemas needed for IMS Supplementary Services.
Steps To Reproduce
Additional InformationAttached the schemas needed for IMS Supplementary Services (from 3GPP TS 24.173)
TagsNo tags attached.
Relationships
Attached Fileszip 24173-schemas.zip (7,125) 09-12-2009 16:29
http://oldforge.etsi.org/mantis/file_download.php?file_id=2311&type=bug
doc CR5453_analysis.doc (45,568) 02-09-2010 17:02
http://oldforge.etsi.org/mantis/file_download.php?file_id=2439&type=bug
doc CR5453_analysis v2.doc (45,056) 02-12-2010 09:57
http://oldforge.etsi.org/mantis/file_download.php?file_id=2463&type=bug
doc CR5453_resolution v3_noTypeSubstitution.doc (1,553,920) 02-12-2010 09:58
http://oldforge.etsi.org/mantis/file_download.php?file_id=2464&type=bug
doc CR5453_resolution v4.doc (1,597,440) 02-12-2010 14:27
http://oldforge.etsi.org/mantis/file_download.php?file_id=2467&type=bug
Issue History
Date ModifiedUsernameFieldChange
09-12-2009 16:29Olaf A. BergengruenNew Issue
09-12-2009 16:29Olaf A. BergengruenStatusnew => assigned
09-12-2009 16:29Olaf A. BergengruenAssigned To => Gyorgy Rethy
09-12-2009 16:29Olaf A. BergengruenFile Added: 24173-schemas.zip
09-12-2009 16:29Olaf A. BergengruenClause Reference(s) => new clause needed
09-12-2009 16:29Olaf A. BergengruenSource (company - Author) =>
10-12-2009 08:53Gyorgy RethyTarget Version => Edition 4.2.1 (not yet published)
10-12-2009 10:00Gyorgy RethyTarget VersionEdition 4.2.1 (not yet published) => Edition 5.1.1 (not yet published)
01-07-2010 11:04Gyorgy RethyNote Added: 0009444
02-07-2010 15:10Gyorgy RethyFile Added: CR5453_resolution v1.doc
02-07-2010 15:12Gyorgy RethyNote Added: 0009478
02-07-2010 15:18Gyorgy RethyFile Deleted: CR5453_resolution v1.doc
02-07-2010 15:18Gyorgy RethyFile Added: CR5453_resolution v1.doc
02-09-2010 17:02Gyorgy RethyFile Deleted: CR5453_resolution v1.doc
02-09-2010 17:02Gyorgy RethyFile Added: CR5453_analysis.doc
02-09-2010 17:04Gyorgy RethyNote Added: 0009702
30-11-2010 14:45Gyorgy RethyNote Added: 0009850
02-12-2010 09:57Gyorgy RethyFile Added: CR5453_analysis v2.doc
02-12-2010 09:58Gyorgy RethyFile Added: CR5453_resolution v3_noTypeSubstitution.doc
02-12-2010 10:01Gyorgy RethyNote Added: 0009917
02-12-2010 10:56Gyorgy RethyFile Added: CR5453_resolution v4_noTypeSubstitution.doc
02-12-2010 10:58Gyorgy RethyNote Added: 0009925
02-12-2010 10:58Gyorgy RethyNote Edited: 0009925
02-12-2010 14:11Gyorgy RethyFile Added: CR5453_resolution v4.doc
02-12-2010 14:14Gyorgy RethyFile Deleted: CR5453_resolution v4.doc
02-12-2010 14:27Gyorgy RethyNote Added: 0009930
02-12-2010 14:27Gyorgy RethyNote Edited: 0009930
02-12-2010 14:27Gyorgy RethyFile Added: CR5453_resolution v4.doc
03-12-2010 14:52Jacob Wieland - SpirentNote Added: 0009937
08-12-2010 14:53Gyorgy RethyCategoryTechnical => New Feature
13-12-2010 12:38Gyorgy RethyFile Deleted: CR5453_resolution v4_noTypeSubstitution.doc
17-12-2010 11:26Gyorgy RethyNote Added: 0009979
17-12-2010 11:26Gyorgy RethyStatusassigned => closed
17-12-2010 11:26Gyorgy RethyResolutionopen => fixed
17-12-2010 11:26Gyorgy RethyFixed in Version => Edition 4.3.1 (not yet published)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009444) +
+ Gyorgy Rethy    +
+ 01-07-2010 11:04    +
+ 		+ + + + +
+ The attached IMS SS schemas also use processContents and abstract attributes that are not supported today, so at least these 3 attributes has to be handled in this CR.
+
+
+
+ + + + + + + + + + +
+ (0009478) +
+ Gyorgy Rethy    +
+ 02-07-2010 15:12    +
+ 		+ + + + +
+ CR5453_resolution v1.doc: a working document uploaded at the end of the STF's June session to have it available next time. Not complete and not checked, but reflects the main direction to resolve the CR.
+
+
+
+ + + + + + + + + + +
+ (0009702) +
+ Gyorgy Rethy    +
+ 02-09-2010 17:04    +
+ 		+ + + + +
+ Decision taken by the discussion on 31th August: develop the proposed solution based on the decisions as shown in the file CR5453_analysis.doc
+
+
+
+ + + + + + + + + + +
+ (0009850) +
+ Gyorgy Rethy    +
+ 30-11-2010 14:45    +
+ 		+ + + + +
+ STF discussion on 30/11/2010: Gyorgy is working on the text, based on the analysis and results od earlier discussions. Substitutable heads and parent types shall be in the TTCN-3 module corresponding to their namespaces.
+
+
+
+ + + + + + + + + + +
+ (0009917) +
+ Gyorgy Rethy    +
+ 02-12-2010 10:01    +
+ 		+ + + + +
+ File CR5453_analysis v2.doc contains an update of the analisys results. File CR5453_resolution v3_noTypeSubstitution.doc contains the proposed text for the solution, except type substitution (contains element substitution, handling of abstract/final/block attributes and new encoding instructions). Pls. review.
+
+
+
+ + + + + + + + + + +
+ (0009925) +
+ Gyorgy Rethy    +
+ 02-12-2010 10:58    +
+ 		+ + + + +
+ In CR5453_resolution v4_noTypeSubstitution.doc clause 5.1.1 Namespace is aligned with the decision to have one module per target namespace, independent of substitutable components. No other changes related to the previous version.
+
+
+
+
+
+ + + + + + + + + + +
+ (0009930) +
+ Gyorgy Rethy    +
+ 02-12-2010 14:27    +
+ 		+ + + + +
+ In CR5453_resolution v4.doc proposed text for type substitution is added plus some related amendments to the useType encoding instruction. No other changes related to the previous version.
+
+
+
+
+
+ + + + + + + + + + +
+ (0009937) +
+ Jacob Wieland - Spirent    +
+ 03-12-2010 14:52    +
+ 		+ + + + +
+ I've reviewed the text and can't find any fault with it.
+
+
+
+ + + + + + + + + + +
+ (0009979) +
+ Gyorgy Rethy    +
+ 17-12-2010 11:26    +
+ 		+ + + + +
+ Included into the draft for MTS approval.
+
+ + diff --git a/docs/mantis/CR5454.md b/docs/mantis/CR5454.md new file mode 100644 index 0000000000000000000000000000000000000000..d14c3d607059ce5ca62f5c69d1345c8ac77c726f --- /dev/null +++ b/docs/mantis/CR5454.md @@ -0,0 +1,42 @@ + + + + + + + + + + + + + 0005454: Attributes shall be in quotes - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005454Part 09: Using XML with TTCN-3Editorialpublic16-12-2009 15:5316-12-2009 15:55
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.1.1 (published 2009-06) 
Target Versionv4.2.1 (published 2010-07)Fixed in Versionv4.2.1 (published 2010-07) 
Clause Reference(s)Annex C
For STF discussion
Source (company - Author)L.M.Ericcson
Summary0005454: Attributes shall be in quotes
Descriptionin Example 2:
+<C1 A1=1 A2=2.0>-1</C1>
+change to
+<C1 A1="1" A2="2.0">-1</C1>
+
+in Example 3:
+<C3 xmlns=”nsA” A1=1 A2=-1000>25</C3>
+
+<C3 xmlns=”nsA” A1="1" A2="-1000">25</C3>
+
+in Example 4:
+<NA:newC1 xmlns:NA=”nsA” A1=1 A2=2>-1000</NA:newC1>
+change to
+<NA:newC1 xmlns:NA=”nsA” A1="1" A2="2">-1000</NA:newC1>
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
16-12-2009 15:53Gyorgy RethyNew Issue
16-12-2009 15:53Gyorgy RethyStatusnew => assigned
16-12-2009 15:53Gyorgy RethyAssigned To => Gyorgy Rethy
16-12-2009 15:53Gyorgy RethyClause Reference(s) => Annex C
16-12-2009 15:53Gyorgy RethySource (company - Author) => L.M.Ericcson
16-12-2009 15:55Gyorgy RethyStatusassigned => closed
16-12-2009 15:55Gyorgy RethyResolutionopen => fixed
16-12-2009 15:55Gyorgy RethyFixed in Version => Edition 4.2.1 (not yet published)
16-12-2009 15:55Gyorgy RethyTarget Version => Edition 4.2.1 (not yet published)
+
+ + + + +
+ There are no notes attached to this issue.
+ + diff --git a/docs/mantis/CR5465.md b/docs/mantis/CR5465.md new file mode 100644 index 0000000000000000000000000000000000000000..f94356b0509c7e3ba882c26cfb2919a2ef32b399 --- /dev/null +++ b/docs/mantis/CR5465.md @@ -0,0 +1,134 @@ + + + + + + + + + + + + + 0005465: Referencing elements or groups from another namespace - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005465Part 09: Using XML with TTCN-3Technicalpublic05-02-2010 14:3824-03-2010 15:56
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PriorityhighSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.2.1 (published 2010-07)Fixed in Versionv4.2.1 (published 2010-07) 
Clause Reference(s)7.1.2, 7.3., 7.4, 7.6.3 etc., B.3.14
For STF discussion
Source (company - Author)     
Summary0005465: Referencing elements or groups from another namespace
DescriptionWhen an element/group etc. reference is referncing a definition from another namespace, the namespace as encoding instruction shall be attached to the field(s) corresponding to the given reference. Clause B.3.14 mentioning this, but this shall be specified explicitly in the main text, at the description of the mapping of referenced definition.
+Also Applicability paragraph of clause B.3.14 shall be extended with union fileds and with element references.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR_5465_resolution_v1.doc (109,568) 23-03-2010 16:16
http://oldforge.etsi.org/mantis/file_download.php?file_id=2346&type=bug
Issue History
Date ModifiedUsernameFieldChange
05-02-2010 14:38Gyorgy RethyNew Issue
05-02-2010 14:38Gyorgy RethyStatusnew => assigned
05-02-2010 14:38Gyorgy RethyAssigned To => Gyorgy Rethy
05-02-2010 14:38Gyorgy RethyClause Reference(s) => 7.1.2, 7.3., 7.4, 7.6.3 etc., B.3.14
05-02-2010 14:38Gyorgy RethySource (company - Author) =>
22-03-2010 16:26Gyorgy RethyPrioritynormal => high
22-03-2010 16:26Gyorgy RethyTarget Version => Edition 4.2.1 (not yet published)
23-03-2010 16:16Gyorgy RethyFile Added: CR_5465_resolution_v1.doc
23-03-2010 16:16Gyorgy RethyNote Added: 0009267
23-03-2010 16:16Gyorgy RethyAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
23-03-2010 16:18Gyorgy RethyNote Edited: 0009267
23-03-2010 19:15Jacob Wieland - SpirentNote Added: 0009271
24-03-2010 15:32Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
24-03-2010 15:56Gyorgy RethyNote Added: 0009284
24-03-2010 15:56Gyorgy RethyStatusassigned => closed
24-03-2010 15:56Gyorgy RethyResolutionopen => fixed
24-03-2010 15:56Gyorgy RethyFixed in Version => Edition 4.2.1 (not yet published)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009267) +
+ Gyorgy Rethy    +
+ 23-03-2010 16:16    +
(edited on: 23-03-2010 16:18)
+ 		+ + + + +
+ Proposed resolution text in file CR_5465_resolution_v1.doc, to be reviewed.
+
+
+
+
+
+ + + + + + + + + + +
+ (0009271) +
+ Jacob Wieland - Spirent    +
+ 23-03-2010 19:15    +
+ 		+ + + + +
+ Except for the thrice repeated typo 'optionaly', it seems to be in order.
+
+
+
+ + + + + + + + + + +
+ (0009284) +
+ Gyorgy Rethy    +
+ 24-03-2010 15:56    +
+ 		+ + + + +
+ Implemented in v4.1.5 ("optionaly" typo corrected).
+
+ + diff --git a/docs/mantis/CR5474.md b/docs/mantis/CR5474.md new file mode 100644 index 0000000000000000000000000000000000000000..f023024fb21645e4e46828cfa44077e19362fbf0 --- /dev/null +++ b/docs/mantis/CR5474.md @@ -0,0 +1,63 @@ + + + + + + + + + + + + + 0005474: Packages and namespaces - Visibility of Imported Declarations from External Sources - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 08: Using IDL with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005474Part 08: Using IDL with TTCN-3New Featurepublic14-02-2010 16:0516-02-2010 07:00
ReporterIna Schieferdecker 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityfeatureReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.2.1 (published 2010-07)Fixed in Versionv4.2.1 (published 2010-07) 
Clause Reference(s)Part 8, Clause 7
Source (company - Author)     
Summary0005474: Packages and namespaces - Visibility of Imported Declarations from External Sources
DescriptionImported IDL declarations are in TTCN-3 public.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
child of 0002566closed Ina Schieferdecker Part 09: Using XML with TTCN-3 Packages and namespaces 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
14-02-2010 16:05Ina SchieferdeckerNew Issue
14-02-2010 16:05Ina SchieferdeckerStatusnew => assigned
14-02-2010 16:05Ina SchieferdeckerAssigned To => Ina Schieferdecker
14-02-2010 16:05Ina SchieferdeckerClause Reference(s) => Part 8, Clause 7
14-02-2010 16:05Ina SchieferdeckerSource (company - Author) =>
14-02-2010 16:05Ina SchieferdeckerIssue generated from: 0002566
14-02-2010 16:05Ina SchieferdeckerRelationship addedchild of 0002566
14-02-2010 16:05Ina SchieferdeckerProjectPart 09: Using XML with TTCN-3 => Part 08: Using IDL with TTCN-3
14-02-2010 16:06Ina SchieferdeckerNote Added: 0009205
14-02-2010 16:06Ina SchieferdeckerStatusassigned => resolved
14-02-2010 16:06Ina SchieferdeckerResolutionopen => fixed
14-02-2010 16:06Ina SchieferdeckerTarget Version => Edition 4.2.1 (not yet published)
16-02-2010 06:59Ina SchieferdeckerStatusresolved => closed
16-02-2010 07:00Ina SchieferdeckerFixed in Version => Edition 4.2.1 (not yet published)
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009205) +
+ Ina Schieferdecker    +
+ 14-02-2010 16:06    +
+ 		+ + + + +
+ Add in clause 7: "All imported IDL declarations are in TTCN-3 public by default (see clause 8.2.5 of ES 201 873-1 [1])."
+
+ + diff --git a/docs/mantis/CR5475.md b/docs/mantis/CR5475.md new file mode 100644 index 0000000000000000000000000000000000000000..b7b6b129132a4b44ac6672ab42c0e317500097eb --- /dev/null +++ b/docs/mantis/CR5475.md @@ -0,0 +1,234 @@ + + + + + + + + + + + + + 0005475: Some TCI constants without explicit values - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005475Part 06: TTCN-3 Control InterfaceClarificationpublic15-02-2010 05:0025-03-2010 11:32
ReporterIna Schieferdecker 
Assigned ToIna Schieferdecker 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.1.1 (published 2009-06) 
Target Versionv4.3.1 (published 2011-06)Fixed in Versionv4.2.1 (published 2010-07) 
Clause Reference(s)Various
Source (company - Author)Ina Schieferdecker, FOKUS
Summary0005475: Some TCI constants without explicit values
DescriptionNot all TCI constants have explicit values which may make the mappings inconsistent between tools.
Steps To Reproduce
Additional InformationTo be fixed: ParameterPassingMode (IN, OUT, INOUT), ComponentKind (CTRL, MTC, PTC, SYSTEM, ALIVE) and Verdict (NONE, PASS, INCONC, FAIL, ERROR)
TagsNo tags attached.
Relationships
child of 0005413closed Ina Schieferdecker TciTypeClassType modified without setting explicit values 
Attached Fileszip es_20187306v040103.zip (1,304,332) 25-03-2010 11:31
http://oldforge.etsi.org/mantis/file_download.php?file_id=2365&type=bug
Issue History
Date ModifiedUsernameFieldChange
15-02-2010 05:00Ina SchieferdeckerNew Issue
15-02-2010 05:00Ina SchieferdeckerStatusnew => assigned
15-02-2010 05:00Ina SchieferdeckerAssigned To => Ina Schieferdecker
15-02-2010 05:00Ina SchieferdeckerClause Reference(s) => Various
15-02-2010 05:00Ina SchieferdeckerSource (company - Author) => Ina Schieferdecker, FOKUS
15-02-2010 05:00Ina SchieferdeckerIssue generated from: 0005413
15-02-2010 05:00Ina SchieferdeckerRelationship addedchild of 0005413
15-02-2010 05:05Ina SchieferdeckerTarget Version => Edition 5.1.1 (not yet published)
23-03-2010 09:40Ina SchieferdeckerNote Added: 0009252
24-03-2010 12:21Ina SchieferdeckerNote Added: 0009275
24-03-2010 12:21Ina SchieferdeckerNote Added: 0009276
24-03-2010 12:22Ina SchieferdeckerFile Added: es_20187306v040103.zip
24-03-2010 12:23Ina SchieferdeckerStatusassigned => resolved
24-03-2010 12:23Ina SchieferdeckerResolutionopen => fixed
24-03-2010 12:23Ina SchieferdeckerFixed in Version => Edition 4.2.1 (not yet published)
24-03-2010 12:23Ina SchieferdeckerStatusresolved => assigned
24-03-2010 12:23Ina SchieferdeckerAssigned ToIna Schieferdecker => Gyorgy Rethy
24-03-2010 13:07Gyorgy RethyNote Added: 0009280
24-03-2010 13:07Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
25-03-2010 11:25Ina SchieferdeckerFile Deleted: es_20187306v040103.zip
25-03-2010 11:26Ina SchieferdeckerNote Added: 0009304
25-03-2010 11:31Ina SchieferdeckerNote Edited: 0009304
25-03-2010 11:31Ina SchieferdeckerFile Added: es_20187306v040103.zip
25-03-2010 11:32Ina SchieferdeckerStatusassigned => resolved
25-03-2010 11:32Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009252) +
+ Ina Schieferdecker    +
+ 23-03-2010 09:40    +
+ 		+ + + + +
+ The proposal is to specify TCI constants explicitly (like it is done for TciTypeClass), i.e.
+
+ParameterPassingMode
+    IN 0
+    OUT 1
+    INOUT 2
+
+ComponentKind
+    CTRL 0
+    MTC 1
+    PTC 2
+    SYSTEM 3
+    ALIVE 4
+
+Verdict
+    NONE 0
+    PASS 1
+    INCONC 2
+    FAIL 3
+    ERROR 4
+
+This change may not be backward compatible.
+
+
+
+ + + + + + + + + + +
+ (0009275) +
+ Ina Schieferdecker    +
+ 24-03-2010 12:21    +
+ 		+ + + + +
+ Defined also the values for component statuts, timer status, TCI status
+
+
+
+ + + + + + + + + + +
+ (0009276) +
+ Ina Schieferdecker    +
+ 24-03-2010 12:21    +
+ 		+ + + + +
+ Implemented as agreed between the tool vendors - please check
+
+
+
+ + + + + + + + + + +
+ (0009280) +
+ Gyorgy Rethy    +
+ 24-03-2010 13:07    +
+ 		+ + + + +
+ ComponentStatus
+A NULL value would also be useful for component variables not containing the handle of any active components at the moment (e.g. initializd with null).
+In Part-1 there is also a component state Error. Though this is a temporary state, may be useful.
+
+TimerStatus
+Also a NULL value would be useful for timers that has never been started before. This could distinguish them from e.g. stopped timers (that would be useful for debugging).
+
+TciParameterPassingMode
+I haven't seen it. Is it in another CR?
+
+
+
+ + + + + + + + + + +
+ (0009304) +
+ Ina Schieferdecker    +
+ 25-03-2010 11:26    +
(edited on: 25-03-2010 11:31)
+ 		+ + + + +
+ nullC and nullT added to component and timer status respectively to the IDL definition and the XML mapping.
+
+Correspondingly, also added to the component and timer status in the Java, C, and C++ mapping
+
+TciParameterPassingMode was meant and is defined as discussed.
+
+
+
+ + diff --git a/docs/mantis/CR5478.md b/docs/mantis/CR5478.md new file mode 100644 index 0000000000000000000000000000000000000000..c32cad07bd198315eeed71cdbb0517b8e7f89c29 --- /dev/null +++ b/docs/mantis/CR5478.md @@ -0,0 +1,139 @@ + + + + + + + + + + + + + 0005478: parameter 'message' of TriExceptionType should be of same type in TCI and TRI - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005478Part 06: TTCN-3 Control InterfaceClarificationpublic23-02-2010 16:3525-03-2010 15:58
ReporterAlexander Lorenz 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.2.1 (published 2010-07)Fixed in Versionv4.2.1 (published 2010-07) 
Clause Reference(s)TCI standard (11.3.2.11), TRI standard (6.3.2.12)
Source (company - Author)Testing Technologies - Alex Lorenz
Summary0005478: parameter 'message' of TriExceptionType should be of same type in TCI and TRI
DescriptionIn the TCI standard (11.3.2.11) it is of type 'TString'.
+In the TRI standard (6.3.2.12) it is of type 'byte[]'.
+
+It should be of type 'byte[]' in both cases.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0005479closed Ina Schieferdecker parameter 'address' of TriAddressType should be of same type in TCI and TRI 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
23-02-2010 16:35Alexander LorenzNew Issue
23-02-2010 16:35Alexander LorenzClause Reference(s) => TCI standard (11.3.2.11), TRI standard (6.3.2.12)
23-02-2010 16:35Alexander LorenzSource (company - Author) => Testing Technologies - Alex Lorenz
24-02-2010 14:47Alexander LorenzNote Added: 0009236
23-03-2010 12:41Gyorgy RethyAssigned To => Ina Schieferdecker
23-03-2010 12:41Gyorgy RethyStatusnew => assigned
23-03-2010 12:41Gyorgy RethyProjectTTCN-3 Change Requests => Part 05: TTCN-3 Runtime Interface
23-03-2010 12:41Gyorgy RethyTarget Version => Edition 4.3.1 (not yet published)
24-03-2010 12:28Ina SchieferdeckerNote Added: 0009277
24-03-2010 12:28Ina SchieferdeckerProjectPart 05: TTCN-3 Runtime Interface => Part 06: TTCN-3 Control Interface
24-03-2010 13:09Ina SchieferdeckerNote Added: 0009281
24-03-2010 13:11Ina SchieferdeckerAssigned ToIna Schieferdecker => Gyorgy Rethy
24-03-2010 13:11Ina SchieferdeckerStatusassigned => resolved
24-03-2010 13:11Ina SchieferdeckerResolutionopen => fixed
24-03-2010 13:11Ina SchieferdeckerFixed in Version => Edition 4.2.1 (not yet published)
24-03-2010 13:11Ina SchieferdeckerTarget VersionEdition 4.3.1 (not yet published) => Edition 4.2.1 (not yet published)
25-03-2010 11:10Ina SchieferdeckerRelationship addedrelated to 0005479
25-03-2010 15:52Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
25-03-2010 15:52Gyorgy RethyStatusresolved => assigned
25-03-2010 15:53Gyorgy RethyStatusassigned => resolved
25-03-2010 15:58Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009236) +
+ Alexander Lorenz    +
+ 24-02-2010 14:47    +
+ 		+ + + + +
+ after the type adaptation, an attribute 'numberOfBits' should be added to the TCI definition, with the respective getter and setter method added to the TRI interface, see issue 0005481:
+http://t-ort.etsi.org/view.php?id=5481 [^]
+
+
+
+ + + + + + + + + + +
+ (0009277) +
+ Ina Schieferdecker    +
+ 24-03-2010 12:28    +
+ 		+ + + + +
+ The agreement between the vendors is to use 'byte[]'. Hence, TCI is changed in favour of TRI. CR is moved to TCI.
+
+
+
+ + + + + + + + + + +
+ (0009281) +
+ Ina Schieferdecker    +
+ 24-03-2010 13:09    +
+ 		+ + + + +
+ Implemented as
+
+<xsd:complexType name="TriExceptionType">
+  <xsd:attribute name="val" type="xsd:hexBinary"/>
+</xsd:complexType>
+
+ + diff --git a/docs/mantis/CR5479.md b/docs/mantis/CR5479.md new file mode 100644 index 0000000000000000000000000000000000000000..cdece5c933052c9d0a0c1174fb95a993593545be --- /dev/null +++ b/docs/mantis/CR5479.md @@ -0,0 +1,139 @@ + + + + + + + + + + + + + 0005479: parameter 'address' of TriAddressType should be of same type in TCI and TRI - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005479Part 06: TTCN-3 Control InterfaceClarificationpublic23-02-2010 16:3725-03-2010 11:11
ReporterAlexander Lorenz 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.3.1 (published 2011-06)Fixed in Versionv4.2.1 (published 2010-07) 
Clause Reference(s)TCI standard (11.3.2.9), TRI standard (6.3.2.6)
Source (company - Author)Testing Technologies - Alex Lorenz
Summary0005479: parameter 'address' of TriAddressType should be of same type in TCI and TRI
DescriptionIn the TCI standard (11.3.2.9) it is of type 'TString'.
+In the TRI standard (6.3.2.6) it is of type 'byte[]'.
+
+It should be of type 'byte[]' in both cases.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0005481closed Ina Schieferdecker TriAddressType should have an additional attribute 'numberOfBits' 
related to 0005478closed Ina Schieferdecker parameter 'message' of TriExceptionType should be of same type in TCI and TRI 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
23-02-2010 16:37Alexander LorenzNew Issue
23-02-2010 16:37Alexander LorenzClause Reference(s) => TCI standard (11.3.2.9), TRI standard (6.3.2.6)
23-02-2010 16:37Alexander LorenzSource (company - Author) => Testing Technologies - Alex Lorenz
24-02-2010 14:48Alexander LorenzNote Added: 0009237
23-03-2010 12:38Gyorgy RethyProjectTTCN-3 Change Requests => Part 05: TTCN-3 Runtime Interface
23-03-2010 12:39Gyorgy RethyIssue cloned: 0005491
23-03-2010 12:39Gyorgy RethyRelationship addedparent of 0005491
23-03-2010 12:40Gyorgy RethyAssigned To => Ina Schieferdecker
23-03-2010 12:40Gyorgy RethyStatusnew => assigned
23-03-2010 12:40Gyorgy RethyTarget Version => Edition 4.3.1 (not yet published)
24-03-2010 12:29Ina SchieferdeckerNote Added: 0009278
24-03-2010 12:30Ina SchieferdeckerProjectPart 05: TTCN-3 Runtime Interface => ETSI TTCN-3 Libraries
24-03-2010 13:06Ina SchieferdeckerNote Added: 0009279
24-03-2010 13:14Sebastian MuellersProjectETSI TTCN-3 Libraries => Part 06: TTCN-3 Control Interface
25-03-2010 07:16Ina SchieferdeckerRelationship addedrelated to 0005481
25-03-2010 11:10Ina SchieferdeckerRelationship addedrelated to 0005478
25-03-2010 11:11Ina SchieferdeckerStatusassigned => resolved
25-03-2010 11:11Ina SchieferdeckerResolutionopen => fixed
25-03-2010 11:11Ina SchieferdeckerFixed in Version => Edition 4.2.1 (not yet published)
25-03-2010 11:11Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009237) +
+ Alexander Lorenz    +
+ 24-02-2010 14:48    +
+ 		+ + + + +
+ after the type adaptation, an attribute 'numberOfBits' should be added to the TCI definition, with the respective getter and setter method added to the TRI interface, see issue 0005481:
+http://t-ort.etsi.org/view.php?id=548 [^]
+
+
+
+ + + + + + + + + + +
+ (0009278) +
+ Ina Schieferdecker    +
+ 24-03-2010 12:29    +
+ 		+ + + + +
+ The agreement between the vendors is to use 'byte[]'. Hence, TCI is changed in favour of TRI. CR is moved to TCI.
+
+
+
+ + + + + + + + + + +
+ (0009279) +
+ Ina Schieferdecker    +
+ 24-03-2010 13:06    +
+ 		+ + + + +
+ Defined as follows:
+
+<xsd:complexType name="TriAddressType">
+  <xsd:attribute name="val" type="xsd:hexBinary"/>
+</xsd:complexType>
+
+ + diff --git a/docs/mantis/CR5480.md b/docs/mantis/CR5480.md new file mode 100644 index 0000000000000000000000000000000000000000..b1d7aefbf97e06b85343b6742c8852b9dd0d25a3 --- /dev/null +++ b/docs/mantis/CR5480.md @@ -0,0 +1,69 @@ + + + + + + + + + + + + + 0005480: TriMessageType is lacking attribute 'numberOfBits' - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005480Part 06: TTCN-3 Control InterfaceClarificationpublic24-02-2010 12:4725-03-2010 15:46
ReporterAlexander Lorenz 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.2.1 (published 2010-07)Fixed in Versionv4.2.1 (published 2010-07) 
Clause Reference(s)TCI standard (11.3.2.6), TRI standard (6.3.2.5)
Source (company - Author)Testing Technologies - Alex Lorenz
Summary0005480: TriMessageType is lacking attribute 'numberOfBits'
DescriptionIn the TRI standard (6.3.2.5), th interface for Tri'MEssageType features the methods:
+
+public int getNumberOfBits();
+public void setNumberOfBits(int amount);
+
+
+but in the TCI standard definition (11.3.2.6), TriMessageType lacks the attribute 'numberOfBits'.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
duplicate of 0005415closed Ina Schieferdecker Part 05: TTCN-3 Runtime Interface  getNumberOfBits/setNumberOfBits missing in for TriAddressType, TriParameterType and TriExceptionType 
related to 0005481closed Ina Schieferdecker Part 06: TTCN-3 Control Interface TriAddressType should have an additional attribute 'numberOfBits' 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
24-02-2010 12:47Alexander LorenzNew Issue
24-02-2010 12:47Alexander LorenzClause Reference(s) => TCI standard (11.3.2.6), TRI standard (6.3.2.5)
24-02-2010 12:47Alexander LorenzSource (company - Author) => Testing Technologies - Alex Lorenz
22-03-2010 15:36Gyorgy RethyRelationship addedduplicate of 0005415
25-03-2010 07:18Ina SchieferdeckerRelationship addedrelated to 0005481
25-03-2010 07:40Ina SchieferdeckerProjectTTCN-3 Change Requests => Part 06: TTCN-3 Control Interface
25-03-2010 11:08Ina SchieferdeckerStatusnew => assigned
25-03-2010 11:08Ina SchieferdeckerAssigned To => Ina Schieferdecker
25-03-2010 11:09Ina SchieferdeckerNote Added: 0009303
25-03-2010 11:09Ina SchieferdeckerStatusassigned => resolved
25-03-2010 11:09Ina SchieferdeckerResolutionopen => fixed
25-03-2010 11:09Ina SchieferdeckerFixed in Version => Edition 4.2.1 (not yet published)
25-03-2010 11:09Ina SchieferdeckerTarget Version => Edition 4.2.1 (not yet published)
25-03-2010 15:46Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009303) +
+ Ina Schieferdecker    +
+ 25-03-2010 11:09    +
+ 		+ + + + +
+ See resolution in CR5481
+
+ + diff --git a/docs/mantis/CR5481.md b/docs/mantis/CR5481.md new file mode 100644 index 0000000000000000000000000000000000000000..0c9722b09d8b51248ec689ef3e49499f2e5770ab --- /dev/null +++ b/docs/mantis/CR5481.md @@ -0,0 +1,186 @@ + + + + + + + + + + + + + 0005481: TriAddressType should have an additional attribute 'numberOfBits' - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005481Part 06: TTCN-3 Control InterfaceClarificationpublic24-02-2010 12:5325-03-2010 15:45
ReporterAlexander Lorenz 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.2.1 (published 2010-07)Fixed in Versionv4.2.1 (published 2010-07) 
Clause Reference(s)TCI standard (11.3.2.9), TRI standard (6.3.2.6)
Source (company - Author)Testing Technologies - Alex Lorenz
Summary0005481: TriAddressType should have an additional attribute 'numberOfBits'
DescriptionThis should be handled equivalently to TriMessageType, see issue 0005480.
+
+http://t-ort.etsi.org/view.php?id=5480 [^]
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
duplicate of 0005415closed Ina Schieferdecker Part 05: TTCN-3 Runtime Interface  getNumberOfBits/setNumberOfBits missing in for TriAddressType, TriParameterType and TriExceptionType 
related to 0005479closed Ina Schieferdecker Part 06: TTCN-3 Control Interface parameter 'address' of TriAddressType should be of same type in TCI and TRI 
related to 0005480closed Ina Schieferdecker Part 06: TTCN-3 Control Interface TriMessageType is lacking attribute 'numberOfBits' 
Attached Filesdoc CR5481_v1.doc (26,624) 25-03-2010 11:08
http://oldforge.etsi.org/mantis/file_download.php?file_id=2364&type=bug
doc CR5481_v2.doc (33,280) 25-03-2010 12:57
http://oldforge.etsi.org/mantis/file_download.php?file_id=2367&type=bug
Issue History
Date ModifiedUsernameFieldChange
24-02-2010 12:53Alexander LorenzNew Issue
24-02-2010 12:53Alexander LorenzClause Reference(s) => TCI standard (11.3.2.9), TRI standard (6.3.2.6)
24-02-2010 12:53Alexander LorenzSource (company - Author) => Testing Technologies - Alex Lorenz
24-02-2010 12:56Alexander LorenzNote Added: 0009235
22-03-2010 15:36Gyorgy RethyRelationship addedduplicate of 0005415
25-03-2010 07:16Ina SchieferdeckerRelationship addedrelated to 0005479
25-03-2010 07:18Ina SchieferdeckerRelationship addedrelated to 0005480
25-03-2010 07:40Ina SchieferdeckerProjectTTCN-3 Change Requests => Part 06: TTCN-3 Control Interface
25-03-2010 11:04Ina SchieferdeckerNote Added: 0009302
25-03-2010 11:07Ina SchieferdeckerStatusnew => assigned
25-03-2010 11:07Ina SchieferdeckerAssigned To => Ina Schieferdecker
25-03-2010 11:08Ina SchieferdeckerFile Added: CR5481_v1.doc
25-03-2010 11:08Ina SchieferdeckerAssigned ToIna Schieferdecker => Jacob Wieland - Spirent
25-03-2010 11:08Ina SchieferdeckerResolutionopen => fixed
25-03-2010 11:08Ina SchieferdeckerFixed in Version => Edition 4.2.1 (not yet published)
25-03-2010 11:08Ina SchieferdeckerTarget Version => Edition 4.2.1 (not yet published)
25-03-2010 12:57Jacob Wieland - SpirentFile Added: CR5481_v2.doc
25-03-2010 13:03Jacob Wieland - SpirentNote Added: 0009306
25-03-2010 13:03Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Ina Schieferdecker
25-03-2010 15:45Ina SchieferdeckerNote Added: 0009316
25-03-2010 15:45Ina SchieferdeckerStatusassigned => resolved
25-03-2010 15:45Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009235) +
+ Alexander Lorenz    +
+ 24-02-2010 12:56    +
+ 		+ + + + +
+ The interface in the TRI also needs to be extended.
+
+
+
+ + + + + + + + + + +
+ (0009302) +
+ Ina Schieferdecker    +
+ 25-03-2010 11:04    +
+ 		+ + + + +
+ In the XML mapping
+
+   <xsd:attribute name="len" type="xsd:integer"/>
+
+to be added to
+
+TriParameterType, TriAddressType, TriExceptionType and TriMessageType
+
+
+
+ + + + + + + + + + +
+ (0009306) +
+ Jacob Wieland - Spirent    +
+ 25-03-2010 13:03    +
+ 		+ + + + +
+ changed the len-attribute to paddingBits which is optional with a default value of 0 and should normally only take values between 0 and 7.
+
+The relation between paddingBits and numberOfBits is:
+
+   numberOfBits == (length(val-attribute)/2)*8-paddingBits
+
+In the byte-aligned case (which is probably the normal one), the paddingBits attribute can be left out, causing a smaller amount of XML text.
+
+
+
+ + + + + + + + + + +
+ (0009316) +
+ Ina Schieferdecker    +
+ 25-03-2010 15:45    +
+ 		+ + + + +
+ As proposed.
+
+Added a note:
+
+NOTE: paddingBits is optional with a default value of 0 and should only take values between 0 and 7.
+The relation between paddingBits and numberOfBits is:
+numberOfBits == (length(val-attribute)/2)*8-paddingBits
+In the byte-aligned case which is the typical one, the paddingBits attribute can be left out.
+
+ + diff --git a/docs/mantis/CR5485.md b/docs/mantis/CR5485.md new file mode 100644 index 0000000000000000000000000000000000000000..c99fc0d5029c64fe1f1a79c5ff570130af611d31 --- /dev/null +++ b/docs/mantis/CR5485.md @@ -0,0 +1,238 @@ + + + + + + + + + + + + + 0005485: C++ mapping issues in TRI and TCI specifications (v. 4.1.1) - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 05: TTCN-3 Runtime Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005485Part 05: TTCN-3 Runtime Interface Technicalpublic17-03-2010 11:2625-03-2010 10:05
ReporterAndrus Lehtmets 
Assigned ToIna Schieferdecker 
PriorityhighSeveritymajorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.2.1 (published 2010-07)Fixed in Versionv4.2.1 (published 2010-07) 
Clause Reference(s)Part 6: TTCN-3 Runtime Interface (TRI); Part 5: TTCN-3 Runtime Interface (TRI) , v. 4.1.1
Source (company - Author)Elvior
Summary0005485: C++ mapping issues in TRI and TCI specifications (v. 4.1.1)
DescriptionWe have found several issues in C++ mapping for TRI and TCI (TTCN-3 v.4.1.1), see attached document.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0005489closed Ina Schieferdecker Part 06: TTCN-3 Control Interface TCI C++ mapping fixes 
Attached Filespdf CPP_Issues.pdf (93,137) 17-03-2010 11:26
http://oldforge.etsi.org/mantis/file_download.php?file_id=2339&type=bug
doc CPP_Issues.doc (36,352) 18-03-2010 07:47
http://oldforge.etsi.org/mantis/file_download.php?file_id=2341&type=bug
doc CPP_Mapping_fixes_for_TRI.doc (33,280) 22-03-2010 14:24
http://oldforge.etsi.org/mantis/file_download.php?file_id=2343&type=bug
doc CPP_Mapping_fixes_for_TRI_v2.doc (34,816) 23-03-2010 08:49
http://oldforge.etsi.org/mantis/file_download.php?file_id=2345&type=bug
zip es_20187305v040103.zip (235,926) 25-03-2010 10:04
http://oldforge.etsi.org/mantis/file_download.php?file_id=2360&type=bug
Issue History
Date ModifiedUsernameFieldChange
17-03-2010 11:26Andrus LehtmetsNew Issue
17-03-2010 11:26Andrus LehtmetsFile Added: CPP_Issues.pdf
17-03-2010 11:26Andrus LehtmetsClause Reference(s) => Part 6: TTCN-3 Runtime Interface (TRI); Part 5: TTCN-3 Runtime Interface (TRI) , v. 4.1.1
17-03-2010 11:26Andrus LehtmetsSource (company - Author) => Elvior
18-03-2010 07:47Andrus LehtmetsFile Added: CPP_Issues.doc
22-03-2010 14:24Andrus LehtmetsFile Added: CPP_Mapping_fixes_for_TRI.doc
22-03-2010 14:26Andrus LehtmetsNote Added: 0009242
22-03-2010 14:56Ina SchieferdeckerProjectTTCN-3 Change Requests => Part 05: TTCN-3 Runtime Interface
22-03-2010 14:56Ina SchieferdeckerRelationship addedrelated to 0005489
22-03-2010 15:59Raul AlfonsoNote Added: 0009243
22-03-2010 16:18Gyorgy RethyAssigned To => Ina Schieferdecker
22-03-2010 16:18Gyorgy RethyPrioritynormal => high
22-03-2010 16:18Gyorgy RethyStatusnew => assigned
22-03-2010 16:20Gyorgy RethyTarget Version => Edition 4.2.1 (not yet published)
23-03-2010 08:49Andrus LehtmetsFile Added: CPP_Mapping_fixes_for_TRI_v2.doc
23-03-2010 08:56Andrus LehtmetsNote Added: 0009249
23-03-2010 16:22Raul AlfonsoNote Added: 0009269
24-03-2010 16:37Ina SchieferdeckerNote Added: 0009288
24-03-2010 17:24Ina SchieferdeckerNote Edited: 0009288
24-03-2010 17:25Ina SchieferdeckerFile Added: es_20187305v040103.zip
24-03-2010 17:25Ina SchieferdeckerAssigned ToIna Schieferdecker => Gyorgy Rethy
24-03-2010 17:25Ina SchieferdeckerStatusassigned => resolved
24-03-2010 17:25Ina SchieferdeckerResolutionopen => fixed
24-03-2010 17:25Ina SchieferdeckerFixed in Version => Edition 4.2.1 (not yet published)
24-03-2010 17:29Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
24-03-2010 17:29Gyorgy RethyStatusresolved => assigned
25-03-2010 09:54Ina SchieferdeckerFile Deleted: es_20187305v040103.zip
25-03-2010 09:55Ina SchieferdeckerFile Added: es_20187305v040103.zip
25-03-2010 10:03Ina SchieferdeckerFile Deleted: es_20187305v040103.zip
25-03-2010 10:04Ina SchieferdeckerFile Added: es_20187305v040103.zip
25-03-2010 10:04Ina SchieferdeckerStatusassigned => resolved
25-03-2010 10:05Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009242) +
+ Andrus Lehtmets    +
+ 22-03-2010 14:26    +
+ 		+ + + + +
+ CPP_Mapping_fixes_for_TRI.doc contains fixes with refers to existing chapters v.4.2.1 draft.
+
+
+
+ + + + + + + + + + +
+ (0009243) +
+ Raul Alfonso    +
+ 22-03-2010 15:59    +
+ 		+ + + + +
+ MTP is disagreed with the points 2.6 (TriDataFactory) and 2.8.3 (remove getTId methods).
+
+2.6.- We think TriDataFactory is not necessary and we don't understand how we have to use it.
+
+2.8.3.- Document
+  virtual const Tinteger getTId() const =0
+but not remove.
+
+
+
+ + + + + + + + + + +
+ (0009249) +
+ Andrus Lehtmets    +
+ 23-03-2010 08:56    +
+ 		+ + + + +
+ Uploaded new version of document.
+2.3 virtual const Tinteger getTId() const =0 - my mistake added description of the method
+
+2.6.TriDataFactory
+We still want it, because it makes it possible to have vendor implementation independent object instantiation.
+How to use it? Here are some examples:
+
+A static TriDataFactory factory instance can be accessed by using the standard "TriDataFactory" identifier:
+Java:
+TriDataFactory.getInstance()
+
+C++:
+TriDataFactory::getInstance()
+
+The vendor specific TRI object implementation instances can ge created using the stadard methods:
+
+Java:
+TriDataFactory.getInstance().createTriMessage();
+
+C++:
+TriDataFactory::getInstance().createTriMessage();
+
+
+
+ + + + + + + + + + +
+ (0009269) +
+ Raul Alfonso    +
+ 23-03-2010 16:22    +
+ 		+ + + + +
+ We don't understand which entity of TTCN3 test system take the responsability to implement TriDataFactory. For example, in the TriCommunicationTE could be a method to get the instance of TriDataFactory, so the TE (and tool vendor) has to implement the TriDataFactory (as TciType, newInstance method and getTypeForName method of CD-Required).
+TciType, newInstance and getTypeForName has a formal specification so there is a mapping in C, Java, C++ ..., but TriDataFactory doesn't have that specification and we don't understand what is mapping.
+
+
+
+ + + + + + + + + + +
+ (0009288) +
+ Ina Schieferdecker    +
+ 24-03-2010 16:37    +
(edited on: 24-03-2010 17:24)
+ 		+ + + + +
+ The STF discussed that the TriDataFactory is as such not part of the TRI interface. It is not to be included.
+
+The other things implemented as proposed.
+
+In addition, equals changed to operator== as it is done in the TCI mapping.
+
+TriParameterPassingMode, TriStatus defined as enum.
+
+According to 2.8 also removed
+virtual const std::vector< const TriParameter * > & getParameters () const =0;
+virtual const std::vector< const TriPortId * > & getPortIds () const =0;
+
+
+
+ + diff --git a/docs/mantis/CR5486.md b/docs/mantis/CR5486.md new file mode 100644 index 0000000000000000000000000000000000000000..b5ac5fabf7428dc217066a8aec7eda7330b794d2 --- /dev/null +++ b/docs/mantis/CR5486.md @@ -0,0 +1,82 @@ + + + + + + + + + + + + + 0005486: BNF errors in return statement - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005486Part 01: TTCN-3 Core LanguageTechnicalpublic17-03-2010 16:2823-03-2010 09:23
ReporterGyorgy Rethy 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.2.1 (published 2010-07)Fixed in Versionv4.2.1 (published 2010-07) 
Clause Reference(s)A.1.6.1.3
Source (company - Author)L.M. Ericsson
Summary0005486: BNF errors in return statement
DescriptionThere are two errros in the current BNF (see below):
+- return statement with no return value/template is allowed
+- in-line template is not allowed
+
+Current BNF:
+556. ReturnStatement ::= ReturnKeyword [Expression | TemplateBody]
+/* STATIC SEMANTICS - Expression shall evaluate to a value of a type compatible with the return type for functions returning a value. It shall evaluate to a value, template (literal or template instance), or a matching mechanism compatible with the return type for functions returning a template. */
+
+Proposed:
+556. ReturnStatement ::= ReturnKeyword ( Expression | InLineTemplate )
+// change 1 ^------------^
+// change 2 ^ ^
+/* STATIC SEMANTICS - Expression shall evaluate to a value of a type compatible with the return type for functions returning a value. It shall evaluate to a value, template (literal or template instance), or a matching mechanism compatible with the return type for functions returning a template. */
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
17-03-2010 16:28Gyorgy RethyNew Issue
17-03-2010 16:28Gyorgy RethyClause Reference(s) => A.1.6.1.3
17-03-2010 16:28Gyorgy RethySource (company - Author) => L.M. Ericsson
22-03-2010 15:32Gyorgy RethyProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
22-03-2010 15:32Gyorgy RethyAssigned To => Ina Schieferdecker
22-03-2010 15:32Gyorgy RethyStatusnew => assigned
22-03-2010 15:32Gyorgy RethyTarget Version => Edition 4.2.1 (not yet published)
23-03-2010 09:17Ina SchieferdeckerNote Added: 0009251
23-03-2010 09:20Ina SchieferdeckerNote Edited: 0009251
23-03-2010 09:22Ina SchieferdeckerStatusassigned => resolved
23-03-2010 09:22Ina SchieferdeckerResolutionopen => fixed
23-03-2010 09:22Ina SchieferdeckerFixed in Version => Edition 4.2.1 (not yet published)
23-03-2010 09:23Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009251) +
+ Ina Schieferdecker    +
+ 23-03-2010 09:17    +
(edited on: 23-03-2010 09:20)
+ 		+ + + + +
+ Return without return value is needed to escape from a function having no return type defined.
+
+Hence, grammar rule only to be changed to
+
+556. ReturnStatement ::= ReturnKeyword [ Expression | InLineTemplate ]
+
+
+
+ + diff --git a/docs/mantis/CR5487.md b/docs/mantis/CR5487.md new file mode 100644 index 0000000000000000000000000000000000000000..a067a294cb6e829f65b0323422c275bc7ed78ba7 --- /dev/null +++ b/docs/mantis/CR5487.md @@ -0,0 +1,185 @@ + + + + + + + + + + + + + 0005487: Extend ispresent() to all templates - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005487Part 01: TTCN-3 Core LanguageNew Featurepublic17-03-2010 17:4225-03-2010 21:20
ReporterGyorgy Rethy 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityfeatureReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.1.1 (published 2009-06) 
Target Versionv4.3.1 (published 2011-06)Fixed in Versionv4.2.1 (published 2010-07) 
Clause Reference(s)C.31
Source (company - Author)L.M. Ericsson
Summary0005487: Extend ispresent() to all templates
DescriptionCurrently ispresent is allowed for record and set FIELDs only. To increase the usability of this predefined function it should be allowed to templates of any type, i.e. return false if the template is "omit", true otherwise except "*" or xyz ifpresent.
+
+In the two latter cases ispresent shall cause an error. This could be re-discussed, either defining other means allowing checking if a template or template field is "*" or ~ ifpresent or define a false or true behaviour of ifpresent().
+
+The issue popped up during a TTCN-3 library development; use case:
+public function f_omitPar(
+  in template ASP_TelnetPortParameters pl_par := omit,
+) runs on CT {
+  // It should be checked here if a value/matching is passed in
+  // or the default value is implicitly assigned
+  if (not ispresent(pl_par)){
+  // ^ ^ but this is not allowed
+    log("Warning");
+  }
+}
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR5487_v1.doc (39,936) 25-03-2010 14:18
http://oldforge.etsi.org/mantis/file_download.php?file_id=2368&type=bug
doc CR5487_v2.doc (44,032) 25-03-2010 14:47
http://oldforge.etsi.org/mantis/file_download.php?file_id=2371&type=bug
Issue History
Date ModifiedUsernameFieldChange
17-03-2010 17:42Gyorgy RethyNew Issue
17-03-2010 17:42Gyorgy RethyStatusnew => assigned
17-03-2010 17:42Gyorgy RethyAssigned To => Ina Schieferdecker
17-03-2010 17:42Gyorgy RethyClause Reference(s) => C.31
17-03-2010 17:42Gyorgy RethySource (company - Author) => L.M. Ericsson
18-03-2010 11:51Gyorgy RethyAssigned ToIna Schieferdecker =>
18-03-2010 11:51Gyorgy RethyStatusassigned => new
19-03-2010 07:42Gyorgy RethyDescription Updated
22-03-2010 16:24Gyorgy RethySeverityminor => feature
22-03-2010 16:24Gyorgy RethyTarget Version => Edition 4.3.1 (not yet published)
23-03-2010 12:35Gyorgy RethyAssigned To => Jacob Wieland - Spirent
23-03-2010 12:35Gyorgy RethyStatusnew => assigned
24-03-2010 08:38Jacob Wieland - SpirentNote Added: 0009272
25-03-2010 09:16Gyorgy RethyNote Added: 0009296
25-03-2010 09:16Gyorgy RethyNote Added: 0009297
25-03-2010 09:19Gyorgy RethyNote Deleted: 0009297
25-03-2010 14:18Jacob Wieland - SpirentFile Added: CR5487_v1.doc
25-03-2010 14:18Jacob Wieland - SpirentNote Added: 0009307
25-03-2010 14:19Jacob Wieland - SpirentStatusassigned => feedback
25-03-2010 14:25Gyorgy RethyAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
25-03-2010 14:25Gyorgy RethyStatusfeedback => assigned
25-03-2010 14:47Gyorgy RethyFile Added: CR5487_v2.doc
25-03-2010 14:49Gyorgy RethyNote Added: 0009309
25-03-2010 14:49Gyorgy RethyAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
25-03-2010 14:58Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Ina Schieferdecker
25-03-2010 15:28Gyorgy RethyStatusassigned => resolved
25-03-2010 15:28Gyorgy RethyResolutionopen => fixed
25-03-2010 21:20Ina SchieferdeckerStatusresolved => closed
25-03-2010 21:20Ina SchieferdeckerFixed in Version => Edition 4.2.1 (not yet published)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009272) +
+ Jacob Wieland - Spirent    +
+ 24-03-2010 08:38    +
+ 		+ + + + +
+ For the simple case of deciding whether or not a template parameter can be assigned to a non-optional template field, ispresent() should be changed that it works on any template and the semantics should be that it returns true in the same cases as if the template paramter would be declared with the (present) restriction. I.e. if you have template(present) x, then ifpresent(x) always returns true. For all templates which cannot be used as template(present), ifpresent() would return false.
+
+This would harmonize the ispresent() function and the present restriction, so it is an easily understandable semantics.
+
+If more powerful querying mechanisms for the contents of templates are really needed in any real-world scenarios for goals which cannot be reached by other existing means, these should be presented so that we can come up with the necessary solutions for these problems.
+
+
+
+ + + + + + + + + + +
+ (0009296) +
+ Gyorgy Rethy    +
+ 25-03-2010 09:16    +
+ 		+ + + + +
+ Discussion on 24th March:
+- Agreed: extend the isptresent() as proposed by Jacob in this CR.
+- For a more generic solution to check template/template field content a convincing use case is needed. Therefore this CR will be closed when the text to extend ispresent() is agreed and implemented and for any more generic feature a new CR would be needed.
+
+
+
+ + + + + + + + + + +
+ (0009307) +
+ Jacob Wieland - Spirent    +
+ 25-03-2010 14:18    +
+ 		+ + + + +
+ uploaded CR proposal
+
+
+
+ + + + + + + + + + +
+ (0009309) +
+ Gyorgy Rethy    +
+ 25-03-2010 14:49    +
+ 		+ + + + +
+ CR5487_v2.doc: only editorial amendments, no technical change. If you agree, (first) assign to Ina, (secondly) set state to Resolved (in Resolved state CRs cannot be assigned to another person)
+
+ + diff --git a/docs/mantis/CR5489.md b/docs/mantis/CR5489.md new file mode 100644 index 0000000000000000000000000000000000000000..24fccd1ad9d7f10b133fde9617b5a7d88507a600 --- /dev/null +++ b/docs/mantis/CR5489.md @@ -0,0 +1,369 @@ + + + + + + + + + + + + + 0005489: TCI C++ mapping fixes - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005489Part 06: TTCN-3 Control InterfaceTechnicalpublic22-03-2010 14:3025-03-2010 10:54
ReporterAndrus Lehtmets 
Assigned ToIna Schieferdecker 
PriorityhighSeveritymajorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.2.1 (published 2010-07)Fixed in Versionv4.2.1 (published 2010-07) 
Clause Reference(s)TCI C++ mapping, part 6
Source (company - Author) Elvior
Summary0005489: TCI C++ mapping fixes
DescriptionTCI C++ mapping fixes separated from TRI ones. Fixes are agreed with MTP and INRIA.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0005485closed Ina Schieferdecker Part 05: TTCN-3 Runtime Interface  C++ mapping issues in TRI and TCI specifications (v. 4.1.1) 
related to 0005885closed Ina Schieferdecker Part 06: TTCN-3 Control Interface Inconsistency in mapping UniversalCharstringValue (implies platform dependency) 
Attached Filesdoc CPP_Mapping_Fixes_for_TCI.doc (26,624) 22-03-2010 14:30
http://oldforge.etsi.org/mantis/file_download.php?file_id=2344&type=bug
zip es_20187306v040103.zip (1,360,255) 25-03-2010 10:53
http://oldforge.etsi.org/mantis/file_download.php?file_id=2362&type=bug
Issue History
Date ModifiedUsernameFieldChange
22-03-2010 14:30Andrus LehtmetsNew Issue
22-03-2010 14:30Andrus LehtmetsFile Added: CPP_Mapping_Fixes_for_TCI.doc
22-03-2010 14:30Andrus LehtmetsClause Reference(s) => TCI C++ mapping, part 6
22-03-2010 14:30Andrus LehtmetsSource (company - Author) => Elvior
22-03-2010 14:56Ina SchieferdeckerRelationship addedrelated to 0005485
22-03-2010 15:50Ina SchieferdeckerProjectTTCN-3 Change Requests => Part 06: TTCN-3 Control Interface
22-03-2010 15:50Ina SchieferdeckerStatusnew => assigned
22-03-2010 15:50Ina SchieferdeckerAssigned To => Ina Schieferdecker
22-03-2010 15:59Raul AlfonsoNote Added: 0009244
22-03-2010 16:18Gyorgy RethyPrioritynormal => high
22-03-2010 16:18Gyorgy RethyTarget Version => Edition 4.2.1 (not yet published)
23-03-2010 08:04Andrus LehtmetsNote Added: 0009247
23-03-2010 08:07Ina SchieferdeckerNote Added: 0009248
23-03-2010 11:03Raul AlfonsoNote Added: 0009253
23-03-2010 11:46Andrus LehtmetsNote Added: 0009254
23-03-2010 12:58Ina SchieferdeckerNote Added: 0009260
23-03-2010 16:22Ina SchieferdeckerNote Added: 0009268
23-03-2010 16:37Ina SchieferdeckerFile Added: es_20187306v040103.zip
24-03-2010 16:15Ina SchieferdeckerNote Edited: 0009248
24-03-2010 16:15Ina SchieferdeckerNote Edited: 0009260
24-03-2010 16:16Ina SchieferdeckerNote Edited: 0009260
24-03-2010 16:16Ina SchieferdeckerNote Added: 0009285
24-03-2010 16:18Ina SchieferdeckerFile Deleted: es_20187306v040103.zip
24-03-2010 16:19Ina SchieferdeckerFile Added: es_20187306v040103.zip
24-03-2010 16:20Ina SchieferdeckerAssigned ToIna Schieferdecker => Gyorgy Rethy
24-03-2010 16:20Ina SchieferdeckerStatusassigned => resolved
24-03-2010 16:20Ina SchieferdeckerResolutionopen => fixed
24-03-2010 16:20Ina SchieferdeckerFixed in Version => Edition 4.2.1 (not yet published)
24-03-2010 16:48Ina SchieferdeckerFile Deleted: es_20187306v040103.zip
24-03-2010 16:48Ina SchieferdeckerFile Added: es_20187306v040103.zip
25-03-2010 10:53Ina SchieferdeckerFile Deleted: es_20187306v040103.zip
25-03-2010 10:53Ina SchieferdeckerFile Added: es_20187306v040103.zip
25-03-2010 10:54Ina SchieferdeckerAssigned ToGyorgy Rethy => Ina Schieferdecker
25-03-2010 10:54Ina SchieferdeckerStatusresolved => closed
25-05-2011 18:04Ina SchieferdeckerRelationship addedrelated to 0005885
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009244) +
+ Raul Alfonso    +
+ 22-03-2010 15:59    +
+ 		+ + + + +
+ MTP is disagreed with the point 2.3 of the document. For us,
+
+  typedef wchar_t TuniversalChar
+
+is OK.
+
+
+
+ + + + + + + + + + +
+ (0009247) +
+ Andrus Lehtmets    +
+ 23-03-2010 08:04    +
+ 		+ + + + +
+ "The width of wchar_t is compiler-specific and can be as small as 8 bits. Consequently, programs that need to be portable across any C or C++ compiler should not use wchar_t for storing Unicode text." (http://en.wikipedia.org/wiki/Wide_character [^])
+
+TuniversalChar type should not be derived from wchart_t, because the size of individual characters of TTCN-3 universal charstrings is 4 bytes. Therefore TuniversalChar should be derived from 4 bytes instead:
+
+either like in C mapping
+Universal Char typedef unsigned char TciUCValue[4]
+or like Elvior proposed:
+typedef unsigned long TuniversalChar
+
+
+
+ + + + + + + + + + +
+ (0009248) +
+ Ina Schieferdecker    +
+ 23-03-2010 08:07    +
(edited on: 24-03-2010 16:15)
+ 		+ + + + +
+ Single characters are miscellaneous types for that purpose only. Still, single characters are treated differently in the mappings:
+ 
+Java
+    Tchar --> char
+    Tuniversalchar --> int
+ 
+C
+    Tchar --> char
+    Tuniversalchar --> TciUCValue
+ 
+C++
+    Tchar --> char
+    Tuniversalchar --> wchar_t
+
+The simplest seems to be to agree on integer types (32 bits are enough).
+
+
+
+
+
+ + + + + + + + + + +
+ (0009253) +
+ Raul Alfonso    +
+ 23-03-2010 11:03    +
+ 		+ + + + +
+ wchar_t shall be as wide as necessary to hold the largest character in the code sets of the locales that an implementation supports. If one platform doesn't support all characters of ISO/IEC 10646, wchar_t will not be able to handle all characters, but I think it is a platform (or c++ compiler) restriction, not a problem in C++ mapping.
+wchar_t was introduced to represent wide char and I don't see any reason to not use this type.
+For example, Tinteger can not work with "all integer" and it is not a problem
+
+
+
+ + + + + + + + + + +
+ (0009254) +
+ Andrus Lehtmets    +
+ 23-03-2010 11:46    +
+ 		+ + + + +
+ Elvior is strongly against using wchar_t. We support Ina's suggestion to use 32 bits integer types there.
+more information about problems and sizes of wchar_t when using different compilers could be found at http://hristov.com/oblog/blog/post/2009/04/07/of-wchar_t/ [^]
+
+
+
+ + + + + + + + + + +
+ (0009260) +
+ Ina Schieferdecker    +
+ 23-03-2010 12:58    +
(edited on: 24-03-2010 16:16)
+ 		+ + + + +
+ This would mean
+
+Java
+    Tchar --> char
+    Tuniversalchar --> int
+ 
+C
+    Tchar --> char
+    Tuniversalchar --> long
+ 
+C++
+    Tchar --> char
+    Tuniversalchar --> long
+
+Please let the STF know if that is ok.
+
+
+
+
+
+ + + + + + + + + + +
+ (0009268) +
+ Ina Schieferdecker    +
+ 23-03-2010 16:22    +
+ 		+ + + + +
+ Implemented with the following changes:
+
+- AddressType is not a class template but a class
+
+- using operator== instead of equals
+
+- removed the explicitly assigned constants in 10.5.2.14 TciTypeClass as that is still under discussion
+
+- missing semicolons were already added
+
+- change to the mapping of universal character (in chapter 10.5.1) still open as it is under discussion
+
+
+
+ + + + + + + + + + +
+ (0009285) +
+ Ina Schieferdecker    +
+ 24-03-2010 16:16    +
+ 		+ + + + +
+ Agreement was finally to go for
+
+Java
+    Tchar --> char
+    Tuniversalchar --> int
+ 
+C
+    Tchar --> char
+    Tuniversalchar --> wchar_t
+ 
+C++
+    Tchar --> char
+    Tuniversalchar --> wchar_t
+
+ + diff --git a/docs/mantis/CR5490.md b/docs/mantis/CR5490.md new file mode 100644 index 0000000000000000000000000000000000000000..41106b7f2b258e13444d61a4ecf7a20ee4086569 --- /dev/null +++ b/docs/mantis/CR5490.md @@ -0,0 +1,425 @@ + + + + + + + + + + + + + 0005490: Actual Parameter Lists for Templates with Formal Parameter List should be mandatory - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005490Part 01: TTCN-3 Core LanguageClarificationpublic23-03-2010 08:4230-04-2010 10:48
ReporterJacob Wieland - Spirent 
Assigned ToIna Schieferdecker 
PriorityhighSeveritymajorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.2.1 (published 2010-07)Fixed in Versionv4.2.1 (published 2010-07) 
Clause Reference(s)5.4
Source (company - Author)Testing Technologies
Summary0005490: Actual Parameter Lists for Templates with Formal Parameter List should be mandatory
DescriptionTemplates are the only entities which can be defined with or without a formal parameter list. Thus, the BNF allows template instances with and without actual parameter lists.
+
+It should be clarified that a template instance of a template with a formal parameter list NEEDS an actual parameter list, even if all formal parameters have a default value (i.e. if the parameter list can remain empty).
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Fileszip Resolution-Jens-CR5490.zip (30,708) 25-03-2010 12:22
http://oldforge.etsi.org/mantis/file_download.php?file_id=2366&type=bug
Issue History
Date ModifiedUsernameFieldChange
23-03-2010 08:42Jacob Wieland - SpirentNew Issue
23-03-2010 08:42Jacob Wieland - SpirentClause Reference(s) => 5.4
23-03-2010 08:42Jacob Wieland - SpirentSource (company - Author) => Testing Technologies
23-03-2010 12:34Gyorgy RethyNote Added: 0009255
23-03-2010 12:34Gyorgy RethyAssigned To => Jens Grabowski
23-03-2010 12:34Gyorgy RethyStatusnew => assigned
23-03-2010 12:34Gyorgy RethyTarget Version => Edition 4.2.1 (not yet published)
23-03-2010 12:34Gyorgy RethyNote Edited: 0009255
23-03-2010 14:19Gyorgy RethyPrioritynormal => high
23-03-2010 15:31Jacob Wieland - SpirentNote Added: 0009264
25-03-2010 11:35Jens GrabowskiNote Added: 0009305
25-03-2010 12:22Jens GrabowskiFile Added: Resolution-Jens-CR5490.zip
25-03-2010 12:24Jens GrabowskiAssigned ToJens Grabowski => Ina Schieferdecker
25-03-2010 15:11Jacob Wieland - SpirentNote Added: 0009312
25-03-2010 15:21Gyorgy RethyNote Added: 0009313
25-03-2010 15:27Gyorgy RethyStatusassigned => resolved
25-03-2010 15:27Gyorgy RethyResolutionopen => fixed
25-03-2010 15:57Ina SchieferdeckerNote Added: 0009317
25-03-2010 15:57Ina SchieferdeckerStatusresolved => closed
25-03-2010 15:57Ina SchieferdeckerFixed in Version => Edition 4.2.1 (not yet published)
11-04-2010 15:42Ina SchieferdeckerStatusclosed => feedback
11-04-2010 15:42Ina SchieferdeckerResolutionfixed => reopened
11-04-2010 15:42Ina SchieferdeckerNote Added: 0009327
14-04-2010 09:10Ina SchieferdeckerNote Added: 0009330
15-04-2010 16:53Gyorgy RethyNote Added: 0009331
15-04-2010 16:54Gyorgy RethyNote Edited: 0009331
30-04-2010 10:47Ina SchieferdeckerNote Added: 0009345
30-04-2010 10:48Ina SchieferdeckerStatusfeedback => closed
30-04-2010 10:48Ina SchieferdeckerResolutionreopened => fixed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009255) +
+ Gyorgy Rethy    +
+ 23-03-2010 12:34    +
+ 		+ + + + +
+ In the proposed solution take into account also the original purpose of formal paramaters with default values: make a library code extendable without the need to touch the library-user code.
+
+
+
+
+
+ + + + + + + + + + +
+ (0009264) +
+ Jacob Wieland - Spirent    +
+ 23-03-2010 15:31    +
+ 		+ + + + +
+ If the ibrary is updated, and a parameter-less template shall be parameterized with formal parameters which all have default values (which is the only case in which no updating of the using code is necessary),
+the following simple work-around works without change to existing using code:
+
+template T <oldName> := <oldRHS>
+
+is changed to:
+
+template T <newName>(<new formal parameters with default values>) := <newRHS>
+
+template T <oldName> := <newName>(); // <newName>() must resolve to <oldRHS>
+
+That way, the requirement that all entities with formal parameters are also instantiated with actual parameters is met and the requirement that the template-using code is not broken also.
+
+Since the solution is simple, an unnecessary complication of the type-inference algorithm and therefore additional unnecessary workload for the static checking can be avoided. The only drawback/burden for the implementor of the library is the introduction of a new name (which, given that the new template has a new semantics, is probably a good idea anyway, otherwise, it could lead to confusion for the user of the library who does not expect the semantics of the used entities to change from one version to another).
+
+
+
+ + + + + + + + + + +
+ (0009305) +
+ Jens Grabowski    +
+ 25-03-2010 11:35    +
+ 		+ + + + +
+ Unfortunately, this ambiguity of the standard has already extensively used by TTCN-3 users (e.g., ETSI STF 160). Therefore, mandatory empty brackets for instances of parameterized templates when no actual parameters are provided (i.e. all formal parameters use their default values) lead to problems. The proposed workaround was also not accepted.
+
+As a consequence, the STF decided to make the empty brackets for the case above explicitly optional. A corresponding sentence will be added in the standard. See resolution in the attachment.
+
+
+
+ + + + + + + + + + +
+ (0009312) +
+ Jacob Wieland - Spirent    +
+ 25-03-2010 15:11    +
+ 		+ + + + +
+ I would change the sentence to:
+
+The empty brackets for instances of parameterized templates that have only parameters with default values are optional when no actual parameters are provided, i.e. all formal parameters use their default values.
+
+
+
+ + + + + + + + + + +
+ (0009313) +
+ Gyorgy Rethy    +
+ 25-03-2010 15:21    +
+ 		+ + + + +
+ I propose to add the sentence to the actual parameters clause instead of the formal parameter clause:
+- it has, in fact, not much to do with the formalparameters
+- everyone will search it in the actual parameter lists clause (me for sure after a few months)
+
+
+
+ + + + + + + + + + +
+ (0009317) +
+ Ina Schieferdecker    +
+ 25-03-2010 15:57    +
+ 		+ + + + +
+ Put into 5.4.2 Actual parameters
+
+
+
+ + + + + + + + + + +
+ (0009327) +
+ Ina Schieferdecker    +
+ 11-04-2010 15:42    +
+ 		+ + + + +
+ Andrus Lehmets, Elvior:
+
+we found that there is still little mismatch in latest core language specification chapter 5.4.2 and BNF.
+ 
+5.4.2 says
+The empty brackets for instances of parameterized templates that have only parameters with default values are optional when no actual parameters are provided, i.e. all formal parameters use their default values.
+ 
+this means that you can use template with parameters without brackets or template with empty brackets ().
+ 
+But BNF does not allow empty brackets for templates:
+ 
+TemplateActualParList ::= "(" ( TemplateActualPar {"," TemplateActualPar}) |
+
+                               ( TemplateActualParAssignment {"," TemplateActualParAssignment })")"
+
+ 
+
+ 
+
+And if there is mismatch between explanation and BNF, then BNF is the correct one.
+
+ 
+
+ 
+
+BR,
+
+Andrus
+
+
+
+ + + + + + + + + + +
+ (0009330) +
+ Ina Schieferdecker    +
+ 14-04-2010 09:10    +
+ 		+ + + + +
+ BNF rule 157 has to be changed to
+
+TemplateActualParList ::=
+"(" [( TemplateActualPar {"," TemplateActualPar}) |
+     ( TemplateActualParAssignment {"," TemplateActualParAssignment })] ")"
+
+
+
+ + + + + + + + + + +
+ (0009331) +
+ Gyorgy Rethy    +
+ 15-04-2010 16:53    +
(edited on: 15-04-2010 16:54)
+ 		+ + + + +
+ Elvior has ACK-ed that he agrees with the proposed BNF solution on the MTS mailing list, therefore if no comment is received untill 19th April, I propose to implement the proposed BNF change, close the CR, upload an updated version to MTS's drafts area and notify MTS-GEN about the availability of the new version.
+
+
+
+
+
+ + + + + + + + + + +
+ (0009345) +
+ Ina Schieferdecker    +
+ 30-04-2010 10:47    +
+ 		+ + + + +
+ Implemented in V.4.2.1 as agreed in AbC
+
+ + diff --git a/docs/mantis/CR5492.md b/docs/mantis/CR5492.md new file mode 100644 index 0000000000000000000000000000000000000000..b1ad0789c7ba471f9d884df180666ece3da89a45 --- /dev/null +++ b/docs/mantis/CR5492.md @@ -0,0 +1,142 @@ + + + + + + + + + + + + + 0005492: Package BNF Corrections - Adv. Param - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Advanced Parametrization (ES 202 784)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005492Ext Pack: Advanced Parametrization (ES 202 784)Editorialpublic23-03-2010 16:5813-12-2010 13:32
ReporterBenjamin Zeiss 
Assigned To 
PriorityhighSeveritytrivialReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv1.2.1 (published 2011-05)Fixed in Versionv1.2.1 (published 2011-05) 
TS version
Clause Reference(s)n/a
Source (company - Author)     
Summary0005492: Package BNF Corrections - Adv. Param
DescriptionPackage Advanced Parameterization v1.1.1:
+------------------------------------------
+-2. FormalTypePar ::= [ InParKeyword ] [ Type | TypeKeyword ] TypeParIdentifier [ ":=" Type ]
++2. FormalTypePar ::= [ InParKeyword ] [ Type | TypeDefKeyword ] TypeParIdentifier [ ":=" Type ]
+
+TypeKeyword -> TypeDefKeyword
+
+-107 StructFieldRef ::= StructFieldIdentifier| PredefinedType | ReferencedType
++107. StructFieldRef ::= StructFieldIdentifier| PredefinedType | ReferencedType
+
+The "." is missing after the rule number.
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
parent of 0005493closed Jens Grabowski Ext Pack: Behaviour Types (ES 202 785) Package BNF Corrections - Beh. types 
parent of 0005494closed  Ext Pack: Config & Deployment Support (ES 202 781) Package BNF Corrections - Conf & Depl. 
Attached Fileszip Resolution-Jens-CR5492.zip (69,585) 25-03-2010 10:05
http://oldforge.etsi.org/mantis/file_download.php?file_id=2361&type=bug
Issue History
Date ModifiedUsernameFieldChange
23-03-2010 16:58Benjamin ZeissNew Issue
23-03-2010 16:58Benjamin ZeissClause Reference(s) => n/a
23-03-2010 16:58Benjamin ZeissSource (company - Author) =>
24-03-2010 11:21Gyorgy RethyIssue cloned: 0005493
24-03-2010 11:21Gyorgy RethyRelationship addedparent of 0005493
24-03-2010 11:22Gyorgy RethyPrioritylow => high
24-03-2010 11:24Gyorgy RethyIssue cloned: 0005494
24-03-2010 11:24Gyorgy RethyRelationship addedparent of 0005494
24-03-2010 11:24Gyorgy RethySummaryPackage BNF Corrections => Package BNF Corrections - Adv. Param
24-03-2010 11:24Gyorgy RethyDescription Updated
24-03-2010 16:54Gyorgy RethyProjectTTCN-3 Change Requests => Ext Pack: Advanced Parametrization (ES 202 784)
25-03-2010 10:02Jens GrabowskiNote Added: 0009299
25-03-2010 10:05Jens GrabowskiFile Added: Resolution-Jens-CR5492.zip
25-03-2010 11:03Jens GrabowskiStatusnew => closed
25-03-2010 11:03Jens GrabowskiResolutionopen => fixed
13-12-2010 13:32Gyorgy RethyStatusclosed => feedback
13-12-2010 13:32Gyorgy RethyResolutionfixed => reopened
13-12-2010 13:32Gyorgy RethyNote Added: 0009954
13-12-2010 13:32Gyorgy RethyNote Added: 0009955
13-12-2010 13:32Gyorgy RethyStatusfeedback => closed
13-12-2010 13:32Gyorgy RethyResolutionreopened => fixed
13-12-2010 13:32Gyorgy RethyFixed in Version => v1.2.1
13-12-2010 13:32Gyorgy RethyTarget Version => v1.2.1
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009299) +
+ Jens Grabowski    +
+ 25-03-2010 10:02    +
+ 		+ + + + +
+ Resolved as proposed in the description.
+
+
+
+ + + + + + + + + + +
+ (0009954) +
+ Gyorgy Rethy    +
+ 13-12-2010 13:32    +
+ 		+ + + + +
+ Added target version and fixed in version to CR.
+
+
+
+ + + + + + + + + + +
+ (0009955) +
+ Gyorgy Rethy    +
+ 13-12-2010 13:32    +
+ 		+ + + + +
+ Target version and fixed in version are added to CR.
+
+ + diff --git a/docs/mantis/CR5493.md b/docs/mantis/CR5493.md new file mode 100644 index 0000000000000000000000000000000000000000..cad96591638c133cf3b5564048346d217877383f --- /dev/null +++ b/docs/mantis/CR5493.md @@ -0,0 +1,157 @@ + + + + + + + + + + + + + 0005493: Package BNF Corrections - Beh. types - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Behaviour Types (ES 202 785)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005493Ext Pack: Behaviour Types (ES 202 785)Editorialpublic24-03-2010 11:2113-12-2010 13:37
ReporterGyorgy Rethy 
Assigned ToJens Grabowski 
PriorityhighSeveritytrivialReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv1.2.1 (published 2011-05)Fixed in Versionv1.2.1 (published 2011-05) 
Clause Reference(s)n/a
Source (company - Author)     
Summary0005493: Package BNF Corrections - Beh. types
DescriptionPackage Behaviour Types v1.1.1:
+--------------------------------
+1. BehaviourDef ::= ( AltstepKeyword BehaviourTypeIdentifier [FormalTypeParList]
+...
+
+The rule "FormalTypeParList" does not exist, neither in the package bnf nor the core language bnf. It is referenced three times in the rule BehaviourDef.
+
+-167. RunsOnSpec ::= RunsKeyword OnKeyword ( ComponentType | SelfKeyword )
++167. RunsOnSpec ::= RunsKeyword OnKeyword ( ComponentType | SelfOp )
+
+SelfKeyword -> SelfOp
+
+-200. TestcaseInstance ::= ExecuteKeyword "(" ( TestCaseRef "(" [TestcaseActualParList] ")" ) |
++200. TestcaseInstance ::= ExecuteKeyword "(" ( TestcaseRef "(" [TestcaseActualParList] ")" ) |
+
+TestCaseRef -> TestcaseRef
+
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
child of 0005492closed  Ext Pack: Advanced Parametrization (ES 202 784) Package BNF Corrections - Adv. Param 
Attached Fileszip Resolution-Jens-CR5493.zip (428,805) 25-03-2010 10:59
http://oldforge.etsi.org/mantis/file_download.php?file_id=2363&type=bug
Issue History
Date ModifiedUsernameFieldChange
24-03-2010 11:21Gyorgy RethyNew Issue
24-03-2010 11:21Gyorgy RethyClause Reference(s) => n/a
24-03-2010 11:21Gyorgy RethySource (company - Author) =>
24-03-2010 11:21Gyorgy RethyIssue generated from: 0005492
24-03-2010 11:21Gyorgy RethyRelationship addedchild of 0005492
24-03-2010 11:25Gyorgy RethySummaryPackage BNF Corrections => Package BNF Corrections - Beh. types
24-03-2010 11:25Gyorgy RethyDescription Updated
24-03-2010 17:01Gyorgy RethyAssigned To => Jens Grabowski
24-03-2010 17:01Gyorgy RethyStatusnew => assigned
24-03-2010 17:01Gyorgy RethyProjectTTCN-3 Change Requests => Ext Pack: Behaviour Types (ES 202 785)
25-03-2010 10:27Benjamin ZeissNote Added: 0009300
25-03-2010 10:59Jens GrabowskiNote Added: 0009301
25-03-2010 10:59Jens GrabowskiFile Added: Resolution-Jens-CR5493.zip
25-03-2010 11:03Jens GrabowskiStatusassigned => closed
25-03-2010 11:03Jens GrabowskiResolutionopen => fixed
13-12-2010 13:36Gyorgy RethyStatusclosed => feedback
13-12-2010 13:36Gyorgy RethyResolutionfixed => reopened
13-12-2010 13:37Gyorgy RethyNote Added: 0009958
13-12-2010 13:37Gyorgy RethyStatusfeedback => closed
13-12-2010 13:37Gyorgy RethyResolutionreopened => fixed
13-12-2010 13:37Gyorgy RethyFixed in Version => v1.2.1
13-12-2010 13:37Gyorgy RethyTarget Version => v1.2.1
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009300) +
+ Benjamin Zeiss    +
+ 25-03-2010 10:27    +
+ 		+ + + + +
+ Regarding FormalTypeParList: i assume that the parameter values match those allowed parameters of the respective altstep, function, and testcase signatures of the core language spec. The adapted rule would then be:
+
+ 1. BehaviourDef ::= ( AltstepKeyword BehaviourTypeIdentifier [AltstepFormalParList]
+                       "("[AltstepFormalParList] ")" [RunsOnSpec] ) |
+     ( FunctionKeyword BehaviourTypeIdentifier [FunctionFormalParList]
+       "("[FunctionFormalParList] ")" [RunsOnSpec] [ReturnType] ) |
+     ( TestcaseKeyword BehaviourTypeIdentifier [TestcaseFormalParList]
+       "("[TestcaseFormalParList] ")" ConfigSpec )
+
+
+
+ + + + + + + + + + +
+ (0009301) +
+ Jens Grabowski    +
+ 25-03-2010 10:59    +
+ 		+ + + + +
+ Resolution for the rules 167 and 200 are implemented as proposed in the description.
+
+Rule 1 is correct, the dependency of FormalTypeParList with the advanced parameterization package has not been considered by the reporter.
+
+
+
+ + + + + + + + + + +
+ (0009958) +
+ Gyorgy Rethy    +
+ 13-12-2010 13:37    +
+ 		+ + + + +
+ Target version and fixed in version are added to CR.
+
+ + diff --git a/docs/mantis/CR5494.md b/docs/mantis/CR5494.md new file mode 100644 index 0000000000000000000000000000000000000000..7bf4ebf5e5dea746a820c64f8c21dc7d47d7e2b1 --- /dev/null +++ b/docs/mantis/CR5494.md @@ -0,0 +1,107 @@ + + + + + + + + + + + + + 0005494: Package BNF Corrections - Conf & Depl. - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Config & Deployment Support (ES 202 781)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005494Ext Pack: Config & Deployment Support (ES 202 781)Editorialpublic24-03-2010 11:2411-07-2012 16:32
ReporterGyorgy Rethy 
Assigned To 
PriorityhighSeveritytrivialReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv1.1.1 (published 2010-08) 
Target Versionv1.1.1 (published 2010-08)Fixed in Versionv1.1.1 (published 2010-08) 
Clause Reference(s)n/a
Source (company - Author)     
TS version
Summary0005494: Package BNF Corrections - Conf & Depl.
DescriptionPackage Configuration and Deployment v0.0.1:
+---------------------------------------------
+-197 TestcaseDef ::= TestcaseKeyword TestcaseIdentifier
++197. TestcaseDef ::= TestcaseKeyword TestcaseIdentifier
+
+The "." is missing after the rule number.
+
+-197a ExecuteOnSpec ::= ExecuteKeyword OnKeyword ConfigurationRef
++197a. ExecuteOnSpec ::= ExecuteKeyword OnKeyword ConfigurationRef
+
+The "." is missing after the rule number.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
child of 0005492closed  Ext Pack: Advanced Parametrization (ES 202 784) Package BNF Corrections - Adv. Param 
Attached Fileszip Resolution-Jens-CR5994.zip (675,714) 25-03-2010 09:42
http://oldforge.etsi.org/mantis/file_download.php?file_id=2358&type=bug
Issue History
Date ModifiedUsernameFieldChange
24-03-2010 11:24Gyorgy RethyNew Issue
24-03-2010 11:24Gyorgy RethyClause Reference(s) => n/a
24-03-2010 11:24Gyorgy RethySource (company - Author) =>
24-03-2010 11:24Gyorgy RethyIssue generated from: 0005492
24-03-2010 11:24Gyorgy RethyRelationship addedchild of 0005492
24-03-2010 16:55Gyorgy RethyProjectTTCN-3 Change Requests => Ext Pack: Config & Deployment Support (ES 202 781)
25-03-2010 09:42Jens GrabowskiNote Added: 0009298
25-03-2010 09:42Jens GrabowskiFile Added: Resolution-Jens-CR5994.zip
25-03-2010 11:04Jens GrabowskiStatusnew => closed
25-03-2010 11:04Jens GrabowskiResolutionopen => fixed
13-12-2010 13:38Gyorgy RethyStatusclosed => feedback
13-12-2010 13:38Gyorgy RethyResolutionfixed => reopened
13-12-2010 13:39Gyorgy RethyNote Added: 0009959
13-12-2010 13:39Gyorgy RethyStatusfeedback => closed
13-12-2010 13:39Gyorgy RethyResolutionreopened => fixed
13-12-2010 13:39Gyorgy RethyFixed in Version => v1.2.1
13-12-2010 13:39Gyorgy RethyTarget Version => v1.2.1
03-01-2011 16:54Gyorgy RethyStatusclosed => feedback
03-01-2011 16:54Gyorgy RethyResolutionfixed => reopened
03-01-2011 16:55Gyorgy RethyStatusfeedback => closed
11-07-2012 16:27user10Product Version => v1.1.1
11-07-2012 16:32user10Resolutionreopened => fixed
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009298) +
+ Jens Grabowski    +
+ 25-03-2010 09:42    +
+ 		+ + + + +
+ Resolved as proposed in the Description
+
+
+
+ + + + + + + + + + +
+ (0009959) +
+ Gyorgy Rethy    +
+ 13-12-2010 13:39    +
+ 		+ + + + +
+ Target version and fixed in version are added to CR header.
+
+ + diff --git a/docs/mantis/CR5504.md b/docs/mantis/CR5504.md new file mode 100644 index 0000000000000000000000000000000000000000..2db832589c415f61b059580a05b65bcb198a97bd --- /dev/null +++ b/docs/mantis/CR5504.md @@ -0,0 +1,65 @@ + + + + + + + + + + + + + 0005504: TCI Error Code - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005504Part 06: TTCN-3 Control InterfaceTechnicalpublic26-03-2010 07:3226-03-2010 18:13
ReporterIna Schieferdecker 
Assigned ToIna Schieferdecker 
PriorityhighSeveritymajorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.3.1 (published 2011-06)Fixed in Versionv4.2.1 (published 2010-07) 
Clause Reference(s)Language mapping clauses for TciStatus
Source (company - Author)Ina Schieferdecker, FOKUS
Summary0005504: TCI Error Code
DescriptionThe TRI Error Code is -1 (in TriStatus), while the TCI Error Code is 1 (in TciStatus).
+
+It is proposed to have also -1 for TCI Error.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
26-03-2010 07:32Ina SchieferdeckerNew Issue
26-03-2010 07:32Ina SchieferdeckerStatusnew => assigned
26-03-2010 07:32Ina SchieferdeckerAssigned To => Gyorgy Rethy
26-03-2010 07:32Ina SchieferdeckerClause Reference(s) => Language mapping clauses for TciStatus
26-03-2010 07:32Ina SchieferdeckerSource (company - Author) => Ina Schieferdecker, FOKUS
26-03-2010 09:16Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
26-03-2010 10:18Gyorgy RethyProjectTTCN-3 Change Requests => Part 06: TTCN-3 Control Interface
26-03-2010 10:18Gyorgy RethyTarget Version => Edition 4.3.1 (not yet published)
26-03-2010 10:59Ina SchieferdeckerNote Added: 0009322
26-03-2010 10:59Ina SchieferdeckerResolutionopen => fixed
26-03-2010 10:59Ina SchieferdeckerFixed in Version => Edition 4.2.1 (not yet published)
26-03-2010 10:59Ina SchieferdeckerAssigned ToIna Schieferdecker => Jacob Wieland - Spirent
26-03-2010 18:13Ina SchieferdeckerAssigned ToJacob Wieland - Spirent => Ina Schieferdecker
26-03-2010 18:13Ina SchieferdeckerStatusassigned => resolved
26-03-2010 18:13Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009322) +
+ Ina Schieferdecker    +
+ 26-03-2010 10:59    +
+ 		+ + + + +
+ as proposed.
+
+ + diff --git a/docs/mantis/CR5507.md b/docs/mantis/CR5507.md new file mode 100644 index 0000000000000000000000000000000000000000..2559a79d71fe8ea0b97e9081d3ff6b9cd547cfec --- /dev/null +++ b/docs/mantis/CR5507.md @@ -0,0 +1,395 @@ + + + + + + + + + + + + + 0005507: Infinity is a real value - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005507Part 01: TTCN-3 Core LanguageClarificationpublic07-04-2010 14:5122-07-2010 13:42
ReporterGyorgy Rethy 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.1.1 (published 2009-06) 
Target Versionv4.3.1 (published 2011-06)Fixed in Versionv4.2.2 (interim 2010) 
Clause Reference(s) 6.1.2.3
Source (company - Author)L.M.Ericsson
Summary0005507: Infinity is a real value
Descriptionthe 3rd sentence says: "In order to specify an infinite integer or float range, the keyword infinity may be used instead of a value indicating that there is no lower or upper boundary. "
+
+The situation has changed with the introduction of the special values infinity, -infinity and not_a_number (pls. note, these values has been introduced primarily for language compatibility with XSD and ASN.1). When ±infinity is used as a bound, ±infinity itself should be included into the range but not_a_number should not.
+
+To exclude the ±infinity special values but to have unrestricted bound for numeric values, the exclusive ±infinity bound shall be used.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0005344closed Ina Schieferdecker Part 01: TTCN-3 Core Language Introduce range subtyping boundaries excluding the boundaries themselves 
related to 0005340closed Gyorgy Rethy Part 09: Using XML with TTCN-3 Incorrect mapping of the XSD double type 
Attached Filesdoc CR5507_resolution_v1.doc (43,008) 29-06-2010 15:00
http://oldforge.etsi.org/mantis/file_download.php?file_id=2380&type=bug
doc CR5507_resolution_v2.doc (47,616) 30-06-2010 10:57
http://oldforge.etsi.org/mantis/file_download.php?file_id=2386&type=bug
doc CR5507_resolution_v3.doc (49,152) 01-07-2010 14:58
http://oldforge.etsi.org/mantis/file_download.php?file_id=2397&type=bug
Issue History
Date ModifiedUsernameFieldChange
07-04-2010 14:51Gyorgy RethyNew Issue
07-04-2010 14:51Gyorgy RethyClause Reference(s) => 6.1.2.3
07-04-2010 14:51Gyorgy RethySource (company - Author) => L.M.Ericsson
18-05-2010 08:47Gyorgy RethyDescription Updated
18-05-2010 10:27Gyorgy RethyDescription Updated
28-06-2010 16:31Ina SchieferdeckerRelationship addedrelated to 0005344
28-06-2010 16:36Gyorgy RethyNote Added: 0009393
28-06-2010 16:36Gyorgy RethyStatusnew => assigned
28-06-2010 16:36Gyorgy RethyAssigned To => Ina Schieferdecker
28-06-2010 16:40Ina SchieferdeckerNote Added: 0009394
29-06-2010 09:35Ina SchieferdeckerRelationship addedrelated to 0005340
29-06-2010 09:36Ina SchieferdeckerNote Edited: 0009394
29-06-2010 11:47Gyorgy RethyNote Added: 0009404
29-06-2010 11:47Gyorgy RethyTarget Version => Edition 4.3.1 (not yet published)
29-06-2010 12:01Gyorgy RethyNote Edited: 0009404
29-06-2010 14:00Gyorgy RethyNote Added: 0009406
29-06-2010 15:00Ina SchieferdeckerFile Added: CR5507_resolution_v1.doc
29-06-2010 15:01Ina SchieferdeckerNote Added: 0009407
29-06-2010 15:03Ina SchieferdeckerAssigned ToIna Schieferdecker => Gyorgy Rethy
29-06-2010 15:12Ina SchieferdeckerResolutionopen => fixed
29-06-2010 15:12Ina SchieferdeckerFixed in Version => Edition 4.2.2 (not yet published)
29-06-2010 15:14Gyorgy RethyNote Added: 0009410
29-06-2010 15:20Gyorgy RethyNote Edited: 0009410
29-06-2010 16:04Gyorgy RethyNote Edited: 0009410
29-06-2010 16:05Gyorgy RethyNote Edited: 0009410
29-06-2010 16:06Gyorgy RethyNote Edited: 0009410
30-06-2010 10:57Gyorgy RethyFile Added: CR5507_resolution_v2.doc
30-06-2010 10:58Gyorgy RethyNote Added: 0009424
30-06-2010 10:59Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
01-07-2010 14:06Ina SchieferdeckerNote Added: 0009449
01-07-2010 14:10Ina SchieferdeckerFile Added: CR5507_resolution_v3.doc
01-07-2010 14:10Ina SchieferdeckerAssigned ToIna Schieferdecker => Gyorgy Rethy
01-07-2010 14:56Ina SchieferdeckerFile Deleted: CR5507_resolution_v3.doc
01-07-2010 14:56Ina SchieferdeckerFile Added: CR5507_resolution_v3.doc
01-07-2010 14:58Ina SchieferdeckerFile Deleted: CR5507_resolution_v3.doc
01-07-2010 14:58Ina SchieferdeckerFile Added: CR5507_resolution_v3.doc
01-07-2010 15:18Gyorgy RethyNote Added: 0009453
01-07-2010 15:18Gyorgy RethyNote Added: 0009454
01-07-2010 15:19Gyorgy RethyNote Edited: 0009454
01-07-2010 15:19Gyorgy RethyNote Edited: 0009454
01-07-2010 15:20Gyorgy RethyNote Edited: 0009454
01-07-2010 15:20Gyorgy RethyNote Deleted: 0009453
01-07-2010 15:20Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
01-07-2010 15:20Gyorgy RethyStatusassigned => resolved
22-07-2010 13:42Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009393) +
+ Gyorgy Rethy    +
+ 28-06-2010 16:36    +
+ 		+ + + + +
+ Check in ASN.1
+Add exclusive bound for infinity in BNF
+
+
+
+ + + + + + + + + + +
+ (0009394) +
+ Ina Schieferdecker    +
+ 28-06-2010 16:40    +
(edited on: 29-06-2010 09:36)
+ 		+ + + + +
+ Unfortunately, the BNF for exclusive ranges were not updated accordingly:
+
+147. LowerBound ::= ([!] SingleConstExpression) | (Minus InfinityKeyword)
+148. UpperBound ::= ([!] SingleConstExpression) | InfinityKeyword
+
+see also 5344 ... wording is missing as well
+
+5344 was overruled by 5340 ... however text of 5340 needs to be included
+
+
+
+
+
+ + + + + + + + + + +
+ (0009404) +
+ Gyorgy Rethy    +
+ 29-06-2010 11:47    +
(edited on: 29-06-2010 12:01)
+ 		+ + + + +
+ There are two options:
+(0.0 .. infinity) includes the infinity special value
+(0.0 .. !infinity) excludes the infinity special value
+----------------------
+both the above syntaxes do exclude the infinity special value
+
+To be considered
+- before deciding ASN.1 and XSD shall be checked on this respect
+- in the current text an example implies that infinity shall be included in the range!
+
+
+
+
+
+ + + + + + + + + + +
+ (0009406) +
+ Gyorgy Rethy    +
+ 29-06-2010 14:00    +
+ 		+ + + + +
+ Another issue is discovered related to this:
+CR5340 introduced the infinity, -infinity and not_a_number and it's resolution contained:
+(from CR5340_resolution_P1_v3.doc)
+2. FloatValue ::= FloatDotNotation | FloatENotation | InfinityKeyword | NaNKeyword
+3. NaNKeyword ::= "not_a_number"
+
+Unfortunately, during implementation of this CR the agreed solution somehow changed to:
+(from es_20187301v040201m.doc)
+488. FloatValue ::= FloatDotNotation | FloatENotation | NaNKeyword
+489. NaNKeyword ::= "not_a_number"
+
+This editorial omission shall be corrected ASAP.
+
+
+
+ + + + + + + + + + +
+ (0009407) +
+ Ina Schieferdecker    +
+ 29-06-2010 15:01    +
+ 		+ + + + +
+ CR5340 and 5344 reviewed for consistency and needed additions identified - text for defining the meaning of float ranges with infinity added. Please check.
+
+
+
+ + + + + + + + + + +
+ (0009410) +
+ Gyorgy Rethy    +
+ 29-06-2010 15:14    +
(edited on: 29-06-2010 16:06)
+ 		+ + + + +
+ The current language mapping do rely on the behaviour proposed in the CR.
+I have checked in ASN.1: PLUS-INFINITY, MINUS-INFINITY and NOT-A-NUMBER are not handled in a special way, they may be part of a range constraint, in which case, if the boundary is not exclusive, the special values themselves are also part of the range. Part-7 is consistent with this, i.e. it assumes that (<anything>..infinity) includes infinity itself. If this assumption is changed, the mapping has to be changed too.
+
+In XSD: special values positive and negative infinity and not-a-number are not handled in a special way except the range specification. Part-9 is consistent with this, i.e. maxInclusive = "infinity" is mapped to (<anything>..infinity). If the assumption that (<anything>..infinity) contains the infinity value is changed, the mapping has to be changed too.
+
+FROM X.680:
+21.3 The abstract values of the real type are the special values PLUS-INFINITY, MINUS-INFINITY, and NOT-A-NUMBER together with numeric real numbers consisting of either plus zero or minus zero, or capable of being specified by the following formula involving three integers, M, B and E: M x BE <etc.>
+
+51.4.2 A "ValueRange" specifies ...
+NOTE – For the purpose of subtyping, NOT-A-NUMBER exceeds all real values, PLUS-INFINITY exceeds all real values except NOT-A-NUMBER, minus zero exceeds all negative real values and is less than plus zero, and MINUS-INFINITY is less than all real values. Otherwise, normal mathematical ordering is applied.
+
+51.4.3 Each endpoint of the range is either closed (in which case that endpoint is specified) or open (in which case the endpoint is not specified). When open, the specification of the endpoint includes a less-than symbol ("<"):
+LowerEndpoint ::= LowerEndValue | LowerEndValue "<"
+UpperEndpoint ::= UpperEndValue | "<" UpperEndValue
+
+
+
+FROM XSD, Part-2:
+[Definition:] float is patterned after the IEEE single-precision 32-bit floating point type [IEEE 754-1985]. The basic ·value space· of float consists of the values m × 2^e, where m is an integer whose absolute value is less than 2^24, and e is an integer between -149 and 104, inclusive. In addition to the basic ·value space· described above, the ·value space· of float also contains the following three special values: positive and negative infinity and not-a-number (NaN). The ·order-relation· on float is: x < y iff y - x is positive for x and y in the value space. Positive infinity is greater than all other non-NaN values. NaN equals itself but is ·incomparable· with (neither greater than nor less than) any other value in the ·value space·.
+Any value ·incomparable· with the value used for the four bounding facets (·minInclusive·, ·maxInclusive·, ·minExclusive·, and ·maxExclusive·) will be excluded from the resulting restricted ·value space·. In particular, when "NaN" is used as a facet value for a bounding facet, since no other float values are ·comparable· with it, the result is a ·value space· either having NaN as its only member (the inclusive cases) or that is empty (the exclusive cases). If any other value is used for a bounding facet, NaN will be excluded from the resulting restricted ·value space·; to add NaN back in requires union with the NaN-only space.
+
+
+
+
+
+ + + + + + + + + + +
+ (0009424) +
+ Gyorgy Rethy    +
+ 30-06-2010 10:58    +
+ 		+ + + + +
+ Solution is OK in principle. I have extended the proposed text in CR5507_resolution_v2.doc to cover all possible cases in detail. Pls. check.
+
+
+
+ + + + + + + + + + +
+ (0009449) +
+ Ina Schieferdecker    +
+ 01-07-2010 14:06    +
+ 		+ + + + +
+ If [-infinity..-infinity] is to be allowed for float, the BNF has to be extended - see v3
+
+
+
+ + + + + + + + + + +
+ (0009454) +
+ Gyorgy Rethy    +
+ 01-07-2010 15:18    +
(edited on: 01-07-2010 15:20)
+ 		+ + + + +
+ Its OK but one comment to the BNF changes: exclusive mark shall be uotside of the brackets, they can be used with ± infinity as well:
+1. LowerBound ::= ["!"]( SingleConstExpression | [Minus] InfinityKeyword )
+2. UpperBound ::= ["!"]( SingleConstExpression | [Minus] InfinityKeyword )
+
+
+
+ + diff --git a/docs/mantis/CR5508.md b/docs/mantis/CR5508.md new file mode 100644 index 0000000000000000000000000000000000000000..6aaca27f686d836b8b933b5901184306c9b4e602 --- /dev/null +++ b/docs/mantis/CR5508.md @@ -0,0 +1,165 @@ + + + + + + + + + + + + + 0005508: float2int called with special float values shall cause error - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005508Part 01: TTCN-3 Core LanguageTechnicalpublic12-04-2010 10:3922-07-2010 13:36
ReporterGyorgy Rethy 
Assigned ToIna Schieferdecker 
PrioritynormalSeveritytrivialReproducibilityalways
StatusclosedResolutionno change required 
PlatformOSOS Version
Product Version 
Target Versionv4.3.1 (published 2011-06)Fixed in Versionv4.2.2 (interim 2010) 
Clause Reference(s)C.8
Source (company - Author)L.M.Ericsson
Summary0005508: float2int called with special float values shall cause error
Description(-)infinity and not_a_number does not exists in the integer type, thus float2int() called with these special float values shall cause an error.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
12-04-2010 10:39Gyorgy RethyNew Issue
12-04-2010 10:39Gyorgy RethyClause Reference(s) => C.8
12-04-2010 10:39Gyorgy RethySource (company - Author) => L.M.Ericsson
28-06-2010 16:50Gyorgy RethyStatusnew => assigned
28-06-2010 16:50Gyorgy RethyAssigned To => Ina Schieferdecker
29-06-2010 11:38Gyorgy RethyNote Added: 0009403
29-06-2010 11:38Gyorgy RethyTarget Version => Edition 4.3.1 (not yet published)
29-06-2010 15:06Ina SchieferdeckerNote Added: 0009408
29-06-2010 15:06Ina SchieferdeckerResolutionopen => no change required
29-06-2010 15:06Ina SchieferdeckerStatusassigned => closed
02-07-2010 13:58Gyorgy RethyStatusclosed => feedback
02-07-2010 13:58Gyorgy RethyResolutionno change required => reopened
02-07-2010 13:58Gyorgy RethyNote Added: 0009475
02-07-2010 13:59Gyorgy RethyFixed in Version => Edition 4.2.2 (not yet published)
02-07-2010 13:59Gyorgy RethyStatusfeedback => closed
02-07-2010 13:59Gyorgy RethyNote Added: 0009476
02-07-2010 13:59Gyorgy RethyResolutionreopened => fixed
22-07-2010 13:36Ina SchieferdeckerResolutionfixed => no change required
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009403) +
+ Gyorgy Rethy    +
+ 29-06-2010 11:38    +
+ 		+ + + + +
+ Agreed in principle, add word numeric.
+
+
+
+ + + + + + + + + + +
+ (0009408) +
+ Ina Schieferdecker    +
+ 29-06-2010 15:06    +
+ 		+ + + + +
+ This error case has already been defined in v4.2.1
+
+
+
+ + + + + + + + + + +
+ (0009475) +
+ Gyorgy Rethy    +
+ 02-07-2010 13:58    +
+ 		+ + + + +
+ Just adding Fixed in Version to the Mantis item
+
+
+
+ + + + + + + + + + +
+ (0009476) +
+ Gyorgy Rethy    +
+ 02-07-2010 13:59    +
+ 		+ + + + +
+ Fixed in Version is updated
+
+ + diff --git a/docs/mantis/CR5509.md b/docs/mantis/CR5509.md new file mode 100644 index 0000000000000000000000000000000000000000..3d3d6f1de2021c0b98c2dca688f9cb958c6e1a0f --- /dev/null +++ b/docs/mantis/CR5509.md @@ -0,0 +1,131 @@ + + + + + + + + + + + + + 0005509: Test case guard timer duration shall be a numeric float value - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005509Part 01: TTCN-3 Core LanguageClarificationpublic12-04-2010 10:4522-07-2010 13:35
ReporterGyorgy Rethy 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.3.1 (published 2011-06)Fixed in Versionv4.2.2 (interim 2010) 
Clause Reference(s)26.1
Source (company - Author)L.M.Ericsson
Summary0005509: Test case guard timer duration shall be a numeric float value
DescriptionCurrent restrictions in $26.1 mention only float, while obviously it should be numeric float values.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR5509_resolution_v1.doc (22,528) 29-06-2010 15:10
http://oldforge.etsi.org/mantis/file_download.php?file_id=2381&type=bug
Issue History
Date ModifiedUsernameFieldChange
12-04-2010 10:45Gyorgy RethyNew Issue
12-04-2010 10:45Gyorgy RethyClause Reference(s) => 26.1
12-04-2010 10:45Gyorgy RethySource (company - Author) => L.M.Ericsson
28-06-2010 16:50Gyorgy RethyStatusnew => assigned
28-06-2010 16:50Gyorgy RethyAssigned To => Ina Schieferdecker
29-06-2010 11:37Gyorgy RethyNote Added: 0009402
29-06-2010 11:37Gyorgy RethyTarget Version => Edition 4.3.1 (not yet published)
29-06-2010 11:37Gyorgy RethyDescription Updated
29-06-2010 15:10Ina SchieferdeckerFile Added: CR5509_resolution_v1.doc
29-06-2010 15:10Ina SchieferdeckerNote Added: 0009409
29-06-2010 15:11Ina SchieferdeckerAssigned ToIna Schieferdecker => Gyorgy Rethy
29-06-2010 15:11Ina SchieferdeckerResolutionopen => fixed
29-06-2010 15:11Ina SchieferdeckerFixed in Version => Edition 4.2.2 (not yet published)
30-06-2010 09:35Gyorgy RethyNote Added: 0009422
30-06-2010 09:35Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
30-06-2010 09:35Gyorgy RethyStatusassigned => resolved
22-07-2010 13:35Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009402) +
+ Gyorgy Rethy    +
+ 29-06-2010 11:37    +
+ 		+ + + + +
+ Agreed in principle, add word numeric.
+
+
+
+ + + + + + + + + + +
+ (0009409) +
+ Ina Schieferdecker    +
+ 29-06-2010 15:10    +
+ 		+ + + + +
+ Please check resolution.
+
+
+
+ + + + + + + + + + +
+ (0009422) +
+ Gyorgy Rethy    +
+ 30-06-2010 09:35    +
+ 		+ + + + +
+ OK with me.
+
+ + diff --git a/docs/mantis/CR5510.md b/docs/mantis/CR5510.md new file mode 100644 index 0000000000000000000000000000000000000000..b7ef5f8c1860560b30da1711d84d4ff9d76c5c87 --- /dev/null +++ b/docs/mantis/CR5510.md @@ -0,0 +1,199 @@ + + + + + + + + + + + + + 0005510: Allowed range of seed values should be specified for rnd() - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005510Part 01: TTCN-3 Core LanguageClarificationpublic12-04-2010 10:5122-07-2010 13:35
ReporterGyorgy Rethy 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.3.1 (published 2011-06)Fixed in Versionv4.2.2 (interim 2010) 
Clause Reference(s)C.35
Source (company - Author)L.M.Ericsson
Summary0005510: Allowed range of seed values should be specified for rnd()
DescriptionThe current text says nothing about which float values (range) is allowed as seed values and what to do if the seed is a non-allowed value, e.g. not_a_number.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR5510_resolution_v1.doc (28,672) 29-06-2010 15:18
http://oldforge.etsi.org/mantis/file_download.php?file_id=2382&type=bug
doc CR5510_resolution_v2.doc (28,672) 30-06-2010 09:26
http://oldforge.etsi.org/mantis/file_download.php?file_id=2385&type=bug
doc CR5510_resolution_v3.doc (28,672) 01-07-2010 15:26
http://oldforge.etsi.org/mantis/file_download.php?file_id=2398&type=bug
Issue History
Date ModifiedUsernameFieldChange
12-04-2010 10:51Gyorgy RethyNew Issue
12-04-2010 10:51Gyorgy RethyClause Reference(s) => C.35
12-04-2010 10:51Gyorgy RethySource (company - Author) => L.M.Ericsson
28-06-2010 16:49Gyorgy RethyStatusnew => assigned
28-06-2010 16:49Gyorgy RethyAssigned To => Ina Schieferdecker
29-06-2010 11:35Gyorgy RethyNote Added: 0009401
29-06-2010 11:35Gyorgy RethyTarget Version => Edition 4.3.1 (not yet published)
29-06-2010 15:18Ina SchieferdeckerFile Added: CR5510_resolution_v1.doc
29-06-2010 15:18Ina SchieferdeckerNote Added: 0009411
29-06-2010 15:19Ina SchieferdeckerAssigned ToIna Schieferdecker => Gyorgy Rethy
29-06-2010 15:19Ina SchieferdeckerResolutionopen => fixed
29-06-2010 15:19Ina SchieferdeckerFixed in Version => Edition 4.2.2 (not yet published)
30-06-2010 09:26Gyorgy RethyFile Added: CR5510_resolution_v2.doc
30-06-2010 09:27Gyorgy RethyNote Added: 0009421
30-06-2010 09:28Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
01-07-2010 15:24Ina SchieferdeckerNote Added: 0009455
01-07-2010 15:26Ina SchieferdeckerFile Added: CR5510_resolution_v3.doc
01-07-2010 15:26Ina SchieferdeckerAssigned ToIna Schieferdecker => Gyorgy Rethy
01-07-2010 17:23Gyorgy RethyNote Added: 0009458
01-07-2010 17:25Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
01-07-2010 17:25Gyorgy RethyStatusassigned => resolved
22-07-2010 13:34Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009401) +
+ Gyorgy Rethy    +
+ 29-06-2010 11:35    +
+ 		+ + + + +
+ Add text on allowed value range and add error case when the seed is out of this range.
+
+
+
+ + + + + + + + + + +
+ (0009411) +
+ Ina Schieferdecker    +
+ 29-06-2010 15:18    +
+ 		+ + + + +
+ See resolution - please check
+
+
+
+ + + + + + + + + + +
+ (0009421) +
+ Gyorgy Rethy    +
+ 30-06-2010 09:27    +
+ 		+ + + + +
+ Uploaded CR5510_resolution_v2.doc: added negative values to error causes. With this change it is OK with me.
+
+
+
+ + + + + + + + + + +
+ (0009455) +
+ Ina Schieferdecker    +
+ 01-07-2010 15:24    +
+ 		+ + + + +
+ I overdid the resolution: seed can also be negative - it just needs to be numerical
+
+
+
+ + + + + + + + + + +
+ (0009458) +
+ Gyorgy Rethy    +
+ 01-07-2010 17:23    +
+ 		+ + + + +
+ OK with me.
+
+ + diff --git a/docs/mantis/CR5511.md b/docs/mantis/CR5511.md new file mode 100644 index 0000000000000000000000000000000000000000..13930ff6c8b68eee1e9feb41b120d707a5104e8a --- /dev/null +++ b/docs/mantis/CR5511.md @@ -0,0 +1,101 @@ + + + + + + + + + + + + + 0005511: Timer default value shall be a numeric float value - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005511Part 01: TTCN-3 Core LanguageTechnicalpublic12-04-2010 10:5429-06-2010 16:46
ReporterGyorgy Rethy 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionno change required 
PlatformOSOS Version
Product Version 
Target Versionv4.3.1 (published 2011-06)Fixed in Version 
Clause Reference(s)12
Source (company - Author)L.M.Ericsson
Summary0005511: Timer default value shall be a numeric float value
DescriptionCurrent clause does not specify this in the restrictions.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
12-04-2010 10:54Gyorgy RethyNew Issue
12-04-2010 10:54Gyorgy RethyClause Reference(s) => 12
12-04-2010 10:54Gyorgy RethySource (company - Author) => L.M.Ericsson
12-04-2010 12:01Gyorgy RethySummaryTimar default value shall be a numeric float value => Timer default value shall be a numeric float value
28-06-2010 16:48Gyorgy RethyStatusnew => assigned
28-06-2010 16:48Gyorgy RethyAssigned To => Ina Schieferdecker
29-06-2010 11:29Gyorgy RethyNote Added: 0009400
29-06-2010 11:29Gyorgy RethyTarget Version => Edition 4.3.1 (not yet published)
29-06-2010 16:45Ina SchieferdeckerNote Added: 0009416
29-06-2010 16:46Ina SchieferdeckerStatusassigned => closed
29-06-2010 16:46Ina SchieferdeckerResolutionopen => no change required
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009400) +
+ Gyorgy Rethy    +
+ 29-06-2010 11:29    +
+ 		+ + + + +
+ Add a the world "numeric" to text.
+
+
+
+ + + + + + + + + + +
+ (0009416) +
+ Ina Schieferdecker    +
+ 29-06-2010 16:45    +
+ 		+ + + + +
+ This is already included in v4.2.1:
+
+"a) In case of a single timer, the default duration value shall resolve to a non-negative numerical float value (i.e. the value shall be greater or equal 0.0, infinity and not_a_number are disallowed).
+
+b) In case of a timer array, it shall resolve to an array of float values obeying to restriction a) above of the same size as the size of the timer array."
+
+ + diff --git a/docs/mantis/CR5513.md b/docs/mantis/CR5513.md new file mode 100644 index 0000000000000000000000000000000000000000..51aaeef47b50510a76550ad74ee8af05cc06e666 --- /dev/null +++ b/docs/mantis/CR5513.md @@ -0,0 +1,1072 @@ + + + + + + + + + + + + + 0005513: resolution of CR5092 contains bogus examples for charstring - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005513Part 01: TTCN-3 Core LanguageClarificationpublic14-04-2010 15:2415-12-2010 00:41
ReporterJacob Wieland - Spirent 
Assigned ToIna Schieferdecker 
PriorityhighSeveritymajorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.3.1 (published 2011-06)Fixed in Versionv4.3.1 (published 2011-06) 
Clause Reference(s)7.1.2
Source (company - Author)Testing Technologies - Jacob Wieland
Summary0005513: resolution of CR5092 contains bogus examples for charstring
DescriptionIn the CR 5092, there are several misleading (or WRONG?) examples concerning concatenation of charstring templates. While mapping * length(N) to a repetition of N ? makes sense in the context of octetstring, hexstring and bitstring types (because there ? has a special meaning already), it does NOT make sense in the context of charstring, as there the character ? is just another character with no special meaning. The only context where that is the case are charstring patterns.
+
+Thus, either the examples are wrong for charstring or it should be explained that concatenating a normal charstring value (template) with a length-template should result in a charstring pattern template (if that is the intention), i.e. all special characters in the charstring value template need to be quoted.
+
+I.e. '"a*?" & * length(2)' would result in a template equivalent to
+the charstring template expression 'pattern "a\*\???"'
+
+Interpreting this as the template "a*???" (without pattern) would not make much sense as that would only match the value "a*???" which is totally different from the meaning in the other string types and thus would be totally confusing for the user.
Steps To Reproduce
Additional InformationThis should actually be a note added to CR5092, but since I was told not to reopen closed CRs, I'm submitting a new one.
TagsNo tags attached.
Relationships
related to 0005092closed Gyorgy Rethy String concatination is not possible for string templates 
related to 0005809closed Ina Schieferdecker CL chapter 15.11 Concatenating templates of string and list types is not supported by BNF 
related to 0005828closed Ina Schieferdecker STF409 comment on [Part 1: TTCN-3 Core Language /Annex B.1.5.2 ]: syntactical ambiguity 
Attached Filesdoc CR5513_resolution v2.doc (86,528) 30-06-2010 15:52
http://oldforge.etsi.org/mantis/file_download.php?file_id=2388&type=bug
doc CR5513_resolution v3.doc (93,184) 01-07-2010 18:01
http://oldforge.etsi.org/mantis/file_download.php?file_id=2399&type=bug
doc CR5513_resolution v4.doc (91,648) 02-07-2010 13:44
http://oldforge.etsi.org/mantis/file_download.php?file_id=2402&type=bug
doc CR5513_resolution v5.doc (90,112) 13-07-2010 11:58
http://oldforge.etsi.org/mantis/file_download.php?file_id=2409&type=bug
doc CR5513_resolution v6.doc (90,112) 14-07-2010 11:47
http://oldforge.etsi.org/mantis/file_download.php?file_id=2410&type=bug
doc CR5513_resolution v7.doc (91,648) 22-07-2010 12:58
http://oldforge.etsi.org/mantis/file_download.php?file_id=2412&type=bug
doc CR5513_resolution v8.doc (91,136) 01-12-2010 10:10
http://oldforge.etsi.org/mantis/file_download.php?file_id=2448&type=bug
doc CR5513_resolution_v9.doc (91,648) 01-12-2010 10:10
http://oldforge.etsi.org/mantis/file_download.php?file_id=2449&type=bug
Issue History
Date ModifiedUsernameFieldChange
14-04-2010 15:24Jacob Wieland - SpirentNew Issue
14-04-2010 15:24Jacob Wieland - SpirentClause Reference(s) => 7.1.2
14-04-2010 15:24Jacob Wieland - SpirentSource (company - Author) => Testing Technologies - Jacob Wieland
14-04-2010 15:26Jacob Wieland - SpirentRelationship addedrelated to 0005092
28-06-2010 16:46Gyorgy RethyStatusnew => assigned
28-06-2010 16:46Gyorgy RethyAssigned To => Gyorgy Rethy
29-06-2010 10:52Gyorgy RethyProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
29-06-2010 10:54Gyorgy RethyNote Added: 0009399
29-06-2010 10:54Gyorgy RethyTarget Version => Edition 4.3.1 (not yet published)
29-06-2010 10:55Gyorgy RethyNote Edited: 0009399
29-06-2010 12:05Jacob Wieland - SpirentNote Added: 0009405
30-06-2010 08:33Gyorgy RethyFile Added: CR5553_resolution.doc
30-06-2010 08:34Gyorgy RethyNote Added: 0009420
30-06-2010 10:27Jacob Wieland - SpirentNote Added: 0009423
30-06-2010 13:11Jacob Wieland - SpirentNote Added: 0009430
30-06-2010 15:50Gyorgy RethyNote Added: 0009434
30-06-2010 15:51Gyorgy RethyFile Deleted: CR5553_resolution.doc
30-06-2010 15:52Gyorgy RethyFile Added: CR5513_resolution v2.doc
30-06-2010 15:52Gyorgy RethyAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
30-06-2010 15:53Gyorgy RethyNote Edited: 0009434
30-06-2010 17:07Jacob Wieland - SpirentNote Added: 0009436
01-07-2010 16:17Gyorgy RethyNote Added: 0009456
01-07-2010 16:18Gyorgy RethyNote Edited: 0009456
01-07-2010 18:01Gyorgy RethyFile Added: CR5513_resolution v3.doc
01-07-2010 18:03Gyorgy RethyNote Added: 0009459
02-07-2010 09:45Gyorgy RethyAssigned ToJacob Wieland - Spirent => Ina Schieferdecker
02-07-2010 09:46Gyorgy RethyNote Added: 0009460
02-07-2010 11:01Ina SchieferdeckerNote Added: 0009466
02-07-2010 11:02Ina SchieferdeckerAssigned ToIna Schieferdecker => Benjamin Zeiss
02-07-2010 11:55Jacob Wieland - SpirentNote Added: 0009470
02-07-2010 12:40Gyorgy RethyNote Added: 0009472
02-07-2010 12:44Jacob Wieland - SpirentNote Added: 0009473
02-07-2010 13:22Gyorgy RethyNote Edited: 0009472
02-07-2010 13:37Gyorgy RethyNote Edited: 0009472
02-07-2010 13:38Gyorgy RethyNote Edited: 0009472
02-07-2010 13:44Gyorgy RethyFile Added: CR5513_resolution v4.doc
02-07-2010 13:48Gyorgy RethyNote Added: 0009474
02-07-2010 14:03Jacob Wieland - SpirentNote Added: 0009477
08-07-2010 15:14Benjamin ZeissNote Added: 0009483
08-07-2010 15:14Benjamin ZeissAssigned ToBenjamin Zeiss => Ina Schieferdecker
13-07-2010 11:58Gyorgy RethyNote Added: 0009520
13-07-2010 11:58Gyorgy RethyFile Added: CR5513_resolution v5.doc
13-07-2010 17:03Gyorgy RethyNote Edited: 0009520
14-07-2010 10:30Jacob Wieland - SpirentNote Added: 0009522
14-07-2010 11:47Gyorgy RethyFile Added: CR5513_resolution v6.doc
14-07-2010 11:50Gyorgy RethyNote Added: 0009523
14-07-2010 11:50Gyorgy RethyStatusassigned => resolved
14-07-2010 11:50Gyorgy RethyResolutionopen => fixed
22-07-2010 12:58Ina SchieferdeckerFile Added: CR5513_resolution v7.doc
22-07-2010 13:04Ina SchieferdeckerNote Added: 0009560
22-07-2010 13:05Ina SchieferdeckerStatusresolved => closed
22-07-2010 13:05Ina SchieferdeckerFixed in Version => Edition 4.2.2 (not yet published)
29-11-2010 12:57Jacob Wieland - SpirentStatusclosed => feedback
29-11-2010 12:57Jacob Wieland - SpirentResolutionfixed => reopened
29-11-2010 12:57Jacob Wieland - SpirentNote Added: 0009826
29-11-2010 13:04Jacob Wieland - SpirentRelationship addedrelated to 0005808
29-11-2010 13:05Jacob Wieland - SpirentRelationship deletedrelated to 0005808
29-11-2010 13:08Jacob Wieland - SpirentRelationship addedrelated to 0005809
29-11-2010 13:49Jacob Wieland - SpirentNote Added: 0009829
29-11-2010 15:54Jacob Wieland - SpirentRelationship addedrelated to 0005828
29-11-2010 16:04Jacob Wieland - SpirentNote Edited: 0009829
30-11-2010 11:20Ina SchieferdeckerFile Added: CR5513_resolution v8.doc
30-11-2010 11:21Ina SchieferdeckerNote Added: 0009840
30-11-2010 11:22Ina SchieferdeckerStatusfeedback => assigned
30-11-2010 11:22Ina SchieferdeckerAssigned ToIna Schieferdecker => Jacob Wieland - Spirent
30-11-2010 11:22Ina SchieferdeckerAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
01-12-2010 09:16Gyorgy RethyNote Added: 0009872
01-12-2010 09:16Gyorgy RethyFile Added: CR5513_resolution_v9.doc
01-12-2010 09:17Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
01-12-2010 09:17Gyorgy RethyStatusassigned => resolved
01-12-2010 09:17Gyorgy RethyResolutionreopened => fixed
01-12-2010 09:17Gyorgy RethyFixed in VersionEdition 4.2.2 (not yet published) => Edition 4.3.1 (not yet published)
01-12-2010 10:09Ina SchieferdeckerFile Deleted: CR5513_resolution v8.doc
01-12-2010 10:10Ina SchieferdeckerFile Deleted: CR5513_resolution_v9.doc
01-12-2010 10:10Ina SchieferdeckerFile Added: CR5513_resolution v8.doc
01-12-2010 10:10Ina SchieferdeckerFile Added: CR5513_resolution_v9.doc
01-12-2010 10:11Ina SchieferdeckerNote Added: 0009878
01-12-2010 15:45Ina SchieferdeckerStatusresolved => closed
15-12-2010 00:41Ina SchieferdeckerNote Added: 0009978
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009399) +
+ Gyorgy Rethy    +
+ 29-06-2010 10:54    +
(edited on: 29-06-2010 10:55)
+ 		+ + + + +
+ Agreed in principle, examples are incorrect, concatenating * length(2) to specific charstring values shall be disallowed; create proposed text.
+Target: interim version!
+
+
+
+
+
+ + + + + + + + + + +
+ (0009405) +
+ Jacob Wieland - Spirent    +
+ 29-06-2010 12:05    +
+ 		+ + + + +
+ In principle, I don't think it should be disallowed to concatenate different charstring templates to get a new template in general.
+
+I.e. if t1 and t2 are valid charstring template expressions, then t1 & t2 should match a charstring value v, if there exists a concatenation v1 & v2 == v so that t1 matches v1 and t2 matches v2. The same extension can be added to the other string types, as well.
+
+But, for the interim version, I think that forbidding concatenation on charstring templates is the right way to go.
+
+
+
+ + + + + + + + + + +
+ (0009420) +
+ Gyorgy Rethy    +
+ 30-06-2010 08:34    +
+ 		+ + + + +
+ Proposed resolution is uploaded in CR5513_resolution.doc.
+
+
+
+ + + + + + + + + + +
+ (0009423) +
+ Jacob Wieland - Spirent    +
+ 30-06-2010 10:27    +
+ 		+ + + + +
+ I have a few other (major) criticisms to this proposal:
+
+1) The BNF does not allow expressions like A & * length(N) because length(N) is only derivable from ExtraMatchingAttributes, which is at the end of TemplateBody which cannot be derived from MulExpression (which is both the left and the right side of AddExpression where & is the operator.
+
+=> Thus, the Examples have to be changed putting () around the * length(N) part.
+(I don' think that the grammar should be changed to accommodate the present examples as that would open up a major can of worms)
+
+2) I think that * length(N) in concatenations should rather be ? length(N)
+This is because ? and ? length(N) are already valid string matching mechanisms while * is only a valid matching mechanism for an optional field, also matching omit. Since in a concatenation, we are not dealing with fields and we are not really inside values (where * has a different semantics), using * (while not being totally wrong no omit can occur anyway) is misleading. Also, the ? length(N) is forbidden explicitly by the text which I think is totally wrong.
+
+
+
+ + + + + + + + + + +
+ (0009430) +
+ Jacob Wieland - Spirent    +
+ 30-06-2010 13:11    +
+ 		+ + + + +
+ I think the attached file is supposed to be in a different CR
+
+
+
+ + + + + + + + + + +
+ (0009434) +
+ Gyorgy Rethy    +
+ 30-06-2010 15:50    +
(edited on: 30-06-2010 15:53)
+ 		+ + + + +
+ Good points. See updated proposal in CR5513_resolution v2.doc.
+
+I have added the BNF and allowed both ? length (N) and * length (N). I see no reason to restrict the syntax only for one of them, though they mean the same. Clause B.1.4.1 allows length for both, to be more restrictive here would be seen by the user as further exception rule. Also more convenient for the user when e.g. changing already existing * to something concatenated.
+
+Pls. review.
+
+
+
+
+
+ + + + + + + + + + +
+ (0009436) +
+ Jacob Wieland - Spirent    +
+ 30-06-2010 17:07    +
+ 		+ + + + +
+ Sorry, but the changes to the BNF do not work.
+
+As far as I can see, the concatenated template cannot begin with ? length(N), i.e. there is no derivation for
+
+? length(N) & 'aa'O
+
+Why should this be?
+
+
+
+ + + + + + + + + + +
+ (0009456) +
+ Gyorgy Rethy    +
+ 01-07-2010 16:17    +
(edited on: 01-07-2010 16:18)
+ 		+ + + + +
+ Need not, just the BNF proposal is not complete enough. I will update.
+
+
+
+
+
+ + + + + + + + + + +
+ (0009459) +
+ Gyorgy Rethy    +
+ 01-07-2010 18:03    +
+ 		+ + + + +
+ Pls. find the updated BNF proposal in CR5513_resolution v3.doc. To identify the additions, they are marked with yellow background as the BNF itself contains blue underlined font.
+
+
+
+ + + + + + + + + + +
+ (0009460) +
+ Gyorgy Rethy    +
+ 02-07-2010 09:46    +
+ 		+ + + + +
+ Ina, pls. cross-check!
+
+
+
+ + + + + + + + + + +
+ (0009466) +
+ Ina Schieferdecker    +
+ 02-07-2010 11:01    +
+ 		+ + + + +
+ Contentwise it looks ok - Benjamin, could you however please check that there is no reduce conflict.
+
+
+
+ + + + + + + + + + +
+ (0009470) +
+ Jacob Wieland - Spirent    +
+ 02-07-2010 11:55    +
+ 		+ + + + +
+ This proposal is better, but it has a different problem.
+
+The grammar now is ambiguous because SimpleSpec can be followed by ExtraMatchingAttributes which also can derive to LengthMatch,
+
+so, in TemplateBody expressions like
+
+'aa'O & ? length(10)
+
+it needs to be clarified if the length(10) is the LengthMatch of MatchingSymbol or TemplateBody.
+
+I think it should be the former, but this needs to be clarified in the static semantics, i.e. by enforcing the LengthMatch for AnyValue and AnyValueOrOmit in concatenations. Thereby, it is clear that the length directly after ? must be part of the MatchingSymbol.
+
+Thus, I propose the following:
+
+/* STATIC SEMANTIC – LengthMatch must be used when MatchingSymbol is used in fractions of a concatenated string, otherwise it shall only be used inside list templates (see clause 15.11). In both cases, the Complement, ValueOrAttribList, Range, BitStringMatch, HexStringMatch, OctetStringMatch, CharStringMatch, SubsetMatch and SupersetMatch productions shall not be used.
+*/
+
+
+
+ + + + + + + + + + +
+ (0009472) +
+ Gyorgy Rethy    +
+ 02-07-2010 12:40    +
(edited on: 02-07-2010 13:38)
+ 		+ + + + +
+ Within simple list templates the length from the path TemplateBody -> ArrayValueOrAttrib -> ArrayElementSpecList -> ArrayElementSpec -> TemplateBody is used, thus this newly added length shall be used with concatenation ONLY. But I agree that in case of concatenation length shall be mandatory.
+
+
+
+
+
+ + + + + + + + + + +
+ (0009473) +
+ Jacob Wieland - Spirent    +
+ 02-07-2010 12:44    +
+ 		+ + + + +
+ All the better, then change the text to:
+
+/* STATIC SEMANTIC – LengthMatch must be used when MatchingSymbol is used in fractions of a concatenated string. In that case, the Complement, ValueOrAttribList, Range, BitStringMatch, HexStringMatch, OctetStringMatch, CharStringMatch, SubsetMatch and SupersetMatch productions shall not be used.
+*/
+
+
+
+ + + + + + + + + + +
+ (0009474) +
+ Gyorgy Rethy    +
+ 02-07-2010 13:48    +
+ 		+ + + + +
+ CR5513_resolution v4.doc: only updates in BNF. One more static rule is added to TemplateBody to exclude e.g.
+'01'B & ? length(2) length (3).
+
+
+
+ + + + + + + + + + +
+ (0009477) +
+ Jacob Wieland - Spirent    +
+ 02-07-2010 14:03    +
+ 		+ + + + +
+ Why, why, why???
+
+The overall length restriction also makes sense in situations where there are * wildcards inside the string-templates:
+
+'aa*bb'O & ? length(1 .. 10) length(3 .. 40)
+
+So, I don't think that the restriction is necessary, move to strike.
+
+With the static semantic at the MatchingSymbol, the grammar is unambiguous in case that only one length() is provided (if it ends with ?/* length, then it is the inner length, if it ends with a different expression, it is the outer length) and it is also unambiguous if it ends with ?/* length() length()
+
+
+
+ + + + + + + + + + +
+ (0009483) +
+ Benjamin Zeiss    +
+ 08-07-2010 15:14    +
+ 		+ + + + +
+ Looking for shift-reduce and reduce-reduce conflicts by hand is obviously not an easy task ;-) Anyhow, here is what I tried in my limited time since last week:
+
+I took the 4.2.1 grammar and converted the EBNF model to a BNF model. From that, I wrote a template that converted the grammar to an input grammar of the LALR GOLD parser which is a pretty nice tool to debug and browse LALR states. Due to the way I converted the grammar, there were already numerous conflicts (but that exist mostly due to the transformation). When ignoring them and incorporating the changes from this CR, I was able to rewrite both EBNF changes to BNF so that they did not produce any new conflicts. So from that, I more or less conclude that the changes should be reasonably safe. I will definately fiddle around with this a little more to see whether I can resolve the problems with the transformation conflicts or at least a number of them. Unfortunately, my time to work on this in this week has run out and Gyorgy asked me to reassign the CR to Ina in this week when I'm done. So this is what I'm doing now.
+
+It would probably be worthwhile to go through the sr/rr conflicts again when I have the grammar conversion in a state that doesn't produce as many initial conflicts.
+
+
+
+ + + + + + + + + + +
+ (0009520) +
+ Gyorgy Rethy    +
+ 13-07-2010 11:58    +
(edited on: 13-07-2010 17:03)
+ 		+ + + + +
+ "Why, why, why???
+The overall length restriction also makes sense in situations where there are * wildcards inside the string-templates:
+
+'aa*bb'O & ? length(1 .. 10) length(3 .. 40)"
+
+It may look a little bit confusing for the user but I admit, this does not seem to be sufficient to forbid this. So, it is OK to remove the new static rule from Templatebody. Done in CR5513_resolution v5.doc.
+
+
+
+
+
+ + + + + + + + + + +
+ (0009522) +
+ Jacob Wieland - Spirent    +
+ 14-07-2010 10:30    +
+ 		+ + + + +
+ The only thing wrong in v5 is the following example:
+
+template RecofInt t_MyRecofInt := { 1, 2 } & { ? length(2), 3, 4 };
+        // results the template {1, 2, ?, ?, 3, 4 }
+
+This should be:
+
+template RecofInt t_MyRecofInt := { 1, 2 } & ? length(2) & { 3, 4 };
+        // results the template {1, 2, ?, ?, 3, 4 }
+
+Otherwise, it is ok.
+
+
+
+ + + + + + + + + + +
+ (0009523) +
+ Gyorgy Rethy    +
+ 14-07-2010 11:50    +
+ 		+ + + + +
+ This is a typo in the example, it was changed unintentionally, the original intention was:
+template RecofInt t_MyRecofInt := { 1, 2 } & { * length(2), 3, 4 };
+        // results the template {1, 2, ?, ?, 3, 4 }
+
+It is corrected in CR5513_resolution v6.doc.
+
+
+
+ + + + + + + + + + +
+ (0009560) +
+ Ina Schieferdecker    +
+ 22-07-2010 13:04    +
+ 		+ + + + +
+ small editorials, also in examples
+
+
+
+ + + + + + + + + + +
+ (0009826) +
+ Jacob Wieland - Spirent    +
+ 29-11-2010 12:57    +
+ 		+ + + + +
+ The LengthMatch for Any and AnyOrOmit in the rule for MatchingSymbol in the BNF should be restricted to contain no optional upper bound (to be consistent with the text).
+
+
+
+ + + + + + + + + + +
+ (0009829) +
+ Jacob Wieland - Spirent    +
+ 29-11-2010 13:49    +
(edited on: 29-11-2010 16:04)
+ 		+ + + + +
+ There is an ambiguity problem with the proposal:
+
+If SingleExpression derives "X & Y", but also only "X" or "Y" and
+SingleValueOrAttrib derives SingleExpression, we have two ways
+of deriving "X & Y" from SimpleSpec.
+
+Also, there is another ambiguity with CharStringMatch which can also contain "&".
+
+Therefore, we should change the grammar in the following manner:
+
+SimpleSpec ::= SingleExpression ["&" SimpleTemplateSpec]
+             | SimpleTemplateSpec
+
+SimpleTemplateSpec ::= CharStringMatch
+                     | SingleTemplateExpression ["&" SimpleSpec]
+
+SingleTemplateExpression ::= MatchingSymbol
+                           | ( TemplateRefWithParList [ExtendedFieldReference] )
+
+MatchingSymbol ::=
+  Complement |
+  AnyValue |
+  AnyOrOmit |
+  ValueOrAttribList |
+  Range |
+  BitStringMatch |
+  HexStringMatch |
+  OctetStringMatch |
+  SubsetMatch |
+  SupersetMatch
+
+This basically resolves the ambiguity in favor of INNER & operators in case there is a shift/reduce conflict.
+
+
+
+
+
+ + + + + + + + + + +
+ (0009840) +
+ Ina Schieferdecker    +
+ 30-11-2010 11:21    +
+ 		+ + + + +
+ Updated the resolution (v8) acc. to Jacobs feedback - please check
+
+
+
+ + + + + + + + + + +
+ (0009872) +
+ Gyorgy Rethy    +
+ 01-12-2010 09:16    +
+ 		+ + + + +
+ First example corrected ("*" was missing in the middle template to be concatenated). See in CR5513_resolution v9.doc
+
+
+
+ + + + + + + + + + +
+ (0009878) +
+ Ina Schieferdecker    +
+ 01-12-2010 10:11    +
+ 		+ + + + +
+ Fixed BNF issue on WildcardLengthMatch
+
+
+
+ + + + + + + + + + +
+ (0009978) +
+ Ina Schieferdecker    +
+ 15-12-2010 00:41    +
+ 		+ + + + +
+ One last correction for WildcardLengthMatch:
+
+128. WildcardLengthMatch ::= LengthKeyword "(" ConstantExpression ")"
+
+ + diff --git a/docs/mantis/CR5514.md b/docs/mantis/CR5514.md new file mode 100644 index 0000000000000000000000000000000000000000..b82e4a533b22156e29a7ec66a5d57992e9f8e849 --- /dev/null +++ b/docs/mantis/CR5514.md @@ -0,0 +1,203 @@ + + + + + + + + + + + + + 0005514: Modulepars, global constants & control defs. shall not be of behaviour type with runs on self - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Behaviour Types (ES 202 785)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005514Ext Pack: Behaviour Types (ES 202 785)Technicalpublic15-04-2010 16:4813-12-2010 13:34
ReporterGyorgy Rethy 
Assigned ToJens Grabowski 
PriorityhighSeveritymajorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv1.2.1 (published 2011-05)Fixed in Versionv1.2.1 (published 2011-05) 
Clause Reference(s)Ext. Beh. types, $5.4, $5.5
Source (company - Author)L.M.Ericsson
Summary0005514: Modulepars, global constants & control defs. shall not be of behaviour type with runs on self
DescriptionUsing "runs on self" in a behaviour type definition causes that runs on compatibility is checked between the function (altstep/testcase), which is enclosing the assignment, and the runs on clause of the function (altstep/testcase), the reference of which is being assigned. In case of component type definitions compatibility i checked against the comp. type definition itself.
+
+However, in case of module parameters, global constants and control part definitions the enclosing entity (the module or the control part) has no runs on clause, therefore compatibility check is not possible.
+
+Hence module parameters, global constants and control part local constants and variables shall not be of behaviour types using "runs on self" (pls. note, runs on self is not allowed for testcase types, thus this problem does not occur for definitions of testcase types).
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Fileszip CR5514-Resolution-ver1-100701-Jens.zip (12,540) 01-07-2010 14:44
http://oldforge.etsi.org/mantis/file_download.php?file_id=2395&type=bug
Issue History
Date ModifiedUsernameFieldChange
15-04-2010 16:48Gyorgy RethyNew Issue
15-04-2010 16:48Gyorgy RethyClause Reference(s) => Ext. Beh. types, $5.4, $5.5
15-04-2010 16:48Gyorgy RethySource (company - Author) => L.M.Ericsson
28-06-2010 16:40Gyorgy RethyStatusnew => assigned
28-06-2010 16:40Gyorgy RethyAssigned To => Jens Grabowski
29-06-2010 10:48Gyorgy RethyProjectTTCN-3 Change Requests => Ext Pack: Behaviour Types (ES 202 785)
29-06-2010 10:51Gyorgy RethyNote Added: 0009398
01-07-2010 14:44Jens GrabowskiNote Added: 0009451
01-07-2010 14:44Jens GrabowskiFile Added: CR5514-Resolution-ver1-100701-Jens.zip
01-07-2010 14:45Jens GrabowskiAssigned ToJens Grabowski => Gyorgy Rethy
01-07-2010 15:06Gyorgy RethyNote Added: 0009452
01-07-2010 15:06Gyorgy RethyAssigned ToGyorgy Rethy => Jens Grabowski
01-07-2010 15:06Gyorgy RethyStatusassigned => resolved
01-07-2010 15:06Gyorgy RethyResolutionopen => fixed
02-07-2010 10:29Jens GrabowskiStatusresolved => closed
02-07-2010 10:29Jens GrabowskiNote Added: 0009464
13-12-2010 13:33Gyorgy RethyStatusclosed => feedback
13-12-2010 13:33Gyorgy RethyResolutionfixed => reopened
13-12-2010 13:34Gyorgy RethyNote Added: 0009956
13-12-2010 13:34Gyorgy RethyStatusfeedback => closed
13-12-2010 13:34Gyorgy RethyResolutionreopened => fixed
13-12-2010 13:34Gyorgy RethyFixed in Version => v1.2.1
13-12-2010 13:34Gyorgy RethyTarget Version => v1.2.1
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009398) +
+ Gyorgy Rethy    +
+ 29-06-2010 10:51    +
+ 		+ + + + +
+ Agreed in principle, produce proposed text.
+
+
+
+ + + + + + + + + + +
+ (0009451) +
+ Jens Grabowski    +
+ 01-07-2010 14:44    +
+ 		+ + + + +
+ Resolution proposal uploaded, assigned to György for proofreading.
+
+
+
+ + + + + + + + + + +
+ (0009452) +
+ Gyorgy Rethy    +
+ 01-07-2010 15:06    +
+ 		+ + + + +
+ OK with me.
+
+
+
+ + + + + + + + + + +
+ (0009464) +
+ Jens Grabowski    +
+ 02-07-2010 10:29    +
+ 		+ + + + +
+ CR Implemented in Draft and uploaded onto the Latest Drafts Section of the ETSI MTS portal (Early Draft, status 0.0.1).
+
+
+
+ + + + + + + + + + +
+ (0009956) +
+ Gyorgy Rethy    +
+ 13-12-2010 13:34    +
+ 		+ + + + +
+ Target version and fixed in version are added to CR and it is closed.
+
+ + diff --git a/docs/mantis/CR5518.md b/docs/mantis/CR5518.md new file mode 100644 index 0000000000000000000000000000000000000000..58bd57df2cb81561827737d2f2523b28e78efcae --- /dev/null +++ b/docs/mantis/CR5518.md @@ -0,0 +1,316 @@ + + + + + + + + + + + + + 0005518: Add int2enum predefined function - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005518Part 01: TTCN-3 Core LanguageNew Featurepublic23-04-2010 10:3214-12-2010 13:20
ReporterGyorgy Rethy 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.1.1 (published 2009-06) 
Target Versionv4.3.1 (published 2011-06)Fixed in Versionv4.3.1 (published 2011-06) 
Clause Reference(s)new
Source (company - Author)L.M.Ericsson
Summary0005518: Add int2enum predefined function
DescriptionConverting between the enumareted and integer type has been a pain in TTCN-3, required - in worth case - two external functions for each enumerated (OK, in real life less, but still...). Introducing enum2int solved half of the problem. users like it. But now users are requesting the "second half" of the solution, conversion from integer to enumerated. Reasons of - at least one of the users - are:
+"I have some values which are (correctly) handled by test ports as integer types.
+But, I'd like to internally handle them as enumerated, for several reasons:
+  - there is a finite number of values for them.
+  - enum values are more human readable in source code than integer.
+  - ttcn log shows enum values with both: label and integer values
+    (const values are only shown as integer, without its label value).
+
+So, when receiving these values, I found the need to convert
+them from integer to the internal enumerated value.
+
+Is there an elegant way to solve this (better than a select/case function)?"
Steps To Reproduce
Additional InformationProposed solution: introduce the int2enum predefined function with the signature:
+
+int2enum (in integer int, out <any defined enumerated type> enum) returm integer;
+
+i.e. the second parameter shall be a variable and the type of this variable defines the enumerated type to which the integer has to be mapped. The return value shall return 0 if the conversion is successful or non-zero if unsuccessful (it needs further discussion if we want to differentiate the erro cases - and how many of them). I think it is needed because in the case of an integer->enum conversion there is quite a high probability that the in integer value does not have an equivalent enum value. If not handling this type of error case via the return value, user who wants to write a robust code ends up with select case statements again and, in fact, the int2enum predefined function would become useless.
TagsNo tags attached.
Relationships
Attached Fileszip CR5518-Resolution-Jens-100630.zip (39,856) 30-06-2010 18:34
http://oldforge.etsi.org/mantis/file_download.php?file_id=2390&type=bug
doc CR5518-Resolution-Gyorgy-100701.doc (212,480) 01-07-2010 09:07
http://oldforge.etsi.org/mantis/file_download.php?file_id=2391&type=bug
doc CR5518-Resolution-Jens-100830.doc (213,504) 31-08-2010 09:28
http://oldforge.etsi.org/mantis/file_download.php?file_id=2417&type=bug
doc CR5518-Resolution-101201.doc (213,504) 01-12-2010 09:26
http://oldforge.etsi.org/mantis/file_download.php?file_id=2447&type=bug
Issue History
Date ModifiedUsernameFieldChange
23-04-2010 10:32Gyorgy RethyNew Issue
23-04-2010 10:32Gyorgy RethyClause Reference(s) => new
23-04-2010 10:32Gyorgy RethySource (company - Author) => L.M.Ericsson
28-06-2010 16:38Gyorgy RethyStatusnew => assigned
28-06-2010 16:38Gyorgy RethyAssigned To => Jens Grabowski
29-06-2010 10:48Gyorgy RethyNote Added: 0009397
29-06-2010 10:48Gyorgy RethyTarget Version => Edition 4.3.1 (not yet published)
30-06-2010 18:34Jens GrabowskiFile Added: CR5518-Resolution-Jens-100630.zip
30-06-2010 18:35Jens GrabowskiNote Added: 0009438
30-06-2010 18:35Jens GrabowskiAssigned ToJens Grabowski => Gyorgy Rethy
01-07-2010 09:07Gyorgy RethyNote Added: 0009440
01-07-2010 09:07Gyorgy RethyFile Added: CR5518-Resolution-Gyorgy-100701.doc
01-07-2010 09:08Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
01-07-2010 09:08Gyorgy RethyStatusassigned => resolved
01-07-2010 09:08Gyorgy RethyResolutionopen => fixed
01-07-2010 09:08Gyorgy RethyFixed in Version => Edition 4.2.2 (not yet published)
05-07-2010 13:43Jacob Wieland - SpirentStatusresolved => feedback
05-07-2010 13:43Jacob Wieland - SpirentResolutionfixed => reopened
05-07-2010 13:43Jacob Wieland - SpirentNote Added: 0009479
13-07-2010 11:47Gyorgy RethyNote Added: 0009518
30-08-2010 12:22Gyorgy RethyStatusfeedback => assigned
30-08-2010 12:22Gyorgy RethyAssigned ToIna Schieferdecker => Jens Grabowski
31-08-2010 09:28Jens GrabowskiFile Added: CR5518-Resolution-Jens-100830.doc
31-08-2010 09:31Jens GrabowskiNote Added: 0009659
31-08-2010 09:31Jens GrabowskiAssigned ToJens Grabowski => Gyorgy Rethy
01-12-2010 09:26Gyorgy RethyFile Added: CR5518-Resolution-101201.doc
01-12-2010 09:28Gyorgy RethyNote Added: 0009873
01-12-2010 09:28Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
01-12-2010 09:28Gyorgy RethyStatusassigned => resolved
01-12-2010 09:28Gyorgy RethyResolutionreopened => fixed
01-12-2010 09:28Gyorgy RethyFixed in VersionEdition 4.2.2 (not yet published) => Edition 4.3.1 (not yet published)
14-12-2010 12:52Ina SchieferdeckerNote Added: 0009963
14-12-2010 13:20Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009397) +
+ Gyorgy Rethy    +
+ 29-06-2010 10:48    +
+ 		+ + + + +
+ Agreed in principle, create proposed text.
+
+
+
+ + + + + + + + + + +
+ (0009438) +
+ Jens Grabowski    +
+ 30-06-2010 18:35    +
+ 		+ + + + +
+ Resolution Version 1 uploaded, assigned to György for proofreading.
+
+
+
+ + + + + + + + + + +
+ (0009440) +
+ Gyorgy Rethy    +
+ 01-07-2010 09:07    +
+ 		+ + + + +
+ Its OK, just some minor editorials. See CR5518-Resolution-Gyorgy-100701.doc.
+
+
+
+ + + + + + + + + + +
+ (0009479) +
+ Jacob Wieland - Spirent    +
+ 05-07-2010 13:43    +
+ 		+ + + + +
+ I would strongly vote for a void-function and treat the error cases as with all other conversion functions as a testcase error. The proposed approach seems inconsistent with the rest of the language in that regard. Error handling should not be necessary on the TTCN-3 language level.
+
+
+
+ + + + + + + + + + +
+ (0009518) +
+ Gyorgy Rethy    +
+ 13-07-2010 11:47    +
+ 		+ + + + +
+ This is also a possible approach, OK, don't include this CR to v4.2.2 but let leave the discussion for the next session.
+
+
+
+ + + + + + + + + + +
+ (0009659) +
+ Jens Grabowski    +
+ 31-08-2010 09:31    +
+ 		+ + + + +
+ Last note from Jacob was accepted and the resolution from 30.08.2010 resolves the CR accordingly. Assigned for proofreading to György.
+
+
+
+ + + + + + + + + + +
+ (0009873) +
+ Gyorgy Rethy    +
+ 01-12-2010 09:28    +
+ 		+ + + + +
+ One minor editorial in aneex C text, "converts and integer value" -> "converts an integer value". Final version is in CR5518-Resolution-101201.doc
+
+
+
+ + + + + + + + + + +
+ (0009963) +
+ Ina Schieferdecker    +
+ 14-12-2010 12:52    +
+ 		+ + + + +
+ Implemented as proposed.
+
+ + diff --git a/docs/mantis/CR5553.md b/docs/mantis/CR5553.md new file mode 100644 index 0000000000000000000000000000000000000000..6b563e6020ace11a75d7df199bd21de5bd9b3f06 --- /dev/null +++ b/docs/mantis/CR5553.md @@ -0,0 +1,1116 @@ + + + + + + + + + + + + + 0005553: Interpretation of import mechanism - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005553Part 01: TTCN-3 Core LanguageTechnicalpublic10-06-2010 12:3422-07-2010 12:57
ReporterWolfgang Seka 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.3.1 (published 2011-06)Fixed in Versionv4.2.2 (interim 2010) 
Clause Reference(s)8.2.3
Source (company - Author)MCC160
Summary0005553: Interpretation of import mechanism
DescriptionThere seem to be different interpretations of the import mechanism as defined in cl. 8.2.3 of part 1. That results in the problem, that some compilers require additional import statements but on the other hand according to quality checks these import statements are not necessary.
+=> it shall be evaluated whether cl. 8.2.3 needs clarification and which mechanism is intended.
+There is an example in the "Additional Information" illustrating the problem.
+
+Note: out of six compilers three of them follow one interpretation and the other three follow the other interpretation.
Steps To Reproduce
Additional InformationThe following example shows in principle the problem we have in the LTE conformance test suite (note that there may be further similar problems).
+
+Example:
+ModuleA: type enumerated MyEnum_Type {valueX, valueY};
+ModuleB: modulepar {
+            MyEnum_Type px_MyModulePar := valueX;
+          }
+ModuleC: ...
+          if (px_MyModulePar == valueY) { ...}
+          ...
+
+Question: Does ModuleC need to import ModuleA to know about valueX and valueY ??
+
+Reference: an argument that this import is not necessary can be restriction e) of cl. 8.2.3.1 - but the whole clause is hard to understand.
TagsNo tags attached.
Relationships
related to 0005834closed Ina Schieferdecker Enumeration values are of local scope - example is to be corrected 
Attached Filesdoc CR5553_resolution.doc (143,872) 29-06-2010 18:52
http://oldforge.etsi.org/mantis/file_download.php?file_id=2383&type=bug
doc CR5553_resolution v2.doc (165,888) 01-07-2010 14:39
http://oldforge.etsi.org/mantis/file_download.php?file_id=2394&type=bug
doc CR5553_resolution v3.doc (168,448) 02-07-2010 11:31
http://oldforge.etsi.org/mantis/file_download.php?file_id=2400&type=bug
doc CR5553_resolution v4.doc (171,520) 12-07-2010 16:27
http://oldforge.etsi.org/mantis/file_download.php?file_id=2407&type=bug
doc CR5553_resolution v5.doc (171,520) 13-07-2010 11:43
http://oldforge.etsi.org/mantis/file_download.php?file_id=2408&type=bug
Issue History
Date ModifiedUsernameFieldChange
10-06-2010 12:34Wolfgang SekaNew Issue
10-06-2010 12:34Wolfgang SekaClause Reference(s) => 8.2.3
10-06-2010 12:34Wolfgang SekaSource (company - Author) => MCC160
28-06-2010 16:11Gyorgy RethyStatusnew => assigned
28-06-2010 16:11Gyorgy RethyAssigned To => Gyorgy Rethy
29-06-2010 10:45Gyorgy RethyNote Added: 0009396
29-06-2010 10:46Gyorgy RethyProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
29-06-2010 10:46Gyorgy RethyTarget Version => Edition 4.3.1 (not yet published)
29-06-2010 16:37Gyorgy RethyNote Added: 0009415
29-06-2010 16:41Gyorgy RethyNote Edited: 0009415
29-06-2010 16:43Gyorgy RethyNote Edited: 0009415
29-06-2010 16:48Gyorgy RethyNote Edited: 0009415
29-06-2010 17:01Gyorgy RethyNote Edited: 0009415
29-06-2010 17:01Gyorgy RethyNote Edited: 0009415
29-06-2010 17:06Gyorgy RethyNote Added: 0009418
29-06-2010 17:08Gyorgy RethyNote Edited: 0009418
29-06-2010 17:21Gyorgy RethyNote Edited: 0009418
29-06-2010 17:22Gyorgy RethyNote Edited: 0009415
29-06-2010 17:22Gyorgy RethyNote Edited: 0009418
29-06-2010 18:35Gyorgy RethyNote Edited: 0009418
29-06-2010 18:50Gyorgy RethyNote Added: 0009419
29-06-2010 18:52Gyorgy RethyFile Added: CR5553_resolution.doc
29-06-2010 18:53Gyorgy RethyNote Edited: 0009418
30-06-2010 11:11Jacob Wieland - SpirentNote Added: 0009425
30-06-2010 11:44Gyorgy RethyNote Added: 0009426
30-06-2010 11:45Gyorgy RethyNote Edited: 0009426
30-06-2010 11:46Gyorgy RethyNote Edited: 0009426
30-06-2010 11:46Gyorgy RethyNote Edited: 0009426
30-06-2010 11:54Gyorgy RethyAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
30-06-2010 11:54Gyorgy RethyAssigned ToJacob Wieland - Spirent => Jens Grabowski
30-06-2010 12:13Jacob Wieland - SpirentNote Added: 0009428
30-06-2010 12:17Jacob Wieland - SpirentNote Edited: 0009428
30-06-2010 12:20Jacob Wieland - SpirentNote Edited: 0009428
30-06-2010 12:26Jacob Wieland - SpirentNote Added: 0009429
30-06-2010 14:27Gyorgy RethyNote Added: 0009431
30-06-2010 14:31Gyorgy RethyNote Added: 0009432
30-06-2010 14:54Gyorgy RethyNote Edited: 0009431
30-06-2010 15:00Jacob Wieland - SpirentNote Added: 0009433
30-06-2010 17:39Gyorgy RethyNote Added: 0009437
30-06-2010 17:40Gyorgy RethyNote Edited: 0009437
30-06-2010 17:42Gyorgy RethyNote Edited: 0009437
30-06-2010 17:43Gyorgy RethyNote Edited: 0009437
30-06-2010 17:45Gyorgy RethyNote Edited: 0009437
30-06-2010 17:46Gyorgy RethyNote Edited: 0009437
01-07-2010 11:26Jacob Wieland - SpirentNote Added: 0009445
01-07-2010 12:01Gyorgy RethyAssigned ToJens Grabowski => Gyorgy Rethy
01-07-2010 14:39Gyorgy RethyFile Added: CR5553_resolution v2.doc
01-07-2010 14:43Gyorgy RethyNote Added: 0009450
01-07-2010 14:45Gyorgy RethyAssigned ToGyorgy Rethy => Jens Grabowski
02-07-2010 09:51Jens GrabowskiNote Added: 0009461
02-07-2010 09:51Jens GrabowskiStatusassigned => resolved
02-07-2010 09:51Jens GrabowskiResolutionopen => fixed
02-07-2010 09:54Jens GrabowskiStatusresolved => feedback
02-07-2010 09:54Jens GrabowskiResolutionfixed => reopened
02-07-2010 09:54Jens GrabowskiStatusfeedback => assigned
02-07-2010 09:54Jens GrabowskiAssigned ToJens Grabowski => Ina Schieferdecker
02-07-2010 09:55Jens GrabowskiStatusassigned => resolved
02-07-2010 09:55Jens GrabowskiResolutionreopened => fixed
02-07-2010 10:55Jacob Wieland - SpirentStatusresolved => feedback
02-07-2010 10:55Jacob Wieland - SpirentResolutionfixed => reopened
02-07-2010 10:55Jacob Wieland - SpirentNote Added: 0009465
02-07-2010 11:12Gyorgy RethyStatusfeedback => assigned
02-07-2010 11:12Gyorgy RethyAssigned ToIna Schieferdecker => Gyorgy Rethy
02-07-2010 11:12Gyorgy RethyNote Added: 0009467
02-07-2010 11:31Gyorgy RethyFile Added: CR5553_resolution v3.doc
02-07-2010 11:32Gyorgy RethyNote Added: 0009468
02-07-2010 12:05Jacob Wieland - SpirentNote Added: 0009471
02-07-2010 12:32Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
02-07-2010 12:32Gyorgy RethyStatusassigned => resolved
07-07-2010 09:33Jens GrabowskiStatusresolved => feedback
07-07-2010 09:33Jens GrabowskiNote Added: 0009481
07-07-2010 09:35Jens GrabowskiAssigned ToIna Schieferdecker => Gyorgy Rethy
07-07-2010 09:35Jens GrabowskiStatusfeedback => assigned
12-07-2010 16:27Gyorgy RethyFile Added: CR5553_resolution v4.doc
12-07-2010 16:29Gyorgy RethyNote Added: 0009514
12-07-2010 16:29Gyorgy RethyNote Edited: 0009514
12-07-2010 16:30Gyorgy RethyNote Edited: 0009514
12-07-2010 16:31Gyorgy RethyAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
12-07-2010 16:31Gyorgy RethyNote Edited: 0009514
13-07-2010 11:42Gyorgy RethyNote Added: 0009516
13-07-2010 11:43Gyorgy RethyNote Edited: 0009516
13-07-2010 11:43Gyorgy RethyFile Added: CR5553_resolution v5.doc
13-07-2010 11:57Jacob Wieland - SpirentNote Added: 0009519
14-07-2010 10:35Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Ina Schieferdecker
14-07-2010 10:36Jacob Wieland - SpirentStatusassigned => resolved
14-07-2010 10:36Jacob Wieland - SpirentFixed in Version => Edition 4.2.2 (not yet published)
14-07-2010 10:36Jacob Wieland - SpirentResolutionreopened => fixed
22-07-2010 12:56Ina SchieferdeckerNote Added: 0009559
22-07-2010 12:56Ina SchieferdeckerStatusresolved => closed
30-11-2010 15:38Ina SchieferdeckerRelationship addedrelated to 0005834
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009396) +
+ Gyorgy Rethy    +
+ 29-06-2010 10:45    +
+ 		+ + + + +
+ Clarify the issue with Wolfgang.
+Analyze possible ambiguity of the current text.
+
+
+
+ + + + + + + + + + +
+ (0009415) +
+ Gyorgy Rethy    +
+ 29-06-2010 16:37    +
(edited on: 29-06-2010 17:22)
+ 		+ + + + +
+ Let complete and extend the example:
+module A {
+  type enumerated MyEnum_Type {valueX, valueY}
+  type record MyRec { integer a, integer b }
+  type component MyComp { var MyRec v_Rec := { a := 5 } }
+}
+
+module B {
+  import from A all;
+  modulepar MyEnum_Type px_MyModulePar := valueY;
+  type component MyCompUser extends MyComp {}
+}
+
+module C {
+  import from B all;
+//but some tools also requiring one of this:
+// import from A all; //or
+// import from B { import all }
+  testcase TC() runs on MyCompUser {
+    if (px_MyModulePar == valueY) {
+      log ("name valueY is know in C without explicit import");
+      setverdict(pass)
+    }
+    if (v_Rec.a == 5) {
+      v_Rec.b := v_Rec.a;
+      log ("Both the variable name v_Rec and the record field names are known in C without explicit import", v_Rec);
+      setverdict (pass)
+    }
+  }
+  control {
+    execute (TC())
+  }
+}
+
+The solution shall be consistent for both (and all similar) cases.
+
+
+
+
+
+ + + + + + + + + + +
+ (0009418) +
+ Gyorgy Rethy    +
+ 29-06-2010 17:06    +
(edited on: 29-06-2010 18:53)
+ 		+ + + + +
+ The standard currently specifies
+in clause 8.2.3.1:
+
+in Table 8: what are the local definitions of different importable definitions. Enumeration values are explicitly mentioned as local definitions of the enumerated type.
+
+in Restrictions:
+c) A definition is imported together with its name and all local definitions.
+NOTE 5: A local definition, e.g. a field name of a user-defined record type, has only meaning in the context of the definitions in which it is defined, e.g. a field name of a record type can only be used to access a field of the record type and not outside this context.
+d) A definition is imported together with all information of referenced definitions that are necessary for the usage of the imported definition, independent of the visibility of the referenced definitions (see clause 8.2.5).
+NOTE 6: If a module A imports a definition from module B that uses a type reference defined in module C, the corresponding information necessary for the usage of that type is automatically imported into module A. Identifiers of referenced definitions are not automatically imported.
+
+------------------------------------end quotation-------------------------
+My conclusion from the above is that the standard is clear enough: in module C of the example above no direct import from module A is needed to use the value valueY in the context of the module parameter px_MyModulePar.
+
+But adding the example to the standard would not harm.
+
+
+
+
+
+ + + + + + + + + + +
+ (0009419) +
+ Gyorgy Rethy    +
+ 29-06-2010 18:50    +
+ 		+ + + + +
+ See proposed resolution in CR5553_resolution.doc.
+
+
+
+ + + + + + + + + + +
+ (0009425) +
+ Jacob Wieland - Spirent    +
+ 30-06-2010 11:11    +
+ 		+ + + + +
+ I completely DISAGREE!
+
+The sentence
+"A definition is imported together with all information of referenced definitions that are necessary for the usage of the imported definition, independent of the visibility of the referenced definitions (see clause 8.2.5)." might imply what you mean, but since 'usage of the imported definition' is not clearly defined, it might also not.
+
+Since it is not necessary to know valueX so that px_MyModulePar can be used in a lot of cases, I don't think that the above sentence applies here.
+
+So, either it must be more clearly defined what 'necessary for the usage of the imported definition', especially for entities of enumerated types, means or the standard is ambiguous and so, of course, the tools can interpret this sentence however they want. All examples unfortunately focus only on field names necessary to write down values of structured types, so this does not help in clearing this up.
+
+In my interpretation, the enumerated type should be directly (or via import import) imported so that its enumerated values are known in the importing module.
+
+
+
+ + + + + + + + + + +
+ (0009426) +
+ Gyorgy Rethy    +
+ 30-06-2010 11:44    +
(edited on: 30-06-2010 11:46)
+ 		+ + + + +
+ Hi Jacob,
+
+Your comment is off target. The quoted sentence is about referenced definitions. What are they? e.g. in case of a record type:
+module A {
+  type record MyRec { MyUnion u, MySetOf s }
+}
+the type definitions MyUnion and MySetOf are referenced from MyRec but they are not needed to assign a value to an instance of MyRec. e.g.
+module B {
+  import from A { type MyRec }
+  const MyRec c_MyRec := { u := { somechoice := 5 }, {} }
+}
+
+Enumerated types do reference nothing, they just do define the value set of the type. This is given explicitly in Table 8:
+
+.....................local defs_.............referenced defs
+enumerated......concrete values.........-
+struct. type....field names.............field types
+....................nested type defs
+
+So, I think my conclusion on what the standard specifies today is correct.
+
+Btw. I think it is clear and also Wolfgang's example shows that the allowed values of a type are necessary to use of the instance of that type.
+
+
+
+
+
+ + + + + + + + + + +
+ (0009428) +
+ Jacob Wieland - Spirent    +
+ 30-06-2010 12:13    +
(edited on: 30-06-2010 12:20)
+ 		+ + + + +
+ Yes, there are SOME usages, where the value needs to be known (i.e. those are those, where the value should be imported explicitly via importing its type), but there are also lots of usages, where the values do not need to be known: usage as parameter, usage as assignment, usage as comparison with another (non-enum-value) expression, etc. etc.
+
+So, NO, it is not clear that the implicit import of the values of the type of an enum-modulepar is necessary for the usage of that modulepar.
+
+Also, my comment was NOT off target. The imported definition was the modulepar. This definition references the enum type. The implicit information necessary for the usage of that referenced enum type would be the enum values defined by that type.
+
+To illustrate my interpretation, take the following example:
+
+module A {
+  type enumerated E { a, b }
+  function f(E x) { ... }
+}
+
+module B {
+  import from A { type E }
+  modulepar E b;
+}
+
+module C {
+  import from A { function f }
+  import from B { modulepar b }
+
+  function g() {
+    f(b); // If the implicit-import-of-enum-values interpretation is used
+          // this should be ambiguous (A.b vs. B.b),
+          // even though everything used is apparently
+          // explicitly imported
+  }
+}
+
+This example shows how confusing such implicit imports can be. If it is not possible to avoid name-clashes even in cases where everything is imported explicitly, I don't think that speaks for a good language design.
+
+Therefore, I stand by my opinion that the local names of enumerated values should only be known, if their type is EXPLICITLY imported. That way, no such confusion can arise.
+
+If you are about to argue that that would be different than for really structured types (record/union/set), then I would argue that there, the names are only usable locally (in a field-assignment context or in a field reference) so there can be no nameclashes with other imported identifiers like for enumerated values.
+
+
+
+
+
+ + + + + + + + + + +
+ (0009429) +
+ Jacob Wieland - Spirent    +
+ 30-06-2010 12:26    +
+ 		+ + + + +
+ Since I don't want to appear all destructive, I will propose a constructive solution to the problem posed by implict imports, as well:
+
+If an enum-value name (and those are the only ones that cause such nameclash-problem) is imported explicitly and implicitly, the identifier shall be resolved using the explicit import in favor of the implicit import.
+
+Thereby, it is possible for the user to control (via explicit imports) which names should be unambiguous in their module.
+
+Such a sentence would need to be added to the definition of the import statement.
+
+
+
+ + + + + + + + + + +
+ (0009431) +
+ Gyorgy Rethy    +
+ 30-06-2010 14:27    +
(edited on: 30-06-2010 14:54)
+ 		+ + + + +
+ Hi Jacob,
+
+OK let's take a cold start. When we talk about "transitive import" like in the case
+module A defines type -> module B defines value -> module C uses the value;
+you are right, the value imported to module C will have a referenced definition, as you correctly wrote "The imported definition was the modulepar. This definition references the enum type. The implicit information necessary for the usage of that referenced enum type would be the enum values defined by that type."
+
+But I don't understand why in this concrete case the enumeration values should not be imported. As I quoted above,
+"d) A definition is imported together with all information of referenced definitions that are necessary for the usage of the imported definition, independent of the visibility of the referenced definitions (see clause 8.2.5).
+NOTE 6: If a module A imports a definition from module B that uses a type reference defined in module C, the corresponding information necessary for the usage of that type is automatically imported into module A. Identifiers of referenced definitions are not automatically imported."
+In the note exactly the case we are talking about is described. So, I do not understand, where is the ambiguity?
+
+Can the equality if (px_MyModulePar == valueY) be executed (or even checked) without knowing the values of the type? I don't think so. So, at least in this concrete case, into this concrete module C the module parameter shall be imported together with the "information necessary for the usage of a referenced definition"; if it is not done like this, the concrete tool in this concrete case fails to comply with the standard.
+
+Pls. note, that enumeration values ARE NOT GLOBAL NAMES. They have meaning in the context of the given enumerated type only. This is true even if they impose some restriction on global names. So, e.g. in the case
+module A {
+  type enumerated Enum { e1, e2 }
+}
+module B {
+  import from A all;
+  const integer e1 := 1;
+  const integer e2 := e1;
+}
+no name clash occur as in module B the name e1 and e2 are used in the context of the integer type! This is defined unambiguously in $6.2.4: "Enumeration identifiers shall be unique within the enumerated type (but do not have to be globally unique) and are consequently visible within the context of the given type only."
+
+
+I don't understand why are you writing that "If it is not possible to avoid name-clashes even in cases where everything is imported explicitly, I don't think that speaks for a good language design." ? In TTCN-3 it is possible to avoid name clashes by using the qualified names. It is also unclear to me how an explicit import statement would help solving name clashes. The rules today are not importing the name "Enum" in the example above. 1 name less in module B. But users tend to like short code lines, so they are practically always using the import all option. And this results importing a lots of names that are not referenced at all in the importing module. So, your proposal would be very unpractical, not giving any advantage, but causing a lots of unnecessary extra (potential) name clashes.
+
+And one more point. Changing the standard would raise a huge backward compatibility problem. Users of tools working according to the standard, i.e. not requiring import from A in module C, have no import statements in their codes. Therefore changing the standard would be an issue for them. Users of the tools requiring the extra import statement will not notice anything if the tool "below them" changes to the standard behaviour. So, for them there is no compatibility problem.
+
+
+
+
+
+ + + + + + + + + + +
+ (0009432) +
+ Gyorgy Rethy    +
+ 30-06-2010 14:31    +
+ 		+ + + + +
+ My comment posted at 13:27 responded to Jacob's comment posted at 11:13. While writing a comment, no new contributions can be seen.
+
+Jacob, could you pls. elaborate more on your proposal, probably an example would help to understand it.
+
+Have you noticed the sentence(s) in the proposal saying, that names of the values take precedence over global definition names?
+
+
+
+ + + + + + + + + + +
+ (0009433) +
+ Jacob Wieland - Spirent    +
+ 30-06-2010 15:00    +
+ 		+ + + + +
+ > Jacob, could you pls. elaborate more on your proposal, probably an example would help to understand it.
+
+I'll give a few examples:
+
+module A {
+ type enumerated E { a, b }
+ function f(E x) { ... }
+}
+
+module B {
+  import from A { function f }
+  function g() {
+    f(a); // => f(A.a) because of implicit import and parameter context
+  }
+}
+
+module C {
+  import from A { type E }
+  modulepar E b, x;
+}
+
+module D {
+  import from C { modulepar x, b }
+  type enumerated E2 { a, b }
+
+  function g() {
+    if (x == a) { // works (C.x == A.a)
+    }
+    if (x == b) { // works (C.x == C.b)
+    }
+    if (a == b) { // works (A.a == C.b) (there is no context suggesting E2)
+    }
+  }
+}
+
+module F {
+  import from A { function f }
+  import from C { modulepar b }
+
+  function g() {
+    f(b); // => f(C.b) because of explicit import
+    if (b == a) { // => (C.b == A.a) because of explicit import
+    }
+  }
+}
+
+> Have you noticed the sentence(s) in the proposal saying, that names of the values take precedence over global definition names?
+
+Yes, and I'm more in favor of the other way around, if the enumerated type is the same.
+
+On account of the backward compatibility issue for the tools that up-to-now interpreted the enum values without explicit import of the enum types, you are right. But, I think my new proposal addresses this issue adequately.
+
+On the question of disambiguation by the user: There are always two ways to resolve name-clashes (at least, there should be): fewer imports (i.e. explicit imports) or use of qualified names. Since using the qualified names at a thousand places is probably more unacceptable than changing one import statement (to exclude an enumerated type whose values I don't want to use explicitly), I think that the users will rather use the latter than the former, even though the former is always more robust against later changes.
+
+But, if a testsuite opts for the non-lazy approach of using explicit imports, they should be able to control via these imports how the unqualified names shall be resolved. Otherwise, the explicit import is a feature that nobody needs because if it does not help in disambiguation, what is it good for?
+
+
+
+ + + + + + + + + + +
+ (0009437) +
+ Gyorgy Rethy    +
+ 30-06-2010 17:39    +
(edited on: 30-06-2010 17:46)
+ 		+ + + + +
+ OK, we are closer now. Let's look at your examples:
+module D {
+  function g() {
+    if (x == a) { // works (C.x == A.a)
+//Gy: I agree
+    }
+    if (x == b) { // works (C.x == C.b)
+/*Gy: how to compare x with value b of E1? As value b is not a global name, cannot be prefixed. The only way to distinguish them unambiguously is to use the local value without prefix and the global name with an explicit prefix, i.e. x == C.b. This is also more consistent with the previous case, where the name a (without prefix) means the local name. Think about the writer of module D, importing all from module C (this is a usual way of importing), later someone adds a definition with name b to module C and suddenly "by magic" and, mainly without any notification, the behaviour of module D changes! Think about the tester debugging, why his regression test changed verdict from one day to another :(( */
+    }
+    if (a == b) { // works (A.a == C.b) (there is no context suggesting E2)
+// Gy: I agree
+    }
+  }
+}
+
+module F {
+  function g() {
+    f(b); // => f(C.b) because of explicit import
+/* Gy: don't agree, the formal parameter of f is of type E that creates the context. The same backward compatibility problem exists as with the x==b example above */
+    if (b == a) { // => (C.b == A.a) because of explicit import
+// Gy: I agree
+    }
+  }
+}
+
+
+
+
+
+ + + + + + + + + + +
+ (0009445) +
+ Jacob Wieland - Spirent    +
+ 01-07-2010 11:26    +
+ 		+ + + + +
+ If it is true that the enum-value-names cannot be prefixed by the module-name of the module that introduced them (which is another weakness in the whole proposal in my opinion), then of course, you are right that they must have precedence if the context can be clearly determined as an enumerated type as otherwise, they cannot be used in a context that also imports/declares the same name (with the same type).
+
+
+
+ + + + + + + + + + +
+ (0009450) +
+ Gyorgy Rethy    +
+ 01-07-2010 14:43    +
+ 		+ + + + +
+ More detailed clarification on the type context is added to CR5553_resolution v2.doc and a few more examples.
+
+Pls. cross-check it.
+
+
+
+ + + + + + + + + + +
+ (0009461) +
+ Jens Grabowski    +
+ 02-07-2010 09:51    +
+ 		+ + + + +
+ proofreading OK
+
+
+
+ + + + + + + + + + +
+ (0009465) +
+ Jacob Wieland - Spirent    +
+ 02-07-2010 10:55    +
+ 		+ + + + +
+ I have one more problem: backward compatibility the other way around.
+
+There will be a lot of test-suites that used the interpretation of our tool that the enum-value-names are (kind of) global names introduced by the module where they are declared and therefore can be prefixed with the module name for disambiguation purposes.
+
+For backward compatibility of these test-suites it would be good if such qualified names would still be explicitly allowed (maybe as a deprecated feature so the tools can warn the users that this is not a wanted feature anymore).
+
+
+
+ + + + + + + + + + +
+ (0009467) +
+ Gyorgy Rethy    +
+ 02-07-2010 11:12    +
+ 		+ + + + +
+ Good point, I will add this as a deprecated feature.
+
+
+
+ + + + + + + + + + +
+ (0009468) +
+ Gyorgy Rethy    +
+ 02-07-2010 11:32    +
+ 		+ + + + +
+ Added to CR5553_resolution v3.doc, pls. review.
+
+
+
+ + + + + + + + + + +
+ (0009471) +
+ Jacob Wieland - Spirent    +
+ 02-07-2010 12:05    +
+ 		+ + + + +
+ OK by me.
+
+
+
+ + + + + + + + + + +
+ (0009481) +
+ Jens Grabowski    +
+ 07-07-2010 09:33    +
+ 		+ + + + +
+ Request from Andrus Lehtmets (Elvior): Add following note:
+
+"NOTE 7: If a module B imports a value or template or parameter of an
+enumerated type from module A, the enumerated values of this type
+including identifiers are automatically imported to module B."
+
+
+
+ + + + + + + + + + +
+ (0009514) +
+ Gyorgy Rethy    +
+ 12-07-2010 16:29    +
(edited on: 12-07-2010 16:31)
+ 		+ + + + +
+ CR5553_resolution v4.doc:
+The proposed note is re-worded and added to existing Note 6 as a new paragraph (but with unchanged technical content). Pls. proof-read.
+
+
+
+
+
+ + + + + + + + + + +
+ (0009516) +
+ Gyorgy Rethy    +
+ 13-07-2010 11:42    +
(edited on: 13-07-2010 11:43)
+ 		+ + + + +
+ "Implicit" (importing) and a sentence on use of the values are added to the new paragraph of the note. Pls. proof-read, if OK, set to resolved and assign to Ina.
+
+
+
+
+
+ + + + + + + + + + +
+ (0009519) +
+ Jacob Wieland - Spirent    +
+ 13-07-2010 11:57    +
+ 		+ + + + +
+ I think this is now sufficiently clear (together with the examples)
+
+
+
+ + + + + + + + + + +
+ (0009559) +
+ Ina Schieferdecker    +
+ 22-07-2010 12:56    +
+ 		+ + + + +
+ small editorials
+
+ + diff --git a/docs/mantis/CR5562.md b/docs/mantis/CR5562.md new file mode 100644 index 0000000000000000000000000000000000000000..2a88cc87dc9ac66512d475cd573dd52d2d93f41d --- /dev/null +++ b/docs/mantis/CR5562.md @@ -0,0 +1,103 @@ + + + + + + + + + + + + + 0005562: Misleading example - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005562Part 01: TTCN-3 Core LanguageClarificationpublic18-06-2010 12:4529-06-2010 16:50
ReporterGyorgy Rethy 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.1.1 (published 2009-06) 
Target Versionv4.3.1 (published 2011-06)Fixed in Versionv4.2.2 (interim 2010) 
Clause Reference(s)6.2.12
Source (company - Author)L.M.Ericsson
Summary0005562: Misleading example
DescriptionIn clause 6.2.12 the following example is given:
+    // receiving an address value and assigning it to variable MySUTentity
+    PCO.receive(address:*) -> value MySUTentity;
+Strictly speaking, the example is semantically incorrect and misleads the users (see attached mail). Therefore it is proposed to change the example to:
+    // receiving an address value and assigning it to variable MySUTentity
+    PCO.receive(address:?) -> value MySUTentity;
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filestxt Use of symbol AnyValueOrNone in receive operation.txt (1,480) 18-06-2010 12:45
http://oldforge.etsi.org/mantis/file_download.php?file_id=2379&type=bug
Issue History
Date ModifiedUsernameFieldChange
18-06-2010 12:45Gyorgy RethyNew Issue
18-06-2010 12:45Gyorgy RethyClause Reference(s) => 6.2.12
18-06-2010 12:45Gyorgy RethySource (company - Author) => L.M.Ericsson
18-06-2010 12:45Gyorgy RethyFile Added: Use of symbol AnyValueOrNone in receive operation.txt
18-06-2010 13:54Gyorgy RethyDescription Updated
28-06-2010 16:12Gyorgy RethyStatusnew => assigned
28-06-2010 16:12Gyorgy RethyAssigned To => Ina Schieferdecker
29-06-2010 10:41Gyorgy RethyTarget Version => Edition 4.3.1 (not yet published)
29-06-2010 10:42Gyorgy RethyNote Added: 0009395
29-06-2010 16:48Ina SchieferdeckerNote Added: 0009417
29-06-2010 16:49Ina SchieferdeckerStatusassigned => resolved
29-06-2010 16:49Ina SchieferdeckerResolutionopen => fixed
29-06-2010 16:49Ina SchieferdeckerFixed in Version => Edition 4.2.2 (not yet published)
29-06-2010 16:50Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009395) +
+ Gyorgy Rethy    +
+ 29-06-2010 10:42    +
+ 		+ + + + +
+ Typo, correct the example
+
+
+
+ + + + + + + + + + +
+ (0009417) +
+ Ina Schieferdecker    +
+ 29-06-2010 16:48    +
+ 		+ + + + +
+ done as agreed
+
+ + diff --git a/docs/mantis/CR5587.md b/docs/mantis/CR5587.md new file mode 100644 index 0000000000000000000000000000000000000000..4d1f07847fe115153605c5398e7891a31a91c8ed --- /dev/null +++ b/docs/mantis/CR5587.md @@ -0,0 +1,249 @@ + + + + + + + + + + + + + 0005587: Clarification in using functions in special places - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005587Part 01: TTCN-3 Core LanguageClarificationpublic01-07-2010 15:1015-12-2010 00:02
ReporterGyorgy Rethy 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.3.1 (published 2011-06)Fixed in Versionv4.3.1 (published 2011-06) 
Clause Reference(s)???
Source (company - Author)STF160
Summary0005587: Clarification in using functions in special places
DescriptionDear stf393,
+
+another question for clarification:
+we have several places in our test suite where in a receive event the return value of a function is used as parameter of the receive template,
+e.g.
+   myPCO.receive(cr_Mytemplate(f_MyFunction(), ...))
+
+Now in some cases f_MyFunction assigns a verdict and kills the PTC.
+
+Even though this is not explicitly listed in 16.1.4 (or is this considered as a special case of inline template ??) acc. to the philosophy of 16.1.4 I tend to agree that this is not allowed.
+Bute there are some thoughts which may be taken into consideration:
+- When we have a variable getting assigned the function just before the receive statement and use this variable in the receive statement:
+    var MyType v_MyVar := f_MyFunction();
+    myPCO.receive(cr_Mytemplate(v_MyVar, ...))
+
+  That should work anyway - BUT "normal" programmers may not understand the difference and consider this as equivalent.
+
+- Regarding the above examples: Is is it clearly specified (e.g. in part 4) at which point in time the function is performed when being parameter in the receive statement ??
+
+- Currently there is poor support by tools to find this issues; just IBM raises an error
+
+So as a summary: when there are restrictions on functions being used as parameters in receive statements acc. to 16.1.4 how can we achieve that people don't do it wrong ??
+Please note, that this is also an issue of tool compatibility.
+
+Thanks and regards
+Wolfgang
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
01-07-2010 15:10Gyorgy RethyNew Issue
01-07-2010 15:10Gyorgy RethyClause Reference(s) => ???
01-07-2010 15:10Gyorgy RethySource (company - Author) => STF160
01-07-2010 15:12Gyorgy RethyTarget Version => Edition 4.3.1 (not yet published)
01-07-2010 17:18Gyorgy RethyNote Added: 0009457
01-07-2010 17:19Gyorgy RethyNote Edited: 0009457
01-07-2010 17:20Gyorgy RethyNote Edited: 0009457
30-08-2010 12:17Gyorgy RethyStatusnew => assigned
30-08-2010 12:17Gyorgy RethyAssigned To => Jacob Wieland - Spirent
30-08-2010 13:55Jacob Wieland - SpirentNote Added: 0009655
30-08-2010 17:22Jacob Wieland - SpirentNote Added: 0009658
30-08-2010 17:24Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
01-09-2010 11:15Jens GrabowskiNote Added: 0009671
02-09-2010 09:27Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
02-09-2010 09:27Gyorgy RethyStatusassigned => resolved
02-09-2010 09:27Gyorgy RethyResolutionopen => fixed
15-12-2010 00:01Ina SchieferdeckerNote Added: 0009974
15-12-2010 00:01Ina SchieferdeckerStatusresolved => closed
15-12-2010 00:02Ina SchieferdeckerFixed in Version => Edition 4.3.1 (not yet published)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009457) +
+ Gyorgy Rethy    +
+ 01-07-2010 17:18    +
(edited on: 01-07-2010 17:20)
+ 		+ + + + +
+ STF discussion result is:
+Passing a function as actual parameter to an object used in a receive statement is a use of the function at a special place just like the function was called directly in the receiving statement. Hence restrictions of $16.1.4 apply.
+
+The STF agreed that the standard should be checked if all and every such cases are handled adequately.
+
+"Is is it clearly specified (e.g. in part 4) at which point in time the function is performed when being parameter in the receive statement ??" -> it is not defined, as functions called during snapshot evaluation shall not change the snapshot, the exact time of evaluating the functions has no significance. Hence the restrictions of 16.1.4.
+
+Checking those restrictions statically is not easy (for tool implementations). So, the STF should use the IBM tool for checking the quality of the code.
+
+Even if "normal" programmers may not understand the difference, the case
+    var MyType v_MyVar := f_MyFunction();
+    myPCO.receive(cr_Mytemplate(v_MyVar, ...))
+essentially differs from calling the function in the receive statement directly. A stand-alone receive is a shorthand for an alt with one receiving branch plus the activated defaults, thus stimulates a snapshot, while during a simple assignment there is no snapshot involved, i.e. no risk of side effects.
+
+
+
+
+
+ + + + + + + + + + +
+ (0009655) +
+ Jacob Wieland - Spirent    +
+ 30-08-2010 13:55    +
+ 		+ + + + +
+ The following sentence in section 16.1.4
+
+"Value returning functions can be called during communication operations (in templates, template fields or in-line templates)"
+
+should be changed to
+
+"Value returning functions can be called during communication operations (in templates, template fields, in-line templates or as actual parameters)"
+
+This way, all function calls that are used as actual parameters during communication operations must adhere to the non-side-effect restrictions.
+
+(Actually, I think the already existent restriction 'in templates or in-line templates' already covers this as cr_Mytemplate(f_MyFunction(), ...) is a template and the f_MyFunction() call is part of that template expression, but being a bit more explicit doesn't hurt here, either)
+
+
+
+ + + + + + + + + + +
+ (0009658) +
+ Jacob Wieland - Spirent    +
+ 30-08-2010 17:22    +
+ 		+ + + + +
+ please review
+
+
+
+ + + + + + + + + + +
+ (0009671) +
+ Jens Grabowski    +
+ 01-09-2010 11:15    +
+ 		+ + + + +
+ Ok for me.
+
+
+
+ + + + + + + + + + +
+ (0009974) +
+ Ina Schieferdecker    +
+ 15-12-2010 00:01    +
+ 		+ + + + +
+ Implemented as proposed.
+
+ + diff --git a/docs/mantis/CR5588.md b/docs/mantis/CR5588.md new file mode 100644 index 0000000000000000000000000000000000000000..338f33e175efdb8be4fdac52ba15d5aa65f52ced --- /dev/null +++ b/docs/mantis/CR5588.md @@ -0,0 +1,287 @@ + + + + + + + + + + + + + 0005588: Follow-up of CR2105 - Deprecating using addressing without explicit binding the addressing type to the port type - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005588Part 01: TTCN-3 Core LanguageTechnicalpublic02-07-2010 10:3014-12-2010 23:52
ReporterGyorgy Rethy 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.3.1 (published 2011-06)Fixed in Versionv4.3.1 (published 2011-06) 
Clause Reference(s)at least 6.2.9, 6.2.12, 22
Source (company - Author)     
Summary0005588: Follow-up of CR2105 - Deprecating using addressing without explicit binding the addressing type to the port type
DescriptionCR2105 allowed binding a type to be used for addressing to port types. The next step would be to remove the drawbacks of using the address type without explicit declaration of the need to support addressing in the port type definition, i.e. deprecate using to/from in mapped port when no address type is declared in the related port type definition. Pls. note, deprecate does not mean removing from the standard or forbid using it in existing test suites. It is a signal that users should use the new feature in new code and - over a longer period of time - refrain from it also in the old code basis.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0002105closed Ina Schieferdecker address should also be bind to port type 
Attached Filesdoc CR-2105 + CR-5588.doc (97,280) 01-09-2010 10:55
http://oldforge.etsi.org/mantis/file_download.php?file_id=2421&type=bug
doc CR-2105 + CR-5588-Jacob.doc (57,856) 01-09-2010 11:48
http://oldforge.etsi.org/mantis/file_download.php?file_id=2422&type=bug
? core.bnf (55,689) 14-12-2010 23:52
http://oldforge.etsi.org/mantis/file_download.php?file_id=2471&type=bug
Issue History
Date ModifiedUsernameFieldChange
02-07-2010 10:30Gyorgy RethyNew Issue
02-07-2010 10:30Gyorgy RethyClause Reference(s) => at least 6.2.9, 6.2.12, 22
02-07-2010 10:30Gyorgy RethySource (company - Author) =>
02-07-2010 10:48Gyorgy RethyProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
02-07-2010 10:49Gyorgy RethyTarget Version => Edition 4.3.1 (not yet published)
30-08-2010 12:13Gyorgy RethyNote Added: 0009653
30-08-2010 12:14Gyorgy RethyStatusnew => assigned
30-08-2010 12:14Gyorgy RethyAssigned To => Benjamin Zeiss
01-09-2010 10:55Benjamin ZeissNote Added: 0009669
01-09-2010 10:55Benjamin ZeissFile Added: CR-2105 + CR-5588.doc
01-09-2010 10:56Benjamin ZeissAssigned ToBenjamin Zeiss => Jacob Wieland - Spirent
01-09-2010 11:48Jacob Wieland - SpirentNote Added: 0009673
01-09-2010 11:48Jacob Wieland - SpirentFile Added: CR-2105 + CR-5588-Jacob.doc
01-09-2010 11:49Jacob Wieland - SpirentNote Added: 0009674
01-09-2010 17:09Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Jens Grabowski
01-09-2010 17:13Benjamin ZeissAssigned ToJens Grabowski => Ina Schieferdecker
01-09-2010 17:13Benjamin ZeissStatusassigned => resolved
01-09-2010 17:13Benjamin ZeissResolutionopen => fixed
01-09-2010 17:13Benjamin ZeissNote Added: 0009686
14-12-2010 15:39Ina SchieferdeckerRelationship addedrelated to 0002105
14-12-2010 15:41Ina SchieferdeckerNote Added: 0009971
14-12-2010 23:51Ina SchieferdeckerNote Added: 0009972
14-12-2010 23:52Ina SchieferdeckerFile Added: core.bnf
14-12-2010 23:52Ina SchieferdeckerStatusresolved => closed
14-12-2010 23:52Ina SchieferdeckerFixed in Version => Edition 4.3.1 (not yet published)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009653) +
+ Gyorgy Rethy    +
+ 30-08-2010 12:13    +
+ 		+ + + + +
+ global address type has effect on port type defintions in the same module only without local address type reference.
+
+
+
+ + + + + + + + + + +
+ (0009669) +
+ Benjamin Zeiss    +
+ 01-09-2010 10:55    +
+ 		+ + + + +
+ Attached a rephrasing proposal to the CR 2105 proposal to reflect the recommended use.
+
+
+
+ + + + + + + + + + +
+ (0009673) +
+ Jacob Wieland - Spirent    +
+ 01-09-2010 11:48    +
+ 		+ + + + +
+ The following sentence does not make sense in the context of the new port-bound address feature:
+
+"Explicit SUT addresses shall only be generated inside a TTCN‑3 module if the type is defined inside the module (globally or within port type definitions). If the type is not defined inside the module, explicit SUT addresses shall only be passed in as parameters or be received in message fields or as parameters of remote procedure calls."
+
+It should (at least) be changed to:
+
+"Explicit SUT addresses for a globally defined address type shall only be generated inside a TTCN‑3 module if the type is defined inside the module itself. If the type is not defined inside the module, explicit SUT addresses for a global address type shall only be passed in as parameters or be received in message fields or as parameters of remote procedure calls."
+
+In my opinion, the whole sentence could be removed as it is an unnecessary restriction. Why should not module B which imports module A, then use A.address like any other type if it uses a port type defined in module A which has no address-type bound?
+
+==============================================================================
+The example which receives addresses should instead be changed to use the sender/from clause(s) because there you need the agreement between the address variables and the address type.
+
+
+
+ + + + + + + + + + +
+ (0009674) +
+ Jacob Wieland - Spirent    +
+ 01-09-2010 11:49    +
+ 		+ + + + +
+ added my changes in CR-2105 + CR-5588-Jacob.doc
+
+
+
+ + + + + + + + + + +
+ (0009686) +
+ Benjamin Zeiss    +
+ 01-09-2010 17:13    +
+ 		+ + + + +
+ Looks good to me. Assigned to Ina.
+
+
+
+ + + + + + + + + + +
+ (0009971) +
+ Ina Schieferdecker    +
+ 14-12-2010 15:41    +
+ 		+ + + + +
+ The agreed syntax from CR2105 is implemented in part 1:
+
+type port PortTypeIdentifier message "{"
+        [ address Type “;” ]
+        [ map param "(" { FormalValuePar [","] }+ ")" ]
+        [ unmap param "(" { FormalValuePar [","] }+ ")" ]
+        { ( in | out | inout ) { MessageType [ "," ] }+ ";" }
+"}"
+
+etc.
+
+
+
+ + + + + + + + + + +
+ (0009972) +
+ Ina Schieferdecker    +
+ 14-12-2010 23:51    +
+ 		+ + + + +
+ see uploaded BNF for defining address types in ports
+
+ + diff --git a/docs/mantis/CR5601.md b/docs/mantis/CR5601.md new file mode 100644 index 0000000000000000000000000000000000000000..7b8498b55b3c40074a89a458dbea894fe2302d17 --- /dev/null +++ b/docs/mantis/CR5601.md @@ -0,0 +1,239 @@ + + + + + + + + + + + + + 0005601: Erroneous example on matching attributes - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005601Part 01: TTCN-3 Core LanguageClarificationpublic12-07-2010 12:1715-12-2010 00:07
ReporterGyorgy Rethy 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.3.1 (published 2011-06)Fixed in Versionv4.3.1 (published 2011-06) 
Clause Reference(s)15.7.4
Source (company - Author)L.M.Ericsson
Summary0005601: Erroneous example on matching attributes
DescriptionThe example in $15.7.4:
+    type record R {
+        record of integer ri optional
+    }
+    template R r:=
+    {
+        ri := * length (1 .. 6) ifpresent // any value containing 1, 2, 3, 4,
+                                            // 5 or 6 provided it is present
+    }
+
+is not correct:
+- according to the BNF length and ifpresent cannot be applied together;
+- not the numbers 1..6 but lists of 1..6 elements are allowed;
+
+The example should be changed to:
+    template R r:=
+    {
+        ri := { * length (1 .. 6) } ifpresent // any value containing 1, 2, 3, 4, 5 or 6 elements, provided it is present
+    }
+
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
12-07-2010 12:17Gyorgy RethyNew Issue
12-07-2010 12:17Gyorgy RethyClause Reference(s) => 15.7.4
12-07-2010 12:17Gyorgy RethySource (company - Author) => L.M.Ericsson
12-07-2010 16:32Gyorgy RethyProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
12-07-2010 16:33Gyorgy RethyTarget Version => Edition 4.3.1 (not yet published)
30-08-2010 11:51Gyorgy RethyStatusnew => assigned
30-08-2010 11:51Gyorgy RethyAssigned To => Benjamin Zeiss
31-08-2010 11:41Benjamin ZeissNote Added: 0009662
01-09-2010 10:56Benjamin ZeissAssigned ToBenjamin Zeiss => Jacob Wieland - Spirent
01-09-2010 11:22Jacob Wieland - SpirentNote Added: 0009672
01-09-2010 17:07Benjamin ZeissNote Added: 0009683
01-09-2010 17:08Benjamin ZeissStatusassigned => resolved
01-09-2010 17:08Benjamin ZeissResolutionopen => fixed
01-09-2010 17:09Benjamin ZeissAssigned ToJacob Wieland - Spirent => Ina Schieferdecker
01-09-2010 17:09Benjamin ZeissStatusresolved => feedback
01-09-2010 17:09Benjamin ZeissResolutionfixed => reopened
01-09-2010 17:10Benjamin ZeissStatusfeedback => resolved
01-09-2010 17:10Benjamin ZeissResolutionreopened => fixed
14-12-2010 14:29Ina SchieferdeckerNote Added: 0009964
14-12-2010 14:46Ina SchieferdeckerNote Added: 0009965
14-12-2010 14:47Ina SchieferdeckerNote Deleted: 0009965
14-12-2010 14:48Ina SchieferdeckerNote Deleted: 0009964
15-12-2010 00:06Ina SchieferdeckerNote Edited: 0009672
15-12-2010 00:07Ina SchieferdeckerNote Added: 0009975
15-12-2010 00:07Ina SchieferdeckerStatusresolved => closed
15-12-2010 00:07Ina SchieferdeckerFixed in Version => Edition 4.3.1 (not yet published)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009662) +
+ Benjamin Zeiss    +
+ 31-08-2010 11:41    +
+ 		+ + + + +
+ Actually, I don't see why this example should be erroneous. Taking the 4.2.2 EBNF as reference, the template definition is derived from rule 93. TemplateDef. If we take
+
+    template R r:=
+    {
+        ri := * length (1 .. 6) ifpresent // any value containing 1, 2, 3, 4,
+                                            // 5 or 6 provided it is present
+    }
+
+it can be derived as follows (skipping a few unimportant steps):
+
+TemplateDef ->
+TemplateKeyword BaseTemplate AssignmentChar TemplateBody
+
+Let's concentrate on the TemplateBody.
+
+TemplateBody ->
+FieldSpecList ->
+"{" FieldSpec "}" ->
+"{" FieldReference AssignmentChar TemplateBody "}"
+
+Let's concentrate on the right TemplateBody as FieldReference AssignmentChar will derive to "ri := " - I think we can agree on that.
+
+TemplateBody ->
+SimpleSpec ExtraMatchingAttributes ->
+SingleValueOrAttrib ExtraMatchingAttributes ->
+MatchingSymbol ExtraMatchingAttributes ->
+AnyOrOmit ExtraMatchingAttributes ->
+"*" ExtraMatchingAttributes ->
+"*" (LengthMatch IfPresentMatch) ->
+"*" StringLength "ifpresent" ->
+"*" "length" "(" SingleConstExpression [".." UpperBound] ")" "ifpresent"
+-> ...
+
+I think now it should be clear that the sentence is derivable if I did not make any bad mistake. Just in case, I have tested the syntactical snippet in the TRex parser and it accepts it as well.
+
+To summarize: length and ifpresent can be applied together, because the third alternative in rule
+
+117. ExtraMatchingAttributes ::= LengthMatch | IfPresentMatch | (LengthMatch IfPresentMatch)
+
+allows it in exactly the notation specified in the example.
+
+If the person reviewing this does not find a mistake here, I suggest to close as resolved.
+
+
+
+ + + + + + + + + + +
+ (0009672) +
+ Jacob Wieland - Spirent    +
+ 01-09-2010 11:22    +
(edited on: 15-12-2010 00:06)
+ 		+ + + + +
+ You are correct, the BNF allows this.
+
+But, the example still should be changed as the comment does not match
+the code:
+
+// any value containing 1, 2, 3, 4,
+// 5 or 6 provided it is present
+
+should be changed to
+
+// any value containing 1, 2, 3, 4,
+// 5 or 6 elements, provided it is present
+
+
+
+
+
+ + + + + + + + + + +
+ (0009683) +
+ Benjamin Zeiss    +
+ 01-09-2010 17:07    +
+ 		+ + + + +
+ I agree. Changing to resolved and assigning to Ina.
+
+
+
+ + + + + + + + + + +
+ (0009975) +
+ Ina Schieferdecker    +
+ 15-12-2010 00:07    +
+ 		+ + + + +
+ Comment changed as proposed
+
+ + diff --git a/docs/mantis/CR5607.md b/docs/mantis/CR5607.md new file mode 100644 index 0000000000000000000000000000000000000000..f176496b6f178ca1c92e7d1714a53c30b0d32c6e --- /dev/null +++ b/docs/mantis/CR5607.md @@ -0,0 +1,210 @@ + + + + + + + + + + + + + 0005607: definitions of an enum type should not have the same name as an enum value in that type - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005607Part 01: TTCN-3 Core LanguageTechnicalpublic14-07-2010 15:3414-12-2010 23:59
ReporterJacob Wieland - Spirent 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.3.1 (published 2011-06)Fixed in Versionv4.3.1 (published 2011-06) 
Clause Reference(s)6.2.4.
Source (company - Author)Testing Technologies - Jacob Wieland
Summary0005607: definitions of an enum type should not have the same name as an enum value in that type
DescriptionAt the moment, a local definition (parameter, variable or constant) or a definition inherited from the runs on clause (i.e. component variable or constant) can have the same name as an enumerated value defined in some enumerated type.
+
+If that definition has an enumerated type which includes such a value, it would not be possible to distinguish between the enum value and the reference to that definition (both have the same type, none of them can be prefixed to resolve the nameclash).
+
+To avoid this, it should be forbidden to introduce (local) definitions (except struct-field-defs) of an enumerated type that have the same name as an enumerated value in that type.
+
+For consistency's sake, the same restriction could be applied to global definitions (const, modulepar, template), as well. Then, it will never be necessary to prefix an reference to a definition of an enumerated type to resolve the nameclash with the enumerated value. Also, defining an entity of an enumerated type with the same name as an enumerated value in that type is pathological at best and would only lead to confusion in any case - another reason why this should be forbidden.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0005958closed Ina Schieferdecker Example 4 of section 8.2.3.1 must be rewritten according to CR5607 
related to 0006440closed Ina Schieferdecker Restriction on imported enumerated types 
Attached Filesdoc CR5607.doc (40,960) 03-09-2010 11:54
http://oldforge.etsi.org/mantis/file_download.php?file_id=2440&type=bug
Issue History
Date ModifiedUsernameFieldChange
14-07-2010 15:34Jacob Wieland - SpirentNew Issue
14-07-2010 15:34Jacob Wieland - SpirentClause Reference(s) => 6.2.4.
14-07-2010 15:34Jacob Wieland - SpirentSource (company - Author) => Testing Technologies - Jacob Wieland
30-08-2010 11:32Gyorgy RethyStatusnew => assigned
30-08-2010 11:32Gyorgy RethyAssigned To => Jacob Wieland - Spirent
30-08-2010 11:40Gyorgy RethyNote Added: 0009652
30-08-2010 13:41Jacob Wieland - SpirentNote Added: 0009654
30-08-2010 17:24Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
02-09-2010 09:53Gyorgy RethyNote Added: 0009691
02-09-2010 09:53Gyorgy RethyAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
03-09-2010 09:25Gyorgy RethyProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
03-09-2010 09:25Gyorgy RethyTarget Version => Edition 4.3.1 (not yet published)
03-09-2010 11:53Jacob Wieland - SpirentNote Added: 0009708
03-09-2010 11:54Jacob Wieland - SpirentFile Added: CR5607.doc
03-09-2010 11:54Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
03-09-2010 11:54Jacob Wieland - SpirentAssigned ToGyorgy Rethy => Ina Schieferdecker
03-09-2010 11:55Jacob Wieland - SpirentStatusassigned => resolved
03-09-2010 11:55Jacob Wieland - SpirentFixed in Version => Edition 4.3.1 (not yet published)
03-09-2010 11:55Jacob Wieland - SpirentResolutionopen => fixed
14-12-2010 23:58Ina SchieferdeckerNote Added: 0009973
14-12-2010 23:59Ina SchieferdeckerStatusresolved => closed
28-11-2011 15:38Ina SchieferdeckerRelationship addedrelated to 0005958
19-03-2013 08:22Tomas UrbanRelationship addedrelated to 0006440
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009652) +
+ Gyorgy Rethy    +
+ 30-08-2010 11:40    +
+ 		+ + + + +
+ Forbid local and global names of enum. type use the same name as an enumer. value of that given type.
+
+
+
+ + + + + + + + + + +
+ (0009654) +
+ Jacob Wieland - Spirent    +
+ 30-08-2010 13:41    +
+ 		+ + + + +
+ In 6.2.4 the following sentence should be added:
+
+"They shall also not be re-used for local or global definitions of the enumerated type which introduces them."
+
+Maybe also a NOTE should be added that because of this all template/var/const/modulepar/formal parameter declarations of an enumerated type shall not have the same name as an enumeration in that type, regardless where that declaration occurs.
+
+
+
+ + + + + + + + + + +
+ (0009691) +
+ Gyorgy Rethy    +
+ 02-09-2010 09:53    +
+ 		+ + + + +
+ This sentence is somewhat too generic, will not be clear for the ordinary user. I think we should be more precise in that, like:
+"When a TTCN-3 global or local definition is declared using an imported enumerated type, the name of that definition shall not be same as any of the enumeration value names of that type."
+
+
+
+ + + + + + + + + + +
+ (0009708) +
+ Jacob Wieland - Spirent    +
+ 03-09-2010 11:53    +
+ 		+ + + + +
+ agreed, I have added this to the document I'll shortly upload
+
+
+
+ + + + + + + + + + +
+ (0009973) +
+ Ina Schieferdecker    +
+ 14-12-2010 23:58    +
+ 		+ + + + +
+ Implemented as proposed
+
+ + diff --git a/docs/mantis/CR5629.md b/docs/mantis/CR5629.md new file mode 100644 index 0000000000000000000000000000000000000000..6719ca9a29d5082e84890fc1e3a35ce520e13bcb --- /dev/null +++ b/docs/mantis/CR5629.md @@ -0,0 +1,123 @@ + + + + + + + + + + + + + 0005629: Incorrect examples values for strings exchanged through the TCI - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005629Part 06: TTCN-3 Control InterfaceClarificationpublic26-07-2010 11:0001-09-2010 15:53
ReporterAnthony Baire 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.1.1 (published 2009-06) 
Target Versionv4.3.1 (published 2011-06)Fixed in Versionv4.3.1 (published 2011-06) 
Clause Reference(s)7.2.2.2 8.2.4
Source (company - Author)IRISA
Summary0005629: Incorrect examples values for strings exchanged through the TCI
DescriptionThe TCI specification states that string values exchanged through the interface shall be represented « as defined in TTCN-3 ». However the sample values that are enumerated are in contradiction with this statement.
+
+Example with octetstring :
+
+    TString getString() Returns the textual representation of this OctetstringValue, as
+                                        defined in TTCN-3. E.g. the textual representation of 0xCAFFEE is
+                                        "CAFFEE"O. The textual representation of the empty TTCN-3
+                                        octetstring is ""O, while its length is zero.
+ "CAFFEE"O should be replaced with 'CAFFEE'O
+ ""O should be replaced with ''O
+
+Sample charstring values are affected too ('' should be replaced with "")
+
+
+The following sections are affected:
+
+7.2.2.2.5 -> 1 occurence
+7.2.2.2.7 -> 3 occurences
+7.2.2.2.8 -> 3 occurences
+7.2.2.2.9 -> 3 occurences
+8.2.4.5 -> 1 occurence
+8.2.4.6 -> 3 occurences
+8.2.4.7 -> 3 occurences
+8.2.4.9 -> 3 occurences
+
+
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Fileszip es_20187306v040203.zip (1,281,034) 01-09-2010 15:52
http://oldforge.etsi.org/mantis/file_download.php?file_id=2426&type=bug
Issue History
Date ModifiedUsernameFieldChange
26-07-2010 11:00Anthony BaireNew Issue
26-07-2010 11:00Anthony BaireClause Reference(s) => 7.2.2.2 8.2.4
26-07-2010 11:00Anthony BaireSource (company - Author) => IRISA
30-08-2010 11:29Gyorgy RethyNote Added: 0009651
30-08-2010 11:29Gyorgy RethyAssigned To => Ina Schieferdecker
30-08-2010 11:29Gyorgy RethyStatusnew => assigned
01-09-2010 15:51Ina SchieferdeckerNote Added: 0009680
01-09-2010 15:52Ina SchieferdeckerFile Added: es_20187306v040203.zip
01-09-2010 15:53Ina SchieferdeckerStatusassigned => resolved
01-09-2010 15:53Ina SchieferdeckerResolutionopen => fixed
01-09-2010 15:53Ina SchieferdeckerFixed in Version => Edition 4.3.1 (not yet published)
01-09-2010 15:53Ina SchieferdeckerTarget Version => Edition 4.3.1 (not yet published)
01-09-2010 15:53Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009651) +
+ Gyorgy Rethy    +
+ 30-08-2010 11:29    +
+ 		+ + + + +
+ Editorial, accept proposed solution
+
+
+
+ + + + + + + + + + +
+ (0009680) +
+ Ina Schieferdecker    +
+ 01-09-2010 15:51    +
+ 		+ + + + +
+ Implemented as proposed - except that it is 8.3.4.5, 8.3.4.6, 8.3.4.7, 8.3.4.9
+
+ + diff --git a/docs/mantis/CR5655.md b/docs/mantis/CR5655.md new file mode 100644 index 0000000000000000000000000000000000000000..5a4dd866fb2a7ffb9ec3c38c7c3e7e5263b1e784 --- /dev/null +++ b/docs/mantis/CR5655.md @@ -0,0 +1,94 @@ + + + + + + + + + + + + + 0005655: Incorrect example e40c - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005655Part 09: Using XML with TTCN-3Technicalpublic06-08-2010 17:0626-11-2010 15:25
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.1.1 (published 2009-06) 
Target Versionv4.3.1 (published 2011-06)Fixed in Versionv4.3.1 (published 2011-06) 
Clause Reference(s)7.6.6.6
For STF discussion
Source (company - Author)L.M.Ericsson
Summary0005655: Incorrect example e40c
DescriptionIn example 2: elements of the optional sequence and the choice shall not have the same names due to moinOccurs="0" attribute of the sequence.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
06-08-2010 17:06Gyorgy RethyNew Issue
06-08-2010 17:06Gyorgy RethyClause Reference(s) => 7.6.6.6
06-08-2010 17:06Gyorgy RethySource (company - Author) => L.M.Ericsson
06-08-2010 17:43Gyorgy RethySummaryIncorrect examples e40c => Incorrect example e40c
30-08-2010 11:28Gyorgy RethyStatusnew => assigned
30-08-2010 11:28Gyorgy RethyAssigned To => Gyorgy Rethy
26-11-2010 15:24Gyorgy RethyNote Added: 0009811
26-11-2010 15:24Gyorgy RethyDescription Updated
26-11-2010 15:25Gyorgy RethyStatusassigned => closed
26-11-2010 15:25Gyorgy RethyResolutionopen => fixed
26-11-2010 15:25Gyorgy RethyFixed in Version => Edition 4.3.1 (not yet published)
26-11-2010 15:25Gyorgy RethyTarget Version => Edition 4.3.1 (not yet published)
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009811) +
+ Gyorgy Rethy    +
+ 26-11-2010 15:24    +
+ 		+ + + + +
+ Solution:
+<complexType name="e40c">
+    <sequence>
+        <sequence minOccurs="0">
+            <element name="foo" type="string"/>
+            <element name="bar" type="string"/>
+        </sequence>
+        <choice>
+            <element name="foo1" type="string"/>
+            <element name="bar1" type="string"/>
+        </choice>
+        <element name="ding" type="string"/>
+    </sequence>
+</complexType>
+
+// Is mapped to
+type record E40c {
+    record {
+        XSD.String foo,
+        XSD.String bar
+    } sequence optional,
+    union {
+        XSD.String foo1,
+        XSD.String bar1
+    } choice,
+    XSD.String ding
+}
+with {
+    variant "name as uncapitalized";
+    variant(sequence, choice) "untagged"
+}
+
+
+ + diff --git a/docs/mantis/CR5656.md b/docs/mantis/CR5656.md new file mode 100644 index 0000000000000000000000000000000000000000..9ee04434657a6a32a69476660d6d91d6ba754403 --- /dev/null +++ b/docs/mantis/CR5656.md @@ -0,0 +1,117 @@ + + + + + + + + + + + + + 0005656: Status in @status tag not needed - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 10: TTCN-3 documentation tags
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005656Part 10: TTCN-3 documentation tagsTechnicalpublic08-08-2010 18:3701-12-2010 11:30
ReporterIna Schieferdecker 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.3.1 (published 2011-06)Fixed in Versionv4.3.1 (published 2011-06) 
Source (company - Author)Ina Schieferdecker, FOKUS
Summary0005656: Status in @status tag not needed
DescriptionPart 10 currently defines:
+
+"@status Status [freetext]
+
+Status shall define the actual status of the object and it shall conform to the naming rules for TTCN 3 identifiers (see annex A of ES 201 873-1 [1]). "
+
+Status is undefined but seems to refer to an identifier. Later on, an example is given without an identifier, but just freetext:
+
+"//* @status deprecated as of version 1.2, replaced by ExtensionHeaderList.
+//* ExtensionHeaderList has a more efficient implementation.
+type record of Header ListOfExtensionHeaders;"
+
+It is better to have @status just with freetext (like most of the documentation tags:
+
+"@status [freetext]"
+
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
08-08-2010 18:37Ina SchieferdeckerNew Issue
08-08-2010 18:37Ina SchieferdeckerStatusnew => assigned
08-08-2010 18:37Ina SchieferdeckerAssigned To => Gyorgy Rethy
08-08-2010 18:37Ina SchieferdeckerSource (company - Author) => Ina Schieferdecker, FOKUS
30-11-2010 15:06Ina SchieferdeckerNote Added: 0009851
01-12-2010 11:28Gyorgy RethyNote Added: 0009891
01-12-2010 11:30Gyorgy RethyStatusassigned => closed
01-12-2010 11:30Gyorgy RethyResolutionopen => fixed
01-12-2010 11:30Gyorgy RethyFixed in Version => Edition 4.3.1 (not yet published)
01-12-2010 11:30Gyorgy RethyTarget Version => Edition 4.3.1 (not yet published)
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009851) +
+ Ina Schieferdecker    +
+ 30-11-2010 15:06    +
+ 		+ + + + +
+ As a single identifier is asked for, we may say:
+
+"@status Status [freetext]
+
+Status shall be a TTCN-3 identifier representing the actual status of the object."
+
+
+
+ + + + + + + + + + +
+ (0009891) +
+ Gyorgy Rethy    +
+ 01-12-2010 11:28    +
+ 		+ + + + +
+ Resolved as Ina proposed in the note.
+
+ + diff --git a/docs/mantis/CR5658.md b/docs/mantis/CR5658.md new file mode 100644 index 0000000000000000000000000000000000000000..77225890e23097dd6e4ac83d2d333b147aa6af91 --- /dev/null +++ b/docs/mantis/CR5658.md @@ -0,0 +1,168 @@ + + + + + + + + + + + + + 0005658: Support patern facets for non-string types - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005658Part 09: Using XML with TTCN-3New Featurepublic09-08-2010 12:1301-12-2011 10:28
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.4.1 (published 2012-04)Fixed in Versionv4.4.1 (published 2012-04) 
Clause Reference(s)6.1.4
For STF discussion
Source (company - Author)L.M.Ericsson
Summary0005658: Support patern facets for non-string types
DescriptionCurrently the pattern facet is supported for XSD types derived from xsd:string, where they are mapped to a TTCN-3 pattern. However it would be useful to retain also pattern facets applied to other types (e.g. decimal) as encoding instructions as today the encoder has no information about this restriction, thus may produce incorrect encoding and is not able to check the received value (checking is not possible in TTCN-3 as the TTCN-3 recognizes the (numeric) value only but not the characters carried the value on the line.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR5658-proposal.doc (174,080) 30-09-2011 12:52
http://oldforge.etsi.org/mantis/file_download.php?file_id=2583&type=bug
doc CR5658_resolution_v2.doc (245,760) 30-11-2011 17:23
http://oldforge.etsi.org/mantis/file_download.php?file_id=2627&type=bug
doc CR5658_resolution_v3.doc (208,384) 01-12-2011 08:57
http://oldforge.etsi.org/mantis/file_download.php?file_id=2631&type=bug
Issue History
Date ModifiedUsernameFieldChange
09-08-2010 12:13Gyorgy RethyNew Issue
09-08-2010 12:13Gyorgy RethyClause Reference(s) => 6.1.4
09-08-2010 12:13Gyorgy RethySource (company - Author) => L.M.Ericsson
30-08-2010 11:26Gyorgy RethyStatusnew => assigned
30-08-2010 11:26Gyorgy RethyAssigned To => Gyorgy Rethy
03-12-2010 10:28Gyorgy RethyTarget Version => Edition 4.3.2 (interim)
13-07-2011 17:05Gyorgy RethyTarget VersionEdition 4.3.2 (interim) => Edition 4.4.1
29-09-2011 16:26Gyorgy RethyAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
30-09-2011 12:41Jacob Wieland - SpirentFile Added: CR5658-proposal.doc
30-09-2011 12:52Jacob Wieland - SpirentFile Deleted: CR5658-proposal.doc
30-09-2011 12:52Jacob Wieland - SpirentFile Added: CR5658-proposal.doc
30-09-2011 12:53Jacob Wieland - SpirentNote Added: 0010310
30-09-2011 12:53Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
30-11-2011 17:19Gyorgy RethyFile Added: CR5858_resolution_v2.doc
30-11-2011 17:22Gyorgy RethyNote Added: 0010452
30-11-2011 17:23Gyorgy RethyFile Deleted: CR5858_resolution_v2.doc
30-11-2011 17:23Gyorgy RethyNote Edited: 0010452
30-11-2011 17:23Gyorgy RethyFile Added: CR5658_resolution_v2.doc
30-11-2011 17:24Gyorgy RethyNote Edited: 0010452
30-11-2011 17:24Gyorgy RethyAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
01-12-2011 08:57Jacob Wieland - SpirentFile Added: CR5658_resolution_v3.doc
01-12-2011 08:58Jacob Wieland - SpirentNote Added: 0010455
01-12-2011 08:58Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Ina Schieferdecker
01-12-2011 08:59Jacob Wieland - SpirentAssigned ToIna Schieferdecker => Gyorgy Rethy
01-12-2011 10:28Gyorgy RethyStatusassigned => closed
01-12-2011 10:28Gyorgy RethyNote Added: 0010462
01-12-2011 10:28Gyorgy RethyResolutionopen => fixed
01-12-2011 10:28Gyorgy RethyFixed in Version => Edition 4.4.1
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010310) +
+ Jacob Wieland - Spirent    +
+ 30-09-2011 12:53    +
+ 		+ + + + +
+ uploaded a proposal for general handling of unsupported facets via variant attribute
+
+
+
+ + + + + + + + + + +
+ (0010452) +
+ Gyorgy Rethy    +
+ 30-11-2011 17:22    +
(edited on: 30-11-2011 17:24)
+ 		+ + + + +
+ CR5658_resolution_v2.doc: Integrated to the rest of Part-9 and added the clause for the encoding instruction. Examples has been made complete (types not only the facets themselves) and text is adjusted.
+Pls. check.
+
+
+
+
+
+ + + + + + + + + + +
+ (0010455) +
+ Jacob Wieland - Spirent    +
+ 01-12-2011 08:58    +
+ 		+ + + + +
+ only editorial changes added, otherwise ok.
+
+
+
+ + + + + + + + + + +
+ (0010462) +
+ Gyorgy Rethy    +
+ 01-12-2011 10:28    +
+ 		+ + + + +
+ Added to master document (v4.3.3).
+
+ + diff --git a/docs/mantis/CR5659.md b/docs/mantis/CR5659.md new file mode 100644 index 0000000000000000000000000000000000000000..392b926b9fcfe391be90f67f85abd63df5bd46eb --- /dev/null +++ b/docs/mantis/CR5659.md @@ -0,0 +1,120 @@ + + + + + + + + + + + + + 0005659: Incorrect example of referencing value list - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005659Part 01: TTCN-3 Core LanguageEditorialpublic12-08-2010 12:3101-09-2010 14:35
ReporterGyorgy Rethy 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.3.1 (published 2011-06)Fixed in Versionv4.3.1 (published 2011-06) 
Clause Reference(s)15.6.3
Source (company - Author)L.M.Ericsson
Summary0005659: Incorrect example of referencing value list
DescriptionThe example in 15.6.3:
+    type record of integer RoI;
+    type record of RoI RoRoI;
+    
+    :
+    var template RoI t_RoI;
+    var template RoRoI t_RoRoI;
+    var template integer t_Int;
+    :
+    t_RoRoI := ({},{0},{0,0},{0,0,0});
+    t_RoI := t_RoRoI[0];
+        // shall cause an error as value list is assigned to t_RoRoI;
+
+Should be corrected and simplified; proposed solution is:
+
+    type record of integer RoI;
+        :
+    var template RoI t_RoI;
+    var template integer t_int;
+
+    t_RoI := ({},{0},{0,0},{0,0,0});
+    t_int := t_RoI[0]
+    // shall cause an error as trying to indexing into a value list matching;
+    
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
12-08-2010 12:31Gyorgy RethyNew Issue
12-08-2010 12:31Gyorgy RethyClause Reference(s) => 15.6.3
12-08-2010 12:31Gyorgy RethySource (company - Author) => L.M.Ericsson
12-08-2010 14:51Gyorgy RethyDescription Updated
30-08-2010 11:22Gyorgy RethyNote Added: 0009650
30-08-2010 11:22Gyorgy RethyStatusnew => assigned
30-08-2010 11:22Gyorgy RethyAssigned To => Ina Schieferdecker
01-09-2010 14:35Ina SchieferdeckerNote Added: 0009678
01-09-2010 14:35Ina SchieferdeckerStatusassigned => resolved
01-09-2010 14:35Ina SchieferdeckerResolutionopen => fixed
01-09-2010 14:35Ina SchieferdeckerFixed in Version => Edition 4.3.1 (not yet published)
01-09-2010 14:35Ina SchieferdeckerTarget Version => Edition 4.3.1 (not yet published)
01-09-2010 14:35Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009650) +
+ Gyorgy Rethy    +
+ 30-08-2010 11:22    +
+ 		+ + + + +
+ Proposed solution accepted
+
+
+
+ + + + + + + + + + +
+ (0009678) +
+ Ina Schieferdecker    +
+ 01-09-2010 14:35    +
+ 		+ + + + +
+ Implemented as proposed
+
+ + diff --git a/docs/mantis/CR5670.md b/docs/mantis/CR5670.md new file mode 100644 index 0000000000000000000000000000000000000000..4836eeccbce3a9e5bf84313860f31357714c20b6 --- /dev/null +++ b/docs/mantis/CR5670.md @@ -0,0 +1,175 @@ + + + + + + + + + + + + + 0005670: Value returning functions shall always return a value - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005670Part 01: TTCN-3 Core LanguageTechnicalpublic27-08-2010 15:2703-09-2010 09:49
ReporterGyorgy Rethy 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.1.1 (published 2009-06) 
Target Versionv4.3.1 (published 2011-06)Fixed in Versionv4.3.1 (published 2011-06) 
Clause Reference(s)16.1
Source (company - Author)L.M. Ericsson
Summary0005670: Value returning functions shall always return a value
DescriptionCurrently an explicit statement is missing that requires that functions with a return clause in their header always shalle reach a return statement followe by an expression.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR5670-Jens-100830.doc (74,752) 31-08-2010 11:18
http://oldforge.etsi.org/mantis/file_download.php?file_id=2418&type=bug
doc CR5670-Jacob-100831.doc (45,568) 31-08-2010 17:10
http://oldforge.etsi.org/mantis/file_download.php?file_id=2419&type=bug
Issue History
Date ModifiedUsernameFieldChange
27-08-2010 15:27Gyorgy RethyNew Issue
27-08-2010 15:27Gyorgy RethyClause Reference(s) => 16.1
27-08-2010 15:27Gyorgy RethySource (company - Author) => L.M. Ericsson
30-08-2010 11:16Gyorgy RethyStatusnew => assigned
30-08-2010 11:16Gyorgy RethyAssigned To => Jens Grabowski
31-08-2010 11:18Jens GrabowskiFile Added: CR5670-Jens-100830.doc
31-08-2010 11:18Jens GrabowskiNote Added: 0009661
31-08-2010 11:19Jens GrabowskiAssigned ToJens Grabowski => Gyorgy Rethy
31-08-2010 13:30Jacob Wieland - SpirentNote Added: 0009666
31-08-2010 13:31Jacob Wieland - SpirentNote Edited: 0009666
31-08-2010 16:24Jens GrabowskiAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
31-08-2010 17:10Jacob Wieland - SpirentFile Added: CR5670-Jacob-100831.doc
31-08-2010 17:29Jens GrabowskiNote Added: 0009667
01-09-2010 17:14Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Ina Schieferdecker
01-09-2010 17:15Jacob Wieland - SpirentStatusassigned => resolved
01-09-2010 17:15Jacob Wieland - SpirentResolutionopen => fixed
03-09-2010 09:26Gyorgy RethyStatusresolved => feedback
03-09-2010 09:26Gyorgy RethyResolutionfixed => reopened
03-09-2010 09:27Gyorgy RethyStatusfeedback => resolved
03-09-2010 09:27Gyorgy RethyResolutionreopened => fixed
03-09-2010 09:27Gyorgy RethyTarget Version => Edition 4.3.1 (not yet published)
03-09-2010 09:49Ina SchieferdeckerNote Added: 0009704
03-09-2010 09:49Ina SchieferdeckerStatusresolved => closed
03-09-2010 09:49Ina SchieferdeckerFixed in Version => Edition 4.3.1 (not yet published)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009661) +
+ Jens Grabowski    +
+ 31-08-2010 11:18    +
+ 		+ + + + +
+ Proposal for resolution in the attached file. Assigned to György for proofreading.
+
+
+
+ + + + + + + + + + +
+ (0009666) +
+ Jacob Wieland - Spirent    +
+ 31-08-2010 13:30    +
(edited on: 31-08-2010 13:31)
+ 		+ + + + +
+ I think the text should rather be as follows:
+
+"If the function header includes a return clause the function, when terminating, shall do so by executing a return statement. The function will cause a test case error if it terminates (i.e. reaches the end of the function body) without executing a return statement."
+
+In Jens's proposal, I had problems with the term signature (which in the TTCN-3 context means something else than you mean), also with type identifier since it can also be a more type expression than an identifier. Also, the function could be non-terminating and this should not cause a test case error, but the proposal required this, as I understood it. The part of the returning of the proper value/template is unnecessary as it is covered adequately by the text before this paragraph.
+
+A shorter description would be:
+
+If the function header includes a return clause every finite sequence of control statements executed by the function must terminate with a return statement.
+
+
+
+
+
+ + + + + + + + + + +
+ (0009667) +
+ Jens Grabowski    +
+ 31-08-2010 17:29    +
+ 		+ + + + +
+ Ok, for me!
+
+
+
+ + + + + + + + + + +
+ (0009704) +
+ Ina Schieferdecker    +
+ 03-09-2010 09:49    +
+ 		+ + + + +
+ Implemented.
+
+ + diff --git a/docs/mantis/CR5671.md b/docs/mantis/CR5671.md new file mode 100644 index 0000000000000000000000000000000000000000..eb908f690dc6955dc226328cfbd00708801497c7 --- /dev/null +++ b/docs/mantis/CR5671.md @@ -0,0 +1,467 @@ + + + + + + + + + + + + + 0005671: Bound-unbound should be handled in a consistent way - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005671Part 01: TTCN-3 Core LanguageClarificationpublic30-08-2010 10:2820-05-2011 15:51
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritylowSeverityminorReproducibilityhave not tried
StatusclosedResolutionwon't fix 
PlatformOSOS Version
Product Versionv4.1.1 (published 2009-06) 
Target Versionv4.3.2 (interim 2011)Fixed in Version 
Clause Reference(s)general
Source (company - Author)L.M.Ericssson
Summary0005671: Bound-unbound should be handled in a consistent way
DescriptionCurently "boundness" and "unboundness" is not handled consistently in case of record/set and record/set of types:
+- record ofs with a whole is handled as completely initialized
+- records with a "whole" (field is uninitialized) is partly initialized
+
+- constants needs not be completely initialized (to be checked and discus if this was the intention or should be changed)
+
+- unclear if a not-completely-initialized value/template can be assigned to a variable (directly, i.e. not participating in an expresion)
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR5671.doc (110,592) 02-09-2010 11:02
http://oldforge.etsi.org/mantis/file_download.php?file_id=2436&type=bug
Issue History
Date ModifiedUsernameFieldChange
30-08-2010 10:28Gyorgy RethyNew Issue
30-08-2010 10:28Gyorgy RethyClause Reference(s) => general
30-08-2010 10:28Gyorgy RethySource (company - Author) => L.M.Ericssson
30-08-2010 11:15Gyorgy RethyStatusnew => assigned
30-08-2010 11:15Gyorgy RethyAssigned To => Jacob Wieland - Spirent
31-08-2010 10:39Jacob Wieland - SpirentNote Added: 0009660
02-09-2010 10:50Jacob Wieland - SpirentFile Added: CR5671.doc
02-09-2010 10:53Jacob Wieland - SpirentNote Added: 0009694
02-09-2010 10:56Jacob Wieland - SpirentFile Deleted: CR5671.doc
02-09-2010 10:56Jacob Wieland - SpirentFile Added: CR5671.doc
02-09-2010 11:00Jacob Wieland - SpirentFile Deleted: CR5671.doc
02-09-2010 11:02Jacob Wieland - SpirentFile Added: CR5671.doc
02-09-2010 11:03Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
03-09-2010 09:23Gyorgy RethyTarget Version => Edition 4.3.1 (not yet published)
26-11-2010 15:17Gyorgy RethyNote Added: 0009809
26-11-2010 15:18Gyorgy RethyNote Added: 0009810
29-11-2010 09:29Jacob Wieland - SpirentNote Added: 0009817
29-11-2010 10:50Gyorgy RethyNote Added: 0009821
29-11-2010 10:51Gyorgy RethyPrioritynormal => low
03-12-2010 10:11Gyorgy RethyTarget VersionEdition 4.3.1 (not yet published) => Edition 4.3.2 (interim)
20-05-2011 15:51Gyorgy RethyNote Added: 0010002
20-05-2011 15:51Gyorgy RethyStatusassigned => closed
20-05-2011 15:51Gyorgy RethyResolutionopen => won't fix
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009660) +
+ Jacob Wieland - Spirent    +
+ 31-08-2010 10:39    +
+ 		+ + + + +
+ Regarding the record ofs:
+
+Section 3.1 (completely initialized) states:
+
+Values and templates of structured types and arrays are completely initialized if all their fields and elements are completely initialized.
+
+Although it should probably be 'variables' instead of 'values'. This error continues in the whole section.
+
+The question where a not completely initialized variable can be used is answered in section 11.1.
+
+d) Use of uninitialized or not completely initialized value variables at other places than the left hand side of assignments or as actual parameters passed to inout or out formal parameters shall cause an error.
+
+The same restriction is reiterated for template variables.
+
+For operation expressions, function calls and predefined function calls, this restriction is also reiterated for the operands (i.e. have to be completely initialized).
+
+=============================================================================
+Regarding the constants:
+
+Constants are assigned a VALUE (see section 10). Since only VARIABLES can be unbound or partially initialized, values are always fully initialized structures and therefore a constant is also always fully initialized.
+
+==============================================================================
+
+Regarding the unbound-assignment question, section 19.1 states clearly:
+
+"During execution of an assignment, the right-hand side of the assignment shall evaluate to a value or template. The effect of an assignment is to bind the variable to the value of the expression or to a template. The expression shall contain no unbound variables."
+
+===============================================================================
+Unfortunately, there is no clear definition what a value actually is, although lots of definitions depend on that. Thus, I think a definition like:
+
+A value is either
+- a basic value (string, integer, float, enumerated) or
+- a structured value (record, set, union) where all mandatory fields contain values and all optional fields contain either values or are omitted. For union values exactly one variant must be chosen and contain a value.
+
+Also, the term evaluation is used frequently in the standard but also not defined. So, maybe another definition needs to be added here.
+
+The evaluation of a value expression yields a value.
+The evaluation of a template expression yields a template.
+An expression is evaluated by evaluating all operation expressions and replacing them with the result of the evaluation. The order of evaluation is left-to-right-inside-out. An operation expression is evaluated by performing the operation on its evaluated operands.
+
+==============================================================================
+SUMMARY:
+
+in essence, the standard is consistent and the CR is moot. The only problem that I could find is the missing definitions of value and evaluate (and the mentioning of values instead of variables in the initialized definitions).
+
+Therefore, the questions could be clarified by fixing this.
+
+
+
+ + + + + + + + + + +
+ (0009694) +
+ Jacob Wieland - Spirent    +
+ 02-09-2010 10:53    +
+ 		+ + + + +
+ I've added the following definitions:
+
+value, reference, evaluation (and they should be read in that order because evaluation depends on value and reference)
+
+I've changed some definitions, especially 'partially initialized' and 'completely initialized' to use these terms.
+
+I've also changed the definition of value notation as it didn't make any sense to me whatsoever.
+
+I hope this is clarification enough for this CR.
+
+
+
+ + + + + + + + + + +
+ (0009809) +
+ Gyorgy Rethy    +
+ 26-11-2010 15:17    +
+ 		+ + + + +
+ Just a few examples of inconsistency:
+
+type record Record { integer x1, integer x2}
+const Record cg_rec := { x2 := 5 } //allowed!? (not forbidden)
+function f1(in Record pl_rec) {
+  var integer vl_int := pl_rec.x2
+}
+function f3() {
+  var integer vl_int;
+  var Record vl_rec := {x2:=5} //partly initialized
+  f1(cg_rec)} //allowed!?
+  f1({x2 := 5}) //allowed!
+  vl_int := vl_rec.f2 //allowed, but not allowed to do the same within a function by passing vl_rec as in parameter
+  f1(vl_rec)} //not allowed!
+}
+        
+function f4(inout Record pl_rec) {...}
+function f5() {
+  var Record vl_rec := {x2:=5} //partly initialized
+  var template Record vt_rec := {x2:=5} //partly initialized
+  f4(vl_rec)} //allowed!
+  f4(vt_rec)} //not allowed!
+}
+
+We can argue if const Record cg_rec := { x2 := 5 } is allowed or not; I know the general theory on type/value systems and saying myself that a valid/legal value of a type shall be a complete instance of the type. However, "value" is not defined in the standard and its also talks about "variable value"s in contexts, when the content of a variable is not necessary completely initialized. Therefore, what a "variable value" and a "constant value" exactly means, is not clearly defined. Hence, if a tool allows partly initialized constants, it cannot be claimed to be non-conformant to the standard.
+
+And whatever is the decision regarding constants, there is still the case of literal values(inline templates) vs. constants and variables.
+
+Probably it is just due to the incompleteness of the text, that incomplete value variables can be passed to inout parameters, while incomplete template variables cannot. But still, these are inconsistencies.
+
+Btw., it is unclear, why we mix the direction of the "content flow" with the completeness of this content. In another words, why partly initialized values (or how to call it?)cannot be passed to in parameters? This has several use cases:
+a) during testing, the database containing data of the simulated users is typically being completed step-by-step or some data (fields) may even remain unbound all the time (e.g. redirected_to_number)). Currently it is not possible to write a function to process part of the data AND to assure that the function only reads but not changes the data in the database. This is because incomplete data cannot be passed to in parameters.
+b) during constracting a message the user need to calculate some parameter by using a few already available other parameters from the partly constructed message. Again, it is not possible to assure, that the function making the calculation is not changing the content, because no partly initialized data can be passed to in parameters.
+
+Pls. note, that in both cases above, passing the fields used within the called function one-by-one as separate parameters is not possible:
+ - maintenance and backward compatibility: changes within the function could change the function interface (new data required) that would break existing "user" code and
+ - convenience, efficiency and readibility: the number of such parameters is often quite significant.
+
+
+
+ + + + + + + + + + +
+ (0009810) +
+ Gyorgy Rethy    +
+ 26-11-2010 15:18    +
+ 		+ + + + +
+ Just a few examples of inconsistency:
+
+type record Record { integer x1, integer x2}
+const Record cg_rec := { x2 := 5 } //allowed!? (not forbidden)
+function f1(in Record pl_rec) {
+  var integer vl_int := pl_rec.x2
+}
+function f3() {
+  var integer vl_int;
+  var Record vl_rec := {x2:=5} //partly initialized
+  f1(cg_rec)} //allowed!?
+  f1({x2 := 5}) //allowed!
+  vl_int := vl_rec.f2 //allowed, but not allowed to do the same within a function by passing vl_rec as in parameter
+  f1(vl_rec)} //not allowed!
+}
+        
+function f4(inout Record pl_rec) {...}
+function f5() {
+  var Record vl_rec := {x2:=5} //partly initialized
+  var template Record vt_rec := {x2:=5} //partly initialized
+  f4(vl_rec)} //allowed!
+  f4(vt_rec)} //not allowed!
+}
+
+We can argue if const Record cg_rec := { x2 := 5 } is allowed or not; I know the general theory on type/value systems and saying myself that a valid/legal value of a type shall be a complete instance of the type. However, "value" is not defined in the standard and its also talks about "variable value"s in contexts, when the content of a variable is not necessary completely initialized. Therefore, what a "variable value" and a "constant value" exactly means, is not clearly defined. Hence, if a tool allows partly initialized constants, it cannot be claimed to be non-conformant to the standard.
+
+And whatever is the decision regarding constants, there is still the case of literal values(inline templates) vs. constants and variables.
+
+Probably it is just due to the incompleteness of the text, that incomplete value variables can be passed to inout parameters, while incomplete template variables cannot. But still, these are inconsistencies.
+
+Btw., it is unclear, why we mix the direction of the "content flow" with the completeness of this content. In another words, why partly initialized values (or how to call it?)cannot be passed to in parameters? This has several use cases:
+a) during testing, the database containing data of the simulated users is typically being completed step-by-step or some data (fields) may even remain unbound all the time (e.g. redirected_to_number)). Currently it is not possible to write a function to process part of the data AND to assure that the function only reads but not changes the data in the database. This is because incomplete data cannot be passed to in parameters.
+b) during constracting a message the user need to calculate some parameter by using a few already available other parameters from the partly constructed message. Again, it is not possible to assure, that the function making the calculation is not changing the content, because no partly initialized data can be passed to in parameters.
+
+Pls. note, that in both cases above, passing the fields used within the called function one-by-one as separate parameters is not possible:
+ - maintenance and backward compatibility: changes within the function could change the function interface (new data required) that would break existing "user" code and
+ - convenience, efficiency and readibility: the number of such parameters is often quite significant.
+
+
+
+ + + + + + + + + + +
+ (0009817) +
+ Jacob Wieland - Spirent    +
+ 29-11-2010 09:29    +
+ 		+ + + + +
+ Here's my opinion on what should be consistently allowed/disallowed:
+
+type record Record { integer x1, integer x2}
+const Record cg_rec := { x2 := 5 } //allowed!? (not forbidden)
+
+FORBIDDEN
+
+function f1(in Record pl_rec) {
+  var integer vl_int := pl_rec.x2
+}
+function f3() {
+  var integer vl_int;
+  var Record vl_rec := {x2:=5} //partly initialized
+
+ALLOWED (although I still would forbid this syntax and allow only assignment using dotted notation to avoid confusion with the whole implicit/explicit omit issue)
+
+  f1(cg_rec)} //allowed!?
+
+FORBIDDEN
+
+  f1({x2 := 5}) //allowed!
+
+FORBIDDEN (not completely initialized in parameter)
+
+  vl_int := vl_rec.f2 //allowed, but not allowed to do the same within a function by passing vl_rec as in parameter
+
+FORBIDDEN (dottet notation on right-hand-side should only work on completely initialized variables)
+
+  f1(vl_rec)} //not allowed!
+
+FORBIDDEN (not completely initialized in parameter)
+}
+        
+function f4(inout Record pl_rec) {...}
+function f5() {
+  var Record vl_rec := {x2:=5} //partly initialized
+
+ALLOWED (although should be forbidden, see above)
+
+  var template Record vt_rec := {x2:=5} //partly initialized
+
+ALLOWED (althoudh should also be forbidden, see above)
+
+  f4(vl_rec)} //allowed!
+
+ALLOWED
+
+  f4(vt_rec)} //not allowed!
+
+FORBIDDEN (but only because of missing template modifier in formal parameter in f4, otherwise should also be allowed)
+}
+
+The reasoning behind forbidding not completely initialzed variables as r-values is that this allows tools to generate efficient code (not having to do lots of is-this-field-initialized-checking at runtime which is time-consuming)/catch user errors already at compile time to prevent costly error-finding in the running code.
+
+So, while it might be appealing to allow the users the freedom to leave everything partially initialized, this will always backfire later on as the two above problems cannot be avoided otherwise.
+
+If you need to pass data structures around that you need to initialize part-by-part, you should use optional fields for the parts that you want to initialize later on. That way, it in in the hands of the user to know (or ask, if necessary) if a field is already initialized before usage. So, the language already allows your use-cases by usage of that feature.
+
+The argument of the breaking of existing code because of additional parameters is moot because that has been solved with the feature of the parameters with default values. This feature (together with the name-assignment-parameter-syntax) also pretty much solves the issue of the a-lot-of-parameters problem.
+
+For these reasons, in my opinion we should clarify the standard in such a way that
+
+a) a value is a completely initialized construct
+b) a constant is initialized with a value at declaration
+c) all variables can be partially initialized
+d) partially initialized variables can only be used on the left-hand-side of an assignment (or as an out-parameter which is the same as left-hand-side of an assigment).
+
+If this in the real world leads to unmanageably clumsy code, we should think of shorthand notations which do not imply performance/maintenance issues as allowing partially initialized constructs everywhere does.
+
+Personally, for the same reasons and from a compiler-constructor's point of view, I would even forbid partially initialized variables as that is a feature which has no place in a type-safe language.
+
+
+
+ + + + + + + + + + +
+ (0009821) +
+ Gyorgy Rethy    +
+ 29-11-2010 10:50    +
+ 		+ + + + +
+ I propose to put aside this CR as we cannot even agree what is allowed today and what is not (I'm talking about the actual text, not about what should be or not should be; but seems text itself should be analysed in more detail). This week we shall concentrate on CRs that have the chance to be resolved.
+
+
+
+ + + + + + + + + + +
+ (0010002) +
+ Gyorgy Rethy    +
+ 20-05-2011 15:51    +
+ 		+ + + + +
+ CR is withdrawn.
+
+ + diff --git a/docs/mantis/CR5672.md b/docs/mantis/CR5672.md new file mode 100644 index 0000000000000000000000000000000000000000..2393fe8510686aed75a932e0bbcc3171c6a918b1 --- /dev/null +++ b/docs/mantis/CR5672.md @@ -0,0 +1,184 @@ + + + + + + + + + + + + + 0005672: enumerated types are not really structured and cannot be constructed from basic types - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005672Part 01: TTCN-3 Core LanguageTechnicalpublic30-08-2010 13:2814-12-2010 13:59
ReporterJacob Wieland - Spirent 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.3.1 (published 2011-06)Fixed in Versionv4.3.1 (published 2011-06) 
Clause Reference(s)6
Source (company - Author)Testing Technologies - Jacob Wieland
Summary0005672: enumerated types are not really structured and cannot be constructed from basic types
DescriptionIn Section 6, the sentence:
+
+Structured types such as record types, set types and enumerated types can be constructed from these basic types.
+
+should be replaced by:
+
+Structured types such as record types, set types and union types can be constructed from these basic types.
+
+The reasons are obvious: enumerated types, though their definition looks similar structured type definitions, are not really structured types (there is no structure) and they cannot be constructed from other basic types. Unions however are structured and therefore it makes more sense to mention them here together with record and set types.
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
30-08-2010 13:28Jacob Wieland - SpirentNew Issue
30-08-2010 13:28Jacob Wieland - SpirentClause Reference(s) => 6
30-08-2010 13:28Jacob Wieland - SpirentSource (company - Author) => Testing Technologies - Jacob Wieland
02-09-2010 11:36Gyorgy RethyStatusnew => assigned
02-09-2010 11:36Gyorgy RethyAssigned To => Ina Schieferdecker
02-09-2010 11:36Gyorgy RethyNote Added: 0009698
02-09-2010 11:38Gyorgy RethyProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
02-09-2010 11:44Gyorgy RethyNote Edited: 0009698
03-09-2010 09:22Gyorgy RethyTarget Version => Edition 4.3.1 (not yet published)
30-11-2010 10:54Ina SchieferdeckerNote Added: 0009838
30-11-2010 10:54Ina SchieferdeckerNote Added: 0009839
30-11-2010 10:55Ina SchieferdeckerAssigned ToIna Schieferdecker => Gyorgy Rethy
30-11-2010 15:24Ina SchieferdeckerNote Edited: 0009838
30-11-2010 15:24Gyorgy RethyNote Added: 0009852
30-11-2010 15:25Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
30-11-2010 15:25Gyorgy RethyResolutionopen => fixed
30-11-2010 15:25Gyorgy RethyFixed in Version => Edition 4.3.1 (not yet published)
30-11-2010 15:25Gyorgy RethyStatusassigned => resolved
14-12-2010 13:59Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009698) +
+ Gyorgy Rethy    +
+ 02-09-2010 11:36    +
(edited on: 02-09-2010 11:44)
+ 		+ + + + +
+ Re-phrase the proposal to cover also address and component types and add a sentence mentioning enumerated as a specific structured type.
+
+
+
+
+
+ + + + + + + + + + +
+ (0009838) +
+ Ina Schieferdecker    +
+ 30-11-2010 10:54    +
(edited on: 30-11-2010 15:24)
+ 		+ + + + +
+ new proposal:
+
+-----------------------
+Structured types such as record types, set types and union types can be constructed from these basic types. Enumerated types are specific structured types being constructed of enumerated values.
+-----------------------
+
+Configuration types are described later in this section - no need to say that they are/are constructed of basic and user-defined types at this place.
+
+
+
+
+
+ + + + + + + + + + +
+ (0009839) +
+ Ina Schieferdecker    +
+ 30-11-2010 10:54    +
+ 		+ + + + +
+ Please check
+
+
+
+ + + + + + + + + + +
+ (0009852) +
+ Gyorgy Rethy    +
+ 30-11-2010 15:24    +
+ 		+ + + + +
+ OK.
+
+ + diff --git a/docs/mantis/CR5676.md b/docs/mantis/CR5676.md new file mode 100644 index 0000000000000000000000000000000000000000..26c209dd065d79132954a0b488bf3d08beec3887 --- /dev/null +++ b/docs/mantis/CR5676.md @@ -0,0 +1,63 @@ + + + + + + + + + + + + + 0005676: Extend the @verdict tag to TTCN-3 modules - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 10: TTCN-3 documentation tags
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005676Part 10: TTCN-3 documentation tagsNew Featurepublic03-09-2010 09:5201-12-2010 11:24
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.4.1 (published 2008-09) 
Target Versionv4.3.1 (published 2011-06)Fixed in Versionv4.3.1 (published 2011-06) 
Source (company - Author)L.M.Ericsson
Summary0005676: Extend the @verdict tag to TTCN-3 modules
DescriptionAs discussed in STF393, a "test case" in the TTCN-3 reference test suite not necessarily contains any test cases, but still the expected verdict and/or the achieved verdict should be dicumented.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0005798closed Gyorgy Rethy Add the @reference tag 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
03-09-2010 09:52Gyorgy RethyNew Issue
03-09-2010 09:52Gyorgy RethySource (company - Author) => L.M.Ericsson
03-09-2010 09:53Gyorgy RethyAssigned To => Gyorgy Rethy
03-09-2010 09:53Gyorgy RethyStatusnew => assigned
03-09-2010 09:53Gyorgy RethyTarget Version => Edition 4.3.1 (not yet published)
03-09-2010 09:57Gyorgy RethySummaryExtend the verdict tag to TTCN-3 modules => Extend the @verdict tag to TTCN-3 modules
01-12-2010 11:22Gyorgy RethyRelationship addedrelated to 0005798
01-12-2010 11:23Gyorgy RethyNote Added: 0009889
01-12-2010 11:24Gyorgy RethyStatusassigned => closed
01-12-2010 11:24Gyorgy RethyResolutionopen => fixed
01-12-2010 11:24Gyorgy RethyFixed in Version => Edition 4.3.1 (not yet published)
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009889) +
+ Gyorgy Rethy    +
+ 01-12-2010 11:23    +
+ 		+ + + + +
+ Both @purpose and @verdict have been extended to TTCN-3 modules.
+
+ + diff --git a/docs/mantis/CR5677.md b/docs/mantis/CR5677.md new file mode 100644 index 0000000000000000000000000000000000000000..b3040b213e3c36df0140a33a96ba4491d0a7472b --- /dev/null +++ b/docs/mantis/CR5677.md @@ -0,0 +1,29 @@ + + + + + + + + + + + + + 0005677: Extend the @requirement tag to dynamic language elements and to module - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 10: TTCN-3 documentation tags
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005677Part 10: TTCN-3 documentation tagsNew Featurepublic03-09-2010 09:5601-12-2010 11:34
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv3.4.1 (published 2008-09) 
Target Versionv4.3.1 (published 2011-06)Fixed in Versionv4.3.1 (published 2011-06) 
Source (company - Author)L.M.Ericsson
Summary0005677: Extend the @requirement tag to dynamic language elements and to module
DescriptionAs discussed in STF393, a TTCN-3 RTS test case - except for specific cases like checking of import - is a TTCN-3 module, not necessarily containing any dynamic language elements. Hence the @requirement tag should be extended to modules. But for consistency and flexibility reasons it should aso be available for other dynamic language elements
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
03-09-2010 09:56Gyorgy RethyNew Issue
03-09-2010 09:56Gyorgy RethySource (company - Author) => L.M.Ericsson
03-09-2010 09:57Gyorgy RethyAssigned To => Gyorgy Rethy
03-09-2010 09:57Gyorgy RethyStatusnew => assigned
03-09-2010 09:57Gyorgy RethyTarget Version => Edition 4.3.1 (not yet published)
01-12-2010 11:34Gyorgy RethyStatusassigned => closed
01-12-2010 11:34Gyorgy RethyResolutionopen => fixed
01-12-2010 11:34Gyorgy RethyFixed in Version => Edition 4.3.1 (not yet published)
+
+ + + + +
+ There are no notes attached to this issue.
+ + diff --git a/docs/mantis/CR5720.md b/docs/mantis/CR5720.md new file mode 100644 index 0000000000000000000000000000000000000000..704934a6cd5a3de5ea5040c6e373517df7c50fa4 --- /dev/null +++ b/docs/mantis/CR5720.md @@ -0,0 +1,158 @@ + + + + + + + + + + + + + 0005720: Replace ISO/IEC references with ITU-T references - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005720Part 01: TTCN-3 Core LanguageEditorialpublic14-09-2010 16:2301-12-2010 16:32
ReporterGyorgy Rethy 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.3.1 (published 2011-06)Fixed in Versionv4.3.1 (published 2011-06) 
Clause Reference(s)References and Bibliographies
Source (company - Author)L.M.Ericson
Summary0005720: Replace ISO/IEC references with ITU-T references
DescriptionITU-T SG17 asked TB MTS in its liaison to replace ISO/IEC references with equivalent ITU-T references, where such exists (see MTS(10)0036). MTS#51 noted the liaison and welcomed the synchronization, therefore it has to be applied in the coming version of the ES 201 873 series an in all extension packages (where appropriate).
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0005722closed Ina Schieferdecker Part 05: TTCN-3 Runtime Interface  Replace ISO/IEC references with ITU-T references 
related to 0005723closed Ina Schieferdecker Part 06: TTCN-3 Control Interface Replace ISO/IEC references with ITU-T references 
Attached Fileszip es_20187301v040203_withNewBNF.zip (804,441) 01-12-2010 16:31
http://oldforge.etsi.org/mantis/file_download.php?file_id=2460&type=bug
Issue History
Date ModifiedUsernameFieldChange
14-09-2010 16:23Gyorgy RethyNew Issue
14-09-2010 16:23Gyorgy RethyClause Reference(s) => References and Bibliographies
14-09-2010 16:23Gyorgy RethySource (company - Author) => L.M.Ericson
14-09-2010 16:24Gyorgy RethySummaryReplace ISO/IEC references with ITU-T References => Replace ISO/IEC references with ITU-T references
14-09-2010 16:24Gyorgy RethyDescription Updated
14-09-2010 16:39Gyorgy RethyProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
24-11-2010 13:10Gyorgy RethyNote Added: 0009798
24-11-2010 13:33Gyorgy RethyNote Edited: 0009798
30-11-2010 15:34Gyorgy RethyNote Added: 0009853
30-11-2010 15:34Gyorgy RethyAssigned To => Ina Schieferdecker
30-11-2010 15:34Gyorgy RethyStatusnew => assigned
01-12-2010 10:00Ina SchieferdeckerRelationship addedrelated to 0005722
01-12-2010 10:00Ina SchieferdeckerRelationship addedrelated to 0005723
01-12-2010 16:28Ina SchieferdeckerNote Added: 0009901
01-12-2010 16:31Ina SchieferdeckerFile Added: es_20187301v040203_withNewBNF.zip
01-12-2010 16:32Ina SchieferdeckerStatusassigned => resolved
01-12-2010 16:32Ina SchieferdeckerResolutionopen => fixed
01-12-2010 16:32Ina SchieferdeckerFixed in Version => Edition 4.3.1 (not yet published)
01-12-2010 16:32Ina SchieferdeckerTarget Version => Edition 4.3.1 (not yet published)
01-12-2010 16:32Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009798) +
+ Gyorgy Rethy    +
+ 24-11-2010 13:10    +
(edited on: 24-11-2010 13:33)
+ 		+ + + + +
+ Equivalent ITU-T references (proposed to reference without date) :
+-----------------------
+ISO/IEC 9646-1
+-> ITU-T Recommendation X.290 (04/95): Data Networks and Open System Communications; Open Systems Interconnection – Conformance testing; OSI conformance testing methodology and framework for protocol Recommendations for ITU-T applications – General concepts
+-----------------------
+ISO/IEC 9646-3 (1998)
+-> ITU-T Recommendation X.292(05/2002): Series X: Data Networks and Open System Communications; Open Systems Interconnection – Conformance testing; OSI conformance testing methodology and framework for protocol Recommendations for ITU-T applications – The Tree and Tabular Combined Notation (TTCN)
+-----------------------
+ISO/IEC 10646 (Unicode)
+->
+
+-----------------------
+ISO/IEC 646 (1991) (7-bit character set)
+-> ITU-T Recommendation T.50(09/92): Terminal Equipment and Protocols for Telematic Services; International Reference Alphabet (IRA) (Formerly International Alphabet No. 5 or IA5); Information technology – 7-Bit coded character set for information interchange
+-----------------------
+ISO/IEC 6429 (1992) (used in whitespace and new line character definitions and definition of special pattern characters)
+-> all references can be replaced by T.50! (actually in A.1.5.1 ref. to ISO/IEC 6429 is superflouos)
+-----------------------
+ISO/IEC 8859-1 (1998) (inf.ref. in Part-1)
+-> used to explain the iso8859string type in $E.2.2.3. The given set of characters can also be referenced as ISO 10646 Basic Latin + Latin-1 Supplement graphical characters (note, ISO/IEC 8859-1 does not contain control characters, while the iso8859string type does!; in this sense the current explanation is not correct)
+-----------------------
+ISO 3166-1 (inf.ref. in Part-7, usede in inf.annex C.1, note 5)
+No equivalent has been found
+-----------------------
+ISO 8601 (inf.ref. in Part-7)
+No equivalent has been found
+
+
+
+
+
+ + + + + + + + + + +
+ (0009853) +
+ Gyorgy Rethy    +
+ 30-11-2010 15:34    +
+ 		+ + + + +
+ STF discussion on 30-11-2010: Change for the ITU-T refs. where exist and retain the ISO/IEC refrerences in notes.
+
+
+
+ + + + + + + + + + +
+ (0009901) +
+ Ina Schieferdecker    +
+ 01-12-2010 16:28    +
+ 		+ + + + +
+ As proposed.
+
+ + diff --git a/docs/mantis/CR5722.md b/docs/mantis/CR5722.md new file mode 100644 index 0000000000000000000000000000000000000000..61f77ac3f103ae06d1de084d5a31db169b172454 --- /dev/null +++ b/docs/mantis/CR5722.md @@ -0,0 +1,63 @@ + + + + + + + + + + + + + 0005722: Replace ISO/IEC references with ITU-T references - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 05: TTCN-3 Runtime Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005722Part 05: TTCN-3 Runtime Interface Editorialpublic14-09-2010 16:4017-12-2010 16:14
ReporterGyorgy Rethy 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.3.1 (published 2011-06)Fixed in Versionv4.3.1 (published 2011-06) 
Clause Reference(s)References
Source (company - Author)L.M.Ericsson
Summary0005722: Replace ISO/IEC references with ITU-T references
DescriptionITU-T SG17 asked TB MTS in its liaison to replace ISO/IEC references with equivalent ITU-T references, where such exists (see MTS(10)0036). MTS#51 noted the liaison and welcomed the synchronization, therefore it has to be applied in the coming version of the ES 201 873 series an in all extension packages (where appropriate).
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0005720closed Ina Schieferdecker Part 01: TTCN-3 Core Language Replace ISO/IEC references with ITU-T references 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
14-09-2010 16:40Gyorgy RethyNew Issue
14-09-2010 16:40Gyorgy RethyClause Reference(s) => References
14-09-2010 16:40Gyorgy RethySource (company - Author) => L.M.Ericsson
30-11-2010 17:39Gyorgy RethyAssigned To => Ina Schieferdecker
30-11-2010 17:39Gyorgy RethyStatusnew => assigned
30-11-2010 17:39Gyorgy RethyTarget Version => Edition 4.3.1 (not yet published)
01-12-2010 10:00Ina SchieferdeckerRelationship addedrelated to 0005720
17-12-2010 16:13Ina SchieferdeckerNote Added: 0009981
17-12-2010 16:13Ina SchieferdeckerStatusassigned => resolved
17-12-2010 16:13Ina SchieferdeckerResolutionopen => fixed
17-12-2010 16:13Ina SchieferdeckerFixed in Version => Edition 4.3.1 (not yet published)
17-12-2010 16:14Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009981) +
+ Ina Schieferdecker    +
+ 17-12-2010 16:13    +
+ 		+ + + + +
+ As proposed.
+
+ + diff --git a/docs/mantis/CR5723.md b/docs/mantis/CR5723.md new file mode 100644 index 0000000000000000000000000000000000000000..4e6a410605e489d36e2aec545b0c9c3dbc41b051 --- /dev/null +++ b/docs/mantis/CR5723.md @@ -0,0 +1,63 @@ + + + + + + + + + + + + + 0005723: Replace ISO/IEC references with ITU-T references - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005723Part 06: TTCN-3 Control InterfaceEditorialpublic14-09-2010 16:4217-12-2010 16:15
ReporterGyorgy Rethy 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.3.1 (published 2011-06)Fixed in Versionv4.3.1 (published 2011-06) 
Clause Reference(s)References
Source (company - Author)L.M.Ericsson
Summary0005723: Replace ISO/IEC references with ITU-T references
DescriptionITU-T SG17 asked TB MTS in its liaison to replace ISO/IEC references with equivalent ITU-T references, where such exists (see MTS(10)0036). MTS#51 noted the liaison and welcomed the synchronization, therefore it has to be applied in the coming version of the ES 201 873 series an in all extension packages (where appropriate).
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0005720closed Ina Schieferdecker Part 01: TTCN-3 Core Language Replace ISO/IEC references with ITU-T references 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
14-09-2010 16:42Gyorgy RethyNew Issue
14-09-2010 16:42Gyorgy RethyClause Reference(s) => References
14-09-2010 16:42Gyorgy RethySource (company - Author) => L.M.Ericsson
30-11-2010 17:43Gyorgy RethyAssigned To => Ina Schieferdecker
30-11-2010 17:43Gyorgy RethyStatusnew => assigned
30-11-2010 17:43Gyorgy RethyTarget Version => Edition 4.3.1 (not yet published)
01-12-2010 10:00Ina SchieferdeckerRelationship addedrelated to 0005720
17-12-2010 16:15Ina SchieferdeckerNote Added: 0009982
17-12-2010 16:15Ina SchieferdeckerStatusassigned => resolved
17-12-2010 16:15Ina SchieferdeckerResolutionopen => fixed
17-12-2010 16:15Ina SchieferdeckerFixed in Version => Edition 4.3.1 (not yet published)
17-12-2010 16:15Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009982) +
+ Ina Schieferdecker    +
+ 17-12-2010 16:15    +
+ 		+ + + + +
+ Implemented as proposed
+
+ + diff --git a/docs/mantis/CR5724.md b/docs/mantis/CR5724.md new file mode 100644 index 0000000000000000000000000000000000000000..1e78f978e69b7876a194ae35794dbe845a3314b6 --- /dev/null +++ b/docs/mantis/CR5724.md @@ -0,0 +1,63 @@ + + + + + + + + + + + + + 0005724: Replace ISO/IEC references with equivalent ITU-T references - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 07: Using ASN.1 with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005724Part 07: Using ASN.1 with TTCN-3Editorialpublic14-09-2010 16:4308-12-2010 14:23
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionno change required 
PlatformOSOS Version
Product Version 
Target Versionv4.3.1 (published 2011-06)Fixed in Versionv4.3.1 (published 2011-06) 
Clause Reference(s)References
Source (company - Author)L.M.Ericcson
Summary0005724: Replace ISO/IEC references with equivalent ITU-T references
DescriptionITU-T SG17 asked TB MTS in its liaison to replace ISO/IEC references with equivalent ITU-T references, where such exists (see MTS(10)0036). MTS#51 noted the liaison and welcomed the synchronization, therefore it has to be applied in the coming version of the ES 201 873 series an in all extension packages (where appropriate).
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
14-09-2010 16:43Gyorgy RethyNew Issue
14-09-2010 16:43Gyorgy RethyClause Reference(s) => References
14-09-2010 16:43Gyorgy RethySource (company - Author) => L.M.Ericcson
14-09-2010 16:44Gyorgy RethyProjectPart 06: TTCN-3 Control Interface => Part 07: Using ASN.1 with TTCN-3
30-11-2010 17:38Gyorgy RethyAssigned To => Gyorgy Rethy
30-11-2010 17:38Gyorgy RethyStatusnew => assigned
30-11-2010 17:38Gyorgy RethyTarget Version => Edition 4.3.1 (not yet published)
08-12-2010 14:23Gyorgy RethyNote Added: 0009951
08-12-2010 14:23Gyorgy RethyStatusassigned => closed
08-12-2010 14:23Gyorgy RethyResolutionopen => no change required
08-12-2010 14:23Gyorgy RethyFixed in Version => Edition 4.3.1 (not yet published)
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009951) +
+ Gyorgy Rethy    +
+ 08-12-2010 14:23    +
+ 		+ + + + +
+ Contains only informative ISO refernces and those have no ITU-T equivalence.
+
+ + diff --git a/docs/mantis/CR5725.md b/docs/mantis/CR5725.md new file mode 100644 index 0000000000000000000000000000000000000000..a1aa6f0c34deed1078d655d4b218d95bb1a30d3b --- /dev/null +++ b/docs/mantis/CR5725.md @@ -0,0 +1,63 @@ + + + + + + + + + + + + + 0005725: Replace ISO/IEC references with ITU-T references - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 08: Using IDL with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005725Part 08: Using IDL with TTCN-3Editorialpublic14-09-2010 16:4508-12-2010 14:20
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.3.1 (published 2011-06)Fixed in Versionv4.3.1 (published 2011-06) 
Clause Reference(s)References & Bibliography
Source (company - Author)L.M.Ericsson
Summary0005725: Replace ISO/IEC references with ITU-T references
DescriptionITU-T SG17 asked TB MTS in its liaison to replace ISO/IEC references with equivalent ITU-T references, where such exists (see MTS(10)0036). MTS#51 noted the liaison and welcomed the synchronization, therefore it has to be applied in the coming version of the ES 201 873 series an in all extension packages (where appropriate).
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
14-09-2010 16:45Gyorgy RethyNew Issue
14-09-2010 16:45Gyorgy RethyClause Reference(s) => References
14-09-2010 16:45Gyorgy RethySource (company - Author) => L.M.Ericsson
14-09-2010 16:46Gyorgy RethyProjectPart 06: TTCN-3 Control Interface => Part 08: Using IDL with TTCN-3
14-09-2010 16:50Gyorgy RethyClause Reference(s)References => References & Bibliography
30-11-2010 17:44Gyorgy RethyStatusnew => assigned
30-11-2010 17:44Gyorgy RethyAssigned To => Gyorgy Rethy
08-12-2010 14:20Gyorgy RethyNote Added: 0009950
08-12-2010 14:20Gyorgy RethyStatusassigned => closed
08-12-2010 14:20Gyorgy RethyResolutionopen => fixed
08-12-2010 14:20Gyorgy RethyFixed in Version => Edition 4.3.1 (not yet published)
08-12-2010 14:20Gyorgy RethyTarget Version => Edition 4.3.1 (not yet published)
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009950) +
+ Gyorgy Rethy    +
+ 08-12-2010 14:20    +
+ 		+ + + + +
+ Done. Also two unused references are deleted.
+
+ + diff --git a/docs/mantis/CR5726.md b/docs/mantis/CR5726.md new file mode 100644 index 0000000000000000000000000000000000000000..a248ca3ff02896ad30f10c8a3762934474fe36d4 --- /dev/null +++ b/docs/mantis/CR5726.md @@ -0,0 +1,63 @@ + + + + + + + + + + + + + 0005726: Replace ISO/IEC references with ITU-T references - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005726Part 09: Using XML with TTCN-3Editorialpublic14-09-2010 16:5206-12-2010 11:29
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionno change required 
PlatformOSOS Version
Product Version 
Target Versionv4.3.1 (published 2011-06)Fixed in Versionv4.3.1 (published 2011-06) 
Clause Reference(s)References
For STF discussion
Source (company - Author)L.M.Ericsson
Summary0005726: Replace ISO/IEC references with ITU-T references
DescriptionITU-T SG17 asked TB MTS in its liaison to replace ISO/IEC references with equivalent ITU-T references, where such exists (see MTS(10)0036). MTS#51 noted the liaison and welcomed the synchronization, therefore it has to be applied in the coming version of the ES 201 873 series an in all extension packages (where appropriate).
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
14-09-2010 16:52Gyorgy RethyNew Issue
14-09-2010 16:52Gyorgy RethyClause Reference(s) => References
14-09-2010 16:52Gyorgy RethySource (company - Author) => L.M.Ericsson
14-09-2010 16:52Gyorgy RethyProjectPart 06: TTCN-3 Control Interface => Part 09: Using XML with TTCN-3
30-11-2010 17:44Gyorgy RethyStatusnew => assigned
30-11-2010 17:44Gyorgy RethyAssigned To => Gyorgy Rethy
06-12-2010 11:29Gyorgy RethyNote Added: 0009940
06-12-2010 11:29Gyorgy RethyStatusassigned => closed
06-12-2010 11:29Gyorgy RethyResolutionopen => no change required
06-12-2010 11:29Gyorgy RethyFixed in Version => Edition 4.3.1 (not yet published)
06-12-2010 11:29Gyorgy RethyTarget Version => Edition 4.3.1 (not yet published)
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009940) +
+ Gyorgy Rethy    +
+ 06-12-2010 11:29    +
+ 		+ + + + +
+ Contains only 1 informative ref. to ISO 8601 that has no ITU-T equivalence.
+
+ + diff --git a/docs/mantis/CR5764.md b/docs/mantis/CR5764.md new file mode 100644 index 0000000000000000000000000000000000000000..bc30dc33130d2d16b96b159a652af8f731ffe5ac --- /dev/null +++ b/docs/mantis/CR5764.md @@ -0,0 +1,44 @@ + + + + + + + + + + + + + 0005764: Wrong <choice> group example - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005764Part 09: Using XML with TTCN-3Technicalpublic27-09-2010 16:4801-12-2010 08:30
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.1.1 (published 2009-06) 
Target Versionv4.3.1 (published 2011-06)Fixed in Versionv4.3.1 (published 2011-06) 
Clause Reference(s)7.9
For STF discussion
Source (company - Author)L.M.Ericsson
Summary0005764: Wrong <choice> group example
DescriptionCurrent example in $7.9 is:
+type record ShipOrBill {
+XSD.String shipTo,
+XSD.String billTo
+}
+with {
+variant "untagged"
+}
+It should be:
+type union ShipOrBill {
+XSD.String shipTo,
+XSD.String billTo
+}
+with {
+variant "untagged"
+}
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
27-09-2010 16:48Gyorgy RethyNew Issue
27-09-2010 16:48Gyorgy RethyClause Reference(s) => 7.9
27-09-2010 16:48Gyorgy RethySource (company - Author) => L.M.Ericsson
30-11-2010 17:45Gyorgy RethyStatusnew => assigned
30-11-2010 17:45Gyorgy RethyAssigned To => Gyorgy Rethy
01-12-2010 08:30Gyorgy RethyStatusassigned => closed
01-12-2010 08:30Gyorgy RethyResolutionopen => fixed
01-12-2010 08:30Gyorgy RethyFixed in Version => Edition 4.3.1 (not yet published)
01-12-2010 08:30Gyorgy RethyTarget Version => Edition 4.3.1 (not yet published)
+
+ + + + +
+ There are no notes attached to this issue.
+ + diff --git a/docs/mantis/CR5769.md b/docs/mantis/CR5769.md new file mode 100644 index 0000000000000000000000000000000000000000..58e229e566008a86e548a4e53f913d5f05f97dcd --- /dev/null +++ b/docs/mantis/CR5769.md @@ -0,0 +1,499 @@ + + + + + + + + + + + + + 0005769: regexp introduces expression inconsistency - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005769Part 01: TTCN-3 Core LanguageTechnicalpublic28-09-2010 15:2311-07-2012 09:56
ReporterJacob Wieland - Spirent 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.5.1 (published 2013-04)Fixed in Versionv4.5.1 (published 2013-04) 
Clause Reference(s)C.33
Source (company - Author)Testing Technologies - Jacob Wieland
Summary0005769: regexp introduces expression inconsistency
DescriptionIn the description of regexp, the examples use expressions for the 'expression' paramter like:
+
+charstring:"?(text)?"
+
+In all other contexts in TTCN-3, this has the meaning: matching the value "?(text)?" as opposed to charstring:pattern "?(text)?" which has the meaning matching all values which have length 8 and have the substring '(text)' in the middle.
+
+Former versions of the standard allowed expressions like regexp(v, "?(text)?", x) as a shorthand for regexp(v, charstring:pattern "?(text)?", x). Even though this already is inconsistent with the rest of the language, where string literals stand for their values and not for a pattern unless prepended by 'pattern', it is an understandable shorthand and since the expression cannot be referenced, it's meaning is properly defined by its place of usage. But now, allowing the expression charstring:"?(text)?", as well, suggests to the user that if he had a VALUE variable p of type charstring which contains "?(text)?" as its current value and then wrote regexp(v, charstring:p, x) this means the same as regexp(v, charstring:"?(text)?", x).
+
+This again would mean that the tool would never be able to process such expressions statically, but only at runtime and since such expressions can contain references to other variables, this would mean that all context information about such variables would have to be available at runtime as well (per some sort of 'reflection') to enable the tool to produce the proper matching algorithm. Since reflection at runtime is always costly, such a consequence is undesirable and should be avoided.
+
+Therefore, the describing text and the examples should be changed in such a way that if expression p is:
+
+- a string literal it is a shorthand for 'pattern p'
+  - this would mean that this pattern is automatically assumed to be of the
+    same base string type as inpar
+- an inline template it is interpreted like inline templates in the language everywhere else,
+  i.e. charstring:"?(text)?" is not the same as charstring:pattern "?(text)?"
+- a value reference of basetype c it is taken literally, i.e. it is treated like c:p, meaning all characters that have special meaning in patterns are treated in the regular expressions as if they were escaped by a '\', thus matching only the value p.
+- a template reference of basetype c, then this will be treated like a value or pattern if it is a value or pattern template, otherwise, it will cause an error.
+
+As a compromise (even though it would leave the inconsistency intact), inline templates with an explicit string literal could still be allowed with the same meaning as is described now in the text, however, this could be confusing for the user as then
+
+var template charstring p := "?(text)?"
+...
+regexp(inpar, p, x)
+
+would have a different meaning than
+
+regexp(inpar, charstring:"?(text)?", x)
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Fileszip PatternTest.zip (1,761) 24-05-2011 19:07
http://oldforge.etsi.org/mantis/file_download.php?file_id=2476&type=bug
doc CR5769-proposal.doc (90,624) 30-09-2011 16:16
http://oldforge.etsi.org/mantis/file_download.php?file_id=2588&type=bug
doc CR5769-proposal_v2.doc (96,768) 01-12-2011 16:05
http://oldforge.etsi.org/mantis/file_download.php?file_id=2648&type=bug
doc CR5769-proposal_v3.doc (100,352) 01-12-2011 17:41
http://oldforge.etsi.org/mantis/file_download.php?file_id=2652&type=bug
doc CR5769-proposal_v4.doc (100,352) 02-12-2011 09:20
http://oldforge.etsi.org/mantis/file_download.php?file_id=2653&type=bug
Issue History
Date ModifiedUsernameFieldChange
28-09-2010 15:23Jacob Wieland - SpirentNew Issue
28-09-2010 15:23Jacob Wieland - SpirentClause Reference(s) => C.33
28-09-2010 15:23Jacob Wieland - SpirentSource (company - Author) => Testing Technologies - Jacob Wieland
30-11-2010 09:44Ina SchieferdeckerProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
30-11-2010 11:33Jacob Wieland - SpirentDescription Updated
13-12-2010 12:43Gyorgy RethyTarget Version => Edition 4.3.2 (interim)
24-05-2011 16:58Gyorgy RethyNote Added: 0010035
24-05-2011 16:58Gyorgy RethyStatusnew => assigned
24-05-2011 16:58Gyorgy RethyAssigned To => Jacob Wieland - Spirent
24-05-2011 19:07Jacob Wieland - SpirentFile Added: PatternTest.zip
24-05-2011 19:11Jacob Wieland - SpirentNote Added: 0010040
27-09-2011 14:05Gyorgy RethyTarget VersionEdition 4.3.2 (interim) => Edition 4.4.1
30-09-2011 16:10Jacob Wieland - SpirentFile Added: CR5769-proposal.doc
30-09-2011 16:13Jacob Wieland - SpirentNote Added: 0010317
30-09-2011 16:16Jacob Wieland - SpirentFile Deleted: CR5769-proposal.doc
30-09-2011 16:16Jacob Wieland - SpirentFile Added: CR5769-proposal.doc
29-11-2011 12:33Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
29-11-2011 12:33Jacob Wieland - SpirentNote Added: 0010389
01-12-2011 16:05Gyorgy RethyFile Added: CR5769-proposal_v2.doc
01-12-2011 16:07Gyorgy RethyNote Added: 0010490
01-12-2011 16:07Gyorgy RethyNote Edited: 0010490
01-12-2011 16:08Gyorgy RethyNote Edited: 0010490
01-12-2011 16:08Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
01-12-2011 16:27Jacob Wieland - SpirentNote Added: 0010493
01-12-2011 17:19Gyorgy RethyFile Added: regexp.zip
01-12-2011 17:27Gyorgy RethyFile Deleted: regexp.zip
01-12-2011 17:40Gyorgy RethyNote Added: 0010495
01-12-2011 17:41Gyorgy RethyFile Added: CR5769-proposal_v3.doc
01-12-2011 17:42Gyorgy RethyNote Edited: 0010495
01-12-2011 17:42Gyorgy RethyAssigned ToIna Schieferdecker => Jacob Wieland - Spirent
01-12-2011 17:43Gyorgy RethyNote Edited: 0010495
02-12-2011 09:12Gyorgy RethyNote Added: 0010499
02-12-2011 09:20Gyorgy RethyFile Added: CR5769-proposal_v4.doc
02-12-2011 10:38Jacob Wieland - SpirentNote Added: 0010504
02-12-2011 10:41Jacob Wieland - SpirentStatusassigned => resolved
02-12-2011 10:41Jacob Wieland - SpirentResolutionopen => fixed
02-12-2011 10:41Jacob Wieland - SpirentNote Added: 0010505
02-12-2011 13:43Gyorgy RethyAssigned ToJacob Wieland - Spirent => Ina Schieferdecker
02-12-2011 13:43Gyorgy RethyStatusresolved => feedback
02-12-2011 13:43Gyorgy RethyResolutionfixed => reopened
02-12-2011 13:43Gyorgy RethyNote Added: 0010520
02-12-2011 13:43Gyorgy RethyStatusfeedback => resolved
02-12-2011 13:43Gyorgy RethyResolutionreopened => fixed
02-12-2011 13:43Gyorgy RethyFixed in Version => Edition 4.4.1
09-07-2012 17:15Ina SchieferdeckerFixed in VersionEdition 4.4.1 =>
09-07-2012 17:15Ina SchieferdeckerTarget VersionEdition 4.4.1 => Edition 4.5.1
11-07-2012 09:56Ina SchieferdeckerNote Added: 0010801
11-07-2012 09:56Ina SchieferdeckerStatusresolved => closed
11-07-2012 09:56Ina SchieferdeckerFixed in Version => Edition 4.5.1
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010035) +
+ Gyorgy Rethy    +
+ 24-05-2011 16:58    +
+ 		+ + + + +
+ Check with tool vendors what is implemented: reference of local constants, local variables, global constants, module parameters etc. Write a test code and ask vendors to return the result.
+
+
+
+ + + + + + + + + + +
+ (0010040) +
+ Jacob Wieland - Spirent    +
+ 24-05-2011 19:11    +
+ 		+ + + + +
+ If the implementation is standard-conform, the testcases in PatternTest.zip should either pass or give the error verdict (respective to their description).
+
+
+
+ + + + + + + + + + +
+ (0010317) +
+ Jacob Wieland - Spirent    +
+ 30-09-2011 16:13    +
+ 		+ + + + +
+ Discussion with Gyorgy yielded the following compromise. A note is added that local definitions cannot be referenced from a regular expression which is interpreted from a value-template, as the regexp function has no access to local definitions. Trying to reference unknown references will lead to a test case error.
+
+I also added another note saying that the regular expression needs to be well-formed to not result in a test case error.
+
+
+
+ + + + + + + + + + +
+ (0010389) +
+ Jacob Wieland - Spirent    +
+ 29-11-2011 12:33    +
+ 		+ + + + +
+ please review
+
+
+
+ + + + + + + + + + +
+ (0010490) +
+ Gyorgy Rethy    +
+ 01-12-2011 16:07    +
(edited on: 01-12-2011 16:08)
+ 		+ + + + +
+ CR5769-proposal_v2.doc: as discussed with Jacob, the requirement that global definition names shall be qualified is deleted and some editorials. pls. make a final review, from my side is OK.
+
+
+
+
+
+ + + + + + + + + + +
+ (0010493) +
+ Jacob Wieland - Spirent    +
+ 01-12-2011 16:27    +
+ 		+ + + + +
+ If unqualified references shall be resolvable at runtime, the following testcase should pass.
+
+module A {
+  const charstring x := "foo";
+  const charstring y := "bar";
+}
+
+module B {
+  import from A all;
+  
+  function f(charstring pat) {
+    const charstring result := regexp("foobar", pat, 0);
+    if (result == "foo" or result == "bar") {
+      setverdict (pass);
+    }
+  }
+   
+  type component C {}
+
+  testcase T() runs on C system C {
+    var boolean b := rnd() * 2.0 > 1.0;
+    if (b) {
+      f("*{x}*");
+    }
+    else {
+      f("*{y}*");
+    }
+  }
+}
+
+
+
+ + + + + + + + + + +
+ (0010495) +
+ Gyorgy Rethy    +
+ 01-12-2011 17:40    +
(edited on: 01-12-2011 17:43)
+ 		+ + + + +
+ I understand your example, it will not work with values, only if the actual parameter of f() is a pattern. But these are two requirements that shall not be in notes, thus I made them body text. I have updated the proposed solution (CR5769-proposal_v3.doc), pls. review.
+
+
+
+
+
+ + + + + + + + + + +
+ (0010499) +
+ Gyorgy Rethy    +
+ 02-12-2011 09:12    +
+ 		+ + + + +
+ I have further simplified and clarified the text in CR5769-proposal_v4.doc. Pls. review this version instead of the previous versions.
+
+
+
+ + + + + + + + + + +
+ (0010504) +
+ Jacob Wieland - Spirent    +
+ 02-12-2011 10:38    +
+ 		+ + + + +
+ okay with me.
+
+
+
+ + + + + + + + + + +
+ (0010505) +
+ Jacob Wieland - Spirent    +
+ 02-12-2011 10:41    +
+ 		+ + + + +
+ problem resolved
+
+
+
+ + + + + + + + + + +
+ (0010520) +
+ Gyorgy Rethy    +
+ 02-12-2011 13:43    +
+ 		+ + + + +
+ Reopening the CR just to assign it Ina.
+
+
+
+ + + + + + + + + + +
+ (0010801) +
+ Ina Schieferdecker    +
+ 11-07-2012 09:56    +
+ 		+ + + + +
+ Implemented as proposed in v4
+
+ + diff --git a/docs/mantis/CR5773.md b/docs/mantis/CR5773.md new file mode 100644 index 0000000000000000000000000000000000000000..db01ab14562c7bf6eec7a5ac6291d37642e6c642 --- /dev/null +++ b/docs/mantis/CR5773.md @@ -0,0 +1,162 @@ + + + + + + + + + + + + + 0005773: Further clarification of decoding union values is needed - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005773Part 09: Using XML with TTCN-3Clarificationpublic29-09-2010 11:2202-12-2010 09:21
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.3.1 (published 2011-06)Fixed in Versionv4.3.1 (published 2011-06) 
Clause Reference(s)7.5.3
For STF discussion
Source (company - Author)L.M.Ericsson
Summary0005773: Further clarification of decoding union values is needed
DescriptionCurrent note in clause 7.5.3 is:
+"NOTE 1: XSD requires (see XML Schema Part 2: Datatypes [9], clause 2.5.1.3) that an element or attribute value is validated against the member types in the order in which they appear in the definition until a match is found. A TTCN-3 tool has to use this strategy as well, when decoding an XSD union value."
+
+For further clarification it should be added that "taking into account the xsi:type attribte, if present, and the value in the XML instance"
+
+This note should also be referenced from clause B.3.16 Use Union.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
29-09-2010 11:22Gyorgy RethyNew Issue
29-09-2010 11:22Gyorgy RethyClause Reference(s) => 7.5.3
29-09-2010 11:22Gyorgy RethySource (company - Author) => L.M.Ericsson
29-09-2010 11:23Gyorgy RethyDescription Updated
29-11-2010 11:24Gyorgy RethyNote Added: 0009822
29-11-2010 11:25Gyorgy RethyNote Edited: 0009822
29-11-2010 11:26Gyorgy RethyAssigned To => Jacob Wieland - Spirent
29-11-2010 11:26Gyorgy RethyStatusnew => assigned
29-11-2010 11:26Gyorgy RethyTarget Version => Edition 4.3.1 (not yet published)
29-11-2010 12:27Jacob Wieland - SpirentNote Added: 0009824
29-11-2010 12:28Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
30-11-2010 15:41Gyorgy RethyStatusassigned => resolved
30-11-2010 15:41Gyorgy RethyResolutionopen => fixed
30-11-2010 15:41Gyorgy RethyFixed in Version => Edition 4.3.1 (not yet published)
02-12-2010 09:21Gyorgy RethyStatusresolved => closed
02-12-2010 09:21Gyorgy RethyNote Added: 0009915
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009822) +
+ Gyorgy Rethy    +
+ 29-11-2010 11:24    +
(edited on: 29-11-2010 11:25)
+ 		+ + + + +
+ Additional clarification: e.g. if the XSD type is
+...
+<xsd:simpleType>
+    <xsd:union>
+        <xsd:simpleType>
+            <xsd:restriction base="xsd:integer"/>
+        </xsd:simpleType>
+        <xsd:simpleType>
+            <xsd:restriction base="xsd:string"/>
+        </xsd:simpleType>
+    </xsd:union>
+</xsd:simpleType>
+
+the XML element
+  <e21unnamedElement>1</e21unnamedElement>
+will be decoded as an integer value, while
+
+  <e21unnamedElement xsi:type="xsd:string">1</e21unnamedElement>
+will be decoded as a string value
+
+Note 1 is proposed to be extended to:
+
+"NOTE 1: XSD requires (see XML Schema Part 2: Datatypes [9], clause 2.5.1.3) that an element or attribute value of an instance is validated against the member types in the order in which they appear in the XSD definition until a match is found (considering any xsi:type attribute present, see also clause B.3.25). A TTCN-3 tool has to use this strategy as well, when decoding an XSD union value."
+
+Pls. check the proposal
+
+
+
+
+
+ + + + + + + + + + +
+ (0009824) +
+ Jacob Wieland - Spirent    +
+ 29-11-2010 12:27    +
+ 		+ + + + +
+ agreed
+
+
+
+ + + + + + + + + + +
+ (0009915) +
+ Gyorgy Rethy    +
+ 02-12-2010 09:21    +
+ 		+ + + + +
+ Done
+
+ + diff --git a/docs/mantis/CR5775.md b/docs/mantis/CR5775.md new file mode 100644 index 0000000000000000000000000000000000000000..9e76e5e21d5e387b542f4e8f6b760b55961d0c7b --- /dev/null +++ b/docs/mantis/CR5775.md @@ -0,0 +1,205 @@ + + + + + + + + + + + + + 0005775: More flexible encoding of elements derived by union - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005775Part 09: Using XML with TTCN-3New Featurepublic29-09-2010 12:1101-12-2011 11:39
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.4.1 (published 2012-04)Fixed in Versionv4.4.1 (published 2012-04) 
Clause Reference(s)B.3.16
For STF discussion
Source (company - Author)L.M.Ericsson
Summary0005775: More flexible encoding of elements derived by union
DescriptionIn clause B.3.16 Use Union it is specified that the encoder shall include the xsi:type attribute into the XML instance of a simpleType element derived by union. However, from the testing perspective it would be more flexible if data couldbe sent both by using the xsi:type attribute or without it.
+
+The new encoding instruction useType, added due to type substitutio would allow to control the presence of the xsi:type attribute from the TTCN-3 code. However, simply removing adding the xsi:type attribute from clause B.3.16 Use Union would be backward incompatible, as would change existing encoding.
+
+Therefore it is proposed: allow not to include xsi:type when useUnion is used without useType as a tool option.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR5775.doc (80,384) 30-11-2011 11:12
http://oldforge.etsi.org/mantis/file_download.php?file_id=2617&type=bug
Issue History
Date ModifiedUsernameFieldChange
29-09-2010 12:11Gyorgy RethyNew Issue
29-09-2010 12:11Gyorgy RethyClause Reference(s) => B.3.16
29-09-2010 12:11Gyorgy RethySource (company - Author) => L.M.Ericsson
30-11-2010 15:47Gyorgy RethyNote Added: 0009854
30-11-2010 15:47Gyorgy RethyAssigned To => Gyorgy Rethy
30-11-2010 15:47Gyorgy RethyStatusnew => assigned
30-11-2010 15:47Gyorgy RethyTarget Version => Edition 4.3.1 (not yet published)
03-12-2010 10:13Gyorgy RethyTarget VersionEdition 4.3.1 (not yet published) => Edition 4.3.2 (interim)
13-07-2011 17:05Gyorgy RethyTarget VersionEdition 4.3.2 (interim) => Edition 4.4.1
30-11-2011 09:51Gyorgy RethyAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
30-11-2011 09:52Gyorgy RethyNote Added: 0010421
30-11-2011 09:52Gyorgy RethyNote Edited: 0010421
30-11-2011 11:12Jacob Wieland - SpirentFile Added: CR5775.doc
30-11-2011 11:12Jacob Wieland - SpirentNote Added: 0010436
30-11-2011 11:12Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
01-12-2011 11:20Gyorgy RethyStatusassigned => resolved
01-12-2011 11:20Gyorgy RethyFixed in Version => Edition 4.4.1
01-12-2011 11:20Gyorgy RethyResolutionopen => fixed
01-12-2011 11:20Gyorgy RethyNote Added: 0010467
01-12-2011 11:39Gyorgy RethyStatusresolved => closed
01-12-2011 11:39Gyorgy RethyNote Added: 0010470
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009854) +
+ Gyorgy Rethy    +
+ 30-11-2010 15:47    +
+ 		+ + + + +
+ STF discussion on 30-11-2010: alternative proposal: add a variant tag to templates that suppresses the type identification attribute.
+
+
+
+ + + + + + + + + + +
+ (0010421) +
+ Gyorgy Rethy    +
+ 30-11-2011 09:52    +
+ 		+ + + + +
+ I have too much CRs in the queue. Pls. take over this one.
+
+
+
+
+
+ + + + + + + + + + +
+ (0010436) +
+ Jacob Wieland - Spirent    +
+ 30-11-2011 11:12    +
+ 		+ + + + +
+ uploaded proposal, please review
+
+
+
+ + + + + + + + + + +
+ (0010467) +
+ Gyorgy Rethy    +
+ 01-12-2011 11:20    +
+ 		+ + + + +
+ To be added to master copy.
+
+
+
+ + + + + + + + + + +
+ (0010470) +
+ Gyorgy Rethy    +
+ 01-12-2011 11:39    +
+ 		+ + + + +
+ Implemented in master copy.
+
+ + diff --git a/docs/mantis/CR5783.md b/docs/mantis/CR5783.md new file mode 100644 index 0000000000000000000000000000000000000000..57a4350d8632988a7087779862ee103b54caabea --- /dev/null +++ b/docs/mantis/CR5783.md @@ -0,0 +1,344 @@ + + + + + + + + + + + + + 0005783: TTCN-3 Signature templates - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005783Part 01: TTCN-3 Core LanguageClarificationpublic06-10-2010 15:2814-12-2010 12:09
ReporterAndrus Lehtmets 
Assigned ToIna Schieferdecker 
PrioritynormalSeveritymajorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.3.1 (published 2011-06)Fixed in Versionv4.3.1 (published 2011-06) 
Clause Reference(s)Part 1: TTCN-3 Core Language
Source (company - Author)Elvior
Summary0005783: TTCN-3 Signature templates
DescriptionWe need clarification about using matching templates with signatures - looks like formal rules for that are missing.
+
+So my question is are following constructions allowed or not?
+[]myport.getcall(myFunction_Sign : ?)
+[]myport.getreply(myFunction:?)
+
+by the examples in CL I would say that corrects are:
+[]myport.getcall(myFunction_Sign :{?, ?, ?})
+[]myport.getreply(myFunction_Sign:{?,?,?} value ?)
+
+but from the other hand - there is no formal rule in CL how matching templates for signature should be built
+
+Shouldn't specification contain a clause that only compound expression is allowed as signature template?
+If '?' is allowed then there should be explicit rules on how to handle it.
+
+Please see also attached mail conversation.
+
+
Steps To Reproduce
Additional InformationWe propose following changes in CL spec:
+1)Chapter 15.2
+The sentence "A signature template defines the values and matching mechanisms of the procedure parameters only, but not the return value." should be replaced with: "A signature template defines values of procedure parameters or a matching mechanism used for matching procedure parameter values. It does not define the return value or matching mechanism for the return value."
+2)New chapter 15.6.4 Referencing signature parameters
+While signature templates do not allow referencing their parameters directly (e.g. using dot notation), such a reference is possible when modifying a signature template. However, there can be a matching mechanism assigned to the signature template. This clause provides rules for such cases.
+a) Value lists and complemented lists: referencing a parameter of a signature template to which a value list or a complemented list is assigned, at the left hand side of an assignment, shall cause an error.
+Example:
+signature MySignature(in integer par1, in integer par2);
+template MySignature t_mySign1 := ({ par1 := 1, par2 := 2 }, { par1 := 2, par2 := 1 });
+template MySignature t_mySign2 modifies t_mySign1 := { par1 := ? }; // shall cause an error as t_mySign1 contains a value list template
+
+b) AnyValue: when referencing a parameter within a signature to which AnyValue is assigned, at the left hand side of an assignment, the signature template is implicitly expanded to the parameter level. During this expansion an AnyValue shall be assigned to all parameters of the template. After this expansion the value or matching mechanism at the right hand side of the assignment shall be assigned to the referenced parameter.
+Example:
+template MySignature t_mySign3 := ?;
+template MySignature t_mySign4 modifies t_mySign3 := { par1 := 3 };
+// t_mySign3 is expanded to { par1 := ?, par2 := ? }
+// thus t_mySign4 will be { par1 := 3, par2 := ? }
+3)Chapter 15.7
+A new line should be added to the table 11:
+Type: Signature
+Allowed matching symbols: ?, list, complement
+
+
TagsNo tags attached.
Relationships
Attached Fileshtm TTCN-3 Signature templates.htm (22,585) 06-10-2010 15:28
http://oldforge.etsi.org/mantis/file_download.php?file_id=2443&type=bug
doc CR5783.doc (108,544) 01-12-2010 10:21
http://oldforge.etsi.org/mantis/file_download.php?file_id=2452&type=bug
doc CR5783 resolution-Gyorgy-101201.doc (122,368) 01-12-2010 13:14
http://oldforge.etsi.org/mantis/file_download.php?file_id=2453&type=bug
Issue History
Date ModifiedUsernameFieldChange
06-10-2010 15:28Andrus LehtmetsNew Issue
06-10-2010 15:28Andrus LehtmetsFile Added: TTCN-3 Signature templates.htm
06-10-2010 15:28Andrus LehtmetsClause Reference(s) => Part 1: TTCN-3 Core Language
06-10-2010 15:28Andrus LehtmetsSource (company - Author) => Elvior
30-11-2010 15:39Ina SchieferdeckerProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
30-11-2010 15:53Gyorgy RethyNote Added: 0009855
30-11-2010 15:53Gyorgy RethyAssigned To => Jacob Wieland - Spirent
30-11-2010 15:53Gyorgy RethyStatusnew => assigned
30-11-2010 15:53Gyorgy RethyTarget Version => Edition 4.3.1 (not yet published)
01-12-2010 10:15Jacob Wieland - SpirentFile Added: CR5783.doc
01-12-2010 10:19Jacob Wieland - SpirentNote Added: 0009879
01-12-2010 10:20Jacob Wieland - SpirentFile Deleted: CR5783.doc
01-12-2010 10:21Jacob Wieland - SpirentFile Added: CR5783.doc
01-12-2010 10:24Jacob Wieland - SpirentNote Added: 0009882
01-12-2010 10:24Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Jens Grabowski
01-12-2010 11:25Jens GrabowskiNote Added: 0009890
01-12-2010 11:25Jens GrabowskiAssigned ToJens Grabowski => Gyorgy Rethy
01-12-2010 12:10Andrus LehtmetsNote Added: 0009892
01-12-2010 13:14Gyorgy RethyFile Added: CR5783 resolution-Gyorgy-101201.doc
01-12-2010 13:17Gyorgy RethyNote Added: 0009893
01-12-2010 13:18Gyorgy RethyNote Edited: 0009893
01-12-2010 13:18Gyorgy RethyAssigned ToGyorgy Rethy => Jens Grabowski
01-12-2010 13:18Gyorgy RethyResolutionopen => fixed
01-12-2010 13:20Jens GrabowskiNote Added: 0009894
01-12-2010 13:20Jens GrabowskiAssigned ToJens Grabowski => Ina Schieferdecker
01-12-2010 13:20Jens GrabowskiStatusassigned => resolved
14-12-2010 12:08Ina SchieferdeckerNote Added: 0009961
14-12-2010 12:09Ina SchieferdeckerStatusresolved => closed
14-12-2010 12:09Ina SchieferdeckerFixed in Version => Edition 4.3.1 (not yet published)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009855) +
+ Gyorgy Rethy    +
+ 30-11-2010 15:53    +
+ 		+ + + + +
+ STF discussion on 30-11-2010: Add a sentence and examples for the shorthand "any signature" case.
+
+
+
+ + + + + + + + + + +
+ (0009879) +
+ Jacob Wieland - Spirent    +
+ 01-12-2010 10:19    +
+ 		+ + + + +
+ I have uploaded the proposal. I've taken most of the proposed text, but not the first sentence as I think it would change the current semantics (while I think the sentence up till now reflects the current semantics more accurately).
+
+I've also added a few more examples.
+
+
+
+ + + + + + + + + + +
+ (0009882) +
+ Jacob Wieland - Spirent    +
+ 01-12-2010 10:24    +
+ 		+ + + + +
+ please proofread
+
+
+
+ + + + + + + + + + +
+ (0009890) +
+ Jens Grabowski    +
+ 01-12-2010 11:25    +
+ 		+ + + + +
+ For me it looks ok. However, György, please have a look into clause 15.6.4 of the resolution.
+
+
+
+ + + + + + + + + + +
+ (0009892) +
+ Andrus Lehtmets    +
+ 01-12-2010 12:10    +
+ 		+ + + + +
+ For Elvior it looks also ok.
+
+
+
+ + + + + + + + + + +
+ (0009893) +
+ Gyorgy Rethy    +
+ 01-12-2010 13:17    +
(edited on: 01-12-2010 13:18)
+ 		+ + + + +
+ Cross-checked, it is OK. Just one minor correction in CR5783 resolution-Gyorgy-101201.doc: in Example 4, the first getreply op. it seems Template2 was meant instead of Template1. This is changed plus some very minor editorials (changing formatting). Jens pls. cross-check, if Ok, can be set to resolved.
+
+
+
+
+
+ + + + + + + + + + +
+ (0009894) +
+ Jens Grabowski    +
+ 01-12-2010 13:20    +
+ 		+ + + + +
+ OK, resolved, assigned to Ina for implementation
+
+
+
+ + + + + + + + + + +
+ (0009961) +
+ Ina Schieferdecker    +
+ 14-12-2010 12:08    +
+ 		+ + + + +
+ Implemented as proposed.
+
+ + diff --git a/docs/mantis/CR5784.md b/docs/mantis/CR5784.md new file mode 100644 index 0000000000000000000000000000000000000000..10a1c4ab85befd07772dc0f44c3386e97da937da --- /dev/null +++ b/docs/mantis/CR5784.md @@ -0,0 +1,78 @@ + + + + + + + + + + + + + 0005784: STF409 question on [Part 1: TTCN-3 Core Language / Section 5.4.1.2 / restriction f) ] - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005784Part 01: TTCN-3 Core LanguageClarificationpublic08-10-2010 09:4530-11-2010 10:07
ReporterAndras Kovacs 
Assigned To 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionno change required 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Clause Reference(s)[Part 1: TTCN-3 Core Language / Section 5.4.1.2 / restriction f) ]
Source (company - Author)BroadBit - Andras Kovacs
Summary0005784: STF409 question on [Part 1: TTCN-3 Core Language / Section 5.4.1.2 / restriction f) ]
DescriptionSection 5.4.1.2 / restriction f) :
+"Default templates of default type formal parameters shall be the specific value null."
+This quoted restriction is not understandable to STF409 experts.
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
08-10-2010 09:45Andras KovacsNew Issue
08-10-2010 09:45Andras KovacsClause Reference(s) => [Part 1: TTCN-3 Core Language / Section 5.4.1.2 / restriction f) ]
08-10-2010 09:45Andras KovacsSource (company - Author) => BroadBit - Andras Kovacs
30-11-2010 09:41Ina SchieferdeckerProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
30-11-2010 10:04Jacob Wieland - SpirentNote Added: 0009836
30-11-2010 10:07Ina SchieferdeckerStatusnew => closed
30-11-2010 10:07Ina SchieferdeckerResolutionopen => no change required
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009836) +
+ Jacob Wieland - Spirent    +
+ 30-11-2010 10:04    +
+ 		+ + + + +
+ First of all, you seem to reference an old version of the standard. In 4.2.1. there are no templates of type 'default' allowed anymore and restriction f) in that section is no longer containing that sentence.
+
+However, I'll try to explain the confusing parts (as they also apply to the same restriction for formal value parameters of type default).
+
+Probably the confusion arises from the double meaning of the word 'default' in that sentence.
+
+The first 'default' references the concept of 'default value/template' for a formal parameter declaration. The second 'default' references the 'default' type used for handles on activated default-altsteps (for deactivation purposes).
+
+Since there can be no global constants of type 'default' because activate() can only be called inside a behavior, the only globally known constant of type 'default' is 'null' (which can be used as a dummy initialization for variables of type 'default'). That's why it is only possible to reference that constant in a default template for a formal template parameter.
+
+Maybe the solution would be to print the 'default' of the 'type default' in bold to distinguish them.
+
+Anyhow, I think this can be considered closed.
+
+ + diff --git a/docs/mantis/CR5785.md b/docs/mantis/CR5785.md new file mode 100644 index 0000000000000000000000000000000000000000..7921d7ad2a045f0b9877ca8a32af52ce84bcda18 --- /dev/null +++ b/docs/mantis/CR5785.md @@ -0,0 +1,464 @@ + + + + + + + + + + + + + 0005785: STF409 question on [Part 1: TTCN-3 Core Language / Section 6.3.2 ] - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005785Part 01: TTCN-3 Core LanguageClarificationpublic08-10-2010 09:4801-07-2011 17:52
ReporterAndras Kovacs 
Assigned ToIna Schieferdecker 
PriorityhighSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.3.2 (interim 2011)Fixed in Versionv4.3.2 (interim 2011) 
Clause Reference(s)[Part 1: TTCN-3 Core Language / Section 6.3.2 ]
Source (company - Author)BroadBit - Andras Kovacs
Summary0005785: STF409 question on [Part 1: TTCN-3 Core Language / Section 6.3.2 ]
DescriptionIs the assignment between record and set types possible if their structures are compatible?
+The standard contains neither a positive or a negative statement on this issue. STF409 experts assumed the answer to above question to be yes.
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR5785.docx (31,957) 25-05-2011 14:30
http://oldforge.etsi.org/mantis/file_download.php?file_id=2484&type=bug
docx CR5785_resolution_v2.docx (29,935) 25-05-2011 15:32
http://oldforge.etsi.org/mantis/file_download.php?file_id=2488&type=bug
Issue History
Date ModifiedUsernameFieldChange
08-10-2010 09:48Andras KovacsNew Issue
08-10-2010 09:48Andras KovacsClause Reference(s) => [Part 1: TTCN-3 Core Language / Section 6.3.2 ]
08-10-2010 09:48Andras KovacsSource (company - Author) => BroadBit - Andras Kovacs
14-10-2010 12:51Jacob Wieland - SpirentNote Added: 0009785
30-11-2010 09:41Ina SchieferdeckerProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
30-11-2010 16:12Gyorgy RethyNote Added: 0009858
30-11-2010 16:13Gyorgy RethyStatusnew => closed
30-11-2010 16:13Gyorgy RethyResolutionopen => no change required
01-12-2010 10:55Benjamin ZeissStatusclosed => feedback
01-12-2010 10:55Benjamin ZeissResolutionno change required => reopened
01-12-2010 10:55Benjamin ZeissNote Added: 0009885
01-12-2010 14:57David Diaz (MTP)Note Added: 0009898
02-12-2010 12:20Jacob Wieland - SpirentNote Added: 0009928
02-12-2010 12:54Gyorgy RethyNote Added: 0009929
02-12-2010 12:56Gyorgy RethyNote Edited: 0009929
02-12-2010 16:06David Diaz (MTP)Note Added: 0009934
13-12-2010 12:42Gyorgy RethyTarget Version => Edition 4.4.1
13-12-2010 12:42Gyorgy RethyTarget VersionEdition 4.4.1 => Edition 4.3.2 (interim)
24-05-2011 16:15Gyorgy RethyNote Added: 0010034
24-05-2011 16:15Gyorgy RethyStatusfeedback => assigned
24-05-2011 16:15Gyorgy RethyAssigned To => Ina Schieferdecker
24-05-2011 19:31Gyorgy RethyPrioritynormal => high
25-05-2011 14:30Ina SchieferdeckerFile Added: CR5785.docx
25-05-2011 14:32Ina SchieferdeckerNote Added: 0010054
25-05-2011 14:33Ina SchieferdeckerAssigned ToIna Schieferdecker => Gyorgy Rethy
25-05-2011 15:32Gyorgy RethyFile Added: CR5785_resolution_v2.docx
25-05-2011 15:35Gyorgy RethyNote Added: 0010057
25-05-2011 15:35Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
30-06-2011 18:44Ina SchieferdeckerNote Added: 0010170
30-06-2011 18:45Ina SchieferdeckerStatusassigned => resolved
30-06-2011 18:45Ina SchieferdeckerFixed in Version => Edition 4.3.2 (interim)
30-06-2011 18:45Ina SchieferdeckerResolutionreopened => fixed
01-07-2011 17:52Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009785) +
+ Jacob Wieland - Spirent    +
+ 14-10-2010 12:51    +
+ 		+ + + + +
+ The main sentence of section 6.3.2 states clearly:
+
+In the case of structured types (except the enumerated type) a value "b" of type "B" is compatible with type "A", if the effective value structures of type "B" and type "A" are compatible, in which case assignments, instantiations and comparisons are allowed.
+
+Since the effective value structures of set and record types with the same field definitions are compatible if the field names are the same (because the field names are determinate for set types) and for every field the type of the field is compatible with the type of the field with the same name in the other type, then according to the above sentence, the set and record type are compatible.
+
+If that is not the intended meaning, the standard should be amended with a sentence like 'Only those structured types are compatible which are described in the following sub-sections'.
+
+
+
+ + + + + + + + + + +
+ (0009858) +
+ Gyorgy Rethy    +
+ 30-11-2010 16:12    +
+ 		+ + + + +
+ STF discussion on 30-11-2010: according to the analysis above STF409 experts are correct.No need to change the standard.
+
+
+
+ + + + + + + + + + +
+ (0009885) +
+ Benjamin Zeiss    +
+ 01-12-2010 10:55    +
+ 		+ + + + +
+ This is feedback from Elvior regarding this issue and the proposal made:
+
+Standard is ambiguous, clause 6.3.2.3 must clearly state either:
+a)set of types are only type compatible with other set types and set of types
+or
+b)set of is types are type compatible with other set types, set of types, record types, record of types and array types
+ 
+We do not like alternative b), since set is also compatible with set and set of only.
+ 
+We propose to change 6.3.2.3 so that the first sentence of 6.3.2.3 starts: "set and set of types are..."
+Until this ambiguity is not removed from standard, we object respective test cases in STF 409.
+
+
+
+ + + + + + + + + + +
+ (0009898) +
+ David Diaz (MTP)    +
+ 01-12-2010 14:57    +
+ 		+ + + + +
+ Dear all,
+
+
+Related with the CR question: “Is the assignment between record and set types possible if their structures are compatible? “, from our point of view, the standard is clear enough:
+
+
+ETSI ES 201 873-1 V4.2.1 (2010-07) – 6.3.2.3
+
+“set types are only type compatible with other set types and set of types”
+
+
+So set type is not compatible with record type. We understand this 6.2.3 paragraph:
+
+
+In the case of structured types (except the enumerated type) a value "b" of type "B" is compatible with type "A", if
+
+the effective value structures of type "B" and type "A" are compatible, in which case assignments, instantiations and
+
+comparisons are allowed.
+
+
+is a general rule overrided by 6.3.2.3 section.
+
+
+From our point of view any STF409 ATS test case where assignments between record and set types are being performed must resolve to a semantic error. If this is not the case, and different opinions on this issue are being considered, we think this set of test cases should be removed from the ATS as a preventative measure until no agreement is reached.
+
+
+Best regards,
+David (MTP)
+
+
+
+ + + + + + + + + + +
+ (0009928) +
+ Jacob Wieland - Spirent    +
+ 02-12-2010 12:20    +
+ 		+ + + + +
+ So, the standard is inconsistent as there are no 'overriding' rules from one statement to another. So, either the other exceptions to the general rule (for records and sets) should also be mentioned (like already for enumerated types) in the general section or the restrictions should be removed in the more specific sections to make the standard consistent.
+
+
+
+ + + + + + + + + + +
+ (0009929) +
+ Gyorgy Rethy    +
+ 02-12-2010 12:54    +
(edited on: 02-12-2010 12:56)
+ 		+ + + + +
+ I think that the general sentence in 6.3.2 should be removed and the "compatible effective value structure" be defined in clause 3.1 as a definition. As of today, seems that this general sentence is a potential source of misunderstandings/misinterpretation.
+
+The following subclauses of 6.3.2 are defining clearly what may be compatible with what: enumerated with nothing; record, record ofs & arrays may be mutually compatible; sets and set ofs may be compatible with each other (but not with record & record ofs); union with union and anytype with anytype may be compatible. I strongly oppose to interpret any other compatibility relation based on a general sentence, meant to be, in fact, a definition, when in the relevant clauses clear compatibility rules are defined.
+
+
+
+
+
+ + + + + + + + + + +
+ (0009934) +
+ David Diaz (MTP)    +
+ 02-12-2010 16:06    +
+ 		+ + + + +
+ Dear Gyorgy,
+
+We fully agree with your proposal.
+
+Regards,
+David
+
+
+
+ + + + + + + + + + +
+ (0010034) +
+ Gyorgy Rethy    +
+ 24-05-2011 16:15    +
+ 		+ + + + +
+ The "if the effective value structures of type "B" and type "A" are compatible" part can be deleted as it doesn't add to the content of the subsequent clauses.
+
+
+
+ + + + + + + + + + +
+ (0010054) +
+ Ina Schieferdecker    +
+ 25-05-2011 14:32    +
+ 		+ + + + +
+ Proposal to get rid of the case “record of types and single-dimension arrays are compatible with record types” by deprecating it.
+
+In this case, "effective value structure" not needed to define type compatibility as given in the uploaded draft text. Please check.
+
+
+
+ + + + + + + + + + +
+ (0010057) +
+ Gyorgy Rethy    +
+ 25-05-2011 15:35    +
+ 		+ + + + +
+ See CR5785_resolution_v2.docx. No technical change to CR5785.docx but text is changed at several places.
+
+Note: Interestingly, also spaces are lost at several places when opening the .docx file.
+
+
+
+ + + + + + + + + + +
+ (0010170) +
+ Ina Schieferdecker    +
+ 30-06-2011 18:44    +
+ 		+ + + + +
+ Implemented basically as proposed.
+
+Changed also at other places "Type compatibility ..." to "Compatibility ..." where appropriate.
+
+ + diff --git a/docs/mantis/CR5786.md b/docs/mantis/CR5786.md new file mode 100644 index 0000000000000000000000000000000000000000..13868400e7c98d94a66ec2c0ecaf005b420a7f13 --- /dev/null +++ b/docs/mantis/CR5786.md @@ -0,0 +1,208 @@ + + + + + + + + + + + + + 0005786: STF409 question on [Part 1: TTCN-3 Core Language / Section 6.3.4 ] - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005786Part 01: TTCN-3 Core LanguageClarificationpublic08-10-2010 09:5114-12-2010 12:20
ReporterAndras Kovacs 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.3.1 (published 2011-06)Fixed in Versionv4.3.1 (published 2011-06) 
Clause Reference(s)[Part 1: TTCN-3 Core Language / Section 6.3.4 ]
Source (company - Author)BroadBit - Andras Kovacs
Summary0005786: STF409 question on [Part 1: TTCN-3 Core Language / Section 6.3.4 ]
DescriptionThe content of section 6.3.4 is not clear. Specific issues:
+- The given example is incomplete, because the port definitions are missing.
+- It is not clear what happens when a communications port is defined to process the messages of a given record type as well as its type synonym.
+ 
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR5786.doc (29,696) 01-12-2010 09:07
http://oldforge.etsi.org/mantis/file_download.php?file_id=2445&type=bug
Issue History
Date ModifiedUsernameFieldChange
08-10-2010 09:51Andras KovacsNew Issue
08-10-2010 09:51Andras KovacsClause Reference(s) => [Part 1: TTCN-3 Core Language / Section 6.3.4 ]
08-10-2010 09:51Andras KovacsSource (company - Author) => BroadBit - Andras Kovacs
14-10-2010 11:09Jacob Wieland - SpirentNote Added: 0009781
30-11-2010 09:40Ina SchieferdeckerProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
30-11-2010 16:15Gyorgy RethyNote Added: 0009859
30-11-2010 16:15Gyorgy RethyNote Edited: 0009859
30-11-2010 16:16Gyorgy RethyAssigned To => Jacob Wieland - Spirent
30-11-2010 16:16Gyorgy RethyStatusnew => assigned
30-11-2010 16:16Gyorgy RethyTarget Version => Edition 4.3.1 (not yet published)
01-12-2010 09:07Jacob Wieland - SpirentFile Added: CR5786.doc
01-12-2010 09:08Jacob Wieland - SpirentNote Added: 0009871
01-12-2010 09:08Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Jens Grabowski
01-12-2010 09:50Jens GrabowskiNote Added: 0009876
01-12-2010 09:51Jens GrabowskiAssigned ToJens Grabowski => Ina Schieferdecker
01-12-2010 09:51Jens GrabowskiStatusassigned => resolved
14-12-2010 12:19Ina SchieferdeckerNote Added: 0009962
14-12-2010 12:19Ina SchieferdeckerResolutionopen => fixed
14-12-2010 12:19Ina SchieferdeckerFixed in Version => Edition 4.3.1 (not yet published)
14-12-2010 12:20Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009781) +
+ Jacob Wieland - Spirent    +
+ 14-10-2010 11:09    +
+ 		+ + + + +
+ In the example, it is stated (albeit in a comment) that the port can process (i.e. send/receive) both types (contrary to your stated point 2). Since the ports are connected (not mapped, where the situation is a bit more difficult because of encoding/decoding), the sent type must be exactly the same as the type of the template to be received (not just compatible) so that matching occurs on the receive statement. This is what the whole section is about. So, the example is in essence complete.
+
+However, the example is still wrong in two respects (in my opinion):
+- P2.receive(MyRec:?) shall not cause an error, but simply a mismatch (there could be other or default alternatives that receive MyRecAlias)
+- P2.receive(MyRec:?) -> value x shall also not cause an error, as - again - this is simply a mismatch and thus no assignment shall take place. And even if an assignment would take place, assigning of a value of one type to a variable of a different type is well defined using the weaker type compatibility rules (but since there will be no matching here, this point is moot - however, in a mapped port, this could be valid).
+
+
+
+ + + + + + + + + + +
+ (0009859) +
+ Gyorgy Rethy    +
+ 30-11-2010 16:15    +
+ 		+ + + + +
+ STF discussion on 30-11-2010: add the port type definition to the example. Also fix Jacob's findings.
+
+
+
+
+
+ + + + + + + + + + +
+ (0009871) +
+ Jacob Wieland - Spirent    +
+ 01-12-2010 09:08    +
+ 		+ + + + +
+ please proofread
+
+
+
+ + + + + + + + + + +
+ (0009876) +
+ Jens Grabowski    +
+ 01-12-2010 09:50    +
+ 		+ + + + +
+ Ok, status is set to resolved and CR is assigned to Ina.
+
+
+
+ + + + + + + + + + +
+ (0009962) +
+ Ina Schieferdecker    +
+ 14-12-2010 12:19    +
+ 		+ + + + +
+ Implemented as proposed
+
+ + diff --git a/docs/mantis/CR5787.md b/docs/mantis/CR5787.md new file mode 100644 index 0000000000000000000000000000000000000000..e7dcb3b9138287acbccbab6c2fee5f577abd5772 --- /dev/null +++ b/docs/mantis/CR5787.md @@ -0,0 +1,66 @@ + + + + + + + + + + + + + 0005787: STF409 comment on [Part 1: TTCN-3 Core Language /Annex B.1.1 ] - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005787Part 01: TTCN-3 Core LanguageTechnicalpublic08-10-2010 12:5430-11-2010 09:40
ReporterAndras Kovacs 
Assigned To 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionno change required 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Clause Reference(s)[Part 1: TTCN-3 Core Language /Annex B.1.1 ]
Source (company - Author)BroadBit - Andras Kovacs
Summary0005787: STF409 comment on [Part 1: TTCN-3 Core Language /Annex B.1.1 ]
DescriptionThe provided example has syntactically incorrect field definition inside a record type:
+" integer[4] field4 "
+The correct statement would be:
+" integer field4[4] "
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
08-10-2010 12:54Andras KovacsNew Issue
08-10-2010 12:54Andras KovacsClause Reference(s) => [Part 1: TTCN-3 Core Language /Annex B.1.1 ]
08-10-2010 12:54Andras KovacsSource (company - Author) => BroadBit - Andras Kovacs
24-11-2010 16:07Gyorgy RethyNote Added: 0009803
29-11-2010 16:15Ina SchieferdeckerStatusnew => closed
29-11-2010 16:15Ina SchieferdeckerResolutionopen => no change required
30-11-2010 09:40Ina SchieferdeckerProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009803) +
+ Gyorgy Rethy    +
+ 24-11-2010 16:07    +
+ 		+ + + + +
+ Has already been corrected in or before version v4.2.1 (I have checked this one version only).
+
+ + diff --git a/docs/mantis/CR5788.md b/docs/mantis/CR5788.md new file mode 100644 index 0000000000000000000000000000000000000000..34c4dff20362740b5d53a10fdacf42f471096007 --- /dev/null +++ b/docs/mantis/CR5788.md @@ -0,0 +1,153 @@ + + + + + + + + + + + + + 0005788: STF409 question on [Part 1: TTCN-3 Core Language / Section 6.2 ] - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005788Part 01: TTCN-3 Core LanguageClarificationpublic08-10-2010 14:0130-11-2010 09:40
ReporterAndras Kovacs 
Assigned To 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionno change required 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Clause Reference(s)[Part 1: TTCN-3 Core Language / Section 6.2 ]
Source (company - Author)BroadBit - Andras Kovacs
Summary0005788: STF409 question on [Part 1: TTCN-3 Core Language / Section 6.2 ]
DescriptionNo type definition existing on page 39. It is impossible to validate the templates from examples without a type definition for each example.
+
+Example 2:
+ - is field2 optional ?
+var MyRecordType MyVariable:= {'11001'B, -, "A string"}
+
+Example 4:
+ - is field3 optional ?
+var MyRecordType MyVariable := {
+    field1 := '111'B,
+    field2 := false,
+    field3 := -
+}
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
08-10-2010 14:01Andras KovacsNew Issue
08-10-2010 14:01Andras KovacsClause Reference(s) => [Part 1: TTCN-3 Core Language / Section 6.2 ]
08-10-2010 14:01Andras KovacsSource (company - Author) => BroadBit - Andras Kovacs
14-10-2010 10:56Jacob Wieland - SpirentNote Added: 0009780
14-10-2010 11:52Benjamin ZeissNote Added: 0009783
14-10-2010 11:53Benjamin ZeissStatusnew => closed
14-10-2010 11:53Benjamin ZeissNote Added: 0009784
14-10-2010 11:53Benjamin ZeissResolutionopen => no change required
30-11-2010 09:40Ina SchieferdeckerProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009780) +
+ Jacob Wieland - Spirent    +
+ 14-10-2010 10:56    +
+ 		+ + + + +
+ I think from the examples it is clear that a valid MyRecordType would be
+
+type record MyRecordType {
+  bitstring field1,
+  boolean field2,
+  charstring field3
+}
+
+whether the fields are optional or not is irrelevant for the examples
+as they only use the 'unchanged' symbol which in variable declarations or assignments can also be used for mandatory fields to leave them unspecified (partial variable initialization).
+
+
+
+ + + + + + + + + + +
+ (0009783) +
+ Benjamin Zeiss    +
+ 14-10-2010 11:52    +
+ 		+ + + + +
+ We agree, I guess this can be closed then.
+
+
+
+ + + + + + + + + + +
+ (0009784) +
+ Benjamin Zeiss    +
+ 14-10-2010 11:53    +
+ 		+ + + + +
+ no change required.
+
+ + diff --git a/docs/mantis/CR5789.md b/docs/mantis/CR5789.md new file mode 100644 index 0000000000000000000000000000000000000000..fe0cae41a1f5964f811357a7e1b6c0c9018815ed --- /dev/null +++ b/docs/mantis/CR5789.md @@ -0,0 +1,146 @@ + + + + + + + + + + + + + 0005789: STF409 question on [Part 1: TTCN-3 Core Language / Section 8.2.3.6 ] - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005789Part 01: TTCN-3 Core LanguageClarificationpublic08-10-2010 14:0214-12-2010 11:47
ReporterAndras Kovacs 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.3.1 (published 2011-06)Fixed in Versionv4.3.1 (published 2011-06) 
Clause Reference(s)[Part 1: TTCN-3 Core Language / Section 8.2.3.6 ]
Source (company - Author)BroadBit - Andras Kovacs
Summary0005789: STF409 question on [Part 1: TTCN-3 Core Language / Section 8.2.3.6 ]
DescriptionIn the second example, the languespec is written after "{ import all }". This does
+neither correspond to the text nor the EBNF.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
08-10-2010 14:02Andras KovacsNew Issue
08-10-2010 14:02Andras KovacsClause Reference(s) => [Part 1: TTCN-3 Core Language / Section 8.2.3.6 ]
08-10-2010 14:02Andras KovacsSource (company - Author) => BroadBit - Andras Kovacs
30-11-2010 09:43Ina SchieferdeckerProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
30-11-2010 16:16Gyorgy RethyNote Added: 0009860
30-11-2010 16:17Gyorgy RethyAssigned To => Ina Schieferdecker
30-11-2010 16:17Gyorgy RethyStatusnew => assigned
30-11-2010 16:17Gyorgy RethyTarget Version => Edition 4.3.1 (not yet published)
02-12-2010 09:25Ina SchieferdeckerNote Added: 0009916
02-12-2010 09:26Ina SchieferdeckerAssigned ToIna Schieferdecker => Gyorgy Rethy
02-12-2010 09:26Ina SchieferdeckerResolutionopen => fixed
02-12-2010 09:26Ina SchieferdeckerFixed in Version => Edition 4.3.1 (not yet published)
02-12-2010 10:27Gyorgy RethyNote Added: 0009922
02-12-2010 10:28Gyorgy RethyNote Edited: 0009922
02-12-2010 10:29Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
02-12-2010 10:29Gyorgy RethyStatusassigned => resolved
14-12-2010 11:47Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009860) +
+ Gyorgy Rethy    +
+ 30-11-2010 16:16    +
+ 		+ + + + +
+ STF discussion on 30-11-2010: fix the example
+
+
+
+ + + + + + + + + + +
+ (0009916) +
+ Ina Schieferdecker    +
+ 02-12-2010 09:25    +
+ 		+ + + + +
+ Correct from
+
+      import from MyNewModule { import all } language "TTCN 3:2003";
+
+to
+
+      import from MyNewModule language "TTCN 3:2003" { import all };
+
+Please check
+
+
+
+ + + + + + + + + + +
+ (0009922) +
+ Gyorgy Rethy    +
+ 02-12-2010 10:27    +
(edited on: 02-12-2010 10:28)
+ 		+ + + + +
+ Add the dash to the language id and probably we could "modernize" the example:
+
+import from MyNewModule language "TTCN-3:2010" { import all };
+
+With this additions is OK.
+
+
+
+ + diff --git a/docs/mantis/CR5790.md b/docs/mantis/CR5790.md new file mode 100644 index 0000000000000000000000000000000000000000..01c2f2deb877970766f4d34cfc4f9f896f26b6a6 --- /dev/null +++ b/docs/mantis/CR5790.md @@ -0,0 +1,210 @@ + + + + + + + + + + + + + 0005790: STF409 question on [Part 1: TTCN-3 Core Language / Section 15.5 / Restriction 3) ] - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005790Part 01: TTCN-3 Core LanguageClarificationpublic08-10-2010 14:0402-12-2010 09:13
ReporterAndras Kovacs 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.3.1 (published 2011-06)Fixed in Versionv4.3.1 (published 2011-06) 
Clause Reference(s)[Part 1: TTCN-3 Core Language / Section 15.5 / Restriction 3) ]
Source (company - Author)BroadBit - Andras Kovacs
Summary0005790: STF409 question on [Part 1: TTCN-3 Core Language / Section 15.5 / Restriction 3) ]
Descriptionshould it say "parameter name" instead of "template name"?
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
08-10-2010 14:04Andras KovacsNew Issue
08-10-2010 14:04Andras KovacsClause Reference(s) => [Part 1: TTCN-3 Core Language / Section 15.5 / Restriction 3) ]
08-10-2010 14:04Andras KovacsSource (company - Author) => BroadBit - Andras Kovacs
14-10-2010 10:48Jacob Wieland - SpirentNote Added: 0009779
14-10-2010 11:43Benjamin ZeissNote Added: 0009782
24-11-2010 15:47Gyorgy RethyNote Added: 0009801
30-11-2010 09:40Ina SchieferdeckerProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
30-11-2010 16:20Gyorgy RethyNote Added: 0009861
30-11-2010 16:20Gyorgy RethyAssigned To => Ina Schieferdecker
30-11-2010 16:20Gyorgy RethyStatusnew => assigned
30-11-2010 16:20Gyorgy RethyTarget Version => Edition 4.3.1 (not yet published)
02-12-2010 09:12Ina SchieferdeckerNote Added: 0009914
02-12-2010 09:12Ina SchieferdeckerStatusassigned => resolved
02-12-2010 09:12Ina SchieferdeckerResolutionopen => fixed
02-12-2010 09:12Ina SchieferdeckerFixed in Version => Edition 4.3.1 (not yet published)
02-12-2010 09:13Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009779) +
+ Jacob Wieland - Spirent    +
+ 14-10-2010 10:48    +
+ 		+ + + + +
+ No, what is meant here is the following:
+
+if you have a template t1 with a formal parameter list
+and you derive a template t2 via modifies t1,
+then t2 needs a formal parameter list, as well which shall appear in the definition of t2 directly behind the template name t2
+
+
+
+ + + + + + + + + + +
+ (0009782) +
+ Benjamin Zeiss    +
+ 14-10-2010 11:43    +
+ 		+ + + + +
+ I find this extremely confusing as the BNF does not allow a formal parameter list anywhere else anyway. I don't think this comment is necessary.
+
+
+
+ + + + + + + + + + +
+ (0009801) +
+ Gyorgy Rethy    +
+ 24-11-2010 15:47    +
+ 		+ + + + +
+ The restriction is (it is about extending parameterized base templates): "3) the formal parameter list shall follow the template name for every modified template;"
+
+"parameter name" makes no sense to me. According to the syntactical structure:
+
+template [restriction] Type TemplateIdentifier ["(" TemplateFormalParList ")"]
+modifies TemplateRef ":=" TemplateBody
+
+Restriction 3) says, that all formal parameters, inherited from the base template and added by the modified template (i.e. TemplateFormalParList), shall follow TemplateIdentifier (and not e.g. the name of the base template).
+
+
+
+ + + + + + + + + + +
+ (0009861) +
+ Gyorgy Rethy    +
+ 30-11-2010 16:20    +
+ 		+ + + + +
+ STF discussion 30-11-2010: remove restriction 3).
+
+
+
+ + + + + + + + + + +
+ (0009914) +
+ Ina Schieferdecker    +
+ 02-12-2010 09:12    +
+ 		+ + + + +
+ As proposed
+
+ + diff --git a/docs/mantis/CR5791.md b/docs/mantis/CR5791.md new file mode 100644 index 0000000000000000000000000000000000000000..57f74f4b261e9c2b090bfce217cc384263fcd8a7 --- /dev/null +++ b/docs/mantis/CR5791.md @@ -0,0 +1,283 @@ + + + + + + + + + + + + + 0005791: STF409 question on [Part 1: TTCN-3 Core Language / Section B.1.2.3 ] - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005791Part 01: TTCN-3 Core LanguageClarificationpublic08-10-2010 16:2515-12-2010 00:31
ReporterAndras Kovacs 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.3.1 (published 2011-06)Fixed in Versionv4.3.1 (published 2011-06) 
Clause Reference(s)[Part 1: TTCN-3 Core Language / Section B.1.2.3 ]
Source (company - Author)BroadBit - Andras Kovacs
Summary0005791: STF409 question on [Part 1: TTCN-3 Core Language / Section B.1.2.3 ]
DescriptionSTF409 experts do not understand the meaning of the following restriction in the paragraph text:
+'A template field that uses the any value mechanism matches the corresponding incoming field if, and only if, the incoming field evaluates to a single element of the specified type.'
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR5791.doc (42,496) 15-12-2010 00:23
http://oldforge.etsi.org/mantis/file_download.php?file_id=2472&type=bug
Issue History
Date ModifiedUsernameFieldChange
08-10-2010 16:25Andras KovacsNew Issue
08-10-2010 16:25Andras KovacsClause Reference(s) => [Part 1: TTCN-3 Core Language / Section B.1.2.3 ]
08-10-2010 16:25Andras KovacsSource (company - Author) => BroadBit - Andras Kovacs
14-10-2010 10:44Jacob Wieland - SpirentNote Added: 0009778
30-11-2010 09:39Ina SchieferdeckerProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
30-11-2010 16:22Gyorgy RethyAssigned To => Ina Schieferdecker
30-11-2010 16:22Gyorgy RethyStatusnew => assigned
30-11-2010 16:22Gyorgy RethyTarget Version => Edition 4.3.1 (not yet published)
02-12-2010 09:09Ina SchieferdeckerNote Added: 0009913
02-12-2010 09:09Ina SchieferdeckerAssigned ToIna Schieferdecker => Gyorgy Rethy
02-12-2010 09:09Ina SchieferdeckerResolutionopen => fixed
02-12-2010 09:09Ina SchieferdeckerFixed in Version => Edition 4.3.1 (not yet published)
02-12-2010 10:34Gyorgy RethyNote Added: 0009923
02-12-2010 10:34Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
02-12-2010 11:31Ina SchieferdeckerNote Added: 0009926
02-12-2010 11:31Ina SchieferdeckerAssigned ToIna Schieferdecker => Gyorgy Rethy
02-12-2010 11:34Gyorgy RethyNote Added: 0009927
02-12-2010 11:34Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
02-12-2010 11:34Gyorgy RethyStatusassigned => resolved
15-12-2010 00:23Ina SchieferdeckerNote Added: 0009976
15-12-2010 00:23Ina SchieferdeckerFile Added: CR5791.doc
15-12-2010 00:30Ina SchieferdeckerNote Added: 0009977
15-12-2010 00:31Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009778) +
+ Jacob Wieland - Spirent    +
+ 14-10-2010 10:44    +
+ 		+ + + + +
+ maybe 'single element' should be replaced by 'value'
+
+
+
+ + + + + + + + + + +
+ (0009913) +
+ Ina Schieferdecker    +
+ 02-12-2010 09:09    +
+ 		+ + + + +
+ The sentence should read:
+
+"A template field that uses the any value mechanism matches the corresponding incoming field if, and only if, the incoming field evaluates to a value of the specified type."
+
+Please check.
+
+
+
+ + + + + + + + + + +
+ (0009923) +
+ Gyorgy Rethy    +
+ 02-12-2010 10:34    +
+ 		+ + + + +
+ AnyValue can also be assigned to a template, typical for simple-type co-ordination messages, so the sentence should read:
+""A template or template field that uses the any value mechanism matches the corresponding incoming message or field respectively, if, and only if, the corresponding message or incoming field evaluates to a value of the specified type.""
+
+
+
+ + + + + + + + + + +
+ (0009926) +
+ Ina Schieferdecker    +
+ 02-12-2010 11:31    +
+ 		+ + + + +
+ As it is not only about incoming messages/fields, better to change the whole paragraph from:
+
+--------------
+The matching symbol "?" (AnyValue) is used to indicate that any valid incoming value is acceptable. It can be used on values of all types. A template field that uses the any value mechanism matches the corresponding incoming field if, and only if, the incoming field evaluates to a single element of the specified type.
+--------------
+
+to
+--------------
+The matching symbol "?" (AnyValue) matches any value of the specified type. It can be used on values of all types.
+--------------
+
+
+
+ + + + + + + + + + +
+ (0009927) +
+ Gyorgy Rethy    +
+ 02-12-2010 11:34    +
+ 		+ + + + +
+ OK with me.
+
+
+
+ + + + + + + + + + +
+ (0009976) +
+ Ina Schieferdecker    +
+ 15-12-2010 00:23    +
+ 		+ + + + +
+ The observation about "incoming" has implications also in the other subclauses of B.1.2 - however in a straightforward manner - implemented as uploaded in the resolution
+
+
+
+ + + + + + + + + + +
+ (0009977) +
+ Ina Schieferdecker    +
+ 15-12-2010 00:30    +
+ 		+ + + + +
+ Same for B.1.1 and B.1.4
+
+ + diff --git a/docs/mantis/CR5794.md b/docs/mantis/CR5794.md new file mode 100644 index 0000000000000000000000000000000000000000..decea4c2a8975075adccdcc7cbcf30f1efa27c43 --- /dev/null +++ b/docs/mantis/CR5794.md @@ -0,0 +1,73 @@ + + + + + + + + + + + + + 0005794: STF409 comment on [Part 1: TTCN-3 Core Language]: missing definition of OctetString elements - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005794Part 01: TTCN-3 Core LanguageTechnicalpublic13-10-2010 17:5230-11-2010 09:39
ReporterAndras Kovacs 
Assigned To 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionwon't fix 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Clause Reference(s)[Part 1: TTCN-3 Core Language]
Source (company - Author)BroadBit - Andras Kovacs
Summary0005794: STF409 comment on [Part 1: TTCN-3 Core Language]: missing definition of OctetString elements
DescriptionLooking through different parts of the standard, as well as the provided examples, it becomes clear that a single element of an octet string is an octet, i.e. a pair of two hex characters (or half-octets).
+However this is nowhere properly defined; it would be useful to have this definition clearly stated in the 'Types and values' section.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
13-10-2010 17:52Andras KovacsNew Issue
13-10-2010 17:52Andras KovacsClause Reference(s) => [Part 1: TTCN-3 Core Language]
13-10-2010 17:52Andras KovacsSource (company - Author) => BroadBit - Andras Kovacs
24-11-2010 16:02Gyorgy RethyNote Added: 0009802
29-11-2010 16:12Ina SchieferdeckerStatusnew => closed
29-11-2010 16:12Ina SchieferdeckerResolutionopen => won't fix
30-11-2010 09:39Ina SchieferdeckerProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009802) +
+ Gyorgy Rethy    +
+ 24-11-2010 16:02    +
+ 		+ + + + +
+ Clause 6.1.1 c) says:
+"c) octetstring: a type whose distinguished values are the ordered sequences of zero or a positive even number of hexadecimal digits (every pair of digits corresponding to an ordered sequence of eight bits)."
+
+In table 4:
+Table 4: Units of length used in field length specifications
+Type Units of Length
+bitstring bits
+hexstring hexadecimal digits
+octetstring octets
+character strings characters
+
+ + diff --git a/docs/mantis/CR5795.md b/docs/mantis/CR5795.md new file mode 100644 index 0000000000000000000000000000000000000000..b7657760ca07ee8f4a83073b0e1a66bb90a1ba54 --- /dev/null +++ b/docs/mantis/CR5795.md @@ -0,0 +1,180 @@ + + + + + + + + + + + + + 0005795: STF409 question on [Part 1: TTCN-3 Core Language / Section 16.1.4 ] - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005795Part 01: TTCN-3 Core LanguageClarificationpublic13-10-2010 17:5614-12-2010 11:59
ReporterAndras Kovacs 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.3.1 (published 2011-06)Fixed in Versionv4.3.1 (published 2011-06) 
Clause Reference(s)[Part 1: TTCN-3 Core Language / Section 16.1.4 ]
Source (company - Author)BroadBit - Andras Kovacs
Summary0005795: STF409 question on [Part 1: TTCN-3 Core Language / Section 16.1.4 ]
DescriptionThis section defines restrictions on functions for the case when a function is involved for example in the following context:
+"Value returning functions can be called during communication operations (in templates, template fields or in-line templates)"
+
+From the above description it is unclear what the meaning of 'during communication operations' in this context is; it should be properly defined and illustrated with examples.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
13-10-2010 17:56Andras KovacsNew Issue
13-10-2010 17:56Andras KovacsClause Reference(s) => [Part 1: TTCN-3 Core Language / Section 16.1.4 ]
13-10-2010 17:56Andras KovacsSource (company - Author) => BroadBit - Andras Kovacs
30-11-2010 09:39Ina SchieferdeckerProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
30-11-2010 16:27Gyorgy RethyNote Added: 0009862
30-11-2010 16:27Gyorgy RethyAssigned To => Ina Schieferdecker
30-11-2010 16:27Gyorgy RethyStatusnew => assigned
30-11-2010 16:27Gyorgy RethyTarget Version => Edition 4.3.1 (not yet published)
01-12-2010 17:16Ina SchieferdeckerNote Added: 0009910
01-12-2010 17:16Ina SchieferdeckerAssigned ToIna Schieferdecker => Gyorgy Rethy
01-12-2010 17:17Ina SchieferdeckerStatusassigned => resolved
01-12-2010 17:17Ina SchieferdeckerResolutionopen => fixed
01-12-2010 17:17Ina SchieferdeckerFixed in Version => Edition 4.3.1 (not yet published)
02-12-2010 10:18Gyorgy RethyStatusresolved => feedback
02-12-2010 10:18Gyorgy RethyResolutionfixed => reopened
02-12-2010 10:18Gyorgy RethyNote Added: 0009918
02-12-2010 10:19Gyorgy RethyNote Added: 0009919
02-12-2010 10:19Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
02-12-2010 10:19Gyorgy RethyStatusfeedback => resolved
02-12-2010 10:19Gyorgy RethyResolutionreopened => fixed
14-12-2010 11:59Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009862) +
+ Gyorgy Rethy    +
+ 30-11-2010 16:27    +
+ 		+ + + + +
+ STF discussion 30-11-2010: change 2* "during" to "in". Ina to cross-check the wording.
+
+
+
+ + + + + + + + + + +
+ (0009910) +
+ Ina Schieferdecker    +
+ 01-12-2010 17:16    +
+ 		+ + + + +
+ Propose to change from
+
+-------------
+Value returning functions can be called during communication operations (in templates, template fields or in-line templates) or during snapshot evaluation (in Boolean guards of alt statements or altsteps (see clause 20.2) and in initialization of altstep local definitions (see clause 16.2).
+-------------
+
+to
+
+-------------
+Value returning functions can be called in communication operations (in templates, template fields or in-line templates), in guards of alt statements or altsteps (see clause 20.2), and in initializations of altstep local definitions (see clause 16.2).
+-------------
+
+Please check.
+
+
+
+ + + + + + + + + + +
+ (0009918) +
+ Gyorgy Rethy    +
+ 02-12-2010 10:18    +
+ 		+ + + + +
+ Shall reopen to be able to assign to Ina.
+
+
+
+ + + + + + + + + + +
+ (0009919) +
+ Gyorgy Rethy    +
+ 02-12-2010 10:19    +
+ 		+ + + + +
+ OK with me.
+
+ + diff --git a/docs/mantis/CR5797.md b/docs/mantis/CR5797.md new file mode 100644 index 0000000000000000000000000000000000000000..508165a753c9a46af3979b60de52b8d7b34ea86b --- /dev/null +++ b/docs/mantis/CR5797.md @@ -0,0 +1,113 @@ + + + + + + + + + + + + + 0005797: BNF for CharStringMatch is inconsistent with description - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005797Part 01: TTCN-3 Core LanguageEditorialpublic22-10-2010 13:3701-12-2010 17:07
ReporterJacob Wieland - Spirent 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionduplicate 
PlatformOSOS Version
Product Version 
Target Versionv4.3.1 (published 2011-06)Fixed in Version 
Clause Reference(s)B.1.5.2., A.1.6.1.3
Source (company - Author)Testing Technologies - Jacob Wieland
Summary0005797: BNF for CharStringMatch is inconsistent with description
DescriptionThe BNF rule
+
+CharStringMatch ::= PatternKeyword Pattern {"&" (Pattern | ReferencedValue)}
+
+should be changed to
+
+CharStringMatch ::= PatternKeyword (Pattern | ReferencedValue) {"&" (Pattern | ReferencedValue)}
+
+to be consistent with the text in B.1.5.2:
+
+"If a fragment of a pattern contains a single reference only, it is allowed, as a shorthand notation, to reference the definition or the field of the definition directly, i.e. leave out double quotes (" ") and the pair of curly brackets ({ })."
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0005828closed Ina Schieferdecker STF409 comment on [Part 1: TTCN-3 Core Language /Annex B.1.5.2 ]: syntactical ambiguity 
related to 0005805closed Ina Schieferdecker BNF rule for PatternElement is ambiguous, Example is wrong 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
22-10-2010 13:37Jacob Wieland - SpirentNew Issue
22-10-2010 13:37Jacob Wieland - SpirentClause Reference(s) => B.1.5.2., A.1.6.1.3
22-10-2010 13:37Jacob Wieland - SpirentSource (company - Author) => Testing Technologies - Jacob Wieland
29-11-2010 15:51Jacob Wieland - SpirentRelationship addedrelated to 0005828
29-11-2010 15:53Jacob Wieland - SpirentRelationship addedrelated to 0005805
30-11-2010 09:38Ina SchieferdeckerProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
30-11-2010 16:55Gyorgy RethyNote Added: 0009864
30-11-2010 16:55Gyorgy RethyAssigned To => Ina Schieferdecker
30-11-2010 16:55Gyorgy RethyStatusnew => assigned
30-11-2010 16:55Gyorgy RethyTarget Version => Edition 4.3.1 (not yet published)
01-12-2010 17:03Ina SchieferdeckerNote Added: 0009907
01-12-2010 17:06Ina SchieferdeckerNote Edited: 0009907
01-12-2010 17:07Ina SchieferdeckerStatusassigned => closed
01-12-2010 17:07Ina SchieferdeckerResolutionopen => duplicate
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009864) +
+ Gyorgy Rethy    +
+ 30-11-2010 16:55    +
+ 		+ + + + +
+ STF discussion 30-11-2010: comment and proposal are correct.
+
+
+
+ + + + + + + + + + +
+ (0009907) +
+ Ina Schieferdecker    +
+ 01-12-2010 17:03    +
(edited on: 01-12-2010 17:06)
+ 		+ + + + +
+ As proposed - by introducing
+
+PatternParticle: Pattern | ReferencedValue
+
+See 5828
+
+
+
+ + diff --git a/docs/mantis/CR5798.md b/docs/mantis/CR5798.md new file mode 100644 index 0000000000000000000000000000000000000000..e0f703904fa35f0b9ccbb33cbc3d15c6ce68f7dc --- /dev/null +++ b/docs/mantis/CR5798.md @@ -0,0 +1,119 @@ + + + + + + + + + + + + + 0005798: Add the @reference tag - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 10: TTCN-3 documentation tags
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005798Part 10: TTCN-3 documentation tagsNew Featurepublic28-10-2010 09:3901-12-2010 11:27
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.3.1 (published 2011-06)Fixed in Versionv4.3.1 (published 2011-06) 
Source (company - Author)L.M.Ericsson
Summary0005798: Add the @reference tag
DescriptionCR 5327 proposed to add the @reference tag that was not agreed with the argument that the @see tag already included and does the same. However, this argument is not correct, as @see can refer to another TTCN-3 definition only, while @reference would refer to "external" baseline of the given TTCN-3 definition. See the example below:
+//******************************************************************************
+//* @reference ISO 8601 $4.1.2.3
+//* @desc Matches reduced accuracy calendar date representations in basic format
+//* @status passed
+//******************************************************************************
+template charstring t_ISO8601DateCalendarReducedBasicSpecificMonth := pattern "(" &
+  "{nc.year}-{nc.month}" &
+  ")";
+
+Today there is no appropriate way to include the mandatory reference e.g. to a standard close into the documentation (that would appear as "Reference" in the documentation itself).
+
+I believe this will be a problem for STF409 too, when trying to include TTCN-3 standard references in an appropriate way into the TTCN-3 code.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0005327closed Gyorgy Rethy Add a @reference tag 
related to 0005676closed Gyorgy Rethy Extend the @verdict tag to TTCN-3 modules 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
28-10-2010 09:39Gyorgy RethyNew Issue
28-10-2010 09:39Gyorgy RethySource (company - Author) => L.M.Ericsson
28-10-2010 09:45Gyorgy RethyDescription Updated
29-10-2010 11:38Benjamin ZeissNote Added: 0009788
30-11-2010 17:09Gyorgy RethyAssigned To => Gyorgy Rethy
30-11-2010 17:09Gyorgy RethyStatusnew => assigned
30-11-2010 17:09Gyorgy RethyTarget Version => Edition 4.3.1 (not yet published)
01-12-2010 10:40Gyorgy RethyDescription Updated
01-12-2010 10:40Gyorgy RethyRelationship addedrelated to 0005327
01-12-2010 10:52Gyorgy RethyStatusassigned => closed
01-12-2010 10:52Gyorgy RethyResolutionopen => fixed
01-12-2010 10:52Gyorgy RethyFixed in Version => Edition 4.3.1 (not yet published)
01-12-2010 11:19Gyorgy RethyStatusclosed => feedback
01-12-2010 11:19Gyorgy RethyResolutionfixed => reopened
01-12-2010 11:21Gyorgy RethyNote Added: 0009888
01-12-2010 11:21Gyorgy RethyNote Edited: 0009888
01-12-2010 11:22Gyorgy RethyRelationship addedrelated to 0005676
01-12-2010 11:22Gyorgy RethyStatusfeedback => closed
01-12-2010 11:22Gyorgy RethyResolutionreopened => fixed
01-12-2010 11:25Gyorgy RethyStatusclosed => assigned
01-12-2010 11:25Gyorgy RethyResolutionfixed => open
01-12-2010 11:25Gyorgy RethyFixed in VersionEdition 4.3.1 (not yet published) =>
01-12-2010 11:27Gyorgy RethyStatusassigned => closed
01-12-2010 11:27Gyorgy RethyResolutionopen => fixed
01-12-2010 11:27Gyorgy RethyFixed in Version => Edition 4.3.1 (not yet published)
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009788) +
+ Benjamin Zeiss    +
+ 29-10-2010 11:38    +
+ 		+ + + + +
+ Yes, it is true that @see is not the appropriate tag for external references and that it must refer to existing TTCN-3 definnitions. In STF 409, we currently embed the standard reference into the @purpose tag in a machine-readable way. And as you suggest, it would be possible to misuse the @remark tag to refer to some external reference, but a separate @reference tag with the specific use to refer to external documents would probably be much more clear and I would support the addition of it. Separating the @purpose and the external reference would also make our STF409 document comments nicer.
+
+On that note, there are two things that we currently do in STF 409 which is not valid according to part 10:
+ - We use the @verdict tag on the module level (only allowed for test cases, functions, and altsteps)
+ - We use the @purpose tag on the module level (only allowed for test cases)
+
+This is because each module represents a conformance test in STF 409. Either we have to find some valid solution for these document tag uses (e.g. using @remark and @desc instead) or we need to change part 10 to allow these tags on module level.
+
+My suggestion would be to introduce a @reference tag and allow @verdict and @purpose on module level as well. In any case, I volunteer to implement this CR whatever decision we make in the end.
+
+
+
+ + + + + + + + + + +
+ (0009888) +
+ Gyorgy Rethy    +
+ 01-12-2010 11:21    +
+ 		+ + + + +
+ The @verdict and @purpose tags are also allowed for TTCN-3 modules, as agreed by the STF earlier and proposed by Benjamin. See also CR 5676.
+
+
+
+ + diff --git a/docs/mantis/CR5799.md b/docs/mantis/CR5799.md new file mode 100644 index 0000000000000000000000000000000000000000..182e963574417df1e0a6bc3a673e794096984530 --- /dev/null +++ b/docs/mantis/CR5799.md @@ -0,0 +1,204 @@ + + + + + + + + + + + + + 0005799: BNF problem in the advanced parameterization package: ExtendedFieldReference - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Advanced Parametrization (ES 202 784)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005799Ext Pack: Advanced Parametrization (ES 202 784)Technicalpublic29-10-2010 16:4713-12-2010 13:31
ReporterBenjamin Zeiss 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv1.2.1 (published 2011-05)Fixed in Versionv1.2.1 (published 2011-05) 
TS version
Clause Reference(s)6.2.3.2
Source (company - Author)Uni Göttingen
Summary0005799: BNF problem in the advanced parameterization package: ExtendedFieldReference
DescriptionIn the TTCN-3 4.2.1 Core BNF, there is a rule:
+
+614. ExtendedFieldReference ::=
+{ ( Dot ( StructFieldIdentifier | TypeDefIdentifier ) ) |
+ArrayOrBitRef |
+( "[" NotUsedSymbol "]" )
+}+
+
+With the NoUsedSymbol denoting the "-" don't change symbol as used in
+clause 6.2.3.2 for referencing the inner type of record of and set of types.
+
+This rule is redefined in the advanced parameterization package v1.1.1:
+
+603. ExtendedFieldReference ::=
+{((Dot (StructFieldIdentifier | (TypeDefIdentifier
+[ActualTypeParList][TypeActualParList]))) |
+ArrayOrBitRef
+) }+
+
+The ( "[" NotUsedSymbol "]" ) part is missing in the advanced
+parameterization package and should probably added to the package BNF.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc Resolution-CR-5799-Jens-101201.doc (345,600) 01-12-2010 13:40
http://oldforge.etsi.org/mantis/file_download.php?file_id=2454&type=bug
Issue History
Date ModifiedUsernameFieldChange
29-10-2010 16:47Benjamin ZeissNew Issue
29-10-2010 16:47Benjamin ZeissClause Reference(s) => 6.2.3.2
29-10-2010 16:47Benjamin ZeissSource (company - Author) => Uni Göttingen
30-11-2010 09:38Ina SchieferdeckerProjectTTCN-3 Change Requests => Ext Pack: Advanced Parametrization (ES 202 784)
01-12-2010 08:14Gyorgy RethyNote Added: 0009870
01-12-2010 08:14Gyorgy RethyAssigned To => Jens Grabowski
01-12-2010 08:14Gyorgy RethyStatusnew => assigned
01-12-2010 08:14Gyorgy RethyNote Edited: 0009870
01-12-2010 13:40Jens GrabowskiFile Added: Resolution-CR-5799-Jens-101201.doc
01-12-2010 13:43Jens GrabowskiNote Added: 0009895
01-12-2010 13:43Jens GrabowskiStatusassigned => closed
01-12-2010 13:43Jens GrabowskiResolutionopen => fixed
13-12-2010 13:30Gyorgy RethyStatusclosed => feedback
13-12-2010 13:30Gyorgy RethyResolutionfixed => reopened
13-12-2010 13:30Gyorgy RethyNote Added: 0009952
13-12-2010 13:31Gyorgy RethyNote Added: 0009953
13-12-2010 13:31Gyorgy RethyStatusfeedback => closed
13-12-2010 13:31Gyorgy RethyResolutionreopened => fixed
13-12-2010 13:31Gyorgy RethyFixed in Version => v1.2.1
13-12-2010 13:31Gyorgy RethyTarget Version => v1.2.1
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009870) +
+ Gyorgy Rethy    +
+ 01-12-2010 08:14    +
+ 		+ + + + +
+ STF discussion 30-11-2010: comment is rigth, correct the BNF in the draft.
+
+
+
+
+
+ + + + + + + + + + +
+ (0009895) +
+ Jens Grabowski    +
+ 01-12-2010 13:43    +
+ 		+ + + + +
+ As suggested by Benjamin, rule 603 is changed to
+
+603. ExtendedFieldReference ::=
+{
+  (
+    (Dot
+      (StructFieldIdentifier |
+       (TypeDefIdentifier [ActualTypeParList [TypeActualParList])
+      )
+    )
+    | ArrayOrBitRef
+    | ("[" NotUsedSymbol "]")
+  )
+}+
+
+The entire package with the implemented resolution is uploaded to this CR. The CR will be set to fixed and closed. An updated Draft will be uploaded to the MTS DRAFT area.
+
+
+
+
+
+ + + + + + + + + + +
+ (0009952) +
+ Gyorgy Rethy    +
+ 13-12-2010 13:30    +
+ 		+ + + + +
+ Adding target version and fixed in version to CR.
+
+
+
+ + + + + + + + + + +
+ (0009953) +
+ Gyorgy Rethy    +
+ 13-12-2010 13:31    +
+ 		+ + + + +
+ Target version and fixed in version are added to CR.
+
+ + diff --git a/docs/mantis/CR5800.md b/docs/mantis/CR5800.md new file mode 100644 index 0000000000000000000000000000000000000000..2291823f71d32acc233f240c4803e5020f8c4fb9 --- /dev/null +++ b/docs/mantis/CR5800.md @@ -0,0 +1,44 @@ + + + + + + + + + + + + + 0005800: Test case stop operation missing in BNF 4.2.1 - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005800Part 01: TTCN-3 Core LanguageTechnicalpublic01-11-2010 16:0530-11-2010 09:37
ReporterBenjamin Zeiss 
Assigned To 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionduplicate 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Clause Reference(s)21.2.1
Source (company - Author)Uni Göttingen
Summary0005800: Test case stop operation missing in BNF 4.2.1
DescriptionThe test case stop operation, as described in clause 21.2.1 of v4.2.1 of the core language standard, is not supported by the BNF in Annex A as far as I can see. A brief look yields that it should probably part of rule
+
+349. StopTCStatement ::= StopKeyword | (ComponentReferenceOrLiteral Dot StopKeyword) | (AllKeyword ComponentKeyword Dot StopKeyword)
+
+But the notation
+
+  testcase "." stop { ( FreeText | TemplateInstance ) [","] } ")"
+
+is not matched by this rule. Furthermore, the StopKeyword only appears in the following rules:
+
+- ControlStatement
+- StopTCStatement
+- PortStopOp
+- StopTimerStatement
+
+My guess is that the syntax has simply been missed to be integrated into the Annex A BNF.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0005801closed Ina Schieferdecker Test case operations - no corresponding BNF rules 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
01-11-2010 16:05Benjamin ZeissNew Issue
01-11-2010 16:05Benjamin ZeissClause Reference(s) => 21.2.1
01-11-2010 16:05Benjamin ZeissSource (company - Author) => Uni Göttingen
01-11-2010 19:03Benjamin ZeissRelationship addedrelated to 0005801
30-11-2010 09:37Ina SchieferdeckerStatusnew => closed
30-11-2010 09:37Ina SchieferdeckerResolutionopen => duplicate
30-11-2010 09:37Ina SchieferdeckerProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
+
+ + + + +
+ There are no notes attached to this issue.
+ + diff --git a/docs/mantis/CR5801.md b/docs/mantis/CR5801.md new file mode 100644 index 0000000000000000000000000000000000000000..8f27ad4f3476b4f84f26e2a91ad46159430512df --- /dev/null +++ b/docs/mantis/CR5801.md @@ -0,0 +1,222 @@ + + + + + + + + + + + + + 0005801: Test case operations - no corresponding BNF rules - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005801Part 01: TTCN-3 Core LanguageEditorialpublic01-11-2010 16:1001-12-2010 10:57
ReporterPhilip Makedonski 
Assigned ToIna Schieferdecker 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.3.1 (published 2011-06)Fixed in Versionv4.3.1 (published 2011-06) 
Clause Reference(s)TTCN-3 v4.2.1 Part 1: Core Notation, Clause 21.2(.1) Test case stop operation
Source (company - Author)University of Göttingen
Summary0005801: Test case operations - no corresponding BNF rules
DescriptionThe testcase.stop operation introduced in clause 21.2.1 of the TTCN-3 Core Notation (v4.2.1) has no respective syntax definition in the BNF productions.
+
+Apart from that, I am just wondering what the point of it is in the first place, wasn't simply using mtc.stop supposed to result in basically the same thing??
Steps To Reproduce1. Read clause 21.2.1
+2. Read annex A.1.6
+(3. Read clauses 21.3.3 and 26.1)
+
Additional Information
TagsNo tags attached.
Relationships
related to 0005800closed  Test case stop operation missing in BNF 4.2.1 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
01-11-2010 16:10Philip MakedonskiNew Issue
01-11-2010 16:10Philip MakedonskiClause Reference(s) => TTCN-3 v4.2.1 Part 1: Core Notation, Clause 21.2(.1) Test case stop operation
01-11-2010 16:10Philip MakedonskiSource (company - Author) => University of Göttingen
01-11-2010 16:36Philip MakedonskiNote Added: 0009793
01-11-2010 19:03Benjamin ZeissRelationship addedrelated to 0005800
11-11-2010 13:58Jacob Wieland - SpirentNote Added: 0009796
30-11-2010 09:36Ina SchieferdeckerProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
30-11-2010 16:57Gyorgy RethyNote Added: 0009865
30-11-2010 16:57Gyorgy RethyAssigned To => Ina Schieferdecker
30-11-2010 16:57Gyorgy RethyStatusnew => assigned
30-11-2010 16:57Gyorgy RethyTarget Version => Edition 4.3.1 (not yet published)
01-12-2010 10:22Ina SchieferdeckerNote Added: 0009881
01-12-2010 10:55Ina SchieferdeckerNote Added: 0009886
01-12-2010 10:57Ina SchieferdeckerStatusassigned => resolved
01-12-2010 10:57Ina SchieferdeckerResolutionopen => fixed
01-12-2010 10:57Ina SchieferdeckerFixed in Version => Edition 4.3.1 (not yet published)
01-12-2010 10:57Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009793) +
+ Philip Makedonski    +
+ 01-11-2010 16:36    +
+ 		+ + + + +
+ After looking a bit closer at it, even the pseudo-syntactic rule present in clause 21.2.1 is incorrect:
+
+testcase "." stop { ( FreeText | TemplateInstance ) [","] } ")"
+
+
+
+ + + + + + + + + + +
+ (0009796) +
+ Jacob Wieland - Spirent    +
+ 11-11-2010 13:58    +
+ 		+ + + + +
+ Semantically, it also sets the error verdict with the given reason. As setverdict(error, reason) is not allowed (for reasons unkonwn and unclear to me), it was felt that some other syntax was needed.
+
+
+
+ + + + + + + + + + +
+ (0009865) +
+ Gyorgy Rethy    +
+ 30-11-2010 16:57    +
+ 		+ + + + +
+ STF discussion 30-11-2010: comment is correct.
+
+
+
+ + + + + + + + + + +
+ (0009881) +
+ Ina Schieferdecker    +
+ 01-12-2010 10:22    +
+ 		+ + + + +
+ BNF and pseudo-syntax changed to
+
+testcase "." stop [ “(“ { ( FreeText | TemplateInstance ) [","] } ")" ]
+
+
+
+ + + + + + + + + + +
+ (0009886) +
+ Ina Schieferdecker    +
+ 01-12-2010 10:55    +
+ 		+ + + + +
+ BNF is
+
+180. FunctionStatement ::= ConfigurationStatements |
+                           TimerStatements |
+                           CommunicationStatements |
+                           BasicStatements |
+                           BehaviourStatements |
+                           VerdictStatements |
+                           SUTStatements |
+                           TestcaseOperation
+
+455. TestcaseOperation ::= TestcaseKeyword "." StopKeyword ["(" {(FreeText |
+                                                                  TemplateInstance)
+                                                                 [","]}
+                                                            ")"]
+
+ + diff --git a/docs/mantis/CR5803.md b/docs/mantis/CR5803.md new file mode 100644 index 0000000000000000000000000000000000000000..330301c4848f8da059a231ffeff75a4ad7b949bf --- /dev/null +++ b/docs/mantis/CR5803.md @@ -0,0 +1,259 @@ + + + + + + + + + + + + + 0005803: STF409 comment on [Part 1: TTCN-3 Core Language / Section 19.11 ]: ad-hoc restrictions - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005803Part 01: TTCN-3 Core LanguageTechnicalpublic10-11-2010 14:0614-12-2010 11:57
ReporterAndras Kovacs 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.3.1 (published 2011-06)Fixed in Versionv4.3.1 (published 2011-06) 
Clause Reference(s)Part 1: TTCN-3 Core Language / Section 19.11
Source (company - Author)BroadBit - Andras Kovacs
Summary0005803: STF409 comment on [Part 1: TTCN-3 Core Language / Section 19.11 ]: ad-hoc restrictions
DescriptionThe following list is given for restrictions on the 'log' statement:
+"Functions used in log statements shall not use directly or indirectly statements other than if…else, for, while, do…while, label, goto, return, mtc, system, self, running (PTC or timer), read and getverdict."
+
+This list seems rather ad-hoc. For example if for/while operations are allowed, then why 'break' operation is not allowed? Since if-else is allowed, why select-case is not allowed? It is recommended to revise these restrictions.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
10-11-2010 14:06Andras KovacsNew Issue
10-11-2010 14:06Andras KovacsClause Reference(s) => Part 1: TTCN-3 Core Language / Section 19.11
10-11-2010 14:06Andras KovacsSource (company - Author) => BroadBit - Andras Kovacs
11-11-2010 13:49Jacob Wieland - SpirentNote Added: 0009795
30-11-2010 09:35Ina SchieferdeckerProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
30-11-2010 16:53Gyorgy RethyNote Added: 0009863
30-11-2010 16:53Gyorgy RethyAssigned To => Ina Schieferdecker
30-11-2010 16:53Gyorgy RethyStatusnew => assigned
30-11-2010 16:53Gyorgy RethyTarget Version => Edition 4.3.1 (not yet published)
01-12-2010 17:12Ina SchieferdeckerNote Added: 0009908
01-12-2010 17:12Ina SchieferdeckerNote Added: 0009909
01-12-2010 17:12Ina SchieferdeckerAssigned ToIna Schieferdecker => Gyorgy Rethy
01-12-2010 17:13Ina SchieferdeckerStatusassigned => resolved
01-12-2010 17:13Ina SchieferdeckerResolutionopen => fixed
01-12-2010 17:13Ina SchieferdeckerFixed in Version => Edition 4.3.1 (not yet published)
02-12-2010 10:20Gyorgy RethyStatusresolved => feedback
02-12-2010 10:20Gyorgy RethyResolutionfixed => reopened
02-12-2010 10:20Gyorgy RethyNote Added: 0009920
02-12-2010 10:21Gyorgy RethyNote Added: 0009921
02-12-2010 10:21Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
02-12-2010 10:21Gyorgy RethyStatusfeedback => resolved
02-12-2010 10:21Gyorgy RethyResolutionreopened => fixed
14-12-2010 11:57Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009795) +
+ Jacob Wieland - Spirent    +
+ 11-11-2010 13:49    +
+ 		+ + + + +
+ Why is any restriction necessary anyway? Why can't I log the result of a function which starts some ptcs, waits for their results and the computes its result in return? This just forces me to put that result in a variable and then log that variable instead? Where is the gain?
+
+
+
+ + + + + + + + + + +
+ (0009863) +
+ Gyorgy Rethy    +
+ 30-11-2010 16:53    +
+ 		+ + + + +
+ STF discussion 30-11-2010: remove the restriction of the log statement
+
+
+
+ + + + + + + + + + +
+ (0009908) +
+ Ina Schieferdecker    +
+ 01-12-2010 17:12    +
+ 		+ + + + +
+ Restrictions redefined from
+
+----------
+In addition to the general static rules of TTCN 3 given in clause 5, the following restrictions apply:
+a) Functions used in log statements shall not use directly or indirectly statements other than if…else, for, while, do…while, label, goto, return, mtc, system, self, running (PTC or timer), read and getverdict.
+----------
+
+to
+
+----------
+No specific restrictions in addition to the general static rules of TTCN 3 given in clause 5.
+----------
+
+In addition, rewording of shall into should not. From
+
+----------
+It is strongly recommended that the execution of the log statement has no effect on the test behaviour. In particular, functions used in a log statement shall neither explicitly nor implicitly change component variable values, port or timer status, and shall not change the value of any of its inout or out parameters.
+----------
+
+to
+
+----------
+It is strongly recommended that the execution of the log statement has no effect on the test behaviour. In particular, functions used in a log statement should not (explicitly or implicitly) change component variable values, port or timer status, and should not change the value of any of its inout or out parameters.
+----------
+
+
+
+ + + + + + + + + + +
+ (0009909) +
+ Ina Schieferdecker    +
+ 01-12-2010 17:12    +
+ 		+ + + + +
+ Please check.
+
+
+
+ + + + + + + + + + +
+ (0009920) +
+ Gyorgy Rethy    +
+ 02-12-2010 10:20    +
+ 		+ + + + +
+ Shall reopen to be able to assign to Ina.
+
+
+
+ + + + + + + + + + +
+ (0009921) +
+ Gyorgy Rethy    +
+ 02-12-2010 10:21    +
+ 		+ + + + +
+ OK with me.
+
+ + diff --git a/docs/mantis/CR5804.md b/docs/mantis/CR5804.md new file mode 100644 index 0000000000000000000000000000000000000000..531771e726deb8c178684ffb748882cb3c411603 --- /dev/null +++ b/docs/mantis/CR5804.md @@ -0,0 +1,177 @@ + + + + + + + + + + + + + 0005804: EnumratedValue needs new method/function getInt - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005804Part 06: TTCN-3 Control InterfaceNew Featurepublic11-11-2010 13:0430-12-2010 17:07
Reportertepelmann 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.1.1 (published 2009-06) 
Target Versionv4.3.1 (published 2011-06)Fixed in Versionv4.3.1 (published 2011-06) 
Clause Reference(s)7.2.2.2.13,8.3.4.13, 9.2, 10.5.3.14
Source (company - Author)    tepelmann
Summary0005804: EnumratedValue needs new method/function getInt
DescriptionIn the TTCN-3 core standard we can find meanwhile the enum2int and upcoming the int2enum predefined function.
+We propose to also give in the TCI the possibility to retrieve the integer value as assigned in TTCN-3 (explicitly or implicitly) and to set the integer value.
Steps To Reproduce
Additional InformationE.g. for Java
+IntegerValue getInt();
+void setInt(IntegerValue enumIntValue);
+or for ANSI-C
+IntegerValue tciGetEnumValueInt(Value inst);
+void tciSetEnumValueInt(Value inst, IntegerValue enumIntValue);
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
11-11-2010 13:04tepelmannNew Issue
11-11-2010 13:04tepelmannClause Reference(s) => 7.2.2.2.13,8.3.4.13, 9.2, 10.5.3.14
11-11-2010 13:04tepelmannSource (company - Author) => tepelmann
30-11-2010 16:58Gyorgy RethyNote Added: 0009866
30-11-2010 16:58Gyorgy RethyAssigned To => Ina Schieferdecker
30-11-2010 16:58Gyorgy RethyStatusnew => assigned
30-11-2010 16:58Gyorgy RethyTarget Version => Edition 4.3.1 (not yet published)
30-12-2010 17:06Ina SchieferdeckerNote Added: 0009984
30-12-2010 17:07Ina SchieferdeckerStatusassigned => resolved
30-12-2010 17:07Ina SchieferdeckerResolutionopen => fixed
30-12-2010 17:07Ina SchieferdeckerFixed in Version => Edition 4.3.1 (not yet published)
30-12-2010 17:07Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009866) +
+ Gyorgy Rethy    +
+ 30-11-2010 16:58    +
+ 		+ + + + +
+ STF discussion 30-11-2010: comment is correct
+
+
+
+ + + + + + + + + + +
+ (0009984) +
+ Ina Schieferdecker    +
+ 30-12-2010 17:06    +
+ 		+ + + + +
+ Defined basically as proposed:
+
+/* Abstract Data */
+
+7.2.2.2.13 The abstract data type EnumeratedValue
+
+TInteger getInt() Returns the integer value of this EnumeratedValue. This integer equals the user-assigned integer value in the TTCN 3 specification or the automatically assigned integer value.
+
+setInt(in TInteger intValue) Sets the integer value of this EnumeratedValue. This integer should equal the user-assigned integer value in the TTCN 3 specification or the automatically assigned integer value.
+
+/* Java */
+
+8.3.4.13 EnumeratedValue
+
+EnumeratedValue is mapped to the following interface:
+// TCI IDL EnumeratedValue
+package org.etsi.ttcn.tci;
+public interface EnumeratedValue {
+    String getEnum ();
+    void setEnum (String enumValue);
+    int getInt();
+    void setInt(int intValue);
+}
+
+
+/* C */
+
+9.2 Value interfaces
+
+Tinteger getInt() unsigned long tciGetEnumInt(Value inst);
+
+setInt(in Tinteger intValue) void tciSetEnumInt(Value inst, unsigned long intValue);
+
+/* C++ */
+
+10.5.3.14 EnumeratedValue
+
+TTCN-3 enumerated value support. It is mapped to the following pure virtual class:
+class EnumeratedValue : public virtual TciValue {
+public:
+    virtual ~EnumeratedValue ();
+    virtual const Tstring & getEnum () const =0;
+    virtual void setEnum (const Tstring &p_value)=0;
+    virtual Tinteger getInt() const =0;
+    virtual void setInt(Tinteger p_int);
+    virtual Tboolean operator== (const EnumeratedValue &enumVal) const =0;
+    virtual EnumeratedValue * clone () const =0;
+    virtual Tboolean operator< (const EnumeratedValue &enumVal) const =0;
+}
+
+
+/* XSD */
+
+11.3.3.17 EnumeratedValue
+EnumeratedValue is mapped to the following complex type:
+    <xsd:complexType name="EnumeratedValue">
+        <xsd:choice>
+            <xsd:element name="value" type="SimpleTypes:TString"/>
+            <xsd:element name="intValue" type="SimpleTypes:TInteger" minOccurs="0"/>
+            <xsd:element name="null" type="Templates:null"/>
+            <xsd:element name="omit" type="Templates:omit"/>
+        </xsd:choice>
+        </xsd:sequence>
+        <xsd:attributeGroup ref="Values:ValueAtts"/>
+    </xsd:complexType>
+
+
+/* C# */
+
+12.4.4.13 EnumeratedValue
+EnumeratedValue is mapped to the following interface:
+public interface ITciEnumeratedValue : ITciValue {
+    string EnumValue { get; set; }
+    int IntValue { get; set; }
+}
+
+ + diff --git a/docs/mantis/CR5805.md b/docs/mantis/CR5805.md new file mode 100644 index 0000000000000000000000000000000000000000..e2535b2c702e10cb15f1811e2e26d220633ab111 --- /dev/null +++ b/docs/mantis/CR5805.md @@ -0,0 +1,342 @@ + + + + + + + + + + + + + 0005805: BNF rule for PatternElement is ambiguous, Example is wrong - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005805Part 01: TTCN-3 Core LanguageTechnicalpublic11-11-2010 13:4601-07-2011 14:42
ReporterJacob Wieland - Spirent 
Assigned ToIna Schieferdecker 
PriorityhighSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.3.2 (interim 2011)Fixed in Versionv4.3.2 (interim 2011) 
Clause Reference(s)B.1.5.2, A.1.6.1.3
Source (company - Author)Testing Technologies - Jacob Wieland
Summary0005805: BNF rule for PatternElement is ambiguous, Example is wrong
DescriptionIn 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
TagsNo tags attached.
Relationships
parent of 0005835closed Ina Schieferdecker BNF rule for PatternElement is ambiguous, Example is wrong 
related to 0005797closed Ina Schieferdecker BNF for CharStringMatch is inconsistent with description 
related to 0005828closed Ina Schieferdecker STF409 comment on [Part 1: TTCN-3 Core Language /Annex B.1.5.2 ]: syntactical ambiguity 
related to 0006169closed Ina Schieferdecker The pattern char grammar has been mixed up 
Attached Files? core.bnf (57,081) 30-06-2011 17:21
http://oldforge.etsi.org/mantis/file_download.php?file_id=2540&type=bug
Issue History
Date ModifiedUsernameFieldChange
11-11-2010 13:46Jacob Wieland - SpirentNew Issue
11-11-2010 13:46Jacob Wieland - SpirentClause Reference(s) => B.1.5.2, A.1.6.1.3
11-11-2010 13:46Jacob Wieland - SpirentSource (company - Author) => Testing Technologies - Jacob Wieland
24-11-2010 15:33Gyorgy RethyNote Added: 0009799
24-11-2010 15:34Gyorgy RethyNote Added: 0009800
29-11-2010 15:45Jacob Wieland - SpirentDescription Updated
29-11-2010 15:53Jacob Wieland - SpirentRelationship addedrelated to 0005797
29-11-2010 15:53Jacob Wieland - SpirentRelationship addedrelated to 0005828
30-11-2010 09:35Ina SchieferdeckerProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
30-11-2010 17:11Gyorgy RethyNote Added: 0009868
30-11-2010 17:11Gyorgy RethyAssigned To => Ina Schieferdecker
30-11-2010 17:11Gyorgy RethyStatusnew => assigned
30-11-2010 17:12Gyorgy RethyIssue cloned: 0005835
30-11-2010 17:12Gyorgy RethyRelationship addedparent of 0005835
01-12-2010 16:47Ina SchieferdeckerNote Added: 0009905
01-12-2010 16:47Ina SchieferdeckerTarget Version => Edition 4.3.1 (not yet published)
01-12-2010 16:49Ina SchieferdeckerNote Edited: 0009905
03-12-2010 10:06Gyorgy RethyTarget VersionEdition 4.3.1 (not yet published) => Edition 4.3.2 (interim)
20-05-2011 13:09Gyorgy RethyNote Deleted: 0009800
24-05-2011 16:02Gyorgy RethyNote Added: 0010033
24-05-2011 16:02Gyorgy RethyAssigned ToIna Schieferdecker => Jacob Wieland - Spirent
24-05-2011 19:30Gyorgy RethyPrioritynormal => high
25-05-2011 09:05Jacob Wieland - SpirentNote Added: 0010043
25-05-2011 17:32Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Ina Schieferdecker
26-05-2011 12:58Jacob Wieland - SpirentFile Added: core.bnf
26-05-2011 12:59Jacob Wieland - SpirentNote Added: 0010085
30-06-2011 17:20Ina SchieferdeckerNote Added: 0010166
30-06-2011 17:21Ina SchieferdeckerFile Deleted: core.bnf
30-06-2011 17:21Ina SchieferdeckerFile Added: core.bnf
01-07-2011 14:41Ina SchieferdeckerStatusassigned => resolved
01-07-2011 14:41Ina SchieferdeckerFixed in Version => Edition 4.3.2 (interim)
01-07-2011 14:41Ina SchieferdeckerResolutionopen => fixed
01-07-2011 14:42Ina SchieferdeckerStatusresolved => closed
10-07-2012 18:01Ina SchieferdeckerRelationship addedrelated to 0006169
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009799) +
+ Gyorgy Rethy    +
+ 24-11-2010 15:33    +
+ 		+ + + + +
+ We should discuss if pattern syntax shall be handled in the BNF at all; patterns are "just strings" with special semantics (i.e. pattern "abc?" and pattern "abc\?" - both correct, just semantically means different things).
+
+Your comment to Example 3 is correct, I think Ref6 shall also be a pattern:
+template charstring Ref6:= pattern "{Ref4}{Ref5}";
+otherwise Ref6 is not de-referenced, just processed as a simple string.
+
+
+
+ + + + + + + + + + +
+ (0009868) +
+ Gyorgy Rethy    +
+ 30-11-2010 17:11    +
+ 		+ + + + +
+ STF discussion 30-11-2010: correct the examples in v4.3.1. More detailed discussion is postponed to 2011.
+
+
+
+ + + + + + + + + + +
+ (0009905) +
+ Ina Schieferdecker    +
+ 01-12-2010 16:47    +
(edited on: 01-12-2010 16:49)
+ 		+ + + + +
+ Example corrected via CR5835. Further discussions then in 2011.
+
+
+
+
+
+ + + + + + + + + + +
+ (0010033) +
+ Gyorgy Rethy    +
+ 24-05-2011 16:02    +
+ 		+ + + + +
+ Replace PatternChar production with a definition excluding the leading pattern characters.
+
+
+
+ + + + + + + + + + +
+ (0010043) +
+ Jacob Wieland - Spirent    +
+ 25-05-2011 09:05    +
+ 		+ + + + +
+ The grammar should be changed in the following way:
+
+108. CharStringMatch ::= PatternKeyword PatternParticle {"&" PatternParticle }
+109. PatternParticle ::= Pattern | ReferencedValue
+110. PatternKeyword ::= "pattern"
+111. Pattern ::= """ {PatternElement} """
+112. PatternElement ::= ("\" ("?" | "*" | "\" | "[" | "]" | "{" | "}" |
+                              """ | "|" | "(" | ")" | "#" | "+" | "d" |
+                              "w" | "t" | "n" | "r" | "s" | "b")) |
+                        ("?" | "*" | "|" | "+") |
+                        ("[" ["^"] {PatternClassChar ["-" PatternClassChar]} "]") |
+                        ("{" ReferencedValue "}") |
+                        ("\" "N" "{" (ReferencedValue | Type) "}") |
+                        (""" """) |
+                        ("(" PatternElement ")") |
+                        ("#" (Num |
+                              ("(" Num "," [Num] ")") | ("(" "," Num ")"))) |
+                        PatternChar
+113. PatternChar ::= NonSpecialPatternChar | PatternQuadruple
+NonSpecialPatternChar ::= Char
+/* STATIC SEMANTICS: NonSpecialPatternChar shall not be one of the following characters: "\", "?", "*", "|", "+", "[", "{", """, "(", "#"
+*/
+PatternClassChar ::= NonSpecialPatternClassChar |
+                     PatternQuadruple |
+                     "\" EscapedPatternClassChar
+NonSpecialPatternClassChar ::= Char
+/* STATIC SEMANTICS: NonSpecialPatternClassChar shall not be one of the following characters: "-", "^", "]"
+*/
+EscapedPatternClassChar ::= Char
+/* STATIC SEMANTICS: EscapedPatternClassChar shall not be one of the following characters: "q"
+*/
+114. PatternQuadruple ::= "\" "q" "(" Number "," Number "," Number "," Number ")"
+
+
+The rules for NonSpecialPatternChar, PatternClassChar, NonSpecialPatternClassChar and EscapedPatternClassChar are new and reflect the restrictions on the characters in the contexts they appear in, i.e. they exclude all characters that have special meaning in those contexts.
+
+
+
+ + + + + + + + + + +
+ (0010085) +
+ Jacob Wieland - Spirent    +
+ 26-05-2011 12:59    +
+ 		+ + + + +
+ added changed grammar
+
+
+
+ + + + + + + + + + +
+ (0010166) +
+ Ina Schieferdecker    +
+ 30-06-2011 17:20    +
+ 		+ + + + +
+ This was not quite the latest BNF ... see uploaded BNF
+
+ + diff --git a/docs/mantis/CR5806.md b/docs/mantis/CR5806.md new file mode 100644 index 0000000000000000000000000000000000000000..8ec7cd5a4bcb0c6dce8b700a21ef47bdddb84f70 --- /dev/null +++ b/docs/mantis/CR5806.md @@ -0,0 +1,152 @@ + + + + + + + + + + + + + 0005806: Syntax error in an example - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005806Part 01: TTCN-3 Core LanguageEditorialpublic19-11-2010 09:1214-12-2010 11:44
ReporterGyorgy Rethy 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.3.1 (published 2011-06)Fixed in Versionv4.3.1 (published 2011-06) 
Clause Reference(s)27.7
Source (company - Author)L.M.Ericsson
Summary0005806: Syntax error in an example
DescriptionIn clause 27.7, Examples, in
+template MyRecord2 MyTemplate21 := { m := { a := ?}} with {optional "implicit omit"}}
+
+->the second curly bracketbefore "with" and the second curly bracket closing the with attribute are superflouos
+
+template MyRecord2 MyTemplate22 := { m := MyTemplate1a}} with {optional "implicit omit"}}
+
+->the second curly bracketbefore "with" and the second curly bracket closing the with attribute are superflouos
+
+template MyRecord2 MyTemplate25 := { m := MyTemplate1b} with {optional override "implicit omit"}}
+
+-> the second curly bracket closing the with attribute is superflouos
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
19-11-2010 09:12Gyorgy RethyNew Issue
19-11-2010 09:12Gyorgy RethyClause Reference(s) => 27.7
19-11-2010 09:12Gyorgy RethySource (company - Author) => L.M.Ericsson
30-11-2010 17:08Gyorgy RethyNote Added: 0009867
30-11-2010 17:08Gyorgy RethyAssigned To => Ina Schieferdecker
30-11-2010 17:08Gyorgy RethyStatusnew => assigned
30-11-2010 17:08Gyorgy RethyTarget Version => Edition 4.3.1 (not yet published)
01-12-2010 17:01Ina SchieferdeckerNote Added: 0009906
01-12-2010 17:01Ina SchieferdeckerAssigned ToIna Schieferdecker => Gyorgy Rethy
02-12-2010 10:36Gyorgy RethyNote Added: 0009924
02-12-2010 10:36Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
02-12-2010 10:36Gyorgy RethyStatusassigned => resolved
02-12-2010 10:36Gyorgy RethyResolutionopen => fixed
02-12-2010 10:36Gyorgy RethyFixed in Version => Edition 4.3.1 (not yet published)
14-12-2010 11:44Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009867) +
+ Gyorgy Rethy    +
+ 30-11-2010 17:08    +
+ 		+ + + + +
+ Ina pls. check and resolve if OK.
+
+
+
+ + + + + + + + + + +
+ (0009906) +
+ Ina Schieferdecker    +
+ 01-12-2010 17:01    +
+ 		+ + + + +
+ In Template21 only the second curly bracket closing the with attribute is superflouos.
+
+The templates should be:
+
+template MyRecord2 MyTemplate21 := {m := { a := ?}} with {optional "implicit omit"}
+
+template MyRecord2 MyTemplate22 := {m := MyTemplate1a} with {optional "implicit omit"}
+
+template MyRecord2 MyTemplate25 := {m := MyTemplate1b} with {optional override "implicit omit"}
+
+Please check.
+
+
+
+ + + + + + + + + + +
+ (0009924) +
+ Gyorgy Rethy    +
+ 02-12-2010 10:36    +
+ 		+ + + + +
+ Correct. Solution is OK with me.
+
+ + diff --git a/docs/mantis/CR5807.md b/docs/mantis/CR5807.md new file mode 100644 index 0000000000000000000000000000000000000000..3ff9ccb55f4ee5be83a325cb943aea1938e2b03b --- /dev/null +++ b/docs/mantis/CR5807.md @@ -0,0 +1,223 @@ + + + + + + + + + + + + + 0005807: Restrictions regarding interleave in section 20.4 are confusing and unecessary - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005807Part 01: TTCN-3 Core LanguageTechnicalpublic24-11-2010 12:0929-06-2011 14:33
ReporterWolfgang Seka 
Assigned ToGyorgy Rethy 
PrioritylowSeveritymajorReproducibilityN/A
StatusclosedResolutionwon't fix 
PlatformOSOS Version
Product Version 
Target Versionv4.3.2 (interim 2011)Fixed in Version 
Clause Reference(s)Part 1 clause 20.4, part 4 and clause 7.5
Source (company - Author)stf160 - Wolfgang
Summary0005807: Restrictions regarding interleave in section 20.4 are confusing and unecessary
DescriptionIssues:
+- when it is not allowed to use 'repeat' in interleave statements it seems to be also not allowed to use 'repeat' in any default behaviour which is activated while 'interleave' is called.
+  This causes severe problems for implementation and maintenance when there is always a (standard) default acivated and there are messages which need to be ignored.
+  => By strictly applying the current release of the TTCN-3 standard in fact 'interleve' is useless for stf160.
+- Even though stf160 does not use it until now I don't see the justification for the restrictions listed in clause 20.4 of part 1 and clause 7.5 of part 4.
+  Since these restrictions are not necessary in the expanded representation with nested alt statments the restrictions shall be removed from the standards.
+  (please note that I've not checked the above statements to valid for all exceptions)
+- There has been discussions on the TTCN-3 reflector about the expansion of 'interleave':
+  Inpendent of how compilers or tools implement 'interleave' it shall be clear that the behaviour of 'interleave' results in the same as the expansion with nested alt statements.
+  (and when this is the case, there shall be no other restrictions as for nested alt statements - see above).
+  If there are exceptions of these rules they shall be stated clearly.
+- According to my understand 'break' results in leaving the whole interleave block whereas a 'break' in an inner alt statemente of nested alt statements will only cause leaving this alt statement.
+  When this interpretation is correct, it shall be mentioned that for 'break' there is an exception of the expansion rules (see above).
Steps To Reproduce
Additional InformationNotes:
+- In general when there are necessary restrictions but no tools checking whether they are fulfilled that is a fundamantal problem for projects like stf160 but also for tool compatibility:
+  We never know what will happen at run-time ...
+- As a matter of experience 'normal' TTCN-3 writers don't know about restriction but implement what their compiler allows. Therefore when restrictions are really necessary it shall be possible to check them by tools (none of the compilers which we are using complains about the 'repeat' in the default behaviour ...)
+- Any changes of part 1 may require additional changes of part 4.
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
24-11-2010 12:09Wolfgang SekaNew Issue
24-11-2010 12:09Wolfgang SekaClause Reference(s) => Part 1 clause 20.4, part 4 and clause 7.5
24-11-2010 12:09Wolfgang SekaSource (company - Author) => stf160 - Wolfgang
30-11-2010 09:29Jacob Wieland - SpirentNote Added: 0009835
30-11-2010 09:30Jacob Wieland - SpirentRelationship addedrelated to 0005833
30-11-2010 09:32Ina SchieferdeckerProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
30-11-2010 16:03Gyorgy RethyNote Added: 0009857
30-11-2010 16:03Gyorgy RethyAssigned To => Jens Grabowski
30-11-2010 16:03Gyorgy RethyStatusnew => assigned
30-11-2010 16:03Gyorgy RethyTarget Version => Edition 4.3.1 (not yet published)
01-12-2010 08:45Gyorgy RethyNote Edited: 0009857
01-12-2010 08:47Gyorgy RethyNote Edited: 0009857
03-12-2010 10:01Gyorgy RethyTarget VersionEdition 4.3.1 (not yet published) => Edition 4.3.2 (interim)
24-05-2011 15:44Gyorgy RethyNote Added: 0010032
24-05-2011 19:29Gyorgy RethyPrioritynormal => low
26-05-2011 14:41Gyorgy RethyRelationship deletedrelated to 0005833
28-06-2011 11:11Jens GrabowskiNote Added: 0010131
28-06-2011 11:13Jens GrabowskiAssigned ToJens Grabowski => Gyorgy Rethy
29-06-2011 14:33Gyorgy RethyNote Added: 0010146
29-06-2011 14:33Gyorgy RethyStatusassigned => closed
29-06-2011 14:33Gyorgy RethyResolutionopen => won't fix
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009835) +
+ Jacob Wieland - Spirent    +
+ 30-11-2010 09:29    +
+ 		+ + + + +
+ I think you are wrong in your assessment that 'break' behaves differently in interleave than in a nested alt statement.
+
+If you have a nested alt statement where no statements are following the 'active' alt statement which contains the 'break' in the same block that contains that alt, then also the whole alt-tree is left by the break - same as for a top-level break in the interleave. If you have an alt-statement inside one branch of the interleave which contains a break, then of course only that alt-statement is left when the break is reached and not the whole interleave.
+
+So, I would say the semantics of the break is the same for both and nothing has to be done in that regard.
+
+
+
+ + + + + + + + + + +
+ (0009857) +
+ Gyorgy Rethy    +
+ 30-11-2010 16:03    +
(edited on: 01-12-2010 08:47)
+ 		+ + + + +
+ STF discussion on 30-11-2010: repeat is allowed in activated defaults. Add a note clarifying this to Part-1 v4.3.1. All other possible changes to interleave is postponed to 2011.
+
+
+
+
+
+ + + + + + + + + + +
+ (0010032) +
+ Gyorgy Rethy    +
+ 24-05-2011 15:44    +
+ 		+ + + + +
+ Ask Wolfgang if allowing repeat in defaults solves STF160's problem.
+
+
+
+ + + + + + + + + + +
+ (0010131) +
+ Jens Grabowski    +
+ 28-06-2011 11:11    +
+ 		+ + + + +
+ Currently, there exists no problem with the restrictions for STF 160 (Wolfgang). A removal of the restrictions may require a new semantics, i.e., a replacement of the macro expansion by, e.g., parallel execution of the interleaved branches.
+
+Assigned to György for closing.
+
+
+
+ + + + + + + + + + +
+ (0010146) +
+ Gyorgy Rethy    +
+ 29-06-2011 14:33    +
+ 		+ + + + +
+ Allowing repeat in interleave statements directly is not required by submitter and it has already been allowed in defaults invoked by the interleave.
+
+ + diff --git a/docs/mantis/CR5808.md b/docs/mantis/CR5808.md new file mode 100644 index 0000000000000000000000000000000000000000..836449bc7c6b61efe359d38846bfa803de85d2dc --- /dev/null +++ b/docs/mantis/CR5808.md @@ -0,0 +1,244 @@ + + + + + + + + + + + + + 0005808: STF409 comment on [Part 1: TTCN-3 Core Language / Section 5.4.1 ]: inout parameters - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005808Part 01: TTCN-3 Core LanguageTechnicalpublic24-11-2010 12:1101-12-2010 10:28
ReporterAndras Kovacs 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionno change required 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Clause Reference(s)[Part 1: TTCN-3 Core Language / Section 5.4.1 ]
Source (company - Author)BroadBit - Andras Kovacs
Summary0005808: STF409 comment on [Part 1: TTCN-3 Core Language / Section 5.4.1 ]: inout parameters
DescriptionIt is implied from the content of this section that there can be no default value for inout parameters, and furthermore the value of a referenced inout parameter must be always present in the corresponding call (i.e. no use of '-' assignment for inout parameter types).
+It would add much to the clarity of the standard if this restriction has been explicitly stated.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
24-11-2010 12:11Andras KovacsNew Issue
24-11-2010 12:11Andras KovacsClause Reference(s) => [Part 1: TTCN-3 Core Language / Section 5.4.1 ]
24-11-2010 12:11Andras KovacsSource (company - Author) => BroadBit - Andras Kovacs
29-11-2010 09:56Jacob Wieland - SpirentNote Added: 0009818
29-11-2010 10:40Gyorgy RethyNote Added: 0009819
29-11-2010 10:41Gyorgy RethyNote Added: 0009820
29-11-2010 10:41Gyorgy RethyAssigned To => Jacob Wieland - Spirent
29-11-2010 10:41Gyorgy RethyStatusnew => assigned
29-11-2010 12:54Jacob Wieland - SpirentNote Added: 0009825
29-11-2010 13:04Jacob Wieland - SpirentRelationship addedrelated to 0005513
29-11-2010 13:05Jacob Wieland - SpirentRelationship deletedrelated to 0005513
29-11-2010 13:10Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
29-11-2010 13:56Gyorgy RethyNote Edited: 0009819
30-11-2010 09:34Ina SchieferdeckerProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
01-12-2010 10:22Gyorgy RethyNote Added: 0009880
01-12-2010 10:28Gyorgy RethyStatusassigned => closed
01-12-2010 10:28Gyorgy RethyResolutionopen => no change required
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009818) +
+ Jacob Wieland - Spirent    +
+ 29-11-2010 09:56    +
+ 		+ + + + +
+ Default values to inout parameters does not make sense as these parameters are always instantiated with VARIABLES and since there are no global variables, no such variable can be supplied in the formal parameter declaration.
+
+However, I think allowing the unchanged symbol as instantiation for for out parameters (with the meaning that the resulting value of the out-parameter after the call is not assigned to any variable) would make sense.
+
+For example:
+
+function splitQualifiedName(in charstring qualifiedName, out charstring moduleName, out charstring declName) {
+...
+  moduleName := ...;
+  declName := ...;
+...
+}
+
+function charstring getDeclarationName(in charstring qualifiedName) return charstring {
+  var charstring result;
+  splitQualifiedName(qualifiedName, -, result);
+  return result;
+}
+
+It could even be possible to allow leaving out the rest of the parameter list (the same as for in-parameters) if all the rest-parameters are 'unchanged'.
+
+function charstring getModuleName(in charstring qualifiedName) return charstring {
+  var charstring result;
+  splitQualifiedName(qualifiedName, result);
+  return result;
+}
+
+Now, allowing default values for inout parameters could then have the meaning that when a function call passes the unchanged symbol to such a parameter, it is treates as if a variable that contains that value was passed to the parameter and assignment to that parameter won't have any effect to the calling function (like for an out parameter).
+
+This would be a consistent and useful generalization of the default-value/unchanged-parameter feature.
+
+
+
+ + + + + + + + + + +
+ (0009819) +
+ Gyorgy Rethy    +
+ 29-11-2010 10:40    +
(edited on: 29-11-2010 13:56)
+ 		+ + + + +
+ STF409 didn't asked to extend default values to inout or out parameters, just to add a sentence to state *explicitly*, that default value is not allowed for these kinds of parameters. Currently the standard states in
+$5.4.1 "Formal in parameters may have default values. This default value is used when no actual parameter is provided." and in
+$5.4.1.1 "In parameters may have a default value, which is given by an expression assigned to the parameter.".
+
+I simply propose to add the sentence to $5.4.1 (following the existing two sentences)
+"Inout and out parameters shall have no default value."
+
+
+
+
+
+ + + + + + + + + + +
+ (0009820) +
+ Gyorgy Rethy    +
+ 29-11-2010 10:41    +
+ 		+ + + + +
+ Assigned to Jacob on my own, to check my proposal.
+
+
+
+ + + + + + + + + + +
+ (0009825) +
+ Jacob Wieland - Spirent    +
+ 29-11-2010 12:54    +
+ 		+ + + + +
+ Your proposal is fine, but I think totally unnecessary.
+
+Since the feature 'default value' is only introduced in the context of in parameters, I don't think that it needs to be forbidden for other kinds of parameters for which it was never introduced.
+
+So, your proposal just adds (in my view unncessecary) redundancy (which later can lead to inconsistencies should the feature be enlarged to encompass other kinds of parameters as well).
+
+It's like saying: Strings can be concatenated with the concatenation operator. Integers cannot be concatenated with the concatenation operator.
+
+Restrictions should only be added where not having the restriction would have any meaningful semantics but which is problematic for some reason. Otherwise, the restriction should be unnecessary.
+
+
+
+ + + + + + + + + + +
+ (0009880) +
+ Gyorgy Rethy    +
+ 01-12-2010 10:22    +
+ 		+ + + + +
+ OK. Clarifying the question in this CR should be enough, default values are allowed for "in" parameters only. No change in the standard's text.
+
+ + diff --git a/docs/mantis/CR5809.md b/docs/mantis/CR5809.md new file mode 100644 index 0000000000000000000000000000000000000000..3a527690ed5253964839ced53f69ab3701a6a32c --- /dev/null +++ b/docs/mantis/CR5809.md @@ -0,0 +1,676 @@ + + + + + + + + + + + + + 0005809: CL chapter 15.11 Concatenating templates of string and list types is not supported by BNF - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005809Part 01: TTCN-3 Core LanguageClarificationpublic24-11-2010 12:4917-07-2011 07:03
ReporterAndrus Lehtmets 
Assigned ToIna Schieferdecker 
PriorityhighSeveritymajorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.3.2 (interim 2011)Fixed in Versionv4.3.2 (interim 2011) 
Clause Reference(s)CL chapter 15.11 Concatenating templates of string and list types and BNF
Source (company - Author)Elvior
Summary0005809: CL chapter 15.11 Concatenating templates of string and list types is not supported by BNF
DescriptionCL chapter 15.11 Concatenating templates of string and list types is not supported by BNF.
+
+We propose to modify BNF so:
+ 111. SingleValueOrAttrib ::= MatchingSymbol |
+SingleExpression |
+( TemplateRefWithParList [ ExtendedFieldReference ] ) [ TemplateConcat ]
+
+NewRule.
+TemplateConcat ::= StringOp SingleValueOrAttrib [TemplateConcat ]
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0005513closed Ina Schieferdecker resolution of CR5092 contains bogus examples for charstring 
Attached Filesdoc es_20187301v040205m_CR_5809.doc (92,160) 26-05-2011 14:17
http://oldforge.etsi.org/mantis/file_download.php?file_id=2506&type=bug
doc es_20187301v040205m_CR_5809_v2.doc (115,200) 30-06-2011 08:48
http://oldforge.etsi.org/mantis/file_download.php?file_id=2529&type=bug
doc es_20187301v040205m_CR_5809_v3.doc (103,936) 01-07-2011 11:09
http://oldforge.etsi.org/mantis/file_download.php?file_id=2544&type=bug
doc es_20187301v040205m_CR_5809_v4.doc (109,056) 17-07-2011 06:19
http://oldforge.etsi.org/mantis/file_download.php?file_id=2558&type=bug
Issue History
Date ModifiedUsernameFieldChange
24-11-2010 12:49Andrus LehtmetsNew Issue
24-11-2010 12:49Andrus LehtmetsClause Reference(s) => CL chapter 15.11 Concatenating templates of string and list types and BNF
24-11-2010 12:49Andrus LehtmetsSource (company - Author) => Elvior
24-11-2010 16:43David Diaz (MTP)Note Added: 0009804
25-11-2010 11:54David Diaz (MTP)Note Added: 0009805
25-11-2010 14:54Jacob Wieland - SpirentNote Added: 0009806
25-11-2010 16:05David Diaz (MTP)Note Added: 0009807
29-11-2010 13:08Jacob Wieland - SpirentRelationship addedrelated to 0005513
29-11-2010 13:09Jacob Wieland - SpirentNote Added: 0009827
30-11-2010 10:52David Diaz (MTP)Note Added: 0009837
03-12-2010 10:09Gyorgy RethyTarget Version => Edition 4.3.2 (interim)
24-05-2011 15:30Gyorgy RethyNote Added: 0010031
24-05-2011 15:30Gyorgy RethyAssigned To => Jacob Wieland - Spirent
24-05-2011 15:30Gyorgy RethyStatusnew => assigned
24-05-2011 19:29Gyorgy RethyPrioritynormal => high
25-05-2011 09:47Jacob Wieland - SpirentNote Added: 0010044
26-05-2011 14:17Jacob Wieland - SpirentFile Added: es_20187301v040205m_CR_5809.doc
26-05-2011 14:23Jacob Wieland - SpirentNote Added: 0010088
26-05-2011 15:29Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
27-05-2011 15:47Gyorgy RethyNote Added: 0010106
30-05-2011 13:30Jacob Wieland - SpirentNote Added: 0010109
29-06-2011 18:01Gyorgy RethyFile Added: es_20187301v040205m_CR_5809_v2.doc
29-06-2011 18:18Gyorgy RethyNote Added: 0010149
29-06-2011 18:26Gyorgy RethyFile Deleted: es_20187301v040205m_CR_5809_v2.doc
29-06-2011 18:26Gyorgy RethyFile Added: es_20187301v040205m_CR_5809_v2.doc
29-06-2011 18:26Gyorgy RethyAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
30-06-2011 08:48Gyorgy RethyFile Deleted: es_20187301v040205m_CR_5809_v2.doc
30-06-2011 08:48Gyorgy RethyFile Added: es_20187301v040205m_CR_5809_v2.doc
30-06-2011 09:34Jacob Wieland - SpirentNote Added: 0010152
30-06-2011 16:31Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
01-07-2011 11:02Jacob Wieland - SpirentNote Added: 0010173
01-07-2011 11:09Jacob Wieland - SpirentFile Added: es_20187301v040205m_CR_5809_v3.doc
04-07-2011 14:51Gyorgy RethyStatusassigned => resolved
04-07-2011 14:51Gyorgy RethyResolutionopen => fixed
05-07-2011 14:38Gyorgy RethyStatusresolved => feedback
05-07-2011 14:38Gyorgy RethyResolutionfixed => reopened
05-07-2011 14:39Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
05-07-2011 14:39Gyorgy RethyStatusfeedback => resolved
05-07-2011 14:39Gyorgy RethyResolutionreopened => fixed
05-07-2011 14:39Gyorgy RethyFixed in Version => Edition 4.3.2 (interim)
17-07-2011 06:19Ina SchieferdeckerNote Added: 0010224
17-07-2011 06:19Ina SchieferdeckerFile Added: es_20187301v040205m_CR_5809_v4.doc
17-07-2011 07:03Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009804) +
+ David Diaz (MTP)    +
+ 24-11-2010 16:43    +
+ 		+ + + + +
+ Dear Andrus,
+
+I think the new rule could be described as:
+
+TemplateConcat ::= StringOp SingleValueOrAttrib
+
+because you have the TemplateConcat [optional] recursion through the updated SingleValueOrAttrib rule.
+
+Anyway, I think this rule is not enough in order to provide full support to clause 15.11.
+
+I would suggest to add the "Syntactical Structure", "Semantic Description" and "Restrictions" sections in order to clarify the operation usage.
+
+Regards,
+David (MTP)
+
+
+
+ + + + + + + + + + +
+ (0009805) +
+ David Diaz (MTP)    +
+ 25-11-2010 11:54    +
+ 		+ + + + +
+ We have some additional comments on this.
+
+Reading the 15.11 clause, a "new" concept seems to be defined: "single template". What's this? What's the syntax supported in this kind of statement?
+I mean that a deep analysis should be performed in order to know what is going to be supported for concatenating "single templates". Because going through the actual TemplateBody rule will lead to provide syntactic support to absolutely all TTCN-3 templates, including for instance the "ifpresent" keyword (we can not rely this check in the semantic side!) and, in addition to this, due to this rule:
+
+53. StringLength ::= LengthKeyword "(" SingleConstExpression [".." UpperBound] ")"
+
+we are also supporting the use of ranges when specifying length restrictions (and this is not supported according to 15.11 description).
+
+In conclusion, we suggest to:
+
+1- Clarify this standard clause through the "Syntactical Structure", "Semantic Description" and "Restrictions" sections (Mantis CR - http://t-ort.etsi.org/view.php?id=5809 [^])
+2- To specify the BNF rules required for this new operation performed over "single templates" expressions, once the 15.11 has been fully defined.
+
+Best regards,
+David (MTP)
+
+
+
+ + + + + + + + + + +
+ (0009806) +
+ Jacob Wieland - Spirent    +
+ 25-11-2010 14:54    +
+ 		+ + + + +
+ I think this issue is already resolved by the CR 5513.
+
+
+
+ + + + + + + + + + +
+ (0009807) +
+ David Diaz (MTP)    +
+ 25-11-2010 16:05    +
+ 		+ + + + +
+ Dear Jacob,
+
+Thanks a lot for providing this info!
+
+After reviewing the proposed solution “CR5513_resolution v7.doc [^] (91,648 bytes) 22-07-2010 11:58”, I think this issue is not fully resolved, as far as:
+
+- It is still possible to specify length restrictions using ranges, despite the clause remains stating “ constrained to a fixed length”.
+
+- Usage and restrictions on the outer template [ExtraMatchingAttributes] mechanisms, if any, should be described – I agree this could be confusing to everybody – not only the user. If no limitation is going to be provided on this, samples are welcome. Let me please insist on requesting for detailed information on this clause. I think it is complex enough to provide the “usual” sections we can see all along the standard document (Syntactical Structure, Semantic Description and Restrictions)
+
+Best regards,
+David (MTP)
+
+
+
+ + + + + + + + + + +
+ (0009827) +
+ Jacob Wieland - Spirent    +
+ 29-11-2010 13:09    +
+ 		+ + + + +
+ I agree with your point 1 and have amended a note to CR5513 in that regard.
+
+But I don't know what restrictions in the ExtraMatchingAttributes you are talking about? Please provide an example of what you want restricted and why.
+
+
+
+ + + + + + + + + + +
+ (0009837) +
+ David Diaz (MTP)    +
+ 30-11-2010 10:52    +
+ 		+ + + + +
+ Hi Jacob,
+
+I don't want to add any restriction to the outer matching attribute. I just ask for clarifications on the “usage (and restrictions, if any is going to be considered)” of the ExtraMatchingAttributes when concatenating templates.
+
+Example:
+The following statements are syntactically valid:
+
+template charstring t_Mycharstring := "ABC" & * length(2) & "E?F" length(1..7); //is this valid?
+template charstring t_Mycharstring := "ABC" & * length(2) length(1..7); //is this valid?
+template charstring t_Mycharstring := "ABC" & * length(2) & "E?F" ifpresent; //this is not valid
+
+template Mymessage MyTemplate:=
+{ :
+field2 := "ABC" & * length(2) & "E?F" ifpresent, //is this valid?
+field3 := ? length(3) //according to the proposed BNF, which rule is being applied?
+field4 := ? length(1..4)
+:
+}
+
+Additionally, according to the proposed BNF, which rule is being applied for field3 and field4:
+
+the ( AnyValue [ LengthMatch ] ) | from rule 4. MatchingSymbol
+or the [ExtraMatchingAttributes] from rule 1. TemplateBody ?
+
+I think the first one is being applied, so this issue should be considered in case of defining a different syntax when concatenating templates, because “ExtraMatchingAttributes” allows the usage of ranges, but this should not be the case when concatenating templates.
+
+Regards,
+David (MTP)
+
+
+
+ + + + + + + + + + +
+ (0010031) +
+ Gyorgy Rethy    +
+ 24-05-2011 15:30    +
+ 		+ + + + +
+ Check the comment.
+
+
+
+ + + + + + + + + + +
+ (0010044) +
+ Jacob Wieland - Spirent    +
+ 25-05-2011 09:47    +
+ 		+ + + + +
+ We should add a NOTE (not a restriction, as it is not really restricting anything), saying that if a concatenation expression in a TemplateBody ends with a AnyValue or AnyValueOrOmit followed by a length restriction, this is supposed to be the WildcardLengthMatch associated with the Wildcard. Other extra matching attributes apply to the whole expression in the TemplateBody.
+
+Example:
+
+template hexstring x := 'f00'H & ? length(0..3); // length(0..3) applies to ?
+template hexstring x2 := 'f00'H & ? length(0..3) length(3..6) // length(0..3) applies to ?, length(3..6) applies to the whole expression.
+
+template hexstring x3 := 'f00'H & ? length(0..1) & 'b*'H length(0..20) // length(0..20) applies to the whole expression.
+
+To me this last example also seems kind of illogical, as the length restriction could as easily be interpreted (naively) to be applicable to 'b*'H, thereby confusing the user. Maybe we should allow WildcardLengthMatch also for other MatchingMechanisms that can be concatenated (and could have variable length).
+
+This would lead to the situation that, if the user WANTS to restrict the length of the whole template that does not end with a particle with a length restriction, they would need to add a paranthesis around the concatenation before appending the ExtraMatchingAttributes length restriction.
+
+If that is a scenario we could live with, then we should remove this confusing feature. It would be a backward compatible change in regard to the situation before concatenation of templates was allowed. But, it would not be backward compatible to 4.3.1.
+
+
+
+ + + + + + + + + + +
+ (0010088) +
+ Jacob Wieland - Spirent    +
+ 26-05-2011 14:23    +
+ 		+ + + + +
+ I've aligned the examples to the text (only specific values and (length restricted) wildcards and no OctetStringMatch etc. are allowed) in 15.11.
+
+I've disallowed StringLength in ExtraMatchingAttributes when SimpleSpec in TemplateBody is a concatenation expression as the length of any concatenation is fix/known anyway (because of the fixed length of the WildcardLengthMatch) and thus an extra StringLength would be superfluous/redundant anyway.
+
+This resolves the syntactical ambiguity as any length appearing at the end of a concatenation must then be WildcardLengthMatch.
+
+I also allowed SingleExpression (with static semantics type integer) in WildcardLengthMatch instead of ConstantExpression as there is no such restriction to a constant in the main text and there is an example using a variable.
+
+
+
+ + + + + + + + + + +
+ (0010106) +
+ Gyorgy Rethy    +
+ 27-05-2011 15:47    +
+ 		+ + + + +
+ In case of binary strings why to disallow e.g. '*'B when ? is allowed (and ? is then transformed back to '*' in the resulted string)? They are equivalent, refering to exactly the same set of values (all values allowed by the type).
+On the other hand, in the case
+type bitstring MyBit5 length (5);
+type bitstring MyBit;
+template MyBit5 c_bit5 := ?;
+template MyBit c_bit := '1'B & c_bit5 & '1'B;
+//what is the resulted template:
+// '1*1'B length(7) or '1*1'B ?
+
+
+
+ + + + + + + + + + +
+ (0010109) +
+ Jacob Wieland - Spirent    +
+ 30-05-2011 13:30    +
+ 		+ + + + +
+ > In case of binary strings why to disallow e.g. '*'B when ? is allowed (and ?
+> is then transformed back to '*' in the resulted string)? They are equivalent,
+> refering to exactly the same set of values (all values allowed by the type).
+
+I don't know. The text forbids it. I didn't write the text. I just aligned the examples with the text.
+
+> On the other hand, in the case
+> type bitstring MyBit5 length (5);
+> type bitstring MyBit;
+> template MyBit5 c_bit5 := ?;
+> template MyBit c_bit := '1'B & c_bit5 & '1'B;
+> //what is the resulted template:
+> // '1*1'B length(7) or '1*1'B ?
+
+I don't think this is allowed by the text either, as I understood it, only specific values (i.e. string literals) and (possibly fixed-length-restricted) wildcards are allowed. I quote:
+
+"The single templates of binary string and list types shall contain only the matching mechanisms specific values, AnyValue or AnyValueOrNone constrained to a fixed length, AnyElement, or AnyElementsOrNone possibly constrained with a length attribute for list types"
+
+
+
+ + + + + + + + + + +
+ (0010149) +
+ Gyorgy Rethy    +
+ 29-06-2011 18:18    +
+ 		+ + + + +
+ 1) By the '*'B vs. ? question I just meant that the ext allows both but the example '*'B has been replaced by ?; by this is not essential.
+2) Jacob wrote:
+"template hexstring x3 := 'f00'H & ? length(0..1) & 'b*'H length(0..20) // length(0..20) applies to the whole expression.
+
+To me this last example also seems kind of illogical, as the length restriction could as easily be interpreted (naively) to be applicable to 'b*'H, thereby confusing the user."
+
+I totally agree, I'm sure, this will be very confusing for the user. So I propose to completely forbid ExtraMatchingAttribute after concatenation, i.e. if the user wants to restrict the length of anything produced by concatenation, ALWAYS force the use of parantheses, independent of what is being concatenated.
+
+Pls. note, even the simple case
+'f00'H & 'b'H length(0..2)
+is ambiguous, as length(0..2) may be understood as applied to the whole concatenation (in which case will not match anything) or applied to 'b'H only (in which case will match 'f00b'H).
+
+Pls. review changes in es_20187301v040205m_CR_5809_v2.doc
+
+
+
+ + + + + + + + + + +
+ (0010152) +
+ Jacob Wieland - Spirent    +
+ 30-06-2011 09:34    +
+ 		+ + + + +
+ > 1) By the '*'B vs. ? question I just meant that the ext allows both but the example '*'B has been replaced by ?; by this is not essential.
+
+You're right, I overlooked AnyElementsOrNone. So the special case '*'O length(X) is also allowed by the text.
+
+Otherwise, we seem to be in agreement on disallowing length constraint on a concatenation expression.
+
+
+
+ + + + + + + + + + +
+ (0010173) +
+ Jacob Wieland - Spirent    +
+ 01-07-2011 11:02    +
+ 		+ + + + +
+ Adding the optional "(" ")" in the BNF makes no sense as they are already included in SingleExpression
+
+SingleExpression =>* Primary => "(" SingleExpression ")"
+
+
+
+ + + + + + + + + + +
+ (0010224) +
+ Ina Schieferdecker    +
+ 17-07-2011 06:19    +
+ 		+ + + + +
+ Implemented with editorial changes, see v4
+
+ + diff --git a/docs/mantis/CR5810.md b/docs/mantis/CR5810.md new file mode 100644 index 0000000000000000000000000000000000000000..29d5fd2907c91f2b3689bcee93e2089ebfc1e0df --- /dev/null +++ b/docs/mantis/CR5810.md @@ -0,0 +1,945 @@ + + + + + + + + + + + + + 0005810: Blocking configuration operation on PTC - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Config & Deployment Support (ES 202 781)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005810Ext Pack: Config & Deployment Support (ES 202 781)New Featurepublic24-11-2010 17:1204-06-2012 06:08
ReporterElisabet Wahlgren 
Assigned ToGyorgy Rethy 
PrioritylowSeverityfeatureReproducibilityN/A
StatusclosedResolutionno change required 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Clause Reference(s)21, Configuration operations
Source (company - Author)     Ericsson AB - Elisabet Wahlgren
TS version
Summary0005810: Blocking configuration operation on PTC
DescriptionThe project I am working in currently uses TTCN-3 in a way that requires PTC configuration to be done in a serial manner (yes, I know the abbreviation PTC stands for Parallel Test Component, but parallel execution is rarely used in our current project). The code is literally littered with statement sequences of the form
+
+componentRef.start(function());
+componentRef.done;
+
+in such amounts that I began searching for a blocking function execution operation, perhaps "execute", so that the required functionality could be expressed as
+
+componentRef.execute(function());
+
+which would improve readability a lot.
+
+Our test environment involves a rather large number of component types for handling all the protocols that our SUT is using, and there is a lot of code written using the current component and data type structures.
+
+Is this abuse of TTCN-3? Or might there be rationales for introducing a blocking configuration operation?
+ 
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR5810.doc (1,989,120) 01-12-2010 13:59
http://oldforge.etsi.org/mantis/file_download.php?file_id=2457&type=bug
zip example_code_from_CR_submitter.zip (2,045) 29-06-2011 14:07
http://oldforge.etsi.org/mantis/file_download.php?file_id=2523&type=bug
? CHCR_TRAF_RestartTestcases.ttcn (146,545) 20-07-2011 17:26
http://oldforge.etsi.org/mantis/file_download.php?file_id=2562&type=bug
Issue History
Date ModifiedUsernameFieldChange
24-11-2010 17:12Elisabet WahlgrenNew Issue
24-11-2010 17:12Elisabet WahlgrenClause Reference(s) => 21, Configuration operations
24-11-2010 17:12Elisabet WahlgrenSource (company - Author) => Ericsson AB - Elisabet Wahlgren
29-11-2010 15:29Jacob Wieland - SpirentNote Added: 0009831
30-11-2010 09:34Ina SchieferdeckerProjectTTCN-3 Change Requests => Ext Pack: Config & Deployment Support (ES 202 781)
30-11-2010 17:33Gyorgy RethyNote Added: 0009869
30-11-2010 17:33Gyorgy RethyAssigned To => Jacob Wieland - Spirent
30-11-2010 17:33Gyorgy RethyStatusnew => assigned
30-11-2010 17:34Gyorgy RethyProjectExt Pack: Config & Deployment Support (ES 202 781) => Part 01: TTCN-3 Core Language
01-12-2010 13:54Jacob Wieland - SpirentFile Added: CR5810.doc
01-12-2010 13:59Jacob Wieland - SpirentFile Deleted: CR5810.doc
01-12-2010 13:59Jacob Wieland - SpirentFile Added: CR5810.doc
01-12-2010 14:00Jacob Wieland - SpirentNote Added: 0009897
01-12-2010 14:00Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Jens Grabowski
03-12-2010 11:00Gyorgy RethyTarget Version => Edition 4.3.2 (interim)
03-12-2010 12:38Jens GrabowskiNote Added: 0009936
03-12-2010 15:02Elisabet WahlgrenNote Added: 0009938
03-12-2010 15:06Elisabet WahlgrenNote Edited: 0009938
03-12-2010 15:11Jens GrabowskiNote Added: 0009939
03-12-2010 15:37Elisabet WahlgrenNote Deleted: 0009938
24-05-2011 19:28Gyorgy RethyPrioritynormal => low
25-05-2011 13:37Jacob Wieland - SpirentNote Added: 0010049
27-05-2011 13:35Elisabet WahlgrenNote Added: 0010101
27-05-2011 13:57Jacob Wieland - SpirentNote Added: 0010102
29-06-2011 13:57Gyorgy RethyAssigned ToJens Grabowski => Jacob Wieland - Spirent
29-06-2011 14:04Gyorgy RethyNote Added: 0010144
29-06-2011 14:07Gyorgy RethyFile Added: example_code_from_CR_submitter.zip
01-07-2011 13:51Jacob Wieland - SpirentNote Added: 0010177
01-07-2011 13:55Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
18-07-2011 16:49Elisabet WahlgrenNote Added: 0010228
19-07-2011 11:19Jacob Wieland - SpirentNote Added: 0010229
20-07-2011 17:26Elisabet WahlgrenFile Added: CHCR_TRAF_RestartTestcases.ttcn
20-07-2011 17:44Elisabet WahlgrenNote Added: 0010230
21-07-2011 10:01Jacob Wieland - SpirentNote Added: 0010231
28-07-2011 10:24Elisabet WahlgrenNote Added: 0010232
28-07-2011 11:06Elisabet WahlgrenNote Edited: 0010232
27-09-2011 14:04Gyorgy RethyTarget VersionEdition 4.3.2 (interim) => Edition 4.4.1
30-11-2011 10:24Gyorgy RethyNote Added: 0010424
30-11-2011 11:27Elisabet WahlgrenNote Added: 0010438
30-11-2011 13:03Gyorgy RethyNote Added: 0010442
30-11-2011 14:25Elisabet WahlgrenNote Added: 0010446
30-11-2011 16:11Gyorgy RethyStatusassigned => closed
30-11-2011 16:11Gyorgy RethyNote Added: 0010450
30-11-2011 16:11Gyorgy RethyResolutionopen => no change required
30-11-2011 16:11Gyorgy RethyFixed in Version => Edition 4.4.1
04-06-2012 06:08Ina SchieferdeckerProjectPart 01: TTCN-3 Core Language => Ext Pack: Config & Deployment Support (ES 202 781)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009831) +
+ Jacob Wieland - Spirent    +
+ 29-11-2010 15:29    +
+ 		+ + + + +
+ The proposal has merit. Especially, for this construct the restriction that the started function may have no out-parameters can be lifted as then it is clear when exactly these variables get their new values. The ptc-execute could also have the return value of the executed function as its result.
+
+Thus, if you had:
+
+function f(inout integer x) runs on C return integer {
+  x := ...;
+  return ...;
+}
+  
+then you could do:
+
+var C ptc := C.create alive;
+...
+var integer x, y;
+...
+x := ptc.execute(f(y));
+
+
+
+ + + + + + + + + + +
+ (0009869) +
+ Gyorgy Rethy    +
+ 30-11-2010 17:33    +
+ 		+ + + + +
+ STF discussion 30-11-2010: make sense also to allow inout parameters (passing back the parameter value when the called function is finished). Text to be proposed.
+
+
+
+ + + + + + + + + + +
+ (0009897) +
+ Jacob Wieland - Spirent    +
+ 01-12-2010 14:00    +
+ 		+ + + + +
+ please proofread and add operational semantics
+
+
+
+ + + + + + + + + + +
+ (0009936) +
+ Jens Grabowski    +
+ 03-12-2010 12:38    +
+ 		+ + + + +
+ On the discussion of the CR and the resolution proposal from J. Wieland:
+
+I (Jens) am sorry, but the CR and the resolution do somehow not fit.
+
+The CR asks for some sort of shorthand for
+
+componentRef.start(function());
+componentRef.done;
+
+Even this CR needs further information: Shall a default be activated in the background, e.g., to supervise the test execution by means of a test case timer?
+
+Jacob's proposal introduces an execute PTC operation
+- with time supervision and
+- with inout parameters.
+
+First of all, if a default is activated in the background, the solution will not match the intention of the CR.
+
+Inout parameters seems to force the strange restriction that the component started by an execute PTC-operation can only be stopped by itself but not be stopped by any other component, even not by the MTC.
+
+If it is stopped by some other component or the time supervision exceeded, the test run will end with a test case error.
+
+I (Jens) doubt that such a behaviour really is wanted by the CR and that we really want such a behaviour ...
+
+Personally, I (Jens) am against inout parameters for a special case only that in addition implies a very severe runtime restriction (i.e., the component can only be stopped by itself). If we want to have inout-parameters, this should be bound to the start operation itself.
+
+My (Jens) proposal is to ask for some clarification first and then to look into Jacob's proposal again.
+
+Answer from Jacob:
+
+I (Jacob) also think that we need more information regarding the context of the intended statement, i.e. are there default alternatives active or not, is it desired that execution in the starting component continues even if componentRef is stopped before finishing, etc.
+
+The semantics I (Jacob) assigned in my proposal is basically the same semantics as that of the existing execute statement for test cases. Of course, there you don't have the possibility that a testcase can be stopped from another control part.
+
+Either way, if you take my proposal or simply go with the just-syntactic-sugar route, both is fine with me. Allowing effect of out parameters in the syntactic-sugar variant would of course be inconsistent with the normal start statement.
+
+Overall summary:
+
+The STF will ask for further information before reconsidering the proposal from Jacob. The resolution of this CR is shifted to the next year (or new STF).
+
+
+
+ + + + + + + + + + +
+ (0009939) +
+ Jens Grabowski    +
+ 03-12-2010 15:11    +
+ 		+ + + + +
+ Dear Elisabet Wahlgren,
+sorry, Mantis is not an open discussion forum and I will not start a discussion about the CR here. Mantis shall only reflect the status of the CRs. The request for further information as well as further discussion will be done offline via Email. However, I do not have your Email. Please do me a favour and send me an Email to grabowski@informatik.uni-goettingen.de
+Best regards
+Jens Grabowski
+
+
+
+ + + + + + + + + + +
+ (0010049) +
+ Jacob Wieland - Spirent    +
+ 25-05-2011 13:37    +
+ 		+ + + + +
+ From the example that was given to the STF, it seems clear that not the
+pattern
+
+p.start(...)
+p.done;
+
+is really the problem that makes the code 'littered' (I would rather say, unreadable), but the use of indexed/dotted notation expressions over and over again.
+
+The usual approach to this problem would be to extract the re-used common (lengthy) sub-expressions of the statements into variables and then use these
+variables instead. If the expressions are used are lvalues,
+this refactoring needs to be done by introducing a new function with out/inout parameters (which are instantiated with the lengthy lvalue-expressions when calling that function).
+
+For example:
+
+vg_iscSessions[p_index.iscInit].componentRef.start(ISCv2_SessionFunctions.f_
+s_isc_INVITE(vg_continue,
+vg_iscSessions[p_index.iscInit].dialogList[p_index.iscInitDialog],
+vl_sdpInvite, p_parInvite.addHeaderInviteSend, -,
+p_parInvite.deleteHeaderInviteSend));
+
+f_cto_waitForReturnResult({ctIsc :=
+vg_iscSessions[p_index.iscInit].componentRef}, vg_continue);
+
+vg_iscSessions[p_index.iscInit].componentRef.start(ISCv2_SessionFunctions.f_
+r_isc_100Trying(vg_continue,
+vg_iscSessions[p_index.iscInit].dialogList[p_index.iscInitDialog],
+p_par100.addHeader, -, -, p_par100.deleteHeader));
+f_cto_waitForReturnResult({ctIsc :=
+vg_iscSessions[p_index.iscInit].componentRef}, vg_continue);
+
+Would be rewritten to:
+
+var ... componentRef := vg_iscSessions[p_index.iscInit].componentRef;
+var ... dialogList :=
+  vg_iscSessions[p_index.iscInit].dialogList[p_index.iscInitDialog];
+var ... wrappedComponentRef := {ctIsc := componentRef}
+
+componentRef.start(ISCv2_SessionFunctions.f_s_isc_INVITE(vg_continue,
+  dialogList, vl_sdpInvite, p_parInvite.addHeaderInviteSend, -,
+  p_parInvite.deleteHeaderInviteSend));
+f_cto_waitForReturnResult(wrappedComponentRef, vg_continue);
+
+componentRef.start(ISCv2_SessionFunctions.f_r_isc_100Trying(vg_continue,
+  dialogList, p_par100.addHeader, -, -, p_par100.deleteHeader));
+f_cto_waitForReturnResult(wrappedComponentRef, vg_continue);
+
+
+
+ + + + + + + + + + +
+ (0010101) +
+ Elisabet Wahlgren    +
+ 27-05-2011 13:35    +
+ 		+ + + + +
+ Thanks for supporting the view of our code as littered on the verge of unreadability! But we seem to need even more brilliant advice to do away with our quest for an "execute" operation, the lack of which seems to add an orthogonal degree of obfuscation to TTCN-3 code. What would you do with the following function:
+
+function f_auto_configureCharging()
+runs on DEFAULT_MTC_CT
+{
+  vg_dn := "MtasCharging=0,applicationName=MtasFunction" & ",nodeName=jambala";
+  // Offline Orig Node Level
+  vg_ldap.start(f_gen_LdapCheckValue(vg_dn,"mtasChargingOriginatingOffline","0",compareTrue));
+  vg_ldap.done;
+  vg_ldap.start(f_gen_setMtasChargingParameter("mtasChargingOriginatingOffline","1"));
+  vg_ldap.done;
+  // Online Orig Node Level
+  vg_ldap.start(f_gen_LdapCheckValue(vg_dn,"mtasChargingOriginatingOnline","0",compareTrue));
+  vg_ldap.done;
+  vg_ldap.start(f_gen_setMtasChargingParameter("mtasChargingOriginatingOnline","1"));
+  vg_ldap.done;
+  // Offline Term Node Level
+  vg_ldap.start(f_gen_LdapCheckValue(vg_dn,"mtasChargingTerminatingOffline","0",compareTrue));
+  vg_ldap.done;
+  vg_ldap.start(f_gen_setMtasChargingParameter("mtasChargingTerminatingOffline","1"));
+  vg_ldap.done;
+  // Online Term Node Level
+  vg_ldap.start(f_gen_LdapCheckValue(vg_dn,"mtasChargingTerminatingOnline","0",compareTrue));
+  vg_ldap.done;
+  vg_ldap.start(f_gen_setMtasChargingParameter("mtasChargingTerminatingOnline","1"));
+  vg_ldap.done;
+  vg_ldap.start(f_gen_removeChargingDeactDests());
+  vg_ldap.done;
+  vg_ldap.start(f_gen_setMtasChargingParameter("mtasChargingDefaultCdfAddress",SIP_CommonDefinitions.tsp_ccfRealm1));
+  vg_ldap.done;
+  // Charging Profile - "Charging"
+  vg_ldap.start(f_gen_addMtasChargingProf("Charging","3","3",false,false,true)); // offline/online enabled
+  vg_ldap.done;
+}
+
+
+11 lines too many here? We have tens of thousands of those.
+
+
+
+ + + + + + + + + + +
+ (0010102) +
+ Jacob Wieland - Spirent    +
+ 27-05-2011 13:57    +
+ 		+ + + + +
+ We still think that you are mainly choosing the wrong approach here.
+
+First of all, if you have repetitive code, you should put it in a separate function. This way you would get rid of almost half your 11 lines.
+
+function f_...()
+runs on DEFAULT_MTC_CT
+{
+vg_ldap.start(f_gen_LdapCheckValue(vg_dn,"mtasChargingOriginatingOffline","0",compareTrue));
+  vg_ldap.done;
+}
+
+Also, if you only have single-threaded calls on the same ptc, why then not define the function as running on the PTC and simply call the functions one after the other. There you have a blocking operation and you get rid of the pattern.
+
+In your example, this would look like this:
+
+function f_auto_configureCharging()
+runs on DEFAULT_MTC_CT
+{
+  vg_dn := "MtasCharging=0,applicationName=MtasFunction" & ",nodeName=jambala";
+  // Offline Orig Node Level
+  vg_ldap.start(configure(...)) // to transmit the correct variable values to the ptc.
+  vg_ldap.done;
+  vg_ldap.start(f());
+}
+
+function f() runs on <PtcType> {
+  f_gen_LdapCheckValue(vg_dn,"mtasChargingOriginatingOffline","0",compareTrue);
+  f_gen_setMtasChargingParameter("mtasChargingOriginatingOffline","1");
+  // Online Orig Node Level
+  f_gen_LdapCheckValue(vg_dn,"mtasChargingOriginatingOnline","0",compareTrue);
+  f_gen_setMtasChargingParameter("mtasChargingOriginatingOnline","1");
+  // Offline Term Node Level
+  f_gen_LdapCheckValue(vg_dn,"mtasChargingTerminatingOffline","0",compareTrue);
+  f_gen_setMtasChargingParameter("mtasChargingTerminatingOffline","1");
+  // Online Term Node Level
+  f_gen_LdapCheckValue(vg_dn,"mtasChargingTerminatingOnline","0",compareTrue);
+  f_gen_setMtasChargingParameter("mtasChargingTerminatingOnline","1");
+  f_gen_removeChargingDeactDests();
+
+  f_gen_setMtasChargingParameter("mtasChargingDefaultCdfAddress",
+                                 SIP_CommonDefinitions.tsp_ccfRealm1);
+  // Charging Profile - "Charging"
+  f_gen_addMtasChargingProf("Charging","3","3",false,false,true);
+  // offline/online enabled
+}
+
+I agree with Jens Grabowski, though, that further discussions should be done by mail.
+Just write to stf430@etsi.org or wieland@testingtech.com or to Jens Grabowski (address above)
+
+
+
+ + + + + + + + + + +
+ (0010144) +
+ Gyorgy Rethy    +
+ 29-06-2011 14:04    +
+ 		+ + + + +
+ As agreed during the STF discussion, the problem can be solved by the language instruments existing today: functions started on the different "PTC" types, with runs on clauses using the relevant PTC type are defined today; the MTC type can be defined as extending all PTC component types; thus, all functions started on a PTC today could also be simply called on the MTC and using the relevant "subpart" of the MTC only. This allows compile time checking of the called functions (as all of them do have the needed runs on clause), would solve the problem of returning a value and would result even a simpler syntax than proposed in the example code.
+
+
+
+ + + + + + + + + + +
+ (0010177) +
+ Jacob Wieland - Spirent    +
+ 01-07-2011 13:51    +
+ 		+ + + + +
+ Since you've explained it already fully and the resulting code would not look different from sweetercode.txt or like function f() in my last comment, I don't know what to do here anymore.
+
+
+
+ + + + + + + + + + +
+ (0010228) +
+ Elisabet Wahlgren    +
+ 18-07-2011 16:49    +
+ 		+ + + + +
+ Thank you for your suggestions for usage of existing language instruments.
+
+However, declaring an MTC incorporating all PTC variables would seem to preclude the possibility of requesting parallel execution of functions on components. As stated in my original request, we use it rarely (currently), but it is needed.
+
+
+
+ + + + + + + + + + +
+ (0010229) +
+ Jacob Wieland - Spirent    +
+ 19-07-2011 11:19    +
+ 		+ + + + +
+ We cannot imagine a setting with your highly restricted testing-style (where, as I understood it, the code flow shall reflect the test flow, basically) where you would need a ptc which is also a member of this flow. Of course, you can still have any number of ptcs beside the MTC which are not part of the flow, but with the known drawbacks of explicit synchronization.
+
+Since you yourself already are saying that you use this only rarely, it should not be a problem to then use one of the other suggested workarounds (or even the start/done pairing) in those rare places as well.
+
+
+
+ + + + + + + + + + +
+ (0010230) +
+ Elisabet Wahlgren    +
+ 20-07-2011 17:44    +
+ 		+ + + + +
+ A real-world example of our (ab)use of the TTCN-3 language was just uploaded to your site. For example, testcase TC_CHCR_DYN0030 orders parallel execution of a function on two test components of a type, ISC session component simulating a SIP call end, that we most often use in serial execution. The testcase causes an application process to die in mid-call, which is intended to result in BYE messages sent to both call ends, and where the order in which they receive this BYE message is not important.
+
+Using PTCs, even if they were used only for serial execution, enables data access restriction (cf private class variables) that decreases the risk of undesired interferences. Your recommendation to include all variables required in the MTC instead makes all data globally accessible, which I believe is not always to be desired. Some programming languages nowadays pride themselves by not allowing global variables at all! However, I believe you do require them, but trying to minimize them is wise.
+
+Your alternative suggestion to declare two-line functions to avoid the start-done sequence I also believe many programmers would hold counter to good coding style. Reasonable function lengths - not too small, not too lengthy - has been shown to correlate with readability and maintainability - conducive to quality.
+
+So, what is the views of the TTCN-3 core language group on coding styles? Is this important in any respect for language usability and code maintainability?
+
+
+
+ + + + + + + + + + +
+ (0010231) +
+ Jacob Wieland - Spirent    +
+ 21-07-2011 10:01    +
+ 		+ + + + +
+ The problem here, I think, is that you are confusing different concepts.
+It seems that you view a 'component' in TTCN-3 like an 'object' in an object-oriented language while in actuality it is more on the lines of a 'thread' in an imperative one and pretty much works the same way (i.e. you have to join it explicitely and somehow use communication/synchronization mechanisms to get results from it and have to deal with it not finishing etc.).
+
+Your argument about the visibility of variables is void, since, if you continue to declare your functions to work only on a certain kind of component and then let the MTC (or other driving component) extend the different component types, the function still can only access those fields defined for its component type. This way, you get the best of both worlds. The only drawback is that you cannot have different component variables of the same name anymore, but that could be seen as a bad style anyway.
+
+Basically, you can define your 'component'-functions pretty much the same way as before, but only have to define the 'driving' function differently. And, as I said, if using ptcs is the exception instead of the rule (as you have stated more than once), then using start/done in those few places cannot hurt. Also, it is not bad style, it is just explicit which is true for most things in TTCN-3. Also, if you want to receive different messages in any order, you could also use the interleave-construct instead of ptcs, again alleviating the need for ptcs.
+
+To my knowledge, TTCN-3 is not designed in a way that you can write down things as short as possible, often opting for the more explicit way. I think it was deemed that this would yield more understandable code as implicit knowledge would not be necessary to understand it - leaving nothing open to interpretation - which is good practice when writing down standardized test suites, I guess.
+
+
+
+ + + + + + + + + + +
+ (0010232) +
+ Elisabet Wahlgren    +
+ 28-07-2011 10:24    +
(edited on: 28-07-2011 11:06)
+ 		+ + + + +
+ It seems my code examples have not been conducive to clarifying the data structures we are using to model our test environment. We use not just one instance of a component type – in which case your suggestion to define an MTC extending all component types ever used would work fine- but in the general case we use an array of for example ISC session components, to model a varying number of participants in the many call scenarios handled by a Multimedia Application Server, as well as for example SDP data arrays per each ISC session component. I would upload some definition files if you require more clarification as to our data structure needs, or perhaps the above, together with the code examples already given, are enough to trigger your structural imagination. So, your suggestion is no solution for us. We really need these data array structures to be able to write general code.
+
+My confusion as regards the concept of component in TTCN-3 may not be overwhelming. I am not alone in viewing the function of a component as a way to enable data isolation, as well as a means of threaded execution for simulation of parallel component interaction with a SUT. Yes, as stated already in my initial CR entry, I realize the “abnormality” of using a concept, introduced to enable simulation of parallel execution, for serial execution. But doesTTCN-3 provides other means of data isolation than use of different component types?
+
+Your suggest that providing only “the more explicit way” of defining operations is preferable in a language used to write standardized test suites (I don’t know if our test suites can be described as “standardized” – is this important?). I think you disregard the fact that the creation and maintenance of a collection of test suites for a reasonably complex product is in fact a large scale programming project, in grave need of good language constructs to be able to produce readable and maintainable test code.
+
+I do not today realize for what more narrow purposes TTCN-3 was created. It seems we may have chosen the wrong tool for our type of automated testing. I think originally it was considered an advantage to use the same tool as other testing instances, to benefit from concerted efforts for creating common test port types, etc. But a general purpose programming language with proven useful constructs would probably serve us better – what do you think?
+
+
+
+
+
+ + + + + + + + + + +
+ (0010424) +
+ Gyorgy Rethy    +
+ 30-11-2011 10:24    +
+ 		+ + + + +
+ As a compromise solution, a blocking start could be discussed, where the blocking nature is explicitly identified:
+MyNewPTC.start(MyFirstBehaviour(),block);
+
+it could also be allowed to write
+MyNewPTC.start(MyFirstBehaviour(),noblock);
+where "noblock" would be the default.
+
+The disadvantage is that block would be a new keyword, but I couldn't find a suitable existing keyword.
+
+
+
+ + + + + + + + + + +
+ (0010438) +
+ Elisabet Wahlgren    +
+ 30-11-2011 11:27    +
+ 		+ + + + +
+ Thank you for your attention to this matter.
+
+You have probably already discussed and rejected the existing "execute" keyword (to be exclusively used for testcases?).
+
+If you are introducing new keywords anyway, would you consider "exec"?
+
+
+
+ + + + + + + + + + +
+ (0010442) +
+ Gyorgy Rethy    +
+ 30-11-2011 13:03    +
+ 		+ + + + +
+ The point is that if there will be two different ways of starting PTC behaviour, it shall be visible explicitly, which one is blocking and which one is non-blocking. Nor execute, neither exec hints this information, thus most of the users would simply confuse the semantics of the two operations. For this reason, none of them would be a good solution.
+
+
+
+ + + + + + + + + + +
+ (0010446) +
+ Elisabet Wahlgren    +
+ 30-11-2011 14:25    +
+ 		+ + + + +
+ Thank you for the explanation. This view of the abilities of the TTCN-3 user community is rather depressing.
+
+Has TTCN-3 really been designed for users without any learning capacities? Could then a user really be expected to understand the need for the "execute" keyword in connection with running (I will not use the e-word) a testcase? What about execution "on components" per se - why would this be possible to understand? How come a TTCN-3 user is expected to understand the alt/altstep functionality - very special constructs for alternative execution paths that would seem to require some form of abstract thinking.
+
+I am very surprised by the suggestion that it would be too advanced, causing confusion, to be required to distinguish between blocking and non-blocking function execution on components by using different keywords. And, after all, exec() is a rather common method of function execution in a lot of code circumstances (system calls from scripts or other programming languages, C, Erlang, etc), and for someone completely new to programming, who would have to learn a lot starting to use TTCN-3 anyway, it would be good to understand some more about execution alternatives.
+
+
+
+ + + + + + + + + + +
+ (0010450) +
+ Gyorgy Rethy    +
+ 30-11-2011 16:11    +
+ 		+ + + + +
+ STF decision 30-11-2011: don't change the standard as the use case can be solved using existing language features in several ways. Introducing a new keyword (and a new syntax and semantics) or re-using execute() would be inappropriate and complicate the language unnecessary.
+
+ + diff --git a/docs/mantis/CR5811.md b/docs/mantis/CR5811.md new file mode 100644 index 0000000000000000000000000000000000000000..25e69bba49bf61e1fbe7fd5019cba3107c49ea65 --- /dev/null +++ b/docs/mantis/CR5811.md @@ -0,0 +1,165 @@ + + + + + + + + + + + + + 0005811: Correction in BNF rules for template variables - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005811Part 01: TTCN-3 Core LanguageTechnicalpublic25-11-2010 09:1114-12-2010 14:54
ReporterAndrus Lehtmets 
Assigned ToBenjamin Zeiss 
PrioritynormalSeveritymajorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.3.1 (published 2011-06)Fixed in Version 
Clause Reference(s)CL
Source (company - Author)Elvior
Summary0005811: Correction in BNF rules for template variables
DescriptionWhile the BNF doesn't allow using static templates and template parameters in expressions, the rule for referenced value (494. ValueReference) allows referencing any variable including template variables. This is because the BNF doesn't distinguish between template variable identifiers and value variable identifiers.
+
+Therefore we propose to change the BNF so that these identifiers are distinct and template variables are excluded from using in expressions in the same way as it is done in case of parameter identifiers.
+
+A new rule should be added to the BNF:
+TempVarIdentifier ::= Identifier
+
+The existing rules shall be changed as follows:
+305. SingleTempVarInstance ::= TempVarIdentifier [ArrayDef] [AssignmentChar TempVarInitialValue]
+307. VariableRef ::= ( VarIdentifier | ValueParIdentifier | TempVarIdentifier | TemplateParIdentifier )
+[ ExtendedFieldReference ]
+544. DefinitionRef ::= StructTypeIdentifier |
+EnumTypeIdentifier |
+PortTypeIdentifier |
+ComponentTypeIdentifier |
+SubTypeIdentifier |
+ConstIdentifier |
+TemplateIdentifier |
+AltstepIdentifier |
+TestcaseIdentifier |
+FunctionIdentifier |
+SignatureIdentifier |
+VarIdentifier |
+TimerIdentifier |
+PortIdentifier |
+ModuleParIdentifier |
+FullGroupIdentifier |
+TempVarIdentifier
+
+In addition to that, the syntactical description in chapter 11.2 shall be changed as follows:
+var template [ restriction ] Type TempVarIdentifier [ ArrayDef ] ":=" TemplateBody
+{ [ "," ] TempVarIdentifier [ ArrayDef ] ":=" TemplateBody } [ ";" ]
+
+It should be also considered to change VarIdentifier to ValueVarIdentifier so that it follows the same naming pattern as parameter identifiers.
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0005451closed Ina Schieferdecker Potential BNF Simplification 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
25-11-2010 09:11Andrus LehtmetsNew Issue
25-11-2010 09:11Andrus LehtmetsClause Reference(s) => CL
25-11-2010 09:11Andrus LehtmetsSource (company - Author) => Elvior
29-11-2010 15:41Jacob Wieland - SpirentNote Added: 0009832
30-11-2010 09:34Ina SchieferdeckerProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
30-11-2010 17:35Gyorgy RethyRelationship addedrelated to 0005451
30-11-2010 17:35Gyorgy RethyAssigned To => Benjamin Zeiss
30-11-2010 17:35Gyorgy RethyStatusnew => assigned
30-11-2010 17:35Gyorgy RethyTarget Version => Edition 4.3.1 (not yet published)
02-12-2010 15:30Benjamin ZeissNote Added: 0009933
14-12-2010 14:54Benjamin ZeissStatusassigned => closed
14-12-2010 14:54Benjamin ZeissNote Added: 0009968
14-12-2010 14:54Benjamin ZeissResolutionopen => fixed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009832) +
+ Jacob Wieland - Spirent    +
+ 29-11-2010 15:41    +
+ 		+ + + + +
+ agreed, but the name should be TemplateVarIdentifier instead of TempVarIdentifier (analogous to TemplateParIdentifier) - also the other existing TempVar-names should be changed to TemplateVar for more consistency.
+
+
+
+ + + + + + + + + + +
+ (0009933) +
+ Benjamin Zeiss    +
+ 02-12-2010 15:30    +
+ 		+ + + + +
+ In the BNF simplification of CR5451, we got rid of all superfluous Identifier rules and chain rules. Therefore, this issue will be solved once 5451 is reviewed and becoming the "official" BNF.
+
+
+
+ + + + + + + + + + +
+ (0009968) +
+ Benjamin Zeiss    +
+ 14-12-2010 14:54    +
+ 		+ + + + +
+ As the BNF simplification has been implementend and CR5451 is closed, this issue is automatically done as well. Hence, closing the issue.
+
+ + diff --git a/docs/mantis/CR5828.md b/docs/mantis/CR5828.md new file mode 100644 index 0000000000000000000000000000000000000000..b7828128b33e83163230a872956e20daeca93778 --- /dev/null +++ b/docs/mantis/CR5828.md @@ -0,0 +1,118 @@ + + + + + + + + + + + + + 0005828: STF409 comment on [Part 1: TTCN-3 Core Language /Annex B.1.5.2 ]: syntactical ambiguity - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005828Part 01: TTCN-3 Core LanguageTechnicalpublic28-11-2010 06:3901-12-2010 14:39
ReporterAndras Kovacs 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.3.1 (published 2011-06)Fixed in Versionv4.3.1 (published 2011-06) 
Clause Reference(s)[Part 1: TTCN-3 Core Language /Annex B.1.5.2 ]
Source (company - Author)BroadBit - Andras Kovacs
Summary0005828: STF409 comment on [Part 1: TTCN-3 Core Language /Annex B.1.5.2 ]: syntactical ambiguity
DescriptionThere is a contradiction between the BNF syntax for Reference expression and the examples given in the standard.
+
+BNF Syntax:
+124. CharStringMatch ::= PatternKeyword Pattern {"&" (Pattern | ReferencedValue)}
+125. PatternKeyword ::= "pattern"
+126. Pattern ::= """ { PatternElement } """
+
+Quotation of examples from Annex B.1.5.2:
+const charstring MyConst2 := "ab";
+ template charstring RegExp1 := pattern "{MyConst2}";
+    // matches the string "ab"
+ template charstring RegExp1a := pattern MyConst2;
+    // the same as above, matches the string "ab"
+
+According to BNF syntax, RegExp1a assignment is not syntactically correct.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0005805closed Ina Schieferdecker BNF rule for PatternElement is ambiguous, Example is wrong 
related to 0005513closed Ina Schieferdecker resolution of CR5092 contains bogus examples for charstring 
related to 0005797closed Ina Schieferdecker BNF for CharStringMatch is inconsistent with description 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
28-11-2010 06:39Andras KovacsNew Issue
28-11-2010 06:39Andras KovacsClause Reference(s) => [Part 1: TTCN-3 Core Language /Annex B.1.5.2 ]
28-11-2010 06:39Andras KovacsSource (company - Author) => BroadBit - Andras Kovacs
29-11-2010 13:06Jacob Wieland - SpirentStatusnew => assigned
29-11-2010 13:06Jacob Wieland - SpirentAssigned To => Jacob Wieland - Spirent
29-11-2010 13:32Jacob Wieland - SpirentNote Added: 0009828
29-11-2010 15:51Jacob Wieland - SpirentRelationship addedrelated to 0005797
29-11-2010 15:53Jacob Wieland - SpirentRelationship addedrelated to 0005805
29-11-2010 15:54Jacob Wieland - SpirentRelationship addedrelated to 0005513
30-11-2010 09:33Ina SchieferdeckerProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
01-12-2010 10:46Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Ina Schieferdecker
01-12-2010 11:03Ina SchieferdeckerNote Added: 0009887
01-12-2010 11:03Ina SchieferdeckerStatusassigned => resolved
01-12-2010 11:03Ina SchieferdeckerResolutionopen => fixed
01-12-2010 11:03Ina SchieferdeckerFixed in Version => Edition 4.3.1 (not yet published)
01-12-2010 11:03Ina SchieferdeckerTarget Version => Edition 4.3.1 (not yet published)
01-12-2010 14:39Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009828) +
+ Jacob Wieland - Spirent    +
+ 29-11-2010 13:32    +
+ 		+ + + + +
+ I propose to change the BNF rule
+
+CharStringMatch ::= PatternKeyword Pattern {"&" (Pattern | ReferencedValue)}
+
+to
+
+CharStringMatch ::= PatternKeyword PatternParticle {"&" PatternParticle}
+PatternParticle ::= Pattern | ReferencedValue
+
+
+
+ + + + + + + + + + +
+ (0009887) +
+ Ina Schieferdecker    +
+ 01-12-2010 11:03    +
+ 		+ + + + +
+ As proposed.
+
+ + diff --git a/docs/mantis/CR5833.md b/docs/mantis/CR5833.md new file mode 100644 index 0000000000000000000000000000000000000000..c307736a2a0678f99e85f4e715455c554db4cbaa --- /dev/null +++ b/docs/mantis/CR5833.md @@ -0,0 +1,408 @@ + + + + + + + + + + + + + 0005833: repeat should be allowed in defaults active during interleave - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005833Part 01: TTCN-3 Core LanguageNew Featurepublic29-11-2010 11:3426-09-2011 14:13
ReporterJacob Wieland - Spirent 
Assigned ToIna Schieferdecker 
PrioritylowSeveritymajorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.3.2 (interim 2011)Fixed in Versionv4.4.1 (published 2012-04) 
Clause Reference(s)20.4
Source (company - Author)Testing Technologies - Jacob Wieland
Summary0005833: repeat should be allowed in defaults active during interleave
DescriptionAt the moment, there are quite a few restrictions on the interleave statement which are due to its semantics being defined as a shorthand notation as an alt-statement.
+
+It should be discussed if these restrictions are really necessary or can be removed or at least lessened to an extent that the interleave statement becomes more usable.
+
+For instance, disallowing repeat inside default alternatives active during an interleave statement makes the whole construct unusable in most (or at least a lot) of real-world examples where some messages/events apart from the expected ones which can arrive in any order need to be dropped so they do not block the port queue for the actually expected messages). This is important at least to the 3GPP STF.
Steps To Reproduce
Additional InformationThe meaning of such a use of repeat would be well-defined even in the interleave-as-alt semantics of the interleave statement. The whole currently active alt-statement (which represents the state of all interleave-branches) would be repeated (as for a repeat in an alt-statement).
+
+Of course, it would make sense to lift the ban on repeat in interleave altogether, too (provided one would also allow an if-construct which does not contain any blocking statements - which also would leave the alt-statement semantics intact).
+
+Take the following example:
+
+I want to receive n messages m1 and m messages m2 (where n and m are parameters, both > 0) in any order.
+
+Suppose, you have a helper function like this:
+
+function inc(inout integer v) return integer {
+  v := v + 1;
+  return v;
+}
+
+Then, at the moment, you would have to do it like this:
+
+var integer receivedM1 := 0, receivedM2 :=0;
+while (receivedM1 < n or receivedM2 < m) {
+  alt {
+  [receivedM1 < n] p.receive(m1) { inc(receivedM1); }
+  [receivedM2 < m] p.receive(m2) { inc(receivedM2); }
+  }
+}
+
+With the interleave and repeat you could do it like this:
+
+interleave {
+[] p.receive(m1) {
+     if (inc(receivedM1) < n) { repeat; }
+   }
+[] p.receive(m2) {
+     if (inc(receivedM2) < m) { repeat; }
+   }
+}
+
+Although the code is not that much shorter, it is not necessary to have an overall condition that needs to be check for every loop
+
+Basically, now it is easy to describe very naturally any interleaving pattern like:
+
+a^n b^m | c^k d^l
+
+where ^x stands for repetition x times and | stands for interleave, while it becomes harder and harder to describe this with pure alt-statements.
+
+Of course, if altsteps were allowed in interleave (which would naturally also not break the alt-statement semantics of interleave), this could be made even easier:
+
+altstep receiveMulti(template T msg,
+                     integer expectedNum,
+                     inout integer received) runs on ... {
+[received < expectedNum]
+  p.receive(msg) {
+    if (inc(received) < expectedNum) { repeat; }
+  }
+}
+
+interleave {
+[] receiveMulti(a, n, receivedA); receiveMulti(b, m, receivedB)
+[] receiveMulti(c, k, receivedC); receiveMulti(d, l, receivedC)
+}
+
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
29-11-2010 11:34Jacob Wieland - SpirentNew Issue
29-11-2010 11:34Jacob Wieland - SpirentClause Reference(s) => 20.4
29-11-2010 11:34Jacob Wieland - SpirentSource (company - Author) => Testing Technologies - Jacob Wieland
29-11-2010 14:27Gyorgy RethyStatusnew => assigned
29-11-2010 14:27Gyorgy RethyAssigned To => Jens Grabowski
30-11-2010 09:30Jacob Wieland - SpirentRelationship addedrelated to 0005807
30-11-2010 09:33Ina SchieferdeckerProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
30-11-2010 15:57Gyorgy RethyNote Added: 0009856
01-12-2010 08:46Gyorgy RethyNote Edited: 0009856
01-12-2010 08:47Gyorgy RethyNote Edited: 0009856
01-12-2010 09:40Jens GrabowskiNote Added: 0009874
01-12-2010 09:43Jens GrabowskiNote Added: 0009875
01-12-2010 09:43Jens GrabowskiAssigned ToJens Grabowski => Jacob Wieland - Spirent
01-12-2010 10:35Jacob Wieland - SpirentNote Added: 0009883
01-12-2010 10:36Jacob Wieland - SpirentStatusassigned => resolved
01-12-2010 10:36Jacob Wieland - SpirentResolutionopen => fixed
01-12-2010 10:37Jacob Wieland - SpirentStatusresolved => feedback
01-12-2010 10:37Jacob Wieland - SpirentResolutionfixed => reopened
01-12-2010 10:37Jacob Wieland - SpirentNote Added: 0009884
01-12-2010 10:37Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Ina Schieferdecker
01-12-2010 10:37Jacob Wieland - SpirentStatusfeedback => resolved
01-12-2010 10:37Jacob Wieland - SpirentAdditional Information Updated
03-12-2010 10:04Gyorgy RethyNote Added: 0009935
03-12-2010 10:04Gyorgy RethyAssigned ToIna Schieferdecker => Jens Grabowski
03-12-2010 10:04Gyorgy RethyStatusresolved => assigned
03-12-2010 10:04Gyorgy RethyPriorityhigh => low
03-12-2010 10:04Gyorgy RethyResolutionreopened => open
03-12-2010 10:04Gyorgy RethyTarget Version => Edition 4.3.2 (interim)
26-05-2011 14:41Gyorgy RethyRelationship deletedrelated to 0005807
26-05-2011 14:42Gyorgy RethyStatusassigned => closed
26-05-2011 14:42Gyorgy RethyNote Added: 0010089
26-05-2011 14:42Gyorgy RethyResolutionopen => fixed
26-05-2011 14:42Gyorgy RethyFixed in Version => Edition 4.3.1 (not yet published)
01-08-2011 11:33Gyorgy RethyAssigned ToJens Grabowski => Ina Schieferdecker
01-08-2011 11:33Gyorgy RethyStatusclosed => feedback
01-08-2011 11:33Gyorgy RethyResolutionfixed => reopened
01-08-2011 11:33Gyorgy RethyNote Added: 0010233
26-09-2011 14:13Ina SchieferdeckerNote Added: 0010234
26-09-2011 14:13Ina SchieferdeckerStatusfeedback => closed
26-09-2011 14:13Ina SchieferdeckerResolutionreopened => fixed
26-09-2011 14:13Ina SchieferdeckerFixed in VersionEdition 4.3.1 => Edition 4.4.1
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009856) +
+ Gyorgy Rethy    +
+ 30-11-2010 15:57    +
(edited on: 01-12-2010 08:47)
+ 		+ + + + +
+ STF discussion on 30-11-2010: repeat is allowed in activated defaults.Add a note clarifying this to Part-1 v4.3.1. All other possible changes to interleave is postponed to 2011.
+
+
+
+
+
+ + + + + + + + + + +
+ (0009874) +
+ Jens Grabowski    +
+ 01-12-2010 09:40    +
+ 		+ + + + +
+ I propose the following resolution:
+
+Change Note 1 in 20.5.1 from
+
+"NOTE 1: An interleave statement is semantically equivalent to a nested set of alt statements and the default mechanism also applies to each of these alt statements. This means, the default mechanism also applies to interleave statements."
+
+to
+
+"NOTE 1: An interleave statement is semantically equivalent to a nested set of alt statements and the default mechanism also applies to each of these alt statements. This means, the default mechanism also applies to interleave statements. Furthermore, the restrictions imposed on interleave statements in Clause 20.4 do not apply to altsteps that are activated as default behaviour for interleave statements."
+
+
+
+ + + + + + + + + + +
+ (0009875) +
+ Jens Grabowski    +
+ 01-12-2010 09:43    +
+ 		+ + + + +
+ Jacob, please proofread proposal.
+
+
+
+ + + + + + + + + + +
+ (0009883) +
+ Jacob Wieland - Spirent    +
+ 01-12-2010 10:35    +
+ 		+ + + + +
+ Proposal is fine.
+
+
+
+ + + + + + + + + + +
+ (0009884) +
+ Jacob Wieland - Spirent    +
+ 01-12-2010 10:37    +
+ 		+ + + + +
+ ina, please set this to resolved
+
+
+
+ + + + + + + + + + +
+ (0009935) +
+ Gyorgy Rethy    +
+ 03-12-2010 10:04    +
+ 		+ + + + +
+ Discussion on interleave restrictions is postponed to 2011, in v4.3.1 only use of repeat in activated defaults has to be clarified.
+
+
+
+ + + + + + + + + + +
+ (0010089) +
+ Gyorgy Rethy    +
+ 26-05-2011 14:42    +
+ 		+ + + + +
+ Implemented.
+
+
+
+ + + + + + + + + + +
+ (0010233) +
+ Gyorgy Rethy    +
+ 01-08-2011 11:33    +
+ 		+ + + + +
+ Addition to Note1 of $20.5.1 is missing in v4.3.1 (and therefore from v4.3.2)
+
+
+
+ + + + + + + + + + +
+ (0010234) +
+ Ina Schieferdecker    +
+ 26-09-2011 14:13    +
+ 		+ + + + +
+ I was taking the note by Jacob literally to close the CR ;-) Note is now extended as proposed.
+
+ + diff --git a/docs/mantis/CR5834.md b/docs/mantis/CR5834.md new file mode 100644 index 0000000000000000000000000000000000000000..1f097cfb72f65e7c81b70f78d7122f8a934fb706 --- /dev/null +++ b/docs/mantis/CR5834.md @@ -0,0 +1,84 @@ + + + + + + + + + + + + + 0005834: Enumeration values are of local scope - example is to be corrected - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005834Part 01: TTCN-3 Core LanguageEditorialpublic30-11-2010 15:3701-12-2010 16:51
ReporterIna Schieferdecker 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.3.1 (published 2011-06)Fixed in Versionv4.3.1 (published 2011-06) 
Clause Reference(s)6.2.4 Example 1
Source (company - Author)Ina Schieferdecker, FOKUS
Summary0005834: Enumeration values are of local scope - example is to be corrected
DescriptionDue to the local scope of enumeration values the two definitions do not clash any more:
+
+    type enumerated MyFirstEnumType {
+        Monday, Tuesday, Wednesday, Thursday, Friday
+    };
+
+    type integer Monday;
+    // This definition causes an error as the name of the type has local or global visibility
+
+Anyhow, the comment would have to be corrected.
+
+Proposal is:
+
+    type enumerated MyFirstEnumType {
+        Monday, Tuesday, Wednesday, Thursday, Friday
+    };
+
+    type integer Monday;
+    // This definition does not clash with the previous one as Monday in MyFirstEnumType is of local scope
+
+This relates to the resolution in CR 5553
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0005553closed Ina Schieferdecker Interpretation of import mechanism 
related to 0005996closed Ina Schieferdecker Correct const enumerated example the same way as the type example 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
30-11-2010 15:37Ina SchieferdeckerNew Issue
30-11-2010 15:37Ina SchieferdeckerClause Reference(s) => 6.2.4 Example 1
30-11-2010 15:37Ina SchieferdeckerSource (company - Author) => Ina Schieferdecker, FOKUS
30-11-2010 15:38Ina SchieferdeckerRelationship addedrelated to 0005553
30-11-2010 15:38Ina SchieferdeckerProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
30-11-2010 17:37Gyorgy RethyAssigned To => Ina Schieferdecker
30-11-2010 17:37Gyorgy RethyStatusnew => assigned
30-11-2010 17:37Gyorgy RethyTarget Version => Edition 4.3.1 (not yet published)
01-12-2010 16:36Gyorgy RethyNote Added: 0009903
01-12-2010 16:51Ina SchieferdeckerStatusassigned => resolved
01-12-2010 16:51Ina SchieferdeckerResolutionopen => fixed
01-12-2010 16:51Ina SchieferdeckerFixed in Version => Edition 4.3.1 (not yet published)
01-12-2010 16:51Ina SchieferdeckerStatusresolved => closed
09-08-2012 13:46Ina SchieferdeckerRelationship addedrelated to 0005996
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009903) +
+ Gyorgy Rethy    +
+ 01-12-2010 16:36    +
+ 		+ + + + +
+ Proposal is OK with me.
+
+ + diff --git a/docs/mantis/CR5835.md b/docs/mantis/CR5835.md new file mode 100644 index 0000000000000000000000000000000000000000..cab21009a7486dbc88bbadf10bb8701bd5f56de4 --- /dev/null +++ b/docs/mantis/CR5835.md @@ -0,0 +1,98 @@ + + + + + + + + + + + + + 0005835: BNF rule for PatternElement is ambiguous, Example is wrong - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005835Part 01: TTCN-3 Core LanguageTechnicalpublic30-11-2010 17:1201-12-2010 16:46
ReporterGyorgy Rethy 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.3.1 (published 2011-06)Fixed in Versionv4.3.1 (published 2011-06) 
Clause Reference(s)B.1.5.2, A.1.6.1.3
Source (company - Author)Testing Technologies - Jacob Wieland
Summary0005835: BNF rule for PatternElement is ambiguous, Example is wrong
DescriptionIn 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
TagsNo tags attached.
Relationships
child of 0005805closed Ina Schieferdecker BNF rule for PatternElement is ambiguous, Example is wrong 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
30-11-2010 17:12Gyorgy RethyNew Issue
30-11-2010 17:12Gyorgy RethyStatusnew => assigned
30-11-2010 17:12Gyorgy RethyAssigned To => Ina Schieferdecker
30-11-2010 17:12Gyorgy RethyClause Reference(s) => B.1.5.2, A.1.6.1.3
30-11-2010 17:12Gyorgy RethySource (company - Author) => Testing Technologies - Jacob Wieland
30-11-2010 17:12Gyorgy RethyIssue generated from: 0005805
30-11-2010 17:12Gyorgy RethyRelationship addedchild of 0005805
01-12-2010 16:44Ina SchieferdeckerNote Added: 0009904
01-12-2010 16:46Ina SchieferdeckerStatusassigned => resolved
01-12-2010 16:46Ina SchieferdeckerResolutionopen => fixed
01-12-2010 16:46Ina SchieferdeckerFixed in Version => Edition 4.3.1 (not yet published)
01-12-2010 16:46Ina SchieferdeckerTarget Version => Edition 4.3.1 (not yet published)
01-12-2010 16:46Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009904) +
+ Ina Schieferdecker    +
+ 01-12-2010 16:44    +
+ 		+ + + + +
+ Example corrected as proposed. In addition, RegExp7 removed as this is part of Example 2 and not of Example 3.
+
+ + diff --git a/docs/mantis/CR5838.md b/docs/mantis/CR5838.md new file mode 100644 index 0000000000000000000000000000000000000000..40ed3c46ade88798d835677012fedb141d537e32 --- /dev/null +++ b/docs/mantis/CR5838.md @@ -0,0 +1,168 @@ + + + + + + + + + + + + + 0005838: Specify encoding and decoding processes for anyElement and anyAttribute - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005838Part 09: Using XML with TTCN-3Technicalpublic01-12-2010 14:5902-12-2010 08:07
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeveritymajorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.3.1 (published 2011-06)Fixed in Versionv4.3.1 (published 2011-06) 
Clause Reference(s)B.3.2 and B.3.3
For STF discussion
Source (company - Author)L.M.Ericsson
Summary0005838: Specify encoding and decoding processes for anyElement and anyAttribute
DescriptionThe encoding instructions anyElement and anyAttribute are defined but it is not clear how they effect the encoding and the decoding processes.
Steps To Reproduce
Additional InformationIt is proposed to add the text to B.3.2 (B.3.3 references B.3.3, therefore no text has to be added to B.3.3):
+In the encoding process the content of the TTCN-3 value shall be handled transparently, except when maxOccurs is greater than 1: in this case the elements of the TTCN-3 record of value (corresponding to the any XSD element), shall be concatenated transparently to produce the encoded XML value.
+In the decoding process, the decoder shall check if the fragment of the received XML document corresponding to the TTCN 3 field with the "anyElement" encoding instruction fulfils the namespace specification in the encoding instruction and is a well-formed XML (i.e. the content shall be assessed according to XML Schema Part 1 [8] clause 3.10.1, assesment level skip. The failure of the namespace checking or the content assessment shall cause a decoding failure.
+
TagsNo tags attached.
Relationships
Attached Filesdoc CR5838_resolution.doc (68,608) 02-12-2010 08:06
http://oldforge.etsi.org/mantis/file_download.php?file_id=2461&type=bug
Issue History
Date ModifiedUsernameFieldChange
01-12-2010 14:59Gyorgy RethyNew Issue
01-12-2010 14:59Gyorgy RethyClause Reference(s) => B.3.2 and B.3.3
01-12-2010 14:59Gyorgy RethySource (company - Author) => L.M.Ericsson
01-12-2010 15:02Gyorgy RethyAssigned To => Gyorgy Rethy
01-12-2010 15:02Gyorgy RethyStatusnew => assigned
01-12-2010 15:02Gyorgy RethyTarget Version => Edition 4.3.1 (not yet published)
01-12-2010 15:02Gyorgy RethyAdditional Information Updated
01-12-2010 15:02Gyorgy RethyNote Added: 0009899
01-12-2010 15:03Gyorgy RethyAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
01-12-2010 15:10Jacob Wieland - SpirentNote Added: 0009900
01-12-2010 15:10Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
01-12-2010 15:20Gyorgy RethyStatusassigned => closed
01-12-2010 15:20Gyorgy RethyResolutionopen => fixed
01-12-2010 15:20Gyorgy RethyFixed in Version => Edition 4.3.1 (not yet published)
02-12-2010 08:06Gyorgy RethyStatusclosed => feedback
02-12-2010 08:06Gyorgy RethyResolutionfixed => reopened
02-12-2010 08:06Gyorgy RethyNote Added: 0009911
02-12-2010 08:06Gyorgy RethyFile Added: CR5838_resolution.doc
02-12-2010 08:07Gyorgy RethyStatusfeedback => closed
02-12-2010 08:07Gyorgy RethyNote Added: 0009912
02-12-2010 08:07Gyorgy RethyResolutionreopened => fixed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009899) +
+ Gyorgy Rethy    +
+ 01-12-2010 15:02    +
+ 		+ + + + +
+ Proposed to accept according to the proposal.
+
+
+
+ + + + + + + + + + +
+ (0009900) +
+ Jacob Wieland - Spirent    +
+ 01-12-2010 15:10    +
+ 		+ + + + +
+ agreed
+
+
+
+ + + + + + + + + + +
+ (0009911) +
+ Gyorgy Rethy    +
+ 02-12-2010 08:06    +
+ 		+ + + + +
+ resolution text uploaded.
+
+
+
+ + + + + + + + + + +
+ (0009912) +
+ Gyorgy Rethy    +
+ 02-12-2010 08:07    +
+ 		+ + + + +
+ Done.
+
+ + diff --git a/docs/mantis/CR5839.md b/docs/mantis/CR5839.md new file mode 100644 index 0000000000000000000000000000000000000000..760718d0a795a91b608d5867e5b49d50594fb242 --- /dev/null +++ b/docs/mantis/CR5839.md @@ -0,0 +1,75 @@ + + + + + + + + + + + + + 0005839: Definition "in the context of a type" should be in clause 3.1 - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005839Part 01: TTCN-3 Core LanguageEditorialpublic04-12-2010 08:1201-07-2011 14:49
ReporterGyorgy Rethy 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.3.2 (interim 2011)Fixed in Versionv4.3.2 (interim 2011) 
Clause Reference(s)6.2.4, 8.2.3
Source (company - Author)L.M.Ericsson
Summary0005839: Definition "in the context of a type" should be in clause 3.1
DescriptionLooking at the new note on "in the context" in clause 6.2.4, in fact it is a definition of a term that we use in this clause and referencing from clause 8.2.3. Therefore as such, should be moved to clause 3.1 Definitions.
+
+Today ($6.2.4)
+-------------------
+NOTE: “In the context” means that at least one object involved in the given TTCN-3 action (an assignment, operation, parameter passing etc.) shall identify a concrete type unambiguously, i.e. either directly (e.g. an in-line template) or by means of a typed TTCN-3 object (e.g. via a constant, variable, formal parameter etc.).
+-------------------
+
+Proposed ($3.1)
+-------------------
+type context: “In the context of a type” means that at least one object involved in the given TTCN-3 action (an assignment, operation, parameter passing etc.) shall identify a concrete type unambiguously, i.e. either directly (e.g. an in-line template) or by means of a typed TTCN-3 object (e.g. via a constant, variable, formal parameter etc.).
+-------------------
+
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
04-12-2010 08:12Gyorgy RethyNew Issue
04-12-2010 08:12Gyorgy RethyClause Reference(s) => 6.2.4, 8.2.3
04-12-2010 08:12Gyorgy RethySource (company - Author) => L.M.Ericsson
13-12-2010 12:44Gyorgy RethyTarget Version => Edition 4.3.2 (interim)
24-05-2011 15:29Gyorgy RethyAssigned To => Ina Schieferdecker
24-05-2011 15:29Gyorgy RethyStatusnew => assigned
24-05-2011 15:29Gyorgy RethyNote Added: 0010030
25-05-2011 15:21Ina SchieferdeckerStatusassigned => resolved
25-05-2011 15:21Ina SchieferdeckerResolutionopen => fixed
01-07-2011 14:49Ina SchieferdeckerStatusresolved => closed
01-07-2011 14:49Ina SchieferdeckerFixed in Version => Edition 4.3.2 (interim)
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010030) +
+ Gyorgy Rethy    +
+ 24-05-2011 15:29    +
+ 		+ + + + +
+ Agreed as proposed.
+
+ + diff --git a/docs/mantis/CR5840.md b/docs/mantis/CR5840.md new file mode 100644 index 0000000000000000000000000000000000000000..96cd1a56c1bfda77a8d139f1a82facf91adb4410 --- /dev/null +++ b/docs/mantis/CR5840.md @@ -0,0 +1,135 @@ + + + + + + + + + + + + + 0005840: Remove ASN.1 ANY DEFINED BY from the mapping lists - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 08: Using IDL with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005840Part 08: Using IDL with TTCN-3Technicalpublic06-12-2010 11:1115-12-2011 14:38
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.4.1 (published 2012-04)Fixed in Versionv4.4.1 (published 2012-04) 
Clause Reference(s)B.2
Source (company - Author)L.M.Ericsson
Summary0005840: Remove ASN.1 ANY DEFINED BY from the mapping lists
DescriptionInformative Annex B Table B.2 compares IDL, ASN.1, TTCN-2 and TTCN-3 data types. For IDL any, ASN.1 ANY DEFINED BY is mentioned as equivalent, though ANY DEFINED BY is not supported by ASN.1 from ASN.1(2002). Therefore it should be removed from the table.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
06-12-2010 11:11Gyorgy RethyNew Issue
06-12-2010 11:11Gyorgy RethyClause Reference(s) => B.2
06-12-2010 11:11Gyorgy RethySource (company - Author) => L.M.Ericsson
13-12-2010 12:45Gyorgy RethyTarget Version => Edition 4.3.2 (interim)
24-05-2011 15:26Gyorgy RethyAssigned To => Gyorgy Rethy
24-05-2011 15:26Gyorgy RethyStatusnew => assigned
24-05-2011 15:26Gyorgy RethyTarget VersionEdition 4.3.2 (interim) => Edition 4.4.1
24-05-2011 19:24Gyorgy RethyNote Added: 0010041
24-05-2011 19:24Gyorgy RethyTarget VersionEdition 4.4.1 => Edition 4.3.2 (interim)
24-05-2011 19:25Gyorgy RethyTarget VersionEdition 4.3.2 (interim) => Edition 4.4.1
24-05-2011 19:27Gyorgy RethyTarget VersionEdition 4.4.1 => Edition 4.3.2 (interim)
25-05-2011 15:52Gyorgy RethyNote Edited: 0010041
25-05-2011 15:52Gyorgy RethyStatusassigned => resolved
25-05-2011 15:52Gyorgy RethyFixed in Version => Edition 4.3.2 (interim)
25-05-2011 15:52Gyorgy RethyResolutionopen => fixed
27-09-2011 14:02Gyorgy RethyStatusresolved => feedback
27-09-2011 14:02Gyorgy RethyResolutionfixed => reopened
27-09-2011 14:02Gyorgy RethyNote Added: 0010247
27-09-2011 14:02Gyorgy RethyNote Edited: 0010247
27-09-2011 14:03Gyorgy RethyStatusfeedback => resolved
27-09-2011 14:03Gyorgy RethyResolutionreopened => fixed
27-09-2011 14:03Gyorgy RethyFixed in VersionEdition 4.3.2 (interim) =>
27-09-2011 14:03Gyorgy RethyTarget VersionEdition 4.3.2 (interim) => Edition 4.4.1
15-12-2011 14:38Gyorgy RethyStatusresolved => closed
15-12-2011 14:38Gyorgy RethyNote Added: 0010532
15-12-2011 14:38Gyorgy RethyFixed in Version => Edition 4.4.1
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010041) +
+ Gyorgy Rethy    +
+ 24-05-2011 19:24    +
(edited on: 25-05-2011 15:52)
+ 		+ + + + +
+ Remove as proposed. Actually, implementation shall be postponed until the published version of v4.3.1 is received.
+
+
+
+
+
+ + + + + + + + + + +
+ (0010247) +
+ Gyorgy Rethy    +
+ 27-09-2011 14:02    +
+ 		+ + + + +
+ Changing target version to v4.4.1
+
+
+
+
+
+ + + + + + + + + + +
+ (0010532) +
+ Gyorgy Rethy    +
+ 15-12-2011 14:38    +
+ 		+ + + + +
+ Implemented.
+
+ + diff --git a/docs/mantis/CR5842.md b/docs/mantis/CR5842.md new file mode 100644 index 0000000000000000000000000000000000000000..de1ed107f9ce6d31b12d6431660c45815c4efe5f --- /dev/null +++ b/docs/mantis/CR5842.md @@ -0,0 +1,168 @@ + + + + + + + + + + + + + 0005842: Support of the processContents attribute - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005842Part 09: Using XML with TTCN-3New Featurepublic06-12-2010 15:5213-07-2011 14:31
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Clause Reference(s)7.7, B.3.2
For STF discussion
Source (company - Author)L.M.Ericsson
Summary0005842: Support of the processContents attribute
DescriptionCurrently the processContents attribute is not supported. For example in case of any (elements) decoding defaults to the value "skip". This means that the content is just syntax-checked and namespace constraint is checked, but the content is not decoded (passed as XSD.String to the TTCN-3 code). However, in case of an available XSD schema for the content, it could also be automatically be decoded (i.e. the schema shall be available when the whole XML Schema is translated) and passed to the TTCN-3 code as structured data - provided the decoding is successful (e.g. any should be converted to a union of XSD.Schema and one or more alternatives for decoded struktured types). In this way the intention of the Schema author can be followed more closely (there can ba a reason if e.g. the strict processContents attribute is specified). Possibilities to add this feature should be considered.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR5842_resolution_v1.doc (146,432) 27-05-2011 11:32
http://oldforge.etsi.org/mantis/file_download.php?file_id=2515&type=bug
Issue History
Date ModifiedUsernameFieldChange
06-12-2010 15:52Gyorgy RethyNew Issue
06-12-2010 15:52Gyorgy RethyClause Reference(s) => 7.7, B.3.2
06-12-2010 15:52Gyorgy RethySource (company - Author) => L.M.Ericsson
06-12-2010 15:53Gyorgy RethyTarget Version => Edition 4.3.2 (interim)
24-05-2011 15:18Gyorgy RethyNote Added: 0010029
24-05-2011 15:18Gyorgy RethyAssigned To => Gyorgy Rethy
24-05-2011 15:18Gyorgy RethyStatusnew => assigned
27-05-2011 11:32Gyorgy RethyFile Added: CR5842_resolution_v1.doc
27-05-2011 11:32Gyorgy RethyNote Added: 0010095
27-05-2011 11:33Gyorgy RethyNote Edited: 0010029
27-05-2011 11:51Gyorgy RethyAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
27-05-2011 12:28Jacob Wieland - SpirentNote Added: 0010098
27-05-2011 12:28Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
27-05-2011 12:30Gyorgy RethyStatusassigned => resolved
27-05-2011 12:30Gyorgy RethyResolutionopen => fixed
13-07-2011 14:31Gyorgy RethyStatusresolved => closed
13-07-2011 14:31Gyorgy RethyNote Added: 0010216
13-07-2011 14:31Gyorgy RethyFixed in Version => Edition 4.3.2 (interim)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010029) +
+ Gyorgy Rethy    +
+ 24-05-2011 15:18    +
(edited on: 27-05-2011 11:33)
+ 		+ + + + +
+ Remaining from last years's CR .
+Take over the semantics from XSD: write the text for this.
+
+
+
+
+
+ + + + + + + + + + +
+ (0010095) +
+ Gyorgy Rethy    +
+ 27-05-2011 11:32    +
+ 		+ + + + +
+ File CR5842_resolution_v1.doc contains proposed resolution of this CR. Jacob, pls. review.
+
+
+
+ + + + + + + + + + +
+ (0010098) +
+ Jacob Wieland - Spirent    +
+ 27-05-2011 12:28    +
+ 		+ + + + +
+ Looks ok to me.
+
+
+
+ + + + + + + + + + +
+ (0010216) +
+ Gyorgy Rethy    +
+ 13-07-2011 14:31    +
+ 		+ + + + +
+ Added to master copy.
+
+ + diff --git a/docs/mantis/CR5843.md b/docs/mantis/CR5843.md new file mode 100644 index 0000000000000000000000000000000000000000..6079e5c744c1e7a4385eedbb21ca9f407fce747c --- /dev/null +++ b/docs/mantis/CR5843.md @@ -0,0 +1,63 @@ + + + + + + + + + + + + + 0005843: Definition is missing in example - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005843Part 09: Using XML with TTCN-3Editorialpublic07-12-2010 12:1107-12-2010 12:20
ReporterGyorgy Rethy 
Assigned To 
PrioritylowSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.1.1 (published 2009-06) 
Target Versionv4.3.1 (published 2011-06)Fixed in Versionv4.3.1 (published 2011-06) 
Clause Reference(s)7.6.2.1
For STF discussion
Source (company - Author)L.M.Ericsson
Summary0005843: Definition is missing in example
DescriptionIn exampe 2 of $7.6.2.1 ns:g25cho is referred to but the definition is missing.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
07-12-2010 12:11Gyorgy RethyNew Issue
07-12-2010 12:11Gyorgy RethyClause Reference(s) => 7.6.2.1
07-12-2010 12:11Gyorgy RethySource (company - Author) => L.M.Ericsson
07-12-2010 12:20Gyorgy RethyNote Added: 0009941
07-12-2010 12:20Gyorgy RethyStatusnew => closed
07-12-2010 12:20Gyorgy RethyResolutionopen => fixed
07-12-2010 12:20Gyorgy RethyFixed in Version => Edition 4.3.1 (not yet published)
07-12-2010 12:20Gyorgy RethyTarget Version => Edition 4.3.1 (not yet published)
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009941) +
+ Gyorgy Rethy    +
+ 07-12-2010 12:20    +
+ 		+ + + + +
+ Corerct refrerence shall be to ns:g25seq. Corrected.
+
+ + diff --git a/docs/mantis/CR5844.md b/docs/mantis/CR5844.md new file mode 100644 index 0000000000000000000000000000000000000000..1747fe9e2887842beeeef6009fd9fc6f838c0979 --- /dev/null +++ b/docs/mantis/CR5844.md @@ -0,0 +1,79 @@ + + + + + + + + + + + + + 0005844: Wrong example6 - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005844Part 09: Using XML with TTCN-3Editorialpublic07-12-2010 13:3807-12-2010 13:39
ReporterGyorgy Rethy 
Assigned To 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.3.1 (published 2011-06)Fixed in Versionv4.3.1 (published 2011-06) 
Clause Reference(s)7.6.2.1
For STF discussion
Source (company - Author)L.M.Ericsson
Summary0005844: Wrong example6
DescriptionIn example 6 now:
+------------------------
+<extension base="ns:X"/>
+    <sequence>
+        <element name="z" type="string"/>
+    </sequence>
+</extension>
+------------------------
+should be:
+------------------------
+<extension base="ns:X">
+    <sequence>
+        <element name="z" type="string"/>
+    </sequence>
+</extension>
+------------------------
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
07-12-2010 13:38Gyorgy RethyNew Issue
07-12-2010 13:38Gyorgy RethyClause Reference(s) => 7.6.2.1
07-12-2010 13:38Gyorgy RethySource (company - Author) => L.M.Ericsson
07-12-2010 13:39Gyorgy RethyNote Added: 0009942
07-12-2010 13:39Gyorgy RethyStatusnew => closed
07-12-2010 13:39Gyorgy RethyResolutionopen => fixed
07-12-2010 13:39Gyorgy RethyFixed in Version => Edition 4.3.1 (not yet published)
07-12-2010 13:39Gyorgy RethyTarget Version => Edition 4.3.1 (not yet published)
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009942) +
+ Gyorgy Rethy    +
+ 07-12-2010 13:39    +
+ 		+ + + + +
+ Corercted.
+
+ + diff --git a/docs/mantis/CR5845.md b/docs/mantis/CR5845.md new file mode 100644 index 0000000000000000000000000000000000000000..cd8b7ec7c5c648d659a7e3f92fd38b7b750269c0 --- /dev/null +++ b/docs/mantis/CR5845.md @@ -0,0 +1,74 @@ + + + + + + + + + + + + + 0005845: BNF does not allow indentificator after keyword pattern - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005845Part 01: TTCN-3 Core LanguageClarificationpublic08-12-2010 11:1624-05-2011 15:15
ReporterBenjamin Zeiss 
Assigned To 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionwon't fix 
PlatformOSOS Version
Product Version 
Target Versionv4.3.2 (interim 2011)Fixed in Version 
Clause Reference(s)Annex B /1.5.2
Source (company - Author)     
Summary0005845: BNF does not allow indentificator after keyword pattern
DescriptionThis issue points to the contradiction between BNF and the examples given in section Annex B /1.5.2 of the standard.
+
+BNF:
+124. CharStringMatch ::= PatternKeyword Pattern {"&" (Pattern | ReferencedValue)}
+125. PatternKeyword ::= "pattern"
+126. Pattern ::= """ { PatternElement } """
+
+Incorrect: field1 := pattern v_Ref
+Correct: field1 := pattern "{v_Ref}"
+
+Related STF409 issue reported by Elvior:
+http://t-ort.etsi.org/view.php?id=5820 [^]
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
08-12-2010 11:16Benjamin ZeissNew Issue
08-12-2010 11:16Benjamin ZeissClause Reference(s) => Annex B /1.5.2
08-12-2010 11:16Benjamin ZeissSource (company - Author) =>
13-12-2010 12:40Gyorgy RethyProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
13-12-2010 12:45Gyorgy RethyTarget Version => Edition 4.3.2 (interim)
24-05-2011 15:15Gyorgy RethyNote Added: 0010028
24-05-2011 15:15Gyorgy RethyStatusnew => closed
24-05-2011 15:15Gyorgy RethyResolutionopen => won't fix
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010028) +
+ Gyorgy Rethy    +
+ 24-05-2011 15:15    +
+ 		+ + + + +
+ The issue has been solved already in the newest version (v4.3.1)
+
+ + diff --git a/docs/mantis/CR5847.md b/docs/mantis/CR5847.md new file mode 100644 index 0000000000000000000000000000000000000000..ee6a1b14f4db757db7451059bb97bd3202f720d1 --- /dev/null +++ b/docs/mantis/CR5847.md @@ -0,0 +1,230 @@ + + + + + + + + + + + + + 0005847: Name Conversion rule and examples in XSD-Mapping are inconsistent (and results unreadable) - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005847Part 09: Using XML with TTCN-3Technicalpublic10-12-2010 12:3813-07-2011 16:12
ReporterJacob Wieland - Spirent 
Assigned ToGyorgy Rethy 
PriorityhighSeveritymajorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Clause Reference(s)XSD Language Mapping, section 5.1.1 and 5.2.2
For STF discussion
Source (company - Author)Testing Technologies - Jacob Wieland
Summary0005847: Name Conversion rule and examples in XSD-Mapping are inconsistent (and results unreadable)
DescriptionAccording to section 5.1.1 the Name Conversion rule (section 5.2.2) is to be applied to namespace names (or if not present, the identifier NoTargetNamespace) to derive TTCN-3 module names.
+
+There, all characters except alphanumeric, space (which actually is not allowed in XML names), hyphen, full stop and underscore are to be removed (rule c)).
+
+However, namespaces in most cases also contain colon and slash characters to provide structure to the name.
+
+If the conversion rule would be applied to
+
+"www.org.example/1" this would become "www_org_example1" while
+"http://www.w3.org/2001/XMLSchema" [^] would become "httpwww_w3_org2001XmlSchema"
+
+Though shorter, these names are far less readable than if the other characters that may occur in namespace-uris would also be replaced by underscore in rule b)
+
+(www_org_example_1 and http_www_w3_org_2001_XmlSchema)
+
+Most examples that map full schemas seem to assume that at least the / character is also replaced by _.
+
+In section 5.1.1 the example strips the http from the namespace, as well which is also inconsistent with the conversion rule.
+
+The examples in annex C also disregard the namespace-to-module conversion rule as most of them would then have the name NoTargetNamespace.
+
+SOLUTION PROPOSAL:
+
+treat all non-alphanumeric name-characters equally in rule b) of 5.2.2 and remove rule c)
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Fileszip es_20187309v040203.zip (279,881) 13-04-2011 10:44
http://oldforge.etsi.org/mantis/file_download.php?file_id=2475&type=bug
doc CR5847_resolution_v2.doc (1,433,600) 25-05-2011 17:26
http://oldforge.etsi.org/mantis/file_download.php?file_id=2494&type=bug
Issue History
Date ModifiedUsernameFieldChange
10-12-2010 12:38Jacob Wieland - SpirentNew Issue
10-12-2010 12:38Jacob Wieland - SpirentClause Reference(s) => XSD Language Mapping, section 5.1.1 and 5.2.2
10-12-2010 12:38Jacob Wieland - SpirentSource (company - Author) => Testing Technologies - Jacob Wieland
10-12-2010 12:50Jacob Wieland - SpirentDescription Updated
13-12-2010 12:46Gyorgy RethyProjectTTCN-3 Change Requests => Part 09: Using XML with TTCN-3
13-12-2010 12:47Gyorgy RethyTarget Version => Edition 4.3.2 (interim)
13-04-2011 10:44Gyorgy RethyFile Added: es_20187309v040203.zip
13-04-2011 10:48Gyorgy RethyNote Added: 0009995
13-04-2011 10:50Gyorgy RethyNote Edited: 0009995
13-05-2011 10:32Gyorgy RethyStatusnew => assigned
13-05-2011 10:32Gyorgy RethyAssigned To => Gyorgy Rethy
24-05-2011 19:23Gyorgy RethyPrioritynormal => high
25-05-2011 16:54Gyorgy RethyNote Added: 0010067
25-05-2011 16:55Gyorgy RethyAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
25-05-2011 16:56Gyorgy RethyNote Edited: 0009995
25-05-2011 17:20Jacob Wieland - SpirentNote Added: 0010069
25-05-2011 17:20Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
25-05-2011 17:26Gyorgy RethyFile Added: CR5847_resolution_v2.doc
25-05-2011 17:28Gyorgy RethyStatusassigned => resolved
25-05-2011 17:28Gyorgy RethyResolutionopen => fixed
25-05-2011 17:28Gyorgy RethyNote Added: 0010070
13-07-2011 16:12Gyorgy RethyStatusresolved => closed
13-07-2011 16:12Gyorgy RethyNote Added: 0010218
13-07-2011 16:12Gyorgy RethyFixed in Version => Edition 4.3.2 (interim)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009995) +
+ Gyorgy Rethy    +
+ 13-04-2011 10:48    +
(edited on: 25-05-2011 16:56)
+ 		+ + + + +
+ 3GPP related CR.
+The file es_20187309v040203.zip contains a proposed resolution based on TB MTS's decision, i.e. resolve the issue according to MTS(11)0028r1 option b). The changes are applied to the input document es_20187310v040202m.doc, i.e. the document version for ETSI member vote. Consequently, all changes shall be re-implemented in the published version of v4.3.1 by STF VO.
+
+
+
+
+
+ + + + + + + + + + +
+ (0010067) +
+ Gyorgy Rethy    +
+ 25-05-2011 16:54    +
+ 		+ + + + +
+ Jacob, pls. review.
+
+
+
+ + + + + + + + + + +
+ (0010069) +
+ Jacob Wieland - Spirent    +
+ 25-05-2011 17:20    +
+ 		+ + + + +
+ Page 81, organization -> example, wildard -> wildcards
+
+Page 106, targetnamespace of module missing, therefor module must be named NoTargetNamespace (or the right targetnamespace added)
+
+Same is true for Example2.
+
+
+
+ + + + + + + + + + +
+ (0010070) +
+ Gyorgy Rethy    +
+ 25-05-2011 17:28    +
+ 		+ + + + +
+ Jacob's comments are corrected in file CR5847_resolution_v2.doc
+
+
+
+ + + + + + + + + + +
+ (0010218) +
+ Gyorgy Rethy    +
+ 13-07-2011 16:12    +
+ 		+ + + + +
+ Added to master copy.
+
+ + diff --git a/docs/mantis/CR5848.md b/docs/mantis/CR5848.md new file mode 100644 index 0000000000000000000000000000000000000000..28276a1d56e17551f85b6b99f14220cb5689ae0f --- /dev/null +++ b/docs/mantis/CR5848.md @@ -0,0 +1,223 @@ + + + + + + + + + + + + + 0005848: String content of anyAttribute values unspecified - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005848Part 09: Using XML with TTCN-3Clarificationpublic10-12-2010 14:3413-07-2011 14:56
ReporterJacob Wieland - Spirent 
Assigned ToGyorgy Rethy 
PriorityhighSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Clause Reference(s)XSD to TTCN-3 Mapping, section 7.7
For STF discussion
Source (company - Author)Testing Technologies - Jacob Wieland
Summary0005848: String content of anyAttribute values unspecified
DescriptionIn clause 7.7 it is described that anyAttributes schema-elements shall be mapped to a record of XSD.String field named 'attr' (with additional name conversion for nameclashes). Unfortunately, it is totally unspecified what the content of the decoded strings shall be, i.e. what format it shall have, since it needs to contain both the information about WHICH attribute is set and the value.
+
+Two solutions come to mind:
+
+Change the definition to something more on the line of:
+
+  record of record { XSD.String name, XSD.String val } attr
+
+or adding a type in XSD:
+
+  type record AnyAttribute { String name, String val }
+
+and then using that type:
+
+  record of XSD.AnyAttribute attr
+
+If, on the other hand, the intention of the standard is that the record of XSD.String shall be a flattened list of pairs of strings (i.e. for attr1="val1" attr2="val2" that you get the list { "attr1", "val1", "attr2", "val2" }, it should explicitly say so.
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR5848_resolution_v1.doc (199,168) 26-05-2011 17:35
http://oldforge.etsi.org/mantis/file_download.php?file_id=2513&type=bug
doc CR5848_resolution_v2.doc (99,840) 27-05-2011 11:49
http://oldforge.etsi.org/mantis/file_download.php?file_id=2516&type=bug
doc CR5848_resolution_v3.doc (106,496) 27-05-2011 12:10
http://oldforge.etsi.org/mantis/file_download.php?file_id=2517&type=bug
Issue History
Date ModifiedUsernameFieldChange
10-12-2010 14:34Jacob Wieland - SpirentNew Issue
10-12-2010 14:34Jacob Wieland - SpirentClause Reference(s) => XSD to TTCN-3 Mapping, section 7.7
10-12-2010 14:34Jacob Wieland - SpirentSource (company - Author) => Testing Technologies - Jacob Wieland
13-12-2010 12:47Gyorgy RethyTarget Version => Edition 4.3.2 (interim)
24-05-2011 15:12Gyorgy RethyNote Added: 0010027
24-05-2011 15:12Gyorgy RethyAssigned To => Gyorgy Rethy
24-05-2011 15:12Gyorgy RethyStatusnew => assigned
24-05-2011 19:22Gyorgy RethyPrioritynormal => high
25-05-2011 16:57Gyorgy RethyNote Edited: 0010027
26-05-2011 08:48Gyorgy RethyNote Edited: 0010027
26-05-2011 17:35Gyorgy RethyFile Added: CR5848_resolution_v1.doc
26-05-2011 17:36Gyorgy RethyNote Added: 0010092
26-05-2011 17:36Gyorgy RethyAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
27-05-2011 11:49Jacob Wieland - SpirentFile Added: CR5848_resolution_v2.doc
27-05-2011 11:52Jacob Wieland - SpirentNote Added: 0010096
27-05-2011 11:53Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
27-05-2011 12:10Gyorgy RethyNote Added: 0010097
27-05-2011 12:10Gyorgy RethyFile Added: CR5848_resolution_v3.doc
27-05-2011 12:11Gyorgy RethyStatusassigned => resolved
27-05-2011 12:11Gyorgy RethyResolutionopen => fixed
13-07-2011 14:56Gyorgy RethyStatusresolved => closed
13-07-2011 14:56Gyorgy RethyNote Added: 0010217
13-07-2011 14:56Gyorgy RethyFixed in Version => Edition 4.3.2 (interim)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010027) +
+ Gyorgy Rethy    +
+ 24-05-2011 15:12    +
(edited on: 26-05-2011 08:48)
+ 		+ + + + +
+ 3GPP related CR.
+String content has to be specified explicitly, in line with X.693.
+
+
+
+
+
+ + + + + + + + + + +
+ (0010092) +
+ Gyorgy Rethy    +
+ 26-05-2011 17:36    +
+ 		+ + + + +
+ See proposed resoltion text in CR5848_resolution_v1.doc. Jacob, pls. review.
+
+
+
+ + + + + + + + + + +
+ (0010096) +
+ Jacob Wieland - Spirent    +
+ 27-05-2011 11:52    +
+ 		+ + + + +
+ changed the ' in the element-tag part in the example to ' because to my knowledge ' can only be used in PCDATA (i.e. text between element tags) and not inside element-tags.
+
+Otherwise OK.
+
+One question, if you have the optional URI followed by whitespace, shall there be a whitespace before the name also if the URI is missing? I.e. should the whitespace not be also in the optional part?
+
+
+
+ + + + + + + + + + +
+ (0010097) +
+ Gyorgy Rethy    +
+ 27-05-2011 12:10    +
+ 		+ + + + +
+ Hi jacob, you are rigth, the whitespace shall be in the optional part. CR5848_resolution_v3.doc contains this correction, no other changes related to ~_v2.
+
+
+
+ + + + + + + + + + +
+ (0010217) +
+ Gyorgy Rethy    +
+ 13-07-2011 14:56    +
+ 		+ + + + +
+ Added to master copy.
+
+ + diff --git a/docs/mantis/CR5851.md b/docs/mantis/CR5851.md new file mode 100644 index 0000000000000000000000000000000000000000..46a97b6329d38584b3dd3aae99da1af02fb81e90 --- /dev/null +++ b/docs/mantis/CR5851.md @@ -0,0 +1,75 @@ + + + + + + + + + + + + + 0005851: ispresent - wrong and superfluous example - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005851Part 01: TTCN-3 Core LanguageEditorialpublic17-12-2010 15:4817-12-2010 15:51
ReporterIna Schieferdecker 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.3.1 (published 2011-06)Fixed in Versionv4.3.1 (published 2011-06) 
Clause Reference(s)C.31
Source (company - Author)Ina Schieferdecker, FOKUS - reported for STF160
Summary0005851: ispresent - wrong and superfluous example
DescriptionThe last example for ispresent
+
+    function f(in template p) {
+      if (ispresent(p)) {
+        // do something
+      }
+    }
+    f(t) // does not cause an error if t is a valid template
+
+is wrong and superfluous - and should be deleted.
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
17-12-2010 15:48Ina SchieferdeckerNew Issue
17-12-2010 15:48Ina SchieferdeckerStatusnew => assigned
17-12-2010 15:48Ina SchieferdeckerAssigned To => Ina Schieferdecker
17-12-2010 15:48Ina SchieferdeckerClause Reference(s) => C.31
17-12-2010 15:48Ina SchieferdeckerSource (company - Author) => Ina Schieferdecker, FOKUS - reported for STF160
17-12-2010 15:48Ina SchieferdeckerProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
17-12-2010 15:49Ina SchieferdeckerStatusassigned => resolved
17-12-2010 15:49Ina SchieferdeckerResolutionopen => fixed
17-12-2010 15:49Ina SchieferdeckerFixed in Version => Edition 4.3.1 (not yet published)
17-12-2010 15:49Ina SchieferdeckerTarget Version => Edition 4.3.1 (not yet published)
17-12-2010 15:49Ina SchieferdeckerSummaryWrong and superfluous example => ispresent - wrong and superfluous example
17-12-2010 15:50Ina SchieferdeckerNote Added: 0009980
17-12-2010 15:50Ina SchieferdeckerNote Edited: 0009980
17-12-2010 15:51Ina SchieferdeckerStatusresolved => closed
17-12-2010 15:51Ina SchieferdeckerDescription Updated
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009980) +
+ Ina Schieferdecker    +
+ 17-12-2010 15:50    +
+ 		+ + + + +
+ Deleted as proposed.
+
+
+
+ + diff --git a/docs/mantis/CR5852.md b/docs/mantis/CR5852.md new file mode 100644 index 0000000000000000000000000000000000000000..bea192617d6ce7673d2b8d7b95b58412eb8dd855 --- /dev/null +++ b/docs/mantis/CR5852.md @@ -0,0 +1,550 @@ + + + + + + + + + + + + + 0005852: choice with optional content should be mapped to an optional union field - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005852Part 09: Using XML with TTCN-3Technicalpublic22-12-2010 12:2713-07-2011 16:33
ReporterJacob Wieland - Spirent 
Assigned ToGyorgy Rethy 
PriorityhighSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Clause Reference(s)XSD Language Mapping, section 7.1.4
For STF discussion
Source (company - Author)Testing Technologies - Jacob Wieland
Summary0005852: choice with optional content should be mapped to an optional union field
DescriptionThe special case that one element (or sub-particle) of a choice particle can occur 0 times (minOccurs="0") should be handled in the way that the resulting union field in the TTCN-3 type should be optional.
+
+Otherwise, if more than one alternative is 'optional', it is unclear which alternative shall be chosen if none of the elements allowed in the choice are present in the XML.
+
+Example:
+
+<choice>
+  <element name="a" minOccurs="0" type="A_Type"/>
+  <element name="b" minOccurs="0" maxOccurs="10" type="B_Type"/>
+</choice>
+
+should be mapped to a field like:
+
+union {
+  A_Type a,
+  record length (1 .. 10) of B_Type b
+} choice optional
+
+Of course, this is true for any sub-particle of a choice which describes the empty XML element concatenation.
+
+Basically, the rule should be: if one of the sub-fields of a union should be optional in regard to minOccurs or can be the empty list, the union should be optional instead.
+
+ 
+  
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR5852_resolution_v1.doc (157,184) 01-07-2011 10:14
http://oldforge.etsi.org/mantis/file_download.php?file_id=2543&type=bug
doc CR5852_resolution_v2.doc (75,776) 01-07-2011 16:44
http://oldforge.etsi.org/mantis/file_download.php?file_id=2553&type=bug
Issue History
Date ModifiedUsernameFieldChange
22-12-2010 12:27Jacob Wieland - SpirentNew Issue
22-12-2010 12:27Jacob Wieland - SpirentClause Reference(s) => XSD Language Mapping, section 7.1.4
22-12-2010 12:27Jacob Wieland - SpirentSource (company - Author) => Testing Technologies - Jacob Wieland
24-05-2011 15:05Gyorgy RethyNote Added: 0010026
24-05-2011 15:05Gyorgy RethyAssigned To => Gyorgy Rethy
24-05-2011 15:05Gyorgy RethyStatusnew => assigned
24-05-2011 15:05Gyorgy RethyTarget Version => Edition 4.3.2 (interim)
24-05-2011 19:22Gyorgy RethyPrioritynormal => high
25-05-2011 16:58Gyorgy RethyNote Edited: 0010026
02-06-2011 14:44Gyorgy RethyNote Added: 0010112
02-06-2011 14:52Gyorgy RethyNote Edited: 0010112
02-06-2011 15:16Gyorgy RethyNote Edited: 0010112
02-06-2011 15:40Gyorgy RethyNote Edited: 0010112
06-06-2011 12:04Jacob Wieland - SpirentNote Added: 0010113
30-06-2011 12:16Gyorgy RethyNote Edited: 0010112
30-06-2011 12:53Gyorgy RethyNote Added: 0010156
30-06-2011 14:39Gyorgy RethyNote Added: 0010158
01-07-2011 10:14Gyorgy RethyFile Added: CR5852_resolution_v1.doc
01-07-2011 10:15Gyorgy RethyNote Added: 0010172
01-07-2011 10:16Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
01-07-2011 14:03Gyorgy RethyAssigned ToIna Schieferdecker => Jacob Wieland - Spirent
01-07-2011 16:44Jacob Wieland - SpirentFile Added: CR5852_resolution_v2.doc
01-07-2011 16:44Jacob Wieland - SpirentNote Added: 0010189
01-07-2011 16:44Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
01-07-2011 16:58Gyorgy RethyStatusassigned => resolved
01-07-2011 16:58Gyorgy RethyResolutionopen => fixed
13-07-2011 16:33Gyorgy RethyStatusresolved => closed
13-07-2011 16:33Gyorgy RethyNote Added: 0010219
13-07-2011 16:33Gyorgy RethyFixed in Version => Edition 4.3.2 (interim)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010026) +
+ Gyorgy Rethy    +
+ 24-05-2011 15:05    +
(edited on: 25-05-2011 16:58)
+ 		+ + + + +
+ 3GPP related CR.
+Check the possible solution.
+
+
+
+
+
+ + + + + + + + + + +
+ (0010112) +
+ Gyorgy Rethy    +
+ 02-06-2011 14:44    +
(edited on: 30-06-2011 12:16)
+ 		+ + + + +
+ Yes, this seems to be an unhandled case... though the case when more than one alternative has minOccurs="0" should be a rather specific one, supposedly used very rarely, as doesn't make much technical sense.
+
+To understand it better, we have to look at the possible cases when choice can appear:
+1) as a complexType on its own
+2) as a choice group
+===========================================
+As compositor of complexTypes, e.g.
+<complexType name="e25choOptional">
+    <choice>
+        <element name="title" type="string" minOccurs="0"/>
+        <element name="forename" type="string" minOccurs="0"/>
+        <element name="surname" type="string" minOccurs="0"/>
+    </choice>
+</complexType>
+<element name="elemChoOptional" type="ns:e25choOptional"/>
+
+This could be handled in two ways:
+-----------------------------
+1.a)
+As proposed above:
+type record E25choOptional {
+    union {
+        XSD.String title,
+        XSD.String forename,
+        XSD.String surname
+    } choice optional
+}
+with {
+variant "name as uncapitalized";
+variant (choice) "untagged";
+};
+
+type E25choOptional ElemChoOptional
+with {
+variant "name as uncapitalized";
+variant "element";
+};
+
+template ElemChoOptional t_ElemChoOptional := { choice := omit }
+
+-----------------------------
+1.b) In this case translating minOccurs="0" maxOccurs="1" to a record of:
+type record E25choOptional {
+    union {
+        record length(0 .. 1) of XSD.String title_list,
+        record length(0 .. 1) of XSD.String forename_list,
+        record length(0 .. 1) of XSD.String surname_list
+    } choice
+}
+with {
+variant "name as uncapitalized";
+variant (choice) "untagged";
+variant (choice.title_list) "untagged";
+variant (choice.title_list[-]) "name as 'title'";
+variant (choice.forename_list) "untagged";
+variant (choice.forename_list[-]) "name as 'forename'";
+variant (choice.surname_list) "untagged";
+variant (choice.surname_list[-]) "name as 'surname'";
+};
+
+type E25choOptional ElemChoOptional
+with {
+variant "name as uncapitalized";
+variant "element";
+};
+
+template ElemChoOptional t_ElemChoOptional := { choice := {title_list := {}}}
+
+In this case, of course, there also shall be the same rule as for union-s, the first matching alternative "wins", thus receiving an empty element would be decoded to:
+{ choice := { title_list := { } } }
+
+Not nice, but can work
+
+===========================================
+Let see these two options also in the case, when choice is used as a governor of groups, embedded in another choice group:
+For example:
+<group name="e25ChoGroupOpt">
+    <choice>
+        <element name="title" type="string" minOccurs="0"/>
+        <element name="forename" type="string" minOccurs="0"/>
+        <element name="surname" type="string" minOccurs="0"/>
+    </choice>
+</group>
+
+<group name="e25ChoChoGroupOpt">
+    <choice>
+        <group ref="ns:e25ChoGroupOpt"/>
+    </choice>
+</group>
+
+<element name="elemFromChoGroupOpt">
+    <complexType>
+        <group ref="ns:e25ChoChoGroupOpt"/>
+    </complexType>
+</element>
+-----------------------------
+2.a) translated according to the proposal to:
+type union E25ChoGroupOpt {
+    XSD.String title,
+    XSD.String forename,
+    XSD.String surname
+}
+with {
+variant "untagged";
+};
+
+type union E25ChoChoGroupOpt {
+    E25ChoGroupOpt e25ChoGroupOpt
+}
+with {
+variant "untagged";
+};
+
+type record ElemFromChoGroupOpt {
+    E25ChoChoGroupOpt e25ChoChoGroupOpt optional
+}
+with {
+variant "name as uncapitalized";
+variant "element";
+};
+
+template ElemFromChoGroupOpt t_ElemFromChoGroupOpt := { e25ChoChoGroupOpt := omit }
+
+-----------------------------
+2.b) or with the modified min/maxOccurs conversion to:
+type union E25ChoGroupOpt {
+    record length(0 .. 1) of XSD.String title_list,
+    record length(0 .. 1) of XSD.String forename_list,
+    record length(0 .. 1) of XSD.String surname_list
+}
+with {
+variant "untagged";
+variant (choice.title_list) "untagged";
+variant (choice.title_list[-]) "name as 'title'";
+variant (choice.forename_list) "untagged";
+variant (choice.forename_list[-]) "name as 'forename'";
+variant (choice.surname_list) "untagged";
+variant (choice.surname_list[-]) "name as 'surname'";
+};
+
+type union E25ChoChoGroupOpt {
+    E25ChoGroupOpt e25ChoGroupOpt
+}
+with {
+variant "untagged";
+};
+
+type record ElemChoFromGroupOptional {
+    E25ChoChoGroupOpt e25ChoChoGroupOpt
+}
+with {
+variant "name as uncapitalized";
+variant "element";
+};
+
+template ElemFromChoGroupOptional t_ElemFromChoGroupOptional := {e25ChoChoGroupOpt:= {e25ChoGroupOpt := {title_list :={}}}}
+
+===========================================
+Let see these two options in the case, when the groups is embedded in a sequence group:
+<!-- e25ChoGroupOpt as above -->
+<group name="e25SeqChoGroupOpt">
+    <sequence>
+        <group ref="ns:e25ChoGroupOpt"/>
+    </sequence>
+</group>
+
+<element name="elemFromSeqGroupOpt">
+    <complexType>
+        <group ref="ns:e25SeqChoGroupOpt"/>
+    </complexType>
+</element>
+-----------------------------
+3.a) According to the proposed solution:
+type record E25SeqChoGroupOpt {
+    E25ChoGroupOpt e25ChoGroupOpt optional
+}
+with {
+variant "untagged";
+};
+
+type record ElemFromSeqGroupOpt {
+    E25SeqChoGroupOpt e25SeqChoGroupOpt
+}
+with {
+variant "name as uncapitalized";
+variant "element";
+};
+
+template ElemFromSeqGroupOpt t_ElemFromSeqGroupOpt := { e25SeqChoGroupOpt:= {e25ChoGroupOpt:=omit }}
+-----------------------------
+3.b) or with the modified min/maxOccurs conversion to:
+
+type record E25SeqChoGroupOpt {
+    E25ChoGroupOpt e25ChoGroupOpt
+}
+with {
+variant "untagged";
+};
+
+type record ElemFromSeqGroupOpt {
+    E25SeqChoGroupOpt e25SeqChoGroupOpt
+}
+with {
+variant "name as uncapitalized";
+variant "element";
+};
+
+template ElemFromSeqGroupOpt t_ElemFromSeqGroupOpt := {e25SeqChoGroupOpt:= {e25ChoGroupOpt := {title_list :={}}}}
+===========================================
+
+So, to sum up the experince from the above trial is:
+- if using the proposed solution:
+the respective union itself cannot be always made optional but all occurances shall be made optional where the given union is USED in a record the first time. Therefore, for example, no template resulting an empty element can be written for the types E25ChoGroupOpt, E25ChoChoGroupOpt. The values/templates using the type are simpler, but depending on the USE, fields at different levels shall be omitted.
+This would be dificult to handle in the standard (changes at more places).
+- if using the modified min/maxOccurs mapping:
+The minOccurs="0" is handled directly at the place where it is used. The values/templates are more complex, but consistent in all cases (value has to be discased to the depth of the respective union in all cases, independent of the use of the union.). At matching, this case is more tricky as the user shall remember that in case of an empty element the decoder picks the first alternative. To implement it in the standard, it would need an additional one-two sentence(s) in clause 7.1.4 ("MinOccurs and maxOccurs"), exactly the place where the user would search for the rule.
+
+Taking into account the findings of the above "experiment", I propose to handle this case by amending the rules of minOccurs conversion.
+
+
+
+
+
+ + + + + + + + + + +
+ (0010113) +
+ Jacob Wieland - Spirent    +
+ 06-06-2011 12:04    +
+ 		+ + + + +
+ Regarding your experiments, I would vote for exactly the other direction. It is much more user-friendly and understandable. We should not opt for the easier way to change the standard just to stick with a user-unfriendly, hard to understand feature.
+
+Anyone can see from your examples that the mapping of version a) is much more natural and much simpler and, I think, also more composable.
+
+Since choices pretty much never can stand on their own (they always must be referenced from an element as its type (or be the top-anonymous type of an element or a group reference), it just needs to be stated that whenever such a reference is made to a choice that can evaluate to an emtpy-XML-content, the field referencing the resulting union type must be optional. This can probably also be done with 2 or three well-placed sentences.
+
+
+
+ + + + + + + + + + +
+ (0010156) +
+ Gyorgy Rethy    +
+ 30-06-2011 12:53    +
+ 		+ + + + +
+ Choose the record of solution. In case of receiving an empty element the decoder shall also use the first alternative with an empty record of.
+
+
+
+ + + + + + + + + + +
+ (0010158) +
+ Gyorgy Rethy    +
+ 30-06-2011 14:39    +
+ 		+ + + + +
+ One more point: when there are more than 1 alternatives with minOccurs="0" in the XSD choice, only the first one shall be a record length(0..X) of, the rest shall be record length(1..X) of; in this way any decoding ambiguity is removed, an empty something can be received by using the first alternative only.
+
+
+
+ + + + + + + + + + +
+ (0010172) +
+ Gyorgy Rethy    +
+ 01-07-2011 10:15    +
+ 		+ + + + +
+ Proposed resolution text is in CR5852_resolution_v1.doc. Pls. review.
+
+
+
+ + + + + + + + + + +
+ (0010189) +
+ Jacob Wieland - Spirent    +
+ 01-07-2011 16:44    +
+ 		+ + + + +
+ added missing case
+
+
+
+ + + + + + + + + + +
+ (0010219) +
+ Gyorgy Rethy    +
+ 13-07-2011 16:33    +
+ 		+ + + + +
+ Added to master copy.
+
+ + diff --git a/docs/mantis/CR5853.md b/docs/mantis/CR5853.md new file mode 100644 index 0000000000000000000000000000000000000000..6421bc3b9407e24e3bf7528d5663e4e9674363d3 --- /dev/null +++ b/docs/mantis/CR5853.md @@ -0,0 +1,208 @@ + + + + + + + + + + + + + 0005853: language tags for XSD should be revised - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005853Part 09: Using XML with TTCN-3New Featurepublic22-12-2010 13:5213-07-2011 14:22
ReporterJacob Wieland - Spirent 
Assigned ToGyorgy Rethy 
PriorityhighSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Clause Reference(s)XSD Language Mapping, section 5
For STF discussion
Source (company - Author)Testing Technologies - Jacob Wieland
Summary0005853: language tags for XSD should be revised
DescriptionIn my opinion, it does not make sense to have the language tags named XML... because, though it is a form of XML which is imported, it is a very special sort and therefore the names starting with XML are totally misleading.
+
+Saying that the XSD schema definitions are written in XML1.0 or some other version of XML should be uninteresting (If a tool needs this information, this is a tool-dependent issue and should be solved via extension tags or something else). More interesting should be the version of XSD which shall be imported from (if at all, actually I think this should be out of scope).
+
+Therefore, the language tags that are used for importing XSD schema definitions should be changed to "XSD" or maybe the uri of the schema definition version (i.e. "http://www.w3.org/2001/XMLSchema" [^]) instead of the misleading XML tags.
+
+The old tags could be kept for backward-compatibility reasons, but since not all tools support these at the moment anyway, it's probably unnecessary.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filestxt CR5853_question.txt (1,863) 25-05-2011 18:06
http://oldforge.etsi.org/mantis/file_download.php?file_id=2495&type=bug
doc CR5853_resolution_v1.doc (1,354,240) 29-06-2011 15:49
http://oldforge.etsi.org/mantis/file_download.php?file_id=2524&type=bug
doc CR5853_resolution_v2.doc (984,576) 30-06-2011 16:43
http://oldforge.etsi.org/mantis/file_download.php?file_id=2537&type=bug
Issue History
Date ModifiedUsernameFieldChange
22-12-2010 13:52Jacob Wieland - SpirentNew Issue
22-12-2010 13:52Jacob Wieland - SpirentClause Reference(s) => XSD Language Mapping, section 5
22-12-2010 13:52Jacob Wieland - SpirentSource (company - Author) => Testing Technologies - Jacob Wieland
24-05-2011 15:01Gyorgy RethyNote Added: 0010025
24-05-2011 15:01Gyorgy RethyAssigned To => Gyorgy Rethy
24-05-2011 15:01Gyorgy RethyStatusnew => assigned
24-05-2011 15:01Gyorgy RethyTarget Version => Edition 4.3.2 (interim)
24-05-2011 15:01Gyorgy RethyNote Edited: 0010025
25-05-2011 17:03Gyorgy RethyNote Edited: 0010025
25-05-2011 17:03Gyorgy RethyPrioritynormal => high
25-05-2011 18:06Gyorgy RethyFile Added: CR5853_question.txt
25-05-2011 18:07Gyorgy RethyNote Added: 0010072
29-06-2011 15:49Gyorgy RethyFile Added: CR5853_resolution_v1.doc
29-06-2011 15:53Gyorgy RethyNote Added: 0010147
29-06-2011 15:54Gyorgy RethyAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
29-06-2011 15:54Gyorgy RethyResolutionopen => fixed
30-06-2011 16:43Jacob Wieland - SpirentFile Added: CR5853_resolution_v2.doc
30-06-2011 16:43Jacob Wieland - SpirentNote Added: 0010164
30-06-2011 17:37Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Ina Schieferdecker
30-06-2011 17:53Ina SchieferdeckerAssigned ToIna Schieferdecker => Gyorgy Rethy
01-07-2011 16:56Gyorgy RethyStatusassigned => resolved
13-07-2011 14:22Gyorgy RethyStatusresolved => closed
13-07-2011 14:22Gyorgy RethyNote Added: 0010215
13-07-2011 14:22Gyorgy RethyFixed in Version => Edition 4.3.2 (interim)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010025) +
+ Gyorgy Rethy    +
+ 24-05-2011 15:01    +
(edited on: 25-05-2011 17:03)
+ 		+ + + + +
+ 3GPP related CR.
+Ask the tool vendors if changing the string is OK. If not, keep the old string as deprecated.
+
+
+
+
+
+ + + + + + + + + + +
+ (0010072) +
+ Gyorgy Rethy    +
+ 25-05-2011 18:07    +
+ 		+ + + + +
+ See email sent to tool vendors in CR5853_question.txt (also "XML1.0" is efected, of course).
+
+
+
+ + + + + + + + + + +
+ (0010147) +
+ Gyorgy Rethy    +
+ 29-06-2011 15:53    +
+ 		+ + + + +
+ 3 positive responses have been received from tool vendors (all 3 requesting keeping the old strings as deprecated) and no one against. Therefore the change has been added to the draft. See and review document CR5853_resolution_v1.doc.
+
+
+
+ + + + + + + + + + +
+ (0010164) +
+ Jacob Wieland - Spirent    +
+ 30-06-2011 16:43    +
+ 		+ + + + +
+ just corrected small grammatical error. Otherwise ok.
+
+
+
+ + + + + + + + + + +
+ (0010215) +
+ Gyorgy Rethy    +
+ 13-07-2011 14:22    +
+ 		+ + + + +
+ Added to master copy.
+
+ + diff --git a/docs/mantis/CR5854.md b/docs/mantis/CR5854.md new file mode 100644 index 0000000000000000000000000000000000000000..98f781452a607d3ea6b747e439b64205b0965328 --- /dev/null +++ b/docs/mantis/CR5854.md @@ -0,0 +1,29 @@ + + + + + + + + + + + + + 0005854: Errors in examples - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005854Part 01: TTCN-3 Core LanguageEditorialpublic03-01-2011 12:0603-01-2011 12:07
ReporterIna Schieferdecker 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.3.1 (published 2011-06)Fixed in Versionv4.3.1 (published 2011-06) 
Clause Reference(s)Part 1
Source (company - Author)Ina Schieferdecker, FOKUS
Summary0005854: Errors in examples
DescriptionIn part 1, there are port type definitions without the message or procedure keyword. These require a straightforward fix.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
03-01-2011 12:06Ina SchieferdeckerNew Issue
03-01-2011 12:06Ina SchieferdeckerStatusnew => assigned
03-01-2011 12:06Ina SchieferdeckerAssigned To => Ina Schieferdecker
03-01-2011 12:06Ina SchieferdeckerClause Reference(s) => Part 1
03-01-2011 12:06Ina SchieferdeckerSource (company - Author) => Ina Schieferdecker, FOKUS
03-01-2011 12:07Ina SchieferdeckerProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
03-01-2011 12:07Ina SchieferdeckerStatusassigned => resolved
03-01-2011 12:07Ina SchieferdeckerResolutionopen => fixed
03-01-2011 12:07Ina SchieferdeckerFixed in Version => Edition 4.3.1 (not yet published)
03-01-2011 12:07Ina SchieferdeckerTarget Version => Edition 4.3.1 (not yet published)
03-01-2011 12:07Ina SchieferdeckerStatusresolved => closed
+
+ + + + +
+ There are no notes attached to this issue.
+ + diff --git a/docs/mantis/CR5855.md b/docs/mantis/CR5855.md new file mode 100644 index 0000000000000000000000000000000000000000..136dad57d525a4a3ea600980b4d2088b3c0ac132 --- /dev/null +++ b/docs/mantis/CR5855.md @@ -0,0 +1,64 @@ + + + + + + + + + + + + + 0005855: TciValueList should be TciValueListType - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005855Part 06: TTCN-3 Control InterfaceTechnicalpublic03-01-2011 12:4610-01-2011 22:28
Reportermichielverschueren 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.1.1 (published 2009-06) 
Target Versionv4.3.1 (published 2011-06)Fixed in Versionv4.3.1 (published 2011-06) 
Clause Reference(s)ETSI ES 201 873-6 V4.2.1 (2010-07)
Source (company - Author)ON Semi - Michiel Verschueren
Summary0005855: TciValueList should be TciValueListType
DescriptionIn ETSI ES 201 873-6 V4.2.1 (2010-07), Annex B, paragraph B.2, the complexType named TciValueList should be named TciValueListType.
Steps To Reproduce
Additional Informationsee e-mail to ETSI MTSsupport from Dec. 24, 2010.
+
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
03-01-2011 12:46michielverschuerenNew Issue
03-01-2011 12:46michielverschuerenClause Reference(s) => ETSI ES 201 873-6 V4.2.1 (2010-07)
03-01-2011 12:46michielverschuerenSource (company - Author) => ON Semi - Michiel Verschueren
10-01-2011 22:23Ina SchieferdeckerAssigned To => Ina Schieferdecker
10-01-2011 22:23Ina SchieferdeckerStatusnew => resolved
10-01-2011 22:23Ina SchieferdeckerResolutionopen => fixed
10-01-2011 22:23Ina SchieferdeckerFixed in Version => Edition 4.3.1 (not yet published)
10-01-2011 22:23Ina SchieferdeckerTarget Version => Edition 4.3.1 (not yet published)
10-01-2011 22:26Ina SchieferdeckerStatusresolved => closed
10-01-2011 22:28Ina SchieferdeckerNote Added: 0009985
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009985) +
+ Ina Schieferdecker    +
+ 10-01-2011 22:28    +
+ 		+ + + + +
+ as proposed
+
+ + diff --git a/docs/mantis/CR5856.md b/docs/mantis/CR5856.md new file mode 100644 index 0000000000000000000000000000000000000000..c6665169f21216d4e764b07f7de8488ff3d5d483 --- /dev/null +++ b/docs/mantis/CR5856.md @@ -0,0 +1,114 @@ + + + + + + + + + + + + + 0005856: ArrayTemplate missing - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005856Part 06: TTCN-3 Control InterfaceTechnicalpublic03-01-2011 12:4910-01-2011 22:33
Reportermichielverschueren 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.1.1 (published 2009-06) 
Target Versionv4.3.1 (published 2011-06)Fixed in Versionv4.3.1 (published 2011-06) 
Clause Reference(s)ETSI ES 201 873-6 V4.2.1 (2010-07)
Source (company - Author)Michiel Verschueren
Summary0005856: ArrayTemplate missing
DescriptionIn ETSI ES 201 873-6 V4.2.1 (2010-07), Annex B, paragraph B.4, an ArrayTemplate complexType element is missing.
Steps To Reproduce
Additional InformationSee e-mail to ETSI MTSsupport on Dec. 24, 2010.
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
03-01-2011 12:49michielverschuerenNew Issue
03-01-2011 12:49michielverschuerenClause Reference(s) => ETSI ES 201 873-6 V4.2.1 (2010-07)
03-01-2011 12:49michielverschuerenSource (company - Author) => Michiel Verschueren
10-01-2011 22:32Ina SchieferdeckerNote Added: 0009986
10-01-2011 22:33Ina SchieferdeckerAssigned To => Ina Schieferdecker
10-01-2011 22:33Ina SchieferdeckerStatusnew => resolved
10-01-2011 22:33Ina SchieferdeckerResolutionopen => fixed
10-01-2011 22:33Ina SchieferdeckerFixed in Version => Edition 4.3.1 (not yet published)
10-01-2011 22:33Ina SchieferdeckerTarget Version => Edition 4.3.1 (not yet published)
10-01-2011 22:33Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009986) +
+ Ina Schieferdecker    +
+ 10-01-2011 22:32    +
+ 		+ + + + +
+ Defined based on ArrayValue and similar to RecordOfTemplate:
+
+    <xsd:complexType name="ArrayTemplate">
+        <xsd:complexContent>
+            <xsd:extension base="Values:ArrayValue">
+                <xsd:choice minOccurs="0" maxOccurs="unbounded">
+                    <xsd:element name="integer" type="Templates:IntegerTemplate" minOccurs="0"
+                            maxOccurs="unbounded"/>
+                    <xsd:element name="float" type="Templates:FloatTemplate" minOccurs="0"
+                            maxOccurs="unbounded"/>
+                    <xsd:element name="boolean" type="Templates:BooleanTemplate" minOccurs="0"
+                            maxOccurs="unbounded"/>
+                    <xsd:element name="verdicttype" type="Templates:VerdictTemplate" minOccurs="0"
+                            maxOccurs="unbounded"/>
+                    <xsd:element name="bitstring" type="Templates:BitstringTemplate"
+                            minOccurs="0" maxOccurs="unbounded"/>
+                    <xsd:element name="hexstring" type="Templates:HexstringTemplate"
+                            minOccurs="0" maxOccurs="unbounded"/>
+                    <xsd:element name="octetstring" type="Templates:OctetstringTemplate"
+                            minOccurs="0" maxOccurs="unbounded"/>
+                    <xsd:element name="charstring" type="Templates:CharstringTemplate"
+                            minOccurs="0" maxOccurs="unbounded"/>
+                    <xsd:element name="universal_charstring"
+                            type="Templates:UniversalCharstringTemplate" minOccurs="0"
+                            maxOccurs="unbounded"/>
+                    <xsd:element name="record" type="Templates:RecordTemplate" minOccurs="0"
+                            maxOccurs="unbounded"/>
+                    <xsd:element name="record_of" type="Templates:RecordOfTemplate"
+                            minOccurs="0" maxOccurs="unbounded"/>
+                    <xsd:element name="array" type="Templates:ArrayTemplate" minOccurs="0"
+                            maxOccurs="unbounded"/>
+                    <xsd:element name="set" type="Templates:SetTemplate" minOccurs="0"
+                            maxOccurs="unbounded"/>
+                    <xsd:element name="set_of" type="Templates:SetOfTemplate"
+                            minOccurs="0" maxOccurs="unbounded"/>
+                    <xsd:element name="enumerated" type="Templates:EnumeratedTemplate"
+                            minOccurs="0" maxOccurs="unbounded"/>
+                    <xsd:element name="union" type="Templates:UnionTemplate" minOccurs="0"
+                            maxOccurs="unbounded"/>
+                    <xsd:element name="anytype" type="Templates:AnytypeTemplate" minOccurs="0"
+                            maxOccurs="unbounded"/>
+                    <xsd:element name="address" type="Templates:AddressTemplate" minOccurs="0"
+                            maxOccurs="unbounded"/>
+                    <xsd:element name="omit" type="Templates:omit"/>
+                    <xsd:element name="any" type="Templates:any"/>
+                    <xsd:element name="anyoromit" type="Templates:anyoromit"/>
+                    <xsd:element name="templateDef" type="SimpleTypes:TString"/>
+                     <xsd:element name="null" type="Templates:null"/>
+                </xsd:choice>
+            </xsd:extension>
+           </xsd:complexContent>
+    </xsd:complexType>
+
+ + diff --git a/docs/mantis/CR5857.md b/docs/mantis/CR5857.md new file mode 100644 index 0000000000000000000000000000000000000000..5ee2d77e523b84559e1ef0f07ea9fba598c95e95 --- /dev/null +++ b/docs/mantis/CR5857.md @@ -0,0 +1,65 @@ + + + + + + + + + + + + + 0005857: cyclic dependency between Values and Templates schema - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005857Part 06: TTCN-3 Control InterfaceTechnicalpublic03-01-2011 12:5824-05-2011 14:59
Reportermichielverschueren 
Assigned To 
PrioritynormalSeveritytweakReproducibilityalways
StatusclosedResolutionwon't fix 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Clause Reference(s)ETSI ES 201 873-6 V4.2.1 (2010-07)
Source (company - Author)Michiel Verschueren
Summary0005857: cyclic dependency between Values and Templates schema
DescriptionIn ETSI ES 201 873-6 V4.2.1 (2010-07), Annex B, there's a cyclic dependency between the schema defined in B.3 (Values) and B.4 (Templates). Values:ValueAtts is referenced by Templates:omit and Templates:null, which are in turn referenced by several Values types.
+
+This is not really a violation of the XML Schema spec, but it is discouraged and XSD tools may have trouble with this.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
03-01-2011 12:58michielverschuerenNew Issue
03-01-2011 12:58michielverschuerenClause Reference(s) => ETSI ES 201 873-6 V4.2.1 (2010-07)
03-01-2011 12:58michielverschuerenSource (company - Author) => Michiel Verschueren
10-01-2011 22:27Ina SchieferdeckerTarget Version => Edition 4.3.2 (interim)
24-05-2011 14:59Gyorgy RethyNote Added: 0010024
24-05-2011 14:59Gyorgy RethyStatusnew => closed
24-05-2011 14:59Gyorgy RethyResolutionopen => won't fix
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010024) +
+ Gyorgy Rethy    +
+ 24-05-2011 14:59    +
+ 		+ + + + +
+ It's not an error. Changes may be non-backward compatible.
+
+ + diff --git a/docs/mantis/CR5858.md b/docs/mantis/CR5858.md new file mode 100644 index 0000000000000000000000000000000000000000..4bffcf8a262fcc192627a93e2940515b493c7f07 --- /dev/null +++ b/docs/mantis/CR5858.md @@ -0,0 +1,234 @@ + + + + + + + + + + + + + 0005858: types extending mixed Event type not declared mixed - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005858Part 06: TTCN-3 Control InterfaceTechnicalpublic03-01-2011 13:0130-09-2011 16:57
Reportermichielverschueren 
Assigned ToIna Schieferdecker 
PriorityhighSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.4.1 (published 2012-04)Fixed in Versionv4.4.1 (published 2012-04) 
Clause Reference(s)ETSI ES 201 873-6 V4.2.1 (2010-07)
Source (company - Author)Michiel Verschueren
Summary0005858: types extending mixed Event type not declared mixed
DescriptionIn ETSI ES 201 873-6 V4.2.1 (2010-07), Annex B, paragraph B.5, several types that are extensions of the Event type are not declared with mixed="true". The Events:Event type is declared with mixed="true", though, and types extending Events:Event should therefore also be declared with mixed="true".
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Fileszip CR5858-proposal.zip (1,004,565) 30-09-2011 14:29
http://oldforge.etsi.org/mantis/file_download.php?file_id=2586&type=bug
Issue History
Date ModifiedUsernameFieldChange
03-01-2011 13:01michielverschuerenNew Issue
03-01-2011 13:01michielverschuerenClause Reference(s) => ETSI ES 201 873-6 V4.2.1 (2010-07)
03-01-2011 13:01michielverschuerenSource (company - Author) => Michiel Verschueren
10-01-2011 22:28Ina SchieferdeckerTarget Version => Edition 4.3.2 (interim)
24-05-2011 14:56Gyorgy RethyNote Added: 0010023
24-05-2011 14:56Gyorgy RethyAssigned To => Jacob Wieland - Spirent
24-05-2011 14:56Gyorgy RethyStatusnew => assigned
24-05-2011 19:20Gyorgy RethyPrioritynormal => high
25-05-2011 18:51Jacob Wieland - SpirentNote Added: 0010075
01-07-2011 13:55Jacob Wieland - SpirentNote Added: 0010178
01-07-2011 13:58michielverschuerenNote Added: 0010179
27-09-2011 14:01Gyorgy RethyTarget VersionEdition 4.3.2 (interim) => Edition 4.4.1
30-09-2011 14:29Jacob Wieland - SpirentFile Added: CR5858-proposal.zip
30-09-2011 14:29Jacob Wieland - SpirentNote Added: 0010315
30-09-2011 14:29Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Ina Schieferdecker
30-09-2011 16:56Ina SchieferdeckerNote Added: 0010320
30-09-2011 16:56Ina SchieferdeckerStatusassigned => resolved
30-09-2011 16:56Ina SchieferdeckerResolutionopen => fixed
30-09-2011 16:57Ina SchieferdeckerStatusresolved => closed
30-09-2011 16:57Ina SchieferdeckerFixed in Version => Edition 4.4.1
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010023) +
+ Gyorgy Rethy    +
+ 24-05-2011 14:56    +
+ 		+ + + + +
+ Check the comment. Seems it would make more sense to remove mixed="true"
+
+
+
+ + + + + + + + + + +
+ (0010075) +
+ Jacob Wieland - Spirent    +
+ 25-05-2011 18:51    +
+ 		+ + + + +
+ asked tool vendors about this.
+
+
+
+ + + + + + + + + + +
+ (0010178) +
+ Jacob Wieland - Spirent    +
+ 01-07-2011 13:55    +
+ 		+ + + + +
+ Since there has only been one answer to this query and no objection has been raised, I would vote for removing the mixed attributes.
+
+
+
+ + + + + + + + + + +
+ (0010179) +
+ michielverschueren    +
+ 01-07-2011 13:58    +
+ 		+ + + + +
+ Sorry for the late feedback.
+I agree with the proposal
+
+
+
+ + + + + + + + + + +
+ (0010315) +
+ Jacob Wieland - Spirent    +
+ 30-09-2011 14:29    +
+ 		+ + + + +
+ removed all mixed="true" from TLI
+
+
+
+ + + + + + + + + + +
+ (0010320) +
+ Ina Schieferdecker    +
+ 30-09-2011 16:56    +
+ 		+ + + + +
+ as proposed.
+
+ + diff --git a/docs/mantis/CR5859.md b/docs/mantis/CR5859.md new file mode 100644 index 0000000000000000000000000000000000000000..eb1604d65c40ba2dde977a52fe77c0273083de4c --- /dev/null +++ b/docs/mantis/CR5859.md @@ -0,0 +1,133 @@ + + + + + + + + + + + + + 0005859: redundant imports in XML schema - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005859Part 06: TTCN-3 Control InterfaceTechnicalpublic03-01-2011 13:0729-09-2011 08:08
Reportermichielverschueren 
Assigned ToIna Schieferdecker 
PrioritynormalSeveritytweakReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.4.1 (published 2012-04)Fixed in Versionv4.4.1 (published 2012-04) 
Clause Reference(s)ETSI ES 201 873-6 V4.2.1 (2010-07)
Source (company - Author)Michiel Verschueren
Summary0005859: redundant imports in XML schema
DescriptionIn ETSI ES 201 873-6 V4.2.1 (2010-07), Annex B, the Templates schema defined in paragraph B.4 redundantly imports the Types schema and the TLI schema defined in paragraph B.6 redundantly imports the Values and Types schema.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
03-01-2011 13:07michielverschuerenNew Issue
03-01-2011 13:07michielverschuerenClause Reference(s) => ETSI ES 201 873-6 V4.2.1 (2010-07)
03-01-2011 13:07michielverschuerenSource (company - Author) => Michiel Verschueren
10-01-2011 22:27Ina SchieferdeckerTarget Version => Edition 4.3.2 (interim)
24-05-2011 14:54Gyorgy RethyNote Added: 0010022
24-05-2011 14:54Gyorgy RethyAssigned To => Jacob Wieland - Spirent
24-05-2011 14:54Gyorgy RethyStatusnew => assigned
25-05-2011 11:36Jacob Wieland - SpirentNote Added: 0010046
25-05-2011 17:25Jacob Wieland - SpirentNote Edited: 0010046
25-05-2011 17:26Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Ina Schieferdecker
27-09-2011 13:59Gyorgy RethyTarget VersionEdition 4.3.2 (interim) => Edition 4.4.1
29-09-2011 08:03Ina SchieferdeckerNote Added: 0010287
29-09-2011 08:08Ina SchieferdeckerStatusassigned => closed
29-09-2011 08:08Ina SchieferdeckerResolutionopen => fixed
29-09-2011 08:08Ina SchieferdeckerFixed in Version => Edition 4.4.1
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010022) +
+ Gyorgy Rethy    +
+ 24-05-2011 14:54    +
+ 		+ + + + +
+ Check the comment.
+
+
+
+ + + + + + + + + + +
+ (0010046) +
+ Jacob Wieland - Spirent    +
+ 25-05-2011 11:36    +
(edited on: 25-05-2011 17:25)
+ 		+ + + + +
+ The reporter is correct. There are unused imports. They shall be removed.
+
+
+
+
+
+ + + + + + + + + + +
+ (0010287) +
+ Ina Schieferdecker    +
+ 29-09-2011 08:03    +
+ 		+ + + + +
+ As proposed.
+
+ + diff --git a/docs/mantis/CR5860.md b/docs/mantis/CR5860.md new file mode 100644 index 0000000000000000000000000000000000000000..6ca06bdd28d9a1a800bb4aaa85043117edf8c4d9 --- /dev/null +++ b/docs/mantis/CR5860.md @@ -0,0 +1,135 @@ + + + + + + + + + + + + + 0005860: Arrays are shorthand for record of, however, different matching mechanisms are allowed for array and record of - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005860Part 01: TTCN-3 Core LanguageClarificationpublic15-01-2011 15:4701-07-2011 17:16
ReporterIna Schieferdecker 
Assigned ToIna Schieferdecker 
PriorityhighSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.3.2 (interim 2011)Fixed in Versionv4.3.2 (interim 2011) 
Clause Reference(s)15.7 on template matching mechanisms
Source (company - Author)Ina Schieferdecker, FOKUS
Summary0005860: Arrays are shorthand for record of, however, different matching mechanisms are allowed for array and record of
Description6.2.7 on arrays defines "Arrays can be used in TTCN-3 as a shorthand notation to specify record of types."
+
+15.7 on template matching mechanisms however defines that permutation for record of is allowed, but not for array.
+
+This should be corrected.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
15-01-2011 15:47Ina SchieferdeckerNew Issue
15-01-2011 15:47Ina SchieferdeckerClause Reference(s) => 15.7 on template matching mechanisms
15-01-2011 15:47Ina SchieferdeckerSource (company - Author) => Ina Schieferdecker, FOKUS
24-05-2011 14:51Gyorgy RethyNote Added: 0010021
24-05-2011 14:51Gyorgy RethyAssigned To => Ina Schieferdecker
24-05-2011 14:51Gyorgy RethyStatusnew => assigned
24-05-2011 14:51Gyorgy RethyFixed in Version => Edition 4.3.2 (interim)
24-05-2011 19:20Gyorgy RethyPrioritynormal => high
24-05-2011 19:20Gyorgy RethyFixed in VersionEdition 4.3.2 (interim) =>
24-05-2011 19:20Gyorgy RethyTarget Version => Edition 4.3.2 (interim)
25-05-2011 18:03Ina SchieferdeckerNote Added: 0010071
25-05-2011 18:04Ina SchieferdeckerStatusassigned => resolved
25-05-2011 18:04Ina SchieferdeckerResolutionopen => fixed
01-07-2011 17:15Ina SchieferdeckerNote Added: 0010197
01-07-2011 17:16Ina SchieferdeckerStatusresolved => closed
01-07-2011 17:16Ina SchieferdeckerFixed in Version => Edition 4.3.2 (interim)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010021) +
+ Gyorgy Rethy    +
+ 24-05-2011 14:51    +
+ 		+ + + + +
+ To be corrected.
+
+
+
+ + + + + + + + + + +
+ (0010071) +
+ Ina Schieferdecker    +
+ 25-05-2011 18:03    +
+ 		+ + + + +
+ Just a simple correction in Table 11: in row array, column permutation put a "Yes"
+
+
+
+ + + + + + + + + + +
+ (0010197) +
+ Ina Schieferdecker    +
+ 01-07-2011 17:15    +
+ 		+ + + + +
+ As proposed.
+
+ + diff --git a/docs/mantis/CR5862.md b/docs/mantis/CR5862.md new file mode 100644 index 0000000000000000000000000000000000000000..b2e9ee569cf824ab7e4307db354a39e9d021285a --- /dev/null +++ b/docs/mantis/CR5862.md @@ -0,0 +1,180 @@ + + + + + + + + + + + + + 0005862: Update syntactical Structure of return - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005862Part 01: TTCN-3 Core LanguageTechnicalpublic17-02-2011 10:5401-07-2011 17:19
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PriorityhighSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.1.1 (published 2009-06) 
Target Versionv4.3.2 (interim 2011)Fixed in Versionv4.3.2 (interim 2011) 
Clause Reference(s)19.11
Source (company - Author)L.M.Ericsson
Summary0005862: Update syntactical Structure of return
DescriptionIn $19.10:
+Syntactical Structure
+return [ Expression ]
+
+InLineTemplate should be added (like in the BNF), the current structure is misleading for the user.
+
+Solution:
+Syntactical Structure
+return [ Expression | InLineTemplate ]
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR5862.docx (18,736) 25-05-2011 16:50
http://oldforge.etsi.org/mantis/file_download.php?file_id=2492&type=bug
Issue History
Date ModifiedUsernameFieldChange
17-02-2011 10:54Gyorgy RethyNew Issue
17-02-2011 10:54Gyorgy RethyClause Reference(s) => 19.11
17-02-2011 10:54Gyorgy RethySource (company - Author) => L.M.Ericsson
24-05-2011 14:50Gyorgy RethyNote Added: 0010020
24-05-2011 14:50Gyorgy RethyAssigned To => Ina Schieferdecker
24-05-2011 14:50Gyorgy RethyStatusnew => assigned
24-05-2011 14:50Gyorgy RethyFixed in Version => Edition 4.3.2 (interim)
24-05-2011 19:19Gyorgy RethyPrioritynormal => high
24-05-2011 19:19Gyorgy RethyCategoryEditorial => Technical
24-05-2011 19:19Gyorgy RethyFixed in VersionEdition 4.3.2 (interim) =>
24-05-2011 19:19Gyorgy RethyTarget Version => Edition 4.3.2 (interim)
25-05-2011 16:50Ina SchieferdeckerFile Added: CR5862.docx
25-05-2011 16:50Ina SchieferdeckerNote Added: 0010066
25-05-2011 16:50Ina SchieferdeckerAssigned ToIna Schieferdecker => Gyorgy Rethy
25-05-2011 18:18Gyorgy RethyStatusassigned => resolved
25-05-2011 18:18Gyorgy RethyResolutionopen => fixed
25-05-2011 18:18Gyorgy RethyNote Added: 0010073
01-07-2011 17:19Ina SchieferdeckerNote Added: 0010198
01-07-2011 17:19Ina SchieferdeckerStatusresolved => closed
01-07-2011 17:19Ina SchieferdeckerFixed in Version => Edition 4.3.2 (interim)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010020) +
+ Gyorgy Rethy    +
+ 24-05-2011 14:50    +
+ 		+ + + + +
+ Check and correct if needed.
+
+
+
+ + + + + + + + + + +
+ (0010066) +
+ Ina Schieferdecker    +
+ 25-05-2011 16:50    +
+ 		+ + + + +
+ Please check.
+
+
+
+ + + + + + + + + + +
+ (0010073) +
+ Gyorgy Rethy    +
+ 25-05-2011 18:18    +
+ 		+ + + + +
+ Its OK.
+
+Just in my Word 2003+patches I miss some spaces in the new example:
+returntemplate
+return"2005"
+return?
+
+This can be a Word issue just we should investigate it to avoid troubles when preparing the new drafts.
+
+
+
+ + + + + + + + + + +
+ (0010198) +
+ Ina Schieferdecker    +
+ 01-07-2011 17:19    +
+ 		+ + + + +
+ As proposed.
+
+ + diff --git a/docs/mantis/CR5864.md b/docs/mantis/CR5864.md new file mode 100644 index 0000000000000000000000000000000000000000..3887b6fd3a73f1176f90edccba5bd2c3c453f136 --- /dev/null +++ b/docs/mantis/CR5864.md @@ -0,0 +1,132 @@ + + + + + + + + + + + + + 0005864: Incorrect clause reference - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005864Part 01: TTCN-3 Core LanguageEditorialpublic28-02-2011 09:1401-07-2011 17:49
ReporterGyorgy Rethy 
Assigned ToIna Schieferdecker 
PrioritylowSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.3.2 (interim 2011)Fixed in Versionv4.3.2 (interim 2011) 
Clause Reference(s)16.2.1
Source (company - Author)L.M.Ericsson
Summary0005864: Incorrect clause reference
DescriptionIn clause 16.2.1 2nd sentence "The invocation may be done either implicitly by the default mechanism (see clause 21) or ...". Reference should be "see clause 20.5" (change hard coded reference with bookmark; also there are several other hardcoded references in the clause).
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Fileszip es_20187301v040302.zip (756,873) 29-06-2011 18:25
http://oldforge.etsi.org/mantis/file_download.php?file_id=2527&type=bug
Issue History
Date ModifiedUsernameFieldChange
28-02-2011 09:14Gyorgy RethyNew Issue
28-02-2011 09:14Gyorgy RethyClause Reference(s) => 16.2.1
28-02-2011 09:14Gyorgy RethySource (company - Author) => L.M.Ericsson
24-05-2011 14:46Gyorgy RethyStatusnew => assigned
24-05-2011 14:46Gyorgy RethyAssigned To => Ina Schieferdecker
24-05-2011 19:12Gyorgy RethyTarget Version => Edition 4.3.2 (interim)
24-05-2011 19:18Gyorgy RethyPrioritynormal => low
29-06-2011 18:24Ina SchieferdeckerNote Added: 0010150
29-06-2011 18:25Ina SchieferdeckerFile Added: es_20187301v040302.zip
29-06-2011 18:25Ina SchieferdeckerStatusassigned => resolved
29-06-2011 18:25Ina SchieferdeckerFixed in Version => Edition 4.4.1
29-06-2011 18:25Ina SchieferdeckerResolutionopen => fixed
29-06-2011 18:26Ina SchieferdeckerNote Added: 0010151
01-07-2011 17:49Ina SchieferdeckerNote Added: 0010203
01-07-2011 17:49Ina SchieferdeckerStatusresolved => closed
01-07-2011 17:49Ina SchieferdeckerFixed in VersionEdition 4.4.1 => Edition 4.3.2 (interim)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010150) +
+ Ina Schieferdecker    +
+ 29-06-2011 18:24    +
+ 		+ + + + +
+ Checked all clause references and corrected as needed ... terrible job ...
+
+
+
+ + + + + + + + + + +
+ (0010151) +
+ Ina Schieferdecker    +
+ 29-06-2011 18:26    +
+ 		+ + + + +
+ Should check in addition table and figure references ...
+
+
+
+ + + + + + + + + + +
+ (0010203) +
+ Ina Schieferdecker    +
+ 01-07-2011 17:49    +
+ 		+ + + + +
+ Check completed
+
+ + diff --git a/docs/mantis/CR5866.md b/docs/mantis/CR5866.md new file mode 100644 index 0000000000000000000000000000000000000000..1ac834eeceafde30d937cd86197ed2bcd38382d5 --- /dev/null +++ b/docs/mantis/CR5866.md @@ -0,0 +1,171 @@ + + + + + + + + + + + + + 0005866: Unspecified behaviour when ports not being connected are used in communication operations - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005866Part 01: TTCN-3 Core LanguageClarificationpublic03-03-2011 18:1001-07-2011 17:32
ReporterWolfgang Seka 
Assigned ToJacob Wieland - Spirent 
PriorityhighSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.1.1 (published 2009-06) 
Target Versionv4.3.2 (interim 2011)Fixed in Versionv4.3.2 (interim 2011) 
Clause Reference(s)ES 201 873-1 cl. 22
Source (company - Author)stf160 - Wolfgang
Summary0005866: Unspecified behaviour when ports not being connected are used in communication operations
DescriptionCurrently it is not clear from TTCN-3 core language what happens when a communication operation is applied to a port which is not connected or mapped.
+Especially for send events clarification is needed.
Steps To Reproduce
Additional InformationIt seems that the operational semantics (part 4) specifies a runtime error at least for send events on not connected ports.
+But other interpretations/solutions may be valid as well => clarification is needed to achieve tool compatibility.
+
+Especially for receive statements there is no obvious reason from a user's point of view why a runtime error shall be raise when a not connected port is used in an alt statement.
+
+Note: apart from the necessary clarification this issue may be related to CR 005243
TagsNo tags attached.
Relationships
Attached Filesdoc CR5866-Resolution-110526.doc (140,800) 26-05-2011 12:22
http://oldforge.etsi.org/mantis/file_download.php?file_id=2500&type=bug
Issue History
Date ModifiedUsernameFieldChange
03-03-2011 18:10Wolfgang SekaNew Issue
03-03-2011 18:10Wolfgang SekaClause Reference(s) => ES 201 873-1 cl. 22
03-03-2011 18:10Wolfgang SekaSource (company - Author) => stf160 - Wolfgang
24-05-2011 14:44Gyorgy RethyNote Added: 0010019
24-05-2011 14:45Gyorgy RethyAssigned To => Jens Grabowski
24-05-2011 14:45Gyorgy RethyStatusnew => assigned
24-05-2011 14:45Gyorgy RethyFixed in Version => Edition 4.3.2 (interim)
24-05-2011 19:10Gyorgy RethyFixed in VersionEdition 4.3.2 (interim) =>
24-05-2011 19:10Gyorgy RethyTarget Version => Edition 4.3.2 (interim)
24-05-2011 19:18Gyorgy RethyPrioritynormal => high
24-05-2011 19:18Gyorgy RethyCategoryTechnical => Clarification
26-05-2011 11:55Jens GrabowskiFile Added: CR5866-Resolution-110526.doc
26-05-2011 11:56Jens GrabowskiNote Added: 0010079
26-05-2011 11:56Jens GrabowskiAssigned ToJens Grabowski => Jacob Wieland - Spirent
26-05-2011 12:22Jacob Wieland - SpirentFile Deleted: CR5866-Resolution-110526.doc
26-05-2011 12:22Jacob Wieland - SpirentFile Added: CR5866-Resolution-110526.doc
26-05-2011 12:22Jacob Wieland - SpirentNote Added: 0010082
26-05-2011 12:23Jacob Wieland - SpirentStatusassigned => resolved
26-05-2011 12:23Jacob Wieland - SpirentResolutionopen => fixed
01-07-2011 17:30Ina SchieferdeckerNote Added: 0010199
01-07-2011 17:32Ina SchieferdeckerStatusresolved => closed
01-07-2011 17:32Ina SchieferdeckerFixed in Version => Edition 4.3.2 (interim)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010019) +
+ Gyorgy Rethy    +
+ 24-05-2011 14:44    +
+ 		+ + + + +
+ Shall cause an error. Check the standard's text and add a clarification if needed.
+
+
+
+ + + + + + + + + + +
+ (0010079) +
+ Jens Grabowski    +
+ 26-05-2011 11:56    +
+ 		+ + + + +
+ Assigned to Jacob for proofreading
+
+
+
+ + + + + + + + + + +
+ (0010082) +
+ Jacob Wieland - Spirent    +
+ 26-05-2011 12:22    +
+ 		+ + + + +
+ replaced with a version with a few typos fixed. Otherwise OK.
+
+
+
+ + + + + + + + + + +
+ (0010199) +
+ Ina Schieferdecker    +
+ 01-07-2011 17:30    +
+ 		+ + + + +
+ Implemented as proposed.
+
+ + diff --git a/docs/mantis/CR5867.md b/docs/mantis/CR5867.md new file mode 100644 index 0000000000000000000000000000000000000000..92ad92dcc523533dfb5060ae5211ea26d5d859be --- /dev/null +++ b/docs/mantis/CR5867.md @@ -0,0 +1,276 @@ + + + + + + + + + + + + + 0005867: Clarification for semantics of DONE - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005867Part 01: TTCN-3 Core LanguageClarificationpublic05-03-2011 11:1601-07-2011 17:51
ReporterWolfgang Seka 
Assigned ToIna Schieferdecker 
PriorityhighSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.3.2 (interim 2011)Fixed in Versionv4.3.2 (interim 2011) 
Clause Reference(s)ES 201 873-1 cl. 21.3.7
Source (company - Author)stf160 - Wolfgang
Summary0005867: Clarification for semantics of DONE
DescriptionIn the core language currently it is not clearly visible that DONE is a permanent state i.e. different than receive or timeout events in this terms.
+A clarifying note would be helpful, e.g.:
+
+Note: Different than rceive or timeout events which only occur once the done operation permanently matches after the respective component has stopped its behaviour.
Steps To Reproduce
Additional InformationThere is alredy a hint in annex F.1.2 but annex F is informative only and probably not read in detail by users.
TagsNo tags attached.
Relationships
Attached Filesdoc Res-CR5867 -110525.doc (77,312) 25-05-2011 13:58
http://oldforge.etsi.org/mantis/file_download.php?file_id=2481&type=bug
doc Res-CR5867 -110525-ver2.doc (78,336) 25-05-2011 14:17
http://oldforge.etsi.org/mantis/file_download.php?file_id=2483&type=bug
doc Res-CR5867 -110525-ver3.doc (80,896) 25-05-2011 14:59
http://oldforge.etsi.org/mantis/file_download.php?file_id=2487&type=bug
doc Res-CR5867 -110525-ver4.doc (50,688) 25-05-2011 15:38
http://oldforge.etsi.org/mantis/file_download.php?file_id=2489&type=bug
Issue History
Date ModifiedUsernameFieldChange
05-03-2011 11:16Wolfgang SekaNew Issue
05-03-2011 11:16Wolfgang SekaClause Reference(s) => ES 201 873-1 cl. 21.3.7
05-03-2011 11:16Wolfgang SekaSource (company - Author) => stf160 - Wolfgang
24-05-2011 14:41Gyorgy RethyNote Added: 0010018
24-05-2011 14:41Gyorgy RethyProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
24-05-2011 14:41Gyorgy RethyAssigned To => Jens Grabowski
24-05-2011 14:41Gyorgy RethyStatusnew => assigned
24-05-2011 14:41Gyorgy RethyFixed in Version => Edition 4.3.2 (interim)
24-05-2011 19:10Gyorgy RethyFixed in VersionEdition 4.3.2 (interim) =>
24-05-2011 19:10Gyorgy RethyTarget Version => Edition 4.3.2 (interim)
24-05-2011 19:17Gyorgy RethyPrioritynormal => high
25-05-2011 13:56Jens GrabowskiNote Added: 0010050
25-05-2011 13:58Jens GrabowskiFile Added: Res-CR5867 -110525.doc
25-05-2011 13:58Jens GrabowskiNote Added: 0010051
25-05-2011 13:58Jens GrabowskiAssigned ToJens Grabowski => Jacob Wieland - Spirent
25-05-2011 14:17Jens GrabowskiFile Added: Res-CR5867 -110525-ver2.doc
25-05-2011 14:18Jens GrabowskiNote Added: 0010052
25-05-2011 14:19Jens GrabowskiAssigned ToJacob Wieland - Spirent => Ina Schieferdecker
25-05-2011 14:58Ina SchieferdeckerNote Added: 0010055
25-05-2011 14:59Ina SchieferdeckerFile Added: Res-CR5867 -110525-ver3.doc
25-05-2011 14:59Ina SchieferdeckerNote Edited: 0010055
25-05-2011 15:00Ina SchieferdeckerAssigned ToIna Schieferdecker => Jacob Wieland - Spirent
25-05-2011 15:38Jacob Wieland - SpirentFile Added: Res-CR5867 -110525-ver4.doc
25-05-2011 15:40Jacob Wieland - SpirentNote Added: 0010058
25-05-2011 17:26Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Ina Schieferdecker
30-06-2011 18:01Ina SchieferdeckerNote Added: 0010169
30-06-2011 18:02Ina SchieferdeckerStatusassigned => resolved
30-06-2011 18:02Ina SchieferdeckerFixed in Version => Edition 4.3.2 (interim)
30-06-2011 18:02Ina SchieferdeckerResolutionopen => fixed
01-07-2011 17:51Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010018) +
+ Gyorgy Rethy    +
+ 24-05-2011 14:41    +
+ 		+ + + + +
+ Check the standard and add an explicit clarification if needed.
+
+
+
+ + + + + + + + + + +
+ (0010050) +
+ Jens Grabowski    +
+ 25-05-2011 13:56    +
+ 		+ + + + +
+ A similar clarification also needs to be added to the kill operation (Clause 21.3.8).
+
+
+
+ + + + + + + + + + +
+ (0010051) +
+ Jens Grabowski    +
+ 25-05-2011 13:58    +
+ 		+ + + + +
+ Resolution adds notes to clauses 21.3.7 (Done operation) and 21.3.8 (Killed operation).
+
+Assigned to Jacob for proofreading.
+
+
+
+ + + + + + + + + + +
+ (0010052) +
+ Jens Grabowski    +
+ 25-05-2011 14:18    +
+ 		+ + + + +
+ Res-CR5867-110525-ver2.doc is an update after a short discussion among Jens and Jacob.
+
+Assigned to Ina for Implementation.
+
+
+
+ + + + + + + + + + +
+ (0010055) +
+ Ina Schieferdecker    +
+ 25-05-2011 14:58    +
(edited on: 25-05-2011 14:59)
+ 		+ + + + +
+ One more update as the explaination about the state change could be more specific - see ver3. Assigned to Jacob to check.
+
+
+
+
+
+ + + + + + + + + + +
+ (0010058) +
+ Jacob Wieland - Spirent    +
+ 25-05-2011 15:40    +
+ 		+ + + + +
+ Basically deleted all the different scenarios where the result could be different and just referenced the annex about the state changes. That way, nothing can be forgotten.
+
+
+
+ + + + + + + + + + +
+ (0010169) +
+ Ina Schieferdecker    +
+ 30-06-2011 18:01    +
+ 		+ + + + +
+ Implemented as proposed.
+
+ + diff --git a/docs/mantis/CR5869.md b/docs/mantis/CR5869.md new file mode 100644 index 0000000000000000000000000000000000000000..031c475ae517405dc592c8ccf481c157fa5b1883 --- /dev/null +++ b/docs/mantis/CR5869.md @@ -0,0 +1,105 @@ + + + + + + + + + + + + + 0005869: template restriction examples - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005869Part 01: TTCN-3 Core LanguageClarificationpublic08-03-2011 13:2001-07-2011 17:13
ReporterAxel Rennoch 
Assigned ToIna Schieferdecker 
PrioritylowSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.3.2 (interim 2011)Fixed in Versionv4.3.2 (interim 2011) 
Clause Reference(s)15.8
Source (company - Author)Axel Rennoch, Fokus
Summary0005869: template restriction examples
Descriptionthe following examples do not conform to the systax relating template restriction:
+
+var template ExampleType (omit) v_omit;
+var template ExampleType (present) v_present;
+var template ExampleType (value) v_value;
Steps To Reproduce
Additional Informationproposed correction according to syntax
+
+var template (omit) ExampleType v_omit;
+var template (present) ExampleType v_present;
+var template (value) ExampleType v_value;
TagsNo tags attached.
Relationships
related to 0005956closed Ina Schieferdecker Syntax error in the example of section 15.8 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
08-03-2011 13:20Axel RennochNew Issue
08-03-2011 13:20Axel RennochClause Reference(s) => 15.8
08-03-2011 13:20Axel RennochSource (company - Author) => Axel Rennoch, Fokus
24-05-2011 14:37Gyorgy RethyProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
24-05-2011 14:38Gyorgy RethyNote Added: 0010017
24-05-2011 14:38Gyorgy RethyAssigned To => Ina Schieferdecker
24-05-2011 14:38Gyorgy RethyStatusnew => assigned
24-05-2011 14:38Gyorgy RethyFixed in Version => Edition 4.3.2 (interim)
24-05-2011 19:09Gyorgy RethyFixed in VersionEdition 4.3.2 (interim) =>
24-05-2011 19:09Gyorgy RethyTarget Version => Edition 4.3.2 (interim)
24-05-2011 19:17Gyorgy RethyPrioritynormal => low
25-05-2011 16:03Ina SchieferdeckerStatusassigned => resolved
25-05-2011 16:03Ina SchieferdeckerResolutionopen => fixed
01-07-2011 17:12Ina SchieferdeckerNote Added: 0010196
01-07-2011 17:13Ina SchieferdeckerStatusresolved => closed
01-07-2011 17:13Ina SchieferdeckerFixed in Version => Edition 4.3.2 (interim)
28-11-2011 13:07Ina SchieferdeckerRelationship addedrelated to 0005956
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010017) +
+ Gyorgy Rethy    +
+ 24-05-2011 14:38    +
+ 		+ + + + +
+ Correct the examples.
+
+
+
+ + + + + + + + + + +
+ (0010196) +
+ Ina Schieferdecker    +
+ 01-07-2011 17:12    +
+ 		+ + + + +
+ As proposed
+
+ + diff --git a/docs/mantis/CR5870.md b/docs/mantis/CR5870.md new file mode 100644 index 0000000000000000000000000000000000000000..a66c118285070b32e1e4d26534e3868690cb3d4f --- /dev/null +++ b/docs/mantis/CR5870.md @@ -0,0 +1,91 @@ + + + + + + + + + + + + + 0005870: wrong syntax used in example - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005870Part 01: TTCN-3 Core LanguageClarificationpublic08-03-2011 14:5501-07-2011 14:51
ReporterAxel Rennoch 
Assigned ToIna Schieferdecker 
PrioritylowSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.3.2 (interim 2011)Fixed in Versionv4.3.2 (interim 2011) 
Clause Reference(s)27.1.2
Source (company - Author)Axel Rennoch, Fokus
Summary0005870: wrong syntax used in example
Descriptiontype definitions of MyRecordB in EXAMPLE 1 and 2 inculdes wrong syntax, e.g.:
+
+    type record MyRecordB
+    {
+         :
+        field MyRecordA
+    }
+
+
+
+type record MyRecordB
+    {
+         :
+        fieldA MyRecordA
+    }
Steps To Reproduce
Additional Informationshould be changed to:
+
+
+    type record MyRecordB
+    {
+         :
+        MyRecordA field
+    }
+
+
+type record MyRecordB
+    {
+         :
+        MyRecordA fieldA
+    }
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
08-03-2011 14:55Axel RennochNew Issue
08-03-2011 14:55Axel RennochClause Reference(s) => 27.1.2
08-03-2011 14:55Axel RennochSource (company - Author) => Axel Rennoch, Fokus
24-05-2011 14:36Gyorgy RethyNote Added: 0010016
24-05-2011 14:36Gyorgy RethyAssigned To => Ina Schieferdecker
24-05-2011 14:36Gyorgy RethyStatusnew => assigned
24-05-2011 14:37Gyorgy RethyProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
24-05-2011 19:09Gyorgy RethyTarget Version => Edition 4.3.2 (interim)
24-05-2011 19:16Gyorgy RethyPrioritynormal => low
25-05-2011 15:41Ina SchieferdeckerStatusassigned => resolved
25-05-2011 15:41Ina SchieferdeckerResolutionopen => fixed
01-07-2011 14:51Ina SchieferdeckerStatusresolved => closed
01-07-2011 14:51Ina SchieferdeckerFixed in Version => Edition 4.3.2 (interim)
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010016) +
+ Gyorgy Rethy    +
+ 24-05-2011 14:36    +
+ 		+ + + + +
+ Comment is correct.
+
+ + diff --git a/docs/mantis/CR5873.md b/docs/mantis/CR5873.md new file mode 100644 index 0000000000000000000000000000000000000000..9c7337d0baa462c3e7cff148891df9e5bfd256fa --- /dev/null +++ b/docs/mantis/CR5873.md @@ -0,0 +1,211 @@ + + + + + + + + + + + + + 0005873: Table A.2 incomplete - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005873Part 01: TTCN-3 Core LanguageEditorialpublic29-03-2011 15:5801-07-2011 17:39
ReporterClaude Desroches 
Assigned ToIna Schieferdecker 
PrioritylowSeveritytrivialReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.3.2 (interim 2011)Fixed in Versionv4.3.2 (interim 2011) 
Clause Reference(s)A.1.5 TTCN-3 terminals
Source (company - Author)     BluKaktus Communications
Summary0005873: Table A.2 incomplete
DescriptionA.1.5 TTCN-3 terminals
+
+Equivalence operator symbols != == >= <= ( list in incomplete)
+
+This error is present in version V4.2.1
+
+NOTE: The Product Version drop down menu in the Mantis Change Request tool also needs to be updated to allow one to select version 4.2.1 to report errors in that version.
Steps To Reproduce
Additional InformationAdd missing the operators: > and <
TagsNo tags attached.
Relationships
Attached Filesdocx CR5873.docx (16,526) 25-05-2011 15:54
http://oldforge.etsi.org/mantis/file_download.php?file_id=2490&type=bug
docx CR5873-rev1-110526.docx (16,937) 26-05-2011 12:11
http://oldforge.etsi.org/mantis/file_download.php?file_id=2498&type=bug
Issue History
Date ModifiedUsernameFieldChange
29-03-2011 15:58Claude DesrochesNew Issue
29-03-2011 15:58Claude DesrochesClause Reference(s) => A.1.5 TTCN-3 terminals
29-03-2011 15:58Claude DesrochesSource (company - Author) => BluKaktus Communications
24-05-2011 14:33Gyorgy RethyNote Added: 0010015
24-05-2011 14:34Gyorgy RethyNote Edited: 0010015
24-05-2011 14:34Gyorgy RethyStatusnew => assigned
24-05-2011 14:34Gyorgy RethyAssigned To => Ina Schieferdecker
24-05-2011 19:08Gyorgy RethyTarget Version => Edition 4.3.2 (interim)
24-05-2011 19:16Gyorgy RethyPrioritynormal => low
25-05-2011 15:54Ina SchieferdeckerFile Added: CR5873.docx
25-05-2011 15:55Ina SchieferdeckerNote Added: 0010063
25-05-2011 15:55Ina SchieferdeckerAssigned ToIna Schieferdecker => Jens Grabowski
26-05-2011 12:11Jens GrabowskiFile Added: CR5873-rev1-110526.docx
26-05-2011 12:13Jens GrabowskiNote Added: 0010081
26-05-2011 12:13Jens GrabowskiAssigned ToJens Grabowski => Ina Schieferdecker
26-05-2011 14:20Ina SchieferdeckerNote Added: 0010087
26-05-2011 14:20Ina SchieferdeckerNote Edited: 0010087
26-05-2011 14:20Ina SchieferdeckerStatusassigned => resolved
26-05-2011 14:20Ina SchieferdeckerResolutionopen => fixed
01-07-2011 17:38Ina SchieferdeckerNote Added: 0010200
01-07-2011 17:39Ina SchieferdeckerStatusresolved => closed
01-07-2011 17:39Ina SchieferdeckerFixed in Version => Edition 4.3.2 (interim)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010015) +
+ Gyorgy Rethy    +
+ 24-05-2011 14:33    +
(edited on: 24-05-2011 14:34)
+ 		+ + + + +
+ Correct this. Add also shift operators and make the table consistent with $7.1.
+
+
+
+
+
+ + + + + + + + + + +
+ (0010063) +
+ Ina Schieferdecker    +
+ 25-05-2011 15:55    +
+ 		+ + + + +
+ Please check
+
+
+
+ + + + + + + + + + +
+ (0010081) +
+ Jens Grabowski    +
+ 26-05-2011 12:13    +
+ 		+ + + + +
+ In revision 1, the "," has been added and the description of "[ ...]" and ";" has been changed.
+
+Please check!
+
+
+
+ + + + + + + + + + +
+ (0010087) +
+ Ina Schieferdecker    +
+ 26-05-2011 14:20    +
+ 		+ + + + +
+ ok, but replace "specificator" with "specifier"
+
+
+
+
+
+ + + + + + + + + + +
+ (0010200) +
+ Ina Schieferdecker    +
+ 01-07-2011 17:38    +
+ 		+ + + + +
+ As proposed.
+
+ + diff --git a/docs/mantis/CR5874.md b/docs/mantis/CR5874.md new file mode 100644 index 0000000000000000000000000000000000000000..6b89457b9758bdda09e4318719aa63e4a0f3bff7 --- /dev/null +++ b/docs/mantis/CR5874.md @@ -0,0 +1,333 @@ + + + + + + + + + + + + + 0005874: language keyword in module definition allows multiple TTCN-3 version FreeText identifiers. - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005874Part 01: TTCN-3 Core LanguageClarificationpublic30-03-2011 14:1501-07-2011 17:10
ReporterClaude Desroches 
Assigned ToIna Schieferdecker 
PrioritylowSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.1.1 (published 2009-06) 
Target Versionv4.3.2 (interim 2011)Fixed in Versionv4.3.2 (interim 2011) 
Clause Reference(s)8.1 Definition of a module and A.1.6.0 TTCN-3 module
Source (company - Author)BluKaktus Communications
Summary0005874: language keyword in module definition allows multiple TTCN-3 version FreeText identifiers.
DescriptionTTCN-3 Version 4.2.1
+
+In 8.1 Definition of a module
+
+module ModuleIdentifier [ language FreeText { "," FreeText } ] "{"
+[ ModuleDefinitionsPart ]
+[ ModuleControlPart ]
+"}"
+
+nothing prevents a user frpm writing something like:
+
+module myModule language "TTCN-3:2001", "TTCN-3:2010", "TTCN-3:2009"
+{
+
+}
+
+Most tools would probably generate an error, however, it might be better to prevent such things.
+
+Further if you have two modules, one using "TTCN-3:2001" and the other using
+"TTCN-3:2010", what should happen if you import types from one module into the other? Will language syntax and semantics for the importing module be used or will the syntax and semantics from the imported module be adopted.
+
+To my knowledge, I don't believe there is any tool on the market which supports multiple versions of TTCN-3 within the same project.
+
+
+Is the following permitted?
+module myModule language "TTCN-3:2010", "TTCN-3:2010", "TTCN-3:2010"
+{
+
+}
+
+(from the grammar point of view it is permitted).
+
+What should happen if one enters:
+
+module myModule language "TTCN-3:2222" // or some other illegal value?
+{
+
+}
+
+There is no information related to processing of the strings and verification of their validity.
+
+
+
+What would that actually mean?
+
+For a compiler this would likely be impossible to resolve because of possibly conflicts which lie in differing grammar defintions.
+
+What should a compiler do? take the first FreeText string or the last one or ignore all of them and choose the current version?
+
+ 
+
+"TTCN-3:2001" - to be used with modules complying with version 1.1.2 of the present document (see annex H).
+"TTCN-3:2003" - to be used with modules complying with version 2.2.1 of the present document (see annex H).
+"TTCN-3:2005" - to be used with modules complying with version 3.1.1 of the present document (see annex H).
+"TTCN-3:2007" - to be used with modules complying with version 3.2.1 of the present document (see annex H).
+"TTCN-3:2008" - to be used with modules complying with version 3.3.2 of the present document (see annex H).
+"TTCN-3:2008 Amendment 1" - to be used with modules complying with version 3.4.1 of the present document
+(see annex H).
+"TTCN-3:2009" - to be used with modules complying with version 4.1.1 of the present document (see annex H).
+"TTCN-3:2010" - to be used with modules complying with the present document.
Steps To Reproduce
Additional Information1) Clarify the text in section 8.1
+
+2) Augment the grammar rules 1 - 8 with static semantic rule(s)
+    to only allow for one TTCN-3 version in a given module.
+
+3) Modify the grammar to limit one to
+    a single TTCN-3 version for a given TTCN-3 module (excluding packages)
+    Actually, one could consider adding the keyword 'package' followed
+    by any valid package or proprietary packages.
+
+Change:
+
+module ModuleIdentifier [ language FreeText { "," FreeText } ] "{"
+[ ModuleDefinitionsPart ]
+[ ModuleControlPart ]
+"}"
+
+
+module ModuleIdentifier
+  [ language FreeText ";" ]
+  [ package FreeText "," { FreeText } ]
+"{"
+[ ModuleDefinitionsPart ]
+[ ModuleControlPart ]
+"}"
+
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
30-03-2011 14:15Claude DesrochesNew Issue
30-03-2011 14:15Claude DesrochesClause Reference(s) => 8.1 Definition of a module and A.1.6.0 TTCN-3 module
30-03-2011 14:15Claude DesrochesSource (company - Author) => BluKaktus Communications
24-05-2011 14:30Gyorgy RethyNote Added: 0010014
24-05-2011 14:30Gyorgy RethyStatusnew => assigned
24-05-2011 14:30Gyorgy RethyAssigned To => Ina Schieferdecker
24-05-2011 19:07Gyorgy RethyTarget Version => Edition 4.3.2 (interim)
24-05-2011 19:16Gyorgy RethyPrioritynormal => low
25-05-2011 15:40Ina SchieferdeckerNote Added: 0010059
25-05-2011 15:40Ina SchieferdeckerNote Added: 0010060
25-05-2011 15:41Ina SchieferdeckerAssigned ToIna Schieferdecker => Gyorgy Rethy
25-05-2011 15:46Gyorgy RethyNote Added: 0010061
25-05-2011 15:47Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
25-05-2011 16:02Ina SchieferdeckerNote Added: 0010064
25-05-2011 16:02Ina SchieferdeckerStatusassigned => resolved
25-05-2011 16:02Ina SchieferdeckerResolutionopen => fixed
01-07-2011 17:09Ina SchieferdeckerNote Added: 0010195
01-07-2011 17:10Ina SchieferdeckerStatusresolved => closed
01-07-2011 17:10Ina SchieferdeckerFixed in Version => Edition 4.3.2 (interim)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010014) +
+ Gyorgy Rethy    +
+ 24-05-2011 14:30    +
+ 		+ + + + +
+ Add an explicit restriction to clause 8.1, limiting language strings one per core standard version and package. The additional package keyword proposal is not supported.
+
+
+
+ + + + + + + + + + +
+ (0010059) +
+ Ina Schieferdecker    +
+ 25-05-2011 15:40    +
+ 		+ + + + +
+ Proposal to define in 8.1:
+
+"Restrictions
+
+In addition to the general static rules of TTCN 3 given in clause 5, the following restrictions apply:
+
+a) At most one language string per module should be given to define the language version in which the module is defined.
+
+b) Per extension package, at most one extension package string of that extension package should be used to define its version used by the module."
+
+
+
+ + + + + + + + + + +
+ (0010060) +
+ Ina Schieferdecker    +
+ 25-05-2011 15:40    +
+ 		+ + + + +
+ Please check.
+
+
+
+ + + + + + + + + + +
+ (0010061) +
+ Gyorgy Rethy    +
+ 25-05-2011 15:46    +
+ 		+ + + + +
+ Rule A should say "core" language; should -> shall:
+a) At most one language string per module shall be given to define the core language version in which the module is defined.
+b) Per extension package, at most one extension package string of that extension package shall be used by the module.
+
+(package string do two things: require a given package be supported, defines/requires the version of that package; for this reason "to define its version used " is deleted as was limiting)
+
+
+
+ + + + + + + + + + +
+ (0010064) +
+ Ina Schieferdecker    +
+ 25-05-2011 16:02    +
+ 		+ + + + +
+ One more minor agreed change:
+
+"b) Per extension package, at most one extension package string of that extension package shall be used by a module."
+
+
+
+ + + + + + + + + + +
+ (0010195) +
+ Ina Schieferdecker    +
+ 01-07-2011 17:09    +
+ 		+ + + + +
+ Implemented as proposed.
+
+In addition, language tag for v4.3.1 and annex H extended as needed.
+
+ + diff --git a/docs/mantis/CR5875.md b/docs/mantis/CR5875.md new file mode 100644 index 0000000000000000000000000000000000000000..4d02ddbce9a4951c25dca18247477ef38c94011b --- /dev/null +++ b/docs/mantis/CR5875.md @@ -0,0 +1,89 @@ + + + + + + + + + + + + + 0005875: Non inuitive language edition strings - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005875Part 01: TTCN-3 Core LanguageEditorialpublic30-03-2011 14:2524-05-2011 14:23
ReporterClaude Desroches 
Assigned To 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionwon't fix 
PlatformOSOS Version
Product Versionv4.1.1 (published 2009-06) 
Target VersionFixed in Version 
Clause Reference(s)8.1 Definition of a module
Source (company - Author)Technicolor- Claude Desroches
Summary0005875: Non inuitive language edition strings
DescriptionVersion 4.2.1 of Core Notation
+
+
+"TTCN-3:2001" -version 1.1.2
+"TTCN-3:2003" -version 2.2.1
+"TTCN-3:2005" -version 3.1.1
+"TTCN-3:2007" -version 3.2.1
+"TTCN-3:2008" -version 3.3.2
+"TTCN-3:2008 Amendment 1" -version 3.4.1
+"TTCN-3:2009" -version 4.1.1
+"TTCN-3:2010" -version present version
+
+The string identifiers for the different versions are not very user friendly or intuitive. It would be easier to understand and more intuitive to use the core notation version number to avoid confusion.
+
+E.g. If a module aligns to TTCN-3 V4.2.1 then use
+the text "TTCN-3:4.2.1"
+
+There can be no confusion. This removes any type of 'mental gymnastics' the developer needs to do and there is no need for him or her to refer back to the standard core notation standard to verify what version of TTCN-3 a given string maps to.
+
+
+Why use "TTCN-3:2010" to identify version 4.2.1? (since version 4.2.1 is also
+used and defined in 2011.
+
+
+
+
Steps To Reproduce
Additional Information  
+
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
30-03-2011 14:25Claude DesrochesNew Issue
30-03-2011 14:25Claude DesrochesClause Reference(s) => 8.1 Definition of a module
30-03-2011 14:25Claude DesrochesSource (company - Author) => Technicolor- Claude Desroches
24-05-2011 14:23Gyorgy RethyNote Added: 0010013
24-05-2011 14:23Gyorgy RethyStatusnew => closed
24-05-2011 14:23Gyorgy RethyResolutionopen => won't fix
24-05-2011 14:23Gyorgy RethyAdditional Information Updated
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010013) +
+ Gyorgy Rethy    +
+ 24-05-2011 14:23    +
+ 		+ + + + +
+ Using years or version no.s is a matter of taste, we should avoid using syntactical alternatives due to taste issues.
+
+ + diff --git a/docs/mantis/CR5876.md b/docs/mantis/CR5876.md new file mode 100644 index 0000000000000000000000000000000000000000..461d582689d9ae126f28815e4eafda29bb84bca4 --- /dev/null +++ b/docs/mantis/CR5876.md @@ -0,0 +1,302 @@ + + + + + + + + + + + + + 0005876: How to use implicit omit with value list notation? - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005876Part 01: TTCN-3 Core LanguageTechnicalpublic08-04-2011 17:1301-07-2011 17:42
ReporterGyorgy Rethy 
Assigned ToIna Schieferdecker 
PriorityhighSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.3.2 (interim 2011)Fixed in Versionv4.3.2 (interim 2011) 
Clause Reference(s)6.2.3
Source (company - Author)L.M.Ericsson
Summary0005876: How to use implicit omit with value list notation?
DescriptionCurrently it is not defined in the standard, how to fill up a record/set value in case of value list notation. E.g. in the case:
+type record MyRec {
+  integer f1,
+  integer f2 optional,
+  integer f3,
+  integer f4,
+  integer f5 optional }
+const MyRec cg_MyRec := { 1,2,4 } with {optional "implicit omit"}
+// the value of cg_MyRec is { f1:=1, f2:= omit, f3:=2, f4:=4, f5 :=omit }, or an error, because
+// the value 2 is assigned to f2 and no value is assigned to the mandatory
+// field f4.
+
+SOLUTION PROPOSAL:
+The semantics should be consistent with the semantics of actual parameter lists passed to formal parameter lists with default values, i.e. even in case of implicit omit, the unassigned optional fields should be skipped explicitly by a not used symbol. I.e. the example above should cause an error and
+const MyRec cg_MyRec2 := { 1, -, 2, 4 }
+//should result the value { f1:=1, f2:= omit, f3:=2, f4:=4, f5 :=omit }
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc es_20187301v040205m_CR_5876.doc (22,016) 26-05-2011 08:48
http://oldforge.etsi.org/mantis/file_download.php?file_id=2496&type=bug
doc CR_5876_resolution_v2.doc (33,792) 27-05-2011 14:15
http://oldforge.etsi.org/mantis/file_download.php?file_id=2519&type=bug
doc CR_5876_resolution_v3.doc (25,600) 27-05-2011 16:48
http://oldforge.etsi.org/mantis/file_download.php?file_id=2521&type=bug
Issue History
Date ModifiedUsernameFieldChange
08-04-2011 17:13Gyorgy RethyNew Issue
08-04-2011 17:13Gyorgy RethyClause Reference(s) => 6.2.3
08-04-2011 17:13Gyorgy RethySource (company - Author) => L.M.Ericsson
08-04-2011 17:18Gyorgy RethyDescription Updated
09-04-2011 07:41Gyorgy RethyDescription Updated
24-05-2011 14:10Gyorgy RethyStatusnew => assigned
24-05-2011 14:10Gyorgy RethyAssigned To => Jacob Wieland - Spirent
24-05-2011 14:11Gyorgy RethyNote Added: 0010012
24-05-2011 19:06Gyorgy RethyTarget Version => Edition 4.3.2 (interim)
24-05-2011 19:15Gyorgy RethyPrioritynormal => high
25-05-2011 12:26Jacob Wieland - SpirentNote Added: 0010048
26-05-2011 08:12Jacob Wieland - SpirentNote Edited: 0010048
26-05-2011 08:48Jacob Wieland - SpirentFile Added: es_20187301v040205m_CR_5876.doc
26-05-2011 09:59Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
26-05-2011 09:59Jacob Wieland - SpirentNote Added: 0010077
27-05-2011 14:15Gyorgy RethyNote Added: 0010103
27-05-2011 14:15Gyorgy RethyFile Added: CR_5876_resolution_v2.doc
27-05-2011 14:15Gyorgy RethyNote Edited: 0010103
27-05-2011 14:16Gyorgy RethyAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
27-05-2011 16:48Jacob Wieland - SpirentFile Added: CR_5876_resolution_v3.doc
27-05-2011 16:49Jacob Wieland - SpirentNote Added: 0010108
27-05-2011 16:49Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
29-06-2011 14:27Gyorgy RethyNote Added: 0010145
29-06-2011 14:27Gyorgy RethyStatusassigned => resolved
29-06-2011 14:27Gyorgy RethyResolutionopen => fixed
29-06-2011 14:27Gyorgy RethyStatusresolved => feedback
29-06-2011 14:27Gyorgy RethyResolutionfixed => reopened
29-06-2011 14:28Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
29-06-2011 14:28Gyorgy RethyStatusfeedback => resolved
29-06-2011 14:28Gyorgy RethyResolutionreopened => fixed
01-07-2011 17:42Ina SchieferdeckerNote Added: 0010202
01-07-2011 17:42Ina SchieferdeckerStatusresolved => closed
01-07-2011 17:42Ina SchieferdeckerFixed in Version => Edition 4.3.2 (interim)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010012) +
+ Gyorgy Rethy    +
+ 24-05-2011 14:11    +
+ 		+ + + + +
+ Agreed in principle as proposed, text to be prepared.
+
+
+
+ + + + + + + + + + +
+ (0010048) +
+ Jacob Wieland - Spirent    +
+ 25-05-2011 12:26    +
(edited on: 26-05-2011 08:12)
+ 		+ + + + +
+ The following should be added to section 6.2
+
+When using value list notation in a scope where the optional attribute is set to "implicit omit", for each mandatory field there shall be an actual element. An optional field can be skipped by using dash "-" as element or by just leaving it out if no other additional element follows in the list – either because the corresponding field is the last in the type or because all following fields are optional and are also left out.
+
+EXAMPLE:
+type record R {
+  integer f1,
+  integer f2 optional,
+  integer f3,
+  integer f4 optional,
+  integer f5 optional
+}
+
+const R x := { 1, -, 2 } with { optional "implicit omit" } // valid
+const R x2 := { 1 } with { optional "implicit omit" } // invalid because of f3
+
+
+
+
+
+ + + + + + + + + + +
+ (0010077) +
+ Jacob Wieland - Spirent    +
+ 26-05-2011 09:59    +
+ 		+ + + + +
+ Please review
+
+
+
+ + + + + + + + + + +
+ (0010103) +
+ Gyorgy Rethy    +
+ 27-05-2011 14:15    +
+ 		+ + + + +
+ I have changed the text to be more explicit. Also, just saying valid or invalid in the examples is not sufficient, the user has to know what is actually happening. Thus, I have changed the examples to var-s and specified their contents after the assignment, just like in the examples before the new paragraph.
+Updated text is in CR_5876_resolution_v2.doc. Jacob, pls. review.
+
+
+
+
+
+ + + + + + + + + + +
+ (0010108) +
+ Jacob Wieland - Spirent    +
+ 27-05-2011 16:49    +
+ 		+ + + + +
+ corrected the explanation in some places, please review
+
+
+
+ + + + + + + + + + +
+ (0010145) +
+ Gyorgy Rethy    +
+ 29-06-2011 14:27    +
+ 		+ + + + +
+ Fine with me, see final resolution in CR_5876_resolution_v3.doc
+
+
+
+ + + + + + + + + + +
+ (0010202) +
+ Ina Schieferdecker    +
+ 01-07-2011 17:42    +
+ 		+ + + + +
+ Implemented as proposed.
+
+ + diff --git a/docs/mantis/CR5877.md b/docs/mantis/CR5877.md new file mode 100644 index 0000000000000000000000000000000000000000..7566c60ce69cdd4a9cce89dfbdd663981124a6c1 --- /dev/null +++ b/docs/mantis/CR5877.md @@ -0,0 +1,605 @@ + + + + + + + + + + + + + 0005877: Semantics of TSI->multiple components connection is unspecified - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005877Part 01: TTCN-3 Core LanguageClarificationpublic09-04-2011 18:0411-07-2012 10:27
ReporterGyorgy Rethy 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.4.1 (published 2012-04)Fixed in Versionv4.5.1 (published 2013-04) 
Clause Reference(s)9.1
Source (company - Author)L.M. Ericsson
Summary0005877: Semantics of TSI->multiple components connection is unspecified
DescriptionClause 9.1 allows a connection when one TSI interface is mapped to ports of different test components (see figure 6.h)). However the semantics of this configuration is not defined. From the test component point of view this is a one-to-one connection, therefore no to/from clauses required.
+
+SOLUTION PROPOSAL
+Add a sentence to clause 9.1 clarifying that in this configuration the TSI shall put the received messages into the port queues of all connected TCs. As in this case addressing is not possible, this seems to be the only possible way.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc es_20187301v040205m_CR_5877.doc (114,176) 27-05-2011 16:26
http://oldforge.etsi.org/mantis/file_download.php?file_id=2520&type=bug
doc es_20187301v040205m_CR_5877_v2.doc (128,000) 29-06-2011 16:41
http://oldforge.etsi.org/mantis/file_download.php?file_id=2525&type=bug
Issue History
Date ModifiedUsernameFieldChange
09-04-2011 18:04Gyorgy RethyNew Issue
09-04-2011 18:04Gyorgy RethyClause Reference(s) => 9.1
09-04-2011 18:04Gyorgy RethySource (company - Author) => L.M. Ericsson
24-05-2011 12:40Gyorgy RethyNote Added: 0010010
24-05-2011 12:40Gyorgy RethyStatusnew => assigned
24-05-2011 12:40Gyorgy RethyAssigned To => Jacob Wieland - Spirent
24-05-2011 13:50Gyorgy RethyNote Added: 0010011
24-05-2011 19:06Gyorgy RethyTarget Version => Edition 4.3.2 (interim)
25-05-2011 11:09Jacob Wieland - SpirentNote Added: 0010045
25-05-2011 11:14Jacob Wieland - SpirentNote Edited: 0010045
26-05-2011 09:53Gyorgy RethyNote Added: 0010076
26-05-2011 12:13Jacob Wieland - SpirentFile Added: es_20187301v040205m_CR_5877.doc
26-05-2011 12:13Jacob Wieland - SpirentNote Added: 0010080
26-05-2011 12:13Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
27-05-2011 14:18Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
27-05-2011 14:19Gyorgy RethyAssigned ToIna Schieferdecker => Gyorgy Rethy
27-05-2011 14:25Gyorgy RethyNote Added: 0010104
27-05-2011 14:25Gyorgy RethyAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
27-05-2011 16:26Jacob Wieland - SpirentFile Deleted: es_20187301v040205m_CR_5877.doc
27-05-2011 16:26Jacob Wieland - SpirentFile Added: es_20187301v040205m_CR_5877.doc
27-05-2011 16:27Jacob Wieland - SpirentNote Added: 0010107
27-05-2011 16:29Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
29-06-2011 16:41Gyorgy RethyFile Added: es_20187301v040205m_CR_5877_v2.doc
29-06-2011 16:43Gyorgy RethyNote Added: 0010148
29-06-2011 16:43Gyorgy RethyAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
30-06-2011 16:39Jacob Wieland - SpirentNote Added: 0010163
30-06-2011 16:39Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
27-09-2011 13:59Gyorgy RethyTarget VersionEdition 4.3.2 (interim) => Edition 4.4.1
30-11-2011 10:27Gyorgy RethyNote Added: 0010425
30-11-2011 10:27Gyorgy RethyAssigned ToGyorgy Rethy => Jens Grabowski
30-11-2011 14:16Gyorgy RethyAssigned ToJens Grabowski => Gyorgy Rethy
02-12-2011 09:38Gyorgy RethyNote Added: 0010501
02-12-2011 09:39Gyorgy RethyAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
02-12-2011 09:39Gyorgy RethyNote Edited: 0010501
02-12-2011 10:47Jacob Wieland - SpirentStatusassigned => resolved
02-12-2011 10:47Jacob Wieland - SpirentResolutionopen => fixed
02-12-2011 10:47Jacob Wieland - SpirentNote Added: 0010506
02-12-2011 10:50Jacob Wieland - SpirentStatusresolved => feedback
02-12-2011 10:50Jacob Wieland - SpirentResolutionfixed => reopened
02-12-2011 10:50Jacob Wieland - SpirentNote Added: 0010507
02-12-2011 10:51Jacob Wieland - SpirentStatusfeedback => assigned
02-12-2011 10:51Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Ina Schieferdecker
02-12-2011 10:52Jacob Wieland - SpirentStatusassigned => resolved
02-12-2011 10:52Jacob Wieland - SpirentResolutionreopened => fixed
02-12-2011 10:52Jacob Wieland - SpirentNote Added: 0010508
11-07-2012 10:27Ina SchieferdeckerNote Added: 0010811
11-07-2012 10:27Ina SchieferdeckerStatusresolved => closed
11-07-2012 10:27Ina SchieferdeckerFixed in Version => Edition 4.5.1
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010010) +
+ Gyorgy Rethy    +
+ 24-05-2011 12:40    +
+ 		+ + + + +
+ Check the current situation in Parts 1 and 5 and with tool vendors , if needed.
+
+
+
+ + + + + + + + + + +
+ (0010011) +
+ Gyorgy Rethy    +
+ 24-05-2011 13:50    +
+ 		+ + + + +
+ Implications to be considered: broadcast or routing within TSI? By default we are not considering to limit the TSI to one2one mappings.
+- shall we allow/require specifying the type of the adaptor in TTCN-3?
+- if yes, should it be in the port type definition or in the map or ?
+- shall it be formal or informal?
+- etc.
+
+
+
+ + + + + + + + + + +
+ (0010045) +
+ Jacob Wieland - Spirent    +
+ 25-05-2011 11:09    +
(edited on: 25-05-2011 11:14)
+ 		+ + + + +
+ If we want to allow restricting/specifying the behavior of the adapter in TTCN-3, different approaches can be taken:
+
+1. introduce additional port modifiers like 'realtime': broadcast, unicast.
+
+type port P mixed broadcast { ... }
+-> This means that the test adapter is supposed to call triEnqueue<X>() for all components mapped to this port for any message/reply/call/exception received on this port.
+
+type port P mixed unicast { ... }
+-> This means that the test adapter must be able to disambiguate the recipient component and shall only call triEnqueue<X>() for this component.
+
+- Drawback: two new keywords (although it would be possible to say in the BNF that any identifier can be a port modifier with the STATIC SEMANTICS that only those having a defined meaning are accepted before the opening brackets).
+
+2. Another formal way would be to use a new kind of attribute:
+
+type port P mixed { ... }
+with {
+  receive "broadcast"
+}
+
+type port P mixed { ... }
+with {
+  receive "unicast"
+}
+
+This has additional advantages:
+- the attribute could be restricted to certain 'members', i.e. types/signatures of the port definition.
+
+type port P mixed { inout T1, T2, T3 }
+with {
+  receive (T1) "unicast"
+  receive (T2) "broadcast"
+}
+
+=> for T1, the port would impose unicast-restriction, for T2 broadcast-restriction and for T3 no restriction would be imposed on the test adapter.
+
+- also we would not have to introduce new keywords, just a new attribute kind.
+
+The drawback of this approach is that it must be communicated to the testadapter somehow, for which types it should employ which behavior (it it is a generic one). I.e. we would need a new function with a signature like: tciGetReceiveAttribute(in TriPortId port, in TciType type, out TciReceiveKind kind).
+
+To avoid this drawback, usage of that attribute with a list of types/signatures could be forbidden, i.e. the whole port is either broadcast or unicast or decide-it-yourself.
+
+3. The last alternative would be to use the informal way of using extension attributes:
+
+type port P mixed { inout T1, T2, T3 }
+with {
+  extension (T1) "receive:unicast"
+  extension (T2) "receive:broadcast"
+}
+
+It has the same advantages and drawbacks of alternative 2.
+
+Modifying the map operation in my opinion is the wrong approach as that is only associated with one port-to-port mapping and has nothing to do with multi-port-to-one-port mapping. Also, this would imply that the testadapters behaviour would need to be dynamically changeable depending on the last map-statement.
+
+
+
+
+
+ + + + + + + + + + +
+ (0010076) +
+ Gyorgy Rethy    +
+ 26-05-2011 09:53    +
+ 		+ + + + +
+ A mixure of options 2 and 3 are agreed, add the new attribute system but with defined strings "receive:unicast" and "receive:broadcast". Use the general attribute overriding rules.
+
+
+
+ + + + + + + + + + +
+ (0010080) +
+ Jacob Wieland - Spirent    +
+ 26-05-2011 12:13    +
+ 		+ + + + +
+ added a proposal, please review
+
+
+
+ + + + + + + + + + +
+ (0010104) +
+ Gyorgy Rethy    +
+ 27-05-2011 14:25    +
+ 		+ + + + +
+ Actually, when opening the file, I cannot see any tracked changes, therefore there is nothing to be reviewed (yet). Also, I can see that the file contains only clause 27 and the BNF. Semantical description shall either be given in clause 9.1 and referenced from clause 27 or vice versa. But I think clause 9.1 would be a more natural place.
+
+
+
+ + + + + + + + + + +
+ (0010107) +
+ Jacob Wieland - Spirent    +
+ 27-05-2011 16:27    +
+ 		+ + + + +
+ somehow the change bars got lost. I've added a sentence to 9.1 and added section 27.8 and the system alternative in the grammar
+
+
+
+ + + + + + + + + + +
+ (0010148) +
+ Gyorgy Rethy    +
+ 29-06-2011 16:43    +
+ 		+ + + + +
+ Technically OK. I have revised the text at some places in 27.8, to e more specific. Pls. check in es_20187301v040205m_CR_5877_v2.doc.
+
+
+
+ + + + + + + + + + +
+ (0010163) +
+ Jacob Wieland - Spirent    +
+ 30-06-2011 16:39    +
+ 		+ + + + +
+ Apart from the changes from 'component' to 'port' it's ok.
+
+However these changes are wrong as the tri-function get componentIds and not portIds, so the test adapter needs to know the right components to call these functions for, not the ports.
+
+
+
+ + + + + + + + + + +
+ (0010425) +
+ Gyorgy Rethy    +
+ 30-11-2011 10:27    +
+ 		+ + + + +
+ I have too much CRs assigned, Jens, pls. review.
+
+
+
+ + + + + + + + + + +
+ (0010501) +
+ Gyorgy Rethy    +
+ 02-12-2011 09:38    +
(edited on: 02-12-2011 09:39)
+ 		+ + + + +
+ It's OK with me.
+The standard does not specify the way it is implemented, but the perception of the user. Of course, in a real system you will use a componentIds to identify the receipent, but writing this in the abstract language's spec. could mismatch the user. Different types of ports may require different unicast/broadcast behaviour: this has to be considered in adapter implementations. Thus, saying that the system attribute defines the behaviour of the component would be misleading; one port type of a component may require unicast, while the other port type of the same component broadcast.
+If you agree, pls. set it to resolved and assign the CR to Ina.
+
+
+
+
+
+ + + + + + + + + + +
+ (0010506) +
+ Jacob Wieland - Spirent    +
+ 02-12-2011 10:47    +
+ 		+ + + + +
+ okay
+
+
+
+ + + + + + + + + + +
+ (0010507) +
+ Jacob Wieland - Spirent    +
+ 02-12-2011 10:50    +
+ 		+ + + + +
+ reopen for reassignment
+
+
+
+ + + + + + + + + + +
+ (0010508) +
+ Jacob Wieland - Spirent    +
+ 02-12-2011 10:52    +
+ 		+ + + + +
+ closed again
+
+
+
+ + + + + + + + + + +
+ (0010811) +
+ Ina Schieferdecker    +
+ 11-07-2012 10:27    +
+ 		+ + + + +
+ Implemented as proposed in v2 with editorial adjustments
+
+ + diff --git a/docs/mantis/CR5878.md b/docs/mantis/CR5878.md new file mode 100644 index 0000000000000000000000000000000000000000..efdaa51f8ee28437e771bf425c7ed9e069521c54 --- /dev/null +++ b/docs/mantis/CR5878.md @@ -0,0 +1,472 @@ + + + + + + + + + + + + + 0005878: TCI TL Java mapping in Chapter 8.5.4.1 needs editoral corrections - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005878Part 06: TTCN-3 Control InterfaceEditorialpublic27-04-2011 12:3730-09-2011 16:42
Reportertepelmann 
Assigned ToIna Schieferdecker 
PrioritylowSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.4.1 (published 2012-04)Fixed in Versionv4.4.1 (published 2012-04) 
Clause Reference(s) 8.5.4.1
Source (company - Author)     tepelmann
Summary0005878: TCI TL Java mapping in Chapter 8.5.4.1 needs editoral corrections
DescriptionIn ETSI ES 201 873-6 V4.2.1 (2010-07) the Java mapping of the TCI-TL interface contains errors:
+- tliMSend_m_BC:
+  -> comma is missing between msgValue and encoderFailure
+- tliPrGetReplyDetected_m, tliPrGetReplyDetected_c
+  -> "in TriParameterList(Type) triPars" should be "TriParameterList triPars"
+- tliPrGetReplyMismatch_m, tliPrGetReplyMismatch_c, tliPrGetReply_m, tliPrGetReply_c
+  -> "in TciValueTemplate parsTmpl" should be "TciValueTemplate parsTmpl"
+- tliTStop
+  -> "in TriTimerDuration dur" should be "TriTimerDuration dur"
+- tliLog
+  -> "Tstring log" should be "String log"
+- tliInfo
+  -> "TriComponent c" should be "TriComponentId c"
+  -> semicolon at the end missing
Steps To Reproduce
Additional InformationHere all editorial changes collected:
+// TCI-TL
+// TE, TM,CH,CD, SA,PA -> TL
+package org.etsi.ttcn.tci;
+
+import org.etsi.ttcn.tri.TriAddress;
+import org.etsi.ttcn.tri.TriAddressList;
+import org.etsi.ttcn.tri.TriComponentId;
+import org.etsi.ttcn.tri.TriException;
+import org.etsi.ttcn.tri.TriMessage;
+import org.etsi.ttcn.tri.TriParameter;
+import org.etsi.ttcn.tri.TriParameterList;
+import org.etsi.ttcn.tri.TriPortId;
+import org.etsi.ttcn.tri.TriPortIdList;
+import org.etsi.ttcn.tri.TriSignatureId;
+import org.etsi.ttcn.tri.TriStatus;
+import org.etsi.ttcn.tri.TriTimerDuration;
+import org.etsi.ttcn.tri.TriTimerId;
+
+public interface TciTLProvided {
+  public void tliTcExecute(String am, int ts, String src, int line, TriComponentId c,
+      TciTestCaseId tcId, TriParameterList triPars, TriTimerDuration dur);
+  public void tliTcStart(String am, int ts, String src, int line, TriComponentId c,
+      TciTestCaseId tcId, TciParameterList tciPars, TriTimerDuration dur);
+  public void tliTcStop(String am, int ts, String src, int line, TriComponentId c);
+  public void tliTcStarted(String am, int ts, String src, int line, TriComponentId c,
+      TciTestCaseId tcId, TciParameterList tciPars, TriTimerDuration dur);
+  public void tliTcTerminated(String am, int ts, String src, int line, TriComponentId c,
+      TciTestCaseId tcId, TciParameterList tciPars, VerdictValue verdict);
+  public void tliCtrlStart(String am, int ts, String src, int line, TriComponentId c);
+  public void tliCtrlStop(String am, int ts, String src, int line, TriComponentId c);
+  public void tliCtrlTerminated(String am, int ts, String src, int line, TriComponentId c);
+  public void tliMSend_m(String am, int ts, String src, int line, TriComponentId c,
+      TriPortId at, TriPortId to, Value msgValue, Value addrValue,
+      TciStatus encoderFailure, TriMessage msg, TriAddress address,
+      TriStatus transmissionFailure);
+  public void tliMSend_m_BC(String am, int ts, String src, int line, TriComponentId c,
+      TriPortId at, TriPortId to, Value msgValue,
+      TciStatus encoderFailure, TriMessage msg, TriStatus transmissionFailure) ;
+  public void tliMSend_m_MC(String am, int ts, String src, int line, TriComponentId c,
+      TriPortId at, TriPortId to, Value msgValue, TciValueList addrValues,
+      TciStatus encoderFailure, TriMessage msg, TriAddressList addresses,
+      TriStatus transmissionFailure);
+  public void tliMSend_c(String am, int ts, String src, int line, TriComponentId c,
+      TriPortId at, TriPortId to, Value msgValue, TriStatus transmissionFailure);
+  public void tliMSend_c_BC(String am, int ts, String src, int line, TriComponentId c,
+      TriPortId at, TriPortIdList to, Value msgValue, TriStatus transmissionFailure);
+  public void tliMSend_c_MC(String am, int ts, String src, int line, TriComponentId c,
+      TriPortId at, TriPortIdList to, Value msgValue, TriStatus transmissionFailure);
+  public void tliMDetected_m(String am, int ts, String src, int line, TriComponentId c,
+      TriPortId at, TriPortId from, TriMessage msg, TriAddress address);
+  public void tliMDetected_c(String am, int ts, String src, int line, TriComponentId c,
+      TriPortId at, TriPortId from, Value msgValue );
+  public void tliMMismatch_m(String am, int ts, String src, int line, TriComponentId c,
+      TriPortId at, Value msgValue, TciValueTemplate msgTmpl, TciValueDifferenceList diffs,
+      Value addrValue, TciValueTemplate addressTmpl);
+  public void tliMMismatch_c(String am, int ts, String src, int line, TriComponentId c,
+      TriPortId at, Value msgValue, TciValueTemplate msgTmpl, TciValueDifferenceList diffs,
+      TriComponentId from, TciNonValueTemplate fromTmpl);
+  public void tliMReceive_m(String am, int ts, String src, int line, TriComponentId c,
+      TriPortId at, Value msgValue, TciValueTemplate msgTmpl,
+      Value addrValue, TciValueTemplate addressTmpl);
+  public void tliMReceive_c(String am, int ts, String src, int line, TriComponentId c,
+      TriPortId at, Value msgValue, TciValueTemplate msgTmpl,
+      TriComponentId from, TciNonValueTemplate fromTmpl);
+  public void tliPrCall_m(String am, int ts, String src, int line, TriComponentId c,
+      TriPortId at, TriPortId to, TriSignatureId signature, TciParameterList tciPars,
+      Value addrValue, TciStatus encoderFailure, TriParameterList triPars,
+      TriAddress address, TriStatus transmissionFailure);
+  public void tliPrCall_m_BC(String am, int ts, String src, int line, TriComponentId c,
+      TriPortId at, TriPortId to, TriSignatureId signature, TciParameterList tciPars,
+      TciStatus encoderFailure, TriParameterList triPars,
+      TriStatus transmissionFailure);
+  public void tliPrCall_m_MC(String am, int ts, String src, int line, TriComponentId c,
+      TriPortId at, TriPortId to, TriSignatureId signature, TciParameterList tciPars,
+      TciValueList addrValues, TciStatus encoderFailure, TriParameterList triPars,
+      TriAddressList addresses, TriStatus transmissionFailure);
+  public void tliPrCall_c(String am, int ts, String src, int line, TriComponentId c,
+      TriPortId at, TriPortId to, TriSignatureId signature, TciParameterList tciPars,
+      TriStatus transmissionFailure);
+  public void tliPrCall_c_BC(String am, int ts, String src, int line, TriComponentId c,
+      TriPortId at, TriPortIdList to, TriSignatureId signature, TciParameterList tciPars,
+      TriStatus transmissionFailure);
+  public void tliPrCall_c_MC(String am, int ts, String src, int line, TriComponentId c,
+      TriPortId at, TriPortIdList to, TriSignatureId signature, TciParameterList tciPars,
+      TriStatus transmissionFailure);
+  public void tliPrGetCallDetected_m(String am, int ts, String src, int line, TriComponentId c,
+      TriPortId at, TriPortId from, TriSignatureId signature, TriParameterList triPars,
+      TriAddress address);
+  public void tliPrGetCallDetected_c(String am, int ts, String src, int line, TriComponentId c,
+      TriPortId at, TriPortId from, TriSignatureId signature, TciParameterList tciPars );
+  public void tliPrGetCallMismatch_m(String am, int ts, String src, int line, TriComponentId c,
+      TriPortId at, TriSignatureId signature,
+      TciParameterList tciPars, TciValueTemplate parsTmpl, TciValueDifferenceList diffs,
+      Value addrValue, TciValueTemplate addressTmpl);
+  public void tliPrGetCallMismatch_c(String am, int ts, String src, int line, TriComponentId c,
+      TriPortId at, TriSignatureId signature,
+      TciParameterList tciPars, TciValueTemplate parsTmpl, TciValueDifferenceList diffs,
+      TriComponentId from, TciNonValueTemplate fromTmpl);
+  public void tliPrGetCall_m(String am, int ts, String src, int line, TriComponentId c,
+      TriPortId at, TriSignatureId signature,
+      TciParameterList tciPars, TciValueTemplate parsTmpl,
+      Value addrValue, TciValueTemplate addressTmpl);
+  public void tliPrGetCall_c(String am, int ts, String src, int line, TriComponentId c,
+      TriPortId at, TriSignatureId signature,
+      TciParameterList tciPars, TciValueTemplate parsTmpl,
+      TriComponentId from, TciNonValueTemplate fromTmpl);
+  public void tliPrReply_m(String am, int ts, String src, int line, TriComponentId c,
+      TriPortId at, TriPortId to, TriSignatureId signature, TciParameterList tciPars,
+      Value replValue, Value addrValue,
+      TciStatus encoderFailure, TriParameterList triPars,
+      TriParameter repl, TriAddress address, TriStatus transmissionFailure);
+  public void tliPrReply_m_BC(String am, int ts, String src, int line, TriComponentId c,
+      TriPortId at, TriPortId to, TriSignatureId signature, TciParameterList tciPars,
+      Value replValue, TciStatus encoderFailure,
+      TriParameterList triPars, TriParameter repl, TriStatus transmissionFailure);
+  public void tliPrReply_m_MC(String am, int ts, String src, int line, TriComponentId c,
+      TriPortId at, TriPortId to, TriSignatureId signature, TciParameterList tciPars,
+      Value replValue, TciValueList addrValues,
+      TciStatus encoderFailure, TriParameterList triPars,
+      TriParameter repl, TriAddressList addresses, TriStatus transmissionFailure);
+  public void tliPrReply_c(String am, int ts, String src, int line, TriComponentId c,
+      TriPortId at, TriPortId to, TriSignatureId signature,
+      TciParameterList tciPars, Value replValue,
+      TriStatus transmissionFailure);
+  public void tliPrReply_c_BC(String am, int ts, String src, int line, TriComponentId c,
+      TriPortId at, TriPortIdList to, TriSignatureId signature, TciParameterList tciPars,
+      Value replValue, TriStatus transmissionFailure);
+  public void tliPrReply_c_MC(String am, int ts, String src, int line, TriComponentId c,
+      TriPortId at, TriPortIdList to, TriSignatureId signature, TciParameterList tciPars,
+      Value replValue, TriStatus transmissionFailure);
+  public void tliPrGetReplyDetected_m(String am, int ts, String src, int line, TriComponentId c,
+      TriPortId at, TriPortId from, TriSignatureId signature, TriParameterList triPars,
+      TriParameter repl, TriAddress address);
+  public void tliPrGetReplyDetected_c(String am, int ts, String src, int line, TriComponentId c,
+      TriPortId at, TriPortId from, TriSignatureId signature, TciParameterList tciPars,
+      Value replValue);
+  public void tliPrGetReplyMismatch_m(String am, int ts, String src, int line, TriComponentId c,
+      TriPortId at, TriSignatureId signature,
+      TciParameterList tciPars, TciValueTemplate parsTmpl,
+      Value replValue, TciValueTemplate replyTmpl, TciValueDifferenceList diffs,
+      Value addrValue, TciValueTemplate addressTmpl);
+  public void tliPrGetReplyMismatch_c(String am, int ts, String src, int line, TriComponentId c,
+      TriPortId at, TriSignatureId signature,
+      TciParameterList tciPars, TciValueTemplate parsTmpl,
+      Value replValue, TciValueTemplate replyTmpl, TciValueDifferenceList diffs,
+      TriComponentId from, TciNonValueTemplate fromTmpl);
+  public void tliPrGetReply_m(String am, int ts, String src, int line, TriComponentId c,
+      TriPortId at, TriSignatureId signature,
+      TciParameterList tciPars, TciValueTemplate parsTmpl,
+      Value replValue, TciValueTemplate replyTmpl,
+      Value addrValue, TciValueTemplate addressTmpl);
+  public void tliPrGetReply_c(String am, int ts, String src, int line, TriComponentId c,
+      TriPortId at, TriSignatureId signature,
+      TciParameterList tciPars, TciValueTemplate parsTmpl,
+      Value replValue, TciValueTemplate replyTmpl,
+      TriComponentId from, TciNonValueTemplate fromTmpl);
+  public void tliPrRaise_m(String am, int ts, String src, int line, TriComponentId c,
+      TriPortId at, TriPortId to,
+      TriSignatureId signature, TciParameterList tciPars, Value excValue,
+      Value addrValue, TciStatus encoderFailure, TriException exc,
+      TriAddress address, TriStatus transmissionFailure);
+  public void tliPrRaise_m_BC(String am, int ts, String src, int line, TriComponentId c,
+      TriPortId at, TriPortId to,
+      TriSignatureId signature, TciParameterList tciPars, Value excValue,
+      TciStatus encoderFailure, TriException exc, TriStatus transmissionFailure) ;
+  public void tliPrRaise_m_MC(String am, int ts, String src, int line, TriComponentId c,
+      TriPortId at, TriPortId to,
+      TriSignatureId signature, TciParameterList tciPars, Value excValue,
+      TciValueList addrValues, TciStatus encoderFailure, TriException exc,
+      TriAddressList addresses, TriStatus transmissionFailure);
+  public void tliPrRaise_c(String am, int ts, String src, int line, TriComponentId c,
+      TriPortId at, TriPortId to, TriSignatureId signature,
+      TciParameterList tciPars, Value excValue, TriStatus transmissionFailure);
+  public void tliPrRaise_c_BC(String am, int ts, String src, int line, TriComponentId c,
+      TriPortId at, TriPortIdList to, TriSignatureId signature, TciParameterList tciPars,
+      Value excValue, TriStatus transmissionFailure);
+  public void tliPrRaise_c_MC(String am, int ts, String src, int line, TriComponentId c,
+      TriPortId at, TriPortIdList to, TriSignatureId signature, TciParameterList tciPars,
+      Value excValue, TriStatus transmissionFailure);
+  public void tliPrCatchDetected_m(String am, int ts, String src, int line, TriComponentId c,
+      TriPortId at, TriPortId from, TriSignatureId signature,
+      TriException exc, TriAddress address);
+  public void tliPrCatchDetected_c(String am, int ts, String src, int line, TriComponentId c,
+      TriPortId at, TriPortId from, TriSignatureId signature,
+      Value excValue);
+  public void tliPrCatchMismatch_m(String am, int ts, String src, int line, TriComponentId c,
+      TriPortId at, TriSignatureId signature,
+      Value excValue, TciValueTemplate excTmpl, TciValueDifferenceList diffs,
+      Value addrValue, TciValueTemplate addressTmpl);
+  public void tliPrCatchMismatch_c(String am, int ts, String src, int line, TriComponentId c,
+      TriPortId at, TriSignatureId signature,
+      Value excValue, TciValueTemplate excTmpl, TciValueDifferenceList diffs,
+      TriComponentId from, TciNonValueTemplate fromTmpl);
+  public void tliPrCatch_m(String am, int ts, String src, int line, TriComponentId c,
+      TriPortId at, TriSignatureId signature,
+      Value excValue, TciValueTemplate excTmpl,
+      Value addrValue, TciValueTemplate addressTmpl);
+  public void tliPrCatch_c(String am, int ts, String src, int line, TriComponentId c,
+      TriPortId at, TriSignatureId signature,
+      Value excValue, TciValueTemplate excTmpl,
+      TriComponentId from, TciNonValueTemplate fromTmpl);
+  public void tliPrCatchTimeoutDetected(String am, int ts, String src, int line, TriComponentId c,
+      TriPortId at, TriSignatureId signature);
+  public void tliPrCatchTimeout(String am, int ts, String src, int line, TriComponentId c,
+      TriPortId at, TriSignatureId signature);
+  public void tliCCreate(String am, int ts, String src, int line, TriComponentId c,
+      TriComponentId comp, String name, Boolean alive);
+  public void tliCStart(String am, int ts, String src, int line, TriComponentId c,
+      TriComponentId comp, TciBehaviourId name, TciParameterList tciPars);
+  public void tliCRunning(String am, int ts, String src, int line, TriComponentId c,
+      TriComponentId comp, ComponentStatus status);
+  public void tliCAlive(String am, int ts, String src, int line, TriComponentId c,
+      TriComponentId comp, ComponentStatus status);
+  public void tliCStop(String am, int ts, String src, int line, TriComponentId c,
+      TriComponentId comp);
+  public void tliCKill(String am, int ts, String src, int line, TriComponentId c,
+      TriComponentId comp);
+  public void tliCDoneMismatch(String am, int ts, String src, int line, TriComponentId c,
+      TriComponentId comp, TciNonValueTemplate compTmpl);
+  public void tliCDone(String am, int ts, String src, int line, TriComponentId c,
+      TciNonValueTemplate compTmpl);
+  public void tliCKilledMismatch(String am, int ts, String src, int line, TriComponentId c,
+      TriComponentId comp, TciNonValueTemplate compTmpl);
+  public void tliCKilled(String am, int ts, String src, int line, TriComponentId c,
+      TciNonValueTemplate compTmpl);
+  public void tliCTerminated(String am, int ts, String src, int line, TriComponentId c,
+      VerdictValue verdict);
+  public void tliPConnect(String am, int ts, String src, int line, TriComponentId c,
+      TriPortId port1, TriPortId port2);
+  public void tliPDisconnect(String am, int ts, String src, int line, TriComponentId c,
+      TriPortId port1, TriPortId port2);
+  public void tliPMap(String am, int ts, String src, int line, TriComponentId c,
+      TriPortId port1, TriPortId port2);
+  public void tliPUnmap(String am, int ts, String src, int line, TriComponentId c,
+      TriPortId port1, TriPortId port2);
+  public void tliPClear(String am, int ts, String src, int line, TriComponentId c,
+      TriPortId port);
+  public void tliPStart(String am, int ts, String src, int line, TriComponentId c,
+      TriPortId port);
+  public void tliPStop(String am, int ts, String src, int line, TriComponentId c,
+      TriPortId port);
+  public void tliPHalt(String am, int ts, String src, int line, TriComponentId c,
+      TriPortId port);
+  public void tliEncode(String am, int ts, String src, int line, TriComponentId c,
+      Value val, TciStatus encoderFailure, TriMessage msg, String codec);
+  public void tliDecode(String am, int ts, String src, int line, TriComponentId c,
+      TriMessage msg, TciStatus decoderFailure, Value val, String codec);
+  public void tliTTimeoutDetected(String am, int ts, String src, int line, TriComponentId c,
+      TriTimerId timer);
+  public void tliTTimeoutMismatch(String am, int ts, String src, int line, TriComponentId c,
+      TriTimerId timer, TciNonValueTemplate timerTmpl);
+  public void tliTTimeout(String am, int ts, String src, int line, TriComponentId c,
+      TriTimerId timer, TciNonValueTemplate timerTmpl);
+  public void tliTStart(String am, int ts, String src, int line, TriComponentId c,
+      TriTimerId timer, TriTimerDuration dur);
+  public void tliTStop(String am, int ts, String src, int line, TriComponentId c,
+      TriTimerId timer, TriTimerDuration dur);
+  public void tliTRead(String am, int ts, String src, int line, TriComponentId c,
+      TriTimerId timer, TriTimerDuration elapsed);
+  public void tliTRunning(String am, int ts, String src, int line, TriComponentId c,
+      TriTimerId timer, TimerStatus status);
+  public void tliSEnter(String am, int ts, String src, int line, TriComponentId c,
+      QualifiedName name, TciParameterList tciPars, String kind);
+  public void tliSLeave(String am, int ts, String src, int line, TriComponentId c,
+      QualifiedName name, TciParameterList tciPars, Value returnValue, String kind);
+  public void tliVar(String am, int ts, String src, int line, TriComponentId c,
+      QualifiedName name, Value varValue);
+  public void tliModulePar(String am, int ts, String src, int line, TriComponentId c,
+      QualifiedName name, Value parValue);
+  public void tliGetVerdict(String am, int ts, String src, int line, TriComponentId c,
+      VerdictValue verdict);
+  public void tliSetVerdict(String am, int ts, String src, int line, TriComponentId c,
+      VerdictValue verdict, String reason);
+  public void tliLog(String am, int ts, String src, int line, TriComponentId c,
+      String log);
+  public void tliAEnter(String am, int ts, String src, int line, TriComponentId c);
+  public void tliALeave(String am, int ts, String src, int line, TriComponentId c);
+  public void tliADefaults(String am, int ts, String src, int line, TriComponentId c);
+  public void tliAActivate(String am, int ts, String src, int line, TriComponentId c,
+      QualifiedName name, TciParameterList tciPars, Value ref);
+  public void tliADeactivate(String am, int ts, String src, int line, TriComponentId c,
+      Value ref);
+  public void tliANomatch(String am, int ts, String src, int line, TriComponentId c);
+  public void tliARepeat(String am, int ts, String src, int line, TriComponentId c);
+  public void tliAWait(String am, int ts, String src, int line, TriComponentId c);
+  public void tliAction(String am, int ts, String src, int line, TriComponentId c, String action);
+  public void tliMatch(String am, int ts, String src, int line, TriComponentId c, Value expr,
+      TciValueTemplate tmpl);
+  public void tliMatchMismatch(String am, int ts, String src, int line, TriComponentId c,
+      Value expr, TciValueTemplate tmpl, TciValueDifferenceList diffs);
+  public void tliInfo (String am, int ts, String src, int line, TriComponentId c,
+      int level, String info);
+}
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
27-04-2011 12:37tepelmannNew Issue
27-04-2011 12:37tepelmannClause Reference(s) => 8.5.4.1
27-04-2011 12:37tepelmannSource (company - Author) => tepelmann
28-04-2011 14:39tepelmannNote Added: 0009996
24-05-2011 12:28Gyorgy RethyAssigned To => Ina Schieferdecker
24-05-2011 12:28Gyorgy RethyPrioritynormal => low
24-05-2011 12:28Gyorgy RethyStatusnew => assigned
24-05-2011 12:28Gyorgy RethyTarget Version => Edition 4.4.1
24-05-2011 19:05Gyorgy RethyTarget VersionEdition 4.4.1 => Edition 4.3.2 (interim)
25-05-2011 15:23Ina SchieferdeckerNote Added: 0010056
25-05-2011 15:23Ina SchieferdeckerStatusassigned => resolved
25-05-2011 15:23Ina SchieferdeckerResolutionopen => fixed
27-09-2011 14:09Gyorgy RethyStatusresolved => feedback
27-09-2011 14:09Gyorgy RethyResolutionfixed => reopened
27-09-2011 14:09Gyorgy RethyNote Added: 0010249
27-09-2011 14:10Gyorgy RethyStatusfeedback => resolved
27-09-2011 14:10Gyorgy RethyResolutionreopened => fixed
27-09-2011 14:10Gyorgy RethyTarget VersionEdition 4.3.2 (interim) => Edition 4.4.1
30-09-2011 16:40Ina SchieferdeckerNote Added: 0010319
30-09-2011 16:42Ina SchieferdeckerStatusresolved => closed
30-09-2011 16:42Ina SchieferdeckerFixed in Version => Edition 4.4.1
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0009996) +
+ tepelmann    +
+ 28-04-2011 14:39    +
+ 		+ + + + +
+ One additional correction is needed for the mapping of TBoolean:
+For tliCCreate the type for alive should be 'boolean' instead of 'Boolean' - see chapter "8.3.1 Basic type mapping".
+
+
+
+ + + + + + + + + + +
+ (0010056) +
+ Ina Schieferdecker    +
+ 25-05-2011 15:23    +
+ 		+ + + + +
+ Agreed as proposed.
+
+
+
+ + + + + + + + + + +
+ (0010249) +
+ Gyorgy Rethy    +
+ 27-09-2011 14:09    +
+ 		+ + + + +
+ Changing target version to 4.4.1
+
+
+
+ + + + + + + + + + +
+ (0010319) +
+ Ina Schieferdecker    +
+ 30-09-2011 16:40    +
+ 		+ + + + +
+ as proposed except that tliPrGetReplyDetected_c uses tciPars not triPars
+
+ + diff --git a/docs/mantis/CR5881.md b/docs/mantis/CR5881.md new file mode 100644 index 0000000000000000000000000000000000000000..f05097bf311fc74cc9a0f6f704b858cf697ca15e --- /dev/null +++ b/docs/mantis/CR5881.md @@ -0,0 +1,182 @@ + + + + + + + + + + + + + 0005881: Problematic sentence in section 7.1.4 - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005881Part 09: Using XML with TTCN-3Technicalpublic28-04-2011 13:0013-07-2011 14:21
ReporterJacob Wieland - Spirent 
Assigned ToJacob Wieland - Spirent 
PriorityhighSeveritymajorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Clause Reference(s)XSD Language Mapping, section 7.1.4
For STF discussion
Source (company - Author)Testing Technologies - Jacob Wieland
Summary0005881: Problematic sentence in section 7.1.4
DescriptionThe following sentence is problematic:
+"
+The initial name of the field shall
+be postfixed with "_list", the encoding instruction "untagged" shall be attached to the outer record of and, finally, if
+no "untagged" encoding instruction is attached to the inner TTCN-3 type being iterated, a "name as ’<initial name>’"
+encoding instruction shall be attached to the inner type, where <initial name> is the name resulted from applying
+clause 5.2.2 to the name of the XSD component being translated.
+"
+
+When encoding, the name-tag should, in our opinion, be the name as defined in the schema (i.e. BEFORE and not AFTER applying clause 5.2.2. to the name).
+
+However, the _list suffix should, of course, be added to the name AFTER applying clause 5.2.2.
+
+This, though, causes names that clash with TTCN-3 reserved words (keywords and predefined functions) to end up with a double __, i.e. display__list. Maybe, a special rule should be introduced here that trailing '_' should be stripped before adding the _list suffix.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR5881_resolution_v1.doc (109,568) 25-05-2011 16:43
http://oldforge.etsi.org/mantis/file_download.php?file_id=2491&type=bug
Issue History
Date ModifiedUsernameFieldChange
28-04-2011 13:00Jacob Wieland - SpirentNew Issue
28-04-2011 13:00Jacob Wieland - SpirentClause Reference(s) => XSD Language Mapping, section 7.1.4
28-04-2011 13:00Jacob Wieland - SpirentSource (company - Author) => Testing Technologies - Jacob Wieland
24-05-2011 12:26Gyorgy RethyNote Added: 0010009
24-05-2011 12:26Gyorgy RethyStatusnew => assigned
24-05-2011 12:26Gyorgy RethyAssigned To => Gyorgy Rethy
24-05-2011 12:27Gyorgy RethyNote Edited: 0010009
24-05-2011 19:05Gyorgy RethyTarget Version => Edition 4.3.2 (interim)
24-05-2011 19:14Gyorgy RethyPrioritynormal => high
25-05-2011 16:43Gyorgy RethyFile Added: CR5881_resolution_v1.doc
25-05-2011 16:44Gyorgy RethyNote Added: 0010065
25-05-2011 16:44Gyorgy RethyNote Edited: 0010065
25-05-2011 16:44Gyorgy RethyAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
25-05-2011 16:55Jacob Wieland - SpirentNote Added: 0010068
25-05-2011 16:57Jacob Wieland - SpirentStatusassigned => resolved
25-05-2011 16:57Jacob Wieland - SpirentResolutionopen => fixed
13-07-2011 14:21Gyorgy RethyStatusresolved => closed
13-07-2011 14:21Gyorgy RethyNote Added: 0010214
13-07-2011 14:21Gyorgy RethyFixed in Version => Edition 4.3.2 (interim)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010009) +
+ Gyorgy Rethy    +
+ 24-05-2011 12:26    +
(edited on: 24-05-2011 12:27)
+ 		+ + + + +
+ Comment is correct, but cl.5.2.2 shall be applied after adding the _list postfix to the name of the TTCN-3 field. Add an example to the standard and correct text.
+
+
+
+
+
+ + + + + + + + + + +
+ (0010065) +
+ Gyorgy Rethy    +
+ 25-05-2011 16:44    +
+ 		+ + + + +
+ See proposed solution in CR5881_resolution_v1.doc. Jacob, pls. review.
+
+
+
+
+
+ + + + + + + + + + +
+ (0010068) +
+ Jacob Wieland - Spirent    +
+ 25-05-2011 16:55    +
+ 		+ + + + +
+ It's OK.
+
+
+
+ + + + + + + + + + +
+ (0010214) +
+ Gyorgy Rethy    +
+ 13-07-2011 14:21    +
+ 		+ + + + +
+ Added to master copy
+
+ + diff --git a/docs/mantis/CR5882.md b/docs/mantis/CR5882.md new file mode 100644 index 0000000000000000000000000000000000000000..77edd52fbe3c925a55e6903465361ea22b65ad14 --- /dev/null +++ b/docs/mantis/CR5882.md @@ -0,0 +1,107 @@ + + + + + + + + + + + + + 0005882: Missing TTCN-3 comment symbols in examples - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 10: TTCN-3 documentation tags
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005882Part 10: TTCN-3 documentation tagsEditorialpublic02-05-2011 09:0815-12-2011 16:11
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PriorityhighSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.4.1 (published 2012-04)Fixed in Versionv4.4.1 (published 2012-04) 
Source (company - Author)  L.M.Ericcson
Summary0005882: Missing TTCN-3 comment symbols in examples
DescriptionIn $5.1 the examples correctly should be:
+EXAMPLE 1:
+        /** text for documentation
+            using block comment */
+
+EXAMPLE 2:
+        //* text for documentation
+        //* using line comments
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
02-05-2011 09:08Gyorgy RethyNew Issue
02-05-2011 09:08Gyorgy RethySource (company - Author) => L.M.Ericcson
24-05-2011 12:19Gyorgy RethyStatusnew => assigned
24-05-2011 12:19Gyorgy RethyAssigned To => Gyorgy Rethy
24-05-2011 12:20Gyorgy RethyNote Added: 0010008
24-05-2011 12:21Gyorgy RethyNote Edited: 0010008
24-05-2011 19:04Gyorgy RethyTarget Version => Edition 4.3.2 (interim)
24-05-2011 19:14Gyorgy RethyPrioritynormal => high
25-05-2011 16:49Gyorgy RethyNote Edited: 0010008
25-05-2011 16:50Gyorgy RethyStatusassigned => resolved
25-05-2011 16:50Gyorgy RethyResolutionopen => fixed
27-09-2011 14:08Gyorgy RethyStatusresolved => feedback
27-09-2011 14:08Gyorgy RethyResolutionfixed => reopened
27-09-2011 14:08Gyorgy RethyNote Added: 0010248
27-09-2011 14:09Gyorgy RethyStatusfeedback => resolved
27-09-2011 14:09Gyorgy RethyResolutionreopened => fixed
27-09-2011 14:09Gyorgy RethyTarget VersionEdition 4.3.2 (interim) => Edition 4.4.1
15-12-2011 16:11Gyorgy RethyStatusresolved => closed
15-12-2011 16:11Gyorgy RethyFixed in Version => Edition 4.4.1
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010008) +
+ Gyorgy Rethy    +
+ 24-05-2011 12:20    +
(edited on: 25-05-2011 16:49)
+ 		+ + + + +
+ Correct the examples. Include the text in the example into a pair of <>-s. To be implemented on the published version of v4.3.1.
+
+
+
+
+
+ + + + + + + + + + +
+ (0010248) +
+ Gyorgy Rethy    +
+ 27-09-2011 14:08    +
+ 		+ + + + +
+ Changing target version to 4.4.1
+
+ + diff --git a/docs/mantis/CR5883.md b/docs/mantis/CR5883.md new file mode 100644 index 0000000000000000000000000000000000000000..cd4693f3acd176f1a03bf3e6de92b7e78b6ae057 --- /dev/null +++ b/docs/mantis/CR5883.md @@ -0,0 +1,205 @@ + + + + + + + + + + + + + 0005883: Example is inconsistent for choice-groups. - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005883Part 09: Using XML with TTCN-3Technicalpublic05-05-2011 13:1313-07-2011 16:38
ReporterJacob Wieland - Spirent 
Assigned ToGyorgy Rethy 
PriorityhighSeveritymajorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Clause Reference(s)XSD Language Mapping, section 7.9
For STF discussion
Source (company - Author)Testing Technologies - Jacob Wieland
Summary0005883: Example is inconsistent for choice-groups.
DescriptionIn section 7.9. the example for the choice group is inconsistent with the sentence
+
+"They shall be mapped the same way as complexTypes with one difference: the "untagged" encoding instruction shall be
+attached to the generated TTCN-3 component, corresponding to the group element (but, of course, will always represent
+a subset of complex types, as only the above compositors are allowed as child and can never have attributes)."
+
+To be consistent, the example would have to look like this:
+
+type record ShipOrBill {
+  union {
+    XSD.String shipTo,
+    XSD.String billTo
+  } choice
+}
+with {
+  variant "untagged"
+}
+
+However, this should be changed to the by far more understandable and usable:
+
+type union ShipOrBill {
+  XSD.String shipTo,
+  XSD.String billTo
+}
+with {
+  variant "untagged"
+}
+
+This would be consistent with the normal XSD semantics where a referenced group signifies the same as if the child of that group were inlined at the point of reference. Since normally, a choice element is mapped to a union type, this should also be done for choice-groups.
+
+Also, since groups can not introduce attributes, it is not necessary to have an additional record layer for choice-groups (as in the complexType case).
+
+Therefore, we propose to change the above sentence to the following:
+
+"They shall be mapped to TTCN-3 type definitions the same way as their child components would be mapped inside a complexType definition with one difference: the "untagged" encoding instruction shall be
+attached to the generated TTCN-3 component, corresponding to the group element."
+
+This will only affect the mapping of choice-groups. The mapping of sequence and all groups will stay the same.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR5883_resolution_v1.doc (75,776) 26-05-2011 17:43
http://oldforge.etsi.org/mantis/file_download.php?file_id=2514&type=bug
doc CR5883_resolution_v2.doc (28,672) 27-05-2011 12:31
http://oldforge.etsi.org/mantis/file_download.php?file_id=2518&type=bug
Issue History
Date ModifiedUsernameFieldChange
05-05-2011 13:13Jacob Wieland - SpirentNew Issue
05-05-2011 13:13Jacob Wieland - SpirentClause Reference(s) => XSD Language Mapping, section 7.9
05-05-2011 13:13Jacob Wieland - SpirentSource (company - Author) => Testing Technologies - Jacob Wieland
24-05-2011 12:18Gyorgy RethyNote Added: 0010007
24-05-2011 12:18Gyorgy RethyStatusnew => assigned
24-05-2011 12:18Gyorgy RethyAssigned To => Gyorgy Rethy
24-05-2011 19:03Gyorgy RethyTarget Version => Edition 4.3.2 (interim)
25-05-2011 17:05Gyorgy RethyNote Edited: 0010007
26-05-2011 17:43Gyorgy RethyFile Added: CR5883_resolution_v1.doc
26-05-2011 17:47Gyorgy RethyNote Added: 0010093
26-05-2011 17:47Gyorgy RethyAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
27-05-2011 12:31Jacob Wieland - SpirentFile Added: CR5883_resolution_v2.doc
27-05-2011 12:31Jacob Wieland - SpirentNote Added: 0010099
27-05-2011 12:32Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
27-05-2011 13:39Gyorgy RethyStatusassigned => resolved
27-05-2011 13:39Gyorgy RethyResolutionopen => fixed
13-07-2011 16:38Gyorgy RethyStatusresolved => closed
13-07-2011 16:38Gyorgy RethyNote Added: 0010220
13-07-2011 16:38Gyorgy RethyFixed in Version => Edition 4.3.2 (interim)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010007) +
+ Gyorgy Rethy    +
+ 24-05-2011 12:18    +
(edited on: 25-05-2011 17:05)
+ 		+ + + + +
+ 3GPP related CR.
+Proposal is OK, example in the newest version is in line with the proposal. The text shall be corrected, proposed text is OK.
+
+
+
+
+
+ + + + + + + + + + +
+ (0010093) +
+ Gyorgy Rethy    +
+ 26-05-2011 17:47    +
+ 		+ + + + +
+ Resolved as proposed by the CR. See complete resolution text in file CR5883_resolution_v1.doc. Jacob pls. review.
+
+
+
+ + + + + + + + + + +
+ (0010099) +
+ Jacob Wieland - Spirent    +
+ 27-05-2011 12:31    +
+ 		+ + + + +
+ Just deleted a wrong s (at the end of complexTypes). Otherwise ok.
+
+
+
+ + + + + + + + + + +
+ (0010220) +
+ Gyorgy Rethy    +
+ 13-07-2011 16:38    +
+ 		+ + + + +
+ Added to master copy.
+
+ + diff --git a/docs/mantis/CR5884.md b/docs/mantis/CR5884.md new file mode 100644 index 0000000000000000000000000000000000000000..e0181563865ba73a0626eee5d045a8060a7de931 --- /dev/null +++ b/docs/mantis/CR5884.md @@ -0,0 +1,217 @@ + + + + + + + + + + + + + 0005884: Relational operators and inlined values [Part 1: Clause 7.1.3] - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005884Part 01: TTCN-3 Core LanguageClarificationpublic08-05-2011 18:3601-07-2011 14:46
ReporterPhilip Makedonski 
Assigned ToIna Schieferdecker 
PriorityhighSeveritytextReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.3.2 (interim 2011)Fixed in Versionv4.3.2 (interim 2011) 
Clause Reference(s)7.1.3
Source (company - Author)University of Göttingen - Philip Makedonski
Summary0005884: Relational operators and inlined values [Part 1: Clause 7.1.3]
DescriptionThere has been some discussion regarding the possibility of using inlined value definitions with relational operators. Take for example:
+
+    type record R
+    {
+        integer a,
+        integer b
+    }
+
+    function f(){
+        var R vl_rec1 := {1,2}
+        var R vl_rec2 := {1,2}
+        if (vl_rec1 == vl_rec2) {} //(1)
+        if (vl_rec2 == {1,2}) {} //(2)
+    }
+
+As of now, the BNF permits (1) but not (2).
+
+Clause 7.1.3 states that:
+"Two record values, set values, record of values or set of values are equal if and only if their effective value structures are compatible (see clause 6.3) and the actual values of all corresponding fields are equal. record values may also be compared to record of values and set values to set of values. In these cases the same rule applies as for comparing two record or set values."
+
+This seems to imply that (2) above (and possibly similar cases) should be accepted as well, although there doesn't seem to be any further evidence pointing to this.
+
+Some clarity on this would be highly appreciated:
+- Is it intentional that (2) is not supported? (I can see various reasons for this, an official statement would be helpful, however)
+
+The list operator (Clause 7.1.2) causes some confusion in a similar manner.
+ 
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc es_20187301v040205m_CR5884.doc (99,840) 26-05-2011 15:24
http://oldforge.etsi.org/mantis/file_download.php?file_id=2507&type=bug
? core.bnf (57,277) 30-06-2011 17:51
http://oldforge.etsi.org/mantis/file_download.php?file_id=2542&type=bug
Issue History
Date ModifiedUsernameFieldChange
08-05-2011 18:36Philip MakedonskiNew Issue
08-05-2011 18:36Philip MakedonskiClause Reference(s) => 7.1.3
08-05-2011 18:36Philip MakedonskiSource (company - Author) => University of Göttingen - Philip Makedonski
24-05-2011 10:40Jacob Wieland - SpirentNote Added: 0010004
24-05-2011 12:02Gyorgy RethyStatusnew => assigned
24-05-2011 12:02Gyorgy RethyAssigned To => Jacob Wieland - Spirent
24-05-2011 18:08Gyorgy RethyTarget Version => Edition 4.3.2 (interim)
24-05-2011 19:13Gyorgy RethyPrioritynormal => high
25-05-2011 10:29Jacob Wieland - SpirentNote Edited: 0010004
25-05-2011 10:31Jacob Wieland - SpirentNote Edited: 0010004
25-05-2011 10:32Jacob Wieland - SpirentNote Edited: 0010004
26-05-2011 13:05Jacob Wieland - SpirentFile Added: core.bnf
26-05-2011 13:06Jacob Wieland - SpirentFile Deleted: core.bnf
26-05-2011 13:06Jacob Wieland - SpirentFile Added: core.bnf
26-05-2011 13:07Jacob Wieland - SpirentNote Added: 0010086
26-05-2011 13:11Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Ina Schieferdecker
26-05-2011 15:24Jacob Wieland - SpirentFile Added: es_20187301v040205m_CR5884.doc
26-05-2011 15:24Jacob Wieland - SpirentNote Added: 0010090
30-06-2011 17:50Ina SchieferdeckerFile Deleted: core.bnf
30-06-2011 17:51Ina SchieferdeckerFile Added: core.bnf
30-06-2011 17:51Ina SchieferdeckerNote Added: 0010168
30-06-2011 17:52Ina SchieferdeckerStatusassigned => resolved
30-06-2011 17:52Ina SchieferdeckerFixed in Version => Edition 4.3.2 (interim)
30-06-2011 17:52Ina SchieferdeckerResolutionopen => fixed
01-07-2011 14:46Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010004) +
+ Jacob Wieland - Spirent    +
+ 24-05-2011 10:40    +
(edited on: 25-05-2011 10:32)
+ 		+ + + + +
+ I wholeheartedly agree.
+
+To be minimally invasive (because the whole Single/Compound expression stuff is defined differently for values and templates), I propose the following changes to allow this:
+
+507. EqualExpression ::= RelExpression {EqualOp RelExpression}
+/* STATIC SEMANTICS - If more than one RelExpression exists, then the RelExpressions shall evaluate to specific values of compatible types.
+If only one RelExpression exists, it shall not derive a CompoundExpression */
+
+508. RelExpression ::= ShiftExpression [RelOp ShiftExpression] |
+                       CompoundExpression
+/* STATIC SEMANTICS - If both ShiftExpressions exist, then each ShiftExpression shall evaluate to a specific integer, Enumerated or float Value or derivatives of these types */
+
+514. AddExpression ::= MulExpression {AddOp MulExpression}
+/* STATIC SEMANTICS - Each MulExpression shall resolve to a specific Value. If more than one MulExpression exists and the AddOp resolves to StringOp then the MulExpressions shall be valid operands for StringOp. If more than one MulExpression exists and the AddOp does not resolve to StringOp then the MulExpression shall both resolve to type integer or float or derivatives of these types. If only one MulExpression exists, it shall not derive a CompoundExpression. */
+
+515. MulExpression ::= UnaryExpression {MultiplyOp UnaryExpression} |
+                       CompoundExpression
+
+Only MulExpression and RelExpression can be CompoundExpressions because only equality and concatenation are defined on structured values.
+The additional STATIC SEMANTIC restrictions are necesssary to avoid ambiguity between SingleExpression and CompoundExpression, i.e. the derivation SingleExpression =>* CompoundExpression must be forbidden so that rule
+
+Expression ::= SingleExpression | CompoundExpression
+
+remains unambiguous.
+
+
+
+
+
+ + + + + + + + + + +
+ (0010086) +
+ Jacob Wieland - Spirent    +
+ 26-05-2011 13:07    +
+ 		+ + + + +
+ added changed bnf
+
+
+
+ + + + + + + + + + +
+ (0010090) +
+ Jacob Wieland - Spirent    +
+ 26-05-2011 15:24    +
+ 		+ + + + +
+ added proposal in text-form, added notes/examples for concatenation/comparison operators
+
+
+
+ + + + + + + + + + +
+ (0010168) +
+ Ina Schieferdecker    +
+ 30-06-2011 17:51    +
+ 		+ + + + +
+ Implemented as proposed with small editorial changes
+
+ + diff --git a/docs/mantis/CR5885.md b/docs/mantis/CR5885.md new file mode 100644 index 0000000000000000000000000000000000000000..4679ce7365419e31e1425c49db7854398be97ff0 --- /dev/null +++ b/docs/mantis/CR5885.md @@ -0,0 +1,460 @@ + + + + + + + + + + + + + 0005885: Inconsistency in mapping UniversalCharstringValue (implies platform dependency) - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005885Part 06: TTCN-3 Control InterfaceClarificationpublic11-05-2011 10:3616-12-2011 06:06
Reportertepelmann 
Assigned ToIna Schieferdecker 
PriorityhighSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.4.1 (published 2012-04)Fixed in Versionv4.4.1 (published 2012-04) 
Clause Reference(s)9.2, 9.6, 10.5.3.7
Source (company - Author)Testing Technologies IST GmbH - tepelmann
Summary0005885: Inconsistency in mapping UniversalCharstringValue (implies platform dependency)
DescriptionI noticed a change in the ANSI C mapping of the UniversalCharstringValue from version 4.1.1 to 4.2.1.
+In 4.1.1 the type TciUCValue was used for all relevant operations, where in 4.2.1 wchar_t is used.
+To remind what was TciUCValue - an array of 4 bytes:
+  typedef unsigned char TciUCValue[4];
+
+I'm wondering if the replacement with wchar_t was correct or not. The reason is that wchar_t has a different size on different platforms, on Unix system mostly 4 bytes, on Windows system 2 bytes.
+I'm not sure if this could cause any inconsistency when interworking between two different systems. As this could cause different encoding and decoding in the case the communication is taking place between to different platforms.
+
+Please clarify this.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0005489closed Ina Schieferdecker TCI C++ mapping fixes 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
11-05-2011 10:36tepelmannNew Issue
11-05-2011 10:36tepelmannClause Reference(s) => 9.2, 9.6, 10.5.3.7
11-05-2011 10:36tepelmannSource (company - Author) => Testing Technologies IST GmbH - tepelmann
24-05-2011 12:12Gyorgy RethyNote Added: 0010006
24-05-2011 12:13Gyorgy RethyStatusnew => assigned
24-05-2011 12:13Gyorgy RethyAssigned To => Ina Schieferdecker
24-05-2011 18:07Gyorgy RethyTarget Version => Edition 4.3.2 (interim)
24-05-2011 19:13Gyorgy RethyPrioritynormal => high
24-05-2011 19:26Gyorgy RethyTarget VersionEdition 4.3.2 (interim) => Edition 4.4.1
24-05-2011 19:26Gyorgy RethyTarget VersionEdition 4.4.1 => Edition 4.3.2 (interim)
25-05-2011 18:04Ina SchieferdeckerRelationship addedrelated to 0005489
25-05-2011 18:35Ina SchieferdeckerNote Added: 0010074
27-09-2011 13:58Gyorgy RethyTarget VersionEdition 4.3.2 (interim) => Edition 4.4.1
30-11-2011 11:07Ina SchieferdeckerNote Added: 0010432
30-11-2011 11:07Ina SchieferdeckerNote Added: 0010433
30-11-2011 11:08Ina SchieferdeckerNote Added: 0010434
30-11-2011 11:09Ina SchieferdeckerNote Added: 0010435
02-12-2011 13:51Ina SchieferdeckerNote Added: 0010522
02-12-2011 13:56Ina SchieferdeckerNote Added: 0010523
02-12-2011 13:57Ina SchieferdeckerNote Added: 0010524
02-12-2011 13:57Ina SchieferdeckerAssigned ToIna Schieferdecker => Jacob Wieland - Spirent
02-12-2011 15:35Jacob Wieland - SpirentNote Added: 0010529
03-12-2011 05:49Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Ina Schieferdecker
16-12-2011 06:05Ina SchieferdeckerNote Added: 0010542
16-12-2011 06:05Ina SchieferdeckerStatusassigned => resolved
16-12-2011 06:05Ina SchieferdeckerResolutionopen => fixed
16-12-2011 06:05Ina SchieferdeckerFixed in Version => Edition 4.4.1
16-12-2011 06:06Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010006) +
+ Gyorgy Rethy    +
+ 24-05-2011 12:12    +
+ 		+ + + + +
+ It has been defined as wchar_t based on CR5489 in discussion with vendors. Proposal is to leave xchar_t but tool implementations shall take care of using a 4 octet representation. This proposal shall be agreed with tool vendors.
+
+
+
+ + + + + + + + + + +
+ (0010074) +
+ Ina Schieferdecker    +
+ 25-05-2011 18:35    +
+ 		+ + + + +
+ This subject indeed requires some more thoughts ... according to my reads the native support for 4 byte universal characters is open in quite some programming languages/operating systems/compilers.
+
+As there is a need for a correct solution and, if possible, one that is comparable to the different language mappings, what about getting indeed back to the 4 byte array of character?
+
+
+
+ + + + + + + + + + +
+ (0010432) +
+ Ina Schieferdecker    +
+ 30-11-2011 11:07    +
+ 		+ + + + +
+ Dear all
+    
+Please also have a look at http://t-ort.etsi.org/view.php?id=5885 [^] which is about the representation of universal characters in the language mappings.
+    
+Either, we leave it as is and require the implementations to have a wchar_t setting that is capable of representing universal characters.
+    
+Or, we return to the original solution with a 4 byte array of character.
+    
+Best regards
+Ina
+
+
+
+ + + + + + + + + + +
+ (0010433) +
+ Ina Schieferdecker    +
+ 30-11-2011 11:07    +
+ 		+ + + + +
+ Hi,
+
+
+
+Both solutions are Ok for Elvior but wchar_t is better because functions exist for that. Of course there exists systems where wchar_t is only 16 bits and there is the risk of losing data. Maybe the better solution would be if TRI will include 2 type functions - for wchar_t and for old structure. In that way one can choose the function he/she likes.
+
+Best Regards,
+
+
+Andres Kull | Founder & Chief Research Officer |Elvior
+
+
+
+ + + + + + + + + + +
+ (0010434) +
+ Ina Schieferdecker    +
+ 30-11-2011 11:08    +
+ 		+ + + + +
+ Dear Ina,
+
+we would prefer a clean, easy to implement but platform independent solution here.
+
+With best regards,
+
+Thilo Lauer, Devoteam
+
+
+
+ + + + + + + + + + +
+ (0010435) +
+ Ina Schieferdecker    +
+ 30-11-2011 11:09    +
+ 		+ + + + +
+ Dear all,
+
+OpenTTCN thinks that having 4 byte / 32 bit representation is more
+accurate for representing characters of universal charstring type. Using
+data type of less than 32 bits would require to have error handling
+defined in the standard if trying to access data that cannot be
+represented using <32 bits.
+
+Kind regards,
+Vesa-Matti
+
+
+
+ + + + + + + + + + +
+ (0010522) +
+ Ina Schieferdecker    +
+ 02-12-2011 13:51    +
+ 		+ + + + +
+ STF decided to get back to the C original presentation of universal char as 4 byte array.
+
+
+
+ + + + + + + + + + +
+ (0010523) +
+ Ina Schieferdecker    +
+ 02-12-2011 13:56    +
+ 		+ + + + +
+ void tciGetUCStringCharValue
+ (Value inst, unsigned long int position,
+  TciUCValue result)
+
+void tciSetUCStringCharValue
+ (Value inst, unsigned long int position,
+  TciUCValue value)
+
+typedef unsigned char TciUCValue[4]
+
+typedef struct TciUCStringValue
+{
+  unsigned long int length;
+  TciUCValue *string;
+} TciUCStringValue;
+
+
+
+ + + + + + + + + + +
+ (0010524) +
+ Ina Schieferdecker    +
+ 02-12-2011 13:57    +
+ 		+ + + + +
+ Please check
+
+
+
+ + + + + + + + + + +
+ (0010529) +
+ Jacob Wieland - Spirent    +
+ 02-12-2011 15:35    +
+ 		+ + + + +
+ seems ok
+
+
+
+ + + + + + + + + + +
+ (0010542) +
+ Ina Schieferdecker    +
+ 16-12-2011 06:05    +
+ 		+ + + + +
+ As proposed.
+
+ + diff --git a/docs/mantis/CR5886.md b/docs/mantis/CR5886.md new file mode 100644 index 0000000000000000000000000000000000000000..73dd226387bbbdcf1b6f0012df11737ad3a34870 --- /dev/null +++ b/docs/mantis/CR5886.md @@ -0,0 +1,107 @@ + + + + + + + + + + + + + 0005886: C++ mapping of TciTestComponentKindType differs from JAVA, ANSI C and C .NET mapping - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005886Part 06: TTCN-3 Control InterfaceClarificationpublic18-05-2011 16:0230-09-2011 14:18
Reportertepelmann 
Assigned ToIna Schieferdecker 
PriorityhighSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.4.1 (published 2012-04)Fixed in Versionv4.4.1 (published 2012-04) 
Clause Reference(s)10.5.2.13
Source (company - Author)Testing Technologies IST GmbH - tepelmann
Summary0005886: C++ mapping of TciTestComponentKindType differs from JAVA, ANSI C and C .NET mapping
DescriptionIn the current definition the C++ mapping looks like this:
+typedef enum
+{
+  SYSTEM_COMP = 0,
+  PTC_COMP = 1,
+  PTC_ALIVE_COMP = 2,
+  MTC_COMP = 3,
+  CTRL_COMP = 4
+} TciTestComponentKind;
+
+In all other language mappings system has the value 3, PTC the value 2, PTC ALIVE 4, MTC 1 and CTRL 0.
Steps To Reproduce
Additional InformationFor the ANSI C mapping we propose also to bind the enum constants to the specific values instead of having it undefined.
TagsNo tags attached.
Relationships
Attached Filesdocx CR5886.docx (16,284) 25-05-2011 17:13
http://oldforge.etsi.org/mantis/file_download.php?file_id=2493&type=bug
Issue History
Date ModifiedUsernameFieldChange
18-05-2011 16:02tepelmannNew Issue
18-05-2011 16:02tepelmannClause Reference(s) => 10.5.2.13
18-05-2011 16:02tepelmannSource (company - Author) => Testing Technologies IST GmbH - tepelmann
24-05-2011 11:49Gyorgy RethyNote Added: 0010005
24-05-2011 11:49Gyorgy RethyStatusnew => assigned
24-05-2011 11:49Gyorgy RethyAssigned To => Ina Schieferdecker
24-05-2011 17:56Gyorgy RethyTarget Version => Edition 4.3.2 (interim)
24-05-2011 19:12Gyorgy RethyPrioritynormal => high
24-05-2011 19:26Gyorgy RethyTarget VersionEdition 4.3.2 (interim) => Edition 4.4.1
24-05-2011 19:27Gyorgy RethyTarget VersionEdition 4.4.1 => Edition 4.3.2 (interim)
25-05-2011 17:13Ina SchieferdeckerFile Added: CR5886.docx
27-09-2011 13:57Gyorgy RethyTarget VersionEdition 4.3.2 (interim) => Edition 4.4.1
30-09-2011 14:16Ina SchieferdeckerNote Added: 0010314
30-09-2011 14:17Ina SchieferdeckerStatusassigned => closed
30-09-2011 14:18Ina SchieferdeckerResolutionopen => fixed
30-09-2011 14:18Ina SchieferdeckerFixed in Version => Edition 4.4.1
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010005) +
+ Gyorgy Rethy    +
+ 24-05-2011 11:49    +
+ 		+ + + + +
+ Ina to check, inform MTP about the change.
+
+
+
+ + + + + + + + + + +
+ (0010314) +
+ Ina Schieferdecker    +
+ 30-09-2011 14:16    +
+ 		+ + + + +
+ No (negative) response received from MTP or IBM, implemented as proposed.
+
+ + diff --git a/docs/mantis/CR5888.md b/docs/mantis/CR5888.md new file mode 100644 index 0000000000000000000000000000000000000000..ef9e9cc535efb12ab2f7212dd48a1a83d508ceff --- /dev/null +++ b/docs/mantis/CR5888.md @@ -0,0 +1,846 @@ + + + + + + + + + + + + + 0005888: An alternative TRI to handle messages and objects directly - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Extended TRI (ES 202 789)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005888Ext Pack: Extended TRI (ES 202 789)New Featurepublic25-05-2011 10:0415-12-2011 13:53
ReporterIna Schieferdecker 
Assigned ToIna Schieferdecker 
PrioritynormalSeveritymajorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv1.1.1 (published 2012-04)Fixed in Versionv1.1.1 (published 2012-04) 
Clause Reference(s)Part 5
Source (company - Author)Ina Schieferdecker, FOKUS
Summary0005888: An alternative TRI to handle messages and objects directly
DescriptionHistorically, TTCN has been used to test communication protocols which typically use encoded messages.
+
+This has been reflected in the TRI SA and TCI CD design of TTCN-3 by encoding and decoding mesages to/from bitstrings.
+
+However, TTCN-3 also supports signature-based communication for which the transformation of objects into bitstrings and vice versa is cumbersome.
+
+Furthermore, some protocols use also structured messages for which the bitstring encoding is not helpful.
+
+Therefore, an alternative API is being proposed along which TTCN-3 values can be directly passed to/from the SUT.
+
+Further details are given in the attached ppt.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0004275closed Ina Schieferdecker Part 01: TTCN-3 Core Language New Concepts to be defined via Packages 
Attached Filespptx An alternative TTCN-3 TRI API to address software.pptx (62,413) 25-05-2011 14:17
http://oldforge.etsi.org/mantis/file_download.php?file_id=2482&type=bug
pptx An alternative TTCN-3 TRI API to address software_v2.pptx (65,825) 26-05-2011 16:58
http://oldforge.etsi.org/mantis/file_download.php?file_id=2511&type=bug
pdf Tutorial_T3UC_2011_new_architecture_concrete_layer_v4.pdf (1,050,415) 13-06-2011 19:50
http://oldforge.etsi.org/mantis/file_download.php?file_id=2522&type=bug
doc es_TTCN3Package_XTRI_v003.doc (323,584) 30-06-2011 10:45
http://oldforge.etsi.org/mantis/file_download.php?file_id=2531&type=bug
docx es_TTCN3Package_XTRI_v004.docx (190,653) 30-09-2011 11:37
http://oldforge.etsi.org/mantis/file_download.php?file_id=2580&type=bug
docx es_TTCN3Package_XTRI_v005.docx (189,400) 01-12-2011 13:54
http://oldforge.etsi.org/mantis/file_download.php?file_id=2643&type=bug
zip es_TTCN3Package_XTRI_v006.zip (184,783) 01-12-2011 14:27
http://oldforge.etsi.org/mantis/file_download.php?file_id=2644&type=bug
docx es_TTCN3Package_XTRI_v007.docx (195,093) 02-12-2011 12:41
http://oldforge.etsi.org/mantis/file_download.php?file_id=2656&type=bug
Issue History
Date ModifiedUsernameFieldChange
25-05-2011 10:04Ina SchieferdeckerNew Issue
25-05-2011 10:04Ina SchieferdeckerFile Added: An alternative TTCN-3 TRI API to address software.pptx
25-05-2011 10:04Ina SchieferdeckerClause Reference(s) => Part 5
25-05-2011 10:04Ina SchieferdeckerSource (company - Author) => Ina Schieferdecker, FOKUS
25-05-2011 11:54Ina SchieferdeckerFile Deleted: An alternative TTCN-3 TRI API to address software.pptx
25-05-2011 11:54Ina SchieferdeckerFile Added: An alternative TTCN-3 TRI API to address software.pptx
25-05-2011 14:16Ina SchieferdeckerFile Deleted: An alternative TTCN-3 TRI API to address software.pptx
25-05-2011 14:17Ina SchieferdeckerFile Added: An alternative TTCN-3 TRI API to address software.pptx
25-05-2011 14:17Ina SchieferdeckerProjectTTCN-3 Change Requests => Ext Pack: Extended TRI (ES 202 789)
25-05-2011 14:17Ina SchieferdeckerStatusnew => assigned
25-05-2011 14:17Ina SchieferdeckerAssigned To => Ina Schieferdecker
25-05-2011 14:30Jacob Wieland - SpirentNote Added: 0010053
26-05-2011 12:35Ina SchieferdeckerFile Added: An alternative TTCN-3 TRI API to address software_v2.pptx
26-05-2011 12:36Ina SchieferdeckerNote Added: 0010083
26-05-2011 15:48Ina SchieferdeckerRelationship addedrelated to 0004275
26-05-2011 16:57Ina SchieferdeckerFile Deleted: An alternative TTCN-3 TRI API to address software_v2.pptx
26-05-2011 16:58Ina SchieferdeckerFile Added: An alternative TTCN-3 TRI API to address software_v2.pptx
27-05-2011 12:36Jacob Wieland - SpirentNote Added: 0010100
13-06-2011 19:50Bernard StepienFile Added: Tutorial_T3UC_2011_new_architecture_concrete_layer_v4.pdf
13-06-2011 19:53Bernard StepienNote Added: 0010115
13-06-2011 19:54Bernard StepienNote Edited: 0010115
15-06-2011 17:38Ming ShangNote Added: 0010116
30-06-2011 10:45Ina SchieferdeckerFile Added: es_TTCN3Package_XTRI_v003.doc
30-06-2011 14:46Ina SchieferdeckerNote Added: 0010159
30-06-2011 14:54Ina SchieferdeckerResolutionopen => fixed
30-06-2011 14:54Ina SchieferdeckerTarget Version => v1.1.1
30-09-2011 11:37Ina SchieferdeckerFile Added: es_TTCN3Package_XTRI_v004.docx
30-11-2011 09:33Jacob Wieland - SpirentNote Added: 0010416
30-11-2011 09:55Jacob Wieland - SpirentNote Added: 0010422
01-12-2011 12:30Ina SchieferdeckerNote Added: 0010471
01-12-2011 12:30Ina SchieferdeckerNote Added: 0010472
01-12-2011 12:31Ina SchieferdeckerNote Added: 0010473
01-12-2011 12:31Ina SchieferdeckerNote Added: 0010474
01-12-2011 12:33Ina SchieferdeckerNote Added: 0010475
01-12-2011 13:54Ina SchieferdeckerFile Added: es_TTCN3Package_XTRI_v005.docx
01-12-2011 13:56Ina SchieferdeckerNote Added: 0010481
01-12-2011 13:56Ina SchieferdeckerAssigned ToIna Schieferdecker => Jacob Wieland - Spirent
01-12-2011 14:04Ming ShangNote Added: 0010482
01-12-2011 14:27Jacob Wieland - SpirentFile Added: es_TTCN3Package_XTRI_v006.zip
01-12-2011 14:30Jacob Wieland - SpirentNote Added: 0010485
01-12-2011 14:31Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Ina Schieferdecker
02-12-2011 12:41Ina SchieferdeckerNote Added: 0010514
02-12-2011 12:41Ina SchieferdeckerFile Added: es_TTCN3Package_XTRI_v007.docx
02-12-2011 12:42Ina SchieferdeckerNote Added: 0010515
15-12-2011 13:52Ina SchieferdeckerStatusassigned => resolved
15-12-2011 13:52Ina SchieferdeckerFixed in Version => v1.1.1
15-12-2011 13:53Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010053) +
+ Jacob Wieland - Spirent    +
+ 25-05-2011 14:30    +
+ 		+ + + + +
+ I think this is a well-rounded concept. One question that remains is how to change the names of the interfaces/functions so they don't clash with the existing names in TRI so that they can exist side-by-side.
+
+I would propose to change the TRI/tri consistently to something else:
+- ETRI (Extended TRI)
+- VTRI (Value-Based TRI)
+- TVRI (TTCN-3 Value-based Runtime Interface)
+- STRI (Software-TRI)
+- ... ?
+
+
+
+ + + + + + + + + + +
+ (0010083) +
+ Ina Schieferdecker    +
+ 26-05-2011 12:36    +
+ 		+ + + + +
+ Agreed on a name for the new interface: XTRI.
+
+Agreed to add a decode function for those cases where the type is not known by the adaptor.
+
+Next is to develop the draft extension package as outlined.
+
+
+
+ + + + + + + + + + +
+ (0010100) +
+ Jacob Wieland - Spirent    +
+ 27-05-2011 12:36    +
+ 		+ + + + +
+ Maybe we should rename the decode method to 'cast' (and the decodingHypothesis parameter simply to type) - because that is in essence, what it does.
+
+Value cast(Value value, Type type)
+
+
+
+ + + + + + + + + + +
+ (0010115) +
+ Bernard Stepien    +
+ 13-06-2011 19:53    +
(edited on: 13-06-2011 19:54)
+ 		+ + + + +
+ We (University of Ottawa and Research and Motion ltd) have implemented this concept in January 2010 and also convinced one of the tool vendors to include it in their current release. Thus, we have 18 months of successful usage of this concept and can happilly agree that this concept is very useful. See our T3UC 2011 tutorial at http://www.site.uottawa.ca/~bernard/Tutorial_T3UC_2011_new_architecture_concrete_layer_v4.pdf [^]
+
+
+
+
+
+ + + + + + + + + + +
+ (0010116) +
+ Ming Shang    +
+ 15-06-2011 17:38    +
+ 		+ + + + +
+ This is Ming Shang from Research In Motion (RIM), Bernard Stepien and I took another approach to solve this problem. Instead of changing the interface specification, we recommended that the TriMessage interface be extended to contain extra information at the runtime. The extended methods for TriMessage look like:
+ void setAttachement(Object attachement),
+ Object getAttachment()
+
+Advantages:
+No fundamental changes required for the TRI
+
+Disadvantages:
+Applied only to the single-rooted inheritance language like Java, under which Object object can represent anything. May not work in the C/C++ domain.
+
+Prerequisite for the Java implementation Runtime (if Java domain):
+Classloader(s) for codec and TestAdapter plugins have to be consistent to avoid java.lang.ClassCastException
+
+
+
+ + + + + + + + + + +
+ (0010159) +
+ Ina Schieferdecker    +
+ 30-06-2011 14:46    +
+ 		+ + + + +
+ We have discussed the proposal by RIM and came to the conclusion that the seperation between tri and xtri is the cleaner method to enable direct access to objects via the SA. Old and new TRI could be used in combination - depending on which TSI interfaces should be adapted how. We continue with xtri as proposed.
+
+
+
+ + + + + + + + + + +
+ (0010416) +
+ Jacob Wieland - Spirent    +
+ 30-11-2011 09:33    +
+ 		+ + + + +
+ For using arbitrary objects in the C-world, I propose to use a type construct like this:
+
+typedef enumerated {
+  e_int,
+  e_long,
+  ...
+  e_ptr
+} type_kind;
+
+typedef void *value;
+
+typedef struct {
+  type_kind tag,
+  value val
+} Object;
+
+The value-pointer shall always be a pointer to the type corresponding to the the tag, so it can then be cast (and dereferenced if it is a base type).
+
+Alternatively, value could be defined as a union over all C primitive types and pointer.
+
+typedef union {
+  int v_int,
+  long v_long,
+  ...
+  void *v_ptr
+} value;
+
+In this case, instead of casting, the proper union-variant must be used depending on the tag. Again, consistency between tag and value must be assumed.
+
+With these definitions, in the C mapping whenever a C-value needs to be passed into the TTCN-3 world without the target type being known (i.e. for receive and catch), you would use this kind of Object type.
+
+The convert function to be implemented by the test adapter (and to be used both by the Test Adapter and the TE) would then become like this:
+
+TciValue convert(Object value, TciType type)
+
+I don't think that we should use Object for passing DOWN to the adapter as then it would fall to the TE to decide how to map Value to Object where it knows nothing about the target to be adapted. (Is the function parameter a long or an int?). Only the adapter layer can know this and has already a clean way via the TCI value interface of accessing the values to be mapped.
+
+For procedure based communication, we should still use some TciParameterList which encapsulates a list of TciParameters (i.e. tuple of name, mode, Value). Then, for out or inout parameters, the convert function would need to be called by the testadapter layer with the value obtained from the target world and the type of the parameter obtainable from the parameter-Value object.
+
+So, to summarize:
+
+- xtriSend, xtriRaise should use TciValue
+- xtriCall, xtriReply, xtriEnqueueReply, xtriEnqueueCall should use TciParameterList (and TciValue for reply result)
+- triEnqueueMsg, triEnqueueException should use Object
+
+
+
+ + + + + + + + + + +
+ (0010422) +
+ Jacob Wieland - Spirent    +
+ 30-11-2011 09:55    +
+ 		+ + + + +
+ To be more precise, we would need the following enum:
+
+typedef enumerated {
+  e_int, // signed int
+  e_short, // signed short int
+  e_long, // signed long int
+  e_char, // char
+  e_uint, // unsigned int
+  e_ushort, // unsigned short int
+  e_ulong, // unsigned long int
+  e_uchar, // unsigned char
+  e_schar, // signed char
+  e_float, // float
+  e_double, // double
+  e_long_double, // long double
+  e_ptr // void *
+} type_kind;
+
+and the following union (if the union variant is used:
+
+typedef union {
+  signed int v_int,
+  signed short int v_short,
+  signed long int v_long,
+  char v_char,
+  unsigned int v_uint,
+  unsigned short int v_ushort,
+  unsigned long int v_ulong,
+  unsigned char v_uchar,
+  signed char v_schar,
+  float v_float,
+  double v_double,
+  long double v_long_double,
+  void *v_ptr //
+} type_kind;
+
+
+
+ + + + + + + + + + +
+ (0010471) +
+ Ina Schieferdecker    +
+ 01-12-2011 12:30    +
+ 		+ + + + +
+ Am 30.09.2011 um 09:47 schrieb Schieferdecker, Ina:
+
+
+    Dear all
+     
+    We have developed the extended TRI (XTRI) package, which defines a more efficient handling of software values. It does not use binary encoded messages for the communication with the SUT, but uses the values as they are; meaning e.g. that software objects or serialized data can be passed directly between the SUT and the TE. The current proposal is available at http://t-ort.etsi.org/view.php?id=5888 [^]
+     
+    This week we have been pointed to the possibility to base the extended TRI operations on Objects instead of Values in order to handle a more general case where any object could be treated by extended TRI that way. There are pros and cons and finally we decided to ask you in order to go for the solution that is considered the best for extended TRI.
+     
+    Hence, please be so kind to respond by end of next week:
+     
+    Should the extended TRI handle TCI Values or generic Objects?
+     
+    Thank you in advance
+    
+    Ina
+
+
+
+ + + + + + + + + + +
+ (0010472) +
+ Ina Schieferdecker    +
+ 01-12-2011 12:30    +
+ 		+ + + + +
+ Hi Ina,
+
+we would prefer generic objects for the extended TRI.
+
+Best regards,
+Stephan
+
+
+
+ + + + + + + + + + +
+ (0010473) +
+ Ina Schieferdecker    +
+ 01-12-2011 12:31    +
+ 		+ + + + +
+ Hello Ina,
+
+    Looks like I started a discussion... My mention of the idea of
+passing generic Objects from the TA to the TE via the xenqueue() method was
+not from me but from a Java intensive collegue at RIM. I think, what most of
+the people do not understand is that with the new extension, the codec no
+longer needs to reside in the TE or better is invoked by the TE but instead
+is residing in the TA or more precisely is invoked by the TA. This is what I
+extensively presented in my tutorial at T3UC'11. In my special case, web
+testing using frameworks, this is essential.
+
+Hope this helps
+Bernard Stepien
+
+
+
+ + + + + + + + + + +
+ (0010474) +
+ Ina Schieferdecker    +
+ 01-12-2011 12:31    +
+ 		+ + + + +
+ Elvior prefers generic objects.
+
+Best Regards,
+
+
+Andres Kull
+
+
+
+ + + + + + + + + + +
+ (0010475) +
+ Ina Schieferdecker    +
+ 01-12-2011 12:33    +
+ 		+ + + + +
+ Dear Ina,
+
+Thank you for your kind answer during your holiday.
+
+In the light of this new information I think you are more prepared to
+select the correct API by yourself based on the feedback you have received
+already.
+
+Kind regards,
+Vesa-Matti
+
+> Dear Vesa-Matti
+>
+> Sorry for answering only now - the difference would be basically that the
+> operations defined by extended TRI would work on generic objects instead
+> of values and that the conversion would allow to transform objects into
+> specific values and vice versa. It would give even more flexibility than
+> working on Values.
+>
+> Best regards
+>
+> Ina
+>
+> Subject: Re: RfC: Extended TRI for software testing based on Value or on
+> Object ?!
+>
+>
+> Dear Ina,
+>
+>>> Should the extended TRI handle TCI Values or generic Objects?
+>
+> I wonder if I have missed something last week but I have not yet received
+> reply to my question about what was the difference between the two
+> proposals given earlier.
+>
+> What would be the technical difference between "TCI Values" and "generic
+> Objects" proposals?
+>
+> Kind regards,
+> Vesa-Matti
+
+
+
+ + + + + + + + + + +
+ (0010481) +
+ Ina Schieferdecker    +
+ 01-12-2011 13:56    +
+ 		+ + + + +
+ generic objects represented as IDL any.
+
+representations for any defined in C, C++ (struct with type tag), C# and Java (Object)
+
+main principle: TE works with Value, SA works with Value/TciParameter when type is clear, otherwise with any
+
+Please review.
+
+
+
+ + + + + + + + + + +
+ (0010482) +
+ Ming Shang    +
+ 01-12-2011 14:04    +
+ 		+ + + + +
+ From RIM perspective, generic object is strongly perferred.
+
+
+
+ + + + + + + + + + +
+ (0010485) +
+ Jacob Wieland - Spirent    +
+ 01-12-2011 14:30    +
+ 		+ + + + +
+ mostly editorial changes, for xtriEnqueueExc Value was replaced by any/Object (resp. mapping) as TTCN-3 type is not known by TA.
+
+Value/ValueList parameter names replaced by SUTaddress/SUTaddresses according to header.
+
+Deleted sentence about ValueList being used as parameter list.
+
+renamed decodingHypothesis to typeHypothesis
+
+
+
+ + + + + + + + + + +
+ (0010514) +
+ Ina Schieferdecker    +
+ 02-12-2011 12:41    +
+ 		+ + + + +
+ made ValueList TciValueList - no need to define an extra type
+
+renamed decodingHypothesis consistently into typeHypothesis
+
+some final editing
+
+
+
+ + + + + + + + + + +
+ (0010515) +
+ Ina Schieferdecker    +
+ 02-12-2011 12:42    +
+ 		+ + + + +
+ Ready for final review - please check
+
+ + diff --git a/docs/mantis/CR5889.md b/docs/mantis/CR5889.md new file mode 100644 index 0000000000000000000000000000000000000000..fedfa73a0c577bebdb1115d24b129b2237ace194 --- /dev/null +++ b/docs/mantis/CR5889.md @@ -0,0 +1,433 @@ + + + + + + + + + + + + + 0005889: Usage as lvalue of fields of types which have subtype constraint which constrains the field should be forbidden - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005889Part 01: TTCN-3 Core LanguageTechnicalpublic25-05-2011 15:2829-11-2013 12:35
ReporterJacob Wieland - Spirent 
Assigned ToIna Schieferdecker 
PrioritylowSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.6.1 (published 2014-06)Fixed in Versionv4.6.1 (published 2014-06) 
Clause Reference(s)6.2
Source (company - Author)Jacob Wieland - Testing Technologies
Summary0005889: Usage as lvalue of fields of types which have subtype constraint which constrains the field should be forbidden
DescriptionIf you have a situation like this:
+
+type record Pair { integer i, integer j }
+type Pair AllowedPair ({1, 2}, {2, 3})
+
+function f() {
+  var AllowedPair x := {1, 2}
+  inc(x.i); // this should be an error
+}
+
+function inc(inout integer p) {
+  p := p + 1;
+}
+
+Then at runtime, this would lead to an invalid variable assignment to variable x which is probably not checked at runtime (because implementing this in general would mean that for every assignment all the subtype constraints of all the containing variables need to be checked) and thus can lead to problems.
+
+Therefore, I propose to disallow any use as lvalues of field references constrained by a subtyping constraint of one of their ancestors, i.e. as the target variable in an assignment or as an inout or out parameter.
+
+That means that such constrained records always have to be assigned in-bulk (by using structured value notations), at least for all the fields that are constrained by the subtyping constraints of their ancestors.
+If a field is not constrained by an ancestor's subtyping constraint, it can still be normally used as lvalue.
+
+Example:
+
+type record R { integer k, integer i, integer j }
+type R R2 ({ k:= 1, i := 2}, { k:= 2, i := 3})
+
+function g() {
+  var R2 x := { 1, 2 }
+  x.k := 2; // error
+  inc(x.i); // error
+  inc(x.j); // allowed
+  x.j := 5; // allowed
+}
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc es_20187301v040205m_CR5889.doc (14,848) 26-05-2011 16:22
http://oldforge.etsi.org/mantis/file_download.php?file_id=2510&type=bug
doc CR5889_resolution_v1.doc (76,800) 14-10-2013 11:55
http://oldforge.etsi.org/mantis/file_download.php?file_id=2934&type=bug
Issue History
Date ModifiedUsernameFieldChange
25-05-2011 15:28Jacob Wieland - SpirentNew Issue
25-05-2011 15:28Jacob Wieland - SpirentClause Reference(s) => 6.2
25-05-2011 15:28Jacob Wieland - SpirentSource (company - Author) => Jacob Wieland - Testing Technologies
26-05-2011 16:04Jacob Wieland - SpirentFile Added: es_20187301v040205m_CR5889.doc
26-05-2011 16:04Jacob Wieland - SpirentNote Added: 0010091
26-05-2011 16:21Jacob Wieland - SpirentFile Deleted: es_20187301v040205m_CR5889.doc
26-05-2011 16:22Jacob Wieland - SpirentFile Added: es_20187301v040205m_CR5889.doc
26-05-2011 16:22Jacob Wieland - SpirentStatusnew => assigned
26-05-2011 16:22Jacob Wieland - SpirentAssigned To => Gyorgy Rethy
26-05-2011 16:23Jacob Wieland - SpirentNote Edited: 0010091
27-05-2011 15:21Gyorgy RethyNote Added: 0010105
27-05-2011 15:33Gyorgy RethyNote Edited: 0010105
28-06-2011 16:38Gyorgy RethyProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
30-06-2011 09:30Gyorgy RethyNote Edited: 0010105
27-09-2011 13:57Gyorgy RethyTarget Version => Edition 4.4.1
30-11-2011 10:32Gyorgy RethyPrioritynormal => low
30-11-2011 10:37Gyorgy RethyNote Added: 0010426
30-11-2011 10:37Gyorgy RethyTarget VersionEdition 4.4.1 => v4.7.1 (published 2015-06)
13-07-2012 15:47Gyorgy RethyNote Added: 0010935
16-07-2012 10:40Jacob Wieland - SpirentNote Added: 0010937
08-07-2013 18:20Gyorgy RethyTarget Versionv4.5.1 (published 2013-04) => v4.6.1 (published 2014-06)
11-10-2013 15:22Gyorgy RethyNote Added: 0011786
11-10-2013 15:23Gyorgy RethyNote Edited: 0011786
11-10-2013 15:23Gyorgy RethyAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
11-10-2013 16:13Jacob Wieland - SpirentNote Added: 0011789
11-10-2013 16:19Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
11-10-2013 16:19Jacob Wieland - SpirentStatusassigned => confirmed
14-10-2013 10:59Gyorgy RethyNote Added: 0011800
14-10-2013 11:55Gyorgy RethyFile Added: CR5889_resolution_v1.doc
14-10-2013 11:55Gyorgy RethyNote Edited: 0011800
14-10-2013 11:55Gyorgy RethyStatusconfirmed => assigned
14-10-2013 11:55Gyorgy RethyAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
14-10-2013 12:36Gyorgy RethyStatusassigned => confirmed
14-10-2013 13:12Jacob Wieland - SpirentStatusconfirmed => assigned
14-10-2013 13:12Jacob Wieland - SpirentNote Added: 0011802
14-10-2013 13:12Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Ina Schieferdecker
14-10-2013 13:12Jacob Wieland - SpirentStatusassigned => confirmed
29-11-2013 12:31Ina SchieferdeckerNote Added: 0011866
29-11-2013 12:31Ina SchieferdeckerStatusconfirmed => resolved
29-11-2013 12:31Ina SchieferdeckerResolutionopen => fixed
29-11-2013 12:35Ina SchieferdeckerStatusresolved => closed
29-11-2013 12:35Ina SchieferdeckerFixed in Version => v4.6.1 (published 2014-06)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010091) +
+ Jacob Wieland - Spirent    +
+ 26-05-2011 16:04    +
(edited on: 26-05-2011 16:23)
+ 		+ + + + +
+ Added concrete proposal. Please review.
+
+
+
+
+
+ + + + + + + + + + +
+ (0010105) +
+ Gyorgy Rethy    +
+ 27-05-2011 15:21    +
(edited on: 30-06-2011 09:30)
+ 		+ + + + +
+ I know that we talked about this, but... when considering the issue, this would mean that constrained structured types can be used to define constants and templates only...; I would say it is quite rare that the user assignes values for the complete structured variable only but never to its fields...; quite the opposite, structured variables are commonly used to construct the value at runtime step-by-step. So, the user will not be able to define parameterized templates for the type, dynamic construction of values/templates would be impossible, what about in parameters (disallowing inout and out only would - again - create a very specific exception in the language) and last but not least would also limit valid uses, when the value assigned to a field is in line with the constraint of the type.
+This needs further consideration in the STF.
+
+
+
+
+
+ + + + + + + + + + +
+ (0010426) +
+ Gyorgy Rethy    +
+ 30-11-2011 10:37    +
+ 		+ + + + +
+ CR is not reporting a problem or unsupported use case, due to the limited time remaining in 2011 it shall be shifetd to 2012.
+
+
+
+ + + + + + + + + + +
+ (0010935) +
+ Gyorgy Rethy    +
+ 13-07-2012 15:47    +
+ 		+ + + + +
+ Checked the ASN.1 to TTCN-3 mapping and there are cases when ASN.1 type constraints are translated to TTCN-3 list subtyping for ASN.1 SEQUENSE and SET (TTCN-3 record and set).
+
+Introducing the change requested in this CR would make such ASN.1 definitions almost unable from TTCN-3 as well.
+
+
+
+ + + + + + + + + + +
+ (0010937) +
+ Jacob Wieland - Spirent    +
+ 16-07-2012 10:40    +
+ 		+ + + + +
+ I guess you meant "unusable".
+
+If so, could you give an example, as I cannot think of one.
+
+
+
+ + + + + + + + + + +
+ (0011786) +
+ Gyorgy Rethy    +
+ 11-10-2013 15:22    +
(edited on: 11-10-2013 15:23)
+ 		+ + + + +
+ Part-7 table 4:
+Type Single Value Contained Subtype (h)
+Sequence list list
+Set list list
+
+contained subtype is a relatively popular construct in ASN.1.
+
+Today it is possible and allowed to change just one field of a variable based on such an imported ASN.1 type. But the point is, that a limitation of this kind would be non-backward compatible.
+
+As we cannot agree on accepting the proposal, either we can agree on closing the CR with not fixed as we escalate it to MTS.
+
+
+
+
+
+ + + + + + + + + + +
+ (0011789) +
+ Jacob Wieland - Spirent    +
+ 11-10-2013 16:13    +
+ 		+ + + + +
+ Maybe we should find out if any of the existing tools are even aware of the problem and deal with it properly. I.e. it is very easy to produce values that violate the restrictions even though this can only be caught at runtime and only via quite complicated checking (which I am almost sure no tool does).
+
+Since closing the CR would leave the problem thus unresolved, I think an escalation to MTS would then be the way to go.
+
+As a compromise, we could, of course, at least (like we did for the non-determinism of initializing templates) strongly advise against such usages (as the potentially problematic places can be determined statically) so that
+
+a) people become aware of the potential problem
+b) tools have an incentive to check for those situation
+
+
+
+ + + + + + + + + + +
+ (0011800) +
+ Gyorgy Rethy    +
+ 14-10-2013 10:59    +
(edited on: 14-10-2013 11:55)
+ 		+ + + + +
+ I agree, a warning (note in the standard and even an example) would be useful. But we cannot forbid ALL usage, because it CAN also be used in a wrong way.
+
+See proposed resolution in CR5889_resolution_v1.doc.
+
+
+
+
+
+ + + + + + + + + + +
+ (0011802) +
+ Jacob Wieland - Spirent    +
+ 14-10-2013 13:12    +
+ 		+ + + + +
+ As a compromise, I guess this suffices.
+
+
+
+ + + + + + + + + + +
+ (0011866) +
+ Ina Schieferdecker    +
+ 29-11-2013 12:31    +
+ 		+ + + + +
+ as proposed in CR5889_resolution_v1.doc
+
+ + diff --git a/docs/mantis/CR5897.md b/docs/mantis/CR5897.md new file mode 100644 index 0000000000000000000000000000000000000000..1b65d220080492432478f32cd7dba2e0f7e4f5d0 --- /dev/null +++ b/docs/mantis/CR5897.md @@ -0,0 +1,498 @@ + + + + + + + + + + + + + 0005897: attr-field should be optional - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005897Part 09: Using XML with TTCN-3New Featurepublic14-06-2011 12:3701-12-2011 14:07
ReporterJacob Wieland - Spirent 
Assigned ToGyorgy Rethy 
PriorityhighSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.4.1 (published 2012-04)Fixed in Versionv4.4.1 (published 2012-04) 
Clause Reference(s)XSD Language Mapping, section 7.7
For STF discussion
Source (company - Author)Testing Technologies - Jacob Wieland
Summary0005897: attr-field should be optional
DescriptionWhen the XSD type definition contains an anyAttributes element, this at the moment is mapped to a field named 'attr' which is a record of XSD.string.
+
+For user friendliness this field should be optional as in probably 99% of the cases, the field will be the empty list and thus it is nicer to just be able to omit it.
+
+To avoid confusion between the empty list and omit, the field could get a length restriction of at least 1.
+
+The only drawback that I see is a backward compatibility issue where ?-templates used for that field would need to be changed to * to keep the same meaning.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR5897_resolution_v2.doc (97,792) 29-09-2011 14:56
http://oldforge.etsi.org/mantis/file_download.php?file_id=2576&type=bug
doc CR5897_resolution_v3.doc (99,840) 01-12-2011 08:52
http://oldforge.etsi.org/mantis/file_download.php?file_id=2630&type=bug
Issue History
Date ModifiedUsernameFieldChange
14-06-2011 12:37Jacob Wieland - SpirentNew Issue
14-06-2011 12:37Jacob Wieland - SpirentClause Reference(s) => XSD Language Mapping, section 7.7
14-06-2011 12:37Jacob Wieland - SpirentSource (company - Author) => Testing Technologies - Jacob Wieland
29-06-2011 12:59Gyorgy RethyNote Added: 0010143
29-06-2011 13:01Gyorgy RethyStatusnew => assigned
29-06-2011 13:01Gyorgy RethyAssigned To => Gyorgy Rethy
13-07-2011 17:06Gyorgy RethyTarget Version => Edition 4.4.1
28-09-2011 12:45Gyorgy RethyNote Added: 0010272
28-09-2011 12:55Gyorgy RethyFile Added: CR5897_resolution_v1.doc
28-09-2011 12:57Gyorgy RethyNote Edited: 0010272
28-09-2011 12:57Gyorgy RethyAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
28-09-2011 12:58Gyorgy RethyNote Edited: 0010272
28-09-2011 13:06Jacob Wieland - SpirentNote Added: 0010274
28-09-2011 14:00Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
28-09-2011 14:25Gyorgy RethyNote Added: 0010276
29-09-2011 09:55Gyorgy RethyNote Added: 0010290
29-09-2011 10:01Gyorgy RethyNote Edited: 0010290
29-09-2011 14:53Gyorgy RethyFile Deleted: CR5897_resolution_v1.doc
29-09-2011 14:56Gyorgy RethyFile Added: CR5897_resolution_v2.doc
29-09-2011 14:57Gyorgy RethyNote Added: 0010300
29-09-2011 14:57Gyorgy RethyAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
29-09-2011 15:39Jacob Wieland - SpirentNote Added: 0010302
29-09-2011 15:42Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
29-09-2011 16:11Gyorgy RethyNote Added: 0010304
29-09-2011 16:13Gyorgy RethyNote Edited: 0010304
29-09-2011 16:22Gyorgy RethyNote Edited: 0010304
29-09-2011 16:27Jacob Wieland - SpirentNote Added: 0010305
28-11-2011 13:24Gyorgy RethyNote Added: 0010346
01-12-2011 08:20Gyorgy RethyNote Edited: 0010346
01-12-2011 08:52Gyorgy RethyFile Added: CR5897_resolution_v3.doc
01-12-2011 08:54Gyorgy RethyNote Added: 0010454
01-12-2011 08:56Gyorgy RethyNote Edited: 0010454
01-12-2011 08:56Gyorgy RethyAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
01-12-2011 09:33Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
01-12-2011 09:33Jacob Wieland - SpirentStatusassigned => resolved
01-12-2011 09:33Jacob Wieland - SpirentResolutionopen => fixed
01-12-2011 09:33Jacob Wieland - SpirentNote Added: 0010458
01-12-2011 14:07Gyorgy RethyStatusresolved => closed
01-12-2011 14:07Gyorgy RethyNote Added: 0010483
01-12-2011 14:07Gyorgy RethyFixed in Version => Edition 4.4.1
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010143) +
+ Gyorgy Rethy    +
+ 29-06-2011 12:59    +
+ 		+ + + + +
+ Would provide a translation that can handle backward compatible XSD changes but also TTCN-3 backward compatibility of decoded TTCN-3 values shall be considered (e.g. a decoder option?)
+
+
+
+ + + + + + + + + + +
+ (0010272) +
+ Gyorgy Rethy    +
+ 28-09-2011 12:45    +
(edited on: 28-09-2011 12:58)
+ 		+ + + + +
+ Actually, may be omit would be more intiutive, but now it cannot be introduced without breaking backward compatibility. On the other hand, writing {} is not more difficult than write omit. Also, not less intuitive regarding its meaning. But currently this is not clearly specified, therefore I propose to add this case explicitly.
+
+See draft in CR5897_resolution_v1
+
+
+
+
+
+ + + + + + + + + + +
+ (0010274) +
+ Jacob Wieland - Spirent    +
+ 28-09-2011 13:06    +
+ 		+ + + + +
+ You forget all the people that use implicit omit. For them it is a BIG difference if they have to add attr := {} in every element which is declared with anyAttributes instead of writing nothing. Also, it clutters the code unnecessarily. So, I think a decoder option would still be a better solution.
+
+Basically, I think the rule should be: If you can omit it in XSD, you should be able to implicitly omit it in TTCN-3 as well.
+
+
+
+ + + + + + + + + + +
+ (0010276) +
+ Gyorgy Rethy    +
+ 28-09-2011 14:25    +
+ 		+ + + + +
+ Jacob, your notes are all correct, the only my concern is backward compatibility. As thinking further on, unfortunately decoder option is not a solution here. How the user should know what type/kind of codec will be used at execution time. The two things are de-coupled by default. And, in practice, no one can guarantee that {}-s and omits are not mixing within the same code. We have to go definitely to one (optional record length(1) of) or the other ({})direction. Let discuss this.
+
+
+
+ + + + + + + + + + +
+ (0010290) +
+ Gyorgy Rethy    +
+ 29-09-2011 09:55    +
(edited on: 29-09-2011 10:01)
+ 		+ + + + +
+ STF discussion on 2011-09-29: propose the record lenght (1..infinity) of XSD.String optional solution. Ask tool vendors and warn MTS about the change.
+
+
+
+
+
+ + + + + + + + + + +
+ (0010300) +
+ Gyorgy Rethy    +
+ 29-09-2011 14:57    +
+ 		+ + + + +
+ Draft is uploaded in CR5897_resolution_v2.doc, pls. review.
+
+
+
+ + + + + + + + + + +
+ (0010302) +
+ Jacob Wieland - Spirent    +
+ 29-09-2011 15:39    +
+ 		+ + + + +
+ It is ok, I think, but I don't know why there are so many cases listed? Isn't anyAttributes always part of a complex type definition which describes the content of an element which is always mapped to a record type?
+
+
+
+ + + + + + + + + + +
+ (0010304) +
+ Gyorgy Rethy    +
+ 29-09-2011 16:11    +
(edited on: 29-09-2011 16:22)
+ 		+ + + + +
+ Thanks. Yes, it is always mapped to a record field, the examples are not about the different mappings of the anyAttribute element, but about the mappings of the different wildcards (namespace attribute of anyAttribute).
+Mail to vendors and MTS-GEN has been sent, any further action shall be postponed till 21th November (deadline for answering the mail). In case of no objection, the CR can be put to the resolved state.
+
+
+
+
+
+ + + + + + + + + + +
+ (0010305) +
+ Jacob Wieland - Spirent    +
+ 29-09-2011 16:27    +
+ 		+ + + + +
+ I was referring to the sentence:
+
+"
+The anyAttribute element shall be translated, like other attributes, to a field of the enframing record type or field or union field (...). The type of this field shall be record length (1..infinity) of XSD.String, the name of the field shall be the result of applying clause ... "attr" and the field, when the enframing type is a record, shall be optional.
+"
+
+Since, I think the enframing type is always a record, the if-clause in this sentence is superfluous.
+
+
+
+ + + + + + + + + + +
+ (0010346) +
+ Gyorgy Rethy    +
+ 28-11-2011 13:24    +
(edited on: 01-12-2011 08:20)
+ 		+ + + + +
+ Elvior, OpenTTCN and TestingTech supports the proposed solution.
+
+
+
+
+
+ + + + + + + + + + +
+ (0010454) +
+ Gyorgy Rethy    +
+ 01-12-2011 08:54    +
(edited on: 01-12-2011 08:56)
+ 		+ + + + +
+ Jacob, you comment is correct, I have ammended the text accordingly (see CR5897_resolution_v3.doc). Pls. do a final cross-check. If OK, pls. set the CR to the resolved state and assign it to me.
+
+
+
+
+
+ + + + + + + + + + +
+ (0010458) +
+ Jacob Wieland - Spirent    +
+ 01-12-2011 09:33    +
+ 		+ + + + +
+ ok with me.
+
+
+
+ + + + + + + + + + +
+ (0010483) +
+ Gyorgy Rethy    +
+ 01-12-2011 14:07    +
+ 		+ + + + +
+ Added to master copy.
+
+ + diff --git a/docs/mantis/CR5898.md b/docs/mantis/CR5898.md new file mode 100644 index 0000000000000000000000000000000000000000..68712161d518867d80af2bb5abb5644dea687adf --- /dev/null +++ b/docs/mantis/CR5898.md @@ -0,0 +1,551 @@ + + + + + + + + + + + + + 0005898: Clarification about comparision of optional fields with values - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005898Part 01: TTCN-3 Core LanguageClarificationpublic15-06-2011 16:5001-12-2011 15:36
ReporterWolfgang Seka 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.4.1 (published 2012-04)Fixed in Versionv4.4.1 (published 2012-04) 
Clause Reference(s)201 873-1 cl. 7.1 (??); 201 873-1 cl. 15.9
Source (company - Author)stf160 - Wolfgang
Summary0005898: Clarification about comparision of optional fields with values
DescriptionIt seems at least not to be obvious in the core language what happens when an optional field of a record is omit and it is used in comparision with a value ("==");
+this causes a runtime error with at least one compiler therefore clarification is important for tool compatibility.
+Furthermore it would be quite costly to get a runtime error in this case.
Steps To Reproduce
Additional InformationExample:
+type record MyRecord_Type {
+   integer field1,
+   integer field2 optional
+};
+
+template (value) MyRecord_Type cs_MyRecord := {
+   field1 := 1,
+   field2 := omit
+};
+
+var MyRecord_Type v_MyRecord := valueof(cs_MyRecord);
+
+=>
+if (v_MyRecord.field2 == 3) { ... } /* shall be allowed i.e. the expression shall result in false and there shall be no runtime error */
+
+if (v_MyRecord.field2 == omit) { ... } /* is this allowed ?? (would be equivalent "if (not ispresent(v_MyRecord.field2)) { ... }" or "if (not isvalue(v_MyRecord.field2)) { ... }" */
+
+in principle there is the same situation with "!=" (but that can be derived from "not (... == ...)")
+
+There is a similar situation in context of the match operation
+
+if (match(v_MyRecord.field2, (2, 3))) { ... } /* I would assume that this is allowed but the standard says "The match operation allows to compare a value (specified in form of an expression) with a template" */
+
+
TagsNo tags attached.
Relationships
Attached Filesdoc CR5898_resolution_v2.doc (92,160) 30-09-2011 14:22
http://oldforge.etsi.org/mantis/file_download.php?file_id=2585&type=bug
doc CR5898-proposal_v3.doc (121,856) 01-12-2011 10:29
http://oldforge.etsi.org/mantis/file_download.php?file_id=2638&type=bug
Issue History
Date ModifiedUsernameFieldChange
15-06-2011 16:50Wolfgang SekaNew Issue
15-06-2011 16:50Wolfgang SekaClause Reference(s) => 201 873-1 cl. 7.1 (??); 201 873-1 cl. 15.9
15-06-2011 16:50Wolfgang SekaSource (company - Author) => stf160 - Wolfgang
28-06-2011 16:26Gyorgy RethyNote Added: 0010133
28-06-2011 16:31Gyorgy RethyNote Edited: 0010133
28-06-2011 16:35Gyorgy RethyNote Edited: 0010133
28-06-2011 16:36Gyorgy RethyProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
29-06-2011 12:45Gyorgy RethyNote Added: 0010142
29-06-2011 12:51Gyorgy RethyNote Edited: 0010142
30-06-2011 11:54Gyorgy RethyNote Added: 0010155
30-06-2011 14:23Gyorgy RethyStatusnew => assigned
30-06-2011 14:23Gyorgy RethyAssigned To => Gyorgy Rethy
27-09-2011 13:34Gyorgy RethyTarget Version => Edition 4.4.1
28-09-2011 16:23Gyorgy RethyNote Edited: 0010142
28-09-2011 16:25Gyorgy RethyNote Edited: 0010142
28-09-2011 16:25Gyorgy RethyNote Deleted: 0010155
30-09-2011 11:53Gyorgy RethyNote Added: 0010309
30-09-2011 11:53Gyorgy RethyFile Added: CR5898_resolution_v1.doc
30-09-2011 11:54Gyorgy RethyAssigned ToGyorgy Rethy => Jens Grabowski
30-09-2011 13:59Jens GrabowskiNote Added: 0010312
30-09-2011 14:00Jens GrabowskiNote Added: 0010313
30-09-2011 14:01Jens GrabowskiAssigned ToJens Grabowski => Gyorgy Rethy
30-09-2011 14:22Gyorgy RethyFile Added: CR5898_resolution_v2.doc
30-09-2011 15:01Gyorgy RethyNote Added: 0010316
30-09-2011 15:02Gyorgy RethyNote Edited: 0010316
30-09-2011 15:02Gyorgy RethyNote Edited: 0010316
30-09-2011 15:03Gyorgy RethyFile Deleted: CR5898_resolution_v1.doc
30-09-2011 15:03Gyorgy RethyAssigned ToGyorgy Rethy => Jens Grabowski
01-10-2011 12:11Wolfgang SekaNote Added: 0010321
30-11-2011 08:31Jacob Wieland - SpirentNote Added: 0010411
30-11-2011 08:37Jacob Wieland - SpirentNote Added: 0010412
30-11-2011 09:48Gyorgy RethyNote Added: 0010420
30-11-2011 14:27Gyorgy RethyAssigned ToJens Grabowski => Jacob Wieland - Spirent
01-12-2011 10:16Jacob Wieland - SpirentFile Added: CR5898-proposal_v3.doc
01-12-2011 10:20Jacob Wieland - SpirentNote Added: 0010461
01-12-2011 10:22Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
01-12-2011 10:23Jacob Wieland - SpirentAssigned ToGyorgy Rethy => Ina Schieferdecker
01-12-2011 10:29Jacob Wieland - SpirentFile Deleted: CR5898-proposal_v3.doc
01-12-2011 10:29Jacob Wieland - SpirentFile Added: CR5898-proposal_v3.doc
01-12-2011 15:35Ina SchieferdeckerNote Added: 0010488
01-12-2011 15:35Ina SchieferdeckerStatusassigned => resolved
01-12-2011 15:35Ina SchieferdeckerResolutionopen => fixed
01-12-2011 15:35Ina SchieferdeckerFixed in Version => Edition 4.4.1
01-12-2011 15:36Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010133) +
+ Gyorgy Rethy    +
+ 28-06-2011 16:26    +
(edited on: 28-06-2011 16:35)
+ 		+ + + + +
+ The question is not strictly related to the equality operator itself. For consistency reasons, the two examples below shall behave the same way:
+1) direct use
+if (v_MyRecord.field2 == 3)...
+
+2) use via parameterization
+function f(in integer pl_int) return boolean {
+  return pl_int == 3
+}
+if(f(v_MyRecord.field2))...
+
+Therefore the question is, if a pure integer value (parameter) can accept omit or not. The answer is clearly defined in clause 6.1.0:
+"a) integer: a type with distinguished values which are the positive and negative whole numbers, including zero.
+    Values of integer type shall be denoted by one or more digits; the first digit shall not be zero unless the value is 0; the value zero shall be represented by a single zero."
+There is no omit in the value set of the integer type and it cannot be assigned to integer. In another words, the above example 2) shall cause an error when calling function f() with a missing .field2 field. Therefore example 1) shall do the same.
+
+Btw., any extension of the simple types with virtual "values" (like "omit") would cause performance degradation of the tools and increase the size of the generated code that may be critical in case of several telecom applications, as we have discussed earlier by email. I have asked our developers, it really would...
+
+If clarification is felt to be needed, I propose to clarify this in the restrictions part of clause 7 (btw. it seems that restriction a) of clause 7 and restriction a) of clause 7.1 claims almost the same, in 7.1 it explicitly mentions that operands are values, but the two restrictions could be merged).
+
+
+
+
+
+ + + + + + + + + + +
+ (0010142) +
+ Gyorgy Rethy    +
+ 29-06-2011 12:45    +
(edited on: 28-09-2011 16:25)
+ 		+ + + + +
+ STF discussion on 29-06-2011: Comparision mechanism for structured value fields could be extended: in the first step the presence of corresponding fields could be checked; if any field present in one value is missing in the other value, equality returns false; if the corresponding present fields have equal values, equality returns true, otherwise it returns false.
+
+Also, to solve the problem in the generic case isvalue() shall be extended to be error-safe, e.g. if a field inside an omitted field is referenced, it shall not cause an error -> A new CR on this has to be submitted.
+
+
+
+
+
+ + + + + + + + + + +
+ (0010309) +
+ Gyorgy Rethy    +
+ 30-09-2011 11:53    +
+ 		+ + + + +
+ Pls. review CR5898_resolution_v1.doc.
+
+
+
+ + + + + + + + + + +
+ (0010312) +
+ Jens Grabowski    +
+ 30-09-2011 13:59    +
+ 		+ + + + +
+ I am sorry, but I think that the resolution adds more confusion then clarification.
+
+Either we handle OMIT like a value, or not.
+
+If we handle OMIT like a value, OMIT values (e.g., optional record fields set to OMIT), can be freely used in relational operators. Even OMIT == OMIT will evaluate to true.
+
+If we do not handle OMIT like a value, OMIT values can not be used in relational operators at all. E.g.,
+
+type record MyRecord_Type {
+   integer field1,
+   integer field2 optional
+};
+
+template (value) MyRecord_Type cs_MyRecord := {
+   field1 := 1,
+   field2 := omit
+};
+
+if (v_MyRecord.field2 == 3) { ... } // will result in a runtime error
+if (v_MyRecord.field2 == omit) { ... } // will also result in a runtime error
+
+The current solution sometimes handles OMIT like a value and sometimes not.
+
+
+
+ + + + + + + + + + +
+ (0010313) +
+ Jens Grabowski    +
+ 30-09-2011 14:00    +
+ 		+ + + + +
+ Reassigned to György for discussion.
+
+
+
+ + + + + + + + + + +
+ (0010316) +
+ Gyorgy Rethy    +
+ 30-09-2011 15:01    +
(edited on: 30-09-2011 15:02)
+ 		+ + + + +
+ Thinking it further, the case of comparing two omitted fields shall not be allowed. In this case the user shall check if at least one of the optional fields is present (writing a function for this is not really an issue. Otherwise the user will - and existing code does -, consider that the content of the optional field is a value and it may cause an error at other places anyway.
+For example
+type set S1 { integer a1 optional};
+type set S2 { integer b1 optional, integer b2 optional };
+type set S3 { integer c1 };
+...
+var S1 vl_S1 := { a1 := omit }
+var S2 vl_S2 := { b1 := omit, b2 := 5 }
+var S3 vl_S3 := { c1 := 3 }
+...
+if(S1.a1==S2.b1){P.send(S1.a1)}//send would cause an error
+if(S1.a1==S2.b2){P.send(S1.a1)}//this will work in this case, because S2.b2 is present
+if(S1.a1==S3.c1){P.send(S1.a1)}//this always will work
+
+CR5898_resolution_v2.doc contains a proposed resolution according to this.
+
+It needs STF discussion and decision.
+
+
+
+
+
+ + + + + + + + + + +
+ (0010321) +
+ Wolfgang Seka    +
+ 01-10-2011 12:11    +
+ 		+ + + + +
+ I don't understand why comparing two omitted fields shall not be allowed and I don't agree to this with a similar argument as by Jens: When I can compare an omitted field with another field there shall be no restriction. From telecommunication's point of view that even may make sense.
+E.g. I receive message twice and want to check whether some field is the same in both message: "if (m1.field == m2.field)"
+When this is allowed for optional fields in general and even when field is omitted in one of the messages people will not have in mind to separately handle the case of the field being omitted in both messages. => At some (later) point in time we will get a runtime error.
+So - it is not the question whether this can easily avoided by e.g. some function or not.
+
+
+
+ + + + + + + + + + +
+ (0010411) +
+ Jacob Wieland - Spirent    +
+ 30-11-2011 08:31    +
+ 		+ + + + +
+ I don't think that mis-using the == operator to test for value-ness before sending (instead of the proper isvalue function) should be an argument to keep this restriction.
+
+Also, if equality is not allowed on omit, then all your if-send statements would cause a runtime-error (at the == check) anyway. So, if existing code would really assume that this restriction existed before, then this would not be the way to exploit this.
+
+
+
+ + + + + + + + + + +
+ (0010412) +
+ Jacob Wieland - Spirent    +
+ 30-11-2011 08:37    +
+ 		+ + + + +
+ The CR resolution is unacceptable. Either comparison with omit is totally disallowed or totally allowed, but singling out the special case where almost EVERYONE intuitively would assume that it would be true to be an error does neither make sense nor does it help the user in any way avoid problems at runtime.
+
+If comparison with omit would be disallowed totally, I would go so far as forbidding it even at static level, i.e. comparison with optional fields should then be disallowed, forcing the user to use valueof() around them to make it explicit that they are aware that the field might be omit and forcing them to check for presentness beforehand.
+
+Still, I don't think this is the way to go.
+
+
+
+ + + + + + + + + + +
+ (0010420) +
+ Gyorgy Rethy    +
+ 30-11-2011 09:48    +
+ 		+ + + + +
+ From usability point of view you are correct. But in this case the wording shall be very cautious to emphasis that the operands of == and != are not only values but also the fields attribute that the field is absent.
+The text says today:
+""Operands of equality (==) and non-equality (!=) shall be values of the same root type and the values being compared ..."
+this wording shall completely be re-phrased.
+
+A note shall also be added saying, that if two fields are equal, this does not mean that they are present (i.e may not be values).
+
+What about missing fields of different types?
+type record MyRec { integer f1 optional, charstring f2 optional }
+const MyRec c_myRec := { omit, omit }
+...
+if (c_myRec.f1 == c_myRec.f2 ) //???; true, false, error?
+I think it shall be error (in whith case it can be checked compile time)
+
+
+
+ + + + + + + + + + +
+ (0010461) +
+ Jacob Wieland - Spirent    +
+ 01-12-2011 10:20    +
+ 		+ + + + +
+ implemented proposal to also allow comparison between field references and between field references and values.
+
+Still forbidden: omit == x, x == omit, omit == omit.
+For this ispresent() shall be used.
+
+Also amended the general restrictions part of Expressions section to be consistent with the Semantic Descriptions part.
+
+
+
+ + + + + + + + + + +
+ (0010488) +
+ Ina Schieferdecker    +
+ 01-12-2011 15:35    +
+ 		+ + + + +
+ Implemented as proposed.
+
+ + diff --git a/docs/mantis/CR5899.md b/docs/mantis/CR5899.md new file mode 100644 index 0000000000000000000000000000000000000000..54d272a44fa285628516d2a8f844e47f1be0fcd0 --- /dev/null +++ b/docs/mantis/CR5899.md @@ -0,0 +1,482 @@ + + + + + + + + + + + + + 0005899: Clarification for partially initialised array - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005899Part 01: TTCN-3 Core LanguageClarificationpublic17-06-2011 11:4517-07-2011 05:59
ReporterWolfgang Seka 
Assigned ToIna Schieferdecker 
PrioritynormalSeveritymajorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.3.2 (interim 2011)Fixed in Versionv4.3.2 (interim 2011) 
Clause Reference(s)201 873-1 cl. 6.2.3
Source (company - Author)stf160 - Wolfgang
Summary0005899: Clarification for partially initialised array
DescriptionInitialisation of "record of" is described in the core language in cl. 6.2.3.
+Regarding uninitialised elements the core language says
+"Undefined elements are permitted only in transient states (while the value remains invisible). Sending a record of or set of value with undefined elements shall cause a dynamic testcase error."
+But seems not to be clearly specified what is meant with "transient states" or with the visibility of the value/element.
+E.g. Assume we have a function initialing some array i.e. the function returns a "record of".
+In this case at least one compiler raises a run-time error even though there is no access to any of the uninitialised fields:
+  v_MyArray := f_MyArray_PartialInit(); // => runtime error
Steps To Reproduce
Additional InformationNote:
+If the above example would be not correct acc. the core language, from a users point of view there shall be a compilation error rather than a run-time error
+
TagsNo tags attached.
Relationships
Attached Filesdoc CR5899_resolution.doc (41,984) 01-07-2011 13:24
http://oldforge.etsi.org/mantis/file_download.php?file_id=2546&type=bug
doc CR5899_resolution_v2.doc (56,832) 01-07-2011 16:47
http://oldforge.etsi.org/mantis/file_download.php?file_id=2554&type=bug
doc CR5899_resolution_v3.doc (57,344) 04-07-2011 14:46
http://oldforge.etsi.org/mantis/file_download.php?file_id=2557&type=bug
Issue History
Date ModifiedUsernameFieldChange
17-06-2011 11:45Wolfgang SekaNew Issue
17-06-2011 11:45Wolfgang SekaClause Reference(s) => 201 873-1 cl. 6.2.3
17-06-2011 11:45Wolfgang SekaSource (company - Author) => stf160 - Wolfgang
22-06-2011 16:07Gyorgy RethyProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
28-06-2011 10:55Jacob Wieland - SpirentNote Added: 0010130
29-06-2011 09:07Gyorgy RethyNote Added: 0010134
30-06-2011 09:57Gyorgy RethySeverityblock => major
30-06-2011 11:14Gyorgy RethyNote Added: 0010154
30-06-2011 11:19Gyorgy RethyNote Edited: 0010154
30-06-2011 11:20Gyorgy RethyStatusnew => assigned
30-06-2011 11:20Gyorgy RethyAssigned To => Jacob Wieland - Spirent
30-06-2011 14:36Gyorgy RethyNote Edited: 0010154
01-07-2011 13:24Jacob Wieland - SpirentFile Added: CR5899_resolution.doc
01-07-2011 13:26Jacob Wieland - SpirentNote Added: 0010175
01-07-2011 13:27Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
01-07-2011 16:47Gyorgy RethyNote Added: 0010190
01-07-2011 16:47Gyorgy RethyFile Added: CR5899_resolution_v2.doc
01-07-2011 16:48Gyorgy RethyNote Edited: 0010190
01-07-2011 16:48Gyorgy RethyAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
04-07-2011 10:05Jacob Wieland - SpirentNote Added: 0010205
04-07-2011 14:45Gyorgy RethyNote Added: 0010207
04-07-2011 14:46Gyorgy RethyFile Added: CR5899_resolution_v3.doc
04-07-2011 17:01Jacob Wieland - SpirentNote Added: 0010208
05-07-2011 09:42Gyorgy RethyNote Added: 0010209
05-07-2011 12:40Jacob Wieland - SpirentNote Added: 0010210
05-07-2011 14:37Gyorgy RethyStatusassigned => resolved
05-07-2011 14:37Gyorgy RethyFixed in Version => Edition 4.3.2 (interim)
05-07-2011 14:37Gyorgy RethyResolutionopen => fixed
05-07-2011 14:37Gyorgy RethyNote Added: 0010211
05-07-2011 14:37Gyorgy RethyStatusresolved => feedback
05-07-2011 14:37Gyorgy RethyResolutionfixed => reopened
05-07-2011 14:38Gyorgy RethyAssigned ToJacob Wieland - Spirent => Ina Schieferdecker
05-07-2011 14:38Gyorgy RethyStatusfeedback => resolved
05-07-2011 14:38Gyorgy RethyResolutionreopened => fixed
05-07-2011 14:38Gyorgy RethyTarget Version => Edition 4.3.2 (interim)
17-07-2011 05:59Ina SchieferdeckerNote Added: 0010223
17-07-2011 05:59Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010130) +
+ Jacob Wieland - Spirent    +
+ 28-06-2011 10:55    +
+ 		+ + + + +
+ In a variable assignment there is an access to the uninitialized fields. When assigning the fields to the variable v_MyArray, each element must be copied. Therefore, it must be initialized.
+
+There cannot be a compilation error because this cannot be checked at compile-time as the compiler cannot know in general what f_MyArray_PartialInit() does. So, it can at most generate a warning, but basically this warning would then have to be generated for almost all assignments of structured variables and thus would not be helpful. (Same problem as with index-checking).
+
+
+
+ + + + + + + + + + +
+ (0010134) +
+ Gyorgy Rethy    +
+ 29-06-2011 09:07    +
+ 		+ + + + +
+ It is not defined anywhere, that assigning a record of means copying of all elements one-by-one. This is just one - inefficient - way of doing that. Another way, e.g. to assign the pointer of the array returned by the function to the pointer of the variable. But this is just a side comment.
+
+More importantly, I'm always in favor of checking whatever possible compile time. But once this case cannot be checked compile time, what is the sense of this restriction? This is just decreases usability and the only "benefit" is that completeness shall be checked before each assignment, instead of checking this once, before sending the value (or entering a library public function, depending of the use case).
+
+
+
+ + + + + + + + + + +
+ (0010154) +
+ Gyorgy Rethy    +
+ 30-06-2011 11:14    +
(edited on: 30-06-2011 14:36)
+ 		+ + + + +
+ Result of STF430's discussion on 30.06.2001:
+Allow
+-assigning not fully initialized structured values
+-passing not fully initialized structured values as in parameter (inout and out are already allowed)
+-returning not fully initialized structured values
+-concatenate, rotate and shift not fully initialized structured values
+
+The standard'd text shall be checked as this issue is handled at several places, so small text changes will be needed at several places; the whole text has to be checked for consistency.
+
+Submit a CR to extend isvalue: return true if parameter is completely initialized and contains a value, return false in all other cases (e.g. for non-accessible fields or uninitialized parameter). Also ispresent and ischosen should be consistent with this.
+
+Submit a CR on isbound.
+
+
+
+
+
+ + + + + + + + + + +
+ (0010175) +
+ Jacob Wieland - Spirent    +
+ 01-07-2011 13:26    +
+ 		+ + + + +
+ uploaded CR5899_resolution.doc, please review
+
+
+
+ + + + + + + + + + +
+ (0010190) +
+ Gyorgy Rethy    +
+ 01-07-2011 16:47    +
(edited on: 01-07-2011 16:48)
+ 		+ + + + +
+ I think that we agreed that uninitialized stuff cannot be returned as this would be a workaround to make already initialized stuff uninitialized again. This could be problematic both from the consistency and implementation point of view.
+Otherwise OK, some editorial changes, see CR5899_resolution_v2.doc. Pls. check.
+
+
+
+
+
+ + + + + + + + + + +
+ (0010205) +
+ Jacob Wieland - Spirent    +
+ 04-07-2011 10:05    +
+ 		+ + + + +
+ How would uninitializing stuff be possible when returning it is possible but assignment of the returned stuff is not possible?
+
+
+
+ + + + + + + + + + +
+ (0010207) +
+ Gyorgy Rethy    +
+ 04-07-2011 14:45    +
+ 		+ + + + +
+ Hi Jacob,
+
+seems that we are saying the same. I have written earlier: "I think that we agreed that uninitialized stuff cannot be returned", thus returning uninitialized stuff shall NOT be allowed - we both claiming this. Ok, I can see, it has been corrected in the value variables clause but not in the template variable clause. I have corrected this, see text in CR5899_resolution_v3.doc for final review.
+
+
+
+ + + + + + + + + + +
+ (0010208) +
+ Jacob Wieland - Spirent    +
+ 04-07-2011 17:01    +
+ 		+ + + + +
+ No, we are not in agreement on this. We decided that returning uninitialized is not harmful in itself. If the function returns something which is then not used, why should that be an error. Thus, our philosophy was: only disallow that which can lead to an error. I.e. the assignment. Therefore, I restricted rhs of assignment to partially initialized. Sure, in most cases the effect is the same, but I would rather check this at runtime at the places of assignment than at all return-statements.
+
+small example:
+
+function f() return integer { var integer i; return i }
+function g(integer x) { // does nothing with x }
+
+why should g(f()) be an error?
+
+
+
+ + + + + + + + + + +
+ (0010209) +
+ Gyorgy Rethy    +
+ 05-07-2011 09:42    +
+ 		+ + + + +
+ Hi Jacob,
+
+Because of consistency, not to have different rules for "all" the cases. Assignment lhs of assignment and a formal parameter are analogous things. In a similar way, rhs of the assignment, actual parameters and return values are also analugue things. Therefore the rules shall be the same at least for these categories not to overcomplicate the language for nothing.
+
+I haven't heard any use case for that and no one requested such feature. So, we would solve a null problem, complicate the tools but adding again a specific rule ... that we should avoid.
+
+Btw. not returning uninitialized value/template can be checked compile time with a limited effort, at least for the most usual cases (let me say 99%). Checking the assignment is really possible in runtime only - at least with reasonable effort.
+
+So, you can see, the reasons are mainly not technical but rather usability issues.
+
+
+
+ + + + + + + + + + +
+ (0010210) +
+ Jacob Wieland - Spirent    +
+ 05-07-2011 12:40    +
+ 		+ + + + +
+ OK
+
+
+
+ + + + + + + + + + +
+ (0010211) +
+ Gyorgy Rethy    +
+ 05-07-2011 14:37    +
+ 		+ + + + +
+ As in CR5899_resolution_v3.doc.
+
+
+
+ + + + + + + + + + +
+ (0010223) +
+ Ina Schieferdecker    +
+ 17-07-2011 05:59    +
+ 		+ + + + +
+ Basically implemented as proposed.
+
+ + diff --git a/docs/mantis/CR5904.md b/docs/mantis/CR5904.md new file mode 100644 index 0000000000000000000000000000000000000000..a230ea9c11e5aff271c2858e1bd8e8473add6e4b --- /dev/null +++ b/docs/mantis/CR5904.md @@ -0,0 +1,187 @@ + + + + + + + + + + + + + 0005904: Mapping of <xs:element name="dummy1"></xs:element> to TTCN-3 - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005904Part 09: Using XML with TTCN-3Technicalpublic20-06-2011 14:0413-07-2011 16:42
ReporterThilo Lauer 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.3.1 (published 2011-06) 
Target VersionFixed in Version 
Clause Reference(s)XSD Language Mapping
For STF discussion
Source (company - Author)Devoteam Danet - Thilo Lauer
Summary0005904: Mapping of <xs:element name="dummy1"></xs:element> to TTCN-3
DescriptionHow shall this be mapped to TTCN-3:
+
+<xs:element name="dummy1"></xs:element>
+
+or
+
+<xs:element name="dummy2" />
+
+
+
+[Gyorgy] responded already:
+the default type of XSD elements is anyType,
+see the XSD spec. Part-1 $3.3.2:
+
+"{type definition}
+The type definition corresponding to the <simpleType> or <complexType> element information item in the [children], if either is present, otherwise the type definition {resolved} to by the {actual value} of the type [attribute], otherwise the {type definition} of the element declaration •resolved• to by the {actual value} of the substitutionGroup [attribute], if present, otherwise the {ur-type definition}".
+
+Hence it shall be translated to XSD.AnyType.
+Currently this case is not handled in Part-9 $7.3,
+could you submit a CR for this case pls.?
+
+[Thilo] hereby submitted as CR.
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR5904_resolution_v1.doc (83,456) 30-06-2011 15:36
http://oldforge.etsi.org/mantis/file_download.php?file_id=2533&type=bug
Issue History
Date ModifiedUsernameFieldChange
20-06-2011 14:04Thilo LauerNew Issue
20-06-2011 14:04Thilo LauerClause Reference(s) => XSD Language Mapping
20-06-2011 14:04Thilo LauerSource (company - Author) => Devoteam Danet - Thilo Lauer
29-06-2011 11:43Gyorgy RethyStatusnew => assigned
29-06-2011 11:43Gyorgy RethyAssigned To => Gyorgy Rethy
30-06-2011 10:03Gyorgy RethyFile Added: CR5904_resolution_v1.doc
30-06-2011 10:04Gyorgy RethyNote Added: 0010153
30-06-2011 10:04Gyorgy RethyAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
30-06-2011 10:06Gyorgy RethyAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
30-06-2011 15:24Gyorgy RethyFile Deleted: CR5904_resolution_v1.doc
30-06-2011 15:24Gyorgy RethyFile Added: CR5904_resolution_v1.doc
30-06-2011 15:25Gyorgy RethyAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
30-06-2011 15:36Gyorgy RethyFile Deleted: CR5904_resolution_v1.doc
30-06-2011 15:36Gyorgy RethyFile Added: CR5904_resolution_v1.doc
30-06-2011 16:29Jacob Wieland - SpirentNote Added: 0010162
30-06-2011 16:30Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
01-07-2011 09:35Gyorgy RethyStatusassigned => resolved
01-07-2011 09:35Gyorgy RethyFixed in Version => Edition 4.3.2 (interim)
01-07-2011 09:35Gyorgy RethyResolutionopen => fixed
01-07-2011 09:36Gyorgy RethyNote Added: 0010171
01-07-2011 09:36Gyorgy RethyStatusresolved => feedback
01-07-2011 09:36Gyorgy RethyResolutionfixed => reopened
01-07-2011 09:37Gyorgy RethyStatusfeedback => resolved
01-07-2011 09:37Gyorgy RethyResolutionreopened => fixed
01-07-2011 09:37Gyorgy RethyTarget Version => Edition 4.3.2 (interim)
13-07-2011 16:41Gyorgy RethyStatusresolved => closed
13-07-2011 16:41Gyorgy RethyNote Added: 0010221
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010153) +
+ Gyorgy Rethy    +
+ 30-06-2011 10:04    +
+ 		+ + + + +
+ Resolution draft is in CR5904_resolution_v1.doc, pls. review.
+
+
+
+ + + + + + + + + + +
+ (0010162) +
+ Jacob Wieland - Spirent    +
+ 30-06-2011 16:29    +
+ 		+ + + + +
+ Ok.
+
+
+
+ + + + + + + + + + +
+ (0010171) +
+ Gyorgy Rethy    +
+ 01-07-2011 09:35    +
+ 		+ + + + +
+ Thanks.
+
+
+
+ + + + + + + + + + +
+ (0010221) +
+ Gyorgy Rethy    +
+ 13-07-2011 16:41    +
+ 		+ + + + +
+ Added to master copy.
+
+ + diff --git a/docs/mantis/CR5905.md b/docs/mantis/CR5905.md new file mode 100644 index 0000000000000000000000000000000000000000..0731eed7ecbcab3e8e80f751598b38a0a813f29f --- /dev/null +++ b/docs/mantis/CR5905.md @@ -0,0 +1,146 @@ + + + + + + + + + + + + + 0005905: Mapping of <xs:attribute name="attrWithoutType"/> to TTCN-3 - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005905Part 09: Using XML with TTCN-3Technicalpublic20-06-2011 14:0813-07-2011 17:04
ReporterThilo Lauer 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.3.1 (published 2011-06) 
Target VersionFixed in Version 
Clause Reference(s)XSD Language Mapping
For STF discussion
Source (company - Author)Devoteam Danet - Thilo Lauer
Summary0005905: Mapping of <xs:attribute name="attrWithoutType"/> to TTCN-3
DescriptionHow shall this be mapped to TTCN-3:
+
+<xs:attribute name="attrWithoutType"/>
+
+[Gyorgy] already responded:
+the default type of XSD attributes is anySimpleType,
+see the XSD spec. Part-1 $3.2.2:
+
+"{type definition}
+The simple type definition corresponding to the <simpleType> element information item in the [children], if present, otherwise the simple type definition {resolved} to by the {actual value} of the type [attribute], if present, otherwise the {simple ur-type definition}."
+
+Hence it shall be translated to XSD.AnySimpleType.
+Currently this case is not handled in Part-9 $7.4.1,
+could you submit a CR for this case pls.?
+
+[Thilo] hereby submitted as CR.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR5905_resolution_v1.doc (98,304) 30-06-2011 15:53
http://oldforge.etsi.org/mantis/file_download.php?file_id=2535&type=bug
doc CR5905_resolution_v2.doc (48,640) 30-06-2011 16:27
http://oldforge.etsi.org/mantis/file_download.php?file_id=2536&type=bug
Issue History
Date ModifiedUsernameFieldChange
20-06-2011 14:08Thilo LauerNew Issue
20-06-2011 14:08Thilo LauerClause Reference(s) => XSD Language Mapping
20-06-2011 14:08Thilo LauerSource (company - Author) => Devoteam Danet - Thilo Lauer
29-06-2011 11:39Gyorgy RethyStatusnew => assigned
29-06-2011 11:39Gyorgy RethyAssigned To => Gyorgy Rethy
29-06-2011 11:41Gyorgy RethyTarget Version => Edition 4.3.2 (interim)
30-06-2011 15:51Gyorgy RethyFile Added: CR5905_resolution_v1.doc
30-06-2011 15:51Gyorgy RethyNote Added: 0010160
30-06-2011 15:51Gyorgy RethyAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
30-06-2011 15:52Gyorgy RethyFile Deleted: CR5905_resolution_v1.doc
30-06-2011 15:53Gyorgy RethyFile Added: CR5905_resolution_v1.doc
30-06-2011 16:27Jacob Wieland - SpirentFile Added: CR5905_resolution_v2.doc
30-06-2011 16:27Jacob Wieland - SpirentNote Added: 0010161
30-06-2011 16:27Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
01-07-2011 09:38Gyorgy RethyResolutionopen => fixed
01-07-2011 09:38Gyorgy RethyFixed in Version => Edition 4.3.2 (interim)
01-07-2011 09:39Gyorgy RethyStatusassigned => resolved
13-07-2011 17:04Gyorgy RethyStatusresolved => closed
13-07-2011 17:04Gyorgy RethyNote Added: 0010222
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010160) +
+ Gyorgy Rethy    +
+ 30-06-2011 15:51    +
+ 		+ + + + +
+ Proposed solution is in the file CR5905_resolution_v1.doc. Pls. review.
+
+
+
+ + + + + + + + + + +
+ (0010161) +
+ Jacob Wieland - Spirent    +
+ 30-06-2011 16:27    +
+ 		+ + + + +
+ corrected only small grammatical error, otherwise ok
+
+
+
+ + + + + + + + + + +
+ (0010222) +
+ Gyorgy Rethy    +
+ 13-07-2011 17:04    +
+ 		+ + + + +
+ Added to master copy.
+
+ + diff --git a/docs/mantis/CR5909.md b/docs/mantis/CR5909.md new file mode 100644 index 0000000000000000000000000000000000000000..10e7ca231cc231744eaa5f78873f9b483e030302 --- /dev/null +++ b/docs/mantis/CR5909.md @@ -0,0 +1,133 @@ + + + + + + + + + + + + + 0005909: Parameter "Reason" for reporting the final verdict's reason is missing in function(s) tliCTerminated, tliCStop, ... - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005909Part 06: TTCN-3 Control InterfaceTechnicalpublic21-06-2011 14:2801-12-2011 14:53
ReporterThilo Lauer 
Assigned ToIna Schieferdecker 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.4.1 (published 2012-04)Fixed in Versionv4.4.1 (published 2012-04) 
Clause Reference(s)Part 6, 7.3.4.1.69 and others
Source (company - Author)Devoteam Danet - Thilo Lauer
Summary0005909: Parameter "Reason" for reporting the final verdict's reason is missing in function(s) tliCTerminated, tliCStop, ...
DescriptionLog "final reason" with "final verdict" of a component:
+ 
+In the core language standard (… ed431__corev425) it reads in section:
+24.2 The Setverdict operation
+...
+The optional parameters allow to provide information that explain the reasons for assigning the verdict.
+This information is composed to a string and stored in an implicit charstring variable.
+>> On termination of the test component, the actual local verdict is logged together with the implicit charstring variable. <<
+ 
+Since the optional parameters can be seen as log information, the same rules and restrictions as for the parameters of the log statement
+(clause 19.11) apply.
+ 
+But:
+in Part 6 (TCI, …ed431_TCIv425) there is no "reason" parameter etc. for the respective tli-Functions tliCTerminated, tliCStop, …:
+
+e.g.:
+7.3.4.1.69 tliCTerminated
+Signature void tliCTerminated(in TString am, in TInteger ts, in TString src,
+                              in TInteger line, in TriComponentIdType c,
+                              in VerdictValue verdict)
+In Parameters am An additional message.
+    ts The time when the event is produced.
+    src The source file of the test specification.
+    line The line number where the request is performed.
+    c The component which produces this event.
+    verdict The verdict of the component.
+Return Value void
+ 
+Here an In Parameter "reason" is missing.
+Or if the verdict's reason should be logged as "additional message" this should be defined explicitly in the standard.
+
+Up to now I haven't checked if the parameter reason would be necessary in other tli-functions beside tliCTerminated as well.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR5909.docx (21,683) 01-12-2011 14:44
http://oldforge.etsi.org/mantis/file_download.php?file_id=2646&type=bug
Issue History
Date ModifiedUsernameFieldChange
21-06-2011 14:28Thilo LauerNew Issue
21-06-2011 14:28Thilo LauerClause Reference(s) => Part 6, 7.3.4.1.69 and others
21-06-2011 14:28Thilo LauerSource (company - Author) => Devoteam Danet - Thilo Lauer
28-06-2011 11:20Jacob Wieland - SpirentNote Added: 0010132
29-06-2011 11:43Gyorgy RethyStatusnew => assigned
29-06-2011 11:43Gyorgy RethyAssigned To => Ina Schieferdecker
27-09-2011 13:34Gyorgy RethyTarget Version => Edition 4.4.1
01-12-2011 14:25Ina SchieferdeckerNote Added: 0010484
01-12-2011 14:29Ina SchieferdeckerFile Added: CR5909.docx
01-12-2011 14:29Ina SchieferdeckerNote Edited: 0010484
01-12-2011 14:42Ina SchieferdeckerNote Edited: 0010484
01-12-2011 14:44Ina SchieferdeckerFile Deleted: CR5909.docx
01-12-2011 14:44Ina SchieferdeckerFile Added: CR5909.docx
01-12-2011 14:53Ina SchieferdeckerStatusassigned => resolved
01-12-2011 14:53Ina SchieferdeckerResolutionopen => fixed
01-12-2011 14:53Ina SchieferdeckerFixed in Version => Edition 4.4.1
01-12-2011 14:53Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010132) +
+ Jacob Wieland - Spirent    +
+ 28-06-2011 11:20    +
+ 		+ + + + +
+ I think it would be proper in:
+tliTcTerminated,
+tliCTerminated
+tliTcStop
+
+
+
+ + + + + + + + + + +
+ (0010484) +
+ Ina Schieferdecker    +
+ 01-12-2011 14:25    +
(edited on: 01-12-2011 14:42)
+ 		+ + + + +
+ Reason added to tliTcTerminated and tliCTerminated as they report verdicts. And also tliTcStop which gives alway error verdict with an optional reason.
+
+
+
+ + diff --git a/docs/mantis/CR5912.md b/docs/mantis/CR5912.md new file mode 100644 index 0000000000000000000000000000000000000000..11b0ed466c01bb5bb1f569db716ba54a1c8d81a7 --- /dev/null +++ b/docs/mantis/CR5912.md @@ -0,0 +1,351 @@ + + + + + + + + + + + + + 0005912: Clarification for Regular Expression - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005912Part 01: TTCN-3 Core LanguageClarificationpublic30-06-2011 09:5401-07-2011 18:02
ReporterWolfgang Seka 
Assigned ToGyorgy Rethy 
PrioritynormalSeveritymajorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.3.2 (interim 2011)Fixed in Versionv4.3.2 (interim 2011) 
Clause Reference(s)ES 201 873-1 clause C.33
Source (company - Author)stf160 - Wolfgang
Summary0005912: Clarification for Regular Expression
DescriptionIn the TTCN-3 Core language there is the parameter groupno of regexp which is defined as
+"Group numbers are assigned by the order of occurrences of the opening bracket of a group and counted starting from 0 by step 1."
+As a result the the whole expression as such cannot be addressed (this is illustrated in the 1st example too, where the 1st subgroup is addressed with groupno 0).
+
+This addressing is a bit confusing since e.g. for the posix C definition the index starts with 1 and 0 means that no subgrouping is applied i.e. index 0 addresses the whole expression.
+There are the following issues to be clarified:
+- clarification that TTCN regexp differs from POSIX implementation of regexp (to make clear that there is a difference)
+- example and clarification how to address the whole expression or what happens when an expression has no subgroup (currently that seems even not possible since index 0 would refer to a non-existing subgroup)
+- As alternative the index could made optional (e.g. in "template (omit) integer groupno := omit") with omit for the top-level expression
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR5912_resolution_v1.doc (37,376) 01-07-2011 11:25
http://oldforge.etsi.org/mantis/file_download.php?file_id=2545&type=bug
doc CR5912_resolution_v2.doc (55,808) 01-07-2011 15:42
http://oldforge.etsi.org/mantis/file_download.php?file_id=2550&type=bug
doc CR5912_resolution_v3.doc (55,808) 01-07-2011 16:51
http://oldforge.etsi.org/mantis/file_download.php?file_id=2555&type=bug
Issue History
Date ModifiedUsernameFieldChange
30-06-2011 09:54Wolfgang SekaNew Issue
30-06-2011 09:54Wolfgang SekaClause Reference(s) => ES 201 873-1 clause C.33
30-06-2011 09:54Wolfgang SekaSource (company - Author) => stf160 - Wolfgang
30-06-2011 14:20Gyorgy RethyNote Added: 0010157
30-06-2011 14:21Gyorgy RethyStatusnew => assigned
30-06-2011 14:21Gyorgy RethyAssigned To => Jacob Wieland - Spirent
30-06-2011 14:21Gyorgy RethyProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
30-06-2011 14:21Gyorgy RethyTarget Version => Edition 4.3.2 (interim)
30-06-2011 14:22Gyorgy RethyNote Edited: 0010157
01-07-2011 11:25Jacob Wieland - SpirentFile Added: CR5912_resolution_v1.doc
01-07-2011 11:26Jacob Wieland - SpirentNote Added: 0010174
01-07-2011 11:27Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
01-07-2011 15:41Gyorgy RethyNote Added: 0010183
01-07-2011 15:41Gyorgy RethyNote Added: 0010184
01-07-2011 15:41Gyorgy RethyNote Added: 0010185
01-07-2011 15:42Gyorgy RethyFile Added: CR5912_resolution_v2.doc
01-07-2011 15:42Gyorgy RethyAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
01-07-2011 16:12Jacob Wieland - SpirentNote Added: 0010187
01-07-2011 16:15Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
01-07-2011 16:50Gyorgy RethyNote Added: 0010192
01-07-2011 16:51Gyorgy RethyFile Added: CR5912_resolution_v3.doc
01-07-2011 16:52Gyorgy RethyNote Added: 0010193
01-07-2011 16:52Gyorgy RethyStatusassigned => resolved
01-07-2011 16:52Gyorgy RethyResolutionopen => fixed
01-07-2011 18:01Ina SchieferdeckerNote Added: 0010204
01-07-2011 18:02Ina SchieferdeckerStatusresolved => closed
01-07-2011 18:02Ina SchieferdeckerFixed in Version => Edition 4.3.2 (interim)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010157) +
+ Gyorgy Rethy    +
+ 30-06-2011 14:20    +
(edited on: 30-06-2011 14:22)
+ 		+ + + + +
+ STF discussion on 30.06.2001:
+Add a stepwise description of regexp's behaviour to the text:
+1) inpar shall match expression according to character pattern matching (acc. to B.1.5)
+2) IF 1) is successful, it returns... (this part is specified already)
+
+Add a note pointing to the fact that TTCN-3 regexp is different than regular expressions in other languages.
+
+
+
+
+
+ + + + + + + + + + +
+ (0010174) +
+ Jacob Wieland - Spirent    +
+ 01-07-2011 11:26    +
+ 		+ + + + +
+ uploaded proposal, please review
+
+
+
+ + + + + + + + + + +
+ (0010183) +
+ Gyorgy Rethy    +
+ 01-07-2011 15:41    +
+ 		+ + + + +
+ Actually, the descrition of how regexp is working was there but in a wrong order, it was the second paragraph. So, have re-structured the existing text instead of adding one more explanation. See in CR5912_resolution_v1.doc. Pls. review.
+
+
+
+ + + + + + + + + + +
+ (0010184) +
+ Gyorgy Rethy    +
+ 01-07-2011 15:41    +
+ 		+ + + + +
+ Actually, the descrition of how regexp is working was there but in a wrong order, it was the second paragraph. So, have re-structured the existing text instead of adding one more explanation. See in CR5912_resolution_v2.doc. Pls. review.
+
+
+
+ + + + + + + + + + +
+ (0010185) +
+ Gyorgy Rethy    +
+ 01-07-2011 15:41    +
+ 		+ + + + +
+ Actually, the descrition of how regexp is working was there but in a wrong order, it was the second paragraph. So, have re-structured the existing text instead of adding one more explanation. See in CR5912_resolution_v2.doc. Pls. review.
+
+
+
+ + + + + + + + + + +
+ (0010187) +
+ Jacob Wieland - Spirent    +
+ 01-07-2011 16:12    +
+ 		+ + + + +
+ Except for the deletion of the 'it' (which introduces grammatical inconsistency), it's fine with me.
+
+
+
+ + + + + + + + + + +
+ (0010192) +
+ Gyorgy Rethy    +
+ 01-07-2011 16:50    +
+ 		+ + + + +
+ it was not deleted but moved to the bullet item; unfortunately to the first only. I have added "it" to the second bulet item too. Final version is in CR5912_resolution_v3.doc
+
+
+
+ + + + + + + + + + +
+ (0010193) +
+ Gyorgy Rethy    +
+ 01-07-2011 16:52    +
+ 		+ + + + +
+ Completed, reviewed.
+
+
+
+ + + + + + + + + + +
+ (0010204) +
+ Ina Schieferdecker    +
+ 01-07-2011 18:01    +
+ 		+ + + + +
+ Implemented as proposed.
+
+ + diff --git a/docs/mantis/CR5913.md b/docs/mantis/CR5913.md new file mode 100644 index 0000000000000000000000000000000000000000..99638e1c9dc3c355b156f6dfd91754c9afab8f9f --- /dev/null +++ b/docs/mantis/CR5913.md @@ -0,0 +1,279 @@ + + + + + + + + + + + + + 0005913: Error-safe isvalue() - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005913Part 01: TTCN-3 Core LanguageNew Featurepublic30-06-2011 14:5017-07-2011 07:29
ReporterGyorgy Rethy 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.3.1 (published 2011-06) 
Target Versionv4.3.2 (interim 2011)Fixed in Versionv4.3.2 (interim 2011) 
Clause Reference(s)Annex C
Source (company - Author)STF430
Summary0005913: Error-safe isvalue()
DescriptionToday the behaviour of isvalue() is not 100% unambigouos related to passing an uninitialized parameter to it. Also it causes error if the field passed in is not accessible.
+
+One of the conclusions of the discussion of CR5899 is, that isvalue() shall be extended to be really error-safe, i.e.
+- allow passing any reference to isvalue(), even if it is uninitialized or not accessible (i.e. calling isvalue() with any reference shall not cause an error);
+- return true if parameter is completely initialized and contains a value, return false in all other cases (e.g. for non-accessible fields or uninitialized parameter).
+
+Also ispresent() and ischosen() should be consistent with this.
+
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR5913_resolution_v1.doc (95,744) 30-06-2011 17:35
http://oldforge.etsi.org/mantis/file_download.php?file_id=2541&type=bug
doc CR5913_resolution_v2.doc (136,192) 01-07-2011 14:46
http://oldforge.etsi.org/mantis/file_download.php?file_id=2548&type=bug
doc CR5913_resolution_v3.doc (157,184) 01-07-2011 16:38
http://oldforge.etsi.org/mantis/file_download.php?file_id=2552&type=bug
doc CR5913_resolution_v4.doc (113,664) 17-07-2011 07:28
http://oldforge.etsi.org/mantis/file_download.php?file_id=2560&type=bug
Issue History
Date ModifiedUsernameFieldChange
30-06-2011 14:50Gyorgy RethyNew Issue
30-06-2011 14:50Gyorgy RethyStatusnew => assigned
30-06-2011 14:50Gyorgy RethyAssigned To => Jacob Wieland - Spirent
30-06-2011 14:50Gyorgy RethyClause Reference(s) => Annex C
30-06-2011 14:50Gyorgy RethySource (company - Author) => STF430
30-06-2011 17:35Jacob Wieland - SpirentFile Added: CR5913_resolution_v1.doc
30-06-2011 17:36Jacob Wieland - SpirentNote Added: 0010167
30-06-2011 17:36Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
01-07-2011 14:02Gyorgy RethyNote Added: 0010180
01-07-2011 14:44Gyorgy RethyNote Added: 0010181
01-07-2011 14:46Gyorgy RethyFile Added: CR5913_resolution_v2.doc
01-07-2011 14:46Gyorgy RethyAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
01-07-2011 16:38Gyorgy RethyFile Added: CR5913_resolution_v3.doc
01-07-2011 16:39Gyorgy RethyNote Added: 0010188
01-07-2011 16:47Jacob Wieland - SpirentNote Added: 0010191
01-07-2011 16:47Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
01-07-2011 16:55Gyorgy RethyNote Added: 0010194
01-07-2011 16:55Gyorgy RethyStatusassigned => resolved
01-07-2011 16:55Gyorgy RethyResolutionopen => fixed
01-07-2011 16:55Gyorgy RethyTarget Version => Edition 4.3.2 (interim)
05-07-2011 14:39Gyorgy RethyStatusresolved => feedback
05-07-2011 14:39Gyorgy RethyResolutionfixed => reopened
05-07-2011 14:40Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
05-07-2011 14:40Gyorgy RethyStatusfeedback => resolved
05-07-2011 14:40Gyorgy RethyResolutionreopened => fixed
05-07-2011 14:40Gyorgy RethyFixed in Version => Edition 4.3.2 (interim)
17-07-2011 07:28Ina SchieferdeckerNote Added: 0010225
17-07-2011 07:28Ina SchieferdeckerFile Added: CR5913_resolution_v4.doc
17-07-2011 07:28Ina SchieferdeckerFile Deleted: CR5913_resolution_v4.doc
17-07-2011 07:28Ina SchieferdeckerFile Added: CR5913_resolution_v4.doc
17-07-2011 07:29Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010167) +
+ Jacob Wieland - Spirent    +
+ 30-06-2011 17:36    +
+ 		+ + + + +
+ I have changed the texts for isvalue, ispresent and ischosen according to our agreement. I have also changed the general relaxation of the restriction to parameters of predefined functions. Please review.
+
+
+
+ + + + + + + + + + +
+ (0010180) +
+ Gyorgy Rethy    +
+ 01-07-2011 14:02    +
+ 		+ + + + +
+ We don't have "template expression" in the language (no template arithmetics is defined, e.g. what would be the result of (1,2,3)+complement(4,5,6)?). Expressions (that may have value operands only) are a subset of templates (that always result a specific value or an error), but
+- any expression is evaluated before calling a predefined function;
+- evaluating an expression may cause runtime error further on, e.g.
+isvalue(5/0) shall cause a runtime error as division by zero is an error during evaluating the expression (the result of which would become the actual parameter of isvalue if didn't caused an error)
+So I changed back "template expressions" to "templates" in the text.
+
+
+
+ + + + + + + + + + +
+ (0010181) +
+ Gyorgy Rethy    +
+ 01-07-2011 14:44    +
+ 		+ + + + +
+ I have also unified the text among the 3 predefined function using the text from ischosen. See reviewed/amended version in CR5913_resolution_v2.doc
+
+
+
+ + + + + + + + + + +
+ (0010188) +
+ Gyorgy Rethy    +
+ 01-07-2011 16:39    +
+ 		+ + + + +
+ Correction to the isvalue/omitted optional fields is uploaded in version CR5913_resolution_v3.doc.
+
+
+
+ + + + + + + + + + +
+ (0010191) +
+ Jacob Wieland - Spirent    +
+ 01-07-2011 16:47    +
+ 		+ + + + +
+ Okay. Can you also align this with the isbound-text?
+
+
+
+ + + + + + + + + + +
+ (0010194) +
+ Gyorgy Rethy    +
+ 01-07-2011 16:55    +
+ 		+ + + + +
+ I will align this with the isbound CR
+
+
+
+ + + + + + + + + + +
+ (0010225) +
+ Ina Schieferdecker    +
+ 17-07-2011 07:28    +
+ 		+ + + + +
+ Implemented with small editorial changes, see v4
+
+ + diff --git a/docs/mantis/CR5914.md b/docs/mantis/CR5914.md new file mode 100644 index 0000000000000000000000000000000000000000..903cb32d00567a4856b615f0778f21b02c2e9339 --- /dev/null +++ b/docs/mantis/CR5914.md @@ -0,0 +1,176 @@ + + + + + + + + + + + + + 0005914: isbound() predefined function - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005914Part 01: TTCN-3 Core LanguageNew Featurepublic30-06-2011 15:1217-07-2011 07:43
ReporterGyorgy Rethy 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.3.1 (published 2011-06) 
Target Versionv4.3.2 (interim 2011)Fixed in Versionv4.3.2 (interim 2011) 
Clause Reference(s)new
Source (company - Author)STF430
Summary0005914: isbound() predefined function
DescriptionIn the diccussion of CR5899 the need for an error-safe isbound() predefined function has been identified. It shall behave the following way:
+- shall accept parameter of any types, incl. all references of structured type fields
+- it shall return true if the in parameter is at least partially initialized
+- it shall not cause an error, but return false if the in parameter is
+  - uninitialized field or record/set of element
+  - is a subfield of an uninitialized field or record/set of element
+  - is a subfield of an omit-ed field (at any level) or not selected union alternative
+  - not accessible in any other way
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR5914_resolution_v1.doc (130,560) 01-07-2011 17:35
http://oldforge.etsi.org/mantis/file_download.php?file_id=2556&type=bug
doc CR5914_resolution_v2.doc (104,448) 17-07-2011 07:42
http://oldforge.etsi.org/mantis/file_download.php?file_id=2561&type=bug
Issue History
Date ModifiedUsernameFieldChange
30-06-2011 15:12Gyorgy RethyNew Issue
30-06-2011 15:12Gyorgy RethyClause Reference(s) => new
30-06-2011 15:12Gyorgy RethySource (company - Author) => STF430
01-07-2011 09:20Gyorgy RethyStatusnew => assigned
01-07-2011 09:20Gyorgy RethyAssigned To => Gyorgy Rethy
01-07-2011 10:26Gyorgy RethyAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
01-07-2011 13:46Jacob Wieland - SpirentFile Added: CR5914_resolution.doc
01-07-2011 13:47Jacob Wieland - SpirentNote Added: 0010176
01-07-2011 13:47Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
01-07-2011 17:35Gyorgy RethyFile Added: CR5914_resolution_v1.doc
01-07-2011 17:36Gyorgy RethyFile Deleted: CR5914_resolution.doc
01-07-2011 17:39Gyorgy RethyNote Added: 0010201
01-07-2011 17:40Gyorgy RethyNote Edited: 0010201
01-07-2011 17:40Gyorgy RethyAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
04-07-2011 10:08Jacob Wieland - SpirentNote Added: 0010206
04-07-2011 10:09Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Ina Schieferdecker
04-07-2011 13:10Gyorgy RethyStatusassigned => resolved
04-07-2011 13:10Gyorgy RethyResolutionopen => fixed
04-07-2011 13:10Gyorgy RethyFixed in Version => Edition 4.3.2 (interim)
04-07-2011 13:10Gyorgy RethyTarget Version => Edition 4.3.2 (interim)
17-07-2011 07:42Ina SchieferdeckerNote Added: 0010226
17-07-2011 07:42Ina SchieferdeckerFile Added: CR5914_resolution_v2.doc
17-07-2011 07:43Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010176) +
+ Jacob Wieland - Spirent    +
+ 01-07-2011 13:47    +
+ 		+ + + + +
+ uploaded proposal CR5914_resolution.doc, please review
+
+
+
+ + + + + + + + + + +
+ (0010201) +
+ Gyorgy Rethy    +
+ 01-07-2011 17:39    +
(edited on: 01-07-2011 17:40)
+ 		+ + + + +
+ Hi, I have uploaded a version that I have created from the isvalue CR5913, not noticing that you have uploaded a file already.
+
+Could you review the file CR5914_resolution_v1.doc pls.? In this version both the text and the examples are aligned with isvalue.
+
+
+
+
+
+ + + + + + + + + + +
+ (0010206) +
+ Jacob Wieland - Spirent    +
+ 04-07-2011 10:08    +
+ 		+ + + + +
+ Reviewed - OK
+
+
+
+ + + + + + + + + + +
+ (0010226) +
+ Ina Schieferdecker    +
+ 17-07-2011 07:42    +
+ 		+ + + + +
+ Implemented with smaller editorial corrections.
+
+ + diff --git a/docs/mantis/CR5915.md b/docs/mantis/CR5915.md new file mode 100644 index 0000000000000000000000000000000000000000..25d487b46f5223b056dad2847e18a0cf33a636b7 --- /dev/null +++ b/docs/mantis/CR5915.md @@ -0,0 +1,131 @@ + + + + + + + + + + + + + 0005915: Add OS extensions for the port checkstate operation - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 04: TTCN-3 Operational Semantics
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005915Part 04: TTCN-3 Operational SemanticsNew Featurepublic01-07-2011 15:3427-02-2012 13:53
ReporterGyorgy Rethy 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.3.1 - VOID 
Target Versionv4.4.1 (published 2012-04)Fixed in Version 
Clause Reference(s)New?
Source (company - Author)STF430
Summary0005915: Add OS extensions for the port checkstate operation
DescriptionCR5243 has added the port checkstate operation to Part-1. This CR is a follow-up to add the needed amendments to Part-4 as well.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR5915-Resolution-JG-110928.doc (356,352) 28-09-2011 17:10
http://oldforge.etsi.org/mantis/file_download.php?file_id=2570&type=bug
doc CR5915-Resolution-JG-110929-V2.doc (359,936) 29-09-2011 16:01
http://oldforge.etsi.org/mantis/file_download.php?file_id=2578&type=bug
doc CR5915-Resolution-JG-110929-V3.doc (359,936) 29-09-2011 16:55
http://oldforge.etsi.org/mantis/file_download.php?file_id=2579&type=bug
Issue History
Date ModifiedUsernameFieldChange
01-07-2011 15:34Gyorgy RethyNew Issue
01-07-2011 15:34Gyorgy RethyClause Reference(s) => New?
01-07-2011 15:34Gyorgy RethySource (company - Author) => STF430
01-07-2011 16:13Gyorgy RethyStatusnew => assigned
01-07-2011 16:13Gyorgy RethyAssigned To => Jens Grabowski
27-09-2011 13:33Gyorgy RethyTarget Version => Edition 4.4.1
28-09-2011 17:10Jens GrabowskiFile Added: CR5915-Resolution-JG-110928.doc
28-09-2011 17:11Jens GrabowskiNote Added: 0010285
28-09-2011 17:12Jens GrabowskiAssigned ToJens Grabowski => Jacob Wieland - Spirent
29-09-2011 12:07Jacob Wieland - SpirentNote Added: 0010296
29-09-2011 16:01Jens GrabowskiFile Added: CR5915-Resolution-JG-110929-V2.doc
29-09-2011 16:05Jacob Wieland - SpirentNote Added: 0010303
29-09-2011 16:20Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Jens Grabowski
29-09-2011 16:55Jens GrabowskiFile Added: CR5915-Resolution-JG-110929-V3.doc
27-02-2012 13:53Jens GrabowskiStatusassigned => closed
27-02-2012 13:53Jens GrabowskiResolutionopen => fixed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010285) +
+ Jens Grabowski    +
+ 28-09-2011 17:11    +
+ 		+ + + + +
+ Resolution uploaded, assigned to Jacob for review.
+
+
+
+ + + + + + + + + + +
+ (0010296) +
+ Jacob Wieland - Spirent    +
+ 29-09-2011 12:07    +
+ 		+ + + + +
+ all component/any component? Should that not be all port/any port?
+
+
+
+ + + + + + + + + + +
+ (0010303) +
+ Jacob Wieland - Spirent    +
+ 29-09-2011 16:05    +
+ 		+ + + + +
+ Ok, but I think it should be if (x == y) instead of if (x := y).
+
+ + diff --git a/docs/mantis/CR5916.md b/docs/mantis/CR5916.md new file mode 100644 index 0000000000000000000000000000000000000000..36c0c38377fb3bc596c1ee4c42cda6ab2eb32cf9 --- /dev/null +++ b/docs/mantis/CR5916.md @@ -0,0 +1,136 @@ + + + + + + + + + + + + + 0005916: Clarification of the role of "\" within patterns - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005916Part 01: TTCN-3 Core LanguageEditorialpublic06-07-2011 10:3429-09-2011 09:47
ReporterPhilip Makedonski 
Assigned ToGyorgy Rethy 
PrioritynormalSeveritytextReproducibilityalways
StatusclosedResolutionwon't fix 
PlatformOSOS Version
Product Version 
Target Versionv4.4.1 (published 2012-04)Fixed in Version 
Clause Reference(s)Part 1, Annex B.1.5, Table B.1
Source (company - Author)University of Göttingen - Philip Makedonski
Summary0005916: Clarification of the role of "\" within patterns
DescriptionIt seems trivial at first sight, however reading into the description within Table B.1, it says:
+"Cause the following metacharacter to be interpreted as a literal (see note 3)."
+
+- this is clear so far, but:
+
+"When preceding a character without defined metacharacter meaning "\" and the
+character together match the character following the "\" (see note 4)"
+
+- although deprecated according to Note 4, it is somewhat confusing - there is perhaps a comma missing here - "when preceding a character ... , "\" and the character together match the character ... " (i.e. "\f" is reduced to "f").
+
+This is in a way also exemplified by "\"" further down in Table B.1, although it has a different connotation to it, which brings about another problem (that may need to be reported as a separate issue):
+
+Clause 6.1.1, Note 3 defines double quote (") as the one and only escape character enabling the use of double quotes within charstring values. Yet, within regular expressions, which are also charstring values, apparently a backslash (\) can serve the same purpose. This is, in my view, an inconsistency which needs to be addressed. Since removing the backslash as an escape character in regular expressions would potentially cause compatibility issues, I guess the only option is to add it as an escape character in all charstring values (which may also cause compatibility issues).
+
+with:
+B.1, Note 3: "Consequently the backslash character can be matched by a pair of backslash characters without space between them (\\), e.g. the pattern "\\d" will match the string "\d"; opening or closing square brackets can be matched by "\[" and "\]" respectively, etc."
+
+and:
+B.2, Note 4: "Such use of the metacharacter "\" is deprecated as further metacharacters can be defined later."
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
06-07-2011 10:34Philip MakedonskiNew Issue
06-07-2011 10:34Philip MakedonskiClause Reference(s) => Part 1, Annex B.1.5, Table B.1
06-07-2011 10:34Philip MakedonskiSource (company - Author) => University of Göttingen - Philip Makedonski
06-07-2011 10:46Philip MakedonskiNote Added: 0010212
27-09-2011 12:12Gyorgy RethyAssigned To => Gyorgy Rethy
27-09-2011 12:12Gyorgy RethyStatusnew => assigned
27-09-2011 12:14Gyorgy RethyProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
27-09-2011 13:25Gyorgy RethyTarget Version => Edition 4.4.1
27-09-2011 16:36Gyorgy RethyNote Added: 0010253
27-09-2011 16:37Gyorgy RethyNote Edited: 0010253
27-09-2011 16:38Gyorgy RethyNote Edited: 0010253
27-09-2011 16:39Gyorgy RethyNote Edited: 0010253
27-09-2011 16:42Gyorgy RethyNote Edited: 0010253
27-09-2011 16:43Gyorgy RethyNote Edited: 0010253
27-09-2011 16:43Gyorgy RethyNote Edited: 0010253
27-09-2011 16:44Gyorgy RethyNote Edited: 0010253
27-09-2011 16:45Gyorgy RethyNote Edited: 0010253
27-09-2011 16:46Gyorgy RethyNote Edited: 0010253
27-09-2011 16:46Gyorgy RethyNote Edited: 0010253
27-09-2011 16:47Gyorgy RethyNote Edited: 0010253
29-09-2011 09:47Gyorgy RethyStatusassigned => closed
29-09-2011 09:47Gyorgy RethyResolutionopen => won't fix
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010212) +
+ Philip Makedonski    +
+ 06-07-2011 10:46    +
+ 		+ + + + +
+ Or perhaps the intended interpretation is that \" within patterns should still contain a double quote escape character - amounting to \"". Is this the case?
+
+
+
+ + + + + + + + + + +
+ (0010253) +
+ Gyorgy Rethy    +
+ 27-09-2011 16:36    +
(edited on: 27-09-2011 16:47)
+ 		+ + + + +
+ First, it should be clear, that charstring VALUES and PATTERNS are different things. Not only "\" but also "?", "*", "|", "+" etc. have different meanings in a value and in a pattern.
+Let's see the meanings of different combinations of "\" and """ in a value and in a pattern:
+
+combination__|__meaning in a value__|__meaning in a pattern
+TODAY
+ab""cd | ab"cd | ab"cd
+ab\"cd | error | ab"cd
+ab\""cd | ab\"cd | error (\" equals ", 2nd " closes the pattern, cd remains hanging)
+ab\\cd | ab\\cd | ab\cd
+IF \ ADDED TO VALUES AS ESCAPE CHARACTER FOR "
+ab""cd | ab"cd | ab"cd -- no change
+ab\"cd | ab"cd | ab"cd -- error removed
+ab\""cd | error | error -- new error introduced
+ab\\cd | ab\cd | ab\cd -- meaning changed
+               ^ (should also be single \ for consistency ?)
+
+I cannot see a way to add \ as escape character for " without causing backward compatibility problems to existing code. It has also be noted, that "\" would have a special meaning in values only if followed by """ (or by "\" ?) but not in other cases. This would be at least as inconsistent as not having it as an escape character in values.
+
+For the above reasons I propose leave the standard as is.
+
+
+
+ + diff --git a/docs/mantis/CR5917.md b/docs/mantis/CR5917.md new file mode 100644 index 0000000000000000000000000000000000000000..272d863f56de06ac6804bbb76393f575d7bb076e --- /dev/null +++ b/docs/mantis/CR5917.md @@ -0,0 +1,71 @@ + + + + + + + + + + + + + 0005917: Wrong example in clause 27.7 - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005917Part 01: TTCN-3 Core LanguageEditorialpublic15-07-2011 15:4427-09-2011 11:41
ReporterGyorgy Rethy 
Assigned To 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionno change required 
PlatformOSOS Version
Product Version 
Target Versionv4.4.1 (published 2012-04)Fixed in Versionv4.4.1 (published 2012-04) 
Clause Reference(s)27.7
Source (company - Author)L.M.Ericsson
Summary0005917: Wrong example in clause 27.7
DescriptionThe example is:
+template MyRecord2 MyTemplate23 := {} with {optional "implicit omit"}
+  // same as MyTemplate2a, m remains undefined
+
+while MyTemplate23 cannot be the same as MyTemplate2a, as doesn't have an implicit omit attribute. The example should be:
+
+template MyRecord2 MyTemplate23 := {} with {optional "implicit omit"}
+  // the content of the template is { m:= {a:=<uninitialized>, b:=omit}}
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
15-07-2011 15:44Gyorgy RethyNew Issue
15-07-2011 15:44Gyorgy RethyClause Reference(s) => 27.7
15-07-2011 15:44Gyorgy RethySource (company - Author) => L.M.Ericsson
27-09-2011 11:41Gyorgy RethyNote Added: 0010242
27-09-2011 11:41Gyorgy RethyStatusnew => closed
27-09-2011 11:41Gyorgy RethyResolutionopen => no change required
27-09-2011 11:41Gyorgy RethyFixed in Version => Edition 4.4.1
27-09-2011 11:41Gyorgy RethyTarget Version => Edition 4.4.1
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010242) +
+ Gyorgy Rethy    +
+ 27-09-2011 11:41    +
+ 		+ + + + +
+ Record2 has a single mandatory field only, where implicit omit doesn't have effect.
+
+ + diff --git a/docs/mantis/CR5918.md b/docs/mantis/CR5918.md new file mode 100644 index 0000000000000000000000000000000000000000..3c66d6eba1117eeb0035c1ccef9dc05c97ba8334 --- /dev/null +++ b/docs/mantis/CR5918.md @@ -0,0 +1,77 @@ + + + + + + + + + + + + + 0005918: Accessing nested types within record and set types not explicitly stated in the spec - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005918Part 01: TTCN-3 Core LanguageClarificationpublic25-07-2011 16:0227-09-2011 11:38
ReporterUwe Truetsch 
Assigned To 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionno change required 
PlatformOSOS Version
Product Versionv4.2.1 (published 2010-07) 
Target Versionv4.4.1 (published 2012-04)Fixed in Versionv4.4.1 (published 2012-04) 
Clause Reference(s)6.2.1.3, 6.2.2.3
Source (company - Author)     NSN - Uwe Truetsch
Summary0005918: Accessing nested types within record and set types not explicitly stated in the spec
DescriptionWithin clause 6.2.1.3 and 6.2.2.3 it is not specified that the user can access types of record fields.
+It is not clear whether only those types shall be accessible which are defined within the record/set or whether it is generally possible for the types of all fields.
+
+e.g.
+
+type record R1 {
+   set { integer sf1, boolean sf2} f1,
+   boolean f2
+}
+
+const R1.f1 c1 := {1, true}; // is this ok?
+const R1.f1.sf1 c1 := 2; // is this ok? It is actually not a nested type definition, it's a basic type instead
+const R1.f2 c 3 := false; // is this ok?
+
+Regardless what the original intention was I would opt for the general approach that all the types of the record/set fields shall be accessible.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
25-07-2011 16:02Uwe TruetschNew Issue
25-07-2011 16:02Uwe TruetschClause Reference(s) => 6.2.1.3, 6.2.2.3
25-07-2011 16:02Uwe TruetschSource (company - Author) => NSN - Uwe Truetsch
27-09-2011 11:38Gyorgy RethyNote Added: 0010241
27-09-2011 11:38Gyorgy RethyStatusnew => closed
27-09-2011 11:38Gyorgy RethyResolutionopen => no change required
27-09-2011 11:38Gyorgy RethyFixed in Version => Edition 4.4.1
27-09-2011 11:38Gyorgy RethyTarget Version => Edition 4.4.1
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010241) +
+ Gyorgy Rethy    +
+ 27-09-2011 11:38    +
+ 		+ + + + +
+ It is explicitly written in the text, example 3 of $6.2.1.1 shows that all 3 cases are allowed.
+
+ + diff --git a/docs/mantis/CR5919.md b/docs/mantis/CR5919.md new file mode 100644 index 0000000000000000000000000000000000000000..06ea57c64374b97c769a3f326f912e57e7bfe903 --- /dev/null +++ b/docs/mantis/CR5919.md @@ -0,0 +1,131 @@ + + + + + + + + + + + + + 0005919: wrong BNF in section: A.1.6.8.1 With statement - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005919Part 01: TTCN-3 Core LanguageTechnicalpublic25-07-2011 17:0328-09-2011 09:46
ReporterUwe Truetsch 
Assigned ToIna Schieferdecker 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.3.1 (published 2011-06) 
Target Versionv4.4.1 (published 2012-04)Fixed in Versionv4.4.1 (published 2012-04) 
Clause Reference(s)A.1.6.8.1
Source (company - Author)NSN - Uwe Truetsch
Summary0005919: wrong BNF in section: A.1.6.8.1 With statement
Descriptionproduction 454 has to be corrected as it does not allow refs like [-].field or [-][0]
+
+Current definition:
+
+454.DefOrFieldRef ::= DefinitionRef |
+                       (FieldReference [ExtendedFieldReference]) |
+                       ("[" Minus | SingleExpression "]") |
+                       AllRef
+
+Proposed definition (as suggested by Mr. Jacob Wieland):
+
+454. DefOrFieldRef ::= DefinitionRef |
+                          ( ( FieldReference | "[" NotUsedSymbol "]" ) [ ExtendedFieldReference ] ) |
+                          AllRef
+
+
+Example:
+
+type record of record of record {
+  integer f1,
+  boolean f2
+ } RoRoR
+
+type component C1 {
+  var RoRoR cv1;
+} with {
+  extension (cv1[-][-], // not possible with current production
+             cv1[-][0], // not possible with current production
+             cv1[0][-]) // ok with current production
+               "some text"
+}
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
25-07-2011 17:03Uwe TruetschNew Issue
25-07-2011 17:03Uwe TruetschClause Reference(s) => A.1.6.8.1
25-07-2011 17:03Uwe TruetschSource (company - Author) => NSN - Uwe Truetsch
27-09-2011 11:33Gyorgy RethyNote Added: 0010240
27-09-2011 11:33Gyorgy RethyAssigned To => Ina Schieferdecker
27-09-2011 11:33Gyorgy RethyStatusnew => assigned
27-09-2011 11:33Gyorgy RethyTarget Version => Edition 4.4.1
27-09-2011 18:50Ina SchieferdeckerNote Added: 0010259
28-09-2011 09:46Ina SchieferdeckerStatusassigned => closed
28-09-2011 09:46Ina SchieferdeckerResolutionopen => fixed
28-09-2011 09:46Ina SchieferdeckerFixed in Version => Edition 4.4.1
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010240) +
+ Gyorgy Rethy    +
+ 27-09-2011 11:33    +
+ 		+ + + + +
+ To be checked in the v4.3.2 BNF
+
+
+
+ + + + + + + + + + +
+ (0010259) +
+ Ina Schieferdecker    +
+ 27-09-2011 18:50    +
+ 		+ + + + +
+ In principle ok, except that NotUsedSymbol is not used any more, but Minus:
+
+454. DefOrFieldRef ::= DefinitionRef |
+                          ( ( FieldReference | "[" Minus "]" ) [ ExtendedFieldReference ] ) |
+                          AllRef
+
+ + diff --git a/docs/mantis/CR5920.md b/docs/mantis/CR5920.md new file mode 100644 index 0000000000000000000000000000000000000000..928a0339dd4c2c023a405dcf6d18bf4232f8d460 --- /dev/null +++ b/docs/mantis/CR5920.md @@ -0,0 +1,70 @@ + + + + + + + + + + + + + 0005920: Out parameter of int2enum need not be initialized - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005920Part 01: TTCN-3 Core LanguageTechnicalpublic11-08-2011 16:1628-09-2011 12:34
ReporterGyorgy Rethy 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.4.1 (published 2012-04)Fixed in Versionv4.4.1 (published 2012-04) 
Clause Reference(s)16.1.2
Source (company - Author)L.M.Ericsson
Summary0005920: Out parameter of int2enum need not be initialized
DescriptionClause 16.1.2 restriction 3)contains the generic statement
+"3) all actual parameters shall be initialized with the exception of the actual parameter passed to the predefined functions isvalue, ischosen, ispresent and isbound predefined function, which may be uninitialized or even non-evaluable reference expressions."
+
+while int2enum() has an out parameter that need not be initialized when the function is called.
+
+Solution
+change restriction 3) to ("in and inout" is added):
+"3) all actual in and inout parameters shall be initialized with the exception of the actual parameter passed to the predefined functions isvalue, ischosen, ispresent and isbound predefined function, which may be uninitialized or even non-evaluable reference expressions."
Steps To Reproduce
Additional InformationChange to "all in and inout actual parameters ..."
TagsNo tags attached.
Relationships
related to 0005965closed Ina Schieferdecker Invalid reference to shift operator 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
11-08-2011 16:16Gyorgy RethyNew Issue
11-08-2011 16:16Gyorgy RethyClause Reference(s) => 16.1.2
11-08-2011 16:16Gyorgy RethySource (company - Author) => L.M.Ericsson
11-08-2011 16:20Gyorgy RethyDescription Updated
27-09-2011 11:30Gyorgy RethyAssigned To => Ina Schieferdecker
27-09-2011 11:30Gyorgy RethyStatusnew => assigned
27-09-2011 11:30Gyorgy RethyTarget Version => Edition 4.4.1
27-09-2011 11:30Gyorgy RethyAdditional Information Updated
28-09-2011 12:33Ina SchieferdeckerNote Added: 0010269
28-09-2011 12:34Ina SchieferdeckerStatusassigned => closed
28-09-2011 12:34Ina SchieferdeckerResolutionopen => fixed
28-09-2011 12:34Ina SchieferdeckerFixed in Version => Edition 4.4.1
29-11-2011 13:33Ina SchieferdeckerRelationship addedrelated to 0005965
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010269) +
+ Ina Schieferdecker    +
+ 28-09-2011 12:33    +
+ 		+ + + + +
+ as proposed.
+
+ + diff --git a/docs/mantis/CR5921.md b/docs/mantis/CR5921.md new file mode 100644 index 0000000000000000000000000000000000000000..e12948e5e78f4ef85361deb77a7c4d4deb5883f6 --- /dev/null +++ b/docs/mantis/CR5921.md @@ -0,0 +1,101 @@ + + + + + + + + + + + + + 0005921: Wrong permutation example in B.1.3.3/Note1 - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005921Part 01: TTCN-3 Core LanguageEditorialpublic16-08-2011 16:4428-09-2011 12:28
ReporterGyorgy Rethy 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.4.1 (published 2012-04)Fixed in Versionv4.4.1 (published 2012-04) 
Clause Reference(s)B.1.3.3
Source (company - Author)L.M.Ericsson
Summary0005921: Wrong permutation example in B.1.3.3/Note1
DescriptionThe current text of the note is:
+"NOTE 1: AnyElementsOrNone used inside permutation has a different effect as AnyElementsOrNone used in conjunction with permutation as in the latter AnyElementsOrNone replaces consecutive elements only. For example, {permutation(1,2,*)} is equivalent to ({*,1,*,2,*},{*,2,*,1,*}), while {permutation(1,2),*} is equivalent to ({1,2},{2,1},*)."
+
+In fact the 2nd example in the second sentence is wrong, is should read
+"... while {permutation(1,2),*} is equivalent to ({1,2,*},{2,1,*})."
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
16-08-2011 16:44Gyorgy RethyNew Issue
16-08-2011 16:44Gyorgy RethyClause Reference(s) => B.1.3.3
16-08-2011 16:44Gyorgy RethySource (company - Author) => L.M.Ericsson
27-09-2011 11:28Gyorgy RethyNote Added: 0010239
27-09-2011 11:28Gyorgy RethyAssigned To => Ina Schieferdecker
27-09-2011 11:28Gyorgy RethyStatusnew => assigned
27-09-2011 11:28Gyorgy RethyTarget Version => Edition 4.4.1
28-09-2011 12:27Ina SchieferdeckerNote Added: 0010266
28-09-2011 12:27Ina SchieferdeckerNote Added: 0010267
28-09-2011 12:28Ina SchieferdeckerStatusassigned => closed
28-09-2011 12:28Ina SchieferdeckerResolutionopen => fixed
28-09-2011 12:28Ina SchieferdeckerFixed in Version => Edition 4.4.1
28-09-2011 12:31Ina SchieferdeckerNote Deleted: 0010267
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010239) +
+ Gyorgy Rethy    +
+ 27-09-2011 11:28    +
+ 		+ + + + +
+ To be corrected.
+
+
+
+ + + + + + + + + + +
+ (0010266) +
+ Ina Schieferdecker    +
+ 28-09-2011 12:27    +
+ 		+ + + + +
+ As suggested.
+
+ + diff --git a/docs/mantis/CR5922.md b/docs/mantis/CR5922.md new file mode 100644 index 0000000000000000000000000000000000000000..32a5fc1e54f912283e20264d2b97de3538829159 --- /dev/null +++ b/docs/mantis/CR5922.md @@ -0,0 +1,606 @@ + + + + + + + + + + + + + 0005922: why strong typing is not used in map and unmap? - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005922Part 01: TTCN-3 Core LanguageTechnicalpublic22-08-2011 15:1928-08-2013 14:58
ReporterAndrus Lehtmets 
Assigned ToIna Schieferdecker 
PrioritynormalSeveritymajorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.6.1 (published 2014-06)Fixed in Versionv4.6.1 (published 2014-06) 
Clause Reference(s)TTCN-3 Edition 4.3.1: Core Language
Source (company - Author)Elvior
Summary0005922: why strong typing is not used in map and unmap?
DescriptionWhy strong typing is not used in map and unmap
+
+This makes it impossible to resolve system type during compile time.
+
+This is important when using port parameters, because otherwise it is impossible to perform any compile time check regarding parameter types an number of parameters.
Steps To Reproduce
Additional InformationIna: Wrt. strong typing in map: we have the concept of consistent connections in TTCN-3, which also apply to the usage of map and unmap. That has been designed by intend. Please explain scenarios why (and how) you like to sharpen this.
+
+Tomáš Urban: The problem is that TSI type declaration is a part of test case declaration and it is visible only within its scope. So if you use map(self:PCO2, system:PCO1) param(v_test1, v_test2) inside a function called from the test case (which is a common situation in many test suites), there's no way how to find out what is the system port type in compile time and it is therefore necessary to link parameters in runtime. We have no technical issues with implementing this solution, but it means that some errors in the code won't be discovered during compilation. Strong typing would resolve this problem. It could be applied only if the param clause is present (meaning there would be no backward compatibility problems with legacy mapping/unmapping calls which don't contain parameters) and it would determine the required type of the system port: map(self:PCO2, system:PCO1) param MyPortType (v_test1, v_test2).
+
+
TagsNo tags attached.
Relationships
related to 0006412closed Ina Schieferdecker system component shall be passed to functions with map/unmap statements 
Attached Filesdoc CR5922.doc (753,664) 29-09-2011 14:10
http://oldforge.etsi.org/mantis/file_download.php?file_id=2574&type=bug
doc CR5922-v2.doc (1,268,736) 11-07-2013 15:21
http://oldforge.etsi.org/mantis/file_download.php?file_id=2831&type=bug
doc CR5922-v3.doc (1,292,800) 28-08-2013 14:57
http://oldforge.etsi.org/mantis/file_download.php?file_id=2870&type=bug
Issue History
Date ModifiedUsernameFieldChange
22-08-2011 15:19Andrus LehtmetsNew Issue
22-08-2011 15:19Andrus LehtmetsClause Reference(s) => TTCN-3 Edition 4.3.1: Core Language
22-08-2011 15:19Andrus LehtmetsSource (company - Author) => Elvior
27-09-2011 12:09Gyorgy RethyProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
27-09-2011 12:09Gyorgy RethyAssigned To => Jacob Wieland - Spirent
27-09-2011 12:09Gyorgy RethyStatusnew => assigned
27-09-2011 12:09Gyorgy RethyTarget Version => Edition 4.4.1
27-09-2011 16:37Jacob Wieland - SpirentNote Added: 0010254
29-09-2011 10:50Gyorgy RethyNote Added: 0010292
29-09-2011 14:10Jacob Wieland - SpirentFile Added: CR5922.doc
29-09-2011 14:11Jacob Wieland - SpirentNote Added: 0010299
29-09-2011 14:11Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
30-11-2011 11:16Gyorgy RethyNote Added: 0010437
30-11-2011 11:16Gyorgy RethyAssigned ToGyorgy Rethy => Jens Grabowski
02-12-2011 09:04Jens GrabowskiNote Added: 0010498
02-12-2011 09:05Jens GrabowskiAssigned ToJens Grabowski => Gyorgy Rethy
02-12-2011 14:02Gyorgy RethyNote Added: 0010526
02-12-2011 14:02Gyorgy RethyAssigned ToGyorgy Rethy => Jens Grabowski
06-12-2011 10:12Jacob Wieland - SpirentNote Added: 0010531
16-12-2011 05:21Ina SchieferdeckerNote Added: 0010539
16-12-2011 05:22Ina SchieferdeckerTarget VersionEdition 4.4.1 => v4.7.1 (published 2015-06)
11-07-2012 16:21Jens GrabowskiNote Added: 0010843
11-07-2012 16:22Jens GrabowskiAssigned ToJens Grabowski => Gyorgy Rethy
13-07-2012 11:55Gyorgy RethyNote Added: 0010916
13-07-2012 14:43Gyorgy RethyAssigned ToGyorgy Rethy => Jens Grabowski
13-07-2012 15:46Tomas UrbanNote Added: 0010934
16-07-2012 10:35Jacob Wieland - SpirentNote Added: 0010936
16-07-2012 10:50Jacob Wieland - SpirentNote Edited: 0010936
18-01-2013 11:44Jacob Wieland - SpirentRelationship addedrelated to 0006412
08-07-2013 18:20Gyorgy RethyTarget Versionv4.5.1 (published 2013-04) => v4.6.1 (published 2014-06)
09-07-2013 11:35Jacob Wieland - SpirentNote Added: 0011456
11-07-2013 15:21Jacob Wieland - SpirentFile Added: CR5922-v2.doc
11-07-2013 15:22Jacob Wieland - SpirentNote Added: 0011549
11-07-2013 15:22Jacob Wieland - SpirentAssigned ToJens Grabowski => Ina Schieferdecker
11-07-2013 15:22Jacob Wieland - SpirentStatusassigned => confirmed
28-08-2013 14:57Ina SchieferdeckerFile Added: CR5922-v3.doc
28-08-2013 14:57Ina SchieferdeckerNote Added: 0011625
28-08-2013 14:57Ina SchieferdeckerStatusconfirmed => resolved
28-08-2013 14:57Ina SchieferdeckerResolutionopen => fixed
28-08-2013 14:57Ina SchieferdeckerFixed in Version => v4.6.1 (published 2014-06)
28-08-2013 14:57Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010254) +
+ Jacob Wieland - Spirent    +
+ 27-09-2011 16:37    +
+ 		+ + + + +
+ I propose the following solution.
+
+1) disallow parameterized map/unmap for unknown mtc/system-ports.
+2) - allow system clauses also on function/altstep definitions (where system compatibility must be the same as runs on compatibility)
+    - allow mtc clauses (analogously to system clauses) for function/altstep definitions (where mtc compatibility must also be the same as runs on compatibility)
+
+For backward compatibility, it shall still be allowed to call a function/altstep without system/mtc clause from a context with system/mtc clause, as long as the restrictions on the runs on compatiblity are adhered to.
+
+Like for runs-on clauses, it shall not be possible to call a function/altstep with a system/mtc clause from a context without system/mtc clause (respectively).
+
+
+
+ + + + + + + + + + +
+ (0010292) +
+ Gyorgy Rethy    +
+ 29-09-2011 10:50    +
+ 		+ + + + +
+ STF discussion 2011-09-29: proposal is basically agreed; map operation using parameters shall use the system keyword.
+
+
+
+ + + + + + + + + + +
+ (0010299) +
+ Jacob Wieland - Spirent    +
+ 29-09-2011 14:11    +
+ 		+ + + + +
+ uploaded proposal, please review
+
+
+
+ + + + + + + + + + +
+ (0010437) +
+ Gyorgy Rethy    +
+ 30-11-2011 11:16    +
+ 		+ + + + +
+ Jens, pls. review.
+
+
+
+ + + + + + + + + + +
+ (0010498) +
+ Jens Grabowski    +
+ 02-12-2011 09:04    +
+ 		+ + + + +
+ Proposal looks good for me. However, I am not sure about backwards compatability. The additional restrictions may invalid older test suites. György, please have a look at this.
+
+
+
+ + + + + + + + + + +
+ (0010526) +
+ Gyorgy Rethy    +
+ 02-12-2011 14:02    +
+ 		+ + + + +
+ I may be biased by the earlier discussions that the whole mtc and system checking stuff shall be an option to the user. I.e. it shall be able to introduce it with minimal effort into its code and no checking shall be mandatory. From the proposed text only the additional restrictions to the
+16.1.1 Invoking functions
+and
+16.2.1 Invoking altsteps
+clauses seem to be potentially problematic as they can also be understood that these checks are always mandatory (while they are mandatory for the tools only IF any of these clauses present).
+
+I'm, still not quite sure about the practical usability of these additions. They become absolutely useless as soon as the user has two MTC or two TSI types with the same port instance definition(s). In this case he/she cannot use the mtc clause e.g. in activated defaults that will check the messages on that common port instance(s).
+
+
+
+ + + + + + + + + + +
+ (0010531) +
+ Jacob Wieland - Spirent    +
+ 06-12-2011 10:12    +
+ 		+ + + + +
+ I don't understand the objection/doubts. If two component types have the same instance definitions, then they are compatible and so don't pose a problem when checking.
+
+The additional restrictions have been modeled after the existing ones for the runs-on clause so they are consistent with the already existing features and totally backward compatible. If code does not use system/mtc clauses it is as valid as before. Only if the new map-param-statement shall be used do they get any relevance.
+
+In principle, this will only lead to a very meagre number of new system/mtc clauses, i.e. only those functions need it that use these map statements (which are normally called directly from the testcase where mtc and system type are known anyway) need them.
+
+
+
+ + + + + + + + + + +
+ (0010539) +
+ Ina Schieferdecker    +
+ 16-12-2011 05:21    +
+ 		+ + + + +
+ Since resolution is not yet agreed, it is moved to 2012
+
+
+
+ + + + + + + + + + +
+ (0010843) +
+ Jens Grabowski    +
+ 11-07-2012 16:21    +
+ 		+ + + + +
+ György, please check the comments from Jacob.
+
+
+
+ + + + + + + + + + +
+ (0010916) +
+ Gyorgy Rethy    +
+ 13-07-2012 11:55    +
+ 		+ + + + +
+ I think that the proposal is too restrictive. The component type in the mtc and system clauses would be used to check only the port consistency in map operations when mtc nad/or system ports are mapped. But in this case:
+
+1) Why ALL definitions shall be compatible for mtc and system component compatibility? (clause 6.3.3 item 3) and 4)) Why it is not sufficient if port definitions are compatible?
+
+2) Why a function or altstep with an mtc and/or a system clause cannot be called from a function or altstep without mtc or system clause? The feature provided by mtc and system clauses
+- is local to the map operation
+- is totally different from the runs on clause; runs on identifies a component type on which the given function should run. While an mtc clause identifies a "foreign" component, the given function is just references a port of it. In case of system, even no TTCN-3 code is running on TSI. So, trying to compare mtc and system clauses to runs on clauses is the same as comparing apples with avocado: they are simply different things.
+
+So, I don't understand, why the simple example below should be disallowed?:
+
+function f() runs on PTC {// why mtc and system clauses would be needed here, when they are not used to anything?
+ var PTC v_PTC := PTC.create;
+ makeMaps();
+ makeConnections(v_PTC)
+}
+
+function makeMaps() runs on PTC mtc MTC system TSI {
+  map (mtc:P, system:P)//the mtc and system clauses are needed only to check this statement
+}
+
+function makeConnections(PTC p_PTC ) runs on PTC mtc MTC {
+  connect (p_PTC:COORD, mtc:COORD); //the mtc clause is used only to check this statement
+}
+
+From a practical perspective, the restrictive approach is useless, because no user (no Ericsson user) will be able or will want to introduce mtc and system clauses throughout the WHOLE existing code, practically for nothing; while, if mtc and system clauses would be required only at the places, where they are REALLY needed, the feature would be used!
+
+
+
+ + + + + + + + + + +
+ (0010934) +
+ Tomas Urban    +
+ 13-07-2012 15:46    +
+ 		+ + + + +
+ I agree with György. I would prefer if it was still possible to call functions with mtc and system clause from functions that don't contain these clauses. Of course if both caller and callee contain the clauses then compatibility check should be still performed.
+
+
+
+ + + + + + + + + + +
+ (0010936) +
+ Jacob Wieland - Spirent    +
+ 16-07-2012 10:35    +
(edited on: 16-07-2012 10:50)
+ 		+ + + + +
+ What you propose would negate anything to be gained from the new construct, i.e. being able to check statically, whether a map statement will be semantically correct at runtime or not. If a function is called from a context which does not know its system type, then no static analysis can determine if the system type required by the calling function (via system clause) is compatible with the one in the runtime context of the calling one, i.e. if the ports to be mapped to actually exist and have the right attributes.
+
+So, the restrictions I proposed are SPECIFICALLY designed to grant exactly this possibility - to allow static correctness analysis of map statements outside of testcase definitions (i.e. in functions or altsteps).
+
+Also, the scenario that Gyorgy describes Ericsson would be faced with is totally unrealistic. Only those functions that directly or indirectly use a map statement (like the function f() in your example which incidentally DOES use a map statement, albeit indirectly) need to be augmented with the system clause (all others need not be changed at all) - which should be very few.
+The rules are simple. If a function causes a map statement, then it should ensure its correctness. If a function causes a connect statement, then it should ensure its correctness.
+
+In principle, I could live with lessening the restriction - thus yielding a warning during static analysis like today if the system type of the calling function is unknown or cannot be safely determined -, but then for consistency reasons, it should be lessened for the runs on clause as well, as there the same arguments can be used, i.e. that runtime checks are totally sufficient (for some people).
+
+Finally, the argument about the restrictions regarding non-ports is totally academic, as using a full-fledged component type as system type does not make sense (and therefore is a misleading use of a type) as the system has no behaviour that could access its timers/variables/constants (and they cannot be accessed by anyone else either). To alleviate the fears of possible backward incompatibilities of such strange usages, the restrictions between system clauses could, of course, be limited to the port declarations only.
+
+
+
+
+
+ + + + + + + + + + +
+ (0011456) +
+ Jacob Wieland - Spirent    +
+ 09-07-2013 11:35    +
+ 		+ + + + +
+ Shall this be further discussed?
+
+Summing up the concerns:
+- define mtc/system compatibility only regarding to port declarations
+- allow clause-less behavior to call clause-having behavior even though this can lead to runtime errors
+
+For consistency's sake, I would propose to have the same lessing of presence-of-clause-restriction for the runs-on clause as otherwise no user will ever understand why the restriction is (unnecessarily) enforced in one place but not in the others which to them are very much alike.
+
+
+
+ + + + + + + + + + +
+ (0011549) +
+ Jacob Wieland - Spirent    +
+ 11-07-2013 15:22    +
+ 		+ + + + +
+ please check
+
+
+
+ + + + + + + + + + +
+ (0011625) +
+ Ina Schieferdecker    +
+ 28-08-2013 14:57    +
+ 		+ + + + +
+ Implemented with editorial corrections
+
+ + diff --git a/docs/mantis/CR5923.md b/docs/mantis/CR5923.md new file mode 100644 index 0000000000000000000000000000000000000000..7585506f94b7e108f2500f22bfbdee5dc9b22a25 --- /dev/null +++ b/docs/mantis/CR5923.md @@ -0,0 +1,379 @@ + + + + + + + + + + + + + 0005923: BNF (rules 50 and 58) in appendix A and port type definition chapter 6.2.9 do not match - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
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) 
Clause Reference(s)TTCN-3 Edition 4.3.1: Core language
Source (company - Author)Elvior
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}
+                                                        ")"]
Steps To Reproduce
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.
Relationships
related to 0005417closed Ina Schieferdecker Support of parametrized map/unmap operation for full dynamic mapping 
related to 0002105closed Ina Schieferdecker address should also be bind to port type 
related to 0005924closed Ina Schieferdecker What should happen when parameter list is present in port type, but not used in map operation 
related to 0005925closed Ina Schieferdecker in case of global unmap - is param list allowed or not? 
Attached Filesdocx CR5923.docx (19,822) 29-09-2011 11:53
http://oldforge.etsi.org/mantis/file_download.php?file_id=2571&type=bug
docx 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 ModifiedUsernameFieldChange
22-08-2011 15:23Andrus LehtmetsNew Issue
22-08-2011 15:23Andrus LehtmetsClause Reference(s) => TTCN-3 Edition 4.3.1: Core language
22-08-2011 15:23Andrus LehtmetsSource (company - Author) => Elvior
27-09-2011 12:04Gyorgy RethyProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
27-09-2011 12:08Gyorgy RethyAssigned To => Ina Schieferdecker
27-09-2011 12:08Gyorgy RethyStatusnew => assigned
27-09-2011 12:08Gyorgy RethyTarget Version => Edition 4.4.1
28-09-2011 12:37Ina SchieferdeckerNote Added: 0010270
28-09-2011 12:37Ina SchieferdeckerNote Added: 0010271
28-09-2011 12:37Ina SchieferdeckerAssigned ToIna Schieferdecker => Jacob Wieland - Spirent
28-09-2011 12:54Jacob Wieland - SpirentNote Added: 0010273
28-09-2011 12:57Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Ina Schieferdecker
29-09-2011 09:45Ina SchieferdeckerRelationship addedrelated to 0005417
29-09-2011 09:47Ina SchieferdeckerRelationship addedrelated to 0002105
29-09-2011 09:50Ina SchieferdeckerNote Added: 0010289
29-09-2011 11:31Ina SchieferdeckerNote Edited: 0010289
29-09-2011 11:38Jacob Wieland - SpirentNote Added: 0010294
29-09-2011 11:53Ina SchieferdeckerNote Edited: 0010294
29-09-2011 11:53Ina SchieferdeckerFile Added: CR5923.docx
29-09-2011 11:53Ina SchieferdeckerNote Added: 0010295
29-09-2011 11:54Ina SchieferdeckerAssigned ToIna Schieferdecker => Jacob Wieland - Spirent
29-09-2011 12:33Jacob Wieland - SpirentFile Added: CR5923-v2.docx
29-09-2011 12:34Jacob Wieland - SpirentNote Added: 0010297
29-09-2011 12:34Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Ina Schieferdecker
29-09-2011 15:32Jacob Wieland - SpirentRelationship addedrelated to 0005937
29-11-2011 12:54Ina SchieferdeckerNote Added: 0010390
29-11-2011 13:05Ina SchieferdeckerStatusassigned => resolved
29-11-2011 13:05Ina SchieferdeckerResolutionopen => fixed
29-11-2011 13:05Ina SchieferdeckerFixed in Version => Edition 4.4.1
29-11-2011 13:05Ina SchieferdeckerStatusresolved => closed
29-11-2011 15:51Ina SchieferdeckerRelationship addedrelated to 0005966
29-11-2011 15:51Ina SchieferdeckerRelationship deletedrelated to 0005966
29-11-2011 15:52Ina SchieferdeckerRelationship deletedrelated to 0005937
29-11-2011 15:53Ina SchieferdeckerRelationship addedrelated to 0005924
29-11-2011 15:54Ina SchieferdeckerRelationship addedrelated 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
+"
+
+ + diff --git a/docs/mantis/CR5924.md b/docs/mantis/CR5924.md new file mode 100644 index 0000000000000000000000000000000000000000..9e6fde3b2c2d9a163bc228846cacc6c442251be2 --- /dev/null +++ b/docs/mantis/CR5924.md @@ -0,0 +1,212 @@ + + + + + + + + + + + + + 0005924: What should happen when parameter list is present in port type, but not used in map operation - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005924Part 01: TTCN-3 Core LanguageClarificationpublic22-08-2011 15:2630-11-2011 09:42
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) 
Clause Reference(s)TTCN-3 Edition 4.3.1: Core language
Source (company - Author)Elvior
Summary0005924: What should happen when parameter list is present in port type, but not used in map operation
Descriptionwhat should happen when parameter list is present in port type, but not used in map operation:
+- syntactically it is correct not to use parameters,
+Specification should explicitly say if this is allowed or not from semantically point of view.
+
+does following sentense mean that parameters must be present always when declared in port type:
+
+"The actual parameters must conform to the map param clause of the port type declaration of the system port used"
+
+
Steps To Reproduce
Additional InformationIna: parameters in map, we have: “The actual parameters must conform to the map param clause of the port type declaration of the system port used.” which means that parameter list should match the port definition.
+Tomáš Urban: The problem with this rule is that it you can understand it in two ways:
+1. If the port type contains a map parameter declaration, the map call must contain a param clause (i.e. it cannot be omitted) and the actual parameters must be compatible with this definitition.
+2. The map call might contain a param clause, in which case the actual parameters must conform to the map parameter declaration in the parent port type, but since the param clause is optional, it is allowed to skip it. (since the actual parameters are omitted, it is not possible to apply the above mentioned rule).
+Notice that the same problems affects the unmap call. This one of the reasons, why we consider the second explanation more solid, because global unmap calls cannot have parametes in any case (see below). That means that unmapping calls without parameters for ports whose types contain unmap parameter declaration are perfectly legal and it would make sense to allow them even if the TSI port is explicitly referenced.
+
TagsNo tags attached.
Relationships
related to 0005925closed Ina Schieferdecker in case of global unmap - is param list allowed or not? 
related to 0005923closed Ina Schieferdecker BNF (rules 50 and 58) in appendix A and port type definition chapter 6.2.9 do not match 
Attached Filesdoc CR5924-Resolution-JG-111129.doc (96,256) 29-11-2011 11:26
http://oldforge.etsi.org/mantis/file_download.php?file_id=2598&type=bug
Issue History
Date ModifiedUsernameFieldChange
22-08-2011 15:26Andrus LehtmetsNew Issue
22-08-2011 15:26Andrus LehtmetsClause Reference(s) => TTCN-3 Edition 4.3.1: Core language
22-08-2011 15:26Andrus LehtmetsSource (company - Author) => Elvior
27-09-2011 12:00Gyorgy RethyProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
27-09-2011 12:01Gyorgy RethyNote Added: 0010246
27-09-2011 12:01Gyorgy RethyAssigned To => Jens Grabowski
27-09-2011 12:01Gyorgy RethyStatusnew => assigned
27-09-2011 12:01Gyorgy RethyTarget Version => Edition 4.4.1
29-11-2011 11:26Jens GrabowskiFile Added: CR5924-Resolution-JG-111129.doc
29-11-2011 11:28Jens GrabowskiNote Added: 0010384
29-11-2011 11:28Jens GrabowskiAssigned ToJens Grabowski => Jacob Wieland - Spirent
29-11-2011 11:50Jacob Wieland - SpirentNote Added: 0010386
29-11-2011 11:50Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Ina Schieferdecker
29-11-2011 13:55Jens GrabowskiNote Added: 0010395
29-11-2011 15:48Ina SchieferdeckerRelationship addedrelated to 0005925
29-11-2011 15:53Ina SchieferdeckerRelationship addedrelated to 0005923
30-11-2011 09:41Ina SchieferdeckerNote Added: 0010419
30-11-2011 09:41Ina SchieferdeckerStatusassigned => resolved
30-11-2011 09:41Ina SchieferdeckerResolutionopen => fixed
30-11-2011 09:41Ina SchieferdeckerFixed in Version => Edition 4.4.1
30-11-2011 09:42Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010246) +
+ Gyorgy Rethy    +
+ 27-09-2011 12:01    +
+ 		+ + + + +
+ Check possible alternatives and consistency.
+
+
+
+ + + + + + + + + + +
+ (0010384) +
+ Jens Grabowski    +
+ 29-11-2011 11:28    +
+ 		+ + + + +
+ Resolution assumes that param clauses in map operations are optional. Assigned to Jacob for cross checking.
+
+
+
+ + + + + + + + + + +
+ (0010386) +
+ Jacob Wieland - Spirent    +
+ 29-11-2011 11:50    +
+ 		+ + + + +
+ ok.
+
+
+
+ + + + + + + + + + +
+ (0010395) +
+ Jens Grabowski    +
+ 29-11-2011 13:55    +
+ 		+ + + + +
+ The resolution of this CR w.r.t. the unmap function is included in the resolution of CR5925 see file CR5925-Resolution-JW-Rev2-JG.doc.
+
+
+
+ + + + + + + + + + +
+ (0010419) +
+ Ina Schieferdecker    +
+ 30-11-2011 09:41    +
+ 		+ + + + +
+ as proposed.
+
+ + diff --git a/docs/mantis/CR5925.md b/docs/mantis/CR5925.md new file mode 100644 index 0000000000000000000000000000000000000000..823a5dfc46991f9ce94bd4a4bbf9bcb36e5ad82f --- /dev/null +++ b/docs/mantis/CR5925.md @@ -0,0 +1,218 @@ + + + + + + + + + + + + + 0005925: in case of global unmap - is param list allowed or not? - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005925Part 01: TTCN-3 Core LanguageTechnicalpublic22-08-2011 15:3030-11-2011 10:29
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) 
Clause Reference(s)TTCN-3 Edition 4.3.1: Core language
Source (company - Author)Elvior
Summary0005925: in case of global unmap - is param list allowed or not?
Descriptionin case of global unmap - are param list allowed or not
+Ex.
+
+unmap(all component:all port) param (...);
+
+Syntactically it is allowed, but semantically it does not make sense.
+
Steps To Reproduce
Additional InformationIna: parameters in unmap, there is a point as TTCN-3 indeed seems not to be explicit here … I am thinking that both cases for a PortRef make sense, i.e. no parameter list or a matching one.
+
+Tomáš Urban: we agree with that. We also think that the rule "The actual parameters must conform to the unmap param clause of the port type declaration of the system port used" semantically forbids use of the param clause if any of the "all port" construction is used, because there's no system port explicitly used in the clause.
+
+Thus, in order to avoid any possible ambiguity, we would prefer to update the syntax so that the param clause is syntactically allowed only with the first two variants:
+unmap [ ( "(" ComponentRef ":" Port "," ComponentRef ":" Port ")" [ param "(" [ { ActualPar [","] }+ ] ")" ] ) |
+             ( "(" PortRef ")" [ param "(" [ { ActualPar [","] }+ ] ")" ] ) |
+             ( "(" ComponentRef ":" all port ")" ) |
+             ( "(" all component ":" all port ")" ) ]
+
+There's also a problem with the unmap call containing one parameter. If the parameter is not a TSI port, but a mapped test component port, the call doesn't contain an explicit TSI port reference, but it can be found from the list of current mappings. The question is if such an implicit reference satisfies the above mentioned rule. In our opinion, it does not. Thus, we would prefer to add the rule that the param clause can be present only if a system port is explicitly referenced in the unmap call.
+
TagsNo tags attached.
Relationships
related to 0005923closed Ina Schieferdecker BNF (rules 50 and 58) in appendix A and port type definition chapter 6.2.9 do not match 
related to 0005924closed Ina Schieferdecker What should happen when parameter list is present in port type, but not used in map operation 
Attached Filesdoc CR5925-Resolution-JG-111129.doc (196,608) 29-11-2011 10:58
http://oldforge.etsi.org/mantis/file_download.php?file_id=2594&type=bug
doc CR5925-Resolution-JW.doc (116,224) 29-11-2011 11:34
http://oldforge.etsi.org/mantis/file_download.php?file_id=2599&type=bug
doc CR5925-Resolution-JW-Rev2-JG.doc (146,944) 29-11-2011 13:51
http://oldforge.etsi.org/mantis/file_download.php?file_id=2604&type=bug
doc CR5925-Resolution-JW-Rev2-JG-3.doc (134,144) 30-11-2011 10:17
http://oldforge.etsi.org/mantis/file_download.php?file_id=2616&type=bug
Issue History
Date ModifiedUsernameFieldChange
22-08-2011 15:30Andrus LehtmetsNew Issue
22-08-2011 15:30Andrus LehtmetsClause Reference(s) => TTCN-3 Edition 4.3.1: Core language
22-08-2011 15:30Andrus LehtmetsSource (company - Author) => Elvior
27-09-2011 11:55Gyorgy RethyNote Added: 0010245
27-09-2011 11:55Gyorgy RethyAssigned To => Jens Grabowski
27-09-2011 11:55Gyorgy RethyStatusnew => assigned
27-09-2011 11:55Gyorgy RethyProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
27-09-2011 13:28Gyorgy RethyTarget Version => Edition 4.4.1
29-11-2011 10:58Jens GrabowskiFile Added: CR5925-Resolution-JG-111129.doc
29-11-2011 10:59Jens GrabowskiNote Added: 0010380
29-11-2011 11:00Jens GrabowskiAssigned ToJens Grabowski => Jacob Wieland - Spirent
29-11-2011 11:34Jacob Wieland - SpirentFile Added: CR5925-Resolution-JW.doc
29-11-2011 11:35Jacob Wieland - SpirentNote Added: 0010385
29-11-2011 11:46Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Ina Schieferdecker
29-11-2011 13:51Jens GrabowskiFile Added: CR5925-Resolution-JW-Rev2-JG.doc
29-11-2011 13:53Jens GrabowskiNote Added: 0010394
29-11-2011 15:48Ina SchieferdeckerRelationship addedrelated to 0005924
29-11-2011 15:54Ina SchieferdeckerRelationship addedrelated to 0005923
30-11-2011 10:17Ina SchieferdeckerNote Added: 0010423
30-11-2011 10:17Ina SchieferdeckerFile Added: CR5925-Resolution-JW-Rev2-JG-3.doc
30-11-2011 10:29Ina SchieferdeckerStatusassigned => resolved
30-11-2011 10:29Ina SchieferdeckerResolutionopen => fixed
30-11-2011 10:29Ina SchieferdeckerFixed in Version => Edition 4.4.1
30-11-2011 10:29Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010245) +
+ Gyorgy Rethy    +
+ 27-09-2011 11:55    +
+ 		+ + + + +
+ To be analysed.
+
+
+
+ + + + + + + + + + +
+ (0010380) +
+ Jens Grabowski    +
+ 29-11-2011 10:59    +
+ 		+ + + + +
+ Resolution proposal follows the proposal in the Additional Information description. Assigned to Jacob for cross checking.
+
+
+
+ + + + + + + + + + +
+ (0010385) +
+ Jacob Wieland - Spirent    +
+ 29-11-2011 11:35    +
+ 		+ + + + +
+ removed typo
+
+deleted unused (inlined) BNF rule, replaced by new rule ParamClause which is used for both map and unmap (to avoid repetition)
+
+
+
+ + + + + + + + + + +
+ (0010394) +
+ Jens Grabowski    +
+ 29-11-2011 13:53    +
+ 		+ + + + +
+ The file CR5925-Resolution-JW-Rev2-JG.doc includes restrictions related to CR5924.
+
+
+
+ + + + + + + + + + +
+ (0010423) +
+ Ina Schieferdecker    +
+ 30-11-2011 10:17    +
+ 		+ + + + +
+ implemented with small correction in the BNF
+
+ + diff --git a/docs/mantis/CR5926.md b/docs/mantis/CR5926.md new file mode 100644 index 0000000000000000000000000000000000000000..b441bc889455f566d2c0c332fb91b336ddf8cebf --- /dev/null +++ b/docs/mantis/CR5926.md @@ -0,0 +1,86 @@ + + + + + + + + + + + + + 0005926: Several errors in examples - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005926Part 09: Using XML with TTCN-3Editorialpublic29-08-2011 16:4227-09-2011 16:06
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PriorityhighSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.4.1 (published 2012-04)Fixed in Versionv4.4.1 (published 2012-04) 
Clause Reference(s)7.1.4
For STF discussion
Source (company - Author)L.M.Ericsson
Summary0005926: Several errors in examples
Description1)
+<complexType name="e15a"> should result TTCN-3 type name E15a, not E15.
+
+2)
+<complexType name="e15c">
+  <sequence>
+    ...
+  <sequence> should be </sequence>
+
+3)
+<complexType name="e15f">
+  <sequence>
+    <element name="comment" minOccurs="0" maxOccurs="unbounded" type="xsd:string"/> should be "string", without a name prefix
+<sequence> should be </sequence> kell
+
+4)
+<element name="minOccurs_maxOccurs_frame">
+    <xs:complexType>
+        <xs:choice minOccurs="0" maxOccurs="unbounded">
+            <element ref="ns:ChoiceChildMinMax"/>
+        </xs:choice>
+    </xs:complexType>
+</element>
+3* element should be with prefix xs:
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
29-08-2011 16:42Gyorgy RethyNew Issue
29-08-2011 16:42Gyorgy RethyClause Reference(s) => 7.1.4
29-08-2011 16:42Gyorgy RethySource (company - Author) => L.M.Ericsson
27-09-2011 12:04Gyorgy RethyAssigned To => Gyorgy Rethy
27-09-2011 12:04Gyorgy RethyStatusnew => assigned
27-09-2011 12:04Gyorgy RethyTarget Version => Edition 4.4.1
27-09-2011 16:06Gyorgy RethyNote Added: 0010251
27-09-2011 16:06Gyorgy RethyPrioritynormal => high
27-09-2011 16:06Gyorgy RethyStatusassigned => closed
27-09-2011 16:06Gyorgy RethyResolutionopen => fixed
27-09-2011 16:06Gyorgy RethyFixed in Version => Edition 4.4.1
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010251) +
+ Gyorgy Rethy    +
+ 27-09-2011 16:06    +
+ 		+ + + + +
+ Corrected in master copy.
+
+ + diff --git a/docs/mantis/CR5927.md b/docs/mantis/CR5927.md new file mode 100644 index 0000000000000000000000000000000000000000..7f43143c7975018b8af7794bcc6649064a9ac546 --- /dev/null +++ b/docs/mantis/CR5927.md @@ -0,0 +1,102 @@ + + + + + + + + + + + + + 0005927: Unify restriction c) for altsteps and for functions - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005927Part 01: TTCN-3 Core LanguageEditorialpublic01-09-2011 16:5929-11-2011 15:05
ReporterGyorgy Rethy 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.4.1 (published 2012-04)Fixed in Versionv4.4.1 (published 2012-04) 
Clause Reference(s)16.1
Source (company - Author)L.M.Ericsson
Summary0005927: Unify restriction c) for altsteps and for functions
DescriptionRestriction c) in clause 16.2 says:
+"c) c) If an altstep includes port operations or uses component variables, constants or timers ... The one exception to this rule...".
+
+This text is also included in clause 16.1 but in the Semantic description part of the clause and not as a Restriction.
+
+It is proposed to move these two sentences to the Restrictions in clause 16.1 to make it more visible, stronger and to unifying it with clause 16.2.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR5927_resolution.doc (91,136) 28-09-2011 12:33
http://oldforge.etsi.org/mantis/file_download.php?file_id=2567&type=bug
Issue History
Date ModifiedUsernameFieldChange
01-09-2011 16:59Gyorgy RethyNew Issue
01-09-2011 16:59Gyorgy RethyClause Reference(s) => 16.1
01-09-2011 16:59Gyorgy RethySource (company - Author) => L.M.Ericsson
27-09-2011 12:03Gyorgy RethyAssigned To => Jacob Wieland - Spirent
27-09-2011 12:03Gyorgy RethyStatusnew => assigned
27-09-2011 12:03Gyorgy RethyTarget Version => Edition 4.4.1
28-09-2011 12:33Jacob Wieland - SpirentFile Added: CR5927_resolution.doc
28-09-2011 12:33Jacob Wieland - SpirentNote Added: 0010268
28-09-2011 12:36Gyorgy RethyProjectPart 09: Using XML with TTCN-3 => Part 01: TTCN-3 Core Language
28-09-2011 12:37Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Ina Schieferdecker
29-11-2011 15:04Ina SchieferdeckerNote Added: 0010403
29-11-2011 15:04Ina SchieferdeckerStatusassigned => resolved
29-11-2011 15:04Ina SchieferdeckerResolutionopen => fixed
29-11-2011 15:04Ina SchieferdeckerFixed in Version => Edition 4.4.1
29-11-2011 15:05Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010268) +
+ Jacob Wieland - Spirent    +
+ 28-09-2011 12:33    +
+ 		+ + + + +
+ moved the sentences to a new restriction, please review
+
+
+
+ + + + + + + + + + +
+ (0010403) +
+ Ina Schieferdecker    +
+ 29-11-2011 15:04    +
+ 		+ + + + +
+ as proposed.
+
+ + diff --git a/docs/mantis/CR5928.md b/docs/mantis/CR5928.md new file mode 100644 index 0000000000000000000000000000000000000000..da3c6d2941b36cea50af028697a421a05d059b68 --- /dev/null +++ b/docs/mantis/CR5928.md @@ -0,0 +1,182 @@ + + + + + + + + + + + + + 0005928: ETSI ES 201 873-1 6.2 example 5: syntactically incorrect - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005928Part 01: TTCN-3 Core LanguageTechnicalpublic06-09-2011 12:4330-11-2011 09:24
ReporterAndrus Lehtmets 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.4.1 (published 2012-04)Fixed in Versionv4.4.1 (published 2012-04) 
Clause Reference(s)ETSI ES 201 873-1 (4.3.2 CL)
Source (company - Author)Elvior
Summary0005928: ETSI ES 201 873-1 6.2 example 5: syntactically incorrect
DescriptionETSI ES 201 873-1 6.2 example 5: syntactically incorrect, var statements cannot have a with clause; var should be replaced with const.
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0005966closed Gyorgy Rethy Invalid syntax in 6.2 example 5 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
06-09-2011 12:43Andrus LehtmetsNew Issue
06-09-2011 12:43Andrus LehtmetsClause Reference(s) => ETSI ES 201 873-1 (4.3.2 CL)
06-09-2011 12:43Andrus LehtmetsSource (company - Author) => Elvior
27-09-2011 11:23Gyorgy RethyNote Added: 0010238
27-09-2011 11:23Gyorgy RethyAssigned To => Ina Schieferdecker
27-09-2011 11:23Gyorgy RethyStatusnew => assigned
27-09-2011 12:30Gyorgy RethyProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
27-09-2011 13:31Gyorgy RethyTarget Version => Edition 4.4.1
28-09-2011 12:25Ina SchieferdeckerNote Added: 0010265
28-09-2011 12:25Ina SchieferdeckerAssigned ToIna Schieferdecker => Gyorgy Rethy
28-09-2011 15:11Gyorgy RethyNote Added: 0010282
28-09-2011 15:12Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
28-09-2011 15:12Gyorgy RethyStatusassigned => resolved
28-09-2011 15:12Gyorgy RethyResolutionopen => fixed
30-11-2011 09:18Ina SchieferdeckerRelationship addedrelated to 0005966
30-11-2011 09:24Ina SchieferdeckerNote Added: 0010414
30-11-2011 09:24Ina SchieferdeckerStatusresolved => closed
30-11-2011 09:24Ina SchieferdeckerFixed in Version => Edition 4.4.1
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010238) +
+ Gyorgy Rethy    +
+ 27-09-2011 11:23    +
+ 		+ + + + +
+ Comment is correct, include vars into a component type and move the attribute to the component type.
+
+
+
+ + + + + + + + + + +
+ (0010265) +
+ Ina Schieferdecker    +
+ 28-09-2011 12:25    +
+ 		+ + + + +
+ I suggest to have the with attribute in the type definition:
+
+    type record R {
+        integer f1,
+        integer f2 optional,
+        integer f3,
+        integer f4 optional,
+        integer f5 optional
+    } with { optional "implicit omit" }
+
+    var R x := { 1, -, 2 }
+         // after the assignment x contains { 1, omit, 2, omit, omit }
+    var R x2 := { 1, 2 }
+         // after the assignment x2 contains { 1, 2, <undefined>, omit, omit }
+
+
+Please check.
+
+
+
+ + + + + + + + + + +
+ (0010282) +
+ Gyorgy Rethy    +
+ 28-09-2011 15:11    +
+ 		+ + + + +
+ Yes, correct.
+
+
+
+ + + + + + + + + + +
+ (0010414) +
+ Ina Schieferdecker    +
+ 30-11-2011 09:24    +
+ 		+ + + + +
+ Resolved by allowing with for local definitions - see CR5966
+
+ + diff --git a/docs/mantis/CR5929.md b/docs/mantis/CR5929.md new file mode 100644 index 0000000000000000000000000000000000000000..a710cc39895901cf67c9b067ca050dbeb1669cf8 --- /dev/null +++ b/docs/mantis/CR5929.md @@ -0,0 +1,355 @@ + + + + + + + + + + + + + 0005929: Compatibility between record and record of, record and array, set and set of. - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005929Part 01: TTCN-3 Core LanguageClarificationpublic06-09-2011 12:4630-11-2011 09:37
ReporterAndrus Lehtmets 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.4.1 (published 2012-04)Fixed in Versionv4.4.1 (published 2012-04) 
Clause Reference(s)ETSI ES 201 873-1 (4.3.2 CL)
Source (company - Author)Elvior
Summary0005929: Compatibility between record and record of, record and array, set and set of.
DescriptionETSI ES 201 873-1 6.3.2.1 removes the compatibility between record and record of, record and array, set and set of. However, the first paragraph of 6.3.2 still mentions this compatibility. It should be rephrased in the following way: "... Enumerated values are not compatible with any other type; records may be compatible with other record types; record of and array values may be compatible with other record of and array types; sets may be compatible with other set types; set of values may be compatible with other set of types; union values may be compatible with other union types; and anytype values may be compatible with other anytype types. ..."
+
+Although arrays are in general handled in the same way as record of types (if not explicitly specified otherwise, see the rule for root type in 3.1), it would increase document readability if arrays are explicitly mentioned in the following rules:
+
+ETSI ES 201 873-1 15.6.3: The first paragraph could contain a note that array templates are handled in the same way as record of templates
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
06-09-2011 12:46Andrus LehtmetsNew Issue
06-09-2011 12:46Andrus LehtmetsClause Reference(s) => ETSI ES 201 873-1 (4.3.2 CL)
06-09-2011 12:46Andrus LehtmetsSource (company - Author) => Elvior
27-09-2011 11:42Gyorgy RethyProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
27-09-2011 11:44Gyorgy RethyNote Added: 0010243
27-09-2011 11:44Gyorgy RethyAssigned To => Ina Schieferdecker
27-09-2011 11:44Gyorgy RethyStatusnew => assigned
27-09-2011 11:44Gyorgy RethyTarget Version => Edition 4.4.1
27-09-2011 11:45Gyorgy RethyNote Added: 0010244
27-09-2011 16:43Ina SchieferdeckerNote Added: 0010255
27-09-2011 17:36Ina SchieferdeckerNote Added: 0010256
27-09-2011 17:36Ina SchieferdeckerNote Added: 0010257
27-09-2011 17:36Ina SchieferdeckerAssigned ToIna Schieferdecker => Gyorgy Rethy
28-09-2011 15:08Gyorgy RethyNote Added: 0010278
28-09-2011 15:08Gyorgy RethyNote Added: 0010279
28-09-2011 15:08Gyorgy RethyNote Added: 0010280
28-09-2011 15:08Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
28-09-2011 15:11Ina SchieferdeckerNote Added: 0010281
28-09-2011 15:12Ina SchieferdeckerNote Deleted: 0010279
28-09-2011 15:12Ina SchieferdeckerNote Deleted: 0010280
28-11-2011 13:10Gyorgy RethyNote Added: 0010345
28-11-2011 13:10Gyorgy RethyStatusassigned => resolved
30-11-2011 09:36Ina SchieferdeckerNote Added: 0010418
30-11-2011 09:37Ina SchieferdeckerStatusresolved => closed
30-11-2011 09:37Ina SchieferdeckerResolutionopen => fixed
30-11-2011 09:37Ina SchieferdeckerFixed in Version => Edition 4.4.1
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010243) +
+ Gyorgy Rethy    +
+ 27-09-2011 11:44    +
+ 		+ + + + +
+ Remove all sentences except the first and last.
+
+
+
+ + + + + + + + + + +
+ (0010244) +
+ Gyorgy Rethy    +
+ 27-09-2011 11:45    +
+ 		+ + + + +
+ Remove all sentences except the first and last.
+
+
+
+ + + + + + + + + + +
+ (0010255) +
+ Ina Schieferdecker    +
+ 27-09-2011 16:43    +
+ 		+ + + + +
+ Changed
+
+"This clause defines compatibility rules for structured types. Enumerated values are not compatible with any other type; record, record ofs and array values may be compatible with other record, record ofs type and arrays; sets and set of values may be compatible with other set and set of types; union values may be compatible with other union types; and anytype values may be compatible with other anytype types. No other type compatibilities for structured types exist. In subsequent clauses, "value "b"" is called the value to be assigned, e.g. when passed as parameter, to an object of type "A"."
+
+to
+
+"This clause defines compatibility rules for structured types. In subsequent clauses, "value "b"" is called the value to be assigned, e.g. when passed as parameter, to an object of type "A"."
+
+
+
+ + + + + + + + + + +
+ (0010256) +
+ Ina Schieferdecker    +
+ 27-09-2011 17:36    +
+ 		+ + + + +
+ Instead of adding a note to 15.6.3, I propose to change as follows.
+
+From
+
+"Both templates and template variables allow referencing elements of a record of or set of template or field using the index notation."
+
+to
+
+"Both templates and template variables allow referencing elements of a record of, array or set of template or field using the index notation."
+
+
+
+ + + + + + + + + + +
+ (0010257) +
+ Ina Schieferdecker    +
+ 27-09-2011 17:36    +
+ 		+ + + + +
+ Please check
+
+
+
+ + + + + + + + + + +
+ (0010278) +
+ Gyorgy Rethy    +
+ 28-09-2011 15:08    +
+ 		+ + + + +
+ Cannot see a file attached.
+
+
+
+ + + + + + + + + + +
+ (0010281) +
+ Ina Schieferdecker    +
+ 28-09-2011 15:11    +
+ 		+ + + + +
+ There is no file attached ... please see my proposal in the note.
+
+Thanks, Ina
+
+
+
+ + + + + + + + + + +
+ (0010345) +
+ Gyorgy Rethy    +
+ 28-11-2011 13:10    +
+ 		+ + + + +
+ OK.
+
+
+
+ + + + + + + + + + +
+ (0010418) +
+ Ina Schieferdecker    +
+ 30-11-2011 09:36    +
+ 		+ + + + +
+ as proposed.
+
+ + diff --git a/docs/mantis/CR5930.md b/docs/mantis/CR5930.md new file mode 100644 index 0000000000000000000000000000000000000000..1f6527a858a69098d894bd76bb5c5b258163e8ef --- /dev/null +++ b/docs/mantis/CR5930.md @@ -0,0 +1,166 @@ + + + + + + + + + + + + + 0005930: Textual rules for permutation inside arrays. - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005930Part 01: TTCN-3 Core LanguageClarificationpublic06-09-2011 12:4811-07-2012 11:09
ReporterAndrus Lehtmets 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.5.1 (published 2013-04)Fixed in Versionv4.5.1 (published 2013-04) 
Clause Reference(s)ETSI ES 201 873-1 (4.3.2 CL)
Source (company - Author) Elvior
Summary0005930: Textual rules for permutation inside arrays.
DescriptionETSI ES 201 873-1 B.1.3.3: Table 11 states that permutation is allowed inside arrays making permutation efficiently available for arrays. The textual rules for permutation should mention this possibility as well.
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR5930.docx (20,066) 29-11-2011 17:19
http://oldforge.etsi.org/mantis/file_download.php?file_id=2610&type=bug
Issue History
Date ModifiedUsernameFieldChange
06-09-2011 12:48Andrus LehtmetsNew Issue
06-09-2011 12:48Andrus LehtmetsClause Reference(s) => ETSI ES 201 873-1 (4.3.2 CL)
06-09-2011 12:48Andrus LehtmetsSource (company - Author) => Elvior
27-09-2011 11:19Gyorgy RethyNote Added: 0010237
27-09-2011 11:19Gyorgy RethyAssigned To => Ina Schieferdecker
27-09-2011 11:19Gyorgy RethyStatusnew => assigned
27-09-2011 11:19Gyorgy RethyProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
27-09-2011 13:31Gyorgy RethyTarget Version => Edition 4.4.1
29-11-2011 17:19Ina SchieferdeckerFile Added: CR5930.docx
29-11-2011 17:19Ina SchieferdeckerNote Added: 0010405
29-11-2011 17:19Ina SchieferdeckerAssigned ToIna Schieferdecker => Gyorgy Rethy
30-11-2011 13:11Gyorgy RethyNote Added: 0010444
30-11-2011 13:12Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
30-11-2011 13:12Gyorgy RethyStatusassigned => resolved
09-07-2012 17:17Ina SchieferdeckerTarget VersionEdition 4.4.1 => Edition 4.5.1
11-07-2012 11:09Ina SchieferdeckerNote Added: 0010826
11-07-2012 11:09Ina SchieferdeckerStatusresolved => closed
11-07-2012 11:09Ina SchieferdeckerResolutionopen => fixed
11-07-2012 11:09Ina SchieferdeckerFixed in Version => Edition 4.5.1
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010237) +
+ Gyorgy Rethy    +
+ 27-09-2011 11:19    +
+ 		+ + + + +
+ Comment is correct.
+
+
+
+ + + + + + + + + + +
+ (0010405) +
+ Ina Schieferdecker    +
+ 29-11-2011 17:19    +
+ 		+ + + + +
+ See uploaded resolution - please check.
+
+
+
+ + + + + + + + + + +
+ (0010444) +
+ Gyorgy Rethy    +
+ 30-11-2011 13:11    +
+ 		+ + + + +
+ OK. Some spaces before "or array" and in Example 2 are missing.
+
+
+
+ + + + + + + + + + +
+ (0010826) +
+ Ina Schieferdecker    +
+ 11-07-2012 11:09    +
+ 		+ + + + +
+ Implemented as proposed.
+
+ + diff --git a/docs/mantis/CR5934.md b/docs/mantis/CR5934.md new file mode 100644 index 0000000000000000000000000000000000000000..ce7be2a682e6e9e6300429552530314a14b33dd9 --- /dev/null +++ b/docs/mantis/CR5934.md @@ -0,0 +1,286 @@ + + + + + + + + + + + + + 0005934: Unhandled case in the v4.3.2 version of the ispresent function - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005934Part 01: TTCN-3 Core LanguageTechnicalpublic15-09-2011 16:3711-07-2012 10:40
ReporterGyorgy Rethy 
Assigned ToIna Schieferdecker 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.5.1 (published 2013-04)Fixed in Versionv4.5.1 (published 2013-04) 
Clause Reference(s)C.31
Source (company - Author)L.M.Ericsson
Summary0005934: Unhandled case in the v4.3.2 version of the ispresent function
DescriptionSee the following example:
+
+type record r { boolean b }
+type union u { boolen b }
+
+var template r vr := ?;
+var template u vu := ?;
+var template boolean vb;
+
+vb := vr.b ; //vr.b equals to AnyValue due to the record expansion
+             //rules in $15.6.2
+vb := vu.b; // causes an error, as vu.b doesn't exist
+ispresent(vr.b) //returns true
+ispresent(vu.b) //what shall be the result of this function call?
+
+As the existence of vu.b can be checked by either isbound or ischosen, it is proposed that in the above case ispresent(vu.b); should cause an error.
+
+The text of $C.31 should be amended accordingly.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR5934-Resolution-JG-110929.doc (93,696) 29-09-2011 14:31
http://oldforge.etsi.org/mantis/file_download.php?file_id=2575&type=bug
doc CR5934.doc (39,936) 30-11-2011 16:33
http://oldforge.etsi.org/mantis/file_download.php?file_id=2624&type=bug
doc CR5934_v2.doc (54,272) 11-07-2012 10:36
http://oldforge.etsi.org/mantis/file_download.php?file_id=2664&type=bug
Issue History
Date ModifiedUsernameFieldChange
15-09-2011 16:37Gyorgy RethyNew Issue
15-09-2011 16:37Gyorgy RethyClause Reference(s) => C.31
15-09-2011 16:37Gyorgy RethySource (company - Author) => L.M.Ericsson
27-09-2011 11:06Gyorgy RethyNote Added: 0010236
27-09-2011 11:07Gyorgy RethyNote Edited: 0010236
27-09-2011 11:08Gyorgy RethyAssigned To => Jacob Wieland - Spirent
27-09-2011 11:08Gyorgy RethyStatusnew => assigned
27-09-2011 11:08Gyorgy RethyTarget Version => Edition 4.4.1
27-09-2011 11:15Gyorgy RethyNote Edited: 0010236
27-09-2011 11:47Gyorgy RethyAssigned ToJacob Wieland - Spirent => Jens Grabowski
29-09-2011 09:32Ina SchieferdeckerRelationship addedrelated to 0005936
29-09-2011 09:42Ina SchieferdeckerStatusassigned => closed
29-09-2011 09:43Ina SchieferdeckerResolutionopen => fixed
29-09-2011 09:43Ina SchieferdeckerFixed in Version => Edition 4.4.1
29-09-2011 14:31Jens GrabowskiFile Added: CR5934-Resolution-JG-110929.doc
29-09-2011 14:40Gyorgy RethyAssigned ToJens Grabowski => Gyorgy Rethy
29-09-2011 14:40Gyorgy RethyStatusclosed => feedback
29-09-2011 14:40Gyorgy RethyResolutionfixed => reopened
29-09-2011 14:40Gyorgy RethyRelationship deletedrelated to 0005936
29-09-2011 14:41Gyorgy RethyStatusfeedback => assigned
30-09-2011 10:51Gyorgy RethyNote Added: 0010307
30-11-2011 13:18Gyorgy RethyNote Added: 0010445
30-11-2011 13:18Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
30-11-2011 14:56Gyorgy RethyAssigned ToIna Schieferdecker => Jacob Wieland - Spirent
30-11-2011 14:57Gyorgy RethyNote Added: 0010447
30-11-2011 16:23Jacob Wieland - SpirentFile Added: CR5934.doc
30-11-2011 16:25Jacob Wieland - SpirentFile Deleted: CR5934.doc
30-11-2011 16:33Jacob Wieland - SpirentFile Added: CR5934.doc
30-11-2011 16:34Jacob Wieland - SpirentNote Added: 0010451
30-11-2011 16:34Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
02-12-2011 09:42Gyorgy RethyNote Added: 0010502
02-12-2011 09:42Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
02-12-2011 09:42Gyorgy RethyStatusassigned => resolved
02-12-2011 09:42Gyorgy RethyResolutionreopened => fixed
09-07-2012 17:16Ina SchieferdeckerFixed in VersionEdition 4.4.1 =>
09-07-2012 17:16Ina SchieferdeckerTarget VersionEdition 4.4.1 => Edition 4.5.1
11-07-2012 10:36Ina SchieferdeckerFile Added: CR5934_v2.doc
11-07-2012 10:40Ina SchieferdeckerNote Added: 0010813
11-07-2012 10:40Ina SchieferdeckerStatusresolved => closed
11-07-2012 10:40Ina SchieferdeckerFixed in Version => Edition 4.5.1
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010236) +
+ Gyorgy Rethy    +
+ 27-09-2011 11:06    +
(edited on: 27-09-2011 11:15)
+ 		+ + + + +
+ This case shall return false, because of the extended definition of ispresent. Current text is OK, but need to be merged with ischosen. ischosen should be deprecated as become superflouos.
+
+
+
+
+
+ + + + + + + + + + +
+ (0010307) +
+ Gyorgy Rethy    +
+ 30-09-2011 10:51    +
+ 		+ + + + +
+ For the first quick review it is OK. However, I would like to consider all possible variations...
+
+
+
+ + + + + + + + + + +
+ (0010445) +
+ Gyorgy Rethy    +
+ 30-11-2011 13:18    +
+ 		+ + + + +
+ To be discussed in the STF for final agreement. If the principle of replacing ischosen by ispresent accepted, the text in CR5934-Resolution-JG-110929.doc is OK.
+
+
+
+ + + + + + + + + + +
+ (0010447) +
+ Gyorgy Rethy    +
+ 30-11-2011 14:57    +
+ 		+ + + + +
+ STF discussion 30-11-2011: ispresent shall not be used for union fields. State this in the text.
+
+
+
+ + + + + + + + + + +
+ (0010451) +
+ Jacob Wieland - Spirent    +
+ 30-11-2011 16:34    +
+ 		+ + + + +
+ please review
+
+
+
+ + + + + + + + + + +
+ (0010502) +
+ Gyorgy Rethy    +
+ 02-12-2011 09:42    +
+ 		+ + + + +
+ Fine with me.
+
+
+
+ + + + + + + + + + +
+ (0010813) +
+ Ina Schieferdecker    +
+ 11-07-2012 10:40    +
+ 		+ + + + +
+ Implemented as in v2
+
+ + diff --git a/docs/mantis/CR5935.md b/docs/mantis/CR5935.md new file mode 100644 index 0000000000000000000000000000000000000000..6fae4438512c679f5fd1265822d2d5ee7dea57e9 --- /dev/null +++ b/docs/mantis/CR5935.md @@ -0,0 +1,412 @@ + + + + + + + + + + + + + 0005935: wrong BNF production - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005935Part 01: TTCN-3 Core LanguageEditorialpublic21-09-2011 09:0630-11-2011 09:13
ReporterUwe Truetsch 
Assigned ToIna Schieferdecker 
PrioritynormalSeveritymajorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.3.1 (published 2011-06) 
Target Versionv4.4.1 (published 2012-04)Fixed in Versionv4.4.1 (published 2012-04) 
Clause Reference(s)A.1.6.8.1 With statement
Source (company - Author)NSN - Uwe Truetsch
Summary0005935: wrong BNF production
Descriptionthere is a missing '|' in between 'Identifier' and 'FullGroupIdentifier' of production 455
+
+is:
+
+455.DefinitionRef ::= Identifier FullGroupIdentifier
+
+should be:
+
+455.DefinitionRef ::= Identifier | FullGroupIdentifier
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR5935.docx (19,454) 29-11-2011 14:43
http://oldforge.etsi.org/mantis/file_download.php?file_id=2605&type=bug
docx CR5935_v2.docx (28,347) 30-11-2011 09:12
http://oldforge.etsi.org/mantis/file_download.php?file_id=2614&type=bug
Issue History
Date ModifiedUsernameFieldChange
21-09-2011 09:06Uwe TruetschNew Issue
21-09-2011 09:06Uwe TruetschClause Reference(s) => A.1.6.8.1 With statement
21-09-2011 09:06Uwe TruetschSource (company - Author) => NSN - Uwe Truetsch
27-09-2011 10:55Gyorgy RethyAssigned To => Ina Schieferdecker
27-09-2011 10:55Gyorgy RethyStatusnew => assigned
27-09-2011 13:30Gyorgy RethyTarget Version => Edition 4.4.1
28-09-2011 11:22Ina SchieferdeckerNote Added: 0010261
28-09-2011 11:23Ina SchieferdeckerNote Added: 0010262
28-09-2011 11:23Ina SchieferdeckerAssigned ToIna Schieferdecker => Jacob Wieland - Spirent
28-09-2011 11:46Jacob Wieland - SpirentNote Added: 0010263
28-09-2011 12:14Ina SchieferdeckerNote Added: 0010264
28-09-2011 13:08Jacob Wieland - SpirentNote Added: 0010275
28-09-2011 13:09Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Ina Schieferdecker
28-09-2011 16:27Ina SchieferdeckerNote Added: 0010284
29-09-2011 11:12Ina SchieferdeckerNote Added: 0010293
29-11-2011 14:42Ina SchieferdeckerNote Added: 0010401
29-11-2011 14:43Ina SchieferdeckerFile Added: CR5935.docx
29-11-2011 14:43Ina SchieferdeckerAssigned ToIna Schieferdecker => Jacob Wieland - Spirent
29-11-2011 18:21Jacob Wieland - SpirentNote Added: 0010407
29-11-2011 18:23Jacob Wieland - SpirentNote Edited: 0010407
29-11-2011 18:26Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Ina Schieferdecker
30-11-2011 07:22Ina SchieferdeckerNote Added: 0010410
30-11-2011 09:12Ina SchieferdeckerFile Added: CR5935_v2.docx
30-11-2011 09:13Ina SchieferdeckerStatusassigned => resolved
30-11-2011 09:13Ina SchieferdeckerResolutionopen => fixed
30-11-2011 09:13Ina SchieferdeckerFixed in Version => Edition 4.4.1
30-11-2011 09:13Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010261) +
+ Ina Schieferdecker    +
+ 28-09-2011 11:22    +
+ 		+ + + + +
+ FullGroupIdentifier is defined as follows
+
+216. FullGroupIdentifier ::= Identifier {Dot Identifier}
+ 
+
+Hence, it is enough to define
+
+462. DefinitionRef ::= FullGroupIdentifier
+
+
+Since, DefinitionRef is used only in DefOrFieldRef this brings us to
+
+461. DefOrFieldRef ::= FullGroupIdentifier |
+                        ( ( FieldReference | "[" Minus "]" ) [ ExtendedFieldReference ] ) |
+                          AllRef
+
+
+
+ + + + + + + + + + +
+ (0010262) +
+ Ina Schieferdecker    +
+ 28-09-2011 11:23    +
+ 		+ + + + +
+ Please check
+
+
+
+ + + + + + + + + + +
+ (0010263) +
+ Jacob Wieland - Spirent    +
+ 28-09-2011 11:46    +
+ 		+ + + + +
+ grammatically, you are correct, but I think the intended semantics of FullGroupIdentifier should not be left unconsidered. It normally stands for a reference of a (possibly nested) group with its fully qualified path-name. As the grammar is written with semantics in mind (to make it more understandable) and not with a parsing algorithm, I would change it as follows:
+
+FullGroupIdentifier ::= DottedIdentifier
+
+DottedIdentifier ::= Identifier {Dot Identifier}
+
+DefinitionRef ::= DottedIdentifier
+
+Of course, if DefinitionRef is used only in DefOrFieldRef, then this could be rewritten as:
+
+DefOrFieldRef ::= DottedIdentifier |
+                  ( ( FieldReference | "[" Minus "]" ) [ ExtendedFieldReference ] ) |
+                  AllRef
+
+
+
+ + + + + + + + + + +
+ (0010264) +
+ Ina Schieferdecker    +
+ 28-09-2011 12:14    +
+ 		+ + + + +
+ Let us discuss ... we wanted also to simplify the syntax ...
+
+
+
+ + + + + + + + + + +
+ (0010275) +
+ Jacob Wieland - Spirent    +
+ 28-09-2011 13:08    +
+ 		+ + + + +
+ Another solution would be to rename FullGroupIdentifier to DottedIdentifier to get rid of the semantic reference.
+
+
+
+ + + + + + + + + + +
+ (0010284) +
+ Ina Schieferdecker    +
+ 28-09-2011 16:27    +
+ 		+ + + + +
+ Or even OptionallyDottedIdentifier
+
+
+
+ + + + + + + + + + +
+ (0010293) +
+ Ina Schieferdecker    +
+ 29-09-2011 11:12    +
+ 		+ + + + +
+ Agreed to call it QualifiedIdentifier
+
+QualifiedIdentifier ::= {Identifier Dot} Identifier
+
+Check if that would be a duplicated rule in the BNF
+
+
+
+ + + + + + + + + + +
+ (0010401) +
+ Ina Schieferdecker    +
+ 29-11-2011 14:42    +
+ 		+ + + + +
+ Make FullGroupIdentifier to QualifiedIdentifier - see CR5935.docx - please check
+
+
+
+ + + + + + + + + + +
+ (0010407) +
+ Jacob Wieland - Spirent    +
+ 29-11-2011 18:21    +
(edited on: 29-11-2011 18:23)
+ 		+ + + + +
+ It's missing the definition of QualifiedIdentifierList. I assume it is:
+
+QualifiedIdentifierList ::= QualifiedIdentifier {"," QualifiedIdentifier}
+
+
+
+
+
+ + + + + + + + + + +
+ (0010410) +
+ Ina Schieferdecker    +
+ 30-11-2011 07:22    +
+ 		+ + + + +
+ Right. Implemented as proposed.
+
+ + diff --git a/docs/mantis/CR5936.md b/docs/mantis/CR5936.md new file mode 100644 index 0000000000000000000000000000000000000000..47593a244c0c9e6f204088c025c563215871e2f8 --- /dev/null +++ b/docs/mantis/CR5936.md @@ -0,0 +1,144 @@ + + + + + + + + + + + + + 0005936: Wrong example in C.31 - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005936Part 01: TTCN-3 Core LanguageClarificationpublic23-09-2011 16:1829-09-2011 09:44
ReporterGyorgy Rethy 
Assigned ToIna Schieferdecker 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.3.1 (published 2011-06) 
Target Versionv4.4.1 (published 2012-04)Fixed in Versionv4.4.1 (published 2012-04) 
Clause Reference(s)C.31
Source (company - Author)L.M.Ericsson
Summary0005936: Wrong example in C.31
DescriptionProduct version is in fact v4.3.2
+In clause C.31 The IsPresent function the first example is:
+    var MyRecord vl_MyRecord := { field1 := {}, field2 := 5 }
+
+    ispresent(vl_MyRecord.field1) // returns true
+
+in clause 3.1:
+partially initialized: values are partially initialized if a concrete value has been assigned to it or to at least one of its fields or elements
+
+completely initialized: values and templates of simple types are completely initialized if they are partially initialized
+
+The field vl_MyRecord.field1 does not fulfil any of the above definition, thus it shall be handled as uninitialized. But in this case ispresent(vl_MyRecord.field1) shall return false in the example.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR5936_resolution_v2.doc (81,920) 28-09-2011 09:16
http://oldforge.etsi.org/mantis/file_download.php?file_id=2566&type=bug
Issue History
Date ModifiedUsernameFieldChange
23-09-2011 16:18Gyorgy RethyNew Issue
23-09-2011 16:18Gyorgy RethyClause Reference(s) => C.31
23-09-2011 16:18Gyorgy RethySource (company - Author) => L.M.Ericsson
27-09-2011 10:54Gyorgy RethyNote Added: 0010235
27-09-2011 10:54Gyorgy RethyAssigned To => Gyorgy Rethy
27-09-2011 10:54Gyorgy RethyStatusnew => assigned
27-09-2011 10:54Gyorgy RethyTarget Version => Edition 4.4.1
27-09-2011 15:58Gyorgy RethyFile Added: CR5936_resolution_v1.doc
27-09-2011 15:58Gyorgy RethyNote Added: 0010250
27-09-2011 15:59Gyorgy RethyAssigned ToGyorgy Rethy => Jens Grabowski
28-09-2011 09:16Gyorgy RethyFile Deleted: CR5936_resolution_v1.doc
28-09-2011 09:16Gyorgy RethyFile Added: CR5936_resolution_v2.doc
28-09-2011 09:16Gyorgy RethyNote Edited: 0010250
28-09-2011 18:52Jens GrabowskiNote Added: 0010286
28-09-2011 18:52Jens GrabowskiAssigned ToJens Grabowski => Ina Schieferdecker
29-09-2011 09:32Ina SchieferdeckerRelationship addedrelated to 0005934
29-09-2011 09:44Ina SchieferdeckerStatusassigned => closed
29-09-2011 09:44Ina SchieferdeckerResolutionopen => fixed
29-09-2011 09:44Ina SchieferdeckerFixed in Version => Edition 4.4.1
29-09-2011 14:40Gyorgy RethyRelationship deletedrelated to 0005934
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010235) +
+ Gyorgy Rethy    +
+ 27-09-2011 10:54    +
+ 		+ + + + +
+ Change true to false in the example with appropriate explanation. Correct note2 of the definition partially initialized.
+
+
+
+ + + + + + + + + + +
+ (0010250) +
+ Gyorgy Rethy    +
+ 27-09-2011 15:58    +
(edited on: 28-09-2011 09:16)
+ 		+ + + + +
+ Pls. review resolution text in CR5936_resolution_v2.doc.
+
+
+
+
+
+ + + + + + + + + + +
+ (0010286) +
+ Jens Grabowski    +
+ 28-09-2011 18:52    +
+ 		+ + + + +
+ Resolution is fine with me. Assigned to Ina for inclusion into the standard.
+
+ + diff --git a/docs/mantis/CR5937.md b/docs/mantis/CR5937.md new file mode 100644 index 0000000000000000000000000000000000000000..53a57d1277b789a3779709a8ca6e89a42a8f4be0 --- /dev/null +++ b/docs/mantis/CR5937.md @@ -0,0 +1,178 @@ + + + + + + + + + + + + + 0005937: Generalize annotation of attributes to declarations/members. - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005937Part 01: TTCN-3 Core LanguageNew Featurepublic28-09-2011 13:4629-11-2011 11:24
ReporterJacob Wieland - Spirent 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.4.1 (published 2012-04)Fixed in Versionv4.4.1 (published 2012-04) 
Clause Reference(s)Clause 27
Source (company - Author)Testing Technologies - Jacob Wieland
Summary0005937: Generalize annotation of attributes to declarations/members.
Description1. It should be possible to add a with-block also for local declarations (i.e. var/const/template/timer/port). Actually, the standard text does not disallow this. There is no mention where the with-statement can actually be placed (except in the BNF).
+
+2. It should be allowed also for component type declarations to add annotations referencing the members of the component type. Although this can be solved as well with 1. the possibility of referencing multiple members in one annotation saves the user from unnecessary repetition). I also think that the standard already implies that this should already be possible:
+
+Clause 27.2. Restriction a)
+"DefinitionRef and FieldReference must refer to a definition or field respectively which is within the module, group or definition to which the with statement is associated."
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0005966closed Gyorgy Rethy Invalid syntax in 6.2 example 5 
Attached Filesdoc CR5937-proposal.doc (687,616) 29-09-2011 15:28
http://oldforge.etsi.org/mantis/file_download.php?file_id=2577&type=bug
Issue History
Date ModifiedUsernameFieldChange
28-09-2011 13:46Jacob Wieland - SpirentNew Issue
28-09-2011 13:46Jacob Wieland - SpirentClause Reference(s) => Clause 27
28-09-2011 13:46Jacob Wieland - SpirentSource (company - Author) => Testing Technologies - Jacob Wieland
28-09-2011 14:07Gyorgy RethyProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
28-09-2011 14:29Gyorgy RethyNote Added: 0010277
28-09-2011 14:29Gyorgy RethyAssigned To => Jacob Wieland - Spirent
28-09-2011 14:29Gyorgy RethyStatusnew => assigned
28-09-2011 14:29Gyorgy RethyTarget Version => Edition 4.4.1
29-09-2011 11:04Gyorgy RethyNote Edited: 0010277
29-09-2011 15:28Jacob Wieland - SpirentFile Added: CR5937-proposal.doc
29-09-2011 15:32Jacob Wieland - SpirentNote Added: 0010301
29-09-2011 15:32Jacob Wieland - SpirentRelationship addedrelated to 0005923
29-09-2011 15:34Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Ina Schieferdecker
29-11-2011 11:04Ina SchieferdeckerRelationship addedrelated to 0005966
29-11-2011 11:22Ina SchieferdeckerNote Added: 0010382
29-11-2011 11:23Ina SchieferdeckerStatusassigned => resolved
29-11-2011 11:23Ina SchieferdeckerResolutionopen => fixed
29-11-2011 11:23Ina SchieferdeckerFixed in Version => Edition 4.4.1
29-11-2011 11:23Ina SchieferdeckerStatusresolved => closed
29-11-2011 11:24Ina SchieferdeckerNote Added: 0010383
29-11-2011 15:52Ina SchieferdeckerRelationship deletedrelated to 0005923
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010277) +
+ Gyorgy Rethy    +
+ 28-09-2011 14:29    +
(edited on: 29-09-2011 11:04)
+ 		+ + + + +
+ STF discussion 2011-09-29: Basically agreed. The feaute should not complicate the use of attributes. Check possible tricky cases, overriding rules, rules when importing declarations with attributes attached to local definitions etc.
+
+
+
+
+
+ + + + + + + + + + +
+ (0010301) +
+ Jacob Wieland - Spirent    +
+ 29-09-2011 15:32    +
+ 		+ + + + +
+ please review proposal. Maybe WithStatement should also be allowed for port-type local declarations. If so, this needs to be taken into account for CR 5923.
+
+Other possible candidates are inline templates (i.e. TemplateBody) and parameter declarations (although these can already be annotated using the with statement with member-ref, I guess).
+
+
+
+ + + + + + + + + + +
+ (0010382) +
+ Ina Schieferdecker    +
+ 29-11-2011 11:22    +
+ 		+ + + + +
+ Changed to "A with statement may associate attributes to a single language element or to elements or fields of structured types (in a recursive way) or to members of component or port types, the same way ..."
+
+Note added to 27.1.3
+
+BNF changes as in CR5966
+
+
+
+ + + + + + + + + + +
+ (0010383) +
+ Ina Schieferdecker    +
+ 29-11-2011 11:24    +
+ 		+ + + + +
+ CR5966 yet to be implemented.
+
+ + diff --git a/docs/mantis/CR5938.md b/docs/mantis/CR5938.md new file mode 100644 index 0000000000000000000000000000000000000000..99971c5ce22ff641f5a1959160894755284b640b --- /dev/null +++ b/docs/mantis/CR5938.md @@ -0,0 +1,105 @@ + + + + + + + + + + + + + 0005938: Type restriction by template list - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005938Part 01: TTCN-3 Core LanguageNew Featurepublic29-09-2011 12:3110-07-2013 17:01
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.3.1 (published 2011-06) 
Target Versionv4.4.1 (published 2012-04)Fixed in Versionv4.4.1 (published 2012-04) 
Clause Reference(s)at least 6 and
Source (company - Author)STF430
Summary0005938: Type restriction by template list
DescriptionAs agreed at the STF meeting on 2011-09-29 we de-couple the two new features identified during discussion CR5262 into two CRs: a) constraning a type with a list of partially defined values and b) contraining types by templates. This CR is for the type restriction by template lists.
+Limitations of templates used for type constraints, identified by now consists:
+- must be completely defined when used - including using in type constraints;
+- shall be resolvable compile time i.e. the similar restrictions as to constants used in type constraints (see $10 restriction b)).
+
+The proposed text from CR5262 is uploaded here in file CR5262_initial_draft.doc
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0005262closed Ina Schieferdecker Part 01: TTCN-3 Core Language Partially constrained structured types 
related to 0005348closed Gyorgy Rethy Part 07: Using ASN.1 with TTCN-3 Transforming set operations in subtype definitions 
Attached Filesdoc CR5938_initial_draft.doc (433,152) 29-09-2011 12:34
http://oldforge.etsi.org/mantis/file_download.php?file_id=2573&type=bug
doc CR5938_proposal.doc (358,400) 30-09-2011 13:35
http://oldforge.etsi.org/mantis/file_download.php?file_id=2584&type=bug
Issue History
Date ModifiedUsernameFieldChange
29-09-2011 12:31Gyorgy RethyNew Issue
29-09-2011 12:31Gyorgy RethyClause Reference(s) => at least 6 and
29-09-2011 12:31Gyorgy RethySource (company - Author) => STF430
29-09-2011 12:34Gyorgy RethyFile Added: CR5938_initial_draft.doc
29-09-2011 12:35Gyorgy RethyAssigned To => Gyorgy Rethy
29-09-2011 12:35Gyorgy RethyStatusnew => assigned
29-09-2011 12:35Gyorgy RethyTarget Version => Edition 4.4.1
29-09-2011 12:35Gyorgy RethyDescription Updated
30-09-2011 13:35Jacob Wieland - SpirentNote Added: 0010311
30-09-2011 13:35Jacob Wieland - SpirentFile Added: CR5938_proposal.doc
30-11-2011 13:10Jacob Wieland - SpirentRelationship addedrelated to 0005348
15-12-2011 14:41Ina SchieferdeckerNote Added: 0010533
15-12-2011 14:41Ina SchieferdeckerStatusassigned => resolved
15-12-2011 14:41Ina SchieferdeckerResolutionopen => fixed
15-12-2011 14:41Ina SchieferdeckerFixed in Version => Edition 4.4.1
15-12-2011 14:41Ina SchieferdeckerStatusresolved => closed
10-07-2013 17:01Gyorgy RethyRelationship addedrelated to 0005262
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010311) +
+ Jacob Wieland - Spirent    +
+ 30-09-2011 13:35    +
+ 		+ + + + +
+ After checking the initial draft, amended the sentence about constant expressions. The rest should still be ok and add the desired features:
+
+1) Partial value specs
+2) Template value specs which are resolvable at compile-time
+
+
+
+ + + + + + + + + + +
+ (0010533) +
+ Ina Schieferdecker    +
+ 15-12-2011 14:41    +
+ 		+ + + + +
+ As proposed.
+
+ + diff --git a/docs/mantis/CR5941.md b/docs/mantis/CR5941.md new file mode 100644 index 0000000000000000000000000000000000000000..96581b334387ff508a67cc78aae76dd68e721c75 --- /dev/null +++ b/docs/mantis/CR5941.md @@ -0,0 +1,181 @@ + + + + + + + + + + + + + 0005941: What lenghtof shall return for record of templates with uninitialized elements? - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005941Part 01: TTCN-3 Core LanguageClarificationpublic04-10-2011 15:3116-12-2011 05:19
ReporterGyorgy Rethy 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.4.1 (published 2012-04)Fixed in Versionv4.4.1 (published 2012-04) 
Clause Reference(s)C.29
Source (company - Author)L.M.Ericsson
Summary0005941: What lenghtof shall return for record of templates with uninitialized elements?
DescriptionThe current text says:
+"The parameter inpar shall only match values, for which the lengthof function would give the same result."
+
+However, this description doesn't fit to case when the template contains uninitialize elements (what such template would match?).
+
+It is proposed to complete the sentence:
+""The parameter inpar shall only match values, for which the lengthof function would give the same result; for the purpose of this evaluation uninitialized elements shall be handled as they contained the AnyElement matching mechanism."
+"
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0005944closed Ina Schieferdecker Misleading sentence for lengthof for arrays. 
Attached Filesdoc CR5941_resolution_v2.doc (81,408) 02-12-2011 10:23
http://oldforge.etsi.org/mantis/file_download.php?file_id=2654&type=bug
Issue History
Date ModifiedUsernameFieldChange
04-10-2011 15:31Gyorgy RethyNew Issue
04-10-2011 15:31Gyorgy RethyClause Reference(s) => C.29
04-10-2011 15:31Gyorgy RethySource (company - Author) => L.M.Ericsson
06-10-2011 11:45Gyorgy RethyFixed in Version => Edition 4.4.1
28-11-2011 16:29Gyorgy RethyAssigned To => Ina Schieferdecker
28-11-2011 16:29Gyorgy RethyStatusnew => assigned
28-11-2011 16:29Gyorgy RethyFixed in VersionEdition 4.4.1 =>
28-11-2011 16:29Gyorgy RethyTarget Version => Edition 4.4.1
29-11-2011 10:05Ina SchieferdeckerNote Added: 0010373
29-11-2011 10:06Ina SchieferdeckerNote Added: 0010374
29-11-2011 10:06Ina SchieferdeckerAssigned ToIna Schieferdecker => Gyorgy Rethy
02-12-2011 10:23Gyorgy RethyNote Added: 0010503
02-12-2011 10:23Gyorgy RethyFile Added: CR5941_resolution_v2.doc
02-12-2011 10:23Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
02-12-2011 14:01Ina SchieferdeckerNote Added: 0010525
02-12-2011 14:06Ina SchieferdeckerRelationship addedrelated to 0005944
16-12-2011 05:19Ina SchieferdeckerStatusassigned => resolved
16-12-2011 05:19Ina SchieferdeckerResolutionopen => fixed
16-12-2011 05:19Ina SchieferdeckerFixed in Version => Edition 4.4.1
16-12-2011 05:19Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010373) +
+ Ina Schieferdecker    +
+ 29-11-2011 10:05    +
+ 		+ + + + +
+ Proposed to change to
+
+"In case of string-type templates, the inpar template shall match values of the same length only. If inpar contains uninitialized elements, these shall be handled as if they would be "*" (AnyElementsOrNone inside value)."
+
+"In case of templates of record of or set of types, the inpar template shall match values for which the lengthof function would give the same result only. If inpar contains uninitialized elements, these shall be handled as if they would be "*" (AnyElementsOrNone inside value)."
+
+
+And adding before the paragraphs on templates for lengthof the following:
+
+"When the function lengthof is applied to string-type templates or to templates of record of or set of types, the length is to be determined by the length of values defined in the template or by the length restriction matching attribute of that template if matching attributes like "*" (AnyElementsOrNone instead of a value) are used that do not predetermine the length."
+
+
+
+ + + + + + + + + + +
+ (0010374) +
+ Ina Schieferdecker    +
+ 29-11-2011 10:06    +
+ 		+ + + + +
+ Please check resolution noted above.
+
+
+
+ + + + + + + + + + +
+ (0010503) +
+ Gyorgy Rethy    +
+ 02-12-2011 10:23    +
+ 		+ + + + +
+ See resolution proosal in file in CR5941_resolution_v2.doc. Pls. review.
+
+
+
+ + + + + + + + + + +
+ (0010525) +
+ Ina Schieferdecker    +
+ 02-12-2011 14:01    +
+ 		+ + + + +
+ as proposed.
+
+ + diff --git a/docs/mantis/CR5942.md b/docs/mantis/CR5942.md new file mode 100644 index 0000000000000000000000000000000000000000..d7af53976250c1b6573e7f131ba7f38150c1e7cd --- /dev/null +++ b/docs/mantis/CR5942.md @@ -0,0 +1,213 @@ + + + + + + + + + + + + + 0005942: Boundness of arguments of the match operation - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005942Part 01: TTCN-3 Core LanguageTechnicalpublic05-10-2011 12:5211-07-2012 11:42
ReporterGyorgy Rethy 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.5.1 (published 2013-04)Fixed in Versionv4.5.1 (published 2013-04) 
Clause Reference(s)al least 15.9
Source (company - Author)L.M.Ericsson
Summary0005942: Boundness of arguments of the match operation
DescriptionIn evolving the TTCN-3 language it has been defined that in parameters may also be partly initialized. Also, we allowed some of the operations to work on partly initialized operators. However, currently no regulation regarding boundness is included for the match operation.
+
+Though this should be clear implicitly, it is proposed to state explicitly, as a restriction that both operators of match shall be completely initialized.
+
+Also the standard could need sanity-check regarding other operations (the issue was raised by a user related to match and no general check could be done before sumbitting this CR).
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0005980closed Ina Schieferdecker all templates/variables referenced in special matching mechanism symbols shall be completely initialized 
Attached Filesdoc CR5942.doc (169,984) 29-11-2011 09:41
http://oldforge.etsi.org/mantis/file_download.php?file_id=2591&type=bug
doc CR5942_resolution_v2.doc (54,272) 02-12-2011 10:54
http://oldforge.etsi.org/mantis/file_download.php?file_id=2655&type=bug
doc CR5942_resolution_v3.doc (53,760) 11-07-2012 11:30
http://oldforge.etsi.org/mantis/file_download.php?file_id=2667&type=bug
Issue History
Date ModifiedUsernameFieldChange
05-10-2011 12:52Gyorgy RethyNew Issue
05-10-2011 12:52Gyorgy RethyClause Reference(s) => al least 15.9
05-10-2011 12:52Gyorgy RethySource (company - Author) => L.M.Ericsson
06-10-2011 11:44Gyorgy RethyTarget Version => Edition 4.4.1
28-11-2011 10:24Jacob Wieland - SpirentNote Added: 0010333
28-11-2011 10:29Jacob Wieland - SpirentNote Added: 0010334
28-11-2011 16:26Gyorgy RethyAssigned To => Jacob Wieland - Spirent
28-11-2011 16:26Gyorgy RethyStatusnew => assigned
29-11-2011 09:41Jacob Wieland - SpirentFile Added: CR5942.doc
29-11-2011 09:50Jacob Wieland - SpirentNote Added: 0010372
29-11-2011 09:51Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
02-12-2011 10:54Gyorgy RethyNote Added: 0010509
02-12-2011 10:54Gyorgy RethyFile Added: CR5942_resolution_v2.doc
02-12-2011 10:55Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
02-12-2011 10:55Gyorgy RethyStatusassigned => resolved
02-12-2011 11:10Jacob Wieland - SpirentRelationship addedrelated to 0005980
09-07-2012 17:15Ina SchieferdeckerTarget VersionEdition 4.4.1 => Edition 4.5.1
11-07-2012 11:30Ina SchieferdeckerFile Added: CR5942_resolution_v3.doc
11-07-2012 11:31Ina SchieferdeckerStatusresolved => closed
11-07-2012 11:31Ina SchieferdeckerFixed in Version => Edition 4.5.1
11-07-2012 11:31Ina SchieferdeckerResolutionopen => fixed
11-07-2012 11:42Ina SchieferdeckerNote Added: 0010832
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010333) +
+ Jacob Wieland - Spirent    +
+ 28-11-2011 10:24    +
+ 		+ + + + +
+ At least the section 15.11. on concatenating templates should enforce that the operands be at least partially initialized.
+
+
+
+ + + + + + + + + + +
+ (0010334) +
+ Jacob Wieland - Spirent    +
+ 28-11-2011 10:29    +
+ 		+ + + + +
+ Also, all structured matching mechanism symbols (ifpresent, subset, superset, permutation, complement, valuelist) should be restricted that their arguments should be fully initialized.
+
+
+
+ + + + + + + + + + +
+ (0010372) +
+ Jacob Wieland - Spirent    +
+ 29-11-2011 09:50    +
+ 		+ + + + +
+ uploaded proposal, the following restrictions have been added:
+
+- parameters of match operation shall be completely initialized
+- for special matching mechanism symbols (both instead-of-values and inside-values and additinal attribute symbols) containing other values or templates, these shall be completely initialized
+- concatenated templates shall be completely initialized
+
+I also added the usual structure to section 15.11
+
+
+
+ + + + + + + + + + +
+ (0010509) +
+ Gyorgy Rethy    +
+ 02-12-2011 10:54    +
+ 		+ + + + +
+ As we discussed, the user shall be able to concatenate also partially initialized values and templates.
+
+I don't understand the matching mechanism item either. It is already defined that when a template is USED, i.e. in a sending or receiving operation, it shall be completely initialized. This, of course, also applies e.g. to the values that are members of value lists, complemented value lists etc. But why to forbid defining e.g. a var template, which has a formal parameter or a component variable in its value list? both are unidefined at the point of DEFINING the template but your restrictions could be taken as they are disallowed.
+
+As there is an agreement regarding the match operation, I left only this in the file CR5942_resolution_v2.doc. If you still think that something should be added for the matching mechanisms, pls. submit a new CR.
+
+
+
+ + + + + + + + + + +
+ (0010832) +
+ Ina Schieferdecker    +
+ 11-07-2012 11:42    +
+ 		+ + + + +
+ Implemented as in v3
+
+ + diff --git a/docs/mantis/CR5944.md b/docs/mantis/CR5944.md new file mode 100644 index 0000000000000000000000000000000000000000..44cd6d4a9ecf93ba91f4515ca4137d5aabbe222d --- /dev/null +++ b/docs/mantis/CR5944.md @@ -0,0 +1,209 @@ + + + + + + + + + + + + + 0005944: Misleading sentence for lengthof for arrays. - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005944Part 01: TTCN-3 Core LanguageTechnicalpublic06-10-2011 10:0129-11-2011 14:07
ReporterGyorgy Rethy 
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) 
Clause Reference(s)C.29
Source (company - Author)L.M.Ericsson
Summary0005944: Misleading sentence for lengthof for arrays.
DescriptionThe current text, regarding the lengthof arrays is:
+"For record of, set of, and array, the value to be returned is the sequential number of the last initialized element: in case of record of and set of the index of that element plus 1. In case of arrays, lengthof should return the index of that last element minus the index of the first element plus 1.
+The length of a fixed length record of, set of, or array value will always be the fixed length according to the type definition."
+
+Arrays are equivalent to fixed-length record ofs, thus the sentence "In case of arrays..." is simply wrong and contradicts to the next sentence ("The length of a fixed length record of, set of, or array value will always be the fixed length according to the type definition.").
+
+Arrays are always of fixed length. Therefore each instance of an array definition (like instances of fixed-length record/set of types) shall have exactly the length specified in the definition. The text shall be changed to:
+"For non-fixed length record of and set of, the value to be returned is the sequential number of the last initialized element: the index of that element plus 1.
+The length of a fixed length record of, set of and arrays shall always be the fixed length according to their types: in case of record of and set of the size specified by the length restriction of the type definition, in case of arrays it shall be the upper index minus the lower index plus 1."
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0005941closed Ina Schieferdecker What lenghtof shall return for record of templates with uninitialized elements? 
Attached Filesdoc CR5944.doc (87,552) 29-11-2011 10:30
http://oldforge.etsi.org/mantis/file_download.php?file_id=2592&type=bug
Issue History
Date ModifiedUsernameFieldChange
06-10-2011 10:01Gyorgy RethyNew Issue
06-10-2011 10:01Gyorgy RethyClause Reference(s) => C.29
06-10-2011 10:01Gyorgy RethySource (company - Author) => L.M.Ericsson
06-10-2011 11:44Gyorgy RethyTarget Version => Edition 4.4.1
06-10-2011 11:44Gyorgy RethySummaryMisleading definition for lengthof for arrays. => Misleading sentence for lengthof for arrays.
06-10-2011 11:44Gyorgy RethyDescription Updated
07-10-2011 16:35Gyorgy RethyDescription Updated
07-10-2011 17:01Gyorgy RethyDescription Updated
28-11-2011 10:13Jacob Wieland - SpirentNote Added: 0010332
28-11-2011 12:54Gyorgy RethyNote Added: 0010343
28-11-2011 16:24Gyorgy RethyNote Added: 0010362
28-11-2011 16:24Gyorgy RethyAssigned To => Jacob Wieland - Spirent
28-11-2011 16:24Gyorgy RethyStatusnew => assigned
29-11-2011 10:30Jacob Wieland - SpirentFile Added: CR5944.doc
29-11-2011 10:31Jacob Wieland - SpirentNote Added: 0010378
29-11-2011 10:31Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Ina Schieferdecker
29-11-2011 14:06Ina SchieferdeckerNote Added: 0010396
29-11-2011 14:06Ina SchieferdeckerStatusassigned => resolved
29-11-2011 14:06Ina SchieferdeckerResolutionopen => fixed
29-11-2011 14:06Ina SchieferdeckerFixed in Version => Edition 4.4.1
29-11-2011 14:07Ina SchieferdeckerStatusresolved => closed
02-12-2011 14:06Ina SchieferdeckerRelationship addedrelated to 0005941
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010332) +
+ Jacob Wieland - Spirent    +
+ 28-11-2011 10:13    +
+ 		+ + + + +
+ Agreed. But I would grammatically re-formulate it to:
+
+"The length of a fixed length record of, set of or array shall always be the fixed length according to its type ..."
+
+
+
+ + + + + + + + + + +
+ (0010343) +
+ Gyorgy Rethy    +
+ 28-11-2011 12:54    +
+ 		+ + + + +
+ has to be discussed as different tools give different results. Therefore we need more detailed investigation.
+
+
+
+ + + + + + + + + + +
+ (0010362) +
+ Gyorgy Rethy    +
+ 28-11-2011 16:24    +
+ 		+ + + + +
+ STF discussion 28/11: formulate the resolution text. Take into account the minimum length acc. to the lenght restriction; fixed length is a special case of this.
+
+
+
+ + + + + + + + + + +
+ (0010378) +
+ Jacob Wieland - Spirent    +
+ 29-11-2011 10:31    +
+ 		+ + + + +
+ uploaded proposal, please review
+
+
+
+ + + + + + + + + + +
+ (0010396) +
+ Ina Schieferdecker    +
+ 29-11-2011 14:06    +
+ 		+ + + + +
+ As proposed.
+
+ + diff --git a/docs/mantis/CR5945.md b/docs/mantis/CR5945.md new file mode 100644 index 0000000000000000000000000000000000000000..6d0ab183df87813c0f05f3b5c4a773470212f5e9 --- /dev/null +++ b/docs/mantis/CR5945.md @@ -0,0 +1,246 @@ + + + + + + + + + + + + + 0005945: Missing types in TCI C++ mappings - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005945Part 06: TTCN-3 Control InterfaceTechnicalpublic15-10-2011 17:4516-12-2011 06:01
ReporterMateusz Pusz 
Assigned ToIna Schieferdecker 
PrioritynormalSeveritytrivialReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.4.1 (published 2012-04)Fixed in Versionv4.4.1 (published 2012-04) 
Clause Reference(s)10.6.1.1 & 10.5.3.9-10
Source (company - Author)Mateusz Pusz/freettcn
Summary0005945: Missing types in TCI C++ mappings
DescriptionTciTestCaseIdList is not defined in TCI C++ mappings but is used by
+TciTmRequired (10.6.1.1) in method tciGetTestCases().
+Tchar is not defined in the standard too and it is used in
+OctetstringValue and HexstringValue interfaces (10.5.3.9-10).
+
+Could you please add those definitions to the standard?
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR5945_TestCaseIdListType.docx (19,189) 02-12-2011 13:31
http://oldforge.etsi.org/mantis/file_download.php?file_id=2657&type=bug
Issue History
Date ModifiedUsernameFieldChange
15-10-2011 17:45Mateusz PuszNew Issue
15-10-2011 17:45Mateusz PuszClause Reference(s) => 10.6.1.1 & 10.5.3.9-10
15-10-2011 17:45Mateusz PuszSource (company - Author) => Mateusz Pusz/freettcn
28-11-2011 16:18Gyorgy RethyProjectTTCN-3 Change Requests => Part 06: TTCN-3 Control Interface
28-11-2011 16:18Gyorgy RethyNote Added: 0010361
28-11-2011 16:19Gyorgy RethyAssigned To => Ina Schieferdecker
28-11-2011 16:19Gyorgy RethyStatusnew => assigned
28-11-2011 16:19Gyorgy RethyTarget Version => Edition 4.4.1
02-12-2011 13:31Ina SchieferdeckerFile Added: CR5945_TestCaseIdListType.docx
02-12-2011 13:41Ina SchieferdeckerNote Added: 0010518
02-12-2011 13:41Ina SchieferdeckerNote Added: 0010519
02-12-2011 13:42Ina SchieferdeckerAssigned ToIna Schieferdecker => Jacob Wieland - Spirent
02-12-2011 15:13Jacob Wieland - SpirentNote Added: 0010528
02-12-2011 16:12Mateusz PuszNote Added: 0010530
03-12-2011 05:48Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Ina Schieferdecker
16-12-2011 06:00Ina SchieferdeckerNote Added: 0010541
16-12-2011 06:00Ina SchieferdeckerStatusassigned => resolved
16-12-2011 06:00Ina SchieferdeckerResolutionopen => fixed
16-12-2011 06:00Ina SchieferdeckerFixed in Version => Edition 4.4.1
16-12-2011 06:01Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010361) +
+ Gyorgy Rethy    +
+ 28-11-2011 16:18    +
+ 		+ + + + +
+ STF discussion 28/11: to be checked.
+
+
+
+ + + + + + + + + + +
+ (0010518) +
+ Ina Schieferdecker    +
+ 02-12-2011 13:41    +
+ 		+ + + + +
+ Tchar in C++
+
+to be defined in 10.5.1 Encapsulated C++ types
+
+The following types have been defined in order to keep the definitions of data types and operations as general as possible:
+....
+Char type definition: typedef unsigned char Tchar
+
+
+
+ + + + + + + + + + +
+ (0010519) +
+ Ina Schieferdecker    +
+ 02-12-2011 13:41    +
+ 		+ + + + +
+ Please check.
+
+
+
+ + + + + + + + + + +
+ (0010528) +
+ Jacob Wieland - Spirent    +
+ 02-12-2011 15:13    +
+ 		+ + + + +
+ seems ok.
+
+
+
+ + + + + + + + + + +
+ (0010530) +
+ Mateusz Pusz    +
+ 02-12-2011 16:12    +
+ 		+ + + + +
+ Please see 0000003 in: http://list.etsi.org/scripts/wa.exe?A2=ind1110&L=ttcn3&T=0&P=393. [^]
+
+What do you think about that?
+
+
+
+ + + + + + + + + + +
+ (0010541) +
+ Ina Schieferdecker    +
+ 16-12-2011 06:00    +
+ 		+ + + + +
+ Tchar is also in the other language mappings so that we stick to it
+
+ + diff --git a/docs/mantis/CR5946.md b/docs/mantis/CR5946.md new file mode 100644 index 0000000000000000000000000000000000000000..6543cf04d03beb4bc551f53363e7ddf9bf33c862 --- /dev/null +++ b/docs/mantis/CR5946.md @@ -0,0 +1,232 @@ + + + + + + + + + + + + + 0005946: TRI & TCI identifiers in C++ interface mapping wrongly defined - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005946Part 06: TTCN-3 Control InterfaceTechnicalpublic15-10-2011 18:0310-08-2012 12:08
ReporterMateusz Pusz 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityblockReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.5.1 (published 2013-04)Fixed in Versionv4.5.1 (published 2013-04) 
Clause Reference(s)TRI 8.5.2, TCI 10.5.2
Source (company - Author)Mateusz Pusz/freettcn
Summary0005946: TRI & TCI identifiers in C++ interface mapping wrongly defined
DescriptionSome TRI and TCI interfaces C++ mappings inherit privately from TRI::QualifiedName. That makes impossible to call any of its interface methods. To make it straight lets assume that TM just received TciTestCaseIdList from TciTmRequired::tciGetTestCases() and wants to present the names to the user. How is it supposed to do it if it does not have the access to private interface of TciTestCaseId class (because public interface of QualifiedName ends as private one in privately inherited child class)? I think that aggregation:
+
+class TciTestCaseId {
+.....
+const QualifiedName &id() const;
+.....
+};
+
+or public inheritance if really needed:
+
+class TciTestCaseId : public QualifiedName {
+.....
+};
+
+should be used here to achieve the goal. Another issue here is the existence of non-virtual cloneQualifiedName() method which makes it not only unusable (no-one have access to it) but also unimplementable as you cannot create the same object from that level in inheritance hierarchy (object slicing).
+
+Even with above problem solved the class does not have any virtual method which makes it really hard to implement its methods as the class does not have any internal members. Because of that the developer is forced to do some external database with contents of those classes (like a map of QualifiedName pointers pointing to its content) and use it with every access to the class interface. It is why I think all methods in that class should be done pure virtual.
+
+I suggest:
+1. Making all methods in QualifiedName virtual and pure virtual (see https://github.com/mpusz/FreeTTCN/blob/d2ff73bbb9f4bb5e49b5cabe2c156512e456056c/freettcn/lib/include/freettcn/etsi/types.h#L60 [^])
+2. Make IDs inherit (TTCN_ID_IFACE_FIXED_1) or aggregate (TTCN_ID_IFACE_FIXED_2) QualifiedName (see https://github.com/mpusz/FreeTTCN/blob/d2ff73bbb9f4bb5e49b5cabe2c156512e456056c/freettcn/lib/include/freettcn/etsi/tci.h [^] and https://github.com/mpusz/FreeTTCN/blob/d2ff73bbb9f4bb5e49b5cabe2c156512e456056c/freettcn/lib/include/freettcn/etsi/tri.h [^])
+I personaly think that aggregation is better here and will make the interface more consistent with other classes like TriComponentId (https://github.com/mpusz/FreeTTCN/blob/d2ff73bbb9f4bb5e49b5cabe2c156512e456056c/freettcn/lib/include/freettcn/etsi/tri.h#L66 [^]). However both solutions will make the interface implementable,
+
+Best
+
+Mat
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
parent of 0006257closed Ina Schieferdecker Part 05: TTCN-3 Runtime Interface  TRI & TCI identifiers in C++ interface mapping wrongly defined 
Attached Filesdocx CR_5946_resolution_v1.docx (45,798) 12-07-2012 16:32
http://oldforge.etsi.org/mantis/file_download.php?file_id=2692&type=bug
Issue History
Date ModifiedUsernameFieldChange
15-10-2011 18:03Mateusz PuszNew Issue
15-10-2011 18:03Mateusz PuszClause Reference(s) => TRI 8.5.2, TCI 10.5.2
15-10-2011 18:03Mateusz PuszSource (company - Author) => Mateusz Pusz/freettcn
15-10-2011 21:05Mateusz PuszNote Added: 0010322
15-10-2011 21:07Mateusz PuszNote Edited: 0010322
28-11-2011 16:16Gyorgy RethyProjectTTCN-3 Change Requests => Part 06: TTCN-3 Control Interface
28-11-2011 16:17Gyorgy RethyNote Added: 0010360
30-11-2011 11:01Ina SchieferdeckerAssigned To => Ina Schieferdecker
30-11-2011 11:01Ina SchieferdeckerStatusnew => assigned
30-11-2011 11:01Ina SchieferdeckerTarget Version => v4.7.1 (published 2015-06)
12-07-2012 14:10Ina SchieferdeckerAssigned ToIna Schieferdecker => Tomas Urban
12-07-2012 16:32Tomas UrbanFile Added: CR_5946_resolution_v1.docx
12-07-2012 16:42Tomas UrbanNote Added: 0010898
12-07-2012 17:01Tomas UrbanStatusassigned => feedback
13-07-2012 12:13Tomas UrbanStatusfeedback => resolved
13-07-2012 12:13Tomas UrbanResolutionopen => fixed
09-08-2012 14:43Tomas UrbanAssigned ToTomas Urban => Ina Schieferdecker
09-08-2012 14:43Tomas UrbanStatusresolved => feedback
09-08-2012 14:43Tomas UrbanResolutionfixed => reopened
09-08-2012 14:43Tomas UrbanNote Added: 0011009
09-08-2012 14:44Tomas UrbanStatusfeedback => assigned
09-08-2012 14:44Tomas UrbanResolutionreopened => open
10-08-2012 12:06Ina SchieferdeckerIssue cloned: 0006257
10-08-2012 12:06Ina SchieferdeckerRelationship addedparent of 0006257
10-08-2012 12:08Ina SchieferdeckerNote Added: 0011027
10-08-2012 12:08Ina SchieferdeckerStatusassigned => closed
10-08-2012 12:08Ina SchieferdeckerResolutionopen => fixed
10-08-2012 12:08Ina SchieferdeckerFixed in Version => Edition 4.5.1
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010322) +
+ Mateusz Pusz    +
+ 15-10-2011 21:05    +
(edited on: 15-10-2011 21:07)
+ 		+ + + + +
+ BTW example implementation for both approaches can be found here: https://github.com/mpusz/FreeTTCN/blob/d2ff73bbb9f4bb5e49b5cabe2c156512e456056c/freettcn/lib/include/freettcn/ttcn3/ttcnId.h [^]
+
+
+
+
+
+ + + + + + + + + + +
+ (0010360) +
+ Gyorgy Rethy    +
+ 28-11-2011 16:17    +
+ 		+ + + + +
+ STF discussion 28/11: Discuss it with tool vendors.
+
+
+
+ + + + + + + + + + +
+ (0010898) +
+ Tomas Urban    +
+ 12-07-2012 16:42    +
+ 		+ + + + +
+ The proposed resolution is to change the methods of QualifiedName to pure virtual and change the definition of the classes derived from QualifiedName (i.e. TriFunctionId, TriSignatureId, TriTestCaseId, TciBehaviourId, TciTestCaseId, TciModuleParameterId) so that the inheritance is public.
+
+The changes were kept on the necessary minimum in order to preserve backwards compatibility of the C++ mapping. For that reason, it was not possible to opt for the aggregate solution or to unify naming of cloning methods.
+
+Tool vendors will be notified about the change. Final decition about the proposal shall be made based on the feedback from the vendors.
+
+
+
+ + + + + + + + + + +
+ (0011009) +
+ Tomas Urban    +
+ 09-08-2012 14:43    +
+ 		+ + + + +
+ No significant feedback was received from the vendors, so it seems we can go on with changing the standard.
+
+Ina, could you please check the proposed resolution?
+
+
+
+ + + + + + + + + + +
+ (0011027) +
+ Ina Schieferdecker    +
+ 10-08-2012 12:08    +
+ 		+ + + + +
+ Implemented as proposed.
+
+ + diff --git a/docs/mantis/CR5947.md b/docs/mantis/CR5947.md new file mode 100644 index 0000000000000000000000000000000000000000..7e07b21ec04445ee0e32088e505902f0319aad7b --- /dev/null +++ b/docs/mantis/CR5947.md @@ -0,0 +1,247 @@ + + + + + + + + + + + + + 0005947: Problem with C++ mapping of TriComponentId::getComponentName() - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 05: TTCN-3 Runtime Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005947Part 05: TTCN-3 Runtime Interface Technicalpublic15-10-2011 18:1102-12-2011 12:55
ReporterMateusz Pusz 
Assigned ToIna Schieferdecker 
PrioritynormalSeveritytrivialReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.4.1 (published 2012-04)Fixed in Versionv4.4.1 (published 2012-04) 
Clause Reference(s)TRI 8.5.2.4
Source (company - Author)Mateusz Pusz/freettcn
Summary0005947: Problem with C++ mapping of TriComponentId::getComponentName()
DescriptionTriComponentId::getComponentName() should return const reference to Tstring so it should look like:
+virtual const Tstring &getComponentName() const = 0;
+(see https://github.com/mpusz/FreeTTCN/blob/d2ff73bbb9f4bb5e49b5cabe2c156512e456056c/freettcn/lib/include/freettcn/etsi/tri.h#L69 [^])
+
+Best
+
+Mat
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
15-10-2011 18:11Mateusz PuszNew Issue
15-10-2011 18:11Mateusz PuszClause Reference(s) => TRI 8.5.2.4
15-10-2011 18:11Mateusz PuszSource (company - Author) => Mateusz Pusz/freettcn
28-11-2011 12:52Gyorgy RethyProjectTTCN-3 Change Requests => Part 05: TTCN-3 Runtime Interface
28-11-2011 16:15Gyorgy RethyNote Added: 0010359
28-11-2011 16:15Gyorgy RethyAssigned To => Ina Schieferdecker
28-11-2011 16:15Gyorgy RethyStatusnew => assigned
28-11-2011 16:15Gyorgy RethyTarget Version => Edition 4.4.1
01-12-2011 15:32Jacob Wieland - SpirentNote Added: 0010487
02-12-2011 07:01Ina SchieferdeckerNote Added: 0010496
02-12-2011 07:02Ina SchieferdeckerStatusassigned => resolved
02-12-2011 07:02Ina SchieferdeckerResolutionopen => fixed
02-12-2011 07:02Ina SchieferdeckerFixed in Version => Edition 4.4.1
02-12-2011 07:02Ina SchieferdeckerStatusresolved => closed
02-12-2011 09:15Mateusz PuszStatusclosed => feedback
02-12-2011 09:15Mateusz PuszResolutionfixed => reopened
02-12-2011 09:15Mateusz PuszNote Added: 0010500
02-12-2011 11:03Ina SchieferdeckerNote Added: 0010510
02-12-2011 12:55Ina SchieferdeckerStatusfeedback => closed
02-12-2011 12:55Ina SchieferdeckerResolutionreopened => fixed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010359) +
+ Gyorgy Rethy    +
+ 28-11-2011 16:15    +
+ 		+ + + + +
+ STF discussion 28/11: Check if there is an error in the standard. If not, postpone the CR to 2012.
+
+
+
+ + + + + + + + + + +
+ (0010487) +
+ Jacob Wieland - Spirent    +
+ 01-12-2011 15:32    +
+ 		+ + + + +
+ that is correct. Please implement as proposed.
+
+
+
+ + + + + + + + + + +
+ (0010496) +
+ Ina Schieferdecker    +
+ 02-12-2011 07:01    +
+ 		+ + + + +
+ Changed all getter methods to const:
+
+class TriAddress {
+public:
+...
+    virtual const Tsize getBitsDataLen()const=0;
+...
+
+class TriComponentId {
+public:
+...
+    virtual const Tstring & getComponentName () const =0;
+...
+
+class TriException {
+public:
+...
+    virtual const Tsize getBitsDataLen()const=0;
+...
+
+class TriMessage {
+public:
+...
+    virtual const Tsize getBitsDataLen()const=0;
+...
+
+class TriParameter {
+public:
+...
+    virtual const Tsize getBitsDataLen()const=0;
+...
+
+class TriPortId {
+public:
+...
+    virtual const Tsize getPortIndex () const =0;
+...
+
+class TriTimerDuration {
+public:
+...
+    virtual const Tfloat getDuration () const =0;
+...
+
+
+
+ + + + + + + + + + +
+ (0010500) +
+ Mateusz Pusz    +
+ 02-12-2011 09:15    +
+ 		+ + + + +
+ Please do not add any other consts that requested. They are not needed there. The values are passed there by copy and not a reference or pointer. Adding const to a passing by value only obfuscates the code and does not solve any problem.
+
+
+
+ + + + + + + + + + +
+ (0010510) +
+ Ina Schieferdecker    +
+ 02-12-2011 11:03    +
+ 		+ + + + +
+ well, this sounds inconsistent to the STF - but we buy your C++ expertise and will add const to getComponentName() only
+
+ + diff --git a/docs/mantis/CR5948.md b/docs/mantis/CR5948.md new file mode 100644 index 0000000000000000000000000000000000000000..d6ee30255fd2c8cd2c9e43114671b6357e8c9762 --- /dev/null +++ b/docs/mantis/CR5948.md @@ -0,0 +1,211 @@ + + + + + + + + + + + + + 0005948: C++ mapings toString() not needed - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 05: TTCN-3 Runtime Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005948Part 05: TTCN-3 Runtime Interface Technicalpublic15-10-2011 18:3210-08-2012 15:03
ReporterMateusz Pusz 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.5.1 (published 2013-04)Fixed in Versionv4.5.1 (published 2013-04) 
Clause Reference(s)TRI 8.5
Source (company - Author)Mateusz Pusz/freettcn
Summary0005948: C++ mapings toString() not needed
DescriptiontoString() methods should not be a part of classes interfaces (they are not needed here). They do not introduce anything that cannot be obtained with already existing public interface. In many cases people will not use toString() interface methods because they may not be implemented like they need (by other vendors). Instead they will create their own utility functions to create strings like they really need (i.e. in TM or TL). Those utilities will use class members visible by already existing public interfaces.
+
+Providing that method in a class forces developer to implement them but he may not know what is the desired output to best fit TL, TM or other entities needs.
+
+Moreover none of TCI classes provide such a method which makes the interface inconsistent.
+
+Please remove those method from QualifiedName, TriComponentId, TriMessage, triException,
+
+Best
+
+Mat
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR5948.docx (24,197) 12-07-2012 11:44
http://oldforge.etsi.org/mantis/file_download.php?file_id=2690&type=bug
Issue History
Date ModifiedUsernameFieldChange
15-10-2011 18:32Mateusz PuszNew Issue
15-10-2011 18:32Mateusz PuszClause Reference(s) => TRI 8.5
15-10-2011 18:32Mateusz PuszSource (company - Author) => Mateusz Pusz/freettcn
28-11-2011 12:52Gyorgy RethyProjectTTCN-3 Change Requests => Part 06: TTCN-3 Control Interface
28-11-2011 16:13Gyorgy RethyNote Added: 0010358
28-11-2011 16:13Gyorgy RethyTarget Version => v4.7.1 (published 2015-06)
30-11-2011 11:02Ina SchieferdeckerStatusnew => assigned
30-11-2011 11:02Ina SchieferdeckerAssigned To => Ina Schieferdecker
12-07-2012 11:38Ina SchieferdeckerProjectPart 06: TTCN-3 Control Interface => Part 05: TTCN-3 Runtime Interface
12-07-2012 11:40Ina SchieferdeckerNote Added: 0010874
12-07-2012 11:44Ina SchieferdeckerFile Added: CR5948.docx
12-07-2012 11:45Ina SchieferdeckerNote Added: 0010875
12-07-2012 11:45Ina SchieferdeckerAssigned ToIna Schieferdecker => Tomas Urban
12-07-2012 11:45Ina SchieferdeckerResolutionopen => fixed
12-07-2012 11:56Tomas UrbanNote Added: 0010878
12-07-2012 11:56Tomas UrbanAssigned ToTomas Urban => Ina Schieferdecker
10-08-2012 15:03Ina SchieferdeckerNote Added: 0011035
10-08-2012 15:03Ina SchieferdeckerStatusassigned => closed
10-08-2012 15:03Ina SchieferdeckerFixed in Version => Edition 4.5.1
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010358) +
+ Gyorgy Rethy    +
+ 28-11-2011 16:13    +
+ 		+ + + + +
+ Postponed to 2012. Needs be discussed with tool vendors.
+
+
+
+ + + + + + + + + + +
+ (0010874) +
+ Ina Schieferdecker    +
+ 12-07-2012 11:40    +
+ 		+ + + + +
+ toString() not in TCI, just in TRI
+
+toString() not only in the C++, but also in the Java mapping - however would leave this untouched.
+
+
+
+ + + + + + + + + + +
+ (0010875) +
+ Ina Schieferdecker    +
+ 12-07-2012 11:45    +
+ 		+ + + + +
+ Please check.
+
+
+
+ + + + + + + + + + +
+ (0010878) +
+ Tomas Urban    +
+ 12-07-2012 11:56    +
+ 		+ + + + +
+ Reviewed. No issues found. It can be added to the specification.
+
+
+
+ + + + + + + + + + +
+ (0011035) +
+ Ina Schieferdecker    +
+ 10-08-2012 15:03    +
+ 		+ + + + +
+ as proposed
+
+ + diff --git a/docs/mantis/CR5949.md b/docs/mantis/CR5949.md new file mode 100644 index 0000000000000000000000000000000000000000..3a7a03aadd3c3dc5ecdfe7ab72e0f5bac11042dc --- /dev/null +++ b/docs/mantis/CR5949.md @@ -0,0 +1,146 @@ + + + + + + + + + + + + + 0005949: TCI and TRI C++ mappings interface unification - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005949Part 06: TTCN-3 Control InterfaceTechnicalpublic15-10-2011 19:1813-07-2012 11:10
ReporterMateusz Pusz 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.5.1 (published 2013-04)Fixed in Versionv4.5.1 (published 2013-04) 
Clause Reference(s)TRI 8.5.2, TCI 10.5.2
Source (company - Author)Mateusz Pusz/freettcn
Summary0005949: TCI and TRI C++ mappings interface unification
DescriptionTRI and TCI C++ mapping interfaces are in some places inconsistent and it would be good to fix it. Especially interfcace for lists is greatly affected. Here is the summary of problems:
+- some get() functions do not use Tindex type
+- some lists have push_back() while other have add() methods
+- most of the classes have clone() while other have cloneSOMETHING() methods which makes them hard to implement in one unified way
+- some classes define isEmpty() method instead of empty()
+- TRI classes return reference in get() methods while TCI returns pointers. I think that latter is better as it leaves the chance to return 0 when index is out out array bounds.
+
+The detailed list of changes can be found by browsing for TTCN_LIST_IFACE_FIXED in https://github.com/mpusz/FreeTTCN/blob/d2ff73bbb9f4bb5e49b5cabe2c156512e456056c/freettcn/lib/include/freettcn/etsi/tri.h [^] and https://github.com/mpusz/FreeTTCN/blob/d2ff73bbb9f4bb5e49b5cabe2c156512e456056c/freettcn/lib/include/freettcn/etsi/tci.h. [^]
+
+Fixing all those problems will allow developers to provide error proof and consistent implementation across all TTCN interfaces. As an example please see: https://github.com/mpusz/FreeTTCN/blob/d2ff73bbb9f4bb5e49b5cabe2c156512e456056c/freettcn/lib/include/freettcn/ttcn3/ttcnArray.h. [^] Please note how easy and nice implementation can be done with well defined interface (TTCN_LIST_IFACE_FIXED case) and how problematic it is otherwise.
+
+Best
+
+Mat
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR_5949_resolution_v1.docx (44,940) 12-07-2012 17:17
http://oldforge.etsi.org/mantis/file_download.php?file_id=2693&type=bug
Issue History
Date ModifiedUsernameFieldChange
15-10-2011 19:18Mateusz PuszNew Issue
15-10-2011 19:18Mateusz PuszClause Reference(s) => TRI 8.5.2, TCI 10.5.2
15-10-2011 19:18Mateusz PuszSource (company - Author) => Mateusz Pusz/freettcn
28-11-2011 16:10Gyorgy RethyProjectTTCN-3 Change Requests => Part 06: TTCN-3 Control Interface
28-11-2011 16:11Gyorgy RethyNote Added: 0010357
28-11-2011 16:11Gyorgy RethyTarget Version => v4.7.1 (published 2015-06)
30-11-2011 11:02Ina SchieferdeckerStatusnew => assigned
30-11-2011 11:02Ina SchieferdeckerAssigned To => Ina Schieferdecker
12-07-2012 14:13Ina SchieferdeckerAssigned ToIna Schieferdecker => Tomas Urban
12-07-2012 17:17Tomas UrbanFile Added: CR_5949_resolution_v1.docx
12-07-2012 17:31Tomas UrbanNote Added: 0010901
12-07-2012 17:31Tomas UrbanAssigned ToTomas Urban => Ina Schieferdecker
13-07-2012 11:09Ina SchieferdeckerStatusassigned => resolved
13-07-2012 11:09Ina SchieferdeckerResolutionopen => fixed
13-07-2012 11:10Ina SchieferdeckerNote Added: 0010913
13-07-2012 11:10Ina SchieferdeckerStatusresolved => closed
13-07-2012 11:10Ina SchieferdeckerFixed in Version => Edition 4.5.1
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010357) +
+ Gyorgy Rethy    +
+ 28-11-2011 16:11    +
+ 		+ + + + +
+ Postponed to 2012. Proposal shall be checked with tool vendors.
+
+
+
+ + + + + + + + + + +
+ (0010901) +
+ Tomas Urban    +
+ 12-07-2012 17:31    +
+ 		+ + + + +
+ Although the proposed changes are very reasonable, they would lead to incompatibility with the previous versions of TRI/TCI C++ mapping. Changes of this character can be approved only if there's a serious functional issue in interface mapping.
+
+Thefore STF 446 made a decision to reject the CR with one exception: parameter type change from Tinteger to Tindex in TciValueDifferenceList.get method (see the attached draft).
+
+
+
+ + + + + + + + + + +
+ (0010913) +
+ Ina Schieferdecker    +
+ 13-07-2012 11:10    +
+ 		+ + + + +
+ Fixed as proposed.
+
+ + diff --git a/docs/mantis/CR5950.md b/docs/mantis/CR5950.md new file mode 100644 index 0000000000000000000000000000000000000000..57f4a07e7a8d728bd22a98a0dfa8c5d1df9a8305 --- /dev/null +++ b/docs/mantis/CR5950.md @@ -0,0 +1,72 @@ + + + + + + + + + + + + + 0005950: Misleading tab in float subclause - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005950Part 01: TTCN-3 Core LanguageEditorialpublic20-10-2011 15:2628-11-2011 13:00
ReporterGyorgy Rethy 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.4.1 (published 2012-04)Fixed in Versionv4.4.1 (published 2012-04) 
Clause Reference(s)$6.1.0
Source (company - Author)L.M.Ericsson
Summary0005950: Misleading tab in float subclause
DescriptionCurrent text is:
+"NOTE 1: In contrast to the general definition of float values, the mantissa of in theTTCN 3 value notation, beside integers, allows decimal numbers as well.
+
+    The special values of the float type consist of infinity (positive infinity), -infinity (negative infinity) and the value not_a_number. For the ordering of special values see clauses 7.1.17.1.1 and 7.1.37.1.3.
+
+NOTE 2: - not_a_number (i.e. minus not a number) is not to be used."
+
+The sentence "The special values ..." is aligned like it was part of NOTE 1, while this is a mandatory requirent (in the word document it is using the style "NO").
+
+It shall be formatted as "Normal" style.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
20-10-2011 15:26Gyorgy RethyNew Issue
20-10-2011 15:26Gyorgy RethyClause Reference(s) => $6.1.0
20-10-2011 15:26Gyorgy RethySource (company - Author) => L.M.Ericsson
20-10-2011 15:29Gyorgy RethySummaryMisleading tab in float => Misleading tab in float subclause
28-11-2011 12:50Gyorgy RethyProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
28-11-2011 12:51Gyorgy RethyAssigned To => Ina Schieferdecker
28-11-2011 12:51Gyorgy RethyStatusnew => assigned
28-11-2011 12:51Gyorgy RethyTarget Version => Edition 4.4.1
28-11-2011 13:00Ina SchieferdeckerNote Added: 0010344
28-11-2011 13:00Ina SchieferdeckerStatusassigned => resolved
28-11-2011 13:00Ina SchieferdeckerResolutionopen => fixed
28-11-2011 13:00Ina SchieferdeckerFixed in Version => Edition 4.4.1
28-11-2011 13:00Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010344) +
+ Ina Schieferdecker    +
+ 28-11-2011 13:00    +
+ 		+ + + + +
+ as proposed.
+
+ + diff --git a/docs/mantis/CR5952.md b/docs/mantis/CR5952.md new file mode 100644 index 0000000000000000000000000000000000000000..8030240c6b2bd0ba19e54163d1b42c12f92be557 --- /dev/null +++ b/docs/mantis/CR5952.md @@ -0,0 +1,77 @@ + + + + + + + + + + + + + 0005952: Assignment of a module parameter to a constant or another module parameter - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005952Part 01: TTCN-3 Core LanguageClarificationpublic27-10-2011 15:0828-11-2011 16:08
ReporterWolfgang Seka 
Assigned To 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionno change required 
PlatformOSOS Version
Product Version 
Target Versionv4.4.1 (published 2012-04)Fixed in Version 
Clause Reference(s)201 873-1 cl. 8.2.1 and/or cl. 10
Source (company - Author)stf160 - Wolfgang
Summary0005952: Assignment of a module parameter to a constant or another module parameter
DescriptionIt seems that
+
+     modulepar T m1;
+     const T m2 := m1;
+
+is not allowed in TTCN-3 but I've not found any clear statement in the core language (Note: the above example would allow aliases for module parameters what would be useful for maintenance reasons)
+
+Furthermore it seems not to be clear whether
+
+     modulepar T m1;
+     modulepar T m2 := m1;
+
+is allowed acc. to the core language.
+
+=> clarification is appreciated.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
27-10-2011 15:08Wolfgang SekaNew Issue
27-10-2011 15:08Wolfgang SekaClause Reference(s) => 201 873-1 cl. 8.2.1 and/or cl. 10
27-10-2011 15:08Wolfgang SekaSource (company - Author) => stf160 - Wolfgang
28-11-2011 16:05Gyorgy RethyProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
28-11-2011 16:08Gyorgy RethyNote Added: 0010356
28-11-2011 16:08Gyorgy RethyStatusnew => closed
28-11-2011 16:08Gyorgy RethyResolutionopen => no change required
28-11-2011 16:08Gyorgy RethyTarget Version => Edition 4.4.1
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010356) +
+ Gyorgy Rethy    +
+ 28-11-2011 16:08    +
+ 		+ + + + +
+ None of the above cases are forbidden, there is no error. Clause 10 declares constants are runtime constants.
+
+ + diff --git a/docs/mantis/CR5953.md b/docs/mantis/CR5953.md new file mode 100644 index 0000000000000000000000000000000000000000..3e548986c4a94a36b189cdc1d42709ab0536f8dc --- /dev/null +++ b/docs/mantis/CR5953.md @@ -0,0 +1,290 @@ + + + + + + + + + + + + + 0005953: String length in oct2str and oct2char predefined functions - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005953Part 01: TTCN-3 Core LanguageClarificationpublic28-10-2011 13:4110-07-2012 19:52
ReporterGyorgy Rethy 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.3.1 (published 2011-06) 
Target Versionv4.5.1 (published 2013-04)Fixed in Versionv4.5.1 (published 2013-04) 
Clause Reference(s)C.23 and C.24
Source (company - Author)L.M.Ericsson
Summary0005953: String length in oct2str and oct2char predefined functions
DescriptionThe textual description of the functions mentions just "length" without specifying what does it mean (i.e. no. of characters or what lenghtof would return).
+
+Proposed solution (different per function):
+C.23 Octetstring to character string
+...
+"The resulting charstring shall have the same length as the incoming octetstring." -> "The resulting charstring shall have the same number of characters as the incoming octetstring."
+
+C.24 Octetstring to character string, version II
+...
+"The resulting charstring shall have the same length as the input octetstring." -> "The resulting charstring shall have the same string length (what lenghtof would return) as the input octetstring."
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
28-10-2011 13:41Gyorgy RethyNew Issue
28-10-2011 13:41Gyorgy RethyClause Reference(s) => C.23 and C.24
28-10-2011 13:41Gyorgy RethySource (company - Author) => L.M.Ericsson
28-11-2011 09:46Jacob Wieland - SpirentNote Added: 0010329
28-11-2011 09:58Gyorgy RethyAssigned To => Ina Schieferdecker
28-11-2011 09:58Gyorgy RethyStatusnew => assigned
28-11-2011 09:58Gyorgy RethyTarget Version => Edition 4.4.1
28-11-2011 10:06Gyorgy RethyNote Added: 0010331
28-11-2011 10:07Gyorgy RethyAssigned ToIna Schieferdecker =>
28-11-2011 10:07Gyorgy RethyStatusassigned => new
28-11-2011 10:08Gyorgy RethyNote Edited: 0010331
28-11-2011 10:08Gyorgy RethyNote Edited: 0010331
28-11-2011 10:08Gyorgy RethyAssigned To => Ina Schieferdecker
28-11-2011 10:08Gyorgy RethyStatusnew => assigned
28-11-2011 10:39Jacob Wieland - SpirentNote Added: 0010337
28-11-2011 12:50Ina SchieferdeckerNote Added: 0010341
28-11-2011 12:50Ina SchieferdeckerAssigned ToIna Schieferdecker => Gyorgy Rethy
30-11-2011 11:04Gyorgy RethyNote Added: 0010431
30-11-2011 11:05Gyorgy RethyStatusassigned => resolved
02-12-2011 13:46Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
02-12-2011 13:46Gyorgy RethyStatusresolved => feedback
02-12-2011 13:46Gyorgy RethyResolutionopen => reopened
02-12-2011 13:46Gyorgy RethyNote Added: 0010521
02-12-2011 13:47Gyorgy RethyStatusfeedback => resolved
02-12-2011 13:47Gyorgy RethyResolutionreopened => fixed
02-12-2011 13:47Gyorgy RethyFixed in Version => Edition 4.4.1
09-07-2012 17:15Ina SchieferdeckerFixed in VersionEdition 4.4.1 =>
09-07-2012 17:15Ina SchieferdeckerTarget VersionEdition 4.4.1 => Edition 4.5.1
10-07-2012 19:52Ina SchieferdeckerNote Added: 0010781
10-07-2012 19:52Ina SchieferdeckerStatusresolved => closed
10-07-2012 19:52Ina SchieferdeckerFixed in Version => Edition 4.5.1
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010329) +
+ Jacob Wieland - Spirent    +
+ 28-11-2011 09:46    +
+ 		+ + + + +
+ I don't think that
+
+"The resulting charstring shall have the same string length (what lenghtof would return) as the input octetstring."
+
+would be correct as lengthof returns half the number of characters for octetstrings while for charstrings, it is obviously the number of characters.
+
+
+
+ + + + + + + + + + +
+ (0010331) +
+ Gyorgy Rethy    +
+ 28-11-2011 10:06    +
(edited on: 28-11-2011 10:08)
+ 		+ + + + +
+ For C.24 it is OK, but your explanation and the proposed text are contradicting for C.23; take the example from the standard: oct2str('4469707379'O) = "4469707379"
+lengthof('4469707379'O) -> results 5
+lengthof("4469707379") -> results 10
+lengthof doesn't return the same value for the octet~ and charstrings.
+
+
+
+
+
+ + + + + + + + + + +
+ (0010337) +
+ Jacob Wieland - Spirent    +
+ 28-11-2011 10:39    +
+ 		+ + + + +
+ Oh, I retract my comment as the proposal was about the oct2char function where, of course, lengthof(oct2char(xxx)) == lengthof(xxx)
+
+
+
+ + + + + + + + + + +
+ (0010341) +
+ Ina Schieferdecker    +
+ 28-11-2011 12:50    +
+ 		+ + + + +
+ I would propose:
+
+C.23: "The resulting charstring shall have double as many characters as the input octetstring has octets."
+
+C.24: "The resulting charstring shall have as many characters as the input octetstring has octets."
+
+
+
+ + + + + + + + + + +
+ (0010431) +
+ Gyorgy Rethy    +
+ 30-11-2011 11:04    +
+ 		+ + + + +
+ OK with me.
+
+
+
+ + + + + + + + + + +
+ (0010521) +
+ Gyorgy Rethy    +
+ 02-12-2011 13:46    +
+ 		+ + + + +
+ Reopening the CR just to assign to Ina.
+
+
+
+ + + + + + + + + + +
+ (0010781) +
+ Ina Schieferdecker    +
+ 10-07-2012 19:52    +
+ 		+ + + + +
+ Implemented as proposed.
+
+ + diff --git a/docs/mantis/CR5954.md b/docs/mantis/CR5954.md new file mode 100644 index 0000000000000000000000000000000000000000..7ee7233de60f6ed2797f17a6add392f819916ad0 --- /dev/null +++ b/docs/mantis/CR5954.md @@ -0,0 +1,275 @@ + + + + + + + + + + + + + 0005954: int2enum expected behavior is not fully specified - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005954Part 01: TTCN-3 Core LanguageClarificationpublic31-10-2011 16:4211-07-2012 11:23
ReporterAndras Kovacs 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.3.1 (published 2011-06) 
Target Versionv4.5.1 (published 2013-04)Fixed in Versionv4.5.1 (published 2013-04) 
Clause Reference(s)Core language / C.42
Source (company - Author)STF433
Summary0005954: int2enum expected behavior is not fully specified
DescriptionThe standard does not specify in section C.42 what should happen when the input integer does not correspond to any enum-value.
+comment: logical behavior would be to throw the test-case error
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
31-10-2011 16:42Andras KovacsNew Issue
31-10-2011 16:42Andras KovacsClause Reference(s) => Core language / C.42
31-10-2011 16:42Andras KovacsSource (company - Author) => STF433
28-11-2011 09:38Jacob Wieland - SpirentNote Added: 0010328
28-11-2011 10:35Jacob Wieland - SpirentNote Added: 0010335
28-11-2011 10:39Gyorgy RethyNote Added: 0010336
28-11-2011 15:50Gyorgy RethyAssigned To => Ina Schieferdecker
28-11-2011 15:50Gyorgy RethyStatusnew => assigned
28-11-2011 15:50Gyorgy RethyTarget Version => Edition 4.4.1
29-11-2011 10:10Ina SchieferdeckerNote Added: 0010375
29-11-2011 10:11Ina SchieferdeckerNote Added: 0010376
29-11-2011 10:11Ina SchieferdeckerAssigned ToIna Schieferdecker => Gyorgy Rethy
30-11-2011 10:59Gyorgy RethyNote Added: 0010429
30-11-2011 10:59Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
30-11-2011 10:59Gyorgy RethyStatusassigned => resolved
09-07-2012 17:17Ina SchieferdeckerTarget VersionEdition 4.4.1 => Edition 4.5.1
11-07-2012 11:23Ina SchieferdeckerNote Added: 0010830
11-07-2012 11:23Ina SchieferdeckerStatusresolved => closed
11-07-2012 11:23Ina SchieferdeckerResolutionopen => fixed
11-07-2012 11:23Ina SchieferdeckerFixed in Version => Edition 4.5.1
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010328) +
+ Jacob Wieland - Spirent    +
+ 28-11-2011 09:38    +
+ 		+ + + + +
+ Agreed. That was the intention.
+
+
+
+ + + + + + + + + + +
+ (0010335) +
+ Jacob Wieland - Spirent    +
+ 28-11-2011 10:35    +
+ 		+ + + + +
+ As a side-proposal, it would be useful if the int2enum function would also return the enum-value that it assigns to the out-parameter to allow it being used inside an expression or as a right-hand-side of an assignment or as argument to the select-construct, etc.. I.e. the return type of the function would always be the same as the type of the out parameter.
+
+
+
+ + + + + + + + + + +
+ (0010336) +
+ Gyorgy Rethy    +
+ 28-11-2011 10:39    +
+ 		+ + + + +
+ $16.1.2, restriction 2) defines
+2) each actual parameter shall evaluate to an element of its corresponding formal parameter's type;
+
+in the case of int2enum this is more tricky as the integer value shall correspond to an associated integer value of the out parameter's type. I propose to define this explicitly.
+
+
+
+ + + + + + + + + + +
+ (0010375) +
+ Ina Schieferdecker    +
+ 29-11-2011 10:10    +
+ 		+ + + + +
+ Change "The general error causes in clause 16.1.2 apply." to
+
+"In addition to the general error causes in clause 16.1.2, error causes are:
+
+- The integer value does not correspond to an associated integer value of the enumerated values in the enumerated type of the out parameter."
+
+
+
+ + + + + + + + + + +
+ (0010376) +
+ Ina Schieferdecker    +
+ 29-11-2011 10:11    +
+ 		+ + + + +
+ Please check resolution noted above.
+
+
+
+ + + + + + + + + + +
+ (0010429) +
+ Gyorgy Rethy    +
+ 30-11-2011 10:59    +
+ 		+ + + + +
+ Proposal OK.
+
+
+
+ + + + + + + + + + +
+ (0010830) +
+ Ina Schieferdecker    +
+ 11-07-2012 11:23    +
+ 		+ + + + +
+ Implemented as proposed.
+
+ + diff --git a/docs/mantis/CR5955.md b/docs/mantis/CR5955.md new file mode 100644 index 0000000000000000000000000000000000000000..38b408612854eaee285940a97dda64ad47c87716 --- /dev/null +++ b/docs/mantis/CR5955.md @@ -0,0 +1,65 @@ + + + + + + + + + + + + + 0005955: Syntax error in the example of section 6.1.2.3 - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005955Part 01: TTCN-3 Core LanguageEditorialpublic01-11-2011 14:4628-11-2011 12:52
ReporterAndras Kovacs 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.3.1 (published 2011-06) 
Target Versionv4.4.1 (published 2012-04)Fixed in Versionv4.4.1 (published 2012-04) 
Clause Reference(s)Core language / 6.1.2.3
Source (company - Author)STF 433
Summary0005955: Syntax error in the example of section 6.1.2.3
DescriptionThe first line in Example 1 is the following:
+type integer MyIntegerRange (0 .. 255); );
+The extra ");" characters should be removed from the end.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
01-11-2011 14:46Andras KovacsNew Issue
01-11-2011 14:46Andras KovacsClause Reference(s) => Core language / 6.1.2.3
01-11-2011 14:46Andras KovacsSource (company - Author) => STF 433
28-11-2011 12:49Gyorgy RethyAssigned To => Ina Schieferdecker
28-11-2011 12:49Gyorgy RethyStatusnew => assigned
28-11-2011 12:49Gyorgy RethyTarget Version => Edition 4.4.1
28-11-2011 12:52Ina SchieferdeckerNote Added: 0010342
28-11-2011 12:52Ina SchieferdeckerStatusassigned => resolved
28-11-2011 12:52Ina SchieferdeckerResolutionopen => fixed
28-11-2011 12:52Ina SchieferdeckerFixed in Version => Edition 4.4.1
28-11-2011 12:52Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010342) +
+ Ina Schieferdecker    +
+ 28-11-2011 12:52    +
+ 		+ + + + +
+ as proposed.
+
+ + diff --git a/docs/mantis/CR5956.md b/docs/mantis/CR5956.md new file mode 100644 index 0000000000000000000000000000000000000000..9f18ed914761a6d31563e9b62baed13b13331e07 --- /dev/null +++ b/docs/mantis/CR5956.md @@ -0,0 +1,40 @@ + + + + + + + + + + + + + 0005956: Syntax error in the example of section 15.8 - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005956Part 01: TTCN-3 Core LanguageTechnicalpublic01-11-2011 14:5528-11-2011 13:08
ReporterAndras Kovacs 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionduplicate 
PlatformOSOS Version
Product Versionv4.3.1 (published 2011-06) 
Target Versionv4.4.1 (published 2012-04)Fixed in Versionv4.4.1 (published 2012-04) 
Clause Reference(s)Core language / 15.8
Source (company - Author)STF 433
Summary0005956: Syntax error in the example of section 15.8
DescriptionThe 'restricted template usage' examples of this section are the following:
+
+var template ExampleType (omit) v_omit;
+var template ExampleType (present) v_present;
+var template ExampleType (value) v_value;
+
+The above notation is not correct, the correct expressions would be:
+
+var template (omit) ExampleType v_omit;
+var template (present) ExampleType v_present;
+var template (value) ExampleType v_value;
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0005869closed Ina Schieferdecker template restriction examples 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
01-11-2011 14:55Andras KovacsNew Issue
01-11-2011 14:55Andras KovacsClause Reference(s) => Core language / 15.8
01-11-2011 14:55Andras KovacsSource (company - Author) => STF 433
28-11-2011 12:48Gyorgy RethyAssigned To => Ina Schieferdecker
28-11-2011 12:48Gyorgy RethyStatusnew => assigned
28-11-2011 12:48Gyorgy RethyTarget Version => Edition 4.4.1
28-11-2011 13:07Ina SchieferdeckerRelationship addedrelated to 0005869
28-11-2011 13:08Ina SchieferdeckerStatusassigned => closed
28-11-2011 13:08Ina SchieferdeckerResolutionopen => duplicate
28-11-2011 13:08Ina SchieferdeckerFixed in Version => Edition 4.4.1
+
+ + + + +
+ There are no notes attached to this issue.
+ + diff --git a/docs/mantis/CR5957.md b/docs/mantis/CR5957.md new file mode 100644 index 0000000000000000000000000000000000000000..89500027c2cc958028a11e4333cc229efa8cd2ba --- /dev/null +++ b/docs/mantis/CR5957.md @@ -0,0 +1,139 @@ + + + + + + + + + + + + + 0005957: Wrong TciType::newInstance() C++ mapping - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005957Part 06: TTCN-3 Control InterfaceTechnicalpublic02-11-2011 07:3602-12-2011 12:54
ReporterMateusz Pusz 
Assigned ToIna Schieferdecker 
PrioritynormalSeveritymajorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.4.1 (published 2012-04)Fixed in Versionv4.4.1 (published 2012-04) 
Clause Reference(s)TCI 10.5.3.1
Source (company - Author)Mateusz Pusz/freettcn
Summary0005957: Wrong TciType::newInstance() C++ mapping
DescriptionTciType::newInstance() is a non-const method which makes it impossible to use in all the places where TciType is passed as cons pointer or reference. Some of such places are:
+- TciValue::getType()
+- RecordOfValue::getElementType()
+- tciCreateTestComponent()
+- getTypeForName(), getInteger(), getFloat()...
+
+In all those cases it is impossible to crate an instance of a type without the need to clone whole type for each operation. It is not a good approach in terms of performance and coding standards.
+
+Please make TciType::newInstance() a const method.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR5957.doc (74,240) 01-12-2011 15:27
http://oldforge.etsi.org/mantis/file_download.php?file_id=2647&type=bug
Issue History
Date ModifiedUsernameFieldChange
02-11-2011 07:36Mateusz PuszNew Issue
02-11-2011 07:36Mateusz PuszClause Reference(s) => TCI 10.5.3.1
02-11-2011 07:36Mateusz PuszSource (company - Author) => Mateusz Pusz/freettcn
28-11-2011 12:47Gyorgy RethyProjectTTCN-3 Change Requests => Part 06: TTCN-3 Control Interface
28-11-2011 15:45Gyorgy RethyAssigned To => Ina Schieferdecker
28-11-2011 15:45Gyorgy RethyStatusnew => assigned
28-11-2011 15:45Gyorgy RethyTarget Version => Edition 4.4.1
28-11-2011 15:47Gyorgy RethyNote Added: 0010355
01-12-2011 15:27Jacob Wieland - SpirentFile Added: CR5957.doc
01-12-2011 15:28Jacob Wieland - SpirentNote Added: 0010486
02-12-2011 12:53Ina SchieferdeckerNote Added: 0010516
02-12-2011 12:53Ina SchieferdeckerStatusassigned => resolved
02-12-2011 12:53Ina SchieferdeckerResolutionopen => fixed
02-12-2011 12:53Ina SchieferdeckerFixed in Version => Edition 4.4.1
02-12-2011 12:54Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010355) +
+ Gyorgy Rethy    +
+ 28-11-2011 15:47    +
+ 		+ + + + +
+ STF discussion 28/11: Discuss the proposal with MTP.
+
+
+
+ + + + + + + + + + +
+ (0010486) +
+ Jacob Wieland - Spirent    +
+ 01-12-2011 15:28    +
+ 		+ + + + +
+ Implemented as proposed.
+
+
+
+ + + + + + + + + + +
+ (0010516) +
+ Ina Schieferdecker    +
+ 02-12-2011 12:53    +
+ 		+ + + + +
+ as proposed.
+
+ + diff --git a/docs/mantis/CR5958.md b/docs/mantis/CR5958.md new file mode 100644 index 0000000000000000000000000000000000000000..1e852dc85b0b84b12658d03b940d3abf45cba565 --- /dev/null +++ b/docs/mantis/CR5958.md @@ -0,0 +1,352 @@ + + + + + + + + + + + + + 0005958: Example 4 of section 8.2.3.1 must be rewritten according to CR5607 - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005958Part 01: TTCN-3 Core LanguageTechnicalpublic02-11-2011 10:2011-07-2012 10:56
ReporterAndras Kovacs 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.3.1 (published 2011-06) 
Target Versionv4.4.1 (published 2012-04)Fixed in Version 
Clause Reference(s)Core language / 8.2.3.1
Source (company - Author)STF433
Summary0005958: Example 4 of section 8.2.3.1 must be rewritten according to CR5607
DescriptionBecause of CR5607, the example statements shown in Example 4 of section 8.2.3.1 will cause a test case error, so the text of the example must be rewritten accordingly
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0005607closed Ina Schieferdecker definitions of an enum type should not have the same name as an enum value in that type 
Attached Filesdoc CR5958.doc (133,632) 29-11-2011 11:09
http://oldforge.etsi.org/mantis/file_download.php?file_id=2596&type=bug
doc CR5958_v2.doc (142,848) 01-12-2011 13:27
http://oldforge.etsi.org/mantis/file_download.php?file_id=2641&type=bug
Issue History
Date ModifiedUsernameFieldChange
02-11-2011 10:20Andras KovacsNew Issue
02-11-2011 10:20Andras KovacsClause Reference(s) => Core language / 8.2.3.1
02-11-2011 10:20Andras KovacsSource (company - Author) => STF433
02-11-2011 10:26Andras KovacsNote Added: 0010324
02-11-2011 10:32Andras KovacsNote Added: 0010325
28-11-2011 09:33Jacob Wieland - SpirentNote Added: 0010327
28-11-2011 09:57Gyorgy RethyTarget Version => Edition 4.4.1
28-11-2011 15:38Ina SchieferdeckerRelationship addedrelated to 0005607
28-11-2011 15:43Gyorgy RethyAssigned To => Jacob Wieland - Spirent
28-11-2011 15:43Gyorgy RethyStatusnew => assigned
29-11-2011 11:09Jacob Wieland - SpirentFile Added: CR5958.doc
29-11-2011 11:16Jacob Wieland - SpirentNote Added: 0010381
29-11-2011 11:16Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
30-11-2011 11:00Gyorgy RethyNote Added: 0010430
30-11-2011 11:01Gyorgy RethyAssigned ToGyorgy Rethy => Jens Grabowski
01-12-2011 11:38Jens GrabowskiNote Added: 0010469
01-12-2011 11:39Jens GrabowskiAssigned ToJens Grabowski => Jacob Wieland - Spirent
01-12-2011 13:27Jacob Wieland - SpirentFile Added: CR5958_v2.doc
01-12-2011 13:28Jacob Wieland - SpirentNote Added: 0010477
01-12-2011 13:28Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Jens Grabowski
01-12-2011 13:32Jacob Wieland - SpirentAssigned ToJens Grabowski => Ina Schieferdecker
01-12-2011 13:33Jacob Wieland - SpirentStatusassigned => resolved
01-12-2011 13:33Jacob Wieland - SpirentResolutionopen => fixed
01-12-2011 13:33Jacob Wieland - SpirentNote Added: 0010478
11-07-2012 10:56Ina SchieferdeckerNote Added: 0010823
11-07-2012 10:56Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010324) +
+ Andras Kovacs    +
+ 02-11-2011 10:26    +
+ 		+ + + + +
+ Furthermore, the following paragraph must be removed from the text of section 8.2.3.1:
+
+"There is one exception to this rule: when in the context of an enumerated type (see clause 6.2.4), an enumeration value
+is clashing with the name of a definition in the importing module, the enumeration value shall take precedence and the
+definition in the importing module shall be referenced by using its qualified name (see example 4 below in this clause). "
+
+
+
+ + + + + + + + + + +
+ (0010325) +
+ Andras Kovacs    +
+ 02-11-2011 10:32    +
+ 		+ + + + +
+ Furthermore, the following sentence must be removed from Note 5 of section 8.2.3.1:
+
+"In particular, importing an enumerated type does not impose the restriction given in clause 6.2.4 on global names defined in the importing module."
+
+
+Furthermore, the following sentence must be removed from Note 6 of section 8.2.3.1:
+
+"Note that this implicit importing does not impose the restriction given in clause 6.2.4 on global names defined in module C."
+
+
+
+ + + + + + + + + + +
+ (0010327) +
+ Jacob Wieland - Spirent    +
+ 28-11-2011 09:33    +
+ 		+ + + + +
+ I agree with everything except the contents of the last note. I don't see th need to remove the sentences as they still apply: when importing an enumerated type, its enumerated field names do not restrict the names being defined in the importing module if they are of different types than the imported enumerated type (which is restricted by CR5607).
+
+
+
+ + + + + + + + + + +
+ (0010381) +
+ Jacob Wieland - Spirent    +
+ 29-11-2011 11:16    +
+ 		+ + + + +
+ uploaded proposal
+
+
+
+ + + + + + + + + + +
+ (0010430) +
+ Gyorgy Rethy    +
+ 30-11-2011 11:00    +
+ 		+ + + + +
+ Jens, pls. review.
+
+
+
+ + + + + + + + + + +
+ (0010469) +
+ Jens Grabowski    +
+ 01-12-2011 11:38    +
+ 		+ + + + +
+ Example:
+
+      const MyEnumType enumY := enumX; // this is not allowed as enumeration namesed values of type
+                                       // MyEnumType restrict names of definitions of that type only
+                                       // global names in module A only (see clause 6.2.4)
+
+is irritating. Possibly delete. Otherwise OK
+
+
+
+ + + + + + + + + + +
+ (0010477) +
+ Jacob Wieland - Spirent    +
+ 01-12-2011 13:28    +
+ 		+ + + + +
+ moved that part of the example to an example in the proper section
+
+
+
+ + + + + + + + + + +
+ (0010478) +
+ Jacob Wieland - Spirent    +
+ 01-12-2011 13:33    +
+ 		+ + + + +
+ Jens has confirmed the matter being resolved
+
+
+
+ + + + + + + + + + +
+ (0010823) +
+ Ina Schieferdecker    +
+ 11-07-2012 10:56    +
+ 		+ + + + +
+ Implemented as proposed in v2
+
+ + diff --git a/docs/mantis/CR5959.md b/docs/mantis/CR5959.md new file mode 100644 index 0000000000000000000000000000000000000000..16b2e2ee5d6d2ea58e60938704dea00a729ac273 --- /dev/null +++ b/docs/mantis/CR5959.md @@ -0,0 +1,342 @@ + + + + + + + + + + + + + 0005959: The localhost identification should be standardised in section 21.3.1 - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005959Part 01: TTCN-3 Core LanguageTechnicalpublic03-11-2011 09:2629-08-2013 17:04
ReporterAndras Kovacs 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.3.1 (published 2011-06) 
Target Versionv4.6.1 (published 2014-06)Fixed in Versionv4.6.1 (published 2014-06) 
Clause Reference(s)Core language / 21.3.1
Source (company - Author)STF433
Summary0005959: The localhost identification should be standardised in section 21.3.1
DescriptionThe creation of components now allows to specify a host id as well. It would be very beneficial to have a standardised way of referring to the localhost. This should be added into section 21.3.1.
+
+There are at least two ways in which the core language standard could be amended for achieving this:
+A: to have a pre-defined constant referring to the localhost (e.g. _LOCALHOST_ )
+B: to have a pre-defined function, which returns the charstring containing the localhost name (e.g. LocalhostName() )
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR_5959_resolution_v1.docx (44,078) 12-07-2012 09:49
http://oldforge.etsi.org/mantis/file_download.php?file_id=2683&type=bug
docx CR_5959_resolution_v2.docx (44,458) 13-07-2012 14:19
http://oldforge.etsi.org/mantis/file_download.php?file_id=2702&type=bug
doc CR5959-Resolution-Predef-Function-V1-JG.doc (72,192) 28-08-2013 15:50
http://oldforge.etsi.org/mantis/file_download.php?file_id=2871&type=bug
Issue History
Date ModifiedUsernameFieldChange
03-11-2011 09:26Andras KovacsNew Issue
03-11-2011 09:26Andras KovacsClause Reference(s) => Core language / 21.3.1
03-11-2011 09:26Andras KovacsSource (company - Author) => STF433
28-11-2011 12:45Gyorgy RethyTarget Version => Edition 4.4.1
28-11-2011 15:27Gyorgy RethyTarget VersionEdition 4.4.1 => v4.7.1 (published 2015-06)
28-11-2011 15:30Gyorgy RethyNote Added: 0010354
10-07-2012 14:49Gyorgy RethyNote Added: 0010764
10-07-2012 14:49Gyorgy RethyAssigned To => Tomas Urban
10-07-2012 14:49Gyorgy RethyStatusnew => assigned
12-07-2012 09:49Tomas UrbanFile Added: CR_5959_resolution_v1.docx
12-07-2012 09:51Tomas UrbanAssigned ToTomas Urban => Ina Schieferdecker
12-07-2012 09:51Tomas UrbanNote Added: 0010859
13-07-2012 12:26Ina SchieferdeckerNote Added: 0010918
13-07-2012 12:26Ina SchieferdeckerAssigned ToIna Schieferdecker => Tomas Urban
13-07-2012 14:19Tomas UrbanFile Added: CR_5959_resolution_v2.docx
13-07-2012 14:23Tomas UrbanNote Added: 0010929
13-07-2012 14:23Tomas UrbanAssigned ToTomas Urban => Ina Schieferdecker
13-07-2012 14:23Tomas UrbanStatusassigned => resolved
13-07-2012 14:23Tomas UrbanResolutionopen => fixed
06-08-2012 16:47Ina SchieferdeckerStatusresolved => closed
06-08-2012 16:47Ina SchieferdeckerFixed in Version => Edition 4.5.1
06-08-2012 16:47Ina SchieferdeckerNote Added: 0010977
22-01-2013 12:42Gyorgy RethyAssigned ToIna Schieferdecker =>
22-01-2013 12:42Gyorgy RethyStatusclosed => feedback
22-01-2013 12:42Gyorgy RethyResolutionfixed => reopened
22-01-2013 12:42Gyorgy RethyNote Added: 0011325
14-05-2013 15:26Gyorgy RethyTarget VersionEdition 4.5.1 => v4.7.1 (published 2015-06)
08-07-2013 15:53Jens GrabowskiStatusfeedback => assigned
08-07-2013 15:53Jens GrabowskiAssigned To => Jens Grabowski
08-07-2013 18:19Gyorgy RethyFixed in Versionv4.5.1 (published 2013-04) =>
28-08-2013 15:50Jens GrabowskiFile Added: CR5959-Resolution-Predef-Function-V1-JG.doc
28-08-2013 15:50Jens GrabowskiNote Added: 0011628
28-08-2013 15:51Jens GrabowskiAssigned ToJens Grabowski => Jacob Wieland - Spirent
29-08-2013 15:10Jacob Wieland - SpirentNote Added: 0011641
29-08-2013 15:10Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Ina Schieferdecker
29-08-2013 15:10Jacob Wieland - SpirentStatusassigned => confirmed
29-08-2013 17:03Ina SchieferdeckerNote Deleted: 0010977
29-08-2013 17:03Ina SchieferdeckerNote Added: 0011643
29-08-2013 17:03Ina SchieferdeckerStatusconfirmed => resolved
29-08-2013 17:03Ina SchieferdeckerResolutionreopened => fixed
29-08-2013 17:03Ina SchieferdeckerFixed in Version => v4.6.1 (published 2014-06)
29-08-2013 17:04Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010354) +
+ Gyorgy Rethy    +
+ 28-11-2011 15:30    +
+ 		+ + + + +
+ This CR is related to the broader topic of network addressing that requires more detailed discussion; as STF 430 has its last session this week, this topic will not be possible to be covered this week.
+
+
+
+ + + + + + + + + + +
+ (0010764) +
+ Gyorgy Rethy    +
+ 10-07-2012 14:49    +
+ 		+ + + + +
+ STF discussion 2012-07-10: go for the first option (macro), proposed text to be written.
+
+
+
+ + + + + + + + + + +
+ (0010859) +
+ Tomas Urban    +
+ 12-07-2012 09:51    +
+ 		+ + + + +
+ Please check.
+
+
+
+ + + + + + + + + + +
+ (0010918) +
+ Ina Schieferdecker    +
+ 13-07-2012 12:26    +
+ 		+ + + + +
+ __LOCALHOST__ better to return the system specific representation of localhost
+
+
+
+ + + + + + + + + + +
+ (0010929) +
+ Tomas Urban    +
+ 13-07-2012 14:23    +
+ 		+ + + + +
+ Changed the macro to produce system-dependent charstring. Please check.
+
+
+
+ + + + + + + + + + +
+ (0011325) +
+ Gyorgy Rethy    +
+ 22-01-2013 12:42    +
+ 		+ + + + +
+ CR is reopened. The macro solution is oposed by Testingtech: the macro/predef.function can be used in different contexts and the localhost IP address in not necessary known at compile time.
+György's comment (in addition): it may also be unknown compile time if the address to be returned is an IPv4 or IPv6 address, it is known runtime only.
+
+
+
+ + + + + + + + + + +
+ (0011628) +
+ Jens Grabowski    +
+ 28-08-2013 15:50    +
+ 		+ + + + +
+ New proposal with predefined function.
+
+Assigned to Jacob for proofreading.
+
+
+
+ + + + + + + + + + +
+ (0011641) +
+ Jacob Wieland - Spirent    +
+ 29-08-2013 15:10    +
+ 		+ + + + +
+ Fine with me.
+
+
+
+ + + + + + + + + + +
+ (0011643) +
+ Ina Schieferdecker    +
+ 29-08-2013 17:03    +
+ 		+ + + + +
+ As proposed.
+
+ + diff --git a/docs/mantis/CR5960.md b/docs/mantis/CR5960.md new file mode 100644 index 0000000000000000000000000000000000000000..feda4149c25deabdf806d0a952d39d0db9640066 --- /dev/null +++ b/docs/mantis/CR5960.md @@ -0,0 +1,67 @@ + + + + + + + + + + + + + 0005960: Syntax error in a check operation example - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005960Part 01: TTCN-3 Core LanguageEditorialpublic07-11-2011 09:2828-11-2011 13:49
ReporterGyorgy Rethy 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.4.1 (published 2012-04)Fixed in Versionv4.4.1 (published 2012-04) 
Clause Reference(s)22.4
Source (company - Author)L.M.Ericsson
Summary0005960: Syntax error in a check operation example
DescriptionIn clause 22.4 Note 2
+MyPort.check(receive) -> sender Mysender
+
+shall be corrected to
+MyPort.check(receive -> sender Mysender)
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
07-11-2011 09:28Gyorgy RethyNew Issue
07-11-2011 09:28Gyorgy RethyClause Reference(s) => 22.4
07-11-2011 09:28Gyorgy RethySource (company - Author) => L.M.Ericsson
28-11-2011 09:20Gyorgy RethyAssigned To => Ina Schieferdecker
28-11-2011 09:20Gyorgy RethyStatusnew => assigned
28-11-2011 09:20Gyorgy RethyTarget Version => Edition 4.4.1
28-11-2011 13:46Ina SchieferdeckerNote Added: 0010349
28-11-2011 13:49Ina SchieferdeckerStatusassigned => resolved
28-11-2011 13:49Ina SchieferdeckerResolutionopen => fixed
28-11-2011 13:49Ina SchieferdeckerFixed in Version => Edition 4.4.1
28-11-2011 13:49Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010349) +
+ Ina Schieferdecker    +
+ 28-11-2011 13:46    +
+ 		+ + + + +
+ as proposed. Changing also to MySender for better readability.
+
+ + diff --git a/docs/mantis/CR5961.md b/docs/mantis/CR5961.md new file mode 100644 index 0000000000000000000000000000000000000000..79f0147e3e32f494c42b5473e60422521d0274a6 --- /dev/null +++ b/docs/mantis/CR5961.md @@ -0,0 +1,485 @@ + + + + + + + + + + + + + 0005961: Table of template restrictions is wrong - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005961Part 01: TTCN-3 Core LanguageEditorialpublic21-11-2011 11:5409-08-2012 13:54
ReporterBogdan Stanca-Kaposta 
Assigned ToIna Schieferdecker 
PrioritynormalSeveritymajorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.5.1 (published 2013-04)Fixed in Versionv4.5.1 (published 2013-04) 
Clause Reference(s)15.8.c (page 121) of ETSI ES 201 873-1 V4.3.1 (2011-06)
Source (company - Author)STF 433
Summary0005961: Table of template restrictions is wrong
DescriptionThe Table 14: "Restricting modified templates" is wrong since the a template of a stronger constraint can always be safely modified (same as cast in object oriented languages) to a weaker constraint.
+
+e.g.
+
+ templates of kind template(omit) or template(value) can be modified to template(omit)
+ 
+ // definitions of restricted templates
+ type record ExampleType {
+    integer a,
+    boolean b optional
+ }
+ template(value) ExampleType exampleValue:= { 1, true };
+ template(present) ExampleType examplePresent modifies exampleValue := { a := ? };
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR5961_resolution_v1.doc (121,856) 19-07-2012 17:06
http://oldforge.etsi.org/mantis/file_download.php?file_id=2704&type=bug
Issue History
Date ModifiedUsernameFieldChange
21-11-2011 11:54Bogdan Stanca-KapostaNew Issue
21-11-2011 11:54Bogdan Stanca-KapostaClause Reference(s) => 15.8.c (page 121) of ETSI ES 201 873-1 V4.3.1 (2011-06)
21-11-2011 11:54Bogdan Stanca-KapostaSource (company - Author) => STF 433
28-11-2011 09:20Gyorgy RethyNote Added: 0010326
28-11-2011 09:27Gyorgy RethyProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
28-11-2011 09:38Gyorgy RethyNote Edited: 0010326
28-11-2011 09:38Gyorgy RethyTarget Version => Edition 4.4.1
28-11-2011 09:58Jacob Wieland - SpirentNote Added: 0010330
28-11-2011 15:21Gyorgy RethyNote Added: 0010353
29-11-2011 14:26Jacob Wieland - SpirentNote Added: 0010400
30-11-2011 10:49Gyorgy RethyNote Added: 0010427
30-11-2011 10:49Gyorgy RethyTarget VersionEdition 4.4.1 => v4.7.1 (published 2015-06)
10-07-2012 19:29Gyorgy RethyNote Added: 0010780
10-07-2012 19:29Gyorgy RethyStatusnew => closed
10-07-2012 19:29Gyorgy RethyResolutionopen => won't fix
11-07-2012 10:16Jacob Wieland - SpirentStatusclosed => feedback
11-07-2012 10:16Jacob Wieland - SpirentResolutionwon't fix => reopened
11-07-2012 10:16Jacob Wieland - SpirentNote Added: 0010808
12-07-2012 15:51Gyorgy RethyNote Added: 0010891
12-07-2012 16:11Jacob Wieland - SpirentNote Added: 0010894
12-07-2012 16:23Jacob Wieland - SpirentNote Edited: 0010894
19-07-2012 17:02Gyorgy RethyNote Added: 0010941
19-07-2012 17:02Gyorgy RethyStatusfeedback => assigned
19-07-2012 17:02Gyorgy RethyAssigned To => Gyorgy Rethy
19-07-2012 17:05Gyorgy RethyNote Edited: 0010941
19-07-2012 17:06Gyorgy RethyFile Added: CR5961_resolution_v1.doc
07-08-2012 15:44Jacob Wieland - SpirentNote Added: 0010985
09-08-2012 08:58Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
09-08-2012 08:58Gyorgy RethyStatusassigned => resolved
09-08-2012 08:58Gyorgy RethyResolutionreopened => fixed
09-08-2012 08:58Gyorgy RethyFixed in Version => Edition 4.5.1
09-08-2012 13:54Ina SchieferdeckerNote Added: 0011007
09-08-2012 13:54Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010326) +
+ Gyorgy Rethy    +
+ 28-11-2011 09:20    +
(edited on: 28-11-2011 09:38)
+ 		+ + + + +
+ In principle anything could be modified to anything else. The purpose of $15.8 restr. c) is to disallow this kind of anything-to-anything modification. Therefore anyone specifying a base template with a certain restriction can be sure that all children modified templates inherit the restriction and cannot override the limitation. Think about SW libraries, where both base templates and API functions are defined with a certain restriction in mind and API function calls cannot fail until the user of the API is calling the functions with modified templates based on the base templates of the lib.
+
+Anyone who wants to have modified templates with weaker restriction shall base them on a base template with weaker restriction.
+
+I propose is to reject the CR.
+
+
+
+
+
+ + + + + + + + + + +
+ (0010330) +
+ Jacob Wieland - Spirent    +
+ 28-11-2011 09:58    +
+ 		+ + + + +
+ First of all, weakening the restriction is NOT an "anything-to-anything" restriction, but a cleanly defined one. It is the only one which can be done safely without having to do additional checks on the modified template (other than in the strengthening restriction where the whole template needs to be re-evaluated to see if it fits the new stronger restriction).
+
+To keep the restriction of the template-to-be-modified or make it stronger in the modifying template does not make any sense whatsoever, in my opinion. If this CR is rejected, then I propose to not relate the restrictions of modified and modifying templates whatsoever as it is simply confusing that nonsensical relations are allowed and sensible ones are disallowed.
+
+In principle, from the user point-of-view, modifying templates is just a shortcut way or re-using already existing templates. The user should be free to use this feature to their best advantage (whatever that might be in different cases).
+
+
+
+ + + + + + + + + + +
+ (0010353) +
+ Gyorgy Rethy    +
+ 28-11-2011 15:21    +
+ 		+ + + + +
+ STF discussion 28/11: relaxing is requested due to a use case, where templates are derived from traces and those templates be used as bases for both sending and receiving. One option could be to require compatibility by definition in table 13. However, this would cause backward compatibility problems. the proposal needs further discussion to find a common solution. Add an example for both use cases.
+
+
+
+ + + + + + + + + + +
+ (0010400) +
+ Jacob Wieland - Spirent    +
+ 29-11-2011 14:26    +
+ 		+ + + + +
+ To summarize my understanding of the discussion:
+
+As far as I understood it, table 14 was introduced to add a restriction that should help the developer of a testsuite which uses some library api which requires certain restricted templates that should be derivations of some base template as parameters and should be safe in doing so.
+
+The argument is that if the restriction in Table 14 is lifted, tools would not be able to impose that restriction on the usage of the api, i.e. the user would be allowed to give templates derived from the base template which would have weaker restrictions than the base template, leading to potential problems at runtime. To avoid this, a non-syntactical relationship between the base template and the derived template is assumed such that the derived template can safely be used where ever the base-template could be used. It is assumed that other ways of ascertaining the safe usage of templates do not exist.
+
+In my opinion/experience, this is not true, as it is possible at compile time for most template expressions to determine whether they respect the demanded template restriction or not by inferring the *actual* template restriction of the expression. Only for those template expressions where this cannot be ascertained, so that the expression *maybe* can fulfill the restriction, a runtime check is necessary in all places where the restriction shall be imposed. In the case that the restriction *cannot* be fulfilled, a compile-time error can be issued. This will be the case (regardless of the removal of table 14) if, for instance, any *actual* present-, omit- or unrestricted-template is given as actual parameter to a value-template formal parameter and then used in its definition.
+
+The inference of the *actual* restriction of a template (in contrast to the *declared* template restriction) must take into account the template-restrictions of its formal parameters (if any) and the actual inferrable restriction of the base template (for derived templates) and of course the sub-expressions of the template.
+
+Even in the presence of table 14 it is not always possible to ascertain that a parameterized value-template that is derived from another value-template is an *actual* value-template (e.g. if it has unrestricted formal template parameters or uses unrestricted template variables). In that case, a runtime check to see if the demanded value-restriction is respected for an instantiation of that template must be done anyway.
+
+So, keeping the restrictions of table 14 does not achieve anything as templates that are declared as having the right restriction could still have the wrong restriction (depending on their parameter instantiations) while templates that have the wrong restriction declared but *could* have the right restriction, also depending on the instantiation of their parameters, cannot be rejected, either.
+
+For me, this can only lead to the conclusion that table 14 can be safely removed without any repercussions whatsoever. I will gladly revise my opinon if someone can show me a scenario where at compile-time it cannot be ascertained that a template-restriction is fulfilled if the restriction of table 14 is lifted where it could be ascertained if it was not.
+
+
+
+ + + + + + + + + + +
+ (0010427) +
+ Gyorgy Rethy    +
+ 30-11-2011 10:49    +
+ 		+ + + + +
+ As we have no consensus and only 3 days left from the STF's last working session, this issue has to be shifted to 2012.
+
+
+
+ + + + + + + + + + +
+ (0010780) +
+ Gyorgy Rethy    +
+ 10-07-2012 19:29    +
+ 		+ + + + +
+ Template restrictions was introduced on 3GPP request and be suitable to TF160's use cases. The current CR doesn't provide a use case, while changing the standard would need a reason.
+
+
+
+ + + + + + + + + + +
+ (0010808) +
+ Jacob Wieland - Spirent    +
+ 11-07-2012 10:16    +
+ 		+ + + + +
+ We provided a use case - see your own comment above. So, the CR still is warranted.
+
+
+
+ + + + + + + + + + +
+ (0010891) +
+ Gyorgy Rethy    +
+ 12-07-2012 15:51    +
+ 		+ + + + +
+ It was not my comment, it says "STF discussion 28/11": I have just noted what was told during a working meeting. The relation of this use case to the CR to be clarified, as any templates retrieved from traces can be defined as simple templates without restictions and to derive any other kind of templates from it - with or without restriction, as needed.
+
+
+
+ + + + + + + + + + +
+ (0010894) +
+ Jacob Wieland - Spirent    +
+ 12-07-2012 16:11    +
(edited on: 12-07-2012 16:23)
+ 		+ + + + +
+ Unfortunately, this is not true.
+
+If I do not generate the templates as value-templates - even though they ARE in effect value-templates -, then it is not allowed for me to use them in places where only value-templates are accepted. This is an unacceptable restriction.
+
+Thus, this would force me to generate the templates as unrestricted templates and then derive new value-restricted templates from them which do not change anything. Since the number of templates should be kept as small as possible for the purpose of usability and not cluttering of the namespace, this is also unacceptable.
+
+The main problem that I still have, though, is, that the table introduces this restriction to achieve a goal which is not achieved. This makes the table not only couterproductive to our use case, but useless for the use case it was introduced for, as well.
+
+
+
+
+
+ + + + + + + + + + +
+ (0010941) +
+ Gyorgy Rethy    +
+ 19-07-2012 17:02    +
(edited on: 19-07-2012 17:05)
+ 		+ + + + +
+ I have checked it with TF160 and lifting this limitation would not cause a problem for them. Therefore I'm not opposing any more, we can go ahead.
+
+See proposed solution in CR5961_resolution_v1.doc.
+
+
+
+
+
+ + + + + + + + + + +
+ (0010985) +
+ Jacob Wieland - Spirent    +
+ 07-08-2012 15:44    +
+ 		+ + + + +
+ I agree.
+
+
+
+ + + + + + + + + + +
+ (0011007) +
+ Ina Schieferdecker    +
+ 09-08-2012 13:54    +
+ 		+ + + + +
+ as proposed.
+
+ + diff --git a/docs/mantis/CR5962.md b/docs/mantis/CR5962.md new file mode 100644 index 0000000000000000000000000000000000000000..3fe638c6c566a7babe282a6d1a54929107139c85 --- /dev/null +++ b/docs/mantis/CR5962.md @@ -0,0 +1,74 @@ + + + + + + + + + + + + + 0005962: Equality operator missing in example - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005962Part 01: TTCN-3 Core LanguageEditorialpublic22-11-2011 16:0129-11-2011 14:11
ReporterGyorgy Rethy 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.3.1 (published 2011-06) 
Target Versionv4.4.1 (published 2012-04)Fixed in Versionv4.4.1 (published 2012-04) 
Clause Reference(s)C.30
Source (company - Author)L.M.Ericcson
Summary0005962: Equality operator missing in example
Descriptionin C.30, example
+    template MyPDU MyTemplate
+//_________________________________^ equality is missing here
+        { field1 := omit,
+          field2 := 5
+        };
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
22-11-2011 16:01Gyorgy RethyNew Issue
22-11-2011 16:01Gyorgy RethyClause Reference(s) => C.30
22-11-2011 16:01Gyorgy RethySource (company - Author) => L.M.Ericcson
28-11-2011 09:01Gyorgy RethyAssigned To => Ina Schieferdecker
28-11-2011 09:01Gyorgy RethyStatusnew => assigned
29-11-2011 14:10Ina SchieferdeckerNote Added: 0010397
29-11-2011 14:11Ina SchieferdeckerStatusassigned => resolved
29-11-2011 14:11Ina SchieferdeckerResolutionopen => fixed
29-11-2011 14:11Ina SchieferdeckerFixed in Version => Edition 4.4.1
29-11-2011 14:11Ina SchieferdeckerTarget Version => Edition 4.4.1
29-11-2011 14:11Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010397) +
+ Ina Schieferdecker    +
+ 29-11-2011 14:10    +
+ 		+ + + + +
+ Assignment operator added:
+
+    template MyPDU MyTemplate :=
+        { field1 := omit,
+          field2 := 5
+        };
+
+ + diff --git a/docs/mantis/CR5963.md b/docs/mantis/CR5963.md new file mode 100644 index 0000000000000000000000000000000000000000..4a34d6012d1a98bb43569ccdb070c5f846853864 --- /dev/null +++ b/docs/mantis/CR5963.md @@ -0,0 +1,98 @@ + + + + + + + + + + + + + 0005963: Examples given in section 27.1.2.1 should be revised - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005963Part 01: TTCN-3 Core LanguageTechnicalpublic23-11-2011 18:0629-11-2011 13:47
ReporterAndras Kovacs 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.4.1 (published 2012-04)Fixed in Versionv4.4.1 (published 2012-04) 
Clause Reference(s)Core language / section 27.1.2.1
Source (company - Author)STF433
Summary0005963: Examples given in section 27.1.2.1 should be revised
DescriptionThere is a technical issue with the example given in section 27.1.2.1: mismatch between MyType and MyCharstring? It seems that these two types are meant to be the same
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR5963.doc (78,336) 29-11-2011 11:58
http://oldforge.etsi.org/mantis/file_download.php?file_id=2600&type=bug
doc CR5963_v2.doc (79,360) 29-11-2011 13:47
http://oldforge.etsi.org/mantis/file_download.php?file_id=2603&type=bug
Issue History
Date ModifiedUsernameFieldChange
23-11-2011 18:06Andras KovacsNew Issue
23-11-2011 18:06Andras KovacsClause Reference(s) => Core language / section 27.1.2.1
23-11-2011 18:06Andras KovacsSource (company - Author) => STF433
28-11-2011 09:21Gyorgy RethyProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
28-11-2011 09:21Gyorgy RethyTarget Version => Edition 4.4.1
28-11-2011 14:12Gyorgy RethyAssigned To => Jacob Wieland - Spirent
28-11-2011 14:12Gyorgy RethyStatusnew => assigned
29-11-2011 11:58Jacob Wieland - SpirentNote Added: 0010387
29-11-2011 11:58Jacob Wieland - SpirentFile Added: CR5963.doc
29-11-2011 11:59Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Ina Schieferdecker
29-11-2011 13:44Ina SchieferdeckerNote Added: 0010392
29-11-2011 13:47Ina SchieferdeckerFile Added: CR5963_v2.doc
29-11-2011 13:47Ina SchieferdeckerStatusassigned => resolved
29-11-2011 13:47Ina SchieferdeckerResolutionopen => fixed
29-11-2011 13:47Ina SchieferdeckerFixed in Version => Edition 4.4.1
29-11-2011 13:47Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010387) +
+ Jacob Wieland - Spirent    +
+ 29-11-2011 11:58    +
+ 		+ + + + +
+ changed MyCharString to MyType
+
+
+
+ + + + + + + + + + +
+ (0010392) +
+ Ina Schieferdecker    +
+ 29-11-2011 13:44    +
+ 		+ + + + +
+ Changed MyCharstring and Mytype consistently to MyType
+
+ + diff --git a/docs/mantis/CR5964.md b/docs/mantis/CR5964.md new file mode 100644 index 0000000000000000000000000000000000000000..5c88da6b24ea43423c01349a2f90abd043aa92ec --- /dev/null +++ b/docs/mantis/CR5964.md @@ -0,0 +1,219 @@ + + + + + + + + + + + + + 0005964: Incorrect terminology in definition of the enumerated type - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005964Part 01: TTCN-3 Core LanguageEditorialpublic28-11-2011 10:3729-11-2011 10:52
ReporterTomas Urban 
Assigned ToIna Schieferdecker 
PrioritynormalSeveritytextReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.3.1 (published 2011-06) 
Target Versionv4.4.1 (published 2012-04)Fixed in Versionv4.4.1 (published 2012-04) 
Clause Reference(s)6.2.2
Source (company - Author)Elvior
Summary0005964: Incorrect terminology in definition of the enumerated type
DescriptionThe chapter 6.2.4 of the core language specification contains the following definition: "Enumerated types are used to model types that take only a distinct named set of values. Such distinct values are called enumerations."
+
+In my opinion, the term "enumeration" is used incorrectly. This term is usually used for the whole set of values, not for the individual values inside the enumerated type. See e.g. wikipedia definition of enumeration (http://en.wikipedia.org/wiki/Enumeration [^]) and enumerated type (http://en.wikipedia.org/wiki/Enumerated_type [^]) or definition of C++ enum type in Microsoft online documentation (http://msdn.microsoft.com/en-us/library/2dzy4k6e%28v=VS.100%29.aspx [^])
+
+Proposal:
+The correct term for distinct named values declared in the enumerated type shall be one of the following:
+- enumerator (that would be my personal pick)
+- enumerated/enumeration value (it is already in use in the specification e.g. in chapter 5.2.2)
+- enumerated/enumeration item
+- enumerated/enumeration member
+- enumerated/enumeration element
+
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Fileszip es_20187301v040303_Nov.zip (800,100) 29-11-2011 10:51
http://oldforge.etsi.org/mantis/file_download.php?file_id=2593&type=bug
Issue History
Date ModifiedUsernameFieldChange
28-11-2011 10:37Tomas UrbanNew Issue
28-11-2011 10:37Tomas UrbanClause Reference(s) => 6.2.2
28-11-2011 10:37Tomas UrbanSource (company - Author) => Elvior
28-11-2011 11:19Gyorgy RethyNote Added: 0010338
28-11-2011 11:20Gyorgy RethyTarget Version => Edition 4.4.1
28-11-2011 13:42Jacob Wieland - SpirentNote Added: 0010347
28-11-2011 14:11Gyorgy RethyNote Added: 0010352
28-11-2011 14:11Gyorgy RethyAssigned To => Ina Schieferdecker
28-11-2011 14:11Gyorgy RethyStatusnew => assigned
29-11-2011 10:25Ina SchieferdeckerNote Added: 0010377
29-11-2011 10:50Ina SchieferdeckerNote Added: 0010379
29-11-2011 10:51Ina SchieferdeckerFile Added: es_20187301v040303_Nov.zip
29-11-2011 10:51Ina SchieferdeckerStatusassigned => resolved
29-11-2011 10:51Ina SchieferdeckerResolutionopen => fixed
29-11-2011 10:51Ina SchieferdeckerFixed in Version => Edition 4.4.1
29-11-2011 10:52Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010338) +
+ Gyorgy Rethy    +
+ 28-11-2011 11:19    +
+ 		+ + + + +
+ To keep the terminology aligned with ASN.1, I propose the term "enumeration item" as this is used in X.680.
+
+
+
+ + + + + + + + + + +
+ (0010347) +
+ Jacob Wieland - Spirent    +
+ 28-11-2011 13:42    +
+ 		+ + + + +
+ I would stick with stomething that is already used.
+
+The occurrences I've found (in order or prominence) are:
+- enumeration value
+- enumerated value
+- enumeration name
+- enumeration identifier
+
+Therefore, I would think we should use enumeration value.
+
+
+
+ + + + + + + + + + +
+ (0010352) +
+ Gyorgy Rethy    +
+ 28-11-2011 14:11    +
+ 		+ + + + +
+ STF discussion 28/11: use enumerated value consistently throughout the standard.
+
+
+
+ + + + + + + + + + +
+ (0010377) +
+ Ina Schieferdecker    +
+ 29-11-2011 10:25    +
+ 		+ + + + +
+ Changed to "Enumerated types are used to model types that take only a distinct named set of values. Such distinct values are called enumerated values. Each enumerated value shall have an identifier. ... The identifiers of enumerated values shall be unique within the enumerated type (but do not have to be globally unique) and are consequently visible in the context of the given type only. The identifiers of enumerated values shall only be reused within other structured type definitions and shall not be used for identifiers of local or global visibility at the same or a lower level of the same branch of the scope hierarchy (see scope hierarchy in clause 5.2)."
+
+
+
+ + + + + + + + + + +
+ (0010379) +
+ Ina Schieferdecker    +
+ 29-11-2011 10:50    +
+ 		+ + + + +
+ Changed to "enumerated value" throughout the master document (see uploaded file, which however also contains numerous other CRs)
+
+ + diff --git a/docs/mantis/CR5965.md b/docs/mantis/CR5965.md new file mode 100644 index 0000000000000000000000000000000000000000..3b183a2de343749dcfe742160cb2d63264a7745c --- /dev/null +++ b/docs/mantis/CR5965.md @@ -0,0 +1,276 @@ + + + + + + + + + + + + + 0005965: Invalid reference to shift operator - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005965Part 01: TTCN-3 Core LanguageEditorialpublic28-11-2011 11:0129-11-2011 15:01
ReporterTomas Urban 
Assigned ToIna Schieferdecker 
PrioritynormalSeveritytextReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.3.1 (published 2011-06) 
Target Versionv4.4.1 (published 2012-04)Fixed in Versionv4.4.1 (published 2012-04) 
Clause Reference(s)11.1
Source (company - Author)Elvior
Summary0005965: Invalid reference to shift operator
DescriptionThis report is related to the intermediate draft of 4.3.2.
+
+Chapter 11.1 contains a new restriction e. The text of the restriction lists shift operators as one of those whose operands can contain partially initialized values. However, shift operators are not defined for any type that can have partially initialized values (see 7.1.6 for more details).
+
+Proposal:
+The reference to the shift operators should be removed from the list.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0005920closed Ina Schieferdecker Out parameter of int2enum need not be initialized 
Attached Filesdoc CR5965.doc (109,568) 29-11-2011 13:46
http://oldforge.etsi.org/mantis/file_download.php?file_id=2602&type=bug
doc CR5965-2.doc (118,272) 29-11-2011 14:58
http://oldforge.etsi.org/mantis/file_download.php?file_id=2607&type=bug
Issue History
Date ModifiedUsernameFieldChange
28-11-2011 11:01Tomas UrbanNew Issue
28-11-2011 11:01Tomas UrbanClause Reference(s) => 11.1
28-11-2011 11:01Tomas UrbanSource (company - Author) => Elvior
28-11-2011 12:27Jacob Wieland - SpirentNote Added: 0010339
28-11-2011 12:43Gyorgy RethyNote Added: 0010340
28-11-2011 12:44Gyorgy RethyTarget Version => Edition 4.4.1
28-11-2011 14:08Gyorgy RethyNote Added: 0010351
28-11-2011 14:09Gyorgy RethyAssigned To => Jacob Wieland - Spirent
28-11-2011 14:09Gyorgy RethyStatusnew => assigned
29-11-2011 12:20Jacob Wieland - SpirentNote Added: 0010388
29-11-2011 12:20Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Ina Schieferdecker
29-11-2011 13:22Jacob Wieland - SpirentFile Added: CR5965.doc
29-11-2011 13:33Ina SchieferdeckerRelationship addedrelated to 0005920
29-11-2011 13:34Ina SchieferdeckerNote Added: 0010391
29-11-2011 13:34Ina SchieferdeckerAssigned ToIna Schieferdecker => Jacob Wieland - Spirent
29-11-2011 13:46Jacob Wieland - SpirentFile Deleted: CR5965.doc
29-11-2011 13:46Jacob Wieland - SpirentFile Added: CR5965.doc
29-11-2011 13:47Jacob Wieland - SpirentNote Added: 0010393
29-11-2011 13:47Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Ina Schieferdecker
29-11-2011 14:49Ina SchieferdeckerNote Edited: 0010391
29-11-2011 14:56Ina SchieferdeckerNote Added: 0010402
29-11-2011 14:58Ina SchieferdeckerFile Added: CR5965-2.doc
29-11-2011 15:01Ina SchieferdeckerStatusassigned => resolved
29-11-2011 15:01Ina SchieferdeckerResolutionopen => fixed
29-11-2011 15:01Ina SchieferdeckerFixed in Version => Edition 4.4.1
29-11-2011 15:01Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010339) +
+ Jacob Wieland - Spirent    +
+ 28-11-2011 12:27    +
+ 		+ + + + +
+ Agreed. However, we have to check if we also mentioned the substr/replace functions to be allowed partially initialized lists.
+
+
+
+ + + + + + + + + + +
+ (0010340) +
+ Gyorgy Rethy    +
+ 28-11-2011 12:43    +
+ 		+ + + + +
+ Correct
+
+
+
+ + + + + + + + + + +
+ (0010351) +
+ Gyorgy Rethy    +
+ 28-11-2011 14:08    +
+ 		+ + + + +
+ STF discussion 28/11: OK to delete shift in $11.1. Add "in" parameters and substr and replace to $16.1.2 Restr. a) 3).
+
+
+
+ + + + + + + + + + +
+ (0010388) +
+ Jacob Wieland - Spirent    +
+ 29-11-2011 12:20    +
+ 		+ + + + +
+ added ispresent,ischosen,isbound, lengthof, replace, substr
+
+could not remove shift (as it was not introduced in 4.3.1. yet which I worked on) - must be merged with other changes (if any) from 4.3.2.
+
+
+
+ + + + + + + + + + +
+ (0010391) +
+ Ina Schieferdecker    +
+ 29-11-2011 13:34    +
(edited on: 29-11-2011 14:49)
+ 		+ + + + +
+ The changes to 16.1.2 need to be merged with the resolution to CR5920
+
+
+
+
+
+ + + + + + + + + + +
+ (0010393) +
+ Jacob Wieland - Spirent    +
+ 29-11-2011 13:47    +
+ 		+ + + + +
+ old proposal deleted, new version uploaded
+
+
+
+ + + + + + + + + + +
+ (0010402) +
+ Ina Schieferdecker    +
+ 29-11-2011 14:56    +
+ 		+ + + + +
+ small extensions to the text in 16.1.2
+
+ + diff --git a/docs/mantis/CR5966.md b/docs/mantis/CR5966.md new file mode 100644 index 0000000000000000000000000000000000000000..e7c72a04debc471b7017434f1fa389ac287bda35 --- /dev/null +++ b/docs/mantis/CR5966.md @@ -0,0 +1,104 @@ + + + + + + + + + + + + + 0005966: Invalid syntax in 6.2 example 5 - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005966Part 01: TTCN-3 Core LanguageEditorialpublic28-11-2011 12:5330-11-2011 09:19
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeveritytextReproducibilityN/A
StatusclosedResolutionduplicate 
PlatformOSOS Version
Product Versionv4.3.1 (published 2011-06) 
Target Versionv4.4.1 (published 2012-04)Fixed in Versionv4.4.1 (published 2012-04) 
Clause Reference(s)6.2, example 5
Source (company - Author)Elvior
Summary0005966: Invalid syntax in 6.2 example 5
DescriptionThis report is related to the interim draft of 4.3.2 specs.
+
+The example 5 in 6.2 contains variable declarations with a with clause. However, the current standard does not allow using the with clause in variable declarations (BNF, rule 247).
+
+Proposal:
+const should be used instead of var.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0005928closed Ina Schieferdecker ETSI ES 201 873-1 6.2 example 5: syntactically incorrect 
related to 0005937closed Ina Schieferdecker Generalize annotation of attributes to declarations/members. 
Attached Filesdocx CR5966.docx (21,424) 29-11-2011 11:04
http://oldforge.etsi.org/mantis/file_download.php?file_id=2595&type=bug
docx CR5966_v2.docx (21,491) 29-11-2011 11:18
http://oldforge.etsi.org/mantis/file_download.php?file_id=2597&type=bug
Issue History
Date ModifiedUsernameFieldChange
28-11-2011 12:53Tomas UrbanNew Issue
28-11-2011 12:53Tomas UrbanClause Reference(s) => 6.2, example 5
28-11-2011 12:53Tomas UrbanSource (company - Author) => Elvior
28-11-2011 13:40Gyorgy RethyAssigned To => Ina Schieferdecker
28-11-2011 13:40Gyorgy RethyStatusnew => assigned
28-11-2011 13:40Gyorgy RethyTarget Version => Edition 4.4.1
29-11-2011 08:07Ina SchieferdeckerNote Added: 0010367
29-11-2011 09:27Ina SchieferdeckerFile Added: CR5966.docx
29-11-2011 09:27Ina SchieferdeckerAssigned ToIna Schieferdecker => Gyorgy Rethy
29-11-2011 09:27Ina SchieferdeckerNote Added: 0010371
29-11-2011 09:28Ina SchieferdeckerNote Edited: 0010371
29-11-2011 11:04Ina SchieferdeckerFile Deleted: CR5966.docx
29-11-2011 11:04Ina SchieferdeckerFile Added: CR5966.docx
29-11-2011 11:04Ina SchieferdeckerRelationship addedrelated to 0005937
29-11-2011 11:18Ina SchieferdeckerFile Added: CR5966_v2.docx
29-11-2011 15:51Ina SchieferdeckerRelationship addedrelated to 0005923
29-11-2011 15:51Ina SchieferdeckerRelationship deletedrelated to 0005923
30-11-2011 09:18Ina SchieferdeckerRelationship addedrelated to 0005928
30-11-2011 09:19Ina SchieferdeckerStatusassigned => closed
30-11-2011 09:19Ina SchieferdeckerResolutionopen => duplicate
30-11-2011 09:19Ina SchieferdeckerFixed in Version => Edition 4.4.1
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010367) +
+ Ina Schieferdecker    +
+ 29-11-2011 08:07    +
+ 		+ + + + +
+ STF 430 agreed to allow with arguments for local definitions in control, test cases, functions, altsteps, and statement blocks.
+
+
+
+ + + + + + + + + + +
+ (0010371) +
+ Ina Schieferdecker    +
+ 29-11-2011 09:27    +
(edited on: 29-11-2011 09:28)
+ 		+ + + + +
+ Please check resolution in CR5966.docx.
+
+
+
+ + diff --git a/docs/mantis/CR5967.md b/docs/mantis/CR5967.md new file mode 100644 index 0000000000000000000000000000000000000000..e619161dbbc8fb9f09dc77ae4b159330c1a84221 --- /dev/null +++ b/docs/mantis/CR5967.md @@ -0,0 +1,68 @@ + + + + + + + + + + + + + 0005967: IsChosen: invalid reference to value list - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005967Part 01: TTCN-3 Core LanguageEditorialpublic28-11-2011 13:0328-11-2011 13:59
ReporterTomas Urban 
Assigned To 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionwon't fix 
PlatformOSOS Version
Product Versionv4.3.1 (published 2011-06) 
Target Versionv4.4.1 (published 2012-04)Fixed in Version 
Clause Reference(s)C.32
Source (company - Author)Elvior
Summary0005967: IsChosen: invalid reference to value list
DescriptionThe following sentence in the chapter C.32 (function ischosen) contains a reference to a value list:
+"The function ischosen is applicable to templates of union types containing a specific value or a value list."
+
+Value lists are not valid values of union types. I think the author of this rule most likely wanted to write "list template" instead, which is a valid operand of the ischosen function as it is demonstrated in the examples. The terms are very similar, so it is easy to make this kind of mistake.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
28-11-2011 13:03Tomas UrbanNew Issue
28-11-2011 13:03Tomas UrbanClause Reference(s) => C.32
28-11-2011 13:03Tomas UrbanSource (company - Author) => Elvior
28-11-2011 13:45Gyorgy RethyNote Added: 0010348
28-11-2011 13:46Gyorgy RethyTarget Version => Edition 4.4.1
28-11-2011 13:59Gyorgy RethyStatusnew => closed
28-11-2011 13:59Gyorgy RethyResolutionopen => won't fix
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010348) +
+ Gyorgy Rethy    +
+ 28-11-2011 13:45    +
+ 		+ + + + +
+ The standard meant value list, i.e. the value list matching (as in $B.1.2.1). See example
+    template U t_U5 := ({ f2 := ’12?’O }, { f2 := ’*34’O length(2) })
+    ischosen(t_U5.f2) // returns true
+
+ + diff --git a/docs/mantis/CR5968.md b/docs/mantis/CR5968.md new file mode 100644 index 0000000000000000000000000000000000000000..4624487abdfa72792399c14da46250b3d0e7d621 --- /dev/null +++ b/docs/mantis/CR5968.md @@ -0,0 +1,67 @@ + + + + + + + + + + + + + 0005968: Invalid syntax in C.38 - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005968Part 01: TTCN-3 Core LanguageEditorialpublic28-11-2011 13:0829-11-2011 14:19
ReporterTomas Urban 
Assigned ToIna Schieferdecker 
PrioritynormalSeveritytrivialReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.3.1 (published 2011-06) 
Target Versionv4.4.1 (published 2012-04)Fixed in Versionv4.4.1 (published 2012-04) 
Clause Reference(s)C.32
Source (company - Author)Elvior
Summary0005968: Invalid syntax in C.38
DescriptionThe examples 4 and 5 (present only in 4.3.2 draft) in C.38 contain the following variable declaration:
+
+var MyUnion vl_ MyUnion;
+
+The declaration contains space in the variable name causing compilers to produce a syntax error. However, the variable is not used in any of the examples, so I propose to delete the declaration completely.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
28-11-2011 13:08Tomas UrbanNew Issue
28-11-2011 13:08Tomas UrbanClause Reference(s) => C.32
28-11-2011 13:08Tomas UrbanSource (company - Author) => Elvior
28-11-2011 13:39Gyorgy RethyAssigned To => Ina Schieferdecker
28-11-2011 13:39Gyorgy RethyStatusnew => assigned
28-11-2011 13:39Gyorgy RethyTarget Version => Edition 4.4.1
29-11-2011 14:17Ina SchieferdeckerNote Added: 0010399
29-11-2011 14:19Ina SchieferdeckerStatusassigned => resolved
29-11-2011 14:19Ina SchieferdeckerResolutionopen => fixed
29-11-2011 14:19Ina SchieferdeckerFixed in Version => Edition 4.4.1
29-11-2011 14:19Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010399) +
+ Ina Schieferdecker    +
+ 29-11-2011 14:17    +
+ 		+ + + + +
+ as proposed.
+
+ + diff --git a/docs/mantis/CR5969.md b/docs/mantis/CR5969.md new file mode 100644 index 0000000000000000000000000000000000000000..3f1aae8647b816488b85c15491f69985587d35b4 --- /dev/null +++ b/docs/mantis/CR5969.md @@ -0,0 +1,69 @@ + + + + + + + + + + + + + 0005969: Invalid value reference in isbound function, example 1 - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005969Part 01: TTCN-3 Core LanguageEditorialpublic28-11-2011 13:1429-11-2011 14:14
ReporterTomas Urban 
Assigned ToIna Schieferdecker 
PrioritynormalSeveritytrivialReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.3.1 (published 2011-06) 
Target Versionv4.4.1 (published 2012-04)Fixed in Versionv4.4.1 (published 2012-04) 
Clause Reference(s)C.43
Source (company - Author)Elvior
Summary0005969: Invalid value reference in isbound function, example 1
DescriptionThis report is related to the interim draft of 4.3.2 specs.
+
+The example 1 in C.43 (isbound function) contains the following line:
+
+isbound(v_char);
+
+However, no such variable is declared in the example. The correct variable name should be vlt_char.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
28-11-2011 13:14Tomas UrbanNew Issue
28-11-2011 13:14Tomas UrbanClause Reference(s) => C.43
28-11-2011 13:14Tomas UrbanSource (company - Author) => Elvior
28-11-2011 13:38Gyorgy RethyAssigned To => Ina Schieferdecker
28-11-2011 13:38Gyorgy RethyStatusnew => assigned
28-11-2011 13:38Gyorgy RethyTarget Version => Edition 4.4.1
29-11-2011 14:13Ina SchieferdeckerNote Added: 0010398
29-11-2011 14:14Ina SchieferdeckerStatusassigned => resolved
29-11-2011 14:14Ina SchieferdeckerResolutionopen => fixed
29-11-2011 14:14Ina SchieferdeckerFixed in Version => Edition 4.4.1
29-11-2011 14:14Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010398) +
+ Ina Schieferdecker    +
+ 29-11-2011 14:13    +
+ 		+ + + + +
+ as proposed.
+
+ + diff --git a/docs/mantis/CR5970.md b/docs/mantis/CR5970.md new file mode 100644 index 0000000000000000000000000000000000000000..ac58465b8fed929db726ae5848fe1f8a3dd9179b --- /dev/null +++ b/docs/mantis/CR5970.md @@ -0,0 +1,103 @@ + + + + + + + + + + + + + 0005970: Interleave restriction, function calls - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005970Part 01: TTCN-3 Core LanguageTechnicalpublic28-11-2011 13:3130-11-2011 09:16
ReporterTomas Urban 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.3.1 (published 2011-06) 
Target Versionv4.4.1 (published 2012-04)Fixed in Versionv4.4.1 (published 2012-04) 
Clause Reference(s)20.4, restriction a
Source (company - Author)Elvior
Summary0005970: Interleave restriction, function calls
DescriptionIn the chapter 20.4 (defining the interleave statement), the restriction a contains the following text:
+
+...user-defined functions, which include communication operations, shall not be used in interleave statements.
+
+I think "communication operations" should be replaced with "reception statements". I don't see any reason to forbid functions that e.g. send messages, because they don't affect interleave functionality. On the other hand, it seems quite strange to permit function call containg e.g. timeouts which would, if not used inside a function call, affect interleave functionality.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
28-11-2011 13:31Tomas UrbanNew Issue
28-11-2011 13:31Tomas UrbanClause Reference(s) => 20.4, restriction a
28-11-2011 13:31Tomas UrbanSource (company - Author) => Elvior
28-11-2011 13:36Gyorgy RethyTarget Version => Edition 4.4.1
28-11-2011 13:54Gyorgy RethyNote Added: 0010350
28-11-2011 13:54Gyorgy RethyNote Edited: 0010350
28-11-2011 13:54Gyorgy RethyAssigned To => Ina Schieferdecker
28-11-2011 13:54Gyorgy RethyStatusnew => assigned
30-11-2011 09:15Ina SchieferdeckerNote Added: 0010413
30-11-2011 09:16Ina SchieferdeckerStatusassigned => resolved
30-11-2011 09:16Ina SchieferdeckerResolutionopen => fixed
30-11-2011 09:16Ina SchieferdeckerFixed in Version => Edition 4.4.1
30-11-2011 09:16Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010350) +
+ Gyorgy Rethy    +
+ 28-11-2011 13:54    +
+ 		+ + + + +
+ STF discussion 28/11: change "communication operations" to "reception statements".
+
+
+
+
+
+ + + + + + + + + + +
+ (0010413) +
+ Ina Schieferdecker    +
+ 30-11-2011 09:15    +
+ 		+ + + + +
+ as proposed.
+
+ + diff --git a/docs/mantis/CR5971.md b/docs/mantis/CR5971.md new file mode 100644 index 0000000000000000000000000000000000000000..d58f65260e8ff539cdf04429576872a4332fdddb --- /dev/null +++ b/docs/mantis/CR5971.md @@ -0,0 +1,72 @@ + + + + + + + + + + + + + 0005971: 6.1.5, example 1: invalid transformation - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005971Part 09: Using XML with TTCN-3Editorialpublic28-11-2011 14:1530-11-2011 10:58
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeveritytextReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.3.1 (published 2011-06) 
Target Versionv4.4.1 (published 2012-04)Fixed in Versionv4.4.1 (published 2012-04) 
Clause Reference(s)6.1.5, example 1
For STF discussion
Source (company - Author)Elvior
Summary0005971: 6.1.5, example 1: invalid transformation
DescriptionThe example 1 in 6.1.5 contains an error in the TTCN-3 code part. The second enumerated item identifier is "on", but such an identifier is invalid, because it is a restricted word in TTCN-3. Correctly applied name transformation rules as defined in 5.2.2 would yield the following code:
+
+type enumerated State {off, on_ }
+with {
+    variant "name as uncapitalized"
+    variant "text 'on_' as 'on'";
+}
+
+
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
28-11-2011 14:15Tomas UrbanNew Issue
28-11-2011 14:15Tomas UrbanClause Reference(s) => 6.1.5, example 1
28-11-2011 14:15Tomas UrbanSource (company - Author) => Elvior
28-11-2011 16:40Gyorgy RethyAssigned To => Gyorgy Rethy
28-11-2011 16:40Gyorgy RethyStatusnew => assigned
28-11-2011 16:40Gyorgy RethyTarget Version => Edition 4.4.1
30-11-2011 10:58Gyorgy RethyStatusassigned => closed
30-11-2011 10:58Gyorgy RethyNote Added: 0010428
30-11-2011 10:58Gyorgy RethyResolutionopen => fixed
30-11-2011 10:58Gyorgy RethyFixed in Version => Edition 4.4.1
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010428) +
+ Gyorgy Rethy    +
+ 30-11-2011 10:58    +
+ 		+ + + + +
+ Corrected in the master copy v4.3.3
+
+ + diff --git a/docs/mantis/CR5972.md b/docs/mantis/CR5972.md new file mode 100644 index 0000000000000000000000000000000000000000..2a419450df49fd583ba98de7fc3f44b9ed013f74 --- /dev/null +++ b/docs/mantis/CR5972.md @@ -0,0 +1,101 @@ + + + + + + + + + + + + + 0005972: Transformed decimal type constraint - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005972Part 09: Using XML with TTCN-3Editorialpublic28-11-2011 14:2802-12-2011 11:16
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeveritytextReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.3.1 (published 2011-06) 
Target Versionv4.4.1 (published 2012-04)Fixed in Versionv4.4.1 (published 2012-04) 
Clause Reference(s)6.4.1
For STF discussion
Source (company - Author)Elvior
Summary0005972: Transformed decimal type constraint
DescriptionThe TTCN-3 type used for representing xsd:decimal type should be constrained to exclude positive and negative infinity and not a value:
+
+type float Decimal (!-infinity .. !infinity)
+
+See specification of the xsd:decimal in the chapter 3.2.3 of the XML Schema Part 2: Datatypes specification for more details.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
28-11-2011 14:28Tomas UrbanNew Issue
28-11-2011 14:28Tomas UrbanClause Reference(s) => 6.4.1
28-11-2011 14:28Tomas UrbanSource (company - Author) => Elvior
28-11-2011 16:38Gyorgy RethyNote Added: 0010366
28-11-2011 16:39Gyorgy RethyAssigned To => Gyorgy Rethy
28-11-2011 16:39Gyorgy RethyStatusnew => assigned
28-11-2011 16:39Gyorgy RethyTarget Version => Edition 4.4.1
02-12-2011 11:16Gyorgy RethyNote Added: 0010511
02-12-2011 11:16Gyorgy RethyStatusassigned => closed
02-12-2011 11:16Gyorgy RethyResolutionopen => fixed
02-12-2011 11:16Gyorgy RethyFixed in Version => Edition 4.4.1
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010366) +
+ Gyorgy Rethy    +
+ 28-11-2011 16:38    +
+ 		+ + + + +
+ STF discussion 28/11: to be checked.
+
+
+
+ + + + + + + + + + +
+ (0010511) +
+ Gyorgy Rethy    +
+ 02-12-2011 11:16    +
+ 		+ + + + +
+ Implemented as proposed.
+
+ + diff --git a/docs/mantis/CR5973.md b/docs/mantis/CR5973.md new file mode 100644 index 0000000000000000000000000000000000000000..396b7b323ad7c233726e5ca709a2589323dfcd65 --- /dev/null +++ b/docs/mantis/CR5973.md @@ -0,0 +1,176 @@ + + + + + + + + + + + + + 0005973: XmlCompatibleString: invalid constraint - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005973Part 09: Using XML with TTCN-3Editorialpublic28-11-2011 14:3602-12-2011 11:24
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeveritymajorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.4.1 (published 2012-04)Fixed in Versionv4.4.1 (published 2012-04) 
Clause Reference(s)Annex A
For STF discussion
Source (company - Author)Elvior
Summary0005973: XmlCompatibleString: invalid constraint
DescriptionThe annex A contains an invalid contraint for the XmlCompatibleString type:
+char(0,0,0,12)..char(0,0,0,12)
+
+This references the "form feed" character, which is not allowed by the Extensible Markup Language specification (chapter 2.2) for values of this type. The set of allowed values includes however the "line feed" character, which is missing from the constraint.
+
+
+Proposal:
+Change the incorrect part of the constraint to: char(0,0,0,13)..char(0,0,0,13)
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR5973.doc (92,672) 29-11-2011 08:35
http://oldforge.etsi.org/mantis/file_download.php?file_id=2589&type=bug
Issue History
Date ModifiedUsernameFieldChange
28-11-2011 14:36Tomas UrbanNew Issue
28-11-2011 14:36Tomas UrbanClause Reference(s) => Annex A
28-11-2011 14:36Tomas UrbanSource (company - Author) => Elvior
28-11-2011 16:37Gyorgy RethyNote Added: 0010365
28-11-2011 16:38Gyorgy RethyAssigned To => Jacob Wieland - Spirent
28-11-2011 16:38Gyorgy RethyStatusnew => assigned
28-11-2011 16:38Gyorgy RethyTarget Version => Edition 4.4.1
29-11-2011 08:28Jacob Wieland - SpirentNote Added: 0010368
29-11-2011 08:35Jacob Wieland - SpirentFile Added: CR5973.doc
29-11-2011 08:36Jacob Wieland - SpirentNote Added: 0010369
29-11-2011 08:36Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Ina Schieferdecker
29-11-2011 08:37Jacob Wieland - SpirentAssigned ToIna Schieferdecker => Gyorgy Rethy
02-12-2011 11:24Gyorgy RethyNote Added: 0010512
02-12-2011 11:24Gyorgy RethyStatusassigned => closed
02-12-2011 11:24Gyorgy RethyResolutionopen => fixed
02-12-2011 11:24Gyorgy RethyFixed in Version => Edition 4.4.1
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010365) +
+ Gyorgy Rethy    +
+ 28-11-2011 16:37    +
+ 		+ + + + +
+ STF discussion 28/11: to be checked.
+
+
+
+ + + + + + + + + + +
+ (0010368) +
+ Jacob Wieland - Spirent    +
+ 29-11-2011 08:28    +
+ 		+ + + + +
+ Allowed characters are indeed only the following:
+
+Char ::= #x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000-#xFFFD] | [#x10000-#x10FFFF]
+
+Therefore, I will change 12 to 13 according to proposal.
+
+
+
+ + + + + + + + + + +
+ (0010369) +
+ Jacob Wieland - Spirent    +
+ 29-11-2011 08:36    +
+ 		+ + + + +
+ uploaded proposal where 12 is replaced by 13 in the relevant places.
+
+
+
+ + + + + + + + + + +
+ (0010512) +
+ Gyorgy Rethy    +
+ 02-12-2011 11:24    +
+ 		+ + + + +
+ Implemented as proposed, both in clause 6.2 and annex A
+
+ + diff --git a/docs/mantis/CR5974.md b/docs/mantis/CR5974.md new file mode 100644 index 0000000000000000000000000000000000000000..839927331279b1151384ce216eddf799b1000b9f --- /dev/null +++ b/docs/mantis/CR5974.md @@ -0,0 +1,101 @@ + + + + + + + + + + + + + 0005974: Default for empty: invalid decoding rule - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005974Part 09: Using XML with TTCN-3Technicalpublic28-11-2011 14:4702-12-2011 11:41
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.3.1 (published 2011-06) 
Target Versionv4.4.1 (published 2012-04)Fixed in Versionv4.4.1 (published 2012-04) 
Clause Reference(s)B.3.7
For STF discussion
Source (company - Author)Elvior
Summary0005974: Default for empty: invalid decoding rule
DescriptionThe decoding rule for the "defaultForEmpty" encoding instruction states that:
+
+"...the decoder shall insert the value specified by freetext if the corresponding attribute or element is omitted in the received XML document."
+
+However, this is correct only for attributes. In case of elements, the element must be always present, but it is not required to contain a value (in which case the value is equal to the default value). See section 3.3.1 in XML Schema Part 1: Structures for more details.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
28-11-2011 14:47Tomas UrbanNew Issue
28-11-2011 14:47Tomas UrbanClause Reference(s) => B.3.7
28-11-2011 14:47Tomas UrbanSource (company - Author) => Elvior
28-11-2011 16:36Gyorgy RethyNote Added: 0010364
28-11-2011 16:36Gyorgy RethyAssigned To => Gyorgy Rethy
28-11-2011 16:36Gyorgy RethyStatusnew => assigned
28-11-2011 16:36Gyorgy RethyTarget Version => Edition 4.4.1
02-12-2011 11:41Gyorgy RethyNote Added: 0010513
02-12-2011 11:41Gyorgy RethyStatusassigned => closed
02-12-2011 11:41Gyorgy RethyResolutionopen => fixed
02-12-2011 11:41Gyorgy RethyFixed in Version => Edition 4.4.1
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010364) +
+ Gyorgy Rethy    +
+ 28-11-2011 16:36    +
+ 		+ + + + +
+ STF discussion 28/11: to be checked.
+
+
+
+ + + + + + + + + + +
+ (0010513) +
+ Gyorgy Rethy    +
+ 02-12-2011 11:41    +
+ 		+ + + + +
+ Implemented as proposed.
+
+ + diff --git a/docs/mantis/CR5975.md b/docs/mantis/CR5975.md new file mode 100644 index 0000000000000000000000000000000000000000..0ede85996a8b293784a89f209975cdc43021c8d2 --- /dev/null +++ b/docs/mantis/CR5975.md @@ -0,0 +1,174 @@ + + + + + + + + + + + + + 0005975: Tranformation of all compositor with minOccurs="0" - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005975Part 09: Using XML with TTCN-3Technicalpublic28-11-2011 14:5816-12-2011 16:49
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionno change required 
PlatformOSOS Version
Product Versionv4.3.1 (published 2011-06) 
Target Versionv4.4.1 (published 2012-04)Fixed in Version 
Clause Reference(s)7.6.4
For STF discussion
Source (company - Author)Elvior
Summary0005975: Tranformation of all compositor with minOccurs="0"
DescriptionIn the current version of the specification, minOccurs="0" attribute applied directly to an all compositor, makes all elements of the generated TTCN-3 record optional. However, such a record type allows the user to create templates that omit some but not all of record elements. The message created from this template is invalid, it won't pass schema validation. The minOccurs="0" attribute means that either all elements are present or none of them is.
+
+Proposal:
+The correct transformation mechanism should be similar to the one used in sequence transformation, i.e. an additional untagged record wrapper shall be generated for the all compositor and the whole wrapper should be set to optional while the fields inside would stay mandatory (see 7.6.6.6 for more details).
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
28-11-2011 14:58Tomas UrbanNew Issue
28-11-2011 14:58Tomas UrbanClause Reference(s) => 7.6.4
28-11-2011 14:58Tomas UrbanSource (company - Author) => Elvior
28-11-2011 16:33Gyorgy RethyNote Added: 0010363
28-11-2011 16:34Gyorgy RethyAssigned To => Jacob Wieland - Spirent
28-11-2011 16:34Gyorgy RethyStatusnew => assigned
28-11-2011 16:34Gyorgy RethyTarget Version => Edition 4.4.1
29-11-2011 09:18Jacob Wieland - SpirentNote Added: 0010370
29-11-2011 09:18Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
02-12-2011 13:33Gyorgy RethyNote Added: 0010517
02-12-2011 13:34Gyorgy RethyTarget VersionEdition 4.4.1 => v4.6.1 (published 2015-06)
02-12-2011 13:36Gyorgy RethyNote Edited: 0010517
16-12-2011 16:49Gyorgy RethyNote Added: 0010543
16-12-2011 16:49Gyorgy RethyStatusassigned => closed
16-12-2011 16:49Gyorgy RethyResolutionopen => no change required
16-12-2011 16:49Gyorgy RethyTarget Versionv4.6.1 (published 2015-06) => Edition 4.4.1
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010363) +
+ Gyorgy Rethy    +
+ 28-11-2011 16:33    +
+ 		+ + + + +
+ STF discussion 28/11: to be checked, but backward compatibility shall be kept.
+
+
+
+ + + + + + + + + + +
+ (0010370) +
+ Jacob Wieland - Spirent    +
+ 29-11-2011 09:18    +
+ 		+ + + + +
+ Because of backward compatibility issues, we opt to leave the standard as it is.
+
+Also, I could not find an explicit statement that for the all-compositor with minOccurs="0" that does not mean that it is implicitly inherited by all its children (although I think I remember reading a passage to that effect way back). I think that this was the reason why the mapping in TTCN-3 is also different than for the other cases.
+
+
+
+ + + + + + + + + + +
+ (0010517) +
+ Gyorgy Rethy    +
+ 02-12-2011 13:33    +
(edited on: 02-12-2011 13:36)
+ 		+ + + + +
+ This way of translation has been included to keep compatibility with ITU-T Recommendation X.694, i.e. users that used the path XSD->ASN.1(using X.694 and available converters)-> TTCN-3 (Part-7) could change to the direct mapping from XSD to TTCN-3 without changes in their existing code. By now, several years has passed from the first publication of Part-9. Probably (almost) all users has changed to the direct mapping, thus X.694 to Part-9 compatibility could be relaxed at some less frequently used places. However, now, backward compatibility with the already existing huge volume of TTCN-3 code is the important aspect. As the proposed change - though would unify mapping of sequence and all compositors - is not backward compatible, we cannot change the mapping in a rush. Including a tool-generated note saying that for correct message encoding all non-attribute fields shall be omitted could help (though not saving the user from making errors).
+
+As we are finishing our last session in 2011 today, further discussions shall be postponed to 2012.
+
+
+
+
+
+ + + + + + + + + + +
+ (0010543) +
+ Gyorgy Rethy    +
+ 16-12-2011 16:49    +
+ 		+ + + + +
+ No change to maintain backward compatibility.
+
+ + diff --git a/docs/mantis/CR5976.md b/docs/mantis/CR5976.md new file mode 100644 index 0000000000000000000000000000000000000000..2c8db2e422d1e05dc360f2b0ecb57cfed7abbe6c --- /dev/null +++ b/docs/mantis/CR5976.md @@ -0,0 +1,411 @@ + + + + + + + + + + + + + 0005976: The select statement should get a shorthand notation for switching over union variants - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005976Part 01: TTCN-3 Core LanguageNew Featurepublic29-11-2011 13:0913-01-2015 18:31
ReporterJacob Wieland - Spirent 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.5.1 (published 2013-04)Fixed in Versionv4.7.1 (published 2015-06) 
Clause Reference(s)6.2.5, 19.3
Source (company - Author)Testing Technologies - Jacob Wieland
Summary0005976: The select statement should get a shorthand notation for switching over union variants
DescriptionAt the moment there is no efficient way in TTCN-3 to switch over the different variants of a union type in a nice syntactic way. If a union has very many alternatives (e.g. when it is comprising all PDU-types of a protocol), this could lead to (unnecessary) performance issues at runtime. Also it would increase readability and thereby decrease maintenance costs.
+
+Therefore, I would like to propose an additional semantics for the select statement:
+
+assume the following definition:
+
+type union U {
+  T1 v1, ... Tn vn
+}
+
+and a context where expression 'u' is of type U.
+
+Then, the user should be able to write
+
+select (u) {
+  case (v1) { // do something with u.v1 ...
+  }
+  ...
+  case (vn) { // do something with u.vn
+  }
+}
+
+This should then be a shorthand notation for:
+
+select (u) {
+  case ({ v1 := ? }) { // do something with u.v1
+  }
+  ...
+  case ({ vn := ? }) { // do something with u.vn
+  }
+}
+
+Like for enumerated types, the union-variant-identifiers shall take precedence over other identifiers of the same name existent in this context (where global identifiers could still be used by module-prefixing).
+
+Alternatively, a new construct selectchosen() with the same syntax as the select construct but only applicable to union values where only union variant identifiers can be used in the cases could be introduced to avoid the nameclash issues.
+
+To avoid the multiple repetition of the expression u (which could also be a very length expression), the selectchosen() construct could even imply a constant declaration const Tn vn := u.vn; for each case (vn), thereby considerably shortening the TTCN-3 code.
+
+This is reminiscent of the WITH-statement of MODULA.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR5976.doc (677,376) 29-11-2011 19:01
http://oldforge.etsi.org/mantis/file_download.php?file_id=2613&type=bug
doc CR5976_resolution_v2.doc (729,088) 30-11-2011 09:28
http://oldforge.etsi.org/mantis/file_download.php?file_id=2615&type=bug
doc CR5976_resolution_v2-comments.doc (674,816) 30-11-2011 11:28
http://oldforge.etsi.org/mantis/file_download.php?file_id=2618&type=bug
doc CR5976_resolution_v3.doc (668,672) 30-11-2011 15:56
http://oldforge.etsi.org/mantis/file_download.php?file_id=2621&type=bug
doc CR5976_resolution_v4.doc (757,248) 02-12-2011 14:18
http://oldforge.etsi.org/mantis/file_download.php?file_id=2658&type=bug
Issue History
Date ModifiedUsernameFieldChange
29-11-2011 13:09Jacob Wieland - SpirentNew Issue
29-11-2011 13:09Jacob Wieland - SpirentClause Reference(s) => 6.2.5, 19.3
29-11-2011 13:09Jacob Wieland - SpirentSource (company - Author) => Testing Technologies - Jacob Wieland
29-11-2011 19:01Jacob Wieland - SpirentFile Added: CR5976.doc
29-11-2011 19:02Jacob Wieland - SpirentNote Added: 0010408
29-11-2011 19:03Jacob Wieland - SpirentNote Added: 0010409
29-11-2011 19:03Jacob Wieland - SpirentStatusnew => assigned
29-11-2011 19:03Jacob Wieland - SpirentAssigned To => Gyorgy Rethy
30-11-2011 08:02Gyorgy RethyProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
30-11-2011 08:03Gyorgy RethyTarget Version => Edition 4.4.1
30-11-2011 09:28Gyorgy RethyFile Added: CR5976_resolution_v2.doc
30-11-2011 09:29Gyorgy RethyNote Added: 0010415
30-11-2011 09:29Gyorgy RethyAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
30-11-2011 11:28Jacob Wieland - SpirentFile Added: CR5976_resolution_v2-comments.doc
30-11-2011 11:29Jacob Wieland - SpirentNote Added: 0010439
30-11-2011 11:31Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
30-11-2011 15:41Gyorgy RethyAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
30-11-2011 15:56Jacob Wieland - SpirentFile Added: CR5976_resolution_v3.doc
30-11-2011 15:58Jacob Wieland - SpirentNote Added: 0010448
30-11-2011 15:58Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
02-12-2011 14:18Gyorgy RethyFile Added: CR5976_resolution_v4.doc
02-12-2011 14:20Gyorgy RethyNote Added: 0010527
02-12-2011 14:21Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
02-12-2011 14:21Gyorgy RethyStatusassigned => resolved
02-12-2011 14:21Gyorgy RethyResolutionopen => fixed
04-06-2012 06:17Ina SchieferdeckerNote Added: 0010628
04-06-2012 06:17Ina SchieferdeckerTarget VersionEdition 4.4.1 => v4.7.1 (published 2015-06)
10-07-2012 19:28Ina SchieferdeckerNote Added: 0010779
10-07-2012 19:28Ina SchieferdeckerStatusresolved => closed
10-07-2012 19:28Ina SchieferdeckerFixed in Version => Edition 4.5.1
12-12-2014 09:48Jacob Wieland - SpirentAssigned ToIna Schieferdecker => Gyorgy Rethy
12-12-2014 09:48Jacob Wieland - SpirentNote Added: 0012543
12-12-2014 09:48Jacob Wieland - SpirentStatusclosed => feedback
12-12-2014 09:48Jacob Wieland - SpirentResolutionfixed => reopened
13-01-2015 12:55Gyorgy RethyResolutionreopened => fixed
13-01-2015 12:55Gyorgy RethyFixed in Versionv4.5.1 (published 2013-04) => v4.7.1 (published 2015-06)
13-01-2015 18:31Gyorgy RethyNote Added: 0012672
13-01-2015 18:31Gyorgy RethyStatusfeedback => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010408) +
+ Jacob Wieland - Spirent    +
+ 29-11-2011 19:02    +
+ 		+ + + + +
+ uploaded proposal text
+
+
+
+ + + + + + + + + + +
+ (0010409) +
+ Jacob Wieland - Spirent    +
+ 29-11-2011 19:03    +
+ 		+ + + + +
+ please review
+
+
+
+ + + + + + + + + + +
+ (0010415) +
+ Gyorgy Rethy    +
+ 30-11-2011 09:29    +
+ 		+ + + + +
+ See changes and explanations in file CR5976_resolution_v2.doc. Pls. review.
+
+
+
+ + + + + + + + + + +
+ (0010439) +
+ Jacob Wieland - Spirent    +
+ 30-11-2011 11:29    +
+ 		+ + + + +
+ added some comments to your comments.
+
+maybe we should have a stf-wide discussion about this part of the feature
+
+
+
+ + + + + + + + + + +
+ (0010448) +
+ Jacob Wieland - Spirent    +
+ 30-11-2011 15:58    +
+ 		+ + + + +
+ okay, changed example to be a bit more verbose, deleted example 2 (which was just to illustrate the name-clashing problem anyway).
+
+
+
+ + + + + + + + + + +
+ (0010527) +
+ Gyorgy Rethy    +
+ 02-12-2011 14:20    +
+ 		+ + + + +
+ OK with me. Only editorial changes (e.g. must->shall, a partially initialized union always has exactly one alternative selected) in the file CR5976_resolution_v4.doc.
+
+
+
+ + + + + + + + + + +
+ (0010628) +
+ Ina Schieferdecker    +
+ 04-06-2012 06:17    +
+ 		+ + + + +
+ Has not yet been implemented in part 1!
+
+
+
+ + + + + + + + + + +
+ (0010779) +
+ Ina Schieferdecker    +
+ 10-07-2012 19:28    +
+ 		+ + + + +
+ Implemented as proposed
+
+
+
+ + + + + + + + + + +
+ (0012543) +
+ Jacob Wieland - Spirent    +
+ 12-12-2014 09:48    +
+ 		+ + + + +
+ somehow, it was forgotten to REALLY implement this in 4.5.1 (the section is missing) and therefore, it is also missing in 4.6.1 and 4.6.2!
+
+Please correct this as soon as possible.
+
+
+
+ + + + + + + + + + +
+ (0012672) +
+ Gyorgy Rethy    +
+ 13-01-2015 18:31    +
+ 		+ + + + +
+ Added to draft V4.6.4
+
+ + diff --git a/docs/mantis/CR5977.md b/docs/mantis/CR5977.md new file mode 100644 index 0000000000000000000000000000000000000000..e8b2056976e81a485da422c53b5322d170aa0e45 --- /dev/null +++ b/docs/mantis/CR5977.md @@ -0,0 +1,224 @@ + + + + + + + + + + + + + 0005977: Reordering Annex C according to Table 15 in 16.1.2 - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005977Part 01: TTCN-3 Core LanguageEditorialpublic30-11-2011 10:4302-12-2011 13:59
ReporterIna Schieferdecker 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.4.1 (published 2012-04)Fixed in Versionv4.4.1 (published 2012-04) 
Clause Reference(s)Annex C
Source (company - Author)Ina Schieferdecker (FOKUS)
Summary0005977: Reordering Annex C according to Table 15 in 16.1.2
DescriptionHi Ina,
+ 
+sorry for the late reply. In principle I think this is a very good idea.
+But please make sure this change is properly documented in the new version and also ensure that tool vendors are aware of this change.
+ 
+Thx,
+Stephan
+ 
+From: Schieferdecker, Ina [mailto:ina.schieferdecker@fokus.fraunhofer.de]
+Sent: 30. kesäkuuta 2011 12:44
+To: stephan.schulz@conformiq.com
+Cc: hogrefe@informatik.uni-goettingen.de; Anthony.Wiles@etsi.org; stf430@etsi.org
+Subject: Concerning restructuring of TTCN-3 Part 1 Annex C
+ 
+Dear Stephan
+ 
+We are just discussing http://t-ort.etsi.org/view.php?id=5899 [^] . To resolve the issue, beside other things we decided to add an isbound function.
+
+Having a look at Annex C, it is quite apparent that over the years that annex became rather hard to read as substructuring is missing.
+
+For example, IsPresent is defined in C.31, IsChosen in C.32, and IsValue in C.38. IsBound would become C.43. There are more cases like this.
+ 
+Hence, we discussed to have another level of headings in Annex C in order to group predefined functions.
+ 
+Would you agree to this approach? It would improve readability, but change the references to all predefined functions – at least, 2nd and not 1st level and for quite some different numbers …
+
+Thank you in advance
+ 
+Ina
Steps To Reproduce
Additional InformationProposal to make sections in Annex C according to categories in Table 15 and to order the subsections for the predefined functions as they are ordered in that table.
TagsNo tags attached.
Relationships
Attached Filesdoc CR5977.doc (222,720) 01-12-2011 16:21
http://oldforge.etsi.org/mantis/file_download.php?file_id=2650&type=bug
Issue History
Date ModifiedUsernameFieldChange
30-11-2011 10:43Ina SchieferdeckerNew Issue
30-11-2011 10:43Ina SchieferdeckerStatusnew => assigned
30-11-2011 10:43Ina SchieferdeckerAssigned To => Ina Schieferdecker
30-11-2011 10:43Ina SchieferdeckerClause Reference(s) => Annex C +
30-11-2011 10:43Ina SchieferdeckerSource (company - Author) => Ina Schieferdecker (FOKUS)
30-11-2011 10:45Gyorgy RethyProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
30-11-2011 10:45Gyorgy RethyClause Reference(s)Annex C + => Annex C
30-11-2011 10:45Gyorgy RethyTarget Version => Edition 4.4.1
30-11-2011 12:45Bogdan Stanca-KapostaNote Added: 0010440
01-12-2011 15:43Ina SchieferdeckerNote Added: 0010489
01-12-2011 16:21Ina SchieferdeckerFile Added: CR5977.doc
01-12-2011 16:23Bogdan Stanca-KapostaNote Added: 0010492
02-12-2011 07:16Ina SchieferdeckerNote Added: 0010497
02-12-2011 13:58Ina SchieferdeckerStatusassigned => resolved
02-12-2011 13:58Ina SchieferdeckerResolutionopen => fixed
02-12-2011 13:58Ina SchieferdeckerFixed in Version => Edition 4.4.1
02-12-2011 13:59Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010440) +
+ Bogdan Stanca-Kaposta    +
+ 30-11-2011 12:45    +
+ 		+ + + + +
+ Dear Ina,
+
+From the point of view of the Conformance Testsuite STF433 this change is still ok.
+
+Nevertheless we would recommend to keep the numbering from now on for all Standard clauses, since the STF work uses the clause numbering as references. If a clause would be removed, the number should not be reused for any other new clause.
+(e.g. just like the paragraphs in the law - "clause was removed")
+
+Best regards,
+Bogdan
+
+
+
+ + + + + + + + + + +
+ (0010489) +
+ Ina Schieferdecker    +
+ 01-12-2011 15:43    +
+ 		+ + + + +
+ Dear Bogdan
+
+thank you for the immediate response and for supporting the CR.
+Wrt. the test suite: what about using th clause headlines instead of the clause numbers? As TTCN-3 is a living standard now and then changes will also be needed in the structure of the document. We tried to keep the main clause structure stable, but cannot assure this for subclause. Still, the clause headlines are rather stable and potentially a better reference than the clause numbers.
+
+Best regards, Ina
+
+
+
+ + + + + + + + + + +
+ (0010492) +
+ Bogdan Stanca-Kaposta    +
+ 01-12-2011 16:23    +
+ 		+ + + + +
+ Dear Ina,
+
+Actually I would expect that the headlines would change often as clause numbering. :)
+Besides, headlines are not always unique, as they are defined by their parent scope.
+
+For the main standard I would expect that the clauses are kept fixed. As for the Annexes the references are not that many (if any) and therefore these are not that critical, but would anyway produce some amount of work for each Conformance STF to track these changes. (I think this would be in our all interest to keep this time as short as possible.)
+
+Another idea would be to have some sort of (unique) identifiers for clauses and use these.
+
+As we have around 900 test modules I would think that is rather late to change this. This is also due the limited time of the STF not really feasible.
+
+Best regards,
+Bogdan (STF433)
+
+
+
+ + + + + + + + + + +
+ (0010497) +
+ Ina Schieferdecker    +
+ 02-12-2011 07:16    +
+ 		+ + + + +
+ Dear Bogdan
+
+this discussion is a bit in the wrong forum - still: in my view, TTCN-3 is matured so that clause changes are rather unlikely - I also think that a test suite should not determine how the technology to be tested is written - IMHO - still, I understand your position and think that it is indeed in the interest of all of us to have an efficient development of the standard and the test suite altogether. And yes, we have tried to keep the clauses as fixed as possible - and in case of main clauses even made use of void clauses - if this is to be applied also on subclause and subsubclause level it needs to be discussed - for example, it is unlikely that the restrictions numbering can be fixed as now and then there are corrections which require new, removed and changed restrictions. Likewise, the grammar rules can hardly have a fixed number. If we squeeze in too many void clauses or restrictions or rules the standard would become unreadable. In short: to keep as is has been the default, however, where needed changes should be possible.
+
+Best regards, Ina
+
+ + diff --git a/docs/mantis/CR5978.md b/docs/mantis/CR5978.md new file mode 100644 index 0000000000000000000000000000000000000000..03a7274787f384e3a2ecd20ebad47f677c56c7c1 --- /dev/null +++ b/docs/mantis/CR5978.md @@ -0,0 +1,224 @@ + + + + + + + + + + + + + 0005978: Position of attr in enframing record - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005978Part 09: Using XML with TTCN-3Clarificationpublic01-12-2011 09:5301-12-2011 16:35
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.3.1 (published 2011-06) 
Target Versionv4.4.1 (published 2012-04)Fixed in Versionv4.4.1 (published 2012-04) 
Clause Reference(s)7.7.2
For STF discussion
Source (company - Author)Elvior
Summary0005978: Position of attr in enframing record
DescriptionThe chapter 7.7 (7.7.2 in the 4.3.2 draft) doesn't contain any direct instruction on the position of the attr field (i.e. the result of anyAttribute transformation) in the enframing record. There's only a note that anyAttribute should be processed in the same way as other attributes, so I assume the rules specified in the clause 7.6.7 should be applied (even though there's no reference to 7.6.7 in the anyAttribute transformation rules).
+
+If this is correct, I have several questions:
+1. Does it mean that the attr field should be a part of the sorting procedure? E.g. if there's an attribute called 'bar', would the attr field precede it in the enframing record?
+2. If the sorting procedure is indeed invoked, what is the namespace related to the attr field? How are wildcards (such as #local, #other etc.) interpreted?
+
+I would prefer if the specification contained a precise definition of the position of the attr field in the enframing record, e.g.: The attr field is inserted to the enframing record together with other attributes according to the rules specified in the clause 7.6.7. For the purposes of the ordering procedure, it is assumed that the attr field has no target namespace.
+
+It would be very nice to include an example of a sequence that contains several attributes and elements and anyAttribute field in the specification to provide a comprehensive guidence on this issue.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR5978.doc (93,696) 01-12-2011 16:09
http://oldforge.etsi.org/mantis/file_download.php?file_id=2649&type=bug
Issue History
Date ModifiedUsernameFieldChange
01-12-2011 09:53Tomas UrbanNew Issue
01-12-2011 09:53Tomas UrbanClause Reference(s) => 7.7.2
01-12-2011 09:53Tomas UrbanSource (company - Author) => Elvior
01-12-2011 10:46Jacob Wieland - SpirentNote Added: 0010464
01-12-2011 10:57Tomas UrbanNote Added: 0010465
01-12-2011 11:27Jacob Wieland - SpirentNote Added: 0010468
01-12-2011 14:31Gyorgy RethyAssigned To => Gyorgy Rethy
01-12-2011 14:31Gyorgy RethyStatusnew => assigned
01-12-2011 14:31Gyorgy RethyTarget Version => Edition 4.4.1
01-12-2011 16:09Jacob Wieland - SpirentFile Added: CR5978.doc
01-12-2011 16:10Jacob Wieland - SpirentNote Added: 0010491
01-12-2011 16:35Gyorgy RethyNote Added: 0010494
01-12-2011 16:35Gyorgy RethyReproducibilityN/A => always
01-12-2011 16:35Gyorgy RethyStatusassigned => closed
01-12-2011 16:35Gyorgy RethyResolutionopen => fixed
01-12-2011 16:35Gyorgy RethyFixed in Version => Edition 4.4.1
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010464) +
+ Jacob Wieland - Spirent    +
+ 01-12-2011 10:46    +
+ 		+ + + + +
+ I think the standard is clear that the "attr" field should be treated like any other attribute field from the ordering perspective.
+
+Unfortunately I agree on the part of the namespace of the anyAttribute which shall be considered during ordering.
+
+Shall the namespace be considered NoTargetNamespace (which I would favour) or should it be the namespace of the type introducing the anyAttribute.
+
+If the latter is the case then the question arises which target namespace is correct if multiple anyAttribute declarations exist in the same type due to type derivation: shall the namespace of the uppermost base type introducing the anyAttribute be the targetnamespace or shall the namespace of the last derivation introducing anyAttributes be the targetnamespace.
+
+To keep it as simple as possible I would opt for the NoTargetNamespace option which would normally lead to the "attr" field being the first of the attribute fields (unless a schema without target namespace is part of the schema space which should be rare).
+
+
+
+ + + + + + + + + + +
+ (0010465) +
+ Tomas Urban    +
+ 01-12-2011 10:57    +
+ 		+ + + + +
+ OK, I agree that the standard is quite clear regarding the participation in the sorting procedure, but for better comprehensibility, it would be nice to add an explicit reference to the clause 7.6.7, i.e. to change the following sentence:
+
+The anyAttribute element shall be translated, like other attributes, to a field ... (see clauses 7.6, 7.6.5 and 7.6.6).
+
+-->
+
+
+The anyAttribute element shall be translated, like other attributes, to a field ... (see clause 7.6.7).
+
+
+
+ + + + + + + + + + +
+ (0010468) +
+ Jacob Wieland - Spirent    +
+ 01-12-2011 11:27    +
+ 		+ + + + +
+ Comparing the mapping with the XSD-to-ASN.1 mapping, it appears that there the component generated for the anyAttributes are added to the record AFTER all components for the (sorted) named attributes have been added to it. So, the attr-field would always appear as the first field after all the other attribute fields.
+
+If we want to stay in sync with that mapping, we should specify it the same way in the XSD-to-TTCN-3 mapping. I think this would be another viable option and since the standard is not clear on that until now, backward compatibility issues will occur with any solution anyhow.
+
+
+
+ + + + + + + + + + +
+ (0010491) +
+ Jacob Wieland - Spirent    +
+ 01-12-2011 16:10    +
+ 		+ + + + +
+ implemented as in XSD to ASN.1 mapping: position after other attributes (if any). Amended an example to that effect.
+
+
+
+ + + + + + + + + + +
+ (0010494) +
+ Gyorgy Rethy    +
+ 01-12-2011 16:35    +
+ 		+ + + + +
+ Implemented according to Jacob's draft.
+
+ + diff --git a/docs/mantis/CR5979.md b/docs/mantis/CR5979.md new file mode 100644 index 0000000000000000000000000000000000000000..fdc4584202d48b1cc29a5cba71369e0d7a963d2d --- /dev/null +++ b/docs/mantis/CR5979.md @@ -0,0 +1,107 @@ + + + + + + + + + + + + + 0005979: AnyType record - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005979Part 09: Using XML with TTCN-3Technicalpublic01-12-2011 13:1201-12-2011 14:15
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.3.1 (published 2011-06) 
Target Versionv4.4.1 (published 2012-04)Fixed in Versionv4.4.1 (published 2012-04) 
Clause Reference(s)6.8
For STF discussion
Source (company - Author)Elvior
Summary0005979: AnyType record
DescriptionThis issue is related to recently resolved http://t-ort.etsi.org/view.php?id=5897. [^] I think that according to the rules introduced by the referenced change, the attr field of the AnyType type specified in 6.8 (and Annex A) should be changed to optional as well:
+
+type record AnyType {
+  record of XSD.String attr optional,
+  record of XSD.String elem_list
+}
+with {
+  variant "XSD:anyType";
+  variant(attr) "anyAttributes";
+  variant(elem_list) "anyElement";
+}
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR5979.doc (100,352) 01-12-2011 13:47
http://oldforge.etsi.org/mantis/file_download.php?file_id=2642&type=bug
Issue History
Date ModifiedUsernameFieldChange
01-12-2011 13:12Tomas UrbanNew Issue
01-12-2011 13:12Tomas UrbanClause Reference(s) => 6.8
01-12-2011 13:12Tomas UrbanSource (company - Author) => Elvior
01-12-2011 13:34Jacob Wieland - SpirentNote Added: 0010479
01-12-2011 13:37Jacob Wieland - SpirentStatusnew => assigned
01-12-2011 13:37Jacob Wieland - SpirentAssigned To => Jacob Wieland - Spirent
01-12-2011 13:47Jacob Wieland - SpirentFile Added: CR5979.doc
01-12-2011 13:47Jacob Wieland - SpirentNote Added: 0010480
01-12-2011 13:47Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
01-12-2011 14:15Gyorgy RethyStatusassigned => closed
01-12-2011 14:15Gyorgy RethyResolutionopen => fixed
01-12-2011 14:15Gyorgy RethyFixed in Version => Edition 4.4.1
01-12-2011 14:15Gyorgy RethyTarget Version => Edition 4.4.1
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010479) +
+ Jacob Wieland - Spirent    +
+ 01-12-2011 13:34    +
+ 		+ + + + +
+ Agreed. That would be consistent.
+
+
+
+ + + + + + + + + + +
+ (0010480) +
+ Jacob Wieland - Spirent    +
+ 01-12-2011 13:47    +
+ 		+ + + + +
+ fixed this in 6.8 and Annex A
+
+ + diff --git a/docs/mantis/CR5980.md b/docs/mantis/CR5980.md new file mode 100644 index 0000000000000000000000000000000000000000..26528b271e7011c7ab9763aff04ee94d5988d15c --- /dev/null +++ b/docs/mantis/CR5980.md @@ -0,0 +1,135 @@ + + + + + + + + + + + + + 0005980: all templates/variables referenced in special matching mechanism symbols shall be completely initialized - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005980Part 01: TTCN-3 Core LanguageTechnicalpublic02-12-2011 11:0913-07-2012 13:13
ReporterJacob Wieland - Spirent 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.5.1 (published 2013-04)Fixed in Versionv4.5.1 (published 2013-04) 
Clause Reference(s)15.7.2., 15.7.3, 15.7.4
Source (company - Author)Testing Technologies - Jacob Wieland
Summary0005980: all templates/variables referenced in special matching mechanism symbols shall be completely initialized
DescriptionIf a matching mechanism symbol were to be used (e.g. to be assigned to a variable) which would contain a reference to a not-completely initialized value/template, this matching mechanism symbol later on could never become completely initialized as there are no assignments to parts of matching mechanism symbols.
+
+If the symbol references a variable that is not initialized at reference-time, the content of the variable at the moment of reference is of course used for initializing the matching symbol. So, if the content of the variable changes later on, this will not change the matching mechanism symbol.
+
+Therefore, it would be unwise to allow not-completely initialized matching mechanism symbols as they can never be used anywhere and thus would only lead to runtime errors as soon as they are used.
Steps To Reproduce
Additional InformationProposals for the necessary changes can be found in CR5942.
TagsNo tags attached.
Relationships
related to 0005942closed Ina Schieferdecker Boundness of arguments of the match operation 
Attached Filesdoc CR5980_resolution_v1.doc (241,664) 11-07-2012 11:18
http://oldforge.etsi.org/mantis/file_download.php?file_id=2666&type=bug
Issue History
Date ModifiedUsernameFieldChange
02-12-2011 11:09Jacob Wieland - SpirentNew Issue
02-12-2011 11:09Jacob Wieland - SpirentClause Reference(s) => 15.7.2., 15.7.3, 15.7.4
02-12-2011 11:09Jacob Wieland - SpirentSource (company - Author) => Testing Technologies - Jacob Wieland
02-12-2011 11:10Jacob Wieland - SpirentRelationship addedrelated to 0005942
09-07-2012 16:55Ina SchieferdeckerProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
10-07-2012 14:34Gyorgy RethyAssigned To => Gyorgy Rethy
10-07-2012 14:34Gyorgy RethyStatusnew => assigned
10-07-2012 14:34Gyorgy RethyTarget Version => Edition 4.5.1
11-07-2012 11:18Gyorgy RethyFile Added: CR5980_resolution_v1.doc
11-07-2012 11:20Gyorgy RethyNote Added: 0010828
11-07-2012 11:20Gyorgy RethyAssigned ToGyorgy Rethy => Tomas Urban
11-07-2012 16:46Tomas UrbanNote Added: 0010847
11-07-2012 16:46Tomas UrbanAssigned ToTomas Urban => Ina Schieferdecker
13-07-2012 13:13Ina SchieferdeckerStatusassigned => resolved
13-07-2012 13:13Ina SchieferdeckerResolutionopen => fixed
13-07-2012 13:13Ina SchieferdeckerStatusresolved => closed
13-07-2012 13:13Ina SchieferdeckerNote Added: 0010921
13-07-2012 13:13Ina SchieferdeckerFixed in Version => Edition 4.5.1
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010828) +
+ Gyorgy Rethy    +
+ 11-07-2012 11:20    +
+ 		+ + + + +
+ CR5942 covers the match operation only, therefore restrictions are added to the clauses mentioned by Jacob. Proposed text is in CR5980_resolution_v1.doc, pls. review.
+
+
+
+ + + + + + + + + + +
+ (0010847) +
+ Tomas Urban    +
+ 11-07-2012 16:46    +
+ 		+ + + + +
+ Reviewed. No issues found. It can be added to the standard.
+
+
+
+ + + + + + + + + + +
+ (0010921) +
+ Ina Schieferdecker    +
+ 13-07-2012 13:13    +
+ 		+ + + + +
+ Implemented as in v1
+
+ + diff --git a/docs/mantis/CR5981.md b/docs/mantis/CR5981.md new file mode 100644 index 0000000000000000000000000000000000000000..8bbf90abb0023eba219b9a80a1fa8787d8464f8d --- /dev/null +++ b/docs/mantis/CR5981.md @@ -0,0 +1,307 @@ + + + + + + + + + + + + + 0005981: TLI does currently not represent the p.check operation appropriately - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005981Part 06: TTCN-3 Control InterfaceTechnicalpublic06-12-2011 14:3620-12-2012 15:05
ReporterThilo Lauer 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityfeatureReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.3.1 (published 2011-06) 
Target Versionv4.5.1 (published 2013-04)Fixed in Versionv4.5.1 (published 2013-04) 
Clause Reference(s)7.3.4.1.19, 7.3.4.1.20, 7.3.4.1.31, 7.3.4.1.32, 7.3.4.1.43, 7.3.4.1.44, 7.3.4.1.55, 7.3.4.1.56
Source (company - Author)Devoteam Danet - Thilo Lauer
Summary0005981: TLI does currently not represent the p.check operation appropriately
DescriptionCurrently there is no distinction in TLI between
+
+  p.receive(...) and p.check(receive(...))
+  p.getcall(...) and p.check(getcall(...))
+  p.getreply(...) and p.check(getreply(...))
+  p.catch(...) and p.check(catch(...))
+
+For now these p.check(...) events have to be logged in TLI by:
+
+  tliMReceive_m/c,
+  tliPrGetCall_m/c,
+  tliPrGetReply_m/c,
+  tliPrCatch_m/c
+
+but this does not indicate in the TLI-Log that the message itself remains in the port queue. This could be an important detail for interpreting the TLI-log.
+ 
+For
+
+  MyPort.check;
+  MyPort.check(from MyPartner);
+  MyPort.check(-> sender MySenderVar);
+  any port.check;
+
+a TLI log-mapping to e.g.:
+
+  tliMReceive_m/c,
+
+would be very misleading in my opinion.
+
+My suggested solution would be to define the TLI-functions below
+
+  tliMCheckReceive_m/c,
+  tliPrCheckGetCall_m/c,
+  tliPrCheckGetReply_m/c,
+  tliPrCheckCatch_m/c
+
+completely identical to tliMReceive_m/c ... tliPrCatch_m/c except for the function's names.
+[An alternative solution could be here to add a "check" flag as parameter to tliMReceive_m/c ... tliPrCatch_m/c as well as to the XML-representation of the logged event]
+
+For
+
+  MyPort.check;
+  MyPort.check(from MyPartner);
+  MyPort.check(-> sender MySenderVar);
+  any port.check;
+
+I would suggest to define a new TLI-function here, named e.g.:
+
+  tliCheck(...)
+
+to indicate this event in the log.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0006600closed Ina Schieferdecker Missing data in TLI check operations 
Attached Filesdocx CR5981_v1.docx (59,994) 14-12-2012 11:08
http://oldforge.etsi.org/mantis/file_download.php?file_id=2783&type=bug
docx CR5981_v2.docx (81,665) 14-12-2012 13:39
http://oldforge.etsi.org/mantis/file_download.php?file_id=2785&type=bug
docx CR5981_v3.docx (110,191) 20-12-2012 15:04
http://oldforge.etsi.org/mantis/file_download.php?file_id=2792&type=bug
Issue History
Date ModifiedUsernameFieldChange
06-12-2011 14:36Thilo LauerNew Issue
06-12-2011 14:36Thilo LauerClause Reference(s) => 7.3.4.1.19, 7.3.4.1.20, 7.3.4.1.31, 7.3.4.1.32, 7.3.4.1.43, 7.3.4.1.44, 7.3.4.1.55, 7.3.4.1.56
06-12-2011 14:36Thilo LauerSource (company - Author) => Devoteam Danet - Thilo Lauer
10-07-2012 14:28Gyorgy RethyNote Added: 0010763
10-07-2012 14:28Gyorgy RethyAssigned To => Ina Schieferdecker
10-07-2012 14:28Gyorgy RethyStatusnew => assigned
10-07-2012 14:28Gyorgy RethyTarget Version => Edition 4.5.1
12-07-2012 15:41Ina SchieferdeckerNote Added: 0010888
10-08-2012 13:43Ina SchieferdeckerNote Added: 0011031
14-12-2012 11:08Ina SchieferdeckerNote Added: 0011271
14-12-2012 11:08Ina SchieferdeckerFile Added: CR5981_v1.docx
14-12-2012 11:08Ina SchieferdeckerAssigned ToIna Schieferdecker => Tomas Urban
14-12-2012 13:39Tomas UrbanFile Added: CR5981_v2.docx
14-12-2012 13:43Tomas UrbanNote Added: 0011281
14-12-2012 13:44Tomas UrbanAssigned ToTomas Urban => Ina Schieferdecker
20-12-2012 15:04Ina SchieferdeckerFile Added: CR5981_v3.docx
20-12-2012 15:04Ina SchieferdeckerNote Added: 0011301
20-12-2012 15:05Ina SchieferdeckerStatusassigned => closed
20-12-2012 15:05Ina SchieferdeckerResolutionopen => fixed
20-12-2012 15:05Ina SchieferdeckerFixed in Version => Edition 4.5.1
26-08-2013 13:30Jacob Wieland - SpirentRelationship addedrelated to 0006600
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010763) +
+ Gyorgy Rethy    +
+ 10-07-2012 14:28    +
+ 		+ + + + +
+ STF discussion 2012-07-10: the issue exists, propose a solution.
+
+
+
+ + + + + + + + + + +
+ (0010888) +
+ Ina Schieferdecker    +
+ 12-07-2012 15:41    +
+ 		+ + + + +
+ The cleanest solution would be to define tliCheck that can take the logs of the different receiving operations. However, that would require to introduce a ReceivingOp Types for parameters to tliCheck. That is considered to be an overkill as basically all the structures in tliMCheckReceive_m/c, tliPrCheckGetCall_m/c, tliPrCheckGetReply_m/c, and tliPrCheckCatch_m/c would have to be repeated.
+
+Another solution would be to add a check flag to all these operations. However, that would be a non-backward-compatible change to the interface.
+
+There are two lightweight approaches:
+
+1. define tliCheck just indicating a check operation that is to be followed ba a log of the log operation of the enclosed receiving operation (this is a work around for the new check logging operation proposal)
+
+2. define the additional "am" parameter that is present in any logging operation to represent the check operation when loggin the enclosed receiving operation (this is a work around for the check tag proposal)
+
+The issue needs to be discussed in the STF
+
+
+
+ + + + + + + + + + +
+ (0011031) +
+ Ina Schieferdecker    +
+ 10-08-2012 13:43    +
+ 		+ + + + +
+ Discussion in the STF: develop option 2
+
+
+
+ + + + + + + + + + +
+ (0011271) +
+ Ina Schieferdecker    +
+ 14-12-2012 11:08    +
+ 		+ + + + +
+ The proposal is defined as by reusing the Detected operations of TLI and defining 8 new operations for Checked:
+
+tliMChecked_m
+tliMChecked_c
+tliPrGetCallChecked_m
+tliPrGetCallChecked_c
+tliPrGetReplyChecked_m
+tliPrGetReplyChecked_c
+tliPrCatchChecked_m
+tliPrCatchChecked_c
+
+Please check
+
+
+
+ + + + + + + + + + +
+ (0011281) +
+ Tomas Urban    +
+ 14-12-2012 13:43    +
+ 		+ + + + +
+ I added four new operations: two of them for successful check any operations and two for logging mismatches in check any operations (in case addresses/components don't match).
+
+I also noticed the schema definitions in the Annex B don't contain the definitions from part 11.4.2.1, but that is probably intentional (so that there's no duplicated text in the draft)
+
+
+
+ + + + + + + + + + +
+ (0011301) +
+ Ina Schieferdecker    +
+ 20-12-2012 15:04    +
+ 		+ + + + +
+ Added the IDL definitions to Annex A in v3.
+Implemented v3.
+
+ + diff --git a/docs/mantis/CR5982.md b/docs/mantis/CR5982.md new file mode 100644 index 0000000000000000000000000000000000000000..b1cd9deb5febe038d3ad3c6312d3cf624f540569 --- /dev/null +++ b/docs/mantis/CR5982.md @@ -0,0 +1,102 @@ + + + + + + + + + + + + + 0005982: Handling the keywords added by extension packages - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 07: Using ASN.1 with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005982Part 07: Using ASN.1 with TTCN-3Clarificationpublic15-12-2011 15:2915-12-2011 15:50
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.4.1 (published 2012-04)Fixed in Versionv4.4.1 (published 2012-04) 
Clause Reference(s)8.2
Source (company - Author)L.M.Ericsson
Summary0005982: Handling the keywords added by extension packages
DescriptionCurrently the mapping rules does not handle/refer to the mapping of keywords added to language extensions.
+
+A note has to be added to warn the users and tool vendors that modules using an extension package may imply additional keywords to postfix.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
15-12-2011 15:29Gyorgy RethyNew Issue
15-12-2011 15:29Gyorgy RethyClause Reference(s) => 8.2
15-12-2011 15:29Gyorgy RethySource (company - Author) => L.M.Ericsson
15-12-2011 15:29Gyorgy RethyAssigned To => Gyorgy Rethy
15-12-2011 15:29Gyorgy RethyStatusnew => assigned
15-12-2011 15:29Gyorgy RethyTarget Version => Edition 4.4.1
15-12-2011 15:30Gyorgy RethyNote Added: 0010534
15-12-2011 15:30Gyorgy RethyStatusassigned => resolved
15-12-2011 15:30Gyorgy RethyResolutionopen => fixed
15-12-2011 15:30Gyorgy RethyFixed in Version => Edition 4.4.1
15-12-2011 15:30Gyorgy RethyStatusresolved => closed
15-12-2011 15:30Gyorgy RethyNote Added: 0010535
15-12-2011 15:49Gyorgy RethyStatusclosed => feedback
15-12-2011 15:49Gyorgy RethyResolutionfixed => reopened
15-12-2011 15:50Gyorgy RethyNote Edited: 0010534
15-12-2011 15:50Gyorgy RethyStatusfeedback => closed
15-12-2011 15:50Gyorgy RethyResolutionreopened => fixed
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010534) +
+ Gyorgy Rethy    +
+ 15-12-2011 15:30    +
(edited on: 15-12-2011 15:50)
+ 		+ + + + +
+ Add note:
+NOTE: ES 201 873 1 [1] clause A.1.5 table A.2 defines the keywords of the core language. However, TTCN-3 language extensions (see [i.20] to [i.23], but other extensions may also be published after the publication of this document) may define additional keywords and rules for handling those keywords in TTCN-3 modules requiring the given extension.
+
+
+
+
+
+ + + + + + + + + + +
+ (0010535) +
+ Gyorgy Rethy    +
+ 15-12-2011 15:30    +
+ 		+ + + + +
+ Implemented
+
+ + diff --git a/docs/mantis/CR5983.md b/docs/mantis/CR5983.md new file mode 100644 index 0000000000000000000000000000000000000000..381763f4d0f36838e9b80fe88e82639b9108343e --- /dev/null +++ b/docs/mantis/CR5983.md @@ -0,0 +1,102 @@ + + + + + + + + + + + + + 0005983: Handling of the keywords added by extension packages - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 08: Using IDL with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005983Part 08: Using IDL with TTCN-3Clarificationpublic15-12-2011 15:4615-12-2011 15:49
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.3.1 (published 2011-06) 
Target Versionv4.4.1 (published 2012-04)Fixed in Versionv4.4.1 (published 2012-04) 
Clause Reference(s)8
Source (company - Author)L.M.Ericsson
Summary0005983: Handling of the keywords added by extension packages
DescriptionCurrently the mapping rules does not handle/refer to the mapping of keywords added to language extensions.
+
+A note has to be added to warn the users and tool vendors that modules using an extension package may imply additional keywords to postfix.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
15-12-2011 15:46Gyorgy RethyNew Issue
15-12-2011 15:46Gyorgy RethyClause Reference(s) => 8
15-12-2011 15:46Gyorgy RethySource (company - Author) => L.M.Ericsson
15-12-2011 15:47Gyorgy RethyAssigned To => Gyorgy Rethy
15-12-2011 15:47Gyorgy RethyStatusnew => assigned
15-12-2011 15:47Gyorgy RethyTarget Version => Edition 4.4.1
15-12-2011 15:47Gyorgy RethyNote Added: 0010536
15-12-2011 15:47Gyorgy RethyStatusassigned => resolved
15-12-2011 15:47Gyorgy RethyResolutionopen => fixed
15-12-2011 15:47Gyorgy RethyFixed in Version => Edition 4.4.1
15-12-2011 15:48Gyorgy RethyStatusresolved => feedback
15-12-2011 15:48Gyorgy RethyResolutionfixed => reopened
15-12-2011 15:48Gyorgy RethyNote Edited: 0010536
15-12-2011 15:49Gyorgy RethyNote Added: 0010537
15-12-2011 15:49Gyorgy RethyStatusfeedback => closed
15-12-2011 15:49Gyorgy RethyResolutionreopened => fixed
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010536) +
+ Gyorgy Rethy    +
+ 15-12-2011 15:47    +
(edited on: 15-12-2011 15:48)
+ 		+ + + + +
+ Add note:
+NOTE: ES 201 873 1 [1] clause A.1.5 table A.2 defines the keywords of the core language. However, TTCN-3 language extensions (see [i.20] to [i.23], but other extensions may also be published after the publication of this document) may define additional keywords and rules for handling those keywords in TTCN-3 modules requiring the given extension.
+
+
+
+
+
+ + + + + + + + + + +
+ (0010537) +
+ Gyorgy Rethy    +
+ 15-12-2011 15:49    +
+ 		+ + + + +
+ Implemented.
+
+ + diff --git a/docs/mantis/CR5984.md b/docs/mantis/CR5984.md new file mode 100644 index 0000000000000000000000000000000000000000..a2ad96dd780fdb8f698bdd711ee1003905c4271f --- /dev/null +++ b/docs/mantis/CR5984.md @@ -0,0 +1,66 @@ + + + + + + + + + + + + + 0005984: Handling the keywords added by extension packages - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005984Part 09: Using XML with TTCN-3Clarificationpublic15-12-2011 15:5415-12-2011 16:00
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.4.1 (published 2012-04)Fixed in Versionv4.4.1 (published 2012-04) 
Clause Reference(s)5.2.2
For STF discussion
Source (company - Author)L.M.Ericsson
Summary0005984: Handling the keywords added by extension packages
DescriptionCurrently the mapping rules does not handle/refer to the mapping of keywords added to language extensions.
+
+A note has to be added to warn the users and tool vendors that modules using an extension package may imply additional keywords to postfix.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
15-12-2011 15:54Gyorgy RethyNew Issue
15-12-2011 15:54Gyorgy RethyClause Reference(s) => 5.2.2
15-12-2011 15:54Gyorgy RethySource (company - Author) => L.M.Ericsson
15-12-2011 15:58Gyorgy RethyAssigned To => Gyorgy Rethy
15-12-2011 15:58Gyorgy RethyStatusnew => assigned
15-12-2011 15:58Gyorgy RethyTarget Version => Edition 4.4.1
15-12-2011 15:58Gyorgy RethyNote Added: 0010538
15-12-2011 16:00Gyorgy RethyStatusassigned => closed
15-12-2011 16:00Gyorgy RethyResolutionopen => fixed
15-12-2011 16:00Gyorgy RethyFixed in Version => Edition 4.4.1
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010538) +
+ Gyorgy Rethy    +
+ 15-12-2011 15:58    +
+ 		+ + + + +
+ Add the note:
+NOTE: ES 201 873 1 [1] clause A.1.5 table A.2 defines the keywords of the core language. However, TTCN-3 language extensions (see [i.3] to [i.6], but other extensions may also be published after the publication of this document) may define additional keywords and rules for handling those keywords in TTCN-3 modules requiring the given extension.
+
+ + diff --git a/docs/mantis/CR5985.md b/docs/mantis/CR5985.md new file mode 100644 index 0000000000000000000000000000000000000000..f12b357159b35ebba3cbc517394fb2757f80d853 --- /dev/null +++ b/docs/mantis/CR5985.md @@ -0,0 +1,44 @@ + + + + + + + + + + + + + 0005985: Support of parametrized map/unmap operation for full dynamic mapping - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 05: TTCN-3 Runtime Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005985Part 05: TTCN-3 Runtime Interface New Featurepublic16-12-2011 05:4216-12-2011 05:44
ReporterIna Schieferdecker 
Assigned ToIna Schieferdecker 
PriorityhighSeveritymajorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.3.1 (published 2011-06) 
Target Versionv4.4.1 (published 2012-04)Fixed in Versionv4.4.1 (published 2012-04) 
Clause Reference(s)missing
Source (company - Author)     
Summary0005985: Support of parametrized map/unmap operation for full dynamic mapping
DescriptionIn many situations in the testing world configuration parameters for connections are needed in the real world.
+In TTCN-3 the establishment of a connection is announced by using the map operation. This allows dynamic mapping inside the behaviour of a test and should be an advantage in comparison with TTCN-2.
+Currently this can be used in all cases where no additional configuration parameters are needed for establishing a connection(in the adaptation). In some cases static configuration parameters like property files are efficient enough, however for fully dynamic configuration and establishing of connections an extension to the existing map operation is needed.
+We propose to extend the existing map operation with an optional parameter containing a configuration value. Attached you will find the modified recommendation including proposals for the map statement and additionally for the port type declaration.
+The benefit of the proposal would be the full support of dynamic configuration!
+
+We include the modified recommendations for reference(including change bars).
Steps To Reproduce
Additional InformationA short example of our proposal:
+var MyConfigType MyConfig := { option := 1, lock := false};
+     :
+map(mtc:Port4, system:PCO2) param MyConfig);
+
+type port PortTypeIdentifier message "{"
+        { ( in | out | inout ) { MessageType [ "," ] }+ ";" }
+        [ map param "(" FormalPar {"," FormalPar} ")"]
+        [ unmap param "(" FormalPar {"," FormalPar} ")"]
+"}"
TagsNo tags attached.
Relationships
child of 0005417closed Ina Schieferdecker Part 01: TTCN-3 Core Language Support of parametrized map/unmap operation for full dynamic mapping 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
16-12-2011 05:42Ina SchieferdeckerNew Issue
16-12-2011 05:42Ina SchieferdeckerStatusnew => assigned
16-12-2011 05:42Ina SchieferdeckerAssigned To => Ina Schieferdecker
16-12-2011 05:42Ina SchieferdeckerClause Reference(s) => missing
16-12-2011 05:42Ina SchieferdeckerSource (company - Author) =>
16-12-2011 05:42Ina SchieferdeckerIssue generated from: 0005417
16-12-2011 05:42Ina SchieferdeckerRelationship addedchild of 0005417
16-12-2011 05:42Ina SchieferdeckerProjectPart 01: TTCN-3 Core Language => Part 05: TTCN-3 Runtime Interface
16-12-2011 05:43Ina SchieferdeckerStatusassigned => closed
16-12-2011 05:43Ina SchieferdeckerResolutionopen => fixed
16-12-2011 05:43Ina SchieferdeckerFixed in Version => Edition 4.4.1
16-12-2011 05:43Ina SchieferdeckerTarget Version => Edition 4.3.1
16-12-2011 05:44Ina SchieferdeckerTarget VersionEdition 4.3.1 => Edition 4.4.1
+
+ + + + +
+ There are no notes attached to this issue.
+ + diff --git a/docs/mantis/CR5986.md b/docs/mantis/CR5986.md new file mode 100644 index 0000000000000000000000000000000000000000..d7e44d8ac9874cf4a271d7ba67cd67c9752b6d30 --- /dev/null +++ b/docs/mantis/CR5986.md @@ -0,0 +1,139 @@ + + + + + + + + + + + + + 0005986: Invalid TCI interface for octetstring - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005986Part 06: TTCN-3 Control InterfaceTechnicalpublic16-12-2011 16:2212-07-2012 16:13
ReporterMateusz Pusz 
Assigned ToIna Schieferdecker 
PrioritynormalSeveritymajorReproducibilityN/A
StatusclosedResolutionwon't fix 
PlatformOSOS Version
Product Version 
Target Versionv4.5.1 (published 2013-04)Fixed in Version 
Clause Reference(s)10.5.3.9-10
Source (company - Author)Mateusz Pusz/freettcn
Summary0005986: Invalid TCI interface for octetstring
DescriptionThat issue is a follow up of 0005945 and exactly that part:
+"Tchar is not defined in the standard too and it is used in OctetstringValue and HexstringValue interfaces (10.5.3.9-10)."
+
+It seems that Tchar is not a good solution here and should be removed from the specification. Here is why...
+
+Lets assume:
+
+var hexstring string1;
+string1 := '1234'H;
+string1[1] := '1'H; // is valid and will end up with '1134'H;
+
+ORG_ETSI_TTCN3_TCI::HexstringValue::setHex(1, '1'); // is valid and will end up again with '1134'H;
+
+Now lets look at another type:
+
+var octetstring string2;
+string2 := '1234'O;
+string2[1] := '11'O; // is valid and will end up with '1211'O;
+
+// but how TCI should behave?
+// we cannot pass
+ORG_ETSI_TTCN3_TCI::OctetstringValue::setOctet(1, '11'); // <---- compilation error
+
+// maybe index of a TTCN type should not be equal to index of TCI type?
+ORG_ETSI_TTCN3_TCI::OctetstringValue::setOctet(2, '1');
+ORG_ETSI_TTCN3_TCI::OctetstringValue::setOctet(3, '1'); // but that is not he best idea
+// and of course getOctet() has to use the same indices
+
+// or maybe Tchar should be treated as an integer and not a char
+ORG_ETSI_TTCN3_TCI::OctetstringValue::setOctet(1, 0x11);
+// but in such a case hexstring should also be modfied to work like that:
+ORG_ETSI_TTCN3_TCI::HexstringValue::setHex(1, 0x01);
+// also getOctet() and getHex() should return similar values
+
+From current TCI definition it is not possible to understand what the standard really means here.
+
+It would be much better to use Tinteger value here because it is directly suggesting the usage scenario. In such a case Tchar type is not needed anywhere and should be removed from the standard.
+
+Alternatively Tchar can be renamed to Tbyte. The same underlying (1 byte long) type will be used, but it will provide totally different meaning suggesting usage of integral values instead of characters. In such a case TCI interface description should be extended with exact information how to use it.
Steps To Reproduce
Additional InformationSee also no.3 here http://list.etsi.org/scripts/wa.exe?A2=ind1110&L=ttcn3&T=0&P=393. [^]
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
16-12-2011 16:22Mateusz PuszNew Issue
16-12-2011 16:22Mateusz PuszClause Reference(s) => 10.5.3.9-10
16-12-2011 16:22Mateusz PuszSource (company - Author) => Mateusz Pusz/freettcn
09-07-2012 16:53Ina SchieferdeckerProjectTTCN-3 Change Requests => Part 06: TTCN-3 Control Interface
10-07-2012 18:24Gyorgy RethyNote Added: 0010777
10-07-2012 18:24Gyorgy RethyAssigned To => Ina Schieferdecker
10-07-2012 18:24Gyorgy RethyStatusnew => assigned
10-07-2012 18:24Gyorgy RethyTarget Version => Edition 4.5.1
12-07-2012 16:12Ina SchieferdeckerNote Added: 0010895
12-07-2012 16:13Ina SchieferdeckerStatusassigned => closed
12-07-2012 16:13Ina SchieferdeckerResolutionopen => won't fix
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010777) +
+ Gyorgy Rethy    +
+ 10-07-2012 18:24    +
+ 		+ + + + +
+ STF discussion 2012-07-10: to be checked
+
+
+
+ + + + + + + + + + +
+ (0010895) +
+ Ina Schieferdecker    +
+ 12-07-2012 16:12    +
+ 		+ + + + +
+ TChar is used in TCI for BitString, HexString, and OctetString in getBit, getHex, and getOctet to return the bit, hex, and octet at a given position as a character.
+
+It is NOT used to set a bit, octet, or hex respectively. For that, integer is used instead - see setBit, setOctet, and setHex.
+
+Hence, the examples given above work differently, but will work if the operations are used as defined.
+
+ + diff --git a/docs/mantis/CR5987.md b/docs/mantis/CR5987.md new file mode 100644 index 0000000000000000000000000000000000000000..d90bb82b790de997851fa37828defd03ff8e817e --- /dev/null +++ b/docs/mantis/CR5987.md @@ -0,0 +1,330 @@ + + + + + + + + + + + + + 0005987: Unclarity of handling nested override directives in section 27 - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005987Part 01: TTCN-3 Core LanguageClarificationpublic17-12-2011 06:2511-10-2013 11:51
ReporterAndras Kovacs 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.3.1 (published 2011-06) 
Target Versionv4.6.1 (published 2014-06)Fixed in Versionv4.6.1 (published 2014-06) 
Clause Reference(s)Core language / section 27.1
Source (company - Author)STF433
Summary0005987: Unclarity of handling nested override directives in section 27
DescriptionIt is not clear from the definition of override directive (in section 27.1) which override statement would take precedence in case of nested statements. The suggested definition would be to define the innermost override statement to take precedence.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR5987_resolution_v1.doc (75,264) 10-07-2013 15:38
http://oldforge.etsi.org/mantis/file_download.php?file_id=2814&type=bug
doc CR5987_resolution_v2.doc (76,288) 28-08-2013 11:08
http://oldforge.etsi.org/mantis/file_download.php?file_id=2867&type=bug
Issue History
Date ModifiedUsernameFieldChange
17-12-2011 06:25Andras KovacsNew Issue
17-12-2011 06:25Andras KovacsClause Reference(s) => Core language / section 27.1
17-12-2011 06:25Andras KovacsSource (company - Author) => STF433
10-07-2012 18:21Gyorgy RethyNote Added: 0010775
10-07-2012 18:21Gyorgy RethyAssigned To => Jens Grabowski
10-07-2012 18:21Gyorgy RethyStatusnew => assigned
10-07-2012 18:21Gyorgy RethyTarget Version => Edition 4.5.1
11-07-2012 12:23Jens GrabowskiNote Added: 0010835
09-08-2012 15:14Jens GrabowskiNote Added: 0011010
11-12-2012 10:18Jens GrabowskiNote Added: 0011214
11-12-2012 10:34Jens GrabowskiNote Added: 0011216
11-12-2012 10:35Jens GrabowskiAssigned ToJens Grabowski => Gyorgy Rethy
14-05-2013 15:20Gyorgy RethyTarget VersionEdition 4.5.1 => v4.7.1 (published 2015-06)
10-07-2013 15:38Gyorgy RethyFile Added: CR5987_resolution_v1.doc
10-07-2013 15:42Gyorgy RethyNote Added: 0011510
10-07-2013 15:42Gyorgy RethyNote Edited: 0011510
10-07-2013 15:42Gyorgy RethyAssigned ToGyorgy Rethy => Jens Grabowski
28-08-2013 11:08Jens GrabowskiFile Added: CR5987_resolution_v2.doc
28-08-2013 11:09Jens GrabowskiNote Added: 0011621
28-08-2013 11:09Jens GrabowskiStatusassigned => resolved
28-08-2013 11:09Jens GrabowskiResolutionopen => fixed
28-08-2013 11:10Jens GrabowskiStatusresolved => feedback
28-08-2013 11:10Jens GrabowskiResolutionfixed => reopened
28-08-2013 11:12Jens GrabowskiAssigned ToJens Grabowski => Ina Schieferdecker
28-08-2013 11:12Jens GrabowskiStatusfeedback => resolved
11-10-2013 11:51Ina SchieferdeckerStatusresolved => closed
11-10-2013 11:51Ina SchieferdeckerNote Added: 0011767
11-10-2013 11:51Ina SchieferdeckerResolutionreopened => fixed
11-10-2013 11:51Ina SchieferdeckerFixed in Version => v4.6.1 (published 2014-06)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010775) +
+ Gyorgy Rethy    +
+ 10-07-2012 18:21    +
+ 		+ + + + +
+ STF discussion 2012-07-10: to be checked
+
+
+
+ + + + + + + + + + +
+ (0010835) +
+ Jens Grabowski    +
+ 11-07-2012 12:23    +
+ 		+ + + + +
+ The standard states in 27.1: "The with statement can be applied to modules, global module definitions and to local definitions in control, test cases, functions, altsteps, statement blocks, and in component type definitions."
+
+I don't see the relation to nested statements. I will ask Andras for an example.
+
+
+
+ + + + + + + + + + +
+ (0011010) +
+ Jens Grabowski    +
+ 09-08-2012 15:14    +
+ 		+ + + + +
+ Email to Andras resent 09.08.12. CR will be closed at the end of the year if no answer is received.
+
+
+
+ + + + + + + + + + +
+ (0011214) +
+ Jens Grabowski    +
+ 11-12-2012 10:18    +
+ 		+ + + + +
+ Answer from Andras:
+
+Am 13.08.2012 11:03, schrieb Andras Kovacs:
+> Dear Jens,
+> I am sorry for being so slow with this answer!
+> It has been some time ago, when dealt with this issue, would have been better to give an example in the CR. I remember the issue being the question of what happens when we have for example the following attribute at the module level:
+> with { optional override "explicit omit"}
+> And the following attribute at the testcase level:
+> with { optional override "implicit omit"}
+>
+> Which override attribute takes precedence in that case? This CR suggests to define a clear rule for such hierarchy.
+>
+> Best regards,
+>
+> Andras Kovacs
+>
+>
+
+
+
+ + + + + + + + + + +
+ (0011216) +
+ Jens Grabowski    +
+ 11-12-2012 10:34    +
+ 		+ + + + +
+ Proposal for resolution:
+
+Add the following sentence on page 211, Section "27.1.2 Overwriting rules for attributes" immediately after the sentence "An attribute definition in a lower scope can be overwritten in a higher scope by using the override directive":
+
+"In case of nested override directives, the override directive of the highest scope shall take precedence."
+
+Assigned to György for crosschecking.
+
+
+
+ + + + + + + + + + +
+ (0011510) +
+ Gyorgy Rethy    +
+ 10-07-2013 15:42    +
+ 		+ + + + +
+ I propose to add the sentence at the end of the clause with some examples. This make the claus's structure more clear: overwriting due to scoping, overriding "simple" rules due to override, relation between override attributes. See proposed text in CR5987_resolution_v1.doc.
+
+Do you agree? Pls. review.
+
+
+
+
+
+ + + + + + + + + + +
+ (0011621) +
+ Jens Grabowski    +
+ 28-08-2013 11:09    +
+ 		+ + + + +
+ OK, only a small typo corrected in v2 of resolution.
+Status changed to resolved, assigned to Ina for implementation.
+
+
+
+ + + + + + + + + + +
+ (0011767) +
+ Ina Schieferdecker    +
+ 11-10-2013 11:51    +
+ 		+ + + + +
+ as proposed
+
+ + diff --git a/docs/mantis/CR5988.md b/docs/mantis/CR5988.md new file mode 100644 index 0000000000000000000000000000000000000000..8d414beff3b22e3b62de1ce4908c2b7dd3880854 --- /dev/null +++ b/docs/mantis/CR5988.md @@ -0,0 +1,241 @@ + + + + + + + + + + + + + 0005988: Scope definition of explicit/implicit omit is poorly phrased in section 27.7 - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005988Part 01: TTCN-3 Core LanguageClarificationpublic17-12-2011 06:3510-08-2012 11:48
ReporterAndras Kovacs 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.3.1 (published 2011-06) 
Target Versionv4.5.1 (published 2013-04)Fixed in Versionv4.5.1 (published 2013-04) 
Clause Reference(s)Core language / section 27.7
Source (company - Author)STF433
Summary0005988: Scope definition of explicit/implicit omit is poorly phrased in section 27.7
DescriptionThe scope of explicit/implicit omit is defined as follows: 'all optional fields, which have not been defined in the definition the attribute is associated with'.
+This sentence is hard to understand, perhaps a better phrasing would be: 'all optional fields, that have no assigned value definition in the statement on which the attribute operates'.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
17-12-2011 06:35Andras KovacsNew Issue
17-12-2011 06:35Andras KovacsClause Reference(s) => Core language / section 27.7
17-12-2011 06:35Andras KovacsSource (company - Author) => STF433
10-07-2012 14:21Gyorgy RethyNote Added: 0010762
10-07-2012 14:21Gyorgy RethyAssigned To => Jens Grabowski
10-07-2012 14:21Gyorgy RethyStatusnew => assigned
10-07-2012 14:21Gyorgy RethyTarget Version => Edition 4.5.1
11-07-2012 12:04Jens GrabowskiNote Added: 0010834
11-07-2012 12:04Jens GrabowskiAssigned ToJens Grabowski => Gyorgy Rethy
12-07-2012 09:55Gyorgy RethyNote Added: 0010860
12-07-2012 09:55Gyorgy RethyAssigned ToGyorgy Rethy => Jens Grabowski
09-08-2012 15:24Jens GrabowskiNote Added: 0011011
09-08-2012 15:25Jens GrabowskiAssigned ToJens Grabowski => Tomas Urban
09-08-2012 17:15Tomas UrbanNote Added: 0011012
09-08-2012 17:15Tomas UrbanAssigned ToTomas Urban => Ina Schieferdecker
10-08-2012 11:48Ina SchieferdeckerNote Added: 0011026
10-08-2012 11:48Ina SchieferdeckerStatusassigned => closed
10-08-2012 11:48Ina SchieferdeckerResolutionopen => fixed
10-08-2012 11:48Ina SchieferdeckerFixed in Version => Edition 4.5.1
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010762) +
+ Gyorgy Rethy    +
+ 10-07-2012 14:21    +
+ 		+ + + + +
+ STF discussion 2012-07-10: wording to be checked
+
+
+
+ + + + + + + + + + +
+ (0010834) +
+ Jens Grabowski    +
+ 11-07-2012 12:04    +
+ 		+ + + + +
+ I am fine with the proposal.
+
+Assigned to György for crosschecking.
+
+
+
+ + + + + + + + + + +
+ (0010860) +
+ Gyorgy Rethy    +
+ 12-07-2012 09:55    +
+ 		+ + + + +
+ Actually, the proposed text would mean that all optional fields not changed by a modified template should be implicitly omitted. This is not our intention. Also, the wording "value assignment" excludes matching mechanisms, template references etc.
+
+I propose another way
+"all optional fields that remain uninitialized after executing the field assignments of the statement on which the attribute operates"
+
+
+
+ + + + + + + + + + +
+ (0011011) +
+ Jens Grabowski    +
+ 09-08-2012 15:24    +
+ 		+ + + + +
+ György's proposal is OK with me. Tomas, can you also crosscheck.
+Assigned to Tomas.
+
+
+
+ + + + + + + + + + +
+ (0011012) +
+ Tomas Urban    +
+ 09-08-2012 17:15    +
+ 		+ + + + +
+ I agree with the text György proposed.
+Assigned to Ina for implementation.
+
+
+
+ + + + + + + + + + +
+ (0011026) +
+ Ina Schieferdecker    +
+ 10-08-2012 11:48    +
+ 		+ + + + +
+ as proposed
+
+ + diff --git a/docs/mantis/CR5989.md b/docs/mantis/CR5989.md new file mode 100644 index 0000000000000000000000000000000000000000..edd577bdf65765f572ef7172af22d7e987af24c0 --- /dev/null +++ b/docs/mantis/CR5989.md @@ -0,0 +1,329 @@ + + + + + + + + + + + + + 0005989: the timestamp parameter ts has no unit - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005989Part 06: TTCN-3 Control InterfaceClarificationpublic21-12-2011 15:0114-12-2012 12:57
ReporterAnthony Baire 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.3.1 (published 2011-06) 
Target Versionv4.5.1 (published 2013-04)Fixed in Versionv4.5.1 (published 2013-04) 
Clause Reference(s)7.3.4.1
Source (company - Author)     
Summary0005989: the timestamp parameter ts has no unit
DescriptionThe TL document does not specify the unit of the timestamp parameter (ts) in each TL operation.
+
+Should it be seconds ? milliseconds ? microseconds ? and which epoch should be used ?
+
+
+Using second may not be granular enough. I would prefer having a stuctured value, like the timeval representation commonly used on POSIX systems:
+
+           struct timeval {
+               time_t tv_sec; /* seconds */
+               suseconds_t tv_usec; /* microseconds */
+           };
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
21-12-2011 15:01Anthony BaireNew Issue
21-12-2011 15:01Anthony BaireClause Reference(s) => 7.3.4.1
21-12-2011 15:01Anthony BaireSource (company - Author) =>
10-07-2012 14:20Gyorgy RethyNote Added: 0010761
10-07-2012 14:20Gyorgy RethyAssigned To => Ina Schieferdecker
10-07-2012 14:20Gyorgy RethyStatusnew => assigned
10-07-2012 14:20Gyorgy RethyResolutionopen => fixed
10-07-2012 14:20Gyorgy RethyTarget Version => Edition 4.5.1
10-07-2012 14:20Gyorgy RethyDescription Updated
13-12-2012 16:22Ina SchieferdeckerNote Added: 0011256
13-12-2012 16:22Ina SchieferdeckerNote Added: 0011257
13-12-2012 16:23Ina SchieferdeckerAssigned ToIna Schieferdecker => Tomas Urban
14-12-2012 08:38Tomas UrbanNote Added: 0011264
14-12-2012 08:38Tomas UrbanAssigned ToTomas Urban => Ina Schieferdecker
14-12-2012 10:38Ina SchieferdeckerNote Added: 0011269
14-12-2012 10:39Ina SchieferdeckerNote Added: 0011270
14-12-2012 10:39Ina SchieferdeckerAssigned ToIna Schieferdecker => Tomas Urban
14-12-2012 12:45Tomas UrbanNote Added: 0011276
14-12-2012 12:45Tomas UrbanAssigned ToTomas Urban => Ina Schieferdecker
14-12-2012 12:57Ina SchieferdeckerNote Added: 0011280
14-12-2012 12:57Ina SchieferdeckerStatusassigned => closed
14-12-2012 12:57Ina SchieferdeckerFixed in Version => Edition 4.5.1
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010761) +
+ Gyorgy Rethy    +
+ 10-07-2012 14:20    +
+ 		+ + + + +
+ STF discussion 2012-07-10: add a note refering to Part-1, where time units are defined in sec/s
+
+
+
+ + + + + + + + + + +
+ (0011256) +
+ Ina Schieferdecker    +
+ 13-12-2012 16:22    +
+ 		+ + + + +
+ Add in "7.3.4.1 TCI TL provided
+This clause specifies the operations the TL shall provide to the TE.
+..."
+
+a note that explains the timestamp:
+
+"7.3.4.1 TCI TL provided
+This clause specifies the operations the TL shall provide to the TE.
+
+Note: A logging event is timestamped by non-negative float values where the base unit is seconds, e.g. millisecond or microsecond precision are possible. The encoding of timestamps as well as their representation in different time formats, e.g. in an execution trace or log file, are tool-specific.
+..."
+
+
+
+ + + + + + + + + + +
+ (0011257) +
+ Ina Schieferdecker    +
+ 13-12-2012 16:22    +
+ 		+ + + + +
+ Please check the note given in the comment above.
+
+
+
+ + + + + + + + + + +
+ (0011264) +
+ Tomas Urban    +
+ 14-12-2012 08:38    +
+ 		+ + + + +
+ I am afraid I cannot completely agree with this solution. First of all, time stamp mapping is platform-specific. There are already two mappings that provide unambiguous time stamps: the C# mapping uses a System.DataTime object and C++ mapping uses the timeval structure. Thus, the problem Anthony mentioned affects only the remaining mappings: java, C and XML (and I guess Anthony had in mind the C mapping in particular). Therefore the solution cannot be a general one as proposed, because it would reduce functionality of C# and C++ versions of the interface.
+
+The proposed change is also not backwards compatible. If we already decide for this kind of change, I would prefer to have a solution that is not tool-specific. Both java and XML contain well-defined representations of time stamps: java.util.Date and xsd:dateTime. The situation is a bit more problematic in case of C, because there's no standardized time stamp implementation. However, I think it would be reasonable to use the timeval structure as in case of C++ mapping (and as proposed by Anthony). The timeval structure is defined in the POSIX standard (the C++ mapping shall contain a reference to this standard, but currently it doesn't).
+
+
+
+ + + + + + + + + + +
+ (0011269) +
+ Ina Schieferdecker    +
+ 14-12-2012 10:38    +
+ 		+ + + + +
+ Revised proposal:
+
+"7.3.4.1 TCI TL provided
+This clause specifies the operations the TL shall provide to the TE.
+
+NOTE: A logging event is timestamped. The timestamps are specific to the language mapping and to the tool used. For example, C# mapping uses System.DataTime objects and C++ mapping uses the POSIX timeval structure. Java, C and XML use integer instead, so that a tool has to choose its timestamp handling. For example, for Java System.currentTimeMillis() could be used or for C time()."
+
+
+
+ + + + + + + + + + +
+ (0011270) +
+ Ina Schieferdecker    +
+ 14-12-2012 10:39    +
+ 		+ + + + +
+ Please check.
+
+
+
+ + + + + + + + + + +
+ (0011276) +
+ Tomas Urban    +
+ 14-12-2012 12:45    +
+ 		+ + + + +
+ I think this solution is the best what we can achieve without resorting to changes that would cause problems with backwards compatibility. So it is fine with me.
+
+
+
+ + + + + + + + + + +
+ (0011280) +
+ Ina Schieferdecker    +
+ 14-12-2012 12:57    +
+ 		+ + + + +
+ Thanks.
+
+ + diff --git a/docs/mantis/CR5990.md b/docs/mantis/CR5990.md new file mode 100644 index 0000000000000000000000000000000000000000..fc926bf13545f4c9f418b1657a57fbf00e3ccb4c --- /dev/null +++ b/docs/mantis/CR5990.md @@ -0,0 +1,321 @@ + + + + + + + + + + + + + 0005990: Various inconsistencies in the XML mapping - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005990Part 06: TTCN-3 Control InterfaceClarificationpublic21-12-2011 17:0712-07-2012 10:18
ReporterAnthony Baire 
Assigned ToIna Schieferdecker 
PrioritynormalSeveritytrivialReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.3.1 (published 2011-06) 
Target Versionv4.5.1 (published 2013-04)Fixed in Versionv4.5.1 (published 2013-04) 
Clause Reference(s)11.4.2.1 B.2 B.5 11.3.2.6 11.3.2.7 11.3.2.9
Source (company - Author)     
Summary0005990: Various inconsistencies in the XML mapping
Description1. In the mapping of TriPortIdListType the name of the elements in the sequence should be "port" instead of "comp"
+
+        <xsd:element name="comp" type="Types:TriPortIdType" minOccurs="0"
+         maxOccurs="unbounded"/>
+-->
+        <xsd:element name="port" type="Types:TriPortIdType" minOccurs="0"
+         maxOccurs="unbounded"/>
+
+
+
+2. The mapping of tliTRunning is not consistent with the mapping of other TL operations: the "status" parameter should be provided as an element
+            <xsd:sequence>
+                <xsd:element name="timer" type="Types:TriTimerIdType"/>
+            </xsd:sequence>
+            <xsd:attribute name="status" type="SimpleTypes:TimerStatusType"/>
+->
+            <xsd:sequence>
+                <xsd:element name="timer" type="Types:TriTimerIdType"/>
+                <xsd:element name="status" type="SimpleTypes:TimerStatusType"/>
+            </xsd:sequence>
+
+
+
+3. The mapping of TriMessageType, TriParameterType and TriAddressType in B.2 is different from their definitions in 11.3.2.6, 11.3.2.7 and 11.3.2.9.
+
+
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR5990.docx (22,833) 11-07-2012 18:09
http://oldforge.etsi.org/mantis/file_download.php?file_id=2681&type=bug
docx CR5990_v2.docx (27,010) 12-07-2012 09:51
http://oldforge.etsi.org/mantis/file_download.php?file_id=2684&type=bug
docx CR5990_v3.docx (27,021) 12-07-2012 10:02
http://oldforge.etsi.org/mantis/file_download.php?file_id=2685&type=bug
Issue History
Date ModifiedUsernameFieldChange
21-12-2011 17:07Anthony BaireNew Issue
21-12-2011 17:07Anthony BaireClause Reference(s) => 11.4.2.1 B.2 B.5 11.3.2.6 11.3.2.7 11.3.2.9
21-12-2011 17:07Anthony BaireSource (company - Author) =>
10-07-2012 15:10Gyorgy RethyNote Added: 0010772
10-07-2012 15:10Gyorgy RethyAssigned To => Ina Schieferdecker
10-07-2012 15:10Gyorgy RethyStatusnew => assigned
10-07-2012 15:10Gyorgy RethyTarget Version => Edition 4.5.1
10-07-2012 15:10Gyorgy RethyDescription Updated
11-07-2012 17:48Ina SchieferdeckerNote Added: 0010851
11-07-2012 17:59Ina SchieferdeckerNote Edited: 0010851
11-07-2012 18:09Ina SchieferdeckerFile Added: CR5990.docx
11-07-2012 18:10Ina SchieferdeckerNote Edited: 0010851
11-07-2012 18:11Ina SchieferdeckerNote Added: 0010854
11-07-2012 18:11Ina SchieferdeckerAssigned ToIna Schieferdecker => Tomas Urban
11-07-2012 18:11Ina SchieferdeckerResolutionopen => fixed
12-07-2012 09:14Tomas UrbanNote Added: 0010856
12-07-2012 09:14Tomas UrbanAssigned ToTomas Urban => Ina Schieferdecker
12-07-2012 09:50Ina SchieferdeckerNote Added: 0010858
12-07-2012 09:51Ina SchieferdeckerFile Added: CR5990_v2.docx
12-07-2012 09:51Ina SchieferdeckerAssigned ToIna Schieferdecker => Tomas Urban
12-07-2012 10:02Ina SchieferdeckerFile Added: CR5990_v3.docx
12-07-2012 10:06Tomas UrbanNote Added: 0010861
12-07-2012 10:06Tomas UrbanAssigned ToTomas Urban => Ina Schieferdecker
12-07-2012 10:18Ina SchieferdeckerStatusassigned => resolved
12-07-2012 10:18Ina SchieferdeckerNote Added: 0010863
12-07-2012 10:18Ina SchieferdeckerStatusresolved => closed
12-07-2012 10:18Ina SchieferdeckerFixed in Version => Edition 4.5.1
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010772) +
+ Gyorgy Rethy    +
+ 10-07-2012 15:10    +
+ 		+ + + + +
+ STF discussion 2012-07-10: to be checked
+
+
+
+ + + + + + + + + + +
+ (0010851) +
+ Ina Schieferdecker    +
+ 11-07-2012 17:48    +
(edited on: 11-07-2012 18:10)
+ 		+ + + + +
+ Wrt. 1: implemented as proposed - in addition, 11.3.2.20 added which defines TriPortIdListType also in that clause
+
+Wrt. 2: as proposed
+
+Wrt. 3: implemented as proposde - in addition:
+- made val in TriMessageType, TriParameterType and in TriAddressType an element as described in 11.3.2.6, 11.3.2.7 and in 11.3.2.9 resp.
+- added paddingBits explainations to 11.3.2.6, 11.3.2.7 and 11.3.2.9
+
+
+
+
+
+ + + + + + + + + + +
+ (0010854) +
+ Ina Schieferdecker    +
+ 11-07-2012 18:11    +
+ 		+ + + + +
+ Please check
+
+
+
+ + + + + + + + + + +
+ (0010856) +
+ Tomas Urban    +
+ 12-07-2012 09:14    +
+ 		+ + + + +
+ I am afraid that there are two issues in the proposed draft.
+
+1. While attribute definitions can be present directly inside a complexType element, elements cannot be used this way. They have to wrapped inside a xsd:sequence, e.g.:
+
+<xsd:complexType name="TriMessageType">
+    <xsd:element attribute name="val" type="xsd:hexBinary"/>
+    <xsd:attribute name="paddingBits" type="xsd:integer" use="optional" default="0"/>
+</xsd:complexType>
+-->
+<xsd:complexType name="TriMessageType">
+    <xsd:sequence>
+        <xsd:element attribute name="val" type="xsd:hexBinary"/>
+    </xsd:sequence>
+    <xsd:attribute name="paddingBits" type="xsd:integer" use="optional" default="0"/>
+</xsd:complexType>
+
+2. It seems that the proposed change in tliTRunning mapping is not present in the draft.
+
+
+
+ + + + + + + + + + +
+ (0010858) +
+ Ina Schieferdecker    +
+ 12-07-2012 09:50    +
+ 		+ + + + +
+ Right: turned val in message, parameter, and address in the XML back to attributes, made it consistent with Annex B and with the explainations.
+
+Added the solution for tliTrunning in v2.
+
+Please check.
+
+
+
+ + + + + + + + + + +
+ (0010861) +
+ Tomas Urban    +
+ 12-07-2012 10:06    +
+ 		+ + + + +
+ Reviewed. No issues found. It can be added to the standard.
+
+
+
+ + + + + + + + + + +
+ (0010863) +
+ Ina Schieferdecker    +
+ 12-07-2012 10:18    +
+ 		+ + + + +
+ Implemented as in v3
+
+ + diff --git a/docs/mantis/CR5991.md b/docs/mantis/CR5991.md new file mode 100644 index 0000000000000000000000000000000000000000..9af3ac122607d771ce9648de78521622f2885190 --- /dev/null +++ b/docs/mantis/CR5991.md @@ -0,0 +1,101 @@ + + + + + + + + + + + + + 0005991: missing definition for TriSignatureIdType - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005991Part 06: TTCN-3 Control InterfaceClarificationpublic21-12-2011 17:1111-07-2012 17:18
ReporterAnthony Baire 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionwon't fix 
PlatformOSOS Version
Product Version 
Target Versionv4.5.1 (published 2013-04)Fixed in Version 
Clause Reference(s)8.3.2 9.5 10.5.2 A
Source (company - Author)     
Summary0005991: missing definition for TriSignatureIdType
DescriptionTriSignatureIdType is defined only in the XML Mapping.
+
+It is not defined in the IDL, C, C++ and Java Mappings.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
21-12-2011 17:11Anthony BaireNew Issue
21-12-2011 17:11Anthony BaireClause Reference(s) => 8.3.2 9.5 10.5.2 A
21-12-2011 17:11Anthony BaireSource (company - Author) =>
10-07-2012 15:01Gyorgy RethyNote Added: 0010768
10-07-2012 15:01Gyorgy RethyAssigned To => Ina Schieferdecker
10-07-2012 15:01Gyorgy RethyStatusnew => assigned
10-07-2012 15:01Gyorgy RethyTarget Version => Edition 4.5.1
10-07-2012 15:01Gyorgy RethyDescription Updated
11-07-2012 17:17Ina SchieferdeckerNote Added: 0010850
11-07-2012 17:18Ina SchieferdeckerStatusassigned => closed
11-07-2012 17:18Ina SchieferdeckerResolutionopen => won't fix
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010768) +
+ Gyorgy Rethy    +
+ 10-07-2012 15:01    +
+ 		+ + + + +
+ STF discussion 2012-07-10: to be checked
+
+
+
+ + + + + + + + + + +
+ (0010850) +
+ Ina Schieferdecker    +
+ 11-07-2012 17:17    +
+ 		+ + + + +
+ The TriSignatureIdType is part of the TRI definitions, there are also the language mappings for C, Java, C++ and C# defined, but none for XML
+
+For the logging interface in TCI however, there is also an XML representation needed so that it is being defined in part 6 and not in part 5.
+
+ + diff --git a/docs/mantis/CR5992.md b/docs/mantis/CR5992.md new file mode 100644 index 0000000000000000000000000000000000000000..d081b575c8c7606c6910c141f6b665da0448f2eb --- /dev/null +++ b/docs/mantis/CR5992.md @@ -0,0 +1,380 @@ + + + + + + + + + + + + + 0005992: TciParameterType allows only TCI Values - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005992Part 06: TTCN-3 Control InterfaceTechnicalpublic21-12-2011 17:1914-12-2012 12:51
ReporterAnthony Baire 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.3.1 (published 2011-06) 
Target Versionv4.5.1 (published 2013-04)Fixed in Versionv4.5.1 (published 2013-04) 
Clause Reference(s)8.3.2.1 9.5 10.5.2.9 11.3.2.7 12.4.2.2
Source (company - Author)     
Summary0005992: TciParameterType allows only TCI Values
DescriptionTciParameterType allows only TCI Values.
+
+However, tliSEnter and tliSLeave may report other kind of parameters. Indeed TTCN-3 functions, testcases, altsteps allow non-value parameters :
+ - templates
+ - port references
+ - timer references
+ - component references
+
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR_5992_v1.docx (435,441) 11-12-2012 15:36
http://oldforge.etsi.org/mantis/file_download.php?file_id=2766&type=bug
docx CR_5992_v2.docx (440,951) 14-12-2012 10:14
http://oldforge.etsi.org/mantis/file_download.php?file_id=2782&type=bug
Issue History
Date ModifiedUsernameFieldChange
21-12-2011 17:19Anthony BaireNew Issue
21-12-2011 17:19Anthony BaireClause Reference(s) => 8.3.2.1 9.5 10.5.2.9 11.3.2.7 12.4.2.2
21-12-2011 17:19Anthony BaireSource (company - Author) =>
10-07-2012 14:18Gyorgy RethyNote Added: 0010760
10-07-2012 14:18Gyorgy RethyAssigned To => Ina Schieferdecker
10-07-2012 14:18Gyorgy RethyStatusnew => assigned
10-07-2012 14:18Gyorgy RethyTarget Version => Edition 4.5.1
13-07-2012 09:38Gyorgy RethyAssigned ToIna Schieferdecker => Tomas Urban
13-07-2012 13:37Tomas UrbanNote Added: 0010922
08-08-2012 11:18Tomas UrbanAssigned ToTomas Urban => Ina Schieferdecker
10-08-2012 12:21Ina SchieferdeckerNote Added: 0011030
10-08-2012 12:21Ina SchieferdeckerAssigned ToIna Schieferdecker => Tomas Urban
11-12-2012 15:36Tomas UrbanFile Added: CR_5992_v1.docx
11-12-2012 15:50Tomas UrbanNote Added: 0011235
11-12-2012 15:50Tomas UrbanAssigned ToTomas Urban => Ina Schieferdecker
14-12-2012 10:10Ina SchieferdeckerFile Added: CR_5992_v2.docx
14-12-2012 10:10Ina SchieferdeckerNote Added: 0011266
14-12-2012 10:11Ina SchieferdeckerNote Added: 0011267
14-12-2012 10:11Ina SchieferdeckerAssigned ToIna Schieferdecker => Tomas Urban
14-12-2012 10:11Ina SchieferdeckerResolutionopen => fixed
14-12-2012 10:11Ina SchieferdeckerFixed in Version => Edition 4.5.1
14-12-2012 10:13Ina SchieferdeckerFile Deleted: CR_5992_v2.docx
14-12-2012 10:14Ina SchieferdeckerFile Added: CR_5992_v2.docx
14-12-2012 12:40Tomas UrbanNote Added: 0011275
14-12-2012 12:41Tomas UrbanAssigned ToTomas Urban => Ina Schieferdecker
14-12-2012 12:51Ina SchieferdeckerNote Added: 0011277
14-12-2012 12:51Ina SchieferdeckerStatusassigned => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010760) +
+ Gyorgy Rethy    +
+ 10-07-2012 14:18    +
+ 		+ + + + +
+ STF discussion 2012-07-10: to be checked
+
+
+
+ + + + + + + + + + +
+ (0010922) +
+ Tomas Urban    +
+ 13-07-2012 13:37    +
+ 		+ + + + +
+ The number of TCI functions affected by this problem is actually wider:
+(TCI-TM)
+tciStartTestCase
+tciTestCaseStarted
+tciTestCaseTerminated
+(TCI-TL)
+tliTcExecute
+tliTcStart
+tliTcStarted
+tliTcTerminated
+tliCStart
+tliSEnter
+tliSLeave
+
+The component type is currently supported by the TCI. There's no dedicated Value class for it, but the Type class contains support for it (see Type.getTypeClass method description in chapter 7.2.2.1).
+
+Adding support for the default, port and timer values is quite simple. It can be done in a similar way as the component type is supported, adding new type tags into the Type.getTypeClass method: DEFAULT, PORT, TIMER. The Type.newInstance description should be extended, saying that instances of default, port, timer and probably component type cannot be created by calling this method and that the method returns distinct value null in these cases.
+
+These changes are quite easy to implement and are backwards compatible as well. It is up to further consideration, whether port, component, timer and default instances should use the Value class in its vanilla form, or whether new dedicated subclasses shall be added to the specification providing extended access to object data (e.g. states, IDs, names etc.).
+
+The situations is more complicated with matching symbols. I have created three possible solutions as an input for further discussion:
+
+1. Null value
+
+A rule shall be added to the TciParameterType definition saying that during the conversion of parameter content into a TCI value object, all occurrences of matching symbols shall be replaced with a distinct value null.
+
+Pros:
+- No change in TCI interface required (no problems with backwards compatibility)
+- Simple to implement by vendors
+
+Cons:
+- Information loss (parameter values or their parts will appear as uninitialized)
+- Not possible to provide matching symbols when starting a test case using the tciStartTestCase function of the TCI-TM interface
+
+2. Dedicated light-weight class for matching symbols
+
+A new class MatchingSymbol shall be added to the chapter 7.2.2.2. This class shall be a subclass of the Value class. It shall contain just one method: TString getTemplateDef(), returning textual definition of the template.
+
+In addition to that, a new isMatchingSymbol method shall be added to the Value class. This method shall return false if a the Value instance contain a value and true if it contains a matching symbol. The reason for adding the method is simple: currently the type tag obtained from the Value.getType().getTypeTag() distincitively identifies the actual class of the Value instance. It allows to safely cast the Value object to the particular subclass and get more details from it. With addition of the MatchingSymbol class, this paradigm will be no longer valid and for languages that do not contain runtime type information (C and in some cases C++), additional information is required to distinguish between standard values and matching symbols.
+
+Note: I also considered use the existing TciValueTemplate class for this purpose. In this scenarion, the TciValueTemplate would be changed so that it is a subclass of the Value class. The benefit of this solution is that no additional class would be necessary. However, I didn't find such a solution suitable. Currently, TciValueTemplate is used in various TLI calls (such as tliMReceive_c) to represent a whole template, so e.g. a record template with matching symbols in its fields is represented by a single TciValueTemplate in these calls. However, when passing such a template as a paremeter in tliSEnter, a RecordValue with TciValueTemplate embedded in it would be passed. Thus there would be an unaxceptable diffence in the way how the class is used in different context. Of course it would be possible to replace all occurrences of TciValueTemplate with Value, but that would cause trouble with backwards compatibility.
+
+Pros:
+- Changes in the TCI interface are minor
+- No backward compatibility issues (only code additions, no modifications or deleting of existing definitions)
+- No information loss
+
+Cons:
+- Not possible to provide matching symbols when starting a test case using the tciStartTestCase function of the TCI-TM interface, as the MatchingSymbol class provides only read access.
+
+3. Dedicated set of classes for matching symbols
+Similar to the previous solution, but instead of one class there would be a whole set of classes representing all matching symbols defined in the core language specification. These classes would contain methods allowing to set the content of matching symbols.
+
+Pros:
+- No backward compatibility issues (only code additions, no modifications or deleting of existing definitions)
+- No information loss
+- It is possible to provide matching symbols when starting a test case using the tciStartTestCase function of the TCI-TM interface, as the new classes grant write access
+
+Cons:
+- Time consuming to write the specification and to implement it
+
+
+
+ + + + + + + + + + +
+ (0011030) +
+ Ina Schieferdecker    +
+ 10-08-2012 12:21    +
+ 		+ + + + +
+ Thank you for the good analysis.
+
+We discussed to go for option 2 and to have a newInstance method for the new subclass, so that also start test case from TM can have template parameters.
+
+If that support is implemented in a TM is due to the tool vendors.
+
+
+
+ + + + + + + + + + +
+ (0011235) +
+ Tomas Urban    +
+ 11-12-2012 15:50    +
+ 		+ + + + +
+ I slightly modified the proposal. It is still very similar to the 2nd option, but there are some important differences:
+
+1. There's no new abstract data type for matching symbols. Instead, the top-level Value data type contains two additional operations: isMatchingSymbol (returns true for matching symbols) and valueToString (for printing value content in the same way as the log operation; can be used for displaying value content)
+
+2. Matching symbols can be created using parseValue operation of the Type abstract data type. The operation requires a string argument, which shall be a value/template in TTCN-3 syntax. The output is either an instance of a Value abstract data type or null in case of failure or missing support from the tool side. This method is an optional part of the TCI.
+
+3. Support for timers, ports, components and defaults is very basic: only type class codes have been added in most mappings and there are no dedicated value data types, because it is not expected the user will modify their values. The new valueToString operation can be used for logging purposes if needed.
+
+Ina could you please check if the draft resolves all the issues mentioned in this CR?
+
+
+
+ + + + + + + + + + +
+ (0011266) +
+ Ina Schieferdecker    +
+ 14-12-2012 10:10    +
+ 		+ + + + +
+ Implemented with some technical and editorial changes
+
+
+
+ + + + + + + + + + +
+ (0011267) +
+ Ina Schieferdecker    +
+ 14-12-2012 10:11    +
+ 		+ + + + +
+ Please check
+
+
+
+ + + + + + + + + + +
+ (0011275) +
+ Tomas Urban    +
+ 14-12-2012 12:40    +
+ 		+ + + + +
+ I am fine with the changes, with one small correction: the "matching_symbol" element shall be added to the ComponentValue definition in Annex B as well.
+
+
+
+ + + + + + + + + + +
+ (0011277) +
+ Ina Schieferdecker    +
+ 14-12-2012 12:51    +
+ 		+ + + + +
+ Thanks.
+
+ + diff --git a/docs/mantis/CR5993.md b/docs/mantis/CR5993.md new file mode 100644 index 0000000000000000000000000000000000000000..5f0c51d639379975658154f6b1e6ce347d8234d2 --- /dev/null +++ b/docs/mantis/CR5993.md @@ -0,0 +1,120 @@ + + + + + + + + + + + + + 0005993: missing parameter in tliXxxxx_m functions (C mapping) - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005993Part 06: TTCN-3 Control InterfaceTechnicalpublic21-12-2011 17:2311-07-2012 18:26
ReporterAnthony Baire 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionno change required 
PlatformOSOS Version
Product Versionv4.3.1 (published 2011-06) 
Target Versionv4.5.1 (published 2013-04)Fixed in Version 
Clause Reference(s)9.4.4.1
Source (company - Author)     
Summary0005993: missing parameter in tliXxxxx_m functions (C mapping)
DescriptionIn the C mapping of the TL, the addrValue parameter is missing in the tliXxxxx_m tliXxxxx_m_MC and tliXxxxx_m_BC functions.
+
+
+ 
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
21-12-2011 17:23Anthony BaireNew Issue
21-12-2011 17:23Anthony BaireClause Reference(s) => 9.4.4.1
21-12-2011 17:23Anthony BaireSource (company - Author) =>
10-07-2012 14:16Gyorgy RethyNote Added: 0010759
10-07-2012 14:16Gyorgy RethyAssigned To => Ina Schieferdecker
10-07-2012 14:16Gyorgy RethyStatusnew => assigned
10-07-2012 14:16Gyorgy RethyTarget Version => Edition 4.5.1
10-07-2012 14:16Gyorgy RethyDescription Updated
11-07-2012 18:25Ina SchieferdeckerNote Added: 0010855
11-07-2012 18:26Ina SchieferdeckerStatusassigned => closed
11-07-2012 18:26Ina SchieferdeckerResolutionopen => no change required
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010759) +
+ Gyorgy Rethy    +
+ 10-07-2012 14:16    +
+ 		+ + + + +
+ STF discussion 2012-07-10: to be checked
+
+
+
+ + + + + + + + + + +
+ (0010855) +
+ Ina Schieferdecker    +
+ 11-07-2012 18:25    +
+ 		+ + + + +
+ See 9.4.4.1, the following operations have the addrValue:
+tliMSend_m
+tliMMismatch_m
+tliMReceive_m
+tliPrCall_m
+tliPrGetCallMismatch_m
+tliPrGetCall_m
+tliPrReply_m
+tliPrGetReplyMismatch_m
+tliPrGetReply_m
+tliPrRaise_m
+tliPrCatchMismatch_m
+tliPrCatch_m
+
+See 9.4.4.1, the following operations have the addrValues:
+tliMSend_m_MC
+tliPrCall_m_MC
+tliPrReply_m_MC
+tliPrRaise_m_MC
+
+The BC operations do not have addresses naturally.
+
+ + diff --git a/docs/mantis/CR5994.md b/docs/mantis/CR5994.md new file mode 100644 index 0000000000000000000000000000000000000000..14dcb793f10ad58b6d13879ed7bb115809fdd5b7 --- /dev/null +++ b/docs/mantis/CR5994.md @@ -0,0 +1,197 @@ + + + + + + + + + + + + + 0005994: AddressValue allows multiples values in the XML mapping - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005994Part 06: TTCN-3 Control InterfaceTechnicalpublic21-12-2011 17:2612-07-2012 13:38
ReporterAnthony Baire 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.3.1 (published 2011-06) 
Target Versionv4.5.1 (published 2013-04)Fixed in Versionv4.5.1 (published 2013-04) 
Clause Reference(s)11.3.3.20 B.3
Source (company - Author)     
Summary0005994: AddressValue allows multiples values in the XML mapping
DescriptionThe XML mapping for AddressValue may contain multiple values. This is kind of strange.
+
+    <xsd:complexType name="AddressValue">
+        <xsd:choice minOccurs="0" maxOccurs="unbounded">
+        ...
+->
+    <xsd:complexType name="AddressValue">
+        <xsd:choice minOccurs="0">
+        ...
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
21-12-2011 17:26Anthony BaireNew Issue
21-12-2011 17:26Anthony BaireClause Reference(s) => 11.3.3.20 B.3
21-12-2011 17:26Anthony BaireSource (company - Author) =>
10-07-2012 14:15Gyorgy RethyNote Added: 0010758
10-07-2012 14:15Gyorgy RethyAssigned To => Ina Schieferdecker
10-07-2012 14:15Gyorgy RethyStatusnew => assigned
10-07-2012 14:15Gyorgy RethyTarget Version => Edition 4.5.1
12-07-2012 10:34Ina SchieferdeckerNote Added: 0010864
12-07-2012 10:35Ina SchieferdeckerNote Added: 0010866
12-07-2012 10:36Ina SchieferdeckerAssigned ToIna Schieferdecker => Tomas Urban
12-07-2012 10:36Ina SchieferdeckerResolutionopen => fixed
12-07-2012 12:04Tomas UrbanNote Added: 0010880
12-07-2012 12:04Tomas UrbanAssigned ToTomas Urban => Ina Schieferdecker
12-07-2012 13:37Ina SchieferdeckerStatusassigned => resolved
12-07-2012 13:37Ina SchieferdeckerStatusresolved => closed
12-07-2012 13:38Ina SchieferdeckerFixed in Version => Edition 4.5.1
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010758) +
+ Gyorgy Rethy    +
+ 10-07-2012 14:15    +
+ 		+ + + + +
+ STF discussion 2012-07-10: we may need several addresses for multicasting. To be checked in the standard.
+
+
+
+ + + + + + + + + + +
+ (0010864) +
+ Ina Schieferdecker    +
+ 12-07-2012 10:34    +
+ 		+ + + + +
+ It should even be resolved into:
+
+-->
+    <xsd:complexType name="AddressValue">
+        <xsd:choice>
+
+meaning that there needs to be an element - if no address value is present, the null element is to be used instead, if it is explicitly omitted, then omit is to be used.
+
+The same fix should be done for AnytypeValue:
+
+    <xsd:complexType name="AddressValue">
+        <xsd:choice minOccurs="0" maxOccurs="unbounded">
+
+-->
+    <xsd:complexType name="AddressValue">
+        <xsd:choice>
+
+Please check.
+
+
+
+ + + + + + + + + + +
+ (0010866) +
+ Ina Schieferdecker    +
+ 12-07-2012 10:35    +
+ 		+ + + + +
+ PS: The addresses in multicasting operations are represented as value lists.
+
+
+
+ + + + + + + + + + +
+ (0010880) +
+ Tomas Urban    +
+ 12-07-2012 12:04    +
+ 		+ + + + +
+ I agree with the proposed changes, just in the fix for AnytypeValue, AddressValue was accidentally used. The correct text would be:
+
+-->
+    <xsd:complexType name="AnytypeValue">
+        <xsd:choice>
+
+With this correction, it can be added to the TCI specification.
+
+ + diff --git a/docs/mantis/CR5995.md b/docs/mantis/CR5995.md new file mode 100644 index 0000000000000000000000000000000000000000..700b23ace4ecdd83372ffe4a614cee42abfe3b70 --- /dev/null +++ b/docs/mantis/CR5995.md @@ -0,0 +1,219 @@ + + + + + + + + + + + + + 0005995: Contradiction between BNF and text of section 27 on the placement of 'with' statement - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005995Part 01: TTCN-3 Core LanguageClarificationpublic28-12-2011 07:2710-07-2012 18:25
ReporterAndras Kovacs 
Assigned ToIna Schieferdecker 
PrioritynormalSeveritymajorReproducibilityN/A
StatusclosedResolutionwon't fix 
PlatformOSOS Version
Product Versionv4.3.1 (published 2011-06) 
Target Versionv4.5.1 (published 2013-04)Fixed in Version 
Clause Reference(s)Core language / section 27
Source (company - Author)STF433
Summary0005995: Contradiction between BNF and text of section 27 on the placement of 'with' statement
DescriptionAccording to BNF, "with" statement is allowed only in the following 3 places:
+1: module part (TTCN3Module ::=...)
+2: module definition part (ModuleDefinition ::=...)
+3: module control block definition (ModuleControlPart ::=...)
+
+However this seems to be in contradiction with the text of section 27, because:
+A: virtually all the examples given in section 27 contradict this
+B: nowhere in the text is such a restriction described on the placement of 'with'
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
28-12-2011 07:27Andras KovacsNew Issue
28-12-2011 07:27Andras KovacsClause Reference(s) => Core language / section 27
28-12-2011 07:27Andras KovacsSource (company - Author) => STF433
28-12-2011 09:06Andras KovacsNote Added: 0010544
28-12-2011 10:24Andras KovacsNote Added: 0010545
10-07-2012 14:13Gyorgy RethyNote Added: 0010757
10-07-2012 14:13Gyorgy RethyAssigned To => Ina Schieferdecker
10-07-2012 14:13Gyorgy RethyStatusnew => assigned
10-07-2012 14:13Gyorgy RethyTarget Version => Edition 4.5.1
10-07-2012 18:21Ina SchieferdeckerNote Added: 0010776
10-07-2012 18:25Ina SchieferdeckerNote Added: 0010778
10-07-2012 18:25Ina SchieferdeckerStatusassigned => closed
10-07-2012 18:25Ina SchieferdeckerResolutionopen => won't fix
10-07-2012 18:25Ina SchieferdeckerNote Edited: 0010776
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010544) +
+ Andras Kovacs    +
+ 28-12-2011 09:06    +
+ 		+ + + + +
+ Correction to the above: the examples in section 27 do not directly contradict the BNF. There are just several examples without a context (i.e. where the declaration has been made). So in light of point B (absence of restriction on where to place the 'with' statement), it is difficult for the reader to get this point. So the placement restriction could be added in the text.
+
+
+
+ + + + + + + + + + +
+ (0010545) +
+ Andras Kovacs    +
+ 28-12-2011 10:24    +
+ 		+ + + + +
+ Also, restriction a) in section 27.7 mentions an attribute directly associated to variable definitions, however according to the BNF a 'with' statement can never directly be associated to a variable definition.
+So reference to variable definitions could be removed from this restriction.
+
+
+
+ + + + + + + + + + +
+ (0010757) +
+ Gyorgy Rethy    +
+ 10-07-2012 14:13    +
+ 		+ + + + +
+ STF discussion 2012-07-10: Check the BNF
+
+
+
+ + + + + + + + + + +
+ (0010776) +
+ Ina Schieferdecker    +
+ 10-07-2012 18:21    +
(edited on: 10-07-2012 18:25)
+ 		+ + + + +
+ With statements are possible end of
+
+ - ModuleDefinition (rule 7)
+ - ComponentDefList(rule 75)
+ - FunctionLocalDef | FunctionLocalInst (rule 163)
+ - AltstepLocalDefList(rule 192)
+ - ModuleControlPart(rule 242)
+ - FunctionLocalDef | FunctionLocalInst(rule 246)
+
+The examples in clause 27 are ok
+
+
+
+
+
+ + + + + + + + + + +
+ (0010778) +
+ Ina Schieferdecker    +
+ 10-07-2012 18:25    +
+ 		+ + + + +
+ Possible places of the with statement are explained in the text (clause 27.1) and are part of the BNF.
+
+ + diff --git a/docs/mantis/CR5996.md b/docs/mantis/CR5996.md new file mode 100644 index 0000000000000000000000000000000000000000..7fea321431ad36ad077e650414a22f779f6b1e85 --- /dev/null +++ b/docs/mantis/CR5996.md @@ -0,0 +1,117 @@ + + + + + + + + + + + + + 0005996: Correct const enumerated example the same way as the type example - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005996Part 01: TTCN-3 Core LanguageEditorialpublic11-01-2012 09:3909-08-2012 13:50
ReporterGyorgy Rethy 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.5.1 (published 2013-04)Fixed in Versionv4.4.1 (published 2012-04) 
Clause Reference(s)6.2.4
Source (company - Author)L.M.Ericsson
Summary0005996: Correct const enumerated example the same way as the type example
DescriptionBased on CR5834 the comment to the type definition of EXAMPLE1 has been corrected
+from:
+"type integer Monday;
+    // This definition causes an error as the name of the type has local or global visibility"
+
+to:
+"type integer Monday;
+    // This definition does not clash with the previous one
+     // as Monday in MyFirstEnumType is of local scope"
+
+However, in the same EXAMPLE1 there is a constant definition that is an example for the same topic that has not been corrected:
+"const integer Monday := 7
+    // This definition causes an error as it reuses the Monday enumeration identifier for a
+    // different TTCN 3 object within the same scope unit"
+
Steps To Reproduce
Additional InformationProposed solutions:
+1) either correct the const example the same way as the type example in CR5834 to:
+const integer Monday := 7
+    //This definition does not clash with the name of the enumerated value
+     // above as Monday in MyFirstEnumType is of local scope
+
+2) or delete the example as it does not gives new information.
TagsNo tags attached.
Relationships
related to 0005834closed Ina Schieferdecker Enumeration values are of local scope - example is to be corrected 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
11-01-2012 09:39Gyorgy RethyNew Issue
11-01-2012 09:39Gyorgy RethyClause Reference(s) => 6.2.4
11-01-2012 09:39Gyorgy RethySource (company - Author) => L.M.Ericsson
10-07-2012 14:05Gyorgy RethyNote Added: 0010756
10-07-2012 14:05Gyorgy RethyAssigned To => Ina Schieferdecker
10-07-2012 14:05Gyorgy RethyStatusnew => assigned
10-07-2012 14:05Gyorgy RethyTarget Version => Edition 4.5.1
13-07-2012 12:49Tomas UrbanNote Added: 0010920
13-07-2012 13:37Tomas UrbanNote Deleted: 0010920
09-08-2012 11:31Gyorgy RethyStatusassigned => resolved
09-08-2012 11:31Gyorgy RethyResolutionopen => fixed
09-08-2012 11:31Gyorgy RethyFixed in Version => Edition 4.5.1
09-08-2012 13:46Ina SchieferdeckerRelationship addedrelated to 0005834
09-08-2012 13:50Ina SchieferdeckerNote Added: 0011006
09-08-2012 13:50Ina SchieferdeckerStatusresolved => closed
09-08-2012 13:50Ina SchieferdeckerFixed in VersionEdition 4.5.1 => Edition 4.4.1 Published 2012-04-01
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010756) +
+ Gyorgy Rethy    +
+ 10-07-2012 14:05    +
+ 		+ + + + +
+ STF discussion 2012-07-10: proposed solution 1, correct the example is agreed.
+
+
+
+ + + + + + + + + + +
+ (0011006) +
+ Ina Schieferdecker    +
+ 09-08-2012 13:50    +
+ 		+ + + + +
+ That const definition has been removed from the text already during the MTS approval process.
+
+ + diff --git a/docs/mantis/CR6007.md b/docs/mantis/CR6007.md new file mode 100644 index 0000000000000000000000000000000000000000..2d514669201ab9ca790605a0281cb494034345e6 --- /dev/null +++ b/docs/mantis/CR6007.md @@ -0,0 +1,172 @@ + + + + + + + + + + + + + 0006007: Clarification for \N{reference} is needed in Table B.1 - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006007Part 01: TTCN-3 Core LanguageClarificationpublic19-01-2012 16:3510-08-2012 11:34
ReporterAndras Kovacs 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.3.1 (published 2011-06) 
Target Versionv4.5.1 (published 2013-04)Fixed in Versionv4.5.1 (published 2013-04) 
Clause Reference(s)Core language / section B.1
Source (company - Author)STF433
Summary0006007: Clarification for \N{reference} is needed in Table B.1
DescriptionSection B.1.5.4 defines \N{reference} as follows:
+'A notation of the form "\N{reference}", where reference is denoting a one-character-length template, constant, variable, formal parameter or module parameter, matches the character in the referenced value or template.'
+
+We assume that the above definition is the correct definition. There is an other definition for \N{reference} in Table B.1, which seems to be different because it talks about a character range instead of a single character, and therefor should be corrected:
+'Match any character within the set of characters, where the set is defined by the referenced definition; see clause B.1.5.4 for more details'
+
+
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR_6007_resolution_v1.doc (119,296) 11-07-2012 10:32
http://oldforge.etsi.org/mantis/file_download.php?file_id=2663&type=bug
Issue History
Date ModifiedUsernameFieldChange
19-01-2012 16:35Andras KovacsNew Issue
19-01-2012 16:35Andras KovacsClause Reference(s) => Core language / section B.1
19-01-2012 16:35Andras KovacsSource (company - Author) => STF433
10-07-2012 14:02Gyorgy RethyNote Added: 0010755
10-07-2012 14:02Gyorgy RethyAssigned To => Gyorgy Rethy
10-07-2012 14:02Gyorgy RethyStatusnew => assigned
10-07-2012 14:02Gyorgy RethyTarget Version => Edition 4.5.1
11-07-2012 10:32Gyorgy RethyFile Added: CR_6007_resolution_v1.doc
11-07-2012 10:34Gyorgy RethyNote Added: 0010812
11-07-2012 10:34Gyorgy RethyAssigned ToGyorgy Rethy => Tomas Urban
11-07-2012 16:50Tomas UrbanNote Added: 0010848
11-07-2012 16:50Tomas UrbanAssigned ToTomas Urban => Ina Schieferdecker
10-08-2012 11:34Ina SchieferdeckerNote Added: 0011024
10-08-2012 11:34Ina SchieferdeckerStatusassigned => closed
10-08-2012 11:34Ina SchieferdeckerResolutionopen => fixed
10-08-2012 11:34Ina SchieferdeckerFixed in Version => Edition 4.5.1
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010755) +
+ Gyorgy Rethy    +
+ 10-07-2012 14:02    +
+ 		+ + + + +
+ STF discussion 2012-07-10: Check in the standard's text.
+
+
+
+ + + + + + + + + + +
+ (0010812) +
+ Gyorgy Rethy    +
+ 11-07-2012 10:34    +
+ 		+ + + + +
+ See proposed text in CR_6007_resolution_v1.doc. Pls. review.
+
+
+
+ + + + + + + + + + +
+ (0010848) +
+ Tomas Urban    +
+ 11-07-2012 16:50    +
+ 		+ + + + +
+ Reviewed. No issues found. It can be added to the standard.
+
+
+
+ + + + + + + + + + +
+ (0011024) +
+ Ina Schieferdecker    +
+ 10-08-2012 11:34    +
+ 		+ + + + +
+ as proposed
+
+ + diff --git a/docs/mantis/CR6008.md b/docs/mantis/CR6008.md new file mode 100644 index 0000000000000000000000000000000000000000..916cc5442318f7bdec1d6fcdcd14e369a8e580af --- /dev/null +++ b/docs/mantis/CR6008.md @@ -0,0 +1,124 @@ + + + + + + + + + + + + + 0006008: Match omit мы undefined value - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006008Part 01: TTCN-3 Core LanguageClarificationpublic19-01-2012 17:1810-07-2012 13:59
ReporterNikolay Pakulin 
Assigned To 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionwon't fix 
PlatformOSOS Version
Product Versionv4.3.1 (published 2011-06) 
Target Versionv4.5.1 (published 2013-04)Fixed in Version 
Clause Reference(s)B 1.1, 6.3
Source (company - Author)ISPRAS, STF 433
Summary0006008: Match omit мы undefined value
DescriptionThe following test case is a refined case when a record, initialized by an array, is matched back agains that array. The pecularity of the test case is that the array contains an undefined element. According to clause 6.3.2.2 corresponding optional field of the record becomes *omit*.
+
+So, the question actually is: how to match an omitted value against an undefined value. What output should the test case produce -- whether full values match or not, whether omitted value matched undefined?
Steps To Reproduce
Additional Informationmodule match_omit_undefined {
+    type record Record {
+        integer a optional
+    }
+    type record length(1) of integer Array;
+    type component MTC {}
+    
+    testcase TC_match_omit_undefined() runs on MTC
+    {
+        var Array array := {-};
+        // recrd.a must be set to omit
+        // TTCN3, v.4.3.1
+        // Clause 6.3.2.2: If an element with an undefined value is assigned to an optional element of the record, this will
+        // cause the optional element to be omitted.
+        var Record recrd := array;
+        var boolean v_match_structured_values := match(recrd, array);
+        var boolean v_match_omit_undefined := match(recrd.a, array[0]);
+   
+        log("Result of matching missing elements: ", v_match_omit_undefined);
+        log("Result of matching structured values: ", v_match_structured_values);
+    }
+    control {
+         execute(TC_match_omit_undefined())
+    }
+}
TagsNo tags attached.
Relationships
related to 0006165closed  Add recof2setof predefined function 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
19-01-2012 17:18Nikolay PakulinNew Issue
19-01-2012 17:18Nikolay PakulinClause Reference(s) => B 1.1, 6.3
19-01-2012 17:18Nikolay PakulinSource (company - Author) => ISPRAS, STF 433
19-01-2012 17:21Nikolay PakulinNote Added: 0010546
10-07-2012 09:32Ina SchieferdeckerRelationship addedrelated to 0006165
10-07-2012 13:59Gyorgy RethyNote Added: 0010754
10-07-2012 13:59Gyorgy RethyStatusnew => closed
10-07-2012 13:59Gyorgy RethyResolutionopen => won't fix
10-07-2012 13:59Gyorgy RethyTarget Version => Edition 4.5.1
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010546) +
+ Nikolay Pakulin    +
+ 19-01-2012 17:21    +
+ 		+ + + + +
+ The title of the CR should read: "Match omit vs undefined value".
+Cyrillic "мы" crawled in due to automatic keyboard layout switcher.
+
+
+
+ + + + + + + + + + +
+ (0010754) +
+ Gyorgy Rethy    +
+ 10-07-2012 13:59    +
+ 		+ + + + +
+ There is no statement that undefined content is changed to omit. According to clause 11.1 restriction d) and e) the assignment recrd := array and both match operations above shall cause an error.
+
+ + diff --git a/docs/mantis/CR6009.md b/docs/mantis/CR6009.md new file mode 100644 index 0000000000000000000000000000000000000000..1f8c5b1f3aade8441d94e397b838d24d42322e53 --- /dev/null +++ b/docs/mantis/CR6009.md @@ -0,0 +1,682 @@ + + + + + + + + + + + + + 0006009: Charstring Pattern Reference Parts should not be allowed - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006009Part 01: TTCN-3 Core LanguageClarificationpublic19-01-2012 17:2321-12-2012 10:48
ReporterBogdan Stanca-Kaposta 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.5.1 (published 2013-04)Fixed in Versionv4.5.1 (published 2013-04) 
Clause Reference(s)B.1.5.2, A.1.6.1.3
Source (company - Author)Bogdan Stanca-Kaposta (Testingtech) STF433
Summary0006009: Charstring Pattern Reference Parts should not be allowed
DescriptionThe two templates from section B.1.5.2 Reference expression / EXAMPLE 2 should not be accepted since only a part of a reference is given.
+
+pattern "{Reg"
+
+is not a valid pattern expression (see BNF 113.PatternElement) since the brace is neither closed nor escaped
+
+Solution: either has to be either escaped or pattern keyword should be removed
+
+template charstring RegExp4 := pattern "\{Reg"
+  or
+template charstring RegExp4 := "{Reg"
+
+so the templates
+
+template charstring RegExp4 := pattern "{Reg";
+template charstring RegExp5 := pattern "Exp1}";
+template charstring RegExp6 := pattern "{RegExp4}{RegExp5}";
+// matches the string "{RegExp1}" only (i.e. shall not be handled as a reference expression
+// after insertion)
+
+have to be changed to:
+
+template charstring RegExp4 := pattern "\{Reg";
+template charstring RegExp5 := pattern "Exp1\}";
+template charstring RegExp6 := pattern "{RegExp4}{RegExp5}";
+// matches the string "{RegExp1}" only (i.e. shall not be handled as a reference expression
+// after insertion)
+
+
+109.CharStringMatch ::= PatternKeyword PatternParticle {"&" PatternParticle}
+110.PatternParticle ::= Pattern | ReferencedValue
+111.PatternKeyword ::= "pattern" 112.Pattern ::= """ {PatternElement} """
+113.PatternElement ::= ("\" ("?" | "*" | "\" | "[" | "]" | "{" | "}" |
+"""
+"w" )) |
+| "|" | "(" | ")" | "#" | "+" | "d" |
+| "t" | "n" | "r" | "s" | "b"
+("?" | "*" | "\" | "|" | "+"
+) | ("[" ["^"] [{PatternChar ["-" PatternChar]}]
+"]") |
+("{" ReferencedValue "}") |
+("\" "N" "{" (ReferencedValue | Type) "}") |
+(""" """) |
+("(" PatternElement ")") |
+("#" (Num |
+("(" Num "," [Num] ")") | ("(" "," Num ")")
+)) |
+PatternChar
+114.PatternChar ::= Char | PatternQuadruple
Steps To Reproduce
Additional Informationsee also mantis issue 0005835
TagsNo tags attached.
Relationships
related to 0006169closed Ina Schieferdecker The pattern char grammar has been mixed up 
related to 0006014closed Ina Schieferdecker Simplifications request for escaping chars inside the string pattern 
Attached Filesdoc CR6009_resolution_v1.doc (104,448) 11-07-2012 17:54
http://oldforge.etsi.org/mantis/file_download.php?file_id=2679&type=bug
doc CR6009_resolution_v2.doc (87,552) 12-07-2012 11:08
http://oldforge.etsi.org/mantis/file_download.php?file_id=2688&type=bug
Issue History
Date ModifiedUsernameFieldChange
19-01-2012 17:23Bogdan Stanca-KapostaNew Issue
19-01-2012 17:23Bogdan Stanca-KapostaClause Reference(s) => B.1.5.2, A.1.6.1.3
19-01-2012 17:23Bogdan Stanca-KapostaSource (company - Author) => Bogdan Stanca-Kaposta (Testingtech) STF433
09-07-2012 16:57Ina SchieferdeckerProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
10-07-2012 12:28Gyorgy RethyNote Added: 0010747
10-07-2012 12:28Gyorgy RethyAssigned To => Gyorgy Rethy
10-07-2012 12:28Gyorgy RethyStatusnew => assigned
10-07-2012 12:28Gyorgy RethyTarget Version => Edition 4.5.1
11-07-2012 17:17Gyorgy RethyNote Edited: 0010747
11-07-2012 17:54Gyorgy RethyFile Added: CR6009_resolution_v1.doc
11-07-2012 17:57Gyorgy RethyNote Added: 0010852
11-07-2012 17:57Gyorgy RethyAssigned ToGyorgy Rethy => Jens Grabowski
12-07-2012 11:08Bogdan Stanca-KapostaFile Added: CR6009_resolution_v2.doc
12-07-2012 11:18Bogdan Stanca-KapostaNote Added: 0010869
12-07-2012 12:27Gyorgy RethyNote Added: 0010881
12-07-2012 12:32Gyorgy RethyNote Edited: 0010881
12-07-2012 13:30Bogdan Stanca-KapostaNote Added: 0010884
12-07-2012 14:34Gyorgy RethyNote Added: 0010887
12-07-2012 14:35Gyorgy RethyNote Edited: 0010887
12-07-2012 14:57Bogdan Stanca-KapostaNote Edited: 0010884
12-07-2012 15:49Jacob Wieland - SpirentNote Added: 0010889
12-07-2012 16:03Jacob Wieland - SpirentNote Added: 0010892
12-07-2012 16:36Jens GrabowskiNote Added: 0010896
12-07-2012 18:34Gyorgy RethyNote Added: 0010905
12-07-2012 18:49Gyorgy RethyNote Added: 0010906
12-07-2012 18:51Gyorgy RethyNote Edited: 0010887
12-07-2012 18:52Gyorgy RethyNote Edited: 0010887
12-07-2012 18:52Gyorgy RethyNote Edited: 0010887
12-07-2012 18:57Gyorgy RethyNote Edited: 0010906
12-07-2012 19:00Gyorgy RethyNote Edited: 0010906
12-07-2012 19:48Gyorgy RethyNote Edited: 0010906
13-07-2012 09:56Jacob Wieland - SpirentNote Added: 0010908
13-07-2012 10:22Jacob Wieland - SpirentNote Edited: 0010908
12-12-2012 09:20Gyorgy RethyAssigned ToJens Grabowski => Tomas Urban
12-12-2012 10:49Ina SchieferdeckerRelationship addedrelated to 0006169
14-12-2012 11:16Tomas UrbanRelationship addedrelated to 0006014
14-12-2012 11:33Tomas UrbanNote Added: 0011273
14-12-2012 11:33Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
19-12-2012 15:28Bogdan Stanca-KapostaNote Added: 0011295
21-12-2012 10:17Gyorgy RethyNote Added: 0011304
21-12-2012 10:19Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
21-12-2012 10:48Ina SchieferdeckerNote Added: 0011306
21-12-2012 10:48Ina SchieferdeckerStatusassigned => closed
21-12-2012 10:48Ina SchieferdeckerResolutionopen => fixed
21-12-2012 10:48Ina SchieferdeckerFixed in Version => Edition 4.5.1
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010747) +
+ Gyorgy Rethy    +
+ 10-07-2012 12:28    +
(edited on: 11-07-2012 17:17)
+ 		+ + + + +
+ STF discussion 2012-07-10:
+Check if there is an ambiguity in the current text and examples.
+
+
+
+
+
+ + + + + + + + + + +
+ (0010852) +
+ Gyorgy Rethy    +
+ 11-07-2012 17:57    +
+ 		+ + + + +
+ The comment is not valid as lonely curly brackets do not have metacharacter meaning (table B.1 clearly shows that only {reference} has a metacharacter meaning).
+
+This clarification and some examples for this has been added to the proposed text in CR6009_resolution_v1.doc. Pls. review it.
+
+
+
+ + + + + + + + + + +
+ (0010869) +
+ Bogdan Stanca-Kaposta    +
+ 12-07-2012 11:18    +
+ 		+ + + + +
+ proposed change base on v1 which complies also with CR 6014
+
+Treating curly brackets with two meaning inside the same context is error prone
+
+Consider a long string which contains a single opening { and afterwards some normal alphanumeric characters. If the { has no special meaning, then it would be natural for someone else to add } (intended as } literal) at a later place.
+
+Suddenly, the pair of brackets { and } gets the reference meaning.
+
+This rule will therefore make such code unmaintainable.
+
+
+
+ + + + + + + + + + +
+ (0010881) +
+ Gyorgy Rethy    +
+ 12-07-2012 12:27    +
(edited on: 12-07-2012 12:32)
+ 		+ + + + +
+ A few years ago I would agree. But now, actually, adding this restriction would cause existing code containing single { without \ to fail. Also, if adding a } to an existing list of characters randomly, it is of very little probability that the new "reference" would match an existing charstring or univ. charstring value or template. It is much more probable, that this simply would cause a semantic checking error. In the rare cases when the new "reference" imitates an existing definition, it will cause a fail or inconc verdict that the testers do debug during functional testing anyway.
+
+So, I stick to leave the standard backward compatible as to my experience the users are much more sensitive to backward compatibility than to correct a new error; even a simplest change takes huge time: write a TR, checking out the code from the version handling system, make the correction, checking the code in, possibly making a new product release if this is in a SW library, administer the TR - all together takes at least half a day, while the technical change is just a few minutes. Also, "old" existing code is normally not touched, just executed as regression test cases. Users expect from a new version of the tool to compile and execute their existing millions of lines of code seemlessly, without changing anything. For this reason even the smallest non-backward compatible change is a very sensitive issue, it shall give a significant value for the user.
+
+
+
+
+
+ + + + + + + + + + +
+ (0010884) +
+ Bogdan Stanca-Kaposta    +
+ 12-07-2012 13:30    +
(edited on: 12-07-2012 14:57)
+ 		+ + + + +
+ I would propose to escalate this to the TTCN-3 users list.
+
+This feature probably has never been used (since not all tools - if any - implement this rule), and I think that the standard changes should improve the life of the other 99.9% that use this special feature of the charstring pattern.
+
+
+
+
+
+ + + + + + + + + + +
+ (0010887) +
+ Gyorgy Rethy    +
+ 12-07-2012 14:34    +
(edited on: 12-07-2012 18:52)
+ 		+ + + + +
+ Where are you taking those strange figures from? I do not know myself how many TTCN-3 users are there as tool vendors do not publish their figures (but I would be interested about your source myself). I know only that our tool Titan do implements patterns as specified today and we have millions of lines of TTCN-3 code and about 3600 active licenses in the company. I really hope that this is just 0,1 % of all TTCN-3 users on the world :-)... but at the same time I have some doubt ...
+
+So, as explained earlier, for Ericsson only the backward-compatible proposal in CR6009_resolution_v1.doc is acceptable.
+
+
+
+
+
+ + + + + + + + + + +
+ (0010889) +
+ Jacob Wieland - Spirent    +
+ 12-07-2012 15:49    +
+ 		+ + + + +
+ Actually, we do not believe that anyone would use this feature willingly as it is simply confusing and will thus yield bad code. We can of course speak only for our users (and extrapolate from that) which use a tool where we explicitly decided not to implement this strange feature and in the last 10 years, no one has complained about missing it.
+
+From my experience with regexp languages in general (and other languages), it is not normal that a part of an expression changes its semantics dependent on another part of the expression which can come MUCH MUCH MUCH later.
+
+Most importantly, the rule about the single { or } also violates the normal compositionality rule for regular expressions, namely that you can compose two valid regular expressions by concatenation and always get a valid regular expression as the result.
+
+
+
+ + + + + + + + + + +
+ (0010892) +
+ Jacob Wieland - Spirent    +
+ 12-07-2012 16:03    +
+ 		+ + + + +
+ Also, pragmatically, no one forces Ericsson to REMOVE the existing feature from their tool, thereby maintaining the possibility for their users to keep their code untouched. As there are also other non-standard-compliant features in existence in that tool, I don't see the relevance to keep the feature in the standard in its current form which can only cause more problems than it solves.
+
+Thus, only for publishing new globally standardized testsuites, this can become an issue and there it is relevant to tag the testsuite with the TTCN-3 edition anyway.
+
+
+
+ + + + + + + + + + +
+ (0010896) +
+ Jens Grabowski    +
+ 12-07-2012 16:36    +
+ 		+ + + + +
+ Even though I am technically on your side, a non backwards compatible change requires an agreement from MTS. After our last non backwards compatible change that we introduced accidentally and which caused problems, I doubt that we will get the agreement.
+
+One way of working towards a removal in the future would be to move the problematic parts into the Annex G "Depreciated language features". I don't know if it can be done here and if this is acceptable for Ericsson.
+
+
+
+ + + + + + + + + + +
+ (0010905) +
+ Gyorgy Rethy    +
+ 12-07-2012 18:34    +
+ 		+ + + + +
+ Jacob, your comment is totally misleading. You are talking about composing references from different patterns that I also think would be a bad code design.
+
+But the feature discussed here is to use a single curly bracket without escaping it (a.k.a escaping is optional). And as this feature has been in the language for a long time and a huge amount of code may use this feature (i.e. matching a single curly bracket as a literal character, without escaping), we do not agree to change the language in a non-backward compatible way without resolving an error and without any major benefit. We do not agree to move this feature to be a deprecated one.
+
+
+
+ + + + + + + + + + +
+ (0010906) +
+ Gyorgy Rethy    +
+ 12-07-2012 18:49    +
(edited on: 12-07-2012 19:48)
+ 		+ + + + +
+ Secondly, this change would cause other technical problems. E.g.
+
+const charstring user:= "me";
+const charstring passw:= "a{bc";
+template charstring temp := pattern "*{user};{passw}*";
+...
+p.send(me);
+p.send(passw);
+p.receive(temp);
+
+this code is working fine today, isn't it? By making escaping for single curly brackets mandatory, this code would become invalid and the use case could not be solved at all, as no one knowns when and at which position passw is containing a curly bracket (pls. note, if there is a pair of curly brackets in passw, the code is still working as references are resolved only once, i.e. the reference {passw} is resolved but then the content of passw is processed literally, i.e. if passw contained "{abc}", temp will match the string containing "me;{abc}").
+
+
+
+
+
+ + + + + + + + + + +
+ (0010908) +
+ Jacob Wieland - Spirent    +
+ 13-07-2012 09:56    +
(edited on: 13-07-2012 10:22)
+ 		+ + + + +
+ No, referencing a charstring *value* (not a pattern) from a pattern automatically quotes all characters in the charstring value which would be special characters in a charstring pattern (to interpret the value as its literal value). Only in the regexp function is a charstring value reinterpreted as a regular expression.
+
+So, even if the feature would be deprecated, the code you provided would still be as valid. The resulting pattern would be: pattern "*me;a\{bc*" which has your desired semantics.
+
+Therefore, I still think that making the feature of single unquoted { or } deprecated is a good compromise which will not break any code, but allow tools to warn users about (or prevent them from) such potentially harmful code. It will not change any semantics whatsoever, but will only deprecate some syntax which is now valid.
+
+The problem of missing compositionality is especially harmful considering the regexp function which can (unfortunately) also take charstring values and reinterpret them as regular expressions. Here, it is even more probable that someone will simply concatenate two or more charstring values which for them are all valid regular expressions (to be arbitrarily received from somewhere) and then give them to the regexp function only to find out at runtime that the resulting regular expression was not valid.
+
+
+
+
+
+ + + + + + + + + + +
+ (0011273) +
+ Tomas Urban    +
+ 14-12-2012 11:33    +
+ 		+ + + + +
+ This issue is a part of several related problems concerning the pattern template rules. The STF 446 has decided to solve these issues by opting for such rule that efficiently excludes any possibility of errors caused by invalid pattern format. Tool vendors can still include their own tool-specific format checks, e.g. warning users when certain characters do not form a valid metacharacters.
+
+Please take a look at resolution a of CR 6014. The STF 446 identified a potential problem mentioned in the discussion concerning automatic escaping of referenced strings inserted into patterns and added such a functionality to the draft.
+
+
+
+ + + + + + + + + + +
+ (0011295) +
+ Bogdan Stanca-Kaposta    +
+ 19-12-2012 15:28    +
+ 		+ + + + +
+ Maybe I missed some of the comments/discussions Threads on this bug. Would it be possible to comment how the {\referenceName} may solve the problem raised in this bug.
+
+Thank you!
+
+STF451
+
+
+
+ + + + + + + + + + +
+ (0011304) +
+ Gyorgy Rethy    +
+ 21-12-2012 10:17    +
+ 		+ + + + +
+ I think that this issue has been handled in 6014 (main text part) and 6169 (BNF), hence this one can be closed with resolution fixed and by a note saying that the technical solution is contained in the above CRs.
+
+
+
+ + + + + + + + + + +
+ (0011306) +
+ Ina Schieferdecker    +
+ 21-12-2012 10:48    +
+ 		+ + + + +
+ Technical solution in 6169 and 6014 - hence closed.
+
+ + diff --git a/docs/mantis/CR6010.md b/docs/mantis/CR6010.md new file mode 100644 index 0000000000000000000000000000000000000000..bad6ed0b3acaf3defd46e4b331c6d15303e3f228 --- /dev/null +++ b/docs/mantis/CR6010.md @@ -0,0 +1,104 @@ + + + + + + + + + + + + + 0006010: Using break at inappropriate places is not only a dynamic error - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006010Part 01: TTCN-3 Core LanguageClarificationpublic03-02-2012 14:2613-07-2012 13:39
ReporterGyorgy Rethy 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.3.2 (interim 2011) 
Target Versionv4.5.1 (published 2013-04)Fixed in Versionv4.5.1 (published 2013-04) 
Clause Reference(s)19.12
Source (company - Author)L.M.Ericson
Summary0006010: Using break at inappropriate places is not only a dynamic error
DescriptionIn clause 19.12, Semantic description, 2nd sentence: "Using break outside the body of a loop (for, while, do-while) or an alternative of an alt or interleave statement shall cause a dynamic error.",
+                        ^ ^
+
+delete the word "dynamic" as using break at inappropriate places may also be discovered by a tool compile time.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR6010-JG-120711.doc (68,608) 11-07-2012 11:38
http://oldforge.etsi.org/mantis/file_download.php?file_id=2668&type=bug
Issue History
Date ModifiedUsernameFieldChange
03-02-2012 14:26Gyorgy RethyNew Issue
03-02-2012 14:26Gyorgy RethyClause Reference(s) => 19.12
03-02-2012 14:26Gyorgy RethySource (company - Author) => L.M.Ericson
10-07-2012 12:28Gyorgy RethyAssigned To => Jens Grabowski
10-07-2012 12:28Gyorgy RethyStatusnew => assigned
10-07-2012 12:28Gyorgy RethyTarget Version => Edition 4.5.1
11-07-2012 11:38Jens GrabowskiNote Added: 0010831
11-07-2012 11:38Jens GrabowskiFile Added: CR6010-JG-120711.doc
11-07-2012 11:42Jens GrabowskiAssigned ToJens Grabowski => Ina Schieferdecker
13-07-2012 13:38Ina SchieferdeckerStatusassigned => resolved
13-07-2012 13:38Ina SchieferdeckerResolutionopen => fixed
13-07-2012 13:39Ina SchieferdeckerStatusresolved => closed
13-07-2012 13:39Ina SchieferdeckerNote Added: 0010923
13-07-2012 13:39Ina SchieferdeckerFixed in Version => Edition 4.5.1
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010831) +
+ Jens Grabowski    +
+ 11-07-2012 11:38    +
+ 		+ + + + +
+ Proposal is OK!
+
+However, the same applies for clause 19.13 "The Continue statement". Complete resolution in attached file.
+
+Assigned to Ina for implementation.
+
+
+
+ + + + + + + + + + +
+ (0010923) +
+ Ina Schieferdecker    +
+ 13-07-2012 13:39    +
+ 		+ + + + +
+ Implemented as proposed.
+
+ + diff --git a/docs/mantis/CR6011.md b/docs/mantis/CR6011.md new file mode 100644 index 0000000000000000000000000000000000000000..e1c4d8e2dde41e83d9e83c41e0b273e134e1255a --- /dev/null +++ b/docs/mantis/CR6011.md @@ -0,0 +1,118 @@ + + + + + + + + + + + + + 0006011: Wording of the restriction (dont mix all import with selective import) doesn't make sense - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006011Part 01: TTCN-3 Core LanguageClarificationpublic03-02-2012 14:4210-07-2012 13:36
ReporterGyorgy Rethy 
Assigned To 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionwon't fix 
PlatformOSOS Version
Product Version 
Target Versionv4.5.1 (published 2013-04)Fixed in Version 
Clause Reference(s)8.2.3.5
Source (company - Author)L.M.Ericsson
Summary0006011: Wording of the restriction (dont mix all import with selective import) doesn't make sense
DescriptionIn clause 8.2.3.5, Restriction a) is: "If all visible definitions of a module are imported by using the all keyword, no other form of import (import of single definitions, import of the same kind, etc.) shall be used for the same import statement."
+
+The BNF doesn't allow mixing import-all and selective import in the same statement.
+import from A all {type all} //syntactically disallowed
+
+Therefore the restriction doesn't make sense today.
+
+Solution:
+a) delete "for the same import statement"
+b) change "for the same import statement" to "for the same import-from module"
+c) delete the whole restriction.
+
+pls. note, that due to import-of-imports, this shall remain to be allowed:
+import from A all;
+import from A {import all}
+that syntactically looks very similar to a sequence of an import-all and a selective import satements:
+import from A all;
+import from A {template all}
+
+therefore solution c) seems to be the most user-friendly.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
03-02-2012 14:42Gyorgy RethyNew Issue
03-02-2012 14:42Gyorgy RethyClause Reference(s) => 8.2.3.5
03-02-2012 14:42Gyorgy RethySource (company - Author) => L.M.Ericsson
19-04-2012 11:31Jacob Wieland - SpirentNote Added: 0010558
10-07-2012 13:36Gyorgy RethyNote Added: 0010753
10-07-2012 13:36Gyorgy RethyStatusnew => closed
10-07-2012 13:36Gyorgy RethyResolutionopen => won't fix
10-07-2012 13:36Gyorgy RethyTarget Version => Edition 4.5.1
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010558) +
+ Jacob Wieland - Spirent    +
+ 19-04-2012 11:31    +
+ 		+ + + + +
+ The BNF simply implements the restriction. So, it is consistent with the restriction. I don't see the problem.
+
+Arguing with a sequence of multiple import statements against a restriction which only restricts single import statements doesn't make sense to me, either.
+
+
+
+ + + + + + + + + + +
+ (0010753) +
+ Gyorgy Rethy    +
+ 10-07-2012 13:36    +
+ 		+ + + + +
+ Leave as is to make the difference between importing the dedfinitions and the import statements visible.
+
+ + diff --git a/docs/mantis/CR6014.md b/docs/mantis/CR6014.md new file mode 100644 index 0000000000000000000000000000000000000000..206435835ab341e1818c132eaaca7ec2111ea420 --- /dev/null +++ b/docs/mantis/CR6014.md @@ -0,0 +1,392 @@ + + + + + + + + + + + + + 0006014: Simplifications request for escaping chars inside the string pattern - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006014Part 01: TTCN-3 Core LanguageTechnicalpublic28-02-2012 11:3721-12-2012 11:34
ReporterBogdan Stanca-Kaposta 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.3.1 (published 2011-06) 
Target Versionv4.5.1 (published 2013-04)Fixed in Versionv4.5.1 (published 2013-04) 
Clause Reference(s)B.1.5.1
Source (company - Author)STF 433
Summary0006014: Simplifications request for escaping chars inside the string pattern
DescriptionThe rules for B.1.5.1 Set expression seems to be too complicated for both TTCN-3 developer and TTCN-3 tester (reader) and hence error prone. In this section there is no need to specify different rules, we propose a simpler formulation.
+
+SIMPLIFIED FORMULATION START:
+
+A list of characters enclosed by a pair of "[" and "]" matches any single character in that list. The set expression is delimited by the "[" "]" symbols. In addition to character literals, it is possible to specify character ranges using the hyphen "-" as separator. The range consist of the character immediately before the separator, the character immediately after it and all characters with a character code between the codes of the two bordering characters.
+
+All charactern also used as metachars must also be escaped (prefixed with "\") inside set expressions if the value of that character should be allowed by that expression.
+
+NOTE 1: Embedded lists are not allowed (for example in pattern "[ab[r-z]]" the second "[" denotes a literal "[", the first "]" closes the list and the second "]" causes an error as no related opening bracket in the pattern).
+
+NOTE2: Using the unescaped characters: #, +, * and ? is not allowed since it does not make sense in the context.
+
+NOTE3: To negate the set place the character "^" at the beginning of the set.
+
+EXAMPLE: (unchanged)
+template charstring RegExp1:= pattern "[a-z]"; // this will match any character from a to z
+template charstring RegExp2:= pattern "[^a-z]"; // this will match any character except a to z
+template charstring RegExp3:= pattern "[AC-E][0-9][0-9][0-9]YKE";
+// RegExp3 will match a string which starts with the letter A or a letter between
+// C and E (but not e.g. B) then has three digits and the letters YKE
+
+SIMPLIFIED FORMULATION END:
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0006009closed Ina Schieferdecker Charstring Pattern Reference Parts should not be allowed 
related to 0006169closed Ina Schieferdecker The pattern char grammar has been mixed up 
Attached Filesdoc CR6014_resolution_v1.doc (116,224) 11-07-2012 17:09
http://oldforge.etsi.org/mantis/file_download.php?file_id=2678&type=bug
doc CR6014_resolution_v2.doc (106,496) 12-07-2012 10:54
http://oldforge.etsi.org/mantis/file_download.php?file_id=2687&type=bug
doc CR6014-resolution-v3.doc (109,056) 10-08-2012 14:12
http://oldforge.etsi.org/mantis/file_download.php?file_id=2720&type=bug
docx CR_6014_v4.docx (59,573) 14-12-2012 11:27
http://oldforge.etsi.org/mantis/file_download.php?file_id=2784&type=bug
docx CR_6014_v5.docx (46,858) 21-12-2012 10:11
http://oldforge.etsi.org/mantis/file_download.php?file_id=2793&type=bug
docx CR_6014_v6.docx (61,680) 21-12-2012 11:33
http://oldforge.etsi.org/mantis/file_download.php?file_id=2795&type=bug
Issue History
Date ModifiedUsernameFieldChange
28-02-2012 11:37Bogdan Stanca-KapostaNew Issue
28-02-2012 11:37Bogdan Stanca-KapostaClause Reference(s) => B.1.5.1
28-02-2012 11:37Bogdan Stanca-KapostaSource (company - Author) => STF 433
10-07-2012 13:23Gyorgy RethyAssigned To => Gyorgy Rethy
10-07-2012 13:23Gyorgy RethyStatusnew => assigned
10-07-2012 13:23Gyorgy RethyTarget Version => Edition 4.5.1
11-07-2012 17:09Gyorgy RethyFile Added: CR6014_resolution_v1.doc
11-07-2012 17:10Gyorgy RethyNote Added: 0010849
11-07-2012 17:16Gyorgy RethyAssigned ToGyorgy Rethy => Jens Grabowski
12-07-2012 10:34Gyorgy RethyNote Added: 0010865
12-07-2012 10:37Gyorgy RethyNote Edited: 0010865
12-07-2012 10:41Gyorgy RethyNote Edited: 0010865
12-07-2012 10:54Bogdan Stanca-KapostaFile Added: CR6014_resolution_v2.doc
12-07-2012 10:59Bogdan Stanca-KapostaNote Added: 0010868
12-07-2012 11:01Bogdan Stanca-KapostaNote Edited: 0010868
12-07-2012 14:24Gyorgy RethyNote Added: 0010886
12-07-2012 14:25Gyorgy RethyNote Edited: 0010886
12-07-2012 15:32Gyorgy RethyNote Edited: 0010886
10-08-2012 14:12Jens GrabowskiFile Added: CR6014-resolution-v3.doc
10-08-2012 14:13Jens GrabowskiNote Added: 0011032
10-08-2012 14:13Jens GrabowskiAssigned ToJens Grabowski => Gyorgy Rethy
12-12-2012 08:30Gyorgy RethyAssigned ToGyorgy Rethy => Tomas Urban
14-12-2012 11:16Tomas UrbanRelationship addedrelated to 0006009
14-12-2012 11:17Tomas UrbanRelationship addedrelated to 0006169
14-12-2012 11:27Tomas UrbanFile Added: CR_6014_v4.docx
14-12-2012 11:28Tomas UrbanNote Added: 0011272
14-12-2012 11:29Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
19-12-2012 15:24Bogdan Stanca-KapostaNote Added: 0011294
21-12-2012 10:11Gyorgy RethyFile Added: CR_6014_v5.docx
21-12-2012 10:13Gyorgy RethyNote Added: 0011302
21-12-2012 10:19Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
21-12-2012 11:32Ina SchieferdeckerNote Added: 0011308
21-12-2012 11:33Ina SchieferdeckerFile Added: CR_6014_v6.docx
21-12-2012 11:33Ina SchieferdeckerStatusassigned => resolved
21-12-2012 11:33Ina SchieferdeckerResolutionopen => fixed
21-12-2012 11:33Ina SchieferdeckerFixed in Version => Edition 4.5.1
21-12-2012 11:33Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010849) +
+ Gyorgy Rethy    +
+ 11-07-2012 17:10    +
+ 		+ + + + +
+ See draft resolution text in CR6014_resolution_v1.doc.
+
+
+
+ + + + + + + + + + +
+ (0010865) +
+ Gyorgy Rethy    +
+ 12-07-2012 10:34    +
(edited on: 12-07-2012 10:41)
+ 		+ + + + +
+ Actually, the proposed simplification would mean non-backward compatible technical change and simply missing to expline all rules (i.e. creating unambiguities). Currently in the standard:
+- [[] and []] are correct sets, but this is not unambiguous from the proposed text;
+- the negation rule cannot be placed in a note, because this is a mandatory rule;
+- it is also not explained that a ^ not in the first position does not have any specific meaning, but when in the first position, it is not member of the set list; e.g. from the proposed text it is unclear what [^^] should do; is it legal or not and what it should match?
+- are empty lists and empty negated lists allowed? this is unclear from the proposal
+- currently the - at the first and last positions and following a first ^ has a literal meaning, at other places it has a metacharacter meaning; but from the proposal it is unclear that e.g. what [-z] should mean? is it a legal set or an erroneous range?
+- currently several metacharacers are allowed without a preceding backslash; removing this rule could invalidate existing valid TTCN-3 codes
+- etc.
+
+Pls. note that a standard is not a user guide. It shall be explicit, complete and precise to allow unambigous tool implementations.
+
+Therefore I tried to make the text more readable but we cannot relax the completeness and the preciseness.
+
+
+
+
+
+ + + + + + + + + + +
+ (0010868) +
+ Bogdan Stanca-Kaposta    +
+ 12-07-2012 10:59    +
(edited on: 12-07-2012 11:01)
+ 		+ + + + +
+ Please note the updated document. I hope this would clarify all the questions.
+
+These changes will eliminate the change of meaning depending on the position of a char inside a pattern.
+
+We think the backward compatibility is not an issue since there are only theoretical relevant cases and are not used in real world implementations. The use of these existing special rules is confusing and makes code unreadable and hard to maintain.
+
+
+
+
+
+ + + + + + + + + + +
+ (0010886) +
+ Gyorgy Rethy    +
+ 12-07-2012 14:24    +
(edited on: 12-07-2012 15:32)
+ 		+ + + + +
+ Unfortunately I cannot neglect the backward compatibility problem like you do. Just the MTAS functional testing code consists of 1,5 million of TTCN-3 lines. And it is using text-based internet protocols like SIP. So, I cannot consider any changes to TTCN-3 patterns as a "theoretical relevant case". For Ericsson all non-backward compatibility cases in the language is a heavily practical issue. More detailed explanation is given in CR 6009.
+
+So, for me still CR6014_resolution_v1.doc is the only possible resolution.
+
+For my own curiosity, I have checked the new examples from CR6014_resolution_v1.doc in a POSIX regexp checker (http://www.zytrax.com/tech/web/regex.htm#experiment [^]) and it gave the same result as the TTCN-3 examples, including the error cases (i.e. - has no metacharacter meaning as the first or last character, escaped or following a first ^; ^ has a literal meaning when not the first character etc. So, it is difficult to claim that the current rules in the standard would be exotic or strange when all Linux/Solaris users are working with similar regex-s.
+
+
+
+
+
+ + + + + + + + + + +
+ (0011032) +
+ Jens Grabowski    +
+ 10-08-2012 14:13    +
+ 		+ + + + +
+ New trial for providing a better text.
+Assigned to György for cross-checking.
+Please also check the examples at the end.
+
+
+
+ + + + + + + + + + +
+ (0011272) +
+ Tomas Urban    +
+ 14-12-2012 11:28    +
+ 		+ + + + +
+ This issue is a part of several related problems concerning the pattern template rules. The STF 446 has decided to solve these issues by opting for such rule that efficiently excludes any possibility of errors caused by invalid pattern format. Tool vendors can still include their own tool-specific format checks, e.g. warning users when certain characters do not form a valid metacharacters.
+
+
+
+ + + + + + + + + + +
+ (0011294) +
+ Bogdan Stanca-Kaposta    +
+ 19-12-2012 15:24    +
+ 		+ + + + +
+ a)
+I'm sorry but there seems that this rule added in V4.docx would make the TTCN-3 users more confuse since no errors would be delivered while compiling and the patterns would have to be validated mainly at runtime.
+
+I this this should not be the goal of a standard.
+
+b)
+The additional {\referenceName} rule just makes the standard even more complicated and the code less readable.
+
+STF451
+
+
+
+ + + + + + + + + + +
+ (0011302) +
+ Gyorgy Rethy    +
+ 21-12-2012 10:13    +
+ 		+ + + + +
+ It is OK with me. In CR_6014_v5.docx there are some editorial changes only: the words saying that referenced objects shall be character values and patterns only is moved to the first paragrapha of the clause, explanations of examples are moved to the EXAMPLE paragraph.
+
+
+
+ + + + + + + + + + +
+ (0011308) +
+ Ina Schieferdecker    +
+ 21-12-2012 11:32    +
+ 		+ + + + +
+ Added v6 with extended BNF rule for new "literal reference".
+Implemented.
+
+ + diff --git a/docs/mantis/CR6015.md b/docs/mantis/CR6015.md new file mode 100644 index 0000000000000000000000000000000000000000..7b97b8df83e74f9c1ff480f1f357ded77c6d7bb2 --- /dev/null +++ b/docs/mantis/CR6015.md @@ -0,0 +1,178 @@ + + + + + + + + + + + + + 0006015: Introduction of triErrorReq for the TRI as it is defined in TCI-CD - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 05: TTCN-3 Runtime Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006015Part 05: TTCN-3 Runtime Interface New Featurepublic05-03-2012 13:0511-12-2012 15:18
Reportertepelmann 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.5.1 (published 2013-04)Fixed in Versionv4.5.1 (published 2013-04) 
Clause Reference(s)201 873-5 V4.3.1 - 5.2
Source (company - Author)     Testing Technologies - tepelmann
Summary0006015: Introduction of triErrorReq for the TRI as it is defined in TCI-CD
DescriptionIn the TRI specification in chapter 5.2. "Error handling" there is nothing stated how to handle "asynchronous" notifications about an unrecoverable error situation in the SA or PA.
+E.g. such a situation can occur at any time when a lower layer indicates an error while processing communication operations like receive, where the layer has been initialized and the receiver thread has been started while mapping a port.
+Like in the TCI-CD required interface we propose to introduce the following method as equivalent for the TRI:
+
+Signature : void triErrorReq(in TString message)
+In Parameters: message: A string value, i.e. the error phrase describing the problem.
+Return Value : void
+Constraint : Shall be called whenever an error situation has occurred.
+Effect : The TE will be notified about an unrecoverable error situation within the SA or PA and forward the error indication to the test management.
Steps To Reproduce
Additional InformationAs an addition to the above proposed method for the TRI interface, for the extended TRI there could be an additional method with a parameter of type Object, where the error can be given in any representation, i.e. as exception.
TagsNo tags attached.
Relationships
parent of 0006176closed Ina Schieferdecker Ext Pack: Extended TRI (ES 202 789) Extension of triErrorReq to Object 
Attached Filesdocx CR6015.docx (53,108) 12-07-2012 17:38
http://oldforge.etsi.org/mantis/file_download.php?file_id=2695&type=bug
docx CR6015_v2.docx (54,760) 13-07-2012 11:34
http://oldforge.etsi.org/mantis/file_download.php?file_id=2699&type=bug
Issue History
Date ModifiedUsernameFieldChange
05-03-2012 13:05tepelmannNew Issue
05-03-2012 13:05tepelmannClause Reference(s) => 201 873-5 V4.3.1 - 5.2
05-03-2012 13:05tepelmannSource (company - Author) => Testing Technologies - tepelmann
10-07-2012 12:13Ina SchieferdeckerProjectTTCN-3 Change Requests => Part 05: TTCN-3 Runtime Interface
10-07-2012 12:15Gyorgy RethyAssigned To => Ina Schieferdecker
10-07-2012 12:15Gyorgy RethyStatusnew => assigned
10-07-2012 12:15Gyorgy RethyTarget Version => Edition 4.5.1
12-07-2012 16:47Ina SchieferdeckerIssue cloned: 0006176
12-07-2012 16:47Ina SchieferdeckerRelationship addedparent of 0006176
12-07-2012 17:38Ina SchieferdeckerFile Added: CR6015.docx
12-07-2012 17:39Ina SchieferdeckerNote Added: 0010903
12-07-2012 17:39Ina SchieferdeckerAssigned ToIna Schieferdecker => Tomas Urban
12-07-2012 17:39Ina SchieferdeckerResolutionopen => fixed
13-07-2012 08:55Tomas UrbanNote Added: 0010907
13-07-2012 08:55Tomas UrbanAssigned ToTomas Urban => Ina Schieferdecker
13-07-2012 11:18Ina SchieferdeckerFile Added: CR6015_v2.docx
13-07-2012 11:20Ina SchieferdeckerFile Deleted: CR6015_v2.docx
13-07-2012 11:20Ina SchieferdeckerFile Added: CR6015_v2.docx
13-07-2012 11:34Ina SchieferdeckerFile Deleted: CR6015_v2.docx
13-07-2012 11:34Ina SchieferdeckerFile Added: CR6015_v2.docx
13-07-2012 11:35Ina SchieferdeckerNote Added: 0010914
13-07-2012 11:35Ina SchieferdeckerStatusassigned => resolved
13-07-2012 11:35Ina SchieferdeckerNote Added: 0010915
13-07-2012 11:35Ina SchieferdeckerStatusresolved => closed
11-12-2012 15:18Ina SchieferdeckerFixed in Version => Edition 4.5.1
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010903) +
+ Ina Schieferdecker    +
+ 12-07-2012 17:39    +
+ 		+ + + + +
+ Please check
+
+
+
+ + + + + + + + + + +
+ (0010907) +
+ Tomas Urban    +
+ 13-07-2012 08:55    +
+ 		+ + + + +
+ I think the proposed draft is OK, but maybe we could consider to extend the description part of the new functions so that it is obvious that the error calls should not be performed when the SA or PA is processing a TRI call from the TE, because this situation is handled by returning TRI_ERROR:
+
+Shall be called whenever an error situation has occurred.
+-->
+(triSAError:) Shall be called by the SA whenever an error situation has occurred, with exceptions of errors that appear during processing of TRI calls initiated by the TE.
+(triPAError:) Shall be called by the PA whenever an error situation has occurred, with exceptions of errors that appear during processing of TRI calls initiated by the TE.
+
+
+
+ + + + + + + + + + +
+ (0010914) +
+ Ina Schieferdecker    +
+ 13-07-2012 11:35    +
+ 		+ + + + +
+ Added the new error handling operations to the IDL spec in Annex A
+
+
+
+ + + + + + + + + + +
+ (0010915) +
+ Ina Schieferdecker    +
+ 13-07-2012 11:35    +
+ 		+ + + + +
+ Implemented as described in v2
+
+ + diff --git a/docs/mantis/CR6016.md b/docs/mantis/CR6016.md new file mode 100644 index 0000000000000000000000000000000000000000..e2078542b8e4f97239d22420d7ba81fc4c208535 --- /dev/null +++ b/docs/mantis/CR6016.md @@ -0,0 +1,415 @@ + + + + + + + + + + + + + 0006016: Ambiguous rules for matching symbols for optional fields - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006016Part 01: TTCN-3 Core LanguageTechnicalpublic09-03-2012 10:1110-08-2012 11:17
ReporterTomas Urban 
Assigned ToIna Schieferdecker 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.3.1 (published 2011-06) 
Target Versionv4.5.1 (published 2013-04)Fixed in Versionv4.5.1 (published 2013-04) 
Clause Reference(s)15.7
Source (company - Author)Elvior
Summary0006016: Ambiguous rules for matching symbols for optional fields
DescriptionThe core language specification v. 4.3.1 contains ambiguous rules for the following matching symbols: any value or none, omit and for the ifpresent attribute.
+
+The table 11 in chapter 15.7. states that the symbols "can be assigned to templates, however when used shall be applied to optional fields of record and set types". Similar rules are provided in the annex B:
+B.1.2.4 Any value or none: "It can be used on values of all types, provided that the template field is declared as optional"
+B.1.2.8 Omitting optional fields: "It can be assigned to templates, but shall only be used in fields of record and set types provided that the fields are optional."
+B.1.4.2 The IfPresent indicator: "This attribute may be used with all the matching mechanisms, provided this field is declared as optional."
+
+These rules obviously forbid using the above mentioned matching symbols in any template which is not an optional record or set field. The question is, what the word "use" stands for. The might be two different interpretations:
+1. "Use" means any kind of operation with the template, including assignment. (e.g. the rule in B.1.2.4 seems to suggest that)
+2. "Use" means only matching operations, i.e. it is legal to assign the symbol to any template, but if the template is used for matching and it does not fulfil the criteria of being applied to an optional field, it produces an error:
+
+type record R { integer field1 optional }
+testcase TC() runs on C
+{
+  template integer vt_1 := *;
+  p1.receive(R:{ field1 := vt_1 }; // legal
+  p1.receive(vt_1); // illegal
+}
+
+The rules specified in the chapter 15.8 seem to use the latter interpretation, because otherwise (using the former interpretation) the template(omit) restriction would make no sense (it would never be possible that the whole template resolves to omit). There are also several examples that allow assigmnent of the above mentioned matching mechanisms to a target that isn't an optional record or set field, e.g.:
+// Example from chapter 15.8
+template(omit) ExampleType exampleOmit := omit;
+// Example 1 in 5.4.1.2
+template MyMessageType MyTemplate (template integer MyFormalParam):=
+{ ... }
+pco1.receive(MyTemplate(omit));
+
+
+Proposal:
+I suggest the rules for handling the above mentioned matching mechanisms should be generalized in a dedicated chapter and made more detailed. The current rules (15.7 table 11, B.1.2.4, B.1.2.8 and B.1.4.2) shall be replaced with a reference to this chapter. The chapter shall contain the following rules:
+
+15.7.5 Matching mechanisms for optional fields
+This chapter specifies rules for the following mechanisms: omit, any value or none and ifpresent. The rules apply also to value lists and complemented value lists containing omit, any value or none or ifpresent on any level of nesting.
+
+The matching mechanisms for optional fields can be assigned only to templates, template variables, template parameters or optional fields of record or set templates. An error shall be produced when these matching mechanisms are assigned to a field of a record of, set of, array, union or anytype template or when used inside a subset or superset.
+
+The matching mechanisms for optional fields can be used for matching only if they are assigned to optional fields of a record or set template.
+
+Example 1:
+type record R
+{
+  integer field1,
+  integer field2 optional
+}
+
+type record of integer RI;
+
+type union U
+{
+   integer option1,
+   charstring option2
+}
+template R t_1 (template integer p_1) :=
+{
+  field1 := 1,
+  field2 := p_1
+}
+...
+template R t_2
+{
+  field1 := 2,
+  field2 := 1 ifpresent // legal: field2 is an optional record field
+}
+var template integer vt_1 := *; // legal: vt_1 is a template variable
+var template RI vt_2 := {1, * }; // legal: * literal is interpretted as
+                                 // AnyElementOrNone
+vt_2 := {1, vt_1}; // illegal: AnyValueOrNone assigned to a record of
+template U t_3 := { option1 := 5 ifpresent } // illegal: ifpresent assigned to
+                                             // a union field
+template integer t_4 := (1, 2, omit); // legal: AnyValueOrNone used in a value
+                                      // list; the same as (1, 2) ifpresent
+
+p1.receive(t_1(omit)); // legal: omit used as a template parameter and the
+                       // parameter is assigned to an optional field. Omit is
+                       // then used for matching the optional field value.
+p1.receive(vt_1); // illegal: vt_1 (containing AnyValueOrNone) is not an
+                  // optional record field, but it is used for matching
+
+
+Compared to the current specification, the suggested rules don't give any room for different interpretations, provide comprehensive and logical functionality and they are in line with other clauses (especially 15.8) and examples.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR6016_resolution_v1.doc (254,464) 07-08-2012 11:39
http://oldforge.etsi.org/mantis/file_download.php?file_id=2707&type=bug
doc CR6016_resolution_v2.doc (191,488) 09-08-2012 17:28
http://oldforge.etsi.org/mantis/file_download.php?file_id=2714&type=bug
doc CR6016_resolution_v3.doc (200,704) 10-08-2012 11:17
http://oldforge.etsi.org/mantis/file_download.php?file_id=2717&type=bug
Issue History
Date ModifiedUsernameFieldChange
09-03-2012 10:11Tomas UrbanNew Issue
09-03-2012 10:11Tomas UrbanClause Reference(s) => 15.7
09-03-2012 10:11Tomas UrbanSource (company - Author) => Elvior
16-05-2012 10:59Jacob Wieland - SpirentNote Added: 0010626
04-07-2012 09:38Tomas UrbanNote Added: 0010668
09-07-2012 16:37Gyorgy RethyProjectPart 09: Using XML with TTCN-3 => Part 01: TTCN-3 Core Language
10-07-2012 12:13Gyorgy RethyNote Added: 0010746
10-07-2012 12:13Gyorgy RethyAssigned To => Gyorgy Rethy
10-07-2012 12:13Gyorgy RethyStatusnew => assigned
10-07-2012 12:13Gyorgy RethyTarget Version => Edition 4.5.1
13-07-2012 13:49Gyorgy RethyNote Added: 0010924
13-07-2012 14:38Gyorgy RethyAssigned ToGyorgy Rethy => Tomas Urban
06-08-2012 10:19Tomas UrbanNote Added: 0010962
06-08-2012 10:19Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
07-08-2012 11:39Gyorgy RethyFile Added: CR6016_resolution_v1.doc
07-08-2012 11:41Gyorgy RethyNote Added: 0010982
07-08-2012 11:41Gyorgy RethyNote Added: 0010983
07-08-2012 11:41Gyorgy RethyNote Added: 0010984
07-08-2012 11:41Gyorgy RethyAssigned ToGyorgy Rethy => Tomas Urban
09-08-2012 17:28Tomas UrbanFile Added: CR6016_resolution_v2.doc
09-08-2012 17:30Tomas UrbanNote Added: 0011013
09-08-2012 17:30Tomas UrbanAssigned ToTomas Urban => Ina Schieferdecker
10-08-2012 10:32Ina SchieferdeckerNote Deleted: 0010984
10-08-2012 10:32Ina SchieferdeckerNote Deleted: 0010983
10-08-2012 11:17Ina SchieferdeckerFile Added: CR6016_resolution_v3.doc
10-08-2012 11:17Ina SchieferdeckerNote Added: 0011021
10-08-2012 11:17Ina SchieferdeckerStatusassigned => closed
10-08-2012 11:17Ina SchieferdeckerResolutionopen => fixed
10-08-2012 11:17Ina SchieferdeckerFixed in Version => Edition 4.5.1
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010626) +
+ Jacob Wieland - Spirent    +
+ 16-05-2012 10:59    +
+ 		+ + + + +
+ In principal I agree (though I think the same rules already are true in the current standard), but I would say that the following sentence
+
+"The matching mechanisms for optional fields can be used for matching only if they are assigned to optional fields of a record or set template."
+
+should be amended with "or if they are used as second argument to the match() operation when the first argument is an optional record or set field."
+
+
+
+ + + + + + + + + + +
+ (0010668) +
+ Tomas Urban    +
+ 04-07-2012 09:38    +
+ 		+ + + + +
+ Could anyone move this issue to the core language category?
+
+
+
+ + + + + + + + + + +
+ (0010746) +
+ Gyorgy Rethy    +
+ 10-07-2012 12:13    +
+ 		+ + + + +
+ STF discussion 2012-07-10:
+Check the issue and the proposal.
+
+
+
+ + + + + + + + + + +
+ (0010924) +
+ Gyorgy Rethy    +
+ 13-07-2012 13:49    +
+ 		+ + + + +
+ Let separate the technical side from the question, how to handle the solution in the standard's text. So, let see the technical question, where *, omit and ifpresent are allowed?
+
+I agree, that this question is somewhat umbigous today.
+
+As all your examples are correct, I suppose that we have a common understanding. Our understanding is that it is not an assignment vs. matching question but rather an top-level-assignment vs. field assignment vs. matching question.
+
+So,
+- at the TOP level, they are allowed to be assigned to any template (template, template var, template par) independent of the type of the template. This also includes template lists and complement lists. But not allowed in subsets and supersets, but this is defined unambiguously.
+Let's borrow one of your examples:
+type union U {
+   integer option1,
+   charstring option2
+}
+template U t_u := *; // is legal
+
+- at the field level, they are allowed to be assigned to optional fields of record and sets only, as in your example:
+template U t_3 := { option1 := 5 ifpresent } // illegal
+
+ or another example:
+template R t_1 (template integer p_1) := { field1 := 1, field2 := *} //OK
+template R t_1 (template integer p_1) := { field1 := *, field2 := 2} //NOK
+
+- at the time of matching (receiving or the match operation), they can be used in optional fields of records and sets only; i.e.
+p.receive (t_u) //shall cause an error
+
+
+The another question is, how to specify these rules in the standard's text.
+Today, we have two places in the standard, where matching mechanisms are specified: clause 15.7 an Annex B. Clause 15.7 in principle contains just a basic information and a reference to Annex B. So, we shouldn't put the above rules there, to avoid inconsistencies with Anex B (that we may have even today). It's better to keep all major rules in Annex B. But Annex B is structured according to the matching mechanisms and this is correct, if someone is searches for rules on how to use an *, he/she should find it in one place. So, what I propose to add the text clarifying the rules for each concerned matching mechanism to its own existing clause, even if this is partly a copy-paste work.
+
+Before going on I would like to know your opinion, if the above is OK, I can continue with proposing a text.
+
+
+
+ + + + + + + + + + +
+ (0010962) +
+ Tomas Urban    +
+ 06-08-2012 10:19    +
+ 		+ + + + +
+ I think the proposed solution is very good. Since you volunteered to write the text, I will reassign the CR to you.
+
+
+
+ + + + + + + + + + +
+ (0010982) +
+ Gyorgy Rethy    +
+ 07-08-2012 11:41    +
+ 		+ + + + +
+ Propoaed resolution is uploaded in file CR6016_resolution_v1.doc. Pls. review.
+
+
+
+ + + + + + + + + + +
+ (0011013) +
+ Tomas Urban    +
+ 09-08-2012 17:30    +
+ 		+ + + + +
+ I agree with the resolution. I only change one word in three place to use the same wording as in the rest of the document.
+Assigned to Ina for implementation.
+
+
+
+ + + + + + + + + + +
+ (0011021) +
+ Ina Schieferdecker    +
+ 10-08-2012 11:17    +
+ 		+ + + + +
+ as proposed with editorial changes
+
+ + diff --git a/docs/mantis/CR6017.md b/docs/mantis/CR6017.md new file mode 100644 index 0000000000000000000000000000000000000000..f21bcc9a45f4e51f00eb329b50456087975e1b0d --- /dev/null +++ b/docs/mantis/CR6017.md @@ -0,0 +1,249 @@ + + + + + + + + + + + + + 0006017: [Part 01: TTCN-3 Core Language] BNF ambiguity for concatenation of string templates - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006017Part 01: TTCN-3 Core LanguageTechnicalpublic16-04-2012 19:5406-08-2012 17:22
ReporterAndras Kovacs 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.5.1 (published 2013-04)Fixed in Versionv4.5.1 (published 2013-04) 
Clause Reference(s)15.11, A.1.6.
Source (company - Author)STF433
Summary0006017: [Part 01: TTCN-3 Core Language] BNF ambiguity for concatenation of string templates
DescriptionBNF 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
TagsNo tags attached.
Relationships
Attached Filesdocx 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 ModifiedUsernameFieldChange
16-04-2012 19:54Andras KovacsNew Issue
16-04-2012 19:54Andras KovacsClause Reference(s) => 15.11, A.1.6.
16-04-2012 19:54Andras KovacsSource (company - Author) => STF433
19-04-2012 11:44Jacob Wieland - SpirentNote Added: 0010559
09-07-2012 16:54Ina SchieferdeckerProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
10-07-2012 12:02Gyorgy RethyNote Added: 0010745
10-07-2012 12:02Gyorgy RethyAssigned To => Tomas Urban
10-07-2012 12:02Gyorgy RethyStatusnew => assigned
10-07-2012 12:02Gyorgy RethyTarget Version => Edition 4.5.1
12-07-2012 11:35Tomas UrbanNote Added: 0010871
12-07-2012 11:35Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
13-07-2012 10:11Gyorgy RethyNote Added: 0010910
13-07-2012 10:12Gyorgy RethyAssigned ToGyorgy Rethy => Tomas Urban
13-07-2012 14:04Tomas UrbanFile Added: CR_6017_resolution_v1.docx
13-07-2012 14:06Tomas UrbanNote Added: 0010926
13-07-2012 14:07Tomas UrbanAssigned ToTomas Urban => Ina Schieferdecker
13-07-2012 14:07Tomas UrbanStatusassigned => resolved
06-08-2012 17:22Ina SchieferdeckerNote Added: 0010978
06-08-2012 17:22Ina SchieferdeckerStatusresolved => closed
06-08-2012 17:22Ina SchieferdeckerResolutionopen => fixed
06-08-2012 17:22Ina SchieferdeckerFixed 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
+
+ + diff --git a/docs/mantis/CR6083.md b/docs/mantis/CR6083.md new file mode 100644 index 0000000000000000000000000000000000000000..1ee68778d72c868d1559742664797fff9239d9f1 --- /dev/null +++ b/docs/mantis/CR6083.md @@ -0,0 +1,96 @@ + + + + + + + + + + + + + 0006083: Incorrect parameters in the different interfaces in the Java mapping - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Extended TRI (ES 202 789)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006083Ext Pack: Extended TRI (ES 202 789)Editorialpublic15-05-2012 18:0011-12-2012 14:10
Reportertepelmann 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv1.2.1 (published 2013-04)Fixed in Versionv1.2.1 (published 2013-04) 
Clause Reference(s)
Source (company - Author)
Summary0006083: Incorrect parameters in the different interfaces in the Java mapping
Description6.5.2.1 Changes to triCommunicationSA
+- remove "in"
+- change TciParameterListType to TciParameterList
+::
+public interface xTriCommunicationSA {
+public TriStatus xtriMapParam(TriPortId compPortId, TriPortId tsiPortId,
+in TciParameterListType paramList);
+// Ref: TRI-Definition 5.5.2.3
+public TriStatus xtriUnmapParam(TriPortId compPortId, TriPortId tsiPortId,
+in TciParameterListType paramList);
+
+
+6.5.2.2 Changes to triCommunicationTE
+- remove in
+  public Value xtriConvert(in Object value, in Type typeHypothesis);
+
+6.5.2.1 Changes to triCommunicationSA
+- second parameter typo
+  // Ref: TRI-Definition 5.5.4.7
+  public TriStatus xtriRaise(TriComponentId componentId, TriPortId tsitPortId,
+      Value sutAddress,
+      TriSignatureId signatureId,
+      Value exc);
+  // Ref: TRI-Definition 5.5.4.8
+  public TriStatus xtriRaiseBC(TriComponentId componentId,
+      TriPortId tsitPortId,
+      TriSignatureId signatureId,
+      Value exc);
+  // Ref: TRI-Definition 5.5.4.9
+  public TriStatus xtriRaiseMC(TriComponentId componentId, TriPortId tsitPortId,
+      TciValueList sutAddresses,
+      TriSignatureId signatureId,
+      Value exc);
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0006378closed Ina Schieferdecker Java mapping: invalid syntax and type names 
related to 0006380closed Ina Schieferdecker Java mapping: misspelled parameter name 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
15-05-2012 18:00tepelmannNew Issue
10-07-2012 12:00Gyorgy RethyStatusnew => assigned
10-07-2012 12:00Gyorgy RethyAssigned To => Ina Schieferdecker
10-12-2012 16:58Gyorgy RethyTarget Version => Edition 1.2.1 (ongoing)
11-12-2012 14:09Ina SchieferdeckerNote Added: 0011226
11-12-2012 14:10Ina SchieferdeckerStatusassigned => resolved
11-12-2012 14:10Ina SchieferdeckerResolutionopen => fixed
11-12-2012 14:10Ina SchieferdeckerFixed in Version => Edition 1.2.1 (ongoing)
11-12-2012 14:10Ina SchieferdeckerStatusresolved => closed
11-12-2012 14:11Ina SchieferdeckerRelationship addedrelated to 0006378
11-12-2012 14:23Ina SchieferdeckerRelationship addedrelated to 0006380
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011226) +
+ Ina Schieferdecker    +
+ 11-12-2012 14:09    +
+ 		+ + + + +
+ Implemented as proposed.
+
+ + diff --git a/docs/mantis/CR6084.md b/docs/mantis/CR6084.md new file mode 100644 index 0000000000000000000000000000000000000000..ffb8dbe14d31affde4a6676d142fe4c63ccd73f5 --- /dev/null +++ b/docs/mantis/CR6084.md @@ -0,0 +1,78 @@ + + + + + + + + + + + + + 0006084: Parameter typo tsitPortId in interface of the Java mapping - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 05: TTCN-3 Runtime Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006084Part 05: TTCN-3 Runtime Interface Editorialpublic15-05-2012 18:0612-07-2012 16:43
Reportertepelmann 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.3.1 (published 2011-06) 
Target Versionv4.5.1 (published 2013-04)Fixed in Versionv4.5.1 (published 2013-04) 
Clause Reference(s)6.5.2.1
Source (company - Author)   Testing Technologies IST GmbH - tepelmann
Summary0006084: Parameter typo tsitPortId in interface of the Java mapping
Description6.5.2.1 triCommunicationSA
+// Ref: TRI-Definition 5.5.4.7
+public TriStatus triRaise(TriComponentId componentId, TriPortId tsitPortId,
+        TriAddress sutAddress,
+        TriSignatureId signatureId,
+        TriException exc);
+// Ref: TRI-Definition 5.5.4.8
+public TriStatus triRaiseBC(TriComponentId componentId,
+        TriPortId tsitPortId,
+        TriSignatureId signatureId,
+        TriException exc);
+// Ref: TRI-Definition 5.5.4.9
+public TriStatus triRaiseMC(TriComponentId componentId, TriPortId tsitPortId,
+        TriAddresses sutAddresses,
+        TriSignatureId signatureId,
+        TriException exc);
Steps To Reproduce
Additional InformationProduct Version is in fact 4.4.1
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
15-05-2012 18:06tepelmannNew Issue
15-05-2012 18:06tepelmannClause Reference(s) => 6.5.2.1
15-05-2012 18:06tepelmannSource (company - Author) => Testing Technologies IST GmbH - tepelmann
10-07-2012 12:00Gyorgy RethyAssigned To => Ina Schieferdecker
10-07-2012 12:00Gyorgy RethyStatusnew => assigned
10-07-2012 12:00Gyorgy RethyTarget Version => Edition 4.5.1
12-07-2012 16:43Ina SchieferdeckerNote Added: 0010900
12-07-2012 16:43Ina SchieferdeckerStatusassigned => resolved
12-07-2012 16:43Ina SchieferdeckerResolutionopen => fixed
12-07-2012 16:43Ina SchieferdeckerStatusresolved => closed
12-07-2012 16:43Ina SchieferdeckerFixed in Version => Edition 4.5.1
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010900) +
+ Ina Schieferdecker    +
+ 12-07-2012 16:43    +
+ 		+ + + + +
+ Corrected as proposed.
+
+ + diff --git a/docs/mantis/CR6085.md b/docs/mantis/CR6085.md new file mode 100644 index 0000000000000000000000000000000000000000..07dc882029965e9ea57520502d3fab729982d309 --- /dev/null +++ b/docs/mantis/CR6085.md @@ -0,0 +1,134 @@ + + + + + + + + + + + + + 0006085: Parameter hostId is used incorrectly based on the description - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006085Part 06: TTCN-3 Control InterfaceTechnicalpublic15-05-2012 18:1112-07-2012 14:06
Reportertepelmann 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.3.1 (published 2011-06) 
Target Versionv4.5.1 (published 2013-04)Fixed in Versionv4.5.1 (published 2013-04) 
Clause Reference(s)7.3.3.2.13, 7.3.3.1.5
Source (company - Author)     Testing Technologies IST GmbH
Summary0006085: Parameter hostId is used incorrectly based on the description
Description7.3.3.2.13 tciCreateTestComponentReq should have parameter hostId
+7.3.3.1.5 tciCreateTestComponent should not have parameter hostId
+
Steps To Reproduce
Additional InformationIn fact it applies for version 4.4.1 too.
TagsNo tags attached.
Relationships
Attached Filesdocx CR6085.docx (22,921) 12-07-2012 10:51
http://oldforge.etsi.org/mantis/file_download.php?file_id=2686&type=bug
Issue History
Date ModifiedUsernameFieldChange
15-05-2012 18:11tepelmannNew Issue
15-05-2012 18:11tepelmannClause Reference(s) => 7.3.3.2.13, 7.3.3.1.5
15-05-2012 18:11tepelmannSource (company - Author) => Testing Technologies IST GmbH
10-07-2012 11:57Gyorgy RethyNote Added: 0010744
10-07-2012 11:57Gyorgy RethyAssigned To => Ina Schieferdecker
10-07-2012 11:57Gyorgy RethyStatusnew => assigned
10-07-2012 11:57Gyorgy RethyTarget Version => Edition 4.5.1
12-07-2012 10:51Ina SchieferdeckerFile Added: CR6085.docx
12-07-2012 10:52Ina SchieferdeckerNote Added: 0010867
12-07-2012 10:53Ina SchieferdeckerAssigned ToIna Schieferdecker => Tomas Urban
12-07-2012 10:53Ina SchieferdeckerResolutionopen => fixed
12-07-2012 11:52Tomas UrbanNote Added: 0010877
12-07-2012 11:53Tomas UrbanAssigned ToTomas Urban => Ina Schieferdecker
12-07-2012 14:06Ina SchieferdeckerStatusassigned => resolved
12-07-2012 14:06Ina SchieferdeckerStatusresolved => closed
12-07-2012 14:06Ina SchieferdeckerFixed in Version => Edition 4.5.1
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010744) +
+ Gyorgy Rethy    +
+ 10-07-2012 11:57    +
+ 		+ + + + +
+ STF discussion 2012-07-10:
+Issue to be analysed.
+
+
+
+ + + + + + + + + + +
+ (0010867) +
+ Ina Schieferdecker    +
+ 12-07-2012 10:52    +
+ 		+ + + + +
+ As proposed, IDL needs to be fixed - see resolution. Please check.
+
+
+
+ + + + + + + + + + +
+ (0010877) +
+ Tomas Urban    +
+ 12-07-2012 11:52    +
+ 		+ + + + +
+ Reviewed. No issues found. It can be added to the standard.
+
+ + diff --git a/docs/mantis/CR6086.md b/docs/mantis/CR6086.md new file mode 100644 index 0000000000000000000000000000000000000000..505b00465f6ffd01f01d49cb61fcb01883ce010e --- /dev/null +++ b/docs/mantis/CR6086.md @@ -0,0 +1,132 @@ + + + + + + + + + + + + + 0006086: Parameter name missing - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006086Part 06: TTCN-3 Control InterfaceNew Featurepublic15-05-2012 18:1214-12-2012 10:17
Reportertepelmann 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.3.1 (published 2011-06) 
Target Versionv4.5.1 (published 2013-04)Fixed in Versionv4.5.1 (published 2013-04) 
Clause Reference(s)8.3.2.12
Source (company - Author)     Testing Technologies IST GmbH - tepelmann
Summary0006086: Parameter name missing
Description8.3.2.13 TciParameterTypeType should also have getParameterName()
+
Steps To Reproduce
Additional InformationIn fact it applies for version 4.4.1 too.
TagsNo tags attached.
Relationships
Attached Filesdocx CR6068.docx (21,464) 14-12-2012 08:03
http://oldforge.etsi.org/mantis/file_download.php?file_id=2778&type=bug
docx CR6068_v2.docx (23,804) 14-12-2012 10:13
http://oldforge.etsi.org/mantis/file_download.php?file_id=2781&type=bug
Issue History
Date ModifiedUsernameFieldChange
15-05-2012 18:12tepelmannNew Issue
15-05-2012 18:12tepelmannClause Reference(s) => 8.3.2.12
15-05-2012 18:12tepelmannSource (company - Author) => Testing Technologies IST GmbH - tepelmann
10-07-2012 11:55Gyorgy RethyAssigned To => Ina Schieferdecker
10-07-2012 11:55Gyorgy RethyStatusnew => assigned
10-07-2012 11:55Gyorgy RethyTarget Version => Edition 4.5.1
12-07-2012 16:03Ina SchieferdeckerNote Added: 0010893
14-12-2012 07:41Ina SchieferdeckerNote Deleted: 0010893
14-12-2012 08:03Ina SchieferdeckerFile Added: CR6068.docx
14-12-2012 08:04Ina SchieferdeckerNote Added: 0011263
14-12-2012 08:04Ina SchieferdeckerAssigned ToIna Schieferdecker => Tomas Urban
14-12-2012 09:00Tomas UrbanFile Added: CR6068_v2.docx
14-12-2012 09:01Tomas UrbanNote Added: 0011265
14-12-2012 09:01Tomas UrbanAssigned ToTomas Urban => Ina Schieferdecker
14-12-2012 10:12Ina SchieferdeckerFile Deleted: CR6068_v2.docx
14-12-2012 10:13Tomas UrbanFile Added: CR6068_v2.docx
14-12-2012 10:16Ina SchieferdeckerNote Added: 0011268
14-12-2012 10:16Ina SchieferdeckerStatusassigned => resolved
14-12-2012 10:16Ina SchieferdeckerResolutionopen => fixed
14-12-2012 10:16Ina SchieferdeckerFixed in Version => Edition 4.5.1
14-12-2012 10:17Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011263) +
+ Ina Schieferdecker    +
+ 14-12-2012 08:04    +
+ 		+ + + + +
+ Please check.
+
+
+
+ + + + + + + + + + +
+ (0011265) +
+ Tomas Urban    +
+ 14-12-2012 09:01    +
+ 		+ + + + +
+ It is generally OK, only C# mapping was missing, so I added it and changed one sentence in C++ mapping. Please see the attached draft.
+
+
+
+ + + + + + + + + + +
+ (0011268) +
+ Ina Schieferdecker    +
+ 14-12-2012 10:16    +
+ 		+ + + + +
+ Implemented
+
+ + diff --git a/docs/mantis/CR6087.md b/docs/mantis/CR6087.md new file mode 100644 index 0000000000000000000000000000000000000000..e1dc3a48454df3930906d42e38307e8e76d8697e --- /dev/null +++ b/docs/mantis/CR6087.md @@ -0,0 +1,98 @@ + + + + + + + + + + + + + 0006087: Incorrect return type of getModuleParameterName - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006087Part 06: TTCN-3 Control InterfaceTechnicalpublic15-05-2012 18:1412-07-2012 14:18
Reportertepelmann 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.3.1 (published 2011-06) 
Target Versionv4.5.1 (published 2013-04)Fixed in Versionv4.5.1 (published 2013-04) 
Clause Reference(s)8.3.2.11
Source (company - Author)Testing Technologies IST GmbH
Summary0006087: Incorrect return type of getModuleParameterName
Description8.3.2.11 TciModuleParameterType getModuleParameterName() should return TciModuleParameterId as this is a qualified name
+
Steps To Reproduce
Additional InformationIn fact it applies for version 4.4.1 too
TagsNo tags attached.
Relationships
Attached Filesdocx CR6087.docx (17,060) 12-07-2012 11:27
http://oldforge.etsi.org/mantis/file_download.php?file_id=2689&type=bug
Issue History
Date ModifiedUsernameFieldChange
15-05-2012 18:14tepelmannNew Issue
15-05-2012 18:14tepelmannClause Reference(s) => 8.3.2.11
15-05-2012 18:14tepelmannSource (company - Author) => Testing Technologies IST GmbH
10-07-2012 11:54Gyorgy RethyAssigned To => Ina Schieferdecker
10-07-2012 11:54Gyorgy RethyStatusnew => assigned
10-07-2012 11:54Gyorgy RethyTarget Version => Edition 4.5.1
12-07-2012 11:26Ina SchieferdeckerNote Added: 0010870
12-07-2012 11:27Ina SchieferdeckerFile Added: CR6087.docx
12-07-2012 11:27Ina SchieferdeckerAssigned ToIna Schieferdecker => Tomas Urban
12-07-2012 11:27Ina SchieferdeckerResolutionopen => fixed
12-07-2012 11:45Tomas UrbanNote Added: 0010876
12-07-2012 11:45Tomas UrbanAssigned ToTomas Urban => Ina Schieferdecker
12-07-2012 14:17Ina SchieferdeckerStatusassigned => resolved
12-07-2012 14:18Ina SchieferdeckerStatusresolved => closed
12-07-2012 14:18Ina SchieferdeckerFixed in Version => Edition 4.5.1
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010870) +
+ Ina Schieferdecker    +
+ 12-07-2012 11:26    +
+ 		+ + + + +
+ ModuleParamterId/qualified names already used in the C++, C# and XML mapping, to be fixed in the Java and the C mapping - see file. Please check.
+
+
+
+ + + + + + + + + + +
+ (0010876) +
+ Tomas Urban    +
+ 12-07-2012 11:45    +
+ 		+ + + + +
+ Review. No issues found. It can be added to the standard.
+
+ + diff --git a/docs/mantis/CR6088.md b/docs/mantis/CR6088.md new file mode 100644 index 0000000000000000000000000000000000000000..c8890e88494af7dc9b49898d7604a50947575da3 --- /dev/null +++ b/docs/mantis/CR6088.md @@ -0,0 +1,1198 @@ + + + + + + + + + + + + + 0006088: superset/subset/permutation/complement should also be possible with dynamic lists - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006088Part 01: TTCN-3 Core LanguageNew Featurepublic16-05-2012 12:2809-08-2012 13:57
ReporterJacob Wieland - Spirent 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.5.1 (published 2013-04)Fixed in Versionv4.5.1 (published 2013-04) 
Clause Reference(s)B.1.2.2, B.1.2.6, B.1.2.7
Source (company - Author)Testing Technologies - Jacob Wieland
Summary0006088: superset/subset/permutation/complement should also be possible with dynamic lists
DescriptionAt the moment, the superset/subset constructions are very restricted in their usefulness as the number of different templates, i.e. the size of the set to be matched against, given to them need to be known already statically.
+
+However, there are situations where the set to be matched against can only be determined dynamically during the course of a testcase. For this, in current TTCN-3, complex for-if-match constructions need to be used to replace simple subset/superset expressions to arrive at the same semantic result.
+
+While it is possible to extract such matching constructs into functions, these have the drawbacks that they cannot be used as matching mechanisms and also need to be type-safe (so they need to be redefined for every set element type or using generics).
+
+To amend these drawbacks, the following construct could be introduced:
+
+subset <set_of_elements>
+
+where <set_of_elements> is a list value or template (i.e. of a record of or set of type of the element type of the subset construct).
+
+Examples:
+
+subset { 1, 2, 3 } is the same as subset (1, 2, 3)
+
+type set of integer int_list;
+
+function is_subset(int_list numbers1, template int_list numbers2) return boolean {
+  return match(numbers1, subset numbers2);
+}
+
+function is_element(integer num, int_list numbers) return boolean {
+   return match({num}, subset numbers2);
+}
+
+function equals(int_list numbers1, int_list numbers2) return boolean {
+  return
+    match(numbers1, subset numbers2) and
+    match(numbers1, superset numbers2);
+}
+
+Restrictions:
+
+If a template is given to the subset/superset matching mechanism as argument, the template shall not resolve to the matching mechanisms Any, complement, subset, superset (basically, only an actual list of templates is allowed).
+
+The matching mechanism AnyElementsOrNone directly inside the set-of template given to subset/superset is not allowed.
+
+For consistency's sake, all similar constructions (i.e. permutation/complement, the 'from' clause in receive statements and the 'to' clause in send statements) should also allow such dynamic list templates.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0006165closed  Add recof2setof predefined function 
Attached Filesdoc CR_6088.doc (80,384) 11-07-2012 09:08
http://oldforge.etsi.org/mantis/file_download.php?file_id=2661&type=bug
doc CR_6088_v2.doc (118,784) 11-07-2012 15:53
http://oldforge.etsi.org/mantis/file_download.php?file_id=2675&type=bug
doc CR_6088_v3.doc (141,312) 12-07-2012 09:14
http://oldforge.etsi.org/mantis/file_download.php?file_id=2682&type=bug
doc CR_6088_v4.doc (146,944) 12-07-2012 12:02
http://oldforge.etsi.org/mantis/file_download.php?file_id=2691&type=bug
doc CR_6088_v5.doc (147,456) 12-07-2012 17:38
http://oldforge.etsi.org/mantis/file_download.php?file_id=2694&type=bug
doc CR_6088_v6.doc (130,048) 12-07-2012 18:01
http://oldforge.etsi.org/mantis/file_download.php?file_id=2696&type=bug
doc CR_6088_v7.doc (137,216) 13-07-2012 15:22
http://oldforge.etsi.org/mantis/file_download.php?file_id=2703&type=bug
doc CR_6088_v8doc.doc (144,896) 09-08-2012 13:39
http://oldforge.etsi.org/mantis/file_download.php?file_id=2713&type=bug
Issue History
Date ModifiedUsernameFieldChange
16-05-2012 12:28Jacob Wieland - SpirentNew Issue
16-05-2012 12:28Jacob Wieland - SpirentClause Reference(s) => B.1.2.2, B.1.2.6, B.1.2.7
16-05-2012 12:28Jacob Wieland - SpirentSource (company - Author) => Testing Technologies - Jacob Wieland
09-07-2012 16:58Ina SchieferdeckerProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
09-07-2012 16:58Gyorgy RethyNote Added: 0010724
10-07-2012 11:53Gyorgy RethyNote Added: 0010743
10-07-2012 11:53Gyorgy RethyAssigned To => Gyorgy Rethy
10-07-2012 11:53Gyorgy RethyStatusnew => assigned
10-07-2012 11:53Gyorgy RethyTarget Version => Edition 4.5.1
10-07-2012 11:59Gyorgy RethyRelationship addedrelated to 0006165
10-07-2012 12:53Jacob Wieland - SpirentNote Added: 0010750
10-07-2012 15:08Gyorgy RethyNote Added: 0010771
10-07-2012 15:09Gyorgy RethyAssigned ToGyorgy Rethy => Tomas Urban
10-07-2012 18:08Jacob Wieland - SpirentNote Added: 0010773
11-07-2012 09:08Tomas UrbanFile Added: CR_6088.doc
11-07-2012 09:20Tomas UrbanNote Added: 0010789
11-07-2012 09:21Tomas UrbanAssigned ToTomas Urban => Jens Grabowski
11-07-2012 10:57Jacob Wieland - SpirentNote Added: 0010824
11-07-2012 11:14Jens GrabowskiNote Added: 0010827
11-07-2012 11:14Jens GrabowskiAssigned ToJens Grabowski => Tomas Urban
11-07-2012 11:23Jacob Wieland - SpirentNote Added: 0010829
11-07-2012 14:03Gyorgy RethyNote Added: 0010836
11-07-2012 15:53Tomas UrbanFile Added: CR_6088_v2.doc
11-07-2012 15:59Tomas UrbanNote Added: 0010839
11-07-2012 16:00Tomas UrbanAssigned ToTomas Urban => Jens Grabowski
12-07-2012 09:14Gyorgy RethyFile Added: CR_6088_v3.doc
12-07-2012 09:15Gyorgy RethyNote Added: 0010857
12-07-2012 09:26Gyorgy RethyNote Edited: 0010857
12-07-2012 11:35Jacob Wieland - SpirentNote Added: 0010872
12-07-2012 11:37Jacob Wieland - SpirentNote Added: 0010873
12-07-2012 12:01Gyorgy RethyNote Added: 0010879
12-07-2012 12:02Gyorgy RethyFile Added: CR_6088_v4.doc
12-07-2012 12:32Tomas UrbanNote Added: 0010882
12-07-2012 14:13Gyorgy RethyNote Added: 0010885
12-07-2012 14:14Gyorgy RethyNote Edited: 0010885
12-07-2012 15:50Tomas UrbanNote Added: 0010890
12-07-2012 16:42Jacob Wieland - SpirentNote Added: 0010899
12-07-2012 17:37Gyorgy RethyNote Added: 0010902
12-07-2012 17:38Gyorgy RethyFile Added: CR_6088_v5.doc
12-07-2012 17:41Gyorgy RethyNote Edited: 0010902
12-07-2012 17:43Gyorgy RethyNote Edited: 0010902
12-07-2012 18:01Tomas UrbanFile Added: CR_6088_v6.doc
12-07-2012 18:02Tomas UrbanNote Added: 0010904
12-07-2012 18:05Gyorgy RethyNote Edited: 0010902
13-07-2012 10:11Jacob Wieland - SpirentNote Added: 0010909
13-07-2012 11:00Gyorgy RethyNote Added: 0010912
13-07-2012 11:07Gyorgy RethyNote Edited: 0010912
13-07-2012 15:22Tomas UrbanFile Added: CR_6088_v7.doc
13-07-2012 15:34Tomas UrbanNote Added: 0010933
13-07-2012 15:34Tomas UrbanAssigned ToJens Grabowski => Ina Schieferdecker
13-07-2012 15:34Tomas UrbanStatusassigned => resolved
13-07-2012 15:34Tomas UrbanResolutionopen => fixed
09-08-2012 13:39Ina SchieferdeckerNote Added: 0011003
09-08-2012 13:39Ina SchieferdeckerFile Added: CR_6088_v8doc.doc
09-08-2012 13:40Ina SchieferdeckerStatusresolved => assigned
09-08-2012 13:40Ina SchieferdeckerAssigned ToIna Schieferdecker => Tomas Urban
09-08-2012 13:40Ina SchieferdeckerNote Added: 0011004
09-08-2012 13:47Tomas UrbanNote Added: 0011005
09-08-2012 13:48Tomas UrbanAssigned ToTomas Urban => Ina Schieferdecker
09-08-2012 13:56Ina SchieferdeckerNote Added: 0011008
09-08-2012 13:56Ina SchieferdeckerStatusassigned => closed
09-08-2012 13:57Ina SchieferdeckerFixed in Version => Edition 4.5.1
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010724) +
+ Gyorgy Rethy    +
+ 09-07-2012 16:58    +
+ 		+ + + + +
+ In general I agree. As subset/superset can be used for set ofs, permutation for record ofs, complement to any type, the simple syntax subset mytemplate (if e.g. mytemplate is a record of) may cause confusions. I propose to identify at the syntactical level that this construct is using only the elements of the argument, e.g.
+
+subset all from mytemplate;
+subset (5, all from mytemplate, 7);
+permutation (3, all from mytemplate);
+
+A little bit longer syntactically but more readable and more clearly reflects the intention.
+
+
+
+ + + + + + + + + + +
+ (0010743) +
+ Gyorgy Rethy    +
+ 10-07-2012 11:53    +
+ 		+ + + + +
+ STF discussion 2012-07-10:
+Proposal agreed in principle, work out a proposed text.
+
+
+
+ + + + + + + + + + +
+ (0010750) +
+ Jacob Wieland - Spirent    +
+ 10-07-2012 12:53    +
+ 		+ + + + +
+ I think the "all" is confusing in this construct, as in a subset, only some of the elements from the list should be in the matching template.
+
+Thus, I propose either to take only the from, i.e.
+
+subset from X, superset from X (would be mz favourite, also shorter)
+
+or
+
+subset any from X / superset all from X
+
+The additional mix-syntax is unnecessary, as it can easily be done by using
+the & operator, i.e.
+
+subset from { 5, 7 } & mytemplate
+
+permutation from { 3 } & mytemplate
+
+
+
+ + + + + + + + + + +
+ (0010771) +
+ Gyorgy Rethy    +
+ 10-07-2012 15:08    +
+ 		+ + + + +
+ actually "all" means that all elements of the referenced template is used in the subset/superset etc. for example:
+type record of integer ROI;
+template ROI t_roi := { 1,2,3}
+
+template SOI t_roi:= subset all from t_roi; //is equivalent to subset (1,2,3), i.e. all elements of t_roi became elements of t_soi.
+
+this will match of course values {1}, {1,2}... etc.
+
+
+
+ + + + + + + + + + +
+ (0010773) +
+ Jacob Wieland - Spirent    +
+ 10-07-2012 18:08    +
+ 		+ + + + +
+ I understand, but I think it is not intuitive language-wise and therefore confusing. Using only the 'from', less so - at least to me.
+
+
+
+ + + + + + + + + + +
+ (0010789) +
+ Tomas Urban    +
+ 11-07-2012 09:20    +
+ 		+ + + + +
+ I added a draft of core language specification changes. From the number of proposals we picked the one that uses the "all from" inside parentheses, e.g. subset(all from t1, 1, 2). There are several reasons for this solution:
+1. The syntax remains very similar to the original one
+2. It can be used for template lists too, e.g.: (1, 2, all from t2)
+3. It has a good readability meaning "include all elements from the source template"
+4. We don't have to deal with the problem whether "from" should be preceded by any, all or nothing in the proposed shorthand form of the notation.
+
+--> assigned to Jens for review
+
+
+
+ + + + + + + + + + +
+ (0010824) +
+ Jacob Wieland - Spirent    +
+ 11-07-2012 10:57    +
+ 		+ + + + +
+ I actually cannot think of a use case where the mixed notation would be necessary. In my experience either the whole dynamic list is to be used as the basis for subset/superset or a fixed list (as we can do now).
+
+If the mixed notation shall be used, then I would opt for 'all X' instead of 'all from X', as it is shorter and has the same intuition.
+
+
+
+ + + + + + + + + + +
+ (0010827) +
+ Jens Grabowski    +
+ 11-07-2012 11:14    +
+ 		+ + + + +
+ For me "all from" is as expressive as "all". However, in any case the meaning of "all from" or "all" needs to be explained informally in Clause 15.7.2. Apart from this, I am fine with the text.
+
+
+
+ + + + + + + + + + +
+ (0010829) +
+ Jacob Wieland - Spirent    +
+ 11-07-2012 11:23    +
+ 		+ + + + +
+ In the examples for subset/superset, the paranthesis is missing, though the syntax allows the construct only with paranthesis.
+
+
+
+ + + + + + + + + + +
+ (0010836) +
+ Gyorgy Rethy    +
+ 11-07-2012 14:03    +
+ 		+ + + + +
+ 1) Actually one may want to compose a list from more than one list variables. Also, it is quite possible to have a mixed case, when some of the elements are static (e.g. IDs assigned by the user are known in beforehand) and some are dynamic (IDs assigned by the network). So, the possibility to refer to the elements of a list inside a () is useful.
+
+2) Add also permutation to the resolution.
+
+3) "all t_mytemplate" is not expressive to me at all, it would not be intuitive for the users. We should go either for "all from" or "from" to have an intuitive syntax.
+
+
+
+ + + + + + + + + + +
+ (0010839) +
+ Tomas Urban    +
+ 11-07-2012 15:59    +
+ 		+ + + + +
+ I made several changes according to your requests:
+1. The chapter on permutations was added
+2. I added a note to the chapter 15.7.2 explaining the basic principle of the "all from" clause, but the reader still has to refer to Annex B to find out all the details. I hope it is fine.
+3. I switched on change tracker
+4. I added parenthesis to the superset and subset examples
+
+There's two changes in the BNF too. Superset, subset and template list can contain one element only if it is all from. And complemented list template BNF was accidentally left unchanged.
+
+
+
+ + + + + + + + + + +
+ (0010857) +
+ Gyorgy Rethy    +
+ 12-07-2012 09:15    +
(edited on: 12-07-2012 09:26)
+ 		+ + + + +
+ I have made some editorial changes in CR_6088_v3.doc to better express that individual elements and all from references can be mixed and some other minor editorials.
+
+Some restrictions could need further considerations. For example, permutation may contain AnyElementsOrNone, even several of them (actually, it makes no difference if there is a single or multiple *-s is/are within a permutation), it is not obvious for me why it cannot be included by referencing from other record/set of templates.
+
+
+
+
+
+ + + + + + + + + + +
+ (0010872) +
+ Jacob Wieland - Spirent    +
+ 12-07-2012 11:35    +
+ 		+ + + + +
+ "Superset, subset and template list can contain one element only if it is all from."
+
+Why? What's wrong with subset (X), superset (X) ?
+
+
+
+ + + + + + + + + + +
+ (0010873) +
+ Jacob Wieland - Spirent    +
+ 12-07-2012 11:37    +
+ 		+ + + + +
+ "Some restrictions could need further considerations. For example, permutation may contain AnyElementsOrNone, even several of them (actually, it makes no difference if there is a single or multiple *-s is/are within a permutation), it is not obvious for me why it cannot be included by referencing from other record/set of templates.
+"
+
+What do you mean? That a record of containing a permutation shall be allowed as a reference referred to be the all-from construct?
+
+
+
+ + + + + + + + + + +
+ (0010879) +
+ Gyorgy Rethy    +
+ 12-07-2012 12:01    +
+ 		+ + + + +
+ See CR_6088_v4.doc.
+
+Regarding the "can contain one element only if it is all from" question, do you refer to the TemplateList BNF productions?
+It seems to me that this also could be simplified to
+
+TemplateListItem {"," TemplateListItem }
+but it is not changed in the draft CR_6088_v4.doc. Let the others also look at this.
+
+Regarding the restrictions, actually I mean that we have had restrictions for the individual elements in the description part and now restrictions for the elements brough in by referencing a template has been added to the new Restrictions paragraph. But actually the same restriction apply for both, the mechanisms, how a member got inside a subset/superset/permutation etc. is unimportant. The more, restrictions shall be writen in one place only to avoid possible inconsistencies.
+
+Therefore:
+- existing restrictions I have moved to the Restrictions paragraph
+- applied the current constrains for the members to the elements referenced by the all from contructs too (in one Restirictions item); actually, for template list and complemented list this means that there is no restriction of the members as there was no restriction before.
+
+
+
+ + + + + + + + + + +
+ (0010882) +
+ Tomas Urban    +
+ 12-07-2012 12:32    +
+ 		+ + + + +
+ The problem is that the mechanism how items get into the target template is actually important. There are several symbols that can appear only inside record of values such as AnyElementsOrNone or permutation. These symbols were explicitely forbidden in the argument of the "all from" clause for these reasons:
+1. AnyElementsOrNone: because it is not possible to reasonably transform it into a single element template as it represents a group of elements in the record of template.
+2. Permutation: because it is a matching symbol for several elements and because of consistency with other rules that don't allow access to items inside permutation.
+
+Proposal: in addition to general restrictions on the set of symbols that can/cannot appear in the constructed template, there could be an additional restriction saying that the template in the all from clause cannot contain AnyElementsOrNone and permutation.
+
+If the proposal is not accepted, it should be said how is AnyElementsOrNone interpretted, because it is not the same as AnyValueOrNone. Additionally, the restriction b in B.1.2.1 and B.1.2.2 should be changed because it referers to the deleted restriction c.
+
+Regarding the subset and superset template:
+The rules are taken from the current BNF, which doesn't allow to construct subset and superset with one item. I agree that it is quite strange and should be changed.
+
+
+
+ + + + + + + + + + +
+ (0010885) +
+ Gyorgy Rethy    +
+ 12-07-2012 14:13    +
(edited on: 12-07-2012 14:14)
+ 		+ + + + +
+ Tomáš, let's separate your comment to two parts:
+1) regarding the matching mechanisms bound to a type, your comment is partly correct: subset/superset should be disallowed if the referencing type is a record of. However, a permutation is practically converting a record of into a set of. So, referencing a permutation from a set of could be allowed without any problems, just the rules has to be specified ("lift over" just the elements of a permutation into the set of). But if this is considered to be too complicated, I can leave with disallowing this as well.
+
+But I don't see a problem in the non-cross-type cases, e.g. permutation is allowed for record of (complemented) lists:
+({permutattion (1,2,3)},{4,5,6})
+
+why the user should not be able to construct the same like
+template MyrecOf t_MyrecOf := {permutation(1,2,3)}
+template MyrecOf t_MyrecOf2 := (all from t_MyrecOf, {4,5,6})
+
+2) AnyElementsOrNone
+Seems we have a terminological issue here.
+- In subset and superset AnyValueOrNone are forbidden, obviously this is converted to forbidding AnyElementsOrNone in case of all from references. So, I think this is just an editorial work to do (I mean there is no new restriction is introduced).
+- In template (complemented) lists AnyValueOrNone is allowed, so an AnyElementOrNone within a referenced record of or set of is implcitly transformed to AnyValueOrNone. This should be written in the text but I cannot see a technical reason to forbid this.
+- Referencing a record/set of with AnyElementsOrNone from within a permutation shouldn't be a problem as AnyElementsOrNone is also allowed in permutation.
+
+
+
+
+
+ + + + + + + + + + +
+ (0010890) +
+ Tomas Urban    +
+ 12-07-2012 15:50    +
+ 		+ + + + +
+ György,
+
+I am afraid i cannot agree with the conclusions you made. The "all from" notation is used for moving individual elements, not the whole template into the target. Let's take the example you wrote, but without the permutation mark:
+template MyrecOf t_MyrecOf := { 1,2,3 };
+The "all from" shall be used to create a template of the member type (integer) of the value in the argument and not a template of the same type (MyrecOf):
+template integer t_int := (all from t_MyrecOf, 4, 5, 6);
+
+In the example you described, you define a template of the same record of type. The result you wanted to get can be easily achieved without the "all from" clause:
+template MyrecOf t_MyrecOf := {permutation(1,2,3)};
+template MyrecOf t_MyrecOf2 := (t_MyrecOf, {4,5,6}); // produces ({permutation(1,2,3)}, {4,5,6})
+
+I hope that we can agree that the "all from" clause produces a set of items of the member type. The problem with the permutation is that it is a matching mechanisms that is rather related to the enclosing record of than to the elements itself. So the issue is how to get those individual elements from there?
+
+Having:
+template MyrecOf t_MyrecOf := {permutation(1,2,3)};
+template integer t_int := (all from(t_MyrecOf), 4, 5, 6);
+the possible results would be either:
+(permutation(1,2,3), 4, 5, 6) // if we consider the whole permutation is a single item
+or
+(1, 2, 3, 4, 5, 6)
+
+I don't like either. The first one is both semantically and syntactically incorrect so it would produce an error anyway. The second one produces a correct template, but it would require additional rules describing that the permutation envelope has to be dropped when "all from" is used. Besides, who would use such rules? What would be a practical application of such a feature? I find it much simpler to forbid permutations in these cases.
+
+The situation with AnyElementsOrNone is a little bit more complicated. You suggest that it shall be transformed into AnyValueOrNone. I don't think it is consistent with the rest of the specification, because no such transformation is actually currently defined and allowed. Besides, there are hidden problems when transforming the element in its literal form. Consider this:
+
+type record of charstring RoC;
+template RoC t_roc := {"abc", * length(2)};
+template charstring t_c := (all from t_roc);
+
+It would produce ("abc", * length(2)). In this case, the original meaning was altered. In the first template, * length(2) means two strings of any length and in the second one, it means any string with length two or omitted value. The situation would be even worse in case of integers, where * length(2) would be semantically incorrect as a length restriction cannot be applied to an integer template. This might be of course fixed by an additional rule saying that the length attribute shall be dropped during this transformation.
+
+In addition to that, AnyValueOrNone is forbidden for subsets and supersets. Complement templates containing it would not match anything. It might find a good use in permutation though, but this produces another problem, because in this case the transformation AnyElementsOrNone -> AnyValueOrNone is not necessary. For these reasons, I would prefer if AnyElementsOrNone remained forbidden in the argument of the "all from" clause.
+
+If both permutations and AnyElementsOrNone were not allowed in the record of values used in the "all from" clause, we would have a nice uniform rule for all places, where the clause can be used.
+
+
+
+ + + + + + + + + + +
+ (0010899) +
+ Jacob Wieland - Spirent    +
+ 12-07-2012 16:42    +
+ 		+ + + + +
+ I agree with Tomáš assessment.
+
+Allowing permutation or AnyElmementsOrNone inside the referenced template introduces uncertainties. As long as no one really needs this feature, it should be forbidden to avoid confusion.
+
+
+
+ + + + + + + + + + +
+ (0010902) +
+ Gyorgy Rethy    +
+ 12-07-2012 17:37    +
(edited on: 12-07-2012 18:05)
+ 		+ + + + +
+ OK, I have got now where my misunderstanding was. Your explanation is correct, and the original restrictions were also correct, with one exception; we should consider one important case.
+Let's define a message template like:
+template MyRec t_message := {
+  iD := 1,
+  iEList := { //record of record, used to check the first two IEs, the rest is unimportant
+    {iEID := 1, IEvalue := "Tinky-Winky"},
+    { iE2 := 2, IEvalue := "Poo"},
+    * }
+}
+and the user wants to use this to define another template for the IEList where the order of the elements is arbitrary, because the SUT may send them in different orders:
+template MyRec.iEList t_IEList_unordered := { permutation (all from t_message.iEList)}
+
+Actually, this is the use case our users need to solve (this was the reason for CR 6165). If disallowing AnyElementsOrNone when all from is used inside a permutation, this use case whould be not be possible, while there is no technical reason for disallowing it. So, in this case, we have a user need that shall overwhelm simplicity and uniformity.
+
+Except this one open issue is remaining: is there a specific reason, why TemplateList is not changed simply to
+TemplateList := "(" (TemplateListItem {"," TemplateListItem}+ )
+?
+
+In principle the order of "direct" elements and elements referenced by all from clauses should be a user's choice.
+
+Pls. check CR_6088_v5.doc that I corrected according to the above, except the BNF that I haven't changed.
+
+
+
+
+
+ + + + + + + + + + +
+ (0010904) +
+ Tomas Urban    +
+ 12-07-2012 18:02    +
+ 		+ + + + +
+ I have no problem with referencing AnyElementsOrNone in permutation, so this is fine for me. Maybe we should add an expample to the draft too.
+
+Regarding the BNF: I think the problem occurs because both superset and subset rules refer to the rules for template list. Currently the BNF allows 2+ elements in template lists, because if a single element were allowed, it would lead to conflicts with an expression inside parentheses. Notice that "all from" doesn't suffer from this conflict (and for that reason, 1 element only is allowed). I think the best way to resolve it is to share the BNF rules for the part in parentheses with complemented template list. I modified the draft this way. Please check if it is fine.
+
+
+
+ + + + + + + + + + +
+ (0010909) +
+ Jacob Wieland - Spirent    +
+ 13-07-2012 10:11    +
+ 		+ + + + +
+ I also agree that for permutation it makes sense. For subset or superset, though, it seems pointless or confusing.
+
+The subset of an infinite set is any set, so that makes no sense. And the superset of a possibly infinite set is what?
+
+So, basically, we should strive for something like: the same restrictions that apply to the direct elements of a matching mechanism construction must also apply to the elements of the template referred to by the all from-construct in such a construction.
+
+
+
+ + + + + + + + + + +
+ (0010912) +
+ Gyorgy Rethy    +
+ 13-07-2012 11:00    +
(edited on: 13-07-2012 11:07)
+ 		+ + + + +
+ Technically is fine with me, I have some editorials (to CR_6088_v6.doc):
+-------
+1.A ListOfTemplates -> 1. ListOfTemplates
+-------
+9.PermutationList ::= "(" PermutationListItem {"," PermutationListItem} ")"
+PermutationListItem ::= (TemplateBody | AllElementsFrom)
+
+could be simplified to
+9.PermutationList ::= "(" TemplateListItem {"," TemplateListItem } ")"
+(some time ago we have decided to simplify the BNF by removing transitional "purpose-specific" productions like
+TemplateIdentifier := Identifier)
+---------
+TemplateList would be used in MatchingSymbol only, where it could be replaced by ListOfTemplates as well and the production TemplateList could simply be deleted
+---------
+wording of item b) in clauses B.1.2.6, B.1.2.7 and B1.3.3 [actually, in B.1.2.7 and B.1.3.3 item ID to be corrected from a) to b)] could be simplified (rext below is given for B.1.2.6, the other clauses could use the same schema)
+from
+b) The member type of the set of type associated with the superset template and the member type of the record of or set of type associated with the template in the all from claused shall be compatible.
+to
+b) The member type of the set of associated with the superset template and the member type of the template in the all from clause shall be compatible.
+---------
+
+
+
+
+
+ + + + + + + + + + +
+ (0010933) +
+ Tomas Urban    +
+ 13-07-2012 15:34    +
+ 		+ + + + +
+ I made the requested changes and corrected a couple of typos. There's only one minor difference compared to György's last editorial proposals. I simplified the rule for permutation in a slightly different way. It uses the same style as complement, subset and superset now:
+-->
+7.PermutationMatch ::= PermutationKeyword ListOfTemplates
+
+
+
+ + + + + + + + + + +
+ (0011003) +
+ Ina Schieferdecker    +
+ 09-08-2012 13:39    +
+ 		+ + + + +
+ Streamlining the BNF and some editorial changes: v8
+
+
+
+ + + + + + + + + + +
+ (0011004) +
+ Ina Schieferdecker    +
+ 09-08-2012 13:40    +
+ 		+ + + + +
+ Please check.
+
+
+
+ + + + + + + + + + +
+ (0011005) +
+ Tomas Urban    +
+ 09-08-2012 13:47    +
+ 		+ + + + +
+ I am OK with the latest changes.
+Assigned to Ina for implementation.
+
+
+
+ + + + + + + + + + +
+ (0011008) +
+ Ina Schieferdecker    +
+ 09-08-2012 13:56    +
+ 		+ + + + +
+ as proposed.
+
+ + diff --git a/docs/mantis/CR6089.md b/docs/mantis/CR6089.md new file mode 100644 index 0000000000000000000000000000000000000000..1df4c17065abc08146e97ca5618403c18c8ec31e --- /dev/null +++ b/docs/mantis/CR6089.md @@ -0,0 +1,702 @@ + + + + + + + + + + + + + 0006089: receive statements on port arrays - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006089Part 01: TTCN-3 Core LanguageNew Featurepublic16-05-2012 12:5129-11-2013 12:19
ReporterJacob Wieland - Spirent 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.6.1 (published 2014-06)Fixed in Versionv4.6.1 (published 2014-06) 
Clause Reference(s)22
Source (company - Author)Testing Technologies - Jacob Wieland
Summary0006089: receive statements on port arrays
DescriptionCurrently, in TTCN-3 there is a dichotomy between dynamically sized port arrays and static alt statements to check for message reception: If it is not known how many ports are in a port array, it is not possible to write down an alt statement which can receive messages over all these ports in parallel.
+
+Though this can be done by use of the default mechanism, we feel that this neither
+makes the TTCN-3 more readable and can lead to confusion (which defaults are actual defaults and which ones are dynamic-port-defaults).
+
+Therefore, we propose to generalize the reception statements (i.e. receive/trigger/getcall/getreply/catch) to work as well on port arrays.
+
+alt {
+[] <port_array_ref>.receive(X) { ... }
+}
+
+where n is the number of ports in the port array,
+would have the same semantics as
+
+alt {
+[] <port_array_ref>[0].receive(X) { ... }
+...
+[] <port_array_ref>[n-1].receive(X) { ... }
+}
+
+To facilitate distinction on which actual port the reception took place as well as allow a reaction on the same port, an optional 'port' clause (analogous to 'sender' and 'value') can be added to the assignment part of the receive statement.
+
+Example:
+
+Assuming, <port_array_ref> is a port array of PortType ports, this would be
+valid:
+
+var PortType p;
+
+alt {
+[] <port_array_ref>.receive(X) -> port p { p.send(Y) }
+}
+
+This construct should work the same way on multi-dimensional port arrays as on single dimensional arrays.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR6089.doc (400,384) 08-10-2013 18:36
http://oldforge.etsi.org/mantis/file_download.php?file_id=2900&type=bug
doc CR6089_resolution_v2.doc (472,064) 09-10-2013 16:16
http://oldforge.etsi.org/mantis/file_download.php?file_id=2913&type=bug
doc CR6089_resolution_v3.doc (491,520) 29-11-2013 12:18
http://oldforge.etsi.org/mantis/file_download.php?file_id=2961&type=bug
Issue History
Date ModifiedUsernameFieldChange
16-05-2012 12:51Jacob Wieland - SpirentNew Issue
16-05-2012 12:51Jacob Wieland - SpirentClause Reference(s) => 22
16-05-2012 12:51Jacob Wieland - SpirentSource (company - Author) => Testing Technologies - Jacob Wieland
16-05-2012 16:03Jacob Wieland - SpirentNote Added: 0010627
09-07-2012 16:56Ina SchieferdeckerProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
09-07-2012 17:08Gyorgy RethyNote Added: 0010726
10-07-2012 11:40Gyorgy RethyNote Added: 0010741
10-07-2012 11:40Gyorgy RethyAssigned To => Jens Grabowski
10-07-2012 11:40Gyorgy RethyStatusnew => assigned
10-07-2012 11:40Gyorgy RethyTarget Version => Edition 4.5.1
10-07-2012 11:46Gyorgy RethyNote Edited: 0010741
10-07-2012 11:46Gyorgy RethyNote Deleted: 0010726
10-07-2012 13:01Jacob Wieland - SpirentNote Added: 0010751
10-07-2012 13:35Jacob Wieland - SpirentNote Added: 0010752
08-07-2013 18:19Gyorgy RethyTarget Versionv4.5.1 (published 2013-04) => v4.6.1 (published 2014-06)
12-07-2013 11:53Jens GrabowskiAssigned ToJens Grabowski => Jacob Wieland - Spirent
12-07-2013 13:48Jacob Wieland - SpirentFile Added: CR6089.zip
12-07-2013 13:49Jacob Wieland - SpirentNote Added: 0011577
12-07-2013 13:57Jacob Wieland - SpirentNote Added: 0011578
12-07-2013 13:57Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
12-07-2013 13:57Jacob Wieland - SpirentStatusassigned => confirmed
29-08-2013 11:14Gyorgy RethyNote Added: 0011635
29-08-2013 11:15Gyorgy RethyAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
29-08-2013 11:15Gyorgy RethyStatusconfirmed => assigned
29-08-2013 11:15Gyorgy RethyResolutionopen => fixed
29-08-2013 11:15Gyorgy RethyNote Edited: 0011635
29-08-2013 14:41Jacob Wieland - SpirentNote Added: 0011640
07-10-2013 13:30Jacob Wieland - SpirentNote Added: 0011685
07-10-2013 13:30Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
07-10-2013 13:30Jacob Wieland - SpirentStatusassigned => confirmed
07-10-2013 17:28Gyorgy RethyNote Added: 0011693
07-10-2013 17:30Gyorgy RethyNote Edited: 0011693
07-10-2013 17:32Gyorgy RethyNote Edited: 0011693
07-10-2013 17:33Gyorgy RethyAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
07-10-2013 17:33Gyorgy RethyStatusconfirmed => assigned
08-10-2013 10:48Jacob Wieland - SpirentNote Added: 0011697
08-10-2013 11:05Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
08-10-2013 11:05Jacob Wieland - SpirentStatusassigned => confirmed
08-10-2013 14:04Gyorgy RethyNote Added: 0011703
08-10-2013 14:30Jacob Wieland - SpirentStatusconfirmed => assigned
08-10-2013 14:30Jacob Wieland - SpirentAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
08-10-2013 18:35Jacob Wieland - SpirentFile Deleted: CR6089.zip
08-10-2013 18:36Jacob Wieland - SpirentFile Added: CR6089.doc
08-10-2013 18:36Jacob Wieland - SpirentNote Added: 0011716
08-10-2013 18:36Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
08-10-2013 18:36Jacob Wieland - SpirentStatusassigned => confirmed
09-10-2013 16:16Gyorgy RethyFile Added: CR6089_resolution_v2.doc
09-10-2013 16:18Gyorgy RethyNote Added: 0011736
09-10-2013 16:18Gyorgy RethyAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
09-10-2013 16:18Gyorgy RethyStatusconfirmed => assigned
10-10-2013 15:27Jacob Wieland - SpirentNote Added: 0011756
10-10-2013 15:27Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Ina Schieferdecker
10-10-2013 15:27Jacob Wieland - SpirentStatusassigned => confirmed
29-11-2013 12:18Ina SchieferdeckerFile Added: CR6089_resolution_v3.doc
29-11-2013 12:19Ina SchieferdeckerNote Added: 0011865
29-11-2013 12:19Ina SchieferdeckerStatusconfirmed => resolved
29-11-2013 12:19Ina SchieferdeckerFixed in Version => v4.6.1 (published 2014-06)
29-11-2013 12:19Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010627) +
+ Jacob Wieland - Spirent    +
+ 16-05-2012 16:03    +
+ 		+ + + + +
+ As an alternative syntax to make the feature more explicit, we could introduce the following:
+
+any <port_array_ref>.receive()
+
+So, this would be a mixture between any port.receive and <port_ref>.receive.
+
+
+
+ + + + + + + + + + +
+ (0010741) +
+ Gyorgy Rethy    +
+ 10-07-2012 11:40    +
(edited on: 10-07-2012 11:46)
+ 		+ + + + +
+ STF discussion 2012-07-10:
+The need for such feature is agreed. The solution could be made consistent for the different active objects, i.e. for ports, timers, components... and shall allow saving the index of the instance of an array as well. Also any port, any timer, any componanet shall be considered. Both access to the active objects and to the index of active objects should be considered.
+Analyse the different alternatives for further discussion.
+
+
+
+
+
+ + + + + + + + + + +
+ (0010751) +
+ Jacob Wieland - Spirent    +
+ 10-07-2012 13:01    +
+ 		+ + + + +
+ Why would that be necessary to know the index of the timer/port? Since timers and ports are passed by reference, it would never be necessary to "assign them back" to their original index. What would the index be useful for otherwise if the port/timer can be assigned to an additional variable to store it for future use.
+
+To enlarge the construction to timers, we would need to introduce timer variables (which de-facto already exist as timer parameters), i.e. see the keyword timer also as a predefined type to be used in var-declarations.
+
+
+
+ + + + + + + + + + +
+ (0010752) +
+ Jacob Wieland - Spirent    +
+ 10-07-2012 13:35    +
+ 		+ + + + +
+ If really seen as necessary, the index-assignment notation could look like this:
+
+type component C {
+  port P[10][10][10] p;
+}
+
+... runs on C {
+var integer i, j, k;
+
+alt {
+[] any p.receive(...) -> port [i][j][k] { p[i][j][k].send(...) }
+}
+
+As the syntax is clearly distinguishable from a variable reference (as in -> port p2), I think this would be a very readable and clear alternative. Also, it would not introduce any new keywords.
+
+
+
+ + + + + + + + + + +
+ (0011577) +
+ Jacob Wieland - Spirent    +
+ 12-07-2013 13:49    +
+ 		+ + + + +
+ added proposal for all receiving operations (receive, trigger, getcall, getreply, catch and check) both in text and in BNF.
+
+changes for components and timers to be done later
+
+
+
+ + + + + + + + + + +
+ (0011578) +
+ Jacob Wieland - Spirent    +
+ 12-07-2013 13:57    +
+ 		+ + + + +
+ can you crosscheck?
+
+
+
+ + + + + + + + + + +
+ (0011635) +
+ Gyorgy Rethy    +
+ 29-08-2013 11:14    +
(edited on: 29-08-2013 11:15)
+ 		+ + + + +
+ My comments:
+1) I would prefer a resolution text containing only the clauses changed by this CR and only the changes related to this CR (not the whole standard)
+
+2) The syntax should more intuitively identify that a port array is meant; "any p" is not intuitive enough, a non-experts reader may miss the point easily; for example
+[] any Port.receive (MyTemplate);
+For similar cases we are already using the [-] syntax (when not a concrete element but the inner type of a record/set of is referred to); i.e.
+[] p[-].receive(Mytemplate)
+would explicitly show that the receive operation works over the whole port array, not on a single port only
+
+3) The need of saving the index of the port is above question, otherwise it would be impossible to respond to the message received over a port that is member of a port array.
+
+4) For saving the index I propose the syntax port i and port (i,j,k), as we are using this syntax already, when saving certain fields of the received message (see $22.2.2). I.e.
+
+[] p[-].receive(Mytemplate) -> port i //single dimension port array
+or
+[] p[-].receive(Mytemplate) -> port (i) //single dimension port array
+and
+[] p[-].receive(Mytemplate) -> port (i,j,k) //3-dimensional port array
+
+5) The meaning of "If the port array is nested, then the inner port arrays are iterated over first." is unclear to me (nesting means to me something in a record field or as a record of element). I suppose multi-dimensional arrays are meant here. I would propose:
+"In case of multi-dimensional port arrays the port indices are iterated from the last index to the first index, i.e. [0,0,0] then [0,0,1] ... [0,1,0], [0,1,1] ... [1,0,0], [1,0,1] etc."
+
+
+
+
+
+ + + + + + + + + + +
+ (0011640) +
+ Jacob Wieland - Spirent    +
+ 29-08-2013 14:41    +
+ 		+ + + + +
+ My comments:
+
+1) This was done only because the CR is supposed to include also stuff for component and timer arrays and I didn't want a merge-nightmare between proposals later on. Of course, the final proposal will only contain the changed sections.
+
+2) The syntax you are proposing also is not intuitive to me - you still need to know what it should signify to understand it. I would opt for a thing similar to the 'all from' construct we introduced for permutation/subset, i.e. 'any from Port.receive'. This clearly distinguishes it both from 'any port.receive' and 'Port.receive'. Alternatively, it could be 'any port from P' which would make it clear to everybody, I think. Basically, this would then be a special case of the any port construction.
+
+3) The index is not necessary for reply if you can assign the port to a port variable instead. The index would only be necessary if you need to use the index information for something else on which your reply depends (i.e. some message for even, some other for odd ports).
+
+
+4) using tuples for index-variable assignment is fine with me. However, if indices are supposed to be assigned, always parantheses should be used (even for single index) to distinguish from port-variable assignment (which I would deem the much more common case and thus a much more useful syntax, especially for multi-dimensional arrays because I only need to declare one port variable instead of one integer variable per dimension and I don't have to pick the port from the array explicitly once more).
+
+you have to agree that for an n-dimensional port array P
+
+var integer i1, ..., in;
+
+[] any port from p.receive(...) -> port (i1, ..., in) { p[i1]...[in].send(...) }
+
+demands a lot of unnecessary work for the user in contrast to:
+
+var P vp;
+
+[] any port from p.receive(...) -> port vp { vp.send(...) }
+
+Also, here you see the additional advantage for the any-port-from-construct as opposed to the p[-]...[-] where you have to know (and care) how many dimensions there are in p.
+
+5) also, I have no problem with rewording the iteration procedure to make it more clear
+
+
+
+ + + + + + + + + + +
+ (0011685) +
+ Jacob Wieland - Spirent    +
+ 07-10-2013 13:30    +
+ 		+ + + + +
+ please comment on my comments
+
+
+
+ + + + + + + + + + +
+ (0011693) +
+ Gyorgy Rethy    +
+ 07-10-2013 17:28    +
(edited on: 07-10-2013 17:32)
+ 		+ + + + +
+ Hi:
+1) OK
+2) "any from P.receive" looks OK for me and still not too long; any port from P seems to be somewhat long, but it is true, is absolutely clear. Also, we have to think about timer arrays, i.e. if I want to check if any timer from an array has expired. We should also add "any from T.timeout" or any timer from T.timeout.
+3) & 4) For pure reply yes, a port variable would be an easy solution. But the response-case is usually not so simple. We often has to maintain the state machines of the ports, because the response depends on the (incoming message + port state). The state is most often a record of enumerated or record of integer, so to check the old state of a port and to store the new state after sending the response, the indices are needed anyway. In fact, multi-dimensional port arrays are used very rarely, if used at all. I haven't seen any yet. I think we should design the language for the majority of use-cases.
+
+
+So, in summary, I think that:
+- we cannot avoid a mechanism to store the port (timer) index. In most cases it will be a single-dimensional index, and the syntax should be optimized for this, but there should be a way to store multi-dimensional indexes as well. For example, we can say that an integer variable or an integer array - that has the same dimensions as the port/timer array itself - name shall be used to store the index. And probably, we could also allow using just an integer array name when referencing a port or timer from an array.
+- we should keep the solution as simple as possible for the tool makers as well. For this reason one mechanism may be sufficient. On the other hand, port parameters are allowed, therefore allowing port variables as well may not be a tremendous extension for tool providers.
+
+
+
+
+
+ + + + + + + + + + +
+ (0011697) +
+ Jacob Wieland - Spirent    +
+ 08-10-2013 10:48    +
+ 		+ + + + +
+ So, the proposal is this, for an N-dimensional port array P:
+
+any [port] from P.receive(...) -> port X
+
+where X can either be
+1) a port variable
+2) an integer variable, if N is 1
+3) an integer array variable of length N
+4) a tuple of integer variables with N components
+
+For easiest usage, we should then also allow for multi-dimensional arrays (case 2) also the syntax P[X], which is short for P[X[0]]...[X[N-1]]
+
+If the last is allowed, then I suppose cases 2 and 3 are really the only ones you need.
+
+
+
+ + + + + + + + + + +
+ (0011703) +
+ Gyorgy Rethy    +
+ 08-10-2013 14:04    +
+ 		+ + + + +
+ STF discussion: stay with 2) and 3) and the short form of using an integer array as a port index reference. Implement it for port, timer and component arrays. The syntax of storing the index need to be thought about when reviewing the resolution draft.
+
+
+
+ + + + + + + + + + +
+ (0011716) +
+ Jacob Wieland - Spirent    +
+ 08-10-2013 18:36    +
+ 		+ + + + +
+ please crosscheck
+
+
+
+ + + + + + + + + + +
+ (0011736) +
+ Gyorgy Rethy    +
+ 09-10-2013 16:18    +
+ 		+ + + + +
+ CR6089_resolution_v2.doc, please review. Hope its self explaining, where I though explanation is useful, added it in a comment.
+
+
+
+ + + + + + + + + + +
+ (0011756) +
+ Jacob Wieland - Spirent    +
+ 10-10-2013 15:27    +
+ 		+ + + + +
+ In principle okay. I still don't think that the new keyword mechanism really needs to be only for modifiers (for me, the @-symbol is more like a keyword-escape-mechanism), but I can think we can discuss that for the future.
+
+I left out the .running and .alive constructs originally because they are not really problematic (they are not blocking and can be solved with a for-loop over the array) while the problem for the blocking constructs cannot be solved with a for-loop. But, if you really also want them in there, I have no problem with that.
+
+
+
+ + + + + + + + + + +
+ (0011865) +
+ Ina Schieferdecker    +
+ 29-11-2013 12:19    +
+ 		+ + + + +
+ As proposed with additions/editorials in v4
+
+ + diff --git a/docs/mantis/CR6096.md b/docs/mantis/CR6096.md new file mode 100644 index 0000000000000000000000000000000000000000..e39610766d09d8d7546dd30533875fb1e45f9584 --- /dev/null +++ b/docs/mantis/CR6096.md @@ -0,0 +1,131 @@ + + + + + + + + + + + + + 0006096: example for template containing a default field is wrong - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006096Part 01: TTCN-3 Core LanguageClarificationpublic04-06-2012 16:2313-07-2012 12:42
ReporterJacob Wieland - Spirent 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.3.2 (interim 2011) 
Target Versionv4.5.1 (published 2013-04)Fixed in Versionv4.5.1 (published 2013-04) 
Clause Reference(s)15
Source (company - Author)Testing Technologies - Jacob Wieland
Summary0006096: example for template containing a default field is wrong
DescriptionSince the restriction b) states that the template should include a field of type default, the example, which clearly does not contain such a field, is wrong in saying that the template in question should cause an error.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR_6096.doc (62,464) 11-07-2012 09:31
http://oldforge.etsi.org/mantis/file_download.php?file_id=2662&type=bug
doc CR_6096_v2.doc (62,976) 13-07-2012 12:41
http://oldforge.etsi.org/mantis/file_download.php?file_id=2700&type=bug
Issue History
Date ModifiedUsernameFieldChange
04-06-2012 16:23Jacob Wieland - SpirentNew Issue
04-06-2012 16:23Jacob Wieland - SpirentClause Reference(s) => 15
04-06-2012 16:23Jacob Wieland - SpirentSource (company - Author) => Testing Technologies - Jacob Wieland
10-07-2012 11:06Gyorgy RethyNote Added: 0010740
10-07-2012 11:06Gyorgy RethyAssigned To => Tomas Urban
10-07-2012 11:06Gyorgy RethyStatusnew => assigned
10-07-2012 11:06Gyorgy RethyTarget Version => Edition 4.5.1
11-07-2012 09:31Tomas UrbanFile Added: CR_6096.doc
11-07-2012 09:36Tomas UrbanNote Added: 0010792
11-07-2012 09:36Tomas UrbanAssigned ToTomas Urban => Ina Schieferdecker
13-07-2012 12:41Ina SchieferdeckerFile Added: CR_6096_v2.doc
13-07-2012 12:42Ina SchieferdeckerNote Added: 0010919
13-07-2012 12:42Ina SchieferdeckerStatusassigned => resolved
13-07-2012 12:42Ina SchieferdeckerResolutionopen => fixed
13-07-2012 12:42Ina SchieferdeckerStatusresolved => closed
13-07-2012 12:42Ina SchieferdeckerFixed in Version => Edition 4.5.1
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010740) +
+ Gyorgy Rethy    +
+ 10-07-2012 11:06    +
+ 		+ + + + +
+ STF discussion 2012-07-10: re-wording rule b) of clause 15 to express the rule in a sipler way: no template is allowed, the type of which contains default in any way.
+
+
+
+ + + + + + + + + + +
+ (0010792) +
+ Tomas Urban    +
+ 11-07-2012 09:36    +
+ 		+ + + + +
+ Changed the rule according to the proposal and excluded port type as well.
+
+
+
+ + + + + + + + + + +
+ (0010919) +
+ Ina Schieferdecker    +
+ 13-07-2012 12:42    +
+ 		+ + + + +
+ see v2
+
+ + diff --git a/docs/mantis/CR6154.md b/docs/mantis/CR6154.md new file mode 100644 index 0000000000000000000000000000000000000000..5f6dee287697b1eb51873a401ae545a2b8e139a8 --- /dev/null +++ b/docs/mantis/CR6154.md @@ -0,0 +1,141 @@ + + + + + + + + + + + + + 0006154: "set/record of" types for local template parameters - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006154Part 01: TTCN-3 Core LanguageNew Featurepublic29-06-2012 09:0312-07-2012 13:24
ReporterAxel Rennoch 
Assigned ToTomas Urban 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionwon't fix 
PlatformOSOS Version
Product Version 
Target Versionv4.5.1 (published 2013-04)Fixed in Version 
Clause Reference(s)Part 15.3
Source (company - Author)Axel Rennoch (FOKUS)
Summary0006154: "set/record of" types for local template parameters
DescriptionThe declaration of templates should accept definitions of formal parameters of types constructed with "set of" and "record of", e.g.:
+
+template Charging_Rule_Install_AVP m_chrgRuleInstall_Definition
+        (set of Charging_Rule_Definition_AVP p_charging_Rule_Definition) :=
+{charging_Rule_Definition := p_charging_Rule_Definition}
Steps To Reproduce
Additional InformationMany DIAMETER message fields have been defined as "set of" types. The proposed change avoids definitions of auxillary types.
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
29-06-2012 09:03Axel RennochNew Issue
29-06-2012 09:03Axel RennochClause Reference(s) => Part 15.3
29-06-2012 09:03Axel RennochSource (company - Author) => Axel Rennoch (FOKUS)
09-07-2012 16:57Ina SchieferdeckerProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
10-07-2012 10:53Gyorgy RethyNote Added: 0010739
10-07-2012 10:53Gyorgy RethyAssigned To => Tomas Urban
10-07-2012 10:53Gyorgy RethyStatusnew => assigned
10-07-2012 10:53Gyorgy RethyTarget Version => Edition 4.5.1
11-07-2012 16:06Tomas UrbanNote Added: 0010840
12-07-2012 10:11Tomas UrbanStatusassigned => feedback
12-07-2012 12:41Axel RennochNote Added: 0010883
12-07-2012 13:24Tomas UrbanStatusfeedback => closed
12-07-2012 13:24Tomas UrbanResolutionopen => won't fix
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010739) +
+ Gyorgy Rethy    +
+ 10-07-2012 10:53    +
+ 		+ + + + +
+ STF discussion 2012-07-10: actually the type of the parameter could be the type of charging_Rule_Definition by dot notation; inform the submiter about it and ask if this is OK to close the CR without addition to the standard.
+
+
+
+ + + + + + + + + + +
+ (0010840) +
+ Tomas Urban    +
+ 11-07-2012 16:06    +
+ 		+ + + + +
+ This kind of template can be defined using the syntactical rules from the current standard. The tricky part is that it is necessary to use an extended type reference:
+
+template Charging_Rule_Install_AVP m_chrgRuleInstall_Definition
+        (Charging_Rule_Install_AVP.charging_Rule_Definition p_charging_Rule_Definition) :=
+{charging_Rule_Definition := p_charging_Rule_Definition}
+
+Could you please inform us if this kind of solution is satisfactory so that we can close the CR?
+
+
+
+ + + + + + + + + + +
+ (0010883) +
+ Axel Rennoch    +
+ 12-07-2012 12:41    +
+ 		+ + + + +
+ Good idea, ok for me. Thanks.
+
+ + diff --git a/docs/mantis/CR6158.md b/docs/mantis/CR6158.md new file mode 100644 index 0000000000000000000000000000000000000000..dba807293d95ea8ad23d0ef1fe059866c77274ea --- /dev/null +++ b/docs/mantis/CR6158.md @@ -0,0 +1,300 @@ + + + + + + + + + + + + + 0006158: Referencing elements of templates: record of terminated with AnyElementsOrNone - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006158Part 01: TTCN-3 Core LanguageTechnicalpublic04-07-2012 11:5810-08-2012 11:44
ReporterTomas Urban 
Assigned ToIna Schieferdecker 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.3.2 (interim 2011) 
Target Versionv4.5.1 (published 2013-04)Fixed in Versionv4.5.1 (published 2013-04) 
Clause Reference(s)15.6.3
Source (company - Author)     
Summary0006158: Referencing elements of templates: record of terminated with AnyElementsOrNone
DescriptionThe chapter 15.6.3 doesn't contain rules for handling record of and set of templates whose last symbol is AnyElementsOrNone. However, the example section seems to be using rules similar to the rules described in the paragraph b:
+
+type record of integer RoI;
+var template RoI t_RoI;
+t_RoI := ? length (2..5);
+t_RoI[1] := 1;
+// after the assignment t_RoI will be {?,1,*} length(2..5);
+t_RoI[3] := ?
+// after the assignment t_RoI will be {?,1,?,?,*} length(2..5);
+
+According to the current rules, the last assignment should actually produce (using the general rules from 6.2.3) {?, 1, *, -, ?) length(2..5). Nevertheless, I think that the example is logically correct and the following paragraph (or similar) should be added to the chapter 15.6.3:
+
+d) AnyElementsOrNone: when referencing an element of a record of or set of template or field that contains AnyElementsOrNone as the last element, in case the index of the reference is greater or equal to the index of the last element, at the right hand side of an assignment, AnyElementsOrNone shall be returned. If a length attribute is attached to the template, the index of the reference shall not violate the length attribute.
+When referencing an element of a record of or set of template or field that contains AnyElementsOrNone as the last element, in case the index of the reference is greater or equal to the index of the last element, at the left hand side of an assignment, the last AnyElementsOrNone shall be replaced with a AnyElement, the value or matching mechanism at the right hand side of the assignment shall be assigned to the referenced element, AnyElement shall be assigned to all elements between the referenced one and the replaced AnyElementsOrNone (if any) and a single AnyElementsOrNone shall be added at the end. A length attribute attached to the template or field shall be left unchanged.
+The index shall not violate type restrictions in any of the above cases.
+
+Examples:
+type record of integer RoI;
+:
+var template RoI vt_RoI;
+var template integer vt_I;
+vt_RoI := {1, *}
+vt_I := vt_RoI[3]; // after the assignment vt_I will be *
+vt_RoI[3] := 4; // after the assignment vt_RoI will be { 1, ?, ?, 4, * }
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR_6158.doc (79,360) 11-07-2012 14:59
http://oldforge.etsi.org/mantis/file_download.php?file_id=2672&type=bug
docx CR_6158_resolution_v2.docx (56,200) 06-08-2012 18:08
http://oldforge.etsi.org/mantis/file_download.php?file_id=2706&type=bug
docx CR_6158_resolution_v3.docx (54,711) 09-08-2012 10:52
http://oldforge.etsi.org/mantis/file_download.php?file_id=2711&type=bug
docx CR_6158_resolution_v4.docx (53,885) 09-08-2012 12:18
http://oldforge.etsi.org/mantis/file_download.php?file_id=2712&type=bug
Issue History
Date ModifiedUsernameFieldChange
04-07-2012 11:58Tomas UrbanNew Issue
04-07-2012 11:58Tomas UrbanClause Reference(s) => 15.6.3
04-07-2012 11:58Tomas UrbanSource (company - Author) =>
10-07-2012 10:46Gyorgy RethyNote Added: 0010738
10-07-2012 10:46Gyorgy RethyAssigned To => Tomas Urban
10-07-2012 10:46Gyorgy RethyStatusnew => assigned
10-07-2012 10:46Gyorgy RethyTarget Version => Edition 4.5.1
10-07-2012 10:47Gyorgy RethyNote Edited: 0010738
11-07-2012 14:59Tomas UrbanFile Added: CR_6158.doc
11-07-2012 14:59Tomas UrbanAssigned ToTomas Urban => Jens Grabowski
11-07-2012 15:01Tomas UrbanNote Added: 0010837
06-08-2012 18:08Tomas UrbanFile Added: CR_6158_resolution_v2.docx
06-08-2012 18:14Tomas UrbanNote Added: 0010981
09-08-2012 10:52Tomas UrbanFile Added: CR_6158_resolution_v3.docx
09-08-2012 10:57Tomas UrbanNote Added: 0011000
09-08-2012 12:18Tomas UrbanFile Added: CR_6158_resolution_v4.docx
09-08-2012 12:19Tomas UrbanNote Added: 0011001
09-08-2012 13:04Jens GrabowskiNote Added: 0011002
09-08-2012 13:04Jens GrabowskiAssigned ToJens Grabowski => Ina Schieferdecker
10-08-2012 11:44Ina SchieferdeckerNote Added: 0011025
10-08-2012 11:44Ina SchieferdeckerStatusassigned => closed
10-08-2012 11:44Ina SchieferdeckerResolutionopen => fixed
10-08-2012 11:44Ina SchieferdeckerFixed in Version => Edition 4.5.1
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010738) +
+ Gyorgy Rethy    +
+ 10-07-2012 10:46    +
(edited on: 10-07-2012 10:47)
+ 		+ + + + +
+ STF discussion 2012-07-10:
+- index is on the rigth hand side: allow expansion if * is at the end of the referenced lists and return ?. If the * is followed by anything else than a * or ?, should cause an error.
+- index is on the left hand side: the same rule as above: * is expanded by ?-s up to the element to be attached, attach the element and add an * at the end of the list.
+
+Check consistency with the existing rules.
+
+
+
+
+
+ + + + + + + + + + +
+ (0010837) +
+ Tomas Urban    +
+ 11-07-2012 15:01    +
+ 		+ + + + +
+ Draft uploaded. I added several additional rules for situations when a length restriction is involved.
+
+
+
+ + + + + + + + + + +
+ (0010981) +
+ Tomas Urban    +
+ 06-08-2012 18:14    +
+ 		+ + + + +
+ I changed the document according to Jens's comments. The most important changes are highlighted for better orientation.
+All template names were modified so that they are the same as in already existing examples for the sake of better integrity of the document.
+I also updated the section on the * occurrence in the middle of templates to be consistent with discussed modifications.
+
+
+
+ + + + + + + + + + +
+ (0011000) +
+ Tomas Urban    +
+ 09-08-2012 10:57    +
+ 		+ + + + +
+ I modified the draft according to Jen's proposals. There are less rules now and no mathematical formulas anymore. The rules for left and right hand side of the assignment are separated now.
+
+
+
+ + + + + + + + + + +
+ (0011001) +
+ Tomas Urban    +
+ 09-08-2012 12:19    +
+ 		+ + + + +
+ Rules for the right hand side simplified + one correction in the example 5
+
+
+
+ + + + + + + + + + +
+ (0011002) +
+ Jens Grabowski    +
+ 09-08-2012 13:04    +
+ 		+ + + + +
+ I am OK with the Resolution.
+Assigned to Ina for Implementation.
+
+
+
+ + + + + + + + + + +
+ (0011025) +
+ Ina Schieferdecker    +
+ 10-08-2012 11:44    +
+ 		+ + + + +
+ as proposed
+
+ + diff --git a/docs/mantis/CR6159.md b/docs/mantis/CR6159.md new file mode 100644 index 0000000000000000000000000000000000000000..ed29148cf37a315ea7e39662961722806d05d440 --- /dev/null +++ b/docs/mantis/CR6159.md @@ -0,0 +1,180 @@ + + + + + + + + + + + + + 0006159: Name of the chapter 15.6.2 - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006159Part 01: TTCN-3 Core LanguageClarificationpublic04-07-2012 13:2711-07-2012 15:37
ReporterTomas Urban 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.3.2 (interim 2011) 
Target Versionv4.5.1 (published 2013-04)Fixed in Versionv4.5.1 (published 2013-04) 
Clause Reference(s)15.6.2
Source (company - Author)     
Summary0006159: Name of the chapter 15.6.2
DescriptionThe rules in the chapter 15.6.2 are generally applicable to union and anytype fields. However, the chapter doesn't explicitely mention these types. I suggest to add these types to the chapter caption (-> 15.6.2 Referencing record, set, union and anytype fields) and to add several related examples, e.g.:
+
+type union U
+{
+  integer variant1,
+  integer variant2
+}
+:
+var template U vt_U;
+var template anytype vt_any;
+var template integer vt_i;
+vt_U := ?;
+vt_i := vt_U.variant1; // after the assignment vt_i will be AnyValue(?)
+
+vt_any := ?;
+vt_i := vt_any.integer; // after the assignment vt_i will be AnyValue(?)
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR_6159.docx (50,986) 11-07-2012 10:52
http://oldforge.etsi.org/mantis/file_download.php?file_id=2665&type=bug
docx CR_6159_resolution_v2.docx (39,727) 11-07-2012 11:42
http://oldforge.etsi.org/mantis/file_download.php?file_id=2669&type=bug
docx CR_6159_resolution_v3.docx (50,836) 11-07-2012 15:36
http://oldforge.etsi.org/mantis/file_download.php?file_id=2674&type=bug
Issue History
Date ModifiedUsernameFieldChange
04-07-2012 13:27Tomas UrbanNew Issue
04-07-2012 13:27Tomas UrbanClause Reference(s) => 15.6.2
04-07-2012 13:27Tomas UrbanSource (company - Author) =>
10-07-2012 09:57Gyorgy RethyNote Added: 0010736
10-07-2012 09:57Gyorgy RethyStatusnew => assigned
10-07-2012 09:57Gyorgy RethyTarget Version => Edition 4.5.1
10-07-2012 09:59Gyorgy RethyAssigned To => Tomas Urban
11-07-2012 10:52Tomas UrbanFile Added: CR_6159.docx
11-07-2012 10:54Tomas UrbanNote Added: 0010821
11-07-2012 10:55Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
11-07-2012 11:42Gyorgy RethyFile Added: CR_6159_resolution_v2.docx
11-07-2012 11:44Gyorgy RethyNote Added: 0010833
11-07-2012 11:45Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
11-07-2012 15:19Ina SchieferdeckerFile Added: CR_6159_resolution_v3.docx
11-07-2012 15:36Ina SchieferdeckerFile Deleted: CR_6159_resolution_v3.docx
11-07-2012 15:36Ina SchieferdeckerFile Added: CR_6159_resolution_v3.docx
11-07-2012 15:37Ina SchieferdeckerStatusassigned => resolved
11-07-2012 15:37Ina SchieferdeckerResolutionopen => fixed
11-07-2012 15:37Ina SchieferdeckerNote Added: 0010838
11-07-2012 15:37Ina SchieferdeckerStatusresolved => closed
11-07-2012 15:37Ina SchieferdeckerFixed in Version => Edition 4.5.1
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010736) +
+ Gyorgy Rethy    +
+ 10-07-2012 09:57    +
+ 		+ + + + +
+ STF discussion 2012-07-10: proposal agreed; rule for the case when an unselected choice is referenced to be added to clause 6.2.5.1.
+
+
+
+ + + + + + + + + + +
+ (0010821) +
+ Tomas Urban    +
+ 11-07-2012 10:54    +
+ 		+ + + + +
+ Changed as agreed. I slightly modified 6.2.6 (the anytype) too.
+
+
+
+ + + + + + + + + + +
+ (0010833) +
+ Gyorgy Rethy    +
+ 11-07-2012 11:44    +
+ 		+ + + + +
+ Technically OK, just a few words changed to align it to the wording generally used in the standard. See text in CR_6159_resolution_v2.docx. Can be implemented.
+
+
+
+ + + + + + + + + + +
+ (0010838) +
+ Ina Schieferdecker    +
+ 11-07-2012 15:37    +
+ 		+ + + + +
+ Implemented as in v3
+
+ + diff --git a/docs/mantis/CR6160.md b/docs/mantis/CR6160.md new file mode 100644 index 0000000000000000000000000000000000000000..29c8141ab47cf8ac2abe0432aff372cc77594cf4 --- /dev/null +++ b/docs/mantis/CR6160.md @@ -0,0 +1,97 @@ + + + + + + + + + + + + + 0006160: Invalid reference to AnyValueOrNone in 15.6.3.c - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006160Part 01: TTCN-3 Core LanguageTechnicalpublic04-07-2012 14:2713-07-2012 14:11
ReporterTomas Urban 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.3.2 (interim 2011) 
Target Versionv4.5.1 (published 2013-04)Fixed in Versionv4.5.1 (published 2013-04) 
Clause Reference(s)15.6.3
Source (company - Author)Elvior
Summary0006160: Invalid reference to AnyValueOrNone in 15.6.3.c
DescriptionThe paragraph c of 15.6.3, contains a reference to AnyValueOrNone, which is incorrect in this context. It should be replaced with AnyElementsOrNone.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
04-07-2012 14:27Tomas UrbanNew Issue
04-07-2012 14:27Tomas UrbanClause Reference(s) => 15.6.3
04-07-2012 14:27Tomas UrbanSource (company - Author) => Elvior
10-07-2012 09:37Gyorgy RethyNote Added: 0010735
10-07-2012 09:42Gyorgy RethyAssigned To => Ina Schieferdecker
10-07-2012 09:42Gyorgy RethyStatusnew => assigned
10-07-2012 09:42Gyorgy RethyTarget Version => Edition 4.5.1
13-07-2012 14:11Ina SchieferdeckerStatusassigned => resolved
13-07-2012 14:11Ina SchieferdeckerResolutionopen => fixed
13-07-2012 14:11Ina SchieferdeckerStatusresolved => closed
13-07-2012 14:11Ina SchieferdeckerNote Added: 0010927
13-07-2012 14:11Ina SchieferdeckerFixed in Version => Edition 4.5.1
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010735) +
+ Gyorgy Rethy    +
+ 10-07-2012 09:37    +
+ 		+ + + + +
+ STF discussion 2012-07-10: comment accepted, to be implemented
+
+
+
+ + + + + + + + + + +
+ (0010927) +
+ Ina Schieferdecker    +
+ 13-07-2012 14:11    +
+ 		+ + + + +
+ As proposed.
+
+ + diff --git a/docs/mantis/CR6163.md b/docs/mantis/CR6163.md new file mode 100644 index 0000000000000000000000000000000000000000..87911f9e3e545197a29914b26cb52f24d67492bf --- /dev/null +++ b/docs/mantis/CR6163.md @@ -0,0 +1,98 @@ + + + + + + + + + + + + + 0006163: MapParam and UnmapParam not defined for the C# mapping - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006163Part 06: TTCN-3 Control InterfaceTechnicalpublic09-07-2012 15:1711-07-2012 16:29
ReporterIna Schieferdecker 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.5.1 (published 2013-04)Fixed in Versionv4.5.1 (published 2013-04) 
Clause Reference(s)12.5.3
Source (company - Author)Ina Schieferdecker, FOKUS
Summary0006163: MapParam and UnmapParam not defined for the C# mapping
DescriptionIn C# mapping of interfaces paragraph *12.5.3 TCI-CH interface*, the newly defined operations TriMapParam, TriMapParamReq, TriUnmapParam and TriUnmapParamReq were not added.
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR_6163.docx (45,383) 11-07-2012 16:15
http://oldforge.etsi.org/mantis/file_download.php?file_id=2676&type=bug
Issue History
Date ModifiedUsernameFieldChange
09-07-2012 15:17Ina SchieferdeckerNew Issue
09-07-2012 15:17Ina SchieferdeckerStatusnew => assigned
09-07-2012 15:17Ina SchieferdeckerAssigned To => Ina Schieferdecker
09-07-2012 15:17Ina SchieferdeckerClause Reference(s) => 12.5.3
09-07-2012 15:17Ina SchieferdeckerSource (company - Author) => Ina Schieferdecker, FOKUS
10-07-2012 09:49Ina SchieferdeckerAssigned ToIna Schieferdecker => Tomas Urban
11-07-2012 12:26Tomas UrbanFile Added: CR_6163.dotx
11-07-2012 12:27Tomas UrbanAssigned ToTomas Urban => Ina Schieferdecker
11-07-2012 16:15Ina SchieferdeckerFile Deleted: CR_6163.dotx
11-07-2012 16:15Ina SchieferdeckerFile Added: CR_6163.docx
11-07-2012 16:16Ina SchieferdeckerNote Added: 0010842
11-07-2012 16:29Ina SchieferdeckerStatusassigned => resolved
11-07-2012 16:29Ina SchieferdeckerResolutionopen => fixed
11-07-2012 16:29Ina SchieferdeckerFixed in Version => Edition 4.5.1
11-07-2012 16:29Ina SchieferdeckerTarget Version => Edition 4.5.1
11-07-2012 16:29Ina SchieferdeckerNote Added: 0010844
11-07-2012 16:29Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010842) +
+ Ina Schieferdecker    +
+ 11-07-2012 16:16    +
+ 		+ + + + +
+ resolution upload with same content, but in docx format
+
+
+
+ + + + + + + + + + +
+ (0010844) +
+ Ina Schieferdecker    +
+ 11-07-2012 16:29    +
+ 		+ + + + +
+ Implemented as proposed.
+
+ + diff --git a/docs/mantis/CR6164.md b/docs/mantis/CR6164.md new file mode 100644 index 0000000000000000000000000000000000000000..80ed126871b977cae74198b72c3e5fc32babf634 --- /dev/null +++ b/docs/mantis/CR6164.md @@ -0,0 +1,65 @@ + + + + + + + + + + + + + 0006164: MapParam and UnmapParam not defined for the C# mapping - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 05: TTCN-3 Runtime Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006164Part 05: TTCN-3 Runtime Interface Technicalpublic09-07-2012 15:1912-07-2012 16:38
ReporterIna Schieferdecker 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.5.1 (published 2013-04)Fixed in Versionv4.5.1 (published 2013-04) 
Clause Reference(s)9.5.2.1
Source (company - Author)Sebastien CASTANO, ITU TSB
Summary0006164: MapParam and UnmapParam not defined for the C# mapping
DescriptionIn C# mapping of interfaces paragraph *9.5.2.1* (interface ITriCommunicationSA), the newly defined operations *TriMapParam* (Ref:
+5.5.2.3) and *TriUnmapParam* (Ref: 5.5.2.4) were not added.
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR_6164.doc (59,904) 11-07-2012 12:18
http://oldforge.etsi.org/mantis/file_download.php?file_id=2670&type=bug
Issue History
Date ModifiedUsernameFieldChange
09-07-2012 15:19Ina SchieferdeckerNew Issue
09-07-2012 15:19Ina SchieferdeckerStatusnew => assigned
09-07-2012 15:19Ina SchieferdeckerAssigned To => Ina Schieferdecker
09-07-2012 15:19Ina SchieferdeckerClause Reference(s) => 9.5.2.1
09-07-2012 15:19Ina SchieferdeckerSource (company - Author) => Sebastien CASTANO, ITU TSB
10-07-2012 09:46Ina SchieferdeckerAssigned ToIna Schieferdecker => Tomas Urban
11-07-2012 12:18Tomas UrbanFile Added: CR_6164.doc
11-07-2012 12:19Tomas UrbanAssigned ToTomas Urban => Ina Schieferdecker
12-07-2012 16:37Ina SchieferdeckerStatusassigned => resolved
12-07-2012 16:37Ina SchieferdeckerResolutionopen => fixed
12-07-2012 16:37Ina SchieferdeckerTarget Version => Edition 4.5.1
12-07-2012 16:38Ina SchieferdeckerNote Added: 0010897
12-07-2012 16:38Ina SchieferdeckerStatusresolved => closed
12-07-2012 16:38Ina SchieferdeckerFixed in Version => Edition 4.5.1
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010897) +
+ Ina Schieferdecker    +
+ 12-07-2012 16:38    +
+ 		+ + + + +
+ Implemented as proposed
+
+ + diff --git a/docs/mantis/CR6165.md b/docs/mantis/CR6165.md new file mode 100644 index 0000000000000000000000000000000000000000..0c27fdeefff39a5448097767362315fbf7e89cfd --- /dev/null +++ b/docs/mantis/CR6165.md @@ -0,0 +1,102 @@ + + + + + + + + + + + + + 0006165: Add recof2setof predefined function - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006165Part 01: TTCN-3 Core LanguageNew Featurepublic09-07-2012 15:5716-07-2012 11:39
ReporterGyorgy Rethy 
Assigned To 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionno change required 
PlatformOSOS Version
Product Version 
Target Versionv4.5.1 (published 2013-04)Fixed in Version 
Clause Reference(s)new
Source (company - Author)L.M.Ericsson
Summary0006165: Add recof2setof predefined function
DescriptionUse case: several IMS protocols defined in XSD contain list of structured information elements, where the list is defined by minOccurs and maxOccurs in XSD. So, the list of structures is translated to TTCN-3 as a record of record. The SUT may send the IEs in an arbitray order (SUT dependent, no mandatory order in the spec.). During functional testing most test cases checks the content (which IEs are included and what is the content, but the order is irrelevant), while in a few test cases also the order is checked (if a given structure was the Nth element). Therefore a general replacement of all record of-s with set of-s in the type definition modules is not a solution.
+The proposed solution is to add a conversion function to convert record ofs to set ofs before matching the relevant part of a received message with a template. The returned type should be
+a) a "mirror" type of the input record of, in which case the result can be returned as a return value and be saved into any compatible set of variable or be piped to e.g. a match predef. function
+b) the outpout is returned as an out parameer, in which case the type of the variable passed to the function as the out parameter.
+
+Solution a) is preferred as the purpose of the requests is to pipe the resulted st of to the match function directly.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0006008closed  Match omit мы undefined value 
related to 0006088closed Ina Schieferdecker superset/subset/permutation/complement should also be possible with dynamic lists 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
09-07-2012 15:57Gyorgy RethyNew Issue
09-07-2012 15:57Gyorgy RethyClause Reference(s) => new
09-07-2012 15:57Gyorgy RethySource (company - Author) => L.M.Ericsson
09-07-2012 16:55Ina SchieferdeckerProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
09-07-2012 17:12Gyorgy RethyNote Added: 0010727
10-07-2012 09:32Ina SchieferdeckerRelationship addedrelated to 0006008
10-07-2012 11:58Gyorgy RethyTarget Version => Edition 4.5.1
10-07-2012 11:59Gyorgy RethyRelationship addedrelated to 0006088
16-07-2012 11:39Gyorgy RethyNote Added: 0010938
16-07-2012 11:39Gyorgy RethyStatusnew => closed
16-07-2012 11:39Gyorgy RethyResolutionopen => no change required
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010727) +
+ Gyorgy Rethy    +
+ 09-07-2012 17:12    +
+ 		+ + + + +
+ Actually, if accepting CR 6088 as proposed plus my proposal for the syntax would solve the problem mentioned above and annulate this CR.
+
+
+
+ + + + + + + + + + +
+ (0010938) +
+ Gyorgy Rethy    +
+ 16-07-2012 11:39    +
+ 		+ + + + +
+ This CR is withdrawn since CR 6088 has been resolved.
+
+ + diff --git a/docs/mantis/CR6167.md b/docs/mantis/CR6167.md new file mode 100644 index 0000000000000000000000000000000000000000..0277eab1720529953fea6285a9802bfa3eaf5386 --- /dev/null +++ b/docs/mantis/CR6167.md @@ -0,0 +1,146 @@ + + + + + + + + + + + + + 0006167: xtriEnqueueMsg sutAddress should be of type Object rather than Value - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Extended TRI (ES 202 789)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006167Ext Pack: Extended TRI (ES 202 789)Technicalpublic10-07-2012 13:4111-12-2012 15:00
Reportertepelmann 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv1.2.1 (published 2013-04)Fixed in Versionv1.2.1 (published 2013-04) 
Clause Reference(s)6.5.2.2 Changes to triCommunicationTE
Source (company - Author)     Testing Technologies - tepelmann
Summary0006167: xtriEnqueueMsg sutAddress should be of type Object rather than Value
DescriptionAnalogue to the other defined xtri enqueue method, the sutAddress of xtriEnqueueMsg should also be of type Object instead of type Value:
+
+public interface xTriCommunicationTE {
+// Message based communication operations
+// Ref: TRI-Definition 5.5.3.4
+public void xtriEnqueueMsg(TriPortId tsiPortId,
+Value sutAddress, TriComponentId componentId,
+Object receivedMessage);
+
+should be:
+public interface xTriCommunicationTE {
+// Message based communication operations
+// Ref: TRI-Definition 5.5.3.4
+public void xtriEnqueueMsg(TriPortId tsiPortId,
+Object sutAddress, TriComponentId componentId,
+Object receivedMessage);
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
10-07-2012 13:41tepelmannNew Issue
10-07-2012 13:41tepelmannClause Reference(s) => 6.5.2.2 Changes to triCommunicationTE
10-07-2012 13:41tepelmannSource (company - Author) => Testing Technologies - tepelmann
10-07-2012 14:51Gyorgy RethyProjectTTCN-3 Change Requests => Part 05: TTCN-3 Runtime Interface
10-07-2012 14:52Gyorgy RethyAssigned To => Ina Schieferdecker
10-07-2012 14:52Gyorgy RethyStatusnew => assigned
10-07-2012 14:52Gyorgy RethyTarget Version => Edition 4.5.1
10-07-2012 14:54Gyorgy RethyNote Added: 0010766
10-07-2012 15:00Ina SchieferdeckerProjectPart 05: TTCN-3 Runtime Interface => Ext Pack: Extended TRI (ES 202 789)
10-07-2012 15:05Ina SchieferdeckerNote Added: 0010770
11-12-2012 14:59Ina SchieferdeckerNote Added: 0011233
11-12-2012 15:00Ina SchieferdeckerStatusassigned => resolved
11-12-2012 15:00Ina SchieferdeckerResolutionopen => fixed
11-12-2012 15:00Ina SchieferdeckerFixed in Version => Edition 1.2.1 (ongoing)
11-12-2012 15:00Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010766) +
+ Gyorgy Rethy    +
+ 10-07-2012 14:54    +
+ 		+ + + + +
+ STF discussion 2012-07-10: to be checked
+
+
+
+ + + + + + + + + + +
+ (0010770) +
+ Ina Schieferdecker    +
+ 10-07-2012 15:05    +
+ 		+ + + + +
+ Right. As defined in the other enqueue operations and the other mappings
+
+
+
+ + + + + + + + + + +
+ (0011233) +
+ Ina Schieferdecker    +
+ 11-12-2012 14:59    +
+ 		+ + + + +
+ Defined for Java as proposed.
+
+ + diff --git a/docs/mantis/CR6168.md b/docs/mantis/CR6168.md new file mode 100644 index 0000000000000000000000000000000000000000..0e05496035199dc9186c6377546618712596cb0c --- /dev/null +++ b/docs/mantis/CR6168.md @@ -0,0 +1,166 @@ + + + + + + + + + + + + + 0006168: xtriConvert should be located in xtriCommunicationSA instead of xtriCommunicationTE - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Extended TRI (ES 202 789)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006168Ext Pack: Extended TRI (ES 202 789)Technicalpublic10-07-2012 13:5911-12-2012 14:54
Reportertepelmann 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv1.2.1 (published 2013-04)Fixed in Versionv1.2.1 (published 2013-04) 
Clause Reference(s)6.5.2.2, 8.6.2, 9.5.5.2
Source (company - Author)     Testing Technologies - tepelmann
Summary0006168: xtriConvert should be located in xtriCommunicationSA instead of xtriCommunicationTE
DescriptionxtriConvert provides functionality for the TE. Therefore it should be located rather in the xtriCommunicationSA interface as here the methods provide functionality for the TE, than in the xtriCommunicationTE interface, where the methods are listed which are required from the TE.
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0006330closed Ina Schieferdecker Pointer value in C and C++ mapping 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
10-07-2012 13:59tepelmannNew Issue
10-07-2012 13:59tepelmannClause Reference(s) => 6.5.2.2, 8.6.2, 9.5.5.2
10-07-2012 13:59tepelmannSource (company - Author) => Testing Technologies - tepelmann
10-07-2012 14:52Gyorgy RethyProjectTTCN-3 Change Requests => Part 05: TTCN-3 Runtime Interface
10-07-2012 14:53Gyorgy RethyNote Added: 0010765
10-07-2012 14:53Gyorgy RethyAssigned To => Ina Schieferdecker
10-07-2012 14:53Gyorgy RethyStatusnew => assigned
10-07-2012 14:53Gyorgy RethyTarget Version => Edition 4.5.1
10-07-2012 14:59Ina SchieferdeckerNote Added: 0010767
10-07-2012 15:00Ina SchieferdeckerProjectPart 05: TTCN-3 Runtime Interface => Ext Pack: Extended TRI (ES 202 789)
10-07-2012 15:02tepelmannNote Added: 0010769
11-12-2012 14:53Ina SchieferdeckerNote Added: 0011232
11-12-2012 14:54Ina SchieferdeckerStatusassigned => resolved
11-12-2012 14:54Ina SchieferdeckerResolutionopen => fixed
11-12-2012 14:54Ina SchieferdeckerFixed in Version => Edition 1.2.1 (ongoing)
11-12-2012 14:54Ina SchieferdeckerStatusresolved => closed
13-12-2012 12:57Ina SchieferdeckerRelationship addedrelated to 0006330
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010765) +
+ Gyorgy Rethy    +
+ 10-07-2012 14:53    +
+ 		+ + + + +
+ STF discussion 2012-07-10: to be checked
+
+
+
+ + + + + + + + + + +
+ (0010767) +
+ Ina Schieferdecker    +
+ 10-07-2012 14:59    +
+ 		+ + + + +
+ This CR should no be resolved by moving to another section in the standard, but rather be resolved by indicating the direction for that operation as it is done by the other operations. This has been left out and should be added: SA --> TE
+
+
+
+ + + + + + + + + + +
+ (0010769) +
+ tepelmann    +
+ 10-07-2012 15:02    +
+ 		+ + + + +
+ This is fine from my side, however the Java mapping will have the interfaces...
+
+
+
+ + + + + + + + + + +
+ (0011232) +
+ Ina Schieferdecker    +
+ 11-12-2012 14:53    +
+ 		+ + + + +
+ Implemented as initially proposed - for Java, C++ and C#.
+
+ + diff --git a/docs/mantis/CR6169.md b/docs/mantis/CR6169.md new file mode 100644 index 0000000000000000000000000000000000000000..85e47d772d23903bc51f816df766c835be4f152e --- /dev/null +++ b/docs/mantis/CR6169.md @@ -0,0 +1,407 @@ + + + + + + + + + + + + + 0006169: The pattern char grammar has been mixed up - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006169Part 01: TTCN-3 Core LanguageTechnicalpublic10-07-2012 18:0121-12-2012 10:46
ReporterIna Schieferdecker 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.5.1 (published 2013-04)Fixed in Versionv4.5.1 (published 2013-04) 
Clause Reference(s)A1.6 rules 112-122
Source (company - Author)Ina Schieferdecker, FOKUS
Summary0006169: The pattern char grammar has been mixed up
DescriptionIn the current grammar, the new PatternClassChar is not yet used:
+
+112. CharStringMatch ::= PatternKeyword PatternParticle {"&" PatternParticle}
+113. PatternParticle ::= Pattern | ReferencedValue
+114. PatternKeyword ::= "pattern"
+115. Pattern ::= """ {PatternElement} """
+116. PatternElement ::= ("\" ("?" | "*" | "\" | "[" | "]" | "{" | "}" |
+                              """ | "|" | "(" | ")" | "#" | "+" | "d" |
+                              "w" | "t" | "n" | "r" | "s" | "b"
+                             )) | ("?" | "*" | "\" | "|" | "+"
+                                  ) | ("[" ["^"] [{PatternChar ["-" PatternChar]}]
+                                       "]") |
+                        ("{" ReferencedValue "}") |
+                        ("\" "N" "{" (ReferencedValue | Type) "}") |
+                        (""" """) |
+                        ("(" PatternElement ")") |
+                        ("#" (Num |
+                              ("(" Num "," [Num] ")") | ("(" "," Num ")")
+                             )) |
+                        PatternChar
+117. PatternChar ::= NonSpecialPatternChar | PatternQuadruple
+118. NonSpecialPatternChar ::= Char
+/* STATIC SEMANTICS: NonSpecialPatternChar shall not be one of the following characters: "\", "?", "*", "|", "+", "[", "{", """, "(", "#" */
+119. PatternClassChar ::= NonSpecialPatternClassChar |
+                          PatternQuadruple |
+                          "\" EscapedPatternClassChar
+120. NonSpecialPatternClassChar ::= Char
+/* STATIC SEMANTICS: NonSpecialPatternClassChar shall not be one of the following characters: "-", "^", "]" */
+121. EscapedPatternClassChar ::= Char
+/* STATIC SEMANTICS: EscapedPatternClassChar shall not be one of the following characters: "q" */
+122. PatternQuadruple ::= "\" "q" "(" Number "," Number "," Number ","
+                          Number ")"
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0005805closed Ina Schieferdecker BNF rule for PatternElement is ambiguous, Example is wrong 
related to 0006009closed Ina Schieferdecker Charstring Pattern Reference Parts should not be allowed 
related to 0006014closed Ina Schieferdecker Simplifications request for escaping chars inside the string pattern 
Attached Filesdocx CR6169_CharStringMatch.docx (15,545) 10-07-2012 18:14
http://oldforge.etsi.org/mantis/file_download.php?file_id=2660&type=bug
docx CR6169_CharStringMatch_v2.docx (19,047) 12-12-2012 10:48
http://oldforge.etsi.org/mantis/file_download.php?file_id=2769&type=bug
docx CR6169_CharStringMatch_v3.docx (18,301) 12-12-2012 17:32
http://oldforge.etsi.org/mantis/file_download.php?file_id=2774&type=bug
docx CR6169_CharStringMatch_v4.docx (18,759) 20-12-2012 14:18
http://oldforge.etsi.org/mantis/file_download.php?file_id=2791&type=bug
Issue History
Date ModifiedUsernameFieldChange
10-07-2012 18:01Ina SchieferdeckerNew Issue
10-07-2012 18:01Ina SchieferdeckerStatusnew => assigned
10-07-2012 18:01Ina SchieferdeckerAssigned To => Ina Schieferdecker
10-07-2012 18:01Ina SchieferdeckerClause Reference(s) => A1.6 rules 112-121
10-07-2012 18:01Ina SchieferdeckerSource (company - Author) => Ina Schieferdecker, FOKUS
10-07-2012 18:01Ina SchieferdeckerRelationship addedrelated to 0005805
10-07-2012 18:07Ina SchieferdeckerClause Reference(s)A1.6 rules 112-121 => A1.6 rules 112-122
10-07-2012 18:07Ina SchieferdeckerTarget Version => Edition 4.5.1
10-07-2012 18:07Ina SchieferdeckerSummaryThe pattern Char grammar has been mixed up => The pattern char grammar has been mixed up
10-07-2012 18:07Ina SchieferdeckerDescription Updated
10-07-2012 18:14Ina SchieferdeckerFile Added: CR6169_CharStringMatch.docx
10-07-2012 18:14Ina SchieferdeckerNote Added: 0010774
10-07-2012 18:15Ina SchieferdeckerAssigned ToIna Schieferdecker => Tomas Urban
11-07-2012 16:41Tomas UrbanNote Added: 0010846
11-07-2012 16:41Tomas UrbanAssigned ToTomas Urban => Ina Schieferdecker
13-07-2012 14:20Gyorgy RethyNote Added: 0010928
13-07-2012 14:21Gyorgy RethyNote Edited: 0010928
13-07-2012 14:22Gyorgy RethyNote Deleted: 0010928
13-07-2012 14:33Gyorgy RethyNote Added: 0010931
13-07-2012 16:23Gyorgy RethyNote Edited: 0010931
12-12-2012 10:17Ina SchieferdeckerFile Added: CR6169_CharStringMatch_v2.docx
12-12-2012 10:24Ina SchieferdeckerFile Deleted: CR6169_CharStringMatch_v2.docx
12-12-2012 10:48Ina SchieferdeckerFile Added: CR6169_CharStringMatch_v2.docx
12-12-2012 10:49Ina SchieferdeckerNote Added: 0011239
12-12-2012 10:49Ina SchieferdeckerAssigned ToIna Schieferdecker => Tomas Urban
12-12-2012 10:49Ina SchieferdeckerRelationship addedrelated to 0006009
12-12-2012 17:32Ina SchieferdeckerFile Added: CR6169_CharStringMatch_v3.docx
12-12-2012 17:33Ina SchieferdeckerNote Added: 0011249
14-12-2012 11:17Tomas UrbanRelationship addedrelated to 0006014
14-12-2012 12:17Tomas UrbanNote Added: 0011274
14-12-2012 12:17Tomas UrbanAssigned ToTomas Urban => Ina Schieferdecker
20-12-2012 14:09Ina SchieferdeckerNote Added: 0011298
20-12-2012 14:18Ina SchieferdeckerFile Added: CR6169_CharStringMatch_v4.docx
20-12-2012 14:18Ina SchieferdeckerAssigned ToIna Schieferdecker => Tomas Urban
20-12-2012 14:19Ina SchieferdeckerNote Added: 0011299
20-12-2012 14:29Tomas UrbanNote Added: 0011300
20-12-2012 14:29Tomas UrbanAssigned ToTomas Urban => Ina Schieferdecker
21-12-2012 10:46Ina SchieferdeckerNote Added: 0011305
21-12-2012 10:46Ina SchieferdeckerStatusassigned => closed
21-12-2012 10:46Ina SchieferdeckerResolutionopen => fixed
21-12-2012 10:46Ina SchieferdeckerFixed in Version => Edition 4.5.1
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010774) +
+ Ina Schieferdecker    +
+ 10-07-2012 18:14    +
+ 		+ + + + +
+ Please check.
+
+
+
+ + + + + + + + + + +
+ (0010846) +
+ Tomas Urban    +
+ 11-07-2012 16:41    +
+ 		+ + + + +
+ I think the modification is correct and can be added to the standard.
+
+
+
+ + + + + + + + + + +
+ (0010931) +
+ Gyorgy Rethy    +
+ 13-07-2012 14:33    +
(edited on: 13-07-2012 16:23)
+ 		+ + + + +
+ PatternChar is not corect, because it
+- would not allow single "{" without escaping it that would be a non-backward compatible change and refused in CR6009.
+- would not allow "?", "*", "|", "+", "[", "{", """, "(", "#" within set expressions, where these characters not only allowed but explicitly defined that has a literal character meaning.
+
+But in general I don't understand why we need the whole PatternElement production at all, when finaly NonSpecialPatternChar has to be restricted by a human-readable static semantic rule. This just complicates the BNF, makes it unreadable and useless. Users will look at the pattern rules in clause B.1.5 anyway and tools will check the content during semantic checking anyway (due to possible references they have to).
+
+
+
+
+
+ + + + + + + + + + +
+ (0011239) +
+ Ina Schieferdecker    +
+ 12-12-2012 10:49    +
+ 		+ + + + +
+ Please check.
+
+
+
+ + + + + + + + + + +
+ (0011249) +
+ Ina Schieferdecker    +
+ 12-12-2012 17:33    +
+ 		+ + + + +
+ Revised the static semantic rules to have a strict and weak interpretation of the patterns.
+
+
+
+ + + + + + + + + + +
+ (0011274) +
+ Tomas Urban    +
+ 14-12-2012 12:17    +
+ 		+ + + + +
+ As a result of a discussion on patterns, it was suggested to remove the static semantics from the BNF. I would also recommend to have just one rule for escaped characters in the BNF to simplify the grammar. The rule would include all explicitly specified escape characters (listed in table B.1) and \ + any character.
+
+
+
+ + + + + + + + + + +
+ (0011298) +
+ Ina Schieferdecker    +
+ 20-12-2012 14:09    +
+ 		+ + + + +
+ The final discussion was to keep the BNF structure, but to have special character semantics only when they follow the specific syntax - otherwise they are interpreted like any other character - see v4
+
+
+
+ + + + + + + + + + +
+ (0011299) +
+ Ina Schieferdecker    +
+ 20-12-2012 14:19    +
+ 		+ + + + +
+ Please check.
+
+
+
+ + + + + + + + + + +
+ (0011300) +
+ Tomas Urban    +
+ 20-12-2012 14:29    +
+ 		+ + + + +
+ I am generally fine with the solution. Only if the escaped reference is added as a part of 6014, it will have to appear in the BNF as well.
+
+
+
+ + + + + + + + + + +
+ (0011305) +
+ Ina Schieferdecker    +
+ 21-12-2012 10:46    +
+ 		+ + + + +
+ Implemented.
+
+ + diff --git a/docs/mantis/CR6173.md b/docs/mantis/CR6173.md new file mode 100644 index 0000000000000000000000000000000000000000..9abfd0df67a6e4b535cc6d868dd99eaf42602df1 --- /dev/null +++ b/docs/mantis/CR6173.md @@ -0,0 +1,99 @@ + + + + + + + + + + + + + 0006173: TCI C# mapping with fully qualified TRI references - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006173Part 06: TTCN-3 Control InterfaceTechnicalpublic11-07-2012 13:4712-07-2012 10:13
ReporterIna Schieferdecker 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.4.1 (published 2012-04) 
Target Versionv4.5.1 (published 2013-04)Fixed in Versionv4.5.1 (published 2013-04) 
Clause Reference(s)12.5
Source (company - Author)Ina Schieferdecker, FOKUS
Summary0006173: TCI C# mapping with fully qualified TRI references
DescriptionThe C# mapping in TCI uses fully qualified TRI references, which is however not needed as the TRI and TCI definitions are separated by the Tri and Tci prefixes respectively.
+
+I suggest to use just the identifiers without qualification to ease readability and maintainability.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR_6173_resolution_v1.docx (69,237) 11-07-2012 18:06
http://oldforge.etsi.org/mantis/file_download.php?file_id=2680&type=bug
Issue History
Date ModifiedUsernameFieldChange
11-07-2012 13:47Ina SchieferdeckerNew Issue
11-07-2012 13:47Ina SchieferdeckerStatusnew => assigned
11-07-2012 13:47Ina SchieferdeckerAssigned To => Tomas Urban
11-07-2012 13:47Ina SchieferdeckerClause Reference(s) => 12.5
11-07-2012 13:47Ina SchieferdeckerSource (company - Author) => Ina Schieferdecker, FOKUS
11-07-2012 13:48Ina SchieferdeckerProjectPart 05: TTCN-3 Runtime Interface => Part 06: TTCN-3 Control Interface
11-07-2012 18:06Tomas UrbanFile Added: CR_6173_resolution_v1.docx
11-07-2012 18:07Tomas UrbanNote Added: 0010853
11-07-2012 18:07Tomas UrbanAssigned ToTomas Urban => Ina Schieferdecker
12-07-2012 10:12Ina SchieferdeckerStatusassigned => resolved
12-07-2012 10:12Ina SchieferdeckerResolutionopen => fixed
12-07-2012 10:12Ina SchieferdeckerTarget Version => Edition 4.5.1
12-07-2012 10:13Ina SchieferdeckerNote Added: 0010862
12-07-2012 10:13Ina SchieferdeckerStatusresolved => closed
12-07-2012 10:13Ina SchieferdeckerFixed in Version => Edition 4.5.1
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010853) +
+ Tomas Urban    +
+ 11-07-2012 18:07    +
+ 		+ + + + +
+ Resolution draft attached. Please check.
+
+
+
+ + + + + + + + + + +
+ (0010862) +
+ Ina Schieferdecker    +
+ 12-07-2012 10:13    +
+ 		+ + + + +
+ Implemented as proposed with some editorial changes
+
+ + diff --git a/docs/mantis/CR6174.md b/docs/mantis/CR6174.md new file mode 100644 index 0000000000000000000000000000000000000000..66705358bcb183088a81ff350e2171486a418ce5 --- /dev/null +++ b/docs/mantis/CR6174.md @@ -0,0 +1,125 @@ + + + + + + + + + + + + + 0006174: Incorrect example for complemented template list - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006174Part 01: TTCN-3 Core LanguageEditorialpublic11-07-2012 14:2513-07-2012 13:51
ReporterIna Schieferdecker 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.5.1 (published 2013-04)Fixed in Versionv4.5.1 (published 2013-04) 
Clause Reference(s)B.1.2.2
Source (company - Author)Ina Schieferdecker, FOKUS
Summary0006174: Incorrect example for complemented template list
DescriptionThe example given in clause B.1.2.2 on complemented template list should be corrected from
+
+template MyMessage MyTemplate:=
+{
+    complement (1,3,5), // list of unacceptable integer values
+    :
+    field3 not(true) // will match false
+    :
+}
+
+to
+
+template MyMessage MyTemplate:=
+{
+    field1 := complement (1,3,5), // list of unacceptable integer values
+    :
+    field3 := not(true) // will match false
+    :
+}
+
+The type definition is given in B.1.1:
+    type record MyMessageType
+    {
+        integer field1,
+        charstring field2,
+        boolean field3 optional,
+        integer field4[4]
+    }
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR_6174.docx (44,187) 11-07-2012 16:32
http://oldforge.etsi.org/mantis/file_download.php?file_id=2677&type=bug
Issue History
Date ModifiedUsernameFieldChange
11-07-2012 14:25Ina SchieferdeckerNew Issue
11-07-2012 14:25Ina SchieferdeckerStatusnew => assigned
11-07-2012 14:25Ina SchieferdeckerAssigned To => Tomas Urban
11-07-2012 14:25Ina SchieferdeckerClause Reference(s) => B.1.2.2
11-07-2012 14:25Ina SchieferdeckerSource (company - Author) => Ina Schieferdecker, FOKUS
11-07-2012 16:32Tomas UrbanFile Added: CR_6174.docx
11-07-2012 16:33Tomas UrbanNote Added: 0010845
11-07-2012 16:33Tomas UrbanAssigned ToTomas Urban => Ina Schieferdecker
13-07-2012 13:51Ina SchieferdeckerStatusassigned => resolved
13-07-2012 13:51Ina SchieferdeckerResolutionopen => fixed
13-07-2012 13:51Ina SchieferdeckerTarget Version => Edition 4.5.1
13-07-2012 13:51Ina SchieferdeckerStatusresolved => closed
13-07-2012 13:51Ina SchieferdeckerNote Added: 0010925
13-07-2012 13:51Ina SchieferdeckerFixed in Version => Edition 4.5.1
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010845) +
+ Tomas Urban    +
+ 11-07-2012 16:33    +
+ 		+ + + + +
+ Please verify the change.
+
+
+
+ + + + + + + + + + +
+ (0010925) +
+ Ina Schieferdecker    +
+ 13-07-2012 13:51    +
+ 		+ + + + +
+ as proposed.
+
+ + diff --git a/docs/mantis/CR6175.md b/docs/mantis/CR6175.md new file mode 100644 index 0000000000000000000000000000000000000000..38229951ad4d35cf8bbeade79fb212c0682cd9e9 --- /dev/null +++ b/docs/mantis/CR6175.md @@ -0,0 +1,72 @@ + + + + + + + + + + + + + 0006175: Typos in TCI Java Mapping - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006175Part 06: TTCN-3 Control InterfaceEditorialpublic11-07-2012 15:5211-07-2012 16:13
ReporterIna Schieferdecker 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.4.1 (published 2012-04) 
Target Versionv4.5.1 (published 2013-04)Fixed in Versionv4.5.1 (published 2013-04) 
Clause Reference(s)8
Source (company - Author)Peter Enskonatus, FOKUS
Summary0006175: Typos in TCI Java Mapping
DescriptionIn tci/RecordValue.java, tci/TciCHProvided.java, tci/TciCHRequired.java, tci/TciValueDifference.java are missing semicolons at the end
+
+In tci/TciTLProvided.java is a missing comma in a parameter list
+
+"in" specifiers in 8.5.4 should be removed
+
+Furthermore, Tstring needs to be String and TriComponent needs to be TriComponentId.
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
11-07-2012 15:52Ina SchieferdeckerNew Issue
11-07-2012 15:52Ina SchieferdeckerStatusnew => assigned
11-07-2012 15:52Ina SchieferdeckerAssigned To => Ina Schieferdecker
11-07-2012 15:52Ina SchieferdeckerClause Reference(s) => 8
11-07-2012 15:52Ina SchieferdeckerSource (company - Author) => Peter Enskonatus, FOKUS
11-07-2012 15:59Ina SchieferdeckerDescription Updated
11-07-2012 16:12Ina SchieferdeckerNote Added: 0010841
11-07-2012 16:13Ina SchieferdeckerStatusassigned => resolved
11-07-2012 16:13Ina SchieferdeckerResolutionopen => fixed
11-07-2012 16:13Ina SchieferdeckerTarget Version => Edition 4.5.1
11-07-2012 16:13Ina SchieferdeckerStatusresolved => closed
11-07-2012 16:13Ina SchieferdeckerFixed in Version => Edition 4.5.1
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010841) +
+ Ina Schieferdecker    +
+ 11-07-2012 16:12    +
+ 		+ + + + +
+ As proposed above: the missing comma was in tliMSend_m_BC
+
+Corrected in addition AddressValue in 8.3.4.15, where leading "> " had to be removed
+
+ + diff --git a/docs/mantis/CR6176.md b/docs/mantis/CR6176.md new file mode 100644 index 0000000000000000000000000000000000000000..497e9409990cbdafccc6976fb2fd84d5a69e87c0 --- /dev/null +++ b/docs/mantis/CR6176.md @@ -0,0 +1,98 @@ + + + + + + + + + + + + + 0006176: Extension of triErrorReq to Object - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Extended TRI (ES 202 789)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006176Ext Pack: Extended TRI (ES 202 789)New Featurepublic12-07-2012 16:4712-12-2012 16:47
ReporterIna Schieferdecker 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv1.2.1 (published 2013-04)Fixed in Versionv1.2.1 (published 2013-04) 
Clause Reference(s)
Source (company - Author)     Testing Technologies - tepelmann
Summary0006176: Extension of triErrorReq to Object
DescriptionIn addition to CR6015, for the extended TRI there could be an additional method with a parameter of type Object, where the error can be given in any representation, i.e. as exception.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0006384closed Ina Schieferdecker Ext Pack: Extended TRI (ES 202 789) C# mapping: Object -> object 
child of 0006015closed Ina Schieferdecker Part 05: TTCN-3 Runtime Interface  Introduction of triErrorReq for the TRI as it is defined in TCI-CD 
Attached Fileszip CR6176_es_202789v010102.zip (142,428) 12-12-2012 14:23
http://oldforge.etsi.org/mantis/file_download.php?file_id=2771&type=bug
Issue History
Date ModifiedUsernameFieldChange
12-07-2012 16:47Ina SchieferdeckerNew Issue
12-07-2012 16:47Ina SchieferdeckerStatusnew => assigned
12-07-2012 16:47Ina SchieferdeckerAssigned To => Ina Schieferdecker
12-07-2012 16:47Ina SchieferdeckerClause Reference(s) => 201 873-5 V4.3.1 - 5.2
12-07-2012 16:47Ina SchieferdeckerSource (company - Author) => Testing Technologies - tepelmann
12-07-2012 16:47Ina SchieferdeckerIssue generated from: 0006015
12-07-2012 16:47Ina SchieferdeckerRelationship addedchild of 0006015
12-07-2012 16:47Ina SchieferdeckerClause Reference(s)201 873-5 V4.3.1 - 5.2 =>
12-07-2012 16:47Ina SchieferdeckerProjectPart 05: TTCN-3 Runtime Interface => Ext Pack: Extended TRI (ES 202 789)
10-12-2012 16:57Gyorgy RethyTarget Version => Edition 1.2.1 (ongoing)
12-12-2012 14:23Ina SchieferdeckerNote Added: 0011243
12-12-2012 14:23Ina SchieferdeckerFile Added: CR6176_es_202789v010102.zip
12-12-2012 14:24Ina SchieferdeckerAssigned ToIna Schieferdecker => Tomas Urban
12-12-2012 14:24Ina SchieferdeckerResolutionopen => fixed
12-12-2012 14:50Tomas UrbanNote Added: 0011245
12-12-2012 14:50Tomas UrbanAssigned ToTomas Urban => Ina Schieferdecker
12-12-2012 16:46Ina SchieferdeckerRelationship addedrelated to 0006384
12-12-2012 16:47Ina SchieferdeckerStatusassigned => resolved
12-12-2012 16:47Ina SchieferdeckerFixed in Version => Edition 1.2.1 (ongoing)
12-12-2012 16:47Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011243) +
+ Ina Schieferdecker    +
+ 12-12-2012 14:23    +
+ 		+ + + + +
+ Implemented with an additional optional parameter of any type.
+Please check.
+
+
+
+ + + + + + + + + + +
+ (0011245) +
+ Tomas Urban    +
+ 12-12-2012 14:50    +
+ 		+ + + + +
+ Checked, no problems found with the changes resulting from this CR. However, I would recommend to change Object class to object in C# mapping of the XTRI. The meaning is the same, but since we use the string class with small letter in C# mapping, the object class should use the same naming convension.
+
+ + diff --git a/docs/mantis/CR6177.md b/docs/mantis/CR6177.md new file mode 100644 index 0000000000000000000000000000000000000000..2671fa15ffb4a22f976ea7ec7bc8dc364cea8f77 --- /dev/null +++ b/docs/mantis/CR6177.md @@ -0,0 +1,86 @@ + + + + + + + + + + + + + 0006177: Typos in TRI Java Mapping - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 05: TTCN-3 Runtime Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006177Part 05: TTCN-3 Runtime Interface Editorialpublic13-07-2012 11:4713-07-2012 12:08
ReporterIna Schieferdecker 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.4.1 (published 2012-04) 
Target Versionv4.5.1 (published 2013-04)Fixed in Versionv4.5.1 (published 2013-04) 
Clause Reference(s)6.3 and 6.5
Source (company - Author)Peter Enskonatus, FOKUS
Summary0006177: Typos in TRI Java Mapping
Description1. The Java mapping does not use Type postfixes - should the inconsistency be fixed or kept for stability?
+
+- public interface TriAddressListType --> public interface TriAddressList
+
+- public interface TriComponentIdListType --> public interface TriComponentIdList
+
+
+2. setParameterPassingMode in TriParameter has a wrong parameter type:
+
+public void setParameterPassingMode(in mode) --> public void setParameterPassingMode(TriParameterPassingMode mode);
+    
+
+3. triRaiseMC has a wrong parameter type:
+
+TriAddresses sutAddresses --> TriAddressList sutAddresses,
+
+
+
+    
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
13-07-2012 11:47Ina SchieferdeckerNew Issue
13-07-2012 11:47Ina SchieferdeckerStatusnew => assigned
13-07-2012 11:47Ina SchieferdeckerAssigned To => Ina Schieferdecker
13-07-2012 11:47Ina SchieferdeckerClause Reference(s) => 6.3 and 6.5
13-07-2012 11:47Ina SchieferdeckerSource (company - Author) => Peter Enskonatus, FOKUS
13-07-2012 11:58Ina SchieferdeckerNote Added: 0010917
13-07-2012 12:00Ina SchieferdeckerStatusassigned => resolved
13-07-2012 12:00Ina SchieferdeckerResolutionopen => fixed
13-07-2012 12:00Ina SchieferdeckerTarget Version => Edition 4.5.1
13-07-2012 12:00Ina SchieferdeckerStatusresolved => closed
13-07-2012 12:00Ina SchieferdeckerFixed in Version => Edition 4.5.1
13-07-2012 12:08Ina SchieferdeckerDescription Updated
13-07-2012 12:08Ina SchieferdeckerNote Edited: 0010917
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010917) +
+ Ina Schieferdecker    +
+ 13-07-2012 11:58    +
(edited on: 13-07-2012 12:08)
+ 		+ + + + +
+ 2 and 3 implemented as proposed.
+
+Wrt. 1: we should stick to the definition in the TRI as various implementations may use it already - stability takes priority over consistency/beauty
+
+
+
+ + diff --git a/docs/mantis/CR6233.md b/docs/mantis/CR6233.md new file mode 100644 index 0000000000000000000000000000000000000000..1349c0aae8a8838dad799bd9dc6ad46c8db0a82a --- /dev/null +++ b/docs/mantis/CR6233.md @@ -0,0 +1,245 @@ + + + + + + + + + + + + + 0006233: Variant overwriting rules are not correct - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006233Part 01: TTCN-3 Core LanguageTechnicalpublic24-07-2012 17:3321-12-2012 12:00
ReporterGyorgy Rethy 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.5.1 (published 2013-04)Fixed in Versionv4.5.1 (published 2013-04) 
Clause Reference(s)27.1.2.1
Source (company - Author)L.M.Ericsson
Summary0006233: Variant overwriting rules are not correct
DescriptionClause 27.1.2.1 paragraph one specifies that
+• a variant attribute overwrites an current variant attribute according to the rules defined in clause 27.1.2;
+
+However this rule, if applied, would cause problems for XSD to TTCN-3 mapping, where the encoding instructions applied to a type (e.g. XSD:decimal") and to a field this type (e.g. "name as...") shall apply at the same time. But, of course, several enoding instructions may apply to a given field as well.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
parent of 0006389closed Gyorgy Rethy Part 09: Using XML with TTCN-3 Variant overwriting rules are not correct 
Attached Fileshtm TTCN-3 language question from ETSI STF446.htm (16,074) 11-12-2012 14:05
http://oldforge.etsi.org/mantis/file_download.php?file_id=2765&type=bug
doc CR6233_resolution_P1_v1.doc (133,120) 21-12-2012 10:53
http://oldforge.etsi.org/mantis/file_download.php?file_id=2794&type=bug
doc CR6233_resolution_P1_v2.doc (111,616) 21-12-2012 11:59
http://oldforge.etsi.org/mantis/file_download.php?file_id=2797&type=bug
Issue History
Date ModifiedUsernameFieldChange
24-07-2012 17:33Gyorgy RethyNew Issue
24-07-2012 17:33Gyorgy RethyClause Reference(s) => 27.1.2.1
24-07-2012 17:33Gyorgy RethySource (company - Author) => L.M.Ericsson
08-08-2012 09:32Gyorgy RethyNote Added: 0010991
08-08-2012 09:32Gyorgy RethyStatusnew => assigned
08-08-2012 09:32Gyorgy RethyAssigned To => Gyorgy Rethy
10-12-2012 16:57Gyorgy RethyTarget Version => Edition 4.5.1
11-12-2012 13:59Gyorgy RethyNote Added: 0011224
11-12-2012 14:05Gyorgy RethyFile Added: TTCN-3 language question from ETSI STF446.htm
13-12-2012 14:54Gyorgy RethyNote Added: 0011255
14-12-2012 12:51Jacob Wieland - SpirentNote Added: 0011278
21-12-2012 10:53Gyorgy RethyFile Added: CR6233_resolution_P1_v1.doc
21-12-2012 10:53Gyorgy RethyNote Added: 0011307
21-12-2012 10:54Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
21-12-2012 10:55Gyorgy RethyIssue cloned: 0006389
21-12-2012 10:55Gyorgy RethyRelationship addedparent of 0006389
21-12-2012 11:59Ina SchieferdeckerNote Added: 0011310
21-12-2012 11:59Ina SchieferdeckerFile Added: CR6233_resolution_P1_v2.doc
21-12-2012 12:00Ina SchieferdeckerStatusassigned => resolved
21-12-2012 12:00Ina SchieferdeckerResolutionopen => fixed
21-12-2012 12:00Ina SchieferdeckerFixed in Version => Edition 4.5.1
21-12-2012 12:00Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010991) +
+ Gyorgy Rethy    +
+ 08-08-2012 09:32    +
+ 		+ + + + +
+ STF discussion 2012-08-08: ask tool vendors if changing the variant overriding rule in part one to "append" by default would be a problem for them.
+
+
+
+ + + + + + + + + + +
+ (0011224) +
+ Gyorgy Rethy    +
+ 11-12-2012 13:59    +
+ 		+ + + + +
+ E-mail has been sent to TTCN-3 tool vendors on 10-Aug and re-sent on 11-Dec. No response received.
+
+
+
+ + + + + + + + + + +
+ (0011255) +
+ Gyorgy Rethy    +
+ 13-12-2012 14:54    +
+ 		+ + + + +
+ STF discussion 2012-12-13:
+- the variant overwriting rules defined in Part-1 are the default rules; add a sentence to Part-1 that different language mappings may define their own variant attribute rules.
+- define the variant rules for the XSD mapping in Part-9
+
+
+
+ + + + + + + + + + +
+ (0011278) +
+ Jacob Wieland - Spirent    +
+ 14-12-2012 12:51    +
+ 		+ + + + +
+ I'm confused, I sent a response to both mails, both times with the same answer,
+which was in essence this:
+
+I think that all provided options are totally unnecessary and this problem can easily be solved by amending the XSD to TTCN-3 mapping. This mapping needs to be changed in such a way that the generated variant attributes for an inner element include all inherited variant attributes that shall not be overwritten.
+
+Since the mapping process is done automatically by some generator which needs to keep track of this information anyway, this should not be a problem. It will also make implementation of generic XSD-codecs simpler as they don't have to follow some additional rules for the append-cases.
+
+Introducing new rules for different language mappings is considered harmful by Testing Technologies as then every language mapping potentially could have a totally different approach to variant attribute overwriting and it is unclear how this can remain compositional, e.g. when types from one language are imported into TTCN-3 and amended with variant attributes. Shall the importers rules be followed or the imported rules? This can at least lead to a lot of confusion by the users and thus to lots of errors and frustration and lesser acceptance of TTCN-3.
+
+
+
+ + + + + + + + + + +
+ (0011307) +
+ Gyorgy Rethy    +
+ 21-12-2012 10:53    +
+ 		+ + + + +
+ See my proposal for part-1 in CR6233_resolution_P1_v1.doc.
+
+
+
+ + + + + + + + + + +
+ (0011310) +
+ Ina Schieferdecker    +
+ 21-12-2012 11:59    +
+ 		+ + + + +
+ Implemented with small editorial given in v2
+
+ + diff --git a/docs/mantis/CR6237.md b/docs/mantis/CR6237.md new file mode 100644 index 0000000000000000000000000000000000000000..9b7a92fc407b7d62c96040dcd27167339e95cf6f --- /dev/null +++ b/docs/mantis/CR6237.md @@ -0,0 +1,114 @@ + + + + + + + + + + + + + 0006237: Expressions in constant declarations - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006237Part 01: TTCN-3 Core LanguageEditorialpublic01-08-2012 09:2308-08-2012 09:38
ReporterTomas Urban 
Assigned ToTomas Urban 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionwon't fix 
PlatformOSOS Version
Product Versionv4.4.1 (published 2012-04) 
Target Versionv4.5.1 (published 2013-04)Fixed in Version 
Clause Reference(s)10
Source (company - Author)Elvior
Summary0006237: Expressions in constant declarations
DescriptionThe syntactical structure for constant declaration in chapter 10 and rule 78 in the BNF refer to "ConstantExpression". ConstantExpression is defined in the BNF rule 496, but is in fact syntactically equal to the rule 489 (Expression). The BNF doesn't contain any other semantic restrictions on "ConstantExpression" that would make it different from a common expression. Since the general tendency in the last revisions of the standard was removal of syntactically identical rules, I propose to remove the rule 496 and 506 and replace all references to ConstantExpression with a reference to Expression.
+
+I would also appreciate if the chapter 10 contained an example of a constant initialized with a runtime-resolved expression (e.g. const float MyConst3 := rnd();) to demonstrate the runtime character of constants in TTCN-3, because this is quite unusual behaviour comparing to commonly used programming languages (C++, C#).
+
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR6237_resolution_v1.doc (74,752) 07-08-2012 17:38
http://oldforge.etsi.org/mantis/file_download.php?file_id=2708&type=bug
Issue History
Date ModifiedUsernameFieldChange
01-08-2012 09:23Tomas UrbanNew Issue
01-08-2012 09:23Tomas UrbanClause Reference(s) => 10
01-08-2012 09:23Tomas UrbanSource (company - Author) => Elvior
06-08-2012 13:05Tomas UrbanNote Added: 0010975
07-08-2012 16:57Gyorgy RethyStatusnew => assigned
07-08-2012 16:57Gyorgy RethyAssigned To => Gyorgy Rethy
07-08-2012 17:36Gyorgy RethyNote Added: 0010986
07-08-2012 17:38Gyorgy RethyFile Added: CR6237_resolution_v1.doc
07-08-2012 17:39Gyorgy RethyNote Edited: 0010986
07-08-2012 17:39Gyorgy RethyAssigned ToGyorgy Rethy => Tomas Urban
08-08-2012 09:38Gyorgy RethyStatusassigned => closed
08-08-2012 09:38Gyorgy RethyResolutionopen => won't fix
08-08-2012 09:38Gyorgy RethyTarget Version => Edition 4.5.1
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010975) +
+ Tomas Urban    +
+ 06-08-2012 13:05    +
+ 		+ + + + +
+ I am sorry for misleading second part of the message. I got this issue from one of our developers and forgot to verify all the facts. In fact, C++ constants are runtime constants and C# constant approach is quite unique, since it supports two types of constants (compile-time resolved const and runtime resolved readonly).
+
+
+
+ + + + + + + + + + +
+ (0010986) +
+ Gyorgy Rethy    +
+ 07-08-2012 17:36    +
(edited on: 07-08-2012 17:39)
+ 		+ + + + +
+ Regarding the BNF question: in fact constant and variable definitions differ in one case, in constants no "unchanged" (dash) can be used for a field or element, in variables it can be used:
+502. ArrayElementExpressionList ::= NotUsedOrExpression {"," NotUsedOrExpression}
+503. NotUsedOrExpression ::= Expression | Minus
+
+510. ArrayElementConstExpressionList ::= ConstantExpression {"," ConstantExpression}
+
+So, I propose not to chanhe the BNF.
+
+Regarding the example:
+I have added one, see the file CR6237_resolution_v1.doc.
+
+Pls. check if this is OK with you.
+
+
+
+ + diff --git a/docs/mantis/CR6238.md b/docs/mantis/CR6238.md new file mode 100644 index 0000000000000000000000000000000000000000..a2aab054e63bb9749c5d8728d2e113565d8aff15 --- /dev/null +++ b/docs/mantis/CR6238.md @@ -0,0 +1,202 @@ + + + + + + + + + + + + + 0006238: Interleave example - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006238Part 01: TTCN-3 Core LanguageEditorialpublic01-08-2012 09:4110-08-2012 09:52
ReporterTomas Urban 
Assigned ToIna Schieferdecker 
PrioritynormalSeveritytextReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.4.1 (published 2012-04) 
Target Versionv4.5.1 (published 2013-04)Fixed in Versionv4.5.1 (published 2013-04) 
Clause Reference(s)20.4
Source (company - Author)Elvior
Summary0006238: Interleave example
DescriptionTwo sections of the interleave example are not correctly transformed:
+
+1.
+[] PCO1.receive(MySig3) {
+ PCO2.receive(MySig4);
+ PCO2.send(MySig5);
+ PCO2.send(MySig6);
+ PCO2.receive(MySig7)
+}
+
+shall be
+[] PCO1.receive(MySig3)
+{
+ alt {
+  []PCO2.receive(MySig4) {
+   PCO2.send(MySig5);
+   PCO2.send(MySig6);
+   PCO2.receive(MySig7)
+  }
+}
+
+2.
+[] PCO2.receive(MySig7) {
+ PCO1.receive(MySig1);
+ PCO1.send(MySig2);
+ PCO1.receive(MySig3);
+}
+
+shall be
+[] PCO2.receive(MySig7) {
+ alt {
+  [] PCO1.receive(MySig1) {
+   PCO1.send(MySig2);
+   PCO1.receive(MySig3);
+  }
+}
+
+Both version are identical in case of nominal test case execution, but they produce different results if a default is activated when executing PCO2.receive(MySig4) or PCO2.receive(MySig1).
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR6238-JG-120809.doc (71,168) 09-08-2012 10:24
http://oldforge.etsi.org/mantis/file_download.php?file_id=2710&type=bug
Issue History
Date ModifiedUsernameFieldChange
01-08-2012 09:41Tomas UrbanNew Issue
01-08-2012 09:41Tomas UrbanClause Reference(s) => 20.4
01-08-2012 09:41Tomas UrbanSource (company - Author) => Elvior
07-08-2012 17:40Gyorgy RethyStatusnew => assigned
07-08-2012 17:40Gyorgy RethyAssigned To => Gyorgy Rethy
07-08-2012 17:56Gyorgy RethyNote Added: 0010987
07-08-2012 17:58Gyorgy RethyAssigned ToGyorgy Rethy => Tomas Urban
08-08-2012 09:44Gyorgy RethyAssigned ToTomas Urban => Jens Grabowski
09-08-2012 10:24Jens GrabowskiFile Added: CR6238-JG-120809.doc
09-08-2012 10:25Jens GrabowskiNote Added: 0010998
09-08-2012 10:27Jens GrabowskiAssigned ToJens Grabowski => Ina Schieferdecker
10-08-2012 09:52Ina SchieferdeckerNote Added: 0011018
10-08-2012 09:52Ina SchieferdeckerStatusassigned => closed
10-08-2012 09:52Ina SchieferdeckerResolutionopen => fixed
10-08-2012 09:52Ina SchieferdeckerFixed in Version => Edition 4.5.1
10-08-2012 09:52Ina SchieferdeckerTarget Version => Edition 4.5.1
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010987) +
+ Gyorgy Rethy    +
+ 07-08-2012 17:56    +
+ 		+ + + + +
+ Let look at the first case:
+1.
+alt {
+[] PCO1.receive(MySig3) {
+   PCO2.receive(MySig4);
+   PCO2.send(MySig5);
+   PCO2.send(MySig6);
+   PCO2.receive(MySig7)
+}
+
+as a standalone receive is a shorthand for an alt with a single receiveing branch, the above is the same as:
+alt {
+[] PCO1.receive(MySig3) {
+   alt { [] PCO2.receive(MySig4){} };
+   PCO2.send(MySig5);
+   PCO2.send(MySig6);
+   alt { [] PCO2.receive(MySig7){} }
+}
+
+your proposal is:
+alt {
+[] PCO1.receive(MySig3)
+{
+ alt {
+  []PCO2.receive(MySig4) {
+   PCO2.send(MySig5);
+   PCO2.send(MySig6);
+   PCO2.receive(MySig7)\
+     //this receive can also be extended to an alt with a single branch
+  }
+}
+
+
+i.e. all activated defaults in both cases will be invoked for both the PCO2.receive(MySig4) and the PCO2.receive(MySig7) statements (separately, of course). Thus, I cannot see how the behaviours of the current example and the proposed changed example differ.
+
+
+
+ + + + + + + + + + +
+ (0010998) +
+ Jens Grabowski    +
+ 09-08-2012 10:25    +
+ 		+ + + + +
+ After STF discussion implemented as proposed by reporter. Resolution is in the attached file. Assigned to Ina for implementation.
+
+
+
+ + + + + + + + + + +
+ (0011018) +
+ Ina Schieferdecker    +
+ 10-08-2012 09:52    +
+ 		+ + + + +
+ as proposed
+
+ + diff --git a/docs/mantis/CR6239.md b/docs/mantis/CR6239.md new file mode 100644 index 0000000000000000000000000000000000000000..de6d417dcb3f5c07efc7c2cc4a6fcaeab65aad9d --- /dev/null +++ b/docs/mantis/CR6239.md @@ -0,0 +1,732 @@ + + + + + + + + + + + + + 0006239: Restriction on verdict operation - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006239Part 01: TTCN-3 Core LanguageTechnicalpublic01-08-2012 09:5605-01-2015 18:25
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.4.1 (published 2012-04) 
Target Versionv4.7.1 (published 2015-06)Fixed in Versionv4.7.1 (published 2015-06) 
Clause Reference(s)24
Source (company - Author)Elvior
Summary0006239: Restriction on verdict operation
DescriptionBoth verdict operations (setverdict, getverdict) should contain similar restriction as the testcase.stop operation regarding invocation from the module control part:
+
+The setverdict/getverdict operation shall not be used in the module control part or functions invoked directly or indirectly by the module control part.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Fileshtm Another TTCN-3 language question from ETSI STF446.htm (14,825) 11-12-2012 14:04
http://oldforge.etsi.org/mantis/file_download.php?file_id=2764&type=bug
doc CR6239-Resolution-JG-130828.doc (851,968) 28-08-2013 10:50
http://oldforge.etsi.org/mantis/file_download.php?file_id=2866&type=bug
doc CR6239-Resolution-JG-130828-V2.doc (851,968) 28-08-2013 15:57
http://oldforge.etsi.org/mantis/file_download.php?file_id=2872&type=bug
doc CR6239-Resolution-JW.doc (853,504) 07-10-2013 13:14
http://oldforge.etsi.org/mantis/file_download.php?file_id=2889&type=bug
doc CR6239-Resolution-JW-IS.doc (854,016) 11-10-2013 16:22
http://oldforge.etsi.org/mantis/file_download.php?file_id=2933&type=bug
doc CR6239-Resolution-v5.doc (845,824) 07-10-2014 11:06
http://oldforge.etsi.org/mantis/file_download.php?file_id=3093&type=bug
Issue History
Date ModifiedUsernameFieldChange
01-08-2012 09:56Tomas UrbanNew Issue
01-08-2012 09:56Tomas UrbanClause Reference(s) => 24
01-08-2012 09:56Tomas UrbanSource (company - Author) => Elvior
07-08-2012 19:01Gyorgy RethyStatusnew => assigned
07-08-2012 19:01Gyorgy RethyAssigned To => Gyorgy Rethy
07-08-2012 19:17Gyorgy RethyNote Added: 0010989
07-08-2012 19:18Gyorgy RethyAssigned ToGyorgy Rethy => Tomas Urban
08-08-2012 10:38Gyorgy RethyNote Added: 0010994
08-08-2012 10:39Gyorgy RethyNote Edited: 0010994
08-08-2012 10:39Gyorgy RethyAssigned ToTomas Urban => Gyorgy Rethy
10-12-2012 16:57Gyorgy RethyTarget Version => Edition 4.5.1
11-12-2012 13:57Gyorgy RethyNote Added: 0011222
11-12-2012 14:00Gyorgy RethyNote Edited: 0011222
11-12-2012 14:04Gyorgy RethyFile Added: Another TTCN-3 language question from ETSI STF446.htm
13-12-2012 14:14Gyorgy RethyNote Added: 0011254
13-12-2012 14:55Gyorgy RethyAssigned ToGyorgy Rethy => Jens Grabowski
14-05-2013 15:21Gyorgy RethyTarget VersionEdition 4.5.1 => v4.7.1 (published 2015-06)
12-07-2013 10:53Jens GrabowskiNote Added: 0011571
27-08-2013 11:09Jens GrabowskiNote Added: 0011608
28-08-2013 10:49Jens GrabowskiNote Added: 0011619
28-08-2013 10:50Jens GrabowskiFile Added: CR6239-Resolution-JG-130828.doc
28-08-2013 10:51Jens GrabowskiNote Added: 0011620
28-08-2013 10:51Jens GrabowskiAssigned ToJens Grabowski => Jacob Wieland - Spirent
28-08-2013 11:23Jacob Wieland - SpirentNote Added: 0011622
28-08-2013 11:23Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Jens Grabowski
28-08-2013 11:23Jacob Wieland - SpirentStatusassigned => confirmed
28-08-2013 15:57Jens GrabowskiFile Added: CR6239-Resolution-JG-130828-V2.doc
28-08-2013 15:58Jens GrabowskiNote Added: 0011629
28-08-2013 15:59Jens GrabowskiStatusconfirmed => assigned
28-08-2013 15:59Jens GrabowskiAssigned ToJens Grabowski => Gyorgy Rethy
30-08-2013 09:44Gyorgy RethyStatusassigned => confirmed
30-08-2013 10:08Gyorgy RethyNote Added: 0011650
30-08-2013 10:08Gyorgy RethyAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
30-08-2013 10:08Gyorgy RethyStatusconfirmed => assigned
07-10-2013 13:14Jacob Wieland - SpirentFile Added: CR6239-Resolution-JW.doc
07-10-2013 13:17Jacob Wieland - SpirentNote Added: 0011684
07-10-2013 13:17Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
07-10-2013 13:17Jacob Wieland - SpirentStatusassigned => confirmed
07-10-2013 16:21Gyorgy RethyNote Added: 0011691
07-10-2013 16:21Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
07-10-2013 16:21Gyorgy RethyStatusconfirmed => resolved
07-10-2013 16:21Gyorgy RethyResolutionopen => fixed
11-10-2013 16:21Ina SchieferdeckerNote Added: 0011790
11-10-2013 16:22Ina SchieferdeckerFile Added: CR6239-Resolution-JW-IS.doc
11-10-2013 16:22Ina SchieferdeckerStatusresolved => assigned
11-10-2013 16:22Ina SchieferdeckerAssigned ToIna Schieferdecker => Gyorgy Rethy
29-11-2013 14:15Jacob Wieland - SpirentNote Added: 0011880
08-04-2014 16:50Gyorgy RethyTarget Versionv4.6.1 (published 2014-06) => v4.7.1 (published 2015-06)
19-06-2014 17:22Gyorgy RethyCategoryEditorial => Technical
06-10-2014 14:13Gyorgy RethyNote Added: 0012231
06-10-2014 14:13Gyorgy RethyAssigned ToGyorgy Rethy => Tomas Urban
07-10-2014 11:06Tomas UrbanFile Added: CR6239-Resolution-v5.doc
07-10-2014 11:10Tomas UrbanNote Added: 0012250
07-10-2014 11:10Tomas UrbanStatusassigned => resolved
07-10-2014 11:10Tomas UrbanAssigned ToTomas Urban => Jens Grabowski
07-10-2014 11:11Tomas UrbanStatusresolved => feedback
07-10-2014 11:11Tomas UrbanResolutionfixed => reopened
07-10-2014 11:11Tomas UrbanStatusfeedback => confirmed
07-10-2014 11:11Tomas UrbanResolutionreopened => open
07-10-2014 14:47Jens GrabowskiNote Added: 0012255
07-10-2014 14:47Jens GrabowskiAssigned ToJens Grabowski => Gyorgy Rethy
07-10-2014 14:47Jens GrabowskiStatusconfirmed => assigned
07-10-2014 14:47Jens GrabowskiStatusassigned => resolved
07-10-2014 14:47Jens GrabowskiResolutionopen => fixed
05-01-2015 18:25Gyorgy RethyNote Added: 0012628
05-01-2015 18:25Gyorgy RethyStatusresolved => closed
05-01-2015 18:25Gyorgy RethyFixed in Version => v4.7.1 (published 2015-06)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010989) +
+ Gyorgy Rethy    +
+ 07-08-2012 19:17    +
+ 		+ + + + +
+ In general, table 16 specifies which operation can be used where. In addition, table 31 defines what can be used in the control part.
+
+I rather propose to remove the restriction from the text of clause 21.2.1 and other similar places in the standard ( 1st paragraph of clauses 19, 19.7, 1st paragraph of the semantic description of clause 19.8), where we are mentioning what can be used in the control part.
+
+
+
+ + + + + + + + + + +
+ (0010994) +
+ Gyorgy Rethy    +
+ 08-08-2012 10:38    +
(edited on: 08-08-2012 10:39)
+ 		+ + + + +
+ STF discussion 2012-08-08: it is not clearly defined in the standard what "use" means: the given operation shall not occur at a given place in the code or it shall not be executed runtime. Users (tool vendors) and 3GPP shall be asked. Invoking functions from control, specific places (guards, etc.) are affected.
+
+
+
+
+
+ + + + + + + + + + +
+ (0011222) +
+ Gyorgy Rethy    +
+ 11-12-2012 13:57    +
(edited on: 11-12-2012 14:00)
+ 		+ + + + +
+ E-mail has been sent to TTCN-3 tool vendors on 10-Aug and re-sent on 11-Dec. Response received from STF 160 only.
+
+
+
+
+
+ + + + + + + + + + +
+ (0011254) +
+ Gyorgy Rethy    +
+ 13-12-2012 14:14    +
+ 		+ + + + +
+ STF discussion 2012-12-13: the runtime usaga of testcase.stop shall be forbidden *option (2) from the mail sent to vendors. To do:
+- add a definition of the term "use" to the definitions section
+- if that is agreed, check all places where "use" is used and change if needed. it is agreed earlier today, that constants and non-parameterized global templates shall be initialized just once, at declaration.
+
+
+
+ + + + + + + + + + +
+ (0011571) +
+ Jens Grabowski    +
+ 12-07-2013 10:53    +
+ 		+ + + + +
+ A restriction similar to "The test case stop operation shall not be used in the module control part or functions invoked directly or
+indirectly by the module control part." only appears in the restrictions paragraph of "testcase.stop".
+
+According to György's proposal, this restriction should be deleted from 21.2.1.
+
+
+
+ + + + + + + + + + +
+ (0011608) +
+ Jens Grabowski    +
+ 27-08-2013 11:09    +
+ 		+ + + + +
+ It is not possible to provide a unique and unambiguous definition of the term "use" in the TTCN-3 standard.
+
+Only Part I includes round about appearences of "use" or "used".
+
+The term "use" in combination with a TTCN-3 statement is mainly used (I cannot even here avoid this word) in the following manners:
+
+(1) "use" refers to specification, e.g., TTCN-3 statement X "can be used in test cases, functions, ...."
+
+(2) "use" refers to execution, e.g., "Configuration operations are used to set up and control test components."
+
+(3) "use" may be replaced by "applied to", e.g., "The stop operation is used to stop a running timer."
+
+(4) the general term "use" refers to a mixture of (1), (2) and (3).
+
+My conclusion is that we should not provide a definition for the term "use", but always provide clarifications whenever an ambiguity is detected. Ambiguities should be reported as CRs as ususal.
+
+
+
+ + + + + + + + + + +
+ (0011619) +
+ Jens Grabowski    +
+ 28-08-2013 10:49    +
+ 		+ + + + +
+ CR implemented as discussed by the STF on 27.08.2013.
+
+- Column headings of table 15 have been changed to highlight an "execution" use instead of a "specification" use. E.g., testcase.stop may occur in a function which is indirectly called by module control. The occurence itself shall not automatically cause an error.
+
+- In all restriction paragraphs of statements/operations mentioned in table 15, a reference to table 15 has been added.
+
+- no definition of the term "use" is provided (see my Note from 27.8.2013)
+
+
+
+ + + + + + + + + + +
+ (0011620) +
+ Jens Grabowski    +
+ 28-08-2013 10:51    +
+ 		+ + + + +
+ Assigned for proofchecking to Jacob.
+
+
+
+ + + + + + + + + + +
+ (0011622) +
+ Jacob Wieland - Spirent    +
+ 28-08-2013 11:23    +
+ 		+ + + + +
+ The third column should rather be headed by:
+
+Can be called in a testing context by functions called from templates, boolean guards, alternative event parts and initialization of altstep local definitions.
+
+I.e., the events-parts are missing.
+
+Shouldn't we also make the disjointness of the columns more explicit?
+
+
+
+ + + + + + + + + + +
+ (0011629) +
+ Jens Grabowski    +
+ 28-08-2013 15:58    +
+ 		+ + + + +
+ Table column heading changed according to Jacob's suggestion. Assigned to György for final proofchecking.
+
+
+
+ + + + + + + + + + +
+ (0011650) +
+ Gyorgy Rethy    +
+ 30-08-2013 10:08    +
+ 		+ + + + +
+ In general OK with me but two comments:
+- I don't understand what "alternative event parts" means :-/? No such term is defined or used in the standard. If the content of the bracket following a receiving statement is meant here, this is called "Matching part" in clause 22.1.4.2. But in this case a clause reference should be given in a note.
+- In table 15, NOTE-s should be just numbered list items like:
+(1) ....
+(2) ....
+
+
+
+ + + + + + + + + + +
+ (0011684) +
+ Jacob Wieland - Spirent    +
+ 07-10-2013 13:17    +
+ 		+ + + + +
+ changed
+
+alternative event part
+
+to
+
+receive part of receive operation, timeout, done or killed operation
+
+which summarizes all existing event possibilities (receive part is also described in the receive operations overview)
+
+
+
+ + + + + + + + + + +
+ (0011691) +
+ Gyorgy Rethy    +
+ 07-10-2013 16:21    +
+ 		+ + + + +
+ Fine with me. Tomas, if possible, pls. check it as well.
+
+
+
+ + + + + + + + + + +
+ (0011790) +
+ Ina Schieferdecker    +
+ 11-10-2013 16:21    +
+ 		+ + + + +
+ The proposed rewording of the columns of table 15 is confusing as testing context is nowhere else defined and used in second last and last column with different meanings.
+
+Hence, another proposal is attached.
+
+The other changes are fine for me.
+
+
+
+ + + + + + + + + + +
+ (0011880) +
+ Jacob Wieland - Spirent    +
+ 29-11-2013 14:15    +
+ 		+ + + + +
+ the meanings of testing context in the columns was exactly the same: directly or indirectly invoked from a testcase
+
+
+
+ + + + + + + + + + +
+ (0012231) +
+ Gyorgy Rethy    +
+ 06-10-2014 14:13    +
+ 		+ + + + +
+ Pls. final check if the wording in the table headers are OK or need some adjustment.
+
+
+
+ + + + + + + + + + +
+ (0012250) +
+ Tomas Urban    +
+ 07-10-2014 11:10    +
+ 		+ + + + +
+ After a discussion, I changed the header of the last column in the table 15 to "Can be directly or indirectly invoked from specific places". This is much shorter than the previous description and the term is well described in the clause 16.1.4. The rest of the proposal is fine by me.
+
+Jens, could you please check if the change is acceptable and in case it is mark the CR as resolved?
+
+
+
+ + + + + + + + + + +
+ (0012255) +
+ Jens Grabowski    +
+ 07-10-2014 14:47    +
+ 		+ + + + +
+ Resolution is also fine with me.
+
+
+
+ + + + + + + + + + +
+ (0012628) +
+ Gyorgy Rethy    +
+ 05-01-2015 18:25    +
+ 		+ + + + +
+ Added to draft V4.6.3
+
+ + diff --git a/docs/mantis/CR6240.md b/docs/mantis/CR6240.md new file mode 100644 index 0000000000000000000000000000000000000000..f140bf3bafa25a7cae82cee604b2933041b35115 --- /dev/null +++ b/docs/mantis/CR6240.md @@ -0,0 +1,133 @@ + + + + + + + + + + + + + 0006240: Table 16: missing operations - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006240Part 01: TTCN-3 Core LanguageEditorialpublic01-08-2012 09:5910-08-2012 10:31
ReporterTomas Urban 
Assigned ToIna Schieferdecker 
PrioritynormalSeveritytextReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.4.1 (published 2012-04) 
Target Versionv4.5.1 (published 2013-04)Fixed in Versionv4.5.1 (published 2013-04) 
Clause Reference(s)18
Source (company - Author)Elvior
Summary0006240: Table 16: missing operations
DescriptionSome recently added operations (e.g. checkstate, testcase.stop) are missing from the table 16.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR6240_resolution_v1.doc (548,864) 07-08-2012 18:59
http://oldforge.etsi.org/mantis/file_download.php?file_id=2709&type=bug
doc CR6240_resolution_v2.doc (444,928) 10-08-2012 10:30
http://oldforge.etsi.org/mantis/file_download.php?file_id=2715&type=bug
Issue History
Date ModifiedUsernameFieldChange
01-08-2012 09:59Tomas UrbanNew Issue
01-08-2012 09:59Tomas UrbanClause Reference(s) => 18
01-08-2012 09:59Tomas UrbanSource (company - Author) => Elvior
07-08-2012 18:58Gyorgy RethyNote Added: 0010988
07-08-2012 18:59Gyorgy RethyFile Added: CR6240_resolution_v1.doc
07-08-2012 18:59Gyorgy RethyStatusnew => assigned
07-08-2012 18:59Gyorgy RethyAssigned To => Gyorgy Rethy
07-08-2012 19:00Gyorgy RethyAssigned ToGyorgy Rethy => Tomas Urban
07-08-2012 19:00Gyorgy RethyNote Edited: 0010988
08-08-2012 10:41Gyorgy RethyAssigned ToTomas Urban => Jens Grabowski
09-08-2012 10:46Jens GrabowskiNote Added: 0010999
09-08-2012 10:46Jens GrabowskiAssigned ToJens Grabowski => Ina Schieferdecker
10-08-2012 10:30Ina SchieferdeckerFile Added: CR6240_resolution_v2.doc
10-08-2012 10:31Ina SchieferdeckerNote Added: 0011019
10-08-2012 10:31Ina SchieferdeckerStatusassigned => closed
10-08-2012 10:31Ina SchieferdeckerResolutionopen => fixed
10-08-2012 10:31Ina SchieferdeckerFixed in Version => Edition 4.5.1
10-08-2012 10:31Ina SchieferdeckerTarget Version => Edition 4.5.1
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010988) +
+ Gyorgy Rethy    +
+ 07-08-2012 18:58    +
(edited on: 07-08-2012 19:00)
+ 		+ + + + +
+ I have found that checkstate is also missing in tables 22 and 25. I have checked all other clauses but haven't found any other operation missing in table 16 than the above mentioned checkstate & testcase.stop. Resolution proposed in CR6240_resolution_v1.doc, pls. check.
+
+
+
+
+
+ + + + + + + + + + +
+ (0010999) +
+ Jens Grabowski    +
+ 09-08-2012 10:46    +
+ 		+ + + + +
+ Resolution is OK. Assigned to Ina for Implementation.
+
+
+
+ + + + + + + + + + +
+ (0011019) +
+ Ina Schieferdecker    +
+ 10-08-2012 10:31    +
+ 		+ + + + +
+ as proposed with editorial changes only
+
+ + diff --git a/docs/mantis/CR6241.md b/docs/mantis/CR6241.md new file mode 100644 index 0000000000000000000000000000000000000000..67906e54be35a9c01b1f59b4d78bc008e77ef003 --- /dev/null +++ b/docs/mantis/CR6241.md @@ -0,0 +1,69 @@ + + + + + + + + + + + + + 0006241: FieldSpec rule in the BNF - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006241Part 01: TTCN-3 Core LanguageEditorialpublic01-08-2012 10:1610-08-2012 11:28
ReporterTomas Urban 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.5.1 (published 2013-04)Fixed in Versionv4.5.1 (published 2013-04) 
Clause Reference(s)A.1.6.1.3
Source (company - Author)Elvior
Summary0006241: FieldSpec rule in the BNF
DescriptionThe BNF rule 95 (FieldSpec) currently doesn't contain an option for leaving fields explicitely unspecified (described in the chapter 6.2). Therefore I propose to change the rule from:
+
+95.FieldSpec ::= FieldReference AssignmentChar TemplateBody
+
+to
+
+95.FieldSpec ::= FieldReference AssignmentChar (TemplateBody | Minus)
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
01-08-2012 10:16Tomas UrbanNew Issue
01-08-2012 10:16Tomas UrbanClause Reference(s) => A.1.6.1.3
01-08-2012 10:16Tomas UrbanSource (company - Author) => Elvior
08-08-2012 10:42Gyorgy RethyStatusnew => assigned
08-08-2012 10:42Gyorgy RethyAssigned To => Ina Schieferdecker
10-08-2012 11:28Ina SchieferdeckerNote Added: 0011022
10-08-2012 11:28Ina SchieferdeckerStatusassigned => closed
10-08-2012 11:28Ina SchieferdeckerResolutionopen => fixed
10-08-2012 11:28Ina SchieferdeckerFixed in Version => Edition 4.5.1
10-08-2012 11:28Ina SchieferdeckerTarget Version => Edition 4.5.1
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011022) +
+ Ina Schieferdecker    +
+ 10-08-2012 11:28    +
+ 		+ + + + +
+ as proposed
+
+ + diff --git a/docs/mantis/CR6242.md b/docs/mantis/CR6242.md new file mode 100644 index 0000000000000000000000000000000000000000..d7ee708fd6db91fdc3d45731e6ce859e4763e6c1 --- /dev/null +++ b/docs/mantis/CR6242.md @@ -0,0 +1,177 @@ + + + + + + + + + + + + + 0006242: Example on assignment notation would be helpful - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006242Part 01: TTCN-3 Core LanguageClarificationpublic01-08-2012 10:3821-12-2012 11:54
ReporterGyorgy Rethy 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.4.1 (published 2012-04) 
Target Versionv4.5.1 (published 2013-04)Fixed in Versionv4.5.1 (published 2013-04) 
Clause Reference(s)6.2.3
Source (company - Author)L.M.Ericsson
Summary0006242: Example on assignment notation would be helpful
DescriptionThe result of the following example is not always clear to the users:
+var record_of_integer ix := { 0,1,2 }
+ix := { [3] := 2*ix[2]+1 }
+log(ix);// assignment notation with one element changed: { 0, 1, 2, 5 }
+
+The result is often mixed up with the following case:
+var record_of_integer ix := { 0,1,2 }
+ix[3] := 2*ix[2]+1
+log(ix); // the same in index noation { 0, 1, 2, 5 }
+
+A detailed, complate and precise description is missing for the 3 value notation forms both all structured types (incl. record, set, recof, setof, union)
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR6242_resolution_v2.doc (215,040) 14-12-2012 14:52
http://oldforge.etsi.org/mantis/file_download.php?file_id=2787&type=bug
doc CR6242_resolution_v3.doc (175,104) 20-12-2012 12:05
http://oldforge.etsi.org/mantis/file_download.php?file_id=2790&type=bug
doc CR6242_resolution_v4.doc (175,616) 21-12-2012 11:52
http://oldforge.etsi.org/mantis/file_download.php?file_id=2796&type=bug
Issue History
Date ModifiedUsernameFieldChange
01-08-2012 10:38Gyorgy RethyNew Issue
01-08-2012 10:38Gyorgy RethyClause Reference(s) => 6.2.3
01-08-2012 10:38Gyorgy RethySource (company - Author) => L.M.Ericsson
01-08-2012 13:31Gyorgy RethyDescription Updated
06-08-2012 08:56Gyorgy RethyDescription Updated
06-08-2012 08:57Gyorgy RethyFile Added: CR6242_resolution_v1.doc
08-08-2012 10:55Gyorgy RethyStatusnew => assigned
08-08-2012 10:55Gyorgy RethyAssigned To => Jens Grabowski
08-08-2012 11:16Gyorgy RethyAssigned ToJens Grabowski => Gyorgy Rethy
08-08-2012 11:23Gyorgy RethyNote Added: 0010995
15-08-2012 16:12Gyorgy RethyNote Added: 0011042
10-12-2012 16:56Gyorgy RethyTarget Version => Edition 4.5.1
13-12-2012 08:16Gyorgy RethyNote View State: 11042: private
13-12-2012 08:17Gyorgy RethyNote View State: 11042: public
13-12-2012 08:18Gyorgy RethyNote View State: 11042: private
13-12-2012 08:18Gyorgy RethyNote View State: 11042: public
13-12-2012 08:25Gyorgy RethyNote Edited: 0011042
13-12-2012 08:32Gyorgy RethyNote Edited: 0011042
13-12-2012 08:33Gyorgy RethyFile Added: RE modified templates modification of a list.txt.txt
14-12-2012 14:46Gyorgy RethyFile Deleted: CR6242_resolution_v1.doc
14-12-2012 14:47Gyorgy RethyNote Deleted: 0011042
14-12-2012 14:47Gyorgy RethyFile Deleted: RE modified templates modification of a list.txt.txt
14-12-2012 14:51Gyorgy RethyNote Added: 0011283
14-12-2012 14:51Gyorgy RethyDescription Updated
14-12-2012 14:52Gyorgy RethyFile Added: CR6242_resolution_v2.doc
14-12-2012 14:52Gyorgy RethyNote Edited: 0011283
14-12-2012 14:53Gyorgy RethyAssigned ToGyorgy Rethy => Jens Grabowski
20-12-2012 12:05Jens GrabowskiFile Added: CR6242_resolution_v3.doc
20-12-2012 12:05Jens GrabowskiNote Added: 0011297
20-12-2012 12:06Jens GrabowskiAssigned ToJens Grabowski => Ina Schieferdecker
21-12-2012 11:52Ina SchieferdeckerFile Added: CR6242_resolution_v4.doc
21-12-2012 11:53Ina SchieferdeckerNote Added: 0011309
21-12-2012 11:53Ina SchieferdeckerStatusassigned => resolved
21-12-2012 11:53Ina SchieferdeckerResolutionopen => fixed
21-12-2012 11:53Ina SchieferdeckerFixed in Version => Edition 4.5.1
21-12-2012 11:54Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010995) +
+ Gyorgy Rethy    +
+ 08-08-2012 11:23    +
+ 		+ + + + +
+ STF discussion 2012-08-08: Just an example is not sufficient, the text should be explicit about the case raised by the CR. Also add text for records and sets.
+
+
+
+ + + + + + + + + + +
+ (0011283) +
+ Gyorgy Rethy    +
+ 14-12-2012 14:51    +
(edited on: 14-12-2012 14:52)
+ 		+ + + + +
+ see proposed solution in CR6242_resolution_v2.doc. This version is for review.
+
+
+
+
+
+ + + + + + + + + + +
+ (0011297) +
+ Jens Grabowski    +
+ 20-12-2012 12:05    +
+ 		+ + + + +
+ Resolution ok for me, I only made minor changes w.r.t. numbering of Examples. Assigned to Ina for implementation.
+
+
+
+ + + + + + + + + + +
+ (0011309) +
+ Ina Schieferdecker    +
+ 21-12-2012 11:53    +
+ 		+ + + + +
+ Implemented as in v4 with small editorials
+
+ + diff --git a/docs/mantis/CR6247.md b/docs/mantis/CR6247.md new file mode 100644 index 0000000000000000000000000000000000000000..c173ac35fd15e4fdddea2df139ed77a07cfe7e49 --- /dev/null +++ b/docs/mantis/CR6247.md @@ -0,0 +1,155 @@ + + + + + + + + + + + + + 0006247: Extended Field Reference can also refer to types - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006247Part 01: TTCN-3 Core LanguageTechnicalpublic06-08-2012 17:3309-08-2012 18:24
ReporterIna Schieferdecker 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.5.1 (published 2013-04)Fixed in Versionv4.5.1 (published 2013-04) 
Clause Reference(s)Annex A
Source (company - Author)Friedrich Wilhelm Schröer, Fraunhofer FOKUS
Summary0006247: Extended Field Reference can also refer to types
DescriptionSince selectors for anytype-alternatives can be type identifiers, but since type identifiers of predefined types are not identifiers but keywords
+
+527.ExtendedFieldReference ::=
+   {
+   (Dot Identifier) |
+   ArrayOrBitRef |
+   ("[" Minus "]")
+   }+
+
+needs to be
+
+527.ExtendedFieldReference ::=
+   {
+   (Dot (Identifier | PredefinedType)) |
+   ArrayOrBitRef |
+   ("[" Minus "]")
+   }+
+
Steps To Reproduce
Additional InformationI agree with the proposal. The rule 527. in A.1.6.8.3 shall be changed as proposed to:
+
+527.ExtendedFieldReference ::=
+   {
+   (Dot (Identifier | PredefinedType)) |
+   ArrayOrBitRef |
+   ("[" Minus "]")
+   }+
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
06-08-2012 17:33Ina SchieferdeckerNew Issue
06-08-2012 17:33Ina SchieferdeckerStatusnew => assigned
06-08-2012 17:33Ina SchieferdeckerAssigned To => Tomas Urban
06-08-2012 17:33Ina SchieferdeckerClause Reference(s) => Annex A
06-08-2012 17:33Ina SchieferdeckerSource (company - Author) => Friedrich Wilhelm Schröer, Fraunhofer FOKUS
06-08-2012 17:34Ina SchieferdeckerNote Added: 0010979
08-08-2012 09:05Tomas UrbanStatusassigned => closed
08-08-2012 09:05Tomas UrbanResolutionopen => fixed
08-08-2012 09:05Tomas UrbanAdditional Information Updated
09-08-2012 17:32Tomas UrbanStatusclosed => feedback
09-08-2012 17:32Tomas UrbanResolutionfixed => reopened
09-08-2012 17:33Tomas UrbanNote Added: 0011014
09-08-2012 17:33Tomas UrbanStatusfeedback => resolved
09-08-2012 17:33Tomas UrbanResolutionreopened => fixed
09-08-2012 17:34Tomas UrbanStatusresolved => feedback
09-08-2012 17:34Tomas UrbanResolutionfixed => reopened
09-08-2012 17:34Tomas UrbanAssigned ToTomas Urban => Ina Schieferdecker
09-08-2012 17:34Tomas UrbanStatusfeedback => assigned
09-08-2012 17:34Tomas UrbanResolutionreopened => fixed
09-08-2012 18:24Ina SchieferdeckerProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
09-08-2012 18:24Ina SchieferdeckerNote Added: 0011017
09-08-2012 18:24Ina SchieferdeckerStatusassigned => closed
09-08-2012 18:24Ina SchieferdeckerFixed in Version => Edition 4.5.1
09-08-2012 18:24Ina SchieferdeckerTarget Version => Edition 4.5.1
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010979) +
+ Ina Schieferdecker    +
+ 06-08-2012 17:34    +
+ 		+ + + + +
+ Please check.
+
+
+
+ + + + + + + + + + +
+ (0011014) +
+ Tomas Urban    +
+ 09-08-2012 17:33    +
+ 		+ + + + +
+ Assigned to Ina for implementation.
+
+
+
+ + + + + + + + + + +
+ (0011017) +
+ Ina Schieferdecker    +
+ 09-08-2012 18:24    +
+ 		+ + + + +
+ as proposed
+
+ + diff --git a/docs/mantis/CR6248.md b/docs/mantis/CR6248.md new file mode 100644 index 0000000000000000000000000000000000000000..fbb9946564edfefa88066479dd5f44710bfe4c81 --- /dev/null +++ b/docs/mantis/CR6248.md @@ -0,0 +1,176 @@ + + + + + + + + + + + + + 0006248: Missing () in BNF rule - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006248Part 01: TTCN-3 Core LanguageTechnicalpublic06-08-2012 17:3709-08-2012 18:14
ReporterIna Schieferdecker 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.5.1 (published 2013-04)Fixed in Versionv4.5.1 (published 2013-04) 
Clause Reference(s)Annex A
Source (company - Author)Friedrich Wilhelm Schröer, Fraunhofer FOKUS
Summary0006248: Missing () in BNF rule
Description41.AllowedValuesSpec ::=
+   "(" ( TemplateOrRange {"," TemplateOrRange }) | CharStringMatch ")"
+
+needs to be
+
+41.AllowedValuesSpec ::=
+   "(" ( ( TemplateOrRange {"," TemplateOrRange } ) | CharStringMatch ) ")"
+
+Otherwise, "(" would be in the left part and ")" in the right, but they enclose the whole allowed values spec
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
06-08-2012 17:37Ina SchieferdeckerNew Issue
06-08-2012 17:37Ina SchieferdeckerStatusnew => assigned
06-08-2012 17:37Ina SchieferdeckerAssigned To => Tomas Urban
06-08-2012 17:37Ina SchieferdeckerClause Reference(s) => Annex A
06-08-2012 17:37Ina SchieferdeckerSource (company - Author) => Friedrich Wilhelm Schröer, Fraunhofer FOKUS
06-08-2012 17:37Ina SchieferdeckerNote Added: 0010980
08-08-2012 09:00Tomas UrbanNote Added: 0010990
08-08-2012 09:00Tomas UrbanStatusassigned => resolved
08-08-2012 09:00Tomas UrbanResolutionopen => fixed
08-08-2012 09:02Tomas UrbanStatusresolved => closed
09-08-2012 17:35Tomas UrbanStatusclosed => feedback
09-08-2012 17:35Tomas UrbanResolutionfixed => reopened
09-08-2012 17:35Tomas UrbanAssigned ToTomas Urban => Ina Schieferdecker
09-08-2012 17:35Tomas UrbanStatusfeedback => assigned
09-08-2012 17:35Tomas UrbanResolutionreopened => fixed
09-08-2012 17:35Tomas UrbanAdditional Information Updated
09-08-2012 17:36Tomas UrbanNote Added: 0011015
09-08-2012 17:36Tomas UrbanAdditional Information Updated
09-08-2012 18:13Ina SchieferdeckerProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
09-08-2012 18:14Ina SchieferdeckerNote Added: 0011016
09-08-2012 18:14Ina SchieferdeckerStatusassigned => closed
09-08-2012 18:14Ina SchieferdeckerFixed in Version => Edition 4.5.1
09-08-2012 18:14Ina SchieferdeckerTarget Version => Edition 4.5.1
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010980) +
+ Ina Schieferdecker    +
+ 06-08-2012 17:37    +
+ 		+ + + + +
+ Please check.
+
+
+
+ + + + + + + + + + +
+ (0010990) +
+ Tomas Urban    +
+ 08-08-2012 09:00    +
+ 		+ + + + +
+ I agree with the proposal. The rule 41. in A.1.6.1.1 shall be changed as proposed to:
+
+41.AllowedValuesSpec ::= "(" ( ( TemplateOrRange {"," TemplateOrRange } ) | CharStringMatch ) ")"
+
+
+
+ + + + + + + + + + +
+ (0011015) +
+ Tomas Urban    +
+ 09-08-2012 17:36    +
+ 		+ + + + +
+ Assigned to Ina for implementation.
+
+
+
+ + + + + + + + + + +
+ (0011016) +
+ Ina Schieferdecker    +
+ 09-08-2012 18:14    +
+ 		+ + + + +
+ as proposed.
+
+ + diff --git a/docs/mantis/CR6253.md b/docs/mantis/CR6253.md new file mode 100644 index 0000000000000000000000000000000000000000..36a3b3794c7ed6bb6117137901d896212fea8a9e --- /dev/null +++ b/docs/mantis/CR6253.md @@ -0,0 +1,63 @@ + + + + + + + + + + + + + 0006253: Old deleted text shall be deleted - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Advanced Parametrization (ES 202 784)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006253Ext Pack: Advanced Parametrization (ES 202 784)Editorialpublic08-08-2012 15:4111-12-2012 12:36
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionwon't fix 
PlatformOSOS Version
Product Version 
Target Versionv1.3.1 (published 2013-04)Fixed in Versionv1.3.1 (published 2013-04) 
TS version1.2.1
Clause Reference(s)all
Source (company - Author)L.M.Ericsson
Summary0006253: Old deleted text shall be deleted
DescriptionDue to some editorial mistake old deleted text is shown in the published document with strike-through characters. They shall physically be deleted from the docuement.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0005449closed Gyorgy Rethy Add mapping for parameterized ASN.1 types 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
08-08-2012 15:41Gyorgy RethyNew Issue
08-08-2012 15:41Gyorgy RethyTS version => 1.2.1
08-08-2012 15:41Gyorgy RethyClause Reference(s) => all
08-08-2012 15:41Gyorgy RethySource (company - Author) => L.M.Ericsson
08-08-2012 15:42Gyorgy RethyNote Added: 0010996
08-08-2012 15:42Gyorgy RethyAssigned To => Gyorgy Rethy
08-08-2012 15:42Gyorgy RethyStatusnew => assigned
08-08-2012 15:42Gyorgy RethyTarget Version => v1.3.1 (ongoing)
08-08-2012 15:47Gyorgy RethyRelationship addedrelated to 0005449
11-12-2012 12:36Gyorgy RethyStatusassigned => closed
11-12-2012 12:36Gyorgy RethyResolutionopen => won't fix
11-12-2012 12:36Gyorgy RethyFixed in Version => v1.3.1 (ongoing)
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010996) +
+ Gyorgy Rethy    +
+ 08-08-2012 15:42    +
+ 		+ + + + +
+ See resolution in the file uploaded to CR 5449.
+
+ + diff --git a/docs/mantis/CR6254.md b/docs/mantis/CR6254.md new file mode 100644 index 0000000000000000000000000000000000000000..f472cb9d577d3af2607a6b538af66bc8ab89b4d7 --- /dev/null +++ b/docs/mantis/CR6254.md @@ -0,0 +1,143 @@ + + + + + + + + + + + + + 0006254: Package compatibility should be changed to the latest published standards - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Advanced Parametrization (ES 202 784)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006254Ext Pack: Advanced Parametrization (ES 202 784)Clarificationpublic08-08-2012 15:4519-12-2012 15:10
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv1.3.1 (published 2013-04)Fixed in Versionv1.3.1 (published 2013-04) 
TS version1.2.1
Clause Reference(s)4
Source (company - Author)L.M.Ericsson
Summary0006254: Package compatibility should be changed to the latest published standards
DescriptionCurrent compatibility list is:
+ES 201 873-1 [1], version 4.1.1;
+ES 201 873-2 [8], version 3.2.1;
+ES 201 873-3 [9], version 3.2.1;
+ES 201 873-4 [2], version 4.1.1;
+ES 201 873-5 [3], version 4.1.1;
+ES 201 873-6 [4], version 4.1.1;
+ES 201 873-7 [5], version 4.1.1;
+ES 201 873-8 [10], version 3.3.1;
+ES 201 873-9 [11], version 4.1.1;
+ES 201 873-10 [6], version 3.4.1.
+
+This should be changed to the latest versions (ongoing V4.5.1)
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0005449closed Gyorgy Rethy Add mapping for parameterized ASN.1 types 
Attached Filesdoc CR6254_resolution_v1.doc (67,072) 11-12-2012 12:33
http://oldforge.etsi.org/mantis/file_download.php?file_id=2762&type=bug
Issue History
Date ModifiedUsernameFieldChange
08-08-2012 15:45Gyorgy RethyNew Issue
08-08-2012 15:45Gyorgy RethyTS version => 1.2.1
08-08-2012 15:45Gyorgy RethyClause Reference(s) => 4
08-08-2012 15:45Gyorgy RethySource (company - Author) => L.M.Ericsson
08-08-2012 15:46Gyorgy RethyNote Added: 0010997
08-08-2012 15:46Gyorgy RethyAssigned To => Gyorgy Rethy
08-08-2012 15:46Gyorgy RethyStatusnew => assigned
08-08-2012 15:46Gyorgy RethyTarget Version => v1.3.1 (ongoing)
08-08-2012 15:46Gyorgy RethyRelationship addedrelated to 0005449
11-12-2012 12:33Gyorgy RethyFile Added: CR6254_resolution_v1.doc
11-12-2012 12:33Gyorgy RethyStatusassigned => resolved
11-12-2012 12:33Gyorgy RethyFixed in Version => v1.3.1 (ongoing)
11-12-2012 12:33Gyorgy RethyResolutionopen => fixed
11-12-2012 12:33Gyorgy RethyNote Added: 0011218
19-12-2012 15:09Gyorgy RethyStatusresolved => closed
19-12-2012 15:09Gyorgy RethyNote Added: 0011293
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0010997) +
+ Gyorgy Rethy    +
+ 08-08-2012 15:46    +
+ 		+ + + + +
+ See resolution in the file uploaded to CR 5449.
+
+
+
+ + + + + + + + + + +
+ (0011218) +
+ Gyorgy Rethy    +
+ 11-12-2012 12:33    +
+ 		+ + + + +
+ See resolution in file CR6254_resolution_v1.doc
+
+
+
+ + + + + + + + + + +
+ (0011293) +
+ Gyorgy Rethy    +
+ 19-12-2012 15:09    +
+ 		+ + + + +
+ Implemented in draft V1.2.2
+
+ + diff --git a/docs/mantis/CR6255.md b/docs/mantis/CR6255.md new file mode 100644 index 0000000000000000000000000000000000000000..42204369cea1c49510c3ae4b1b6ffe3ba8fcbea8 --- /dev/null +++ b/docs/mantis/CR6255.md @@ -0,0 +1,63 @@ + + + + + + + + + + + + + 0006255: All not allowed subtypings should be identified by grey cell background - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 07: Using ASN.1 with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006255Part 07: Using ASN.1 with TTCN-3Editorialpublic10-08-2012 10:2919-12-2012 13:33
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.5.1 (published 2013-04)Fixed in Versionv4.5.1 (published 2013-04) 
Clause Reference(s)table 4
Source (company - Author)L.M.Ericsson
Summary0006255: All not allowed subtypings should be identified by grey cell background
DescriptionIn table 4 some cells with "No" are grey, some are without background color. The view of the table shall be uniform in the whole table.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0006256closed Gyorgy Rethy TIME subtype conversions is missing in table 4 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
10-08-2012 10:29Gyorgy RethyNew Issue
10-08-2012 10:29Gyorgy RethyClause Reference(s) => table 4
10-08-2012 10:29Gyorgy RethySource (company - Author) => L.M.Ericsson
10-08-2012 11:34Gyorgy RethyNote Added: 0011023
10-08-2012 11:34Gyorgy RethyStatusnew => resolved
10-08-2012 11:34Gyorgy RethyResolutionopen => fixed
10-08-2012 11:34Gyorgy RethyFixed in Version => Edition 4.5.1
10-08-2012 11:34Gyorgy RethyTarget Version => Edition 4.5.1
10-08-2012 12:14Gyorgy RethyRelationship addedrelated to 0006256
14-12-2012 11:09Ina SchieferdeckerStatusresolved => assigned
14-12-2012 11:09Ina SchieferdeckerAssigned To => Gyorgy Rethy
19-12-2012 13:33Gyorgy RethyStatusassigned => closed
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011023) +
+ Gyorgy Rethy    +
+ 10-08-2012 11:34    +
+ 		+ + + + +
+ Implemented in the draft.
+
+ + diff --git a/docs/mantis/CR6256.md b/docs/mantis/CR6256.md new file mode 100644 index 0000000000000000000000000000000000000000..a1d039578528ea66b7ad6d11e0bf3c1cccc1ff22 --- /dev/null +++ b/docs/mantis/CR6256.md @@ -0,0 +1,166 @@ + + + + + + + + + + + + + 0006256: TIME subtype conversions is missing in table 4 - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 07: Using ASN.1 with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006256Part 07: Using ASN.1 with TTCN-3Technicalpublic10-08-2012 11:5019-12-2012 13:45
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.5.1 (published 2013-04)Fixed in Versionv4.5.1 (published 2013-04) 
Clause Reference(s)table 4
Source (company - Author)L.M.Ericsson
Summary0006256: TIME subtype conversions is missing in table 4
DescriptionCurrently only the property setting subtyping of the ASN.1 type TIME is handled in table 4. Add conversion rules for the other allowed forms of subtyping.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0006255closed Gyorgy Rethy All not allowed subtypings should be identified by grey cell background 
Attached Filesdoc es_20187307v040402.doc (916,992) 10-08-2012 12:03
http://oldforge.etsi.org/mantis/file_download.php?file_id=2719&type=bug
Issue History
Date ModifiedUsernameFieldChange
10-08-2012 11:50Gyorgy RethyNew Issue
10-08-2012 11:50Gyorgy RethyClause Reference(s) => table 4
10-08-2012 11:50Gyorgy RethySource (company - Author) => L.M.Ericsson
10-08-2012 11:50Gyorgy RethyStatusnew => assigned
10-08-2012 11:50Gyorgy RethyAssigned To => Gyorgy Rethy
10-08-2012 12:03Gyorgy RethyFile Added: es_20187307v040402.doc
10-08-2012 12:14Gyorgy RethyNote Added: 0011029
10-08-2012 12:14Gyorgy RethyRelationship addedrelated to 0006255
10-08-2012 15:07Gyorgy RethyAssigned ToGyorgy Rethy => Tomas Urban
10-12-2012 16:55Gyorgy RethyTarget Version => Edition 4.5.1
10-12-2012 17:08Tomas UrbanNote Added: 0011210
10-12-2012 17:09Tomas UrbanAssigned ToTomas Urban => Ina Schieferdecker
11-12-2012 13:58Ina SchieferdeckerNote Added: 0011223
11-12-2012 13:59Ina SchieferdeckerAssigned ToIna Schieferdecker => Gyorgy Rethy
19-12-2012 13:45Gyorgy RethyNote Added: 0011288
19-12-2012 13:45Gyorgy RethyStatusassigned => closed
19-12-2012 13:45Gyorgy RethyResolutionopen => fixed
19-12-2012 13:45Gyorgy RethyFixed in Version => Edition 4.5.1
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011029) +
+ Gyorgy Rethy    +
+ 10-08-2012 12:14    +
+ 		+ + + + +
+ Draft resolution is available in file es_20187307v040402.doc. Ready for review.
+
+
+
+ + + + + + + + + + +
+ (0011210) +
+ Tomas Urban    +
+ 10-12-2012 17:08    +
+ 		+ + + + +
+ I agree with the resolution.
+Assigned to Ina for implementation.
+
+
+
+ + + + + + + + + + +
+ (0011223) +
+ Ina Schieferdecker    +
+ 11-12-2012 13:58    +
+ 		+ + + + +
+ I agree as well - assigned to the editor for implementation
+
+
+
+ + + + + + + + + + +
+ (0011288) +
+ Gyorgy Rethy    +
+ 19-12-2012 13:45    +
+ 		+ + + + +
+ Implemented in draft V4.4.2
+
+ + diff --git a/docs/mantis/CR6257.md b/docs/mantis/CR6257.md new file mode 100644 index 0000000000000000000000000000000000000000..42559203a89d2ef34da4deb2e1a0af716dca4118 --- /dev/null +++ b/docs/mantis/CR6257.md @@ -0,0 +1,88 @@ + + + + + + + + + + + + + 0006257: TRI & TCI identifiers in C++ interface mapping wrongly defined - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 05: TTCN-3 Runtime Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006257Part 05: TTCN-3 Runtime Interface Technicalpublic10-08-2012 12:0610-08-2012 12:08
ReporterIna Schieferdecker 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityblockReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.5.1 (published 2013-04)Fixed in Versionv4.5.1 (published 2013-04) 
Clause Reference(s)TRI 8.5.2, TCI 10.5.2
Source (company - Author)Mateusz Pusz/freettcn
Summary0006257: TRI & TCI identifiers in C++ interface mapping wrongly defined
DescriptionSome TRI and TCI interfaces C++ mappings inherit privately from TRI::QualifiedName. That makes impossible to call any of its interface methods. To make it straight lets assume that TM just received TciTestCaseIdList from TciTmRequired::tciGetTestCases() and wants to present the names to the user. How is it supposed to do it if it does not have the access to private interface of TciTestCaseId class (because public interface of QualifiedName ends as private one in privately inherited child class)? I think that aggregation:
+
+class TciTestCaseId {
+.....
+const QualifiedName &id() const;
+.....
+};
+
+or public inheritance if really needed:
+
+class TciTestCaseId : public QualifiedName {
+.....
+};
+
+should be used here to achieve the goal. Another issue here is the existence of non-virtual cloneQualifiedName() method which makes it not only unusable (no-one have access to it) but also unimplementable as you cannot create the same object from that level in inheritance hierarchy (object slicing).
+
+Even with above problem solved the class does not have any virtual method which makes it really hard to implement its methods as the class does not have any internal members. Because of that the developer is forced to do some external database with contents of those classes (like a map of QualifiedName pointers pointing to its content) and use it with every access to the class interface. It is why I think all methods in that class should be done pure virtual.
+
+I suggest:
+1. Making all methods in QualifiedName virtual and pure virtual (see https://github.com/mpusz/FreeTTCN/blob/d2ff73bbb9f4bb5e49b5cabe2c156512e456056c/freettcn/lib/include/freettcn/etsi/types.h#L60 [^])
+2. Make IDs inherit (TTCN_ID_IFACE_FIXED_1) or aggregate (TTCN_ID_IFACE_FIXED_2) QualifiedName (see https://github.com/mpusz/FreeTTCN/blob/d2ff73bbb9f4bb5e49b5cabe2c156512e456056c/freettcn/lib/include/freettcn/etsi/tci.h [^] and https://github.com/mpusz/FreeTTCN/blob/d2ff73bbb9f4bb5e49b5cabe2c156512e456056c/freettcn/lib/include/freettcn/etsi/tri.h [^])
+I personaly think that aggregation is better here and will make the interface more consistent with other classes like TriComponentId (https://github.com/mpusz/FreeTTCN/blob/d2ff73bbb9f4bb5e49b5cabe2c156512e456056c/freettcn/lib/include/freettcn/etsi/tri.h#L66 [^]). However both solutions will make the interface implementable,
+
+Best
+
+Mat
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
child of 0005946closed Ina Schieferdecker Part 06: TTCN-3 Control Interface TRI & TCI identifiers in C++ interface mapping wrongly defined 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
10-08-2012 12:06Ina SchieferdeckerNew Issue
10-08-2012 12:06Ina SchieferdeckerStatusnew => assigned
10-08-2012 12:06Ina SchieferdeckerAssigned To => Ina Schieferdecker
10-08-2012 12:06Ina SchieferdeckerClause Reference(s) => TRI 8.5.2, TCI 10.5.2
10-08-2012 12:06Ina SchieferdeckerSource (company - Author) => Mateusz Pusz/freettcn
10-08-2012 12:06Ina SchieferdeckerIssue generated from: 0005946
10-08-2012 12:06Ina SchieferdeckerRelationship addedchild of 0005946
10-08-2012 12:07Ina SchieferdeckerProjectPart 06: TTCN-3 Control Interface => Part 05: TTCN-3 Runtime Interface
10-08-2012 12:08Ina SchieferdeckerNote Added: 0011028
10-08-2012 12:08Ina SchieferdeckerStatusassigned => closed
10-08-2012 12:08Ina SchieferdeckerResolutionopen => fixed
10-08-2012 12:08Ina SchieferdeckerFixed in Version => Edition 4.5.1
10-08-2012 12:08Ina SchieferdeckerTarget Version => Edition 4.5.1
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011028) +
+ Ina Schieferdecker    +
+ 10-08-2012 12:08    +
+ 		+ + + + +
+ Implemented as proposed.
+
+ + diff --git a/docs/mantis/CR6309.md b/docs/mantis/CR6309.md new file mode 100644 index 0000000000000000000000000000000000000000..d8195812d3001a12392e862f14174ab42e630945 --- /dev/null +++ b/docs/mantis/CR6309.md @@ -0,0 +1,115 @@ + + + + + + + + + + + + + 0006309: NamedNumber should be mapped to constant in TTCN-3 - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 07: Using ASN.1 with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006309Part 07: Using ASN.1 with TTCN-3Technicalpublic10-09-2012 21:2719-12-2012 13:47
Reportertepelmann 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.4.1 (published 2012-04) 
Target Versionv4.5.1 (published 2013-04)Fixed in Versionv4.5.1 (published 2013-04) 
Clause Reference(s)9.1
Source (company - Author)     Testing Technologies - tepelmann
Summary0006309: NamedNumber should be mapped to constant in TTCN-3
DescriptionIn chapter "9.1 Transformation rules for ASN.1 types and values" in transformation rule 12) the handling of named numbers is defined.
+Currently the named numbers are ignored.
+This is valid for mapping the type itself. However the named numbers are given to provide specific meanings to specific values. This can be used in TTCN-3 as well.
+The named numbers shall be mapped to constants in TTCN-3.
+A proposal for the name of the constant is as follow: the type name as prefix, followed by an underscore and the name of the named number and a final underscore to avoid name clashes.
+
+To keep the named number in the format of constant is also important as a change of the named number in the ASN.1 module would be transparent for the TTCN-3 module, if the TTCN-3 constant is used inside TTCN-3 rather then a direct number(which may have changed the meaning in ASN.1)
Steps To Reproduce
Additional Informatione.g.:
+Definition in ASN.1:
+  Color ::= INTEGER {red(0),green(1), blue(255) }
+
+Mapped constant in TTCN-3:
+  type integer Color;
+
+  const Color Color_green_ := 1;
+
+  const Color Color_red_ := 0;
+
+  const Color Color_blue_ := 255;
+
TagsNo tags attached.
Relationships
Attached Filesdoc CR6309_resolution_v1.doc (120,832) 11-12-2012 13:08
http://oldforge.etsi.org/mantis/file_download.php?file_id=2763&type=bug
Issue History
Date ModifiedUsernameFieldChange
10-09-2012 21:27tepelmannNew Issue
10-09-2012 21:27tepelmannClause Reference(s) => 9.1
10-09-2012 21:27tepelmannSource (company - Author) => Testing Technologies - tepelmann
10-12-2012 13:23Gyorgy RethyStatusnew => assigned
10-12-2012 13:23Gyorgy RethyAssigned To => Gyorgy Rethy
10-12-2012 16:55Gyorgy RethyTarget Version => Edition 4.5.1
11-12-2012 13:08Gyorgy RethyFile Added: CR6309_resolution_v1.doc
11-12-2012 13:09Gyorgy RethyNote Added: 0011221
11-12-2012 13:09Gyorgy RethyStatusassigned => resolved
11-12-2012 13:09Gyorgy RethyResolutionopen => fixed
11-12-2012 13:09Gyorgy RethyFixed in Version => Edition 4.5.1
19-12-2012 13:47Gyorgy RethyStatusresolved => closed
19-12-2012 13:47Gyorgy RethyNote Added: 0011289
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011221) +
+ Gyorgy Rethy    +
+ 11-12-2012 13:09    +
+ 		+ + + + +
+ See proposed resolution in file CR6309_resolution_v1.doc
+
+
+
+ + + + + + + + + + +
+ (0011289) +
+ Gyorgy Rethy    +
+ 19-12-2012 13:47    +
+ 		+ + + + +
+ Implemented in draft V4.4.2
+
+ + diff --git a/docs/mantis/CR6310.md b/docs/mantis/CR6310.md new file mode 100644 index 0000000000000000000000000000000000000000..bb5d315ee2736dc5bb45c24d84c08d859bc0908e --- /dev/null +++ b/docs/mantis/CR6310.md @@ -0,0 +1,146 @@ + + + + + + + + + + + + + 0006310: Change Request for Extension Package Performance and Realtime Testing - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Perf & Real Time Testing (ES 202 782)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006310Ext Pack: Perf & Real Time Testing (ES 202 782)New Featurepublic11-09-2012 16:2726-12-2013 12:24
ReporterGeorg Janker 
Assigned ToJens Grabowski 
PrioritynormalSeveritymajorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv1.2.1 (published 2014-06)Fixed in Version 
Clause Reference(s)N/A
Source (company - Author)RUETZ SYSTEM SOLUTIONS GmbH - Georg Janker
TS version
Summary0006310: Change Request for Extension Package Performance and Realtime Testing
DescriptionFor realtime ports we propose to augment the sending communication
+operations with a timestamp assignment clause similar to the TimestampSpec
+for receiving communication operations.
Steps To Reproduce
Additional InformationTime-measurements for realtime testing are always time-critical and thus
+should be as precise as possible. Only the test-adapter can know when a
+message actually has been sent to the SUT (if it wasn't told to send at
+a specified point in time).
+Measuring on the level of the TE leaves an unspecified gap between
+measuring time and actual sending time (messages need to be encoded and
+might be transported through several layers of adaptation, often even to
+a different embedded component on a different node from the TE where the
+embedded SUT resides) which distorts the measurements unnecessarily,
+yielding imprecise results.
+
+Thus, neither
+
+send_timestamp := now;
+p.send(X);
+
+nor
+
+p.send(X);
+send_timestamp := now
+
+does the problem justice in lots of cases.
+
+Therefore, we propose the following syntax (and analogous versions for
+all other sending operations):
+
+p.send(<template>) [to <receiver>] -> timestamp <float_variable>
+
+To allow the implementation of this behavior, we propose to
+change the timestamp parameter of the tri-sending-functions to INOUT.
+In case of unspecified timestamp for sending, a negative timestamp value
+shall be given to the paramter when calling the tri-function.
+In that case, after the call, the timestamp shall contain the actual
+sending timestamp.
+In case that a positive timestamp was given when calling the tri-function,
+the value of the parameter shall be the same afterwards, if the sending
+operation was successful.
+
+This should avoid any backward compatibility issues regarding the interface
+if there are any concerns by the current implementers/providers of that
+  interface.
+
+Alternatively, a second version with only an out timestamp parameter instead
+of the in timestamp parameter could be introduced for all sending operation
+tri functions. This would probably make sense at least on the language
+mapping level, i.e. to use overloading in Java/C++/C# and add a differently
+named function for the C mapping.
+
TagsNo tags attached.
Relationships
Attached Filesdoc CR6310.doc (389,632) 25-11-2013 16:15
http://oldforge.etsi.org/mantis/file_download.php?file_id=2938&type=bug
Issue History
Date ModifiedUsernameFieldChange
11-09-2012 16:27Georg JankerNew Issue
11-09-2012 16:27Georg JankerClause Reference(s) => N/A
11-09-2012 16:27Georg JankerSource (company - Author) => RUETZ SYSTEM SOLUTIONS GmbH - Georg Janker
19-09-2012 15:24Gyorgy RethyProjectTTCN-3 Change Requests => Ext Pack: Perf & Real Time Testing (ES 202 782)
10-12-2012 13:29Gyorgy RethyStatusnew => assigned
10-12-2012 13:29Gyorgy RethyAssigned To => Jens Grabowski
10-12-2012 16:43Gyorgy RethyTarget Version => v1.2.1 (published 2014-06)
08-10-2013 16:25Jens GrabowskiNote Added: 0011707
08-10-2013 16:26Jens GrabowskiAssigned ToJens Grabowski => Jacob Wieland - Spirent
25-11-2013 16:15Jacob Wieland - SpirentFile Added: CR6310.doc
25-11-2013 16:19Jacob Wieland - SpirentNote Added: 0011829
25-11-2013 16:19Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Jens Grabowski
25-11-2013 16:19Jacob Wieland - SpirentStatusassigned => confirmed
26-12-2013 12:24Jens GrabowskiStatusconfirmed => closed
26-12-2013 12:24Jens GrabowskiResolutionopen => fixed
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011707) +
+ Jens Grabowski    +
+ 08-10-2013 16:25    +
+ 		+ + + + +
+ Assigned to Jacob according to STF discussion today.
+
+
+
+ + + + + + + + + + +
+ (0011829) +
+ Jacob Wieland - Spirent    +
+ 25-11-2013 16:19    +
+ 		+ + + + +
+ please review proposal
+
+ + diff --git a/docs/mantis/CR6318.md b/docs/mantis/CR6318.md new file mode 100644 index 0000000000000000000000000000000000000000..b3e631d8e59617a1a073a2b59e50217fcbfb12f4 --- /dev/null +++ b/docs/mantis/CR6318.md @@ -0,0 +1,840 @@ + + + + + + + + + + + + + 0006318: Assignment of global templates and module parameters - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006318Part 01: TTCN-3 Core LanguageClarificationpublic21-09-2012 10:1026-11-2013 16:57
ReporterTomas Urban 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.4.1 (published 2012-04) 
Target Versionv4.6.1 (published 2014-06)Fixed in Versionv4.6.1 (published 2014-06) 
Clause Reference(s)8.2
Source (company - Author)Elvior
Summary0006318: Assignment of global templates and module parameters
DescriptionI couldn't find any rules in the current standard saying when assignments of globally defined objects (i.e. static templates and module parameters) shall take place during execution. In my opinion, that gives vendors too much space for interpretation resulting in different approaches for executing such assignments, e.g.:
+
+1. At the beginning of control part
+2. When a global object is first referenced
+3. At the beginning of the lowest block containing the first reference to a global object
+
+Let's demonstrate it on an example:
+
+module M
+{
+ function f() return integer {
+  log("in function");
+  return 1;
+ }
+ template integer t := f();
+ type port P message{ inout integer; }
+ type component C { port P; }
+ testcase TC() runs on C {
+  log("in test case");
+  p.send(t);
+ }
+ control {
+  log("in control");
+  execute(TC());
+ }
+}
+
+In case of the first approach, the log would look like this:
+in function
+in control
+in test case
+
+In case of the second approach, thel log would lool like this:
+in control
+in test case
+in function
+
+In case of the third approach, thel log would lool like this:
+in control
+in function
+in test case
+
+If the first approach is used, then the global object declaration cannot contain calls that are not allowed in the control block. E.g. LTE test suite contains global templates that reference functions with testcase.stop inside and istantiating these templates in the control block can lead to trouble. This approach also makes unnecessary calls (instantiating templates that are actually never used).
+
+If the second approach is used, then there's a danger that the template is referenced in a place mentioned in the chapter 16.1.4. In such a case it is possible that its declaration contains a function call that is forbidden by the restrictions listed in 16.1.4. If the template has been already referenced before, the statement will be executed without any problem (because the value has been already assigned and the forbidden function is actually not called). However, in case it is the first template reference, an error will occur during the function call. Such an approach is in my opinion unacceptable, because it can lead to different test case results that are dependent only on execution path.
+
+The third approach doesn't suffer from any of the above mentioned problems, but it produces "unnatural" execution order and it might be difficult to explain it to users.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0006606closed Gyorgy Rethy Allow usage of deterministic external functions in snapshot evaluation 
Attached Filesdoc CR-6318-resolution-V1.doc (70,144) 19-12-2012 13:49
http://oldforge.etsi.org/mantis/file_download.php?file_id=2789&type=bug
doc CR-6318-resolution-V2.doc (70,656) 21-12-2012 12:06
http://oldforge.etsi.org/mantis/file_download.php?file_id=2798&type=bug
doc CR6318-Resolution-V3-JG.doc (90,624) 30-08-2013 10:35
http://oldforge.etsi.org/mantis/file_download.php?file_id=2880&type=bug
doc CR6318-Resolution-V4-JW.doc (89,600) 30-08-2013 13:44
http://oldforge.etsi.org/mantis/file_download.php?file_id=2881&type=bug
doc CR6318-Resolution-V5.doc (89,600) 10-10-2013 10:00
http://oldforge.etsi.org/mantis/file_download.php?file_id=2918&type=bug
Issue History
Date ModifiedUsernameFieldChange
21-09-2012 10:10Tomas UrbanNew Issue
21-09-2012 10:10Tomas UrbanClause Reference(s) => 8.2
21-09-2012 10:10Tomas UrbanSource (company - Author) => Elvior
28-09-2012 12:09Jacob Wieland - SpirentNote Added: 0011154
10-12-2012 13:38Gyorgy RethyStatusnew => assigned
10-12-2012 13:38Gyorgy RethyAssigned To => Jens Grabowski
10-12-2012 16:42Gyorgy RethyTarget Version => Edition 4.5.1
11-12-2012 10:14Jens GrabowskiNote Added: 0011213
11-12-2012 10:14Jens GrabowskiAssigned ToJens Grabowski => Tomas Urban
11-12-2012 13:07Tomas UrbanNote Added: 0011220
14-12-2012 07:50Tomas UrbanNote Added: 0011262
14-12-2012 07:50Tomas UrbanAssigned ToTomas Urban => Jens Grabowski
14-12-2012 12:56Jacob Wieland - SpirentNote Added: 0011279
14-12-2012 14:36Jens GrabowskiFile Added: CR6014-resolution-v3.doc
14-12-2012 14:37Jens GrabowskiNote Added: 0011282
14-12-2012 14:37Jens GrabowskiAssigned ToJens Grabowski => Gyorgy Rethy
19-12-2012 13:49Jens GrabowskiFile Deleted: CR6014-resolution-v3.doc
19-12-2012 13:49Jens GrabowskiFile Added: CR-6318-resolution-V1.doc
20-12-2012 11:19Gyorgy RethyNote Added: 0011296
20-12-2012 11:19Gyorgy RethyStatusassigned => resolved
20-12-2012 11:19Gyorgy RethyResolutionopen => fixed
20-12-2012 11:19Gyorgy RethyFixed in Version => Edition 4.5.1
21-12-2012 10:56Gyorgy RethyStatusresolved => feedback
21-12-2012 10:56Gyorgy RethyResolutionfixed => reopened
21-12-2012 10:57Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
21-12-2012 10:57Gyorgy RethyStatusfeedback => resolved
21-12-2012 10:57Gyorgy RethyResolutionreopened => fixed
21-12-2012 12:05Ina SchieferdeckerNote Added: 0011311
21-12-2012 12:06Ina SchieferdeckerFile Added: CR-6318-resolution-V2.doc
21-12-2012 12:06Ina SchieferdeckerStatusresolved => closed
04-01-2013 11:52Jacob Wieland - SpirentStatusclosed => feedback
04-01-2013 11:52Jacob Wieland - SpirentResolutionfixed => reopened
04-01-2013 11:52Jacob Wieland - SpirentNote Added: 0011318
04-01-2013 12:03Ina SchieferdeckerStatusfeedback => assigned
04-01-2013 12:03Ina SchieferdeckerAssigned ToIna Schieferdecker => Jens Grabowski
04-01-2013 12:04Ina SchieferdeckerNote Added: 0011319
18-01-2013 11:13Jacob Wieland - SpirentNote Added: 0011323
14-05-2013 15:33Gyorgy RethyTarget VersionEdition 4.5.1 => v4.7.1 (published 2015-06)
08-07-2013 18:18Gyorgy RethyFixed in Versionv4.5.1 (published 2013-04) =>
29-08-2013 16:31Gyorgy RethyNote Added: 0011642
30-08-2013 10:35Jens GrabowskiFile Added: CR6318-Resolution-V3-JG.doc
30-08-2013 10:37Jens GrabowskiNote Added: 0011654
30-08-2013 10:37Jens GrabowskiAssigned ToJens Grabowski => Jacob Wieland - Spirent
30-08-2013 13:44Jacob Wieland - SpirentFile Added: CR6318-Resolution-V4-JW.doc
30-08-2013 13:47Jacob Wieland - SpirentNote Added: 0011659
30-08-2013 13:48Jacob Wieland - SpirentNote Added: 0011660
30-08-2013 13:48Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
30-08-2013 13:48Jacob Wieland - SpirentStatusassigned => confirmed
30-08-2013 14:14Gyorgy RethyNote Added: 0011663
30-08-2013 14:14Gyorgy RethyStatusconfirmed => assigned
30-08-2013 14:14Gyorgy RethyAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
30-08-2013 14:14Gyorgy RethyStatusassigned => confirmed
30-08-2013 16:04Jacob Wieland - SpirentNote Added: 0011665
30-08-2013 16:19Jacob Wieland - SpirentStatusconfirmed => assigned
30-08-2013 16:19Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Ina Schieferdecker
30-08-2013 16:19Jacob Wieland - SpirentAssigned ToIna Schieferdecker => Gyorgy Rethy
09-10-2013 10:53Jacob Wieland - SpirentRelationship addedrelated to 0006606
10-10-2013 10:00Gyorgy RethyFile Added: CR6318-Resolution-V5.doc
10-10-2013 10:02Gyorgy RethyNote Added: 0011744
10-10-2013 10:03Gyorgy RethyAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
10-10-2013 10:03Gyorgy RethyStatusassigned => confirmed
10-10-2013 10:03Gyorgy RethyResolutionreopened => fixed
10-10-2013 10:09Tomas UrbanNote Added: 0011745
10-10-2013 15:30Jacob Wieland - SpirentStatusconfirmed => assigned
10-10-2013 15:30Jacob Wieland - SpirentNote Added: 0011757
10-10-2013 15:30Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Ina Schieferdecker
10-10-2013 15:30Jacob Wieland - SpirentStatusassigned => confirmed
26-11-2013 16:56Ina SchieferdeckerNote Added: 0011839
26-11-2013 16:56Ina SchieferdeckerStatusconfirmed => resolved
26-11-2013 16:56Ina SchieferdeckerFixed in Version => v4.6.1 (published 2014-06)
26-11-2013 16:57Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011154) +
+ Jacob Wieland - Spirent    +
+ 28-09-2012 12:09    +
+ 		+ + + + +
+ Since global templates are like constants, they should normally not produce any behavior or side-effects. Therefore, the same restrictions as for the usage of functions during alt-guard-evaluation should be imposed.
+
+With this approach, it becomes irrelevant when the template is instantiated whether early at module-loading time or lazy at first-usage.
+
+If the use of a template shall produce a behavior, it should be parameterized and the behavior given as actual parameter. Then, the evaluation time is clearly the point of usage. This approach can even be used together with default parameter values.
+
+
+
+ + + + + + + + + + +
+ (0011213) +
+ Jens Grabowski    +
+ 11-12-2012 10:14    +
+ 		+ + + + +
+ Section "16.1.4 Invoking functions from specific places" defines the restrictions for the usage of functions during alt-guard evaluation.
+
+If I interprete 16.1.4 correctly, then he same restrictions apply for invoking functions in templates, template fields, in-line templates or as actual parameters.
+
+The text of 16.1.4 is:
+
+"Value returning functions can be called in communication operations (in templates, template fields, in-line templates, or
+as actual parameters), in guards of alt statements or altsteps (see clause 20.2), and in initializations of altstep local
+definitions (see clause 16.2). To avoid side effects that cause changing the state of the component or the actual snapshot
+and to prevent different results of subsequent evaluations on an unchanged snapshot, the following operations shall not
+be used in functions called in the cases specified above:"
+
+Thus, the solution provided by Jacob is already implemented in the standard. Assigned to Tomas to crosscheck.
+
+
+
+ + + + + + + + + + +
+ (0011220) +
+ Tomas Urban    +
+ 11-12-2012 13:07    +
+ 		+ + + + +
+ Jens, I am afraid that I cannot agree your conclusion. 16.1.4 sets restrictions on function calls used in three syntactical constructions: communication operations, guards and altstep local definitions. It doesn't set any restriction on global template definitions.
+
+We could of course add "and in declarations of global templates" to the mentioned sentence ("Value returning functions ... "), but I don't think it can be done because of problems with backwards compatibility. In particular, I am sure that there are test suites that contain external function calls in global template definitions. Using the same restrictions as for alt guards means that such test suites would stop working. However, allowing external functions has unfortunately an unpleasant side efect: the order of global template assignments will start to matter and it will be required to specify rules for execution order.
+
+
+
+ + + + + + + + + + +
+ (0011262) +
+ Tomas Urban    +
+ 14-12-2012 07:50    +
+ 		+ + + + +
+ Assigned to Jens to implement the changes discussed at yesterday's meeting.
+
+
+
+ + + + + + + + + + +
+ (0011279) +
+ Jacob Wieland - Spirent    +
+ 14-12-2012 12:56    +
+ 		+ + + + +
+ I think the problem with external functions is that it is unknown whether they have side effects or not.
+
+Maybe a way should be introduced to declare an external function side-effect-free and then allowing these functions both inside templates as well as the other special function-invocation-places.
+
+
+
+ + + + + + + + + + +
+ (0011282) +
+ Jens Grabowski    +
+ 14-12-2012 14:37    +
+ 		+ + + + +
+ Proposal for Resolution uploaded.
+Assigned to Gyögy for crosschecking.
+
+
+
+ + + + + + + + + + +
+ (0011296) +
+ Gyorgy Rethy    +
+ 20-12-2012 11:19    +
+ 		+ + + + +
+ Its Ok with one typo: in the first inserted text "paramterization" should be parameterization (first e is missing)
+
+
+
+ + + + + + + + + + +
+ (0011311) +
+ Ina Schieferdecker    +
+ 21-12-2012 12:05    +
+ 		+ + + + +
+ Implemented with small editorials as in v2.
+
+
+
+ + + + + + + + + + +
+ (0011318) +
+ Jacob Wieland - Spirent    +
+ 04-01-2013 11:52    +
+ 		+ + + + +
+ Sorry, but the resolution is not understandable.
+
+What does "the place of their declaration" mean for global templates in regard to their initialization TIME. Up till now, the order of global declarations (which are essentially unordered) does not imply any initialization order. Also, no restriction when these templates shall be initialized (or if at all) before their use exists. The whole point of this CR was to clarify this (if really necessary) to avoid divergences between tools.
+
+This has not been achieved by the solution as the place of a declaration does not tell us anything about the time of its initialization.
+
+Also, if one would assume that all global templates shall be initialized before execution, the proposed solution would mean that parameterized templates are partially initialized before execution and the fields affected by parameterization are initialized at the place of their use.
+
+This, in my view, is completely unacceptable behavior. No one would expect this behavior and it is backward incompatible for parameterized templates that call external functions (but not with one of the parameters) and assume this function call is done for every new instance of the template.
+
+
+
+ + + + + + + + + + +
+ (0011319) +
+ Ina Schieferdecker    +
+ 04-01-2013 12:04    +
+ 		+ + + + +
+ Please check
+
+
+
+ + + + + + + + + + +
+ (0011323) +
+ Jacob Wieland - Spirent    +
+ 18-01-2013 11:13    +
+ 		+ + + + +
+ Counter proposal.
+
+In my understanding, the only problem that really exists (in regard to this issue) is the question whether it should be allowed to use templates using not-allowed constructs in the snapshot-evaluation-part of an alt-statement (i.e. in the guard expression or in the event-part).
+
+Since it is definitely more convenient to allow this, I would propose to specify that all instances of global templates that are referenced in the snapshot-evaluation part of an (explicit or implicit) alt statement must be instantiated at the latest before the first evaluation of the snapshot of that alt statement and should otherwise be instantiated in the order of the appearance of their usage (from left to right).
+
+Otherwise standardizing the instantiation order of global templates has wide-ranging ramifications. First of all, a global order must be established (i.e. over all modules), as otherwise, the order of unrelated templates would still be arbitrary. This would force every tool to always instantiate all global templates even though they are potentially not used by any testcase that is being run, i.e. performance optimizations are not possible in that regard anymore.
+
+This new proposed solution thus solves two problems. It allows usage of any template inside the snapshot-evaluation part and assigns (a new) clear semantic meaning to such usage. It also leaves possibilities for tools to optimize template instantiation in regard to the testcases being executed.
+
+If the order of external function calls is relevant to the user, they should write the TTCN-3 code accordingly so that order is enforced (e.g. by parameterizing the templates with the results of such calls).
+
+Also, this proposal has no backward compatibility drawbacks (unlike the other) as the semantics of behavior of functioning existing code is not affected by it.
+
+
+
+ + + + + + + + + + +
+ (0011642) +
+ Gyorgy Rethy    +
+ 29-08-2013 16:31    +
+ 		+ + + + +
+ STF discussion 2013-08-29: A text to be included into the templates clause saying that users are strongly advised to adhere to the restrictions of 16.1.4 (functions called at specific places) for all function calls inside global constants, templates and module parameters, to avoid non-deterministic behavior and const/template/modulepar values.
+These limitations cannot be made mandatory for backward compatibility reason, hence the advice.
+It is also agreed that external functions producing deterministic output will be allowed in 16.1.4.
+
+
+
+ + + + + + + + + + +
+ (0011654) +
+ Jens Grabowski    +
+ 30-08-2013 10:37    +
+ 		+ + + + +
+ Resolution in file "CR6318-Resolution-V3-JG.doc". Assigned to Jacob for cross-checking.
+
+
+
+ + + + + + + + + + +
+ (0011659) +
+ Jacob Wieland - Spirent    +
+ 30-08-2013 13:47    +
+ 		+ + + + +
+ Removed the changes to the paragraph describing the full speficiation/initialization of templates in their declaration. We agreed that that was unnecessary.
+
+Fixed typos (adviced -> advised)
+
+Made description of non-deterministic functions more explicit (also regarding out parameters).
+
+
+
+ + + + + + + + + + +
+ (0011660) +
+ Jacob Wieland - Spirent    +
+ 30-08-2013 13:48    +
+ 		+ + + + +
+ please review my changes
+
+
+
+ + + + + + + + + + +
+ (0011663) +
+ Gyorgy Rethy    +
+ 30-08-2013 14:14    +
+ 		+ + + + +
+ In general OK with me but one comment.
+
+While clause 16.1.4 item j) disallows inout and out parameters, the new text of item e) says: "where the resulting values for actual inout or out parameters or the return value may differ for different invocations with the same actual in and inout parameters".
+
+j) and new e) seems to be contradicting. It seems it would be enough to write: "where the return value may differ for different invocations with the same actual parameters"
+
+
+
+ + + + + + + + + + +
+ (0011665) +
+ Jacob Wieland - Spirent    +
+ 30-08-2013 16:04    +
+ 		+ + + + +
+ no, the calling of out/inout functions is only disallowed for the top-level call (note 8, I think). Inside a function, calling other functions with inout/out parameters is allowed. The same should be true for external functions to be consistent and therefore, the determinism also needs to be established for the inout/out parameters.
+
+
+
+ + + + + + + + + + +
+ (0011744) +
+ Gyorgy Rethy    +
+ 10-10-2013 10:02    +
+ 		+ + + + +
+ It is note 6; I have added to it in CR6318-Resolution-V5.doc that the non-recursivity is meant for restriction j) to be unambiguous in this. With this minor amendment it is OK with me. Tomas, Jacob, pls, check if the resolution is OK with you.
+
+
+
+ + + + + + + + + + +
+ (0011745) +
+ Tomas Urban    +
+ 10-10-2013 10:09    +
+ 		+ + + + +
+ Very elegant solution. It allows tool vendors to add proper warnings/errors (depending on compiler settings) in problematic cases and still preserves backwards compatibility. I like it.
+
+
+
+ + + + + + + + + + +
+ (0011757) +
+ Jacob Wieland - Spirent    +
+ 10-10-2013 15:30    +
+ 		+ + + + +
+ fine with me
+
+
+
+ + + + + + + + + + +
+ (0011839) +
+ Ina Schieferdecker    +
+ 26-11-2013 16:56    +
+ 		+ + + + +
+ as proposed
+
+ + diff --git a/docs/mantis/CR6321.md b/docs/mantis/CR6321.md new file mode 100644 index 0000000000000000000000000000000000000000..88e4aef475d27b4082f254e7f01d7d0f3ec25678 --- /dev/null +++ b/docs/mantis/CR6321.md @@ -0,0 +1,107 @@ + + + + + + + + + + + + + 0006321: Add explanatory text to enum2int - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006321Part 01: TTCN-3 Core LanguageClarificationpublic26-09-2012 17:2514-12-2012 06:59
ReporterGyorgy Rethy 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.5.1 (published 2013-04)Fixed in Versionv4.5.1 (published 2013-04) 
Clause Reference(s)C.1.30 Enumerated to integer
Source (company - Author)L.M.Ericsson
Summary0006321: Add explanatory text to enum2int
DescriptionWhen using enumerated values, the standard requires that the type of that value be always identified:
+in clause 6.2.4:
+"... . The identifiers of enumerated values shall be unique within the enumerated type (but do not have to be globally unique) and are consequently visible in the context of the given type only. ..."
+and in clause 3.1:
+"type context: "In the context of a type" means that at least one object involved in the given TTCN-3 action (an assignment, operation, parameter passing etc.) identifies a concrete type unambiguously
+NOTE: Either directly (e.g. an in-line template) or by means of a typed TTCN-3 object (e.g. via a constant, variable, formal parameter etc.)."
+
+As a consequence, no simple literal enumerated value shall be passed to enum2int, only a typed object, like a constant, variable, modulepar or a function call with a return type. Users should be notified about this specifics.
+
+Proposed solution: adding the following sentence to end of the 1st paragraph of C.1.30:
+"The actual parameter passed to inpar always shall be a typed object (see clause 6.2.4 and the definition "type context" in clause 3.1)."
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
26-09-2012 17:25Gyorgy RethyNew Issue
26-09-2012 17:25Gyorgy RethyClause Reference(s) => C.1.30 Enumerated to integer
26-09-2012 17:25Gyorgy RethySource (company - Author) => L.M.Ericsson
17-10-2012 12:50Jacob Wieland - SpirentNote Added: 0011175
10-12-2012 13:39Gyorgy RethyStatusnew => assigned
10-12-2012 13:39Gyorgy RethyAssigned To => Ina Schieferdecker
10-12-2012 16:40Gyorgy RethyTarget Version => Edition 4.5.1
14-12-2012 06:59Ina SchieferdeckerNote Added: 0011259
14-12-2012 06:59Ina SchieferdeckerStatusassigned => closed
14-12-2012 06:59Ina SchieferdeckerResolutionopen => fixed
14-12-2012 06:59Ina SchieferdeckerFixed in Version => Edition 4.5.1
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011175) +
+ Jacob Wieland - Spirent    +
+ 17-10-2012 12:50    +
+ 		+ + + + +
+ I agree.
+
+
+
+ + + + + + + + + + +
+ (0011259) +
+ Ina Schieferdecker    +
+ 14-12-2012 06:59    +
+ 		+ + + + +
+ Implemented as proposed.
+
+ + diff --git a/docs/mantis/CR6327.md b/docs/mantis/CR6327.md new file mode 100644 index 0000000000000000000000000000000000000000..e3ed7ae337e6d1360dc9ea8c48b471dbfbbe228c --- /dev/null +++ b/docs/mantis/CR6327.md @@ -0,0 +1,97 @@ + + + + + + + + + + + + + 0006327: Invalid C# mapping of XTriMapParam and XTriUnmapParam - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Extended TRI (ES 202 789)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006327Ext Pack: Extended TRI (ES 202 789)Technicalpublic06-11-2012 08:0111-12-2012 14:19
ReporterTomas Urban 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv1.1.1 (published 2012-04) 
Target Versionv1.2.1 (published 2013-04)Fixed in Versionv1.2.1 (published 2013-04) 
Clause Reference(s)
Source (company - Author)
Summary0006327: Invalid C# mapping of XTriMapParam and XTriUnmapParam
DescriptionIn the C# IXTriCommunicationSA definition (9.5.2.1), the third parameters of XTriMapParam and XTriUnmapParam methods are currently of the ITciValueList type. That's incorrect, because the abstract interface definition (as specified in 5.5.2.3 and 5.5.2.5) requires the parameters to be of the TciParameterListType. This type shall be mapped to ITciParameterList in C#.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
06-11-2012 08:01Tomas UrbanNew Issue
13-11-2012 12:52Tomas UrbanNote Added: 0011180
10-12-2012 13:49Gyorgy RethyStatusnew => assigned
10-12-2012 13:49Gyorgy RethyAssigned To => Ina Schieferdecker
10-12-2012 16:40Gyorgy RethyTarget Version => Edition 1.2.1 (ongoing)
11-12-2012 14:18Ina SchieferdeckerNote Added: 0011227
11-12-2012 14:19Ina SchieferdeckerStatusassigned => resolved
11-12-2012 14:19Ina SchieferdeckerResolutionopen => fixed
11-12-2012 14:19Ina SchieferdeckerFixed in Version => Edition 1.2.1 (ongoing)
11-12-2012 14:19Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011180) +
+ Tomas Urban    +
+ 13-11-2012 12:52    +
+ 		+ + + + +
+ Several other methods are affected too: XTriCall, XTriCallBC, XTriCallMC, XTriReply, XTriReplyBC, XTriReplyMC, XTriExternalFunction, XTriEnqueueCall and XTriEnqueueReply.
+
+
+
+ + + + + + + + + + +
+ (0011227) +
+ Ina Schieferdecker    +
+ 11-12-2012 14:18    +
+ 		+ + + + +
+ Implemented as proposed for all parameterList parameters in the C# mapping.
+
+ + diff --git a/docs/mantis/CR6330.md b/docs/mantis/CR6330.md new file mode 100644 index 0000000000000000000000000000000000000000..b92ffa838cf10de5c0974379cea9ae7bc0e7f552 --- /dev/null +++ b/docs/mantis/CR6330.md @@ -0,0 +1,69 @@ + + + + + + + + + + + + + 0006330: Pointer value in C and C++ mapping - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Extended TRI (ES 202 789)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006330Ext Pack: Extended TRI (ES 202 789)Editorialpublic15-11-2012 12:0813-12-2012 12:59
ReporterTomas Urban 
Assigned ToIna Schieferdecker 
PrioritynormalSeveritytextReproducibilityhave not tried
StatusclosedResolutionwon't fix 
PlatformOSOS Version
Product Versionv1.1.1 (published 2012-04) 
Target Versionv1.2.1 (published 2013-04)Fixed in Version 
Clause Reference(s)
Source (company - Author)
Summary0006330: Pointer value in C and C++ mapping
DescriptionThe last item in the type_kind enumeration is called e_ptr (with void pointer as description).
+
+There are two possible interpretation I could come up:
+
+1. It indicates presence of a Value object. In this case the comment could be changed so that people dodn't get impression that any void pointer is suitable. I would prefer to change e_ptr to e_value or e_tci_value too, but that might be impossible for compatibility reasons. An alternative would be to add e_value/e_tci_value to the enumeration with the same value as e_ptr (as a synonym).
+
+2. It indicates any content and it is up to the xtriConvert function to provide the conversion to a TCI value. In this case I would prefer to add e_value or e_tci_value to the enumeration to allow passing TCI values directly to the TE without need to execute the xtriConvert function.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0006168closed Ina Schieferdecker xtriConvert should be located in xtriCommunicationSA instead of xtriCommunicationTE 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
15-11-2012 12:08Tomas UrbanNew Issue
15-11-2012 12:25Tomas UrbanSummaryValue in C and C++ mapping => Pointer value in C and C++ mapping
15-11-2012 12:25Tomas UrbanDescription Updated
10-12-2012 13:50Gyorgy RethyStatusnew => assigned
10-12-2012 13:50Gyorgy RethyAssigned To => Ina Schieferdecker
10-12-2012 16:12Gyorgy RethyTarget Version => Edition 1.2.1 (ongoing)
13-12-2012 12:57Ina SchieferdeckerRelationship addedrelated to 0006168
13-12-2012 12:59Ina SchieferdeckerNote Added: 0011253
13-12-2012 12:59Ina SchieferdeckerStatusassigned => closed
13-12-2012 12:59Ina SchieferdeckerResolutionopen => won't fix
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011253) +
+ Ina Schieferdecker    +
+ 13-12-2012 12:59    +
+ 		+ + + + +
+ This issue was caused by the wrong placement of xtriConvert in extended TRI. Now that xtriConvert is placed in the right interface, it is not an issue anymore.
+
+ + diff --git a/docs/mantis/CR6331.md b/docs/mantis/CR6331.md new file mode 100644 index 0000000000000000000000000000000000000000..7715b3f3aee5e1decadcc4b29a7327e78cb5c56e --- /dev/null +++ b/docs/mantis/CR6331.md @@ -0,0 +1,66 @@ + + + + + + + + + + + + + 0006331: String support for C and C++ - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Extended TRI (ES 202 789)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006331Ext Pack: Extended TRI (ES 202 789)New Featurepublic15-11-2012 12:1411-12-2012 15:17
ReporterTomas Urban 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv1.2.1 (published 2013-04)Fixed in Versionv1.2.1 (published 2013-04) 
Clause Reference(s)
Source (company - Author)
Summary0006331: String support for C and C++
DescriptionThe type_kind enumeration defined in C and C++ mapping shall contain support for standard null terminated strings. The following items shall be added to the enumeration:
+e_char_string = 30, // char *
+e_wchar_string = 31 // wchar_t *
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
15-11-2012 12:14Tomas UrbanNew Issue
10-12-2012 13:51Gyorgy RethyStatusnew => assigned
10-12-2012 13:51Gyorgy RethyAssigned To => Ina Schieferdecker
10-12-2012 16:10Gyorgy RethyTarget Version => Edition 1.2.1 (ongoing)
11-12-2012 15:16Ina SchieferdeckerNote Added: 0011234
11-12-2012 15:16Ina SchieferdeckerStatusassigned => resolved
11-12-2012 15:16Ina SchieferdeckerResolutionopen => fixed
11-12-2012 15:16Ina SchieferdeckerFixed in Version => Edition 1.2.1 (ongoing)
11-12-2012 15:16Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011234) +
+ Ina Schieferdecker    +
+ 11-12-2012 15:16    +
+ 		+ + + + +
+ Implemented as proposed.
+
+ + diff --git a/docs/mantis/CR6332.md b/docs/mantis/CR6332.md new file mode 100644 index 0000000000000000000000000000000000000000..8b627fc21be60d3adca3e8de9959b8373928c525 --- /dev/null +++ b/docs/mantis/CR6332.md @@ -0,0 +1,78 @@ + + + + + + + + + + + + + 0006332: Syntax errors in C and C++ mapping - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Extended TRI (ES 202 789)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006332Ext Pack: Extended TRI (ES 202 789)Editorialpublic15-11-2012 12:5011-12-2012 14:40
ReporterTomas Urban 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv1.1.1 (published 2012-04) 
Target Versionv1.2.1 (published 2013-04)Fixed in Versionv1.2.1 (published 2013-04) 
Clause Reference(s)
Source (company - Author)
Summary0006332: Syntax errors in C and C++ mapping
DescriptionTciParameterList -> TciParameterListType (C mapping, see TCI specification)
+
+enumerated -> enum (C and C++)
+
+typedef struct {
+type_kind tag,
+value val
+} Object;
+->
+typedef struct {
+type_kind tag;
+value val;
+} Object;
+(C and C++)
+
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
15-11-2012 12:50Tomas UrbanNew Issue
10-12-2012 13:52Gyorgy RethyStatusnew => assigned
10-12-2012 13:52Gyorgy RethyAssigned To => Ina Schieferdecker
10-12-2012 16:10Gyorgy RethyTarget Version => Edition 1.2.1 (ongoing)
11-12-2012 14:39Ina SchieferdeckerNote Added: 0011231
11-12-2012 14:40Ina SchieferdeckerStatusassigned => resolved
11-12-2012 14:40Ina SchieferdeckerResolutionopen => fixed
11-12-2012 14:40Ina SchieferdeckerFixed in Version => Edition 1.2.1 (ongoing)
11-12-2012 14:40Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011231) +
+ Ina Schieferdecker    +
+ 11-12-2012 14:39    +
+ 		+ + + + +
+ Implemented as proposed.
+
+ + diff --git a/docs/mantis/CR6333.md b/docs/mantis/CR6333.md new file mode 100644 index 0000000000000000000000000000000000000000..56eeeb1fdcea1437d5982f93f11a7b9285dd25c2 --- /dev/null +++ b/docs/mantis/CR6333.md @@ -0,0 +1,70 @@ + + + + + + + + + + + + + 0006333: TCI C mapping: numeric version of tciSetInt and tciGetInt - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006333Part 06: TTCN-3 Control InterfaceNew Featurepublic20-11-2012 11:0314-12-2012 07:35
ReporterTomas Urban 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.4.1 (published 2012-04) 
Target Versionv4.5.1 (published 2013-04)Fixed in Versionv4.5.1 (published 2013-04) 
Clause Reference(s)9.2
Source (company - Author)Elvior
Summary0006333: TCI C mapping: numeric version of tciSetInt and tciGetInt
DescriptionThe current C mapping of the tciSetInt and tciGetInt contains several functions that use either character strings or individual digits and a sign to get or set numeric values. Although this approach can be useful for dealing with very large numbers, I believe that in the most common cases, users would benefit from having a simple set and get functions using integer numbers (as it is the case in mapping to other languages). The current functions usually require writing conversion code on the adapter side (often even platform-specific), which is time-consuming and results in slower code.
+
+Proposed functions to be added to the C mapping:
+long long tciGetInt(Value inst);
+void tciSetInt(Value inst, long long value);
+
+The existing functions shall be left unchanged to keep backwards compatibility and allow handling large values (exceeding boundaries of signed 64-bit numbers).
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
20-11-2012 11:03Tomas UrbanNew Issue
20-11-2012 11:03Tomas UrbanClause Reference(s) => 9.2
20-11-2012 11:03Tomas UrbanSource (company - Author) => Elvior
10-12-2012 13:41Gyorgy RethyStatusnew => assigned
10-12-2012 13:41Gyorgy RethyAssigned To => Ina Schieferdecker
10-12-2012 16:39Gyorgy RethyTarget Version => Edition 4.5.1
14-12-2012 07:35Ina SchieferdeckerNote Added: 0011261
14-12-2012 07:35Ina SchieferdeckerStatusassigned => resolved
14-12-2012 07:35Ina SchieferdeckerResolutionopen => fixed
14-12-2012 07:35Ina SchieferdeckerFixed in Version => Edition 4.5.1
14-12-2012 07:35Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011261) +
+ Ina Schieferdecker    +
+ 14-12-2012 07:35    +
+ 		+ + + + +
+ Implemented as proposed.
+
+ + diff --git a/docs/mantis/CR6334.md b/docs/mantis/CR6334.md new file mode 100644 index 0000000000000000000000000000000000000000..7b76afba46bc28464ffe29d9144cf34b7614f385 --- /dev/null +++ b/docs/mantis/CR6334.md @@ -0,0 +1,102 @@ + + + + + + + + + + + + + 0006334: C++ mapping: invalid return value of xtriConvert - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Extended TRI (ES 202 789)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006334Ext Pack: Extended TRI (ES 202 789)Technicalpublic20-11-2012 13:5011-12-2012 14:22
ReporterTomas Urban 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv1.2.1 (published 2013-04)Fixed in Versionv1.2.1 (published 2013-04) 
Clause Reference(s)8.6.2
Source (company - Author)Elvior
Summary0006334: C++ mapping: invalid return value of xtriConvert
DescriptionThe xtriConvert function of the xTriCommunicationTE class return a stack-allocated instance TciValue. This will always lead to a compilation error, because TciValue is an abstract class. The correct signature could be:
+virtual TciValue * xtriConvert(const Object *value, const TciType *typeHypothesis)=0;
+or
+virtual TciValue & xtriConvert(const Object *value, const TciType *typeHypothesis)=0;
+
+I would prefer the first variant, since the method obviously has capability of creating new objects and this way it is possible to pass the responsibility for disposing the created objects to the caller.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
20-11-2012 13:50Tomas UrbanNew Issue
20-11-2012 13:50Tomas UrbanClause Reference(s) => 8.6.2
20-11-2012 13:50Tomas UrbanSource (company - Author) => Elvior
20-11-2012 13:51Tomas UrbanNote Added: 0011181
23-11-2012 07:14Tomas UrbanProjectPart 06: TTCN-3 Control Interface => Ext Pack: Extended TRI (ES 202 789)
10-12-2012 13:52Gyorgy RethyStatusnew => assigned
10-12-2012 13:52Gyorgy RethyAssigned To => Ina Schieferdecker
10-12-2012 16:39Gyorgy RethyProduct VersionEdition 4.4.1 Published 2012-04-01 =>
10-12-2012 16:39Gyorgy RethyTarget Version => Edition 1.2.1 (ongoing)
11-12-2012 14:21Ina SchieferdeckerNote Added: 0011228
11-12-2012 14:21Ina SchieferdeckerStatusassigned => resolved
11-12-2012 14:21Ina SchieferdeckerResolutionopen => fixed
11-12-2012 14:21Ina SchieferdeckerFixed in Version => Edition 1.2.1 (ongoing)
11-12-2012 14:22Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011181) +
+ Tomas Urban    +
+ 20-11-2012 13:51    +
+ 		+ + + + +
+ This issue is related to Advanced TRI. Could anyone move it to this project?
+
+
+
+ + + + + + + + + + +
+ (0011228) +
+ Ina Schieferdecker    +
+ 11-12-2012 14:21    +
+ 		+ + + + +
+ Implemented the first proposal.
+
+ + diff --git a/docs/mantis/CR6335.md b/docs/mantis/CR6335.md new file mode 100644 index 0000000000000000000000000000000000000000..d5bfcf30ad2de4163fce26e92a6ed937393ec41f --- /dev/null +++ b/docs/mantis/CR6335.md @@ -0,0 +1,66 @@ + + + + + + + + + + + + + 0006335: Reset call shall be removed from C++ mapping - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Extended TRI (ES 202 789)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006335Ext Pack: Extended TRI (ES 202 789)Editorialpublic20-11-2012 14:1111-12-2012 14:34
ReporterTomas Urban 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv1.1.1 (published 2012-04) 
Target Versionv1.2.1 (published 2013-04)Fixed in Versionv1.2.1 (published 2013-04) 
Clause Reference(s)
Source (company - Author)
Summary0006335: Reset call shall be removed from C++ mapping
DescriptionThe SA reset call shall not be present in the of xTriCommunicationSA definition. The following lines shall be removed:
+
+//To reset the System Adaptor
+virtual xTriStatus triSAReset ()=0;
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
20-11-2012 14:11Tomas UrbanNew Issue
10-12-2012 13:53Gyorgy RethyStatusnew => assigned
10-12-2012 13:53Gyorgy RethyAssigned To => Ina Schieferdecker
10-12-2012 16:09Gyorgy RethyTarget Version => Edition 1.2.1 (ongoing)
11-12-2012 14:33Ina SchieferdeckerNote Added: 0011230
11-12-2012 14:33Ina SchieferdeckerStatusassigned => resolved
11-12-2012 14:33Ina SchieferdeckerResolutionopen => fixed
11-12-2012 14:33Ina SchieferdeckerFixed in Version => Edition 1.2.1 (ongoing)
11-12-2012 14:34Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011230) +
+ Ina Schieferdecker    +
+ 11-12-2012 14:33    +
+ 		+ + + + +
+ Implemented as proposed.
+
+ + diff --git a/docs/mantis/CR6336.md b/docs/mantis/CR6336.md new file mode 100644 index 0000000000000000000000000000000000000000..f2d83430d442c85f76fcda2fe9a039708a777e6b --- /dev/null +++ b/docs/mantis/CR6336.md @@ -0,0 +1,63 @@ + + + + + + + + + + + + + 0006336: C++ mapping: invalid const qualifier in xtriMapParam and xtriUnmapParam - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Extended TRI (ES 202 789)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006336Ext Pack: Extended TRI (ES 202 789)Technicalpublic23-11-2012 07:1211-12-2012 14:31
ReporterTomas Urban 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv1.1.1 (published 2012-04) 
Target Versionv1.2.1 (published 2013-04)Fixed in Versionv1.2.1 (published 2013-04) 
Clause Reference(s)
Source (company - Author)
Summary0006336: C++ mapping: invalid const qualifier in xtriMapParam and xtriUnmapParam
DescriptionIn C++ mapping, the last parameter of xtriMapParam and xtriUnmapParam methods of the xTriCommunicationSA class shall not contain a const qualifier, because it prevents setting of output parameter values.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
23-11-2012 07:12Tomas UrbanNew Issue
10-12-2012 13:53Gyorgy RethyStatusnew => assigned
10-12-2012 13:53Gyorgy RethyAssigned To => Ina Schieferdecker
10-12-2012 15:11Gyorgy RethyTarget Version => Edition 1.2.1 (ongoing)
11-12-2012 14:30Ina SchieferdeckerNote Added: 0011229
11-12-2012 14:30Ina SchieferdeckerStatusassigned => resolved
11-12-2012 14:30Ina SchieferdeckerResolutionopen => fixed
11-12-2012 14:30Ina SchieferdeckerFixed in Version => Edition 1.2.1 (ongoing)
11-12-2012 14:30Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011229) +
+ Ina Schieferdecker    +
+ 11-12-2012 14:30    +
+ 		+ + + + +
+ Implemented as proposed.
+
+ + diff --git a/docs/mantis/CR6337.md b/docs/mantis/CR6337.md new file mode 100644 index 0000000000000000000000000000000000000000..b051b0917db495b8533a9612508b724843df4a88 --- /dev/null +++ b/docs/mantis/CR6337.md @@ -0,0 +1,137 @@ + + + + + + + + + + + + + 0006337: Excess use of const qualifiers in C++ mapping - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006337Part 06: TTCN-3 Control InterfaceTechnicalpublic23-11-2012 08:2014-12-2012 07:30
ReporterTomas Urban 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.4.1 (published 2012-04) 
Target Versionv4.5.1 (published 2013-04)Fixed in Versionv4.5.1 (published 2013-04) 
Clause Reference(s)10
Source (company - Author)Elvior
Summary0006337: Excess use of const qualifiers in C++ mapping
DescriptionThe current definition of C++ TCI mapping contains several methods where use of const qualifiers is too restrictive. The issue concerns various get methods of constructive value classes and classes for parameter handling.
+
+In case of value classes, it leads to writing an inefficient code. E.g. in order to change an existing value inside a record, one must create a copy of the existing field, set the value in the copy and use the copy to call the setField method.
+
+The most severely affected class is the TciParameterList class, especially if used in extended TRI calls. E.g. in order to set a value of an output parameter of an external functions, the following algorithm has to be used:
+1. Get all parameter from the parameter list and store them (the get method of the TciParameterList returns constants)
+2. Create a copy of the parameter that will be modified
+3. Create a copy of the TCI value object contained in the parameter copy (the getValue method again returns a constant)
+4. Modify the value contained in the TCI value object
+5. Call the setValue of the parameter object to set the new parameter value
+6. Clear the parameter list
+7. Use the push_back method to assign the parameter copy and all remaining parameters to the list (the parameter list class doesn't contain a method to change a parameter at a specified index).
+
+It is very clumsy. In my opinion, the algorith should be:
+1. Get the parameter be to modified from the list
+2. Get the TCI object embedded in the parameter
+3. Modify the value
+
+There's of course a good reason, why the const qualifier is used. The affected get methods are (in most cases) allowed in const objects too. It means that the current get methods cannot be simply modified by removing the const qualifier, because that would lead to compilations with existing TCI implementations. Fortunately C++ allows so called const overloading, so it is possible to create methods with the same name, parameters and return values, but different const qualifiers.
+
+Therefore I propose to add the following methods to C++ TCI mapping:
+
+1. To the TciParameter class (10.5.2.9):
+virtual TciValue & getValue () = 0;
+
+2. To the TciParameterList class (10.5.2.10):
+virtual TciParameter *get (Tindex p_index) = 0;
+
+3. To the RecordValue class (10.5.3.11):
+virtual TciValue &getField (const Tstring &p_field_name) = 0;
+
+4. To the RecordOfValue class (10.5.3.12, the current get method shall be removed, because it doesn't work in const objects):
+virtual const TciValue & getField (Tindex p_position) const = 0;
+virtual TciValue & getField (Tindex p_position) = 0;
+
+5. To the UnionValue class (10.5.3.13):
+virtual TciValue & getVariant (const Tstring &p_variantName) = 0;
+
+6. To the AddressValue class (10.5.3.17):
+virtual TciValue & getAddress () = 0;
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR_6337_v1.docx (136,585) 12-12-2012 08:09
http://oldforge.etsi.org/mantis/file_download.php?file_id=2767&type=bug
Issue History
Date ModifiedUsernameFieldChange
23-11-2012 08:20Tomas UrbanNew Issue
23-11-2012 08:20Tomas UrbanClause Reference(s) => 10
23-11-2012 08:20Tomas UrbanSource (company - Author) => Elvior
10-12-2012 13:42Gyorgy RethyStatusnew => assigned
10-12-2012 13:42Gyorgy RethyAssigned To => Tomas Urban
10-12-2012 16:15Gyorgy RethyTarget Version => Edition 4.5.1
12-12-2012 08:09Tomas UrbanFile Added: CR_6337_v1.docx
12-12-2012 08:10Tomas UrbanNote Added: 0011238
12-12-2012 08:10Tomas UrbanAssigned ToTomas Urban => Ina Schieferdecker
14-12-2012 07:29Ina SchieferdeckerNote Added: 0011260
14-12-2012 07:29Ina SchieferdeckerStatusassigned => resolved
14-12-2012 07:29Ina SchieferdeckerResolutionopen => fixed
14-12-2012 07:29Ina SchieferdeckerFixed in Version => Edition 4.5.1
14-12-2012 07:30Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011238) +
+ Tomas Urban    +
+ 12-12-2012 08:10    +
+ 		+ + + + +
+ Proposed resolution attached.
+Please review.
+
+
+
+ + + + + + + + + + +
+ (0011260) +
+ Ina Schieferdecker    +
+ 14-12-2012 07:29    +
+ 		+ + + + +
+ Implemented as proposed.
+
+ + diff --git a/docs/mantis/CR6338.md b/docs/mantis/CR6338.md new file mode 100644 index 0000000000000000000000000000000000000000..aafa98e54ae4cef61dc88cc38a2d891bf06169db --- /dev/null +++ b/docs/mantis/CR6338.md @@ -0,0 +1,135 @@ + + + + + + + + + + + + + 0006338: Location of definitions and fields generated for wildcards (any element) shall be defined - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006338Part 09: Using XML with TTCN-3Clarificationpublic30-11-2012 11:0211-12-2012 16:13
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionwon't fix 
PlatformOSOS Version
Product Version 
Target Versionv4.5.1 (published 2013-04)Fixed in Versionv4.5.1 (published 2013-04) 
Clause Reference(s)7.7
For STF discussion
Source (company - Author)L.M.Ericsson
Summary0006338: Location of definitions and fields generated for wildcards (any element) shall be defined
DescriptionLocation of fields corresponding to anyAttribute is specified but not the order of fields generated for element elements and any elements within the enclosing structured type.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
30-11-2012 11:02Gyorgy RethyNew Issue
30-11-2012 11:02Gyorgy RethyClause Reference(s) => 7.7
30-11-2012 11:02Gyorgy RethySource (company - Author) => L.M.Ericsson
10-12-2012 13:43Gyorgy RethyStatusnew => assigned
10-12-2012 13:43Gyorgy RethyAssigned To => Gyorgy Rethy
10-12-2012 16:14Gyorgy RethyTarget Version => Edition 4.5.1
11-12-2012 10:21Gyorgy RethyFile Added: CR6338_resolution_v1.doc
11-12-2012 10:22Gyorgy RethyNote Added: 0011215
11-12-2012 10:22Gyorgy RethyAssigned ToGyorgy Rethy => Tomas Urban
11-12-2012 16:10Tomas UrbanNote Added: 0011236
11-12-2012 16:10Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
11-12-2012 16:11Gyorgy RethyFile Deleted: CR6338_resolution_v1.doc
11-12-2012 16:12Gyorgy RethyNote Added: 0011237
11-12-2012 16:13Gyorgy RethyStatusassigned => closed
11-12-2012 16:13Gyorgy RethyResolutionopen => won't fix
11-12-2012 16:13Gyorgy RethyFixed in Version => Edition 4.5.1
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011215) +
+ Gyorgy Rethy    +
+ 11-12-2012 10:22    +
+ 		+ + + + +
+ Proposed resolultion is in CR6338_resolution_v1.doc, pls. review.
+
+
+
+ + + + + + + + + + +
+ (0011236) +
+ Tomas Urban    +
+ 11-12-2012 16:10    +
+ 		+ + + + +
+ The position of the any element is significant in case of xsd:sequence. It means that the generated field cannot be at the end of the enframing record, because the codec would not know the insertion point for the any element.
+
+The current specification already contains a sentence: "The XSD any element shall be translated, like other elements, to a field of the enframing record type or field or union field ..." I suppose the sentence can be interpreted in the way that rules for position of the any element are the same as for any other element (because the chapter 7.7.1 doesn't specify otherwise). If it is safe to make such an assumption, I think that actually no change is required in the specification.
+
+Assigned to György to crosscheck.
+
+
+
+ + + + + + + + + + +
+ (0011237) +
+ Gyorgy Rethy    +
+ 11-12-2012 16:12    +
+ 		+ + + + +
+ Correct, the CR can be closed, no change is needed.
+
+ + diff --git a/docs/mantis/CR6339.md b/docs/mantis/CR6339.md new file mode 100644 index 0000000000000000000000000000000000000000..ad56c3495115f98ff28446c882731ed3f72ac8f8 --- /dev/null +++ b/docs/mantis/CR6339.md @@ -0,0 +1,165 @@ + + + + + + + + + + + + + 0006339: Section 7.6.8: wrong mixed content naming examples - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006339Part 09: Using XML with TTCN-3Editorialpublic30-11-2012 12:5619-12-2012 13:17
ReporterThilo Lauer 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.4.1 (published 2012-04) 
Target Versionv4.5.1 (published 2013-04)Fixed in Versionv4.5.1 (published 2013-04) 
Clause Reference(s)ETSI ES 201 873-9 V4.4.1 (2012-04) - Section 7.6.8: Mixed content
For STF discussion
Source (company - Author)Devoteam - Thilo Lauer
Summary0006339: Section 7.6.8: wrong mixed content naming examples
DescriptionWrong naming of mixed content examples. See uploaded Email Discussion "XSD2TTCN ed.4.4.1 mixed content naming questions.msg" for more details.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesmsg XSD2TTCN ed.4.4.1 mixed content naming questions.msg (85,504) 30-11-2012 12:56
http://oldforge.etsi.org/mantis/file_download.php?file_id=2722&type=bug
doc CR6339_resolution_v1.doc (106,496) 10-12-2012 13:18
http://oldforge.etsi.org/mantis/file_download.php?file_id=2757&type=bug
Issue History
Date ModifiedUsernameFieldChange
30-11-2012 12:56Thilo LauerNew Issue
30-11-2012 12:56Thilo LauerFile Added: XSD2TTCN ed.4.4.1 mixed content naming questions.msg
30-11-2012 12:56Thilo LauerClause Reference(s) => ETSI ES 201 873-9 V4.4.1 (2012-04) - Section 7.6.8: Mixed content
30-11-2012 12:56Thilo LauerSource (company - Author) => Devoteam - Thilo Lauer
10-12-2012 13:18Gyorgy RethyFile Added: CR6339_resolution_v1.doc
10-12-2012 13:19Gyorgy RethyNote Added: 0011204
10-12-2012 13:47Gyorgy RethyStatusnew => assigned
10-12-2012 13:47Gyorgy RethyAssigned To => Gyorgy Rethy
10-12-2012 14:00Gyorgy RethyStatusassigned => resolved
10-12-2012 14:00Gyorgy RethyFixed in Version => Edition 4.5.1
10-12-2012 14:00Gyorgy RethyResolutionopen => fixed
10-12-2012 14:00Gyorgy RethyNote Added: 0011205
10-12-2012 15:09Gyorgy RethyStatusresolved => feedback
10-12-2012 15:09Gyorgy RethyResolutionfixed => reopened
10-12-2012 15:09Gyorgy RethyTarget Version => Edition 4.5.1
10-12-2012 15:10Gyorgy RethyStatusfeedback => resolved
10-12-2012 15:10Gyorgy RethyResolutionreopened => fixed
10-12-2012 15:10Gyorgy RethyNote Added: 0011207
19-12-2012 13:17Gyorgy RethyStatusresolved => closed
19-12-2012 13:17Gyorgy RethyNote Added: 0011287
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011204) +
+ Gyorgy Rethy    +
+ 10-12-2012 13:19    +
+ 		+ + + + +
+ See draft resolution in CR6339_resolution_v1.doc
+
+
+
+ + + + + + + + + + +
+ (0011205) +
+ Gyorgy Rethy    +
+ 10-12-2012 14:00    +
+ 		+ + + + +
+ corrected
+
+
+
+ + + + + + + + + + +
+ (0011207) +
+ Gyorgy Rethy    +
+ 10-12-2012 15:10    +
+ 		+ + + + +
+ Target version is specified
+
+
+
+ + + + + + + + + + +
+ (0011287) +
+ Gyorgy Rethy    +
+ 19-12-2012 13:17    +
+ 		+ + + + +
+ Implemented in draft V4.4.2
+
+ + diff --git a/docs/mantis/CR6378.md b/docs/mantis/CR6378.md new file mode 100644 index 0000000000000000000000000000000000000000..311ed16b09224ac4afb5745d26f0d5718f3ef7e6 --- /dev/null +++ b/docs/mantis/CR6378.md @@ -0,0 +1,31 @@ + + + + + + + + + + + + + 0006378: Java mapping: invalid syntax and type names - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Extended TRI (ES 202 789)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006378Ext Pack: Extended TRI (ES 202 789)Editorialpublic05-12-2012 07:4311-12-2012 14:12
ReporterTomas Urban 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionduplicate 
PlatformOSOS Version
Product Versionv1.1.1 (published 2012-04) 
Target Versionv1.2.1 (published 2013-04)Fixed in Versionv1.2.1 (published 2013-04) 
Clause Reference(s)
Source (company - Author)
Summary0006378: Java mapping: invalid syntax and type names
DescriptionThird parameters of the xTriCommunicationSA.xtriMapParam and xTriCommunicationSA.xtriUnmapParam have incorrect syntax (superfluous "in" keyword from the abstract interface definition shall be removed) and use wrong type name ("TciParameterList" shall be used instead of "TciParameterListType").
+
+Both parameters of the xTriCommunicationTE.xtriConvert have incorrect syntax (superfluous "in" keyword from the abstract interface definition shall be removed).
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0006083closed Ina Schieferdecker Incorrect parameters in the different interfaces in the Java mapping 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
05-12-2012 07:43Tomas UrbanNew Issue
10-12-2012 13:53Gyorgy RethyStatusnew => assigned
10-12-2012 13:53Gyorgy RethyAssigned To => Ina Schieferdecker
10-12-2012 16:09Gyorgy RethyTarget Version => Edition 1.2.1 (ongoing)
11-12-2012 14:11Ina SchieferdeckerRelationship addedrelated to 0006083
11-12-2012 14:12Ina SchieferdeckerStatusassigned => closed
11-12-2012 14:12Ina SchieferdeckerResolutionopen => duplicate
11-12-2012 14:12Ina SchieferdeckerFixed in Version => Edition 1.2.1 (ongoing)
+
+ + + + +
+ There are no notes attached to this issue.
+ + diff --git a/docs/mantis/CR6379.md b/docs/mantis/CR6379.md new file mode 100644 index 0000000000000000000000000000000000000000..c9d17dcc3c07d83f885ea3310a117676b2ac503a --- /dev/null +++ b/docs/mantis/CR6379.md @@ -0,0 +1,165 @@ + + + + + + + + + + + + + 0006379: Add case "minOccurs not present and maxOccurs=unbounded" to Table 7 - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006379Part 09: Using XML with TTCN-3Editorialpublic05-12-2012 09:4619-12-2012 13:11
ReporterThilo Lauer 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.4.1 (published 2012-04) 
Target Versionv4.5.1 (published 2013-04)Fixed in Versionv4.5.1 (published 2013-04) 
Clause Reference(s)ETSI ES 201 873-9 V4.4.1 (2012-04) - Section 7.1.4 MinOccurs and maxOccurs Table 7
For STF discussion
Source (company - Author)Devoteam - Thilo Lauer
Summary0006379: Add case "minOccurs not present and maxOccurs=unbounded" to Table 7
DescriptionAdd this case to section 7.1.4, Table 7:
+
+column: content:
+=======================
+minOccurs: not present, //i.e. default value = 1
+maxOccurs: unbounded
+in...:
+TTCN-3: record length (1..infinity) of <initial type>
+
+
+Comment:
+The table row starting with: "<x> ≥ 1" covers the case above only implicitly. But imho it should be contained explicitly in Table 7.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR6379_resolution_v1.doc (89,088) 10-12-2012 15:07
http://oldforge.etsi.org/mantis/file_download.php?file_id=2759&type=bug
Issue History
Date ModifiedUsernameFieldChange
05-12-2012 09:46Thilo LauerNew Issue
05-12-2012 09:46Thilo LauerClause Reference(s) => ETSI ES 201 873-9 V4.4.1 (2012-04) - Section 7.1.4 MinOccurs and maxOccurs Table 7
05-12-2012 09:46Thilo LauerSource (company - Author) => Devoteam - Thilo Lauer
05-12-2012 11:10Thilo LauerNote Added: 0011202
05-12-2012 11:36Thilo LauerNote Edited: 0011202
10-12-2012 13:47Gyorgy RethyStatusnew => assigned
10-12-2012 13:47Gyorgy RethyAssigned To => Gyorgy Rethy
10-12-2012 14:59Gyorgy RethyNote Added: 0011206
10-12-2012 14:59Gyorgy RethyFile Added: CR6379_resolution_v1.doc
10-12-2012 15:01Gyorgy RethyFile Deleted: CR6379_resolution_v1.doc
10-12-2012 15:07Gyorgy RethyFile Added: CR6379_resolution_v1.doc
10-12-2012 15:08Gyorgy RethyStatusassigned => resolved
10-12-2012 15:08Gyorgy RethyResolutionopen => fixed
10-12-2012 15:08Gyorgy RethyFixed in Version => Edition 4.5.1
10-12-2012 15:08Gyorgy RethyTarget Version => Edition 4.5.1
19-12-2012 13:11Gyorgy RethyStatusresolved => closed
19-12-2012 13:11Gyorgy RethyNote Added: 0011286
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011202) +
+ Thilo Lauer    +
+ 05-12-2012 11:10    +
(edited on: 05-12-2012 11:36)
+ 		+ + + + +
+ The following cases should also be added to section 7.1.4, Table 7 for clarification reasons:
+
+column: content:
+=======================
+minOccurs: 0
+maxOccurs: <y> > 1
+in...:
+TTCN-3: record length (0..<y>) of <initial type>
+
+
+column: content:
+=======================
+minOccurs: not present // i.e. default value = 1
+maxOccurs: <y> > 1
+in...:
+TTCN-3: record length (1..<y>) of <initial type>
+
+
+
+
+
+ + + + + + + + + + +
+ (0011206) +
+ Gyorgy Rethy    +
+ 10-12-2012 14:59    +
+ 		+ + + + +
+ See resolution proposal in CR6379_resolution_v1.doc.
+
+The case minOccurs is missing, maxOccurs is unbounded has been added to the column where minOccurs >= 1, because, as the CR also mentions, this is not a separate case just a different way of specifying minOccurs ="1".
+
+The case minOccurs: 0 and maxOccurs: <y> > 1 has been solved by replacing <x> not equals 0 by <x> >= 0
+
+The case minOccurs: 1 or not present maxOccurs: <y> > 1 has been added as a new row
+
+
+
+ + + + + + + + + + +
+ (0011286) +
+ Gyorgy Rethy    +
+ 19-12-2012 13:11    +
+ 		+ + + + +
+ Implemented in draft V4.4.2
+
+ + diff --git a/docs/mantis/CR6380.md b/docs/mantis/CR6380.md new file mode 100644 index 0000000000000000000000000000000000000000..ca991cec16e0623b0ee3345ca2eaddd86594648c --- /dev/null +++ b/docs/mantis/CR6380.md @@ -0,0 +1,29 @@ + + + + + + + + + + + + + 0006380: Java mapping: misspelled parameter name - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Extended TRI (ES 202 789)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006380Ext Pack: Extended TRI (ES 202 789)Editorialpublic05-12-2012 14:1811-12-2012 14:23
ReporterTomas Urban 
Assigned ToIna Schieferdecker 
PrioritynormalSeveritytrivialReproducibilityhave not tried
StatusclosedResolutionduplicate 
PlatformOSOS Version
Product Version 
Target Versionv1.2.1 (published 2013-04)Fixed in Versionv1.2.1 (published 2013-04) 
Clause Reference(s)
Source (company - Author)
Summary0006380: Java mapping: misspelled parameter name
DescriptionThe name of the second parameter in of the xtriRaise methods is misspelled: tsitPortId -> tsiPortId
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0006083closed Ina Schieferdecker Incorrect parameters in the different interfaces in the Java mapping 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
05-12-2012 14:18Tomas UrbanNew Issue
10-12-2012 13:54Gyorgy RethyStatusnew => assigned
10-12-2012 13:54Gyorgy RethyAssigned To => Ina Schieferdecker
10-12-2012 15:10Gyorgy RethyTarget Version => Edition 1.2.1 (ongoing)
11-12-2012 14:23Ina SchieferdeckerRelationship addedrelated to 0006083
11-12-2012 14:23Ina SchieferdeckerStatusassigned => closed
11-12-2012 14:23Ina SchieferdeckerResolutionopen => duplicate
11-12-2012 14:23Ina SchieferdeckerFixed in Version => Edition 1.2.1 (ongoing)
+
+ + + + +
+ There are no notes attached to this issue.
+ + diff --git a/docs/mantis/CR6381.md b/docs/mantis/CR6381.md new file mode 100644 index 0000000000000000000000000000000000000000..f812fa5dfe36afbf407924a7fabed1ae1fe39ff0 --- /dev/null +++ b/docs/mantis/CR6381.md @@ -0,0 +1,165 @@ + + + + + + + + + + + + + 0006381: Alphabetical order shall be precisely defined - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006381Part 09: Using XML with TTCN-3Clarificationpublic11-12-2012 17:1219-12-2012 13:06
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.4.1 (published 2012-04) 
Target Versionv4.5.1 (published 2013-04)Fixed in Versionv4.5.1 (published 2013-04) 
Clause Reference(s)5.2.3, 7.6.7
For STF discussion
Source (company - Author)Elvior
Summary0006381: Alphabetical order shall be precisely defined
DescriptionThere are different ways how to sort strings alphabetically. E.g. abc, Abc, Bcd can be sorted as Abc, abc, Bcd (logical order) or Abc, Bcd, abc (ASCI/Unicode character order). The specification shall clearly specify unambiguous rules for alphabetical sorting, because it has an impact on transformed TTCN-3 code.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR6381_resolution_v1.doc (76,800) 12-12-2012 14:11
http://oldforge.etsi.org/mantis/file_download.php?file_id=2770&type=bug
doc CR6381_resolution_v2.doc (78,336) 12-12-2012 14:39
http://oldforge.etsi.org/mantis/file_download.php?file_id=2772&type=bug
Issue History
Date ModifiedUsernameFieldChange
11-12-2012 17:12Tomas UrbanNew Issue
11-12-2012 17:12Tomas UrbanClause Reference(s) => 5.2.3, 7.6.7
11-12-2012 17:12Tomas UrbanSource (company - Author) => Elvior
12-12-2012 08:54Gyorgy RethyStatusnew => assigned
12-12-2012 08:54Gyorgy RethyAssigned To => Gyorgy Rethy
12-12-2012 08:54Gyorgy RethyTarget Version => Edition 4.5.1
12-12-2012 14:11Gyorgy RethyFile Added: CR6381_resolution_v1.doc
12-12-2012 14:12Gyorgy RethyNote Added: 0011242
12-12-2012 14:12Gyorgy RethyAssigned ToGyorgy Rethy => Tomas Urban
12-12-2012 14:39Tomas UrbanFile Added: CR6381_resolution_v2.doc
12-12-2012 14:40Tomas UrbanNote Added: 0011244
12-12-2012 14:40Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
12-12-2012 15:29Gyorgy RethyNote Added: 0011247
12-12-2012 15:29Gyorgy RethyStatusassigned => resolved
12-12-2012 15:29Gyorgy RethyResolutionopen => fixed
12-12-2012 15:29Gyorgy RethyFixed in Version => Edition 4.5.1
19-12-2012 13:06Gyorgy RethyStatusresolved => closed
19-12-2012 13:06Gyorgy RethyNote Added: 0011285
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011242) +
+ Gyorgy Rethy    +
+ 12-12-2012 14:12    +
+ 		+ + + + +
+ draft proposal for resolution is in CR6381_resolution_v1.doc. Pls. review
+
+
+
+ + + + + + + + + + +
+ (0011244) +
+ Tomas Urban    +
+ 12-12-2012 14:40    +
+ 		+ + + + +
+ Basically I agree, I only added a clause for shorter names.
+
+
+
+ + + + + + + + + + +
+ (0011247) +
+ Gyorgy Rethy    +
+ 12-12-2012 15:29    +
+ 		+ + + + +
+ Good point.
+
+
+
+ + + + + + + + + + +
+ (0011285) +
+ Gyorgy Rethy    +
+ 19-12-2012 13:06    +
+ 		+ + + + +
+ Implemented in draft version V4.4.2
+
+ + diff --git a/docs/mantis/CR6382.md b/docs/mantis/CR6382.md new file mode 100644 index 0000000000000000000000000000000000000000..6343d3b19d29963593aa1f8202931d2dd390b9c2 --- /dev/null +++ b/docs/mantis/CR6382.md @@ -0,0 +1,73 @@ + + + + + + + + + + + + + 0006382: Typo in Destructor for xTriPlatformPA - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Extended TRI (ES 202 789)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006382Ext Pack: Extended TRI (ES 202 789)Editorialpublic12-12-2012 13:3012-12-2012 13:32
ReporterIna Schieferdecker 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv1.2.1 (published 2013-04)Fixed in Versionv1.2.1 (published 2013-04) 
Clause Reference(s)8.6.3 Changes to TriPlatformPA in clause 7.9
Source (company - Author)Ina Schieferdecker, FOKUS
Summary0006382: Typo in Destructor for xTriPlatformPA
DescriptionThe destructor needs to be called xTriPlatformPA and not TriPlatformPA
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
12-12-2012 13:30Ina SchieferdeckerNew Issue
12-12-2012 13:30Ina SchieferdeckerStatusnew => assigned
12-12-2012 13:30Ina SchieferdeckerAssigned To => Ina Schieferdecker
12-12-2012 13:30Ina SchieferdeckerClause Reference(s) => 8.6.3 Changes to TriPlatformPA in clause 7.9
12-12-2012 13:30Ina SchieferdeckerSource (company - Author) => Ina Schieferdecker, FOKUS
12-12-2012 13:31Ina SchieferdeckerNote Added: 0011240
12-12-2012 13:31Ina SchieferdeckerProjectTTCN-3 Change Requests => Ext Pack: Extended TRI (ES 202 789)
12-12-2012 13:32Ina SchieferdeckerStatusassigned => resolved
12-12-2012 13:32Ina SchieferdeckerResolutionopen => fixed
12-12-2012 13:32Ina SchieferdeckerFixed in Version => Edition 1.2.1 (ongoing)
12-12-2012 13:32Ina SchieferdeckerTarget Version => Edition 1.2.1 (ongoing)
12-12-2012 13:32Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011240) +
+ Ina Schieferdecker    +
+ 12-12-2012 13:31    +
+ 		+ + + + +
+ Defined as
+
+class xTriPlatformPA {
+public:
+
+    //Destructor.
+    virtual ~xTriPlatformPA ();
+    
+    //For each external function specified in the TTCN-3 ATS implement the behaviour.
+    virtual TriStatus xtriExternalFunction (const TriFunctionId *functionId, TciParameterList *parameterList, TciValue *returnValue)=0;
+}
+
+ + diff --git a/docs/mantis/CR6383.md b/docs/mantis/CR6383.md new file mode 100644 index 0000000000000000000000000000000000000000..ef8ce09423e5c8a704fbbf16bf51ce8d3ba2c8a1 --- /dev/null +++ b/docs/mantis/CR6383.md @@ -0,0 +1,70 @@ + + + + + + + + + + + + + 0006383: Typos in class names in the C++ mapping - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Extended TRI (ES 202 789)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006383Ext Pack: Extended TRI (ES 202 789)Editorialpublic12-12-2012 13:5012-12-2012 13:52
ReporterIna Schieferdecker 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv1.2.1 (published 2013-04)Fixed in Versionv1.2.1 (published 2013-04) 
Clause Reference(s)7.8 Changes to clause 8 C++ language mapping
Source (company - Author)Ina Schieferdecker, FOKUS
Summary0006383: Typos in class names in the C++ mapping
DescriptionConsistent with the C++ naming scheme, the extended TRI classes should be named:
+
+class xTriCommunicationSa {...}
+class xTriCommunicationTe {...}
+class xTriPlatformPa {...}
+class xTriPlatformTe {
+
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
12-12-2012 13:50Ina SchieferdeckerNew Issue
12-12-2012 13:50Ina SchieferdeckerStatusnew => assigned
12-12-2012 13:50Ina SchieferdeckerAssigned To => Ina Schieferdecker
12-12-2012 13:50Ina SchieferdeckerClause Reference(s) => 7.8 Changes to clause 8 C++ language mapping
12-12-2012 13:50Ina SchieferdeckerSource (company - Author) => Ina Schieferdecker, FOKUS
12-12-2012 13:51Ina SchieferdeckerCategoryTechnical => Editorial
12-12-2012 13:51Ina SchieferdeckerProjectTTCN-3 Change Requests => Ext Pack: Extended TRI (ES 202 789)
12-12-2012 13:51Ina SchieferdeckerNote Added: 0011241
12-12-2012 13:51Ina SchieferdeckerStatusassigned => resolved
12-12-2012 13:51Ina SchieferdeckerResolutionopen => fixed
12-12-2012 13:51Ina SchieferdeckerFixed in Version => Edition 1.2.1 (ongoing)
12-12-2012 13:51Ina SchieferdeckerTarget Version => Edition 1.2.1 (ongoing)
12-12-2012 13:52Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011241) +
+ Ina Schieferdecker    +
+ 12-12-2012 13:51    +
+ 		+ + + + +
+ as proposed.
+
+ + diff --git a/docs/mantis/CR6384.md b/docs/mantis/CR6384.md new file mode 100644 index 0000000000000000000000000000000000000000..ccf77b7b0938a76603e63a2f3436bff30d375cb7 --- /dev/null +++ b/docs/mantis/CR6384.md @@ -0,0 +1,63 @@ + + + + + + + + + + + + + 0006384: C# mapping: Object -> object - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Extended TRI (ES 202 789)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006384Ext Pack: Extended TRI (ES 202 789)Editorialpublic12-12-2012 15:0913-12-2012 08:23
ReporterTomas Urban 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv1.1.1 (published 2012-04) 
Target Versionv1.2.1 (published 2013-04)Fixed in Versionv1.2.1 (published 2013-04) 
Clause Reference(s)
Source (company - Author)
Summary0006384: C# mapping: Object -> object
DescriptionThe current C# mappings use the keyword "string" rather than the class name "String" (i.e. System.String). However, for abstract objects, XTRI uses the class name "Object" and not the keyword "object". In my opinion, used convension should be the same in both cases and because objects are used in XTRI only, while strings appear in other interfaces as well, I recommend to change XTRI C# so that the keyword "object" is used.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0006176closed Ina Schieferdecker Extension of triErrorReq to Object 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
12-12-2012 15:09Tomas UrbanNew Issue
12-12-2012 15:09Tomas UrbanStatusnew => assigned
12-12-2012 15:09Tomas UrbanAssigned To => Ina Schieferdecker
12-12-2012 16:46Ina SchieferdeckerRelationship addedrelated to 0006176
12-12-2012 17:06Ina SchieferdeckerNote Added: 0011248
13-12-2012 08:22Ina SchieferdeckerStatusassigned => resolved
13-12-2012 08:22Ina SchieferdeckerResolutionopen => fixed
13-12-2012 08:22Ina SchieferdeckerFixed in Version => Edition 1.2.1 (ongoing)
13-12-2012 08:22Ina SchieferdeckerTarget Version => Edition 1.2.1 (ongoing)
13-12-2012 08:23Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011248) +
+ Ina Schieferdecker    +
+ 12-12-2012 17:06    +
+ 		+ + + + +
+ Implemented as proposed.
+
+ + diff --git a/docs/mantis/CR6385.md b/docs/mantis/CR6385.md new file mode 100644 index 0000000000000000000000000000000000000000..26a28f2aed3ecc0bf68c1ecddb573f75baefe514 --- /dev/null +++ b/docs/mantis/CR6385.md @@ -0,0 +1,66 @@ + + + + + + + + + + + + + 0006385: Couple of editorials in Part-10 - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 10: TTCN-3 documentation tags
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006385Part 10: TTCN-3 documentation tagsEditorialpublic12-12-2012 17:3812-12-2012 17:42
ReporterGyorgy Rethy 
Assigned To 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.5.1 (published 2013-04)Fixed in Versionv4.5.1 (published 2013-04) 
Source (company - Author)L.M.Ericsson
Summary0006385: Couple of editorials in Part-10
Description- The abbreviaton TTCN-3 to be deleted as this is contained in Part-1
+- Add URI to the abbreviations
+- In clause 8 change "Url tag" to "@url tag"
+- textual clause no. references shall be replaced by bookmark cross/references
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
12-12-2012 17:38Gyorgy RethyNew Issue
12-12-2012 17:38Gyorgy RethySource (company - Author) => L.M.Ericsson
12-12-2012 17:42Gyorgy RethyNote Added: 0011250
12-12-2012 17:42Gyorgy RethyStatusnew => closed
12-12-2012 17:42Gyorgy RethyResolutionopen => fixed
12-12-2012 17:42Gyorgy RethyFixed in Version => Edition 4.5.1
12-12-2012 17:42Gyorgy RethyTarget Version => Edition 4.5.1
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011250) +
+ Gyorgy Rethy    +
+ 12-12-2012 17:42    +
+ 		+ + + + +
+ Implemented in the draft as proposed
+
+ + diff --git a/docs/mantis/CR6386.md b/docs/mantis/CR6386.md new file mode 100644 index 0000000000000000000000000000000000000000..3cb61886d4a814fa957312a5632a27a9e989a6f5 --- /dev/null +++ b/docs/mantis/CR6386.md @@ -0,0 +1,63 @@ + + + + + + + + + + + + + 0006386: Add the new extensions to the informative references - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 07: Using ASN.1 with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006386Part 07: Using ASN.1 with TTCN-3Editorialpublic19-12-2012 13:5119-12-2012 14:09
ReporterGyorgy Rethy 
Assigned To 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.5.1 (published 2013-04)Fixed in Versionv4.5.1 (published 2013-04) 
Clause Reference(s)2.2
Source (company - Author)L.M.Ericsson
Summary0006386: Add the new extensions to the informative references
DescriptionTTCN-3 extensions are listed in the informative references clause because they may define new keywords that has to be appended with an "_". New ones published by ETSI has to be added.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
19-12-2012 13:51Gyorgy RethyNew Issue
19-12-2012 13:51Gyorgy RethyClause Reference(s) => 2.2
19-12-2012 13:51Gyorgy RethySource (company - Author) => L.M.Ericsson
19-12-2012 14:09Gyorgy RethyNote Added: 0011291
19-12-2012 14:09Gyorgy RethyStatusnew => closed
19-12-2012 14:09Gyorgy RethyResolutionopen => fixed
19-12-2012 14:09Gyorgy RethyFixed in Version => Edition 4.5.1
19-12-2012 14:09Gyorgy RethyTarget Version => Edition 4.5.1
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011291) +
+ Gyorgy Rethy    +
+ 19-12-2012 14:09    +
+ 		+ + + + +
+ Implemented in draft V4.4.2
+
+ + diff --git a/docs/mantis/CR6387.md b/docs/mantis/CR6387.md new file mode 100644 index 0000000000000000000000000000000000000000..d3e723ed08de969766e78fedb0f81a80c485f51b --- /dev/null +++ b/docs/mantis/CR6387.md @@ -0,0 +1,63 @@ + + + + + + + + + + + + + 0006387: Add the new extensions to the informative references - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006387Part 09: Using XML with TTCN-3Editorialpublic19-12-2012 14:0219-12-2012 14:09
ReporterGyorgy Rethy 
Assigned To 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.5.1 (published 2013-04)Fixed in Versionv4.5.1 (published 2013-04) 
Clause Reference(s)2.2
For STF discussion
Source (company - Author)L.M.Ericsson
Summary0006387: Add the new extensions to the informative references
DescriptionTTCN-3 extensions are listed in the informative references clause because they may define new keywords that has to be appended with an "_". New ones published by ETSI has to be added.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
19-12-2012 14:02Gyorgy RethyNew Issue
19-12-2012 14:02Gyorgy RethyClause Reference(s) => 2.2
19-12-2012 14:02Gyorgy RethySource (company - Author) => L.M.Ericsson
19-12-2012 14:09Gyorgy RethyNote Added: 0011290
19-12-2012 14:09Gyorgy RethyStatusnew => closed
19-12-2012 14:09Gyorgy RethyResolutionopen => fixed
19-12-2012 14:09Gyorgy RethyFixed in Version => Edition 4.5.1
19-12-2012 14:09Gyorgy RethyTarget Version => Edition 4.5.1
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011290) +
+ Gyorgy Rethy    +
+ 19-12-2012 14:09    +
+ 		+ + + + +
+ Implemented in draft V4.4.2
+
+ + diff --git a/docs/mantis/CR6388.md b/docs/mantis/CR6388.md new file mode 100644 index 0000000000000000000000000000000000000000..f54c212efe7b9ab0bde51d425b84179fd8e51895 --- /dev/null +++ b/docs/mantis/CR6388.md @@ -0,0 +1,63 @@ + + + + + + + + + + + + + 0006388: Add the new extensions to the informative references - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 08: Using IDL with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006388Part 08: Using IDL with TTCN-3Editorialpublic19-12-2012 14:1419-12-2012 14:19
ReporterGyorgy Rethy 
Assigned To 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.5.1 (published 2013-04)Fixed in Versionv4.5.1 (published 2013-04) 
Clause Reference(s)2.2
Source (company - Author)L.M.Ericsson
Summary0006388: Add the new extensions to the informative references
DescriptionTTCN-3 extensions are listed in the informative references clause because they may define new keywords that has to be appended with an "_". New ones published by ETSI has to be added.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
19-12-2012 14:14Gyorgy RethyNew Issue
19-12-2012 14:14Gyorgy RethyClause Reference(s) => 2.2
19-12-2012 14:14Gyorgy RethySource (company - Author) => L.M.Ericsson
19-12-2012 14:19Gyorgy RethyNote Added: 0011292
19-12-2012 14:19Gyorgy RethyStatusnew => closed
19-12-2012 14:19Gyorgy RethyResolutionopen => fixed
19-12-2012 14:19Gyorgy RethyFixed in Version => Edition 4.5.1
19-12-2012 14:19Gyorgy RethyTarget Version => Edition 4.5.1
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011292) +
+ Gyorgy Rethy    +
+ 19-12-2012 14:19    +
+ 		+ + + + +
+ Implemented in draft V4.4.2
+
+ + diff --git a/docs/mantis/CR6389.md b/docs/mantis/CR6389.md new file mode 100644 index 0000000000000000000000000000000000000000..cbfd9d9d08bff87aec9c90151a7f1b15fc5f9051 --- /dev/null +++ b/docs/mantis/CR6389.md @@ -0,0 +1,358 @@ + + + + + + + + + + + + + 0006389: Variant overwriting rules are not correct - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006389Part 09: Using XML with TTCN-3Technicalpublic21-12-2012 10:5513-12-2016 16:21
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.5.1 (published 2013-04) 
Target Versionv4.8.1 (published 2017-05)Fixed in Versionv4.8.1 (published 2017-05) 
Clause Reference(s)Part-9
For STF discussion
Source (company - Author)L.M.Ericsson
Summary0006389: Variant overwriting rules are not correct
DescriptionThis CR was created to handle the Part-9 part of CR 6233 separately from CR6233 itself.
+
+Clause 27.1.2.1 paragraph one specifies that
+• a variant attribute overwrites an current variant attribute according to the rules defined in clause 27.1.2;
+
+However this rule, if applied, would cause problems for XSD to TTCN-3 mapping, where the encoding instructions applied to a type (e.g. XSD:decimal") and to a field this type (e.g. "name as...") shall apply at the same time. But, of course, several enoding instructions may apply to a given field as well.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
parent of 0006798closed Kristóf Szabados Part 09: Using XML with TTCN-3 TTCN-3 Alias_or_Synonym Type Def. of an XSD Type 
child of 0006233closed Ina Schieferdecker Part 01: TTCN-3 Core Language Variant overwriting rules are not correct 
Attached Filesdocx CR6389.docx (152,606) 24-09-2015 10:33
http://oldforge.etsi.org/mantis/file_download.php?file_id=3277&type=bug
docx CR6389_v2.docx (141,398) 18-11-2016 11:09
http://oldforge.etsi.org/mantis/file_download.php?file_id=3569&type=bug
docx CR6389_v3.docx (141,126) 18-11-2016 12:55
http://oldforge.etsi.org/mantis/file_download.php?file_id=3573&type=bug
Issue History
Date ModifiedUsernameFieldChange
21-12-2012 10:55Gyorgy RethyNew Issue
21-12-2012 10:55Gyorgy RethyStatusnew => assigned
21-12-2012 10:55Gyorgy RethyAssigned To => Gyorgy Rethy
21-12-2012 10:55Gyorgy RethyClause Reference(s) => Part-9
21-12-2012 10:55Gyorgy RethySource (company - Author) => L.M.Ericsson
21-12-2012 10:55Gyorgy RethyIssue generated from: 0006233
21-12-2012 10:55Gyorgy RethyRelationship addedchild of 0006233
21-12-2012 10:58Gyorgy RethyProjectPart 01: TTCN-3 Core Language => Part 09: Using XML with TTCN-3
14-05-2013 15:27Gyorgy RethyTarget Version => Edition 4.1.1 Published 2009-06-02
14-05-2013 15:29Gyorgy RethyTarget VersionEdition 4.1.1 Published 2009-06-02 => v4.6.1 (published 2015-06)
11-07-2013 10:43Gyorgy RethyStatusassigned => confirmed
11-07-2013 10:43Gyorgy RethyStatusconfirmed => assigned
08-04-2014 17:06Gyorgy RethyProduct Version => v4.5.1 (published 2013-04)
08-04-2014 17:06Gyorgy RethyTarget Versionv4.6.1 - VOID => v4.6.1 (published 2015-06)
06-10-2014 14:14Gyorgy RethyPrioritynormal => high
04-11-2014 15:25Gyorgy RethyRelationship addedparent of 0006798
06-11-2014 10:39Gyorgy RethyAssigned ToGyorgy Rethy => Tomas Urban
06-11-2014 10:40Gyorgy RethyTarget Versionv4.6.1 (published 2015-06) => v4.7.1 (published 2016-07)
06-11-2014 15:04Tomas UrbanNote Added: 0012471
06-11-2014 15:16Tomas UrbanNote Edited: 0012471bug_revision_view_page.php?bugnote_id=12471#r100
06-11-2014 15:21Tomas UrbanNote Added: 0012476
06-11-2014 15:21Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
23-09-2015 16:37Gyorgy RethyAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
24-09-2015 10:33Jacob Wieland - SpirentFile Added: CR6389.docx
24-09-2015 10:34Jacob Wieland - SpirentNote Added: 0013284
24-09-2015 10:34Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
24-09-2015 10:34Jacob Wieland - SpirentStatusassigned => confirmed
03-11-2015 10:33Gyorgy RethyNote Added: 0013459
03-11-2015 10:33Gyorgy RethyStatusconfirmed => assigned
07-01-2016 08:52Gyorgy RethyPriorityhigh => normal
18-07-2016 14:50Jens GrabowskiAssigned ToGyorgy Rethy => Kristóf Szabados
04-08-2016 11:52Kristóf SzabadosNote Added: 0014044
17-08-2016 11:42Jacob Wieland - SpirentTarget Versionv4.7.1 (published 2016-07) => v4.8.1 (published 2017-05)
18-11-2016 11:09Kristóf SzabadosFile Added: CR6389_v2.docx
18-11-2016 11:09Kristóf SzabadosNote Added: 0014334
18-11-2016 11:28Kristóf SzabadosAssigned ToKristóf Szabados => Jacob Wieland - Spirent
18-11-2016 11:28Kristóf SzabadosNote Added: 0014338
18-11-2016 12:55Kristóf SzabadosFile Added: CR6389_v3.docx
18-11-2016 12:59Kristóf SzabadosStatusassigned => resolved
18-11-2016 12:59Kristóf SzabadosFixed in Version => v4.8.1 (published 2017-05)
18-11-2016 12:59Kristóf SzabadosResolutionopen => fixed
18-11-2016 12:59Kristóf SzabadosAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
13-12-2016 16:21Gyorgy RethyNote Added: 0014427
13-12-2016 16:21Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0012471) +
+ Tomas Urban    +
+ 06-11-2014 15:04    +
(edited on: 06-11-2014 15:16)
+ 		+ + + + +
+ Proposal: Formalize the rules that are in fact already in use in part 9 by a couple of changes in part 1. New syntax is required for some of the specific rules.
+
+1. Rules for multiple occurences of attributes:
+Attributes are represented by a single string on TCI level (with the exception of the extension attribute which is a string array). It is currently not entirely obvious what should happen if there are several attributes of the same kind, but I believe that most tools concatenate them. In order to formalize the rules I propose the following changes:
+a. The encode, display and optional attribute can occur at most once
+b. The variant and extension attribute occurrence count is not limited
+c. If there is more than 1 attribute of the same type, all attributes shall have the same override setting (either override present or missing). E.g. type integer I with { variant "A"; variant(override) "B" } shall produce an error.
+d. Change TCI so that it supports string array for variants. The existing variant support shall be kept for backward compatibility reasons. In case of multiple variants, it should contain concatenation of all variant attributes separated by semicolons.
+
+2. Rule for named variants:
+It should be possible to create a named variant attribute in the following way:
+type integer I with
+{
+   variant["EncodingProperty1"] "EncodingPropertyValue"
+   variant["EncodingProperty2"] "EncodingPropertyValue"
+}
+
+This way we can formalize overwriting of some encoding properties while others are kept intact:
+
+type I I2 with
+{
+   variant["EncodingProperty2"] "NewEncodingPropertyValue"
+}
+// only the EncodingProperty2 changes, EncodingProperty1 retains its value
+
+It should be possible to disable inherited named variants too:
+type I I3 with
+{
+   variant["EncodingProperty2"] -
+}
+// the EncodingProperty2 disappears, only the EncodingProperty1 remains
+
+In TCI, the named variant attribute is interpretted as VariantAttributeName ":" VariantAttributeValue (e.g. "EncodingProperty1: EncodingPropertyValue")
+
+Almost all XSD-based attributes are of this kind, just using a different syntax. The existing syntax of XSD encoding instructions would have to be adapted to the proposed named attribute syntax. While not backward compatible, this type of change is not very dangerous. First, the existing test suites will still compile since the attributes have no impact on TTCN-3 code itself and since most of TTCN-3 tools generate the codecs internally, the attributes don't influence the process significantly.
+
+Example of possible transformation of XSD encoding instruction:
+Current syntax: variant "elementFormQualified"
+New syntax: variant["elementForm"] "Qualified"
+
+3. Local attributes
+Some XSD encoding instructions are not intended to be inherited or applied to sub-fields, e.g. the "name as capitalized" variant. This could be indicated by a private keyword:
+
+type record Employee
+{
+   XSD.String name,
+   ...
+} with { private variant["Name as"] "capitalized" }
+
+
+
+
+
+ + + + + + + + + + +
+ (0012476) +
+ Tomas Urban    +
+ 06-11-2014 15:21    +
+ 		+ + + + +
+ This issue is a complicated ones and I propose to postpone it to the next year.
+
+
+
+ + + + + + + + + + +
+ (0013284) +
+ Jacob Wieland - Spirent    +
+ 24-09-2015 10:34    +
+ 		+ + + + +
+ please review the uploaded solution proposal
+
+
+
+ + + + + + + + + + +
+ (0013459) +
+ Gyorgy Rethy    +
+ 03-11-2015 10:33    +
+ 		+ + + + +
+ I think an "Overwriting rule" part should be added to each encoding instruction to clause B, between the "Applicable to (TTCN-3)" and the "Description" parts.
+
+
+
+ + + + + + + + + + +
+ (0014044) +
+ Kristóf Szabados    +
+ 04-08-2016 11:52    +
+ 		+ + + + +
+ I believe it would be a good idea to state that this applies only to certain encodings (XML).
+
+The described behaviour differs from the one in the core language.
+Without the restriction on the encoding, no tool could claim to support both the core and part9 at the same time.
+
+
+
+ + + + + + + + + + +
+ (0014334) +
+ Kristóf Szabados    +
+ 18-11-2016 11:09    +
+ 		+ + + + +
+ Hopefully easier to understand like this
+
+
+
+ + + + + + + + + + +
+ (0014338) +
+ Kristóf Szabados    +
+ 18-11-2016 11:28    +
+ 		+ + + + +
+ please check the changes
+
+
+
+ + + + + + + + + + +
+ (0014427) +
+ Gyorgy Rethy    +
+ 13-12-2016 16:21    +
+ 		+ + + + +
+ Added to draft V4.7.2
+
+ + diff --git a/docs/mantis/CR6390.md b/docs/mantis/CR6390.md new file mode 100644 index 0000000000000000000000000000000000000000..a7b5257757e985de6df94ca597202b685122ff5d --- /dev/null +++ b/docs/mantis/CR6390.md @@ -0,0 +1,63 @@ + + + + + + + + + + + + + 0006390: Update the package to the latest versions of ES 201 873 parts - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Behaviour Types (ES 202 785)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006390Ext Pack: Behaviour Types (ES 202 785)Editorialpublic21-12-2012 15:4921-12-2012 16:01
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv1.3.1 (published 2013-05)Fixed in Versionv1.3.1 (published 2013-05) 
Clause Reference(s)all
Source (company - Author)L.M.Ericsson
Summary0006390: Update the package to the latest versions of ES 201 873 parts
DescriptionThe package compatibility (including its content and BNF) shall be updated to the latest versions of ES 201 873: V4.5.1 for P1 and P5-P10 and V4.4.1 for P4.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
21-12-2012 15:49Gyorgy RethyNew Issue
21-12-2012 15:49Gyorgy RethyClause Reference(s) => all
21-12-2012 15:49Gyorgy RethySource (company - Author) => L.M.Ericsson
21-12-2012 15:49Gyorgy RethyTS version => n/a
21-12-2012 16:01Gyorgy RethyNote Added: 0011312
21-12-2012 16:01Gyorgy RethyAssigned To => Gyorgy Rethy
21-12-2012 16:01Gyorgy RethyStatusnew => closed
21-12-2012 16:01Gyorgy RethyResolutionopen => fixed
21-12-2012 16:01Gyorgy RethyFixed in Version => v1.3.1 (ongoing)
21-12-2012 16:01Gyorgy RethyTarget Version => v1.3.1 (ongoing)
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011312) +
+ Gyorgy Rethy    +
+ 21-12-2012 16:01    +
+ 		+ + + + +
+ Implemented in draft V1.2.2
+
+ + diff --git a/docs/mantis/CR6411.md b/docs/mantis/CR6411.md new file mode 100644 index 0000000000000000000000000000000000000000..d903d580a05d68dd20c23054d2f506b512196dab --- /dev/null +++ b/docs/mantis/CR6411.md @@ -0,0 +1,745 @@ + + + + + + + + + + + + + 0006411: Example to clarify Modified Template semantics - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006411Part 01: TTCN-3 Core LanguageClarificationpublic16-01-2013 11:0323-09-2014 16:01
ReporterThilo Lauer 
Assigned ToGyorgy Rethy 
PriorityurgentSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.4.1 (published 2012-04) 
Target Versionv4.7.1 (published 2015-06)Fixed in Versionv4.6.2 (interim 2014) 
Clause Reference(s)15.5 Modified templates
Source (company - Author)Devoteam - Thilo Lauer
Summary0006411: Example to clarify Modified Template semantics
DescriptionPlease add this example as clarification of the semantic of modified templates for of-type-fields:
+
+type record of integer MyIntegerList_Type;
+
+type record MyRecord_Type {
+  MyIntegerList_Type intList
+};
+
+template (value) MyRecord_Type cs_MyRecord := { intList := {1, 2, 3} };
+template (value) MyRecord_Type cds_MyRecordModified1 modifies cs_MyRecord :=
+{ intList := { 42 } };
+template (value) MyRecord_Type cds_MyRecordModified2 modifies cs_MyRecord :=
+{ intList := { [0] := 42 } };
+
+// result:
+// cds_MyRecordModified1.intList has value : {42}
+// cds_MyRecordModified2.intList has value : {42, 2, 3}
+
+
+
Steps To Reproduce
Additional InformationOur previous interpretation of the semantics of modified templates was, that we are in a modification context, where values are modified, but not completely replaced, e.g.:
+
+template (value) MyRecord_Type cds_MyRecordModified1 modifies cs_MyRecord :=
+{ intList := { 42 } };
+// results also to:
+// cds_MyRecordModified1.intList has value : {42, 2, 3}
+
+But meanwhile we have changed our semantic to:
+// cds_MyRecordModified1.intList has value : {42}
TagsNo tags attached.
Relationships
related to 0006429closed Gyorgy Rethy modifies of 'record of' fields still seems to be ambiguous 
Attached Files? modified_templates_4ETSI.ttcn (2,895) 27-08-2013 08:41
http://oldforge.etsi.org/mantis/file_download.php?file_id=2855&type=bug
doc CR6429_CR6411_resolution_v1.doc (88,576) 28-08-2013 10:34
http://oldforge.etsi.org/mantis/file_download.php?file_id=2864&type=bug
doc CR6429_CR6411_resolution_v2.doc (88,576) 29-08-2013 09:57
http://oldforge.etsi.org/mantis/file_download.php?file_id=2873&type=bug
docx CR6429_CR6411_resolution_v2-2.docx (60,220) 19-06-2014 17:01
http://oldforge.etsi.org/mantis/file_download.php?file_id=3064&type=bug
Issue History
Date ModifiedUsernameFieldChange
16-01-2013 11:03Thilo LauerNew Issue
16-01-2013 11:03Thilo LauerClause Reference(s) => 15.5 Modified templates
16-01-2013 11:03Thilo LauerSource (company - Author) => Devoteam - Thilo Lauer
08-07-2013 15:50Jens GrabowskiStatusnew => assigned
08-07-2013 15:50Jens GrabowskiAssigned To => Gyorgy Rethy
08-07-2013 15:51Jens GrabowskiRelationship addedrelated to 0006429
08-07-2013 18:17Gyorgy RethyTarget Version => v4.6.1 (published 2014-06)
12-07-2013 14:48Gyorgy RethyNote Added: 0011579
12-07-2013 14:50Gyorgy RethyNote Edited: 0011579
26-08-2013 12:19Gyorgy RethyNote Added: 0011591
26-08-2013 12:20Gyorgy RethyNote Edited: 0011591
26-08-2013 14:12Jacob Wieland - SpirentNote Added: 0011596
26-08-2013 17:10Gyorgy RethyFile Added: modified_templates_4ETSI.ttcn
26-08-2013 17:10Gyorgy RethyNote Added: 0011604
27-08-2013 08:40Gyorgy RethyFile Deleted: modified_templates_4ETSI.ttcn
27-08-2013 08:41Gyorgy RethyFile Added: modified_templates_4ETSI.ttcn
27-08-2013 09:13Gyorgy RethyNote Added: 0011605
27-08-2013 10:45Jacob Wieland - SpirentNote Added: 0011606
28-08-2013 10:34Gyorgy RethyFile Added: CR6429_CR6411_resolution_v1.doc
28-08-2013 10:35Gyorgy RethyNote Added: 0011615
28-08-2013 10:35Gyorgy RethyAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
28-08-2013 11:30Jacob Wieland - SpirentNote Added: 0011623
28-08-2013 11:31Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
28-08-2013 11:31Jacob Wieland - SpirentStatusassigned => confirmed
29-08-2013 09:57Gyorgy RethyNote Added: 0011632
29-08-2013 09:57Gyorgy RethyFile Added: CR6429_CR6411_resolution_v2.doc
29-08-2013 09:57Gyorgy RethyStatusconfirmed => assigned
29-08-2013 09:57Gyorgy RethyAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
29-08-2013 09:58Gyorgy RethyNote Edited: 0011632
29-08-2013 14:14Jacob Wieland - SpirentNote Added: 0011639
29-08-2013 14:14Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
30-08-2013 09:42Gyorgy RethyNote Added: 0011649
30-08-2013 09:42Gyorgy RethyAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
30-08-2013 09:43Gyorgy RethyStatusassigned => confirmed
30-08-2013 13:57Jacob Wieland - SpirentNote Added: 0011662
07-10-2013 12:27Jacob Wieland - SpirentStatusconfirmed => assigned
07-10-2013 12:27Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
08-10-2013 16:23Gyorgy RethyNote Added: 0011706
08-10-2013 16:23Gyorgy RethyAssigned ToGyorgy Rethy => Jens Grabowski
10-10-2013 13:30Jacob Wieland - SpirentNote Added: 0011751
10-10-2013 13:32Jacob Wieland - SpirentNote Added: 0011752
08-04-2014 16:50Gyorgy RethyTarget Versionv4.6.1 (published 2014-06) => v4.7.1 (published 2015-06)
19-06-2014 14:29Gyorgy RethyAssigned ToJens Grabowski => Axel Rennoch
19-06-2014 14:30Gyorgy RethyNote Added: 0012146
19-06-2014 17:01Axel RennochFile Added: CR6429_CR6411_resolution_v2-2.docx
19-06-2014 17:02Axel RennochAssigned ToAxel Rennoch => Gyorgy Rethy
19-06-2014 17:03Axel RennochNote Added: 0012160
19-06-2014 17:03Axel RennochStatusassigned => confirmed
27-06-2014 13:44Gyorgy RethyPrioritynormal => urgent
23-09-2014 16:01Gyorgy RethyNote Added: 0012216
23-09-2014 16:01Gyorgy RethyStatusconfirmed => closed
23-09-2014 16:01Gyorgy RethyResolutionopen => fixed
23-09-2014 16:01Gyorgy RethyFixed in Version => v4.6.2 (interim 2014)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011579) +
+ Gyorgy Rethy    +
+ 12-07-2013 14:48    +
(edited on: 12-07-2013 14:50)
+ 		+ + + + +
+ Examples in the dscription part are correct. The CR is handled together with CR6429, please see the resolution there.
+
+
+
+
+
+ + + + + + + + + + +
+ (0011591) +
+ Gyorgy Rethy    +
+ 26-08-2013 12:19    +
(edited on: 26-08-2013 12:20)
+ 		+ + + + +
+ Yes Thilo, your new interpretation is correct.
+
+In general, the rules of modifying record/set-s and record_of/set_of-s is underspecified. What is defined by the text or by an example:
+
+- in records/sets: the fields specified are replaced, fields not specified are left unchanged; shall be true for both assignment and list notations as the text doesn't specify different rules for different types of notations ($15.5 semantic description 2nd paragraph, and for the assignment notation: example 1).
+examples:
+type record R { integer a, integer b }
+template R t_r1 := { a:= 1, b:= 2 }
+template R t_r2 modifies t_r1 := { a:= 42 } // results { 42, 2 }
+template R t_r3 modifies t_r1 := { a:= 42, b:= - } // results { 42, 2 }
+template R t_r4 modifies t_r1 := { 42 } // results { 42, 2 }
+template R t_r5 modifies t_r1 := { 42,- } // results { 42, 2 }
+template R t_r6 modifies t_r1 := { b:= 42 } // results { 1, 42 }
+template R t_r7 modifies t_r1 := { -,42 } // results { 1, 42 }
+
+All of the above examples comply with the existing text, but examples for list notation are missing.
+
+-in record_of/set_of-s:
+Rule is given explicitly to change individual elements: $15.5 semantic description 3rd paragraph, example 2.
+No explicit rule is given when complete record_of/set_of is defined using list notation (current text: "When individual values of a modified template or a modified template field of record of type wished to be changed..." can be understood as a hint that in other cases the whole value is replaced, but this is not formulated explicitly).
+
+In this case, I think both CR6411 and CR6429 are correct, a "complete" record/set, i.e. without index notation should replace the whole parent record/set_of, otherwise there is no other way to replace the whole parent value.
+
+However, this raises the question of t_r4 above. For consistency this should be the rule for records/sets as well: in both cases list notation should be considered as a complete value, any kind of notation with ":=" changes just the identified fields or elements only.
+But this would be a BACKWARD INCOMPATIBLE CHANGE that needs to be agreed with users and tool vendors!
+
+- no explicit rule is given for other structured types: union and enumerated: the rule is trivial as they always contain one chosen field/enum.value, this will simply replace its parent.
+
+
+
+
+
+ + + + + + + + + + +
+ (0011596) +
+ Jacob Wieland - Spirent    +
+ 26-08-2013 14:12    +
+ 		+ + + + +
+ Since there is no clarification required or needed for record/set types (without of), I don't think that we should introduce a backward incompatible change for them.
+
+
+
+ + + + + + + + + + +
+ (0011604) +
+ Gyorgy Rethy    +
+ 26-08-2013 17:10    +
+ 		+ + + + +
+ See examples in modified_templates_4ETSI.ttcn
+
+
+
+ + + + + + + + + + +
+ (0011605) +
+ Gyorgy Rethy    +
+ 27-08-2013 09:13    +
+ 		+ + + + +
+ In this case at least we shall be clear and explicit about the semantics when using different kind of notations and shall explicitly notify (warn) the users about the semantic difference between the record/set and ~of-s when using a value list notation.
+
+
+
+ + + + + + + + + + +
+ (0011606) +
+ Jacob Wieland - Spirent    +
+ 27-08-2013 10:45    +
+ 		+ + + + +
+ Agreed, this should be done in a NOTE (and the example, I guess)
+
+
+
+ + + + + + + + + + +
+ (0011615) +
+ Gyorgy Rethy    +
+ 28-08-2013 10:35    +
+ 		+ + + + +
+ Draft resolution text is in CR6429_CR6411_resolution_v1.doc.
+
+Pls. review.
+
+
+
+ + + + + + + + + + +
+ (0011623) +
+ Jacob Wieland - Spirent    +
+ 28-08-2013 11:30    +
+ 		+ + + + +
+ I still have issue with the formulation
+
+"then the specified matching symbol replaces the one specified in the parent template"
+
+because what we actually mean is that it *modifies* the matching symbol in the parent template, i.e. replacement only occurs for non-structured and enumerated types while for structured, replacement means recursive modification.
+
+Since modification for non-structured and enumerated types is already defined as replacement, I think we are safe to change this part to:
+
+"then the specified matching symbol modifies the one specified in the parent template"
+
+
+
+ + + + + + + + + + +
+ (0011632) +
+ Gyorgy Rethy    +
+ 29-08-2013 09:57    +
(edited on: 29-08-2013 09:58)
+ 		+ + + + +
+ Modifies is a dangerous word as it can be misunderstood as modifying the matching symbol itself, e.g.
+template MyRecord t_base := { a:= true, b:=(1,2,3,4)}
+template MyRecord t_mod modifies t_base := { b:=(5,6,7,8)}
+//could be misinterpreted as t_mod containing {true, (1,2,3,4,5,6,7,8)},
+//as it just modifies field b of t_base, not replaces it...
+
+
+I propose rather to specify precisely *what* is replaced: replaces the one specified in the corresponding field of the parent template.
+
+See CR6429_CR6411_resolution_v2.doc
+
+
+
+
+
+ + + + + + + + + + +
+ (0011639) +
+ Jacob Wieland - Spirent    +
+ 29-08-2013 14:14    +
+ 		+ + + + +
+ Still, I don't understand the text in the way which corresponds to my understanding of the intention of the text.
+
+The sentence
+
+"For templates, template fields and elements of record and set types, if a record or set field and its corresponding matching symbol is specified in the modified template, then the specified matching symbol replaces the one specified in the corresponding field of the parent template".
+
+for me implies, that if the "matching symbol" is an underspecified value which is a field assignment notation, this underspecified value would *replace* the one in the parent and not simply *modify* those fields in the parent field which are specified (recursively).
+
+The only time, real replacement actually occurs is for non-compound-expression matching mechanisms.
+
+
+
+ + + + + + + + + + +
+ (0011649) +
+ Gyorgy Rethy    +
+ 30-08-2013 09:42    +
+ 		+ + + + +
+ The sentence is talking about one single field of a record or set. If this field is specified AND no dash on the RHS, the content of the given field replaces the content of the same field in the parent template.
+
+Actually, reading through the sentence several times during CR resolution, I cannot read it another way. So, pls. formulate a sentence you think expresses we want to say here.
+
+(PS: maybe the beginning of the sentence is too complicated, it could be just ""For record and set types, if a record or set field and its corresponding matching symbol ..."
+
+
+
+ + + + + + + + + + +
+ (0011662) +
+ Jacob Wieland - Spirent    +
+ 30-08-2013 13:57    +
+ 		+ + + + +
+ The problem is, if the "single field of a record or set" is again a structured expression. Then *replacement* (which normally means fully replacing the old with the new, i.e. not keeping anything from the old) is in actuality meant as *modification* for the field, i.e. only those fields in the sub-structure of the field are modifying the fields of the sub-structure of the parent field.
+
+In my opinion, using *modifies* (or *recursively modifies*) instead of *replaces* makes the issue totally clear as for non-structured values, *modifies* is already defined as full replacement (in the paragraph before).
+
+
+
+ + + + + + + + + + +
+ (0011706) +
+ Gyorgy Rethy    +
+ 08-10-2013 16:23    +
+ 		+ + + + +
+ Assigned to Jens for proof-reading -> CR6429_CR6411_resolution_v2.doc
+
+
+
+ + + + + + + + + + +
+ (0011751) +
+ Jacob Wieland - Spirent    +
+ 10-10-2013 13:30    +
+ 		+ + + + +
+ Somehow, the more often I read the description/definition of the modification algorithm, the less I can see the connection to my understanding of the modifies construct (and what the examples describe).
+
+In the algorithm, always replacement is used where modification is meant. Since these are semantically different things, I think we have to clarify this so that the actual algorithm is reflected.
+
+Basically, there are the following cases in this recursive algorithm:
+0) a field to be modified is not initialized in the parent -> replacement
+
+1) a matching symbol which is not a compound expression shall modify an existing field in the parent -> replacement
+
+2) a compound expression shall modify an existing field in the parent
+-> recursion: the elements/fields of the compound expression modify their respective counterparts in the parent.
+
+For 2, there then are the special cases for list notation used for record of and set of fields regarding additional truncation of the parent.
+
+
+
+ + + + + + + + + + +
+ (0011752) +
+ Jacob Wieland - Spirent    +
+ 10-10-2013 13:32    +
+ 		+ + + + +
+ In the proposed resolution, there is a typo: corresping
+
+
+
+ + + + + + + + + + +
+ (0012146) +
+ Gyorgy Rethy    +
+ 19-06-2014 14:30    +
+ 		+ + + + +
+ STF discussion: assigned to Axel, together with 6429 to check which text reads more easily and unambiguously and add an example.
+
+
+
+ + + + + + + + + + +
+ (0012160) +
+ Axel Rennoch    +
+ 19-06-2014 17:03    +
+ 		+ + + + +
+ replace "matching symbol" by "matching mechanism" and correction of two typos
+
+
+
+ + + + + + + + + + +
+ (0012216) +
+ Gyorgy Rethy    +
+ 23-09-2014 16:01    +
+ 		+ + + + +
+ Added to master copy of V4.6.2
+
+ + diff --git a/docs/mantis/CR6412.md b/docs/mantis/CR6412.md new file mode 100644 index 0000000000000000000000000000000000000000..f80accae489a743a72c71d4dd2eba78b86da613f --- /dev/null +++ b/docs/mantis/CR6412.md @@ -0,0 +1,211 @@ + + + + + + + + + + + + + 0006412: system component shall be passed to functions with map/unmap statements - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006412Part 01: TTCN-3 Core LanguageTechnicalpublic16-01-2013 12:3928-08-2013 14:59
ReporterThilo Lauer 
Assigned ToIna Schieferdecker 
PrioritynormalSeveritymajorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.4.1 (published 2012-04) 
Target Versionv4.6.1 (published 2014-06)Fixed in Versionv4.6.1 (published 2014-06) 
Clause Reference(s)16.1 Functions
Source (company - Author)Devoteam - Thilo Lauer
Summary0006412: system component shall be passed to functions with map/unmap statements
DescriptionIf map/unmap statements are used in a function, then the system component should also be passed to this function,
+  (1) either as parameter
+  (2) or by using keyword system to define the function's system component.
+
+Let's assume the following component definitions:
+  type component UTRAN_PTC {
+    var UTRAN_Global_Type vc_UTRAN_Global;
+
+    port UTRAN_AM_PORT U_AM;
+    port UTRAN_TM_PORT U_TM;
+    port UTRAN_UM_PORT U_UM;
+    ...
+    port UTRAN_VNG_PORT U_VNG;
+    ...
+  };
+
+  type component UTRAN_SYSTEM {
+    port UTRAN_AM_PORT S_U_AM;
+    port UTRAN_TM_PORT S_U_TM;
+    port UTRAN_UM_PORT S_U_UM;
+    ...
+    port UTRAN_VNG_PORT S_U_VNG;
+  };
+
+Example:
+The defintition of function f_UTRAN_PTC_Map below can generally be called in the context of different test cases
+with different system components (defining different system ports).
+Therefore if this function is defined as shown below, it can currently not be decided at compile time
+if the system component actually has the system ports used in the function's map statements:
+
+  function f_UTRAN_PTC_Map(UTRAN_PTC p_Utran)
+  {
+    map(p_Utran:U_AM, system:S_U_AM);
+    map(p_Utran:U_TM, system:S_U_TM);
+    map(p_Utran:U_UM, system:S_U_UM);
+    // ... further map statements
+
+    if (f_GetTestcaseAttrib_Qbased_Rsrq(testcasename())) {
+      map(p_Utran:U_VNG, system:S_U_VNG);
+    }
+  }
+
+Given the function definition above, errors with system port mappings can only be detected at runtime.
+
+
+To be able to do this checks at compile time, we suggest ...
+============================================================
+1.) either to pass the system component additionally as parameter:
+    i.e. to change the function definition in the test suite to:
+  
+  function f_UTRAN_PTC_Map(UTRAN_PTC p_Utran, UTRAN_SYSTEM sys_Utran)
+  // *** added parameter: UTRAN_SYSTEM sys_Utran ***
+  {
+    map(p_Utran:U_AM, sys_Utran:S_U_AM);
+    map(p_Utran:U_TM, sys_Utran:S_U_TM);
+    map(p_Utran:U_UM, sys_Utran:S_U_UM);
+    // ... further map statements
+    
+    if (f_GetTestcaseAttrib_Qbased_Rsrq(testcasename())) {
+      map(p_Utran:U_VNG, sys_Utran:S_U_VNG);
+    }
+  }
+
+  // function call:
+  f_UTRAN_PTC_Map(p_Utran, system);
+  // *** keyword "system" passed as actual component parameter value here ***
+
+  
+2.) or to change the TTCN-3 syntax for function definitions as shown below:
+
+  function f_UTRAN_PTC_Map(UTRAN_PTC p_Utran) system UTRAN_SYSTEM
+  // *** system UTRAN_SYSTEM added ***
+  {
+    ...
+  }
+
+ 
+Solution 1.) requires a change in some ETSI/3GPP suites
+Solution 2.) requires a change in some ETSI/3GPP suites and in the TTCN-3 standard as well.
+
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0005922closed Ina Schieferdecker why strong typing is not used in map and unmap? 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
16-01-2013 12:39Thilo LauerNew Issue
16-01-2013 12:39Thilo LauerClause Reference(s) => 16.1 Functions
16-01-2013 12:39Thilo LauerSource (company - Author) => Devoteam - Thilo Lauer
18-01-2013 11:44Jacob Wieland - SpirentNote Added: 0011324
18-01-2013 11:44Jacob Wieland - SpirentRelationship addedrelated to 0005922
08-07-2013 15:48Jens GrabowskiStatusnew => assigned
08-07-2013 15:48Jens GrabowskiAssigned To => Jacob Wieland - Spirent
08-07-2013 18:16Gyorgy RethyTarget Version => v4.6.1 (published 2014-06)
11-07-2013 15:23Jacob Wieland - SpirentNote Added: 0011550
11-07-2013 15:23Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Ina Schieferdecker
11-07-2013 15:23Jacob Wieland - SpirentStatusassigned => confirmed
28-08-2013 14:58Ina SchieferdeckerNote Added: 0011626
28-08-2013 14:58Ina SchieferdeckerStatusconfirmed => resolved
28-08-2013 14:58Ina SchieferdeckerResolutionopen => fixed
28-08-2013 14:58Ina SchieferdeckerFixed in Version => v4.6.1 (published 2014-06)
28-08-2013 14:59Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011324) +
+ Jacob Wieland - Spirent    +
+ 18-01-2013 11:44    +
+ 		+ + + + +
+ A proposal for the solution of this issue can already be found in CR5922
+
+
+
+ + + + + + + + + + +
+ (0011550) +
+ Jacob Wieland - Spirent    +
+ 11-07-2013 15:23    +
+ 		+ + + + +
+ see proposal in 5922
+
+
+
+ + + + + + + + + + +
+ (0011626) +
+ Ina Schieferdecker    +
+ 28-08-2013 14:58    +
+ 		+ + + + +
+ Resolved together with 5922
+
+ + diff --git a/docs/mantis/CR6415.md b/docs/mantis/CR6415.md new file mode 100644 index 0000000000000000000000000000000000000000..80e9c898777d02ad41eed5257b6bf383d5078783 --- /dev/null +++ b/docs/mantis/CR6415.md @@ -0,0 +1,189 @@ + + + + + + + + + + + + + 0006415: Static PTC behaviour state between test cases - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Config & Deployment Support (ES 202 781)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006415Ext Pack: Config & Deployment Support (ES 202 781)Clarificationpublic24-01-2013 10:5126-12-2013 14:00
ReporterJanek Nikolajev 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv1.1.1 (published 2010-08) 
Target Versionv1.3.1 (published 2014-06)Fixed in Version 
Clause Reference(s)5.8
Source (company - Author)Janek
TS version1.1.1
Summary0006415: Static PTC behaviour state between test cases
DescriptionIn clause 5.8 "Executing test cases on static test configurations"
+It is not clear what should happen to running behaviour of static PTCs in case the test case ends.
+The question also applies to running timers.
+
+Should all running PTCs be implicitly stopped, or continue running between test cases?
+
+In case of timers(and component variables), the specification says: "They remain in the same state as when they were left after the creation
+of the static test configuration or after the termination of a previous test case".
+Does that mean that a running timer should continue running, but cannot change state to "timeout", since this will violate the same rule?
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR6415.doc (173,568) 29-11-2013 12:59
http://oldforge.etsi.org/mantis/file_download.php?file_id=2963&type=bug
Issue History
Date ModifiedUsernameFieldChange
24-01-2013 10:51Janek NikolajevNew Issue
24-01-2013 10:51Janek NikolajevClause Reference(s) => 5.8
24-01-2013 10:51Janek NikolajevSource (company - Author) => Janek
24-01-2013 10:51Janek NikolajevTS version => 1.1.1
25-03-2013 10:10Tomas UrbanNote Added: 0011340
08-07-2013 15:47Jens GrabowskiStatusnew => assigned
08-07-2013 15:47Jens GrabowskiAssigned To => Jens Grabowski
08-07-2013 18:16Gyorgy RethyTarget Version => v1.3.1 (published 2014-06)
28-11-2013 12:55Jacob Wieland - SpirentNote Added: 0011859
29-11-2013 12:55Jacob Wieland - SpirentFile Added: CR6415.doc
29-11-2013 12:59Jacob Wieland - SpirentFile Deleted: CR6415.doc
29-11-2013 12:59Jacob Wieland - SpirentFile Added: CR6415.doc
29-11-2013 13:02Jacob Wieland - SpirentNote Added: 0011870
29-11-2013 13:02Jacob Wieland - SpirentStatusassigned => confirmed
26-12-2013 13:59Jens GrabowskiNote Added: 0011905
26-12-2013 14:00Jens GrabowskiStatusconfirmed => closed
26-12-2013 14:00Jens GrabowskiResolutionopen => fixed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011340) +
+ Tomas Urban    +
+ 25-03-2013 10:10    +
+ 		+ + + + +
+ Having active SUT-related behaviour in between test cases is not a good idea. For that reason, I suppose that the simplest solution of the issue is to stop behaviour running on all parallel static components when MTC stops.
+
+Proposal:
+The current rule saying that "Furthermore, all non-static test components, non-static connections and all non static mappings shall be discarded." shall be changed to: "Furthermore, all behaviour running on parallel static components shall be implicitly stopped and non-static test components, non-static connections and all non static mappings shall be discarded."
+
+Regarding timers:
+The following rule shall be amended:
+"They remain in the same state as when they were left after the creation
+of the static test configuration or after the termination of a previous test case."
+-->
+"They remain in the same state as when they were left after the creation
+of the static test configuration or after the termination of a previous test case with exception of running timers which can change their state from running to timeout."
+
+
+
+ + + + + + + + + + +
+ (0011859) +
+ Jacob Wieland - Spirent    +
+ 28-11-2013 12:55    +
+ 		+ + + + +
+ I think the test components should be stopped. No behavior should be running between test cases. The SUT can still enqueue messages at the components' ports but they can at the earliest be processed during the course of the next testcases. The same is true for static mappings before the first testcase invocation on a static configuration.
+
+I a timer can continue running and change its internal state to timeout (i.e. be put in the timeout queue). Again, this state change can only be observed from an actually running behavior at the earliest during the next testcase.
+
+
+
+ + + + + + + + + + +
+ (0011870) +
+ Jacob Wieland - Spirent    +
+ 29-11-2013 13:02    +
+ 		+ + + + +
+ Re-affirmed that also for test cases on static configuration, all ptcs are stopped when the test case terminates (as for normal test cases). There is no behavior between test cases running.
+
+Also added that timers can time out even after the termination (but the timeout can only be observed in a following test case). Same for messages from the SUT to static ports.
+
+
+
+ + + + + + + + + + +
+ (0011905) +
+ Jens Grabowski    +
+ 26-12-2013 13:59    +
+ 		+ + + + +
+ Implemented as suggested.
+
+ + diff --git a/docs/mantis/CR6421.md b/docs/mantis/CR6421.md new file mode 100644 index 0000000000000000000000000000000000000000..602ddedfb030a5b7f65a6aa99b8757ab9117a1c9 --- /dev/null +++ b/docs/mantis/CR6421.md @@ -0,0 +1,278 @@ + + + + + + + + + + + + + 0006421: 6.2.13.2: Semantic error in Example 1 - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006421Part 01: TTCN-3 Core LanguageTechnicalpublic06-02-2013 11:4711-10-2013 11:46
ReporterAndras Kovacs 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.4.1 (published 2012-04) 
Target Versionv4.6.1 (published 2014-06)Fixed in Versionv4.6.1 (published 2014-06) 
Clause Reference(s)6.2.13.2
Source (company - Author)STF451 - Andras Kovacs
Summary0006421: 6.2.13.2: Semantic error in Example 1
DescriptionThe following quoted type definition of MyRecordSub4 is semantically incorrect, since the f1 field of MyRecord is left undefined:
+type MyRecord MyRecordSub4 (
+{ f2 := "user", f3 := "password" }, { f2 := "User", f3 := "Password" }
+)
+
+The suggested correction is either to add 'with { optional "implicit omit"}' attribute to the above type definition or to add f1:=* definitions for the f1 field.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR6421_resolution_v1.doc (75,264) 10-07-2013 18:03
http://oldforge.etsi.org/mantis/file_download.php?file_id=2823&type=bug
doc CR6421_resolution_v2.doc (76,288) 12-07-2013 10:50
http://oldforge.etsi.org/mantis/file_download.php?file_id=2844&type=bug
Issue History
Date ModifiedUsernameFieldChange
06-02-2013 11:47Andras KovacsNew Issue
06-02-2013 11:47Andras KovacsClause Reference(s) => 6.2.13.2
06-02-2013 11:47Andras KovacsSource (company - Author) => STF451 - Andras Kovacs
22-02-2013 11:28Jacob Wieland - SpirentNote Added: 0011329
26-02-2013 13:52Tomas UrbanNote Added: 0011331
28-02-2013 08:52Jacob Wieland - SpirentNote Added: 0011333
08-07-2013 15:46Jens GrabowskiStatusnew => assigned
08-07-2013 15:46Jens GrabowskiAssigned To => Gyorgy Rethy
08-07-2013 18:16Gyorgy RethyTarget Version => v4.6.1 (published 2014-06)
10-07-2013 17:12Gyorgy RethyNote Added: 0011518
10-07-2013 18:03Gyorgy RethyFile Added: CR6421_resolution_v1.doc
11-07-2013 08:33Gyorgy RethyNote Edited: 0011518
12-07-2013 09:36Gyorgy RethyAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
12-07-2013 09:36Gyorgy RethyStatusassigned => confirmed
12-07-2013 10:50Jacob Wieland - SpirentFile Added: CR6421_resolution_v2.doc
12-07-2013 10:51Jacob Wieland - SpirentNote Added: 0011570
12-07-2013 10:51Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
12-07-2013 10:51Jacob Wieland - SpirentStatusconfirmed => assigned
12-07-2013 10:51Jacob Wieland - SpirentStatusassigned => confirmed
12-07-2013 11:59Gyorgy RethyNote Added: 0011574
12-07-2013 12:01Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
12-07-2013 12:01Gyorgy RethyStatusconfirmed => resolved
12-07-2013 12:01Gyorgy RethyResolutionopen => fixed
11-10-2013 11:46Ina SchieferdeckerStatusresolved => closed
11-10-2013 11:46Ina SchieferdeckerNote Added: 0011766
11-10-2013 11:46Ina SchieferdeckerFixed in Version => v4.6.1 (published 2014-06)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011329) +
+ Jacob Wieland - Spirent    +
+ 22-02-2013 11:28    +
+ 		+ + + + +
+ No, the point of such subtyping (as far as I remember) was that only the restricted fields shall be mentioned and all others are implicitly defined as AnyElement for mandatory fields and AnyElementOrNone for optional fields.
+
+
+
+ + + + + + + + + + +
+ (0011331) +
+ Tomas Urban    +
+ 26-02-2013 13:52    +
+ 		+ + + + +
+ I am afraid that the problem is not in the example, but in the rule specified in the same chapter: "When constraining record of, set of, union and anytype types, all templates of the expanded list (i.e. after resolving the type references) shall be valid (i.e. complete) templates of the first parent type, except in the case of field assignment notations for constrained record or set types where the fields that are not explicitly present in the value notation are seen as containing Any for mandatory fields and AnyOrOmit for optional fields of the type."
+
+For some strange reason, record and set types are not mentioned in the beginning of this rule, efficiently restricting it to records and sets nested inside the currently listed types. This was probably not the intention. The sentence should be changed to: "When constraining record, set, record of, set of, union and anytype types, all templates...", in which case the rule can be applied to the MyRecordSub4 type, making all missing fields equal to AnyValueOrNone.
+
+The rule contains one more mistake too: AnyOrOmit is not a correct term and it should be replaced with AnyValueOrNone.
+
+
+
+ + + + + + + + + + +
+ (0011333) +
+ Jacob Wieland - Spirent    +
+ 28-02-2013 08:52    +
+ 		+ + + + +
+ I can agree with these editorial changes.
+
+
+
+ + + + + + + + + + +
+ (0011518) +
+ Gyorgy Rethy    +
+ 10-07-2013 17:12    +
(edited on: 11-07-2013 08:33)
+ 		+ + + + +
+ The example is correct, it is according to the last sentence of the 2nd paragraph; this paragraph was resulted from resolving CRs 5938 and 5262 together. The final text could be read as ambiguous, this could lead to the misunderstanding regarding the example. I propose to review and make consistent the text of the paragraph. See my proposal in CR6421_resolution_v1.doc.
+
+
+
+
+
+ + + + + + + + + + +
+ (0011570) +
+ Jacob Wieland - Spirent    +
+ 12-07-2013 10:51    +
+ 		+ + + + +
+ after careful reading, I've left the sub-types in there and just made some additions to make it more air-tight.
+
+
+
+ + + + + + + + + + +
+ (0011574) +
+ Gyorgy Rethy    +
+ 12-07-2013 11:59    +
+ 		+ + + + +
+ OK with me.
+
+
+
+ + + + + + + + + + +
+ (0011766) +
+ Ina Schieferdecker    +
+ 11-10-2013 11:46    +
+ 		+ + + + +
+ as proposed
+
+ + diff --git a/docs/mantis/CR6422.md b/docs/mantis/CR6422.md new file mode 100644 index 0000000000000000000000000000000000000000..78fdf3857e16160425cd977437aaf3fa09437dee --- /dev/null +++ b/docs/mantis/CR6422.md @@ -0,0 +1,104 @@ + + + + + + + + + + + + + 0006422: Restrictions on operations invoked from special places - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006422Part 01: TTCN-3 Core LanguageTechnicalpublic18-02-2013 09:4328-08-2013 16:50
ReporterTomas Urban 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.6.1 (published 2014-06)Fixed in Versionv4.6.1 (published 2014-06) 
Clause Reference(s)16.1.4
Source (company - Author)Elvior
Summary0006422: Restrictions on operations invoked from special places
DescriptionThe are many operations that cannot appear in functions that are called from "special places". These operations are mentioned in the chapter 16.1.4.
+
+However, some of these operations can appear in these "special places" directly as a part of expressions without a wrapping function:
+a) component operations: create, running and alive
+b) timer operations: running, read
+c) default operations: activate
+
+Although calling these operations directly might seem undesirable (according to explanation of reasons for not allowing these operation inside functions called from "special places"), there is in fact no rule forbidding their direct use in the "special places". I suggest to add this rule to the specification.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0006423closed Ina Schieferdecker Restriction on communication operations in functions 
related to 0006511closed Ina Schieferdecker One more "special place" for function call 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
18-02-2013 09:43Tomas UrbanNew Issue
18-02-2013 09:43Tomas UrbanClause Reference(s) => 16.1.4
18-02-2013 09:43Tomas UrbanSource (company - Author) => Elvior
08-07-2013 15:44Jens GrabowskiProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
08-07-2013 15:44Jens GrabowskiRelationship addedrelated to 0006423
08-07-2013 15:45Jens GrabowskiRelationship addedrelated to 0006511
08-07-2013 15:45Jens GrabowskiStatusnew => assigned
08-07-2013 15:45Jens GrabowskiAssigned To => Jacob Wieland - Spirent
08-07-2013 18:15Gyorgy RethyTarget Version => v4.6.1 (published 2014-06)
09-07-2013 15:55Jacob Wieland - SpirentNote Added: 0011481
10-07-2013 15:31Jacob Wieland - SpirentNote Added: 0011507
11-07-2013 10:18Jacob Wieland - SpirentStatusassigned => confirmed
11-07-2013 10:48Jacob Wieland - SpirentStatusconfirmed => assigned
11-07-2013 10:48Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Ina Schieferdecker
11-07-2013 10:57Jacob Wieland - SpirentStatusassigned => confirmed
28-08-2013 16:50Ina SchieferdeckerStatusconfirmed => resolved
28-08-2013 16:50Ina SchieferdeckerResolutionopen => fixed
28-08-2013 16:50Ina SchieferdeckerFixed in Version => v4.6.1 (published 2014-06)
28-08-2013 16:50Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011481) +
+ Jacob Wieland - Spirent    +
+ 09-07-2013 15:55    +
+ 		+ + + + +
+ This should probably be another restrction in section 21 where these configuation operations are defined.
+
+
+
+ + + + + + + + + + +
+ (0011507) +
+ Jacob Wieland - Spirent    +
+ 10-07-2013 15:31    +
+ 		+ + + + +
+ resolution proposal see CR6511
+
+ + diff --git a/docs/mantis/CR6423.md b/docs/mantis/CR6423.md new file mode 100644 index 0000000000000000000000000000000000000000..943ebaac082beaea398c38bb26b10eec8b8b3a76 --- /dev/null +++ b/docs/mantis/CR6423.md @@ -0,0 +1,133 @@ + + + + + + + + + + + + + 0006423: Restriction on communication operations in functions - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006423Part 01: TTCN-3 Core LanguageTechnicalpublic18-02-2013 11:1928-08-2013 16:49
ReporterTomas Urban 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.6.1 (published 2014-06)Fixed in Versionv4.6.1 (published 2014-06) 
Clause Reference(s)16.1.4
Source (company - Author)Elvior
Summary0006423: Restriction on communication operations in functions
DescriptionThe chapter 16.1.4 states that "Value returning functions can be called in communication operations... To avoid side effects that cause changing the state of the component or the actual snapshot and to prevent different results of subsequent evaluations on an unchanged snapshot, the following operations shall not be used in functions called in the cases specified above."
+
+I think the use of the expression "communication operations" is misfortunate and puts unnecessary restrictions on non-blocking operations. Operations like send, getcall etc. are never a part of snaphot evaluation. Therefore I suggest to change "communication operations" to "blocking communication operations".
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0006511closed Ina Schieferdecker One more "special place" for function call 
related to 0006422closed Ina Schieferdecker Restrictions on operations invoked from special places 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
18-02-2013 11:19Tomas UrbanNew Issue
18-02-2013 11:19Tomas UrbanClause Reference(s) => 16.1.4
18-02-2013 11:19Tomas UrbanSource (company - Author) => Elvior
08-07-2013 15:40Jens GrabowskiProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
08-07-2013 15:43Jens GrabowskiRelationship addedrelated to 0006511
08-07-2013 15:43Jens GrabowskiStatusnew => assigned
08-07-2013 15:43Jens GrabowskiAssigned To => Jacob Wieland - Spirent
08-07-2013 15:44Jens GrabowskiRelationship addedrelated to 0006422
08-07-2013 18:15Gyorgy RethyTarget Version => v4.6.1 (published 2014-06)
09-07-2013 11:38Jacob Wieland - SpirentNote Added: 0011457
09-07-2013 16:12Jacob Wieland - SpirentNote Added: 0011484
10-07-2013 15:30Jacob Wieland - SpirentNote Added: 0011506
11-07-2013 10:19Jacob Wieland - SpirentStatusassigned => confirmed
11-07-2013 10:48Jacob Wieland - SpirentStatusconfirmed => assigned
11-07-2013 10:48Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Ina Schieferdecker
28-08-2013 16:49Ina SchieferdeckerStatusassigned => resolved
28-08-2013 16:49Ina SchieferdeckerResolutionopen => fixed
28-08-2013 16:49Ina SchieferdeckerFixed in Version => v4.6.1 (published 2014-06)
28-08-2013 16:49Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011457) +
+ Jacob Wieland - Spirent    +
+ 09-07-2013 11:38    +
+ 		+ + + + +
+ How about: "operations invoked during snapshot evaluation"?
+
+
+
+ + + + + + + + + + +
+ (0011484) +
+ Jacob Wieland - Spirent    +
+ 09-07-2013 16:12    +
+ 		+ + + + +
+ Actually, it should simply be disallowed to directly or indirectly call functions containing implicit or explicit alt statements (and all blocking operations written on their own are implicit alt statements) from the snapshot-evaluation part of an alt statement (i.e the guard or the event part).
+
+
+
+ + + + + + + + + + +
+ (0011506) +
+ Jacob Wieland - Spirent    +
+ 10-07-2013 15:30    +
+ 		+ + + + +
+ resolution proposal see CR6511
+
+ + diff --git a/docs/mantis/CR6424.md b/docs/mantis/CR6424.md new file mode 100644 index 0000000000000000000000000000000000000000..c8147e85e5211a6a6e9f26a2a4b18bb59a75d24a --- /dev/null +++ b/docs/mantis/CR6424.md @@ -0,0 +1,76 @@ + + + + + + + + + + + + + 0006424: Ambiguous rule in the regexp function - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006424Part 01: TTCN-3 Core LanguageClarificationpublic19-02-2013 10:5611-07-2013 10:28
ReporterTomas Urban 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.6.1 (published 2014-06)Fixed in Versionv4.6.1 (published 2014-06) 
Clause Reference(s)C.4.1
Source (company - Author)Elvior
Summary0006424: Ambiguous rule in the regexp function
DescriptionThe regexp function specification contains the following rule:
+"The type of expression shall be universal charstring only when the type of inpar is universal charstring."
+
+It seems quite straightforward, but the specification contains compatibility rules for character strings too. These rules allow to use universal string values (if conditions are fulfilled) as character string values. The question if the above mentioned regexp rule overrides the compatility rule or not.
+
+Proposal:
+The current rule shall be amended:
+The type ... universal charstring. The compatibility rules for character string values specified in 6.3.1 cannot be applied in this case. (If compatibility rules cannot be used)
+or
+The type ... universal charstring or the expression can be interpreted as a character string according to the compatibility rules specified in 6.3.1. (If compatibility rules can be used)
+
+Alternative proposal:
+The regexp function signature can be changed so that the first two parameters and the return value are of the universal charstring type. This would still allow to use charstring values as parameters (as all charstrings can be interpreted as universal charstrings) and because the function result is always a substring of the first parameter, it can be safely used as a charstring value (using compatibility rules specified in 6.3.1).
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
19-02-2013 10:56Tomas UrbanNew Issue
19-02-2013 10:56Tomas UrbanClause Reference(s) => C.4.1
19-02-2013 10:56Tomas UrbanSource (company - Author) => Elvior
22-02-2013 11:23Jacob Wieland - SpirentNote Added: 0011328
08-07-2013 15:37Jens GrabowskiProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
08-07-2013 15:39Jens GrabowskiStatusnew => assigned
08-07-2013 15:39Jens GrabowskiAssigned To => Jacob Wieland - Spirent
08-07-2013 18:14Gyorgy RethyTarget Version => v4.6.1 (published 2014-06)
10-07-2013 11:54Gyorgy RethyNote Added: 0011497
10-07-2013 12:08Jacob Wieland - SpirentNote Deleted: 0011328
10-07-2013 12:08Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Ina Schieferdecker
11-07-2013 10:27Ina SchieferdeckerStatusassigned => resolved
11-07-2013 10:27Ina SchieferdeckerFixed in Version => v4.6.1 (published 2014-06)
11-07-2013 10:27Ina SchieferdeckerResolutionopen => fixed
11-07-2013 10:28Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011497) +
+ Gyorgy Rethy    +
+ 10-07-2013 11:54    +
+ 		+ + + + +
+ STF decision 2013-07-10: delete the sentence questioned by the CR.
+
+ + diff --git a/docs/mantis/CR6425.md b/docs/mantis/CR6425.md new file mode 100644 index 0000000000000000000000000000000000000000..ccfcba6edce3db05974aa9c306ae69fd8528fed5 --- /dev/null +++ b/docs/mantis/CR6425.md @@ -0,0 +1,204 @@ + + + + + + + + + + + + + 0006425: Incomplete rule for compound expression comparison - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006425Part 01: TTCN-3 Core LanguageClarificationpublic19-02-2013 14:3130-08-2013 10:34
ReporterTomas Urban 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.6.1 (published 2014-06)Fixed in Versionv4.6.1 (published 2014-06) 
Clause Reference(s)7.1.3
Source (company - Author)Elvior
Summary0006425: Incomplete rule for compound expression comparison
DescriptionThe following rule from the chapter 7.1.3 sets the requirements on operands which are both compound expressions, but doesn't specify the way how the comparison shall be performed:
+If there is a compound expression on both sides of the comparison
+operator, they shall both be value list notation expressions where the elements shall be of the same root type.
+
+Proposal:
+The rule should be amended with the following sentence: The compound expressions are then compared as if they were arrays of this root type.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR4625.doc (166,912) 11-07-2013 13:04
http://oldforge.etsi.org/mantis/file_download.php?file_id=2828&type=bug
Issue History
Date ModifiedUsernameFieldChange
19-02-2013 14:31Tomas UrbanNew Issue
19-02-2013 14:31Tomas UrbanClause Reference(s) => 7.1.3
19-02-2013 14:31Tomas UrbanSource (company - Author) => Elvior
08-07-2013 15:36Jens GrabowskiProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
08-07-2013 15:36Jens GrabowskiStatusnew => assigned
08-07-2013 15:36Jens GrabowskiAssigned To => Jacob Wieland - Spirent
08-07-2013 15:37Gyorgy RethyNote Added: 0011453
08-07-2013 18:14Gyorgy RethyTarget Version => v4.6.1 (published 2014-06)
09-07-2013 11:43Jacob Wieland - SpirentNote Added: 0011458
09-07-2013 11:56Jacob Wieland - SpirentNote Added: 0011461
11-07-2013 13:04Jacob Wieland - SpirentFile Added: CR4625.doc
11-07-2013 13:04Jacob Wieland - SpirentNote Added: 0011544
11-07-2013 13:04Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Ina Schieferdecker
11-07-2013 13:04Jacob Wieland - SpirentStatusassigned => confirmed
30-08-2013 10:33Ina SchieferdeckerNote Added: 0011653
30-08-2013 10:33Ina SchieferdeckerStatusconfirmed => resolved
30-08-2013 10:33Ina SchieferdeckerResolutionopen => fixed
30-08-2013 10:33Ina SchieferdeckerFixed in Version => v4.6.1 (published 2014-06)
30-08-2013 10:34Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011453) +
+ Gyorgy Rethy    +
+ 08-07-2013 15:37    +
+ 		+ + + + +
+ First check what the current text specifies and what is missing.
+
+
+
+ + + + + + + + + + +
+ (0011458) +
+ Jacob Wieland - Spirent    +
+ 09-07-2013 11:43    +
+ 		+ + + + +
+ I think this is covered by the general definition of value equality and the special cases of set of/record of types, so I think there is nothing to be done here.
+
+
+
+ + + + + + + + + + +
+ (0011461) +
+ Jacob Wieland - Spirent    +
+ 09-07-2013 11:56    +
+ 		+ + + + +
+ As the general definition was removed, we somehow did not add one relevant condition to the record of/set of/array case, i.e. that the two values to be compared must have the same length to be equal (additional to the corresponding elements to be equal, of course).
+
+
+
+ + + + + + + + + + +
+ (0011544) +
+ Jacob Wieland - Spirent    +
+ 11-07-2013 13:04    +
+ 		+ + + + +
+ added proposal, please check
+
+
+
+ + + + + + + + + + +
+ (0011653) +
+ Ina Schieferdecker    +
+ 30-08-2013 10:33    +
+ 		+ + + + +
+ As proposed.
+
+ + diff --git a/docs/mantis/CR6426.md b/docs/mantis/CR6426.md new file mode 100644 index 0000000000000000000000000000000000000000..6af09898ad346310654b8f8b057ff9170f6e83b1 --- /dev/null +++ b/docs/mantis/CR6426.md @@ -0,0 +1,253 @@ + + + + + + + + + + + + + 0006426: Missing restrictions on operations in component type declarations - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006426Part 01: TTCN-3 Core LanguageTechnicalpublic20-02-2013 08:3711-07-2013 16:20
ReporterTomas Urban 
Assigned ToJacob Wieland - Spirent 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.6.1 (published 2014-06)Fixed in Versionv4.6.1 (published 2014-06) 
Clause Reference(s)6.2.10.1
Source (company - Author)Elvior
Summary0006426: Missing restrictions on operations in component type declarations
DescriptionThe current specification contains several restrictions on operations that can be used in component declaration blocks. These restrictions are mostly implicit (such as the rule from the chapter 21 restricting configuration operation to test cases, functions and altsteps).
+
+The implicit restrictions lead to paradoxes: e.g. it is illegal to use the create operation directly in a component declaration block, but when the same create operation is wrapped in a function called from the component declaration part, it is legal (because the create operation can be used in a function).
+
+In some cases there are no restrictions at all, so the component declaration can call a function that contains communication operations. This is rather dangerous, especially considering the fact that the component hasn't been properly initialized at that point and the ports used in these operations might not exist yet.
+
+The current situation gives an impression that the issue hasn't been properly analyzed and additional rules are necessary.
+
+Proposal:
+The following rule shall be added to the section 6.2.10.1:
+The following operations shall not be used in component type definition and in functions called directly or indirectly from component type definition:
+a) All component operations, i.e. create, start (component), stop (component), kill, running (component), alive, done and killed.
+b) All port operations, i.e. start (port), stop (port), halt, clear, send, receive, trigger, call, getcall, reply, getreply, raise, catch, check, connect, map, checkstate
+c) All timer operations, i.e. start (timer), stop (timer), running (timer), read, timeout.
+d) The testcase.stop operation
+
+Notes shall be added to the 3rd column of the table 16 saying that the above mentioned operations are only allowed in functions that are not called from component type definitions (and control part as well).
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR6426.doc (171,008) 10-07-2013 17:08
http://oldforge.etsi.org/mantis/file_download.php?file_id=2819&type=bug
doc CR6426_v2.doc (173,568) 11-07-2013 11:26
http://oldforge.etsi.org/mantis/file_download.php?file_id=2826&type=bug
Issue History
Date ModifiedUsernameFieldChange
20-02-2013 08:37Tomas UrbanNew Issue
20-02-2013 08:37Tomas UrbanClause Reference(s) => 6.2.10.1
20-02-2013 08:37Tomas UrbanSource (company - Author) => Elvior
22-02-2013 11:20Jacob Wieland - SpirentNote Added: 0011327
08-07-2013 15:34Gyorgy RethyNote Added: 0011452
08-07-2013 15:34Jens GrabowskiProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
08-07-2013 15:34Jens GrabowskiStatusnew => assigned
08-07-2013 15:34Jens GrabowskiAssigned To => Jacob Wieland - Spirent
08-07-2013 18:13Gyorgy RethyTarget Version => v4.6.1 (published 2014-06)
09-07-2013 15:27Jacob Wieland - SpirentNote Added: 0011480
10-07-2013 17:08Jacob Wieland - SpirentFile Added: CR6426.doc
10-07-2013 17:09Jacob Wieland - SpirentNote Added: 0011517
10-07-2013 19:34Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
10-07-2013 19:34Jacob Wieland - SpirentNote Added: 0011529
11-07-2013 09:04Jacob Wieland - SpirentAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
11-07-2013 10:17Jacob Wieland - SpirentStatusassigned => confirmed
11-07-2013 10:48Jacob Wieland - SpirentStatusconfirmed => assigned
11-07-2013 10:48Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Ina Schieferdecker
11-07-2013 10:58Jacob Wieland - SpirentStatusassigned => confirmed
11-07-2013 11:26Ina SchieferdeckerFile Added: CR6426_v2.doc
11-07-2013 11:27Ina SchieferdeckerStatusconfirmed => assigned
11-07-2013 11:27Ina SchieferdeckerAssigned ToIna Schieferdecker => Jacob Wieland - Spirent
11-07-2013 11:47Jacob Wieland - SpirentStatusassigned => resolved
11-07-2013 11:47Jacob Wieland - SpirentFixed in Version => v4.6.1 (published 2014-06)
11-07-2013 11:47Jacob Wieland - SpirentResolutionopen => fixed
11-07-2013 11:47Jacob Wieland - SpirentNote Added: 0011539
11-07-2013 16:20Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011327) +
+ Jacob Wieland - Spirent    +
+ 22-02-2013 11:20    +
+ 		+ + + + +
+ The list seems very similar to the restriction of operations in alt-guards. Probably most other operations disallowed there (i.e. function calls with 'out' or 'inout' parameters, verdict operations) should also be disallowed. The only exception I would make is external functions (which I would also exclude from the other list).
+
+If there should really be a difference, at least a common subset should be identified and referenced from both places.
+
+
+
+ + + + + + + + + + +
+ (0011452) +
+ Gyorgy Rethy    +
+ 08-07-2013 15:34    +
+ 		+ + + + +
+ Check the existing text
+
+
+
+ + + + + + + + + + +
+ (0011480) +
+ Jacob Wieland - Spirent    +
+ 09-07-2013 15:27    +
+ 		+ + + + +
+ I think it is better (and sufficient) to restrict the configuration operations in section 21 further to be usable only in testcase-behavior, i.e. testcases and functions/altsteps called directly or indirectly from testcases or from functions started on ptcs.
+
+A NOTE could be added in the section about definition of component types, referencing this restriction.
+
+
+
+ + + + + + + + + + +
+ (0011517) +
+ Jacob Wieland - Spirent    +
+ 10-07-2013 17:09    +
+ 		+ + + + +
+ added proposal
+
+
+
+ + + + + + + + + + +
+ (0011529) +
+ Jacob Wieland - Spirent    +
+ 10-07-2013 19:34    +
+ 		+ + + + +
+ please check
+
+
+
+ + + + + + + + + + +
+ (0011539) +
+ Jacob Wieland - Spirent    +
+ 11-07-2013 11:47    +
+ 		+ + + + +
+ fine with me
+
+ + diff --git a/docs/mantis/CR6428.md b/docs/mantis/CR6428.md new file mode 100644 index 0000000000000000000000000000000000000000..02dbdcb6da16bf6d18d6805f2fcee1815d84097e --- /dev/null +++ b/docs/mantis/CR6428.md @@ -0,0 +1,245 @@ + + + + + + + + + + + + + 0006428: Connecting already connected ports - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006428Part 01: TTCN-3 Core LanguageClarificationpublic26-02-2013 13:3630-08-2013 09:54
ReporterTomas Urban 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.6.1 (published 2014-06)Fixed in Versionv4.6.1 (published 2014-06) 
Clause Reference(s)21.1.1 and 9.1
Source (company - Author)Elvior
Summary0006428: Connecting already connected ports
DescriptionThe current specification doesn't provide an explicit guidelines on what happens in case when the ports referenced in the connect operation are already connected.
+
+The TTCN-3 core language specification contains a rule (in the section 9.1) saying that "A port owned by a component A shall not be connected with two or more ports owned by a component B". When connecting existing ports, this rule is not breached. However, I assume that creating a second connection between these ports wouldn't be very suitable, so there are two interpretations what might happen:
+1. An error shall occur, because of attempting to create a duplicate connection
+2. The connection operation shall simply return without creating a connection (but notifying TRI)
+
+In both cases, the TTCN-3 specification should be amended, adding precise rules for this situation so that there's no space for different interpretations.
+
+The map operations suffers from the similar problem as well.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR6428_resolution_v1.doc (70,656) 29-08-2013 10:39
http://oldforge.etsi.org/mantis/file_download.php?file_id=2874&type=bug
doc CR6428_resolution_v2.doc (70,656) 29-08-2013 17:09
http://oldforge.etsi.org/mantis/file_download.php?file_id=2875&type=bug
Issue History
Date ModifiedUsernameFieldChange
26-02-2013 13:36Tomas UrbanNew Issue
26-02-2013 13:36Tomas UrbanClause Reference(s) => 21.1.1 and 9.1
26-02-2013 13:36Tomas UrbanSource (company - Author) => Elvior
08-07-2013 15:33Jens GrabowskiStatusnew => assigned
08-07-2013 15:33Jens GrabowskiAssigned To => Jens Grabowski
08-07-2013 18:09Gyorgy RethyProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
08-07-2013 18:13Gyorgy RethyTarget Version => v4.6.1 (published 2014-06)
29-08-2013 09:47Jens GrabowskiNote Added: 0011631
29-08-2013 10:39Jens GrabowskiFile Added: CR6428_resolution_v1.doc
29-08-2013 10:40Jens GrabowskiNote Added: 0011634
29-08-2013 10:41Jens GrabowskiAssigned ToJens Grabowski => Ina Schieferdecker
29-08-2013 10:41Jens GrabowskiStatusassigned => confirmed
29-08-2013 11:41Ina SchieferdeckerNote Added: 0011636
29-08-2013 11:42Ina SchieferdeckerNote Edited: 0011636
29-08-2013 12:04Ina SchieferdeckerNote Added: 0011637
29-08-2013 17:09Ina SchieferdeckerFile Added: CR6428_resolution_v2.doc
29-08-2013 17:09Ina SchieferdeckerNote Added: 0011644
29-08-2013 17:09Ina SchieferdeckerAssigned ToIna Schieferdecker => Jens Grabowski
29-08-2013 17:09Ina SchieferdeckerResolutionopen => fixed
29-08-2013 17:09Ina SchieferdeckerFixed in Version => v4.6.1 (published 2014-06)
29-08-2013 17:21Jens GrabowskiNote Added: 0011646
29-08-2013 17:21Jens GrabowskiAssigned ToJens Grabowski => Ina Schieferdecker
30-08-2013 09:54Ina SchieferdeckerStatusconfirmed => resolved
30-08-2013 09:54Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011631) +
+ Jens Grabowski    +
+ 29-08-2013 09:47    +
+ 		+ + + + +
+ This case is handled in Annex "F.3.1 Configuration Operations". Connecting/Mapping already connected/mapped ports is defined as NULL operation. An appropriate remark will be added to the map and connect operations.
+
+
+
+ + + + + + + + + + +
+ (0011634) +
+ Jens Grabowski    +
+ 29-08-2013 10:40    +
+ 		+ + + + +
+ Resolution agreed with György, assigned to Ina for implementation.
+
+
+
+ + + + + + + + + + +
+ (0011636) +
+ Ina Schieferdecker    +
+ 29-08-2013 11:41    +
(edited on: 29-08-2013 11:42)
+ 		+ + + + +
+ This CR requires discussion: if for an already existing mapped/connected port connection, the triMap/tciConnect are invoked, the test behavior might be different due to changes in the adapter/connection if or if not the map/connect operation is invoked a second time.
+
+We have to discuss, if a repeated map/connect operation is really opaque (i.e. the null operation) or if TRI/TCI are involved respectively.
+
+
+
+
+
+ + + + + + + + + + +
+ (0011637) +
+ Ina Schieferdecker    +
+ 29-08-2013 12:04    +
+ 		+ + + + +
+ Discussion in STF: tripMap and tciConnect should not (!) be invoked in these cases, so that a repeated map/connect is a null operation.
+
+
+
+ + + + + + + + + + +
+ (0011644) +
+ Ina Schieferdecker    +
+ 29-08-2013 17:09    +
+ 		+ + + + +
+ Please check
+
+
+
+ + + + + + + + + + +
+ (0011646) +
+ Jens Grabowski    +
+ 29-08-2013 17:21    +
+ 		+ + + + +
+ Note is ok.
+
+ + diff --git a/docs/mantis/CR6429.md b/docs/mantis/CR6429.md new file mode 100644 index 0000000000000000000000000000000000000000..a2ad3db1417f50dd4dab25c578df60ff6ecd8dc7 --- /dev/null +++ b/docs/mantis/CR6429.md @@ -0,0 +1,349 @@ + + + + + + + + + + + + + 0006429: modifies of 'record of' fields still seems to be ambiguous - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006429Part 01: TTCN-3 Core LanguageClarificationpublic27-02-2013 15:5204-01-2015 20:06
ReporterJacob Wieland - Spirent 
Assigned ToGyorgy Rethy 
PriorityurgentSeveritymajorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.5.1 (published 2013-04) 
Target Versionv4.7.1 (published 2015-06)Fixed in Versionv4.7.1 (published 2015-06) 
Clause Reference(s)Section 15.5.
Source (company - Author)Testing Technologies - Jacob Wieland
Summary0006429: modifies of 'record of' fields still seems to be ambiguous
DescriptionHaving a record type with a record of field
+
+type record R {
+  record of record {
+    integer a,
+    integer b
+  } list
+}
+
+and a template of that type
+
+template R r1 := {
+  list := {
+    {
+      a := 1,
+      b := 2
+    },
+    {
+      a := 3,
+      b := 4
+    }
+  }
+}
+
+the question arises what the meaning of the following modified template is:
+
+template R r2 modifies r1 := {
+  list := {
+    {
+      a := 0
+    }
+  }
+}
+
+Because the standard says that matching mechanisms in fields are replaced (unless inside records), I think the correct interpretation of this would be
+error or partially defined template, as the { { a := 0 } } tries to replace the whole { { a := 1, b := 2 }, { a := 3, b := 4 } } list (and because b is not optional).
+
+To get the desired result of just replacing the a-field in element 0, the correct syntax would be
+
+template R r2 modifies r1 := {
+  list := {
+    [0] := {
+      a := 0
+    }
+  }
+}
+
+Unfortunately, the standard only "allows" this with a "may" clause but does not explicitly state that this is the only way of doing this, thus making people think that using partially defined list-notation to partially modify some elements of the original would also be okay.
+
+But, if the replacement-syntax also is interpreted as an by-element-modification syntax (as some people seem to interpret the standard), then
+there is no possibility of writing down a modification of the whole list-field with a totally different list that is shorter than the original.
+
+If the replacement is equally long or longer, there is of course no problem as then all existing fields are overwritten anyway. But how can one get rid of superfluous elements at the end? In my opinion, this would not be possible, if the list notation can be used for modification instead of replacement.
+
+If allowing the list notation for modification, then it should be clarified that the length of the resulting list is the length of the list notation in the modifying template (i.e. all trailing unchanged elements that shall be kept in the list need to be specified with the unchanged symbol explicitly).
+
+Then, we would have a clear distinction between
+
+template R r2 modifies r1 := {
+  list := {
+    {
+      a := 0
+    }
+  }
+}
+
+and
+
+template R r3 modified r1 := {
+  list := {
+    {
+      a := 0
+    },
+    -
+  }
+}
+
+The r3 template would keep the second element of the list, the r2 template would delete it. Both would modify the first element.
+
+This solution would be especially beneficial as it seems to be consistent with the record-of-modification-interpretation of the standard people have and thus would not create backward compatibility issues with the tools employing this interpretation. Only the tools not accepting this interpretation at the moment would need to be changed to allow it.
+  
Steps To Reproduce
Additional InformationThe problem came up in STF 160 in the context of the LTE test suite.
TagsNo tags attached.
Relationships
related to 0006411closed Gyorgy Rethy Example to clarify Modified Template semantics 
Attached Filesdocx draft-res-6429.docx (25,579) 07-10-2014 11:21
http://oldforge.etsi.org/mantis/file_download.php?file_id=3094&type=bug
docx draft-res-6429-V2.docx (20,735) 08-10-2014 10:58
http://oldforge.etsi.org/mantis/file_download.php?file_id=3108&type=bug
Issue History
Date ModifiedUsernameFieldChange
27-02-2013 15:52Jacob Wieland - SpirentNew Issue
27-02-2013 15:52Jacob Wieland - SpirentClause Reference(s) => Section 15.5.
27-02-2013 15:52Jacob Wieland - SpirentSource (company - Author) => Testing Technologies - Jacob Wieland
08-07-2013 15:32Jens GrabowskiStatusnew => assigned
08-07-2013 15:32Jens GrabowskiAssigned To => Gyorgy Rethy
08-07-2013 15:51Jens GrabowskiRelationship addedrelated to 0006411
08-07-2013 18:09Gyorgy RethyProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
08-07-2013 18:13Gyorgy RethyTarget Version => v4.6.1 (published 2014-06)
26-08-2013 11:25Gyorgy RethyNote Added: 0011590
26-08-2013 13:36Jacob Wieland - SpirentNote Added: 0011595
28-08-2013 10:44Gyorgy RethyNote Added: 0011617
28-08-2013 10:47Gyorgy RethyNote Added: 0011618
28-08-2013 10:47Gyorgy RethyStatusassigned => closed
28-08-2013 10:47Gyorgy RethyResolutionopen => fixed
28-08-2013 10:47Gyorgy RethyFixed in Version => v4.6.1 (published 2014-06)
19-06-2014 14:30Gyorgy RethyAssigned ToGyorgy Rethy => Axel Rennoch
19-06-2014 14:30Gyorgy RethyStatusclosed => assigned
20-06-2014 11:39Gyorgy RethyProduct Version => v4.5.1 (published 2013-04)
20-06-2014 11:39Gyorgy RethyTarget Versionv4.6.1 (published 2014-06) => v4.7.1 (published 2015-06)
27-06-2014 13:43Gyorgy RethyPrioritynormal => urgent
07-10-2014 11:21Axel RennochFile Added: draft-res-6429.docx
07-10-2014 11:23Axel RennochNote Added: 0012251
07-10-2014 11:24Axel RennochAssigned ToAxel Rennoch => Gyorgy Rethy
07-10-2014 11:24Axel RennochStatusassigned => confirmed
08-10-2014 07:53Gyorgy RethyAssigned ToGyorgy Rethy => Jens Grabowski
08-10-2014 10:58Jens GrabowskiFile Added: draft-res-6429-V2.docx
08-10-2014 10:58Jens GrabowskiNote Added: 0012274
08-10-2014 10:58Jens GrabowskiAssigned ToJens Grabowski => Gyorgy Rethy
08-10-2014 10:58Jens GrabowskiStatusconfirmed => assigned
08-10-2014 10:59Jens GrabowskiStatusassigned => resolved
04-01-2015 20:06Gyorgy RethyNote Added: 0012608
04-01-2015 20:06Gyorgy RethyStatusresolved => closed
04-01-2015 20:06Gyorgy RethyFixed in Versionv4.6.1 (published 2014-06) => v4.7.1 (published 2015-06)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011590) +
+ Gyorgy Rethy    +
+ 26-08-2013 11:25    +
+ 		+ + + + +
+ I think the example first_r2 is more tricky: I agree, that a complete record_of (i.e. not using the index notation) shall replace the complete record_of of the parent. But the first element is a record, where a:=0 replaces field "a" of the parent, but field b remains unchanged. Hence first_r2 should be {{a:=0, b:=2}}. Otherwise we are in conflict with the general rule of modifying records.
+
+To avoid split the discussion over the two related CRs (6411 and 6429), I switch to 6411 now and let further discuss further the topic at that CR.
+
+
+
+ + + + + + + + + + +
+ (0011595) +
+ Jacob Wieland - Spirent    +
+ 26-08-2013 13:36    +
+ 		+ + + + +
+ Isn't that exactly what I have proposed?
+
+
+
+ + + + + + + + + + +
+ (0011617) +
+ Gyorgy Rethy    +
+ 28-08-2013 10:44    +
+ 		+ + + + +
+ In that case we are on the same side. Anyway we have agreed at the STF discussion yesterday (see note to CR6411) :-)
+
+
+
+ + + + + + + + + + +
+ (0011618) +
+ Gyorgy Rethy    +
+ 28-08-2013 10:47    +
+ 		+ + + + +
+ This CR is closed, because it is merged with CR6411, pls. find the discussion and resolution at that CR.
+
+
+
+ + + + + + + + + + +
+ (0012251) +
+ Axel Rennoch    +
+ 07-10-2014 11:23    +
+ 		+ + + + +
+ clarifications added regarding list notation for modification, following the "solution" proposed by Jacob
+
+
+
+ + + + + + + + + + +
+ (0012274) +
+ Jens Grabowski    +
+ 08-10-2014 10:58    +
+ 		+ + + + +
+ changed cp. to cf.
+
+
+
+ + + + + + + + + + +
+ (0012608) +
+ Gyorgy Rethy    +
+ 04-01-2015 20:06    +
+ 		+ + + + +
+ Added to draft V4.6.3
+
+ + diff --git a/docs/mantis/CR6430.md b/docs/mantis/CR6430.md new file mode 100644 index 0000000000000000000000000000000000000000..6dba2d6c76d709bab4524b987caf5e5e449a3419 --- /dev/null +++ b/docs/mantis/CR6430.md @@ -0,0 +1,796 @@ + + + + + + + + + + + + + 0006430: Use of uninitialized and partially initialized values - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006430Part 01: TTCN-3 Core LanguageTechnicalpublic28-02-2013 08:0428-11-2013 10:57
ReporterTomas Urban 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.6.1 (published 2014-06)Fixed in Versionv4.6.1 (published 2014-06) 
Clause Reference(s)7.1, 11.1, 11.2
Source (company - Author)Elvior
Summary0006430: Use of uninitialized and partially initialized values
DescriptionThe current specification constraints the use of partially initialized variables (11.1 restriction d, 11.2. restriction e). However, no such rule is specified for constants, parameters, templates, module parameters and compound expressions. This leads to situations when the same value content produces an error if the operand is a variable and no error, if it is a compound expression:
+
+var MyRecord v_r := { field1 := 1, field2 := - }
+template MyRecord t_r := ?;
+match(v_r, t_r); // error, v_r is partially initialized
+match({ field1 := 1, field2 := - }, t_r); // no error: no restriction on
+     // partially initialized compound expressions
+
+Proposal:
+The rules for using uninitialized and partially initialized values shall be general for all values.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR6430_resolution_v1.doc (577,024) 10-10-2013 08:48
http://oldforge.etsi.org/mantis/file_download.php?file_id=2915&type=bug
doc CR6430_resolution_v2.doc (642,560) 10-10-2013 17:44
http://oldforge.etsi.org/mantis/file_download.php?file_id=2923&type=bug
doc CR6430_resolution_v3.doc (647,168) 11-10-2013 14:43
http://oldforge.etsi.org/mantis/file_download.php?file_id=2931&type=bug
doc CR6430_resolution_v4.doc (645,632) 28-11-2013 10:56
http://oldforge.etsi.org/mantis/file_download.php?file_id=2955&type=bug
Issue History
Date ModifiedUsernameFieldChange
28-02-2013 08:04Tomas UrbanNew Issue
28-02-2013 08:04Tomas UrbanClause Reference(s) => 7.1, 11.1, 11.2
28-02-2013 08:04Tomas UrbanSource (company - Author) => Elvior
28-02-2013 08:44Jacob Wieland - SpirentNote Added: 0011332
01-03-2013 12:23Tomas UrbanNote Added: 0011334
01-03-2013 13:25Jacob Wieland - SpirentNote Added: 0011335
08-07-2013 15:29Jens GrabowskiProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
08-07-2013 15:30Jens GrabowskiStatusnew => assigned
08-07-2013 15:30Jens GrabowskiAssigned To => Jacob Wieland - Spirent
08-07-2013 15:31Jens GrabowskiAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
08-07-2013 18:12Gyorgy RethyTarget Version => v4.6.1 (published 2014-06)
26-08-2013 14:53Jacob Wieland - SpirentNote Added: 0011597
08-10-2013 18:00Gyorgy RethyNote Added: 0011712
08-10-2013 18:00Gyorgy RethyNote Added: 0011713
08-10-2013 18:01Gyorgy RethyNote Deleted: 0011712
09-10-2013 12:27Jacob Wieland - SpirentNote Added: 0011728
09-10-2013 13:15Tomas UrbanNote Added: 0011730
09-10-2013 17:11Gyorgy RethyNote Added: 0011737
09-10-2013 17:12Gyorgy RethyNote Added: 0011738
09-10-2013 17:18Gyorgy RethyNote Edited: 0011737
09-10-2013 18:12Gyorgy RethyNote Edited: 0011738
10-10-2013 08:48Gyorgy RethyFile Added: CR6430_resolution_v1.doc
10-10-2013 08:49Gyorgy RethyNote Added: 0011740
10-10-2013 08:56Gyorgy RethyNote Added: 0011741
10-10-2013 13:03Jacob Wieland - SpirentNote Added: 0011749
10-10-2013 13:08Jacob Wieland - SpirentNote Added: 0011750
10-10-2013 17:27Gyorgy RethyNote Added: 0011760
10-10-2013 17:44Gyorgy RethyFile Added: CR6430_resolution_v2.doc
10-10-2013 17:46Gyorgy RethyNote Added: 0011761
10-10-2013 17:46Gyorgy RethyNote Edited: 0011761
10-10-2013 17:47Gyorgy RethyNote Edited: 0011760
10-10-2013 17:52Gyorgy RethyAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
11-10-2013 12:24Jacob Wieland - SpirentNote Added: 0011769
11-10-2013 12:26Jacob Wieland - SpirentNote Edited: 0011769
11-10-2013 12:29Jacob Wieland - SpirentNote Added: 0011771
11-10-2013 12:30Jacob Wieland - SpirentNote Added: 0011772
11-10-2013 12:30Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
11-10-2013 12:30Jacob Wieland - SpirentStatusassigned => confirmed
11-10-2013 14:40Gyorgy RethyFile Added: CR6430_resolution_v3.doc
11-10-2013 14:41Gyorgy RethyNote Added: 0011784
11-10-2013 14:41Gyorgy RethyAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
11-10-2013 14:42Gyorgy RethyFile Deleted: CR6430_resolution_v3.doc
11-10-2013 14:43Gyorgy RethyFile Added: CR6430_resolution_v3.doc
11-10-2013 16:31Jacob Wieland - SpirentStatusconfirmed => assigned
11-10-2013 16:33Jacob Wieland - SpirentNote Added: 0011793
11-10-2013 16:33Jacob Wieland - SpirentStatusassigned => confirmed
11-10-2013 16:34Jacob Wieland - SpirentStatusconfirmed => assigned
11-10-2013 16:34Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Ina Schieferdecker
11-10-2013 16:34Jacob Wieland - SpirentStatusassigned => confirmed
28-11-2013 10:56Ina SchieferdeckerFile Added: CR6430_resolution_v4.doc
28-11-2013 10:56Ina SchieferdeckerNote Added: 0011853
28-11-2013 10:57Ina SchieferdeckerStatusconfirmed => resolved
28-11-2013 10:57Ina SchieferdeckerResolutionopen => fixed
28-11-2013 10:57Ina SchieferdeckerFixed in Version => v4.6.1 (published 2014-06)
28-11-2013 10:57Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011332) +
+ Jacob Wieland - Spirent    +
+ 28-02-2013 08:44    +
+ 		+ + + + +
+ In my opinion, constants, templates and module parameters must be fully initialized (i.e. they cannot be partially initialized) as they can not be changed later on (being constant as they are). Leaving parts of constants uninitialized would defy their purpose.
+
+Therefore, restrictions on partially uninitialized constants, templates and module parameters are unnecessary as they cannot exist. That is why the restrictions only apply to things that can be initialized partially, i.e. variables.
+
+
+
+ + + + + + + + + + +
+ (0011334) +
+ Tomas Urban    +
+ 01-03-2013 12:23    +
+ 		+ + + + +
+ I am afraid I cannot agree. First of all, the current specification doesn't require constants, templates or module parameters to be fully initialized. Besides, uninitialized templates might be useful as base templates for later modifications where the module author intentionally leaves holes for filling by modified templates (using similar design principles as abstract classes in object oriented programming languages).
+
+
+
+ + + + + + + + + + +
+ (0011335) +
+ Jacob Wieland - Spirent    +
+ 01-03-2013 13:25    +
+ 		+ + + + +
+ If it was possible to declare these templates as abstract, I would agree, but as it is not, I think this is just inviting people to write error-prone code as partially initialized templates cannot be differentiated from fully initialized ones. They would not get any feedback from tools that the template they use is not fully initialized (even though in most cases, this is probably unintentional) and then can run into situations at runtime where there is an error because they are using the template (which is often expensive).
+
+Therefore, I would either go into the direction of specifically having to declare a template as abstract/partial or whatever or to forbid this entirely (which doesn't hurt as one can always use wildcards to fill in the abstract holes).
+
+
+
+ + + + + + + + + + +
+ (0011597) +
+ Jacob Wieland - Spirent    +
+ 26-08-2013 14:53    +
+ 		+ + + + +
+ Also, the restriction exists that all operaands (except certain exceptions) to predefined functions (here: match) must be fully initialized. Therefore, the
+
+match({ field1 := 1, field2 := - }, t_r);
+
+would also produce an error.
+
+
+
+ + + + + + + + + + +
+ (0011713) +
+ Gyorgy Rethy    +
+ 08-10-2013 18:00    +
+ 		+ + + + +
+ I have checked the text of the standard and found:
+    1. There is _no_ requirement saying that constants should be completely initialized. The same apply for module parameters and templates. For templates it is explicitly stated that they need to be completely initialized, when used in a send or receive operation: i.e. implicitly confirmed that may not be initialized in before. Records, sets and unions may even be left uninitialized by using {} at the RHS of their declarations.
+    2. For expressions it is stated that only the _operands_ of operators has to be initialized: i.e. it is allowed to assign partially initialized objects and consequently also allowed to pass them as actual parameters (btw. this is stated explicitly for variables).
+    3. Except for the listed exceptions, in and inout _parameters_ of predefined functions shall completely be initialized. Hence match({field1:= 1,field2:=-}, t_r); shall cause an error.
+We cannot make non-backward compatible changes in the standard. In addition, using partially initialized constants/templates have use cases: for example, used as global values/templates to initialize dynamically built messages; in this case, leaving the dynamically assigned fields uninitialized will prevent sending a wrong message, when a field of the message is forgotten to be completed runtime (otherwise a dummy value would have to be used when initializing the constant/template and the message would be sent containing this dummy value - causing a debugging nightmare for the user).
+
+Therefore, I agree with Tomas, we need to define the rules of using not or partly initialized stuff in general, not only for variables. I will prepare a proposed draft.
+
+
+
+ + + + + + + + + + +
+ (0011728) +
+ Jacob Wieland - Spirent    +
+ 09-10-2013 12:27    +
+ 		+ + + + +
+ I have to reiterate. What shall be the purpose of not-fully-initialized constants or module parameters which can never become fully initialized and therefore are basically just potential error-carriers? What is the use-case?
+
+For templates, even though I still see them as problematic for the same reason, I can see the argument that they can be used as the basis for modification (and in that way - "changed") later on.
+
+
+
+ + + + + + + + + + +
+ (0011730) +
+ Tomas Urban    +
+ 09-10-2013 13:15    +
+ 		+ + + + +
+ Just one slightly off-topic note. It was mentioned several times in this thread that match is a predefined function. That's an incorrect statement. Match doesn't belong to predefined functions and it is not an operand of an expression either. The core language specification defines it as an operation. As such, limitations on predefined function parameters and operands of expressions cannot be applied to it.
+
+The point of this CR is that while the core language specification has a rule on using partially initialized variables, other entities are not affected by this rule. And the fact is that regardless whether some of these entities are practically usefull or not, they do not produce the same kind of behaviour as variables even if the content is the same. Therefore I believe, that extending the rule currently valid for variables only to all values regardless of their origin would make the specification better.
+
+The question whether partially initialized static content is fine shall be handled separately in a different CR.
+
+
+
+ + + + + + + + + + +
+ (0011737) +
+ Gyorgy Rethy    +
+ 09-10-2013 17:11    +
(edited on: 09-10-2013 17:18)
+ 		+ + + + +
+ copy-paste:
+"using partially initialized constants/templates have use cases: for example, used as global values/templates to initialize dynamically built messages; in this case, leaving the dynamically assigned fields uninitialized will prevent sending a wrong message, when a field of the message is forgotten to be completed runtime (otherwise a dummy value would have to be used when initializing the constant/template and the message would be sent containing this dummy value - causing a debugging nightmare for the user)."
+
+And again, unless we can _guarantee_ that a functionality is unused, we cannot make a non-backward compatible change. This statement was reinforced several times from TF160, from our users and from TC MTS. I would like to avoid going to MTS with a minor issue like this.
+
+
+
+
+
+ + + + + + + + + + +
+ (0011738) +
+ Gyorgy Rethy    +
+ 09-10-2013 17:12    +
(edited on: 09-10-2013 18:12)
+ 		+ + + + +
+ Tomaš, thank for noting the match operation, I will look after it as well.
+
+
+
+
+
+ + + + + + + + + + +
+ (0011740) +
+ Gyorgy Rethy    +
+ 10-10-2013 08:49    +
+ 		+ + + + +
+ See draft resolution text for review in CR6430_resolution_v1.doc.
+
+
+
+ + + + + + + + + + +
+ (0011741) +
+ Gyorgy Rethy    +
+ 10-10-2013 08:56    +
+ 		+ + + + +
+ It needs be discussed in the STF, how to continue with this CR.
+
+
+
+ + + + + + + + + + +
+ (0011749) +
+ Jacob Wieland - Spirent    +
+ 10-10-2013 13:03    +
+ 		+ + + + +
+ The addenda to constants and templates regarding the partial initialization are unnecessary/superfluous as this is already covered by the definition of partially initialized.
+
+For module parameters, it should only be necessary that they are at least partially initialized upon USAGE. The initialization state of unused module parameters should not be of any consequence.
+
+The backward compatibility issue regarding standardization bodies I don't see as that problematic in this case as at least one tool does not support partially initialized templates (not template variables!), constants and module parameters. Since no standardization body (and at least none of our customers) has yet complained about this being a missing feature in the tool, I surely think this would be more on the level of a clarification than an actual backward-incompatible change that would have any real negative impact.
+
+But, if you insist that you need this feature, do the clarification in the other direction.
+
+
+
+ + + + + + + + + + +
+ (0011750) +
+ Jacob Wieland - Spirent    +
+ 10-10-2013 13:08    +
+ 		+ + + + +
+ In principle, I agree with the proposal originally given in the CR description that the restriction at the moment given only for value variables and template variables shall be enlarged to all values and templates. Then, we would not have to repeat that restriction over and over again.
+
+
+
+ + + + + + + + + + +
+ (0011760) +
+ Gyorgy Rethy    +
+ 10-10-2013 17:27    +
(edited on: 10-10-2013 17:47)
+ 		+ + + + +
+ STF decisions on 10-10-2013:
+- the restriction shall not be related to WHAT we use but to WHERE we use it; namely, the restrictions of 11.1 e) and 11.2 e) shall be moved to the relevant clauses (actual parameters, assignment, function return, rotate, concatenation match etc.), thus making them valid for all kind of data objects;
+- definition of partially initialized, note 2 shall not make a distinction between constant/templates/modulepars vs. variables but be valid for all type of data objects;
+- in general, already initialized objects shall not be allowed to be made uninitialized.
+
+
+
+
+
+ + + + + + + + + + +
+ (0011761) +
+ Gyorgy Rethy    +
+ 10-10-2013 17:46    +
+ 		+ + + + +
+ Pls. see CR6430_resolution_v2.doc, changed acc. to the decisions below.
+
+
+
+
+
+ + + + + + + + + + +
+ (0011769) +
+ Jacob Wieland - Spirent    +
+ 11-10-2013 12:24    +
(edited on: 11-10-2013 12:26)
+ 		+ + + + +
+ I still think that 8.2.1. restriction h) is wrong. It would enforce that all module parameters need to be initialized (partially), even the unused ones. When all places that use things explicitly forbid the usage of uninitialized module parameters, then this is completely sufficient to catch errors caused by uninitialized module parameters.
+
+Of course,the same is true for constants and templates. The error would simply be caused by the usage, not by the declaration.
+
+
+
+
+
+ + + + + + + + + + +
+ (0011771) +
+ Jacob Wieland - Spirent    +
+ 11-10-2013 12:29    +
+ 		+ + + + +
+ Also, we dropped this requirement for STF160 that for return, the returned data object must be partially initialized. So, this has to be removed as well.
+
+
+
+ + + + + + + + + + +
+ (0011772) +
+ Jacob Wieland - Spirent    +
+ 11-10-2013 12:30    +
+ 		+ + + + +
+ please see my previous notes
+
+
+
+ + + + + + + + + + +
+ (0011784) +
+ Gyorgy Rethy    +
+ 11-10-2013 14:41    +
+ 		+ + + + +
+ I agree with all your comments, they have been implemented. See and review CR6430_resolution_v3.doc.
+
+
+
+ + + + + + + + + + +
+ (0011793) +
+ Jacob Wieland - Spirent    +
+ 11-10-2013 16:33    +
+ 		+ + + + +
+ okay with me
+
+
+
+ + + + + + + + + + +
+ (0011853) +
+ Ina Schieferdecker    +
+ 28-11-2013 10:56    +
+ 		+ + + + +
+ as proposed with small editorials in v4
+
+ + diff --git a/docs/mantis/CR6431.md b/docs/mantis/CR6431.md new file mode 100644 index 0000000000000000000000000000000000000000..30eb31a5a1dbab36f29eaac39cce499a9179f4ab --- /dev/null +++ b/docs/mantis/CR6431.md @@ -0,0 +1,203 @@ + + + + + + + + + + + + + 0006431: Superfluous rule for component type compatibility - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006431Part 01: TTCN-3 Core LanguageEditorialpublic01-03-2013 12:1112-07-2013 14:00
ReporterTomas Urban 
Assigned ToJacob Wieland - Spirent 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.6.1 (published 2014-06)Fixed in Versionv4.6.1 (published 2014-06) 
Clause Reference(s)5, 6.2.10.1, 6.3.3, Appendix A
Source (company - Author)Elvior
Summary0006431: Superfluous rule for component type compatibility
DescriptionThe chapter 6.3.3 contains a restriction d stating that: "For local template definitions, the identifiers, the types, the formal parameter lists and the assigned template or template field values shall be identical."
+
+However, component type definitions cannot contain local template definitions, so this rule doesn't make any sense and should be removed from the specification.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR6431.doc (182,784) 10-07-2013 17:36
http://oldforge.etsi.org/mantis/file_download.php?file_id=2821&type=bug
doc CR6431_v2.doc (184,832) 12-07-2013 13:23
http://oldforge.etsi.org/mantis/file_download.php?file_id=2848&type=bug
Issue History
Date ModifiedUsernameFieldChange
01-03-2013 12:11Tomas UrbanNew Issue
01-03-2013 12:11Tomas UrbanClause Reference(s) => 6.6.3
01-03-2013 12:11Tomas UrbanSource (company - Author) => Elvior
08-07-2013 15:28Jens GrabowskiProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
08-07-2013 15:28Jens GrabowskiStatusnew => assigned
08-07-2013 15:28Jens GrabowskiAssigned To => Jacob Wieland - Spirent
08-07-2013 18:11Gyorgy RethyTarget Version => v4.6.1 (published 2014-06)
09-07-2013 12:09Jacob Wieland - SpirentNote Added: 0011463
09-07-2013 12:10Jacob Wieland - SpirentClause Reference(s)6.6.3 => 6.3.3
09-07-2013 12:10Jacob Wieland - SpirentNote Added: 0011464
09-07-2013 12:10Jacob Wieland - SpirentDescription Updated
09-07-2013 15:03Jacob Wieland - SpirentNote Added: 0011479
09-07-2013 15:03Jacob Wieland - SpirentNote Edited: 0011479
09-07-2013 15:04Jacob Wieland - SpirentClause Reference(s)6.3.3 => 5, 6.3.3, Appendix A
09-07-2013 15:08Jacob Wieland - SpirentClause Reference(s)5, 6.3.3, Appendix A => 5, 6.2.10.1, 6.3.3, Appendix A
10-07-2013 17:36Jacob Wieland - SpirentFile Added: CR6431.doc
10-07-2013 18:15Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
10-07-2013 18:15Jacob Wieland - SpirentNote Added: 0011526
11-07-2013 09:06Jacob Wieland - SpirentAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
11-07-2013 10:16Jacob Wieland - SpirentStatusassigned => confirmed
11-07-2013 10:52Jacob Wieland - SpirentStatusconfirmed => assigned
11-07-2013 10:52Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Ina Schieferdecker
11-07-2013 10:53Jacob Wieland - SpirentStatusassigned => confirmed
12-07-2013 13:23Ina SchieferdeckerFile Added: CR6431_v2.doc
12-07-2013 13:23Ina SchieferdeckerNote Added: 0011576
12-07-2013 13:24Ina SchieferdeckerStatusconfirmed => assigned
12-07-2013 13:24Ina SchieferdeckerAssigned ToIna Schieferdecker => Jacob Wieland - Spirent
12-07-2013 13:55Jacob Wieland - SpirentStatusassigned => resolved
12-07-2013 13:55Jacob Wieland - SpirentFixed in Version => v4.6.1 (published 2014-06)
12-07-2013 13:55Jacob Wieland - SpirentResolutionopen => fixed
12-07-2013 14:00Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011463) +
+ Jacob Wieland - Spirent    +
+ 09-07-2013 12:09    +
+ 		+ + + + +
+ Agreed.
+
+
+
+ + + + + + + + + + +
+ (0011464) +
+ Jacob Wieland - Spirent    +
+ 09-07-2013 12:10    +
+ 		+ + + + +
+ changed clause reference to proper section
+
+
+
+ + + + + + + + + + +
+ (0011479) +
+ Jacob Wieland - Spirent    +
+ 09-07-2013 15:03    +
+ 		+ + + + +
+ Since it is explicitly allowed in the table in section 5, we decided to allow it also in the BNF. Therefore, the restriction would gain meaning as well.
+
+
+
+
+
+ + + + + + + + + + +
+ (0011526) +
+ Jacob Wieland - Spirent    +
+ 10-07-2013 18:15    +
+ 		+ + + + +
+ please check
+
+
+
+ + + + + + + + + + +
+ (0011576) +
+ Ina Schieferdecker    +
+ 12-07-2013 13:23    +
+ 		+ + + + +
+ BNF rule to be changed as well: CR6431_v2
+
+ + diff --git a/docs/mantis/CR6433.md b/docs/mantis/CR6433.md new file mode 100644 index 0000000000000000000000000000000000000000..50dae9921becb6eb6d2a3e00d6b8118adc9c22ef --- /dev/null +++ b/docs/mantis/CR6433.md @@ -0,0 +1,288 @@ + + + + + + + + + + + + + 0006433: Invalid pattern syntax in regexp examples - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006433Part 01: TTCN-3 Core LanguageEditorialpublic08-03-2013 11:2711-10-2013 12:28
ReporterTomas Urban 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.6.1 (published 2014-06)Fixed in Versionv4.6.1 (published 2014-06) 
Clause Reference(s)C.4.1
Source (company - Author)Elvior
Summary0006433: Invalid pattern syntax in regexp examples
DescriptionThe example section of the regexp predefined function includes this pattern:
+var template charstring myPattern := pattern"([ /t]#(,)date:[ \d\-]#(,);[ /t]#(,)msgno: (\d#(1,3)); (exp)#(0,1))"
+
+It seems that the example author wanted to use #(,) as a quantifier for matching the preceding character set n times (with both upper and lower bounds unlimitted). However, the n-times quantifier format as it is defined in the BNF and Annex B requires at least one bound to be present. Thus, because it cannot be translated as the quantifier, this part shall be interpretted as a literal, matching a hash mark and comma (with a comma forming a group), yielding a different result than shown in the example.
+
+The pattern shall be therefore changed to:
+var template charstring myPattern := pattern"([ /t]#(0,)date:[ \d\-]#(0,);[ /t]#(0,)msgno: (\d#(1,3)); (exp)#(0,1))";
+
+NB: There are many semicolons missing in the regexp function example section. They should be added as well
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR6433_resolution_v1.doc (120,832) 27-08-2013 11:18
http://oldforge.etsi.org/mantis/file_download.php?file_id=2858&type=bug
? regexp_inTheStandard.ttcn (3,386) 27-08-2013 11:18
http://oldforge.etsi.org/mantis/file_download.php?file_id=2859&type=bug
doc CR6433_resolution_v2.doc (120,832) 28-08-2013 10:39
http://oldforge.etsi.org/mantis/file_download.php?file_id=2865&type=bug
doc CR6433_resolution_v3.doc (125,440) 30-08-2013 10:07
http://oldforge.etsi.org/mantis/file_download.php?file_id=2878&type=bug
doc CR6433_resolution_v4.doc (126,464) 11-10-2013 12:28
http://oldforge.etsi.org/mantis/file_download.php?file_id=2926&type=bug
Issue History
Date ModifiedUsernameFieldChange
08-03-2013 11:27Tomas UrbanNew Issue
08-03-2013 11:27Tomas UrbanClause Reference(s) => C.4.1
08-03-2013 11:27Tomas UrbanSource (company - Author) => Elvior
08-03-2013 11:43Tomas UrbanDescription Updated
08-07-2013 15:27Jens GrabowskiStatusnew => assigned
08-07-2013 15:27Jens GrabowskiAssigned To => Gyorgy Rethy
08-07-2013 18:09Gyorgy RethyProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
08-07-2013 18:11Gyorgy RethyTarget Version => v4.6.1 (published 2014-06)
09-07-2013 16:47Jacob Wieland - SpirentNote Added: 0011485
27-08-2013 10:58Gyorgy RethyNote Added: 0011607
27-08-2013 10:59Gyorgy RethyNote Edited: 0011607
27-08-2013 10:59Gyorgy RethyFile Added: regexp_inTheStandard.ttcn
27-08-2013 11:00Gyorgy RethyFile Added: CR6433_resolution_v1.doc
27-08-2013 11:18Gyorgy RethyFile Deleted: regexp_inTheStandard.ttcn
27-08-2013 11:18Gyorgy RethyFile Deleted: CR6433_resolution_v1.doc
27-08-2013 11:18Gyorgy RethyFile Added: CR6433_resolution_v1.doc
27-08-2013 11:18Gyorgy RethyFile Added: regexp_inTheStandard.ttcn
27-08-2013 11:19Gyorgy RethyNote Edited: 0011607
27-08-2013 11:19Gyorgy RethyAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
27-08-2013 17:35Jacob Wieland - SpirentNote Added: 0011613
27-08-2013 17:35Jacob Wieland - SpirentStatusassigned => confirmed
27-08-2013 17:36Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent =>
27-08-2013 17:36Jacob Wieland - SpirentStatusconfirmed => assigned
27-08-2013 17:36Jacob Wieland - SpirentAssigned To => Jacob Wieland - Spirent
27-08-2013 17:36Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
27-08-2013 17:36Jacob Wieland - SpirentStatusassigned => confirmed
28-08-2013 10:39Gyorgy RethyNote Added: 0011616
28-08-2013 10:39Gyorgy RethyFile Added: CR6433_resolution_v2.doc
28-08-2013 10:40Gyorgy RethyStatusconfirmed => assigned
28-08-2013 10:40Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
30-08-2013 10:07Ina SchieferdeckerFile Added: CR6433_resolution_v3.doc
30-08-2013 10:08Ina SchieferdeckerNote Added: 0011651
30-08-2013 10:08Ina SchieferdeckerStatusassigned => confirmed
30-08-2013 10:08Ina SchieferdeckerResolutionopen => fixed
30-08-2013 10:08Ina SchieferdeckerStatusconfirmed => assigned
30-08-2013 10:08Ina SchieferdeckerAssigned ToIna Schieferdecker => Jacob Wieland - Spirent
30-08-2013 13:51Jacob Wieland - SpirentNote Added: 0011661
30-08-2013 13:51Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Ina Schieferdecker
30-08-2013 13:51Jacob Wieland - SpirentStatusassigned => confirmed
30-08-2013 16:28Jacob Wieland - SpirentStatusconfirmed => resolved
30-08-2013 16:28Jacob Wieland - SpirentFixed in Version => v4.6.1 (published 2014-06)
11-10-2013 12:28Ina SchieferdeckerFile Added: CR6433_resolution_v4.doc
11-10-2013 12:28Ina SchieferdeckerStatusresolved => closed
11-10-2013 12:28Ina SchieferdeckerNote Added: 0011770
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011485) +
+ Jacob Wieland - Spirent    +
+ 09-07-2013 16:47    +
+ 		+ + + + +
+ A different approach would be to allow #(,) and #() as a shorthand notation for #(0,) which is one of the most commonly needed repetition operators.
+
+
+
+ + + + + + + + + + +
+ (0011607) +
+ Gyorgy Rethy    +
+ 27-08-2013 10:58    +
(edited on: 27-08-2013 11:19)
+ 		+ + + + +
+ I propose to take both...
+Correct the example acc. to the current syntax and include the two shorthand-s proposed by Jacob. This way the examples will be correct until the new shorthand-s are implemented :-)
+
+See proposed solution in CR6433_resolution_v1.doc.
+
+Pls. review
+
+
+
+
+
+ + + + + + + + + + +
+ (0011613) +
+ Jacob Wieland - Spirent    +
+ 27-08-2013 17:35    +
+ 		+ + + + +
+ fine with me except for a typo in
+
+ "matches the preceding expression at any number of times"
+
+which should be
+
+ "matches the preceding expression any number of times"
+
+
+
+ + + + + + + + + + +
+ (0011616) +
+ Gyorgy Rethy    +
+ 28-08-2013 10:39    +
+ 		+ + + + +
+ Typo corrected in CR6433_resolution_v2.doc.
+
+
+
+ + + + + + + + + + +
+ (0011651) +
+ Ina Schieferdecker    +
+ 30-08-2013 10:08    +
+ 		+ + + + +
+ Added BNF rule - please check
+
+
+
+ + + + + + + + + + +
+ (0011661) +
+ Jacob Wieland - Spirent    +
+ 30-08-2013 13:51    +
+ 		+ + + + +
+ change is correct
+
+
+
+ + + + + + + + + + +
+ (0011770) +
+ Ina Schieferdecker    +
+ 11-10-2013 12:28    +
+ 		+ + + + +
+ as proposed with some technical fixes in v4
+
+ + diff --git a/docs/mantis/CR6434.md b/docs/mantis/CR6434.md new file mode 100644 index 0000000000000000000000000000000000000000..78742226c2e279f218e3230bbefe45448017a12b --- /dev/null +++ b/docs/mantis/CR6434.md @@ -0,0 +1,73 @@ + + + + + + + + + + + + + 0006434: Invalid BNF rule for n-times quantifier - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006434Part 01: TTCN-3 Core LanguageTechnicalpublic08-03-2013 11:3711-07-2013 15:16
ReporterTomas Urban 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.6.1 (published 2014-06)Fixed in Versionv4.6.1 (published 2014-06) 
Clause Reference(s)A.1.6.1.3
Source (company - Author)Elvior
Summary0006434: Invalid BNF rule for n-times quantifier
DescriptionThe rule 116 in its current format allows only single digits as a boundaries in n-times quantifier:
+("#" (Num |
+("(" Num "," [Num] ")") | ("(" "," Num ")")
+))
+
+The rule shall be changed to:
+("#" (Num |
+("(" Number "," [Number] ")") | ("(" "," Number ")")
+))
+
+Note: the first Num shall be left unchanged, because the #n form requires a single digit.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
08-03-2013 11:37Tomas UrbanNew Issue
08-03-2013 11:37Tomas UrbanClause Reference(s) => A.1.6.1.3
08-03-2013 11:37Tomas UrbanSource (company - Author) => Elvior
08-07-2013 15:26Jens GrabowskiProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
08-07-2013 15:26Jens GrabowskiStatusnew => assigned
08-07-2013 15:26Jens GrabowskiAssigned To => Ina Schieferdecker
08-07-2013 18:08Gyorgy RethyTarget Version => v4.6.1 (published 2014-06)
09-07-2013 14:08Ina SchieferdeckerNote Added: 0011474
11-07-2013 15:15Ina SchieferdeckerStatusassigned => resolved
11-07-2013 15:15Ina SchieferdeckerFixed in Version => v4.6.1 (published 2014-06)
11-07-2013 15:15Ina SchieferdeckerResolutionopen => fixed
11-07-2013 15:16Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011474) +
+ Ina Schieferdecker    +
+ 09-07-2013 14:08    +
+ 		+ + + + +
+ To be changed as proposed.
+
+ + diff --git a/docs/mantis/CR6438.md b/docs/mantis/CR6438.md new file mode 100644 index 0000000000000000000000000000000000000000..2bc86548b4216230a1d52a0200e96deb49526ef7 --- /dev/null +++ b/docs/mantis/CR6438.md @@ -0,0 +1,167 @@ + + + + + + + + + + + + + 0006438: Restriction on port mapping parameters - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006438Part 01: TTCN-3 Core LanguageTechnicalpublic13-03-2013 07:2811-07-2013 16:34
ReporterTomas Urban 
Assigned ToJacob Wieland - Spirent 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.6.1 (published 2014-06)Fixed in Versionv4.6.1 (published 2014-06) 
Clause Reference(s)6.2.9
Source (company - Author)Elvior
Summary0006438: Restriction on port mapping parameters
DescriptionThe type of map/unmap parameters shall be restricted in a similar way as in case of signatures (values of these types shall not pass the TRI boundary):
+
+Map and unmap parameters of a port type shall not be of port, component or default type or of structured types having fields of port, component or default type.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0006447closed Ina Schieferdecker Additional restrictions on port mapping and unmapping parameters 
Attached Filesdocx CR6438.docx (162,490) 10-07-2013 15:43
http://oldforge.etsi.org/mantis/file_download.php?file_id=2815&type=bug
docx CR6438_v2.docx (163,175) 11-07-2013 11:43
http://oldforge.etsi.org/mantis/file_download.php?file_id=2827&type=bug
Issue History
Date ModifiedUsernameFieldChange
13-03-2013 07:28Tomas UrbanNew Issue
13-03-2013 07:28Tomas UrbanClause Reference(s) => 6.2.9
13-03-2013 07:28Tomas UrbanSource (company - Author) => Elvior
08-07-2013 15:24Jens GrabowskiProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
08-07-2013 15:25Jens GrabowskiRelationship addedrelated to 0006447
08-07-2013 15:25Jens GrabowskiStatusnew => assigned
08-07-2013 15:25Jens GrabowskiAssigned To => Jacob Wieland - Spirent
08-07-2013 18:07Gyorgy RethyTarget Version => v4.6.1 (published 2014-06)
09-07-2013 12:15Jacob Wieland - SpirentNote Added: 0011465
10-07-2013 15:43Jacob Wieland - SpirentFile Added: CR6438.docx
10-07-2013 15:43Jacob Wieland - SpirentNote Added: 0011512
10-07-2013 19:32Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
10-07-2013 19:32Jacob Wieland - SpirentNote Added: 0011528
11-07-2013 09:05Jacob Wieland - SpirentAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
11-07-2013 10:17Jacob Wieland - SpirentStatusassigned => confirmed
11-07-2013 10:49Jacob Wieland - SpirentStatusconfirmed => assigned
11-07-2013 10:49Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Ina Schieferdecker
11-07-2013 10:54Jacob Wieland - SpirentStatusassigned => confirmed
11-07-2013 11:43Ina SchieferdeckerFile Added: CR6438_v2.docx
11-07-2013 11:44Ina SchieferdeckerStatusconfirmed => assigned
11-07-2013 11:44Ina SchieferdeckerAssigned ToIna Schieferdecker => Jacob Wieland - Spirent
11-07-2013 11:59Jacob Wieland - SpirentStatusassigned => resolved
11-07-2013 11:59Jacob Wieland - SpirentFixed in Version => v4.6.1 (published 2014-06)
11-07-2013 11:59Jacob Wieland - SpirentResolutionopen => fixed
11-07-2013 11:59Jacob Wieland - SpirentNote Added: 0011540
11-07-2013 16:34Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011465) +
+ Jacob Wieland - Spirent    +
+ 09-07-2013 12:15    +
+ 		+ + + + +
+ What about unions and anytype. Should the restriction also be enforced if the chosen alternative does not contain component/timer/port/default?
+
+
+
+ + + + + + + + + + +
+ (0011512) +
+ Jacob Wieland - Spirent    +
+ 10-07-2013 15:43    +
+ 		+ + + + +
+ added proposal
+
+
+
+ + + + + + + + + + +
+ (0011528) +
+ Jacob Wieland - Spirent    +
+ 10-07-2013 19:32    +
+ 		+ + + + +
+ please check and if okay also resolve related CR
+
+
+
+ + + + + + + + + + +
+ (0011540) +
+ Jacob Wieland - Spirent    +
+ 11-07-2013 11:59    +
+ 		+ + + + +
+ fine with me
+
+ + diff --git a/docs/mantis/CR6440.md b/docs/mantis/CR6440.md new file mode 100644 index 0000000000000000000000000000000000000000..28f588038c5ef4605edbeb3d3bf1b1013e706cf2 --- /dev/null +++ b/docs/mantis/CR6440.md @@ -0,0 +1,241 @@ + + + + + + + + + + + + + 0006440: Restriction on imported enumerated types - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006440Part 01: TTCN-3 Core LanguageEditorialpublic19-03-2013 08:2127-08-2013 17:10
ReporterTomas Urban 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.6.1 (published 2014-06)Fixed in Versionv4.6.1 (published 2014-06) 
Clause Reference(s)6.2.4
Source (company - Author)Elvior
Summary0006440: Restriction on imported enumerated types
DescriptionAs a resolution of CR 5607, the following rule was added to the specification:
+"When a TTCN-3 global or local definition is declared using an imported enumerated type, the name of that definition shall not be the same as any of the enumerated values of that type."
+
+This rule imposes unnecessary restriction on function, altstep, type, test case, signature or parameterized template definitions. The rule shall be related only to constant, module parameters, variables, formal parameters and non-parameterized templates.
+
+Proposal of a modified rule:
+Constants, module parameters, variables, formal parameters and non-parameterized templates of an imported enumerated type shall not have the same identifier as any of enumerated values of that type.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0005607closed Ina Schieferdecker definitions of an enum type should not have the same name as an enum value in that type 
Attached Filesdoc CR6440.doc (161,792) 10-07-2013 18:09
http://oldforge.etsi.org/mantis/file_download.php?file_id=2824&type=bug
doc CR6440_resolution_v2.doc (161,792) 12-07-2013 09:30
http://oldforge.etsi.org/mantis/file_download.php?file_id=2843&type=bug
doc CR6440_resolution_v3.doc (162,304) 12-07-2013 10:57
http://oldforge.etsi.org/mantis/file_download.php?file_id=2845&type=bug
Issue History
Date ModifiedUsernameFieldChange
19-03-2013 08:21Tomas UrbanNew Issue
19-03-2013 08:21Tomas UrbanClause Reference(s) => 6.2.4
19-03-2013 08:21Tomas UrbanSource (company - Author) => Elvior
19-03-2013 08:22Tomas UrbanRelationship addedrelated to 0005607
19-03-2013 08:22Tomas UrbanDescription Updated
08-07-2013 15:22Jens GrabowskiProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
08-07-2013 15:23Jens GrabowskiStatusnew => assigned
08-07-2013 15:23Jens GrabowskiAssigned To => Jacob Wieland - Spirent
08-07-2013 18:06Gyorgy RethyTarget Version => v4.6.1 (published 2014-06)
09-07-2013 12:03Jacob Wieland - SpirentNote Added: 0011462
10-07-2013 18:09Jacob Wieland - SpirentFile Added: CR6440.doc
10-07-2013 18:10Jacob Wieland - SpirentNote Added: 0011522
10-07-2013 18:11Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
10-07-2013 18:11Jacob Wieland - SpirentNote Added: 0011523
12-07-2013 09:25Gyorgy RethyNote Added: 0011568
12-07-2013 09:30Gyorgy RethyFile Added: CR6440_resolution_v2.doc
12-07-2013 09:34Gyorgy RethyAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
12-07-2013 09:34Gyorgy RethyStatusassigned => confirmed
12-07-2013 10:53Jacob Wieland - SpirentStatusconfirmed => assigned
12-07-2013 10:54Jacob Wieland - SpirentNote Added: 0011572
12-07-2013 10:54Jacob Wieland - SpirentStatusassigned => confirmed
12-07-2013 10:55Jacob Wieland - SpirentStatusconfirmed => assigned
12-07-2013 10:55Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Ina Schieferdecker
12-07-2013 10:57Jacob Wieland - SpirentFile Added: CR6440_resolution_v3.doc
12-07-2013 10:57Jacob Wieland - SpirentNote Deleted: 0011572
12-07-2013 10:58Jacob Wieland - SpirentNote Added: 0011573
12-07-2013 10:58Jacob Wieland - SpirentStatusassigned => confirmed
27-08-2013 17:09Ina SchieferdeckerNote Added: 0011612
27-08-2013 17:09Ina SchieferdeckerStatusconfirmed => resolved
27-08-2013 17:09Ina SchieferdeckerResolutionopen => fixed
27-08-2013 17:09Ina SchieferdeckerFixed in Version => v4.6.1 (published 2014-06)
27-08-2013 17:10Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011462) +
+ Jacob Wieland - Spirent    +
+ 09-07-2013 12:03    +
+ 		+ + + + +
+ Since that is the gist of what the restriction aimed at, I have no problem with this clarification. "Using" here was meant as "Having" (which is only possible for the non-parameterized declarations).
+
+Parameterized templates which have only parameters with default-values/templates must also fulfil this restriction to avoid the ambiguity. Of course, this is only relevant if the right-hand-side of the template definition is a function call.
+
+
+
+ + + + + + + + + + +
+ (0011522) +
+ Jacob Wieland - Spirent    +
+ 10-07-2013 18:10    +
+ 		+ + + + +
+ Made restriction more clear.
+
+
+
+ + + + + + + + + + +
+ (0011523) +
+ Jacob Wieland - Spirent    +
+ 10-07-2013 18:11    +
+ 		+ + + + +
+ please check
+
+
+
+ + + + + + + + + + +
+ (0011568) +
+ Gyorgy Rethy    +
+ 12-07-2013 09:25    +
+ 		+ + + + +
+ See updated text in CR6440_resolution_v2.doc. No technical change, just adjusted the text as discussed.
+
+
+
+ + + + + + + + + + +
+ (0011573) +
+ Jacob Wieland - Spirent    +
+ 12-07-2013 10:58    +
+ 		+ + + + +
+ we missed formal parameters, I amended the proposal accordingly, please check
+
+
+
+ + + + + + + + + + +
+ (0011612) +
+ Ina Schieferdecker    +
+ 27-08-2013 17:09    +
+ 		+ + + + +
+ As proposed
+
+ + diff --git a/docs/mantis/CR6446.md b/docs/mantis/CR6446.md new file mode 100644 index 0000000000000000000000000000000000000000..3b8586c5b5af8a3a0209f19ee15658483fd04b7f --- /dev/null +++ b/docs/mantis/CR6446.md @@ -0,0 +1,105 @@ + + + + + + + + + + + + + 0006446: Restrictions on the use of the configuration type - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Config & Deployment Support (ES 202 781)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006446Ext Pack: Config & Deployment Support (ES 202 781)Technicalpublic21-03-2013 08:5026-12-2013 13:41
ReporterTomas Urban 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv1.1.1 (published 2010-08) 
Target Versionv1.3.1 (published 2014-06)Fixed in Version 
Clause Reference(s)5.1
Source (company - Author)Elvior
TS version 
Summary0006446: Restrictions on the use of the configuration type
DescriptionThe configuration type shall have similar restrictions as the default type:
+
+1) The configuration type cannot be constrained
+2) The anytype doesn't include the configuration type
+3) Module parameters shall not be of the configuration type
+4) Signature parameters shall not be of the configuration type
+5) Templates shall not be of the configuration type
+6) Templates shall not be of a structured type that contains fields of the configuration type on any level of nesting
+7) External functions are not allowed to contain parameters or return value of the configuration type
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR6446.doc (169,472) 29-11-2013 14:06
http://oldforge.etsi.org/mantis/file_download.php?file_id=2969&type=bug
Issue History
Date ModifiedUsernameFieldChange
21-03-2013 08:50Tomas UrbanNew Issue
21-03-2013 08:50Tomas UrbanClause Reference(s) => 5.1
21-03-2013 08:50Tomas UrbanSource (company - Author) => Elvior
21-03-2013 08:50Tomas UrbanTS version =>
08-07-2013 15:20Jens GrabowskiStatusnew => assigned
08-07-2013 15:20Jens GrabowskiAssigned To => Jens Grabowski
08-07-2013 18:06Gyorgy RethyTarget Version => v1.3.1 (published 2014-06)
29-11-2013 14:06Jacob Wieland - SpirentFile Added: CR6446.doc
29-11-2013 14:06Jacob Wieland - SpirentNote Added: 0011879
29-11-2013 14:06Jacob Wieland - SpirentStatusassigned => confirmed
26-12-2013 13:41Jens GrabowskiNote Added: 0011900
26-12-2013 13:41Jens GrabowskiStatusconfirmed => closed
26-12-2013 13:41Jens GrabowskiResolutionopen => fixed
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011879) +
+ Jacob Wieland - Spirent    +
+ 29-11-2013 14:06    +
+ 		+ + + + +
+ implemented as requested with slight re-wording
+
+
+
+ + + + + + + + + + +
+ (0011900) +
+ Jens Grabowski    +
+ 26-12-2013 13:41    +
+ 		+ + + + +
+ implemented as proposed
+
+ + diff --git a/docs/mantis/CR6447.md b/docs/mantis/CR6447.md new file mode 100644 index 0000000000000000000000000000000000000000..903e9ecc3d9ae42ed951f247a31dbf5d22f70b6a --- /dev/null +++ b/docs/mantis/CR6447.md @@ -0,0 +1,172 @@ + + + + + + + + + + + + + 0006447: Additional restrictions on port mapping and unmapping parameters - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006447Part 01: TTCN-3 Core LanguageTechnicalpublic21-03-2013 09:0711-07-2013 16:35
ReporterTomas Urban 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.6.1 (published 2014-06)Fixed in Versionv4.6.1 (published 2014-06) 
Clause Reference(s)6.2.9
Source (company - Author)Elvior
Summary0006447: Additional restrictions on port mapping and unmapping parameters
DescriptionThe following restrictions on types used for port mapping and unmapping parameters shall be added:
+
+d) Port mapping and unmapping parameters shall not be of a component, default or port type.
+e) Port mappping and unmapping parameters shall not be of a structured type that contains fields of a component, default or port type on any level of nesting.
+
+Similar rule should be added to the configuration and deployment package regarding the configuration type.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0006438closed Jacob Wieland - Spirent Restriction on port mapping parameters 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
21-03-2013 09:07Tomas UrbanNew Issue
21-03-2013 09:07Tomas UrbanClause Reference(s) => 6.2.9
21-03-2013 09:07Tomas UrbanSource (company - Author) => Elvior
08-07-2013 15:19Jens GrabowskiNote Added: 0011451
08-07-2013 15:20Jens GrabowskiStatusnew => assigned
08-07-2013 15:20Jens GrabowskiAssigned To => Jacob Wieland - Spirent
08-07-2013 15:25Jens GrabowskiRelationship addedrelated to 0006438
08-07-2013 18:06Gyorgy RethyTarget Version => v4.6.1 (published 2014-06)
08-07-2013 23:18Jacob Wieland - SpirentNote Added: 0011454
10-07-2013 11:06Gyorgy RethyNote Added: 0011496
10-07-2013 11:42Gyorgy RethyNote Edited: 0011496
10-07-2013 15:44Jacob Wieland - SpirentNote Added: 0011513
10-07-2013 19:31Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
11-07-2013 09:07Jacob Wieland - SpirentAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
11-07-2013 10:15Jacob Wieland - SpirentStatusassigned => confirmed
11-07-2013 10:56Jacob Wieland - SpirentStatusconfirmed => assigned
11-07-2013 10:56Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Tomas Urban
11-07-2013 10:56Jacob Wieland - SpirentAssigned ToTomas Urban => Ina Schieferdecker
11-07-2013 10:56Jacob Wieland - SpirentStatusassigned => confirmed
11-07-2013 16:34Ina SchieferdeckerStatusconfirmed => resolved
11-07-2013 16:34Ina SchieferdeckerFixed in Version => v4.6.1 (published 2014-06)
11-07-2013 16:34Ina SchieferdeckerResolutionopen => fixed
11-07-2013 16:35Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011451) +
+ Jens Grabowski    +
+ 08-07-2013 15:19    +
+ 		+ + + + +
+ CR is related to Part 1 and the Configuration and Deployment package.
+
+
+
+ + + + + + + + + + +
+ (0011454) +
+ Jacob Wieland - Spirent    +
+ 08-07-2013 23:18    +
+ 		+ + + + +
+ Would it not be prudent to say that the same restrictions as for external function parameters apply (as in essence, this is a special external function call?)
+
+
+
+ + + + + + + + + + +
+ (0011496) +
+ Gyorgy Rethy    +
+ 10-07-2013 11:06    +
(edited on: 10-07-2013 11:42)
+ 		+ + + + +
+ STF decision 2013-07-10: Add the restrictions to the map/unmap parameters.
+
+
+
+
+
+ + + + + + + + + + +
+ (0011513) +
+ Jacob Wieland - Spirent    +
+ 10-07-2013 15:44    +
+ 		+ + + + +
+ see proposal for CR6438
+
+ + diff --git a/docs/mantis/CR6448.md b/docs/mantis/CR6448.md new file mode 100644 index 0000000000000000000000000000000000000000..47c5220edd3ea2ad69e88deba177eb4ca2ded84e --- /dev/null +++ b/docs/mantis/CR6448.md @@ -0,0 +1,431 @@ + + + + + + + + + + + + + 0006448: Rules for external function parameters - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006448Part 01: TTCN-3 Core LanguageTechnicalpublic21-03-2013 10:3127-08-2014 13:17
ReporterTomas Urban 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.6.1 (published 2014-06)Fixed in Versionv4.6.1 (published 2014-06) 
Clause Reference(s)16.1.3
Source (company - Author)Elvior
Summary0006448: Rules for external function parameters
DescriptionThere's a mismatch between external function syntactical structure and restrictions. The syntactical part allows to use port and timer parameters, but the restriction a) says that no port or timer operations are allowed inside external functions.
+
+Proposal:
+External functions should have the same restrictions as signatures, i.e. only value parameters shall be allowed (with component and default type forbidden). Port, template and timer parameters shall be completely forbidden. That's because the parameters are typically passed over TRI in an encoded form and ports, timers, components, default values and matching symbols cannot be encoded.
+
+If the above mentioned proposal is not acceptable, something has to be done with the TRI, because its current form is not capable of passing ports, timers, components, default values and matching symbols to the PA.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0006793closed Tomas Urban Part 06: TTCN-3 Control Interface Value Interface is underspecified/inconsistent for Templates 
Attached Filesdoc CR6448_resolution_v1.doc (178,176) 12-07-2013 11:50
http://oldforge.etsi.org/mantis/file_download.php?file_id=2846&type=bug
doc CR6448_resolution_v2.doc (179,200) 12-07-2013 12:00
http://oldforge.etsi.org/mantis/file_download.php?file_id=2847&type=bug
Issue History
Date ModifiedUsernameFieldChange
21-03-2013 10:31Tomas UrbanNew Issue
21-03-2013 10:31Tomas UrbanClause Reference(s) => 16.1.3
21-03-2013 10:31Tomas UrbanSource (company - Author) => Elvior
08-07-2013 15:16Jens GrabowskiStatusnew => assigned
08-07-2013 15:16Jens GrabowskiAssigned To => Gyorgy Rethy
08-07-2013 18:05Gyorgy RethyTarget Version => v4.6.1 (published 2014-06)
09-07-2013 09:43Gyorgy RethyNote Added: 0011455
09-07-2013 13:34Jacob Wieland - SpirentNote Added: 0011466
09-07-2013 13:37Jacob Wieland - SpirentNote Added: 0011467
10-07-2013 09:01Gyorgy RethyNote Added: 0011492
10-07-2013 09:23Jacob Wieland - SpirentNote Added: 0011494
10-07-2013 12:04Gyorgy RethyNote Edited: 0011455
10-07-2013 12:12Gyorgy RethyNote Added: 0011498
10-07-2013 12:24Gyorgy RethyNote Added: 0011499
10-07-2013 14:09Jacob Wieland - SpirentNote Added: 0011503
10-07-2013 14:10Jacob Wieland - SpirentNote Added: 0011504
12-07-2013 10:34Gyorgy RethyNote Added: 0011569
12-07-2013 11:50Gyorgy RethyFile Added: CR6448_resolution_v1.doc
12-07-2013 11:51Gyorgy RethyAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
12-07-2013 11:51Gyorgy RethyStatusassigned => confirmed
12-07-2013 12:00Jacob Wieland - SpirentFile Added: CR6448_resolution_v2.doc
12-07-2013 12:00Jacob Wieland - SpirentStatusconfirmed => assigned
12-07-2013 12:01Jacob Wieland - SpirentNote Added: 0011575
12-07-2013 12:01Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
12-07-2013 12:01Jacob Wieland - SpirentStatusassigned => confirmed
12-07-2013 12:24Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
12-07-2013 12:24Gyorgy RethyStatusconfirmed => resolved
12-07-2013 12:24Gyorgy RethyResolutionopen => fixed
12-07-2013 14:19Ina SchieferdeckerStatusresolved => closed
12-07-2013 14:19Ina SchieferdeckerFixed in Version => v4.6.1 (published 2014-06)
27-08-2014 13:17Jacob Wieland - SpirentRelationship addedrelated to 0006793
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011455) +
+ Gyorgy Rethy    +
+ 09-07-2013 09:43    +
(edited on: 10-07-2013 12:04)
+ 		+ + + + +
+ My proposal:
+1) Disallow port, timer, component and default (template pars is discussed in item 2 below).
+change the BNF:
+233.ExtFunctionDef ::= ExtKeyword FunctionKeyword Identifier "(" [ExtFunctionFormalParList] ")" [ReturnType] /* Gyorgy: Ext... is added to FunctionFormalParList */
+234.ExtKeyword ::= "external"
+/* Gyorgy: new terminals */
+235.ExtFunctionFormalParList ::= ExtFunctionFormalPar {"," ExtFunctionFormalPar}
+236.ExtFunctionFormalPar ::= FormalValuePar | FormalTemplatePar
+
+Change clause 16.1.3 External functions, restriction a) to:
+a) External functions shall have value and template formal parameters only and are not allowed to contain component, port, timer or default handling operations.
+
+
+2) Passing template parameters to external functions is used in code today, forbidding this would be backward incompatible. In some cases at functional testing both sending and receiving templates are created dynamically, sometimes using external functions, e.g. to handle data stored in databases, test management systems etc. These external functions may return ? or * in inout parameters, for example because this is explicitly specified by the user (pls. note, it not possible to check in TTCN-3 today, if a field or template contains matching, it has to be decided within the external function) or e.g. the field does not have a corresponding data in the database. It has to be discussed how to encode matching mechanisms, instead of restricting the usability of the language.
+
+
+
+
+
+ + + + + + + + + + +
+ (0011466) +
+ Jacob Wieland - Spirent    +
+ 09-07-2013 13:34    +
+ 		+ + + + +
+ the problem is more how to determine the presence and kinds of matching mechanisms in the template to be encoded (if necessary).
+
+In my experience, though, external functions are implemented with a pseudo-encoding for the parameters anyway (just encoding some reference to the actual value/template) which later on led to the XTRI approach where no encoding is necessary.
+
+Still, it could be useful to make information about the mechanisms at runtime accessible. Internally it needs to be accessible for logging purposes anyway so this information just needs to be exposed via a standardized API.
+
+
+
+ + + + + + + + + + +
+ (0011467) +
+ Jacob Wieland - Spirent    +
+ 09-07-2013 13:37    +
+ 		+ + + + +
+ Also, I see no reason why to restrict the parameters on ports, timers and components (or even default). For these, there are actual entities present in TRI(TriComponentId, TriPortId, TriTimerId), just not in the current value-universe (which would have to be enlarged for those).
+
+
+
+ + + + + + + + + + +
+ (0011492) +
+ Gyorgy Rethy    +
+ 10-07-2013 09:01    +
+ 		+ + + + +
+ The reason of forbidding port, timer, component and default parameters is not technical. These active TTCN-3 objects determine the component behaviour e.g. the snapshots, and we do not want that the user changes the state of these objects outside of the TTCN-3 code. These objects shall be under the control of the TE to secure tool robustness and stability.
+
+
+
+ + + + + + + + + + +
+ (0011494) +
+ Jacob Wieland - Spirent    +
+ 10-07-2013 09:23    +
+ 		+ + + + +
+ since there will always be ways around this access restriction (by giving pseudo-references to these objects to the TRI instead of the actual values and then letting the tool de-reference these references again) I don't think that such a restriction helps very much, it just makes code more complicated in case that you do need access to this kind of thing (and know what you are doing).
+
+What should be standardized should be the same restriction as in the language itself that the Test Adaptation needs to adhere to, i.e. no state-changing operations during a snapshot. Why read-access should be restricted is beyond me.
+
+
+
+ + + + + + + + + + +
+ (0011498) +
+ Gyorgy Rethy    +
+ 10-07-2013 12:12    +
+ 		+ + + + +
+ If the user or a tool vendor wants to make its test system hard to control (potentially unstable) and hard to debug, by hacking it, this is his or her problem. The decision was many years ago that the language shall not support doing this.
+
+The decision was that TTCN-3 active objects shall remain under the full control of the TTCN-3 tool. The CR does not require and not reasoning to change this decision, just requests making the BNF consistent with the above decision.
+
+
+
+ + + + + + + + + + +
+ (0011499) +
+ Gyorgy Rethy    +
+ 10-07-2013 12:24    +
+ 		+ + + + +
+ STF decision 2013-07-10: Proposed solution is OK, change the BNF as proposed by Gyorgy, allow template parameters and add TRI encoding for matching mechanisms: approach should be similar to TLI: distinc the very basic matching mechanism like ? and *, and the rest should be strings.
+
+
+
+ + + + + + + + + + +
+ (0011503) +
+ Jacob Wieland - Spirent    +
+ 10-07-2013 14:09    +
+ 		+ + + + +
+ before adding this new restriction which would introduce possible backward incompatibility for existing test suites, we should ask the tool vendors if they know if this feature (of ports or timers as parameters) is used anywhere.
+
+
+
+ + + + + + + + + + +
+ (0011504) +
+ Jacob Wieland - Spirent    +
+ 10-07-2013 14:10    +
+ 		+ + + + +
+ Also, we should clarify what timer and port handling operations are (I guess it should be all operation ts that change the state of a port or timer) that are disallowed to be used by external functions.
+
+
+
+ + + + + + + + + + +
+ (0011569) +
+ Gyorgy Rethy    +
+ 12-07-2013 10:34    +
+ 		+ + + + +
+ OK, Jacob is correct, it could be better to keep backward compatibility and instead of a new restriction allow operations that do not make harm to the test system. See my first draft text proposal in CR6448_resolution_v1.doc.
+
+
+
+ + + + + + + + + + +
+ (0011575) +
+ Jacob Wieland - Spirent    +
+ 12-07-2013 12:01    +
+ 		+ + + + +
+ apart from some generalization (because now we allow also templates in component types) in 16.1. restriction i), it's fine with me
+
+ + diff --git a/docs/mantis/CR6449.md b/docs/mantis/CR6449.md new file mode 100644 index 0000000000000000000000000000000000000000..9082d2891567e1a3d176b3e896a087b122abddca --- /dev/null +++ b/docs/mantis/CR6449.md @@ -0,0 +1,310 @@ + + + + + + + + + + + + + 0006449: Invalid note in the chapter 10 - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006449Part 01: TTCN-3 Core LanguageEditorialpublic21-03-2013 12:5511-07-2013 16:47
ReporterTomas Urban 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.6.1 (published 2014-06)Fixed in Versionv4.6.1 (published 2014-06) 
Clause Reference(s)10
Source (company - Author)Elvior
Summary0006449: Invalid note in the chapter 10
DescriptionThe chapter 10 (declaring constants) contains the following note:
+The only value that can be assigned to constants of default and component types is the special value null.
+
+This note is correct only for component constants declared in the module declaration part. However, component constants declared inside code blocks and default constants can have other values that null as demonstrated in the following examples:
+
+// valid in a module declaration part
+altstep a()
+{
+  [] any timer.timeout{};
+}
+const default constDefault := activate(a());
+
+// valid inside a code block
+testcase TC() runs on MyComponent system MySystem
+{
+  const MyComponent constPtc := MyComponent.create;
+  ...
+}
+
+I propose to remove the note from the specification.
+
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR6449.doc (200,192) 11-07-2013 15:58
http://oldforge.etsi.org/mantis/file_download.php?file_id=2834&type=bug
Issue History
Date ModifiedUsernameFieldChange
21-03-2013 12:55Tomas UrbanNew Issue
21-03-2013 12:55Tomas UrbanClause Reference(s) => 10
21-03-2013 12:55Tomas UrbanSource (company - Author) => Elvior
08-07-2013 15:13Jens GrabowskiStatusnew => assigned
08-07-2013 15:13Jens GrabowskiAssigned To => Gyorgy Rethy
08-07-2013 18:05Gyorgy RethyTarget Version => v4.6.1 (published 2014-06)
09-07-2013 16:49Jacob Wieland - SpirentNote Added: 0011486
10-07-2013 08:27Gyorgy RethyNote Added: 0011489
10-07-2013 08:27Gyorgy RethyNote Added: 0011490
10-07-2013 08:28Gyorgy RethyNote Deleted: 0011490
10-07-2013 12:26Gyorgy RethyNote Added: 0011500
10-07-2013 12:26Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
10-07-2013 12:26Gyorgy RethyStatusassigned => resolved
11-07-2013 12:09Ina SchieferdeckerNote Added: 0011541
11-07-2013 12:09Ina SchieferdeckerStatusresolved => assigned
11-07-2013 12:09Ina SchieferdeckerAssigned ToIna Schieferdecker => Jacob Wieland - Spirent
11-07-2013 12:30Jacob Wieland - SpirentNote Added: 0011543
11-07-2013 12:31Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Ina Schieferdecker
11-07-2013 12:31Jacob Wieland - SpirentStatusassigned => confirmed
11-07-2013 13:58Ina SchieferdeckerNote Added: 0011546
11-07-2013 13:59Ina SchieferdeckerStatusconfirmed => assigned
11-07-2013 13:59Ina SchieferdeckerAssigned ToIna Schieferdecker => Jacob Wieland - Spirent
11-07-2013 15:58Jacob Wieland - SpirentFile Added: CR6449.doc
11-07-2013 15:59Jacob Wieland - SpirentNote Added: 0011554
11-07-2013 15:59Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Ina Schieferdecker
11-07-2013 15:59Jacob Wieland - SpirentStatusassigned => confirmed
11-07-2013 16:47Ina SchieferdeckerStatusconfirmed => resolved
11-07-2013 16:47Ina SchieferdeckerFixed in Version => v4.6.1 (published 2014-06)
11-07-2013 16:47Ina SchieferdeckerResolutionopen => fixed
11-07-2013 16:47Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011486) +
+ Jacob Wieland - Spirent    +
+ 09-07-2013 16:49    +
+ 		+ + + + +
+ I concur.
+
+
+
+ + + + + + + + + + +
+ (0011489) +
+ Gyorgy Rethy    +
+ 10-07-2013 08:27    +
+ 		+ + + + +
+ Tomáš's comment is correct. I propose to correct the note instead removing it completely:
+
+Current text:
+NOTE: The only value that can be assigned to constants of default and component types is the special value null.
+
+Corrected text:
+NOTE: The only value that can be assigned to global and component constants of default and component types is the special value null.
+
+
+
+ + + + + + + + + + +
+ (0011500) +
+ Gyorgy Rethy    +
+ 10-07-2013 12:26    +
+ 		+ + + + +
+ STF decision 2013-07-10: proposed solution is OK.
+
+
+
+ + + + + + + + + + +
+ (0011541) +
+ Ina Schieferdecker    +
+ 11-07-2013 12:09    +
+ 		+ + + + +
+ Better to say
+
+NOTE: The only value that can be assigned to global constants being of default or component types and to constants within component types being of default or component types is the special value null.
+
+
+
+ + + + + + + + + + +
+ (0011543) +
+ Jacob Wieland - Spirent    +
+ 11-07-2013 12:30    +
+ 		+ + + + +
+ the terms component variable and component constant should be defined in the definitions section (as variables/constants defined inside a component type) to avoid ambiguity. All places which use the terms component variable or component constant differently (i.e. with the meaning variable or constant of type component) should be changed accordingly.
+
+Additionally, for completeness sake, the terms component timer, component port and component template could also be defined in the definitions section as timers, ports or templates defined inside a component type.
+
+
+
+ + + + + + + + + + +
+ (0011546) +
+ Ina Schieferdecker    +
+ 11-07-2013 13:58    +
+ 		+ + + + +
+ Then:
+
+"NOTE: The only value that can be assigned to global constants or to component constants of default or component types is the special value null."
+
+Change in F.1.1 to
+"... which is typically bound to a variable of component type. The behaviour related to a variable of component type ..."
+
+Add in 3.1
+"component constant - a constant defined in a component type
+component port - a port defined in a component type
+component template- a template defined in a component type
+component timer - a timer defined in a component type
+component variable - a variable defined in a component type"
+
+
+
+ + + + + + + + + + +
+ (0011554) +
+ Jacob Wieland - Spirent    +
+ 11-07-2013 15:59    +
+ 		+ + + + +
+ please check
+
+ + diff --git a/docs/mantis/CR6450.md b/docs/mantis/CR6450.md new file mode 100644 index 0000000000000000000000000000000000000000..c598372dc40405211f14d37d894a1d0f25d6eb8c --- /dev/null +++ b/docs/mantis/CR6450.md @@ -0,0 +1,221 @@ + + + + + + + + + + + + + 0006450: Some typos in template concatenation examples - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006450Part 01: TTCN-3 Core LanguageEditorialpublic21-03-2013 20:4011-07-2013 15:43
ReporterGyorgy Rethy 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.6.1 (published 2014-06)Fixed in Versionv4.6.1 (published 2014-06) 
Clause Reference(s)15.11
Source (company - Author)L.M.Ericsson
Summary0006450: Some typos in template concatenation examples
DescriptionIn example 2 of clause 15.11:
+1)
+    template RecofChar t_MyRecofChar := {"ABC"} & {"D?", "EF"};
+        // results the template {"ABC", "D", "EF" }
+
+
+it should be:
+        // results the template {"ABC", "D?", "EF" }
+
+2)
+    template RecofChar t_MyRecofCharPar (integer N):= { "ABC" }, ? * length(N) & { "EF" };
+
+should be:
+    template RecofChar t_MyRecofCharPar (integer N):= { "ABC" }, * length(N) & { "EF" };
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
21-03-2013 20:40Gyorgy RethyNew Issue
21-03-2013 20:40Gyorgy RethyClause Reference(s) => 15.11
21-03-2013 20:40Gyorgy RethySource (company - Author) => L.M.Ericsson
21-03-2013 20:41Gyorgy RethySummaryError in concatenation example => Some typos in template concatenation examples
08-07-2013 15:12Jens GrabowskiStatusnew => assigned
08-07-2013 15:12Jens GrabowskiAssigned To => Ina Schieferdecker
08-07-2013 18:04Gyorgy RethyTarget Version => v4.6.1 (published 2014-06)
09-07-2013 14:20Ina SchieferdeckerNote Added: 0011475
09-07-2013 14:35Jacob Wieland - SpirentNote Added: 0011478
11-07-2013 10:47Ina SchieferdeckerNote Added: 0011533
11-07-2013 10:49Ina SchieferdeckerStatusassigned => confirmed
11-07-2013 10:49Ina SchieferdeckerStatusconfirmed => assigned
11-07-2013 10:49Ina SchieferdeckerAssigned ToIna Schieferdecker => Jacob Wieland - Spirent
11-07-2013 12:10Jacob Wieland - SpirentNote Added: 0011542
11-07-2013 12:10Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Ina Schieferdecker
11-07-2013 12:10Jacob Wieland - SpirentStatusassigned => confirmed
11-07-2013 15:42Ina SchieferdeckerNote Added: 0011552
11-07-2013 15:42Ina SchieferdeckerStatusconfirmed => resolved
11-07-2013 15:42Ina SchieferdeckerFixed in Version => v4.6.1 (published 2014-06)
11-07-2013 15:42Ina SchieferdeckerResolutionopen => fixed
11-07-2013 15:42Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011475) +
+ Ina Schieferdecker    +
+ 09-07-2013 14:20    +
+ 		+ + + + +
+ As proposed.
+
+
+
+ + + + + + + + + + +
+ (0011478) +
+ Jacob Wieland - Spirent    +
+ 09-07-2013 14:35    +
+ 		+ + + + +
+ actually, it should be:
+
+template RecofChar t_MyRecofCharPar (integer N):= { "ABC" }& ? & * length(N) & { "EF" };
+
+
+
+ + + + + + + + + + +
+ (0011533) +
+ Ina Schieferdecker    +
+ 11-07-2013 10:47    +
+ 		+ + + + +
+ Indeed, could also be
+
+template RecofChar t_MyRecofCharPar (integer N):= { "ABC" } & * length(N) & { "EF" };
+
+Which one is more elaborated for the purpose?
+
+
+
+ + + + + + + + + + +
+ (0011542) +
+ Jacob Wieland - Spirent    +
+ 11-07-2013 12:10    +
+ 		+ + + + +
+ I think the version whith more features (so with ? & * length) is more elaborate.
+
+
+
+ + + + + + + + + + +
+ (0011552) +
+ Ina Schieferdecker    +
+ 11-07-2013 15:42    +
+ 		+ + + + +
+ Ok for the more elaborated one, which then results in
+
+P.receive ( t_MyRecofCharPar(3) );
+//actual content of t_MyRecofCharPar is { "ABC", ?, ?, ?, ?, "EF" }
+
+ + diff --git a/docs/mantis/CR6451.md b/docs/mantis/CR6451.md new file mode 100644 index 0000000000000000000000000000000000000000..29d2355fd6eda641752ceba7755770b6064aca98 --- /dev/null +++ b/docs/mantis/CR6451.md @@ -0,0 +1,290 @@ + + + + + + + + + + + + + 0006451: Invalid notes in static create, map and connect - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Config & Deployment Support (ES 202 781)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006451Ext Pack: Config & Deployment Support (ES 202 781)Clarificationpublic22-03-2013 12:2307-01-2015 09:37
ReporterTomas Urban 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv1.2.1 (published 2013-06) 
Target Versionv1.4.1 (published 2015-06)Fixed in Versionv1.4.1 (published 2015-06) 
Clause Reference(s)5.5, 5.6
Source (company - Author)Elvior
TS version 
Summary0006451: Invalid notes in static create, map and connect
DescriptionThe static create, map and connect operations contain notes saying that a static component, mapping or connection can be created or established even in cases when the static keyword is missing according to the context from which they are executed (note 2 in 5.5, note in 5.6).
+
+However, there's no rule describing this behaviour in the specification (the note itself doesn't constitute a rule.) On contrary, the specification clearly stipulates that the static keyword is mandatory for creating stating components, mappings and connections:
+"The creation of static test components shall be indicated by the additional keyword static in the create operation." (5.5)
+"The establishment of static connections and static mappings shall be indicated by the additional keyword static in connect and the map operations." (5.6)
+
+Yet another indication is hidden in 5.2: there's a rule saying that non-static create, map or connect is not allowed in configuration functions. This rule would make no sense if it was possible to interpret create, map or connect operations without the static keyword as static according to the execution context.
+
+Proposal:
+The notes shall be removed. Static create, map and connect operation shall always contain the keyword static. If the keyword is not present, the operations use the rules from the core language specification (i.e. creating non-static components, mappings and connections).
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR6451_v1.docx (50,068) 08-10-2014 16:28
http://oldforge.etsi.org/mantis/file_download.php?file_id=3121&type=bug
Issue History
Date ModifiedUsernameFieldChange
22-03-2013 12:23Tomas UrbanNew Issue
22-03-2013 12:23Tomas UrbanClause Reference(s) => 5.5, 5.6
22-03-2013 12:23Tomas UrbanSource (company - Author) => Elvior
22-03-2013 12:23Tomas UrbanTS version =>
08-07-2013 15:11Jens GrabowskiStatusnew => assigned
08-07-2013 15:11Jens GrabowskiAssigned To => Jens Grabowski
08-07-2013 18:04Gyorgy RethyTarget Version => v1.3.1 (published 2014-06)
29-11-2013 13:21Jacob Wieland - SpirentNote Added: 0011872
29-11-2013 13:21Jacob Wieland - SpirentStatusassigned => confirmed
29-11-2013 15:04Tomas UrbanNote Added: 0011881
02-12-2013 12:52Jacob Wieland - SpirentNote Added: 0011882
02-12-2013 13:58Tomas UrbanNote Added: 0011883
26-12-2013 13:24Jens GrabowskiNote Added: 0011896
26-12-2013 13:25Jens GrabowskiStatusconfirmed => assigned
08-04-2014 12:07Jens GrabowskiAssigned ToJens Grabowski => Tomas Urban
08-04-2014 17:34Gyorgy RethyProduct Version => v1.2.1 (published 2013-06)
08-04-2014 17:34Gyorgy RethyTarget Versionv1.3.1 (published 2014-06) => v1.4.1 (published 2015-06)
08-10-2014 16:28Tomas UrbanFile Added: CR6451_v1.docx
08-10-2014 16:29Tomas UrbanNote Added: 0012300
08-10-2014 16:29Tomas UrbanStatusassigned => resolved
08-10-2014 16:29Tomas UrbanResolutionopen => fixed
08-10-2014 16:29Tomas UrbanAssigned ToTomas Urban => Jens Grabowski
07-01-2015 09:37Jens GrabowskiNote Added: 0012665
07-01-2015 09:37Jens GrabowskiStatusresolved => closed
07-01-2015 09:37Jens GrabowskiFixed in Version => v1.4.1 (published 2015-06)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011872) +
+ Jacob Wieland - Spirent    +
+ 29-11-2013 13:21    +
+ 		+ + + + +
+ I think this CR is invalid. The intention of the standard is clear that all components, connections and mappings done by a configuration or functions called from a configuration are static. The static keyword is optional to make this explicit.
+
+That way, a function can be written that establishes a (part of a) configuration which can be used either from a static configuration or from a testcase. Using the static keyword restricts this to be usable only from a configuration.
+
+Basically, this is what NOTE 2 in 5.5 and the NOTE in 5.6. try to clarify.
+
+
+
+ + + + + + + + + + +
+ (0011881) +
+ Tomas Urban    +
+ 29-11-2013 15:04    +
+ 		+ + + + +
+ I am afraid that you missed my point. I actually have nothing against context-specific meaning of the map/connect statement. The problem is that the current specification technically doesn't allow that. The first rule of 5.6 makes the use of the "static" keyword mandatory, because there's no other rule allowing creation of static mapping/connection without this keyword. Note as such doesn't constitute a rule.
+
+Since I generally support explicit syntax, because it makes easier to discover errors in compilation time, my original proposal went in that direction. However, I think the scenario you described is completely justified, so if the STF decides in favour of optional use of the static keyword, I won't have any major objections (the only one I can think of is that one cannot explicitly mark a mapping/connection statement as non-static). Nevertheless, even in this case, it is required to change the specification so that:
+1. The first sententence of 5.6 mentions that the static keyword is optional
+2. There's a binding rule (not a note) saying that the map/connect operation without the "static" keyword is context-dependent
+3. The same changes should be applied to 5.5
+(4. As an option for explicit marking of non-static map/connect/create, it would be possible to use two keywords: "not static")
+
+
+
+ + + + + + + + + + +
+ (0011882) +
+ Jacob Wieland - Spirent    +
+ 02-12-2013 12:52    +
+ 		+ + + + +
+ Actually, I think marking a thing as non-static does not make sense as it is forbidden to do so semantically in the configurations and automatically true in all other places (where static is forbidden). So, in my opinion, the static keyword is pretty much superfluous anyway. If there is a rule demanding it (which I have not seen, yet), then the example which uses both statements with and without static keyword needs to be amended as well, if it shall remain mandatory.
+
+
+
+ + + + + + + + + + +
+ (0011883) +
+ Tomas Urban    +
+ 02-12-2013 13:58    +
+ 		+ + + + +
+ The following rules make the use of the static keyword mandatory:
+5.5: The creation of static test components shall be indicated by the additional keyword static in the create operation.
+5.6: The establishment of static connections and static mappings shall be indicated by the additional keyword static in connect and the map operations.
+
+The standard doesn't contain any explicit exceptions (if notes are ignored), so my in opinion, these rules clearly say that the keyword must be present to create a static component/mapping/connection.
+
+
+
+ + + + + + + + + + +
+ (0011896) +
+ Jens Grabowski    +
+ 26-12-2013 13:24    +
+ 		+ + + + +
+ Discussion needs to be continued in 2014
+
+
+
+ + + + + + + + + + +
+ (0012300) +
+ Tomas Urban    +
+ 08-10-2014 16:29    +
+ 		+ + + + +
+ Static keyword changed to optional according to Jacob's proposal. Please check.
+
+
+
+ + + + + + + + + + +
+ (0012665) +
+ Jens Grabowski    +
+ 07-01-2015 09:37    +
+ 		+ + + + +
+ Implemented as proposed by Tomas.
+
+ + diff --git a/docs/mantis/CR6452.md b/docs/mantis/CR6452.md new file mode 100644 index 0000000000000000000000000000000000000000..131fad9a27688c38694aff98d28cbba8e7f0afe4 --- /dev/null +++ b/docs/mantis/CR6452.md @@ -0,0 +1,138 @@ + + + + + + + + + + + + + 0006452: Missing rules for mapping parameters - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Config & Deployment Support (ES 202 781)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006452Ext Pack: Config & Deployment Support (ES 202 781)Technicalpublic22-03-2013 12:3526-12-2013 14:33
ReporterTomas Urban 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv1.3.1 (published 2014-06)Fixed in Version 
Clause Reference(s)5.6, 7
Source (company - Author)Elvior
TS version 
Summary0006452: Missing rules for mapping parameters
DescriptionThe rules for a static map operation don't contain a possibility to use mapping parameters in static mapping calls.
+
+Proposal:
+Change the syntax of the static mapping operation to:
+map "(" ComponentRef ":" Port "," ComponentRef ":" Port ")"
+[ param "(" [ { ActualPar [","] }+ ] ")" ] [static]
+
+Add triStaticMapParam to the chapter 7
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR6452.docx (20,196) 08-10-2013 17:58
http://oldforge.etsi.org/mantis/file_download.php?file_id=2899&type=bug
Issue History
Date ModifiedUsernameFieldChange
22-03-2013 12:35Tomas UrbanNew Issue
22-03-2013 12:35Tomas UrbanClause Reference(s) => 5.6, 7
22-03-2013 12:35Tomas UrbanSource (company - Author) => Elvior
22-03-2013 12:35Tomas UrbanTS version =>
08-07-2013 15:10Jens GrabowskiStatusnew => assigned
08-07-2013 15:10Jens GrabowskiAssigned To => Ina Schieferdecker
08-07-2013 18:03Gyorgy RethyTarget Version => v1.3.1 (published 2014-06)
09-07-2013 13:49Ina SchieferdeckerNote Added: 0011469
08-10-2013 17:58Ina SchieferdeckerFile Added: CR6452.docx
08-10-2013 17:58Ina SchieferdeckerNote Added: 0011711
08-10-2013 17:58Ina SchieferdeckerAssigned ToIna Schieferdecker => Jens Grabowski
08-10-2013 17:58Ina SchieferdeckerStatusassigned => confirmed
26-12-2013 14:33Jens GrabowskiNote Added: 0011909
26-12-2013 14:33Jens GrabowskiStatusconfirmed => closed
26-12-2013 14:33Jens GrabowskiResolutionopen => fixed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011469) +
+ Ina Schieferdecker    +
+ 09-07-2013 13:49    +
+ 		+ + + + +
+ In principle ok
+
+
+
+ + + + + + + + + + +
+ (0011711) +
+ Ina Schieferdecker    +
+ 08-10-2013 17:58    +
+ 		+ + + + +
+ Please check
+
+
+
+ + + + + + + + + + +
+ (0011909) +
+ Jens Grabowski    +
+ 26-12-2013 14:33    +
+ 		+ + + + +
+ Implemented as suggested
+
+ + diff --git a/docs/mantis/CR6453.md b/docs/mantis/CR6453.md new file mode 100644 index 0000000000000000000000000000000000000000..7a30f011928c64bd3fd0ce66870244ca2ef3f565 --- /dev/null +++ b/docs/mantis/CR6453.md @@ -0,0 +1,101 @@ + + + + + + + + + + + + + 0006453: Functions called from configuration function - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Config & Deployment Support (ES 202 781)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006453Ext Pack: Config & Deployment Support (ES 202 781)Clarificationpublic22-03-2013 12:5926-12-2013 13:49
ReporterTomas Urban 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv1.3.1 (published 2014-06)Fixed in Version 
Clause Reference(s)5.2
Source (company - Author)Elvior
TS version 
Summary0006453: Functions called from configuration function
DescriptionThe restriction c) shall be valid for functions invoked from configuration functions too.
+
+Proposal:
+The first sentence of the restriction shall be extended to:
+For the behaviour definition in the body of the configuration function and functions called directly or indirectly from the configuration function the following restrictions shall hold: ...
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0006454closed Jens Grabowski Superfluous restriction for the configuration function 
Attached Filesdoc CR6453.doc (173,056) 29-11-2013 13:28
http://oldforge.etsi.org/mantis/file_download.php?file_id=2965&type=bug
Issue History
Date ModifiedUsernameFieldChange
22-03-2013 12:59Tomas UrbanNew Issue
22-03-2013 12:59Tomas UrbanClause Reference(s) => 5.2
22-03-2013 12:59Tomas UrbanSource (company - Author) => Elvior
22-03-2013 12:59Tomas UrbanTS version =>
08-07-2013 15:08Jens GrabowskiStatusnew => assigned
08-07-2013 15:08Jens GrabowskiAssigned To => Jens Grabowski
08-07-2013 18:03Gyorgy RethyTarget Version => v1.3.1 (published 2014-06)
29-11-2013 13:28Jacob Wieland - SpirentFile Added: CR6453.doc
29-11-2013 13:30Jacob Wieland - SpirentNote Added: 0011873
29-11-2013 13:30Jacob Wieland - SpirentStatusassigned => confirmed
29-11-2013 13:31Jacob Wieland - SpirentRelationship addedrelated to 0006454
26-12-2013 13:48Jens GrabowskiNote Added: 0011903
26-12-2013 13:49Jens GrabowskiStatusconfirmed => closed
26-12-2013 13:49Jens GrabowskiResolutionopen => fixed
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011873) +
+ Jacob Wieland - Spirent    +
+ 29-11-2013 13:30    +
+ 		+ + + + +
+ also let the restriction c) apply to functions called directly or indirectly from configuration functions. Clarified that all components, connections and mappings are static, deleted superfluous sentence that non-static components, connections and mappings shall not be created (as that is impossible).
+
+
+
+ + + + + + + + + + +
+ (0011903) +
+ Jens Grabowski    +
+ 26-12-2013 13:48    +
+ 		+ + + + +
+ Implemented as proposed
+
+ + diff --git a/docs/mantis/CR6454.md b/docs/mantis/CR6454.md new file mode 100644 index 0000000000000000000000000000000000000000..7c5b6802a95f9794e0c4af3d599e59e9fa593e61 --- /dev/null +++ b/docs/mantis/CR6454.md @@ -0,0 +1,99 @@ + + + + + + + + + + + + + 0006454: Superfluous restriction for the configuration function - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Config & Deployment Support (ES 202 781)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006454Ext Pack: Config & Deployment Support (ES 202 781)Editorialpublic22-03-2013 13:1326-12-2013 13:46
ReporterTomas Urban 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv1.3.1 (published 2014-06)Fixed in Version 
Clause Reference(s)5.2
Source (company - Author)Elvior
TS version 
Summary0006454: Superfluous restriction for the configuration function
DescriptionThe restriction c) on the configuration function behaviour states that: "Once created or established, static test components, static connections and static mappings shall not be destroyed."
+
+However, general rules for static component specified in the chapter 5.9 don't allow destroying static components, connections or mappings in any place. Thus, the above mentioned restriction is completely redundant and shall be removed from the specification.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0006453closed Jens Grabowski Functions called from configuration function 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
22-03-2013 13:13Tomas UrbanNew Issue
22-03-2013 13:13Tomas UrbanClause Reference(s) => 5.2
22-03-2013 13:13Tomas UrbanSource (company - Author) => Elvior
22-03-2013 13:13Tomas UrbanTS version =>
08-07-2013 15:07Jens GrabowskiStatusnew => assigned
08-07-2013 15:07Jens GrabowskiAssigned To => Jens Grabowski
08-07-2013 18:02Gyorgy RethyTarget Version => v1.3.1 (published 2014-06)
29-11-2013 13:31Jacob Wieland - SpirentRelationship addedrelated to 0006453
29-11-2013 13:31Jacob Wieland - SpirentNote Added: 0011874
29-11-2013 13:31Jacob Wieland - SpirentStatusassigned => confirmed
26-12-2013 13:45Jens GrabowskiNote Added: 0011902
26-12-2013 13:46Jens GrabowskiStatusconfirmed => closed
26-12-2013 13:46Jens GrabowskiResolutionopen => fixed
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011874) +
+ Jacob Wieland - Spirent    +
+ 29-11-2013 13:31    +
+ 		+ + + + +
+ solution added in CR6453
+
+
+
+ + + + + + + + + + +
+ (0011902) +
+ Jens Grabowski    +
+ 26-12-2013 13:45    +
+ 		+ + + + +
+ implemented as proposed.
+
+ + diff --git a/docs/mantis/CR6455.md b/docs/mantis/CR6455.md new file mode 100644 index 0000000000000000000000000000000000000000..337b022ff38b12396f22eb00c194fe7b34c90a9a --- /dev/null +++ b/docs/mantis/CR6455.md @@ -0,0 +1,135 @@ + + + + + + + + + + + + + 0006455: Logging of configurations - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Config & Deployment Support (ES 202 781)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006455Ext Pack: Config & Deployment Support (ES 202 781)Clarificationpublic22-03-2013 14:0026-12-2013 14:18
ReporterTomas Urban 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv1.3.1 (published 2014-06)Fixed in Version 
Clause Reference(s)5
Source (company - Author)Elvior
TS version 
Summary0006455: Logging of configurations
DescriptionThe current specification doesn't contain any rule on how values of the configuration type shall be logged.
+
+Proposal:
+The log operation shall log the configuration state, which can be one of the following: Configured, Error, Killed
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0006523closed Jens Grabowski Static configuration TciValue reference representation is not specified 
Attached Filesdocx CR6455.docx (15,700) 09-10-2013 11:10
http://oldforge.etsi.org/mantis/file_download.php?file_id=2909&type=bug
Issue History
Date ModifiedUsernameFieldChange
22-03-2013 14:00Tomas UrbanNew Issue
22-03-2013 14:00Tomas UrbanClause Reference(s) => 5
22-03-2013 14:00Tomas UrbanSource (company - Author) => Elvior
22-03-2013 14:00Tomas UrbanTS version =>
08-07-2013 15:07Jens GrabowskiStatusnew => assigned
08-07-2013 15:07Jens GrabowskiAssigned To => Ina Schieferdecker
08-07-2013 18:02Gyorgy RethyTarget Version => v1.3.1 (published 2014-06)
09-07-2013 10:49Ina SchieferdeckerRelationship addedrelated to 0006523
08-10-2013 18:31Ina SchieferdeckerNote Added: 0011714
08-10-2013 18:32Ina SchieferdeckerNote Edited: 0011714
08-10-2013 18:34Ina SchieferdeckerNote Added: 0011715
09-10-2013 11:10Ina SchieferdeckerNote Deleted: 0011714
09-10-2013 11:10Ina SchieferdeckerFile Added: CR6455.docx
09-10-2013 11:11Ina SchieferdeckerNote Added: 0011725
09-10-2013 11:11Ina SchieferdeckerAssigned ToIna Schieferdecker => Jens Grabowski
09-10-2013 11:11Ina SchieferdeckerStatusassigned => confirmed
26-12-2013 14:17Jens GrabowskiNote Added: 0011908
26-12-2013 14:18Jens GrabowskiStatusconfirmed => closed
26-12-2013 14:18Jens GrabowskiResolutionopen => fixed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011715) +
+ Ina Schieferdecker    +
+ 08-10-2013 18:34    +
+ 		+ + + + +
+ For the log statement, it is proposed to have Started and Killed
+
+
+
+ + + + + + + + + + +
+ (0011725) +
+ Ina Schieferdecker    +
+ 09-10-2013 11:11    +
+ 		+ + + + +
+ Please check
+
+
+
+ + + + + + + + + + +
+ (0011908) +
+ Jens Grabowski    +
+ 26-12-2013 14:17    +
+ 		+ + + + +
+ Implemented as suggested
+
+ + diff --git a/docs/mantis/CR6456.md b/docs/mantis/CR6456.md new file mode 100644 index 0000000000000000000000000000000000000000..e04a57de0f944f43270534dbefb7612fde0a8342 --- /dev/null +++ b/docs/mantis/CR6456.md @@ -0,0 +1,101 @@ + + + + + + + + + + + + + 0006456: Comparison of configurations - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Config & Deployment Support (ES 202 781)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006456Ext Pack: Config & Deployment Support (ES 202 781)Technicalpublic22-03-2013 14:0526-12-2013 13:44
ReporterTomas Urban 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv1.3.1 (published 2014-06)Fixed in Version 
Clause Reference(s)5.1
Source (company - Author)Elvior
TS version 
Summary0006456: Comparison of configurations
DescriptionThe current specification allows comparison of two configurations, but it doesn't formalize the rules for such comparison.
+
+Proposal:
+The following rule shall be added to the specification:
+Two static test configuration values are equal if and only if they contain the same value (i.e. they designate the same static test configuration, independent of the actual state of the denoted object).
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR6456.doc (166,912) 29-11-2013 13:54
http://oldforge.etsi.org/mantis/file_download.php?file_id=2967&type=bug
Issue History
Date ModifiedUsernameFieldChange
22-03-2013 14:05Tomas UrbanNew Issue
22-03-2013 14:05Tomas UrbanClause Reference(s) => 5.1
22-03-2013 14:05Tomas UrbanSource (company - Author) => Elvior
22-03-2013 14:05Tomas UrbanTS version =>
08-07-2013 15:06Jens GrabowskiStatusnew => assigned
08-07-2013 15:06Jens GrabowskiAssigned To => Jens Grabowski
08-07-2013 18:02Gyorgy RethyTarget Version => v1.3.1 (published 2014-06)
29-11-2013 13:54Jacob Wieland - SpirentFile Added: CR6456.doc
29-11-2013 13:56Jacob Wieland - SpirentNote Added: 0011877
29-11-2013 13:56Jacob Wieland - SpirentStatusassigned => confirmed
26-12-2013 13:44Jens GrabowskiNote Added: 0011901
26-12-2013 13:44Jens GrabowskiStatusconfirmed => closed
26-12-2013 13:44Jens GrabowskiResolutionopen => fixed
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011877) +
+ Jacob Wieland - Spirent    +
+ 29-11-2013 13:56    +
+ 		+ + + + +
+ Added a sentence that each successful execution of a configuration function results in a configuration value which is only equal to itself.
+
+
+
+ + + + + + + + + + +
+ (0011901) +
+ Jens Grabowski    +
+ 26-12-2013 13:44    +
+ 		+ + + + +
+ Implemented as proposed
+
+ + diff --git a/docs/mantis/CR6457.md b/docs/mantis/CR6457.md new file mode 100644 index 0000000000000000000000000000000000000000..c1d7be4825a4a784419ce8d42f85eb7725f9b158 --- /dev/null +++ b/docs/mantis/CR6457.md @@ -0,0 +1,209 @@ + + + + + + + + + + + + + 0006457: Host ID not supported - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Config & Deployment Support (ES 202 781)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006457Ext Pack: Config & Deployment Support (ES 202 781)Technicalpublic22-03-2013 15:0026-12-2013 14:04
ReporterTomas Urban 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv1.3.1 (published 2014-06)Fixed in Version 
Clause Reference(s)5.5, 5.8
Source (company - Author)Elvior
TS version 
Summary0006457: Host ID not supported
DescriptionHost ID is not present in the syntactical structure of the static create operation and the execute statement. This is especially important in case of the execute statement, becuase currently it is not obvious whether the host ID parameter shall precede or follow the configuration reference.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0006468closed Jens Grabowski Import of configuration functions 
Attached Filesdoc CR6457.doc (169,472) 28-11-2013 11:43
http://oldforge.etsi.org/mantis/file_download.php?file_id=2957&type=bug
Issue History
Date ModifiedUsernameFieldChange
22-03-2013 15:00Tomas UrbanNew Issue
22-03-2013 15:00Tomas UrbanClause Reference(s) => 5.5, 5.8
22-03-2013 15:00Tomas UrbanSource (company - Author) => Elvior
22-03-2013 15:00Tomas UrbanTS version =>
08-07-2013 15:03Jens GrabowskiStatusnew => assigned
08-07-2013 15:03Jens GrabowskiAssigned To => Jens Grabowski
08-07-2013 15:05Jens GrabowskiNote Added: 0011450
08-07-2013 18:01Gyorgy RethyTarget Version => v1.3.1 (published 2014-06)
30-08-2013 11:56Ina SchieferdeckerNote Added: 0011655
28-11-2013 11:33Jacob Wieland - SpirentNote Added: 0011856
28-11-2013 11:43Jacob Wieland - SpirentFile Added: CR6457.doc
28-11-2013 11:44Jacob Wieland - SpirentNote Edited: 0011856
28-11-2013 11:44Jacob Wieland - SpirentRelationship addedrelated to 0006468
28-11-2013 11:48Jacob Wieland - SpirentNote Added: 0011857
28-11-2013 11:48Jacob Wieland - SpirentStatusassigned => confirmed
26-12-2013 14:03Jens GrabowskiNote Added: 0011906
26-12-2013 14:04Jens GrabowskiStatusconfirmed => closed
26-12-2013 14:04Jens GrabowskiResolutionopen => fixed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011450) +
+ Jens Grabowski    +
+ 08-07-2013 15:05    +
+ 		+ + + + +
+ Check handling of Host ID in static configuration package. Check Host ID is possible to define for execute in the Core Part.
+
+
+
+ + + + + + + + + + +
+ (0011655) +
+ Ina Schieferdecker    +
+ 30-08-2013 11:56    +
+ 		+ + + + +
+ static create simply missed the second optional parameter in create as defined in part 1, clause 21.3.1.
+
+It should be
+
+ComponentType "." create [ "(" Expression ["," Expression] ")" ] [ alive | static ]
+
+I suggest to correct the syntactic structure and BNF rule for static create.
+
+Please check.
+
+
+
+ + + + + + + + + + +
+ (0011856) +
+ Jacob Wieland - Spirent    +
+ 28-11-2013 11:33    +
(edited on: 28-11-2013 11:44)
+ 		+ + + + +
+ syntactical part amended in attached document, BNF amendments in CR6468
+
+
+
+
+
+ + + + + + + + + + +
+ (0011857) +
+ Jacob Wieland - Spirent    +
+ 28-11-2013 11:48    +
+ 		+ + + + +
+ please review
+
+
+
+ + + + + + + + + + +
+ (0011906) +
+ Jens Grabowski    +
+ 26-12-2013 14:03    +
+ 		+ + + + +
+ Implemented as suggested
+
+ + diff --git a/docs/mantis/CR6468.md b/docs/mantis/CR6468.md new file mode 100644 index 0000000000000000000000000000000000000000..c1fb20b8f269ece7b19e91b594a78adddd5bdb3f --- /dev/null +++ b/docs/mantis/CR6468.md @@ -0,0 +1,107 @@ + + + + + + + + + + + + + 0006468: Import of configuration functions - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Config & Deployment Support (ES 202 781)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006468Ext Pack: Config & Deployment Support (ES 202 781)New Featurepublic25-03-2013 07:2226-12-2013 14:15
ReporterTomas Urban 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv1.3.1 (published 2014-06)Fixed in Version 
Clause Reference(s)5
Source (company - Author)Elvior
TS version 
Summary0006468: Import of configuration functions
DescriptionThe current specification doesn't define any dedicated rules for importing configuration functions. It means the only way of importing them is importing all definititions from the module or group-based import. However, such an approach is not feasible in some cases and it is not consistent with the principles introduced in the core language specification where each element that could appear in the module declaration part has a dedicated import clause.
+
+Proposal:
+The configuration and deployment package shall define rules allowing the following statements:
+import from MyModule { configuration a, b, c; }
+import from MyModule { configuration all; }
+import from MyModule { configuration all except a, b, c; }
+import from MyModule all except { configuration a, b, c; }
+import from MyModule all except { configuration all; }
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0006457closed Jens Grabowski Host ID not supported 
Attached Filesdoc CR6468.doc (191,488) 28-11-2013 11:47
http://oldforge.etsi.org/mantis/file_download.php?file_id=2958&type=bug
Issue History
Date ModifiedUsernameFieldChange
25-03-2013 07:22Tomas UrbanNew Issue
25-03-2013 07:22Tomas UrbanClause Reference(s) => 5
25-03-2013 07:22Tomas UrbanSource (company - Author) => Elvior
25-03-2013 07:22Tomas UrbanTS version =>
25-03-2013 08:31Tomas UrbanDescription Updated
08-07-2013 15:00Jens GrabowskiStatusnew => assigned
08-07-2013 15:00Jens GrabowskiAssigned To => Jens Grabowski
08-07-2013 18:01Gyorgy RethyTarget Version => v1.3.1 (published 2014-06)
28-11-2013 11:30Jacob Wieland - SpirentAssigned ToJens Grabowski => Jacob Wieland - Spirent
28-11-2013 11:30Jacob Wieland - SpirentFile Added: CR6468.doc
28-11-2013 11:32Jacob Wieland - SpirentNote Added: 0011855
28-11-2013 11:32Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Jens Grabowski
28-11-2013 11:32Jacob Wieland - SpirentStatusassigned => confirmed
28-11-2013 11:44Jacob Wieland - SpirentRelationship addedrelated to 0006457
28-11-2013 11:45Jacob Wieland - SpirentStatusconfirmed => assigned
28-11-2013 11:45Jacob Wieland - SpirentAssigned ToJens Grabowski => Jacob Wieland - Spirent
28-11-2013 11:45Jacob Wieland - SpirentFile Deleted: CR6468.doc
28-11-2013 11:47Jacob Wieland - SpirentFile Added: CR6468.doc
28-11-2013 11:47Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Jens Grabowski
28-11-2013 11:47Jacob Wieland - SpirentStatusassigned => confirmed
26-12-2013 14:15Jens GrabowskiNote Added: 0011907
26-12-2013 14:15Jens GrabowskiStatusconfirmed => closed
26-12-2013 14:15Jens GrabowskiResolutionopen => fixed
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011855) +
+ Jacob Wieland - Spirent    +
+ 28-11-2013 11:32    +
+ 		+ + + + +
+ added appropriate rules and clauses to BNF
+
+also updated the changed BNF rules to be in sync with current standard
+
+
+
+ + + + + + + + + + +
+ (0011907) +
+ Jens Grabowski    +
+ 26-12-2013 14:15    +
+ 		+ + + + +
+ Implemented as proposed.
+
+ + diff --git a/docs/mantis/CR6469.md b/docs/mantis/CR6469.md new file mode 100644 index 0000000000000000000000000000000000000000..d2371191317ee17661cc14f9eb5cf82963b8b5ab --- /dev/null +++ b/docs/mantis/CR6469.md @@ -0,0 +1,165 @@ + + + + + + + + + + + + + 0006469: TRI and TCI C# mapping is missing - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Config & Deployment Support (ES 202 781)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006469Ext Pack: Config & Deployment Support (ES 202 781)Technicalpublic25-03-2013 13:2726-12-2013 13:38
ReporterTomas Urban 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv1.3.1 (published 2014-06)Fixed in Version 
Clause Reference(s)7, 8
Source (company - Author)Elvior
TS version 
Summary0006469: TRI and TCI C# mapping is missing
DescriptionThe current version of the document doesn't specify C# mapping for the TRI and TCI extensions
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0006522closed Jens Grabowski No way to specify configuration reference for "tciStartTestCase" in TCI-TM 
related to 0006523closed Jens Grabowski Static configuration TciValue reference representation is not specified 
Attached Filesdocx CR6469.docx (19,198) 07-10-2013 15:26
http://oldforge.etsi.org/mantis/file_download.php?file_id=2891&type=bug
zip es_202781v010203_October2013.zip (742,986) 10-10-2013 19:18
http://oldforge.etsi.org/mantis/file_download.php?file_id=2924&type=bug
Issue History
Date ModifiedUsernameFieldChange
25-03-2013 13:27Tomas UrbanNew Issue
25-03-2013 13:27Tomas UrbanClause Reference(s) => 7, 8
25-03-2013 13:27Tomas UrbanSource (company - Author) => Elvior
25-03-2013 13:27Tomas UrbanTS version =>
08-07-2013 14:58Jens GrabowskiStatusnew => assigned
08-07-2013 14:58Jens GrabowskiAssigned To => Ina Schieferdecker
08-07-2013 17:13Gyorgy RethyTarget Version => v1.3.1 (published 2014-06)
09-07-2013 13:50Ina SchieferdeckerNote Added: 0011470
07-10-2013 15:26Ina SchieferdeckerFile Added: CR6469.docx
07-10-2013 15:26Ina SchieferdeckerNote Added: 0011690
07-10-2013 15:26Ina SchieferdeckerAssigned ToIna Schieferdecker => Jens Grabowski
09-10-2013 15:05Ina SchieferdeckerStatusassigned => confirmed
10-10-2013 19:18Ina SchieferdeckerFile Added: es_202781v010203_October2013.zip
10-10-2013 19:18Ina SchieferdeckerRelationship addedrelated to 0006522
10-10-2013 19:19Ina SchieferdeckerRelationship addedrelated to 0006523
10-10-2013 19:19Ina SchieferdeckerNote Added: 0011762
26-12-2013 13:38Jens GrabowskiNote Added: 0011899
26-12-2013 13:38Jens GrabowskiStatusconfirmed => closed
26-12-2013 13:38Jens GrabowskiResolutionopen => fixed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011470) +
+ Ina Schieferdecker    +
+ 09-07-2013 13:50    +
+ 		+ + + + +
+ Yes indeed.
+
+
+
+ + + + + + + + + + +
+ (0011690) +
+ Ina Schieferdecker    +
+ 07-10-2013 15:26    +
+ 		+ + + + +
+ Please check.
+
+
+
+ + + + + + + + + + +
+ (0011762) +
+ Ina Schieferdecker    +
+ 10-10-2013 19:19    +
+ 		+ + + + +
+ Mappings defined for CR 6522, 6523 and 6469 in uploaded file
+
+
+
+ + + + + + + + + + +
+ (0011899) +
+ Jens Grabowski    +
+ 26-12-2013 13:38    +
+ 		+ + + + +
+ Implemented as suggested!
+
+ + diff --git a/docs/mantis/CR6477.md b/docs/mantis/CR6477.md new file mode 100644 index 0000000000000000000000000000000000000000..42b60cedfab92247968a05897b0fd100cadb8fc8 --- /dev/null +++ b/docs/mantis/CR6477.md @@ -0,0 +1,106 @@ + + + + + + + + + + + + + 0006477: clarification needed that it is no error to apply "ifpresent" on an expression which may result in "omit" - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006477Part 01: TTCN-3 Core LanguageClarificationpublic26-03-2013 10:4911-07-2013 11:36
ReporterWolfgang Seka 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.6.1 (published 2014-06)Fixed in Versionv4.6.1 (published 2014-06) 
Clause Reference(s)B.1.4.2
Source (company - Author)     MCC160 - Wolfgang
Summary0006477: clarification needed that it is no error to apply "ifpresent" on an expression which may result in "omit"
DescriptionExample
+
+    var template (omit) MyType v_MyVariable := f_MyFunction();
+
+=> depending on what f_MyFunction returns v_MyVariable may result in omit;
+
+nevertheless there shall be no error for "v_MyVariable ifpresent"
+(i.e. "omit ifpresent" shall interpreted as omit)
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR6477.doc (157,696) 10-07-2013 16:29
http://oldforge.etsi.org/mantis/file_download.php?file_id=2818&type=bug
Issue History
Date ModifiedUsernameFieldChange
26-03-2013 10:49Wolfgang SekaNew Issue
26-03-2013 10:49Wolfgang SekaClause Reference(s) => B.1.4.2
26-03-2013 10:49Wolfgang SekaSource (company - Author) => MCC160 - Wolfgang
08-07-2013 14:58Jens GrabowskiProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
08-07-2013 14:58Jens GrabowskiStatusnew => assigned
08-07-2013 14:58Jens GrabowskiAssigned To => Jacob Wieland - Spirent
08-07-2013 17:12Gyorgy RethyTarget Version => v4.6.1 (published 2014-06)
09-07-2013 17:00Jacob Wieland - SpirentNote Added: 0011487
10-07-2013 16:29Jacob Wieland - SpirentFile Added: CR6477.doc
10-07-2013 18:14Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
10-07-2013 18:14Jacob Wieland - SpirentNote Added: 0011525
11-07-2013 09:08Jacob Wieland - SpirentAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
11-07-2013 10:15Jacob Wieland - SpirentStatusassigned => confirmed
11-07-2013 10:56Jacob Wieland - SpirentStatusconfirmed => assigned
11-07-2013 10:56Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Ina Schieferdecker
11-07-2013 10:57Jacob Wieland - SpirentStatusassigned => confirmed
11-07-2013 11:33Ina SchieferdeckerStatusconfirmed => resolved
11-07-2013 11:33Ina SchieferdeckerFixed in Version => v4.6.1 (published 2014-06)
11-07-2013 11:33Ina SchieferdeckerResolutionopen => fixed
11-07-2013 11:36Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011487) +
+ Jacob Wieland - Spirent    +
+ 09-07-2013 17:00    +
+ 		+ + + + +
+ This makes sense to me. ifpresent enlarges the set of "objects" to be matched by the special value omit. If the set already contains that object, nothing happens. The same would be true if the template already is an ifpresent template or an AnyValueOrNone.
+
+Otherwise, it would be necessary to restrict ifpresent such that it only can be applied to present-templates (thereby excluding omit, ifpresent and *). Since I don't see any harm in the idempotency of ifpresent, I would opt for allowing rather than restriction.
+
+
+
+ + + + + + + + + + +
+ (0011525) +
+ Jacob Wieland - Spirent    +
+ 10-07-2013 18:14    +
+ 		+ + + + +
+ please check
+
+ + diff --git a/docs/mantis/CR6491.md b/docs/mantis/CR6491.md new file mode 100644 index 0000000000000000000000000000000000000000..e96162cf6f649e084ab8e1e25d2a43c1bc100a35 --- /dev/null +++ b/docs/mantis/CR6491.md @@ -0,0 +1,294 @@ + + + + + + + + + + + + + 0006491: At least some compiler generate a runtime error when a function returns an unititialised variable even in cases when the result - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006491Part 01: TTCN-3 Core LanguageTechnicalpublic27-03-2013 18:5529-08-2013 07:56
ReporterWolfgang Seka 
Assigned ToIna Schieferdecker 
PrioritynormalSeveritymajorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.6.1 (published 2014-06)Fixed in Versionv4.6.1 (published 2014-06) 
Clause Reference(s)e.g. 11.1
Source (company - Author)MCC160 - Wolfgang
Summary0006491: At least some compiler generate a runtime error when a function returns an unititialised variable even in cases when the result
DescriptionThere are cases where e.g. due to maintenance on existing TTCN-3 code a function is enhanced to return a value just for special cases, i.e. a function which has not had a return value before gets a return statement which is needed for some particular case.
+Now it may happen that the function is just changed for the particular case when the return value is expected but for the other cases it e.g. returns an unitialised variable.
+From a user's point of view that would not harm as in these cases the caller of the function does not evaluate the functions's result at all.
+Nevertheless acc. to the restrictions in clause 11.1 of part 1 this is not allowed.
+BUT - it seems that compilers cannot find that a compile time (or at least not for all cases).
+But since some compilers are "improved" now to check this formal correctness at runtime, errors occur at runtime even though from a user's perspective there is no error.
+As there is no way to detect that kind of problems before it comes to the runtime error and the code is even logically correct these errors are very costly.
+
+=> either the restrictions regarding the return statements shall be reduced to allow returning uninitialised variables as long as they are not used by the caller or other proposals are requested about how these kind of problems can be avoided.
Steps To Reproduce
Additional InformationMCC160 would like to participate on any discussions about this topic.
TagsNo tags attached.
Relationships
Attached Filesdoc CR6491.doc (164,352) 28-08-2013 13:51
http://oldforge.etsi.org/mantis/file_download.php?file_id=2869&type=bug
Issue History
Date ModifiedUsernameFieldChange
27-03-2013 18:55Wolfgang SekaNew Issue
27-03-2013 18:55Wolfgang SekaClause Reference(s) => e.g. 11.1
27-03-2013 18:55Wolfgang SekaSource (company - Author) => MCC160 - Wolfgang
05-04-2013 09:49Jacob Wieland - SpirentNote Added: 0011408
05-04-2013 10:57Wolfgang SekaNote Added: 0011409
08-07-2013 14:56Jens GrabowskiProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
08-07-2013 14:56Jens GrabowskiStatusnew => assigned
08-07-2013 14:56Jens GrabowskiAssigned To => Jacob Wieland - Spirent
08-07-2013 17:12Gyorgy RethyTarget Version => v4.6.1 (published 2014-06)
10-07-2013 19:33Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
11-07-2013 09:05Jacob Wieland - SpirentAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
12-07-2013 08:58Jacob Wieland - SpirentNote Added: 0011566
12-07-2013 09:01Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Ina Schieferdecker
12-07-2013 09:01Jacob Wieland - SpirentStatusassigned => confirmed
15-07-2013 10:43Wolfgang SekaNote Added: 0011580
27-08-2013 14:26Ina SchieferdeckerStatusconfirmed => assigned
27-08-2013 14:26Ina SchieferdeckerAssigned ToIna Schieferdecker => Jacob Wieland - Spirent
27-08-2013 14:33Gyorgy RethyNote Added: 0011609
27-08-2013 14:34Gyorgy RethyNote Edited: 0011609
28-08-2013 13:51Jacob Wieland - SpirentFile Added: CR6491.doc
28-08-2013 13:52Jacob Wieland - SpirentNote Added: 0011624
28-08-2013 13:52Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Ina Schieferdecker
28-08-2013 13:52Jacob Wieland - SpirentStatusassigned => confirmed
29-08-2013 07:55Ina SchieferdeckerNote Added: 0011630
29-08-2013 07:55Ina SchieferdeckerStatusconfirmed => resolved
29-08-2013 07:55Ina SchieferdeckerResolutionopen => fixed
29-08-2013 07:55Ina SchieferdeckerFixed in Version => v4.6.1 (published 2014-06)
29-08-2013 07:56Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011408) +
+ Jacob Wieland - Spirent    +
+ 05-04-2013 09:49    +
+ 		+ + + + +
+ As I said in the meeting, I would opt for lifting the restriction on return statements since the assignment of an uninitialized value to a variable will catch such a behavior as well. It should be clear, though that this can lead to the situation where the result of a function is used directly as an actual parameter (where uninitialized values are allowed) of another function which then could lead to a runtime-error very far away from the error-cause. This makes the error-cause hard to locate, which is very costly, as well. Thus, there is no ideal solution for this problem, it has to be decided which scenario is more probable and thus more costly.
+
+
+
+ + + + + + + + + + +
+ (0011409) +
+ Wolfgang Seka    +
+ 05-04-2013 10:57    +
+ 		+ + + + +
+ As already mentioned in the earlier discussions - it is up to tools whether/how to provide the user with additional information and warnings at runtime and how to configure that; it is up to users whether to make use of this information and to configure the runtime environment accordingly. But the core language as such shall be independent of this and in particular it shall not mandate generation of runtime errors where - from a user's point of view - there is no problem at all.
+Furthermore in this context the argumentation "... This makes the error-cause hard to locate ..." is not applicable as it is a tool issue how to verify and debug the code.
+
+
+
+ + + + + + + + + + +
+ (0011566) +
+ Jacob Wieland - Spirent    +
+ 12-07-2013 08:58    +
+ 		+ + + + +
+ After a lengthy discussion, the STF still thinks that the dangers of lifting this restriction outweigh the benefits the STF160 would gain.
+
+In some cases it is possible to check statically, if a return value is initialized or not (after a potentially very costly analysis), but in lots of cases it can only be determined at runtime. Other languages solve this problem by restricting the language even further, so that the data-flow analysis becomes feasible; but then they forbid scenarios statically (the maybe-cases) some of which would never be a problem at runtime. Thus, they force the user - without specific necessity - to write more complicated code. This requirement in TTCN-3 is more implicit but still there.
+
+ 
+
+Also, during the discussion, it was strongly opposed to make the semantic rules of the return statement context-dependent, i.e. depending on the place the given function is called. This would be a wrong language design.
+
+The instruments to solve similar problems when a function is extended are given by the language itself, for instance by the isbound() predefined function. It can be used to check the to-be-returned variable before returning it and then return a dummy value in the case it is not initialized. Another way of preventing such errors is to use unit-testing for functions or to impose a coding style that initializes all variables at declaration.
+
+
+
+ + + + + + + + + + +
+ (0011580) +
+ Wolfgang Seka    +
+ 15-07-2013 10:43    +
+ 		+ + + + +
+ Mail set to stf460 (12 July 2013 09:11):
+
+"I've seen the note added to 6491 in I don't think that it is the right decision and I think from a user's point of view it is not acceptable:
+
+You are shifting tool problems from the tooling side to the user's side: There is no reason why cannot raise a warning at runtime (but that is a tool issue) but by raising a runtime the problem is definitely at the user's side.
+ 
+Again please note that the issues causing problems are not visible for the user when writing the code therefore the user will not use any "instruments by the language itself" until there is a runtime error.
+
+I hope that this is NOT a final decision."
+
+
+
+ + + + + + + + + + +
+ (0011609) +
+ Gyorgy Rethy    +
+ 27-08-2013 14:33    +
(edited on: 27-08-2013 14:34)
+ 		+ + + + +
+ STF discussion 2013-08-27: we should allow returning uninitialized value by a function, but this shall not be assigned to a variable or used in expression, ( but can be passed as parameter where uninitialized actual parameter is allowed)
+
+
+
+
+
+ + + + + + + + + + +
+ (0011624) +
+ Jacob Wieland - Spirent    +
+ 28-08-2013 13:52    +
+ 		+ + + + +
+ added proposal, simply lessened the restriction for use of uninitialized variables to allow return statements.
+
+
+
+ + + + + + + + + + +
+ (0011630) +
+ Ina Schieferdecker    +
+ 29-08-2013 07:55    +
+ 		+ + + + +
+ As proposed.
+
+ + diff --git a/docs/mantis/CR6511.md b/docs/mantis/CR6511.md new file mode 100644 index 0000000000000000000000000000000000000000..f0ba464096eee7df1268139b7a6e2f2c0713fb68 --- /dev/null +++ b/docs/mantis/CR6511.md @@ -0,0 +1,356 @@ + + + + + + + + + + + + + 0006511: One more "special place" for function call - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006511Part 01: TTCN-3 Core LanguageTechnicalpublic02-04-2013 16:0728-08-2013 12:43
ReporterTomas Urban 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.6.1 (published 2014-06)Fixed in Versionv4.6.1 (published 2014-06) 
Clause Reference(s)16.1.4
Source (company - Author)Elvior
Summary0006511: One more "special place" for function call
DescriptionAlthough the chapter 16.1.4 covers most situations that can lead to a change in the snapshot state, one thing was left unnoticed. In particular, port, component and timer references used in blocking operations might contain an array index with a function call (e.g t[f()].timeout, p[f()].receive, ptc[f()].done). According to the current rules, this kind of function call is not restricted by the rules described in 16.1.4.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0006423closed Ina Schieferdecker Restriction on communication operations in functions 
related to 0006422closed Ina Schieferdecker Restrictions on operations invoked from special places 
Attached Filesdocx CR6511.docx (202,501) 10-07-2013 15:30
http://oldforge.etsi.org/mantis/file_download.php?file_id=2812&type=bug
docx CR6511-v2.docx (202,775) 28-08-2013 12:30
http://oldforge.etsi.org/mantis/file_download.php?file_id=2868&type=bug
Issue History
Date ModifiedUsernameFieldChange
02-04-2013 16:07Tomas UrbanNew Issue
02-04-2013 16:07Tomas UrbanClause Reference(s) => 16.1.4
02-04-2013 16:07Tomas UrbanSource (company - Author) => Elvior
03-04-2013 09:11Tomas UrbanNote Added: 0011377
04-04-2013 13:17Tomas UrbanNote Added: 0011406
05-04-2013 09:44Jacob Wieland - SpirentNote Added: 0011407
08-07-2013 14:54Jens GrabowskiProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
08-07-2013 14:55Jens GrabowskiStatusnew => assigned
08-07-2013 14:55Jens GrabowskiAssigned To => Jacob Wieland - Spirent
08-07-2013 15:43Jens GrabowskiRelationship addedrelated to 0006423
08-07-2013 15:45Jens GrabowskiRelationship addedrelated to 0006422
08-07-2013 17:11Gyorgy RethyTarget Version => v4.6.1 (published 2014-06)
09-07-2013 16:23Jacob Wieland - SpirentNote Edited: 0011407
10-07-2013 10:09Gyorgy RethyNote Added: 0011495
10-07-2013 15:15Jacob Wieland - SpirentNote Added: 0011505
10-07-2013 15:15Jacob Wieland - SpirentFile Added: CR6511.docx
10-07-2013 15:17Jacob Wieland - SpirentFile Deleted: CR6511.docx
10-07-2013 15:17Jacob Wieland - SpirentFile Added: CR6511.docx
10-07-2013 15:28Jacob Wieland - SpirentFile Deleted: CR6511.docx
10-07-2013 15:29Jacob Wieland - SpirentFile Added: CR6511.docx
10-07-2013 15:30Jacob Wieland - SpirentFile Deleted: CR6511.docx
10-07-2013 15:30Jacob Wieland - SpirentFile Added: CR6511.docx
10-07-2013 15:32Jacob Wieland - SpirentNote Added: 0011508
10-07-2013 18:18Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
10-07-2013 18:18Jacob Wieland - SpirentNote Added: 0011527
11-07-2013 09:06Jacob Wieland - SpirentAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
11-07-2013 10:16Jacob Wieland - SpirentStatusassigned => confirmed
11-07-2013 10:50Jacob Wieland - SpirentStatusconfirmed => assigned
11-07-2013 10:50Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Ina Schieferdecker
11-07-2013 10:53Jacob Wieland - SpirentStatusassigned => confirmed
26-08-2013 16:07Ina SchieferdeckerNote Added: 0011601
26-08-2013 16:08Ina SchieferdeckerStatusconfirmed => assigned
26-08-2013 16:08Ina SchieferdeckerAssigned ToIna Schieferdecker => Jacob Wieland - Spirent
26-08-2013 16:33Jacob Wieland - SpirentNote Added: 0011602
26-08-2013 16:36Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Ina Schieferdecker
26-08-2013 16:36Jacob Wieland - SpirentStatusassigned => confirmed
28-08-2013 12:30Ina SchieferdeckerFile Added: CR6511-v2.docx
28-08-2013 12:42Ina SchieferdeckerStatusconfirmed => resolved
28-08-2013 12:42Ina SchieferdeckerResolutionopen => fixed
28-08-2013 12:42Ina SchieferdeckerFixed in Version => v4.6.1 (published 2014-06)
28-08-2013 12:43Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011377) +
+ Tomas Urban    +
+ 03-04-2013 09:11    +
+ 		+ + + + +
+ There's one more place that is not covered by the current rules: in parameters passed to an altstep branch, e.g.:
+
+alt
+{
+   []altstep1(f());
+}
+
+If such a parameter is a result of a function call, the function will be called during snapshot evaluation and if unrestricted, it might cause the feared side effects mentioned in 16.1.4.
+
+Notice that out and inout parameters of the alstep branch cannot lead to any side effects, because their value might change only if an alternative branch is activated inside the altstep, which terminates snapshot evaluation.
+
+
+
+ + + + + + + + + + +
+ (0011406) +
+ Tomas Urban    +
+ 04-04-2013 13:17    +
+ 		+ + + + +
+ Yet another special place are functions returning an object on which a blocking operation is performed and their parameters, e.g.:
+alt
+{
+  []fCompFunc(f()).done {} // both fCompFunc and f shall fullfil condition specified in 16.1.4
+}
+
+
+
+ + + + + + + + + + +
+ (0011407) +
+ Jacob Wieland - Spirent    +
+ 05-04-2013 09:44    +
(edited on: 09-07-2013 16:23)
+ 		+ + + + +
+ To make it short, all parts (sub-expressions) of the guard and the event-part (i.e. those expressions evaluated in a snapshot) should be snapshot-safe.
+
+This should be a further restriction in section 20.2.
+
+Of course, the wording in the "invoking functions from special places" should also be changed so it only refers to the functions called during the evaluation of blocking communication operations.
+
+
+
+
+
+ + + + + + + + + + +
+ (0011495) +
+ Gyorgy Rethy    +
+ 10-07-2013 10:09    +
+ 		+ + + + +
+ STF decision 2013-07-10:
+- Side effect restrictions shall apply both to the guard and to the receiving event part of alt branches.
+- Make a generic statement in the text that side effects effecting a snapshot evaluation and objects evaluated in subsequent shapshots shall be avoided. Give also a list of identified cases and a note saying that the list may not be exhaustive.
+
+
+
+ + + + + + + + + + +
+ (0011505) +
+ Jacob Wieland - Spirent    +
+ 10-07-2013 15:15    +
+ 		+ + + + +
+ Since the term event is described in the semantic description of the alt statement, I think it is safe to add the restriction in a general manner in regard to this. I've also added examples that disallow all cases we have identified until now.
+
+
+
+ + + + + + + + + + +
+ (0011508) +
+ Jacob Wieland - Spirent    +
+ 10-07-2013 15:32    +
+ 		+ + + + +
+ added proposal
+
+
+
+ + + + + + + + + + +
+ (0011527) +
+ Jacob Wieland - Spirent    +
+ 10-07-2013 18:18    +
+ 		+ + + + +
+ please check and if okay, also set the related ones to resolved
+
+
+
+ + + + + + + + + + +
+ (0011601) +
+ Ina Schieferdecker    +
+ 26-08-2013 16:07    +
+ 		+ + + + +
+ Please reconsider the resolution: it forbids to have value returning functions in send and alike.
+
+
+
+ + + + + + + + + + +
+ (0011602) +
+ Jacob Wieland - Spirent    +
+ 26-08-2013 16:33    +
+ 		+ + + + +
+ What part does forbid this? Can you give an example of a forbidden value-returning function call?
+
+ + diff --git a/docs/mantis/CR6516.md b/docs/mantis/CR6516.md new file mode 100644 index 0000000000000000000000000000000000000000..babe397c695b8877d6344d037059baf55c697771 --- /dev/null +++ b/docs/mantis/CR6516.md @@ -0,0 +1,165 @@ + + + + + + + + + + + + + 0006516: Continuous signalling: Missing table of keywords - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Continuous signal support (ES 202 786)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006516Ext Pack: Continuous signal support (ES 202 786)Editorialpublic05-04-2013 13:4826-12-2013 13:02
ReporterTomas Urban 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv1.2.1 (published 2014-06)Fixed in Versionv1.2.1 (published 2014-06) 
Summary0006516: Continuous signalling: Missing table of keywords
DescriptionThe core language specification and other extension packages contain a table with all keywords defined in the specification in the annex describing the BNF. However, such a table is missing in the continous signalling specification.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR6516-Resolution-V1-130711.doc (131,584) 11-07-2013 10:32
http://oldforge.etsi.org/mantis/file_download.php?file_id=2825&type=bug
doc CR6520-6519-6518-6517-6516-Res-V1-130711.doc (753,664) 11-07-2013 16:07
http://oldforge.etsi.org/mantis/file_download.php?file_id=2839&type=bug
Issue History
Date ModifiedUsernameFieldChange
05-04-2013 13:48Tomas UrbanNew Issue
05-04-2013 13:48Tomas UrbanClause Reference(s) => Annex A
05-04-2013 13:48Tomas UrbanSource (company - Author) => Elvior
08-07-2013 14:52Jens GrabowskiStatusnew => assigned
08-07-2013 14:52Jens GrabowskiAssigned To => Jens Grabowski
08-07-2013 17:10Gyorgy RethyProjectTTCN-3 Change Requests => Ext Pack: Continuous signal support (ES 202 786)
08-07-2013 17:11Gyorgy RethyTarget Version => v1.2.1 (published 2014-06)
11-07-2013 10:00Jens GrabowskiNote Added: 0011531
11-07-2013 10:32Jens GrabowskiFile Added: CR6516-Resolution-V1-130711.doc
11-07-2013 10:33Jens GrabowskiNote Added: 0011532
11-07-2013 16:07Jens GrabowskiFile Added: CR6520-6519-6518-6517-6516-Res-V1-130711.doc
11-07-2013 16:08Jens GrabowskiNote Added: 0011559
11-07-2013 16:14Jens GrabowskiProjectExt Pack: Continuous signal support (ES 202 786) => TTCN-3 Change Requests
11-07-2013 16:16Jens GrabowskiProjectTTCN-3 Change Requests => Ext Pack: Continuous signal support (ES 202 786)
11-07-2013 16:20Jens GrabowskiAssigned ToJens Grabowski => Jacob Wieland - Spirent
11-07-2013 16:32Jacob Wieland - SpirentStatusassigned => resolved
11-07-2013 16:32Jacob Wieland - SpirentFixed in Version => v1.2.1 (published 2014-06)
11-07-2013 16:32Jacob Wieland - SpirentResolutionopen => fixed
12-07-2013 08:53Jens GrabowskiAssigned ToJacob Wieland - Spirent => Jens Grabowski
12-07-2013 08:53Jens GrabowskiStatusresolved => feedback
12-07-2013 08:53Jens GrabowskiResolutionfixed => reopened
12-07-2013 08:53Jens GrabowskiNote Added: 0011563
12-07-2013 08:53Jens GrabowskiStatusfeedback => resolved
12-07-2013 08:53Jens GrabowskiResolutionreopened => fixed
26-12-2013 13:02Jens GrabowskiStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011531) +
+ Jens Grabowski    +
+ 11-07-2013 10:00    +
+ 		+ + + + +
+ Resolution extends resolution for BNF related CRs 6517 and 6518.
+
+
+
+ + + + + + + + + + +
+ (0011532) +
+ Jens Grabowski    +
+ 11-07-2013 10:33    +
+ 		+ + + + +
+ Resolution uploaded. To be checked.
+
+
+
+ + + + + + + + + + +
+ (0011559) +
+ Jens Grabowski    +
+ 11-07-2013 16:08    +
+ 		+ + + + +
+ Resolution of CR 6520, 6519, 6518, 6517, 6516 in one file.
+
+
+
+ + + + + + + + + + +
+ (0011563) +
+ Jens Grabowski    +
+ 12-07-2013 08:53    +
+ 		+ + + + +
+ To be assigned to Editor of Package
+
+ + diff --git a/docs/mantis/CR6517.md b/docs/mantis/CR6517.md new file mode 100644 index 0000000000000000000000000000000000000000..f23a6251012d39f774fe90ee9bbb7f720b813e0c --- /dev/null +++ b/docs/mantis/CR6517.md @@ -0,0 +1,169 @@ + + + + + + + + + + + + + 0006517: Continuous signalling: keyword format in the BNF - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Continuous signal support (ES 202 786)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006517Ext Pack: Continuous signal support (ES 202 786)Editorialpublic05-04-2013 14:1926-12-2013 13:02
ReporterTomas Urban 
Assigned ToJens Grabowski 
PrioritynormalSeveritytrivialReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv1.2.1 (published 2014-06)Fixed in Versionv1.2.1 (published 2014-06) 
Summary0006517: Continuous signalling: keyword format in the BNF
DescriptionFor some strange reason, all keywords defined in the BNF of the continuous signalling extension package, contain a superfluous space character in the beginning. There are two typos in the keyword rules as well:
+40.FindeKeyword -> FindKeyword
+46.AssertKeyword ::= " Assert" -> 46.AssertKeyword ::= "assert"
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR6517-Resolution-V1-130710.doc (127,488) 10-07-2013 16:23
http://oldforge.etsi.org/mantis/file_download.php?file_id=2817&type=bug
doc CR6520-6519-6518-6517-6516-Res-V1-130711.doc (753,664) 11-07-2013 16:06
http://oldforge.etsi.org/mantis/file_download.php?file_id=2837&type=bug
Issue History
Date ModifiedUsernameFieldChange
05-04-2013 14:19Tomas UrbanNew Issue
05-04-2013 14:19Tomas UrbanClause Reference(s) => A.2
05-04-2013 14:19Tomas UrbanSource (company - Author) => Elvior
08-07-2013 14:51Jens GrabowskiStatusnew => assigned
08-07-2013 14:51Jens GrabowskiAssigned To => Jens Grabowski
08-07-2013 17:09Gyorgy RethyProjectTTCN-3 Change Requests => Ext Pack: Continuous signal support (ES 202 786)
08-07-2013 17:09Gyorgy RethyTarget Version => v1.2.1 (published 2014-06)
10-07-2013 15:59Jens GrabowskiNote Added: 0011515
10-07-2013 16:23Jens GrabowskiFile Added: CR6517-Resolution-V1-130710.doc
10-07-2013 16:23Jens GrabowskiNote Added: 0011516
10-07-2013 16:23Jens GrabowskiAssigned ToJens Grabowski => Gyorgy Rethy
11-07-2013 15:46Jens GrabowskiAssigned ToGyorgy Rethy => Jens Grabowski
11-07-2013 16:06Jens GrabowskiFile Added: CR6520-6519-6518-6517-6516-Res-V1-130711.doc
11-07-2013 16:06Jens GrabowskiNote Added: 0011557
11-07-2013 16:21Jens GrabowskiAssigned ToJens Grabowski => Jacob Wieland - Spirent
11-07-2013 16:30Jacob Wieland - SpirentStatusassigned => resolved
11-07-2013 16:30Jacob Wieland - SpirentFixed in Version => v1.2.1 (published 2014-06)
11-07-2013 16:30Jacob Wieland - SpirentResolutionopen => fixed
12-07-2013 08:54Jens GrabowskiAssigned ToJacob Wieland - Spirent => Jens Grabowski
12-07-2013 08:54Jens GrabowskiStatusresolved => feedback
12-07-2013 08:54Jens GrabowskiResolutionfixed => reopened
12-07-2013 08:54Jens GrabowskiNote Added: 0011564
12-07-2013 08:55Jens GrabowskiStatusfeedback => resolved
12-07-2013 08:55Jens GrabowskiResolutionreopened => fixed
26-12-2013 13:01Jens GrabowskiStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011515) +
+ Jens Grabowski    +
+ 10-07-2013 15:59    +
+ 		+ + + + +
+ Resolution as proposed by reporter.
+
+(Note removal of rules 39-44 and change of rule 35 is due to the implementation of CR6518)
+
+
+
+ + + + + + + + + + +
+ (0011516) +
+ Jens Grabowski    +
+ 10-07-2013 16:23    +
+ 		+ + + + +
+ György, please crosscheck
+
+
+
+ + + + + + + + + + +
+ (0011557) +
+ Jens Grabowski    +
+ 11-07-2013 16:06    +
+ 		+ + + + +
+ Resolution of CR 6520, 6519, 6518, 6517, 6516 in one file.
+
+
+
+ + + + + + + + + + +
+ (0011564) +
+ Jens Grabowski    +
+ 12-07-2013 08:54    +
+ 		+ + + + +
+ Assigned to Editor of Package.
+
+ + diff --git a/docs/mantis/CR6518.md b/docs/mantis/CR6518.md new file mode 100644 index 0000000000000000000000000000000000000000..67342d1c53088ebaada7b2e15397c879da89e5ec --- /dev/null +++ b/docs/mantis/CR6518.md @@ -0,0 +1,167 @@ + + + + + + + + + + + + + 0006518: Continuous signalling: find and violates - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Continuous signal support (ES 202 786)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006518Ext Pack: Continuous signal support (ES 202 786)Editorialpublic05-04-2013 14:2426-12-2013 13:03
ReporterTomas Urban 
Assigned ToJens Grabowski 
PrioritynormalSeveritymajorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv1.2.1 (published 2014-06)Fixed in Versionv1.2.1 (published 2014-06) 
Summary0006518: Continuous signalling: find and violates
DescriptionThe continuous signalling specification mentions find and violates operations in 5.2.5 and defines syntactical rules for them in the BNF (A.2 rules 35, 39, 42), but semantical definition is completely missing, i.e. it is completely unknown what these operations should do.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR6518-Resolution-V1-130710.doc (140,800) 10-07-2013 15:52
http://oldforge.etsi.org/mantis/file_download.php?file_id=2816&type=bug
doc CR6520-6519-6518-6517-6516-Res-V1-130711.doc (753,664) 11-07-2013 16:04
http://oldforge.etsi.org/mantis/file_download.php?file_id=2836&type=bug
Issue History
Date ModifiedUsernameFieldChange
05-04-2013 14:24Tomas UrbanNew Issue
05-04-2013 14:24Tomas UrbanClause Reference(s) => 5.2.5, A.2
05-04-2013 14:24Tomas UrbanSource (company - Author) => Elvior
08-07-2013 14:50Jens GrabowskiStatusnew => assigned
08-07-2013 14:50Jens GrabowskiAssigned To => Jens Grabowski
08-07-2013 17:08Gyorgy RethyProjectTTCN-3 Change Requests => Ext Pack: Continuous signal support (ES 202 786)
08-07-2013 17:08Gyorgy RethyTarget Version => v1.2.1 (published 2014-06)
10-07-2013 15:43Jens GrabowskiNote Added: 0011511
10-07-2013 15:52Jens GrabowskiFile Added: CR6518-Resolution-V1-130710.doc
10-07-2013 15:52Jens GrabowskiNote Added: 0011514
10-07-2013 15:53Jens GrabowskiAssigned ToJens Grabowski => Gyorgy Rethy
11-07-2013 15:47Jens GrabowskiAssigned ToGyorgy Rethy => Jens Grabowski
11-07-2013 16:04Jens GrabowskiFile Added: CR6520-6519-6518-6517-6516-Res-V1-130711.doc
11-07-2013 16:05Jens GrabowskiNote Added: 0011556
11-07-2013 16:21Jens GrabowskiAssigned ToJens Grabowski => Jacob Wieland - Spirent
11-07-2013 16:26Jacob Wieland - SpirentStatusassigned => resolved
11-07-2013 16:26Jacob Wieland - SpirentFixed in Version => v1.2.1 (published 2014-06)
11-07-2013 16:26Jacob Wieland - SpirentResolutionopen => fixed
12-07-2013 08:55Jens GrabowskiAssigned ToJacob Wieland - Spirent => Jens Grabowski
12-07-2013 08:55Jens GrabowskiStatusresolved => feedback
12-07-2013 08:55Jens GrabowskiResolutionfixed => reopened
12-07-2013 08:55Jens GrabowskiNote Added: 0011565
12-07-2013 08:56Jens GrabowskiStatusfeedback => resolved
12-07-2013 08:56Jens GrabowskiResolutionreopened => fixed
26-12-2013 13:03Jens GrabowskiStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011511) +
+ Jens Grabowski    +
+ 10-07-2013 15:43    +
+ 		+ + + + +
+ A few functions have been removed from the original proposal, mainly functions for convenience. The removal "find" and "violates" was incomplete.
+
+Resolution proposal: Removal of the functions in text and BNF.
+
+
+
+ + + + + + + + + + +
+ (0011514) +
+ Jens Grabowski    +
+ 10-07-2013 15:52    +
+ 		+ + + + +
+ György, please crosscheck.
+
+
+
+ + + + + + + + + + +
+ (0011556) +
+ Jens Grabowski    +
+ 11-07-2013 16:05    +
+ 		+ + + + +
+ Resolution of CR 6520, 6519, 6518, 6517, 6516 in one file.
+
+
+
+ + + + + + + + + + +
+ (0011565) +
+ Jens Grabowski    +
+ 12-07-2013 08:55    +
+ 		+ + + + +
+ Assigned to Editor of Package
+
+ + diff --git a/docs/mantis/CR6519.md b/docs/mantis/CR6519.md new file mode 100644 index 0000000000000000000000000000000000000000..18a4e1e93815f861c46df378c327ac7f0c3cc386 --- /dev/null +++ b/docs/mantis/CR6519.md @@ -0,0 +1,179 @@ + + + + + + + + + + + + + 0006519: Continuous signalling: use of external packages - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Continuous signal support (ES 202 786)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006519Ext Pack: Continuous signal support (ES 202 786)Editorialpublic05-04-2013 15:0026-12-2013 13:01
ReporterTomas Urban 
Assigned ToJens Grabowski 
PrioritynormalSeveritymajorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv1.2.1 (published 2014-06)Fixed in Versionv1.2.1 (published 2014-06) 
Summary0006519: Continuous signalling: use of external packages
DescriptionThe continuous signalling specification refers to and uses rules defined in other external packages (e.g. advanced parameterization in 5.2.1 or behaviour types in 5.4.5). However, these external packages are not referenced in the document (in particular in chapter 2).
+
+In my opinion, dependency between extension packages shall be reduced to the absolute minimum and if such a dependency cannot be avoided, then the following rules shall be observed:
+1. The extension package whose rules are used (source extension package) shall be referenced in the dependent extension package
+2. The part of the dependent extension package that uses the rules of the source extension package shall be optional
+3. When using features described in the point 2, both packages shall be referenced in the language clause of the module
+
+The above defined rules make sure that extension packages don't automatically enable features of other extension packages which is confusing for the users (as they might not be familiar with those extension packages) and imposes unnecessary requirements on TTCN-3 tool vendors as the other packages might not be supported by them.
+
+In case of the continuous signalling package I propose following:
+1. Remove syntactical features of the advanced parameterization package from the chapter 5.2.1 as they are used only in examples
+2. Change the mode type defined in 5.4.5.1 to an optinal feature dependent on the behaviour type extension package according to the above specified rules
+3. Simplify the example in 5.4.2.2 so that it doesn't use behaviour types (the mode definition shall be used directly)
+4. Swap chapters 5.4.5.1 and 5.4.5.2, because mode type is optional and dependent on parameterized mode definition
+5. Add missing reference to the behaviour type specification
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR6519-Res-V1-130711.doc (660,992) 11-07-2013 15:44
http://oldforge.etsi.org/mantis/file_download.php?file_id=2833&type=bug
doc CR6520-6519-6518-6517-6516-Res-V1-130711.doc (753,664) 11-07-2013 16:06
http://oldforge.etsi.org/mantis/file_download.php?file_id=2838&type=bug
Issue History
Date ModifiedUsernameFieldChange
05-04-2013 15:00Tomas UrbanNew Issue
05-04-2013 15:00Tomas UrbanClause Reference(s) => 5.2.1, 5.4.5
05-04-2013 15:00Tomas UrbanSource (company - Author) => Elvior
08-07-2013 14:39Jens GrabowskiStatusnew => assigned
08-07-2013 14:39Jens GrabowskiAssigned To => Jens Grabowski
08-07-2013 14:50Jens GrabowskiNote Added: 0011449
08-07-2013 17:05Gyorgy RethyProjectTTCN-3 Change Requests => Ext Pack: Continuous signal support (ES 202 786)
08-07-2013 17:07Gyorgy RethyTarget Version => v1.2.1 (published 2014-06)
11-07-2013 15:44Jens GrabowskiFile Added: CR6519-Res-V1-130711.doc
11-07-2013 15:44Jens GrabowskiNote Added: 0011553
11-07-2013 16:06Jens GrabowskiFile Added: CR6520-6519-6518-6517-6516-Res-V1-130711.doc
11-07-2013 16:07Jens GrabowskiNote Added: 0011558
11-07-2013 16:15Jens GrabowskiProjectExt Pack: Continuous signal support (ES 202 786) => TTCN-3 Change Requests
11-07-2013 16:19Jens GrabowskiProjectTTCN-3 Change Requests => Ext Pack: Continuous signal support (ES 202 786)
11-07-2013 16:20Jens GrabowskiAssigned ToJens Grabowski => Jacob Wieland - Spirent
11-07-2013 16:41Jacob Wieland - SpirentStatusassigned => resolved
11-07-2013 16:41Jacob Wieland - SpirentFixed in Version => v1.2.1 (published 2014-06)
11-07-2013 16:41Jacob Wieland - SpirentResolutionopen => fixed
12-07-2013 08:52Jens GrabowskiAssigned ToJacob Wieland - Spirent => Jens Grabowski
12-07-2013 08:52Jens GrabowskiStatusresolved => feedback
12-07-2013 08:52Jens GrabowskiResolutionfixed => reopened
12-07-2013 08:52Jens GrabowskiNote Added: 0011562
12-07-2013 08:52Jens GrabowskiStatusfeedback => resolved
12-07-2013 08:52Jens GrabowskiResolutionreopened => fixed
26-12-2013 13:01Jens GrabowskiStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011449) +
+ Jens Grabowski    +
+ 08-07-2013 14:50    +
+ 		+ + + + +
+ Proposal: Split in two CRs. One CR is related to Continuous Signals, one CR treats the problem in general.
+
+
+
+ + + + + + + + + + +
+ (0011553) +
+ Jens Grabowski    +
+ 11-07-2013 15:44    +
+ 		+ + + + +
+ Implemented according to the proposal of the reporter.
+
+
+
+ + + + + + + + + + +
+ (0011558) +
+ Jens Grabowski    +
+ 11-07-2013 16:07    +
+ 		+ + + + +
+ Resolution of CR 6520, 6519, 6518, 6517, 6516 in one file.
+
+
+
+ + + + + + + + + + +
+ (0011562) +
+ Jens Grabowski    +
+ 12-07-2013 08:52    +
+ 		+ + + + +
+ should be reassigned to editor of Package.
+
+ + diff --git a/docs/mantis/CR6520.md b/docs/mantis/CR6520.md new file mode 100644 index 0000000000000000000000000000000000000000..29a85e4c3c983d9a16a829f700a28fc0f4c5a843 --- /dev/null +++ b/docs/mantis/CR6520.md @@ -0,0 +1,132 @@ + + + + + + + + + + + + + 0006520: Continuous signalling: PortValueOp shall not define a keyword - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Continuous signal support (ES 202 786)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006520Ext Pack: Continuous signal support (ES 202 786)Editorialpublic05-04-2013 15:1026-12-2013 13:00
ReporterTomas Urban 
Assigned ToJens Grabowski 
PrioritynormalSeveritytrivialReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv1.2.1 (published 2014-06)Fixed in Version 
Summary0006520: Continuous signalling: PortValueOp shall not define a keyword
DescriptionThe PortValueOp rule in BNF defines a "value" keyword. However, this keyword is already defined in the core language specification (rule 330.ValueKeyword). The PortValueOp rule shall be changed so that it references the keyword definition in the core language specification:
+15.PortValueOp ::= ValueKeyword
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR6520-Res-V1-130709.doc (116,736) 09-07-2013 16:00
http://oldforge.etsi.org/mantis/file_download.php?file_id=2805&type=bug
Issue History
Date ModifiedUsernameFieldChange
05-04-2013 15:10Tomas UrbanNew Issue
05-04-2013 15:10Tomas UrbanClause Reference(s) => A.2
05-04-2013 15:10Tomas UrbanSource (company - Author) => Elvior
08-07-2013 14:38Jens GrabowskiStatusnew => assigned
08-07-2013 14:38Jens GrabowskiAssigned To => Jens Grabowski
08-07-2013 16:49Gyorgy RethyProjectTTCN-3 Change Requests => Ext Pack: Continuous signal support (ES 202 786)
08-07-2013 16:49Gyorgy RethyTarget Version => v1.2.1 (published 2014-06)
09-07-2013 15:59Jens GrabowskiNote Added: 0011482
09-07-2013 16:00Jens GrabowskiFile Added: CR6520-Res-V1-130709.doc
09-07-2013 16:04Jens GrabowskiNote Added: 0011483
09-07-2013 16:04Jens GrabowskiAssigned ToJens Grabowski => Gyorgy Rethy
10-07-2013 09:05Gyorgy RethyNote Added: 0011493
10-07-2013 09:05Gyorgy RethyAssigned ToGyorgy Rethy => Jens Grabowski
10-07-2013 09:05Gyorgy RethyStatusassigned => resolved
26-12-2013 13:00Jens GrabowskiStatusresolved => closed
26-12-2013 13:00Jens GrabowskiResolutionopen => fixed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011482) +
+ Jens Grabowski    +
+ 09-07-2013 15:59    +
+ 		+ + + + +
+ Implemented as proposed by Reporter.
+
+
+
+ + + + + + + + + + +
+ (0011483) +
+ Jens Grabowski    +
+ 09-07-2013 16:04    +
+ 		+ + + + +
+ György please check if (trivial) solution is OK.
+
+
+
+ + + + + + + + + + +
+ (0011493) +
+ Gyorgy Rethy    +
+ 10-07-2013 09:05    +
+ 		+ + + + +
+ It's OK.
+
+ + diff --git a/docs/mantis/CR6521.md b/docs/mantis/CR6521.md new file mode 100644 index 0000000000000000000000000000000000000000..bf765b4287450d2cdcf5ebc66d93d301278504fb --- /dev/null +++ b/docs/mantis/CR6521.md @@ -0,0 +1,63 @@ + + + + + + + + + + + + + 0006521: Section 8.3.3.1: last method name incorrect in description section - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006521Part 06: TTCN-3 Control InterfaceEditorialpublic07-04-2013 16:2411-07-2013 16:59
ReporterAlexandre Berge 
Assigned ToIna Schieferdecker 
PrioritynormalSeveritytextReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.4.1 (published 2012-04) 
Target Versionv4.6.1 (published 2014-06)Fixed in Versionv4.6.1 (published 2014-06) 
Clause Reference(s)8.3.3.1
Source (company - Author)AMB Consulting - berge
Summary0006521: Section 8.3.3.1: last method name incorrect in description section
DescriptionLast item of the "methods" description section should be "getTypeExtension" instead of "getTypeEncoding"
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
07-04-2013 16:24Alexandre BergeNew Issue
07-04-2013 16:24Alexandre BergeClause Reference(s) => 8.3.3.1
07-04-2013 16:24Alexandre BergeSource (company - Author) => AMB Consulting - berge
08-07-2013 14:36Jens GrabowskiStatusnew => assigned
08-07-2013 14:36Jens GrabowskiAssigned To => Ina Schieferdecker
08-07-2013 16:48Gyorgy RethyTarget Version => v4.6.1 (published 2014-06)
09-07-2013 13:58Ina SchieferdeckerNote Added: 0011472
11-07-2013 16:59Ina SchieferdeckerStatusassigned => resolved
11-07-2013 16:59Ina SchieferdeckerFixed in Version => v4.6.1 (published 2014-06)
11-07-2013 16:59Ina SchieferdeckerResolutionopen => fixed
11-07-2013 16:59Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011472) +
+ Ina Schieferdecker    +
+ 09-07-2013 13:58    +
+ 		+ + + + +
+ Ok in the code, but to be corrected in the method description list
+
+ + diff --git a/docs/mantis/CR6522.md b/docs/mantis/CR6522.md new file mode 100644 index 0000000000000000000000000000000000000000..b1811aeae33e33aed856d3ce055bc9e6846ec3f4 --- /dev/null +++ b/docs/mantis/CR6522.md @@ -0,0 +1,167 @@ + + + + + + + + + + + + + 0006522: No way to specify configuration reference for "tciStartTestCase" in TCI-TM - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Config & Deployment Support (ES 202 781)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006522Ext Pack: Config & Deployment Support (ES 202 781)Clarificationpublic08-04-2013 10:4826-12-2013 13:35
ReporterJanek Nikolajev 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv1.1.1 (published 2010-08) 
Target Versionv1.3.1 (published 2014-06)Fixed in Version 
Clause Reference(s)8.2
Source (company - Author)Elvior - Janek Nikolajev
TS version1.1.1
Summary0006522: No way to specify configuration reference for "tciStartTestCase" in TCI-TM
DescriptionAny number of static configurations can be created and killed, but there is no way how to specify what existing configuration reference to use when starting a test case over TCI-TM interface.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0006523closed Jens Grabowski Static configuration TciValue reference representation is not specified 
related to 0006469closed Jens Grabowski TRI and TCI C# mapping is missing 
Attached Filesdocx CR6522.docx (24,075) 08-10-2013 16:50
http://oldforge.etsi.org/mantis/file_download.php?file_id=2897&type=bug
Issue History
Date ModifiedUsernameFieldChange
08-04-2013 10:48Janek NikolajevNew Issue
08-04-2013 10:48Janek NikolajevClause Reference(s) => 8.2
08-04-2013 10:48Janek NikolajevSource (company - Author) => Elvior - Janek Nikolajev
08-04-2013 10:48Janek NikolajevTS version => 1.1.1
08-07-2013 14:35Jens GrabowskiStatusnew => assigned
08-07-2013 14:35Jens GrabowskiAssigned To => Ina Schieferdecker
08-07-2013 16:48Gyorgy RethyTarget Version => v1.3.1 (published 2014-06)
09-07-2013 13:51Ina SchieferdeckerRelationship addedrelated to 0006523
09-07-2013 13:53Ina SchieferdeckerNote Added: 0011471
08-10-2013 16:50Ina SchieferdeckerFile Added: CR6522.docx
08-10-2013 16:51Ina SchieferdeckerNote Added: 0011708
08-10-2013 16:52Ina SchieferdeckerNote Added: 0011709
08-10-2013 16:52Ina SchieferdeckerAssigned ToIna Schieferdecker => Jens Grabowski
08-10-2013 16:52Ina SchieferdeckerStatusassigned => confirmed
10-10-2013 19:18Ina SchieferdeckerRelationship addedrelated to 0006469
26-12-2013 13:35Jens GrabowskiNote Added: 0011897
26-12-2013 13:35Jens GrabowskiStatusconfirmed => closed
26-12-2013 13:35Jens GrabowskiResolutionopen => fixed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011471) +
+ Ina Schieferdecker    +
+ 09-07-2013 13:53    +
+ 		+ + + + +
+ See 0006523
+
+
+
+ + + + + + + + + + +
+ (0011708) +
+ Ina Schieferdecker    +
+ 08-10-2013 16:51    +
+ 		+ + + + +
+ The same issue exists for tciExecuteTestCaseReq and tciExecuteTestCase
+
+The addition of the parameter to theses TM and CH operations is a backward incompatible change and requires discussion.
+
+
+
+ + + + + + + + + + +
+ (0011709) +
+ Ina Schieferdecker    +
+ 08-10-2013 16:52    +
+ 		+ + + + +
+ Please check (the mappings are to be adjusted once having agreed on a solution)
+
+
+
+ + + + + + + + + + +
+ (0011897) +
+ Jens Grabowski    +
+ 26-12-2013 13:35    +
+ 		+ + + + +
+ Implemented as suggested!
+
+ + diff --git a/docs/mantis/CR6523.md b/docs/mantis/CR6523.md new file mode 100644 index 0000000000000000000000000000000000000000..4b91bc504680d566f8d2572294d92f9f7dbdbfd7 --- /dev/null +++ b/docs/mantis/CR6523.md @@ -0,0 +1,145 @@ + + + + + + + + + + + + + 0006523: Static configuration TciValue reference representation is not specified - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Config & Deployment Support (ES 202 781)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006523Ext Pack: Config & Deployment Support (ES 202 781)Clarificationpublic08-04-2013 11:2526-12-2013 13:37
ReporterJanek Nikolajev 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv1.1.1 (published 2010-08) 
Target Versionv1.3.1 (published 2014-06)Fixed in Version 
Clause Reference(s)7.3.1.1.12, 7.3.1.2.7
Source (company - Author)Elvior - Janek Nikolajev
TS version1.1.1
Summary0006523: Static configuration TciValue reference representation is not specified
DescriptionThe TCI Value type and representation is not specified for the static configuration reference parameter in the following TM functions:
+
+void tciConfigStarted(in Value ref);
+void tciKillConfig(in Value ref);
+
+void tciConfigStarted(in Value ref);
+void tciConfigKilled(in Value ref);
+
+We suggest that CONFIGURATION type to be added to TciTypeClass enumeration list.
+The static configuration reference value should have an abstract representation similar to DEFAULT, PORT, TIMER values in the future TCI standard versions.
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0006455closed Jens Grabowski Logging of configurations 
related to 0006522closed Jens Grabowski No way to specify configuration reference for "tciStartTestCase" in TCI-TM 
related to 0006469closed Jens Grabowski TRI and TCI C# mapping is missing 
Attached Filesdocx CR6523.docx (25,642) 08-10-2013 08:30
http://oldforge.etsi.org/mantis/file_download.php?file_id=2893&type=bug
Issue History
Date ModifiedUsernameFieldChange
08-04-2013 11:25Janek NikolajevNew Issue
08-04-2013 11:25Janek NikolajevClause Reference(s) => 7.3.1.1.12, 7.3.1.2.7
08-04-2013 11:25Janek NikolajevSource (company - Author) => Elvior - Janek Nikolajev
08-04-2013 11:25Janek NikolajevTS version => 1.1.1
08-07-2013 14:33Jens GrabowskiStatusnew => assigned
08-07-2013 14:33Jens GrabowskiAssigned To => Ina Schieferdecker
08-07-2013 16:38Gyorgy RethyTarget Version => v1.3.1 (published 2014-06)
09-07-2013 10:49Ina SchieferdeckerRelationship addedrelated to 0006455
09-07-2013 11:53Ina SchieferdeckerNote Added: 0011459
09-07-2013 13:51Ina SchieferdeckerRelationship addedrelated to 0006522
08-10-2013 08:30Ina SchieferdeckerFile Added: CR6523.docx
08-10-2013 08:30Ina SchieferdeckerNote Added: 0011694
08-10-2013 08:30Ina SchieferdeckerStatusassigned => confirmed
08-10-2013 08:30Ina SchieferdeckerStatusconfirmed => assigned
08-10-2013 08:30Ina SchieferdeckerAssigned ToIna Schieferdecker => Jens Grabowski
09-10-2013 15:04Ina SchieferdeckerStatusassigned => confirmed
10-10-2013 19:19Ina SchieferdeckerRelationship addedrelated to 0006469
26-12-2013 13:36Jens GrabowskiNote Added: 0011898
26-12-2013 13:37Jens GrabowskiStatusconfirmed => closed
26-12-2013 13:37Jens GrabowskiResolutionopen => fixed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011459) +
+ Ina Schieferdecker    +
+ 09-07-2013 11:53    +
+ 		+ + + + +
+ Proposal would be to add
+- TciConfigurationIdType
+- use TciConfigurationIdType instead of Value
+- add CONFIGURATION to tciTypeClassType
+- check all operations and language mappings accordingly
+
+
+
+ + + + + + + + + + +
+ (0011694) +
+ Ina Schieferdecker    +
+ 08-10-2013 08:30    +
+ 		+ + + + +
+ Please check.
+
+
+
+ + + + + + + + + + +
+ (0011898) +
+ Jens Grabowski    +
+ 26-12-2013 13:36    +
+ 		+ + + + +
+ Implemented as suggested!
+
+ + diff --git a/docs/mantis/CR6562.md b/docs/mantis/CR6562.md new file mode 100644 index 0000000000000000000000000000000000000000..dbaa875a8264f84240423fe80912e3f18ee39453 --- /dev/null +++ b/docs/mantis/CR6562.md @@ -0,0 +1,453 @@ + + + + + + + + + + + + + 0006562: Use of template references in expression - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006562Part 01: TTCN-3 Core LanguageClarificationpublic24-05-2013 15:3512-07-2013 10:26
ReporterTomas Urban 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.4.1 (published 2012-04) 
Target Versionv4.6.1 (published 2014-06)Fixed in Versionv4.6.1 (published 2014-06) 
Clause Reference(s)15
Source (company - Author)Elvior
Summary0006562: Use of template references in expression
DescriptionWe have had a long discussion with the STF writing TTCN-3 complience test regarding refencing templates in expressions and it seems that we cannot find a common stance. Our position is that regardless of what the template contains, it cannot be used in expressions directly. The STF claims that if the template contains a value (and no matching symbols), it can be refenced.
+
+There are arguments supporting both interpretations:
+1. The BNF doesn't seem to contain any static semantics about references inside expressions (supporting STF's position)
+2. On the other hand, the BNF makes a difference between ReferencedValue and TemplateRefWithParList. This means that instances of parameterized templates are not allowed in expressions which wouldn't make sense if common templates were allowed.
+3. If direct template referencing were possible, the valueof operator would be completely useless.
+
+Proposal:
+An explicit rule shall be added to the core language specification (either chapter 7 or 15) saying that template refences are either allowed (if they contain no matching symbols) or forbidden in expressions. We support the latter option, because it allows the user to discover potentially harmful use of template reference already in compilation time. However, we think it is worth of considering, whether this restriction shall apply to templates with a value restriction, because they cannot contain matching symbols and therefore it is safe to use them inside expressions.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0006580closed Ina Schieferdecker It must be clarified in the standard whether the first parameter in match() can be a template 
Attached Filesdoc CR6562_resolution_v1.doc (82,432) 09-07-2013 11:56
http://oldforge.etsi.org/mantis/file_download.php?file_id=2804&type=bug
doc CR6562_resolution_v2.doc (83,456) 10-07-2013 08:50
http://oldforge.etsi.org/mantis/file_download.php?file_id=2806&type=bug
doc CR6562_resolution_v3.doc (83,456) 10-07-2013 14:19
http://oldforge.etsi.org/mantis/file_download.php?file_id=2808&type=bug
doc CR6562_resolution_v4.doc (84,992) 11-07-2013 16:00
http://oldforge.etsi.org/mantis/file_download.php?file_id=2835&type=bug
doc CR6562_resolution_v5.doc (74,240) 11-07-2013 16:12
http://oldforge.etsi.org/mantis/file_download.php?file_id=2840&type=bug
Issue History
Date ModifiedUsernameFieldChange
24-05-2013 15:35Tomas UrbanNew Issue
24-05-2013 15:35Tomas UrbanClause Reference(s) => 15
24-05-2013 15:35Tomas UrbanSource (company - Author) => Elvior
08-07-2013 12:00Jacob Wieland - SpirentNote Added: 0011448
08-07-2013 14:31Jens GrabowskiStatusnew => assigned
08-07-2013 14:31Jens GrabowskiAssigned To => Ina Schieferdecker
08-07-2013 14:33Jens GrabowskiAssigned ToIna Schieferdecker => Gyorgy Rethy
08-07-2013 16:38Gyorgy RethyTarget Version => v4.6.1 (published 2014-06)
09-07-2013 11:55Gyorgy RethyNote Added: 0011460
09-07-2013 11:56Gyorgy RethyFile Added: CR6562_resolution_v1.doc
09-07-2013 13:46Jacob Wieland - SpirentNote Added: 0011468
09-07-2013 14:01Jacob Wieland - SpirentNote Added: 0011473
10-07-2013 08:50Gyorgy RethyNote Added: 0011491
10-07-2013 08:50Gyorgy RethyFile Added: CR6562_resolution_v2.doc
10-07-2013 11:59Gyorgy RethyNote Edited: 0011491
10-07-2013 12:02Gyorgy RethyNote Edited: 0011460
10-07-2013 13:31Gyorgy RethyNote Added: 0011501
10-07-2013 13:32Gyorgy RethyFile Added: CR6562_resolution_v3.doc
10-07-2013 13:32Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
10-07-2013 13:32Gyorgy RethyStatusassigned => resolved
10-07-2013 13:32Gyorgy RethyResolutionopen => fixed
10-07-2013 13:42Gyorgy RethyNote Edited: 0011460
10-07-2013 13:51Gyorgy RethyNote Added: 0011502
10-07-2013 13:51Gyorgy RethyNote Edited: 0011502
10-07-2013 14:19Gyorgy RethyFile Deleted: CR6562_resolution_v3.doc
10-07-2013 14:19Gyorgy RethyFile Added: CR6562_resolution_v3.doc
11-07-2013 08:46Gyorgy RethyRelationship addedrelated to 0006580
11-07-2013 11:09Ina SchieferdeckerNote Added: 0011534
11-07-2013 11:09Ina SchieferdeckerAssigned ToIna Schieferdecker => Gyorgy Rethy
11-07-2013 11:09Ina SchieferdeckerStatusresolved => confirmed
11-07-2013 14:22Gyorgy RethyNote Added: 0011547
11-07-2013 14:24Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
11-07-2013 14:24Gyorgy RethyStatusconfirmed => resolved
11-07-2013 15:59Ina SchieferdeckerNote Added: 0011555
11-07-2013 16:00Ina SchieferdeckerFile Added: CR6562_resolution_v4.doc
11-07-2013 16:00Ina SchieferdeckerStatusresolved => assigned
11-07-2013 16:00Ina SchieferdeckerAssigned ToIna Schieferdecker => Gyorgy Rethy
11-07-2013 16:12Gyorgy RethyFile Added: CR6562_resolution_v5.doc
11-07-2013 16:13Gyorgy RethyNote Added: 0011560
11-07-2013 16:14Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
11-07-2013 16:14Gyorgy RethyStatusassigned => confirmed
12-07-2013 10:25Ina SchieferdeckerStatusconfirmed => resolved
12-07-2013 10:25Ina SchieferdeckerFixed in Version => v4.6.1 (published 2014-06)
12-07-2013 10:26Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011448) +
+ Jacob Wieland - Spirent    +
+ 08-07-2013 12:00    +
+ 		+ + + + +
+ This would introduce huge backward-incompatibility issues. The load for reducing user-errors should be shouldered by the tools (i.e. by warnings) and not by unnecessary restrictions of the standard.
+
+The basic problem stems from the usage of templates both for building messages for sending (definitely a value) and for matching (probably no value). Later introduced template restrictions have alleviated this problem somewhat but the problem remains for the unrestricted templates.
+
+Maybe the unrestricted template construct should be made deprecated so that future test suites will be discouraged from using this feature.
+
+
+
+ + + + + + + + + + +
+ (0011460) +
+ Gyorgy Rethy    +
+ 09-07-2013 11:55    +
(edited on: 10-07-2013 13:42)
+ 		+ + + + +
+ In TTCN-3 a data is a value or template by _definition_ and not by content. Let separate the problem into two parts: 1) can template be used in expressions? 2) Is it defined clearly enough what is a template and what is a value?
+
+1) Clause Semantic Description says:
+"The operands of the operators used in an expression shall be values..."
+I think this statement is sufficient.
+
+The BNF specifies the syntax only, therefore it is more "allowing" than the language as a whole, no conclusions can be made based on the BNF only. For example, OpCall also contains TestcaseInstance, while it cannot be present in any Expression, just in Expressions in the control part.
+
+Expressions in TTCN-3 today mean both "pure" references and "real" expressions involving operations. While simple references can be templates, if the LHS is a template, "real" expressions can contain values only, i.e. no templates with value content is allowed. In principle, these two cases could be separated in the BNF but value/template returning functions would make this separation complicated.
+Examples:
+const integer c_int1 := 5;
+const integer c_int2 := 42;
+template integer t_int := 0;
+...
+var template integer vt_int := t_int; // allowed, both RHS and LHS are templates, Expression is: "t_int"
+var integer v_int := c_int2 - c_int1; allowed,Expression is a operands are values
+v_int := vt_int; //not allowed, if RHS is template, LHS shall be a template too
+                 // Expression is: "t_int"
+
+
+2) Once this question is coming up time-to-time, it seems that the standard should define even more precisely what is a value and what is a template. See my proposal in the attached file CR6562_resolution_v1.doc.
+
+
+
+
+
+ + + + + + + + + + +
+ (0011468) +
+ Jacob Wieland - Spirent    +
+ 09-07-2013 13:46    +
+ 		+ + + + +
+ "A TTCN 3 value is a data object containing a specific value of its type" seems to be a circular definition to me (as we are in the definition of "value").
+
+I guess an actual definition would have to employ some set/type-theory to be non-circular.
+
+
+
+ + + + + + + + + + +
+ (0011473) +
+ Jacob Wieland - Spirent    +
+ 09-07-2013 14:01    +
+ 		+ + + + +
+ Basically, I would define a value as a distinct element of a type while a template describes the (possibly single-element) subset of values of a type that it matches.
+
+So, while the set of single-element subsets of a type is isomorphic to the set of values of a type, it is not the same thing. The valueof operation is a partial operation on the set of templates which maps the subset of one-element-sets to its value counterparts (i.e. the single value they match).
+
+
+
+ + + + + + + + + + +
+ (0011491) +
+ Gyorgy Rethy    +
+ 10-07-2013 08:50    +
(edited on: 10-07-2013 11:59)
+ 		+ + + + +
+ Good point, Jacob, see the updated definitions in CR6562_resolution_v2.doc.
+
+
+
+
+
+ + + + + + + + + + +
+ (0011501) +
+ Gyorgy Rethy    +
+ 10-07-2013 13:31    +
+ 		+ + + + +
+ STF decision 2013-07-10:
+- No need to change the BNF and the sentence saying that operands shall be values is sufficient (i.e. when no operation is involved, expression (the RHS) can be both values or templates provided the restrictions are respected, but operands shall be values only).
+- For definition of templates and values see CR6562_resolution_v3.doc
+
+
+
+ + + + + + + + + + +
+ (0011502) +
+ Gyorgy Rethy    +
+ 10-07-2013 13:51    +
+ 		+ + + + +
+ I propose, in addition, to amend the first sentence of clause 7.
+
+The sentence now: "TTCN 3 allows the specification of expressions using the operators defined in clause 7.1."
+
+Proposed text: "TTCN 3 allows the specification of expressions. TTCN-3 Expressions may be simple template or value references or literals (i.e. no operation is involved), or may be composed of the operations defined in clause 7.1."
+
+
+
+
+
+ + + + + + + + + + +
+ (0011534) +
+ Ina Schieferdecker    +
+ 11-07-2013 11:09    +
+ 		+ + + + +
+ Sentence in clause 7 better reworded into
+
+"TTCN 3 allows the specification of expressions. TTCN-3 expressions may be template references, value references or literals (i.e. no operation is involved), and may be composed of the operations defined in clause 7.1."
+
+
+
+ + + + + + + + + + +
+ (0011547) +
+ Gyorgy Rethy    +
+ 11-07-2013 14:22    +
+ 		+ + + + +
+ OK with me.
+
+
+
+ + + + + + + + + + +
+ (0011555) +
+ Ina Schieferdecker    +
+ 11-07-2013 15:59    +
+ 		+ + + + +
+ Some more rewording - please see v4
+
+
+
+ + + + + + + + + + +
+ (0011560) +
+ Gyorgy Rethy    +
+ 11-07-2013 16:13    +
+ 		+ + + + +
+ Amended the last sentence of the template definition to make it symmetric to the value definition. See in CR6562_resolution_v5.doc
+
+ + diff --git a/docs/mantis/CR6563.md b/docs/mantis/CR6563.md new file mode 100644 index 0000000000000000000000000000000000000000..2d6ea7a6ccdcebc5fee3ce8f4f33ef41681da1d8 --- /dev/null +++ b/docs/mantis/CR6563.md @@ -0,0 +1,209 @@ + + + + + + + + + + + + + 0006563: Ambiguous rule in rules on template concatenation - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006563Part 01: TTCN-3 Core LanguageClarificationpublic28-05-2013 15:3311-10-2013 12:32
ReporterTomas Urban 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.6.1 (published 2014-06)Fixed in Versionv4.6.1 (published 2014-06) 
Clause Reference(s)15.11
Source (company - Author)Elvior
Summary0006563: Ambiguous rule in rules on template concatenation
DescriptionThe current specification contains this sentence:
+The single templates of binary string and list types shall contain only the matching mechanisms specific values, AnyValue or AnyValueOrNone constrained to a fixed length, AnyElement, or AnyElementsOrNone possibly constrained with a length attribute for list types.
+
+From the description it is not clear if AnyValue shall be constrained to a fixed length or if "constrained to a fixed length" is related only to AnyValueOrNone.
+
+Proposal:
+"AnyValue or AnyValueOrNone..." shall be changed either to:
+"AnyValue constrained to a fixed length or AnyValueOrNone ..." or
+"unconstrained AnyValue, AnyValue constrained to a fixed length or AnyValueOrNone..."
+
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0006564closed Gyorgy Rethy Concatenation example using undefined rules 
Attached Filesdocx CR6563_v1.docx (17,134) 30-08-2013 10:25
http://oldforge.etsi.org/mantis/file_download.php?file_id=2879&type=bug
docx CR6563_v2.docx (17,455) 30-08-2013 14:34
http://oldforge.etsi.org/mantis/file_download.php?file_id=2882&type=bug
Issue History
Date ModifiedUsernameFieldChange
28-05-2013 15:33Tomas UrbanNew Issue
28-05-2013 15:33Tomas UrbanClause Reference(s) => 15.11
28-05-2013 15:33Tomas UrbanSource (company - Author) => Elvior
28-05-2013 15:41Tomas UrbanRelationship addedrelated to 0006564
28-05-2013 15:43Tomas UrbanNote Added: 0011439
08-07-2013 14:30Jens GrabowskiStatusnew => assigned
08-07-2013 14:30Jens GrabowskiAssigned To => Ina Schieferdecker
08-07-2013 16:37Gyorgy RethyTarget Version => v4.6.1 (published 2014-06)
30-08-2013 10:25Ina SchieferdeckerFile Added: CR6563_v1.docx
30-08-2013 10:26Ina SchieferdeckerNote Added: 0011652
30-08-2013 10:26Ina SchieferdeckerAssigned ToIna Schieferdecker => Gyorgy Rethy
30-08-2013 10:26Ina SchieferdeckerStatusassigned => confirmed
30-08-2013 14:34Gyorgy RethyNote Added: 0011664
30-08-2013 14:34Gyorgy RethyFile Added: CR6563_v2.docx
30-08-2013 14:35Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
30-08-2013 16:33Jacob Wieland - SpirentStatusconfirmed => resolved
30-08-2013 16:33Jacob Wieland - SpirentFixed in Version => v4.6.1 (published 2014-06)
30-08-2013 16:33Jacob Wieland - SpirentResolutionopen => fixed
30-08-2013 16:33Jacob Wieland - SpirentNote Added: 0011667
11-10-2013 12:32Ina SchieferdeckerStatusresolved => closed
11-10-2013 12:32Ina SchieferdeckerNote Added: 0011773
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011439) +
+ Tomas Urban    +
+ 28-05-2013 15:43    +
+ 		+ + + + +
+ If an unrestricted AnyValue is allowed, the specification shall specify rule on what will it convert to in the concatenation result. See the related CR for more details.
+
+
+
+ + + + + + + + + + +
+ (0011652) +
+ Ina Schieferdecker    +
+ 30-08-2013 10:26    +
+ 		+ + + + +
+ Please check
+
+
+
+ + + + + + + + + + +
+ (0011664) +
+ Gyorgy Rethy    +
+ 30-08-2013 14:34    +
+ 		+ + + + +
+ Actually, Tomas's comment was to the first paragraph of the clause, hence I have added "both" to that paragraph. See CR6563_v2.docx.
+
+
+
+ + + + + + + + + + +
+ (0011667) +
+ Jacob Wieland - Spirent    +
+ 30-08-2013 16:33    +
+ 		+ + + + +
+ looks alright
+
+
+
+ + + + + + + + + + +
+ (0011773) +
+ Ina Schieferdecker    +
+ 11-10-2013 12:32    +
+ 		+ + + + +
+ as proposed
+
+ + diff --git a/docs/mantis/CR6564.md b/docs/mantis/CR6564.md new file mode 100644 index 0000000000000000000000000000000000000000..c63e6440b91d4c84ce1b720a7ce75914d7a88f55 --- /dev/null +++ b/docs/mantis/CR6564.md @@ -0,0 +1,347 @@ + + + + + + + + + + + + + 0006564: Concatenation example using undefined rules - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006564Part 01: TTCN-3 Core LanguageClarificationpublic28-05-2013 15:3806-01-2015 18:57
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.4.1 (published 2012-04) 
Target Versionv4.7.1 (published 2015-06)Fixed in Versionv4.7.1 (published 2015-06) 
Clause Reference(s)15.11
Source (company - Author) Elvior
Summary0006564: Concatenation example using undefined rules
DescriptionThe chapter 15.11 contains the following example:
+template octetstring t_Myoct1 := 'ABC'O & 'D'O & ? & ? length(1) & 'EF'O;
+// results in the template 'ABCD*?EF'O
+
+In this example, AnyValue is converted into AnyElementsOrNone. However, neither the chapter 15.11 nor any other chapter contains a rule that would describe this kind of template conversion.
+
+Proposal:
+The rule shall be formally declared or the example shall be removed from the specification
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0006563closed Ina Schieferdecker Ambiguous rule in rules on template concatenation 
Attached Filesdocx CR6564_v1.docx (20,589) 29-08-2013 17:40
http://oldforge.etsi.org/mantis/file_download.php?file_id=2876&type=bug
docx CR6564_v2.docx (22,034) 07-10-2014 09:12
http://oldforge.etsi.org/mantis/file_download.php?file_id=3089&type=bug
Issue History
Date ModifiedUsernameFieldChange
28-05-2013 15:38Tomas UrbanNew Issue
28-05-2013 15:38Tomas UrbanClause Reference(s) => 15.11
28-05-2013 15:38Tomas UrbanSource (company - Author) => Elvior
28-05-2013 15:41Tomas UrbanRelationship addedrelated to 0006563
08-07-2013 11:51Jacob Wieland - SpirentNote Added: 0011447
08-07-2013 12:04Gyorgy RethyTarget Version => v4.7.1 (published 2015-06)
08-07-2013 14:26Jens GrabowskiStatusnew => assigned
08-07-2013 14:26Jens GrabowskiAssigned To => Ina Schieferdecker
09-07-2013 14:33Ina SchieferdeckerNote Added: 0011477
29-08-2013 17:40Ina SchieferdeckerFile Added: CR6564_v1.docx
29-08-2013 17:41Ina SchieferdeckerNote Added: 0011647
29-08-2013 17:41Ina SchieferdeckerStatusassigned => confirmed
29-08-2013 17:42Ina SchieferdeckerStatusconfirmed => assigned
29-08-2013 17:42Ina SchieferdeckerAssigned ToIna Schieferdecker => Jacob Wieland - Spirent
30-08-2013 16:23Jacob Wieland - SpirentStatusassigned => resolved
30-08-2013 16:23Jacob Wieland - SpirentFixed in Version => v4.6.1 (published 2014-06)
30-08-2013 16:23Jacob Wieland - SpirentResolutionopen => fixed
30-08-2013 16:23Jacob Wieland - SpirentNote Added: 0011666
09-10-2013 13:33Ina SchieferdeckerStatusresolved => assigned
09-10-2013 13:33Ina SchieferdeckerAssigned ToJacob Wieland - Spirent => Ina Schieferdecker
29-11-2013 12:43Ina SchieferdeckerNote Added: 0011867
29-11-2013 12:43Ina SchieferdeckerStatusassigned => resolved
29-11-2013 12:43Ina SchieferdeckerStatusresolved => closed
18-03-2014 12:37Tomas UrbanNote Added: 0011927
18-03-2014 12:37Tomas UrbanStatusclosed => feedback
18-03-2014 12:37Tomas UrbanResolutionfixed => reopened
07-04-2014 13:53Jens GrabowskiNote Added: 0011937
07-04-2014 13:54Jens GrabowskiAssigned ToIna Schieferdecker => Gyorgy Rethy
07-04-2014 13:54Jens GrabowskiStatusfeedback => assigned
08-04-2014 16:50Gyorgy RethyTarget Versionv4.6.1 (published 2014-06) => v4.7.1 (published 2015-06)
09-04-2014 14:06Gyorgy RethyFixed in Versionv4.6.1 (published 2014-06) =>
06-10-2014 14:48Gyorgy RethyAssigned ToGyorgy Rethy => Tomas Urban
07-10-2014 09:12Tomas UrbanFile Added: CR6564_v2.docx
07-10-2014 09:13Tomas UrbanNote Added: 0012245
07-10-2014 09:13Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
07-10-2014 09:13Tomas UrbanStatusassigned => confirmed
08-10-2014 07:53Gyorgy RethyAssigned ToGyorgy Rethy => Jens Grabowski
08-10-2014 08:41Jens GrabowskiAssigned ToJens Grabowski => Gyorgy Rethy
08-10-2014 08:41Jens GrabowskiStatusconfirmed => assigned
08-10-2014 08:41Jens GrabowskiStatusassigned => resolved
08-10-2014 08:41Jens GrabowskiResolutionreopened => fixed
06-01-2015 18:57Gyorgy RethyNote Added: 0012656
06-01-2015 18:57Gyorgy RethyStatusresolved => closed
06-01-2015 18:57Gyorgy RethyFixed in Version => v4.7.1 (published 2015-06)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011447) +
+ Jacob Wieland - Spirent    +
+ 08-07-2013 11:51    +
+ 		+ + + + +
+ Since it is clear what the semantics of ? length(X) (it matches all strings of the specified length) for a string type is, no conversion rule is necessary as the only equivalent string-notation that matches the same set of strings is the string containing exactly X AnyElements. Even though this is implicit, it is still unambiguous.
+
+
+
+ + + + + + + + + + +
+ (0011477) +
+ Ina Schieferdecker    +
+ 09-07-2013 14:33    +
+ 		+ + + + +
+ A sentence to be added in order to explain the conversion of & ? & into *
+
+Also, Octetstring examples to be checked that they contain even number of octets
+
+
+
+ + + + + + + + + + +
+ (0011647) +
+ Ina Schieferdecker    +
+ 29-08-2013 17:41    +
+ 		+ + + + +
+ Please check
+
+
+
+ + + + + + + + + + +
+ (0011666) +
+ Jacob Wieland - Spirent    +
+ 30-08-2013 16:23    +
+ 		+ + + + +
+ okay with me
+
+
+
+ + + + + + + + + + +
+ (0011867) +
+ Ina Schieferdecker    +
+ 29-11-2013 12:43    +
+ 		+ + + + +
+ as proposed
+
+
+
+ + + + + + + + + + +
+ (0011927) +
+ Tomas Urban    +
+ 18-03-2014 12:37    +
+ 		+ + + + +
+ I am not entirely happy with the resolution of this CR. The new standard indeed includes explanation of what happens during conversion, but the explanation is in a form of a comment in the sample code. There's still no formal rule supporting this kind on concatenation. On contrary, the rules actually don't allow to use plain AnyValue in template concatenation as it is required to be constrained to a single length:
+
+"The single templates of binary string and list types shall contain only the matching mechanisms specific values, AnyValue or AnyValueOrNone, both constrained to a fixed length, AnyElement, or AnyElementsOrNone possibly constrained with a length attribute for list types."
+
+
+
+ + + + + + + + + + +
+ (0011937) +
+ Jens Grabowski    +
+ 07-04-2014 13:53    +
+ 		+ + + + +
+ Sentence will be added according to Note from Ina (09-07-2013 14:33).
+
+
+
+ + + + + + + + + + +
+ (0012245) +
+ Tomas Urban    +
+ 07-10-2014 09:13    +
+ 		+ + + + +
+ The requested rule was added to the proposal.
+Please check.
+
+
+
+ + + + + + + + + + +
+ (0012656) +
+ Gyorgy Rethy    +
+ 06-01-2015 18:57    +
+ 		+ + + + +
+ Added to draft V4.6.3
+
+ + diff --git a/docs/mantis/CR6565.md b/docs/mantis/CR6565.md new file mode 100644 index 0000000000000000000000000000000000000000..701913acdba96f8d6a7af89f19df2ba0044768c6 --- /dev/null +++ b/docs/mantis/CR6565.md @@ -0,0 +1,86 @@ + + + + + + + + + + + + + 0006565: There Appears to be a parenthesis missing in rule 116 (PatternElement) - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006565Part 01: TTCN-3 Core LanguageClarificationpublic28-05-2013 18:5811-07-2013 15:13
ReporterPhilip Makedonski 
Assigned ToIna Schieferdecker 
PrioritynormalSeveritytrivialReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.6.1 (published 2014-06)Fixed in Versionv4.6.1 (published 2014-06) 
Clause Reference(s)A.1.6.1.3 Template definitions
Source (company - Author)University of Göttingen - Philip Makedonski
Summary0006565: There Appears to be a parenthesis missing in rule 116 (PatternElement)
DescriptionThere appears to be a parenthesis missing at the end of the PatternElement rule:
+
+116.PatternElement ::=
+(
+  ("\" ("?" | "*" | "\" | "[" | "]" | "{" | "}" | """ | "|" | "(" | ")" | "#" | "+" | "d" | "w" | "t" | "n" | "r" | "s" | "b" ))
+  |
+  ("?" | "*" | "\" | "|" | "+")
+  |
+  ("[" ["^"] [{PatternClassChar ["-" PatternClassChar]}]"]")
+  |
+  ("{" ["\"] ReferencedValue "}")
+  |
+  ("\" "N" "{" (ReferencedValue | Type) "}")
+  |
+  (""" """)
+  |
+  ("(" PatternElement ")")
+  |
+  ("#" (Num | ("(" Num "," [Num] ")") | ("(" "," Num ")") ))
+  |
+  PatternChar
+) <- missing parenthesis (I didn't count them, my tool did)
+
+Should be trivial to fix.
Steps To Reproduce
Additional InformationOn a related note, perhaps I am missing something but rule numbers seem to appear multiple times, no idea if it is intentional (e.g. 118, 120). Should be trivial to fix as well.
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
28-05-2013 18:58Philip MakedonskiNew Issue
28-05-2013 18:58Philip MakedonskiClause Reference(s) => A.1.6.1.3 Template definitions
28-05-2013 18:58Philip MakedonskiSource (company - Author) => University of Göttingen - Philip Makedonski
08-07-2013 14:24Jens GrabowskiStatusnew => assigned
08-07-2013 14:24Jens GrabowskiAssigned To => Ina Schieferdecker
08-07-2013 16:36Gyorgy RethyProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
08-07-2013 16:36Gyorgy RethyTarget Version => v4.6.1 (published 2014-06)
09-07-2013 14:22Ina SchieferdeckerNote Added: 0011476
11-07-2013 15:12Ina SchieferdeckerNote Added: 0011548
11-07-2013 15:12Ina SchieferdeckerNote Deleted: 0011476
11-07-2013 15:13Ina SchieferdeckerStatusassigned => resolved
11-07-2013 15:13Ina SchieferdeckerFixed in Version => v4.6.1 (published 2014-06)
11-07-2013 15:13Ina SchieferdeckerResolutionopen => fixed
11-07-2013 15:13Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011548) +
+ Ina Schieferdecker    +
+ 11-07-2013 15:12    +
+ 		+ + + + +
+ Removed the first superfluous parenthesis
+
+ + diff --git a/docs/mantis/CR6580.md b/docs/mantis/CR6580.md new file mode 100644 index 0000000000000000000000000000000000000000..c80a3b7a81797320975ab876c0a0972a8b5cc0a6 --- /dev/null +++ b/docs/mantis/CR6580.md @@ -0,0 +1,148 @@ + + + + + + + + + + + + + 0006580: It must be clarified in the standard whether the first parameter in match() can be a template - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006580Part 01: TTCN-3 Core LanguageTechnicalpublic08-07-2013 11:5529-08-2013 17:12
ReporterAndras Kovacs 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionwon't fix 
PlatformOSOS Version
Product Versionv4.4.1 (published 2012-04) 
Target Versionv4.6.1 (published 2014-06)Fixed in Version 
Clause Reference(s)15.6.2
Source (company - Author)STF451 - Andras Kovacs
Summary0006580: It must be clarified in the standard whether the first parameter in match() can be a template
DescriptionIt is presently unclear whether the first parameter in match() function can be a template.
+
+Reasons to consider that a template is allowed as first parameter:
+- The BNF says, that first argument shall be an expression, which expression can be also a reference (identifier), and since template values are compatible with values, template value should be accepted.
+
+Reasons to consider that a template is not allowed here:
+- The BNF says, that first argument shall be an expression
+- The BNF uses different statements for value reference (ReferencedValue) and template reference (TemplateRefWithParList). That efficiently excludes parameterized template instances in expression.
+
+The proper interpretation should be clarified in the next revision.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0006562closed Ina Schieferdecker Use of template references in expression 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
08-07-2013 11:55Andras KovacsNew Issue
08-07-2013 11:55Andras KovacsClause Reference(s) => 15.6.2
08-07-2013 11:55Andras KovacsSource (company - Author) => STF451 - Andras Kovacs
08-07-2013 14:23Jens GrabowskiStatusnew => assigned
08-07-2013 14:23Jens GrabowskiAssigned To => Gyorgy Rethy
08-07-2013 16:01Gyorgy RethyTarget Version => v4.6.1 (published 2014-06)
11-07-2013 08:46Gyorgy RethyRelationship addedrelated to 0006562
11-07-2013 09:13Gyorgy RethyNote Added: 0011530
11-07-2013 09:18Gyorgy RethyNote Edited: 0011530
11-07-2013 14:26Gyorgy RethyNote Edited: 0011530
11-07-2013 14:26Gyorgy RethyNote Edited: 0011530
11-07-2013 14:26Gyorgy RethyStatusassigned => confirmed
29-08-2013 10:01Gyorgy RethyStatusconfirmed => assigned
29-08-2013 10:01Gyorgy RethyAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
29-08-2013 14:05Jacob Wieland - SpirentNote Added: 0011638
29-08-2013 14:05Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Ina Schieferdecker
29-08-2013 14:05Jacob Wieland - SpirentStatusassigned => confirmed
29-08-2013 17:12Ina SchieferdeckerNote Added: 0011645
29-08-2013 17:12Ina SchieferdeckerStatusconfirmed => closed
29-08-2013 17:12Ina SchieferdeckerResolutionopen => won't fix
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011530) +
+ Gyorgy Rethy    +
+ 11-07-2013 09:13    +
(edited on: 11-07-2013 14:26)
+ 		+ + + + +
+ I think no change is needed. Clause 15.9 Restriction a) declares:
+
+"a) The expression-parameter of the match operation shall not evaluate to a template, i.e. the match operation cannot be used to compare two templates."
+
+It should be sufficient, together with the clarification of what are values and templates, included in CR6562 (i.e. an object defined as template containing a specific value is a template).
+
+Resolution to be ACKed by STF460.
+
+
+
+
+
+ + + + + + + + + + +
+ (0011638) +
+ Jacob Wieland - Spirent    +
+ 29-08-2013 14:05    +
+ 		+ + + + +
+ I concur.
+
+
+
+ + + + + + + + + + +
+ (0011645) +
+ Ina Schieferdecker    +
+ 29-08-2013 17:12    +
+ 		+ + + + +
+ As agreed
+
+ + diff --git a/docs/mantis/CR6581.md b/docs/mantis/CR6581.md new file mode 100644 index 0000000000000000000000000000000000000000..0c542f8b9eeacb8fc2e11bcc59674900f24bde15 --- /dev/null +++ b/docs/mantis/CR6581.md @@ -0,0 +1,244 @@ + + + + + + + + + + + + + 0006581: It must be clarified whether altsteps can accept timer parameters defined in the control part - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006581Part 01: TTCN-3 Core LanguageClarificationpublic08-07-2013 14:2511-10-2013 12:00
ReporterAndras Kovacs 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.6.1 (published 2014-06)Fixed in Versionv4.6.1 (published 2014-06) 
Clause Reference(s)20.5.2: restriction a)
Source (company - Author)STF451 - Andras Kovacs
Summary0006581: It must be clarified whether altsteps can accept timer parameters defined in the control part
DescriptionCan altsteps have timer parameters defined in the control part?
+
+Reasoning for allowing such definition:
+- the BNF allows timers to be defined in the control part, and allows altsteps to be activated from the control part
+- there is no use to have timers in the control part unless they can be used as input parameters for altsteps
+
+Reasoning for not allowing such definition:
+Timers defined in the control part are not component type local timers and as such they violate the restriction a) specified in 20.5.2.
+
+The standard should clarify this issue.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR6581-Res-V1-130709.doc (68,096) 10-07-2013 17:29
http://oldforge.etsi.org/mantis/file_download.php?file_id=2820&type=bug
doc CR6581-Res-V2-130709.doc (68,608) 10-07-2013 17:52
http://oldforge.etsi.org/mantis/file_download.php?file_id=2822&type=bug
doc CR6581-Res-V3-130709.doc (68,608) 11-10-2013 12:00
http://oldforge.etsi.org/mantis/file_download.php?file_id=2925&type=bug
Issue History
Date ModifiedUsernameFieldChange
08-07-2013 14:25Andras KovacsNew Issue
08-07-2013 14:25Andras KovacsClause Reference(s) => 20.5.2: restriction a)
08-07-2013 14:25Andras KovacsSource (company - Author) => STF451 - Andras Kovacs
08-07-2013 14:27Jens GrabowskiStatusnew => assigned
08-07-2013 14:27Jens GrabowskiAssigned To => Jens Grabowski
08-07-2013 14:30Gyorgy RethyProduct VersionEdition 4.4.1 Published 2012-04-01 =>
08-07-2013 14:30Gyorgy RethyTarget Version => v4.6.1 (published 2014-06)
09-07-2013 17:11Jacob Wieland - SpirentNote Added: 0011488
10-07-2013 17:28Jens GrabowskiNote Added: 0011519
10-07-2013 17:29Jens GrabowskiFile Added: CR6581-Res-V1-130709.doc
10-07-2013 17:29Jens GrabowskiNote Added: 0011520
10-07-2013 17:29Jens GrabowskiAssigned ToJens Grabowski => Jacob Wieland - Spirent
10-07-2013 17:52Jacob Wieland - SpirentFile Added: CR6581-Res-V2-130709.doc
10-07-2013 17:54Jacob Wieland - SpirentNote Added: 0011521
10-07-2013 17:54Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent =>
10-07-2013 18:16Jacob Wieland - SpirentAssigned To => Gyorgy Rethy
11-07-2013 16:36Gyorgy RethyStatusassigned => confirmed
29-08-2013 10:10Gyorgy RethyNote Added: 0011633
29-08-2013 10:19Gyorgy RethyAssigned ToGyorgy Rethy => Ina Schieferdecker
29-08-2013 10:19Gyorgy RethyStatusconfirmed => resolved
29-08-2013 10:19Gyorgy RethyResolutionopen => fixed
11-10-2013 12:00Ina SchieferdeckerFile Added: CR6581-Res-V3-130709.doc
11-10-2013 12:00Ina SchieferdeckerStatusresolved => closed
11-10-2013 12:00Ina SchieferdeckerNote Added: 0011768
11-10-2013 12:00Ina SchieferdeckerFixed in Version => v4.6.1 (published 2014-06)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011488) +
+ Jacob Wieland - Spirent    +
+ 09-07-2013 17:11    +
+ 		+ + + + +
+ I think the restriction should be amended (to allow timers). In principle, the control behavior runs on an implicit type-less component which has local timers as any other component.
+
+
+
+ + + + + + + + + + +
+ (0011519) +
+ Jens Grabowski    +
+ 10-07-2013 17:28    +
+ 		+ + + + +
+ Restrictions in 20.5.2 have been changed/extended.
+
+(Note: Invoking altsteps in Clause 16.2.1 also refers to 20.5.2. Therefore, only the restrictions in 20.5.2 need to be changed/extended.)
+
+
+
+ + + + + + + + + + +
+ (0011520) +
+ Jens Grabowski    +
+ 10-07-2013 17:29    +
+ 		+ + + + +
+ Jacob, please crosscheck.
+
+
+
+ + + + + + + + + + +
+ (0011521) +
+ Jacob Wieland - Spirent    +
+ 10-07-2013 17:54    +
+ 		+ + + + +
+ changed it to apply only to the activated altsteps (as we are in the activate operation section) and not in general to altstep invocations (as the restriction there is not necessary because all timers that are known in the moment of invocation are still definitely existent.
+
+
+
+ + + + + + + + + + +
+ (0011633) +
+ Gyorgy Rethy    +
+ 29-08-2013 10:10    +
+ 		+ + + + +
+ Text in CR6581-Res-V2-130709.doc OK with me. Was it assigned to me for crosschecking? Have you (Jacob and Jens) agreed on this text?
+
+
+
+ + + + + + + + + + +
+ (0011768) +
+ Ina Schieferdecker    +
+ 11-10-2013 12:00    +
+ 		+ + + + +
+ only small editorial change
+
+ + diff --git a/docs/mantis/CR6582.md b/docs/mantis/CR6582.md new file mode 100644 index 0000000000000000000000000000000000000000..2cb375ca98582d25465d3c41b537498d48bb9314 --- /dev/null +++ b/docs/mantis/CR6582.md @@ -0,0 +1,131 @@ + + + + + + + + + + + + + 0006582: timer parameters are not excluded for procedure signature declarations - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006582Part 01: TTCN-3 Core LanguageTechnicalpublic10-07-2013 12:4526-08-2013 16:02
ReporterJacob Wieland - Spirent 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.5.1 (published 2013-04)Fixed in Versionv4.5.1 (published 2013-04) 
Clause Reference(s)14
Source (company - Author)     
Summary0006582: timer parameters are not excluded for procedure signature declarations
DescriptionEven though the syntactical structure allows only value parameters to be declared, the restriction misses timers.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR6582.docx (161,332) 10-07-2013 15:37
http://oldforge.etsi.org/mantis/file_download.php?file_id=2813&type=bug
Issue History
Date ModifiedUsernameFieldChange
10-07-2013 12:45Jacob Wieland - SpirentNew Issue
10-07-2013 12:45Jacob Wieland - SpirentClause Reference(s) => 14
10-07-2013 12:45Jacob Wieland - SpirentSource (company - Author) =>
10-07-2013 12:48Jacob Wieland - SpirentAssigned To => Jacob Wieland - Spirent
10-07-2013 12:48Jacob Wieland - SpirentStatusnew => assigned
10-07-2013 15:37Jacob Wieland - SpirentFile Added: CR6582.docx
10-07-2013 15:38Jacob Wieland - SpirentNote Added: 0011509
10-07-2013 18:13Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
10-07-2013 18:13Jacob Wieland - SpirentNote Added: 0011524
11-07-2013 09:08Jacob Wieland - SpirentAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
11-07-2013 10:14Jacob Wieland - SpirentStatusassigned => confirmed
11-07-2013 10:55Jacob Wieland - SpirentStatusconfirmed => assigned
11-07-2013 10:55Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Ina Schieferdecker
11-07-2013 10:55Jacob Wieland - SpirentStatusassigned => confirmed
26-08-2013 16:01Ina SchieferdeckerNote Added: 0011600
26-08-2013 16:01Ina SchieferdeckerProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
26-08-2013 16:02Ina SchieferdeckerStatusconfirmed => resolved
26-08-2013 16:02Ina SchieferdeckerResolutionopen => fixed
26-08-2013 16:02Ina SchieferdeckerFixed in Version => v4.5.1 (published 2013-04)
26-08-2013 16:02Ina SchieferdeckerTarget Version => v4.5.1 (published 2013-04)
26-08-2013 16:02Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011509) +
+ Jacob Wieland - Spirent    +
+ 10-07-2013 15:38    +
+ 		+ + + + +
+ added proposal
+
+
+
+ + + + + + + + + + +
+ (0011524) +
+ Jacob Wieland - Spirent    +
+ 10-07-2013 18:13    +
+ 		+ + + + +
+ please check
+
+
+
+ + + + + + + + + + +
+ (0011600) +
+ Ina Schieferdecker    +
+ 26-08-2013 16:01    +
+ 		+ + + + +
+ as proposed
+
+ + diff --git a/docs/mantis/CR6585.md b/docs/mantis/CR6585.md new file mode 100644 index 0000000000000000000000000000000000000000..9c23d2ec89f7855e76029e232a50d65a082ef24d --- /dev/null +++ b/docs/mantis/CR6585.md @@ -0,0 +1,183 @@ + + + + + + + + + + + + + 0006585: LanguageSpec handling of import statements shall support both implicit & explicit mappings - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006585Part 01: TTCN-3 Core LanguageTechnicalpublic11-07-2013 10:1811-07-2013 16:42
ReporterGyorgy Rethy 
Assigned ToIna Schieferdecker 
PriorityhighSeveritymajorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.6.1 (published 2014-06)Fixed in Versionv4.6.1 (published 2014-06) 
Clause Reference(s)8.2.3.6
Source (company - Author)STF460
Summary0006585: LanguageSpec handling of import statements shall support both implicit & explicit mappings
Descriptionissue was raised by 3GPP, see mail discussion with Shicheng Hu:
+Hi Gyorgy and All
+ 
+Thanks for the explanation. I understand better about the pros and cons.
+ 
+As you all know, the 3GPP conformance test suites are globally used for the UE certification. There are two basic requirements
+ 
+1. The test suites delivered by STF160 should be unique as the standardised test suites.
+2. Copyrights of the test suites belong to ETSI and the other 3GPP organizational partners.
+ 
+Now, because of the two mapping options I have the following problems.
+ 
+1. The 3GPP test suites should be analysed by all existing tools. The import XSD statement in the 3GPP test suites must be slightly adapted for the mapping options, and the imported XSD modules must be replaced with the mapped TTCN modules. Therefore, STF160 is no more in the position to provide a "unique" delivery for the UE certifications. The high risk is what happens if the UE to be certified passes the test with one mapping option, but fails the test in another mapped option?
+ 
+2. The explicit mapping option is relying on the tools and has introduced a Copyrights problem. The generated mapped TTCN modules by the tool (from the original XSD modules) is a piece of software. Its copyrights are owned by the tool makers. ETSI has no copyrights on this piece of TTCN codes. This is against the current copyrights principle for the ETSI standards once a 3GPP delivery includes the mapped TTCN modules generated by the tools. As you know, the copyrights have the commercial implications.
+ 
+3. On the top, there is a big tool interoperability problem with the explicit mapping, supposing the Part 9 is correct. The mapped TTCN modules generated by one tool cannot ne accepted by the others.
+ 
+My preference is to stick the explicit mapping, despite of the technical difficulties. Your comments are welcome.
+ 
+Br
+Shicheng
+________________________________________
+From: György Réthy [mailto:gyorgy.rethy@ericsson.com]
+Sent: 08 July 2013 17:47
+To: Shicheng Hu
+Cc: STF460
+Subject: RE: XSD import
+Hi Shicheng,
+
+It is not so straightforward. Both ways has their pros and cons. XSD differs from the TTCN-3 type system significantly both in philosophy, in concrete language components and ways of restricting and combining those components. So, for example, if importing an ASN.1 type, it is relatively straightforward how the equivalent TTCN-3 type would look like, i.e. how to define the TTCN-3 instances of that type. It is far not so easy for types, attributes and elements imported from XSD.
+
+So, the clear benefit of the explicit mapping is that the user can SEE the generated TTCN-3 definitions that makes writing values and templates more easy. Another benefit is, that – if needed – the user may tweak the generated TTCN-3 types – until the XML codec support the changes. Of course, it also has drawbacks, e.g. the user need to take an additional step to convert XSD to TTCN-3 modules, has to handle additional files in its project and in the version control system and shall not forget to re-generate the TTCN-3 modules if XSD is updated and a more difficult tool implementation.
+
+And, if course, implicit mapping has its pros and cons. Pros are e.g. the simpler handling of projects, less files, no forgotten updates etc. and the list of cons are the missing features that were the benefits for the explicit mapping – so, more or less pros and cons are the opposite as with the explicit mapping.
+
+So, I think, there is no ideal solution, just different ones with different properties.
+
+Regards, Gyorgy
+
+From: Shicheng Hu [mailto:Shicheng.Hu@ETSI.ORG]
+Sent: 2013. július 5. 16:55
+To: STF460@LIST.ETSI.ORG
+Subject: XSD import
+
+Hi Gyorgy and All
+ 
+I have an issue on XSD import in Part 9. Why does the standard allow the implicit and explicitly import XSD modules as two options? An implicit mapping makes much more sense.
+ 
+Br
+Shicheng
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR6585.doc (162,816) 11-07-2013 13:38
http://oldforge.etsi.org/mantis/file_download.php?file_id=2829&type=bug
doc CR6585_v2.doc (166,912) 11-07-2013 14:52
http://oldforge.etsi.org/mantis/file_download.php?file_id=2830&type=bug
doc CR6585_v3.doc (167,936) 11-07-2013 15:37
http://oldforge.etsi.org/mantis/file_download.php?file_id=2832&type=bug
Issue History
Date ModifiedUsernameFieldChange
11-07-2013 10:18Gyorgy RethyNew Issue
11-07-2013 10:18Gyorgy RethyClause Reference(s) => 8.2.3.6
11-07-2013 10:18Gyorgy RethySource (company - Author) => STF460
11-07-2013 10:20Gyorgy RethyStatusnew => assigned
11-07-2013 10:20Gyorgy RethyAssigned To => Jacob Wieland - Spirent
11-07-2013 11:15Gyorgy RethyNote Added: 0011535
11-07-2013 11:16Gyorgy RethyProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
11-07-2013 11:17Gyorgy RethyTarget Version => v4.6.1 (published 2014-06)
11-07-2013 13:38Jacob Wieland - SpirentFile Added: CR6585.doc
11-07-2013 13:39Jacob Wieland - SpirentNote Added: 0011545
11-07-2013 13:39Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Ina Schieferdecker
11-07-2013 13:39Jacob Wieland - SpirentStatusassigned => confirmed
11-07-2013 14:52Ina SchieferdeckerFile Added: CR6585_v2.doc
11-07-2013 14:52Ina SchieferdeckerStatusconfirmed => assigned
11-07-2013 14:52Ina SchieferdeckerAssigned ToIna Schieferdecker => Gyorgy Rethy
11-07-2013 14:52Ina SchieferdeckerAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
11-07-2013 15:37Jacob Wieland - SpirentFile Added: CR6585_v3.doc
11-07-2013 15:38Jacob Wieland - SpirentNote Added: 0011551
11-07-2013 15:38Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Ina Schieferdecker
11-07-2013 15:38Jacob Wieland - SpirentStatusassigned => confirmed
11-07-2013 16:42Ina SchieferdeckerStatusconfirmed => resolved
11-07-2013 16:42Ina SchieferdeckerFixed in Version => v4.6.1 (published 2014-06)
11-07-2013 16:42Ina SchieferdeckerResolutionopen => fixed
11-07-2013 16:42Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011535) +
+ Gyorgy Rethy    +
+ 11-07-2013 11:15    +
+ 		+ + + + +
+ STF discussion 2013-07-11:
+When the import statement contains a LanguageSpec string, this does not mandate importing from the original source files only, but means importing from the original (e.g. XSD) source file OR from an explicitly mapped TTCN-3 source file. This means that tools supporting explicit mapping, if the language string is present, shall accept only TTCN-3 modules complying with the mapping specification.
+
+
+
+ + + + + + + + + + +
+ (0011545) +
+ Jacob Wieland - Spirent    +
+ 11-07-2013 13:39    +
+ 		+ + + + +
+ please check
+
+
+
+ + + + + + + + + + +
+ (0011551) +
+ Jacob Wieland - Spirent    +
+ 11-07-2013 15:38    +
+ 		+ + + + +
+ please check again
+
+ + diff --git a/docs/mantis/CR6586.md b/docs/mantis/CR6586.md new file mode 100644 index 0000000000000000000000000000000000000000..d67f8959b9d4dca0bfe5951bead909a3e3f248df --- /dev/null +++ b/docs/mantis/CR6586.md @@ -0,0 +1,317 @@ + + + + + + + + + + + + + 0006586: How to encode to/decode from XML values containing non-ASCII characters? - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006586Part 01: TTCN-3 Core LanguageTechnicalpublic11-07-2013 10:5709-04-2014 14:11
ReporterGyorgy Rethy 
Assigned ToIna Schieferdecker 
PriorityhighSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.6.1 (published 2014-06)Fixed in Versionv4.6.1 (published 2014-06) 
Clause Reference(s)16,1.2, Annex C
Source (company - Author)STF460
Summary0006586: How to encode to/decode from XML values containing non-ASCII characters?
DescriptionIssue is raised by 3GPP TF160, see mail from Wolfgang Seka:
+
+Hi György, Ina, Jens, Tomas,
+
+I've still have another issue regarding XSD on my list:
+
+Firstly just for clarification - I guess the common way to encode an XSD type (lets call it MyXSD_Type) is
+var template (value) MyXSD_Type v_XML_Message := cs_XML_Template;
+var charstring v_EncodedXML := oct2char(bit2oct(encvalue(v_XML_Message)));
+and in the other direction
+var MyXSD_Type v_XML_Message;
+var bitstring v_Bitstring := oct2bit(char2oct(v_EncodedXML));
+decvalue(v_Bitstring, v_XML_Message);
+Even though we can encapsulate that, from a user's point of view it is a bit "bulky" so I wonder whether it would be werth to introduce special encoding/decoding functions for this purpose
+(not that urgent but at least nice-to-have).
+
+But there is another issue related to this: In the XSD files which we are using there are often extensions so that there is an "any" place-holder in the base definitions which gets populated which specific types by an extension.
+Typically the place-holder is converted to an "XSD.String" field in the TTCN. Now it seems that different tools have different definitions for XSD.String: as long as it results in charstring there is no problem and the extension can be encoded/decoded by using encvalue/decvalue as shown above. But it seems that XSD.String is not always "charstring" but may also be defined as something like "universal charstring" what causes a problem with char2oct in the above.
+(that would be another reason to introduce specific functions to encode/decode XSD types as these functions may use XSD.String as abstract type)
+
+So - what is the generic solution ??
+
+Best regards
+Wolfgang
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0006706closed Gyorgy Rethy Encoding in oct2unichar, unichar2oct, encvalue_unichar, decvalue_unichar 
Attached Filesdoc CR6586.doc (226,304) 11-07-2013 19:13
http://oldforge.etsi.org/mantis/file_download.php?file_id=2842&type=bug
doc CR6586-v2.doc (235,008) 27-08-2013 17:26
http://oldforge.etsi.org/mantis/file_download.php?file_id=2863&type=bug
Issue History
Date ModifiedUsernameFieldChange
11-07-2013 10:57Gyorgy RethyNew Issue
11-07-2013 10:57Gyorgy RethyClause Reference(s) => 16,1.2, Annex C
11-07-2013 10:57Gyorgy RethySource (company - Author) => STF460
11-07-2013 10:59Jacob Wieland - SpirentStatusnew => assigned
11-07-2013 10:59Jacob Wieland - SpirentAssigned To => Jacob Wieland - Spirent
11-07-2013 11:17Gyorgy RethyPrioritynormal => high
11-07-2013 11:17Gyorgy RethyTarget Version => v4.6.1 (published 2014-06)
11-07-2013 11:34Jacob Wieland - SpirentNote Added: 0011536
11-07-2013 11:38Gyorgy RethyNote Added: 0011537
11-07-2013 11:38Jacob Wieland - SpirentNote Added: 0011538
11-07-2013 19:13Jacob Wieland - SpirentFile Added: CR6586.doc
11-07-2013 19:14Jacob Wieland - SpirentNote Added: 0011561
11-07-2013 19:14Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Ina Schieferdecker
11-07-2013 19:14Jacob Wieland - SpirentStatusassigned => confirmed
26-08-2013 15:49Ina SchieferdeckerFile Added: CR6586-v2.doc
26-08-2013 15:49Ina SchieferdeckerNote Added: 0011599
26-08-2013 15:50Ina SchieferdeckerStatusconfirmed => assigned
26-08-2013 15:50Ina SchieferdeckerAssigned ToIna Schieferdecker => Jacob Wieland - Spirent
26-08-2013 16:42Jacob Wieland - SpirentNote Added: 0011603
27-08-2013 15:30Ina SchieferdeckerFile Deleted: CR6586-v2.doc
27-08-2013 15:31Ina SchieferdeckerFile Added: CR6586-v2.doc
27-08-2013 17:23Ina SchieferdeckerFile Deleted: CR6586-v2.doc
27-08-2013 17:23Ina SchieferdeckerFile Added: CR6586-v2.doc
27-08-2013 17:25Ina SchieferdeckerFile Deleted: CR6586-v2.doc
27-08-2013 17:26Ina SchieferdeckerFile Added: CR6586-v2.doc
27-08-2013 17:30Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Ina Schieferdecker
27-08-2013 17:30Jacob Wieland - SpirentStatusassigned => confirmed
27-08-2013 18:46Ina SchieferdeckerNote Added: 0011614
27-08-2013 18:46Ina SchieferdeckerStatusconfirmed => resolved
27-08-2013 18:46Ina SchieferdeckerResolutionopen => fixed
27-08-2013 18:46Ina SchieferdeckerFixed in Version => v4.6.1 (published 2014-06)
27-08-2013 18:47Ina SchieferdeckerStatusresolved => closed
09-04-2014 14:11Gyorgy RethyRelationship addedrelated to 0006706
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011536) +
+ Jacob Wieland - Spirent    +
+ 11-07-2013 11:34    +
+ 		+ + + + +
+ STF-discussion: we propose to add two new predefined functions
+
+decvalueuchar(in universal charstring encoded_value,
+              inout any_data_type decoded_value,
+              in charstring string_encoding) return integer
+
+encvalueuchar(in any_data_type val, in charstring string_encoding) return universal charstring
+
+Maybe the names could be chosen as less of a mouthfull: encuchar, decuchar maybe or value2uchar and uchar2value
+
+For completeness sake, we probably should also add two other conversion functions.
+
+uchar2oct(in universal charstring str, in charstring string_encoding) return octetstring
+
+oct2uchar(in octetstring str, in charstring string_encoding) return universal charstring
+
+For the string_encoding parameters, a list of predefined allowed/standardized values and their respective meanings shall be added. Tool providers could be free to add additional, non-standardized allowed values that their tool supports (which could then be standardized later).
+
+If these functions exists, we have to equivalences:
+
+decvalueuchar(cstr, val, enc) =^= decvalue(oct2bit(uchar2oct(cstr, enc), val)
+
+encvalueuchar(val, enc) =^= oct2uchar(bit2oct(encvalue(val)), enc)
+
+
+
+ + + + + + + + + + +
+ (0011537) +
+ Gyorgy Rethy    +
+ 11-07-2013 11:38    +
+ 		+ + + + +
+ STF discussion 2013-07-11:
+Add new encvalueuchar and decvalueuchar predefined functions. encvalueuchar will encode TTCN-3 values into a universal charstring, as if oct2uchar(bit2oct(encvalue(v_XML_Message)),UTF8) was used (just TTCN-3 don’t have oct2uchar today) and decvalueuchar will do the opposite. So, one can convert between TTCN-3 representations of XML values and an XML value in one step.
+
+The type of encoding shall be defined by an additional argument, which will be a predefined enumeration; currently we are considering UTF8, UCS-2 (used by SMS) and UCS-4.
+
+
+
+ + + + + + + + + + +
+ (0011538) +
+ Jacob Wieland - Spirent    +
+ 11-07-2013 11:38    +
+ 		+ + + + +
+ Also, the string_encoding parameter could be made optional, i.e. given a default value, probably "utf-8".
+
+
+
+ + + + + + + + + + +
+ (0011561) +
+ Jacob Wieland - Spirent    +
+ 11-07-2013 19:14    +
+ 		+ + + + +
+ added oct2unichar, unichar2oct, decvalue_unichar, encvalue_unichar.
+References to character encoding standards are missing.
+
+
+
+ + + + + + + + + + +
+ (0011599) +
+ Ina Schieferdecker    +
+ 26-08-2013 15:49    +
+ 		+ + + + +
+ Please check the small changes
+
+
+
+ + + + + + + + + + +
+ (0011603) +
+ Jacob Wieland - Spirent    +
+ 26-08-2013 16:42    +
+ 		+ + + + +
+ No problem with me if the standard-references are not necessary. The encoded unicode (UCS-4) values were generated by use of wikipedia.
+
+
+
+ + + + + + + + + + +
+ (0011614) +
+ Ina Schieferdecker    +
+ 27-08-2013 18:46    +
+ 		+ + + + +
+ As proposed
+
+ + diff --git a/docs/mantis/CR6588.md b/docs/mantis/CR6588.md new file mode 100644 index 0000000000000000000000000000000000000000..45754d166ad7d5faefc50d8c87b43bfd51f49887 --- /dev/null +++ b/docs/mantis/CR6588.md @@ -0,0 +1,139 @@ + + + + + + + + + + + + + 0006588: Text string compatibility rules are ambiguous - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006588Part 01: TTCN-3 Core LanguageClarificationpublic11-07-2013 18:0227-08-2013 17:07
ReporterGyorgy Rethy 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.5.1 (published 2013-04) 
Target Versionv4.6.1 (published 2014-06)Fixed in Versionv4.6.1 (published 2014-06) 
Clause Reference(s)6.3.1
Source (company - Author)L.M.Ericsson
Summary0006588: Text string compatibility rules are ambiguous
DescriptionThe first paragraph of 6.3.1 says: "For variables, constants, templates, etc. of simple basic types and basic string types the value "b" is compatible to type "A" if type "B" resolves to the same root type as type "A" (e.g. integer) and it does not violate subtyping (e.g. ranges, length restrictions) of type "A"."
+
+Then, the last two paragraphs define compatibility rules between charstrings and universal charstrings, and allows implicit casting, i.e. the root types need not be the same.
+
+Obviously, the first paragraph is meant for binary strings only, not for all string types.
Steps To Reproduce
Additional InformationSee proposed solution in the attached file.
TagsNo tags attached.
Relationships
Attached Filesdoc Char-Uchar_compatibility_resolution_v1.doc (68,096) 11-07-2013 18:02
http://oldforge.etsi.org/mantis/file_download.php?file_id=2841&type=bug
doc Char-Uchar_compatibility_resolution_v2.doc (69,632) 27-08-2013 17:00
http://oldforge.etsi.org/mantis/file_download.php?file_id=2861&type=bug
Issue History
Date ModifiedUsernameFieldChange
11-07-2013 18:02Gyorgy RethyNew Issue
11-07-2013 18:02Gyorgy RethyFile Added: Char-Uchar_compatibility_resolution_v1.doc
11-07-2013 18:02Gyorgy RethyClause Reference(s) => 6.3.1
11-07-2013 18:02Gyorgy RethySource (company - Author) => L.M.Ericsson
11-07-2013 18:04Gyorgy RethyAssigned To => Ina Schieferdecker
11-07-2013 18:04Gyorgy RethyStatusnew => assigned
11-07-2013 18:04Gyorgy RethyTarget Version => v4.6.1 (published 2014-06)
11-07-2013 18:05Gyorgy RethyDescription Updated
12-07-2013 09:06Jacob Wieland - SpirentNote Added: 0011567
27-08-2013 17:00Ina SchieferdeckerFile Added: Char-Uchar_compatibility_resolution_v2.doc
27-08-2013 17:01Ina SchieferdeckerNote Added: 0011610
27-08-2013 17:06Ina SchieferdeckerNote Added: 0011611
27-08-2013 17:06Ina SchieferdeckerStatusassigned => resolved
27-08-2013 17:06Ina SchieferdeckerResolutionopen => fixed
27-08-2013 17:06Ina SchieferdeckerFixed in Version => v4.6.1 (published 2014-06)
27-08-2013 17:07Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011567) +
+ Jacob Wieland - Spirent    +
+ 12-07-2013 09:06    +
+ 		+ + + + +
+ I think it is not inconsistent.
+
+The general sentence states one condition when types are compatible. The additonal sentence weakens this condition for the special case.
+
+If the general sentence would contain an "only" or "if and only if" instead of simply "if", then it would really be inconsistent.
+
+
+
+ + + + + + + + + + +
+ (0011610) +
+ Ina Schieferdecker    +
+ 27-08-2013 17:01    +
+ 		+ + + + +
+ STF discussion: revert to original text and make the additional rules for charstring and universal charstring more explicit - see v2
+
+
+
+ + + + + + + + + + +
+ (0011611) +
+ Ina Schieferdecker    +
+ 27-08-2013 17:06    +
+ 		+ + + + +
+ As discussed.
+
+ + diff --git a/docs/mantis/CR6600.md b/docs/mantis/CR6600.md new file mode 100644 index 0000000000000000000000000000000000000000..c42f4c8874850850d2a355eb2f61990b30cc63b0 --- /dev/null +++ b/docs/mantis/CR6600.md @@ -0,0 +1,178 @@ + + + + + + + + + + + + + 0006600: Missing data in TLI check operations - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006600Part 06: TTCN-3 Control InterfaceTechnicalpublic15-08-2013 09:3430-08-2013 12:42
ReporterTomas Urban 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.5.1 (published 2013-04) 
Target Versionv4.6.1 (published 2014-06)Fixed in Versionv4.6.1 (published 2014-06) 
Clause Reference(s)7.3.4
Source (company - Author)Elvior
Summary0006600: Missing data in TLI check operations
DescriptionCR 5981 introduced operations for logging the check operation. However, parameters of these operations don't contain decoded values (in case of traffic received from the SA) and templates used for matching, which are quite valueable for logging.
+
+Operations for logging the check call performed on mapped ports also contain encoded data and addresses, but that information seems to be redundant, because it is always available to the TLI via preceding tli*Detected calls.
+
+Proposal:
+Change the interface of the TLI checking operations to resemble tliMReceive, tliPrGetCall, tliPrGetReply and tliPrCatch calls (instead of using syntax of tli*Detected calls).
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0005981closed Ina Schieferdecker TLI does currently not represent the p.check operation appropriately 
Attached Filesrar CR6600.rar (1,015,417) 29-08-2013 17:53
http://oldforge.etsi.org/mantis/file_download.php?file_id=2877&type=bug
Issue History
Date ModifiedUsernameFieldChange
15-08-2013 09:34Tomas UrbanNew Issue
15-08-2013 09:34Tomas UrbanClause Reference(s) => 7.3.4
15-08-2013 09:34Tomas UrbanSource (company - Author) => Elvior
26-08-2013 13:29Jacob Wieland - SpirentNote Added: 0011594
26-08-2013 13:30Jacob Wieland - SpirentRelationship addedrelated to 0005981
26-08-2013 13:30Jacob Wieland - SpirentStatusnew => assigned
26-08-2013 13:30Jacob Wieland - SpirentAssigned To => Jacob Wieland - Spirent
28-08-2013 15:08Jacob Wieland - SpirentNote Added: 0011627
29-08-2013 17:53Jacob Wieland - SpirentFile Added: CR6600.rar
29-08-2013 17:55Jacob Wieland - SpirentNote Added: 0011648
29-08-2013 17:55Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Ina Schieferdecker
29-08-2013 17:55Jacob Wieland - SpirentStatusassigned => confirmed
29-08-2013 17:56Jacob Wieland - SpirentNote Edited: 0011648
29-08-2013 17:57Jacob Wieland - SpirentNote Edited: 0011648
30-08-2013 12:42Ina SchieferdeckerNote Added: 0011656
30-08-2013 12:42Ina SchieferdeckerStatusconfirmed => resolved
30-08-2013 12:42Ina SchieferdeckerResolutionopen => fixed
30-08-2013 12:42Ina SchieferdeckerFixed in Version => v4.6.1 (published 2014-06)
30-08-2013 12:42Ina SchieferdeckerTarget Version => v4.6.1 (published 2014-06)
30-08-2013 12:42Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011594) +
+ Jacob Wieland - Spirent    +
+ 26-08-2013 13:29    +
+ 		+ + + + +
+ I agree with the reporter. The problem here is backward (in-)compatibility.
+
+Fortunately, this is a relatively new feature, so maybe not all tools have implemented this up till now.
+
+I think we should ask the tool vendors about this.
+
+
+
+ + + + + + + + + + +
+ (0011627) +
+ Jacob Wieland - Spirent    +
+ 28-08-2013 15:08    +
+ 		+ + + + +
+ reviewing this, the same problem exists also with _c variants of these tli-events, they also should be modelled after their respective Receive_c events.
+
+
+
+ + + + + + + + + + +
+ (0011648) +
+ Jacob Wieland - Spirent    +
+ 29-08-2013 17:55    +
(edited on: 29-08-2013 17:57)
+ 		+ + + + +
+ changed all events of the checked operation to have the same parameters as their respective receive events in all language mappings
+
+also fixed some typos (at least one tliMReceive was tliMRecieve and in some tables, the parameter names differed in capitalization from the signature)
+
+
+
+
+
+ + + + + + + + + + +
+ (0011656) +
+ Ina Schieferdecker    +
+ 30-08-2013 12:42    +
+ 		+ + + + +
+ As proposed.
+
+ + diff --git a/docs/mantis/CR6601.md b/docs/mantis/CR6601.md new file mode 100644 index 0000000000000000000000000000000000000000..007a957cbab11156b9d4c4cb21eaba9adc2787e8 --- /dev/null +++ b/docs/mantis/CR6601.md @@ -0,0 +1,175 @@ + + + + + + + + + + + + + 0006601: C++ mapping of the address in mismatch calls - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006601Part 06: TTCN-3 Control InterfaceTechnicalpublic15-08-2013 09:4930-08-2013 13:16
ReporterTomas Urban 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.5.1 (published 2013-04) 
Target Versionv4.6.1 (published 2014-06)Fixed in Versionv4.6.1 (published 2014-06) 
Clause Reference(s)10.6.4.1
Source (company - Author)Elvior
Summary0006601: C++ mapping of the address in mismatch calls
DescriptionThe C++ mapping of the mismatch calls (tliMMismatch_m, tliPrGetCallMismatch_m, tliPrGetReplyMismatch_m, tliPrCatchMismatch_m, tliCheckAnyMismatch_m) uses TriAddress as a class of the address parameter. However, according to the abstract interface specification defined in the chapter 7.3.4.1, it should be the C++ mapping of the Value type, i.e. the TciValue class (defined in 10.5.3.2)
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
15-08-2013 09:49Tomas UrbanNew Issue
15-08-2013 09:49Tomas UrbanClause Reference(s) => 10.6.4.1
15-08-2013 09:49Tomas UrbanSource (company - Author) => Elvior
15-08-2013 10:20Tomas UrbanNote Added: 0011589
26-08-2013 13:11Jacob Wieland - SpirentNote Added: 0011592
26-08-2013 14:20Jacob Wieland - SpirentStatusnew => assigned
26-08-2013 14:20Jacob Wieland - SpirentAssigned To => Jacob Wieland - Spirent
26-08-2013 14:57Jacob Wieland - SpirentNote Added: 0011598
26-08-2013 14:57Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Ina Schieferdecker
26-08-2013 14:57Jacob Wieland - SpirentStatusassigned => confirmed
30-08-2013 12:56Ina SchieferdeckerNote Added: 0011658
30-08-2013 13:15Ina SchieferdeckerStatusconfirmed => resolved
30-08-2013 13:15Ina SchieferdeckerResolutionopen => fixed
30-08-2013 13:15Ina SchieferdeckerFixed in Version => v4.6.1 (published 2014-06)
30-08-2013 13:15Ina SchieferdeckerTarget Version => v4.6.1 (published 2014-06)
30-08-2013 13:16Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011589) +
+ Tomas Urban    +
+ 15-08-2013 10:20    +
+ 		+ + + + +
+ The same problem affects receiving calls too: tliMRecieve_m, tliPrGetCall_m, tliPrGetReply_m and tliPrCatch_m.
+
+
+
+ + + + + + + + + + +
+ (0011592) +
+ Jacob Wieland - Spirent    +
+ 26-08-2013 13:11    +
+ 		+ + + + +
+ Reporter is correct,
+
+TriAddress *address
+
+needs to be replaced by
+
+Value addrValue
+
+in the C++ mapping of the methods:
+
+tliMMismatch_m, tliPrGetCallMismatch_m, tliPrGetReplyMismatch_m, tliPrCatchMismatch_m, tliCheckAnyMismatch_m, tliMRecieve_m, tliPrGetCall_m, tliPrGetReply_m and tliPrCatch_m
+
+
+
+ + + + + + + + + + +
+ (0011598) +
+ Jacob Wieland - Spirent    +
+ 26-08-2013 14:57    +
+ 		+ + + + +
+ Since those are just editorial changes, I reassign this.
+
+
+
+ + + + + + + + + + +
+ (0011658) +
+ Ina Schieferdecker    +
+ 30-08-2013 12:56    +
+ 		+ + + + +
+ Changed to "const Value *addrValue" in these operations.
+
+ + diff --git a/docs/mantis/CR6605.md b/docs/mantis/CR6605.md new file mode 100644 index 0000000000000000000000000000000000000000..3302aba9970ad1b4a9bd85687f4748b57437b7e1 --- /dev/null +++ b/docs/mantis/CR6605.md @@ -0,0 +1,67 @@ + + + + + + + + + + + + + 0006605: Java and C++ mapping of tliTcExecute - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006605Part 06: TTCN-3 Control InterfaceTechnicalpublic28-08-2013 08:2630-08-2013 12:51
ReporterTomas Urban 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.5.1 (published 2013-04) 
Target Versionv4.6.1 (published 2014-06)Fixed in Versionv4.6.1 (published 2014-06) 
Clause Reference(s)8.5.4.1, 10.6.4.1
Source (company - Author)Elvior
Summary0006605: Java and C++ mapping of tliTcExecute
DescriptionThe java and C++ mapping of the tliTcExecute function is incorrect. The class of the 7th parameter shall be TciParameterList and not TriParameterList as it is in case of all other mappings and the abstract definition specified in 7.3.4.1.1.
+
+For an unknown reason, the parameter name specified in 7.3.4.1.1 is triPars, which is somehow confusing and shall be changed to tciPars.
+
+Note: It might be that the problem is in the abstract definition and C, C# and XML mapping. However that doesn't seem very likely, because the TE would need to encode the parameters just for logging purposes and all other similar TCI-TL and TCI-TM calls use the TciParameterList class.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
28-08-2013 08:26Tomas UrbanNew Issue
28-08-2013 08:26Tomas UrbanClause Reference(s) => 8.5.4.1, 10.6.4.1
28-08-2013 08:26Tomas UrbanSource (company - Author) => Elvior
28-08-2013 09:45Ina SchieferdeckerStatusnew => assigned
28-08-2013 09:45Ina SchieferdeckerAssigned To => Ina Schieferdecker
30-08-2013 12:50Ina SchieferdeckerNote Added: 0011657
30-08-2013 12:51Ina SchieferdeckerStatusassigned => confirmed
30-08-2013 12:51Ina SchieferdeckerResolutionopen => fixed
30-08-2013 12:51Ina SchieferdeckerFixed in Version => v4.6.1 (published 2014-06)
30-08-2013 12:51Ina SchieferdeckerTarget Version => v4.6.1 (published 2014-06)
30-08-2013 12:51Ina SchieferdeckerStatusconfirmed => closed
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011657) +
+ Ina Schieferdecker    +
+ 30-08-2013 12:50    +
+ 		+ + + + +
+ Ads proposed: corrected in abstract definition in 7.3.4.1.1 to tciPars, in Java mapping in 8.5.4.1 to TciParameterList tciPars, and in C++ mapping to const TciParameterList *tciPars
+
+ + diff --git a/docs/mantis/CR6606.md b/docs/mantis/CR6606.md new file mode 100644 index 0000000000000000000000000000000000000000..db689cabdcf0435ae80cc7e4df4614624d3a2973 --- /dev/null +++ b/docs/mantis/CR6606.md @@ -0,0 +1,175 @@ + + + + + + + + + + + + + 0006606: Allow usage of deterministic external functions in snapshot evaluation - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006606Part 01: TTCN-3 Core LanguageNew Featurepublic29-08-2013 17:0227-11-2013 12:42
ReporterJacob Wieland - Spirent 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.6.1 (published 2014-06)Fixed in Versionv4.6.1 (published 2014-06) 
Clause Reference(s)16.4.1
Source (company - Author)Testing Technologies - Jacob Wieland
Summary0006606: Allow usage of deterministic external functions in snapshot evaluation
DescriptionAt the moment, all external function calls are disallowed during snapshot/alternative evaluation.
+
+This is to ensure determinism of the alt-statement.
+
+However, there are lots of functions, namely deterministic functions like conversion functions or data retrieval functions which some or other reason are not reasonable to implement in TTCN-3, which would not cause a problem for this determinism.
+
+Therefore, I propose to lessen the restriction e) in section 16.4.1. to allow deterministic external functions, i.e. external functions which a) always produce the same output for the same input and b) also adhere to the same restrictions as non-external functions at the same place would have to follow.
Steps To Reproduce
Additional InformationUsing the modifier construction, external functions could be declared as being 'deterministic', as a hint for both the implementer of the external function as well as the tool which could opt for either optimizing such function calls with memoization or check them for determinism with the same technique (at least at development time) and produce runtime errors if non-determinism is detected.
+
+Then, tools can choose to warn at compile time about usages of external functions which are not marked as deterministic when used in the special places (or dependent on user preference, disallow such uses altogether which would still be backward compatible).
+
+Of course, normal functions should also be able to be tagged/modified as deterministic so that a tool can be forced to check the adherence to these restrictions for that function.
TagsNo tags attached.
Relationships
related to 0006318closed Ina Schieferdecker Assignment of global templates and module parameters 
Attached Filesdoc CR6606.doc (236,544) 09-10-2013 10:38
http://oldforge.etsi.org/mantis/file_download.php?file_id=2906&type=bug
doc CR6606_v2.doc (239,104) 26-11-2013 17:33
http://oldforge.etsi.org/mantis/file_download.php?file_id=2942&type=bug
doc CR6606_v3.doc (239,616) 26-11-2013 17:49
http://oldforge.etsi.org/mantis/file_download.php?file_id=2944&type=bug
doc CR6606_v4.doc (240,640) 27-11-2013 12:41
http://oldforge.etsi.org/mantis/file_download.php?file_id=2946&type=bug
Issue History
Date ModifiedUsernameFieldChange
29-08-2013 17:02Jacob Wieland - SpirentNew Issue
29-08-2013 17:02Jacob Wieland - SpirentClause Reference(s) => 16.4.1
29-08-2013 17:02Jacob Wieland - SpirentSource (company - Author) => Testing Technologies - Jacob Wieland
30-08-2013 16:26Jacob Wieland - SpirentStatusnew => assigned
30-08-2013 16:26Jacob Wieland - SpirentAssigned To => Jacob Wieland - Spirent
09-10-2013 10:38Jacob Wieland - SpirentFile Added: CR6606.doc
09-10-2013 10:39Jacob Wieland - SpirentNote Added: 0011722
09-10-2013 10:39Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Ina Schieferdecker
09-10-2013 10:39Jacob Wieland - SpirentStatusassigned => confirmed
09-10-2013 10:53Jacob Wieland - SpirentRelationship addedrelated to 0006318
10-10-2013 19:23Ina SchieferdeckerProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
26-11-2013 17:33Ina SchieferdeckerNote Added: 0011840
26-11-2013 17:33Ina SchieferdeckerFile Added: CR6606_v2.doc
26-11-2013 17:33Ina SchieferdeckerStatusconfirmed => assigned
26-11-2013 17:33Ina SchieferdeckerAssigned ToIna Schieferdecker => Jacob Wieland - Spirent
26-11-2013 17:49Jacob Wieland - SpirentFile Added: CR6606_v3.doc
26-11-2013 17:50Jacob Wieland - SpirentNote Added: 0011842
26-11-2013 17:50Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
26-11-2013 17:50Jacob Wieland - SpirentStatusassigned => confirmed
27-11-2013 12:41Ina SchieferdeckerFile Added: CR6606_v4.doc
27-11-2013 12:42Ina SchieferdeckerNote Added: 0011845
27-11-2013 12:42Ina SchieferdeckerStatusconfirmed => resolved
27-11-2013 12:42Ina SchieferdeckerResolutionopen => fixed
27-11-2013 12:42Ina SchieferdeckerFixed in Version => v4.6.1 (published 2014-06)
27-11-2013 12:42Ina SchieferdeckerTarget Version => v4.6.1 (published 2014-06)
27-11-2013 12:42Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011722) +
+ Jacob Wieland - Spirent    +
+ 09-10-2013 10:39    +
+ 		+ + + + +
+ please review
+
+
+
+ + + + + + + + + + +
+ (0011840) +
+ Ina Schieferdecker    +
+ 26-11-2013 17:33    +
+ 		+ + + + +
+ small additions - please check
+
+
+
+ + + + + + + + + + +
+ (0011842) +
+ Jacob Wieland - Spirent    +
+ 26-11-2013 17:50    +
+ 		+ + + + +
+ changed BNF nonterminal to DeterministicModifier, also introduced that nomenclature in the main text.
+
+
+
+ + + + + + + + + + +
+ (0011845) +
+ Ina Schieferdecker    +
+ 27-11-2013 12:42    +
+ 		+ + + + +
+ as proposed with some editorial changes in v4
+
+ + diff --git a/docs/mantis/CR6609.md b/docs/mantis/CR6609.md new file mode 100644 index 0000000000000000000000000000000000000000..d84264d977ee8cd58e8f76a559b1e37799ae9d85 --- /dev/null +++ b/docs/mantis/CR6609.md @@ -0,0 +1,35 @@ + + + + + + + + + + + + + 0006609: Continuous signalling: discrepancy in port type definition - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Continuous signal support (ES 202 786)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006609Ext Pack: Continuous signal support (ES 202 786)Editorialpublic04-09-2013 08:5826-12-2013 13:00
ReporterTomas Urban 
Assigned ToJens Grabowski 
PrioritynormalSeveritytrivialReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv1.2.1 (published 2014-06)Fixed in Version 
Summary0006609: Continuous signalling: discrepancy in port type definition
DescriptionThe syntactical structure of the stream port type definition specified in 5.2.2.1 contains three direction options (in, out, inout) while the BNF rule 0000011 contains only two options (in, out).
+
+Proposal:
+The inout option shall be added to the BNF.
+
+P.S.
+I am sorry for reporting this issue under general CRs, but the form for reporting continuous signalling issues doesn't work (the mandatory category field cannot be set, because the combo box doesn't contain any values). It would be great if anyone can fix it.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR6609-Res-V1-131008.doc (113,152) 08-10-2013 16:16
http://oldforge.etsi.org/mantis/file_download.php?file_id=2896&type=bug
Issue History
Date ModifiedUsernameFieldChange
04-09-2013 08:58Tomas UrbanNew Issue
04-09-2013 08:58Tomas UrbanClause Reference(s) => 5.2.2.1
04-09-2013 08:58Tomas UrbanSource (company - Author) => Elvior
07-10-2013 12:31Gyorgy RethyProjectTTCN-3 Change Requests => Ext Pack: Continuous signal support (ES 202 786)
07-10-2013 12:32Gyorgy RethyAssigned To => Jens Grabowski
07-10-2013 12:32Gyorgy RethyStatusnew => assigned
07-10-2013 12:32Gyorgy RethyTarget Version => v1.2.1 (published 2014-06)
08-10-2013 16:16Jens GrabowskiFile Added: CR6609-Res-V1-131008.doc
08-10-2013 16:17Jens GrabowskiStatusassigned => resolved
08-10-2013 16:17Jens GrabowskiResolutionopen => fixed
26-12-2013 13:00Jens GrabowskiStatusresolved => closed
+
+ + + + +
+ There are no notes attached to this issue.
+ + diff --git a/docs/mantis/CR6610.md b/docs/mantis/CR6610.md new file mode 100644 index 0000000000000000000000000000000000000000..21b4d18a9ca78c64a4afee1eee3515027ae33cb1 --- /dev/null +++ b/docs/mantis/CR6610.md @@ -0,0 +1,288 @@ + + + + + + + + + + + + + 0006610: Continuous signalling: restrictions on mapping of stream ports - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Continuous signal support (ES 202 786)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006610Ext Pack: Continuous signal support (ES 202 786)Technicalpublic04-09-2013 11:0420-06-2014 10:20
ReporterTomas Urban 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv1.1.1 (published 2012-04) 
Target Versionv1.3.1 (published 2015-06)Fixed in Version 
Summary0006610: Continuous signalling: restrictions on mapping of stream ports
DescriptionThere are no specific rules on connecting and mapping stream ports. It means that the core language specification rules shall be used in these situations. However, the concept of streaming is unknown to the core rules, so they cannot be used directly, but only interpreted. In my opinion, it is an undesirable situation.
+
+Proposal:
+Dedicated restrictions on connecting and mapping stream ports shall be added to the continous signalling specification as follows:
+a) The connect operation is allowed only if the in value type of port 1 is equal to the out value type of port 2 and the out value type of port 1 is equal to the in value type of port 2
+b) The map operation is allowed only if the in value type of port 1 is equal to the in value type of port 2 and the out value type of port 1 is equal to the out value type of port 2
+c) Incoming stream ports of a test component and outgoing stream ports of the system adapter cannot be connected/mapped to more than one port (The sampling procedure can insert only a single value into the incoming stream in one sampling step and with 2 or more connected/mapped ports it is not obvious from which port would that value come. Such limitation is not necessary for outgoing stream ports and incoming ports of the system adapter, which might be useful e.g. for streaming to several PTCs.)
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR6610_v1.docx (16,453) 10-04-2014 11:10
http://oldforge.etsi.org/mantis/file_download.php?file_id=2990&type=bug
Issue History
Date ModifiedUsernameFieldChange
04-09-2013 11:04Tomas UrbanNew Issue
04-09-2013 11:04Tomas UrbanClause Reference(s) => 5.2
04-09-2013 11:04Tomas UrbanSource (company - Author) => Elvior
25-09-2013 14:57Jacob Wieland - SpirentNote Added: 0011673
07-10-2013 12:30Gyorgy RethyProjectTTCN-3 Change Requests => Ext Pack: Continuous signal support (ES 202 786)
07-10-2013 12:31Gyorgy RethyAssigned To => Jens Grabowski
07-10-2013 12:31Gyorgy RethyStatusnew => assigned
07-10-2013 12:31Gyorgy RethyTarget Version => v1.2.1 (published 2014-06)
10-10-2013 22:11Tomas UrbanNote Added: 0011763
11-10-2013 13:33Jacob Wieland - SpirentNote Added: 0011778
11-10-2013 14:08Tomas UrbanNote Added: 0011782
14-10-2013 13:35Jacob Wieland - SpirentNote Added: 0011805
08-04-2014 10:42Jens GrabowskiAssigned ToJens Grabowski => Tomas Urban
08-04-2014 17:09Gyorgy RethyProduct Version => v1.1.1 (published 2012-04)
08-04-2014 17:09Gyorgy RethyTarget Versionv1.2.1 (published 2014-06) => v1.3.1 (published 2015-06)
09-04-2014 15:00Tomas UrbanNote Added: 0011973
09-04-2014 15:00Tomas UrbanAssigned ToTomas Urban => Jens Grabowski
10-04-2014 11:10Tomas UrbanFile Added: CR6610_v1.docx
10-04-2014 11:13Tomas UrbanStatusassigned => confirmed
20-06-2014 10:20Jens GrabowskiNote Added: 0012181
20-06-2014 10:20Jens GrabowskiStatusconfirmed => closed
20-06-2014 10:20Jens GrabowskiResolutionopen => fixed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011673) +
+ Jacob Wieland - Spirent    +
+ 25-09-2013 14:57    +
+ 		+ + + + +
+ How do these restrictions (a/b) differ from the normal restrictions?
+
+Also, why isn't the normal disambiguation (from/sender) possible if an incoming port is mapped/connected to multiple other ports?
+
+
+
+ + + + + + + + + + +
+ (0011763) +
+ Tomas Urban    +
+ 10-10-2013 22:11    +
+ 		+ + + + +
+ The difference is in terminology. Streaming ports always support one type called "value type" while message and procedure ports have message or procedure lists. Since there's always one type, it is not necessary to use set comparison, but the compatibility rule is based on simple equality. But technically, the rules are similar. My intention was merely to provide explict rule so that the reader doesn't have to derivem them himself/herself.
+
+Regarding source disambiguation: I don't think it is possible. Let's imagine the situation of having one incoming stream connected to two outgoing streams. The incoming stream gets its value during sampling procedure (which is active in the background without user interference and therefore cannot be influenced by any from/sender clause). With two outgoing streams, there are two candidates for the source value. Which one will be taken and stored in the port history? Will the TE store both and somehow create two parallel histories? The current specification doesn't consider it possible. Of course, one might modify the rules for value, history and values operations and add a from/sender operation to them to handle this parallelism, but is it actually necessary? Are there any users requiring it? I seriously doubt about it. And for that reason I proposed the restriction c which efficiently removes the problem of multiple source streams.
+
+
+
+ + + + + + + + + + +
+ (0011778) +
+ Jacob Wieland - Spirent    +
+ 11-10-2013 13:33    +
+ 		+ + + + +
+ I think the single-source/multiple-target restriction makes sense.
+
+Regarding the connect/map restrictions, I think a NOTE could be sufficient which clarifies that the rules that exist for lists of types also work for these single-element-lists in the same way.
+
+
+
+ + + + + + + + + + +
+ (0011782) +
+ Tomas Urban    +
+ 11-10-2013 14:08    +
+ 		+ + + + +
+ I might tentatively agree with a note, but I don't think it is a correct approach.
+
+The original rules operate with terms inlist-PORT1, inlist-PORT2, outlist-PORT1, outlist-PORT2. These terms are define as messages or procerures in the in/out direction of a particular port. However, stream port don't contain messages or procedures, but a stream value type (see semantic description in 5.2.2.1). This term is not mentioned in the original rule.
+
+In my opinion, all specifications should rigorously use correct terminology in order to be interpreted correctly. That's the reason why I proposed a dedicated rule for stream ports.
+
+And there's a second reason, I totally forgot about in my previous post. Without the proposed rules, one might consider stream value type equal to a message list with one element, which would efficiently make it possible to map/connect stream ports with/to message ports.
+
+
+
+ + + + + + + + + + +
+ (0011805) +
+ Jacob Wieland - Spirent    +
+ 14-10-2013 13:35    +
+ 		+ + + + +
+ I agree that the restriction that stream ports shall only be connected/mapped to other stream ports is a valid point.
+
+I also have no problem of repeating the more general statement from the standard in a more specialized way here, but I think that simple additional restrictions and stating that - except for the restrictions - a stream port behaves like a message port with one message type regarding map/connect would also be totally sufficient.
+
+
+
+ + + + + + + + + + +
+ (0011973) +
+ Tomas Urban    +
+ 09-04-2014 15:00    +
+ 		+ + + + +
+ Resolution uploaded.
+Please check.
+
+
+
+ + + + + + + + + + +
+ (0012181) +
+ Jens Grabowski    +
+ 20-06-2014 10:20    +
+ 		+ + + + +
+ Implemented as proposed in the DRAFT of the next version.
+
+ + diff --git a/docs/mantis/CR6611.md b/docs/mantis/CR6611.md new file mode 100644 index 0000000000000000000000000000000000000000..32b91b3f9cadf6c1f031a3dd7d96ca7af1083c7f --- /dev/null +++ b/docs/mantis/CR6611.md @@ -0,0 +1,132 @@ + + + + + + + + + + + + + 0006611: Continuous signalling: port control operations - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Continuous signal support (ES 202 786)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006611Ext Pack: Continuous signal support (ES 202 786)Technicalpublic04-09-2013 11:3520-06-2014 09:21
ReporterTomas Urban 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv1.1.1 (published 2012-04) 
Target Versionv1.3.1 (published 2015-06)Fixed in Versionv1.3.1 (published 2015-06) 
Summary0006611: Continuous signalling: port control operations
DescriptionThe exact effect of port control operations (start, stop, clear, halt, checkstate) on streaming ports shall be specified in the continuous signalling specification. The current rules from the core language specification are quite difficult to apply, because communication ports are fundamentally different from streaming ports.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR6611_v1.docx (15,876) 11-04-2014 13:10
http://oldforge.etsi.org/mantis/file_download.php?file_id=3016&type=bug
Issue History
Date ModifiedUsernameFieldChange
04-09-2013 11:35Tomas UrbanNew Issue
04-09-2013 11:35Tomas UrbanClause Reference(s) => 5.2
04-09-2013 11:35Tomas UrbanSource (company - Author) => Elvior
07-10-2013 12:30Gyorgy RethyProjectTTCN-3 Change Requests => Ext Pack: Continuous signal support (ES 202 786)
07-10-2013 12:30Gyorgy RethyAssigned To => Jens Grabowski
07-10-2013 12:30Gyorgy RethyStatusnew => assigned
07-10-2013 12:30Gyorgy RethyTarget Version => v1.2.1 (published 2014-06)
07-04-2014 10:51Jens GrabowskiNote Added: 0011932
08-04-2014 08:56Gyorgy RethyTarget Versionv1.2.1 (published 2014-06) => v1.3.1 (published 2015-06)
08-04-2014 10:45Jens GrabowskiAssigned ToJens Grabowski => Tomas Urban
08-04-2014 17:10Gyorgy RethyProduct Version => v1.1.1 (published 2012-04)
11-04-2014 13:10Tomas UrbanFile Added: CR6611_v1.docx
11-04-2014 13:12Tomas UrbanNote Added: 0012026
11-04-2014 13:12Tomas UrbanAssigned ToTomas Urban => Jens Grabowski
11-04-2014 13:12Tomas UrbanStatusassigned => confirmed
20-06-2014 09:21Jens GrabowskiNote Added: 0012174
20-06-2014 09:21Jens GrabowskiStatusconfirmed => closed
20-06-2014 09:21Jens GrabowskiResolutionopen => fixed
20-06-2014 09:21Jens GrabowskiFixed in Version => v1.3.1 (published 2015-06)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011932) +
+ Jens Grabowski    +
+ 07-04-2014 10:51    +
+ 		+ + + + +
+ Tomas will make a proposal.
+
+
+
+ + + + + + + + + + +
+ (0012026) +
+ Tomas Urban    +
+ 11-04-2014 13:12    +
+ 		+ + + + +
+ Resolution uploaded.
+Please check.
+
+
+
+ + + + + + + + + + +
+ (0012174) +
+ Jens Grabowski    +
+ 20-06-2014 09:21    +
+ 		+ + + + +
+ Implemented as proposed.
+
+ + diff --git a/docs/mantis/CR6613.md b/docs/mantis/CR6613.md new file mode 100644 index 0000000000000000000000000000000000000000..08d87198b26fd931db8fe54c6ff6f5fe5efa6df4 --- /dev/null +++ b/docs/mantis/CR6613.md @@ -0,0 +1,338 @@ + + + + + + + + + + + + + 0006613: Signature types and generic singature type parameters should be allowed. - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Advanced Parametrization (ES 202 784)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006613Ext Pack: Advanced Parametrization (ES 202 784)New Featurepublic12-09-2013 11:0522-01-2014 11:07
ReporterJacob Wieland - Spirent 
Assigned ToJacob Wieland - Spirent 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv1.4.1 (published 2014-06)Fixed in Versionv1.4.1 (published 2014-06) 
TS versionlatest
Clause Reference(s)new feature
Source (company - Author)Testing Technologies - Jacob Wieland
Summary0006613: Signature types and generic singature type parameters should be allowed.
DescriptionThere is no possibility to type-safely abstract over signatures of the same 'signature' (i.e. parameter list, return value, exceptions). This leads to a lot of copy-paste with the obvious common drawbacks and a low acceptance of the procedure based communication feature in general.
+
+Proposal:
+
+allow signature types:
+
+type signature S(...) return R exception(E1, ..., En)
+
+allow generic signature type parameters:
+
+type port P<S s> procedure { inout s; }
+
+function myCall<S s>(P<s> p) return R {
+  var R r;
+  p.call(s:{/* parameters matching parameter list of S */}, 1.0) {
+  [] p.getreply(s:{...}) -> value r; { return r; }
+  [] p.catch(s, E1:?) { testcase.stop; }
+  ...
+  }
+}
+
+This would allow the following usage, supposing concrete_s is of signature type S:
+
+type port ConcreteP procedure { inout concrete_s };
+
+function g(ConcreteP p) return R {
+   return myCall<concrete_s>(p);
+}
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR6613.doc (278,528) 09-10-2013 13:37
http://oldforge.etsi.org/mantis/file_download.php?file_id=2910&type=bug
doc CR6613 resolution v2.doc (292,864) 24-11-2013 21:29
http://oldforge.etsi.org/mantis/file_download.php?file_id=2936&type=bug
doc CR6613 resolution v3.doc (297,472) 25-11-2013 14:07
http://oldforge.etsi.org/mantis/file_download.php?file_id=2937&type=bug
doc CR6613 resolution v4.doc (302,080) 29-12-2013 19:09
http://oldforge.etsi.org/mantis/file_download.php?file_id=2973&type=bug
Issue History
Date ModifiedUsernameFieldChange
12-09-2013 11:05Jacob Wieland - SpirentNew Issue
12-09-2013 11:05Jacob Wieland - SpirentTS version => latest
12-09-2013 11:05Jacob Wieland - SpirentClause Reference(s) => new feature
12-09-2013 11:05Jacob Wieland - SpirentSource (company - Author) => Testing Technologies - Jacob Wieland
07-10-2013 12:24Gyorgy RethyProjectExt Pack: Advanced Parametrization (ES 202 784) => Ext Pack: Continuous signal support (ES 202 786)
07-10-2013 12:26Gyorgy RethyProjectExt Pack: Continuous signal support (ES 202 786) => TTCN-3 Change Requests
07-10-2013 12:28Gyorgy RethyNote Added: 0011681
08-10-2013 10:48Gyorgy RethyProjectTTCN-3 Change Requests => Ext Pack: Advanced Parametrization (ES 202 784)
08-10-2013 13:46Gyorgy RethyNote Added: 0011702
08-10-2013 13:46Gyorgy RethyAssigned To => Jacob Wieland - Spirent
08-10-2013 13:46Gyorgy RethyStatusnew => assigned
08-10-2013 13:46Gyorgy RethyTarget Version => v1.4.1 (published 2014-06)
09-10-2013 13:37Jacob Wieland - SpirentFile Added: CR6613.doc
09-10-2013 13:39Jacob Wieland - SpirentNote Added: 0011731
09-10-2013 13:39Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
09-10-2013 13:39Jacob Wieland - SpirentStatusassigned => confirmed
24-11-2013 21:29Gyorgy RethyFile Added: CR6613 resolution v2.doc
24-11-2013 21:35Gyorgy RethyNote Added: 0011821
24-11-2013 21:36Gyorgy RethyStatusconfirmed => assigned
24-11-2013 21:36Gyorgy RethyAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
25-11-2013 14:07Jacob Wieland - SpirentFile Added: CR6613 resolution v3.doc
25-11-2013 14:10Jacob Wieland - SpirentNote Added: 0011826
25-11-2013 14:10Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
25-11-2013 14:10Jacob Wieland - SpirentStatusassigned => confirmed
29-12-2013 19:08Gyorgy RethyNote Added: 0011910
29-12-2013 19:09Gyorgy RethyNote Edited: 0011910
29-12-2013 19:09Gyorgy RethyFile Added: CR6613 resolution v4.doc
29-12-2013 19:10Gyorgy RethyStatusconfirmed => assigned
29-12-2013 19:10Gyorgy RethyAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
29-12-2013 19:10Gyorgy RethyNote Edited: 0011910
29-12-2013 20:25Gyorgy RethyStatusassigned => confirmed
29-12-2013 20:25Gyorgy RethyResolutionopen => fixed
29-12-2013 20:25Gyorgy RethyFixed in Version => v1.4.1 (published 2014-06)
06-01-2014 12:39Jacob Wieland - SpirentStatusconfirmed => resolved
06-01-2014 12:39Jacob Wieland - SpirentNote Added: 0011913
22-01-2014 11:07Gyorgy RethyStatusresolved => closed
22-01-2014 11:07Gyorgy RethyNote Added: 0011916
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011681) +
+ Gyorgy Rethy    +
+ 07-10-2013 12:28    +
+ 		+ + + + +
+ To be clarified: which document and clause the CR is related to?
+
+
+
+ + + + + + + + + + +
+ (0011702) +
+ Gyorgy Rethy    +
+ 08-10-2013 13:46    +
+ 		+ + + + +
+ STF discussion: type signature ... is not needed. Parameterization with dummySignature (just using the signature keyword) needs to be allowed, just like to parameterization with types.
+
+
+
+ + + + + + + + + + +
+ (0011731) +
+ Jacob Wieland - Spirent    +
+ 09-10-2013 13:39    +
+ 		+ + + + +
+ After discussion in STF: allowed signature as type-parameter-modifier (as alternative to type) and restricted its usage to only signature-types. Allowed signatures as actual parameters as well (only Type was allowed before and in the core language, these two are distinguished).
+
+
+
+ + + + + + + + + + +
+ (0011821) +
+ Gyorgy Rethy    +
+ 24-11-2013 21:35    +
+ 		+ + + + +
+ The terms "type" and "signature" are used in a distinct way in part-1, where signature has a character similar to types, but is related to synchronous communication. For this reason they shall also be used in a distinct way in the packages, like "type and signature formal parameters".
+
+Resolution text in CR6613 resolution v2.doc is re-edited according to this. Pls. review.
+
+
+
+ + + + + + + + + + +
+ (0011826) +
+ Jacob Wieland - Spirent    +
+ 25-11-2013 14:10    +
+ 		+ + + + +
+ some small editorial changes, one duplicate sentence fragment deleted
+
+in actual parameter section, added signatures in the syntactical part
+
+
+
+ + + + + + + + + + +
+ (0011910) +
+ Gyorgy Rethy    +
+ 29-12-2013 19:08    +
(edited on: 29-12-2013 19:10)
+ 		+ + + + +
+ Some further changes, pls. review; see CR6613 resolution v4.doc:
+- New package tag is added and a note saying that modules not containing signature parameters are also compatible with the previous tag.
+-table 2 is extended with signature parameterization of types, functions,
+-Default signature is added to syntactical structure in 5.4.1.5.
+-Last sentence of 5.4.1.5 is deleted as the same requirement exists in 5.4.2.1.
+
+
+
+
+
+ + + + + + + + + + +
+ (0011913) +
+ Jacob Wieland - Spirent    +
+ 06-01-2014 12:39    +
+ 		+ + + + +
+ Looks fine to me.
+
+
+
+ + + + + + + + + + +
+ (0011916) +
+ Gyorgy Rethy    +
+ 22-01-2014 11:07    +
+ 		+ + + + +
+ Implemented in draft for approval
+
+ + diff --git a/docs/mantis/CR6614.md b/docs/mantis/CR6614.md new file mode 100644 index 0000000000000000000000000000000000000000..ecd540557d372f6d227b6c79a4038ad8a493b144 --- /dev/null +++ b/docs/mantis/CR6614.md @@ -0,0 +1,136 @@ + + + + + + + + + + + + + 0006614: Using streaming ports in static configurations - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Continuous signal support (ES 202 786)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006614Ext Pack: Continuous signal support (ES 202 786)Technicalpublic12-09-2013 13:2306-01-2015 16:59
ReporterTomas Urban 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv1.1.1 (published 2012-04) 
Target Versionv1.3.1 (published 2015-06)Fixed in Version 
Summary0006614: Using streaming ports in static configurations
DescriptionThe use of streaming ports (defined in extension package ETSI ES 202 786) in static configuration (defined in extension package ETSI ES 202 781) is not defined in either of the specifications.
+
+Logically, it should be possible, but at there should be at least some rules regarding the sampling mechanism:
+1. Time progress for static MTCs should start in the begining of configuration function(and not in the beginning of a test case)
+2. Sampling of ports of static components shall be active even when a test case is not running (during transition between test cases)
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR6614_v1.docx (79,606) 10-10-2014 08:59
http://oldforge.etsi.org/mantis/file_download.php?file_id=3140&type=bug
Issue History
Date ModifiedUsernameFieldChange
12-09-2013 13:23Tomas UrbanNew Issue
12-09-2013 13:23Tomas UrbanClause Reference(s) => ETSI ES 202 786 and ETSI ES 202 781
12-09-2013 13:23Tomas UrbanSource (company - Author) => Elvior
07-10-2013 12:17Gyorgy RethyProjectTTCN-3 Change Requests => Ext Pack: Continuous signal support (ES 202 786)
07-10-2013 12:23Gyorgy RethyAssigned To => Jens Grabowski
07-10-2013 12:23Gyorgy RethyStatusnew => assigned
07-10-2013 12:23Gyorgy RethyTarget Version => v1.2.1 (published 2014-06)
22-10-2013 08:45Tomas UrbanNote Added: 0011811
08-04-2014 10:30Jens GrabowskiAssigned ToJens Grabowski => Tomas Urban
08-04-2014 17:09Gyorgy RethyProduct Version => v1.1.1 (published 2012-04)
08-04-2014 17:09Gyorgy RethyTarget Versionv1.2.1 (published 2014-06) => v1.3.1 (published 2015-06)
10-10-2014 08:59Tomas UrbanFile Added: CR6614_v1.docx
10-10-2014 09:01Tomas UrbanNote Added: 0012337
10-10-2014 09:01Tomas UrbanAssigned ToTomas Urban => Jens Grabowski
10-10-2014 09:01Tomas UrbanStatusassigned => confirmed
06-01-2015 16:59Jens GrabowskiNote Added: 0012642
06-01-2015 16:59Jens GrabowskiStatusconfirmed => closed
06-01-2015 16:59Jens GrabowskiResolutionopen => fixed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011811) +
+ Tomas Urban    +
+ 22-10-2013 08:45    +
+ 		+ + + + +
+ If the above mentioned proposals are accepted, there will be an impact on TRI. Current clock-related functions (triStartClock, triReadClock, triNextSampling, triBeginWait, triProcessStep, triEndWait) expect one active clock. However, the use of configurations means that there will be several clocks running in parallel with different starts. I order to distinguish between them, there should be a dedicated "static" version of these functions containing one additional parameter of a TriConfigurationIdType. This type should have the same format as TriFuncionIdType (being derived from QualifiedName). The parameter shall contain a value of an active configuration for all TRI calls from a test case running on the configuration or an inactive configuration when performing sampling of its ports between test cases (in triNextSampling, triProcessStep).
+
+
+
+ + + + + + + + + + +
+ (0012337) +
+ Tomas Urban    +
+ 10-10-2014 09:01    +
+ 		+ + + + +
+ Proposal uploaded. It contains also complete TRI mapping which was actually resolved in 0006628 but for some reason didn't make it to the final version of the document.
+Please check.
+
+
+
+ + + + + + + + + + +
+ (0012642) +
+ Jens Grabowski    +
+ 06-01-2015 16:59    +
+ 		+ + + + +
+ Implemented according to proposal.
+
+ + diff --git a/docs/mantis/CR6616.md b/docs/mantis/CR6616.md new file mode 100644 index 0000000000000000000000000000000000000000..b33af27a95f8fcad353f961d872bc31bcd0a5197 --- /dev/null +++ b/docs/mantis/CR6616.md @@ -0,0 +1,134 @@ + + + + + + + + + + + + + 0006616: Continuous signalling: Syntactical description of the apply operation - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Continuous signal support (ES 202 786)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006616Ext Pack: Continuous signal support (ES 202 786)Editorialpublic27-09-2013 09:2120-06-2014 09:59
ReporterTomas Urban 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv1.1.1 (published 2012-04) 
Target Versionv1.3.1 (published 2015-06)Fixed in Version 
Summary0006616: Continuous signalling: Syntactical description of the apply operation
DescriptionThe syntactical description of the apply operation is wrong for two reasons:
+1. The BNF doesn't allow use of if statements in the body of the cont mode (only assignments and asserts are allowed, see Annex A.2 rule 59)
+2. Since both value and delta changes become efficient when the next port sample is taken and the described cont mode doesn't contain any measures for waiting for this to happen (and thus running on the smallest sampling rate available in the system), the given algorithm will efficiently overwrite previously assigned values and deltas if the delta provided in the previous step is higher than the smallest available system sampling rate.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR6616_v1.docx (17,270) 11-04-2014 09:16
http://oldforge.etsi.org/mantis/file_download.php?file_id=3010&type=bug
Issue History
Date ModifiedUsernameFieldChange
27-09-2013 09:21Tomas UrbanNew Issue
27-09-2013 09:21Tomas UrbanClause Reference(s) => 5.2.5.3
27-09-2013 09:21Tomas UrbanSource (company - Author) => Elvior
07-10-2013 12:16Gyorgy RethyProjectTTCN-3 Change Requests => Ext Pack: Continuous signal support (ES 202 786)
07-10-2013 12:16Gyorgy RethyAssigned To => Jens Grabowski
07-10-2013 12:16Gyorgy RethyStatusnew => assigned
07-10-2013 12:16Gyorgy RethyTarget Version => v1.2.1 (published 2014-06)
07-04-2014 10:58Jens GrabowskiNote Added: 0011933
08-04-2014 10:46Jens GrabowskiAssigned ToJens Grabowski => Tomas Urban
08-04-2014 17:10Gyorgy RethyProduct Version => v1.1.1 (published 2012-04)
08-04-2014 17:10Gyorgy RethyTarget Versionv1.2.1 (published 2014-06) => v1.3.1 (published 2015-06)
11-04-2014 09:16Tomas UrbanFile Added: CR6616_v1.docx
11-04-2014 09:17Tomas UrbanNote Added: 0012016
11-04-2014 09:17Tomas UrbanAssigned ToTomas Urban => Jens Grabowski
11-04-2014 09:17Tomas UrbanStatusassigned => confirmed
20-06-2014 09:59Jens GrabowskiNote Added: 0012178
20-06-2014 09:59Jens GrabowskiStatusconfirmed => closed
20-06-2014 09:59Jens GrabowskiResolutionopen => fixed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011933) +
+ Jens Grabowski    +
+ 07-04-2014 10:58    +
+ 		+ + + + +
+ Proposal by Tomas
+
+
+
+ + + + + + + + + + +
+ (0012016) +
+ Tomas Urban    +
+ 11-04-2014 09:17    +
+ 		+ + + + +
+ Proposed resolution uploaded. The code was successfully tested in TestCast, but it my be worth to try it with some other tool as well.
+Please check the resolution.
+
+
+
+ + + + + + + + + + +
+ (0012178) +
+ Jens Grabowski    +
+ 20-06-2014 09:59    +
+ 		+ + + + +
+ Implemented as proposed in current Draft.
+
+ + diff --git a/docs/mantis/CR6617.md b/docs/mantis/CR6617.md new file mode 100644 index 0000000000000000000000000000000000000000..2914673d1b640a8c0f20de17cff47cd7d8dad1b4 --- /dev/null +++ b/docs/mantis/CR6617.md @@ -0,0 +1,99 @@ + + + + + + + + + + + + + 0006617: Continuous signalling: invalid use of notes - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Continuous signal support (ES 202 786)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006617Ext Pack: Continuous signal support (ES 202 786)Editorialpublic27-09-2013 09:3326-12-2013 12:56
ReporterTomas Urban 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv1.2.1 (published 2014-06)Fixed in Version 
Summary0006617: Continuous signalling: invalid use of notes
DescriptionNote 3 in 5.2.3.1 and note in 5.2.3.3 constitute new binding rules rather than clarifying existing rules or their consequences and as such should not be marked as a note.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR6617-Res-V1-131008.doc (73,728) 08-10-2013 10:01
http://oldforge.etsi.org/mantis/file_download.php?file_id=2894&type=bug
Issue History
Date ModifiedUsernameFieldChange
27-09-2013 09:33Tomas UrbanNew Issue
27-09-2013 09:33Tomas UrbanClause Reference(s) => 5.2.3.1, 5.2.3.3
27-09-2013 09:33Tomas UrbanSource (company - Author) => Elvior
07-10-2013 12:15Gyorgy RethyProjectTTCN-3 Change Requests => Ext Pack: Continuous signal support (ES 202 786)
07-10-2013 12:15Gyorgy RethyAssigned To => Jens Grabowski
07-10-2013 12:15Gyorgy RethyStatusnew => assigned
07-10-2013 12:15Gyorgy RethyTarget Version => v1.2.1 (published 2014-06)
08-10-2013 10:00Jens GrabowskiNote Added: 0011696
08-10-2013 10:01Jens GrabowskiFile Added: CR6617-Res-V1-131008.doc
08-10-2013 10:01Jens GrabowskiAssigned ToJens Grabowski => Jacob Wieland - Spirent
08-10-2013 11:19Jacob Wieland - SpirentNote Added: 0011700
08-10-2013 11:19Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Ina Schieferdecker
08-10-2013 11:19Jacob Wieland - SpirentStatusassigned => confirmed
08-10-2013 12:37Ina SchieferdeckerStatusconfirmed => assigned
08-10-2013 12:37Ina SchieferdeckerAssigned ToIna Schieferdecker => Jens Grabowski
08-10-2013 16:24Jens GrabowskiStatusassigned => resolved
08-10-2013 16:24Jens GrabowskiResolutionopen => fixed
26-12-2013 12:56Jens GrabowskiStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011696) +
+ Jens Grabowski    +
+ 08-10-2013 10:00    +
+ 		+ + + + +
+ Resolution Proposal attached.
+
+Assigned to Jacob for cross-checking.
+
+
+
+ + + + + + + + + + +
+ (0011700) +
+ Jacob Wieland - Spirent    +
+ 08-10-2013 11:19    +
+ 		+ + + + +
+ fine with me
+
+ + diff --git a/docs/mantis/CR6618.md b/docs/mantis/CR6618.md new file mode 100644 index 0000000000000000000000000000000000000000..d6377d6e23d54dbc4be4ed14bd3f3a070c148091 --- /dev/null +++ b/docs/mantis/CR6618.md @@ -0,0 +1,132 @@ + + + + + + + + + + + + + 0006618: Continuous signalling: invalid use of goto in examples - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Continuous signal support (ES 202 786)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006618Ext Pack: Continuous signal support (ES 202 786)Technicalpublic27-09-2013 09:4026-12-2013 12:59
ReporterTomas Urban 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv1.2.1 (published 2014-06)Fixed in Version 
Summary0006618: Continuous signalling: invalid use of goto in examples
DescriptionThe goto commands used in examples in 5.4.1.1.3 and 5.4.1.1.4 are located inside optional transition statement blocks, which is forbidden by the 2nd restriction of 5.4.1.1.1. The correct place for the goto command would be after the statement blocks, as described in 5.4.1.1.2.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR6618-Res-V1-131007.doc (74,240) 07-10-2013 16:28
http://oldforge.etsi.org/mantis/file_download.php?file_id=2892&type=bug
Issue History
Date ModifiedUsernameFieldChange
27-09-2013 09:40Tomas UrbanNew Issue
27-09-2013 09:40Tomas UrbanClause Reference(s) => 5.4.1.1.3, 5.4.1.1.4
27-09-2013 09:40Tomas UrbanSource (company - Author) => Elvior
07-10-2013 11:56Gyorgy RethyProjectTTCN-3 Change Requests => Ext Pack: Continuous signal support (ES 202 786)
07-10-2013 11:57Gyorgy RethyAssigned To => Jens Grabowski
07-10-2013 11:57Gyorgy RethyStatusnew => assigned
07-10-2013 11:57Gyorgy RethyTarget Version => v1.2.1 (published 2014-06)
07-10-2013 13:51Tomas UrbanNote Added: 0011687
07-10-2013 16:28Jens GrabowskiFile Added: CR6618-Res-V1-131007.doc
07-10-2013 16:29Jens GrabowskiNote Added: 0011692
07-10-2013 16:30Jens GrabowskiAssigned ToJens Grabowski => Jacob Wieland - Spirent
08-10-2013 14:18Jacob Wieland - SpirentNote Added: 0011704
08-10-2013 14:18Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Jens Grabowski
08-10-2013 14:18Jacob Wieland - SpirentStatusassigned => confirmed
08-10-2013 16:20Jens GrabowskiStatusconfirmed => resolved
08-10-2013 16:20Jens GrabowskiResolutionopen => fixed
26-12-2013 12:59Jens GrabowskiStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011687) +
+ Tomas Urban    +
+ 07-10-2013 13:51    +
+ 		+ + + + +
+ I have to admit that my statement is probably not correct, as the mentioned goto commands don't break the hierarchy rules. However, it would be still feasible to change the examples to keep the same code convention in the whole specification.
+
+
+
+ + + + + + + + + + +
+ (0011692) +
+ Jens Grabowski    +
+ 07-10-2013 16:29    +
+ 		+ + + + +
+ Changed according the Note from Tomas.
+Assigned to Jacob for Crosschecking.
+
+
+
+ + + + + + + + + + +
+ (0011704) +
+ Jacob Wieland - Spirent    +
+ 08-10-2013 14:18    +
+ 		+ + + + +
+ ok
+
+ + diff --git a/docs/mantis/CR6619.md b/docs/mantis/CR6619.md new file mode 100644 index 0000000000000000000000000000000000000000..8e30856d9d0a8ffda8ede4c7b1556119e5c366d0 --- /dev/null +++ b/docs/mantis/CR6619.md @@ -0,0 +1,101 @@ + + + + + + + + + + + + + 0006619: Continuous signalling: vague rule on error verdict caused by invariants - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Continuous signal support (ES 202 786)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006619Ext Pack: Continuous signal support (ES 202 786)Clarificationpublic27-09-2013 10:0506-01-2015 17:00
ReporterTomas Urban 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv1.1.1 (published 2012-04) 
Target Versionv1.3.1 (published 2015-06)Fixed in Version 
Summary0006619: Continuous signalling: vague rule on error verdict caused by invariants
DescriptionThe chapter 5.4.1.2 contains the following rule: "If an invariant of an active mode is violated, the mode must be able to switch to another mode that has valid invariants during the respective sampling step. If this is not possible, the test system must set an error verdict."
+
+This rule contains a term "switch to another mode" which is undefined by the specification and might be interpreted in several ways. I would appreciate precise specification of this term, especially in cases when dealing with implicit follow-up modes:
+- If there's a statement (such as an assignment) between a mode terminated by an invariant and its follow-up mode, will it activate the above mentioned rule?
+- If the follow-up mode is on a different scope (e.g. in a calling function), will leaving the original scope set an error verdict or not?
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR6619_v1.docx (53,157) 09-10-2014 14:12
http://oldforge.etsi.org/mantis/file_download.php?file_id=3129&type=bug
Issue History
Date ModifiedUsernameFieldChange
27-09-2013 10:05Tomas UrbanNew Issue
27-09-2013 10:05Tomas UrbanClause Reference(s) => 5.4.1.2
27-09-2013 10:05Tomas UrbanSource (company - Author) => Elvior
07-10-2013 11:46Gyorgy RethyProjectTTCN-3 Change Requests => Ext Pack: Continuous signal support (ES 202 786)
07-10-2013 11:48Gyorgy RethyAssigned To => Jens Grabowski
07-10-2013 11:48Gyorgy RethyStatusnew => assigned
08-04-2014 10:47Jens GrabowskiAssigned ToJens Grabowski => Tomas Urban
08-04-2014 17:11Gyorgy RethyProduct Version => v1.1.1 (published 2012-04)
08-04-2014 17:11Gyorgy RethyTarget Version => v1.3.1 (published 2015-06)
09-10-2014 14:12Tomas UrbanFile Added: CR6619_v1.docx
09-10-2014 14:12Tomas UrbanNote Added: 0012324
09-10-2014 14:12Tomas UrbanAssigned ToTomas Urban => Jens Grabowski
09-10-2014 14:12Tomas UrbanStatusassigned => confirmed
06-01-2015 17:00Jens GrabowskiNote Added: 0012643
06-01-2015 17:00Jens GrabowskiStatusconfirmed => closed
06-01-2015 17:00Jens GrabowskiResolutionopen => fixed
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0012324) +
+ Tomas Urban    +
+ 09-10-2014 14:12    +
+ 		+ + + + +
+ Resolution draft uploaded. Please check.
+
+
+
+ + + + + + + + + + +
+ (0012643) +
+ Jens Grabowski    +
+ 06-01-2015 17:00    +
+ 		+ + + + +
+ Implemented according to proposal.
+
+ + diff --git a/docs/mantis/CR6620.md b/docs/mantis/CR6620.md new file mode 100644 index 0000000000000000000000000000000000000000..3578220e9e51b70a5562d88c37f1278afda0f5fd --- /dev/null +++ b/docs/mantis/CR6620.md @@ -0,0 +1,139 @@ + + + + + + + + + + + + + 0006620: Continuous signalling: missing semicolon in cont statement BNF - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Continuous signal support (ES 202 786)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006620Ext Pack: Continuous signal support (ES 202 786)Technicalpublic27-09-2013 11:5226-12-2013 12:57
ReporterTomas Urban 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv1.2.1 (published 2014-06)Fixed in Version 
Summary0006620: Continuous signalling: missing semicolon in cont statement BNF
DescriptionThe current BNF rule 52 for the cont statement doesn't contain a semicolon as a separator of VarInstance and BasicModeOp. The rule shall be changed to:
+
+52.BasicMode ::= ContKeyword " {" {VarInstance [SemiColon]}
+[OnEntryBlock]
+[InvariantBlock]
+{BasicModeOp [SemiColon]}
+[OnExitBlock]
+" }"
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR6620-6621-V1-131007.doc (98,304) 07-10-2013 12:30
http://oldforge.etsi.org/mantis/file_download.php?file_id=2888&type=bug
Issue History
Date ModifiedUsernameFieldChange
27-09-2013 11:52Tomas UrbanNew Issue
27-09-2013 11:52Tomas UrbanClause Reference(s) => A.2
27-09-2013 11:52Tomas UrbanSource (company - Author) => Elvior
07-10-2013 11:47Gyorgy RethyProjectTTCN-3 Change Requests => Ext Pack: Continuous signal support (ES 202 786)
07-10-2013 11:48Gyorgy RethyAssigned To => Jens Grabowski
07-10-2013 11:48Gyorgy RethyStatusnew => assigned
07-10-2013 11:57Gyorgy RethyTarget Version => v1.2.1 (published 2014-06)
07-10-2013 12:30Jens GrabowskiNote Added: 0011682
07-10-2013 12:30Jens GrabowskiFile Added: CR6620-6621-V1-131007.doc
07-10-2013 12:31Jens GrabowskiNote Added: 0011683
07-10-2013 12:31Jens GrabowskiAssigned ToJens Grabowski => Jacob Wieland - Spirent
08-10-2013 14:21Jacob Wieland - SpirentNote Added: 0011705
08-10-2013 14:21Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Jens Grabowski
08-10-2013 14:21Jacob Wieland - SpirentStatusassigned => confirmed
08-10-2013 16:22Jens GrabowskiStatusconfirmed => resolved
08-10-2013 16:22Jens GrabowskiResolutionopen => fixed
26-12-2013 12:57Jens GrabowskiStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011682) +
+ Jens Grabowski    +
+ 07-10-2013 12:30    +
+ 		+ + + + +
+ Implemented as suggested (attached file also includes update according to CR6621).
+
+
+
+ + + + + + + + + + +
+ (0011683) +
+ Jens Grabowski    +
+ 07-10-2013 12:31    +
+ 		+ + + + +
+ Assigned to Jacob for crosschecking.
+
+
+
+ + + + + + + + + + +
+ (0011705) +
+ Jacob Wieland - Spirent    +
+ 08-10-2013 14:21    +
+ 		+ + + + +
+ except for the missing parenthesis for 6621 (see there), ok
+
+ + diff --git a/docs/mantis/CR6621.md b/docs/mantis/CR6621.md new file mode 100644 index 0000000000000000000000000000000000000000..058d47559943e8d16789e95b6183b87d28ae38df --- /dev/null +++ b/docs/mantis/CR6621.md @@ -0,0 +1,145 @@ + + + + + + + + + + + + + 0006621: Continuous signalling: invalid BNF for transitions - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Continuous signal support (ES 202 786)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006621Ext Pack: Continuous signal support (ES 202 786)Technicalpublic27-09-2013 15:1126-12-2013 12:55
ReporterTomas Urban 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv1.2.1 (published 2014-06)Fixed in Version 
Summary0006621: Continuous signalling: invalid BNF for transitions
DescriptionThe current rule 69. of the BNF defining a single transition is inconsistent with the syntactical structure in 5.4.1.1.1. The trigger part and statement are compulsory in the BNF, but optional in 5.4.1.1.1 and other parts of the specification.
+
+I propose to update the rule to:
+69.UntilGuardStatement ::= "[" [BooleanExpression] "]" [GuardOp] [StatementBlock] [GotoStatement]
+
+or
+
+69.UntilGuardStatement ::= ( "[" BooleanExpression "]" [GuardOp] ) | ( "[" "]" GuardOp ) [StatementBlock] [GotoStatement]
+
+The second option provides a better representation of the rule that there can be either a guard or a trigger or both.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR6621-V1-131007.doc (97,792) 07-10-2013 12:10
http://oldforge.etsi.org/mantis/file_download.php?file_id=2887&type=bug
doc CR6621-V2-131007.doc (97,792) 07-10-2013 15:22
http://oldforge.etsi.org/mantis/file_download.php?file_id=2890&type=bug
Issue History
Date ModifiedUsernameFieldChange
27-09-2013 15:11Tomas UrbanNew Issue
27-09-2013 15:11Tomas UrbanClause Reference(s) => A.2
27-09-2013 15:11Tomas UrbanSource (company - Author) => Elvior
07-10-2013 11:44Jens GrabowskiStatusnew => assigned
07-10-2013 11:44Jens GrabowskiAssigned To => Jens Grabowski
07-10-2013 11:46Gyorgy RethyProjectTTCN-3 Change Requests => Ext Pack: Continuous signal support (ES 202 786)
07-10-2013 12:10Jens GrabowskiFile Added: CR6621-V1-131007.doc
07-10-2013 12:11Jens GrabowskiNote Added: 0011679
07-10-2013 12:11Jens GrabowskiAssigned ToJens Grabowski => Jacob Wieland - Spirent
07-10-2013 12:14Gyorgy RethyTarget Version => v1.2.1 (published 2014-06)
07-10-2013 12:25Jacob Wieland - SpirentNote Added: 0011680
07-10-2013 12:25Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Jens Grabowski
07-10-2013 12:25Jacob Wieland - SpirentStatusassigned => confirmed
07-10-2013 15:22Jens GrabowskiNote Added: 0011689
07-10-2013 15:22Jens GrabowskiFile Added: CR6621-V2-131007.doc
07-10-2013 15:23Jens GrabowskiStatusconfirmed => resolved
07-10-2013 15:23Jens GrabowskiResolutionopen => fixed
26-12-2013 12:55Jens GrabowskiStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011679) +
+ Jens Grabowski    +
+ 07-10-2013 12:11    +
+ 		+ + + + +
+ Second option implemented.
+
+Assigned to Jacob for crosscheck.
+
+
+
+ + + + + + + + + + +
+ (0011680) +
+ Jacob Wieland - Spirent    +
+ 07-10-2013 12:25    +
+ 		+ + + + +
+ I think the actual syntax must be (as | is weaker than concatenation in BNF):
+
+ (( "[" BooleanExpression "]" [GuardOp] ) | ( "[" "]" GuardOp )) [StatementBlock] [GotoStatement]
+
+
+
+ + + + + + + + + + +
+ (0011689) +
+ Jens Grabowski    +
+ 07-10-2013 15:22    +
+ 		+ + + + +
+ Changed according to Jacob's remark.
+Status changed to resolved.
+
+ + diff --git a/docs/mantis/CR6622.md b/docs/mantis/CR6622.md new file mode 100644 index 0000000000000000000000000000000000000000..dee86b909b674100eae90eb5f9c5c2900721c9da --- /dev/null +++ b/docs/mantis/CR6622.md @@ -0,0 +1,561 @@ + + + + + + + + + + + + + 0006622: Introduce special reserved words to avoid future additional keyword problems - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006622Part 01: TTCN-3 Core LanguageNew Featurepublic07-10-2013 11:0607-02-2014 06:40
ReporterJacob Wieland - Spirent 
Assigned ToGyorgy Rethy 
PriorityhighSeveritymajorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.6.1 (published 2014-06)Fixed in Versionv4.6.1 (published 2014-06) 
Clause Reference(s)A.1.5
Source (company - Author)Testing Technologies - Jacob Wieland
Summary0006622: Introduce special reserved words to avoid future additional keyword problems
DescriptionIn the past, an existing concept in TTCN-3 has been enlarged or given an additional semantics by adding specific syntax or keywords.
+
+This often lead to backward incompatibilities as every new keyword cannot be used as an identifier and therefore all such identifiers in older test suites need to be renamed if they shall be used in a module from the newer language version.
+
+Also, the optional TTCN-3 packages often need to introduce new keywords which - because of their optionality - makes the situation even more complicated.
+
+To alleviate these problems in the future while maintaining/achieving high readability of the language, the concept of special reserved word shall be introduced that works like a keyword but does not clash with an identifier.
+
+The syntax/usage and semantics of each such special reserved word shall still be specified in either the core language or the language package that introduces the it.
+
+The lexical syntax of a special reserved word shall be the @-symbol followed by a sequence of letters, numbers or underscores starting with a letter. This sequence must not be restricted any further other than to avoid clashes between special reserved words. Therefore, the TTCN-3 maintenance must in the future take heed of possible special-reserved-word-clashes whenever a new special reserved word is to be introduced.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR6622.doc (173,568) 09-10-2013 09:46
http://oldforge.etsi.org/mantis/file_download.php?file_id=2903&type=bug
doc CR6622_v2.doc (174,592) 10-10-2013 13:50
http://oldforge.etsi.org/mantis/file_download.php?file_id=2921&type=bug
doc CR6622_resolution_v3.doc (176,128) 11-10-2013 13:41
http://oldforge.etsi.org/mantis/file_download.php?file_id=2929&type=bug
doc CR6622_resolution_v4.doc (177,664) 29-11-2013 09:55
http://oldforge.etsi.org/mantis/file_download.php?file_id=2959&type=bug
Issue History
Date ModifiedUsernameFieldChange
07-10-2013 11:06Jacob Wieland - SpirentNew Issue
07-10-2013 11:06Jacob Wieland - SpirentClause Reference(s) => Core Language - Section 28
07-10-2013 11:06Jacob Wieland - SpirentSource (company - Author) => Testing Technologies - Jacob Wieland
07-10-2013 11:07Jacob Wieland - SpirentStatusnew => assigned
07-10-2013 11:07Jacob Wieland - SpirentAssigned To => Jacob Wieland - Spirent
07-10-2013 11:59Gyorgy RethyProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
07-10-2013 11:59Gyorgy RethyTarget Version => v4.6.1 (published 2014-06)
07-10-2013 12:04Gyorgy RethyNote Added: 0011678
08-10-2013 14:26Jacob Wieland - SpirentClause Reference(s)Core Language - Section 28 => A.1.5
08-10-2013 14:26Jacob Wieland - SpirentSummaryIntroduce modifiers to avoid future additional keyword problems => Introduce special reserved words to avoid future additional keyword problems
08-10-2013 14:26Jacob Wieland - SpirentDescription Updated
09-10-2013 09:46Jacob Wieland - SpirentFile Added: CR6622.doc
09-10-2013 09:47Jacob Wieland - SpirentNote Added: 0011718
09-10-2013 09:47Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
09-10-2013 09:47Jacob Wieland - SpirentStatusassigned => confirmed
10-10-2013 10:21Gyorgy RethyNote Added: 0011746
10-10-2013 10:22Gyorgy RethyAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
10-10-2013 10:22Gyorgy RethyStatusconfirmed => assigned
10-10-2013 13:43Jacob Wieland - SpirentNote Added: 0011754
10-10-2013 13:46Jacob Wieland - SpirentNote Added: 0011755
10-10-2013 13:50Jacob Wieland - SpirentFile Added: CR6622_v2.doc
10-10-2013 13:50Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
10-10-2013 13:50Jacob Wieland - SpirentStatusassigned => confirmed
11-10-2013 13:38Gyorgy RethyFile Added: CR6622_v3.doc
11-10-2013 13:40Gyorgy RethyNote Added: 0011779
11-10-2013 13:40Gyorgy RethyAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
11-10-2013 13:40Gyorgy RethyStatusconfirmed => assigned
11-10-2013 13:41Gyorgy RethyNote Edited: 0011779
11-10-2013 13:41Gyorgy RethyFile Deleted: CR6622_v3.doc
11-10-2013 13:41Gyorgy RethyFile Added: CR6622_resolution_v3.doc
11-10-2013 14:03Jacob Wieland - SpirentNote Added: 0011781
11-10-2013 17:09Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
11-10-2013 17:09Jacob Wieland - SpirentStatusassigned => confirmed
23-11-2013 10:20Gyorgy RethyNote Added: 0011820
23-11-2013 10:21Gyorgy RethyAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
23-11-2013 10:21Gyorgy RethyStatusconfirmed => assigned
25-11-2013 13:01Jacob Wieland - SpirentNote Added: 0011825
26-11-2013 14:46Jacob Wieland - SpirentNote Added: 0011835
26-11-2013 14:47Jacob Wieland - SpirentNote Added: 0011836
26-11-2013 14:47Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Ina Schieferdecker
26-11-2013 14:47Jacob Wieland - SpirentStatusassigned => confirmed
29-11-2013 09:55Ina SchieferdeckerFile Added: CR6622_resolution_v4.doc
29-11-2013 09:56Ina SchieferdeckerNote Added: 0011862
29-11-2013 09:56Ina SchieferdeckerAssigned ToIna Schieferdecker => Gyorgy Rethy
29-11-2013 09:56Ina SchieferdeckerResolutionopen => fixed
29-11-2013 10:53Jacob Wieland - SpirentNote Added: 0011863
07-02-2014 05:40Ina SchieferdeckerNote Added: 0011922
07-02-2014 05:40Ina SchieferdeckerStatusconfirmed => closed
07-02-2014 05:40Ina SchieferdeckerFixed in Version => v4.6.1 (published 2014-06)
07-02-2014 06:40Ina SchieferdeckerNote Added: 0011924
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011678) +
+ Gyorgy Rethy    +
+ 07-10-2013 12:04    +
+ 		+ + + + +
+ Hi Jacob, just an editorial note; I can see the clause reference in the CR is 28. I propose to add this stuff to a new clause 5.6, as the mechanism will be used later on throughout the standard.
+
+
+
+ + + + + + + + + + +
+ (0011718) +
+ Jacob Wieland - Spirent    +
+ 09-10-2013 09:47    +
+ 		+ + + + +
+ I have now simply added a new paragraph and table to the TTCN-3 terminals section in annex A which is where the other terminals are also introduced (and therefore the right place, I think).
+
+
+
+ + + + + + + + + + +
+ (0011746) +
+ Gyorgy Rethy    +
+ 10-10-2013 10:21    +
+ 		+ + + + +
+ Text has to be added to clause 5.1 instead. The modifiers are not necessary followed by identifiers, in most cases the opposite:
+[private] @fuzz template ...
+function MyFunc (in @lazy integer p_i) {...}
+
+
+
+ + + + + + + + + + +
+ (0011754) +
+ Jacob Wieland - Spirent    +
+ 10-10-2013 13:43    +
+ 		+ + + + +
+ No, I think there is a misunderstanding on your part. the @-symbol (just the character '@') is followed by what is defined as an identifier (i.e. a sequence of letters, digits and underscores beginning with a letter). Such a special reserved word can be used anywhere by the grammar.
+
+
+
+ + + + + + + + + + +
+ (0011755) +
+ Jacob Wieland - Spirent    +
+ 10-10-2013 13:46    +
+ 		+ + + + +
+ Originally I had added a sentence to 5.1, but I seem to have accidentally deleted it. Maybe I'll find it again.
+
+
+
+ + + + + + + + + + +
+ (0011779) +
+ Gyorgy Rethy    +
+ 11-10-2013 13:40    +
(edited on: 11-10-2013 13:41)
+ 		+ + + + +
+ I meant this: see in CR6622_resolution_v3.doc
+
+
+
+
+
+ + + + + + + + + + +
+ (0011781) +
+ Jacob Wieland - Spirent    +
+ 11-10-2013 14:03    +
+ 		+ + + + +
+ Why limit ourselves in that way? Why can these keywords not be used for other purposes as well? Of course, we should still only add them if absolutely necessary, but I don't see a reason why this idea can not be used more generally other than for modifiers?
+
+
+
+ + + + + + + + + + +
+ (0011820) +
+ Gyorgy Rethy    +
+ 23-11-2013 10:20    +
+ 		+ + + + +
+ They can be used later, for other "special" purpose too, if we decide so. But to write a concrete text we need a concrete concept. At the moment the modifier concept is in our heads (that was discussed and agreed earlier) that can be extended later.
+
+I think, the language shall remain consistent in the sense that no@-keywords and @-special-words shall not be mixed. I.e. @identifier words shall be used for special purposes only - like the modifiers - on the long term. Of course, we can use a better (English) word for the special words than "modifiers" in the standard's text, but in this case we need to explain the "modifier meaning" of the @lazy and the @fuzz. If you have a proposal, come forward with it.
+
+
+
+ + + + + + + + + + +
+ (0011825) +
+ Jacob Wieland - Spirent    +
+ 25-11-2013 13:01    +
+ 		+ + + + +
+ Okay, what you are getting at that these specific special reserved words play the role of modifiers and thus should also be called modifiers in the respective sections that introduce them. I have no problem with that. In the general section introducing the terminal symbols, I would still use a more general term, though, so as not to limit ourselves in the future.
+
+
+
+ + + + + + + + + + +
+ (0011835) +
+ Jacob Wieland - Spirent    +
+ 26-11-2013 14:46    +
+ 		+ + + + +
+ So, my original proposal (CR6622_v2.doc) stands: in general, when describing the TTCN-3 terminal symbols, call them special TTCN-3 keywords - no semantics is involved, it's just technical. And when such keywords are used as modifiers by some language construct, call them modifiers (in the other proposals).
+
+
+
+ + + + + + + + + + +
+ (0011836) +
+ Jacob Wieland - Spirent    +
+ 26-11-2013 14:47    +
+ 		+ + + + +
+ Please review and give feedback, if any.
+
+
+
+ + + + + + + + + + +
+ (0011862) +
+ Ina Schieferdecker    +
+ 29-11-2013 09:56    +
+ 		+ + + + +
+ Please check v4
+
+
+
+ + + + + + + + + + +
+ (0011863) +
+ Jacob Wieland - Spirent    +
+ 29-11-2013 10:53    +
+ 		+ + + + +
+ you're mixing the lexical and the semantic levels.
+
+Yes, on the semantic level, some of these special keywords can be used like modifiers for existing constructions, but, they could be used for other purposes as well, so already calling them modifiers on the lexical level (which is what these sections describe) is simply wrong.
+
+Thus, all things that have to do with modifiers should be removed from these sections. If you really want to introduce the concept of modifiers, there should be an own section introduced somewhere (at the moment I have no idea where) which describes what a modifier is, where it should normally placed and that they can be freely combined in any order (which is something to do with the syntactical level, not the lexical one).
+
+Maybe the term modifier should simply be defined in the definitions section, so that it later can be used in the text for keywords that play the role of modifiers (the keyword realtime, for instance, is also a modifier for port types).
+
+
+
+ + + + + + + + + + +
+ (0011922) +
+ Ina Schieferdecker    +
+ 07-02-2014 05:40    +
+ 		+ + + + +
+ Implemented as proposed in v4
+
+
+
+ + + + + + + + + + +
+ (0011924) +
+ Ina Schieferdecker    +
+ 07-02-2014 06:40    +
+ 		+ + + + +
+ @deterministic to be kept because of CR on deterministic functions!
+
+ + diff --git a/docs/mantis/CR6623.md b/docs/mantis/CR6623.md new file mode 100644 index 0000000000000000000000000000000000000000..c87353742b4149438ac369532de57a7b89b97acf --- /dev/null +++ b/docs/mantis/CR6623.md @@ -0,0 +1,1431 @@ + + + + + + + + + + + + + 0006623: Allow lazy evaluation. - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006623Part 01: TTCN-3 Core LanguageNew Featurepublic07-10-2013 11:5107-02-2014 06:38
ReporterJacob Wieland - Spirent 
Assigned ToIna Schieferdecker 
PriorityhighSeveritymajorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.6.1 (published 2014-06)Fixed in Versionv4.6.1 (published 2014-06) 
Clause Reference(s)5.4.1, 11, 15, 16
Source (company - Author)Testing Technologies - Jacob Wieland
Summary0006623: Allow lazy evaluation.
DescriptionLazy expression/function application evaluation which delays the evaluation of an expression until its actual usage can have any number of applications.
+
+In security testing there is a concept called fuzzing where an operator can either generate one of a list of values randomly (and a different one for every invocation) or mutate a given value randomly, thereby simulating security attacks that the test system must be proof against. Lazy evaluation would allow a simple denotation of fuzz-templates which are only evaluated at the place of their usage, i.e. upon sending, when matching or converting to a value.
+
+Another application or lazy evaluation is optional code which may be active in one context but inactive in another (only determinable at runtime). Having to evaluate the non-active expressions puts unnecessary strain on the testing architecture and can lead to bad performance of the test system. To avoid this, at the moment, the code must be much more complicated than it would have to be using lazy evaluation and would need to replicate the decision-code (which of the different optional code-parts are active) in many places.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR6623.doc (768,512) 09-10-2013 09:43
http://oldforge.etsi.org/mantis/file_download.php?file_id=2902&type=bug
doc CR6623_v2.doc (651,264) 10-10-2013 13:34
http://oldforge.etsi.org/mantis/file_download.php?file_id=2920&type=bug
doc CR6623_v3.doc (685,568) 11-10-2013 12:30
http://oldforge.etsi.org/mantis/file_download.php?file_id=2927&type=bug
doc CR6623_v4.doc (676,864) 26-11-2013 17:42
http://oldforge.etsi.org/mantis/file_download.php?file_id=2943&type=bug
doc CR6623_v5.doc (707,072) 28-01-2014 16:03
http://oldforge.etsi.org/mantis/file_download.php?file_id=2976&type=bug
Issue History
Date ModifiedUsernameFieldChange
07-10-2013 11:51Jacob Wieland - SpirentNew Issue
07-10-2013 11:51Jacob Wieland - SpirentClause Reference(s) => 5.4.1, 11, 15, 16
07-10-2013 11:51Jacob Wieland - SpirentSource (company - Author) => Testing Technologies - Jacob Wieland
07-10-2013 11:54Jacob Wieland - SpirentStatusnew => assigned
07-10-2013 11:54Jacob Wieland - SpirentAssigned To => Jacob Wieland - Spirent
07-10-2013 11:58Gyorgy RethyProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
07-10-2013 11:59Gyorgy RethyPrioritynormal => high
07-10-2013 11:59Gyorgy RethyTarget Version => v4.4.1 (published 2012-04)
07-10-2013 12:13Gyorgy RethyTarget Versionv4.4.1 (published 2012-04) => v4.6.1 (published 2014-06)
09-10-2013 09:43Jacob Wieland - SpirentFile Added: CR6623.doc
09-10-2013 09:51Jacob Wieland - SpirentNote Added: 0011719
09-10-2013 09:51Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Jens Grabowski
09-10-2013 09:51Jacob Wieland - SpirentStatusassigned => confirmed
09-10-2013 10:14Jens GrabowskiStatusconfirmed => assigned
09-10-2013 12:21Jens GrabowskiNote Added: 0011726
09-10-2013 12:21Jens GrabowskiAssigned ToJens Grabowski => Jacob Wieland - Spirent
10-10-2013 10:41Gyorgy RethyNote Added: 0011747
10-10-2013 13:34Jacob Wieland - SpirentFile Added: CR6623_v2.doc
10-10-2013 13:40Jacob Wieland - SpirentNote Added: 0011753
10-10-2013 13:40Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
10-10-2013 13:40Jacob Wieland - SpirentStatusassigned => confirmed
11-10-2013 12:30Gyorgy RethyFile Added: CR6623_v3.doc
11-10-2013 12:33Gyorgy RethyNote Added: 0011775
11-10-2013 12:36Gyorgy RethyAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
11-10-2013 12:36Gyorgy RethyStatusconfirmed => assigned
11-10-2013 13:01Jacob Wieland - SpirentNote Added: 0011776
11-10-2013 13:22Jacob Wieland - SpirentNote Edited: 0011776
11-10-2013 13:23Jacob Wieland - SpirentNote Added: 0011777
11-10-2013 13:23Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
11-10-2013 13:23Jacob Wieland - SpirentStatusassigned => confirmed
11-10-2013 14:21Gyorgy RethyNote Added: 0011783
11-10-2013 14:21Gyorgy RethyAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
11-10-2013 14:21Gyorgy RethyStatusconfirmed => assigned
11-10-2013 14:24Gyorgy RethyNote Edited: 0011783
11-10-2013 14:59Tomas UrbanNote Added: 0011785
11-10-2013 15:00Tomas UrbanNote Edited: 0011785
11-10-2013 15:26Jacob Wieland - SpirentNote Added: 0011787
11-10-2013 15:29Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
11-10-2013 15:29Jacob Wieland - SpirentStatusassigned => confirmed
11-10-2013 15:34Tomas UrbanNote Added: 0011788
11-10-2013 16:25Gyorgy RethyNote Added: 0011791
11-10-2013 16:25Gyorgy RethyStatusconfirmed => assigned
11-10-2013 16:25Gyorgy RethyAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
11-10-2013 16:26Tomas UrbanNote Added: 0011792
11-10-2013 16:43Gyorgy RethyNote Added: 0011794
11-10-2013 16:54Jacob Wieland - SpirentNote Added: 0011795
11-10-2013 17:01Jacob Wieland - SpirentNote Added: 0011796
12-10-2013 10:21Gyorgy RethyNote Added: 0011797
12-10-2013 10:27Gyorgy RethyNote Edited: 0011797
12-10-2013 10:40Gyorgy RethyNote Edited: 0011797
12-10-2013 10:43Gyorgy RethyNote Edited: 0011797
12-10-2013 10:47Gyorgy RethyNote Edited: 0011797
12-10-2013 10:48Gyorgy RethyNote Edited: 0011797
12-10-2013 10:49Gyorgy RethyNote Edited: 0011797
12-10-2013 17:00Tomas UrbanNote Added: 0011798
14-10-2013 10:52Gyorgy RethyNote Added: 0011799
14-10-2013 10:54Gyorgy RethyNote Edited: 0011799
14-10-2013 12:26Tomas UrbanNote Added: 0011801
14-10-2013 13:23Jacob Wieland - SpirentNote Added: 0011803
14-10-2013 13:26Jacob Wieland - SpirentNote Added: 0011804
22-11-2013 13:28Gyorgy RethyNote Added: 0011815
22-11-2013 13:29Gyorgy RethyNote Edited: 0011815
26-11-2013 15:28Jacob Wieland - SpirentNote Added: 0011837
26-11-2013 17:42Jacob Wieland - SpirentFile Added: CR6623_v4.doc
26-11-2013 17:43Jacob Wieland - SpirentNote Added: 0011841
26-11-2013 17:43Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
26-11-2013 17:43Jacob Wieland - SpirentStatusassigned => confirmed
28-11-2013 11:05Gyorgy RethyNote Added: 0011854
28-11-2013 11:05Gyorgy RethyStatusconfirmed => assigned
28-11-2013 11:05Gyorgy RethyAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
28-11-2013 11:50Jacob Wieland - SpirentNote Added: 0011858
28-11-2013 12:06Jacob Wieland - SpirentNote Edited: 0011858
28-11-2013 14:50Gyorgy RethyAssigned ToJacob Wieland - Spirent => Jens Grabowski
28-01-2014 16:02Gyorgy RethyNote Added: 0011917
28-01-2014 16:03Gyorgy RethyFile Added: CR6623_v5.doc
28-01-2014 16:04Gyorgy RethyTarget Versionv4.6.1 (published 2014-06) => v4.7.1 (published 2015-06)
29-01-2014 11:07Jacob Wieland - SpirentNote Added: 0011918
29-01-2014 11:08Jacob Wieland - SpirentAssigned ToJens Grabowski => Ina Schieferdecker
29-01-2014 11:08Jacob Wieland - SpirentStatusassigned => confirmed
04-02-2014 13:05Jacob Wieland - SpirentStatusconfirmed => resolved
04-02-2014 13:05Jacob Wieland - SpirentFixed in Version => v4.6.1 (published 2014-06)
04-02-2014 13:05Jacob Wieland - SpirentResolutionopen => fixed
07-02-2014 06:38Ina SchieferdeckerNote Added: 0011923
07-02-2014 06:38Ina SchieferdeckerStatusresolved => closed
07-02-2014 06:38Ina SchieferdeckerTarget Versionv4.7.1 (published 2015-06) => v4.6.1 (published 2014-06)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011719) +
+ Jacob Wieland - Spirent    +
+ 09-10-2013 09:51    +
+ 		+ + + + +
+ please review
+
+
+
+ + + + + + + + + + +
+ (0011726) +
+ Jens Grabowski    +
+ 09-10-2013 12:21    +
+ 		+ + + + +
+ After personal discussion reassigned to Jacob.
+
+
+
+ + + + + + + + + + +
+ (0011747) +
+ Gyorgy Rethy    +
+ 10-10-2013 10:41    +
+ 		+ + + + +
+ Results of the personal discussion with Jacob yesterday: actually we need two modifiers. In some cases evaluation shall be done at each case when a definition is used (e.g. fuzzy templates for security testing). In other cases evaluation shall be delayed, but done only once, at the first use (e.g. lazy parameter evaluation for performance testing, hoping that no evaluation will be needed at all). This has to be controlled by the user, only he knows its use case.
+
+Consequently we need two modifiers for these two different use cases.
+
+We could think about if the modifiers themselves should be put to the core or to the packages, as it was thought at the beginning?
+
+
+
+ + + + + + + + + + +
+ (0011753) +
+ Jacob Wieland - Spirent    +
+ 10-10-2013 13:40    +
+ 		+ + + + +
+ please review:
+
+fuzzy: lazy evaluation, always re-evaluate
+lazy: lazy evaluation, evaluate at most once
+
+- templates now can only be fuzzy
+- variables and parameters can be lazy or fuzzy
+- functions can no longer be fuzzy (not really necessary)
+
+restrictions are chosen in a way that does not conflict with existing features and that does not allow access to local variables that do not exist anymore when evaluating a fuzzy/lazy variable or parameter.
+
+
+
+ + + + + + + + + + +
+ (0011775) +
+ Gyorgy Rethy    +
+ 11-10-2013 12:33    +
+ 		+ + + + +
+ See my amendments and comments in CR6623_v3.doc.
+
+Btw. once performance and security testing require different behavior and modifiers, we could return to the original idea and add @lazy to the performance package and @fuzzy to a new security package. What do you think? Could you also ask Dirk about it?
+
+
+
+ + + + + + + + + + +
+ (0011776) +
+ Jacob Wieland - Spirent    +
+ 11-10-2013 13:01    +
(edited on: 11-10-2013 13:22)
+ 		+ + + + +
+ The restriction for fuzzy variables only being assigned completely has been introduced because otherwise, the implementation would need to know which parts of the expression need to be re-evaluated on the next usage and which not (otherwise, it can simple re-evaluate upon usage without any additional knowledge whatsoever). This overcomplicates things and so I would rather have this restriction.
+
+Lazy template declaration need not be restricted (in section 15, restriction c)) because they have not been introduced. There's only fuzzy templates and fuzzy/lazy template variables.
+
+Regarding 19.1. semantic description of assignment of lazy variables.
+
+Consider the following:
+
+var @lazy MyRecord x := f_initializeRecord();
+x.i := 5;
+
+How should you implement the assignment of field i without first evaluating the x and then changing the value? Actually, if the right-hand-side contains the unchanged symbol, the x also must be evaluated before assignment. Only when the assignment is to x and not a sub-part of x and the right-hand-side does not contain the unchanged symbol would evaluation of x before assignment be unnecessary.
+
+Also, I don't understand your comment "This would cause loss of tool performance and complicates feature for the user without obvoius benefit. For lazy it would just have reverse effect, re-evaluationg all fields all the time, that would not been re-evaluated for an ordinary variable or parameter."
+
+Where is tool performance lost?
+What fields are re-evaluated? (None, in my opinion)
+
+For fuzzy variables, if you have the restriction that no subparts of them can be assigned, the problem does not present itself. Otherwise, you would have the same problem, of course.
+
+
+
+
+
+ + + + + + + + + + +
+ (0011777) +
+ Jacob Wieland - Spirent    +
+ 11-10-2013 13:23    +
+ 		+ + + + +
+ please review my remarks
+
+
+
+ + + + + + + + + + +
+ (0011783) +
+ Gyorgy Rethy    +
+ 11-10-2013 14:21    +
(edited on: 11-10-2013 14:24)
+ 		+ + + + +
+ "The restriction for fuzzy variables only being assigned completely "
+
+It is too restrictive, this is not they normal way, how variables are used in general. The tool need not keep track which parts has been assigned and which one has not. taking your example (modified):
+var @fuzzy MyRecord x := f_initializeRecord();
+x.i := 5; //here x need to be evaluated for tool simplicity reasons
+x.j := 42;//here x need NOT be re-evaluated before the assignment, just assign 42 to the field j
+y := x; //x is evaluated before the assignment
+z := x.j //x is evaluated before the assignment as well
+P.send (x) //x is evaluated again
+==> it is enough to evaluate x if the whole x has been assigned a value in beforehand; but this doesn't mean that field assignments should be forbidden in overall
+------------------------------------------------------
+"Regarding 19.1. semantic description of assignment of lazy variables"
+
+you wrote: "If only part of a lazy variable is assigned, both the variable and the right-hand-side are evaluated before assignment."
+
+Consider this as this is a very typical situation:
+var @lazy MyRecord v_MyRecord;
+v_MyRecord.f1 := f_initialize_f1();
+//function call is stored but it is useless to evaluate any of the fields
+...//v_MyRecord not used here
+v_MyRecord.f2 := f_initialize_f2(); //ditto
+...//v_MyRecord not used here
+v_MyRecord.f3 := f_initialize_f3(); //ditto
+if (b){P.send (v_MyRecord)} //this is the first place, where v_MyRecord really needs to be evaluated; all 3 function calls. But acc. to your proposal, up to this point *all fields* of the lazy variable should have been re-evaluated 3 times! resulting a worth performance than without @lazy!
+==> it is enough to evaluate v_MyRecord at v_MyRecord.f1 if the whole v_MyRecord has been assigned a value in beforehand, like in your example
+x := f_initializeRecord(); x.i := 5;
+
+
+
+
+
+ + + + + + + + + + +
+ (0011785) +
+ Tomas Urban    +
+ 11-10-2013 14:59    +
(edited on: 11-10-2013 15:00)
+ 		+ + + + +
+ Have you considered a scope restriction too? In my opinion, expressions that contain variables declared on a lower scope or in a non-related scope shall not be referenced in expressions assigned to fuzzy and lazy variables, because there's a serious danger that at the point of evaluation, the memory allocated for such referenced variables has been already disposed. E.g.
+
+function f1(inout @lazy p)
+{
+   // y is a local variable that will be disposed when the funcion returns
+   var integer y := 5;
+   p := y + 4;
+}
+
+function f2()
+{
+   var @lazy integer x;
+   f1(x);
+   log(x); // the address of y is no longer available
+}
+
+Of course, it is possible to save the local memory block together with the entry point for lazy/fuzzy evaluation, but it might make disposing procedures impractically complex.
+
+
+
+
+
+ + + + + + + + + + +
+ (0011787) +
+ Jacob Wieland - Spirent    +
+ 11-10-2013 15:26    +
+ 		+ + + + +
+ @Tomas: lazy inout or out are not allowed (specifically because of this problem)
+
+@Gyorgy:
+
+> "The restriction for fuzzy variables only being assigned completely "
+
+> It is too restrictive, this is not they normal way, how variables are used in > general. The tool need not keep track which parts has been assigned and which > one has not. taking your example (modified):
+> var @fuzzy MyRecord x := f_initializeRecord();
+> x.i := 5; //here x need to be evaluated for tool simplicity reasons
+
+What would be the evaluation of x here?
+
+> x.j := 42;//here x need NOT be re-evaluated before the assignment, just assign 42 to the field j
+
+What would be the evaluation of x here?
+
+> y := x; //x is evaluated before the assignment
+
+> z := x.j //x is evaluated before the assignment as well
+> P.send (x) //x is evaluated again
+> ==> it is enough to evaluate x if the whole x has been assigned a value in beforehand; but this doesn't mean that field assignments should be forbidden in overall
+
+My problem is, I have no idea what the semantics of x is supposed to be after all these assignments. What happens to the values that WOULD have to be assigned by f_initializeRecord() because of the overwriting of these fields? Do they override the assignments, if so, the assignments have no effect. Do I have to keep the additional assignments extra somewhere and delay them over the evaluation of the original assignment (like a modifies)? This is all far too complicated - no one would understand that semantics either way.
+
+My view of fuzzy variables is simple: they store an unevaluated, unchangeable expression that will be evaluated every time, so that is in essence a bit like a macro variable.
+
+------------------------------------------------------
+> "Regarding 19.1. semantic description of assignment of lazy variables"
+
+> you wrote: "If only part of a lazy variable is assigned, both the variable and the right-hand-side are evaluated before assignment."
+
+> Consider this as this is a very typical situation:
+> var @lazy MyRecord v_MyRecord;
+> v_MyRecord.f1 := f_initialize_f1();
+> //function call is stored but it is useless to evaluate any of the fields
+> ...//v_MyRecord not used here
+> v_MyRecord.f2 := f_initialize_f2(); //ditto
+> ...//v_MyRecord not used here
+> v_MyRecord.f3 := f_initialize_f3(); //ditto
+> if (b){P.send (v_MyRecord)} //this is the first place, where v_MyRecord really needs to be evaluated; all 3 function calls. But acc. to your proposal, > up to this point *all fields* of the lazy variable should have been re-evaluated 3 times! resulting a worth performance than without @lazy!
+> ==> it is enough to evaluate v_MyRecord at v_MyRecord.f1 if the whole v_MyRecord has been assigned a value in beforehand, like in your example
+> x := f_initializeRecord(); x.i := 5;
+
+This is a total misinterpretation of my intention. Since every evaluation only happens at most ONCE for every lazy variable, it would simply mean that the already assigned fields of the variable are evaluated (if not evaluated already) whenever you assign a new field (that way you do not need to keep track of which fields already have been evaluated and which have not). Of course, if the overall variable is not used, this is worse than if you assigned all the fields in one assignment (because there, nothing would ever be evaluated before usage).
+
+So, assignment of f2 would evaluate rhs of f1 and f2. Assignment of f3 would evaluate rhs of f3. Usage of x would not evaluate anything anymore.This would not be worse than non-lazy, it would be exactly like non-lazy.
+
+But, I can see that this dynamic-lazy-approach that you seem to have in mind can add some value.
+
+It is clear, though, that, if a sub-part of a variable is already assigned something (because it or one of its parent has been assigned), then it needs to be evaluated before further assignment. Can we agree on this part?
+
+
+
+ + + + + + + + + + +
+ (0011788) +
+ Tomas Urban    +
+ 11-10-2013 15:34    +
+ 		+ + + + +
+ > lazy inout or out are not allowed (specifically because of this problem)
+Excellent!
+
+But what about this:
+var @lazy integer x;
+while (...)
+{
+   var integer y;
+   ... // compute y
+   x := y + 1;
+}
+log(x); // x refers to y, but block where y is defined is no
+// longer valid at this point
+
+
+
+ + + + + + + + + + +
+ (0011791) +
+ Gyorgy Rethy    +
+ 11-10-2013 16:25    +
+ 		+ + + + +
+ @Tomas
+I think it's reasonable to say that all operands of the expression shall be visible at the place, where the variable/parameter is actually evaluated. As the feature is meant for performance testing, I don't think this would cause usability issues (only component variables are used anyway). But this is a reason to add the feature to the real time & perf. package instead of the core.
+
+@Jacob
+@fuzzy
+You misunderstood. In cases, when x is initialized as a whole but not evaluated yet (two runtime flags), x is evaluated BEFORE x.i.
+
+Hence, for x.i := 5 the semantics is:
+x := f_initializeRecord();//delayed evaluation
+x.i := 5; //simple field assignment, no re-evaluation
+//and then
+x.j := 42; //simple field assignment, no re-evaluation
+
+Otherwise you would waste only tool performance for nothing, or even for worth testing results. pls. note, fuzzy doesn't mean random! You may fuzz test by shooting messages with a monotonously increasing value in it (for example, a port scanning attack). If fuzzy values are evaluated all the time, even when it is not necessary, this would result holes in the increasing value.
+
+Also note, that fuzz testing is a form of performance testing! The tool shall try as many possible attacks as it can for as short time period as it can. So, tool performance matter here.
+
+@lazy
+in this case the text has to be re-written that it cannot be misinterpreted.
+
+
+
+ + + + + + + + + + +
+ (0011792) +
+ Tomas Urban    +
+ 11-10-2013 16:26    +
+ 		+ + + + +
+ Could you also consider recursive definitions:
+
+var @lazy integer i := 1;
+i := i + 1;
+log(i); // what will be the result?
+
+Or another example:
+
+var @lazy integer i;
+var @lazy integer j;
+i := j;
+j := i; // definition by a circle
+log(i); // infinite loop during resolving
+
+In my opinion, recursive references should not appear in lazy and fuzzy variables.
+
+
+
+ + + + + + + + + + +
+ (0011794) +
+ Gyorgy Rethy    +
+ 11-10-2013 16:43    +
+ 		+ + + + +
+ Hi Tomas, pls. note, only the time of the evaluation is delayed, not its "content". t stick to your example:
+
+var @lazy integer i := 1;
+ i := i + 1;
+
+is equal to:
+var @lazy integer i := 1;
+ i := (i := 1) + 1;
+
+i := j; //it's not possible for normal variables either, because j is uninitialized.
+
+But
+var @lazy integer i;
+var @lazy integer j := 1;
+ i := j;
+ j := i;
+
+Would be equivalent to:
+var @lazy integer i;
+var @lazy integer j := 1;
+ i := (j := 1); //i:= 1, 1 is stored in i here
+ j := (i := 1)//j:=1
+
+
+
+ + + + + + + + + + +
+ (0011795) +
+ Jacob Wieland - Spirent    +
+ 11-10-2013 16:54    +
+ 		+ + + + +
+ @Gyorgy/fuzzy
+
+I think what you are trying to accomplish can be easily accomplished by
+assigning the fuzzy template to a non-lazy/fuzzy variable (that way fixing the current value) and then overwriting the fields that you want to change. That would have a clear semantics in my view. I'm still not clear what your example does. Is the function call evaluated before the field assignment or not? If so, what is the difference to lazy?
+
+@Tomas:
+
+yeah, the inner-local-variable-problem was on my radar as well, but I have not found a solution for that (neither how to formulate the restriction nor how to enforce it).
+
+The recursitivity issue is not a big problem and cannot be avoided in my opinion. It is always possible to write down infinite recursions or endless loops. That cannot be avoided or thoroughly checked statically (semi-decidable problem) so I don't see how another way of doing so harms anyone.
+
+
+
+ + + + + + + + + + +
+ (0011796) +
+ Jacob Wieland - Spirent    +
+ 11-10-2013 17:01    +
+ 		+ + + + +
+ @Gyorgy/recursion
+
+I think Tomas is right in his assessment. Since the time of evaluation is delayed until after the re-assignment of i (or the first assignment of j) is done, the evaluation of the right-hand-side i/j already points to the new initialization of i/j and not the original, overwritten one.
+
+Otherwise, for every re-initialization of a variable, one would have to check the right-hand-side for usages of that variable and then at least evaluate that variable before assigning (as otherwise the original assignment will be lost).
+
+Again, this seems to be very complicated (and pathological, no doubt), which is why I would opt for the easier-to-understand-and-implement version which may cause infinite recursion in such pathological cases (as is always the case for lazy evaluation, I think).
+
+
+
+ + + + + + + + + + +
+ (0011797) +
+ Gyorgy Rethy    +
+ 12-10-2013 10:21    +
(edited on: 12-10-2013 10:49)
+ 		+ + + + +
+ Example extended, corrected:
+var @lazy integer i;
+ var @lazy integer j := 1;//initialization is a must as the next assignment
+                          //(i:=j) would cause runtime error without it
+  i := j;
+  j := i;
+  j := 5;
+
+Is equivalent to:
+ var @lazy integer i;
+ var @lazy integer j := 1;
+  i := (j := 1); //previous j:= 1 is executed here when executing the expression;
+                 // 1 is stored in j, nothing is stored in i
+  j := (i := j ) //j is assigned to i when evaluating the expression;
+                 //as j contains 1 at this point, 1 is assigned to i;
+                 //the original assignment (j := i) is not executed at this point,
+                 //but delayed to the next use of j on the RHS
+  j := 5; //This overrides the previous delayed assignment with a new one;
+                 //yes, the stored j := i assignment is replaced here with a new
+                 //delayed assignment, but what difference does it make?
+
+I can't see where is the recursion or problem here. Everything is done sequentially, only the time of the previous assignment is delayed.
+-----------------------------------------------------
+@difference between @lazy and @fuzzy (we have discussed this already)
+@lazy evaluation is delayed only until the first use on RHS or FIRST assignment to its part, but NOT re-evaluated at further use on RHS
+@fuzzy first evaluation is delayed until the first use on RHS or FIRST assignment to its part AND re-evaluated AT EACH use on RHS
+-----------------------------------------------------
+@fuzzy semantics
+What I say has also a clear semantics, but does not force the user to make "dirty" workarounds, which again,
+1) decreasing tool performance;
+2) you tend to forget that TTCN-3 is not meant for programming experts, but shall be a language that can also be used correctly by testers without programming experience (in fact, they may be about 90% of the users)! If we do not consider this, we will make a wrong language design;
+3) the user may not even be aware that he is using a @fuzzy template/variable; you also tend to forget that majority of the testers are using test frameworks that hides a lots of information from them (e.g. direct access of component variables that can be set/get via library functions only).
+
+
+
+
+
+ + + + + + + + + + +
+ (0011798) +
+ Tomas Urban    +
+ 12-10-2013 17:00    +
+ 		+ + + + +
+ György, I am afaid that we have a different understanding how the RHS of lazy/fuzzy variables work. In my opinion, the RHS of assignment to a lazy/fuzzy variable is NOT evaluated at all, i.e. not used. The TE doesn't perform any calculations during the assignment, it simply stores an entry point for the expression and continues with a next command. This is actually the whole point of lazy/fuzzy variables: not to do anything with the RHS in case of assignment. Thus, applied to our sample code:
+
+var @lazy integer i;
+var @lazy integer j := 1;
+i := j; // value of j is not calculated at this point, because RHS of lazy assignments is not evaluated
+j := i; // i is not evaluated as well
+log(i); // evaluation occurs at this point, producing endless loop
+
+Also notice that in the example, the RHS is trivial. However, since the RHS might contain function calls with cyclic reference to a fuzzy/lazy variable burried deep inside, there's no way to discover this connection without very complex analysis of the RHS or without executing the function. And I don't believe this is intended.
+
+I also think that unlike standard assignments, assignments of lazy or fuzzy variables might contain uninitialized references on the RHS. These symbols have to be initialized in the moment when the fuzzy/lazy variable is used. Thus, the following code should work without a problem and print 5:
+var integer @lazy i;
+var integer @lazy j;
+i := j;
+j := 5;
+log(i);
+
+In order to resolve the problem with unresolvable cyclic references, I would propose one of the following rules:
+1. If a cyclic reference to a variable (or parameter) being resolved is discovered in the evaluated expression, the TE shall produce a runtime error.
+
+2. The expression on the RHS of lazy/fuzzy variable (or parameter) assignment shall not contain any direct or indirect reference to a lazy/fuzzy variable (or parameter).
+
+Both rules would solve the issue with unresolvable cyclic references. The first proposal deals with the actual problem, but its disadvantage is that it offers no protection agains the problem in compilation time. However, there are other similar issues that compilers do not detect, such as endless loops. With a good debugger, it should not be a big deal to discover the source of the error when it occurs.
+
+The second solution is capable of discovering issues in compilation time (with a good compiler). However, it might be too restrictive. I can imagine situations when chaining lazy/fuzzy variables would be useful.
+
+
+
+ + + + + + + + + + +
+ (0011799) +
+ Gyorgy Rethy    +
+ 14-10-2013 10:52    +
(edited on: 14-10-2013 10:54)
+ 		+ + + + +
+ Tomas, we are talking about two different features here. I agree, if we proposed the feature you are describing, it would cause both technical and usability (for the user) problems. You are distinguishing use in an expression or in an operation/statement, and evaluation is invoked only by the second one; we are talking about a much simpler feature that does not make this distinction. Otherwise is would also be impossible to follow/debug what's happening for the user.
+
+The feature I'm talking about is the one in the CR resolution draft. It specifies: "That means that evaluation is delayed during execution until the first actual usage, other than using it at the left hand side of an assignment or passing it to a fuzzy or lazy formal parameter."
+
+This means that in "var @lazy integer j := 1", j:=1 is not evaluated, but in "i := j", the previous j:=1 is evaluated, because this is the FIRST use "other than using it at the left hand side of an assignment or passing it to a fuzzy or lazy formal parameter". For this reason, your example with j not initialized at declaration will cause an error (at the line of i:=j).
+
+This resolves possible cyclic issues and your proposed restrictions are not needed.
+
+
+
+
+
+ + + + + + + + + + +
+ (0011801) +
+ Tomas Urban    +
+ 14-10-2013 12:26    +
+ 		+ + + + +
+ I don't make a distinction where the symbol is used. The whole problem is in understanding of the word "usage" and "usage" in the following rule: "That means that evaluation is delayed during execution until the first actual usage, other than using it at the left hand side of an assignment or passing it to a fuzzy or lazy formal parameter."
+
+We had this discussion last year and the conclusion was that the word "use" doesn't mean syntactical presence, but actual execution of a particular statement. My point is that assignment to a lazy/fuzzy variable doesn't constitute usage, because if the proposed rule is applied to i in i := j (i fullfils the condition of being a lazy variable on the LHS), it triggers delayed execution of the RHS containing j. It means that the expression is not evaluated at the moment of assignment, thus j is not "used" and the rule for evaluation of lazy variables cannot be applied to it.
+
+Your point would be valid, if the words "using" and "usage" were replaced with "occurring" and "occurrence". However, even in this case, there might be a problem with component variables. Consider this:
+
+type component C
+{
+  var @lazy i := 0;
+  var @lazy j := 0;
+}
+
+function f1() return integer runs on C
+{
+  return j;
+}
+
+function f2() return integer runs on C
+{
+  return i;
+}
+
+
+testcase TC() runs on C
+{
+   i := f1(); // j is referenced indirectly
+   j := f2(); // i is referenced indirectly
+   log(i);
+}
+
+Discovering such indirect references requires complex algorithms (my example is just for demonstration, the dependency might not be that obvious in a real code) and leaving them undetected lead to the cyclic reference problem described in my previous posts.
+
+
+
+ + + + + + + + + + +
+ (0011803) +
+ Jacob Wieland - Spirent    +
+ 14-10-2013 13:23    +
+ 		+ + + + +
+ I have to fully agree with Tomas. My understanding of usage does not include usage on the right-hand-side of assignments to lazy variables (because that is the whole point of lazy variables that their right-hand-sides are only evaluated when the variable is used, not when they are assigned).
+
+Therefore, I think that Tomas is right in his assessment. We would have to agree whether the runtime or the compile time solution is more acceptable.
+
+In my opinion, runtime checking is enough, the second restriction could be used as the basis for warnings of cyclic-lazy-variable-dependence. Of course, if a compiler detects an obvious cyclic dependency of a lazy variable (that is used in a non-lazy context) to itself, it may already produce an error at compile-time.
+
+
+
+ + + + + + + + + + +
+ (0011804) +
+ Jacob Wieland - Spirent    +
+ 14-10-2013 13:26    +
+ 		+ + + + +
+ In regard to the access-to-lower-scope-variables, I think we need a restriction like:
+
+The right-hand-side of an assignment to a lazy/fuzzy variable shall only contain references to variables/constants/templates that are known in the scope of the variable declaration.
+
+
+
+ + + + + + + + + + +
+ (0011815) +
+ Gyorgy Rethy    +
+ 22-11-2013 13:28    +
(edited on: 22-11-2013 13:29)
+ 		+ + + + +
+ Actually, we have two properties of lazy variables
+a) they are evaluated when used on the RHS
+b) expression on the RHS is not evaluated when there is a lazy variable on the LHS.
+
+Therefore, when there are lazy vars on both sides of an assignment, the two rules collide. Which one of the rules should take precedence? -> is a matter of optimization decision.
+
+Actually, the requirement is to avoid evaluation of vars/parameters that are NEVER used. For tool performance reasons. If a value is assigned to a variable and the variable *is* used, the time of its evaluation is irrelevant from performance point of view -> it requires the same computing resources. Assigning a value to a var and re-assigning it without using the first value is a rare case and a bad programming style that can be corrected in the code. You try to take into account this situation as well, by giving precedence to rule b), but this leads to extra complications and sometimes to a difficult-to-follow code behavior. This can be avoided if rule a) had the precedence above rule b). As a bonus, the code's behavior is much easier to understand, no implicit chains of var value assignments that actually never happen.
+
+As a compromise solution, we could also say that if a lazy var/parameter is used at both sides of an assignment, the lazy var used in the expression on the RHS is evaluated, but the expression itself does not.
+
+
+I don't fully understand Jacob's proposal regarding lower-scope-variables. For example, it is clear that a component var's value used in an evaluation, shall be its actual value at the time when the RHS is evaluated. This proposal would limit the usability of lazy component vars to zero. In performance testing component variables are used whenever possible, and local variables shall be avoided like a hot iron: the memory for component vars are allocated during tool initialization, when we have more time, while for local vars the memory is allocated during traffic generation, when we are lack of spare time. And memory operations are expensive.
+
+Example; please note, the bahaviour is trivial to follow even in this simple example:
+type component MyComp { var integer ci := 0; }
+
+function MyFuncDieIfZero() runs on MyComp return integer {
+  if (ci==0) { testcase.stop; } // die if the component variable is zero
+  return ci;
+}
+function MyLazyFunc(in @lazy integer pi) runs on MyComp {
+  ci := 1;
+  log(pi); // first use of pi -> 3*MyFuncDieIfZero() is evaluated,
+           // as ci==1 at this point, 3*1=3 is logged
+  ci := 2;
+  log(pi); // second use of pi -> not evaluated, the value 3 is used again
+}
+Calling the function:
+MyLazyFunc(3*MyFuncDieIfZero());
+  // the MyFuncDieIfZero() function is not evaluated here;
+  // as ci==0 at this point, it would die if it was evaluated
+
+
+
+
+
+ + + + + + + + + + +
+ (0011837) +
+ Jacob Wieland - Spirent    +
+ 26-11-2013 15:28    +
+ 		+ + + + +
+ Let me see if I understand your concept of lazy variable correctly.
+
+Suppose we have a declaration
+
+var T x := E
+
+where E contains the variables x1, ... xn
+
+Then x is actually assigned the lambda closure
+
+(\\x1,...,xn.E)(eval(x1),...,eval(xn))
+
+so that later on eval(x) is the evaluation of E where the variables x1 to xn are substituted with their values when x was assigned (not when it is evaluated).
+
+If that is the case, then it does not matter whether or not the variables on the right-hand-side are lazy or not, they are evaluated before assignment, i.e. a use of a lazy variable on the right-hand-side is an actual use that triggers evaluation.
+
+This actually means that it does not matter when a lazy variable is evaluated after an assignment (before it is assigned again) - it will always yield the same result.
+
+In that case, we do not need any restriction in regard of which variables can be used on the right hand side of lazy variable assignments.
+
+For field/element assignments of lazy variables, it is still necessary to first evaluate the variable, i.e. field/element assignments are also a "use" of a lazy variable.
+
+I think I like this concept. It has fewer restrictions and it does not deviate from normal variables a lot, i.e. most variables whose right-hand-sides have no side-effectscan simply be turned into a lazy variables.
+
+
+
+ + + + + + + + + + +
+ (0011841) +
+ Jacob Wieland - Spirent    +
+ 26-11-2013 17:43    +
+ 		+ + + + +
+ amended the proposal according to your comments, please review
+
+
+
+ + + + + + + + + + +
+ (0011854) +
+ Gyorgy Rethy    +
+ 28-11-2013 11:05    +
+ 		+ + + + +
+ Using the closure concept sounds interesting, though I didn't really meant this. Yes, you are right, in this case it is almost(or completely?) unimportant if a variable is lazy or not. In another words, this sounds like a tool optimization issue for me. Also, this may raise memory issues for the tools: the use case is the load testing scenarios, where - literally - millions of entities need to be simulated, and their data need to be stored; so tools have memory consumption issues already.
+
+What I meant is to give control to the user, i.e. declaring a var/param lazy or non-lazy should make a difference. In my "half-way" view, when a lazy var/parameter is evaluated - at its first use-, the values of the dependent data at the time of the evaluation, i.e. not at the time of the assignment, is used. Like in my example below with the component variable. Just the evaluation is done at the first use in all cases, independently of what is at the LHS (i.e. is not re-delayed and re-delayed when the LHS is also lazy).
+
+
+
+ + + + + + + + + + +
+ (0011858) +
+ Jacob Wieland - Spirent    +
+ 28-11-2013 11:50    +
(edited on: 28-11-2013 12:06)
+ 		+ + + + +
+ sorry, I either don't udnerstand your concept or it suffers from the problem that occur if the variables used on the right-hand-side are either the variable being assigned or point to a lazy variable that again uses the variable being assigned (circularity) or not accessible/existent anymore in the scope of usage of the lazy variable (because the scope of these variables has already been left).
+
+also, it has kind of weird, unforseeable consequences in case that the variables being used by the lazy variable are changed after the assignment, so the value of the variable when being evaluated depends on the time of evaluation.
+
+
+
+
+
+ + + + + + + + + + +
+ (0011917) +
+ Gyorgy Rethy    +
+ 28-01-2014 16:02    +
+ 		+ + + + +
+ please find the updated version in CR6623_v5.doc. I didn't change the sentence related to function return value evaluation in ~_v4 version, so hopefully it will be OK.
+
+Please review.
+
+
+
+ + + + + + + + + + +
+ (0011918) +
+ Jacob Wieland - Spirent    +
+ 29-01-2014 11:07    +
+ 		+ + + + +
+ Section 5.4.2. EXAMPLE 6, the modulepar should be renamed to logComplexMessage (or even logMessage and the comment be amended accordingly. At the moment, the semantics is counter-intuitive to the natural-language semantics.
+
+Section 7.1. Restriction a) has a typo: experssion
+
+Otherwise, I consider this resolved.
+
+
+
+ + + + + + + + + + +
+ (0011923) +
+ Ina Schieferdecker    +
+ 07-02-2014 06:38    +
+ 		+ + + + +
+ Implemented with editorial corrections as proposed in v5 and last comment.
+
+
+
+ + diff --git a/docs/mantis/CR6624.md b/docs/mantis/CR6624.md new file mode 100644 index 0000000000000000000000000000000000000000..652b748a99d0e7416c25c3892f0019e19201bd14 --- /dev/null +++ b/docs/mantis/CR6624.md @@ -0,0 +1,191 @@ + + + + + + + + + + + + + 0006624: Allow access to random seed per component. - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006624Part 01: TTCN-3 Core LanguageNew Featurepublic07-10-2013 12:1906-01-2015 18:28
ReporterJacob Wieland - Spirent 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.5.1 (published 2013-04) 
Target Versionv4.7.1 (published 2015-06)Fixed in Versionv4.7.1 (published 2015-06) 
Clause Reference(s)Annex C
Source (company - Author)Testing Technologies - Jacob Wieland
Summary0006624: Allow access to random seed per component.
DescriptionThe predefined rnd() function allows generating random numbers to allow non-deterministic test-behavior. However, sometimes, it is desirable to reproduce such behavior later on (if a problem occurred for a specific sequence of random numbers and it needs to be tested whether the problem has been fixed).
+
+For this, it is necessary to have access to the random-seed that is used by the invocation of the rnd() function. By setting the seed at the beginning of a test case to a specific value, the same sequence of numbers shall be generated, given the same input to the test system. If parallel test components (PTCs) are used, an independent seed per test component is necessary to achieve this determinism.
+
+Therefore, we propose to introduce a function setseed(float) which sets the seed of the invoking component to the given value which must be a float number between in the range (0.0 .. 1.0).
+
+Given that function, the sequence
+
+setseed(x); y := rnd();
+
+has the same semantics as
+
+y := rnd(x);
+
+Calling the rnd() function always implicitly updates the seed of the calling test component to the value returned by the rnd() function.
+
+Additionally, a function getseed() return float can be introduced to access the current seed of a component.
+
+To gain the capability of reproducing such random test behavior, the invocation of the setseed() function maybe should lead to a tliSetSeed call on the TCI level.
Steps To Reproduce
Additional InformationThis concept was originally introduced in the draft for the security testing.
TagsNo tags attached.
Relationships
related to 0006658closed Ina Schieferdecker Part 05: TTCN-3 Runtime Interface  random number generator should be available to test adaptation 
related to 0006659closed Ina Schieferdecker Part 06: TTCN-3 Control Interface Generation of random numbers should be logged for analysis and reproducibility purposes. 
Attached Filesdoc CR6624.doc (157,184) 27-11-2013 11:59
http://oldforge.etsi.org/mantis/file_download.php?file_id=2945&type=bug
doc CR6624_resolution_v2.doc (156,672) 17-06-2014 16:12
http://oldforge.etsi.org/mantis/file_download.php?file_id=3039&type=bug
Issue History
Date ModifiedUsernameFieldChange
07-10-2013 12:19Jacob Wieland - SpirentNew Issue
07-10-2013 12:19Jacob Wieland - SpirentClause Reference(s) => Annex C
07-10-2013 12:19Jacob Wieland - SpirentSource (company - Author) => Testing Technologies - Jacob Wieland
07-10-2013 12:20Jacob Wieland - SpirentStatusnew => assigned
07-10-2013 12:20Jacob Wieland - SpirentAssigned To => Jacob Wieland - Spirent
27-11-2013 11:22Jacob Wieland - SpirentNote Added: 0011843
27-11-2013 11:58Jacob Wieland - SpirentRelationship addedrelated to 0006658
27-11-2013 11:59Jacob Wieland - SpirentRelationship addedrelated to 0006659
27-11-2013 11:59Jacob Wieland - SpirentFile Added: CR6624.doc
27-11-2013 11:59Jacob Wieland - SpirentNote Added: 0011844
27-11-2013 11:59Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
27-11-2013 11:59Jacob Wieland - SpirentStatusassigned => confirmed
17-06-2014 16:02Gyorgy RethyProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
17-06-2014 16:02Gyorgy RethyProduct Version => v4.5.1 (published 2013-04)
17-06-2014 16:02Gyorgy RethyTarget Version => v4.7.1 (published 2015-06)
17-06-2014 16:12Gyorgy RethyNote Added: 0012110
17-06-2014 16:12Gyorgy RethyFile Added: CR6624_resolution_v2.doc
17-06-2014 16:12Gyorgy RethyStatusconfirmed => resolved
17-06-2014 16:12Gyorgy RethyFixed in Version => v4.7.1 (published 2015-06)
17-06-2014 16:12Gyorgy RethyResolutionopen => fixed
06-01-2015 18:28Gyorgy RethyNote Added: 0012650
06-01-2015 18:28Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011843) +
+ Jacob Wieland - Spirent    +
+ 27-11-2013 11:22    +
+ 		+ + + + +
+ Upon further consideration, getseed/setseed do not seem to be necessary after all, as long as the seed-per-component requirement is fulfilled. The setseed is basically done by the rnd function.
+
+To be able to use the random number generator inside the test adapter (e.g. by external functions), a function triRnd(TriComponentId componentId, FloatValue seed) should be added to the TRI (TriPARequired?).
+
+Also, a tliRnd log event should be added to the TCI so that the generation of random numbers can be logged and those values later be analyzed (and used for reproducing the test execution).
+
+I will add a proposal for each of these issues.
+
+
+
+ + + + + + + + + + +
+ (0011844) +
+ Jacob Wieland - Spirent    +
+ 27-11-2013 11:59    +
+ 		+ + + + +
+ please review
+
+
+
+ + + + + + + + + + +
+ (0012110) +
+ Gyorgy Rethy    +
+ 17-06-2014 16:12    +
+ 		+ + + + +
+ CR6624_resolution_v2.doc
+
+It is OK, one editorial change: the second (new) paragraph has been changed to a note. It doesn't contain new requirement (those are already contained in the first paragraph), but explains why has each component and control part its own seeds.
+
+
+
+ + + + + + + + + + +
+ (0012650) +
+ Gyorgy Rethy    +
+ 06-01-2015 18:28    +
+ 		+ + + + +
+ Added to draft V4.6.3
+
+ + diff --git a/docs/mantis/CR6625.md b/docs/mantis/CR6625.md new file mode 100644 index 0000000000000000000000000000000000000000..49cb169e1fb3c4cc2c9a70e24812710e831b96e7 --- /dev/null +++ b/docs/mantis/CR6625.md @@ -0,0 +1,370 @@ + + + + + + + + + + + + + 0006625: Sampling rate of modes - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Continuous signal support (ES 202 786)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006625Ext Pack: Continuous signal support (ES 202 786)Clarificationpublic07-10-2013 13:3720-06-2014 10:31
ReporterTomas Urban 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv1.1.1 (published 2012-04) 
Target Versionv1.3.1 (published 2015-06)Fixed in Version 
Summary0006625: Sampling rate of modes
DescriptionThe current specification doesn't give clear guidelines whether it is possible to change a sampling rate of modes by the means of the stepsize parameter or whether sampling always occurs at basic sampling rate.
+
+The chapter 5.1.2 says that "in addition, sampling rates can
+be set separately and as part of the test specification by means of stepsize attribute." That would point out to the possibility that any sampling rate can be changed, including the one used in modes.
+
+However, the following paragraph mentions only port sampling rates: "This number (i.e. the value associated with the stepsize parameter) interpreted as seconds is used as the default rate of sampling values over the stream ports to which are affected by this stepsize attribute."
+
+In my opinion, the specification should explicitly specify if the stepsize attribute affects modes or not to prevent possible misinterpretation and one of the following rules shall be added to the specification:
+
+1. (This number interpreted as seconds is used ... over the stream ports) and the sampling rate of modes (which are affected by this attribute).
+2. The stepsize attribute has no effect on sampling procedure of modes; mode sampling rate is always equal to the basic rate of the concrete test system.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR6625-Resolution-V1.doc (228,352) 10-10-2013 16:19
http://oldforge.etsi.org/mantis/file_download.php?file_id=2922&type=bug
docx CR6625_v2.docx (72,484) 20-06-2014 10:27
http://oldforge.etsi.org/mantis/file_download.php?file_id=3071&type=bug
Issue History
Date ModifiedUsernameFieldChange
07-10-2013 13:37Tomas UrbanNew Issue
07-10-2013 13:37Tomas UrbanClause Reference(s) => 5.4
07-10-2013 13:37Tomas UrbanSource (company - Author) => Elvior
07-10-2013 13:37Tomas UrbanTS version => 1.2.1
07-10-2013 13:39Tomas UrbanNote Added: 0011686
07-10-2013 14:18Gyorgy RethyNote Added: 0011688
07-10-2013 14:18Gyorgy RethyAssigned To => Jens Grabowski
07-10-2013 14:18Gyorgy RethyStatusnew => assigned
07-10-2013 14:18Gyorgy RethyTarget Version => v1.3.1 (published 2015-06)
07-10-2013 14:18Gyorgy RethyProjectExt Pack: Config & Deployment Support (ES 202 781) => Ext Pack: Continuous signal support (ES 202 786)
07-10-2013 14:19Gyorgy RethyProduct Versionv1.2.1 (published 2013-06) =>
07-10-2013 14:19Gyorgy RethyTarget Versionv1.3.1 (published 2015-06) => v1.2.1 (published 2014-06)
10-10-2013 16:19Jens GrabowskiFile Added: CR6625-Resolution-V1.doc
10-10-2013 16:20Jens GrabowskiNote Added: 0011759
10-10-2013 16:20Jens GrabowskiAssigned ToJens Grabowski => Jacob Wieland - Spirent
11-10-2013 12:33Jacob Wieland - SpirentNote Added: 0011774
11-10-2013 12:37Jacob Wieland - SpirentNote Edited: 0011774
11-10-2013 12:38Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Jens Grabowski
11-10-2013 12:38Jacob Wieland - SpirentStatusassigned => confirmed
11-10-2013 13:56Tomas UrbanNote Added: 0011780
14-10-2013 13:45Jacob Wieland - SpirentNote Added: 0011806
14-10-2013 14:17Tomas UrbanNote Added: 0011807
08-04-2014 10:42Jens GrabowskiAssigned ToJens Grabowski => Tomas Urban
08-04-2014 10:42Jens GrabowskiStatusconfirmed => assigned
08-04-2014 17:09Gyorgy RethyProduct Version => v1.1.1 (published 2012-04)
08-04-2014 17:09Gyorgy RethyTarget Versionv1.2.1 (published 2014-06) => v1.3.1 (published 2015-06)
09-04-2014 15:50Tomas UrbanFile Added: CR6625_v1.docx
09-04-2014 15:50Tomas UrbanFile Deleted: CR6625_v1.docx
09-04-2014 15:51Tomas UrbanFile Added: CR6670_v2.docx
09-04-2014 15:58Tomas UrbanNote Added: 0011975
09-04-2014 15:58Tomas UrbanAssigned ToTomas Urban => Jens Grabowski
10-04-2014 11:14Tomas UrbanStatusassigned => confirmed
20-06-2014 10:25Tomas UrbanFile Deleted: CR6670_v2.docx
20-06-2014 10:27Tomas UrbanFile Added: CR6625_v2.docx
20-06-2014 10:31Jens GrabowskiNote Added: 0012182
20-06-2014 10:31Jens GrabowskiStatusconfirmed => closed
20-06-2014 10:31Jens GrabowskiResolutionopen => fixed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011686) +
+ Tomas Urban    +
+ 07-10-2013 13:39    +
+ 		+ + + + +
+ I am sorry for entering this issue under a wrong specification. It belongs to continuous signalling extension package.
+
+
+
+ + + + + + + + + + +
+ (0011688) +
+ Gyorgy Rethy    +
+ 07-10-2013 14:18    +
+ 		+ + + + +
+ Pls. Jens, look at this as well.
+
+
+
+ + + + + + + + + + +
+ (0011759) +
+ Jens Grabowski    +
+ 10-10-2013 16:20    +
+ 		+ + + + +
+ Proposal for Tomas ok, assigned to Jacob for cross-checking.
+
+
+
+ + + + + + + + + + +
+ (0011774) +
+ Jacob Wieland - Spirent    +
+ 11-10-2013 12:33    +
(edited on: 11-10-2013 12:37)
+ 		+ + + + +
+ There is, in my opinion, no sampling rate for modes. The only things that are sampled are stream ports. Their sampling activates mode-steps which then use the latest sampling values.
+
+It is even conceptually. allowed to have modes which work on ports with different sampling rates. The mode, in essence is not an active entity, but a passive one which is event-and-sampling-driven.
+
+Thus, I think the CR is invalid and should be rejected.
+
+
+
+
+
+ + + + + + + + + + +
+ (0011780) +
+ Tomas Urban    +
+ 11-10-2013 13:56    +
+ 		+ + + + +
+ I am afraid that I absolutely disagree with this explanation. I couldn't find a single word in the current specification saying that modes are passive event-driven entities.
+
+All that I can read from the specification is that while a mode is active, its content is executed periodically, once each sampling step. Please notice that the specification even explicitely uses word "active" when describing mode behaviour.
+
+In addition to that, current rules contained in the chapter of modes refer simply to "sampling step" without saying that it is actually a sampling step related to ports referenced inside mode statements. The current specification also doesn't say anything about dependency of sampling on events which you offer as an alternative trigger for mode activity.
+
+Besides, there are practical problems related to the passive approach:
+1. Modes can be defined without refering any port or trigger event. What would be the sampling step then?
+2. Relevant ports (used in invariants and until guards) might be hidden behind functions containing runtime-evaluated branchinch statements. Gathering port references from these functions calls requires very complex analysis of the runtime code and might be practically impossible in some cases.
+
+
+
+ + + + + + + + + + +
+ (0011806) +
+ Jacob Wieland - Spirent    +
+ 14-10-2013 13:45    +
+ 		+ + + + +
+ As I was highly involved in the conception of the continuous package, I can assure you that there was never any concept of sampling rate of modes intended. They shall only be activated by ports being sampled or other non-periodic events (like message reception) they wait for.
+
+The only things that are supposed to have sampling rates are the ports which then, when used by the modes, inflict an (implicit) sampling rate per mode, but, if the mode uses more than one port with different sampling rates, the activation of the modes by the ports is very arbitrary and has nothing much to do with a 'rate' anymore.
+
+If our intention is not clear from the text, that needs to be clarified, but not by introducing concepts that clearly contradict our intention.
+
+
+
+ + + + + + + + + + +
+ (0011807) +
+ Tomas Urban    +
+ 14-10-2013 14:17    +
+ 		+ + + + +
+ Jacob, thank you for explanation. I have no problem with this concept, but I am afraid that the impression one can have from the the current text is that mode is an active statement whose stepsize can be set. At least I had this impression.
+
+Actually, if the specification clearly stated that modes are always sampled using the base sampling rate, the concept of activity or passivity would be irrelevant, because port sampling rates are required to be multiples of the base sampling rate (there would be still differences e.g. in logging output, but similar differences occur during taking snapshots in alt statements and they do not affect test results). Such a rule (or similar) would be in line with the general approach used in the TTCN-3 specification: to introduce theoretical concepts rather than include implementaion details.
+
+I would also appreciate if the specification contained operational semantics for mode statements. These statements are quite complicated and different from those known from standard programming languages. Operational semantics would provide the reader with schematic description of the concept and it could prevent misunderstandings of this kind.
+
+
+
+ + + + + + + + + + +
+ (0011975) +
+ Tomas Urban    +
+ 09-04-2014 15:58    +
+ 		+ + + + +
+ New draft created according to Jacob's comments. It contains a rule that modes alway use the base sampling and that the stepsize attribute doesn't have any effect. In addition, there's a note saying that mode sampling is just a theoretical concept, not a prescription for implementation and that implementation details might differ. Jacob's sample of passive approach with triggers is used as an example of possible implementation.
+
+I hope the rules written this way are acceptable for everyone.
+Jens, could you please check the resolution?
+
+
+
+ + + + + + + + + + +
+ (0012182) +
+ Jens Grabowski    +
+ 20-06-2014 10:31    +
+ 		+ + + + +
+ Implemented as proposed in the latest resolution proposal (V2).
+
+ + diff --git a/docs/mantis/CR6626.md b/docs/mantis/CR6626.md new file mode 100644 index 0000000000000000000000000000000000000000..95009d39705008cbe80d4acd113e0d1fc6d1ac64 --- /dev/null +++ b/docs/mantis/CR6626.md @@ -0,0 +1,102 @@ + + + + + + + + + + + + + 0006626: Continuous signalling: restriction on blocking operations in modes - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Continuous signal support (ES 202 786)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006626Ext Pack: Continuous signal support (ES 202 786)Clarificationpublic07-10-2013 14:1220-06-2014 10:14
ReporterTomas Urban 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv1.1.1 (published 2012-04) 
Target Versionv1.3.1 (published 2015-06)Fixed in Version 
Summary0006626: Continuous signalling: restriction on blocking operations in modes
DescriptionThe current specification contains several identical restrictions forbidding the use of blocking statements in various sections of mode statements. I found two issues concerning these rules:
+
+1. The rules don't include functions called from these places, thus an additional rule shall be added saying that functions invoked from modes cannot contain blocking statements and also modes. (Because that would mess up the sampling mechanism. For the same reasons, modes are forbidden in the cont statement).
+
+2. The rule shall be general for the whole mode statement. Currently it is used in places where blocking operations are syntactically possible. However, when functions mentioned in the previous point are considered, it should be added to more places, such as guards of the until block and invariant statements. In my opinion, it is better to create a general rule with one notable exception - the trigger part of the until statement (in which case the "blocking" commands are actually not causing real blocking)
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR6626_v1.docx (23,104) 09-04-2014 16:31
http://oldforge.etsi.org/mantis/file_download.php?file_id=2985&type=bug
Issue History
Date ModifiedUsernameFieldChange
07-10-2013 14:12Tomas UrbanNew Issue
07-10-2013 14:12Tomas UrbanClause Reference(s) => 5.4.1
07-10-2013 14:12Tomas UrbanSource (company - Author) => Elvior
07-10-2013 14:18Gyorgy RethyProjectTTCN-3 Change Requests => Ext Pack: Continuous signal support (ES 202 786)
07-10-2013 14:19Gyorgy RethyAssigned To => Jens Grabowski
07-10-2013 14:19Gyorgy RethyStatusnew => assigned
07-10-2013 14:19Gyorgy RethyTarget Version => v1.2.1 (published 2014-06)
08-04-2014 12:06Jens GrabowskiAssigned ToJens Grabowski => Tomas Urban
08-04-2014 17:11Gyorgy RethyProduct Version => v1.1.1 (published 2012-04)
08-04-2014 17:11Gyorgy RethyTarget Versionv1.2.1 (published 2014-06) => v1.3.1 (published 2015-06)
09-04-2014 16:31Tomas UrbanFile Added: CR6626_v1.docx
09-04-2014 16:34Tomas UrbanNote Added: 0011976
09-04-2014 16:34Tomas UrbanAssigned ToTomas Urban => Jens Grabowski
10-04-2014 11:14Tomas UrbanStatusassigned => confirmed
20-06-2014 10:14Jens GrabowskiNote Added: 0012179
20-06-2014 10:14Jens GrabowskiStatusconfirmed => closed
20-06-2014 10:14Jens GrabowskiResolutionopen => fixed
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011976) +
+ Tomas Urban    +
+ 09-04-2014 16:34    +
+ 		+ + + + +
+ Resolution uploaded.
+Please check.
+
+
+
+ + + + + + + + + + +
+ (0012179) +
+ Jens Grabowski    +
+ 20-06-2014 10:14    +
+ 		+ + + + +
+ Implemented as proposed in Draft of next version.
+
+ + diff --git a/docs/mantis/CR6627.md b/docs/mantis/CR6627.md new file mode 100644 index 0000000000000000000000000000000000000000..51b9a98fcc3e354a47691965c82d9a989380728d --- /dev/null +++ b/docs/mantis/CR6627.md @@ -0,0 +1,167 @@ + + + + + + + + + + + + + 0006627: Continuous signalling: wait inside mode statement - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Continuous signal support (ES 202 786)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006627Ext Pack: Continuous signal support (ES 202 786)Technicalpublic07-10-2013 14:3926-12-2013 12:54
ReporterTomas Urban 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv1.2.1 (published 2014-06)Fixed in Version 
Summary0006627: Continuous signalling: wait inside mode statement
DescriptionThe wait command is not a traditional blocking operation as it cannot be used as an alternative inside alt statements. However, when used inside mode statements, it might lead to skipping next sampling steps, which is exactly the reason why blocking operations cannot be used in these places. In my opinion, the use of the wait statement shall be forbidden for the same reason inside mode statements as well.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR6627-Res-V1-131008.doc (84,480) 08-10-2013 17:48
http://oldforge.etsi.org/mantis/file_download.php?file_id=2898&type=bug
doc CR6627-Res-V2.doc (85,504) 09-10-2013 08:48
http://oldforge.etsi.org/mantis/file_download.php?file_id=2901&type=bug
doc CR6627-Res-V3.doc (79,360) 09-10-2013 10:11
http://oldforge.etsi.org/mantis/file_download.php?file_id=2905&type=bug
doc CR6627-Res-V4.doc (86,528) 09-10-2013 10:56
http://oldforge.etsi.org/mantis/file_download.php?file_id=2908&type=bug
Issue History
Date ModifiedUsernameFieldChange
07-10-2013 14:39Tomas UrbanNew Issue
07-10-2013 14:39Tomas UrbanClause Reference(s) => 5.4.1
07-10-2013 14:39Tomas UrbanSource (company - Author) => Elvior
08-10-2013 10:40Gyorgy RethyProjectTTCN-3 Change Requests => Ext Pack: Continuous signal support (ES 202 786)
08-10-2013 10:41Gyorgy RethyAssigned To => Jens Grabowski
08-10-2013 10:41Gyorgy RethyStatusnew => assigned
08-10-2013 10:41Gyorgy RethyTarget Version => v1.2.1 (published 2014-06)
08-10-2013 17:48Jens GrabowskiFile Added: CR6627-Res-V1-131008.doc
08-10-2013 17:49Jens GrabowskiNote Added: 0011710
08-10-2013 17:49Jens GrabowskiAssigned ToJens Grabowski => Jacob Wieland - Spirent
09-10-2013 08:48Jacob Wieland - SpirentFile Added: CR6627-Res-V2.doc
09-10-2013 08:50Jacob Wieland - SpirentNote Added: 0011717
09-10-2013 08:50Jacob Wieland - SpirentStatusassigned => confirmed
09-10-2013 08:51Jacob Wieland - SpirentStatusconfirmed => assigned
09-10-2013 08:51Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Jens Grabowski
09-10-2013 08:51Jacob Wieland - SpirentStatusassigned => confirmed
09-10-2013 10:11Jens GrabowskiFile Added: CR6627-Res-V3.doc
09-10-2013 10:12Jens GrabowskiNote Added: 0011721
09-10-2013 10:12Jens GrabowskiStatusconfirmed => resolved
09-10-2013 10:12Jens GrabowskiResolutionopen => fixed
09-10-2013 10:55Jacob Wieland - SpirentAssigned ToJens Grabowski => Jacob Wieland - Spirent
09-10-2013 10:55Jacob Wieland - SpirentStatusresolved => feedback
09-10-2013 10:55Jacob Wieland - SpirentResolutionfixed => reopened
09-10-2013 10:56Jacob Wieland - SpirentNote Added: 0011724
09-10-2013 10:56Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Jens Grabowski
09-10-2013 10:56Jacob Wieland - SpirentStatusfeedback => confirmed
09-10-2013 10:56Jacob Wieland - SpirentFile Added: CR6627-Res-V4.doc
09-10-2013 12:19Jens GrabowskiStatusconfirmed => resolved
09-10-2013 12:19Jens GrabowskiResolutionreopened => fixed
26-12-2013 12:54Jens GrabowskiStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011710) +
+ Jens Grabowski    +
+ 08-10-2013 17:49    +
+ 		+ + + + +
+ Resolution attached.
+
+Assigned to Jacob for cross-checking.
+
+
+
+ + + + + + + + + + +
+ (0011717) +
+ Jacob Wieland - Spirent    +
+ 09-10-2013 08:50    +
+ 		+ + + + +
+ I also excluded timout, done, killed and modes themselves and generalized to receiving operations (which subsumes receive,getcall,getreply,catch,trigger,check). Excluding alt and interleave is not necessary as they would need at least one of the above. so they are excluded implicitly.
+
+
+
+ + + + + + + + + + +
+ (0011721) +
+ Jens Grabowski    +
+ 09-10-2013 10:12    +
+ 		+ + + + +
+ Wording in V3 slightly changed.
+
+
+
+ + + + + + + + + + +
+ (0011724) +
+ Jacob Wieland - Spirent    +
+ 09-10-2013 10:56    +
+ 		+ + + + +
+ added plural-s to statement
+
+ + diff --git a/docs/mantis/CR6628.md b/docs/mantis/CR6628.md new file mode 100644 index 0000000000000000000000000000000000000000..a47328ad68cab87f8988c5c282cbd4f5157778c3 --- /dev/null +++ b/docs/mantis/CR6628.md @@ -0,0 +1,139 @@ + + + + + + + + + + + + + 0006628: Continuous signalling: TRI and TCI mapping - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Continuous signal support (ES 202 786)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006628Ext Pack: Continuous signal support (ES 202 786)Technicalpublic07-10-2013 14:4404-01-2014 11:37
ReporterTomas Urban 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv1.2.1 (published 2014-06)Fixed in Versionv1.2.1 (published 2014-06) 
Summary0006628: Continuous signalling: TRI and TCI mapping
DescriptionThe continuous signalling extension package should contain standardized mapping of TRI and TCI extensions to C, C++, java, C# and W3C XML as it the case of other extension packages.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR6628.docx (73,676) 10-10-2013 12:51
http://oldforge.etsi.org/mantis/file_download.php?file_id=2919&type=bug
doc CR6635-6630-6627-6621-6620-6618-6617-6609-6520-6519-6518-6517-6516-Editorial-6628.doc (839,168) 23-12-2013 13:11
http://oldforge.etsi.org/mantis/file_download.php?file_id=2971&type=bug
doc MTS-202786ContSign ed121v001_v2.doc (867,328) 03-01-2014 15:33
http://oldforge.etsi.org/mantis/file_download.php?file_id=2974&type=bug
doc MTS-202786ContSign ed121v001_v3.doc (873,472) 04-01-2014 11:36
http://oldforge.etsi.org/mantis/file_download.php?file_id=2975&type=bug
Issue History
Date ModifiedUsernameFieldChange
07-10-2013 14:44Tomas UrbanNew Issue
07-10-2013 14:44Tomas UrbanClause Reference(s) => 6
07-10-2013 14:44Tomas UrbanSource (company - Author) => Elvior
08-10-2013 10:45Gyorgy RethyProjectTTCN-3 Change Requests => Ext Pack: Continuous signal support (ES 202 786)
08-10-2013 10:47Gyorgy RethyAssigned To => Ina Schieferdecker
08-10-2013 10:47Gyorgy RethyStatusnew => assigned
08-10-2013 10:47Gyorgy RethyTarget Version => v1.2.1 (published 2014-06)
10-10-2013 12:51Ina SchieferdeckerFile Added: CR6628.docx
10-10-2013 12:51Ina SchieferdeckerNote Added: 0011748
10-10-2013 12:51Ina SchieferdeckerAssigned ToIna Schieferdecker => Jens Grabowski
10-10-2013 12:51Ina SchieferdeckerStatusassigned => confirmed
23-12-2013 13:10Ina SchieferdeckerStatusconfirmed => resolved
23-12-2013 13:10Ina SchieferdeckerResolutionopen => fixed
23-12-2013 13:10Ina SchieferdeckerFixed in Version => v1.2.1 (published 2014-06)
23-12-2013 13:11Ina SchieferdeckerFile Added: CR6635-6630-6627-6621-6620-6618-6617-6609-6520-6519-6518-6517-6516-Editorial-6628.doc
26-12-2013 12:55Jens GrabowskiStatusresolved => closed
03-01-2014 15:33Ina SchieferdeckerFile Added: MTS-202786ContSign ed121v001_v2.doc
03-01-2014 15:38Ina SchieferdeckerNote Added: 0011911
04-01-2014 11:36Ina SchieferdeckerFile Added: MTS-202786ContSign ed121v001_v3.doc
04-01-2014 11:37Ina SchieferdeckerNote Added: 0011912
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011748) +
+ Ina Schieferdecker    +
+ 10-10-2013 12:51    +
+ 		+ + + + +
+ Please check
+
+
+
+ + + + + + + + + + +
+ (0011911) +
+ Ina Schieferdecker    +
+ 03-01-2014 15:38    +
+ 		+ + + + +
+ TRI mappings added and corrected
+
+
+
+ + + + + + + + + + +
+ (0011912) +
+ Ina Schieferdecker    +
+ 04-01-2014 11:37    +
+ 		+ + + + +
+ Some final corrections by Tomas Urban:
+
+1. The most serious one concerns C# mapping of the ITriPlatformTE interface. The content of the interface was a copy of the ITriPlatformPA interface - corrected now.
+
+2. The header of the chapter 6.12 contains a reference to 9.5.2.4 instead of 6.5.3.2 (which is java mapping) now.
+
+3. In the draft C# mapping, all methods started with a small letter, while the common naming convention (also used in TRI and TCI specifications) uses capital letters. There was also a mispelled interface name (TriMessage instead of ITriMessage) in parameter mapping.
+
+4. Like the original C mapping, the C++ mapping used pointers to timestamps in triStartClock, triNextSampling and triBeginWait. However, as input parameters, these values should be passed by value. (Only triReadClock should pass the timestamp as a pointer).
+
+ + diff --git a/docs/mantis/CR6629.md b/docs/mantis/CR6629.md new file mode 100644 index 0000000000000000000000000000000000000000..66ce3e9a73da6ffe9783a47d2a2532ea8733516c --- /dev/null +++ b/docs/mantis/CR6629.md @@ -0,0 +1,325 @@ + + + + + + + + + + + + + 0006629: Continuous signalling: unnecessary address parameter in TRI - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Continuous signal support (ES 202 786)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006629Ext Pack: Continuous signal support (ES 202 786)Technicalpublic07-10-2013 14:4806-01-2015 16:58
ReporterTomas Urban 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv1.1.1 (published 2012-04) 
Target Versionv1.3.1 (published 2015-06)Fixed in Version 
Summary0006629: Continuous signalling: unnecessary address parameter in TRI
DescriptionThe triSetStreamValue and triGetStreamValue contain an address parameter, but this parameter cannot be set in TTCN-3 code, because unlike the send/receive commands, the value operator doesn't contain any address part. I propose to remove the parameter from both TRI functions.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR6629.docx (22,239) 09-10-2013 14:29
http://oldforge.etsi.org/mantis/file_download.php?file_id=2911&type=bug
docx CR6629_v2.docx (60,321) 08-10-2014 15:25
http://oldforge.etsi.org/mantis/file_download.php?file_id=3116&type=bug
Issue History
Date ModifiedUsernameFieldChange
07-10-2013 14:48Tomas UrbanNew Issue
07-10-2013 14:48Tomas UrbanClause Reference(s) => 6.7, 6,8
07-10-2013 14:48Tomas UrbanSource (company - Author) => Elvior
08-10-2013 10:45Gyorgy RethyProjectTTCN-3 Change Requests => Ext Pack: Config & Deployment Support (ES 202 781)
08-10-2013 10:47Gyorgy RethyAssigned To => Ina Schieferdecker
08-10-2013 10:47Gyorgy RethyStatusnew => assigned
08-10-2013 10:47Gyorgy RethyTarget Version => v1.3.1 (published 2015-06)
08-10-2013 11:19Ina SchieferdeckerProjectExt Pack: Config & Deployment Support (ES 202 781) => Ext Pack: Continuous signal support (ES 202 786)
09-10-2013 12:22Ina SchieferdeckerNote Added: 0011727
09-10-2013 12:26Ina SchieferdeckerNote Edited: 0011727
09-10-2013 12:49Tomas UrbanNote Added: 0011729
09-10-2013 14:08Ina SchieferdeckerNote Edited: 0011727
09-10-2013 14:23Ina SchieferdeckerNote Added: 0011732
09-10-2013 14:29Ina SchieferdeckerFile Added: CR6629.docx
09-10-2013 15:07Ina SchieferdeckerNote Added: 0011733
09-10-2013 15:07Ina SchieferdeckerAssigned ToIna Schieferdecker => Jens Grabowski
09-10-2013 15:07Ina SchieferdeckerStatusassigned => confirmed
07-04-2014 10:44Jens GrabowskiNote Added: 0011931
08-04-2014 10:45Jens GrabowskiAssigned ToJens Grabowski => Tomas Urban
08-04-2014 10:45Jens GrabowskiStatusconfirmed => assigned
08-04-2014 17:10Gyorgy RethyProduct Version => v1.1.1 (published 2012-04)
10-04-2014 14:30Tomas UrbanNote Added: 0012010
08-10-2014 14:16Tomas UrbanNote Edited: 0012010bug_revision_view_page.php?bugnote_id=12010#r79
08-10-2014 15:25Tomas UrbanFile Added: CR6629_v2.docx
08-10-2014 15:44Tomas UrbanNote Added: 0012287
08-10-2014 15:44Tomas UrbanAssigned ToTomas Urban => Jens Grabowski
08-10-2014 15:44Tomas UrbanStatusassigned => confirmed
06-01-2015 16:58Jens GrabowskiNote Added: 0012641
06-01-2015 16:58Jens GrabowskiStatusconfirmed => closed
06-01-2015 16:58Jens GrabowskiResolutionopen => fixed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011727) +
+ Ina Schieferdecker    +
+ 09-10-2013 12:22    +
(edited on: 09-10-2013 14:08)
+ 		+ + + + +
+ We suggest to do the opposite: add the optional [to/from Address] to the apply and to the value operation. Reasoning: also a stream port could be on adapter level a "multiplex interface" which requires additional addressing.
+
+
+
+
+
+ + + + + + + + + + +
+ (0011729) +
+ Tomas Urban    +
+ 09-10-2013 12:49    +
+ 		+ + + + +
+ I am afraid such an approach causes several new problems:
+1. Why multicast is not allowed? And if it is allowed, it requires additional functions in the TRI.
+2. Addressing would then make sense for streaming to connected ports, so components should be allowed in the to clause as well.
+3. Value operation used for reading should not contain "to", because the address in this case contains the sender, not the recepient. The core language specification uses the sender clause for this purpose, but no statement using it can be present on the right hand side of an assignment which might lead to trouble finding suitable syntax (myStreamVal := p1.value -> sender myAddr doesn't look very nice).
+4. It also requires update of the data stream structures, because addresses have to be stored for each sample. That means changing many parts of the existing specification.
+
+
+
+ + + + + + + + + + +
+ (0011732) +
+ Ina Schieferdecker    +
+ 09-10-2013 14:23    +
+ 		+ + + + +
+ Right, we do not add multicasting with this!
+The solution is just about differentiating entities within the SUT that can be reached from the very same stream port. This is just the basic addressing concept of TTCN-3.
+I will upload a draft in a couple of minutes.
+
+
+
+ + + + + + + + + + +
+ (0011733) +
+ Ina Schieferdecker    +
+ 09-10-2013 15:07    +
+ 		+ + + + +
+ Please check
+
+
+
+ + + + + + + + + + +
+ (0011931) +
+ Jens Grabowski    +
+ 07-04-2014 10:44    +
+ 		+ + + + +
+ Tomas will check the drafts for changes made by Ina with regard to this CR.
+
+
+
+ + + + + + + + + + +
+ (0012010) +
+ Tomas Urban    +
+ 10-04-2014 14:30    +
(edited on: 08-10-2014 14:16)
+ 		+ + + + +
+ I still don't understand how addressing should work in case of the value operation. The value operation doesn't work like the receive operation. It is non-blocking and it returns a value. The current proposal seems to ignore this fact adding matching features to it without explaining consequences of a mismatch. In addition to that, the value operation can occur on the LHS and it would therefore make sense to allow addressing in this case too.
+
+In my opinion, if addressing is to be used, it shall be done differently, e.g. by introducing an address operation for streaming ports. This operation would have the same scope as the value operation, i.e. it could be used both on LHS and RHS. When used on the RHS, it would return the address acquired during the last sampling step (or null if the SA didn't provide any address) and when used on the LHS, if would set the address for the next sampling step.
+
+The specification has to deal with the fact that addresses are bound to individual sampling steps (as the address might change during the progress of a test case) and there should be a way how to get and set addresses for multiple steps. Modifying the sample data structure is probably not the best approach as this would cause backwards incompatibility. One possible solution is to define the get operations by combining the address keyword with history and values keywords:
+streamport.address history(StartTime, EndTime); // returns record of address and timestamp pairs
+streamport.address values(StartTime, EndTime); // returns record of addresses
+
+The apply clause can be left as specified in the current proposal, with an additional option to use a record of addresses instead of a single address in order specify addresses for each individual step. In this case, the number of addresses must be equal to the number of items in the record of samples. Using a single address instead or a list would mean using the same address for all steps.
+
+-> The CR requires to be discussed by the STF.
+
+
+
+
+
+ + + + + + + + + + +
+ (0012287) +
+ Tomas Urban    +
+ 08-10-2014 15:44    +
+ 		+ + + + +
+ I still think the original solution for this CR is not correct because of the reasons mentioned in my previous comments. However, introducing addresses as a third element of the sample record seems like overkill for resolving this rather minor issue. It would require quite a big set of new rules and significant changes in the TTCN-3 tools.
+
+In my opinion, stream ports are not likely to change the address of the monitored stream in the SUT after their are connected with it. And because this connection is made by the map operation, all the necessary information for locating the SUT stream can be passed by map parameters.
+
+For that reason, I added syntactical support for this feature (and also unmap parameters) to the new proposal. These parameters are well known from the core language specification and it should not be very difficult for the vendors to implement them. The proposal also removes addresses from the TRI part of the specification.
+
+
+
+ + + + + + + + + + +
+ (0012641) +
+ Jens Grabowski    +
+ 06-01-2015 16:58    +
+ 		+ + + + +
+ Implemented according to proposal
+
+ + diff --git a/docs/mantis/CR6630.md b/docs/mantis/CR6630.md new file mode 100644 index 0000000000000000000000000000000000000000..aa24853ae0efa40902ea7bb3104e13d56ffeae16 --- /dev/null +++ b/docs/mantis/CR6630.md @@ -0,0 +1,190 @@ + + + + + + + + + + + + + 0006630: Continuous signalling: withdrawing BNF support for labels in the par statement - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - TTCN-3 Change Requests
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006630TTCN-3 Change RequestsTechnicalpublic07-10-2013 14:5826-12-2013 12:54
ReporterTomas Urban 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Clause Reference(s)A.2
For STF discussion
Source (company - Author)Elvior
Summary0006630: Continuous signalling: withdrawing BNF support for labels in the par statement
DescriptionThe BNF allows to declare labels inside the par statement body. However, it is not possible to jump to these labels because of a restriction on the use of the goto command in par statements (see 5.4.1.1.2 for more details). I don't think it is wise to support syntax that has no useful meaning and therefore I propose to change the BNF so that the labels are syntactically allowed only inside the seq statement:
+
+51.ModeSpecification ::= ( BasicMode | SeqMode | ParMode ) [ UntilBlock ]
+62a. SeqMode ::= SeqKeyword " {" {VarInstance}
+[OnEntryBlock]
+[InvariantBlock]
+ModeList
+[OnExitBlock]
+" }"
+62b.ParMode ::= ParKeyword " {" {VarInstance}
+[OnEntryBlock]
+[InvariantBlock]
+{ ModeSpecification }
+[OnExitBlock]
+" }"
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR6630-Res-V1-131008.doc (118,784) 08-10-2013 10:53
http://oldforge.etsi.org/mantis/file_download.php?file_id=2895&type=bug
Issue History
Date ModifiedUsernameFieldChange
07-10-2013 14:58Tomas UrbanNew Issue
07-10-2013 14:58Tomas UrbanClause Reference(s) => A.2
07-10-2013 14:58Tomas UrbanSource (company - Author) => Elvior
08-10-2013 09:13Tomas UrbanNote Added: 0011695
08-10-2013 10:09Jens GrabowskiStatusnew => assigned
08-10-2013 10:09Jens GrabowskiAssigned To => Jens Grabowski
08-10-2013 10:53Jens GrabowskiNote Added: 0011698
08-10-2013 10:53Jens GrabowskiFile Added: CR6630-Res-V1-131008.doc
08-10-2013 10:53Jens GrabowskiAssigned ToJens Grabowski => Jacob Wieland - Spirent
08-10-2013 11:15Jacob Wieland - SpirentNote Added: 0011699
08-10-2013 11:17Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Jens Grabowski
08-10-2013 11:17Jacob Wieland - SpirentStatusassigned => confirmed
08-10-2013 11:34Tomas UrbanNote Added: 0011701
26-12-2013 12:54Jens GrabowskiStatusconfirmed => closed
26-12-2013 12:54Jens GrabowskiResolutionopen => fixed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011695) +
+ Tomas Urban    +
+ 08-10-2013 09:13    +
+ 		+ + + + +
+ I also noticed there's no semicolon separator support inside complex modes, so the rules so the rule for the par statement should be:
+62b.ParMode ::= ParKeyword "{" {VarInstance}
+[OnEntryBlock]
+[InvariantBlock]
+{ ModeSpecification [SemiColon] }
+[OnExitBlock]
+"}"
+
+and the rule 65 should be:
+65.ModeList ::= { [LabelStatement [SemiColon] ] ModeSpecification [SemiColon]}
+
+
+
+ + + + + + + + + + +
+ (0011698) +
+ Jens Grabowski    +
+ 08-10-2013 10:53    +
+ 		+ + + + +
+ Implemented according to proposal of Tomas.
+
+Assigned to Jacob for cross-checking.
+
+
+
+ + + + + + + + + + +
+ (0011699) +
+ Jacob Wieland - Spirent    +
+ 08-10-2013 11:15    +
+ 		+ + + + +
+ In principle okay, but I don't think we need the semicolons (except for the label statement where it should be mandatory according to the normal semicolon rules) as there can never be any ambiguity which needs to be resolved with the semicolon (all modes end with a closing bracket which makes the semicolon superfluous).
+
+
+
+ + + + + + + + + + +
+ (0011701) +
+ Tomas Urban    +
+ 08-10-2013 11:34    +
+ 		+ + + + +
+ All modes do not end with curly brackets: there might be parametrized mode instances inside complex modes (see e.g. example 2 in 5.4.5.2) and this is the reason why the second optional semicolon should be in the rule as well.
+
+ + diff --git a/docs/mantis/CR6631.md b/docs/mantis/CR6631.md new file mode 100644 index 0000000000000000000000000000000000000000..36fe3c6af2a5d8dae6f63a3af27ab8dadf6920a1 --- /dev/null +++ b/docs/mantis/CR6631.md @@ -0,0 +1,97 @@ + + + + + + + + + + + + + 0006631: tliPSetState in ANSI C Language Mapping - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Config & Deployment Support (ES 202 781)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006631Ext Pack: Config & Deployment Support (ES 202 781)Editorialpublic07-10-2013 15:1906-01-2016 09:26
ReporterIna Schieferdecker 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv1.3.1 (published 2014-06)Fixed in Version 
Clause Reference(s)8.8
Source (company - Author)Ina Schieferdecker, FOKUS
TS version
Summary0006631: tliPSetState in ANSI C Language Mapping
DescriptionThe extension for the ANSI C Language Mapping uses tliPSetStateKilled instead of tliPSetState - this is a simple fix to tliPSetState
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR6631.doc (171,008) 29-11-2013 13:08
http://oldforge.etsi.org/mantis/file_download.php?file_id=2964&type=bug
Issue History
Date ModifiedUsernameFieldChange
07-10-2013 15:19Ina SchieferdeckerNew Issue
07-10-2013 15:19Ina SchieferdeckerStatusnew => assigned
07-10-2013 15:19Ina SchieferdeckerAssigned To => Jens Grabowski
07-10-2013 15:19Ina SchieferdeckerClause Reference(s) => 8.8
07-10-2013 15:19Ina SchieferdeckerSource (company - Author) => Ina Schieferdecker, FOKUS
07-10-2013 15:20Ina SchieferdeckerProjectTTCN-3 Change Requests => Ext Pack: Config & Deployment Support (ES 202 781)
29-11-2013 13:08Jacob Wieland - SpirentFile Added: CR6631.doc
29-11-2013 13:09Jacob Wieland - SpirentNote Added: 0011871
29-11-2013 13:09Jacob Wieland - SpirentStatusassigned => confirmed
26-12-2013 13:54Jens GrabowskiNote Added: 0011904
26-12-2013 13:54Jens GrabowskiStatusconfirmed => closed
26-12-2013 13:54Jens GrabowskiResolutionopen => fixed
06-01-2016 09:26Gyorgy RethyTarget Version => v1.3.1 (published 2014-06)
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011871) +
+ Jacob Wieland - Spirent    +
+ 29-11-2013 13:09    +
+ 		+ + + + +
+ looks like a copy-paste error to me, fixed
+
+
+
+ + + + + + + + + + +
+ (0011904) +
+ Jens Grabowski    +
+ 26-12-2013 13:54    +
+ 		+ + + + +
+ Implemented as proposed.
+
+ + diff --git a/docs/mantis/CR6632.md b/docs/mantis/CR6632.md new file mode 100644 index 0000000000000000000000000000000000000000..c8f02f99217e964a66d2aaaa2e2d17ecf2ab68fe --- /dev/null +++ b/docs/mantis/CR6632.md @@ -0,0 +1,35 @@ + + + + + + + + + + + + + 0006632: Typo in clause title - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006632Part 06: TTCN-3 Control InterfaceEditorialpublic07-10-2013 15:2206-01-2016 09:12
ReporterIna Schieferdecker 
Assigned To 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.6.1 (published 2014-06)Fixed in Versionv4.6.1 (published 2014-06) 
Clause Reference(s)12.5.1.2
Source (company - Author)Ina Schieferdecker, FOKUS
Summary0006632: Typo in clause title
Description12.5.1.2 should read
+
+
+12.5.1.2 TCI-TM required
+The TCI-TM required interface is mapped to the following interface:
+
+(instead of provided)
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
07-10-2013 15:22Ina SchieferdeckerNew Issue
07-10-2013 15:22Ina SchieferdeckerStatusnew => assigned
07-10-2013 15:22Ina SchieferdeckerAssigned To => Ina Schieferdecker
07-10-2013 15:22Ina SchieferdeckerClause Reference(s) => 12.5.1.2
07-10-2013 15:22Ina SchieferdeckerSource (company - Author) => Ina Schieferdecker, FOKUS
07-10-2013 15:23Ina SchieferdeckerProjectTTCN-3 Change Requests => Part 06: TTCN-3 Control Interface
07-10-2013 15:42Ina SchieferdeckerStatusassigned => resolved
07-10-2013 15:42Ina SchieferdeckerFixed in Version => v4.6.1 (published 2014-06)
07-10-2013 15:42Ina SchieferdeckerResolutionopen => fixed
07-10-2013 15:42Ina SchieferdeckerStatusresolved => closed
06-01-2016 09:12Gyorgy RethyAssigned ToIna Schieferdecker =>
06-01-2016 09:12Gyorgy RethyTarget Version => v4.6.1 (published 2014-06)
+
+ + + + +
+ There are no notes attached to this issue.
+ + diff --git a/docs/mantis/CR6633.md b/docs/mantis/CR6633.md new file mode 100644 index 0000000000000000000000000000000000000000..da678022e92d732c062beceea00e56b943c6d2a9 --- /dev/null +++ b/docs/mantis/CR6633.md @@ -0,0 +1,63 @@ + + + + + + + + + + + + + 0006633: Continuous signalling: return value of TCI-CH functions - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Continuous signal support (ES 202 786)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006633Ext Pack: Continuous signal support (ES 202 786)Technicalpublic07-10-2013 15:5826-12-2013 12:51
ReporterTomas Urban 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv1.2.1 (published 2014-06)Fixed in Version 
Summary0006633: Continuous signalling: return value of TCI-CH functions
DescriptionIn the standard TCI specification (ETSI ES 201 873-6), TCI-CH functions that are in principle similar to the two TCI-CH functions introduced by the continuous signalling package (i.e. enqueue, send, call, reply and raise functions) do not use any return values. I think that the TCI-CH functions from the continuous signalling package should use the same paradigm.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0006637closed Jens Grabowski Missing TCI operations 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
07-10-2013 15:58Tomas UrbanNew Issue
07-10-2013 15:58Tomas UrbanClause Reference(s) => 7.1, 7.2
07-10-2013 15:58Tomas UrbanSource (company - Author) => Elvior
08-10-2013 10:46Gyorgy RethyProjectTTCN-3 Change Requests => Ext Pack: Continuous signal support (ES 202 786)
08-10-2013 10:46Gyorgy RethyAssigned To => Ina Schieferdecker
08-10-2013 10:46Gyorgy RethyStatusnew => assigned
08-10-2013 10:46Gyorgy RethyTarget Version => v1.2.1 (published 2014-06)
09-10-2013 15:06Ina SchieferdeckerAssigned ToIna Schieferdecker => Jens Grabowski
09-10-2013 15:06Ina SchieferdeckerStatusassigned => confirmed
10-10-2013 09:37Ina SchieferdeckerRelationship addedrelated to 0006637
10-10-2013 09:37Ina SchieferdeckerNote Added: 0011742
26-12-2013 12:51Jens GrabowskiStatusconfirmed => closed
26-12-2013 12:51Jens GrabowskiResolutionopen => fixed
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011742) +
+ Ina Schieferdecker    +
+ 10-10-2013 09:37    +
+ 		+ + + + +
+ See v2 of CR6637
+
+ + diff --git a/docs/mantis/CR6634.md b/docs/mantis/CR6634.md new file mode 100644 index 0000000000000000000000000000000000000000..035cee01f760eb033a8e917b6f6673f461aed489 --- /dev/null +++ b/docs/mantis/CR6634.md @@ -0,0 +1,98 @@ + + + + + + + + + + + + + 0006634: Real time & Perf: Editorials - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Perf & Real Time Testing (ES 202 782)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006634Ext Pack: Perf & Real Time Testing (ES 202 782)Editorialpublic07-10-2013 16:1126-12-2013 12:23
ReporterGyorgy Rethy 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv1.2.1 (published 2014-06)Fixed in Version 
Clause Reference(s)
Source (company - Author)
TS version
Summary0006634: Real time & Perf: Editorials
Description1. TTCN-3 Part-2 has been made historical, it has to be deleted from the references.
+2. Package compatibility needs to be amended: V4.2.1 is minimum requirement, but the package is also compatible with later versions; this requires update of the BNF additions to contain only the additional terminals.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR6634.doc (160,256) 28-11-2013 10:53
http://oldforge.etsi.org/mantis/file_download.php?file_id=2954&type=bug
Issue History
Date ModifiedUsernameFieldChange
07-10-2013 16:11Gyorgy RethyNew Issue
07-10-2013 16:11Gyorgy RethyAssigned To => Gyorgy Rethy
07-10-2013 16:11Gyorgy RethyStatusnew => assigned
07-10-2013 16:11Gyorgy RethyTarget Version => v1.2.1 (published 2014-06)
08-10-2013 11:47Gyorgy RethyProjectExt Pack: Continuous signal support (ES 202 786) => Ext Pack: Perf & Real Time Testing (ES 202 782)
08-10-2013 15:27Gyorgy RethyAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
28-11-2013 10:53Jacob Wieland - SpirentFile Added: CR6634.doc
28-11-2013 10:54Jacob Wieland - SpirentNote Added: 0011852
28-11-2013 10:54Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Jens Grabowski
28-11-2013 10:54Jacob Wieland - SpirentStatusassigned => confirmed
26-12-2013 11:05Jens GrabowskiNote Added: 0011894
26-12-2013 12:23Jens GrabowskiStatusconfirmed => closed
26-12-2013 12:23Jens GrabowskiResolutionopen => fixed
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011852) +
+ Jacob Wieland - Spirent    +
+ 28-11-2013 10:54    +
+ 		+ + + + +
+ please review
+
+
+
+ + + + + + + + + + +
+ (0011894) +
+ Jens Grabowski    +
+ 26-12-2013 11:05    +
+ 		+ + + + +
+ Implemented as proposed.
+
+ + diff --git a/docs/mantis/CR6635.md b/docs/mantis/CR6635.md new file mode 100644 index 0000000000000000000000000000000000000000..336b9fa1f08911f5e05938862c0e559184b64d20 --- /dev/null +++ b/docs/mantis/CR6635.md @@ -0,0 +1,126 @@ + + + + + + + + + + + + + 0006635: Continuous signalling: missing BNF rules - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Continuous signal support (ES 202 786)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006635Ext Pack: Continuous signal support (ES 202 786)Technicalpublic08-10-2013 08:5526-12-2013 12:53
ReporterTomas Urban 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv1.2.1 (published 2014-06)Fixed in Version 
Summary0006635: Continuous signalling: missing BNF rules
DescriptionThere are two important rules missing in the BNF section and one token has a misleading name.
+
+1) There's no rule allowing the use of modes in statements block. Proposal: insert a modification of the BNF rule 466 of the core language specification to the chapter A.1 as follows:
+
+466.BehaviourStatements ::= TestcaseInstance |
+FunctionInstance |
+ReturnStatement |
+AltConstruct |
+InterleavedConstruct |
+LabelStatement |
+GotoStatement |
+RepeatStatement |
+DeactivateStatement |
+AltstepInstance |
+ActivateOp |
+BreakStatement |
+ContinueStatement |
+ModeSpecification
+
+2) The token name ModeInstance used in the specification is misleading, because the rule 72 doesn't describe instance creation, but defines behaviour of a parameterized mode. Traditionally, this kind of statements are called definitions, therefore I propose to change the name of the token to ModeDef (see FunctionDef, TestCaseDef, AltstepDef etc. in the core language specification BNF).
+
+3) The BNF doesn't define a syntax for calling parameterized mode instances. This kind of mode instance usage is defined in the chapter 5.4.5.2 of the specification (see the "assertion" parameter in the example 2). Proposal: The current rule 51. should be modified to:
+
+51.ModeSpecification ::= (( BasicMode | ComplexMode ) [ UntilBlock ] ) | ModeInstance
+
+where mode instance is defined as:
+73. ModeInstance ::= ModeRef "(" [FunctionActualParList] ")"
+74. ModeRef ::= [Identifier Dot] Identifier
+
+Note: the term instance is used here in line with the terminology specified in the core language BNF (e.g. FunctionInstance, TestCaseInstance, AltstepInstance etc.)
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR6635-Res-V1-131009.doc (119,296) 09-10-2013 10:01
http://oldforge.etsi.org/mantis/file_download.php?file_id=2904&type=bug
doc CR6635-Res-V2.doc (124,416) 09-10-2013 10:48
http://oldforge.etsi.org/mantis/file_download.php?file_id=2907&type=bug
Issue History
Date ModifiedUsernameFieldChange
08-10-2013 08:55Tomas UrbanNew Issue
08-10-2013 08:55Tomas UrbanClause Reference(s) => A
08-10-2013 08:55Tomas UrbanSource (company - Author) => Elvior
08-10-2013 10:39Gyorgy RethyProjectTTCN-3 Change Requests => Ext Pack: Continuous signal support (ES 202 786)
08-10-2013 10:39Gyorgy RethyAssigned To => Jens Grabowski
08-10-2013 10:39Gyorgy RethyStatusnew => assigned
08-10-2013 10:39Gyorgy RethyTarget Version => v1.2.1 (published 2014-06)
09-10-2013 10:01Jens GrabowskiFile Added: CR6635-Res-V1-131009.doc
09-10-2013 10:02Jens GrabowskiNote Added: 0011720
09-10-2013 10:02Jens GrabowskiAssigned ToJens Grabowski => Jacob Wieland - Spirent
09-10-2013 10:49Jacob Wieland - SpirentFile Added: CR6635-Res-V2.doc
09-10-2013 10:49Jacob Wieland - SpirentNote Added: 0011723
09-10-2013 10:49Jacob Wieland - SpirentStatusassigned => confirmed
09-10-2013 10:50Jacob Wieland - SpirentStatusconfirmed => assigned
09-10-2013 10:50Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Jens Grabowski
09-10-2013 10:50Jacob Wieland - SpirentStatusassigned => confirmed
09-10-2013 14:25Jens GrabowskiStatusconfirmed => resolved
09-10-2013 14:25Jens GrabowskiResolutionopen => fixed
26-12-2013 12:53Jens GrabowskiStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011720) +
+ Jens Grabowski    +
+ 09-10-2013 10:02    +
+ 		+ + + + +
+ Jacob, please crosscheck (Note, the rule numbers are different to the ones mentioned in the CR as I used a version which already includes several BNF changes.)
+
+
+
+ + + + + + + + + + +
+ (0011723) +
+ Jacob Wieland - Spirent    +
+ 09-10-2013 10:49    +
+ 		+ + + + +
+ added missing ModuleDefinition rule which needs to be amended to include ModeDef as an alternative, otherwise okay
+
+ + diff --git a/docs/mantis/CR6636.md b/docs/mantis/CR6636.md new file mode 100644 index 0000000000000000000000000000000000000000..acfaaab47f112816779fc49edaf0d5cc56e4982f --- /dev/null +++ b/docs/mantis/CR6636.md @@ -0,0 +1,135 @@ + + + + + + + + + + + + + 0006636: inconsistencies for timepoint parameter in TRI part for different language mappings - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Perf & Real Time Testing (ES 202 782)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006636Ext Pack: Perf & Real Time Testing (ES 202 782)Technicalpublic08-10-2013 13:2706-01-2016 09:28
ReporterJacob Wieland - Spirent 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv1.2.1 (published 2014-06)Fixed in Versionv1.2.1 (published 2014-06) 
Clause Reference(s)Section 6, 7
Source (company - Author)Testing Technologies - Jacob Wieland
TS version2010
Summary0006636: inconsistencies for timepoint parameter in TRI part for different language mappings
DescriptionThe tri specification for the real time package adds a timepoint parameter which is supposed to be a TriTimerDuration (carrying the point in time since beginning of the testcase as a float in seconds). However, in the Java mapping, this is mapped to a long parameter (where it is unclear what the relation between the long and the seconds shall be).
+
+Also, there is no way for the SA to be informed by the PA that this point in time has been reached, so the pattern wait(x); send is hard to implement in the SA.
+
+Therefore, I propose to add a blocking function in PA triWaitUntil(TriTimerDuration timepoint) which blocks until the given timpoint is reached or causes an error if the timepoint is already passed.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
08-10-2013 13:27Jacob Wieland - SpirentNew Issue
08-10-2013 13:27Jacob Wieland - SpirentClause Reference(s) => Section 6, 7
08-10-2013 13:27Jacob Wieland - SpirentSource (company - Author) => Testing Technologies - Jacob Wieland
08-10-2013 13:27Jacob Wieland - SpirentTS version => 2010
08-10-2013 13:28Jacob Wieland - SpirentStatusnew => assigned
08-10-2013 13:28Jacob Wieland - SpirentAssigned To => Jacob Wieland - Spirent
25-11-2013 16:18Jacob Wieland - SpirentNote Added: 0011827
25-11-2013 16:19Jacob Wieland - SpirentNote Added: 0011828
25-11-2013 16:19Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Jens Grabowski
25-11-2013 16:19Jacob Wieland - SpirentStatusassigned => confirmed
26-12-2013 12:06Jens GrabowskiNote Added: 0011895
26-12-2013 12:23Jens GrabowskiStatusconfirmed => closed
26-12-2013 12:23Jens GrabowskiResolutionopen => fixed
06-01-2016 09:28Gyorgy RethyFixed in Version => v1.2.1 (published 2014-06)
06-01-2016 09:28Gyorgy RethyTarget Version => v1.2.1 (published 2014-06)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011827) +
+ Jacob Wieland - Spirent    +
+ 25-11-2013 16:18    +
+ 		+ + + + +
+ Resolution proposal can be found in CR 6310
+
+
+
+ + + + + + + + + + +
+ (0011828) +
+ Jacob Wieland - Spirent    +
+ 25-11-2013 16:19    +
+ 		+ + + + +
+ please review proposal
+
+
+
+ + + + + + + + + + +
+ (0011895) +
+ Jens Grabowski    +
+ 26-12-2013 12:06    +
+ 		+ + + + +
+ Implemented as proposed.
+
+ + diff --git a/docs/mantis/CR6637.md b/docs/mantis/CR6637.md new file mode 100644 index 0000000000000000000000000000000000000000..6aa2ca37f4fb87d3aeae186f5b2842225ac7fc82 --- /dev/null +++ b/docs/mantis/CR6637.md @@ -0,0 +1,131 @@ + + + + + + + + + + + + + 0006637: Missing TCI operations - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Continuous signal support (ES 202 786)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006637Ext Pack: Continuous signal support (ES 202 786)Technicalpublic09-10-2013 14:5826-12-2013 12:49
ReporterIna Schieferdecker 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv1.2.1 (published 2014-06)Fixed in Version 
Summary0006637: Missing TCI operations
DescriptiontciGetStreamValueReq and tciGetStreamValue are to be defined for CH in the continuous signalling extension package
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0006633closed Jens Grabowski Continuous signalling: return value of TCI-CH functions 
Attached Filesdocx CR6637.docx (23,404) 09-10-2013 16:10
http://oldforge.etsi.org/mantis/file_download.php?file_id=2912&type=bug
docx CR6637_v2.docx (22,979) 09-10-2013 18:32
http://oldforge.etsi.org/mantis/file_download.php?file_id=2914&type=bug
docx CR6637_v3.docx (22,708) 10-10-2013 09:55
http://oldforge.etsi.org/mantis/file_download.php?file_id=2917&type=bug
Issue History
Date ModifiedUsernameFieldChange
09-10-2013 14:58Ina SchieferdeckerNew Issue
09-10-2013 14:58Ina SchieferdeckerStatusnew => assigned
09-10-2013 14:58Ina SchieferdeckerAssigned To => Ina Schieferdecker
09-10-2013 14:58Ina SchieferdeckerClause Reference(s) => 7
09-10-2013 14:58Ina SchieferdeckerSource (company - Author) => Ina Schieferdecker, FOKUS
09-10-2013 14:59Ina SchieferdeckerProjectTTCN-3 Change Requests => Ext Pack: Continuous signal support (ES 202 786)
09-10-2013 15:45Ina SchieferdeckerNote Added: 0011734
09-10-2013 15:49Ina SchieferdeckerNote Deleted: 0011734
09-10-2013 16:10Ina SchieferdeckerFile Added: CR6637.docx
09-10-2013 16:10Ina SchieferdeckerNote Added: 0011735
09-10-2013 16:10Ina SchieferdeckerAssigned ToIna Schieferdecker => Jens Grabowski
09-10-2013 16:10Ina SchieferdeckerStatusassigned => confirmed
09-10-2013 16:11Ina SchieferdeckerTarget Version => v1.2.1 (published 2014-06)
09-10-2013 18:31Ina SchieferdeckerNote Added: 0011739
09-10-2013 18:32Ina SchieferdeckerFile Added: CR6637_v2.docx
10-10-2013 09:37Ina SchieferdeckerRelationship addedrelated to 0006633
10-10-2013 09:40Ina SchieferdeckerNote Added: 0011743
10-10-2013 09:41Ina SchieferdeckerFile Added: CR6637_v3.docx
10-10-2013 09:55Ina SchieferdeckerFile Deleted: CR6637_v3.docx
10-10-2013 09:55Ina SchieferdeckerFile Added: CR6637_v3.docx
26-12-2013 12:49Jens GrabowskiStatusconfirmed => closed
26-12-2013 12:49Jens GrabowskiResolutionopen => fixed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011735) +
+ Ina Schieferdecker    +
+ 09-10-2013 16:10    +
+ 		+ + + + +
+ Please check.
+
+
+
+ + + + + + + + + + +
+ (0011739) +
+ Ina Schieferdecker    +
+ 09-10-2013 18:31    +
+ 		+ + + + +
+ Revision: TriStatus not to be used in TCI operations - see v2
+
+
+
+ + + + + + + + + + +
+ (0011743) +
+ Ina Schieferdecker    +
+ 10-10-2013 09:40    +
+ 		+ + + + +
+ One more small editorial update
+
+ + diff --git a/docs/mantis/CR6639.md b/docs/mantis/CR6639.md new file mode 100644 index 0000000000000000000000000000000000000000..8373c80ae801dbf7e01762f13b450a32528da39d --- /dev/null +++ b/docs/mantis/CR6639.md @@ -0,0 +1,154 @@ + + + + + + + + + + + + + 0006639: Single precision of float value in java mapping - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006639Part 06: TTCN-3 Control InterfaceTechnicalpublic10-10-2013 09:2023-12-2013 14:05
ReporterTomas Urban 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.5.1 (published 2013-04) 
Target Versionv4.6.1 (published 2014-06)Fixed in Versionv4.6.1 (published 2014-06) 
Clause Reference(s)8.3.4.3
Source (company - Author)Elvior
Summary0006639: Single precision of float value in java mapping
DescriptionThe java mapping of the methods for getting and setting float values (FloatValue.getFloat, FloatValue.setFloat) use single precision numbers. All other mappings use double precision and C# mapping supports lossless (text-based) conversion in addition to that.
+
+The precision loss connected with converting to 32-bit floats has a negative implact on test case results, especially in complex and repeated calculations and as such, it is not acceptable in some testing environments. Quite recently, we had two cases from airspace and transport industry, when we had to implement XTRI adapters in C# rather than in java because of this limitation.
+
+Proposal:
+Change the parameter and return type from float to double in FloatValue.setFloat and FloatValue.getFloat of java mapping. This change is simple, but it might cause backwards compatibility issues.
+
+Alternative proposal:
+Add new methods to the FloatValue interface:
+public void setDouble(double value);
+public double getDouble();
+
+This change doesn't cause any backwards compatibility issues, but the interface won't be as nice as the other interfaces.
+
+Additional recommendation:
+Add methods for setting values without precision loss for testing systems where rounding to 64-bit double precision is not acceptable (if internally supported by the tool):
+public void setStringValue(string value);
+public string getStringValue();
+
+Similar methods are described in the C# mapping section.
+
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR6639.doc (367,104) 26-11-2013 12:58
http://oldforge.etsi.org/mantis/file_download.php?file_id=2940&type=bug
Issue History
Date ModifiedUsernameFieldChange
10-10-2013 09:20Tomas UrbanNew Issue
10-10-2013 09:20Tomas UrbanClause Reference(s) => 8.3.4.3
10-10-2013 09:20Tomas UrbanSource (company - Author) => Elvior
10-10-2013 09:47Gyorgy RethyAssigned To => Jacob Wieland - Spirent
10-10-2013 09:47Gyorgy RethyStatusnew => assigned
10-10-2013 09:47Gyorgy RethyTarget Version => v4.6.1 (published 2014-06)
10-10-2013 16:02Jacob Wieland - SpirentNote Added: 0011758
26-11-2013 12:58Jacob Wieland - SpirentFile Added: CR6639.doc
26-11-2013 12:58Jacob Wieland - SpirentNote Added: 0011833
26-11-2013 12:58Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Ina Schieferdecker
26-11-2013 12:58Jacob Wieland - SpirentStatusassigned => confirmed
23-12-2013 14:05Ina SchieferdeckerNote Added: 0011891
23-12-2013 14:05Ina SchieferdeckerStatusconfirmed => resolved
23-12-2013 14:05Ina SchieferdeckerResolutionopen => fixed
23-12-2013 14:05Ina SchieferdeckerFixed in Version => v4.6.1 (published 2014-06)
23-12-2013 14:05Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011758) +
+ Jacob Wieland - Spirent    +
+ 10-10-2013 16:02    +
+ 		+ + + + +
+ I think adding getDouble()/setDouble() is the viable way to go.
+
+I also would add getBigDecimal()/setBigDecimal() for arbitrary precision using java.math.BigDecimal (which allows all decimal operations and easy conversions from/to double and float).
+
+
+
+ + + + + + + + + + +
+ (0011833) +
+ Jacob Wieland - Spirent    +
+ 26-11-2013 12:58    +
+ 		+ + + + +
+ please review
+
+
+
+ + + + + + + + + + +
+ (0011891) +
+ Ina Schieferdecker    +
+ 23-12-2013 14:05    +
+ 		+ + + + +
+ as proposed
+
+ + diff --git a/docs/mantis/CR6640.md b/docs/mantis/CR6640.md new file mode 100644 index 0000000000000000000000000000000000000000..e47562951903eb82c2fbfeffac806e84f9b5350f --- /dev/null +++ b/docs/mantis/CR6640.md @@ -0,0 +1,102 @@ + + + + + + + + + + + + + 0006640: Uniform diction of words - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006640Part 01: TTCN-3 Core LanguageEditorialpublic11-10-2013 10:5827-11-2013 12:43
ReporterIna Schieferdecker 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.6.1 (published 2014-06)Fixed in Versionv4.6.1 (published 2014-06) 
Clause Reference(s)all
Source (company - Author)Ina Schieferdecker, FOKUS
Summary0006640: Uniform diction of words
DescriptionPart 1 uses both run-time and runtime, but only one should be in place.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
11-10-2013 10:58Ina SchieferdeckerNew Issue
11-10-2013 10:58Ina SchieferdeckerStatusnew => assigned
11-10-2013 10:58Ina SchieferdeckerAssigned To => Ina Schieferdecker
11-10-2013 10:58Ina SchieferdeckerClause Reference(s) => all
11-10-2013 10:58Ina SchieferdeckerSource (company - Author) => Ina Schieferdecker, FOKUS
11-10-2013 10:59Ina SchieferdeckerNote Added: 0011764
11-10-2013 10:59Ina SchieferdeckerProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
11-10-2013 11:00Ina SchieferdeckerStatusassigned => confirmed
11-10-2013 11:00Ina SchieferdeckerTarget Version => v4.6.1 (published 2014-06)
11-10-2013 11:21Ina SchieferdeckerNote Added: 0011765
27-11-2013 12:43Ina SchieferdeckerStatusconfirmed => resolved
27-11-2013 12:43Ina SchieferdeckerResolutionopen => fixed
27-11-2013 12:43Ina SchieferdeckerFixed in Version => v4.6.1 (published 2014-06)
27-11-2013 12:43Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011764) +
+ Ina Schieferdecker    +
+ 11-10-2013 10:59    +
+ 		+ + + + +
+ Decision to go for runtime.
+
+
+
+ + + + + + + + + + +
+ (0011765) +
+ Ina Schieferdecker    +
+ 11-10-2013 11:21    +
+ 		+ + + + +
+ same with
+pre-defined and predefined --> decision for predefined
+in-line and inline --> decision for in-line
+right hand side and right-hand-side --> decision for right hand side
+left hand side and left-hand-side --> decision for left hand side
+side effect and side-effect --> decision for side effect
+
+ + diff --git a/docs/mantis/CR6645.md b/docs/mantis/CR6645.md new file mode 100644 index 0000000000000000000000000000000000000000..c9412ce578c466fe39baa5ac90f9cf96eac2630f --- /dev/null +++ b/docs/mantis/CR6645.md @@ -0,0 +1,321 @@ + + + + + + + + + + + + + 0006645: Rules for array values - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006645Part 01: TTCN-3 Core LanguageEditorialpublic17-10-2013 16:3204-01-2015 19:05
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritylowSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.7.1 (published 2015-06)Fixed in Versionv4.7.1 (published 2015-06) 
Clause Reference(s)6.2.3, 6.2.7
Source (company - Author)STF 470
Summary0006645: Rules for array values
Description6.2.3 contains several references to array values. However, since the chapter is only about record of and set of, such references shouldn't be there, because the specification has a dedicated section for arrays (6.2.7). I believe that specifying rules for different language elements than those the chapter is about should be avoided at all costs. Otherwise the specification loses readability. The reference to array is also quite misleading and unnecessary in case of an index notation, because arrays have their own rules that are slightly different from the rules for record of and set of.
+
+I propose the following editorial changes:
+1. Remove all occurrences of the word "array" from 6.2.3.
+
+2. 6.2.7 has a rule saying that the allowed notation for is the index notation and value list notation, but assignment notation is not mentioned in this rule: "Values may be assigned individually by a value list notation or indexed notation or more than one or all at once by a value list notation". However, since 6.2 already specifies general rules for using the value list and assignment notations and further rules in 6.2.7 state that the index notation is also a valid option, I think the rule is superfluous and can be dropped.
+
+3. Since 6.2.7 doesn't contain any rules for using the assignment notation for arrays, these rules shall be added to 6.2.7, either by saying that rules described in 6.2.3 are valid for arrays as well or putting a slightly adjusted version of these rules into the chapter 6.2.7.
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0006762closed Gyorgy Rethy Array indexing breaches strong typing principle 
related to 0006646closed Gyorgy Rethy Missing semantic rules for the index and assignment notation 
Attached Filesdocx draft-res-6645-v1.docx (30,803) 04-11-2014 17:35
http://oldforge.etsi.org/mantis/file_download.php?file_id=3162&type=bug
docx draft-res-6645-v2.docx (33,954) 05-11-2014 09:47
http://oldforge.etsi.org/mantis/file_download.php?file_id=3165&type=bug
Issue History
Date ModifiedUsernameFieldChange
17-10-2013 16:32Tomas UrbanNew Issue
17-10-2013 16:32Tomas UrbanClause Reference(s) => 6.2.3, 6.2.7
17-10-2013 16:32Tomas UrbanSource (company - Author) => STF 470
21-11-2013 16:51Gyorgy RethyNote Added: 0011814
22-11-2013 14:49Gyorgy RethyProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
22-11-2013 14:50Gyorgy RethyNote Edited: 0011814
22-11-2013 14:50Gyorgy RethyTarget Version => v4.6.1 (published 2014-06)
22-11-2013 14:51Gyorgy RethyStatusnew => assigned
22-11-2013 14:51Gyorgy RethyAssigned To => Ina Schieferdecker
29-11-2013 12:53Ina SchieferdeckerNote Added: 0011868
29-11-2013 12:54Ina SchieferdeckerTarget Versionv4.6.1 (published 2014-06) => v4.7.1 (published 2015-06)
08-04-2014 16:51Gyorgy RethyAssigned ToIna Schieferdecker => Gyorgy Rethy
06-10-2014 14:52Gyorgy RethyPrioritynormal => low
10-10-2014 08:30Gyorgy RethyAssigned ToGyorgy Rethy => Axel Rennoch
04-11-2014 17:35Axel RennochFile Added: draft-res-6645-v1.docx
04-11-2014 17:38Axel RennochNote Added: 0012409
05-11-2014 08:53Axel RennochAssigned ToAxel Rennoch => Tomas Urban
05-11-2014 08:53Axel RennochStatusassigned => confirmed
05-11-2014 09:46Tomas UrbanRelationship addedrelated to 0006762
05-11-2014 09:46Tomas UrbanRelationship addedrelated to 0006646
05-11-2014 09:47Tomas UrbanFile Added: draft-res-6645-v2.docx
05-11-2014 09:50Tomas UrbanNote Added: 0012416
05-11-2014 09:50Tomas UrbanAssigned ToTomas Urban => Axel Rennoch
05-11-2014 10:17Axel RennochNote Added: 0012419
05-11-2014 10:18Axel RennochNote Added: 0012420
05-11-2014 10:18Axel RennochAssigned ToAxel Rennoch => Tomas Urban
05-11-2014 10:18Axel RennochStatusconfirmed => acknowledged
05-11-2014 14:28Tomas UrbanNote Added: 0012435
05-11-2014 14:28Tomas UrbanStatusacknowledged => resolved
05-11-2014 14:28Tomas UrbanFixed in Version => v4.7.1 (published 2015-06)
05-11-2014 14:28Tomas UrbanResolutionopen => fixed
05-11-2014 14:28Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
04-01-2015 19:05Gyorgy RethyNote Added: 0012606
04-01-2015 19:05Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011814) +
+ Gyorgy Rethy    +
+ 21-11-2013 16:51    +
(edited on: 22-11-2013 14:50)
+ 		+ + + + +
+ This structure has more a historical reason than technical. Once we have agreed that - with some minor technical deviations (e.g. array indexing may start with other index than 0, but don't have a named type) - arrays and length restricted record of-s are equivalent. For this reason clauses 6.2.3 and 6.2.7 could be merged, but we will not have time to do this at our last session in 2014 next week. I propose a quick patch now to handle the index assignment notation issue and open a follow-up CR to make the merge. Let discuss this at the STF session next week.
+
+
+
+
+
+ + + + + + + + + + +
+ (0011868) +
+ Ina Schieferdecker    +
+ 29-11-2013 12:53    +
+ 		+ + + + +
+ In response to issue 2, changed in 6.2.7
+
+"Values may be assigned individually by a value list notation or indexed notation or more than one or all at once by a value list notation."
+
+to
+
+"Values may be assigned individually by a value list notation or indexed notation or more than one or all at once by a value list notation or index assignment notation."
+
+The suggested rewrites will be done in 2014 only.
+
+
+
+ + + + + + + + + + +
+ (0012409) +
+ Axel Rennoch    +
+ 04-11-2014 17:38    +
+ 		+ + + + +
+ Minimal changes to solve issues 1 and 3 as well as some font/typo corrections are provided with the uploaded draft resolution v1. We still may do a bigger change, i.e. merging 6.2.3 and 6.2.7.
+
+
+
+ + + + + + + + + + +
+ (0012416) +
+ Tomas Urban    +
+ 05-11-2014 09:50    +
+ 		+ + + + +
+ I am fine with the changes, but I added several more rules to the array section in order to make sure that no rules are lost because of the removal of references to arrays from the section 6.2.3.
+
+Please review the updated proposal.
+
+
+
+ + + + + + + + + + +
+ (0012419) +
+ Axel Rennoch    +
+ 05-11-2014 10:17    +
+ 		+ + + + +
+ Thank you, the changes are fine for me. :-)
+
+
+
+ + + + + + + + + + +
+ (0012420) +
+ Axel Rennoch    +
+ 05-11-2014 10:18    +
+ 		+ + + + +
+ Can you set the status to "resolved"?
+
+
+
+ + + + + + + + + + +
+ (0012435) +
+ Tomas Urban    +
+ 05-11-2014 14:28    +
+ 		+ + + + +
+ The proposed changes have been reviewed and can be added to the next verion of the TTCN-3 core language standard.
+
+
+
+ + + + + + + + + + +
+ (0012606) +
+ Gyorgy Rethy    +
+ 04-01-2015 19:05    +
+ 		+ + + + +
+ Added to draft V4.6.3.
+
+ + diff --git a/docs/mantis/CR6646.md b/docs/mantis/CR6646.md new file mode 100644 index 0000000000000000000000000000000000000000..36732cb90aed6a9cd30ad9e6b38043be1679e16e --- /dev/null +++ b/docs/mantis/CR6646.md @@ -0,0 +1,248 @@ + + + + + + + + + + + + + 0006646: Missing semantic rules for the index and assignment notation - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006646Part 01: TTCN-3 Core LanguageTechnicalpublic17-10-2013 17:2304-01-2015 21:01
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.5.1 (published 2013-04) 
Target Versionv4.7.1 (published 2015-06)Fixed in Versionv4.7.1 (published 2015-06) 
Clause Reference(s)6.2
Source (company - Author)STF 470
Summary0006646: Missing semantic rules for the index and assignment notation
DescriptionThe following rules seem to be obvious and implicitly implied, but it would be worth of considering to declare them explicitly:
+
+1. The value used in the index notation shall be of an integer type (The specification currently only mentions numeric boundaries without formally saying anything about the type. It raises a question whether e.g. arr["0"] can be a valid statement. In some programming languages, it is a valid statement.)
+
+2. The value used in the index notation shall not be smaller than the index of the first item. (The current rules specify precisely the lower index only, but underflow situation is not considered at all).
+
+3. The index values used in the assignment notation for record of, set of and array values shall obey the rules valid for values used in the index notation. (Although obvious, such a rule is currently missing and it would be wise to formalize it.)
+
+P.S. Missing rules of this kind complicate the work of STF 470, because without a formal requirement, it is difficult to link a our test cases with related clauses in the core language specification and causes troubles in tracking test coverage.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0006762closed Gyorgy Rethy Array indexing breaches strong typing principle 
related to 0006645closed Gyorgy Rethy Rules for array values 
Attached Filesdoc CR6646.doc (342,016) 26-11-2013 11:15
http://oldforge.etsi.org/mantis/file_download.php?file_id=2939&type=bug
doc CR6646_v2.doc (349,184) 08-10-2014 11:24
http://oldforge.etsi.org/mantis/file_download.php?file_id=3110&type=bug
Issue History
Date ModifiedUsernameFieldChange
17-10-2013 17:23Tomas UrbanNew Issue
17-10-2013 17:23Tomas UrbanClause Reference(s) => 6.2
17-10-2013 17:23Tomas UrbanSource (company - Author) => STF 470
21-11-2013 10:44Gyorgy RethyStatusnew => assigned
21-11-2013 10:44Gyorgy RethyAssigned To => Jacob Wieland - Spirent
21-11-2013 13:18Gyorgy RethyNote Added: 0011812
21-11-2013 13:18Gyorgy RethyTarget Version => v4.6.1 (published 2014-06)
26-11-2013 11:15Jacob Wieland - SpirentFile Added: CR6646.doc
26-11-2013 11:18Jacob Wieland - SpirentNote Added: 0011832
26-11-2013 11:18Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
26-11-2013 11:18Jacob Wieland - SpirentStatusassigned => confirmed
08-04-2014 16:51Gyorgy RethyTarget Versionv4.6.1 (published 2014-06) => v4.7.1 (published 2015-06)
06-10-2014 14:56Gyorgy RethyAssigned ToGyorgy Rethy => Jens Grabowski
06-10-2014 14:56Gyorgy RethyStatusconfirmed => assigned
06-10-2014 14:57Gyorgy RethyStatusassigned => confirmed
07-10-2014 16:05Jens GrabowskiAssigned ToJens Grabowski => Tomas Urban
07-10-2014 16:05Jens GrabowskiStatusconfirmed => assigned
07-10-2014 16:05Jens GrabowskiStatusassigned => confirmed
07-10-2014 16:16Tomas UrbanNote Added: 0012262
07-10-2014 16:16Tomas UrbanStatusconfirmed => resolved
07-10-2014 16:16Tomas UrbanResolutionopen => fixed
07-10-2014 16:16Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
08-10-2014 11:24Tomas UrbanAssigned ToGyorgy Rethy => Tomas Urban
08-10-2014 11:24Tomas UrbanNote Added: 0012276
08-10-2014 11:24Tomas UrbanStatusresolved => feedback
08-10-2014 11:24Tomas UrbanResolutionfixed => reopened
08-10-2014 11:24Tomas UrbanFile Added: CR6646_v2.doc
08-10-2014 11:25Tomas UrbanRelationship addedrelated to 0006762
08-10-2014 11:29Tomas UrbanNote Added: 0012277
08-10-2014 11:29Tomas UrbanStatusfeedback => assigned
08-10-2014 11:29Tomas UrbanAssigned ToTomas Urban => Jens Grabowski
08-10-2014 11:29Tomas UrbanStatusassigned => confirmed
08-10-2014 14:41Jens GrabowskiStatusconfirmed => resolved
08-10-2014 14:41Jens GrabowskiResolutionreopened => fixed
08-10-2014 14:41Jens GrabowskiAssigned ToJens Grabowski => Gyorgy Rethy
05-11-2014 09:46Tomas UrbanRelationship addedrelated to 0006645
04-01-2015 21:01Gyorgy RethyNote Added: 0012614
04-01-2015 21:01Gyorgy RethyStatusresolved => closed
04-01-2015 21:01Gyorgy RethyFixed in Version => v4.7.1 (published 2015-06)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011812) +
+ Gyorgy Rethy    +
+ 21-11-2013 13:18    +
+ 		+ + + + +
+ Jacob, pls. check in the standard's text what rules are missing for the index notation. All rules could be listed in clause 6.2.3, to make it easier for the reader (and also for us to notice if something is missing).
+
+Other:
+- "indexed notation" should be changed to "index notation": clause 6.2, 6.2.3 (2*), 6.2.7
+- "Indexed value notation" be changed to index notation too: clause 6.2.3, 6.2.7
+
+
+
+ + + + + + + + + + +
+ (0011832) +
+ Jacob Wieland - Spirent    +
+ 26-11-2013 11:18    +
+ 		+ + + + +
+ I have put/refined the explanation regarding the index in the index notation definition. 6.2.3 only treats record of an set of while index notation is also for arrays and string types (with the same restrictions).
+
+Also changed all references to the notation to "index notation"
+
+
+
+ + + + + + + + + + +
+ (0012262) +
+ Tomas Urban    +
+ 07-10-2014 16:16    +
+ 		+ + + + +
+ The proposed resolution solves the issues described in this CR and can be added into next version of the TTCN-3 core language standard.
+
+
+
+ + + + + + + + + + +
+ (0012276) +
+ Tomas Urban    +
+ 08-10-2014 11:24    +
+ 		+ + + + +
+ Reopened because of use of the forbidden word "must" and missing reference to array and record of values used as an index in the index notation definition.
+
+
+
+ + + + + + + + + + +
+ (0012277) +
+ Tomas Urban    +
+ 08-10-2014 11:29    +
+ 		+ + + + +
+ When I was updating 0006762 I noticed that some facts were missing in the indexing value definition. I modified the definition adding the missing features.
+Please check.
+
+
+
+ + + + + + + + + + +
+ (0012614) +
+ Gyorgy Rethy    +
+ 04-01-2015 21:01    +
+ 		+ + + + +
+ Added to draft V4.6.3
+
+ + diff --git a/docs/mantis/CR6647.md b/docs/mantis/CR6647.md new file mode 100644 index 0000000000000000000000000000000000000000..af6ed9e9c9ea6f53aa1c96df96cac36c2efdb9fa --- /dev/null +++ b/docs/mantis/CR6647.md @@ -0,0 +1,248 @@ + + + + + + + + + + + + + 0006647: Additional restrictions for component.start - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006647Part 01: TTCN-3 Core LanguageTechnicalpublic18-10-2013 10:2105-01-2015 17:41
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PriorityhighSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.5.1 (published 2013-04) 
Target Versionv4.7.1 (published 2015-06)Fixed in Versionv4.7.1 (published 2015-06) 
Clause Reference(s)21.3.2
Source (company - Author)STF 470
Summary0006647: Additional restrictions for component.start
DescriptionIn my opinion, the current restriction limiting the type of parameters of function used in a component start operation (21.3.2.b) should contain the default type too. That's because 6.2.8 limits the use of default values to the component of their origin. Passing a reference to a different component would only lead to problems, because any use of it in the started component would automatically lead to an error.
+
+The updated rule should also mention that the parameters of the function shall not be of a structured type that contains fields of default or port type on any level of nesting.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR6647.doc (287,232) 26-11-2013 14:31
http://oldforge.etsi.org/mantis/file_download.php?file_id=2941&type=bug
Issue History
Date ModifiedUsernameFieldChange
18-10-2013 10:21Tomas UrbanNew Issue
18-10-2013 10:21Tomas UrbanClause Reference(s) => 21.3.2
18-10-2013 10:21Tomas UrbanSource (company - Author) => STF 470
18-10-2013 11:22Tomas UrbanNote Added: 0011808
21-11-2013 13:27Gyorgy RethyNote Added: 0011813
21-11-2013 13:27Gyorgy RethyAssigned To => Jacob Wieland - Spirent
21-11-2013 13:27Gyorgy RethyStatusnew => assigned
21-11-2013 13:27Gyorgy RethyTarget Version => v4.6.1 (published 2014-06)
26-11-2013 10:16Jacob Wieland - SpirentNote Added: 0011831
26-11-2013 14:31Jacob Wieland - SpirentFile Added: CR6647.doc
26-11-2013 14:32Jacob Wieland - SpirentNote Added: 0011834
26-11-2013 14:32Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
26-11-2013 14:32Jacob Wieland - SpirentStatusassigned => confirmed
08-04-2014 16:51Gyorgy RethyTarget Versionv4.6.1 (published 2014-06) => v4.7.1 (published 2015-06)
06-10-2014 15:00Gyorgy RethyPrioritynormal => high
08-10-2014 07:55Gyorgy RethyAssigned ToGyorgy Rethy => Jens Grabowski
08-10-2014 13:51Jens GrabowskiNote Added: 0012282
08-10-2014 13:51Jens GrabowskiStatusconfirmed => resolved
08-10-2014 13:51Jens GrabowskiResolutionopen => fixed
08-10-2014 13:51Jens GrabowskiAssigned ToJens Grabowski => Gyorgy Rethy
05-01-2015 17:41Gyorgy RethyNote Added: 0012625
05-01-2015 17:41Gyorgy RethyStatusresolved => closed
05-01-2015 17:41Gyorgy RethyFixed in Version => v4.7.1 (published 2015-06)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011808) +
+ Tomas Urban    +
+ 18-10-2013 11:22    +
+ 		+ + + + +
+ I am afraid that my original post not entirely correct. 6.2.8 doesn't directly indicate that using an default reference related to a different component leads to an error, but that such a reference "has no meaning". This expression is rather unfortunate, because it is somehow ambiguous.
+
+However, the most typical use of this reference, i.e. the deactivate operation will cause an error according to the rules in 20.5.3:
+- A test component cannot deactivate a default in another test component.
+- Calling a deactivate operation with an undefined default reference ... shall cause a runtime error.
+
+Assignment and parameter passing would probably still work, because it doesn't analyze the content.
+
+There might be problems with a log statement, because it is a question how to interpret this value with "no meaning" and comparing values with "no meaning" might be somehow difficult too.
+
+Thus I believe there's still a good justification for the original CR and it could be also considered, whether the rule from the chapter 6.2.8 (Default references have meaning only within the test component instances they are activated, i.e. a default reference assigned to a default variable in test component instance "a1" of type "A" has no meaning in test component instance
+"a2" of type "A".) shouldn't be dropped, because if the proposal is implemented there won't be any way of passing a default to a different component.
+
+
+
+ + + + + + + + + + +
+ (0011813) +
+ Gyorgy Rethy    +
+ 21-11-2013 13:27    +
+ 		+ + + + +
+ I agree with Thomas's proposal. Jacob, pls. look at it; I also propose to separate the two bullet items of restriction b) (on the runs on clause and on formal parameters) into two distinct restrictions.
+
+
+
+ + + + + + + + + + +
+ (0011831) +
+ Jacob Wieland - Spirent    +
+ 26-11-2013 10:16    +
+ 		+ + + + +
+ Off the top of my head, I can think of a scenario where using a default value from another component would not be an error: passing that value back to the original component in a message which then that component can use to deactivate the default.
+
+Anyway, forbidding this now would be backward incompatible, so I don't see the point.
+
+
+
+ + + + + + + + + + +
+ (0011834) +
+ Jacob Wieland - Spirent    +
+ 26-11-2013 14:32    +
+ 		+ + + + +
+ I've added a proposal to the effect of the wishes of the reporter. Please review.
+
+
+
+ + + + + + + + + + +
+ (0012282) +
+ Jens Grabowski    +
+ 08-10-2014 13:51    +
+ 		+ + + + +
+ Proposal is fine with me.
+
+
+
+ + + + + + + + + + +
+ (0012625) +
+ Gyorgy Rethy    +
+ 05-01-2015 17:41    +
+ 		+ + + + +
+ Added to draft V4.6.3
+
+ + diff --git a/docs/mantis/CR6648.md b/docs/mantis/CR6648.md new file mode 100644 index 0000000000000000000000000000000000000000..0840abaecaed65c28847dde193d58e003552620c --- /dev/null +++ b/docs/mantis/CR6648.md @@ -0,0 +1,207 @@ + + + + + + + + + + + + + 0006648: 6.2: Value list notation should not be used for set - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006648Part 01: TTCN-3 Core LanguageTechnicalpublic18-10-2013 14:3329-11-2013 13:58
ReporterAndras Kovacs 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.6.1 (published 2014-06)Fixed in Versionv4.6.1 (published 2014-06) 
Clause Reference(s)6.2
Source (company - Author)STF470 - Andras Kovacs
Summary0006648: 6.2: Value list notation should not be used for set
DescriptionIn section 6.2, the paragraph under Example 1 contains the following sentence:
+"The value list notation can be used for record, record of, set and set of value notations and for arrays."
+
+It is probably a mistake that 'set' is listed in the above sentence. Using value list notation for set would also be in contradiction to restrictions of section 6.2.2.
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR6648_v1.docx (16,283) 29-11-2013 13:56
http://oldforge.etsi.org/mantis/file_download.php?file_id=2968&type=bug
Issue History
Date ModifiedUsernameFieldChange
18-10-2013 14:33Andras KovacsNew Issue
18-10-2013 14:33Andras KovacsClause Reference(s) => 6.2
18-10-2013 14:33Andras KovacsSource (company - Author) => STF470 - Andras Kovacs
21-10-2013 09:59Jacob Wieland - SpirentNote Added: 0011809
22-11-2013 14:46Gyorgy RethyProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
22-11-2013 14:52Gyorgy RethyNote Added: 0011816
22-11-2013 14:52Gyorgy RethyAssigned To => Ina Schieferdecker
22-11-2013 14:52Gyorgy RethyStatusnew => assigned
22-11-2013 14:52Gyorgy RethyTarget Version => v4.6.1 (published 2014-06)
22-11-2013 14:54Gyorgy RethyNote Edited: 0011816
22-11-2013 14:55Gyorgy RethyNote Edited: 0011816
26-11-2013 16:04Jacob Wieland - SpirentNote Added: 0011838
28-11-2013 13:39Gyorgy RethyNote Added: 0011861
28-11-2013 13:40Gyorgy RethyNote Edited: 0011861
29-11-2013 13:56Ina SchieferdeckerFile Added: CR6648_v1.docx
29-11-2013 13:56Ina SchieferdeckerNote Added: 0011878
29-11-2013 13:57Ina SchieferdeckerStatusassigned => resolved
29-11-2013 13:57Ina SchieferdeckerResolutionopen => fixed
29-11-2013 13:57Ina SchieferdeckerFixed in Version => v4.6.1 (published 2014-06)
29-11-2013 13:58Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011809) +
+ Jacob Wieland - Spirent    +
+ 21-10-2013 09:59    +
+ 		+ + + + +
+ I think we should drop that restriction. What is its purpose?
+
+
+
+ + + + + + + + + + +
+ (0011816) +
+ Gyorgy Rethy    +
+ 22-11-2013 14:52    +
(edited on: 22-11-2013 14:55)
+ 		+ + + + +
+ I think this is a trivial error in clause 6.2. In set, fields may be in any order; if field names are not present, no one can know that which value is assigned to which field.
+
+
+
+
+
+ + + + + + + + + + +
+ (0011838) +
+ Jacob Wieland - Spirent    +
+ 26-11-2013 16:04    +
+ 		+ + + + +
+ if the value-list notation is used, of course the order of declaration, same as for record types should be relevant. The any-order thing is only relevant for encoded values, on the TTCN-3 level, there is no real difference between set and record types.
+
+
+
+ + + + + + + + + + +
+ (0011861) +
+ Gyorgy Rethy    +
+ 28-11-2013 13:39    +
(edited on: 28-11-2013 13:40)
+ 		+ + + + +
+ STF discussion 2013-11-28: We can allow value list notation for set types in clause 6.2.2, semantics shall be that in this case values are assigned to fields in the sequential order of the fields in the type definition.
+
+
+
+
+
+ + + + + + + + + + +
+ (0011878) +
+ Ina Schieferdecker    +
+ 29-11-2013 13:56    +
+ 		+ + + + +
+ as proposed - see file
+
+ + diff --git a/docs/mantis/CR6649.md b/docs/mantis/CR6649.md new file mode 100644 index 0000000000000000000000000000000000000000..9f375e3404434e7805ea005dbfb432c81c19c283 --- /dev/null +++ b/docs/mantis/CR6649.md @@ -0,0 +1,299 @@ + + + + + + + + + + + + + 0006649: inconsistency of running, done and killed operation - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006649Part 01: TTCN-3 Core LanguageTechnicalpublic30-10-2013 09:4729-11-2013 12:59
ReporterJacob Wieland - Spirent 
Assigned ToIna Schieferdecker 
PrioritynormalSeveritymajorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.6.1 (published 2014-06)Fixed in Versionv4.6.1 (published 2014-06) 
Clause Reference(s)21.3.6, 21.3.7, 21.3.8
Source (company - Author)Testing Technologies - Jacob Wieland
Summary0006649: inconsistency of running, done and killed operation
DescriptionThe done operation is defined with an inconsistent semantics.
+
+A single ptc which never has been started is not supposed to be done.
+
+all component.done is supposed to be true if all ptcs that have been started at some point are not running anymore.
+
+Thus, according to the current standard, if I only have a single ptc which has never been started:
+-ptc.done does not match
+-all component.done matches
+
+This, in my opinion, is counter-intuitive and not a useful distinction.
+
+In my opinion, the done operation should match if and only if the running operation when the snapshot was taken did not match where all component really should mean *all* components and not just some of them.
+
+The same is true for the running and killed operations where the all component has a different semantics as one would expect for a single never-started component.
+
+-ptc.running is false
+-all component.running is true
+
+-ptc.killed does not match
+-all component.killed matches
+
+Since this is more of a pathological case, I don't think that making this consistent will cause problems, even though it would be a backward incompatible change.
+
+If this is not changed, at least some NOTES should be added to the standard, warning about this.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR6649.doc (164,864) 29-11-2013 11:55
http://oldforge.etsi.org/mantis/file_download.php?file_id=2960&type=bug
Issue History
Date ModifiedUsernameFieldChange
30-10-2013 09:47Jacob Wieland - SpirentNew Issue
30-10-2013 09:47Jacob Wieland - SpirentClause Reference(s) => 21.3.6, 21.3.7, 21.3.8
30-10-2013 09:47Jacob Wieland - SpirentSource (company - Author) => Testing Technologies - Jacob Wieland
22-11-2013 15:02Gyorgy RethyProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
22-11-2013 15:14Gyorgy RethyNote Added: 0011817
22-11-2013 15:15Gyorgy RethyTarget Version => v4.6.1 (published 2014-06)
22-11-2013 15:16Gyorgy RethyNote Edited: 0011817
25-11-2013 12:47Jacob Wieland - SpirentNote Added: 0011822
25-11-2013 12:49Jacob Wieland - SpirentNote Added: 0011823
26-11-2013 08:55Ina SchieferdeckerNote Added: 0011830
28-11-2013 13:31Gyorgy RethyNote Added: 0011860
28-11-2013 13:31Gyorgy RethyAssigned To => Jacob Wieland - Spirent
28-11-2013 13:31Gyorgy RethyStatusnew => assigned
29-11-2013 11:55Jacob Wieland - SpirentFile Added: CR6649.doc
29-11-2013 11:56Jacob Wieland - SpirentNote Added: 0011864
29-11-2013 11:56Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Ina Schieferdecker
29-11-2013 11:56Jacob Wieland - SpirentStatusassigned => confirmed
29-11-2013 12:59Ina SchieferdeckerNote Added: 0011869
29-11-2013 12:59Ina SchieferdeckerStatusconfirmed => resolved
29-11-2013 12:59Ina SchieferdeckerResolutionopen => fixed
29-11-2013 12:59Ina SchieferdeckerStatusresolved => closed
29-11-2013 12:59Ina SchieferdeckerFixed in Version => v4.6.1 (published 2014-06)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011817) +
+ Gyorgy Rethy    +
+ 22-11-2013 15:14    +
(edited on: 22-11-2013 15:16)
+ 		+ + + + +
+ Backward compatibility is requirement no. 1. This CR could have been considered 10 years ago, but not today. We cannot change the semantics of TTCN-3 operations, especially when there is no error identified.
+
+These are not pathological cases at all. MTC is commonly used for test configuration creation, starting PTCs, coordination during execution and waiting until all started PTCs finished. For efficient test case development, it is a valid use case to use just one test configuration, but start behavior only on those PTCs, which are needed for the given test case. This is much simpler, and if a new object has to be added to the test case, the test configuration need not be changed, only a function has to be started on a PTC that was unused earlier.
+
+
+
+
+
+ + + + + + + + + + +
+ (0011822) +
+ Jacob Wieland - Spirent    +
+ 25-11-2013 12:47    +
+ 		+ + + + +
+ I'm not saying that the meaning of the 'all component' (even though not really aptly named) should be changed in this regard, but the semantics of the <not ever started component>.killed|done should be changed. This is a pathological case (if not a deadlock waiting to happen, i.e. a programming error) anyway as no one in their right mind would wait for a component specifically that has never been started to finish.
+
+In that way, the semantics of the operations could be made consistent which at the moment, they are definitely not.
+
+Obviously, this would also not change the semantics of the scenario that you are describing.
+
+
+
+ + + + + + + + + + +
+ (0011823) +
+ Jacob Wieland - Spirent    +
+ 25-11-2013 12:49    +
+ 		+ + + + +
+ Anyway, as I have already written in my original proposal, since this is definitely a cause for potential errors (as inconsistent definitions always are), this grave difference should be at least noted/warned about in the standard.
+
+
+
+ + + + + + + + + + +
+ (0011830) +
+ Ina Schieferdecker    +
+ 26-11-2013 08:55    +
+ 		+ + + + +
+ I see the point, however, those statements are to be used by the MTC which is sequential by itself. Therefore, I agree with your judgement that it is about rather pathological cases and would prefer to add a note only in order to ensure backward compatibility.
+
+
+
+ + + + + + + + + + +
+ (0011860) +
+ Gyorgy Rethy    +
+ 28-11-2013 13:31    +
+ 		+ + + + +
+ STF discussion 2013-11-28: add notes to notify users and tool implementers about the specifics of the current defined semantics. Jens: pls. check how it is defined in Part-4.
+
+
+
+ + + + + + + + + + +
+ (0011864) +
+ Jacob Wieland - Spirent    +
+ 29-11-2013 11:56    +
+ 		+ + + + +
+ added NOTEs to done and running operation to point out the difference between single and all component application. For killed and alive it was consistent, after all.
+
+
+
+ + + + + + + + + + +
+ (0011869) +
+ Ina Schieferdecker    +
+ 29-11-2013 12:59    +
+ 		+ + + + +
+ as proposed
+
+ + diff --git a/docs/mantis/CR6650.md b/docs/mantis/CR6650.md new file mode 100644 index 0000000000000000000000000000000000000000..92c66527d969f298e808c29e009b0af6c5f905a3 --- /dev/null +++ b/docs/mantis/CR6650.md @@ -0,0 +1,207 @@ + + + + + + + + + + + + + 0006650: matching mechanisms which match omit should not be allowed as elements of record of or set of templates - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006650Part 01: TTCN-3 Core LanguageClarificationpublic07-11-2013 13:2229-11-2013 13:38
ReporterJacob Wieland - Spirent 
Assigned ToIna Schieferdecker 
PriorityhighSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.6.1 (published 2014-06)Fixed in Versionv4.6.1 (published 2014-06) 
Clause Reference(s)15.7.
Source (company - Author)     
Summary0006650: matching mechanisms which match omit should not be allowed as elements of record of or set of templates
DescriptionThe following restricting NOTEs should be changed into proper restrictions:
+
+NOTE 1 and NOTE 2 in 15.7.2 and NOTE in 15.7.4.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR6650.doc (293,376) 28-11-2013 09:48
http://oldforge.etsi.org/mantis/file_download.php?file_id=2953&type=bug
doc CR6650_v2.doc (297,472) 29-11-2013 13:37
http://oldforge.etsi.org/mantis/file_download.php?file_id=2966&type=bug
Issue History
Date ModifiedUsernameFieldChange
07-11-2013 13:22Jacob Wieland - SpirentNew Issue
07-11-2013 13:22Jacob Wieland - SpirentClause Reference(s) => 15.7.
07-11-2013 13:22Jacob Wieland - SpirentSource (company - Author) =>
22-11-2013 15:20Gyorgy RethyProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
22-11-2013 15:30Gyorgy RethyNote Added: 0011818
22-11-2013 15:30Gyorgy RethyTarget Version => v4.6.1 (published 2014-06)
22-11-2013 15:30Gyorgy RethyNote Added: 0011819
22-11-2013 15:30Gyorgy RethyAssigned To => Ina Schieferdecker
22-11-2013 15:30Gyorgy RethyStatusnew => assigned
22-11-2013 15:31Gyorgy RethyNote Deleted: 0011818
25-11-2013 12:58Jacob Wieland - SpirentNote Added: 0011824
28-11-2013 09:48Jacob Wieland - SpirentFile Added: CR6650.doc
28-11-2013 09:50Jacob Wieland - SpirentNote Added: 0011850
28-11-2013 09:52Jacob Wieland - SpirentNote Added: 0011851
28-11-2013 09:52Jacob Wieland - SpirentStatusassigned => confirmed
29-11-2013 13:37Ina SchieferdeckerFile Added: CR6650_v2.doc
29-11-2013 13:37Ina SchieferdeckerNote Added: 0011875
29-11-2013 13:37Ina SchieferdeckerStatusconfirmed => resolved
29-11-2013 13:37Ina SchieferdeckerResolutionopen => fixed
29-11-2013 13:38Ina SchieferdeckerStatusresolved => closed
29-11-2013 13:38Ina SchieferdeckerFixed in Version => v4.6.1 (published 2014-06)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011819) +
+ Gyorgy Rethy    +
+ 22-11-2013 15:30    +
+ 		+ + + + +
+ I propose to delete the notes: they are the 3rd place, where those restrictions are defined: 1st in Table 11, than in clause 15.7 and than in Annex B. Restriction a) of 15.7.2 and 15.7.4 refer already to table 11 and to clause B, therefore, in fact, the notes contain no new information (but contain shorter, and thus easier-to-misinterpret text).
+
+
+
+ + + + + + + + + + +
+ (0011824) +
+ Jacob Wieland - Spirent    +
+ 25-11-2013 12:58    +
+ 		+ + + + +
+ Sorry, but in Table 11, there are only notes and the table is not in a section marked as Restrictions. Therefore, it deviates from the other places that introduce restrictions (and referring to these "restrictions" in other restrictions parts is in my view unfounded).
+
+Also, I have not found any restrictions in this regard in Annex B.
+
+I would vote to move the restrictions from the notes to the right places, i.e. the respective restrictions sections.
+
+
+
+ + + + + + + + + + +
+ (0011850) +
+ Jacob Wieland - Spirent    +
+ 28-11-2013 09:50    +
+ 		+ + + + +
+ Added restrictions section to 15.7.
+
+Restructured Annex B according to the Restrictions/Examples paradigm used in the rest of the document. All restricting sentences are moved to the restrictions sections, new restrictions sections are introduced where missing, examples are moved into the examples sections
+
+
+
+ + + + + + + + + + +
+ (0011851) +
+ Jacob Wieland - Spirent    +
+ 28-11-2013 09:52    +
+ 		+ + + + +
+ please review
+
+
+
+ + + + + + + + + + +
+ (0011875) +
+ Ina Schieferdecker    +
+ 29-11-2013 13:37    +
+ 		+ + + + +
+ as proposed with editorials in v2
+
+ + diff --git a/docs/mantis/CR6658.md b/docs/mantis/CR6658.md new file mode 100644 index 0000000000000000000000000000000000000000..412c783967ab605601ce977f59b7a5e33cc810d6 --- /dev/null +++ b/docs/mantis/CR6658.md @@ -0,0 +1,137 @@ + + + + + + + + + + + + + 0006658: random number generator should be available to test adaptation - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 05: TTCN-3 Runtime Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006658Part 05: TTCN-3 Runtime Interface New Featurepublic27-11-2013 11:4023-12-2013 14:17
ReporterJacob Wieland - Spirent 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.6.1 (published 2014-06)Fixed in Versionv4.6.1 (published 2014-06) 
Clause Reference(s)5.6
Source (company - Author)Testing Technologies - Jacob Wieland
Summary0006658: random number generator should be available to test adaptation
DescriptionThe test adapter (especially external functions, e.g. used for security testing) should be able to produce random numbers depending on the same seed as the calling TE behavior (to allow for reproducibility also on the test adapter level).
+
+Therefore, the rnd function should be exposed to tri level by introducing
+
+FloatValue triRnd(TriComponentId, FloatValue seed)
+
+where seed can be null and which has the same semantics as the predefinded function rnd.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0006624closed Gyorgy Rethy Part 01: TTCN-3 Core Language Allow access to random seed per component. 
related to 0006659closed Ina Schieferdecker Part 06: TTCN-3 Control Interface Generation of random numbers should be logged for analysis and reproducibility purposes. 
related to 0006660closed Ina Schieferdecker Ext Pack: Extended TRI (ES 202 789) introduce xtriRnd 
Attached Filesdoc CR6658.doc (249,856) 27-11-2013 14:44
http://oldforge.etsi.org/mantis/file_download.php?file_id=2951&type=bug
Issue History
Date ModifiedUsernameFieldChange
27-11-2013 11:40Jacob Wieland - SpirentNew Issue
27-11-2013 11:40Jacob Wieland - SpirentClause Reference(s) => 5.6
27-11-2013 11:40Jacob Wieland - SpirentSource (company - Author) => Testing Technologies - Jacob Wieland
27-11-2013 11:57Jacob Wieland - SpirentStatusnew => assigned
27-11-2013 11:57Jacob Wieland - SpirentAssigned To => Jacob Wieland - Spirent
27-11-2013 11:58Jacob Wieland - SpirentRelationship addedrelated to 0006624
27-11-2013 11:58Jacob Wieland - SpirentRelationship addedrelated to 0006659
27-11-2013 14:07Jacob Wieland - SpirentNote Added: 0011847
27-11-2013 14:07Jacob Wieland - SpirentFile Added: CR6658.doc
27-11-2013 14:10Jacob Wieland - SpirentRelationship addedrelated to 0006660
27-11-2013 14:24Jacob Wieland - SpirentFile Deleted: CR6658.doc
27-11-2013 14:24Jacob Wieland - SpirentFile Added: CR6658.doc
27-11-2013 14:26Jacob Wieland - SpirentFile Deleted: CR6658.doc
27-11-2013 14:26Jacob Wieland - SpirentFile Added: CR6658.doc
27-11-2013 14:37Jacob Wieland - SpirentFile Deleted: CR6658.doc
27-11-2013 14:44Jacob Wieland - SpirentFile Added: CR6658.doc
27-11-2013 14:50Jacob Wieland - SpirentTarget Version => v4.6.1 (published 2014-06)
27-11-2013 14:52Jacob Wieland - SpirentNote Added: 0011849
27-11-2013 14:52Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Ina Schieferdecker
27-11-2013 14:52Jacob Wieland - SpirentStatusassigned => confirmed
23-12-2013 14:16Ina SchieferdeckerNote Added: 0011892
23-12-2013 14:16Ina SchieferdeckerStatusconfirmed => resolved
23-12-2013 14:16Ina SchieferdeckerResolutionopen => fixed
23-12-2013 14:16Ina SchieferdeckerFixed in Version => v4.6.1 (published 2014-06)
23-12-2013 14:16Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011847) +
+ Jacob Wieland - Spirent    +
+ 27-11-2013 14:07    +
+ 		+ + + + +
+ Of course, in tri you cannot use FloatValue, so TriMessage has to be used in instead. The same thing should be done in XTRI.
+
+
+
+ + + + + + + + + + +
+ (0011849) +
+ Jacob Wieland - Spirent    +
+ 27-11-2013 14:52    +
+ 		+ + + + +
+ please review
+
+
+
+ + + + + + + + + + +
+ (0011892) +
+ Ina Schieferdecker    +
+ 23-12-2013 14:16    +
+ 		+ + + + +
+ as proposed.
+
+ + diff --git a/docs/mantis/CR6659.md b/docs/mantis/CR6659.md new file mode 100644 index 0000000000000000000000000000000000000000..979e0daa020ba7be3b42cbec5d47d5bd888fe976 --- /dev/null +++ b/docs/mantis/CR6659.md @@ -0,0 +1,99 @@ + + + + + + + + + + + + + 0006659: Generation of random numbers should be logged for analysis and reproducibility purposes. - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006659Part 06: TTCN-3 Control InterfaceNew Featurepublic27-11-2013 11:5623-12-2013 14:01
ReporterJacob Wieland - Spirent 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.6.1 (published 2014-06)Fixed in Versionv4.6.1 (published 2014-06) 
Clause Reference(s)7.3.4.1, 8.5.4.1, 9.4.4.1, 10.6.4.1, 11.4.2.1, 12.5.4.1, B.6
Source (company - Author)Testing Technologies - Jacob Wieland
Summary0006659: Generation of random numbers should be logged for analysis and reproducibility purposes.
DescriptionAt the moment, a test behavior may be dependent on random numbers generated by the TE. Unfortunately, the generation of these numbers is not logged, so it can be hard to reproduce the same test behavior, even given the same input from the SUT.
+
+To that end, I propose to introduce a log event TliRnd which is produced whenever the rnd() function is called (or triRnd()) and which includes both the used seed as well as the result of the call.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0006624closed Gyorgy Rethy Part 01: TTCN-3 Core Language Allow access to random seed per component. 
related to 0006658closed Ina Schieferdecker Part 05: TTCN-3 Runtime Interface  random number generator should be available to test adaptation 
Attached Filesdoc CR6659.doc (662,016) 27-11-2013 13:01
http://oldforge.etsi.org/mantis/file_download.php?file_id=2947&type=bug
doc CR6659_v2.doc (670,208) 23-12-2013 14:00
http://oldforge.etsi.org/mantis/file_download.php?file_id=2972&type=bug
Issue History
Date ModifiedUsernameFieldChange
27-11-2013 11:56Jacob Wieland - SpirentNew Issue
27-11-2013 11:56Jacob Wieland - SpirentClause Reference(s) => 7.3.4.1, 8.5.4.1, 9.4.4.1, 10.6.4.1, 11.4.2.1, 12.5.4.1, B.6
27-11-2013 11:56Jacob Wieland - SpirentSource (company - Author) => Testing Technologies - Jacob Wieland
27-11-2013 11:57Jacob Wieland - SpirentStatusnew => assigned
27-11-2013 11:57Jacob Wieland - SpirentAssigned To => Jacob Wieland - Spirent
27-11-2013 11:58Jacob Wieland - SpirentRelationship addedrelated to 0006658
27-11-2013 11:59Jacob Wieland - SpirentRelationship addedrelated to 0006624
27-11-2013 13:01Jacob Wieland - SpirentFile Added: CR6659.doc
27-11-2013 13:01Jacob Wieland - SpirentNote Added: 0011846
27-11-2013 13:01Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Ina Schieferdecker
27-11-2013 13:01Jacob Wieland - SpirentStatusassigned => confirmed
27-11-2013 14:53Jacob Wieland - SpirentTarget Version => v4.6.1 (published 2014-06)
23-12-2013 14:00Ina SchieferdeckerNote Added: 0011890
23-12-2013 14:00Ina SchieferdeckerFile Added: CR6659_v2.doc
23-12-2013 14:01Ina SchieferdeckerStatusconfirmed => resolved
23-12-2013 14:01Ina SchieferdeckerResolutionopen => fixed
23-12-2013 14:01Ina SchieferdeckerFixed in Version => v4.6.1 (published 2014-06)
23-12-2013 14:01Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011846) +
+ Jacob Wieland - Spirent    +
+ 27-11-2013 13:01    +
+ 		+ + + + +
+ please review
+
+
+
+ + + + + + + + + + +
+ (0011890) +
+ Ina Schieferdecker    +
+ 23-12-2013 14:00    +
+ 		+ + + + +
+ As proposed - just one small extension.
+
+ + diff --git a/docs/mantis/CR6660.md b/docs/mantis/CR6660.md new file mode 100644 index 0000000000000000000000000000000000000000..e818dfbae447b0611d0fbf236ba6c84d374abd53 --- /dev/null +++ b/docs/mantis/CR6660.md @@ -0,0 +1,97 @@ + + + + + + + + + + + + + 0006660: introduce xtriRnd - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Extended TRI (ES 202 789)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006660Ext Pack: Extended TRI (ES 202 789)New Featurepublic27-11-2013 14:0923-12-2013 14:26
ReporterJacob Wieland - Spirent 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv1.3.1 (published 2014-06)Fixed in Versionv1.3.1 (published 2014-06) 
Clause Reference(s)
Source (company - Author)
Summary0006660: introduce xtriRnd
Descriptionintroduce xtriRnd with unencoded float values (see CR5568)
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0006658closed Ina Schieferdecker Part 05: TTCN-3 Runtime Interface  random number generator should be available to test adaptation 
Attached Filesdocx CR6660.docx (137,137) 27-11-2013 14:44
http://oldforge.etsi.org/mantis/file_download.php?file_id=2952&type=bug
Issue History
Date ModifiedUsernameFieldChange
27-11-2013 14:09Jacob Wieland - SpirentNew Issue
27-11-2013 14:09Jacob Wieland - SpirentStatusnew => assigned
27-11-2013 14:09Jacob Wieland - SpirentAssigned To => Jacob Wieland - Spirent
27-11-2013 14:10Jacob Wieland - SpirentRelationship addedrelated to 0006658
27-11-2013 14:44Jacob Wieland - SpirentFile Added: CR6660.docx
27-11-2013 14:45Jacob Wieland - SpirentSummaryintroduce triRnd and triSelf => introduce xtriRnd
27-11-2013 14:45Jacob Wieland - SpirentDescription Updated
27-11-2013 14:51Jacob Wieland - SpirentTarget Version => v1.3.1 (published 2014-06)
27-11-2013 14:52Jacob Wieland - SpirentNote Added: 0011848
27-11-2013 14:52Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Ina Schieferdecker
27-11-2013 14:52Jacob Wieland - SpirentStatusassigned => confirmed
23-12-2013 14:26Ina SchieferdeckerNote Added: 0011893
23-12-2013 14:26Ina SchieferdeckerStatusconfirmed => resolved
23-12-2013 14:26Ina SchieferdeckerResolutionopen => fixed
23-12-2013 14:26Ina SchieferdeckerFixed in Version => v1.3.1 (published 2014-06)
23-12-2013 14:26Ina SchieferdeckerStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011848) +
+ Jacob Wieland - Spirent    +
+ 27-11-2013 14:52    +
+ 		+ + + + +
+ please review
+
+
+
+ + + + + + + + + + +
+ (0011893) +
+ Ina Schieferdecker    +
+ 23-12-2013 14:26    +
+ 		+ + + + +
+ as proposed
+
+ + diff --git a/docs/mantis/CR6661.md b/docs/mantis/CR6661.md new file mode 100644 index 0000000000000000000000000000000000000000..d68772f410e4e665b05b5845fb89e93e1f2e6190 --- /dev/null +++ b/docs/mantis/CR6661.md @@ -0,0 +1,73 @@ + + + + + + + + + + + + + 0006661: Array is forgotten in permutation clause - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006661Part 01: TTCN-3 Core LanguageClarificationpublic29-11-2013 11:2229-11-2013 13:45
ReporterGyorgy Rethy 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.6.1 (published 2014-06)Fixed in Versionv4.6.1 (published 2014-06) 
Clause Reference(s)B.1.3.3
Source (company - Author)L.M.Ericsson
Summary0006661: Array is forgotten in permutation clause
DescriptionIn table 11 it is specified unambiguously that permutation can be used for arrays. But clause B.1.3.3 forgets to mention this: "Permutation is an operation for matching that shall be used only on values of record of types."
+
+Proposed solution: Add array to the above sentence.
+
+Another note: cells for the columns "Range", "Superset", "Subset" and "Pattern" should be grey for the row "array", like it is for record of-s.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
29-11-2013 11:22Gyorgy RethyNew Issue
29-11-2013 11:22Gyorgy RethyClause Reference(s) => B.1.3.3
29-11-2013 11:22Gyorgy RethySource (company - Author) => L.M.Ericsson
29-11-2013 11:22Gyorgy RethyAssigned To => Ina Schieferdecker
29-11-2013 11:22Gyorgy RethyStatusnew => assigned
29-11-2013 11:22Gyorgy RethySummaryArray is Forgotten in => Array is Forgotten in permutation clause
29-11-2013 11:23Gyorgy RethyProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
29-11-2013 11:23Gyorgy RethyTarget Version => v4.6.1 (published 2014-06)
29-11-2013 11:23Gyorgy RethySummaryArray is Forgotten in permutation clause => Array is forgotten in permutation clause
29-11-2013 13:45Ina SchieferdeckerNote Added: 0011876
29-11-2013 13:45Ina SchieferdeckerStatusassigned => resolved
29-11-2013 13:45Ina SchieferdeckerResolutionopen => fixed
29-11-2013 13:45Ina SchieferdeckerStatusresolved => closed
29-11-2013 13:45Ina SchieferdeckerFixed in Version => v4.6.1 (published 2014-06)
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011876) +
+ Ina Schieferdecker    +
+ 29-11-2013 13:45    +
+ 		+ + + + +
+ As proposed:
+
+"Permutation is an operation for matching that shall be used only on values of record of types." --> "Permutation is an operation for matching that shall be used only on values of record of and array types."
+
+"Each individual member listed in the permutation shall be of the type replicated by the record of type." --> "Each individual member listed in the permutation shall be of the type replicated by the record of or array type."
+
+The cells in table 11 also re-coloured.
+
+ + diff --git a/docs/mantis/CR6663.md b/docs/mantis/CR6663.md new file mode 100644 index 0000000000000000000000000000000000000000..11b690c14c63a3af015824bd0d9d9527287e6a06 --- /dev/null +++ b/docs/mantis/CR6663.md @@ -0,0 +1,213 @@ + + + + + + + + + + + + + 0006663: regexp's behaviour if both string parameters are literals - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006663Part 01: TTCN-3 Core LanguageClarificationpublic12-12-2013 12:0806-01-2015 18:49
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PriorityhighSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.6.1 (published 2014-06) 
Target Versionv4.7.1 (published 2015-06)Fixed in Versionv4.7.1 (published 2015-06) 
Clause Reference(s)C.4.1
Source (company - Author)L.M.Ericsson
Summary0006663: regexp's behaviour if both string parameters are literals
DescriptionThe current behavior of regexp is unspecified in the case when both inpar and expression are literals. e.g.:
+var charstring v_temp := regexp ( "CSP-1234", "CSP-(\d#(1,4))", 0 );
+
+Possible behaviors:
+- return an error as the type of the parameters are not defined
+- implicitly assume the types of the parameters from their contents (i.e. cause error in case of inpar deducted to be a charstring and expression to be a universal charstring, and return a string otherwise)
+- consider the type of the variable at the LHS in a strict way, i.e. the types of the parameters shall be the same, and cause error or return a string based on this information; if there is no appropriate type to consider(e.g. inside an expression), cause an error.
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR6663_update_proposal.docx (25,317) 10-04-2014 13:27
http://oldforge.etsi.org/mantis/file_download.php?file_id=2998&type=bug
docx CR6663_update_proposal-V2.docx (20,655) 08-10-2014 10:39
http://oldforge.etsi.org/mantis/file_download.php?file_id=3107&type=bug
Issue History
Date ModifiedUsernameFieldChange
12-12-2013 12:08Gyorgy RethyNew Issue
12-12-2013 12:08Gyorgy RethyClause Reference(s) => C.4.1
12-12-2013 12:08Gyorgy RethySource (company - Author) => L.M.Ericsson
12-12-2013 12:09Gyorgy RethyProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
12-12-2013 13:01Jacob Wieland - SpirentNote Added: 0011884
07-04-2014 14:27Gyorgy RethyNote Added: 0011941
07-04-2014 14:27Gyorgy RethyAssigned To => Axel Rennoch
07-04-2014 14:27Gyorgy RethyStatusnew => assigned
08-04-2014 16:52Gyorgy RethyProduct Version => v4.6.1 (published 2014-06)
08-04-2014 16:52Gyorgy RethyTarget Version => v4.7.1 (published 2015-06)
10-04-2014 13:27Axel RennochFile Added: CR6663_update_proposal.docx
10-04-2014 13:28Axel RennochAssigned ToAxel Rennoch => Gyorgy Rethy
10-04-2014 13:28Axel RennochNote Added: 0012004
10-04-2014 13:28Axel RennochStatusassigned => confirmed
06-10-2014 15:07Gyorgy RethyPrioritynormal => high
08-10-2014 07:56Gyorgy RethyAssigned ToGyorgy Rethy => Jens Grabowski
08-10-2014 10:39Jens GrabowskiNote Added: 0012273
08-10-2014 10:39Jens GrabowskiFile Added: CR6663_update_proposal-V2.docx
08-10-2014 10:39Jens GrabowskiAssigned ToJens Grabowski => Gyorgy Rethy
08-10-2014 10:39Jens GrabowskiStatusconfirmed => assigned
08-10-2014 10:40Jens GrabowskiStatusassigned => resolved
08-10-2014 10:40Jens GrabowskiResolutionopen => fixed
06-01-2015 18:49Gyorgy RethyNote Added: 0012655
06-01-2015 18:49Gyorgy RethyStatusresolved => closed
06-01-2015 18:49Gyorgy RethyFixed in Version => v4.7.1 (published 2015-06)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011884) +
+ Jacob Wieland - Spirent    +
+ 12-12-2013 13:01    +
+ 		+ + + + +
+ I think the restriction should simply be dropped as it serves no purpose. The return type (as the return value can only be a substring of the input parameter) follows obviously from the type of the input parameter whose type can always be inferred from the content, if it is a string literal.
+
+It can have no detrimental effect if I use a universal charstring pattern on a charstring value (at worst, it does not match) or if I use a charstring pattern on a universal charstring value (as every charstring is implicitly also a universal charstring).
+
+Therefore, the restriction has no purpose and can be dropped. This will also not create backward compatibility issues as it just allows more usages of regexp without changing the semantics of the previously allowed usages.
+
+
+
+ + + + + + + + + + +
+ (0011941) +
+ Gyorgy Rethy    +
+ 07-04-2014 14:27    +
+ 		+ + + + +
+ stf478, 2014-04-07: Add a formal rule to decide the type implicitly according to content.
+Add the same rules to substring and replace.
+
+
+
+ + + + + + + + + + +
+ (0012004) +
+ Axel Rennoch    +
+ 10-04-2014 13:28    +
+ 		+ + + + +
+ Problem: parameters of regexp may have no type information
+
+Approach: types of literal arguments should be derived from the contents
+
+
+
+ + + + + + + + + + +
+ (0012273) +
+ Jens Grabowski    +
+ 08-10-2014 10:39    +
+ 		+ + + + +
+ Wording slightly changed.
+
+
+
+ + + + + + + + + + +
+ (0012655) +
+ Gyorgy Rethy    +
+ 06-01-2015 18:49    +
+ 		+ + + + +
+ Added to draft V4.6.3
+
+ + diff --git a/docs/mantis/CR6669.md b/docs/mantis/CR6669.md new file mode 100644 index 0000000000000000000000000000000000000000..1f0f5656996f88c47904268fec8baac9bfc42656 --- /dev/null +++ b/docs/mantis/CR6669.md @@ -0,0 +1,175 @@ + + + + + + + + + + + + + 0006669: Missing support for decvalue function in TCI - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006669Part 06: TTCN-3 Control InterfaceTechnicalpublic10-01-2014 12:5317-12-2014 11:42
ReporterTomas Urban 
Assigned ToTomas Urban 
PrioritynormalSeveritymajorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.5.1 (published 2013-04) 
Target Versionv4.7.1 (published 2015-06)Fixed in Versionv4.7.1 (published 2015-06) 
Clause Reference(s)7.3.2.2
Source (company - Author)Elvior
Summary0006669: Missing support for decvalue function in TCI
DescriptionThe decvalue function defined in the C.5.2 of the core language specification requires that the decoder appart from decoding the value (or not decoding it) provides two additional values:
+1. If the decoding process didn't use the whole supplied bitstring for the decoding, the undecoded part
+2. If the decoding process didn't succeed, the method returns 2 if the reason is insufficient number of bytes to decode or 1 in case of any other (unspecified) cause.
+
+Neither of these two additional values can be obtained through the TCI-CD provided interface, because its decode method of the interface return just the decoded value or null. This makes the decvalue function work completely only with proprietary codec interfaces, while its use with TCI is restricted to return values 0 and 1 and the undecoded part equal to an empty bit string.
+
+Since changing the TCI decode function signature wouldn't be feasible because of compatibility issues, I propose to add a new function to the TCI-CD provided interface:
+
+TInteger decValue(inout TriMessageType, in TypeHypothesis decodingHyporthesis, out Value decodedValue)
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR6699_v1.docx (14,648) 16-06-2014 13:51
http://oldforge.etsi.org/mantis/file_download.php?file_id=3031&type=bug
Issue History
Date ModifiedUsernameFieldChange
10-01-2014 12:53Tomas UrbanNew Issue
10-01-2014 12:53Tomas UrbanClause Reference(s) => 7.3.2.2
10-01-2014 12:53Tomas UrbanSource (company - Author) => Elvior
07-04-2014 14:36Gyorgy RethyNote Added: 0011942
07-04-2014 14:38Gyorgy RethyAssigned To => Tomas Urban
07-04-2014 14:38Gyorgy RethyStatusnew => assigned
08-04-2014 17:07Gyorgy RethyTarget Version => v4.7.1 (published 2015-06)
30-04-2014 09:31Jacob Wieland - SpirentNote Added: 0012060
16-06-2014 13:51Tomas UrbanFile Added: CR6699_v1.docx
16-06-2014 13:51Tomas UrbanNote Added: 0012085
16-06-2014 13:51Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
16-06-2014 13:51Tomas UrbanStatusassigned => confirmed
17-06-2014 07:22Jacob Wieland - SpirentNote Added: 0012095
08-10-2014 08:11Gyorgy RethyAssigned ToGyorgy Rethy => Tomas Urban
08-10-2014 08:11Gyorgy RethyStatusconfirmed => resolved
08-10-2014 08:11Gyorgy RethyResolutionopen => fixed
08-10-2014 08:11Gyorgy RethyFixed in Version => v4.7.1 (published 2015-06)
17-12-2014 11:42Tomas UrbanStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011942) +
+ Gyorgy Rethy    +
+ 07-04-2014 14:36    +
+ 		+ + + + +
+ stf478, 2014-04-07: (1) a new function should be added to return the decoding result value. (2) start a discussion thread with tool vendors if a common error handling and fallback mechanism could be agreed.
+
+
+
+ + + + + + + + + + +
+ (0012060) +
+ Jacob Wieland - Spirent    +
+ 30-04-2014 09:31    +
+ 		+ + + + +
+ As we also encountered the case that a codec shall behave differently when decoding a received message and decoding via decvalue, Testing Technologies would also appreciate a new function tciDecValue (and, of course, tciEncValue).
+
+This way, we would solve two issues with one CR ;-)
+
+
+
+ + + + + + + + + + +
+ (0012085) +
+ Tomas Urban    +
+ 16-06-2014 13:51    +
+ 		+ + + + +
+ Proposal uploaded. Please check.
+
+
+
+ + + + + + + + + + +
+ (0012095) +
+ Jacob Wieland - Spirent    +
+ 17-06-2014 07:22    +
+ 		+ + + + +
+ fine by me
+
+ + diff --git a/docs/mantis/CR6670.md b/docs/mantis/CR6670.md new file mode 100644 index 0000000000000000000000000000000000000000..6ab9ac34d4899f9ed43b43d62605cd082c378c23 --- /dev/null +++ b/docs/mantis/CR6670.md @@ -0,0 +1,135 @@ + + + + + + + + + + + + + 0006670: Restrictions on the decvalue function - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006670Part 01: TTCN-3 Core LanguageTechnicalpublic10-01-2014 14:4005-01-2015 17:48
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.5.1 (published 2013-04) 
Target Versionv4.7.1 (published 2015-06)Fixed in Versionv4.7.1 (published 2015-06) 
Clause Reference(s)C.5.2
Source (company - Author)STF 470
Summary0006670: Restrictions on the decvalue function
DescriptionThe current restriction rule for the decvalue function is as follows:
+The restrictions in clause 16.1.2 apply. If any of these restrictions is applicable, the return value shall be 1.
+
+I believe that the second sentence is invalid and should be applied only to the restriction a.3 of 16.1.2. Breaching any of the remaining restrictions should lead to a compilation error.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR6670_v1.docx (57,907) 07-10-2014 11:44
http://oldforge.etsi.org/mantis/file_download.php?file_id=3095&type=bug
Issue History
Date ModifiedUsernameFieldChange
10-01-2014 14:40Tomas UrbanNew Issue
10-01-2014 14:40Tomas UrbanClause Reference(s) => C.5.2
10-01-2014 14:40Tomas UrbanSource (company - Author) => STF 470
07-04-2014 14:43Gyorgy RethyNote Added: 0011943
07-04-2014 14:43Gyorgy RethyAssigned To => Gyorgy Rethy
07-04-2014 14:43Gyorgy RethyStatusnew => assigned
08-04-2014 16:52Gyorgy RethyTarget Version => v4.7.1 (published 2015-06)
06-10-2014 15:08Gyorgy RethyAssigned ToGyorgy Rethy => Tomas Urban
07-10-2014 11:44Tomas UrbanFile Added: CR6670_v1.docx
07-10-2014 11:46Tomas UrbanNote Added: 0012252
07-10-2014 11:46Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
07-10-2014 11:46Tomas UrbanStatusassigned => confirmed
08-10-2014 09:38Gyorgy RethyStatusconfirmed => resolved
08-10-2014 09:38Gyorgy RethyResolutionopen => fixed
08-10-2014 09:38Gyorgy RethyFixed in Version => v4.7.1 (published 2015-06)
05-01-2015 17:48Gyorgy RethyNote Added: 0012626
05-01-2015 17:48Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011943) +
+ Gyorgy Rethy    +
+ 07-04-2014 14:43    +
+ 		+ + + + +
+ Sentence related to 16.1.2 to be removed. Return values are related to the result of the decoding, this to be clarified in the text.
+
+
+
+ + + + + + + + + + +
+ (0012252) +
+ Tomas Urban    +
+ 07-10-2014 11:46    +
+ 		+ + + + +
+ Resolution draft uploaded.
+Please check.
+
+
+
+ + + + + + + + + + +
+ (0012626) +
+ Gyorgy Rethy    +
+ 05-01-2015 17:48    +
+ 		+ + + + +
+ Added to draft V4.6.3
+
+ + diff --git a/docs/mantis/CR6671.md b/docs/mantis/CR6671.md new file mode 100644 index 0000000000000000000000000000000000000000..1a20fbdee21a21170e8eecb8f1ec106f49c056fe --- /dev/null +++ b/docs/mantis/CR6671.md @@ -0,0 +1,102 @@ + + + + + + + + + + + + + 0006671: Const qualifiers missing in C version of xtriConvert - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Extended TRI (ES 202 789)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006671Ext Pack: Extended TRI (ES 202 789)Technicalpublic20-01-2014 12:4619-12-2014 09:34
ReporterTomas Urban 
Assigned ToTomas Urban 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv1.2.1 (published 2013-04) 
Target Versionv1.4.1 (published 2015-06)Fixed in Versionv1.4.1 (published 2015-06) 
Clause Reference(s)
Source (company - Author)
Summary0006671: Const qualifiers missing in C version of xtriConvert
DescriptionThe current mapping of the xtriConvert function into C is:
+Value xtriConvert (Object* value, Type* typeHypothesis)
+
+However, all other C functions use the const qualifier for input parameters, thus the correct mapping should be:
+Value xtriConvert (const Object* value, const Type* typeHypothesis)
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR6671_v1.docx (17,633) 11-04-2014 09:55
http://oldforge.etsi.org/mantis/file_download.php?file_id=3013&type=bug
Issue History
Date ModifiedUsernameFieldChange
20-01-2014 12:46Tomas UrbanNew Issue
08-04-2014 08:50Gyorgy RethyAssigned To => Tomas Urban
08-04-2014 08:50Gyorgy RethyStatusnew => assigned
08-04-2014 17:08Gyorgy RethyTarget Version => v1.4.1 (published 2015-06)
11-04-2014 09:55Tomas UrbanFile Added: CR6671_v1.docx
11-04-2014 09:55Tomas UrbanNote Added: 0012020
11-04-2014 09:55Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
11-04-2014 09:55Tomas UrbanStatusassigned => confirmed
08-10-2014 08:18Gyorgy RethyAssigned ToGyorgy Rethy => Tomas Urban
08-10-2014 08:18Gyorgy RethyStatusconfirmed => resolved
08-10-2014 08:18Gyorgy RethyResolutionopen => fixed
08-10-2014 08:18Gyorgy RethyFixed in Version => v1.4.1 (published 2015-06)
19-12-2014 09:34Tomas UrbanNote Added: 0012566
19-12-2014 09:34Tomas UrbanStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0012020) +
+ Tomas Urban    +
+ 11-04-2014 09:55    +
+ 		+ + + + +
+ Resolution uploaded.
+Please check.
+
+
+
+ + + + + + + + + + +
+ (0012566) +
+ Tomas Urban    +
+ 19-12-2014 09:34    +
+ 		+ + + + +
+ Proposed changes added to the specification draft.
+
+ + diff --git a/docs/mantis/CR6672.md b/docs/mantis/CR6672.md new file mode 100644 index 0000000000000000000000000000000000000000..d6d734b89d32aba2d0d0fb1695572052d25cc37e --- /dev/null +++ b/docs/mantis/CR6672.md @@ -0,0 +1,102 @@ + + + + + + + + + + + + + 0006672: xtriSAErrorReq in C++ mapping is not a pure virtual function - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Extended TRI (ES 202 789)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006672Ext Pack: Extended TRI (ES 202 789)Technicalpublic20-01-2014 13:1719-12-2014 09:35
ReporterTomas Urban 
Assigned ToTomas Urban 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv1.2.1 (published 2013-04) 
Target Versionv1.4.1 (published 2015-06)Fixed in Versionv1.4.1 (published 2015-06) 
Clause Reference(s)
Source (company - Author)
Summary0006672: xtriSAErrorReq in C++ mapping is not a pure virtual function
DescriptionThe xtriSAErrorReq mapping to C++ is defined as follows:
+virtual void xtriSAErrorReq (const String message, const Object *cause);
+
+However, all other TRI, TCI and XTRI are mapped as pure virtual functions, thus correct mapping would be:
+virtual void xtriSAErrorReq (const String message, const Object *cause) = 0;
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR6672_v1.docx (15,274) 11-04-2014 09:44
http://oldforge.etsi.org/mantis/file_download.php?file_id=3011&type=bug
Issue History
Date ModifiedUsernameFieldChange
20-01-2014 13:17Tomas UrbanNew Issue
08-04-2014 08:53Gyorgy RethyAssigned To => Tomas Urban
08-04-2014 08:53Gyorgy RethyStatusnew => assigned
08-04-2014 08:53Gyorgy RethyTarget Version => v1.4.1 (published 2015-06)
11-04-2014 09:44Tomas UrbanFile Added: CR6672_v1.docx
11-04-2014 09:45Tomas UrbanNote Added: 0012018
11-04-2014 09:45Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
11-04-2014 09:45Tomas UrbanStatusassigned => confirmed
08-10-2014 11:09Gyorgy RethyAssigned ToGyorgy Rethy => Tomas Urban
08-10-2014 11:09Gyorgy RethyStatusconfirmed => resolved
08-10-2014 11:09Gyorgy RethyResolutionopen => fixed
08-10-2014 11:09Gyorgy RethyFixed in Version => v1.4.1 (published 2015-06)
19-12-2014 09:35Tomas UrbanNote Added: 0012567
19-12-2014 09:35Tomas UrbanStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0012018) +
+ Tomas Urban    +
+ 11-04-2014 09:45    +
+ 		+ + + + +
+ Resolution uploaded.
+Please check.
+
+
+
+ + + + + + + + + + +
+ (0012567) +
+ Tomas Urban    +
+ 19-12-2014 09:35    +
+ 		+ + + + +
+ Proposed changes added to the specification draft.
+
+ + diff --git a/docs/mantis/CR6673.md b/docs/mantis/CR6673.md new file mode 100644 index 0000000000000000000000000000000000000000..fe4d38a9dd48926f1e86752fe5c63224235385ef --- /dev/null +++ b/docs/mantis/CR6673.md @@ -0,0 +1,168 @@ + + + + + + + + + + + + + 0006673: Typos in C++ mapping - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Extended TRI (ES 202 789)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006673Ext Pack: Extended TRI (ES 202 789)Editorialpublic20-01-2014 13:3619-12-2014 09:46
ReporterTomas Urban 
Assigned ToTomas Urban 
PriorityhighSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv1.2.1 (published 2013-04) 
Target Versionv1.4.1 (published 2015-06)Fixed in Versionv1.4.1 (published 2015-06) 
Clause Reference(s)
Source (company - Author)
Summary0006673: Typos in C++ mapping
DescriptionAll destructors of interface classes have misspelled name (the last letter shall be lower case).
+
+In the extension to TriPlatformPA class, the class name (TriPlatformTe) is misspelled too (initial x is missing).
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR6673_v1.docx (21,679) 11-04-2014 09:51
http://oldforge.etsi.org/mantis/file_download.php?file_id=3012&type=bug
Issue History
Date ModifiedUsernameFieldChange
20-01-2014 13:36Tomas UrbanNew Issue
20-01-2014 13:43Tomas UrbanNote Added: 0011915
08-04-2014 08:55Gyorgy RethyAssigned To => Tomas Urban
08-04-2014 08:55Gyorgy RethyPrioritynormal => high
08-04-2014 08:55Gyorgy RethyStatusnew => assigned
08-04-2014 08:55Gyorgy RethyTarget Version => v1.4.1 (published 2015-06)
11-04-2014 09:51Tomas UrbanFile Added: CR6673_v1.docx
11-04-2014 09:52Tomas UrbanNote Added: 0012019
11-04-2014 09:52Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
11-04-2014 09:52Tomas UrbanStatusassigned => confirmed
08-10-2014 10:24Gyorgy RethyNote Added: 0012271
08-10-2014 10:24Gyorgy RethyAssigned ToGyorgy Rethy => Tomas Urban
08-10-2014 10:24Gyorgy RethyStatusconfirmed => resolved
08-10-2014 10:24Gyorgy RethyResolutionopen => fixed
08-10-2014 10:24Gyorgy RethyFixed in Version => v1.4.1 (published 2015-06)
19-12-2014 09:46Tomas UrbanNote Added: 0012568
19-12-2014 09:46Tomas UrbanStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011915) +
+ Tomas Urban    +
+ 20-01-2014 13:43    +
+ 		+ + + + +
+ It might be also vice-versa: the identifier used in the destructor is correct and class name is misspelled. This is actually the more likely variant, because it such a naming convention is used in all C++ mappings and spellcheckers tend to correct two consequent upper case letters turning the second one to lower case.
+
+
+
+ + + + + + + + + + +
+ (0012019) +
+ Tomas Urban    +
+ 11-04-2014 09:52    +
+ 		+ + + + +
+ Resolution uploaded.
+Please check.
+
+
+
+ + + + + + + + + + +
+ (0012271) +
+ Gyorgy Rethy    +
+ 08-10-2014 10:24    +
+ 		+ + + + +
+ Your presumption is correct. I checked in xTRI versions 1.1.1 and 1.2.1 and in both the class name is xTriCommunicationSA. So, obviously the autocorrect function of word has "corrected" the class names.
+
+
+
+ + + + + + + + + + +
+ (0012568) +
+ Tomas Urban    +
+ 19-12-2014 09:46    +
+ 		+ + + + +
+ Proposed changes added to the specification draft.
+
+ + diff --git a/docs/mantis/CR6674.md b/docs/mantis/CR6674.md new file mode 100644 index 0000000000000000000000000000000000000000..0be06111dfeb22d3ffc570f81e14d96425116338 --- /dev/null +++ b/docs/mantis/CR6674.md @@ -0,0 +1,165 @@ + + + + + + + + + + + + + 0006674: Typos in C++ mapping - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 05: TTCN-3 Runtime Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006674Part 05: TTCN-3 Runtime Interface Technicalpublic20-01-2014 13:3919-12-2014 09:04
ReporterTomas Urban 
Assigned ToTomas Urban 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.4.1 (published 2012-04) 
Target Versionv4.7.1 (published 2015-06)Fixed in Versionv4.7.1 (published 2015-06) 
Clause Reference(s)8
Source (company - Author)Elvior
Summary0006674: Typos in C++ mapping
DescriptionAll destructors of interface classes (TriCommunicationSa, TriCommunicationTe, TriPlatformPa, TriPlatformTe) have misspelled name (the last letter shall be lower case).
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR6674_v1.docx (52,776) 17-06-2014 08:31
http://oldforge.etsi.org/mantis/file_download.php?file_id=3035&type=bug
Issue History
Date ModifiedUsernameFieldChange
20-01-2014 13:39Tomas UrbanNew Issue
20-01-2014 13:39Tomas UrbanClause Reference(s) => 8
20-01-2014 13:39Tomas UrbanSource (company - Author) => Elvior
20-01-2014 13:43Tomas UrbanNote Added: 0011914
08-04-2014 08:56Gyorgy RethyAssigned To => Tomas Urban
08-04-2014 08:56Gyorgy RethyStatusnew => assigned
08-04-2014 08:56Gyorgy RethyTarget Version => v4.7.1 (published 2015-06)
11-04-2014 14:14Tomas UrbanRelationship addedrelated to 0006677
11-04-2014 14:34Tomas UrbanRelationship deletedrelated to 0006677
17-06-2014 08:31Tomas UrbanFile Added: CR6674_v1.docx
17-06-2014 08:32Tomas UrbanNote Added: 0012096
17-06-2014 08:32Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
17-06-2014 08:32Tomas UrbanStatusassigned => confirmed
08-10-2014 10:29Gyorgy RethyNote Added: 0012272
08-10-2014 10:29Gyorgy RethyAssigned ToGyorgy Rethy => Tomas Urban
08-10-2014 10:29Gyorgy RethyStatusconfirmed => resolved
08-10-2014 10:29Gyorgy RethyResolutionopen => fixed
08-10-2014 10:29Gyorgy RethyFixed in Version => v4.7.1 (published 2015-06)
19-12-2014 09:04Tomas UrbanNote Added: 0012564
19-12-2014 09:04Tomas UrbanStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011914) +
+ Tomas Urban    +
+ 20-01-2014 13:43    +
+ 		+ + + + +
+ It might be also vice-versa: the identifier used in the destructor is correct and class name is misspelled. This is actually the more likely variant, because it such a naming convention is used in all C++ mappings and spellcheckers tend to correct two consequent upper case letters turning the second one to lower case.
+
+
+
+ + + + + + + + + + +
+ (0012096) +
+ Tomas Urban    +
+ 17-06-2014 08:32    +
+ 		+ + + + +
+ Resolution uploaded. Please check.
+
+
+
+ + + + + + + + + + +
+ (0012272) +
+ Gyorgy Rethy    +
+ 08-10-2014 10:29    +
+ 		+ + + + +
+ Correct, the same situation as in CR6673 with xTRI. I have checked in TRI version V4.5.1, the class names has a capital last letter.
+
+
+
+ + + + + + + + + + +
+ (0012564) +
+ Tomas Urban    +
+ 19-12-2014 09:04    +
+ 		+ + + + +
+ Proposed change added to the specification draft.
+
+ + diff --git a/docs/mantis/CR6676.md b/docs/mantis/CR6676.md new file mode 100644 index 0000000000000000000000000000000000000000..9fa108c21a4a5e1d05e3f3ea008959cb3c8ceb32 --- /dev/null +++ b/docs/mantis/CR6676.md @@ -0,0 +1,75 @@ + + + + + + + + + + + + + 0006676: Incorrect record definition in import example - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006676Part 01: TTCN-3 Core LanguageEditorialpublic24-01-2014 08:2519-06-2014 17:02
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeveritytrivialReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.5.1 (published 2013-04) 
Target Versionv4.7.1 (published 2015-06)Fixed in Versionv4.6.2 (interim 2014) 
Clause Reference(s)8.2.3.1
Source (company - Author)STF 470
Summary0006676: Incorrect record definition in import example
DescriptionThe example 1a. in 8.2.3.1 contains an incorrect definition of the record type MyRecordType which is defined as follows:
+
+type record MyRecordType {
+field1 MyType4,
+field2 integer
+}
+
+The correct definition should be:
+type record MyRecordType {
+MyType4 field1,
+integer field2
+}
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
24-01-2014 08:25Tomas UrbanNew Issue
24-01-2014 08:25Tomas UrbanClause Reference(s) => 8.2.3.1
24-01-2014 08:25Tomas UrbanSource (company - Author) => STF 470
07-04-2014 14:54Gyorgy RethyAssigned To => Gyorgy Rethy
07-04-2014 14:54Gyorgy RethyStatusnew => assigned
08-04-2014 16:52Gyorgy RethyTarget Version => v4.7.1 (published 2015-06)
19-06-2014 17:02Gyorgy RethyNote Added: 0012159
19-06-2014 17:02Gyorgy RethyStatusassigned => closed
19-06-2014 17:02Gyorgy RethyResolutionopen => fixed
19-06-2014 17:02Gyorgy RethyFixed in Version => v4.6.2 (interim 2014)
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0012159) +
+ Gyorgy Rethy    +
+ 19-06-2014 17:02    +
+ 		+ + + + +
+ Fixed in master copy.
+
+ + diff --git a/docs/mantis/CR6677.md b/docs/mantis/CR6677.md new file mode 100644 index 0000000000000000000000000000000000000000..56e42940f603d3731055d991fee26a1bfa6eddf0 --- /dev/null +++ b/docs/mantis/CR6677.md @@ -0,0 +1,241 @@ + + + + + + + + + + + + + 0006677: Additional rule on name class in import - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006677Part 01: TTCN-3 Core LanguageClarificationpublic24-01-2014 10:4006-01-2015 19:17
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.6.1 (published 2014-06) 
Target Versionv4.7.1 (published 2015-06)Fixed in Versionv4.7.1 (published 2015-06) 
Clause Reference(s)8.2.3.1
Source (company - Author)STF 470
Summary0006677: Additional rule on name class in import
DescriptionThe current rules on a name clash caused by import implicitly assume that when the name clash is between a definition from an importing module and an imported definition, then using an unqualified reference means the local definition. However, this fact is never stated directly. The current rules only say that the name clash shall be resolved by adding a module prefix to the imported definition, but never say what happens if there's no prefix.
+
+There are of course examples describing this situation and from the whole text it is obvious that such a reference is a reference to a definition in the current module, but I think it would cause no harm, if an explicit rule was added to the chapter 8.2.3.1 (before the paragraph defining an exception valid for enumerated values):
+
+When there's a name clash between a definition from an importing module and an imported definition, a reference that is not prefixed with a module identifier shall be processed as a reference to the definition from the importing module.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0006694closed Gyorgy Rethy clarify that only module definitions can be prefixed by module identifier 
Attached Filesdocx CR6677_update_proposal.docx (13,731) 10-04-2014 13:35
http://oldforge.etsi.org/mantis/file_download.php?file_id=2999&type=bug
docx CR6677_update_proposal_v2.docx (13,864) 11-04-2014 14:12
http://oldforge.etsi.org/mantis/file_download.php?file_id=3018&type=bug
docx CR6677_update_proposal_v3.docx (13,930) 07-10-2014 09:43
http://oldforge.etsi.org/mantis/file_download.php?file_id=3091&type=bug
Issue History
Date ModifiedUsernameFieldChange
24-01-2014 10:40Tomas UrbanNew Issue
24-01-2014 10:40Tomas UrbanClause Reference(s) => 8.2.3.1
24-01-2014 10:40Tomas UrbanSource (company - Author) => STF 470
07-04-2014 14:57Gyorgy RethyAssigned To => Axel Rennoch
07-04-2014 14:57Gyorgy RethyStatusnew => assigned
08-04-2014 16:53Gyorgy RethyProduct Version => v4.6.1 (published 2014-06)
08-04-2014 16:53Gyorgy RethyTarget Version => v4.7.1 (published 2015-06)
10-04-2014 13:35Axel RennochFile Added: CR6677_update_proposal.docx
10-04-2014 13:35Axel RennochAssigned ToAxel Rennoch => Gyorgy Rethy
10-04-2014 13:36Axel RennochNote Added: 0012005
10-04-2014 13:36Axel RennochStatusassigned => confirmed
10-04-2014 13:48Axel RennochFile Added: CR6691_update_proposal.docx
10-04-2014 13:48Axel RennochFile Deleted: CR6691_update_proposal.docx
11-04-2014 14:01Gyorgy RethyNote Added: 0012029
11-04-2014 14:02Gyorgy RethyAssigned ToGyorgy Rethy => Axel Rennoch
11-04-2014 14:02Gyorgy RethyStatusconfirmed => assigned
11-04-2014 14:12Axel RennochFile Added: CR6677_update_proposal_v2.docx
11-04-2014 14:13Axel RennochNote Added: 0012030
11-04-2014 14:13Tomas UrbanNote Added: 0012031
11-04-2014 14:14Tomas UrbanRelationship addedrelated to 0006674
11-04-2014 14:34Tomas UrbanNote Edited: 0012031bug_revision_view_page.php?bugnote_id=12031#r14
11-04-2014 14:34Tomas UrbanRelationship deletedrelated to 0006674
11-04-2014 14:35Tomas UrbanRelationship addedrelated to 0006694
06-10-2014 15:09Gyorgy RethyStatusassigned => confirmed
06-10-2014 15:11Gyorgy RethyAssigned ToAxel Rennoch => Tomas Urban
07-10-2014 09:43Tomas UrbanFile Added: CR6677_update_proposal_v3.docx
07-10-2014 09:44Tomas UrbanNote Added: 0012247
07-10-2014 09:44Tomas UrbanStatusconfirmed => resolved
07-10-2014 09:44Tomas UrbanResolutionopen => fixed
07-10-2014 09:44Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
06-01-2015 19:17Gyorgy RethyNote Added: 0012660
06-01-2015 19:17Gyorgy RethyStatusresolved => closed
06-01-2015 19:17Gyorgy RethyFixed in Version => v4.7.1 (published 2015-06)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0012005) +
+ Axel Rennoch    +
+ 10-04-2014 13:36    +
+ 		+ + + + +
+ Problem: missing module identifiers refering to own module scope
+
+Approach: missing module identifier is implicitly given by the module name that provides the scope of the reference
+
+
+
+ + + + + + + + + + +
+ (0012029) +
+ Gyorgy Rethy    +
+ 11-04-2014 14:01    +
+ 		+ + + + +
+ As I remember the STF discussion, it was also about name clash between an enumeration value and a local definition's name. In this case the missing prefix does not refer implicitly to the local module. I think what we need (at least), if there is no such statement yet that all definitions can be referred by their qualified names, i.e. the local module name can also be used as the prefix of a qualified name.
+
+
+
+ + + + + + + + + + +
+ (0012030) +
+ Axel Rennoch    +
+ 11-04-2014 14:13    +
+ 		+ + + + +
+ update_proposal_v2 takes into account the cases of enumerated values
+
+
+
+ + + + + + + + + + +
+ (0012031) +
+ Tomas Urban    +
+ 11-04-2014 14:13    +
(edited on: 11-04-2014 14:34)
+ 		+ + + + +
+ That was a different CR: 6694. IMHO, the current resolution is fine for this CR.
+
+
+
+
+
+ + + + + + + + + + +
+ (0012247) +
+ Tomas Urban    +
+ 07-10-2014 09:44    +
+ 		+ + + + +
+ The proposed resolution (with one trivial correction) is ready for inclusion into the next version of the TTCN-3 core language standard.
+
+
+
+ + + + + + + + + + +
+ (0012660) +
+ Gyorgy Rethy    +
+ 06-01-2015 19:17    +
+ 		+ + + + +
+ Added to draft V4.6.3
+
+ + diff --git a/docs/mantis/CR6678.md b/docs/mantis/CR6678.md new file mode 100644 index 0000000000000000000000000000000000000000..06231ff402681ccc584a18b1b121a059c2f53a67 --- /dev/null +++ b/docs/mantis/CR6678.md @@ -0,0 +1,395 @@ + + + + + + + + + + + + + 0006678: Reference to omitted field in the right hand side of an assignment - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006678Part 01: TTCN-3 Core LanguageClarificationpublic04-02-2014 09:3206-01-2015 18:43
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.5.1 (published 2013-04) 
Target Versionv4.7.1 (published 2015-06)Fixed in Versionv4.7.1 (published 2015-06) 
Clause Reference(s)17.1
Source (company - Author)Elvior
Summary0006678: Reference to omitted field in the right hand side of an assignment
DescriptionI am afraid the core language specification doesn't contain any specific guidelines for using a reference to an omitted field in the right hand side of an assignment. Theoretically it should not be allowed, because the restriction 17.1.a requires the RHS value to be a value or template and omit/reference to an omitted field is neither of those. However, I think that such an interpretation is too restrictive and probably no-one reads it this way. I have seen several ETSI test suites which don't follow this strict interpretation.
+
+Therefore I propose to formalize the commonly accepted interpretation by amending the rules for assignment in the following way:
+
+Modify the restriction a:
+The right-hand side of an assignment shall evaluate to a value or template, which is type compatible with the variable at the left-hand side of the assignment or an omitted field or omit symbol.
+
+Add restriction c:
+If the right-hand side of an assignment contains an omitted field or omit symbol, the left-hand side shall contain a reference to an optional field or to a template variable.
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR6678_v1.docx (18,112) 09-04-2014 12:58
http://oldforge.etsi.org/mantis/file_download.php?file_id=2981&type=bug
docx CR6678_resolution_v2.docx (18,922) 10-10-2014 08:57
http://oldforge.etsi.org/mantis/file_download.php?file_id=3139&type=bug
docx CR6678_resolution_v3.docx (19,521) 10-10-2014 09:37
http://oldforge.etsi.org/mantis/file_download.php?file_id=3141&type=bug
docx CR6678_resolution_v4.docx (19,602) 10-10-2014 11:05
http://oldforge.etsi.org/mantis/file_download.php?file_id=3144&type=bug
Issue History
Date ModifiedUsernameFieldChange
04-02-2014 09:32Tomas UrbanNew Issue
04-02-2014 09:32Tomas UrbanClause Reference(s) => 17.1
04-02-2014 09:32Tomas UrbanSource (company - Author) => Elvior
07-04-2014 15:09Gyorgy RethyAssigned To => Tomas Urban
07-04-2014 15:09Gyorgy RethyStatusnew => assigned
08-04-2014 17:00Gyorgy RethyTarget Version => v4.7.1 (published 2015-06)
09-04-2014 12:58Tomas UrbanFile Added: CR6678_v1.docx
09-04-2014 13:00Tomas UrbanNote Added: 0011971
09-04-2014 13:49Tomas UrbanAssigned ToTomas Urban => Jens Grabowski
10-04-2014 11:08Tomas UrbanStatusassigned => confirmed
30-04-2014 09:06Jacob Wieland - SpirentNote Added: 0012057
30-04-2014 09:06Jacob Wieland - SpirentNote Added: 0012058
16-06-2014 09:07Jens GrabowskiAssigned ToJens Grabowski => Tomas Urban
16-06-2014 09:07Jens GrabowskiStatusconfirmed => assigned
16-06-2014 09:48Tomas UrbanNote Added: 0012076
17-06-2014 14:14Gyorgy RethyAssigned ToTomas Urban => Gyorgy Rethy
06-10-2014 15:14Gyorgy RethyStatusassigned => confirmed
10-10-2014 08:56Gyorgy RethyNote Added: 0012336
10-10-2014 08:57Gyorgy RethyFile Added: CR6678_resolution_v2.docx
10-10-2014 08:58Gyorgy RethyAssigned ToGyorgy Rethy => Tomas Urban
10-10-2014 09:37Tomas UrbanFile Added: CR6678_resolution_v3.docx
10-10-2014 09:39Tomas UrbanNote Added: 0012339
10-10-2014 09:39Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
10-10-2014 09:50Gyorgy RethyNote Added: 0012343
10-10-2014 10:57Jacob Wieland - SpirentNote Added: 0012355
10-10-2014 11:05Tomas UrbanFile Added: CR6678_resolution_v4.docx
10-10-2014 11:06Tomas UrbanNote Added: 0012356
04-11-2014 11:28Gyorgy RethyStatusconfirmed => resolved
04-11-2014 11:28Gyorgy RethyFixed in Version => v4.7.1 (published 2015-06)
04-11-2014 11:28Gyorgy RethyResolutionopen => fixed
06-01-2015 18:43Gyorgy RethyNote Added: 0012653
06-01-2015 18:43Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011971) +
+ Tomas Urban    +
+ 09-04-2014 13:00    +
+ 		+ + + + +
+ Draft resolution created. No modifications to the restriction a were made as omit is syntactically a value. New restriction c specifies dedicated rules for handling omit or omitted field occurring in the RHS.
+Please check the proposed resolution.
+
+
+
+ + + + + + + + + + +
+ (0012057) +
+ Jacob Wieland - Spirent    +
+ 30-04-2014 09:06    +
+ 		+ + + + +
+ I don't get it. Since when is 'omit' not a template? It can be used both for unrestricted templates and for templates with omit-restriction.
+
+I think this additional restriction is just a special case of the restriction before it.
+
+
+
+ + + + + + + + + + +
+ (0012058) +
+ Jacob Wieland - Spirent    +
+ 30-04-2014 09:06    +
+ 		+ + + + +
+ But, of course, the case with the optional field in a non-template-variable is relevant.
+
+
+
+ + + + + + + + + + +
+ (0012076) +
+ Tomas Urban    +
+ 16-06-2014 09:48    +
+ 		+ + + + +
+ The whole idea of the proposed restriction is to gather so far scattered or missing rules on handling the omit symbol and omitted non-template fields occuring on the RHS into one place. And you are right that the rule is mostly intended for non-template variables.
+
+In case of templates occuring on the LHS, it describes the process how the overloaded omit literal and omitted field of a non-template variable become a matching symbol. The rule doesn't actually explicitly describe handling of the omit matching symbol on the RHS if the above mentioned transformation has already taken place. This is indeed covered by the restriction b.
+
+I admit it might be partially overlapping with the restriction b, but the expression "reference to an omitted field" is mostly related to non-template variables. If you wish, I might extend this expression by adding "of non-template values" to it, but it will make the rule longer and won't give any actual benefit as there is actually no conflict with the restriction b.
+
+
+
+ + + + + + + + + + +
+ (0012336) +
+ Gyorgy Rethy    +
+ 10-10-2014 08:56    +
+ 		+ + + + +
+ See my proposal in CR6678_resolution_v2.docx.
+
+My intention was to collect rules on template LHS-s in item b) and turn item c) out: when the LHS is a mandatory-kind value, omit and omitted fields are not allowed.
+
+I also found unambiguous "contains a reference to", because {f1:=1, f2:=omit} contains reference to omit, but is a simple record/set value.
+
+Please look at how do you like it this way.
+
+
+
+ + + + + + + + + + +
+ (0012339) +
+ Tomas Urban    +
+ 10-10-2014 09:39    +
+ 		+ + + + +
+ I added a rule explaining the impact of referencing an omitted field on the right hand side of an assignment.
+
+
+
+ + + + + + + + + + +
+ (0012343) +
+ Gyorgy Rethy    +
+ 10-10-2014 09:50    +
+ 		+ + + + +
+ OK with me. If no comment from Jacob, in the next session can be set to resolved.
+
+
+
+ + + + + + + + + + +
+ (0012355) +
+ Jacob Wieland - Spirent    +
+ 10-10-2014 10:57    +
+ 		+ + + + +
+ I do not understand this sentence:
+
+"c) If the left-hand side of the assignment is a reference to a non-optional value object (i.e. a value definition, a mandatory field, a record/set of/array element, a union alternative, a value parameter), the left-hand side shall not be a reference to an omitted field or the omit symbol."
+
+Should the first 'left-hand side' not be 'right-hand side'?
+
+
+
+ + + + + + + + + + +
+ (0012356) +
+ Tomas Urban    +
+ 10-10-2014 11:06    +
+ 		+ + + + +
+ The second one should be "right-hand side". Corrected in version 4.
+
+
+
+ + + + + + + + + + +
+ (0012653) +
+ Gyorgy Rethy    +
+ 06-01-2015 18:43    +
+ 		+ + + + +
+ Added to draft V4.6.3
+
+ + diff --git a/docs/mantis/CR6679.md b/docs/mantis/CR6679.md new file mode 100644 index 0000000000000000000000000000000000000000..71e314f5a2bae84b22aaf073e36c1711d58ad610 --- /dev/null +++ b/docs/mantis/CR6679.md @@ -0,0 +1,204 @@ + + + + + + + + + + + + + 0006679: More generic restriction on import from newer TTCN-3 versions - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006679Part 01: TTCN-3 Core LanguageTechnicalpublic04-02-2014 09:5606-01-2015 16:03
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.5.1 (published 2013-04) 
Target Versionv4.7.1 (published 2015-06)Fixed in Versionv4.7.1 (published 2015-06) 
Clause Reference(s)8.2.3.8
Source (company - Author)STF 470
Summary0006679: More generic restriction on import from newer TTCN-3 versions
DescriptionThe restriction 8.2.3.8.c should be more generic. The restriction currently describes on possible source of import incompatibility (between module language tag and language tags in the import clauses) and on the basis of that makes a conclusion that "a TTCN-3 module can only import from earlier or same editions of TTCN-3 but not from later editions". However, there are other possibilities when this kind of incompatibility might happen:
+- Language tag in the imported module contains higher TTCN-3 version than in the importing module
+- The importing module contains a language tag, but the import clause and the imported module have no language. In this case, the language of the imported module is determined from other (tool-specific) sources according to the restriction b, which might result in a higher TTCN-3 version than in the importing module
+
+In my opinion, the restriction c should be either reduced to the second part of the sentence (which is generic enough to cover all possibilities) or the above mentioned cases should mentioned as well.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR-6697-Resolution-V140410-1.doc (73,728) 10-04-2014 12:27
http://oldforge.etsi.org/mantis/file_download.php?file_id=2992&type=bug
doc CR-6697-Resolution-V140620-2.doc (72,704) 20-06-2014 10:39
http://oldforge.etsi.org/mantis/file_download.php?file_id=3072&type=bug
Issue History
Date ModifiedUsernameFieldChange
04-02-2014 09:56Tomas UrbanNew Issue
04-02-2014 09:56Tomas UrbanClause Reference(s) => 8.2.3.8
04-02-2014 09:56Tomas UrbanSource (company - Author) => STF 470
04-02-2014 12:39Tomas UrbanNote Added: 0011919
04-02-2014 13:17Tomas UrbanNote Deleted: 0011919
07-04-2014 15:29Gyorgy RethyAssigned To => Jens Grabowski
07-04-2014 15:29Gyorgy RethyStatusnew => assigned
08-04-2014 17:00Gyorgy RethyTarget Version => v4.7.1 (published 2015-06)
10-04-2014 12:27Jens GrabowskiFile Added: CR-6697-Resolution-V140410-1.doc
10-04-2014 12:27Jens GrabowskiAssigned ToJens Grabowski => Tomas Urban
10-04-2014 12:28Jens GrabowskiNote Added: 0011996
10-04-2014 12:28Jens GrabowskiStatusassigned => confirmed
10-04-2014 13:14Tomas UrbanNote Added: 0012002
10-04-2014 13:14Tomas UrbanStatusconfirmed => resolved
10-04-2014 13:14Tomas UrbanResolutionopen => fixed
10-04-2014 13:14Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
15-04-2014 14:01Jacob Wieland - SpirentNote Added: 0012039
15-04-2014 14:01Jacob Wieland - SpirentStatusresolved => feedback
15-04-2014 14:01Jacob Wieland - SpirentResolutionfixed => reopened
20-06-2014 10:39Tomas UrbanFile Added: CR-6697-Resolution-V140620-2.doc
20-06-2014 10:40Tomas UrbanNote Added: 0012183
20-06-2014 10:40Tomas UrbanStatusfeedback => assigned
20-06-2014 10:40Tomas UrbanStatusassigned => resolved
20-06-2014 10:40Tomas UrbanResolutionreopened => fixed
06-01-2015 16:03Gyorgy RethyNote Added: 0012640
06-01-2015 16:03Gyorgy RethyStatusresolved => closed
06-01-2015 16:03Gyorgy RethyFixed in Version => v4.7.1 (published 2015-06)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011996) +
+ Jens Grabowski    +
+ 10-04-2014 12:28    +
+ 		+ + + + +
+ Please check
+
+
+
+ + + + + + + + + + +
+ (0012002) +
+ Tomas Urban    +
+ 10-04-2014 13:14    +
+ 		+ + + + +
+ I have found no problems with the resolution.
+Ready for inclusion in the new version of the standard.
+
+
+
+ + + + + + + + + + +
+ (0012039) +
+ Jacob Wieland - Spirent    +
+ 15-04-2014 14:01    +
+ 		+ + + + +
+ there is a 'to' missing after 'has'
+
+
+
+ + + + + + + + + + +
+ (0012183) +
+ Tomas Urban    +
+ 20-06-2014 10:40    +
+ 		+ + + + +
+ Updated according to Jacob's comment.
+
+
+
+ + + + + + + + + + +
+ (0012640) +
+ Gyorgy Rethy    +
+ 06-01-2015 16:03    +
+ 		+ + + + +
+ Added to draft V4.6.3
+
+ + diff --git a/docs/mantis/CR6680.md b/docs/mantis/CR6680.md new file mode 100644 index 0000000000000000000000000000000000000000..4f8bd18dfeebc72b99560ee8657e0ebc66e97bf5 --- /dev/null +++ b/docs/mantis/CR6680.md @@ -0,0 +1,65 @@ + + + + + + + + + + + + + 0006680: Typo in rules on importing from fother TTCN-3 editions and non-TTCN-3 modules - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006680Part 01: TTCN-3 Core LanguageEditorialpublic04-02-2014 12:5619-06-2014 16:56
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeveritytrivialReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.5.1 (published 2013-04) 
Target Versionv4.7.1 (published 2015-06)Fixed in Versionv4.6.2 (interim 2014) 
Clause Reference(s)8.2.3.6
Source (company - Author)STF 470
Summary0006680: Typo in rules on importing from fother TTCN-3 editions and non-TTCN-3 modules
DescriptionIn the following rule, the second "of" should be replaced with "or":
+
+to import from a TTCN-3 module of another edition of (-> OR) from a non-TTCN-3 module the import statement shall contain an appropriate language identifier string
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
04-02-2014 12:56Tomas UrbanNew Issue
04-02-2014 12:56Tomas UrbanClause Reference(s) => 8.2.3.6
04-02-2014 12:56Tomas UrbanSource (company - Author) => STF 470
08-04-2014 09:00Gyorgy RethyAssigned To => Gyorgy Rethy
08-04-2014 09:00Gyorgy RethyStatusnew => assigned
08-04-2014 09:00Gyorgy RethyTarget Version => v4.7.1 (published 2015-06)
19-06-2014 16:56Gyorgy RethyNote Added: 0012157
19-06-2014 16:56Gyorgy RethyStatusassigned => closed
19-06-2014 16:56Gyorgy RethyResolutionopen => fixed
19-06-2014 16:56Gyorgy RethyFixed in Version => v4.6.2 (interim 2014)
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0012157) +
+ Gyorgy Rethy    +
+ 19-06-2014 16:56    +
+ 		+ + + + +
+ Done in master copy
+
+ + diff --git a/docs/mantis/CR6681.md b/docs/mantis/CR6681.md new file mode 100644 index 0000000000000000000000000000000000000000..24f9d076d86c0eabf47b72b69aa3e031c956df32 --- /dev/null +++ b/docs/mantis/CR6681.md @@ -0,0 +1,271 @@ + + + + + + + + + + + + + 0006681: Restriction on types that can be used in port type definition - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006681Part 01: TTCN-3 Core LanguageTechnicalpublic05-02-2014 10:3705-01-2015 18:46
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.5.1 (published 2013-04) 
Target Versionv4.7.1 (published 2015-06)Fixed in Versionv4.7.1 (published 2015-06) 
Clause Reference(s)6.2.9
Source (company - Author)Elvior
Summary0006681: Restriction on types that can be used in port type definition
DescriptionSince it is not possible to define teplates of port or default types or of structured types containing port or default types (restriction a, b in the section 15) and therefore a parameter of communication operation (which is a template instance) cannot be of any of these types, it would be logical that the types cannot be used in a message type list of a port type definition. However, there's no such restriction in the chapter 6.2.9 at the moment.
+
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR6681_update_proposal.docx (18,116) 10-04-2014 14:12
http://oldforge.etsi.org/mantis/file_download.php?file_id=3002&type=bug
docx CR6681_update_proposal_v1.docx (18,206) 11-04-2014 15:45
http://oldforge.etsi.org/mantis/file_download.php?file_id=3019&type=bug
docx CR6681_update_proposal_v1-2.docx (18,804) 16-06-2014 11:41
http://oldforge.etsi.org/mantis/file_download.php?file_id=3030&type=bug
Issue History
Date ModifiedUsernameFieldChange
05-02-2014 10:37Tomas UrbanNew Issue
05-02-2014 10:37Tomas UrbanClause Reference(s) => 6.2.9
05-02-2014 10:37Tomas UrbanSource (company - Author) => Elvior
08-04-2014 11:04Gyorgy RethyAssigned To => Axel Rennoch
08-04-2014 11:04Gyorgy RethyStatusnew => assigned
08-04-2014 11:04Gyorgy RethyTarget Version => v4.7.1 (published 2015-06)
10-04-2014 14:12Axel RennochFile Added: CR6681_update_proposal.docx
10-04-2014 14:12Axel RennochAssigned ToAxel Rennoch => Gyorgy Rethy
10-04-2014 14:12Axel RennochNote Added: 0012007
10-04-2014 14:12Axel RennochStatusassigned => confirmed
11-04-2014 15:45Gyorgy RethyFile Added: CR6681_update_proposal_v1.docx
11-04-2014 15:45Gyorgy RethyNote Added: 0012032
11-04-2014 15:46Gyorgy RethyAssigned ToGyorgy Rethy => Axel Rennoch
11-04-2014 15:46Gyorgy RethyStatusconfirmed => assigned
11-04-2014 15:47Gyorgy RethyStatusassigned => confirmed
15-04-2014 14:09Jacob Wieland - SpirentNote Added: 0012041
16-06-2014 11:41Axel RennochFile Added: CR6681_update_proposal_v1-2.docx
16-06-2014 11:42Axel RennochNote Added: 0012083
16-06-2014 11:43Axel RennochAssigned ToAxel Rennoch => Tomas Urban
16-06-2014 11:43Axel RennochStatusconfirmed => assigned
16-06-2014 11:44Axel RennochNote Added: 0012084
16-06-2014 11:44Axel RennochStatusassigned => confirmed
16-06-2014 13:55Tomas UrbanNote Added: 0012086
16-06-2014 13:55Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
16-06-2014 13:55Tomas UrbanStatusconfirmed => assigned
16-06-2014 13:59Tomas UrbanStatusassigned => confirmed
06-10-2014 15:17Gyorgy RethyStatusconfirmed => resolved
06-10-2014 15:17Gyorgy RethyFixed in Version => v4.7.1 (published 2015-06)
06-10-2014 15:17Gyorgy RethyResolutionopen => fixed
05-01-2015 18:46Gyorgy RethyNote Added: 0012633
05-01-2015 18:46Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0012007) +
+ Axel Rennoch    +
+ 10-04-2014 14:12    +
+ 		+ + + + +
+ Problem: port definitions may include references of “messages” types (or of their subparts) “port” or “default”
+
+Analysis: Such types could not be the base of templates to be exchanged at ports and need to be forbidden.
+
+
+
+ + + + + + + + + + +
+ (0012032) +
+ Gyorgy Rethy    +
+ 11-04-2014 15:45    +
+ 		+ + + + +
+ Technically fine. More direct wording is proposed in CR6681_update_proposal_v1.docx. Please check if you agree.
+
+
+
+ + + + + + + + + + +
+ (0012041) +
+ Jacob Wieland - Spirent    +
+ 15-04-2014 14:09    +
+ 		+ + + + +
+ Is this not covered by the defined term 'data type'?
+
+
+
+ + + + + + + + + + +
+ (0012083) +
+ Axel Rennoch    +
+ 16-06-2014 11:42    +
+ 		+ + + + +
+ wording changed, now using the predefined term "data type"
+
+
+
+ + + + + + + + + + +
+ (0012084) +
+ Axel Rennoch    +
+ 16-06-2014 11:44    +
+ 		+ + + + +
+ minor text change now using predefined term from section 3.1
+
+
+
+ + + + + + + + + + +
+ (0012086) +
+ Tomas Urban    +
+ 16-06-2014 13:55    +
+ 		+ + + + +
+ I am fine with this solution. Please check and if you have no objections, I think the proposed restriction can be added to the standard.
+
+
+
+ + + + + + + + + + +
+ (0012633) +
+ Gyorgy Rethy    +
+ 05-01-2015 18:46    +
+ 		+ + + + +
+ Added to draft V4.6.3
+
+ + diff --git a/docs/mantis/CR6682.md b/docs/mantis/CR6682.md new file mode 100644 index 0000000000000000000000000000000000000000..c2ecbc1a119ffcc121cef623fc0f49eee7f6510e --- /dev/null +++ b/docs/mantis/CR6682.md @@ -0,0 +1,100 @@ + + + + + + + + + + + + + 0006682: Strong typing compatibility rules for connect and map - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006682Part 01: TTCN-3 Core LanguageTechnicalpublic05-02-2014 12:0405-01-2015 18:43
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritylowSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.5.1 (published 2013-04) 
Target Versionv4.7.1 (published 2015-06)Fixed in Versionv4.7.1 (published 2015-06) 
Clause Reference(s)6.3.4
Source (company - Author)STF 470
Summary0006682: Strong typing compatibility rules for connect and map
DescriptionThe strong typing rules specified for communication operation in 6.3.4 shall be valid also when checking compatibility of inlists and outlists of ports used as arguments of connect and map operations. The curent rules don't explicitly state that and it leaves some space for alternative interpretations. Adding an explicit rule into 6.3.4 would remove any kind of ambiguity.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR6682_update_proposal.docx (16,931) 10-04-2014 14:18
http://oldforge.etsi.org/mantis/file_download.php?file_id=3003&type=bug
Issue History
Date ModifiedUsernameFieldChange
05-02-2014 12:04Tomas UrbanNew Issue
05-02-2014 12:04Tomas UrbanClause Reference(s) => 6.3.4
05-02-2014 12:04Tomas UrbanSource (company - Author) => STF 470
08-04-2014 11:06Gyorgy RethyAssigned To => Axel Rennoch
08-04-2014 11:06Gyorgy RethyStatusnew => assigned
08-04-2014 11:06Gyorgy RethyTarget Version => v4.7.1 (published 2015-06)
10-04-2014 14:18Axel RennochFile Added: CR6682_update_proposal.docx
10-04-2014 14:19Axel RennochAssigned ToAxel Rennoch => Gyorgy Rethy
10-04-2014 14:19Axel RennochNote Added: 0012008
10-04-2014 14:19Axel RennochStatusassigned => confirmed
06-10-2014 15:23Gyorgy RethyAssigned ToGyorgy Rethy => Jens Grabowski
06-10-2014 15:23Gyorgy RethyPrioritynormal => low
06-10-2014 15:24Gyorgy RethyAssigned ToJens Grabowski => Gyorgy Rethy
06-10-2014 15:24Gyorgy RethyStatusconfirmed => resolved
06-10-2014 15:24Gyorgy RethyFixed in Version => v4.7.1 (published 2015-06)
05-01-2015 18:43Gyorgy RethyNote Added: 0012632
05-01-2015 18:43Gyorgy RethyStatusresolved => closed
05-01-2015 18:43Gyorgy RethyResolutionopen => fixed
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0012008) +
+ Axel Rennoch    +
+ 10-04-2014 14:19    +
+ 		+ + + + +
+ Problem: arguments of connect and map operations do not have strong typing requirements
+
+Analysis: should be disallowed to avoid run-time errors
+
+
+
+
+ + + + + + + + + + +
+ (0012632) +
+ Gyorgy Rethy    +
+ 05-01-2015 18:43    +
+ 		+ + + + +
+ Added to draft V4.6.3
+
+ + diff --git a/docs/mantis/CR6683.md b/docs/mantis/CR6683.md new file mode 100644 index 0000000000000000000000000000000000000000..d01e3032910d2fcd609072c36e960c27fc78ee39 --- /dev/null +++ b/docs/mantis/CR6683.md @@ -0,0 +1,312 @@ + + + + + + + + + + + + + 0006683: triUnmapParam call invoked when unmap operation has just one parameter - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 05: TTCN-3 Runtime Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006683Part 05: TTCN-3 Runtime Interface Technicalpublic06-02-2014 07:4419-12-2014 09:07
ReporterTomas Urban 
Assigned ToTomas Urban 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.5.1 (published 2013-04) 
Target Versionv4.7.1 (published 2015-06)Fixed in Versionv4.7.1 (published 2015-06) 
Clause Reference(s)5.5.2
Source (company - Author)Elvior
Summary0006683: triUnmapParam call invoked when unmap operation has just one parameter
DescriptionThe current TRI specification doesn't provide any guidelines for the situation when a parameterized unmap call contains a system port that is mapped to more than one component port. Will there be one triUnmapParam call for the first (or last) component port and common triUnmap calls for the remaining ones? Or will there be triUnmapParam calls for all of them and the values of out parameters will be taken from the first (or last) call?
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filestxt Question_for_TTCN-3_tool_vendors_CR6683.txt (1,620) 14-04-2014 08:56
http://oldforge.etsi.org/mantis/file_download.php?file_id=3021&type=bug
docx CR6683_v1.docx (49,354) 16-06-2014 14:57
http://oldforge.etsi.org/mantis/file_download.php?file_id=3033&type=bug
docx CR6683_v2.docx (49,411) 08-10-2014 11:15
http://oldforge.etsi.org/mantis/file_download.php?file_id=3109&type=bug
Issue History
Date ModifiedUsernameFieldChange
06-02-2014 07:44Tomas UrbanNew Issue
06-02-2014 07:44Tomas UrbanClause Reference(s) => 5.5.2
06-02-2014 07:44Tomas UrbanSource (company - Author) => Elvior
08-04-2014 11:14Gyorgy RethyNote Added: 0011957
08-04-2014 11:14Gyorgy RethyAssigned To => Tomas Urban
08-04-2014 11:14Gyorgy RethyStatusnew => assigned
08-04-2014 11:14Gyorgy RethyTarget Version => v4.7.1 (published 2015-06)
11-04-2014 10:17Tomas UrbanNote Added: 0012021
14-04-2014 08:53Gyorgy RethyFile Added: Question for TTCN-3 tool vendors CR6683.txt
14-04-2014 08:54Gyorgy RethyNote Added: 0012033
14-04-2014 08:56Gyorgy RethyFile Deleted: Question for TTCN-3 tool vendors CR6683.txt
14-04-2014 08:56Gyorgy RethyFile Added: Question_for_TTCN-3_tool_vendors_CR6683.txt
15-04-2014 09:11Jacob Wieland - SpirentNote Added: 0012034
16-06-2014 14:57Tomas UrbanFile Added: CR6683_v1.docx
16-06-2014 14:58Tomas UrbanNote Added: 0012089
16-06-2014 14:58Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
16-06-2014 14:58Tomas UrbanStatusassigned => confirmed
17-06-2014 07:19Jacob Wieland - SpirentNote Added: 0012094
08-10-2014 11:15Gyorgy RethyFile Added: CR6683_v2.docx
08-10-2014 11:15Gyorgy RethyNote Added: 0012275
08-10-2014 11:15Gyorgy RethyAssigned ToGyorgy Rethy => Tomas Urban
08-10-2014 11:15Gyorgy RethyStatusconfirmed => resolved
08-10-2014 11:15Gyorgy RethyResolutionopen => fixed
08-10-2014 11:15Gyorgy RethyFixed in Version => v4.7.1 (published 2015-06)
19-12-2014 09:07Tomas UrbanNote Added: 0012565
19-12-2014 09:07Tomas UrbanStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011957) +
+ Gyorgy Rethy    +
+ 08-04-2014 11:14    +
+ 		+ + + + +
+ Ask other tool vendors how this case has been solved.
+
+
+
+ + + + + + + + + + +
+ (0012021) +
+ Tomas Urban    +
+ 11-04-2014 10:17    +
+ 		+ + + + +
+ Question to TTCN-3 tool vendors send. Answers expected by the beginning of June.
+
+
+
+ + + + + + + + + + +
+ (0012033) +
+ Gyorgy Rethy    +
+ 14-04-2014 08:54    +
+ 		+ + + + +
+ Tomas's mail is uploaded as file attachment.
+
+
+
+ + + + + + + + + + +
+ (0012034) +
+ Jacob Wieland - Spirent    +
+ 15-04-2014 09:11    +
+ 		+ + + + +
+ For Testing Tech, the only consistent semantics is that an
+
+unmap(c:p) param(p1,...,pn)
+
+is equivalent to
+
+foreach (mc:mp | mc:mp is mapped to c:p) {
+  unmap(c:p, mc:mp) param(p1, ..., pn)
+}
+
+That means that there will be a triUnmapParam call for each mapped port (preferably in the order that they were originally mapped to make it unambiguous)
+which also induces a semantics for the inout/out parameters of the unmap param declaration (i.e. if a parameter is an out parameter, the last triUnmapParam call which assigns it a value 'wins', if it is an inout parameter, subsequent assignments to the parameter are done for each triUnmapParam call).
+
+
+
+ + + + + + + + + + +
+ (0012089) +
+ Tomas Urban    +
+ 16-06-2014 14:58    +
+ 		+ + + + +
+ I added a proposal based on the algorithm described by Jacob. A similar change was made for the triUnmap function. Please check
+
+
+
+ + + + + + + + + + +
+ (0012094) +
+ Jacob Wieland - Spirent    +
+ 17-06-2014 07:19    +
+ 		+ + + + +
+ fine with me
+
+
+
+ + + + + + + + + + +
+ (0012275) +
+ Gyorgy Rethy    +
+ 08-10-2014 11:15    +
+ 		+ + + + +
+ OK, one typo is corrected in CR6683_v2.docx.
+
+
+
+ + + + + + + + + + +
+ (0012565) +
+ Tomas Urban    +
+ 19-12-2014 09:07    +
+ 		+ + + + +
+ Proposed change added to the specification draft.
+
+ + diff --git a/docs/mantis/CR6684.md b/docs/mantis/CR6684.md new file mode 100644 index 0000000000000000000000000000000000000000..eeac02fbce708794c8e50d71b7245cddb247229a --- /dev/null +++ b/docs/mantis/CR6684.md @@ -0,0 +1,107 @@ + + + + + + + + + + + + + 0006684: Wrong rule for forbidden mapping - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006684Part 01: TTCN-3 Core LanguageTechnicalpublic06-02-2014 10:0105-01-2015 18:35
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.5.1 (published 2013-04) 
Target Versionv4.7.1 (published 2015-06)Fixed in Versionv4.7.1 (published 2015-06) 
Clause Reference(s)9.1
Source (company - Author)STF 470
Summary0006684: Wrong rule for forbidden mapping
DescriptionThe section 9.1 contains the following rule:
+
+A port owned by a component A can only have a one-to-one connection with the test system interface. This means, connections as shown in figures 7 (b) and 7 (d) are not allowed.
+
+The problem is that the rule actually does not cover the situation in figure 7 (b). There are two connections in this figure: componentA.port1 : TSI and componentA.port2 : TSI. Both are 1:1 connections from the perspective of the involved component ports, thus not breaching the rule.
+
+I propose to update the rule by removing the reference to the figure 7 (b) from the above mentioned rule and adding a new rule:
+
+A port of a test system interface cannot have connection with more than one port owned by a component A. This means, connections as shown in figure 7 (b) are not allowed.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR6684_update_proposal.docx (20,246) 10-04-2014 14:24
http://oldforge.etsi.org/mantis/file_download.php?file_id=3004&type=bug
Issue History
Date ModifiedUsernameFieldChange
06-02-2014 10:01Tomas UrbanNew Issue
06-02-2014 10:01Tomas UrbanClause Reference(s) => 9.1
06-02-2014 10:01Tomas UrbanSource (company - Author) => STF 470
08-04-2014 11:18Gyorgy RethyAssigned To => Axel Rennoch
08-04-2014 11:18Gyorgy RethyStatusnew => assigned
08-04-2014 11:18Gyorgy RethyTarget Version => v4.7.1 (published 2015-06)
10-04-2014 14:24Axel RennochFile Added: CR6684_update_proposal.docx
10-04-2014 14:25Axel RennochAssigned ToAxel Rennoch => Gyorgy Rethy
10-04-2014 14:26Axel RennochNote Added: 0012009
10-04-2014 14:26Axel RennochStatusassigned => confirmed
06-10-2014 15:27Gyorgy RethyStatusconfirmed => resolved
06-10-2014 15:27Gyorgy RethyResolutionopen => fixed
06-10-2014 15:27Gyorgy RethyFixed in Version => v4.7.1 (published 2015-06)
05-01-2015 18:35Gyorgy RethyNote Added: 0012630
05-01-2015 18:35Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0012009) +
+ Axel Rennoch    +
+ 10-04-2014 14:26    +
+ 		+ + + + +
+ Problem: figure 7b is not correctly described
+
+Analysis: contradiction between text and illustration, text need to be separated from figure 7d.
+
+
+
+ + + + + + + + + + +
+ (0012630) +
+ Gyorgy Rethy    +
+ 05-01-2015 18:35    +
+ 		+ + + + +
+ Added to draft V4.6.3
+
+ + diff --git a/docs/mantis/CR6685.md b/docs/mantis/CR6685.md new file mode 100644 index 0000000000000000000000000000000000000000..be8bf7dad0676d1e6e62d2d0eb8c1f5a865b8afb --- /dev/null +++ b/docs/mantis/CR6685.md @@ -0,0 +1,277 @@ + + + + + + + + + + + + + 0006685: Splitting rules for xsd:anyType - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006685Part 09: Using XML with TTCN-3Clarificationpublic06-02-2014 13:3904-11-2015 09:34
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.5.1 (published 2013-04) 
Target Versionv4.6.1 (published 2015-06)Fixed in Versionv4.6.1 (published 2015-06) 
Clause Reference(s)6.8
For STF discussion
Source (company - Author)Elvior
Summary0006685: Splitting rules for xsd:anyType
DescriptionAccording to 6.8, xsd:anyType content is mapped to a record of strings. However, the specification doesn't provide any guideline on how to split received XML content into individual strings which makes matching of these fields nearly impossible.
+
+There's of course a possibility that it is a tool-dependent feature, but in such a case, it should be explicitly stated in the specification so that developers don't include fields of this type in matching patterns of test suites meant for public use (such as the test suites developed in ETSI STFs).
+
+However, I would prefer if binding rules were added to the specification. When creating those rules, all possible content types should be considered, especially:
+- primitive data
+- nested complex content
+- sequence of elements
+- mixed content
+
+The clause 6.8 should contain an example on each of the above mentioned data contents too.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
has duplicate 0006842closed Gyorgy Rethy Rule for anyType shall not be a comment 
has duplicate 0006869closed Gyorgy Rethy AnyType in XSD module is missing embed_values field 
Attached Filesdoc CR6685_resolution_v1.doc (192,512) 08-12-2014 16:46
http://oldforge.etsi.org/mantis/file_download.php?file_id=3193&type=bug
doc CR6685_resolution_v2.doc (208,896) 12-12-2014 11:31
http://oldforge.etsi.org/mantis/file_download.php?file_id=3196&type=bug
doc CR6685_resolution_v3.doc (210,432) 15-12-2014 09:22
http://oldforge.etsi.org/mantis/file_download.php?file_id=3198&type=bug
Issue History
Date ModifiedUsernameFieldChange
06-02-2014 13:39Tomas UrbanNew Issue
06-02-2014 13:39Tomas UrbanClause Reference(s) => 6.8
06-02-2014 13:39Tomas UrbanSource (company - Author) => Elvior
07-04-2014 14:10Jens GrabowskiAssigned To => Gyorgy Rethy
07-04-2014 14:10Jens GrabowskiStatusnew => assigned
07-04-2014 14:10Jens GrabowskiNote Added: 0011940
08-04-2014 17:06Gyorgy RethyTarget Version => v4.6.1 (published 2015-06)
07-11-2014 12:38Gyorgy RethyAssigned ToGyorgy Rethy => Tomas Urban
07-11-2014 12:40Gyorgy RethyNote Added: 0012493
08-12-2014 16:46Gyorgy RethyFile Added: CR6685_resolution_v1.doc
08-12-2014 16:49Gyorgy RethyNote Added: 0012536
08-12-2014 16:50Gyorgy RethyStatusassigned => confirmed
10-12-2014 09:39Tomas UrbanNote Added: 0012537
10-12-2014 09:39Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
11-12-2014 13:34Gyorgy RethyRelationship addedparent of 0006842
11-12-2014 13:36Gyorgy RethyRelationship replacedhas duplicate 0006842
12-12-2014 11:31Gyorgy RethyFile Added: CR6685_resolution_v2.doc
12-12-2014 11:33Gyorgy RethyNote Added: 0012544
12-12-2014 11:34Gyorgy RethyAssigned ToGyorgy Rethy => Tomas Urban
15-12-2014 09:22Tomas UrbanFile Added: CR6685_resolution_v3.doc
15-12-2014 09:25Tomas UrbanNote Added: 0012549
15-12-2014 09:25Tomas UrbanStatusconfirmed => resolved
15-12-2014 09:25Tomas UrbanResolutionopen => fixed
15-12-2014 09:25Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
30-12-2014 20:03Gyorgy RethyNote Added: 0012592
30-12-2014 20:03Gyorgy RethyStatusresolved => closed
30-12-2014 20:03Gyorgy RethyFixed in Version => v4.6.1 (published 2015-06)
04-11-2015 09:34Gyorgy RethyRelationship addedhas duplicate 0006869
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011940) +
+ Jens Grabowski    +
+ 07-04-2014 14:10    +
+ 		+ + + + +
+ György, will investigate the problem.
+
+
+
+ + + + + + + + + + +
+ (0012493) +
+ Gyorgy Rethy    +
+ 07-11-2014 12:40    +
+ 		+ + + + +
+ We shall look at ASN.1, X.695 if they have a rule on using the RECORD OF. If yes, and technically sound, we should take it over, if not, we need to define a technically sound way.
+
+
+
+ + + + + + + + + + +
+ (0012536) +
+ Gyorgy Rethy    +
+ 08-12-2014 16:49    +
+ 		+ + + + +
+ Please find and review the proposed solution in CR6685_resolution_v1.doc. I still have to look at, if the case when the <element> of type anyType is nillable, does it need any additional text or just a note refering to the nillable clause.
+
+
+
+ + + + + + + + + + +
+ (0012537) +
+ Tomas Urban    +
+ 10-12-2014 09:39    +
+ 		+ + + + +
+ The proposed changes are fine by me. For nillable elements, I think a note would be sufficient.
+
+
+
+ + + + + + + + + + +
+ (0012544) +
+ Gyorgy Rethy    +
+ 12-12-2014 11:33    +
+ 		+ + + + +
+ OK, thinking further, I cannot see a reason even for a note (equally we could add notes to take into account other facets influencing the mapping, e.g. minOccurs/maxOccurs), but I have added an example. Pls. check, and if correct, set the CR to resolved.
+
+
+
+ + + + + + + + + + +
+ (0012549) +
+ Tomas Urban    +
+ 15-12-2014 09:25    +
+ 		+ + + + +
+ Apart from one cosmetic problem with quotes (corrected in the 3rd version of the resolution), the proposed changes solve the CR and the resolution can be added to the new version of the TTCN-3 specification.
+
+
+
+ + + + + + + + + + +
+ (0012592) +
+ Gyorgy Rethy    +
+ 30-12-2014 20:03    +
+ 		+ + + + +
+ Added to draft V4.5.3
+
+ + diff --git a/docs/mantis/CR6686.md b/docs/mantis/CR6686.md new file mode 100644 index 0000000000000000000000000000000000000000..9ccfc128af0e79a6494f4e46e8cb176d5647e44b --- /dev/null +++ b/docs/mantis/CR6686.md @@ -0,0 +1,72 @@ + + + + + + + + + + + + + 0006686: Editorial Comments by Elvior during v4.6.1 approval - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006686Part 01: TTCN-3 Core LanguageEditorialpublic07-02-2014 05:2307-02-2014 05:24
ReporterIna Schieferdecker 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.5.1 (published 2013-04) 
Target Versionv4.6.1 (published 2014-06)Fixed in Versionv4.6.1 (published 2014-06) 
Clause Reference(s)see above
Source (company - Author)   Elvior
Summary0006686: Editorial Comments by Elvior during v4.6.1 approval
Description(8.1) TTCN-3:2013 and TTCN-3:2014 are incorrectly defined
+
+(10) module parameters → constants
+
+(20.2.d) runnin → running
+
+(B.1.2.7.f) SuperSet → SubSet
+
+(15.11) Why was only AnyElement excluded from the replacement rule? AnyElementsOrNone should be excluded as well for the same reason.
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
07-02-2014 05:23Ina SchieferdeckerNew Issue
07-02-2014 05:23Ina SchieferdeckerStatusnew => assigned
07-02-2014 05:23Ina SchieferdeckerAssigned To => Ina Schieferdecker
07-02-2014 05:23Ina SchieferdeckerClause Reference(s) => see above
07-02-2014 05:23Ina SchieferdeckerSource (company - Author) => Elvior
07-02-2014 05:24Ina SchieferdeckerNote Added: 0011920
07-02-2014 05:24Ina SchieferdeckerStatusassigned => closed
07-02-2014 05:24Ina SchieferdeckerResolutionopen => fixed
07-02-2014 05:24Ina SchieferdeckerFixed in Version => v4.6.1 (published 2014-06)
07-02-2014 05:24Ina SchieferdeckerTarget Version => v4.6.1 (published 2014-06)
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011920) +
+ Ina Schieferdecker    +
+ 07-02-2014 05:24    +
+ 		+ + + + +
+ Implemented as proposed.
+
+ + diff --git a/docs/mantis/CR6687.md b/docs/mantis/CR6687.md new file mode 100644 index 0000000000000000000000000000000000000000..67cf50aa0f54cb8c4d11b3a827d7d13bdb5958d3 --- /dev/null +++ b/docs/mantis/CR6687.md @@ -0,0 +1,68 @@ + + + + + + + + + + + + + 0006687: Editorial Comments by Elvior during v4.6.1 approval - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006687Part 06: TTCN-3 Control InterfaceEditorialpublic07-02-2014 05:3307-02-2014 05:33
ReporterIna Schieferdecker 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.5.1 (published 2013-04) 
Target Versionv4.6.1 (published 2014-06)Fixed in Versionv4.6.1 (published 2014-06) 
Clause Reference(s)(10.6.4.1)
Source (company - Author)Elvior
Summary0006687: Editorial Comments by Elvior during v4.6.1 approval
Description(10.6.4.1) tliMMismatch_m, tliMReceive_m, tliPrGetCallMismatch_m,
+tliPrGetCall_m, tliPrGetReplyMismatch_m, tliPrGetReply_m,
+tliPrCatchMismatch_m, tliPrCatch_m, tliCheckAnyMismatch_m: the change
+in the function signature is correct, but the used type is not. It
+should be TciValue instead of Value.
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
07-02-2014 05:33Ina SchieferdeckerNew Issue
07-02-2014 05:33Ina SchieferdeckerStatusnew => assigned
07-02-2014 05:33Ina SchieferdeckerAssigned To => Ina Schieferdecker
07-02-2014 05:33Ina SchieferdeckerClause Reference(s) => (10.6.4.1)
07-02-2014 05:33Ina SchieferdeckerSource (company - Author) => Elvior
07-02-2014 05:33Ina SchieferdeckerNote Added: 0011921
07-02-2014 05:33Ina SchieferdeckerStatusassigned => closed
07-02-2014 05:33Ina SchieferdeckerResolutionopen => fixed
07-02-2014 05:33Ina SchieferdeckerFixed in Version => v4.6.1 (published 2014-06)
07-02-2014 05:33Ina SchieferdeckerTarget Version => v4.6.1 (published 2014-06)
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011921) +
+ Ina Schieferdecker    +
+ 07-02-2014 05:33    +
+ 		+ + + + +
+ Implemented as proposed
+
+ + diff --git a/docs/mantis/CR6688.md b/docs/mantis/CR6688.md new file mode 100644 index 0000000000000000000000000000000000000000..be3802d597e53518cd7f9d193882030b5f87a624 --- /dev/null +++ b/docs/mantis/CR6688.md @@ -0,0 +1,276 @@ + + + + + + + + + + + + + 0006688: Log and TLI should support modifiers - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006688Part 06: TTCN-3 Control InterfaceTechnicalpublic07-02-2014 06:4726-01-2015 11:37
ReporterIna Schieferdecker 
Assigned ToTomas Urban 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.5.1 (published 2013-04) 
Target Versionv4.7.1 (published 2015-06)Fixed in Versionv4.7.1 (published 2015-06) 
Clause Reference(s)various
Source (company - Author)Ina Schieferdecker, FOKUS
Summary0006688: Log and TLI should support modifiers
Description@index, @lazy, @fuzzy and @deterministic have been added recently into part 1, but not into TLI or into the log statement.
+
+As e.g. fuzzy or lazy are rather tricky I see the need to enable logging of the current modifier features of a variable, etc.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR6688_v1.docx (424,969) 19-06-2014 13:58
http://oldforge.etsi.org/mantis/file_download.php?file_id=3058&type=bug
Issue History
Date ModifiedUsernameFieldChange
07-02-2014 06:47Ina SchieferdeckerNew Issue
07-02-2014 06:47Ina SchieferdeckerClause Reference(s) => various
07-02-2014 06:47Ina SchieferdeckerSource (company - Author) => Ina Schieferdecker, FOKUS
08-04-2014 11:24Gyorgy RethyAssigned To => Jens Grabowski
08-04-2014 11:24Gyorgy RethyStatusnew => assigned
08-04-2014 11:24Gyorgy RethyTarget Version => v4.7.1 (published 2015-06)
30-04-2014 09:38Jacob Wieland - SpirentNote Added: 0012061
07-05-2014 13:37Jacob Wieland - SpirentNote Added: 0012065
17-06-2014 07:38Jens GrabowskiAssigned ToJens Grabowski => Tomas Urban
18-06-2014 16:20Tomas UrbanNote Added: 0012132
19-06-2014 13:58Tomas UrbanFile Added: CR6688_v1.docx
19-06-2014 13:59Tomas UrbanNote Added: 0012144
19-06-2014 13:59Tomas UrbanAssigned ToTomas Urban => Jens Grabowski
19-06-2014 13:59Tomas UrbanStatusassigned => confirmed
06-10-2014 10:58Jens GrabowskiNote Added: 0012225
06-10-2014 10:59Jens GrabowskiAssigned ToJens Grabowski => Tomas Urban
06-10-2014 10:59Jens GrabowskiStatusconfirmed => assigned
06-10-2014 11:23Tomas UrbanNote Added: 0012227
06-10-2014 11:23Tomas UrbanStatusassigned => resolved
06-10-2014 11:23Tomas UrbanResolutionopen => fixed
17-12-2014 09:40Tomas UrbanNote Added: 0012558
17-12-2014 09:40Tomas UrbanStatusresolved => closed
26-01-2015 11:37Gyorgy RethyFixed in Version => v4.7.1 (published 2015-06)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0012061) +
+ Jacob Wieland - Spirent    +
+ 30-04-2014 09:38    +
+ 		+ + + + +
+ It is also a little bit unclear when the tliVar log event shall occur in case of lazy/fuzzy variables. If it shall occur at assignment of the variable, what would the logged value be (as it not to be evaluated)? In my opinion, the tliVar should be delayed to the time of actual evaluation of the variable. In case of fuzzy variables, it could be called whenever the variable is evaluated.
+
+
+
+ + + + + + + + + + +
+ (0012065) +
+ Jacob Wieland - Spirent    +
+ 07-05-2014 13:37    +
+ 		+ + + + +
+ Another interesting question is what the logging should do with initialized-but-unevaluated lazy/fuzzy variables/parameters (i.e. in tliLog, tliSEnter, tliSLeave).
+
+
+
+ + + + + + + + + + +
+ (0012132) +
+ Tomas Urban    +
+ 18-06-2014 16:20    +
+ 		+ + + + +
+ Proposal:
+@deterministic shall be hadled as a special kind of scope, i.e. the current string parameter "kind" of the tliSEnter and tliSLeave shall contain "@deterministic function" instead of just "function". This way the signature of these calls will remain backwards compatible.
+
+@index doesn't require special handling, as redirect assignments don't have dedicated parameters in the TLI receiving calls and the index of the actual port is available through the at parameter.
+
+@fuzzy and not evaluated @lazy values will be represented by a special TCI value objects. This way the TCI interface prevents the users from examining the value details. The tliVar will always use these objects in case of @fuzzy and @lazy variable assignments and they can appear in tliSEnter, tliSLeave and other parameterized calls as well.
+
+The specification will also define a new dedicated tliVarEvaluate call that occurs every time when a value of @fuzzy or @lazy variable is calculated.
+
+
+
+ + + + + + + + + + +
+ (0012144) +
+ Tomas Urban    +
+ 19-06-2014 13:59    +
+ 		+ + + + +
+ Proposal uploaded, assigned to Jens for cross-checking.
+
+
+
+ + + + + + + + + + +
+ (0012225) +
+ Jens Grabowski    +
+ 06-10-2014 10:58    +
+ 		+ + + + +
+ Proposal is fine with me.
+
+
+
+ + + + + + + + + + +
+ (0012227) +
+ Tomas Urban    +
+ 06-10-2014 11:23    +
+ 		+ + + + +
+ Ready for adding into the standard.
+
+
+
+ + + + + + + + + + +
+ (0012558) +
+ Tomas Urban    +
+ 17-12-2014 09:40    +
+ 		+ + + + +
+ Added to the TCI specification draft 4.6.2.
+
+ + diff --git a/docs/mantis/CR6690.md b/docs/mantis/CR6690.md new file mode 100644 index 0000000000000000000000000000000000000000..e1a944b386d2dc0ee62e7af8395b58c3db80e10c --- /dev/null +++ b/docs/mantis/CR6690.md @@ -0,0 +1,747 @@ + + + + + + + + + + + + + 0006690: Case insensitive pattern matching - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006690Part 01: TTCN-3 Core LanguageNew Featurepublic17-02-2014 16:0128-07-2014 16:43
ReporterWolfgang Seka 
Assigned ToGyorgy Rethy 
PriorityurgentSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.6.1 (published 2014-06) 
Target Versionv4.6.2 (interim 2014)Fixed in Versionv4.6.2 (interim 2014) 
Clause Reference(s)B.1.5, C.4.1
Source (company - Author)MCC160 - Wolfgang
Summary0006690: Case insensitive pattern matching
Descriptionthere is an issue with text based protocols:
+
+E.g. SIP is widely case insensitive. But when looking at existing implementation this is not handled in TTCN.
+Of course it could be handled by codec (e.g. by converting all case insensitive strings to lower case) but that seems to be not the best solution as there are still case sensitve strings and it may be hard to find generic criteria for the codec implementation. Furthermore it seems to be not a good design decision to mandate manipulation of received strings by codec.
+
+=> it seems to be better to add means for case insensitive pattern matching to the TTCN language:
+This may be e.g. by enhancement of the "pattern" keyword:
+  template (present) charstring v_MyPattern := pattern caseinsensitive "*AB*"; /* shall match any string containing "AB", "Ab", "aB", "ab" */
+(Of course this is just an example for how it could be expressed).
+
+In addition the regexp function may be enhanced by a new parameter as well to allow case insensitive regular expressions.
+ 
+My questions to you:
+1. Can you acknowledge the issue as such ??
+2. Is it feasable to add support of case insensitive pattern matching to the TTCN-3 language ??
+3. Assuming the answer to 1./2. is "yes" what can be the time schedule ??
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files? CaseInsensitivePattern.ttcn (1,054) 10-04-2014 08:58
http://oldforge.etsi.org/mantis/file_download.php?file_id=2988&type=bug
doc CR6690_caseInsensitivePattern_resolution_v1.doc (762,880) 11-04-2014 11:21
http://oldforge.etsi.org/mantis/file_download.php?file_id=3014&type=bug
doc CR6690_caseInsensitivePattern_resolution_v2.doc (763,904) 11-04-2014 12:35
http://oldforge.etsi.org/mantis/file_download.php?file_id=3015&type=bug
doc CR6690_caseInsensitivePattern_resolution_v3.doc (764,416) 16-06-2014 09:13
http://oldforge.etsi.org/mantis/file_download.php?file_id=3028&type=bug
doc CR6690_caseInsensitivePattern_resolution_v4.doc (764,416) 17-06-2014 15:42
http://oldforge.etsi.org/mantis/file_download.php?file_id=3038&type=bug
Issue History
Date ModifiedUsernameFieldChange
17-02-2014 16:01Wolfgang SekaNew Issue
20-02-2014 09:25Jacob Wieland - SpirentNote Added: 0011925
07-04-2014 13:26Gyorgy RethyProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
07-04-2014 14:05Jens GrabowskiNote Added: 0011939
07-04-2014 14:06Jens GrabowskiAssigned To => Tomas Urban
07-04-2014 14:06Jens GrabowskiStatusnew => assigned
08-04-2014 13:14Tomas UrbanNote Added: 0011958
08-04-2014 13:22Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
08-04-2014 17:01Gyorgy RethyProduct Version => v4.6.1 (published 2014-06)
08-04-2014 17:01Gyorgy RethyTarget Version => v4.7.1 (published 2015-06)
09-04-2014 12:37Gyorgy RethyPriorityhigh => urgent
09-04-2014 13:19Gyorgy RethyNote Added: 0011972
09-04-2014 13:33Gyorgy RethyNote Edited: 0011972bug_revision_view_page.php?bugnote_id=11972#r6
10-04-2014 08:01Gyorgy RethyNote Added: 0011980
10-04-2014 08:42Gyorgy RethyNote Added: 0011981
10-04-2014 08:50Gyorgy RethyNote Edited: 0011981bug_revision_view_page.php?bugnote_id=11981#r8
10-04-2014 08:55Gyorgy RethyNote Added: 0011982
10-04-2014 08:56Gyorgy RethyFile Added: CaseInsensitivePattern.ttcn
10-04-2014 08:57Gyorgy RethyFile Deleted: CaseInsensitivePattern.ttcn
10-04-2014 08:58Gyorgy RethyFile Added: CaseInsensitivePattern.ttcn
10-04-2014 10:28Gyorgy RethyNote Edited: 0011958bug_revision_view_page.php?bugnote_id=11958#r10
10-04-2014 10:35Gyorgy RethyNote Added: 0011988
10-04-2014 11:13Gyorgy RethyNote Added: 0011989
10-04-2014 11:18Gyorgy RethyNote Added: 0011990
11-04-2014 11:20Gyorgy RethyNote Edited: 0011990bug_revision_view_page.php?bugnote_id=11990#r12
11-04-2014 11:20Gyorgy RethyNote Added: 0012022
11-04-2014 11:21Gyorgy RethyFile Added: CR6690_caseInsensitivePattern_resolution_v1.doc
11-04-2014 11:22Gyorgy RethyNote Added: 0012023
11-04-2014 11:22Gyorgy RethyAssigned ToGyorgy Rethy => Tomas Urban
11-04-2014 11:22Gyorgy RethyStatusassigned => confirmed
11-04-2014 12:35Tomas UrbanFile Added: CR6690_caseInsensitivePattern_resolution_v2.doc
11-04-2014 12:37Tomas UrbanNote Added: 0012024
11-04-2014 12:37Tomas UrbanStatusconfirmed => resolved
11-04-2014 12:37Tomas UrbanResolutionopen => fixed
11-04-2014 12:37Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
15-04-2014 14:07Jacob Wieland - SpirentNote Added: 0012040
15-04-2014 14:07Jacob Wieland - SpirentStatusresolved => feedback
15-04-2014 14:07Jacob Wieland - SpirentResolutionfixed => reopened
30-04-2014 08:39Jacob Wieland - SpirentAssigned ToGyorgy Rethy => Tomas Urban
30-04-2014 08:39Jacob Wieland - SpirentStatusfeedback => confirmed
16-06-2014 09:13Tomas UrbanFile Added: CR6690_caseInsensitivePattern_resolution_v3.doc
16-06-2014 09:13Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
16-06-2014 09:13Tomas UrbanStatusconfirmed => assigned
16-06-2014 09:14Tomas UrbanNote Added: 0012074
17-06-2014 09:36Gyorgy RethyStatusassigned => confirmed
17-06-2014 15:42Gyorgy RethyFile Added: CR6690_caseInsensitivePattern_resolution_v4.doc
17-06-2014 15:55Gyorgy RethyTarget Versionv4.7.1 (published 2015-06) => v4.6.2 (interim 2014)
17-06-2014 15:59Gyorgy RethyNote Added: 0012109
17-06-2014 15:59Gyorgy RethyStatusconfirmed => resolved
17-06-2014 15:59Gyorgy RethyFixed in Version => v4.6.2 (interim 2014)
17-06-2014 15:59Gyorgy RethyResolutionreopened => fixed
20-06-2014 11:55Gyorgy RethyFixed in Versionv4.6.2 (interim 2014) =>
28-07-2014 16:43Gyorgy RethyNote Added: 0012207
28-07-2014 16:43Gyorgy RethyStatusresolved => closed
28-07-2014 16:43Gyorgy RethyFixed in Version => v4.6.2 (interim 2014)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011925) +
+ Jacob Wieland - Spirent    +
+ 20-02-2014 09:25    +
+ 		+ + + + +
+ Testing Tech agrees that such a feature is necessary. We have similar problems in other text-based protocols.
+
+
+
+ + + + + + + + + + +
+ (0011939) +
+ Jens Grabowski    +
+ 07-04-2014 14:05    +
+ 		+ + + + +
+ STF agreed, syntactical alternatives will be investigated by Tomas.
+
+
+
+ + + + + + + + + + +
+ (0011958) +
+ Tomas Urban    +
+ 08-04-2014 13:14    +
(edited on: 10-04-2014 10:28)
+ 		+ + + + +
+ Possible solutions:
+
+1. Using an additional modifier after "pattern". The solution is similar to what was proposed by the reported, but a modifier is used instead of a keyword in order to avoid problems with name clashes in the existing test suites. The proposed keyword (caseinsensitive) seems to be too long, maybe something shorter would be more feasible, e.g. insensitive or nocase:
+pattern @caseinsensitive "*AB*"
+pattern @insensitive "*AB*"
+pattern @nocase "*AB*"
+
+//need to be decided if this reference inherits the case-insensitive-ness or not? If no inheritance, the same template can be matched both in a case-sensitive and case-insensitive ways:
+pattern "{t_pattern}";
+pattern @nocase "{t_pattern}";
+
+Advantages:
+- short syntax
+- it is obvious from the code what should be achieved
+Disadvantages:
+- adds a new modifier
+- static construction, not possible to insert the modifier dynamically
+
+2. Using a dedicated escape sequence in the beginning of the pattern string, e.g. "\I":
+pattern "\I*AB*"
+Advantages:
+- the shortest alternative to write
+- no changes in the general TTCN-3 syntax
+- the escape sequence can be added dynamically to the pattern
+Disadvantages:
+- meaning is not obvious without detailed knowledge of TTCN-3 regular expression syntax
+- possibility of backwards compatibility issues (although \I doesn't represent any metacharacter, it might still be present in existing patterns being interpreted as "I")
+
+3. Using additional parameter of a chosen type (e.g. of a bitstring type restricted to certain length) following the pattern string:
+pattern "*AB*" variant CASE_INSENSITIVE; // where CASE_INSENSITIVE is defined as const bitstring CASE_INSENSITIVE := '10000000'B;
+Advantages:
+- the content of the parameter part can be dynamic
+- allows future extensions and combinations of parameters using bitwise logic (similar to regular expressions in java, C#): pattern "*AB*" variant CASE_INSENSITIVE or4b FUTURE_PARAMETER
+- with parameters defined as useful values (similar to port status strings defined in E.2.2.4), the meaning is obvious to unskilled reader
+- no new keyword/modifier
+Disadvantages:
+- long syntax
+- adding new useful values poses a risk of name clashes
+
+
+
+
+
+ + + + + + + + + + +
+ (0011972) +
+ Gyorgy Rethy    +
+ 09-04-2014 13:19    +
(edited on: 09-04-2014 13:33)
+ 		+ + + + +
+ Thanks for the good analysis. I agree with it, just some additions:
+
+Option 1, Disadvantages
+in all cases it is possible to reference a case insensitive pattern from a case sensitive one, and vice versa; in option 1 its semantic is a matter of decision, but because of e.g. email addresses, URN-s embedded in a case sensitive environment, probably we will need to preserve the case sensitive-ness of the referenced patterns. (Btw. it may become a problem, how to identify case-insensitive fragments of patterns in logs)
+Do we need a more dynamic construction mechanism than this?
+Please note, that in POSIX(like) regex implementations case sensitive-ness causes additional complications, therefore dynamic construction should be kept at the minimum necessary level.
+
+Option 3, +Disadvantage
+Would overload the meaning of "variant" that is a sub-attribute of the encode attribute currently.
+Or, using the current syntax, it would be
+pattern "*AB*" with { variant "CASE_INSENSITIVE" }
+that looks less nice and would mix the rather special variant overwriting rules into the picture.
+
+
+
+
+
+ + + + + + + + + + +
+ (0011980) +
+ Gyorgy Rethy    +
+ 10-04-2014 08:01    +
+ 		+ + + + +
+ Mail from Wolfgang (2014-04-09):
+Hi György,
+
+I don't have a strong preference from stf160 point of view:
+- in general I'll try to encapsulate issues like case-sensitivity
+- I would not expect any name clashes with our test suite (and if so we can solve them - we don't have frozen code)
+- I general I don't have problems with long expressions
+
+but what is important for me is that we can e.g. define a string as base to be used in an expression for case sensitive pattern as well as for case insensitive.
+
+A typical use case for stf160 would be the GenericParam of ETSI's "LibSip" which represents the generic-param definition of RFC 3261:
+generic-param = token [ EQUAL gen-value ]
+gen-value = token / host / quoted-string
+and in TTCN:
+  type record GenericParam
+  {
+    charstring id,
+    charstring paramValue optional
+  }
+For this in TTCN we need some generic receive template which currently is:
+  template (present) GenericParam cr_GenericParam(template (present) charstring p_Id,
+                                                  template charstring p_ParamValue := omit) :=
+  {
+    id := p_Id, // needs to be declared as case-insensitive
+    paramValue := p_ParamValue // needs to be declared as case-insensitive or quoted string (case-sensitive)
+  };
+
+When looking at the above example it seems to be useful that a given pattern can be further declared as case-insensitive i.e. that it is not necessary to declare a pattern as case-insensitive from the beginning.
+So for the above example we would need to "convert" p_Id to be case-insensitive and to assign to paramValue something like (<case insensitive variant of p_ParamValue>, """" & p_ParamValue & """") => another aspect could be whether we will have an "inline" solution or whether we need to go for an explicit definition in which case we may need to define wrapper functions in TTCN (as e.g. we cannot define variables in templates)
+
+Please note that regarding definition of GenericParam we have on-going discussions to change paramValue to a union of token and quotedString to avoid dealing with double quotes in TTCN (but that's a different story)
+
+Best regards
+Wolfgang
+
+
+
+ + + + + + + + + + +
+ (0011981) +
+ Gyorgy Rethy    +
+ 10-04-2014 08:42    +
(edited on: 10-04-2014 08:50)
+ 		+ + + + +
+ Gyorgy's answer (2014-04-10):
+Hi Wolfgang,
+
+Thanks for the explanation. It seems that you may possibly need something to switch the case-insensitive-ness. One problem with this that, as we discussed up to know, embedding case insensitive fragments into case sensitive patterns (e.g. email-addresses, URN-s into a case sensitive string environment) may be needed. But control of case-sensitiveness could be achieved when referencing values from a pattern.
+
+If taking your example, it could be changed to:
+
+  template (present) GenericParam cr_GenericParam( charstring p_Id,
+                                                  template charstring p_ParamValue := omit) :=
+  {
+    id := pattern @nocase "{p_Id}", // "converted to needs to be declared as case-insensitive
+    paramValue := f_processParamValue(p_ParamValue) // needs to be declared as case-insensitive or quoted string (case-sensitive)
+// choice between case sensitive and insensitive matching would need an additional parameter
+  };
+
+function f_processParamValue(template charstring p_ParamValue) return template charstring {
+   if (ispresent(p_ParamValue)) {
+     var charstring t_tmp := valueof(p_ParamValue);
+     return pattern @nocase "{t_tmp}"
+  }
+  else {return omit}
+}
+
+Would something like this be OK with you?
+
+
+
+
+
+ + + + + + + + + + +
+ (0011982) +
+ Gyorgy Rethy    +
+ 10-04-2014 08:55    +
+ 		+ + + + +
+ Wolfgang's example - extended w. switching between case sensitive and insensitive matching is attached in CaseInsensitivePattern.ttcn
+
+
+
+ + + + + + + + + + +
+ (0011988) +
+ Gyorgy Rethy    +
+ 10-04-2014 10:35    +
+ 		+ + + + +
+ STF discussion:
+at this stage go for the pattern @nocase solution without inhering case-sensitive-ness property of referenced patterns.
+
+
+
+ + + + + + + + + + +
+ (0011989) +
+ Gyorgy Rethy    +
+ 10-04-2014 11:13    +
+ 		+ + + + +
+ Mail from Wolfgang (2014-04-10):
+
+Hi György,
+
+yes - would be ok for me.
+
+Best regards
+Wolfgang
+
+
+
+ + + + + + + + + + +
+ (0011990) +
+ Gyorgy Rethy    +
+ 10-04-2014 11:18    +
(edited on: 11-04-2014 11:20)
+ 		+ + + + +
+ STF discussion: The @nocase has to be added to regexp as well, with the same semantics!
+
+
+
+
+
+ + + + + + + + + + +
+ (0012022) +
+ Gyorgy Rethy    +
+ 11-04-2014 11:20    +
+ 		+ + + + +
+ Fists draft resolution text is in CR6690_caseInsensitivePattern_resolution_v1.doc.
+
+
+
+ + + + + + + + + + +
+ (0012023) +
+ Gyorgy Rethy    +
+ 11-04-2014 11:22    +
+ 		+ + + + +
+ Pls. review proposed resolution.
+
+
+
+ + + + + + + + + + +
+ (0012024) +
+ Tomas Urban    +
+ 11-04-2014 12:37    +
+ 		+ + + + +
+ The proposed resolution checked. I have found no major issues, only two small text corrections were made (updated draft uploaded).
+The resolution is ready to be included in the next version of the language standard.
+
+
+
+ + + + + + + + + + +
+ (0012040) +
+ Jacob Wieland - Spirent    +
+ 15-04-2014 14:07    +
+ 		+ + + + +
+ there are two typos:
+
+derefencing (should be dereferencing) and
+
+'the whole resulted pattern' (must be 'the whole resulting pattern')
+
+
+
+ + + + + + + + + + +
+ (0012074) +
+ Tomas Urban    +
+ 16-06-2014 09:14    +
+ 		+ + + + +
+ Updated according to Jacob's comments.
+
+
+
+ + + + + + + + + + +
+ (0012109) +
+ Gyorgy Rethy    +
+ 17-06-2014 15:59    +
+ 		+ + + + +
+ Final check OK
+
+
+
+ + + + + + + + + + +
+ (0012207) +
+ Gyorgy Rethy    +
+ 28-07-2014 16:43    +
+ 		+ + + + +
+ Added to master copy of V4.6.2 (interim 2014)
+
+ + diff --git a/docs/mantis/CR6691.md b/docs/mantis/CR6691.md new file mode 100644 index 0000000000000000000000000000000000000000..6c00e888858ba6bcd5a41a32c280132b8fa98de5 --- /dev/null +++ b/docs/mantis/CR6691.md @@ -0,0 +1,159 @@ + + + + + + + + + + + + + 0006691: Port visibility in compile time in connection operations - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006691Part 01: TTCN-3 Core LanguageClarificationpublic21-02-2014 07:4106-01-2015 19:15
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.5.1 (published 2013-04) 
Target Versionv4.7.1 (published 2015-06)Fixed in Versionv4.7.1 (published 2015-06) 
Clause Reference(s)21.1
Source (company - Author)Elvior
Summary0006691: Port visibility in compile time in connection operations
DescriptionWith the introduction of mtc and system clauses in 4.6.1, it is possible to achieve that all component references in connection operations are strongly typed. However, the current specification doesn't actually say that this strong typing influences port references used in communication operations in any way and it is not obvious whether such port references shall be resolved according to the strong typing rules in compilation time or in runtime using the real component instance. The same problem was present in earlier specifications too, but then it only concerned component variables and reference to self.
+
+Let's demonstrate it on the example:
+
+type port P message { inout integer; }
+type component C1 { port P p1; }
+type component C2 { port P p1, p2; }
+
+testcase TC runs on C1 system C1
+{
+  var C1 v_ptc := C2.create; // valid assignment: C2 is compatible in C1
+  // In the following statement, v_ptc:p2 is not visible according to strong
+  // typing rules, but the real instance contains the port p2. Static check
+  // made in compilation time should print an error, but runtime check would
+  // succeed
+  connect(self:p1, v_ptc:p2);
+}
+
+In strongly typed languages, static checks are typically made in these cases leading to compilation errors. In order to prevent it, it is necessary to use explicit casting. TTCN-3 doesn't have any casting concept, but it is possible to use alternative approaches, such as assignment to a temporary variable or typing on the function level using runs on, mtc and system clauses. For this reason, I suggest to introduce strong typing rules for situations when the component type is known by adding the following rule to the section 21.1.1 and 21.1.2:
+
+If the type of the component referenced in a connection operation is known (either when the component reference is a variable or value returned from a function or the type is defined the runs on, mtc or system clause of the calling function), the referenced port declaration shall be present in this component type.
+
+It would be also beneficial to add an example to demonstrate this rule.
+
+For test suites with untyped mtc and system, everything would remain the same, because only runtime resolution is possible in these cases. If the proposed strong typing rule is not acceptable, the core language specification should still say that the port reference are related to the actual instance. Otherwise there will be different interpretations by tool vendors leading to real test suites portability issues.
+
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR6691_update_proposal.docx (25,754) 10-04-2014 13:49
http://oldforge.etsi.org/mantis/file_download.php?file_id=3001&type=bug
docx CR6691_v2.docx (27,148) 07-10-2014 15:18
http://oldforge.etsi.org/mantis/file_download.php?file_id=3100&type=bug
docx CR6691_v3.docx (21,601) 07-10-2014 15:29
http://oldforge.etsi.org/mantis/file_download.php?file_id=3101&type=bug
Issue History
Date ModifiedUsernameFieldChange
21-02-2014 07:41Tomas UrbanNew Issue
07-04-2014 15:43Gyorgy RethyNote Added: 0011944
07-04-2014 15:51Gyorgy RethyAssigned To => Axel Rennoch
07-04-2014 15:51Gyorgy RethyStatusnew => assigned
08-04-2014 17:01Gyorgy RethyTarget Version => v4.7.1 (published 2015-06)
10-04-2014 13:49Axel RennochFile Added: CR6691_update_proposal.docx
10-04-2014 13:49Axel RennochAssigned ToAxel Rennoch => Gyorgy Rethy
10-04-2014 13:50Axel RennochNote Added: 0012006
10-04-2014 13:50Axel RennochStatusassigned => confirmed
06-10-2014 15:29Gyorgy RethyAssigned ToGyorgy Rethy => Jens Grabowski
07-10-2014 15:18Tomas UrbanFile Added: CR6691_v2.docx
07-10-2014 15:29Jens GrabowskiFile Added: CR6691_v3.docx
07-10-2014 15:29Jens GrabowskiAssigned ToJens Grabowski => Gyorgy Rethy
07-10-2014 15:29Jens GrabowskiStatusconfirmed => assigned
07-10-2014 15:29Jens GrabowskiStatusassigned => resolved
07-10-2014 15:29Jens GrabowskiResolutionopen => fixed
06-01-2015 19:15Gyorgy RethyNote Added: 0012659
06-01-2015 19:15Gyorgy RethyStatusresolved => closed
06-01-2015 19:15Gyorgy RethyFixed in Version => v4.7.1 (published 2015-06)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011944) +
+ Gyorgy Rethy    +
+ 07-04-2014 15:43    +
+ 		+ + + + +
+ stf478, 2014-04-07: type-restriction based limitation applies, i.e. the above connect example shall produce an error. Standard has to be checked, if it is unambiguous from the text and amend if needed.
+
+
+
+ + + + + + + + + + +
+ (0012006) +
+ Axel Rennoch    +
+ 10-04-2014 13:50    +
+ 		+ + + + +
+ Problem: assignments to component instance may cause non-visible ports within components
+
+Approach: existing port identifiers that are not visible could not be detected at compile time and should not be used in connection statements
+
+
+
+ + + + + + + + + + +
+ (0012659) +
+ Gyorgy Rethy    +
+ 06-01-2015 19:15    +
+ 		+ + + + +
+ Added to draft V4.6.3
+
+ + diff --git a/docs/mantis/CR6692.md b/docs/mantis/CR6692.md new file mode 100644 index 0000000000000000000000000000000000000000..091c5a020981c11054aab65d3c0ba40beb3055cc --- /dev/null +++ b/docs/mantis/CR6692.md @@ -0,0 +1,219 @@ + + + + + + + + + + + + + 0006692: More detailed restriction on parameters of modified templates - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006692Part 01: TTCN-3 Core LanguageClarificationpublic26-02-2014 08:4606-01-2015 19:30
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.5.1 (published 2013-04) 
Target Versionv4.7.1 (published 2015-06)Fixed in Versionv4.7.1 (published 2015-06) 
Clause Reference(s)15.5
Source (company - Author)Elvior
Summary0006692: More detailed restriction on parameters of modified templates
DescriptionThe restriction 15.5.b.1 says that: "the derived template shall not omit parameters defined at any of the modification steps between the base
+template and the actual modified template".
+
+However, the word "omit" might be interpreted in several ways. E.g. it is not clear if the type of the parameter has to remain exactly the same or if it is possible to use a compatible type:
+
+type integer Restricted(0..1)
+template MyType m_src (int p_par) := {...}
+template MyType m_modified (Restricted p_par) modifies m_src := {...}
+
+It is also not clear if it is allowed to use a different kind of parameter (i.e. change a value parameter to a template parameter or vice versa) or to add or remove a template restriction:
+
+template MyType m_modified2 (template int p_par) modifies m_src := {...}
+template MyType m_modified3 (template(omit) int p_par) modifies m_modified2 := {...}
+
+In my opinion, the restriction should describe these situations to avoid possible different interpretations by tool vendors.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR6692_v1-140616-JG.docx (22,517) 18-06-2014 08:28
http://oldforge.etsi.org/mantis/file_download.php?file_id=3043&type=bug
docx CR6692_v2-140618-TU.docx (26,877) 18-06-2014 13:44
http://oldforge.etsi.org/mantis/file_download.php?file_id=3052&type=bug
Issue History
Date ModifiedUsernameFieldChange
26-02-2014 08:46Tomas UrbanNew Issue
07-04-2014 15:54Gyorgy RethyAssigned To => Gyorgy Rethy
07-04-2014 15:54Gyorgy RethyStatusnew => assigned
07-04-2014 16:07Gyorgy RethyAssigned ToGyorgy Rethy => Jens Grabowski
08-04-2014 17:02Gyorgy RethyTarget Version => v4.7.1 (published 2015-06)
30-04-2014 09:21Jacob Wieland - SpirentNote Added: 0012059
17-06-2014 14:01Jens GrabowskiNote Added: 0012107
17-06-2014 14:08Gyorgy RethyNote Edited: 0012107bug_revision_view_page.php?bugnote_id=12107#r27
18-06-2014 08:28Jens GrabowskiNote Added: 0012117
18-06-2014 08:28Jens GrabowskiFile Added: CR6692_v1-140616-JG.docx
18-06-2014 08:29Jens GrabowskiAssigned ToJens Grabowski => Tomas Urban
18-06-2014 08:29Jens GrabowskiStatusassigned => confirmed
18-06-2014 13:44Tomas UrbanFile Added: CR6692_v2-140618-TU.docx
18-06-2014 13:48Tomas UrbanNote Added: 0012125
18-06-2014 13:48Tomas UrbanStatusconfirmed => resolved
18-06-2014 13:48Tomas UrbanResolutionopen => fixed
18-06-2014 13:48Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
06-01-2015 19:30Gyorgy RethyNote Added: 0012663
06-01-2015 19:30Gyorgy RethyStatusresolved => closed
06-01-2015 19:30Gyorgy RethyFixed in Version => v4.7.1 (published 2015-06)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0012059) +
+ Jacob Wieland - Spirent    +
+ 30-04-2014 09:21    +
+ 		+ + + + +
+ The resulting clarification should take care of the semantics of modification, insofar that a changed parameter type (either by being more or less restrictive) or a changed template modifier (either adding or removing accepted actual parameters) must still be processable by the parent-template definition before the modifications of the modifying template are applied to it.
+
+Therefore, in my opinion, only more restrictive types/template-restrictions should be allowed for the inherited parameters in the modifying template, if the parameters are to be changeable at all.
+
+If you allow less-restrictive types/template-restrictions, this would be confusing as the modifying template would practically be undefined for values not accepted by the parent template, even though the signature of the modifying template suggests that it would accept these actual parameters.
+
+
+
+ + + + + + + + + + +
+ (0012107) +
+ Jens Grabowski    +
+ 17-06-2014 14:01    +
(edited on: 17-06-2014 14:08)
+ 		+ + + + +
+ STF discussion: Template parameters shall not ommitted and their types or names be changed, but template parameter restrictions can be changed to a stricter one.
+
+
+
+
+
+ + + + + + + + + + +
+ (0012117) +
+ Jens Grabowski    +
+ 18-06-2014 08:28    +
+ 		+ + + + +
+ Resolution proposal attached. Assigned to Tomas for proofreading.
+
+
+
+ + + + + + + + + + +
+ (0012125) +
+ Tomas Urban    +
+ 18-06-2014 13:48    +
+ 		+ + + + +
+ I made a minor typographical correction (full stop replaced with a semicolon), but appart from that, the proposed rule changes solve the reported issue and are ready to be included to the next version of the standard.
+
+
+
+ + + + + + + + + + +
+ (0012663) +
+ Gyorgy Rethy    +
+ 06-01-2015 19:30    +
+ 		+ + + + +
+ Added to draft V4.6.3
+
+ + diff --git a/docs/mantis/CR6693.md b/docs/mantis/CR6693.md new file mode 100644 index 0000000000000000000000000000000000000000..ff1617f57d72ac4d2c47afaf09c2bc2c96fd63b2 --- /dev/null +++ b/docs/mantis/CR6693.md @@ -0,0 +1,227 @@ + + + + + + + + + + + + + 0006693: Missing rules for omitted values in complement templates - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006693Part 01: TTCN-3 Core LanguageClarificationpublic26-02-2014 10:1606-01-2015 19:22
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.5.1 (published 2013-04) 
Target Versionv4.7.1 (published 2015-06)Fixed in Versionv4.7.1 (published 2015-06) 
Clause Reference(s)B.1.2.2
Source (company - Author)Elvior
Summary0006693: Missing rules for omitted values in complement templates
DescriptionAccording to the discussion in http://www.ttcn-3.org/index.php/forum/forum-core-language/2523-complemented-value-list#7836, [^] complement templates cannot match omitted fields.
+
+However, this rule doesn't seem to be formalized anywhere. The rules for complement say that "a template field that uses complement matches the corresponding field if and only if the field does not match any of the
+values or templates listed in the template list". There's no restriction saying that the match is related to the "field value", but to the field itself.
+
+Let's demonstrate the issue on an example:
+type record R
+{
+  integer field1 optional
+}
+
+var R v_var1 := { field1 := omit }
+log(match(v_var1.field1, 3)); // logs false
+log(match(v_var1.field1, complement(3)));
+
+In my opinion, the last line of the example fulfils the condition that "the field does not match any of the values or templates listed in the template list" as demonstrated on the previous line and should log "true" as a result.
+
+If the intention of the specification is to exclude omitted values from the match, the original rule shall be amended in the following way:
+
+A template field that uses complement matches the corresponding field if and only if the field value is present and does not match any of the
+values or templates listed in the template list.
+
+In addition to that, the following restriction shall be added:
+
+d) Matching an omitted field with a complement template will always produce negative match.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR6693_update_proposal.docx (15,432) 16-06-2014 11:08
http://oldforge.etsi.org/mantis/file_download.php?file_id=3029&type=bug
Issue History
Date ModifiedUsernameFieldChange
26-02-2014 10:16Tomas UrbanNew Issue
07-04-2014 16:14Gyorgy RethyNote Added: 0011945
07-04-2014 16:14Gyorgy RethyAssigned To => Axel Rennoch
07-04-2014 16:14Gyorgy RethyStatusnew => assigned
08-04-2014 17:02Gyorgy RethyTarget Version => v4.7.1 (published 2015-06)
16-06-2014 11:07Axel RennochNote Added: 0012078
16-06-2014 11:08Axel RennochFile Added: CR6693_update_proposal.docx
16-06-2014 11:11Axel RennochNote Added: 0012079
16-06-2014 11:11Axel RennochStatusassigned => confirmed
16-06-2014 11:12Axel RennochAssigned ToAxel Rennoch => Tomas Urban
16-06-2014 11:12Axel RennochStatusconfirmed => assigned
16-06-2014 11:13Axel RennochNote Added: 0012080
16-06-2014 11:13Axel RennochStatusassigned => confirmed
16-06-2014 11:13Axel RennochNote Deleted: 0012078
16-06-2014 11:19Tomas UrbanNote Added: 0012081
16-06-2014 11:19Tomas UrbanStatusconfirmed => resolved
16-06-2014 11:19Tomas UrbanFixed in Version => v4.7.1 (published 2015-06)
16-06-2014 11:19Tomas UrbanResolutionopen => fixed
16-06-2014 11:19Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
20-06-2014 11:50Gyorgy RethyFixed in Versionv4.7.1 (published 2015-06) =>
06-01-2015 19:22Gyorgy RethyNote Added: 0012661
06-01-2015 19:22Gyorgy RethyStatusresolved => closed
06-01-2015 19:22Gyorgy RethyFixed in Version => v4.7.1 (published 2015-06)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011945) +
+ Gyorgy Rethy    +
+ 07-04-2014 16:14    +
+ 		+ + + + +
+ stf478: Check and clarify text as needed.
+
+
+
+ + + + + + + + + + +
+ (0012079) +
+ Axel Rennoch    +
+ 16-06-2014 11:11    +
+ 		+ + + + +
+ Problem: “complement(…)” should not match “omit”, in case of an absent field (omit), i.e."omit" shall not match the result of a complement calculation
+
+Analysis: According to 15.7.2: complement (…): complement of a list of values or templates; this expectation is not about a missing field, i.e. omit (not any value or “missing field”) could NOT match
+
+Approach: to clarify with an explicit new restiction to B.1.2.2 (see attachment)
+
+
+
+ + + + + + + + + + +
+ (0012080) +
+ Axel Rennoch    +
+ 16-06-2014 11:13    +
+ 		+ + + + +
+ CR checked and draft resolution attached
+
+
+
+ + + + + + + + + + +
+ (0012081) +
+ Tomas Urban    +
+ 16-06-2014 11:19    +
+ 		+ + + + +
+ I am fine with the resolution. Gyorgy, please check it too and if you don't have any objections, I think it can be includede to the standard.
+
+
+
+ + + + + + + + + + +
+ (0012661) +
+ Gyorgy Rethy    +
+ 06-01-2015 19:22    +
+ 		+ + + + +
+ Added to draft V4.6.3
+
+ + diff --git a/docs/mantis/CR6694.md b/docs/mantis/CR6694.md new file mode 100644 index 0000000000000000000000000000000000000000..36b9e9a12d36695fb92d061210862fbf1cac2fd0 --- /dev/null +++ b/docs/mantis/CR6694.md @@ -0,0 +1,210 @@ + + + + + + + + + + + + + 0006694: clarify that only module definitions can be prefixed by module identifier - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006694Part 01: TTCN-3 Core LanguageClarificationpublic26-02-2014 12:5906-01-2015 19:26
ReporterJacob Wieland - Spirent 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.6.1 (published 2014-06) 
Target Versionv4.7.1 (published 2015-06)Fixed in Versionv4.7.1 (published 2015-06) 
Clause Reference(s)section 8
Source (company - Author)Testing Technologies - Jacob Wieland
Summary0006694: clarify that only module definitions can be prefixed by module identifier
Descriptionglobal definitions, i.e. those that are defined directly in module definitions part or a group definition are the only definitions that shall be prefixable by their module identifier. There is some debate that the following paragraph in section 8 also applies to local variables (as seen in conformance test suite case Sem_08020301_GeneralFormatOfImport_006)
+
+"When the definition is referenced in the same module where it is defined, the module identifier of the module (the
+current module) also may be used for prefixing the identifier of the definition."
+
+In my opinion, this is not the intention of the paragraph, so this should be clarified.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0006677closed Gyorgy Rethy Additional rule on name class in import 
Attached Filesdocx CR6694_v1-140616-JG.docx (34,363) 18-06-2014 09:32
http://oldforge.etsi.org/mantis/file_download.php?file_id=3044&type=bug
docx CR6694_v2-140618-TU.docx (43,254) 18-06-2014 14:02
http://oldforge.etsi.org/mantis/file_download.php?file_id=3053&type=bug
Issue History
Date ModifiedUsernameFieldChange
26-02-2014 12:59Jacob Wieland - SpirentNew Issue
07-04-2014 16:28Gyorgy RethyNote Added: 0011946
07-04-2014 16:34Gyorgy RethyNote Edited: 0011946bug_revision_view_page.php?bugnote_id=11946#r2
07-04-2014 16:34Gyorgy RethyAssigned To => Jens Grabowski
07-04-2014 16:34Gyorgy RethyStatusnew => assigned
11-04-2014 14:35Tomas UrbanRelationship addedrelated to 0006677
07-05-2014 16:48Gyorgy RethyProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
11-05-2014 20:49Gyorgy RethyTarget Version => v4.7.1 (published 2015-06)
17-06-2014 13:55Gyorgy RethyNote Added: 0012106
18-06-2014 09:32Jens GrabowskiFile Added: CR6694_v1-140616-JG.docx
18-06-2014 09:32Jens GrabowskiNote Added: 0012119
18-06-2014 09:33Jens GrabowskiAssigned ToJens Grabowski => Tomas Urban
18-06-2014 09:33Jens GrabowskiStatusassigned => confirmed
18-06-2014 14:02Tomas UrbanFile Added: CR6694_v2-140618-TU.docx
18-06-2014 14:05Tomas UrbanNote Added: 0012126
18-06-2014 14:05Tomas UrbanStatusconfirmed => resolved
18-06-2014 14:05Tomas UrbanResolutionopen => fixed
18-06-2014 14:05Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
06-01-2015 19:26Gyorgy RethyNote Added: 0012662
06-01-2015 19:26Gyorgy RethyStatusresolved => closed
06-01-2015 19:26Gyorgy RethyProduct Version => v4.6.1 (published 2014-06)
06-01-2015 19:26Gyorgy RethyFixed in Version => v4.7.1 (published 2015-06)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011946) +
+ Gyorgy Rethy    +
+ 07-04-2014 16:28    +
(edited on: 07-04-2014 16:34)
+ 		+ + + + +
+ stf478: analyze the actual rules and alternative solutions. Check text for enumerated name clash resolution (what takes precedence) and related prefixing rules. Proposal: prefix component definitions with self.
+
+
+
+
+
+ + + + + + + + + + +
+ (0012106) +
+ Gyorgy Rethy    +
+ 17-06-2014 13:55    +
+ 		+ + + + +
+ STF discussion:
+- allow prefixing with module name global definitions only (sentence to be added)
+- make prefixing local definition names deprecated, new sub-clause in Annex G
+
+
+
+ + + + + + + + + + +
+ (0012119) +
+ Jens Grabowski    +
+ 18-06-2014 09:32    +
+ 		+ + + + +
+ Resolution proposal attached, assigned to Tomas for proofreading.
+
+
+
+ + + + + + + + + + +
+ (0012126) +
+ Tomas Urban    +
+ 18-06-2014 14:05    +
+ 		+ + + + +
+ I made one minor change (do -> did) to use the same tense as in other deprecated features.
+
+Otherwise the proposal solves the described issue and is ready to be included in the next version of the standard.
+
+
+
+ + + + + + + + + + +
+ (0012662) +
+ Gyorgy Rethy    +
+ 06-01-2015 19:26    +
+ 		+ + + + +
+ Added to draft V4.6.3
+
+ + diff --git a/docs/mantis/CR6695.md b/docs/mantis/CR6695.md new file mode 100644 index 0000000000000000000000000000000000000000..e8f73ee4e1c833aa17d1b6375a96aa5e0c7bbbd8 --- /dev/null +++ b/docs/mantis/CR6695.md @@ -0,0 +1,300 @@ + + + + + + + + + + + + + 0006695: restriction on arithmetic operators should be put in a restriction section or should be dropped altogether - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006695Part 01: TTCN-3 Core LanguageClarificationpublic04-03-2014 16:4906-01-2015 19:10
ReporterJacob Wieland - Spirent 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.5.1 (published 2013-04) 
Target Versionv4.7.1 (published 2015-06)Fixed in Versionv4.7.1 (published 2015-06) 
Clause Reference(s)7.1.1
Source (company - Author)Testing Technologies - Jacob Wieland
Summary0006695: restriction on arithmetic operators should be put in a restriction section or should be dropped altogether
Descriptionthe restriction on the arithmetic float operators are only mentioned in a NOTE, but not in a proper restriction.
+
+It is unclear why these restrictions exist in the first place as in other languages, clear semantics of using the special values as operands exist:
+
+Infinity * -Infinity == -Infinity
+Infinity * Infinity == Infinity
+-Infinity * -Infinity == Infinity
+Infinity * positive_number == Infinity
+Infinity * 0.0 == NaN
+Infinity * negative_number == -Infinity
+-Infinity * positive_number == -Infinity
+-Infinity * 0.0 == NaN
+-Infinity * negative_number == Infinity
+X * NaN == NaN
+Infinity / (Infinity or NaN or -Infinity) == NaN
+Infinity / positive_number == Infinity
+Infinity / negative_number == -Infinity
+-Infinity / positive_number == -Infinity
+-Infinity / negative_number == Infinity
+-Infinity / (Infinity or NaN or -Infinity) == NaN
+(Infinity or NaN or -Infinity) / Infinity == NaN
+(Infinity or NaN or -Infinity) / -Infinity == NaN
+NaN / X == NaN
+X / NaN == NaN
+
+Therefore, I think the restriction should be dropped.
+
+
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR6695_update_proposal.docx (14,971) 10-04-2014 14:54
http://oldforge.etsi.org/mantis/file_download.php?file_id=3006&type=bug
docx CR6695_update_proposal-v3.docx (13,695) 07-10-2014 15:57
http://oldforge.etsi.org/mantis/file_download.php?file_id=3103&type=bug
Issue History
Date ModifiedUsernameFieldChange
04-03-2014 16:49Jacob Wieland - SpirentNew Issue
07-04-2014 16:46Gyorgy RethyNote Added: 0011947
07-04-2014 16:57Gyorgy RethyAssigned To => Axel Rennoch
07-04-2014 16:57Gyorgy RethyStatusnew => assigned
10-04-2014 14:54Axel RennochFile Added: CR6695_update_proposal.docx
10-04-2014 14:55Axel RennochAssigned ToAxel Rennoch => Gyorgy Rethy
10-04-2014 14:58Axel RennochNote Added: 0012012
10-04-2014 14:58Axel RennochStatusassigned => confirmed
20-06-2014 11:40Gyorgy RethyProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
20-06-2014 11:40Gyorgy RethyProduct Version => v4.5.1 (published 2013-04)
20-06-2014 11:40Gyorgy RethyTarget Version => v4.7.1 (published 2015-06)
06-10-2014 10:24Gyorgy RethyNote Added: 0012219
06-10-2014 10:24Gyorgy RethyNote Edited: 0012219bug_revision_view_page.php?bugnote_id=12219#r67
06-10-2014 10:24Gyorgy RethyNote Edited: 0012219bug_revision_view_page.php?bugnote_id=12219#r68
06-10-2014 12:01Jacob Wieland - SpirentNote Added: 0012228
06-10-2014 15:38Gyorgy RethyNote Added: 0012233
06-10-2014 15:39Gyorgy RethyAssigned ToGyorgy Rethy => Jens Grabowski
07-10-2014 15:57Jens GrabowskiFile Added: CR6695_update_proposal-v3.docx
07-10-2014 15:57Jens GrabowskiAssigned ToJens Grabowski => Gyorgy Rethy
07-10-2014 15:57Jens GrabowskiStatusconfirmed => assigned
07-10-2014 15:57Jens GrabowskiStatusassigned => resolved
07-10-2014 15:57Jens GrabowskiResolutionopen => fixed
06-01-2015 19:10Gyorgy RethyNote Added: 0012658
06-01-2015 19:10Gyorgy RethyStatusresolved => closed
06-01-2015 19:10Gyorgy RethyFixed in Version => v4.7.1 (published 2015-06)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011947) +
+ Gyorgy Rethy    +
+ 07-04-2014 16:46    +
+ 		+ + + + +
+ stf478: check how operations are handled in other languages.
+
+
+
+ + + + + + + + + + +
+ (0012012) +
+ Axel Rennoch    +
+ 10-04-2014 14:58    +
+ 		+ + + + +
+ Problem: a note prevents arithmetic float operators for special float values infinity, -infinity and not_a_number
+
+
+
+Analysis:
+a) IEEE 754:2008 standard allow operation (ch 6.1):
+
+Infinity * -Infinity == -Infinity
+Infinity * Infinity == Infinity
+-Infinity * -Infinity == Infinity
+Infinity * positive_number == Infinity
+Infinity * negative_number == -Infinity
+-Infinity * positive_number == -Infinity
+-Infinity * negative_number == Infinity
+Infinity / positive_number == Infinity
+Infinity / negative_number == -Infinity
+-Infinity / positive_number == -Infinity
+-Infinity / negative_number == Infinity
+
+
+b) IEEE 754:2008 standard defines exceptions (i.e. invalid_operation=NaN, 7.1):
+
+Infinity * 0.0 == NaN
+-Infinity * 0.0 == NaN
+X * NaN == NaN
+Infinity / (Infinity or NaN or -Infinity) == NaN
+-Infinity / (Infinity or NaN or -Infinity) == NaN
+(Infinity or NaN or -Infinity) / Infinity == NaN
+(Infinity or NaN or -Infinity) / -Infinity == NaN
+NaN / X == NaN
+X / NaN == NaN
+
+
+
+
+ + + + + + + + + + +
+ (0012219) +
+ Gyorgy Rethy    +
+ 06-10-2014 10:24    +
+ 		+ + + + +
+ Using float in TTCN-3 is twofold:
+- they are data sent in message fields (e.g. signal strength in dB); in this context special values can also appear
+- used as numbers in the TTCN-3 code (behaviour), e.g. timer values and durations (delays), calculating averages etc. In this context operations make sense, but using special values make not.
+
+We have to decide which way to go: making the note a mandatory text or allow operations an special values?
+
+*It needs STF discussion*
+
+
+
+
+
+ + + + + + + + + + +
+ (0012228) +
+ Jacob Wieland - Spirent    +
+ 06-10-2014 12:01    +
+ 		+ + + + +
+ Treating them differently would be confusing, I think.
+
+
+
+ + + + + + + + + + +
+ (0012233) +
+ Gyorgy Rethy    +
+ 06-10-2014 15:38    +
+ 		+ + + + +
+ Add a sentence that operations of IEEE 754 to be followed.
+
+
+
+ + + + + + + + + + +
+ (0012658) +
+ Gyorgy Rethy    +
+ 06-01-2015 19:10    +
+ 		+ + + + +
+ Added to draft V4.6.3
+
+ + diff --git a/docs/mantis/CR6696.md b/docs/mantis/CR6696.md new file mode 100644 index 0000000000000000000000000000000000000000..605438c03d25bb33ee3ed88267ffa9ee4a49d9bf --- /dev/null +++ b/docs/mantis/CR6696.md @@ -0,0 +1,194 @@ + + + + + + + + + + + + + 0006696: Import of the XSD module - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006696Part 09: Using XML with TTCN-3Technicalpublic05-03-2014 16:2626-01-2015 11:26
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PriorityurgentSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.5.1 (published 2013-04) 
Target Versionv4.6.1 (published 2015-06)Fixed in Versionv4.5.2 (interim 2014) 
Clause Reference(s)5
For STF discussion
Source (company - Author)STF 475
Summary0006696: Import of the XSD module
DescriptionThe specification contains different rules for using the built-in XSD data types in case of implicit and explicit mapping:
+
+Built-in data types, described in detail in clause 6, in case of an implicit conversion are internal to the tool and can be referenced directly by the user, while in case of an explicit conversion, the user shall have to import the XSD.ttcn module (see annex A) in addition to the TTCN-3 modules resulted from the conversion.
+
+First, it is not obvious what the scope of this rule is. Is the rule related just to the internal represantation (that is invisible to the user) in case of implicit conversion and to the generated TTCN-3 modules in case of explicit conversion or is it a rule for all modules that import anything from XSD or is it a general rule for all modules in the test suite (if XSD support is available/switched on)? The specification should provide a clear answer to this question to avoid different interpretations by tool vendors.
+
+Dependent on the answer to the above mentioned questions there are additional issues concerning the situation when the user has to use any of the definitions from the XSD module in the code, e.g. when writing functions that use the types from the XSD module as arguments/return types.
+
+I will start with the situation when XSD types are visible in the user code. In this case, the rule causes a significant problem when writing test suites that should work with both approaches. If the test suite requires to use any of the built-in types, it has to explicitly import the XSD module in order to support explicit conversion. However, it is not clear if this will work with implicit conversion, because the specification doesn't require that a tool using implicit conversion shall support explicit import of the XSD module (even though it is not forbiden either).
+
+It is also not obvious what are the namespace impacts of the "built-in data types ... can be referenced" rule in case of implicit conversion. Does it mean that these names are inserted into the namespace (together with the XSD module) in the same way as in case of an imported module?
+
+In case the above mentioned rule concerns the internal representation/generated modules only, there's a question if a tool using implicit conversion should support explicit import the XSD module in order to use the types defined in it. Again, this is related to the fact that the specification doesn't require the tools using implicit conversion shall support explicit import of the XSD module.
+
+The solution I propose is following:
+1. The rule is related only to the internal representation (in case of implicit approach) and to the generated code (in case of explicit approach), i.e. the definitions from the XSD module cannot be automatically referenced in the modules written by the user.
+2. Tools that use implicit approach should allow explicit import of the XSD module (even if it is not physically present in the test suite, i.e. it is provided by the tool), in order to allow using definitions from it in the modules written by the user.
+
+There is also one minor additional problem connected with the above mentioned rule: it mentions a file name (XSD.ttcn), but the core language specification considers file system mapping to be tool-specific. In my opinion, module name shall be used instead.
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR6696_resolution_v1.doc (89,600) 20-06-2014 10:54
http://oldforge.etsi.org/mantis/file_download.php?file_id=3073&type=bug
doc CR6696_resolution_v2.doc (90,112) 20-06-2014 11:45
http://oldforge.etsi.org/mantis/file_download.php?file_id=3074&type=bug
doc CR6696_resolution_v3.doc (90,624) 23-06-2014 15:49
http://oldforge.etsi.org/mantis/file_download.php?file_id=3075&type=bug
Issue History
Date ModifiedUsernameFieldChange
05-03-2014 16:26Tomas UrbanNew Issue
08-04-2014 09:12Gyorgy RethyAssigned To => Gyorgy Rethy
08-04-2014 09:12Gyorgy RethyPrioritynormal => high
08-04-2014 09:12Gyorgy RethyStatusnew => assigned
08-04-2014 09:12Gyorgy RethyTarget Version => v4.6.1 (published 2015-06)
20-06-2014 10:01Gyorgy RethyPriorityhigh => urgent
20-06-2014 10:54Gyorgy RethyFile Added: CR6696_resolution_v1.doc
20-06-2014 10:55Gyorgy RethyNote Added: 0012184
20-06-2014 10:55Gyorgy RethyAssigned ToGyorgy Rethy => Tomas Urban
20-06-2014 10:55Gyorgy RethyStatusassigned => confirmed
20-06-2014 11:45Tomas UrbanFile Added: CR6696_resolution_v2.doc
20-06-2014 11:49Tomas UrbanNote Added: 0012187
20-06-2014 11:49Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
20-06-2014 11:50Tomas UrbanNote Edited: 0012187bug_revision_view_page.php?bugnote_id=12187#r61
20-06-2014 11:50Tomas UrbanNote Edited: 0012187bug_revision_view_page.php?bugnote_id=12187#r62
23-06-2014 15:49Gyorgy RethyFile Added: CR6696_resolution_v3.doc
23-06-2014 15:51Gyorgy RethyNote Added: 0012194
23-06-2014 15:51Gyorgy RethyStatusconfirmed => resolved
23-06-2014 15:51Gyorgy RethyFixed in Version => v4.6.1 (published 2015-06)
23-06-2014 15:51Gyorgy RethyResolutionopen => fixed
24-06-2014 09:30Gyorgy RethyNote Added: 0012195
24-06-2014 09:30Gyorgy RethyStatusresolved => closed
24-06-2014 09:30Gyorgy RethyFixed in Versionv4.6.1 (published 2015-06) => v4.5.2 (interim 2014)
26-01-2015 11:21Gyorgy RethyFixed in Versionv4.5.2 (interim 2014) => v4.6.1 (published 2015-06)
26-01-2015 11:26Gyorgy RethyFixed in Versionv4.6.1 (published 2015-06) => v4.5.2 (interim 2014)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0012184) +
+ Gyorgy Rethy    +
+ 20-06-2014 10:55    +
+ 		+ + + + +
+ Proposed resolution draft is in CR6696_resolution_v1.doc.
+
+Pls. review.
+
+
+
+ + + + + + + + + + +
+ (0012187) +
+ Tomas Urban    +
+ 20-06-2014 11:49    +
(edited on: 20-06-2014 11:50)
+ 		+ + + + +
+ Besides editorial changes, I made two modifications:
+1. Explicit import of the XSD module is possible in case of implicit mapping
+2. Explicit mapping allows to use the "XSD" language tag for importing generated modules as an option.
+
+Both changes are required for writing code that will compile in all TTCN-3 tools regardless of whether they use one or the other conversion.
+
+
+
+
+
+ + + + + + + + + + +
+ (0012194) +
+ Gyorgy Rethy    +
+ 23-06-2014 15:51    +
+ 		+ + + + +
+ Final text in CR6696_resolution_v3.doc.
+
+Added: if importing a TTCN-3 module and the import statement uses the language "XSD" clause, the imported module shall have an XML encode attribute attached.
+
+
+
+ + + + + + + + + + +
+ (0012195) +
+ Gyorgy Rethy    +
+ 24-06-2014 09:30    +
+ 		+ + + + +
+ Implemented in master copy of V4.5.2.
+
+ + diff --git a/docs/mantis/CR6697.md b/docs/mantis/CR6697.md new file mode 100644 index 0000000000000000000000000000000000000000..9ceaf30d1b408ee4e654f1e82948c86e2c0d95f5 --- /dev/null +++ b/docs/mantis/CR6697.md @@ -0,0 +1,770 @@ + + + + + + + + + + + + + 0006697: Missing functionality to check absence of an object - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006697Part 01: TTCN-3 Core LanguageNew Featurepublic06-03-2014 10:5128-07-2014 14:11
ReporterWolfgang Seka 
Assigned ToGyorgy Rethy 
PriorityurgentSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.6.1 (published 2014-06) 
Target Versionv4.6.2 (interim 2014)Fixed in Versionv4.6.2 (interim 2014) 
Clause Reference(s)ES 201 873-1 C.3
Source (company - Author)MCC160 - Wolfgang
Summary0006697: Missing functionality to check absence of an object
DescriptionThere are several functions to check presence of an object but there is no way to check whether an object omit: e.g. isomitted.
+NOTE: "isomitted(inpar)" would not be the same as "not ispresent(inpar)" as in case of "var template MyType v_MyType := *" both functions would result in false.
Steps To Reproduce
Additional InformationUse case:
+The "isomitted" functionality is helpful e.g. for SIP when you want to construct a message which may or may not have a message body (i.e. parameter is either omit or a template); in case of the message body being present the message needs to have a Content-Type.
TagsNo tags attached.
Relationships
related to 0006736closed Gyorgy Rethy new matching mechanism for binary string types 
Attached Filesdocx CR6697_v1.docx (26,820) 10-04-2014 12:56
http://oldforge.etsi.org/mantis/file_download.php?file_id=2994&type=bug
docx CR6697_v2.docx (27,067) 18-04-2014 10:27
http://oldforge.etsi.org/mantis/file_download.php?file_id=3022&type=bug
docx CR6697_v3.docx (39,617) 17-06-2014 16:50
http://oldforge.etsi.org/mantis/file_download.php?file_id=3040&type=bug
docx CR6697_v4.docx (47,746) 01-07-2014 16:41
http://oldforge.etsi.org/mantis/file_download.php?file_id=3077&type=bug
docx CR6697_v5.docx (47,549) 11-07-2014 13:41
http://oldforge.etsi.org/mantis/file_download.php?file_id=3078&type=bug
Issue History
Date ModifiedUsernameFieldChange
06-03-2014 10:51Wolfgang SekaNew Issue
08-04-2014 08:52Gyorgy RethyProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
08-04-2014 09:27Gyorgy RethyNote Added: 0011948
08-04-2014 09:28Gyorgy RethyAssigned To => Jens Grabowski
08-04-2014 09:28Gyorgy RethyStatusnew => assigned
08-04-2014 09:28Gyorgy RethyProduct Version => v4.6.1 (published 2014-06)
08-04-2014 09:28Gyorgy RethyTarget Version => v4.7.1 (published 2015-06)
08-04-2014 10:09Wolfgang SekaNote Added: 0011951
09-04-2014 12:38Gyorgy RethyPrioritynormal => urgent
10-04-2014 10:01Gyorgy RethyAssigned ToJens Grabowski => Tomas Urban
10-04-2014 10:06Gyorgy RethyNote Added: 0011986
10-04-2014 10:07Jacob Wieland - SpirentNote Added: 0011987
10-04-2014 11:26Tomas UrbanNote Added: 0011991
10-04-2014 12:56Tomas UrbanFile Added: CR6697_v1.docx
10-04-2014 12:57Tomas UrbanNote Added: 0011999
10-04-2014 12:57Tomas UrbanAssigned ToTomas Urban => Jens Grabowski
10-04-2014 12:57Tomas UrbanStatusassigned => confirmed
18-04-2014 10:27Gyorgy RethyNote Added: 0012042
18-04-2014 10:27Gyorgy RethyFile Added: CR6697_v2.docx
18-04-2014 10:28Gyorgy RethyAssigned ToJens Grabowski => Tomas Urban
18-04-2014 10:28Gyorgy RethyStatusconfirmed => assigned
18-04-2014 10:28Gyorgy RethyNote Edited: 0012042bug_revision_view_page.php?bugnote_id=12042#r18
18-04-2014 10:29Gyorgy RethyNote Edited: 0012042bug_revision_view_page.php?bugnote_id=12042#r19
22-04-2014 08:34Jacob Wieland - SpirentNote Added: 0012044
22-04-2014 09:30Tomas UrbanNote Added: 0012045
22-04-2014 11:08Jacob Wieland - SpirentNote Added: 0012046
22-04-2014 12:09Tomas UrbanNote Added: 0012047
22-04-2014 12:28Jacob Wieland - SpirentNote Added: 0012048
16-06-2014 10:18Tomas UrbanNote Added: 0012077
17-06-2014 15:56Gyorgy RethyTarget Versionv4.7.1 (published 2015-06) => v4.6.2 (interim 2014)
17-06-2014 16:50Tomas UrbanFile Added: CR6697_v3.docx
17-06-2014 16:57Tomas UrbanNote Added: 0012111
17-06-2014 16:57Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
17-06-2014 16:57Tomas UrbanStatusassigned => confirmed
17-06-2014 16:57Tomas UrbanRelationship addedrelated to 0006736
18-06-2014 20:07Jacob Wieland - SpirentNote Added: 0012135
01-07-2014 16:41Gyorgy RethyFile Added: CR6697_v4.docx
01-07-2014 16:43Gyorgy RethyNote Added: 0012199
01-07-2014 16:44Gyorgy RethyAssigned ToGyorgy Rethy => Tomas Urban
02-07-2014 07:47Tomas UrbanNote Added: 0012200
03-07-2014 07:36Jacob Wieland - SpirentNote Added: 0012201
11-07-2014 13:41Gyorgy RethyFile Added: CR6697_v5.docx
11-07-2014 13:48Gyorgy RethyNote Added: 0012202
11-07-2014 13:48Gyorgy RethyStatusconfirmed => resolved
11-07-2014 13:48Gyorgy RethyFixed in Version => v4.6.2 (interim 2014)
11-07-2014 13:48Gyorgy RethyResolutionopen => fixed
11-07-2014 13:48Gyorgy RethyAssigned ToTomas Urban => Gyorgy Rethy
28-07-2014 14:11Gyorgy RethyNote Added: 0012204
28-07-2014 14:11Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011948) +
+ Gyorgy Rethy    +
+ 08-04-2014 09:27    +
+ 		+ + + + +
+ not ispresent(object) and isvalue (object) could solve the problem.
+
+
+
+ + + + + + + + + + +
+ (0011951) +
+ Wolfgang Seka    +
+ 08-04-2014 10:09    +
+ 		+ + + + +
+ Example:
+
+var template MyType v_MyTemplateVariable1 := cr_MyTemplate;
+var template MyType v_MyTemplateVariable2 := cr_MyTemplate ifpresent;
+var template MyType v_MyTemplateVariable3 := *;
+var template MyType v_MyTemplateVariable4 := omit;
+
+=> acc. to my understanding
+   ispresent returns true for v_MyTemplateVariable1 only but returns false for v_MyTemplateVariable[2..4];
+   isvalue may return true for v_MyTemplateVariable1 but returns false for v_MyTemplateVariable[2..4];
+
+What is interesting for us is to identify v_MyTemplateVariable4 being explicitly set to omit.
+
+
+
+ + + + + + + + + + +
+ (0011986) +
+ Gyorgy Rethy    +
+ 10-04-2014 10:06    +
+ 		+ + + + +
+ STF discussion:
+most widely use-able way would be to convert templates to charstrings; in this case simply a
+ttnc2char(t_Mytemplate) == "omit";
+would give the requested feature.
+
+
+
+ + + + + + + + + + +
+ (0011987) +
+ Jacob Wieland - Spirent    +
+ 10-04-2014 10:07    +
+ 		+ + + + +
+ What is wrong with x == omit? That is allowed by now, is it not?
+
+
+
+ + + + + + + + + + +
+ (0011991) +
+ Tomas Urban    +
+ 10-04-2014 11:26    +
+ 		+ + + + +
+ Comparison with omit is not allowed for two reasons, according to restriction 7.a:
+1) Templates cannot be operands of expression
+2) Operands of expressions have to be completely initialized values and omit is not a value
+
+
+
+ + + + + + + + + + +
+ (0011999) +
+ Tomas Urban    +
+ 10-04-2014 12:57    +
+ 		+ + + + +
+ Definition of the proposed ttcn2char function attached.
+Please check.
+
+
+
+ + + + + + + + + + +
+ (0012042) +
+ Gyorgy Rethy    +
+ 18-04-2014 10:27    +
(edited on: 18-04-2014 10:29)
+ 		+ + + + +
+ A few comments (see CR6697_v2.docx):
+- the <something>2char functions are converting <something> to its character equivalents, e.g. int2char the character codepoint in ISO646 to the character (int2char(65) == "A"); this function will not convert, just print out the content;
+- the <something>2str functions do simply print out the content into a charstring. Therefore I propose that the name of the predef. function should be ttcn2str.
+   -> changed in CR6697_v2.docx
+- I haven't found a description on how to present matching symbols in textual form; in tliLog for example the whole "data" to be logged is a string, i.e. the internal format seems to be tool specific; to allow using simple strings instead of patterns, when checking the content, we should specify the exact format, e.g. in "-1 ifpresent" there shall be exactly 1 space between "-1" and "ifpresent" (do you agree?);
+        -> not defined in CR6697_v2.docx, just the ifpresent example has been added.
+- the function should accept uninitialized, partly and completely initialized input (at different places it was defined differently)
+   -> corrected in CR6697_v2.docx
+
+
+
+
+
+ + + + + + + + + + +
+ (0012044) +
+ Jacob Wieland - Spirent    +
+ 22-04-2014 08:34    +
+ 		+ + + + +
+ Sorry, I am very sure that the restriction of value-only has been lifted for the equality operator. Please check again in the standard in the section about the equality operation.
+
+
+
+ + + + + + + + + + +
+ (0012045) +
+ Tomas Urban    +
+ 22-04-2014 09:30    +
+ 		+ + + + +
+ I am sorry, but I am not aware of any rule allowing templates as operands of the equality operator. The rules of the section 7.1.3 allow values only:
+
+Operands of equality (==) and non-equality (!=) shall be completely initialized values or field references of type compatible root types and the values or field references being compared shall obey the following rules. This implies that instances of types not mentioned below shall not be operands of equality and non-equality.
+
+Two field references are equal if the referenced fields are both optional fields and both fields are set to omit or if both referenced fields (regardless if they are optional or not) are initialized with values and these values are equal. A field reference is equal to a value if the referenced field is initialized with a value and both values are equal.
+
+
+
+ + + + + + + + + + +
+ (0012046) +
+ Jacob Wieland - Spirent    +
+ 22-04-2014 11:08    +
+ 		+ + + + +
+ Well, as you are probably aware, this allows fields that are omit to be compared with values (yields false) or with other fields that are omit (yields true). So, since template(omit) variables/parameters are only stand-ins for field references (either they are assigned a field reference or are used to be assigned to a field reference at some point), it stands to reason that comparing them with omit makes as much sense as comparing a field reference with omit (or with another field reference that is omitted).
+
+Basically, it makes no sense whatsoever to treat a field reference that COULD be omit any differently than omit or a template with omit-restriction.
+
+
+
+ + + + + + + + + + +
+ (0012047) +
+ Tomas Urban    +
+ 22-04-2014 12:09    +
+ 		+ + + + +
+ Jacob, I understand your point, but this is a problem of semantics. Although template(omit) and template(value) are restricted in such a way that their content is a value (or omit), they are still not values in the sense of definition of value specified in the section 3.1.
+
+Then there's a problem of the omit symbol itself. According to the definition of its use specified in the section 5, omit is a symbol used for omission of fields. It is not a value and as such it doesn't fulfil semantic requirements on operands of the equality operation.
+
+However, all I wrote is just my interpretation of the rules. Since it seems that your interpretation is rather different, I think we need a CR to handle this situation explicitly in the standard. Could you please enter one?
+
+
+
+ + + + + + + + + + +
+ (0012048) +
+ Jacob Wieland - Spirent    +
+ 22-04-2014 12:28    +
+ 		+ + + + +
+ Okay, done, but this still does not solve the problem to check whether a non-restricted template is omit. I don't like the string-solution AT ALL. Sure, a to-string operation for templates is a nice thing to have, but we should not encourage people to use it for this intended purpose as that is just a dirty hack/workaround, in my opinion.
+
+
+
+ + + + + + + + + + +
+ (0012077) +
+ Tomas Urban    +
+ 16-06-2014 10:18    +
+ 		+ + + + +
+ I think this issue should be discussed again. I admit that Jacob's position comparing the proposed solution to a dirty hack is a relevant one and well-written code should not use it.
+
+Maybe we should get back to the original proposal or specify a more general function istemplatekind() with two parameters (template, template kind) that would return true if the matching symbol is of certain kind and false otherwise:
+
+var template integer vt_1 := ?, vt_2 := (0..2) ifpresent;
+var boolen v_res;
+...
+v_res := istemplatekind(vt_1, "AnyValue"); // true
+v_res := istemplatekind(vt_1, "AnyValueOrNone"); // false
+v_res := istemplatekind(vt_2, "complement"); // false
+v_res := istemplatekind(vt_2, "list"); // true
+v_res := istemplatekind(vt_2, "ifpresent"); // true
+
+Another option would be to allow using matching symbols and templates as operands of the equality operations and define the rules for this kind of comparison.
+
+Both proposed solutions can be actually implemented together with the ttcn2char function which might be actually handy in some cases. I have one comment to this function as well: It should not return charstring, but universal charstring, since the converted template might contain universal string fields. In case it doesn't, universal charstring conversion to charstring is implicit, so the current functionality won't change.
+
+
+
+ + + + + + + + + + +
+ (0012111) +
+ Tomas Urban    +
+ 17-06-2014 16:57    +
+ 		+ + + + +
+ New proposal uploaded. The biggest change is addition of the new istemplatekind function. The description anticipites addidion of the new @encoded matching mechanism proposed in 0006736. If there are any changes in resolution of CR6736, the current proposal has to be updated accordingly.
+
+I also change the return type and the name of the universal string conversion function from ttcn2str to any2unichar. The "any" part stands for the input parameter which is of "any type" and the second part stands for "universal charstring". So far all functions converting from/to universal charstring used unichar and it would be nice to follow the same naming convension.
+
+Please check.
+
+
+
+ + + + + + + + + + +
+ (0012135) +
+ Jacob Wieland - Spirent    +
+ 18-06-2014 20:07    +
+ 		+ + + + +
+ Seems ok to me.
+
+
+
+ + + + + + + + + + +
+ (0012199) +
+ Gyorgy Rethy    +
+ 01-07-2014 16:43    +
+ 		+ + + + +
+ See CR6697_v4.docx.
+
+I have no significant technical comment, mainly the name of any2uni?. There are mostly editorial changes. Please re-review.
+
+
+
+ + + + + + + + + + +
+ (0012200) +
+ Tomas Urban    +
+ 02-07-2014 07:47    +
+ 		+ + + + +
+ Fine by me. I have no objections against changing the name to any2unistr.
+
+
+
+ + + + + + + + + + +
+ (0012201) +
+ Jacob Wieland - Spirent    +
+ 03-07-2014 07:36    +
+ 		+ + + + +
+ apart from a typo: ora should be "or a", I see no problem other than the term
+
+"the searched matching mechanism", I would replace it with "the matching mechanism kind queried for" - there is no search going on and the parameter is called "kind" which should make the text more clear.
+
+
+
+ + + + + + + + + + +
+ (0012202) +
+ Gyorgy Rethy    +
+ 11-07-2014 13:48    +
+ 		+ + + + +
+ Changed acc. to Jacob's comment (minor change that "enquired" is used instead of "requested for" as a one-word synonym reads better)
+
+
+
+ + + + + + + + + + +
+ (0012204) +
+ Gyorgy Rethy    +
+ 28-07-2014 14:11    +
+ 		+ + + + +
+ Added to master copy of V4.6.2 (interim 2014)
+
+ + diff --git a/docs/mantis/CR6698.md b/docs/mantis/CR6698.md new file mode 100644 index 0000000000000000000000000000000000000000..6c4d1ccf7a33bf8e86209eba5d7e9b38e145633e --- /dev/null +++ b/docs/mantis/CR6698.md @@ -0,0 +1,617 @@ + + + + + + + + + + + + + 0006698: Missing functionality to cast "template" to "template (present)" - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006698Part 01: TTCN-3 Core LanguageNew Featurepublic06-03-2014 10:5819-06-2014 17:11
ReporterWolfgang Seka 
Assigned ToTomas Urban 
PriorityurgentSeverityminorReproducibilityhave not tried
StatusclosedResolutionwon't fix 
PlatformOSOS Version
Product Versionv4.6.1 (published 2014-06) 
Target Versionv4.6.2 (interim 2014)Fixed in Versionv4.6.2 (interim 2014) 
Clause Reference(s)ES 201 873-1 15.10
Source (company - Author) MCC160 - Wolfgang
Summary0006698: Missing functionality to cast "template" to "template (present)"
DescriptionWith valueof a template (especially with restriction "template (omit)" can be casted to a value (what serves "template (value)" as well).
+
+But there is no way make a "template (present)" out of a "template" in case it is know that the template is present.
+
Steps To Reproduce
Additional InformationThis issue is related to 6697
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
06-03-2014 10:58Wolfgang SekaNew Issue
08-04-2014 08:58Gyorgy RethyProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
08-04-2014 09:32Gyorgy RethyAssigned To => Tomas Urban
08-04-2014 09:32Gyorgy RethyStatusnew => assigned
08-04-2014 09:32Gyorgy RethyProduct Version => v4.6.1 (published 2014-06)
08-04-2014 09:32Gyorgy RethyTarget Version => v4.7.1 (published 2015-06)
08-04-2014 09:36Gyorgy RethyNote Added: 0011949
08-04-2014 13:37Tomas UrbanNote Added: 0011959
08-04-2014 15:35Wolfgang SekaNote Added: 0011962
08-04-2014 17:01Tomas UrbanNote Added: 0011964
09-04-2014 09:45Wolfgang SekaNote Added: 0011966
09-04-2014 11:35Jacob Wieland - SpirentNote Added: 0011970
09-04-2014 12:35Gyorgy RethyPrioritynormal => urgent
10-04-2014 09:41Gyorgy RethyNote Added: 0011984
10-04-2014 09:42Gyorgy RethyPriorityurgent => normal
17-06-2014 09:57Gyorgy RethyPrioritynormal => urgent
17-06-2014 10:55Gyorgy RethyNote Added: 0012099
17-06-2014 15:03Tomas UrbanNote Added: 0012108
17-06-2014 15:56Gyorgy RethyTarget Versionv4.7.1 (published 2015-06) => v4.6.2 (interim 2014)
17-06-2014 16:59Wolfgang SekaNote Added: 0012112
18-06-2014 07:58Tomas UrbanNote Added: 0012114
18-06-2014 08:21Wolfgang SekaNote Added: 0012116
18-06-2014 14:19Tomas UrbanNote Added: 0012128
18-06-2014 16:37Wolfgang SekaNote Added: 0012133
19-06-2014 15:25Gyorgy RethyNote Added: 0012151
19-06-2014 15:27Gyorgy RethyNote Edited: 0012151bug_revision_view_page.php?bugnote_id=12151#r45
19-06-2014 15:30Gyorgy RethyStatusassigned => closed
19-06-2014 15:30Gyorgy RethyResolutionopen => won't fix
19-06-2014 15:30Gyorgy RethyFixed in Version => v4.6.2 (interim 2014)
19-06-2014 15:32Gyorgy RethyNote Edited: 0012151bug_revision_view_page.php?bugnote_id=12151#r46
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011949) +
+ Gyorgy Rethy    +
+ 08-04-2014 09:36    +
+ 		+ + + + +
+ The purpose and the expected functionality to be clarified with Wolfgang.
+
+
+
+ + + + + + + + + + +
+ (0011959) +
+ Tomas Urban    +
+ 08-04-2014 13:37    +
+ 		+ + + + +
+ Assigning from an unrestricted template to a restricted one is allowed and should not cause any problem if all restriction requirements are met. No casting operation (similar to valueof) is necessary in this case. So e.g. the following code should work without a problem:
+
+type record R {
+  integer field1,
+  integer field2
+}
+...
+var template R vm_unrestricted := {
+  field1 := (0..10),
+  field2 := ?
+}
+var template(present) R vm_present := vm_unrestricted;
+
+Could you please provide a code example that causes problems? Or would you like to have an similar example as above or a note explaining this functionality in the core language specification?
+
+
+
+ + + + + + + + + + +
+ (0011962) +
+ Wolfgang Seka    +
+ 08-04-2014 15:35    +
+ 		+ + + + +
+ This would an improvement:
+
+when we have e.g.
+
+          template (present) SomeType cr_AnyTemplate := { ... };
+
+          function f_MyFunction(template SomeType p_AnyOrOmitTemplate)
+          {
+            var template (present) SomeType v_AnyTemplate;
+
+            if (ispresent(p_AnyOrOmitTemplate)) {
+              v_AnyTemplate := p_AnyOrOmitTemplate;
+            } else {
+              v_AnyTemplate := cr_AnyTemplate;
+            }
+            ...
+          }
+
+currently at least one compiler raises a warning because of the potential risk of a runtime error. In general I appreciate that kind of warning as sometimes it really helps to correct issues in the implementation.
+But in cases like above (and we have several of them) we always need to check that the code is correct as it is. Therefore - and for completeness - we would consider it as improvement when we can explicitly says "we know what we are doing - we have checked that the template is really there" so that we don't get warnings anymore (but we still get warnings in cases where it is unintended)
+
+
+
+ + + + + + + + + + +
+ (0011964) +
+ Tomas Urban    +
+ 08-04-2014 17:01    +
+ 		+ + + + +
+ The current position of the STF 478 is that it would not be very efficient if the TTCN-3 language standard provided a standardized (casting) solution for each situation where TTCN-3 tools might generate a warning. It would make the language even more complicated than it is right now. The valueof operand is an exception to this rule, because conversion from values to template is necessary as certain operations are not permitted for templates.
+
+However, it would be possible to introduce a generic solution for suppressing warnings, e.g. in the following statement. We were thinking of a special comment format, but it might have other form (that will be decided in further discussion). But before we go on with that, we would like to know your opinion. In your case the code would look like:
+
+          function f_MyFunction(template SomeType p_AnyOrOmitTemplate)
+          {
+            var template (present) SomeType v_AnyTemplate;
+
+            if (ispresent(p_AnyOrOmitTemplate)) {
+              //@nowarn
+              v_AnyTemplate := p_AnyOrOmitTemplate;
+            } else {
+              v_AnyTemplate := cr_AnyTemplate;
+            }
+            ...
+          }
+
+
+
+ + + + + + + + + + +
+ (0011966) +
+ Wolfgang Seka    +
+ 09-04-2014 09:45    +
+ 		+ + + + +
+ I have no strong opinion about whether or not it is efficient to cast less restricted templates to stronger restricted ones - even though it would enable tools give better information a compile time.
+
+That "@nowarn" pragma could be an option ...
+
+But - where to place it: intuitively I would expect it in that line for which no warning shall be issues. But that is different from your example.
+
+
+
+ + + + + + + + + + +
+ (0011970) +
+ Jacob Wieland - Spirent    +
+ 09-04-2014 11:35    +
+ 		+ + + + +
+ Testing Tech agrees that this would be a very useful feature. We actually were thinking about raising the same CR (something like presentof()).
+
+Of course, the nowarn annotations could also be a way to reduce the number of warnings.
+
+Still another way to go would be an explicit cast operator which could be useful in multiple occasions of such problems.
+
+
+
+ + + + + + + + + + +
+ (0011984) +
+ Gyorgy Rethy    +
+ 10-04-2014 09:41    +
+ 		+ + + + +
+ STF discussion: should not go into the interim version. The real value and implications of a cast operation to be clarified.
+
+
+
+ + + + + + + + + + +
+ (0012099) +
+ Gyorgy Rethy    +
+ 17-06-2014 10:55    +
+ 		+ + + + +
+ STF discussion:
+- warning control should be at the tool level; putting it into the language could spoil readability; warning control could be put into tool-specific extension attributes
+examples:
+function f() {v_AnyTemplate := v_AnyOrOmitTemplate} with { extension "nowarning" }
+function f() {
+v_AnyTemplate := v_AnyOrOmitTemplate;
+{v_AnyTemplate1 := v_AnyOrOmitTemplate1} with { extension "warning" }
+} with { extension "nowarning" }
+
+
+
+ + + + + + + + + + +
+ (0012108) +
+ Tomas Urban    +
+ 17-06-2014 15:03    +
+ 		+ + + + +
+ Wolfgang, the conclusion we have reached so far is that it is rather a tool issue than a TTCN-3 language problem and it should be discussed on the 3GPP meeting with tool vendors. As the TTCN-3 language standard doesn't require or recommend to generate a warning in the described case, it is not possible to define a mechanism that would suppress such a warning. In the previous György's comment, you can find a possible solution of TTCN-3 complient (but still tool-dependent) warning suppression mechanism.
+
+Could you please inform us if such a solution is suitable for you so that we can close the CR? Of course, if the proposal is not fine with you, please send us your objections.
+
+
+
+ + + + + + + + + + +
+ (0012112) +
+ Wolfgang Seka    +
+ 17-06-2014 16:59    +
+ 		+ + + + +
+ I'm happy with György's proposal but wonder how it can be specified to be common for all tools:
+I assume when a tool does not understand the extension it shall just ignore it;
+but when a tool supports suppression of warnings somehow it shall be standardised that "warning"/"nowarning" are at least one common way to control warnings from within TTCN-3.
+What we definitely don't want is that different tools require different extensions.
+
+
+
+ + + + + + + + + + +
+ (0012114) +
+ Tomas Urban    +
+ 18-06-2014 07:58    +
+ 		+ + + + +
+ Unknown extensions should be indeed ignored by the TTCN-3 tools. If you wish to have a standardized solution for your project, I think the easiest way is to describe all necessary extensions in your project requirements and discuss support questions with representatives of tool vendors.
+
+
+
+ + + + + + + + + + +
+ (0012116) +
+ Wolfgang Seka    +
+ 18-06-2014 08:21    +
+ 		+ + + + +
+ "... describe all necessary extensions in your project requirements and discuss support questions with representatives of tool vendors"
+
+That is exactly what I'm not happy with: We don't want to have a project or tool vendor specific solution for this case.
+
+Please note that I'm still not convinced that this is not a language issue; nevertheless I could live with a solution on tool level when it is standardised.
+
+
+
+ + + + + + + + + + +
+ (0012128) +
+ Tomas Urban    +
+ 18-06-2014 14:19    +
+ 		+ + + + +
+ I see. We can specify a standardized solution for you, but I am not sure if we can publish it as a part of TTCN-3 standards. Would an unpublished, i.e. not binding specification be enough for you or would you prefer an extension package?
+
+
+
+ + + + + + + + + + +
+ (0012133) +
+ Wolfgang Seka    +
+ 18-06-2014 16:37    +
+ 		+ + + + +
+ After some internal discussion with Olivier we have the common opinion that there shall be some official specification, e.g. for standard extensions.
+These standard extensions can be put to some annex. Personally I think that it is sufficient to keep that informative but it would make clear for all tools and projects that when a tool supports suppression of warnings how this has to be expressed in TTCN.
+
+
+
+ + + + + + + + + + +
+ (0012151) +
+ Gyorgy Rethy    +
+ 19-06-2014 15:25    +
(edited on: 19-06-2014 15:32)
+ 		+ + + + +
+ STF decision: STF cannot decide to produce a new part of TTCN-3 (extension package) on its own, TC MTS shall approve a NWI for this. In the STF's oppinion it should be an EG or TR document, rather than an extension package.
+We can report the outcome of this CR to TC MTS, but we cannot propose the NWI.
+
+
+
+ + diff --git a/docs/mantis/CR6699.md b/docs/mantis/CR6699.md new file mode 100644 index 0000000000000000000000000000000000000000..948b4a2ea62804d803eaccab2e6000aac82097a1 --- /dev/null +++ b/docs/mantis/CR6699.md @@ -0,0 +1,254 @@ + + + + + + + + + + + + + 0006699: Missing/invalid expansion rules for templates with template restrictions in 15.6.2 - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006699Part 01: TTCN-3 Core LanguageClarificationpublic06-03-2014 12:1928-07-2014 14:20
ReporterWolfgang Seka 
Assigned ToGyorgy Rethy 
PriorityurgentSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.6.1 (published 2014-06) 
Target Versionv4.6.2 (interim 2014)Fixed in Versionv4.6.2 (interim 2014) 
Clause Reference(s)ES 201 873-1 clause 15.6.2
Source (company - Author)MCC160 - Wolfgang
Summary0006699: Missing/invalid expansion rules for templates with template restrictions in 15.6.2
DescriptionClause 15.6.2 describes how to expand a template variable which is initialised with omit when a single field of the variable gets assigned:
+The other fields shall be expanded to "?" if the are mandatory and to "*" else.
+
+This is applicable for pure template variables (i.e. without template restrictions) but - at least from a user's point of view - it does not make sense for a "template (omit)" variable as the implicit expansion leads to violation of the template restriction what causes a runtime error with at least one tool. This is not acceptable from a user's point of view especially in a following scenario:
+
+type record MyRecord_Type {
+  integer field1,
+  integer field2
+};
+
+var template (omit) MyRecord_Type v_MyRecord := omit;
+
+v_MyRecord.field1 := 1; // assignment 1
+v_MyRecord.field2 := 2; // assignment 2
+
+-> It does not make any use to get a run-time error between assignment 1 and 2.
+
+=> Clause 15.6.2 shall be enhanced to cope with "template (omit)" variables so that internal expansion rules of the core language do not violate the core language itself.
+The simplest solution would be to consider fields not being assigned yet as "uninitialized" in terms of isbound (or optional fields could be expanded to omit as well).
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR6699_v1.docx (14,648) 09-04-2014 15:12
http://oldforge.etsi.org/mantis/file_download.php?file_id=2982&type=bug
Issue History
Date ModifiedUsernameFieldChange
06-03-2014 12:19Wolfgang SekaNew Issue
08-04-2014 08:59Gyorgy RethyProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
08-04-2014 10:01Gyorgy RethyNote Added: 0011950
08-04-2014 10:01Gyorgy RethyAssigned To => Tomas Urban
08-04-2014 10:01Gyorgy RethyStatusnew => assigned
08-04-2014 17:02Gyorgy RethyProduct Version => v4.6.1 (published 2014-06)
08-04-2014 17:02Gyorgy RethyTarget Version => v4.7.1 (published 2015-06)
09-04-2014 11:20Jacob Wieland - SpirentNote Added: 0011968
09-04-2014 12:36Gyorgy RethyPrioritynormal => urgent
09-04-2014 15:12Tomas UrbanFile Added: CR6699_v1.docx
09-04-2014 15:13Tomas UrbanNote Added: 0011974
10-04-2014 12:52Tomas UrbanNote Added: 0011998
10-04-2014 12:52Tomas UrbanAssigned ToTomas Urban => Jens Grabowski
10-04-2014 12:52Tomas UrbanStatusassigned => confirmed
16-06-2014 09:30Jens GrabowskiNote Added: 0012075
16-06-2014 09:30Jens GrabowskiAssigned ToJens Grabowski => Gyorgy Rethy
16-06-2014 09:30Jens GrabowskiStatusconfirmed => assigned
16-06-2014 09:31Jens GrabowskiStatusassigned => resolved
16-06-2014 09:31Jens GrabowskiResolutionopen => fixed
17-06-2014 15:57Gyorgy RethyFixed in Version => v4.6.2 (interim 2014)
17-06-2014 15:57Gyorgy RethyTarget Versionv4.7.1 (published 2015-06) => v4.6.2 (interim 2014)
20-06-2014 11:55Gyorgy RethyFixed in Versionv4.6.2 (interim 2014) =>
28-07-2014 14:20Gyorgy RethyNote Added: 0012205
28-07-2014 14:20Gyorgy RethyStatusresolved => closed
28-07-2014 14:20Gyorgy RethyFixed in Version => v4.6.2 (interim 2014)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011950) +
+ Gyorgy Rethy    +
+ 08-04-2014 10:01    +
+ 		+ + + + +
+ Check if limiting template restriction to template and template(present) would cause problem with the users of other tools.
+
+
+
+ + + + + + + + + + +
+ (0011968) +
+ Jacob Wieland - Spirent    +
+ 09-04-2014 11:20    +
+ 		+ + + + +
+ I would agree that for template(value) and template(omit) the expansion behavior should be the same as for values.
+
+As far as I know, the implicit-omit-template-expansion feature is not used by our customers, yet.
+
+
+
+ + + + + + + + + + +
+ (0011974) +
+ Tomas Urban    +
+ 09-04-2014 15:13    +
+ 		+ + + + +
+ Resolution uploaded. Waiting for vendor feedback.
+
+
+
+ + + + + + + + + + +
+ (0011998) +
+ Tomas Urban    +
+ 10-04-2014 12:52    +
+ 		+ + + + +
+ As it doesn't seem there are any objections from the vendors, I think we can proceed with resolving the issue.
+Please check the proposed solution.
+
+
+
+ + + + + + + + + + +
+ (0012075) +
+ Jens Grabowski    +
+ 16-06-2014 09:30    +
+ 		+ + + + +
+ Ok, from my side.
+
+
+
+ + + + + + + + + + +
+ (0012205) +
+ Gyorgy Rethy    +
+ 28-07-2014 14:20    +
+ 		+ + + + +
+ Added to master copy of V4.6.2 (interim 2014)
+
+ + diff --git a/docs/mantis/CR6700.md b/docs/mantis/CR6700.md new file mode 100644 index 0000000000000000000000000000000000000000..52b3aeddc6af0ca551be28ca9b3d8f3d22db046b --- /dev/null +++ b/docs/mantis/CR6700.md @@ -0,0 +1,178 @@ + + + + + + + + + + + + + 0006700: Clarification for clause 15.6.3 - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006700Part 01: TTCN-3 Core LanguageClarificationpublic07-03-2014 09:4601-08-2014 14:56
ReporterWolfgang Seka 
Assigned ToGyorgy Rethy 
PriorityurgentSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.6.1 (published 2014-06) 
Target Versionv4.6.2 (interim 2014)Fixed in Versionv4.6.2 (interim 2014) 
Clause Reference(s)ES 201 873-1 clause 15.6.3
Source (company - Author) MCC160 - Wolfgang
Summary0006700: Clarification for clause 15.6.3
DescriptionAt least one tool interprets ES 201 873-1 clause 15.6.3 in that way that e.g.
+
+  type record of integer RoI;
+  var template (omit) RoI t_RoI := omit;
+  t_RoI[0] := 42;
+
+causes a runtime error.
+The proposed workaround is
+
+  t_RoI := { 42 };
+
+
+From a user's point of view this is a useless restriction as there is no benefit (the run-time error is just raised because of a weird restriction which can be by-passed by another - in general equivalent - notation => from a user's point of view there is no technical justification and therefore the restriction is not acceptable)
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0006714closed Gyorgy Rethy Expansion of LHS in case of uninitialized constructive variables 
Attached Filesdocx CR6670_v1.docx (23,329) 09-04-2014 09:15
http://oldforge.etsi.org/mantis/file_download.php?file_id=2978&type=bug
Issue History
Date ModifiedUsernameFieldChange
07-03-2014 09:46Wolfgang SekaNew Issue
08-04-2014 08:59Gyorgy RethyProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
08-04-2014 10:17Gyorgy RethyAssigned To => Tomas Urban
08-04-2014 10:17Gyorgy RethyStatusnew => assigned
08-04-2014 10:17Gyorgy RethyProduct Version => v4.6.1 (published 2014-06)
08-04-2014 10:17Gyorgy RethyTarget Version => v4.7.1 (published 2015-06)
08-04-2014 10:18Gyorgy RethyNote Added: 0011952
09-04-2014 09:15Tomas UrbanFile Added: CR6670_v1.docx
09-04-2014 09:18Tomas UrbanRelationship addedrelated to 0006714
09-04-2014 09:19Tomas UrbanNote Added: 0011965
09-04-2014 09:19Tomas UrbanAssigned ToTomas Urban => Jens Grabowski
09-04-2014 12:37Gyorgy RethyPrioritynormal => urgent
10-04-2014 11:09Tomas UrbanStatusassigned => confirmed
10-04-2014 11:50Jens GrabowskiNote Added: 0011995
10-04-2014 11:50Jens GrabowskiAssigned ToJens Grabowski => Tomas Urban
10-04-2014 11:50Jens GrabowskiStatusconfirmed => assigned
10-04-2014 11:50Jens GrabowskiStatusassigned => confirmed
16-06-2014 09:51Tomas UrbanStatusconfirmed => resolved
16-06-2014 09:51Tomas UrbanFixed in Version => v4.7.1 (published 2015-06)
16-06-2014 09:51Tomas UrbanResolutionopen => fixed
16-06-2014 09:51Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
17-06-2014 15:57Gyorgy RethyFixed in Versionv4.7.1 (published 2015-06) => v4.6.2 (interim 2014)
17-06-2014 15:57Gyorgy RethyTarget Versionv4.7.1 (published 2015-06) => v4.6.2 (interim 2014)
20-06-2014 11:55Gyorgy RethyFixed in Versionv4.6.2 (interim 2014) =>
01-08-2014 14:56Gyorgy RethyNote Added: 0012211
01-08-2014 14:56Gyorgy RethyStatusresolved => closed
01-08-2014 14:56Gyorgy RethyFixed in Version => v4.6.2 (interim 2014)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011952) +
+ Gyorgy Rethy    +
+ 08-04-2014 10:18    +
+ 		+ + + + +
+ STF478: create a proposal for omit expansion on LHS.
+
+
+
+ + + + + + + + + + +
+ (0011965) +
+ Tomas Urban    +
+ 09-04-2014 09:19    +
+ 		+ + + + +
+ Proposal created. It contains new rules for AnyValueOrNone (LHS) and omit. Detailed rules concerning omit handling in dot and index notation will be resolved in CR6714.
+Please check.
+
+
+
+ + + + + + + + + + +
+ (0011995) +
+ Jens Grabowski    +
+ 10-04-2014 11:50    +
+ 		+ + + + +
+ Can be set to resolved and assigned to György after the resolution of 6714.
+
+
+
+ + + + + + + + + + +
+ (0012211) +
+ Gyorgy Rethy    +
+ 01-08-2014 14:56    +
+ 		+ + + + +
+ Added to master copy of V4.6.2 (interim 2014)
+
+ + diff --git a/docs/mantis/CR6701.md b/docs/mantis/CR6701.md new file mode 100644 index 0000000000000000000000000000000000000000..d82b88254ebbb82abc232a3d754a6b3af9462703 --- /dev/null +++ b/docs/mantis/CR6701.md @@ -0,0 +1,107 @@ + + + + + + + + + + + + + 0006701: Example XML is invalid - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006701Part 09: Using XML with TTCN-3Editorialpublic07-03-2014 12:5326-01-2015 11:26
ReporterNikolay Pakulin 
Assigned ToGyorgy Rethy 
PrioritylowSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.5.1 (published 2013-04) 
Target Versionv4.6.1 (published 2015-06)Fixed in Versionv4.5.2 (interim 2014) 
Clause Reference(s)7.6.1.1, 7.6.1.2
For STF discussion
Source (company - Author)STF 475
Summary0006701: Example XML is invalid
DescriptionSections 7.6.1.1 and 7.6.2.2 contain the following sample XML:
+
+<?xml version="1.0" encoding="UTF-8"?>
+<e23 bar=1 foo=2.0>something</e23>
+
+This XML is invalid: according to XML grammar http://www.w3.org/TR/REC-xml/#sec-common-syn [^] (syntactic rule 0000010) attribute value must be enclosed in either single or double quotes.
+
+Syntactically valid XML should like
+<?xml version="1.0" encoding="UTF-8"?>
+<e23 bar="1" foo="2.0">something</e23>
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
07-03-2014 12:53Nikolay PakulinNew Issue
08-04-2014 10:19Gyorgy RethyAssigned To => Gyorgy Rethy
08-04-2014 10:19Gyorgy RethyStatusnew => assigned
08-04-2014 17:06Gyorgy RethyTarget Version => v4.6.1 (published 2015-06)
16-06-2014 15:49Gyorgy RethyNote Added: 0012090
16-06-2014 15:49Gyorgy RethyStatusassigned => resolved
16-06-2014 15:49Gyorgy RethyFixed in Version => v4.6.1 (published 2015-06)
16-06-2014 15:49Gyorgy RethyResolutionopen => fixed
20-06-2014 11:54Gyorgy RethyFixed in Versionv4.6.1 (published 2015-06) =>
23-06-2014 11:27Gyorgy RethyNote Added: 0012192
23-06-2014 11:27Gyorgy RethyStatusresolved => closed
23-06-2014 11:27Gyorgy RethyFixed in Version => v4.6.1 (published 2015-06)
24-06-2014 08:58Gyorgy RethyFixed in Versionv4.6.1 (published 2015-06) => v4.5.2 (interim 2014)
26-01-2015 11:19Gyorgy RethyFixed in Versionv4.5.2 (interim 2014) => v4.6.1 (published 2015-06)
26-01-2015 11:26Gyorgy RethyFixed in Versionv4.6.1 (published 2015-06) => v4.5.2 (interim 2014)
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0012090) +
+ Gyorgy Rethy    +
+ 16-06-2014 15:49    +
+ 		+ + + + +
+ Corrected in master copy version v.4.5.2
+
+
+
+ + + + + + + + + + +
+ (0012192) +
+ Gyorgy Rethy    +
+ 23-06-2014 11:27    +
+ 		+ + + + +
+ Implemented in master copy V4.5.2
+
+ + diff --git a/docs/mantis/CR6702.md b/docs/mantis/CR6702.md new file mode 100644 index 0000000000000000000000000000000000000000..ab64c17c1d8a821c7d02c2f5ed1d0a03239f0af3 --- /dev/null +++ b/docs/mantis/CR6702.md @@ -0,0 +1,224 @@ + + + + + + + + + + + + + 0006702: Assignment of partially initialized values of structured types - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006702Part 01: TTCN-3 Core LanguageTechnicalpublic11-03-2014 12:1906-01-2015 17:07
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.5.1 (published 2013-04) 
Target Versionv4.7.1 (published 2015-06)Fixed in Versionv4.7.1 (published 2015-06) 
Clause Reference(s)19.1
Source (company - Author)Elvior
Summary0006702: Assignment of partially initialized values of structured types
DescriptionDuring porting code from a different TTCN-3 tool to our tool, we encountered an interesting problem. The problem is related to the following code:
+
+type record MyRecord
+{
+  charstring field1,
+  charstring field2,
+  charstring field3
+}
+...
+var MyRecord v_MyList1;
+var MyRecord v_MyList2;
+v_MyList1 := {value1”, “value2”, “value3” };
+v_MyList2.field2 := “newvalue”; // leaving field1 and field3 uninitialized
+
+v_MyList1 := v_MyList2;
+
+In our tool, the value of v_MyList1 after the last assignment is {<uninitialized>, “newvalue”, <uninitialized>}, while in the other tool it is {“value1”, “newvalue”, “value3” }.
+
+Our position is that only general assignment rules apply to the last assignment, thus the whole record value is assigned to the v_MyList1 variable completely ovewriting its previous content.
+
+The specification does contain rules that allow the original values to be kept after an assignment, but these rules are related to specific value notations occuring on the RHS: assignment notation and list notation (specified in 6.2).
+
+In order to prevent this kind of different interpretations, we would welcome if the next edition of the TTCN-3 standard contained either a note or an explicit rule mentioning that the whole value is assigned in this case including uninitialized fields (i.e. all fields of the original value get overwritten).
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR6702_v1-140616-JG.docx (19,702) 18-06-2014 10:43
http://oldforge.etsi.org/mantis/file_download.php?file_id=3045&type=bug
docx CR6702_v2-140618-TU.docx (24,597) 18-06-2014 14:10
http://oldforge.etsi.org/mantis/file_download.php?file_id=3054&type=bug
Issue History
Date ModifiedUsernameFieldChange
11-03-2014 12:19Tomas UrbanNew Issue
07-04-2014 14:00Jens GrabowskiNote Added: 0011938
07-04-2014 14:00Jens GrabowskiAssigned To => Jens Grabowski
07-04-2014 14:00Jens GrabowskiStatusnew => assigned
08-04-2014 17:04Gyorgy RethyTarget Version => v4.7.1 (published 2015-06)
17-06-2014 13:43Gyorgy RethyNote Added: 0012105
18-06-2014 10:43Jens GrabowskiFile Added: CR6702_v1-140616-JG.docx
18-06-2014 10:44Jens GrabowskiNote Added: 0012120
18-06-2014 10:44Jens GrabowskiAssigned ToJens Grabowski => Tomas Urban
18-06-2014 10:44Jens GrabowskiStatusassigned => confirmed
18-06-2014 14:10Tomas UrbanFile Added: CR6702_v2-140618-TU.docx
18-06-2014 14:12Tomas UrbanNote Added: 0012127
18-06-2014 14:12Tomas UrbanStatusconfirmed => resolved
18-06-2014 14:12Tomas UrbanResolutionopen => fixed
18-06-2014 14:12Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
06-01-2015 17:07Gyorgy RethyNote Added: 0012645
06-01-2015 17:07Gyorgy RethyStatusresolved => closed
06-01-2015 17:07Gyorgy RethyFixed in Version => v4.7.1 (published 2015-06)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011938) +
+ Jens Grabowski    +
+ 07-04-2014 14:00    +
+ 		+ + + + +
+ Assignment of an uninitialized value results in an uninitialized value. Add example.
+
+
+
+ + + + + + + + + + +
+ (0012105) +
+ Gyorgy Rethy    +
+ 17-06-2014 13:43    +
+ 		+ + + + +
+ STF discussion:
+A structured value on the RHS shall be assigned completely to LHS, I.e., if a partially initialized var is assigned to a completely initialized one, fields uninitialized at the RHS shall also become uninitialized at the LHS.
+
+
+
+ + + + + + + + + + +
+ (0012120) +
+ Jens Grabowski    +
+ 18-06-2014 10:44    +
+ 		+ + + + +
+ Resolution proposal attached, assigned to Tomas for proofreading.
+
+
+
+ + + + + + + + + + +
+ (0012127) +
+ Tomas Urban    +
+ 18-06-2014 14:12    +
+ 		+ + + + +
+ I made one cosmetic change in the example, replacing typographical quotation marks with correct symbol in the examples.
+
+Otherwise the proposal solves the described issue and it is ready to be included in the next version of the TTCN-3 standard.
+
+
+
+ + + + + + + + + + +
+ (0012645) +
+ Gyorgy Rethy    +
+ 06-01-2015 17:07    +
+ 		+ + + + +
+ Added to draft V4.6.3
+
+ + diff --git a/docs/mantis/CR6703.md b/docs/mantis/CR6703.md new file mode 100644 index 0000000000000000000000000000000000000000..34471ad6317dcea69abdab41ae719a5d55700082 --- /dev/null +++ b/docs/mantis/CR6703.md @@ -0,0 +1,103 @@ + + + + + + + + + + + + + 0006703: Inconsisten assignment restriction - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006703Part 01: TTCN-3 Core LanguageTechnicalpublic11-03-2014 12:2920-06-2014 11:49
ReporterTomas Urban 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionwon't fix 
PlatformOSOS Version
Product Versionv4.5.1 (published 2013-04) 
Target Versionv4.7.1 (published 2015-06)Fixed in Version 
Clause Reference(s)19.1
Source (company - Author)Elvior
Summary0006703: Inconsisten assignment restriction
DescriptionThe resolution of CR 6562 allowed to use standalone template references in expressions. However, there has been no change in the restriction 19.1.b:
+
+When the right hand side of the assignment evaluates to a template (global or local template, in-line template or template variable), the variable at the left hand side shall be a template variable.)
+
+This restriction is now inconsistent with the newly introduced rules. Therefore I propose to change the restriction to the following:
+
+When the RHS evaluates to a matching symbol, the variable at the left hand side shall be a template variable.)
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
11-03-2014 12:29Tomas UrbanNew Issue
17-03-2014 15:10Tomas UrbanNote Added: 0011926
07-04-2014 11:32Jens GrabowskiAssigned To => Jens Grabowski
07-04-2014 11:32Jens GrabowskiStatusnew => assigned
07-04-2014 11:33Jens GrabowskiNote Added: 0011934
07-04-2014 11:33Jens GrabowskiStatusassigned => closed
07-04-2014 11:33Jens GrabowskiResolutionopen => won't fix
20-06-2014 11:49Gyorgy RethyTarget Version => v4.7.1 (published 2015-06)
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011926) +
+ Tomas Urban    +
+ 17-03-2014 15:10    +
+ 		+ + + + +
+ I am sorry for entering this CR. It is not justified and should be closed without changing anything in the language specification.
+
+
+
+ + + + + + + + + + +
+ (0011934) +
+ Jens Grabowski    +
+ 07-04-2014 11:33    +
+ 		+ + + + +
+ Closed due to request of reporter.
+
+ + diff --git a/docs/mantis/CR6704.md b/docs/mantis/CR6704.md new file mode 100644 index 0000000000000000000000000000000000000000..75e14b474c71ced8cec97365aa94ded9fb4b2e32 --- /dev/null +++ b/docs/mantis/CR6704.md @@ -0,0 +1,494 @@ + + + + + + + + + + + + + 0006704: Number of matches of subset items - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006704Part 01: TTCN-3 Core LanguageTechnicalpublic27-03-2014 07:5005-01-2015 16:16
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritylowSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.5.1 (published 2013-04) 
Target Versionv4.7.1 (published 2015-06)Fixed in Versionv4.7.1 (published 2015-06) 
Clause Reference(s)B.1.2.7
Source (company - Author)Elvior
Summary0006704: Number of matches of subset items
DescriptionThe current specification says that a set of value can be matched by subset if it contains only elements present in the subset. It doesn't contain any restriction on the number of occurences of the elements in the set of value, in particular it doesn't say that these elements can be present only once. However, there are notes in the comments of examples pointing exactly in that direction (i.e. that subset elements can appear zero times or once in the value being matched).
+
+Example:
+Using subset(1, 2, 3) to match the value { 2, 2 }.
+
+If the intention is to limit maximum allowed matches of individual items defined the subset to one, there should be a formal rule for it. Please notice that introducing such a rule would produce backward incompatibility, because e.g. our tool allows multiple matches. There's of course a possibility that the comments are wrong and if it is the case, they should be corrected.
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR6704_v1.docx (52,040) 07-10-2014 08:51
http://oldforge.etsi.org/mantis/file_download.php?file_id=3086&type=bug
docx CR6704_v2.docx (54,559) 09-10-2014 09:01
http://oldforge.etsi.org/mantis/file_download.php?file_id=3123&type=bug
docx CR6704_v3.docx (54,022) 09-10-2014 11:52
http://oldforge.etsi.org/mantis/file_download.php?file_id=3126&type=bug
docx CR6704_v4.docx (54,624) 09-10-2014 15:50
http://oldforge.etsi.org/mantis/file_download.php?file_id=3132&type=bug
Issue History
Date ModifiedUsernameFieldChange
27-03-2014 07:50Tomas UrbanNew Issue
07-04-2014 13:35Gyorgy RethyNote Added: 0011936
07-04-2014 13:35Gyorgy RethyAssigned To => Gyorgy Rethy
07-04-2014 13:35Gyorgy RethyStatusnew => assigned
08-04-2014 17:05Gyorgy RethyTarget Version => v4.7.1 (published 2015-06)
30-04-2014 08:55Jacob Wieland - SpirentNote Added: 0012056
06-10-2014 15:41Gyorgy RethyAssigned ToGyorgy Rethy => Tomas Urban
06-10-2014 15:41Gyorgy RethyPrioritynormal => low
07-10-2014 08:51Tomas UrbanFile Added: CR6704_v1.docx
07-10-2014 08:56Tomas UrbanNote Added: 0012242
07-10-2014 08:56Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
07-10-2014 08:56Tomas UrbanStatusassigned => confirmed
07-10-2014 10:25Jacob Wieland - SpirentNote Added: 0012249
08-10-2014 08:23Gyorgy RethyAssigned ToGyorgy Rethy => Axel Rennoch
09-10-2014 09:01Axel RennochFile Added: CR6704_v2.docx
09-10-2014 09:06Axel RennochNote Added: 0012308
09-10-2014 09:06Axel RennochAssigned ToAxel Rennoch => Tomas Urban
09-10-2014 09:06Axel RennochStatusconfirmed => assigned
09-10-2014 09:07Axel RennochNote Added: 0012309
09-10-2014 09:07Axel RennochStatusassigned => confirmed
09-10-2014 11:26Tomas UrbanNote Added: 0012313
09-10-2014 11:52Tomas UrbanFile Added: CR6704_v3.docx
09-10-2014 11:54Tomas UrbanNote Added: 0012314
09-10-2014 11:54Tomas UrbanAssigned ToTomas Urban => Axel Rennoch
09-10-2014 12:33Jacob Wieland - SpirentNote Added: 0012320
09-10-2014 15:50Axel RennochFile Added: CR6704_v4.docx
09-10-2014 15:51Axel RennochNote Added: 0012329
09-10-2014 15:51Axel RennochAssigned ToAxel Rennoch => Tomas Urban
09-10-2014 15:51Axel RennochStatusconfirmed => assigned
09-10-2014 15:52Axel RennochNote Added: 0012330
09-10-2014 15:52Axel RennochStatusassigned => confirmed
09-10-2014 16:00Tomas UrbanNote Added: 0012331
09-10-2014 16:00Tomas UrbanStatusconfirmed => resolved
09-10-2014 16:00Tomas UrbanResolutionopen => fixed
09-10-2014 16:00Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
05-01-2015 16:16Gyorgy RethyNote Added: 0012620
05-01-2015 16:16Gyorgy RethyStatusresolved => closed
05-01-2015 16:16Gyorgy RethyFixed in Version => v4.7.1 (published 2015-06)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011936) +
+ Gyorgy Rethy    +
+ 07-04-2014 13:35    +
+ 		+ + + + +
+ STF478, 2014-04-07: Check the text, no more than one matching is allowed. Check text and propose correction.
+
+
+
+ + + + + + + + + + +
+ (0012056) +
+ Jacob Wieland - Spirent    +
+ 30-04-2014 08:55    +
+ 		+ + + + +
+ since the 'set of' in TTCN-3 is a mathematical 'bag' (i.e. multi-set where each element can occur multiple times), the subset and superset constructions should also adhere to this semantics. Otherwise, the language would become inconsistent and it would be impossible to match for a minimum/maximum number of occurrences of the same element or different elements matching the same template.
+
+
+
+ + + + + + + + + + +
+ (0012242) +
+ Tomas Urban    +
+ 07-10-2014 08:56    +
+ 		+ + + + +
+ Proposal uploaded. It contains a rule for the SuperSet matching mechanism too in order to keep uniform style and remove any possibility of different interpretations. I didn't provide any examples, but I think the notes explain the added rules sufficiently.
+Please check.
+
+
+
+ + + + + + + + + + +
+ (0012249) +
+ Jacob Wieland - Spirent    +
+ 07-10-2014 10:25    +
+ 		+ + + + +
+ The wording, unfortunately, is still ambiguous.
+
+As it is written in the proposal, it would enforce that for each subset/superset-element that is matching an element of the set-of value, it is not allowed to match another one. This, of course, is not the intention.
+
+Maybe it should be described in a more mathematical fashion, i.e.
+
+For superset:
+
+- there exists an one-to-one mapping from the superset-elements to the elements of the set-of-value so that the superset-element matches the set-of-element it is mapped to.
+
+For subset:
+
+- there exists a one-to-one mapping from the elements of the set-of-value to the superset-elements so that the set-of element is matched by the superset-element it is mapped to.
+
+Of course, in both cases, there can be more than one of these mappings, i.e. the match can be ambiguous.
+
+
+
+ + + + + + + + + + +
+ (0012308) +
+ Axel Rennoch    +
+ 09-10-2014 09:06    +
+ 		+ + + + +
+ The situation appears to be solved by the additional text in the uploaded proposal. However the notes may be substituted by the "mathematical" explanations proposed by Jacob. I also do not see a need for additional examples.
+
+
+
+ + + + + + + + + + +
+ (0012309) +
+ Axel Rennoch    +
+ 09-10-2014 09:07    +
+ 		+ + + + +
+ Second upload exchanges only the notes.
+
+
+
+ + + + + + + + + + +
+ (0012313) +
+ Tomas Urban    +
+ 09-10-2014 11:26    +
+ 		+ + + + +
+ I think that Jacob's arguments are valid. The current wording is indeed too restrictive. E.g. having a superset (?, 2) and set of { 1, 2 }, the second element of the set is matched by both superset items. It means that the successful matches are not distinct as required by the proposed rule. I will update the proposal.
+
+
+
+ + + + + + + + + + +
+ (0012314) +
+ Tomas Urban    +
+ 09-10-2014 11:54    +
+ 		+ + + + +
+ Updated according to Jacob's proposal. Please check.
+
+
+
+ + + + + + + + + + +
+ (0012320) +
+ Jacob Wieland - Spirent    +
+ 09-10-2014 12:33    +
+ 		+ + + + +
+ Except for the 'between's which should be 'from's this is fine.
+
+A one-to-one-mapping *between* two sets - in my opinion - is a bijective mapping (i.e. also surjectivel, i.e. A and B have the same size), while a one-to-one mapping *from* set A to set B needs only to be injectve (i.e. B can have more elements than A)
+
+
+
+ + + + + + + + + + +
+ (0012329) +
+ Axel Rennoch    +
+ 09-10-2014 15:51    +
+ 		+ + + + +
+ wording change to reflect mapping as non-bijective
+
+
+
+ + + + + + + + + + +
+ (0012330) +
+ Axel Rennoch    +
+ 09-10-2014 15:52    +
+ 		+ + + + +
+ final wording to be confirmed
+
+
+
+ + + + + + + + + + +
+ (0012331) +
+ Tomas Urban    +
+ 09-10-2014 16:00    +
+ 		+ + + + +
+ I have no objections. The proposed resolution is ready to be added to the next version of the TTCN-3 core language standard.
+
+
+
+ + + + + + + + + + +
+ (0012620) +
+ Gyorgy Rethy    +
+ 05-01-2015 16:16    +
+ 		+ + + + +
+ Added to draft V4.6.3
+
+ + diff --git a/docs/mantis/CR6705.md b/docs/mantis/CR6705.md new file mode 100644 index 0000000000000000000000000000000000000000..2334ac05f429459cda63677145f37bc27041941f --- /dev/null +++ b/docs/mantis/CR6705.md @@ -0,0 +1,172 @@ + + + + + + + + + + + + + 0006705: Invalid restriction on subset length - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006705Part 01: TTCN-3 Core LanguageEditorialpublic27-03-2014 08:0019-06-2014 17:33
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.6.1 (published 2014-06) 
Target Versionv4.7.1 (published 2015-06)Fixed in Versionv4.6.2 (interim 2014) 
Clause Reference(s)B.1.2.7
Source (company - Author)Elvior
Summary0006705: Invalid restriction on subset length
DescriptionThis problem is related to TTCN-3:2014 (final draft, 4.5.3). It seems that during when moving the restriction on length attribute from the textual part to the restriction section (restriction f), the text for superset was accidentally copied. The correct text would be:
+
+If the length matching attribute is attached to the SubSet, the maximum length allowed by the length attribute shall not exceed the number of the elements in the SubSet.
+
+The restriction is also related to the CR6704. If this CR is resolved in favour of unlimited occurences of subset elements, the restriction should be removed as it doesn't make sense.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
27-03-2014 08:00Tomas UrbanNew Issue
08-04-2014 10:20Gyorgy RethyAssigned To => Gyorgy Rethy
08-04-2014 10:20Gyorgy RethyStatusnew => assigned
08-04-2014 14:50Gyorgy RethyNote Added: 0011960
08-04-2014 14:55Tomas UrbanNote Added: 0011961
08-04-2014 14:55Tomas UrbanAssigned ToGyorgy Rethy =>
08-04-2014 14:55Tomas UrbanStatusassigned => closed
08-04-2014 14:55Tomas UrbanFixed in Version => v4.7.1 (published 2015-06)
08-04-2014 14:55Tomas UrbanTarget Version => v4.7.1 (published 2015-06)
08-04-2014 15:34Gyorgy RethyProduct Versionv4.5.1 (published 2013-04) => v4.6.1 (published 2014-06)
08-04-2014 15:36Gyorgy RethyNote Added: 0011963
08-04-2014 15:36Gyorgy RethyAssigned To => Gyorgy Rethy
08-04-2014 15:36Gyorgy RethyStatusclosed => resolved
08-04-2014 15:36Gyorgy RethyResolutionopen => fixed
19-06-2014 17:32Gyorgy RethyNote Added: 0012165
19-06-2014 17:32Gyorgy RethyStatusresolved => closed
19-06-2014 17:33Gyorgy RethyFixed in Versionv4.7.1 (published 2015-06) => v4.6.2 (interim 2014)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011960) +
+ Gyorgy Rethy    +
+ 08-04-2014 14:50    +
+ 		+ + + + +
+ Resolution: Clause B.1.2.7 SubSet, Restriction f) shall be changed to
+
+"f) If the length matching attribute is attached to the SubSet, the maximal length allowed by the length attribute shall not be more than the number of the elements in the SubSet."
+
+
+
+ + + + + + + + + + +
+ (0011961) +
+ Tomas Urban    +
+ 08-04-2014 14:55    +
+ 		+ + + + +
+ Proposed resolution checked. No objections.
+Closing the CR.
+
+
+
+ + + + + + + + + + +
+ (0011963) +
+ Gyorgy Rethy    +
+ 08-04-2014 15:36    +
+ 		+ + + + +
+ Status changed to resolved to secure the solution is implemented either on 4.6.1, or 4.7.1 if misses 4.6.1
+
+
+
+ + + + + + + + + + +
+ (0012165) +
+ Gyorgy Rethy    +
+ 19-06-2014 17:32    +
+ 		+ + + + +
+ Fixed in master copy
+
+ + diff --git a/docs/mantis/CR6706.md b/docs/mantis/CR6706.md new file mode 100644 index 0000000000000000000000000000000000000000..ca0d191a44b41179d54c91b55496a99f0ca241d4 --- /dev/null +++ b/docs/mantis/CR6706.md @@ -0,0 +1,397 @@ + + + + + + + + + + + + + 0006706: Encoding in oct2unichar, unichar2oct, encvalue_unichar, decvalue_unichar - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006706Part 01: TTCN-3 Core LanguageTechnicalpublic27-03-2014 12:4124-07-2014 14:47
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PriorityurgentSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.6.1 (published 2014-06) 
Target Versionv4.6.2 (interim 2014)Fixed in Versionv4.6.2 (interim 2014) 
Clause Reference(s)C.1.31, C.1.32, C.5.3, C.5.4
Source (company - Author)Elvior
Summary0006706: Encoding in oct2unichar, unichar2oct, encvalue_unichar, decvalue_unichar
DescriptionThis CR is related to TTCN-3:2014 (final draft, 4.5.3).
+
+The TTCN-3:2014 standard introduced new conversion and codec functions handling universal strings and specified several encoding options. However, these encoding options are insufficient as the standard omits one important aspect of multibyte encoding: the endianness. According to the examples, it seems that little endian is assumed, but this should be formally declared in the rules. Besides, it should be possible to use big endian encodings, since they are at least as common as little endian encodings. For that reason, I propose to add additional encoding strings: UTF-16BE, UTF-32BE, UCS-2BE (and eventually UCS-4BE, but this is just a synonym for UTF-32BE).
+
+There's also an error in the examples for oct2unichar and unichar2oct functions. The used encoding is not UCS-4, but UCS-2.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0006586closed Ina Schieferdecker How to encode to/decode from XML values containing non-ASCII characters? 
Attached Filesdocx CR6706_update_proposal.docx (28,926) 10-04-2014 12:58
http://oldforge.etsi.org/mantis/file_download.php?file_id=2995&type=bug
docx CR6706_resolution_v2.docx (31,470) 11-04-2014 13:47
http://oldforge.etsi.org/mantis/file_download.php?file_id=3017&type=bug
docx CR6706_resolution_v2-3.docx (32,261) 17-06-2014 09:21
http://oldforge.etsi.org/mantis/file_download.php?file_id=3037&type=bug
docx CR6706_resolution_v4.docx (44,774) 17-06-2014 17:51
http://oldforge.etsi.org/mantis/file_download.php?file_id=3041&type=bug
docx CR6706_resolution_v5.docx (47,295) 18-06-2014 13:29
http://oldforge.etsi.org/mantis/file_download.php?file_id=3050&type=bug
docx CR6706_resolution_v6.docx (51,972) 20-06-2014 09:55
http://oldforge.etsi.org/mantis/file_download.php?file_id=3069&type=bug
docx CR6706_resolution_v7.docx (52,494) 20-06-2014 10:17
http://oldforge.etsi.org/mantis/file_download.php?file_id=3070&type=bug
Issue History
Date ModifiedUsernameFieldChange
27-03-2014 12:41Tomas UrbanNew Issue
07-04-2014 11:48Jens GrabowskiNote Added: 0011935
08-04-2014 10:31Gyorgy RethyNote Added: 0011953
08-04-2014 10:34Gyorgy RethyAssigned To => Axel Rennoch
08-04-2014 10:34Gyorgy RethyStatusnew => assigned
08-04-2014 10:34Gyorgy RethyProduct Versionv4.5.1 (published 2013-04) => v4.6.1 (published 2014-06)
08-04-2014 10:34Gyorgy RethyTarget Version => v4.7.1 (published 2015-06)
08-04-2014 10:36Gyorgy RethyNote Edited: 0011953bug_revision_view_page.php?bugnote_id=11953#r4
09-04-2014 14:11Gyorgy RethyRelationship addedrelated to 0006586
09-04-2014 14:11Gyorgy RethyPrioritynormal => urgent
10-04-2014 12:58Axel RennochFile Added: CR6706_update_proposal.docx
10-04-2014 12:58Axel RennochAssigned ToAxel Rennoch => Tomas Urban
10-04-2014 12:59Axel RennochAssigned ToTomas Urban => Gyorgy Rethy
10-04-2014 13:03Axel RennochNote Added: 0012000
10-04-2014 13:03Axel RennochStatusassigned => confirmed
11-04-2014 13:46Gyorgy RethyNote Added: 0012028
11-04-2014 13:47Gyorgy RethyFile Added: CR6706_resolution_v2.docx
11-04-2014 13:48Gyorgy RethyAssigned ToGyorgy Rethy => Axel Rennoch
11-04-2014 13:48Gyorgy RethyStatusconfirmed => assigned
17-06-2014 09:21Axel RennochFile Added: CR6706_resolution_v2-3.docx
17-06-2014 09:23Axel RennochAssigned ToAxel Rennoch => Gyorgy Rethy
17-06-2014 09:23Axel RennochNote Added: 0012097
17-06-2014 09:23Axel RennochStatusassigned => confirmed
17-06-2014 15:58Gyorgy RethyTarget Versionv4.7.1 (published 2015-06) => v4.6.2 (interim 2014)
17-06-2014 17:51Gyorgy RethyNote Added: 0012113
17-06-2014 17:51Gyorgy RethyFile Added: CR6706_resolution_v4.docx
18-06-2014 07:31Gyorgy RethyAssigned ToGyorgy Rethy => Axel Rennoch
18-06-2014 07:31Gyorgy RethyStatusconfirmed => assigned
18-06-2014 08:35Gyorgy RethyNote Edited: 0012113bug_revision_view_page.php?bugnote_id=12113#r29
18-06-2014 13:29Axel RennochFile Added: CR6706_resolution_v5.docx
18-06-2014 13:31Axel RennochNote Added: 0012123
19-06-2014 16:46Axel RennochAssigned ToAxel Rennoch => Gyorgy Rethy
20-06-2014 09:20Gyorgy RethyStatusassigned => confirmed
20-06-2014 09:55Gyorgy RethyNote Added: 0012177
20-06-2014 09:55Gyorgy RethyFile Added: CR6706_resolution_v6.docx
20-06-2014 09:56Gyorgy RethyAssigned ToGyorgy Rethy => Tomas Urban
20-06-2014 09:56Gyorgy RethyStatusconfirmed => assigned
20-06-2014 09:56Gyorgy RethyNote Edited: 0012177bug_revision_view_page.php?bugnote_id=12177#r59
20-06-2014 09:57Gyorgy RethyStatusassigned => confirmed
20-06-2014 10:17Tomas UrbanFile Added: CR6706_resolution_v7.docx
20-06-2014 10:19Tomas UrbanNote Added: 0012180
20-06-2014 10:19Tomas UrbanStatusconfirmed => resolved
20-06-2014 10:19Tomas UrbanResolutionopen => fixed
20-06-2014 10:19Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
24-07-2014 14:47Gyorgy RethyNote Added: 0012203
24-07-2014 14:47Gyorgy RethyStatusresolved => closed
24-07-2014 14:47Gyorgy RethyFixed in Version => v4.6.2 (interim 2014)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011935) +
+ Jens Grabowski    +
+ 07-04-2014 11:48    +
+ 		+ + + + +
+ Agreed in principle.
+
+
+
+ + + + + + + + + + +
+ (0011953) +
+ Gyorgy Rethy    +
+ 08-04-2014 10:31    +
(edited on: 08-04-2014 10:36)
+ 		+ + + + +
+ STF478: Check where bid endian is specified in a reference-able way, e.g. in a standard. Also oct2int, unichar2oct are effected.
+
+
+
+
+
+ + + + + + + + + + +
+ (0012000) +
+ Axel Rennoch    +
+ 10-04-2014 13:03    +
+ 		+ + + + +
+ The list is not according to the latest version of ISO10646:2012 and has been updated. In addition abbreviations, attribute variants and references to ISO10646 have been updated.
+
+
+
+ + + + + + + + + + +
+ (0012028) +
+ Gyorgy Rethy    +
+ 11-04-2014 13:46    +
+ 		+ + + + +
+ Changes shall be marked with windows revision marking: easier to accept all, background colors has to be removed by sections (e.g. in tables we use background color intentionally).
+
+1) I have extended the note in clause 27.5; depending on 2), itmay need be revised.
+2) Old UCS-2 is a subset of UTF-16 (see also note in ISO 10646 p.16). So, in principle, deprecating UCS-2 should not cause any problem when testing SMS. However, this needed be cross-checked at the next session before the final decision is taken.
+3) Descriptions of the new codepoints to be added to clause 27.5.
+4) Deprecation of UCS-2 and UCS-4 shall be added to Annex G, as new clause G.10 (style of the previous clauses of Annex G can be used).
+
+Updated text is uploaded in CR6706_resolution_v2.docx
+
+
+
+ + + + + + + + + + +
+ (0012097) +
+ Axel Rennoch    +
+ 17-06-2014 09:23    +
+ 		+ + + + +
+ background colors removed, cross-check with iso10646-2012-0 done
+
+
+
+ + + + + + + + + + +
+ (0012113) +
+ Gyorgy Rethy    +
+ 17-06-2014 17:51    +
(edited on: 18-06-2014 08:35)
+ 		+ + + + +
+ See some additions and corrections in CR6706_resolution_v4.docx.
+Also some issues are discovered:
+- description of codepoints UTF-16LE/BE and UTF-32LE/BE to be added to $27.5
+- in predefined functions it has to be specified that the octets does not contain the BOMs
+- in the predefined functions the encoding string values UTF-16 and UTF-32 need to be defaulted to big endian explicitly
+
+
+
+
+
+ + + + + + + + + + +
+ (0012123) +
+ Axel Rennoch    +
+ 18-06-2014 13:31    +
+ 		+ + + + +
+ - discovered issues considered in uploaded version v5
+- also: update of reference to ISO/IEC 10646 (2012)
+
+
+
+ + + + + + + + + + +
+ (0012177) +
+ Gyorgy Rethy    +
+ 20-06-2014 09:55    +
(edited on: 20-06-2014 09:56)
+ 		+ + + + +
+ CR6706_resolution_v6.docx.
+
+It is OK for me.
+
+Minor corrections and modifications are added (e.g. UCS Transformation Format -> UCS Encoding sccheme (the new name used in ISO/IEC 10646) note on BOMs moved to mandatory text etc.).
+
+Please cross-check and set to resolved if you agree (i.e. if you have only editorial changes).
+
+
+
+
+
+ + + + + + + + + + +
+ (0012180) +
+ Tomas Urban    +
+ 20-06-2014 10:19    +
+ 		+ + + + +
+ Cross-checked. Only minor editorial changes were made. The last version of the proposal solves the issue and it is ready for inclusion into the next version of the core language standard.
+
+
+
+ + + + + + + + + + +
+ (0012203) +
+ Gyorgy Rethy    +
+ 24-07-2014 14:47    +
+ 		+ + + + +
+ Added to master copy of V4.6.2.
+
+ + diff --git a/docs/mantis/CR6707.md b/docs/mantis/CR6707.md new file mode 100644 index 0000000000000000000000000000000000000000..05c8c12b5798be9f539745afc7d33fdd2141f4af --- /dev/null +++ b/docs/mantis/CR6707.md @@ -0,0 +1,202 @@ + + + + + + + + + + + + + 0006707: Section 7.1.2: Clarification of compatible types with the List operator - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006707Part 01: TTCN-3 Core LanguageClarificationpublic27-03-2014 17:2306-10-2014 15:46
ReporterAndras Kovacs 
Assigned ToAxel Rennoch 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionwon't fix 
PlatformOSOS Version
Product Versionv4.6.1 (published 2014-06) 
Target Versionv4.7.1 (published 2015-06)Fixed in Versionv4.7.1 (published 2015-06) 
Clause Reference(s)7.1.2
Source (company - Author)STF470 - Andras Kovacs
Summary0006707: Section 7.1.2: Clarification of compatible types with the List operator
DescriptionSection 7.1.2 states that the list operator may act on 'values of string types, record of, set of, or array of the same root types'.
+Concatenation of 'record' and 'set' types have been omitted. Is this intentional?
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
27-03-2014 17:23Andras KovacsNew Issue
07-04-2014 07:14Andras KovacsNote Added: 0011930
08-04-2014 10:40Gyorgy RethyNote Added: 0011954
08-04-2014 10:41Gyorgy RethyAssigned To => Axel Rennoch
08-04-2014 10:41Gyorgy RethyStatusnew => assigned
08-04-2014 10:41Gyorgy RethyProduct Versionv4.5.1 (published 2013-04) => v4.6.1 (published 2014-06)
08-04-2014 10:41Gyorgy RethyTarget Version => v4.7.1 (published 2015-06)
06-10-2014 10:05Axel RennochNote Added: 0012218
06-10-2014 15:46Gyorgy RethyNote Added: 0012234
06-10-2014 15:46Gyorgy RethyStatusassigned => closed
06-10-2014 15:46Gyorgy RethyResolutionopen => won't fix
06-10-2014 15:46Gyorgy RethyFixed in Version => v4.7.1 (published 2015-06)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011930) +
+ Andras Kovacs    +
+ 07-04-2014 07:14    +
+ 		+ + + + +
+ In particular, the question is whether the following type of test case expression is valid:
+
+ type set IntegerSet1 {
+  integer a1 optional,
+  integer a2 optional,
+  integer a3 optional
+ };
+
+ type set IntegerSet2 {
+  integer a4 optional,
+  integer a5 optional,
+  integer a6 optional
+ };
+
+ type set LargeSet {
+  integer a1 optional,
+  integer a2 optional,
+  integer a3 optional,
+  integer a4 optional,
+  integer a5 optional,
+  integer a6 optional
+ };
+
+
+testcase TC_list_operator() runs on GeneralComp {
+    const IntegerSet1 c_set1 := {a1:=0,a2:=omit,a3:=2};
+    const IntegerSet2 c_set2 := {a4:=3,a5:=5,a6:=omit};
+    const LargeSet c_large := {a1:=0,a2:=omit,a3:=2,a4:=3,a5:=5,a6:=omit};
+
+    if ( c_set1 & c_set2 == c_large ) {
+        setverdict(pass);
+    } else {
+        setverdict(fail);
+    }
+}
+
+
+
+ + + + + + + + + + +
+ (0011954) +
+ Gyorgy Rethy    +
+ 08-04-2014 10:40    +
+ 		+ + + + +
+ Ask submitter for a reasonable use case.
+
+
+
+ + + + + + + + + + +
+ (0012218) +
+ Axel Rennoch    +
+ 06-10-2014 10:05    +
+ 		+ + + + +
+ Answer by authors:
+The use case would be a flexible constructing of comparisons, using recordX & recordY notation for concatenation.
+At STF470 we are just developing the testing suite - it is up to STF478 to decide whether such use case is important enough.
+
+
+
+ + + + + + + + + + +
+ (0012234) +
+ Gyorgy Rethy    +
+ 06-10-2014 15:46    +
+ 		+ + + + +
+ The types of the operands and the result are not compatible. It is intentionally forbidden to concatenate record and set values.
+
+ + diff --git a/docs/mantis/CR6708.md b/docs/mantis/CR6708.md new file mode 100644 index 0000000000000000000000000000000000000000..6fae7b489bec93146a1231305baef508615a7527 --- /dev/null +++ b/docs/mantis/CR6708.md @@ -0,0 +1,171 @@ + + + + + + + + + + + + + 0006708: Section 23.6: the timer queue handling for timeout checking of 'any' timer - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006708Part 01: TTCN-3 Core LanguageTechnicalpublic27-03-2014 17:3206-01-2015 16:01
ReporterAndras Kovacs 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.5.1 (published 2013-04) 
Target Versionv4.7.1 (published 2015-06)Fixed in Versionv4.7.1 (published 2015-06) 
Clause Reference(s)23.6
Source (company - Author)STF470 - Andras Kovacs
Summary0006708: Section 23.6: the timer queue handling for timeout checking of 'any' timer
DescriptionConsider the following timeout check:
+[] any timer.timeout
+
+When the above condition is selected by the expiration of any timer, should the corresponding timer be removed from the queue?
+For example: if the trigger has been the timeout of timer[1], what should the subsequently called t_timer[1].running expression evaluate to?
+
+This should be specifically stated in the document.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR-6708-Resolution-V140410-1.doc (77,312) 10-04-2014 11:30
http://oldforge.etsi.org/mantis/file_download.php?file_id=2991&type=bug
Issue History
Date ModifiedUsernameFieldChange
27-03-2014 17:32Andras KovacsNew Issue
08-04-2014 10:45Gyorgy RethyNote Added: 0011955
08-04-2014 10:45Gyorgy RethyTarget Version => v4.7.1 (published 2015-06)
08-04-2014 10:46Gyorgy RethyAssigned To => Jens Grabowski
08-04-2014 10:46Gyorgy RethyStatusnew => assigned
10-04-2014 11:30Jens GrabowskiNote Added: 0011992
10-04-2014 11:30Jens GrabowskiFile Added: CR-6708-Resolution-V140410-1.doc
10-04-2014 11:31Jens GrabowskiAssigned ToJens Grabowski => Tomas Urban
10-04-2014 11:32Jens GrabowskiStatusassigned => confirmed
10-04-2014 11:44Tomas UrbanNote Added: 0011993
10-04-2014 11:44Tomas UrbanStatusconfirmed => resolved
10-04-2014 11:44Tomas UrbanResolutionopen => fixed
10-04-2014 11:44Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
17-06-2014 16:19Gyorgy RethyFixed in Version => v4.7.1 (published 2015-06)
20-06-2014 11:48Gyorgy RethyFixed in Versionv4.7.1 (published 2015-06) =>
06-01-2015 16:01Gyorgy RethyNote Added: 0012639
06-01-2015 16:01Gyorgy RethyStatusresolved => closed
06-01-2015 16:01Gyorgy RethyFixed in Version => v4.7.1 (published 2015-06)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011955) +
+ Gyorgy Rethy    +
+ 08-04-2014 10:45    +
+ 		+ + + + +
+ Amend the core language text to make clear that the timer name is removed from the timeout list.
+
+
+
+ + + + + + + + + + +
+ (0011992) +
+ Jens Grabowski    +
+ 10-04-2014 11:30    +
+ 		+ + + + +
+ Resolution proposal attached.
+
+
+
+ + + + + + + + + + +
+ (0011993) +
+ Tomas Urban    +
+ 10-04-2014 11:44    +
+ 		+ + + + +
+ Fine by me.
+
+
+
+ + + + + + + + + + +
+ (0012639) +
+ Gyorgy Rethy    +
+ 06-01-2015 16:01    +
+ 		+ + + + +
+ Added to draft V4.6.3
+
+ + diff --git a/docs/mantis/CR6709.md b/docs/mantis/CR6709.md new file mode 100644 index 0000000000000000000000000000000000000000..7395ccad4cbffaf1d3ce0fa21745faa7e794d2d3 --- /dev/null +++ b/docs/mantis/CR6709.md @@ -0,0 +1,161 @@ + + + + + + + + + + + + + 0006709: 22.3: What should happen when addresses are used on connected ports? - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006709Part 01: TTCN-3 Core LanguageTechnicalpublic27-03-2014 17:4906-01-2015 17:02
ReporterAndras Kovacs 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.5.1 (published 2013-04) 
Target Versionv4.7.1 (published 2015-06)Fixed in Versionv4.7.1 (published 2015-06) 
Clause Reference(s)22.3
Source (company - Author)STF470 - Andras Kovacs
Summary0006709: 22.3: What should happen when addresses are used on connected ports?
DescriptionIt is not specified what should happen when addresses are used on connected ports, as in the following example (full test case attached):
+
+    type charstring address;
+    const address c_client1Addr := "client1Addr";
+    const address c_client2Addr := "client2Addr";
+
+    type component GeneralComp {
+        port remotePort PCO;
+        var address v_myAddress;
+    }
+
+
+testcase TC_CallOperation() runs on GeneralComp system GeneralComp {
+        var GeneralComp server := GeneralComp.create("RemoteProcedure Service");
+        var GeneralComp client := GeneralComp.create("RemoteProcedure Client");
+        var GeneralComp client2 := GeneralComp.create("RemoteProcedure Client");
+        // map the PTCs to the system port
+        connect(server:PCO, client:PCO);
+        connect(server:PCO, client2:PCO);
+
+        server.start(f_ServerResponses());
+       
+        client.start(f_ClientQuery(c_client1Addr));
+        client2.start(f_ClientQuery(c_client2Addr));
+...
+}
+
+It is a question whether these test cases should:
+A: just fail to match this kind of alternatives (because the address type of the value in the sender clause is not compatible with the sending component) or
+B: produce a runtime error (because of type incompatibility during redirect assignment) as this situation is not described in the core language specification.
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files? Sem_220301_CallOperation_004.ttcn (3,931) 27-03-2014 17:49
http://oldforge.etsi.org/mantis/file_download.php?file_id=2977&type=bug
docx CR6709_v1-140616-JG.docx (19,650) 18-06-2014 13:29
http://oldforge.etsi.org/mantis/file_download.php?file_id=3049&type=bug
Issue History
Date ModifiedUsernameFieldChange
27-03-2014 17:49Andras KovacsNew Issue
27-03-2014 17:49Andras KovacsFile Added: Sem_220301_CallOperation_004.ttcn
08-04-2014 10:48Gyorgy RethyAssigned To => Jens Grabowski
08-04-2014 10:48Gyorgy RethyStatusnew => assigned
08-04-2014 10:48Gyorgy RethyTarget Version => v4.7.1 (published 2015-06)
18-06-2014 13:27Jens GrabowskiFile Added: CR6709_v1-140616-JG.docx
18-06-2014 13:28Jens GrabowskiFile Deleted: CR6709_v1-140616-JG.docx
18-06-2014 13:29Jens GrabowskiFile Added: CR6709_v1-140616-JG.docx
18-06-2014 13:29Jens GrabowskiNote Added: 0012122
18-06-2014 13:29Jens GrabowskiAssigned ToJens Grabowski => Tomas Urban
18-06-2014 13:29Jens GrabowskiStatusassigned => confirmed
18-06-2014 15:20Tomas UrbanNote Added: 0012131
18-06-2014 15:20Tomas UrbanStatusconfirmed => resolved
18-06-2014 15:20Tomas UrbanResolutionopen => fixed
18-06-2014 15:20Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
06-01-2015 17:02Gyorgy RethyNote Added: 0012644
06-01-2015 17:02Gyorgy RethyStatusresolved => closed
06-01-2015 17:02Gyorgy RethyFixed in Version => v4.7.1 (published 2015-06)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0012122) +
+ Jens Grabowski    +
+ 18-06-2014 13:29    +
+ 		+ + + + +
+ Resolution: Further restriction in Clause 6.2.12 "Addressing entities inside the SUT". Resolution attached, assigned to Tomas for proofreading.
+
+
+
+ + + + + + + + + + +
+ (0012131) +
+ Tomas Urban    +
+ 18-06-2014 15:20    +
+ 		+ + + + +
+ The proposed rule change solves the reported issue and it is ready to be included in the next version of the TTCN-3 core language standard.
+
+
+
+ + + + + + + + + + +
+ (0012644) +
+ Gyorgy Rethy    +
+ 06-01-2015 17:02    +
+ 		+ + + + +
+ Added to draft V4.6.3
+
+ + diff --git a/docs/mantis/CR6710.md b/docs/mantis/CR6710.md new file mode 100644 index 0000000000000000000000000000000000000000..01b891523ff0a234be933a99ba7c2d2d48bb6cd0 --- /dev/null +++ b/docs/mantis/CR6710.md @@ -0,0 +1,267 @@ + + + + + + + + + + + + + 0006710: Activate using timers declared in control block - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006710Part 01: TTCN-3 Core LanguageTechnicalpublic03-04-2014 13:3305-01-2015 17:51
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.5.1 (published 2013-04) 
Target Versionv4.7.1 (published 2015-06)Fixed in Versionv4.7.1 (published 2015-06) 
Clause Reference(s)20.5.2
Source (company - Author)Elvior
Summary0006710: Activate using timers declared in control block
DescriptionThe TTCN-3:2014 specification allows to use timers declared in the control block as parameters of altstep used in the activate operation (restriction 20.5.2.b). However, it is not clear if the rule allows to use timers from a child blocks of the control block or not. I think that the timers from the child block shall not be allowed, because the default might be processed after exiting the child block, i.e. when the timer has been already destroyed as in the following example:
+
+altstep(timer t) {
+  [] t. timeout { stop; }
+}
+
+control {
+  var boolean v_bCondition := false;
+  timer t_global := 10.0;
+  t_global.start;
+  if (v_bCondition) {
+    timer t_local := 1.0;
+    t_local.start;
+    activate(a(t_local)); // activation using local timer
+    ...
+  }
+  // local timer t_local no longer exists, but the default will be activated
+  // in the following alt:
+  t_global.timeout;
+}
+
+Proposal:
+The restriction 20.5.2.b shall mention that the rule doesn't include timers declared in child statement blocks of the module control part.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR6710_update_proposal.docx (16,751) 10-04-2014 14:46
http://oldforge.etsi.org/mantis/file_download.php?file_id=3005&type=bug
docx CR6710_v2.docx (17,077) 18-06-2014 08:11
http://oldforge.etsi.org/mantis/file_download.php?file_id=3042&type=bug
Issue History
Date ModifiedUsernameFieldChange
03-04-2014 13:33Tomas UrbanNew Issue
08-04-2014 10:49Gyorgy RethyAssigned To => Axel Rennoch
08-04-2014 10:49Gyorgy RethyStatusnew => assigned
08-04-2014 10:49Gyorgy RethyTarget Version => v4.7.1 (published 2015-06)
10-04-2014 14:46Axel RennochFile Added: CR6710_update_proposal.docx
10-04-2014 14:46Axel RennochAssigned ToAxel Rennoch => Gyorgy Rethy
10-04-2014 14:46Axel RennochNote Added: 0012011
10-04-2014 14:46Axel RennochStatusassigned => confirmed
11-04-2014 13:05Gyorgy RethyNote Added: 0012025
11-04-2014 13:06Gyorgy RethyAssigned ToGyorgy Rethy => Tomas Urban
11-04-2014 13:06Gyorgy RethyStatusconfirmed => assigned
11-04-2014 13:23Tomas UrbanNote Added: 0012027
18-06-2014 08:11Tomas UrbanFile Added: CR6710_v2.docx
18-06-2014 08:12Tomas UrbanNote Added: 0012115
18-06-2014 08:12Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
18-06-2014 08:12Tomas UrbanStatusassigned => confirmed
06-10-2014 15:49Gyorgy RethyAssigned ToGyorgy Rethy => Jens Grabowski
07-10-2014 15:13Jens GrabowskiNote Added: 0012256
07-10-2014 15:13Jens GrabowskiAssigned ToJens Grabowski => Gyorgy Rethy
07-10-2014 15:13Jens GrabowskiStatusconfirmed => assigned
07-10-2014 15:13Jens GrabowskiStatusassigned => resolved
07-10-2014 15:13Jens GrabowskiResolutionopen => fixed
05-01-2015 17:51Gyorgy RethyNote Added: 0012627
05-01-2015 17:51Gyorgy RethyStatusresolved => closed
05-01-2015 17:51Gyorgy RethyFixed in Version => v4.7.1 (published 2015-06)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0012011) +
+ Axel Rennoch    +
+ 10-04-2014 14:46    +
+ 		+ + + + +
+ Problem: local timer defined in control part statement blocks should not appear as a parameter to altstep (they are not existing anymore after leaving the statement block)
+
+Analysis
+definitions within local statement block do not exist anymore after leaving the behavior block. The activation is not anymore valid and thus should not be allowed
+
+
+
+ + + + + + + + + + +
+ (0012025) +
+ Gyorgy Rethy    +
+ 11-04-2014 13:05    +
+ 		+ + + + +
+ I agree, that would be a silly coding style, but in TTCN-3 it is allowed. Allk timers are objects of the component instance, in this case the control part "component". So, actually, t_local is destroyed when the block is left, "just" its name becomes directly inaccessible. I.e., yes, for the
+ t_global.timeout; statement, t_local will expire earlier and causing stop of execution.
+Btw. t_local still can be accessed outside of the block indirectly, by e.g.
+any timer.running;
+all timer.stop;
+
+Let discuss the CR at the next session.
+
+
+
+ + + + + + + + + + +
+ (0012027) +
+ Tomas Urban    +
+ 11-04-2014 13:23    +
+ 		+ + + + +
+ György, I am afraid that you are not right. Timeout doesn't survive exit from a scope block according to this note from the section 12: "Timers declared and started in scope units such as functions cease to exist when the scope unit is left. They do not contribute to the test behaviour once the scope unit is left."
+(Maybe this should not be a note, but a rule, because it seems to constitute a mandatory behaviour.)
+
+Besides, if we allow this kind of behaviour for local timers of a control block, it is a question why we cannot do the same for local component timers. The whole idea behind the original proposal and the way how timers in the versions that preceded 4.6.1 were handled was that users don't have to think about out-of-scope timers being processed in the default procedure.
+
+
+
+ + + + + + + + + + +
+ (0012115) +
+ Tomas Urban    +
+ 18-06-2014 08:12    +
+ 		+ + + + +
+ Slightly modified according to yesterday discussion. Please check.
+
+
+
+ + + + + + + + + + +
+ (0012256) +
+ Jens Grabowski    +
+ 07-10-2014 15:13    +
+ 		+ + + + +
+ Resolution is fine with me.
+
+
+
+ + + + + + + + + + +
+ (0012627) +
+ Gyorgy Rethy    +
+ 05-01-2015 17:51    +
+ 		+ + + + +
+ Added to draft V4.6.3
+
+ + diff --git a/docs/mantis/CR6711.md b/docs/mantis/CR6711.md new file mode 100644 index 0000000000000000000000000000000000000000..be0c7023db215b2222ef7ed08da3e7d65b951c03 --- /dev/null +++ b/docs/mantis/CR6711.md @@ -0,0 +1,281 @@ + + + + + + + + + + + + + 0006711: Section 15.9: the phrasing of restriction a) must be made more precise - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006711Part 01: TTCN-3 Core LanguageTechnicalpublic07-04-2014 07:4604-01-2015 20:17
ReporterAndras Kovacs 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.5.1 (published 2013-04) 
Target Versionv4.7.1 (published 2015-06)Fixed in Versionv4.7.1 (published 2015-06) 
Clause Reference(s)15.9
Source (company - Author)STF470 - Andras Kovacs
Summary0006711: Section 15.9: the phrasing of restriction a) must be made more precise
DescriptionRestriction a) states: "The expression-parameter of the match operation shall not evaluate to a template, i.e. the match operation cannot be used to compare two templates."
+The above restriction can be interpreted in two different ways:
+
+A: a template as an input parameter of a match operation
+B: "shall not evaluate to a template" is interpreted to meant that, if evaluated, it will not contain any constraints, i.e. is a value. This is true for initialized template(value) variables. Othrwise,the text should have stated "shall not be a template".
+
+The meaning of the restriction must be made more clear in light of the above ambiguity.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx draft-res-6711.docx (19,955) 10-10-2014 12:48
http://oldforge.etsi.org/mantis/file_download.php?file_id=3145&type=bug
docx draft-res-6711-v2.docx (22,213) 03-11-2014 12:40
http://oldforge.etsi.org/mantis/file_download.php?file_id=3148&type=bug
docx draft-res-6711-v3.docx (22,247) 03-11-2014 13:08
http://oldforge.etsi.org/mantis/file_download.php?file_id=3150&type=bug
Issue History
Date ModifiedUsernameFieldChange
07-04-2014 07:46Andras KovacsNew Issue
08-04-2014 10:59Gyorgy RethyNote Added: 0011956
08-04-2014 10:59Gyorgy RethyAssigned To => Gyorgy Rethy
08-04-2014 10:59Gyorgy RethyStatusnew => assigned
08-04-2014 10:59Gyorgy RethyTarget Version => v4.7.1 (published 2015-06)
10-10-2014 10:41Gyorgy RethyAssigned ToGyorgy Rethy => Axel Rennoch
10-10-2014 12:48Axel RennochFile Added: draft-res-6711.docx
10-10-2014 12:48Axel RennochAssigned ToAxel Rennoch => Gyorgy Rethy
10-10-2014 12:50Axel RennochNote Added: 0012365
10-10-2014 12:50Axel RennochStatusassigned => confirmed
13-10-2014 09:24Gyorgy RethyNote Added: 0012367
13-10-2014 09:24Gyorgy RethyAssigned ToGyorgy Rethy => Axel Rennoch
13-10-2014 09:29Gyorgy RethyNote Edited: 0012367bug_revision_view_page.php?bugnote_id=12367#r89
03-11-2014 12:40Axel RennochFile Added: draft-res-6711-v2.docx
03-11-2014 12:42Axel RennochAssigned ToAxel Rennoch => Tomas Urban
03-11-2014 12:42Axel RennochStatusconfirmed => assigned
03-11-2014 12:43Axel RennochNote Added: 0012374
03-11-2014 12:43Axel RennochStatusassigned => confirmed
03-11-2014 13:08Tomas UrbanFile Added: draft-res-6711-v3.docx
03-11-2014 13:17Tomas UrbanNote Added: 0012376
03-11-2014 13:17Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
05-11-2014 16:27Gyorgy RethyNote Added: 0012439
05-11-2014 16:27Gyorgy RethyStatusconfirmed => resolved
05-11-2014 16:27Gyorgy RethyFixed in Version => v4.7.1 (published 2015-06)
05-11-2014 16:27Gyorgy RethyResolutionopen => fixed
04-01-2015 20:17Gyorgy RethyNote Added: 0012611
04-01-2015 20:17Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011956) +
+ Gyorgy Rethy    +
+ 08-04-2014 10:59    +
+ 		+ + + + +
+ Cross-check template definition, expressions clause and all places where expression is used. Add note to clause 7 saying that templates can be used at the RHS of assignment, parameter passing and (predefined) functions where template passing is explicitly allowed.
+
+
+
+ + + + + + + + + + +
+ (0012365) +
+ Axel Rennoch    +
+ 10-10-2014 12:50    +
+ 		+ + + + +
+ Re-wording following the CR, note to clause 7 added, cross-check done. Please have a look to changes.
+
+
+
+ + + + + + + + + + +
+ (0012367) +
+ Gyorgy Rethy    +
+ 13-10-2014 09:24    +
(edited on: 13-10-2014 09:29)
+ 		+ + + + +
+ The text proposed in the CR is unclear to me, we should not follow it directly (i.e. the term "constrain" is not defined, while "constraint" and "constrained" are intensively used in relation to subtyping).
+
+I propose to solve the CR in the opposite way: state explicitly that the argument of the match shall evaluate to a value. We have a definition for value:
+value: TTCN-3 data objects are values or templates by definition. A TTCN 3 value is an instance of its type
+NOTE: Values are defined by module parameters, constants, value variables, or formal value parameters. Any of those are value objects from the point of view of their usage.
+
+To remove Andras's ambiguity note could be extended by:" A template containing only specific value matching - though refering to a single instance of its type - is not a value object, but is a template object."
+
+
+
+
+
+ + + + + + + + + + +
+ (0012374) +
+ Axel Rennoch    +
+ 03-11-2014 12:43    +
+ 		+ + + + +
+ A revised resolution taking into account latest comments.
+
+
+
+ + + + + + + + + + +
+ (0012376) +
+ Tomas Urban    +
+ 03-11-2014 13:17    +
+ 		+ + + + +
+ I made one small changes in the proposal, but otherwise it is fine by me. Gyorgy, could please take a look at it before marking it as resolved?
+
+
+
+ + + + + + + + + + +
+ (0012439) +
+ Gyorgy Rethy    +
+ 05-11-2014 16:27    +
+ 		+ + + + +
+ Fine with me.
+
+
+
+ + + + + + + + + + +
+ (0012611) +
+ Gyorgy Rethy    +
+ 04-01-2015 20:17    +
+ 		+ + + + +
+ Added to draft V4.6.3
+
+ + diff --git a/docs/mantis/CR6712.md b/docs/mantis/CR6712.md new file mode 100644 index 0000000000000000000000000000000000000000..26157a4a098e77d04a491b6ea77561d13d7c0ee5 --- /dev/null +++ b/docs/mantis/CR6712.md @@ -0,0 +1,166 @@ + + + + + + + + + + + + + 0006712: Reference to TFT should be removed - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Config & Deployment Support (ES 202 781)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006712Ext Pack: Config & Deployment Support (ES 202 781)Editorialpublic08-04-2014 14:0308-01-2015 11:30
ReporterGyorgy Rethy 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv1.2.1 (published 2013-06) 
Target Versionv1.4.1 (published 2015-06)Fixed in Version 
Clause Reference(s)2.2 & 4
Source (company - Author)L.M.Ericsson
TS versionN/A
Summary0006712: Reference to TFT should be removed
DescriptionThe document references ES 202 783-2 in the informative references and in the package compatibility clauses. As this part has been made historical, it should be removed from those lists.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
08-04-2014 14:03Gyorgy RethyNew Issue
08-04-2014 14:03Gyorgy RethyAssigned To => Jens Grabowski
08-04-2014 14:03Gyorgy RethyStatusnew => assigned
08-04-2014 14:03Gyorgy RethyTarget Version => v1.4.1 (published 2015-06)
08-04-2014 17:35Gyorgy RethyProduct Versionv1.3.1 (published 2014-06) => v1.2.1 (published 2013-06)
17-06-2014 13:36Gyorgy RethyNote Added: 0012104
20-06-2014 09:41Jens GrabowskiNote Added: 0012176
07-01-2015 09:27Jens GrabowskiNote Added: 0012664
08-01-2015 11:30Jens GrabowskiNote Added: 0012667
08-01-2015 11:30Jens GrabowskiStatusassigned => closed
08-01-2015 11:30Jens GrabowskiResolutionopen => fixed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0012104) +
+ Gyorgy Rethy    +
+ 17-06-2014 13:36    +
+ 		+ + + + +
+ STF discussion:
+Remove TFT and GFT references from all extension packages. TFT is historical. The packages are not aligned with GFT.
+
+
+
+ + + + + + + + + + +
+ (0012176) +
+ Jens Grabowski    +
+ 20-06-2014 09:41    +
+ 		+ + + + +
+ Removed from Draft of ETSI ES 202 786: Methods for Testing and Specification (MTS); The Testing and Test Control Notation version 3; TTCN-3 Language Extensions: Support of interfaces with continuous signals
+
+
+
+ + + + + + + + + + +
+ (0012664) +
+ Jens Grabowski    +
+ 07-01-2015 09:27    +
+ 		+ + + + +
+ Removed from Draft of ETSI ES 202 781: Methods for Testing and Specification (MTS); The Testing and Test Control Notation version 3; TTCN-3 Language Extensions: Configuration and Deployment Support
+
+
+
+ + + + + + + + + + +
+ (0012667) +
+ Jens Grabowski    +
+ 08-01-2015 11:30    +
+ 		+ + + + +
+ References have been removed.
+
+ + diff --git a/docs/mantis/CR6713.md b/docs/mantis/CR6713.md new file mode 100644 index 0000000000000000000000000000000000000000..cd7eb02d819874d97c93c8b98263bdda63464716 --- /dev/null +++ b/docs/mantis/CR6713.md @@ -0,0 +1,29 @@ + + + + + + + + + + + + + 0006713: Remove TFT from the standard - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006713Part 01: TTCN-3 Core LanguageEditorialpublic08-04-2014 14:2823-06-2014 11:45
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.6.1 (published 2014-06) 
Target Versionv4.7.1 (published 2015-06)Fixed in Versionv4.6.2 (interim 2014) 
Clause Reference(s)4.1
Source (company - Author)L.M.Ericsson
Summary0006713: Remove TFT from the standard
DescriptionES 201 873-2 has been made historical. It is referenced in clause 4.1. All references to historical documents should be removed.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
08-04-2014 14:28Gyorgy RethyNew Issue
08-04-2014 17:05Gyorgy RethyProduct Version => v4.6.1 (published 2014-06)
08-04-2014 17:05Gyorgy RethyTarget Version => v4.7.1 (published 2015-06)
19-06-2014 17:29Gyorgy RethyAssigned To => Gyorgy Rethy
19-06-2014 17:29Gyorgy RethyStatusnew => assigned
23-06-2014 11:45Gyorgy RethyStatusassigned => closed
23-06-2014 11:45Gyorgy RethyResolutionopen => fixed
23-06-2014 11:45Gyorgy RethyFixed in Version => v4.6.2 (interim 2014)
+
+ + + + +
+ There are no notes attached to this issue.
+ + diff --git a/docs/mantis/CR6714.md b/docs/mantis/CR6714.md new file mode 100644 index 0000000000000000000000000000000000000000..3ef14f91605d037da73a20d1c94b525dc26921bc --- /dev/null +++ b/docs/mantis/CR6714.md @@ -0,0 +1,241 @@ + + + + + + + + + + + + + 0006714: Expansion of LHS in case of uninitialized constructive variables - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006714Part 01: TTCN-3 Core LanguageTechnicalpublic08-04-2014 14:4923-09-2014 15:25
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PriorityurgentSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.5.1 (published 2013-04) 
Target Versionv4.6.2 (interim 2014)Fixed in Versionv4.6.2 (interim 2014) 
Clause Reference(s)6.2
Source (company - Author)STF 478
Summary0006714: Expansion of LHS in case of uninitialized constructive variables
DescriptionIt might be obvious what happens if the LHS of an assignment contains a reference to a record field and the record itself is uninitialized or omitted, i.e. that the record value is created, the RHS is assigned to the referenced field and all remaining fields become uninitialized (unless "implicit omit" is involved). However, this kind of rule is missing from the core language specification and should be added for values of the following constructive types: record, set, record of, set of, array, union.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0006700closed Gyorgy Rethy Clarification for clause 15.6.3 
related to 0006715closed Gyorgy Rethy Referencing alternatives of union templates 
related to 0006717closed Gyorgy Rethy Values of address type in expressions and references 
Attached Filesdocx CR6714_v1.docx (31,945) 09-04-2014 10:32
http://oldforge.etsi.org/mantis/file_download.php?file_id=2979&type=bug
docx CR6714_v2.docx (33,814) 10-04-2014 13:10
http://oldforge.etsi.org/mantis/file_download.php?file_id=2996&type=bug
docx CR6714_v3.docx (37,004) 01-08-2014 14:41
http://oldforge.etsi.org/mantis/file_download.php?file_id=3080&type=bug
docx CR6714_v4.docx (39,396) 11-08-2014 10:15
http://oldforge.etsi.org/mantis/file_download.php?file_id=3081&type=bug
Issue History
Date ModifiedUsernameFieldChange
08-04-2014 14:49Tomas UrbanNew Issue
08-04-2014 14:49Tomas UrbanStatusnew => assigned
08-04-2014 14:49Tomas UrbanAssigned To => Tomas Urban
09-04-2014 09:18Tomas UrbanRelationship addedrelated to 0006700
09-04-2014 10:31Tomas UrbanRelationship addedrelated to 0006715
09-04-2014 10:32Tomas UrbanAssigned ToTomas Urban =>
09-04-2014 10:32Tomas UrbanFile Added: CR6714_v1.docx
09-04-2014 10:35Tomas UrbanNote Added: 0011967
09-04-2014 10:35Tomas UrbanAssigned To => Jens Grabowski
09-04-2014 13:31Tomas UrbanRelationship addedrelated to 0006717
09-04-2014 14:03Gyorgy RethyPrioritynormal => urgent
10-04-2014 11:07Tomas UrbanStatusassigned => confirmed
10-04-2014 11:47Jens GrabowskiNote Added: 0011994
10-04-2014 11:47Jens GrabowskiAssigned ToJens Grabowski => Tomas Urban
10-04-2014 11:47Jens GrabowskiStatusconfirmed => assigned
10-04-2014 11:48Jens GrabowskiStatusassigned => confirmed
10-04-2014 13:10Tomas UrbanFile Added: CR6714_v2.docx
10-04-2014 13:12Tomas UrbanNote Added: 0012001
10-04-2014 13:12Tomas UrbanAssigned ToTomas Urban => Jens Grabowski
07-05-2014 16:30Gyorgy RethyProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
11-05-2014 20:49Gyorgy RethyTarget Version => v4.7.1 (published 2015-06)
16-06-2014 09:02Jens GrabowskiNote Added: 0012073
16-06-2014 09:03Jens GrabowskiAssigned ToJens Grabowski => Gyorgy Rethy
16-06-2014 09:03Jens GrabowskiStatusconfirmed => assigned
16-06-2014 09:04Jens GrabowskiStatusassigned => resolved
16-06-2014 09:04Jens GrabowskiResolutionopen => fixed
17-06-2014 15:58Gyorgy RethyProduct Version => v4.5.1 (published 2013-04)
17-06-2014 15:58Gyorgy RethyFixed in Version => v4.6.2 (interim 2014)
17-06-2014 15:58Gyorgy RethyTarget Versionv4.7.1 (published 2015-06) => v4.6.2 (interim 2014)
20-06-2014 11:54Gyorgy RethyFixed in Versionv4.6.2 (interim 2014) =>
01-08-2014 14:40Gyorgy RethyNote Added: 0012210
01-08-2014 14:40Gyorgy RethyStatusresolved => confirmed
01-08-2014 14:41Gyorgy RethyFile Added: CR6714_v3.docx
01-08-2014 14:41Gyorgy RethyAssigned ToGyorgy Rethy => Tomas Urban
01-08-2014 14:41Gyorgy RethyStatusconfirmed => assigned
01-08-2014 14:42Gyorgy RethyStatusassigned => confirmed
11-08-2014 10:15Tomas UrbanFile Added: CR6714_v4.docx
11-08-2014 10:19Tomas UrbanNote Added: 0012214
11-08-2014 10:19Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
23-09-2014 15:25Gyorgy RethyStatusconfirmed => closed
23-09-2014 15:25Gyorgy RethyFixed in Version => v4.6.2 (interim 2014)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011967) +
+ Tomas Urban    +
+ 09-04-2014 10:35    +
+ 		+ + + + +
+ Proposal created. It formalizes the common convension for referencing fields of omitted and uninitialized values.
+Please check.
+
+
+
+ + + + + + + + + + +
+ (0011994) +
+ Jens Grabowski    +
+ 10-04-2014 11:47    +
+ 		+ + + + +
+ What means:
+- implicitly or explicitly set to "implicit omit"
+- implicitly or explicitly set to "explicit omit"
+
+The values "implicit omit" and "explicit omit" are unknown to me. In addition, an explicitly set to "implicit omit" should become an "explicit omit" and vice versa.
+
+
+
+ + + + + + + + + + +
+ (0012001) +
+ Tomas Urban    +
+ 10-04-2014 13:12    +
+ 		+ + + + +
+ Changed the wording: implicitly or explicitly set to -> equal to
+Please check.
+
+
+
+ + + + + + + + + + +
+ (0012073) +
+ Jens Grabowski    +
+ 16-06-2014 09:02    +
+ 		+ + + + +
+ Ok, from my point of view.
+
+
+
+ + + + + + + + + + +
+ (0012210) +
+ Gyorgy Rethy    +
+ 01-08-2014 14:40    +
+ 		+ + + + +
+ Text related to expansion of dot/index notations has been amended to unambiguously descibe the cases, when records/sets/recordofs/setofs/unions are mixing along the expansion.
+
+Pls. review CR6714_v3.docx. Changed text is identified by yellow background to allow quick review.
+
+
+
+ + + + + + + + + + +
+ (0012214) +
+ Tomas Urban    +
+ 11-08-2014 10:19    +
+ 		+ + + + +
+ I like the last changes in the proposal and I have no objection against them. I only made a small correction in the rules on union values, adding set of and array to the list of types that can be expanded.
+
+ + diff --git a/docs/mantis/CR6715.md b/docs/mantis/CR6715.md new file mode 100644 index 0000000000000000000000000000000000000000..d5af054593aa063d3eae6577a22d72b7a65054e3 --- /dev/null +++ b/docs/mantis/CR6715.md @@ -0,0 +1,234 @@ + + + + + + + + + + + + + 0006715: Referencing alternatives of union templates - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006715Part 01: TTCN-3 Core LanguageTechnicalpublic09-04-2014 10:3123-09-2014 16:17
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.6.1 (published 2014-06) 
Target Versionv4.6.2 (interim 2014)Fixed in Versionv4.6.2 (interim 2014) 
Clause Reference(s)15.6
Source (company - Author)STF 478
Summary0006715: Referencing alternatives of union templates
DescriptionThere are currently no rules for referencing union template fields that contain matching symbols, both for right hand and left hand side. E.g. in the RHS case, a reference to any alternative of a union template containing AnyValue should return AnyValue. In the LHS case, the most interesting case is again connected with AnyValue, where AnyValue should be first assigned to the referenced alternative so that it can be used for further expansion (e.g. if the alternative is a record) according to the rules specified in 15.6.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0006714closed Gyorgy Rethy Expansion of LHS in case of uninitialized constructive variables 
Attached Filesdocx CR6715_v1.docx (17,947) 09-04-2014 11:24
http://oldforge.etsi.org/mantis/file_download.php?file_id=2980&type=bug
docx CR6715_v2.docx (19,604) 10-04-2014 12:39
http://oldforge.etsi.org/mantis/file_download.php?file_id=2993&type=bug
docx CR6715_v3.docx (22,951) 10-04-2014 13:22
http://oldforge.etsi.org/mantis/file_download.php?file_id=2997&type=bug
docx CR6715_v4.docx (23,224) 11-04-2014 07:59
http://oldforge.etsi.org/mantis/file_download.php?file_id=3008&type=bug
docx CR6715_v5.docx (23,350) 11-04-2014 08:11
http://oldforge.etsi.org/mantis/file_download.php?file_id=3009&type=bug
Issue History
Date ModifiedUsernameFieldChange
09-04-2014 10:31Tomas UrbanNew Issue
09-04-2014 10:31Tomas UrbanStatusnew => assigned
09-04-2014 10:31Tomas UrbanAssigned To => Tomas Urban
09-04-2014 10:31Tomas UrbanRelationship addedrelated to 0006714
09-04-2014 11:24Tomas UrbanFile Added: CR6715_v1.docx
09-04-2014 11:25Tomas UrbanNote Added: 0011969
09-04-2014 11:26Tomas UrbanAssigned ToTomas Urban => Jens Grabowski
10-04-2014 11:09Tomas UrbanStatusassigned => confirmed
10-04-2014 12:39Jens GrabowskiFile Added: CR6715_v2.docx
10-04-2014 12:39Jens GrabowskiAssigned ToJens Grabowski => Tomas Urban
10-04-2014 12:39Jens GrabowskiStatusconfirmed => assigned
10-04-2014 12:39Jens GrabowskiNote Added: 0011997
10-04-2014 12:39Jens GrabowskiStatusassigned => confirmed
10-04-2014 13:22Tomas UrbanFile Added: CR6715_v3.docx
10-04-2014 13:23Tomas UrbanNote Added: 0012003
10-04-2014 13:23Tomas UrbanStatusconfirmed => resolved
10-04-2014 13:23Tomas UrbanResolutionopen => fixed
10-04-2014 13:23Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
11-04-2014 07:59Gyorgy RethyFile Added: CR6715_v4.docx
11-04-2014 07:59Gyorgy RethyNote Added: 0012014
11-04-2014 08:11Gyorgy RethyNote Added: 0012015
11-04-2014 08:11Gyorgy RethyFile Added: CR6715_v5.docx
11-05-2014 20:47Gyorgy RethyProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
11-05-2014 20:48Gyorgy RethyTarget Version => v4.7.1 (published 2015-06)
17-06-2014 16:21Gyorgy RethyProduct Version => v4.6.1 (published 2014-06)
17-06-2014 16:21Gyorgy RethyFixed in Version => v4.7.1 (published 2015-06)
20-06-2014 11:52Gyorgy RethyFixed in Versionv4.7.1 (published 2015-06) =>
28-07-2014 14:24Gyorgy RethyNote Added: 0012206
28-07-2014 14:24Gyorgy RethyPrioritynormal => urgent
28-07-2014 14:24Gyorgy RethyTarget Versionv4.7.1 (published 2015-06) => v4.6.2 (interim 2014)
28-07-2014 14:26Gyorgy RethyNote Deleted: 0012206
28-07-2014 15:11Gyorgy RethyPriorityurgent => normal
23-09-2014 16:17Gyorgy RethyNote Added: 0012217
23-09-2014 16:17Gyorgy RethyStatusresolved => closed
23-09-2014 16:17Gyorgy RethyFixed in Version => v4.6.2 (interim 2014)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011969) +
+ Tomas Urban    +
+ 09-04-2014 11:25    +
+ 		+ + + + +
+ Draft of proposed rules attached. The rules are based on the existing rules for records and there are several dedicated examples.
+Please check.
+
+
+
+ + + + + + + + + + +
+ (0011997) +
+ Jens Grabowski    +
+ 10-04-2014 12:39    +
+ 		+ + + + +
+ Some additional clarification is needed.
+
+
+
+ + + + + + + + + + +
+ (0012003) +
+ Tomas Urban    +
+ 10-04-2014 13:23    +
+ 		+ + + + +
+ After small corrections proposed by Jens, the resolution is ready to be inculed in the next version of the TTCN-3 standard.
+
+
+
+ + + + + + + + + + +
+ (0012014) +
+ Gyorgy Rethy    +
+ 11-04-2014 07:59    +
+ 		+ + + + +
+ Some editorials in CR6715_v4.docx
+
+
+
+ + + + + + + + + + +
+ (0012015) +
+ Gyorgy Rethy    +
+ 11-04-2014 08:11    +
+ 		+ + + + +
+ Version updated by Tomas is uploaded: CR6715_v5.docx
+
+
+
+ + + + + + + + + + +
+ (0012217) +
+ Gyorgy Rethy    +
+ 23-09-2014 16:17    +
+ 		+ + + + +
+ Added to draft V4.6.2
+
+ + diff --git a/docs/mantis/CR6716.md b/docs/mantis/CR6716.md new file mode 100644 index 0000000000000000000000000000000000000000..09e924b591a71e0f7e23ff3e7a8a8baf9ead3f7d --- /dev/null +++ b/docs/mantis/CR6716.md @@ -0,0 +1,135 @@ + + + + + + + + + + + + + 0006716: ISO/IEC 10646 version - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006716Part 01: TTCN-3 Core LanguageTechnicalpublic09-04-2014 11:0705-01-2015 18:40
ReporterAxel Rennoch 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.6.1 (published 2014-06) 
Target Versionv4.7.1 (published 2015-06)Fixed in Versionv4.7.1 (published 2015-06) 
Clause Reference(s)2.1, 6.1.1, 8, 27.5, C.2.1, E.2.2
Source (company - Author)Axel Rennoch
Summary0006716: ISO/IEC 10646 version
DescriptionCurrent TTCN-3 standard includes [2] as "ISO/IEC 10646" but without any date. Several references in the text appear to not refer to the latest version 2012 (e.g. [2] is not a multipart standard anymore).
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
09-04-2014 11:07Axel RennochNew Issue
06-10-2014 10:35Gyorgy RethyAssigned To => Gyorgy Rethy
06-10-2014 10:35Gyorgy RethyStatusnew => assigned
06-10-2014 10:35Gyorgy RethyAssigned ToGyorgy Rethy => Axel Rennoch
06-10-2014 10:45Gyorgy RethyNote Added: 0012221
06-10-2014 12:14Axel RennochNote Added: 0012229
06-10-2014 12:16Axel RennochAssigned ToAxel Rennoch => Gyorgy Rethy
06-10-2014 15:59Gyorgy RethyStatusassigned => resolved
06-10-2014 15:59Gyorgy RethyResolutionopen => fixed
06-10-2014 15:59Gyorgy RethyFixed in Version => v4.7.1 (published 2015-06)
05-01-2015 18:40Gyorgy RethyNote Added: 0012631
05-01-2015 18:40Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0012221) +
+ Gyorgy Rethy    +
+ 06-10-2014 10:45    +
+ 		+ + + + +
+ Axel, pls. check which clause references has changed in the new ISO 10646 version. A list in mantis is enough: <old clause> <new clause> is sufficient, no need for a .doc attachment. I will make the changes in the master document.
+
+
+
+ + + + + + + + + + +
+ (0012229) +
+ Axel Rennoch    +
+ 06-10-2014 12:14    +
+ 		+ + + + +
+ [2] ISO/IEC 10646:2012
+
+page 85, chapter 8: annex R -> chapter 10.1 (UTF-8)
+page 309, chapter e2.2.0: annex R -> chapter 10.1 (UTF-8)
+page 309, chapter e2.2.2: annex Q -> chapter 10.4 (UTF-16)
+
+
+
+ + + + + + + + + + +
+ (0012631) +
+ Gyorgy Rethy    +
+ 05-01-2015 18:40    +
+ 		+ + + + +
+ Added to draft V4.6.3
+
+ + diff --git a/docs/mantis/CR6717.md b/docs/mantis/CR6717.md new file mode 100644 index 0000000000000000000000000000000000000000..00ddc09de5951810eeda6ef127f7838005b91230 --- /dev/null +++ b/docs/mantis/CR6717.md @@ -0,0 +1,224 @@ + + + + + + + + + + + + + 0006717: Values of address type in expressions and references - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006717Part 01: TTCN-3 Core LanguageTechnicalpublic09-04-2014 13:3005-01-2015 17:31
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritylowSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.6.1 (published 2014-06) 
Target Versionv4.7.1 (published 2015-06)Fixed in Versionv4.7.1 (published 2015-06) 
Clause Reference(s)6.2
Source (company - Author)STF 478
Summary0006717: Values of address type in expressions and references
DescriptionSince address types are based on standard TTCN-3 types, their instances can be used in expressions and extended reference operators (dot notation, index notation) can be applied to them. However, in addition to all values of the base type, the values of the address type can contain a special value null. The current specification doesn't seem to provide guidelines for situation when an address value used in an extended reference or an expression contains this value.
+
+type integer address;
+...
+var address v_a := null;
+var integer v_i := 1 + v_a;
+
+type record address
+{
+  charstring host,
+  integer tcp_port
+}
+...
+var address v_a := null;
+var integer v_i := v_a.tcp_port
+
+It seems obvious that the above examples should produce an error. Therefore I propose to change the specification in the following way:
+
+1. Add explicit compatibility rules for the address type into the section 6.3 that exclude the null value. There's currently a note regarding the address type, but it doesn't consider existence of the null symbol. With null excluded, the problem with expressions will disappear as it won't be possible to convert it to a valid expression operand value.
+
+2. Add either a global rule for referencing an entity within a field to which null is assigned to the section 6.2.12, saying that rules for referencing omitted value are valid in this case or explicitly list the null value together with omit in all places where rules for extended references are specified (in 6.2, see the related CR)
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0006714closed Gyorgy Rethy Expansion of LHS in case of uninitialized constructive variables 
Attached Filesdocx CR6717_resolution_v1.docx (112,777) 07-10-2014 09:05
http://oldforge.etsi.org/mantis/file_download.php?file_id=3087&type=bug
docx CR6717_resolution_v2.docx (118,859) 07-10-2014 09:28
http://oldforge.etsi.org/mantis/file_download.php?file_id=3090&type=bug
docx CR6717_resolution_v3.docx (119,102) 08-10-2014 16:17
http://oldforge.etsi.org/mantis/file_download.php?file_id=3119&type=bug
Issue History
Date ModifiedUsernameFieldChange
09-04-2014 13:30Tomas UrbanNew Issue
09-04-2014 13:31Tomas UrbanRelationship addedrelated to 0006714
20-06-2014 11:42Gyorgy RethyProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
20-06-2014 11:42Gyorgy RethyProduct Version => v4.6.1 (published 2014-06)
20-06-2014 11:42Gyorgy RethyTarget Version => v4.6.1 (published 2014-06)
20-06-2014 11:48Gyorgy RethyTarget Versionv4.6.1 (published 2014-06) => v4.7.1 (published 2015-06)
06-10-2014 16:03Gyorgy RethyNote Added: 0012235
06-10-2014 16:03Gyorgy RethyAssigned To => Gyorgy Rethy
06-10-2014 16:03Gyorgy RethyPrioritynormal => low
06-10-2014 16:03Gyorgy RethyStatusnew => confirmed
07-10-2014 09:05Gyorgy RethyFile Added: CR6717_resolution_v1.docx
07-10-2014 09:05Gyorgy RethyNote Added: 0012243
07-10-2014 09:06Gyorgy RethyAssigned ToGyorgy Rethy => Tomas Urban
07-10-2014 09:28Tomas UrbanFile Added: CR6717_resolution_v2.docx
07-10-2014 09:31Tomas UrbanNote Added: 0012246
07-10-2014 09:31Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
08-10-2014 16:17Gyorgy RethyFile Added: CR6717_resolution_v3.docx
08-10-2014 16:17Gyorgy RethyNote Added: 0012295
08-10-2014 16:17Gyorgy RethyStatusconfirmed => resolved
08-10-2014 16:17Gyorgy RethyResolutionopen => fixed
08-10-2014 16:17Gyorgy RethyFixed in Version => v4.7.1 (published 2015-06)
05-01-2015 17:31Gyorgy RethyNote Added: 0012624
05-01-2015 17:31Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0012235) +
+ Gyorgy Rethy    +
+ 06-10-2014 16:03    +
+ 		+ + + + +
+ Add: null is not allowed as operand of expressions
+     referencing a field "behind" null is an error
+
+
+
+ + + + + + + + + + +
+ (0012243) +
+ Gyorgy Rethy    +
+ 07-10-2014 09:05    +
+ 		+ + + + +
+ Proposed resolution is uploaded in CR6717_resolution_v1.docx. Please review.
+
+
+
+ + + + + + + + + + +
+ (0012246) +
+ Tomas Urban    +
+ 07-10-2014 09:31    +
+ 		+ + + + +
+ I am mostly fine with the resolution, but I slightly ammended the proposed rules:
+- null is allowed in non-equality too
+- applying index notation to null leads to an error
+
+Please check and if you are fine with my modifications, we can mark the CR as resolved.
+
+
+
+ + + + + + + + + + +
+ (0012295) +
+ Gyorgy Rethy    +
+ 08-10-2014 16:17    +
+ 		+ + + + +
+ Your comemnts (and additions) are correct.
+
+
+
+ + + + + + + + + + +
+ (0012624) +
+ Gyorgy Rethy    +
+ 05-01-2015 17:31    +
+ 		+ + + + +
+ Added to draft V4.6.3
+
+ + diff --git a/docs/mantis/CR6718.md b/docs/mantis/CR6718.md new file mode 100644 index 0000000000000000000000000000000000000000..5c4941fac917b7beec72f9c042361c34895e0b6b --- /dev/null +++ b/docs/mantis/CR6718.md @@ -0,0 +1,204 @@ + + + + + + + + + + + + + 0006718: Null value in the to and from clause - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006718Part 01: TTCN-3 Core LanguageTechnicalpublic09-04-2014 13:4405-01-2015 18:31
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.6.1 (published 2014-06) 
Target Versionv4.7.1 (published 2015-06)Fixed in Versionv4.7.1 (published 2015-06) 
Clause Reference(s)22
Source (company - Author)STF 478
Summary0006718: Null value in the to and from clause
DescriptionAddress values can contain a special value null (see 6.2.12 for more details). However, it is not obvious what would happen if this value is used in the communication operations. In my opinion there are two options:
+
+1. It will produce an error.
+2. It will work: in case of outgoing operation, no address will be passed to the SA (the corresponding field of the TRI operation will be null). It would be just a more verbous variant of outgoing operations without a to clause. In case of an incoming operation, using null in the from clause would mean that the event can be accepted only if the SA didn't supply any address. (This is different than omitting the from clause as the sender address is not matched in this case).
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR6718_resolution_v1.docx (94,500) 06-10-2014 16:38
http://oldforge.etsi.org/mantis/file_download.php?file_id=3085&type=bug
zip Operational-Semantics-CR6718.zip (1,618,357) 07-10-2014 14:07
http://oldforge.etsi.org/mantis/file_download.php?file_id=3096&type=bug
Issue History
Date ModifiedUsernameFieldChange
09-04-2014 13:44Tomas UrbanNew Issue
18-06-2014 08:38Gyorgy RethyProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
18-06-2014 08:38Gyorgy RethyProduct Version => v4.6.1 (published 2014-06)
18-06-2014 08:38Gyorgy RethyTarget Version => v4.7.1 (published 2015-06)
06-10-2014 16:06Gyorgy RethyNote Added: 0012236
06-10-2014 16:06Gyorgy RethyAssigned To => Gyorgy Rethy
06-10-2014 16:06Gyorgy RethyStatusnew => confirmed
06-10-2014 16:08Gyorgy RethyNote Edited: 0012236bug_revision_view_page.php?bugnote_id=12236#r70
06-10-2014 16:38Gyorgy RethyFile Added: CR6718_resolution_v1.docx
06-10-2014 16:38Gyorgy RethyNote Added: 0012238
06-10-2014 16:39Gyorgy RethyAssigned ToGyorgy Rethy => Jens Grabowski
07-10-2014 08:24Jens GrabowskiNote Added: 0012241
07-10-2014 08:24Jens GrabowskiStatusconfirmed => resolved
07-10-2014 08:24Jens GrabowskiResolutionopen => fixed
07-10-2014 08:24Jens GrabowskiAssigned ToJens Grabowski => Gyorgy Rethy
07-10-2014 08:24Jens GrabowskiStatusresolved => assigned
07-10-2014 08:25Jens GrabowskiStatusassigned => resolved
07-10-2014 14:07Jens GrabowskiFile Added: Operational-Semantics-CR6718.zip
07-10-2014 14:07Jens GrabowskiNote Added: 0012253
05-01-2015 18:31Gyorgy RethyNote Added: 0012629
05-01-2015 18:31Gyorgy RethyStatusresolved => closed
05-01-2015 18:31Gyorgy RethyFixed in Version => v4.7.1 (published 2015-06)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0012236) +
+ Gyorgy Rethy    +
+ 06-10-2014 16:06    +
(edited on: 06-10-2014 16:08)
+ 		+ + + + +
+ Shall cause an error. Jens to check if this is already included in Part-4 (if the receiver cannot be determined, it should cause an error).
+
+
+
+
+
+ + + + + + + + + + +
+ (0012238) +
+ Gyorgy Rethy    +
+ 06-10-2014 16:38    +
+ 		+ + + + +
+ Please check CR6718_resolution_v1.docx.
+
+
+
+ + + + + + + + + + +
+ (0012241) +
+ Jens Grabowski    +
+ 07-10-2014 08:24    +
+ 		+ + + + +
+ Resolution is fine with me. Will also be implemented in OS.
+
+
+
+ + + + + + + + + + +
+ (0012253) +
+ Jens Grabowski    +
+ 07-10-2014 14:07    +
+ 		+ + + + +
+ CR also implemented in operational semantics.
+
+
+
+ + + + + + + + + + +
+ (0012629) +
+ Gyorgy Rethy    +
+ 05-01-2015 18:31    +
+ 		+ + + + +
+ Added to draft V4.6.3
+
+ + diff --git a/docs/mantis/CR6719.md b/docs/mantis/CR6719.md new file mode 100644 index 0000000000000000000000000000000000000000..1ff15662a57d168c1b02a505ae4bc7c0b9d17dda --- /dev/null +++ b/docs/mantis/CR6719.md @@ -0,0 +1,239 @@ + + + + + + + + + + + + + 0006719: Mapping of nillable complex elements is not correct - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006719Part 09: Using XML with TTCN-3Technicalpublic09-04-2014 15:2231-12-2014 11:43
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.5.1 (published 2013-04) 
Target Versionv4.6.1 (published 2015-06)Fixed in Versionv4.6.1 (published 2015-06) 
Clause Reference(s)7.1.11
For STF discussion
Source (company - Author)L.M.Ericsson
Summary0006719: Mapping of nillable complex elements is not correct
DescriptionClause 7.1.11 specifies that the whole content of nillable complex elements shall be enframed by an additional "record{...} content optional" plus the useNil instruction construct. However, this is true for the contained elements only: if the complex type has also attributes, these still may be present in the encoded XML. Therefore, the extra record generated for the nillable attribute shall enframe the complex type's elements only and the complex type's attributes shall be outside of the record.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0006721closed Gyorgy Rethy Rules on the use of the ref attribute in element definitions 
Attached Filesdoc CR6719_nillable_Resolution_v1.doc (89,088) 09-04-2014 16:52
http://oldforge.etsi.org/mantis/file_download.php?file_id=2986&type=bug
doc CR6719_nillable_Resolution_v2.doc (90,112) 10-04-2014 09:10
http://oldforge.etsi.org/mantis/file_download.php?file_id=2989&type=bug
doc CR6719_nillable_resolution_v3.doc (92,672) 10-04-2014 15:32
http://oldforge.etsi.org/mantis/file_download.php?file_id=3007&type=bug
Issue History
Date ModifiedUsernameFieldChange
09-04-2014 15:22Gyorgy RethyNew Issue
09-04-2014 16:51Gyorgy RethyAssigned To => Gyorgy Rethy
09-04-2014 16:51Gyorgy RethyStatusnew => assigned
09-04-2014 16:51Gyorgy RethyProduct Version => v4.5.1 (published 2013-04)
09-04-2014 16:51Gyorgy RethyTarget Version => v4.6.1 (published 2015-06)
09-04-2014 16:52Gyorgy RethyFile Added: CR6719_nillable_Resolution_v1.doc
09-04-2014 16:53Gyorgy RethyNote Added: 0011978
09-04-2014 16:54Gyorgy RethyNote Deleted: 0011978
09-04-2014 16:54Gyorgy RethyNote Added: 0011979
09-04-2014 16:54Gyorgy RethyStatusassigned => confirmed
09-04-2014 16:58Gyorgy RethyAssigned ToGyorgy Rethy => Tomas Urban
09-04-2014 16:58Gyorgy RethyStatusconfirmed => assigned
09-04-2014 17:01Gyorgy RethyStatusassigned => confirmed
10-04-2014 09:07Tomas UrbanRelationship addedrelated to 0006721
10-04-2014 09:09Tomas UrbanNote Added: 0011983
10-04-2014 09:10Tomas UrbanFile Added: CR6719_nillable_Resolution_v2.doc
10-04-2014 09:10Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
10-04-2014 09:10Tomas UrbanStatusconfirmed => assigned
10-04-2014 10:02Jacob Wieland - SpirentNote Added: 0011985
10-04-2014 11:06Tomas UrbanStatusassigned => confirmed
10-04-2014 15:32Gyorgy RethyNote Added: 0012013
10-04-2014 15:32Gyorgy RethyFile Added: CR6719_nillable_resolution_v3.doc
10-04-2014 15:32Gyorgy RethyAssigned ToGyorgy Rethy => Tomas Urban
10-04-2014 15:32Gyorgy RethyStatusconfirmed => assigned
10-04-2014 15:32Gyorgy RethyStatusassigned => confirmed
11-04-2014 09:24Tomas UrbanNote Added: 0012017
11-04-2014 09:24Tomas UrbanStatusconfirmed => resolved
11-04-2014 09:24Tomas UrbanResolutionopen => fixed
11-04-2014 09:24Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
17-06-2014 16:20Gyorgy RethyFixed in Version => v4.6.1 (published 2015-06)
20-06-2014 11:54Gyorgy RethyFixed in Versionv4.6.1 (published 2015-06) =>
31-12-2014 11:43Gyorgy RethyNote Added: 0012595
31-12-2014 11:43Gyorgy RethyStatusresolved => closed
31-12-2014 11:43Gyorgy RethyFixed in Version => v4.6.1 (published 2015-06)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011979) +
+ Gyorgy Rethy    +
+ 09-04-2014 16:54    +
+ 		+ + + + +
+ Proposed resolution is in CR6719_nillable_Resolution_v1.doc. Please review.
+
+
+
+ + + + + + + + + + +
+ (0011983) +
+ Tomas Urban    +
+ 10-04-2014 09:09    +
+ 		+ + + + +
+ Fine by me. I only changed the code generated for the referenced nillable element and added the result of this element transformation (see the related issue for more information).
+Please check.
+
+
+
+ + + + + + + + + + +
+ (0011985) +
+ Jacob Wieland - Spirent    +
+ 10-04-2014 10:02    +
+ 		+ + + + +
+ Some more clarification/specification is needed in regard to the relationship between the content-field and the attribute fields, i.e. their order and nameclash-resolution (i.e. what happens if the mangling of attribute-names also yield "content" - which takes precedence?)
+
+
+
+ + + + + + + + + + +
+ (0012013) +
+ Gyorgy Rethy    +
+ 10-04-2014 15:32    +
+ 		+ + + + +
+ In example 2 "UseNil" has to be attached to the top-level record and not to its "content" field: corrected both in the text and in the example.
+
+Handling of possible name clashes has been added to the new paragraph of $7.1.11 and to the text of $B.3.15. Also, an explanatory note is added to B.3.15.
+
+See in CR6719_nillable_resolution_v3.doc.
+
+
+
+ + + + + + + + + + +
+ (0012017) +
+ Tomas Urban    +
+ 11-04-2014 09:24    +
+ 		+ + + + +
+ I have found no issues in the proposed resolution.
+The changes can be added to the next version of the standard.
+
+
+
+ + + + + + + + + + +
+ (0012595) +
+ Gyorgy Rethy    +
+ 31-12-2014 11:43    +
+ 		+ + + + +
+ Added to draft V4.5.3
+
+ + diff --git a/docs/mantis/CR6720.md b/docs/mantis/CR6720.md new file mode 100644 index 0000000000000000000000000000000000000000..5deee25b15fd0be47cfe21c8398ebd94b22c25fa --- /dev/null +++ b/docs/mantis/CR6720.md @@ -0,0 +1,72 @@ + + + + + + + + + + + + + 0006720: Typo on clause 7.3 - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006720Part 09: Using XML with TTCN-3Editorialpublic09-04-2014 15:5126-01-2015 11:27
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.5.1 (published 2013-04) 
Target Versionv4.6.1 (published 2015-06)Fixed in Versionv4.5.2 (interim 2014) 
Clause Reference(s)7.3
For STF discussion
Source (company - Author)L.M.Ericsson
Summary0006720: Typo on clause 7.3
DescriptionThe "v" of the "variant" attribute is missing:
+<element name="e16a" type="typename"/>
+
+// is translated to:
+type typename E16a
+with {
+    variant "element";
+    ariant "name as uncapitalized "
+}
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
09-04-2014 15:51Gyorgy RethyNew Issue
09-04-2014 15:52Gyorgy RethyAssigned To => Gyorgy Rethy
09-04-2014 15:52Gyorgy RethyStatusnew => assigned
09-04-2014 15:52Gyorgy RethyProduct Version => v4.5.1 (published 2013-04)
09-04-2014 15:52Gyorgy RethyTarget Version => v4.6.1 (published 2015-06)
09-04-2014 16:50Gyorgy RethyStatusassigned => resolved
09-04-2014 16:50Gyorgy RethyResolutionopen => fixed
09-04-2014 16:50Gyorgy RethyFixed in Version => v4.6.1 (published 2015-06)
09-04-2014 16:51Gyorgy RethyNote Added: 0011977
09-04-2014 16:51Gyorgy RethyStatusresolved => closed
24-06-2014 09:00Gyorgy RethyFixed in Versionv4.6.1 (published 2015-06) => v4.5.2 (interim 2014)
26-01-2015 11:21Gyorgy RethyFixed in Versionv4.5.2 (interim 2014) => v4.6.1 (published 2015-06)
26-01-2015 11:27Gyorgy RethyFixed in Versionv4.6.1 (published 2015-06) => v4.5.2 (interim 2014)
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0011977) +
+ Gyorgy Rethy    +
+ 09-04-2014 16:51    +
+ 		+ + + + +
+ Implemented in master document es_20187309v040502.doc
+
+ + diff --git a/docs/mantis/CR6721.md b/docs/mantis/CR6721.md new file mode 100644 index 0000000000000000000000000000000000000000..ecb73d49de91727eb0ffc50ec74b8151cd1aa032 --- /dev/null +++ b/docs/mantis/CR6721.md @@ -0,0 +1,139 @@ + + + + + + + + + + + + + 0006721: Rules on the use of the ref attribute in element definitions - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006721Part 09: Using XML with TTCN-3Clarificationpublic10-04-2014 08:5931-12-2014 11:48
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.5.2 (interim 2014) 
Target Versionv4.6.1 (published 2015-06)Fixed in Versionv4.6.1 (published 2015-06) 
Clause Reference(s)7.3
For STF discussion
Source (company - Author)STF 478
Summary0006721: Rules on the use of the ref attribute in element definitions
DescriptionThe rules on conversion of local elements defined by reference are somehow unclear. In the section 7.3, the description of the procedure used for generating the element type is described as follows: "the type of the field shall be the type resulted by mapping the type of the XSD element as specified for global elements".
+
+However, it is not clear whether in case of referenced elements, the type generated for the referenced global element shall be used (which seem to be the case in examples) or this procedure should be repeated for the local element generating copy of the global type locally.
+
+As I don't see any obstacles for using the type reference instead of the copy, I propose the following change of the above mentioned rules:
+
+...the type of the field shall be the type into which a referenced global element is mapped or the type resulted by mapping the type of the locally defined XSD element using the procedure specified for global elements...
+
+No examples have to be changed as they already follow these rules.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0006719closed Gyorgy Rethy Mapping of nillable complex elements is not correct 
Attached Filesdoc CR6721_resolution_v1.doc (90,624) 12-12-2014 14:41
http://oldforge.etsi.org/mantis/file_download.php?file_id=3197&type=bug
Issue History
Date ModifiedUsernameFieldChange
10-04-2014 08:59Tomas UrbanNew Issue
10-04-2014 08:59Tomas UrbanStatusnew => assigned
10-04-2014 08:59Tomas UrbanAssigned To => Gyorgy Rethy
10-04-2014 09:07Tomas UrbanRelationship addedrelated to 0006719
12-12-2014 14:41Gyorgy RethyFile Added: CR6721_resolution_v1.doc
12-12-2014 14:46Gyorgy RethyNote Added: 0012546
12-12-2014 14:46Gyorgy RethyAssigned ToGyorgy Rethy => Tomas Urban
12-12-2014 14:46Gyorgy RethyStatusassigned => confirmed
12-12-2014 14:46Gyorgy RethyProduct Version => v4.5.2 (interim 2014)
15-12-2014 09:16Tomas UrbanNote Added: 0012548
15-12-2014 09:16Tomas UrbanStatusconfirmed => resolved
15-12-2014 09:16Tomas UrbanResolutionopen => fixed
15-12-2014 09:16Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
31-12-2014 11:48Gyorgy RethyNote Added: 0012596
31-12-2014 11:48Gyorgy RethyStatusresolved => closed
31-12-2014 11:48Gyorgy RethyFixed in Version => v4.6.1 (published 2015-06)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0012546) +
+ Gyorgy Rethy    +
+ 12-12-2014 14:46    +
+ 		+ + + + +
+ I propose even a more categorical correction of the text; see and review CR6721_resolution_v1.doc
+
+
+
+ + + + + + + + + + +
+ (0012548) +
+ Tomas Urban    +
+ 15-12-2014 09:16    +
+ 		+ + + + +
+ The proposed resolution solves the CR and can be added to the next version of the TTCN-3 specification.
+
+
+
+ + + + + + + + + + +
+ (0012596) +
+ Gyorgy Rethy    +
+ 31-12-2014 11:48    +
+ 		+ + + + +
+ Added to draft V4.5.3
+
+ + diff --git a/docs/mantis/CR6722.md b/docs/mantis/CR6722.md new file mode 100644 index 0000000000000000000000000000000000000000..71154240c9385efac13752d84d5b7d8e84c2487c --- /dev/null +++ b/docs/mantis/CR6722.md @@ -0,0 +1,377 @@ + + + + + + + + + + + + + 0006722: Visibility is not taken into account in component compatibility - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006722Part 01: TTCN-3 Core LanguageTechnicalpublic10-04-2014 11:5205-01-2015 16:13
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.6.1 (published 2014-06) 
Target Versionv4.7.1 (published 2015-06)Fixed in Versionv4.7.1 (published 2015-06) 
Clause Reference(s)6.3.3
Source (company - Author)L.M.Ericsson
Summary0006722: Visibility is not taken into account in component compatibility
DescriptionCurrently the visibility (private/friend/public) of component definitions are not handled (not mentioned) in component compatibility rules. The rules has to be extended with visibility.
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx draft-res-6722.docx (16,667) 07-10-2014 10:19
http://oldforge.etsi.org/mantis/file_download.php?file_id=3092&type=bug
Issue History
Date ModifiedUsernameFieldChange
10-04-2014 11:52Gyorgy RethyNew Issue
15-04-2014 13:55Jacob Wieland - SpirentNote Added: 0012038
18-06-2014 08:40Gyorgy RethyTarget Version => v4.7.1 (published 2015-06)
18-06-2014 08:40Gyorgy RethyDescription Updatedbug_revision_view_page.php?rev_id=31#r31
06-10-2014 16:11Gyorgy RethyNote Added: 0012237
06-10-2014 16:11Gyorgy RethyAssigned To => Axel Rennoch
06-10-2014 16:11Gyorgy RethyStatusnew => assigned
07-10-2014 10:19Axel RennochFile Added: draft-res-6722.docx
07-10-2014 10:19Axel RennochNote Added: 0012248
07-10-2014 10:20Axel RennochAssigned ToAxel Rennoch => Gyorgy Rethy
07-10-2014 10:20Axel RennochStatusassigned => confirmed
08-10-2014 09:30Gyorgy RethyAssigned ToGyorgy Rethy => Jens Grabowski
08-10-2014 14:23Jens GrabowskiStatusconfirmed => resolved
08-10-2014 14:23Jens GrabowskiResolutionopen => fixed
08-10-2014 14:23Jens GrabowskiAssigned ToJens Grabowski => Gyorgy Rethy
08-10-2014 16:34Jacob Wieland - SpirentNote Added: 0012301
08-10-2014 16:34Jacob Wieland - SpirentStatusresolved => feedback
08-10-2014 16:34Jacob Wieland - SpirentResolutionfixed => reopened
09-10-2014 10:22Gyorgy RethyNote Added: 0012311
09-10-2014 10:22Gyorgy RethyStatusfeedback => assigned
10-10-2014 10:28Axel RennochNote Added: 0012346
10-10-2014 10:30Axel RennochNote Added: 0012347
10-10-2014 10:30Axel RennochStatusassigned => confirmed
03-11-2014 16:51Gyorgy RethyAssigned ToGyorgy Rethy => Jens Grabowski
04-11-2014 12:40Jens GrabowskiNote Added: 0012395
04-11-2014 12:41Jens GrabowskiStatusconfirmed => resolved
04-11-2014 12:41Jens GrabowskiResolutionreopened => fixed
04-11-2014 12:41Jens GrabowskiAssigned ToJens Grabowski => Gyorgy Rethy
05-01-2015 16:13Gyorgy RethyNote Added: 0012619
05-01-2015 16:13Gyorgy RethyStatusresolved => closed
05-01-2015 16:13Gyorgy RethyFixed in Version => v4.7.1 (published 2015-06)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0012038) +
+ Jacob Wieland - Spirent    +
+ 15-04-2014 13:55    +
+ 		+ + + + +
+ Could you elaborate on what the problem is? Visibility normally is only interesting on the context-checking level. How does that influence component compatibility rules?
+
+
+
+ + + + + + + + + + +
+ (0012237) +
+ Gyorgy Rethy    +
+ 06-10-2014 16:11    +
+ 		+ + + + +
+ Take the straighforward approach: visibility has to be the same in the parent and in the child.
+
+
+
+ + + + + + + + + + +
+ (0012248) +
+ Axel Rennoch    +
+ 07-10-2014 10:19    +
+ 		+ + + + +
+ additional rule added to consider visibility for compatibility
+
+
+
+ + + + + + + + + + +
+ (0012301) +
+ Jacob Wieland - Spirent    +
+ 08-10-2014 16:34    +
+ 		+ + + + +
+ Sorry, can you please explain what visibility has to do with compatibility. Visibility normally only affects which names I can reference/use. So,if a name is not visible from my point of reference, I cannot use it. What has that to do with component type compatibility.
+
+If a function is defined on a component type which is not visible to me but I know a compatible component type - why should I not be allowed to run the function on that component type?
+
+
+
+ + + + + + + + + + +
+ (0012311) +
+ Gyorgy Rethy    +
+ 09-10-2014 10:22    +
+ 		+ + + + +
+ STF discussion: componenet type need not be visible at places where a function with a compatible component type in its run on clause is called. Check this and make explicit if not defined yet is clause 8.2.3.1.
+
+
+
+ + + + + + + + + + +
+ (0012346) +
+ Axel Rennoch    +
+ 10-10-2014 10:28    +
+ 		+ + + + +
+ In 8.2.3.1 restriction d) appears to be sufficient. In addition we have example 5 which addresses such component extension.
+
+From this view there is no need for any more change and the CR may be closed.
+
+
+
+ + + + + + + + + + +
+ (0012347) +
+ Axel Rennoch    +
+ 10-10-2014 10:30    +
+ 		+ + + + +
+ CR do not need any changes and can be closed.
+
+
+
+ + + + + + + + + + +
+ (0012395) +
+ Jens Grabowski    +
+ 04-11-2014 12:40    +
+ 		+ + + + +
+ 8.2.3.1 restriction d)
+"A definition is imported together with all information of referenced definitions that are necessary for the usage of the imported definition, independent of the visibility of the referenced definitions (see clause 8.2.5)."
+
+And example 5:
+
+EXAMPLE 5: Importing local definitions transitively
+    module A {
+      type enumerated MyEnum_Type { enumX, enumY, enumZ}
+      type record MyRec { integer a, integer b }
+      type component MyComp { var MyRec v_Rec := { a := 5 } }
+    }
+
+    module B {
+      import from A all;
+      modulepar MyEnum_Type px_MyModulePar := enumY;
+      type component MyCompUser extends MyComp {}
+    }
+
+    module C {
+      import from B all;
+      testcase TC() runs on MyCompUser {
+        if (px_MyModulePar == enumY) {
+          // the enumerated value enumY is know in C without explicitly
+              // importing it from A
+          setverdict(pass)
+        }
+        if (v_Rec.a == 5) {
+          v_Rec.b := v_Rec.a;
+          // Both the variable name v_Rec and the record field names are
+              //known in C without
+          // explicitly importing them from A
+          setverdict (pass)
+        }
+      }
+    }
+
+
+should do the job. Thus, no changes need to be implemented in the standard.
+
+
+
+ + + + + + + + + + +
+ (0012619) +
+ Gyorgy Rethy    +
+ 05-01-2015 16:13    +
+ 		+ + + + +
+ No change is needed in the stanadrd.
+
+ + diff --git a/docs/mantis/CR6723.md b/docs/mantis/CR6723.md new file mode 100644 index 0000000000000000000000000000000000000000..ef82a0401ae264a1400d50ea13922cce5ae85d66 --- /dev/null +++ b/docs/mantis/CR6723.md @@ -0,0 +1,29 @@ + + + + + + + + + + + + + 0006723: R of regexp shall be lowercase - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006723Part 01: TTCN-3 Core LanguageEditorialpublic10-04-2014 16:1120-06-2014 11:46
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeveritytrivialReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.6.1 (published 2014-06) 
Target Versionv4.7.1 (published 2015-06)Fixed in Versionv4.6.2 (interim 2014) 
Clause Reference(s)C.4.1
Source (company - Author)L.M.Ericsson
Summary0006723: R of regexp shall be lowercase
Descriptionin the syntactical description Regexp -> regexp
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
10-04-2014 16:11Gyorgy RethyNew Issue
18-06-2014 08:42Gyorgy RethySeverityminor => trivial
18-06-2014 08:42Gyorgy RethyStatusnew => resolved
18-06-2014 08:42Gyorgy RethyResolutionopen => fixed
18-06-2014 08:42Gyorgy RethyProduct Version => v4.6.1 (published 2014-06)
18-06-2014 08:42Gyorgy RethyFixed in Version => v4.6.2 (interim 2014)
18-06-2014 08:42Gyorgy RethyTarget Version => v4.6.2 (interim 2014)
19-06-2014 17:05Gyorgy RethyStatusresolved => closed
19-06-2014 17:05Gyorgy RethyAssigned To => Gyorgy Rethy
20-06-2014 11:46Gyorgy RethyTarget Versionv4.6.2 (interim 2014) => v4.7.1 (published 2015-06)
+
+ + + + +
+ There are no notes attached to this issue.
+ + diff --git a/docs/mantis/CR6724.md b/docs/mantis/CR6724.md new file mode 100644 index 0000000000000000000000000000000000000000..0f4fc9bdd42d07e7290f27e17130752fac9b1374 --- /dev/null +++ b/docs/mantis/CR6724.md @@ -0,0 +1,63 @@ + + + + + + + + + + + + + 0006724: Strange name of hostId - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006724Part 01: TTCN-3 Core LanguageEditorialpublic10-04-2014 16:1519-06-2014 17:28
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.6.1 (published 2014-06) 
Target Versionv4.7.1 (published 2015-06)Fixed in Versionv4.6.2 (interim 2014) 
Clause Reference(s)C.6.3
Source (company - Author)L.M.Ericsson
Summary0006724: Strange name of hostId
Descriptionyoolea shall be hostId (7 times)
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
10-04-2014 16:15Gyorgy RethyNew Issue
10-04-2014 16:18Gyorgy RethyProduct Version => v4.6.1 (published 2014-06)
10-04-2014 16:18Gyorgy RethyTarget Version => v4.7.1 (published 2015-06)
19-06-2014 17:28Gyorgy RethyNote Added: 0012164
19-06-2014 17:28Gyorgy RethyStatusnew => closed
19-06-2014 17:28Gyorgy RethyAssigned To => Gyorgy Rethy
19-06-2014 17:28Gyorgy RethyResolutionopen => fixed
19-06-2014 17:28Gyorgy RethyFixed in Version => v4.6.2 (interim 2014)
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0012164) +
+ Gyorgy Rethy    +
+ 19-06-2014 17:28    +
+ 		+ + + + +
+ Fixed in master copy
+
+ + diff --git a/docs/mantis/CR6725.md b/docs/mantis/CR6725.md new file mode 100644 index 0000000000000000000000000000000000000000..a442072aba399542e95b32d12607ef9af35cfb92 --- /dev/null +++ b/docs/mantis/CR6725.md @@ -0,0 +1,63 @@ + + + + + + + + + + + + + 0006725: Strange character sequence for "preprocessor" - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006725Part 01: TTCN-3 Core LanguageEditorialpublic10-04-2014 16:1819-06-2014 17:21
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.6.1 (published 2014-06) 
Target Versionv4.7.1 (published 2015-06)Fixed in Versionv4.6.2 (interim 2014) 
Clause Reference(s)Annex D
Source (company - Author)L.M.Ericsson
Summary0006725: Strange character sequence for "preprocessor"
Description"yooleany essor" shall be "preprocessor" (6 times)
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
duplicate of 0006784closed Gyorgy Rethy Replace "yooleany essor" with "preprocessor" 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
10-04-2014 16:18Gyorgy RethyNew Issue
10-04-2014 16:19Gyorgy RethyTarget Version => v4.7.1 (published 2015-06)
03-06-2014 15:47Jacob Wieland - SpirentRelationship addedrelated to 0006766
03-06-2014 15:47Jacob Wieland - SpirentRelationship deletedrelated to 0006766
19-06-2014 17:21Gyorgy RethyRelationship addedduplicate of 0006784
19-06-2014 17:21Gyorgy RethyNote Added: 0012163
19-06-2014 17:21Gyorgy RethyStatusnew => closed
19-06-2014 17:21Gyorgy RethyAssigned To => Gyorgy Rethy
19-06-2014 17:21Gyorgy RethyResolutionopen => fixed
19-06-2014 17:21Gyorgy RethyFixed in Version => v4.6.2 (interim 2014)
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0012163) +
+ Gyorgy Rethy    +
+ 19-06-2014 17:21    +
+ 		+ + + + +
+ Fixed
+
+ + diff --git a/docs/mantis/CR6726.md b/docs/mantis/CR6726.md new file mode 100644 index 0000000000000000000000000000000000000000..f7a99247132d94d61c13b4396c0c5b989bd92aef --- /dev/null +++ b/docs/mantis/CR6726.md @@ -0,0 +1,63 @@ + + + + + + + + + + + + + 0006726: yoolean should be boolean - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006726Part 01: TTCN-3 Core LanguageEditorialpublic10-04-2014 16:2419-06-2014 17:19
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.6.1 (published 2014-06) 
Target Versionv4.7.1 (published 2015-06)Fixed in Versionv4.6.2 (interim 2014) 
Clause Reference(s)Annex F, clause G.1
Source (company - Author)L.M.Ericsson
Summary0006726: yoolean should be boolean
Description"yoolean" shall be "Boolean" (2 times)
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
10-04-2014 16:24Gyorgy RethyNew Issue
19-06-2014 17:19Gyorgy RethyNote Added: 0012162
19-06-2014 17:19Gyorgy RethyStatusnew => closed
19-06-2014 17:19Gyorgy RethyAssigned To => Gyorgy Rethy
19-06-2014 17:19Gyorgy RethyResolutionopen => fixed
19-06-2014 17:19Gyorgy RethyFixed in Version => v4.6.2 (interim 2014)
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0012162) +
+ Gyorgy Rethy    +
+ 19-06-2014 17:19    +
+ 		+ + + + +
+ Fixed in master copy
+
+ + diff --git a/docs/mantis/CR6727.md b/docs/mantis/CR6727.md new file mode 100644 index 0000000000000000000000000000000000000000..eccf3c4ad4a727a15ff23a776db47114acc025b0 --- /dev/null +++ b/docs/mantis/CR6727.md @@ -0,0 +1,259 @@ + + + + + + + + + + + + + 0006727: Alternative reference of unicode characters - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006727Part 01: TTCN-3 Core LanguageNew Featurepublic11-04-2014 10:2806-01-2015 18:20
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.6.1 (published 2014-06) 
Target Versionv4.7.1 (published 2015-06)Fixed in Versionv4.7.1 (published 2015-06) 
Clause Reference(s)6.1.1, B.1.5, but all uses of quadruple shall be checked
Source (company - Author)L.M.Ericsson
Summary0006727: Alternative reference of unicode characters
DescriptionTTCN-3 today provides only the quadruple syntax to refer to non-ISO646 universal characters. ISO 10646:212 uses other ways of identifying character codes, therefore it become quite difficult for the user to calculate the quadruple from the character code and vice versa. More ISO 10646-conformant syntax(es) should be added to TTCN-3 to make the life of testers easier.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR6727_v1.docx (60,213) 19-06-2014 16:23
http://oldforge.etsi.org/mantis/file_download.php?file_id=3060&type=bug
docx CR6727_v2.docx (69,313) 30-06-2014 11:02
http://oldforge.etsi.org/mantis/file_download.php?file_id=3076&type=bug
docx CR6727_v3.docx (71,720) 07-10-2014 09:05
http://oldforge.etsi.org/mantis/file_download.php?file_id=3088&type=bug
Issue History
Date ModifiedUsernameFieldChange
11-04-2014 10:28Gyorgy RethyNew Issue
17-06-2014 10:59Gyorgy RethyAssigned To => Axel Rennoch
17-06-2014 10:59Gyorgy RethyStatusnew => assigned
19-06-2014 11:15Axel RennochNote Added: 0012139
19-06-2014 11:18Axel RennochAssigned ToAxel Rennoch => Gyorgy Rethy
19-06-2014 11:19Axel RennochNote Added: 0012140
19-06-2014 11:19Axel RennochStatusassigned => confirmed
19-06-2014 16:23Tomas UrbanFile Added: CR6727_v1.docx
19-06-2014 16:24Tomas UrbanNote Added: 0012155
30-06-2014 11:02Gyorgy RethyFile Added: CR6727_v2.docx
30-06-2014 11:09Gyorgy RethyNote Added: 0012197
30-06-2014 11:09Gyorgy RethyAssigned ToGyorgy Rethy => Axel Rennoch
30-06-2014 11:09Gyorgy RethyStatusconfirmed => assigned
30-06-2014 11:09Gyorgy RethyStatusassigned => confirmed
30-06-2014 11:10Gyorgy RethyNote Edited: 0012197bug_revision_view_page.php?bugnote_id=12197#r65
07-10-2014 09:05Axel RennochFile Added: CR6727_v3.docx
07-10-2014 09:06Axel RennochNote Added: 0012244
07-10-2014 09:06Axel RennochAssigned ToAxel Rennoch => Gyorgy Rethy
07-10-2014 09:06Axel RennochStatusconfirmed => assigned
07-10-2014 09:07Axel RennochStatusassigned => resolved
07-10-2014 09:07Axel RennochResolutionopen => fixed
06-01-2015 18:20Gyorgy RethyNote Added: 0012648
06-01-2015 18:20Gyorgy RethyStatusresolved => closed
06-01-2015 18:20Gyorgy RethyFixed in Version => v4.7.1 (published 2015-06)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0012139) +
+ Axel Rennoch    +
+ 19-06-2014 11:15    +
+ 		+ + + + +
+ Following ISO10646:2012 section 6.2 characters can be represented by a (six digit) integer between 000000 and 10FFFF to identify its code point. For BMF plane leading '00' and for other defined planes leading '0' may be omitted.
+
+The following notation has been proposed for "short identifiers for code points" (UIDs):
+
+   { U | u } {+}(xxxx | xxxxx | xxxxxx)
+   where “x” represents one hexadecimal digit (0 to 9, A to F, or a to f).
+
+In addition section 6.6 proposes a syntax for sequences of code points by the following BNF:
+
+   “<” (xxxx | xxxxx | xxxxxx) ((“,” space?) (xxxx | xxxxx | xxxxxx))+ “>”
+   where “x” represents one hexadecimal digit (0 to 9, A to F, or a to f).
+
+It is proposed to adapt this syntax in TTCN-3 to address code points, e.g.:
+
+   char(U0054 U0054 U0043 U004E)
+   char(U000054 U000054 U000043 U00004E)
+   char(U000054, U000054, U000043, U00004E)
+
+
+
+ + + + + + + + + + +
+ (0012140) +
+ Axel Rennoch    +
+ 19-06-2014 11:19    +
+ 		+ + + + +
+ first proposal to express UCS characters
+
+
+
+ + + + + + + + + + +
+ (0012155) +
+ Tomas Urban    +
+ 19-06-2014 16:24    +
+ 		+ + + + +
+ Formal proposal uploaded, please check.
+
+
+
+ + + + + + + + + + +
+ (0012197) +
+ Gyorgy Rethy    +
+ 30-06-2014 11:09    +
(edited on: 30-06-2014 11:10)
+ 		+ + + + +
+ See version CR6727_v2.docx.
+
+In general: technically fine with me. Some small comments:
+- added changes to pattern matching (in quadruple metacharacter both formats allowed);
+- actually, we are deviating so much from UID that I found it better not to call our new format USI and UID.
+
+
+
+
+
+ + + + + + + + + + +
+ (0012244) +
+ Axel Rennoch    +
+ 07-10-2014 09:06    +
+ 		+ + + + +
+ final check:
+- addition of two abbreviations
+- one typo correction
+
+upload of final version v3
+
+
+
+ + + + + + + + + + +
+ (0012648) +
+ Gyorgy Rethy    +
+ 06-01-2015 18:20    +
+ 		+ + + + +
+ Added to draft V4.6.3
+
+ + diff --git a/docs/mantis/CR6728.md b/docs/mantis/CR6728.md new file mode 100644 index 0000000000000000000000000000000000000000..976f936cec483c95f81c5ed0317b9029c782142e --- /dev/null +++ b/docs/mantis/CR6728.md @@ -0,0 +1,283 @@ + + + + + + + + + + + + + 0006728: Rules for direct references inside patterns - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006728Part 01: TTCN-3 Core LanguageTechnicalpublic11-04-2014 11:1304-01-2015 20:40
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritylowSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.6.1 (published 2014-06) 
Target Versionv4.7.1 (published 2015-06)Fixed in Versionv4.7.1 (published 2015-06) 
Clause Reference(s)B.1.5
Source (company - Author)STF 478
Summary0006728: Rules for direct references inside patterns
DescriptionI addition to "{ref}" notation, the BNF allows to use references directly in patterns as in the following example:
+
+var charstring v_char := "[abc]";
+var template charstring v_pattern := pattern v_char;
+
+However, there don't seem to be any formal rules for these references. The specification only says (in the section B.1.5) that: "Character patterns may be composed from several fragments using the concatenation operation. The fragments of the pattern shall be concatenated before any evaluation of the pattern expression." It should be explained what is the allowed content of these references (type, if values only are allowed or values and templates, and in case of templates, what matching symbols).
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR6728_v1.docx (52,964) 03-11-2014 12:45
http://oldforge.etsi.org/mantis/file_download.php?file_id=3149&type=bug
docx CR6728_v2.docx (43,608) 05-11-2014 11:40
http://oldforge.etsi.org/mantis/file_download.php?file_id=3166&type=bug
Issue History
Date ModifiedUsernameFieldChange
11-04-2014 11:13Tomas UrbanNew Issue
15-04-2014 09:24Jacob Wieland - SpirentNote Added: 0012037
07-10-2014 09:09Gyorgy RethyPrioritynormal => low
10-10-2014 07:29Tomas UrbanAssigned To => Tomas Urban
10-10-2014 07:29Tomas UrbanStatusnew => assigned
03-11-2014 11:27Tomas UrbanFile Added: CR6728_v1.docx
03-11-2014 12:42Tomas UrbanNote Added: 0012373
03-11-2014 12:42Tomas UrbanAssigned ToTomas Urban => Jens Grabowski
03-11-2014 12:42Tomas UrbanStatusassigned => confirmed
03-11-2014 12:45Tomas UrbanFile Deleted: CR6728_v1.docx
03-11-2014 12:45Tomas UrbanFile Added: CR6728_v1.docx
03-11-2014 13:00Jacob Wieland - SpirentNote Added: 0012375
05-11-2014 11:39Jens GrabowskiNote Added: 0012421
05-11-2014 11:39Jens GrabowskiNote Added: 0012422
05-11-2014 11:40Jens GrabowskiFile Added: CR6728_v2.docx
05-11-2014 11:40Jens GrabowskiAssigned ToJens Grabowski => Tomas Urban
05-11-2014 11:40Jens GrabowskiStatusconfirmed => assigned
05-11-2014 16:08Tomas UrbanNote Added: 0012437
05-11-2014 16:08Tomas UrbanStatusassigned => resolved
05-11-2014 16:08Tomas UrbanFixed in Version => v4.7.1 (published 2015-06)
05-11-2014 16:08Tomas UrbanResolutionopen => fixed
05-11-2014 16:08Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
04-01-2015 20:40Gyorgy RethyNote Added: 0012613
04-01-2015 20:40Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0012037) +
+ Jacob Wieland - Spirent    +
+ 15-04-2014 09:24    +
+ 		+ + + + +
+ I think it should only be (uni) charstring values and (uni) charstring patterns that can be referenced.
+
+
+
+ + + + + + + + + + +
+ (0012373) +
+ Tomas Urban    +
+ 03-11-2014 12:42    +
+ 		+ + + + +
+ Proposal uploaded. Please review.
+
+
+
+ + + + + + + + + + +
+ (0012375) +
+ Jacob Wieland - Spirent    +
+ 03-11-2014 13:00    +
+ 		+ + + + +
+ Editorial for the beginning of the new paragraph:
+It should be either "Pattern definitions" or "A pattern definition".
+
+Also, I don't get the meaning/purpose of the sentence
+
+"When the referenced template contains a pattern, only the string content of the referenced pattern is used as a fragment for creating the new pattern."
+
+
+
+ + + + + + + + + + +
+ (0012421) +
+ Jens Grabowski    +
+ 05-11-2014 11:39    +
+ 		+ + + + +
+ Sentence changed to:
+"When the referenced template contains a pattern, the character pattern definition of this pattern is used as a fragment for creating the new pattern."
+
+The term "character pattern" is taken from Clause 6.1.2.5
+
+An alternative phrasing of the sentence may be:
+"When the referenced template contains a pattern, the character pattern definition of this pattern is considered when creating the new pattern."
+
+
+
+ + + + + + + + + + +
+ (0012422) +
+ Jens Grabowski    +
+ 05-11-2014 11:39    +
+ 		+ + + + +
+ Tomas, please made the final check.
+
+
+
+ + + + + + + + + + +
+ (0012437) +
+ Tomas Urban    +
+ 05-11-2014 16:08    +
+ 		+ + + + +
+ Final check completed. No modifications are necessary and the proposed change is ready to be added to the next version of the TTCN-3 core language specification.
+
+
+
+ + + + + + + + + + +
+ (0012613) +
+ Gyorgy Rethy    +
+ 04-01-2015 20:40    +
+ 		+ + + + +
+ Added to draft V4.6.3
+
+ + diff --git a/docs/mantis/CR6729.md b/docs/mantis/CR6729.md new file mode 100644 index 0000000000000000000000000000000000000000..160fe071e51c9a2013f511b8f887ae3978b63baa --- /dev/null +++ b/docs/mantis/CR6729.md @@ -0,0 +1,169 @@ + + + + + + + + + + + + + 0006729: Rules for concatenation of charstring templates - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006729Part 01: TTCN-3 Core LanguageTechnicalpublic11-04-2014 11:2205-01-2015 17:15
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.6.1 (published 2014-06) 
Target Versionv4.7.1 (published 2015-06)Fixed in Versionv4.7.1 (published 2015-06) 
Clause Reference(s)15.11
Source (company - Author)STF 478
Summary0006729: Rules for concatenation of charstring templates
DescriptionThe clause 15.11 allows to concatenate templates of charstring and universal charstring types, but doesn't set any restrictions on the content of the templates. There are some guidelines in the examples, but the current rules leave too much space for different interpretations.
+
+It should be decided whether it is feasible to keep the restrictive approach showed in the examples, i.e. the template operands shall resolve to charstring values only, or allow patterns too, or allow other matching symbols as well. If matching symbols are allowed, it is necessary to specify that the result is always a pattern in these cases and define transformation rules, e.g. "abc" & ? length(1..10) -> pattern "abc?#(1,10)"
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR6729_v1.docx (50,586) 08-10-2014 10:12
http://oldforge.etsi.org/mantis/file_download.php?file_id=3106&type=bug
Issue History
Date ModifiedUsernameFieldChange
11-04-2014 11:22Tomas UrbanNew Issue
15-04-2014 09:22Jacob Wieland - SpirentNote Added: 0012036
15-04-2014 09:24Tomas UrbanDescription Updatedbug_revision_view_page.php?rev_id=16#r16
07-10-2014 11:24Tomas UrbanDescription Updatedbug_revision_view_page.php?rev_id=71#r71
07-10-2014 14:51Tomas UrbanAssigned To => Tomas Urban
07-10-2014 14:51Tomas UrbanStatusnew => assigned
08-10-2014 10:12Tomas UrbanFile Added: CR6729_v1.docx
08-10-2014 10:13Tomas UrbanNote Added: 0012270
08-10-2014 10:13Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
08-10-2014 10:13Tomas UrbanStatusassigned => confirmed
08-10-2014 16:02Jacob Wieland - SpirentNote Added: 0012291
09-10-2014 08:58Gyorgy RethyStatusconfirmed => resolved
09-10-2014 08:58Gyorgy RethyResolutionopen => fixed
09-10-2014 08:58Gyorgy RethyFixed in Version => v4.7.1 (published 2015-06)
05-01-2015 17:15Gyorgy RethyNote Added: 0012621
05-01-2015 17:15Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0012036) +
+ Jacob Wieland - Spirent    +
+ 15-04-2014 09:22    +
+ 		+ + + + +
+ I think it should be values-only concatenation.
+
+That is not too restrictive, as pattern-concatenation can be done via concatenation inside the pattern language via the reference construct.
+
+
+
+ + + + + + + + + + +
+ (0012270) +
+ Tomas Urban    +
+ 08-10-2014 10:13    +
+ 		+ + + + +
+ Proposal uploaded. Please check.
+
+
+
+ + + + + + + + + + +
+ (0012291) +
+ Jacob Wieland - Spirent    +
+ 08-10-2014 16:02    +
+ 		+ + + + +
+ Looks fine.
+
+
+
+ + + + + + + + + + +
+ (0012621) +
+ Gyorgy Rethy    +
+ 05-01-2015 17:15    +
+ 		+ + + + +
+ Added to draft V4.6.3
+
+ + diff --git a/docs/mantis/CR6731.md b/docs/mantis/CR6731.md new file mode 100644 index 0000000000000000000000000000000000000000..e9397300a1599ef7cc62025be52e39cd299f16ce --- /dev/null +++ b/docs/mantis/CR6731.md @@ -0,0 +1,1249 @@ + + + + + + + + + + + + + 0006731: Passing parameters by reference - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006731Part 01: TTCN-3 Core LanguageTechnicalpublic14-04-2014 11:3404-01-2015 20:37
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.6.1 (published 2014-06) 
Target Versionv4.7.1 (published 2015-06)Fixed in Versionv4.7.1 (published 2015-06) 
Clause Reference(s)5.4
Source (company - Author)Elvior
Summary0006731: Passing parameters by reference
DescriptionIt doesn't seem to be completely obvious, if inout parameters are passed by reference or if an assignment to a parameter is made when entering a parameterized context and another from the parameter when exiting the parameterized context.
+
+Let's demonstrate the issue on the simple example:
+type component C {
+  var integer vc_int := 0;
+}
+
+function f(inout intenger p_int) runs on C {
+  vc_int := 10;
+  log(p_int); // will it print 0 o 10?
+}
+
+testcase TC() runs on C {
+  f();
+}
+
+The definition in 3.1 seems to point in the direction of passing by reference: inout parameterization: kind of parameterization where the actual parameter is bound to the formal parameter when the parameterized object is invoked. However, there are other rules that seem to favour the other approach, e.g. the recently added restriction 5.4.2.j. This restriction wouldn't make much sense when passing by reference as it would simply pass the pointer to the original variable and the language contains means for checking if the value is defined (the isbound function). However, assignment of uninitialized values is forbidden, so the rule is perfectly justified for the two-way assignment interpretation.
+
+I think it would be worth of considering to describe the mechanisms connected with inout assignments more exactly. Special attention should be paid to the situations when the inout parameters can be passed to external entities (and memory sharing typical for passing by reference is difficult to achieve) such as calling external functions, parameterized mapping etc. and sharing with testing code running in parallel (component.start call).
+
+In case the decision is made in favour of passign by reference, it would be necessary to formalize rules for type compatibility and template/value compatibility. That's because when passing by reference, no value assignment actually takes place.
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0006813closed Gyorgy Rethy Passing fields or elements of a component variable as inout parameter 
Attached Filesdoc CR6731_resolution_v1.doc (94,720) 18-06-2014 12:20
http://oldforge.etsi.org/mantis/file_download.php?file_id=3047&type=bug
doc CR6731_resolution_v2.doc (98,816) 08-10-2014 11:32
http://oldforge.etsi.org/mantis/file_download.php?file_id=3111&type=bug
doc CR6731_resolution_v3.doc (166,400) 08-10-2014 13:50
http://oldforge.etsi.org/mantis/file_download.php?file_id=3114&type=bug
doc CR6731_resolution_v4.doc (166,400) 08-10-2014 16:40
http://oldforge.etsi.org/mantis/file_download.php?file_id=3122&type=bug
doc CR6731_resolution_v5.doc (175,616) 09-10-2014 09:27
http://oldforge.etsi.org/mantis/file_download.php?file_id=3124&type=bug
doc CR6731_resolution_v6.doc (175,616) 09-10-2014 11:05
http://oldforge.etsi.org/mantis/file_download.php?file_id=3125&type=bug
doc CR6731_resolution_v7.doc (179,200) 09-10-2014 15:43
http://oldforge.etsi.org/mantis/file_download.php?file_id=3131&type=bug
doc CR6731_resolution_v8.doc (179,200) 04-11-2014 09:26
http://oldforge.etsi.org/mantis/file_download.php?file_id=3152&type=bug
doc CR6731_resolution_v9.doc (180,736) 04-11-2014 11:22
http://oldforge.etsi.org/mantis/file_download.php?file_id=3155&type=bug
Issue History
Date ModifiedUsernameFieldChange
14-04-2014 11:34Tomas UrbanNew Issue
15-04-2014 09:19Jacob Wieland - SpirentNote Added: 0012035
18-06-2014 09:04Gyorgy RethyNote Added: 0012118
18-06-2014 09:04Gyorgy RethyAssigned To => Gyorgy Rethy
18-06-2014 09:04Gyorgy RethyStatusnew => assigned
18-06-2014 09:04Gyorgy RethyTarget Version => v4.7.1 (published 2015-06)
18-06-2014 09:06Gyorgy RethyNote Edited: 0012118bug_revision_view_page.php?bugnote_id=12118#r33
18-06-2014 09:10Gyorgy RethyNote Edited: 0012118bug_revision_view_page.php?bugnote_id=12118#r34
18-06-2014 11:52Gyorgy RethyNote Edited: 0012118bug_revision_view_page.php?bugnote_id=12118#r38
18-06-2014 12:11Gyorgy RethyFile Added: CR6731_resolution_v1.doc
18-06-2014 12:16Gyorgy RethyNote Added: 0012121
18-06-2014 12:17Gyorgy RethyAssigned ToGyorgy Rethy => Tomas Urban
18-06-2014 12:17Gyorgy RethyStatusassigned => confirmed
18-06-2014 12:19Gyorgy RethyFile Deleted: CR6731_resolution_v1.doc
18-06-2014 12:20Gyorgy RethyFile Added: CR6731_resolution_v1.doc
18-06-2014 12:25Gyorgy RethyNote Edited: 0012118bug_revision_view_page.php?bugnote_id=12118#r39
18-06-2014 15:11Tomas UrbanNote Added: 0012130
18-06-2014 15:11Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
18-06-2014 15:11Tomas UrbanStatusconfirmed => assigned
08-10-2014 08:25Gyorgy RethyAssigned ToGyorgy Rethy => Axel Rennoch
08-10-2014 08:31Gyorgy RethyStatusassigned => confirmed
08-10-2014 11:32Axel RennochFile Added: CR6731_resolution_v2.doc
08-10-2014 11:35Axel RennochNote Added: 0012278
08-10-2014 11:36Axel RennochAssigned ToAxel Rennoch => Tomas Urban
08-10-2014 11:36Axel RennochStatusconfirmed => assigned
08-10-2014 11:36Axel RennochStatusassigned => confirmed
08-10-2014 13:50Tomas UrbanFile Added: CR6731_resolution_v3.doc
08-10-2014 13:59Tomas UrbanNote Added: 0012283
08-10-2014 14:00Tomas UrbanAssigned ToTomas Urban => Axel Rennoch
08-10-2014 16:08Axel RennochNote Added: 0012294
08-10-2014 16:09Axel RennochAssigned ToAxel Rennoch => Gyorgy Rethy
08-10-2014 16:09Axel RennochStatusconfirmed => assigned
08-10-2014 16:10Axel RennochStatusassigned => confirmed
08-10-2014 16:25Jacob Wieland - SpirentNote Added: 0012297
08-10-2014 16:29Jacob Wieland - SpirentNote Added: 0012299
08-10-2014 16:40Gyorgy RethyFile Added: CR6731_resolution_v4.doc
08-10-2014 16:40Gyorgy RethyNote Added: 0012303
08-10-2014 16:41Gyorgy RethyStatusconfirmed => resolved
08-10-2014 16:41Gyorgy RethyResolutionopen => fixed
08-10-2014 16:41Gyorgy RethyFixed in Version => v4.7.1 (published 2015-06)
09-10-2014 09:17Tomas UrbanAssigned ToGyorgy Rethy => Tomas Urban
09-10-2014 09:17Tomas UrbanStatusresolved => feedback
09-10-2014 09:17Tomas UrbanResolutionfixed => reopened
09-10-2014 09:27Tomas UrbanFile Added: CR6731_resolution_v5.doc
09-10-2014 09:28Tomas UrbanNote Added: 0012310
09-10-2014 09:28Tomas UrbanStatusfeedback => assigned
09-10-2014 11:05Tomas UrbanFile Added: CR6731_resolution_v6.doc
09-10-2014 12:02Tomas UrbanNote Added: 0012315
09-10-2014 12:02Tomas UrbanAssigned ToTomas Urban => Axel Rennoch
09-10-2014 12:02Tomas UrbanStatusassigned => confirmed
09-10-2014 13:13Jacob Wieland - SpirentNote Added: 0012322
09-10-2014 15:14Tomas UrbanNote Added: 0012327
09-10-2014 15:43Tomas UrbanFile Added: CR6731_resolution_v7.doc
09-10-2014 15:47Tomas UrbanNote Added: 0012328
10-10-2014 08:51Axel RennochAssigned ToAxel Rennoch => Tomas Urban
10-10-2014 08:51Axel RennochStatusconfirmed => assigned
10-10-2014 08:52Axel RennochNote Added: 0012335
10-10-2014 08:52Axel RennochStatusassigned => confirmed
10-10-2014 09:04Tomas UrbanNote Added: 0012338
10-10-2014 09:04Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
10-10-2014 10:07Jacob Wieland - SpirentNote Added: 0012344
10-10-2014 10:38Tomas UrbanNote Added: 0012349
10-10-2014 10:38Tomas UrbanNote Edited: 0012349bug_revision_view_page.php?bugnote_id=12349#r85
10-10-2014 10:41Jacob Wieland - SpirentNote Added: 0012350
10-10-2014 10:44Jacob Wieland - SpirentNote Added: 0012353
10-10-2014 10:50Jacob Wieland - SpirentNote Added: 0012354
03-11-2014 13:43Gyorgy RethyNote Added: 0012377
03-11-2014 15:19Jacob Wieland - SpirentNote Added: 0012379
03-11-2014 16:14Gyorgy RethyNote Added: 0012383
03-11-2014 16:15Gyorgy RethyAssigned ToGyorgy Rethy => Tomas Urban
04-11-2014 08:50Tomas UrbanFile Added: CR6731_resolution_v8.doc
04-11-2014 08:50Tomas UrbanFile Deleted: CR6731_resolution_v8.doc
04-11-2014 09:26Tomas UrbanFile Added: CR6731_resolution_v8.doc
04-11-2014 09:35Tomas UrbanNote Added: 0012387
04-11-2014 09:35Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
04-11-2014 10:30Jacob Wieland - SpirentNote Added: 0012390
04-11-2014 11:22Gyorgy RethyFile Added: CR6731_resolution_v9.doc
04-11-2014 11:23Gyorgy RethyNote Added: 0012392
04-11-2014 11:24Gyorgy RethyStatusconfirmed => resolved
04-11-2014 11:24Gyorgy RethyResolutionreopened => fixed
05-11-2014 07:57Tomas UrbanAssigned ToGyorgy Rethy => Tomas Urban
05-11-2014 07:57Tomas UrbanStatusresolved => feedback
05-11-2014 07:57Tomas UrbanResolutionfixed => reopened
05-11-2014 07:57Tomas UrbanFile Added: CR6731_resolution_v10.doc
05-11-2014 08:01Tomas UrbanNote Added: 0012411
05-11-2014 08:01Tomas UrbanStatusfeedback => assigned
05-11-2014 08:01Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
05-11-2014 08:01Tomas UrbanStatusassigned => confirmed
05-11-2014 16:19Gyorgy RethyRelationship addedrelated to 0006813
05-11-2014 16:22Gyorgy RethyNote Added: 0012438
05-11-2014 16:23Gyorgy RethyFile Deleted: CR6731_resolution_v10.doc
05-11-2014 16:23Gyorgy RethyStatusconfirmed => resolved
05-11-2014 16:23Gyorgy RethyResolutionreopened => fixed
04-01-2015 20:37Gyorgy RethyNote Added: 0012612
04-01-2015 20:37Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0012035) +
+ Jacob Wieland - Spirent    +
+ 15-04-2014 09:19    +
+ 		+ + + + +
+ I'm pretty sure the only way this can go in general is the assignment-semantics as otherwise, passing a variable of one type as an actual parameter to a formal parameter of a type-compatible type would probably be hard to achieve. However, if the types are the same, passing-by-reference is mostly equivalent to the assignment-semantics.
+
+
+
+ + + + + + + + + + +
+ (0012118) +
+ Gyorgy Rethy    +
+ 18-06-2014 09:04    +
(edited on: 18-06-2014 12:25)
+ 		+ + + + +
+ I agree with Jacob. Assignment-semantics was the original assumption, because TTCN-3 is an abstract language. It simply doesn't know things like pointer. We have references to active TTCN-3 objects only, like timers, components, ports, but not to data objects. Also, a term like passing-by-reference is not defined, so we should avoid using it.
+
+I think the sources of the problem are
+- using the word "bound" in the definitions of all kinds of parameterization; "bound" itself may be interpreted both as "assigning" and "connecting" and for in parameters it is used in the sense of "assigning" (otherwise it would be impossible to prevent changing the original value of the actual parameter), while for inout and out is used in the sense of "connecting";
+- the definition of inout parameterization seems to be incomplete; i.e. it mentions nothing more than "bounding" the actual parameter to the formal parameter that really gives the impression of pointer-passing.
+
+I suppose, in the example
+testcase TC() runs on C {
+  f(vc_int);
+}
+was meant. Actually, according to Note1 to the definition of inout parameterization, the example shall print 10.
+
+I will propose correction to the text.
+
+
+
+
+
+ + + + + + + + + + +
+ (0012121) +
+ Gyorgy Rethy    +
+ 18-06-2014 12:16    +
+ 		+ + + + +
+ See the proposed solution in CR6731_resolution_v1.doc.
+
+
+
+ + + + + + + + + + +
+ (0012130) +
+ Tomas Urban    +
+ 18-06-2014 15:11    +
+ 		+ + + + +
+ Result of STF discussion: the proposal should be more detailed. Possible improvements:
+- defining the term "passing by reference" and its implications
+- type compatibility rules for passing by reference (especially constraint handling)
+- some examples
+- check the situation in the existing TTCN-3 tools
+
+
+
+ + + + + + + + + + +
+ (0012278) +
+ Axel Rennoch    +
+ 08-10-2014 11:35    +
+ 		+ + + + +
+ - addition of an inital definition of "passing by reference"
+- extended note for "inout" and "out" parameterization
+
+
+
+ + + + + + + + + + +
+ (0012283) +
+ Tomas Urban    +
+ 08-10-2014 13:59    +
+ 		+ + + + +
+ Since Axel defined the term "passing by reference", I added it to several other rules so that the concept can be really used. I also defined what "passing by value" means. The terms are defined on an abstract level (no pointers and other implementation details are mentioned).
+
+The system now resembles the one used in modern programming languages, the in and out parameterization use passing by value and inout passing by reference. Some current or proposed rules were not completely compatible with these concepts, so I had to modify them.
+
+I also added an example demonstrating the difference between the two principles of parameter passing.
+
+Axel, could you please check if there are no inconsistencies in my proposal? If so, we can continue our discussion if it is acceptable to solve the CR this way.
+
+
+
+ + + + + + + + + + +
+ (0012294) +
+ Axel Rennoch    +
+ 08-10-2014 16:08    +
+ 		+ + + + +
+ The proposal is fine for me. We may move the second sentence of the defintions "passing by .." to a NOTE.
+
+
+
+ + + + + + + + + + +
+ (0012297) +
+ Jacob Wieland - Spirent    +
+ 08-10-2014 16:25    +
+ 		+ + + + +
+ So, in my opinion it follows for inout parameterization that the type of the formal and actual parameter need to be the same, otherwise, there could develop some very confusing situations:
+
+type integer I1 (0 .. 5);
+type integer I2 (5 .. 10);
+
+var integer i := 5;
+
+f(i, i);
+
+function f(inout I1 i1, inout I2 i2) {
+  i1 := 0; // causes an error because it violates constraint of I2
+  i2 := 10; // causes an error because it violates constraint of I1
+}
+
+I'm also not sure what happens if one actual parameter contains another one.
+
+Consider the following:
+
+type record R {
+  record {
+    integer i
+  } f
+}
+
+var R rr := ... ;
+
+f2(rr, rr.f.i);
+
+where f2 is defined like this
+
+function f2(inout R r, inout integer i) {
+  r := { f := { i := x } } // is parameter i changed here or not?
+  i := i + 1; // does this still change r or not?
+}
+
+
+
+ + + + + + + + + + +
+ (0012299) +
+ Jacob Wieland - Spirent    +
+ 08-10-2014 16:29    +
+ 		+ + + + +
+ Ah, the first restriction is already in the proposal, my bad. The other question still remains, though.
+
+
+
+ + + + + + + + + + +
+ (0012303) +
+ Gyorgy Rethy    +
+ 08-10-2014 16:40    +
+ 		+ + + + +
+ CR6731_resolution_v4.doc: only cosmetic editorial changes.
+
+
+
+ + + + + + + + + + +
+ (0012310) +
+ Tomas Urban    +
+ 09-10-2014 09:28    +
+ 		+ + + + +
+ I am afraid I have to reopen this CR. As Jacob pointed out there are unresolved questions regarding elements of structured types that are passed by reference. I tried to address these issues in the next version of the proposal.
+
+Jacob, if you have time, could you please take a look at it and comment it?
+
+
+
+ + + + + + + + + + +
+ (0012315) +
+ Tomas Urban    +
+ 09-10-2014 12:02    +
+ 		+ + + + +
+ Axel, could you please check the last additions to the proposed resolution?
+
+
+
+ + + + + + + + + + +
+ (0012322) +
+ Jacob Wieland - Spirent    +
+ 09-10-2014 13:13    +
+ 		+ + + + +
+ I would not know how to implement this (easily).
+
+Also, if I understand it correctly, this would have the following implication.
+
+type union U {
+  record {
+    integer i
+  } v1,
+  record {
+    float f
+  } v2
+}
+
+var U u := { v1 := { i := 5 } }
+
+f(u, u.v1.i);
+
+where
+
+function f(U pu, integer pi) {
+  pu := { v2 := { f := 5.0 } } // => pi is undefined
+  pi := 5 // => pu == { v1 := { i := 5 } }
+}
+
+This, in my opinion, is highly uninituitive. It also breaks the rule that a variable that has been ininitalized cannot be un-initialized again.
+
+I would define the semantics in such a way that pi keeps its value and does not have any impact on pu after pu was severed from pi anymore. pi can still be used inside the function, but is thrown away after f is left.
+
+This is much more in sync with the copy-back approach that we interpreted the standard up-till now (and is also far easier to implement as pi does not have to know where it resides in its superstructure while in the proposed solution, it does to be able to do the appropriate expansion).
+
+
+
+ + + + + + + + + + +
+ (0012327) +
+ Tomas Urban    +
+ 09-10-2014 15:14    +
+ 		+ + + + +
+ Jacob, you understand the proposal correctly.
+
+It is quite easy to implement using structured pointers. Instead of saving the address of the element itself, the tool can store the whole reference chain, i.e. in your example pi would be represented as { address of u, index of v2, index of i }. Dereferencing such pointers is not that fast as in case of classical pointers, but it should not constitute a major performance bottleneck.
+
+I actually understand your concern that it is not intuitive. However, it is difficult to find any intuitive solution. When using copy-back approach, it behaves also in an unexpected way, especially for people used to passing by reference (and copying has other cons, such as wasting of resources).
+
+There are two alternative approaches we could consider.
+
+1) Element detaching instead of complete deleting. That's what Jacob proposes, i.e. that the elements that become disconnected from the original value (by omitting, truncating or selecting other variant) continue to live their own life after disconnection. That's the approach used for objects in languages with garbage collector, so the principle is quite well known. The question is if it is suitable for TTCN-3. I have some objections against this:
+a) It doesn't seem to be intuitive either as restoring the original structure of the structured object doesn't reconnect the object.
+b) We define passing by reference as sharing the data content by the actual and formal parameter, but this wouldn't apply in this case.
+c) It might be difficult to implement in tools that do not use garbage collection (e.g. C++ based tools) as they would have to simulate garbage collector functionality.
+d) It would require to change the definitions again and create additional rules.
+
+2) References cannot be used after the referenced element is no longer valid. This is probably simpler to implement and explain in the rules, but a) and b) from the former paragraph are still valid.
+
+In my opinion the proposed solution is the least "evil" one and I would pick it as the resolution of this CR. However, I am open to further discussion.
+
+
+
+ + + + + + + + + + +
+ (0012328) +
+ Tomas Urban    +
+ 09-10-2014 15:47    +
+ 		+ + + + +
+ Two small additions to the proposal (CR6731_resolution_v7.doc):
+- rules for using references in actual parameters
+- rules for order of passing values from out formal parameters to actual parameters
+
+
+
+ + + + + + + + + + +
+ (0012335) +
+ Axel Rennoch    +
+ 10-10-2014 08:52    +
+ 		+ + + + +
+ checked and can be set to resolved.
+
+
+
+ + + + + + + + + + +
+ (0012338) +
+ Tomas Urban    +
+ 10-10-2014 09:04    +
+ 		+ + + + +
+ Gyorgy, please take a final look at it before we mark it as resolved. Since Jacob raised some objections, a person different from the authors of the proposed changes should set the final verdict.
+
+
+
+ + + + + + + + + + +
+ (0012344) +
+ Jacob Wieland - Spirent    +
+ 10-10-2014 10:07    +
+ 		+ + + + +
+ I think the unintuitive-ness is my biggest concern, as well as the fact that we took great pains to introduce restrictions so that no variable that was at any point initialized can become uninitialized again.
+
+This way, we introduce such a case through the back-door and what makes it worse, it is not apparent in the context of the variable at all (since the function does not know what its actual parameters will be) and can be caused by the assignment of a different variable. No flow-analysis checking for initialization of variables before usage would work anymore.
+
+As non-garbage-collection frameworks have to take care of garbage-collection themselves, anyway, I am sure, it will be quite easy to find out that the reference to the variable is lost and therefore it can be collected (by whatever mechanism, if any) after the function is left again.
+
+The unintuitive-ness of the non-reconnection-issue is granted, though I think only to those not thinking about implementations of data-structures. Both in the C-pointer-world as in the object-oriented-world no-one would expect a reconnect once a sub-structure is replaced with a different sub-structure. Anyway, if a NOTE explaining that special situation is added to the standard, confusion there can be avoided. This is, of course, true also for the other approach, but there the other drawbacks mentioned above are not addressed.
+
+
+
+ + + + + + + + + + +
+ (0012349) +
+ Tomas Urban    +
+ 10-10-2014 10:38    +
+ 		+ + + + +
+ Technically, we still don't allow to uninitialize variables. Only formal inout parameters can become uninitialized and only in cases when they refer to an element located in an optional part of a structured value. The existing tools most likely implement flow analysis in such a way that disappearance of the optional part of structured values is considered and I see no reason, why this approach cannot be extended to parameters passed by reference.
+
+If you are concerned about the back door problem, we should first discuss if passing by reference is suitable at all, because this problem will always exist when two different references share the same data content.
+
+
+
+
+
+ + + + + + + + + + +
+ (0012350) +
+ Jacob Wieland - Spirent    +
+ 10-10-2014 10:41    +
+ 		+ + + + +
+ Thinking about this further, I think what you are proposing is actually called normally 'call-by-name', i.e. that in the parameterized body, the references to the formal-inout-parameters are replaced not by the references to the actual parameters but by the actual parameters themselves (i.e. the pu would be replaced by the expression u and pi would be replaced by the expression). That way, you would get your proposed semantics. This, of course, should not be called call-by-reference since those people knowing the term from other context will not understand the proposed call-by-name semantics. Thus, if you go that way - accepting all the drawbacks - please name and describe the concept accordingly.
+
+
+
+ + + + + + + + + + +
+ (0012353) +
+ Jacob Wieland - Spirent    +
+ 10-10-2014 10:44    +
+ 		+ + + + +
+ At the moment, no variable can become uninitialized by the disappearance of a sub-structure of another variable. So, flow-analysis tools do not have to take into account that a variable can become uninitialized, but only has to keep track of sub-structures. In principle, you are right, flow analysis is already pretty impossible even without this additional complication, but I don't think making it more complicated will help matters there.
+
+
+
+ + + + + + + + + + +
+ (0012354) +
+ Jacob Wieland - Spirent    +
+ 10-10-2014 10:50    +
+ 		+ + + + +
+ Of course, we could simply forbid this kind of situation altogether. I.e. passing a variable and a sub-structure of the same variable both as inout parameter to a function could be forbidden to avoid these semantic uncertainties. Though this might introduce backward-incompatiblities, the actual (probably pathological) situations where something like this occurs now are not clearly defined anyway and could lead to different behaviors in different tools, so I don't see a big problem there.
+
+Thinking about this some more, we should also think about what happens if a variable and its sub-structure are passed to an inout and an out parameter. Does the out-copy-back-assignment win or lose according to parameter order or does copy-back always occur?
+
+
+
+ + + + + + + + + + +
+ (0012377) +
+ Gyorgy Rethy    +
+ 03-11-2014 13:43    +
+ 		+ + + + +
+ I think the main point is to define the rules clearly. At this point in time (TTCN-3 is 15 years old), we shall avoid backward incompatible restrictions.
+
+Let discuss the possible alternatives further.
+
+It seems to me that there is no disagreement regarding the unstructured case (new example 6). But, see below...
+
+The complicated thing is when passing a structure and also its element as read-write-able parameters. I agree, from a (framework) function writer's point of view it may be strange and unexpected if some parameters can be made implicitly uninitialized by certain parameter combinations...
+
+There are more ways to go:
+- either specify a special exception for this case (too many exceptions already in the language)
+- allow side effects, notify users about them.
+- define a rule disallowing side effects in both cases (when the same value is passed to two different inout parameters and when a structure and its element are also passed as inout parameters), i.e. seemingly a value passed in, a value passed out, no side effect inside. This will complicate tool implementations but probably the safest for the users.
+
+
+
+out parameters' behaviour should not be a problem, as they are passed by value, i.e. changing an out parameter within the called function shall not change the inout parameter's value immediately, within the function. An interesting effect that dependig on the above decision, it may or may not overwrite the inout parameter's (or its elemen's) value when leaving the function.
+
+
+
+ + + + + + + + + + +
+ (0012379) +
+ Jacob Wieland - Spirent    +
+ 03-11-2014 15:19    +
+ 		+ + + + +
+ I would opt for variant 3 (disallowing). It is a pathological case and will probably lead to unexpected behavior (and up till now, different behavior for each implementation).
+
+And, I think that this should include out parameters as well (mixing them with inout in a shared structure). If only out parameters are used, there is no problem.
+
+
+
+ + + + + + + + + + +
+ (0012383) +
+ Gyorgy Rethy    +
+ 03-11-2014 16:14    +
+ 		+ + + + +
+ STF discussion: passing a sructure and a member of that structure to two different inout parameters of a function at the same time should be disallowed.
+
+
+
+ + + + + + + + + + +
+ (0012387) +
+ Tomas Urban    +
+ 04-11-2014 09:35    +
+ 		+ + + + +
+ Modification in the last version of the document:
+1. Restriction saying that elements of a structure cannot be passed by reference if the structure is also passed by reference.
+2. Restriction saying that distinct alternatives of union and anytype values cannot be passed by reference.
+
+These restrictions should prevent the situation when an already initialized inout parameter value becomes uninitialized through modification of another inout parameter.
+
+I also removed the rules that were related to the now-disallowed behaviour and moved the section on structured values into the section describing actual parameters where it logically belongs.
+
+Please review.
+
+
+
+ + + + + + + + + + +
+ (0012390) +
+ Jacob Wieland - Spirent    +
+ 04-11-2014 10:30    +
+ 		+ + + + +
+ No objections from me.
+
+
+
+ + + + + + + + + + +
+ (0012392) +
+ Gyorgy Rethy    +
+ 04-11-2014 11:23    +
+ 		+ + + + +
+ In CR6731_resolution_v9.doc only editorials and the new note to the actual parameter restrictions is deleted as superfluous, in agreement with Tomas.
+
+
+
+ + + + + + + + + + +
+ (0012411) +
+ Tomas Urban    +
+ 05-11-2014 08:01    +
+ 		+ + + + +
+ One more restriction is necessary to prevent the situation when both parent structure and its field/element are available as a reference: the combination of runs on and component variable field passed to an inout parameter.
+
+The restriction n) has been added to 5.4.2 and original restriction n) was changed to o). Please review.
+
+
+
+ + + + + + + + + + +
+ (0012438) +
+ Gyorgy Rethy    +
+ 05-11-2014 16:22    +
+ 		+ + + + +
+ It is agreed that a new restriction on component variabes has more chance to invalidate existing and working test suites, therefore we need user feedback on it. Hence it will not be included into this CR but new CR 6813 has been created. CR6731_resolution_v9.doc continues to be the final agreed version.
+
+
+
+ + + + + + + + + + +
+ (0012612) +
+ Gyorgy Rethy    +
+ 04-01-2015 20:37    +
+ 		+ + + + +
+ Added to V4.6.3
+
+ + diff --git a/docs/mantis/CR6732.md b/docs/mantis/CR6732.md new file mode 100644 index 0000000000000000000000000000000000000000..460a2e367d80ea7b4df77a0d2001a29103f0b245 --- /dev/null +++ b/docs/mantis/CR6732.md @@ -0,0 +1,170 @@ + + + + + + + + + + + + + 0006732: Language tag of XSD module import - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006732Part 09: Using XML with TTCN-3Editorialpublic16-04-2014 09:1131-12-2014 14:33
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.5.1 (published 2013-04) 
Target Versionv4.6.1 (published 2015-06)Fixed in Versionv4.6.1 (published 2015-06) 
Clause Reference(s)Annex C
For STF discussion
Source (company - Author)STF 475
Summary0006732: Language tag of XSD module import
DescriptionThere's an inconsistency between the examples in the main part of the specification and the annex C. The examples in the main part do not use any language tag when importing the XSD module, but the examples in the annex C do.
+
+I assume that there should be no language tag as according to the rules specified in the section 5, the "XSD" language tag is reserved for importing from XSD schemas.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR6732_v1.docx (59,757) 06-10-2014 11:05
http://oldforge.etsi.org/mantis/file_download.php?file_id=3082&type=bug
Issue History
Date ModifiedUsernameFieldChange
16-04-2014 09:11Tomas UrbanNew Issue
15-06-2014 18:02Gyorgy RethyAssigned To => Gyorgy Rethy
15-06-2014 18:02Gyorgy RethyStatusnew => assigned
15-06-2014 18:02Gyorgy RethyTarget Version => v4.6.1 (published 2015-06)
23-06-2014 11:37Gyorgy RethyNote Added: 0012193
23-06-2014 11:38Gyorgy RethyAssigned ToGyorgy Rethy => Tomas Urban
23-06-2014 11:38Gyorgy RethyStatusassigned => confirmed
06-10-2014 11:05Tomas UrbanFile Added: CR6732_v1.docx
06-10-2014 11:14Tomas UrbanNote Added: 0012226
06-10-2014 11:14Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
04-11-2014 13:59Gyorgy RethyNote Added: 0012400
04-11-2014 13:59Gyorgy RethyStatusconfirmed => resolved
04-11-2014 13:59Gyorgy RethyFixed in Version => v4.6.1 (published 2015-06)
04-11-2014 13:59Gyorgy RethyResolutionopen => fixed
31-12-2014 14:33Gyorgy RethyNote Added: 0012600
31-12-2014 14:33Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0012193) +
+ Gyorgy Rethy    +
+ 23-06-2014 11:37    +
+ 		+ + + + +
+ Actually, Annex C needs to be corrected. No "XSD" language tag needs to be present when importing from another TTCN-3 module, it shall be used when importing from XSD modules directly (i.e. at implicit mapping). As decided earlier, when the "XSD" language tag is used for importing a TTCN-3 module, which has any XML encode attribute defined in clause B.2 applied, this shall not cause an error.
+
+Annex C will be corrected accordingly.
+
+
+
+ + + + + + + + + + +
+ (0012226) +
+ Tomas Urban    +
+ 06-10-2014 11:14    +
+ 		+ + + + +
+ Resolution proposal uploaded. The language tag was removed from the import of the XSD module and language "XML" was changed to language "XSD" for other import clauses. There was a problem with module names too, so I corrected those as well.
+Please check.
+
+
+
+ + + + + + + + + + +
+ (0012400) +
+ Gyorgy Rethy    +
+ 04-11-2014 13:59    +
+ 		+ + + + +
+ A final cross-checking to be made during implementing the CR!
+
+
+
+ + + + + + + + + + +
+ (0012600) +
+ Gyorgy Rethy    +
+ 31-12-2014 14:33    +
+ 		+ + + + +
+ Added to draft V4.5.3
+
+ + diff --git a/docs/mantis/CR6733.md b/docs/mantis/CR6733.md new file mode 100644 index 0000000000000000000000000000000000000000..59216dfdeb935d8ddb7c1682abd9a3cf2add1163 --- /dev/null +++ b/docs/mantis/CR6733.md @@ -0,0 +1,131 @@ + + + + + + + + + + + + + 0006733: Space allowed only in namespaces - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006733Part 09: Using XML with TTCN-3Technicalpublic17-04-2014 09:1526-01-2015 11:27
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritylowSeveritytrivialReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.5.1 (published 2013-04) 
Target Versionv4.6.1 (published 2015-06)Fixed in Versionv4.5.2 (interim 2014) 
Clause Reference(s)5.2.2
For STF discussion
Source (company - Author)STF 475
Summary0006733: Space allowed only in namespaces
DescriptionThe note 2 in the section 5.2.2 should include space character as well, since this character cannot occur in type, element, attribute or group names (see the definition of NCName in the section 2 of REC-xml-names-19990114 for more details).
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
17-04-2014 09:15Tomas UrbanNew Issue
24-04-2014 09:53Tomas UrbanNote Added: 0012052
15-06-2014 17:31Gyorgy RethyTarget Version => v4.6.1 (published 2015-06)
16-06-2014 14:53Gyorgy RethyNote Added: 0012088
16-06-2014 14:53Gyorgy RethyStatusnew => resolved
16-06-2014 14:53Gyorgy RethyFixed in Version => v4.6.1 (published 2015-06)
16-06-2014 14:53Gyorgy RethyResolutionopen => fixed
16-06-2014 14:53Gyorgy RethyAssigned To => Gyorgy Rethy
20-06-2014 11:50Gyorgy RethyFixed in Versionv4.6.1 (published 2015-06) =>
20-06-2014 11:52Gyorgy RethyNote Added: 0012188
20-06-2014 11:52Gyorgy RethyStatusresolved => closed
20-06-2014 11:52Gyorgy RethyFixed in Version => v4.6.1 (published 2015-06)
24-06-2014 09:00Gyorgy RethyFixed in Versionv4.6.1 (published 2015-06) => v4.5.2 (interim 2014)
26-01-2015 11:20Gyorgy RethyFixed in Versionv4.5.2 (interim 2014) => v4.6.1 (published 2015-06)
26-01-2015 11:27Gyorgy RethyFixed in Versionv4.6.1 (published 2015-06) => v4.5.2 (interim 2014)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0012052) +
+ Tomas Urban    +
+ 24-04-2014 09:53    +
+ 		+ + + + +
+ Please notice that although space can be used in namespaces, it is discouraged to do so.
+
+
+
+ + + + + + + + + + +
+ (0012088) +
+ Gyorgy Rethy    +
+ 16-06-2014 14:53    +
+ 		+ + + + +
+ " " (SPACE) added to the note as proposed in the master copy.
+
+
+
+ + + + + + + + + + +
+ (0012188) +
+ Gyorgy Rethy    +
+ 20-06-2014 11:52    +
+ 		+ + + + +
+ Implemented in V4.5.2
+
+ + diff --git a/docs/mantis/CR6734.md b/docs/mantis/CR6734.md new file mode 100644 index 0000000000000000000000000000000000000000..99d74495974ccf19fbc003f1e8bbc009fc78c4cb --- /dev/null +++ b/docs/mantis/CR6734.md @@ -0,0 +1,182 @@ + + + + + + + + + + + + + 0006734: Extension of the rule on same type identifiers - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006734Part 09: Using XML with TTCN-3Technicalpublic17-04-2014 14:2026-01-2015 11:45
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.5.1 (published 2013-04) 
Target Versionv4.6.1 (published 2015-06)Fixed in Versionv4.6.1 (published 2015-06) 
Clause Reference(s)5.2.2
For STF discussion
Source (company - Author)STF 475
Summary0006734: Extension of the rule on same type identifiers
DescriptionThe rule 5.2.2.j currently concerns only the situation when the type name is equal to another existing type name or reserved word. However, there are two more situations when a name clash can occur: conflict with the local module name and conflict with an imported module name (see 5.2.2 of the core language specification for more details). Both situations should be added to 5.2.2.j
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0006735closed Gyorgy Rethy Missing rules for transforming XSD namespaces into TTCN-3 module names 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
17-04-2014 14:20Tomas UrbanNew Issue
15-06-2014 18:02Gyorgy RethyTarget Version => v4.6.1 (published 2015-06)
16-06-2014 14:51Tomas UrbanFile Added: CR6734_v1.docx
16-06-2014 14:52Tomas UrbanNote Added: 0012087
16-06-2014 14:52Tomas UrbanAssigned To => Gyorgy Rethy
16-06-2014 14:52Tomas UrbanStatusnew => confirmed
16-06-2014 14:53Tomas UrbanFile Deleted: CR6734_v1.docx
16-06-2014 14:54Tomas UrbanAssigned ToGyorgy Rethy => Tomas Urban
16-06-2014 14:54Tomas UrbanStatusconfirmed => new
16-06-2014 14:55Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
16-06-2014 14:55Tomas UrbanStatusnew => assigned
17-06-2014 13:17Tomas UrbanNote Deleted: 0012087
17-06-2014 13:17Tomas UrbanRelationship addedrelated to 0006735
18-06-2014 20:19Jacob Wieland - SpirentNote Added: 0012136
19-06-2014 07:58Tomas UrbanNote Added: 0012137
19-06-2014 12:38Jacob Wieland - SpirentNote Added: 0012142
05-11-2014 10:02Gyorgy RethyNote Added: 0012417
05-11-2014 10:02Gyorgy RethyStatusassigned => closed
05-11-2014 10:02Gyorgy RethyResolutionopen => fixed
05-11-2014 10:02Gyorgy RethyFixed in Version => v4.5.2 (interim 2014)
26-01-2015 11:45Gyorgy RethyFixed in Versionv4.5.2 (interim 2014) => v4.6.1 (published 2015-06)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0012136) +
+ Jacob Wieland - Spirent    +
+ 18-06-2014 20:19    +
+ 		+ + + + +
+ Actually, I don't think there is a conflict with an imported module name as such name-clash can always be resolved by adding the local module name to the local definition. Then, using the unqualified clashing name always must mean the imported module. (The same issue exists in TTCN-3 core language and I am not aware of such a restriction there)
+
+
+
+ + + + + + + + + + +
+ (0012137) +
+ Tomas Urban    +
+ 19-06-2014 07:58    +
+ 		+ + + + +
+ I am afraid you are wrong. The core language specifications states (in 5.2.2): "The identifier of a module (its module name) or of an imported module belongs to the scope unit of the module and cannot be used as identifier for other definitions inside this module."
+
+There's a good reason for that, see the example:
+
+module M1 {
+  const integer x := 1;
+}
+
+module M2 {
+  import from M1 all;
+  type record R { integer x }
+  control {
+    const R M1 := { x:= 2 };
+    const integer y := M1.x; // imported constant or local definition?
+  }
+}
+
+
+
+ + + + + + + + + + +
+ (0012142) +
+ Jacob Wieland - Spirent    +
+ 19-06-2014 12:38    +
+ 		+ + + + +
+ You are right. Still, as I have demonstrated, the restriction is unnecessary as the nameclash can be easily be resolved. The only difference to the normal nameclash-resolution wuld be that the local definition needs to be prefixed.
+
+Anyway, maybe food for a different CR. As it is, it makes sense (and avoids nameclashes) to number the local definitions if a module with clashing name is imported.
+
+
+
+ + + + + + + + + + +
+ (0012417) +
+ Gyorgy Rethy    +
+ 05-11-2014 10:02    +
+ 		+ + + + +
+ Solution to postfix clashing type names has been added to clause 5.2.2 k) in CR 6735 to the interim version V4.5.2.
+
+ + diff --git a/docs/mantis/CR6735.md b/docs/mantis/CR6735.md new file mode 100644 index 0000000000000000000000000000000000000000..c3279b34e15d521e26a4d2694b6b0de2b2cd225d --- /dev/null +++ b/docs/mantis/CR6735.md @@ -0,0 +1,447 @@ + + + + + + + + + + + + + 0006735: Missing rules for transforming XSD namespaces into TTCN-3 module names - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006735Part 09: Using XML with TTCN-3Clarificationpublic21-04-2014 11:0026-01-2015 11:22
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.5.1 (published 2013-04) 
Target Versionv4.6.1 (published 2015-06)Fixed in Versionv4.5.2 (interim 2014) 
Clause Reference(s)5.2.2
For STF discussion
Source (company - Author)STF 475
Summary0006735: Missing rules for transforming XSD namespaces into TTCN-3 module names
DescriptionThe section 5.1.1 containing the rules for transformation of XSD namespaces into TTCN-3 module names refers to the chapter 5.2.2: The names of the TTCN 3 modules generated based on this clause shall be the result of applying the name transformation rules in clause 5.2.2 to the related target namespace.
+
+The section 5.2.2 provides good guidelines for transforming the module name so that it contains characters allowed in TTCN-3, but there are no rules for handling name clashes. In particular, there should be a dedicated rule saying what happens if transformation of several distinct namespace into TTCN-3 module yields the same result or results into a TTCN-3 keyword or a name of a predefined function (similar to the rules j, k and l for types, field names and enumerated items).
+
+It is also not known what rule for X-prefixing should be applied. Is the X character capitalized as for types (rules f, h) or uncapitalized as for field names(rules g, i)?
+
+In addition to that, the section 5.2.3 should contain rules for ordering namespaces before transformation takes place. These rules should take into account existence of the predefined "NoTargetNamespace" module for items without namespace so that it is known which namespace takes precedence during tranformation in the unlikely case when there's another namespace that transforms to "NoTargetNamespace" as well.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0006777closed Axel Rennoch Normalization of target namespace values to be clarified 
related to 0006734closed Gyorgy Rethy Extension of the rule on same type identifiers 
Attached Filesdoc CR6735_resolution_v1.doc (114,176) 16-06-2014 17:31
http://oldforge.etsi.org/mantis/file_download.php?file_id=3034&type=bug
doc CR6735_resolution_v2.doc (114,688) 17-06-2014 09:21
http://oldforge.etsi.org/mantis/file_download.php?file_id=3036&type=bug
doc CR6735_resolution_v3.doc (114,688) 19-06-2014 16:39
http://oldforge.etsi.org/mantis/file_download.php?file_id=3061&type=bug
doc CR6735_resolution_v4.doc (115,200) 20-06-2014 08:51
http://oldforge.etsi.org/mantis/file_download.php?file_id=3067&type=bug
Issue History
Date ModifiedUsernameFieldChange
21-04-2014 11:00Tomas UrbanNew Issue
22-04-2014 08:32Jacob Wieland - SpirentNote Added: 0012043
15-06-2014 17:47Gyorgy RethyAssigned To => Gyorgy Rethy
15-06-2014 17:47Gyorgy RethyStatusnew => assigned
15-06-2014 18:03Gyorgy RethyTarget Version => v4.6.1 (published 2015-06)
16-06-2014 16:18Gyorgy RethyNote Added: 0012091
16-06-2014 17:06Gyorgy RethyNote Edited: 0012091bug_revision_view_page.php?bugnote_id=12091#r23
16-06-2014 17:06Gyorgy RethyNote Edited: 0012091bug_revision_view_page.php?bugnote_id=12091#r24
16-06-2014 17:31Gyorgy RethyRelationship addedrelated to 0006777
16-06-2014 17:31Gyorgy RethyFile Added: CR6735_resolution_v1.doc
16-06-2014 17:32Gyorgy RethyNote Edited: 0012091bug_revision_view_page.php?bugnote_id=12091#r25
16-06-2014 17:33Gyorgy RethyAssigned ToGyorgy Rethy => Tomas Urban
16-06-2014 17:33Gyorgy RethyStatusassigned => confirmed
16-06-2014 17:33Gyorgy RethyResolutionopen => fixed
17-06-2014 07:16Jacob Wieland - SpirentNote Added: 0012093
17-06-2014 09:21Gyorgy RethyFile Added: CR6735_resolution_v2.doc
17-06-2014 09:27Gyorgy RethyNote Added: 0012098
17-06-2014 12:17Jacob Wieland - SpirentNote Added: 0012102
17-06-2014 13:17Tomas UrbanRelationship addedrelated to 0006734
17-06-2014 13:24Tomas UrbanNote Added: 0012103
17-06-2014 13:24Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
19-06-2014 16:18Gyorgy RethyNote Added: 0012154
19-06-2014 16:19Gyorgy RethyNote Edited: 0012154bug_revision_view_page.php?rev_id=50
19-06-2014 16:20Gyorgy RethyNote Edited: 0012154bug_revision_view_page.php?rev_id=51
19-06-2014 16:21Gyorgy RethyNote Edited: 0012154bug_revision_view_page.php?rev_id=52
19-06-2014 16:25Gyorgy RethyNote Deleted: 0012154
19-06-2014 16:38Gyorgy RethyNote Added: 0012156
19-06-2014 16:38Gyorgy RethyNote Edited: 0012156bug_revision_view_page.php?bugnote_id=12156#r54
19-06-2014 16:39Gyorgy RethyFile Added: CR6735_resolution_v3.doc
19-06-2014 16:41Gyorgy RethyNote Edited: 0012156bug_revision_view_page.php?bugnote_id=12156#r55
19-06-2014 16:41Gyorgy RethyAssigned ToGyorgy Rethy => Tomas Urban
19-06-2014 16:41Gyorgy RethyStatusconfirmed => assigned
20-06-2014 07:49Tomas UrbanNote Added: 0012166
20-06-2014 07:49Tomas UrbanStatusassigned => resolved
20-06-2014 07:49Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
20-06-2014 08:02Jacob Wieland - SpirentNote Added: 0012167
20-06-2014 08:02Jacob Wieland - SpirentStatusresolved => feedback
20-06-2014 08:02Jacob Wieland - SpirentResolutionfixed => reopened
20-06-2014 08:02Jacob Wieland - SpirentStatusfeedback => assigned
20-06-2014 08:51Tomas UrbanFile Added: CR6735_resolution_v4.doc
20-06-2014 08:53Tomas UrbanNote Added: 0012172
20-06-2014 08:53Tomas UrbanStatusassigned => confirmed
24-06-2014 09:49Gyorgy RethyNote Edited: 0012156bug_revision_view_page.php?bugnote_id=12156#r63
24-06-2014 09:54Gyorgy RethyNote Added: 0012196
24-06-2014 09:54Gyorgy RethyStatusconfirmed => closed
24-06-2014 09:54Gyorgy RethyResolutionreopened => fixed
24-06-2014 09:54Gyorgy RethyFixed in Version => v4.5.2 (interim 2014)
26-01-2015 11:21Gyorgy RethyFixed in Versionv4.5.2 (interim 2014) => v4.6.1 (published 2015-06)
26-01-2015 11:22Gyorgy RethyFixed in Versionv4.6.1 (published 2015-06) => v4.5.2 (interim 2014)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0012043) +
+ Jacob Wieland - Spirent    +
+ 22-04-2014 08:32    +
+ 		+ + + + +
+ I think first the namespaces should be ordered alphabetically/lexicographically where the non-existent namespace (yielding NoTargetNamespace) should be the smallest item for comparison, even smaller than the empty string (which would yield namespace X or x, in my opinion, it should be capitalized).
+
+Then, after applying the mapping-rules, if nameclashes occur, it is clear which namespace gets which number, dependent on the above ordering.
+
+In my opinion, no two modules can have the NoTargetNamespace as all schemas without namespace are all collected in the NoTargetNamespace module (they all have the same namespace, i.e. none). Using the no-namespace as smallest element in the ordering ensures that all actual namespaces which yield NoTargetNamespace will be numbered. That way, NoTargetNamespace is unambiguously the module for all definitions without a namespace.
+
+
+
+ + + + + + + + + + +
+ (0012091) +
+ Gyorgy Rethy    +
+ 16-06-2014 16:18    +
(edited on: 16-06-2014 17:32)
+ 		+ + + + +
+ See proposed resolution in CR6735_resolution_v1.doc.
+
+Rule to order target namespace values before converting them to TTCN-3 is added to 5.2.2 a). New rule m) is added to postfix clashing module names.
+
+A rule to use the target namespace values *before* converting them to TTCN-3 module names is added to clause 5.2.3.
+
+Clause 2.2. of "Namespaces in XML 1.0 (Second Edition)" disallows empty character string as XML namespace, hence no additional rule is needed for this case (no X substitution).
+
+Correct, no two modules can have the name NoTargetNamespace, as XSD documents without a namespace are collected into it and "NoTargetNamespace" is not a valid namespace value.
+
+
+
+
+
+ + + + + + + + + + +
+ (0012093) +
+ Jacob Wieland - Spirent    +
+ 17-06-2014 07:16    +
+ 		+ + + + +
+ Why the exception in 5.2.2 e) for namespaces, since there is already a way to resolve the nameclashes, what is that exception good for?
+
+http://www.example.org/ [^] and http://www.example.org/Ü/ [^] would still result in the same (base)namespace because of the underscore-collapsing-rule and this would lead to double-underscores when appending the suffix.
+
+Why not keep the same rules as for other names?
+
+
+
+ + + + + + + + + + +
+ (0012098) +
+ Gyorgy Rethy    +
+ 17-06-2014 09:27    +
+ 		+ + + + +
+ See CR6735_resolution_v2.doc.
+
+We have discussed this with Tomas, it would be better to leave the trailing _ in module names, but not to add another one when postfixing the module name. The reason is that the kind of
+http://www.example.org [^] vs. http://www.example.org/ [^] case is more frequent than http://www.example.org/ [^] vs. http://www.example.org/Ü/. [^]
+It would be better if in the first case users could see the difference also in the generated module names.
+
+I have also added that module names shall also be prefixed, when it is clashing with a definition name in the same module.
+
+
+
+ + + + + + + + + + +
+ (0012102) +
+ Jacob Wieland - Spirent    +
+ 17-06-2014 12:17    +
+ 		+ + + + +
+ The module names being generated should be independent of the contents of the modules, as they should be the same as seen from all modules. Basically, first all module names shall be generated and then the names of the contents of the module. So, the name of a definition inside a target-namespace should never have any influence on the name of a module. Only the set of namespaces should be the deciding factor.
+
+
+
+ + + + + + + + + + +
+ (0012103) +
+ Tomas Urban    +
+ 17-06-2014 13:24    +
+ 		+ + + + +
+ I agree with Jacob. The resolution of name clashes should go from top to bottom, not vice versa. The proposed solution doesn't take into account the use of module identifiers in import clauses too. When adding import dependencies, the amount of definitions to check for name clashes would significantly grow and make the procedure inefficient. See also the related issue 0006734.
+
+
+
+ + + + + + + + + + +
+ (0012156) +
+ Gyorgy Rethy    +
+ 19-06-2014 16:38    +
(edited on: 24-06-2014 09:49)
+ 		+ + + + +
+ OK. Taking into account the probability of such a name clash, I think it is a low-probability case, but for this reason it can be either ways. I have changed it that the module names are generated first and the definition names are postfixed (or postfix is shifted) in case of name clash.
+
+Rule m) in ~_v2 become rule j) and rule k) (old j)) is extended with module names. No other change in the document!
+
+Pls. review CR6735_resolution_v3.doc.
+
+
+
+
+
+ + + + + + + + + + +
+ (0012166) +
+ Tomas Urban    +
+ 20-06-2014 07:49    +
+ 		+ + + + +
+ I found no problems in the last draft. The proposal resolves the described issue and it is ready to be included in the next version of standard.
+
+
+
+ + + + + + + + + + +
+ (0012167) +
+ Jacob Wieland - Spirent    +
+ 20-06-2014 08:02    +
+ 		+ + + + +
+ Sorry, I have to slightly disagree with Tomas.
+
+In rule k) the sub-sentence
+
+"is identical to the name of the TTCN-3 module the definitions is being placed to" is neither grammatically correct nor does it describe what we intend.
+
+As I understoot it, it should be more on the line of
+
+"is identitcal to the name of the TTCN-3 module generated for its target namespace or one of the modules imported into that module"
+
+
+
+ + + + + + + + + + +
+ (0012172) +
+ Tomas Urban    +
+ 20-06-2014 08:53    +
+ 		+ + + + +
+ I modified the mentioned sub-sentence: the original sentence was made gramatically correct and a clause on imported modules was added as well.
+
+
+
+ + + + + + + + + + +
+ (0012196) +
+ Gyorgy Rethy    +
+ 24-06-2014 09:54    +
+ 		+ + + + +
+ Implemented in master copy V4.5.2.
+
+ + diff --git a/docs/mantis/CR6736.md b/docs/mantis/CR6736.md new file mode 100644 index 0000000000000000000000000000000000000000..f0557836033478d6a32e41dce2a874d78a55cff3 --- /dev/null +++ b/docs/mantis/CR6736.md @@ -0,0 +1,1421 @@ + + + + + + + + + + + + + 0006736: new matching mechanism for binary string types - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006736Part 01: TTCN-3 Core LanguageNew Featurepublic22-04-2014 08:2404-01-2015 19:53
ReporterJacob Wieland - Spirent 
Assigned ToGyorgy Rethy 
PrioritynormalSeveritymajorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.7.1 (published 2015-06)Fixed in Versionv4.7.1 (published 2015-06) 
Clause Reference(s)Appendix B
Source (company - Author)Testing Technologies - Jacob Wieland
Summary0006736: new matching mechanism for binary string types
DescriptionLots of protocols carry payloads. This leads to complicated check(receive)->decvalue->match->receive constructions which we encounter more and more frequently.
+
+Assuming, we have a type
+
+type record R {
+   // ... headers
+   // ...
+   octetstring payload
+}
+
+and we want to receive an R carrying a payload whose decoded value matches a template t of type T.
+
+This can, at the moment, be achieved by something like the following:
+
+template T t := ...;
+template R r := ...;
+
+var octetstring payload;
+var T decoded_payload;
+alt{
+[] p.check(receive(r)) -> value (payload := payload) {
+   if (decvalue(oct2bit(payload), decoded_payload) == 0) {
+     if (match(decoded_payload, t) {
+       p.receive;
+     }
+   }
+}
+
+We propose a new matching mechanism which can achieve the same in a much more convenient (and compositional manner, in case the payload again contains a payload).
+
+The syntax of this new matching mechanism would be simply:
+
+match(t)
+
+where t is the template to be matched.
+
+This matching mechanism would be usable for all octetstring or bitstring values/fields and would match if and only if the value can be decoded successfully to the type of template t and the decoded value matches template t.
+
+In that case, the above code can be shortened to:
+
+p.receive(modifies r := { payload := match(t) });
+
+For even more convenience, assignment of the decoded field could be allowed to a variable of the same type as the matched template:
+
+p.receive(modifies r := { payload := match(t) }) -> value (decoded_payload := payload);
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0006697closed Gyorgy Rethy Missing functionality to check absence of an object 
related to 0006783closed Gyorgy Rethy Wrong syntax to save exception parameters 
Attached Filesdocx CR6736_v1.docx (80,093) 18-06-2014 15:18
http://oldforge.etsi.org/mantis/file_download.php?file_id=3055&type=bug
docx CR6736_v2.docx (83,724) 19-06-2014 08:10
http://oldforge.etsi.org/mantis/file_download.php?file_id=3056&type=bug
docx CR6736_v3.docx (87,440) 19-06-2014 15:35
http://oldforge.etsi.org/mantis/file_download.php?file_id=3059&type=bug
docx CR6736_v4.docx (89,856) 19-06-2014 17:00
http://oldforge.etsi.org/mantis/file_download.php?file_id=3063&type=bug
docx CR6736_v5.docx (118,934) 06-10-2014 14:43
http://oldforge.etsi.org/mantis/file_download.php?file_id=3084&type=bug
docx CR6736_v6.docx (120,760) 09-10-2014 12:20
http://oldforge.etsi.org/mantis/file_download.php?file_id=3128&type=bug
docx CR6736_v7.docx (126,123) 07-11-2014 11:48
http://oldforge.etsi.org/mantis/file_download.php?file_id=3184&type=bug
Issue History
Date ModifiedUsernameFieldChange
22-04-2014 08:24Jacob Wieland - SpirentNew Issue
15-05-2014 14:08Gyorgy RethyProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
15-05-2014 14:09Gyorgy RethyTarget Version => v4.7.1 (published 2015-06)
17-06-2014 11:35Gyorgy RethyNote Added: 0012100
17-06-2014 11:36Gyorgy RethyAssigned To => Tomas Urban
17-06-2014 11:36Gyorgy RethyStatusnew => assigned
17-06-2014 16:57Tomas UrbanRelationship addedrelated to 0006697
18-06-2014 13:31Tomas UrbanFile Added: CR6673_v1.docx
18-06-2014 13:40Tomas UrbanNote Added: 0012124
18-06-2014 13:40Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
18-06-2014 13:40Tomas UrbanStatusassigned => confirmed
18-06-2014 15:18Tomas UrbanFile Deleted: CR6673_v1.docx
18-06-2014 15:18Tomas UrbanFile Added: CR6736_v1.docx
18-06-2014 19:52Jacob Wieland - SpirentNote Added: 0012134
18-06-2014 19:56Jacob Wieland - SpirentNote Edited: 0012134bug_revision_view_page.php?bugnote_id=12134#r41
19-06-2014 08:10Tomas UrbanFile Added: CR6736_v2.docx
19-06-2014 08:12Tomas UrbanNote Added: 0012138
19-06-2014 15:35Gyorgy RethyFile Added: CR6736_v3.docx
19-06-2014 15:39Gyorgy RethyNote Added: 0012152
19-06-2014 15:39Gyorgy RethyAssigned ToGyorgy Rethy => Tomas Urban
19-06-2014 15:39Gyorgy RethyStatusconfirmed => assigned
19-06-2014 15:40Gyorgy RethyNote Edited: 0012152bug_revision_view_page.php?bugnote_id=12152#r48
19-06-2014 16:57Tomas UrbanFile Added: CR6736_v4.docx
19-06-2014 17:00Tomas UrbanFile Deleted: CR6736_v4.docx
19-06-2014 17:00Tomas UrbanFile Added: CR6736_v4.docx
19-06-2014 17:01Tomas UrbanNote Added: 0012158
19-06-2014 17:01Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
19-06-2014 17:01Tomas UrbanStatusassigned => confirmed
20-06-2014 08:16Jacob Wieland - SpirentNote Added: 0012169
20-06-2014 08:42Tomas UrbanNote Added: 0012171
20-06-2014 14:13Jacob Wieland - SpirentNote Added: 0012189
06-10-2014 10:30Gyorgy RethyAssigned ToGyorgy Rethy => Tomas Urban
06-10-2014 10:30Gyorgy RethyStatusconfirmed => assigned
06-10-2014 10:34Gyorgy RethyNote Added: 0012220
06-10-2014 14:36Tomas UrbanFile Added: CR6736_v5.docx
06-10-2014 14:42Tomas UrbanFile Deleted: CR6736_v5.docx
06-10-2014 14:43Tomas UrbanFile Added: CR6736_v5.docx
06-10-2014 14:44Tomas UrbanNote Added: 0012232
06-10-2014 14:44Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
06-10-2014 14:44Tomas UrbanStatusassigned => confirmed
06-10-2014 16:50Jacob Wieland - SpirentNote Added: 0012240
08-10-2014 09:22Gyorgy RethyAssigned ToGyorgy Rethy => Jens Grabowski
08-10-2014 09:23Gyorgy RethyNote Added: 0012267
08-10-2014 09:23Gyorgy RethyNote Edited: 0012267bug_revision_view_page.php?bugnote_id=12267#r75
08-10-2014 14:08Jens GrabowskiNote Added: 0012284
08-10-2014 14:09Jens GrabowskiStatusconfirmed => resolved
08-10-2014 14:09Jens GrabowskiResolutionopen => fixed
08-10-2014 14:09Jens GrabowskiAssigned ToJens Grabowski => Gyorgy Rethy
09-10-2014 12:16Axel RennochNote Added: 0012317
09-10-2014 12:16Axel RennochStatusresolved => feedback
09-10-2014 12:16Axel RennochResolutionfixed => reopened
09-10-2014 12:20Axel RennochFile Added: CR6736_v6.docx
09-10-2014 12:21Axel RennochNote Added: 0012318
09-10-2014 12:21Axel RennochStatusfeedback => assigned
09-10-2014 12:22Axel RennochNote Added: 0012319
09-10-2014 12:22Axel RennochStatusassigned => confirmed
09-10-2014 14:13Tomas UrbanRelationship addedrelated to 0006783
10-10-2014 11:52Thilo LauerNote Added: 0012360
10-10-2014 12:02Jacob Wieland - SpirentNote Added: 0012362
10-10-2014 12:06Tomas UrbanNote Added: 0012363
10-10-2014 12:13Jacob Wieland - SpirentNote Added: 0012364
10-10-2014 12:15Jacob Wieland - SpirentNote Edited: 0012364bug_revision_view_page.php?bugnote_id=12364#r87
10-10-2014 13:46Jacob Wieland - SpirentNote Added: 0012366
03-11-2014 10:23Gyorgy RethyNote Added: 0012371
03-11-2014 10:23Gyorgy RethyAssigned ToGyorgy Rethy => Tomas Urban
04-11-2014 11:46Tomas UrbanNote Added: 0012393
04-11-2014 12:00Jacob Wieland - SpirentNote Added: 0012394
04-11-2014 16:24Tomas UrbanNote Added: 0012407
05-11-2014 08:47Tomas UrbanNote Added: 0012414
05-11-2014 08:47Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
07-11-2014 11:46Gyorgy RethyNote Added: 0012490
07-11-2014 11:48Gyorgy RethyFile Added: CR6736_v7.docx
07-11-2014 11:50Gyorgy RethyAssigned ToGyorgy Rethy => Tomas Urban
07-11-2014 12:29Tomas UrbanNote Added: 0012491
07-11-2014 12:29Tomas UrbanStatusconfirmed => resolved
07-11-2014 12:29Tomas UrbanFixed in Version => v4.7.1 (published 2015-06)
07-11-2014 12:29Tomas UrbanResolutionreopened => fixed
07-11-2014 12:30Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
07-11-2014 12:30Tomas UrbanStatusresolved => feedback
07-11-2014 12:30Tomas UrbanResolutionfixed => reopened
07-11-2014 12:30Tomas UrbanStatusfeedback => resolved
17-11-2014 13:51Jacob Wieland - SpirentNote Added: 0012506
17-11-2014 13:51Jacob Wieland - SpirentStatusresolved => feedback
17-11-2014 13:51Jacob Wieland - SpirentStatusfeedback => resolved
17-11-2014 13:51Jacob Wieland - SpirentResolutionreopened => fixed
04-01-2015 19:53Gyorgy RethyNote Added: 0012607
04-01-2015 19:53Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0012100) +
+ Gyorgy Rethy    +
+ 17-06-2014 11:35    +
+ 		+ + + + +
+ STF discussion:
+The feature itself is useful. Reusing the match operation with a different semantics is not supported. Instead the syntax like below could be used.
+
+template R r:= {
+  headers :=....,
+  payload := @encoded (t)
+}
+
+template T t:= {....}
+var T v_t;
+
+function f() {
+P.receive(r) -> value (v_t := @decoded(payload)); /*will match decoded r, decode the payload field and match the decoded payload field against t; decoded payload is stored*/
+
+
+
+ + + + + + + + + + +
+ (0012124) +
+ Tomas Urban    +
+ 18-06-2014 13:40    +
+ 		+ + + + +
+ Proposal uploaded. There's slight change in the syntax. The existing modifiers are typically used without parentheses enclosing the object being modified, so I decided to use the same coding style. I also added an optional encoding format parameter which is useful for decoding character strings:
+
+template R r:= {
+  headers :=....,
+  bin_payload := @encoded t,
+  txt_payload := @encoded("UTF-8") t2
+}
+
+p.receive(r) -> value (v_bin := @decoded bin_payload, v_txt := @decoded("UTF8") txt_payload);
+
+Please check.
+
+
+
+ + + + + + + + + + +
+ (0012134) +
+ Jacob Wieland - Spirent    +
+ 18-06-2014 19:52    +
(edited on: 18-06-2014 19:56)
+ 		+ + + + +
+ there is a typo: hextring (occurring at least twice)
+
+Also,
+
+( FieldOrTypeReference |
+  @decoded [ "(" Expression ")" ] FieldOrTypeReference [ "," ] )
+
+can be shortened to
+
+( [ @decoded [ "(" Expression ")" ] ] FieldOrTypeReference [ "," ] )
+
+In B.1.2.9, the template to be matched is first called the "decoded template" but later on is referenced as the "decoding target". It should be called consistently the "decoding target".
+
+Otherwise, I'm very happy with the proposal.
+
+
+
+
+
+ + + + + + + + + + +
+ (0012138) +
+ Tomas Urban    +
+ 19-06-2014 08:12    +
+ 		+ + + + +
+ Jacob, thank you for noticing these problems. I corrected the proposal accordingly.
+
+
+
+ + + + + + + + + + +
+ (0012152) +
+ Gyorgy Rethy    +
+ 19-06-2014 15:39    +
(edited on: 19-06-2014 15:40)
+ 		+ + + + +
+ Technically OK with me.
+
+Results of my review and our verbal discussions with Tomas during it are captured in CR6736_v3.docx. During the review - that was based on CR6736_v1.docx - CR6736_v2.docx has been uploaded. Tomas, pls. review my output document CR6736_v3.docx, and also merge the changes between CR6736_v1.docx and CR6736_v2.docx into it.
+
+
+
+
+
+ + + + + + + + + + +
+ (0012158) +
+ Tomas Urban    +
+ 19-06-2014 17:01    +
+ 		+ + + + +
+ I merged the documents and made several minor changes in the examples concerning the receive operation. Please check.
+
+
+
+ + + + + + + + + + +
+ (0012169) +
+ Jacob Wieland - Spirent    +
+ 20-06-2014 08:16    +
+ 		+ + + + +
+ Just to be thorough, isn't the @decoded access missing for procedure-based communication (param assignments)? Sure, it's not as likely that a parameter may contain an encoded payload, but it's not impossible either.
+
+
+
+ + + + + + + + + + +
+ (0012171) +
+ Tomas Urban    +
+ 20-06-2014 08:42    +
+ 		+ + + + +
+ It doesn't make much sence, because currently you cannot assign a parameter field, only the whole parameter.
+
+
+
+ + + + + + + + + + +
+ (0012189) +
+ Jacob Wieland - Spirent    +
+ 20-06-2014 14:13    +
+ 		+ + + + +
+ of course, even the whole parameter could be a payload
+
+
+
+ + + + + + + + + + +
+ (0012220) +
+ Gyorgy Rethy    +
+ 06-10-2014 10:34    +
+ 		+ + + + +
+ It sounds reasonable that a signature parameter and also a return value may also contain encoded data.
+
+
+
+ + + + + + + + + + +
+ (0012232) +
+ Tomas Urban    +
+ 06-10-2014 14:44    +
+ 		+ + + + +
+ Support for @decoded in procedure-based communication added to the proposal.
+Please check.
+
+
+
+ + + + + + + + + + +
+ (0012240) +
+ Jacob Wieland - Spirent    +
+ 06-10-2014 16:50    +
+ 		+ + + + +
+ Looks fine.
+
+
+
+ + + + + + + + + + +
+ (0012267) +
+ Gyorgy Rethy    +
+ 08-10-2014 09:23    +
+ 		+ + + + +
+ Jens, make final cross-check pls.
+
+
+
+
+
+ + + + + + + + + + +
+ (0012284) +
+ Jens Grabowski    +
+ 08-10-2014 14:08    +
+ 		+ + + + +
+ Ok for me
+
+
+
+ + + + + + + + + + +
+ (0012317) +
+ Axel Rennoch    +
+ 09-10-2014 12:16    +
+ 		+ + + + +
+ reopen to add correctioin/changes from CR6783
+
+
+
+ + + + + + + + + + +
+ (0012318) +
+ Axel Rennoch    +
+ 09-10-2014 12:21    +
+ 		+ + + + +
+ updated getreply syntax due to CR6783
+
+
+
+ + + + + + + + + + +
+ (0012319) +
+ Axel Rennoch    +
+ 09-10-2014 12:22    +
+ 		+ + + + +
+ updated after reopening due to CR6783 discussion/solution
+
+
+
+ + + + + + + + + + +
+ (0012360) +
+ Thilo Lauer    +
+ 10-10-2014 11:52    +
+ 		+ + + + +
+ TTCN-3 already contains anything you need to handle payloads as shown below.
+
+Therefore we strongly oppose to the @encode/@decode modifier solution,
+as it hides relevant issues from the TTCN-3 users (TTCN was originally designed to make issues obvious. This was one reason why TTCN does not has implicit type conversions e.g. when assigning an integer value to a float variable)
+
+If you simply define an altstep e.g. matchPayload and a template e.g. t_payload you get anything you need! And a few lines of TTCN-3 code make it obvious for TTCN-3 users what is really happening!
+
+What is the need to make TTCN-3 more and more complex by @modifiers ???
+
+The modifiers @encode / @decode will add additional complexity to the runtime system of compilers and it will require some effort to explain it to normal TTCN-3 users.
+
+This code does the task pretty well - and it makes it obvious to the TTCN-3 user, what is really done:
+
+type record R {
+   // ... headers
+   // ...
+   octetstring payload
+}
+
+template T t := ...;
+template R r := ...;
+template R r_payload(T t):= {
+   // ... headers
+   // ...
+   payload:=bit2oct(encvalue(t));
+}
+
+altstep matchPayload(R r, inout T t) runs on MyMTC
+{
+  var octetstring v_payload;
+  var T v_decoded_payload;
+  [] p.check(receive(r)) -> value (v_payload := r.payload) {
+     if (decvalue(oct2bit(v_payload), v_decoded_payload) == 0) {
+       if (match(v_decoded_payload, t) {
+         p.receive;
+         t:=v_decoded_payload;
+       }
+     }
+}
+
+// use, send direction
+p.send(r_payload(t));
+
+// use, receive direction
+matchPayload(r,t);
+
+alt {
+    [] matchPayload(r,t) {...}
+}
+
+
+
+ + + + + + + + + + +
+ (0012362) +
+ Jacob Wieland - Spirent    +
+ 10-10-2014 12:02    +
+ 		+ + + + +
+ Forcing the user to write the same (obviously quite complicated) function over and over again for every type is a clear sign that the language is in need of a feature. This new feature shall be introduced here. Of course, as with any feature, no one is forcing any user to use it.
+
+Additionally, your approach is not compositional as the the proposal is. (i.e. it cannot deal with multiple-envelope-layers in a simple,readable way as the proposed feature does).
+
+
+
+ + + + + + + + + + +
+ (0012363) +
+ Tomas Urban    +
+ 10-10-2014 12:06    +
+ 		+ + + + +
+ You forget to add repeat statement to your code:
+...
+       if (match(v_decoded_payload, t) {
+         p.receive;
+         t:=v_decoded_payload;
+       } else {
+         repeat;
+       }
+...
+
+Now compare it to the proposed solution:
+type record R {
+   // ... headers
+   // ...
+   octetstring payload
+}
+
+template T t := ...;
+template R r := ...;
+template R r_payload(T t):= {
+   // ... headers
+   // ...
+   payload := t ;
+}
+
+// use, send direction
+p.send(r_payload(encvalue(t)));
+
+// use, receive direction
+p.receive(r_payload(@encoded t))
+
+alt {
+    [] p.receive(r_payload(@encoded t)) {...}
+}
+
+We save a lot of code this way! Besides, I am quite sure that the proposed solution produced much more readable solution.
+
+Your code also has a serious drawback. Activating the p.check branch terminates processing of the snapshot, meaning that the following branches and defaults of the alt statement cannot be processed at all. That means that you cannot match any other payload types within this alt. Our proposal doesn't suffer from this issue.
+
+
+
+ + + + + + + + + + +
+ (0012364) +
+ Jacob Wieland - Spirent    +
+ 10-10-2014 12:13    +
(edited on: 10-10-2014 12:15)
+ 		+ + + + +
+ small correction, it would need to be
+
+template R r_payload(template octetstring t) := ...
+
+and
+
+send(r_payload(bit2oct(encvalue(...)))
+
+
+
+
+
+ + + + + + + + + + +
+ (0012366) +
+ Jacob Wieland - Spirent    +
+ 10-10-2014 13:46    +
+ 		+ + + + +
+ Actually, in Thilos workaround-with-existing-features proposal, you would need to disable the guard of the check-branch before doing the repeat, as otherwise, for the next iteration the same code would be called and you would have an endless loop. the value of that guard would need to be added as an inout parameter to the altstep (and you would need one flag for each such altstep).
+
+So, no, though it may be possible in a very complicated (and not quite as powerful and non-composable) way to do the same things in TTCN-3 already, it is in no way near usable or readable.
+
+
+
+ + + + + + + + + + +
+ (0012371) +
+ Gyorgy Rethy    +
+ 03-11-2014 10:23    +
+ 		+ + + + +
+ Please be the 'STF owner' of the issues, let we discuss it at the afternoon.
+
+
+
+ + + + + + + + + + +
+ (0012393) +
+ Tomas Urban    +
+ 04-11-2014 11:46    +
+ 		+ + + + +
+ Result of STF discussion:
+We agree with Thilo that the current core language specification contains enough features to handle encoded payloads. The proposed solution doesn't impose any restrictions on these features and users can still use them in their code (if they don't want to learn new features or consider that the @encoded/@decoded mechanism hides something important).
+
+We disagree with the statement that the proposed feature "hides relevant issues from the TTCN-3 users". Both the @encoded matching mechanism and the @decoded modifier occuring in redirect assignments are precisely specified and any user can check the specification to find out what exactly these modifiers do. In case our description is not precise enough or contains ambiguities, we would like to know where precisely they are in order to correct them.
+
+We cannot accept the argument that "the modifiers @encode / @decode will add additional complexity to the runtime system of compilers and it will require some effort to explain it to normal TTCN-3 users". If we accepted it, we couldn't add any new features to the language specification, because any new addition suffer from this issue. Besides, the proposed addition to the specification only formalizes what was requested by TTCN-3 users. The author of the CR was not the only one who requested a feature simplifying handling of encoded payloads.
+
+The main reason for the proposed change is code readability and execution efficiency. It can be demonstrated on a simple example. In this example, the testing code can receive two envelope messages (Envelope1, Envelope2) with different payloads (Payload1 and Payload2 in Envelope1, Payload3 and Payload4 in Envelope2). In order to make the example more realistic, it contains a default reacting to unknown messages and response timeout. The example contains a common part and two variants of the testing code: the first one using the proposed features and the second one using already existing features.
+
+// Common part
+module Common {
+
+  type record Envelope1 {
+     integer contentId,
+     octetstring payload
+  }
+
+  type record Envelope2 {
+     charstring contentId,
+     octetstring payload
+  }
+
+  type record Payload1 {}
+  type record Payload2 {}
+  type record Payload3 {}
+  type record Payload4 {}
+
+  template Payload1 m_payload1 := {}
+  template Payload2 m_payload2 := {}
+  template Payload3 m_payload3 := {}
+  template Payload4 m_payload4 := {}
+
+  type port P message {
+    in Envelope1, Envelope2
+  }
+
+  type component Comp {
+    port P p;
+    timer tc_maxWait := 10.0;
+  }
+
+  altstep a_default() runs on Comp {
+    [] tc_maxWait.timeout {
+       setverdict(fail, "No message");
+       mtc.stop;
+    }
+    [] p.receive {
+       setverdict(fail, "Unexpected message");
+       mtc.stop;
+    }
+  }
+}
+
+// Proposed solution
+module ProposedSolution {
+  import from Common all;
+
+  template Envelope1 m_envelope1(integer p_contentId, template octetstring p_payload) {
+    contentId := p_contentId,
+    payload := p_payload
+  }
+
+  template Envelope2 m_envelope2(charstring p_contentId, template octetstring p_payload) {
+    contentId = p_contentId,
+    payload := p_payload
+  }
+
+  testcase TC_01() runs on Comp {
+    var Payload1 v_payload1;
+    var Payload2 v_payload2;
+    var Payload3 v_payload3;
+    var Payload4 v_payload4;
+    activate(a_default());
+    tc_maxWait.start;
+    alt {
+      [] p.receive(m_envelope1(1, @encoded(m_payload1))) -> value (v_payload1 := @decoded payload) { }
+      [] p.receive(m_envelope1(2, @encoded(m_payload2))) -> value (v_payload2 := @decoded payload) { }
+      [] p.receive(m_envelope2("msg3", @encoded(m_payload3))) -> value (v_payload3 := @decoded payload) { }
+      [] p.receive(m_envelope2("msg4", @encoded(m_payload4))) -> value (v_payload4 := @decoded payload) { }
+    }
+  }
+}
+
+// Current solution
+module CurrentSolution {
+  import from Common all;
+
+  testcase TC_01() runs on Comp {
+    var Payload1 v_payload1;
+    var Payload2 v_payload2;
+    var Payload3 v_payload3;
+    var Payload4 v_payload4;
+    var octetstring v_encPayload;
+    var boolean v_guard := true;
+    var integer v_numContentId;
+    var charstring v_strContentId;
+    activate(a_default());
+    tc_maxWait.start;
+    alt {
+      [v_guard] p.check(receive(Envelope1:?)
+         -> value (v_numContentId := contentId, v_encPayload := payload)) {
+         var Payload1 v_decodedPayload1;
+         var Payload2 v_decodedPayload2;
+         var bitstring v_payloadBits := oct2bit(v_encPayload);
+         if (v_numContentId == 1 and decvalue(v_payloadBits, v_decodedPayload1) == 0) {
+           if (match(v_decodedPayload1, m_payload1)) {
+             p.receive;
+             v_payload1 := v_decodedPayload1;
+             v_guard := false;
+           }
+         } else if (v_numContentId == 2 and decvalue(v_payloadBits, v_decodedPayload2) == 0) {
+           if (match(v_decodedPayload2, m_payload2)) {
+             p.receive;
+             v_payload2 := v_decodedPayload2;
+             v_guard := false;
+           }
+         }
+         if (v_guard) {
+            v_guard := false;
+            repeat;
+         }
+      }
+      [v_guard] p.check(receive(Envelope2:?)
+         -> value (v_strContentId := contentId, v_encPayload := payload)) {
+         var Payload3 v_decodedPayload3;
+         var Payload4 v_decodedPayload4;
+         var bitstring v_payloadBits := oct2bit(v_encPayload);
+         if (v_strContentId == "msg3" and decvalue(v_payloadBits, v_decodedPayload3) == 0) {
+           if (match(v_decodedPayload3, m_payload3)) {
+             p.receive;
+             v_payload3 := v_decodedPayload3;
+             v_guard := false;
+           }
+         } else if (v_strContentId == "msg4" and decvalue(v_payloadBits, v_decodedPayload4) == 0) {
+           if (match(v_decodedPayload4, m_payload4)) {
+             p.receive;
+             v_payload2 := v_decodedPayload4;
+             v_guard := false;
+           }
+         }
+         if (v_guard) {
+            v_guard := false;
+            repeat;
+         }
+      }
+    }
+  }
+}
+
+
+
+ + + + + + + + + + +
+ (0012394) +
+ Jacob Wieland - Spirent    +
+ 04-11-2014 12:00    +
+ 		+ + + + +
+ The long version does not work with only one guard flag. You need one guard per alternative.
+
+
+
+ + + + + + + + + + +
+ (0012407) +
+ Tomas Urban    +
+ 04-11-2014 16:24    +
+ 		+ + + + +
+ It depends on encoding. In this particular example I assumed that Envelope1 and Envelope2 have distinct encoding. Thus, if a message is succesfully decoded as Envelope1, it cannot be decoded as Envelope2 when repeat is called. However, I admit that in many cases you will need one guard per alternative.
+
+
+
+ + + + + + + + + + +
+ (0012414) +
+ Tomas Urban    +
+ 05-11-2014 08:47    +
+ 		+ + + + +
+ Technically there doesn't seem to be any problem in details anymore, but Thilo opposes the whole idea. As time is running out, we should decide if we include the proposed changes to the standard and risk that it won't pass the acceptance procedure or postpone it to the next year. I personally think we have enough arguments to decide in favour of the proposed solution.
+
+
+
+ + + + + + + + + + +
+ (0012490) +
+ Gyorgy Rethy    +
+ 07-11-2014 11:46    +
+ 		+ + + + +
+ As discussed with Tomas, a matching mechanism is more appropriate as a modifier, as in fact we are not modifying an existing matching but defining a new one. For the consistency the price will be a new keyword. Also the name has been changed - after long discussion - to decmatch. MatchingDecodedContent is the now name of the matching mechanism.
+
+See updated resolution proposal in CR6736_v7.docx.
+
+Please review.
+
+
+
+ + + + + + + + + + +
+ (0012491) +
+ Tomas Urban    +
+ 07-11-2014 12:29    +
+ 		+ + + + +
+ Proposal reviewed. The proposed changes are ready to be added to the next version of the core language specification.
+
+Note for Jacob: please check the text too if you have time.
+
+
+
+ + + + + + + + + + +
+ (0012506) +
+ Jacob Wieland - Spirent    +
+ 17-11-2014 13:51    +
+ 		+ + + + +
+ In principle, it's fine with me. I still don"t like the new keyword, but I can live with it.
+
+
+
+ + + + + + + + + + +
+ (0012607) +
+ Gyorgy Rethy    +
+ 04-01-2015 19:53    +
+ 		+ + + + +
+ Added to draft V4.6.3
+
+ + diff --git a/docs/mantis/CR6737.md b/docs/mantis/CR6737.md new file mode 100644 index 0000000000000000000000000000000000000000..fda124217bb7594430597cb39d99e81b1fc981ae --- /dev/null +++ b/docs/mantis/CR6737.md @@ -0,0 +1,218 @@ + + + + + + + + + + + + + 0006737: Allow equality operator also on omit symbol and templates with restriction omit. - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Advanced Matching (ES 203 022)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006737Ext Pack: Advanced Matching (ES 203 022)New Featurepublic22-04-2014 12:2524-12-2016 13:25
ReporterJacob Wieland - Spirent 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv1.1.1 (published 2017-07)Fixed in Versionv1.1.1 (published 2017-07) 
Clause Reference(s)7.1.3
Source (company - Author)Testing Technologies - Jacob Wieland
TS version
Summary0006737: Allow equality operator also on omit symbol and templates with restriction omit.
DescriptionAt the moment, two fields can be compared and they are equal if both are omit and not equal if one is omit and the other is not.
+
+This definition should be enlarged so that equality can be tested against the explicit omit-symbol (i.e. x.f == omit) and against templates with restriction omit (i.e. x.f == t, where t is an omit-template).
+
+Basically, an omit-template should be treatable always like a field reference.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR6737.docx (125,510) 19-08-2016 14:58
http://oldforge.etsi.org/mantis/file_download.php?file_id=3504&type=bug
Issue History
Date ModifiedUsernameFieldChange
22-04-2014 12:25Jacob Wieland - SpirentNew Issue
11-05-2014 20:47Gyorgy RethyProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
18-06-2014 09:11Gyorgy RethyProduct Version => v4.6.1 (published 2014-06)
18-06-2014 09:11Gyorgy RethyTarget Version => v4.7.1 (published 2015-06)
03-11-2014 14:14Gyorgy RethyNote Added: 0012378
03-11-2014 15:33Jacob Wieland - SpirentNote Added: 0012380
06-11-2014 09:19Gyorgy RethyTarget Versionv4.7.1 (published 2015-06) => v4.8.1 (ongoing)
03-08-2015 16:34Gyorgy RethyNote Added: 0013043
03-08-2015 16:34Gyorgy RethyAssigned To => Jens Grabowski
03-08-2015 16:34Gyorgy RethyStatusnew => assigned
02-11-2015 15:39Jens GrabowskiNote Added: 0013446
02-11-2015 15:40Jens GrabowskiAssigned ToJens Grabowski => Gyorgy Rethy
03-11-2015 08:03Gyorgy RethyTarget Versionv4.8.1 (ongoing) => Next version (to be defined)
05-11-2015 11:02Gyorgy RethyProjectPart 01: TTCN-3 Core Language => Ext Pack: Advanced Matching (ES 203 022)
05-11-2015 11:07Gyorgy RethyProduct Versionv4.6.1 (published 2014-06) =>
05-11-2015 11:07Gyorgy RethyTarget VersionNext version (to be defined) => v1.1.1 (published 2017-07)
18-07-2016 11:24Jens GrabowskiAssigned ToGyorgy Rethy => Jens Grabowski
15-08-2016 13:18Jens GrabowskiAssigned ToJens Grabowski => Kristóf Szabados
19-08-2016 09:32Jens GrabowskiAssigned ToKristóf Szabados => Jacob Wieland - Spirent
19-08-2016 14:58Jacob Wieland - SpirentFile Added: CR6737.docx
19-08-2016 14:59Jacob Wieland - SpirentNote Added: 0014184
19-08-2016 14:59Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Jens Grabowski
19-08-2016 14:59Jacob Wieland - SpirentStatusassigned => confirmed
17-11-2016 12:38Jens GrabowskiStatusconfirmed => resolved
17-11-2016 12:38Jens GrabowskiResolutionopen => fixed
24-12-2016 13:25Jens GrabowskiStatusresolved => closed
24-12-2016 13:25Jens GrabowskiFixed in Version => v1.1.1 (published 2017-07)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0012378) +
+ Gyorgy Rethy    +
+ 03-11-2014 14:14    +
+ 		+ + + + +
+ For values:
+if (isbound(x.f) and ispresent(x.f)) { /* do something */ }
+and
+if (isbound(x.f) {
+  if (x.f==omit) { /* do something */ }
+}
+
+would give the same result; isbound shall be used in both cases anyway, if there is a possibility that x.f may be uninitialized and may be skipped otherwise. In the above case the the whole contsruct for the x.f==omit syntax is more complicated and it could strengthen the frequent misunderstanding that omit is a value (what omit is *not*).
+
+For templates we are introducing a more generic matching checking mechanism, while this syntax would relate to the particular omit case only (but, what it should return for ispresent?)
+
+So, I think, this would be just a syntactical sugar of limited usability, and hence I don't support it.
+
+
+
+ + + + + + + + + + +
+ (0012380) +
+ Jacob Wieland - Spirent    +
+ 03-11-2014 15:33    +
+ 		+ + + + +
+ what about template parameters which may be omit? fields are not the only things you want to check for omit and using the istemplatekind function for this seems heavy-handed to me.
+
+Basically, at the moment I would use a workaround by defining record with an optional field and declaring a constant where that field is omit and then use that field for comparison.
+
+If such a workaround is available, why not allow it directly, I wonder. It might be of "limited usability" but for those who like the usability, it would be much nicer than such nasty workarounds. I don't see the harm in the feature, either.
+
+
+
+ + + + + + + + + + +
+ (0013043) +
+ Gyorgy Rethy    +
+ 03-08-2015 16:34    +
+ 		+ + + + +
+ STF discussion 03-08-2015: Discussion tends to if for the specific case when a value field is matched to omit (literal, template(omit)), should this be shorthanded by using the "==". I.e. match(x.f,omit) -> x.f==omit?
+
+
+
+ + + + + + + + + + +
+ (0013446) +
+ Jens Grabowski    +
+ 02-11-2015 15:39    +
+ 		+ + + + +
+ CR should be resolved next year as part of the new Extension Package on "Advanced matching".
+
+
+
+ + + + + + + + + + +
+ (0014184) +
+ Jacob Wieland - Spirent    +
+ 19-08-2016 14:59    +
+ 		+ + + + +
+ please review
+
+ + diff --git a/docs/mantis/CR6738.md b/docs/mantis/CR6738.md new file mode 100644 index 0000000000000000000000000000000000000000..31640323351cf1f6786e635742a649166bcd591b --- /dev/null +++ b/docs/mantis/CR6738.md @@ -0,0 +1,149 @@ + + + + + + + + + + + + + 0006738: Float values in examples are wrong due to TTCN3 standard - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006738Part 09: Using XML with TTCN-3Editorialpublic23-04-2014 09:2326-01-2015 11:27
ReporterBostjan Pintar 
Assigned To 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionno change required 
PlatformOSOS Version
Product Versionv4.5.1 (published 2013-04) 
Target Versionv4.6.1 (published 2015-06)Fixed in Versionv4.5.2 (interim 2014) 
Clause Reference(s)6.1.7; 6.1.8; 6.1.9; 6.1.10
For STF discussion
Source (company - Author)     STF475
Summary0006738: Float values in examples are wrong due to TTCN3 standard
DescriptionWithin ETSI ES 201 873-1(clause 6.1.0) it is written that Floating point values can be expressed by using two forms of value notations. First is the decimal notation with a dot in a sequence of numbers. To get correct transformation from XSD to TTCN3 following clauses within ETSI ES 201 873-9 should be adopted as proposed below:
+
+clause 6.1.7
+line within EXAMPLE 2
+<minInclusive value="-5"/> should be changed into <minInclusive value="-5.0"/>
+
+clause 6.1.8
+line within EXAMPLE 2
+<maxInclusive value="-5"/> should be changed into <maxInclusive value="-5.0"/>
+
+clause 6.1.9
+line within EXAMPLE 2:
+<minExclusive value="-5"/> should be changed into <minExclusive value="-5.0"/>
+<minExclusive value="-6"/> should be changed into <minExclusive value="-6.0"/>
+
+clause 6.1.10
+line within EXAMPLE 2:
+<maxExclusive value="-5"/> should be changed into <maxExclusive value="-5.0"/>
+<maxExclusive value="-4"/> should be changed into <maxExclusive value="-4".0/>
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
23-04-2014 09:23Bostjan PintarNew Issue
23-04-2014 13:02Jacob Wieland - SpirentNote Added: 0012049
24-04-2014 07:35Bostjan PintarNote Added: 0012050
24-04-2014 07:38Tomas UrbanNote Added: 0012051
24-04-2014 07:38Tomas UrbanStatusnew => closed
24-04-2014 07:38Tomas UrbanResolutionopen => no change required
24-04-2014 07:38Tomas UrbanFixed in Version => v4.6.1 (published 2015-06)
20-06-2014 11:45Gyorgy RethyTarget Version => v4.6.1 (published 2015-06)
24-06-2014 08:59Gyorgy RethyFixed in Versionv4.6.1 (published 2015-06) => v4.5.2 (interim 2014)
26-01-2015 11:20Gyorgy RethyFixed in Versionv4.5.2 (interim 2014) => v4.6.1 (published 2015-06)
26-01-2015 11:27Gyorgy RethyFixed in Versionv4.6.1 (published 2015-06) => v4.5.2 (interim 2014)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0012049) +
+ Jacob Wieland - Spirent    +
+ 23-04-2014 13:02    +
+ 		+ + + + +
+ for the XSD parts, only the XSD restrictions on float values apply, not the TTCN-3 restrictions. The mapping must take care to map to correct TTCN-3 float literals if the value is not a valid TTCN-3 literal (by adding .0).
+
+
+
+ + + + + + + + + + +
+ (0012050) +
+ Bostjan Pintar    +
+ 24-04-2014 07:35    +
+ 		+ + + + +
+ Issue was discussed on STF475 and we agree on the comment.
+
+
+
+ + + + + + + + + + +
+ (0012051) +
+ Tomas Urban    +
+ 24-04-2014 07:38    +
+ 		+ + + + +
+ Closing. No change in the specification required.
+
+ + diff --git a/docs/mantis/CR6739.md b/docs/mantis/CR6739.md new file mode 100644 index 0000000000000000000000000000000000000000..e00fb1d95a2e0d47f6034d1889a4c8ffeef04f0c --- /dev/null +++ b/docs/mantis/CR6739.md @@ -0,0 +1,165 @@ + + + + + + + + + + + + + 0006739: Example on restricted anonymous simple type - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006739Part 09: Using XML with TTCN-3Clarificationpublic23-04-2014 09:4331-12-2014 15:38
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.5.1 (published 2013-04) 
Target Versionv4.6.1 (published 2015-06)Fixed in Versionv4.6.1 (published 2015-06) 
Clause Reference(s)7.5.1
For STF discussion
Source (company - Author)STF 475
Summary0006739: Example on restricted anonymous simple type
DescriptionIn the section 7.5.1, there's an example that should demonstrate conversion of an anonymous simple type. The example text states that the inner simpleType is in bold, but there's no bold section in the XSD and the XSD doesn't seem to contain the inner part either (only the outer simpleType named "e19" type is present).
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR6739_resolution_v1.doc (87,552) 22-12-2014 11:53
http://oldforge.etsi.org/mantis/file_download.php?file_id=3205&type=bug
doc CR6739_resolution_v1a.doc (88,576) 29-12-2014 15:42
http://oldforge.etsi.org/mantis/file_download.php?file_id=3207&type=bug
Issue History
Date ModifiedUsernameFieldChange
23-04-2014 09:43Tomas UrbanNew Issue
15-06-2014 17:44Gyorgy RethyAssigned To => Gyorgy Rethy
15-06-2014 17:44Gyorgy RethyStatusnew => assigned
15-06-2014 18:03Gyorgy RethyTarget Version => v4.6.1 (published 2015-06)
07-11-2014 11:59Gyorgy RethyAssigned ToGyorgy Rethy => Axel Rennoch
22-12-2014 11:53Gyorgy RethyFile Added: CR6739_resolution_v1.doc
22-12-2014 11:54Gyorgy RethyNote Added: 0012570
22-12-2014 11:54Gyorgy RethyStatusassigned => confirmed
29-12-2014 15:42Axel RennochFile Added: CR6739_resolution_v1a.doc
29-12-2014 15:42Axel RennochNote Added: 0012590
29-12-2014 15:43Axel RennochNote Added: 0012591
29-12-2014 15:43Axel RennochAssigned ToAxel Rennoch => Gyorgy Rethy
29-12-2014 15:43Axel RennochStatusconfirmed => acknowledged
30-12-2014 18:45Gyorgy RethyStatusacknowledged => resolved
30-12-2014 18:45Gyorgy RethyFixed in Version => v4.6.1 (published 2015-06)
30-12-2014 18:45Gyorgy RethyResolutionopen => fixed
31-12-2014 15:38Gyorgy RethyNote Added: 0012604
31-12-2014 15:38Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0012570) +
+ Gyorgy Rethy    +
+ 22-12-2014 11:54    +
+ 		+ + + + +
+ Example extended and corrected. Please check in CR6739_resolution_v1.doc
+
+
+
+ + + + + + + + + + +
+ (0012590) +
+ Axel Rennoch    +
+ 29-12-2014 15:42    +
+ 		+ + + + +
+ Modifications are fine, I just corrected two small typos.
+
+
+
+ + + + + + + + + + +
+ (0012591) +
+ Axel Rennoch    +
+ 29-12-2014 15:43    +
+ 		+ + + + +
+ You may set the CR to resolved.
+
+
+
+ + + + + + + + + + +
+ (0012604) +
+ Gyorgy Rethy    +
+ 31-12-2014 15:38    +
+ 		+ + + + +
+ Added to draft V4.5.3
+
+ + diff --git a/docs/mantis/CR6742.md b/docs/mantis/CR6742.md new file mode 100644 index 0000000000000000000000000000000000000000..f8b3755a685e30194662c40940c513d6f5938b04 --- /dev/null +++ b/docs/mantis/CR6742.md @@ -0,0 +1,170 @@ + + + + + + + + + + + + + 0006742: yearExpansion not correctly defined - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006742Part 09: Using XML with TTCN-3Technicalpublic23-04-2014 14:4031-12-2014 15:28
ReporterBostjan Pintar 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.5.1 (published 2013-04) 
Target Versionv4.6.1 (published 2015-06)Fixed in Versionv4.6.1 (published 2015-06) 
Clause Reference(s)6.5
For STF discussion
Source (company - Author)STF475
Summary0006742: yearExpansion not correctly defined
DescriptionyearExpansion within clause 6.5 is not defined correctly. Charstring value "(-([1-9][0-9]#(0,))#(,1))#(,1)" need to be replaced with correct one.
+
+The format of xsd:gYear is CCYY. No left truncation is allowed. To represent years later than 9999, additional digits can be added to the left of the year value. To represent years before 0001, a preceding minus sign ("-") is allowed.(possible values are -1999, 11999)
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx draft-res-6742-v1.docx (26,271) 06-11-2014 12:37
http://oldforge.etsi.org/mantis/file_download.php?file_id=3174&type=bug
Issue History
Date ModifiedUsernameFieldChange
23-04-2014 14:40Bostjan PintarNew Issue
15-06-2014 17:43Gyorgy RethyAssigned To => Gyorgy Rethy
15-06-2014 17:43Gyorgy RethyStatusnew => assigned
15-06-2014 17:43Gyorgy RethyTarget Version => v4.6.1 (published 2015-06)
05-11-2014 09:22Gyorgy RethyAssigned ToGyorgy Rethy => Axel Rennoch
05-11-2014 09:25Gyorgy RethyNote Added: 0012415
05-11-2014 14:19Tomas UrbanNote Added: 0012434
06-11-2014 10:37Gyorgy RethyStatusassigned => confirmed
06-11-2014 12:37Axel RennochFile Added: draft-res-6742-v1.docx
06-11-2014 12:38Axel RennochNote Added: 0012461
06-11-2014 12:40Axel RennochStatusconfirmed => resolved
06-11-2014 12:40Axel RennochResolutionopen => fixed
31-12-2014 15:28Gyorgy RethyNote Added: 0012603
31-12-2014 15:28Gyorgy RethyStatusresolved => closed
31-12-2014 15:28Gyorgy RethyAssigned ToAxel Rennoch => Gyorgy Rethy
31-12-2014 15:28Gyorgy RethyFixed in Version => v4.6.1 (published 2015-06)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0012415) +
+ Gyorgy Rethy    +
+ 05-11-2014 09:25    +
+ 		+ + + + +
+ Axel, pls. check. Note that yearExpansion is defining the optional additional digits and minus sign, in date/time patterns it is used together with year like
+"{yearExpansion}{year} ..."
+
+
+
+ + + + + + + + + + +
+ (0012434) +
+ Tomas Urban    +
+ 05-11-2014 14:19    +
+ 		+ + + + +
+ The correct approach would be to separate the minus sign from the numbers:
+
+yearExpansion := "-#(,1)([1-9][0-9]#(0,))#(,1)"
+
+
+
+ + + + + + + + + + +
+ (0012461) +
+ Axel Rennoch    +
+ 06-11-2014 12:38    +
+ 		+ + + + +
+ correction considered in 6.5 and annex A
+
+
+
+ + + + + + + + + + +
+ (0012603) +
+ Gyorgy Rethy    +
+ 31-12-2014 15:28    +
+ 		+ + + + +
+ Added to draft V4.5.3
+
+ + diff --git a/docs/mantis/CR6746.md b/docs/mantis/CR6746.md new file mode 100644 index 0000000000000000000000000000000000000000..19c94dbd99619a9775b2c2533ff66b23a0ee6801 --- /dev/null +++ b/docs/mantis/CR6746.md @@ -0,0 +1,137 @@ + + + + + + + + + + + + + 0006746: Inconsistent namespace prefixing in examples - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006746Part 09: Using XML with TTCN-3Editorialpublic24-04-2014 12:0613-01-2015 14:28
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeveritytrivialReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.5.1 (published 2013-04) 
Target Versionv4.6.1 (published 2015-06)Fixed in Versionv4.6.1 (published 2015-06) 
Clause Reference(s)5, 6, 7, 8, C, D
For STF discussion
Source (company - Author)STF 475
Summary0006746: Inconsistent namespace prefixing in examples
DescriptionThe current specification uses different prefix style in the examples. Sometimes the schema namespace ("http://www.w3.org/2001/XMLSchema" [^]) is the default (unprefixed) namespace, but it can have also xsd or xs prefix. The same is valid for the target namespace which is either unprefixed or ns. There might be other variants too as I didn't check the whole document thoroughly.
+
+In my opinion the naming convension should be the same in the whole document. Suitable combinations would be either no prefix for the schema namespace and ns for the local one or xsd for the schema namespace and no prefix for the local one. This convension should be generalized somewhere (maybe in the section 3).
+
+Different naming might be justified in some examples, but if it is the case, the example should contain namespace prefix definitions as well.
+
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
24-04-2014 12:06Tomas UrbanNew Issue
24-04-2014 12:22Tomas UrbanNote Added: 0012053
15-06-2014 17:16Gyorgy RethyAssigned To => Gyorgy Rethy
15-06-2014 17:16Gyorgy RethyStatusnew => assigned
15-06-2014 18:03Gyorgy RethyTarget Version => v4.6.1 (published 2015-06)
04-11-2014 14:09Gyorgy RethyNote Added: 0012402
04-11-2014 14:09Gyorgy RethyStatusassigned => resolved
04-11-2014 14:09Gyorgy RethyFixed in Version => v4.6.1 (published 2015-06)
04-11-2014 14:09Gyorgy RethyResolutionopen => fixed
13-01-2015 14:28Gyorgy RethyNote Added: 0012670
13-01-2015 14:28Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0012053) +
+ Tomas Urban    +
+ 24-04-2014 12:22    +
+ 		+ + + + +
+ In some cases, there are different prefices for one namespace within one example (e.g. 7.5.3, example 2) which is actually an error.
+
+
+
+ + + + + + + + + + +
+ (0012402) +
+ Gyorgy Rethy    +
+ 04-11-2014 14:09    +
+ 		+ + + + +
+ Comment is correct, a unified namespace prefix convention to be used in examples: xsd: for the XSD namespave, ns: for the target namespace. This is to be done during final editing of the draft, to allow using the time of the joint working sessions to work on technical issues.
+
+
+
+ + + + + + + + + + +
+ (0012670) +
+ Gyorgy Rethy    +
+ 13-01-2015 14:28    +
+ 		+ + + + +
+ Implemented in draft V4.6.4
+
+ + diff --git a/docs/mantis/CR6747.md b/docs/mantis/CR6747.md new file mode 100644 index 0000000000000000000000000000000000000000..5c7f3dde5220d0fa6c9e26df17eddec48354506f --- /dev/null +++ b/docs/mantis/CR6747.md @@ -0,0 +1,204 @@ + + + + + + + + + + + + + 0006747: XML documents based on type definitions - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006747Part 09: Using XML with TTCN-3Technicalpublic24-04-2014 12:1731-12-2014 15:25
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.5.1 (published 2013-04) 
Target Versionv4.6.1 (published 2015-06)Fixed in Versionv4.6.1 (published 2015-06) 
Clause Reference(s)7
For STF discussion
Source (company - Author)STF 475
Summary0006747: XML documents based on type definitions
DescriptionThere are several examples where an XML document is based on a XSD type definition (e.g. 7.1.11 example 1, 7.5.2 example 2 etc.). However, such documents won't pass schema validation because nodes on the XML document cannot be based on XSD type definitions but on XSD element definitions.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx draft-res-6747-v1.docx (78,370) 06-11-2014 10:50
http://oldforge.etsi.org/mantis/file_download.php?file_id=3170&type=bug
docx draft-res-6747-v2.docx (79,006) 06-11-2014 12:42
http://oldforge.etsi.org/mantis/file_download.php?file_id=3175&type=bug
Issue History
Date ModifiedUsernameFieldChange
24-04-2014 12:17Tomas UrbanNew Issue
24-04-2014 12:17Tomas UrbanProduct Version => v4.5.1 (published 2013-04)
15-06-2014 17:17Gyorgy RethyAssigned To => Gyorgy Rethy
15-06-2014 17:17Gyorgy RethyStatusnew => assigned
15-06-2014 18:04Gyorgy RethyTarget Version => v4.6.1 (published 2015-06)
05-11-2014 10:11Gyorgy RethyNote Added: 0012418
05-11-2014 10:11Gyorgy RethyAssigned ToGyorgy Rethy => Axel Rennoch
06-11-2014 10:50Axel RennochFile Added: draft-res-6747-v1.docx
06-11-2014 10:52Axel RennochNote Added: 0012453
06-11-2014 10:53Axel RennochNote Added: 0012454
06-11-2014 10:53Axel RennochAssigned ToAxel Rennoch => Tomas Urban
06-11-2014 10:53Axel RennochStatusassigned => acknowledged
06-11-2014 12:42Tomas UrbanFile Added: draft-res-6747-v2.docx
06-11-2014 12:45Tomas UrbanNote Added: 0012462
06-11-2014 12:45Tomas UrbanAssigned ToTomas Urban => Axel Rennoch
06-11-2014 12:45Tomas UrbanStatusacknowledged => confirmed
06-11-2014 12:51Axel RennochStatusconfirmed => resolved
06-11-2014 12:51Axel RennochResolutionopen => fixed
31-12-2014 15:25Gyorgy RethyNote Added: 0012602
31-12-2014 15:25Gyorgy RethyStatusresolved => closed
31-12-2014 15:25Gyorgy RethyAssigned ToAxel Rennoch => Gyorgy Rethy
31-12-2014 15:25Gyorgy RethyFixed in Version => v4.6.1 (published 2015-06)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0012418) +
+ Gyorgy Rethy    +
+ 05-11-2014 10:11    +
+ 		+ + + + +
+ Comment is correct. Please check the examples and prepare corrections where needed (preferred is to add also an element definition of that type).
+
+
+
+ + + + + + + + + + +
+ (0012453) +
+ Axel Rennoch    +
+ 06-11-2014 10:52    +
+ 		+ + + + +
+ all examples in part09 checked and corrections provided in attached file.
+
+
+
+ + + + + + + + + + +
+ (0012454) +
+ Axel Rennoch    +
+ 06-11-2014 10:53    +
+ 		+ + + + +
+ Please have a look if all examples have been corrected where needed.
+
+
+
+ + + + + + + + + + +
+ (0012462) +
+ Tomas Urban    +
+ 06-11-2014 12:45    +
+ 		+ + + + +
+ I made tree changes in the proposal:
+1. I added intendation to places where the element wrapper was added
+2. One incorrect element name in the produced XML was corrected (old error)
+3. I rejected the changes in substitution group. The element wrapper should not be added there, it would make the XSD invalid.
+
+Please review the proposal and if you are fine with it, mark it as resolved.
+
+
+
+ + + + + + + + + + +
+ (0012602) +
+ Gyorgy Rethy    +
+ 31-12-2014 15:25    +
+ 		+ + + + +
+ Added to V4.5.3
+
+ + diff --git a/docs/mantis/CR6748.md b/docs/mantis/CR6748.md new file mode 100644 index 0000000000000000000000000000000000000000..9e596e4a7fb53834eaa8ad31992f17619fc40a6c --- /dev/null +++ b/docs/mantis/CR6748.md @@ -0,0 +1,63 @@ + + + + + + + + + + + + + 0006748: Missing variants in defivation by union example 3 - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006748Part 09: Using XML with TTCN-3Editorialpublic24-04-2014 12:3126-01-2015 11:28
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeveritytrivialReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.5.1 (published 2013-04) 
Target Versionv4.6.1 (published 2015-06)Fixed in Versionv4.5.2 (interim 2014) 
Clause Reference(s)7.5.3
For STF discussion
Source (company - Author)STF 475
Summary0006748: Missing variants in defivation by union example 3
DescriptionThe example 3 on derivation by union (mixed content) doesn't contain "name as" variants for the first and second alternative. These variants are mandatory according to the rules defined in 5.2.2, because the identifiers have been modified during name transformation.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
24-04-2014 12:31Tomas UrbanNew Issue
15-06-2014 17:14Gyorgy RethyAssigned To => Gyorgy Rethy
15-06-2014 17:14Gyorgy RethyStatusnew => assigned
15-06-2014 17:14Gyorgy RethyTarget Version => v4.6.1 (published 2015-06)
23-06-2014 11:22Gyorgy RethyNote Added: 0012190
23-06-2014 11:22Gyorgy RethyStatusassigned => closed
23-06-2014 11:22Gyorgy RethyResolutionopen => fixed
23-06-2014 11:22Gyorgy RethyFixed in Version => v4.6.1 (published 2015-06)
24-06-2014 08:59Gyorgy RethyFixed in Versionv4.6.1 (published 2015-06) => v4.5.2 (interim 2014)
26-01-2015 11:20Gyorgy RethyFixed in Versionv4.5.2 (interim 2014) => v4.6.1 (published 2015-06)
26-01-2015 11:28Gyorgy RethyFixed in Versionv4.6.1 (published 2015-06) => v4.5.2 (interim 2014)
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0012190) +
+ Gyorgy Rethy    +
+ 23-06-2014 11:22    +
+ 		+ + + + +
+ Implemented in master copy V4.5.2
+
+ + diff --git a/docs/mantis/CR6749.md b/docs/mantis/CR6749.md new file mode 100644 index 0000000000000000000000000000000000000000..204148ecf674356bd9d116799d4acb139a2f5e63 --- /dev/null +++ b/docs/mantis/CR6749.md @@ -0,0 +1,140 @@ + + + + + + + + + + + + + 0006749: Types mapped to enumeration - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006749Part 09: Using XML with TTCN-3Technicalpublic24-04-2014 15:2931-12-2014 14:54
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.5.1 (published 2013-04) 
Target Versionv4.6.1 (published 2015-06)Fixed in Versionv4.6.1 (published 2015-06) 
Clause Reference(s)6.1.5
For STF discussion
Source (company - Author)STF 475
Summary0006749: Types mapped to enumeration
DescriptionThe section 6.1.5 specifies that only an XSD string type and XSD integer type can be mapped into enumeration. However, this is rather an ambigous statement, because it can either mean two types, i.e. xsd:string and xsd:integer or any of the string and integer types available in XSD, i.e. all types from the section 6.2 and 6.3 (e.g. xsd:token or xsd:byte).
+
+It seems that the latter is case, because xsd:token is transformed into enumeration in 7.5.3, example 4.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR6749_resolution_v1.doc (101,376) 10-10-2014 09:43
http://oldforge.etsi.org/mantis/file_download.php?file_id=3142&type=bug
Issue History
Date ModifiedUsernameFieldChange
24-04-2014 15:29Tomas UrbanNew Issue
15-06-2014 17:06Gyorgy RethyTarget Version => v4.6.1 (published 2015-06)
15-06-2014 17:13Gyorgy RethyAssigned To => Gyorgy Rethy
15-06-2014 17:13Gyorgy RethyStatusnew => assigned
10-10-2014 09:42Gyorgy RethyNote Added: 0012340
10-10-2014 09:43Gyorgy RethyNote Edited: 0012340bug_revision_view_page.php?bugnote_id=12340#r83
10-10-2014 09:43Gyorgy RethyFile Added: CR6749_resolution_v1.doc
10-10-2014 09:46Gyorgy RethyAssigned ToGyorgy Rethy => Tomas Urban
10-10-2014 09:46Gyorgy RethyStatusassigned => confirmed
10-10-2014 11:42Tomas UrbanNote Added: 0012359
10-10-2014 11:42Tomas UrbanStatusconfirmed => resolved
10-10-2014 11:42Tomas UrbanFixed in Version => v4.6.1 (published 2015-06)
10-10-2014 11:42Tomas UrbanResolutionopen => fixed
10-10-2014 11:42Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
31-12-2014 14:54Gyorgy RethyNote Added: 0012601
31-12-2014 14:54Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0012340) +
+ Gyorgy Rethy    +
+ 10-10-2014 09:42    +
(edited on: 10-10-2014 09:43)
+ 		+ + + + +
+ Actually the clause states that types derived from XSD string and integer shall be mapped as their parents:
+"A simple type definition that is derived from an XSD string type..."
+"A simple type definition that is derived from the XSD integer type"
+"Any other enumeration facet"
+
+For further clarification of the above wording I have added two notes to the clauses on string and integer mappings.
+
+
+
+
+
+ + + + + + + + + + +
+ (0012359) +
+ Tomas Urban    +
+ 10-10-2014 11:42    +
+ 		+ + + + +
+ I am fine with the resolution. It can be added to the next version of the specification.
+
+
+
+ + + + + + + + + + +
+ (0012601) +
+ Gyorgy Rethy    +
+ 31-12-2014 14:54    +
+ 		+ + + + +
+ Added to draft V4.5.3
+
+ + diff --git a/docs/mantis/CR6750.md b/docs/mantis/CR6750.md new file mode 100644 index 0000000000000000000000000000000000000000..95a7ca7335129f7ee489429a2568f67b2f59a426 --- /dev/null +++ b/docs/mantis/CR6750.md @@ -0,0 +1,103 @@ + + + + + + + + + + + + + 0006750: Spaces are not allowed within type content - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006750Part 09: Using XML with TTCN-3Editorialpublic24-04-2014 15:3926-01-2015 11:28
ReporterBostjan Pintar 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.5.1 (published 2013-04) 
Target Versionv4.6.1 (published 2015-06)Fixed in Versionv4.5.2 (interim 2014) 
Clause Reference(s)7.6.7
For STF discussion
Source (company - Author)STF475
Summary0006750: Spaces are not allowed within type content
DescriptionSpace beside string and integer in the following example need to be removed:
+
+clause 7.6.7
+  Example 2 -
+    <xsd:attribute name="barInAgroup" type="xsd:string " />
+    <xsd:attribute name="dingInAgroup" type="xsd:integer " />
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
24-04-2014 15:39Bostjan PintarNew Issue
13-06-2014 15:42Gyorgy RethyTarget Version => v4.6.1 (published 2015-06)
15-06-2014 17:02Gyorgy RethyNote Added: 0012071
15-06-2014 17:02Gyorgy RethyStatusnew => resolved
15-06-2014 17:02Gyorgy RethyFixed in Version => v4.6.1 (published 2015-06)
15-06-2014 17:02Gyorgy RethyResolutionopen => fixed
15-06-2014 17:02Gyorgy RethyAssigned To => Gyorgy Rethy
20-06-2014 11:32Gyorgy RethyNote Added: 0012185
20-06-2014 11:32Gyorgy RethyStatusresolved => closed
24-06-2014 08:59Gyorgy RethyFixed in Versionv4.6.1 (published 2015-06) => v4.5.2 (interim 2014)
26-01-2015 11:20Gyorgy RethyFixed in Versionv4.5.2 (interim 2014) => v4.6.1 (published 2015-06)
26-01-2015 11:28Gyorgy RethyFixed in Versionv4.6.1 (published 2015-06) => v4.5.2 (interim 2014)
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0012071) +
+ Gyorgy Rethy    +
+ 15-06-2014 17:02    +
+ 		+ + + + +
+ Fixed in master copy.
+
+
+
+ + + + + + + + + + +
+ (0012185) +
+ Gyorgy Rethy    +
+ 20-06-2014 11:32    +
+ 		+ + + + +
+ Implemented in master copy V4.5.2
+
+ + diff --git a/docs/mantis/CR6751.md b/docs/mantis/CR6751.md new file mode 100644 index 0000000000000000000000000000000000000000..3e580a762cdab87022e2eaa4d01ea2309b1f7791 --- /dev/null +++ b/docs/mantis/CR6751.md @@ -0,0 +1,97 @@ + + + + + + + + + + + + + 0006751: Processing order of union items - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006751Part 09: Using XML with TTCN-3Editorialpublic25-04-2014 08:2226-01-2015 11:28
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.5.1 (published 2013-04) 
Target Versionv4.6.1 (published 2015-06)Fixed in Versionv4.5.2 (interim 2014) 
Clause Reference(s)7.5.3
For STF discussion
Source (company - Author)STF 475
Summary0006751: Processing order of union items
DescriptionThe processing order is compulsory according to the note 1 of the section 7.5.3. However, notes cannot introduce mandatory requirements, thus I propose to change the note into a standard rule and replace the expression "has to" with "shall".
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
25-04-2014 08:22Tomas UrbanNew Issue
13-06-2014 15:42Gyorgy RethyTarget Version => v4.6.1 (published 2015-06)
15-06-2014 17:13Gyorgy RethyNote Added: 0012072
15-06-2014 17:13Gyorgy RethyStatusnew => resolved
15-06-2014 17:13Gyorgy RethyFixed in Version => v4.6.1 (published 2015-06)
15-06-2014 17:13Gyorgy RethyResolutionopen => fixed
15-06-2014 17:13Gyorgy RethyAssigned To => Gyorgy Rethy
20-06-2014 11:53Gyorgy RethyFixed in Versionv4.6.1 (published 2015-06) =>
23-06-2014 11:24Gyorgy RethyNote Added: 0012191
23-06-2014 11:24Gyorgy RethyStatusresolved => closed
23-06-2014 11:24Gyorgy RethyFixed in Version => v4.6.1 (published 2015-06)
24-06-2014 08:58Gyorgy RethyFixed in Versionv4.6.1 (published 2015-06) => v4.5.2 (interim 2014)
26-01-2015 11:19Gyorgy RethyFixed in Versionv4.5.2 (interim 2014) => v4.6.1 (published 2015-06)
26-01-2015 11:28Gyorgy RethyFixed in Versionv4.6.1 (published 2015-06) => v4.5.2 (interim 2014)
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0012072) +
+ Gyorgy Rethy    +
+ 15-06-2014 17:13    +
+ 		+ + + + +
+ Comment accepted, text is changed from being a note to be in the main text in the master copy (v4.5.2).
+
+
+
+ + + + + + + + + + +
+ (0012191) +
+ Gyorgy Rethy    +
+ 23-06-2014 11:24    +
+ 		+ + + + +
+ Text is changed from being a note to be in the main text in the master copy (v4.5.2).
+
+ + diff --git a/docs/mantis/CR6752.md b/docs/mantis/CR6752.md new file mode 100644 index 0000000000000000000000000000000000000000..55b43ebc917702c53e4b1365483c58c3843b7d1a --- /dev/null +++ b/docs/mantis/CR6752.md @@ -0,0 +1,682 @@ + + + + + + + + + + + + + 0006752: Rules for transformation of enumerated facet applied to union content - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006752Part 09: Using XML with TTCN-3Clarificationpublic25-04-2014 08:5420-12-2016 09:07
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.5.1 (published 2013-04) 
Target Versionv4.8.1 (published 2017-05)Fixed in Versionv4.8.1 (published 2017-05) 
Clause Reference(s)7.5.3
For STF discussion
Source (company - Author)STF 475
Summary0006752: Rules for transformation of enumerated facet applied to union content
DescriptionIt is not obvious what rules were applied in the example 5 to generate the constraint. In particular, it seems that the enumerated values are converted to random alternatives of the union type that is being constrained. The textual order doesn't seem to be used, because in that case all values would fit to the first alternative, i.e. alt_ generated from xsd:string.
+
+However, even with correct textual order, the constraint is too restrictive, because only one constraint item is generated per XSD enumeration value. The correct approach would be to generate constraint items for all alternatives for which the XSD enumeration value is syntactically correct. In the given case transformation should yield:
+
+type E21unnamed E22 ({alt_:="20"}, {alt_1:=20.0}, {alt_1:=20}, {alt_:="50"}, {alt_1:=50.0}, {alt_1:=50}, {alt_:="small"})
+with {
+    variant "name as uncapitalized"
+}
+
+In my opinion, this procedure is so complicated and includes certain amount of interpretaion that it should be described in the specification as a binding rule.
+
+Besides, the example itself is not a very good one since the processing order requires that strings are always processed first meaning that float and integer values cannot ever be successfully decoded. In order to fix that, the order of items in the parent union should be reversed.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
has duplicate 0006766closed Gyorgy Rethy enumeration facet applied to a union-simple-type-derivation should yield an enumeration type 
Attached Filesdoc CR6752_resolution_v1.doc (115,200) 11-12-2014 13:27
http://oldforge.etsi.org/mantis/file_download.php?file_id=3195&type=bug
docx CR6752_resolution_v2.docx (72,576) 06-11-2015 10:57
http://oldforge.etsi.org/mantis/file_download.php?file_id=3371&type=bug
docx CR6752_resolution_v3.docx (73,277) 10-11-2015 15:28
http://oldforge.etsi.org/mantis/file_download.php?file_id=3372&type=bug
docx CR6752_resolution_v4.docx (74,058) 22-12-2015 08:26
http://oldforge.etsi.org/mantis/file_download.php?file_id=3396&type=bug
docx CR6752_resolution_v5.docx (59,285) 14-11-2016 10:00
http://oldforge.etsi.org/mantis/file_download.php?file_id=3514&type=bug
docx CR6752_resolution_v6.docx (61,056) 15-11-2016 09:29
http://oldforge.etsi.org/mantis/file_download.php?file_id=3515&type=bug
docx CR6752_resolution_v7.docx (61,755) 16-11-2016 13:21
http://oldforge.etsi.org/mantis/file_download.php?file_id=3535&type=bug
Issue History
Date ModifiedUsernameFieldChange
25-04-2014 08:54Tomas UrbanNew Issue
25-04-2014 09:33Tomas UrbanNote Added: 0012054
03-06-2014 15:47Jacob Wieland - SpirentRelationship addedrelated to 0006766
13-06-2014 15:41Gyorgy RethyTarget Version => v4.6.1 (published 2015-06)
15-06-2014 17:08Gyorgy RethyAssigned To => Gyorgy Rethy
15-06-2014 17:08Gyorgy RethyStatusnew => assigned
05-11-2014 09:14Gyorgy RethyRelationship replacedhas duplicate 0006766
10-12-2014 15:35Gyorgy RethyNote Added: 0012538
11-12-2014 13:27Gyorgy RethyFile Added: CR6752_resolution_v1.doc
11-12-2014 13:28Gyorgy RethyNote Added: 0012540
11-12-2014 13:29Gyorgy RethyAssigned ToGyorgy Rethy => Tomas Urban
11-12-2014 13:29Gyorgy RethyStatusassigned => confirmed
11-12-2014 22:27Jacob Wieland - SpirentNote Added: 0012542
15-12-2014 09:11Tomas UrbanNote Added: 0012547
15-12-2014 09:11Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
29-12-2014 14:59Gyorgy RethyNote Added: 0012586
29-12-2014 14:59Gyorgy RethyTarget Versionv4.6.1 (published 2015-06) => v4.7.1 (published 2016-07)
05-08-2015 12:00Jacob Wieland - SpirentNote Added: 0013083
05-08-2015 12:00Jacob Wieland - SpirentStatusconfirmed => assigned
07-08-2015 14:34Jacob Wieland - SpirentNote Added: 0013150
10-08-2015 09:00Jacob Wieland - SpirentNote Added: 0013151
05-11-2015 08:44Gyorgy RethyAssigned ToGyorgy Rethy => Axel Rennoch
06-11-2015 10:57Axel RennochFile Added: CR6752_resolution_v2.docx
10-11-2015 15:28Axel RennochFile Added: CR6752_resolution_v3.docx
10-11-2015 15:30Axel RennochNote Added: 0013520
10-11-2015 15:30Axel RennochAssigned ToAxel Rennoch => Jacob Wieland - Spirent
10-11-2015 15:30Axel RennochStatusassigned => feedback
23-11-2015 10:47Jacob Wieland - SpirentNote Added: 0013535
23-11-2015 10:47Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Axel Rennoch
23-11-2015 10:47Jacob Wieland - SpirentStatusfeedback => assigned
22-12-2015 08:26Gyorgy RethyFile Added: CR6752_resolution_v4.docx
22-12-2015 08:26Gyorgy RethyStatusassigned => confirmed
22-12-2015 12:01Jacob Wieland - SpirentNote Added: 0013647
22-12-2015 12:01Jacob Wieland - SpirentStatusconfirmed => resolved
22-12-2015 12:01Jacob Wieland - SpirentFixed in Version => v4.7.1 (published 2016-07)
22-12-2015 12:01Jacob Wieland - SpirentResolutionopen => fixed
22-12-2015 12:01Jacob Wieland - SpirentAssigned ToAxel Rennoch => Gyorgy Rethy
04-01-2016 16:46Gyorgy RethyNote Added: 0013657
04-01-2016 16:47Gyorgy RethyStatusresolved => confirmed
05-01-2016 08:19Gyorgy RethyNote Edited: 0013657bug_revision_view_page.php?bugnote_id=13657#r259
05-01-2016 08:19Gyorgy RethyAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
05-01-2016 08:19Gyorgy RethyStatusconfirmed => assigned
05-01-2016 08:19Gyorgy RethyStatusassigned => confirmed
05-01-2016 08:39Gyorgy RethyNote Edited: 0013657bug_revision_view_page.php?bugnote_id=13657#r260
05-01-2016 08:40Gyorgy RethyNote Edited: 0013657bug_revision_view_page.php?bugnote_id=13657#r261
05-01-2016 10:29Jacob Wieland - SpirentNote Added: 0013659
21-07-2016 11:30Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Kristóf Szabados
21-07-2016 11:30Jacob Wieland - SpirentStatusconfirmed => assigned
17-08-2016 12:06Jacob Wieland - SpirentFixed in Versionv4.7.1 (published 2016-07) =>
17-08-2016 12:06Jacob Wieland - SpirentTarget Versionv4.7.1 (published 2016-07) => v4.8.1 (published 2017-05)
14-11-2016 10:00Kristóf SzabadosFile Added: CR6752_resolution_v5.docx
15-11-2016 09:29Kristóf SzabadosFile Added: CR6752_resolution_v6.docx
15-11-2016 09:30Kristóf SzabadosAssigned ToKristóf Szabados => Axel Rennoch
15-11-2016 09:31Kristóf SzabadosNote Added: 0014234
16-11-2016 13:15Axel RennochFile Added: CR6752_resolution_v7.docx
16-11-2016 13:20Axel RennochFile Deleted: CR6752_resolution_v7.docx
16-11-2016 13:21Axel RennochFile Added: CR6752_resolution_v7.docx
16-11-2016 13:21Axel RennochNote Added: 0014264
16-11-2016 13:23Axel RennochAssigned ToAxel Rennoch => Gyorgy Rethy
16-11-2016 13:23Axel RennochStatusassigned => resolved
20-12-2016 09:07Gyorgy RethyNote Added: 0014463
20-12-2016 09:07Gyorgy RethyStatusresolved => closed
20-12-2016 09:07Gyorgy RethyFixed in Version => v4.8.1 (published 2017-05)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0012054) +
+ Tomas Urban    +
+ 25-04-2014 09:33    +
+ 		+ + + + +
+ There is one additional problem with float values occuring in the enumerated facets restricting union content. In this particular case, the schema validation procedure expects exactly the same value string as specified in the enumeration facet. This is different from a enumerated facets restricting a float type where validation is based on the value itself and the format doesn't matter.
+
+The issue occurs in the moment when the XML codec tries to encode this kind of union value. Since there's no encoding information regarding the expected textual format of the produced float value, the codec can pick any of the suitable float formats. This format doesn't have to match the value defined in the enumeration facet and that will lead to an XML document validation error. E.g. in the example 5, the required value is without the decimal point (50), but XML codecs are likely to produce a value with the decimal point (50.0).
+
+
+
+ + + + + + + + + + +
+ (0012538) +
+ Gyorgy Rethy    +
+ 10-12-2014 15:35    +
+ 		+ + + + +
+ The comment is correct. I think that the example itself is an exotic case, therefore we need to seek for the simplest solution. From this point of view, defining extra conversion rules, as proposed in CR6766 (at least one for enumeration restrictions containing a string alternative and one for the restrictions not containing a string alternative), would overdo it.
+
+Tomas is correct, in the TTCN-3 type restriction we need to store the syntax in the enumeration facets and leave the rest for the codec. This would make it easer for the user as well, as the decoder, after validation, can put the received value into the alternative in the type restriction. I'm going to write a proposal and add one more example, where numeric alternatives are the first.
+
+
+
+ + + + + + + + + + +
+ (0012540) +
+ Gyorgy Rethy    +
+ 11-12-2014 13:28    +
+ 		+ + + + +
+ Please review: CR6752_resolution_v1.doc.
+
+
+
+ + + + + + + + + + +
+ (0012542) +
+ Jacob Wieland - Spirent    +
+ 11-12-2014 22:27    +
+ 		+ + + + +
+ I still don't see the merit of this over-complicated mapping. If the range of values the type is being restricted to is a simple enumeration, why not map it to an enumeration type? Just because there is a subtyping relationship inside XSD does not mean there has to be one in XML and since the enumeration facets do not carry the type information (which union variant they belong to), this does not even have to be transported into TTCN-3.
+
+
+
+ + + + + + + + + + +
+ (0012547) +
+ Tomas Urban    +
+ 15-12-2014 09:11    +
+ 		+ + + + +
+ The proposal is technically correct and could be added into the next version of the specification. However, I think that before we make a final decision, we should consider Jacob's proposal as well. In my opinion, it would be indeed more suitable to transforms unions restricted with the enumeration facet into a simple enumerated type using the string values. That would be much easier to implement and simpler to understand from the user point of view.
+
+
+
+ + + + + + + + + + +
+ (0012586) +
+ Gyorgy Rethy    +
+ 29-12-2014 14:59    +
+ 		+ + + + +
+ OK, in this case we have to shift the CR to the next version in 2015.
+
+
+
+ + + + + + + + + + +
+ (0013083) +
+ Jacob Wieland - Spirent    +
+ 05-08-2015 12:00    +
+ 		+ + + + +
+ I'll just unconfirm this CR and assign it to Gyorgy to respawn the discussion.
+
+
+
+ + + + + + + + + + +
+ (0013150) +
+ Jacob Wieland - Spirent    +
+ 07-08-2015 14:34    +
+ 		+ + + + +
+ Augmenting my proposal, I propose to map a union with an enumeration facet to the following structure:
+
+type record {
+  enumerated { noType, <member_type_1_id>, ..., <member_type_n_id> } xsiType,
+  enumerated { <enum_value_1>, ..., <enum_value_m> } content
+}
+
+This way, the respresentation of an xsd union value is a pair { xsiType := id, content := id2 }
+
+By giving a type enum value other than noType, the encoder will use the corresponding type in the xsi:type attribute of the element containing content of this simple type.
+
+For matching, ? can be used if the type is irrelevant.
+
+This mapping solves the problem of normalization (if a float is restricted to a certain representation via the enumeration facet, the decoder knows for every such representation which enumeration value to map it to or from).
+
+The corresponding templates look very similar if given in list form:
+
+{ t, v } instead of { t := v }
+
+
+
+ + + + + + + + + + +
+ (0013151) +
+ Jacob Wieland - Spirent    +
+ 10-08-2015 09:00    +
+ 		+ + + + +
+ even better would be, of course:
+
+type record {
+  enumerated { <member_type_1_id>, ..., <member_type_n_id> } xsiType optional,
+  enumerated { <enum_value_1>, ..., <enum_value_m> } content
+}
+
+The presence of the xsiType field would then indicate also the presence of the xsd:type attribute.
+
+
+
+ + + + + + + + + + +
+ (0013520) +
+ Axel Rennoch    +
+ 10-11-2015 15:30    +
+ 		+ + + + +
+ Please have a look to the modified text and example in resolution_v3.
+
+
+
+ + + + + + + + + + +
+ (0013535) +
+ Jacob Wieland - Spirent    +
+ 23-11-2015 10:47    +
+ 		+ + + + +
+ sorry, but I think it needs more elaboration.
+
+The names of the xsiType enumerated values should be the same names as the alternatives in the other union-mappings (i.e. if it is a union containing anonymous simple types, it should be alt_1 etc. for these, only for referenced types (in the memberTypes attribute), the referenced type names shall be used - same as in other union).
+
+This, of course, will also change the example.
+
+
+
+ + + + + + + + + + +
+ (0013647) +
+ Jacob Wieland - Spirent    +
+ 22-12-2015 12:01    +
+ 		+ + + + +
+ For me, the text is ok.
+
+
+
+ + + + + + + + + + +
+ (0013657) +
+ Gyorgy Rethy    +
+ 04-01-2016 16:46    +
(edited on: 05-01-2016 08:40)
+ 		+ + + + +
+ I have found a problem with this resolution: in this mapping:
+type record E22 {
+  enumerated {alt_, alt_1, alt_2} xsiType optional,
+  enumerated {x20, x50_0, small_1} content
+}
+with {
+    variant "name as uncapitalized";
+    variant "element";
+    variant "useUnion";
+    variant(alt_, alt_1, alt_2) "name as ''";
+}
+
+there is no implicit or explicit reference to the base type e21unnamed; therefore the XSD types of the enumerated names alt_, alt_1_ & alt_2 are not known at encoding, while they are needed for the xsi:type attribute of the XML value.
+
+An option could be to use the XSD type names directly as enumeration names; Also, the exact names of the XSD enumeration values should be given explicitly, where the TTCN-3 name mangling changes them, e.g.:
+type record E22 {
+  enumerated {float_, integer_, string} xsiType optional,
+  enumerated {x20, x50_0, small_1} content
+}
+with {
+    variant "name as uncapitalized";
+    variant "element";
+    variant "useUnion";
+    variant (xsiType) "text 'float_' as 'float'";
+    variant (xsiType) "text 'integer_' as 'integer'";
+    variant (content) "text 'x20' as '20'";
+    variant (content) "text 'x50_0' as '50.0'";
+    variant (content) "text ' small_1' as ' small-1'";
+}
+
+In this case the useUnion instruction shall behave quite differently from the "basic case", specified currently in clause B.3.16. Thus B.3.16 shall be revised and extended with the description of this specific case.
+
+
+
+
+
+ + + + + + + + + + +
+ (0013659) +
+ Jacob Wieland - Spirent    +
+ 05-01-2016 10:29    +
+ 		+ + + + +
+ I agree, this would be a good approach.
+
+
+
+ + + + + + + + + + +
+ (0014234) +
+ Kristóf Szabados    +
+ 15-11-2016 09:31    +
+ 		+ + + + +
+ please review
+
+
+
+ + + + + + + + + + +
+ (0014264) +
+ Axel Rennoch    +
+ 16-11-2016 13:21    +
+ 		+ + + + +
+ correction of example 5
+
+
+
+ + + + + + + + + + +
+ (0014463) +
+ Gyorgy Rethy    +
+ 20-12-2016 09:07    +
+ 		+ + + + +
+ Added to draft V4.7.2
+
+ + diff --git a/docs/mantis/CR6753.md b/docs/mantis/CR6753.md new file mode 100644 index 0000000000000000000000000000000000000000..c1ab92168f2c8ee99095fa70d93c3f3868b068fb --- /dev/null +++ b/docs/mantis/CR6753.md @@ -0,0 +1,131 @@ + + + + + + + + + + + + + 0006753: Partially initialized values in "any from" calls - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006753Part 01: TTCN-3 Core LanguageClarificationpublic28-04-2014 12:1806-01-2015 19:05
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.6.1 (published 2014-06) 
Target Versionv4.7.1 (published 2015-06)Fixed in Versionv4.7.1 (published 2015-06) 
Clause Reference(s)21.3.5, 21.3.6, 21.3.7, 21.3.8, 22.2.2, 22.2.3, 22.3.2, 22.3.4, 22.3.6, 22.4, 23.5, 23.6
Source (company - Author)STF 470
Summary0006753: Partially initialized values in "any from" calls
DescriptionWith the omission of the restriction 11.1.e (present in 4.5.1, but missing in 4.6.1), it is not obvious what should happen if an "any from" construct contains a reference to a partially initialized variable. My assumption is that it should lead to a runtime error, but such a rule doesn't seem to be present in the specification.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR6753_v1.docx (105,095) 07-10-2014 15:44
http://oldforge.etsi.org/mantis/file_download.php?file_id=3102&type=bug
Issue History
Date ModifiedUsernameFieldChange
28-04-2014 12:18Tomas UrbanNew Issue
30-04-2014 08:41Jacob Wieland - SpirentNote Added: 0012055
13-06-2014 15:41Gyorgy RethyTarget Version => v4.7.1 (published 2015-06)
07-10-2014 14:50Tomas UrbanAssigned To => Tomas Urban
07-10-2014 14:50Tomas UrbanStatusnew => assigned
07-10-2014 15:44Tomas UrbanFile Added: CR6753_v1.docx
07-10-2014 15:45Tomas UrbanNote Added: 0012259
07-10-2014 15:45Tomas UrbanAssigned ToTomas Urban => Jens Grabowski
07-10-2014 15:45Tomas UrbanStatusassigned => confirmed
07-10-2014 16:11Jens GrabowskiAssigned ToJens Grabowski => Gyorgy Rethy
07-10-2014 16:11Jens GrabowskiStatusconfirmed => assigned
07-10-2014 16:11Jens GrabowskiStatusassigned => resolved
07-10-2014 16:11Jens GrabowskiResolutionopen => fixed
06-01-2015 19:05Gyorgy RethyNote Added: 0012657
06-01-2015 19:05Gyorgy RethyStatusresolved => closed
06-01-2015 19:05Gyorgy RethyFixed in Version => v4.7.1 (published 2015-06)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0012055) +
+ Jacob Wieland - Spirent    +
+ 30-04-2014 08:41    +
+ 		+ + + + +
+ I agree. All matching mechanisms that cannot be changed anymore should only reference fully initialized values/templates.
+
+
+
+ + + + + + + + + + +
+ (0012259) +
+ Tomas Urban    +
+ 07-10-2014 15:45    +
+ 		+ + + + +
+ Resolution uploaded. Please check.
+
+
+
+ + + + + + + + + + +
+ (0012657) +
+ Gyorgy Rethy    +
+ 06-01-2015 19:05    +
+ 		+ + + + +
+ Added to draft V4.6.3
+
+ + diff --git a/docs/mantis/CR6754.md b/docs/mantis/CR6754.md new file mode 100644 index 0000000000000000000000000000000000000000..ce5d237db2a250e441be62087fa9540b6daeec64 --- /dev/null +++ b/docs/mantis/CR6754.md @@ -0,0 +1,245 @@ + + + + + + + + + + + + + 0006754: Predefined function to identify unicode string encoding automatically - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006754Part 01: TTCN-3 Core LanguageNew Featurepublic29-04-2014 09:0206-01-2015 18:06
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.6.1 (published 2014-06) 
Target Versionv4.7.1 (published 2015-06)Fixed in Versionv4.7.1 (published 2015-06) 
Clause Reference(s)new cluae C.5.X
Source (company - Author)L.M.Ericsson
Summary0006754: Predefined function to identify unicode string encoding automatically
DescriptionPredifend function decode_unichar requires to identify the encoding type in the parameter string_encoding. However, the initial octet sequence (BOMs) -if included - may identify the type of the encoding, in which case it could be identified automatically in TTCN-3.
+
+We propose to add the predefined function
+
+get_stringencoding(in octetstring encoded_value) return charstring
+
+to the standard.
+
+It will return one of the string_encoding values, defined in clause C.5.4 or "<unknown>" if the type of encoding could not been identified.
+
+Note, that except the BOMs, any other secure methods can be used to identify the type of the string's encoding.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
has duplicate 0006755closed Gyorgy Rethy Predefined function to remove BOMs from universal charstring 
Attached Filesdocx CR6754_resolution_v1.docx (20,191) 19-06-2014 13:04
http://oldforge.etsi.org/mantis/file_download.php?file_id=3057&type=bug
docx CR6754_resolution_v2.docx (27,933) 08-10-2014 15:41
http://oldforge.etsi.org/mantis/file_download.php?file_id=3117&type=bug
docx CR6754_resolution_v3.docx (28,347) 09-10-2014 15:08
http://oldforge.etsi.org/mantis/file_download.php?file_id=3130&type=bug
docx CR6754_resolution_v4.docx (29,206) 09-10-2014 16:33
http://oldforge.etsi.org/mantis/file_download.php?file_id=3135&type=bug
Issue History
Date ModifiedUsernameFieldChange
29-04-2014 09:02Gyorgy RethyNew Issue
13-06-2014 15:41Gyorgy RethyProduct Version => v4.6.1 (published 2014-06)
13-06-2014 15:41Gyorgy RethyTarget Version => v4.7.1 (published 2015-06)
17-06-2014 11:52Gyorgy RethyAssigned To => Axel Rennoch
17-06-2014 11:52Gyorgy RethyStatusnew => assigned
19-06-2014 13:04Axel RennochFile Added: CR6754_resolution_v1.docx
19-06-2014 13:05Axel RennochAssigned ToAxel Rennoch => Gyorgy Rethy
19-06-2014 13:05Axel RennochNote Added: 0012143
19-06-2014 13:05Axel RennochStatusassigned => confirmed
08-10-2014 15:23Gyorgy RethyRelationship addedhas duplicate 0006755
08-10-2014 15:41Gyorgy RethyFile Added: CR6754_resolution_v2.docx
08-10-2014 15:42Gyorgy RethyNote Added: 0012286
08-10-2014 15:42Gyorgy RethyAssigned ToGyorgy Rethy => Axel Rennoch
08-10-2014 16:25Axel RennochNote Added: 0012298
08-10-2014 16:26Axel RennochAssigned ToAxel Rennoch => Gyorgy Rethy
08-10-2014 16:26Axel RennochStatusconfirmed => assigned
08-10-2014 16:26Axel RennochStatusassigned => confirmed
09-10-2014 15:08Gyorgy RethyFile Added: CR6754_resolution_v3.docx
09-10-2014 15:14Gyorgy RethyNote Added: 0012326
09-10-2014 15:14Gyorgy RethyAssigned ToGyorgy Rethy => Axel Rennoch
09-10-2014 16:31Axel RennochFile Added: CR6704_v4.docx
09-10-2014 16:32Axel RennochNote Added: 0012334
09-10-2014 16:33Axel RennochFile Deleted: CR6704_v4.docx
09-10-2014 16:33Axel RennochFile Added: CR6754_resolution_v4.docx
09-10-2014 16:34Axel RennochStatusconfirmed => resolved
09-10-2014 16:34Axel RennochResolutionopen => fixed
13-10-2014 09:40Gyorgy RethyAssigned ToAxel Rennoch => Gyorgy Rethy
06-01-2015 18:06Gyorgy RethyNote Added: 0012647
06-01-2015 18:06Gyorgy RethyStatusresolved => closed
06-01-2015 18:06Gyorgy RethyFixed in Version => v4.7.1 (published 2015-06)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0012143) +
+ Axel Rennoch    +
+ 19-06-2014 13:05    +
+ 		+ + + + +
+ iinitial text proposal for comments
+
+
+
+ + + + + + + + + + +
+ (0012286) +
+ Gyorgy Rethy    +
+ 08-10-2014 15:42    +
+ 		+ + + + +
+ In CR6754_resolution_v2.docx: merged with CR6755 (remove_bom function is also included into this file). Please review the changes.
+
+
+
+ + + + + + + + + + +
+ (0012298) +
+ Axel Rennoch    +
+ 08-10-2014 16:25    +
+ 		+ + + + +
+ new sections are fine. we may add the explanation/abbreviation for BOM?
+
+
+
+ + + + + + + + + + +
+ (0012326) +
+ Gyorgy Rethy    +
+ 09-10-2014 15:14    +
+ 		+ + + + +
+ It's a good idea. I have added BOM to the abbreviations. I have also a problem with ISO 10646 wording, it is unclear when an FEFF sequence is a signature and when not, why not?...; so I rather used the term "FEFF ZERO WIDTH NO-BREAK SPACE" in the text, this at least used consistently in ISO 10646.
+
+Updated version is in CR6754_resolution_v3.docx. please review. If OK, from my side it can be set to resolved.
+
+
+
+ + + + + + + + + + +
+ (0012334) +
+ Axel Rennoch    +
+ 09-10-2014 16:32    +
+ 		+ + + + +
+ adjusting wording of title of table and column
+
+
+
+ + + + + + + + + + +
+ (0012647) +
+ Gyorgy Rethy    +
+ 06-01-2015 18:06    +
+ 		+ + + + +
+ Added to draft V4.6.3
+
+ + diff --git a/docs/mantis/CR6755.md b/docs/mantis/CR6755.md new file mode 100644 index 0000000000000000000000000000000000000000..e6229e18420682f2b5d2281760a34231911a4a7d --- /dev/null +++ b/docs/mantis/CR6755.md @@ -0,0 +1,137 @@ + + + + + + + + + + + + + 0006755: Predefined function to remove BOMs from universal charstring - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006755Part 01: TTCN-3 Core LanguageNew Featurepublic29-04-2014 09:1910-10-2014 10:43
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeveritymajorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.7.1 (published 2015-06) 
Target Versionv4.7.1 (published 2015-06)Fixed in Versionv4.7.1 (published 2015-06) 
Clause Reference(s)new C.5.X
Source (company - Author)L.M.Ericsson
Summary0006755: Predefined function to remove BOMs from universal charstring
DescriptionUnicode strings may have initial octets (BOMs) identifying the type of the string encoding. In cases, when this needs to be removed (e.g. if relaying a string or the string should be used as a binary payload without BOMs). BOMs are optional, and if present, the length depend on the type of encoding. Therefore, removing BOMs cannot be solved in TTCN-3 a simple way by e.g. calling a substr function.
+
+We propose to add the predefined function
+
+function remove_bom(in octetstring encoded_value) return octetstring;
+
+It will strip the BOMs if they are present and return the original octetstring otherwise.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
duplicate of 0006754closed Gyorgy Rethy Predefined function to identify unicode string encoding automatically 
Attached Filesdocx draft-res-6755.docx (16,913) 07-10-2014 15:15
http://oldforge.etsi.org/mantis/file_download.php?file_id=3099&type=bug
Issue History
Date ModifiedUsernameFieldChange
29-04-2014 09:19Gyorgy RethyNew Issue
13-06-2014 15:40Gyorgy RethyTarget Version => v4.7.1 (published 2015-06)
17-06-2014 11:55Gyorgy RethyNote Added: 0012101
17-06-2014 11:56Gyorgy RethyAssigned To => Axel Rennoch
17-06-2014 11:56Gyorgy RethyStatusnew => assigned
07-10-2014 15:15Axel RennochFile Added: draft-res-6755.docx
07-10-2014 15:15Axel RennochAssigned ToAxel Rennoch => Gyorgy Rethy
07-10-2014 15:15Axel RennochStatusassigned => confirmed
08-10-2014 15:23Gyorgy RethyRelationship addedduplicate of 0006754
08-10-2014 15:24Gyorgy RethyNote Added: 0012285
10-10-2014 10:43Gyorgy RethyNote Added: 0012351
10-10-2014 10:43Gyorgy RethyStatusconfirmed => closed
10-10-2014 10:43Gyorgy RethyResolutionopen => fixed
10-10-2014 10:43Gyorgy RethyFixed in Version => v4.7.1 (published 2015-06)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0012101) +
+ Gyorgy Rethy    +
+ 17-06-2014 11:55    +
+ 		+ + + + +
+ STF discussion: Control of BOM presence could be needed also for encode.
+
+
+
+ + + + + + + + + + +
+ (0012285) +
+ Gyorgy Rethy    +
+ 08-10-2014 15:24    +
+ 		+ + + + +
+ This CR is merged into CR 6754, because the two functions are closely related and should be discussed and changed in a synchronized way.
+
+
+
+ + + + + + + + + + +
+ (0012351) +
+ Gyorgy Rethy    +
+ 10-10-2014 10:43    +
+ 		+ + + + +
+ Resolution is included into CR6754!
+
+ + diff --git a/docs/mantis/CR6756.md b/docs/mantis/CR6756.md new file mode 100644 index 0000000000000000000000000000000000000000..f0d424c62957153cd42ca132bf430c4832efb148 --- /dev/null +++ b/docs/mantis/CR6756.md @@ -0,0 +1,207 @@ + + + + + + + + + + + + + 0006756: External Function constraint exceptions should be revised - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006756Part 01: TTCN-3 Core LanguageTechnicalpublic07-05-2014 10:3505-01-2015 16:11
ReporterAndras Kovacs 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.6.1 (published 2014-06) 
Target Versionv4.7.1 (published 2015-06)Fixed in Versionv4.7.1 (published 2015-06) 
Clause Reference(s)16.1.3
Source (company - Author)STF470 - Andras Kovacs
Summary0006756: External Function constraint exceptions should be revised
DescriptionThe section on External functions states the following constraints:
+"External functions are not allowed to contain default handling, configuration, communication or timer operations, except the check, checkstate, alive, running, done, killed, read, mtc, system, and self operations."
+
+Does it really make sense to allow check, done, killed, read, mtc, system and self operations in the above exception list? If it makes sense, then examples should be provided on how to use such function call.
+
+In the view of STF470, the above mentioned exceptions make sense only in two unlikely scenarios:
+1. The external function contains default parameter values and these values are returned from a function call. This function then might contain one of the forbidden operation. However, we don't consider parameter value assignment to be a part of the called external function. In our opinion, default parameter values are calculated before the external function is actually called.
+2. TTCN-3 tools might contain proprietary features allowing to execute ordinary TTCN-3 functions from external functions. In this case, the restriction makes sense, but it is a question whether the standard should contain rules that regulate proprietary solutions.
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR6756_v1-141104-JG.docx (17,838) 04-11-2014 10:29
http://oldforge.etsi.org/mantis/file_download.php?file_id=3154&type=bug
Issue History
Date ModifiedUsernameFieldChange
07-05-2014 10:35Andras KovacsNew Issue
07-05-2014 13:31Jacob Wieland - SpirentNote Added: 0012064
13-06-2014 15:40Gyorgy RethyTarget Version => v4.7.1 (published 2015-06)
03-11-2014 16:48Gyorgy RethyNote Added: 0012386
03-11-2014 16:48Gyorgy RethyAssigned To => Jens Grabowski
03-11-2014 16:48Gyorgy RethyStatusnew => assigned
04-11-2014 10:28Jens GrabowskiNote Added: 0012389
04-11-2014 10:29Jens GrabowskiFile Added: CR6756_v1-141104-JG.docx
04-11-2014 10:29Jens GrabowskiAssigned ToJens Grabowski => Tomas Urban
04-11-2014 10:29Jens GrabowskiStatusassigned => confirmed
04-11-2014 13:49Tomas UrbanNote Added: 0012398
04-11-2014 13:49Tomas UrbanStatusconfirmed => resolved
04-11-2014 13:49Tomas UrbanFixed in Version => v4.7.1 (published 2015-06)
04-11-2014 13:49Tomas UrbanResolutionopen => fixed
04-11-2014 13:49Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
05-01-2015 16:11Gyorgy RethyNote Added: 0012618
05-01-2015 16:11Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0012064) +
+ Jacob Wieland - Spirent    +
+ 07-05-2014 13:31    +
+ 		+ + + + +
+ In my opinion, these restrictions should be changed to a cautionary NOTE that, dependent on the context where the external function is used, all state-changing operations should be avoided to avoid unwanted side-effects.
+
+
+
+ + + + + + + + + + +
+ (0012386) +
+ Gyorgy Rethy    +
+ 03-11-2014 16:48    +
+ 		+ + + + +
+ STF discussion: change the sentence to a note.
+
+
+
+ + + + + + + + + + +
+ (0012389) +
+ Jens Grabowski    +
+ 04-11-2014 10:28    +
+ 		+ + + + +
+ Please check resolution proposal.
+
+
+
+ + + + + + + + + + +
+ (0012398) +
+ Tomas Urban    +
+ 04-11-2014 13:49    +
+ 		+ + + + +
+ I reviewed the proposal and found no problems. The proposed changes can be added to the next version of the core language specification.
+
+
+
+ + + + + + + + + + +
+ (0012618) +
+ Gyorgy Rethy    +
+ 05-01-2015 16:11    +
+ 		+ + + + +
+ Added to draft V4.6.3
+
+ + diff --git a/docs/mantis/CR6761.md b/docs/mantis/CR6761.md new file mode 100644 index 0000000000000000000000000000000000000000..04de631694ebb0da93b283e6dfa82bc067f7057b --- /dev/null +++ b/docs/mantis/CR6761.md @@ -0,0 +1,144 @@ + + + + + + + + + + + + + 0006761: extended type - syntactical Structure - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006761Part 01: TTCN-3 Core LanguageTechnicalpublic25-05-2014 11:5105-01-2015 17:17
ReporterAxel Rennoch 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.6.1 (published 2014-06) 
Target Versionv4.7.1 (published 2015-06)Fixed in Versionv4.7.1 (published 2015-06) 
Clause Reference(s)6.2.10.2
Source (company - Author)Axel Rennoch
Summary0006761: extended type - syntactical Structure
Descriptionsyntactical Structure does not reflect extension by multiple components ("ComponentTypeIdentifier")
+
+need to be aligned with A.1.6.1.1: rule 71.ComponentDef
Steps To Reproduce
Additional Informationproposed correction:
+
+type component ComponentTypeIdentifier extends
+ComponentTypeIdentifier {, ComponentTypeIdentifier}
+"{"
+{ (
+ PortInstance
+|VarInstance
+|TimerInstance
+|ConstDef
+) }
+"}"
TagsNo tags attached.
Relationships
Attached Filesdocx CR6761_v1.docx (46,441) 08-10-2014 09:42
http://oldforge.etsi.org/mantis/file_download.php?file_id=3105&type=bug
Issue History
Date ModifiedUsernameFieldChange
25-05-2014 11:51Axel RennochNew Issue
06-10-2014 13:45Gyorgy RethyAssigned To => Gyorgy Rethy
06-10-2014 13:45Gyorgy RethyStatusnew => assigned
08-10-2014 09:25Gyorgy RethyAssigned ToGyorgy Rethy => Tomas Urban
08-10-2014 09:42Tomas UrbanFile Added: CR6761_v1.docx
08-10-2014 09:42Tomas UrbanNote Added: 0012269
08-10-2014 09:42Tomas UrbanAssigned ToTomas Urban => Axel Rennoch
08-10-2014 09:42Tomas UrbanStatusassigned => confirmed
08-10-2014 13:40Axel RennochAssigned ToAxel Rennoch => Gyorgy Rethy
08-10-2014 13:40Axel RennochStatusconfirmed => assigned
08-10-2014 13:41Axel RennochNote Added: 0012281
08-10-2014 13:41Axel RennochStatusassigned => confirmed
08-10-2014 16:23Gyorgy RethyStatusconfirmed => resolved
08-10-2014 16:23Gyorgy RethyResolutionopen => fixed
08-10-2014 16:23Gyorgy RethyProduct Versionv4.7.1 (published 2015-06) => v4.6.1 (published 2014-06)
08-10-2014 16:23Gyorgy RethyFixed in Version => v4.7.1 (published 2015-06)
05-01-2015 17:17Gyorgy RethyNote Added: 0012622
05-01-2015 17:17Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0012269) +
+ Tomas Urban    +
+ 08-10-2014 09:42    +
+ 		+ + + + +
+ As proposed. Please check.
+
+
+
+ + + + + + + + + + +
+ (0012281) +
+ Axel Rennoch    +
+ 08-10-2014 13:41    +
+ 		+ + + + +
+ The proposal is fine with me. CR can be closed.
+
+
+
+ + + + + + + + + + +
+ (0012622) +
+ Gyorgy Rethy    +
+ 05-01-2015 17:17    +
+ 		+ + + + +
+ Added to draft V4.6.3
+
+ + diff --git a/docs/mantis/CR6762.md b/docs/mantis/CR6762.md new file mode 100644 index 0000000000000000000000000000000000000000..86f33d607abc24680ed8baa752feca4376ae82ca --- /dev/null +++ b/docs/mantis/CR6762.md @@ -0,0 +1,161 @@ + + + + + + + + + + + + + 0006762: Array indexing breaches strong typing principle - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006762Part 01: TTCN-3 Core LanguageTechnicalpublic03-06-2014 09:2304-01-2015 21:16
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.7.1 (published 2015-06) 
Target Versionv4.7.1 (published 2015-06)Fixed in Versionv4.7.1 (published 2015-06) 
Clause Reference(s)6.2.3
Source (company - Author)Elvior
Summary0006762: Array indexing breaches strong typing principle
DescriptionA new rule was added into the chapter 6.2.3 in 4.6.1 saying that: "For multi-dimensional arrays or nested record of or set of types, an array or record of integer can be used as a short-hand notation for a nested index notation."
+
+If the value in the index notation is of an record of type not constrained to a single length and dimension of the value is not known at compilation time, the type of the expression cannot be determined in compilation time. In other word, such a reference is not strongly typed. E.g.
+
+type record of integer RoI;
+...
+var integer v_arr[2][2];
+var RoI v_index;
+if (rnd()< 0.5) { v_index := {0} }
+else { v_index := { 0, 1 }
+v_arr[v_index] := 2; // OK for v_index == {0, 1}, but not OK for v_index == {0}
+
+Using not strongly typed data leads to problems with error discovery in compilation time. Besides, it constitutes a significant problem for TTCN-3 tools that are dependent on strong typing as value references can appear in many syntactical constructions and all these places have to be fitted with a runtime type resolution.
+
+Proposal:
+Allow using values of record of inside the index notation only if the record of is restricted to a single length.
+
+Alternative proposal:
+Add a rule saying that in case the index value is of a record of type not constrained to a single length that is not a constant fulfilling conditions imposed by the restriction 10.b, an error will be generated if the indexing value contains a different number of elements than the dimension of the value being indexed.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0006646closed Gyorgy Rethy Missing semantic rules for the index and assignment notation 
related to 0006645closed Gyorgy Rethy Rules for array values 
Attached Filesdocx CR6762_v1.docx (54,934) 08-10-2014 11:37
http://oldforge.etsi.org/mantis/file_download.php?file_id=3112&type=bug
Issue History
Date ModifiedUsernameFieldChange
03-06-2014 09:23Tomas UrbanNew Issue
03-06-2014 09:45Jacob Wieland - SpirentNote Added: 0012068
03-06-2014 09:49Jacob Wieland - SpirentNote Edited: 0012068bug_revision_view_page.php?bugnote_id=12068#r21
07-10-2014 14:50Tomas UrbanAssigned To => Tomas Urban
07-10-2014 14:50Tomas UrbanStatusnew => assigned
08-10-2014 10:28Tomas UrbanDescription Updatedbug_revision_view_page.php?rev_id=77#r77
08-10-2014 11:25Tomas UrbanRelationship addedrelated to 0006646
08-10-2014 11:37Tomas UrbanFile Added: CR6762_v1.docx
08-10-2014 11:37Tomas UrbanNote Added: 0012279
08-10-2014 11:37Tomas UrbanAssigned ToTomas Urban => Jens Grabowski
08-10-2014 11:37Tomas UrbanStatusassigned => confirmed
08-10-2014 14:27Jens GrabowskiStatusconfirmed => resolved
08-10-2014 14:27Jens GrabowskiResolutionopen => fixed
08-10-2014 14:27Jens GrabowskiAssigned ToJens Grabowski => Gyorgy Rethy
05-11-2014 09:46Tomas UrbanRelationship addedrelated to 0006645
04-01-2015 21:16Gyorgy RethyNote Added: 0012616
04-01-2015 21:16Gyorgy RethyStatusresolved => closed
04-01-2015 21:16Gyorgy RethyFixed in Version => v4.7.1 (published 2015-06)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0012068) +
+ Jacob Wieland - Spirent    +
+ 03-06-2014 09:45    +
(edited on: 03-06-2014 09:49)
+ 		+ + + + +
+ I agree, I also think it should be restricted to arrays of known dimensions and only arrays of the right number of dimensions should be allowed which, of course, is only checkable at runtime, but can be assumed to be true at compile-time.
+
+If that is not the case, you get problem with generics (if the array type is generic over its element type, the dimensions could not be discernable if the dimensions of the element-type need to be taken into account as well).
+
+So, in my opinion, only direct lists of ArraySpec consitute a dimension-specifiction.
+
+This would mean that:
+
+type integer A[5][6] has two dimensions
+
+type A B[10][10] also has two dimensions
+
+
+
+
+
+ + + + + + + + + + +
+ (0012279) +
+ Tomas Urban    +
+ 08-10-2014 11:37    +
+ 		+ + + + +
+ Resolution uploaded. Please check.
+
+
+
+ + + + + + + + + + +
+ (0012616) +
+ Gyorgy Rethy    +
+ 04-01-2015 21:16    +
+ 		+ + + + +
+ Added to draft V4.6.3
+
+ + diff --git a/docs/mantis/CR6766.md b/docs/mantis/CR6766.md new file mode 100644 index 0000000000000000000000000000000000000000..9d33a45b441fb441ac0d594289a29d4853791e45 --- /dev/null +++ b/docs/mantis/CR6766.md @@ -0,0 +1,177 @@ + + + + + + + + + + + + + 0006766: enumeration facet applied to a union-simple-type-derivation should yield an enumeration type - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006766Part 09: Using XML with TTCN-3Technicalpublic03-06-2014 15:4604-01-2016 11:01
ReporterJacob Wieland - Spirent 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.6.1 (published 2015-06) 
Target Versionv4.7.1 (published 2016-07)Fixed in Versionv4.7.1 (published 2016-07) 
Clause Reference(s)7.5.3, 6.1.5
For STF discussion
Source (company - Author)Testing Technologies - Jacob Wieland
Summary0006766: enumeration facet applied to a union-simple-type-derivation should yield an enumeration type
DescriptionEXAMPLE 5 in section 7.5.3 describes a very strange mapping of enumeration-facet-restriction to a union type derivation.
+
+If a union type is restricted by enumeration facet, it should simply yield an enumeration type with the enumerated values instead of a complicated union type where each alternative needs to be restricted by all the available enumerated values (filtered by the already existing restrictions).
+
+As the mutual exclusitivity between alternatives is hard to enforce (i.e. string contains pretty much everything all other types contain), every alternative would have to be paired with every enumeration-facet-value to yield a proper variant.
+
+Also, in the example, the values to be used 20.0 and 50.0 would normally mapped to their equivalent (including .0) in XML, thereby violating the enumeration-facet-restriction. Therefore, the enumeration-facet must somehow be preserved in the variant-attributes like for enumerated types to allow the encoder to map 20.0 to 20.
+
+Mapping to enumeration type instead would make all of these problems go away. Also, I think the standard is inconsistent or should at least mention this special case in the mapping of enumeration facet (section 6.1.5).
+
+In my opinion, it should be changed so that a union type that contains at least one string type should be handled like derived from a string type (as that is the more general case) and if the union is derived only from number types, it should be handled like an enumeration type derived from number type). The resulting types are much easier to use in the TTCN-3.
+
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
duplicate of 0006752closed Gyorgy Rethy Rules for transformation of enumerated facet applied to union content 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
03-06-2014 15:46Jacob Wieland - SpirentNew Issue
03-06-2014 15:46Jacob Wieland - SpirentStatusnew => assigned
03-06-2014 15:46Jacob Wieland - SpirentAssigned To => Gyorgy Rethy
03-06-2014 15:47Jacob Wieland - SpirentRelationship addedrelated to 0006725
03-06-2014 15:47Jacob Wieland - SpirentRelationship addedrelated to 0006752
03-06-2014 15:47Jacob Wieland - SpirentRelationship deletedrelated to 0006725
05-11-2014 09:12Gyorgy RethyAssigned ToGyorgy Rethy => Tomas Urban
05-11-2014 09:14Gyorgy RethyAssigned ToTomas Urban => Gyorgy Rethy
05-11-2014 09:14Gyorgy RethyRelationship replacedduplicate of 0006752
18-12-2014 13:44Gyorgy RethyNote Added: 0012563
18-12-2014 13:44Gyorgy RethyStatusassigned => confirmed
29-12-2014 15:00Gyorgy RethyNote Added: 0012587
29-12-2014 15:00Gyorgy RethyTarget Versionv4.6.1 (published 2015-06) => v4.7.1 (published 2016-07)
05-11-2015 08:44Gyorgy RethyAssigned ToGyorgy Rethy => Axel Rennoch
05-11-2015 08:44Gyorgy RethyStatusconfirmed => assigned
27-12-2015 11:23Axel RennochNote Added: 0013648
27-12-2015 11:23Axel RennochStatusassigned => resolved
27-12-2015 11:23Axel RennochResolutionopen => fixed
27-12-2015 11:23Axel RennochAssigned ToAxel Rennoch => Gyorgy Rethy
04-01-2016 11:01Gyorgy RethyFixed in Version => v4.7.1 (published 2016-07)
04-01-2016 11:01Gyorgy RethyNote Added: 0013651
04-01-2016 11:01Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0012563) +
+ Gyorgy Rethy    +
+ 18-12-2014 13:44    +
+ 		+ + + + +
+ Set to confirmed to be in synch to CR 6752; solution is handled within CR6752.
+
+
+
+ + + + + + + + + + +
+ (0012587) +
+ Gyorgy Rethy    +
+ 29-12-2014 15:00    +
+ 		+ + + + +
+ Shifted to the next version together with CR6752.
+
+
+
+ + + + + + + + + + +
+ (0013648) +
+ Axel Rennoch    +
+ 27-12-2015 11:23    +
+ 		+ + + + +
+ resolved due to resolution of CR 6752
+
+
+
+ + + + + + + + + + +
+ (0013651) +
+ Gyorgy Rethy    +
+ 04-01-2016 11:01    +
+ 		+ + + + +
+ See CR 6752
+
+ + diff --git a/docs/mantis/CR6774.md b/docs/mantis/CR6774.md new file mode 100644 index 0000000000000000000000000000000000000000..4e54d5368c0a5b38886c6d6c71f188612872a3ba --- /dev/null +++ b/docs/mantis/CR6774.md @@ -0,0 +1,150 @@ + + + + + + + + + + + + + 0006774: Return values for altsteps - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006774Part 01: TTCN-3 Core LanguageNew Featurepublic16-06-2014 10:0223-09-2015 08:56
ReporterWolfgang Seka 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionwon't fix 
PlatformOSOS Version
Product Versionv4.5.1 (published 2013-04) 
Target Versionv4.8.1 (published 2016-07)Fixed in Version 
Clause Reference(s)16.2
Source (company - Author)     MCC160 - Wolfgang
Summary0006774: Return values for altsteps
DescriptionWith "-> value" acc. to cl. 22.2.2 in a receive statement a value can be stored in a variable. This concept shall be enhanced for altsteps as well:
+It shall be possible to declare a return value for an altstep which can be assigned to a variable with "-> value".
+
+NOTE: as for receive statements there is no need to assign the receive value to a variable directly with the ":=" operator (at least from MCC160's point of view).
+
Steps To Reproduce
Additional InformationUse case:
+
+Especially with SIP we cannot fully check the correctness of a message by means of receive templates but need to do further checking after we have received a message; furthermore we may need to respond to requests immediately and but we also may need to refer to the content of messages later on.
+ Now - we have scenarios where some requests need to be received in any order or some of them are even optional.
+ => it is useful to have a set of altsteps to receive a single Message, check it and respond to it.
+
+ So - what I would do when possible is e.g.
+ alt {
+   [] a_ReceiveCheckRespondToMessage1(...) -> value v_Message1 {...}
+   [] a_ReceiveCheckRespondToMessage2(...) -> value v_Message2 {...}
+   [] a_ReceiveCheckRespondToMessage3(...) -> value v_Message3 {...}
+   ...
+   [] t_Timer.timeout {...}
+ }
+
+=> improve readability, avoidance of "out" paramters
TagsNo tags attached.
Relationships
Attached Filespptx Discussion-CR6774.pptx (51,721) 06-08-2015 11:18
http://oldforge.etsi.org/mantis/file_download.php?file_id=3242&type=bug
Issue History
Date ModifiedUsernameFieldChange
16-06-2014 10:02Wolfgang SekaNew Issue
17-06-2014 11:57Gyorgy RethyAssigned To => Jens Grabowski
17-06-2014 11:57Gyorgy RethyStatusnew => assigned
17-06-2014 16:00Gyorgy RethyProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
17-06-2014 16:01Gyorgy RethyProduct Version => v4.5.1 (published 2013-04)
17-06-2014 16:01Gyorgy RethyTarget Version => v4.7.1 (published 2015-06)
06-11-2014 09:17Gyorgy RethyTarget Versionv4.7.1 (published 2015-06) => v4.8.1 (published 2016-07)
06-08-2015 11:18Jens GrabowskiFile Added: Discussion-CR6774.pptx
06-08-2015 11:19Jens GrabowskiNote Added: 0013110
06-08-2015 14:13Gyorgy RethyNote Added: 0013117
23-09-2015 08:54Jens GrabowskiNote Added: 0013246
23-09-2015 08:56Jens GrabowskiStatusassigned => closed
23-09-2015 08:56Jens GrabowskiResolutionopen => won't fix
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0013110) +
+ Jens Grabowski    +
+ 06-08-2015 11:19    +
+ 		+ + + + +
+ Slideset for STF internal discussion uploaded.
+
+
+
+ + + + + + + + + + +
+ (0013117) +
+ Gyorgy Rethy    +
+ 06-08-2015 14:13    +
+ 		+ + + + +
+ STF discussion 06-08-2015: After discussiong the analysis the STF view is that the feature would complicate the language with a lots of special rules. The same readibility can be achieved by using out parameters in altsteps and/or using components variables and commenting the code.
+
+
+
+ + + + + + + + + + +
+ (0013246) +
+ Jens Grabowski    +
+ 23-09-2015 08:54    +
+ 		+ + + + +
+ After a short Email discussion with the reporter, the CR will not be implemented. The gain by the feature compared with the complication of the language with lots of special rules is too low.
+
+ + diff --git a/docs/mantis/CR6775.md b/docs/mantis/CR6775.md new file mode 100644 index 0000000000000000000000000000000000000000..e39dfdfc32a1a1f48bd6377b3d555185dce12931 --- /dev/null +++ b/docs/mantis/CR6775.md @@ -0,0 +1,244 @@ + + + + + + + + + + + + + 0006775: getverdict from other component - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006775Part 01: TTCN-3 Core LanguageNew Featurepublic16-06-2014 13:3206-01-2015 17:54
ReporterAxel Rennoch 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityfeatureReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.7.1 (published 2015-06) 
Target Versionv4.7.1 (published 2015-06)Fixed in Versionv4.7.1 (published 2015-06) 
Clause Reference(s)24.3
Source (company - Author)Axel Rennoch
Summary0006775: getverdict from other component
DescriptionCurrently "getverdict" can only be applied to get the local verdict. However a component may be interested in the intermediate verdict of a different component, e.g. "mtc" wants to check the verdict of a parallel test component that has terminated some functional behaviour, but is still alive and ready to execute further behaviour.
+
+The proposal is to allow the application of "getverdict" also to other components in order to retrieve their verdicts according to the following example:
+
+var PTC v_ptc := PTC.create alive;
+var verdicttype v_result;
+v_ptc.start(f_preamble());
+v_ptc.done;
+v_result := v_ptc.getverdict;
+if (v_result==pass) {...} else {...};
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0006804closed Tomas Urban Part 06: TTCN-3 Control Interface TCI support for verdict assignment in done and killed operations 
Attached Filesdocx CR6775_v1_141010.docx (69,277) 10-10-2014 10:43
http://oldforge.etsi.org/mantis/file_download.php?file_id=3143&type=bug
docx CR6775_v2_141103.docx (94,708) 03-11-2014 10:47
http://oldforge.etsi.org/mantis/file_download.php?file_id=3146&type=bug
Issue History
Date ModifiedUsernameFieldChange
16-06-2014 13:32Axel RennochNew Issue
17-06-2014 11:57Gyorgy RethyAssigned To => Jens Grabowski
17-06-2014 11:57Gyorgy RethyStatusnew => assigned
19-06-2014 14:54Gyorgy RethyNote Added: 0012147
10-10-2014 10:43Jens GrabowskiFile Added: CR6775_v1_141010.docx
10-10-2014 10:43Jens GrabowskiNote Added: 0012352
10-10-2014 10:44Jens GrabowskiAssigned ToJens Grabowski => Tomas Urban
03-11-2014 10:47Tomas UrbanFile Added: CR6775_v2_141103.docx
03-11-2014 10:50Tomas UrbanNote Added: 0012372
03-11-2014 10:50Tomas UrbanAssigned ToTomas Urban => Jens Grabowski
04-11-2014 10:35Jens GrabowskiNote Added: 0012391
04-11-2014 10:35Jens GrabowskiAssigned ToJens Grabowski => Tomas Urban
04-11-2014 14:59Tomas UrbanRelationship addedrelated to 0006804
04-11-2014 16:17Tomas UrbanNote Added: 0012405
04-11-2014 16:17Tomas UrbanStatusassigned => resolved
04-11-2014 16:17Tomas UrbanFixed in Version => v4.7.1 (published 2015-06)
04-11-2014 16:17Tomas UrbanResolutionopen => fixed
04-11-2014 16:17Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
06-01-2015 17:54Gyorgy RethyNote Added: 0012646
06-01-2015 17:54Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0012147) +
+ Gyorgy Rethy    +
+ 19-06-2014 14:54    +
+ 		+ + + + +
+ STF discussion: check the technical solution when the function started on a PTC, its local verdict can be retrieved with the PTC.done statement using the assignment syntax -> v_myVerdictVar. Always returns a verdicttype.
+
+
+
+ + + + + + + + + + +
+ (0012352) +
+ Jens Grabowski    +
+ 10-10-2014 10:43    +
+ 		+ + + + +
+ First proposal. Please review!
+
+
+
+ + + + + + + + + + +
+ (0012372) +
+ Tomas Urban    +
+ 03-11-2014 10:50    +
+ 		+ + + + +
+ I am fine with the proposed resolution. I only made few cosmetic corrections. Please check the second version of the document and if it is OK with you, the CR can be marked as resolved.
+
+
+
+ + + + + + + + + + +
+ (0012391) +
+ Jens Grabowski    +
+ 04-11-2014 10:35    +
+ 		+ + + + +
+ Tomas, I am fine with your second version. However, please check if this CR also requires changes in parts 5 and/or 6. Either you resolve it in the context of this CR or provide a new CR.
+
+
+
+ + + + + + + + + + +
+ (0012405) +
+ Tomas Urban    +
+ 04-11-2014 16:17    +
+ 		+ + + + +
+ I created a related CR for TCI changes. The proposed resolution of this CR is acceptable and can be added to the next version of the TTCN-3 core language specification.
+
+
+
+ + + + + + + + + + +
+ (0012646) +
+ Gyorgy Rethy    +
+ 06-01-2015 17:54    +
+ 		+ + + + +
+ Added to draft V4.6.3.
+
+BNF is aligned to the syntax structure in the text: only one port redirect symbol is allowed even if both the verdict and component index are stored.
+
+ + diff --git a/docs/mantis/CR6776.md b/docs/mantis/CR6776.md new file mode 100644 index 0000000000000000000000000000000000000000..9750bf74c55f75ab57d6fc5d7a7b957a83bc53dc --- /dev/null +++ b/docs/mantis/CR6776.md @@ -0,0 +1,306 @@ + + + + + + + + + + + + + 0006776: Other characters allowed in namespaces should be replaced by "_" too - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006776Part 09: Using XML with TTCN-3Technicalpublic16-06-2014 15:0631-12-2014 14:06
ReporterGyorgy Rethy 
Assigned ToAxel Rennoch 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.5.1 (published 2013-04) 
Target Versionv4.6.1 (published 2015-06)Fixed in Versionv4.6.1 (published 2015-06) 
Clause Reference(s)5.2.2
For STF discussion
Source (company - Author)L.M.Ericsson
Summary0006776: Other characters allowed in namespaces should be replaced by "_" too
DescriptionCurrent text of rule b) requires replacing SPACE, FULL STOP, HYPEN-MINUS, COLON and SOLIDUS by a LOW LINE. However RFC2396 allows also other characters in (target) namespaces, which is translated to TTCN-3 module name(s), hence should also be replaced by LOW LINE.
+
+Such characters are:
+"!", "~", "*", "'", "(", ")", "?", "#",... (completeness to be checked)
+
+Alternatively, the rule could be reversed: change all characters not allowed in TTCN-3 identifiers (but also @) by LOW LINE.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR6776_resolution_v1.doc (113,664) 09-10-2014 16:00
http://oldforge.etsi.org/mantis/file_download.php?file_id=3133&type=bug
doc CR6776_resolution_v1.1.doc (118,784) 04-11-2014 10:02
http://oldforge.etsi.org/mantis/file_download.php?file_id=3153&type=bug
doc CR6776_resolution_v1.2.doc (118,784) 06-11-2014 11:52
http://oldforge.etsi.org/mantis/file_download.php?file_id=3171&type=bug
doc CR6776_resolution_v1.3.doc (119,296) 06-11-2014 12:20
http://oldforge.etsi.org/mantis/file_download.php?file_id=3173&type=bug
Issue History
Date ModifiedUsernameFieldChange
16-06-2014 15:06Gyorgy RethyNew Issue
18-06-2014 09:12Gyorgy RethyAssigned To => Gyorgy Rethy
18-06-2014 09:12Gyorgy RethyStatusnew => assigned
18-06-2014 09:12Gyorgy RethyTarget Version => v4.6.1 (published 2015-06)
18-06-2014 09:13Gyorgy RethyDescription Updatedbug_revision_view_page.php?rev_id=36#r36
18-06-2014 09:15Gyorgy RethyDescription Updatedbug_revision_view_page.php?rev_id=37#r37
09-10-2014 16:00Gyorgy RethyFile Added: CR6776_resolution_v1.doc
09-10-2014 16:02Gyorgy RethyNote Added: 0012332
09-10-2014 16:02Gyorgy RethyAssigned ToGyorgy Rethy => Axel Rennoch
09-10-2014 16:02Gyorgy RethyStatusassigned => confirmed
04-11-2014 10:02Axel RennochFile Added: CR6776_resolution_v1.1.doc
04-11-2014 10:02Axel RennochAssigned ToAxel Rennoch => Gyorgy Rethy
04-11-2014 10:02Axel RennochStatusconfirmed => assigned
04-11-2014 10:04Axel RennochNote Added: 0012388
04-11-2014 10:04Axel RennochStatusassigned => confirmed
06-11-2014 10:34Gyorgy RethyNote Added: 0012452
06-11-2014 10:35Gyorgy RethyAssigned ToGyorgy Rethy => Axel Rennoch
06-11-2014 11:52Axel RennochFile Added: CR6776_resolution_v1.2.doc
06-11-2014 11:53Axel RennochNote Added: 0012455
06-11-2014 11:54Axel RennochNote Added: 0012456
06-11-2014 11:54Axel RennochAssigned ToAxel Rennoch => Tomas Urban
06-11-2014 11:54Axel RennochStatusconfirmed => acknowledged
06-11-2014 12:20Tomas UrbanFile Added: CR6776_resolution_v1.3.doc
06-11-2014 12:21Tomas UrbanNote Added: 0012458
06-11-2014 12:21Tomas UrbanAssigned ToTomas Urban => Axel Rennoch
06-11-2014 12:21Tomas UrbanStatusacknowledged => confirmed
06-11-2014 12:46Axel RennochNote Added: 0012463
06-11-2014 12:46Axel RennochStatusconfirmed => resolved
06-11-2014 12:46Axel RennochResolutionopen => fixed
31-12-2014 14:06Gyorgy RethyNote Added: 0012599
31-12-2014 14:06Gyorgy RethyStatusresolved => closed
31-12-2014 14:06Gyorgy RethyFixed in Version => v4.6.1 (published 2015-06)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0012332) +
+ Gyorgy Rethy    +
+ 09-10-2014 16:02    +
+ 		+ + + + +
+ Resolution proposal uploaded.
+
+
+
+ + + + + + + + + + +
+ (0012388) +
+ Axel Rennoch    +
+ 04-11-2014 10:04    +
+ 		+ + + + +
+ proposed CR is fine, I just added some simple examples for the substition algorithm
+
+
+
+ + + + + + + + + + +
+ (0012452) +
+ Gyorgy Rethy    +
+ 06-11-2014 10:34    +
+ 		+ + + + +
+ STF dicsussion: No change in the text as it would cause backward incompatibility, add examples from the proposal.
+
+
+
+ + + + + + + + + + +
+ (0012455) +
+ Axel Rennoch    +
+ 06-11-2014 11:53    +
+ 		+ + + + +
+ file attached following the STF discussion.
+
+
+
+ + + + + + + + + + +
+ (0012456) +
+ Axel Rennoch    +
+ 06-11-2014 11:54    +
+ 		+ + + + +
+ Please have a final check of the examples before closing.
+
+
+
+ + + + + + + + + + +
+ (0012458) +
+ Tomas Urban    +
+ 06-11-2014 12:21    +
+ 		+ + + + +
+ I made only minor editorial changes (mostly change of the quotation characters). If you are happy with them, you can mark the issue as resolved.
+
+
+
+ + + + + + + + + + +
+ (0012463) +
+ Axel Rennoch    +
+ 06-11-2014 12:46    +
+ 		+ + + + +
+ I'm happy.
+
+
+
+ + + + + + + + + + +
+ (0012599) +
+ Gyorgy Rethy    +
+ 31-12-2014 14:06    +
+ 		+ + + + +
+ Added to draft V4.5.3
+
+ + diff --git a/docs/mantis/CR6777.md b/docs/mantis/CR6777.md new file mode 100644 index 0000000000000000000000000000000000000000..c6b23bd9009b323adc568fd7833b6fca550b92df --- /dev/null +++ b/docs/mantis/CR6777.md @@ -0,0 +1,100 @@ + + + + + + + + + + + + + 0006777: Normalization of target namespace values to be clarified - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006777Part 09: Using XML with TTCN-3Clarificationpublic16-06-2014 15:4626-01-2015 11:44
ReporterGyorgy Rethy 
Assigned ToAxel Rennoch 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.5.1 (published 2013-04) 
Target Versionv4.6.1 (published 2015-06)Fixed in Versionv4.6.1 (published 2015-06) 
Clause Reference(s)5.2.2
For STF discussion
Source (company - Author)L.M.Ericsson
Summary0006777: Normalization of target namespace values to be clarified
DescriptionCurrently it is not stated explicitly if target namespace values (when converted to TTCN-3 module names are handled literaly or by first un-escaping and resolving them, i.e.
+- "http://www.example.org [^] and "http://www.example.org/; [^] or
+- http://www.example.org/~wilbur [^] and http://www.example.org/%7ewilbur [^]
+will result the same module names or different module names?
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0006735closed Gyorgy Rethy Missing rules for transforming XSD namespaces into TTCN-3 module names 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
16-06-2014 15:46Gyorgy RethyNew Issue
16-06-2014 17:31Gyorgy RethyRelationship addedrelated to 0006735
16-06-2014 17:33Gyorgy RethyAssigned To => Gyorgy Rethy
16-06-2014 17:33Gyorgy RethyStatusnew => assigned
16-06-2014 17:34Gyorgy RethyNote Added: 0012092
05-11-2014 09:09Gyorgy RethyAssigned ToGyorgy Rethy => Axel Rennoch
06-11-2014 10:22Gyorgy RethyNote Added: 0012451
06-11-2014 10:22Gyorgy RethyStatusassigned => closed
06-11-2014 10:22Gyorgy RethyResolutionopen => fixed
06-11-2014 10:22Gyorgy RethyFixed in Version => v4.5.2 (interim 2014)
26-01-2015 11:44Gyorgy RethyFixed in Versionv4.5.2 (interim 2014) => v4.6.1 (published 2015-06)
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0012092) +
+ Gyorgy Rethy    +
+ 16-06-2014 17:34    +
+ 		+ + + + +
+ RESOLVED WITHIN CR 6735!
+
+
+
+ + + + + + + + + + +
+ (0012451) +
+ Gyorgy Rethy    +
+ 06-11-2014 10:22    +
+ 		+ + + + +
+ Been included in CR6735 in the interim version
+
+ + diff --git a/docs/mantis/CR6778.md b/docs/mantis/CR6778.md new file mode 100644 index 0000000000000000000000000000000000000000..b4808a901e28c04a2955e07aea4cd14bf15d2554 --- /dev/null +++ b/docs/mantis/CR6778.md @@ -0,0 +1,97 @@ + + + + + + + + + + + + + 0006778: Add language string TTCN-3:2015 for the new edition - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006778Part 01: TTCN-3 Core LanguageTechnicalpublic17-06-2014 16:1804-01-2015 21:13
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeveritytrivialReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.6.1 (published 2014-06) 
Target Versionv4.7.1 (published 2015-06)Fixed in Versionv4.7.1 (published 2015-06) 
Clause Reference(s)8.1
Source (company - Author)L.M.Ericsson
Summary0006778: Add language string TTCN-3:2015 for the new edition
DescriptionA new language string shall be added for the new version
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
17-06-2014 16:18Gyorgy RethyNew Issue
18-06-2014 09:16Gyorgy RethyAssigned To => Gyorgy Rethy
18-06-2014 09:16Gyorgy RethySeverityminor => trivial
18-06-2014 09:16Gyorgy RethyStatusnew => assigned
18-06-2014 09:16Gyorgy RethyProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
18-06-2014 09:17Gyorgy RethyProduct Version => v4.6.1 (published 2014-06)
18-06-2014 09:17Gyorgy RethyTarget Version => v4.7.1 (published 2015-06)
19-06-2014 14:06Gyorgy RethyNote Added: 0012145
19-06-2014 14:06Gyorgy RethyStatusassigned => resolved
19-06-2014 14:06Gyorgy RethyFixed in Version => v4.7.1 (published 2015-06)
19-06-2014 14:06Gyorgy RethyResolutionopen => fixed
20-06-2014 11:53Gyorgy RethyFixed in Versionv4.7.1 (published 2015-06) =>
04-01-2015 21:13Gyorgy RethyNote Added: 0012615
04-01-2015 21:13Gyorgy RethyStatusresolved => closed
04-01-2015 21:13Gyorgy RethyFixed in Version => v4.7.1 (published 2015-06)
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0012145) +
+ Gyorgy Rethy    +
+ 19-06-2014 14:06    +
+ 		+ + + + +
+ To be added to master copy after the interim version V4.6.2 has been produced.
+
+
+
+ + + + + + + + + + +
+ (0012615) +
+ Gyorgy Rethy    +
+ 04-01-2015 21:13    +
+ 		+ + + + +
+ Added to draft V4.6.3
+
+ + diff --git a/docs/mantis/CR6779.md b/docs/mantis/CR6779.md new file mode 100644 index 0000000000000000000000000000000000000000..411c0aba7c20258c5f091f9770220f65021f1f93 --- /dev/null +++ b/docs/mantis/CR6779.md @@ -0,0 +1,63 @@ + + + + + + + + + + + + + 0006779: Correct figures 6 and 7 to show borders of test system - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006779Part 01: TTCN-3 Core LanguageEditorialpublic18-06-2014 09:5020-06-2014 11:47
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.6.1 (published 2014-06) 
Target Versionv4.7.1 (published 2015-06)Fixed in Versionv4.6.2 (interim 2014) 
Clause Reference(s)9.1
Source (company - Author)L.M.Ericsson
Summary0006779: Correct figures 6 and 7 to show borders of test system
DescriptionCurrently the are outside of the picture
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
18-06-2014 09:50Gyorgy RethyNew Issue
18-06-2014 09:50Gyorgy RethyAssigned To => Gyorgy Rethy
18-06-2014 09:50Gyorgy RethyStatusnew => assigned
18-06-2014 09:50Gyorgy RethyTarget Version => v4.7.1 (published 2015-06)
18-06-2014 15:07Gyorgy RethyNote Added: 0012129
18-06-2014 15:07Gyorgy RethyStatusassigned => closed
18-06-2014 15:07Gyorgy RethyResolutionopen => fixed
18-06-2014 15:07Gyorgy RethyFixed in Version => v4.7.1 (published 2015-06)
20-06-2014 11:47Gyorgy RethyFixed in Versionv4.7.1 (published 2015-06) => v4.6.2 (interim 2014)
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0012129) +
+ Gyorgy Rethy    +
+ 18-06-2014 15:07    +
+ 		+ + + + +
+ Implemented in master copy V4.6.2
+
+ + diff --git a/docs/mantis/CR6780.md b/docs/mantis/CR6780.md new file mode 100644 index 0000000000000000000000000000000000000000..5ad71f4c8a7489ac65c105fec92d7420aa1b12b6 --- /dev/null +++ b/docs/mantis/CR6780.md @@ -0,0 +1,107 @@ + + + + + + + + + + + + + 0006780: Sender clause should implicitly define the content of the missing from clause - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006780Part 01: TTCN-3 Core LanguageTechnicalpublic18-06-2014 15:3920-06-2014 11:45
ReporterTomas Urban 
Assigned To 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionwon't fix 
PlatformOSOS Version
Product Versionv4.6.1 (published 2014-06) 
Target Versionv4.7.1 (published 2015-06)Fixed in Version 
Clause Reference(s)22.2.2
Source (company - Author)STF 478
Summary0006780: Sender clause should implicitly define the content of the missing from clause
DescriptionIf a receiving statement contains a sender clause, but the from clause is missing, the from clause should be defined from the sender clause implicitly in the following way:
+
+var address v_addr;
+p.receive -> sender v_addr;
+
+is equal to
+p.receive from address:? -> sender v_addr;
+
+This way the language rule prevents unnecessary crashes of the testing code caused by incompatibility of the actual sender and the variable used for storing it. A mismatch will be detected instead, which is a situation that can be gracefully handled by the TE.
+
+Notice that the described situation is not possible with values as the value clause can be present only when the matching template is defined. Similar solution would be possible for the sender clause (i.e. to bind the sender clause to a presence of the from clause), but such a change wouldn't be backwards compatible.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0006781closed Gyorgy Rethy Type compatibility of the from and sender clause 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
18-06-2014 15:39Tomas UrbanNew Issue
18-06-2014 15:52Tomas UrbanRelationship addedrelated to 0006781
19-06-2014 15:20Gyorgy RethyNote Added: 0012150
20-06-2014 08:56Tomas UrbanNote Added: 0012173
20-06-2014 08:56Tomas UrbanStatusnew => closed
20-06-2014 08:56Tomas UrbanResolutionopen => won't fix
20-06-2014 11:44Gyorgy RethyProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
20-06-2014 11:45Gyorgy RethyProduct Version => v4.6.1 (published 2014-06)
20-06-2014 11:45Gyorgy RethyTarget Version => v4.7.1 (published 2015-06)
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0012150) +
+ Gyorgy Rethy    +
+ 19-06-2014 15:20    +
+ 		+ + + + +
+ STF discussion: do not make this addition: this addition could cause DTE when the given branch is not successful and would be a backward incompatible change.
+
+
+
+ + + + + + + + + + +
+ (0012173) +
+ Tomas Urban    +
+ 20-06-2014 08:56    +
+ 		+ + + + +
+ As the decision of the STF is to reject the CR, the issue is closed as "won't fix".
+
+ + diff --git a/docs/mantis/CR6781.md b/docs/mantis/CR6781.md new file mode 100644 index 0000000000000000000000000000000000000000..d189cf37e9dc8d73e17e2906c96732ce13cadbad --- /dev/null +++ b/docs/mantis/CR6781.md @@ -0,0 +1,133 @@ + + + + + + + + + + + + + 0006781: Type compatibility of the from and sender clause - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006781Part 01: TTCN-3 Core LanguageTechnicalpublic18-06-2014 15:5105-01-2015 17:25
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.6.1 (published 2014-06) 
Target Versionv4.7.1 (published 2015-06)Fixed in Versionv4.7.1 (published 2015-06) 
Clause Reference(s)22.2.2
Source (company - Author)STF 478
Summary0006781: Type compatibility of the from and sender clause
DescriptionThere's currently no formal requirement for type compatibility between the template in the from clause and the variable in the sender clause. However, if these entities are of incompatible types, the operation will always result in an error according to the restriction 22.2.2.e (and similar restrictions for the remaining blocking operations).
+
+Adding the formal requirement doesn't actually prevent the error from happening, but the added rule might inspire tool vendors to detect this situation in the compilation stage, where correction of test suite errors is the cheapest. Please notice that similar requirement exists for e.g. for the value clause, probably for the same reason.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0006780closed  Sender clause should implicitly define the content of the missing from clause 
Attached Filesdocx CR6781_v1.docx (52,570) 20-06-2014 09:34
http://oldforge.etsi.org/mantis/file_download.php?file_id=3068&type=bug
Issue History
Date ModifiedUsernameFieldChange
18-06-2014 15:51Tomas UrbanNew Issue
18-06-2014 15:52Tomas UrbanRelationship addedrelated to 0006780
20-06-2014 09:06Tomas UrbanAssigned To => Tomas Urban
20-06-2014 09:06Tomas UrbanStatusnew => assigned
20-06-2014 09:34Tomas UrbanFile Added: CR6781_v1.docx
20-06-2014 09:35Tomas UrbanNote Added: 0012175
20-06-2014 09:35Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
20-06-2014 09:35Tomas UrbanStatusassigned => confirmed
20-06-2014 11:38Gyorgy RethyProduct Version => v4.6.1 (published 2014-06)
20-06-2014 11:38Gyorgy RethyTarget Version => v4.7.1 (published 2015-06)
08-10-2014 09:28Gyorgy RethyAssigned ToGyorgy Rethy => Axel Rennoch
08-10-2014 09:28Gyorgy RethyStatusconfirmed => assigned
08-10-2014 09:29Gyorgy RethyStatusassigned => confirmed
08-10-2014 12:08Axel RennochAssigned ToAxel Rennoch => Gyorgy Rethy
08-10-2014 12:08Axel RennochStatusconfirmed => assigned
08-10-2014 12:09Axel RennochNote Added: 0012280
08-10-2014 12:09Axel RennochStatusassigned => confirmed
08-10-2014 16:19Gyorgy RethyStatusconfirmed => resolved
08-10-2014 16:19Gyorgy RethyResolutionopen => fixed
08-10-2014 16:19Gyorgy RethyFixed in Version => v4.7.1 (published 2015-06)
05-01-2015 17:25Gyorgy RethyNote Added: 0012623
05-01-2015 17:25Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0012175) +
+ Tomas Urban    +
+ 20-06-2014 09:35    +
+ 		+ + + + +
+ Resolution proposal uploaded. Please check.
+
+
+
+ + + + + + + + + + +
+ (0012280) +
+ Axel Rennoch    +
+ 08-10-2014 12:09    +
+ 		+ + + + +
+ proposal is fine
+
+
+
+ + + + + + + + + + +
+ (0012623) +
+ Gyorgy Rethy    +
+ 05-01-2015 17:25    +
+ 		+ + + + +
+ Added to draft V4.6.3
+
+ + diff --git a/docs/mantis/CR6782.md b/docs/mantis/CR6782.md new file mode 100644 index 0000000000000000000000000000000000000000..bb0b0ac567a9da4f816e72329cffcbdad82da3fc --- /dev/null +++ b/docs/mantis/CR6782.md @@ -0,0 +1,131 @@ + + + + + + + + + + + + + 0006782: Complement matching should be allowed for template(present)-s - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006782Part 01: TTCN-3 Core LanguageTechnicalpublic19-06-2014 11:5205-01-2015 19:05
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.6.1 (published 2014-06) 
Target Versionv4.7.1 (published 2015-06)Fixed in Versionv4.7.1 (published 2015-06) 
Clause Reference(s)15.8
Source (company - Author)L.M.Ericsson
Summary0006782: Complement matching should be allowed for template(present)-s
DescriptionCurrently table 12 excludes using complemented list for templates with present restriction. It should be allowed.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
19-06-2014 11:52Gyorgy RethyNew Issue
19-06-2014 14:58Gyorgy RethyNote Added: 0012148
19-06-2014 15:42Gyorgy RethyProduct Version => v4.6.1 (published 2014-06)
19-06-2014 15:42Gyorgy RethyTarget Version => v4.7.1 (published 2015-06)
19-06-2014 15:43Gyorgy RethyNote Added: 0012153
19-06-2014 15:43Gyorgy RethyStatusnew => resolved
19-06-2014 15:43Gyorgy RethyFixed in Version => v4.7.1 (published 2015-06)
19-06-2014 15:43Gyorgy RethyResolutionopen => fixed
19-06-2014 15:43Gyorgy RethyAssigned To => Gyorgy Rethy
20-06-2014 11:53Gyorgy RethyFixed in Versionv4.7.1 (published 2015-06) =>
05-01-2015 19:05Gyorgy RethyNote Added: 0012634
05-01-2015 19:05Gyorgy RethyStatusresolved => closed
05-01-2015 19:05Gyorgy RethyFixed in Version => v4.7.1 (published 2015-06)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0012148) +
+ Gyorgy Rethy    +
+ 19-06-2014 14:58    +
+ 		+ + + + +
+ STF discussion: no reason identified why disallow complemented matching for template(present).
+
+
+
+ + + + + + + + + + +
+ (0012153) +
+ Gyorgy Rethy    +
+ 19-06-2014 15:43    +
+ 		+ + + + +
+ After the interim version V4.6.2 has been produced, add "Yes" to the "ComplementedList" column of row "present" of table 12.
+
+
+
+ + + + + + + + + + +
+ (0012634) +
+ Gyorgy Rethy    +
+ 05-01-2015 19:05    +
+ 		+ + + + +
+ Implemented in draft V4.6.3
+
+ + diff --git a/docs/mantis/CR6783.md b/docs/mantis/CR6783.md new file mode 100644 index 0000000000000000000000000000000000000000..f6defe5a8cecff0ee8040a5fdaa47e9ab1ea7eaa --- /dev/null +++ b/docs/mantis/CR6783.md @@ -0,0 +1,452 @@ + + + + + + + + + + + + + 0006783: Wrong syntax to save exception parameters - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006783Part 01: TTCN-3 Core LanguageTechnicalpublic19-06-2014 12:2104-01-2015 21:19
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.6.1 (published 2014-06) 
Target Versionv4.7.1 (published 2015-06)Fixed in Versionv4.7.1 (published 2015-06) 
Clause Reference(s)22.3.6
Source (company - Author)L.M.Ericsson
Summary0006783: Wrong syntax to save exception parameters
DescriptionIn the Syntactical Structure part for the Catch operation, the "storing message part" syntax is used:
+[ "->" [ value ( VariableRef |
+                 ( "(" { VariableRef [ ":=" FieldOrTypeReference ][","] } ")" )
+                ) ]
+instead of "storing the parameter" syntax used in other procedure-based operations, e.g. in getreply, where storing the whole reply is using the value keyword and storing individual parameters is using the param keyword:
+[ "->" [ value VariableRef ]
+       [ param "(" { ( VariableRef ":=" ParameterIdentifier ) "," } |
+                   { ( VariableRef | "-" ) "," }
+               ")" ]
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0006736closed Gyorgy Rethy new matching mechanism for binary string types 
Attached Filesdocx CR6783_v1.docx (65,026) 20-06-2014 08:24
http://oldforge.etsi.org/mantis/file_download.php?file_id=3065&type=bug
docx CR6783_v1_alt.docx (56,064) 20-06-2014 08:26
http://oldforge.etsi.org/mantis/file_download.php?file_id=3066&type=bug
docx CR6783_v3.docx (16,586) 09-10-2014 12:09
http://oldforge.etsi.org/mantis/file_download.php?file_id=3127&type=bug
Issue History
Date ModifiedUsernameFieldChange
19-06-2014 12:21Gyorgy RethyNew Issue
19-06-2014 12:31Jacob Wieland - SpirentNote Added: 0012141
19-06-2014 15:07Gyorgy RethyNote Added: 0012149
19-06-2014 15:07Gyorgy RethyDescription Updatedbug_revision_view_page.php?rev_id=43#r43
20-06-2014 07:52Tomas UrbanAssigned To => Tomas Urban
20-06-2014 07:52Tomas UrbanStatusnew => assigned
20-06-2014 08:06Jacob Wieland - SpirentNote Added: 0012168
20-06-2014 08:24Tomas UrbanFile Added: CR6783_v1.docx
20-06-2014 08:26Tomas UrbanFile Added: CR6783_v1_alt.docx
20-06-2014 08:38Tomas UrbanNote Added: 0012170
20-06-2014 08:38Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
20-06-2014 08:38Tomas UrbanStatusassigned => confirmed
20-06-2014 08:39Tomas UrbanNote Edited: 0012170bug_revision_view_page.php?bugnote_id=12170#r57
20-06-2014 11:38Gyorgy RethyTarget Version => v4.7.1 (published 2015-06)
08-10-2014 09:27Gyorgy RethyAssigned ToGyorgy Rethy => Axel Rennoch
08-10-2014 15:57Axel RennochNote Added: 0012289
08-10-2014 15:57Axel RennochAssigned ToAxel Rennoch => Gyorgy Rethy
08-10-2014 15:57Axel RennochStatusconfirmed => assigned
08-10-2014 15:58Axel RennochNote Added: 0012290
08-10-2014 15:58Axel RennochStatusassigned => confirmed
08-10-2014 16:21Gyorgy RethyNote Added: 0012296
08-10-2014 16:21Gyorgy RethyAssigned ToGyorgy Rethy => Axel Rennoch
09-10-2014 10:29Gyorgy RethyNote Added: 0012312
09-10-2014 12:09Axel RennochFile Added: CR6783_v3.docx
09-10-2014 12:10Axel RennochNote Added: 0012316
09-10-2014 12:45Axel RennochAssigned ToAxel Rennoch => Tomas Urban
09-10-2014 12:45Axel RennochStatusconfirmed => assigned
09-10-2014 12:46Axel RennochNote Added: 0012321
09-10-2014 12:46Axel RennochStatusassigned => confirmed
09-10-2014 14:13Tomas UrbanRelationship addedrelated to 0006736
09-10-2014 14:18Tomas UrbanNote Added: 0012325
09-10-2014 14:18Tomas UrbanStatusconfirmed => resolved
09-10-2014 14:18Tomas UrbanResolutionopen => fixed
09-10-2014 14:18Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
04-01-2015 21:19Gyorgy RethyNote Added: 0012617
04-01-2015 21:19Gyorgy RethyStatusresolved => closed
04-01-2015 21:19Gyorgy RethyFixed in Version => v4.7.1 (published 2015-06)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0012141) +
+ Jacob Wieland - Spirent    +
+ 19-06-2014 12:31    +
+ 		+ + + + +
+ Exceptions have no parameters. They are a special kind of message.
+
+
+
+ + + + + + + + + + +
+ (0012149) +
+ Gyorgy Rethy    +
+ 19-06-2014 15:07    +
+ 		+ + + + +
+ STF discussion: in the BNF separate message and procedure storing rules. Delete storing part of messages for the Catch operation.
+
+
+
+ + + + + + + + + + +
+ (0012168) +
+ Jacob Wieland - Spirent    +
+ 20-06-2014 08:06    +
+ 		+ + + + +
+ I still don't understand the issue here at all. What's wrong with something that has been working for years? If an exception is caught, there are no parameters to be assigned, just the exception value. Therefore, storing it like a message makes more sense than storing it like a parameter list.
+
+
+
+ + + + + + + + + + +
+ (0012170) +
+ Tomas Urban    +
+ 20-06-2014 08:38    +
(edited on: 20-06-2014 08:39)
+ 		+ + + + +
+ I prepared two alternative solutions. The first one (CR6783_v1.docx) unifies the value redirect for getreply and catch so that only the simple syntax is allowed as requested in the CR.
+
+However, since the current catch statement actually describes the extended syntax, the alternative proposal (CR6783_v1_alt.docx) changes only the BNF so that only the getreply statement uses the simplified form. Since the base proposal also affects the text of the catch operation, I am afraid that it would introduce backwards incompatibility. If the alternative proposal is taken into use instead of the base one, similar changes as in 0006736 shall be made in the syntax description of the catch operation as it still uses the same syntax for value redirect assignments on the BNF level as the receive operation (or the BNF should disallow the @decoded clause for the catch operation).
+
+
+
+
+
+ + + + + + + + + + +
+ (0012289) +
+ Axel Rennoch    +
+ 08-10-2014 15:57    +
+ 		+ + + + +
+ Following the previous STF discussion there should be some unification/modification of the storing rules and the first resolution may be selected. However we may think about also allowing the "previous" syntax for keeping backward compatibility, as a deprecated approach?
+
+
+
+ + + + + + + + + + +
+ (0012290) +
+ Axel Rennoch    +
+ 08-10-2014 15:58    +
+ 		+ + + + +
+ The CR solution may need a final STF decision.
+
+
+
+ + + + + + + + + + +
+ (0012296) +
+ Gyorgy Rethy    +
+ 08-10-2014 16:21    +
+ 		+ + + + +
+ Axel, pls. keep the CR at yourself until the STF decision.
+
+
+
+ + + + + + + + + + +
+ (0012312) +
+ Gyorgy Rethy    +
+ 09-10-2014 10:29    +
+ 		+ + + + +
+ STF discussion: correct getreply syntax in text to be in synch with BNF and allow extended reference. Catch is in principle OK, but check consistency of the text with the BNF. Also make those changes in CR 6736
+
+
+
+ + + + + + + + + + +
+ (0012316) +
+ Axel Rennoch    +
+ 09-10-2014 12:10    +
+ 		+ + + + +
+ new syntax part for getreply in text (also considering CR6736_v5).
+
+
+
+ + + + + + + + + + +
+ (0012321) +
+ Axel Rennoch    +
+ 09-10-2014 12:46    +
+ 		+ + + + +
+ Please confirm latest update following the STF discussion
+
+
+
+ + + + + + + + + + +
+ (0012325) +
+ Tomas Urban    +
+ 09-10-2014 14:18    +
+ 		+ + + + +
+ The proposed resolution fixes the problem by extending the syntactical description of the getvalue operation.
+
+It is ready to be added to the next version of the TTCN-3 standard. Please make sure that the changes proposed in the resolution of the related CR 0006736 are not overwritten by this CR.
+
+
+
+ + + + + + + + + + +
+ (0012617) +
+ Gyorgy Rethy    +
+ 04-01-2015 21:19    +
+ 		+ + + + +
+ Added to drfat V4.6.3
+
+ + diff --git a/docs/mantis/CR6784.md b/docs/mantis/CR6784.md new file mode 100644 index 0000000000000000000000000000000000000000..5f78ae08e1b20612f72219be2ac6368fd1350537 --- /dev/null +++ b/docs/mantis/CR6784.md @@ -0,0 +1,63 @@ + + + + + + + + + + + + + 0006784: Replace "yooleany essor" with "preprocessor" - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006784Part 01: TTCN-3 Core LanguageEditorialpublic19-06-2014 17:1420-06-2014 11:44
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.6.1 (published 2014-06) 
Target Versionv4.7.1 (published 2015-06)Fixed in Versionv4.6.2 (interim 2014) 
Clause Reference(s)Annex D
Source (company - Author)L.M.Ericsson
Summary0006784: Replace "yooleany essor" with "preprocessor"
Descriptionappears in each sub-clauses
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
has duplicate 0006725closed Gyorgy Rethy Strange character sequence for "preprocessor" 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
19-06-2014 17:14Gyorgy RethyNew Issue
19-06-2014 17:14Gyorgy RethyStatusnew => assigned
19-06-2014 17:14Gyorgy RethyAssigned To => Gyorgy Rethy
19-06-2014 17:17Gyorgy RethyNote Added: 0012161
19-06-2014 17:17Gyorgy RethyStatusassigned => closed
19-06-2014 17:17Gyorgy RethyResolutionopen => fixed
19-06-2014 17:17Gyorgy RethyFixed in Version => v4.6.2 (interim 2014)
19-06-2014 17:21Gyorgy RethyRelationship addedhas duplicate 0006725
20-06-2014 11:44Gyorgy RethyTarget Version => v4.7.1 (published 2015-06)
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0012161) +
+ Gyorgy Rethy    +
+ 19-06-2014 17:17    +
+ 		+ + + + +
+ Fixed in master copy
+
+ + diff --git a/docs/mantis/CR6785.md b/docs/mantis/CR6785.md new file mode 100644 index 0000000000000000000000000000000000000000..b6af344bfcbed5017e200b409add1cf112dd1a3a --- /dev/null +++ b/docs/mantis/CR6785.md @@ -0,0 +1,470 @@ + + + + + + + + + + + + + 0006785: Change name and add description of string_encoding parameter - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006785Part 01: TTCN-3 Core LanguageClarificationpublic20-06-2014 09:1906-01-2015 18:41
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.6.1 (published 2014-06) 
Target Versionv4.7.1 (published 2015-06)Fixed in Versionv4.7.1 (published 2015-06) 
Clause Reference(s)C.5.3, C.5.4
Source (company - Author)L.M.Ericsson
Summary0006785: Change name and add description of string_encoding parameter
DescriptionIn the encvalue_unichar and decvalue_unichar predefined functions the parameter string_encoding is specified. Its name is the same as the name of the similar parameter used in the oct2unichar and unichar2oct predefined functions, however its semantical behaviour is completely different. It is controlling how to serialize the universal charstring to the bitstring sent to the encoder and deserialize the bitstring received from the codec.
+
+Proposed soltion:
+change the name of the parameter to "serialization"
+Add a textual description to the first paragraph specifying what the parameter controls.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR6785_v1.docx (50,571) 04-11-2014 14:10
http://oldforge.etsi.org/mantis/file_download.php?file_id=3159&type=bug
docx CR6785_v2.docx (52,258) 06-11-2014 12:12
http://oldforge.etsi.org/mantis/file_download.php?file_id=3172&type=bug
docx CR6785_v3.docx (52,752) 06-11-2014 13:34
http://oldforge.etsi.org/mantis/file_download.php?file_id=3177&type=bug
Issue History
Date ModifiedUsernameFieldChange
20-06-2014 09:19Gyorgy RethyNew Issue
20-06-2014 10:57Gyorgy RethyProduct Version => v4.6.1 (published 2014-06)
20-06-2014 10:57Gyorgy RethyTarget Version => v4.7.1 (published 2015-06)
20-06-2014 11:40Jacob Wieland - SpirentNote Added: 0012186
06-10-2014 12:22Gyorgy RethyNote Added: 0012230
06-10-2014 16:41Jacob Wieland - SpirentNote Added: 0012239
03-11-2014 16:38Gyorgy RethyAssigned To => Tomas Urban
03-11-2014 16:38Gyorgy RethyStatusnew => assigned
04-11-2014 13:57Tomas UrbanNote Added: 0012399
04-11-2014 14:10Tomas UrbanFile Added: CR6785_v1.docx
04-11-2014 14:36Tomas UrbanNote Added: 0012403
04-11-2014 14:36Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
04-11-2014 14:36Tomas UrbanStatusassigned => confirmed
04-11-2014 18:54Jacob Wieland - SpirentNote Added: 0012410
04-11-2014 18:58Jacob Wieland - SpirentNote Edited: 0012410bug_revision_view_page.php?bugnote_id=12410#r95
05-11-2014 16:39Gyorgy RethyNote Added: 0012440
05-11-2014 17:11Gyorgy RethyNote Added: 0012441
05-11-2014 17:12Gyorgy RethyAssigned ToGyorgy Rethy => Tomas Urban
05-11-2014 17:13Gyorgy RethyNote Edited: 0012441bug_revision_view_page.php?bugnote_id=12441#r97
05-11-2014 17:14Gyorgy RethyNote Edited: 0012441bug_revision_view_page.php?bugnote_id=12441#r98
06-11-2014 12:12Tomas UrbanFile Added: CR6785_v2.docx
06-11-2014 12:13Tomas UrbanNote Added: 0012457
06-11-2014 12:13Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
06-11-2014 13:34Gyorgy RethyFile Added: CR6785_v3.docx
06-11-2014 13:35Gyorgy RethyNote Added: 0012466
06-11-2014 13:36Gyorgy RethyAssigned ToGyorgy Rethy => Tomas Urban
06-11-2014 14:06Tomas UrbanNote Added: 0012469
06-11-2014 14:06Tomas UrbanStatusconfirmed => resolved
06-11-2014 14:06Tomas UrbanFixed in Version => v4.7.1 (published 2015-06)
06-11-2014 14:06Tomas UrbanResolutionopen => fixed
06-11-2014 14:06Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
06-01-2015 18:41Gyorgy RethyNote Added: 0012652
06-01-2015 18:41Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0012186) +
+ Jacob Wieland - Spirent    +
+ 20-06-2014 11:40    +
+ 		+ + + + +
+ Can you explain the difference? I don't see one.
+
+
+
+ + + + + + + + + + +
+ (0012230) +
+ Gyorgy Rethy    +
+ 06-10-2014 12:22    +
+ 		+ + + + +
+ The encvalue/decvalue functions are calling the/a (textual) codec and they return what the codec is actually returns; for example, to a SIP encoder I can send a TTCN-3 abstract value representing a SIP message and get the encoded SIP message, i.e. a sequence of (abstract) unicode characters: this doesn't have any encoding. This sequence of characters are sent by the codec to the TE as a bitstring that the TE has to convert to abstract character data: the string_encoding parameter defines the type of serialization the encoder uses when creating the bitstring sent to the TE. Actually, if an internal control mechanism would handle this at TCI, this parameter would not be needed at all in TTCN-3 (or we could say that if the parameter is missing, it handled at TCI automatically).
+
+The oct2unichar and unichar2oct are converting the values within the TE (as seen by the user) and the string_encoding parameter is really controlling how the TTCN-3 characters are encoded within the TTCN-3 octetstring value.
+
+
+
+ + + + + + + + + + +
+ (0012239) +
+ Jacob Wieland - Spirent    +
+ 06-10-2014 16:41    +
+ 		+ + + + +
+ I still do not really get what you are saying at all.
+
+How does this relate to the equivalency:
+
+encvalue_unichar(val, dec_rule) == oct2unichar(bit2oct(encvalue(val)), dec_rule)
+
+Here, obviously, the dec_rule has the same semantics, it is used to determine how to deserialize the bits generated by the (binary) encoder as character data.
+
+The same is true for the decvalue_unichar function.
+
+What is a textual codec?
+
+
+
+ + + + + + + + + + +
+ (0012399) +
+ Tomas Urban    +
+ 04-11-2014 13:57    +
+ 		+ + + + +
+ Jacob, you are absolutely right and the unichar functions do work exactly as you describe. The problem is that a user that doesn't read the specification carefuly might get an impression that the parameter is an instruction to the codec (especially if it is a textual codec) influencing the encoding of the value. For that reason we want to change the name of the parameter so that it is more obvious what it actually does.
+
+
+
+ + + + + + + + + + +
+ (0012403) +
+ Tomas Urban    +
+ 04-11-2014 14:36    +
+ 		+ + + + +
+ Proposal uploaded. Please review.
+
+
+
+ + + + + + + + + + +
+ (0012410) +
+ Jacob Wieland - Spirent    +
+ 04-11-2014 18:54    +
(edited on: 04-11-2014 18:58)
+ 		+ + + + +
+ I think the terminus string-encoding is pretty commonly used while I have never heard the term string serialization. Sure, it might be confused with encoding as used otherwise in the standard, but do we really have to invent new words because of that?
+
+Also, I still do not get the "semantic difference" to the same parameter in oct2unichar and unichar2oct.
+
+
+
+
+
+ + + + + + + + + + +
+ (0012440) +
+ Gyorgy Rethy    +
+ 05-11-2014 16:39    +
+ 		+ + + + +
+ http://en.wikipedia.org/wiki/Serialization [^]
+You are rigth, encoding and serialization are pritty much similar, sometimes the same thing. Both terms are used in computing, but serialization is not used in networking terminology. This term is selected to make the distinction.
+
+
+
+ + + + + + + + + + +
+ (0012441) +
+ Gyorgy Rethy    +
+ 05-11-2014 17:11    +
(edited on: 05-11-2014 17:14)
+ 		+ + + + +
+ My understanding of the semantical difference is:
+
+In oct2unichar and unichar2oct the string_encoding parameter is directly influencing the return value of these functions, I think their semantics is clear.
+
+Now, if looking at decvalue_unichar. Let encoded_value be a raw SIP message received from the line (note, it has several options, ie. short/long header formats, headers are unordered, possible line breaks etc.), so we want to send it to a codec for decoding. The codec will decode it into an abstract TTCN-3 data e.g. SIP_PDU, this is the type of decoded_value. Pls. note, the raw SIP message is a character string only it doesn't need any identification of string encoding. My understanding is that the string_serialization controls how our raw SIP message will be serialized by the TE into a bitstring when sending to the codec. Pls. correct me if I'm wrong.
+
+Shall it appear in the TTCN-3 code or should it be a tool internal issue, I do not really know, maybe allowing it in the TTCN-3 code gives more option to change the codec.
+
+Anyway, in both cases, if I'm correct or I'm wrong, the purpose of the parameter seems to be unclear from the current text.
+
+
+
+
+
+ + + + + + + + + + +
+ (0012457) +
+ Tomas Urban    +
+ 06-11-2014 12:13    +
+ 		+ + + + +
+ Textual description of the encvalue_unichar and decvalue_unichar functions addded. Please review.
+
+
+
+ + + + + + + + + + +
+ (0012466) +
+ Gyorgy Rethy    +
+ 06-11-2014 13:35    +
+ 		+ + + + +
+ CR6785_v3.docx: no technical change, but a small explanatory addition (in brackets) to CR6785_v2.docx.
+
+Please check.
+
+
+
+ + + + + + + + + + +
+ (0012469) +
+ Tomas Urban    +
+ 06-11-2014 14:06    +
+ 		+ + + + +
+ I have no objections. I think the CR can be marked as resolved and it is ready to be added to the next version of the TTCN-3 core language standard.
+
+
+
+ + + + + + + + + + +
+ (0012652) +
+ Gyorgy Rethy    +
+ 06-01-2015 18:41    +
+ 		+ + + + +
+ Added to draft V4.6.3
+
+ + diff --git a/docs/mantis/CR6786.md b/docs/mantis/CR6786.md new file mode 100644 index 0000000000000000000000000000000000000000..3c482ae86a0de7e47a5fbd15d5456dea2910147d --- /dev/null +++ b/docs/mantis/CR6786.md @@ -0,0 +1,70 @@ + + + + + + + + + + + + + 0006786: Add the hostid predefined function to clause 16.1.2 - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006786Part 01: TTCN-3 Core LanguageEditorialpublic30-06-2014 13:3330-06-2014 14:39
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.6.1 (published 2014-06) 
Target Versionv4.7.1 (published 2015-06)Fixed in Versionv4.6.2 (interim 2014) 
Clause Reference(s)16.1.2
Source (company - Author)L.M.Ericsson
Summary0006786: Add the hostid predefined function to clause 16.1.2
DescriptionThe hostid predefined function is defined in clause C.6.3 but is missing in clause 16.1.2.
+
+Solution: add hosted to $16.1.2:
+Table 14/other functions>
+           Returns the host id of the test component or module hosted
+
+Syntactical Structure:
+hostid "(" [ SingleExpression ] ")"
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
30-06-2014 13:33Gyorgy RethyNew Issue
30-06-2014 14:37Gyorgy RethyProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
30-06-2014 14:38Gyorgy RethyAssigned To => Gyorgy Rethy
30-06-2014 14:38Gyorgy RethyStatusnew => assigned
30-06-2014 14:38Gyorgy RethyResolutionopen => fixed
30-06-2014 14:38Gyorgy RethyProduct Version => v4.6.1 (published 2014-06)
30-06-2014 14:38Gyorgy RethyFixed in Version => v4.6.2 (interim 2014)
30-06-2014 14:38Gyorgy RethyTarget Version => v4.7.1 (published 2015-06)
30-06-2014 14:39Gyorgy RethyNote Added: 0012198
30-06-2014 14:39Gyorgy RethyStatusassigned => closed
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0012198) +
+ Gyorgy Rethy    +
+ 30-06-2014 14:39    +
+ 		+ + + + +
+ Added to master copy of V4.6.2
+
+ + diff --git a/docs/mantis/CR6787.md b/docs/mantis/CR6787.md new file mode 100644 index 0000000000000000000000000000000000000000..0d23335a70da765dbad186aac3d9608f789685a0 --- /dev/null +++ b/docs/mantis/CR6787.md @@ -0,0 +1,137 @@ + + + + + + + + + + + + + 0006787: Control of fraction digits - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006787Part 09: Using XML with TTCN-3Technicalpublic01-07-2014 20:2731-12-2014 14:03
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PriorityhighSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.5.1 (published 2013-04) 
Target Versionv4.6.1 (published 2015-06)Fixed in Versionv4.6.1 (published 2015-06) 
Clause Reference(s)5.4
For STF discussion
Source (company - Author)STF 475
Summary0006787: Control of fraction digits
DescriptionAccording to 5.4.c it is not possible to specify the number of fraction digits for a float field. It means that value encoding and decoding are fully dependent on proprietary codec settings. This situation is unacceptable for strict conformance testing. According to the information from STF160, control over fraction digits should be possible directly in the TTCN-3 test suite, including the option of generating codec failure when a decoded field contains a different number of fraction digits than required.
+
+There's currently indeed a mechanism that leads to similar results: specifying a variant attribute e.g. transparent fractionDigits value='1'. However, this attribute is related to existing facets in XML schemas and therefore it is not possible to say what should be codec behaviour when it is applied to a template field that is associated with an XSD element that doesn't contain the fractionDigits facet.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
parent of 0006797closed Gyorgy Rethy Meaning of totalDigits facet has been changed in XSD 
Attached Filesdoc CR6787_resolution_v1.doc (99,328) 07-10-2014 15:00
http://oldforge.etsi.org/mantis/file_download.php?file_id=3098&type=bug
doc CR6787_resolution_v2.doc (99,840) 08-10-2014 08:08
http://oldforge.etsi.org/mantis/file_download.php?file_id=3104&type=bug
Issue History
Date ModifiedUsernameFieldChange
01-07-2014 20:27Tomas UrbanNew Issue
06-10-2014 10:57Gyorgy RethyAssigned To => Gyorgy Rethy
06-10-2014 10:57Gyorgy RethyStatusnew => assigned
06-10-2014 10:57Gyorgy RethyProduct Version => v4.5.1 (published 2013-04)
06-10-2014 10:57Gyorgy RethyTarget Version => v4.6.1 (published 2015-06)
07-10-2014 09:10Gyorgy RethyPrioritynormal => high
07-10-2014 15:00Gyorgy RethyFile Added: CR6787_resolution_v1.doc
07-10-2014 15:20Gyorgy RethyRelationship addedparent of 0006797
07-10-2014 15:23Gyorgy RethyNote Added: 0012258
07-10-2014 15:23Gyorgy RethyAssigned ToGyorgy Rethy => Tomas Urban
07-10-2014 15:23Gyorgy RethyStatusassigned => confirmed
07-10-2014 15:24Gyorgy RethyNote Edited: 0012258bug_revision_view_page.php?bugnote_id=12258#r73
08-10-2014 08:08Tomas UrbanFile Added: CR6787_resolution_v2.doc
08-10-2014 08:14Tomas UrbanNote Added: 0012265
08-10-2014 08:14Tomas UrbanStatusconfirmed => resolved
08-10-2014 08:14Tomas UrbanResolutionopen => fixed
08-10-2014 08:14Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
31-12-2014 14:03Gyorgy RethyNote Added: 0012598
31-12-2014 14:03Gyorgy RethyStatusresolved => closed
31-12-2014 14:03Gyorgy RethyFixed in Version => v4.6.1 (published 2015-06)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0012258) +
+ Gyorgy Rethy    +
+ 07-10-2014 15:23    +
(edited on: 07-10-2014 15:24)
+ 		+ + + + +
+ Please check proposed resolution in CR6787_resolution_v1.doc
+
+Note: it includes also corrections to the totalDigits facet, see CR6897.
+
+
+
+
+
+ + + + + + + + + + +
+ (0012265) +
+ Tomas Urban    +
+ 08-10-2014 08:14    +
+ 		+ + + + +
+ I removed fractionDigits from the examples on not mapped facets (as fractionDigits are mapped now). Otherwise the proposal is ready to be added to the next version of the standard.
+
+
+
+ + + + + + + + + + +
+ (0012598) +
+ Gyorgy Rethy    +
+ 31-12-2014 14:03    +
+ 		+ + + + +
+ Added to draft V4.5.3
+
+ + diff --git a/docs/mantis/CR6788.md b/docs/mantis/CR6788.md new file mode 100644 index 0000000000000000000000000000000000000000..3c0abfbec6321bd028ae862df979aa14cf3926ed --- /dev/null +++ b/docs/mantis/CR6788.md @@ -0,0 +1,34 @@ + + + + + + + + + + + + + 0006788: Error in example E46a - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006788Part 09: Using XML with TTCN-3Editorialpublic02-07-2014 13:1302-07-2014 13:16
ReporterGyorgy Rethy 
Assigned To 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.5.1 (published 2013-04) 
Target Versionv4.6.1 (published 2015-06)Fixed in Versionv4.5.2 (interim 2014) 
Clause Reference(s)7.7.1
For STF discussion
Source (company - Author)L.M.Ericsson
Summary0006788: Error in example E46a
DescriptionIn the examples, example generated TTCN-3 type E46a, the encoding instruction attached the field elem is:
+variant(elem) "anyElement except unqualified,'http://www.organization.org/wildcards'" [^]
+
+It shall correctly be:
+variant(elem) "anyElement except unqualified,'http://www.example.org/wildcards'" [^]
+(the target namespace of the XSD definition is ://www. example.org/wildcards)
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
02-07-2014 13:13Gyorgy RethyNew Issue
02-07-2014 13:15Gyorgy RethyProjectTTCN-3 Change Requests => Part 09: Using XML with TTCN-3
02-07-2014 13:16Gyorgy RethyStatusnew => closed
02-07-2014 13:16Gyorgy RethyResolutionopen => fixed
02-07-2014 13:16Gyorgy RethyProduct Version => v4.5.1 (published 2013-04)
02-07-2014 13:16Gyorgy RethyFixed in Version => v4.5.2 (interim 2014)
02-07-2014 13:16Gyorgy RethyTarget Version => v4.6.1 (published 2015-06)
+
+ + + + +
+ There are no notes attached to this issue.
+ + diff --git a/docs/mantis/CR6789.md b/docs/mantis/CR6789.md new file mode 100644 index 0000000000000000000000000000000000000000..dfc1b06e4f737b710f6da5db84530a219a58ecdf --- /dev/null +++ b/docs/mantis/CR6789.md @@ -0,0 +1,319 @@ + + + + + + + + + + + + + 0006789: Allow non-ISO646 (UTF-8 compatible) characters in universal charstrings - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006789Part 01: TTCN-3 Core LanguageNew Featurepublic23-07-2014 10:5106-01-2015 18:26
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.6.1 (published 2014-06) 
Target Versionv4.7.1 (published 2015-06)Fixed in Versionv4.7.1 (published 2015-06) 
Clause Reference(s)6.1.1 e)
Source (company - Author)L.M.Ericsson
Summary0006789: Allow non-ISO646 (UTF-8 compatible) characters in universal charstrings
DescriptionNowadays more and more protocols are textual or carrying textual content and do allow non-ASCII characters. For example both XML and JSON allow non-ISO646 characters.
+
+As users need to work more and more with unicode characters, it raises the requirement to be able to enter non-ASCII characters in unicode charstring values directly, instead of using the cumbersome quadruple notation. Using the new, U-coded unicode character reference (see CR6727), makes the syntax better, but doesn't solve the problem completely. The two syntaxes would complement each other: not all unicode characters are supported by UTF-8, not all text editors can represent all UTF-8 graphical characters and some users may want to stick to using ISO646 characters e.g. for backward compatibility reasons.
+
+As TTCN-3 modules shall be stored in UTF-8 (see clause 8), this would not allow misreading the values (to 2, 3 or 4 separate characters), when transferring the code between tools (though an elder tool may interpret the code as being erroneous, if version is not identified in the module header).
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx draft-res-6789-v1.docx (14,935) 04-11-2014 13:58
http://oldforge.etsi.org/mantis/file_download.php?file_id=3158&type=bug
docx draft-res-6789-v2.docx (25,191) 06-11-2014 15:09
http://oldforge.etsi.org/mantis/file_download.php?file_id=3178&type=bug
Issue History
Date ModifiedUsernameFieldChange
23-07-2014 10:51Gyorgy RethyNew Issue
06-10-2014 10:55Gyorgy RethyNote Added: 0012224
06-10-2014 10:55Gyorgy RethyTarget Version => v4.7.1 (published 2015-06)
09-10-2014 13:58Jacob Wieland - SpirentNote Added: 0012323
03-11-2014 16:33Gyorgy RethyAssigned To => Axel Rennoch
03-11-2014 16:33Gyorgy RethyStatusnew => assigned
04-11-2014 13:58Axel RennochFile Added: draft-res-6789-v1.docx
04-11-2014 14:00Axel RennochNote Added: 0012401
06-11-2014 08:58Gyorgy RethyNote Added: 0012446
06-11-2014 15:09Axel RennochFile Added: draft-res-6789-v2.docx
06-11-2014 15:11Axel RennochNote Added: 0012472
06-11-2014 15:12Axel RennochNote Added: 0012473
06-11-2014 15:12Axel RennochAssigned ToAxel Rennoch => Gyorgy Rethy
06-11-2014 15:12Axel RennochStatusassigned => acknowledged
07-11-2014 11:50Gyorgy RethyStatusacknowledged => confirmed
07-11-2014 13:37Jacob Wieland - SpirentNote Added: 0012498
06-01-2015 18:23Gyorgy RethyStatusconfirmed => resolved
06-01-2015 18:23Gyorgy RethyResolutionopen => fixed
06-01-2015 18:26Gyorgy RethyNote Added: 0012649
06-01-2015 18:26Gyorgy RethyStatusresolved => closed
06-01-2015 18:26Gyorgy RethyFixed in Version => v4.7.1 (published 2015-06)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0012224) +
+ Gyorgy Rethy    +
+ 06-10-2014 10:55    +
+ 		+ + + + +
+ *For STF discussion*
+
+
+
+ + + + + + + + + + +
+ (0012323) +
+ Jacob Wieland - Spirent    +
+ 09-10-2014 13:58    +
+ 		+ + + + +
+ As the only escape-character in TTCN-3 charstring literals is the quote-symbol, I guess this would have to be used.
+
+"aaa"0706"bbb", for instance, could then be the same as "aaa" & <unicode of 0706> & "bbb".
+
+As far as I can see, this does not introduce any backward incompatiblity as there is at the moment no grammar rule which allows a number directly behind a charstring literal.
+
+
+
+ + + + + + + + + + +
+ (0012401) +
+ Axel Rennoch    +
+ 04-11-2014 14:00    +
+ 		+ + + + +
+ Based on Jacob's idea we may allow different representations, please see examples in the attachment, since characters do not appear in this box. ;-)
+
+
+
+ + + + + + + + + + +
+ (0012446) +
+ Gyorgy Rethy    +
+ 06-11-2014 08:58    +
+ 		+ + + + +
+ We shall not extend the scope of the CR. If more/other feature is needed, another CR shall be submitted.
+
+The standard specifies the TTCN-3 modules to be saved in UTF-8, TTCN-3 editors should support UTF-8 characters (at least a reasoable subset), because they are allowed in comments. So, in principle no technical difficulties to allow their direct use in universal charstring values as well.
+
+The additional syntax brings in new problems:
+- in case of "aaa"0706"bbb", how to know what the user wanted to write? it may be a simple typing error and he/she meant "aaa""0706""bbb"! For this reason I strongly oppose this syntax, i.e. to extend the smantics associated with the "
+character.
+
+Anyway, UTF-8 today covers wast majority of really used characters, therefore the char(U4E2D, U56FD) syntax will become rarely used or used due to local style guides.
+
+
+
+ + + + + + + + + + +
+ (0012472) +
+ Axel Rennoch    +
+ 06-11-2014 15:11    +
+ 		+ + + + +
+ Following the discussion only a note has been added in the attached file to 6.1.1 e).
+
+
+
+ + + + + + + + + + +
+ (0012473) +
+ Axel Rennoch    +
+ 06-11-2014 15:12    +
+ 		+ + + + +
+ Please advice if the new note is sufficient.
+
+
+
+ + + + + + + + + + +
+ (0012498) +
+ Jacob Wieland - Spirent    +
+ 07-11-2014 13:37    +
+ 		+ + + + +
+ no problem with me. I just pointed out that a direct inclusion into the charstring literals needs to use the " character as that is the only escape character we have (unfortunately). In principle, I agree with Gyorgys reasoning that mostly, their will be no need for the char-syntax to be used.
+
+The only exception I see is standardization bodies which want to publish their testsuites in a non-UTF8 based format.
+
+
+
+ + + + + + + + + + +
+ (0012649) +
+ Gyorgy Rethy    +
+ 06-01-2015 18:26    +
+ 		+ + + + +
+ Added to draft V4.6.3
+
+ + diff --git a/docs/mantis/CR6790.md b/docs/mantis/CR6790.md new file mode 100644 index 0000000000000000000000000000000000000000..a3c71be112e0aee520a55f026d4f2017689028ac --- /dev/null +++ b/docs/mantis/CR6790.md @@ -0,0 +1,63 @@ + + + + + + + + + + + + + 0006790: Wrong predefined function references - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006790Part 01: TTCN-3 Core LanguageEditorialpublic06-08-2014 08:4506-08-2014 08:46
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.6.1 (published 2014-06) 
Target Versionv4.7.1 (published 2015-06)Fixed in Versionv4.6.2 (interim 2014) 
Clause Reference(s)6.2.4
Source (company - Author)L.M.Ericsson
Summary0006790: Wrong predefined function references
DescriptionAt the end of the 2nd paragraph clause reference is to C.1.29 instead of C.1.30.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
06-08-2014 08:45Gyorgy RethyNew Issue
06-08-2014 08:46Gyorgy RethyAssigned To => Gyorgy Rethy
06-08-2014 08:46Gyorgy RethyStatusnew => assigned
06-08-2014 08:46Gyorgy RethyProduct Version => v4.6.1 (published 2014-06)
06-08-2014 08:46Gyorgy RethyTarget Version => v4.7.1 (published 2015-06)
06-08-2014 08:46Gyorgy RethyNote Added: 0012212
06-08-2014 08:46Gyorgy RethyStatusassigned => closed
06-08-2014 08:46Gyorgy RethyResolutionopen => fixed
06-08-2014 08:46Gyorgy RethyFixed in Version => v4.6.2 (interim 2014)
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0012212) +
+ Gyorgy Rethy    +
+ 06-08-2014 08:46    +
+ 		+ + + + +
+ Fixed in V4.6.2 (interim 2014)
+
+ + diff --git a/docs/mantis/CR6791.md b/docs/mantis/CR6791.md new file mode 100644 index 0000000000000000000000000000000000000000..2e035d0270626d0395e2346e76b2fb0346a28af2 --- /dev/null +++ b/docs/mantis/CR6791.md @@ -0,0 +1,67 @@ + + + + + + + + + + + + + 0006791: Presence checking functions have in parameters only - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006791Part 01: TTCN-3 Core LanguageClarificationpublic06-08-2014 08:5106-08-2014 08:59
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeveritytrivialReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.6.1 (published 2014-06) 
Target Versionv4.7.1 (published 2015-06)Fixed in Versionv4.6.2 (interim 2014) 
Clause Reference(s)16.1.2
Source (company - Author)L.M.Ericsson
Summary0006791: Presence checking functions have in parameters only
Description$16.1.2, Restriction a), item 3) reads: "the actual in and inout parameter passed to the predefined functions isvalue, ischosen, ispresent and isbound may be uninitialized or even contain non-evaluable reference expressions".
+
+However, all these functions have a in parameter only.
+
+Proposed solution: delete "and inout".
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
06-08-2014 08:51Gyorgy RethyNew Issue
06-08-2014 08:52Gyorgy RethyAssigned To => Gyorgy Rethy
06-08-2014 08:52Gyorgy RethyStatusnew => assigned
06-08-2014 08:52Gyorgy RethyProduct Version => v4.6.1 (published 2014-06)
06-08-2014 08:52Gyorgy RethyTarget Version => v4.7.1 (published 2015-06)
06-08-2014 08:59Gyorgy RethyNote Added: 0012213
06-08-2014 08:59Gyorgy RethyStatusassigned => closed
06-08-2014 08:59Gyorgy RethyResolutionopen => fixed
06-08-2014 08:59Gyorgy RethyFixed in Version => v4.6.2 (interim 2014)
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0012213) +
+ Gyorgy Rethy    +
+ 06-08-2014 08:59    +
+ 		+ + + + +
+ Corrected in V4.6.2 (interim 2014)
+
+ + diff --git a/docs/mantis/CR6792.md b/docs/mantis/CR6792.md new file mode 100644 index 0000000000000000000000000000000000000000..4a898bcc1228ced33dc58186095819f72ebdfc72 --- /dev/null +++ b/docs/mantis/CR6792.md @@ -0,0 +1,97 @@ + + + + + + + + + + + + + 0006792: Add hyperlinks to predefined function clauses - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006792Part 01: TTCN-3 Core LanguageEditorialpublic06-08-2014 09:0207-01-2015 18:42
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.6.1 (published 2014-06) 
Target Versionv4.7.1 (published 2015-06)Fixed in Versionv4.7.1 (published 2015-06) 
Clause Reference(s)16.1.2
Source (company - Author)L.M.Ericsson
Summary0006792: Add hyperlinks to predefined function clauses
DescriptionTo make reading the standard more convenient for the user, add hyperlinks to the relevant clauses in annex C to the predefined function names in table 14.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
06-08-2014 09:02Gyorgy RethyNew Issue
06-08-2014 09:03Gyorgy RethyAssigned To => Gyorgy Rethy
06-08-2014 09:03Gyorgy RethyStatusnew => assigned
06-08-2014 09:03Gyorgy RethyProduct Version => v4.6.1 (published 2014-06)
06-08-2014 09:03Gyorgy RethyTarget Version => v4.7.1 (published 2015-06)
08-10-2014 09:24Gyorgy RethyNote Added: 0012268
08-10-2014 09:24Gyorgy RethyStatusassigned => resolved
08-10-2014 09:24Gyorgy RethyResolutionopen => fixed
08-10-2014 09:24Gyorgy RethyFixed in Version => v4.7.1 (published 2015-06)
07-01-2015 18:42Gyorgy RethyNote Added: 0012666
07-01-2015 18:42Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0012268) +
+ Gyorgy Rethy    +
+ 08-10-2014 09:24    +
+ 		+ + + + +
+ To be added during the final editing process
+
+
+
+ + + + + + + + + + +
+ (0012666) +
+ Gyorgy Rethy    +
+ 07-01-2015 18:42    +
+ 		+ + + + +
+ Added to draft V4.6.4
+
+ + diff --git a/docs/mantis/CR6793.md b/docs/mantis/CR6793.md new file mode 100644 index 0000000000000000000000000000000000000000..8362c1318ef39ce56244820495f91de16b83e77c --- /dev/null +++ b/docs/mantis/CR6793.md @@ -0,0 +1,417 @@ + + + + + + + + + + + + + 0006793: Value Interface is underspecified/inconsistent for Templates - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006793Part 06: TTCN-3 Control InterfaceClarificationpublic27-08-2014 13:1517-12-2014 11:43
ReporterJacob Wieland - Spirent 
Assigned ToTomas Urban 
PriorityhighSeveritymajorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.6.1 (published 2014-06) 
Target Versionv4.7.1 (published 2015-06)Fixed in Versionv4.7.1 (published 2015-06) 
Clause Reference(s)7.2.
Source (company - Author)Testing Technologies - Jacob Wieland
Summary0006793: Value Interface is underspecified/inconsistent for Templates
DescriptionIn section 7.2 of the TCI standard, the value interface is introduced for the purpose of encoding and decoding:
+
+"The TCI specification defines a set of abstract data types. These describe, at a very high level, which kind of data shall be passed from a calling to a called entity. The abstract data types are used to determine:
+•
+how TTCN-3 data is passed from a TE to an encoder, to encode TTCN-3 value representations into a bitstring;
+and in the reverse case;
+•
+how data passed from a decoder to the TE shall be decoded from a bitstring into its TTCN-3 value
+representation"
+
+In section 7.2.2 it is stated:
+
+"The abstract TTCN-3 type and value representation consists of two parts:
+•
+an abstract data type
+Type
+that represents all TTCN-3 types in a TTCN-3 module;
+•
+different abstract data types that represent TTCN-3 values, i.e. TTCN-3 values of a given TTCN-3 type. This
+can be either values of TTCN-3 predefined types or of TTCN-3 user-defined types."
+
+This suggests that only value instances (not templates) are to be handled via these interfaces (and neglects the fact that templates can also be passed to external functions as parameters).
+
+In section 7.2.2.2. however, two additional non-mandatory functions are introduced (I guess this was added later) that contradict the above statement:
+
+"In addition,
+Value
+can be used to represent matching mechanisms, which are used instead or inside values e.g. in
+template parameters or for template variables. Two additional operations:
+isMatchingSymbol
+(returns true for
+matching symbols) and
+valueToString (
+for printing value content in the same way as the log operation; can be
+used for displaying value content) are defined. These operations are not mandatory - it is up to a tool vendor to support
+them or not"
+
+The following definitions in section 7.2.2.2 of methods on Values (except the two just mentioned) all seem to take the first statement for granted, i.e. that they are invoked on TTCN-3 values only.
+
+For instance, the semantics of the function getField() in section 7.2.2.2.11 is defined using the term length which is only defined for values and for omit (if taken from the function getLength()). Therefore, in our opinion, the term length for templates is unspecified. Several interpretations are possible, but are not specifically stated by the standard.
+
+Other functions for accessing parts of values (i.e. in string-values and especially in numeric-types) are also unspecified for Templates.
+
+A clarification of these inconsistencies/underspecifications would be helpful.
+
+For backward compatibility for our customers, we would favor the interpretation that getLength() for a list-value-notation template should give the number of items in the notation and getField(i) should give back the item at the given position i, even if items up to i are AnyElementsOrNone or Permutation which would count as a single item in regard to position. Though this would not be consistent with the lengthof() function and the index-notation in the TTCN-3 core language, it would be helpful for exploring such templates. (Otherwise, another way of exploration should be added to the standard).
+
+As already stated in CR 6448, a better template interface for exploring (or even building) templates (other than isMatchingSymbol and valueToString) is still needed.
+
+If the above interpretation for getLength() and getField() of RecordOfValue is not possible and the Value interface (except isMatchingSymbol and valueToString) shall only be applicable for actual TTCN-3 values and not templates, then it should at least be stated so specifically to avoid future misinterpretations.
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0006448closed Ina Schieferdecker Part 01: TTCN-3 Core Language Rules for external function parameters 
related to 0006812closed Tomas Urban Part 06: TTCN-3 Control Interface Abstract data classes for matching mechanisms 
Attached Filesdocx CR6793_v1.docx (49,652) 07-10-2014 14:41
http://oldforge.etsi.org/mantis/file_download.php?file_id=3097&type=bug
docx CR6793_v2.docx (50,105) 08-10-2014 16:05
http://oldforge.etsi.org/mantis/file_download.php?file_id=3118&type=bug
Issue History
Date ModifiedUsernameFieldChange
27-08-2014 13:15Jacob Wieland - SpirentNew Issue
27-08-2014 13:17Jacob Wieland - SpirentRelationship addedrelated to 0006448
06-10-2014 10:53Gyorgy RethyNote Added: 0012223
06-10-2014 10:53Gyorgy RethyAssigned To => Tomas Urban
06-10-2014 10:53Gyorgy RethyStatusnew => assigned
07-10-2014 14:41Tomas UrbanFile Added: CR6793_v1.docx
07-10-2014 14:44Tomas UrbanNote Added: 0012254
07-10-2014 14:44Tomas UrbanStatusassigned => confirmed
07-10-2014 14:44Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
07-10-2014 16:10Jacob Wieland - SpirentNote Added: 0012261
08-10-2014 08:13Gyorgy RethyNote Added: 0012264
08-10-2014 08:13Gyorgy RethyAssigned ToGyorgy Rethy => Tomas Urban
08-10-2014 08:59Tomas UrbanNote Added: 0012266
08-10-2014 15:46Jacob Wieland - SpirentNote Added: 0012288
08-10-2014 16:05Tomas UrbanFile Added: CR6793_v2.docx
08-10-2014 16:07Tomas UrbanNote Added: 0012293
08-10-2014 16:07Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
08-10-2014 16:45Jacob Wieland - SpirentNote Added: 0012305
09-10-2014 09:00Gyorgy RethyAssigned ToGyorgy Rethy => Tomas Urban
09-10-2014 09:00Gyorgy RethyStatusconfirmed => resolved
09-10-2014 09:00Gyorgy RethyResolutionopen => fixed
09-10-2014 09:00Gyorgy RethyFixed in Version => v4.7.1 (published 2015-06)
05-11-2014 15:58Tomas UrbanRelationship addedrelated to 0006812
17-12-2014 11:43Tomas UrbanNote Added: 0012561
17-12-2014 11:43Tomas UrbanStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0012223) +
+ Gyorgy Rethy    +
+ 06-10-2014 10:53    +
+ 		+ + + + +
+ For checking the problem.
+
+
+
+ + + + + + + + + + +
+ (0012254) +
+ Tomas Urban    +
+ 07-10-2014 14:44    +
+ 		+ + + + +
+ I think there's a misunderstanding in the interpretation of the rules added to TCI specification ver. 4.5.1. The dedicated abstract data types (such as RecordOfValue) were never intended to manipulate with matching mechanisms. So your assumption that "the definitions in section 7.2.2.2 of methods on Values (except the two just mentioned) all seem to take the first statement for granted, i.e. that they are invoked on TTCN-3 values only" is absolutely correct.
+
+The whole idea was that the data objects representing matching mechanisms are instances of the base Value abstract data type and never instances of the dedicated abstract data types, i.e. whenever the isMatchingSymbol operation returns true, the object cannot be cast to the dedicated abstract data type.
+
+This is a lightweight solution addressing the issue that there was absolutely no mechanism for representing templates occurring in parameters etc. I agree with you that a fully fledged framework for getting and modifying all possible properties of matching mechanisms would be needed, however it hasn't been so far implemented because of time constraints.
+
+In the attached proposal, I only addressed the issue raised in the CR and added some rules that leave less space for distinct interpretations. I assign the problem to György for cross-checking and I would like to hear your comments Jacob as well.
+
+
+
+ + + + + + + + + + +
+ (0012261) +
+ Jacob Wieland - Spirent    +
+ 07-10-2014 16:10    +
+ 		+ + + + +
+ I have a problem with this NOTE:
+
+"Constructive values such as records, sets, records of, sets of, arrays, unions and anytype values might contain a matching mechanism in one of their elements and still return false. In this case, it is always possible to use the dedicated abstract data type operations to access individual elements of the constructive value."
+
+It contradicts the preceding definition:
+
+"... returns true if ..."
+"It is a record of, set of or array value containing a matching mechanism specified in clauses B.1.3.2 or B.1.3.3 of ES 201 8731 [1] in one of its elements"
+
+Also, since the only specified way for accessing parts of RecordOfValue is the getField method which is dependent on the length, how is the semantics of length and getField for such a template-instance, e.g. if there is a AnyElementsOrNone in the list. It clearly must be different from the semantics of lengthof() and the index-notation (which are undefined in that case). This would have to be specified.
+
+Thus, I would either strike that NOTE or we need further specification.
+
+
+
+ + + + + + + + + + +
+ (0012264) +
+ Gyorgy Rethy    +
+ 08-10-2014 08:13    +
+ 		+ + + + +
+ Pls. check Jacob's comment.
+
+
+
+ + + + + + + + + + +
+ (0012266) +
+ Tomas Urban    +
+ 08-10-2014 08:59    +
+ 		+ + + + +
+ What contradiction do you see there? Could you please be more specific, because I couldn't find any.
+
+B.1.3.2 describes AnyElementsOrNone and B.1.3.3 describes permutation. As you know, a whole set of complicated rules is then used in the core language standard for length calculations and element access. The current TCI avoid these rules. According to the specification, the RecordOfValue and SetOfValue data types cannot be used for records of, sets of and arrays containing the mentioned matching mechanisms. Only the general Value data type is granted for these templates. This means that element access is not possible in these cases at all, because there's never an instance with a getField method.
+
+However, records of, sets of and arrays containing other matching mechanisms in their elements (e.g. AnyElement, range, pattern etc.) can be represented by a RecordOfValue and SetOfValue instance as there are no side effects on the length calculation and field access. And this is exactly the situation the note describes.
+
+Example:
+type record of integer RoI;
+template RoI m_t1 := { 1, * };
+// cannot be transformed to RecordOfValue, because it contains AnyElementsOrNone
+// transformed to Value, isMatchingSymbol returns true
+template RoI m_t2 := { 2, ?, 6}
+// can be transformed to RecordOfValue, isMatchingSymbol returns false
+// RecordOfValue.getField(0) returns an IntegerValue instance
+// RecordOfValue.getField(1) returns a Value instance with isMatchingSymbol
+// returning true
+
+
+
+ + + + + + + + + + +
+ (0012288) +
+ Jacob Wieland - Spirent    +
+ 08-10-2014 15:46    +
+ 		+ + + + +
+ Ah, I didn't catch the restriction to clauses B.1.3.2 and B.1.3.3 (maybe that should be spelled out to AnyElementsOrOne and Permutation)
+
+
+
+ + + + + + + + + + +
+ (0012293) +
+ Tomas Urban    +
+ 08-10-2014 16:07    +
+ 		+ + + + +
+ I added a new version of the proposal that contains names of the concerned matching mechanisms too. I hope it helps to increase readability of the rules.
+
+
+
+ + + + + + + + + + +
+ (0012305) +
+ Jacob Wieland - Spirent    +
+ 08-10-2014 16:45    +
+ 		+ + + + +
+ Thanks, much more readable.
+
+
+
+ + + + + + + + + + +
+ (0012561) +
+ Tomas Urban    +
+ 17-12-2014 11:43    +
+ 		+ + + + +
+ Added to the TCI specification draft 4.6.2.
+
+ + diff --git a/docs/mantis/CR6794.md b/docs/mantis/CR6794.md new file mode 100644 index 0000000000000000000000000000000000000000..cc1796db1aa8a4b547ba070070d8ce0bfb4bc92b --- /dev/null +++ b/docs/mantis/CR6794.md @@ -0,0 +1,65 @@ + + + + + + + + + + + + + 0006794: Typo error - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006794Part 09: Using XML with TTCN-3Editorialpublic16-09-2014 09:1406-10-2014 10:52
ReporterBostjan Pintar 
Assigned To 
PrioritylowSeveritytextReproducibilityN/A
StatusclosedResolutionopen 
PlatformOSOS Version
Product Versionv4.5.1 (published 2013-04) 
Target Versionv4.6.1 (published 2015-06)Fixed in Versionv4.6.1 (published 2015-06) 
Clause Reference(s)6.1.5
For STF discussion
Source (company - Author)STF475
Summary0006794: Typo error
DescriptionWithin clause 6.1.5 Example 2 on page 26 there is missing syntactical character >.
+
+Should be written </xsd:simpleType> instead </xsd:simpleType
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
16-09-2014 09:14Bostjan PintarNew Issue
06-10-2014 10:52Gyorgy RethyNote Added: 0012222
06-10-2014 10:52Gyorgy RethyStatusnew => closed
06-10-2014 10:52Gyorgy RethyFixed in Version => v4.6.1 (published 2015-06)
06-10-2014 10:52Gyorgy RethyTarget Version => v4.6.1 (published 2015-06)
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0012222) +
+ Gyorgy Rethy    +
+ 06-10-2014 10:52    +
+ 		+ + + + +
+ Corrected in master copy V4.5.3
+
+ + diff --git a/docs/mantis/CR6795.md b/docs/mantis/CR6795.md new file mode 100644 index 0000000000000000000000000000000000000000..7f8b4971239b07c1e5177de2be76d17b1580f42e --- /dev/null +++ b/docs/mantis/CR6795.md @@ -0,0 +1,65 @@ + + + + + + + + + + + + + 0006795: Identifier of nested sequence field inside choice - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006795Part 09: Using XML with TTCN-3Technicalpublic22-09-2014 12:1507-10-2014 17:15
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.5.1 (published 2013-04) 
Target Versionv4.6.1 (published 2015-06)Fixed in Versionv4.6.1 (published 2015-06) 
Clause Reference(s)7.6.5.4
For STF discussion
Source (company - Author)STF 475
Summary0006795: Identifier of nested sequence field inside choice
DescriptionThe chapter 7.6.5.4 doesn't formally specify the identifier that shall be used for transformed sequence field located inside a choice. The field name is obviously "sequence" as this name appears in the examples, but I couldn't find any rule mentioning this identifier in this context.
+
+Proposal: formal definition of the identifier shall be added.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
22-09-2014 12:15Tomas UrbanNew Issue
06-10-2014 10:47Gyorgy RethyAssigned To => Gyorgy Rethy
06-10-2014 10:47Gyorgy RethyStatusnew => assigned
07-10-2014 17:15Gyorgy RethyNote Added: 0012263
07-10-2014 17:15Gyorgy RethyStatusassigned => closed
07-10-2014 17:15Gyorgy RethyResolutionopen => fixed
07-10-2014 17:15Gyorgy RethyFixed in Version => v4.6.1 (published 2015-06)
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0012263) +
+ Gyorgy Rethy    +
+ 07-10-2014 17:15    +
+ 		+ + + + +
+ The sentence " The name of the record field shall be the result of applying clause 5.2.2 to “sequence”" has been added to clause 7.6.5.4.
+
+ + diff --git a/docs/mantis/CR6796.md b/docs/mantis/CR6796.md new file mode 100644 index 0000000000000000000000000000000000000000..29733d70d7e8b4e4227e405cc2060bf9370ee7ec --- /dev/null +++ b/docs/mantis/CR6796.md @@ -0,0 +1,82 @@ + + + + + + + + + + + + + 0006796: Invalid example on nested sequence inside choice - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006796Part 09: Using XML with TTCN-3Technicalpublic22-09-2014 12:3807-10-2014 15:56
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.5.1 (published 2013-04) 
Target Versionv4.6.1 (published 2015-06)Fixed in Versionv4.6.1 (published 2015-06) 
Clause Reference(s)7.6.5.4
For STF discussion
Source (company - Author)STF 475
Summary0006796: Invalid example on nested sequence inside choice
DescriptionThe example 2 in the chapter 7.6.5.4 is invalid. There's a nested sequence inside a nested sequence. This kind of nesting is described in the chapter 7.6.6.4 and according to the rules specified there, it shall not produce an additional record wrapper. Correct mapping would be:
+
+type record E34b {
+  union {
+    record {
+      XSD.String foo,
+      XSD.String bar
+      XSD.String ding,
+      XSD.String foo_1,
+      XSD.String bar_1
+    } sequence,
+    XSD.String ding
+  } choice
+}
+with {
+  variant "name as uncapitalized ";
+  variant(choice, choice.sequence) "untagged";
+  variant(choice.sequence.foo_1) "name as 'foo'"
+  variant(choice.sequence.bar_1) "name as 'bar'"
+}
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
22-09-2014 12:38Tomas UrbanNew Issue
06-10-2014 10:47Gyorgy RethyAssigned To => Gyorgy Rethy
06-10-2014 10:47Gyorgy RethyStatusnew => assigned
07-10-2014 15:56Gyorgy RethyNote Added: 0012260
07-10-2014 15:56Gyorgy RethyStatusassigned => closed
07-10-2014 15:56Gyorgy RethyResolutionopen => fixed
07-10-2014 15:56Gyorgy RethyFixed in Version => v4.6.1 (published 2015-06)
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0012260) +
+ Gyorgy Rethy    +
+ 07-10-2014 15:56    +
+ 		+ + + + +
+ Comment is valid, example has been corrected in the master copy V4.5.3 as proposed by the CR.
+
+ + diff --git a/docs/mantis/CR6797.md b/docs/mantis/CR6797.md new file mode 100644 index 0000000000000000000000000000000000000000..f12022b36bb524ee818bb4ba36db0614dff53051 --- /dev/null +++ b/docs/mantis/CR6797.md @@ -0,0 +1,65 @@ + + + + + + + + + + + + + 0006797: Meaning of totalDigits facet has been changed in XSD - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006797Part 09: Using XML with TTCN-3Technicalpublic07-10-2014 15:0607-10-2014 15:22
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.5.1 (published 2013-04) 
Target Versionv4.6.1 (published 2015-06)Fixed in Versionv4.6.1 (published 2015-06) 
Clause Reference(s)6.1.11
For STF discussion
Source (company - Author)L.M.Ericsson
Summary0006797: Meaning of totalDigits facet has been changed in XSD
DescriptionIn XSD Part2:2004 the totalDigits facet, for decimal values, is not limiting the literal number of digits any more, but the value space of the given element (i.e. leading and trailing zeros, excessing the number defined by totalDigits, are allowed.
+
+Clause 6.1.11 shall be reworded accordingly.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
child of 0006787closed Gyorgy Rethy Control of fraction digits 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
07-10-2014 15:06Gyorgy RethyNew Issue
07-10-2014 15:07Gyorgy RethyProjectPart 01: TTCN-3 Core Language => Part 09: Using XML with TTCN-3
07-10-2014 15:08Gyorgy RethyAssigned To => Gyorgy Rethy
07-10-2014 15:08Gyorgy RethyStatusnew => assigned
07-10-2014 15:08Gyorgy RethyProduct Versionv4.6.1 (published 2014-06) => v4.5.1 (published 2013-04)
07-10-2014 15:08Gyorgy RethyTarget Version => v4.6.1 (published 2015-06)
07-10-2014 15:19Gyorgy RethySummaryMeaning of totalDigits facet has changed in XSD => Meaning of totalDigits facet has been changed in XSD
07-10-2014 15:20Gyorgy RethyRelationship addedchild of 0006787
07-10-2014 15:22Gyorgy RethyNote Added: 0012257
07-10-2014 15:22Gyorgy RethyStatusassigned => closed
07-10-2014 15:22Gyorgy RethyResolutionopen => fixed
07-10-2014 15:22Gyorgy RethyFixed in Version => v4.6.1 (published 2015-06)
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0012257) +
+ Gyorgy Rethy    +
+ 07-10-2014 15:22    +
+ 		+ + + + +
+ This CR is closed, because its resolution is included into the resolution text of CR 6787
+
+ + diff --git a/docs/mantis/CR6798.md b/docs/mantis/CR6798.md new file mode 100644 index 0000000000000000000000000000000000000000..51db8af446dedaa7909a182bb38f61c0845f00db --- /dev/null +++ b/docs/mantis/CR6798.md @@ -0,0 +1,368 @@ + + + + + + + + + + + + + 0006798: TTCN-3 Alias_or_Synonym Type Def. of an XSD Type - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006798Part 09: Using XML with TTCN-3New Featurepublic08-10-2014 13:0602-07-2017 09:51
ReporterThilo Lauer 
Assigned ToKristóf Szabados 
PriorityhighSeveritymajorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.5.1 (published 2013-04) 
Target Versionv4.9.1 (published 2018-05)Fixed in Versionv4.8.1 (published 2017-05) 
Clause Reference(s)TTCN-3, Part 9
For STF discussion
Source (company - Author) Devoteam - Thilo Lauer
Summary0006798: TTCN-3 Alias_or_Synonym Type Def. of an XSD Type
DescriptionXSD types/elements contain at source level as well as at byte/character stream level a number of additional informations compared to TTCN-3 types,
+e.g. (target) namespace, attribute (yes,no), type/element name (seen at XML character stream level!). (See also Part 9, B.3 Encoding instructions).
+
+As soon as you define an alias type definition in a TTCN-3 module, normally all this additional information from the original XSD type/element will get lost. As far as I know, Part 9 of the standard does not cover how to handle this this case.
+
+At the last Telco, we got the issue, that RAN5 requires alias definitions,
+but without the necessity to add all the XML encoding instructions.
+
+Therefore for alias types we would like to suggest an implicit copy mechanism by the compiler at compile time:
+
+If an TTCN-3 alias type is defined for an XSD type/element, the compiler
+implicitly copies all relevant XML encoding instructions to the TTCN-3 alias type as well.
+
+Additionally the "namespace as ... " XML encoding instruction is implicitly added to the TTCN-3 alias type. This allows to combine TTCN-3 alias types of XSD types/elements from different targetNamespaces in one (!) TTCN-3 module.
+
+Note:
+This works only for pure alias definitions.
+As soon as you do more in TTCN-3, e.g. if you define a TTCN-3 record containing a field of an XSD_elementType, and some more fields with pure TTCN-3 types ...
+and ...
+you want to encode this TTCN-3 record type with XML, you have to add all the additional XSD information required, using the "B.3 Encoding instructions" of Part 9.
+
+Please have a look in the uploaded PowerPoint file. It explains this issue a bit more in detail.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
child of 0006389closed Gyorgy Rethy Variant overwriting rules are not correct 
Attached Filespptx CR_TTCN-3 Alias_or_Synonym Type Def. of an XSD Type.pptx (854,258) 08-10-2014 13:06
http://oldforge.etsi.org/mantis/file_download.php?file_id=3113&type=bug
Issue History
Date ModifiedUsernameFieldChange
08-10-2014 13:06Thilo LauerNew Issue
08-10-2014 13:06Thilo LauerFile Added: CR_TTCN-3 Alias_or_Synonym Type Def. of an XSD Type.pptx
08-10-2014 16:06Jacob Wieland - SpirentNote Added: 0012292
08-10-2014 16:40Thilo LauerNote Added: 0012302
08-10-2014 16:56Jacob Wieland - SpirentNote Added: 0012306
08-10-2014 17:01Thilo LauerNote Added: 0012307
09-10-2014 09:13Thilo LauerNote Deleted: 0012307
03-11-2014 14:17Gyorgy RethyTarget Version => v4.6.1 (published 2015-06)
03-11-2014 16:30Gyorgy RethyNote Added: 0012385
03-11-2014 16:30Gyorgy RethyAssigned To => Gyorgy Rethy
03-11-2014 16:30Gyorgy RethyStatusnew => assigned
04-11-2014 15:25Gyorgy RethyRelationship addedchild of 0006389
04-11-2014 15:34Gyorgy RethyNote Edited: 0012385bug_revision_view_page.php?bugnote_id=12385#r91
04-11-2014 15:41Gyorgy RethyNote Added: 0012404
04-11-2014 15:44Gyorgy RethyNote Edited: 0012404bug_revision_view_page.php?bugnote_id=12404#r93
06-11-2014 10:12Gyorgy RethyNote Added: 0012450
06-11-2014 10:13Gyorgy RethyAssigned ToGyorgy Rethy => Tomas Urban
06-11-2014 15:19Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
06-11-2014 15:20Tomas UrbanNote Added: 0012475
26-01-2015 10:11Gyorgy RethyTarget Versionv4.6.1 (published 2015-06) => v4.7.1 (published 2016-07)
18-07-2016 14:52Jens GrabowskiAssigned ToGyorgy Rethy => Kristóf Szabados
17-08-2016 12:05Jacob Wieland - SpirentTarget Versionv4.7.1 (published 2016-07) => v4.8.1 (published 2017-05)
17-11-2016 13:46Jens GrabowskiNote Added: 0014304
17-11-2016 13:47Jens GrabowskiTarget Versionv4.8.1 (published 2017-05) => v4.9.1 (published 2018-05)
02-07-2017 09:51Kristóf SzabadosNote Added: 0014727
02-07-2017 09:51Kristóf SzabadosStatusassigned => closed
02-07-2017 09:51Kristóf SzabadosResolutionopen => fixed
02-07-2017 09:51Kristóf SzabadosFixed in Version => v4.8.1 (published 2017-05)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0012292) +
+ Jacob Wieland - Spirent    +
+ 08-10-2014 16:06    +
+ 		+ + + + +
+ I still think the aliasing should only work for XSD-element-TTCN-3 types and not for XSD-type-TTCN-3 types (as those do not carry the relevant information and could be referenced from serveral element-types, so it is not clear where to copy the element-information from).
+
+
+
+ + + + + + + + + + +
+ (0012302) +
+ Thilo Lauer    +
+ 08-10-2014 16:40    +
+ 		+ + + + +
+ You are right! I have raised CR_6800 for clarification of this issue (mostly for TTCN-3 users!)
+
+By the way: is there any meaningful use of "XSD-type-TTCN-3 types" ?
+
+
+
+ + + + + + + + + + +
+ (0012306) +
+ Jacob Wieland - Spirent    +
+ 08-10-2014 16:56    +
+ 		+ + + + +
+ the use of any non-PDU-types, I guess. Storing it in variables for more simple access for manipulation, for instance. Also, if two elements share the same type, a variable of the type-type can be used for transfer. In principle, I agree, it would have been more prudent to hide the type-types from the user somehow, but since they can be used from different other definitions, this would have been hard to achieve.
+
+
+
+ + + + + + + + + + +
+ (0012385) +
+ Gyorgy Rethy    +
+ 03-11-2014 16:30    +
(edited on: 04-11-2014 15:34)
+ 		+ + + + +
+ STF discussion: investigate the proposal, according to the proposed solution of the reporter.
+
+
+
+
+
+ + + + + + + + + + +
+ (0012404) +
+ Gyorgy Rethy    +
+ 04-11-2014 15:41    +
(edited on: 04-11-2014 15:44)
+ 		+ + + + +
+ Actually, this can/shall be handled as a subcase of the variant attribute overwriting rules within the context of the XML encode attribute, therefore to be handled within CR6389.
+
+in practical term, this would mean that the XML encode attribute shall also be attached to the module collecting the aliases (or to groups containing the aliases or to the aliases themselves).
+
+
+
+
+
+ + + + + + + + + + +
+ (0012450) +
+ Gyorgy Rethy    +
+ 06-11-2014 10:12    +
+ 		+ + + + +
+ STF discussion: to be able to resolve this request this year the rules relevant for the partial case to be defined; they shall be compatible with the general rules to be added later.
+
+name as instruction needs specific discussion.
+
+
+
+ + + + + + + + + + +
+ (0012475) +
+ Tomas Urban    +
+ 06-11-2014 15:20    +
+ 		+ + + + +
+ This issue can be fully resolve only after the rules on attributes defined in the part 9 are fully compatible with the attribute mechanism defined in the part 1 (see 0006389 for more details). Without achieving full compatibility, we would have to solve many issues similar to this one. For that reason, I propose to postpone the resolution of this CR to the next year.
+
+
+
+ + + + + + + + + + +
+ (0014304) +
+ Jens Grabowski    +
+ 17-11-2016 13:46    +
+ 		+ + + + +
+ STF is working on the overwriting rules of attributes in part 1. With a planned extension, the CR will be resolved with fewer changes than are necessary now. Complete resolution shifted to 2017 version.
+
+
+
+ + + + + + + + + + +
+ (0014727) +
+ Kristóf Szabados    +
+ 02-07-2017 09:51    +
+ 		+ + + + +
+ Contacting the reporter of the CR he agreed that last year's changes can solve this CR.
+
+The CR can be closed now.
+
+ + diff --git a/docs/mantis/CR6799.md b/docs/mantis/CR6799.md new file mode 100644 index 0000000000000000000000000000000000000000..b79c5d78782360e2125e7b3ee6c2923e29137a92 --- /dev/null +++ b/docs/mantis/CR6799.md @@ -0,0 +1,762 @@ + + + + + + + + + + + + + 0006799: Using the encvalue() function to build parts of a XML message or a XML matching template - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006799Part 09: Using XML with TTCN-3New Featurepublic08-10-2014 14:4907-08-2015 13:41
ReporterThilo Lauer 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.5.1 (published 2013-04) 
Target Versionv4.6.1 (published 2015-06)Fixed in Versionv4.6.1 (published 2015-06) 
Clause Reference(s)TTCN-3, Part 9
For STF discussion
Source (company - Author) Devoteam - Thilo Lauer
Summary0006799: Using the encvalue() function to build parts of a XML message or a XML matching template
DescriptionIf the encvalue() function is used to generate parts of an XML message it can generally not be decided by the compiler/XML codec when to generate the XML header and when not.
+There are situations when it is obvious but there are also situations when it is tricky or impossible to guess what the intention of the test suite developer was - in terms of adding the XML-header or not.
+
+Therefore we suggest to add an optional parameter to encvalue() function in order to let the generation of XML header be controlled by TTCN-3 test suite developers:
+
+encvalue(in template (value) any_type inpar,
+         in boolean xmlHeader:=true) return bitstring
+
+Please have a look in the uploaded PowerPoint file, which contains an example from the LTE test suite.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0006815closed Tomas Urban Part 06: TTCN-3 Control Interface TCI support for dynamic encoding parameter 
Attached Filespptx CR_Using the encvalue() function to build parts of a XML message or a XML matching template.pptx (852,218) 08-10-2014 14:49
http://oldforge.etsi.org/mantis/file_download.php?file_id=3115&type=bug
docx CR6799_v1.docx (54,028) 05-11-2014 08:14
http://oldforge.etsi.org/mantis/file_download.php?file_id=3164&type=bug
doc CR6799_resolution_P9_v1.doc (87,552) 06-11-2014 15:18
http://oldforge.etsi.org/mantis/file_download.php?file_id=3180&type=bug
doc CR6799_resolution_P9_v2.doc (89,088) 06-11-2014 16:00
http://oldforge.etsi.org/mantis/file_download.php?file_id=3181&type=bug
docx CR6799_v2.docx (54,316) 07-11-2014 08:46
http://oldforge.etsi.org/mantis/file_download.php?file_id=3182&type=bug
doc CR6799_resolution_P9_v3.doc (90,112) 21-11-2014 10:23
http://oldforge.etsi.org/mantis/file_download.php?file_id=3186&type=bug
Issue History
Date ModifiedUsernameFieldChange
08-10-2014 14:49Thilo LauerNew Issue
08-10-2014 14:49Thilo LauerFile Added: CR_Using the encvalue() function to build parts of a XML message or a XML matching template.pptx
08-10-2014 16:42Jacob Wieland - SpirentNote Added: 0012304
09-10-2014 16:14Tomas UrbanNote Added: 0012333
09-10-2014 16:15Tomas UrbanNote Edited: 0012333bug_revision_view_page.php?bugnote_id=12333#r81
10-10-2014 09:42Jacob Wieland - SpirentNote Added: 0012341
10-10-2014 10:17Tomas UrbanNote Added: 0012345
10-10-2014 10:32Thilo LauerNote Added: 0012348
10-10-2014 11:09Jacob Wieland - SpirentNote Added: 0012357
10-10-2014 11:37Tomas UrbanNote Added: 0012358
10-10-2014 11:56Jacob Wieland - SpirentNote Added: 0012361
03-11-2014 10:04Gyorgy RethyTarget Version => v4.6.1 (published 2015-06)
03-11-2014 15:43Gyorgy RethyNote Added: 0012381
03-11-2014 15:44Gyorgy RethyAssigned To => Tomas Urban
03-11-2014 15:44Gyorgy RethyStatusnew => assigned
03-11-2014 15:58Jacob Wieland - SpirentNote Added: 0012382
04-11-2014 16:45Tomas UrbanNote Added: 0012408
05-11-2014 08:14Tomas UrbanFile Added: CR6799_v1.docx
05-11-2014 08:16Tomas UrbanNote Added: 0012412
05-11-2014 08:16Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
05-11-2014 08:16Tomas UrbanStatusassigned => confirmed
06-11-2014 13:39Gyorgy RethyNote Added: 0012467
06-11-2014 15:17Gyorgy RethyFile Added: CR6799_resolution_v1.doc
06-11-2014 15:18Gyorgy RethyFile Deleted: CR6799_resolution_v1.doc
06-11-2014 15:18Gyorgy RethyFile Added: CR6799_resolution_P9_v1.doc
06-11-2014 15:19Gyorgy RethyNote Added: 0012474
06-11-2014 15:19Gyorgy RethyAssigned ToGyorgy Rethy => Tomas Urban
06-11-2014 16:00Tomas UrbanFile Added: CR6799_resolution_P9_v2.doc
06-11-2014 16:02Tomas UrbanNote Added: 0012477
06-11-2014 16:02Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
07-11-2014 08:46Tomas UrbanFile Added: CR6799_v2.docx
07-11-2014 08:47Tomas UrbanNote Added: 0012478
07-11-2014 08:58Tomas UrbanRelationship addedrelated to 0006815
21-11-2014 10:23Gyorgy RethyFile Added: CR6799_resolution_P9_v3.doc
21-11-2014 10:25Gyorgy RethyNote Added: 0012512
21-11-2014 10:25Gyorgy RethyAssigned ToGyorgy Rethy => Tomas Urban
21-11-2014 15:19Tomas UrbanNote Added: 0012514
21-11-2014 15:19Tomas UrbanStatusconfirmed => resolved
21-11-2014 15:19Tomas UrbanFixed in Version => v4.6.1 (published 2015-06)
21-11-2014 15:19Tomas UrbanResolutionopen => fixed
21-11-2014 15:19Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
31-12-2014 11:51Gyorgy RethyNote Added: 0012597
31-12-2014 11:51Gyorgy RethyStatusresolved => closed
07-08-2015 13:41Gyorgy RethyNote Added: 0013147
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0012304) +
+ Jacob Wieland - Spirent    +
+ 08-10-2014 16:42    +
+ 		+ + + + +
+ I am strongly opposed to this kind of specific-problem-resolution-approach. I would rather have a map-param-like solution or something else where you can pass additional parameters to the encoder. Similar problems can happen in any encoding (e.g. whether or not to include BOMs or whether or not to pretty-print the XML and so forth), so I would opt for a more general approach to this problem.
+
+
+
+ + + + + + + + + + +
+ (0012333) +
+ Tomas Urban    +
+ 09-10-2014 16:14    +
(edited on: 09-10-2014 16:15)
+ 		+ + + + +
+ Maybe we could overload the @encoded symbol proposed in 0006736 so that it can be used in templates for sending. TCI update would be required then too. Would it solve the problem?
+
+
+
+
+
+ + + + + + + + + + +
+ (0012341) +
+ Jacob Wieland - Spirent    +
+ 10-10-2014 09:42    +
+ 		+ + + + +
+ This is too vague a proposal. Please give an example.
+
+
+
+ + + + + + + + + + +
+ (0012345) +
+ Tomas Urban    +
+ 10-10-2014 10:17    +
+ 		+ + + + +
+ Assuming we have a complex type with anyElement and a real element we would like to put into in its encoded form mapped into the following TTCN-3 definitions:
+
+type record Envelope {
+    XSD.String elem
+}
+with {
+    variant "name as uncapitalized";
+    variant(elem) "anyElement"
+}
+type record Payload {
+    ...
+}
+with {
+    variant "name as uncapitalized"
+}
+
+the template for sending could be defined in the following way:
+
+template Payload m_payload := {...}
+template Envelope m_msg := {
+    elem := @encoded m_payload
+}
+
+Like in case of matching, the @encoding modifier would allow to insert a content of an arbitrary type into a template field of a string type. The modifier would be interpretted by the codec as an instruction to encode the value of the arbitrary type first, tranform it to the target string type and perform additional encoding task (if necessary) to insert the string to the encoded PDU.
+
+
+
+ + + + + + + + + + +
+ (0012348) +
+ Thilo Lauer    +
+ 10-10-2014 10:32    +
+ 		+ + + + +
+ Originally TTCN was designed to make it obvious from the TTCN source code what is really done with received/sent messages and that everyone can easily read that code. This was one of the reasons that TTCN-3 does not have automatic type conversion (e.g. between float and integer, between bitstring, hexstring and octetstring, etc.) For all this stuff you need an extra type conversion function! On the other side more and more complexity is passed to the compiler with all these "@modifiers". Does a normal TTCN-3 user still understand what is really going on????
+!!! We strongly oppose to such a solution !!!
+
+
+
+ + + + + + + + + + +
+ (0012357) +
+ Jacob Wieland - Spirent    +
+ 10-10-2014 11:09    +
+ 		+ + + + +
+ @Tomas: I think what you are describing is already allowed with the @encoded matching mechanism, but I don't see the connection to the issue at hand how the encoder should know whether or not to include the header.
+
+@Thilo: the modifiers are a result/solution of/to years of backward-compatibility problems caused by new features which need new keywords because new keywords always potentially break old stuff. The modifiers solve this as they cannot clash with existing keywords and identifiers and thus are a clean way of introducing new keywords.
+
+That said, I don't think that forcing the user to write longer and repetitive code for every little thing they do will raise the acceptance of TTCN-3. If the semantics of an explicitly-written-down feature is clearly explained in the standard, it should not be a problem. There is no 'implicit conversion' going on but an explicit one. Anyway, I still don't see a solution to the problem at hand.
+
+What about a variant attribute for the template to be sent controlling whether the codec should add a header or not? I think this would be much more in sync with existing TTCN-3 approaches.
+
+
+
+ + + + + + + + + + +
+ (0012358) +
+ Tomas Urban    +
+ 10-10-2014 11:37    +
+ 		+ + + + +
+ At the moment, @encoded is specified for matching only. My proposal is to use it for sending as well. In the given example, the codec would get RecordValue representing the Entity value as usually. When encoding the value content, the getField("elem") call would return EncodedValue (containing a reference to universal string as the target type and RecordValue representing the data source of the Payload type) instead of a UniversalCharstringValue.
+
+The difference comparing to the original proposal made by Thilo is that there's one encoding call instead of two. And since the codec is well aware that the @encoded content lies inside of an XML envelope, it can easily use appropriate encoding without the XML-header and even take advantage of other features already used within the produced XML document (such as namespace prefixes).
+
+
+
+ + + + + + + + + + +
+ (0012361) +
+ Jacob Wieland - Spirent    +
+ 10-10-2014 11:56    +
+ 		+ + + + +
+ For this specific problem, this would indeed be an elegant solution, though I still think that making it more explicit, as Thilo wants to be enforced, is probably not such a bad idea (Otherwise, the decision is shifted to the implementer of the codec and that again can yield different results from implementation to implementation (one implementation might simply delegate to another codec and that codec always adds the header and one might do it differently).
+
+
+
+ + + + + + + + + + +
+ (0012381) +
+ Gyorgy Rethy    +
+ 03-11-2014 15:43    +
+ 		+ + + + +
+ STF discussion: preferred way is to add an optional string parameter to encvalue/decvalue for codec conrtol purposes in part-1. In part-9 a "noXmlHeader" and if later needed, more instructions will be defined.
+
+
+
+ + + + + + + + + + +
+ (0012382) +
+ Jacob Wieland - Spirent    +
+ 03-11-2014 15:58    +
+ 		+ + + + +
+ How is that additional parameter to be transported to tciEncode? Adding a new parameter there would break a lot of code?
+
+Also, can we at least make the part-1 solution less specific (i.e. allow any type to be passed so that for other codecs this can be reused?) Otherwise, all information will be encoded in a string and that string needs to be parsed by the codec which seems overly complicated.
+
+
+
+ + + + + + + + + + +
+ (0012408) +
+ Tomas Urban    +
+ 04-11-2014 16:45    +
+ 		+ + + + +
+ Just a couple of comments:
+1. There are two options for handling it on TCI level: either extending the tciEncode function (which has the drawback that old libraries have to be recompiled) or introducing a new function for handling the parameterized call (tciEncodeParam). In any case, a new CR has to be made for part 6.
+
+2. Character strings are already used for static encoding instructions in TTCN-3 attributes. Our intention was to follow the same paradigm for dynamic encoding instructions as well. Besides, we don't expect that this parameter will be widely used and if used, it probably won't contain very complicated content. Using the charstring type also saves the user from making type checks in their codecs. In case our assumptions turns out to be wrong, it is always possible to lift the type restriction and allow values of all types in the next version of the TTCN-3 specification.
+
+
+
+ + + + + + + + + + +
+ (0012412) +
+ Tomas Urban    +
+ 05-11-2014 08:16    +
+ 		+ + + + +
+ Resolution proposal uploaded. Please review.
+
+If you find the resolution acceptable, please create a CR for TCI changes and assign it to me.
+
+
+
+ + + + + + + + + + +
+ (0012467) +
+ Gyorgy Rethy    +
+ 06-11-2014 13:39    +
+ 		+ + + + +
+ Part-1 addition is OK with me.
+
+
+
+ + + + + + + + + + +
+ (0012474) +
+ Gyorgy Rethy    +
+ 06-11-2014 15:19    +
+ 		+ + + + +
+ CR6799_resolution_P9_v1.doc: Part-9 portion of the solution. Please check.
+
+
+
+ + + + + + + + + + +
+ (0012477) +
+ Tomas Urban    +
+ 06-11-2014 16:02    +
+ 		+ + + + +
+ According to our discussion I changed the part concerning xmlns and made a couple of minor editorial changes (removed variant attribute from the syntax, changed quotation marks, swapped neither and nor).
+
+Please review.
+
+
+
+ + + + + + + + + + +
+ (0012478) +
+ Tomas Urban    +
+ 07-11-2014 08:47    +
+ 		+ + + + +
+ The encoding_info parameter changed to universal string for additional flexibility.
+
+
+
+ + + + + + + + + + +
+ (0012512) +
+ Gyorgy Rethy    +
+ 21-11-2014 10:25    +
+ 		+ + + + +
+ Part-1 resolution in CR6799_v2.docx is OK with me.
+
+Please check Part-9 resolution in CR6799_resolution_P9_v3.doc. If OK with you, CR can directly be set to resolved.
+
+
+
+ + + + + + + + + + +
+ (0012514) +
+ Tomas Urban    +
+ 21-11-2014 15:19    +
+ 		+ + + + +
+ I have no objections. The resolution v3 can be added to the part 9.
+
+
+
+ + + + + + + + + + +
+ (0012597) +
+ Gyorgy Rethy    +
+ 31-12-2014 11:51    +
+ 		+ + + + +
+ Added to draft V4.5.3
+
+
+
+ + + + + + + + + + +
+ (0013147) +
+ Gyorgy Rethy    +
+ 07-08-2015 13:41    +
+ 		+ + + + +
+ Implemented in interim draft V4.7.2 uploaded to MTS's drafts area (file es_20187301v040702_e.docx of CR 7085).
+
+ + diff --git a/docs/mantis/CR6800.md b/docs/mantis/CR6800.md new file mode 100644 index 0000000000000000000000000000000000000000..69e681338fb7bf65a38e2c0b0184c6903392b78b --- /dev/null +++ b/docs/mantis/CR6800.md @@ -0,0 +1,449 @@ + + + + + + + + + + + + + 0006800: In TTCN-3 "XSD_typeTypes" should never be used for sending XML messages, instead use "XSD_elementTypes"! - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006800Part 09: Using XML with TTCN-3Clarificationpublic08-10-2014 16:2304-12-2015 15:04
ReporterThilo Lauer 
Assigned ToGyorgy Rethy 
PriorityhighSeveritymajorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.5.1 (published 2013-04) 
Target Versionv4.7.1 (published 2016-07)Fixed in Versionv4.7.1 (published 2016-07) 
Clause Reference(s)TTCN-3, Part 9
For STF discussion
Source (company - Author) Devoteam - Thilo Lauer
Summary0006800: In TTCN-3 "XSD_typeTypes" should never be used for sending XML messages, instead use "XSD_elementTypes"!
Description1.) XML / XSD does not allow to send/receive XSD type definitions itself.
+    XML / XSD only allows to send/receive XSD element definitions.
+
+2.) Part 9 defines a mapping for both XSD type def. and XSD element def. to TTCN-3 types. To distinguish both ones let's call these TTCN-3 types "XSD_typeTypes" and "XSD_elementTypes" here.
+
+3.) As a consequence of 1.) in TTCN-3 only values and templates of "XSD_elementTypes" should be used to send/receive XML-messages.
+This should be made obvious to TTCN-3 users/developers.
+
+Sending/Receiving of "XSD_typeTypes" values/templates conform to XSD definitions is currently not covered by Part 9 nor by the XML / XSD standards and should therefore be avoided.
+
+See the uploaded PowerPoint document for an LTE example.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filespptx CR_In TTCN-3 XSD_typeTypes should never be used for sending XML messages, instead use XSD_elementTypes.pptx (855,384) 08-10-2014 16:23
http://oldforge.etsi.org/mantis/file_download.php?file_id=3120&type=bug
msg TTCN-3 CR 6800 - XSD_typeTypes and XSD_elementTypes.msg (35,840) 04-11-2014 13:03
http://oldforge.etsi.org/mantis/file_download.php?file_id=3156&type=bug
docx CR6800_v1.docx (47,211) 06-11-2014 08:45
http://oldforge.etsi.org/mantis/file_download.php?file_id=3168&type=bug
docx CR6800_v2.docx (48,193) 06-11-2014 13:29
http://oldforge.etsi.org/mantis/file_download.php?file_id=3176&type=bug
docx CR6800_v3.docx (49,100) 02-11-2015 10:39
http://oldforge.etsi.org/mantis/file_download.php?file_id=3333&type=bug
Issue History
Date ModifiedUsernameFieldChange
08-10-2014 16:23Thilo LauerNew Issue
08-10-2014 16:23Thilo LauerFile Added: CR_In TTCN-3 XSD_typeTypes should never be used for sending XML messages, instead use XSD_elementTypes.pptx
03-11-2014 10:13Gyorgy RethyTarget Version => v4.6.1 (published 2015-06)
03-11-2014 14:32Gyorgy RethyPriorityhigh => urgent
03-11-2014 14:33Gyorgy RethyPriorityurgent => high
03-11-2014 16:23Gyorgy RethyNote Added: 0012384
03-11-2014 16:23Gyorgy RethyAssigned To => Gyorgy Rethy
03-11-2014 16:23Gyorgy RethyStatusnew => assigned
04-11-2014 13:03Gyorgy RethyFile Added: TTCN-3 CR 6800 - XSD_typeTypes and XSD_elementTypes.msg
04-11-2014 13:07Gyorgy RethyNote Added: 0012396
04-11-2014 13:07Gyorgy RethyFile Added: CR6800_resolution_v1.doc
04-11-2014 13:08Gyorgy RethyNote Added: 0012397
04-11-2014 17:18Gyorgy RethyFile Deleted: CR6800_resolution_v1.doc
04-11-2014 17:19Gyorgy RethyFile Added: CR6800_resolution_v1.doc
04-11-2014 17:19Gyorgy RethyAssigned ToGyorgy Rethy => Tomas Urban
05-11-2014 08:38Tomas UrbanNote Added: 0012413
05-11-2014 08:38Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
05-11-2014 08:45Gyorgy RethyAssigned ToGyorgy Rethy => Tomas Urban
05-11-2014 09:07Gyorgy RethyFile Deleted: CR6800_resolution_v1.doc
06-11-2014 08:45Tomas UrbanFile Added: CR6800_v1.docx
06-11-2014 08:51Tomas UrbanNote Added: 0012444
06-11-2014 08:51Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
06-11-2014 08:51Tomas UrbanStatusassigned => confirmed
06-11-2014 09:42Gyorgy RethyNote Added: 0012449
06-11-2014 09:43Gyorgy RethyAssigned ToGyorgy Rethy => Tomas Urban
06-11-2014 09:43Gyorgy RethyStatusconfirmed => assigned
06-11-2014 13:29Tomas UrbanFile Added: CR6800_v2.docx
06-11-2014 13:32Tomas UrbanNote Added: 0012465
06-11-2014 14:00Tomas UrbanNote Added: 0012468
06-11-2014 14:03Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
06-11-2014 14:03Tomas UrbanStatusassigned => confirmed
26-01-2015 10:11Gyorgy RethyTarget Versionv4.6.1 (published 2015-06) => v4.7.1 (published 2016-07)
02-11-2015 10:39Gyorgy RethyFile Added: CR6800_v3.docx
02-11-2015 10:39Gyorgy RethyNote Added: 0013434
02-11-2015 10:40Gyorgy RethyAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
02-11-2015 10:40Gyorgy RethyStatusconfirmed => assigned
02-11-2015 13:22Jacob Wieland - SpirentNote Added: 0013435
02-11-2015 13:22Jacob Wieland - SpirentStatusassigned => resolved
02-11-2015 13:22Jacob Wieland - SpirentFixed in Version => v4.7.1 (published 2016-07)
02-11-2015 13:22Jacob Wieland - SpirentResolutionopen => fixed
04-12-2015 15:04Gyorgy RethyNote Added: 0013557
04-12-2015 15:04Gyorgy RethyStatusresolved => closed
04-12-2015 15:04Gyorgy RethyAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0012384) +
+ Gyorgy Rethy    +
+ 03-11-2014 16:23    +
+ 		+ + + + +
+ STF discussion: friend visibility could be used to make "XSD_Type_types" visible within modules converted fron XSD specs only. Think about possible side effects.
+
+
+
+ + + + + + + + + + +
+ (0012396) +
+ Gyorgy Rethy    +
+ 04-11-2014 13:07    +
+ 		+ + + + +
+ TTCN-3 CR 6800 - XSD_typeTypes and XSD_elementTypes.msg : mail sent to Thilo Lauer on this issue.
+Two options sketched:
+- leave policing of usage of TTCN-3 types generated for XSD types for tools
+- use friend visibility to make TTCN-3 types generated for XSD types unvisible outside of the generated set of modules.
+
+
+
+ + + + + + + + + + +
+ (0012397) +
+ Gyorgy Rethy    +
+ 04-11-2014 13:08    +
+ 		+ + + + +
+ CR6800_resolution_v1.doc: first draft for the second option. To be further refined if this option is decided.
+
+
+
+ + + + + + + + + + +
+ (0012413) +
+ Tomas Urban    +
+ 05-11-2014 08:38    +
+ 		+ + + + +
+ I am concerned about adding friend visibility to the XSD module type definitions. It is very likely that these types are used in function definitions of existing test suites, e.g. LTE. With friend visibility, these test suits won't compile.
+
+Before going on with this change, we should carefully check the usage of XSD_typeTypes in the existing test suites (and especially the ones maintained by ETSI) so that we don't break anything.
+
+An alternative solution to the visibility restriction would be introduction of a modifier for type definitions that would restrict the type from being used in communication operations:
+
+type @TBD record Rec {...} // suitable modifier name has to be found
+:
+p.send(Rec:{...}) // produces an error because the Rec type has the modifier
+
+Such a solution won't break any (correctly written) TTCN-3 code, but the disadvantage is that we would make the language even more complex by introducing a new modifier.
+
+
+
+ + + + + + + + + + +
+ (0012444) +
+ Tomas Urban    +
+ 06-11-2014 08:51    +
+ 		+ + + + +
+ Proposed solution: a restriction in clause B.2 saying that only values or templates that a result of transformation of XSD elements and attributes can be used in codec operations. Values and templates derived from other XSD definitions shall cause an error. It is up to TTCN-3 tool vendors to decide whether to detect this kind of error during static compilation checks (which should be possible as encoding variants are resolved during static analysis) or in runtime when invoking the codec.
+
+
+
+ + + + + + + + + + +
+ (0012449) +
+ Gyorgy Rethy    +
+ 06-11-2014 09:42    +
+ 		+ + + + +
+ STF discussion: we need continue discussion with STF160 to agree on a mutually suitable solution. We need to prepare a summary of the possible options, pros and cons.
+
+
+
+ + + + + + + + + + +
+ (0012465) +
+ Tomas Urban    +
+ 06-11-2014 13:32    +
+ 		+ + + + +
+ Proposed solution changes according to the conclusion of STF discussion:
+- the rules were moved to the first section of Annex B
+- the rules were split to communication operations (only elements allowed) and codec operations (elements and attributes)
+- additional notes added to point out the posibility of static semantic check by TTCN-3 tools
+
+
+
+ + + + + + + + + + +
+ (0012468) +
+ Tomas Urban    +
+ 06-11-2014 14:00    +
+ 		+ + + + +
+ Summary of solutions considered by the STF:
+
+1. Friend visibility of TTCN-3 types that are based on XSD type definitions
+Pros: TTCN-3 types are not visible outside of the modules that are result of the XSD-to-TTCN-3 mapping, it is not possible to use them for sending/receiving.
+Cons: The types cannot be used in other places where it might be handy, e.g. in parameters of parameterized templates. There's a big probability that existing test suites use them this way. The change would cause problems with backward compatibility.
+Conclusion: This approach was found too restrictive and backward compatibility issues are an obvious showstopper.
+
+2. New modifier restricting the use of types in certain operations
+Pros: It would efficiently solve the problem, because the tools would indicate an error when a type with the modifier is used in forbidden operations. There would not be any backward compatibility issues as the modifier was not present in the previous versions.
+Cons: Introduction of a modifier increases complexity of the language and requires changes in the core language standard.
+Conclusion: It was found that the case is not strong enough for introduction of a modifier. It is also a question if modifiers can actualy be used this way.
+
+3. Restriction disallowing the use of TTCN-3 types derived from XSD types in templates
+Pros: It would solve the issue as tools would announce an error when attempting to create such templates.
+Cons: Similar to 1: too restrictive, the types might be already used e.g. in template parameters. Template parameters could be actually excluded from the rule, but that makes the rules more complicated. Besides, there is still a problem with predefined template fragments that are declared formally as templates, but never used directly in communication operations. Not backward compatible.
+Conclusion: Reject for problems with backward compatibility issues and excesive restrictions imposed on the users.
+
+4. Restriction disallowing the use of TTCN-3 types derived from XSD types in communication and encoding operations
+Pros: Addresses the root of the problem, i.e. the use of types that should never be passed to the codec. It should be possible to detect the error at compilation time as variant attributes are statically resolved.
+Cons: The problem cannot be detected when constructing templates (but that might be actually useful when creating template fragments).
+Conclusion: This proposal was selected as the main candidate for resolving the CR.
+
+
+
+ + + + + + + + + + +
+ (0013434) +
+ Gyorgy Rethy    +
+ 02-11-2015 10:39    +
+ 		+ + + + +
+ CR6800_v3.docx, please check.
+
+
+
+ + + + + + + + + + +
+ (0013435) +
+ Jacob Wieland - Spirent    +
+ 02-11-2015 13:22    +
+ 		+ + + + +
+ looks ok to me
+
+
+
+ + + + + + + + + + +
+ (0013557) +
+ Gyorgy Rethy    +
+ 04-12-2015 15:04    +
+ 		+ + + + +
+ Added to draft V4.6.3
+
+ + diff --git a/docs/mantis/CR6801.md b/docs/mantis/CR6801.md new file mode 100644 index 0000000000000000000000000000000000000000..02d5e7a8a39e4ecbb564318e4843ec566e338bfd --- /dev/null +++ b/docs/mantis/CR6801.md @@ -0,0 +1,604 @@ + + + + + + + + + + + + + 0006801: Visibility of component definitions - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Object-oriented features (ES 203 790)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006801Ext Pack: Object-oriented features (ES 203 790)[All Projects] Generalpublic09-10-2014 18:4916-04-2018 11:56
ReporterGyorgy Rethy 
Assigned ToKristóf Szabados 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionreopened 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0006801: Visibility of component definitions
DescriptionWhen defining libaries, it is often the case that some data shall not be manipulated by the users of the library directly; e.g. the internal database of a test framework, storing entity states, simulated entity-related data, temporary data like session ids etc. These are typically defined as component variables.
+
+This is because the type and structure of framework-internal data may (in fact WILL) change over time, as the framework is developed further. But if the user access framework-internal data directly, these changes causes the user code be broken.
+
+TTCN-3 doesn't have the means to disable direct access to component definitions. Please note, that at least the "top level" component types definitions of the framework shall be public, as the users shall be able to extend them.
+
+The solution of the problem is to introduce visibily within components for component definitions as well:
+In component member definitions they mean the following:
+• The public modifier means that any function/testcase/altstep running on that component instance can access the member definition directly.
+• The private modifier means that only those functions/testcases/altsteps can access the definition which refer to the component type in its runs on clause directly. If they run on a component type extending the one containing the definition, it will not be directly visible.
+The friend modifier is not available within component types.
+
+
+In this way framework-internal data is defined within private component types as private definitions. For data manipulation set and get functions are defined within the same module, with public visibility. These can be used by the users. Also, public component type(s), extending the private one is defined that other library modules or the users can use directly or extend further.
+
+See attached code example.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0007679closed Jens Grabowski Class Concept to be added 
related to 0007693closed Kristóf Szabados component members with visibility and functions inside the components 
Attached Files? public_private_componentdef.ttcn (1,829) 09-10-2014 19:00
http://oldforge.etsi.org/mantis/file_download.php?file_id=3138&type=bug
pptx Component Field Visibility.pptx (56,670) 13-10-2015 10:34
http://oldforge.etsi.org/mantis/file_download.php?file_id=3298&type=bug
docx CR6801_resolution_v1.docx (310,869) 15-10-2015 11:52
http://oldforge.etsi.org/mantis/file_download.php?file_id=3312&type=bug
docx CR6801_resolution_v1_CommentsJG.docx (259,935) 16-10-2015 09:14
http://oldforge.etsi.org/mantis/file_download.php?file_id=3328&type=bug
docx CR6801_resolution_v2.docx (321,149) 16-10-2015 10:26
http://oldforge.etsi.org/mantis/file_download.php?file_id=3329&type=bug
docx CR6801_resolution_v3.docx (321,797) 02-11-2015 13:22
http://oldforge.etsi.org/mantis/file_download.php?file_id=3334&type=bug
docx CR6801_resolution_v4.docx (528,538) 02-11-2015 14:31
http://oldforge.etsi.org/mantis/file_download.php?file_id=3337&type=bug
docx CR6801_resolution_v5.docx (262,590) 22-07-2016 13:21
http://oldforge.etsi.org/mantis/file_download.php?file_id=3433&type=bug
Issue History
Date ModifiedUsernameFieldChange
09-10-2014 18:49Gyorgy RethyNew Issue
09-10-2014 18:50Gyorgy RethyFile Added: public_private_moduledef.ttcn
09-10-2014 18:50Gyorgy RethyFile Deleted: public_private_moduledef.ttcn
09-10-2014 18:52Gyorgy RethyFile Added: public_private_componentdef.ttcn
09-10-2014 18:59Gyorgy RethyFile Deleted: public_private_componentdef.ttcn
09-10-2014 19:00Gyorgy RethyFile Added: public_private_componentdef.ttcn
10-10-2014 09:46Jacob Wieland - SpirentNote Added: 0012342
03-11-2014 09:34Gyorgy RethyTarget Version => v4.7.1 (published 2015-06)
06-11-2014 09:12Gyorgy RethyTarget Versionv4.7.1 (published 2015-06) => v4.8.1 (published 2016-07)
21-11-2014 09:50Gyorgy RethyProduct Version => v4.7.1 (published 2015-06)
03-08-2015 15:25Gyorgy RethyNote Added: 0013042
03-08-2015 15:25Gyorgy RethyAssigned To => Jens Grabowski
03-08-2015 15:25Gyorgy RethyStatusnew => assigned
13-10-2015 07:29Jens GrabowskiAssigned ToJens Grabowski => Jacob Wieland - Spirent
13-10-2015 10:34Jacob Wieland - SpirentFile Added: Component Field Visibility.pptx
13-10-2015 10:35Jacob Wieland - SpirentNote Added: 0013363
14-10-2015 15:30Gyorgy RethyNote Added: 0013387
15-10-2015 11:52Jacob Wieland - SpirentFile Added: CR6801_resolution_v1.docx
15-10-2015 11:53Jacob Wieland - SpirentNote Added: 0013394
15-10-2015 11:53Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Jens Grabowski
15-10-2015 11:53Jacob Wieland - SpirentStatusassigned => confirmed
16-10-2015 09:14Jens GrabowskiNote Added: 0013423
16-10-2015 09:14Jens GrabowskiFile Added: CR6801_resolution_v1_CommentsJG.docx
16-10-2015 09:14Jens GrabowskiAssigned ToJens Grabowski => Jacob Wieland - Spirent
16-10-2015 09:14Jens GrabowskiStatusconfirmed => assigned
16-10-2015 10:26Jacob Wieland - SpirentFile Added: CR6801_resolution_v2.docx
16-10-2015 10:27Jacob Wieland - SpirentNote Added: 0013424
16-10-2015 10:27Jacob Wieland - SpirentNote Added: 0013425
16-10-2015 10:27Jacob Wieland - SpirentStatusassigned => confirmed
16-10-2015 10:27Jacob Wieland - SpirentStatusconfirmed => assigned
16-10-2015 10:28Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
16-10-2015 10:28Jacob Wieland - SpirentStatusassigned => confirmed
02-11-2015 13:22Gyorgy RethyFile Added: CR6801_resolution_v3.docx
02-11-2015 13:28Gyorgy RethyNote Added: 0013436
02-11-2015 13:28Gyorgy RethyAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
02-11-2015 13:28Gyorgy RethyStatusconfirmed => assigned
02-11-2015 14:31Jacob Wieland - SpirentFile Added: CR6801_resolution_v4.docx
02-11-2015 14:33Jacob Wieland - SpirentNote Added: 0013443
02-11-2015 14:33Jacob Wieland - SpirentStatusassigned => resolved
02-11-2015 14:33Jacob Wieland - SpirentFixed in Version => v4.8.1 (published 2016-07)
02-11-2015 14:33Jacob Wieland - SpirentResolutionopen => fixed
02-11-2015 14:33Jacob Wieland - SpirentStatusresolved => feedback
02-11-2015 14:33Jacob Wieland - SpirentResolutionfixed => reopened
02-11-2015 14:34Jacob Wieland - SpirentStatusfeedback => resolved
02-11-2015 14:34Jacob Wieland - SpirentResolutionreopened => fixed
02-11-2015 14:34Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
16-12-2015 11:03Gyorgy RethyNote Added: 0013636
16-12-2015 11:03Gyorgy RethyStatusresolved => feedback
16-12-2015 11:55Jacob Wieland - SpirentNote Added: 0013637
16-12-2015 12:00Jacob Wieland - SpirentNote Edited: 0013637bug_revision_view_page.php?bugnote_id=13637#r246
16-12-2015 12:01Jacob Wieland - SpirentNote Edited: 0013637bug_revision_view_page.php?bugnote_id=13637#r247
18-07-2016 11:20Jens GrabowskiAssigned ToGyorgy Rethy => Kristóf Szabados
18-07-2016 11:20Jens GrabowskiStatusfeedback => assigned
18-07-2016 11:20Jens GrabowskiStatusassigned => feedback
22-07-2016 13:21Kristóf SzabadosFile Added: CR6801_resolution_v5.docx
22-07-2016 13:23Kristóf SzabadosNote Added: 0014037
17-08-2016 10:47Jacob Wieland - SpirentTarget Versionv4.8.1 (published 2016-07) => v4.9.1(ongoing)
17-08-2016 11:02Jacob Wieland - SpirentStatusfeedback => resolved
17-08-2016 11:02Jacob Wieland - SpirentFixed in Versionv4.8.1 (published 2016-07) => v4.9.1(ongoing)
17-08-2016 11:02Jacob Wieland - SpirentAssigned ToKristóf Szabados => Gyorgy Rethy
18-11-2016 08:24Kristóf SzabadosAssigned ToGyorgy Rethy => Kristóf Szabados
18-11-2016 08:24Kristóf SzabadosStatusresolved => feedback
18-11-2016 08:24Kristóf SzabadosResolutionfixed => reopened
18-11-2016 08:42Kristóf SzabadosStatusfeedback => assigned
18-11-2016 08:42Kristóf SzabadosFixed in Versionv4.9.1(ongoing) =>
18-11-2016 08:42Kristóf SzabadosTarget Versionv4.9.1(ongoing) => Next version (to be defined)
18-11-2016 08:43Kristóf SzabadosNote Added: 0014322
16-07-2017 13:10Kristóf SzabadosRelationship addedrelated to 0007693
28-07-2017 12:36Jens GrabowskiProjectPart 01: TTCN-3 Core Language => Ext Pack: Object-oriented features (ES 203 790)
28-07-2017 12:36Jens GrabowskiCategoryNew Feature => General
27-10-2017 11:20Kristóf SzabadosRelationship addedrelated to 0007679
27-10-2017 11:21Kristóf SzabadosNote Added: 0014910
16-04-2018 11:55Jens GrabowskiStatusassigned => closed
16-04-2018 11:56Jens GrabowskiNote Added: 0015080
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0012342) +
+ Jacob Wieland - Spirent    +
+ 10-10-2014 09:46    +
+ 		+ + + + +
+ Sounds like a very reasonable proposal/concept to me.
+
+
+
+ + + + + + + + + + +
+ (0013042) +
+ Gyorgy Rethy    +
+ 03-08-2015 15:25    +
+ 		+ + + + +
+ STF discussion 03-08-2015: no consensus on the current proposal. It is felt to be restrictive to one case, maybe a more generic approach could be though about. Consider possible alternatives at the STF session in October.
+
+
+
+ + + + + + + + + + +
+ (0013363) +
+ Jacob Wieland - Spirent    +
+ 13-10-2015 10:35    +
+ 		+ + + + +
+ I have uploaded a PP-presentation discussing the different issues and possible solutions of private component members. Please review so we can use this as a basis for discussion.
+
+
+
+ + + + + + + + + + +
+ (0013387) +
+ Gyorgy Rethy    +
+ 14-10-2015 15:30    +
+ 		+ + + + +
+ STF discussion:
+- go for solution 1.5: private data can be accessed by functions complying to all conditions:
+   - having the concrete comp. type in their runs on clause
+   - are in the same module as the component type definition
+   - identified by an "accessor" modifier
+
+
+
+ + + + + + + + + + +
+ (0013394) +
+ Jacob Wieland - Spirent    +
+ 15-10-2015 11:53    +
+ 		+ + + + +
+ please review
+
+
+
+ + + + + + + + + + +
+ (0013423) +
+ Jens Grabowski    +
+ 16-10-2015 09:14    +
+ 		+ + + + +
+ See Comments in attached file. There was the discussion to deprecate indirect compatability. Maybe we should discuss this again.
+
+
+
+ + + + + + + + + + +
+ (0013424) +
+ Jacob Wieland - Spirent    +
+ 16-10-2015 10:27    +
+ 		+ + + + +
+ uploaded version addressing Jens's comments
+
+
+
+ + + + + + + + + + +
+ (0013425) +
+ Jacob Wieland - Spirent    +
+ 16-10-2015 10:27    +
+ 		+ + + + +
+ please review and resolve
+
+
+
+ + + + + + + + + + +
+ (0013436) +
+ Gyorgy Rethy    +
+ 02-11-2015 13:28    +
+ 		+ + + + +
+ CR6801_resolution_v3.docx: The text with yellow background in clause 6.3.3(about implicit type compatibility) should be moved to a new clause G.12; otherwise OK with me, only editorial changes.
+
+
+
+ + + + + + + + + + +
+ (0013443) +
+ Jacob Wieland - Spirent    +
+ 02-11-2015 14:33    +
+ 		+ + + + +
+ resolved according to last comment (also removed the NOTEs as they were only highlighting the difference between the new and the deprecated compatibility)
+
+
+
+ + + + + + + + + + +
+ (0013636) +
+ Gyorgy Rethy    +
+ 16-12-2015 11:03    +
+ 		+ + + + +
+ Sorry, we have a problem with the @accessor modifyer. The problem is that private variables are used so widely that the @accessor restriction is practically impossible to introduce at this stage.
+
+@accessor in fact "sort" the functions/atsteps within the module (in which the component type is defined) to the ones that are allowed to directly access the private definitions and the ones which are disallowed. However, in practice it would solve a null problem, as one module is always a responsibility of one person or team. Therefore, in practice, this kind of sorting is not needed.
+
+
+
+ + + + + + + + + + +
+ (0013637) +
+ Jacob Wieland - Spirent    +
+ 16-12-2015 11:55    +
(edited on: 16-12-2015 12:01)
+ 		+ + + + +
+ I thought we discussed this at length and made a decision.
+
+Of course, the usual pattern of using the publicly defined variables of a component does not work anymore, so this is not a backward-compatibility feature.
+It is a feature for the allowing to define proper APIs in the future, which at the moment is not possible.
+
+If, if I understand you correctly, you want to implicitly turn all functions inside the same module as the component containing the private variables (which, I guess, is a proprietary feature in your tool?) into implicit accessor functions for their runs on type, this incurs implicit restrictions on all functions using these functions (i.e. the previous lax component-runs-on compatibility rules cannot be used anymore).
+
+In principle, I have no problem with that, but it breaks your usual preference regarding implicitness vs. explicitness.
+
+
+
+
+
+ + + + + + + + + + +
+ (0014037) +
+ Kristóf Szabados    +
+ 22-07-2016 13:23    +
+ 		+ + + + +
+ after my conversation with Jacob I have updated the proposal: functions with the @accessor modifier are no longer required to reside in the same module as the component they are running on, they can also reside in friend modules of the component's module.
+
+
+
+ + + + + + + + + + +
+ (0014322) +
+ Kristóf Szabados    +
+ 18-11-2016 08:43    +
+ 		+ + + + +
+ re-opened and shifted for next year.
+We should reconsider this CR together with next year's Object Orientation topic.
+
+
+
+ + + + + + + + + + +
+ (0014910) +
+ Kristóf Szabados    +
+ 27-10-2017 11:21    +
+ 		+ + + + +
+ This CR will be solved as part of the Object-Oriented Extension (CR7679)
+
+
+
+ + + + + + + + + + +
+ (0015080) +
+ Jens Grabowski    +
+ 16-04-2018 11:56    +
+ 		+ + + + +
+ CR solved as part of the OO-extension.
+
+ + diff --git a/docs/mantis/CR6802.md b/docs/mantis/CR6802.md new file mode 100644 index 0000000000000000000000000000000000000000..23ae8c56fa4e7697118116bb0c182051ba9f3c9a --- /dev/null +++ b/docs/mantis/CR6802.md @@ -0,0 +1,181 @@ + + + + + + + + + + + + + 0006802: isvalue Definition is inconsistent/confusing - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006802Part 01: TTCN-3 Core LanguageClarificationpublic20-10-2014 12:1606-01-2015 18:46
ReporterJacob Wieland - Spirent 
Assigned ToGyorgy Rethy 
PrioritylowSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.6.1 (published 2014-06) 
Target Versionv4.7.1 (published 2015-06)Fixed in Versionv4.7.1 (published 2015-06) 
Clause Reference(s)C.3.3
Source (company - Author)Testing Technologies - Jacob Wieland
Summary0006802: isvalue Definition is inconsistent/confusing
DescriptionIn section C.3.3 (isvalue), it is stated:
+
+"This function is allowed for templates of all data types."
+
+A data type is defined as all types not containing component/port/default on any level.
+
+But, the isvalue function then explicitly is defined as returning true for the null-value which is only valid for component and default types.
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
20-10-2014 12:16Jacob Wieland - SpirentNew Issue
20-10-2014 12:39Tomas UrbanNote Added: 0012368
21-10-2014 09:25Jacob Wieland - SpirentNote Added: 0012369
03-11-2014 09:05Gyorgy RethyProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
03-11-2014 09:31Gyorgy RethyNote Added: 0012370
03-11-2014 09:31Gyorgy RethyProduct Version => v4.6.1 (published 2014-06)
03-11-2014 09:31Gyorgy RethyTarget Version => v4.7.1 (published 2015-06)
03-11-2014 15:25Gyorgy RethyStatusnew => resolved
03-11-2014 15:25Gyorgy RethyResolutionopen => fixed
03-11-2014 15:25Gyorgy RethyFixed in Version => v4.7.1 (published 2015-06)
03-11-2014 15:26Gyorgy RethyAssigned To => Gyorgy Rethy
03-11-2014 15:26Gyorgy RethyStatusresolved => assigned
03-11-2014 15:26Gyorgy RethyStatusassigned => resolved
06-01-2015 18:46Gyorgy RethyNote Added: 0012654
06-01-2015 18:46Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0012368) +
+ Tomas Urban    +
+ 20-10-2014 12:39    +
+ 		+ + + + +
+ Null value is valid for the address type too.
+
+
+
+ + + + + + + + + + +
+ (0012369) +
+ Jacob Wieland - Spirent    +
+ 21-10-2014 09:25    +
+ 		+ + + + +
+ You are right, since the address type is also not intrinsically a data type (it is always mentioned additionally to data types) but only additionally allows null explicitly, the same confusion for isvalue arises also for the address type.
+
+
+
+ + + + + + + + + + +
+ (0012370) +
+ Gyorgy Rethy    +
+ 03-11-2014 09:31    +
+ 		+ + + + +
+ I propose the correction:
+"C.3.3 The IsValue function
+    isvalue(in template any_type inpar) return boolean;
+
+This function is allowed for templates of all data types, <new> component and address types and default values</new>. The function shall ...
+The null value assigned to default and component references shall be considered as concrete values."
+
+Note: templates shall not be of default type, that's why this wording.
+
+For ports isvalue would make no sense, they cannot be a value or template at all.
+
+
+
+ + + + + + + + + + +
+ (0012654) +
+ Gyorgy Rethy    +
+ 06-01-2015 18:46    +
+ 		+ + + + +
+ Added to draft V4.6.3
+
+ + diff --git a/docs/mantis/CR6803.md b/docs/mantis/CR6803.md new file mode 100644 index 0000000000000000000000000000000000000000..3c219d013846d45df1bc41842e4e38f1be6a8c0b --- /dev/null +++ b/docs/mantis/CR6803.md @@ -0,0 +1,131 @@ + + + + + + + + + + + + + 0006803: Implementation of CR 0006775: getverdict from other component in Part 4 - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 04: TTCN-3 Operational Semantics
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006803Part 04: TTCN-3 Operational SemanticsTechnicalpublic04-11-2014 10:4121-07-2016 08:37
ReporterJens Grabowski 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.4.1 (published 2012-04) 
Target Versionv4.5.1 (published 2016-07)Fixed in Versionv4.5.1 (published 2016-07) 
Clause Reference(s)9.27
Source (company - Author)Jens Grabowski (STF 478)
Summary0006803: Implementation of CR 0006775: getverdict from other component in Part 4
DescriptionCR 0006775: getverdict from other component has to be implemented in Part 4
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Fileszip es_20187304v040401p-CR6803.zip (1,606,564) 02-11-2015 15:37
http://oldforge.etsi.org/mantis/file_download.php?file_id=3338&type=bug
zip es_20187304v040401p-CR6803-v2.zip (1,606,032) 03-11-2015 11:32
http://oldforge.etsi.org/mantis/file_download.php?file_id=3349&type=bug
Issue History
Date ModifiedUsernameFieldChange
04-11-2014 10:41Jens GrabowskiNew Issue
04-11-2014 10:41Jens GrabowskiStatusnew => assigned
04-11-2014 10:41Jens GrabowskiAssigned To => Jens Grabowski
02-11-2015 15:37Jens GrabowskiFile Added: es_20187304v040401p-CR6803.zip
02-11-2015 15:37Jens GrabowskiNote Added: 0013445
02-11-2015 15:37Jens GrabowskiAssigned ToJens Grabowski => Jacob Wieland - Spirent
03-11-2015 09:51Jacob Wieland - SpirentNote Added: 0013454
03-11-2015 09:51Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Jens Grabowski
03-11-2015 09:51Jacob Wieland - SpirentStatusassigned => confirmed
03-11-2015 11:32Jens GrabowskiFile Added: es_20187304v040401p-CR6803-v2.zip
03-11-2015 11:33Jens GrabowskiNote Added: 0013463
03-11-2015 12:14Jacob Wieland - SpirentStatusconfirmed => resolved
03-11-2015 12:14Jacob Wieland - SpirentFixed in Version => v4.5.1 (published 2016-07)
03-11-2015 12:14Jacob Wieland - SpirentResolutionopen => fixed
21-07-2016 08:37Jens GrabowskiStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0013445) +
+ Jens Grabowski    +
+ 02-11-2015 15:37    +
+ 		+ + + + +
+ Jacob, please check.
+
+
+
+ + + + + + + + + + +
+ (0013454) +
+ Jacob Wieland - Spirent    +
+ 03-11-2015 09:51    +
+ 		+ + + + +
+ everything ok except for typo in 8.3.3a (componend), pls fix and resolve
+
+
+
+ + + + + + + + + + +
+ (0013463) +
+ Jens Grabowski    +
+ 03-11-2015 11:33    +
+ 		+ + + + +
+ Typo fixed.
+
+ + diff --git a/docs/mantis/CR6804.md b/docs/mantis/CR6804.md new file mode 100644 index 0000000000000000000000000000000000000000..c4c38290ec14671714105b882cbc58233b7935f3 --- /dev/null +++ b/docs/mantis/CR6804.md @@ -0,0 +1,131 @@ + + + + + + + + + + + + + 0006804: TCI support for verdict assignment in done and killed operations - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006804Part 06: TTCN-3 Control InterfaceTechnicalpublic04-11-2014 14:5926-01-2015 11:36
ReporterTomas Urban 
Assigned ToTomas Urban 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.7.1 (published 2015-06) 
Target Versionv4.7.1 (published 2015-06)Fixed in Versionv4.7.1 (published 2015-06) 
Clause Reference(s)7.3.3, 7.3.4
Source (company - Author)STF 478
Summary0006804: TCI support for verdict assignment in done and killed operations
DescriptionAs 0006775 introduced verdict redirect assignment for done and killed operations, additional changes have to be made in the TCI.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0006775closed Gyorgy Rethy Part 01: TTCN-3 Core Language getverdict from other component 
Attached Filesdocx CR6804_v1.docx (110,703) 04-11-2014 16:17
http://oldforge.etsi.org/mantis/file_download.php?file_id=3160&type=bug
Issue History
Date ModifiedUsernameFieldChange
04-11-2014 14:59Tomas UrbanNew Issue
04-11-2014 14:59Tomas UrbanStatusnew => assigned
04-11-2014 14:59Tomas UrbanAssigned To => Tomas Urban
04-11-2014 14:59Tomas UrbanRelationship addedrelated to 0006775
04-11-2014 16:17Tomas UrbanFile Added: CR6804_v1.docx
04-11-2014 16:18Tomas UrbanNote Added: 0012406
04-11-2014 16:18Tomas UrbanAssigned ToTomas Urban => Jens Grabowski
04-11-2014 16:18Tomas UrbanStatusassigned => confirmed
05-11-2014 12:43Jens GrabowskiNote Added: 0012423
05-11-2014 12:43Jens GrabowskiStatusconfirmed => resolved
05-11-2014 12:43Jens GrabowskiResolutionopen => fixed
05-11-2014 12:43Jens GrabowskiAssigned ToJens Grabowski => Tomas Urban
17-12-2014 09:40Tomas UrbanNote Added: 0012559
17-12-2014 09:40Tomas UrbanStatusresolved => closed
26-01-2015 11:36Gyorgy RethyFixed in Version => v4.7.1 (published 2015-06)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0012406) +
+ Tomas Urban    +
+ 04-11-2014 16:18    +
+ 		+ + + + +
+ Proposal uploaded. Please review.
+
+
+
+ + + + + + + + + + +
+ (0012423) +
+ Jens Grabowski    +
+ 05-11-2014 12:43    +
+ 		+ + + + +
+ Resolution is ok with me.
+
+
+
+ + + + + + + + + + +
+ (0012559) +
+ Tomas Urban    +
+ 17-12-2014 09:40    +
+ 		+ + + + +
+ Added to the TCI specification draft 4.6.2.
+
+ + diff --git a/docs/mantis/CR6811.md b/docs/mantis/CR6811.md new file mode 100644 index 0000000000000000000000000000000000000000..f7fc0f9508ea2e66df14414e81346a3e0fded5f6 --- /dev/null +++ b/docs/mantis/CR6811.md @@ -0,0 +1,253 @@ + + + + + + + + + + + + + 0006811: Missing BNF support for lower bound exclustion in length restriction - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006811Part 01: TTCN-3 Core LanguageTechnicalpublic05-11-2014 14:5704-01-2015 20:11
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.6.1 (published 2014-06) 
Target Versionv4.7.1 (published 2015-06)Fixed in Versionv4.7.1 (published 2015-06) 
Clause Reference(s)A.1.6.1.1
Source (company - Author)STF 478
Summary0006811: Missing BNF support for lower bound exclustion in length restriction
DescriptionThe BNF rule for the length restriction doesn't allow to use exclamation mark when defining the lower bound. The rule shall be changed from
+
+44.StringLength ::= LengthKeyword "(" SingleExpression [".." Bound] ")"
+
+to
+
+44.StringLength ::= LengthKeyword "(" ["!"] SingleExpression [".." Bound] ")"
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
05-11-2014 14:57Tomas UrbanNew Issue
05-11-2014 14:57Tomas UrbanStatusnew => assigned
05-11-2014 14:57Tomas UrbanAssigned To => Gyorgy Rethy
06-11-2014 08:26Gyorgy RethyNote Added: 0012442
06-11-2014 08:27Gyorgy RethyNote Added: 0012443
06-11-2014 08:27Gyorgy RethyAssigned ToGyorgy Rethy => Tomas Urban
06-11-2014 08:27Gyorgy RethyStatusassigned => confirmed
06-11-2014 08:58Tomas UrbanNote Added: 0012445
06-11-2014 08:58Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
06-11-2014 12:34Gyorgy RethyNote Added: 0012459
06-11-2014 12:35Gyorgy RethyNote Added: 0012460
06-11-2014 12:35Gyorgy RethyStatusconfirmed => resolved
06-11-2014 12:35Gyorgy RethyFixed in Version => v4.7.1 (published 2015-06)
06-11-2014 12:35Gyorgy RethyResolutionopen => fixed
04-01-2015 20:11Gyorgy RethyNote Added: 0012610
04-01-2015 20:11Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0012442) +
+ Gyorgy Rethy    +
+ 06-11-2014 08:26    +
+ 		+ + + + +
+ Optional ! is added to Bound due to special values in range constraints, where they have well defined semantics (because special values have concrete encodings)
+
+In case of length adding ! would complicate the language without obvious advantage and it would be difficult -if not impossible - to explain the semantics of ..!infinity.
+
+Let's go the opposite way and add the static semantics rule excluding ! for length contraints:
+
+44.StringLength ::= LengthKeyword "(" SingleExpression [".." Bound] ")"
+
+/* STATIC SEMANTICS - StringLength shall only be used with String types or to limit set of and record of. SingleExpression and Bound shall evaluate to non-negative integer values (in case of Bound including infinity) <new> and in Bound the oprional "!" shall not be present</new>*/
+
+
+
+ + + + + + + + + + +
+ (0012443) +
+ Gyorgy Rethy    +
+ 06-11-2014 08:27    +
+ 		+ + + + +
+ Pleae check the proposed solution in the previous note.
+
+
+
+ + + + + + + + + + +
+ (0012445) +
+ Tomas Urban    +
+ 06-11-2014 08:58    +
+ 		+ + + + +
+ In principle I agree, but I think it is better to exclude the exclamation mark directly in the BNF rule than by static semantics. This way we get rid off -infinity as well:
+
+44.StringLength ::= LengthKeyword "(" SingleExpression [".." (SingleExpression | InfinityKeyword]) ")"
+
+/* STATIC SEMANTICS - StringLength shall only be used with String types or to limit set of and record of. SingleExpression and Bound shall evaluate to non-negative integer values */
+
+
+
+ + + + + + + + + + +
+ (0012459) +
+ Gyorgy Rethy    +
+ 06-11-2014 12:34    +
+ 		+ + + + +
+ Yes, I agree, much better solution...
+
+I have chenged it in the BNF <a small change: closing ) and ] shall be swapped: InfinityKeyword)] >
+
+
+
+ + + + + + + + + + +
+ (0012460) +
+ Gyorgy Rethy    +
+ 06-11-2014 12:35    +
+ 		+ + + + +
+ Added to BNF in BNF tool and also to master copy.
+
+
+
+ + + + + + + + + + +
+ (0012610) +
+ Gyorgy Rethy    +
+ 04-01-2015 20:11    +
+ 		+ + + + +
+ Added to draft V.4.6.3
+
+ + diff --git a/docs/mantis/CR6812.md b/docs/mantis/CR6812.md new file mode 100644 index 0000000000000000000000000000000000000000..fc7370194b42882217b4b068275e23dc9cc6cfc8 --- /dev/null +++ b/docs/mantis/CR6812.md @@ -0,0 +1,866 @@ + + + + + + + + + + + + + 0006812: Abstract data classes for matching mechanisms - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006812Part 06: TTCN-3 Control InterfaceNew Featurepublic05-11-2014 15:5826-01-2015 11:39
ReporterTomas Urban 
Assigned ToTomas Urban 
PrioritynormalSeverityfeatureReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.7.1 (published 2015-06)Fixed in Versionv4.7.1 (published 2015-06) 
Clause Reference(s)7.2.2
Source (company - Author)STF 478
Summary0006812: Abstract data classes for matching mechanisms
DescriptionDuring resolving several CRs in the past (e.g. 0006793), it was repeatedly proposed that the TCI should contain dedicated classes for TTCN-3 matching mechanisms so that TCI users can access properties of the matching mechanisms via dedicated methods and even change these properties if needed.
+
+While the current version of the TCI contains crude read access (through a text conversion) that might be acceptable (but not comfortable to use) for TCI-TL or analysis of in template parameters of external functions is xTRI, it is not usable for building templates outside of the TE. Thus it e.g. not possible to modify out/inout template parameters in external functions or set the content of template parameters of test cases in TCI-TM (unless they contain no matching mechanism).
+
+This CR attempts to change that, introducing a new set of dedicated abstract TCI data classes and modifying the existing ones that allow the users to work with TTCN-3 templates in TCI without any restriction.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0006793closed Tomas Urban Value Interface is underspecified/inconsistent for Templates 
Attached Filesdocx CR6812_v1.docx (83,016) 05-11-2014 15:59
http://oldforge.etsi.org/mantis/file_download.php?file_id=3167&type=bug
docx CR6812_v2.docx (82,132) 06-11-2014 09:00
http://oldforge.etsi.org/mantis/file_download.php?file_id=3169&type=bug
docx CR6812_v3.docx (112,198) 07-11-2014 12:31
http://oldforge.etsi.org/mantis/file_download.php?file_id=3185&type=bug
docx CR6812_v4.docx (163,392) 16-12-2014 14:23
http://oldforge.etsi.org/mantis/file_download.php?file_id=3203&type=bug
Issue History
Date ModifiedUsernameFieldChange
05-11-2014 15:58Tomas UrbanNew Issue
05-11-2014 15:58Tomas UrbanStatusnew => assigned
05-11-2014 15:58Tomas UrbanAssigned To => Tomas Urban
05-11-2014 15:58Tomas UrbanRelationship addedrelated to 0006793
05-11-2014 15:59Tomas UrbanFile Added: CR6812_v1.docx
05-11-2014 16:02Tomas UrbanNote Added: 0012436
06-11-2014 07:51Tomas UrbanSummaryAbstract data classes for matching mechanims => Abstract data classes for matching mechanisms
06-11-2014 09:00Tomas UrbanFile Added: CR6812_v2.docx
06-11-2014 09:02Tomas UrbanNote Added: 0012447
06-11-2014 09:24Gyorgy RethyNote Added: 0012448
06-11-2014 09:24Gyorgy RethyTarget Version => v4.7.1 (published 2015-06)
06-11-2014 09:25Gyorgy RethyAssigned ToTomas Urban => Jens Grabowski
06-11-2014 14:17Jens GrabowskiAssigned ToJens Grabowski => Tomas Urban
07-11-2014 10:15Jacob Wieland - SpirentNote Added: 0012480
07-11-2014 10:26Tomas UrbanNote Added: 0012481
07-11-2014 10:31Jacob Wieland - SpirentNote Added: 0012482
07-11-2014 10:32Tomas UrbanNote Added: 0012483
07-11-2014 10:33Jacob Wieland - SpirentNote Added: 0012484
07-11-2014 10:39Jacob Wieland - SpirentNote Added: 0012485
07-11-2014 10:45Jacob Wieland - SpirentNote Added: 0012486
07-11-2014 10:48Jacob Wieland - SpirentNote Added: 0012487
07-11-2014 11:16Tomas UrbanNote Added: 0012488
07-11-2014 11:21Tomas UrbanNote Added: 0012489
07-11-2014 12:31Tomas UrbanFile Added: CR6812_v3.docx
07-11-2014 12:33Tomas UrbanNote Added: 0012492
07-11-2014 13:28Jacob Wieland - SpirentNote Added: 0012496
07-11-2014 13:32Jacob Wieland - SpirentNote Added: 0012497
15-12-2014 10:03Tomas UrbanNote Added: 0012551
15-12-2014 16:54Jacob Wieland - SpirentNote Added: 0012552
16-12-2014 07:53Tomas UrbanNote Added: 0012553
16-12-2014 08:16Tomas UrbanNote Edited: 0012553bug_revision_view_page.php?bugnote_id=12553#r102
16-12-2014 14:23Tomas UrbanFile Added: CR6812_v4.docx
16-12-2014 14:27Tomas UrbanNote Added: 0012554
16-12-2014 14:27Tomas UrbanAssigned ToTomas Urban => Jens Grabowski
16-12-2014 14:27Tomas UrbanStatusassigned => confirmed
16-12-2014 14:35Jacob Wieland - SpirentNote Added: 0012555
06-01-2015 10:17Jens GrabowskiNote Added: 0012635
06-01-2015 10:17Jens GrabowskiStatusconfirmed => resolved
06-01-2015 10:17Jens GrabowskiResolutionopen => fixed
06-01-2015 10:17Jens GrabowskiAssigned ToJens Grabowski => Tomas Urban
06-01-2015 10:18Tomas UrbanNote Added: 0012636
06-01-2015 10:18Tomas UrbanStatusresolved => closed
26-01-2015 11:39Gyorgy RethyFixed in Version => v4.7.1 (published 2015-06)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0012436) +
+ Tomas Urban    +
+ 05-11-2014 16:02    +
+ 		+ + + + +
+ Jacob, I added you as a monitoring user as you showed particular interest in TCI data types for matching symbols. If you have time, could you please quickly review the concept? There's no mapping at the moment, I would first like stabilize the draft before I go on with it.
+
+
+
+ + + + + + + + + + +
+ (0012447) +
+ Tomas Urban    +
+ 06-11-2014 09:02    +
+ 		+ + + + +
+ Minor corrections:
+- removed inclusive flag from the LengthRestriction abstract data class (see 0006811 for more details)
+- removed length restriction from permutations
+
+
+
+ + + + + + + + + + +
+ (0012448) +
+ Gyorgy Rethy    +
+ 06-11-2014 09:24    +
+ 		+ + + + +
+ If this CR is succeeded be agreed this year, it replaces 6793, if not, then 6793 will be implemented in V4.7.1 and this CR is moved for the next edition.
+
+
+
+ + + + + + + + + + +
+ (0012480) +
+ Jacob Wieland - Spirent    +
+ 07-11-2014 10:15    +
+ 		+ + + + +
+ I don't understand the following:
+
+"void removePermutation(TInteger index)
+Removes the permutation at the specified index. The allowed index range is from 0 to (getPermutationCount() – 1). No elements are removed from the record of by this operation. When the operation completes, the existing elements at positions specified by the removed permutation don’t belong to any permutation."
+
+
+
+ + + + + + + + + + +
+ (0012481) +
+ Tomas Urban    +
+ 07-11-2014 10:26    +
+ 		+ + + + +
+ // Let's have the following record-of template:
+rec = {0, 1, 2, 3, 4, 5};
+
+// We create a permutation:
+Permutation permutation = new Permutation(); // TCI should actually contain a factory method - I will specify that
+permutation.setStartPosition(1);
+permutation.setLength(2);
+
+// Now we add permutation to the template:
+rec.addPermutation(permutation);
+// the record-of is now { 0, permutation(1, 2), 3, 4, 5}
+// rec.getPermutationCount returns 1
+
+// If we want to remove the permuation, we call:
+rec.removePermutation(0);
+// the record-of is now again { 0, 1, 2, 3, 4, 5 }
+// the elements that belonged to the permutation (1, 2) are not deleted
+// only the permutation "wrapper" disappears
+
+
+
+ + + + + + + + + + +
+ (0012482) +
+ Jacob Wieland - Spirent    +
+ 07-11-2014 10:31    +
+ 		+ + + + +
+ In proposed section 7.2.2.3.2.
+
+"void insert(Value item, TInteger position)
+Inserts the item to the specified position inside the the matching list, replacing the original item. The matching list doesn’t change its size during this operation."
+
+Why do you call an overwriting function "insert"? For insertion, I would expect the length to change by one. Also, it should be restricted to the positions already available, I guess.
+
+I propose to either change the name to set or setItem if it shall keep the proposed semantics (I would prefer that option as then you have a get/set pair) or to change the semantics to an insert-semantics if it shall keep the name.
+
+
+
+ + + + + + + + + + +
+ (0012483) +
+ Tomas Urban    +
+ 07-11-2014 10:32    +
+ 		+ + + + +
+ Yes, that's absolutely correct. It is actually corrected in the work version of the document.
+
+
+
+ + + + + + + + + + +
+ (0012484) +
+ Jacob Wieland - Spirent    +
+ 07-11-2014 10:33    +
+ 		+ + + + +
+ Also, the following paragraph is doubled (in section 7.2.2.3.2)
+
+"
+void get(TInteger position) Returns the value or template at the specified position inside the matching mechanism.
+"
+
+
+
+ + + + + + + + + + +
+ (0012485) +
+ Jacob Wieland - Spirent    +
+ 07-11-2014 10:39    +
+ 		+ + + + +
+ Just a question: are length restrictions like
+
+length(1..4, 7 .. 8, 10 .. infinity) not allowed in TTCN-3?
+
+If they are allowed, then the LengthRestriction should be a ListMatching as well and just contain a list of number or ranges.
+
+
+
+ + + + + + + + + + +
+ (0012486) +
+ Jacob Wieland - Spirent    +
+ 07-11-2014 10:45    +
+ 		+ + + + +
+ The Permutation modelling seems a bit weird to me. Anyway, it should be restricted that permutations cannot overlap, i.e. the range between startPos..startPos+length-1 of one permutation shall not intersect with the range startPos..startPos+length-1 of another permutation attached to the same RecordOfValue.
+
+
+
+ + + + + + + + + + +
+ (0012487) +
+ Jacob Wieland - Spirent    +
+ 07-11-2014 10:48    +
+ 		+ + + + +
+ In section 7.2.2.4.1, the possibility to model -infinity is missing. Since ranges are not used only for lengths but also for integer types that can include negative infinity, this needs to be added.
+
+
+
+ + + + + + + + + + +
+ (0012488) +
+ Tomas Urban    +
+ 07-11-2014 11:16    +
+ 		+ + + + +
+ Minus infinity support is context dependent. If the RangeBoundary is used as a lower range and set to infinity, it will be interpreted as -infinity.
+
+
+
+ + + + + + + + + + +
+ (0012489) +
+ Tomas Urban    +
+ 07-11-2014 11:21    +
+ 		+ + + + +
+ The current version of the core language specification allows only a single range to be used in the length restriction.
+
+
+
+ + + + + + + + + + +
+ (0012492) +
+ Tomas Urban    +
+ 07-11-2014 12:33    +
+ 		+ + + + +
+ Interim draft uploaded. It contains several additions and corrections base on the received feedback and java mapping. C, C++ and C# mapping are still missing.
+
+
+
+ + + + + + + + + + +
+ (0012496) +
+ Jacob Wieland - Spirent    +
+ 07-11-2014 13:28    +
+ 		+ + + + +
+ The abstract TTCN-3 type and value representation consist of two parts
+
+should be changed into
+
+... consists of the following parts
+
+
+
+ + + + + + + + + + +
+ (0012497) +
+ Jacob Wieland - Spirent    +
+ 07-11-2014 13:32    +
+ 		+ + + + +
+ Also, there is no (direct) way to create an omit-template. I think omit needs to be added to the MatchingSymbols list.
+
+
+
+ + + + + + + + + + +
+ (0012551) +
+ Tomas Urban    +
+ 15-12-2014 10:03    +
+ 		+ + + + +
+ Omit templates are intentionally left out because of dual meaning of the omit symbol. The current proposal expects that omit is represented in the same way as in case of omitted values, i.e. that the notPresent function returns true. I will add a note to the proposal.
+
+
+
+ + + + + + + + + + +
+ (0012552) +
+ Jacob Wieland - Spirent    +
+ 15-12-2014 16:54    +
+ 		+ + + + +
+ That is okay, my question is about creating an omit template as root. Creating one as a field of a record/set template is already possible, of course.
+
+
+
+ + + + + + + + + + +
+ (0012553) +
+ Tomas Urban    +
+ 16-12-2014 07:53    +
(edited on: 16-12-2014 08:16)
+ 		+ + + + +
+ I think I understand what you mean. In the current specification, there are only two ways on how to set a value to omit: either using RecordValue.setFieldOmitted or creating a blank new value by calling Type.newInstance.
+
+Introducing a new matching symbol for top-level omit is possible in general. However, before we decide in its favor, we should consider the consequences. The main problem is that such a matching symbol is not compatible with the representation of omit assigned to record fields. There are two possible ways to resolve this problem:
+
+1. Introduce the dedicated matching symbol and a rule saying that assigning MatchingMechanism(OMIT) to an optional field of a record value (by calling RecordValue.setField) is the same as calling RecordValue.setFieldOmitted for the same field.
+
+2. No new matching symbol and allow to explicitly create omit from existing instances by a new function Value.setNotPresent. The function would control the Value.notPresent property which is currently available only for reading.
+
+Which of the approaches would you prefer?
+
+
+
+
+
+ + + + + + + + + + +
+ (0012554) +
+ Tomas Urban    +
+ 16-12-2014 14:27    +
+ 		+ + + + +
+ Complete version of the proposal is ready now. Jens, could you please check it?
+
+
+
+ + + + + + + + + + +
+ (0012555) +
+ Jacob Wieland - Spirent    +
+ 16-12-2014 14:35    +
+ 		+ + + + +
+ I think setNotPresent sounds fine to me.
+
+
+
+ + + + + + + + + + +
+ (0012635) +
+ Jens Grabowski    +
+ 06-01-2015 10:17    +
+ 		+ + + + +
+ Ok for me.
+
+
+
+ + + + + + + + + + +
+ (0012636) +
+ Tomas Urban    +
+ 06-01-2015 10:18    +
+ 		+ + + + +
+ Added to the TCI specification draft.
+
+ + diff --git a/docs/mantis/CR6813.md b/docs/mantis/CR6813.md new file mode 100644 index 0000000000000000000000000000000000000000..056a7b10d0437701b964b24730bb9644514ebe41 --- /dev/null +++ b/docs/mantis/CR6813.md @@ -0,0 +1,271 @@ + + + + + + + + + + + + + 0006813: Passing fields or elements of a component variable as inout parameter - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006813Part 01: TTCN-3 Core LanguageTechnicalpublic05-11-2014 16:1814-12-2015 14:01
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.7.1 (published 2015-06) 
Target Versionv4.8.1 (published 2016-07)Fixed in Versionv4.8.1 (published 2016-07) 
Clause Reference(s)5.4.2
Source (company - Author)L.M.Ericsson
Summary0006813: Passing fields or elements of a component variable as inout parameter
DescriptionCR6731 raised a problem to specify the exact behaviour of inout parameters. During resolving this CR it was realized that passing a structure and also its field as inout parameters would allow making the element-parameter implicitly uninitialized. Therefore, this case has been forbidden by restriction m)of clause 5.4.2.
+
+Note: this implicitly uninitializing probem doesn't exist for mandatory record/set fields, but for the reason of a simpler rule they have also been disallowed.
+
+The principal same problem exists if a field/element of a component variable is passed as inout parameter to a function with a runs on clause referring directly or via compatibility to the component type containing the structured variable definition. However it was considered that this case shall be handled more cautiously, as there is much higher chance to invalidate existing and working test suites then by the above restriction. Therefore it was decided that more time is required to get user feedback and thus no restriction is added to V4.7.1 on this case.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0006731closed Gyorgy Rethy Passing parameters by reference 
Attached Filesdocx CR6813_resolution.docx (179,216) 15-10-2015 17:05
http://oldforge.etsi.org/mantis/file_download.php?file_id=3326&type=bug
docx CR6813_resolution_v2.docx (183,537) 03-11-2015 08:38
http://oldforge.etsi.org/mantis/file_download.php?file_id=3342&type=bug
Issue History
Date ModifiedUsernameFieldChange
05-11-2014 16:18Gyorgy RethyNew Issue
05-11-2014 16:19Gyorgy RethyRelationship addedrelated to 0006731
07-11-2014 13:06Jacob Wieland - SpirentNote Added: 0012494
07-11-2014 13:09Jacob Wieland - SpirentNote Deleted: 0012494
07-11-2014 13:15Jacob Wieland - SpirentNote Added: 0012495
21-04-2015 08:35Jacob Wieland - SpirentNote Added: 0012943
03-08-2015 14:56Gyorgy RethyNote Added: 0013041
03-08-2015 14:57Gyorgy RethyAssigned To => Gyorgy Rethy
03-08-2015 14:57Gyorgy RethyStatusnew => assigned
14-10-2015 12:32Gyorgy RethyNote Added: 0013383
15-10-2015 12:40Jacob Wieland - SpirentAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
15-10-2015 17:05Jacob Wieland - SpirentFile Added: CR6813_resolution.docx
15-10-2015 17:05Jacob Wieland - SpirentNote Added: 0013421
15-10-2015 17:05Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
15-10-2015 17:05Jacob Wieland - SpirentStatusassigned => confirmed
03-11-2015 08:38Gyorgy RethyFile Added: CR6813_resolution_v2.docx
03-11-2015 08:41Gyorgy RethyNote Added: 0013449
03-11-2015 08:41Gyorgy RethyStatusconfirmed => resolved
03-11-2015 08:41Gyorgy RethyFixed in Version => v4.8.1 (published 2016-07)
03-11-2015 08:41Gyorgy RethyResolutionopen => fixed
14-12-2015 14:01Gyorgy RethyNote Added: 0013622
14-12-2015 14:01Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0012495) +
+ Jacob Wieland - Spirent    +
+ 07-11-2014 13:15    +
+ 		+ + + + +
+ For this, at least, I would propose to use the normal pass-by-reference semantics, i.e. if two variables (directly or indirectly) reference the same entity and one such reference is deleted (by the removal of the structure that referenced it), the other variable continues to reference it as long as it exists (i.e. until the function is left).
+
+
+
+ + + + + + + + + + +
+ (0012943) +
+ Jacob Wieland - Spirent    +
+ 21-04-2015 08:35    +
+ 		+ + + + +
+ on further reflection, since the runs-on component is in essence already an inout parameter, passing component variables to a function as inout parameters should only be allowed if the function does not have a runs on clause. Then, only the other inout restrictions need apply.
+
+
+
+ + + + + + + + + + +
+ (0013041) +
+ Gyorgy Rethy    +
+ 03-08-2015 14:56    +
+ 		+ + + + +
+ STF discussion 03-08-2015: prepare an example that discovers tools behavoiur, send to tool vendors and ask them to return the result.
+
+
+
+ + + + + + + + + + +
+ (0013383) +
+ Gyorgy Rethy    +
+ 14-10-2015 12:32    +
+ 		+ + + + +
+ STF discussion: Add a warning note to inout parameterization about the possible side effects and add the example to the standard.
+
+
+
+ + + + + + + + + + +
+ (0013421) +
+ Jacob Wieland - Spirent    +
+ 15-10-2015 17:05    +
+ 		+ + + + +
+ please review and resolve
+
+
+
+ + + + + + + + + + +
+ (0013449) +
+ Gyorgy Rethy    +
+ 03-11-2015 08:41    +
+ 		+ + + + +
+ CR6813_resolution_v2.docx: editorial changes and the new example is emphasised by its own example header.
+
+
+
+ + + + + + + + + + +
+ (0013622) +
+ Gyorgy Rethy    +
+ 14-12-2015 14:01    +
+ 		+ + + + +
+ Added to draft V4.7.4
+
+ + diff --git a/docs/mantis/CR6814.md b/docs/mantis/CR6814.md new file mode 100644 index 0000000000000000000000000000000000000000..a25ebf359f41e0d8301c34b45c08f15c1b684e3d --- /dev/null +++ b/docs/mantis/CR6814.md @@ -0,0 +1,136 @@ + + + + + + + + + + + + + 0006814: Delete TemplateList from BNF - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006814Part 01: TTCN-3 Core LanguageTechnicalpublic06-11-2014 13:1104-01-2015 20:10
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.6.2 (interim 2014) 
Target Versionv4.7.1 (published 2015-06)Fixed in Versionv4.7.1 (published 2015-06) 
Clause Reference(s)Annex B
Source (company - Author)L.M.Ericsson
Summary0006814: Delete TemplateList from BNF
DescriptionIn V4.4.1 when value list matching was extended to contain also tempplates, the valueOrAttribList BNF definition has been changed to TemplateList.
+
+In V4.5.1 the all from construct was instroduced and the new definition ListOfTemplates is used in MatchingSymbol, but the "old" TemplateList definition is not deleted.
+
+Proposed solution:
+- delete TemplateList and in the static semantics note of MatchingSymbol replace "TemplateList" with "ListOfTemplates"
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
06-11-2014 13:11Gyorgy RethyNew Issue
06-11-2014 13:11Gyorgy RethyAssigned To => Tomas Urban
06-11-2014 13:11Gyorgy RethyStatusnew => assigned
06-11-2014 13:12Gyorgy RethyProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
06-11-2014 13:12Gyorgy RethyNote Added: 0012464
06-11-2014 13:12Gyorgy RethyProduct Version => v4.6.2 (interim 2014)
06-11-2014 13:12Gyorgy RethyTarget Version => v4.7.1 (published 2015-06)
06-11-2014 14:11Tomas UrbanNote Added: 0012470
06-11-2014 14:11Tomas UrbanStatusassigned => resolved
06-11-2014 14:11Tomas UrbanFixed in Version => v4.7.1 (published 2015-06)
06-11-2014 14:11Tomas UrbanResolutionopen => fixed
06-11-2014 14:11Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
04-01-2015 20:10Gyorgy RethyNote Added: 0012609
04-01-2015 20:10Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0012464) +
+ Gyorgy Rethy    +
+ 06-11-2014 13:12    +
+ 		+ + + + +
+ Please cross-check
+
+
+
+ + + + + + + + + + +
+ (0012470) +
+ Tomas Urban    +
+ 06-11-2014 14:11    +
+ 		+ + + + +
+ That's absolutely correct. Please implement as proposed.
+
+
+
+ + + + + + + + + + +
+ (0012609) +
+ Gyorgy Rethy    +
+ 04-01-2015 20:10    +
+ 		+ + + + +
+ Added to draft V4.6.3
+
+ + diff --git a/docs/mantis/CR6815.md b/docs/mantis/CR6815.md new file mode 100644 index 0000000000000000000000000000000000000000..cfcc3ed3f40fb5e472c3c622bb957df2613021d6 --- /dev/null +++ b/docs/mantis/CR6815.md @@ -0,0 +1,165 @@ + + + + + + + + + + + + + 0006815: TCI support for dynamic encoding parameter - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006815Part 06: TTCN-3 Control InterfaceTechnicalpublic07-11-2014 08:5826-01-2015 11:37
ReporterTomas Urban 
Assigned ToTomas Urban 
PrioritynormalSeveritymajorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.7.1 (published 2015-06) 
Target Versionv4.7.1 (published 2015-06)Fixed in Versionv4.7.1 (published 2015-06) 
Clause Reference(s)7.3.2
Source (company - Author)STF 478
Summary0006815: TCI support for dynamic encoding parameter
DescriptionTCI should be extended to support the encoding_info parameter in codec functions defined in 0006799.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0006799closed Gyorgy Rethy Part 09: Using XML with TTCN-3 Using the encvalue() function to build parts of a XML message or a XML matching template 
Attached Filesdocx CR6815_v1.docx (53,917) 07-11-2014 09:29
http://oldforge.etsi.org/mantis/file_download.php?file_id=3183&type=bug
docx CR6815_v2.docx (58,276) 17-12-2014 11:41
http://oldforge.etsi.org/mantis/file_download.php?file_id=3204&type=bug
Issue History
Date ModifiedUsernameFieldChange
07-11-2014 08:58Tomas UrbanNew Issue
07-11-2014 08:58Tomas UrbanStatusnew => assigned
07-11-2014 08:58Tomas UrbanAssigned To => Tomas Urban
07-11-2014 08:58Tomas UrbanRelationship addedrelated to 0006799
07-11-2014 09:29Tomas UrbanFile Added: CR6815_v1.docx
07-11-2014 09:30Tomas UrbanNote Added: 0012479
07-11-2014 09:30Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
07-11-2014 09:30Tomas UrbanStatusassigned => confirmed
17-12-2014 11:41Tomas UrbanFile Added: CR6815_v2.docx
17-12-2014 11:41Tomas UrbanAssigned ToGyorgy Rethy => Jens Grabowski
17-12-2014 11:41Tomas UrbanNote Added: 0012560
06-01-2015 10:52Jens GrabowskiNote Added: 0012637
06-01-2015 10:52Jens GrabowskiStatusconfirmed => resolved
06-01-2015 10:52Jens GrabowskiResolutionopen => fixed
06-01-2015 10:52Jens GrabowskiAssigned ToJens Grabowski => Tomas Urban
06-01-2015 12:14Tomas UrbanNote Added: 0012638
06-01-2015 12:14Tomas UrbanStatusresolved => closed
26-01-2015 11:37Gyorgy RethyFixed in Version => v4.7.1 (published 2015-06)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0012479) +
+ Tomas Urban    +
+ 07-11-2014 09:30    +
+ 		+ + + + +
+ Resolution uploaded. Please review.
+
+
+
+ + + + + + + + + + +
+ (0012560) +
+ Tomas Urban    +
+ 17-12-2014 11:41    +
+ 		+ + + + +
+ Second version of the document uploaded (merged with 0006669).
+
+
+
+ + + + + + + + + + +
+ (0012637) +
+ Jens Grabowski    +
+ 06-01-2015 10:52    +
+ 		+ + + + +
+ Ok for me.
+
+
+
+ + + + + + + + + + +
+ (0012638) +
+ Tomas Urban    +
+ 06-01-2015 12:14    +
+ 		+ + + + +
+ Added to the TCI specification draft.
+
+ + diff --git a/docs/mantis/CR6838.md b/docs/mantis/CR6838.md new file mode 100644 index 0000000000000000000000000000000000000000..6c4dcea89248c15a6c3d43bfdf2f1537717ea52b --- /dev/null +++ b/docs/mantis/CR6838.md @@ -0,0 +1,169 @@ + + + + + + + + + + + + + 0006838: Invalid example 4 in the mixed content section - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006838Part 09: Using XML with TTCN-3Technicalpublic08-12-2014 14:5930-12-2014 20:28
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.5.1 (published 2013-04) 
Target Versionv4.6.1 (published 2015-06)Fixed in Versionv4.6.1 (published 2015-06) 
Clause Reference(s)7.6.8, 7.6.4
For STF discussion
Source (company - Author)STF 475
Summary0006838: Invalid example 4 in the mixed content section
DescriptionThe example 4 in the chapter 7.6.8 is invalid, because it omits just one field of the record. From the TTCN-3 point of view, it is fine, but the generated XML document won't pass validation (and maybe some codecs won't allow to encode the message too).
+
+The easier fix is just to correct the example. However, it would be worth of considering to change the rules for conversion of the all content (described in 7.6.4) so that this kind of mistake wouldn't be possible, i.e. it would be possible only to omit all or none of the fields of the record that is a result of conversion of the all content with minOccurs=0.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR6838_resolution_v1.doc (102,400) 23-12-2014 16:09
http://oldforge.etsi.org/mantis/file_download.php?file_id=3206&type=bug
Issue History
Date ModifiedUsernameFieldChange
08-12-2014 14:59Tomas UrbanNew Issue
23-12-2014 16:08Gyorgy RethyNote Added: 0012574
23-12-2014 16:08Gyorgy RethyAssigned To => Tomas Urban
23-12-2014 16:08Gyorgy RethyStatusnew => confirmed
23-12-2014 16:08Gyorgy RethyTarget Version => v4.6.1 (published 2015-06)
23-12-2014 16:09Gyorgy RethyFile Added: CR6838_resolution_v1.doc
29-12-2014 15:02Gyorgy RethyAssigned ToTomas Urban => Axel Rennoch
29-12-2014 15:02Gyorgy RethyStatusconfirmed => assigned
29-12-2014 15:02Gyorgy RethyStatusassigned => confirmed
29-12-2014 15:30Axel RennochNote Added: 0012588
29-12-2014 15:30Axel RennochNote Added: 0012589
29-12-2014 15:30Axel RennochAssigned ToAxel Rennoch => Gyorgy Rethy
29-12-2014 15:30Axel RennochStatusconfirmed => acknowledged
30-12-2014 18:25Gyorgy RethyStatusacknowledged => resolved
30-12-2014 18:25Gyorgy RethyFixed in Version => v4.6.1 (published 2015-06)
30-12-2014 18:25Gyorgy RethyResolutionopen => fixed
30-12-2014 20:28Gyorgy RethyNote Added: 0012594
30-12-2014 20:28Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0012574) +
+ Gyorgy Rethy    +
+ 23-12-2014 16:08    +
+ 		+ + + + +
+ Example is corrected, pls. cross-check in CR6838_resolution_v1.doc.
+
+You are correct, if looking at the TTCN-3 definition only, it is possible to define an XML element, invalid according to the schema. To correct this an alternative "native" mapping to TTCN-3 set could be added, but this would require another CR next year.
+
+
+
+ + + + + + + + + + +
+ (0012588) +
+ Axel Rennoch    +
+ 29-12-2014 15:30    +
+ 		+ + + + +
+ The modified example in the resolution looks good. However next year we may talk about some conventions about naming of identifiers for templates etc. ;-)
+
+
+
+ + + + + + + + + + +
+ (0012589) +
+ Axel Rennoch    +
+ 29-12-2014 15:30    +
+ 		+ + + + +
+ you may set the CR to resolved.
+
+
+
+ + + + + + + + + + +
+ (0012594) +
+ Gyorgy Rethy    +
+ 30-12-2014 20:28    +
+ 		+ + + + +
+ Added to draft V4.5.3
+
+ + diff --git a/docs/mantis/CR6839.md b/docs/mantis/CR6839.md new file mode 100644 index 0000000000000000000000000000000000000000..8d747aba57dcc6eab0289e4a030b6c51ca4b5135 --- /dev/null +++ b/docs/mantis/CR6839.md @@ -0,0 +1,65 @@ + + + + + + + + + + + + + 0006839: Embedded complex types with a name attribute - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006839Part 09: Using XML with TTCN-3Technicalpublic08-12-2014 15:0723-12-2014 16:42
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.5.1 (published 2013-04) 
Target Versionv4.6.1 (published 2015-06)Fixed in Versionv4.6.1 (published 2015-06) 
Clause Reference(s)7.6.8
For STF discussion
Source (company - Author)STF 475
Summary0006839: Embedded complex types with a name attribute
DescriptionExamples 2, 3 and 5 in the chapter 7.6.8 contain complex types embedded inside XSD element definitions. These complex types contain a name attribute, but the name attribute cannot be used in this scope.
+
+Proposal: remove the superfluous name attribute.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
08-12-2014 15:07Tomas UrbanNew Issue
23-12-2014 16:42Gyorgy RethyNote Added: 0012575
23-12-2014 16:42Gyorgy RethyAssigned To => Gyorgy Rethy
23-12-2014 16:42Gyorgy RethyStatusnew => closed
23-12-2014 16:42Gyorgy RethyResolutionopen => fixed
23-12-2014 16:42Gyorgy RethyFixed in Version => v4.6.1 (published 2015-06)
23-12-2014 16:42Gyorgy RethyTarget Version => v4.6.1 (published 2015-06)
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0012575) +
+ Gyorgy Rethy    +
+ 23-12-2014 16:42    +
+ 		+ + + + +
+ Corrected as proposed in master copy V4.5.3.
+
+ + diff --git a/docs/mantis/CR6840.md b/docs/mantis/CR6840.md new file mode 100644 index 0000000000000000000000000000000000000000..88459de14ff1e0a3566db19740f6cbf76ec8690c --- /dev/null +++ b/docs/mantis/CR6840.md @@ -0,0 +1,65 @@ + + + + + + + + + + + + + 0006840: Superfluous word in group referencing rule - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006840Part 09: Using XML with TTCN-3Editorialpublic09-12-2014 09:3112-12-2014 11:38
ReporterTomas Urban 
Assigned To 
PrioritynormalSeveritytrivialReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.5.1 (published 2013-04) 
Target Versionv4.6.1 (published 2015-06)Fixed in Versionv4.6.1 (published 2015-06) 
Clause Reference(s)7.6.3
For STF discussion
Source (company - Author)STF 475
Summary0006840: Superfluous word in group referencing rule
DescriptionIn the following sentence in the section 7.6.3, there's a superfluous word "was":
+
+when group reference is a child of complexType ... if the child elements of the refereced group definition were WAS present in the complexType definition directly;
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
09-12-2014 09:31Tomas UrbanNew Issue
12-12-2014 11:38Gyorgy RethyNote Added: 0012545
12-12-2014 11:38Gyorgy RethyStatusnew => closed
12-12-2014 11:38Gyorgy RethyResolutionopen => fixed
12-12-2014 11:38Gyorgy RethyFixed in Version => v4.6.1 (published 2015-06)
12-12-2014 11:38Gyorgy RethyTarget Version => v4.6.1 (published 2015-06)
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0012545) +
+ Gyorgy Rethy    +
+ 12-12-2014 11:38    +
+ 		+ + + + +
+ Thanks, corrected in master copy V4.5.3
+
+ + diff --git a/docs/mantis/CR6841.md b/docs/mantis/CR6841.md new file mode 100644 index 0000000000000000000000000000000000000000..bb24aa686148d65bf6dff7d514754d1305bff89e --- /dev/null +++ b/docs/mantis/CR6841.md @@ -0,0 +1,135 @@ + + + + + + + + + + + + + 0006841: Contradictory wording in all from restrictions - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006841Part 01: TTCN-3 Core LanguageClarificationpublic11-12-2014 10:4306-01-2015 18:33
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.6.2 (interim 2014) 
Target Versionv4.7.1 (published 2015-06)Fixed in Versionv4.7.1 (published 2015-06) 
Clause Reference(s)B.1.3.3 Permutation, Restrictions
Source (company - Author)L.M.Ericsson
Summary0006841: Contradictory wording in all from restrictions
DescriptionRestrictions b) and d) are worded as:
+b) The template in the all from clause as a whole shall not resolve into a matching mechanism (i.e. its fields may contain any of the matching mechanisms or matching attributes that are allowed by the following restriction).
+c) Individual members of a permutation and elements of the template in the all from clause shall only be expressions, templates, and the AnyElement and AnyElementsOrNone matching mechanisms.
+
+While the overall intention can be guessed, striktly speaking, specific values used in templates are also matching mechanisms (item b). Item c) allows "templates" within all from, but all matching mechanisms are templates, thus this is contradicting to b); I think item c) meant template references, obeying restriction b).
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR6841_resolution_v1.docx (77,405) 11-12-2014 11:06
http://oldforge.etsi.org/mantis/file_download.php?file_id=3194&type=bug
Issue History
Date ModifiedUsernameFieldChange
11-12-2014 10:43Gyorgy RethyNew Issue
11-12-2014 11:06Gyorgy RethyFile Added: CR6841_resolution_v1.docx
11-12-2014 11:07Gyorgy RethyNote Added: 0012539
11-12-2014 11:07Gyorgy RethyAssigned To => Tomas Urban
11-12-2014 11:07Gyorgy RethyStatusnew => confirmed
11-12-2014 11:07Gyorgy RethyProduct Version => v4.6.2 (interim 2014)
11-12-2014 11:07Gyorgy RethyTarget Version => v4.7.1 (published 2015-06)
15-12-2014 09:28Tomas UrbanNote Added: 0012550
15-12-2014 09:28Tomas UrbanStatusconfirmed => resolved
15-12-2014 09:28Tomas UrbanResolutionopen => fixed
15-12-2014 09:28Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
06-01-2015 18:33Gyorgy RethyNote Added: 0012651
06-01-2015 18:33Gyorgy RethyStatusresolved => closed
06-01-2015 18:33Gyorgy RethyFixed in Version => v4.7.1 (published 2015-06)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0012539) +
+ Gyorgy Rethy    +
+ 11-12-2014 11:07    +
+ 		+ + + + +
+ Please review.
+
+
+
+ + + + + + + + + + +
+ (0012550) +
+ Tomas Urban    +
+ 15-12-2014 09:28    +
+ 		+ + + + +
+ The proposed resolution solves the CR and can be added to the next version of the TTCN-3 core language specification.
+
+
+
+ + + + + + + + + + +
+ (0012651) +
+ Gyorgy Rethy    +
+ 06-01-2015 18:33    +
+ 		+ + + + +
+ Added to draft V4.6.3
+
+ + diff --git a/docs/mantis/CR6842.md b/docs/mantis/CR6842.md new file mode 100644 index 0000000000000000000000000000000000000000..f2e51bf488e906db7c52e5528fb44785e885725c --- /dev/null +++ b/docs/mantis/CR6842.md @@ -0,0 +1,97 @@ + + + + + + + + + + + + + 0006842: Rule for anyType shall not be a comment - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006842Part 09: Using XML with TTCN-3Editorialpublic11-12-2014 12:5430-12-2014 20:05
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeveritytrivialReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.5.1 (published 2013-04) 
Target Versionv4.6.1 (published 2015-06)Fixed in Versionv4.6.1 (published 2015-06) 
Clause Reference(s)6.8
For STF discussion
Source (company - Author)STF 475
Summary0006842: Rule for anyType shall not be a comment
DescriptionIn the section 6.8, there's the following sentence: "while anyType is translated into XML content opaque to the codec". This sentence constitutes a rule for handling the XSD anyType and as such, it shall not be a comment in the example, but a part of the section text.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
duplicate of 0006685closed Gyorgy Rethy Splitting rules for xsd:anyType 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
11-12-2014 12:54Tomas UrbanNew Issue
11-12-2014 13:34Gyorgy RethyRelationship addedchild of 0006685
11-12-2014 13:36Gyorgy RethyNote Added: 0012541
11-12-2014 13:36Gyorgy RethyRelationship replacedduplicate of 0006685
11-12-2014 13:36Gyorgy RethyStatusnew => resolved
11-12-2014 13:36Gyorgy RethyFixed in Version => v4.6.1 (published 2015-06)
11-12-2014 13:36Gyorgy RethyResolutionopen => fixed
11-12-2014 13:36Gyorgy RethyAssigned To => Gyorgy Rethy
30-12-2014 20:05Gyorgy RethyNote Added: 0012593
30-12-2014 20:05Gyorgy RethyStatusresolved => closed
30-12-2014 20:05Gyorgy RethyTarget Version => v4.6.1 (published 2015-06)
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0012541) +
+ Gyorgy Rethy    +
+ 11-12-2014 13:36    +
+ 		+ + + + +
+ The commented sentence has been deleted and concrete rule for anyType conversion has been added in CR 6685
+
+
+
+ + + + + + + + + + +
+ (0012593) +
+ Gyorgy Rethy    +
+ 30-12-2014 20:05    +
+ 		+ + + + +
+ CT 6685 added to draft V4.5.3
+
+ + diff --git a/docs/mantis/CR6843.md b/docs/mantis/CR6843.md new file mode 100644 index 0000000000000000000000000000000000000000..02fe0192b91b5a8d23599197bddcece6a28d4524 --- /dev/null +++ b/docs/mantis/CR6843.md @@ -0,0 +1,181 @@ + + + + + + + + + + + + + 0006843: allow select union for anytype - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006843Part 01: TTCN-3 Core LanguageNew Featurepublic12-12-2014 09:3511-12-2015 15:30
ReporterBogdan Stanca-Kaposta 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.8.1 (published 2016-07)Fixed in Versionv4.8.1 (published 2016-07) 
Clause Reference(s)19.3
Source (company - Author)Testing Technologies IST GmbH
Summary0006843: allow select union for anytype
DescriptionThe following construct should be allowed (similar to unions).
+
+The select construct is defined in 19.3: The Select case statement
+
+        var anytype x;
+        select union (x) {
+            case (integer) {
+                log(x.integer);
+            }
+            case (charstring) {
+                log(x.charstring);
+            }
+            else {
+                log("unknown");
+            }
+        }
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR6843_resolution.docx (169,893) 06-08-2015 12:56
http://oldforge.etsi.org/mantis/file_download.php?file_id=3246&type=bug
docx CR6843_resolution_v2.docx (170,978) 06-08-2015 16:27
http://oldforge.etsi.org/mantis/file_download.php?file_id=3248&type=bug
Issue History
Date ModifiedUsernameFieldChange
12-12-2014 09:35Bogdan Stanca-KapostaNew Issue
14-05-2015 10:10Gyorgy RethyTarget Version => v4.8.1 (published 2016-07)
03-08-2015 14:52Gyorgy RethyNote Added: 0013040
03-08-2015 14:52Gyorgy RethyAssigned To => Jacob Wieland - Spirent
03-08-2015 14:52Gyorgy RethyStatusnew => assigned
06-08-2015 12:56Jacob Wieland - SpirentFile Added: CR6843_resolution.docx
06-08-2015 12:56Jacob Wieland - SpirentNote Added: 0013116
06-08-2015 12:56Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Axel Rennoch
06-08-2015 12:56Jacob Wieland - SpirentStatusassigned => confirmed
06-08-2015 16:27Axel RennochFile Added: CR6843_resolution_v2.docx
06-08-2015 16:29Axel RennochNote Added: 0013121
06-08-2015 16:29Axel RennochStatusconfirmed => resolved
06-08-2015 16:29Axel RennochResolutionopen => fixed
06-08-2015 16:29Axel RennochAssigned ToAxel Rennoch => Gyorgy Rethy
04-11-2015 14:02Gyorgy RethyFixed in Version => v4.8.1 (published 2016-07)
11-12-2015 15:30Gyorgy RethyNote Added: 0013602
11-12-2015 15:30Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0013040) +
+ Gyorgy Rethy    +
+ 03-08-2015 14:52    +
+ 		+ + + + +
+ STF discussion 03-08-2015: agreed in principle, prepare a text proposal.
+
+
+
+ + + + + + + + + + +
+ (0013116) +
+ Jacob Wieland - Spirent    +
+ 06-08-2015 12:56    +
+ 		+ + + + +
+ please review
+
+
+
+ + + + + + + + + + +
+ (0013121) +
+ Axel Rennoch    +
+ 06-08-2015 16:29    +
+ 		+ + + + +
+ resolution is correct, v2 just considers some final typos and font changes.
+
+
+
+ + + + + + + + + + +
+ (0013602) +
+ Gyorgy Rethy    +
+ 11-12-2015 15:30    +
+ 		+ + + + +
+ Added to draft V4.7.4
+
+ + diff --git a/docs/mantis/CR6853.md b/docs/mantis/CR6853.md new file mode 100644 index 0000000000000000000000000000000000000000..4dc6ee56ec96492a9e4c74eb445b4b92a3c7fc3f --- /dev/null +++ b/docs/mantis/CR6853.md @@ -0,0 +1,68 @@ + + + + + + + + + + + + + 0006853: duplicate declaration Duration - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006853Part 09: Using XML with TTCN-3Editorialpublic16-12-2014 16:1719-12-2014 12:54
ReporterBogdan Stanca-Kaposta 
Assigned To 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.5.1 (published 2013-04) 
Target Versionv4.6.1 (published 2015-06)Fixed in Versionv4.6.1 (published 2015-06) 
Clause Reference(s)Annex A
For STF discussion
Source (company - Author)STF475
Summary0006853: duplicate declaration Duration
DescriptionThe incomplete declaration XSD.Duration should be removed from page 98 of the 4.5.1 standard, Annex A.
+
+type charstring Duration (pattern ") with { variant "XSD:duration"
+};
+
+The complete declaration for XSD.Duration is already in the next line.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
16-12-2014 16:17Bogdan Stanca-KapostaNew Issue
19-12-2014 12:54Gyorgy RethyNote Added: 0012569
19-12-2014 12:54Gyorgy RethyStatusnew => closed
19-12-2014 12:54Gyorgy RethyResolutionopen => fixed
19-12-2014 12:54Gyorgy RethyFixed in Version => v4.6.1 (published 2015-06)
19-12-2014 12:54Gyorgy RethyTarget Version => v4.6.1 (published 2015-06)
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0012569) +
+ Gyorgy Rethy    +
+ 19-12-2014 12:54    +
+ 		+ + + + +
+ Thanks for the comment, corrected in draft V4.5.3
+
+ + diff --git a/docs/mantis/CR6854.md b/docs/mantis/CR6854.md new file mode 100644 index 0000000000000000000000000000000000000000..6d31d6ac04fe37d2812d37c23e9e69812bea24a2 --- /dev/null +++ b/docs/mantis/CR6854.md @@ -0,0 +1,135 @@ + + + + + + + + + + + + + 0006854: missing semicolon after const declarations - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006854Part 09: Using XML with TTCN-3Editorialpublic16-12-2014 16:2418-12-2014 11:33
ReporterBogdan Stanca-Kaposta 
Assigned To 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.5.1 (published 2013-04) 
Target Versionv4.6.1 (published 2015-06)Fixed in Versionv4.6.1 (published 2015-06) 
Clause Reference(s)Annex A
For STF discussion
Source (company - Author)STF475
Summary0006854: missing semicolon after const declarations
DescriptionA semicolon is missing at the end of the const declaration (page 96, Annex A).
+
+//ETSI ES 201 873-9 V4.5.1 (2013-04)
+//These constants are used in the XSd date/time type definitions
+    const charstring
+    dash := "-",
+    cln := ":",
+    year := "(0(0(0[1-9]|[1-9][0-9])|[1-9][0-9][0-9])|[1-9][0-9][0-9][0-9])", yearExpansion := "(-([1-9][0-9]#(0,))#(,1))#(,1)",
+    month := "(0[1-9]|1[0-2])",
+    dayOfMonth := "(0[1-9]|[12][0-9]|3[01])",
+    hour := "([01][0-9]|2[0-3])",
+    minute := "([0-5][0-9])",
+    second := "([0-5][0-9])",
+    sFraction := "(.[0-9]#(1,))#(,1)",
+    endOfDayExt := "24:00:00(.0#(1,))#(,1)",
+    nums := "[0-9]#(1,)",
+    ZorTimeZoneExt := "(Z|[\+\-]((0[0-9]|1[0-3]):[0-5][0-9]|14:00))#(,1)", durTime := "(T[0-9]#(1,)"&
+    "(H([0-9]#(1,)(M([0-9]#(1,)(S|.[0-9]#(1,)S))#(,1)|.[0-9]#(1,)S|S))#(,1)|"& "M([0-9]#(1,)(S|.[0-9]#(1,)S)|.[0-9]#(1,)M)#(,1)|"&
+    "S|"&
+    ".[0-9]#(1,)S))"
+================ missing semicolon here ================
+//anySimpleType
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
16-12-2014 16:24Bogdan Stanca-KapostaNew Issue
16-12-2014 16:59Bogdan Stanca-KapostaNote Added: 0012557
16-12-2014 17:01Bogdan Stanca-KapostaNote Edited: 0012557bug_revision_view_page.php?bugnote_id=12557#r104
18-12-2014 11:33Gyorgy RethyNote Added: 0012562
18-12-2014 11:33Gyorgy RethyStatusnew => closed
18-12-2014 11:33Gyorgy RethyResolutionopen => fixed
18-12-2014 11:33Gyorgy RethyFixed in Version => v4.6.1 (published 2015-06)
18-12-2014 11:33Gyorgy RethyTarget Version => v4.6.1 (published 2015-06)
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0012557) +
+ Bogdan Stanca-Kaposta    +
+ 16-12-2014 16:59    +
(edited on: 16-12-2014 17:01)
+ 		+ + + + +
+ There are also missing semicolons after each of the following declarations (page 99):
+
+//TTCN-3 type definitions supporting the mapping of W3C XML Schema built-in datatypes
+type utf8string XMLCompatibleString (
+char(0,0,0,9).. char(0,0,0,9), char(0,0,0,10)..char(0,0,0,10), char(0,0,0,13)..char(0,0,0,13),
+char(0,0,0,32)..char(0,0,215,255), char(0,0,224,0)..char(0,0,255,253), char(0,1,0,0)..char(0,16,255,253)
+)
+================ missing semicolon here ================
+type utf8string XMLStringWithNoWhitespace (
+char(0,0,0,33)..char(0,0,215,255), char(0,0,224,0)..char(0,0,255,253), char(0,1,0,0)..char(0,16,255,253)
+)
+================ missing semicolon here ================
+type utf8string XMLStringWithNoCRLFHT (
+char(0,0,0,32)..char(0,0,215,255), char(0,0,224,0)..char(0,0,255,253), char(0,1,0,0)..char(0,16,255,253)
+)
+================ optional semicolon here ================
+
+
+
+
+
+ + + + + + + + + + +
+ (0012562) +
+ Gyorgy Rethy    +
+ 18-12-2014 11:33    +
+ 		+ + + + +
+ Comments are valid, all are corrected in master draft V4.5.3
+
+ + diff --git a/docs/mantis/CR6855.md b/docs/mantis/CR6855.md new file mode 100644 index 0000000000000000000000000000000000000000..671f7f167aed80d0b873ca8be050172a2ef38ad1 --- /dev/null +++ b/docs/mantis/CR6855.md @@ -0,0 +1,69 @@ + + + + + + + + + + + + + 0006855: Outdated note on mixed ports - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006855Part 01: TTCN-3 Core LanguageEditorialpublic17-12-2014 09:2404-01-2015 18:49
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.6.2 (interim 2014) 
Target Versionv4.7.1 (published 2015-06)Fixed in Versionv4.7.1 (published 2015-06) 
Clause Reference(s)22.4
Source (company - Author)L.M.Ericsson
Summary0006855: Outdated note on mixed ports
DescriptionMixed ports have been moved to deprecated features of the language some years ago. Therefore note 2 of clause 22.4:
+"Information related to the message-based input queue of a mixed port can be retrieved easily by using the check operation in combination with a receive any operation, e.g.
+MyPort.check(receive) -> sender Mysender."
+
+is superfluous and outdated.
+
+Proposed solution: remove the note.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
17-12-2014 09:24Gyorgy RethyNew Issue
18-12-2014 11:28Gyorgy RethyAssigned To => Gyorgy Rethy
18-12-2014 11:28Gyorgy RethyStatusnew => resolved
18-12-2014 11:28Gyorgy RethyResolutionopen => fixed
18-12-2014 11:28Gyorgy RethyProduct Version => v4.6.2 (interim 2014)
18-12-2014 11:28Gyorgy RethyFixed in Version => v4.7.1 (published 2015-06)
18-12-2014 11:28Gyorgy RethyTarget Version => v4.7.1 (published 2015-06)
04-01-2015 18:49Gyorgy RethyNote Added: 0012605
04-01-2015 18:49Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0012605) +
+ Gyorgy Rethy    +
+ 04-01-2015 18:49    +
+ 		+ + + + +
+ Added to draft V4.6.3
+
+ + diff --git a/docs/mantis/CR6856.md b/docs/mantis/CR6856.md new file mode 100644 index 0000000000000000000000000000000000000000..50805565d8ff8501aa1b65cbfe9f5dd4af5dc364 --- /dev/null +++ b/docs/mantis/CR6856.md @@ -0,0 +1,63 @@ + + + + + + + + + + + + + 0006856: Replace references to ISO/IEC 10646 with refernces to the 2012 version - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 08: Using IDL with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006856Part 08: Using IDL with TTCN-3Clarificationpublic12-01-2015 10:4212-01-2015 16:04
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.5.1 (published 2013-04) 
Target Versionv4.6.1 (published 2015-06)Fixed in Versionv4.6.1 (published 2015-06) 
Clause Reference(s)2.1
Source (company - Author)L.M.Erirsson
Summary0006856: Replace references to ISO/IEC 10646 with refernces to the 2012 version
DescriptionCheck also clause number refernces in the text.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
12-01-2015 10:42Gyorgy RethyNew Issue
12-01-2015 16:04Gyorgy RethyClause Reference(s)2.1 and all other => 2.1
12-01-2015 16:04Gyorgy RethyNote Added: 0012668
12-01-2015 16:04Gyorgy RethyResolutionopen => fixed
12-01-2015 16:04Gyorgy RethyProduct Version => v4.5.1 (published 2013-04)
12-01-2015 16:04Gyorgy RethyFixed in Version => v4.6.1 (published 2015-06)
12-01-2015 16:04Gyorgy RethyTarget Version => v4.6.1 (published 2015-06)
12-01-2015 16:04Gyorgy RethyStatusnew => closed
12-01-2015 16:04Gyorgy RethyAssigned To => Gyorgy Rethy
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0012668) +
+ Gyorgy Rethy    +
+ 12-01-2015 16:04    +
+ 		+ + + + +
+ Added to draft V4.5.2
+
+ + diff --git a/docs/mantis/CR6857.md b/docs/mantis/CR6857.md new file mode 100644 index 0000000000000000000000000000000000000000..e8d90fd757b284ec5589f2db41b7672eacfc40c6 --- /dev/null +++ b/docs/mantis/CR6857.md @@ -0,0 +1,63 @@ + + + + + + + + + + + + + 0006857: Replace references to ISO 10646 with the 2012 version - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006857Part 09: Using XML with TTCN-3Editorialpublic12-01-2015 10:4612-01-2015 16:35
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.5.1 (published 2013-04) 
Target Versionv4.6.1 (published 2015-06)Fixed in Versionv4.6.1 (published 2015-06) 
Clause Reference(s)2.2 and all other
For STF discussion
Source (company - Author)L.M.Ericsson
Summary0006857: Replace references to ISO 10646 with the 2012 version
DescriptionCheck also clause references in the text.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
12-01-2015 10:46Gyorgy RethyNew Issue
12-01-2015 16:35Gyorgy RethyNote Added: 0012669
12-01-2015 16:35Gyorgy RethyAssigned To => Gyorgy Rethy
12-01-2015 16:35Gyorgy RethyStatusnew => closed
12-01-2015 16:35Gyorgy RethyResolutionopen => fixed
12-01-2015 16:35Gyorgy RethyProduct Version => v4.5.1 (published 2013-04)
12-01-2015 16:35Gyorgy RethyFixed in Version => v4.6.1 (published 2015-06)
12-01-2015 16:35Gyorgy RethyTarget Version => v4.6.1 (published 2015-06)
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0012669) +
+ Gyorgy Rethy    +
+ 12-01-2015 16:35    +
+ 		+ + + + +
+ Added to draft V4.5.4
+
+ + diff --git a/docs/mantis/CR6859.md b/docs/mantis/CR6859.md new file mode 100644 index 0000000000000000000000000000000000000000..3678529a4f0371960bc27b488414582629516fbc --- /dev/null +++ b/docs/mantis/CR6859.md @@ -0,0 +1,97 @@ + + + + + + + + + + + + + 0006859: Remove refrences to GFT - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Advanced Parametrization (ES 202 784)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006859Ext Pack: Advanced Parametrization (ES 202 784)Editorialpublic12-01-2015 10:5704-11-2015 14:15
ReporterGyorgy Rethy 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionno change required 
PlatformOSOS Version
Product Version 
Target Versionv1.6.1 (published 2017-04)Fixed in Versionv1.6.1 (published 2017-04) 
TS versionn/a
Clause Reference(s)2.1 and 4
Source (company - Author)L.M.Ericsson
Summary0006859: Remove refrences to GFT
DescriptionSee title.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
12-01-2015 10:57Gyorgy RethyNew Issue
14-05-2015 14:11Gyorgy RethyTarget Version => v1.6.1 (published 2017-04)
03-08-2015 14:46Gyorgy RethyAssigned To => Jens Grabowski
03-08-2015 14:46Gyorgy RethyStatusnew => assigned
03-08-2015 14:47Gyorgy RethyNote Added: 0013039
04-08-2015 09:24Jens GrabowskiNote Added: 0013044
04-08-2015 09:24Jens GrabowskiStatusassigned => closed
04-08-2015 09:24Jens GrabowskiResolutionopen => fixed
04-11-2015 14:15Gyorgy RethyResolutionfixed => no change required
04-11-2015 14:15Gyorgy RethyFixed in Version => v1.6.1 (published 2017-04)
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0013039) +
+ Gyorgy Rethy    +
+ 03-08-2015 14:47    +
+ 		+ + + + +
+ STF discussion 03-08-2015: cross check in the latest published version, if not, implement it.
+
+
+
+ + + + + + + + + + +
+ (0013044) +
+ Jens Grabowski    +
+ 04-08-2015 09:24    +
+ 		+ + + + +
+ ETSI ES 202 784 V1.5.1 (2015-06) does not include any reference to GFT or TFT.
+
+ + diff --git a/docs/mantis/CR6860.md b/docs/mantis/CR6860.md new file mode 100644 index 0000000000000000000000000000000000000000..de3176902e6174e9c36e0175e3f9239b43de46af --- /dev/null +++ b/docs/mantis/CR6860.md @@ -0,0 +1,63 @@ + + + + + + + + + + + + + 0006860: Remove references to TFT and GFT - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Continuous signal support (ES 202 786)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006860Ext Pack: Continuous signal support (ES 202 786)Editorialpublic12-01-2015 11:0126-01-2015 10:44
ReporterGyorgy Rethy 
Assigned To 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv1.2.1 (published 2014-06) 
Target Versionv1.3.1 (published 2015-06)Fixed in Versionv1.3.1 (published 2015-06) 
Summary0006860: Remove references to TFT and GFT
DescriptionSee title.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
12-01-2015 11:01Gyorgy RethyNew Issue
26-01-2015 10:44Gyorgy RethyNote Added: 0012679
26-01-2015 10:44Gyorgy RethyStatusnew => closed
26-01-2015 10:44Gyorgy RethyResolutionopen => fixed
26-01-2015 10:44Gyorgy RethyProduct Version => v1.2.1 (published 2014-06)
26-01-2015 10:44Gyorgy RethyFixed in Version => v1.3.1 (published 2015-06)
26-01-2015 10:44Gyorgy RethyTarget Version => v1.3.1 (published 2015-06)
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0012679) +
+ Gyorgy Rethy    +
+ 26-01-2015 10:44    +
+ 		+ + + + +
+ Implemented in draft for TB approval.
+
+ + diff --git a/docs/mantis/CR6862.md b/docs/mantis/CR6862.md new file mode 100644 index 0000000000000000000000000000000000000000..1c86474f411d08deb52c27bc020953528a4187c2 --- /dev/null +++ b/docs/mantis/CR6862.md @@ -0,0 +1,63 @@ + + + + + + + + + + + + + 0006862: Remove informal annex "Bibliography" - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006862Part 09: Using XML with TTCN-3Editorialpublic13-01-2015 14:3113-01-2015 14:34
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.5.1 (published 2013-04) 
Target Versionv4.6.1 (published 2015-06)Fixed in Versionv4.6.1 (published 2015-06) 
Clause Reference(s)Annex E
For STF discussion
Source (company - Author)L.M.Ericsson
Summary0006862: Remove informal annex "Bibliography"
DescriptionAcc. to ETI editing rules, informal reefrnces shall be in clause 2.2 Informative references
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
13-01-2015 14:31Gyorgy RethyNew Issue
13-01-2015 14:34Gyorgy RethyNote Added: 0012671
13-01-2015 14:34Gyorgy RethyAssigned To => Gyorgy Rethy
13-01-2015 14:34Gyorgy RethyStatusnew => closed
13-01-2015 14:34Gyorgy RethyResolutionopen => fixed
13-01-2015 14:34Gyorgy RethyProduct Version => v4.5.1 (published 2013-04)
13-01-2015 14:34Gyorgy RethyFixed in Version => v4.6.1 (published 2015-06)
13-01-2015 14:34Gyorgy RethyTarget Version => v4.6.1 (published 2015-06)
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0012671) +
+ Gyorgy Rethy    +
+ 13-01-2015 14:34    +
+ 		+ + + + +
+ Implemented in draft V4.6.4
+
+ + diff --git a/docs/mantis/CR6863.md b/docs/mantis/CR6863.md new file mode 100644 index 0000000000000000000000000000000000000000..f088d02c9880ba8a9074dcbc8d3034788c5e27d7 --- /dev/null +++ b/docs/mantis/CR6863.md @@ -0,0 +1,63 @@ + + + + + + + + + + + + + 0006863: Update Annex C examples - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006863Part 09: Using XML with TTCN-3Editorialpublic13-01-2015 14:4415-01-2015 09:47
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.5.1 (published 2013-04) 
Target Versionv4.6.1 (published 2015-06)Fixed in Versionv4.6.1 (published 2015-06) 
Clause Reference(s)Annec C
For STF discussion
Source (company - Author)L.M.Ericsson
Summary0006863: Update Annex C examples
DescriptionAnnex C examples shall be updated with the changes in the mapping and the naming and namespace conventions used in the rest of the document.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
13-01-2015 14:44Gyorgy RethyNew Issue
15-01-2015 09:47Gyorgy RethyNote Added: 0012674
15-01-2015 09:47Gyorgy RethyAssigned To => Gyorgy Rethy
15-01-2015 09:47Gyorgy RethyStatusnew => closed
15-01-2015 09:47Gyorgy RethyResolutionopen => fixed
15-01-2015 09:47Gyorgy RethyProduct Version => v4.5.1 (published 2013-04)
15-01-2015 09:47Gyorgy RethyFixed in Version => v4.6.1 (published 2015-06)
15-01-2015 09:47Gyorgy RethyTarget Version => v4.6.1 (published 2015-06)
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0012674) +
+ Gyorgy Rethy    +
+ 15-01-2015 09:47    +
+ 		+ + + + +
+ Added to draft V4.6.4
+
+ + diff --git a/docs/mantis/CR6864.md b/docs/mantis/CR6864.md new file mode 100644 index 0000000000000000000000000000000000000000..364f50d94de701053290d24740a0868c2f6fa7e7 --- /dev/null +++ b/docs/mantis/CR6864.md @@ -0,0 +1,240 @@ + + + + + + + + + + + + + 0006864: Index notation applied to omitted or uninitialized strings - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006864Part 01: TTCN-3 Core LanguageClarificationpublic14-01-2015 08:3814-12-2015 11:24
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.7.1 (published 2015-06) 
Target Versionv4.8.1 (published 2016-07)Fixed in Versionv4.8.1 (published 2016-07) 
Clause Reference(s)6.1.1.1
Source (company - Author)Elvior
Summary0006864: Index notation applied to omitted or uninitialized strings
DescriptionThe current specification doesn't contain a formal rule describing what should happen if the index notation is applied to an unitialized or omitted string field. On the RHS, it seems quite obvious - an error shall be generated. On the LHS, there are two options: either produce an error as well or allow index 0 to create a string with length 1 (that would be consistent with expansion of an empty string). I would prefer the first option.
+
+Proposal: add the following restriction to the section 6.1.1.1:
+Referencing an identified element of an uninitialized or omitted string field or value on the right or left hand side of an assignment shall cause an error.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR-6864-150804-V1.docx (59,097) 04-08-2015 14:48
http://oldforge.etsi.org/mantis/file_download.php?file_id=3230&type=bug
docx CR6864_resolution_v2.docx (78,642) 03-11-2015 14:29
http://oldforge.etsi.org/mantis/file_download.php?file_id=3355&type=bug
Issue History
Date ModifiedUsernameFieldChange
14-01-2015 08:38Tomas UrbanNew Issue
14-01-2015 14:10Jacob Wieland - SpirentNote Added: 0012673
14-05-2015 10:09Gyorgy RethyTarget Version => v4.8.1 (published 2016-07)
03-08-2015 14:45Gyorgy RethyNote Added: 0013038
03-08-2015 14:45Gyorgy RethyAssigned To => Jens Grabowski
03-08-2015 14:45Gyorgy RethyStatusnew => assigned
04-08-2015 14:48Jens GrabowskiFile Added: CR-6864-150804-V1.docx
04-08-2015 14:49Jens GrabowskiNote Added: 0013068
04-08-2015 14:50Jens GrabowskiAssigned ToJens Grabowski => Gyorgy Rethy
04-08-2015 14:50Jens GrabowskiStatusassigned => confirmed
03-11-2015 14:06Gyorgy RethyNote Edited: 0013038bug_revision_view_page.php?bugnote_id=13038#r202
03-11-2015 14:29Gyorgy RethyFile Added: CR6864_resolution_v2.docx
03-11-2015 14:36Gyorgy RethyNote Added: 0013472
03-11-2015 14:36Gyorgy RethyAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
03-11-2015 14:36Gyorgy RethyStatusconfirmed => assigned
03-11-2015 14:41Jacob Wieland - SpirentNote Added: 0013474
03-11-2015 14:41Jacob Wieland - SpirentStatusassigned => resolved
03-11-2015 14:41Jacob Wieland - SpirentFixed in Version => v4.8.1 (published 2016-07)
03-11-2015 14:41Jacob Wieland - SpirentResolutionopen => fixed
03-11-2015 14:41Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
14-12-2015 11:24Gyorgy RethyNote Added: 0013610
14-12-2015 11:24Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0012673) +
+ Jacob Wieland - Spirent    +
+ 14-01-2015 14:10    +
+ 		+ + + + +
+ I have no problem with the proposed solution.
+
+
+
+ + + + + + + + + + +
+ (0013038) +
+ Gyorgy Rethy    +
+ 03-08-2015 14:45    +
(edited on: 03-11-2015 14:06)
+ 		+ + + + +
+ STF discussion 03-08-2015: allow creation of the value with length 1 when index is 0; this allows initialized and fill-up a string in loops.
+
+
+
+
+
+ + + + + + + + + + +
+ (0013068) +
+ Jens Grabowski    +
+ 04-08-2015 14:49    +
+ 		+ + + + +
+ Proposal for resoulution uploaded. Assigned for proofreading to György.
+
+
+
+ + + + + + + + + + +
+ (0013472) +
+ Gyorgy Rethy    +
+ 03-11-2015 14:36    +
+ 		+ + + + +
+ CR6864_resolution_v2.docx: Basicaly OK with me; just extended the first rule for the LHS (only single-length elements can be on the LHS), because it did sound to me like a rule for the RHS only (in spite of the bitstring example); added some charstring examples for the extension.
+
+Please review, if agree, it can be put to resolved directly.
+
+
+
+ + + + + + + + + + +
+ (0013474) +
+ Jacob Wieland - Spirent    +
+ 03-11-2015 14:41    +
+ 		+ + + + +
+ ok
+
+
+
+ + + + + + + + + + +
+ (0013610) +
+ Gyorgy Rethy    +
+ 14-12-2015 11:24    +
+ 		+ + + + +
+ Added to draft V4.7.4
+
+ + diff --git a/docs/mantis/CR6867.md b/docs/mantis/CR6867.md new file mode 100644 index 0000000000000000000000000000000000000000..7816b5f45a94fc4c70716e1292a3b9500d500067 --- /dev/null +++ b/docs/mantis/CR6867.md @@ -0,0 +1,349 @@ + + + + + + + + + + + + + 0006867: Handling XSD type aliases - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006867Part 09: Using XML with TTCN-3New Featurepublic15-01-2015 09:5826-07-2017 10:31
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.6.1 (published 2015-06) 
Target Versionv4.7.1 (published 2016-07)Fixed in Versionv4.7.1 (published 2016-07) 
Clause Reference(s)7.5.1, 7.6
For STF discussion
Source (company - Author)L.M.Ericsson
Summary0006867: Handling XSD type aliases
DescriptionXSD allows defining type aliases both by using <restriction> or <extension>, but not adding effective changes or new components to the base type.
+
+It is proposed to add new mapping rules that in this cases in TTCN-3 type aliases shall be generated. This would increase readibility and alignment of the generated TTCN-3 module with the XSD specification.
+
+Note, that this new rule is fully backward compatible.
+
+If accepted, will need also changing NewC1 definition in Annex C Example 3.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0007656closed Gyorgy Rethy Invalid examples on simple content mapping 
Attached Filesdocx CR6867_resolution_v1.docx (111,483) 05-08-2015 16:56
http://oldforge.etsi.org/mantis/file_download.php?file_id=3237&type=bug
docx CR6867_resolution_v2.docx (116,284) 06-08-2015 12:05
http://oldforge.etsi.org/mantis/file_download.php?file_id=3245&type=bug
docx CR6867_resolution_v3.docx (117,764) 15-10-2015 14:42
http://oldforge.etsi.org/mantis/file_download.php?file_id=3325&type=bug
Issue History
Date ModifiedUsernameFieldChange
15-01-2015 09:58Gyorgy RethyNew Issue
14-05-2015 10:07Gyorgy RethyTarget Version => v4.7.1 (published 2016-07)
03-08-2015 14:30Gyorgy RethyNote Added: 0013037
03-08-2015 14:31Gyorgy RethyAssigned To => Gyorgy Rethy
03-08-2015 14:31Gyorgy RethyStatusnew => assigned
05-08-2015 16:56Gyorgy RethyFile Added: CR6867_resolution_v1.docx
05-08-2015 16:57Gyorgy RethyNote Added: 0013091
05-08-2015 16:57Gyorgy RethyAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
05-08-2015 16:57Gyorgy RethyStatusassigned => confirmed
06-08-2015 07:45Jacob Wieland - SpirentNote Added: 0013096
06-08-2015 07:45Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
06-08-2015 07:45Jacob Wieland - SpirentStatusconfirmed => assigned
06-08-2015 09:28Gyorgy RethyNote Added: 0013101
06-08-2015 09:38Jacob Wieland - SpirentNote Added: 0013102
06-08-2015 09:52Gyorgy RethyNote Added: 0013106
06-08-2015 09:52Gyorgy RethyAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
06-08-2015 12:05Jacob Wieland - SpirentFile Added: CR6867_resolution_v2.docx
06-08-2015 12:05Jacob Wieland - SpirentNote Added: 0013115
06-08-2015 12:05Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
06-08-2015 12:05Jacob Wieland - SpirentStatusassigned => confirmed
15-10-2015 14:42Gyorgy RethyFile Added: CR6867_resolution_v3.docx
15-10-2015 14:42Gyorgy RethyNote Added: 0013418
15-10-2015 14:42Gyorgy RethyStatusconfirmed => resolved
15-10-2015 14:42Gyorgy RethyFixed in Version => v4.7.1 (published 2016-07)
15-10-2015 14:42Gyorgy RethyResolutionopen => fixed
04-12-2015 14:54Gyorgy RethyProduct Version => v4.6.1 (published 2015-06)
04-12-2015 14:54Gyorgy RethyNote Added: 0013556
04-12-2015 14:54Gyorgy RethyStatusresolved => closed
26-07-2017 10:31Tomas UrbanRelationship addedrelated to 0007656
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0013037) +
+ Gyorgy Rethy    +
+ 03-08-2015 14:30    +
+ 		+ + + + +
+ STF discussion 03-08-2015: prepare concrete proposal.
+
+
+
+ + + + + + + + + + +
+ (0013091) +
+ Gyorgy Rethy    +
+ 05-08-2015 16:57    +
+ 		+ + + + +
+ Proposed solution is uploaded in CR6867_resolution_v1.docx. Please check.
+
+
+
+ + + + + + + + + + +
+ (0013096) +
+ Jacob Wieland - Spirent    +
+ 06-08-2015 07:45    +
+ 		+ + + + +
+ I think the solution is inconsistent, as the new rules contradict the rule(s) in the containing section 7.6.
+
+"Globally defined XSD complexType-s shall be translated to a TTCN-3 record type."
+
+"Locally defined anonymous complexTypes shall be ignored. In this case the record type generated for the parent element of the complexType (see clause 7.3), shall enframe the fields resulted by mapping the content (the children) of the XSD complexType."
+
+In the case of empty restriction/extension (no matter what kind of content is the base), you always create either global Subtype Definition (without constraints) in case of a global complex type or a local anonymous complex type of a toplevel element or a Type Reference to the Base Type for anonymous complex types inside local elements. Neither of these is a record definition.
+
+I propose to describe the special case of non-extension/restriction in the main section 7.6. Maybe as a general rule that derived complex types with empty restriction/extension are mapped to References of the TTCN-3 element corresponding to their base type.
+
+
+
+ + + + + + + + + + +
+ (0013101) +
+ Gyorgy Rethy    +
+ 06-08-2015 09:28    +
+ 		+ + + + +
+ OK, than I propose a general rule in clause 7.6 identified with some name (like "type synonym mapping case"), referring to this general rule in the subclauses (e.g. in cases other than the type synonym case in clause 7.6) and leave the examples in the subclauses for demonstration purposes.
+
+
+
+ + + + + + + + + + +
+ (0013102) +
+ Jacob Wieland - Spirent    +
+ 06-08-2015 09:38    +
+ 		+ + + + +
+ sounds good to me
+
+
+
+ + + + + + + + + + +
+ (0013106) +
+ Gyorgy Rethy    +
+ 06-08-2015 09:52    +
+ 		+ + + + +
+ Please prepare a new version of the resolution acc. to what has been agreed.
+
+
+
+ + + + + + + + + + +
+ (0013115) +
+ Jacob Wieland - Spirent    +
+ 06-08-2015 12:05    +
+ 		+ + + + +
+ done, please review
+
+
+
+ + + + + + + + + + +
+ (0013418) +
+ Gyorgy Rethy    +
+ 15-10-2015 14:42    +
+ 		+ + + + +
+ Final resolution is in CR6867_resolution_v3.docx. Only editorial changes to ~v2.
+
+
+
+ + + + + + + + + + +
+ (0013556) +
+ Gyorgy Rethy    +
+ 04-12-2015 14:54    +
+ 		+ + + + +
+ Added to draft V4.6.3
+
+ + diff --git a/docs/mantis/CR6868.md b/docs/mantis/CR6868.md new file mode 100644 index 0000000000000000000000000000000000000000..ab1379e60b2955d7a283c93632fd7440be06225b --- /dev/null +++ b/docs/mantis/CR6868.md @@ -0,0 +1,289 @@ + + + + + + + + + + + + + 0006868: XSD.GYear does not allow years greater than 9999 - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006868Part 09: Using XML with TTCN-3Technicalpublic20-01-2015 15:3204-12-2015 14:07
ReporterBogdan Stanca-Kaposta 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.5.1 (published 2013-04) 
Target Versionv4.7.1 (published 2016-07)Fixed in Versionv4.7.1 (published 2016-07) 
Clause Reference(s)Annex A, 6.5.6
For STF discussion
Source (company - Author)STF475
Summary0006868: XSD.GYear does not allow years greater than 9999
DescriptionyearExpansion is too strict and does not allow positive years having more than 4 digits (only negative ones).
+
+Proposed solution is to update the yearExpansion to
+
+const charstring
+...
+        year := "[0-9]#(4)", // or "\d#4"
+        yearExpansion := "-#(,1)([1-9][0-9]#(0,))#(,1)",
+...
+
+
+Please check the lexical mapping fom W3C
+[56] yearFrag ::= '-'? (([1-9] digit digit digit+)) | ('0' digit digit digit))
+
+source: http://www.w3.org/TR/xmlschema11-2/#nt-yrFrag [^]
+
+
+Examples from W3C
+<ex:gYearElement>10739</ex:gYearElement>
+source: http://www.w3.org/2002/ws/databinding/examples/6/09/GYearElement/ [^]
+
Steps To ReproduceTo reproduce please execute the XML Conformance Test Pos_060506_gregorian_year_003
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
20-01-2015 15:32Bogdan Stanca-KapostaNew Issue
21-01-2015 10:14Bogdan Stanca-KapostaNote Added: 0012675
21-01-2015 10:14Bogdan Stanca-KapostaNote Edited: 0012675bug_revision_view_page.php?bugnote_id=12675#r109
21-01-2015 10:14Bogdan Stanca-KapostaNote Edited: 0012675bug_revision_view_page.php?bugnote_id=12675#r110
21-01-2015 10:15Bogdan Stanca-KapostaNote Edited: 0012675bug_revision_view_page.php?bugnote_id=12675#r111
21-01-2015 10:18Jacob Wieland - SpirentDescription Updatedbug_revision_view_page.php?rev_id=113#r113
21-01-2015 10:18Jacob Wieland - SpirentNote Edited: 0012675bug_revision_view_page.php?bugnote_id=12675#r114
14-05-2015 10:08Gyorgy RethyTarget Version => v4.7.1 (published 2016-07)
03-08-2015 14:27Gyorgy RethyAssigned To => Gyorgy Rethy
03-08-2015 14:27Gyorgy RethyStatusnew => assigned
13-10-2015 12:09Gyorgy RethyNote Added: 0013365
13-10-2015 12:10Gyorgy RethyNote Edited: 0013365bug_revision_view_page.php?bugnote_id=13365#r184
13-10-2015 12:13Gyorgy RethyNote Edited: 0013365bug_revision_view_page.php?bugnote_id=13365#r185
13-10-2015 12:13Gyorgy RethyNote Edited: 0013365bug_revision_view_page.php?bugnote_id=13365#r186
13-10-2015 12:14Gyorgy RethyNote Edited: 0013365bug_revision_view_page.php?bugnote_id=13365#r187
13-10-2015 12:15Gyorgy RethyNote Edited: 0013365bug_revision_view_page.php?bugnote_id=13365#r188
13-10-2015 12:16Gyorgy RethyAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
13-10-2015 12:16Gyorgy RethyStatusassigned => confirmed
13-10-2015 15:37Jacob Wieland - SpirentNote Added: 0013375
13-10-2015 15:40Jacob Wieland - SpirentNote Edited: 0013375bug_revision_view_page.php?bugnote_id=13375#r190
13-10-2015 15:47Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
13-10-2015 15:47Jacob Wieland - SpirentStatusconfirmed => assigned
13-10-2015 16:12Gyorgy RethyNote Added: 0013376
13-10-2015 16:13Gyorgy RethyNote Added: 0013377
13-10-2015 16:13Gyorgy RethyStatusassigned => resolved
13-10-2015 16:13Gyorgy RethyFixed in Version => v4.7.1 (published 2016-07)
13-10-2015 16:13Gyorgy RethyResolutionopen => fixed
04-12-2015 14:07Gyorgy RethyNote Added: 0013554
04-12-2015 14:07Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0012675) +
+ Bogdan Stanca-Kaposta    +
+ 21-01-2015 10:14    +
(edited on: 21-01-2015 10:18)
+ 		+ + + + +
+ The root issue has been already fixed by http://forge.etsi.org/mantis/view.php?id=6742 [^]
+
+Nevertheless we could improve the reading of year by replacing it
+
+  year := "[0-9]#(4)", // without any spaces or "\d#4"
+
+
+
+
+
+ + + + + + + + + + +
+ (0013365) +
+ Gyorgy Rethy    +
+ 13-10-2015 12:09    +
(edited on: 13-10-2015 12:15)
+ 		+ + + + +
+ Actually, XSD prohibits the year "0000" in the fixed-length 4-digit year part. The proposed pattern would allow "0000" and TTCN-3 pattern does not allow excluding certain concrete values from the patterns)
+
+But I agree, the year pattern should be changed to increase readibility (and make the fixed length more visible):
+
+  year := "(0#3[1-9])|(0#2[1-9][0-9])|(0[1-9][0-9]#(2))|([1-9][0-9]#(3))"
+NOTE: in the final version #(2) and #(3) will be without brackets, but for some reasons Mantis changes them to 0000002 and 0000003 in comments.
+
+(for easier comparisionthe current pattern is:
+  year := "(0(0(0[1-9]|[1-9][0-9])|[1-9][0-9][0-9])|[1-9][0-9][0-9][0-9])")
+
+Please review!
+
+
+
+
+
+ + + + + + + + + + +
+ (0013375) +
+ Jacob Wieland - Spirent    +
+ 13-10-2015 15:37    +
(edited on: 13-10-2015 15:40)
+ 		+ + + + +
+ Where did you read that the year 0000 is prohibited. That is not apparent from the pattern given in the W3C standard (as copied above:
+
+[56] yearFrag ::= '-'? (([1-9] digit digit digit+)) | ('0' digit digit digit))
+
+)
+
+This clearly allows 0000.
+
+To quote the description in W3C:
+
+yearFrag is a numeral consisting of at least four decimal digits, optionally preceded by a minus sign; leading '0' digits are prohibited *except to bring the digit count up to four*. It represents the ·year· value.
+
+
+
+
+
+ + + + + + + + + + +
+ (0013376) +
+ Gyorgy Rethy    +
+ 13-10-2015 16:12    +
+ 		+ + + + +
+ OK, clarified now. XSD version 1.0 didn't allow '0000', version 1.1 does allow this.
+
+So, there is no problem to go for
+  year := "[0-9]0000004"
+
+For any case I will add a note to clause 6.5.2 Date and time:
+NOTE: Please note that XSD version 1.0 didn't allow the year '0000'. XSD version 1.1 allows this.
+
+
+
+ + + + + + + + + + +
+ (0013377) +
+ Gyorgy Rethy    +
+ 13-10-2015 16:13    +
+ 		+ + + + +
+ See resolution in the last note.
+
+
+
+ + + + + + + + + + +
+ (0013554) +
+ Gyorgy Rethy    +
+ 04-12-2015 14:07    +
+ 		+ + + + +
+ Added to draft version V4.6.3
+
+ + diff --git a/docs/mantis/CR6869.md b/docs/mantis/CR6869.md new file mode 100644 index 0000000000000000000000000000000000000000..78b37e170125e62ad3936cb4e6cfe676212df3ea --- /dev/null +++ b/docs/mantis/CR6869.md @@ -0,0 +1,88 @@ + + + + + + + + + + + + + 0006869: AnyType in XSD module is missing embed_values field - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006869Part 09: Using XML with TTCN-3Technicalpublic21-01-2015 13:0304-11-2015 09:45
ReporterJacob Wieland - Spirent 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionno change required 
PlatformOSOS Version
Product Versionv4.5.1 (published 2013-04) 
Target Versionv4.7.1 (published 2016-07)Fixed in Versionv4.7.1 (published 2016-07) 
Clause Reference(s)6.8
For STF discussion
Source (company - Author)Testing Technologies - Jacob Wieland
Summary0006869: AnyType in XSD module is missing embed_values field
DescriptionAt the moment, it is not possible to model mixed elements with the AnyType type definitoin of the XSD module as it only included attributes and elements but
+not the possibly existing contents between the elements.
+
+Therefore, the AnyType definition should be changed to:
+
+type record AnyType {
+    record length (1 .. infinity) of String attr optional,
+    record length (1 .. infinity) of String embed_values optional,
+    record of String elem_list
+}
+
+Of course, at the moment, since String can contain anything, the elem_list could be used as a workaround to carry also the other content, but this is inconsistent with other mixed element types and should be avoided.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
duplicate of 0006685closed Gyorgy Rethy Splitting rules for xsd:anyType 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
21-01-2015 13:03Jacob Wieland - SpirentNew Issue
21-01-2015 13:03Jacob Wieland - SpirentStatusnew => assigned
21-01-2015 13:03Jacob Wieland - SpirentAssigned To => Gyorgy Rethy
04-11-2015 09:34Gyorgy RethyRelationship addedduplicate of 0006685
04-11-2015 09:44Gyorgy RethyNote Added: 0013482
04-11-2015 09:45Gyorgy RethyNote Edited: 0013482bug_revision_view_page.php?bugnote_id=13482#r204
04-11-2015 09:45Gyorgy RethyStatusassigned => closed
04-11-2015 09:45Gyorgy RethyResolutionopen => no change required
04-11-2015 09:45Gyorgy RethyFixed in Version => v4.7.1 (published 2016-07)
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0013482) +
+ Gyorgy Rethy    +
+ 04-11-2015 09:44    +
(edited on: 04-11-2015 09:45)
+ 		+ + + + +
+ Comment was correct, but as it is related to an earlier version of the standard. The CR was submitted at the time when the new v4.6.1 version was not TB approved yet, but it contained the solution for the problem based on CR 6685. In version v4.6.1 AnyType is changed to:
+type record AnyType {
+    record of XSD.String embed_values optional,
+    record length (1 .. infinity) of XSD.String attr optional,
+    record of XSD.String elem_list
+}
+with {
+    variant "XSD:anyType";
+    variant "embedValues";
+    variant(attr) "anyAttributes";
+    variant(elem_list) "anyElement";
+}
+(having embedValues as the first field gives alignment with mixed content's mapping).
+
+
+
+ + diff --git a/docs/mantis/CR6870.md b/docs/mantis/CR6870.md new file mode 100644 index 0000000000000000000000000000000000000000..1ef5e3acd90eaf0d761d8dd2a05eb40791f873cb --- /dev/null +++ b/docs/mantis/CR6870.md @@ -0,0 +1,65 @@ + + + + + + + + + + + + + 0006870: Delete references to TFT and GFT - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Perf & Real Time Testing (ES 202 782)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006870Ext Pack: Perf & Real Time Testing (ES 202 782)Editorialpublic26-01-2015 10:3226-01-2015 10:33
ReporterGyorgy Rethy 
Assigned To 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv1.2.1 (published 2014-06) 
Target Versionv1.3.1 (published 2015-06)Fixed in Versionv1.3.1 (published 2015-06) 
Clause Reference(s)Foreword, clause 2.2
Source (company - Author)L.M.Ericsson
TS versionn/a
Summary0006870: Delete references to TFT and GFT
DescriptionTFT (ES 201 873-2) has been made historical by ETSI, GFT (ES 201 873-3) is not maintained.
+
+References to them should be deleted.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
26-01-2015 10:32Gyorgy RethyNew Issue
26-01-2015 10:33Gyorgy RethyNote Added: 0012676
26-01-2015 10:33Gyorgy RethyStatusnew => closed
26-01-2015 10:33Gyorgy RethyResolutionopen => fixed
26-01-2015 10:33Gyorgy RethyProduct Version => v1.2.1 (published 2014-06)
26-01-2015 10:33Gyorgy RethyFixed in Version => v1.3.1 (published 2015-06)
26-01-2015 10:33Gyorgy RethyTarget Version => v1.3.1 (published 2015-06)
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0012676) +
+ Gyorgy Rethy    +
+ 26-01-2015 10:33    +
+ 		+ + + + +
+ Implemented in draft for TB approval.
+
+ + diff --git a/docs/mantis/CR6871.md b/docs/mantis/CR6871.md new file mode 100644 index 0000000000000000000000000000000000000000..1b44954a9fe069cea31a0632a146759a34aebd07 --- /dev/null +++ b/docs/mantis/CR6871.md @@ -0,0 +1,65 @@ + + + + + + + + + + + + + 0006871: Delete references to GFT - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Advanced Parametrization (ES 202 784)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006871Ext Pack: Advanced Parametrization (ES 202 784)Editorialpublic26-01-2015 10:3526-01-2015 10:36
ReporterGyorgy Rethy 
Assigned To 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv1.4.1 (published 2014-06) 
Target Versionv1.5.1 (published 2015-06)Fixed in Versionv1.5.1 (published 2015-06) 
TS versionn/a
Clause Reference(s)Foreword, clauses 2.2 and 4
Source (company - Author)L.M.Ericsson
Summary0006871: Delete references to GFT
DescriptionGFT (ES 201 873-3) is not maintained any more.
+ 
+References to it should be deleted
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
26-01-2015 10:35Gyorgy RethyNew Issue
26-01-2015 10:36Gyorgy RethyNote Added: 0012677
26-01-2015 10:36Gyorgy RethyStatusnew => closed
26-01-2015 10:36Gyorgy RethyResolutionopen => fixed
26-01-2015 10:36Gyorgy RethyProduct Version => v1.4.1 (published 2014-06)
26-01-2015 10:36Gyorgy RethyFixed in Version => v1.5.1 (published 2015-06)
26-01-2015 10:36Gyorgy RethyTarget Version => v1.5.1 (published 2015-06)
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0012677) +
+ Gyorgy Rethy    +
+ 26-01-2015 10:36    +
+ 		+ + + + +
+ Implemented in draft for TB approval.
+
+ + diff --git a/docs/mantis/CR6872.md b/docs/mantis/CR6872.md new file mode 100644 index 0000000000000000000000000000000000000000..345ef412c7f5fbc62255a92aa1a96c99490efcdd --- /dev/null +++ b/docs/mantis/CR6872.md @@ -0,0 +1,65 @@ + + + + + + + + + + + + + 0006872: Delete references to GFT - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Behaviour Types (ES 202 785)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006872Ext Pack: Behaviour Types (ES 202 785)Editorialpublic26-01-2015 10:4026-01-2015 10:41
ReporterGyorgy Rethy 
Assigned To 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv1.3.1 (published 2013-05) 
Target Versionv1.4.1 (published 2015-06)Fixed in Versionv1.4.1 (published 2015-06) 
Clause Reference(s)Foreword, clauses 2.2 and 4
Source (company - Author)L.M.Ericsson
Summary0006872: Delete references to GFT
DescriptionGFT (ES 201 873-3) is not maintained any more.
+  
+References to it should be deleted.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
26-01-2015 10:40Gyorgy RethyNew Issue
26-01-2015 10:41Gyorgy RethyNote Added: 0012678
26-01-2015 10:41Gyorgy RethyStatusnew => closed
26-01-2015 10:41Gyorgy RethyResolutionopen => fixed
26-01-2015 10:41Gyorgy RethyProduct Version => v1.3.1 (published 2013-05)
26-01-2015 10:41Gyorgy RethyFixed in Version => v1.4.1 (published 2015-06)
26-01-2015 10:41Gyorgy RethyTarget Version => v1.4.1 (published 2015-06)
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0012678) +
+ Gyorgy Rethy    +
+ 26-01-2015 10:41    +
+ 		+ + + + +
+ Implemented in draft for TB approval.
+
+ + diff --git a/docs/mantis/CR6874.md b/docs/mantis/CR6874.md new file mode 100644 index 0000000000000000000000000000000000000000..c9866697a7ae0b9340fc066b1b42e212fcb6a57d --- /dev/null +++ b/docs/mantis/CR6874.md @@ -0,0 +1,65 @@ + + + + + + + + + + + + + 0006874: Delete references to GFT - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Extended TRI (ES 202 789)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006874Ext Pack: Extended TRI (ES 202 789)Editorialpublic26-01-2015 10:5726-01-2015 10:57
ReporterGyorgy Rethy 
Assigned To 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv1.3.1 (published 2014-06) 
Target Versionv1.4.1 (published 2015-06)Fixed in Versionv1.4.1 (published 2015-06) 
Clause Reference(s)Foreword, clauses 2.2
Source (company - Author)L.M.Ericsson
Summary0006874: Delete references to GFT
DescriptionGFT (ES 201 873-3) is not maintained any more.
+  
+References to it should be deleted.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
26-01-2015 10:57Gyorgy RethyNew Issue
26-01-2015 10:57Gyorgy RethyNote Added: 0012680
26-01-2015 10:57Gyorgy RethyStatusnew => closed
26-01-2015 10:57Gyorgy RethyResolutionopen => fixed
26-01-2015 10:57Gyorgy RethyProduct Version => v1.3.1 (published 2014-06)
26-01-2015 10:57Gyorgy RethyFixed in Version => v1.4.1 (published 2015-06)
26-01-2015 10:57Gyorgy RethyTarget Version => v1.4.1 (published 2015-06)
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0012680) +
+ Gyorgy Rethy    +
+ 26-01-2015 10:57    +
+ 		+ + + + +
+ Implemented in draft for TB approval.
+
+ + diff --git a/docs/mantis/CR6875.md b/docs/mantis/CR6875.md new file mode 100644 index 0000000000000000000000000000000000000000..269ccdb8aa455f6878415505dfe4049904166e4b --- /dev/null +++ b/docs/mantis/CR6875.md @@ -0,0 +1,156 @@ + + + + + + + + + + + + + 0006875: sequence nested in sequence is mapped wrong in EXAMPLE 2 in 7.6.5.4 - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006875Part 09: Using XML with TTCN-3Editorialpublic26-01-2015 17:1015-10-2015 16:10
ReporterJacob Wieland - Spirent 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.6.1 (published 2015-06) 
Target Versionv4.7.1 (published 2016-07)Fixed in Versionv4.7.1 (published 2016-07) 
Clause Reference(s)7.6.5.4
For STF discussion
Source (company - Author)Testing Technologies - Jacob Wieland
Summary0006875: sequence nested in sequence is mapped wrong in EXAMPLE 2 in 7.6.5.4
DescriptionThe example 2 in section 7.6.5.4. is inconsistent with the
+mapping description of section 7.6.6.4 (sequence with nested sequence)
+
+EXAMPLE 2: Multiple sequence-s nested to choice:
+<complexType name="e34b">
+ <choice>
+ <sequence>
+ <sequence>
+ <element name="foo" type="string"/>
+ <element name="bar" type="string"/>
+ </sequence>
+ <element name="ding" type="string"/>
+ <element name="foo" type="string"/>
+ <element name="bar" type="string"/>
+ </sequence>
+ <element name="ding" type="string"/>
+ </choice>
+</complexType>
+// Is translated to:
+type record E34b {
+union {
+ record {
+ record {
+ XSD.String foo,
+ XSD.String bar
+ } sequence,
+ XSD.String ding,
+ XSD.String foo,
+ XSD.String bar
+ } sequence,
+ XSD.String ding
+} choice
+}
+with {
+variant "name as uncapitalized ";
+variant(choice, choice.sequence, choice.sequence.sequence) "untagged"
+}
+
+According to 7.6.6.4, a sequence within a sequence (with minoccurs=maxoccurs=1) shall be flattened to a single record type/field and not mapped to nested record types.
+
+Therefore, the resulting type should be:
+
+type record E34b {
+union {
+ record {
+ XSD.String foo,
+ XSD.String bar,
+ XSD.String ding,
+ XSD.String foo_1,
+ XSD.String bar_1
+ } sequence,
+ XSD.String ding
+} choice
+}
+with {
+variant "name as uncapitalized ";
+variant(choice, choice.sequence) "untagged"
+}
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
26-01-2015 17:10Jacob Wieland - SpirentNew Issue
26-01-2015 17:10Jacob Wieland - SpirentStatusnew => assigned
26-01-2015 17:10Jacob Wieland - SpirentAssigned To => Gyorgy Rethy
15-10-2015 16:10Gyorgy RethyNote Added: 0013420
15-10-2015 16:10Gyorgy RethyStatusassigned => closed
15-10-2015 16:10Gyorgy RethyResolutionopen => fixed
15-10-2015 16:10Gyorgy RethyFixed in Version => v4.7.1 (published 2016-07)
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0013420) +
+ Gyorgy Rethy    +
+ 15-10-2015 16:10    +
+ 		+ + + + +
+ Example should have been corrected already, in the current draft it exactly as requested by the CR:
+
+EXAMPLE 2: Multiple sequence-s nested to choice:
+<xsd:complexType name="e34b">
+    <xsd:choice>
+        <xsd:sequence>
+            <sequence>
+                <xsd:element name="foo" type="xsd:string"/>
+                <xsd:element name="bar" type="xsd:string"/>
+            </xsd:sequence>
+            <xsd:element name="ding" type="xsd:string"/>
+            <xsd:element name="foo" type="xsd:string"/>
+            <xsd:element name="bar" type="xsd:string"/>
+        </xsd:sequence>
+        <xsd:element name="ding" type="xsd:string"/>
+    </xsd:choice>
+</xsd:complexType>
+
+// Is translated to:
+type record E34b {
+    union {
+        record {
+            XSD.String foo,
+            XSD.String bar,
+            XSD.String ding,
+            XSD.String foo_,
+            XSD.String bar_
+        } sequence,
+        XSD.String ding
+    } choice
+}
+with {
+    variant "name as uncapitalized ";
+    variant(foo_) "name as 'foo'";
+    variant(bar_) "name as 'bar'";
+    variant(choice, choice.sequence) "untagged";
+}
+
+ + diff --git a/docs/mantis/CR6934.md b/docs/mantis/CR6934.md new file mode 100644 index 0000000000000000000000000000000000000000..5c06d36ed77476e945ba9f42d9ad46ea28d0ebc2 --- /dev/null +++ b/docs/mantis/CR6934.md @@ -0,0 +1,742 @@ + + + + + + + + + + + + + 0006934: Unnecessary restriction on match operation - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006934Part 01: TTCN-3 Core LanguageClarificationpublic11-03-2015 14:2007-08-2015 13:50
ReporterWolfgang Seka 
Assigned ToGyorgy Rethy 
PriorityhighSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.6.1 (published 2014-06) 
Target Versionv4.8.1 (published 2016-07)Fixed in Versionv4.8.1 (published 2016-07) 
Clause Reference(s)15.9, B.1.2.8
Source (company - Author)MCC160 - Wolfgang
Summary0006934: Unnecessary restriction on match operation
DescriptionBy applying restrictions of B.1.2.8 on match operation a runtime error may be generated by tools when the second parameter of "match" is omit.
Steps To Reproduce
Additional InformationRecently for some compiler an additional runtime check has been introduced causing runtime errors for match operations where never has been any issue before.
+Apart from the general question what these kinds of checks shall be good for, a correction/clarification in the core language seems to be required to prevent tool vendors from introducing this kind of checks.
+
+Clause 15.9 is describing the match operation as such and defines 2 additional restrictions:
+a) first parameter shall not evaluate to a template
+b) parameters shall be fully initialised.
+
+Nevertheless there are further restrictions in B.1.2.8 - now being used as argument to generate a runtime error:
+On one hand the title of B.1.2.8 is "Omitting optional fields" and the description is talking about omitting optional fields only. On the other hand restriction a) somehow includes templates to be omitted as such (this could be interpreted as a hint that this clause is applicable for templates and template variables too).
+Restriction b) says "At the time of matching, it shall be applied to optional fields of record and set templates only" i.e. it does not say anything about templates as such what now is used as argument to raise a runtime error.
+
+
+In the current case the above interpretation results in a runtime error e.g. for
+  function f_MyMatch(integer i, template (omit) integer p_Template) { return match(i, p_Template); }
+when p_Template results in omit.
+
+
+From a user's point of view this interpretation does not provide any benefit and therefore is useless.
+In addition it could be argued whether the interpretation is applicable at all.
+
+
+=> Clarification for 15.9 and/or B.1.2.8 is needed to allow operations like "match(someValue, omit)" (resulting in false).
+
+
+Furthermore there are other cases for potential problems:
+Assuming
+  type record MyRecord_Type { integer a, integer b optional };
+
+  var MyRecord_Type v_MyRecord := { 0, omit };
+
+=>
+
+  match(v_MyRecord.b, 42); // shall not cause an error but result in false
+  match(v_MyRecord.b, omit); // shall not cause an error but result in true
+
+
+
+In general there is the question whether "match" shall cause any runtime error at all (similar changes in the core language have been done e.g. for "ispresent" some years ago):
+In case of any "error" match may simply return false and it is up to tool implementations to provide a user with additional information (if needed) about the mismatch by means of logging.
TagsNo tags attached.
Relationships
related to 0007085closed Gyorgy Rethy Placeholder for the draft of V4.8.1 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
11-03-2015 14:20Wolfgang SekaNew Issue
12-03-2015 10:04Jacob Wieland - SpirentNote Added: 0012832
13-03-2015 12:48Wolfgang SekaNote Added: 0012833
13-03-2015 13:06Jacob Wieland - SpirentNote Added: 0012834
13-05-2015 10:45Gyorgy RethyProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
13-05-2015 10:45Gyorgy RethyProduct Version => v4.6.1 (published 2014-06)
13-05-2015 10:45Gyorgy RethyTarget Version => v4.8.1 (published 2016-07)
03-08-2015 14:19Gyorgy RethyNote Added: 0013036
03-08-2015 14:19Gyorgy RethyAssigned To => Gyorgy Rethy
03-08-2015 14:19Gyorgy RethyStatusnew => assigned
03-08-2015 14:21Gyorgy RethyNote Edited: 0013036bug_revision_view_page.php?bugnote_id=13036#r134
04-08-2015 09:41Gyorgy RethyNote Added: 0013046
04-08-2015 09:47Gyorgy RethyResolutionopen => fixed
04-08-2015 09:50Gyorgy RethyAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
04-08-2015 09:50Gyorgy RethyStatusassigned => confirmed
04-08-2015 10:56Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
04-08-2015 10:56Jacob Wieland - SpirentStatusconfirmed => assigned
04-08-2015 10:57Jacob Wieland - SpirentNote Added: 0013051
04-08-2015 10:59Jacob Wieland - SpirentNote Added: 0013052
04-08-2015 13:34Gyorgy RethyNote Added: 0013058
04-08-2015 13:35Gyorgy RethyNote Edited: 0013058bug_revision_view_page.php?bugnote_id=13058#r143
04-08-2015 13:55Gyorgy RethyNote Added: 0013059
04-08-2015 13:56Gyorgy RethyAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
04-08-2015 13:56Gyorgy RethyStatusassigned => confirmed
04-08-2015 14:07Jacob Wieland - SpirentNote Added: 0013060
04-08-2015 14:07Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
04-08-2015 14:07Jacob Wieland - SpirentStatusconfirmed => assigned
04-08-2015 17:24Gyorgy RethyNote Added: 0013073
04-08-2015 17:24Gyorgy RethyRelationship addedrelated to 0007085
04-08-2015 17:25Gyorgy RethyNote Added: 0013074
04-08-2015 17:26Gyorgy RethyAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
04-08-2015 17:26Gyorgy RethyStatusassigned => confirmed
05-08-2015 10:50Jacob Wieland - SpirentNote Added: 0013082
05-08-2015 10:50Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
05-08-2015 10:50Jacob Wieland - SpirentStatusconfirmed => assigned
06-08-2015 09:48Gyorgy RethyNote Added: 0013105
06-08-2015 09:48Gyorgy RethyAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
06-08-2015 11:23Jacob Wieland - SpirentNote Added: 0013111
06-08-2015 11:25Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
06-08-2015 13:07Jacob Wieland - SpirentNote Edited: 0013111bug_revision_view_page.php?bugnote_id=13111#r147
07-08-2015 10:32Jacob Wieland - SpirentFile Added: es_20187301v040702_e.docx
07-08-2015 10:35Jacob Wieland - SpirentNote Added: 0013132
07-08-2015 10:35Jacob Wieland - SpirentFile Deleted: es_20187301v040702_e.docx
07-08-2015 10:35Jacob Wieland - SpirentFile Added: es_20187301v040702_e.docx
07-08-2015 10:37Jacob Wieland - SpirentNote Added: 0013133
07-08-2015 10:37Jacob Wieland - SpirentStatusassigned => confirmed
07-08-2015 13:37Gyorgy RethyFile Deleted: es_20187301v040702_e.docx
07-08-2015 13:40Gyorgy RethyNote Added: 0013146
07-08-2015 13:40Gyorgy RethyStatusconfirmed => closed
07-08-2015 13:40Gyorgy RethyFixed in Version => v4.8.1 (published 2016-07)
07-08-2015 13:50Gyorgy RethyNote Edited: 0013146bug_revision_view_page.php?bugnote_id=13146#r149
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0012832) +
+ Jacob Wieland - Spirent    +
+ 12-03-2015 10:04    +
+ 		+ + + + +
+ I disagree with the analysis that the standard is ambiguous or unclear:
+
+The sentence "At the time of matching, it shall be applied to optional fields of record and set templates only" is clear (although we interpret this as meaning 'any entity which is allowed to be omit', i.e. also variables/parameters with modifier template(omit)). It is not used to justify the restriction of the definition of templates, just the restriction of the use of the match operation in the same way as implicit match-operations during receive-operations to be language-consistent.
+
+The match operation is definitely "a time of matching".
+
+I agree that, if the restriction is to be upheld, the same restriction should already be mentioned in the match operation restrictions section to be less "distributed" and confusing.
+
+In general, I, too find the restriction totally unnecessary, as using an omit, * or ifpresent template to match a non-optional entity can have no detrimental effect whatsoever (which is why our tool supported this behavior before, even though it has been non-standard-conform for a long time), even though for 'omit' it is basically just a complicated way of writing 'false', but so is 1 == 2 and that is not disallowed either.
+
+However, the conformance test suite introduced this problem by defining a testcase which checked this restriction which is why the runtime check has been introduced.
+
+The above example of function f_MyMatch to make your case is problematic as there does not seem to be any clear reason why not simply the second parameter is defined as template(value) as it is used to match a value parameter which can never be omit anyway. A more useful use case would probably be more convincing.
+
+Your example with the record type basically calls for an enlargement of the semantics of the match operation to also allow omit as the first actual parameter where at the moment only a value is allowed.
+
+
+
+ + + + + + + + + + +
+ (0012833) +
+ Wolfgang Seka    +
+ 13-03-2015 12:48    +
+ 		+ + + + +
+ Regarding ambiguity of the core language:
+I don't care whether it is ambiguous, confusing, inconsistent or just useless - but it shall be corrected/changed.
+
+Regarding the example:
+f_MyMatch is given to illustrate the issue, not to convince anybody. But we have cases where some global variable can be omit (at the very beginning) or has a value and whenever it gets assigned a new value this shall be checked not to be the previous one (I know that this can done differently but that is not the point)
+
+Apart from the above can I interprete your feedback in that way that in general you agree to change/enhance the language to allow the given examples ??
+
+
+
+ + + + + + + + + + +
+ (0012834) +
+ Jacob Wieland - Spirent    +
+ 13-03-2015 13:06    +
+ 		+ + + + +
+ Yes, as I have stated, we interpreted it for years in the way you desire and it was only changed in the current way because of enforcing standard conformity. I think this restriction is unnecessary.
+
+
+
+ + + + + + + + + + +
+ (0013036) +
+ Gyorgy Rethy    +
+ 03-08-2015 14:19    +
(edited on: 03-08-2015 14:21)
+ 		+ + + + +
+ STF discussion 03-08-2015: change restriction b) from "at the time of matching" to "at the time of matching during a receiving operation".
+
+
+
+
+
+ + + + + + + + + + +
+ (0013046) +
+ Gyorgy Rethy    +
+ 04-08-2015 09:41    +
+ 		+ + + + +
+ Proposed resolution is in the draft uploaded to CR 7085 (http://forge.etsi.org/mantis/view.php?id=7085 [^]), es_20187301v040702.docx, please cross-check.
+
+One more restriction c) is added to close 15.9 that by intention is not putting new constraint to using match just saying explicitly what is agreed yesterday (omit and * can be used as template argument to match optional value fields). Please check if the text is unambiguous.
+
+
+
+ + + + + + + + + + +
+ (0013051) +
+ Jacob Wieland - Spirent    +
+ 04-08-2015 10:57    +
+ 		+ + + + +
+ Sorry, the new restriction contradicts exactly what we decided yesterday. The aim of the CR is to NOT have this restriction.
+
+
+
+ + + + + + + + + + +
+ (0013052) +
+ Jacob Wieland - Spirent    +
+ 04-08-2015 10:59    +
+ 		+ + + + +
+ The same restriction also is mentioned for the AnyValueOrNone matching mechanism (at the time of matching).
+
+so, to be consistent, it should also be changed there (the 'at the time of matching' part is written there several times and there are even examples that need to be changed accordingly - same as for Omit)
+
+
+
+ + + + + + + + + + +
+ (0013058) +
+ Gyorgy Rethy    +
+ 04-08-2015 13:34    +
(edited on: 04-08-2015 13:35)
+ 		+ + + + +
+ Jacob, I don't understand your first comment. My understanding is that we agreed yesterday that we allow these:
+match(x.f, omit);//x is record/set, field f is optional
+match(x.f, *);
+[if you support them also for mandatory fields f, that's fine, but this is a TT extension]
+
+but this doesn't make sense:
+match(y, omit);//y is any type, not necessarily record/set
+match(y, *);
+and we haven't agreed to support them
+
+exactly this is what restriction c) says.
+
+
+
+
+
+ + + + + + + + + + +
+ (0013059) +
+ Gyorgy Rethy    +
+ 04-08-2015 13:55    +
+ 		+ + + + +
+ es_20187301v040702_c.docx is uploaded to CR 7085. Please check it. If you don't agree, we will need a technical discussion.
+
+
+
+ + + + + + + + + + +
+ (0013060) +
+ Jacob Wieland - Spirent    +
+ 04-08-2015 14:07    +
+ 		+ + + + +
+ yes, and it is exactly this restriction that the CR addresses. The proposal is to LIFT this restriction, i.e. to ALLOW match(x, <something potentially being initialized to omit>), even in case that x is not a reference to an optional field or non-present template parameter/variable.
+
+If you still do not want to allow this, then the standard does not need to be changed as that is exactly what the standard at the moment (though hidden in that "at the time of matching") already does.
+
+This, though, will not address the concerns of those who issued this CR.
+
+
+
+ + + + + + + + + + +
+ (0013073) +
+ Gyorgy Rethy    +
+ 04-08-2015 17:24    +
+ 		+ + + + +
+ STF discussion 04-08-2015: allow matching any value (i.e. not only optional fields of values) to omit, like match(x,omit)//x is a value of any type;
+this matching will always return false.
+
+
+
+ + + + + + + + + + +
+ (0013074) +
+ Gyorgy Rethy    +
+ 04-08-2015 17:25    +
+ 		+ + + + +
+ See resolution in es_20187301v040702_b.docx in CR 7085. Please review.
+
+
+
+ + + + + + + + + + +
+ (0013082) +
+ Jacob Wieland - Spirent    +
+ 05-08-2015 10:50    +
+ 		+ + + + +
+ Sorry, the sentence
+
+"Matching the value to the omit matching mechanism directly or by a TemplateInstance, which evaluates to omit, shall return false."
+
+seems superfluous to me as that is already subsumed by the preceding sentence.
+
+Also, it should already be described in the semantic description that the first argument may also denote an option field.
+
+Also, to be consistent, what about a template(omit) parameter/variable/template?
+
+
+
+ + + + + + + + + + +
+ (0013105) +
+ Gyorgy Rethy    +
+ 06-08-2015 09:48    +
+ 		+ + + + +
+ "Matching the value to the omit matching ..." this sentence was the point of the whole many-days discussion. You think that e.g. an integer value can match to omit (and is unseccessful) "by default", others in the STF (including me) thinks that this comparision *in general* makes no sense. For this reason at the last discussion we have decided to create an explicit rule for this case to remove any ambiguity (and allow this kind of matching using match()). This sentence is exactly the explicit rule we have agreed to add.
+
+Denote a field: this is obvious, as actual parameters can be fields.
+
+Not only template(omit) can be compared to a (non-field) value, but any template to which the matching omit is assigned when passed to match()"... or by a TemplateInstance, which evaluates to omit..."; passing template(omit) is open to the users and it is a way to prevent possible runtime error - but shall not be mandatory.
+
+
+
+ + + + + + + + + + +
+ (0013111) +
+ Jacob Wieland - Spirent    +
+ 06-08-2015 11:23    +
(edited on: 06-08-2015 13:07)
+ 		+ + + + +
+ If you allow omit explicitly, then, of course, the semantics shall be the same matching semantics for omit as everywhere else (i.e. omit does only match an omitted field). So, of course, this additional sentence is superfluous in the context where omit is allowed also to be applicable to values (by the match operation).
+
+Also, the semantic description for match operation at the moment still talks about a VALUE. As you cannot stop reiterating, an omitted field is not a value, therefore, a field-denotation referencing an optional field is also not a value in general, but can also be omit which would make it inapplicable to the match operation in its current description. Thus, the text needs to be changed to allow values and and optional field references also for the first argument. (If I have understood correctly that you want to allow this).
+
+In your last paragraph in your last note, I think you are still talking about the right (template) argument to match(), while I am talking about the left (formerly value) argument to match().
+
+
+
+
+
+ + + + + + + + + + +
+ (0013132) +
+ Jacob Wieland - Spirent    +
+ 07-08-2015 10:35    +
+ 		+ + + + +
+ further text changes reflecting our current understanding on how the match operation should work. For consistency's sake, I also allowed template(omit) expressions as the expression argument of match as it has the same semantics as an optional value field.
+
+
+
+ + + + + + + + + + +
+ (0013133) +
+ Jacob Wieland - Spirent    +
+ 07-08-2015 10:37    +
+ 		+ + + + +
+ please review text on match operation. if approved, move proposal to CR 7085
+
+
+
+ + + + + + + + + + +
+ (0013146) +
+ Gyorgy Rethy    +
+ 07-08-2015 13:40    +
(edited on: 07-08-2015 13:50)
+ 		+ + + + +
+ Final text agreed in person, which is implemented in interim draft V4.7.3 uploaded to MTS's drafts area (file es_20187301v040702_e.docx of CR 7085).
+
+
+
+ + diff --git a/docs/mantis/CR7041.md b/docs/mantis/CR7041.md new file mode 100644 index 0000000000000000000000000000000000000000..825779bdd63522df954b6fc5cb9cd1f16db7582a --- /dev/null +++ b/docs/mantis/CR7041.md @@ -0,0 +1,134 @@ + + + + + + + + + + + + + 0007041: Typo in the TciCDProvided - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007041Part 06: TTCN-3 Control InterfaceEditorialpublic27-04-2015 08:5606-01-2016 09:14
ReporterBogdan Stanca-Kaposta 
Assigned ToGyorgy Rethy 
PrioritynormalSeveritytrivialReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.7.1 (published 2015-06) 
Target Versionv4.8.1 (published 2016-07)Fixed in Versionv4.8.1 (published 2016-07) 
Clause Reference(s)7.3.2.2.2
Source (company - Author)STF487
Summary0007041: Typo in the TciCDProvided
DescriptionThere is a typo on 7.3.2.2.2 encode: "perfoming"
+
+observed on Final draft ETSI ES 201 873-6 V4.7.1 (2015-03)
+RES/MTS-201873-6 T3ed471
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
27-04-2015 08:56Bogdan Stanca-KapostaNew Issue
12-05-2015 09:48Gyorgy RethyProduct Version => v4.7.1 (published 2015-06)
12-05-2015 09:48Gyorgy RethyTarget Version => v4.8.1 (published 2016-07)
03-08-2015 13:57Gyorgy RethyNote Added: 0013035
03-08-2015 13:57Gyorgy RethyAssigned To => Tomas Urban
03-08-2015 13:57Gyorgy RethyStatusnew => assigned
16-10-2015 08:45Jacob Wieland - SpirentAssigned ToTomas Urban => Gyorgy Rethy
02-11-2015 08:45Gyorgy RethyNote Added: 0013431
02-11-2015 08:45Gyorgy RethyStatusassigned => resolved
02-11-2015 08:45Gyorgy RethyFixed in Version => v4.8.1 (published 2016-07)
02-11-2015 08:45Gyorgy RethyResolutionopen => fixed
06-01-2016 09:14Gyorgy RethyNote Added: 0013663
06-01-2016 09:14Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0013035) +
+ Gyorgy Rethy    +
+ 03-08-2015 13:57    +
+ 		+ + + + +
+ STF discussion 03-08-2015: agreed, implement change.
+
+
+
+ + + + + + + + + + +
+ (0013431) +
+ Gyorgy Rethy    +
+ 02-11-2015 08:45    +
+ 		+ + + + +
+ to be corrected directly in the final draft.
+
+
+
+ + + + + + + + + + +
+ (0013663) +
+ Gyorgy Rethy    +
+ 06-01-2016 09:14    +
+ 		+ + + + +
+ Implemented in draft V4.7.2
+
+ + diff --git a/docs/mantis/CR7053.md b/docs/mantis/CR7053.md new file mode 100644 index 0000000000000000000000000000000000000000..f1542ee2e45e5d212eef106bf58a5e8fd82e4cc3 --- /dev/null +++ b/docs/mantis/CR7053.md @@ -0,0 +1,103 @@ + + + + + + + + + + + + + 0007053: More detailed explanation of a module parameter restriction - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007053Part 01: TTCN-3 Core LanguageClarificationpublic12-05-2015 09:4504-11-2015 14:16
ReporterGyorgy Rethy 
Assigned To 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionwon't fix 
PlatformOSOS Version
Product Versionv4.7.1 (published 2015-06) 
Target Versionv4.8.1 (published 2016-07)Fixed in Versionv4.8.1 (published 2016-07) 
Clause Reference(s)8.2.1
Source (company - Author)L.M.Ericsson
Summary0007053: More detailed explanation of a module parameter restriction
DescriptionCurrent text of restriction b) reads:
+"b) Module parameters shall not be of port type, default type or component type."
+
+Though the idea behind is clear, values for these types are allocated by the test system, users sometimes understand the restriction that modulepars shall not be these types _as a whole_.
+
+It is proposed to extend the text to:
+"b) Module parameters shall not be of port type, default type or component type and shall not embed fields of these types in any dept."
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
12-05-2015 09:45Gyorgy RethyNew Issue
12-05-2015 09:46Gyorgy RethyProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
12-05-2015 09:47Gyorgy RethyProduct Version => v4.7.1 (published 2015-06)
12-05-2015 09:47Gyorgy RethyTarget Version => v4.8.1 (published 2016-07)
12-05-2015 19:37Jacob Wieland - SpirentNote Added: 0012970
13-05-2015 10:43Gyorgy RethyNote Added: 0012972
13-05-2015 10:43Gyorgy RethyStatusnew => closed
13-05-2015 10:43Gyorgy RethyResolutionopen => won't fix
04-11-2015 14:16Gyorgy RethyFixed in Version => v4.8.1 (published 2016-07)
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0012970) +
+ Jacob Wieland - Spirent    +
+ 12-05-2015 19:37    +
+ 		+ + + + +
+ Again, this sounds like the definition of "data type" to me. So, the restriction should just be that their type shall be a data type, I think.
+
+
+
+ + + + + + + + + + +
+ (0012972) +
+ Gyorgy Rethy    +
+ 13-05-2015 10:43    +
+ 		+ + + + +
+ The CR is withdrawn, instead CR 7055 has been submitted.
+
+ + diff --git a/docs/mantis/CR7055.md b/docs/mantis/CR7055.md new file mode 100644 index 0000000000000000000000000000000000000000..543a179c6e22bcbe535a0445ab65fd43d9fc34ba --- /dev/null +++ b/docs/mantis/CR7055.md @@ -0,0 +1,243 @@ + + + + + + + + + + + + + 0007055: Allow component and default types in module parameters - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007055Part 01: TTCN-3 Core LanguageNew Featurepublic13-05-2015 10:4215-12-2015 09:54
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.7.1 (published 2015-06) 
Target Versionv4.8.1 (published 2016-07)Fixed in Versionv4.8.1 (published 2016-07) 
Clause Reference(s)8.2.1
Source (company - Author)L.M.Ericsson
Summary0007055: Allow component and default types in module parameters
DescriptionCurrently the standard disallows port, default and component types in module parameters. Clause 8.2.1 restriction
+"b) Module parameters shall not be of port type, default type or component type."
+
+However, using a field of component type in a type definition also used for a module parameter have a use case:
+The type SimulatedNodes below contains the parameters of the nodes simulated from TTCN-3, including their component references. Of course, actual component reference values are assigned to the simulated nodes "database" at component creation, but other parameters are assigned semi-statically, during runtime configuration of the test system.
+
+Forcing the users to define parallel types - which are not compatible to each other by definition -, one for the simulated nodes "database" and one for the runtime parameters of the nodes (or one per node), would be very user-unfriendly, complicating the code unnecessarily.
+
+    modulepar SimulatedNodes tsp_SimulatedNodes;
+
+    type record SimulatedNode
+    {
+        charstring name,
+        NodeInfo info,
+        IPL4_Sockets sockets
+    }
+
+    type union NodeInfo
+    {
+        ENodeB eNodeB,
+        RNC rnc,
+        DiameterNode diameterNode,
+        SGSN_MME sgsn_mme,
+        SGW sgw,
+        CBC cbc,
+        RADIUS radius
+    }
+
+    type record RNC
+    {
+        Interface iu_ss7,
+        RNC_Mapping_CT mapping_ct,
+        integer sccp_connId,
+        octetstring trafficModeType,
+        octetstring routingContext,
+        RAI rai,
+        OCT2 sac,
+        BIT24 iuSigConnId,
+        integer id
+    }
+
Steps To Reproduce
Additional InformationProposed solution: allow default and component types in module parameters, but their runtime configuration values shall be null.
+In clause 8.2.1 restrictions:
+b) Module parameters shall not be of, and shall not contain at any level of embedding port types.
+...
+f) <new> Module parameters of default or component types shall only be initialized with the special value null.
TagsNo tags attached.
Relationships
Attached Filesdocx CR7055_resolution.docx (169,887) 15-10-2015 14:21
http://oldforge.etsi.org/mantis/file_download.php?file_id=3322&type=bug
docx CR7055_resolution_v2.docx (170,520) 16-10-2015 10:44
http://oldforge.etsi.org/mantis/file_download.php?file_id=3330&type=bug
Issue History
Date ModifiedUsernameFieldChange
13-05-2015 10:42Gyorgy RethyNew Issue
13-05-2015 10:44Gyorgy RethyProduct Version => v4.7.1 (published 2015-06)
13-05-2015 10:44Gyorgy RethyTarget Version => v4.8.1 (published 2016-07)
03-08-2015 13:56Gyorgy RethyNote Added: 0013034
03-08-2015 13:56Gyorgy RethyAssigned To => Gyorgy Rethy
03-08-2015 13:56Gyorgy RethyStatusnew => assigned
15-10-2015 14:20Jacob Wieland - SpirentAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
15-10-2015 14:21Jacob Wieland - SpirentFile Added: CR7055_resolution.docx
15-10-2015 14:21Jacob Wieland - SpirentNote Added: 0013413
15-10-2015 14:21Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Axel Rennoch
15-10-2015 14:21Jacob Wieland - SpirentStatusassigned => confirmed
16-10-2015 10:44Axel RennochFile Added: CR7055_resolution_v2.docx
16-10-2015 10:49Axel RennochNote Added: 0013426
16-10-2015 10:53Axel RennochNote Added: 0013427
16-10-2015 10:53Axel RennochStatusconfirmed => resolved
16-10-2015 10:53Axel RennochFixed in Version => v4.8.1 (published 2016-07)
16-10-2015 10:53Axel RennochResolutionopen => fixed
16-10-2015 10:53Axel RennochAssigned ToAxel Rennoch => Gyorgy Rethy
15-12-2015 09:54Gyorgy RethyNote Added: 0013632
15-12-2015 09:54Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0013034) +
+ Gyorgy Rethy    +
+ 03-08-2015 13:56    +
+ 		+ + + + +
+ STF discussion 03-08-2015: agreed, implement proposed change.
+
+
+
+ + + + + + + + + + +
+ (0013413) +
+ Jacob Wieland - Spirent    +
+ 15-10-2015 14:21    +
+ 		+ + + + +
+ please review and resolve
+
+
+
+ + + + + + + + + + +
+ (0013426) +
+ Axel Rennoch    +
+ 16-10-2015 10:49    +
+ 		+ + + + +
+ Proposd text changes are fine; in resolution v2 there are just some more font changes for the keywords.
+
+
+
+ + + + + + + + + + +
+ (0013427) +
+ Axel Rennoch    +
+ 16-10-2015 10:53    +
+ 		+ + + + +
+ The resolution v2 resolves the CR, please close.
+
+
+
+ + + + + + + + + + +
+ (0013632) +
+ Gyorgy Rethy    +
+ 15-12-2015 09:54    +
+ 		+ + + + +
+ Added to draft V4.7.4
+
+ + diff --git a/docs/mantis/CR7056.md b/docs/mantis/CR7056.md new file mode 100644 index 0000000000000000000000000000000000000000..66df7b857d4f96ac6d57f7adc1a555dd0eca7f3f --- /dev/null +++ b/docs/mantis/CR7056.md @@ -0,0 +1,222 @@ + + + + + + + + + + + + + 0007056: Fields are mixed up in example - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007056Part 09: Using XML with TTCN-3Editorialpublic14-05-2015 10:0504-12-2015 13:05
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.6.1 (published 2015-06) 
Target Versionv4.7.1 (published 2016-07)Fixed in Versionv4.7.1 (published 2016-07) 
Clause Reference(s)7.6.2.2, example 2
For STF discussion
Source (company - Author)L.M.Ericsson
Summary0007056: Fields are mixed up in example
DescriptionThe fields shipDate and orderDate are mixed up in the generated TTCN-3 type.
+Current example:
+<!-- The restricting type is: -->
+<complexType name="RestrictedPurchaseOrderType">
+    <complexContent>
+        <restriction base="ns:PurchaseOrderType">
+            <sequence>
+                <element name="shipTo" type="string"/>
+                <element name="billTo" type="string"/>
+                <element ref="ns:comment" minOccurs="1"/>
+                <element name="items" type="ns:Items"/>
+            </sequence>
+            <attribute name="shipDate" type="date" use="required" />
+            <attribute name="orderDate" type="date" use="prohibited" />
+        </restriction>
+    </complexContent>
+</complexType>
+-----------------------------
+/* restricting type */
+type record RestrictedPurchaseOrderType {
+    XSD.Date orderDate, //note that this field become mandatory
+                                    //note that the field shipDate is not added
+    XSD.String shipTo,
+    XSD.String billTo,
+    Comment comment, //note that this field become mandatory
+    Items items
+}
+with {
+    variant (orderDate) "attribute"
+}
Steps To Reproduce
Additional InformationIt should be:
+<!-- The restricting type is: -->
+<complexType name="RestrictedPurchaseOrderType">
+    <complexContent>
+        <restriction base="ns:PurchaseOrderType">
+            <sequence>
+                <element name="shipTo" type="string"/>
+                <element name="billTo" type="string"/>
+                <element ref="ns:comment" minOccurs="1"/>
+                <element name="items" type="ns:Items"/>
+            </sequence>
+            <attribute name="shipDate" type="date" use="required" />
+            <attribute name="orderDate" type="date" use="prohibited" />
+        </restriction>
+    </complexContent>
+</complexType>
+-----------------------------
+/* restricting type */
+type record RestrictedPurchaseOrderType {
+    XSD.Date shipDate, //note that this field become mandatory
+                                    //note that the field orderDate is not added
+    XSD.String shipTo,
+    XSD.String billTo,
+    Comment comment, //note that this field become mandatory
+    Items items
+}
+with {
+    variant (orderDate) "attribute"
+}
TagsNo tags attached.
Relationships
Attached Filesdocx CR7056_resolution_v1.docx (18,444) 04-08-2015 15:12
http://oldforge.etsi.org/mantis/file_download.php?file_id=3231&type=bug
Issue History
Date ModifiedUsernameFieldChange
14-05-2015 10:05Gyorgy RethyNew Issue
14-05-2015 10:06Gyorgy RethyProduct Version => v4.6.1 (published 2015-06)
14-05-2015 10:06Gyorgy RethyTarget Version => v4.7.1 (published 2016-07)
03-08-2015 13:43Gyorgy RethyNote Added: 0013033
03-08-2015 13:43Gyorgy RethyAssigned To => Axel Rennoch
03-08-2015 13:43Gyorgy RethyStatusnew => assigned
04-08-2015 15:12Axel RennochFile Added: CR7056_resolution_v1.docx
04-08-2015 15:13Axel RennochNote Added: 0013070
04-08-2015 15:14Axel RennochNote Added: 0013071
04-08-2015 15:14Axel RennochAssigned ToAxel Rennoch => Gyorgy Rethy
04-08-2015 15:14Axel RennochStatusassigned => confirmed
05-08-2015 13:13Gyorgy RethyStatusconfirmed => resolved
05-08-2015 13:13Gyorgy RethyFixed in Version => v4.7.1 (published 2016-07)
05-08-2015 13:13Gyorgy RethyResolutionopen => fixed
04-12-2015 13:05Gyorgy RethyNote Added: 0013551
04-12-2015 13:05Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0013033) +
+ Gyorgy Rethy    +
+ 03-08-2015 13:43    +
+ 		+ + + + +
+ STF discussion 03-08-2015: proposed solution to be cross-checked.
+
+
+
+ + + + + + + + + + +
+ (0013070) +
+ Axel Rennoch    +
+ 04-08-2015 15:13    +
+ 		+ + + + +
+ proposed solution is correct and uploaded in document file
+
+
+
+ + + + + + + + + + +
+ (0013071) +
+ Axel Rennoch    +
+ 04-08-2015 15:14    +
+ 		+ + + + +
+ proposed solution has been put into the uploaded file
+
+
+
+ + + + + + + + + + +
+ (0013551) +
+ Gyorgy Rethy    +
+ 04-12-2015 13:05    +
+ 		+ + + + +
+ Added to draft V4.6.3
+
+ + diff --git a/docs/mantis/CR7057.md b/docs/mantis/CR7057.md new file mode 100644 index 0000000000000000000000000000000000000000..d89a041d15ca60bbba01657172948ec71ea86ca0 --- /dev/null +++ b/docs/mantis/CR7057.md @@ -0,0 +1,362 @@ + + + + + + + + + + + + + 0007057: Extend the mapping of XSD any element and anyAttribute element to TTCN-3 anytype - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007057Part 09: Using XML with TTCN-3New Featurepublic18-05-2015 13:4219-12-2016 11:22
ReporterThilo Lauer 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.6.1 (published 2015-06) 
Target Versionv4.8.1 (published 2017-05)Fixed in Versionv4.8.1 (published 2017-05) 
Clause Reference(s)ES 201 873-9, section 7.7; Annex A (normative): TTCN-3 module XSD
For STF discussion
Source (company - Author)     Devoteam - Thilo Lauer
Summary0007057: Extend the mapping of XSD any element and anyAttribute element to TTCN-3 anytype
Description[new for any element:]
+an XSD any element should be mapped to TTCN-3 anytype if the any value matches one of the XSD element types known to the test suite (except XSD.String); otherwise …
+
+[use current mapping to XSD.string as default:]
+the any element should be mapped to XSD.string as defined up to now in section 7.7.1 of ETSI ES 201 873-9
+
+For details see the enclosed Word-document.
+
+
+[new for anyAttribute element:]
+an XSD anyAttribute element should be mapped to TTCN-3 anytype if the anyAttribute value matches one of the XSD attribute types known to the test suite (except XSD.String); otherwise …
+
+[use current mapping to XSD.string as default:]
+the anyAttribute element should be mapped to XSD.string as defined up to now in section 7.7.2 of ETSI ES 201 873-9
+
+The predefinded types XSD.AnyType and XSD.AnySimpleType should be extended accordingly.
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0007126closed Gyorgy Rethy Part 01: TTCN-3 Core Language Semantics of anytype not really usable 
Attached Filesdocx CR_extend XSD any and anyAttribute elements to TTCN-3 anytype.docx (53,091) 18-05-2015 13:42
http://oldforge.etsi.org/mantis/file_download.php?file_id=3210&type=bug
docx CR7057_extend XSD any and anyAttribute elements to TTCN-3 anytype_V2.docx (58,680) 25-06-2015 10:53
http://oldforge.etsi.org/mantis/file_download.php?file_id=3216&type=bug
docx CR7057.docx (713,776) 03-11-2015 11:49
http://oldforge.etsi.org/mantis/file_download.php?file_id=3351&type=bug
docx CR7057_v2.docx (394,922) 15-11-2016 16:23
http://oldforge.etsi.org/mantis/file_download.php?file_id=3525&type=bug
docx CR7057_v3.docx (395,017) 16-11-2016 11:21
http://oldforge.etsi.org/mantis/file_download.php?file_id=3531&type=bug
Issue History
Date ModifiedUsernameFieldChange
18-05-2015 13:42Thilo LauerNew Issue
18-05-2015 13:42Thilo LauerFile Added: CR_extend XSD any and anyAttribute elements to TTCN-3 anytype.docx
01-06-2015 09:58Gyorgy RethyTarget Version => v4.7.1 (published 2016-07)
25-06-2015 10:53Thilo LauerFile Added: CR7057_extend XSD any and anyAttribute elements to TTCN-3 anytype_V2.docx
25-06-2015 10:56Thilo LauerNote Added: 0012985
03-08-2015 13:34Gyorgy RethyNote Added: 0013032
03-08-2015 13:36Gyorgy RethyNote Edited: 0013032bug_revision_view_page.php?bugnote_id=13032#r132
03-08-2015 13:40Gyorgy RethyAssigned To => Gyorgy Rethy
03-08-2015 13:40Gyorgy RethyStatusnew => assigned
02-11-2015 10:11Jacob Wieland - SpirentAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
03-11-2015 11:46Jacob Wieland - SpirentFile Added: CR7057.docx
03-11-2015 11:47Jacob Wieland - SpirentFile Deleted: CR7057.docx
03-11-2015 11:49Jacob Wieland - SpirentFile Added: CR7057.docx
03-11-2015 11:51Jacob Wieland - SpirentNote Added: 0013464
03-11-2015 11:51Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
03-11-2015 11:51Jacob Wieland - SpirentStatusassigned => confirmed
07-01-2016 08:53Gyorgy RethyPriorityhigh => normal
18-07-2016 10:58Jens GrabowskiAssigned ToGyorgy Rethy => Kristóf Szabados
18-07-2016 10:58Jens GrabowskiStatusconfirmed => assigned
18-07-2016 10:58Jens GrabowskiStatusassigned => confirmed
17-08-2016 12:04Jacob Wieland - SpirentTarget Versionv4.7.1 (published 2016-07) => v4.8.1 (published 2017-05)
15-11-2016 16:23Kristóf SzabadosFile Added: CR7057_v2.docx
15-11-2016 16:23Kristóf SzabadosNote Added: 0014253
16-11-2016 09:47Kristóf SzabadosRelationship addedrelated to 0007126
16-11-2016 09:51Kristóf SzabadosNote Added: 0014257
16-11-2016 10:40Kristóf SzabadosAssigned ToKristóf Szabados => Jens Grabowski
16-11-2016 10:40Kristóf SzabadosStatusconfirmed => assigned
16-11-2016 10:40Kristóf SzabadosNote Added: 0014258
16-11-2016 11:21Jens GrabowskiFile Added: CR7057_v3.docx
16-11-2016 11:22Jens GrabowskiNote Added: 0014262
16-11-2016 11:23Jens GrabowskiNote Added: 0014263
16-11-2016 11:23Jens GrabowskiStatusassigned => resolved
16-11-2016 11:23Jens GrabowskiResolutionopen => fixed
16-11-2016 11:23Jens GrabowskiAssigned ToJens Grabowski => Gyorgy Rethy
19-12-2016 11:22Gyorgy RethyNote Added: 0014459
19-12-2016 11:22Gyorgy RethyStatusresolved => closed
19-12-2016 11:22Gyorgy RethyFixed in Version => v4.8.1 (published 2017-05)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0012985) +
+ Thilo Lauer    +
+ 25-06-2015 10:56    +
+ 		+ + + + +
+ Additional Clarification, added 25.6.2015:
+"XSD elements with no assigned type"
+shall be mapped to XSD.anyType and as a consequence of this CR7057
+to TTCN-3 anytype (defaulting to XSD.string)
+I have added a clarification for this related issue to version 2 of my uploaded word document.
+
+
+
+ + + + + + + + + + +
+ (0013032) +
+ Gyorgy Rethy    +
+ 03-08-2015 13:34    +
(edited on: 03-08-2015 13:36)
+ 		+ + + + +
+ STF discussion 03-08-2015: check if the change could be solved in a (at least partially) backward compatible way. Also, anytype contains only types from tjhe given module, how to decode AnyElement to any type from any module?
+Jacob to submit another CR to discuss extension of the definition of TTCN-3 anytype.
+
+
+
+
+
+ + + + + + + + + + +
+ (0013464) +
+ Jacob Wieland - Spirent    +
+ 03-11-2015 11:51    +
+ 		+ + + + +
+ added alternative mapping possibility for anyType, anySimpleType, any and anyAttribute (according to request).
+
+Left old way of mapping for backward compatibility. Otherwise, we could just deprecate the old mapping.
+
+please review
+
+
+
+ + + + + + + + + + +
+ (0014253) +
+ Kristóf Szabados    +
+ 15-11-2016 16:23    +
+ 		+ + + + +
+ corrected a word duplication and a missing import in the text
+
+
+
+ + + + + + + + + + +
+ (0014257) +
+ Kristóf Szabados    +
+ 16-11-2016 09:51    +
+ 		+ + + + +
+ The definition on the TTCN-3 anytype was extended in CR7126
+
+
+
+ + + + + + + + + + +
+ (0014258) +
+ Kristóf Szabados    +
+ 16-11-2016 10:40    +
+ 		+ + + + +
+ looks fine by me
+
+
+
+ + + + + + + + + + +
+ (0014262) +
+ Jens Grabowski    +
+ 16-11-2016 11:22    +
+ 		+ + + + +
+ Removed a few typos. Text ok. Set to resolved and assigned to György.
+
+
+
+ + + + + + + + + + +
+ (0014263) +
+ Jens Grabowski    +
+ 16-11-2016 11:23    +
+ 		+ + + + +
+ For implementation.
+
+
+
+ + + + + + + + + + +
+ (0014459) +
+ Gyorgy Rethy    +
+ 19-12-2016 11:22    +
+ 		+ + + + +
+ Added to draft V4.7.2
+
+ + diff --git a/docs/mantis/CR7059.md b/docs/mantis/CR7059.md new file mode 100644 index 0000000000000000000000000000000000000000..e96df7fe0e01b5d43c37092bde77f07d49039ddc --- /dev/null +++ b/docs/mantis/CR7059.md @@ -0,0 +1,276 @@ + + + + + + + + + + + + + 0007059: constraints of TTCN-3 types unavailable at TCI level - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007059Part 06: TTCN-3 Control InterfaceNew Featurepublic26-05-2015 10:1406-01-2016 09:21
ReporterJacob Wieland - Spirent 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.8.1 (published 2016-07)Fixed in Versionv4.8.1 (published 2016-07) 
Clause Reference(s)7.2
Source (company - Author)Testing Technologies - Jacob Wieland
Summary0007059: constraints of TTCN-3 types unavailable at TCI level
DescriptionIf types are defined in TTCN-3 with length restrictions, boundaries or other constraints, it could be interestring to be able to query these constraints
+from either the type or at least from an instance of the type, using the same interfaces as for template exploration.
+
+Up till now there have been requests for querying the boundaries of range-constrained number-types and the length-restrictions of length-restricted types.
+
+Thus, we propose at least the following new TCI-functions:
+
+RangeBoundary getUpperTypeBoundary();
+RangeBoundary getLowerTypeBoundary();
+LengthRestriction getTypeLengthRestriction();
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx es_20187306v040701p_CR7059.docx (1,512,377) 06-08-2015 11:27
http://oldforge.etsi.org/mantis/file_download.php?file_id=3243&type=bug
docx es_20187306v040701p_CR7059_v2.docx (1,515,898) 07-08-2015 09:05
http://oldforge.etsi.org/mantis/file_download.php?file_id=3250&type=bug
docx es_20187306v040701p_CR7059_v3.docx (1,516,727) 07-08-2015 12:21
http://oldforge.etsi.org/mantis/file_download.php?file_id=3256&type=bug
Issue History
Date ModifiedUsernameFieldChange
26-05-2015 10:14Jacob Wieland - SpirentNew Issue
03-08-2015 13:17Gyorgy RethyNote Added: 0013031
03-08-2015 13:17Gyorgy RethyAssigned To => Jacob Wieland - Spirent
03-08-2015 13:17Gyorgy RethyStatusnew => assigned
05-08-2015 15:17Jacob Wieland - SpirentStatusassigned => acknowledged
06-08-2015 11:27Jacob Wieland - SpirentFile Added: es_20187306v040701p_CR7059.docx
06-08-2015 11:29Jacob Wieland - SpirentNote Added: 0013112
06-08-2015 11:29Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Axel Rennoch
06-08-2015 11:29Jacob Wieland - SpirentStatusacknowledged => confirmed
07-08-2015 09:05Axel RennochFile Added: es_20187306v040701p_CR7059_v2.docx
07-08-2015 09:06Axel RennochNote Added: 0013124
07-08-2015 09:08Axel RennochNote Added: 0013125
07-08-2015 09:08Axel RennochAssigned ToAxel Rennoch => Jacob Wieland - Spirent
07-08-2015 09:08Axel RennochStatusconfirmed => acknowledged
07-08-2015 09:34Jacob Wieland - SpirentNote Added: 0013127
07-08-2015 12:21Jacob Wieland - SpirentFile Added: es_20187306v040701p_CR7059_v3.docx
07-08-2015 12:22Jacob Wieland - SpirentNote Added: 0013140
07-08-2015 12:22Jacob Wieland - SpirentStatusacknowledged => resolved
07-08-2015 12:22Jacob Wieland - SpirentFixed in Version => v4.8.1 (published 2016-07)
07-08-2015 12:22Jacob Wieland - SpirentResolutionopen => fixed
16-10-2015 13:24Jacob Wieland - SpirentStatusresolved => feedback
16-10-2015 13:24Jacob Wieland - SpirentResolutionfixed => reopened
16-10-2015 13:24Jacob Wieland - SpirentStatusfeedback => resolved
16-10-2015 13:24Jacob Wieland - SpirentResolutionreopened => fixed
16-10-2015 13:24Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
06-01-2016 09:21Gyorgy RethyNote Added: 0013664
06-01-2016 09:21Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0013031) +
+ Gyorgy Rethy    +
+ 03-08-2015 13:17    +
+ 		+ + + + +
+ STF discussion 03-08-2015: agreed, prepare text proposal.
+
+
+
+ + + + + + + + + + +
+ (0013112) +
+ Jacob Wieland - Spirent    +
+ 06-08-2015 11:29    +
+ 		+ + + + +
+ since the changes are distributed over the whole text, I have uploaded a full version of the TCI standard. Please review, the changes are always in the Value sections for each language mapping.
+
+
+
+ + + + + + + + + + +
+ (0013124) +
+ Axel Rennoch    +
+ 07-08-2015 09:06    +
+ 		+ + + + +
+ v2 contains some corrections related to LengthRestriction
+
+
+
+ + + + + + + + + + +
+ (0013125) +
+ Axel Rennoch    +
+ 07-08-2015 09:08    +
+ 		+ + + + +
+ please consider to rename getTypeRestriction to getMatchingMechanism
+
+
+
+ + + + + + + + + + +
+ (0013127) +
+ Jacob Wieland - Spirent    +
+ 07-08-2015 09:34    +
+ 		+ + + + +
+ I would consider getTypeMatchingMechanism.
+
+
+
+ + + + + + + + + + +
+ (0013140) +
+ Jacob Wieland - Spirent    +
+ 07-08-2015 12:22    +
+ 		+ + + + +
+ changed getTypeRestriction to getTypeMatchingMechanism and uploaded changes in v3
+
+
+
+ + + + + + + + + + +
+ (0013664) +
+ Gyorgy Rethy    +
+ 06-01-2016 09:21    +
+ 		+ + + + +
+ Implemented in draft V4.7.2
+
+ + diff --git a/docs/mantis/CR7080.md b/docs/mantis/CR7080.md new file mode 100644 index 0000000000000000000000000000000000000000..4f214061f4674a3129ee79e6b9f78ff3ffb83d11 --- /dev/null +++ b/docs/mantis/CR7080.md @@ -0,0 +1,144 @@ + + + + + + + + + + + + + 0007080: Few errors in examples - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007080Part 09: Using XML with TTCN-3Editorialpublic12-06-2015 14:3207-08-2015 10:57
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.6.1 (published 2015-06) 
Target Versionv4.7.1 (published 2016-07)Fixed in Versionv4.7.1 (published 2016-07) 
Clause Reference(s)See Description section
For STF discussion
Source (company - Author)L.M.Ericsson
Summary0007080: Few errors in examples
DescriptionIn clause 5.1.4, the closing "/>" of the element "elem" within Ctype2 is missing
+--------------------------------------------------------------
+In clause 6.1.5, Example2, the
+        variant "name as uncapitalized";
+should be
+        variant "name as 'integer-0-5-10'";
+--------------------------------------------------------------
+In clause 7.5.1, Example, the "/" is superflouos at the opening tag of restriction and the end tag to be shifted by one more tabulator character.
+--------------------------------------------------------------
+In clause 7.5.3, Example4, the attribute name of the enumeration element shall be 'value' instead of 'name'.
+--------------------------------------------------------------
+In clause 7.6.3, Example4, first TTCN-3 type's name should be 'SeqGroupAndElementsInSequence'
+--------------------------------------------------------------
+In clause 7.7.2, Example, element definition e45d, the namespace prefix of the extension base should be 'this'
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
12-06-2015 14:32Gyorgy RethyNew Issue
12-06-2015 14:32Gyorgy RethyStatusnew => assigned
12-06-2015 14:32Gyorgy RethyAssigned To => Gyorgy Rethy
16-06-2015 11:11Gyorgy RethyNote Added: 0012982
22-07-2015 15:09Gyorgy RethyNote Added: 0013002
22-07-2015 15:09Gyorgy RethyStatusassigned => confirmed
07-08-2015 10:57Gyorgy RethyNote Added: 0013135
07-08-2015 10:57Gyorgy RethyStatusconfirmed => closed
07-08-2015 10:57Gyorgy RethyResolutionopen => fixed
07-08-2015 10:57Gyorgy RethyFixed in Version => v4.7.1 (published 2016-07)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0012982) +
+ Gyorgy Rethy    +
+ 16-06-2015 11:11    +
+ 		+ + + + +
+ Corrected in draft V4.6.2
+
+
+
+ + + + + + + + + + +
+ (0013002) +
+ Gyorgy Rethy    +
+ 22-07-2015 15:09    +
+ 		+ + + + +
+ See corrections in CR 7084, draft es_20187309v040603.docx
+
+
+
+ + + + + + + + + + +
+ (0013135) +
+ Gyorgy Rethy    +
+ 07-08-2015 10:57    +
+ 		+ + + + +
+ Implemented in interim draft V4.6.2 (file es_20187309v040603_v4.docx in CR7084)
+
+ + diff --git a/docs/mantis/CR7081.md b/docs/mantis/CR7081.md new file mode 100644 index 0000000000000000000000000000000000000000..ab32199426397ee1185d6187ce372e0e0acf4e7f --- /dev/null +++ b/docs/mantis/CR7081.md @@ -0,0 +1,173 @@ + + + + + + + + + + + + + 0007081: Allow EOF to close line comemnts - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007081Part 01: TTCN-3 Core LanguageNew Featurepublic15-06-2015 13:4707-08-2015 13:51
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.7.1 (published 2015-06) 
Target Versionv4.8.1 (published 2016-07)Fixed in Versionv4.8.1 (published 2016-07) 
Clause Reference(s)A.1.4 3rd paragraph
Source (company - Author)L.M.Ericsson
Summary0007081: Allow EOF to close line comemnts
DescriptionToday <newline> character(s) is required to close line comments. This rule forces a line break and a superfluous empty line after line comments following the closing brakets of a module.
+
+Proposed solution:
+Change:
+"Line comments shall be ... and closed by a <newline>."
+to
+Line comments shall be ... and closed by a <newline> or <end-of-file>.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
15-06-2015 13:47Gyorgy RethyNew Issue
03-08-2015 13:13Gyorgy RethyAssigned To => Gyorgy Rethy
03-08-2015 13:13Gyorgy RethyStatusnew => assigned
03-08-2015 13:13Gyorgy RethyNote Added: 0013030
04-08-2015 09:54Gyorgy RethyStatusassigned => resolved
04-08-2015 09:54Gyorgy RethyResolutionopen => fixed
04-08-2015 09:54Gyorgy RethyNote Added: 0013049
04-08-2015 09:56Gyorgy RethyStatusresolved => closed
04-08-2015 09:56Gyorgy RethyProduct Version => v4.7.1 (published 2015-06)
04-08-2015 09:56Gyorgy RethyFixed in Version => v4.8.1 (published 2016-07)
04-08-2015 09:56Gyorgy RethyTarget Version => v4.8.1 (published 2016-07)
07-08-2015 13:39Gyorgy RethyNote Added: 0013145
07-08-2015 13:41Gyorgy RethyNote Added: 0013148
07-08-2015 13:51Gyorgy RethyNote Edited: 0013148bug_revision_view_page.php?bugnote_id=13148#r151
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0013030) +
+ Gyorgy Rethy    +
+ 03-08-2015 13:13    +
+ 		+ + + + +
+ STF discussion 03-08-2015: agreed, make the change in the draft.
+
+
+
+ + + + + + + + + + +
+ (0013049) +
+ Gyorgy Rethy    +
+ 04-08-2015 09:54    +
+ 		+ + + + +
+ Added to draft V4.7.2
+
+
+
+ + + + + + + + + + +
+ (0013145) +
+ Gyorgy Rethy    +
+ 07-08-2015 13:39    +
+ 		+ + + + +
+ Implemented in interim draft V4.7.2 uploaded to MTS's drafts area (file es_20187301v040702_e.docx of CR 7085).
+
+
+
+ + + + + + + + + + +
+ (0013148) +
+ Gyorgy Rethy    +
+ 07-08-2015 13:41    +
(edited on: 07-08-2015 13:51)
+ 		+ + + + +
+ Implemented in interim draft V4.7.3 uploaded to MTS's drafts area (file es_20187301v040702_e.docx of CR 7085).
+
+
+
+ + diff --git a/docs/mantis/CR7082.md b/docs/mantis/CR7082.md new file mode 100644 index 0000000000000000000000000000000000000000..67235f46820b33dd22acabc40b9265aa3ca6d89e --- /dev/null +++ b/docs/mantis/CR7082.md @@ -0,0 +1,134 @@ + + + + + + + + + + + + + 0007082: Further errors in examples - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007082Part 09: Using XML with TTCN-3Editorialpublic16-06-2015 10:5507-08-2015 10:58
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.6.1 (published 2015-06) 
Target Versionv4.7.1 (published 2016-07)Fixed in Versionv4.7.1 (published 2016-07) 
Clause Reference(s)7.6.3
For STF discussion
Source (company - Author)L.M.Ericsson
Summary0007082: Further errors in examples
DescriptionIn clause 7.6.3, Example3:
+- name of the TTCN-3 type related to the XSD complexType LonelyChoGroupOptional, should also be LonelyChoGroupOptional.
+- name of the TTCN-3 type related to the XSD complexType LonelyChoGroupRecurrence, should also be LonelyChoGroupRecurrence and the TTCN-3 comment related to the annotation should be added to the TTCN-3 definition.
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
16-06-2015 10:55Gyorgy RethyNew Issue
16-06-2015 10:55Gyorgy RethyStatusnew => assigned
16-06-2015 10:55Gyorgy RethyAssigned To => Gyorgy Rethy
16-06-2015 11:12Gyorgy RethyNote Added: 0012983
22-07-2015 15:08Gyorgy RethyNote Added: 0013001
22-07-2015 15:08Gyorgy RethyStatusassigned => confirmed
07-08-2015 10:58Gyorgy RethyNote Added: 0013136
07-08-2015 10:58Gyorgy RethyStatusconfirmed => closed
07-08-2015 10:58Gyorgy RethyResolutionopen => fixed
07-08-2015 10:58Gyorgy RethyFixed in Version => v4.7.1 (published 2016-07)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0012983) +
+ Gyorgy Rethy    +
+ 16-06-2015 11:12    +
+ 		+ + + + +
+ Corrected in draft V4.6.2
+
+
+
+ + + + + + + + + + +
+ (0013001) +
+ Gyorgy Rethy    +
+ 22-07-2015 15:08    +
+ 		+ + + + +
+ See corrections in CR 7084, draft es_20187309v040603.docx
+
+
+
+ + + + + + + + + + +
+ (0013136) +
+ Gyorgy Rethy    +
+ 07-08-2015 10:58    +
+ 		+ + + + +
+ Implemented in interim draft V4.6.2 (file es_20187309v040603_v4.docx in CR7084)
+
+ + diff --git a/docs/mantis/CR7083.md b/docs/mantis/CR7083.md new file mode 100644 index 0000000000000000000000000000000000000000..1743bed385af039e0373171587e967678751f551 --- /dev/null +++ b/docs/mantis/CR7083.md @@ -0,0 +1,110 @@ + + + + + + + + + + + + + 0007083: Misleading XSD and TTCN-3 comments - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007083Part 09: Using XML with TTCN-3Editorialpublic16-06-2015 10:5904-01-2016 15:41
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.6.1 (published 2015-06) 
Target Versionv4.7.1 (published 2016-07)Fixed in Versionv4.7.1 (published 2016-07) 
Clause Reference(s)all
For STF discussion
Source (company - Author)L.M.Ericsson
Summary0007083: Misleading XSD and TTCN-3 comments
DescriptionIn the examples "helper" texts are present as XSD and TTCN-3 comments, like:
+<!-- Referencing a group with compositor <choice> (see group declaration in $7.9) -->
+<xsd:complexType name="LonelyChoGroup">
+...
+
+//Is translated to TTCN-3 as:
+type record LonelyChoGroup {
+...
+
+This is misleading as XSD comments shall be translated to TTCN-3 comemnts as well.
+
+Proposed solution: use a specific font type for "helper" text and remove XSD and TTCN-3 comment symbols.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
16-06-2015 10:59Gyorgy RethyNew Issue
16-06-2015 11:11Gyorgy RethyAssigned To => Gyorgy Rethy
16-06-2015 11:11Gyorgy RethyStatusnew => assigned
03-08-2015 13:08Gyorgy RethyNote Added: 0013029
05-08-2015 13:22Gyorgy RethyNote Edited: 0013029bug_revision_view_page.php?bugnote_id=13029#r145
02-11-2015 10:10Gyorgy RethyStatusassigned => resolved
02-11-2015 10:10Gyorgy RethyFixed in Version => v4.7.1 (published 2016-07)
02-11-2015 10:10Gyorgy RethyResolutionopen => fixed
04-12-2015 14:55Gyorgy RethyAssigned ToGyorgy Rethy => Axel Rennoch
04-12-2015 14:55Gyorgy RethyStatusresolved => assigned
04-12-2015 14:56Gyorgy RethyStatusassigned => resolved
04-01-2016 15:41Gyorgy RethyNote Added: 0013654
04-01-2016 15:41Gyorgy RethyAssigned ToAxel Rennoch => Gyorgy Rethy
04-01-2016 15:41Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0013029) +
+ Gyorgy Rethy    +
+ 03-08-2015 13:08    +
(edited on: 05-08-2015 13:22)
+ 		+ + + + +
+ STF discussion 03-08-2015: make the editorial changes. Also check if more formal rules can be defined to translate XML comments and XSD annotations, e.g. their place in the generated TTCN-3 modules...
+
+
+
+
+
+ + + + + + + + + + +
+ (0013654) +
+ Gyorgy Rethy    +
+ 04-01-2016 15:41    +
+ 		+ + + + +
+ All examples are changed accordingly in draft V4.6.4
+
+ + diff --git a/docs/mantis/CR7084.md b/docs/mantis/CR7084.md new file mode 100644 index 0000000000000000000000000000000000000000..8f4ba21216b67e25ef1c1d10d5246127f4453602 --- /dev/null +++ b/docs/mantis/CR7084.md @@ -0,0 +1,136 @@ + + + + + + + + + + + + + 0007084: Placeholder for the draft of V4.7.1 - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007084Part 09: Using XML with TTCN-3Editorialpublic16-06-2015 11:2607-08-2015 11:06
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.6.1 (published 2015-06) 
Target Versionv4.7.1 (published 2016-07)Fixed in Versionv4.7.1 (published 2016-07) 
Clause Reference(s)N/A
For STF discussion
Source (company - Author)L.M.Ericsson
Summary0007084: Placeholder for the draft of V4.7.1
DescriptionThis CR is created to make the latest draft, contaning the closed (implemented) CRs available.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx es_20187309v040603.docx (475,438) 22-07-2015 15:06
http://oldforge.etsi.org/mantis/file_download.php?file_id=3221&type=bug
docx es_20187309v040603_v2.docx (497,491) 04-08-2015 11:37
http://oldforge.etsi.org/mantis/file_download.php?file_id=3227&type=bug
docx es_20187309v040603_v3.docx (501,956) 06-08-2015 09:13
http://oldforge.etsi.org/mantis/file_download.php?file_id=3239&type=bug
docx es_20187309v040603_v4.docx (508,857) 07-08-2015 10:54
http://oldforge.etsi.org/mantis/file_download.php?file_id=3254&type=bug
Issue History
Date ModifiedUsernameFieldChange
16-06-2015 11:26Gyorgy RethyNew Issue
16-06-2015 11:27Gyorgy RethyFile Added: es_20187309v040602.docx
16-06-2015 11:27Gyorgy RethyAssigned To => Gyorgy Rethy
16-06-2015 11:27Gyorgy RethyStatusnew => assigned
16-06-2015 11:32Gyorgy RethyFile Deleted: es_20187309v040602.docx
16-06-2015 11:32Gyorgy RethyFile Added: es_20187309v040602.docx
30-06-2015 09:59Gyorgy RethyFile Deleted: es_20187309v040602.docx
30-06-2015 10:00Gyorgy RethyFile Added: es_20187309v040602.docx
30-06-2015 10:01Gyorgy RethyStatusassigned => confirmed
22-07-2015 15:06Gyorgy RethyFile Added: es_20187309v040603.docx
22-07-2015 15:06Gyorgy RethyFile Deleted: es_20187309v040602.docx
03-08-2015 11:21Gyorgy RethyAssigned ToGyorgy Rethy => Axel Rennoch
03-08-2015 11:21Gyorgy RethyStatusconfirmed => assigned
04-08-2015 11:37Axel RennochFile Added: es_20187309v040603_v2.docx
04-08-2015 11:45Axel RennochNote Added: 0013055
04-08-2015 11:50Axel RennochAssigned ToAxel Rennoch => Gyorgy Rethy
04-08-2015 11:50Axel RennochStatusassigned => confirmed
06-08-2015 09:13Gyorgy RethyFile Added: es_20187309v040603_v3.docx
06-08-2015 09:15Gyorgy RethyNote Added: 0013100
07-08-2015 10:54Gyorgy RethyFile Added: es_20187309v040603_v4.docx
07-08-2015 11:06Gyorgy RethyNote Added: 0013138
07-08-2015 11:06Gyorgy RethyStatusconfirmed => closed
07-08-2015 11:06Gyorgy RethyResolutionopen => fixed
07-08-2015 11:06Gyorgy RethyFixed in Version => v4.7.1 (published 2016-07)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0013055) +
+ Axel Rennoch    +
+ 04-08-2015 11:45    +
+ 		+ + + + +
+ new document v2 has been uploaded with the following modifications:
+- several changes for the setting of "," and ";"
+- several changes for TTCN-3 keywords using bold font
+- add missing TTCN-3 type definition in ch 7.6.3, example 4
+- several modifications to indentation/linefeeds
+
+
+
+ + + + + + + + + + +
+ (0013100) +
+ Gyorgy Rethy    +
+ 06-08-2015 09:15    +
+ 		+ + + + +
+ new version es_20187309v040603_v3 uploaded:
+- ; is used at the end of each variant atribute in a consistent way (except Annex C that will be updated later this year.
+
+
+
+ + + + + + + + + + +
+ (0013138) +
+ Gyorgy Rethy    +
+ 07-08-2015 11:06    +
+ 		+ + + + +
+ File es_20187309v040603_v4.docx is uploaded to the MTS's drafts area as 4.6.2; as agreed in the STF, all further drafts will be uploaded to the MTS area only, there will be no placeholder for the standard's latest draft in Mantis.
+
+ + diff --git a/docs/mantis/CR7085.md b/docs/mantis/CR7085.md new file mode 100644 index 0000000000000000000000000000000000000000..cdbe5a43d2cf45e2a3230dfb55c0bb20bb08a156 --- /dev/null +++ b/docs/mantis/CR7085.md @@ -0,0 +1,131 @@ + + + + + + + + + + + + + 0007085: Placeholder for the draft of V4.8.1 - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007085Part 01: TTCN-3 Core LanguageEditorialpublic16-06-2015 11:2907-08-2015 13:43
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionopen 
PlatformOSOS Version
Product Versionv4.7.1 (published 2015-06) 
Target Versionv4.8.1 (published 2016-07)Fixed in Versionv4.8.1 (published 2016-07) 
Clause Reference(s)N/A
Source (company - Author)L.M.Ericsson
Summary0007085: Placeholder for the draft of V4.8.1
DescriptionThis CR is created to make the latest draft, contaning the closed (implemented) CRs available.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0006934closed Gyorgy Rethy Unnecessary restriction on match operation 
Attached Filesdocx es_20187301v040702.docx (1,459,322) 04-08-2015 09:55
http://oldforge.etsi.org/mantis/file_download.php?file_id=3225&type=bug
docx es_20187301v040702_b.docx (1,455,133) 04-08-2015 10:55
http://oldforge.etsi.org/mantis/file_download.php?file_id=3226&type=bug
docx es_20187301v040702_c.docx (1,461,484) 04-08-2015 13:54
http://oldforge.etsi.org/mantis/file_download.php?file_id=3228&type=bug
docx es_20187301v040702_d.docx (1,461,986) 04-08-2015 17:25
http://oldforge.etsi.org/mantis/file_download.php?file_id=3232&type=bug
docx es_20187301v040702_e.docx (1,478,138) 07-08-2015 13:19
http://oldforge.etsi.org/mantis/file_download.php?file_id=3258&type=bug
Issue History
Date ModifiedUsernameFieldChange
16-06-2015 11:29Gyorgy RethyNew Issue
16-06-2015 11:29Gyorgy RethyFile Added: es_20187301v040702.docx
16-06-2015 11:30Gyorgy RethyAssigned To => Gyorgy Rethy
16-06-2015 11:30Gyorgy RethyStatusnew => assigned
16-06-2015 11:30Gyorgy RethyProduct Version => v4.7.1 (published 2015-06)
16-06-2015 11:30Gyorgy RethyTarget Version => v4.8.1 (published 2016-07)
04-08-2015 08:56Gyorgy RethyFile Deleted: es_20187301v040702.docx
04-08-2015 08:56Gyorgy RethyFile Added: es_20187301v040702.docx
04-08-2015 09:42Gyorgy RethyFile Deleted: es_20187301v040702.docx
04-08-2015 09:42Gyorgy RethyFile Added: es_20187301v040702.docx
04-08-2015 09:48Gyorgy RethyFile Deleted: es_20187301v040702.docx
04-08-2015 09:48Gyorgy RethyFile Added: es_20187301v040702.docx
04-08-2015 09:49Gyorgy RethyNote Added: 0013048
04-08-2015 09:55Gyorgy RethyFile Deleted: es_20187301v040702.docx
04-08-2015 09:55Gyorgy RethyFile Added: es_20187301v040702.docx
04-08-2015 10:55Gyorgy RethyFile Added: es_20187301v040702_b.docx
04-08-2015 10:56Gyorgy RethyNote Added: 0013050
04-08-2015 13:54Gyorgy RethyFile Added: es_20187301v040702_c.docx
04-08-2015 17:24Gyorgy RethyRelationship addedrelated to 0006934
04-08-2015 17:25Gyorgy RethyFile Added: es_20187301v040702_d.docx
05-08-2015 10:42Jacob Wieland - SpirentNote Added: 0013080
05-08-2015 10:49Jacob Wieland - SpirentNote Deleted: 0013080
05-08-2015 10:49Jacob Wieland - SpirentNote Added: 0013081
05-08-2015 10:50Jacob Wieland - SpirentNote Deleted: 0013081
07-08-2015 13:19Gyorgy RethyFile Added: es_20187301v040702_e.docx
07-08-2015 13:43Gyorgy RethyNote Added: 0013149
07-08-2015 13:43Gyorgy RethyStatusassigned => closed
07-08-2015 13:43Gyorgy RethyFixed in Version => v4.8.1 (published 2016-07)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0013048) +
+ Gyorgy Rethy    +
+ 04-08-2015 09:49    +
+ 		+ + + + +
+ Contains resolution of CRs 6799, 6934, 7097. After content reviewed and agreed within the STF, the draft will be uploaded to MTS's draft area and this CR will be closed.
+
+
+
+ + + + + + + + + + +
+ (0013050) +
+ Gyorgy Rethy    +
+ 04-08-2015 10:56    +
+ 		+ + + + +
+ latest draft is in es_20187301v040702_b.docx: change to the first paragraph of C.3.1 has been reversed.
+
+
+
+ + + + + + + + + + +
+ (0013149) +
+ Gyorgy Rethy    +
+ 07-08-2015 13:43    +
+ 		+ + + + +
+ es_20187301v040702_e.docx has been uploaded to MTS's drafts area as interim draft V4.7.2. This CR is closed and according to the agreement in the STF all interim drafts will be uploaded to the MTS drafts area, no placeholder for the standard will be in Mantis.
+
+ + diff --git a/docs/mantis/CR7087.md b/docs/mantis/CR7087.md new file mode 100644 index 0000000000000000000000000000000000000000..bfd494237545bc6ad00798a2ce5fb2d09c3c67d5 --- /dev/null +++ b/docs/mantis/CR7087.md @@ -0,0 +1,169 @@ + + + + + + + + + + + + + 0007087: Change order of memberTypes in union examples - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007087Part 09: Using XML with TTCN-3Editorialpublic17-06-2015 15:1707-08-2015 10:28
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.6.1 (published 2015-06) 
Target Versionv4.7.1 (published 2016-07)Fixed in Versionv4.7.1 (published 2016-07) 
Clause Reference(s)7.5.3
For STF discussion
Source (company - Author)L.M.Ericsson
Summary0007087: Change order of memberTypes in union examples
DescriptionIn examples 1, 2 the type derived by union has string , float and integer memberTypes. The XSD string type is the first on list that is not practical for examples, as received values will be matched in the textual order of the alternatives and the string type can match all received values.
+
+Proposed solution: place the string type as the last on the list of memberTypes.
+
+In addition, the TTCN-3 type E21unnamedElement is superfluous, there is no rrelated XSD component in the example and E21unnamed is already declared as <element>.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7087_resolution_v1.docx (68,968) 17-06-2015 15:26
http://oldforge.etsi.org/mantis/file_download.php?file_id=3215&type=bug
docx CR7087_resolution_v2.docx (72,001) 04-08-2015 14:21
http://oldforge.etsi.org/mantis/file_download.php?file_id=3229&type=bug
Issue History
Date ModifiedUsernameFieldChange
17-06-2015 15:17Gyorgy RethyNew Issue
17-06-2015 15:25Gyorgy RethyProduct Version => v4.6.1 (published 2015-06)
17-06-2015 15:25Gyorgy RethyTarget Version => v4.7.1 (published 2016-07)
17-06-2015 15:25Gyorgy RethyDescription Updatedbug_revision_view_page.php?rev_id=126#r126
17-06-2015 15:26Gyorgy RethyFile Added: CR7087_resolution_v1.docx
03-08-2015 13:00Gyorgy RethyNote Added: 0013028
03-08-2015 13:01Gyorgy RethyAssigned To => Axel Rennoch
03-08-2015 13:01Gyorgy RethyStatusnew => assigned
04-08-2015 14:21Axel RennochFile Added: CR7087_resolution_v2.docx
04-08-2015 14:23Axel RennochNote Added: 0013062
04-08-2015 14:24Axel RennochNote Added: 0013063
04-08-2015 14:24Axel RennochAssigned ToAxel Rennoch => Gyorgy Rethy
04-08-2015 14:24Axel RennochStatusassigned => confirmed
07-08-2015 10:25Gyorgy RethyStatusconfirmed => closed
07-08-2015 10:25Gyorgy RethyResolutionopen => fixed
07-08-2015 10:25Gyorgy RethyFixed in Version => v4.7.1 (published 2016-07)
07-08-2015 10:28Gyorgy RethyNote Added: 0013131
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0013028) +
+ Gyorgy Rethy    +
+ 03-08-2015 13:00    +
+ 		+ + + + +
+ STF discussion 03-08-2015: check if this correction is included into the drfat in CR 7084. Check the correction.
+
+
+
+ + + + + + + + + + +
+ (0013062) +
+ Axel Rennoch    +
+ 04-08-2015 14:23    +
+ 		+ + + + +
+ v2 of the resolution also considers the corrections that have been done for CR 7084
+
+
+
+ + + + + + + + + + +
+ (0013063) +
+ Axel Rennoch    +
+ 04-08-2015 14:24    +
+ 		+ + + + +
+ the document in this CR should override the text in CR 7084
+
+
+
+ + + + + + + + + + +
+ (0013131) +
+ Gyorgy Rethy    +
+ 07-08-2015 10:28    +
+ 		+ + + + +
+ Changes added to interim draft V4.6.2 (file es_20187309v040603_v4.docx in CR7084)
+
+ + diff --git a/docs/mantis/CR7090.md b/docs/mantis/CR7090.md new file mode 100644 index 0000000000000000000000000000000000000000..fb82567bfca9bd31ace719dcc8c471ef396f3fbd --- /dev/null +++ b/docs/mantis/CR7090.md @@ -0,0 +1,435 @@ + + + + + + + + + + + + + 0007090: description and example for field value redirect are wrong - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007090Part 01: TTCN-3 Core LanguageEditorialpublic22-06-2015 13:5210-12-2015 16:16
ReporterJacob Wieland - Spirent 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.8.1 (published 2016-07)Fixed in Versionv4.8.1 (published 2016-07) 
Clause Reference(s)22.2.2
Source (company - Author)Testing Technologies - Jacob Wieland
Summary0007090: description and example for field value redirect are wrong
DescriptionThe BNF allows as the right hand side of a value-field redirect assignment only
+
+FieldReference ExtendedFieldReference
+
+(disregarding @encoded at the moment)
+
+in the section 22.2.2 this has been shorted to FieldOrTypeReference in the Syntactical Structure part.
+
+The description, though clear and confusing left and right hand side, can only be understood correctly if the intention of the feature is already clear. The later example is wrong.
+
+"When the keyword value is followed by an assignment list enframed by a pair of parentheses, the whole received
+message and/or one or more parts of it can be stored. In a single assignment within the list, on the left hand side of the
+assignment symbol (":=") a field of the template type shall be referenced, on the right hand side the name of the variable
+or a formal parameter, in which the value shall be stored. The variable or formal parameter shall be type compatible
+with the type on the left hand side of the assignment symbol. As a special case the field reference can be absent to
+indicate that the whole message shall be stored in a variable. "
+
+This is followed by the wrong example:
+
+MyPort.receive(MyType:?) -> value (MyVar, MyMessageIdVar:= MyType.messageId)
+ // The value of the received message is stored in the variable
+ // MyVar and the value of the messageId field of the received
+ // message is stored in the variable MyMessageIdVar.
+
+which contradicts both the above description and the semantic restriction of the BNF on FieldReference (i.e. it shall only start with a type in case it is applied to anytype.
+
+The example needs to be amended to
+
+MyPort.receive(MyType:?) -> value (MyVar, MyMessageIdVar:= messageId)
+
+and maybe the FieldOrTypeReference part could be clarified more in the description part as well. Also, left and right need to be fixed as the variable is on the left and the field reference on the right.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
has duplicate 0007168closed Gyorgy Rethy Invalid description of redirect assignment of message fields in receive operation 
Attached Filesdocx CR7090_resolution_v1.docx (28,265) 05-08-2015 16:11
http://oldforge.etsi.org/mantis/file_download.php?file_id=3236&type=bug
docx CR7090_resolution_v2.docx (27,420) 06-08-2015 09:10
http://oldforge.etsi.org/mantis/file_download.php?file_id=3238&type=bug
docx CR7090_resolution_v3.docx (28,524) 06-08-2015 10:10
http://oldforge.etsi.org/mantis/file_download.php?file_id=3241&type=bug
docx CR7090_resolution_v4.docx (28,796) 09-12-2015 16:33
http://oldforge.etsi.org/mantis/file_download.php?file_id=3390&type=bug
Issue History
Date ModifiedUsernameFieldChange
22-06-2015 13:52Jacob Wieland - SpirentNew Issue
03-08-2015 12:57Gyorgy RethyNote Added: 0013027
03-08-2015 12:57Gyorgy RethyAssigned To => Axel Rennoch
03-08-2015 12:57Gyorgy RethyStatusnew => assigned
04-08-2015 09:09Gyorgy RethyProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
05-08-2015 16:11Axel RennochFile Added: CR7090_resolution_v1.docx
05-08-2015 16:12Axel RennochNote Added: 0013089
05-08-2015 16:14Axel RennochNote Added: 0013090
05-08-2015 16:14Axel RennochAssigned ToAxel Rennoch => Jacob Wieland - Spirent
05-08-2015 16:14Axel RennochStatusassigned => acknowledged
06-08-2015 07:52Jacob Wieland - SpirentNote Added: 0013097
06-08-2015 07:52Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Axel Rennoch
06-08-2015 07:52Jacob Wieland - SpirentStatusacknowledged => assigned
06-08-2015 09:10Axel RennochFile Added: CR7090_resolution_v2.docx
06-08-2015 09:11Axel RennochNote Added: 0013098
06-08-2015 09:13Axel RennochNote Added: 0013099
06-08-2015 09:13Axel RennochAssigned ToAxel Rennoch => Jacob Wieland - Spirent
06-08-2015 09:13Axel RennochStatusassigned => acknowledged
06-08-2015 10:10Jacob Wieland - SpirentFile Added: CR7090_resolution_v3.docx
06-08-2015 10:11Jacob Wieland - SpirentNote Added: 0013107
06-08-2015 10:11Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Axel Rennoch
06-08-2015 10:11Jacob Wieland - SpirentStatusacknowledged => confirmed
06-08-2015 10:33Axel RennochNote Added: 0013108
06-08-2015 10:33Axel RennochStatusconfirmed => resolved
06-08-2015 10:33Axel RennochResolutionopen => fixed
06-08-2015 10:33Axel RennochAssigned ToAxel Rennoch => Gyorgy Rethy
07-09-2015 18:06Jacob Wieland - SpirentRelationship addedhas duplicate 0007168
04-11-2015 14:00Gyorgy RethyTarget Version => v4.8.1 (published 2016-07)
04-11-2015 14:02Gyorgy RethyFixed in Version => v4.8.1 (published 2016-07)
09-12-2015 16:33Gyorgy RethyFile Added: CR7090_resolution_v4.docx
09-12-2015 16:35Gyorgy RethyNote Added: 0013575
09-12-2015 16:35Gyorgy RethyStatusresolved => feedback
09-12-2015 16:35Gyorgy RethyResolutionfixed => reopened
09-12-2015 16:37Gyorgy RethyAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
09-12-2015 16:37Gyorgy RethyStatusfeedback => confirmed
10-12-2015 16:04Jacob Wieland - SpirentNote Added: 0013579
10-12-2015 16:04Jacob Wieland - SpirentStatusconfirmed => resolved
10-12-2015 16:04Jacob Wieland - SpirentResolutionreopened => fixed
10-12-2015 16:04Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
10-12-2015 16:16Gyorgy RethyNote Added: 0013581
10-12-2015 16:16Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0013027) +
+ Gyorgy Rethy    +
+ 03-08-2015 12:57    +
+ 		+ + + + +
+ STF discussion 03-08-2015: correct example and review textual description to make it more readable.
+
+
+
+ + + + + + + + + + +
+ (0013089) +
+ Axel Rennoch    +
+ 05-08-2015 16:12    +
+ 		+ + + + +
+ The uploaded file contains the corrected text and some text proposals (in comments).
+
+
+
+ + + + + + + + + + +
+ (0013090) +
+ Axel Rennoch    +
+ 05-08-2015 16:14    +
+ 		+ + + + +
+ Please have a look to the proposed alternative text variants.
+
+
+
+ + + + + + + + + + +
+ (0013097) +
+ Jacob Wieland - Spirent    +
+ 06-08-2015 07:52    +
+ 		+ + + + +
+ Regarding the first comment: What is meant with "A list element with a single assignment"?
+
+In the second comment, I like version two better but not only the ":=" should be missing but also the right-hand-side.
+
+
+
+ + + + + + + + + + +
+ (0013098) +
+ Axel Rennoch    +
+ 06-08-2015 09:11    +
+ 		+ + + + +
+ A second draft text proposal has been uploaded for further improvements.
+
+
+
+ + + + + + + + + + +
+ (0013099) +
+ Axel Rennoch    +
+ 06-08-2015 09:13    +
+ 		+ + + + +
+ Please have a look to v2 and feel free to do further modifications in the uploaded file.
+
+
+
+ + + + + + + + + + +
+ (0013107) +
+ Jacob Wieland - Spirent    +
+ 06-08-2015 10:11    +
+ 		+ + + + +
+ changed text somewhat, please review
+
+
+
+ + + + + + + + + + +
+ (0013108) +
+ Axel Rennoch    +
+ 06-08-2015 10:33    +
+ 		+ + + + +
+ The correction of the example and the final text proposed in the upload solves the CR.
+
+
+
+ + + + + + + + + + +
+ (0013575) +
+ Gyorgy Rethy    +
+ 09-12-2015 16:35    +
+ 		+ + + + +
+ Sorry guys, the changed text still was hard to read and confusing to me. Please look at my proposed text in CR7090_resolution_v4.docx.
+
+
+
+ + + + + + + + + + +
+ (0013579) +
+ Jacob Wieland - Spirent    +
+ 10-12-2015 16:04    +
+ 		+ + + + +
+ ok with me
+
+
+
+ + + + + + + + + + +
+ (0013581) +
+ Gyorgy Rethy    +
+ 10-12-2015 16:16    +
+ 		+ + + + +
+ Added to V4.7.4
+
+ + diff --git a/docs/mantis/CR7094.md b/docs/mantis/CR7094.md new file mode 100644 index 0000000000000000000000000000000000000000..10189504707d642c2dffd90bbaa8952588f50df9 --- /dev/null +++ b/docs/mantis/CR7094.md @@ -0,0 +1,67 @@ + + + + + + + + + + + + + 0007094: Paragraph text mentions 3, but 4 postfixing rules defined - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007094Part 09: Using XML with TTCN-3Editorialpublic30-06-2015 09:3130-06-2015 09:32
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.6.1 (published 2015-06) 
Target Versionv4.7.1 (published 2016-07)Fixed in Versionv4.7.1 (published 2016-07) 
Clause Reference(s)5.2.2
For STF discussion
Source (company - Author)L.M.Ericsson
Summary0007094: Paragraph text mentions 3, but 4 postfixing rules defined
DescriptionIntroduction text sound as:
+"Finally, depending on the kind of name being generated, one of the three following items shall apply:"
+but there are 4 rules j) to m) defined.
+
+Proposed solution: replace "three" with "four" in intro text.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
30-06-2015 09:31Gyorgy RethyNew Issue
30-06-2015 09:31Gyorgy RethyStatusnew => assigned
30-06-2015 09:31Gyorgy RethyAssigned To => Gyorgy Rethy
30-06-2015 09:32Gyorgy RethyNote Added: 0012988
30-06-2015 09:32Gyorgy RethyStatusassigned => closed
30-06-2015 09:32Gyorgy RethyResolutionopen => fixed
30-06-2015 09:32Gyorgy RethyFixed in Version => v4.7.1 (published 2016-07)
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0012988) +
+ Gyorgy Rethy    +
+ 30-06-2015 09:32    +
+ 		+ + + + +
+ Corrected in draft V4.6.2
+
+ + diff --git a/docs/mantis/CR7096.md b/docs/mantis/CR7096.md new file mode 100644 index 0000000000000000000000000000000000000000..bddc957cbe4436700d3aa5b473d5cc53d57e94af --- /dev/null +++ b/docs/mantis/CR7096.md @@ -0,0 +1,311 @@ + + + + + + + + + + + + + 0007096: Strong typing in redirect assignments - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007096Part 01: TTCN-3 Core LanguageClarificationpublic01-07-2015 12:2114-12-2015 10:51
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.7.1 (published 2015-06) 
Target Versionv4.8.1 (published 2016-07)Fixed in Versionv4.8.1 (published 2016-07) 
Clause Reference(s)6.3.4
Source (company - Author)Elvior
Summary0007096: Strong typing in redirect assignments
DescriptionThe current rules (as specified in the section 6.3.4) require strong typing in the redirect assignment part of the receive or trigger operations.
+
+However, redirect assignment can be used in the getcall, getreply and catch operation too, but it not explicitly mentioned in this section or any other section of the core language specification that strong typing is required in these case. This is not a very consistent solution. Compatibility rules shall be identical for all redirect assignments.
+
+Proposed solution: The last sententence of the section 6.3.4 shall be modified so that it explicitly enumerates the above mentioned operations in the following way:
+
+Strong typing also applies to storing the received value, parameters, address or component reference during a receive, trigger, getcall, getreply, catch or check operation.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7096_rules_overview.docx (15,404) 05-08-2015 14:32
http://oldforge.etsi.org/mantis/file_download.php?file_id=3235&type=bug
docx CR7096_resolution_v1.docx (80,619) 21-09-2015 13:37
http://oldforge.etsi.org/mantis/file_download.php?file_id=3259&type=bug
Issue History
Date ModifiedUsernameFieldChange
01-07-2015 12:21Tomas UrbanNew Issue
01-07-2015 12:33Jacob Wieland - SpirentNote Added: 0012993
01-07-2015 12:37Tomas UrbanNote Added: 0012994
03-08-2015 12:51Gyorgy RethyNote Added: 0013026
03-08-2015 12:51Gyorgy RethyAssigned To => Axel Rennoch
03-08-2015 12:51Gyorgy RethyStatusnew => assigned
05-08-2015 14:32Axel RennochFile Added: CR7096_rules_overview.docx
05-08-2015 14:33Axel RennochNote Added: 0013087
06-08-2015 14:49Gyorgy RethyNote Added: 0013118
21-09-2015 13:37Axel RennochFile Added: CR7096_resolution_v1.docx
21-09-2015 13:39Axel RennochNote Added: 0013203
21-09-2015 13:39Axel RennochAssigned ToAxel Rennoch => Jacob Wieland - Spirent
21-09-2015 13:39Axel RennochStatusassigned => acknowledged
22-09-2015 08:04Jacob Wieland - SpirentNote Added: 0013229
22-09-2015 08:04Jacob Wieland - SpirentStatusacknowledged => resolved
22-09-2015 08:04Jacob Wieland - SpirentFixed in Version => v4.8.1 (published 2016-07)
22-09-2015 08:04Jacob Wieland - SpirentResolutionopen => fixed
16-10-2015 13:29Jacob Wieland - SpirentStatusresolved => feedback
16-10-2015 13:29Jacob Wieland - SpirentResolutionfixed => reopened
16-10-2015 13:30Jacob Wieland - SpirentStatusfeedback => resolved
16-10-2015 13:30Jacob Wieland - SpirentResolutionreopened => fixed
16-10-2015 13:30Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
04-11-2015 14:00Gyorgy RethyTarget Version => v4.8.1 (published 2016-07)
14-12-2015 10:51Gyorgy RethyNote Added: 0013608
14-12-2015 10:51Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0012993) +
+ Jacob Wieland - Spirent    +
+ 01-07-2015 12:33    +
+ 		+ + + + +
+ I disagree, strong typing is necessary only for the matching-part because there the concrete type is used as type-hypothesis for the codec. For the redirection-assignment part it is not necessary as the result can also be stored in a compatible variable.
+
+Lessening this restriction would be backward compatible, while imposing the same restriction on the other operations would be backward incompatible.
+
+
+
+ + + + + + + + + + +
+ (0012994) +
+ Tomas Urban    +
+ 01-07-2015 12:37    +
+ 		+ + + + +
+ I have no objections against Jacob's proposal. It removes inconsistent rules for handling redirect assignments and that was the main objective of this CR.
+
+
+
+ + + + + + + + + + +
+ (0013026) +
+ Gyorgy Rethy    +
+ 03-08-2015 12:51    +
+ 		+ + + + +
+ STF discussion 03-08-2015: as first step collect type compatibility rules for all kinds of redirect (value, address,...) and for all types of receiving operations.
+
+
+
+ + + + + + + + + + +
+ (0013087) +
+ Axel Rennoch    +
+ 05-08-2015 14:33    +
+ 		+ + + + +
+ various rules have been identified and collected in a table, see uploaded file
+
+
+
+ + + + + + + + + + +
+ (0013118) +
+ Gyorgy Rethy    +
+ 06-08-2015 14:49    +
+ 		+ + + + +
+ STF discussion 06-08-2015: The rules are currently not fully consistent, we shall make them harmonized throughout the standard. The STF doesn't see a technical reason to keep strong typing for the storing part of communication operations (for the message and from matching parts strong typing is required).
+
+Before making the changes let leave time for comments. If no objection is received until the next STF session (w39, 21-25 September), prepare the text proposal.
+
+
+
+ + + + + + + + + + +
+ (0013203) +
+ Axel Rennoch    +
+ 21-09-2015 13:39    +
+ 		+ + + + +
+ Please have a look to the proposed changes in the uploaded resolution file.
+
+
+
+ + + + + + + + + + +
+ (0013229) +
+ Jacob Wieland - Spirent    +
+ 22-09-2015 08:04    +
+ 		+ + + + +
+ proposal ok
+
+
+
+ + + + + + + + + + +
+ (0013608) +
+ Gyorgy Rethy    +
+ 14-12-2015 10:51    +
+ 		+ + + + +
+ Added to draft V4.7.4
+
+ + diff --git a/docs/mantis/CR7097.md b/docs/mantis/CR7097.md new file mode 100644 index 0000000000000000000000000000000000000000..eca551f70a7e874177c4a4693e7a6e2e3449c09d --- /dev/null +++ b/docs/mantis/CR7097.md @@ -0,0 +1,248 @@ + + + + + + + + + + + + + 0007097: Clarification: ispresent function for elements of a "record of" or "set of" - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007097Part 01: TTCN-3 Core LanguageClarificationpublic01-07-2015 13:3707-08-2015 13:51
ReporterWolfgang Seka 
Assigned ToGyorgy Rethy 
PriorityhighSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.7.1 (published 2015-06) 
Target Versionv4.8.1 (published 2016-07)Fixed in Versionv4.8.1 (published 2016-07) 
Clause Reference(s)16.1.2, C.3.1
Source (company - Author)MCC160 - Wolfgang
Summary0007097: Clarification: ispresent function for elements of a "record of" or "set of"
DescriptionCurrently it is not defined what happens in case of e.g. ispresent(v_RecordOf[i]): Table 14 (clause 16.1.2) refers to "optional field in a record or set value or template" only.
+On the other hand according to C.3.1 ispresent shall not cause an error.
+
+=> Either applicability of ispresent shall be enhanced to cope with "record of" and "set of" too or an error shall be defined for this case (compilation or runtime error).
+
+Note: at least with one compiler currently there are side effects resulting in runtime errors which are not directly related to ispresent.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
01-07-2015 13:37Wolfgang SekaNew Issue
03-08-2015 11:42Gyorgy RethyNote Added: 0013025
03-08-2015 11:42Gyorgy RethyAssigned To => Jacob Wieland - Spirent
03-08-2015 11:42Gyorgy RethyStatusnew => assigned
04-08-2015 08:30Gyorgy RethyNote Edited: 0013025bug_revision_view_page.php?bugnote_id=13025#r136
04-08-2015 09:12Gyorgy RethyProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
04-08-2015 09:37Gyorgy RethyNote Added: 0013045
04-08-2015 09:42Gyorgy RethyNote Added: 0013047
04-08-2015 09:42Gyorgy RethyStatusassigned => confirmed
04-08-2015 09:44Gyorgy RethyResolutionopen => fixed
04-08-2015 10:54Gyorgy RethyNote Edited: 0013025bug_revision_view_page.php?bugnote_id=13025#r137
04-08-2015 14:48Jacob Wieland - SpirentNote Added: 0013067
04-08-2015 14:48Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
04-08-2015 14:48Jacob Wieland - SpirentStatusconfirmed => assigned
07-08-2015 13:17Gyorgy RethyNote Added: 0013143
07-08-2015 13:18Gyorgy RethyNote Added: 0013144
07-08-2015 13:18Gyorgy RethyStatusassigned => closed
07-08-2015 13:18Gyorgy RethyProduct Version => v4.7.1 (published 2015-06)
07-08-2015 13:18Gyorgy RethyFixed in Version => v4.8.1 (published 2016-07)
07-08-2015 13:18Gyorgy RethyTarget Version => v4.8.1 (published 2016-07)
07-08-2015 13:51Gyorgy RethyNote Edited: 0013144bug_revision_view_page.php?bugnote_id=13144#r153
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0013025) +
+ Gyorgy Rethy    +
+ 03-08-2015 11:42    +
(edited on: 04-08-2015 10:54)
+ 		+ + + + +
+ STF discussion 03-08-2015: ispresent is not allowed to record/set of elements, this shall cause a semantic error. Solution to clarify: refer to table 14 in clause C.3.1. To table 14 add other language elements that can match omit (e.g. complete templates).
+
+
+
+
+
+ + + + + + + + + + +
+ (0013045) +
+ Gyorgy Rethy    +
+ 04-08-2015 09:37    +
+ 		+ + + + +
+ Proposed resolution is in the draft uploaded to CR 7085 (http://forge.etsi.org/mantis/view.php?id=7085 [^]), es_20187301v040702.docx, please cross-check.
+
+At the end of this working session the draft containing closed CRs will be uploaded to MTS drafts area. Further candidates to be included: CRs 6774 & 6934
+
+
+
+ + + + + + + + + + +
+ (0013047) +
+ Gyorgy Rethy    +
+ 04-08-2015 09:42    +
+ 		+ + + + +
+ Please check draft in CR 7085
+
+
+
+ + + + + + + + + + +
+ (0013067) +
+ Jacob Wieland - Spirent    +
+ 04-08-2015 14:48    +
+ 		+ + + + +
+ the proposed solution is wrong. ispresent should return true for all templates that are not AnyValueOrNone, Ifpresent or Omit, i.e. it should return false for all matching mechanisms that can match omit.
+
+proposal: change entry in table 14 to:
+
+"Determine ... is present or is assigned a matching mechanism that cannot match an ommitted field." (maybe with a note that those are omit, * and ifpresent)
+
+
+
+ + + + + + + + + + +
+ (0013143) +
+ Gyorgy Rethy    +
+ 07-08-2015 13:17    +
+ 		+ + + + +
+ Proposal is OK with minor editorial modifications. See file es_20187301v040702_e.docx in CR 7085.
+
+
+
+ + + + + + + + + + +
+ (0013144) +
+ Gyorgy Rethy    +
+ 07-08-2015 13:18    +
(edited on: 07-08-2015 13:51)
+ 		+ + + + +
+ Implemented in interim draft version V4.7.3 uploaded to TB MTS's drafts area (file es_20187301v040702_e.docx in CR7085).
+
+
+
+ + diff --git a/docs/mantis/CR7100.md b/docs/mantis/CR7100.md new file mode 100644 index 0000000000000000000000000000000000000000..d83dd224baf2a0ffe556838aaf28f2e9485ef277 --- /dev/null +++ b/docs/mantis/CR7100.md @@ -0,0 +1,177 @@ + + + + + + + + + + + + + 0007100: Mapping of XSD id attributes - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007100Part 09: Using XML with TTCN-3Technicalpublic06-07-2015 16:4404-12-2015 15:21
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeveritymajorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.6.1 (published 2015-06) 
Target Versionv4.7.1 (published 2016-07)Fixed in Versionv4.7.1 (published 2016-07) 
Clause Reference(s)7.1.1
For STF discussion
Source (company - Author)L.M.Ericsson
Summary0007100: Mapping of XSD id attributes
DescriptionToday, the mapping of id attributes of XSD components is wrong.
+
+Each id attribute is mapped to a stand-alone TTCN-3 type (see $7.1.1). Hovewer, XSD allows to assign id-s to all XSD elements (including <schema>) but <documentation> (see attached example, which is valid XSD). The mapping today is not able to bind the id attribute values to the XSD elements defining them.
+
+Proposed solutions:
+TTCN-3 with attributes can be added to any TTCN-3 definition or a field of it, thus
+- either define an encoding instruction and map the id attribute value to it; this would allow to encode the id value into the XML document at sending and checking the id value at reception;
+a consistent form could be
+variant """ id as 'freetext' """,
+where freetext contains the value of the id attribute;
+- or ignore the id attributes (in principle it may cause problems when testing applications expecting the id-s in the encoded XML).
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files? all.xsd (2,238) 06-07-2015 16:44
http://oldforge.etsi.org/mantis/file_download.php?file_id=3218&type=bug
docx CR7100.docx (687,836) 02-11-2015 14:10
http://oldforge.etsi.org/mantis/file_download.php?file_id=3336&type=bug
Issue History
Date ModifiedUsernameFieldChange
06-07-2015 16:44Gyorgy RethyNew Issue
06-07-2015 16:44Gyorgy RethyFile Added: all.xsd
03-08-2015 11:28Gyorgy RethyNote Added: 0013024
03-08-2015 11:28Gyorgy RethyAssigned To => Gyorgy Rethy
03-08-2015 11:28Gyorgy RethyStatusnew => assigned
02-11-2015 10:09Gyorgy RethyAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
02-11-2015 13:52Jacob Wieland - SpirentNote Added: 0013437
02-11-2015 14:10Jacob Wieland - SpirentFile Added: CR7100.docx
02-11-2015 14:11Jacob Wieland - SpirentNote Added: 0013440
02-11-2015 14:11Jacob Wieland - SpirentStatusassigned => resolved
02-11-2015 14:11Jacob Wieland - SpirentFixed in Version => v4.7.1 (published 2016-07)
02-11-2015 14:11Jacob Wieland - SpirentResolutionopen => fixed
02-11-2015 14:11Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
04-12-2015 15:21Gyorgy RethyNote Added: 0013558
04-12-2015 15:21Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0013024) +
+ Gyorgy Rethy    +
+ 03-08-2015 11:28    +
+ 		+ + + + +
+ STF discussion 03-08-2015: Check how id-s are used in XML encoding.
+
+
+
+ + + + + + + + + + +
+ (0013437) +
+ Jacob Wieland - Spirent    +
+ 02-11-2015 13:52    +
+ 		+ + + + +
+ as far as I understand, the id attributes in the schema definition have no bearing on the XML (not to be confused with attributes of type xsd:ID), they simply allow uniquely identifying components of a schema, probably so that these components can be referenced by some schema-referencing mechanism.
+
+Therefore, in principle, the current definition in the standard is correct, allowing the types that the schema-components are mapped to also to be referenced by their ID-alias type. However, since these types do not really add any value in the TTCN-3 context, maybe they can be ignored in the mapping altogether (or added as variant attribute). For schema-components which are not mapped to a TTCN-3 type or field, but which are mapped to a TTCN-3 construct (like a module), a variant attribute might be the only way of preserving this information.
+
+
+
+ + + + + + + + + + +
+ (0013440) +
+ Jacob Wieland - Spirent    +
+ 02-11-2015 14:11    +
+ 		+ + + + +
+ according to STF discussion: mark feature as deprecated (see proposal)
+
+
+
+ + + + + + + + + + +
+ (0013558) +
+ Gyorgy Rethy    +
+ 04-12-2015 15:21    +
+ 		+ + + + +
+ Added to draft V4.6.3
+
+ + diff --git a/docs/mantis/CR7111.md b/docs/mantis/CR7111.md new file mode 100644 index 0000000000000000000000000000000000000000..4d4818fa3ba1411a34226eeb998e45cb139ad5f4 --- /dev/null +++ b/docs/mantis/CR7111.md @@ -0,0 +1,105 @@ + + + + + + + + + + + + + 0007111: Several errors in examples - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007111Part 09: Using XML with TTCN-3Editorialpublic22-07-2015 15:0307-08-2015 10:55
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.6.1 (published 2015-06) 
Target Versionv4.7.1 (published 2016-07)Fixed in Versionv4.7.1 (published 2016-07) 
Clause Reference(s)See Description section
For STF discussion
Source (company - Author)L.M.Ericsson
Summary0007111: Several errors in examples
DescriptionIn 6.1.5, Example2: „name as uncapitalized” shall be „name as ‘integer-0-5-10’
+In 6.1.5, Example2 Example3: „name as uncapitalized” shall be „name as ‘integer-1-10’”.
+In 6.1.5, Example4: "name as uncapitalized" shall be "name as multiple-of-4"; minExclusive value="5" shall be maxExclusive value="5".
+In 7.5.2, Example2: add xsd: prefix to list & restriciton tags (opening and closing)
+In 7.5.3, Example2: add xsd: prefix to union and restriction tags
+In 7.5.3, Example3: minInclusive is superfluous in the example, it is ignored by the conversion for date types anyway; add "name as 'Time-or-int-or-boolean-or-dateRestricted'"
+In 7.6.1.1, Example: add xsd: prefix to restriction tag
+In 7.6.5.4, Example2: add '_' postfix to second occurance of field names foo and bar
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
22-07-2015 15:03Gyorgy RethyNew Issue
22-07-2015 15:05Gyorgy RethyNote Added: 0013000
22-07-2015 15:05Gyorgy RethyAssigned To => Gyorgy Rethy
22-07-2015 15:05Gyorgy RethyStatusnew => assigned
22-07-2015 15:05Gyorgy RethyResolutionopen => fixed
22-07-2015 15:07Gyorgy RethyStatusassigned => confirmed
07-08-2015 10:55Gyorgy RethyNote Added: 0013134
07-08-2015 10:55Gyorgy RethyStatusconfirmed => closed
07-08-2015 10:55Gyorgy RethyFixed in Version => v4.7.1 (published 2016-07)
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0013000) +
+ Gyorgy Rethy    +
+ 22-07-2015 15:05    +
+ 		+ + + + +
+ See corrections in CR 7084, draft es_20187309v040603.docx
+
+
+
+ + + + + + + + + + +
+ (0013134) +
+ Gyorgy Rethy    +
+ 07-08-2015 10:55    +
+ 		+ + + + +
+ Implemented in interim draft V4.6.2 (file es_20187309v040603_v4.docx in CR7084)
+
+ + diff --git a/docs/mantis/CR7112.md b/docs/mantis/CR7112.md new file mode 100644 index 0000000000000000000000000000000000000000..6d9d551247dee1c1b812c48ec5619bc0ec6b86e3 --- /dev/null +++ b/docs/mantis/CR7112.md @@ -0,0 +1,243 @@ + + + + + + + + + + + + + 0007112: allow different syntax for binary string types - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007112Part 01: TTCN-3 Core LanguageNew Featurepublic27-07-2015 11:1911-12-2015 15:23
ReporterJacob Wieland - Spirent 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.8.1 (published 2016-07)Fixed in Versionv4.8.1 (published 2016-07) 
Clause Reference(s)6.1.1., A.1.6.6.
Source (company - Author)Testing Technologies - Jacob Wieland
Summary0007112: allow different syntax for binary string types
DescriptionIt is very often a hassle to convert a binary representation taken from some other tool into a TTCN-3 octestsring or bitstring.
+
+In normal representations, there are often spaces allowed between groups of digits or there are prefixes like 0x or 0b in front of some digit groups.
+
+It would be very convenient if such a representation could be used directly in TTCN-3 as well so that no conversion would be necessary anymore.
+
+Also, the strings can thus be structured and made more readable. Better readability almost always improves the quality of code.
+
+Minimally, allowing spaces would be sufficient. For convenience sake allowing newlines and 0x/0b prefixes would be a bonus.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7112_resolution_v1b.docx (34,757) 06-08-2015 15:34
http://oldforge.etsi.org/mantis/file_download.php?file_id=3247&type=bug
docx CR7112_resolution_v2b.docx (35,193) 07-08-2015 12:34
http://oldforge.etsi.org/mantis/file_download.php?file_id=3257&type=bug
Issue History
Date ModifiedUsernameFieldChange
27-07-2015 11:19Jacob Wieland - SpirentNew Issue
03-08-2015 11:07Gyorgy RethyNote Added: 0013023
03-08-2015 11:07Gyorgy RethyAssigned To => Axel Rennoch
03-08-2015 11:07Gyorgy RethyStatusnew => assigned
04-08-2015 09:08Gyorgy RethyProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
06-08-2015 13:05Jacob Wieland - SpirentTarget Version => v4.8.1 (published 2016-07)
06-08-2015 15:34Axel RennochFile Added: CR7112_resolution_v1b.docx
06-08-2015 15:35Axel RennochNote Added: 0013119
06-08-2015 15:36Axel RennochNote Added: 0013120
06-08-2015 15:36Axel RennochAssigned ToAxel Rennoch => Jacob Wieland - Spirent
06-08-2015 15:36Axel RennochStatusassigned => acknowledged
07-08-2015 09:03Jacob Wieland - SpirentNote Added: 0013122
07-08-2015 12:34Axel RennochFile Added: CR7112_resolution_v2b.docx
07-08-2015 12:35Axel RennochNote Added: 0013142
07-08-2015 12:35Axel RennochStatusacknowledged => resolved
07-08-2015 12:35Axel RennochResolutionopen => fixed
07-08-2015 12:35Axel RennochAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
04-11-2015 14:02Gyorgy RethyFixed in Version => v4.8.1 (published 2016-07)
11-12-2015 15:23Gyorgy RethyNote Added: 0013601
11-12-2015 15:23Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0013023) +
+ Gyorgy Rethy    +
+ 03-08-2015 11:07    +
+ 		+ + + + +
+ STF discussion 03-08-2015: Agreed to allow spaces. Analyse also possible introduction of alternative syntaxes.
+
+
+
+ + + + + + + + + + +
+ (0013119) +
+ Axel Rennoch    +
+ 06-08-2015 15:35    +
+ 		+ + + + +
+ following the discussion the uploaded file considers spaces and newlines, but not 0x/0b prefixes.
+
+
+
+ + + + + + + + + + +
+ (0013120) +
+ Axel Rennoch    +
+ 06-08-2015 15:36    +
+ 		+ + + + +
+ Please check the uploaded proposed solution for correctness.
+
+
+
+ + + + + + + + + + +
+ (0013122) +
+ Jacob Wieland - Spirent    +
+ 07-08-2015 09:03    +
+ 		+ + + + +
+ Small amendment, the newline shall consist of 'any combination of the newline characters that constitute a newline' (i.e. under windows CR LF is just ONE newline). Known combinations (to me) are: CR LF (windows), LF (linux), CR (macos). Maybe this should be reflected in the BNF rule.
+
+NLChar ::= CR [LF] | LF | VT
+
+
+
+ + + + + + + + + + +
+ (0013142) +
+ Axel Rennoch    +
+ 07-08-2015 12:35    +
+ 		+ + + + +
+ final rewording to consider windows newlines (CR LF)
+
+
+
+ + + + + + + + + + +
+ (0013601) +
+ Gyorgy Rethy    +
+ 11-12-2015 15:23    +
+ 		+ + + + +
+ Added to draft V4.7.4
+
+ + diff --git a/docs/mantis/CR7113.md b/docs/mantis/CR7113.md new file mode 100644 index 0000000000000000000000000000000000000000..cf138acc929886c1c275ff5fe967c4d24f147462 --- /dev/null +++ b/docs/mantis/CR7113.md @@ -0,0 +1,107 @@ + + + + + + + + + + + + + 0007113: Wording issues in rules on actual values of in formal parameters - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007113Part 01: TTCN-3 Core LanguageEditorialpublic28-07-2015 08:1703-11-2015 10:28
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritylowSeveritytrivialReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.7.1 (published 2015-06) 
Target Versionv4.8.1 (published 2016-07)Fixed in Versionv4.8.1 (published 2016-07) 
Clause Reference(s)5.4.2
Source (company - Author)STF 487
Summary0007113: Wording issues in rules on actual values of in formal parameters
DescriptionThere are two issues in the rules on actual values of in formal value parameters:
+
+1) The rules mention "variables" two times
+2) The rules say that parameter can be a "value returning function", but the correct explanation would be a "value returning function call" or "invocation of a value returning function".
+
+The second issue concerns the rules on actual values of in formal template parameters as well.
+
+Proposal: Change the paragraphs of 5.4.2 in the following way:
+Actual parameters that are passed by value to in formal value parameters shall be literal values, module parameters, constants, variables, value returning (external) function calls, formal value parameters (of in, inout or out parameterization) of the current scope or expressions composed of the above.
+
+Actual parameters that are passed to in formal template parameters shall be literal values, module parameters, constants, variables, value or template returning (external) function calls, formal value parameters (of in, inout or out parameterization) of the current scope or expressions composed of the above, as well as templates, template variables or formal template parameters (of in, inout or out parameterization) of the current scope.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0007114closed Gyorgy Rethy Actual parameters of out formal value parameters not defined 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
28-07-2015 08:17Tomas UrbanNew Issue
03-08-2015 11:00Gyorgy RethyAssigned To => Jacob Wieland - Spirent
03-08-2015 11:00Gyorgy RethyStatusnew => assigned
03-08-2015 11:01Gyorgy RethyRelationship addedrelated to 0007114
04-08-2015 14:35Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
04-08-2015 14:36Jacob Wieland - SpirentNote Added: 0013064
04-08-2015 14:36Jacob Wieland - SpirentStatusassigned => confirmed
25-09-2015 10:58Gyorgy RethyTarget Version => v4.8.1 (published 2016-07)
03-11-2015 10:28Gyorgy RethyNote Added: 0013457
03-11-2015 10:28Gyorgy RethyStatusconfirmed => closed
03-11-2015 10:28Gyorgy RethyResolutionopen => fixed
03-11-2015 10:28Gyorgy RethyFixed in Version => v4.8.1 (published 2016-07)
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0013064) +
+ Jacob Wieland - Spirent    +
+ 04-08-2015 14:36    +
+ 		+ + + + +
+ see proposal in CR 7114
+
+
+
+ + + + + + + + + + +
+ (0013457) +
+ Gyorgy Rethy    +
+ 03-11-2015 10:28    +
+ 		+ + + + +
+ Resolved in CR7114
+
+ + diff --git a/docs/mantis/CR7114.md b/docs/mantis/CR7114.md new file mode 100644 index 0000000000000000000000000000000000000000..43b2e0a691c08661129ec371c038d916959bbbb8 --- /dev/null +++ b/docs/mantis/CR7114.md @@ -0,0 +1,549 @@ + + + + + + + + + + + + + 0007114: Actual parameters of out formal value parameters not defined - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007114Part 01: TTCN-3 Core LanguageTechnicalpublic28-07-2015 13:3610-12-2015 16:04
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.7.1 (published 2015-06) 
Target Versionv4.8.1 (published 2016-07)Fixed in Versionv4.8.1 (published 2016-07) 
Clause Reference(s)5.4.2
Source (company - Author)STF 487
Summary0007114: Actual parameters of out formal value parameters not defined
DescriptionIn the last version of the standard, the following rule no longer includes out formal value parameters and as a result, the actual parameters of out formal value parameters are no longer defined:
+
+Actual parameters that are passed to inout formal value parameters shall be variables or formal value parameters (of in, inout or out parameterization) or references to elements of variables or formal value parameters of structured types.
+
+Proposal: Restore the original text: Actual parameters that are passed to inout or out formal value parameters shall be variables or formal value parameters (of in, inout or out parameterization) or references to elements of variables or formal value parameters of structured types.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0007113closed Gyorgy Rethy Wording issues in rules on actual values of in formal parameters 
related to 0007118closed Gyorgy Rethy Not clear when actual parameter passing occurs 
related to 0007119closed Gyorgy Rethy Out parameter rule inside a note 
related to 0007116closed Gyorgy Rethy Actual parameters of out formal template parameters 
related to 0007149closed Gyorgy Rethy Allow to skip actual out parameters 
related to 0007115closed Gyorgy Rethy Actual parameters of inout formal template parameters 
Attached Filesdocx CR7114.docx (216,870) 06-08-2015 16:45
http://oldforge.etsi.org/mantis/file_download.php?file_id=3249&type=bug
docx CR7114_resolution_v2.docx (221,266) 13-10-2015 15:26
http://oldforge.etsi.org/mantis/file_download.php?file_id=3303&type=bug
docx CR7114_resolution_v3.docx (222,266) 14-10-2015 11:07
http://oldforge.etsi.org/mantis/file_download.php?file_id=3307&type=bug
docx CR7114_resolution_v4.docx (222,598) 03-11-2015 10:29
http://oldforge.etsi.org/mantis/file_download.php?file_id=3345&type=bug
Issue History
Date ModifiedUsernameFieldChange
28-07-2015 13:36Tomas UrbanNew Issue
28-07-2015 14:24Tomas UrbanNote Added: 0013008
03-08-2015 10:56Gyorgy RethyNote Added: 0013022
03-08-2015 10:57Gyorgy RethyAssigned To => Jacob Wieland - Spirent
03-08-2015 10:57Gyorgy RethyStatusnew => assigned
03-08-2015 11:01Gyorgy RethyRelationship addedrelated to 0007113
04-08-2015 14:10Jacob Wieland - SpirentNote Added: 0013061
04-08-2015 14:10Jacob Wieland - SpirentStatusassigned => confirmed
04-08-2015 14:36Jacob Wieland - SpirentRelationship addedrelated to 0007118
04-08-2015 14:37Jacob Wieland - SpirentRelationship addedrelated to 0007119
04-08-2015 14:38Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
04-08-2015 14:38Jacob Wieland - SpirentStatusconfirmed => assigned
04-08-2015 14:38Jacob Wieland - SpirentStatusassigned => confirmed
04-08-2015 15:20Gyorgy RethyNote Added: 0013072
06-08-2015 09:55Gyorgy RethyAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
06-08-2015 09:55Gyorgy RethyStatusconfirmed => assigned
06-08-2015 10:16Gyorgy RethyRelationship addedrelated to 0007116
06-08-2015 13:05Jacob Wieland - SpirentTarget Version => v4.8.1 (published 2016-07)
06-08-2015 16:45Jacob Wieland - SpirentFile Added: CR7114.docx
07-08-2015 09:04Jacob Wieland - SpirentNote Added: 0013123
07-08-2015 09:04Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
07-08-2015 09:04Jacob Wieland - SpirentStatusassigned => confirmed
07-08-2015 09:46Tomas UrbanNote Added: 0013128
10-08-2015 09:16Jacob Wieland - SpirentNote Added: 0013152
12-10-2015 14:39Gyorgy RethyNote Added: 0013355
12-10-2015 14:39Gyorgy RethyAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
12-10-2015 14:39Gyorgy RethyStatusconfirmed => assigned
12-10-2015 14:46Gyorgy RethyNote Edited: 0013355bug_revision_view_page.php?bugnote_id=13355#r179
12-10-2015 14:47Gyorgy RethyNote Edited: 0013355bug_revision_view_page.php?bugnote_id=13355#r180
12-10-2015 16:04Jacob Wieland - SpirentNote Added: 0013360
12-10-2015 17:21Jacob Wieland - SpirentNote Edited: 0013360bug_revision_view_page.php?bugnote_id=13360#r182
13-10-2015 12:25Gyorgy RethyRelationship addedrelated to 0007149
13-10-2015 12:26Gyorgy RethyRelationship deletedrelated to 0007149
13-10-2015 12:36Gyorgy RethyNote Added: 0013367
13-10-2015 12:36Gyorgy RethyStatusassigned => confirmed
13-10-2015 12:39Gyorgy RethyRelationship addedrelated to 0007149
13-10-2015 14:54Jacob Wieland - SpirentNote Added: 0013371
13-10-2015 15:26Jacob Wieland - SpirentFile Added: CR7114_resolution_v2.docx
13-10-2015 15:31Jacob Wieland - SpirentNote Added: 0013373
13-10-2015 15:32Jacob Wieland - SpirentNote Deleted: 0013371
13-10-2015 15:32Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent =>
13-10-2015 15:33Jacob Wieland - SpirentAssigned To => Jacob Wieland - Spirent
13-10-2015 15:33Jacob Wieland - SpirentStatusconfirmed => assigned
13-10-2015 15:33Jacob Wieland - SpirentNote Added: 0013374
13-10-2015 15:33Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
13-10-2015 15:33Jacob Wieland - SpirentStatusassigned => confirmed
14-10-2015 11:07Gyorgy RethyFile Added: CR7114_resolution_v3.docx
14-10-2015 11:07Gyorgy RethyStatusconfirmed => resolved
14-10-2015 11:07Gyorgy RethyFixed in Version => v4.8.1 (published 2016-07)
14-10-2015 11:07Gyorgy RethyResolutionopen => fixed
15-10-2015 12:51Jacob Wieland - SpirentRelationship addedrelated to 0007115
03-11-2015 10:28Gyorgy RethyStatusresolved => feedback
03-11-2015 10:29Gyorgy RethyFile Added: CR7114_resolution_v4.docx
03-11-2015 10:30Gyorgy RethyNote Added: 0013458
03-11-2015 10:30Gyorgy RethyStatusfeedback => resolved
10-12-2015 16:04Gyorgy RethyNote Added: 0013578
10-12-2015 16:04Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0013008) +
+ Tomas Urban    +
+ 28-07-2015 14:24    +
+ 		+ + + + +
+ The original proposal is actually not correct. There's actually a difference between inout and out parameters, because out parameters as assignment target can be template variables as well. Therefore a new rule should be added saying that:
+
+Actual parameters that are passed to out formal value parameters shall be variables, template variables, formal value parameters, formal template parameters or references to elements of variables, template variables, formal value parameters or formal template parameters of structured types.
+
+
+
+ + + + + + + + + + +
+ (0013022) +
+ Gyorgy Rethy    +
+ 03-08-2015 10:56    +
+ 		+ + + + +
+ STF discussion 03-08-2015: Comment correct. Add rule for out value parameter and check if formal template parameters need separate paragraphs for out and inout parameters.
+
+
+
+ + + + + + + + + + +
+ (0013061) +
+ Jacob Wieland - Spirent    +
+ 04-08-2015 14:10    +
+ 		+ + + + +
+ please review, this proposal addresses CRS 7113, 7114, 7118, 7119
+
+
+
+ + + + + + + + + + +
+ (0013072) +
+ Gyorgy Rethy    +
+ 04-08-2015 15:20    +
+ 		+ + + + +
+ Jacob, pls. upload the file :-)
+
+
+
+ + + + + + + + + + +
+ (0013123) +
+ Jacob Wieland - Spirent    +
+ 07-08-2015 09:04    +
+ 		+ + + + +
+ done, please review
+
+
+
+ + + + + + + + + + +
+ (0013128) +
+ Tomas Urban    +
+ 07-08-2015 09:46    +
+ 		+ + + + +
+ I like the proposed solution, it solves the issues raised in this CR and 7113, 7116, 7119.
+
+However, there still several things for discussion:
+1. The problem described in CR 7118 doesn't seem to be addressed.
+2. I would prefer to use a different expression than the term "applications of value returning functions", mostly because the term is not consistent with the terminology used in the current specification (invocation of functions, function call).
+3. I propose to move the proposed rules that concern template restrictions from the restriction d to the restriction e so that all rules related to template restriction are in one paragraph.
+
+
+
+ + + + + + + + + + +
+ (0013152) +
+ Jacob Wieland - Spirent    +
+ 10-08-2015 09:16    +
+ 		+ + + + +
+ CR 7118 is addressed in the definitions section for out parameterization by the following:
+
+"content of the formal parameter is passed back to the evaluation of the actual parameter at the time of the invocation of the parameterized object"
+
+We probably need a better description than "evaluation of the actual parameter" for out parameters as the variable reference that the actual parameter expression evaluates to is meant here and not its content.
+
+
+
+ + + + + + + + + + +
+ (0013355) +
+ Gyorgy Rethy    +
+ 12-10-2015 14:39    +
(edited on: 12-10-2015 14:47)
+ 		+ + + + +
+ Reading the whole sentence it tends to become hardly readable. I make a try to rewording it:
+
+out parameterization: kind of parameterization by value, where the actual parameter's content (the argument) is not passed to the formal parameter when the parameterized object is invoked, but the content of the formal parameter is passed back to the actual parameter when the invoked object completes, if the formal parameter has been initialized during the invocation. The actual parameter is the object evaluated at the time of the invocation.
+
+If the "by value" in the first line is acceptable, we do not need note 1.
+
+I also propose to add Tomas's example to clause 5.4.2, it would clarify what the last sentence refers to.
+
+I don't agree with the new clause in 5.4.2, semantic desription: template variables (formal parameters etc.) shall not be passed to a *value* formal parameter.
+
+Why value variables, formal parameters etc. are not allowed to be passed to template formal parameters? (clauses 5 and 6 of 5.4.2, semantic desription)
+
+
+
+
+
+ + + + + + + + + + +
+ (0013360) +
+ Jacob Wieland - Spirent    +
+ 12-10-2015 16:04    +
(edited on: 12-10-2015 17:21)
+ 		+ + + + +
+ The reason is the contravariance of out parameters. For an out parameter, the formal parameter type must be assignment-compatible to the actual parameter type (the reverse as for in parameters which are co-variant, where the actual parameter type must be assignment-compatible to the formal parameter type).
+
+If a template formal parameter could take a value-actual parameter, this would violate the rule that a value cannot be assigned a template without using valueof (and thus, back-assignment would need an implicit valueof and could fail, if the out parameter was assigned a non-value template).
+
+Likewise, it is no problem to pass a template actual parameter (variable) to an out-value-formal parameter, as an assignment of a value to a template is always allowed (all values are automatically templates).
+
+The rules as they are in the proposal reflect exactly this contravariance.
+
+
+
+
+
+ + + + + + + + + + +
+ (0013367) +
+ Gyorgy Rethy    +
+ 13-10-2015 12:36    +
+ 		+ + + + +
+ Jacob, regarding (template) actual pars for out formal parameters you are rigth.
+
+Please check the proposed text for the definition (in my previous comment and add to the resolution file if you agree.
+
+I think that in the new example swapping the order of e := v; and i := i + 1;
+would better demontrate that the index value of v_roi[i] doesn't change by changing i within the called function.
+
+
+
+ + + + + + + + + + +
+ (0013373) +
+ Jacob Wieland - Spirent    +
+ 13-10-2015 15:31    +
+ 		+ + + + +
+ I have changed 'object evaluated' to 'variable reference evaluated' as I thought this was slightly less ambiguous (though I'm still not 100% happy with it as "evaluated" still suggests reading the content of the variable).
+
+What I would like to express is that the "expression describing the variable that the out-parameter result shall be assigned to is resolved to a variable before the invocation takes place". But since expression has a different meaning in the standard, I'm at a loss for words. Also, this is rather unwieldy. Anyway.
+
+I have also changed the example as you have asked.
+
+
+
+ + + + + + + + + + +
+ (0013374) +
+ Jacob Wieland - Spirent    +
+ 13-10-2015 15:33    +
+ 		+ + + + +
+ pls review again and close
+
+
+
+ + + + + + + + + + +
+ (0013458) +
+ Gyorgy Rethy    +
+ 03-11-2015 10:30    +
+ 		+ + + + +
+ CR7114_resolution_v4.docx: minor editorials in 5.4.2 in parameterization.
+
+
+
+ + + + + + + + + + +
+ (0013578) +
+ Gyorgy Rethy    +
+ 10-12-2015 16:04    +
+ 		+ + + + +
+ Added to draft V4.7.4
+
+ + diff --git a/docs/mantis/CR7115.md b/docs/mantis/CR7115.md new file mode 100644 index 0000000000000000000000000000000000000000..870277a7f1c2325c404969dfb41f257566e39fdb --- /dev/null +++ b/docs/mantis/CR7115.md @@ -0,0 +1,181 @@ + + + + + + + + + + + + + 0007115: Actual parameters of inout formal template parameters - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007115Part 01: TTCN-3 Core LanguageTechnicalpublic28-07-2015 13:4511-12-2015 15:11
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.7.1 (published 2015-06) 
Target Versionv4.8.1 (published 2016-07)Fixed in Versionv4.8.1 (published 2016-07) 
Clause Reference(s)5.4.2
Source (company - Author)STF 487
Summary0007115: Actual parameters of inout formal template parameters
DescriptionThe following rule shall not include variables and formal value parameters:
+
+Actual parameters that are passed to inout formal template parameters shall be variables, template variables, formal value or template parameters (of in, inout or out parameterization) of the current scope or references to elements of (template) variables or formal (template) parameters of structured types.
+
+In its current form, the rule allows to pass a matching symbol to a non-template variable and therefore breaches one of the fundamental principles of TTCN-3. Consider this:
+
+function f(inout template integer p) {
+  p := ?;
+}
+
+control {
+  var integer v;
+  f(v); // allowed, but the variable will contain ? after the call!!!
+}
+
+Proposal: Update the rule in the following way:
+Actual parameters that are passed to inout formal template parameters shall be template variables, formal template parameters (of in, inout or out parameterization) of the current scope or references to elements of template variables or formal template parameters of structured types.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0007114closed Gyorgy Rethy Actual parameters of out formal value parameters not defined 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
28-07-2015 13:45Tomas UrbanNew Issue
28-07-2015 13:52Tomas UrbanNote Added: 0013007
03-08-2015 10:47Gyorgy RethyNote Added: 0013020
03-08-2015 10:47Gyorgy RethyAssigned To => Gyorgy Rethy
03-08-2015 10:47Gyorgy RethyStatusnew => assigned
25-09-2015 10:58Gyorgy RethyTarget Version => v4.8.1 (published 2016-07)
15-10-2015 12:51Jacob Wieland - SpirentRelationship addedrelated to 0007114
15-10-2015 12:51Jacob Wieland - SpirentNote Added: 0013404
15-10-2015 12:52Jacob Wieland - SpirentStatusassigned => resolved
15-10-2015 12:52Jacob Wieland - SpirentResolutionopen => fixed
04-11-2015 14:02Gyorgy RethyFixed in Version => v4.8.1 (published 2016-07)
11-12-2015 15:11Gyorgy RethyNote Added: 0013600
11-12-2015 15:11Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0013007) +
+ Tomas Urban    +
+ 28-07-2015 13:52    +
+ 		+ + + + +
+ Please notice that the proposed solution was already a part of the accepted solution of CR6731, but for some reason it didn't get to the last version of the TTCN-3 core language specification.
+
+
+
+ + + + + + + + + + +
+ (0013020) +
+ Gyorgy Rethy    +
+ 03-08-2015 10:47    +
+ 		+ + + + +
+ STF discussion 03-08-2015: Culd be a potentially backward incompatible change. Ask tool vendors; send out a simple example code and ask for the result.
+
+
+
+ + + + + + + + + + +
+ (0013404) +
+ Jacob Wieland - Spirent    +
+ 15-10-2015 12:51    +
+ 		+ + + + +
+ resolved together with 7114
+
+
+
+ + + + + + + + + + +
+ (0013600) +
+ Gyorgy Rethy    +
+ 11-12-2015 15:11    +
+ 		+ + + + +
+ Resolved in CR 7114
+
+ + diff --git a/docs/mantis/CR7116.md b/docs/mantis/CR7116.md new file mode 100644 index 0000000000000000000000000000000000000000..853d101d65c38db4b952cb5816eec37924b7acae --- /dev/null +++ b/docs/mantis/CR7116.md @@ -0,0 +1,385 @@ + + + + + + + + + + + + + 0007116: Actual parameters of out formal template parameters - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007116Part 01: TTCN-3 Core LanguageTechnicalpublic28-07-2015 14:3114-10-2015 12:44
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.7.1 (published 2015-06) 
Target Versionv4.8.1 (published 2016-07)Fixed in Versionv4.8.1 (published 2016-07) 
Clause Reference(s)5.4.2
Source (company - Author)STF 487
Summary0007116: Actual parameters of out formal template parameters
DescriptionVariables and formal value parameters should not be mentioned in the following rule:
+
+Actual parameters that are passed to out formal template parameters shall be variables, template variables, formal value parameters, formal template parameters or references to elements of variables, template variables, formal value parameters or formal template parameters of structured types.
+
+That's because it allows to assign template to value. Consider the following example:
+
+Actual parameters that are passed to out formal template parameters shall be template variables, formal template parameters or references to elements of template variables or formal template parameters of structured types.
+
+function f(out template integer p) {
+  p := ?;
+}
+
+control {
+  var integer v;
+  f(v); // after the function call, v would contain a matching symbol!!!
+}
+
+Proposal: Change the rule to:
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0007114closed Gyorgy Rethy Actual parameters of out formal value parameters not defined 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
28-07-2015 14:31Tomas UrbanNew Issue
29-07-2015 11:39Tomas UrbanNote Added: 0013009
30-07-2015 10:04Tomas UrbanNote Added: 0013010
03-08-2015 10:46Gyorgy RethyNote Added: 0013019
03-08-2015 10:46Gyorgy RethyAssigned To => Gyorgy Rethy
03-08-2015 10:46Gyorgy RethyStatusnew => assigned
03-08-2015 10:53Tomas UrbanNote Added: 0013021
04-08-2015 11:21Gyorgy RethyNote Edited: 0013019bug_revision_view_page.php?bugnote_id=13019#r139
04-08-2015 11:40Gyorgy RethyNote Added: 0013054
04-08-2015 11:54Gyorgy RethyNote Added: 0013056
04-08-2015 12:56Gyorgy RethyNote Edited: 0013056bug_revision_view_page.php?bugnote_id=13056#r141
04-08-2015 14:58Jacob Wieland - SpirentNote Added: 0013069
06-08-2015 10:16Gyorgy RethyRelationship addedrelated to 0007114
07-08-2015 09:05Jacob Wieland - SpirentStatusassigned => confirmed
25-09-2015 10:58Gyorgy RethyTarget Version => v4.8.1 (published 2016-07)
14-10-2015 12:44Gyorgy RethyNote Added: 0013385
14-10-2015 12:44Gyorgy RethyNote Added: 0013386
14-10-2015 12:44Gyorgy RethyStatusconfirmed => closed
14-10-2015 12:44Gyorgy RethyResolutionopen => fixed
14-10-2015 12:44Gyorgy RethyFixed in Version => v4.8.1 (published 2016-07)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0013009) +
+ Tomas Urban    +
+ 29-07-2015 11:39    +
+ 		+ + + + +
+ The changed rule should be:
+Actual parameters that are passed to out formal template parameters shall be template variables, formal template parameters or references to elements of template variables or formal template parameters of structured types.
+
+
+
+ + + + + + + + + + +
+ (0013010) +
+ Tomas Urban    +
+ 30-07-2015 10:04    +
+ 		+ + + + +
+ It should be also possible to use references to string items as actual parameters of out formal value parameters.
+
+Example:
+
+function f (out charstring p_out) {
+   p_out := "r";
+}
+
+control {
+  var charstring v_str := "test";
+  f(v_str[0]); // similar to assignment such as v_str[0] := "r"
+  log(v_str); // prints "rest"
+}
+
+
+
+ + + + + + + + + + +
+ (0013019) +
+ Gyorgy Rethy    +
+ 03-08-2015 10:46    +
(edited on: 04-08-2015 11:21)
+ 		+ + + + +
+ STF discussion 03-08-2015: Could be a potentially backward incompatible change. Ask tool vendors; send out a simple example code and ask for the result.
+
+
+
+
+
+ + + + + + + + + + +
+ (0013021) +
+ Tomas Urban    +
+ 03-08-2015 10:53    +
+ 		+ + + + +
+ Just a note: In case the STF decides that the references are resolved at the moment of passing of the formal parameter value to the actual parameter (i.e. this is the moment of passing the actual parameter to the formal parameter), the following rule has to be changed so that it doesn't include out parameters anymore: The actual parameters are evaluated in the order of their appearance.
+
+
+
+ + + + + + + + + + +
+ (0013054) +
+ Gyorgy Rethy    +
+ 04-08-2015 11:40    +
+ 		+ + + + +
+ I think your comment is partly correct, I would say the rule should be refined:
+- in fact, the actual parameter itself passed to an out parameter shall not be evaluated when entering the called function (it shall not be an expression anyway, just a "bare" variable that will be overwritten, so evaluating it or not "theoretically", doesn't change anything)
+- but if the actual parameter is a member of an array (of any kind), than the index has to be evaluated to know, which array member is the actual actual :-) parameter; there is no reason to make this evaluation in another order than the general parameter evaluation.
+
+
+
+ + + + + + + + + + +
+ (0013056) +
+ Gyorgy Rethy    +
+ 04-08-2015 11:54    +
(edited on: 04-08-2015 12:56)
+ 		+ + + + +
+ Looking at the CR again, in more detail, in fact the question is if we allow passing value variables to template formal parameters?
+If yes,
+- it may cause runtime error when trying returning a matching mechanism from the function,
+- or an implicit valueof if the formal parameter returns a concrete value,
+but is backward compatible, as this is not forbidden today.
+- and this is true for inout parameters as well...
+
+But if all tools are so cautious that forbids this at the semantic check level, it can also be made explicit in the standard.
+
+One way or another, but some clarification will be needed...
+
+
+
+
+
+ + + + + + + + + + +
+ (0013069) +
+ Jacob Wieland - Spirent    +
+ 04-08-2015 14:58    +
+ 		+ + + + +
+ I have addressed these issues also in the CR 7114 resolution proposal.
+
+But, of course, because of the possible backward incompatibility (in case that an out parameter is declared as template but always filled with a value when used with an actual value parameter), we should still ask the tool vendors about this.
+
+Basically, it should DEFINITELY be an error if an actual value parameter is used for a template formal parameter which is assigned a matching mechanism. The question is only, if it is rejected at compile-time just on the basis of the parameter and type declarations or other inferrable means or if it is rejected at runtime when the out-parameter-template is assigned back to the actual-value-parameter.
+
+
+
+ + + + + + + + + + +
+ (0013385) +
+ Gyorgy Rethy    +
+ 14-10-2015 12:44    +
+ 		+ + + + +
+ Resolved by CR 7114 already
+
+
+
+ + + + + + + + + + +
+ (0013386) +
+ Gyorgy Rethy    +
+ 14-10-2015 12:44    +
+ 		+ + + + +
+ Resolved by CR 7114.
+
+ + diff --git a/docs/mantis/CR7117.md b/docs/mantis/CR7117.md new file mode 100644 index 0000000000000000000000000000000000000000..4878c563d7403f4a90f40e93cf5528f680e84779 --- /dev/null +++ b/docs/mantis/CR7117.md @@ -0,0 +1,878 @@ + + + + + + + + + + + + + 0007117: The order of evaluation of actual and default parameters is not completely set - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007117Part 01: TTCN-3 Core LanguageTechnicalpublic30-07-2015 14:2114-12-2015 13:34
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.7.1 (published 2015-06) 
Target Versionv4.8.1 (published 2016-07)Fixed in Versionv4.8.1 (published 2016-07) 
Clause Reference(s)5.4.2
Source (company - Author)STF 487
Summary0007117: The order of evaluation of actual and default parameters is not completely set
DescriptionThe current specification describes the order of evaluation of actual parameters (order of their appearance) and default parameters (order of the formal parameter list). However, there's no rule specifying the order of evaluation when both actual and default parameters are present in a single parameterized statement.
+
+Proposal: Add the following rule:
+The default parameters are evaluated after all actual parameters have been evaluated.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0007124closed Gyorgy Rethy Semantics of Actual Parameter Assignment Notation ambiguous. 
Attached Filesdocx CR-7117-150805-V1.docx (72,696) 05-08-2015 10:06
http://oldforge.etsi.org/mantis/file_download.php?file_id=3233&type=bug
docx CR-7117-150924-V2.docx (73,021) 24-09-2015 09:49
http://oldforge.etsi.org/mantis/file_download.php?file_id=3276&type=bug
docx CR-7117-150924-V3.docx (92,962) 24-09-2015 10:40
http://oldforge.etsi.org/mantis/file_download.php?file_id=3278&type=bug
Issue History
Date ModifiedUsernameFieldChange
30-07-2015 14:21Tomas UrbanNew Issue
30-07-2015 14:54Jacob Wieland - SpirentNote Added: 0013011
30-07-2015 14:59Tomas UrbanNote Added: 0013012
03-08-2015 10:39Gyorgy RethyNote Added: 0013018
03-08-2015 10:40Gyorgy RethyAssigned To => Jens Grabowski
03-08-2015 10:40Gyorgy RethyStatusnew => assigned
04-08-2015 11:15Jens GrabowskiNote Added: 0013053
05-08-2015 10:05Jens GrabowskiNote Added: 0013075
05-08-2015 10:06Jens GrabowskiFile Added: CR-7117-150805-V1.docx
05-08-2015 10:06Jens GrabowskiAssigned ToJens Grabowski => Jacob Wieland - Spirent
05-08-2015 10:15Tomas UrbanNote Added: 0013076
05-08-2015 10:18Tomas UrbanNote Added: 0013077
05-08-2015 10:32Jacob Wieland - SpirentNote Added: 0013078
05-08-2015 10:34Jacob Wieland - SpirentNote Added: 0013079
05-08-2015 12:03Jacob Wieland - SpirentRelationship addedrelated to 0007124
05-08-2015 12:04Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Jens Grabowski
05-08-2015 12:04Jacob Wieland - SpirentNote Added: 0013084
05-08-2015 12:26Tomas UrbanNote Added: 0013085
05-08-2015 14:32Jacob Wieland - SpirentNote Added: 0013086
05-08-2015 14:56Jacob Wieland - SpirentNote Added: 0013088
05-08-2015 21:06Tomas UrbanNote Added: 0013092
06-08-2015 07:29Jacob Wieland - SpirentNote Added: 0013093
06-08-2015 07:30Jacob Wieland - SpirentNote Added: 0013094
06-08-2015 07:40Tomas UrbanNote Added: 0013095
23-09-2015 13:29Jens GrabowskiNote Added: 0013267
23-09-2015 13:30Jens GrabowskiAssigned ToJens Grabowski => Jacob Wieland - Spirent
23-09-2015 15:09Jacob Wieland - SpirentNote Added: 0013272
23-09-2015 15:12Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Jens Grabowski
24-09-2015 09:49Jens GrabowskiFile Added: CR-7117-150924-V2.docx
24-09-2015 09:50Jens GrabowskiNote Added: 0013283
24-09-2015 09:50Jens GrabowskiAssigned ToJens Grabowski => Jacob Wieland - Spirent
24-09-2015 10:40Jacob Wieland - SpirentFile Added: CR-7117-150924-V3.docx
24-09-2015 10:41Jacob Wieland - SpirentNote Added: 0013285
24-09-2015 10:41Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
24-09-2015 10:41Jacob Wieland - SpirentStatusassigned => confirmed
24-09-2015 16:41Gyorgy RethyTarget Version => v4.8.1 (published 2016-07)
14-10-2015 12:43Gyorgy RethyNote Added: 0013384
03-11-2015 09:27Gyorgy RethyStatusconfirmed => resolved
03-11-2015 09:27Gyorgy RethyFixed in Version => v4.8.1 (published 2016-07)
03-11-2015 09:27Gyorgy RethyResolutionopen => fixed
14-12-2015 13:34Gyorgy RethyNote Added: 0013618
14-12-2015 13:34Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0013011) +
+ Jacob Wieland - Spirent    +
+ 30-07-2015 14:54    +
+ 		+ + + + +
+ I disagree, the parameters should be evaluated in the order of their appearance. If an actual parameter with a corresponding formal parameter with a default is not filled, the default is evaluated in its place.
+
+Basically, writing down a parameter list with left-out actual parameters which have defaults should be semantically the same as the replacement of the missing actual parameters with their defaults.
+
+
+
+ + + + + + + + + + +
+ (0013012) +
+ Tomas Urban    +
+ 30-07-2015 14:59    +
+ 		+ + + + +
+ I have no problem with this proposal. It still solves the original issue.
+
+
+
+ + + + + + + + + + +
+ (0013018) +
+ Gyorgy Rethy    +
+ 03-08-2015 10:39    +
+ 		+ + + + +
+ STF discussion 03-08-2015: Check if current restrictions excludes side effects or not.
+
+
+
+ + + + + + + + + + +
+ (0013053) +
+ Jens Grabowski    +
+ 04-08-2015 11:15    +
+ 		+ + + + +
+ (1) The current restrictions for default values do not exclude side effects. I.e., expressions defining default values need not to adhere to Clause 16.1.4. There are some restrictions for avoiding side effects, e.g., "The expression shall not refer to elements of the component type of the optional runs on clause. The expression shall not refer to other parameters of the same parameter list. The expression shall not contain the invocation of functions with a runs on clause." and for module parameters: "The constant expression for the default value of a module parameter shall respect the limitations given in clause 16.1.4."
+
+(2) The rule referred to by Tomas is:
+"When a formal parameter has been defined with a default value or template, respectively, then it is not necessary to provide an actual parameter. The actual parameters are evaluated in the order of their appearance. If for some formal parameters, no actual parameter has been provided, their default values are taken and evaluated in the order of the formal parameter list."
+I interprete this differently than Tomas due to the word "some" which includes the case where both actual and default parameters are present in a single parameterized statement. In this case my interpretation follows Jacobs understanding that "he parameters should be evaluated in the order of their appearance". However, different interpretations have only effect in case of side effects. A rewording is needed.
+
+(3) We may think of restricting default values, by applying the rules in 16.1.4. As this may have consequences for backwards compatability, I propose to add at least a recommendation that expressions used for the initialization of default values should adhere to 16.1.4 (like the recommendation for constant definitions).
+
+(The issue will be discussed in the STF again.)
+
+
+
+ + + + + + + + + + +
+ (0013075) +
+ Jens Grabowski    +
+ 05-08-2015 10:05    +
+ 		+ + + + +
+ Resolution proposal according to my interpretatation uploaded. Assigned for Proofreading to Jacob.
+
+
+
+ + + + + + + + + + +
+ (0013076) +
+ Tomas Urban    +
+ 05-08-2015 10:15    +
+ 		+ + + + +
+ The proposed resolution is unfortunately not backwards compatible. Let's consider the following code:
+
+type component C {
+  var integer vc_counter := 0;
+}
+
+function f_inc() runs on C return integer {
+  vc_counter := vc_counter + 1;
+  return vc_counter;
+}
+
+function f_test() runs on C {
+  log(p_val1 / p_val2);
+}
+
+testcase TC() runs on C {
+  f_test(p_val2 := f_inc(), p_val1 := f_inc());
+}
+
+Using the current rules (parameters resolved in the order of the actual parameter list), the code logs 2, but using the proposed rules (order of the formal parameter list), the code logs 0.
+
+
+
+ + + + + + + + + + +
+ (0013077) +
+ Tomas Urban    +
+ 05-08-2015 10:18    +
+ 		+ + + + +
+ I am sorry, I submitted the previous note too fast. The function f_test didn't declare the parameters. The correct definition should be:
+
+function f_test(integer p_val1, integer p_val2) runs on C {
+...
+}
+
+
+
+ + + + + + + + + + +
+ (0013078) +
+ Jacob Wieland - Spirent    +
+ 05-08-2015 10:32    +
+ 		+ + + + +
+ I always interpreted the assignment-notation as just syntactic sugar to the list-notation. I am almost sure that the sentence about the evaluation of actual parameters was already in the text before the assignment notation was introduced, i.e. only the list notation existed where the order of formal parameters is the same as the order of actual parameters.
+
+Therefore, the actual parameters would always be evaluated in the order of the formal parameters and the order of appearance in the list-notation would have no impact on that.
+
+I think we have to decide what the intended interpretation of the evaluation order for assignment-notation was and whether this now generates a backward-compatibility problem or not.
+
+
+
+ + + + + + + + + + +
+ (0013079) +
+ Jacob Wieland - Spirent    +
+ 05-08-2015 10:34    +
+ 		+ + + + +
+ In essence, in my view, it is ambiguous for a mapping-notation to talk about order. It can always mean two things: order by key or order by list. Normally, mappings are ordered by keys and the keys here are the parameter names of the formal parameter list. Therefore, with this interpretation, the evaluation order for the assignment-notation would still be the same as for the list-notation, i.e. f(a:=x,b:=y) =^= f(b:=y,a:=x)
+
+
+
+ + + + + + + + + + +
+ (0013084) +
+ Jacob Wieland - Spirent    +
+ 05-08-2015 12:04    +
+ 		+ + + + +
+ solve in tandem with 7124
+
+
+
+ + + + + + + + + + +
+ (0013085) +
+ Tomas Urban    +
+ 05-08-2015 12:26    +
+ 		+ + + + +
+ Assignment notation is used in C# and uses the actual order of parameters and not the order of formal parameters. Why should TTCN-3 behave differently? There should be really a strong reason to deviate from the rules used by standard programming languages.
+
+Besides, normally are statements interpretted in textual order, unless operator priority is involved. I doesn't seem logical that in statement "f_test(p_val2 := f_eval(), p_val1 := f_eval())" "p_val1 := f_eval()" is resolved before "p_val2 := f_eval()".
+
+
+
+ + + + + + + + + + +
+ (0013086) +
+ Jacob Wieland - Spirent    +
+ 05-08-2015 14:32    +
+ 		+ + + + +
+ Sorry, just because a feature introduced into C# in 2011 does it differently (and in my opinion wrongly) than a similar feature in TTCN-3 which, I think, was even introduced earlier doesn't mean much.
+
+For TTCN-3, the assignment notation was always intended as a syntactical shorthand-notation (especially for use with templates with lots of parameters with defaults) where it makes much more sense to first normalize the expression to list-notation (i.e. order parameters, fill holes with defaults) and then evaluate the result.
+
+
+
+ + + + + + + + + + +
+ (0013088) +
+ Jacob Wieland - Spirent    +
+ 05-08-2015 14:56    +
+ 		+ + + + +
+ Anyway, since it is a very obscure case if someone switches the order of the parameters anyway, we could also change it in the way of the textual order. However, this would be backward compatible for the other tools, so there is no perfect solution.
+
+Also, the evaluation then becomes a more difficult procedure:
+
+- evaluate the arguments of the given parameter-assignments.
+- convert the assignment-list into a non-assignment-list, by putting in the order of the formal parameters the evaluated named parameter or the evaluated default value of the parameter, if the parameter was not assigned in the parameter list
+
+It's basically the question: evaluate-convert-evaluate or just convert-evaluate
+
+
+
+ + + + + + + + + + +
+ (0013092) +
+ Tomas Urban    +
+ 05-08-2015 21:06    +
+ 		+ + + + +
+ I would like to repeat that the current rules exactly say which order should be used: "The actual parameters are evaluated in the order of their appearance."
+
+I have discussed the matter with my coleagues and the official position of Elvior is that the rule shouldn't be changed for the three reasons I already mentioned:
+
+1. Backwards incompatibility
+2. Different behaviour compared to programming and scripting languages (its not just C# and VB; Python works in the same way)
+3. Execution in different than textual order doesn't follow the natural order for processing TTCN-3 syntax.
+
+According to the existing rules, assignment notation is not a syntax sugar and it behaves differently than the list notation in some cases as I demonstrated above. The sentence describing the evaluation order was introduced in 4.1.1 i.e. in the same version as the assignment notation itself. The intensions of the STF that introduced the feature might be interesting from a historical point of view, but they are quite irrelevant now. It is the written rules what matter.
+
+The mapping process is an implementation-specific issue. Neither the core language specification nor operational semantics use this term and I cannot see a reason why it should be of any importance when discussing this CR. Besides, I don't think that the assignment list should be converted to the list notation at all. Why can't the TE write the actual values directly to formal parameters when their names are known (as defined in operational semantics in 9.24: In the second step the values of the actual parameter are calculated and assigned to the corresponding field in the call record)?
+
+
+
+ + + + + + + + + + +
+ (0013093) +
+ Jacob Wieland - Spirent    +
+ 06-08-2015 07:29    +
+ 		+ + + + +
+ The deciding factor here is actually section 7.11. in the Operational Semantics:
+
+"If assignment notation has been used for the actual
+parameter list, then the default values are appended to the actual parameters, the order among the default values
+corresponds to their order in the formal parameter list."
+
+From that, you are right and the transformation-before-evaluation interpretation was wrong.
+
+
+
+ + + + + + + + + + +
+ (0013094) +
+ Jacob Wieland - Spirent    +
+ 06-08-2015 07:30    +
+ 		+ + + + +
+ So, in essence, your CR is invalid, as the standard already defines everything clearly, after all ;-)
+
+
+
+ + + + + + + + + + +
+ (0013095) +
+ Tomas Urban    +
+ 06-08-2015 07:40    +
+ 		+ + + + +
+ Great that you found this rule. I hope it is not a big deal to mention it in the core language specification too.
+
+
+
+ + + + + + + + + + +
+ (0013267) +
+ Jens Grabowski    +
+ 23-09-2015 13:29    +
+ 		+ + + + +
+ Jacob: Is the attached resolution ok?
+
+
+
+ + + + + + + + + + +
+ (0013272) +
+ Jacob Wieland - Spirent    +
+ 23-09-2015 15:09    +
+ 		+ + + + +
+ no, the actual parameter resolution is wrong, as according to the operational semantics, given parameters are evaluated as appearing in their textual order and all non-given parameters with default values are evaluated in the formal parameter list order.
+
+
+
+ + + + + + + + + + +
+ (0013283) +
+ Jens Grabowski    +
+ 24-09-2015 09:50    +
+ 		+ + + + +
+ New proposal uploaded, please check.
+
+
+
+ + + + + + + + + + +
+ (0013285) +
+ Jacob Wieland - Spirent    +
+ 24-09-2015 10:41    +
+ 		+ + + + +
+ made small grammatical correction, otherwise fine, please review and resolve
+
+
+
+ + + + + + + + + + +
+ (0013384) +
+ Gyorgy Rethy    +
+ 14-10-2015 12:43    +
+ 		+ + + + +
+ STF discussion: no problem to define order of default parameter evaluation after evaluating the actual parameters
+
+
+
+ + + + + + + + + + +
+ (0013618) +
+ Gyorgy Rethy    +
+ 14-12-2015 13:34    +
+ 		+ + + + +
+ Added to draft V4.7.4
+
+ + diff --git a/docs/mantis/CR7118.md b/docs/mantis/CR7118.md new file mode 100644 index 0000000000000000000000000000000000000000..75e5211a8bc67a917dfb841f04c2cbe400c0c11c --- /dev/null +++ b/docs/mantis/CR7118.md @@ -0,0 +1,231 @@ + + + + + + + + + + + + + 0007118: Not clear when actual parameter passing occurs - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007118Part 01: TTCN-3 Core LanguageTechnicalpublic31-07-2015 11:1803-11-2015 09:44
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.7.1 (published 2015-06) 
Target Versionv4.8.1 (published 2016-07)Fixed in Versionv4.8.1 (published 2016-07) 
Clause Reference(s)5.4.2
Source (company - Author)STF 487
Summary0007118: Not clear when actual parameter passing occurs
DescriptionThe current rules for actual parameters use the term "actual parameter passing" in several places. It is described how it works (the scope, involved objects etc.), but not when it occurs (or at least not explicitly).
+
+Although not specified explicitly, the moment of actual parameter passing is set by the other rules for in and inout parameters - it has to occur before entering the parameterized content, i.e. before the bounding process specified in the section 3.1.
+
+However, the situation is ambiguous in case of out parameters. The actual parameter value is not needed inside the parameterized content and there are rules saying that passing of the formal parameter to the actual parameter (which is not the same as actual parameter passing) occurs after invocation of the parameterized object. The question is then whether actual parameter passing occurs at this point (at the end of the invocation) or before invocation.
+
+Consider the following example:
+    type component GeneralComp {
+        var integer vc_index := 0;
+    }
+    
+    type record of integer RI;
+    
+    function f_test(out integer p_par1) runs on GeneralComp {
+        vc_index := 1;
+        p_par1 := 10;
+    }
+    
+    testcase TC_Sem_050402_actual_parameters_168() runs on GeneralComp {
+        var RI v_ri := { 1, 2 }
+        f_test(v_ri[vc_index]); // tested parameter passing
+        log(v_ri); // will we get { 1, 10 } or { 10, 2 } ?
+    }
+
+In my opinion, the actual parameter passing shall occur at the moment of invocation, thus the example above should produce { 10, 2 }.
+
+In order to remove all possible ambiguities, I propose to add the following sentence to the section 5.4.2:
+
+Actual parameters are passed to formal parameters before invoking the parametrized object.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0007114closed Gyorgy Rethy Actual parameters of out formal value parameters not defined 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
31-07-2015 11:18Tomas UrbanNew Issue
03-08-2015 09:40Gyorgy RethyNote Added: 0013013
03-08-2015 09:57Tomas UrbanNote Added: 0013014
03-08-2015 10:28Gyorgy RethyNote Added: 0013016
03-08-2015 10:29Gyorgy RethyAssigned To => Jacob Wieland - Spirent
03-08-2015 10:29Gyorgy RethyStatusnew => assigned
04-08-2015 14:36Jacob Wieland - SpirentNote Added: 0013065
04-08-2015 14:36Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
04-08-2015 14:36Jacob Wieland - SpirentStatusassigned => confirmed
04-08-2015 14:36Jacob Wieland - SpirentRelationship addedrelated to 0007114
25-09-2015 10:58Gyorgy RethyTarget Version => v4.8.1 (published 2016-07)
03-11-2015 09:44Gyorgy RethyNote Added: 0013452
03-11-2015 09:44Gyorgy RethyStatusconfirmed => closed
03-11-2015 09:44Gyorgy RethyResolutionopen => fixed
03-11-2015 09:44Gyorgy RethyFixed in Version => v4.8.1 (published 2016-07)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0013013) +
+ Gyorgy Rethy    +
+ 03-08-2015 09:40    +
+ 		+ + + + +
+ I think that out parameters return values are passed back to the calling entity at the moment when the called function reaches its end or return. Shall be checked the standard's text if the moment of passing parameter values back is specified.
+
+
+
+ + + + + + + + + + +
+ (0013014) +
+ Tomas Urban    +
+ 03-08-2015 09:57    +
+ 		+ + + + +
+ The problem raised within this CR is not about passing the value to the out parameter. This is clear and well specified. The issue concerns the fact that it is not know when the "binding" between the actual and formal parameter occurs (actual parameter passing is the TTCN-3 term used for this binding) - whether it is before the parameterized statements starts execution or after that.
+
+The issue is important, because the reference used as an actual parameter might contain items (such as array indexes) that can be changed within the parameterized content. The problem with the reference containing an index is demonstrated in the example attached to the original CR.
+
+In case of mainstream programming languages, out parameters are used e.g. in C# where references used as actual parameters are resolved before executing parameterized content and not at the moment of value assignment from the formal parameter to the actual parameter. I would expect the same behaviour from TTCN-3.
+
+
+
+ + + + + + + + + + +
+ (0013016) +
+ Gyorgy Rethy    +
+ 03-08-2015 10:28    +
+ 		+ + + + +
+ STF discussion 03-08-2015: Check possible unambiguity and add text if needed. Add the example even if no unambiguity is identified.
+
+
+
+ + + + + + + + + + +
+ (0013065) +
+ Jacob Wieland - Spirent    +
+ 04-08-2015 14:36    +
+ 		+ + + + +
+ see resolution proposal CR 7114
+
+
+
+ + + + + + + + + + +
+ (0013452) +
+ Gyorgy Rethy    +
+ 03-11-2015 09:44    +
+ 		+ + + + +
+ Resolution can be found in CR7114
+
+ + diff --git a/docs/mantis/CR7119.md b/docs/mantis/CR7119.md new file mode 100644 index 0000000000000000000000000000000000000000..c53a576b8d60dfc8a15dbef93c361a00e3c922e8 --- /dev/null +++ b/docs/mantis/CR7119.md @@ -0,0 +1,135 @@ + + + + + + + + + + + + + 0007119: Out parameter rule inside a note - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007119Part 01: TTCN-3 Core LanguageTechnicalpublic31-07-2015 11:3403-11-2015 09:44
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.7.1 (published 2015-06) 
Target Versionv4.8.1 (published 2016-07)Fixed in Versionv4.8.1 (published 2016-07) 
Clause Reference(s)3.1, 5.4.2
Source (company - Author)STF 487
Summary0007119: Out parameter rule inside a note
DescriptionThe section 3.1 contains a definition of out parameterization. This definition contains NOTE 4 describing the TE behaviour in cases when the out formal parameter hasn't been initialized during invocation of a parameterized object.
+
+The problem is that this note is not supported by any formal rule further in the text. It is important to specify the rule, because otherwise the rules for handling uninitialized values should apply to this case, producing an error.
+
+Proposal: The note shall be changed into a formal rule in the chapter 5.4.2
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0007114closed Gyorgy Rethy Actual parameters of out formal value parameters not defined 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
31-07-2015 11:34Tomas UrbanNew Issue
03-08-2015 10:18Gyorgy RethyAssigned To => Jacob Wieland - Spirent
03-08-2015 10:18Gyorgy RethyStatusnew => assigned
03-08-2015 10:20Gyorgy RethyNote Added: 0013015
04-08-2015 14:37Jacob Wieland - SpirentNote Added: 0013066
04-08-2015 14:37Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
04-08-2015 14:37Jacob Wieland - SpirentStatusassigned => confirmed
04-08-2015 14:37Jacob Wieland - SpirentRelationship addedrelated to 0007114
25-09-2015 10:58Gyorgy RethyTarget Version => v4.8.1 (published 2016-07)
03-11-2015 09:44Gyorgy RethyNote Added: 0013453
03-11-2015 09:44Gyorgy RethyStatusconfirmed => closed
03-11-2015 09:44Gyorgy RethyResolutionopen => fixed
03-11-2015 09:44Gyorgy RethyFixed in Version => v4.8.1 (published 2016-07)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0013015) +
+ Gyorgy Rethy    +
+ 03-08-2015 10:20    +
+ 		+ + + + +
+ STF discussion 03-08-2015: comment agreed, check main text and move the note if no relevant rule exits; text has to be both in clauses in value and template formal parameers.
+
+
+
+ + + + + + + + + + +
+ (0013066) +
+ Jacob Wieland - Spirent    +
+ 04-08-2015 14:37    +
+ 		+ + + + +
+ see resolution proposal CR 7114
+
+
+
+ + + + + + + + + + +
+ (0013453) +
+ Gyorgy Rethy    +
+ 03-11-2015 09:44    +
+ 		+ + + + +
+ Resolution can be found in CR7114
+
+ + diff --git a/docs/mantis/CR7120.md b/docs/mantis/CR7120.md new file mode 100644 index 0000000000000000000000000000000000000000..67264e851b66a7795a64f98d1abc798c5b4cbafa --- /dev/null +++ b/docs/mantis/CR7120.md @@ -0,0 +1,202 @@ + + + + + + + + + + + + + 0007120: Missing restriction on number of parameters in list notation - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007120Part 01: TTCN-3 Core LanguageTechnicalpublic03-08-2015 10:2311-12-2015 15:10
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.7.1 (published 2015-06) 
Target Versionv4.8.1 (published 2016-07)Fixed in Versionv4.8.1 (published 2016-07) 
Clause Reference(s)5.4.2
Source (company - Author)STF 487
Summary0007120: Missing restriction on number of parameters in list notation
DescriptionThe restriction a in 5.4.2 on list notation doesn't explicitly say that the number of actual parameters may not exceed the number of formal parameters. Although it seems obvious, this rule is currently not formally specified and cannot be tested in conformance tests. There's also a possibility to interpret the rules in such a way that excessive parameters are simply ignored.
+
+Proposal:
+Add the following sentence to the restriction a: The number of actual parameters in the list notation may not exceed the number of parameters in the formal parameter list.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7120_resolution_v1.docx (26,733) 06-08-2015 09:39
http://oldforge.etsi.org/mantis/file_download.php?file_id=3240&type=bug
Issue History
Date ModifiedUsernameFieldChange
03-08-2015 10:23Tomas UrbanNew Issue
03-08-2015 10:28Gyorgy RethyAssigned To => Jacob Wieland - Spirent
03-08-2015 10:28Gyorgy RethyStatusnew => assigned
03-08-2015 10:30Gyorgy RethyNote Added: 0013017
03-08-2015 10:31Gyorgy RethyAssigned ToJacob Wieland - Spirent => Axel Rennoch
06-08-2015 09:39Axel RennochFile Added: CR7120_resolution_v1.docx
06-08-2015 09:41Axel RennochNote Added: 0013103
06-08-2015 09:43Axel RennochNote Added: 0013104
06-08-2015 09:43Axel RennochAssigned ToAxel Rennoch => Jacob Wieland - Spirent
06-08-2015 09:43Axel RennochStatusassigned => acknowledged
06-08-2015 11:10Jacob Wieland - SpirentNote Added: 0013109
06-08-2015 11:10Jacob Wieland - SpirentStatusacknowledged => resolved
06-08-2015 11:10Jacob Wieland - SpirentResolutionopen => fixed
06-08-2015 11:10Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
04-11-2015 14:00Gyorgy RethyTarget Version => v4.8.1 (published 2016-07)
04-11-2015 14:02Gyorgy RethyFixed in Version => v4.8.1 (published 2016-07)
11-12-2015 15:10Gyorgy RethyNote Added: 0013599
11-12-2015 15:10Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0013017) +
+ Gyorgy Rethy    +
+ 03-08-2015 10:30    +
+ 		+ + + + +
+ STF discussion 03-08-2015: Check in the text and add rule if needed.
+
+
+
+ + + + + + + + + + +
+ (0013103) +
+ Axel Rennoch    +
+ 06-08-2015 09:41    +
+ 		+ + + + +
+ Currently "ignoring" parameters is specified in the context of signature templates only. But additional actual parameters indicate a conflict with the parameter list and should not be allowed. Thus the proposed rule has been added to the restriction "a" as proposed before.
+
+
+
+ + + + + + + + + + +
+ (0013104) +
+ Axel Rennoch    +
+ 06-08-2015 09:43    +
+ 		+ + + + +
+ Please have a look to the draft proposed resolution and justification in the note.
+
+
+
+ + + + + + + + + + +
+ (0013109) +
+ Jacob Wieland - Spirent    +
+ 06-08-2015 11:10    +
+ 		+ + + + +
+ looks good to me
+
+
+
+ + + + + + + + + + +
+ (0013599) +
+ Gyorgy Rethy    +
+ 11-12-2015 15:10    +
+ 		+ + + + +
+ Added to draft V4.7.4
+
+ + diff --git a/docs/mantis/CR7121.md b/docs/mantis/CR7121.md new file mode 100644 index 0000000000000000000000000000000000000000..ece4518260423647b0a859e5ff1ebf31cf90b590 --- /dev/null +++ b/docs/mantis/CR7121.md @@ -0,0 +1,63 @@ + + + + + + + + + + + + + 0007121: Restriction on the use of union alternatives as inout parameters shall be extended to anytype - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007121Part 01: TTCN-3 Core LanguageTechnicalpublic04-08-2015 10:5304-11-2015 14:13
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionno change required 
PlatformOSOS Version
Product Versionv4.7.1 (published 2015-06) 
Target Versionv4.8.1 (published 2016-07)Fixed in Versionv4.8.1 (published 2016-07) 
Clause Reference(s)5.4.2
Source (company - Author)STF 487
Summary0007121: Restriction on the use of union alternatives as inout parameters shall be extended to anytype
DescriptionRestriction n of 5.4.2 shall be extended to include the anytype. The reasoning is similar as for the union alternatives: to avoid problems with inactive anytype content, uninitialized values and selected type activation/deactivation through the formal parameter.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
04-08-2015 10:53Tomas UrbanNew Issue
04-08-2015 11:56Tomas UrbanNote Added: 0013057
05-08-2015 12:02Jacob Wieland - SpirentStatusnew => resolved
05-08-2015 12:02Jacob Wieland - SpirentResolutionopen => no change required
05-08-2015 12:02Jacob Wieland - SpirentAssigned To => Jacob Wieland - Spirent
16-10-2015 13:28Jacob Wieland - SpirentStatusresolved => feedback
16-10-2015 13:28Jacob Wieland - SpirentResolutionno change required => reopened
16-10-2015 13:28Jacob Wieland - SpirentStatusfeedback => resolved
16-10-2015 13:28Jacob Wieland - SpirentFixed in Version => v4.8.1 (published 2016-07)
16-10-2015 13:28Jacob Wieland - SpirentResolutionreopened => fixed
16-10-2015 13:28Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
16-10-2015 13:28Jacob Wieland - SpirentStatusresolved => closed
04-11-2015 14:13Gyorgy RethyResolutionfixed => no change required
04-11-2015 14:13Gyorgy RethyTarget Version => v4.8.1 (published 2016-07)
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0013057) +
+ Tomas Urban    +
+ 04-08-2015 11:56    +
+ 		+ + + + +
+ Please remove this issue as invalid. Anytype is actually mentioned. For some reason I missed it. I am very sorry.
+
+ + diff --git a/docs/mantis/CR7122.md b/docs/mantis/CR7122.md new file mode 100644 index 0000000000000000000000000000000000000000..c3c991af9de5c83b4b1f7b0af04aac5f3513c876 --- /dev/null +++ b/docs/mantis/CR7122.md @@ -0,0 +1,167 @@ + + + + + + + + + + + + + 0007122: Signatures should not be mentioned in the rules on actual parameters - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007122Part 01: TTCN-3 Core LanguageTechnicalpublic04-08-2015 11:4615-12-2015 09:49
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.7.1 (published 2015-06) 
Target Versionv4.8.1 (published 2016-07)Fixed in Versionv4.8.1 (published 2016-07) 
Clause Reference(s)5.4.2
Source (company - Author)STF 487
Summary0007122: Signatures should not be mentioned in the rules on actual parameters
DescriptionIn the section 5.4.2, the restrictions g and h mention signatures. While signatures do have formal parameters, the term "parameter" means something different in this case than what is described in the section 5.4. (Template semantics is used for actual parameters). There's also an appropriate note regarding this in the table 2.
+
+For this reason, the section 5.4.2 shall not mention signatures at all. The word "signature" shall be dropped from the restriction g an the restriction h shall be removed completely.
Steps To Reproduce
Additional Information
Tagstechnically agreed
Relationships
Attached Filesdocx CR7122_resolution_v1.docx (86,023) 12-10-2015 16:18
http://oldforge.etsi.org/mantis/file_download.php?file_id=3297&type=bug
Issue History
Date ModifiedUsernameFieldChange
04-08-2015 11:46Tomas UrbanNew Issue
21-09-2015 10:27Gyorgy RethyTarget Version => v4.8.1 (published 2016-07)
21-09-2015 14:01Gyorgy RethyNote Added: 0013204
21-09-2015 14:01Gyorgy RethyTag Attached: technically agreed
12-10-2015 15:36Axel RennochAssigned To => Axel Rennoch
12-10-2015 15:36Axel RennochStatusnew => assigned
12-10-2015 16:18Axel RennochFile Added: CR7122_resolution_v1.docx
12-10-2015 16:19Axel RennochAssigned ToAxel Rennoch =>
12-10-2015 16:20Axel RennochNote Added: 0013361
12-10-2015 16:20Axel RennochAssigned To => Jacob Wieland - Spirent
12-10-2015 16:20Axel RennochStatusassigned => acknowledged
13-10-2015 11:21Jacob Wieland - SpirentNote Added: 0013364
13-10-2015 11:21Jacob Wieland - SpirentStatusacknowledged => resolved
13-10-2015 11:21Jacob Wieland - SpirentFixed in Version => v4.8.1 (published 2016-07)
13-10-2015 11:21Jacob Wieland - SpirentResolutionopen => fixed
16-10-2015 13:22Jacob Wieland - SpirentStatusresolved => feedback
16-10-2015 13:22Jacob Wieland - SpirentResolutionfixed => reopened
16-10-2015 13:22Jacob Wieland - SpirentStatusfeedback => resolved
16-10-2015 13:22Jacob Wieland - SpirentResolutionreopened => fixed
16-10-2015 13:22Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
15-12-2015 09:49Gyorgy RethyNote Added: 0013631
15-12-2015 09:49Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0013204) +
+ Gyorgy Rethy    +
+ 21-09-2015 14:01    +
+ 		+ + + + +
+ STF discussion: proposal accepted, but put a note saying that signatures also have parameters, they handling see in clauses ...
+
+
+
+ + + + + + + + + + +
+ (0013361) +
+ Axel Rennoch    +
+ 12-10-2015 16:20    +
+ 		+ + + + +
+ Please check uploaded resolution_v1.
+
+
+
+ + + + + + + + + + +
+ (0013364) +
+ Jacob Wieland - Spirent    +
+ 13-10-2015 11:21    +
+ 		+ + + + +
+ resolved according to what has been discussed
+
+
+
+ + + + + + + + + + +
+ (0013631) +
+ Gyorgy Rethy    +
+ 15-12-2015 09:49    +
+ 		+ + + + +
+ Added to draft V4.7.4
+
+ + diff --git a/docs/mantis/CR7123.md b/docs/mantis/CR7123.md new file mode 100644 index 0000000000000000000000000000000000000000..8b3f0b073bf0d34cab45f6ef12124d5f1550ed67 --- /dev/null +++ b/docs/mantis/CR7123.md @@ -0,0 +1,271 @@ + + + + + + + + + + + + + 0007123: Type parameterization in examples - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007123Part 01: TTCN-3 Core LanguageEditorialpublic04-08-2015 12:1011-12-2015 14:35
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.7.1 (published 2015-06) 
Target Versionv4.8.1 (published 2016-07)Fixed in Versionv4.8.1 (published 2016-07) 
Clause Reference(s)5.4.2
Source (company - Author)STF 487
Summary0007123: Type parameterization in examples
DescriptionThe example 4 in 5.4.2 includes a record type definition and its use as a demonstration of the restriction g. While technically correct, it is a relict from the time when the core language specification allowed type parametrization. This feature has been moved to an extension package long time ago, but the example was left unchanged.
+
+In the current specification, the example doesn't make much sense as types are always without parameters. The restriction should be demonstrated using another object that can be parametrized, but doesn't contain parentheses if there are no parameters: a template.
Steps To Reproduce
Additional Information
Tagstechnically agreed
Relationships
Attached Filesdocx CR7123_resolution_v1.docx (32,977) 23-09-2015 08:16
http://oldforge.etsi.org/mantis/file_download.php?file_id=3261&type=bug
docx CR7123_resolution_v2.docx (33,729) 23-09-2015 13:21
http://oldforge.etsi.org/mantis/file_download.php?file_id=3271&type=bug
Issue History
Date ModifiedUsernameFieldChange
04-08-2015 12:10Tomas UrbanNew Issue
21-09-2015 10:27Gyorgy RethyTarget Version => v4.8.1 (published 2016-07)
21-09-2015 14:11Gyorgy RethyNote Added: 0013205
21-09-2015 14:17Gyorgy RethyTag Attached: technically agreed
22-09-2015 15:58Axel RennochAssigned To => Axel Rennoch
22-09-2015 15:58Axel RennochStatusnew => assigned
23-09-2015 08:16Axel RennochFile Added: CR7123_resolution_v1.docx
23-09-2015 08:18Axel RennochNote Added: 0013244
23-09-2015 08:18Axel RennochAssigned ToAxel Rennoch => Jacob Wieland - Spirent
23-09-2015 08:18Axel RennochStatusassigned => acknowledged
23-09-2015 12:07Jacob Wieland - SpirentNote Added: 0013259
23-09-2015 12:08Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Axel Rennoch
23-09-2015 12:08Jacob Wieland - SpirentStatusacknowledged => assigned
23-09-2015 13:21Axel RennochFile Added: CR7123_resolution_v2.docx
23-09-2015 13:22Axel RennochNote Added: 0013265
23-09-2015 13:22Axel RennochAssigned ToAxel Rennoch => Jacob Wieland - Spirent
23-09-2015 13:22Axel RennochStatusassigned => acknowledged
23-09-2015 15:05Jacob Wieland - SpirentNote Added: 0013270
23-09-2015 15:05Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Axel Rennoch
23-09-2015 15:05Jacob Wieland - SpirentStatusacknowledged => assigned
23-09-2015 15:12Axel RennochNote Added: 0013274
23-09-2015 15:12Axel RennochStatusassigned => resolved
23-09-2015 15:12Axel RennochResolutionopen => fixed
23-09-2015 15:12Axel RennochAssigned ToAxel Rennoch => Gyorgy Rethy
04-11-2015 14:02Gyorgy RethyFixed in Version => v4.8.1 (published 2016-07)
11-12-2015 14:35Gyorgy RethyNote Added: 0013591
11-12-2015 14:35Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0013205) +
+ Gyorgy Rethy    +
+ 21-09-2015 14:11    +
+ 		+ + + + +
+ STF discussion: Add use of the non-parameterized template with an explaining comment.
+
+
+
+ + + + + + + + + + +
+ (0013244) +
+ Axel Rennoch    +
+ 23-09-2015 08:18    +
+ 		+ + + + +
+ Please check the modification.
+
+
+
+ + + + + + + + + + +
+ (0013259) +
+ Jacob Wieland - Spirent    +
+ 23-09-2015 12:07    +
+ 		+ + + + +
+ this example confuses more than it helps, there is no empty formal parameter list (there is no formal parameter list).
+
+I propose to simply delete that part of the example.
+
+
+
+ + + + + + + + + + +
+ (0013265) +
+ Axel Rennoch    +
+ 23-09-2015 13:22    +
+ 		+ + + + +
+ How about another example using a default?
+
+
+
+ + + + + + + + + + +
+ (0013270) +
+ Jacob Wieland - Spirent    +
+ 23-09-2015 15:05    +
+ 		+ + + + +
+ I don't know, you mean a default parameter? Sure, why not.
+
+
+
+ + + + + + + + + + +
+ (0013274) +
+ Axel Rennoch    +
+ 23-09-2015 15:12    +
+ 		+ + + + +
+ The old sample has been replaced with a new sample that covers default parameters in templates, too.
+
+
+
+ + + + + + + + + + +
+ (0013591) +
+ Gyorgy Rethy    +
+ 11-12-2015 14:35    +
+ 		+ + + + +
+ Added to draft V4.7.4
+
+ + diff --git a/docs/mantis/CR7124.md b/docs/mantis/CR7124.md new file mode 100644 index 0000000000000000000000000000000000000000..47c5109cf6bae8024d6b70cb260e7252a8a4350f --- /dev/null +++ b/docs/mantis/CR7124.md @@ -0,0 +1,185 @@ + + + + + + + + + + + + + 0007124: Semantics of Actual Parameter Assignment Notation ambiguous. - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007124Part 01: TTCN-3 Core LanguageClarificationpublic05-08-2015 11:5213-10-2015 12:22
ReporterJacob Wieland - Spirent 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.7.1 (published 2015-06) 
Target Versionv4.8.1 (published 2016-07)Fixed in Versionv4.8.1 (published 2016-07) 
Clause Reference(s)5.4.2
Source (company - Author)Testing Technologies - Jacob Wieland
Summary0007124: Semantics of Actual Parameter Assignment Notation ambiguous.
DescriptionAt the moment, the intended equivalency between an actual parameter list in assignment notation and an actual parameter list in list notation is not clearly stated in the standard.
+
+The assignment notation is just supposed to be a syntactical shorthand notation
+for a list notation where the assigned actual parameters are filled with the right-hand-side of the assignment and the actual parameters for all unassigned formal parameters are filled with their default values.
+
+This will resolve tool-ambiguity between tools that already interpret assignment-notation in the way described above and those that evaluate assignment-notation in the textual order of assignments (instead of the order of definition in the formal parameter list.
Steps To Reproduce
Additional InformationThe semantic description of 5.4.2 should be sub-structured into several named paragraphs, e.g.
+
+- Assignment-Notation
+- Evaluation (including
+-- evaluation order
+-- lazy/fuzzy parameters
+-- evaluation of out/inout parameters as left-hand-side expressions (with automatic left-hand-side-expansion)
+-- passing back of out-parameters to actual parameters
+)
+- In, Out and Inout Parameters
+- Default Parameters
+- Special Parameters (Timers, Ports)
+
+(not necessarily in that order)
TagsNo tags attached.
Relationships
related to 0007117closed Gyorgy Rethy The order of evaluation of actual and default parameters is not completely set 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
05-08-2015 11:52Jacob Wieland - SpirentNew Issue
05-08-2015 11:52Jacob Wieland - SpirentStatusnew => assigned
05-08-2015 11:52Jacob Wieland - SpirentAssigned To => Jens Grabowski
05-08-2015 12:03Jacob Wieland - SpirentRelationship addedrelated to 0007117
23-09-2015 13:32Jens GrabowskiNote Added: 0013268
23-09-2015 13:32Jens GrabowskiAssigned ToJens Grabowski => Jacob Wieland - Spirent
23-09-2015 15:11Jacob Wieland - SpirentNote Added: 0013273
23-09-2015 15:12Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Jens Grabowski
24-09-2015 16:23Jacob Wieland - SpirentNote Added: 0013297
24-09-2015 16:23Jacob Wieland - SpirentAssigned ToJens Grabowski => Gyorgy Rethy
24-09-2015 16:23Jacob Wieland - SpirentStatusassigned => confirmed
13-10-2015 12:20Gyorgy RethyProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
13-10-2015 12:20Gyorgy RethyProduct Version => v4.7.1 (published 2015-06)
13-10-2015 12:20Gyorgy RethyTarget Version => v4.8.1 (published 2016-07)
13-10-2015 12:22Gyorgy RethyNote Added: 0013366
13-10-2015 12:22Gyorgy RethyStatusconfirmed => closed
13-10-2015 12:22Gyorgy RethyResolutionopen => fixed
13-10-2015 12:22Gyorgy RethyFixed in Version => v4.8.1 (published 2016-07)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0013268) +
+ Jens Grabowski    +
+ 23-09-2015 13:32    +
+ 		+ + + + +
+ Jacob: Is this resolved with the resolution of CR 7117?
+
+I don't see the need of restructuring 5.4.2. Your proposal for the restructuring seems also to include parts which go beyond pure restructuring?
+
+
+
+ + + + + + + + + + +
+ (0013273) +
+ Jacob Wieland - Spirent    +
+ 23-09-2015 15:11    +
+ 		+ + + + +
+ no, (see my last Note there). Basically, the original text should be changed to mention textual order of appearance and then adding the missing parameters with defaults at the end.
+
+
+
+ + + + + + + + + + +
+ (0013297) +
+ Jacob Wieland - Spirent    +
+ 24-09-2015 16:23    +
+ 		+ + + + +
+ resolved in 7117
+
+
+
+ + + + + + + + + + +
+ (0013366) +
+ Gyorgy Rethy    +
+ 13-10-2015 12:22    +
+ 		+ + + + +
+ Resolved by CR7117
+
+ + diff --git a/docs/mantis/CR7125.md b/docs/mantis/CR7125.md new file mode 100644 index 0000000000000000000000000000000000000000..6b24a242c05333d921c040768839b3348dc689e5 --- /dev/null +++ b/docs/mantis/CR7125.md @@ -0,0 +1,200 @@ + + + + + + + + + + + + + 0007125: Nillable section needs correction - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007125Part 09: Using XML with TTCN-3Technicalpublic05-08-2015 12:0307-08-2015 11:00
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.6.1 (published 2015-06) 
Target Versionv4.7.1 (published 2016-07)Fixed in Versionv4.7.1 (published 2016-07) 
Clause Reference(s)7.1.4, 7.1.11, B.3.15
For STF discussion
Source (company - Author)L.M.Ericsson
Summary0007125: Nillable section needs correction
Description- Example 2 in clause 7.1.11 need to be corrected (see proposal in attachment)
+- The textual description of translating nillable elements needs to be simplified to improve readibility (see proposal in attachment)
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR_nillable_proposed_solution.docx (79,699) 05-08-2015 12:03
http://oldforge.etsi.org/mantis/file_download.php?file_id=3234&type=bug
docx CR_nillable_proposed_solution_v2.docx (87,002) 06-08-2015 11:48
http://oldforge.etsi.org/mantis/file_download.php?file_id=3244&type=bug
docx CR_nillable_proposed_solution_v3.docx (88,001) 07-08-2015 10:01
http://oldforge.etsi.org/mantis/file_download.php?file_id=3251&type=bug
Issue History
Date ModifiedUsernameFieldChange
05-08-2015 12:03Gyorgy RethyNew Issue
05-08-2015 12:03Gyorgy RethyFile Added: CR_nillable_proposed_solution.docx
06-08-2015 09:03Gyorgy RethyAssigned To => Axel Rennoch
06-08-2015 09:03Gyorgy RethyStatusnew => assigned
06-08-2015 09:18Gyorgy RethyTarget Version => v4.7.1 (published 2016-07)
06-08-2015 11:48Axel RennochFile Added: CR_nillable_proposed_solution_v2.docx
06-08-2015 11:51Axel RennochNote Added: 0013113
06-08-2015 11:51Axel RennochNote Added: 0013114
06-08-2015 11:51Axel RennochAssigned ToAxel Rennoch => Gyorgy Rethy
06-08-2015 11:51Axel RennochStatusassigned => acknowledged
07-08-2015 10:00Gyorgy RethyNote Added: 0013129
07-08-2015 10:01Gyorgy RethyNote Added: 0013130
07-08-2015 10:01Gyorgy RethyStatusacknowledged => resolved
07-08-2015 10:01Gyorgy RethyFixed in Version => v4.7.1 (published 2016-07)
07-08-2015 10:01Gyorgy RethyResolutionopen => fixed
07-08-2015 10:01Gyorgy RethyFile Added: CR_nillable_proposed_solution_v3.docx
07-08-2015 11:00Gyorgy RethyNote Added: 0013137
07-08-2015 11:00Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0013113) +
+ Axel Rennoch    +
+ 06-08-2015 11:51    +
+ 		+ + + + +
+ file upload with some little typo corrections and rewording in text proposal
+
+
+
+ + + + + + + + + + +
+ (0013114) +
+ Axel Rennoch    +
+ 06-08-2015 11:51    +
+ 		+ + + + +
+ please check if the rewording is correct
+
+
+
+ + + + + + + + + + +
+ (0013129) +
+ Gyorgy Rethy    +
+ 07-08-2015 10:00    +
+ 		+ + + + +
+ Some further minor editorial corrections in CR_nillable_proposed_solution_v3.docx
+
+
+
+ + + + + + + + + + +
+ (0013130) +
+ Gyorgy Rethy    +
+ 07-08-2015 10:01    +
+ 		+ + + + +
+ Changes are implemented in interim draft V4.6.2
+
+
+
+ + + + + + + + + + +
+ (0013137) +
+ Gyorgy Rethy    +
+ 07-08-2015 11:00    +
+ 		+ + + + +
+ Implemented in interim draft V4.6.2 (file es_20187309v040603_v4.docx in CR7084)
+
+ + diff --git a/docs/mantis/CR7126.md b/docs/mantis/CR7126.md new file mode 100644 index 0000000000000000000000000000000000000000..442d4385fd99f66aebaaa6598e2c69abcbd1daf5 --- /dev/null +++ b/docs/mantis/CR7126.md @@ -0,0 +1,365 @@ + + + + + + + + + + + + + 0007126: Semantics of anytype not really usable - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007126Part 01: TTCN-3 Core LanguageTechnicalpublic05-08-2015 13:0216-11-2016 09:47
ReporterJacob Wieland - Spirent 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.7.1 (published 2015-06) 
Target Versionv4.8.1 (published 2016-07)Fixed in Versionv4.8.1 (published 2016-07) 
Clause Reference(s)6, A.1.6.8.3
Source (company - Author)Testing Technologies - Jacob Wieland
Summary0007126: Semantics of anytype not really usable
DescriptionThe anytype in its current semantic definition includes only those top-level types that are visible at the place of its usage, i.e. all imported top-level types and all locally defined top-level types. This makes it quite unusable for any kind of library function defined on objects of type anytype. Also, this restrictive semantics is very dissimilar to the semantics of the same concept in imported external languages which are normally mapped to anytype.
+
+Its semantic should be changed that it can contain a value of any top-level type and that only the syntax of anytype values/template and referencing anytype value/template-contents shall be restricted to the types known in the context of usage.
+
+The reason for this is that the anytype in TTCN-3 should be a similar concept the open types in other languages mapped to it (which include ASN.1 ANY, IDL any, XSD any/anyType (possibly)).
+
+Additionally, one could think of special restrictions for anytype:
+- restriction by module(s) or module exceptions
+- restriction by language(s)
+- restriction by types
+
+With these restriction concepts, it would be possible to model the semantics of the different constructs in the external languages.
+
+ASN.1 ANY: anytype(octetstring, language "ASN.1:1997") (or whatever language the module defining the ANY was imported as)
+
+XSD:
+any ##other => anytype(XSD.String, language "XSD" except M) (where M would be name of the mapped-to module)
+
+any A, B, C => anytype(XSD.String, from A, B, C)
+
+Finally, it should be possible to access anytype with a type T even in a context where T is ambiguous (imported from different sources) or where a local T is defined in the module but an imported T should be accessed.
+
+For value-notation, this would change the syntactical structure to:
+
+'{' [ModuleName '.'] TypeIdentifier ":=" Expression '}'
+
+For anytype field access, this would need to be changed to:
+
+AnyTypeReference ['.' ModuleName] '.' TypeIdentifier
+
+The latter would seem to be a syntactical clash with
+
+AnyTypeReference '.' TypeIdentifier '.' FieldIdentifier
+
+but since no TypeIdentifier M can be used in a module named M or importing from M, this can always be resolved via the first identifier after the AnyTypeReference.
+
+
+This syntactical ambiguity is also the reason why only top-level types are allowed to be used in the anytype.
+
+If non-top-level (inner types inside a record/set type) were also allowed, then the following expression would be ambiguous:
+
+AnyTypeRef.Type.Field
+
+This has (at the moment) the semantics of (AnyTypeRef.Type).Field and not of
+
+AnyTypeRef.(Type.Field).
+
+If we also want to allow any inner types in anytype, the additional syntax
+
+AnyType '.' '(' TypeReference ')'
+
+needs to be allowed and the value-notation can be generalized to
+
+'{' TypeReference ":=" Expression '}'
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0007057closed Gyorgy Rethy Part 09: Using XML with TTCN-3 Extend the mapping of XSD any element and anyAttribute element to TTCN-3 anytype 
Attached Filespptx Anytype – what does it mean.pptx (68,192) 22-09-2015 08:34
http://oldforge.etsi.org/mantis/file_download.php?file_id=3260&type=bug
docx CR7126.docx (235,380) 23-09-2015 11:53
http://oldforge.etsi.org/mantis/file_download.php?file_id=3267&type=bug
docx CR7126_resolution_v2.docx (241,718) 04-11-2015 13:34
http://oldforge.etsi.org/mantis/file_download.php?file_id=3358&type=bug
docx CR7126_resolution_v3.docx (452,475) 04-11-2015 21:35
http://oldforge.etsi.org/mantis/file_download.php?file_id=3365&type=bug
Issue History
Date ModifiedUsernameFieldChange
05-08-2015 13:02Jacob Wieland - SpirentNew Issue
07-08-2015 09:19Gyorgy RethyProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
07-08-2015 09:21Gyorgy RethyNote Added: 0013126
07-08-2015 09:21Gyorgy RethyAssigned To => Jacob Wieland - Spirent
07-08-2015 09:21Gyorgy RethyStatusnew => assigned
07-08-2015 09:21Gyorgy RethyProduct Version => v4.7.1 (published 2015-06)
07-08-2015 09:21Gyorgy RethyTarget Version => v4.8.1 (published 2016-07)
07-08-2015 12:13Jacob Wieland - SpirentFile Added: Anytype – what does it mean.pptx
07-08-2015 12:14Jacob Wieland - SpirentNote Added: 0013139
22-09-2015 08:34Jacob Wieland - SpirentFile Deleted: Anytype – what does it mean.pptx
22-09-2015 08:34Jacob Wieland - SpirentFile Added: Anytype – what does it mean.pptx
23-09-2015 11:53Jacob Wieland - SpirentFile Added: CR7126.docx
23-09-2015 11:57Jacob Wieland - SpirentNote Added: 0013256
23-09-2015 11:57Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
23-09-2015 11:57Jacob Wieland - SpirentStatusassigned => confirmed
04-11-2015 13:34Gyorgy RethyFile Added: CR7126_resolution_v2.docx
04-11-2015 13:42Gyorgy RethyNote Added: 0013485
04-11-2015 13:43Gyorgy RethyNote Edited: 0013485bug_revision_view_page.php?bugnote_id=13485#r206
04-11-2015 13:43Gyorgy RethyAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
04-11-2015 14:07Jacob Wieland - SpirentNote Added: 0013488
04-11-2015 14:13Jacob Wieland - SpirentNote Added: 0013489
04-11-2015 14:13Jacob Wieland - SpirentStatusconfirmed => resolved
04-11-2015 14:13Jacob Wieland - SpirentFixed in Version => v4.8.1 (published 2016-07)
04-11-2015 14:13Jacob Wieland - SpirentResolutionopen => fixed
04-11-2015 14:13Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
04-11-2015 21:35Jacob Wieland - SpirentAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
04-11-2015 21:35Jacob Wieland - SpirentStatusresolved => feedback
04-11-2015 21:35Jacob Wieland - SpirentResolutionfixed => reopened
04-11-2015 21:35Jacob Wieland - SpirentFile Added: CR7126_resolution_v3.docx
04-11-2015 21:36Jacob Wieland - SpirentNote Added: 0013496
04-11-2015 21:36Jacob Wieland - SpirentStatusfeedback => assigned
04-11-2015 21:36Jacob Wieland - SpirentStatusassigned => resolved
04-11-2015 21:36Jacob Wieland - SpirentResolutionreopened => fixed
04-11-2015 21:36Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
11-12-2015 14:25Gyorgy RethyNote Added: 0013589
11-12-2015 14:25Gyorgy RethyStatusresolved => closed
16-11-2016 09:47Kristóf SzabadosRelationship addedrelated to 0007057
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0013126) +
+ Gyorgy Rethy    +
+ 07-08-2015 09:21    +
+ 		+ + + + +
+ Please prepare an analysis comparing current and proposed new syntax and semantics, what are the potential backward co mpatibility issues we need to consider.
+
+
+
+ + + + + + + + + + +
+ (0013139) +
+ Jacob Wieland - Spirent    +
+ 07-08-2015 12:14    +
+ 		+ + + + +
+ uploaded discussion of the different anytype aspects as powerpoint slides
+
+
+
+ + + + + + + + + + +
+ (0013256) +
+ Jacob Wieland - Spirent    +
+ 23-09-2015 11:57    +
+ 		+ + + + +
+ added proposal for anytype changes.
+
+decided to not add the capability of using nested type references as anytype variants (only type names and module-prefixed type names are allowed) because it does not really add any additional power to the language (the root type can be used in the anytype variable as a container). It just adds unnecessary complications to the language which are hard to explain, hard to implement and they would probably have to be restricted in some way.
+
+In the advanced parameterization package, we should add also change it so that type parameters can be given for TypeReference.
+
+
+
+ + + + + + + + + + +
+ (0013485) +
+ Gyorgy Rethy    +
+ 04-11-2015 13:42    +
(edited on: 04-11-2015 13:43)
+ 		+ + + + +
+ CR7126_resolution_v2.docx: I basically agree (and though it's not noted here, my memory says we have agreed already on the conclusions in the .ppt analysis).
+I have made using anytype with ischosen more explicit in clause C.3.2, please check. I'm concerned about possible name clashes in the case of
+    ischosen(t_a1.M.U)
+if: type union M (MyUType U) is defined in the same module, where t_a1 is defined (which, in this case is not module M);
+
+
+
+
+
+ + + + + + + + + + +
+ (0013488) +
+ Jacob Wieland - Spirent    +
+ 04-11-2015 14:07    +
+ 		+ + + + +
+ I have already thought about that problem, and as far as I have understood, it is not allowed to have a type M in a module which also imports module M.
+
+Therefore, t_a1.M.U refers to type M.U in the anytype if U is imported from M or to field U in the union type M in the anytype if nothing from module M is imported.
+
+
+
+ + + + + + + + + + +
+ (0013489) +
+ Jacob Wieland - Spirent    +
+ 04-11-2015 14:13    +
+ 		+ + + + +
+ I'm happy with the additions, the NOTE about strong typing for ischosen is correct, as well.
+
+
+
+ + + + + + + + + + +
+ (0013496) +
+ Jacob Wieland - Spirent    +
+ 04-11-2015 21:36    +
+ 		+ + + + +
+ made some corrections to the anytype ischosen example
+
+
+
+ + + + + + + + + + +
+ (0013589) +
+ Gyorgy Rethy    +
+ 11-12-2015 14:25    +
+ 		+ + + + +
+ Added to draft V4.7.4
+
+ + diff --git a/docs/mantis/CR7127.md b/docs/mantis/CR7127.md new file mode 100644 index 0000000000000000000000000000000000000000..31f713bc056b082f900de94568b5cbb1e91c738e --- /dev/null +++ b/docs/mantis/CR7127.md @@ -0,0 +1,63 @@ + + + + + + + + + + + + + 0007127: Obsolete @encoded used in istemplatekind - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007127Part 01: TTCN-3 Core LanguageEditorialpublic06-08-2015 10:0723-09-2015 12:07
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.7.1 (published 2015-06) 
Target Versionv4.8.1 (published 2016-07)Fixed in Versionv4.8.1 (published 2016-07) 
Clause Reference(s)C.3.5
Source (company - Author)STF 487
Summary0007127: Obsolete @encoded used in istemplatekind
DescriptionThe table C.1 in the istemplatekind function definition contains wrong string and description of the matching mechanism described in B.1.2.9. "@encoded" and "Encoded value" were used only in CR drafts of 4.7.1, but were later replaced with "decmatch" and "Matching decoded content". This change should be done in the table C.1 and the CR reference shall be removed.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
06-08-2015 10:07Tomas UrbanNew Issue
21-09-2015 10:27Gyorgy RethyTarget Version => v4.8.1 (published 2016-07)
21-09-2015 14:12Gyorgy RethyAssigned To => Gyorgy Rethy
21-09-2015 14:12Gyorgy RethyStatusnew => assigned
23-09-2015 12:07Gyorgy RethyNote Added: 0013258
23-09-2015 12:07Gyorgy RethyStatusassigned => closed
23-09-2015 12:07Gyorgy RethyResolutionopen => fixed
23-09-2015 12:07Gyorgy RethyFixed in Version => v4.8.1 (published 2016-07)
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0013258) +
+ Gyorgy Rethy    +
+ 23-09-2015 12:07    +
+ 		+ + + + +
+ Corrected in draft version 4.7.4
+
+ + diff --git a/docs/mantis/CR7128.md b/docs/mantis/CR7128.md new file mode 100644 index 0000000000000000000000000000000000000000..6ea9ff2d5c112464c726bc90d1b284c9c5cf74d2 --- /dev/null +++ b/docs/mantis/CR7128.md @@ -0,0 +1,167 @@ + + + + + + + + + + + + + 0007128: Wrong endianness in examples - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007128Part 01: TTCN-3 Core LanguageTechnicalpublic06-08-2015 10:1911-12-2015 15:06
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.7.1 (published 2015-06) 
Target Versionv4.8.1 (published 2016-07)Fixed in Versionv4.8.1 (published 2016-07) 
Clause Reference(s)C.1.31
Source (company - Author)STF 487
Summary0007128: Wrong endianness in examples
DescriptionThe example on using little endian UTF-16 encoding in converdion of an octet string to universal charstring conversion in C.1.31 is incorrect. The octet string is in the big endian format and the function will thus not yield the expected result.
+
+The same problem is present in C.1.32 in the opposite conversion.
Steps To Reproduce
Additional Information
Tagstechnically agreed
Relationships
Attached Filesdocx CR7128_resolution_v1.docx (77,285) 15-10-2015 10:56
http://oldforge.etsi.org/mantis/file_download.php?file_id=3311&type=bug
Issue History
Date ModifiedUsernameFieldChange
06-08-2015 10:19Tomas UrbanNew Issue
21-09-2015 10:27Gyorgy RethyTarget Version => v4.8.1 (published 2016-07)
21-09-2015 14:15Gyorgy RethyNote Added: 0013206
21-09-2015 14:17Gyorgy RethyTag Attached: technically agreed
15-10-2015 10:49Axel RennochAssigned To => Axel Rennoch
15-10-2015 10:49Axel RennochStatusnew => assigned
15-10-2015 10:56Axel RennochFile Added: CR7128_resolution_v1.docx
15-10-2015 10:58Axel RennochNote Added: 0013393
15-10-2015 10:58Axel RennochAssigned ToAxel Rennoch => Jacob Wieland - Spirent
15-10-2015 10:58Axel RennochStatusassigned => acknowledged
15-10-2015 12:02Jacob Wieland - SpirentNote Added: 0013395
15-10-2015 12:02Jacob Wieland - SpirentStatusacknowledged => resolved
15-10-2015 12:02Jacob Wieland - SpirentResolutionopen => fixed
15-10-2015 12:02Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
04-11-2015 14:02Gyorgy RethyFixed in Version => v4.8.1 (published 2016-07)
11-12-2015 15:06Gyorgy RethyNote Added: 0013598
11-12-2015 15:06Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0013206) +
+ Gyorgy Rethy    +
+ 21-09-2015 14:15    +
+ 		+ + + + +
+ STF discussion: to be checked and corrected if needed.
+
+
+
+ + + + + + + + + + +
+ (0013393) +
+ Axel Rennoch    +
+ 15-10-2015 10:58    +
+ 		+ + + + +
+ please confirm corrected and additional samples in uploaded files
+
+
+
+ + + + + + + + + + +
+ (0013395) +
+ Jacob Wieland - Spirent    +
+ 15-10-2015 12:02    +
+ 		+ + + + +
+ reviewed and correct
+
+
+
+ + + + + + + + + + +
+ (0013598) +
+ Gyorgy Rethy    +
+ 11-12-2015 15:06    +
+ 		+ + + + +
+ Added to draft V4.7.4
+
+ + diff --git a/docs/mantis/CR7129.md b/docs/mantis/CR7129.md new file mode 100644 index 0000000000000000000000000000000000000000..bcf368c50a685726e2d3d5cf75bba3326ed27bf4 --- /dev/null +++ b/docs/mantis/CR7129.md @@ -0,0 +1,99 @@ + + + + + + + + + + + + + 0007129: Naming convension in examples - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007129Part 01: TTCN-3 Core LanguageEditorialpublic06-08-2015 10:3806-01-2016 09:09
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritylowSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.7.1 (published 2015-06) 
Target Versionv4.8.1 (published 2016-07)Fixed in Versionv4.8.1 (published 2016-07) 
Clause Reference(s)All examples
Source (company - Author)STF 487
Summary0007129: Naming convension in examples
DescriptionAll examples in the core language specification should use the same naming convension (preferably the ETSI generic naming convension specified at http://www.ttcn-3.org/index.php/development/naming-convention/naming-convention-etsi [^]).
+
+The current specification doesn't seem to follow any naming rules and it simply doesn't look good when e.g. functions start once with a capital letter, once with a small letter and once with the f_ prefix. I am aware that changing all existing examples is a time consuming job, but it should be taken at some point.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
06-08-2015 10:38Tomas UrbanNew Issue
21-09-2015 10:27Gyorgy RethyTarget Version => v4.8.1 (published 2016-07)
21-09-2015 14:19Gyorgy RethyNote Added: 0013207
06-01-2016 09:09Gyorgy RethyNote Added: 0013662
06-01-2016 09:09Gyorgy RethyStatusnew => closed
06-01-2016 09:09Gyorgy RethyAssigned To => Gyorgy Rethy
06-01-2016 09:09Gyorgy RethyResolutionopen => fixed
06-01-2016 09:09Gyorgy RethyFixed in Version => v4.8.1 (published 2016-07)
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0013207) +
+ Gyorgy Rethy    +
+ 21-09-2015 14:19    +
+ 		+ + + + +
+ STF discussion: handle it as low priority
+
+
+
+ + + + + + + + + + +
+ (0013662) +
+ Gyorgy Rethy    +
+ 06-01-2016 09:09    +
+ 		+ + + + +
+ Implemented in draft V4.7.5
+
+ + diff --git a/docs/mantis/CR7130.md b/docs/mantis/CR7130.md new file mode 100644 index 0000000000000000000000000000000000000000..1e75de5b86a498c39a412150754280207de33ba6 --- /dev/null +++ b/docs/mantis/CR7130.md @@ -0,0 +1,97 @@ + + + + + + + + + + + + + 0007130: Typo in the example 3 on actual parameters - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007130Part 01: TTCN-3 Core LanguageEditorialpublic06-08-2015 11:4423-09-2015 10:40
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritylowSeveritytrivialReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.7.1 (published 2015-06) 
Target Versionv4.8.1 (published 2016-07)Fixed in Versionv4.8.1 (published 2016-07) 
Clause Reference(s)5.4.2
Source (company - Author)STF 487
Summary0007130: Typo in the example 3 on actual parameters
DescriptionThe example 3 in the section 5.4.2 contains a fuction f_swapElements. The last line of the example contains an unknown reference to p_tmp. The referenced value should be v_tmp instead.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
06-08-2015 11:44Tomas UrbanNew Issue
21-09-2015 10:27Gyorgy RethyTarget Version => v4.8.1 (published 2016-07)
21-09-2015 14:20Gyorgy RethyNote Added: 0013208
21-09-2015 14:20Gyorgy RethyAssigned To => Gyorgy Rethy
21-09-2015 14:20Gyorgy RethyStatusnew => assigned
23-09-2015 10:40Gyorgy RethyNote Added: 0013253
23-09-2015 10:40Gyorgy RethyStatusassigned => closed
23-09-2015 10:40Gyorgy RethyResolutionopen => fixed
23-09-2015 10:40Gyorgy RethyFixed in Version => v4.8.1 (published 2016-07)
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0013208) +
+ Gyorgy Rethy    +
+ 21-09-2015 14:20    +
+ 		+ + + + +
+ STF discussion: check and correct
+
+
+
+ + + + + + + + + + +
+ (0013253) +
+ Gyorgy Rethy    +
+ 23-09-2015 10:40    +
+ 		+ + + + +
+ Corrected in draft version 4.7.4
+
+ + diff --git a/docs/mantis/CR7131.md b/docs/mantis/CR7131.md new file mode 100644 index 0000000000000000000000000000000000000000..6ea8416958a79525d2716394c938dec6f1b1ff4d --- /dev/null +++ b/docs/mantis/CR7131.md @@ -0,0 +1,101 @@ + + + + + + + + + + + + + 0007131: Wrong description in the example 6 on actual parameters - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007131Part 01: TTCN-3 Core LanguageEditorialpublic06-08-2015 12:1823-09-2015 10:11
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritylowSeveritytrivialReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.7.1 (published 2015-06) 
Target Versionv4.8.1 (published 2016-07)Fixed in Versionv4.8.1 (published 2016-07) 
Clause Reference(s)5.4.2
Source (company - Author)STF 487
Summary0007131: Wrong description in the example 6 on actual parameters
DescriptionThe example 6 in 5.4.2 contains the following description:
+
+computeComplexMessage() is only invoked if logMessage is false
+
+However, this is not true, the function is invoked in the opposite way: only if logMessage is true.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
06-08-2015 12:18Tomas UrbanNew Issue
21-09-2015 10:27Gyorgy RethyTarget Version => v4.8.1 (published 2016-07)
21-09-2015 14:21Gyorgy RethyAssigned To => Gyorgy Rethy
21-09-2015 14:21Gyorgy RethyStatusnew => assigned
21-09-2015 14:21Gyorgy RethyNote Added: 0013209
23-09-2015 10:11Gyorgy RethyNote Added: 0013252
23-09-2015 10:11Gyorgy RethyStatusassigned => closed
23-09-2015 10:11Gyorgy RethyResolutionopen => fixed
23-09-2015 10:11Gyorgy RethyFixed in Version => v4.8.1 (published 2016-07)
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0013209) +
+ Gyorgy Rethy    +
+ 21-09-2015 14:21    +
+ 		+ + + + +
+ STF discussion: check and correct
+
+
+
+ + + + + + + + + + +
+ (0013252) +
+ Gyorgy Rethy    +
+ 23-09-2015 10:11    +
+ 		+ + + + +
+ Corrected in draft version 4.7.4
+
+ + diff --git a/docs/mantis/CR7132.md b/docs/mantis/CR7132.md new file mode 100644 index 0000000000000000000000000000000000000000..8e78a7632062463a41a22fb575ce2ecff3901f9b --- /dev/null +++ b/docs/mantis/CR7132.md @@ -0,0 +1,214 @@ + + + + + + + + + + + + + 0007132: Syntax of the select statement - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007132Part 01: TTCN-3 Core LanguageTechnicalpublic07-08-2015 11:5115-12-2015 09:46
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.7.1 (published 2015-06) 
Target Versionv4.8.1 (published 2016-07)Fixed in Versionv4.8.1 (published 2016-07) 
Clause Reference(s)A.1.6.8.3
Source (company - Author)STF 487
Summary0007132: Syntax of the select statement
DescriptionThe BNF defines the select body syntax as follows:
+
+563.SelectCaseBody ::= "{" {SelectCase}+ "}"
+564.SelectCase ::= CaseKeyword ("(" InLineTemplate {"," InLineTemplate}
+")" | ElseKeyword) StatementBlock
+
+However, in my opinion it is not a correct or complete definition and it is not compatible with the textual description of the statement (19.3). The problem is that the rule doesn't say that the else branch should occur at most once and if present it should be the last branch in the SelectCaseBody construct. There should be either a static semantic rule saying that or (preferably) it should be resolved syntactically:
+
+563.SelectCaseBody ::= "{" {SelectCase}+ [CaseElse] "}"
+564.SelectCase ::= CaseKeyword "(" InLineTemplate {"," InLineTemplate}
+")" StatementBlock
+565.CaseElse ::= CaseKeyword ElseKeyword StatementBlock
+
Steps To Reproduce
Additional Information
Tagstechnically agreed
Relationships
related to 0007133closed Gyorgy Rethy Select union statement should have at least one branch 
Attached Filesdocx CR7132_resolution_v1.docx (88,159) 23-09-2015 09:31
http://oldforge.etsi.org/mantis/file_download.php?file_id=3263&type=bug
Issue History
Date ModifiedUsernameFieldChange
07-08-2015 11:51Tomas UrbanNew Issue
07-08-2015 12:32Tomas UrbanNote Added: 0013141
21-09-2015 10:27Gyorgy RethyTarget Version => v4.8.1 (published 2016-07)
21-09-2015 14:39Gyorgy RethyNote Added: 0013210
21-09-2015 14:41Gyorgy RethyTag Attached: technically agreed
22-09-2015 16:16Axel RennochAssigned To => Axel Rennoch
22-09-2015 16:16Axel RennochStatusnew => assigned
23-09-2015 09:31Axel RennochFile Added: CR7132_resolution_v1.docx
23-09-2015 09:33Axel RennochNote Added: 0013248
23-09-2015 09:33Axel RennochAssigned ToAxel Rennoch => Jacob Wieland - Spirent
23-09-2015 09:33Axel RennochStatusassigned => confirmed
23-09-2015 09:33Axel RennochRelationship addedrelated to 0007133
23-09-2015 12:41Jacob Wieland - SpirentNote Added: 0013264
23-09-2015 12:41Jacob Wieland - SpirentStatusconfirmed => resolved
23-09-2015 12:41Jacob Wieland - SpirentFixed in Version => v4.8.1 (published 2016-07)
23-09-2015 12:41Jacob Wieland - SpirentResolutionopen => fixed
16-10-2015 13:23Jacob Wieland - SpirentStatusresolved => feedback
16-10-2015 13:23Jacob Wieland - SpirentResolutionfixed => reopened
16-10-2015 13:23Jacob Wieland - SpirentStatusfeedback => resolved
16-10-2015 13:23Jacob Wieland - SpirentResolutionreopened => fixed
16-10-2015 13:23Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
15-12-2015 09:46Gyorgy RethyNote Added: 0013630
15-12-2015 09:46Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0013141) +
+ Tomas Urban    +
+ 07-08-2015 12:32    +
+ 		+ + + + +
+ If possible, it would be nice to have textual restrictions on the use of the else branch in 16.3.1 and 16.3.2:
+
+The else branch shall be present at most once and if used it shall be the last branch of the select statement.
+
+
+
+ + + + + + + + + + +
+ (0013210) +
+ Gyorgy Rethy    +
+ 21-09-2015 14:39    +
+ 		+ + + + +
+ STF discussion: change the BNF acc. to the proposal. Correct the Syntactical Structure part of $19.3.1: at least one branch shall be present
+
+
+
+ + + + + + + + + + +
+ (0013248) +
+ Axel Rennoch    +
+ 23-09-2015 09:33    +
+ 		+ + + + +
+ Please check and close the CR.
+This CR overwrites issue 0007133.
+
+
+
+ + + + + + + + + + +
+ (0013264) +
+ Jacob Wieland - Spirent    +
+ 23-09-2015 12:41    +
+ 		+ + + + +
+ ok
+
+
+
+ + + + + + + + + + +
+ (0013630) +
+ Gyorgy Rethy    +
+ 15-12-2015 09:46    +
+ 		+ + + + +
+ Added to draft V4.7.4
+
+ + diff --git a/docs/mantis/CR7133.md b/docs/mantis/CR7133.md new file mode 100644 index 0000000000000000000000000000000000000000..77ad4d5a5aa7fd33d304ad9b77d76bcd1f2a4598 --- /dev/null +++ b/docs/mantis/CR7133.md @@ -0,0 +1,243 @@ + + + + + + + + + + + + + 0007133: Select union statement should have at least one branch - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007133Part 01: TTCN-3 Core LanguageTechnicalpublic07-08-2015 11:5512-10-2015 12:06
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.7.1 (published 2015-06) 
Target Versionv4.8.1 (published 2016-07)Fixed in Versionv4.8.1 (published 2016-07) 
Clause Reference(s)19.3.2
Source (company - Author)STF 487
Summary0007133: Select union statement should have at least one branch
DescriptionThe BNF defines the select body as follows:
+
+563.SelectCaseBody ::= "{" {SelectCase}+ "}"
+
+Please notice the rule requires 1..N SelectCase items. However, the textual description of the select union statement states that "the statement contains a header part and zero or more branches". That's clearly inconsistent with the BNF. and a select union statement with no branch doesn't make any sense either. I propose to change the sentence to: "the statement contains a header part and one or more branches".
Steps To Reproduce
Additional Information
Tagstechnically agreed
Relationships
related to 0007132closed Gyorgy Rethy Syntax of the select statement 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
07-08-2015 11:55Tomas UrbanNew Issue
21-09-2015 10:27Gyorgy RethyTarget Version => v4.8.1 (published 2016-07)
21-09-2015 14:41Gyorgy RethyNote Added: 0013211
21-09-2015 14:41Gyorgy RethyTag Attached: technically agreed
22-09-2015 16:02Axel RennochAssigned To => Axel Rennoch
22-09-2015 16:02Axel RennochStatusnew => assigned
23-09-2015 08:29Axel RennochFile Added: CR7133_resolution_v1.docx
23-09-2015 08:31Axel RennochNote Added: 0013245
23-09-2015 08:31Axel RennochAssigned ToAxel Rennoch => Jacob Wieland - Spirent
23-09-2015 08:31Axel RennochStatusassigned => acknowledged
23-09-2015 09:33Axel RennochRelationship addedrelated to 0007132
23-09-2015 12:01Jacob Wieland - SpirentFile Added: CR7133_resolution_v2.docx
23-09-2015 12:02Jacob Wieland - SpirentNote Added: 0013257
23-09-2015 12:02Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
23-09-2015 12:02Jacob Wieland - SpirentStatusacknowledged => confirmed
25-09-2015 11:28Gyorgy RethyNote Added: 0013304
25-09-2015 11:28Gyorgy RethyAssigned ToGyorgy Rethy => Axel Rennoch
25-09-2015 11:28Gyorgy RethyStatusconfirmed => assigned
25-09-2015 13:13Axel RennochFile Deleted: CR7133_resolution_v1.docx
25-09-2015 13:13Axel RennochFile Deleted: CR7133_resolution_v2.docx
25-09-2015 13:13Axel RennochNote Added: 0013310
25-09-2015 13:14Axel RennochAssigned ToAxel Rennoch => Gyorgy Rethy
25-09-2015 13:14Axel RennochStatusassigned => confirmed
12-10-2015 12:06Gyorgy RethyNote Added: 0013354
12-10-2015 12:06Gyorgy RethyStatusconfirmed => closed
12-10-2015 12:06Gyorgy RethyResolutionopen => fixed
12-10-2015 12:06Gyorgy RethyFixed in Version => v4.8.1 (published 2016-07)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0013211) +
+ Gyorgy Rethy    +
+ 21-09-2015 14:41    +
+ 		+ + + + +
+ STF discussion: correct the text of the Semantic description
+
+
+
+ + + + + + + + + + +
+ (0013245) +
+ Axel Rennoch    +
+ 23-09-2015 08:31    +
+ 		+ + + + +
+ Please confirm the modification.
+
+
+
+ + + + + + + + + + +
+ (0013257) +
+ Jacob Wieland - Spirent    +
+ 23-09-2015 12:02    +
+ 		+ + + + +
+ added additional + after the set in the Syntactical Structure part, please review and resolve
+
+
+
+ + + + + + + + + + +
+ (0013304) +
+ Gyorgy Rethy    +
+ 25-09-2015 11:28    +
+ 		+ + + + +
+ Actually, select case and select union shall have the same semantics, they have a common BNF in Annex A. Currently select case also allows only a single else branch that, of course, makes no sense once we define select case as a shorthand for an if-else sequence. So select case shall also be changed to require at least one non-else branch.
+
+I think we have also discussed that for consistency we disallow else branches at the middle.
+
+Also the BNF in Annex A shall be changed, e.g. to:
+563.SelectCaseBody ::= "{" {SelectCase}+ [ ElseKeyword StatementBlock ]"}"
+564.SelectCase ::= CaseKeyword ("(" TemplateInstance {"," TemplateInstance } ")" StatementBlock
+
+
+
+ + + + + + + + + + +
+ (0013310) +
+ Axel Rennoch    +
+ 25-09-2015 13:13    +
+ 		+ + + + +
+ The resolution of the CR is covered by CR 7132, including BNF.
+
+
+
+ + + + + + + + + + +
+ (0013354) +
+ Gyorgy Rethy    +
+ 12-10-2015 12:06    +
+ 		+ + + + +
+ See resolution in CR 7132
+
+ + diff --git a/docs/mantis/CR7134.md b/docs/mantis/CR7134.md new file mode 100644 index 0000000000000000000000000000000000000000..bf2534e580eb7f9bed0855fbd393f0a113568a2a --- /dev/null +++ b/docs/mantis/CR7134.md @@ -0,0 +1,101 @@ + + + + + + + + + + + + + 0007134: Syntactical structure of the select branch shall contain TemplateInstance - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007134Part 01: TTCN-3 Core LanguageClarificationpublic07-08-2015 12:3923-09-2015 11:40
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeveritytrivialReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.7.1 (published 2015-06) 
Target Versionv4.8.1 (published 2016-07)Fixed in Versionv4.8.1 (published 2016-07) 
Clause Reference(s)19.3.1
Source (company - Author)STF 487
Summary0007134: Syntactical structure of the select branch shall contain TemplateInstance
DescriptionThe syntactical structure of the select statement describes the branch as:
+{ case "(" { SingleExpression [","] } ")" StatementBlock }
+
+However, it's not consistent with the BNF and the textual description, which allows using templates in select branches. The correct syntax would be:
+{ case "(" { TemplateInstance [","] } ")" StatementBlock }
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0007185closed Gyorgy Rethy BNF productions TemplateInstance vs. InLineTemplate 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
07-08-2015 12:39Tomas UrbanNew Issue
21-09-2015 10:27Gyorgy RethyTarget Version => v4.8.1 (published 2016-07)
21-09-2015 14:42Gyorgy RethyNote Added: 0013212
21-09-2015 14:43Gyorgy RethyAssigned To => Gyorgy Rethy
21-09-2015 14:43Gyorgy RethyStatusnew => assigned
23-09-2015 11:39Gyorgy RethyRelationship addedrelated to 0007185
23-09-2015 11:40Gyorgy RethyNote Added: 0013255
23-09-2015 11:40Gyorgy RethyStatusassigned => closed
23-09-2015 11:40Gyorgy RethyResolutionopen => fixed
23-09-2015 11:40Gyorgy RethyFixed in Version => v4.8.1 (published 2016-07)
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0013212) +
+ Gyorgy Rethy    +
+ 21-09-2015 14:42    +
+ 		+ + + + +
+ STF discussion: correct to TemplateBody
+
+
+
+ + + + + + + + + + +
+ (0013255) +
+ Gyorgy Rethy    +
+ 23-09-2015 11:40    +
+ 		+ + + + +
+ Changed to TemplateInstance in draft version 4.7.4 (see also CR 7185).
+
+ + diff --git a/docs/mantis/CR7135.md b/docs/mantis/CR7135.md new file mode 100644 index 0000000000000000000000000000000000000000..0ace98f51e6af72e6b98595e9fea7d3b85cda528 --- /dev/null +++ b/docs/mantis/CR7135.md @@ -0,0 +1,144 @@ + + + + + + + + + + + + + 0007135: Template instance in the header of the select union statement - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007135Part 01: TTCN-3 Core LanguageTechnicalpublic07-08-2015 14:3415-12-2015 10:12
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.7.1 (published 2015-06) 
Target Versionv4.8.1 (published 2016-07)Fixed in Versionv4.8.1 (published 2016-07) 
Clause Reference(s)19.3.2
Source (company - Author)STF 487
Summary0007135: Template instance in the header of the select union statement
DescriptionAccording to the BNF, there cannot be a template instance in the header of the select union statement:
+
+561.SelectCaseConstruct ::= SelectKeyword [UnionKeyword] "(" SingleExpression ")" SelectCaseBody
+
+However, the textual description of the statement in 19.3.2 expects a template instance instead of the expression.
+
+There are two ways for handling the problem:
+a. Disallow the use of templates. BNF should stay the same, but the text in 19.3.2 should be changed replacing "TemplateInstance" with "SingleExpression".
+
+b. Modify the BNF:
+
+561.SelectCaseConstruct ::= SelectKeyword ("(" SingleExpression ")")|( UnionKeyword "(" InLineTemplate ")") SelectCaseBody
+
+In this second case, the textual description should be ammended and describe what happens when the template instance contains a matching symbol (either an error or application of the expansion rules).
Steps To Reproduce
Additional Information
Tagstechnically agreed
Relationships
Attached Filesdocx CR7135_resolution.docx (168,676) 15-10-2015 14:02
http://oldforge.etsi.org/mantis/file_download.php?file_id=3321&type=bug
Issue History
Date ModifiedUsernameFieldChange
07-08-2015 14:34Tomas UrbanNew Issue
21-09-2015 10:27Gyorgy RethyTarget Version => v4.8.1 (published 2016-07)
21-09-2015 14:52Gyorgy RethyTag Attached: technically agreed
21-09-2015 14:52Gyorgy RethyNote Added: 0013213
21-09-2015 14:53Gyorgy RethyAssigned To => Gyorgy Rethy
21-09-2015 14:53Gyorgy RethyStatusnew => assigned
15-10-2015 14:02Jacob Wieland - SpirentFile Added: CR7135_resolution.docx
15-10-2015 14:02Jacob Wieland - SpirentNote Added: 0013412
15-10-2015 14:02Jacob Wieland - SpirentStatusassigned => resolved
15-10-2015 14:02Jacob Wieland - SpirentFixed in Version => v4.8.1 (published 2016-07)
15-10-2015 14:02Jacob Wieland - SpirentResolutionopen => fixed
15-12-2015 10:12Gyorgy RethyNote Added: 0013633
15-12-2015 10:12Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0013213) +
+ Gyorgy Rethy    +
+ 21-09-2015 14:52    +
+ 		+ + + + +
+ STF discussion: change acc. to proposed alternative a.
+
+
+
+ + + + + + + + + + +
+ (0013412) +
+ Jacob Wieland - Spirent    +
+ 15-10-2015 14:02    +
+ 		+ + + + +
+ changed accordingly
+
+
+
+ + + + + + + + + + +
+ (0013633) +
+ Gyorgy Rethy    +
+ 15-12-2015 10:12    +
+ 		+ + + + +
+ Added to draft V4.7.4
+
+ + diff --git a/docs/mantis/CR7136.md b/docs/mantis/CR7136.md new file mode 100644 index 0000000000000000000000000000000000000000..68eb4f0e447593ed9501f66486b14f763f5a6095 --- /dev/null +++ b/docs/mantis/CR7136.md @@ -0,0 +1,293 @@ + + + + + + + + + + + + + 0007136: Value list size for arrays - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007136Part 01: TTCN-3 Core LanguageClarificationpublic11-08-2015 14:4114-12-2015 11:44
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.7.1 (published 2015-06) 
Target Versionv4.8.1 (published 2016-07)Fixed in Versionv4.8.1 (published 2016-07) 
Clause Reference(s)6.2.7
Source (company - Author)STF 487
Summary0007136: Value list size for arrays
DescriptionThe rules for using value list notation for arrays don't specify what should happen if the value list contains a different amount of items than the array size. I assume that longer list is not allowed (using the rules describing arrays as a short-hand for a fixed size record-of and applying the constraint) and shorter value lists would be fine (just leaving the remaining items uninitialized). Nevertheless, I would prefer an explicit rule or note to be added into the specification to avoid any kind of different interpretations.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7136_resolution_v1.docx (384,721) 03-11-2015 10:55
http://oldforge.etsi.org/mantis/file_download.php?file_id=3347&type=bug
Issue History
Date ModifiedUsernameFieldChange
11-08-2015 14:41Tomas UrbanNew Issue
21-09-2015 10:27Gyorgy RethyTarget Version => v4.8.1 (published 2016-07)
21-09-2015 15:01Gyorgy RethyNote Added: 0013214
21-09-2015 15:01Gyorgy RethyAssigned To => Tomas Urban
21-09-2015 15:01Gyorgy RethyStatusnew => feedback
21-09-2015 15:17Tomas UrbanNote Added: 0013216
21-09-2015 15:17Tomas UrbanStatusfeedback => assigned
15-10-2015 13:54Jacob Wieland - SpirentNote Added: 0013409
15-10-2015 13:55Jacob Wieland - SpirentNote Added: 0013410
15-10-2015 13:55Jacob Wieland - SpirentAssigned ToTomas Urban => Gyorgy Rethy
15-10-2015 13:55Jacob Wieland - SpirentStatusassigned => confirmed
02-11-2015 15:24Gyorgy RethyNote Added: 0013444
02-11-2015 15:25Gyorgy RethyNote Edited: 0013444bug_revision_view_page.php?bugnote_id=13444#r198
02-11-2015 15:25Gyorgy RethyAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
02-11-2015 15:25Gyorgy RethyStatusconfirmed => assigned
03-11-2015 10:55Jacob Wieland - SpirentFile Added: CR7136_resolution_v1.docx
03-11-2015 10:55Jacob Wieland - SpirentNote Added: 0013461
03-11-2015 10:55Jacob Wieland - SpirentStatusassigned => resolved
03-11-2015 10:55Jacob Wieland - SpirentFixed in Version => v4.8.1 (published 2016-07)
03-11-2015 10:55Jacob Wieland - SpirentResolutionopen => fixed
03-11-2015 10:55Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
14-12-2015 11:44Gyorgy RethyNote Added: 0013614
14-12-2015 11:44Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0013214) +
+ Gyorgy Rethy    +
+ 21-09-2015 15:01    +
+ 		+ + + + +
+ STF discussion: There is no clear understanding what problem the CR wants to report. The relation of the number of items in a value list to the size of an array is unclear. Please elaborate the problem in more detail and provide an example.
+
+
+
+ + + + + + + + + + +
+ (0013216) +
+ Tomas Urban    +
+ 21-09-2015 15:17    +
+ 		+ + + + +
+ Examples:
+
+var integer v_arr[3] := { 0, 1 }, // less elements than the size of the array
+ v_arr2[3] := { 0, 1, 2, 3 }; // more elements than the size of the array
+
+Applying the rules for record of, the first assignment goes through and the second one produces an error. The problem is that the section on arrays doesn't say directly that these rules shall be apply, so there's a certain degree of uncertainty.
+
+It would be nice to have explicit guidelines for these two cases.
+
+
+
+ + + + + + + + + + +
+ (0013409) +
+ Jacob Wieland - Spirent    +
+ 15-10-2015 13:54    +
+ 		+ + + + +
+ As arrays are just a different notation for record of types with fixed length restrictions (and maybe an offset), the same restrictions as for those apply.
+
+In section 6.2.3 it is stated:
+
+"Already initialized elements left without a corresponding list member in a value list notation (i.e. at the end of a list) are becoming uninitialized."
+
+So it is explicitly allowed to assign a shorter list, even if it was already longer. The missing elements remain uninitialized. Since a longer list would definitely violate the fixed length restriction, that is out of the question, too.
+
+Therefore, I think there is no action required here.
+
+
+
+ + + + + + + + + + +
+ (0013410) +
+ Jacob Wieland - Spirent    +
+ 15-10-2015 13:55    +
+ 		+ + + + +
+ confirm and resolve
+
+
+
+ + + + + + + + + + +
+ (0013444) +
+ Gyorgy Rethy    +
+ 02-11-2015 15:24    +
(edited on: 02-11-2015 15:25)
+ 		+ + + + +
+ I think what Tomas is missing is just an explicit statement or reference to 6.2.3.
+
+Actually, in $6.2.3 we have:
+"When using the value list notation, all elements in the structure shall be specified either with a value or the not used symbol "-". The first member of the list is assigned to the first element, the second list member is assigned to the second element, etc. No empty assignment is allowed (e.g. two commas, the second immediately following the first or only with white space between them). Elements to be left out of the assignment shall be explicitly skipped in the list by use of the not-used-symbol "-". Already initialized elements left without a corresponding list member in a value list notation (i.e. at the end of a list) are becoming uninitialized. In this way, a value with initialized elements can be made empty by using the empty value list notation ("{}")."
+
+and in 6.2.7:
+"The values of array elements shall be compatible with the corresponding variable or type declaration. Values may be assigned individually by a value list notation or indexed notation or more than one or all at once by a value list notation or index assignment notation. >>When the value list notation is used, the first value of the list is assigned to the first element of the array (the element with index 0 or the lower bound if an index range has been given), the second value to the next element, etc. Elements to be left out from the assignment shall be explicitly skipped in the list by using dash. For using the assignment notation for arrays, the rules described in 6.2.3 are valid for arrays as well.<<"
+
+I think that the text in 6.2.7 between >> and << could be just replaced by
+"For using the value list and the assignment notations for arrays, the rules described in 6.2.3 are valid for arrays as well."
+
+
+
+
+
+ + + + + + + + + + +
+ (0013461) +
+ Jacob Wieland - Spirent    +
+ 03-11-2015 10:55    +
+ 		+ + + + +
+ resolved according to Gyorgy's proposal
+
+
+
+ + + + + + + + + + +
+ (0013614) +
+ Gyorgy Rethy    +
+ 14-12-2015 11:44    +
+ 		+ + + + +
+ Added to draft V4.7.4
+
+ + diff --git a/docs/mantis/CR7137.md b/docs/mantis/CR7137.md new file mode 100644 index 0000000000000000000000000000000000000000..e96d2b1c523f81161432228dc984430988e3372b --- /dev/null +++ b/docs/mantis/CR7137.md @@ -0,0 +1,203 @@ + + + + + + + + + + + + + 0007137: Uniqueness of items in assignment notation - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007137Part 01: TTCN-3 Core LanguageTechnicalpublic11-08-2015 14:5314-12-2015 11:29
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.7.1 (published 2015-06) 
Target Versionv4.8.1 (published 2016-07)Fixed in Versionv4.8.1 (published 2016-07) 
Clause Reference(s)6.2
Source (company - Author)STF 487
Summary0007137: Uniqueness of items in assignment notation
DescriptionThe current specification doesn't say whether the identifiers used in the assignment notation for records, sets, records-of, sets-of and arrays shall be unique or not.
+
+My impression is that it is allowed (because it doesn't seem to be forbidden), but it would be good to state that explicitly and describe the guidelines for this situation.
+
+However, maybe it would be a better and simpler to forbid using the same field reference inside the assignment notation more than once.
Steps To Reproduce
Additional Information
Tagstechnically agreed
Relationships
Attached Filesdocx CR7137_resolution_v1.docx (77,661) 23-09-2015 10:01
http://oldforge.etsi.org/mantis/file_download.php?file_id=3264&type=bug
docx CR7137_resolution_v2.docx (78,398) 23-09-2015 12:35
http://oldforge.etsi.org/mantis/file_download.php?file_id=3270&type=bug
Issue History
Date ModifiedUsernameFieldChange
11-08-2015 14:53Tomas UrbanNew Issue
21-09-2015 10:27Gyorgy RethyTarget Version => v4.8.1 (published 2016-07)
21-09-2015 15:04Gyorgy RethyTag Attached: technically agreed
21-09-2015 15:05Gyorgy RethyNote Added: 0013215
22-09-2015 16:22Axel RennochAssigned To => Axel Rennoch
22-09-2015 16:22Axel RennochStatusnew => assigned
23-09-2015 10:01Axel RennochFile Added: CR7137_resolution_v1.docx
23-09-2015 10:01Axel RennochNote Added: 0013249
23-09-2015 10:01Axel RennochAssigned ToAxel Rennoch => Jacob Wieland - Spirent
23-09-2015 10:01Axel RennochStatusassigned => confirmed
23-09-2015 12:35Jacob Wieland - SpirentFile Added: CR7137_resolution_v2.docx
23-09-2015 12:36Jacob Wieland - SpirentNote Added: 0013262
23-09-2015 12:37Jacob Wieland - SpirentStatusconfirmed => assigned
23-09-2015 12:37Jacob Wieland - SpirentNote Added: 0013263
23-09-2015 12:37Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
23-09-2015 12:37Jacob Wieland - SpirentStatusassigned => confirmed
03-11-2015 13:12Gyorgy RethyStatusconfirmed => resolved
03-11-2015 13:12Gyorgy RethyFixed in Version => v4.8.1 (published 2016-07)
03-11-2015 13:12Gyorgy RethyResolutionopen => fixed
14-12-2015 11:29Gyorgy RethyNote Added: 0013612
14-12-2015 11:29Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0013215) +
+ Gyorgy Rethy    +
+ 21-09-2015 15:05    +
+ 		+ + + + +
+ STF discussion: this is an error; field name shall be only once (like in value list notation the number of values shall not be more than the number of fields)
+
+
+
+ + + + + + + + + + +
+ (0013249) +
+ Axel Rennoch    +
+ 23-09-2015 10:01    +
+ 		+ + + + +
+ Please check the resolution.
+
+
+
+ + + + + + + + + + +
+ (0013262) +
+ Jacob Wieland - Spirent    +
+ 23-09-2015 12:36    +
+ 		+ + + + +
+ made statement about index-notation more precise (uniqueness of indices and conformity to index range)
+
+
+
+ + + + + + + + + + +
+ (0013263) +
+ Jacob Wieland - Spirent    +
+ 23-09-2015 12:37    +
+ 		+ + + + +
+ please review and resolve
+
+
+
+ + + + + + + + + + +
+ (0013612) +
+ Gyorgy Rethy    +
+ 14-12-2015 11:29    +
+ 		+ + + + +
+ Added to draft V4.7.4
+
+ + diff --git a/docs/mantis/CR7138.md b/docs/mantis/CR7138.md new file mode 100644 index 0000000000000000000000000000000000000000..1f361eb88b149be6b1214e1f746bdfafc0d871d0 --- /dev/null +++ b/docs/mantis/CR7138.md @@ -0,0 +1,271 @@ + + + + + + + + + + + + + 0007138: Missing rule on lower and upper bound of arrays - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007138Part 01: TTCN-3 Core LanguageClarificationpublic12-08-2015 10:0314-12-2015 11:14
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.7.1 (published 2015-06) 
Target Versionv4.8.1 (published 2016-07)Fixed in Versionv4.8.1 (published 2016-07) 
Clause Reference(s)6.2.7
Source (company - Author)STF 487
Summary0007138: Missing rule on lower and upper bound of arrays
DescriptionAlthough it might seem obvious to any thinking human being, the core language specification should still have an explicit rule saying that the upper bound of the range used for defining array dimension shall be greater than the lower bound.
Steps To Reproduce
Additional Information
Tagstechnically agreed
Relationships
Attached Filesdocx CR7138_resolution_v1.docx (81,872) 23-09-2015 11:31
http://oldforge.etsi.org/mantis/file_download.php?file_id=3266&type=bug
docx CR7138_resolution_v2.docx (82,764) 23-09-2015 12:14
http://oldforge.etsi.org/mantis/file_download.php?file_id=3269&type=bug
docx CR7138_resolution_v3.docx (82,653) 03-11-2015 13:41
http://oldforge.etsi.org/mantis/file_download.php?file_id=3353&type=bug
Issue History
Date ModifiedUsernameFieldChange
12-08-2015 10:03Tomas UrbanNew Issue
21-09-2015 10:27Gyorgy RethyTarget Version => v4.8.1 (published 2016-07)
21-09-2015 15:23Gyorgy RethyTag Attached: technically agreed
21-09-2015 15:25Gyorgy RethyNote Added: 0013217
22-09-2015 16:50Axel RennochAssigned To => Axel Rennoch
22-09-2015 16:50Axel RennochStatusnew => assigned
23-09-2015 11:31Axel RennochFile Added: CR7138_resolution_v1.docx
23-09-2015 11:32Axel RennochNote Added: 0013254
23-09-2015 11:32Axel RennochAssigned ToAxel Rennoch => Jacob Wieland - Spirent
23-09-2015 11:32Axel RennochStatusassigned => confirmed
23-09-2015 12:14Jacob Wieland - SpirentFile Added: CR7138_resolution_v2.docx
23-09-2015 12:16Jacob Wieland - SpirentNote Added: 0013260
23-09-2015 12:17Jacob Wieland - SpirentStatusconfirmed => assigned
23-09-2015 12:17Jacob Wieland - SpirentNote Added: 0013261
23-09-2015 12:17Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
23-09-2015 12:17Jacob Wieland - SpirentStatusassigned => confirmed
03-11-2015 13:41Gyorgy RethyFile Added: CR7138_resolution_v3.docx
03-11-2015 13:44Gyorgy RethyNote Added: 0013470
03-11-2015 13:44Gyorgy RethyAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
03-11-2015 13:44Gyorgy RethyStatusconfirmed => assigned
03-11-2015 14:46Jacob Wieland - SpirentNote Added: 0013475
03-11-2015 14:46Jacob Wieland - SpirentStatusassigned => resolved
03-11-2015 14:46Jacob Wieland - SpirentFixed in Version => v4.8.1 (published 2016-07)
03-11-2015 14:46Jacob Wieland - SpirentResolutionopen => fixed
03-11-2015 14:46Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
14-12-2015 11:14Gyorgy RethyNote Added: 0013609
14-12-2015 11:14Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0013217) +
+ Gyorgy Rethy    +
+ 21-09-2015 15:25    +
+ 		+ + + + +
+ STF discussion: length and index range upper bound shall be greater or equal to lower bound; add both for arrays and record/set ofs
+
+
+
+ + + + + + + + + + +
+ (0013254) +
+ Axel Rennoch    +
+ 23-09-2015 11:32    +
+ 		+ + + + +
+ Please check if resolution is sufficient.
+
+
+
+ + + + + + + + + + +
+ (0013260) +
+ Jacob Wieland - Spirent    +
+ 23-09-2015 12:16    +
+ 		+ + + + +
+ changed "be equal or greater (than|to)" to "not be lesser than".
+
+In the other case it would have to be "equal to or greater than" which I found clumsy.
+
+
+
+ + + + + + + + + + +
+ (0013261) +
+ Jacob Wieland - Spirent    +
+ 23-09-2015 12:17    +
+ 		+ + + + +
+ please check and resolve
+
+
+
+ + + + + + + + + + +
+ (0013470) +
+ Gyorgy Rethy    +
+ 03-11-2015 13:44    +
+ 		+ + + + +
+ CR7138_resolution_v3.docx: some editorial changes: range can be understood as range of values and also as a specific syntax; e.g. (5..5)|[5..5] has a range syntax, while specifying a single length value. Changes are aiming to clarify this aspect.
+
+Jacob, please review, if you agree, you can put it to resolved directly.
+
+
+
+ + + + + + + + + + +
+ (0013475) +
+ Jacob Wieland - Spirent    +
+ 03-11-2015 14:46    +
+ 		+ + + + +
+ ok
+
+
+
+ + + + + + + + + + +
+ (0013609) +
+ Gyorgy Rethy    +
+ 14-12-2015 11:14    +
+ 		+ + + + +
+ Added to draft V4.7.4
+
+ + diff --git a/docs/mantis/CR7139.md b/docs/mantis/CR7139.md new file mode 100644 index 0000000000000000000000000000000000000000..5dcdcf7867154b309c7bf8047b81ee51f10283ca --- /dev/null +++ b/docs/mantis/CR7139.md @@ -0,0 +1,844 @@ + + + + + + + + + + + + + 0007139: Unnecessary rule on uniqueness of enumerated values - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007139Part 01: TTCN-3 Core LanguageClarificationpublic13-08-2015 08:2811-12-2015 14:29
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritylowSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.7.1 (published 2015-06) 
Target Versionv4.8.1 (published 2016-07)Fixed in Versionv4.8.1 (published 2016-07) 
Clause Reference(s)6.2.4
Source (company - Author)STF 487
Summary0007139: Unnecessary rule on uniqueness of enumerated values
DescriptionThe section 6.2.4 states that: "The identifiers of enumerated values shall only be reused within other structured type definitions and shall not be used for identifiers of local or global visibility at the same or a lower level of the same branch of the scope hierarchy (see scope hierarchy in clause 5.2)."
+
+The scope of the enumerated values is the enumerated type itself. Thus, there can never be a conflict with an identifier that has a global visibility. And the rule forbidding reusing of identifiers inside the same enumerated type (i.e. at the same and lower scope) is already defined: "The identifiers of enumerated values shall be unique within the enumerated type (but do not have to be globally unique) and are consequently visible in the context of the given type only."
+
+For these reasons I find the above mentioned rule on global and local visibility superfluous and suggest that it should be dropped.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7139.docx (381,538) 04-11-2015 13:44
http://oldforge.etsi.org/mantis/file_download.php?file_id=3359&type=bug
docx CR7139_resolution_v2.docx (76,038) 04-11-2015 15:02
http://oldforge.etsi.org/mantis/file_download.php?file_id=3362&type=bug
Issue History
Date ModifiedUsernameFieldChange
13-08-2015 08:28Tomas UrbanNew Issue
13-08-2015 09:45Tomas UrbanNote Added: 0013153
13-08-2015 09:56Tomas UrbanNote Added: 0013154
13-08-2015 13:57Jacob Wieland - SpirentNote Added: 0013155
13-08-2015 14:26Tomas UrbanNote Added: 0013156
13-08-2015 14:37Jacob Wieland - SpirentNote Added: 0013157
13-08-2015 20:49Tomas UrbanNote Added: 0013158
14-08-2015 07:56Jacob Wieland - SpirentNote Added: 0013159
14-08-2015 09:18Tomas UrbanNote Added: 0013160
14-08-2015 12:34Jacob Wieland - SpirentNote Added: 0013161
14-08-2015 13:20Tomas UrbanNote Added: 0013162
14-08-2015 13:49Tomas UrbanNote Added: 0013165
14-08-2015 13:51Tomas UrbanNote Edited: 0013165bug_revision_view_page.php?bugnote_id=13165#r155
14-08-2015 13:51Tomas UrbanNote Edited: 0013165bug_revision_view_page.php?bugnote_id=13165#r156
17-08-2015 08:41Jacob Wieland - SpirentNote Added: 0013168
17-08-2015 09:32Tomas UrbanNote Added: 0013169
21-09-2015 10:27Gyorgy RethyTarget Version => v4.8.1 (published 2016-07)
21-09-2015 15:38Gyorgy RethyNote Added: 0013218
21-09-2015 15:39Gyorgy RethyPrioritynormal => low
03-11-2015 15:03Gyorgy RethyNote Added: 0013476
03-11-2015 15:03Gyorgy RethyAssigned To => Jacob Wieland - Spirent
03-11-2015 15:03Gyorgy RethyStatusnew => assigned
04-11-2015 13:44Jacob Wieland - SpirentFile Added: CR7139.docx
04-11-2015 13:51Jacob Wieland - SpirentNote Added: 0013486
04-11-2015 13:53Jacob Wieland - SpirentNote Added: 0013487
04-11-2015 13:53Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Jens Grabowski
04-11-2015 13:53Jacob Wieland - SpirentStatusassigned => confirmed
04-11-2015 14:52Gyorgy RethyFile Added: CR7139_resolution_v2.docx
04-11-2015 14:59Gyorgy RethyFile Deleted: CR7139_resolution_v2.docx
04-11-2015 15:02Gyorgy RethyFile Added: CR7139_resolution_v2.docx
04-11-2015 15:06Gyorgy RethyNote Added: 0013491
04-11-2015 15:06Gyorgy RethyAssigned ToJens Grabowski => Jacob Wieland - Spirent
04-11-2015 15:06Gyorgy RethyStatusconfirmed => assigned
04-11-2015 17:21Jacob Wieland - SpirentNote Added: 0013494
04-11-2015 17:21Jacob Wieland - SpirentStatusassigned => resolved
04-11-2015 17:21Jacob Wieland - SpirentFixed in Version => v4.8.1 (published 2016-07)
04-11-2015 17:21Jacob Wieland - SpirentResolutionopen => fixed
04-11-2015 17:21Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
11-12-2015 14:29Gyorgy RethyNote Added: 0013590
11-12-2015 14:29Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0013153) +
+ Tomas Urban    +
+ 13-08-2015 09:45    +
+ 		+ + + + +
+ The problem seems to be more complex. There is one place suggesting that the identifiers of enumerated values cannot be reused. The section 5.2.2 (uniqueness on identifiers) says that enumerated value identifiers can be reused only in other enumerated types: "Identifiers for fields of structured types, enumerated values and groups do not have to be globally unique, however in the case of enumerated values the identifiers shall only be reused for enumerated values within other enumerated types."
+
+However the code in the example 1 of 6.2.4 violates this rule completely and provides reasonable description suggesting a completely different behaviour which is inline with complex-specific resolution of enumerate value identifiers.
+
+In my opinion, the example is right and the rule on uniqueness should be removed. There has been a shift to context-specific interpretation of enumerated values in previous TTCN-3 specifications and I think that the uniqueness rule was just left unnoticed. Nevertheless, if I am mistaken, something has to be done with the example 1.
+
+There's also one additional rule that is affected by this issue: "When a TTCN-3 module parameter, formal parameter, constant, variable, non-parameterized template or parameterized template with all formal parameters having default values of an imported enumerated type is defined, the name of that definition shall not be the same as any of the enumerated values of that type."
+
+In case the uniqueness rule is dropped, then it is possible to create local definitions of an enumerated type reusing one of the enumerated value identifiers:
+
+module Module1 {
+  type enumerated Days { Monday, Tuesday, Wednesday }
+  control {
+    var Days v_day := Monday, Monday := Tuesday;
+    if (v_day == Monday) {...} //comparing v_day with an enumerated value
+    // but how to compare v_day and Monday variables?
+  }
+}
+
+The easy fix for this issue would be to remove the word "imported" from the above mentioned rule.
+
+
+
+ + + + + + + + + + +
+ (0013154) +
+ Tomas Urban    +
+ 13-08-2015 09:56    +
+ 		+ + + + +
+ In case of dropping the uniqueness rule, one more issue has to be addressed: the enumerated value identifiers have to take precedence over definitions. There's a rule for imported enumerations covering this issue in 8.2.3.1: "when in the context of an enumerated type (see clause 6.2.4), an enumerated value is clashing with the name of a definition in the importing module, the enumerated value shall take precedence and the definition in the importing module shall be referenced by using its qualified name (see example 4 below in this clause)."
+
+This rule should be valid to local definitions as well.
+
+
+
+ + + + + + + + + + +
+ (0013155) +
+ Jacob Wieland - Spirent    +
+ 13-08-2015 13:57    +
+ 		+ + + + +
+ Since it is a definite source of a possible error to define a thing of an enum type E with the same name as one of E's values, I would still forbid this, even if there is some rule that semantically defines this.
+
+imagine an enumeration E which does not have name V.
+
+I then declare
+
+var E V and subsequently use V.
+
+Later on, someone else changes E and adds V. Suddenly, my code means something completely different in all places where I use V in the context of E.
+
+This should be avoided and lead to an error, i.e. forcing me to rename (or forcing the other person to choose a different name)
+
+
+
+ + + + + + + + + + +
+ (0013156) +
+ Tomas Urban    +
+ 13-08-2015 14:26    +
+ 		+ + + + +
+ Jacob, I completely agree and I don't want to change this. My point is that the current TTCN-3 rules provide three different interpretations for reuse of identifiers:
+
+According to 5.2.2 the enumerated value identifier cannot be reused even in other structured types in the same module.
+
+6.2.4 allows the reuse in structured type, but it probably (because the text is not very comprehensive) doesn't allow the reuse e.g. as a name of a type which should be completely harmless.
+
+And there is also the importing rule - variables etc. of imported enum types cannot have the same name as one of the enumerated values. The rule is brilliant, the only problem is that it should be valid for all enumerations and not only for imported ones.
+
+My proposal is to drop the restrictions to a minimum: enumerated value identifiers can be reused anywhere with the exception of the enum type scope and values of the defining enumerated type.
+
+
+
+ + + + + + + + + + +
+ (0013157) +
+ Jacob Wieland - Spirent    +
+ 13-08-2015 14:37    +
+ 		+ + + + +
+ If I just understood what that means, I could agree. Alas, I don't.
+
+In my opinion, enum value-names could be re-used for anything except other value-names in the same enumerated type definition and all entities declared with the enumerated type as their type.
+
+Also, imagine the following situation:
+
+enumerated E1 { a }
+enumerated E2 { b }
+
+const E1 b := a;
+const E2 a := b;
+
+What does the expression (a == b) mean?
+
+
+
+ + + + + + + + + + +
+ (0013158) +
+ Tomas Urban    +
+ 13-08-2015 20:49    +
+ 		+ + + + +
+ > In my opinion, enum value-names could be re-used for anything except other value-names in the same enumerated type definition and all entities declared with the enumerated type as their type.
+
+Thumbs up for that. But compare it with the two problematic rules quoted above:
+
+"The identifiers of enumerated values shall only be reused within other structured type definitions and shall not be used for identifiers of local or global visibility at the same or a lower level of the same branch of the scope hierarchy (see scope hierarchy in clause 5.2)."
+
+"Identifiers for fields of structured types, enumerated values and groups do not have to be globally unique, however in the case of enumerated values the identifiers shall only be reused for enumerated values within other enumerated types."
+
+Do these rule support your interpretation? I don't think so. And I don't even think they are compatible. That's why I propose to remove them (and eventually replace with something better).
+
+Your example is indeed quite tricky. Because statements are typically processed in the textual order, I would expect "a" to be interpreted first as the constant "a" (for no enumeration context is known at that point - we just started processing) and "b" to be interpreted as the enumerated value "b" of the type E2 (as we can establish an implicit reference to the type E2 through the constant "a" at this point). The expression would then yield true.
+
+
+
+ + + + + + + + + + +
+ (0013159) +
+ Jacob Wieland - Spirent    +
+ 14-08-2015 07:56    +
+ 		+ + + + +
+ I totally disagree. Expressions are first evaluated for their syntactic and semantic properties and then evaluated.
+
+Otherwise, you could never write something like <enumValue> == <enumVariable> because enumValue has no enum context when processing from left to right.
+
+But, since a == b should always be equivalent to b == a for expressions a and b without side-effects, your approach would violate this rule.
+
+Sure, we already have that situation at the moment if two enums share the same values and then two values from that intersection are to be compared (as then the enum-context also cannot be determined) but in that situation at least only enum-values are involved and no additional potential clash with local items is possible.
+
+Basically, the rules as they are now do the following:
+
+They disallow the situation that I have described (as a and b would be disallowed in the same module to be redefined as constants) and they always allow to resolve nameclashes by prefixing. If an enum-value can shadow a local variable of the same type that is no longer the case, so that definitely needs to stay forbidden).
+
+
+
+ + + + + + + + + + +
+ (0013160) +
+ Tomas Urban    +
+ 14-08-2015 09:18    +
+ 		+ + + + +
+ > Otherwise, you could never write something like <enumValue> == <enumVariable> because enumValue has no enum context when processing from left to right.
+
+I don't agree with that statement. Processing from left to right only takes precedence. If it is not possible to use it, right to left is used as the second option and resolves the symbols without any problem.
+
+Your example is currently a valid code in TTCN-3, in case the enumeration types are imported to the module where constants "a" and "b" are defined. So how do you resolve it in this case, especially if constants are locally defined and cannot be prefixed?
+
+
+
+ + + + + + + + + + +
+ (0013161) +
+ Jacob Wieland - Spirent    +
+ 14-08-2015 12:34    +
+ 		+ + + + +
+ I disagree, at the moment it is invalid code because it is ambiguous. There is no rule that says that the left argument takes precedence over the right argument when determining enumeration context.
+
+In the case of local definitions, I would always give precedence to the local definition (as do all languages normally) and if it is a global definition, I can prefix the constant and therby establish unambiguity. (a must be defined in a different module than enum value a, same with b, so the module prefix determines which it is).
+
+
+
+ + + + + + + + + + +
+ (0013162) +
+ Tomas Urban    +
+ 14-08-2015 13:20    +
+ 		+ + + + +
+ > I disagree, at the moment it is invalid code because it is ambiguous.
+Please refer to the TTCN-3 rules which are violated in the example below.
+
+module Module1 {
+  type enumerated E1 { a }
+  type enumerated E2 { b }
+}
+
+module Module2 {
+  imports from Module1 all;
+  control {
+    const E1 b := a;
+    const E2 a := b;
+    log(a == b);
+  }
+}
+
+> In the case of local definitions, I would always give precedence to the local definition (as do all languages normally) and if it is a global definition, I can prefix the constant and therby establish unambiguity. (a must be defined in a different module than enum value a, same with b, so the module prefix determines which it is).
+
+Unfortunately, TTCN-3 does NOT behave this way. The rules of 8.2.3.1 (which I already mentioned here) describe quite unambiguously this situation: "There is one exception to this rule: when in the context of an enumerated type (see clause 6.2.4), an enumerated value is clashing with the name of a definition in the importing module, the enumerated value shall take precedence and the definition in the importing module shall be referenced by using its qualified name (see example 4 below in this clause)." Please open the specification and take a look at the example.
+
+But before you do that, just take a look at the discussion here. I actually don't try to defend any kind of interpretation. I would be fine with any as long as there's just one. My point is that the current rules just don't offer that. They are contradictory and contain blank spots.
+
+
+
+ + + + + + + + + + +
+ (0013165) +
+ Tomas Urban    +
+ 14-08-2015 13:49    +
(edited on: 14-08-2015 13:51)
+ 		+ + + + +
+ Maybe there's a simple solution for this situation:
+
+1. Enumerated value identifiers shall be unique just within the enumerated type
+2. Enumerated value identifiers can be reused for other definitions (in the module where the enumeration is defined, in importing modules and even for constant/variables/templates of the defining enumerated type)
+3. When resolving identifiers, global and local references are ALWAYS resolved first (i.e. if there's an enumerated value and a variable of the same name, it is always resolved as a variable even if it means type mismatch)
+4. In order to resolve name clashes, a new concept of extended enumerated value reference will be introduced: EnumeratedTypeReference.EnumeratedValue.
+
+What do you think?
+
+
+
+
+
+ + + + + + + + + + +
+ (0013168) +
+ Jacob Wieland - Spirent    +
+ 17-08-2015 08:41    +
+ 		+ + + + +
+ In principle, in a language where there is no other overloading, I like this approach much better than what we have now, but I'm sure that this change is not backward-compatible. (In pathological cases, of course. At the moment, it is allowed to have an integer-variable i and an enum-value i).
+
+type enumerated E { i }
+
+function(integer i, E e) {
+  if (e == i) { // enum interpretation of i
+  }
+  if (3 == i) { // integer interpretation of i
+  }
+}
+
+function g() {
+  var integer i := 3;
+  f(i, i); // first i is the integer variable, second i is the enum value
+}
+
+So, to preserve this (unambiguous) behavior, I would suggest that only in type-ambiguous cases of name-clashing identifiers (where the enum-context cannot be unambiguously established), local definitions shall have precedence before the enum value (and then the clash can be resolved towards the enum-value by prefixing with the enum type - which at the moment I always do with valueof(E:v) ;-)).
+
+So, the a == b example in this case would then cause an error as it would resolve both a and b to the constants and their types are not compatible. The user would have to add an enum-type-prefix either before a or b or add a module-prefix before a or b (if they are global) to establish an unambiguous enum-context.
+
+
+
+ + + + + + + + + + +
+ (0013169) +
+ Tomas Urban    +
+ 17-08-2015 09:32    +
+ 		+ + + + +
+ I have no problem with this solution. It might require more rules to describe, but backwards compatibility is important and the compiler might always issue a warning in the cases where prefixing would make code more readable. I am looking forward for the proposal draft.
+
+
+
+ + + + + + + + + + +
+ (0013218) +
+ Gyorgy Rethy    +
+ 21-09-2015 15:38    +
+ 		+ + + + +
+ STF discussion: CR is low priority, because the restriction does not cause a problem.
+
+
+
+ + + + + + + + + + +
+ (0013476) +
+ Gyorgy Rethy    +
+ 03-11-2015 15:03    +
+ 		+ + + + +
+ STF discussion: analyse if the other enumerated rules restricting enumeration value names are covering all possible name clashing scenarios.
+
+
+
+ + + + + + + + + + +
+ (0013486) +
+ Jacob Wieland - Spirent    +
+ 04-11-2015 13:51    +
+ 		+ + + + +
+ aligned the description in 5.2 with the one in 6.2.4, i.e. enum values in a module can be used as other enum values or as fields of structured types but nothing else.
+
+The reasoning is that the existing restrictions align the feature with the rest of the language:
+- no shadowing/overloading in the same module (re-using constant name as type name is also not allowed, but would in principle not be a problem) - except for enumerated values
+- name-clashes between local variable and imported value can always be resolved by module-prefixing (no new enumtype-prefixing context needed)
+
+
+
+ + + + + + + + + + +
+ (0013487) +
+ Jacob Wieland - Spirent    +
+ 04-11-2015 13:53    +
+ 		+ + + + +
+ please review and resolve
+
+
+
+ + + + + + + + + + +
+ (0013491) +
+ Gyorgy Rethy    +
+ 04-11-2015 15:06    +
+ 		+ + + + +
+ CR7139_resolution_v2.docx: the addition to clause 6.2.4 is true within a module only. In other modules, importing the enumerated type, enumeration names can be used as names of non-enumerated definitions. This is the whole "context business" about.
+
+Please review.
+
+
+
+ + + + + + + + + + +
+ (0013494) +
+ Jacob Wieland - Spirent    +
+ 04-11-2015 17:21    +
+ 		+ + + + +
+ I think the addition is redundant as the scope of the whole paragraph is talking about the uniqueness inside one module scope. But, it doesn't hurt, either, so we can leave it as is.
+
+
+
+ + + + + + + + + + +
+ (0013590) +
+ Gyorgy Rethy    +
+ 11-12-2015 14:29    +
+ 		+ + + + +
+ Added to draft V4.7.4
+
+ + diff --git a/docs/mantis/CR7140.md b/docs/mantis/CR7140.md new file mode 100644 index 0000000000000000000000000000000000000000..6ef8accfed3a785e1986dfbe5ed87f3193743247 --- /dev/null +++ b/docs/mantis/CR7140.md @@ -0,0 +1,212 @@ + + + + + + + + + + + + + 0007140: Templates not allowed in the value part of the reply operation - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007140Part 01: TTCN-3 Core LanguageTechnicalpublic14-08-2015 10:4011-12-2015 14:48
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.7.1 (published 2015-06) 
Target Versionv4.8.1 (published 2016-07)Fixed in Versionv4.8.1 (published 2016-07) 
Clause Reference(s)22.3.3
Source (company - Author)STF 487
Summary0007140: Templates not allowed in the value part of the reply operation
DescriptionAll communication operations for outgoing traffic allow to use templates (conforming to the value restriction) in their parameters. However, there's one exception to this paradigm - the value clause of the reply operation which is defined in the BNF as:
+
+322.ReplyValue ::= ValueKeyword Expression
+
+And in 22.3.3 as:
+Port "." reply "(" TemplateInstance [ value Expression ] ")" [ to Address ]
+
+In my opinion the value part of the reply operation should support template instances as well:
+
+322.ReplyValue ::= ValueKeyword InLineTemplate
+
+Syntactical structure of 22.3.3: Port "." reply "(" TemplateInstance [ value TemplateInstance ] ")" [ to Address ]
+
+The restriction 22.3.3.e should be extended: The TemplateInstance in the value clause (and all parts of it) shall have a specific value i.e. the use of matching mechanisms such as AnyValue is not allowed.
Steps To Reproduce
Additional Information
Tagstechnically agreed
Relationships
related to 0007184closed Gyorgy Rethy Template instance in the value part of reply operations 
Attached Filesdocx CR7140_resolution_v1.docx (86,678) 23-09-2015 15:02
http://oldforge.etsi.org/mantis/file_download.php?file_id=3273&type=bug
docx CR7140_resolution_v2.docx (90,056) 23-09-2015 15:40
http://oldforge.etsi.org/mantis/file_download.php?file_id=3274&type=bug
Issue History
Date ModifiedUsernameFieldChange
14-08-2015 10:40Tomas UrbanNew Issue
21-09-2015 10:27Gyorgy RethyTarget Version => v4.8.1 (published 2016-07)
21-09-2015 15:39Gyorgy RethyTag Attached: technically agreed
21-09-2015 15:42Gyorgy RethyNote Added: 0013219
23-09-2015 11:38Axel RennochAssigned To => Axel Rennoch
23-09-2015 11:38Axel RennochStatusnew => assigned
23-09-2015 15:02Axel RennochFile Added: CR7140_resolution_v1.docx
23-09-2015 15:05Axel RennochNote Added: 0013271
23-09-2015 15:05Axel RennochAssigned ToAxel Rennoch => Jacob Wieland - Spirent
23-09-2015 15:05Axel RennochStatusassigned => acknowledged
23-09-2015 15:40Jacob Wieland - SpirentFile Added: CR7140_resolution_v2.docx
23-09-2015 15:41Jacob Wieland - SpirentNote Added: 0013277
23-09-2015 15:42Jacob Wieland - SpirentNote Added: 0013278
23-09-2015 15:42Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
23-09-2015 15:42Jacob Wieland - SpirentStatusacknowledged => confirmed
25-09-2015 11:41Gyorgy RethyStatusconfirmed => resolved
25-09-2015 11:41Gyorgy RethyFixed in Version => v4.8.1 (published 2016-07)
25-09-2015 11:41Gyorgy RethyResolutionopen => fixed
15-10-2015 13:13Jacob Wieland - SpirentRelationship addedrelated to 0007184
11-12-2015 14:48Gyorgy RethyNote Added: 0013592
11-12-2015 14:48Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0013219) +
+ Gyorgy Rethy    +
+ 21-09-2015 15:42    +
+ 		+ + + + +
+ STF discussion: comment correct, but TemplateBody is sufficient in the "value" part
+
+
+
+ + + + + + + + + + +
+ (0013271) +
+ Axel Rennoch    +
+ 23-09-2015 15:05    +
+ 		+ + + + +
+ Please check the resolution that allows both Expression and TemplateBody.
+
+
+
+ + + + + + + + + + +
+ (0013277) +
+ Jacob Wieland - Spirent    +
+ 23-09-2015 15:41    +
+ 		+ + + + +
+ since TemplateBody already encompasses everything from Expression, I simplified/disambiguated Expression | TemplateBody to only TemplateBody. Also, I have simplified the text to avoid redundancy.
+
+
+
+ + + + + + + + + + +
+ (0013278) +
+ Jacob Wieland - Spirent    +
+ 23-09-2015 15:42    +
+ 		+ + + + +
+ please review and resolve
+
+
+
+ + + + + + + + + + +
+ (0013592) +
+ Gyorgy Rethy    +
+ 11-12-2015 14:48    +
+ 		+ + + + +
+ Added to draft V4.7.4
+
+ + diff --git a/docs/mantis/CR7141.md b/docs/mantis/CR7141.md new file mode 100644 index 0000000000000000000000000000000000000000..1aff7225690f98b17be7b8d5350da981f422311d --- /dev/null +++ b/docs/mantis/CR7141.md @@ -0,0 +1,286 @@ + + + + + + + + + + + + + 0007141: Strong typing rules - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007141Part 01: TTCN-3 Core LanguageClarificationpublic14-08-2015 12:5011-12-2015 15:03
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritylowSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.7.1 (published 2015-06) 
Target Versionv4.8.1 (published 2016-07)Fixed in Versionv4.8.1 (published 2016-07) 
Clause Reference(s)6.3.4
Source (company - Author)STF 487
Summary0007141: Strong typing rules
DescriptionThe current rules on strong typing specified in 6.3.4 say: The types of values or templates directly used as parameters to these operations [send, receive, trigger, call, getcall, reply, getreply and raise and connection operations connect, map, disconnect and unmap] shall also be explicitly defined in the associated port type definition.
+
+This rule is fine for the send and receive operation, but not applicable to the remaining operations. In case of procedure-based communication operations, there are several problems:
+1. Associated port type definition doesn't contain types in this case, but signatures. TTCN-3 doesn't allow to create signature aliases, thus signature templates are implicitly strongly typed.
+2. In case of the reply and getreply operation, it is not obvious whether the value part shall be strongly typed or not. The existing rule is not helpful (even if we consider signature to be a type) as the return value type is defined in the signature and not in the associated port definition. In theory, strong typing is not necessary as the return value type is implicitly available through the signature template and the provided value/template can be safely converted to this type.
+3. In case of the raise and catch operation, the exception value type is again not explicitly defined in the associated port type definition. Correct statement would be that the signature shall be explicitly defined in the associated port type definition and the exception value/template type shall be explicitly defined in the signature exception list. Strong typing is required in this case as the exception list might contain several distinct compatible types.
+
+For the map, unmap and component operation, the rule doesn't make sense either. Strong typing is related to the system, runs on and mtc clauses in this case - it is used to verify that ports used as parameters of these calls are present in the component.
+
+It should be also explained whether strong typing is applied to the to/from clause and if so how exaclty it works.
+
+Proposal: Rewording required to address all above mentioned issues.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7141_resolution_v1.docx (77,459) 03-11-2015 09:05
http://oldforge.etsi.org/mantis/file_download.php?file_id=3343&type=bug
docx CR7141_resolution_v2.docx (93,366) 03-11-2015 10:20
http://oldforge.etsi.org/mantis/file_download.php?file_id=3344&type=bug
docx CR7149_resolution_v3.docx (68,376) 04-11-2015 10:09
http://oldforge.etsi.org/mantis/file_download.php?file_id=3356&type=bug
Issue History
Date ModifiedUsernameFieldChange
14-08-2015 12:50Tomas UrbanNew Issue
21-09-2015 10:27Gyorgy RethyTarget Version => v4.8.1 (published 2016-07)
21-09-2015 15:53Gyorgy RethyNote Added: 0013220
21-09-2015 15:54Gyorgy RethyPrioritynormal => low
02-11-2015 15:40Axel RennochAssigned To => Axel Rennoch
02-11-2015 15:40Axel RennochStatusnew => assigned
03-11-2015 09:05Axel RennochFile Added: CR7141_resolution_v1.docx
03-11-2015 09:07Axel RennochNote Added: 0013450
03-11-2015 09:09Axel RennochNote Added: 0013451
03-11-2015 09:09Axel RennochAssigned ToAxel Rennoch => Jacob Wieland - Spirent
03-11-2015 09:09Axel RennochStatusassigned => feedback
03-11-2015 10:19Jacob Wieland - SpirentNote Added: 0013455
03-11-2015 10:20Jacob Wieland - SpirentFile Added: CR7141_resolution_v2.docx
03-11-2015 10:20Jacob Wieland - SpirentNote Added: 0013456
03-11-2015 10:20Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Jens Grabowski
03-11-2015 10:20Jacob Wieland - SpirentStatusfeedback => confirmed
04-11-2015 10:09Jens GrabowskiFile Added: CR7149_resolution_v3.docx
04-11-2015 10:09Jens GrabowskiNote Added: 0013483
04-11-2015 10:09Jens GrabowskiAssigned ToJens Grabowski =>
04-11-2015 10:10Jens GrabowskiAssigned To => Gyorgy Rethy
04-11-2015 10:10Jens GrabowskiStatusconfirmed => resolved
04-11-2015 14:03Gyorgy RethyFixed in Version => v4.8.1 (published 2016-07)
11-12-2015 15:03Gyorgy RethyNote Added: 0013597
11-12-2015 15:03Gyorgy RethyStatusresolved => closed
11-12-2015 15:03Gyorgy RethyResolutionopen => fixed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0013220) +
+ Gyorgy Rethy    +
+ 21-09-2015 15:53    +
+ 		+ + + + +
+ STF discussion: CR to be handled with low prioriy
+
+
+
+ + + + + + + + + + +
+ (0013450) +
+ Axel Rennoch    +
+ 03-11-2015 09:07    +
+ 		+ + + + +
+ uploaded file considers the CR and removes a contradiction with section 22.2.2 that does not require strong typing for the assignment of messages in receive/trigger operations.
+
+
+
+ + + + + + + + + + +
+ (0013451) +
+ Axel Rennoch    +
+ 03-11-2015 09:09    +
+ 		+ + + + +
+ Please review the current resolution_v1 and consider additional rewording for further improvements.
+
+
+
+ + + + + + + + + + +
+ (0013455) +
+ Jacob Wieland - Spirent    +
+ 03-11-2015 10:19    +
+ 		+ + + + +
+ removed additional restriction to connection operations (no such restriction is necessary, would be backward incompatible)
+
+Also reworded the description referencing the different cases:
+- values of send, receive, trigger
+- parameter signatures of call, getcall, reply, getreply
+- signature type of catch and raise
+- exceptions of catch and raise
+
+For return value part of reply/getreply and for parameters contained in the signature-template for call/getcall/reply/getreply, no strong typing is necessary.
+
+
+
+ + + + + + + + + + +
+ (0013456) +
+ Jacob Wieland - Spirent    +
+ 03-11-2015 10:20    +
+ 		+ + + + +
+ please review and resolve
+
+
+
+ + + + + + + + + + +
+ (0013483) +
+ Jens Grabowski    +
+ 04-11-2015 10:09    +
+ 		+ + + + +
+ Two typos removed. Set to resolved and assigned to György.
+
+
+
+ + + + + + + + + + +
+ (0013597) +
+ Gyorgy Rethy    +
+ 11-12-2015 15:03    +
+ 		+ + + + +
+ Added to draft V4.7.4
+
+ + diff --git a/docs/mantis/CR7142.md b/docs/mantis/CR7142.md new file mode 100644 index 0000000000000000000000000000000000000000..242d43629cb6ee3f2d9df02db6746214632c6be6 --- /dev/null +++ b/docs/mantis/CR7142.md @@ -0,0 +1,99 @@ + + + + + + + + + + + + + 0007142: Terminology in example on expressions - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007142Part 01: TTCN-3 Core LanguageEditorialpublic17-08-2015 09:4509-12-2015 16:45
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritylowSeveritytrivialReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.7.1 (published 2015-06) 
Target Versionv4.8.1 (published 2016-07)Fixed in Versionv4.8.1 (published 2016-07) 
Clause Reference(s)7
Source (company - Author)STF 487
Summary0007142: Terminology in example on expressions
DescriptionThe example on expressions in the section 7 contains the following note: // compound expression, field expression list
+
+"Field expression list" is not a standard term for this kind of compound expression and this is the only place in the specification where it is used. The correct term would be "assignment notation" or "field assignment notation".
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7142_resolution.docx (168,792) 15-10-2015 13:39
http://oldforge.etsi.org/mantis/file_download.php?file_id=3319&type=bug
Issue History
Date ModifiedUsernameFieldChange
17-08-2015 09:45Tomas UrbanNew Issue
21-09-2015 10:27Gyorgy RethyTarget Version => v4.8.1 (published 2016-07)
21-09-2015 15:55Gyorgy RethyNote Added: 0013221
21-09-2015 15:55Gyorgy RethyAssigned To => Gyorgy Rethy
21-09-2015 15:55Gyorgy RethyStatusnew => assigned
15-10-2015 13:39Jacob Wieland - SpirentFile Added: CR7142_resolution.docx
15-10-2015 13:39Jacob Wieland - SpirentStatusassigned => resolved
15-10-2015 13:39Jacob Wieland - SpirentResolutionopen => fixed
04-11-2015 14:03Gyorgy RethyFixed in Version => v4.8.1 (published 2016-07)
09-12-2015 16:45Gyorgy RethyNote Added: 0013577
09-12-2015 16:45Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0013221) +
+ Gyorgy Rethy    +
+ 21-09-2015 15:55    +
+ 		+ + + + +
+ STF discussion: let use assignment notation
+
+
+
+ + + + + + + + + + +
+ (0013577) +
+ Gyorgy Rethy    +
+ 09-12-2015 16:45    +
+ 		+ + + + +
+ Added to draft V4.7.4
+
+ + diff --git a/docs/mantis/CR7143.md b/docs/mantis/CR7143.md new file mode 100644 index 0000000000000000000000000000000000000000..dce6bf3c73edc95abc8d3abf64ca32ce146b5678 --- /dev/null +++ b/docs/mantis/CR7143.md @@ -0,0 +1,220 @@ + + + + + + + + + + + + + 0007143: Compound expression for union and anytype - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007143Part 01: TTCN-3 Core LanguageClarificationpublic17-08-2015 10:0114-12-2015 13:41
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.7.1 (published 2015-06) 
Target Versionv4.8.1 (published 2016-07)Fixed in Versionv4.8.1 (published 2016-07) 
Clause Reference(s)7
Source (company - Author)STF 487
Summary0007143: Compound expression for union and anytype
DescriptionThe section 7 rule says that "compound expressions are used for expressions of array, record, record of and set of types".
+
+In my opinion, compound expressions should be allowed for union and anytype too.
+// Having the following definitions:
+type union U {
+  integer option1,
+  charstring option2
+}
+...
+var U v_union;
+var anytype v_any;
+
+// it is faster to write
+if (v_union == { option1 := 1 }) {...}
+if (v_any == { integer := 1}) {...}
+
+// than
+if (ischosen(v_union.option1) and v_union.option1 == 1) {...}
+if (ischosen(v_any.integer) and v_any.integer == 1) {...}
+
+// the produced executable should be slightly more efficient too
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7143_resolution.docx (168,564) 15-10-2015 13:23
http://oldforge.etsi.org/mantis/file_download.php?file_id=3317&type=bug
Issue History
Date ModifiedUsernameFieldChange
17-08-2015 10:01Tomas UrbanNew Issue
17-08-2015 10:12Tomas UrbanNote Added: 0013170
21-09-2015 10:27Gyorgy RethyTarget Version => v4.8.1 (published 2016-07)
21-09-2015 12:15Gyorgy RethyNote Added: 0013201
21-09-2015 15:56Gyorgy RethyNote Added: 0013222
21-09-2015 15:56Gyorgy RethyAssigned To => Gyorgy Rethy
21-09-2015 15:56Gyorgy RethyStatusnew => assigned
15-10-2015 13:23Jacob Wieland - SpirentFile Added: CR7143_resolution.docx
15-10-2015 13:23Jacob Wieland - SpirentNote Added: 0013407
15-10-2015 13:23Jacob Wieland - SpirentStatusassigned => confirmed
03-11-2015 09:19Gyorgy RethyStatusconfirmed => resolved
03-11-2015 09:19Gyorgy RethyFixed in Version => v4.8.1 (published 2016-07)
03-11-2015 09:19Gyorgy RethyResolutionopen => fixed
14-12-2015 13:41Gyorgy RethyNote Added: 0013620
14-12-2015 13:41Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0013170) +
+ Tomas Urban    +
+ 17-08-2015 10:12    +
+ 		+ + + + +
+ For some reason, the set type is also missing from the same rule.
+
+
+
+ + + + + + + + + + +
+ (0013201) +
+ Gyorgy Rethy    +
+ 21-09-2015 12:15    +
+ 		+ + + + +
+ Of course, the "faster syntax" is allowed, let check and correct rule in section 7.
+
+
+
+ + + + + + + + + + +
+ (0013222) +
+ Gyorgy Rethy    +
+ 21-09-2015 15:56    +
+ 		+ + + + +
+ STF discussion: add union and set to the sentence.
+
+
+
+ + + + + + + + + + +
+ (0013407) +
+ Jacob Wieland - Spirent    +
+ 15-10-2015 13:23    +
+ 		+ + + + +
+ added union, set and anytype
+
+
+
+ + + + + + + + + + +
+ (0013620) +
+ Gyorgy Rethy    +
+ 14-12-2015 13:41    +
+ 		+ + + + +
+ Added to draft V4.7.4
+
+ + diff --git a/docs/mantis/CR7144.md b/docs/mantis/CR7144.md new file mode 100644 index 0000000000000000000000000000000000000000..dcf0d638d061ba7448233af64f77f8318d16de1d --- /dev/null +++ b/docs/mantis/CR7144.md @@ -0,0 +1,218 @@ + + + + + + + + + + + + + 0007144: Restriction on blocking operations in else branch - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007144Part 01: TTCN-3 Core LanguageClarificationpublic17-08-2015 14:5014-12-2015 13:39
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.7.1 (published 2015-06) 
Target Versionv4.8.1 (published 2016-07)Fixed in Versionv4.8.1 (published 2016-07) 
Clause Reference(s)20.2
Source (company - Author)STF 487
Summary0007144: Restriction on blocking operations in else branch
DescriptionThe restriction 20.2.e states that "The else branch shall not contain any of the actions allowed in branches guarded by a boolean expression (i.e. an altstep call or a done, a killed, a timeout or a receiving operation)."
+
+This is quite ambiguous statement, because the specification doesn't clearly specify what a branch exactly includes. In particular, it is not known if the term "branch" means just the blocking statement or if it includes the following statement block as well.
+
+If branches included the statement block, the restriction would mean that nothing can be inside the else branch (as almost anything can appear inside a statement block) which is simply nonsense. Nevertheless, there is a lot of other rules hinting in the direction that branches do include subsequent statement blocks.
+
+If the previous interpretation is ignored, there are two other explanations of the restriction:
+
+1. The term "branch" means the just a blocking operation in this case. Since the else branch simply doesn't have any, it is just a textual description of the syntactical rule.
+
+2. The statement means that even the statement block following the [else] keyword cannot contain any of the blocking operations. This restriction wouldn't make much sense as nested alts are allowed in other branches, but one of my colleagues interprets the rule this way.
+
+In any case, I propose to reword the statement. Because I prefer the 1st explanation, I would like the restriction to be changed to: the statement block of the else branch shall not be preceded (alternatively: the [else] keyword shall not be followed) by any of the blocking actions that might occur in the beginning of branches guarded by a boolean expression (i.e. an altstep call or a done, a killed, a timeout or a receiving operation).
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7144_resolution_v1.docx (176,484) 15-10-2015 12:46
http://oldforge.etsi.org/mantis/file_download.php?file_id=3315&type=bug
Issue History
Date ModifiedUsernameFieldChange
17-08-2015 14:50Tomas UrbanNew Issue
21-09-2015 10:27Gyorgy RethyTarget Version => v4.8.1 (published 2016-07)
21-09-2015 16:04Gyorgy RethyNote Added: 0013223
21-09-2015 16:04Gyorgy RethyAssigned To => Jens Grabowski
21-09-2015 16:04Gyorgy RethyStatusnew => assigned
23-09-2015 09:24Jens GrabowskiNote Added: 0013247
23-09-2015 09:25Jens GrabowskiAssigned ToJens Grabowski => Gyorgy Rethy
15-10-2015 12:46Jacob Wieland - SpirentFile Added: CR7144_resolution_v1.docx
15-10-2015 12:47Jacob Wieland - SpirentNote Added: 0013402
15-10-2015 12:47Jacob Wieland - SpirentNote Added: 0013403
15-10-2015 12:47Jacob Wieland - SpirentStatusassigned => confirmed
03-11-2015 09:23Gyorgy RethyStatusconfirmed => resolved
03-11-2015 09:23Gyorgy RethyFixed in Version => v4.8.1 (published 2016-07)
03-11-2015 09:23Gyorgy RethyResolutionopen => fixed
14-12-2015 13:39Gyorgy RethyNote Added: 0013619
14-12-2015 13:39Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0013223) +
+ Gyorgy Rethy    +
+ 21-09-2015 16:04    +
+ 		+ + + + +
+ STF discussion: check in the OS if there would be any problem if deleting the restriction.
+
+
+
+ + + + + + + + + + +
+ (0013247) +
+ Jens Grabowski    +
+ 23-09-2015 09:24    +
+ 		+ + + + +
+ The CR is correct and 20.2.e has to be corrected.
+
+Proposal for correction:
+
+"e) In an else branch, the [else] keyword shall not shall not be followed by any of the blocking actions allowed in branches guarded by a boolean expression
+(i.e. an altstep call or a done, a killed, a timeout or a receiving operation)."
+
+Assigned to György for proofreading.
+
+
+
+ + + + + + + + + + +
+ (0013402) +
+ Jacob Wieland - Spirent    +
+ 15-10-2015 12:47    +
+ 		+ + + + +
+ since the syntactical structure already reflects this restriction, a semantic restriction is not necessary. Replaced the text in restriction e) by Void.
+
+
+
+ + + + + + + + + + +
+ (0013403) +
+ Jacob Wieland - Spirent    +
+ 15-10-2015 12:47    +
+ 		+ + + + +
+ please review and resolve
+
+
+
+ + + + + + + + + + +
+ (0013619) +
+ Gyorgy Rethy    +
+ 14-12-2015 13:39    +
+ 		+ + + + +
+ Added to draft V4.7.4
+
+ + diff --git a/docs/mantis/CR7146.md b/docs/mantis/CR7146.md new file mode 100644 index 0000000000000000000000000000000000000000..bbae756c3a6f020ce9188de535a16fe38d6493a2 --- /dev/null +++ b/docs/mantis/CR7146.md @@ -0,0 +1,201 @@ + + + + + + + + + + + + + 0007146: Operations missing in the list of forbidden port operations - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007146Part 01: TTCN-3 Core LanguageClarificationpublic18-08-2015 11:5414-12-2015 15:01
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.7.1 (published 2015-06) 
Target Versionv4.8.1 (published 2016-07)Fixed in Versionv4.8.1 (published 2016-07) 
Clause Reference(s)16.1.4
Source (company - Author)STF 487
Summary0007146: Operations missing in the list of forbidden port operations
DescriptionThe restriction b of the section 16.1.4 says that all port operations are disallowed, followed by a list of forbidden operations. The list unfortunatelly doesn't contain all port operations; the only missing entries are disconnect, unmap and checkstate. The first two operations are mentioned in the note 3 though.
+
+Proposal: add disconnet, unmap and checkstate to the restriction.
Steps To Reproduce
Additional Information
Tagstechnically agreed
Relationships
related to 0007147closed Gyorgy Rethy Operation with side effects in alt statemets 
Attached Filesdocx CR7146_resolution_v1.docx (77,244) 24-09-2015 12:37
http://oldforge.etsi.org/mantis/file_download.php?file_id=3279&type=bug
Issue History
Date ModifiedUsernameFieldChange
18-08-2015 11:54Tomas UrbanNew Issue
19-08-2015 08:53Jacob Wieland - SpirentNote Added: 0013171
21-09-2015 10:27Gyorgy RethyTarget Version => v4.8.1 (published 2016-07)
21-09-2015 16:10Gyorgy RethyNote Added: 0013224
21-09-2015 16:11Gyorgy RethyTag Attached: technically agreed
21-09-2015 16:17Gyorgy RethyRelationship addedrelated to 0007147
23-09-2015 15:48Axel RennochAssigned To => Axel Rennoch
23-09-2015 15:48Axel RennochStatusnew => assigned
24-09-2015 12:37Axel RennochFile Added: CR7146_resolution_v1.docx
24-09-2015 12:38Axel RennochNote Added: 0013287
24-09-2015 12:38Axel RennochAssigned ToAxel Rennoch => Jacob Wieland - Spirent
24-09-2015 12:38Axel RennochStatusassigned => acknowledged
24-09-2015 14:04Jacob Wieland - SpirentNote Added: 0013290
24-09-2015 14:04Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
24-09-2015 14:04Jacob Wieland - SpirentStatusacknowledged => confirmed
02-11-2015 15:59Gyorgy RethyStatusconfirmed => resolved
02-11-2015 15:59Gyorgy RethyFixed in Version => v4.8.1 (published 2016-07)
02-11-2015 15:59Gyorgy RethyResolutionopen => fixed
14-12-2015 15:01Gyorgy RethyNote Added: 0013624
14-12-2015 15:01Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0013171) +
+ Jacob Wieland - Spirent    +
+ 19-08-2015 08:53    +
+ 		+ + + + +
+ Maybe it would be better to just remove the specific list and add an exception later if there should be one.
+
+
+
+ + + + + + + + + + +
+ (0013224) +
+ Gyorgy Rethy    +
+ 21-09-2015 16:10    +
+ 		+ + + + +
+ STF discussion: to be checked in detail.
+
+
+
+ + + + + + + + + + +
+ (0013287) +
+ Axel Rennoch    +
+ 24-09-2015 12:38    +
+ 		+ + + + +
+ Please have a look to the modification in the resolution.
+
+
+
+ + + + + + + + + + +
+ (0013290) +
+ Jacob Wieland - Spirent    +
+ 24-09-2015 14:04    +
+ 		+ + + + +
+ looks good to me
+
+
+
+ + + + + + + + + + +
+ (0013624) +
+ Gyorgy Rethy    +
+ 14-12-2015 15:01    +
+ 		+ + + + +
+ Added to draft V4.7.4
+
+ + diff --git a/docs/mantis/CR7147.md b/docs/mantis/CR7147.md new file mode 100644 index 0000000000000000000000000000000000000000..4fc3b017840f49c68c80aa62fb49913bbbe3c6b0 --- /dev/null +++ b/docs/mantis/CR7147.md @@ -0,0 +1,237 @@ + + + + + + + + + + + + + 0007147: Operation with side effects in alt statemets - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007147Part 01: TTCN-3 Core LanguageTechnicalpublic18-08-2015 12:1114-12-2015 11:41
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.7.1 (published 2015-06) 
Target Versionv4.8.1 (published 2016-07)Fixed in Versionv4.8.1 (published 2016-07) 
Clause Reference(s)20.2
Source (company - Author)STF 487
Summary0007147: Operation with side effects in alt statemets
DescriptionThe restrictions b, c and d of the section 20.2 disallow the use of certain operations in alt guards, alt branch events and parameters of altstep instances in alt branches. The forbidden operations are a subset of calls listed in 16.1.4. In particular, only the operations that can be used in expressions are listed.
+
+However, the list (composed of create, running, alive and activate) is not complete. There are several other operations with side effect that might syntactically appear in expressions: read, checkstate, rnd, non-deterministic external function invocation (the last two are not covered by 16.1.4, because that section states only that they shall not appear INSIDE of functions called from the special places, but nothing about direct invocation).
+
+Proposal: add the missing operations to the restrictions b, c and d.
Steps To Reproduce
Additional Information
Tagstechnically agreed
Relationships
related to 0007146closed Gyorgy Rethy Operations missing in the list of forbidden port operations 
Attached Filesdocx CR7147_resolution_v1.docx (84,450) 24-09-2015 12:38
http://oldforge.etsi.org/mantis/file_download.php?file_id=3280&type=bug
docx CR7147_resolution_v2.docx (84,752) 24-09-2015 16:04
http://oldforge.etsi.org/mantis/file_download.php?file_id=3284&type=bug
docx CR7147_resolution_v3.docx (85,080) 03-11-2015 11:15
http://oldforge.etsi.org/mantis/file_download.php?file_id=3348&type=bug
Issue History
Date ModifiedUsernameFieldChange
18-08-2015 12:11Tomas UrbanNew Issue
21-09-2015 10:27Gyorgy RethyTarget Version => v4.8.1 (published 2016-07)
21-09-2015 16:16Gyorgy RethyTag Attached: technically agreed
21-09-2015 16:17Gyorgy RethyRelationship addedrelated to 0007146
21-09-2015 16:17Gyorgy RethyNote Added: 0013225
23-09-2015 15:48Axel RennochAssigned To => Axel Rennoch
23-09-2015 15:48Axel RennochStatusnew => assigned
24-09-2015 12:38Axel RennochFile Added: CR7147_resolution_v1.docx
24-09-2015 12:41Axel RennochNote Added: 0013288
24-09-2015 12:41Axel RennochAssigned ToAxel Rennoch => Jacob Wieland - Spirent
24-09-2015 12:41Axel RennochStatusassigned => acknowledged
24-09-2015 14:11Jacob Wieland - SpirentNote Added: 0013291
24-09-2015 14:11Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Axel Rennoch
24-09-2015 14:11Jacob Wieland - SpirentStatusacknowledged => assigned
24-09-2015 16:04Jacob Wieland - SpirentFile Added: CR7147_resolution_v2.docx
24-09-2015 16:04Jacob Wieland - SpirentNote Added: 0013296
24-09-2015 16:04Jacob Wieland - SpirentAssigned ToAxel Rennoch => Gyorgy Rethy
24-09-2015 16:04Jacob Wieland - SpirentStatusassigned => confirmed
03-11-2015 11:15Gyorgy RethyFile Added: CR7147_resolution_v3.docx
03-11-2015 11:16Gyorgy RethyNote Added: 0013462
03-11-2015 11:16Gyorgy RethyStatusconfirmed => resolved
03-11-2015 11:16Gyorgy RethyFixed in Version => v4.8.1 (published 2016-07)
03-11-2015 11:16Gyorgy RethyResolutionopen => fixed
14-12-2015 11:41Gyorgy RethyNote Added: 0013613
14-12-2015 11:41Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0013225) +
+ Gyorgy Rethy    +
+ 21-09-2015 16:17    +
+ 		+ + + + +
+ STF discussion: check in detail.
+
+
+
+ + + + + + + + + + +
+ (0013288) +
+ Axel Rennoch    +
+ 24-09-2015 12:41    +
+ 		+ + + + +
+ Do you see further approaches to address forbidden operations?
+
+
+
+ + + + + + + + + + +
+ (0013291) +
+ Jacob Wieland - Spirent    +
+ 24-09-2015 14:11    +
+ 		+ + + + +
+ I would formulate that the restriction applied to the contents of functions called from special places shall also be applied both to the boolean guard and all other expressions occurring in the match part of an alternative.
+
+
+
+ + + + + + + + + + +
+ (0013296) +
+ Jacob Wieland - Spirent    +
+ 24-09-2015 16:04    +
+ 		+ + + + +
+ proposal ok for me, please review and resolve
+
+
+
+ + + + + + + + + + +
+ (0013462) +
+ Gyorgy Rethy    +
+ 03-11-2015 11:16    +
+ 		+ + + + +
+ CR7147_resolution_v3.docx: editorial changes to make text more readable and avoid too many use of apply-applied.
+
+
+
+ + + + + + + + + + +
+ (0013613) +
+ Gyorgy Rethy    +
+ 14-12-2015 11:41    +
+ 		+ + + + +
+ Added to draft V4.7.4
+
+ + diff --git a/docs/mantis/CR7148.md b/docs/mantis/CR7148.md new file mode 100644 index 0000000000000000000000000000000000000000..28c440d6bf8d479a96be8bd5bf1a11245523056a --- /dev/null +++ b/docs/mantis/CR7148.md @@ -0,0 +1,313 @@ + + + + + + + + + + + + + 0007148: Parameters of functions started as PTC behaviour - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007148Part 01: TTCN-3 Core LanguageTechnicalpublic19-08-2015 12:4811-12-2015 15:00
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.7.1 (published 2015-06) 
Target Versionv4.8.1 (published 2016-07)Fixed in Versionv4.8.1 (published 2016-07) 
Clause Reference(s)21.3.2
Source (company - Author)STF 487
Summary0007148: Parameters of functions started as PTC behaviour
DescriptionThe section 21.3.2 on starting test components doesn't say much about out and inout parameters. There's no restriction on them, so they seem to be allowed. The only text concerning these parameters can be found in the note 2: "Possible return values of a function invoked in a start test component operation, i.e. templates denoted by return keyword or inout and out parameters, have no effect when the started test component terminates."
+
+There are several problems connected with that. The first problem is obvious - this text should not be in the note as it has all attributes of a mandatory rule.
+
+The second problem is related to the principle of passing inout parameters by reference. This principle was introduced in recent specifications and I think the implications on the start call were not considered. Allowing to pass references this way would lead to shared variables and I think this is not a desired effect. Ports, defaults and timers are forbidden to be passed exactly for the same reason.
+
+In my opinion, it should be either completely disallowed to use inout parameters in fuctions invoked in the start call (which is unfortunately not a backwards compatible solution) or there should be a rule saying that the actual inout parameters are passed by value in this case.
+
+The third problem is connected with the out parameters. Since the actual parameter is not assigned when the test component terminates (as described in the note 2), there's a question why the actual parameter should be present at all. In my opinion, TTCN-3 should allow to skip actual out parameters (see the related CR) and this notation can be either recommended (in a note, backwards compatible) or mandatory (leads to better code, but not backwards compatible).
Steps To Reproduce
Additional Information
Tagstechnically agreed
Relationships
related to 0007149closed Gyorgy Rethy Allow to skip actual out parameters 
Attached Filesdocx CR7148_resolution_v1.docx (79,106) 25-09-2015 10:50
http://oldforge.etsi.org/mantis/file_download.php?file_id=3288&type=bug
docx CR7148_resolution_v2.docx (80,916) 25-09-2015 12:20
http://oldforge.etsi.org/mantis/file_download.php?file_id=3289&type=bug
docx CR7148_resolution_v3.docx (80,776) 25-09-2015 12:43
http://oldforge.etsi.org/mantis/file_download.php?file_id=3290&type=bug
Issue History
Date ModifiedUsernameFieldChange
19-08-2015 12:48Tomas UrbanNew Issue
19-08-2015 12:56Tomas UrbanNote Added: 0013172
21-08-2015 11:03Jacob Wieland - SpirentNote Added: 0013176
21-09-2015 10:27Gyorgy RethyTarget Version => v4.8.1 (published 2016-07)
21-09-2015 16:23Gyorgy RethyTag Attached: technically agreed
21-09-2015 16:26Gyorgy RethyNote Added: 0013226
21-09-2015 16:30Gyorgy RethyRelationship addedrelated to 0007149
21-09-2015 16:31Gyorgy RethyNote Edited: 0013226bug_revision_view_page.php?bugnote_id=13226#r169
24-09-2015 12:41Axel RennochAssigned To => Axel Rennoch
24-09-2015 12:41Axel RennochStatusnew => assigned
25-09-2015 10:50Axel RennochFile Added: CR7148_resolution_v1.docx
25-09-2015 10:52Axel RennochNote Added: 0013302
25-09-2015 10:53Axel RennochAssigned ToAxel Rennoch => Jacob Wieland - Spirent
25-09-2015 10:53Axel RennochStatusassigned => feedback
25-09-2015 11:07Jacob Wieland - SpirentNote Added: 0013303
25-09-2015 12:20Jacob Wieland - SpirentFile Added: CR7148_resolution_v2.docx
25-09-2015 12:21Jacob Wieland - SpirentNote Added: 0013307
25-09-2015 12:21Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Axel Rennoch
25-09-2015 12:21Jacob Wieland - SpirentStatusfeedback => confirmed
25-09-2015 12:43Axel RennochFile Added: CR7148_resolution_v3.docx
25-09-2015 12:46Axel RennochNote Added: 0013309
25-09-2015 12:46Axel RennochStatusconfirmed => resolved
25-09-2015 12:46Axel RennochResolutionopen => fixed
25-09-2015 12:46Axel RennochAssigned ToAxel Rennoch => Gyorgy Rethy
04-11-2015 14:03Gyorgy RethyFixed in Version => v4.8.1 (published 2016-07)
11-12-2015 15:00Gyorgy RethyNote Added: 0013596
11-12-2015 15:00Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0013172) +
+ Tomas Urban    +
+ 19-08-2015 12:56    +
+ 		+ + + + +
+ Unfortunately I don't have rights to add the related CR, so I link it this way: 0007149
+
+
+
+ + + + + + + + + + +
+ (0013176) +
+ Jacob Wieland - Spirent    +
+ 21-08-2015 11:03    +
+ 		+ + + + +
+ Basically, the semantics of out and inout parameters of started functions should be changed so that inout parameters are treated like in-parameters (i.e. the value of the given actual parameter is copied because in/inout parameters need to be partially initialized) and out actual parameters are basically treated like an anonymous variable (to which the result-value is assigned and subsequently forgotten).
+
+This would preserve the existing semantics of "no effect" in existing code.
+
+
+
+ + + + + + + + + + +
+ (0013226) +
+ Gyorgy Rethy    +
+ 21-09-2015 16:26    +
(edited on: 21-09-2015 16:31)
+ 		+ + + + +
+ STF discussion: note shall be mandatory text. More explicit statement is needed that when starting a function, inout parameters shall be handled like in parameters (i.e. passed by value). Out prrameters may optionally be skipped (see CR 7149)
+
+
+
+
+
+ + + + + + + + + + +
+ (0013302) +
+ Axel Rennoch    +
+ 25-09-2015 10:52    +
+ 		+ + + + +
+ Initial ideas in resolution v1 uploaded.
+
+
+
+ + + + + + + + + + +
+ (0013303) +
+ Jacob Wieland - Spirent    +
+ 25-09-2015 11:07    +
+ 		+ + + + +
+ The sentences should be put in the Semantic Description part as they are not really restrictions, but just describe what is allowed for out parameters and what happens for inout and out parameters.
+
+
+
+ + + + + + + + + + +
+ (0013307) +
+ Jacob Wieland - Spirent    +
+ 25-09-2015 12:21    +
+ 		+ + + + +
+ changed the text, moved to Semantic description parts and added further clarifications. please review
+
+
+
+ + + + + + + + + + +
+ (0013309) +
+ Axel Rennoch    +
+ 25-09-2015 12:46    +
+ 		+ + + + +
+ This final version just delete unnecessary characters and clean the formatting.
+
+
+
+ + + + + + + + + + +
+ (0013596) +
+ Gyorgy Rethy    +
+ 11-12-2015 15:00    +
+ 		+ + + + +
+ Added to draft V4.7.4
+
+ + diff --git a/docs/mantis/CR7149.md b/docs/mantis/CR7149.md new file mode 100644 index 0000000000000000000000000000000000000000..5f25f993d2f8fc0845de2c30a79693bc275a0663 --- /dev/null +++ b/docs/mantis/CR7149.md @@ -0,0 +1,498 @@ + + + + + + + + + + + + + 0007149: Allow to skip actual out parameters - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007149Part 01: TTCN-3 Core LanguageNew Featurepublic19-08-2015 12:5410-12-2015 16:14
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.7.1 (published 2015-06) 
Target Versionv4.8.1 (published 2016-07)Fixed in Versionv4.8.1 (published 2016-07) 
Clause Reference(s)5.4.2
Source (company - Author)STF 487
Summary0007149: Allow to skip actual out parameters
DescriptionIn cases when the user is not interested in getting an out parameter value, it should be allowed to skip the actual out parameter. This is similar to calling a function without saving the returned value. See the following example:
+
+function f_out(out integer p_out) return integer {
+  // compute p_out and the function result
+  return v_res;
+}
+
+control {
+  var integer v_num := f_out(-); // not interested in getting the out parameter
+}
+
+
Steps To Reproduce
Additional Information
Tagstechnically agreed
Relationships
related to 0007114closed Gyorgy Rethy Actual parameters of out formal value parameters not defined 
related to 0007148closed Gyorgy Rethy Parameters of functions started as PTC behaviour 
Attached Filesdocx CR7149_resolution_v1.docx (87,990) 25-09-2015 14:47
http://oldforge.etsi.org/mantis/file_download.php?file_id=3293&type=bug
docx CR7149_resolution_v2.docx (91,049) 12-10-2015 15:37
http://oldforge.etsi.org/mantis/file_download.php?file_id=3295&type=bug
docx CR7149_resolution_v3.docx (91,786) 13-10-2015 12:51
http://oldforge.etsi.org/mantis/file_download.php?file_id=3300&type=bug
docx CR7149_resolution_v3-problem.docx (69,169) 15-10-2015 13:59
http://oldforge.etsi.org/mantis/file_download.php?file_id=3320&type=bug
Issue History
Date ModifiedUsernameFieldChange
19-08-2015 12:54Tomas UrbanNew Issue
20-08-2015 13:17Jacob Wieland - SpirentNote Added: 0013173
20-08-2015 13:22Jacob Wieland - SpirentNote Added: 0013174
21-08-2015 09:47Tomas UrbanNote Added: 0013175
21-09-2015 10:27Gyorgy RethyTarget Version => v4.8.1 (published 2016-07)
21-09-2015 16:29Gyorgy RethyTag Attached: technically agreed
21-09-2015 16:30Gyorgy RethyNote Added: 0013227
21-09-2015 16:30Gyorgy RethyRelationship addedrelated to 0007148
24-09-2015 12:41Axel RennochAssigned To => Axel Rennoch
24-09-2015 12:41Axel RennochStatusnew => assigned
25-09-2015 14:44Axel RennochFile Added: CR7149_resolution_v1.docx
25-09-2015 14:44Axel RennochNote Added: 0013317
25-09-2015 14:45Axel RennochAssigned ToAxel Rennoch => Jacob Wieland - Spirent
25-09-2015 14:45Axel RennochStatusassigned => feedback
25-09-2015 14:46Axel RennochFile Deleted: CR7149_resolution_v1.docx
25-09-2015 14:47Axel RennochFile Added: CR7149_resolution_v1.docx
12-10-2015 11:58Gyorgy RethyNote Added: 0013353
12-10-2015 15:37Jacob Wieland - SpirentFile Added: CR7149_resolution_v2.docx
12-10-2015 15:40Jacob Wieland - SpirentNote Added: 0013358
12-10-2015 15:40Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
12-10-2015 15:40Jacob Wieland - SpirentStatusfeedback => confirmed
13-10-2015 12:23Gyorgy RethyFile Added: CR7149_resolution_v3.docx
13-10-2015 12:25Gyorgy RethyRelationship addedrelated to 0007114
13-10-2015 12:26Gyorgy RethyRelationship deletedrelated to 0007114
13-10-2015 12:39Gyorgy RethyRelationship addedrelated to 0007114
13-10-2015 12:51Gyorgy RethyNote Added: 0013368
13-10-2015 12:51Gyorgy RethyFile Deleted: CR7149_resolution_v3.docx
13-10-2015 12:51Gyorgy RethyFile Added: CR7149_resolution_v3.docx
13-10-2015 12:51Gyorgy RethyAssigned ToGyorgy Rethy => Jens Grabowski
13-10-2015 12:51Gyorgy RethyStatusconfirmed => assigned
13-10-2015 12:52Gyorgy RethyNote Added: 0013369
13-10-2015 12:52Gyorgy RethyStatusassigned => confirmed
15-10-2015 13:59Jens GrabowskiFile Added: CR7149_resolution_v3-problem.docx
15-10-2015 14:00Jens GrabowskiNote Added: 0013411
15-10-2015 14:01Jens GrabowskiAssigned ToJens Grabowski => Gyorgy Rethy
15-10-2015 14:01Jens GrabowskiStatusconfirmed => assigned
15-10-2015 14:30Jacob Wieland - SpirentNote Added: 0013415
15-10-2015 14:31Jacob Wieland - SpirentNote Added: 0013416
15-10-2015 14:31Jacob Wieland - SpirentStatusassigned => confirmed
02-11-2015 14:40Gyorgy RethyStatusconfirmed => resolved
02-11-2015 14:40Gyorgy RethyFixed in Version => v4.8.1 (published 2016-07)
02-11-2015 14:40Gyorgy RethyResolutionopen => fixed
10-12-2015 16:14Gyorgy RethyNote Added: 0013580
10-12-2015 16:14Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0013173) +
+ Jacob Wieland - Spirent    +
+ 20-08-2015 13:17    +
+ 		+ + + + +
+ I wholeheartedly agree, I have been toying with the same idea for some time.
+
+
+
+ + + + + + + + + + +
+ (0013174) +
+ Jacob Wieland - Spirent    +
+ 20-08-2015 13:22    +
+ 		+ + + + +
+ in a similar vein, it should be possible to pass a non-variable (i.e. constant expression) to an inout parameter.
+
+Here, the following equivalence would be established:
+
+f(E) is equivalent to f(v) where var T v := E;
+
+Basically, an anonymous variable would be filled with the evaluation of expression E and passed to the inout parameter. The result value will be discarded when the function is finished.
+
+
+
+ + + + + + + + + + +
+ (0013175) +
+ Tomas Urban    +
+ 21-08-2015 09:47    +
+ 		+ + + + +
+ I like the idea of the anonymous variable. It would be useful not only for passing expressions to inout formal parameters, but also as a solution for passing variables to functions started on other components (see 0007148 for more details).
+
+
+
+ + + + + + + + + + +
+ (0013227) +
+ Gyorgy Rethy    +
+ 21-09-2015 16:30    +
+ 		+ + + + +
+ STF discussion: feature makes sense. Detailed resolution text to be developed.
+
+
+
+ + + + + + + + + + +
+ (0013317) +
+ Axel Rennoch    +
+ 25-09-2015 14:44    +
+ 		+ + + + +
+ Please check the initial resolution v1.
+
+
+
+ + + + + + + + + + +
+ (0013353) +
+ Gyorgy Rethy    +
+ 12-10-2015 11:58    +
+ 		+ + + + +
+ My understanding is that the agreement was for the out parameters only. The "-" makes it explicit that the user doesn't want to store the actual out parameter value. This is easy and clear from the user's point of view.
+
+I'm far not so sure about the inout parameter case. Testers - though should be - are not programmers. This change would make a complicated language even more complicated for them. In fact, the workaround for the inout parameters is just one additional line:
+
+var Mytype v_tmp := <expression>
+f(v_tmp);
+
+inout parameterization is by reference (by definition); now are we going to break this (?) and say: it is by reference if, but by value if...
+expressions may contain variables, if expression is allowed, further questions may/will come up, like does the variables in the expression be changed when the parameter is manipulated within the function? etc. I'm sure other questions to be clarified will come up as well. I know that all these questions can be answered, but all this would make the whole thing so complicated that I believe, it doesn't worth it; just to eliminate one line of code that btw. makes the behaviour clear and visible.
+
+
+
+ + + + + + + + + + +
+ (0013358) +
+ Jacob Wieland - Spirent    +
+ 12-10-2015 15:40    +
+ 		+ + + + +
+ changed according to last comment, please review new file.
+
+Made dash-usage consistent, i.e. if a trailing parameter-list contains only dashes (regardless whether for in parameters with defaults or for out parameters), these can be left out.
+
+
+
+ + + + + + + + + + +
+ (0013368) +
+ Gyorgy Rethy    +
+ 13-10-2015 12:51    +
+ 		+ + + + +
+ CR7149_resolution_v3.docx: additional sentence on skipping out parameters is also added to the new paragraph on value out parameters coming from CR7114 (paragraph itself may change in CR7114, the purpose here is just to have the additional sentence in this CR).
+
+
+
+ + + + + + + + + + +
+ (0013369) +
+ Gyorgy Rethy    +
+ 13-10-2015 12:52    +
+ 		+ + + + +
+ Jens, please also review it.
+
+
+
+ + + + + + + + + + +
+ (0013411) +
+ Jens Grabowski    +
+ 15-10-2015 14:00    +
+ 		+ + + + +
+ Apart from the duplication of one paragraph, see file: CR7149_resolution_v3-problem.docx, the resolution is ok.
+
+
+
+ + + + + + + + + + +
+ (0013415) +
+ Jacob Wieland - Spirent    +
+ 15-10-2015 14:30    +
+ 		+ + + + +
+ The duplicated sentence is correct as it appears in two different contexts. The first paragraph has the context of formal value out parameters and the other paragraph has the context of formal template out parameters.
+
+
+
+ + + + + + + + + + +
+ (0013416) +
+ Jacob Wieland - Spirent    +
+ 15-10-2015 14:31    +
+ 		+ + + + +
+ reviewed again, to me it is resolved, please resolve if you agree
+
+
+
+ + + + + + + + + + +
+ (0013580) +
+ Gyorgy Rethy    +
+ 10-12-2015 16:14    +
+ 		+ + + + +
+ Added to draft V4.7.4
+
+ + diff --git a/docs/mantis/CR7155.md b/docs/mantis/CR7155.md new file mode 100644 index 0000000000000000000000000000000000000000..695a33e1de313af4b8df440fdb20cdcaf8cff427 --- /dev/null +++ b/docs/mantis/CR7155.md @@ -0,0 +1,289 @@ + + + + + + + + + + + + + 0007155: Running and alive operation should not be forbidden for MTC - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007155Part 01: TTCN-3 Core LanguageTechnicalpublic21-08-2015 09:4314-12-2015 13:15
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritylowSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.7.1 (published 2015-06) 
Target Versionv4.8.1 (published 2016-07)Fixed in Versionv4.8.1 (published 2016-07) 
Clause Reference(s)21.3.5 and 21.3.6
Source (company - Author)STF 487
Summary0007155: Running and alive operation should not be forbidden for MTC
DescriptionThe current rules doesn't allow to use the running and alive operation for the MTC. Similar restrictions are valid for the done and killed operation, where it makes sense as these event never occur during execution of a test case and for the start operation which behaves as any other attempt to start a behaviour on a running component producing an error.
+
+However, in case of the running operation, I simply don't understand the reasons why the TE should throw an error instead of simply returning true. The alive operation is more complicated. I would expect it to return false for the usual non-static MTC defined in the core language standard and true for a static MTC from the configuration and deployment extension package.
+
+Proposal: allow using the alive and running operations for the MTC with the above described logic.
+
+Proposal:
+
+
Steps To Reproduce
Additional Information
Tagstechnically agreed
Relationships
Attached Filesdocx CR7155_resolution_v1.docx (81,244) 12-10-2015 15:01
http://oldforge.etsi.org/mantis/file_download.php?file_id=3294&type=bug
docx CR7155_resolution_v2.docx (81,656) 12-10-2015 15:51
http://oldforge.etsi.org/mantis/file_download.php?file_id=3296&type=bug
Issue History
Date ModifiedUsernameFieldChange
21-08-2015 09:43Tomas UrbanNew Issue
21-09-2015 10:27Gyorgy RethyTarget Version => v4.8.1 (published 2016-07)
21-09-2015 16:36Gyorgy RethyTag Attached: technically agreed
21-09-2015 16:41Gyorgy RethyNote Added: 0013228
12-10-2015 10:13Axel RennochAssigned To => Axel Rennoch
12-10-2015 10:13Axel RennochStatusnew => assigned
12-10-2015 15:01Axel RennochFile Added: CR7155_resolution_v1.docx
12-10-2015 15:08Axel RennochNote Added: 0013356
12-10-2015 15:09Axel RennochNote Added: 0013357
12-10-2015 15:09Axel RennochAssigned ToAxel Rennoch => Jacob Wieland - Spirent
12-10-2015 15:09Axel RennochStatusassigned => acknowledged
12-10-2015 15:51Jacob Wieland - SpirentFile Added: CR7155_resolution_v2.docx
12-10-2015 15:51Jacob Wieland - SpirentNote Added: 0013359
12-10-2015 15:51Jacob Wieland - SpirentStatusacknowledged => confirmed
12-10-2015 15:52Jacob Wieland - SpirentStatusconfirmed => assigned
12-10-2015 15:52Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
12-10-2015 15:52Jacob Wieland - SpirentStatusassigned => confirmed
13-10-2015 09:46Gyorgy RethyNote Added: 0013362
13-10-2015 09:47Gyorgy RethyAssigned ToGyorgy Rethy => Axel Rennoch
13-10-2015 09:47Gyorgy RethyPrioritynormal => low
13-10-2015 15:31Axel RennochNote Added: 0013372
13-10-2015 15:31Axel RennochAssigned ToAxel Rennoch => Gyorgy Rethy
13-10-2015 15:31Axel RennochStatusconfirmed => assigned
13-10-2015 15:32Axel RennochStatusassigned => confirmed
03-11-2015 09:36Gyorgy RethyStatusconfirmed => resolved
03-11-2015 09:36Gyorgy RethyFixed in Version => v4.8.1 (published 2016-07)
03-11-2015 09:36Gyorgy RethyResolutionopen => fixed
14-12-2015 13:15Gyorgy RethyNote Added: 0013617
14-12-2015 13:15Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0013228) +
+ Gyorgy Rethy    +
+ 21-09-2015 16:41    +
+ 		+ + + + +
+ STF discussion: has effect both to the core language and the configuration and deployment package. Part-1 portion (e.g. mtc.running) has higher priority, configuration part to be handled with low priority. Let chaeck in detail where these documants would need to be changed.
+
+
+
+ + + + + + + + + + +
+ (0013356) +
+ Axel Rennoch    +
+ 12-10-2015 15:08    +
+ 		+ + + + +
+ Part-1 changes are provided in uploaded file resolution_v1.
+Currently no proposals for the config and deployment package since operations .alive and .running are not mentioned in ES 202 781.
+
+
+
+ + + + + + + + + + +
+ (0013357) +
+ Axel Rennoch    +
+ 12-10-2015 15:09    +
+ 		+ + + + +
+ Please check the proposed resolution v1.
+
+
+
+ + + + + + + + + + +
+ (0013359) +
+ Jacob Wieland - Spirent    +
+ 12-10-2015 15:51    +
+ 		+ + + + +
+ slightly changed the wording of the first proposal to be more consistent with preceding text. Otherwise, ok.
+
+
+
+ + + + + + + + + + +
+ (0013362) +
+ Gyorgy Rethy    +
+ 13-10-2015 09:46    +
+ 		+ + + + +
+ Syntactic structure and BNF needs to update as well. alive and running ops doesn't allow MTCKeyword and SelfOp; ie. v_MyPTC.alive is allowed, self.alive or mtc.alive are not allowed.
+
+Also, config&deployment package should be updated.
+
+I propose to handle the CR with low priority.
+
+
+
+ + + + + + + + + + +
+ (0013372) +
+ Axel Rennoch    +
+ 13-10-2015 15:31    +
+ 		+ + + + +
+ The CR provides a clarification for situations like
+var PTC v_my := mtc;
+v_my.running;
+
+I propose to avoid explicit statements like
+mtc.alive; self.running; //etc.
+
+and not to change the BNF.
+
+Furthermore the config&deployment package may not be modified due to this CR since .alive and .running ops are not treated.
+
+
+
+ + + + + + + + + + +
+ (0013617) +
+ Gyorgy Rethy    +
+ 14-12-2015 13:15    +
+ 		+ + + + +
+ Added to V4.7.4
+
+ + diff --git a/docs/mantis/CR7156.md b/docs/mantis/CR7156.md new file mode 100644 index 0000000000000000000000000000000000000000..956019d31415212f03eeeb456baaeb5cb0481ab5 --- /dev/null +++ b/docs/mantis/CR7156.md @@ -0,0 +1,235 @@ + + + + + + + + + + + + + 0007156: Missing restriction on exception values - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007156Part 01: TTCN-3 Core LanguageTechnicalpublic26-08-2015 09:4811-12-2015 14:54
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.7.1 (published 2015-06) 
Target Versionv4.8.1 (published 2016-07)Fixed in Versionv4.8.1 (published 2016-07) 
Clause Reference(s)22.3.5
Source (company - Author)STF 487
Summary0007156: Missing restriction on exception values
DescriptionCurrent rules for the raise operation specified in the section 22.3.5 do not explicitly say that raised exceptions cannot contain matching mechanisms. For that reason I propose to add the following restriction:
+
+The TemplateInstance (and all parts of it) shall have a specific value i.e. the use of matching mechanisms such as AnyValue is not allowed.
Steps To Reproduce
Additional Information
Tagstechnically agreed
Relationships
Attached Filesdocx CR7156.docx (170,188) 24-09-2015 14:34
http://oldforge.etsi.org/mantis/file_download.php?file_id=3281&type=bug
Issue History
Date ModifiedUsernameFieldChange
26-08-2015 09:48Tomas UrbanNew Issue
21-09-2015 10:27Gyorgy RethyTarget Version => v4.8.1 (published 2016-07)
22-09-2015 08:58Gyorgy RethyNote Added: 0013230
22-09-2015 08:58Gyorgy RethyTag Attached: technically agreed
24-09-2015 14:12Jacob Wieland - SpirentAssigned To => Jacob Wieland - Spirent
24-09-2015 14:12Jacob Wieland - SpirentStatusnew => assigned
24-09-2015 14:34Jacob Wieland - SpirentFile Added: CR7156.docx
24-09-2015 14:35Jacob Wieland - SpirentNote Added: 0013294
24-09-2015 14:35Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
24-09-2015 14:35Jacob Wieland - SpirentStatusassigned => confirmed
25-09-2015 11:04Gyorgy RethyAssigned ToGyorgy Rethy => Axel Rennoch
25-09-2015 13:27Axel RennochNote Added: 0013311
25-09-2015 13:32Axel RennochNote Added: 0013312
25-09-2015 13:32Axel RennochAssigned ToAxel Rennoch => Gyorgy Rethy
25-09-2015 13:32Axel RennochStatusconfirmed => assigned
15-10-2015 12:41Jacob Wieland - SpirentNote Added: 0013399
15-10-2015 12:41Jacob Wieland - SpirentStatusassigned => resolved
15-10-2015 12:41Jacob Wieland - SpirentResolutionopen => fixed
04-11-2015 14:03Gyorgy RethyFixed in Version => v4.8.1 (published 2016-07)
11-12-2015 14:54Gyorgy RethyNote Added: 0013595
11-12-2015 14:54Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0013230) +
+ Gyorgy Rethy    +
+ 22-09-2015 08:58    +
+ 		+ + + + +
+ STF discussion: add the restriction
+
+
+
+ + + + + + + + + + +
+ (0013294) +
+ Jacob Wieland - Spirent    +
+ 24-09-2015 14:35    +
+ 		+ + + + +
+ added proposal adding the missing restriction. please review and resolve
+
+
+
+ + + + + + + + + + +
+ (0013311) +
+ Axel Rennoch    +
+ 25-09-2015 13:27    +
+ 		+ + + + +
+ The resolution looks good.
+
+
+
+ + + + + + + + + + +
+ (0013312) +
+ Axel Rennoch    +
+ 25-09-2015 13:32    +
+ 		+ + + + +
+ CR should be set to resolved.
+
+
+
+ + + + + + + + + + +
+ (0013399) +
+ Jacob Wieland - Spirent    +
+ 15-10-2015 12:41    +
+ 		+ + + + +
+ ok, then
+
+
+
+ + + + + + + + + + +
+ (0013595) +
+ Gyorgy Rethy    +
+ 11-12-2015 14:54    +
+ 		+ + + + +
+ Added to draft v4.7.4
+
+ + diff --git a/docs/mantis/CR7164.md b/docs/mantis/CR7164.md new file mode 100644 index 0000000000000000000000000000000000000000..e17454d989f02a2019c630df46c3fc7087678b0a --- /dev/null +++ b/docs/mantis/CR7164.md @@ -0,0 +1,205 @@ + + + + + + + + + + + + + 0007164: Content of the from clause not properly explained - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007164Part 01: TTCN-3 Core LanguageTechnicalpublic04-09-2015 14:3214-12-2015 15:08
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritylowSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.7.1 (published 2015-06) 
Target Versionv4.8.1 (published 2016-07)Fixed in Versionv4.8.1 (published 2016-07) 
Clause Reference(s)22.2.2
Source (company - Author)STF 487
Summary0007164: Content of the from clause not properly explained
DescriptionThe description of the from clause in the section 22.2.2 (receive operation) is as follows: "In the case of one-to-many connections the receive operation may be restricted to a certain communication partner. This restriction shall be denoted using the from keyword."
+
+There are several problems with these rules:
+1. There's a question what should happen in case of one-to-one connection. Is it an error to use the from clause?
+2. The from clause can contain a list of components or adresses and the any component notation. These are not properly explained, there's only a note about this posibility in the syntactical description.
+
+The problems concerns other "receiving" operations: trigger, check, getcall, getreply, catch.
Steps To Reproduce
Additional Information
Tagstechnically agreed
Relationships
Attached Filesdocx CR7164_resolution_v1.docx (126,030) 15-10-2015 12:41
http://oldforge.etsi.org/mantis/file_download.php?file_id=3314&type=bug
docx CR7164_resolution_v2.docx (135,253) 15-10-2015 13:33
http://oldforge.etsi.org/mantis/file_download.php?file_id=3318&type=bug
Issue History
Date ModifiedUsernameFieldChange
04-09-2015 14:32Tomas UrbanNew Issue
21-09-2015 10:27Gyorgy RethyTarget Version => v4.8.1 (published 2016-07)
22-09-2015 09:02Gyorgy RethyTag Attached: technically agreed
22-09-2015 09:04Gyorgy RethyNote Added: 0013231
22-09-2015 09:04Gyorgy RethyPrioritynormal => low
12-10-2015 11:45Axel RennochAssigned To => Axel Rennoch
12-10-2015 11:45Axel RennochStatusnew => assigned
15-10-2015 12:41Axel RennochFile Added: CR7164_resolution_v1.docx
15-10-2015 12:43Axel RennochNote Added: 0013400
15-10-2015 12:44Axel RennochNote Added: 0013401
15-10-2015 12:44Axel RennochAssigned ToAxel Rennoch => Jacob Wieland - Spirent
15-10-2015 12:44Axel RennochStatusassigned => acknowledged
15-10-2015 13:33Jacob Wieland - SpirentFile Added: CR7164_resolution_v2.docx
15-10-2015 13:34Jacob Wieland - SpirentNote Added: 0013408
15-10-2015 13:34Jacob Wieland - SpirentStatusacknowledged => confirmed
15-10-2015 14:03Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent =>
15-10-2015 14:03Jacob Wieland - SpirentAssigned To => Jacob Wieland - Spirent
15-10-2015 14:03Jacob Wieland - SpirentStatusconfirmed => assigned
15-10-2015 14:04Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
15-10-2015 14:04Jacob Wieland - SpirentStatusassigned => confirmed
02-11-2015 14:49Gyorgy RethyStatusconfirmed => resolved
02-11-2015 14:49Gyorgy RethyFixed in Version => v4.8.1 (published 2016-07)
02-11-2015 14:49Gyorgy RethyResolutionopen => fixed
14-12-2015 15:08Gyorgy RethyNote Added: 0013625
14-12-2015 15:08Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0013231) +
+ Gyorgy Rethy    +
+ 22-09-2015 09:04    +
+ 		+ + + + +
+ STF discussion: comment is correct, using from on P2P connections shall not be an error, even if the component id is different from the ID of the peer. Text has to be amended. Handle this CR with low priority.
+
+
+
+ + + + + + + + + + +
+ (0013400) +
+ Axel Rennoch    +
+ 15-10-2015 12:43    +
+ 		+ + + + +
+ New text has been added to the related "receiving" operations in resolution_v1.
+
+
+
+ + + + + + + + + + +
+ (0013401) +
+ Axel Rennoch    +
+ 15-10-2015 12:44    +
+ 		+ + + + +
+ Please check modification in the uploaded file v1.
+
+
+
+ + + + + + + + + + +
+ (0013408) +
+ Jacob Wieland - Spirent    +
+ 15-10-2015 13:34    +
+ 		+ + + + +
+ added also "component references" as they are also allowed in case of intercomponent communication
+
+
+
+ + + + + + + + + + +
+ (0013625) +
+ Gyorgy Rethy    +
+ 14-12-2015 15:08    +
+ 		+ + + + +
+ Added to draft V4.7.4
+
+ + diff --git a/docs/mantis/CR7167.md b/docs/mantis/CR7167.md new file mode 100644 index 0000000000000000000000000000000000000000..aea56aa0fe1d62eed9eb0a4b990607fe139519ce --- /dev/null +++ b/docs/mantis/CR7167.md @@ -0,0 +1,417 @@ + + + + + + + + + + + + + 0007167: Matching mechanism to match multiple items in arrays, records and sets of single types - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Advanced Matching (ES 203 022)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007167Ext Pack: Advanced Matching (ES 203 022)New Featurepublic07-09-2015 10:5324-12-2016 12:59
ReporterTomas Urban 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv1.1.1 (published 2017-07)Fixed in Versionv1.1.1 (published 2017-07) 
Clause Reference(s)B.1.3
Source (company - Author)Elvior
TS version
Summary0007167: Matching mechanism to match multiple items in arrays, records and sets of single types
DescriptionI one of our projects we had an interesting problems with matching incoming messages. The message contained a record of complex record entries and one of the string fields of each record element was required to contain a certain pattern.
+
+We ended up with using a rather complicated solution containing a check procedure (for general acceptance), for-loop for element check and continue statement + some guards for flow control.
+
+However, it would be nice if TTCN-3 contained a matching mechanism that would allow to specify properties of SEVERAL record of, set of or array items. Such a mechanism would be generally similar to AnyElementsOrNone with that difference that it would impose additional restrictions on the element content. Similarly to the AnyElementsOrNone, it could be optionaly ammended with a length restriction.
+
+Possible syntactical solutions:
+The following type is used in examples:
+type record of record {
+   integer field1,
+   charstring field2
+} RoR;
+
+
+1. Extension of the AnyElementsOrNone mechanism:
+   a. using the with keyword:
+      {
+         // standard field match (fixed values)
+         { field1 := 3, field2 := pattern "test" },
+         // 0..N matches where field2 of each element has to start with "abc"
+         * with { field1 := ?, field2 := pattern "abc*" }
+      }
+   b. using the pattern keyword:
+      {
+         // standard field match (fixed values)
+         { field1 := 3, field2 := pattern "test" },
+         // 0..N matches where field2 of each element has to start with "abc"
+         * pattern { field1 := ?, field2 := pattern "abc*" }
+      }
+2. Using the any keyword:
+      {
+         // standard field match (fixed values)
+         { field1 := 3, field2 := pattern "test" },
+         // 0..N matches where field2 of each element has to start with "abc"
+         any { field1 := ?, field2 := pattern "abc*" }
+      }
+
Steps To Reproduce
Additional Information
Tagstechnically agreed
Relationships
related to 0007174closed Jens Grabowski New matching mechanism: matching by function 
related to 0007494closed Jens Grabowski TRI and TCI extensions for advanced matching 
Attached Filesdocx CR7167-1.docx (170,009) 15-11-2016 14:49
http://oldforge.etsi.org/mantis/file_download.php?file_id=3523&type=bug
docx CR7167-2.docx (156,818) 17-11-2016 09:54
http://oldforge.etsi.org/mantis/file_download.php?file_id=3548&type=bug
Issue History
Date ModifiedUsernameFieldChange
07-09-2015 10:53Tomas UrbanNew Issue
07-09-2015 16:23Jacob Wieland - SpirentNote Added: 0013193
21-09-2015 10:27Gyorgy RethyTarget Version => v4.8.1 (ongoing)
21-09-2015 11:11Gyorgy RethyRelationship addedrelated to 0007174
21-09-2015 11:49Gyorgy RethyNote Added: 0013200
21-09-2015 11:50Gyorgy RethyNote Edited: 0013200bug_revision_view_page.php?bugnote_id=13200#r167
22-09-2015 09:35Gyorgy RethyTag Attached: technically agreed
22-09-2015 09:38Gyorgy RethyNote Added: 0013232
22-09-2015 09:38Gyorgy RethyAssigned To => Jacob Wieland - Spirent
22-09-2015 09:38Gyorgy RethyStatusnew => assigned
23-09-2015 15:15Jacob Wieland - SpirentNote Added: 0013275
23-09-2015 15:27Jacob Wieland - SpirentNote Added: 0013276
23-09-2015 15:27Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
23-09-2015 15:27Jacob Wieland - SpirentStatusassigned => confirmed
03-11-2015 11:58Gyorgy RethyNote Added: 0013466
03-11-2015 11:58Gyorgy RethyTarget Versionv4.8.1 (ongoing) => Next version (to be defined)
05-11-2015 11:05Gyorgy RethyProjectPart 01: TTCN-3 Core Language => Ext Pack: Advanced Matching (ES 203 022)
05-11-2015 11:05Gyorgy RethyProduct Versionv4.7.1 (published 2015-06) =>
05-11-2015 11:05Gyorgy RethyTarget VersionNext version (to be defined) => v1.1.1 (published 2017-07)
15-12-2015 10:40Gyorgy RethyStatusconfirmed => assigned
18-07-2016 14:52Jens GrabowskiAssigned ToGyorgy Rethy => Kristóf Szabados
20-07-2016 14:32Jens GrabowskiAssigned ToKristóf Szabados => Jens Grabowski
15-08-2016 13:17Jens GrabowskiAssigned ToJens Grabowski => Tomas Urban
15-11-2016 14:49Tomas UrbanFile Added: CR7167-1.docx
15-11-2016 14:50Tomas UrbanNote Added: 0014251
15-11-2016 14:50Tomas UrbanAssigned ToTomas Urban => Jacob Wieland - Spirent
15-11-2016 14:50Tomas UrbanStatusassigned => confirmed
16-11-2016 14:39Tomas UrbanRelationship addedrelated to 0007494
17-11-2016 09:54Jacob Wieland - SpirentFile Added: CR7167-2.docx
17-11-2016 09:55Jacob Wieland - SpirentStatusconfirmed => assigned
17-11-2016 09:55Jacob Wieland - SpirentNote Added: 0014290
17-11-2016 09:55Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Jens Grabowski
17-11-2016 09:55Jacob Wieland - SpirentStatusassigned => confirmed
17-11-2016 12:36Jens GrabowskiStatusconfirmed => resolved
17-11-2016 12:36Jens GrabowskiResolutionopen => fixed
24-12-2016 12:59Jens GrabowskiStatusresolved => closed
24-12-2016 12:59Jens GrabowskiFixed in Version => v1.1.1 (published 2017-07)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0013193) +
+ Jacob Wieland - Spirent    +
+ 07-09-2015 16:23    +
+ 		+ + + + +
+ Obviously, every idea has its time. I have been pondering the same problem for a while and wanted to propose some sort of repeat-statement (where * is just a very special repeat of ? with no length restriction.
+
+Ideas of mine were:
+
+A * [length(L..U)] (where A is a matching mechanism) - similar to BNF
+
+or
+
+A repeat [length(L .. U)]
+
+or
+
+repeat (A1, ..., An) [length(L .. U)]
+
+
+The existing AnyElementsOrNone (*) would then just be a shorthand of ? * (or the other ways).
+
+We could also borrow the #-repetition from the pattern-language (to have in-language-familiarity for similar constructs), i.e.
+
+A # ([lower], [upper]) with A #(,) being the same as A*.
+
+
+
+ + + + + + + + + + +
+ (0013200) +
+ Gyorgy Rethy    +
+ 21-09-2015 11:49    +
(edited on: 21-09-2015 11:50)
+ 		+ + + + +
+ alternatively repetition of a template element could be allowed, like:
+
+{{field1 := 3, field2 := pattern "test" }} this will match a record/set of with one element only
+
+{{ field1 := 3, field2 := pattern "test"} length(0..infinity)} this will match a record/set of with any number of elements, each obeying the inline template.
+
+Please note, the syntax is already allowed, in this case we need to amend only the text in clause B.1.4.1, especially Restriction a).
+
+
+
+
+
+ + + + + + + + + + +
+ (0013232) +
+ Gyorgy Rethy    +
+ 22-09-2015 09:38    +
+ 		+ + + + +
+ STF discussion: to specify repetitions of record/set of elements we shall reuse the #(n,m) [#(), #(n,)...) syntax from patterns. This will be language consistent and also allows defining different "subsets" of element repetitoons within a list. Exanmples of the syntax to be prepared for te different cases, e.g. record of record of record, combinations with length() etc.
+
+
+
+ + + + + + + + + + +
+ (0013275) +
+ Jacob Wieland - Spirent    +
+ 23-09-2015 15:15    +
+ 		+ + + + +
+ Syntactical Structure shall be:
+
+ArrayElementSpec ::= Minus |
+                          PermutationMatch |
+                          TemplateBody [Repetition]
+
+Repetition ::= "#" "(" [SingleExpression] ["," [SingleExpression]] ")"
+
+If Repetition is present, the TemplateBody must be of the same root record of type as the surrounding template (i.e. if it is of root type record of T, the repeated template must also be of root type record of T).
+
+This allows (for the Repetition part):
+#() - 0 .. infinity,
+#(x) - x .. x,
+#(x,) - x .. infinity,
+#(x,y) - x .. y,
+#(,y) - 0 .. y,
+#(,) - 0 .. infinity (if we want to exclude this possibility, the rule becomes more complicated)
+
+The special BNF constructs {}, [] and {}+ can be modeled with #(), #(,1) and #(1,) respectively.
+
+EXAMPLE:
+
+type record of T S;
+template T a, b, c;
+template S s1 := { a, b, c }
+template S s2 := { permutation(a, *, c) length(5) }
+var integer x, y;
+
+template S t1 := { {a, b, c} #(x,y) }
+// matches any record of repeating elements matching a, b, c consecutively
+// for at least x, at most y times.
+
+template S t2 := { s1 #(x,y) } // same as t1
+
+template S t3 := { { (a, b, c) } # (x) }
+// matches any repetition of length x where each element conforms to
+// (a, b, c) (i.e. a or b or c).
+
+template S t4 := { (s1, s2) #(x,y) }
+// matches a sequence that can be partitioned into x up to y
+// sub-sequences where each sub-sequence matches s1 or s2.
+
+template S t5 := { p, {s1 #(0,1), s2 #(1,)} #(x), q }
+// matches a record of where first element matches p,
+// then is followed by a repetition of length x of a
+// repetition of an optional s1-sub-sequence followed by
+// a non-empty repetition of s2-sub-sequences and finally followed by
+// an element matching q.
+
+template S t6 := { s1 & s2 #(5) }
+// matches a record of which can be partititioned into 5 sub-sequences
+// where each-sub-sequence matches the concatenation-template s1 & s2.
+
+As we can see, it is very easy to compose such templates from other templates and to combine it with existing matching mechanisms.
+
+
+
+ + + + + + + + + + +
+ (0013276) +
+ Jacob Wieland - Spirent    +
+ 23-09-2015 15:27    +
+ 		+ + + + +
+ please review examples in my last note
+
+
+
+ + + + + + + + + + +
+ (0013466) +
+ Gyorgy Rethy    +
+ 03-11-2015 11:58    +
+ 		+ + + + +
+ To be part of the new extension on advanced matching mechanisms.
+
+
+
+ + + + + + + + + + +
+ (0014251) +
+ Tomas Urban    +
+ 15-11-2016 14:50    +
+ 		+ + + + +
+ Proposal uploaded. Please check.
+
+
+
+ + + + + + + + + + +
+ (0014290) +
+ Jacob Wieland - Spirent    +
+ 17-11-2016 09:55    +
+ 		+ + + + +
+ Please review.
+
+ + diff --git a/docs/mantis/CR7168.md b/docs/mantis/CR7168.md new file mode 100644 index 0000000000000000000000000000000000000000..790d0b0c967ca2720ecfac379468d32d4db672d3 --- /dev/null +++ b/docs/mantis/CR7168.md @@ -0,0 +1,171 @@ + + + + + + + + + + + + + 0007168: Invalid description of redirect assignment of message fields in receive operation - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007168Part 01: TTCN-3 Core LanguageEditorialpublic07-09-2015 13:2609-12-2015 16:39
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionduplicate 
PlatformOSOS Version
Product Versionv4.7.1 (published 2015-06) 
Target Versionv4.8.1 (published 2016-07)Fixed in Versionv4.8.1 (published 2016-07) 
Clause Reference(s)22.2.2
Source (company - Author)STF 487
Summary0007168: Invalid description of redirect assignment of message fields in receive operation
DescriptionThe section 22.2.2 states that: "In a single assignment within the list, on the left hand side of the assignment symbol (":=") a field of the template type shall be referenced, on the right hand side the name of the variable or a formal parameter, in which the value shall be stored."
+
+However, this is clearly wrong. The (source) template field shall be on the right and the (target) variable on the left hand side of the assignment symbol. Both syntactical description and examples use that order. Besides, it is the common way how to write assignments. It would be very weird if redirect assignments behaved differently.
+
+Proposal: Change the rule to:
+In a single assignment within the list, on the right hand side of the assignment symbol (":=") a field of the template type shall be referenced, on the left hand side the name of the variable or a formal parameter, in which the value shall be stored.
Steps To Reproduce
Additional Information
Tagstechnically agreed
Relationships
duplicate of 0007090closed Gyorgy Rethy description and example for field value redirect are wrong 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
07-09-2015 13:26Tomas UrbanNew Issue
07-09-2015 13:35Tomas UrbanNote Added: 0013192
07-09-2015 18:06Jacob Wieland - SpirentNote Added: 0013194
07-09-2015 18:06Jacob Wieland - SpirentRelationship addedduplicate of 0007090
21-09-2015 10:24Gyorgy RethyTarget Version => v4.8.1 (published 2016-07)
22-09-2015 09:40Gyorgy RethyTag Attached: technically agreed
22-09-2015 09:41Gyorgy RethyNote Added: 0013233
22-09-2015 09:41Gyorgy RethyAssigned To => Gyorgy Rethy
22-09-2015 09:41Gyorgy RethyStatusnew => assigned
15-10-2015 13:15Jacob Wieland - SpirentStatusassigned => resolved
15-10-2015 13:15Jacob Wieland - SpirentResolutionopen => duplicate
04-11-2015 14:03Gyorgy RethyFixed in Version => v4.8.1 (published 2016-07)
09-12-2015 16:39Gyorgy RethyNote Added: 0013576
09-12-2015 16:39Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0013192) +
+ Tomas Urban    +
+ 07-09-2015 13:35    +
+ 		+ + + + +
+ The following rule shall be also changed to:
+"The variable or formal parameter shall be type compatible with the type of the field on the right hand side of the assignment symbol."
+
+
+
+ + + + + + + + + + +
+ (0013194) +
+ Jacob Wieland - Spirent    +
+ 07-09-2015 18:06    +
+ 		+ + + + +
+ already solved in CR 7090
+
+
+
+ + + + + + + + + + +
+ (0013233) +
+ Gyorgy Rethy    +
+ 22-09-2015 09:41    +
+ 		+ + + + +
+ STF discussion: comment is correct, may be solved by CR 7090 already. Check it and correct if still needed.
+
+
+
+ + + + + + + + + + +
+ (0013576) +
+ Gyorgy Rethy    +
+ 09-12-2015 16:39    +
+ 		+ + + + +
+ Added to draft V4.7.4
+
+ + diff --git a/docs/mantis/CR7171.md b/docs/mantis/CR7171.md new file mode 100644 index 0000000000000000000000000000000000000000..62d2297dd8c157c90807d46e6466974f3e9d978d --- /dev/null +++ b/docs/mantis/CR7171.md @@ -0,0 +1,173 @@ + + + + + + + + + + + + + 0007171: Make a template list restriction explicit - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007171Part 01: TTCN-3 Core LanguageClarificationpublic09-09-2015 16:4904-12-2015 16:33
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.7.1 (published 2015-06) 
Target Versionv4.8.1 (published 2016-07)Fixed in Versionv4.8.1 (published 2016-07) 
Clause Reference(s)B.1.2.1
Source (company - Author)L.M.Ericsson
Summary0007171: Make a template list restriction explicit
DescriptionTemplate list matching, though allows templates, matches only fields of the (received) value that are present. This is descried in the text:
+"Template lists specify lists of acceptable values. ...
+A template field that uses a template list matches the corresponding field if, and only if, the field value matches any one of the values or templates in the template list. ..."
+
+Omit is not a value, thus cannot match a "field value". Consequently the templates in the list shall not resolve to "omit" as a whole. This restriction should be made explicit in the standard in the Restrictions clause to make it clear to the users of the language. Also a note mentioning using ifpresent to match missing fields would be useful, like:
+NOTE: Omitted fields can be matched by adding ifpresent to the template list matching mechanism.
+
+
+
Steps To Reproduce
Additional Information
Tagstechnically agreed
Relationships
Attached Filesdocx CR7171_resolution_v1.docx (78,474) 23-09-2015 10:06
http://oldforge.etsi.org/mantis/file_download.php?file_id=3265&type=bug
docx CR7171_resolution_v2.docx (60,613) 23-09-2015 13:24
http://oldforge.etsi.org/mantis/file_download.php?file_id=3272&type=bug
Issue History
Date ModifiedUsernameFieldChange
09-09-2015 16:49Gyorgy RethyNew Issue
21-09-2015 10:26Gyorgy RethyTarget Version => v4.8.1 (published 2016-07)
22-09-2015 09:44Gyorgy RethyTag Attached: technically agreed
22-09-2015 09:45Gyorgy RethyNote Added: 0013234
22-09-2015 09:45Gyorgy RethyAssigned To => Gyorgy Rethy
22-09-2015 09:45Gyorgy RethyStatusnew => assigned
23-09-2015 10:06Gyorgy RethyFile Added: CR7171_resolution_v1.docx
23-09-2015 10:08Gyorgy RethyNote Added: 0013251
23-09-2015 10:08Gyorgy RethyAssigned ToGyorgy Rethy => Jens Grabowski
23-09-2015 10:08Gyorgy RethyStatusassigned => confirmed
23-09-2015 10:08Gyorgy RethyProduct Version => v4.7.1 (published 2015-06)
23-09-2015 13:24Jens GrabowskiFile Added: CR7171_resolution_v2.docx
23-09-2015 13:27Jens GrabowskiNote Added: 0013266
23-09-2015 13:27Jens GrabowskiAssigned ToJens Grabowski => Gyorgy Rethy
23-09-2015 13:27Jens GrabowskiStatusconfirmed => resolved
04-11-2015 14:03Gyorgy RethyFixed in Version => v4.8.1 (published 2016-07)
04-12-2015 16:33Gyorgy RethyNote Added: 0013562
04-12-2015 16:33Gyorgy RethyStatusresolved => closed
04-12-2015 16:33Gyorgy RethyResolutionopen => fixed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0013234) +
+ Gyorgy Rethy    +
+ 22-09-2015 09:45    +
+ 		+ + + + +
+ STF discussion: templates in the list shall obey the template(present) restriction. Put this into the text and also into a restriction.
+
+
+
+ + + + + + + + + + +
+ (0013251) +
+ Gyorgy Rethy    +
+ 23-09-2015 10:08    +
+ 		+ + + + +
+ Resolution proposal is in CR7171_resolution_v1. Please review.
+
+
+
+ + + + + + + + + + +
+ (0013266) +
+ Jens Grabowski    +
+ 23-09-2015 13:27    +
+ 		+ + + + +
+ Wording slightly changed in v2. Otherwise ok.
+
+
+
+ + + + + + + + + + +
+ (0013562) +
+ Gyorgy Rethy    +
+ 04-12-2015 16:33    +
+ 		+ + + + +
+ Added to draft V4.7.4
+
+ + diff --git a/docs/mantis/CR7172.md b/docs/mantis/CR7172.md new file mode 100644 index 0000000000000000000000000000000000000000..054f2436a30a39ef89b132dfe59867141c741499 --- /dev/null +++ b/docs/mantis/CR7172.md @@ -0,0 +1,647 @@ + + + + + + + + + + + + + 0007172: Is variable initialization with undefined function result allowed? - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007172Part 01: TTCN-3 Core LanguageClarificationpublic10-09-2015 10:3514-12-2015 13:03
ReporterJacob Wieland - Spirent 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.7.1 (published 2015-06) 
Target Versionv4.8.1 (published 2016-07)Fixed in Versionv4.8.1 (published 2016-07) 
Clause Reference(s)11.1, 11.2, 19
Source (company - Author)Testing Technologies - Jacob Wieland
Summary0007172: Is variable initialization with undefined function result allowed?
DescriptionIt is forbidden to assign a variable an undefined value, but it is allowed to explicitly initialize with -, i.e. leave it explicitly uninitialized.
+
+The intent of this was to disallow uninitializing things that are already initialized.
+
+Therefore, it should be clarified that variable initialization with a function call that returns an uninitialized result is allowed (in my understanding, it is, but some customers question that).
+
+Also, maybe the restriction should be relaxed to apply only to (partially) initialized variables. I.e. assignment of uninitialized to an uninitialized variable should be allowed, as it can not be harmful.
+
Steps To Reproduce
Additional Information
Tagstechnically agreed
Relationships
Attached Filesdocx CR7172_resolution_v1.docx (91,441) 23-09-2015 17:54
http://oldforge.etsi.org/mantis/file_download.php?file_id=3275&type=bug
docx CR7172_resolution_v2.docx (103,298) 24-09-2015 15:33
http://oldforge.etsi.org/mantis/file_download.php?file_id=3283&type=bug
docx CR7172_resolution_v3.docx (103,083) 24-09-2015 16:36
http://oldforge.etsi.org/mantis/file_download.php?file_id=3285&type=bug
docx CR7172_resolution_v4.docx (105,421) 25-09-2015 09:55
http://oldforge.etsi.org/mantis/file_download.php?file_id=3287&type=bug
docx CR7172_resolution_v5.docx (107,562) 25-09-2015 13:50
http://oldforge.etsi.org/mantis/file_download.php?file_id=3291&type=bug
docx CR7172_resolution_v6.docx (105,950) 13-10-2015 16:54
http://oldforge.etsi.org/mantis/file_download.php?file_id=3305&type=bug
docx CR7172_resolution_v7.docx (109,746) 13-10-2015 17:26
http://oldforge.etsi.org/mantis/file_download.php?file_id=3306&type=bug
docx CR7172_resolution_v8.docx (112,222) 16-10-2015 08:39
http://oldforge.etsi.org/mantis/file_download.php?file_id=3327&type=bug
docx CR7172_resolution_v8-Comments.docx (84,298) 16-10-2015 10:54
http://oldforge.etsi.org/mantis/file_download.php?file_id=3331&type=bug
docx CR7172_resolution_v9.docx (113,761) 02-11-2015 15:58
http://oldforge.etsi.org/mantis/file_download.php?file_id=3340&type=bug
docx CR7172_resolution_v10.docx (132,430) 03-11-2015 10:42
http://oldforge.etsi.org/mantis/file_download.php?file_id=3346&type=bug
Issue History
Date ModifiedUsernameFieldChange
10-09-2015 10:35Jacob Wieland - SpirentNew Issue
21-09-2015 09:51Gyorgy RethyProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
21-09-2015 10:26Gyorgy RethyTarget Version => v4.8.1 (published 2016-07)
22-09-2015 10:12Gyorgy RethyTag Attached: technically agreed
22-09-2015 10:13Gyorgy RethyNote Added: 0013235
22-09-2015 10:13Gyorgy RethyAssigned To => Gyorgy Rethy
22-09-2015 10:13Gyorgy RethyStatusnew => assigned
23-09-2015 17:54Gyorgy RethyFile Added: CR7172_resolution_v1.docx
23-09-2015 17:56Gyorgy RethyNote Added: 0013280
23-09-2015 17:56Gyorgy RethyAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
23-09-2015 17:56Gyorgy RethyStatusassigned => confirmed
23-09-2015 17:56Gyorgy RethyProduct Version => v4.7.1 (published 2015-06)
24-09-2015 10:53Jacob Wieland - SpirentNote Added: 0013286
24-09-2015 10:53Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
24-09-2015 10:53Jacob Wieland - SpirentStatusconfirmed => assigned
24-09-2015 15:33Jacob Wieland - SpirentFile Added: CR7172_resolution_v2.docx
24-09-2015 16:36Gyorgy RethyFile Added: CR7172_resolution_v3.docx
24-09-2015 16:39Gyorgy RethyNote Added: 0013298
24-09-2015 16:39Gyorgy RethyAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
24-09-2015 16:39Gyorgy RethyStatusassigned => confirmed
24-09-2015 16:56Jacob Wieland - SpirentNote Added: 0013299
25-09-2015 09:51Jacob Wieland - SpirentFile Added: CR7172_resolution_v4.docx
25-09-2015 09:55Jacob Wieland - SpirentFile Deleted: CR7172_resolution_v4.docx
25-09-2015 09:55Jacob Wieland - SpirentFile Added: CR7172_resolution_v4.docx
25-09-2015 09:56Jacob Wieland - SpirentStatusconfirmed => assigned
25-09-2015 09:57Jacob Wieland - SpirentNote Added: 0013300
25-09-2015 09:57Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
25-09-2015 09:57Jacob Wieland - SpirentStatusassigned => confirmed
25-09-2015 13:50Gyorgy RethyFile Added: CR7172_resolution_v5.docx
25-09-2015 13:56Gyorgy RethyNote Added: 0013313
25-09-2015 13:57Gyorgy RethyAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
25-09-2015 15:38Gyorgy RethyNote Edited: 0013313bug_revision_view_page.php?bugnote_id=13313#r173
26-09-2015 11:40Jacob Wieland - SpirentNote Added: 0013330
26-09-2015 12:16Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
26-09-2015 12:16Jacob Wieland - SpirentStatusconfirmed => assigned
13-10-2015 16:42Gyorgy RethyFile Added: CR7172_resolution_v6.docx
13-10-2015 16:50Gyorgy RethyNote Added: 0013378
13-10-2015 16:50Gyorgy RethyFile Deleted: CR7172_resolution_v6.docx
13-10-2015 16:54Gyorgy RethyFile Added: CR7172_resolution_v6.docx
13-10-2015 16:54Gyorgy RethyAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
13-10-2015 16:54Gyorgy RethyStatusassigned => confirmed
13-10-2015 17:26Jacob Wieland - SpirentFile Added: CR7172_resolution_v7.docx
13-10-2015 17:26Jacob Wieland - SpirentNote Added: 0013379
13-10-2015 17:27Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
13-10-2015 17:27Jacob Wieland - SpirentStatusconfirmed => assigned
13-10-2015 17:27Jacob Wieland - SpirentNote Added: 0013380
13-10-2015 17:27Jacob Wieland - SpirentAssigned ToGyorgy Rethy => Jens Grabowski
13-10-2015 17:27Jacob Wieland - SpirentStatusassigned => confirmed
15-10-2015 15:50Jens GrabowskiNote Added: 0013419
15-10-2015 15:51Jens GrabowskiAssigned ToJens Grabowski => Gyorgy Rethy
15-10-2015 15:51Jens GrabowskiStatusconfirmed => assigned
16-10-2015 08:39Jacob Wieland - SpirentFile Added: CR7172_resolution_v8.docx
16-10-2015 08:42Jacob Wieland - SpirentNote Added: 0013422
16-10-2015 08:43Jacob Wieland - SpirentAssigned ToGyorgy Rethy => Jens Grabowski
16-10-2015 08:43Jacob Wieland - SpirentStatusassigned => confirmed
16-10-2015 10:54Jens GrabowskiFile Added: CR7172_resolution_v8-Comments.docx
16-10-2015 10:55Jens GrabowskiNote Added: 0013428
16-10-2015 10:55Jens GrabowskiAssigned ToJens Grabowski => Gyorgy Rethy
16-10-2015 10:55Jens GrabowskiStatusconfirmed => assigned
16-10-2015 13:26Jacob Wieland - SpirentAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
16-10-2015 13:26Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
16-10-2015 13:26Jacob Wieland - SpirentStatusassigned => confirmed
02-11-2015 15:48Gyorgy RethyFile Added: CR7172_resolution_v9.docx
02-11-2015 15:56Gyorgy RethyNote Added: 0013447
02-11-2015 15:56Gyorgy RethyAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
02-11-2015 15:56Gyorgy RethyStatusconfirmed => assigned
02-11-2015 15:58Gyorgy RethyFile Deleted: CR7172_resolution_v9.docx
02-11-2015 15:58Gyorgy RethyFile Added: CR7172_resolution_v9.docx
03-11-2015 10:42Jacob Wieland - SpirentFile Added: CR7172_resolution_v10.docx
03-11-2015 10:46Jacob Wieland - SpirentNote Added: 0013460
03-11-2015 10:46Jacob Wieland - SpirentStatusassigned => resolved
03-11-2015 10:46Jacob Wieland - SpirentFixed in Version => v4.8.1 (published 2016-07)
03-11-2015 10:46Jacob Wieland - SpirentResolutionopen => fixed
03-11-2015 10:46Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
14-12-2015 13:03Gyorgy RethyNote Added: 0013616
14-12-2015 13:03Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0013235) +
+ Gyorgy Rethy    +
+ 22-09-2015 10:13    +
+ 		+ + + + +
+ STF discussion: clarify that initialization is an assignment. Check also functions returning uninitialized.
+
+
+
+ + + + + + + + + + +
+ (0013280) +
+ Gyorgy Rethy    +
+ 23-09-2015 17:56    +
+ 		+ + + + +
+ Proposed resolution is in CR7172_resolution_v1.docx. Please review.
+
+
+
+ + + + + + + + + + +
+ (0013286) +
+ Jacob Wieland - Spirent    +
+ 24-09-2015 10:53    +
+ 		+ + + + +
+ Unfortunately, this proposal does not solve the problem. Defining initialization does not carry over the restrictions of the Assignment statement to the initialization assignment part of the variable declaration statement.
+
+You are confusing the concept of assignment with the Assignment sintatement. The Assignment statement is a syntactical structure. Thus, all restrictions in the section Assignments is only applicable to those statements (unless stated otherwise).
+
+What would be helpful would be adding in the Declaring Variables section that all restrictions on Assignment statements in the Assignments section also apply to the initialization part.
+
+
+
+ + + + + + + + + + +
+ (0013298) +
+ Gyorgy Rethy    +
+ 24-09-2015 16:39    +
+ 		+ + + + +
+ In CR7172_resolution_v3.docx restrictions are added to the value variable, template variable and template clauses. Also a sentence is added to the completely initialized definition saying that {} also initializes empty records and sets, as we just have discussed.
+
+
+
+ + + + + + + + + + +
+ (0013299) +
+ Jacob Wieland - Spirent    +
+ 24-09-2015 16:56    +
+ 		+ + + + +
+ First question: Why is the text about structurd types (for completely initialized definition) in a NOTE while the one for simple types isn't?
+
+Secondly: I still think this text leaves the question open whether or not an empty record/set type or a record of/set of/array type with min length 0 is already completely initialized without assigning {}. Since mathematically, the first sentence already applies to these types (all elements or fields - the empty set here - have been completely initialized), that sentence alone does not force any additional action for complete initialization.
+
+The following sentence is also no further restriction on this. It says, that if you initialize with {}, then it is completely initialized, but that is not a necessary condition for completely initialized, just a valid one. I'm missing something like "at least" or "only", saying that for empty record/set types, for them to become completely initialized they HAVE to be assigned {} and the same for record of/set of/array types.
+
+
+
+ + + + + + + + + + +
+ (0013300) +
+ Jacob Wieland - Spirent    +
+ 25-09-2015 09:57    +
+ 		+ + + + +
+ changed the wording of completely initialized to be less ambiguous. please review
+
+
+
+ + + + + + + + + + +
+ (0013313) +
+ Gyorgy Rethy    +
+ 25-09-2015 13:56    +
(edited on: 25-09-2015 15:38)
+ 		+ + + + +
+ Now, in CR7172_resolution_v5.docx I have separated the cases: simple type, unions, record/set-s and record/set of-s, as we discussed. I think that trying to define common rules for record/set and record/set of-s was one of the source of the problems as they are, in fact, completely different constructs.
+
+I have restored the NOTE that now lists "the solutions" for some interesting/specific cases. I hope that this, together with the definition of initialization solves the empty record/set issue. If not, then we will have to insert a sentence about initialization of empty record/sets to clauses 6.2.1 and 6.2.2.
+
+
+
+
+
+ + + + + + + + + + +
+ (0013330) +
+ Jacob Wieland - Spirent    +
+ 26-09-2015 11:40    +
+ 		+ + + + +
+ Unfortunately, the mandatory definition text is still implying that empty structured types are completely initialized even without assignment (all their elements/fields HAVE been completely initialized). The NOTE contradicts this and is thus more restrictive.
+
+The last sentence that completely initialized implies "at least partially initialized" is necessary as for partially initialized it is necessary that at least one field/element has been partially initialized. For empty values, that is not true, therefore, it must be stated explicitly somewhere.
+
+
+
+ + + + + + + + + + +
+ (0013378) +
+ Gyorgy Rethy    +
+ 13-10-2015 16:50    +
+ 		+ + + + +
+ See CR7172_resolution_v6.docx. I have no better idea than slicing the cases further on to empty and non-empty record/set-s. jacob, if you have further comment, please come up with a concrete text proposal in a new version of the file.
+
+
+
+ + + + + + + + + + +
+ (0013379) +
+ Jacob Wieland - Spirent    +
+ 13-10-2015 17:26    +
+ 		+ + + + +
+ I have added another proposal that, in my opinion, is airtight regarding this issue.
+
+
+
+ + + + + + + + + + +
+ (0013380) +
+ Jacob Wieland - Spirent    +
+ 13-10-2015 17:27    +
+ 		+ + + + +
+ please review and resolve
+
+
+
+ + + + + + + + + + +
+ (0013419) +
+ Jens Grabowski    +
+ 15-10-2015 15:50    +
+ 		+ + + + +
+ I am sorry, the more I am reading the resolutions the less I understand it.
+
+I understand that variables or parameters can be uninitialized, partially initialized or completely initialized, but I don’t understand how a value can be uninitialized, partially initialized or completely initialized.
+
+A variable has a type which defines the possible set of values for this variable (its domain).
+
+Uninitialized means that you can say nothing about the relation between value of the variable and its domain.
+
+Completely initialized means that the variable value represents exactly one value in the domain of the variable.
+
+Partially initialized means that parts of the variable value are known, i.e., are completely initialized, and that other parts remain uninitialized.
+
+Maybe it is easier to argue along this line instead of making examples for all kinds of types.
+
+
+
+ + + + + + + + + + +
+ (0013422) +
+ Jacob Wieland - Spirent    +
+ 16-10-2015 08:42    +
+ 		+ + + + +
+ added another version which defines three disjoint states: uninitialized, partially initialized (only possible for structured types) and completely initialized. The attached NOTES are just for clarification of the special cases. The definitions should reflect our requirements.
+
+please review once more.
+
+
+
+ + + + + + + + + + +
+ (0013428) +
+ Jens Grabowski    +
+ 16-10-2015 10:55    +
+ 		+ + + + +
+ I can live with this definition.
+
+
+
+ + + + + + + + + + +
+ (0013447) +
+ Gyorgy Rethy    +
+ 02-11-2015 15:56    +
+ 		+ + + + +
+ CR7172_resolution_v9.docx: I have made the different options of initialization a note as Jens proposed (no change in text).
+I changed partially initialized:
+- we say that completely initialized things are also fulfils partially initialized criteria, while the new text for partially initialized excluded this (saying that it is uninitialized and not completely initialized.
+- I prefer some direct definition instead of saying that it is not uninitialized (it seems to be obvious, in this case no definition would be needed).
+
+
+
+ + + + + + + + + + +
+ (0013460) +
+ Jacob Wieland - Spirent    +
+ 03-11-2015 10:46    +
+ 		+ + + + +
+ replaced "no content initialization" with "no initialization of it or at least one of its parts" in the definition of uninitialized. content initialization is too ambiguous (someone might think that only content initialization can change the state from uninitialized to not uninitialized, but the assignment of {} does not initialize content, but still initializes).
+
+Also deleted superfluous sub-sentence about omit in the values section (according to Jens's comment).
+
+
+
+ + + + + + + + + + +
+ (0013616) +
+ Gyorgy Rethy    +
+ 14-12-2015 13:03    +
+ 		+ + + + +
+ Added to drfat V4.7.4
+
+ + diff --git a/docs/mantis/CR7173.md b/docs/mantis/CR7173.md new file mode 100644 index 0000000000000000000000000000000000000000..7ab09e4e8b2c74500c90dce79e43063a455c065f --- /dev/null +++ b/docs/mantis/CR7173.md @@ -0,0 +1,139 @@ + + + + + + + + + + + + + 0007173: Semantic description of Assignments is contradictory - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007173Part 01: TTCN-3 Core LanguageClarificationpublic10-09-2015 10:4011-12-2015 14:50
ReporterJacob Wieland - Spirent 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.8.1 (published 2016-07)Fixed in Versionv4.8.1 (published 2016-07) 
Clause Reference(s)19.1
Source (company - Author)Testing Technologies - Jacob Wieland
Summary0007173: Semantic description of Assignments is contradictory
DescriptionIn section 19.1 Assignments, it is stated in the Semantic Description part:
+
+"The expression shall contain no unbound variables."
+
+in the next paragraph it is stated (contradictorily):
+
+"If a partially initialized value is assigned to a completely initialized variable, fields uninitialized at the right-hand side of the assignment shall also become uninitialized at the left-hand side."
+
+Also, the first restriction can not be found in the Restrictions part of the section.
Steps To Reproduce
Additional Information
Tagstechnically agreed
Relationships
Attached Filesdocx CR7173_resolution.docx (170,366) 15-10-2015 12:57
http://oldforge.etsi.org/mantis/file_download.php?file_id=3316&type=bug
Issue History
Date ModifiedUsernameFieldChange
10-09-2015 10:40Jacob Wieland - SpirentNew Issue
21-09-2015 09:46Gyorgy RethyProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
21-09-2015 10:26Gyorgy RethyTarget Version => v4.8.1 (published 2016-07)
22-09-2015 10:21Gyorgy RethyNote Added: 0013236
22-09-2015 10:21Gyorgy RethyTag Attached: technically agreed
22-09-2015 10:21Gyorgy RethyAssigned To => Gyorgy Rethy
22-09-2015 10:21Gyorgy RethyStatusnew => assigned
15-10-2015 12:57Jacob Wieland - SpirentFile Added: CR7173_resolution.docx
15-10-2015 12:57Jacob Wieland - SpirentNote Added: 0013405
15-10-2015 12:57Jacob Wieland - SpirentStatusassigned => resolved
15-10-2015 12:57Jacob Wieland - SpirentResolutionopen => fixed
04-11-2015 14:03Gyorgy RethyFixed in Version => v4.8.1 (published 2016-07)
11-12-2015 14:50Gyorgy RethyNote Added: 0013594
11-12-2015 14:50Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0013236) +
+ Gyorgy Rethy    +
+ 22-09-2015 10:21    +
+ 		+ + + + +
+ STF discussion: delete the sentence, restrictions available in other parts.
+
+
+
+ + + + + + + + + + +
+ (0013405) +
+ Jacob Wieland - Spirent    +
+ 15-10-2015 12:57    +
+ 		+ + + + +
+ added proposal with deleted sentence
+
+
+
+ + + + + + + + + + +
+ (0013594) +
+ Gyorgy Rethy    +
+ 11-12-2015 14:50    +
+ 		+ + + + +
+ Added to draft V4.7.4
+
+ + diff --git a/docs/mantis/CR7174.md b/docs/mantis/CR7174.md new file mode 100644 index 0000000000000000000000000000000000000000..24606a8ca7f189650d0c8899533c37e1b977aa90 --- /dev/null +++ b/docs/mantis/CR7174.md @@ -0,0 +1,830 @@ + + + + + + + + + + + + + 0007174: New matching mechanism: matching by function - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Advanced Matching (ES 203 022)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007174Ext Pack: Advanced Matching (ES 203 022)New Featurepublic11-09-2015 08:5724-12-2016 12:01
ReporterTomas Urban 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv1.1.1 (published 2017-07)Fixed in Version 
Clause Reference(s)15.7, B.1
Source (company - Author)Elvior
TS version
Summary0007174: New matching mechanism: matching by function
DescriptionCurrent TTCN-3 matching mechanisms are very efficient in dealing with quite many standard situations. However, there's always possibility that matching conditions are too complicated and none of the matching mechanisms can be used. The typical solution in this case is performing additional checking in the code block attached to receive statements.
+
+This approach has unfortunately quite many drawbacks that are mostly related to the jump out of the snapshot mechanism. For that reason I propose a new matching mechanism that would allow the users to define their own custom matching procedure.
+
+Syntax:
+
+function match FunctionIdentifier
+// NOTE: there might be more elegant syntax options. The current proposal
+// advantage is that it uses existing keywords and pretty well describes
+// the functionality
+
+Semantics:
+FunctionIdentifier shall be a reference to a function that accepts a single in value parameter and returns boolean. The matching mechanism matches values of the same type or compatible type as the type of the parameter.
+
+When matching, the referenced function is called with the matched value passed to it as an actual parameter. Succesful match is achieved only if the function returns true.
+
+Restrictions:
+a. When used in receiving communication operations, rules from the section 16.1.4 apply.
+b. An error shall be produced when the referenced function returns something else than a boolean value.
+c. An error shall be produced when the referenced function contains a different number of parameter than 1.
+d. An error shall be produced when the parameter of the referenced function is not an in value paremeter.
+
+Required modifications in other rules:
+15.6: the matching mechanism doesn't allow to reference subfields and it should be therefore listed in 15.6.2.a, 15.6.3.b, 15.6.4.a, 15.6.5.a
+
+Example:
+
+type record R {
+  charstring startDate,
+  charstring endDate
+}
+
+function f_extractMonth(charstring p_date) return integer {
+  // unspecified algorithm to extract month from a string-based date
+}
+
+function f_isMonthTheSame(in R p_rec) return boolean {
+  return f_extractMonth(p_rec.startDate) == f_extractMonth(p_rec.endDate);
+}
+
+template R mw_monthMatch := function match f_isMonthTheSame;
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0007494closed Jens Grabowski TRI and TCI extensions for advanced matching 
related to 0007175closed Jens Grabowski No easy way to describe conjunction matching mechanism. 
related to 0007167closed Jens Grabowski Matching mechanism to match multiple items in arrays, records and sets of single types 
Attached Filespptx Dynamic-Matching-Templates-Ideas-160722.pptx (31,688) 22-07-2016 13:36
http://oldforge.etsi.org/mantis/file_download.php?file_id=3434&type=bug
docx CR7174.docx (147,228) 16-08-2016 09:21
http://oldforge.etsi.org/mantis/file_download.php?file_id=3450&type=bug
docx CR7174-v2.docx (148,644) 16-08-2016 11:44
http://oldforge.etsi.org/mantis/file_download.php?file_id=3459&type=bug
docx CR7174-3.docx (167,385) 18-08-2016 15:23
http://oldforge.etsi.org/mantis/file_download.php?file_id=3491&type=bug
docx CR7174-4.docx (170,169) 19-08-2016 15:08
http://oldforge.etsi.org/mantis/file_download.php?file_id=3505&type=bug
Issue History
Date ModifiedUsernameFieldChange
11-09-2015 08:57Tomas UrbanNew Issue
11-09-2015 10:07Jacob Wieland - SpirentNote Added: 0013196
11-09-2015 10:08Jacob Wieland - SpirentNote Edited: 0013196bug_revision_view_page.php?bugnote_id=13196#r162
11-09-2015 10:09Jacob Wieland - SpirentNote Edited: 0013196bug_revision_view_page.php?bugnote_id=13196#r163
11-09-2015 10:36Tomas UrbanNote Added: 0013197
21-09-2015 10:07Gyorgy RethyRelationship addedrelated to 0007175
21-09-2015 10:25Gyorgy RethyTarget Version => v4.8.1 (ongoing)
21-09-2015 11:11Gyorgy RethyRelationship addedrelated to 0007167
22-09-2015 11:35Gyorgy RethyNote Added: 0013237
22-09-2015 11:40Gyorgy RethyNote Edited: 0013237bug_revision_view_page.php?bugnote_id=13237#r171
24-09-2015 13:19Jacob Wieland - SpirentNote Added: 0013289
25-09-2015 10:19Jacob Wieland - SpirentNote Added: 0013301
30-09-2015 15:00Tomas UrbanNote Added: 0013342
01-10-2015 08:48Jacob Wieland - SpirentNote Added: 0013343
01-10-2015 09:18Jacob Wieland - SpirentNote Added: 0013344
01-10-2015 10:36Tomas UrbanNote Added: 0013345
01-10-2015 11:06Jacob Wieland - SpirentNote Added: 0013346
01-10-2015 11:08Jacob Wieland - SpirentNote Edited: 0013346bug_revision_view_page.php?bugnote_id=13346#r175
03-11-2015 11:55Gyorgy RethyTarget Versionv4.8.1 (ongoing) => Next version (to be defined)
03-11-2015 11:56Gyorgy RethyNote Added: 0013465
03-11-2015 11:59Gyorgy RethyNote Edited: 0013465bug_revision_view_page.php?bugnote_id=13465#r200
05-11-2015 11:01Gyorgy RethyProjectPart 01: TTCN-3 Core Language => Ext Pack: Advanced Matching (ES 203 022)
05-11-2015 11:08Gyorgy RethyProduct Versionv4.7.1 (published 2015-06) =>
05-11-2015 11:08Gyorgy RethyTarget VersionNext version (to be defined) => v1.1.1 (published 2017-07)
18-07-2016 11:24Jens GrabowskiAssigned To => Jens Grabowski
18-07-2016 11:24Jens GrabowskiStatusnew => assigned
22-07-2016 13:36Jens GrabowskiFile Added: Dynamic-Matching-Templates-Ideas-160722.pptx
15-08-2016 13:10Jens GrabowskiAssigned ToJens Grabowski => Jacob Wieland - Spirent
15-08-2016 16:00Jacob Wieland - SpirentFile Added: CR7174.docx
15-08-2016 16:02Jacob Wieland - SpirentNote Added: 0014081
15-08-2016 16:02Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Jens Grabowski
15-08-2016 16:02Jacob Wieland - SpirentStatusassigned => confirmed
16-08-2016 09:21Jacob Wieland - SpirentFile Deleted: CR7174.docx
16-08-2016 09:21Jacob Wieland - SpirentFile Added: CR7174.docx
16-08-2016 09:21Jacob Wieland - SpirentNote Added: 0014087
16-08-2016 11:44Jens GrabowskiFile Added: CR7174-v2.docx
16-08-2016 11:44Jens GrabowskiNote Added: 0014103
16-08-2016 11:45Jens GrabowskiAssigned ToJens Grabowski => Tomas Urban
16-08-2016 11:45Jens GrabowskiStatusconfirmed => assigned
18-08-2016 15:23Tomas UrbanFile Added: CR7174-3.docx
18-08-2016 15:24Tomas UrbanRelationship addedrelated to 0007494
18-08-2016 15:26Tomas UrbanNote Added: 0014157
18-08-2016 15:26Tomas UrbanAssigned ToTomas Urban => Axel Rennoch
18-08-2016 15:26Tomas UrbanStatusassigned => confirmed
19-08-2016 15:08Axel RennochFile Added: CR7174-4.docx
19-08-2016 15:11Axel RennochNote Added: 0014188
19-08-2016 15:11Axel RennochAssigned ToAxel Rennoch => Jens Grabowski
19-08-2016 15:11Axel RennochStatusconfirmed => assigned
14-11-2016 10:38Jens GrabowskiStatusassigned => confirmed
17-11-2016 12:37Jens GrabowskiStatusconfirmed => resolved
17-11-2016 12:37Jens GrabowskiResolutionopen => fixed
24-12-2016 12:01Jens GrabowskiStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0013196) +
+ Jacob Wieland - Spirent    +
+ 11-09-2015 10:07    +
(edited on: 11-09-2015 10:09)
+ 		+ + + + +
+ I second the proposal. Since other templates can also use functions for initialization, there is no new problem concerning the Halting Problem with these new functions.
+
+Also, since no object can be both of type T and of type T => boolean, it would probably be sufficient to just allow any deterministic function-reference of type function(T x) return boolean as matching mechanism for a template of type T.
+
+I.e.
+
+I would also simply allow:
+
+template R x := f
+
+if f is of type function(R y) return boolean.
+
+Since this at the moment is a semantic error, there is no backward compatibility issue with that.
+
+If used in modifies, it should be replaced fully (if it is part of the base template) or replace fully if it is in the modifying template.
+
+I'm a bit against using 'function' as a keyword for that matching mechanism as this will make error-recovery for parsers harder which rely on declaration-keywords. In that case, I would prefer a modifier @matching or simple @is, i.e.
+
+template R x := @matching f
+
+or
+
+template R x := @is f
+
+This @is is motivated by the fact that boolean functions are normally considered semantically equivalent to predicates and for a predicate P 'P(v)' is the same as 'v is P'.
+
+
+
+
+
+ + + + + + + + + + +
+ (0013197) +
+ Tomas Urban    +
+ 11-09-2015 10:36    +
+ 		+ + + + +
+ I have no problem with the proposed modifiers. However, I would prefer not to use function identifiers directly because of a negative impact on readability of the code. The syntax looks the same as a variable/template reference and if naming convensions are not strictly followed, the real meaning of the matching mechanism won't be immediately obvious. It is probably also more complicated to implement it than the solution with a modifier.
+
+
+
+ + + + + + + + + + +
+ (0013237) +
+ Gyorgy Rethy    +
+ 22-09-2015 11:35    +
(edited on: 22-09-2015 11:40)
+ 		+ + + + +
+ STF discussion:
+- the feature is useful
+- the body shall be deterministic and without side effects to snapshots
+- its declaration is open yet: it can be a new language "class" user defined matching mechanism or a function with a specific prototype. This to be decided.
+- Parameterization to be allowed, but the concrete syntax still need to be agreed.
+- Alternative idea defining dynamic templates with a function-like body (see restrictions above) and returning boolean (without a return clause in the header).
+- A new package for advanced matching is to be considered.
+
+
+
+
+
+ + + + + + + + + + +
+ (0013289) +
+ Jacob Wieland - Spirent    +
+ 24-09-2015 13:19    +
+ 		+ + + + +
+ Syntactically, I would propose the following:
+
+@dynamic template ReferencedType Identifier[FormalParList] StatementBlock
+
+In the body part, I would refer to the argument per default as _ (single underscore).
+
+In easy expressions, this looks like this:
+
+return _ > 5;
+
+If a name should be given to the parameter, it can be done by simple variable/constant declaration:
+
+var T x := _;
+
+This way, there is no need for an additional syntactical way of declaring the template-instance-parameter name and it is still possible to give it a name, if so desired.
+
+The underscore does not clash with the normal identifiers as they need to start with a letter.
+
+Alternatively, we could allow the following lambda-closure-like syntax:
+
+@dynamic template ReferencedType Identifier[FormalParList] ":=" "(" Identifier ")" "=>" StatementBlock
+
+where the Identifier before the "=>" is the name of the value to be matched
+
+This would actually also work great with inline-templates:
+
+T:(x) => { ... }
+
+because
+
+T:{ ... } needs possibly indefinite parser lookahead (you need to find out if the block begins with a statement of with a field assignment or with an element) to distinguish from non-dynamic templates.
+
+If not going with the lambda-notation, inline dynamic templates thus need also be prefixed with the @dynamic modifier:
+
+p.receive(@dynamic T:{...})
+
+Additionally, as a shorthand notation for statement blocks that only contain a return statement, we could use the declarative notation:
+
+@dynamic template ReferencedType Identifier[FormalParList] := [(Identifier) =>] BooleanExpression
+
+as in (if isOdd is a @deterministic boolean function with an integer formal parameter):
+
+@dynamic template integer odd := isOdd(_);
+
+or inline
+
+@dynamic integer:isOdd(_)
+
+or
+
+@dynamic template integer odd := (x) => isOdd(x);
+
+or inline
+
+@dynamic integer:(x) => isOdd(x)
+
+For the very common pattern: (x) => f(x), we could also allow just f, which would shorten the above to:
+
+@dynamic template integer odd := isOdd;
+or inline
+@dynamic integer:isOdd
+
+Finally, for places where the type of the template is already known, i.e. for template fields or template parameters, we could allow both
+
+(Identifier) => BooleanExpression,
+(Identifier) => StatementBlock and
+BooleanFunctionReference
+
+(maybe the last thing should be (optionally or mandatory) prefixed with @dynamic)
+
+
+
+ + + + + + + + + + +
+ (0013301) +
+ Jacob Wieland - Spirent    +
+ 25-09-2015 10:19    +
+ 		+ + + + +
+ Thinking about this some more, I think it is probably best to not allow the underscore-notation. It is too abstract and also not compositional (i.e. if in the body of the function, another inline template is used, the inner _ would shadow the outer _ and that is normally not allowed in TTCN-3.
+
+The notation
+
+(x) => BooleanExpression
+
+also has the drawback that you potentially need indefinite look-ahead in the parser (if using LL-approach) to determine that it is not the (x) => StatementBlock notation (in the special, though probably pathological case that the boolean expression starts with a compound value, like in { ... } == x. Limiting the syntax of the BooleanExpression to a subset that does not clash in prefix with the StatementBlock is not good language design, either.
+
+So, the remaining syntaxes would be:
+
+(x) => StatementBlock
+
+FunctionReference (for the special case (x) => { return f(x) }), possibly with a modifier in front like @dynamic or @match or @is.
+
+
+
+ + + + + + + + + + +
+ (0013342) +
+ Tomas Urban    +
+ 30-09-2015 15:00    +
+ 		+ + + + +
+ I think it is better to keep things as simple as possible. Parameter passing can be resolved by using lambda closure in a similar way as in the case of @lazy and @fuzzy variables.
+
+From the syntactical point of view, I would skip the (x) part completely and use a modifier as a prefix followed always by a statement block. This kind of syntax should be easy to parse and won't cause any grammar conflicts. The syntax would be then:
+
+modifier StatementBlock
+
+For referencing the matched value, I would use a universal identifier such as "value". The value keyword is already present in TTCN-3 and it is commonly used as a context-specific variable identifier (e.g. in C#).
+
+Examples:
+// @dynamic modifier is used, but any of Jacob's proposed alternatives is fine
+
+// simple dynamic template
+template integer mw_greaterThan2 := @dynamic { return value > 2; }
+
+// parameterized dynamic template
+template integer mw_greaterThanParam(integer p_par) := @dynamic { return value > p_par; }
+
+// calling a function
+template integer mw_matchByFunction := @dynamic { return f_myFunc(value); }
+
+// when used inside a block
+function f_createTemplate() return template integer
+{
+  var integer v_var1, v_var2;
+  // ... compute v_var1 and v_var2
+
+  // lambda closure required to keep the values of v_var1 and v_var2 after exiting the function
+  return @dynamic { return value * v_var1 > v_var2; };
+}
+
+
+
+ + + + + + + + + + +
+ (0013343) +
+ Jacob Wieland - Spirent    +
+ 01-10-2015 08:48    +
+ 		+ + + + +
+ I am fine with this proposal (although it complicates the implementation of the compilation frontend quite a bit).
+
+It is also compositional (if a dynamic template uses another dynamic template inside its body, it must simply declare a variable/constant referring to the value so that the inner template can access it (as the inner 'value' shadows that outer 'value').
+
+It cannot clash with the normal use of the value-keyword as inside such bodies, no blocking or otherwise state-changing statements are allowed.
+
+It would still like to have a shorthand version for the @dynamic { return f(value) } template. Either
+
+@dynamic <FunctionReference> (which is clearly distinguished syntactically as <FunctionReference> must start with an identifier and the other starts with opening bracket '{')
+
+or using a different modifier like @is or @match (which is simply more readable but introduces another modifier)
+
+For the last example you gave (which produced the closure), I would add a restriction that a dynamic template shall not reference their context's inout or out parameters or their sub-structures as the target of an assignment (or not at all, to avoid confusion). That way, there is no need to explain what the semantics of such an assignment would be.
+
+
+
+ + + + + + + + + + +
+ (0013344) +
+ Jacob Wieland - Spirent    +
+ 01-10-2015 09:18    +
+ 		+ + + + +
+ Thinking some more on this, I would actually disallow any reference to any variable or parameter (except read-access to the template-parameters if we are contextually inside a parameterized template because they cannot change) inside a @dynamic body.
+
+consider the following example:
+function g(template integer p) {
+}
+
+function f(integer p) return template integer {
+  var template integer t := @dynamic { value > p };
+  while (...) {
+    ptc.start(g(t));
+    p := ...;
+    ptc.done;
+  }
+}
+
+Here, it would be unclear that the reference p inside the lambda-template when used by g would be and even worse, there is suddenly some data-sharing between the component running f and the one running g. Similar things are true if write-access to outside-variables by the dynamic template were allowed.
+
+If we restrict that the only things from outside the dynamic block that can be referenced are const and non-var template and formal parameters of the containing template, this cannot happen.
+
+Of course, in your lambda-example, this would lead to the inconvenience that v_var1 and v_var2 need to be copied to const c_1 and c_2 and referenced as these from the dynamic block.
+
+If this restriction is not added, then a different semantics needs to be given to references of outside-variables inside a dynamic block, i.e. they are implicit formal in parameters whose initial value is the one their outside-namesake has when the @dynamic block is instantiated. While this approach is a little bit more convenient for the user, it has a level of implicitly that might be confusing (it could also be added later if the restrictive approach is deemed to cumbersome).
+
+
+
+ + + + + + + + + + +
+ (0013345) +
+ Tomas Urban    +
+ 01-10-2015 10:36    +
+ 		+ + + + +
+ Well written, Jacob! I didn't notice the component issue at all.
+
+1. I like the explanation you provided for the direct function call notation, i.e. that @dynamic FunctionIdentifier is a shorthand for @dynamic { return FunctionIdentifier(value); }
+
+This so far the best explanation and completely in-line with similar shortcuts that are already present in the TTCN-3 specification.
+
+2. For the closure issues I propose two semantic restrictions:
+
+a. In the statement block of the @dynamic matching mechanism, only variables defined in this block can appear on left hand side of an assignment and as an actual parameter of formal out and inout parameters. Using any other variable in these place shall produce an error.
+-> This restriction should prevent the assignment issue already in the compilation stage. We don't have to use copying which might be actually undesirable, because in some cases the user might want to compare the matched value against the actual variable value.
+
+b. Templates containing a @dynamic matching mechanism created in functions, test cases or altsteps running on a main or parallel test component cannot be used as a parameter of a function referenced in a component.start operation. Using such a template shall produce an error.
+-> The rule should prevent possibility of dynamic access to other component variables.
+
+I agree that compilation might be complicated, because the mechanism itself is not strongly typed, but the type should be always visible from the the context:
+
+template MyType mw_t1 := @dynamic{...} // type from the template definition
+template MyRec mw_t2 := {
+   field1 := ?
+   field2 := @dynamic {...} // typed according to MyRec.field2 definition
+}
+p.receive(MyType:@dynamic {...}); // using inline type
+f_func(@dynamic {...}); // using function parameter type
+
+
+
+ + + + + + + + + + +
+ (0013346) +
+ Jacob Wieland - Spirent    +
+ 01-10-2015 11:06    +
(edited on: 01-10-2015 11:08)
+ 		+ + + + +
+ I don't think that your restriction b. is a good idea as in general it can only be checked at runtime (can only be statically checked if the @dynamic template is actually part of the start-statement). Runtime-checks always introduce inefficiency during execution and also have the drawback that often standardization-bodies do not execute their tests and thus errors come to light only much later and it takes a lot of time until they are officially fixed.
+
+The restrictions I proposed are easily checked statically (at compile-time), even though they introduce some inconvenience to the usage (though not much, you could easily declare all the variables-to-be-used as const from the beginning and then simply initialize with the computed value directly).
+
+Otherwise, I would rather opt for the copy-semantics, i.e.
+
+if the variables/parameters (not parameters of the enclosing parameterized template) V1 ... Vn which are not declared but used in the @dynamic B body B have the types T1 ... Tn respectively, the semantics of @dynamic B is the same as t(V1, ..., Vn) where t is an implicit generic template t(T1 V1, ..., Tn Vn) := @dynamic B (with this semantic trick a copy of each variable at the time of template instantiation is used in B).
+
+The frontend-issue I mentioned is more the problem that suddenly the value-keyword can be used as an identifier in a certain context and it is context-dependent whether it shall be interpreted as a keyword or as an identifier. It's not an unsolvable problem, but it is tricky.
+
+The type of the 'value' keyword, of course, is always the type of the whole dynamic template, so that type always must be known, either by the inline-template-type-prefix or because the template is used in a context whose type is known.
+
+
+
+
+
+ + + + + + + + + + +
+ (0013465) +
+ Gyorgy Rethy    +
+ 03-11-2015 11:56    +
(edited on: 03-11-2015 11:59)
+ 		+ + + + +
+ To be part of the new extension on advanced matching mechanisms.
+
+
+
+
+
+ + + + + + + + + + +
+ (0014081) +
+ Jacob Wieland - Spirent    +
+ 15-08-2016 16:02    +
+ 		+ + + + +
+ Added main section and BNF changes.
+
+Please review.
+
+Still missing: TCI changes.
+
+
+
+ + + + + + + + + + +
+ (0014087) +
+ Jacob Wieland - Spirent    +
+ 16-08-2016 09:21    +
+ 		+ + + + +
+ refined the restriction on in parameters to be more airtight
+
+
+
+ + + + + + + + + + +
+ (0014103) +
+ Jens Grabowski    +
+ 16-08-2016 11:44    +
+ 		+ + + + +
+ Tomas: Can you proofread the text and add a section on TCI changes if needed.
+
+
+
+ + + + + + + + + + +
+ (0014157) +
+ Tomas Urban    +
+ 18-08-2016 15:26    +
+ 		+ + + + +
+ Minor changes made (shorted name of the matching mechanism: dynamic matching function -> dynamic matching, qualified function name), assigned to Axel for proofreading.
+
+TRI and TCI will be handled separately in its own CR 0007494.
+
+
+
+ + + + + + + + + + +
+ (0014188) +
+ Axel Rennoch    +
+ 19-08-2016 15:11    +
+ 		+ + + + +
+ modified (naming conventions, font corrections, additional comment in example) proposal can be used for the final draft
+
+ + diff --git a/docs/mantis/CR7175.md b/docs/mantis/CR7175.md new file mode 100644 index 0000000000000000000000000000000000000000..b87dd6bf66c8f960a5a80fa31b9f1c3d2ba7bb96 --- /dev/null +++ b/docs/mantis/CR7175.md @@ -0,0 +1,464 @@ + + + + + + + + + + + + + 0007175: No easy way to describe conjunction matching mechanism. - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Advanced Matching (ES 203 022)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007175Ext Pack: Advanced Matching (ES 203 022)New Featurepublic11-09-2015 12:2024-12-2016 12:45
ReporterJacob Wieland - Spirent 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv1.1.1 (published 2017-07)Fixed in Versionv1.1.1 (published 2017-07) 
Clause Reference(s)B.1.2
Source (company - Author)Testing Technologies - Jacob Wieland
TS version
Summary0007175: No easy way to describe conjunction matching mechanism.
DescriptionAt the moment, it is not possible to easily combine two existing matching mechanism into a conjunction, i.e. a matching mechanism which matches iff both matching mechanisms match.
+
+It is possible via the DeMorgan rules to write it like this:
+
+complement(complement(A), complement(B)) (not(not(A) or not(B)) == A and B) but that is a very clumsy way.
+
+Another way is to define a type restricted by A and then a subtype restricted by B and then use a ? of the resulting type as matching mechanism, but again, this is very complicated.
+
+Therefore, I propose to introduce a new matching mechanism that does this directly, i.e.
+
+and(A1, ..., An)
+
+Since the keyword 'and' normally can only appear in infix position, I don't see any grammatical ambiguities arising from this.
Steps To Reproduce
Additional Information
Tagstechnically agreed
Relationships
related to 0007174closed Jens Grabowski New matching mechanism: matching by function 
related to 0007494closed Jens Grabowski TRI and TCI extensions for advanced matching 
Attached Filespptx Additional-logical-operators-Ideas-160722.pptx (35,785) 22-07-2016 13:37
http://oldforge.etsi.org/mantis/file_download.php?file_id=3436&type=bug
docx CR7175-1.docx (176,072) 19-08-2016 15:42
http://oldforge.etsi.org/mantis/file_download.php?file_id=3506&type=bug
docx CR7175-2.docx (184,372) 15-11-2016 13:17
http://oldforge.etsi.org/mantis/file_download.php?file_id=3520&type=bug
docx CR7175-3.docx (180,865) 15-11-2016 14:25
http://oldforge.etsi.org/mantis/file_download.php?file_id=3522&type=bug
docx CR7175-4.docx (164,193) 16-11-2016 13:20
http://oldforge.etsi.org/mantis/file_download.php?file_id=3534&type=bug
docx CR7175-5.docx (167,187) 16-11-2016 14:36
http://oldforge.etsi.org/mantis/file_download.php?file_id=3538&type=bug
docx CR7175-6.docx (167,029) 16-11-2016 16:53
http://oldforge.etsi.org/mantis/file_download.php?file_id=3545&type=bug
docx CR7175-7.docx (194,695) 17-11-2016 08:58
http://oldforge.etsi.org/mantis/file_download.php?file_id=3546&type=bug
docx CR7175-8.docx (167,605) 17-11-2016 10:57
http://oldforge.etsi.org/mantis/file_download.php?file_id=3550&type=bug
Issue History
Date ModifiedUsernameFieldChange
11-09-2015 12:20Jacob Wieland - SpirentNew Issue
21-09-2015 09:45Gyorgy RethyProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
21-09-2015 10:07Gyorgy RethyRelationship addedrelated to 0007174
21-09-2015 10:25Gyorgy RethyProduct Version => v4.7.1 (published 2015-06)
21-09-2015 10:25Gyorgy RethyTarget Version => v4.8.1 (ongoing)
22-09-2015 11:42Gyorgy RethyNote Added: 0013238
22-09-2015 13:15Gyorgy RethyTag Attached: technically agreed
22-09-2015 13:19Gyorgy RethyNote Added: 0013239
03-11-2015 12:00Gyorgy RethyNote Added: 0013467
03-11-2015 12:00Gyorgy RethyTarget Versionv4.8.1 (ongoing) => Next version (to be defined)
05-11-2015 11:01Gyorgy RethyProjectPart 01: TTCN-3 Core Language => Ext Pack: Advanced Matching (ES 203 022)
05-11-2015 11:08Gyorgy RethyProduct Versionv4.7.1 (published 2015-06) =>
05-11-2015 11:08Gyorgy RethyTarget VersionNext version (to be defined) => v1.1.1 (published 2017-07)
18-07-2016 11:23Jens GrabowskiAssigned To => Jens Grabowski
18-07-2016 11:23Jens GrabowskiStatusnew => assigned
22-07-2016 13:37Jens GrabowskiFile Added: Additional-logical-operators-Ideas-160722.pptx
15-08-2016 13:12Jens GrabowskiAssigned ToJens Grabowski => Tomas Urban
19-08-2016 09:59Jens GrabowskiNote Added: 0014171
19-08-2016 15:42Tomas UrbanFile Added: CR7175-1.docx
19-08-2016 15:43Tomas UrbanNote Added: 0014192
15-11-2016 13:17Tomas UrbanFile Added: CR7175-2.docx
15-11-2016 13:18Tomas UrbanAssigned ToTomas Urban => Jacob Wieland - Spirent
15-11-2016 13:19Tomas UrbanNote Added: 0014249
15-11-2016 13:19Tomas UrbanStatusassigned => confirmed
15-11-2016 14:25Tomas UrbanFile Added: CR7175-3.docx
16-11-2016 13:19Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent =>
16-11-2016 13:19Jacob Wieland - SpirentAssigned To => Jacob Wieland - Spirent
16-11-2016 13:19Jacob Wieland - SpirentStatusconfirmed => assigned
16-11-2016 13:20Jacob Wieland - SpirentFile Added: CR7175-4.docx
16-11-2016 13:23Jacob Wieland - SpirentNote Added: 0014266
16-11-2016 13:23Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Axel Rennoch
16-11-2016 13:23Jacob Wieland - SpirentStatusassigned => confirmed
16-11-2016 14:36Axel RennochFile Added: CR7175-5.docx
16-11-2016 14:37Axel RennochNote Added: 0014270
16-11-2016 14:38Axel RennochAssigned ToAxel Rennoch => Kristóf Szabados
16-11-2016 14:38Axel RennochStatusconfirmed => assigned
16-11-2016 14:38Axel RennochNote Added: 0014271
16-11-2016 14:38Axel RennochStatusassigned => confirmed
16-11-2016 14:39Tomas UrbanRelationship addedrelated to 0007494
16-11-2016 16:53Kristóf SzabadosFile Added: CR7175-6.docx
16-11-2016 16:53Kristóf SzabadosNote Added: 0014282
16-11-2016 16:54Kristóf SzabadosNote Added: 0014283
16-11-2016 16:55Kristóf SzabadosAssigned ToKristóf Szabados => Tomas Urban
16-11-2016 16:55Kristóf SzabadosStatusconfirmed => assigned
17-11-2016 08:58Tomas UrbanFile Added: CR7175-7.docx
17-11-2016 09:00Tomas UrbanNote Added: 0014287
17-11-2016 09:00Tomas UrbanAssigned ToTomas Urban => Jens Grabowski
17-11-2016 09:00Tomas UrbanStatusassigned => confirmed
17-11-2016 10:57Jens GrabowskiFile Added: CR7175-8.docx
17-11-2016 10:57Jens GrabowskiStatusconfirmed => resolved
17-11-2016 10:57Jens GrabowskiResolutionopen => fixed
24-12-2016 12:44Jens GrabowskiStatusresolved => closed
24-12-2016 12:45Jens GrabowskiFixed in Version => v1.1.1 (published 2017-07)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0013238) +
+ Gyorgy Rethy    +
+ 22-09-2015 11:42    +
+ 		+ + + + +
+ STF discussion: candidate for a new advanced matching mechanisms package.
+
+
+
+ + + + + + + + + + +
+ (0013239) +
+ Gyorgy Rethy    +
+ 22-09-2015 13:19    +
+ 		+ + + + +
+ STF discussion: useful extension of matching mechanisms. It need be studied, which operations could work with which matching mechanisms. Logical operations and set operations are the first obvious candidates. Candidate for the new advanced matching package proposed to MTS.
+
+
+
+ + + + + + + + + + +
+ (0013467) +
+ Gyorgy Rethy    +
+ 03-11-2015 12:00    +
+ 		+ + + + +
+ To be part of the new extension on advanced matching mechanisms.
+
+
+
+ + + + + + + + + + +
+ (0014171) +
+ Jens Grabowski    +
+ 19-08-2016 09:59    +
+ 		+ + + + +
+ STF discussion:
+
+- conjunction, keyword: conjunct(T1,T2,...)
+
+
+- implication, infix notation, keyword implies: T1 implies T2
+
+- substraction, infix notation, keyword without: T1 without T2
+
+(Repetition of sub-sequences inside values see CR 7167)
+
+- Inside-Values Disjunction: analogous to conjunction, keyword: disjunct
+
+
+
+ + + + + + + + + + +
+ (0014192) +
+ Tomas Urban    +
+ 19-08-2016 15:43    +
+ 		+ + + + +
+ Partial draft attached (containing conjuction, implication and exclusion). To be contiued in the next SFT session.
+
+
+
+ + + + + + + + + + +
+ (0014249) +
+ Tomas Urban    +
+ 15-11-2016 13:19    +
+ 		+ + + + +
+ Proposal uploaded, please review.
+
+
+
+ + + + + + + + + + +
+ (0014266) +
+ Jacob Wieland - Spirent    +
+ 16-11-2016 13:23    +
+ 		+ + + + +
+ please review for understandability
+
+
+
+ + + + + + + + + + +
+ (0014270) +
+ Axel Rennoch    +
+ 16-11-2016 14:37    +
+ 		+ + + + +
+ some minor corrections
+BNF has been checked together with BNF from the core
+
+
+
+ + + + + + + + + + +
+ (0014271) +
+ Axel Rennoch    +
+ 16-11-2016 14:38    +
+ 		+ + + + +
+ please do your check and forward to Jens
+
+
+
+ + + + + + + + + + +
+ (0014282) +
+ Kristóf Szabados    +
+ 16-11-2016 16:53    +
+ 		+ + + + +
+ Added an example for usage of all from.
+Please check.
+
+
+
+ + + + + + + + + + +
+ (0014283) +
+ Kristóf Szabados    +
+ 16-11-2016 16:54    +
+ 		+ + + + +
+ also hopefully simplified restriction e in section 4.2
+
+
+
+ + + + + + + + + + +
+ (0014287) +
+ Tomas Urban    +
+ 17-11-2016 09:00    +
+ 		+ + + + +
+ One modification made: "and all other required conditions are met" added to 4.5 restriction g.
+
+Please check and mark as resolved if acceptable.
+
+ + diff --git a/docs/mantis/CR7179.md b/docs/mantis/CR7179.md new file mode 100644 index 0000000000000000000000000000000000000000..f57533cbcf0689d5e9d19280d5a34057a8746794 --- /dev/null +++ b/docs/mantis/CR7179.md @@ -0,0 +1,277 @@ + + + + + + + + + + + + + 0007179: Minor issues with restriction on address references in receive operations - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007179Part 01: TTCN-3 Core LanguageClarificationpublic17-09-2015 08:0214-12-2015 13:56
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.7.1 (published 2015-06) 
Target Versionv4.8.1 (published 2016-07)Fixed in Versionv4.8.1 (published 2016-07) 
Clause Reference(s)22.2.2
Source (company - Author)STF 487
Summary0007179: Minor issues with restriction on address references in receive operations
DescriptionThe restriction 22.2.2.f states that: "AddressRef for retrieving the sending entity shall be of type address, component or of the type provided in the address declaration of the port type of the port instance referenced in the receive operation. No AddressRef shall contain the special value null at the time of the operation."
+
+There are several problems with this restriction:
+
+1. The term "AddressRef" used in the first sentence is only partially correct. The syntactical description uses the term "VariableRef" for sender redirect assignment and the same term shall be used in the restriction f. The sentence should start this way: "All AddressRef items in the from clause and all VariableRef items in the sender clause shall be of type..."
+
+2. The term "type provided in the address declaration of the port type" is ambiguous. Assuming the address type of the port type PortType is declared as "address integer", the rule requires that reference shall be of an integer type and cannot be of the PortType.address type. This rule is inconsistent with the one used for the global address type (type used to create the global address type cannot be referenced in the sender and from clauses). The specification unfortunately uses both types of references in examples (see example 2 and 3 in the section 6.2.12).
+
+Proposal: Change the term to "address type bound to the port" (see the chapter 6.2.9) and disallow usage of the base type. Update the examples in 6.2.12 accordingly.
+
+3. The sentence "No AddressRef shall contain the special value null at the time of the operation." should contain an explicit reference to the from clause. The rule shall start this way "No AddressRef in the from clause..."
Steps To Reproduce
Additional Information
Tagstechnically agreed
Relationships
Attached Filesdocx CR7179_resolution_v1.docx (95,541) 15-10-2015 10:28
http://oldforge.etsi.org/mantis/file_download.php?file_id=3310&type=bug
docx CR7179_resolution_v2.docx (159,549) 15-10-2015 14:26
http://oldforge.etsi.org/mantis/file_download.php?file_id=3323&type=bug
docx CR7179_resolution_v3.docx (155,627) 15-10-2015 14:39
http://oldforge.etsi.org/mantis/file_download.php?file_id=3324&type=bug
Issue History
Date ModifiedUsernameFieldChange
17-09-2015 08:02Tomas UrbanNew Issue
21-09-2015 10:24Gyorgy RethyTarget Version => v4.8.1 (published 2016-07)
22-09-2015 13:21Gyorgy RethyTag Attached: technically agreed
22-09-2015 13:23Gyorgy RethyNote Added: 0013240
13-10-2015 15:48Axel RennochAssigned To => Axel Rennoch
13-10-2015 15:48Axel RennochStatusnew => assigned
15-10-2015 10:28Axel RennochFile Added: CR7179_resolution_v1.docx
15-10-2015 10:30Axel RennochNote Added: 0013391
15-10-2015 10:33Axel RennochNote Added: 0013392
15-10-2015 10:33Axel RennochAssigned ToAxel Rennoch => Jacob Wieland - Spirent
15-10-2015 10:33Axel RennochStatusassigned => acknowledged
15-10-2015 12:11Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Axel Rennoch
15-10-2015 12:11Jacob Wieland - SpirentStatusacknowledged => assigned
15-10-2015 12:12Jacob Wieland - SpirentNote Added: 0013397
15-10-2015 14:26Axel RennochFile Added: CR7179_resolution_v2.docx
15-10-2015 14:28Axel RennochNote Added: 0013414
15-10-2015 14:28Axel RennochAssigned ToAxel Rennoch => Jacob Wieland - Spirent
15-10-2015 14:28Axel RennochStatusassigned => acknowledged
15-10-2015 14:39Jacob Wieland - SpirentFile Added: CR7179_resolution_v3.docx
15-10-2015 14:40Jacob Wieland - SpirentNote Added: 0013417
15-10-2015 14:40Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
15-10-2015 14:40Jacob Wieland - SpirentStatusacknowledged => confirmed
03-11-2015 09:09Gyorgy RethyStatusconfirmed => resolved
03-11-2015 09:09Gyorgy RethyFixed in Version => v4.8.1 (published 2016-07)
03-11-2015 09:09Gyorgy RethyResolutionopen => fixed
14-12-2015 13:56Gyorgy RethyNote Added: 0013621
14-12-2015 13:56Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0013240) +
+ Gyorgy Rethy    +
+ 22-09-2015 13:23    +
+ 		+ + + + +
+ STF discussion: textual description to be aligned with the syntactical structure part. Also, check the relation of global address type with the port-specific address type.
+
+
+
+ + + + + + + + + + +
+ (0013391) +
+ Axel Rennoch    +
+ 15-10-2015 10:30    +
+ 		+ + + + +
+ Proposed text and updated examples in uploaded file resolution_v1.
+
+
+
+ + + + + + + + + + +
+ (0013392) +
+ Axel Rennoch    +
+ 15-10-2015 10:33    +
+ 		+ + + + +
+ Please have a look to the proposed changes.
+
+
+
+ + + + + + + + + + +
+ (0013397) +
+ Jacob Wieland - Spirent    +
+ 15-10-2015 12:12    +
+ 		+ + + + +
+ proposed change is fine, but needs to be repeated for all communication operations (send, call, reply, raise, trigger, getcall, getreply, catch and check)
+
+
+
+ + + + + + + + + + +
+ (0013414) +
+ Axel Rennoch    +
+ 15-10-2015 14:28    +
+ 		+ + + + +
+ Resolution v2 now covers all communicatoin ops, please confirm.
+
+
+
+ + + + + + + + + + +
+ (0013417) +
+ Jacob Wieland - Spirent    +
+ 15-10-2015 14:40    +
+ 		+ + + + +
+ changed cp. to see to be consistent with the rest of the standard. otherwise ok.
+
+
+
+ + + + + + + + + + +
+ (0013621) +
+ Gyorgy Rethy    +
+ 14-12-2015 13:56    +
+ 		+ + + + +
+ Added to draft V4.7.4
+
+ + diff --git a/docs/mantis/CR7180.md b/docs/mantis/CR7180.md new file mode 100644 index 0000000000000000000000000000000000000000..7ed7717b3c07a4784dea7f3936ae61eeabb5b0f8 --- /dev/null +++ b/docs/mantis/CR7180.md @@ -0,0 +1,318 @@ + + + + + + + + + + + + + 0007180: Implicit from clause - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007180Part 01: TTCN-3 Core LanguageTechnicalpublic17-09-2015 10:3914-12-2015 14:58
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.7.1 (published 2015-06) 
Target Versionv4.8.1 (published 2016-07)Fixed in Versionv4.8.1 (published 2016-07) 
Clause Reference(s)22.2.2
Source (company - Author)STF 487
Summary0007180: Implicit from clause
DescriptionThe current rules state that an error is produced when there's a mismatch between a target variable of a sender redirect assignment and the real sender (see e.g. the restriction 22.2.2.e.)
+
+However, this situation can only happen in case the receiving statement contains no from clause or the from clause contains the all component construct. In my opinion, it would be more consistent with the general principles of alt statement evaluation if this situation produced just a mismatch, because the sender clause actually implicitly specifies the required type of the sender.
+
+Thus:
+var address v_sender;
+p.receive -> sender v_sender
+
+could be interpreted as:
+p.receive from address:? -> sender v_sender
+
+For that reason, I propose the following rule to be added to the section 22.2.2:
+In case the receive statement contains a sender clause and the from clause is either missing or contains the any component notation, an implicit from clause is used instead, containing an AnyValue template of the same type as the variable referenced in the sender clause.
+
+If accepted, a similar rule should be added to all remaining receiving statements (trigger, getcall, getreply, catch and check).
Steps To Reproduce
Additional Information
Tagstechnically agreed
Relationships
Attached Filesdocx CR7180_resolution_A_v1.docx (208,149) 13-10-2015 13:14
http://oldforge.etsi.org/mantis/file_download.php?file_id=3301&type=bug
docx CR7180_resolution_B_v1.docx (198,389) 13-10-2015 13:14
http://oldforge.etsi.org/mantis/file_download.php?file_id=3302&type=bug
docx CR7180_resolution_A_v2.docx (200,645) 14-10-2015 15:28
http://oldforge.etsi.org/mantis/file_download.php?file_id=3308&type=bug
docx CR7180_resolution_A_v3.docx (209,829) 15-10-2015 08:44
http://oldforge.etsi.org/mantis/file_download.php?file_id=3309&type=bug
docx CR7180_resolution_A_v4.docx (196,937) 02-11-2015 16:13
http://oldforge.etsi.org/mantis/file_download.php?file_id=3341&type=bug
Issue History
Date ModifiedUsernameFieldChange
17-09-2015 10:39Tomas UrbanNew Issue
21-09-2015 10:24Gyorgy RethyTarget Version => v4.8.1 (published 2016-07)
22-09-2015 13:34Gyorgy RethyTag Attached: technically agreed
22-09-2015 13:38Gyorgy RethyNote Added: 0013241
12-10-2015 17:02Axel RennochAssigned To => Axel Rennoch
12-10-2015 17:02Axel RennochStatusnew => assigned
13-10-2015 13:14Axel RennochFile Added: CR7180_resolution_A_v1.docx
13-10-2015 13:14Axel RennochFile Added: CR7180_resolution_B_v1.docx
13-10-2015 13:18Axel RennochNote Added: 0013370
14-10-2015 11:54Gyorgy RethyNote Added: 0013382
14-10-2015 15:28Axel RennochFile Added: CR7180_resolution_A_v2.docx
14-10-2015 15:39Axel RennochNote Added: 0013388
14-10-2015 15:40Axel RennochNote Added: 0013389
14-10-2015 15:40Axel RennochAssigned ToAxel Rennoch => Jacob Wieland - Spirent
14-10-2015 15:40Axel RennochStatusassigned => acknowledged
15-10-2015 08:44Jacob Wieland - SpirentFile Added: CR7180_resolution_A_v3.docx
15-10-2015 08:46Jacob Wieland - SpirentNote Added: 0013390
15-10-2015 08:46Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
15-10-2015 08:46Jacob Wieland - SpirentStatusacknowledged => confirmed
02-11-2015 16:13Gyorgy RethyFile Added: CR7180_resolution_A_v4.docx
02-11-2015 16:15Gyorgy RethyNote Added: 0013448
02-11-2015 16:15Gyorgy RethyStatusconfirmed => resolved
02-11-2015 16:15Gyorgy RethyFixed in Version => v4.8.1 (published 2016-07)
02-11-2015 16:15Gyorgy RethyResolutionopen => fixed
14-12-2015 14:58Gyorgy RethyNote Added: 0013623
14-12-2015 14:58Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0013241) +
+ Gyorgy Rethy    +
+ 22-09-2015 13:38    +
+ 		+ + + + +
+ STF discussion: Add a note to restriction e) describing what type mismatch in case of sender storing means. In general, rules applying to receiving operations in genera, like this one, should be moved to the genric clause of receiving ops. Check which rules could be moved to a common set of rules.
+
+
+
+ + + + + + + + + + +
+ (0013370) +
+ Axel Rennoch    +
+ 13-10-2015 13:18    +
+ 		+ + + + +
+ Resolution A_v1 adds the several notes to the related restrictions.
+Resolution B_v1 add one note only to 22.1.4.2
+
+
+
+ + + + + + + + + + +
+ (0013382) +
+ Gyorgy Rethy    +
+ 14-10-2015 11:54    +
+ 		+ + + + +
+ STF decision: if the from clause is missing, but the type of the sender can be determined, it shall be type compatible with the type of the variable.
+
+
+
+ + + + + + + + + + +
+ (0013388) +
+ Axel Rennoch    +
+ 14-10-2015 15:39    +
+ 		+ + + + +
+ New version 2 for resolution A that does not introduce "implicit from" clauses but provides details on type mismatch for all sections with receiving statements.
+
+
+
+ + + + + + + + + + +
+ (0013389) +
+ Axel Rennoch    +
+ 14-10-2015 15:40    +
+ 		+ + + + +
+ Please check CR7180_resolution_A_v2.docx
+
+
+
+ + + + + + + + + + +
+ (0013390) +
+ Jacob Wieland - Spirent    +
+ 15-10-2015 08:46    +
+ 		+ + + + +
+ because in the getcall, getreply, catch and check operations only the case where both a from and a sender clause is present was mentioned, I added another sentence for the case that a sender but no from clause is present.
+
+please review and resolve
+
+
+
+ + + + + + + + + + +
+ (0013448) +
+ Gyorgy Rethy    +
+ 02-11-2015 16:15    +
+ 		+ + + + +
+ CR7180_resolution_A_v4.docx: Little textual re-wording in clause 22.2.2 to eliminate "shall" from the note -> this text to be copied to the other clauses as well.
+
+
+
+ + + + + + + + + + +
+ (0013623) +
+ Gyorgy Rethy    +
+ 14-12-2015 14:58    +
+ 		+ + + + +
+ Added to draft V4.7.4
+
+ + diff --git a/docs/mantis/CR7183.md b/docs/mantis/CR7183.md new file mode 100644 index 0000000000000000000000000000000000000000..551f70a5231c6ec40d5f38764e7a948013b232fc --- /dev/null +++ b/docs/mantis/CR7183.md @@ -0,0 +1,133 @@ + + + + + + + + + + + + + 0007183: Return value not mentioned in the section describing @decoded clause of getreply - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007183Part 01: TTCN-3 Core LanguageEditorialpublic21-09-2015 10:4815-12-2015 09:38
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeveritytrivialReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.7.1 (published 2015-06) 
Target Versionv4.8.1 (published 2016-07)Fixed in Versionv4.8.1 (published 2016-07) 
Clause Reference(s)22.3.4
Source (company - Author)STF 487
Summary0007183: Return value not mentioned in the section describing @decoded clause of getreply
DescriptionThe section describing the rules for using the @decoded clause in the getreply statement currently mentions signature parameters, but not the return value (which is also syntactically possible).
+
+Proposal: add the return value to the description.
Steps To Reproduce
Additional Information
Tagstechnically agreed
Relationships
Attached Filesdocx CR7183.docx (175,436) 24-09-2015 15:03
http://oldforge.etsi.org/mantis/file_download.php?file_id=3282&type=bug
Issue History
Date ModifiedUsernameFieldChange
21-09-2015 10:48Tomas UrbanNew Issue
21-09-2015 16:42Gyorgy RethyTarget Version => v4.8.1 (published 2016-07)
22-09-2015 13:39Gyorgy RethyTag Attached: technically agreed
22-09-2015 13:39Gyorgy RethyNote Added: 0013242
24-09-2015 15:03Jacob Wieland - SpirentFile Added: CR7183.docx
24-09-2015 15:03Jacob Wieland - SpirentNote Added: 0013295
24-09-2015 15:03Jacob Wieland - SpirentAssigned To => Gyorgy Rethy
24-09-2015 15:03Jacob Wieland - SpirentStatusnew => confirmed
02-11-2015 08:58Gyorgy RethyStatusconfirmed => resolved
02-11-2015 08:58Gyorgy RethyFixed in Version => v4.8.1 (published 2016-07)
02-11-2015 08:58Gyorgy RethyResolutionopen => fixed
15-12-2015 09:38Gyorgy RethyNote Added: 0013629
15-12-2015 09:38Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0013242) +
+ Gyorgy Rethy    +
+ 22-09-2015 13:39    +
+ 		+ + + + +
+ STF discussion: check and correct if needed.
+
+
+
+ + + + + + + + + + +
+ (0013295) +
+ Jacob Wieland - Spirent    +
+ 24-09-2015 15:03    +
+ 		+ + + + +
+ added proposal, please review and resolve
+
+
+
+ + + + + + + + + + +
+ (0013629) +
+ Gyorgy Rethy    +
+ 15-12-2015 09:38    +
+ 		+ + + + +
+ Added to draft V4.7.4
+
+ + diff --git a/docs/mantis/CR7184.md b/docs/mantis/CR7184.md new file mode 100644 index 0000000000000000000000000000000000000000..2d38f21bbb172bf21d4a43ce0d87aaf78838d9c0 --- /dev/null +++ b/docs/mantis/CR7184.md @@ -0,0 +1,169 @@ + + + + + + + + + + + + + 0007184: Template instance in the value part of reply operations - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007184Part 01: TTCN-3 Core LanguageTechnicalpublic21-09-2015 13:0511-12-2015 14:48
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.7.1 (published 2015-06) 
Target Versionv4.8.1 (published 2016-07)Fixed in Versionv4.8.1 (published 2016-07) 
Clause Reference(s)22.2.3
Source (company - Author)STF 487
Summary0007184: Template instance in the value part of reply operations
DescriptionThe current specification allows only expressions in the value part of the reply operations. This is inconsistent with all remaining "sending" operations which allow template instances as their parameters. It also means that inline templates are syntactically incorrect in the value clause.
+
+Proposal:
+Change the syntactical description of 22.3.3 and the BNF rule 323 replacing "Expression" with "TemplateInstance"
+Add a restriction to the section 22.3.3 saying that the template in the value clause shall resolve to a completely initialized specific value
Steps To Reproduce
Additional Information
Tagstechnically agreed
Relationships
related to 0007140closed Gyorgy Rethy Templates not allowed in the value part of the reply operation 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
21-09-2015 13:05Tomas UrbanNew Issue
21-09-2015 13:07Tomas UrbanNote Added: 0013202
21-09-2015 16:42Gyorgy RethyTarget Version => v4.8.1 (published 2016-07)
22-09-2015 13:40Gyorgy RethyTag Attached: technically agreed
22-09-2015 13:41Gyorgy RethyNote Added: 0013243
22-09-2015 13:41Gyorgy RethyAssigned To => Gyorgy Rethy
22-09-2015 13:41Gyorgy RethyStatusnew => assigned
15-10-2015 13:13Jacob Wieland - SpirentRelationship addedrelated to 0007140
15-10-2015 13:13Jacob Wieland - SpirentNote Added: 0013406
15-10-2015 13:13Jacob Wieland - SpirentStatusassigned => resolved
15-10-2015 13:13Jacob Wieland - SpirentResolutionopen => fixed
04-11-2015 14:03Gyorgy RethyFixed in Version => v4.8.1 (published 2016-07)
11-12-2015 14:48Gyorgy RethyNote Added: 0013593
11-12-2015 14:48Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0013202) +
+ Tomas Urban    +
+ 21-09-2015 13:07    +
+ 		+ + + + +
+ Please remove the CR as duplicate. The issue has been already sumbitted in 0007140
+
+
+
+ + + + + + + + + + +
+ (0013243) +
+ Gyorgy Rethy    +
+ 22-09-2015 13:41    +
+ 		+ + + + +
+ STF discussion: should be template(value). Correct it.
+
+
+
+ + + + + + + + + + +
+ (0013406) +
+ Jacob Wieland - Spirent    +
+ 15-10-2015 13:13    +
+ 		+ + + + +
+ resolved in 7140
+
+
+
+ + + + + + + + + + +
+ (0013593) +
+ Gyorgy Rethy    +
+ 11-12-2015 14:48    +
+ 		+ + + + +
+ Resolved in CR 7140
+
+ + diff --git a/docs/mantis/CR7185.md b/docs/mantis/CR7185.md new file mode 100644 index 0000000000000000000000000000000000000000..bb4a8f15050eb98c2336941f9fd43fbaca6830a8 --- /dev/null +++ b/docs/mantis/CR7185.md @@ -0,0 +1,109 @@ + + + + + + + + + + + + + 0007185: BNF productions TemplateInstance vs. InLineTemplate - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007185Part 01: TTCN-3 Core LanguageClarificationpublic23-09-2015 11:3805-01-2016 15:59
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PriorityurgentSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.8.1 (published 2016-07)Fixed in Versionv4.8.1 (published 2016-07) 
Clause Reference(s)all part-1
Source (company - Author)L.M.Ericsson
Summary0007185: BNF productions TemplateInstance vs. InLineTemplate
DescriptionUp to version V4.2.1 a TemplateInstance production existed in the BNF:
+150. TemplateInstance ::= InLineTemplate
+
+It was used in the text to explain the syntactical structures of the language for the users .
+
+As it was a simple name alies to InLineTemplate, this production was removed from the BNF during the BNF simplification; but it is used further on in the textual desrcriptions in Part-1 and in 3 static semantic rules! as well.
+
+Therefore the name to identify template instances shall be unified.
+It is proposed to use TemplateInstance for the following reasons:
+- this change will effect the BNF only that is primarily used by tooling expers, i.e. less audience is effected
+- the language defines in-line templates in clause 15.4, that is only a subset of all possible template instances. Therefore using the name "InLineTemplate" in ALL syntactical structures, when referring to template instances would be highly misleading for the users.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0007134closed Gyorgy Rethy Syntactical structure of the select branch shall contain TemplateInstance 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
23-09-2015 11:38Gyorgy RethyNew Issue
23-09-2015 11:39Gyorgy RethyRelationship addedrelated to 0007134
23-09-2015 14:39Jacob Wieland - SpirentNote Added: 0013269
23-09-2015 16:47Gyorgy RethyNote Added: 0013279
23-09-2015 16:47Gyorgy RethyStatusnew => resolved
23-09-2015 16:47Gyorgy RethyFixed in Version => v4.8.1 (published 2016-07)
23-09-2015 16:47Gyorgy RethyResolutionopen => fixed
23-09-2015 16:47Gyorgy RethyAssigned To => Gyorgy Rethy
24-09-2015 16:41Gyorgy RethyTarget Version => v4.8.1 (published 2016-07)
21-12-2015 08:13Gyorgy RethyNote Edited: 0013279bug_revision_view_page.php?bugnote_id=13279#r257
05-01-2016 15:59Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0013269) +
+ Jacob Wieland - Spirent    +
+ 23-09-2015 14:39    +
+ 		+ + + + +
+ agreed
+
+
+
+ + + + + + + + + + +
+ (0013279) +
+ Gyorgy Rethy    +
+ 23-09-2015 16:47    +
(edited on: 21-12-2015 08:13)
+ 		+ + + + +
+ Implemented in draft version 4.7.4. The CR is not closed to remind re-checking the final draft before submitting to MTS approval.
+
+
+
+ + diff --git a/docs/mantis/CR7186.md b/docs/mantis/CR7186.md new file mode 100644 index 0000000000000000000000000000000000000000..245f92347590dd7f112d0a66e2456dc277528f80 --- /dev/null +++ b/docs/mantis/CR7186.md @@ -0,0 +1,148 @@ + + + + + + + + + + + + + 0007186: Simplify BNF of the return statement - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007186Part 01: TTCN-3 Core LanguageClarificationpublic25-09-2015 11:4811-12-2015 15:57
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.7.1 (published 2015-06) 
Target Versionv4.8.1 (published 2016-07)Fixed in Versionv4.8.1 (published 2016-07) 
Clause Reference(s)19.10 and Annex A
Source (company - Author)L.M.Ericsson
Summary0007186: Simplify BNF of the return statement
DescriptionThe return statement's syntax is defined as:
+(clause 19.10)
+Syntactical Structure
+return [ Expression | TemplateInstance ]
+
+and in the BNF as
+481.ReturnStatement ::= ReturnKeyword [Expression | TemplateInstance]
+
+As TemplateInstance allows the syntax provided by Exprsession, it could be simplified to:
+
+Syntactical Structure
+return [ TemplateInstance ]
+
+and
+481.ReturnStatement ::= ReturnKeyword [TemplateInstance]
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
25-09-2015 11:48Gyorgy RethyNew Issue
25-09-2015 11:51Gyorgy RethyNote Added: 0013306
25-09-2015 11:51Gyorgy RethyAssigned To => Jacob Wieland - Spirent
25-09-2015 11:51Gyorgy RethyStatusnew => assigned
25-09-2015 12:39Jacob Wieland - SpirentNote Added: 0013308
25-09-2015 12:43Jacob Wieland - SpirentStatusassigned => resolved
25-09-2015 12:43Jacob Wieland - SpirentFixed in Version => v4.8.1 (published 2016-07)
25-09-2015 12:43Jacob Wieland - SpirentResolutionopen => fixed
25-09-2015 12:43Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
11-12-2015 15:57Gyorgy RethyNote Added: 0013603
11-12-2015 15:57Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0013306) +
+ Gyorgy Rethy    +
+ 25-09-2015 11:51    +
+ 		+ + + + +
+ Please cross-check.
+
+
+
+ + + + + + + + + + +
+ (0013308) +
+ Jacob Wieland - Spirent    +
+ 25-09-2015 12:39    +
+ 		+ + + + +
+ Agreed.
+
+For the rule of Assignment, Expression | TemplateBody is used which can also be simplified to TemplateBody
+
+
+
+ + + + + + + + + + +
+ (0013603) +
+ Gyorgy Rethy    +
+ 11-12-2015 15:57    +
+ 		+ + + + +
+ Added to draft V4.7.4
+
+ + diff --git a/docs/mantis/CR7187.md b/docs/mantis/CR7187.md new file mode 100644 index 0000000000000000000000000000000000000000..2554313ae6e99660ae97c3ef6bb056cd15a4e6a9 --- /dev/null +++ b/docs/mantis/CR7187.md @@ -0,0 +1,527 @@ + + + + + + + + + + + + + 0007187: Allow null-value for all value variables with the same semantics as uninitialized. - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Object-oriented features (ES 203 790)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007187Ext Pack: Object-oriented features (ES 203 790)[All Projects] Generalpublic01-10-2015 10:3311-10-2018 14:20
ReporterJacob Wieland - Spirent 
Assigned ToJacob Wieland - Spirent 
PrioritynormalSeveritymajorReproducibilityhave not tried
StatusclosedResolutionwon't fix 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0007187: Allow null-value for all value variables with the same semantics as uninitialized.
DescriptionThere are numerous (non-conform) test suites in existence that use the null value for data types like for component types, i.e. for checking whether a variable has been initialized (v == null) and for even explicitly uninitializing it after it already has been initialized.
+
+Enforcing the standard-conform null-semantics in a tool (restricting it so it can only be used for component, default and address types) makes all these test suites not usable in these tools. Test suite maintainers do not want to spend the effort of rewriting their (sometimes very large) test suite to use isbound() for null checks and adding workarounds for modelling null-values (like adding additional variants to union types or wrapping in single-optional-field-record types) in another way. The newer tools thus have a lower acceptance than their older non-standard-conform versions, even if they offer workarounds.
+
+Therefore, I think it should be allowed to use null as a special value that can be assigned to data-type variables and can be checked against in the same way as for component, default and address types (with the same semantics as for these). NOTES that maybe this is a bad practice could be added to the sections in question.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7187.docx (536,463) 05-11-2015 14:03
http://oldforge.etsi.org/mantis/file_download.php?file_id=3367&type=bug
docx CR7187v3.docx (276,073) 21-07-2016 11:22
http://oldforge.etsi.org/mantis/file_download.php?file_id=3430&type=bug
Issue History
Date ModifiedUsernameFieldChange
01-10-2015 10:33Jacob Wieland - SpirentNew Issue
04-11-2015 13:59Gyorgy RethyProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
04-11-2015 21:49Jacob Wieland - SpirentNote Added: 0013497
05-11-2015 09:16Jacob Wieland - SpirentAssigned To => Jacob Wieland - Spirent
05-11-2015 09:16Jacob Wieland - SpirentStatusnew => assigned
05-11-2015 14:03Jacob Wieland - SpirentFile Added: CR7187.docx
05-11-2015 14:13Jacob Wieland - SpirentNote Added: 0013502
05-11-2015 14:14Jacob Wieland - SpirentNote Added: 0013503
05-11-2015 14:14Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Jens Grabowski
05-11-2015 14:14Jacob Wieland - SpirentStatusassigned => confirmed
05-11-2015 15:11Gyorgy RethyNote Added: 0013504
05-11-2015 15:59Jacob Wieland - SpirentNote Added: 0013509
11-12-2015 15:58Gyorgy RethyProduct Version => v4.8.1 (published 2016-07)
11-12-2015 15:58Gyorgy RethyTarget Version => v4.9.1(ongoing)
11-12-2015 15:59Gyorgy RethyStatusconfirmed => assigned
11-12-2015 16:01Gyorgy RethyNote Added: 0013604
20-07-2016 13:39Jens GrabowskiNote Added: 0014007
20-07-2016 13:39Jens GrabowskiAssigned ToJens Grabowski => Jacob Wieland - Spirent
21-07-2016 11:22Jacob Wieland - SpirentFile Added: CR7187v3.docx
21-07-2016 11:22Jacob Wieland - SpirentNote Added: 0014027
21-07-2016 11:22Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Tomas Urban
21-07-2016 11:22Jacob Wieland - SpirentStatusassigned => confirmed
21-07-2016 15:20Tomas UrbanNote Added: 0014031
21-07-2016 15:21Tomas UrbanNote Edited: 0014031bug_revision_view_page.php?bugnote_id=14031#r308
21-07-2016 15:21Tomas UrbanNote Edited: 0014031bug_revision_view_page.php?bugnote_id=14031#r309
21-07-2016 15:22Tomas UrbanNote Edited: 0014031bug_revision_view_page.php?bugnote_id=14031#r310
21-07-2016 15:23Tomas UrbanAssigned ToTomas Urban => Jacob Wieland - Spirent
21-07-2016 15:23Tomas UrbanStatusconfirmed => assigned
17-08-2016 16:13Jacob Wieland - SpirentNote Added: 0014136
17-11-2016 13:55Jens GrabowskiNote Added: 0014307
17-11-2016 13:55Jens GrabowskiTarget Versionv4.9.1(ongoing) => Next version (to be defined)
04-09-2017 09:18Jens GrabowskiProjectPart 01: TTCN-3 Core Language => Ext Pack: Object-oriented features (ES 203 790)
04-09-2017 09:18Jens GrabowskiCategoryNew Feature => General
11-10-2018 11:57Jacob Wieland - SpirentNote Added: 0015253
11-10-2018 14:20Kristóf SzabadosNote Added: 0015255
11-10-2018 14:20Kristóf SzabadosStatusassigned => closed
11-10-2018 14:20Kristóf SzabadosResolutionopen => won't fix
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0013497) +
+ Jacob Wieland - Spirent    +
+ 04-11-2015 21:49    +
+ 		+ + + + +
+ Maybe this could be allowed with a modifier for variables/formal parameters/constants/module parameters:
+
+var integer @nullable v := null;
+
+This would clearly mark it as a property of the variable (not the content), similar to optional and omit (where omit also is not the content of the field, but a property of the field)
+
+Use of null for assignment and comparison would be allowed only for nullable entities.
+
+isvalue and ispresent should still be false when called for these and all operations except comparison with a null-object should cause an error.
+
+
+
+ + + + + + + + + + +
+ (0013502) +
+ Jacob Wieland - Spirent    +
+ 05-11-2015 14:13    +
+ 		+ + + + +
+ I have added a proposal that generalizes the already existing null-concept for component, default and address types to a concept named "nullable" where each variable, formal parameter and return clause can be declared nullable by adding a @nullable modifier.
+component, default and address types are always nullable, otherwise, a data object is only nullable, if it is declared with this modifier.
+
+nullable objects can contain the special value null (i.e. they can be initialized with it and can be compared for equality/inequality with it).
+
+As for the already existing nullable types, all nullable objects which are initialized with null are considered bound and concrete value (i.e. isbound and isvalue return true).
+
+With the proposal, no fields or elements of structured values can be nullable (except for those who are automatically nullable). It would allow easily augmenting the existing use-cases for such null-assignment/checks.
+
+For future consideration:
+- default implicit/explicit nullable attribute (similar to optional attribute) to allow all variable/parameters/return types implicitly to be declared as nullable.
+- nullable modifier for type definitions
+- nullable modifier for field declarations
+- nullable modifier for record of element types
+
+
+
+ + + + + + + + + + +
+ (0013503) +
+ Jacob Wieland - Spirent    +
+ 05-11-2015 14:14    +
+ 		+ + + + +
+ please review
+
+
+
+ + + + + + + + + + +
+ (0013504) +
+ Gyorgy Rethy    +
+ 05-11-2015 15:11    +
+ 		+ + + + +
+ I can't remember any conclusion from the discussion yesterday. I think a proposal is yet premature.
+
+
+
+ + + + + + + + + + +
+ (0013509) +
+ Jacob Wieland - Spirent    +
+ 05-11-2015 15:59    +
+ 		+ + + + +
+ no, but I didn't think a proposal would hurt and the matter is too important to be shifted due to lack of proposal, so I added it as further base of discussion
+
+
+
+ + + + + + + + + + +
+ (0013604) +
+ Gyorgy Rethy    +
+ 11-12-2015 16:01    +
+ 		+ + + + +
+ I mean there was no agreement, if this is something we really want in the language.
+
+
+
+ + + + + + + + + + +
+ (0014007) +
+ Jens Grabowski    +
+ 20-07-2016 13:39    +
+ 		+ + + + +
+ STF agreement: Proposal accepted. Jacob will add a few examples and assign it back to Tomas for final proofreading.
+
+
+
+ + + + + + + + + + +
+ (0014027) +
+ Jacob Wieland - Spirent    +
+ 21-07-2016 11:22    +
+ 		+ + + + +
+ please review and resolve
+
+
+
+ + + + + + + + + + +
+ (0014031) +
+ Tomas Urban    +
+ 21-07-2016 15:20    +
(edited on: 21-07-2016 15:22)
+ 		+ + + + +
+ Result of STF discussion:
+
+TTCN-3 should be brought closer to programming languages such as Java or C#. That means the following changes:
+
+1. All types with exception of four primitive types (integer, float, boolean, verdicttype) and one constructive type (enumerated) shall be nullable, i.e. in addition to the current set of values, they will contain the specific value null. Exclusion is made for performance reason.
+
+2. For the mentioned excluded types, a nullable alternative can be explicitly made nullable using the @nullable modifier if needed:
+
+type integer @nullable NullableInt;
+
+3. Values, field and templates of nullable types that don't have any value explicitly assigned to them are implicitly initialized with the null value. This is actually not different from the current situation - the null value is just a different name for the uninitialized state which will completely disappear for the nullable types. Only three types that are currently nullable (component, address, default) will behave differently, because null and uninitialized are distinct at the moment.
+
+4. The isbound, ispresent, isvalue will yield false for the null value.
+
+Benefits:
+1. Passing null from one variable to another (currently not possible with uninitialized variables)
+2. Possibility to "uninitialize" already initialized value by assigning null to it
+3. Null check with == and != operators (currently unintuitive with the isbound function)
+4. Greater similarity with Java, C# and in some extent with C and C++
+
+Drawbacks:
+Minor backwards incompatibility for component, default and address types. These types will lose one of its states (uninitialized) and the behaviour of the isbound, isvalue and ispresent functions will change for operands of these types. The loss of state is most likely not harmful as it could only remove potential errors (e.g. comparison of uninitialized variable would yield false instead of a runtime error). However, change in the predefined functions could have some impact. The STF assumes that this impact is very limited, but it should be found out how often these functions are used in combination with the operands of component, default and address types in real test suites.
+
+
+
+
+
+ + + + + + + + + + +
+ (0014136) +
+ Jacob Wieland - Spirent    +
+ 17-08-2016 16:13    +
+ 		+ + + + +
+ STF-discussion:
+- introduce all types (except integer, float, boolean, enumerated, verdict) as implicitly nullable
+- add modifier to declare subtype of non-nullable types to be nullable
+- add attribute to declare 'implicit null' for a syntactic context meaning that all values living in this context will always have null instead of <uninitialized> (i.e. even if an uninitialized field is assigned to a field, the result will be null)
+- define new term "complete" to signify that something is completely initialized with non-null, use that those places where now "completely initialized" is used
+- require completeness in most cases where now "completely initialized" is required
+- check whether "completely initialized" is still needed anywhere where complete is not wanted
+- isvalue() returns true only for complete values
+- isbound() returns true for "at least partially initialized" structures, so also for null
+
+
+
+ + + + + + + + + + +
+ (0014307) +
+ Jens Grabowski    +
+ 17-11-2016 13:55    +
+ 		+ + + + +
+ Shifted to 2017. To be discussed in the context of OO extensions.
+
+
+
+ + + + + + + + + + +
+ (0015253) +
+ Jacob Wieland - Spirent    +
+ 11-10-2018 11:57    +
+ 		+ + + + +
+ I think in light of the OO developments, we can close this as unnecessary.
+
+
+
+ + + + + + + + + + +
+ (0015255) +
+ Kristóf Szabados    +
+ 11-10-2018 14:20    +
+ 		+ + + + +
+ STF agreement: not needed.
+
+ + diff --git a/docs/mantis/CR7188.md b/docs/mantis/CR7188.md new file mode 100644 index 0000000000000000000000000000000000000000..67db8ddc4fb9411f6c31361630e896e54d4183a8 --- /dev/null +++ b/docs/mantis/CR7188.md @@ -0,0 +1,171 @@ + + + + + + + + + + + + + 0007188: Presence of the XSD module - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007188Part 09: Using XML with TTCN-3Technicalpublic02-10-2015 09:3618-07-2016 11:44
ReporterTomas Urban 
Assigned To 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionwon't fix 
PlatformOSOS Version
Product Versionv4.6.1 (published 2015-06) 
Target Versionv4.8.1 (published 2017-05)Fixed in Version 
Clause Reference(s)5, Annex A
For STF discussion
Source (company - Author)STF 487
Summary0007188: Presence of the XSD module
DescriptionThe current specification doesn't define precisely the rules for presence of the XSD module and this gives space for different interpretations. The following issues should be considered:
+
+1. Module presence: Is the module automatically added/generated only if there are XML schemas in the test suite, i.e. if implicit or explicit conversion takes place (e.g. some rules on explicit mapping from the section 5 point in that direction)? Or is it automatically added even in situations when no schema is present, but some of the TTCN-3 explicitly import it?
+
+2. What should happen if there's user-defined XSD module in the test suite (especially in case when it is different from the one that is defined in the annex A)?
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
02-10-2015 09:36Tomas UrbanNew Issue
02-10-2015 14:03Jacob Wieland - SpirentNote Added: 0013347
03-11-2015 15:31Gyorgy RethyNote Added: 0013477
03-11-2015 15:31Gyorgy RethyAssigned To => Tomas Urban
03-11-2015 15:31Gyorgy RethyStatusnew => feedback
06-01-2016 09:23Gyorgy RethyTarget Version => v4.8.1 (published 2017-05)
18-07-2016 11:43Tomas UrbanNote Added: 0013978
18-07-2016 11:44Tomas UrbanNote Added: 0013979
18-07-2016 11:44Tomas UrbanStatusfeedback => closed
18-07-2016 11:44Tomas UrbanAssigned ToTomas Urban =>
18-07-2016 11:44Tomas UrbanResolutionopen => won't fix
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0013347) +
+ Jacob Wieland - Spirent    +
+ 02-10-2015 14:03    +
+ 		+ + + + +
+ in my opinion this is more of a tool issue than a standard issue
+
+in principle the standard defines the meaning of the different types by mapping them to types in the XSD module. For the explicit mapping, the XSD module needs to exist for that, for the implicit mapping, this is not really necessary, as long as the types generated are type compatible with the types from the XSD module. Of course, if the user wants to use some types from the module directly, either the tool has to provide that or the user has to provide the module himself. In case the user provides a module of the same name with a different content for those types that are defined in the standard, this should probably be considered erroneous in the explicit-mapping case. For implicit, it doesn't matter much.
+
+
+
+ + + + + + + + + + +
+ (0013477) +
+ Gyorgy Rethy    +
+ 03-11-2015 15:31    +
+ 		+ + + + +
+ STF discussion: The questions are relavant for explicit mapping only. The oppinion is that in this case these are tooling issues, not to be defined by the language specification.
+
+
+
+ + + + + + + + + + +
+ (0013978) +
+ Tomas Urban    +
+ 18-07-2016 11:43    +
+ 		+ + + + +
+ Since test suite handling is generally a tool issue, I accept the decision of the STF.
+
+
+
+ + + + + + + + + + +
+ (0013979) +
+ Tomas Urban    +
+ 18-07-2016 11:44    +
+ 		+ + + + +
+ Closing as won't fix.
+
+ + diff --git a/docs/mantis/CR7189.md b/docs/mantis/CR7189.md new file mode 100644 index 0000000000000000000000000000000000000000..1370eb9fd8fbbcc47e4b9933efa24d7a9e5abd63 --- /dev/null +++ b/docs/mantis/CR7189.md @@ -0,0 +1,106 @@ + + + + + + + + + + + + + 0007189: Wrong templates in substitution examples - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007189Part 09: Using XML with TTCN-3Editorialpublic02-10-2015 13:2104-11-2015 14:08
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.6.1 (published 2015-06) 
Target Versionv4.7.1 (published 2016-07)Fixed in Versionv4.7.1 (published 2016-07) 
Clause Reference(s)8.1.1
For STF discussion
Source (company - Author)STF 487
Summary0007189: Wrong templates in substitution examples
DescriptionThe templates in the examples on element substition in 8.1.1 are incorrectly defined. One pair of curly brackets (for the head_list element) is missing. E.g. the template in the EXAMPLE 1 should be defined as follows:
+
+template Ize t_Ize := {
+  head_list := {
+    { head := "anything" },
+    { member1 := "any thing" },
+    { member2 := something },
+    { member3 := { bar:= 5, foo := omit, base := "anything else" }
+  }
+}
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0007193closed Gyorgy Rethy Delete type of the substitution group element in example 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
02-10-2015 13:21Tomas UrbanNew Issue
02-11-2015 10:33Axel RennochAssigned To => Axel Rennoch
02-11-2015 10:33Axel RennochStatusnew => assigned
02-11-2015 10:35Axel RennochRelationship addedrelated to 0007193
02-11-2015 10:36Axel RennochNote Added: 0013433
02-11-2015 14:21Axel RennochNote Added: 0013442
02-11-2015 14:21Axel RennochStatusassigned => closed
02-11-2015 14:21Axel RennochAssigned ToAxel Rennoch => Gyorgy Rethy
02-11-2015 14:21Axel RennochResolutionopen => fixed
04-11-2015 14:08Gyorgy RethyFixed in Version => v4.7.1 (published 2016-07)
04-11-2015 14:08Gyorgy RethyTarget Version => v4.7.1 (published 2016-07)
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0013433) +
+ Axel Rennoch    +
+ 02-11-2015 10:36    +
+ 		+ + + + +
+ Correction is covered by resolution of CR 7193.
+
+
+
+ + + + + + + + + + +
+ (0013442) +
+ Axel Rennoch    +
+ 02-11-2015 14:21    +
+ 		+ + + + +
+ covered and resolved by CR 7193
+
+ + diff --git a/docs/mantis/CR7193.md b/docs/mantis/CR7193.md new file mode 100644 index 0000000000000000000000000000000000000000..5b83a3856009fbfe7559cf103d2bc3ee02e4ebd3 --- /dev/null +++ b/docs/mantis/CR7193.md @@ -0,0 +1,165 @@ + + + + + + + + + + + + + 0007193: Delete type of the substitution group element in example - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007193Part 09: Using XML with TTCN-3Editorialpublic08-10-2015 11:4004-12-2015 15:35
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.6.1 (published 2015-06) 
Target Versionv4.7.1 (published 2016-07)Fixed in Versionv4.7.1 (published 2016-07) 
Clause Reference(s)8.1.1
For STF discussion
Source (company - Author)L.M.Ericsson
Summary0007193: Delete type of the substitution group element in example
DescriptionIn clause 8.1.1, example 1 the substitution group element "member1" has the same type as the head element. In this case the type attribute is not mandatory. Though the example is technically correct as is, but for demonstration purposes it would be more powerful if its type attribute is deleted.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0007189closed Gyorgy Rethy Wrong templates in substitution examples 
Attached Filesdocx CR7193_resolution_v1.docx (66,424) 02-11-2015 13:56
http://oldforge.etsi.org/mantis/file_download.php?file_id=3335&type=bug
Issue History
Date ModifiedUsernameFieldChange
08-10-2015 11:40Gyorgy RethyNew Issue
15-10-2015 13:07Gyorgy RethyProduct Version => v4.6.1 (published 2015-06)
15-10-2015 13:07Gyorgy RethyTarget Version => v4.7.1 (published 2016-07)
15-10-2015 13:07Gyorgy RethyDescription Updatedbug_revision_view_page.php?rev_id=192#r192
02-11-2015 10:29Axel RennochAssigned To => Axel Rennoch
02-11-2015 10:29Axel RennochStatusnew => assigned
02-11-2015 10:35Axel RennochRelationship addedrelated to 0007189
02-11-2015 13:56Axel RennochFile Added: CR7193_resolution_v1.docx
02-11-2015 13:58Axel RennochNote Added: 0013438
02-11-2015 14:01Axel RennochNote Added: 0013439
02-11-2015 14:01Axel RennochAssigned ToAxel Rennoch => Jacob Wieland - Spirent
02-11-2015 14:01Axel RennochStatusassigned => acknowledged
02-11-2015 14:17Jacob Wieland - SpirentNote Added: 0013441
02-11-2015 14:17Jacob Wieland - SpirentStatusacknowledged => resolved
02-11-2015 14:17Jacob Wieland - SpirentFixed in Version => v4.7.1 (published 2016-07)
02-11-2015 14:17Jacob Wieland - SpirentResolutionopen => fixed
02-11-2015 14:17Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
04-12-2015 15:35Gyorgy RethyNote Added: 0013559
04-12-2015 15:35Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0013438) +
+ Axel Rennoch    +
+ 02-11-2015 13:58    +
+ 		+ + + + +
+ uploaded file considers CR7193, CR7189 and several changes of indentations, font changes etc. to improve readability.
+
+
+
+ + + + + + + + + + +
+ (0013439) +
+ Axel Rennoch    +
+ 02-11-2015 14:01    +
+ 		+ + + + +
+ Please check and confirm corrections and further changes.
+
+
+
+ + + + + + + + + + +
+ (0013441) +
+ Jacob Wieland - Spirent    +
+ 02-11-2015 14:17    +
+ 		+ + + + +
+ changes ok
+
+
+
+ + + + + + + + + + +
+ (0013559) +
+ Gyorgy Rethy    +
+ 04-12-2015 15:35    +
+ 		+ + + + +
+ Added to draft V4.6.3
+
+ + diff --git a/docs/mantis/CR7194.md b/docs/mantis/CR7194.md new file mode 100644 index 0000000000000000000000000000000000000000..0bf96859a990803c2c837d31f23cb5f8d5477fec --- /dev/null +++ b/docs/mantis/CR7194.md @@ -0,0 +1,165 @@ + + + + + + + + + + + + + 0007194: More explanation to type substitution would be useful - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007194Part 09: Using XML with TTCN-3Editorialpublic08-10-2015 13:3911-12-2015 11:12
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.6.1 (published 2015-06) 
Target Versionv4.7.1 (published 2016-07)Fixed in Versionv4.7.1 (published 2016-07) 
Clause Reference(s)8.2
For STF discussion
Source (company - Author)L.M.Ericsson
Summary0007194: More explanation to type substitution would be useful
DescriptionClause 8.2 decribes HOW to convert XSD to TTCN-3 to allow encoding/decoding XML type substitutions (by using the xsi:<type> atribute). However WHY this feature exists in the standard and how to use it are not always clear to the user (probably more oftn unclear than clear?). Therefore additional explanations would be useful.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0007240closed Gyorgy Rethy Error in example 1 of clause 8.1.1 
Attached Filesdocx CR7194_resolution_v1.docx (60,229) 04-11-2015 16:40
http://oldforge.etsi.org/mantis/file_download.php?file_id=3363&type=bug
docx CR7194_resolution_v2.docx (100,351) 09-12-2015 14:02
http://oldforge.etsi.org/mantis/file_download.php?file_id=3386&type=bug
Issue History
Date ModifiedUsernameFieldChange
08-10-2015 13:39Gyorgy RethyNew Issue
03-11-2015 15:32Gyorgy RethyTarget Version => v4.8.1 (published 2017-05)
04-11-2015 16:40Axel RennochFile Added: CR7194_resolution_v1.docx
04-11-2015 16:42Axel RennochNote Added: 0013492
04-11-2015 16:42Axel RennochAssigned To => Gyorgy Rethy
04-11-2015 16:42Axel RennochStatusnew => feedback
09-12-2015 14:02Gyorgy RethyFile Added: CR7194_resolution_v2.docx
09-12-2015 14:02Gyorgy RethyNote Added: 0013570
09-12-2015 14:02Gyorgy RethyStatusfeedback => assigned
09-12-2015 14:03Gyorgy RethyAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
09-12-2015 14:03Gyorgy RethyStatusassigned => confirmed
09-12-2015 14:03Gyorgy RethyTarget Versionv4.8.1 (published 2017-05) => v4.7.1 (published 2016-07)
09-12-2015 16:06Jacob Wieland - SpirentNote Added: 0013572
09-12-2015 16:07Jacob Wieland - SpirentStatusconfirmed => resolved
09-12-2015 16:07Jacob Wieland - SpirentFixed in Version => v4.7.1 (published 2016-07)
09-12-2015 16:07Jacob Wieland - SpirentResolutionopen => fixed
09-12-2015 16:07Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
09-12-2015 16:09Jacob Wieland - SpirentRelationship addedrelated to 0007240
11-12-2015 11:12Gyorgy RethyNote Added: 0013584
11-12-2015 11:12Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0013492) +
+ Axel Rennoch    +
+ 04-11-2015 16:42    +
+ 		+ + + + +
+ Please have a look to the example in the uploaded file.
+
+
+
+ + + + + + + + + + +
+ (0013570) +
+ Gyorgy Rethy    +
+ 09-12-2015 14:02    +
+ 		+ + + + +
+ CR7194_resolution_v2.docx: updated text and examples. Pls. review.
+
+
+
+ + + + + + + + + + +
+ (0013572) +
+ Jacob Wieland - Spirent    +
+ 09-12-2015 16:06    +
+ 		+ + + + +
+ apart from a typo "documant", it is fine
+
+
+
+ + + + + + + + + + +
+ (0013584) +
+ Gyorgy Rethy    +
+ 11-12-2015 11:12    +
+ 		+ + + + +
+ Added to draft V4.6.4
+
+ + diff --git a/docs/mantis/CR7195.md b/docs/mantis/CR7195.md new file mode 100644 index 0000000000000000000000000000000000000000..13d293548cf2b6564803078a65260fd29922a5a9 --- /dev/null +++ b/docs/mantis/CR7195.md @@ -0,0 +1,446 @@ + + + + + + + + + + + + + 0007195: interleave is much too restricted - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007195Part 01: TTCN-3 Core LanguageNew Featurepublic09-10-2015 15:2712-12-2016 20:28
ReporterJacob Wieland - Spirent 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.9.1 (published 2017-05)Fixed in Versionv4.9.1 (published 2017-05) 
Clause Reference(s)20.4
Source (company - Author)Testing Technologies - Jacob Wieland
Summary0007195: interleave is much too restricted
DescriptionThe restriction a) of the Interleave Statement unnecessarily disallows far too much.
+
+Unproblematic are:
+- activate/deactivate
+- stop (same as break+stop)
+- loops/conditionals containing no (potentially) blocking statements
+- direct invocation of altsteps (same as alt statements with altsteps)
+- return (same as break + return)
+- goto outside the interleave (same as break + goto)
+
+If the restrictions were to be relaxed to disallow only repeat, function calls containing blocking statements and loops/if-statements containing blocking statements, the mapping to alt-statements would still possible with the expected semantics.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR-7195.docx (21,380) 28-12-2015 11:27
http://oldforge.etsi.org/mantis/file_download.php?file_id=3397&type=bug
Issue History
Date ModifiedUsernameFieldChange
09-10-2015 15:27Jacob Wieland - SpirentNew Issue
03-11-2015 16:07Gyorgy RethyNote Added: 0013478
03-11-2015 16:07Gyorgy RethyAssigned To => Jens Grabowski
03-11-2015 16:07Gyorgy RethyStatusnew => assigned
04-11-2015 13:58Gyorgy RethyProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
04-11-2015 13:59Gyorgy RethyTarget Version => v4.8.1 (published 2016-07)
05-11-2015 15:28Jens GrabowskiNote Added: 0013505
05-11-2015 15:33Jens GrabowskiNote Added: 0013506
05-11-2015 16:04Jens GrabowskiNote Added: 0013510
05-11-2015 16:37Jens GrabowskiNote Added: 0013511
05-11-2015 19:13Jacob Wieland - SpirentNote Added: 0013513
06-11-2015 11:12Gyorgy RethyNote Added: 0013516
28-12-2015 11:27Jens GrabowskiFile Added: CR-7195.docx
28-12-2015 11:29Jens GrabowskiNote Added: 0013650
28-12-2015 11:29Jens GrabowskiAssigned ToJens Grabowski => Gyorgy Rethy
28-12-2015 11:29Jens GrabowskiStatusassigned => confirmed
18-07-2016 14:51Jens GrabowskiAssigned ToGyorgy Rethy => Kristóf Szabados
18-07-2016 14:51Jens GrabowskiStatusconfirmed => assigned
18-07-2016 14:51Jens GrabowskiStatusassigned => confirmed
17-08-2016 10:48Jacob Wieland - SpirentTarget Versionv4.8.1 (published 2016-07) => v4.9.1 (published 2017-05)
18-08-2016 08:24Kristóf SzabadosNote Added: 0014146
18-08-2016 08:24Kristóf SzabadosStatusconfirmed => resolved
18-08-2016 08:24Kristóf SzabadosFixed in Version => v4.9.1 (published 2017-05)
18-08-2016 08:24Kristóf SzabadosResolutionopen => fixed
18-08-2016 08:24Kristóf SzabadosAssigned ToKristóf Szabados => Gyorgy Rethy
12-12-2016 20:28Gyorgy RethyNote Added: 0014399
12-12-2016 20:28Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0013478) +
+ Gyorgy Rethy    +
+ 03-11-2015 16:07    +
+ 		+ + + + +
+ STF discussion: check that allowing which operation keeps interleave and the final semantics easy to understand and which one would make it difficult to understand the expected behaviour.
+We can allow the obvious and easy-to-use ones.
+
+
+
+ + + + + + + + + + +
+ (0013505) +
+ Jens Grabowski    +
+ 05-11-2015 15:28    +
+ 		+ + + + +
+ Note 1:
+
+- stop (same as break+stop)
+- return (same as break + return)
+- goto outside the interleave (same as break + goto)
+
+can be allowed, Jacob already provided the corresponding semantics.
+
+
+
+ + + + + + + + + + +
+ (0013506) +
+ Jens Grabowski    +
+ 05-11-2015 15:33    +
+ 		+ + + + +
+ Note 2:
+
+- - loops/conditionals containing no (potentially) blocking statements
+
+If I interprete this correctly, such loops/conditionals are loops/conditionals within statement blocks embedded in interleave statements. I.e., such loops will always appear as a whole in the textual replacement semantics.
+
+If yes, it can be allowed.
+
+
+
+ + + + + + + + + + +
+ (0013510) +
+ Jens Grabowski    +
+ 05-11-2015 16:04    +
+ 		+ + + + +
+ Note 3:
+
+- activate/deactivate
+
+The textual expansion mechanism may easily provide a semantics for this, but the effects are difficult to predict. The test outcome may become dependent on the order in which the ports are examined. But the idea of interleave is exactly the opposite, i.e., specifying reception sequences where the order in which the ports are examined plays no role.
+
+
+
+ + + + + + + + + + +
+ (0013511) +
+ Jens Grabowski    +
+ 05-11-2015 16:37    +
+ 		+ + + + +
+ Note 4a)
+
+- direct invocation of altsteps (same as alt statements with altsteps)
+
+
+First case (example):
+
+interleave {
+[] receive(M1){};
+[] MyAltstep(){};
+}
+
+Shall this be allowed? What is the interpretation?
+
+
+Interpretation 1: M1 and all top alternatives of MyAltstep are interleaved.
+
+In this case the interpretation of MyAltstep becomes context dependent. If used in an alt construct, only one alternative is executed. If used in an interleave, all alternatives are interleaved executed.
+
+I am against such context dependent interpretations!
+
+
+
+Interpretation 2: The evaluation order in MyAltstep is kept but interleaved with the reception of M1.
+
+If MyAltstep includeds nested alt statements and one alternative in MyAltstep is chosen first, M1 may be interleaved with the altstep internal alternatives. This may be difficult to understand.
+
+In addition, Altsteps used within interleave must follow the same restrictions as interleave statements, i.e., special restrictions for altsteps used in certain places.
+
+
+Interpretation 3: Not allowed.
+
+
+
+ + + + + + + + + + +
+ (0013513) +
+ Jacob Wieland - Spirent    +
+ 05-11-2015 19:13    +
+ 		+ + + + +
+ Actually, when I raised this issue I was not even thinking about your example, but about this one:
+
+interleave {
+[] p.receive(A); { MyAltstep(); ... }
+[] ...
+}
+
+which is equivalent to
+
+interleave {
+[] p.receive(A); { alt{ [] MyAltstep(); {} } ... }
+[] ...
+}
+
+which does not violate any restrictions at the moment, but has obviously the same problems as the example you have given.
+
+In principle, I share your opinion that only the interpretation 2 would be acceptable (from 1 and 2), but it would require the same restrictions as for interleave to the invoked altsteps recursively. To achieve this, the mapping semantics would have to be changed to first unfold all altstep invocations (i.e they shall not be recursive) and then impose the interleave-to-alt-translation (if no violation of the other restrictions occurs in the unfolded interleave).
+
+However, if that is the case, then the same restriction must hold for usage of altsteps also in alt statements in the statement blocks of the interleave branches! No such restriction is imposed at the moment on the statement blocks.
+
+Thus, to be consistent either altstep instances must be allowed inside the whole interleave structure, stand-alone or not (with other interleave restrictions imposed on them) or they should be disallowed both inside alt statements and stand-alone.
+
+
+
+ + + + + + + + + + +
+ (0013516) +
+ Gyorgy Rethy    +
+ 06-11-2015 11:12    +
+ 		+ + + + +
+ STF discussion: cover Note 1 & 2 below by this CR and add a clarification that all altstep calles are forbidden (clarify direct call).
+
+
+
+ + + + + + + + + + +
+ (0013650) +
+ Jens Grabowski    +
+ 28-12-2015 11:29    +
+ 		+ + + + +
+ Resolution attached. I put it to confirmed and assign it directly to György as it implements the STF discussion.
+
+
+
+ + + + + + + + + + +
+ (0014146) +
+ Kristóf Szabados    +
+ 18-08-2016 08:24    +
+ 		+ + + + +
+ Implements STF decision, looks fine by me.
+
+
+
+ + + + + + + + + + +
+ (0014399) +
+ Gyorgy Rethy    +
+ 12-12-2016 20:28    +
+ 		+ + + + +
+ Added to draft V4.8.2
+
+ + diff --git a/docs/mantis/CR7196.md b/docs/mantis/CR7196.md new file mode 100644 index 0000000000000000000000000000000000000000..58d5566303c9a978ad87ba057aa4668e645b2139 --- /dev/null +++ b/docs/mantis/CR7196.md @@ -0,0 +1,243 @@ + + + + + + + + + + + + + 0007196: start operation with altstep should be allowed - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007196Part 01: TTCN-3 Core LanguageClarificationpublic09-10-2015 15:5505-01-2016 15:41
ReporterJacob Wieland - Spirent 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.8.1 (published 2016-07)Fixed in Versionv4.8.1 (published 2016-07) 
Clause Reference(s)21.3.2
Source (company - Author)Testing Technologies - Jacob Wieland
Summary0007196: start operation with altstep should be allowed
DescriptionThere is really no need to restrict the start operation to only apply to functions and not to altsteps. Altsteps in this context are just special functions containing only an alt-statement (and maybe some variable declarations). As long as the runs on and other compatibilities are adhered to, there is no need for this restriction.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7196_resolution_v1.docx (454,526) 05-11-2015 09:48
http://oldforge.etsi.org/mantis/file_download.php?file_id=3366&type=bug
docx CR7196_resolution_v2.docx (1,674,920) 05-11-2015 15:35
http://oldforge.etsi.org/mantis/file_download.php?file_id=3369&type=bug
Issue History
Date ModifiedUsernameFieldChange
09-10-2015 15:55Jacob Wieland - SpirentNew Issue
03-11-2015 16:11Gyorgy RethyNote Added: 0013479
03-11-2015 16:11Gyorgy RethyAssigned To => Jacob Wieland - Spirent
03-11-2015 16:11Gyorgy RethyStatusnew => assigned
04-11-2015 13:58Gyorgy RethyProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
04-11-2015 13:59Gyorgy RethyTarget Version => v4.8.1 (published 2016-07)
05-11-2015 09:48Jacob Wieland - SpirentFile Added: CR7196_resolution_v1.docx
05-11-2015 09:49Jacob Wieland - SpirentNote Added: 0013498
05-11-2015 09:49Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Jens Grabowski
05-11-2015 09:49Jacob Wieland - SpirentStatusassigned => confirmed
05-11-2015 13:48Jens GrabowskiNote Added: 0013499
05-11-2015 13:48Jens GrabowskiStatusconfirmed => assigned
05-11-2015 13:48Jens GrabowskiAssigned ToJens Grabowski => Jacob Wieland - Spirent
05-11-2015 15:35Jacob Wieland - SpirentFile Added: CR7196_resolution_v2.docx
05-11-2015 15:43Jacob Wieland - SpirentNote Added: 0013507
05-11-2015 15:43Jacob Wieland - SpirentNote Added: 0013508
05-11-2015 15:43Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Jens Grabowski
05-11-2015 15:43Jacob Wieland - SpirentStatusassigned => confirmed
28-12-2015 10:29Jens GrabowskiAssigned ToJens Grabowski => Gyorgy Rethy
28-12-2015 10:29Jens GrabowskiStatusconfirmed => resolved
05-01-2016 15:41Gyorgy RethyNote Added: 0013660
05-01-2016 15:41Gyorgy RethyStatusresolved => closed
05-01-2016 15:41Gyorgy RethyResolutionopen => fixed
05-01-2016 15:41Gyorgy RethyFixed in Version => v4.8.1 (published 2016-07)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0013479) +
+ Gyorgy Rethy    +
+ 03-11-2015 16:11    +
+ 		+ + + + +
+ STF discussion: basically agreed. Prepare text proosal.
+
+
+
+ + + + + + + + + + +
+ (0013498) +
+ Jacob Wieland - Spirent    +
+ 05-11-2015 09:49    +
+ 		+ + + + +
+ please review and resolve
+
+
+
+ + + + + + + + + + +
+ (0013499) +
+ Jens Grabowski    +
+ 05-11-2015 13:48    +
+ 		+ + + + +
+ Sorry, but I assign it back due to the following reasons:
+- the term behaviour as shorthand for functions and altsteps is nowhere defined (test cases also define behaviour)
+- in the function section it is explicitly mentioned that functions started with a start test component operation shall always have a runs on clause.
+
+Maybe we have to discuss these issues.
+
+
+
+ + + + + + + + + + +
+ (0013507) +
+ Jacob Wieland - Spirent    +
+ 05-11-2015 15:43    +
+ 		+ + + + +
+ There was already a definition of test behaviour (or behaviour) in the definitions section that referred to testcases, functions and altsteps (but excluded altsteps directly started for ptcs, of course). I have included another definition "behaviour definition" which enumerates the different kinds of behaviour definitions explicitly. If the proposed text remains unclear, maybe this terminus could be used in certain places.
+
+the term behaviour is widely used through the whole standard (and sometimes with additions like function behaviour, behaviour function, etc), but mostly as a running sequence of statements and most of the cases refer to these 3 entities (though control part, of course, should also be considered as behaviour, though maybe not test behaviour). Especially in section 21.3 it is often used to describe any behaviour running on a component.
+
+I have tried to make the use of the terms more consistent through the standard and to include altstep in any place that was missing that was previously only mentioning functions.
+
+I have also added the same restriction for started altsteps as for started functions.
+
+
+
+ + + + + + + + + + +
+ (0013508) +
+ Jacob Wieland - Spirent    +
+ 05-11-2015 15:43    +
+ 		+ + + + +
+ please review again
+
+
+
+ + + + + + + + + + +
+ (0013660) +
+ Gyorgy Rethy    +
+ 05-01-2016 15:41    +
+ 		+ + + + +
+ Added to draft V4.7.5
+
+ + diff --git a/docs/mantis/CR7200.md b/docs/mantis/CR7200.md new file mode 100644 index 0000000000000000000000000000000000000000..796bb35860d42ace078b0fe5f717e5a54043ae8d --- /dev/null +++ b/docs/mantis/CR7200.md @@ -0,0 +1,298 @@ + + + + + + + + + + + + + 0007200: Allow ranges and value list for enumerated types - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007200Part 01: TTCN-3 Core LanguageTechnicalpublic15-10-2015 09:1410-12-2015 16:54
Reportertepelmann 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.8.1 (published 2016-07)Fixed in Versionv4.8.1 (published 2016-07) 
Clause Reference(s)6.2.4, C.1.30
Source (company - Author)Testing Technologies
Summary0007200: Allow ranges and value list for enumerated types
DescriptionThe type enumerated provides the tester with meaningful values during development and execution without the necessity to interpret specific values.
+However there is one disadvantage in cases where not all possible values are specified inside the enumerated, e.g. reserved values. This occurs in the majority of protocol specifications.
+Simple example: A 8Bit enocded enumerated Color -
+type enumerated Color {
+  e_red(0),
+  e_green(1),
+  e_blue(2),
+  e_reserved
+}
+
+On the sending side it is not possible to select all values - e_reserved has only one value: 3, where values between 0 and 255 would be selectable.
+On the receiving side there are two possible pitfalls in case of receiving a value not expressed by the enumerated type. Either you get an error because the value is not assignable, or you have special decoding mapping the unassignable value to 'reserved' but loosing the actual value.
+
+Proposal: Allow ranges and value list for the type enumerated
+E.g.
+type enumerated Color {
+  e_red(0),
+  e_green(1),
+  e_blue(2),
+  e_reserved(3..255)
+}
+
+type enumerated Color {
+  e_red(0),
+  e_green(1),
+  e_blue(3),
+  e_reserved(2,4..255)
+}
+
+For the sending(and receiving) side the explicit value of 'reserved' could be expressed in brackets - reserved(127).
+For receiving - where the actual value is unknown beforehand - the actual value could be retrieved via the existing enum2int predefined function.
+
+If the explicit value is not given the lowest possible value could be used by default - this is the current behaviour.
+
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7200.docx (520,017) 04-11-2015 17:14
http://oldforge.etsi.org/mantis/file_download.php?file_id=3364&type=bug
docx CR7200-1-v2.docx (254,422) 05-11-2015 14:08
http://oldforge.etsi.org/mantis/file_download.php?file_id=3368&type=bug
docx CR7200-1-v3.docx (314,507) 09-12-2015 15:47
http://oldforge.etsi.org/mantis/file_download.php?file_id=3389&type=bug
Issue History
Date ModifiedUsernameFieldChange
15-10-2015 09:14tepelmannNew Issue
02-11-2015 08:56tepelmannNote Added: 0013432
03-11-2015 16:42Gyorgy RethyNote Added: 0013480
03-11-2015 16:42Gyorgy RethyAssigned To => Jacob Wieland - Spirent
03-11-2015 16:42Gyorgy RethyStatusnew => assigned
04-11-2015 13:59Gyorgy RethyTarget Version => v4.8.1 (published 2016-07)
04-11-2015 17:14Jacob Wieland - SpirentFile Added: CR7200.docx
04-11-2015 17:15Jacob Wieland - SpirentNote Added: 0013493
04-11-2015 17:16Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Jens Grabowski
04-11-2015 17:16Jacob Wieland - SpirentStatusassigned => confirmed
05-11-2015 14:07Jens GrabowskiNote Added: 0013501
05-11-2015 14:08Jens GrabowskiFile Added: CR7200-1-v2.docx
05-11-2015 14:08Jens GrabowskiAssigned ToJens Grabowski => Gyorgy Rethy
05-11-2015 14:08Jens GrabowskiStatusconfirmed => assigned
05-11-2015 14:09Jens GrabowskiStatusassigned => confirmed
06-11-2015 08:53Gyorgy RethyNote Edited: 0013480bug_revision_view_page.php?bugnote_id=13480#r214
09-12-2015 15:30Gyorgy RethyFile Added: CR7200-1-v3.docx
09-12-2015 15:31Gyorgy RethyFile Deleted: CR7200-1-v3.docx
09-12-2015 15:47Gyorgy RethyFile Added: CR7200-1-v3.docx
09-12-2015 15:50Gyorgy RethyNote Added: 0013571
09-12-2015 15:50Gyorgy RethyStatusconfirmed => resolved
09-12-2015 15:50Gyorgy RethyFixed in Version => v4.8.1 (published 2016-07)
09-12-2015 15:50Gyorgy RethyResolutionopen => fixed
10-12-2015 16:54Gyorgy RethyNote Added: 0013582
10-12-2015 16:54Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0013432) +
+ tepelmann    +
+ 02-11-2015 08:56    +
+ 		+ + + + +
+ Real world example: 3GPP TS 24.008, 10.5.3.3 CM service type:
+Service type (octet 1)
+Bits
+4 3 2 1
+0 0 0 1 Mobile originating call establishment or packet mode connection establishment
+0 0 1 0 Emergency call establishment
+0 1 0 0 Short message service
+1 0 0 0 Supplementary service activation
+1 0 0 1 Voice group call establishment
+1 0 1 0 Voice broadcast call establishment
+1 0 1 1 Location Services (NOTE)
+                
+All other values are reserved.
+
+Could result in:
+type enumerated CM_ServiceType {
+  e_mobileOrigCallEstab_packetModConEstab(1),
+  e_emergCallEstab(2),
+  e_sms(4),
+  e_supplServAct(8),
+  e_voiceGroupCallEstab(9),
+  e_voiceBcastCallEstab(10),
+  e_locServices(11),
+  reserved(3, 5..6, 12..15)
+}
+
+
+
+ + + + + + + + + + +
+ (0013480) +
+ Gyorgy Rethy    +
+ 03-11-2015 16:42    +
(edited on: 06-11-2015 08:53)
+ 		+ + + + +
+ STF discussion: practical usefulness is agreed. The "range" enumerated names can be used as TTCN-3 values with concrete associated integer values only. Otherwise they can be used in templates.
+Prepare a concrete proposal.
+
+
+
+
+
+ + + + + + + + + + +
+ (0013493) +
+ Jacob Wieland - Spirent    +
+ 04-11-2015 17:15    +
+ 		+ + + + +
+ added proposal allowing enum ranges, enum values with single integer and enum templates with integer template list
+
+please review
+
+
+
+ + + + + + + + + + +
+ (0013501) +
+ Jens Grabowski    +
+ 05-11-2015 14:07    +
+ 		+ + + + +
+ Corrected one or two typos.
+
+György: In this resolution, Jacob also corrected examples on page 12 of the attachment which are not directly related to enum ranges. Please check them also. For this reason a put this issue to confirm instead of resolved.
+
+
+
+ + + + + + + + + + +
+ (0013571) +
+ Gyorgy Rethy    +
+ 09-12-2015 15:50    +
+ 		+ + + + +
+ 1 example causing error is added to $6.2.4 (enumerated value with associated integer is used) plus editorials.
+
+
+
+ + + + + + + + + + +
+ (0013582) +
+ Gyorgy Rethy    +
+ 10-12-2015 16:54    +
+ 		+ + + + +
+ Added to draft V4.7.4
+
+ + diff --git a/docs/mantis/CR7201.md b/docs/mantis/CR7201.md new file mode 100644 index 0000000000000000000000000000000000000000..b283928482195b745f9344dd9cc80fd98319e377 --- /dev/null +++ b/docs/mantis/CR7201.md @@ -0,0 +1,131 @@ + + + + + + + + + + + + + 0007201: Missing conversion for unnamed <list> derivations - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007201Part 09: Using XML with TTCN-3Technicalpublic15-10-2015 10:1704-12-2015 15:52
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.6.1 (published 2015-06) 
Target Versionv4.7.1 (published 2016-07)Fixed in Versionv4.7.1 (published 2016-07) 
Clause Reference(s)7.5.2 Derivation by list
For STF discussion
Source (company - Author)L.M.Ericsson
Summary0007201: Missing conversion for unnamed <list> derivations
DescriptionCurrently the standard describes derivation by <list> for the named types using itemType only. Like for union-t, rules for (embedded) unnamed types shall be given.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7201_resolution_v1.docx (71,864) 15-10-2015 12:03
http://oldforge.etsi.org/mantis/file_download.php?file_id=3313&type=bug
Issue History
Date ModifiedUsernameFieldChange
15-10-2015 10:17Gyorgy RethyNew Issue
15-10-2015 12:03Gyorgy RethyNote Added: 0013396
15-10-2015 12:03Gyorgy RethyAssigned To => Jacob Wieland - Spirent
15-10-2015 12:03Gyorgy RethyReproducibilityhave not tried => always
15-10-2015 12:03Gyorgy RethyStatusnew => confirmed
15-10-2015 12:03Gyorgy RethyFile Added: CR7201_resolution_v1.docx
15-10-2015 12:17Jacob Wieland - SpirentNote Added: 0013398
15-10-2015 12:17Jacob Wieland - SpirentStatusconfirmed => resolved
15-10-2015 12:17Jacob Wieland - SpirentResolutionopen => fixed
15-10-2015 12:17Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
04-11-2015 14:05Gyorgy RethyFixed in Version => v4.7.1 (published 2016-07)
04-12-2015 15:52Gyorgy RethyNote Added: 0013561
04-12-2015 15:52Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0013396) +
+ Gyorgy Rethy    +
+ 15-10-2015 12:03    +
+ 		+ + + + +
+ Proposed resolution is in CR7201_resolution_v1.docx. Please review
+
+
+
+ + + + + + + + + + +
+ (0013398) +
+ Jacob Wieland - Spirent    +
+ 15-10-2015 12:17    +
+ 		+ + + + +
+ proposal looks ok to me
+
+
+
+ + + + + + + + + + +
+ (0013561) +
+ Gyorgy Rethy    +
+ 04-12-2015 15:52    +
+ 		+ + + + +
+ Added to draft V4.6.3
+
+ + diff --git a/docs/mantis/CR7210.md b/docs/mantis/CR7210.md new file mode 100644 index 0000000000000000000000000000000000000000..ba773c07c83cd716c4917b01c7027ef3d4ed7be8 --- /dev/null +++ b/docs/mantis/CR7210.md @@ -0,0 +1,182 @@ + + + + + + + + + + + + + 0007210: How to decode an empty element when an optional sequence includes optional elements only - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007210Part 09: Using XML with TTCN-3Technicalpublic29-10-2015 11:0904-12-2015 15:46
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.6.1 (published 2015-06) 
Target Versionv4.7.1 (published 2016-07)Fixed in Versionv4.7.1 (published 2016-07) 
Clause Reference(s)7.6.6.6 and B.3.21
For STF discussion
Source (company - Author)L.M.Ericsson
Summary0007210: How to decode an empty element when an optional sequence includes optional elements only
DescriptionThe XSD element below :
+<xsd:element name="optionals_in_optional">
+  <xsd:complexType>
+    <xsd:sequence minOccurs="0">
+      <xsd:element name="elem1" type="xsd:string" minOccurs="0"/>
+      <xsd:element name="elem2" type="xsd:integer" minOccurs="0"/>
+      <xsd:element name="elem3" type="xsd:decimal" minOccurs="0"/>
+      <xsd:element name="elem4" type="xsd:dateTime" minOccurs="0"/>
+      <xsd:element name="elem5" type="xsd:duration" minOccurs="0"/>
+    </xsd:sequence>
+  </xsd:complexType>
+</xsd:element>
+
+
+will be translated to TTCN-3 as:
+type record Optionals_in_optional
+{
+    record {
+        XSD.String elem1 optional,
+        XSD.Integer elem2 optional,
+        XSD.Decimal elem3 optional,
+        XSD.DateTime elem4 optional,
+        XSD.Duration elem5 optional
+    } sequence optional
+}
+with {
+variant "name as uncapitalized";
+variant "element";
+variant (sequence) "untagged";
+};
+
+where the 'sequence' name of the record shall not be present in the encoded XML value.
+
+This is not the problem at encoding, both
+template Optionals_in_optional t_optionals1 := { sequence := omit }
+and
+template Optionals_in_optional t_optionals2 := {
+  sequence := {
+    elem1 := omit,
+    elem2 := omit,
+    elem3 := omit,
+    elem4 := omit,
+    elem5 := omit
+  }
+}
+
+will be encoded as an empty <optionals_in_optional></optionals_in_optional> element.
+
+However, it is NOT SPECIFIED, how the above incoming element shall be decoded into TTCN-3. Therefore the user needs to define a template list containing both templates above to be sure that the incoming empty element will match. This is cumbersome and superflouos.
+
+Proposed solution: it is proposed to specify that this specific case shall be decoded to the value { sequence := omit }; this is the shortest and thus more user friendly solution.
+Note: it could cause backward incompatibility if code is written to tool-specific decoding, and causes no backward compatibility for code written to ba standard-compliant.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7210_resolution_v1.docx (63,553) 29-10-2015 11:54
http://oldforge.etsi.org/mantis/file_download.php?file_id=3332&type=bug
docx CR7210_resolution_v2.docx (65,389) 04-11-2015 11:11
http://oldforge.etsi.org/mantis/file_download.php?file_id=3357&type=bug
Issue History
Date ModifiedUsernameFieldChange
29-10-2015 11:09Gyorgy RethyNew Issue
29-10-2015 11:37Gyorgy RethyDescription Updatedbug_revision_view_page.php?rev_id=194#r194
29-10-2015 11:45Gyorgy RethyDescription Updatedbug_revision_view_page.php?rev_id=195#r195
29-10-2015 11:54Gyorgy RethyFile Added: CR7210_resolution_v1.docx
29-10-2015 11:55Gyorgy RethyDescription Updatedbug_revision_view_page.php?rev_id=196#r196
03-11-2015 16:49Gyorgy RethyAssigned To => Axel Rennoch
03-11-2015 16:49Gyorgy RethyStatusnew => assigned
03-11-2015 16:50Gyorgy RethyNote Added: 0013481
04-11-2015 11:11Axel RennochFile Added: CR7210_resolution_v2.docx
04-11-2015 11:13Axel RennochNote Added: 0013484
04-11-2015 11:13Axel RennochAssigned ToAxel Rennoch => Gyorgy Rethy
04-11-2015 11:13Axel RennochStatusassigned => confirmed
04-11-2015 13:56Gyorgy RethyStatusconfirmed => resolved
04-11-2015 13:56Gyorgy RethyFixed in Version => v4.7.1 (published 2016-07)
04-11-2015 13:56Gyorgy RethyResolutionopen => fixed
04-11-2015 14:05Gyorgy RethyProduct Version => v4.6.1 (published 2015-06)
04-11-2015 14:05Gyorgy RethyTarget Version => v4.7.1 (published 2016-07)
04-12-2015 15:46Gyorgy RethyNote Added: 0013560
04-12-2015 15:46Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0013481) +
+ Gyorgy Rethy    +
+ 03-11-2015 16:50    +
+ 		+ + + + +
+ STF discussion: agreed in pronciple. Review proposed solution.
+
+
+
+ + + + + + + + + + +
+ (0013484) +
+ Axel Rennoch    +
+ 04-11-2015 11:13    +
+ 		+ + + + +
+ Just some minor formatting issues solved in resolution_v2.
+
+
+
+ + + + + + + + + + +
+ (0013560) +
+ Gyorgy Rethy    +
+ 04-12-2015 15:46    +
+ 		+ + + + +
+ Added to draft V4.6.3
+
+ + diff --git a/docs/mantis/CR7212.md b/docs/mantis/CR7212.md new file mode 100644 index 0000000000000000000000000000000000000000..1999dccec77041f8e306c04410cd222de99e721e --- /dev/null +++ b/docs/mantis/CR7212.md @@ -0,0 +1,99 @@ + + + + + + + + + + + + + 0007212: Update Operational Semantics: Visibility of Definitions (public, friend, private) - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 04: TTCN-3 Operational Semantics
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007212Part 04: TTCN-3 Operational SemanticsClarificationpublic03-11-2015 11:2321-07-2016 08:28
ReporterJens Grabowski 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.4.1 (published 2012-04) 
Target Versionv4.5.1 (published 2016-07)Fixed in Versionv4.5.1 (published 2016-07) 
Clause Reference(s)8.2 (Module Definitions Part in Core Language)
Source (company - Author) STF 491
Summary0007212: Update Operational Semantics: Visibility of Definitions (public, friend, private)
DescriptionThe operational semantics does not handle visibility of definitions. A note should be added to clarify this.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Fileszip es_20187304v040401p-CR7212.zip (1,607,608) 03-11-2015 12:06
http://oldforge.etsi.org/mantis/file_download.php?file_id=3352&type=bug
Issue History
Date ModifiedUsernameFieldChange
03-11-2015 11:23Jens GrabowskiNew Issue
03-11-2015 11:23Jens GrabowskiStatusnew => assigned
03-11-2015 11:23Jens GrabowskiAssigned To => Jens Grabowski
03-11-2015 12:06Jens GrabowskiFile Added: es_20187304v040401p-CR7212.zip
03-11-2015 12:06Jens GrabowskiNote Added: 0013468
03-11-2015 12:07Jens GrabowskiAssigned ToJens Grabowski => Jacob Wieland - Spirent
03-11-2015 12:33Jacob Wieland - SpirentNote Added: 0013469
03-11-2015 12:33Jacob Wieland - SpirentStatusassigned => resolved
03-11-2015 12:33Jacob Wieland - SpirentFixed in Version => v4.5.1 (published 2016-07)
03-11-2015 12:33Jacob Wieland - SpirentResolutionopen => fixed
03-11-2015 12:33Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Jens Grabowski
06-01-2016 14:39Gyorgy RethyTarget Versionv4.6.1(ongoing) => v4.5.1 (published 2016-07)
21-07-2016 08:28Jens GrabowskiStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0013468) +
+ Jens Grabowski    +
+ 03-11-2015 12:06    +
+ 		+ + + + +
+ New item added to Clause 6 "Restrictions".
+
+@Jacob: please crosscheck.
+
+
+
+ + + + + + + + + + +
+ (0013469) +
+ Jacob Wieland - Spirent    +
+ 03-11-2015 12:33    +
+ 		+ + + + +
+ ok
+
+ + diff --git a/docs/mantis/CR7213.md b/docs/mantis/CR7213.md new file mode 100644 index 0000000000000000000000000000000000000000..7bc7ede2fdcfa1b52689490a944514f67f09f3e7 --- /dev/null +++ b/docs/mantis/CR7213.md @@ -0,0 +1,142 @@ + + + + + + + + + + + + + 0007213: Example is wrong - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007213Part 01: TTCN-3 Core LanguageClarificationpublic03-11-2015 13:5114-12-2015 11:26
ReporterJens Grabowski 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.7.1 (published 2015-06) 
Target Versionv4.8.1 (published 2016-07)Fixed in Versionv4.8.1 (published 2016-07) 
Clause Reference(s)11.1
Source (company - Author)STF 491
Summary0007213: Example is wrong
DescriptionExample in Clause 11.1 is wrong:
+
+var integer MyVar0;
+var integer MyVar1 := 1;
+var boolean MyVar2 := true, MyVar3 := false;
+var @lazy integer MyLazyVar1 := MyVar1+1;
+MyVar1 := 2;
+MyVar2 := MyLazyVar1; // MyLazyVar1 evaluates to 2 + 1
+MyLazyVar1 := MyLazyVar1 + 1;
+MyVar2 := MyLazyVar1; // causes an error as MyLazyVar1 references itself
+
+MyVar2 and MyLazyVar1 are of different types, thus the assignment causes an error, but not (only) due to the self reference of MyLazyVar1
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7213_resolution_v1.docx (77,080) 03-11-2015 14:13
http://oldforge.etsi.org/mantis/file_download.php?file_id=3354&type=bug
Issue History
Date ModifiedUsernameFieldChange
03-11-2015 13:51Jens GrabowskiNew Issue
03-11-2015 14:09Axel RennochAssigned To => Axel Rennoch
03-11-2015 14:09Axel RennochStatusnew => assigned
03-11-2015 14:13Axel RennochFile Added: CR7213_resolution_v1.docx
03-11-2015 14:14Axel RennochNote Added: 0013471
03-11-2015 14:14Axel RennochAssigned ToAxel Rennoch => Jacob Wieland - Spirent
03-11-2015 14:14Axel RennochStatusassigned => acknowledged
03-11-2015 14:36Jacob Wieland - SpirentNote Added: 0013473
03-11-2015 14:36Jacob Wieland - SpirentStatusacknowledged => resolved
03-11-2015 14:36Jacob Wieland - SpirentFixed in Version => v4.8.1 (published 2016-07)
03-11-2015 14:36Jacob Wieland - SpirentResolutionopen => fixed
03-11-2015 14:36Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
14-12-2015 11:26Gyorgy RethyNote Added: 0013611
14-12-2015 11:26Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0013471) +
+ Axel Rennoch    +
+ 03-11-2015 14:14    +
+ 		+ + + + +
+ Please check the correction in uploaded file.
+
+
+
+ + + + + + + + + + +
+ (0013473) +
+ Jacob Wieland - Spirent    +
+ 03-11-2015 14:36    +
+ 		+ + + + +
+ correct
+
+
+
+ + + + + + + + + + +
+ (0013611) +
+ Gyorgy Rethy    +
+ 14-12-2015 11:26    +
+ 		+ + + + +
+ Added to draft V4.7.4
+
+ + diff --git a/docs/mantis/CR7214.md b/docs/mantis/CR7214.md new file mode 100644 index 0000000000000000000000000000000000000000..6116325ebb353dd5f891fb069882a84056fcd5f9 --- /dev/null +++ b/docs/mantis/CR7214.md @@ -0,0 +1,99 @@ + + + + + + + + + + + + + 0007214: Lazy and Fuzzy evaluation of variables and parameters is not mentioned in the operational semantics - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 04: TTCN-3 Operational Semantics
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007214Part 04: TTCN-3 Operational SemanticsClarificationpublic04-11-2015 10:4121-07-2016 08:31
ReporterJens Grabowski 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.4.1 (published 2012-04) 
Target Versionv4.5.1 (published 2016-07)Fixed in Versionv4.5.1 (published 2016-07) 
Clause Reference(s)6
Source (company - Author)STF 491
Summary0007214: Lazy and Fuzzy evaluation of variables and parameters is not mentioned in the operational semantics
DescriptionThe operational semantics does not cover lazy and fuzzy evaluation of variables and parameters. This should be clarified.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Fileszip es_20187304v040401p-CR7214.zip (1,608,356) 04-11-2015 14:39
http://oldforge.etsi.org/mantis/file_download.php?file_id=3360&type=bug
Issue History
Date ModifiedUsernameFieldChange
04-11-2015 10:41Jens GrabowskiNew Issue
04-11-2015 10:41Jens GrabowskiStatusnew => assigned
04-11-2015 10:41Jens GrabowskiAssigned To => Jens Grabowski
04-11-2015 14:39Jens GrabowskiNote Added: 0013490
04-11-2015 14:39Jens GrabowskiFile Added: es_20187304v040401p-CR7214.zip
04-11-2015 14:39Jens GrabowskiAssigned ToJens Grabowski => Jacob Wieland - Spirent
04-11-2015 17:51Jacob Wieland - SpirentNote Added: 0013495
04-11-2015 17:51Jacob Wieland - SpirentStatusassigned => resolved
04-11-2015 17:51Jacob Wieland - SpirentFixed in Version => v4.5.1 (published 2016-07)
04-11-2015 17:51Jacob Wieland - SpirentResolutionopen => fixed
04-11-2015 17:51Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Jens Grabowski
21-07-2016 08:31Jens GrabowskiStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0013490) +
+ Jens Grabowski    +
+ 04-11-2015 14:39    +
+ 		+ + + + +
+ Notes have been added to the clauses 6, 9.18, 9.21 and 9.57.
+
+Jacob please check if they are appropriate.
+
+
+
+ + + + + + + + + + +
+ (0013495) +
+ Jacob Wieland - Spirent    +
+ 04-11-2015 17:51    +
+ 		+ + + + +
+ looks good
+
+ + diff --git a/docs/mantis/CR7215.md b/docs/mantis/CR7215.md new file mode 100644 index 0000000000000000000000000000000000000000..47f4b9df646be3a804a826a8e12b53d52f2d8deb --- /dev/null +++ b/docs/mantis/CR7215.md @@ -0,0 +1,369 @@ + + + + + + + + + + + + + 0007215: Clarify the what the enumerated value's "type context" means - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007215Part 01: TTCN-3 Core LanguageClarificationpublic05-11-2015 12:0711-12-2015 14:02
ReporterGyorgy Rethy 
Assigned ToJacob Wieland - Spirent 
PriorityhighSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.7.1 (published 2015-06) 
Target Versionv4.8.1 (published 2016-07)Fixed in Versionv4.8.1 (published 2016-07) 
Clause Reference(s)6.2.4
Source (company - Author)L.M.Ericsson
Summary0007215: Clarify the what the enumerated value's "type context" means
DescriptionThe standard states that "The identifiers of enumerated values shall be unique within the enumerated type (but do not have to be globally unique) and are consequently visible in the context of the given type only."
+
+However, the exact meaning of "context of the given type" is not further elaborated. Therefore it shall be specified in more detail.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7215_resolution_v1.docx (97,138) 05-11-2015 16:31
http://oldforge.etsi.org/mantis/file_download.php?file_id=3370&type=bug
docx CR7215_resolution_v2.docx (108,649) 04-12-2015 11:15
http://oldforge.etsi.org/mantis/file_download.php?file_id=3384&type=bug
docx CR7215_resolution_v3.docx (108,555) 04-12-2015 13:12
http://oldforge.etsi.org/mantis/file_download.php?file_id=3385&type=bug
Issue History
Date ModifiedUsernameFieldChange
05-11-2015 12:07Gyorgy RethyNew Issue
05-11-2015 12:07Gyorgy RethyAssigned To => Gyorgy Rethy
05-11-2015 12:07Gyorgy RethyStatusnew => assigned
05-11-2015 13:10Gyorgy RethyDescription Updatedbug_revision_view_page.php?rev_id=208#r208
05-11-2015 16:31Gyorgy RethyFile Added: CR7215_resolution_v1.docx
05-11-2015 16:37Gyorgy RethyNote Added: 0013512
05-11-2015 16:38Gyorgy RethyNote Edited: 0013512bug_revision_view_page.php?bugnote_id=13512#r210
05-11-2015 16:38Gyorgy RethyNote Edited: 0013512bug_revision_view_page.php?bugnote_id=13512#r211
05-11-2015 16:39Gyorgy RethyNote Edited: 0013512bug_revision_view_page.php?bugnote_id=13512#r212
05-11-2015 16:40Gyorgy RethyAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
05-11-2015 16:40Gyorgy RethyStatusassigned => confirmed
06-11-2015 09:47Jacob Wieland - SpirentNote Added: 0013515
06-11-2015 09:48Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
06-11-2015 09:48Jacob Wieland - SpirentStatusconfirmed => assigned
01-12-2015 15:05Gyorgy RethyNote Added: 0013540
01-12-2015 15:32Gyorgy RethyNote Edited: 0013540bug_revision_view_page.php?bugnote_id=13540#r218
01-12-2015 15:52Gyorgy RethyNote Edited: 0013540bug_revision_view_page.php?bugnote_id=13540#r219
02-12-2015 12:59Jacob Wieland - SpirentNote Added: 0013541
04-12-2015 10:34Gyorgy RethyFile Added: CR7215_resolution_v2.docx
04-12-2015 10:37Gyorgy RethyNote Added: 0013549
04-12-2015 10:37Gyorgy RethyAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
04-12-2015 10:37Gyorgy RethyPrioritynormal => high
04-12-2015 10:37Gyorgy RethyStatusassigned => confirmed
04-12-2015 10:37Gyorgy RethyProduct Version => v4.7.1 (published 2015-06)
04-12-2015 10:37Gyorgy RethyTarget Version => v4.8.1 (published 2016-07)
04-12-2015 10:38Gyorgy RethyFile Deleted: CR7215_resolution_v2.docx
04-12-2015 10:58Gyorgy RethyFile Added: CR7215_resolution_v2.docx
04-12-2015 11:00Gyorgy RethyFile Deleted: CR7215_resolution_v2.docx
04-12-2015 11:15Gyorgy RethyFile Added: CR7215_resolution_v2.docx
04-12-2015 11:16Gyorgy RethyNote Added: 0013550
04-12-2015 13:12Gyorgy RethyFile Added: CR7215_resolution_v3.docx
04-12-2015 13:13Gyorgy RethyNote Added: 0013552
04-12-2015 14:25Jacob Wieland - SpirentNote Added: 0013555
04-12-2015 14:25Jacob Wieland - SpirentStatusconfirmed => resolved
04-12-2015 14:25Jacob Wieland - SpirentFixed in Version => v4.8.1 (published 2016-07)
04-12-2015 14:25Jacob Wieland - SpirentResolutionopen => fixed
11-12-2015 14:02Gyorgy RethyNote Added: 0013588
11-12-2015 14:02Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0013512) +
+ Gyorgy Rethy    +
+ 05-11-2015 16:37    +
(edited on: 05-11-2015 16:39)
+ 		+ + + + +
+ Actually, I didn't need to change or specify the rules for enumarated. It was already further down, in paragraph 3 and example 2 of the same clause (6.2.4):
+
+"For any instantiation or value reference of an enumerated type, the given type shall be implicitly or explicitly referenced.
+NOTE 2: If the enumerated type is an element of a user defined structured type, the enumerated type is implicitly referenced via the given element (i.e. by the identifier of the element or the position of the value in a value list notation) at value assignment, instantiation, etc.
+EXAMPLE2:
+...
+    // But the following causes an error
+    if ( Tuesday == Wednesday ) {...}
+    // there is no TTCN-3 type(d) object to establish the type context for the equality operator
+    // Please note that the values Tuesday and Wednesday are defined within the type
+    // MyFirstEnumType only, but this is not sufficient to establish the type context
+"
+So, to make it more readable and to keep related rules in one place, I have moved paragraph 3 into paragraph 1, added two more examples to NOTE2 and a matching example to EXAMPLE2.
+
+Please review.
+
+
+
+
+
+ + + + + + + + + + +
+ (0013515) +
+ Jacob Wieland - Spirent    +
+ 06-11-2015 09:47    +
+ 		+ + + + +
+ Yes, this makes things more clear.
+
+However, reading the text, I stumbled upon this sentence:
+
+"Operations on enumerated types shall only use these identifiers and are restricted to assignment, equivalence and ordering operators."
+
+Doesn't that entail that I cannot compare a variable/field of the enumerated type or pass it as an actual parameter, since the only operations allowed on it are comparisons and these cannot use variables, but only the enumerated names (I guess on both sides) which then does not work because there is no enum context.
+
+I think this sentence is bogus and needs to be rewritten.
+
+
+
+ + + + + + + + + + +
+ (0013540) +
+ Gyorgy Rethy    +
+ 01-12-2015 15:05    +
(edited on: 01-12-2015 15:52)
+ 		+ + + + +
+ Of course you can compare an enumerated value with a typed object and can pass it as actual parameter.
+
+The given sentence talks about "operations" only, and mentions equality explicitly. The note below says: "Another example is passing an enumerated value as actual parameter, in which case the type of the corresponding formal parameter establishes the type context needed to make the enumeration value visible."
+
+But based on the discussion today at the STF160 tool vendors meeting I tend to think that a more generic approach is needed to explain what establishes a type context.
+
+I propose to define it in a way that all language procedures requiring type compatibility (operations, parameter passing etc.) establish the type context, if at least one participant is a typed object, while statements allowing type incompatibility require typed objects as arguments.
+
+
+
+
+
+ + + + + + + + + + +
+ (0013541) +
+ Jacob Wieland - Spirent    +
+ 02-12-2015 12:59    +
+ 		+ + + + +
+ it is not only statements allowing type incompatibility (which at the moment is only match) but also statements/operations allowing parameters of any type (i.e. no specific type required), which are log, testcase.stop and setverdict as well as the is-functions (if I'm not forgetting anything).
+
+
+
+ + + + + + + + + + +
+ (0013549) +
+ Gyorgy Rethy    +
+ 04-12-2015 10:37    +
+ 		+ + + + +
+ The issue (the specific case of using enum values within match()) has been also raised by STF160 at their tool vendors meeting @01.dec.2015. Hence priority is raised to high.
+
+
+
+ + + + + + + + + + +
+ (0013550) +
+ Gyorgy Rethy    +
+ 04-12-2015 11:16    +
+ 		+ + + + +
+ Please review CR7215_resolution_v2.docx.
+
+
+
+ + + + + + + + + + +
+ (0013552) +
+ Gyorgy Rethy    +
+ 04-12-2015 13:13    +
+ 		+ + + + +
+ CR7215_resolution_v3.docx: type context for comparision operators is added to Note2.
+
+
+
+ + + + + + + + + + +
+ (0013555) +
+ Jacob Wieland - Spirent    +
+ 04-12-2015 14:25    +
+ 		+ + + + +
+ I think this is ok now, can be set to resolved.
+
+
+
+ + + + + + + + + + +
+ (0013588) +
+ Gyorgy Rethy    +
+ 11-12-2015 14:02    +
+ 		+ + + + +
+ Added to draft V4.7.4
+
+ + diff --git a/docs/mantis/CR7216.md b/docs/mantis/CR7216.md new file mode 100644 index 0000000000000000000000000000000000000000..4eb14e1edc0f87238cd2f720a945fd4022637bcc --- /dev/null +++ b/docs/mantis/CR7216.md @@ -0,0 +1,172 @@ + + + + + + + + + + + + + 0007216: match operation should require type compatibility of the operands - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007216Part 01: TTCN-3 Core LanguageTechnicalpublic05-11-2015 12:1613-12-2016 15:27
ReporterJacob Wieland - Spirent 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.8.1 (published 2016-07) 
Target Versionv4.9.1 (published 2017-05)Fixed in Versionv4.9.1 (published 2017-05) 
Clause Reference(s)15.9.
Source (company - Author)Testing Technologies - Jacob Wieland
Summary0007216: match operation should require type compatibility of the operands
DescriptionAt the moment, the match operation allows two operands of incompatible types, yielding false.
+
+This feature should be made deprecated so that tools may opt for warning users about these cases or even mark this as erroneous.
+
+It is the only place in the language that allows the combination of two things of incompatible types even though the semantics of the operation (true if the templates matches the value) are otherwise defined only for objects of compatible types. Thus is not really consistent with the rest of a type-safe language.
+
+Disallowing this (probably pathological) case could lead to backward-incompatibilities, but it is hard to imagine someone using something like match(a,b) intentionally to write down 'false' except in non-real world scenarios which want to test this feature thoroughly.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7216-1.docx (20,468) 18-07-2016 14:40
http://oldforge.etsi.org/mantis/file_download.php?file_id=3413&type=bug
Issue History
Date ModifiedUsernameFieldChange
05-11-2015 12:16Jacob Wieland - SpirentNew Issue
06-11-2015 08:43Gyorgy RethyProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
06-11-2015 08:43Gyorgy RethyProduct Version => v4.8.1 (published 2016-07)
06-11-2015 08:43Gyorgy RethyTarget Version => v4.9.1 (published 2017-05)
18-07-2016 11:22Jens GrabowskiAssigned To => Tomas Urban
18-07-2016 11:22Jens GrabowskiStatusnew => assigned
18-07-2016 11:23Jens GrabowskiNote Added: 0013977
18-07-2016 14:40Tomas UrbanFile Added: CR7216-1.docx
18-07-2016 14:42Tomas UrbanAssigned ToTomas Urban => Axel Rennoch
18-07-2016 14:42Tomas UrbanNote Added: 0013981
15-08-2016 15:08Axel RennochNote Added: 0014080
15-08-2016 15:08Axel RennochAssigned ToAxel Rennoch => Gyorgy Rethy
15-08-2016 15:08Axel RennochStatusassigned => confirmed
13-12-2016 15:27Gyorgy RethyNote Added: 0014423
13-12-2016 15:27Gyorgy RethyStatusconfirmed => closed
13-12-2016 15:27Gyorgy RethyResolutionopen => fixed
13-12-2016 15:27Gyorgy RethyFixed in Version => v4.9.1 (published 2017-05)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0013977) +
+ Jens Grabowski    +
+ 18-07-2016 11:23    +
+ 		+ + + + +
+ STF decision: Deprecate the feature.
+
+
+
+ + + + + + + + + + +
+ (0013981) +
+ Tomas Urban    +
+ 18-07-2016 14:42    +
+ 		+ + + + +
+ Resolution uploaded.
+Please check.
+
+
+
+ + + + + + + + + + +
+ (0014080) +
+ Axel Rennoch    +
+ 15-08-2016 15:08    +
+ 		+ + + + +
+ The proposed resolution is ok. Please close the CR.
+
+
+
+ + + + + + + + + + +
+ (0014423) +
+ Gyorgy Rethy    +
+ 13-12-2016 15:27    +
+ 		+ + + + +
+ Added to draft V4.8.2
+
+ + diff --git a/docs/mantis/CR7217.md b/docs/mantis/CR7217.md new file mode 100644 index 0000000000000000000000000000000000000000..c8238e57a9768e7daddd4c0791de972d489685b5 --- /dev/null +++ b/docs/mantis/CR7217.md @@ -0,0 +1,72 @@ + + + + + + + + + + + + + 0007217: Add language string for the coming version - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007217Part 01: TTCN-3 Core LanguageNew Featurepublic05-11-2015 13:4705-11-2015 13:53
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.7.1 (published 2015-06) 
Target Versionv4.8.1 (published 2016-07)Fixed in Versionv4.8.1 (published 2016-07) 
Clause Reference(s)8.1, H
Source (company - Author)L.M.Ericsson
Summary0007217: Add language string for the coming version
Description(1)
+In clause 8.1 change
+    "TTCN 3:2015" - to be used with modules complying with the present document.
+
+to
+    "TTCN 3:2015" - to be used with modules complying with version 4.7.1 of the present document (see annex H).
+    "TTCN 3:2015" - to be used with modules complying with the present document.
+
+(2)
+In Annex H add version v4.7.1.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
05-11-2015 13:47Gyorgy RethyNew Issue
05-11-2015 13:48Gyorgy RethyProduct Version => v4.7.1 (published 2015-06)
05-11-2015 13:48Gyorgy RethyTarget Version => v4.8.1 (published 2016-07)
05-11-2015 13:48Gyorgy RethyAssigned To => Gyorgy Rethy
05-11-2015 13:48Gyorgy RethyStatusnew => assigned
05-11-2015 13:53Gyorgy RethyNote Added: 0013500
05-11-2015 13:53Gyorgy RethyStatusassigned => closed
05-11-2015 13:53Gyorgy RethyResolutionopen => fixed
05-11-2015 13:53Gyorgy RethyFixed in Version => v4.8.1 (published 2016-07)
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0013500) +
+ Gyorgy Rethy    +
+ 05-11-2015 13:53    +
+ 		+ + + + +
+ Added to draft version v4.7.4
+
+ + diff --git a/docs/mantis/CR7238.md b/docs/mantis/CR7238.md new file mode 100644 index 0000000000000000000000000000000000000000..5f7b3c0797cd7723b3f2875263978c3a1285053b --- /dev/null +++ b/docs/mantis/CR7238.md @@ -0,0 +1,173 @@ + + + + + + + + + + + + + 0007238: Follow-up on date/time changes in XSD 1.1 - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007238Part 09: Using XML with TTCN-3Clarificationpublic04-12-2015 13:5812-01-2017 09:13
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionno change required 
PlatformOSOS Version
Product Versionv4.7.1 (published 2016-07) 
Target Versionv4.8.1 (published 2017-05)Fixed in Versionv4.8.1 (published 2017-05) 
Clause Reference(s)6.5
For STF discussion
Source (company - Author)L.M.Ericsson
Summary0007238: Follow-up on date/time changes in XSD 1.1
DescriptionCR6868 pinpointed a change in XSD 1.1, related to XSD 1.0: the new version allows year 0000, while the old one disallowed this. This specific case (the year pattern in clause 6.5 and Annex A) has been changed.
+
+However, other potential changes in XSD date/time types shall also be checked and applied in Part-9.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
04-12-2015 13:58Gyorgy RethyNew Issue
06-01-2016 09:23Gyorgy RethyTarget Version => v4.8.1 (published 2017-05)
18-07-2016 11:18Jens GrabowskiAssigned To => Kristóf Szabados
18-07-2016 11:18Jens GrabowskiStatusnew => assigned
20-07-2016 10:22Kristóf SzabadosNote Added: 0013998
20-07-2016 10:24Kristóf SzabadosNote Added: 0013999
20-07-2016 10:24Kristóf SzabadosAssigned ToKristóf Szabados => Gyorgy Rethy
20-07-2016 10:24Kristóf SzabadosStatusassigned => feedback
18-08-2016 15:54Jacob Wieland - SpirentNote Added: 0014160
17-11-2016 14:10Jens GrabowskiStatusfeedback => closed
17-11-2016 14:10Jens GrabowskiResolutionopen => no change required
12-01-2017 09:13Gyorgy RethyFixed in Version => v4.8.1 (published 2017-05)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0013998) +
+ Kristóf Szabados    +
+ 20-07-2016 10:22    +
+ 		+ + + + +
+ I found one item that might need to be changed.
+
+Part 9 describes year and yearExpanded as separate entities:
+"
+year := "[0-9]#(4)",
+yearExpansion := "-#(,1)([1-9][0-9]#(0,))#(,1)",
+"
+Which can follow each other in patterns:
+"
+type charstring DateTime (pattern
+  "{yearExpansion}{year}{dash}{month}{dash}{dayOfMonth}T({hour}{cln}{minute}{cln}{second}" &
+  "{sFraction}|{endOfDayExt}){ZorTimeZoneExt}"
+  )
+with {
+    variant "XSD:dateTime";
+}
+"
+
+According to XSD schema (https://www.w3.org/TR/xmlschema11-2/#nt-yrFrag [^]) these should be one item:
+"
+[16] dateTimeLexicalRep ::= yearFrag '-' monthFrag '-' dayFrag 'T' ((hourFrag ':' minuteFrag ':' secondFrag) | endOfDayFrag) timezoneFrag?
+[56] yearFrag ::= '-'? (([1-9] digit digit digit+)) | ('0' digit digit digit))
+"
+
+ISO 8601:2004(E) in section 4.1.2.4 says that the year element is expanded with more digits:
+"
+If, by agreement, expanded representations are used, the formats shall be as specified below. The
+interchange parties shall agree the additional number of digits in the time element year. In the examples below
+it has been agreed to expand the time element year with two digits
+"
+
+I believe the current description of the related patterns in part 9 should be changed to:
+"
+type charstring Date (pattern
+  "({yearExpansion}|{year}){dash}{month}{dash}{dayOfMonth}{ZorTimeZoneExt}"
+  ) with {
+       variant "XSD:date";
+    }
+"
+and the yearExpansion to "(-#(,1)[1-9][0-9]#(3,)|0[0-9]#(3))"
+
+
+
+ + + + + + + + + + +
+ (0013999) +
+ Kristóf Szabados    +
+ 20-07-2016 10:24    +
+ 		+ + + + +
+ Could you comment on the changes proposed in the previous comment?
+(change the yearExpansion and the patterns it is used in)
+
+
+
+ + + + + + + + + + +
+ (0014160) +
+ Jacob Wieland - Spirent    +
+ 18-08-2016 15:54    +
+ 		+ + + + +
+ would that in any way change the semantics as we have them now? If not, I would not change anything.
+
+ + diff --git a/docs/mantis/CR7239.md b/docs/mantis/CR7239.md new file mode 100644 index 0000000000000000000000000000000000000000..8e9a1adaa02d021588508fe1d3cf0bb364d0bbc2 --- /dev/null +++ b/docs/mantis/CR7239.md @@ -0,0 +1,337 @@ + + + + + + + + + + + + + 0007239: Change element substitution generation rules to support backward compatibility - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007239Part 09: Using XML with TTCN-3New Featurepublic08-12-2015 11:2613-12-2016 17:25
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.6.1 (published 2015-06) 
Target Versionv4.8.1 (published 2017-05)Fixed in Versionv4.8.1 (published 2017-05) 
Clause Reference(s)8.1.1
For STF discussion
Source (company - Author)L.M.Ericsson
Summary0007239: Change element substitution generation rules to support backward compatibility
DescriptionCurrently rules in clause 8.1.1 specify that for the head element of a substitution group ONLY a union type is generated. This causes backward compatibility problem, when a new version of an XSD specification introduces substitution.
+I show this on example 1 from the standard;
+----------------------------------------
+let say version one defines the "head" element only, without substitution:
+    <xsd:element name="head" type="xsd:string" />
+
+For this element e.g. the TTCN-3 code will be generated:
+
+module http_www_example_org {
+...
+type XSD.String Head
+with {
+variant "name as uncapitalized";
+variant "element";
+};
+} with {...}
+
+And the user writes its own code and testing its SUT using it, e.g.:
+
+module use {
+
+import from http_www_example_org all;
+
+template Head t_message := "mytext"
+
+}
+-----------------------------------------------------
+Now, the XSD specification changes to a new version, adding substitution elements, and according to the current rules, in TTCN-3 ONLY the Head_group type will be generated for the "head" element:
+
+module http_www_example_org {
+...
+type union Head_group {
+  XSD.String head,
+..Member1 member1,
+..Member2 member2,
+  Member3 member3
+}
+with {
+   variant "untagged";
+   variant(head) "element";
+}
+
+} with {...}
+
+So, in this case the generated module will not contain a type named Head and the above module use.ttcn will not compile.
+-----------------------------------------------------
+Users do not want to change TTCN-3 code used for regression testing of SUT code that didn't change. This is a wasted time for them. Users wants that modules written for version 1 of the specification is also working with the type modules generated for version 2 (used to test other products and/or new features).
+This could be achieved by a small backward compatible change in Part-9:
+- for the version 2 XSD document containing substitution, instead of generating the Head_group type for the head element only, generate its own TTCN-3 type for the head element and the Head_group type in addition:
+
+module http_www_example_org {
+...
+type XSD.String Head
+with {
+variant "name as uncapitalized";
+variant "element";
+};
+type union Head_group {
+  Head head,
+..Member1 member1,
+..Member2 member2,
+  Member3 member3
+}
+with {variant "untagged"}
+} with {...}
+
+So now, the "old" TTCN-3 mdule use.ttcn, importing the new http_www_example_org module will compile.
+
+This will not solve the backward compatibility for all uses of the head element, but is backward compatible from the XSD to TTCN mapping point of view and also makes the generated code more readable.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0007421closed Gyorgy Rethy How to achieve full backward compatibility in case of element- and/or type-substitution 
related to 0007240closed Gyorgy Rethy Error in example 1 of clause 8.1.1 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
08-12-2015 11:26Gyorgy RethyNew Issue
08-12-2015 11:32Gyorgy RethyRelationship addedrelated to 0007240
08-12-2015 11:42Gyorgy RethyAssigned To => Jacob Wieland - Spirent
08-12-2015 11:42Gyorgy RethyStatusnew => assigned
08-12-2015 11:42Gyorgy RethyProduct Version => v4.6.1 (published 2015-06)
08-12-2015 11:42Gyorgy RethyTarget Version => v4.7.1 (published 2016-07)
08-12-2015 11:42Gyorgy RethyDescription Updatedbug_revision_view_page.php?rev_id=225#r225
09-12-2015 14:09Gyorgy RethyDescription Updatedbug_revision_view_page.php?rev_id=226#r226
09-12-2015 16:11Jacob Wieland - SpirentNote Added: 0013574
09-12-2015 16:11Jacob Wieland - SpirentStatusassigned => resolved
09-12-2015 16:11Jacob Wieland - SpirentFixed in Version => v4.7.1 (published 2016-07)
09-12-2015 16:11Jacob Wieland - SpirentResolutionopen => fixed
09-12-2015 16:11Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
11-12-2015 11:15Gyorgy RethyNote Added: 0013585
11-12-2015 11:15Gyorgy RethyStatusresolved => feedback
11-12-2015 11:15Gyorgy RethyResolutionfixed => reopened
11-12-2015 11:17Gyorgy RethyNote Edited: 0013585bug_revision_view_page.php?bugnote_id=13585#r228
11-12-2015 11:17Gyorgy RethyAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
11-12-2015 11:17Gyorgy RethyStatusfeedback => assigned
14-12-2015 12:39Jacob Wieland - SpirentNote Added: 0013615
21-12-2015 08:16Gyorgy RethyFixed in Versionv4.7.1 (published 2016-07) =>
21-12-2015 08:16Gyorgy RethyTarget Versionv4.7.1 (published 2016-07) => v4.8.1 (published 2017-05)
24-06-2016 10:39Jacob Wieland - SpirentNote Added: 0013968
19-08-2016 13:26Jacob Wieland - SpirentRelationship addedrelated to 0007421
19-08-2016 13:27Jacob Wieland - SpirentNote Added: 0014179
19-08-2016 13:27Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Kristóf Szabados
19-08-2016 13:27Jacob Wieland - SpirentStatusassigned => confirmed
17-11-2016 10:18Kristóf SzabadosNote Added: 0014295
17-11-2016 10:18Kristóf SzabadosStatusconfirmed => resolved
17-11-2016 10:18Kristóf SzabadosFixed in Version => v4.9.1 (published 2018-05)
17-11-2016 10:18Kristóf SzabadosResolutionreopened => fixed
17-11-2016 14:13Kristóf SzabadosAssigned ToKristóf Szabados => Gyorgy Rethy
17-11-2016 14:13Kristóf SzabadosStatusresolved => assigned
17-11-2016 14:18Kristóf SzabadosStatusassigned => resolved
17-11-2016 14:18Kristóf SzabadosFixed in Versionv4.9.1 (published 2018-05) => v4.8.1 (published 2017-05)
13-12-2016 17:25Gyorgy RethyNote Added: 0014430
13-12-2016 17:25Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0013574) +
+ Jacob Wieland - Spirent    +
+ 09-12-2015 16:11    +
+ 		+ + + + +
+ resolved in CR 7194
+
+
+
+ + + + + + + + + + +
+ (0013585) +
+ Gyorgy Rethy    +
+ 11-12-2015 11:15    +
(edited on: 11-12-2015 11:17)
+ 		+ + + + +
+ Actually, CR 7194 deals with the type substitution part only ($8.2). This CR proposes a backward compatible change to element substitution mapping ($8.1).
+
+
+
+
+
+ + + + + + + + + + +
+ (0013615) +
+ Jacob Wieland - Spirent    +
+ 14-12-2015 12:39    +
+ 		+ + + + +
+ Then I propose to shift it to the next year.
+
+
+
+ + + + + + + + + + +
+ (0013968) +
+ Jacob Wieland - Spirent    +
+ 24-06-2016 10:39    +
+ 		+ + + + +
+ This problem would be solved also by the implicit-boxing/unboxing-union feature. The unions generated for the substitution case sould be such special wrapper-unions and thus, templates written in a context without substitution should also work if substitution is enabled.
+
+
+
+ + + + + + + + + + +
+ (0014179) +
+ Jacob Wieland - Spirent    +
+ 19-08-2016 13:27    +
+ 		+ + + + +
+ solved by the proposal for CR 7421 and 7493
+
+
+
+ + + + + + + + + + +
+ (0014295) +
+ Kristóf Szabados    +
+ 17-11-2016 10:18    +
+ 		+ + + + +
+ Solved by the proposal for CR 7421 (which also builds on 7493)
+
+
+
+ + + + + + + + + + +
+ (0014430) +
+ Gyorgy Rethy    +
+ 13-12-2016 17:25    +
+ 		+ + + + +
+ See resolution in CR 7421
+
+ + diff --git a/docs/mantis/CR7240.md b/docs/mantis/CR7240.md new file mode 100644 index 0000000000000000000000000000000000000000..17d7c1d583311056981c2fc9f5c061415d9120b9 --- /dev/null +++ b/docs/mantis/CR7240.md @@ -0,0 +1,122 @@ + + + + + + + + + + + + + 0007240: Error in example 1 of clause 8.1.1 - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007240Part 09: Using XML with TTCN-3Editorialpublic08-12-2015 11:3111-12-2015 10:59
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.6.1 (published 2015-06) 
Target Versionv4.7.1 (published 2016-07)Fixed in Versionv4.7.1 (published 2016-07) 
Clause Reference(s)8.1.1
For STF discussion
Source (company - Author)L.M.Ericsson
Summary0007240: Error in example 1 of clause 8.1.1
DescriptionIn the generated type Head_group there is no identification, that the field "head" also represents an XSD element (pls. note that for the other fields the types Member1, Member2 and Member3 carry the "element" encoding instruction)
+
+Change:
+type union Head_group {
+  XSD.String head,
+  Member1 member1,
+  Member2 member2,
+  Member3 member3
+}
+with {
+    variant "untagged";
+}
+
+To:
+type union Head_group {
+  XSD.String head,
+..Member1 member1,
+..Member2 member2,
+  Member3 member3
+}
+with {
+    variant "untagged";
+    variant(head) "element";
+}
+
+Please note, this change is not needed, if CR7239 is agreed, as in this case the "element" instruction will be placed on the Head type.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0007239closed Gyorgy Rethy Change element substitution generation rules to support backward compatibility 
related to 0007194closed Gyorgy Rethy More explanation to type substitution would be useful 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
08-12-2015 11:31Gyorgy RethyNew Issue
08-12-2015 11:32Gyorgy RethyRelationship addedrelated to 0007239
08-12-2015 11:33Gyorgy RethyDescription Updatedbug_revision_view_page.php?rev_id=223#r223
08-12-2015 11:43Gyorgy RethyAssigned To => Jacob Wieland - Spirent
08-12-2015 11:43Gyorgy RethyStatusnew => assigned
08-12-2015 11:43Gyorgy RethyProduct Version => v4.6.1 (published 2015-06)
08-12-2015 11:43Gyorgy RethyTarget Version => v4.7.1 (published 2016-07)
09-12-2015 16:09Jacob Wieland - SpirentRelationship addedrelated to 0007194
09-12-2015 16:10Jacob Wieland - SpirentNote Added: 0013573
09-12-2015 16:10Jacob Wieland - SpirentStatusassigned => resolved
09-12-2015 16:10Jacob Wieland - SpirentFixed in Version => v4.7.1 (published 2016-07)
09-12-2015 16:10Jacob Wieland - SpirentResolutionopen => fixed
09-12-2015 16:10Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
11-12-2015 10:59Gyorgy RethyNote Added: 0013583
11-12-2015 10:59Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0013573) +
+ Jacob Wieland - Spirent    +
+ 09-12-2015 16:10    +
+ 		+ + + + +
+ resolved in CR7194
+
+
+
+ + + + + + + + + + +
+ (0013583) +
+ Gyorgy Rethy    +
+ 11-12-2015 10:59    +
+ 		+ + + + +
+ Added to draft V4.6.4
+
+ + diff --git a/docs/mantis/CR7271.md b/docs/mantis/CR7271.md new file mode 100644 index 0000000000000000000000000000000000000000..2a873e681ee855f6c67645d772cdcd2613384573 --- /dev/null +++ b/docs/mantis/CR7271.md @@ -0,0 +1,274 @@ + + + + + + + + + + + + + 0007271: template(present) restriction shall also apply to individual elements of complement,superset,subset,permutation lists - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007271Part 01: TTCN-3 Core LanguageClarificationpublic27-12-2015 11:1612-12-2016 13:32
ReporterJacob Wieland - Spirent 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.8.1 (published 2016-07) 
Target Versionv4.9.1 (published 2017-05)Fixed in Versionv4.9.1 (published 2017-05) 
Clause Reference(s)B.1.2.2, B.1.2.6, B.1.2.7, B.1.3.3
Source (company - Author)Testing Technologies - Jacob Wieland
Summary0007271: template(present) restriction shall also apply to individual elements of complement,superset,subset,permutation lists
DescriptionCR 7171 added restriction that template lists shall only contain template(present) items. The same should be true for the constructs
+complement, superset, subset and permutation (with the exception of AnyElementsOrNone for permutation)
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0007487closed Gyorgy Rethy inconsistent examples and naming in Annex B 
Attached Filesdocx CR7271_7487_7488_resolution_v1.docx (152,882) 16-08-2016 11:36
http://oldforge.etsi.org/mantis/file_download.php?file_id=3458&type=bug
docx CR7271_7487_7488_resolution_v2.docx (160,895) 16-08-2016 15:10
http://oldforge.etsi.org/mantis/file_download.php?file_id=3463&type=bug
docx CR7271_7487_7488_resolution_v3.docx (117,315) 17-08-2016 10:27
http://oldforge.etsi.org/mantis/file_download.php?file_id=3469&type=bug
Issue History
Date ModifiedUsernameFieldChange
27-12-2015 11:16Jacob Wieland - SpirentNew Issue
18-07-2016 11:18Jens GrabowskiAssigned To => Axel Rennoch
18-07-2016 11:18Jens GrabowskiStatusnew => assigned
16-08-2016 11:36Axel RennochFile Added: CR7271_7487_7488_resolution_v1.docx
16-08-2016 11:37Axel RennochNote Added: 0014101
16-08-2016 11:39Axel RennochNote Added: 0014102
16-08-2016 11:39Axel RennochAssigned ToAxel Rennoch => Jacob Wieland - Spirent
16-08-2016 11:39Axel RennochStatusassigned => acknowledged
16-08-2016 14:24Jacob Wieland - SpirentNote Added: 0014109
16-08-2016 14:24Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Axel Rennoch
16-08-2016 14:24Jacob Wieland - SpirentStatusacknowledged => assigned
16-08-2016 15:10Axel RennochFile Added: CR7271_7487_7488_resolution_v2.docx
16-08-2016 15:10Axel RennochNote Added: 0014111
16-08-2016 15:12Axel RennochNote Added: 0014112
16-08-2016 15:12Axel RennochAssigned ToAxel Rennoch => Jacob Wieland - Spirent
16-08-2016 15:12Axel RennochStatusassigned => acknowledged
16-08-2016 15:26Axel RennochRelationship addedrelated to 0007487
17-08-2016 10:27Jacob Wieland - SpirentFile Added: CR7271_7487_7488_resolution_v3.docx
17-08-2016 10:28Jacob Wieland - SpirentNote Added: 0014125
17-08-2016 10:29Jacob Wieland - SpirentStatusacknowledged => resolved
17-08-2016 10:29Jacob Wieland - SpirentResolutionopen => fixed
17-08-2016 10:29Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
17-08-2016 10:30Jacob Wieland - SpirentAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
17-08-2016 10:30Jacob Wieland - SpirentStatusresolved => feedback
17-08-2016 10:30Jacob Wieland - SpirentResolutionfixed => reopened
17-08-2016 10:43Jacob Wieland - SpirentStatusfeedback => resolved
17-08-2016 10:43Jacob Wieland - SpirentResolutionreopened => fixed
17-08-2016 10:43Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
12-12-2016 13:32Gyorgy RethyNote Added: 0014383
12-12-2016 13:32Gyorgy RethyStatusresolved => closed
12-12-2016 13:32Gyorgy RethyFixed in Version => v4.9.1 (published 2017-05)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014101) +
+ Axel Rennoch    +
+ 16-08-2016 11:37    +
+ 		+ + + + +
+ The resolution already uses the proposed changes from CRs 7487 and 7488.
+
+
+
+ + + + + + + + + + +
+ (0014102) +
+ Axel Rennoch    +
+ 16-08-2016 11:39    +
+ 		+ + + + +
+ Please check and modify/confirm the current resolution.
+
+
+
+ + + + + + + + + + +
+ (0014109) +
+ Jacob Wieland - Spirent    +
+ 16-08-2016 14:24    +
+ 		+ + + + +
+ 1) new restrictions should be appended to the restrictions list to avoid existing references to restrictions to point to the wrong one (this should probably also be fixed for the TemplateList construct)
+
+2) MyRecordof is used several times, but not defined anywhere near the examples (last definition I say was in section 6). For consistency, it should also be renamed to MyRecordofType or MyListType.
+
+3) The IfPresent indicator template also needs the template present restriction
+
+4) in permutation, the template present restriction applies to all templates except AnyElementsOrNone
+
+
+
+ + + + + + + + + + +
+ (0014111) +
+ Axel Rennoch    +
+ 16-08-2016 15:10    +
+ 		+ + + + +
+ comments from Jacob considered in resolution draft v2
+
+
+
+ + + + + + + + + + +
+ (0014112) +
+ Axel Rennoch    +
+ 16-08-2016 15:12    +
+ 		+ + + + +
+ please check/confirm resolution v2 and assign to György
+
+
+
+ + + + + + + + + + +
+ (0014125) +
+ Jacob Wieland - Spirent    +
+ 17-08-2016 10:28    +
+ 		+ + + + +
+ I have added a definition for MyRecordofType and also deleted the restriction for if present again, because, thinking about it some more, it doesn't really hurt to use the ifpresent indicator on a non-present template (here, the ifpresent simply does not have any additional effect).
+
+
+
+ + + + + + + + + + +
+ (0014383) +
+ Gyorgy Rethy    +
+ 12-12-2016 13:32    +
+ 		+ + + + +
+ Added too draft V4.8.2
+
+ + diff --git a/docs/mantis/CR7272.md b/docs/mantis/CR7272.md new file mode 100644 index 0000000000000000000000000000000000000000..51630e60a15581636cd415a3ab8706e7f9ec3f99 --- /dev/null +++ b/docs/mantis/CR7272.md @@ -0,0 +1,97 @@ + + + + + + + + + + + + + 0007272: matching symbols should be uniformly formatted - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007272Part 01: TTCN-3 Core LanguageEditorialpublic27-12-2015 11:1905-01-2016 15:57
ReporterJacob Wieland - Spirent 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.7.1 (published 2015-06) 
Target Versionv4.8.1 (published 2016-07)Fixed in Versionv4.8.1 (published 2016-07) 
Clause Reference(s)whole standard
Source (company - Author)Testing Technologies - Jacob Wieland
Summary0007272: matching symbols should be uniformly formatted
DescriptionThe symbols Omit, AnyElementsOrNone, AnyValueOrNone, AnyValue, AnyElement, IfPresent, Subset, Superset, Complement should all be written in the same style, probably italic. At the moment, it varies between italic and non-italic.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
27-12-2015 11:19Jacob Wieland - SpirentNew Issue
27-12-2015 12:59Jacob Wieland - SpirentNote Added: 0013649
27-12-2015 12:59Jacob Wieland - SpirentStatusnew => resolved
27-12-2015 12:59Jacob Wieland - SpirentResolutionopen => fixed
27-12-2015 12:59Jacob Wieland - SpirentProduct Versionv4.8.1 (published 2016-07) => v4.7.1 (published 2015-06)
27-12-2015 12:59Jacob Wieland - SpirentTarget Versionv4.9.1 (published 2017-05) => v4.8.1 (published 2016-07)
05-01-2016 15:57Gyorgy RethyNote Added: 0013661
05-01-2016 15:57Gyorgy RethyStatusresolved => closed
05-01-2016 15:57Gyorgy RethyAssigned To => Gyorgy Rethy
05-01-2016 15:57Gyorgy RethyFixed in Version => v4.8.1 (published 2016-07)
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0013649) +
+ Jacob Wieland - Spirent    +
+ 27-12-2015 12:59    +
+ 		+ + + + +
+ resolved in latest draft for vs 4.7.4
+
+
+
+ + + + + + + + + + +
+ (0013661) +
+ Gyorgy Rethy    +
+ 05-01-2016 15:57    +
+ 		+ + + + +
+ All non-example, BNF or string occurances are changed to italic. Implemented in draft V4.7.5.
+
+ + diff --git a/docs/mantis/CR7288.md b/docs/mantis/CR7288.md new file mode 100644 index 0000000000000000000000000000000000000000..6821baaecbe46e697cd89ba8b3d4f9b858662aa9 --- /dev/null +++ b/docs/mantis/CR7288.md @@ -0,0 +1,378 @@ + + + + + + + + + + + + + 0007288: Not described use cases for optional attribute - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007288Part 01: TTCN-3 Core LanguageClarificationpublic06-01-2016 11:4912-12-2016 11:06
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.7.1 (published 2015-06) 
Target Versionv4.9.1 (published 2017-05)Fixed in Versionv4.9.1 (published 2017-05) 
Clause Reference(s)6.2.3, 27.7, 3.1
Source (company - Author)Elvior
Summary0007288: Not described use cases for optional attribute
DescriptionThe current rules for the optional attribute describe very well the situation when the RHS of an assignment contains a value or field list (6.2.3).
+
+However, other assignments of a record (or set) value are possible:
+a) a direct assignment (either from a function or a different record), e.g.:
+type record R {
+  integer field1 optional,
+  integer field2 optional
+}
+...
+var R v_var1 := { 1, - };
+var R v_var2 with { optional "implicit omit" };
+v_var2 := v_var1; // will we get { 1, omit } or { 1, - }?
+
+b) only individual fields are assigned
+var R v_var3 with { optional "implicit omit" };
+// what is the value now? uninitialized or {omit, omit}?
+v_var3.field1 := 1; // is the value of v_var3 { 1, omit } or { 1, - }?
+
+The specification doesn't provide any examples on how to handle these situations. The rules of 27.7 seem to point in the direction of inserting the omit symbol, but e.g. the note 2 in the section on partially defined values in 3.1 mentions the list syntax specifically.
+
+Proposal: Add rules/notes/examples describing TTCN-3 behaviour in the above mentioned cases.
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0007453closed Gyorgy Rethy Restriction on use of optional attibutes in variables 
related to 0007473closed Gyorgy Rethy Chapter 6.2.1 inconsitencies in optionial attribute "explicit omit" 
Attached Filesdocx CR_7288.docx (20,572) 19-07-2016 09:58
http://oldforge.etsi.org/mantis/file_download.php?file_id=3415&type=bug
docx CR7288_v2.docx (159,145) 20-07-2016 09:10
http://oldforge.etsi.org/mantis/file_download.php?file_id=3421&type=bug
Issue History
Date ModifiedUsernameFieldChange
06-01-2016 11:49Tomas UrbanNew Issue
07-01-2016 08:50Gyorgy RethyTarget Version => v4.6.2 (interim 2014)
18-07-2016 11:13Jens GrabowskiAssigned To => Kristóf Szabados
18-07-2016 11:13Jens GrabowskiStatusnew => assigned
18-07-2016 11:15Jens GrabowskiNote Added: 0013976
18-07-2016 15:00Kristóf SzabadosNote Added: 0013982
18-07-2016 15:31Kristóf SzabadosAssigned ToKristóf Szabados => Tomas Urban
18-07-2016 15:59Tomas UrbanRelationship addedrelated to 0007453
18-07-2016 16:05Tomas UrbanNote Added: 0013983
18-07-2016 16:05Tomas UrbanAssigned ToTomas Urban => Kristóf Szabados
19-07-2016 09:58Kristóf SzabadosFile Added: CR_7288.docx
19-07-2016 09:59Kristóf SzabadosAssigned ToKristóf Szabados => Tomas Urban
19-07-2016 10:05Kristóf SzabadosNote Added: 0013985
19-07-2016 10:05Kristóf SzabadosStatusassigned => feedback
20-07-2016 09:10Kristóf SzabadosFile Added: CR7288_v2.docx
20-07-2016 13:52Thilo LauerNote Added: 0014008
21-07-2016 08:12Tomas UrbanNote Added: 0014017
21-07-2016 08:19Tomas UrbanNote Added: 0014018
21-07-2016 08:19Tomas UrbanAssigned ToTomas Urban => Kristóf Szabados
21-07-2016 08:19Tomas UrbanStatusfeedback => assigned
22-07-2016 13:50Kristóf SzabadosNote Added: 0014039
22-07-2016 13:50Kristóf SzabadosStatusassigned => resolved
22-07-2016 13:50Kristóf SzabadosResolutionopen => fixed
22-07-2016 13:50Kristóf SzabadosAssigned ToKristóf Szabados => Gyorgy Rethy
17-08-2016 05:26Kristóf SzabadosRelationship addedrelated to 0007473
17-08-2016 10:52Jacob Wieland - SpirentStatusresolved => feedback
17-08-2016 10:52Jacob Wieland - SpirentResolutionfixed => reopened
17-08-2016 10:52Jacob Wieland - SpirentTarget Versionv4.6.2 (interim 2014) => v4.9.1 (published 2017-05)
17-08-2016 10:54Jacob Wieland - SpirentStatusfeedback => resolved
17-08-2016 10:54Jacob Wieland - SpirentResolutionreopened => fixed
12-12-2016 11:06Gyorgy RethyNote Added: 0014378
12-12-2016 11:06Gyorgy RethyStatusresolved => closed
12-12-2016 11:06Gyorgy RethyFixed in Version => v4.9.1 (published 2017-05)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0013976) +
+ Jens Grabowski    +
+ 18-07-2016 11:15    +
+ 		+ + + + +
+ Majority for
+
+a) v_var2 := v_var1; // will we get { 1, omit }
+
+b) v_var3.field1 := 1; // is the value of v_var3 { 1, omit }
+
+
+
+ + + + + + + + + + +
+ (0013982) +
+ Kristóf Szabados    +
+ 18-07-2016 15:00    +
+ 		+ + + + +
+ As far as I understand this usage against the standard.
+In version 4.8.1 (the latest I can reach) optional attributes can not be associated to variables.
+
+27.7 starts with
+"The optional attribute can be used to indicate that optional fields of constants, module parameters or templates of record and set types are implicitly set to omit."
+
+restriction "a" in this section explicitly states that variables can not be associated with optional attributes:
+"Data type, port type, procedure signature and variable definitions and import statements shall not have an optional attribute associated to them directly"
+
+
+
+ + + + + + + + + + +
+ (0013983) +
+ Tomas Urban    +
+ 18-07-2016 16:05    +
+ 		+ + + + +
+ I created a new CR regarding this issue (0007453). Regardless of the resolution of this CR, the first issue has to be still addressed as constants, templates and module parameters can be initialized without using value list or assignment notation.
+
+
+
+ + + + + + + + + + +
+ (0013985) +
+ Kristóf Szabados    +
+ 19-07-2016 10:05    +
+ 		+ + + + +
+ after separating the issue of variables into a new CR
+"v_var2 := v_var1; // will we get { 1, omit }" sounds good (constants/templates/moduleparameters)
+
+
+
+ + + + + + + + + + +
+ (0014008) +
+ Thilo Lauer    +
+ 20-07-2016 13:52    +
+ 		+ + + + +
+ It seems that there is a general misunderstanding of (-) and omit in this CR:
+(-) in current TTCN-3 is a "skip this assignment" symbol and no(!) value that can be stored e.g. in a variable!
+
+omit is a special value that can be stored e.g. in a template variable!
+
+Therefore a variable can never(!) have a "value" { 1, - } !!!
+
+The variable "value" here can only be { 1, omit } or { 1, <unbound> }
+or it can have a template "value" or a value "value":
+{ 1, ? } or { 1, 99 }
+
+
+
+ + + + + + + + + + +
+ (0014017) +
+ Tomas Urban    +
+ 21-07-2016 08:12    +
+ 		+ + + + +
+ The skip symbol is used as <unbound> or UNINITIALIZED in this context. It is just shorter to write is this way.
+
+
+
+ + + + + + + + + + +
+ (0014018) +
+ Tomas Urban    +
+ 21-07-2016 08:19    +
+ 		+ + + + +
+ The last proposal solves the first issue. The solution for the second issue is dependent on the resolution of 0007453. If it allows to use optional attributes for variables, the proposal has to be extended. Otherwise, you can mark te CR as resolved.
+
+
+
+ + + + + + + + + + +
+ (0014039) +
+ Kristóf Szabados    +
+ 22-07-2016 13:50    +
+ 		+ + + + +
+ The first issue was corrected.
+The second should be considered when CR 7453 is handled.
+
+
+
+ + + + + + + + + + +
+ (0014378) +
+ Gyorgy Rethy    +
+ 12-12-2016 11:06    +
+ 		+ + + + +
+ Added to V4.8.2
+
+ + diff --git a/docs/mantis/CR7291.md b/docs/mantis/CR7291.md new file mode 100644 index 0000000000000000000000000000000000000000..d0aa888ff6da3494a20b7e6c2ef2482e878faa73 --- /dev/null +++ b/docs/mantis/CR7291.md @@ -0,0 +1,132 @@ + + + + + + + + + + + + + 0007291: Update introduction text - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 07: Using ASN.1 with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007291Part 07: Using ASN.1 with TTCN-3Editorialpublic07-01-2016 13:2715-12-2016 15:19
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.5.1 (published 2013-04) 
Target Versionv4.6.1 (published 2017-05)Fixed in Versionv4.6.1 (published 2017-05) 
Clause Reference(s)4 Introduction
Source (company - Author)L.M.Ericsson
Summary0007291: Update introduction text
Description- Add references to parts for IDL and XSD (JSON) mappings
+- Unify introduction text of with Parts 8,9 & 11
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc es_20187307v040501p-CR7291.doc (145,408) 19-08-2016 13:49
http://oldforge.etsi.org/mantis/file_download.php?file_id=3500&type=bug
Issue History
Date ModifiedUsernameFieldChange
07-01-2016 13:27Gyorgy RethyNew Issue
07-01-2016 13:30Gyorgy RethyProduct Version => v4.6.1 (published 2017-05)
07-01-2016 13:30Gyorgy RethyTarget Version => v4.7.1 (published 2018-05)
07-01-2016 13:30Gyorgy RethyDescription Updatedbug_revision_view_page.php?rev_id=271#r271
07-01-2016 13:30Gyorgy RethyProduct Versionv4.6.1 (published 2017-05) => v4.5.1 (published 2013-04)
18-07-2016 10:56Jens GrabowskiAssigned To => Axel Rennoch
18-07-2016 10:56Jens GrabowskiStatusnew => assigned
19-08-2016 13:49Axel RennochFile Added: es_20187307v040501p-CR7291.doc
19-08-2016 13:53Axel RennochNote Added: 0014180
19-08-2016 13:53Axel RennochAssigned ToAxel Rennoch => Kristóf Szabados
19-08-2016 13:53Axel RennochStatusassigned => confirmed
29-08-2016 15:00Kristóf SzabadosNote Added: 0014195
29-08-2016 15:00Kristóf SzabadosStatusconfirmed => resolved
29-08-2016 15:00Kristóf SzabadosFixed in Version => v4.7.1 (published 2018-05)
29-08-2016 15:00Kristóf SzabadosResolutionopen => fixed
29-08-2016 15:00Kristóf SzabadosAssigned ToKristóf Szabados => Gyorgy Rethy
15-12-2016 15:19Gyorgy RethyNote Added: 0014440
15-12-2016 15:19Gyorgy RethyStatusresolved => closed
15-12-2016 15:19Gyorgy RethyFixed in Versionv4.7.1 (published 2018-05) => v4.6.1 (published 2017-05)
15-12-2016 15:19Gyorgy RethyTarget Versionv4.7.1 (published 2018-05) => v4.6.1 (published 2017-05)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014180) +
+ Axel Rennoch    +
+ 19-08-2016 13:53    +
+ 		+ + + + +
+ updated reference and introduction sections, please check/modifiy and assign to György (rapporteur)
+
+
+
+ + + + + + + + + + +
+ (0014195) +
+ Kristóf Szabados    +
+ 29-08-2016 15:00    +
+ 		+ + + + +
+ Looks good to me.
+
+
+
+ + + + + + + + + + +
+ (0014440) +
+ Gyorgy Rethy    +
+ 15-12-2016 15:19    +
+ 		+ + + + +
+ Added to draft V4.6.2
+
+ + diff --git a/docs/mantis/CR7292.md b/docs/mantis/CR7292.md new file mode 100644 index 0000000000000000000000000000000000000000..b5a7cc407503e5d8e2399b815fd335654ecbbc66 --- /dev/null +++ b/docs/mantis/CR7292.md @@ -0,0 +1,100 @@ + + + + + + + + + + + + + 0007292: Update introduction text - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 08: Using IDL with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007292Part 08: Using IDL with TTCN-3Editorialpublic07-01-2016 13:2915-12-2016 14:54
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.6.1 (published 2015-06) 
Target Versionv4.7.1 (published 2017-05)Fixed in Versionv4.7.1 (published 2017-05) 
Clause Reference(s)4 Introduction
Source (company - Author)L.M.Ericsson
Summary0007292: Update introduction text
Description- Add references to parts for ASN.1 and XSD (JSON) mappings
+- Add references to language extension packages
+- Update figure 1 with figure from part-7
+- Unify introduction text of with Parts 8,9 & 11
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx es_20187308v040601p-CR7292.docx (64,376) 19-08-2016 13:49
http://oldforge.etsi.org/mantis/file_download.php?file_id=3501&type=bug
Issue History
Date ModifiedUsernameFieldChange
07-01-2016 13:29Gyorgy RethyNew Issue
07-01-2016 13:31Gyorgy RethyProduct Version => v4.6.1 (published 2015-06)
07-01-2016 13:31Gyorgy RethyTarget Version => Next version (to be defined)
07-01-2016 13:38Gyorgy RethyDescription Updatedbug_revision_view_page.php?rev_id=275#r275
18-07-2016 10:56Jens GrabowskiAssigned To => Axel Rennoch
18-07-2016 10:56Jens GrabowskiStatusnew => assigned
19-08-2016 13:49Axel RennochFile Added: es_20187308v040601p-CR7292.docx
19-08-2016 13:54Axel RennochNote Added: 0014181
19-08-2016 13:54Axel RennochAssigned ToAxel Rennoch => Gyorgy Rethy
19-08-2016 13:54Axel RennochStatusassigned => confirmed
15-12-2016 14:54Gyorgy RethyNote Added: 0014439
15-12-2016 14:54Gyorgy RethyFixed in Version => v4.7.1 (published 2017-05)
15-12-2016 14:54Gyorgy RethyTarget VersionNext version (to be defined) => v4.7.1 (published 2017-05)
15-12-2016 14:54Gyorgy RethyStatusconfirmed => closed
15-12-2016 14:54Gyorgy RethyResolutionopen => fixed
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014181) +
+ Axel Rennoch    +
+ 19-08-2016 13:54    +
+ 		+ + + + +
+ updated reference and introduction sections, please check/modifiy
+
+
+
+ + + + + + + + + + +
+ (0014439) +
+ Gyorgy Rethy    +
+ 15-12-2016 14:54    +
+ 		+ + + + +
+ Added to draft v4.6.2
+
+ + diff --git a/docs/mantis/CR7293.md b/docs/mantis/CR7293.md new file mode 100644 index 0000000000000000000000000000000000000000..dc6197619a50747209a2c83ed9bc5632722d30c9 --- /dev/null +++ b/docs/mantis/CR7293.md @@ -0,0 +1,135 @@ + + + + + + + + + + + + + 0007293: Update introduction text - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007293Part 09: Using XML with TTCN-3Editorialpublic07-01-2016 13:3513-12-2016 21:28
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.7.1 (published 2016-07) 
Target Versionv4.8.1 (published 2017-05)Fixed in Versionv4.8.1 (published 2017-05) 
Clause Reference(s)4 Introduction
For STF discussion
Source (company - Author)L.M.Ericsson
Summary0007293: Update introduction text
Description- Add references to parts for IDL(JSON) mappings
+- Add references to language extension packages
+- Update figure 1 ith the figure from part 7
+- Delete compatibility requirement with ASN.1 E-XER
+- Unify introduction text of with Parts 8,9 & 11
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx es_20187309v040701p-CR7293.docx (86,092) 19-08-2016 13:49
http://oldforge.etsi.org/mantis/file_download.php?file_id=3502&type=bug
Issue History
Date ModifiedUsernameFieldChange
07-01-2016 13:35Gyorgy RethyNew Issue
07-01-2016 13:37Gyorgy RethyDescription Updatedbug_revision_view_page.php?rev_id=273#r273
18-07-2016 10:56Jens GrabowskiAssigned To => Axel Rennoch
18-07-2016 10:56Jens GrabowskiStatusnew => assigned
19-08-2016 13:49Axel RennochFile Added: es_20187309v040701p-CR7293.docx
19-08-2016 13:54Axel RennochNote Added: 0014182
19-08-2016 13:54Axel RennochAssigned ToAxel Rennoch => Kristóf Szabados
19-08-2016 13:54Axel RennochStatusassigned => confirmed
29-08-2016 15:00Kristóf SzabadosNote Added: 0014196
29-08-2016 15:00Kristóf SzabadosStatusconfirmed => resolved
29-08-2016 15:00Kristóf SzabadosFixed in Version => v4.9.1 (published 2018-05)
29-08-2016 15:00Kristóf SzabadosResolutionopen => fixed
29-08-2016 15:00Kristóf SzabadosAssigned ToKristóf Szabados => Gyorgy Rethy
13-12-2016 21:28Gyorgy RethyNote Added: 0014433
13-12-2016 21:28Gyorgy RethyStatusresolved => closed
13-12-2016 21:28Gyorgy RethyFixed in Versionv4.9.1 (published 2018-05) => v4.8.1 (published 2017-05)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014182) +
+ Axel Rennoch    +
+ 19-08-2016 13:54    +
+ 		+ + + + +
+ updated reference and introduction sections, please check/modifiy and assign to György (rapporteur)
+
+
+
+ + + + + + + + + + +
+ (0014196) +
+ Kristóf Szabados    +
+ 29-08-2016 15:00    +
+ 		+ + + + +
+ Looks good to me
+
+
+
+ + + + + + + + + + +
+ (0014433) +
+ Gyorgy Rethy    +
+ 13-12-2016 21:28    +
+ 		+ + + + +
+ Added to draft V4.7.2
+
+ + diff --git a/docs/mantis/CR7294.md b/docs/mantis/CR7294.md new file mode 100644 index 0000000000000000000000000000000000000000..79db88e8b0d79a99c3dff39e3b6e6f07056805b3 --- /dev/null +++ b/docs/mantis/CR7294.md @@ -0,0 +1,445 @@ + + + + + + + + + + + + + 0007294: default values/templates of formal parameters should live in the runs-on scope - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007294Part 01: TTCN-3 Core LanguageNew Featurepublic08-01-2016 11:1216-12-2016 22:35
ReporterJacob Wieland - Spirent 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.9.1 (published 2017-05)Fixed in Versionv4.9.1 (published 2017-05) 
Clause Reference(s)5.4.1.1, 5.4.1.2
Source (company - Author)Jacob Wieland
Summary0007294: default values/templates of formal parameters should live in the runs-on scope
DescriptionIf a function or altstep has a runs-on clause, it is assured that it can only be called from another context which has a runs-on-compatible runs-on context. That means that all members of the runs-on type of the called function/altstep also exist in the calling behavior or in the component that is started with this function/altstep.
+
+Therefore, the restriction e) in 5.4.1.1. can be relaxed insofar that default values of formal parameters may reference the members of the runs-on component type without any averse effects. This change would be backward compatible.
+
+The same, of course, is also true for restriction d) in 5.4.1.2.
Steps To Reproducetype component A {
+  var integer i := 0;
+}
+
+type component B extends A {
+  var integer j;
+}
+
+function f(integer x := i + 1) runs on A {
+  if (x > i) {
+    ...
+  }
+}
+
+function g() runs on B {
+  f(-);
+  B.create.start(f(-));
+}
+
+ 
Additional InformationThis feature was inspired by a use-case where an additional parameter was introduced later on but for backward compatibility reasons was to be filled per default with the value of a component variable which was previously used in its place.
TagsNo tags attached.
Relationships
related to 0007454closed Jens Grabowski Part 04: TTCN-3 Operational Semantics Operational semantics for default parameters 
related to 0007573closed Gyorgy Rethy Ext Pack: Advanced Parametrization (ES 202 784) Default types shall not refer to value parameters 
Attached Filesdocx CR7294-1.docx (29,215) 19-07-2016 08:26
http://oldforge.etsi.org/mantis/file_download.php?file_id=3414&type=bug
docx CR7294-2.docx (32,715) 20-07-2016 10:46
http://oldforge.etsi.org/mantis/file_download.php?file_id=3422&type=bug
docx CR7294-3.docx (27,828) 20-07-2016 12:36
http://oldforge.etsi.org/mantis/file_download.php?file_id=3425&type=bug
Issue History
Date ModifiedUsernameFieldChange
08-01-2016 11:12Jacob Wieland - SpirentNew Issue
18-07-2016 10:55Jens GrabowskiAssigned To => Tomas Urban
18-07-2016 10:55Jens GrabowskiStatusnew => assigned
19-07-2016 08:26Tomas UrbanFile Added: CR7294-1.docx
19-07-2016 08:44Tomas UrbanRelationship addedrelated to 0007454
19-07-2016 08:46Tomas UrbanNote Added: 0013984
19-07-2016 08:46Tomas UrbanAssigned ToTomas Urban => Jacob Wieland - Spirent
19-07-2016 12:30Jacob Wieland - SpirentNote Added: 0013988
19-07-2016 12:30Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Jens Grabowski
19-07-2016 15:00Jens GrabowskiNote Added: 0013990
19-07-2016 15:01Jens GrabowskiAssigned ToJens Grabowski => Tomas Urban
20-07-2016 10:46Tomas UrbanFile Added: CR7294-2.docx
20-07-2016 10:48Tomas UrbanNote Added: 0014000
20-07-2016 10:48Tomas UrbanAssigned ToTomas Urban => Jacob Wieland - Spirent
20-07-2016 10:48Tomas UrbanStatusassigned => confirmed
20-07-2016 12:36Jacob Wieland - SpirentFile Added: CR7294-3.docx
20-07-2016 12:37Jacob Wieland - SpirentNote Added: 0014006
20-07-2016 12:38Jacob Wieland - SpirentStatusconfirmed => assigned
20-07-2016 12:38Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Tomas Urban
20-07-2016 12:38Jacob Wieland - SpirentStatusassigned => confirmed
20-07-2016 16:18Tomas UrbanNote Added: 0014013
20-07-2016 16:19Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
20-07-2016 16:19Tomas UrbanStatusconfirmed => resolved
17-08-2016 11:13Jacob Wieland - SpirentProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
17-08-2016 11:59Jacob Wieland - SpirentStatusresolved => feedback
17-08-2016 11:59Jacob Wieland - SpirentResolutionopen => reopened
17-08-2016 11:59Jacob Wieland - SpirentTarget Version => v4.9.1 (published 2017-05)
17-08-2016 12:00Jacob Wieland - SpirentStatusfeedback => resolved
17-08-2016 12:00Jacob Wieland - SpirentFixed in Version => v4.9.1 (published 2017-05)
17-08-2016 12:00Jacob Wieland - SpirentResolutionreopened => fixed
13-12-2016 07:48Gyorgy RethyNote Added: 0014400
13-12-2016 08:15Gyorgy RethyNote Edited: 0014400bug_revision_view_page.php?bugnote_id=14400#r344
13-12-2016 08:16Gyorgy RethyStatusresolved => feedback
13-12-2016 08:16Gyorgy RethyResolutionfixed => reopened
14-12-2016 13:24Jacob Wieland - SpirentNote Added: 0014436
14-12-2016 13:24Jacob Wieland - SpirentStatusfeedback => assigned
16-12-2016 19:43Gyorgy RethyNote Added: 0014450
16-12-2016 22:32Gyorgy RethyNote Edited: 0014450bug_revision_view_page.php?bugnote_id=14450#r352
16-12-2016 22:32Gyorgy RethyRelationship addedrelated to 0007573
16-12-2016 22:35Gyorgy RethyNote Added: 0014458
16-12-2016 22:35Gyorgy RethyStatusassigned => closed
16-12-2016 22:35Gyorgy RethyResolutionreopened => fixed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0013984) +
+ Tomas Urban    +
+ 19-07-2016 08:46    +
+ 		+ + + + +
+ Resolved as proposed. Please check.
+
+
+
+ + + + + + + + + + +
+ (0013988) +
+ Jacob Wieland - Spirent    +
+ 19-07-2016 12:30    +
+ 		+ + + + +
+ In my opinion, we could also include functions with a compatible runs on(system,mtc) clause than the function with the default parameter.
+
+The reasoning behind this is the following: a default parameter is only evaluated in case that the calling context did not provide an actual parameter. Therefore, the evaluation of that default parameter can be deferred until the beginning of the called behaviour, these assignments are basically part of the behaviour block which is already running on the runs-on component.
+
+Therefore, it doesn't matter what the calling context was and it also doesn't matter whether the default parameter is blocking or has side-effects. It is clear when they are evaluated.
+
+Basically, what I'm saying is that:
+
+function f(T x := E) runs on C {
+  S1;
+  ...
+  ;Sn
+}
+
+is semantically equivalent to
+
+function f(T x) runs on C {
+  if (not isbound(x)) { x := E }
+  S1;
+  ...
+  Sn
+}
+
+and isbound(x) for an in-parameter can only be true if a - is given as actual parameter.
+
+The exception from this rule is altsteps that are used as default alts, where, of course, all the restrictions applied for the local variable initializations also must apply to the default values (no side-effects, no blocking).
+
+
+
+ + + + + + + + + + +
+ (0013990) +
+ Jens Grabowski    +
+ 19-07-2016 15:00    +
+ 		+ + + + +
+ I agree with Jacob. Tomas, can you check the comment from Jacob. If you also agree, please adapt the proposal. Apart from possibly required changes, the proposal is ok.
+
+
+
+ + + + + + + + + + +
+ (0014000) +
+ Tomas Urban    +
+ 20-07-2016 10:48    +
+ 		+ + + + +
+ Updated as proposed: the sentence concerning the functions was removed and a new rule was added to the chapter on altsteps (operations with side effects)
+
+Please review.
+
+
+
+ + + + + + + + + + +
+ (0014006) +
+ Jacob Wieland - Spirent    +
+ 20-07-2016 12:37    +
+ 		+ + + + +
+ reformulated the restrictions
+
+added sentences when these default expressions are evaluated
+
+please review
+
+
+
+ + + + + + + + + + +
+ (0014013) +
+ Tomas Urban    +
+ 20-07-2016 16:18    +
+ 		+ + + + +
+ Fine by me. The third proposal is acceptable as the solution of the CR.
+
+
+
+ + + + + + + + + + +
+ (0014400) +
+ Gyorgy Rethy    +
+ 13-12-2016 07:48    +
(edited on: 13-12-2016 08:15)
+ 		+ + + + +
+ Added to draft V4.8.2 as in the CR.
+
+However the meaning of "any following" is unclear to me in "shall not refer to other parameters of the same or any following parameter list." (in restriction d of clauses 5.4.1.1 and 5.4.1.2). A testcase/function/altstep have a list of formal parameters; this is "the same" parameter list as in which the default value is defined; but what is "the following" parameter list?
+
+
+
+
+
+ + + + + + + + + + +
+ (0014436) +
+ Jacob Wieland - Spirent    +
+ 14-12-2016 13:24    +
+ 		+ + + + +
+ The restriction is intended to avoid situations like this:
+
+type component C {
+  var template integer b := (0 .. 100);
+}
+
+type record Pair(template integer a, template integer b) {
+  integer first(a),
+  integer second(b)
+}
+
+function f<T := Pair(a,b)>(template integer a) runs on C {
+}
+
+Here, the default type value would reference both a variable from the runs-on component and a formal parameter from the following value parameter list.
+
+While this is, of course, a pathological case, it still needs to be restricted to not occur, in my opinion.
+
+
+
+ + + + + + + + + + +
+ (0014450) +
+ Gyorgy Rethy    +
+ 16-12-2016 19:43    +
(edited on: 16-12-2016 22:32)
+ 		+ + + + +
+ Technically correct; but this shall be added to the language extension on advanced parameterization. CR 7573 has been created and done for this purpose.
+
+
+
+
+
+ + + + + + + + + + +
+ (0014458) +
+ Gyorgy Rethy    +
+ 16-12-2016 22:35    +
+ 		+ + + + +
+ Added to draft V4.8.2 except "or any following", which has been added to the advanced parameterization package.
+
+ + diff --git a/docs/mantis/CR7353.md b/docs/mantis/CR7353.md new file mode 100644 index 0000000000000000000000000000000000000000..cd12919b50b45dede9327f0891598d2d891152aa --- /dev/null +++ b/docs/mantis/CR7353.md @@ -0,0 +1,167 @@ + + + + + + + + + + + + + 0007353: attributes should be attachable to their definition only - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007353Part 01: TTCN-3 Core LanguageNew Featurepublic18-01-2016 10:2212-12-2016 18:21
ReporterJacob Wieland - Spirent 
Assigned ToGyorgy Rethy 
PrioritynormalSeveritymajorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.9.1 (published 2017-05)Fixed in Versionv4.9.1 (published 2017-05) 
Clause Reference(s)27
Source (company - Author)Testing Technologies - Jacob Wieland
Summary0007353: attributes should be attachable to their definition only
DescriptionIt is often the case that an attribute (especially true for extension attributes, but also often for variant and display attributes) shall not be inherited by the children of a definition. At the moment, this can only be achieved by adding the attribute with some other (or non-) value for all children to avoid their inheriting the attribute from the parent.
+
+Therefore, there should be a syntactic feature, e.g. a modifier named @local for the attribute definition that has this effect. Of course, this kind of modifier would clash naturally with the override keyword and thus should not be usable alongside it (not override or not @local)
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0007448closed Gyorgy Rethy Allowing multiple encodings for TTCN-3 types 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
18-01-2016 10:22Jacob Wieland - SpirentNew Issue
11-07-2016 10:28Jacob Wieland - SpirentRelationship addedrelated to 0007448
18-07-2016 10:01Jens GrabowskiAssigned To => Tomas Urban
18-07-2016 10:01Jens GrabowskiStatusnew => assigned
16-08-2016 16:25Tomas UrbanNote Added: 0014115
16-08-2016 16:25Tomas UrbanAssigned ToTomas Urban => Jens Grabowski
16-08-2016 16:25Tomas UrbanStatusassigned => confirmed
17-08-2016 11:14Jacob Wieland - SpirentProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
17-08-2016 11:15Jacob Wieland - SpirentTarget Version => v4.9.1 (published 2017-05)
18-08-2016 10:59Jens GrabowskiAssigned ToJens Grabowski => Kristóf Szabados
18-08-2016 10:59Jens GrabowskiStatusconfirmed => assigned
18-08-2016 10:59Jens GrabowskiStatusassigned => confirmed
19-08-2016 13:34Kristóf SzabadosAssigned ToKristóf Szabados => Jacob Wieland - Spirent
19-08-2016 13:34Kristóf SzabadosStatusconfirmed => assigned
19-08-2016 15:01Jacob Wieland - SpirentNote Added: 0014186
19-08-2016 15:01Jacob Wieland - SpirentStatusassigned => confirmed
17-11-2016 09:59Jacob Wieland - SpirentNote Added: 0014291
17-11-2016 09:59Jacob Wieland - SpirentStatusconfirmed => resolved
17-11-2016 09:59Jacob Wieland - SpirentResolutionopen => fixed
17-11-2016 09:59Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
12-12-2016 18:21Gyorgy RethyNote Added: 0014394
12-12-2016 18:21Gyorgy RethyStatusresolved => closed
12-12-2016 18:21Gyorgy RethyFixed in Version => v4.9.1 (published 2017-05)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014115) +
+ Tomas Urban    +
+ 16-08-2016 16:25    +
+ 		+ + + + +
+ Resolved as a part of resolution of the related CR 0007448.
+
+
+
+ + + + + + + + + + +
+ (0014186) +
+ Jacob Wieland - Spirent    +
+ 19-08-2016 15:01    +
+ 		+ + + + +
+ please review
+
+
+
+ + + + + + + + + + +
+ (0014291) +
+ Jacob Wieland - Spirent    +
+ 17-11-2016 09:59    +
+ 		+ + + + +
+ I have reviewed that part in the document attached to the related CR and it was fine.
+
+
+
+ + + + + + + + + + +
+ (0014394) +
+ Gyorgy Rethy    +
+ 12-12-2016 18:21    +
+ 		+ + + + +
+ See resolution in CR 7448
+
+ + diff --git a/docs/mantis/CR7356.md b/docs/mantis/CR7356.md new file mode 100644 index 0000000000000000000000000000000000000000..9ee5802a2d08bd5447b3836ded36f180030818fc --- /dev/null +++ b/docs/mantis/CR7356.md @@ -0,0 +1,278 @@ + + + + + + + + + + + + + 0007356: allow bounded formal type parameters also for non component types - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Advanced Parametrization (ES 202 784)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007356Ext Pack: Advanced Parametrization (ES 202 784)New Featurepublic18-01-2016 11:0116-12-2016 11:44
ReporterJacob Wieland - Spirent 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv1.6.1 (published 2017-04) 
Target Versionv1.6.1 (published 2017-04)Fixed in Versionv1.6.1 (published 2017-04) 
TS version1.6.1
Clause Reference(s)5.4.1.5
Source (company - Author)Testing Technologies - Jacob Wieland
Summary0007356: allow bounded formal type parameters also for non component types
DescriptionAt the moment, a formal type parameter can only be given a supertype (or bound) that the actual parameter needs to conform to in case it is a component type.
+
+However, it is often the case that a generic function can only work for a certain kind of type. Other languages solve this with a feature called bounded polymorphism where the supertype of the type parameter is given in the declaration.
+
+The current approach forces the tool-providers to check for every application of a generic behavior/template whether or not the instantiation is statically correct for the given actual type parameters. Errors produced when failing that check are usually not very helpful, either, so it is very user-unfriendly by design.
+
+In the case where bounds can be given for the formal type parameters, as well, the behavior/template can be checked on its own (using the bounds as approximation) and at the points of their instantiation, only the actual parameter needs to be checked against the formal type's bound.
+
+Of course, there can still be situations where the first approach is necessary/valid (i.e. float vs. integer or charstring vs. universal charstring), but that is only the case if at least one of the formal type parameters does not have a supertype or if the type of an actual parameter can not be established (because it is an unbounded type parameter).
Steps To ReproduceTo fix this problem, restriction c) of change of section 5.4.1.5 shall be dropped.
Additional Information
TagsNo tags attached.
Relationships
related to 0005449closed Gyorgy Rethy Add mapping for parameterized ASN.1 types 
Attached Filesdocx CR7356v2.docx (157,360) 21-07-2016 10:16
http://oldforge.etsi.org/mantis/file_download.php?file_id=3429&type=bug
Issue History
Date ModifiedUsernameFieldChange
18-01-2016 11:01Jacob Wieland - SpirentNew Issue
18-03-2016 10:36Jacob Wieland - SpirentRelationship addedrelated to 0005449
18-03-2016 10:36Jacob Wieland - SpirentNote Added: 0013896
18-07-2016 10:42Jens GrabowskiAssigned To => Jens Grabowski
18-07-2016 10:42Jens GrabowskiStatusnew => assigned
20-07-2016 09:07Jens GrabowskiNote Added: 0013996
20-07-2016 09:07Jens GrabowskiAssigned ToJens Grabowski => Kristóf Szabados
20-07-2016 14:00Jens GrabowskiNote Added: 0014009
20-07-2016 14:00Jens GrabowskiAssigned ToKristóf Szabados => Jacob Wieland - Spirent
21-07-2016 10:16Jacob Wieland - SpirentFile Added: CR7356v2.docx
21-07-2016 10:16Jacob Wieland - SpirentNote Added: 0014026
21-07-2016 10:16Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Kristóf Szabados
21-07-2016 10:16Jacob Wieland - SpirentStatusassigned => confirmed
17-08-2016 11:16Jacob Wieland - SpirentProduct VersionNext version (to be defined) => v1.6.1 (published 2017-04)
17-08-2016 11:16Jacob Wieland - SpirentTarget Version => Next version (to be defined)
07-11-2016 07:35Kristóf SzabadosAssigned ToKristóf Szabados => Jacob Wieland - Spirent
07-11-2016 07:35Kristóf SzabadosStatusconfirmed => assigned
07-11-2016 07:36Kristóf SzabadosNote Added: 0014221
07-11-2016 07:36Kristóf SzabadosStatusassigned => confirmed
10-11-2016 11:57Jacob Wieland - SpirentNote Added: 0014223
10-11-2016 11:57Jacob Wieland - SpirentStatusconfirmed => resolved
10-11-2016 11:57Jacob Wieland - SpirentFixed in Version => v1.6.1 (published 2017-04)
10-11-2016 11:57Jacob Wieland - SpirentResolutionopen => fixed
10-11-2016 11:57Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
16-12-2016 11:39Gyorgy RethyNote Added: 0014443
16-12-2016 11:39Gyorgy RethyStatusresolved => closed
16-12-2016 11:39Gyorgy RethyTarget VersionNext version (to be defined) => v1.6.1 (published 2017-04)
16-12-2016 11:44Gyorgy RethyNote Edited: 0014443bug_revision_view_page.php?bugnote_id=14443#r350
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0013896) +
+ Jacob Wieland - Spirent    +
+ 18-03-2016 10:36    +
+ 		+ + + + +
+ if this restriction is lifted, the problem of proposal for CR 5449 would also be solved
+
+
+
+ + + + + + + + + + +
+ (0013996) +
+ Jens Grabowski    +
+ 20-07-2016 09:07    +
+ 		+ + + + +
+ I am fine with this proposal. Kristof please check if the resolution of this CR also solves 5449.
+
+
+
+ + + + + + + + + + +
+ (0014009) +
+ Jens Grabowski    +
+ 20-07-2016 14:00    +
+ 		+ + + + +
+ STF agreement: Jacob will propose a definition of type compatability for this package. Afterwards we check if the restriction can be relaxed to type compatability.
+
+
+
+ + + + + + + + + + +
+ (0014026) +
+ Jacob Wieland - Spirent    +
+ 21-07-2016 10:16    +
+ 		+ + + + +
+ please review
+
+
+
+ + + + + + + + + + +
+ (0014221) +
+ Kristóf Szabados    +
+ 07-11-2016 07:36    +
+ 		+ + + + +
+ The proposal looks fine by me.
+Solves a part of CR 5449
+
+
+
+ + + + + + + + + + +
+ (0014223) +
+ Jacob Wieland - Spirent    +
+ 10-11-2016 11:57    +
+ 		+ + + + +
+ please implement
+
+
+
+ + + + + + + + + + +
+ (0014443) +
+ Gyorgy Rethy    +
+ 16-12-2016 11:39    +
(edited on: 16-12-2016 11:44)
+ 		+ + + + +
+ Added to draft V1.5.2
+
+
+
+ + diff --git a/docs/mantis/CR7367.md b/docs/mantis/CR7367.md new file mode 100644 index 0000000000000000000000000000000000000000..6ec63ad39b985ce78a59c3a33dc93fa40f1db343 --- /dev/null +++ b/docs/mantis/CR7367.md @@ -0,0 +1,167 @@ + + + + + + + + + + + + + 0007367: Check the use of "may"-s in the standard - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007367Part 01: TTCN-3 Core LanguageClarificationpublic03-02-2016 12:5512-12-2016 10:26
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.8.1 (published 2016-07) 
Target Versionv4.9.1 (published 2017-05)Fixed in Versionv4.9.1 (published 2017-05) 
Clause Reference(s)all part-1
Source (company - Author)L.M.Ericsson
Summary0007367: Check the use of "may"-s in the standard
DescriptionThe standard is using "may"-s typically when allowing tool options. ETSI drafting rules allow using "should", when the implementations has an option, but the standard suggests a recommended way.
+
+Proposal: Check the "may"-s in the standard and identify a recommended way by using "should", where it is appropriate.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7367_resolution_v1.docx (1,644,743) 19-08-2016 08:32
http://oldforge.etsi.org/mantis/file_download.php?file_id=3495&type=bug
Issue History
Date ModifiedUsernameFieldChange
03-02-2016 12:55Gyorgy RethyNew Issue
18-07-2016 10:53Jens GrabowskiAssigned To => Axel Rennoch
18-07-2016 10:53Jens GrabowskiStatusnew => assigned
19-08-2016 08:32Axel RennochFile Added: CR7367_resolution_v1.docx
19-08-2016 08:36Axel RennochNote Added: 0014165
19-08-2016 08:36Axel RennochAssigned ToAxel Rennoch => Kristóf Szabados
19-08-2016 08:36Axel RennochStatusassigned => acknowledged
19-08-2016 10:07Axel RennochNote Added: 0014172
19-08-2016 10:07Axel RennochStatusacknowledged => confirmed
29-08-2016 15:10Kristóf SzabadosNote Added: 0014197
29-08-2016 15:10Kristóf SzabadosStatusconfirmed => resolved
29-08-2016 15:10Kristóf SzabadosFixed in Version => v4.10.1 (published 2018-05)
29-08-2016 15:10Kristóf SzabadosResolutionopen => fixed
29-08-2016 15:10Kristóf SzabadosAssigned ToKristóf Szabados => Gyorgy Rethy
12-12-2016 10:26Gyorgy RethyNote Added: 0014373
12-12-2016 10:26Gyorgy RethyStatusresolved => closed
12-12-2016 10:26Gyorgy RethyFixed in Versionv4.10.1 (published 2018-05) => v4.9.1 (published 2017-05)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014165) +
+ Axel Rennoch    +
+ 19-08-2016 08:36    +
+ 		+ + + + +
+ The document contained more than 400 "may"-s. I changed only six occurrences into "should". Please have a look and confirm or modify.
+
+
+
+ + + + + + + + + + +
+ (0014172) +
+ Axel Rennoch    +
+ 19-08-2016 10:07    +
+ 		+ + + + +
+ status correction
+
+
+
+ + + + + + + + + + +
+ (0014197) +
+ Kristóf Szabados    +
+ 29-08-2016 15:10    +
+ 		+ + + + +
+ looks good to me
+
+
+
+ + + + + + + + + + +
+ (0014373) +
+ Gyorgy Rethy    +
+ 12-12-2016 10:26    +
+ 		+ + + + +
+ Added to draft V4.8.2
+
+ + diff --git a/docs/mantis/CR7368.md b/docs/mantis/CR7368.md new file mode 100644 index 0000000000000000000000000000000000000000..bee37c22d3935f72a51ced23c3c1c5b418387176 --- /dev/null +++ b/docs/mantis/CR7368.md @@ -0,0 +1,167 @@ + + + + + + + + + + + + + 0007368: Check the use of "may"-s in the standard - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007368Part 09: Using XML with TTCN-3Clarificationpublic03-02-2016 12:5913-12-2016 21:53
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.8.1 (published 2017-05)Fixed in Versionv4.8.1 (published 2017-05) 
Clause Reference(s)all part-9
For STF discussion
Source (company - Author)L.M.Ericsson
Summary0007368: Check the use of "may"-s in the standard
DescriptionThe standard is using "may"-s typically when allowing tool options. ETSI drafting rules allow using "should", when the implementations has an option, but the standard suggests a recommended way.
+
+Proposal: Check the "may"-s in the standard and identify a recommended way by using "should", where it is appropriate.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0007470closed Gyorgy Rethy editorial: inconsistent namespace names 
related to 0007466closed Gyorgy Rethy editorial: indentation, hyperlink, typo fixes in part 
Attached Filesdocx es_20187309v040701p-CR7470_7466_7368.docx (606,331) 16-08-2016 16:25
http://oldforge.etsi.org/mantis/file_download.php?file_id=3465&type=bug
Issue History
Date ModifiedUsernameFieldChange
03-02-2016 12:59Gyorgy RethyNew Issue
18-07-2016 10:52Jens GrabowskiAssigned To => Kristóf Szabados
18-07-2016 10:52Jens GrabowskiStatusnew => assigned
18-07-2016 10:53Jens GrabowskiAssigned ToKristóf Szabados => Axel Rennoch
16-08-2016 16:25Axel RennochFile Added: es_20187309v040701p-CR7470_7466_7368.docx
16-08-2016 16:26Axel RennochNote Added: 0014117
16-08-2016 16:27Axel RennochRelationship addedrelated to 0007470
16-08-2016 16:27Axel RennochRelationship addedrelated to 0007466
16-08-2016 16:29Axel RennochNote Added: 0014119
16-08-2016 16:29Axel RennochAssigned ToAxel Rennoch => Kristóf Szabados
16-08-2016 16:29Axel RennochStatusassigned => acknowledged
17-08-2016 11:58Jacob Wieland - SpirentTarget Version => v4.8.1 (published 2017-05)
19-08-2016 15:19Kristóf SzabadosNote Added: 0014189
19-08-2016 15:19Kristóf SzabadosStatusacknowledged => resolved
19-08-2016 15:19Kristóf SzabadosFixed in Version => v4.9.1 (published 2018-05)
19-08-2016 15:19Kristóf SzabadosResolutionopen => fixed
19-08-2016 15:19Kristóf SzabadosAssigned ToKristóf Szabados => Gyorgy Rethy
13-12-2016 21:53Gyorgy RethyNote Added: 0014434
13-12-2016 21:53Gyorgy RethyStatusresolved => closed
13-12-2016 21:53Gyorgy RethyFixed in Versionv4.9.1 (published 2018-05) => v4.8.1 (published 2017-05)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014117) +
+ Axel Rennoch    +
+ 16-08-2016 16:26    +
+ 		+ + + + +
+ The uploaded document considers CRs 7470, 7466 and 7368.
+
+
+
+ + + + + + + + + + +
+ (0014119) +
+ Axel Rennoch    +
+ 16-08-2016 16:29    +
+ 		+ + + + +
+ Please check/confirm modifications in the uploaded document.
+
+
+
+ + + + + + + + + + +
+ (0014189) +
+ Kristóf Szabados    +
+ 19-08-2016 15:19    +
+ 		+ + + + +
+ looks good for me
+
+
+
+ + + + + + + + + + +
+ (0014434) +
+ Gyorgy Rethy    +
+ 13-12-2016 21:53    +
+ 		+ + + + +
+ Added to draft V4.7.2
+
+ + diff --git a/docs/mantis/CR7372.md b/docs/mantis/CR7372.md new file mode 100644 index 0000000000000000000000000000000000000000..8bef337aadb24170525f5c2cd12bf88675f5b1aa --- /dev/null +++ b/docs/mantis/CR7372.md @@ -0,0 +1,344 @@ + + + + + + + + + + + + + 0007372: types/variables for startable/executable behaviors should be possible - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Behaviour Types (ES 202 785)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007372Ext Pack: Behaviour Types (ES 202 785)New Featurepublic04-02-2016 10:5416-12-2016 22:26
ReporterJacob Wieland - Spirent 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionopen 
PlatformOSOS Version
Product Versionv1.4.1 (published 2015-06) 
Target Versionv1.5.1 (published 2017-08)Fixed in Versionv1.5.1 (published 2017-08) 
Clause Reference(s)5, 6
Source (company - Author)Testing Technologies - Jacob Wieland
Summary0007372: types/variables for startable/executable behaviors should be possible
DescriptionAt the moment, it is possible to define behavior types for testcase, altstep and function. However, what is not possible to store a reference (and pass as a parameter) to such an entity paired with an actual parameter list as used by the start and execute operations.
+
+To be more concrete, at the moment, one can write:
+
+c.start(f(p1,...,pn));
+
+What should be possible should be:
+
+var T x := f(p1,...,pn);
+...
+c.start(x);
+
+where T must be some special behavior type which can be only restricted by runs on, system and mtc clauses.
+
+The first idea that comes into mind would be something like this:
+
+type function F runs on C;
+type altstep A runs on C;
+
+Entities of such types are all parameterized function/altstep references (respectively) with a runs-on compatible runs on clause (and mtc/system compatible mtc/system clauses). Such entities can be given to the start operation as parameter if the same requirements are fulfilled, i.e. runs-on compatibility with the type of the component to be started and mtc/system compatibility with the mtc/system context.
+
+Likewise, we would introduce:
+
+type testcase T runs on C system S;
+
+Entities of such types would be all parameterized testcase references with compatible runs on and system clauses. Such entities can be given to the execute operation during control part execution.
+
+
Steps To Reproduce
Additional InformationUse case.
+
+type component C {}
+type function Behavior runs on C;
+type record of C Components;
+type record of Behavior Behaviors;
+
+function handleParallel(Components v_components, Behaviors v_behaviors) {
+  for (var integer i := 0; i < lengthof(v_components); i := i + 1) {
+    v_components[i].start(v_behaviors[i]);
+  }
+  for (var integer i := 0; i < lengthof(v_components); i := i + 1) {
+    v_components[i].done;
+  }
+}
+
+Or another way:
+
+type record of record {
+  C comp,
+  Behavior behavior
+} Startables;
+
+function handle(Startables v_startables) {
+  for (var integer i := 0; i < lengthof(v_startables); i := i + 1) {
+    v_startables[i].comp.start(v_startables[i].behavior);
+  }
+  for (var integer i := 0; i < lengthof(v_startables); i := i + 1) {
+    v_startables[i].comp.done;
+  }
+}
+
+Which then can be used in a way like this:
+
+handle({ { c1, behavior1(p1,...,pn) },
+         { c2, behavior1(q1,...,qn) },
+         { c3, behavior2(...) } });
+
+At the moment, this is only possible by introducing a function for each function which wraps the start statement and then giving the function call of the wrapper-function as lazy parameter to the handle function.
+
+
TagsNo tags attached.
Relationships
Attached Filesdoc CR7372.doc (1,134,592) 19-07-2016 10:39
http://oldforge.etsi.org/mantis/file_download.php?file_id=3416&type=bug
doc CR7372v2.doc (1,142,272) 20-07-2016 11:38
http://oldforge.etsi.org/mantis/file_download.php?file_id=3424&type=bug
Issue History
Date ModifiedUsernameFieldChange
04-02-2016 10:54Jacob Wieland - SpirentNew Issue
18-07-2016 10:51Jens GrabowskiAssigned To => Jacob Wieland - Spirent
18-07-2016 10:51Jens GrabowskiStatusnew => assigned
19-07-2016 10:39Jacob Wieland - SpirentFile Added: CR7372.doc
19-07-2016 10:40Jacob Wieland - SpirentNote Added: 0013986
19-07-2016 10:40Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Jens Grabowski
19-07-2016 10:40Jacob Wieland - SpirentStatusassigned => confirmed
19-07-2016 14:17Jens GrabowskiNote Added: 0013989
19-07-2016 14:18Jens GrabowskiAssigned ToJens Grabowski => Tomas Urban
19-07-2016 14:18Jens GrabowskiStatusconfirmed => assigned
19-07-2016 14:18Jens GrabowskiStatusassigned => confirmed
20-07-2016 09:49Tomas UrbanNote Added: 0013997
20-07-2016 09:49Tomas UrbanAssigned ToTomas Urban => Jens Grabowski
20-07-2016 10:57Jens GrabowskiNote Added: 0014003
20-07-2016 10:57Jens GrabowskiAssigned ToJens Grabowski => Jacob Wieland - Spirent
20-07-2016 10:57Jens GrabowskiStatusconfirmed => assigned
20-07-2016 11:31Jacob Wieland - SpirentFile Added: CR7372v2.doc
20-07-2016 11:32Jacob Wieland - SpirentNote Added: 0014004
20-07-2016 11:32Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Tomas Urban
20-07-2016 11:32Jacob Wieland - SpirentStatusassigned => confirmed
20-07-2016 11:38Jacob Wieland - SpirentFile Deleted: CR7372v2.doc
20-07-2016 11:38Jacob Wieland - SpirentFile Added: CR7372v2.doc
21-07-2016 08:09Tomas UrbanNote Added: 0014016
21-07-2016 08:10Tomas UrbanAssigned ToTomas Urban => Jens Grabowski
21-07-2016 08:10Tomas UrbanStatusconfirmed => resolved
16-12-2016 22:26Gyorgy RethyNote Added: 0014457
16-12-2016 22:26Gyorgy RethyAssigned ToJens Grabowski => Gyorgy Rethy
16-12-2016 22:26Gyorgy RethyStatusresolved => closed
16-12-2016 22:26Gyorgy RethyFixed in Version => v1.5.1 (published 2017-08)
16-12-2016 22:26Gyorgy RethyTarget Versionv1.6.1 (published 2018-05) => v1.5.1 (published 2017-08)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0013986) +
+ Jacob Wieland - Spirent    +
+ 19-07-2016 10:40    +
+ 		+ + + + +
+ please review uploaded proposal
+
+
+
+ + + + + + + + + + +
+ (0013989) +
+ Jens Grabowski    +
+ 19-07-2016 14:17    +
+ 		+ + + + +
+ Maybe "supended" is better than "deferred". I need a further opinion on this proposal. Tomas, please check.
+
+
+
+ + + + + + + + + + +
+ (0013997) +
+ Tomas Urban    +
+ 20-07-2016 09:49    +
+ 		+ + + + +
+ I would prefer "deferred", because it is closer to the way how the pointer is actually used. "Suspended" might be understood so that the variable contains a pointer to a single function entity that has already started and then has been paused.
+
+The restrictions on the function instance in 6.2.13.4 are currently empty, but I would add some:
+a) For the actual parameters of a function, restrictions from 21.3.2 of the core language specification shall apply
+b) For the actual parameters of an alstep, restrictions from 20.5.2 of the core language specification shall apply
+c) For the actual parameters of a test case, restriction from 26.1 of the core language specification shall apply
+d) Only variables defined in the root of the control block can be used as the actual out and inout parameters of a deferred testcase behaviour value.
+
+I would also like to see a rule saying when exactly the actual in parameters are evaluated. In my opinion, it should be at the time of creation of the deferred behaviour value.
+
+
+
+ + + + + + + + + + +
+ (0014003) +
+ Jens Grabowski    +
+ 20-07-2016 10:57    +
+ 		+ + + + +
+ Jacob,
+
+can you check the comment from Tomas and comment or update the proposal accordingly.
+
+
+
+ + + + + + + + + + +
+ (0014004) +
+ Jacob Wieland - Spirent    +
+ 20-07-2016 11:32    +
+ 		+ + + + +
+ please review the new version
+
+
+
+ + + + + + + + + + +
+ (0014016) +
+ Tomas Urban    +
+ 21-07-2016 08:09    +
+ 		+ + + + +
+ No issues found. The proposal can be added to the next version of the advanced parameterization specification.
+
+
+
+ + + + + + + + + + +
+ (0014457) +
+ Gyorgy Rethy    +
+ 16-12-2016 22:26    +
+ 		+ + + + +
+ Added to draft V1.4.2
+
+ + diff --git a/docs/mantis/CR7390.md b/docs/mantis/CR7390.md new file mode 100644 index 0000000000000000000000000000000000000000..fc2d6e42ffd317d184148a6a22db5c40b59b619c --- /dev/null +++ b/docs/mantis/CR7390.md @@ -0,0 +1,186 @@ + + + + + + + + + + + + + 0007390: Misleading variable name - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007390Part 01: TTCN-3 Core LanguageEditorialpublic08-02-2016 10:0509-12-2016 15:07
ReporterBogdan Stanca-Kaposta 
Assigned ToGyorgy Rethy 
PrioritynormalSeveritytrivialReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.7.1 (published 2015-06) 
Target Versionv4.9.1 (published 2017-05)Fixed in Versionv4.9.1 (published 2017-05) 
Clause Reference(s)19.3.1 The Select case statement
Source (company - Author)STF 487
Summary0007390: Misleading variable name
DescriptionOn the Example at page 158, the variable name "myTempVar" may be misleading (since may be interpreted as my template variable).
+
+Conform 15.9 Match Operation the first parameter of the match operator is the expression and second the template.
Steps To Reproduce
Additional Informationpage 158
+
+// the above select statement is equivalent to the following nested if-else statement.
+ // Note: the following textual replacement of the select-case statement is described in
+ // the operational semantics of TTCN-3.
+ {
+ var charstring myTempVar := MyModulePar;
+ if (match(myTempVar, "firstValue")
+ {
+ log ("The first branch is selected");
+ }
+ else if (match(myTempVar, MyCharVar) or match(myTempVar, MyCharConst))
+ {
+ log ("The second branch is selected");
+ }
+ else
+ {
+ log ("The value of the module parameter MyModulePar is selected");
+ }
+ }
TagsNo tags attached.
Relationships
Attached Filesdocx CR7390_resolution_v1.docx (80,611) 15-08-2016 09:45
http://oldforge.etsi.org/mantis/file_download.php?file_id=3439&type=bug
docx CR7390_resolution_v2.docx (61,851) 09-11-2016 07:38
http://oldforge.etsi.org/mantis/file_download.php?file_id=3513&type=bug
Issue History
Date ModifiedUsernameFieldChange
08-02-2016 10:05Bogdan Stanca-KapostaNew Issue
18-07-2016 10:47Jens GrabowskiNote Added: 0013975
18-07-2016 10:47Jens GrabowskiAssigned To => Axel Rennoch
18-07-2016 10:47Jens GrabowskiStatusnew => assigned
15-08-2016 09:45Axel RennochFile Added: CR7390_resolution_v1.docx
15-08-2016 09:46Axel RennochNote Added: 0014059
15-08-2016 09:46Axel RennochAssigned ToAxel Rennoch => Gyorgy Rethy
15-08-2016 09:46Axel RennochStatusassigned => confirmed
17-08-2016 11:58Jacob Wieland - SpirentTarget Version => v4.9.1 (published 2017-05)
09-11-2016 07:38Gyorgy RethyFile Added: CR7390_resolution_v2.docx
09-11-2016 07:38Gyorgy RethyNote Added: 0014222
09-11-2016 07:38Gyorgy RethyStatusconfirmed => resolved
09-11-2016 07:38Gyorgy RethyFixed in Version => v4.9.1 (published 2017-05)
09-11-2016 07:38Gyorgy RethyResolutionopen => fixed
09-12-2016 15:07Gyorgy RethyNote Added: 0014366
09-12-2016 15:07Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0013975) +
+ Jens Grabowski    +
+ 18-07-2016 10:47    +
+ 		+ + + + +
+ @Axel: if ok, resolve and assign to György for integration.
+
+
+
+ + + + + + + + + + +
+ (0014059) +
+ Axel Rennoch    +
+ 15-08-2016 09:46    +
+ 		+ + + + +
+ Please have a look to the resolution.
+
+
+
+ + + + + + + + + + +
+ (0014222) +
+ Gyorgy Rethy    +
+ 09-11-2016 07:38    +
+ 		+ + + + +
+ variable name is also replaced in the first if.
+
+
+
+ + + + + + + + + + +
+ (0014366) +
+ Gyorgy Rethy    +
+ 09-12-2016 15:07    +
+ 		+ + + + +
+ Added to draft V4.8.2
+
+ + diff --git a/docs/mantis/CR7421.md b/docs/mantis/CR7421.md new file mode 100644 index 0000000000000000000000000000000000000000..5ffb939765634eb7c7018856ee8bd7c9353686a7 --- /dev/null +++ b/docs/mantis/CR7421.md @@ -0,0 +1,256 @@ + + + + + + + + + + + + + 0007421: How to achieve full backward compatibility in case of element- and/or type-substitution - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007421Part 09: Using XML with TTCN-3New Featurepublic01-03-2016 13:1413-12-2016 17:05
ReporterThilo Lauer 
Assigned ToGyorgy Rethy 
PriorityhighSeveritymajorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.8.1 (published 2017-05)Fixed in Versionv4.8.1 (published 2017-05) 
Clause Reference(s)ES 201 873-9, chapter 8: Substitutions
For STF discussion
Source (company - Author)Devoteam, Thilo Lauer
Summary0007421: How to achieve full backward compatibility in case of element- and/or type-substitution
DescriptionWe propose that compiling 'with element- and/or type-substitution enabled' the compiler shall be fully backward compatibe i.e. the compiler shall be able to compile suites containing templates (and field access paths) that were written for non-element / non-type substiution.
+
+This means, that suites can be written, that can contain a mixture of "non-substituion" templates and "substitution" templates without any need to change older code in a testsuite. Even if both options (element and type substitution) are switched on older testsuites, that do not use substitution, can be compiled.
+
+As far as we can see our proposal is a more general and more flexible solution as the one proposed in Mantis, CR7239: "Change element substitution generation rules to support backward compatibility"
+
+Please see uploaded document "2016-02-26_Devoteam proposal for backward compatibility in case of element- and or type-substitution.docx" for details
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0007493closed Gyorgy Rethy Part 01: TTCN-3 Core Language Add Wrapper-Union capability to the standard 
related to 0007239closed Gyorgy Rethy Part 09: Using XML with TTCN-3 Change element substitution generation rules to support backward compatibility 
Attached Filesdocx 2016-02-26_Devoteam proposal for backward compatibility in case of element- and or type-substitution.docx (1,389,136) 01-03-2016 13:14
http://oldforge.etsi.org/mantis/file_download.php?file_id=3402&type=bug
docx CR7421.docx (167,200) 19-08-2016 13:23
http://oldforge.etsi.org/mantis/file_download.php?file_id=3498&type=bug
Issue History
Date ModifiedUsernameFieldChange
01-03-2016 13:14Thilo LauerNew Issue
01-03-2016 13:14Thilo LauerFile Added: 2016-02-26_Devoteam proposal for backward compatibility in case of element- and or type-substitution.docx
18-03-2016 10:44Jacob Wieland - SpirentNote Added: 0013897
08-04-2016 11:34Gyorgy RethyNote Added: 0013930
08-04-2016 11:34Gyorgy RethyNote Edited: 0013930bug_revision_view_page.php?bugnote_id=13930#r289
07-06-2016 13:34Gyorgy RethyNote Edited: 0013930bug_revision_view_page.php?bugnote_id=13930#r292
07-06-2016 13:36Gyorgy RethyNote Edited: 0013930bug_revision_view_page.php?bugnote_id=13930#r293
18-07-2016 10:20Jens GrabowskiAssigned To => Jacob Wieland - Spirent
18-07-2016 10:20Jens GrabowskiStatusnew => assigned
16-08-2016 16:32Jacob Wieland - SpirentRelationship addedrelated to 0007493
17-08-2016 11:03Jacob Wieland - SpirentTarget Version => v4.8.1 (published 2017-05)
19-08-2016 13:23Jacob Wieland - SpirentFile Added: CR7421.docx
19-08-2016 13:24Jacob Wieland - SpirentNote Added: 0014177
19-08-2016 13:24Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Kristóf Szabados
19-08-2016 13:24Jacob Wieland - SpirentStatusassigned => confirmed
19-08-2016 13:26Jacob Wieland - SpirentRelationship addedrelated to 0007239
17-11-2016 10:10Kristóf SzabadosNote Added: 0014293
17-11-2016 10:10Kristóf SzabadosStatusconfirmed => resolved
17-11-2016 10:10Kristóf SzabadosFixed in Version => v4.9.1 (published 2018-05)
17-11-2016 10:10Kristóf SzabadosResolutionopen => fixed
17-11-2016 14:18Kristóf SzabadosNote Added: 0014309
17-11-2016 14:18Kristóf SzabadosStatusresolved => feedback
17-11-2016 14:18Kristóf SzabadosResolutionfixed => reopened
17-11-2016 14:19Kristóf SzabadosStatusfeedback => resolved
17-11-2016 14:19Kristóf SzabadosFixed in Versionv4.9.1 (published 2018-05) => v4.8.1 (published 2017-05)
17-11-2016 14:19Kristóf SzabadosResolutionreopened => fixed
17-11-2016 14:21Kristóf SzabadosStatusresolved => feedback
17-11-2016 14:21Kristóf SzabadosResolutionfixed => reopened
17-11-2016 14:21Kristóf SzabadosStatusfeedback => resolved
17-11-2016 14:21Kristóf SzabadosResolutionreopened => fixed
17-11-2016 14:21Kristóf SzabadosAssigned ToKristóf Szabados => Gyorgy Rethy
13-12-2016 17:05Gyorgy RethyNote Added: 0014429
13-12-2016 17:05Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0013897) +
+ Jacob Wieland - Spirent    +
+ 18-03-2016 10:44    +
+ 		+ + + + +
+ From my understanding, the proposal tries to introduce the following type compatibility (where WU is a union type marked as a special wrapper type):
+
+a of type T is compatible to WU if a is compatible to the type of the first variant of WU
+
+and
+
+{ v := a } of type WU is compatible to type T if v is the first variant of WU and a is compatible to T
+
+if type T again is a wrapper-union, this can lead to multiple implicit wrappings/unwrappings (as in the case of both XSD element-substitution and subtyping).
+
+(Just added this as a reminder here fore later discussions)
+
+
+
+ + + + + + + + + + +
+ (0013930) +
+ Gyorgy Rethy    +
+ 08-04-2016 11:34    +
(edited on: 07-06-2016 13:36)
+ 		+ + + + +
+ It would be more appropriate and secure for the user to identify the default choice in the type definition explicitly (as opposed to have a rule based on the textual order of the union fields).
+
+Beside this the idea is good, gives huge flexibility to TTCN-3 code extensions.
+
+A corresponding Part-1 CR for default choice of union types should be created.
+
+
+
+
+
+ + + + + + + + + + +
+ (0014177) +
+ Jacob Wieland - Spirent    +
+ 19-08-2016 13:24    +
+ 		+ + + + +
+ please review
+
+
+
+ + + + + + + + + + +
+ (0014293) +
+ Kristóf Szabados    +
+ 17-11-2016 10:10    +
+ 		+ + + + +
+ looks good to me (now as CR 7493 is resolved)
+
+
+
+ + + + + + + + + + +
+ (0014309) +
+ Kristóf Szabados    +
+ 17-11-2016 14:18    +
+ 		+ + + + +
+ incorrect assignment at resolved
+
+
+
+ + + + + + + + + + +
+ (0014429) +
+ Gyorgy Rethy    +
+ 13-12-2016 17:05    +
+ 		+ + + + +
+ Added to draft V4.7.2
+
+ + diff --git a/docs/mantis/CR7427.md b/docs/mantis/CR7427.md new file mode 100644 index 0000000000000000000000000000000000000000..c4b2382c99bcb3d94d89951e89deb5ba3e21e9cc --- /dev/null +++ b/docs/mantis/CR7427.md @@ -0,0 +1,147 @@ + + + + + + + + + + + + + 0007427: Type substitution is limiting replacing built-in XSD types - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007427Part 09: Using XML with TTCN-3Technicalpublic24-03-2016 16:3313-12-2016 17:30
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeveritymajorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.7.1 (published 2016-07) 
Target Versionv4.8.1 (published 2017-05)Fixed in Versionv4.8.1 (published 2017-05) 
Clause Reference(s)8.2 paragraph 1
For STF discussion
Source (company - Author)L.M.Ericsson
Summary0007427: Type substitution is limiting replacing built-in XSD types
DescriptionCurrent text says:
+"This clause is invoked if the XSD simpleType or complexType is referenced by the base attribute of the restriction or extension element information item(s) ..."
+
+However this restricts the substitution of elements of built-in XSD types, while XSD/XML allows this. In the attached example the XSD element is defined to be of type integer, while its instance is of the type xsi:integer_deriv; the XML element validates without error.
+
+Proposed solution: change the text to:
+"This clause is invoked if the XSD built-in type, simpleType or complexType is referenced by the base attribute of the restriction or extension element information item(s) ..."
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files? typesub.xsd (363) 24-03-2016 16:35
http://oldforge.etsi.org/mantis/file_download.php?file_id=3406&type=bug
xml typesub.xml (236) 24-03-2016 16:42
http://oldforge.etsi.org/mantis/file_download.php?file_id=3407&type=bug
docx CR7427_proposal.docx (144,283) 16-11-2016 14:28
http://oldforge.etsi.org/mantis/file_download.php?file_id=3536&type=bug
docx CR7427_proposal_v2.docx (146,263) 16-11-2016 15:00
http://oldforge.etsi.org/mantis/file_download.php?file_id=3540&type=bug
Issue History
Date ModifiedUsernameFieldChange
24-03-2016 16:33Gyorgy RethyNew Issue
24-03-2016 16:34Gyorgy RethyFile Added: typesub.xml
24-03-2016 16:35Gyorgy RethyFile Added: typesub.xsd
24-03-2016 16:41Gyorgy RethyFile Deleted: typesub.xml
24-03-2016 16:42Gyorgy RethyFile Added: typesub.xml
18-07-2016 10:39Jens GrabowskiAssigned To => Kristóf Szabados
18-07-2016 10:39Jens GrabowskiStatusnew => assigned
17-08-2016 11:57Jacob Wieland - SpirentTarget Version => v4.8.1 (published 2017-05)
16-11-2016 13:22Kristóf SzabadosNote Added: 0014265
16-11-2016 14:28Kristóf SzabadosFile Added: CR7427_proposal.docx
16-11-2016 14:42Kristóf SzabadosStatusassigned => confirmed
16-11-2016 14:43Kristóf SzabadosAssigned ToKristóf Szabados => Axel Rennoch
16-11-2016 14:43Kristóf SzabadosStatusconfirmed => assigned
16-11-2016 15:00Axel RennochFile Added: CR7427_proposal_v2.docx
16-11-2016 15:01Axel RennochNote Added: 0014272
16-11-2016 15:02Axel RennochAssigned ToAxel Rennoch => Gyorgy Rethy
16-11-2016 15:03Axel RennochStatusassigned => resolved
16-11-2016 15:03Axel RennochResolutionopen => fixed
13-12-2016 17:30Gyorgy RethyNote Added: 0014431
13-12-2016 17:30Gyorgy RethyStatusresolved => closed
13-12-2016 17:30Gyorgy RethyFixed in Version => v4.8.1 (published 2017-05)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014265) +
+ Kristóf Szabados    +
+ 16-11-2016 13:22    +
+ 		+ + + + +
+ If I understand correctly simpleType already includes built-in types.
+
+Section 8.2 has a note:
+"
+NOTE 1: This definition also includes the case when the type of an element is a built-in XSD data type and one or more user-defined types are derived from this built-in type.
+"
+
+Also simpleType is described in section 5.0 in Table 1 as:
+"
+Defines the simplest types. They may be a built-in type, a list or choice of built-in types and they are not allowed to have attributes.
+"
+
+
+
+ + + + + + + + + + +
+ (0014272) +
+ Axel Rennoch    +
+ 16-11-2016 15:01    +
+ 		+ + + + +
+ small font corrections to the example 1 only
+
+
+
+ + + + + + + + + + +
+ (0014431) +
+ Gyorgy Rethy    +
+ 13-12-2016 17:30    +
+ 		+ + + + +
+ Added to draft V4.7.2
+
+ + diff --git a/docs/mantis/CR7435.md b/docs/mantis/CR7435.md new file mode 100644 index 0000000000000000000000000000000000000000..48407f49bf60372574492751da94e83d6d9858fc --- /dev/null +++ b/docs/mantis/CR7435.md @@ -0,0 +1,552 @@ + + + + + + + + + + + + + 0007435: @decoded modifier is not compositional enough - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007435Part 01: TTCN-3 Core LanguageNew Featurepublic03-05-2016 17:0012-12-2016 16:48
ReporterJacob Wieland - Spirent 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.8.1 (published 2016-07) 
Target Versionv4.9.1 (published 2017-05)Fixed in Versionv4.9.1 (published 2017-05) 
Clause Reference(s)19.1, 22.2.2, 22.2.3, 22.3.2, 22.3.4, 22.3.6, A
Source (company - Author)Spirent - Jacob Wieland
Summary0007435: @decoded modifier is not compositional enough
DescriptionIn case that a decoded payload again contains a decoded payload (both matched with the decmatch construct), it should be possible to assign also the inner decoded value to a variable in the receive-statement.
+
+As an inline syntax in the value-assignment notation, I could imagine two variants:
+
+Variant 1:
+v_inner := @decoded <outer_payload>.@decoded <inner_payload>
+
+where <outer_payload> is the extended field reference of the payload field in the root type and <inner_payload> is the extended field reference of the payload field in the decoded outer payload type.
+
+Variant 2:
+
+v_inner := @decoded (@decoded <outer_payload>).<inner_payload>
+
+Additionally, it should be possible to also use the @decoded syntax on the right-hand-side of an assignment:
+
+v_inner := @decoded v_outer.<inner_payload>
+
+Of course, here, the problem of multiple layers where the inner layer shall be accessed directly without having to assign the outer layer to a variable, also exists.
Steps To Reproduce
Additional InformationI am afraid that it might not be as easy as it seems. At the moment, the type of the first payload is dependend on the target variable type. However, if we allow the intermediate level(s), their types are not known. Please check the following example:
+
+):
+
+type record PDU {
+  PduHeader header,
+  bitstring outerPayload
+}
+
+type record OuterPayload1 {
+  OuterPayloadHeader header,
+  bitstring innerPayload
+}
+
+type record InnerPayload1 {
+  InnerPayloadHeader header,
+  integer data1,
+  charstring data2
+}
+
+...
+var template PDU vmw_pdu;
+var InnerPayload1 v_inner;
+... //vmw_pdu is initialized
+p.receive(vmw_pdu) -> value (v_inner := @decoded outerPayload.@decoded innerPayload);
+
+In the example, it seems that the intention is to decode @decoded outerPayload to a value of the OuterPayload1 type. However, the compiler has no type information at the compilation time and cannot perform static analysis of the composed @decoded statement. Runtime-resolved vmw_pdu template doesn't help in this case, at least not during static analysis.
+
+It would be possible to allow strong typing of the @decoded modifier as follows:
+p.receive(vmw_pdu) -> value (v_inner := @decoded:OuterPayload1 outerPayload.@decoded innerPayload);
+
+In this case there would be no obstacle for having multilayer @decoded modifier in standalone assignment statements:
+
+var template PDU vmw_pdu;
+var PDU v_pdu;
+var InnerPayload1 v_inner;
+p.receive(vmw_pdu) -> value v_pdu;
+v_inner := @decoded:OuterPayload1 v_pdu.outerPayload.@decoded innerPayload);
+
+Is such a solution satisfactory?
TagsNo tags attached.
Relationships
Attached Filesdocx CR7435-1.docx (45,364) 21-07-2016 16:35
http://oldforge.etsi.org/mantis/file_download.php?file_id=3431&type=bug
docx CR7435-2.docx (47,781) 22-07-2016 08:19
http://oldforge.etsi.org/mantis/file_download.php?file_id=3432&type=bug
docx CR7435-3.docx (32,114) 29-08-2016 14:49
http://oldforge.etsi.org/mantis/file_download.php?file_id=3507&type=bug
Issue History
Date ModifiedUsernameFieldChange
03-05-2016 17:00Jacob Wieland - SpirentNew Issue
18-07-2016 10:37Jens GrabowskiAssigned To => Tomas Urban
18-07-2016 10:37Jens GrabowskiStatusnew => assigned
19-07-2016 09:37Tomas UrbanAssigned ToTomas Urban => Jacob Wieland - Spirent
19-07-2016 09:37Tomas UrbanAdditional Information Updatedbug_revision_view_page.php?rev_id=297#r297
19-07-2016 11:11Jacob Wieland - SpirentNote Added: 0013987
19-07-2016 11:12Jacob Wieland - SpirentNote Edited: 0013987bug_revision_view_page.php?bugnote_id=13987#r299
19-07-2016 11:14Jacob Wieland - SpirentNote Edited: 0013987bug_revision_view_page.php?bugnote_id=13987#r300
19-07-2016 14:40Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Tomas Urban
20-07-2016 14:52Jens GrabowskiNote Added: 0014010
20-07-2016 14:52Jens GrabowskiAssigned ToTomas Urban => Kristóf Szabados
20-07-2016 21:40Kristóf SzabadosNote Added: 0014015
21-07-2016 10:13Tomas UrbanNote Added: 0014025
21-07-2016 14:24Kristóf SzabadosNote Added: 0014030
21-07-2016 14:24Kristóf SzabadosAssigned ToKristóf Szabados => Tomas Urban
21-07-2016 15:22Tomas UrbanAssigned ToTomas Urban => Jacob Wieland - Spirent
21-07-2016 15:23Tomas UrbanAssigned ToJacob Wieland - Spirent => Tomas Urban
21-07-2016 16:35Tomas UrbanFile Added: CR7435-1.docx
21-07-2016 16:36Tomas UrbanNote Added: 0014032
21-07-2016 16:36Tomas UrbanAssigned ToTomas Urban => Kristóf Szabados
21-07-2016 16:36Tomas UrbanStatusassigned => confirmed
22-07-2016 08:19Tomas UrbanFile Added: CR7435-2.docx
22-07-2016 08:20Tomas UrbanNote Added: 0014033
22-07-2016 10:35Kristóf SzabadosNote Added: 0014034
17-08-2016 11:26Jacob Wieland - SpirentProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
17-08-2016 11:27Jacob Wieland - SpirentProduct Version => v4.8.1 (published 2016-07)
17-08-2016 11:27Jacob Wieland - SpirentTarget Version => v4.9.1 (published 2017-05)
29-08-2016 14:49Kristóf SzabadosFile Added: CR7435-3.docx
29-08-2016 14:50Kristóf SzabadosAssigned ToKristóf Szabados => Tomas Urban
29-08-2016 14:50Kristóf SzabadosStatusconfirmed => assigned
29-08-2016 14:51Kristóf SzabadosNote Added: 0014194
30-08-2016 11:02Jacob Wieland - SpirentNote Added: 0014198
14-11-2016 13:51Jens GrabowskiStatusassigned => confirmed
14-11-2016 13:52Jens GrabowskiAssigned ToTomas Urban => Gyorgy Rethy
14-11-2016 13:52Jens GrabowskiStatusconfirmed => assigned
14-11-2016 13:52Jens GrabowskiStatusassigned => resolved
14-11-2016 13:52Jens GrabowskiResolutionopen => fixed
12-12-2016 16:48Gyorgy RethyNote Added: 0014392
12-12-2016 16:48Gyorgy RethyStatusresolved => closed
12-12-2016 16:48Gyorgy RethyFixed in Version => v4.9.1 (published 2017-05)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0013987) +
+ Jacob Wieland - Spirent    +
+ 19-07-2016 11:11    +
(edited on: 19-07-2016 11:14)
+ 		+ + + + +
+ I think this syntax is a bit confusing (because the @decoded at the beginning refers to the last item in the whole chain).
+
+Maybe we should switch to a pure @decoded-selector which would look a bit like an anytype usage:
+
+<extended-field-ref>.@decoded.<toplevel-type-reference>
+
+in the example this would be:
+
+v_inner := @decoded outerPayload.@decoded.OuterPayload1.innerPayload
+
+or, alternatively
+v_inner := outerPayload.@decoded.OuterPayload1.innerPayload.@decoded.InnerPayload1
+
+The latter expression is fully context-free and self-contained (if outerPayload is a variable) and could also be used in a type-less environment like a log (in a typed environment, it is redundant, so maybe would help in type-checking).
+For less redundancy, the last type-selection could be optional if the type of the whole expression is known from the context (e.g. the type of the lhs), which would yield:
+
+v_inner := outerPayload.@decoded.OuterPayload1.innerPayload.@decoded
+
+When using the type-cast-syntax, I would propose to do it like this:
+
+<type>:@decoded <ref>
+
+which would yield in our example:
+
+v_inner := @decoded (OuterPayload1:@decoded outerPayload).innerPayload
+
+or as a context-free expression:
+
+InnerPayload1:@decoded (OuterPayload1:@decoded outerPayload).innerPayload
+
+I.e. the type-prefix must only be added if the type of the @decoded expression is not known from its context.
+
+
+
+
+
+ + + + + + + + + + +
+ (0014010) +
+ Jens Grabowski    +
+ 20-07-2016 14:52    +
+ 		+ + + + +
+ Agreement Jacob and Tomas:
+
+<extended-field-ref>.@decoded.<toplevel-type-reference>
+
+in the example this would be:
+
+v_inner := @decoded outerPayload.@decoded.OuterPayload1.innerPayload
+
+or, alternatively
+v_inner := outerPayload.@decoded.OuterPayload1.innerPayload.@decoded.InnerPayload1
+
+The latter expression is fully context-free and self-contained (if outerPayload is a variable) and could also be used in a type-less environment like a log (in a typed environment, it is redundant, so maybe would help in type-checking).
+
+Check also for acceptance for short form:
+v_inner := outerPayload.OuterPayload1.innerPayload.InnerPayload1
+
+Assigned to Kristof for crosscheck within Ericsson.
+
+
+
+ + + + + + + + + + +
+ (0014015) +
+ Kristóf Szabados    +
+ 20-07-2016 21:40    +
+ 		+ + + + +
+ If I understand correctly the syntaxes with @decoded() would conflict with the current standard, according to which the parameter when present would need to describe the encoding format of the universal charstring field.
+
+regarding the syntax the "type-cast" looks better to me, as it is much easier to see what belongs to where. 2-3 or more embedding with the . notation and users will need to group the expression into its parts on paper.
+
+I don't think the type prefix must be denied if the type is known from the context. Tools could ignore it if they want, the users could use it to make the expression more intuitively readable, and it could be used as a form to make the intent more explicit.
+
+
+
+ + + + + + + + + + +
+ (0014025) +
+ Tomas Urban    +
+ 21-07-2016 10:13    +
+ 		+ + + + +
+ The casting syntax doesn't contain a conflict. I would contain two pair of parenthesis if used with encoding:
+
+InnerPayload1:@decode("UTF-8") (OuterPayload1:@decode("UTF-8") outerPayload).innerPayload
+
+For me, it is less readable than dot notation as two parts of the inner payload (InnerPayload1 type and innerPayload field) are separated. The distance will grow if the protocol contains more items.
+
+In order to increase readability, we could introduce a different lexical symbol for the dot notation so that the user can see when decoding takes place from the syntax. Yesterday we discussed two possible symbols (: and ->) with Jacob, but they were rejected, because they already have different meaning in TTCN-3. One possible candidate would be tilde (~). Its common meaning is "approximately" or "similar to" which would quite well fit its intended meaning in TTCN-3. Another possibility would be a direction sign, e.g. => or >>. If a symbol different than dot is used, we could skip using the @decoded modifier at all and use just the short syntax. Please see the following examples:
+
+v_inner := outerPayload~OuterPayload1.innerPayload~InnerPayload1
+v_inner := outerPayload~("UTF-8")OuterPayload1.innerPayload~("UTF-8")InnerPayload1
+
+v_inner := outerPayload=>OuterPayload1.innerPayload=>InnerPayload1
+v_inner := outerPayload=>("UTF-8")OuterPayload1.innerPayload=>("UTF-8")InnerPayload1
+
+v_inner := outerPayload>>OuterPayload1.innerPayload>>InnerPayload1
+v_inner := outerPayload>>("UTF-8")OuterPayload1.innerPayload>>("UTF-8")InnerPayload1
+
+Kristof mentioned a problem with extended type reference. This is a valid remark. However, exactly the same problem exists with the anytype where only top-level types can be referenced. I would keep this rule valid for the decoded field reference in case the STF decides for the extension of the dot notation rule.
+
+
+
+ + + + + + + + + + +
+ (0014030) +
+ Kristóf Szabados    +
+ 21-07-2016 14:24    +
+ 		+ + + + +
+ We had a discussion and decided to got with the syntax:
+"
+v_inner := outerPayload=>OuterPayload1.innerPayload=>InnerPayload1
+v_inner := outerPayload=>("UTF-8")OuterPayload1.innerPayload=>("UTF-8")InnerPayload1
+"
+
+Also the type reference must be restricted to pointing to a top-level type definition, otherwise it would be impossible to separate it from the proceeding field reference.
+
+
+
+ + + + + + + + + + +
+ (0014032) +
+ Tomas Urban    +
+ 21-07-2016 16:36    +
+ 		+ + + + +
+ Proposal uploaded. Please check.
+
+
+
+ + + + + + + + + + +
+ (0014033) +
+ Tomas Urban    +
+ 22-07-2016 08:20    +
+ 		+ + + + +
+ Minor modification in the proposal: terminals added to the table A.2
+
+
+
+ + + + + + + + + + +
+ (0014034) +
+ Kristóf Szabados    +
+ 22-07-2016 10:35    +
+ 		+ + + + +
+ ExtendedFieldReference is used in many locations.
+For example right now these seem to be syntactically OK:
+match(..,..) => type
+valueof(..,..) => type
+some_function(...) => type
+
+variable := field1 => (type) => (type) => (type)
+
+Wouldn't it be better to keep this separated from the generic reference, somewhat like this?:
+338.SingleValueSpec ::= VariableRef [AssignmentChar [( DecodedModifier ["(" Expression] ")"]
+                                                     | DecodingOperation )] FieldReference ExtendedFieldReference]
+
+??. DecodedOperation ::= {FieldReference "=>" DecodedFieldType}+
+??. DecodedFieldType ::= PredefinedType | Identifier | "(" Type [ "," Expression ] ")"
+
+---
+
+shouldn't VariableAssignment be also updated for syntactic consistency?
+
+
+
+ + + + + + + + + + +
+ (0014194) +
+ Kristóf Szabados    +
+ 29-08-2016 14:51    +
+ 		+ + + + +
+ I have uploaded a new version with minor typo corrections.
+Please check/modifiy and assign to György (rapporteur)
+
+
+
+ + + + + + + + + + +
+ (0014198) +
+ Jacob Wieland - Spirent    +
+ 30-08-2016 11:02    +
+ 		+ + + + +
+ looks good to me
+
+
+
+ + + + + + + + + + +
+ (0014392) +
+ Gyorgy Rethy    +
+ 12-12-2016 16:48    +
+ 		+ + + + +
+ Added to V4.8.2
+
+ + diff --git a/docs/mantis/CR7436.md b/docs/mantis/CR7436.md new file mode 100644 index 0000000000000000000000000000000000000000..7614b0e8154ca902aa8a65c12d934925a00147bd --- /dev/null +++ b/docs/mantis/CR7436.md @@ -0,0 +1,173 @@ + + + + + + + + + + + + + 0007436: Allow 'all' wildcard also as actual type parameter inside port type definitions - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Advanced Parametrization (ES 202 784)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007436Ext Pack: Advanced Parametrization (ES 202 784)New Featurepublic31-05-2016 12:4016-12-2016 21:14
ReporterJacob Wieland - Spirent 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv1.5.1 (published 2015-06) 
Target Versionv1.6.1 (published 2017-04)Fixed in Versionv1.6.1 (published 2017-04) 
TS version?
Clause Reference(s)new clause
Source (company - Author)Spirent - Jacob Wieland
Summary0007436: Allow 'all' wildcard also as actual type parameter inside port type definitions
DescriptionAt the moment, it is allowed to use 'all' as kind of a wildcard in a port type for either in, out or inout declarations.
+
+Given a generic type R<T> where T is the formal type parameter, it would be useful to be allowed to use R<all> also as a type instance in port type definitions like this:
+
+type record R<T> {...}
+
+type port PortType message { inout R<all> }
+
+The semantics, of course, would be the same as for the previous known usage of 'all', i.e. R<all> is a short form of the list R<T1>, ..., R<Tn> where T1, ..., Tn is the set of all defined types (which, given generics, is possibly infinite)
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7436.docx (157,452) 20-07-2016 16:05
http://oldforge.etsi.org/mantis/file_download.php?file_id=3426&type=bug
docx CR7436-1-v2-160721.docx (153,915) 21-07-2016 08:48
http://oldforge.etsi.org/mantis/file_download.php?file_id=3428&type=bug
Issue History
Date ModifiedUsernameFieldChange
31-05-2016 12:40Jacob Wieland - SpirentNew Issue
18-07-2016 10:32Jens GrabowskiAssigned To => Jacob Wieland - Spirent
18-07-2016 10:32Jens GrabowskiStatusnew => assigned
20-07-2016 16:05Jacob Wieland - SpirentFile Added: CR7436.docx
20-07-2016 16:06Jacob Wieland - SpirentNote Added: 0014011
20-07-2016 16:06Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Jens Grabowski
20-07-2016 16:06Jacob Wieland - SpirentStatusassigned => confirmed
21-07-2016 08:48Jens GrabowskiFile Added: CR7436-1-v2-160721.docx
21-07-2016 08:49Jens GrabowskiNote Added: 0014021
21-07-2016 08:50Jens GrabowskiAssigned ToJens Grabowski => Tomas Urban
21-07-2016 08:50Jens GrabowskiStatusconfirmed => assigned
21-07-2016 09:40Tomas UrbanNote Added: 0014023
21-07-2016 09:40Tomas UrbanAssigned ToTomas Urban => Jens Grabowski
21-07-2016 09:40Tomas UrbanStatusassigned => resolved
16-12-2016 21:14Gyorgy RethyNote Added: 0014454
16-12-2016 21:14Gyorgy RethyAssigned ToJens Grabowski => Gyorgy Rethy
16-12-2016 21:14Gyorgy RethyProduct Versionv1.6.1 (published 2017-04) => v1.5.1 (published 2015-06)
16-12-2016 21:14Gyorgy RethyFixed in Version => v1.6.1 (published 2017-04)
16-12-2016 21:14Gyorgy RethyTarget VersionNext version (to be defined) => v1.6.1 (published 2017-04)
16-12-2016 21:14Gyorgy RethyStatusresolved => closed
16-12-2016 21:14Gyorgy RethyResolutionopen => fixed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014011) +
+ Jacob Wieland - Spirent    +
+ 20-07-2016 16:06    +
+ 		+ + + + +
+ please review
+
+
+
+ + + + + + + + + + +
+ (0014021) +
+ Jens Grabowski    +
+ 21-07-2016 08:49    +
+ 		+ + + + +
+ Formatting: Keywords in new examples are now set to bold.
+
+
+
+ + + + + + + + + + +
+ (0014023) +
+ Tomas Urban    +
+ 21-07-2016 09:40    +
+ 		+ + + + +
+ The proposal can be added into the next version of the advanced parameterization specification.
+
+
+
+ + + + + + + + + + +
+ (0014454) +
+ Gyorgy Rethy    +
+ 16-12-2016 21:14    +
+ 		+ + + + +
+ Added to draft V1.5.3
+
+ + diff --git a/docs/mantis/CR7437.md b/docs/mantis/CR7437.md new file mode 100644 index 0000000000000000000000000000000000000000..91fd4c56f0771c262a5da713e8feddb3c7ca69f3 --- /dev/null +++ b/docs/mantis/CR7437.md @@ -0,0 +1,251 @@ + + + + + + + + + + + + + 0007437: It should be possible to assign the variant of a union to a variable and use such variant values for union operations - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007437Part 01: TTCN-3 Core LanguageNew Featurepublic31-05-2016 13:0714-11-2016 16:23
ReporterJacob Wieland - Spirent 
Assigned ToKristóf Szabados 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionno change required 
PlatformOSOS Version
Product Versionv4.8.1 (published 2016-07) 
Target Versionv4.9.1 (published 2017-05)Fixed in Version 
Clause Reference(s)6.2.5, C.3.2
Source (company - Author)Spirent - Jacob Wieland
Summary0007437: It should be possible to assign the variant of a union to a variable and use such variant values for union operations
DescriptionConsider the following use case:
+
+type union U { ... }
+type record of U RU;
+
+template RU containsV := { *, { V := X }, *}
+
+At the moment, there is no easy way to access X or to write a function which
+gets the list and the variant V and produces the union value which has variant V.
+
+What can be envisioned could be something like this:
+
+function getElementOfVariant(RU list, U.variant v) return U {
+  for (var integer i := 0; i < lengthof(list); i:= i+1) {
+    if (ischosen(list[i], v)) {
+      return list[i];
+    }
+  }
+}
+
+Thus, U.variant would be an implicit enumerated type containing the enumerated values that are the variant names of the union type while the ischosen operation would be overloaded so that it can always take a pair of U and U.variant as actual parameters and check, whether the given variant is the one chosen in the union value/template. The ischosen would get the two items as separate parameters because both actual parameters can be arbitrarily complex dotted notations and using dot-notation to combine them would be ambiguous.
+
+The construct u.variant (where u is a union value of type U) could be used to actually get the variant from a union value (so u.variant is always of type U.variant iff u is of union type U).
+
+All other restrictions of enumerated types would apply to the variant type of a union type.
Steps To Reproduce
Additional InformationAll this can be done already by programming it explicitly, but needs to be done for every union type anew. The proposed feature would give the user a generic solution for this problem.
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
31-05-2016 13:07Jacob Wieland - SpirentNew Issue
18-07-2016 10:29Jens GrabowskiAssigned To => Kristóf Szabados
18-07-2016 10:29Jens GrabowskiStatusnew => assigned
16-08-2016 14:45Jacob Wieland - SpirentNote Added: 0014110
17-08-2016 11:25Jacob Wieland - SpirentProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
17-08-2016 11:26Jacob Wieland - SpirentProduct Version => v4.8.1 (published 2016-07)
17-08-2016 11:26Jacob Wieland - SpirentTarget Version => v4.9.1 (published 2017-05)
13-11-2016 16:50Kristóf SzabadosNote Added: 0014224
14-11-2016 03:45Jacob Wieland - SpirentNote Added: 0014225
14-11-2016 03:46Jacob Wieland - SpirentNote Added: 0014226
14-11-2016 16:23Jens GrabowskiNote Added: 0014232
14-11-2016 16:23Jens GrabowskiStatusassigned => closed
14-11-2016 16:23Jens GrabowskiResolutionopen => no change required
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014110) +
+ Jacob Wieland - Spirent    +
+ 16-08-2016 14:45    +
+ 		+ + + + +
+ Because the .variant would clash with the attribute retrieval operation, we propose to use
+
+<union_type>.enumerated to signify the enumerated type of the union variants
+and
+<union_value>.present to evaluate to the enumerated value of the present variant
+
+The following rule applies:
+
+If u is of union type U, then u.present is of type U.enumerated.
+
+For the ischosen operation with two arguments, the restriction must be that the first argument must be a value of a union type U and the second argument must be of type U.enumerated.
+
+
+
+ + + + + + + + + + +
+ (0014224) +
+ Kristóf Szabados    +
+ 13-11-2016 16:50    +
+ 		+ + + + +
+ Can't the initial task be solved by something like this:
+function getElementOfVariant(RU list, template U v) return U {
+  for (var integer i := 0; i < lengthof(list); i:= i+1) {
+    if (match(list[i],v)) {
+      return list[i];
+    }
+  }
+  return list[0];
+}
+...
+var RU containsV := { { field1 := 1 }, {field2 := "something"}};
+var U temp := getElementOfVariant(containsV, {field1 := ?});
+log("result: ", temp);
+temp := getElementOfVariant(containsV, {field2 := ?});
+log("result: ", temp);
+
+Where U is a union of an integer and charstring field
+
+
+
+ + + + + + + + + + +
+ (0014225) +
+ Jacob Wieland - Spirent    +
+ 14-11-2016 03:45    +
+ 		+ + + + +
+ true, also with the new template with out parameters, it would be even easier to get access to the actual value:
+
+if (match(l,{*,{field:=? -> v},*})) { /* do something with v */ }
+
+
+
+ + + + + + + + + + +
+ (0014226) +
+ Jacob Wieland - Spirent    +
+ 14-11-2016 03:46    +
+ 		+ + + + +
+ so, in essence, I propose to drop this issue
+
+
+
+ + + + + + + + + + +
+ (0014232) +
+ Jens Grabowski    +
+ 14-11-2016 16:23    +
+ 		+ + + + +
+ See discussion.
+
+ + diff --git a/docs/mantis/CR7438.md b/docs/mantis/CR7438.md new file mode 100644 index 0000000000000000000000000000000000000000..6b84b8fba3da1ac5a96b6ac42e6beab6290f7c3b --- /dev/null +++ b/docs/mantis/CR7438.md @@ -0,0 +1,309 @@ + + + + + + + + + + + + + 0007438: Templates with variable bindings. - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Advanced Matching (ES 203 022)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007438Ext Pack: Advanced Matching (ES 203 022)New Featurepublic31-05-2016 13:5524-12-2016 12:26
ReporterJacob Wieland - Spirent 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv1.1.1 (published 2017-07)Fixed in Versionv1.1.1 (published 2017-07) 
Clause Reference(s)Advanced Matching Package
Source (company - Author)Spirent - Jacob Wieland
TS version
Summary0007438: Templates with variable bindings.
DescriptionIn function languages, it is customary to use patterns of constructed data types to define the parameters of functions. These patterns can contain unbound variables which will be bound if the pattern matches, so that they can be used on the right-hand-side of the definition.
+
+Since TTCN-3 already has a powerful pattern language available, it would be very useful to allow a similar variable binding as a side-effect of matching.
+
+We propose the following syntax:
+
+<matching mechanism> -> <variable>
+
+in all places where in a template body a matching mechanism is allowed at the moment.
+
+For example:
+
+type record Pair { integer a, integer b }
+
+template Pair pair(out integer a, out integer b) := {
+  a := ? -> a,
+  b := ? -> b
+}
+
+var integer a, b;
+var Pair p := ...;
+if (match(p, pair(a,b))) { /* do something with a and b */ }
+
+Of course, the assignment syntax could also be used in an inline template, as long as the variables used are declared in the context of the inline template.
+
+if (match(p, Pair:{ ? -> a, ? -> b }) { /* same semantics as above */ }
+
+The variable would be assigned the value that matched the corresponding matching mechanism iff the whole template body matches. The variable needs to be of the correct type, depending on the place of the matching mechanism inside the template body.
+
+For convenience, parameterized templates would be allowed to declare out parameters to be used for variable binding.
+
+A still open question is what should happen if a template has multiple ways of matching the value (as could, for instance, happen with { *, pair(a,b), * } in a record of Pair). As checking this condition can only be done at runtime and is normally much more expensive than searching for the first match, I propose to keep that ambiguous so that the result can be the assignment for ANY match, thus forcing the user to define the templates in a non-ambiguous way.
+
+Alternatively, a construct could be introduced which allows multiply applying the match operation with the same template (e.g. in a template variable) until no new matching is found:
+
+type record of Pair Pairs;
+var Pairs p := ...;
+var @match template Pairs t := { *, pair(a, b), * }; // this would be kind of a lazy definition
+while (match(p, t)) { /* do something with a and b */ }
+
+Of course, these kinds of templates could also be used in receive statements or anywhere else where templates for matching are allowed (i.e. select cases).
+
+If passed as an actual in parameter, the formal parameter should be declared with a @match modifier so that it is clear that this template can only be used for matching. A template variable that is declared with the @match operator can not be used to be assigned to a normal template variable or used as a return template.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filespptx Template-Inline-Redirect-Ideas-160722.pptx (30,328) 22-07-2016 13:36
http://oldforge.etsi.org/mantis/file_download.php?file_id=3435&type=bug
docx CR-7438-Templates-with-variable-bindings-V1.docx (30,289) 15-11-2016 13:21
http://oldforge.etsi.org/mantis/file_download.php?file_id=3521&type=bug
docx CR-7438-Templates-with-variable-bindings-V2.docx (41,461) 15-11-2016 16:39
http://oldforge.etsi.org/mantis/file_download.php?file_id=3526&type=bug
docx CR-7438-Templates-with-variable-bindings-V3.docx (49,638) 16-11-2016 11:03
http://oldforge.etsi.org/mantis/file_download.php?file_id=3530&type=bug
docx CR-7438-Templates-with-variable-bindings-V4.docx (49,739) 17-11-2016 10:10
http://oldforge.etsi.org/mantis/file_download.php?file_id=3549&type=bug
docx CR-7438-Templates-with-variable-bindings-V5.docx (50,836) 18-11-2016 10:09
http://oldforge.etsi.org/mantis/file_download.php?file_id=3565&type=bug
Issue History
Date ModifiedUsernameFieldChange
31-05-2016 13:55Jacob Wieland - SpirentNew Issue
31-05-2016 13:58Jacob Wieland - SpirentClause Reference(s)TBD => Advanced Matching Package
31-05-2016 16:50Jacob Wieland - SpirentDescription Updatedbug_revision_view_page.php?rev_id=291#r291
18-07-2016 10:25Jens GrabowskiNote Added: 0013974
18-07-2016 10:26Jens GrabowskiAssigned To => Jens Grabowski
18-07-2016 10:26Jens GrabowskiStatusnew => assigned
19-07-2016 16:22Jens GrabowskiProjectTTCN-3 Change Requests => Ext Pack: Advanced Matching (ES 203 022)
22-07-2016 13:36Jens GrabowskiFile Added: Template-Inline-Redirect-Ideas-160722.pptx
17-08-2016 11:56Jacob Wieland - SpirentTarget Version => v1.1.1 (published 2017-07)
15-11-2016 13:21Jens GrabowskiFile Added: CR-7438-Templates-with-variable-bindings-V1.docx
15-11-2016 13:21Jens GrabowskiAssigned ToJens Grabowski => Jacob Wieland - Spirent
15-11-2016 16:39Jacob Wieland - SpirentFile Added: CR-7438-Templates-with-variable-bindings-V2.docx
15-11-2016 16:39Jacob Wieland - SpirentNote Added: 0014254
15-11-2016 16:39Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Axel Rennoch
15-11-2016 16:39Jacob Wieland - SpirentStatusassigned => confirmed
16-11-2016 11:03Axel RennochFile Added: CR-7438-Templates-with-variable-bindings-V3.docx
16-11-2016 11:03Axel RennochNote Added: 0014260
16-11-2016 11:04Axel RennochAssigned ToAxel Rennoch => Jacob Wieland - Spirent
16-11-2016 11:04Axel RennochStatusconfirmed => assigned
16-11-2016 11:05Axel RennochNote Added: 0014261
16-11-2016 11:05Axel RennochStatusassigned => confirmed
17-11-2016 10:10Jacob Wieland - SpirentFile Added: CR-7438-Templates-with-variable-bindings-V4.docx
17-11-2016 10:12Jacob Wieland - SpirentNote Added: 0014294
17-11-2016 10:12Jacob Wieland - SpirentStatusconfirmed => resolved
17-11-2016 10:12Jacob Wieland - SpirentFixed in Version => v1.1.1 (published 2017-07)
17-11-2016 10:12Jacob Wieland - SpirentResolutionopen => fixed
17-11-2016 10:12Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Jens Grabowski
18-11-2016 09:48Jens GrabowskiNote Added: 0014326
18-11-2016 09:48Jens GrabowskiAssigned ToJens Grabowski => Jacob Wieland - Spirent
18-11-2016 09:48Jens GrabowskiStatusresolved => assigned
18-11-2016 10:09Jacob Wieland - SpirentFile Added: CR-7438-Templates-with-variable-bindings-V5.docx
18-11-2016 10:10Jacob Wieland - SpirentNote Added: 0014328
18-11-2016 10:10Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Jens Grabowski
18-11-2016 10:10Jacob Wieland - SpirentStatusassigned => confirmed
24-12-2016 12:26Jens GrabowskiStatusconfirmed => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0013974) +
+ Jens Grabowski    +
+ 18-07-2016 10:25    +
+ 		+ + + + +
+ Candidate for "Advanced Matching" extension package.
+
+
+
+ + + + + + + + + + +
+ (0014254) +
+ Jacob Wieland - Spirent    +
+ 15-11-2016 16:39    +
+ 		+ + + + +
+ please do a preliminary review, this is still in the drafting stage, but please check whether everything is understandable
+
+
+
+ + + + + + + + + + +
+ (0014260) +
+ Axel Rennoch    +
+ 16-11-2016 11:03    +
+ 		+ + + + +
+ some corrections, formatting and text additions
+
+
+
+ + + + + + + + + + +
+ (0014261) +
+ Axel Rennoch    +
+ 16-11-2016 11:05    +
+ 		+ + + + +
+ please use version 3 for further updates
+
+
+
+ + + + + + + + + + +
+ (0014294) +
+ Jacob Wieland - Spirent    +
+ 17-11-2016 10:12    +
+ 		+ + + + +
+ I have reviewed again and made some small wording changes to not confuse the match operation with a template match.
+
+
+
+ + + + + + + + + + +
+ (0014326) +
+ Jens Grabowski    +
+ 18-11-2016 09:48    +
+ 		+ + + + +
+ BNF rules have to be added.
+
+
+
+ + + + + + + + + + +
+ (0014328) +
+ Jacob Wieland - Spirent    +
+ 18-11-2016 10:10    +
+ 		+ + + + +
+ added missing BNF changes part, please review and resolve
+
+ + diff --git a/docs/mantis/CR7445.md b/docs/mantis/CR7445.md new file mode 100644 index 0000000000000000000000000000000000000000..2f107c7afdb24b4ec37cfd907fa44a71224a9941 --- /dev/null +++ b/docs/mantis/CR7445.md @@ -0,0 +1,264 @@ + + + + + + + + + + + + + 0007445: usage of encode/variant attributes should be enhanced - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007445Part 01: TTCN-3 Core LanguageNew Featurepublic17-06-2016 13:0708-09-2017 10:52
ReporterJacob Wieland - Spirent 
Assigned ToTomas Urban 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.10.1 (published 2018-05)Fixed in Versionv4.10.1 (published 2018-05) 
Clause Reference(s)27
Source (company - Author)Spirent - Jacob Wieland
Summary0007445: usage of encode/variant attributes should be enhanced
DescriptionIn a user scenario, the same data shall sometimes be encoded with different encodings which have different variant attributes to configure the codec.
+
+This is not easily accomplished by TTCN-3 at the moment as any type/member can only have one encode/variant attribute (or the semantics of multiplicity of such attributes is unspecified) and the variant attribute is tied to the encoding attribute. Thus, you would need two copies of the same type system with different attributes attached and, following that, copies of all the templates for these types, as well and selection expressions at all usage points which makes the whole thing very hard to manage.
+
+What would be necessary to achieve the single-type/template approach would be to allow, at least on the type definition level, to add multiple encode/variant attributes and to somehow tag variant attributes with the encoding rule they are tied to.
+
+Care must also be taken on the TCI level with the functions getType() getTypeEncoding() getTypeEncodingVariant() getValueEncoding() and getValueEncodingVariant(). Ideally, a codec should be unaware of the encoding/variant multiplicity and still work with the assumption that the value-encoding of the template to be encoded establishes the relevant encoding context.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0007448closed Gyorgy Rethy Allowing multiple encodings for TTCN-3 types 
related to 0007707closed Gyorgy Rethy Port and timer variables and structured types containing ports and timers 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
17-06-2016 13:07Jacob Wieland - SpirentNew Issue
11-07-2016 10:27Jacob Wieland - SpirentRelationship addedrelated to 0007448
18-07-2016 10:02Jens GrabowskiAssigned To => Tomas Urban
18-07-2016 10:02Jens GrabowskiStatusnew => assigned
16-08-2016 16:26Tomas UrbanNote Added: 0014116
16-08-2016 16:26Tomas UrbanAssigned ToTomas Urban => Jens Grabowski
16-08-2016 16:26Tomas UrbanStatusassigned => confirmed
17-08-2016 11:09Jacob Wieland - SpirentProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
17-08-2016 11:10Jacob Wieland - SpirentTarget Version => v4.9.1 (published 2017-05)
18-08-2016 10:59Jens GrabowskiAssigned ToJens Grabowski => Kristóf Szabados
18-08-2016 10:59Jens GrabowskiStatusconfirmed => assigned
18-08-2016 10:59Jens GrabowskiStatusassigned => confirmed
19-08-2016 13:34Kristóf SzabadosAssigned ToKristóf Szabados => Jacob Wieland - Spirent
19-08-2016 13:34Kristóf SzabadosStatusconfirmed => assigned
19-08-2016 15:01Jacob Wieland - SpirentNote Added: 0014187
19-08-2016 15:01Jacob Wieland - SpirentStatusassigned => confirmed
14-11-2016 13:14Jacob Wieland - SpirentNote Added: 0014228
14-11-2016 13:16Jacob Wieland - SpirentNote Edited: 0014228bug_revision_view_page.php?bugnote_id=14228#r330
14-11-2016 15:59Jens GrabowskiNote Added: 0014231
15-11-2016 09:41Jacob Wieland - SpirentNote Added: 0014235
15-11-2016 09:41Jacob Wieland - SpirentSeveritymajor => minor
15-11-2016 09:41Jacob Wieland - SpirentStatusconfirmed => new
15-11-2016 09:41Jacob Wieland - SpirentTarget Versionv4.9.1 (published 2017-05) => v4.10.1 (published 2018-05)
17-11-2016 14:04Jens GrabowskiStatusnew => assigned
08-09-2017 10:26Tomas UrbanAssigned ToJacob Wieland - Spirent => Tomas Urban
08-09-2017 10:43Tomas UrbanRelationship addedrelated to 0007707
08-09-2017 10:52Tomas UrbanNote Added: 0014826
08-09-2017 10:52Tomas UrbanStatusassigned => closed
08-09-2017 10:52Tomas UrbanResolutionopen => fixed
08-09-2017 10:52Tomas UrbanFixed in Version => v4.10.1 (published 2018-05)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014116) +
+ Tomas Urban    +
+ 16-08-2016 16:26    +
+ 		+ + + + +
+ Resolved as a part of resolution of the related CR 0007448.
+
+
+
+ + + + + + + + + + +
+ (0014187) +
+ Jacob Wieland - Spirent    +
+ 19-08-2016 15:01    +
+ 		+ + + + +
+ please review
+
+
+
+ + + + + + + + + + +
+ (0014228) +
+ Jacob Wieland - Spirent    +
+ 14-11-2016 13:14    +
(edited on: 14-11-2016 13:16)
+ 		+ + + + +
+ Using the following pattern, the existing syntactical elements of TTCN-3 could already be used to write such code.
+
+Let's assume our PDU type is PDU.
+
+We would declare
+
+type port PDUPort message { inout PDU }
+
+type PDUPort JSONPDUPort with { encode "JSON" }
+
+type PDUPort XMLPDUPort with { encode "XML" }
+
+component PDUComponent {
+
+  port JSONPDUPOrt jsonPort;
+  port XMLPDUPort xmlPort;
+  var PDUPort pduPort;
+}
+
+function configure() runs on PDUComponent {
+  if (useJSON) { pduPort := jsonPort; } else { pduPort := xmlPort; }
+}
+
+Then, in the rest of the code, we would simply use the port variable and never the concrete ones directly.
+
+
+
+
+
+ + + + + + + + + + +
+ (0014231) +
+ Jens Grabowski    +
+ 14-11-2016 15:59    +
+ 		+ + + + +
+ STF agreement: Use resolution as proposed in CR 7448. This proposal may be discussed in the scope of the 2017 TTCN-3 STF.
+
+
+
+ + + + + + + + + + +
+ (0014235) +
+ Jacob Wieland - Spirent    +
+ 15-11-2016 09:41    +
+ 		+ + + + +
+ I shift this to the future so we don't forget about it.
+
+
+
+ + + + + + + + + + +
+ (0014826) +
+ Tomas Urban    +
+ 08-09-2017 10:52    +
+ 		+ + + + +
+ The original issue was handled in the related CR 0007448 and the proposed introduction of port variables has its own dedicated CR 0007707. As there are no more issues left, the CR has been closed by STF 533.
+
+ + diff --git a/docs/mantis/CR7446.md b/docs/mantis/CR7446.md new file mode 100644 index 0000000000000000000000000000000000000000..88194b1836958c336de2056f9285a023dc5639b4 --- /dev/null +++ b/docs/mantis/CR7446.md @@ -0,0 +1,176 @@ + + + + + + + + + + + + + 0007446: definite overlapping of select cases should be disallowed or at least discouraged - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007446Part 01: TTCN-3 Core LanguageClarificationpublic24-06-2016 10:3212-12-2016 10:31
ReporterJacob Wieland - Spirent 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.8.1 (published 2016-07) 
Target Versionv4.9.1 (published 2017-05)Fixed in Versionv4.9.1 (published 2017-05) 
Clause Reference(s)19.3
Source (company - Author)Spirent - Jacob Wieland
Summary0007446: definite overlapping of select cases should be disallowed or at least discouraged
DescriptionIn a testsuite in the LTE context, there was a select statement over a (very large) enumerated type where some cases (probably wrongly due to copy-paste or some other editorial reason) used the same enumerated values in multiple cases.
+
+According to the current semantics of the select statement, this is not forbidden and in effect leads only to dead code, i.e. the later cases of the same value are never reached. Since it is not disallowed, it also doesn't seem to be checked by the available tools up till now, even though this would clearly benefit the user.
+
+Therefore, it is proposed to forbid/discourage unambiguous overlapping of cases, i.e. a later case shall not use only the same expressions that earlier cases already covered.
+
+Of course, since it is allowed to use templates in select statements, the overlapping-property can not in all cases be easily (or at all) be determined. It should be up to the tool how much effort should be put into this analysis beyond checking for the same syntactic expressions (which is trivial).
+
+For backward compatibility reasons, we should simply strongly discourage such definite overlapping, so that tools shall be allowed to treat that as an error, if they find a definite overlap (and otherwise ignore it as before).
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7446_proposal_v1.docx (153,456) 17-08-2016 11:12
http://oldforge.etsi.org/mantis/file_download.php?file_id=3470&type=bug
docx CR7446_proposal_v2.docx (153,886) 17-08-2016 14:11
http://oldforge.etsi.org/mantis/file_download.php?file_id=3473&type=bug
docx CR7446_proposal_v3.docx (154,559) 17-08-2016 22:43
http://oldforge.etsi.org/mantis/file_download.php?file_id=3483&type=bug
docx CR7446_proposal_v4.docx (154,246) 18-08-2016 15:48
http://oldforge.etsi.org/mantis/file_download.php?file_id=3493&type=bug
Issue History
Date ModifiedUsernameFieldChange
24-06-2016 10:32Jacob Wieland - SpirentNew Issue
18-07-2016 10:16Jens GrabowskiAssigned To => Kristóf Szabados
18-07-2016 10:16Jens GrabowskiStatusnew => assigned
17-08-2016 11:12Kristóf SzabadosFile Added: CR7446_proposal_v1.docx
17-08-2016 11:18Kristóf SzabadosNote Added: 0014128
17-08-2016 11:18Kristóf SzabadosAssigned ToKristóf Szabados => Jacob Wieland - Spirent
17-08-2016 11:18Kristóf SzabadosStatusassigned => confirmed
17-08-2016 11:18Jacob Wieland - SpirentProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
17-08-2016 11:19Jacob Wieland - SpirentProduct Version => v4.8.1 (published 2016-07)
17-08-2016 11:19Jacob Wieland - SpirentTarget Version => v4.9.1 (published 2017-05)
17-08-2016 14:11Kristóf SzabadosFile Added: CR7446_proposal_v2.docx
17-08-2016 14:12Kristóf SzabadosNote Added: 0014131
17-08-2016 22:43Kristóf SzabadosFile Added: CR7446_proposal_v3.docx
17-08-2016 22:44Kristóf SzabadosNote Added: 0014143
18-08-2016 15:48Jacob Wieland - SpirentFile Added: CR7446_proposal_v4.docx
18-08-2016 15:48Jacob Wieland - SpirentStatusconfirmed => resolved
18-08-2016 15:48Jacob Wieland - SpirentFixed in Version => v4.9.1 (published 2017-05)
18-08-2016 15:48Jacob Wieland - SpirentResolutionopen => fixed
18-08-2016 15:48Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
12-12-2016 10:31Gyorgy RethyNote Added: 0014374
12-12-2016 10:31Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014128) +
+ Kristóf Szabados    +
+ 17-08-2016 11:18    +
+ 		+ + + + +
+ Could you check my proposed solution?
+
+I added a note on how non-overlaping template instances in branches and a deterministic expression in the header could be used for better performance.
+
+
+
+ + + + + + + + + + +
+ (0014131) +
+ Kristóf Szabados    +
+ 17-08-2016 14:12    +
+ 		+ + + + +
+ Added the note on how overlapping is discouraged (as it creates dead code).
+Please check.
+
+
+
+ + + + + + + + + + +
+ (0014143) +
+ Kristóf Szabados    +
+ 17-08-2016 22:44    +
+ 		+ + + + +
+ I have added the restriction as discussed.
+
+
+
+ + + + + + + + + + +
+ (0014374) +
+ Gyorgy Rethy    +
+ 12-12-2016 10:31    +
+ 		+ + + + +
+ Added to draft V4.8.2
+
+ + diff --git a/docs/mantis/CR7448.md b/docs/mantis/CR7448.md new file mode 100644 index 0000000000000000000000000000000000000000..0d5502c77f707598fa96276d336330d2a6936b63 --- /dev/null +++ b/docs/mantis/CR7448.md @@ -0,0 +1,930 @@ + + + + + + + + + + + + + 0007448: Allowing multiple encodings for TTCN-3 types - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007448Part 01: TTCN-3 Core LanguageNew Featurepublic08-07-2016 12:1412-12-2016 18:22
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PriorityhighSeveritymajorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.8.1 (published 2016-07) 
Target Versionv4.9.1 (published 2017-05)Fixed in Versionv4.9.1 (published 2017-05) 
Clause Reference(s)Many
Source (company - Author)L.M.Ericsson
Summary0007448: Allowing multiple encodings for TTCN-3 types
DescriptionToday the type of encoding of the test data is not fixed in the specification in all cases. The simplest example is that IoT common service level data is specified at the abstract level and can be encoded by XML or by JSON, in the discretion of the vendor. The abstract data structure can well be defined in TTCN-3, however the different possible types of encoding is not supported by the language.
+Therefore TTCN-3 shall, as well, be able to encode and decode the same abstract data structures in different encodings.
+
+We ask to resolve the CR with urgency, as oneM2M is currently writing the conformance test suite, where this problem has been raised. The project will finish by end of the year, that means they need tool support ASAP.
+
+Proposed solution can be found in the attached file.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0007445closed Tomas Urban Part 01: TTCN-3 Core Language usage of encode/variant attributes should be enhanced 
related to 0007353closed Gyorgy Rethy Part 01: TTCN-3 Core Language attributes should be attachable to their definition only 
related to 0007451closed Gyorgy Rethy Part 01: TTCN-3 Core Language Multiple occurrence of an attribute 
related to 0007459closed Gyorgy Rethy Part 01: TTCN-3 Core Language the overwriting rules for attributes and the examples should be written more consistent 
related to 0007524closed Tomas Urban Part 06: TTCN-3 Control Interface TCI extension for multiple attributes 
Attached Filesdocx Allowing multiple encodings of TTCN PA3.docx (30,489) 08-07-2016 12:16
http://oldforge.etsi.org/mantis/file_download.php?file_id=3412&type=bug
docx CR7448-1.docx (167,050) 16-08-2016 16:21
http://oldforge.etsi.org/mantis/file_download.php?file_id=3464&type=bug
docx CR7448-V2.docx (118,202) 17-08-2016 15:15
http://oldforge.etsi.org/mantis/file_download.php?file_id=3476&type=bug
docx CR7448-3.docx (170,626) 18-08-2016 09:43
http://oldforge.etsi.org/mantis/file_download.php?file_id=3486&type=bug
docx CR7448-4.docx (129,174) 18-08-2016 15:28
http://oldforge.etsi.org/mantis/file_download.php?file_id=3492&type=bug
docx CR7448-5.docx (129,427) 19-08-2016 13:24
http://oldforge.etsi.org/mantis/file_download.php?file_id=3499&type=bug
docx CR7448-6.docx (127,120) 19-08-2016 14:35
http://oldforge.etsi.org/mantis/file_download.php?file_id=3503&type=bug
docx CR7448-7.docx (185,850) 16-11-2016 11:21
http://oldforge.etsi.org/mantis/file_download.php?file_id=3532&type=bug
docx CR7448-8.docx (132,164) 16-11-2016 15:09
http://oldforge.etsi.org/mantis/file_download.php?file_id=3541&type=bug
docx CR7448-9.docx (133,532) 17-11-2016 09:50
http://oldforge.etsi.org/mantis/file_download.php?file_id=3547&type=bug
Issue History
Date ModifiedUsernameFieldChange
08-07-2016 12:14Gyorgy RethyNew Issue
08-07-2016 12:16Gyorgy RethyFile Added: Allowing multiple encodings of TTCN PA3.docx
11-07-2016 10:27Jacob Wieland - SpirentRelationship addedrelated to 0007445
11-07-2016 10:28Jacob Wieland - SpirentRelationship addedrelated to 0007353
18-07-2016 09:59Jens GrabowskiAssigned To => Tomas Urban
18-07-2016 09:59Jens GrabowskiStatusnew => assigned
19-07-2016 16:10Tomas UrbanNote Added: 0013993
19-07-2016 16:11Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
19-07-2016 16:11Tomas UrbanStatusassigned => feedback
20-07-2016 12:03Gyorgy RethyNote Added: 0014005
20-07-2016 12:03Gyorgy RethyStatusfeedback => assigned
20-07-2016 12:04Gyorgy RethyNote Edited: 0014005bug_revision_view_page.php?bugnote_id=14005#r302
20-07-2016 12:07Gyorgy RethyNote Edited: 0014005bug_revision_view_page.php?bugnote_id=14005#r303
20-07-2016 12:07Gyorgy RethyAssigned ToGyorgy Rethy => Tomas Urban
20-07-2016 12:09Gyorgy RethyNote Edited: 0014005bug_revision_view_page.php?bugnote_id=14005#r304
20-07-2016 16:07Tomas UrbanNote Added: 0014012
20-07-2016 16:08Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
20-07-2016 16:08Tomas UrbanStatusassigned => feedback
21-07-2016 08:25Tomas UrbanNote Edited: 0014012bug_revision_view_page.php?bugnote_id=14012#r306
21-07-2016 09:46Gyorgy RethyNote Added: 0014024
21-07-2016 09:46Gyorgy RethyStatusfeedback => assigned
21-07-2016 09:46Gyorgy RethyAssigned ToGyorgy Rethy => Tomas Urban
02-08-2016 10:50Martin HauchNote Added: 0014041
02-08-2016 13:03Gyorgy RethyNote Added: 0014042
02-08-2016 13:46Gyorgy RethyNote Added: 0014043
02-08-2016 13:46Gyorgy RethyNote Edited: 0014042bug_revision_view_page.php?bugnote_id=14042#r312
16-08-2016 16:21Tomas UrbanFile Added: CR7448-1.docx
16-08-2016 16:24Tomas UrbanNote Added: 0014114
16-08-2016 16:24Tomas UrbanAssigned ToTomas Urban => Jens Grabowski
16-08-2016 16:24Tomas UrbanStatusassigned => confirmed
16-08-2016 16:27Tomas UrbanRelationship addedrelated to 0007451
17-08-2016 11:05Jacob Wieland - SpirentTarget Version => v4.9.1 (published 2017-05)
17-08-2016 15:15Jens GrabowskiFile Added: CR7448-V2.docx
17-08-2016 15:17Jens GrabowskiNote Added: 0014134
17-08-2016 15:17Jens GrabowskiAssigned ToJens Grabowski => Tomas Urban
17-08-2016 15:17Jens GrabowskiStatusconfirmed => assigned
18-08-2016 09:43Tomas UrbanFile Added: CR7448-3.docx
18-08-2016 09:48Tomas UrbanNote Added: 0014150
18-08-2016 09:48Tomas UrbanAssigned ToTomas Urban => Kristóf Szabados
18-08-2016 09:48Tomas UrbanStatusassigned => confirmed
18-08-2016 09:49Tomas UrbanRelationship addedrelated to 0007459
18-08-2016 15:28Jacob Wieland - SpirentFile Added: CR7448-4.docx
18-08-2016 15:29Jacob Wieland - SpirentNote Added: 0014158
18-08-2016 16:44Gyorgy RethyNote Added: 0014161
19-08-2016 13:24Kristóf SzabadosFile Added: CR7448-5.docx
19-08-2016 13:26Kristóf SzabadosNote Added: 0014178
19-08-2016 13:26Kristóf SzabadosAssigned ToKristóf Szabados => Tomas Urban
19-08-2016 13:26Kristóf SzabadosStatusconfirmed => assigned
19-08-2016 14:35Kristóf SzabadosFile Added: CR7448-6.docx
19-08-2016 14:36Kristóf SzabadosNote Added: 0014183
14-11-2016 15:38Jens GrabowskiNote Added: 0014230
16-11-2016 11:01Tomas UrbanFile Added: CR7448-7.docx
16-11-2016 11:02Tomas UrbanNote Added: 0014259
16-11-2016 11:02Tomas UrbanAssigned ToTomas Urban => Jacob Wieland - Spirent
16-11-2016 11:02Tomas UrbanStatusassigned => confirmed
16-11-2016 11:15Tomas UrbanRelationship addedrelated to 0007524
16-11-2016 11:21Tomas UrbanFile Deleted: CR7448-7.docx
16-11-2016 11:21Tomas UrbanFile Added: CR7448-7.docx
16-11-2016 15:09Jacob Wieland - SpirentFile Added: CR7448-8.docx
16-11-2016 15:10Jacob Wieland - SpirentNote Added: 0014274
16-11-2016 15:10Jacob Wieland - SpirentStatusconfirmed => resolved
16-11-2016 15:10Jacob Wieland - SpirentFixed in Version => v4.9.1 (published 2017-05)
16-11-2016 15:10Jacob Wieland - SpirentResolutionopen => fixed
16-11-2016 15:10Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
17-11-2016 09:50Kristóf SzabadosAssigned ToGyorgy Rethy => Kristóf Szabados
17-11-2016 09:50Kristóf SzabadosStatusresolved => feedback
17-11-2016 09:50Kristóf SzabadosResolutionfixed => reopened
17-11-2016 09:50Kristóf SzabadosFile Added: CR7448-9.docx
17-11-2016 09:52Kristóf SzabadosNote Added: 0014288
17-11-2016 09:52Kristóf SzabadosAssigned ToKristóf Szabados => Jens Grabowski
17-11-2016 09:52Kristóf SzabadosStatusfeedback => assigned
17-11-2016 11:53Jens GrabowskiNote Added: 0014300
17-11-2016 11:54Jens GrabowskiStatusassigned => resolved
17-11-2016 11:54Jens GrabowskiResolutionreopened => fixed
17-11-2016 11:54Jens GrabowskiAssigned ToJens Grabowski => Gyorgy Rethy
12-12-2016 18:22Gyorgy RethyNote Added: 0014395
12-12-2016 18:22Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0013993) +
+ Tomas Urban    +
+ 19-07-2016 16:10    +
+ 		+ + + + +
+ The part of the proposal concerning the way how different encodings and associated variants are specified (multiple encode statements, variants with an encode prefix and a colon) is acceptable without any objections.
+
+In the case of selection the actual encoding the STF proposes to use the static approach. We assume that there's (one or more global PDU) containing potentially complicated structure of elements with multiple encodings and variants. The desired encoding and the associated set of variants will be selected by creating an alias type (or template) with a dedicated "filtering" attribute. Please check the following example:
+
+type Payload {
+    XSD.Integer foo,
+    XSD.Float bar
+} with {
+  encode "XML";
+  encode "Jason";
+  variant "XML":"name as uncapitalized"
+  variant "Jason":"name as 'dt'"
+}
+
+type record PDU {
+  Payload payload
+} with {
+  encode "XML";
+  encode "Jason";
+  variant "XML":"element"; // example of an XML variant
+  variant "JSON":"name as 'pd'"; // example of a Jason variant
+}
+
+type PDU XmlPDU with { encode @only "XML" }
+// This definition removes all Jason related attributes and keeps XML (on all
+// levels), so that the XmlPDU type is equal to:
+// type record XmlPDU {
+// Payload payload
+// } with {
+// encode "XML";
+// variant "element";
+// variant(payload) "name as uncapitalized";
+// }
+
+type PDU JasonPDU { encode @only "JSON" }
+// type record JasonPDU {
+// Payload payload
+// } with {
+// encode "Jason";
+// variant "name as 'pd'";
+// variant(payload) "name as 'dt'";
+// }
+
+Could you please comment if the @only filter would work for you? It should be possible to write a universal test suite for XML and Jason with it. You will still need two different receive branches, but handling can be common for both of them as the type structures are equal.
+
+The main advantage of the @only modifier is that it doesn't require complicated changes in the receiving, sending, encoding and decoding statements and the impact on the TCI will be minimal. It is also easily applicable to protocol stacks.
+
+
+
+ + + + + + + + + + +
+ (0014005) +
+ Gyorgy Rethy    +
+ 20-07-2016 12:03    +
(edited on: 20-07-2016 12:09)
+ 		+ + + + +
+ Depending on what the question is:
+- if @only is proposed *in addition* what the CR requests (i.e. allow types with multiple encodings, where the actual codec is chosen by the TE based on a runtime configuration parameter), it is acceptable, but is useless, superfluous; it doesn't solve dynamic encoding control either;
+- if all the multiple encoding problem is wanted to be solved by aliases, it is not acceptable. It is principally wrong approach. It would not need any language extension, just a clarification of overwriting rules for encode and variant attributes for aliases.
+
+Considering the below type definitions;
+The requested solution looks like:
+
+template PDU t_PDU := { payload := { foo := 42, bar := 5.0 }
+
+function f() runs on CT {
+  P.send (t_PDU);
+  alt {
+      [] P.receive (PDU:?){...} //note, that receiving a "wrongly" encoded message, i.e. of encoded by the 'another' encoding causes a runtime error here
+  }
+  ...
+}
+
+----------------------------------------------------------------------
+The code with the proposed alias solution would look like:
+
+template XmlPDU t_PDUxml := { payload := { foo := 42, bar := 5.0 }
+template JasonPDU t_PDUjson := t_PDUxml;
+
+function f() runs on CT {
+  if (modulepar_encoding=="XML") {P.send (t_PDUxml)};
+  elseif (modulepar_encoding=="JSON") {P.send (t_PDUjson);
+  alt {
+      [modulepar_encoding=="XML"] P.receive (XmlPDU :?){...} //note, that if receiving receiving a PDU encoded with "Jason" it will cause a deadlock of the component here
+      [modulepar_encoding=="Jason"] P.receive (JasonPDU:?){...}// the same for receiving an "XML" encoded message
+//Pls. note, if "XML" encoding is expected from the SUT, but it uses "Jason" instead, this shall be a fail verdict as well!
+  }
+  ...
+}
+
+Drawbacks of the proposed alias solution:
+- huge amount of superfluous code, to be written for nothing, with all its readability and other consequences (the TE could choose the needed encoding itself, instead of this, the user shall explicitly control it from the TTCN-3 code);
+- horrible maintain-ability: if a new, 3rd (or the 2nd) encoding is introduced, the "whole" TTCN-3 code has to be updated: new type aliases, new template aliases, new if~ and alt branches everywhere... if adding a new if~ or alt branch is forgotten at a single place, or a wrong template alias is used (a typical copy-paste error), the error cannot be discovered @ compile time, only @ runtime, by a wrong test case result (if, at all);
+for example, in standard test suites, where the code is typically written by the standard body, but is not executed, this would cause a nightmare.
+
+
+
+
+
+ + + + + + + + + + +
+ (0014012) +
+ Tomas Urban    +
+ 20-07-2016 16:07    +
(edited on: 21-07-2016 08:25)
+ 		+ + + + +
+ We propose the following solution to the dynamic problem:
+
+a) Keep the @only modifier for static filtering (for the users that might find some use of it).
+b) Introduce a dynamic solution using a new encode statement:
+( PortReference | "all" "port" | "self") "." encode "(" (Type | all) "," Expression ")"
+
+The encode statement would activate an encoding filter for a particular port, all port or a whole component. The filter would apply to a particular type, its part (useful for protocol stacks) or to all messages passed to the codec. It would basically do the same thing as the @only modifier, but dynamicly.
+
+Example for our XML/Jason case:
+modulepar universal charstring ENCODING; // set to "XML" by TCI-TM
+self.encode(PDU, ENCODING); // Disables all encodings that are not "XML"
+    // and variants related to them
+p.send(PDU:{...}}; // When the message is sent out, only the "XML" encode
+    // attribute and related "XML" variants are visible to the codec
+
+// in order to go through all encodings:
+type record of universal charstring TEnc;
+var TEnc v_enc := {...} // dynamically specify acceptable encodings
+var integer i := 0;
+p.encode(PDU, v_enc[i]);
+alt {
+  [] p.receive(PDU:?)
+  // [] ... other alternatives
+  [else] {
+     i := i + 1;
+     if (i < lengthof(v_enc)) {
+       p.encode(PDU, v_enc[i]);
+       repeat;
+     }
+  }
+}
+
+The advantage of this approach is that we don't have to change the syntax of the sending/receiving operations and of the enc_value and dec_value functions. It contains support of protocol stacks as an extended type reference can be used as the first parameter.
+
+Gyorgy, could you please say if it is acceptable for you?
+
+
+
+
+
+ + + + + + + + + + +
+ (0014024) +
+ Gyorgy Rethy    +
+ 21-07-2016 09:46    +
+ 		+ + + + +
+ If I understand correctly:
+- several encode attributes can be attached to a type (group module ...) and variant attributes can be scoped with the syntax proposed by the CR;
+- P.encode(PDU,modPar_encoding); activates a concrete encoding to a given port
+- all port.encode(PDU,modPar_encoding); activates a concrete encoding to all ports of the given component, but NOT for encvalue/decvalue-s
+- self.encode(PDU,modPar_encoding); activates a concrete encoding to all ports AND encvalue/decvalue-s of the given component
+- in addition, a new optional parameter will allow select/change the default encoding for individual encvalue/decvalue/encvalue_unichar/decvalue_unichar calls
+
+This solution, as a whole, is fine with me.
+
+
+
+ + + + + + + + + + +
+ (0014041) +
+ Martin Hauch    +
+ 02-08-2016 10:50    +
+ 		+ + + + +
+ Questions:
+Where are the types defined, which should be used for "JSON" and "XML" coding?
+Definitions from XSD:
+"Part 9: Using XML schema with TTCN-3" does not define variant "XML":"element"; (or other "XML" renamings for elements or attributes). Current "Part 11: Using JSON with TTCN-3" does not define variant "JSON":name as 'pd'"
+Should the syntax for variant attributes be changed to bind the variant-atrribute information to an encoding-rule in case of more than 1 encoding-rule is assigned?
+How should JSON-variants be added to these from XSD converted types?
+How should xsd-defined types be encoded in JSON?
+
+Definitions from TTCN:
+I think this should work. The encode- and variant-attributes could be defined for all types (as shown in your example), respecting the possible attribute-values defined in the documents "Part 9: Using XML schema with TTCN-3" and "Part 11: Using JSON with TTCN-3".
+
+
+
+ + + + + + + + + + +
+ (0014042) +
+ Gyorgy Rethy    +
+ 02-08-2016 13:03    +
(edited on: 02-08-2016 13:46)
+ 		+ + + + +
+ Thanks Martin, good points.
+I think both Part-9 and draft Part-11 shall be updated to allow generating the variant scopings automatically (for backward compatibility and readibility reasons this should be a user-choice converter configuration parameter).
+As JSON doesn't have a schema, no JSON encoding instructions can be generated automatically, they always need to be added manually to TTCN-3 files. Therefore, the output of an XML converter need to be decorated with JSON variant attributes manually.
+
+
+
+
+
+ + + + + + + + + + +
+ (0014043) +
+ Gyorgy Rethy    +
+ 02-08-2016 13:46    +
+ 		+ + + + +
+ During the internal discussions we were also discussing a possible compact syntax to assign an encoding instruction to multiple encode-s, something like
+
+variant (resourceName){"XML","JSON"}:"name as 'rn'";
+
+at the end this feature wasn't included into the initial proposal, to keep it simple.
+
+However, now ETSI has raised the same issue, as the main attribute to be used in the IoT conformance tests is name as, which is the same in both XML and JSON. Another ETSI's point is that e.g. if a new, 3rd encoding is added, it is easier to add the name of the new encoding to the list of encodes, than copy-paste-change all the variants for the new encoding, which would make the code long, nasty and hardly readable.
+
+Could you please also consider a compact syntax, to add an encoding instruction to multiple encodings by a single variant?
+
+
+
+ + + + + + + + + + +
+ (0014114) +
+ Tomas Urban    +
+ 16-08-2016 16:24    +
+ 		+ + + + +
+ Proposal uploaded. The document also contains a resolution for all related CRs. Please check.
+
+
+
+ + + + + + + + + + +
+ (0014134) +
+ Jens Grabowski    +
+ 17-08-2016 15:17    +
+ 		+ + + + +
+ Please check again. Ericsson should also proofread before resolving the issue.
+
+
+
+ + + + + + + + + + +
+ (0014150) +
+ Tomas Urban    +
+ 18-08-2016 09:48    +
+ 		+ + + + +
+ I am fine with the corrections. I only made a couple of minor formating changes in the document.
+
+Kristóf, could you please look at the document too and discuss the matter with György?
+
+
+
+ + + + + + + + + + +
+ (0014158) +
+ Jacob Wieland - Spirent    +
+ 18-08-2016 15:29    +
+ 		+ + + + +
+ I have added/changed multiple places according to our discussions.
+
+Please review.
+
+
+
+ + + + + + + + + + +
+ (0014161) +
+ Gyorgy Rethy    +
+ 18-08-2016 16:44    +
+ 		+ + + + +
+ Hi, in general the proposal looks fine, but a few comments/questions:
+
+1) Regarding the @local modifier I’m not sure if it’s really needed: while it complicates the language and the tools, I can see little practical use. Let see the example from the standard:
+    module M {
+        type record MyRec {
+            integer field1,
+            integer field1,
+        } with { encode @local "CodecB" }
+        // the record type MyRec will be encoded with CodecB, but its fields with CodecA,
+        // because local attribute CodecB doesn’t affect elements of the MyRec type.
+    } with { encode "CodecA" }
+
+In reality, typically protocol messages and their fields have encode attributes, in which case fields are practically always some constrained types, having their own type definitions (and thus inheriting the attribute associated to the group/module). Maybe boolean fields are exceptions, but I haven’t seen any of them being encoded differently than the enclosing type; and if, it is more intuitive to add their encoding to the field directly (than to understand what @local means):
+    module M {
+
+type integer (0..255) Intfield;
+
+type record MyRec {
+  Intfield field1,
+  Intfield field2,
+  boolean field3
+} with { encode "CodecB";//this does not apply to fields field1 and field2 acc. to the previous rule
+         encode (field3) “CodecA”}
+} with { encode "CodecA" }
+
+2) I think it would be more secure if variant attribute without encode reference is allowed only, if there is just a single encode applied to the scope (i.e. not to have "global variant"s). Once a new encoding is added to a module, all variants has to be re-checked anyway, during which it is easy to copy-paste the encoding scope in front of the already existing variant. But with the current "global variant" rule, variants forgotten to be cross-checked and scoped, will automatically start effecting on the new encoding as well.
+
+3) If considering the example:
+    // Modifying list of allowed encodings
+    type Int Int2 with {
+        encode "CodecA"; // variants "CodecA"."Rule1" and "GlobalRule" are kept
+        encode "CodecC"; variant "CodecC"."Rule6"; // new encoding and related variant
+        // "CodecB" encoding and related variant are discarded as "CodecB" is not
+        // explicitly referenced
+    }
+
+It is unclear why the @only modifier is needed.
+In the example
+    // Selecting encoding with an @only modifier
+    type MyRecord MyRecord2 with {
+        encode @only (field1) "CodecB"; // field1 will be encoded with CodecB
+        encode @only "CodecA" // the record and field2 will be encoded with CodecA
+    }
+Applying encode (field1) "CodecB" and encode "CodecA" would have exactly the same effect: whatever other encodings applied to MyRecord and MyRecord.field1 are simply discarded.
+
+4) Has ETSI’s request to allow associating a variant to several encodings with a single statement been considered? Example (syntax below is appropriate, any suitable syntax will do it):
+    module M {
+type record MyRecX {
+  Intfield field1,
+  Intfield field2,
+  boolean field3
+} with { variant(field1) {"CodecA”,”CodecB”}.”name as ‘f1’”;
+         variant(field2) {"CodecA”,”CodecB”}.”name as ‘f2’”;
+         variant(field3) {"CodecA”,”CodecB”}.”name as ‘f3’”}
+
+} with { encode "CodecA" }
+
+
+
+ + + + + + + + + + +
+ (0014178) +
+ Kristóf Szabados    +
+ 19-08-2016 13:26    +
+ 		+ + + + +
+ Added clarification, that variants without explicit encoding relation are implicitly related to all encodings in effect.
+
+
+
+ + + + + + + + + + +
+ (0014183) +
+ Kristóf Szabados    +
+ 19-08-2016 14:36    +
+ 		+ + + + +
+ Added example to show the difference between encodes with and without @only.
+
+
+
+ + + + + + + + + + +
+ (0014230) +
+ Jens Grabowski    +
+ 14-11-2016 15:38    +
+ 		+ + + + +
+ STF discussion:
+1) @local will be kept
+2) no global variants for multiple encodings
+4) one variant for multiple encodings by explicit naming
+
+3) @only will be skipped (no different scope level, same scope level)
+
+- Precedence rules for 3) will be checked for tools represented in STF.
+
+
+
+ + + + + + + + + + +
+ (0014259) +
+ Tomas Urban    +
+ 16-11-2016 11:02    +
+ 		+ + + + +
+ Specification updated according to STF discussion conclusion. Please review.
+
+
+
+ + + + + + + + + + +
+ (0014274) +
+ Jacob Wieland - Spirent    +
+ 16-11-2016 15:10    +
+ 		+ + + + +
+ added a missing closing parenthesis in BNF, otherwise ok, ready for implementation
+
+
+
+ + + + + + + + + + +
+ (0014288) +
+ Kristóf Szabados    +
+ 17-11-2016 09:52    +
+ 		+ + + + +
+ Corrected some typos.
+Added a note before example 4.
+Corrected example in section 27.9 (in the testcase ContainerType needed to be changed to PDU as that is the name of the type)
+
+
+
+ + + + + + + + + + +
+ (0014300) +
+ Jens Grabowski    +
+ 17-11-2016 11:53    +
+ 		+ + + + +
+ OK, ready for implementation.
+
+
+
+ + + + + + + + + + +
+ (0014395) +
+ Gyorgy Rethy    +
+ 12-12-2016 18:22    +
+ 		+ + + + +
+ Added to draft V4.8.2
+
+ + diff --git a/docs/mantis/CR7450.md b/docs/mantis/CR7450.md new file mode 100644 index 0000000000000000000000000000000000000000..92b2aa88c0b64482eee8d95a6217b090df4bf49b --- /dev/null +++ b/docs/mantis/CR7450.md @@ -0,0 +1,203 @@ + + + + + + + + + + + + + 0007450: enumerated types should be compatible on par with other structured types - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007450Part 01: TTCN-3 Core LanguageNew Featurepublic15-07-2016 12:5016-12-2016 19:21
ReporterJacob Wieland - Spirent 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.8.1 (published 2016-07) 
Target Versionv4.9.1 (published 2017-05)Fixed in Versionv4.9.1 (published 2017-05) 
Clause Reference(s)6.3.2.1
Source (company - Author)Spirent - Jacob Wieland
Summary0007450: enumerated types should be compatible on par with other structured types
DescriptionAt the moment, an enumerated type (and its values) is only compatible to itself, but not to any other enumerated type.
+
+That means that two structured types which contain an enumerated type and have the same form in every aspect also are not compatible to each other, even though that is true for all base types and all other structured types.
+
+Example:
+
+type record A {
+  integer i (1..200) optional
+}
+
+is compatible to
+
+type record B {
+  integer j (1..200) optional
+}
+
+but
+
+type record A2 {
+  enumerated { a, b } e optional
+}
+
+is not compatible to
+
+type record B2 {
+  enumerated { a, b } f optional
+}
+
+This, in my view, is an unnecessary language inconsistency which, for instance, prevents simple value-translation from an old, compatible type to a new one.
+
+It is also unclear why this restriction is imposed at all.
+
+Therefore, I propose to add a type-compatibility rule that states that any enumerated value b of enumerated type B is compatible with enumerated type A if an enumerated value with the same name also exists in A and has the same number associated with it as b in B. Naturally, then, an enumerated type B is compatible to an enumerated type A if all its values are compatible with A.
+
+If this rule is introduced, an enumerated type essentially behaves like a restricted integer type, though still not compatible with integer types but only with other enumerated types.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7450.docx (151,319) 19-07-2016 15:51
http://oldforge.etsi.org/mantis/file_download.php?file_id=3418&type=bug
docx CR7450-2.docx (170,763) 19-07-2016 16:33
http://oldforge.etsi.org/mantis/file_download.php?file_id=3419&type=bug
Issue History
Date ModifiedUsernameFieldChange
15-07-2016 12:50Jacob Wieland - SpirentNew Issue
18-07-2016 09:56Jens GrabowskiAssigned To => Jacob Wieland - Spirent
18-07-2016 09:56Jens GrabowskiStatusnew => assigned
19-07-2016 15:51Jacob Wieland - SpirentFile Added: CR7450.docx
19-07-2016 15:52Jacob Wieland - SpirentNote Added: 0013992
19-07-2016 15:52Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Tomas Urban
19-07-2016 15:52Jacob Wieland - SpirentStatusassigned => confirmed
19-07-2016 16:33Tomas UrbanFile Added: CR7450-2.docx
19-07-2016 16:36Tomas UrbanNote Added: 0013994
19-07-2016 16:36Tomas UrbanAssigned ToTomas Urban => Jacob Wieland - Spirent
21-07-2016 11:26Jacob Wieland - SpirentNote Added: 0014029
21-07-2016 11:26Jacob Wieland - SpirentStatusconfirmed => resolved
21-07-2016 11:26Jacob Wieland - SpirentFixed in Version => v4.8.1 (published 2016-07)
21-07-2016 11:26Jacob Wieland - SpirentResolutionopen => fixed
21-07-2016 11:26Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
16-12-2016 19:21Gyorgy RethyNote Added: 0014448
16-12-2016 19:21Gyorgy RethyStatusresolved => closed
16-12-2016 19:21Gyorgy RethyFixed in Versionv4.8.1 (published 2016-07) => v4.9.1 (published 2017-05)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0013992) +
+ Jacob Wieland - Spirent    +
+ 19-07-2016 15:52    +
+ 		+ + + + +
+ please review
+
+
+
+ + + + + + + + + + +
+ (0013994) +
+ Tomas Urban    +
+ 19-07-2016 16:36    +
+ 		+ + + + +
+ Minor changes in the text so that it is compatible with the section 6.3.0.
+
+Please review and if fine, it can be marked as resolved.
+
+A separate CR will be submited for the terminology of the union compatibility.
+
+
+
+ + + + + + + + + + +
+ (0014029) +
+ Jacob Wieland - Spirent    +
+ 21-07-2016 11:26    +
+ 		+ + + + +
+ text is ok
+
+
+
+ + + + + + + + + + +
+ (0014448) +
+ Gyorgy Rethy    +
+ 16-12-2016 19:21    +
+ 		+ + + + +
+ Added to draft V4.8.2
+
+ + diff --git a/docs/mantis/CR7451.md b/docs/mantis/CR7451.md new file mode 100644 index 0000000000000000000000000000000000000000..1977314bb5c84cad0c8d92a210abb377f0231ae3 --- /dev/null +++ b/docs/mantis/CR7451.md @@ -0,0 +1,199 @@ + + + + + + + + + + + + + 0007451: Multiple occurrence of an attribute - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007451Part 01: TTCN-3 Core LanguageTechnicalpublic18-07-2016 13:4912-12-2016 18:21
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.9.1 (published 2017-05)Fixed in Versionv4.9.1 (published 2017-05) 
Clause Reference(s)27
Source (company - Author)STF 514
Summary0007451: Multiple occurrence of an attribute
DescriptionIt would be feasible to describe precise rules for multiple occurrences of an attribute. These rules are missing. Some of them will be introduced as a part of resolution of 0007448.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0007448closed Gyorgy Rethy Allowing multiple encodings for TTCN-3 types 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
18-07-2016 13:49Tomas UrbanNew Issue
18-07-2016 13:49Tomas UrbanStatusnew => assigned
18-07-2016 13:49Tomas UrbanAssigned To => Tomas Urban
18-07-2016 13:50Tomas UrbanNote Added: 0013980
16-08-2016 16:27Tomas UrbanRelationship addedrelated to 0007448
16-08-2016 16:27Tomas UrbanNote Added: 0014118
16-08-2016 16:27Tomas UrbanAssigned ToTomas Urban => Jens Grabowski
16-08-2016 16:27Tomas UrbanStatusassigned => confirmed
17-08-2016 11:28Jacob Wieland - SpirentProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
17-08-2016 11:28Jacob Wieland - SpirentTarget Version => v4.9.1 (published 2017-05)
18-08-2016 10:58Jens GrabowskiAssigned ToJens Grabowski => Kristóf Szabados
18-08-2016 10:58Jens GrabowskiStatusconfirmed => assigned
18-08-2016 10:58Jens GrabowskiStatusassigned => confirmed
17-11-2016 09:54Kristóf SzabadosNote Added: 0014289
17-11-2016 09:54Kristóf SzabadosStatusconfirmed => resolved
17-11-2016 09:54Kristóf SzabadosFixed in Version => v4.10.1 (published 2018-05)
17-11-2016 09:54Kristóf SzabadosResolutionopen => fixed
17-11-2016 14:20Kristóf SzabadosNote Added: 0014310
17-11-2016 14:20Kristóf SzabadosStatusresolved => feedback
17-11-2016 14:20Kristóf SzabadosResolutionfixed => reopened
17-11-2016 14:20Kristóf SzabadosStatusfeedback => resolved
17-11-2016 14:20Kristóf SzabadosFixed in Versionv4.10.1 (published 2018-05) => v4.9.1 (published 2017-05)
17-11-2016 14:20Kristóf SzabadosResolutionreopened => fixed
17-11-2016 14:20Kristóf SzabadosStatusresolved => feedback
17-11-2016 14:20Kristóf SzabadosResolutionfixed => reopened
17-11-2016 14:20Kristóf SzabadosStatusfeedback => resolved
17-11-2016 14:20Kristóf SzabadosResolutionreopened => fixed
17-11-2016 14:20Kristóf SzabadosAssigned ToKristóf Szabados => Gyorgy Rethy
12-12-2016 18:21Gyorgy RethyNote Added: 0014393
12-12-2016 18:21Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0013980) +
+ Tomas Urban    +
+ 18-07-2016 13:50    +
+ 		+ + + + +
+ STF discussion: append attributes using comma as a separator
+
+
+
+ + + + + + + + + + +
+ (0014118) +
+ Tomas Urban    +
+ 16-08-2016 16:27    +
+ 		+ + + + +
+ Resolved as a part of resolution of the related CR 0007448.
+
+
+
+ + + + + + + + + + +
+ (0014289) +
+ Kristóf Szabados    +
+ 17-11-2016 09:54    +
+ 		+ + + + +
+ Resolved as part of CR 7448
+
+
+
+ + + + + + + + + + +
+ (0014310) +
+ Kristóf Szabados    +
+ 17-11-2016 14:20    +
+ 		+ + + + +
+ incorrectly assigned at resolved
+
+
+
+ + + + + + + + + + +
+ (0014393) +
+ Gyorgy Rethy    +
+ 12-12-2016 18:21    +
+ 		+ + + + +
+ See resolution in CR 7448
+
+ + diff --git a/docs/mantis/CR7452.md b/docs/mantis/CR7452.md new file mode 100644 index 0000000000000000000000000000000000000000..02fb634a2c1584814fe5f51fa976fb26e2bc811a --- /dev/null +++ b/docs/mantis/CR7452.md @@ -0,0 +1,280 @@ + + + + + + + + + + + + + 0007452: Function for displaying attribute content - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007452Part 01: TTCN-3 Core LanguageTechnicalpublic18-07-2016 14:0113-12-2016 10:42
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.9.1 (published 2017-05)Fixed in Versionv4.9.1 (published 2017-05) 
Clause Reference(s)27
Source (company - Author)STF 514
Summary0007452: Function for displaying attribute content
DescriptionAt the moment, it is not possible to check an attribute value in the TTCN-3 languange. Such functionality is avalibable in TCI or through proprietary tool functions. The first option is quite clumsy and requires to execute the test suite, the second one cannot be standardized and used in conformance tests. As the result, attributes are not properly tested by the conformance test suite.
+
+Proposal: Add a function (or functions) that would print attribute values.
+
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7452-1.docx (19,317) 19-07-2016 14:26
http://oldforge.etsi.org/mantis/file_download.php?file_id=3417&type=bug
docx CR7452-2.docx (24,332) 18-08-2016 11:48
http://oldforge.etsi.org/mantis/file_download.php?file_id=3487&type=bug
docx CR7452-V3.docx (20,723) 19-08-2016 08:28
http://oldforge.etsi.org/mantis/file_download.php?file_id=3494&type=bug
docx CR7452-4.docx (25,984) 19-08-2016 08:42
http://oldforge.etsi.org/mantis/file_download.php?file_id=3496&type=bug
Issue History
Date ModifiedUsernameFieldChange
18-07-2016 14:01Tomas UrbanNew Issue
18-07-2016 14:01Tomas UrbanStatusnew => assigned
18-07-2016 14:01Tomas UrbanAssigned To => Tomas Urban
18-07-2016 14:44Tomas UrbanSummaryFunction for displaying an attribute content => Function for displaying attribute content
19-07-2016 14:26Tomas UrbanFile Added: CR7452-1.docx
21-07-2016 08:21Tomas UrbanAssigned ToTomas Urban => Jens Grabowski
21-07-2016 08:23Tomas UrbanNote Added: 0014020
21-07-2016 09:13Jens GrabowskiNote Added: 0014022
22-07-2016 12:22Jens GrabowskiNote Added: 0014035
22-07-2016 12:23Jens GrabowskiAssigned ToJens Grabowski => Tomas Urban
17-08-2016 11:31Jacob Wieland - SpirentProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
17-08-2016 11:32Jacob Wieland - SpirentTarget Version => v4.9.1 (published 2017-05)
18-08-2016 11:48Tomas UrbanFile Added: CR7452-2.docx
18-08-2016 11:48Tomas UrbanNote Added: 0014152
18-08-2016 11:48Tomas UrbanAssigned ToTomas Urban => Jens Grabowski
18-08-2016 11:48Tomas UrbanStatusassigned => confirmed
19-08-2016 08:28Jens GrabowskiFile Added: CR7452-V3.docx
19-08-2016 08:28Jens GrabowskiAssigned ToJens Grabowski => Tomas Urban
19-08-2016 08:28Jens GrabowskiStatusconfirmed => assigned
19-08-2016 08:29Jens GrabowskiNote Added: 0014162
19-08-2016 08:30Jens GrabowskiStatusassigned => confirmed
19-08-2016 08:42Tomas UrbanFile Added: CR7452-4.docx
19-08-2016 08:43Tomas UrbanNote Added: 0014168
19-08-2016 08:43Tomas UrbanStatusconfirmed => resolved
19-08-2016 08:43Tomas UrbanFixed in Version => v4.10.1 (published 2018-05)
19-08-2016 08:43Tomas UrbanResolutionopen => fixed
19-08-2016 08:43Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
13-12-2016 10:42Gyorgy RethyNote Added: 0014404
13-12-2016 10:42Gyorgy RethyStatusresolved => closed
13-12-2016 10:42Gyorgy RethyFixed in Versionv4.10.1 (published 2018-05) => v4.9.1 (published 2017-05)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014020) +
+ Tomas Urban    +
+ 21-07-2016 08:23    +
+ 		+ + + + +
+ Proposal uploaded. The feature uses new operators, because it would be difficult to pass types into an predefined function as type parameters are only available in an external package and cannot be used in the core language specification. The new operators use existing reserved words.
+
+Please check.
+
+
+
+ + + + + + + + + + +
+ (0014022) +
+ Jens Grabowski    +
+ 21-07-2016 09:13    +
+ 		+ + + + +
+ Discussion within the STF required:
+Are several new operators (without new reserved words) are better than one new generic operator with one new keyword?
+
+
+
+ + + + + + + + + + +
+ (0014035) +
+ Jens Grabowski    +
+ 22-07-2016 12:22    +
+ 		+ + + + +
+ STF agreement:
+Instead of function like operators, the dot notation is more appropriate.
+
+Example:
+<Type>.display returns display attribute of <Type>
+
+Tomas to adapt proposal.
+
+
+
+ + + + + + + + + + +
+ (0014152) +
+ Tomas Urban    +
+ 18-08-2016 11:48    +
+ 		+ + + + +
+ Proposal updated according to the STF discussion. Please check.
+
+
+
+ + + + + + + + + + +
+ (0014162) +
+ Jens Grabowski    +
+ 19-08-2016 08:29    +
+ 		+ + + + +
+ A few typos have been removed and some wording ist changed. I you agree, set to resolved and assign to Györy for implementation.
+
+
+
+ + + + + + + + + + +
+ (0014168) +
+ Tomas Urban    +
+ 19-08-2016 08:43    +
+ 		+ + + + +
+ Ready for implementation.
+
+
+
+ + + + + + + + + + +
+ (0014404) +
+ Gyorgy Rethy    +
+ 13-12-2016 10:42    +
+ 		+ + + + +
+ Added to V4.8.2
+
+ + diff --git a/docs/mantis/CR7453.md b/docs/mantis/CR7453.md new file mode 100644 index 0000000000000000000000000000000000000000..fcb3728d164eee9b392284f8b42c98ee5d4677e6 --- /dev/null +++ b/docs/mantis/CR7453.md @@ -0,0 +1,209 @@ + + + + + + + + + + + + + 0007453: Restriction on use of optional attibutes in variables - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007453Part 01: TTCN-3 Core LanguageTechnicalpublic18-07-2016 15:5813-12-2016 10:14
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.9.1 (published 2017-05)Fixed in Versionv4.9.1 (published 2017-05) 
Clause Reference(s)27.7, 6.2.1.0
Source (company - Author)STF 514
Summary0007453: Restriction on use of optional attibutes in variables
DescriptionAccording to the restriction 27.7.a, optional attributes cannot be used for variables. However, there are two examples in the standard which don't follow this restriction (in 6.2.1.0).
+
+Proposal:
+Either lift the restriction and add the rules for a single field assignment (see 0007288 for more details) or keep the restriction as it is and correct the examples.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0007288closed Gyorgy Rethy Not described use cases for optional attribute 
Attached Filesdocx CR7453_proposal.docx (156,091) 17-11-2016 12:36
http://oldforge.etsi.org/mantis/file_download.php?file_id=3554&type=bug
docx CR7453_proposal_v2.docx (178,251) 17-11-2016 14:35
http://oldforge.etsi.org/mantis/file_download.php?file_id=3557&type=bug
Issue History
Date ModifiedUsernameFieldChange
18-07-2016 15:58Tomas UrbanNew Issue
18-07-2016 15:59Tomas UrbanRelationship addedrelated to 0007288
19-07-2016 15:36Tomas UrbanAssigned To => Kristóf Szabados
19-07-2016 15:36Tomas UrbanStatusnew => assigned
19-07-2016 15:40Tomas UrbanNote Added: 0013991
22-07-2016 13:48Kristóf SzabadosNote Added: 0014038
17-08-2016 11:31Jacob Wieland - SpirentProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
17-08-2016 11:55Jacob Wieland - SpirentTarget Version => v4.9.1 (published 2017-05)
17-11-2016 12:00Kristóf SzabadosStatusassigned => confirmed
17-11-2016 12:36Kristóf SzabadosFile Added: CR7453_proposal.docx
17-11-2016 12:36Kristóf SzabadosNote Added: 0014301
17-11-2016 12:36Kristóf SzabadosAssigned ToKristóf Szabados => Tomas Urban
17-11-2016 12:36Kristóf SzabadosStatusconfirmed => assigned
17-11-2016 14:35Tomas UrbanFile Added: CR7453_proposal_v2.docx
17-11-2016 14:40Tomas UrbanNote Added: 0014312
17-11-2016 14:40Tomas UrbanAssigned ToTomas Urban => Kristóf Szabados
17-11-2016 14:40Tomas UrbanStatusassigned => confirmed
17-11-2016 15:27Kristóf SzabadosStatusconfirmed => resolved
17-11-2016 15:27Kristóf SzabadosFixed in Version => v4.9.1 (published 2017-05)
17-11-2016 15:27Kristóf SzabadosResolutionopen => fixed
17-11-2016 15:27Kristóf SzabadosAssigned ToKristóf Szabados => Gyorgy Rethy
13-12-2016 10:14Gyorgy RethyNote Added: 0014402
13-12-2016 10:14Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0013991) +
+ Tomas Urban    +
+ 19-07-2016 15:40    +
+ 		+ + + + +
+ STF discussion: It seems feasible to allow the optional attribute for variables, but it could cause backwards compatibility problems as global implicit omit (e.g. on module level) would affect all variables now. The impact is probably minimal, but it depends on test suites. A question should be sent to vendors and STF 160 if the proposed change affects them anyhow.
+
+
+
+ + + + + + + + + + +
+ (0014038) +
+ Kristóf Szabados    +
+ 22-07-2016 13:48    +
+ 		+ + + + +
+ Please note, that this CR is related to CR 7288.
+If this limitation is lifted (and optional attributes can be attached to variables) it should be defined what the behaviour will be like in the 2nd case of CR 7288.
+
+
+
+ + + + + + + + + + +
+ (0014301) +
+ Kristóf Szabados    +
+ 17-11-2016 12:36    +
+ 		+ + + + +
+ please review
+
+
+
+ + + + + + + + + + +
+ (0014312) +
+ Tomas Urban    +
+ 17-11-2016 14:40    +
+ 		+ + + + +
+ The proposal was mostly OK. However I made some changes:
+
+1. I moved the rule on assignments out of the restriction section, because in fact it is not a restriction, but description of the feature.
+2. I made small changes in wording of the moved rule and the note.
+3. I fixed some wording in the examples
+
+Please check and mark as resolved if you find no more issues.
+
+
+
+ + + + + + + + + + +
+ (0014402) +
+ Gyorgy Rethy    +
+ 13-12-2016 10:14    +
+ 		+ + + + +
+ Added to draft V4.8.2
+
+ + diff --git a/docs/mantis/CR7454.md b/docs/mantis/CR7454.md new file mode 100644 index 0000000000000000000000000000000000000000..b58786e8bdfe44ae3b7a8abbab0781a627a02aab --- /dev/null +++ b/docs/mantis/CR7454.md @@ -0,0 +1,224 @@ + + + + + + + + + + + + + 0007454: Operational semantics for default parameters - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 04: TTCN-3 Operational Semantics
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007454Part 04: TTCN-3 Operational SemanticsTechnicalpublic19-07-2016 08:4218-11-2016 10:42
ReporterTomas Urban 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.5.1 (published 2016-07) 
Target Versionv4.6.1(ongoing)Fixed in Versionv4.6.1(ongoing) 
Clause Reference(s)7.11
Source (company - Author)STF 514
Summary0007454: Operational semantics for default parameters
DescriptionCR 0007294 allows to use component variables, templates and constants from the runs on clause in the expressions specifying default values. Section 7.11 of the operational semantics specification has to be changed accordingly. Since it is not always possible to copy the expression specifying the default value any more (e.g. in the execute and ptc.start statements, the component variables are not accessible), it was suggested that the expression shall be evaluated first and the result shall be appended to the actual parameter list. However, the question is if this doesn't exceed the scope of the chapter 7, because it contains steps that are made on textual level and evaluating an expression is a runtime operation.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0007294closed Gyorgy Rethy Part 01: TTCN-3 Core Language default values/templates of formal parameters should live in the runs-on scope 
Attached Filesdocx CR-7454-Resolution-160721.docx (1,963,592) 21-07-2016 08:24
http://oldforge.etsi.org/mantis/file_download.php?file_id=3427&type=bug
Issue History
Date ModifiedUsernameFieldChange
19-07-2016 08:42Tomas UrbanNew Issue
19-07-2016 08:42Tomas UrbanStatusnew => assigned
19-07-2016 08:42Tomas UrbanAssigned To => Jens Grabowski
19-07-2016 08:44Tomas UrbanRelationship addedrelated to 0007294
20-07-2016 10:52Jens GrabowskiNote Added: 0014001
20-07-2016 10:54Jens GrabowskiNote Added: 0014002
20-07-2016 10:54Jens GrabowskiAssigned ToJens Grabowski => Tomas Urban
20-07-2016 16:45Tomas UrbanNote Added: 0014014
20-07-2016 16:45Tomas UrbanAssigned ToTomas Urban => Jens Grabowski
21-07-2016 08:22Jens GrabowskiNote Added: 0014019
21-07-2016 08:24Jens GrabowskiFile Added: CR-7454-Resolution-160721.docx
21-07-2016 08:24Jens GrabowskiStatusassigned => resolved
21-07-2016 08:24Jens GrabowskiResolutionopen => fixed
17-08-2016 11:52Jacob Wieland - SpirentStatusresolved => feedback
17-08-2016 11:52Jacob Wieland - SpirentResolutionfixed => reopened
17-08-2016 11:52Jacob Wieland - SpirentTarget Versionv4.5.1 (published 2016-07) => v4.6.1(ongoing)
17-08-2016 11:54Jacob Wieland - SpirentStatusfeedback => resolved
17-08-2016 11:54Jacob Wieland - SpirentFixed in Version => v4.6.1(ongoing)
17-08-2016 11:54Jacob Wieland - SpirentResolutionreopened => fixed
18-11-2016 10:42Jens GrabowskiNote Added: 0014332
18-11-2016 10:42Jens GrabowskiStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014001) +
+ Jens Grabowski    +
+ 20-07-2016 10:52    +
+ 		+ + + + +
+ Proposes resolution: Change of 7.11 in Operational Semantics to:
+
+7.11 Adding default values of parameters
+
+Formal parameters may have default values. If no actual parameter is provided in a specific invocation, then the default value is added to the actual parameter list. If list notation has been used for the actual parameter list, then the default value is inserted according to the order in the formal parameter list. If assignment notation has been used for the actual parameter list, then the default values are appended to the actual parameters, the order among the default values corresponds to their order in the formal parameter list.
+
+Default values may be provided in form of concrete values or expressions. The evaluation of default values shall follow the same rules as the evaluation of actual parameters, i.e., the rules provided in clause 9.24.
+
+
+
+ + + + + + + + + + +
+ (0014002) +
+ Jens Grabowski    +
+ 20-07-2016 10:54    +
+ 		+ + + + +
+ Tomas, please check if the addition of the last two sentences in 7.11 is sufficient.
+
+
+
+ + + + + + + + + + +
+ (0014014) +
+ Tomas Urban    +
+ 20-07-2016 16:45    +
+ 		+ + + + +
+ I would prefer to have a different kind of replacement, in particular the one Jacob suggested in 0007294:
+
+function f(T x := E) runs on C {
+  S1;
+  ...
+  ;Sn
+}
+
+is semantically equivalent to
+
+function f(T x) runs on C {
+  if (not isbound(x)) { x := E }
+  {
+    S1;
+    ...
+    Sn
+  }
+}
+
+Please notice the additional statement block which wasn't in Jacob's proposal. It is important, because function body might contain declarations and those are required to be in the block beginning.
+
+
+
+ + + + + + + + + + +
+ (0014019) +
+ Jens Grabowski    +
+ 21-07-2016 08:22    +
+ 		+ + + + +
+ Proposal agreed.
+
+
+
+ + + + + + + + + + +
+ (0014332) +
+ Jens Grabowski    +
+ 18-11-2016 10:42    +
+ 		+ + + + +
+ CR implemented in DRAFT.
+
+ + diff --git a/docs/mantis/CR7455.md b/docs/mantis/CR7455.md new file mode 100644 index 0000000000000000000000000000000000000000..61f474e469d1917f39776bed9396d01aa5f2104e --- /dev/null +++ b/docs/mantis/CR7455.md @@ -0,0 +1,382 @@ + + + + + + + + + + + + + 0007455: The type of formal in parameters of external functions should be allowed to be 'any' - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007455Part 01: TTCN-3 Core LanguageNew Featurepublic19-07-2016 15:0228-12-2019 15:28
ReporterJacob Wieland - Spirent 
Assigned ToGyorgy Rethy 
PrioritylowSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.9.1 (published 2017-05) 
Target Version4.11.1 (published 2019-05)Fixed in Version4.12.1 (published 2020-05) 
Clause Reference(s)16.1.3
Source (company - Author)Spirent - Jacob Wieland
Summary0007455: The type of formal in parameters of external functions should be allowed to be 'any'
DescriptionIn some cases, an external function should be able to work on any value, regardless of type. Redefining the same function for different types or using generic parameters or wrapping the value in an anytype is tedious and not user-friendly.
+
+We could introduce the type 'any' to be used for external function in-parameters.
+
+This would allow, for instance, to declare and implement such a function as valueof() as an external function
+
+external function valueof(template any t) return boolean;
+
+Typical use-cases are normalization, stringification/logging, runtime-checking, special encoding functions.
Steps To Reproduce
Additional InformationIf such a feature existed, some of the predefined functions in the standard could be pushed into a UsefulFunctions library (which could still be standardized) so that they are not further cluttering up the global name space.
TagsNo tags attached.
Relationships
related to 0007867closed Gyorgy Rethy the ispresent, ischosen, isvalue, isbound predefined functions should be moved to operations. 
Attached Filesdocx CR7455-1.docx (240,526) 26-08-2019 14:27
http://oldforge.etsi.org/mantis/file_download.php?file_id=3853&type=bug
docx CR7455-2.docx (216,731) 26-08-2019 15:11
http://oldforge.etsi.org/mantis/file_download.php?file_id=3857&type=bug
Issue History
Date ModifiedUsernameFieldChange
19-07-2016 15:02Jacob Wieland - SpirentNew Issue
15-08-2016 11:54Jens GrabowskiNote Added: 0014071
15-08-2016 11:54Jens GrabowskiAssigned To => Jens Grabowski
15-08-2016 11:54Jens GrabowskiPrioritynormal => low
15-08-2016 11:54Jens GrabowskiStatusnew => assigned
17-08-2016 11:30Jacob Wieland - SpirentProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
17-08-2016 11:30Jacob Wieland - SpirentTarget Version => v4.9.1 (published 2017-05)
16-11-2016 14:35Jens GrabowskiNote Added: 0014268
16-11-2016 14:35Jens GrabowskiTarget Versionv4.9.1 (published 2017-05) => v4.10.1 (published 2018-05)
24-10-2017 13:42Jens GrabowskiNote Added: 0014850
05-01-2018 13:28Gyorgy RethyProduct Version => v4.9.1 (published 2017-05)
05-01-2018 13:28Gyorgy RethyTarget Versionv4.10.1 (published 2018-05) => 4.11.1 (published 2019-05)
08-08-2019 14:28Kristóf SzabadosNote Added: 0015435
08-08-2019 14:28Kristóf SzabadosAssigned ToJens Grabowski => Tomas Urban
26-08-2019 13:35Tomas UrbanFile Added: CR7455-1.docx
26-08-2019 13:36Tomas UrbanFile Deleted: CR7455-1.docx
26-08-2019 14:27Tomas UrbanFile Added: CR7455-1.docx
26-08-2019 14:28Tomas UrbanNote Added: 0015457
26-08-2019 14:28Tomas UrbanAssigned ToTomas Urban => Jacob Wieland - Spirent
26-08-2019 14:28Tomas UrbanStatusassigned => confirmed
26-08-2019 15:11Tomas UrbanFile Added: CR7455-2.docx
26-08-2019 15:18Tomas UrbanNote Added: 0015462
26-08-2019 15:19Kristóf SzabadosRelationship addedrelated to 0007867
16-12-2019 13:32Jacob Wieland - SpirentNote Added: 0015524
16-12-2019 13:32Jacob Wieland - SpirentStatusconfirmed => resolved
16-12-2019 13:32Jacob Wieland - SpirentFixed in Version => 4.11.1 (published 2019-05)
16-12-2019 13:32Jacob Wieland - SpirentResolutionopen => fixed
16-12-2019 13:32Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Jens Grabowski
16-12-2019 17:44Kristóf SzabadosNote Added: 0015531
16-12-2019 17:44Kristóf SzabadosStatusresolved => new
16-12-2019 17:45Kristóf SzabadosAssigned ToJens Grabowski => Jacob Wieland - Spirent
16-12-2019 17:45Kristóf SzabadosStatusnew => assigned
17-12-2019 07:50Jacob Wieland - SpirentNote Added: 0015532
17-12-2019 07:57Jacob Wieland - SpirentStatusassigned => resolved
17-12-2019 07:57Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Jens Grabowski
28-12-2019 15:07Gyorgy RethyAssigned ToJens Grabowski => Gyorgy Rethy
28-12-2019 15:07Gyorgy RethyStatusresolved => assigned
28-12-2019 15:08Gyorgy RethyStatusassigned => resolved
28-12-2019 15:28Gyorgy RethyNote Added: 0015589
28-12-2019 15:28Gyorgy RethyStatusresolved => closed
28-12-2019 15:28Gyorgy RethyFixed in Version4.11.1 (published 2019-05) => 4.12.1 (published 2020-05)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014071) +
+ Jens Grabowski    +
+ 15-08-2016 11:54    +
+ 		+ + + + +
+ STF discussion: alternative solution: simplification of anytype assignment (automatic boxing and unboxing)
+
+
+
+ + + + + + + + + + +
+ (0014268) +
+ Jens Grabowski    +
+ 16-11-2016 14:35    +
+ 		+ + + + +
+ Moved to the 2017 Maintenance STF
+
+
+
+ + + + + + + + + + +
+ (0014850) +
+ Jens Grabowski    +
+ 24-10-2017 13:42    +
+ 		+ + + + +
+ To be moved to 2018 maintenance. Maybe partially resolved by OO extension.
+
+
+
+ + + + + + + + + + +
+ (0015435) +
+ Kristóf Szabados    +
+ 08-08-2019 14:28    +
+ 		+ + + + +
+ STF discussion: Allow it as type of external function formal parameters.
+
+
+
+ + + + + + + + + + +
+ (0015457) +
+ Tomas Urban    +
+ 26-08-2019 14:28    +
+ 		+ + + + +
+ Resolution uploaded. Please check.
+
+
+
+ + + + + + + + + + +
+ (0015462) +
+ Tomas Urban    +
+ 26-08-2019 15:18    +
+ 		+ + + + +
+ Predefined detection functions (isvalue, isbound etc.) were removed from the proposed resolution, because these functions will be changed to operators.
+
+
+
+ + + + + + + + + + +
+ (0015524) +
+ Jacob Wieland - Spirent    +
+ 16-12-2019 13:32    +
+ 		+ + + + +
+ Seems fine to me.
+
+
+
+ + + + + + + + + + +
+ (0015531) +
+ Kristóf Szabados    +
+ 16-12-2019 17:44    +
+ 		+ + + + +
+ How can this be?:
+"Values of open type occurring on the right hand side of an assignment are compatible with a value “a” of a type “A”, if the actual value contained in the open type value is compatible with “A”."
+
+If open types are only allowed "in formal parameters of external and predefined functions" they should not be able to occure on the right hand side of assignments.
+
+
+
+ + + + + + + + + + +
+ (0015532) +
+ Jacob Wieland - Spirent    +
+ 17-12-2019 07:50    +
+ 		+ + + + +
+ The reason for that sentence is the possibility of formal out parameters of type any (where the actual parameter is semantically on the left hand side of the formal parameter) and inout formal parameters of type any (where the actual parameter is both on the left and the right hand side).
+
+The sentence means, for instance, that if a variable of type A is given to decvalue then it should be assigned something compatible with A if decvalue has decoded successfully. Thus, even the external functions need to respect such type restrictions and cannot assign something of an incompatible type.
+
+
+
+ + + + + + + + + + +
+ (0015589) +
+ Gyorgy Rethy    +
+ 28-12-2019 15:28    +
+ 		+ + + + +
+ Implemented in final draft 4.11.2
+
+ + diff --git a/docs/mantis/CR7456.md b/docs/mantis/CR7456.md new file mode 100644 index 0000000000000000000000000000000000000000..298982c2b206b3d0baa74004cf7d4679ee81cc7c --- /dev/null +++ b/docs/mantis/CR7456.md @@ -0,0 +1,131 @@ + + + + + + + + + + + + + 0007456: Terminology in compatibility rules for union and anytype - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007456Part 01: TTCN-3 Core LanguageEditorialpublic19-07-2016 16:4109-12-2016 15:21
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeveritytrivialReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.7.1 (published 2015-06) 
Target Versionv4.9.1 (published 2017-05)Fixed in Versionv4.9.1 (published 2017-05) 
Clause Reference(s)6.3.2.4, 6.3.2.5
Source (company - Author)STF 514
Summary0007456: Terminology in compatibility rules for union and anytype
DescriptionThe compatibility rules should use the same terms as described in 6.3.0 and 6.3.2.0. The value "a" is not defined at the moment.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7456-1.docx (16,403) 20-07-2016 07:59
http://oldforge.etsi.org/mantis/file_download.php?file_id=3420&type=bug
Issue History
Date ModifiedUsernameFieldChange
19-07-2016 16:41Tomas UrbanNew Issue
19-07-2016 16:41Tomas UrbanStatusnew => assigned
19-07-2016 16:41Tomas UrbanAssigned To => Tomas Urban
20-07-2016 07:59Tomas UrbanFile Added: CR7456-1.docx
20-07-2016 08:01Tomas UrbanNote Added: 0013995
20-07-2016 08:01Tomas UrbanAssigned ToTomas Urban => Jacob Wieland - Spirent
21-07-2016 11:25Jacob Wieland - SpirentNote Added: 0014028
21-07-2016 11:25Jacob Wieland - SpirentStatusassigned => resolved
21-07-2016 11:25Jacob Wieland - SpirentFixed in Version => v4.8.1 (published 2016-07)
21-07-2016 11:25Jacob Wieland - SpirentResolutionopen => fixed
21-07-2016 11:25Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
17-08-2016 11:38Jacob Wieland - SpirentStatusresolved => feedback
17-08-2016 11:38Jacob Wieland - SpirentResolutionfixed => reopened
17-08-2016 11:38Jacob Wieland - SpirentFixed in Versionv4.8.1 (published 2016-07) => v4.9.1 (published 2017-05)
17-08-2016 11:38Jacob Wieland - SpirentTarget Versionv4.8.1 (published 2016-07) => v4.9.1 (published 2017-05)
17-08-2016 11:39Jacob Wieland - SpirentStatusfeedback => resolved
17-08-2016 11:39Jacob Wieland - SpirentResolutionreopened => fixed
09-12-2016 15:21Gyorgy RethyNote Added: 0014367
09-12-2016 15:21Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0013995) +
+ Tomas Urban    +
+ 20-07-2016 08:01    +
+ 		+ + + + +
+ Type and value names updated. Please review.
+
+
+
+ + + + + + + + + + +
+ (0014028) +
+ Jacob Wieland - Spirent    +
+ 21-07-2016 11:25    +
+ 		+ + + + +
+ updated text is ok
+
+
+
+ + + + + + + + + + +
+ (0014367) +
+ Gyorgy Rethy    +
+ 09-12-2016 15:21    +
+ 		+ + + + +
+ Added to draft V4.8.2
+
+ + diff --git a/docs/mantis/CR7457.md b/docs/mantis/CR7457.md new file mode 100644 index 0000000000000000000000000000000000000000..0cbf46cd92bb68216df3f3a4d5700ecceb840369 --- /dev/null +++ b/docs/mantis/CR7457.md @@ -0,0 +1,139 @@ + + + + + + + + + + + + + 0007457: external functions with type parameters should be allowed - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Advanced Parametrization (ES 202 784)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007457Ext Pack: Advanced Parametrization (ES 202 784)New Featurepublic20-07-2016 16:5716-12-2016 21:09
ReporterJacob Wieland - Spirent 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv1.5.1 (published 2015-06) 
Target Versionv1.6.1 (published 2017-04)Fixed in Versionv1.6.1 (published 2017-04) 
TS version1
Clause Reference(s)5.4.1.5
Source (company - Author)Spirent - Jacob Wieland
Summary0007457: external functions with type parameters should be allowed
DescriptionRestriction d) states that type parameterization of external functions is not allowed.
+
+In principle, allowing this is not a problem, except for the current triExternalFunction() that does not allow to pass type parameters.
+
+To circumvent having to change the triExternalFunction interface (i.e. the TciParameterListType), we need to be able to represent types as special values.
+
+To achieve this, a new class TypeValue derived from Value can be introduced which encapsulates a Type object. Also, we would need the TciTypeClass TYPE for such objects.
+
+The parameter list passed to triExternalFunction would then be the concatenation of the type and value parameter lists in TTCN-3.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7457.docx (204,174) 17-11-2016 16:17
http://oldforge.etsi.org/mantis/file_download.php?file_id=3560&type=bug
docx CR7457-2.docx (254,555) 18-11-2016 09:12
http://oldforge.etsi.org/mantis/file_download.php?file_id=3562&type=bug
Issue History
Date ModifiedUsernameFieldChange
20-07-2016 16:57Jacob Wieland - SpirentNew Issue
15-08-2016 11:31Jens GrabowskiAssigned To => Jacob Wieland - Spirent
15-08-2016 11:31Jens GrabowskiStatusnew => assigned
17-11-2016 16:17Jacob Wieland - SpirentFile Added: CR7457.docx
17-11-2016 16:17Jacob Wieland - SpirentNote Added: 0014320
17-11-2016 16:17Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Tomas Urban
17-11-2016 16:17Jacob Wieland - SpirentStatusassigned => confirmed
18-11-2016 09:12Tomas UrbanFile Added: CR7457-2.docx
18-11-2016 09:14Tomas UrbanNote Added: 0014323
18-11-2016 09:14Tomas UrbanAssigned ToTomas Urban => Jacob Wieland - Spirent
18-11-2016 09:35Jacob Wieland - SpirentStatusconfirmed => resolved
18-11-2016 09:35Jacob Wieland - SpirentFixed in Version => v1.6.1 (published 2017-04)
18-11-2016 09:35Jacob Wieland - SpirentResolutionopen => fixed
18-11-2016 09:35Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Tomas Urban
16-12-2016 21:09Gyorgy RethyNote Added: 0014453
16-12-2016 21:09Gyorgy RethyAssigned ToTomas Urban => Gyorgy Rethy
16-12-2016 21:09Gyorgy RethyStatusresolved => closed
16-12-2016 21:09Gyorgy RethyProduct Versionv1.6.1 (published 2017-04) => v1.5.1 (published 2015-06)
16-12-2016 21:09Gyorgy RethyTarget VersionNext version (to be defined) => v1.6.1 (published 2017-04)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014320) +
+ Jacob Wieland - Spirent    +
+ 17-11-2016 16:17    +
+ 		+ + + + +
+ please review
+
+
+
+ + + + + + + + + + +
+ (0014323) +
+ Tomas Urban    +
+ 18-11-2016 09:14    +
+ 		+ + + + +
+ Acceptable in general, but I made a couple of minor changes. Please check and if you find no major issues, resolve the CR.
+
+
+
+ + + + + + + + + + +
+ (0014453) +
+ Gyorgy Rethy    +
+ 16-12-2016 21:09    +
+ 		+ + + + +
+ Added to draft V1.5.3
+
+ + diff --git a/docs/mantis/CR7458.md b/docs/mantis/CR7458.md new file mode 100644 index 0000000000000000000000000000000000000000..cd9017823eeed3e533a09d4e12c72f379182c3f5 --- /dev/null +++ b/docs/mantis/CR7458.md @@ -0,0 +1,178 @@ + + + + + + + + + + + + + 0007458: editorial: encvalue/decvalue are missing a parameter in section 16.1.2 - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007458Part 01: TTCN-3 Core LanguageEditorialpublic21-07-2016 10:3513-12-2016 14:40
ReporterKristóf Szabados 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.8.1 (published 2016-07) 
Target Versionv4.9.1 (published 2017-05)Fixed in Versionv4.9.1 (published 2017-05) 
Clause Reference(s)16.1.2, C.5.1-4
Source (company - Author)L.M.Ericsson
Summary0007458: editorial: encvalue/decvalue are missing a parameter in section 16.1.2
DescriptionIn section 16.1.2 encvalue is listed as
+"
+encvalue "(" TemplateInstance ")" |
+"
+
+While C.5.1 shows encvalue as:
+"
+encvalue(in template (value) any_type inpar,
+             in universal charstring encoding_info := "") return bitstring
+"
+
+
+decvalue, encvalue_unichar and decvalue_unichar is also involved
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7458_resolution_v1.docx (90,141) 15-08-2016 13:47
http://oldforge.etsi.org/mantis/file_download.php?file_id=3440&type=bug
Issue History
Date ModifiedUsernameFieldChange
21-07-2016 10:35Kristóf SzabadosNew Issue
22-07-2016 12:28Jens GrabowskiNote Added: 0014036
22-07-2016 12:28Jens GrabowskiAssigned To => Axel Rennoch
22-07-2016 12:28Jens GrabowskiStatusnew => assigned
15-08-2016 13:47Axel RennochFile Added: CR7458_resolution_v1.docx
15-08-2016 13:51Axel RennochAssigned ToAxel Rennoch => Gyorgy Rethy
15-08-2016 13:51Axel RennochNote Added: 0014072
15-08-2016 13:51Axel RennochStatusassigned => confirmed
15-08-2016 13:52Axel RennochStatusconfirmed => assigned
15-08-2016 13:53Axel RennochNote Added: 0014073
15-08-2016 13:53Axel RennochStatusassigned => confirmed
17-08-2016 11:51Jacob Wieland - SpirentTarget Version => v4.9.1 (published 2017-05)
13-12-2016 14:40Gyorgy RethyNote Added: 0014415
13-12-2016 14:40Gyorgy RethyStatusconfirmed => closed
13-12-2016 14:40Gyorgy RethyResolutionopen => fixed
13-12-2016 14:40Gyorgy RethyFixed in Version => v4.9.1 (published 2017-05)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014036) +
+ Jens Grabowski    +
+ 22-07-2016 12:28    +
+ 		+ + + + +
+ STF discussion:
+Editorial problem
+
+
+
+ + + + + + + + + + +
+ (0014072) +
+ Axel Rennoch    +
+ 15-08-2016 13:51    +
+ 		+ + + + +
+ Addition of missing parameters, correction of fonts and missing quotes. Please have a look to the resolution.
+
+
+
+ + + + + + + + + + +
+ (0014073) +
+ Axel Rennoch    +
+ 15-08-2016 13:53    +
+ 		+ + + + +
+ Please check and close the CR.
+
+
+
+ + + + + + + + + + +
+ (0014415) +
+ Gyorgy Rethy    +
+ 13-12-2016 14:40    +
+ 		+ + + + +
+ Added to draft V.4.8.2
+
+ + diff --git a/docs/mantis/CR7459.md b/docs/mantis/CR7459.md new file mode 100644 index 0000000000000000000000000000000000000000..f001523cf2f8572495592796219487585f45f108 --- /dev/null +++ b/docs/mantis/CR7459.md @@ -0,0 +1,183 @@ + + + + + + + + + + + + + 0007459: the overwriting rules for attributes and the examples should be written more consistent - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007459Part 01: TTCN-3 Core LanguageClarificationpublic22-07-2016 14:4412-12-2016 10:10
ReporterJacob Wieland - Spirent 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.8.1 (published 2016-07) 
Target Versionv4.9.1 (published 2017-05)Fixed in Versionv4.9.1 (published 2017-05) 
Clause Reference(s)27.1.2
Source (company - Author)Spirent - Jacob Wieland
Summary0007459: the overwriting rules for attributes and the examples should be written more consistent
DescriptionThere seems to be some confusion in the standard concerning the overwriting rules for attributes.
+
+Especially the meaning of overriding the attribute in a lower scope is either not clear or it is not followed correctly in the EXAMPLE in 27.1.2.1 where MyType already has an encoding rule given by its surrounding module scope and no override is used to change that (though it is claimed to be changed by the parent encoding rule of the type MyPDUtwo in MyVariantsTwo.
+
+The consensus in the STF is that the current intended (and probably implemented by most tools) meaning is this:
+
+If a referenced type already has an encoding attached to it at the place of its definition (either by inheritance from its scope or direct annotation), that encoding 'wins' unless an encode attribute with override is inherited from the referencing definition's scope.
+
+The text in the standard should be simplified/clarified in this regards and more (and correct) examples should be given to illustrate the different scenarios.
+
+Still open questions are:
+
+What is the meaning of encode/variant attributes on import statements?
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0007448closed Gyorgy Rethy Allowing multiple encodings for TTCN-3 types 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
22-07-2016 14:44Jacob Wieland - SpirentNew Issue
15-08-2016 11:26Jens GrabowskiAssigned To => Tomas Urban
15-08-2016 11:26Jens GrabowskiStatusnew => assigned
17-08-2016 11:24Jacob Wieland - SpirentProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
17-08-2016 11:24Jacob Wieland - SpirentProduct Version => v4.8.1 (published 2016-07)
17-08-2016 11:24Jacob Wieland - SpirentTarget Version => v4.9.1 (published 2017-05)
18-08-2016 09:49Tomas UrbanRelationship addedrelated to 0007448
18-08-2016 09:58Tomas UrbanNote Added: 0014151
18-08-2016 09:58Tomas UrbanAssigned ToTomas Urban => Jacob Wieland - Spirent
18-08-2016 09:58Tomas UrbanStatusassigned => confirmed
18-08-2016 15:30Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Kristóf Szabados
18-08-2016 15:30Jacob Wieland - SpirentStatusconfirmed => assigned
18-08-2016 15:30Jacob Wieland - SpirentStatusassigned => confirmed
19-08-2016 13:35Kristóf SzabadosAssigned ToKristóf Szabados => Jacob Wieland - Spirent
19-08-2016 13:35Kristóf SzabadosStatusconfirmed => assigned
19-08-2016 15:00Jacob Wieland - SpirentNote Added: 0014185
19-08-2016 15:00Jacob Wieland - SpirentStatusassigned => confirmed
17-11-2016 10:00Jacob Wieland - SpirentNote Added: 0014292
17-11-2016 10:00Jacob Wieland - SpirentStatusconfirmed => resolved
17-11-2016 10:00Jacob Wieland - SpirentFixed in Version => v4.9.1 (published 2017-05)
17-11-2016 10:00Jacob Wieland - SpirentResolutionopen => fixed
17-11-2016 10:00Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
12-12-2016 10:10Gyorgy RethyNote Added: 0014372
12-12-2016 10:10Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014151) +
+ Tomas Urban    +
+ 18-08-2016 09:58    +
+ 		+ + + + +
+ The issue has been addressed in 0007448 as a part of a complex change of attribute handling. Several modifications related to this CR have been made:
+
+1. New rules for precedence of attributes (from strongest to lowest): direct use, inherited from a referenced type, inherited from a scope
+2. New rule for import where import clause works as an additional scope unit lying between the importing and imported module. The attributes set this way are valid within the importing module only
+3. Corrections in the mentioned example
+
+Please check the proposed solution in the related CR.
+
+
+
+ + + + + + + + + + +
+ (0014185) +
+ Jacob Wieland - Spirent    +
+ 19-08-2016 15:00    +
+ 		+ + + + +
+ please review
+
+
+
+ + + + + + + + + + +
+ (0014292) +
+ Jacob Wieland - Spirent    +
+ 17-11-2016 10:00    +
+ 		+ + + + +
+ I have reviewed the text in the documents in the related CR and it was fine.
+
+
+
+ + + + + + + + + + +
+ (0014372) +
+ Gyorgy Rethy    +
+ 12-12-2016 10:10    +
+ 		+ + + + +
+ See CR 7448
+
+ + diff --git a/docs/mantis/CR7462.md b/docs/mantis/CR7462.md new file mode 100644 index 0000000000000000000000000000000000000000..d7520bdc86212ccff6c32816889c2b17f5dc653c --- /dev/null +++ b/docs/mantis/CR7462.md @@ -0,0 +1,345 @@ + + + + + + + + + + + + + 0007462: encvalue/decvalue should also work directly with octet and hex-string values - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007462Part 01: TTCN-3 Core LanguageNew Featurepublic26-07-2016 10:4212-12-2016 20:21
ReporterJacob Wieland - Spirent 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.8.1 (published 2016-07) 
Target Versionv4.9.1 (published 2017-05)Fixed in Versionv4.9.1 (published 2017-05) 
Clause Reference(s)C.5.1, C.5.2
Source (company - Author)Spirent - Jacob Wieland
Summary0007462: encvalue/decvalue should also work directly with octet and hex-string values
DescriptionAt the moment, any octetstring that should be encoded with encvalue or decoded with decvalue needs to be explicitly converted to bitstring.
+
+This makes no sense in the most common case that the protocol is byte-based and in the adaptation layer, the bitstring again has to be converted to bytes, creating a possible imperformance.
+
+Therefore, we propose to allow encvalue and decvalue to also work directly with octetstrings (and hexstrings).
Steps To Reproduce
Additional InformationSince the encvalue function at the moment returns a bitstring, it's semantic description might be a little more problematic as the return type would be determined from the demanded type of the encvalue() function call (i.e. the variable it is assigned or parameter type it is used as actual paramter for).
+
+Only in context-less environments (log, setverdict, testcase.stop, comparison operators where both operands are of indeterminate type), the bitstring-default-result type would be used for backward compatibility reasons.
+
+Alternatively, two new predefined functions encvalue_octetstr/decvalue_octetstr could be introduced. That doesn't make the TTCN-3 code shorter, but at least no unnecessary conversions need to take place.
TagsNo tags attached.
Relationships
Attached Filesdocx CR7462.docx (162,395) 16-08-2016 09:15
http://oldforge.etsi.org/mantis/file_download.php?file_id=3449&type=bug
docx CR7462-V2.docx (162,679) 16-08-2016 09:26
http://oldforge.etsi.org/mantis/file_download.php?file_id=3453&type=bug
docx CR7462-V3.docx (163,654) 18-08-2016 08:08
http://oldforge.etsi.org/mantis/file_download.php?file_id=3484&type=bug
Issue History
Date ModifiedUsernameFieldChange
26-07-2016 10:42Jacob Wieland - SpirentNew Issue
15-08-2016 11:18Jens GrabowskiNote Added: 0014070
15-08-2016 11:18Jens GrabowskiAssigned To => Jacob Wieland - Spirent
15-08-2016 11:18Jens GrabowskiStatusnew => assigned
16-08-2016 09:15Jacob Wieland - SpirentFile Added: CR7462.docx
16-08-2016 09:15Jacob Wieland - SpirentNote Added: 0014085
16-08-2016 09:15Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Jens Grabowski
16-08-2016 09:15Jacob Wieland - SpirentStatusassigned => confirmed
16-08-2016 09:26Jens GrabowskiFile Added: CR7462-V2.docx
16-08-2016 09:27Jens GrabowskiNote Added: 0014090
16-08-2016 09:27Jens GrabowskiNote Added: 0014091
16-08-2016 09:27Jens GrabowskiStatusconfirmed => resolved
16-08-2016 09:27Jens GrabowskiResolutionopen => fixed
16-08-2016 09:27Jens GrabowskiAssigned ToJens Grabowski => Gyorgy Rethy
17-08-2016 11:22Jacob Wieland - SpirentProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
17-08-2016 11:22Jacob Wieland - SpirentStatusresolved => feedback
17-08-2016 11:22Jacob Wieland - SpirentResolutionfixed => reopened
17-08-2016 11:23Jacob Wieland - SpirentProduct Version => v4.8.1 (published 2016-07)
17-08-2016 11:23Jacob Wieland - SpirentTarget Version => v4.9.1 (published 2017-05)
17-08-2016 11:23Jacob Wieland - SpirentStatusfeedback => resolved
17-08-2016 11:23Jacob Wieland - SpirentFixed in Version => v4.9.1 (published 2017-05)
17-08-2016 11:23Jacob Wieland - SpirentResolutionreopened => fixed
17-08-2016 21:26Kristóf SzabadosNote Added: 0014142
18-08-2016 07:56Jens GrabowskiNote Added: 0014144
18-08-2016 07:56Jens GrabowskiAssigned ToGyorgy Rethy => Kristóf Szabados
18-08-2016 07:56Jens GrabowskiStatusresolved => assigned
18-08-2016 08:08Kristóf SzabadosFile Added: CR7462-V3.docx
18-08-2016 08:09Kristóf SzabadosNote Added: 0014145
18-08-2016 08:09Kristóf SzabadosAssigned ToKristóf Szabados => Jacob Wieland - Spirent
18-08-2016 08:09Kristóf SzabadosStatusassigned => feedback
18-08-2016 15:36Jacob Wieland - SpirentNote Added: 0014159
18-08-2016 15:36Jacob Wieland - SpirentStatusfeedback => assigned
18-08-2016 15:36Jacob Wieland - SpirentStatusassigned => resolved
18-08-2016 15:36Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
12-12-2016 20:21Gyorgy RethyNote Added: 0014398
12-12-2016 20:21Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014070) +
+ Jens Grabowski    +
+ 15-08-2016 11:18    +
+ 		+ + + + +
+ STF discussion: New predefined functions. Funtion name proposals: encvalue_o, decvalue_o
+
+
+
+ + + + + + + + + + +
+ (0014085) +
+ Jacob Wieland - Spirent    +
+ 16-08-2016 09:15    +
+ 		+ + + + +
+ please review
+
+
+
+ + + + + + + + + + +
+ (0014090) +
+ Jens Grabowski    +
+ 16-08-2016 09:27    +
+ 		+ + + + +
+ Apart from two typos ok!
+
+
+
+ + + + + + + + + + +
+ (0014091) +
+ Jens Grabowski    +
+ 16-08-2016 09:27    +
+ 		+ + + + +
+ resolution according to STF discussion.
+
+
+
+ + + + + + + + + + +
+ (0014142) +
+ Kristóf Szabados    +
+ 17-08-2016 21:26    +
+ 		+ + + + +
+ the CR7462-V2.docx seems to contain several problems:
+- C.5.2 calls the function "encvalue_o" in the example, but decvalue_o in the text.
+- also in both cases the text talks about working with octetstrings, but the examples display bitstring returns and parameters
+
+
+
+ + + + + + + + + + +
+ (0014144) +
+ Jens Grabowski    +
+ 18-08-2016 07:56    +
+ 		+ + + + +
+ Kristof, please correct the proposal.
+
+
+
+ + + + + + + + + + +
+ (0014145) +
+ Kristóf Szabados    +
+ 18-08-2016 08:09    +
+ 		+ + + + +
+ I have corrected the issue I noticed, please review.
+
+
+
+ + + + + + + + + + +
+ (0014159) +
+ Jacob Wieland - Spirent    +
+ 18-08-2016 15:36    +
+ 		+ + + + +
+ please implement
+
+
+
+ + + + + + + + + + +
+ (0014398) +
+ Gyorgy Rethy    +
+ 12-12-2016 20:21    +
+ 		+ + + + +
+ Added to draft V4.8.2
+
+ + diff --git a/docs/mantis/CR7463.md b/docs/mantis/CR7463.md new file mode 100644 index 0000000000000000000000000000000000000000..6c7417159d8504066d78eaa5125368e25775f122 --- /dev/null +++ b/docs/mantis/CR7463.md @@ -0,0 +1,208 @@ + + + + + + + + + + + + + 0007463: Support for named bits - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 07: Using ASN.1 with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007463Part 07: Using ASN.1 with TTCN-3Technicalpublic26-07-2016 12:1615-12-2016 15:50
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.5.1 (published 2013-04) 
Target Versionv4.6.1 (published 2017-05)Fixed in Versionv4.6.1 (published 2017-05) 
Clause Reference(s)9.1
Source (company - Author)Elvior
Summary0007463: Support for named bits
DescriptionThe conversion rules for ASN.1 currently ignore named bit identifiers (section 9.1 rule 12). However, they are in fact used in some TTCN-3 standardized test suites (e.g. ITS) in a similar fashion as named numbers and I believe that most of the tools have some non-standard support for them.
+
+Proposal: allow automatic import of named bits as constants (in a similar way as named numbers are allowed)
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR7463.doc (206,336) 15-08-2016 14:08
http://oldforge.etsi.org/mantis/file_download.php?file_id=3442&type=bug
doc CR7463-2.doc (206,848) 17-08-2016 09:56
http://oldforge.etsi.org/mantis/file_download.php?file_id=3466&type=bug
doc CR7463-3.doc (199,168) 17-08-2016 14:16
http://oldforge.etsi.org/mantis/file_download.php?file_id=3474&type=bug
Issue History
Date ModifiedUsernameFieldChange
26-07-2016 12:16Tomas UrbanNew Issue
15-08-2016 11:08Jens GrabowskiAssigned To => Jacob Wieland - Spirent
15-08-2016 11:08Jens GrabowskiStatusnew => assigned
15-08-2016 14:08Jacob Wieland - SpirentFile Added: CR7463.doc
15-08-2016 14:09Jacob Wieland - SpirentNote Added: 0014075
15-08-2016 14:10Jacob Wieland - SpirentNote Added: 0014076
15-08-2016 14:10Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Tomas Urban
15-08-2016 14:10Jacob Wieland - SpirentStatusassigned => confirmed
17-08-2016 09:56Tomas UrbanFile Added: CR7463-2.doc
17-08-2016 10:03Tomas UrbanNote Added: 0014123
17-08-2016 10:03Tomas UrbanAssigned ToTomas Urban => Jacob Wieland - Spirent
17-08-2016 10:03Tomas UrbanStatusconfirmed => assigned
17-08-2016 10:03Tomas UrbanStatusassigned => confirmed
17-08-2016 10:44Jacob Wieland - SpirentTarget Version => v4.7.1 (published 2018-05)
17-08-2016 14:16Jacob Wieland - SpirentFile Added: CR7463-3.doc
17-08-2016 14:16Jacob Wieland - SpirentNote Added: 0014132
17-08-2016 14:16Jacob Wieland - SpirentStatusconfirmed => resolved
17-08-2016 14:16Jacob Wieland - SpirentFixed in Version => v4.7.1 (published 2018-05)
17-08-2016 14:16Jacob Wieland - SpirentResolutionopen => fixed
17-08-2016 14:16Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
15-12-2016 15:50Gyorgy RethyNote Added: 0014441
15-12-2016 15:50Gyorgy RethyStatusresolved => closed
15-12-2016 15:50Gyorgy RethyProduct Versionv4.6.1 (published 2017-05) => v4.5.1 (published 2013-04)
15-12-2016 15:50Gyorgy RethyFixed in Versionv4.7.1 (published 2018-05) => v4.6.1 (published 2017-05)
15-12-2016 15:50Gyorgy RethyTarget Versionv4.7.1 (published 2018-05) => v4.6.1 (published 2017-05)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014075) +
+ Jacob Wieland - Spirent    +
+ 15-08-2016 14:09    +
+ 		+ + + + +
+ Slightly changed the rules for mapping named bit values to add padding 0s at the end to fulful minimal type length requirements.
+
+
+
+ + + + + + + + + + +
+ (0014076) +
+ Jacob Wieland - Spirent    +
+ 15-08-2016 14:10    +
+ 		+ + + + +
+ please review
+
+
+
+ + + + + + + + + + +
+ (0014123) +
+ Tomas Urban    +
+ 17-08-2016 10:03    +
+ 		+ + + + +
+ The proposal is acceptable. I made several minor changes:
+1. Added named bit identifier to the rule on constant names
+2. Removed the new rule for type of the integer constant, because we already have a rule on that (constants are of the original ASN.1 type)
+3. Changed the apostrophe symbol in examples to the correct one
+
+If you are fine with the changes, you can mark the CR as resolved.
+
+
+
+ + + + + + + + + + +
+ (0014132) +
+ Jacob Wieland - Spirent    +
+ 17-08-2016 14:16    +
+ 		+ + + + +
+ changed the wrong quotation marks to proper ones, too.
+
+Otherwise, fine with me.
+
+
+
+ + + + + + + + + + +
+ (0014441) +
+ Gyorgy Rethy    +
+ 15-12-2016 15:50    +
+ 		+ + + + +
+ Added to draft V4.5.2
+
+ + diff --git a/docs/mantis/CR7464.md b/docs/mantis/CR7464.md new file mode 100644 index 0000000000000000000000000000000000000000..573552b86971b618cb9150b1bf955fb649b8c46a --- /dev/null +++ b/docs/mantis/CR7464.md @@ -0,0 +1,167 @@ + + + + + + + + + + + + + 0007464: Remove restriction on templates in external function return value - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007464Part 01: TTCN-3 Core LanguageTechnicalpublic26-07-2016 12:3213-12-2016 10:23
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.9.1 (published 2017-05)Fixed in Versionv4.9.1 (published 2017-05) 
Clause Reference(s)16.1.3
Source (company - Author)Elvior
Summary0007464: Remove restriction on templates in external function return value
DescriptionThe current definition of external functions doesn't allow to return templates. This restriction doesn't make much sense any more, because recent additions of the TCI allow to handle matching symbols as values so it should be possible to pass them directly over XTRI or encode them with TCI-CD and then pass over TRI. Besides, it doesn't make much sense to allow an out template parameter, but not a template return value.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7464-1.docx (18,267) 17-08-2016 13:54
http://oldforge.etsi.org/mantis/file_download.php?file_id=3472&type=bug
Issue History
Date ModifiedUsernameFieldChange
26-07-2016 12:32Tomas UrbanNew Issue
15-08-2016 11:03Jens GrabowskiNote Added: 0014069
15-08-2016 11:04Jens GrabowskiAssigned To => Tomas Urban
15-08-2016 11:04Jens GrabowskiStatusnew => assigned
17-08-2016 11:50Jacob Wieland - SpirentTarget Version => v4.9.1 (published 2017-05)
17-08-2016 13:54Tomas UrbanFile Added: CR7464-1.docx
17-08-2016 13:55Tomas UrbanNote Added: 0014130
17-08-2016 13:55Tomas UrbanAssigned ToTomas Urban => Axel Rennoch
17-08-2016 13:55Tomas UrbanStatusassigned => confirmed
18-08-2016 09:02Axel RennochAssigned ToAxel Rennoch => Gyorgy Rethy
18-08-2016 09:02Axel RennochStatusconfirmed => assigned
18-08-2016 09:03Axel RennochNote Added: 0014147
17-11-2016 14:06Jens GrabowskiStatusassigned => resolved
13-12-2016 10:23Gyorgy RethyNote Added: 0014403
13-12-2016 10:23Gyorgy RethyStatusresolved => closed
13-12-2016 10:23Gyorgy RethyResolutionopen => fixed
13-12-2016 10:23Gyorgy RethyFixed in Version => v4.9.1 (published 2017-05)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014069) +
+ Jens Grabowski    +
+ 15-08-2016 11:03    +
+ 		+ + + + +
+ STF discussion: Agreed
+
+
+
+ + + + + + + + + + +
+ (0014130) +
+ Tomas Urban    +
+ 17-08-2016 13:55    +
+ 		+ + + + +
+ Proposal uploaded. Please check.
+
+The BNF hasn't been changed as it already allows to define return templates for external functions.
+
+
+
+ + + + + + + + + + +
+ (0014147) +
+ Axel Rennoch    +
+ 18-08-2016 09:03    +
+ 		+ + + + +
+ The proposal is correct and can be used for the delivery.
+
+
+
+ + + + + + + + + + +
+ (0014403) +
+ Gyorgy Rethy    +
+ 13-12-2016 10:23    +
+ 		+ + + + +
+ Added to V4.8.2
+
+ + diff --git a/docs/mantis/CR7465.md b/docs/mantis/CR7465.md new file mode 100644 index 0000000000000000000000000000000000000000..5e74c00b35f5fa5e6dd4fbc97074d5c2fcd99d56 --- /dev/null +++ b/docs/mantis/CR7465.md @@ -0,0 +1,517 @@ + + + + + + + + + + + + + 0007465: control part should be able to have a runs on clause and call other control parts - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007465Part 01: TTCN-3 Core LanguageNew Featurepublic27-07-2016 13:1204-01-2019 13:28
ReporterJacob Wieland - Spirent 
Assigned ToGyorgy Rethy 
PrioritylowSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.8.1 (published 2016-07) 
Target Version4.11.1 (published 2019-05)Fixed in Version4.11.1 (published 2019-05) 
Clause Reference(s)8.3
Source (company - Author)Spirent - Jacob Wieland
Summary0007465: control part should be able to have a runs on clause and call other control parts
DescriptionIt should be possible to declare a runs on clause for the control part, so that the component members (except for ports) can be accessed by the control part. Naturally, only functions that are runs-on compatible shall be called by the control part.
+
+Finally, it should be possible to call one control part in module A from a control part in module B, e.g. by referencing A.control; in the control part of B. Of course, the called control part must also be runs-on compatible with the calling control part.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0007806closed Tomas Urban Part 06: TTCN-3 Control Interface TCI update: module control function 
Attached Filesdocx CR7465-v1.docx (700,001) 27-10-2017 12:17
http://oldforge.etsi.org/mantis/file_download.php?file_id=3723&type=bug
docx CR7465-v2.docx (568,900) 10-10-2018 08:02
http://oldforge.etsi.org/mantis/file_download.php?file_id=3793&type=bug
docx CR7465-v3.docx (736,924) 10-10-2018 11:22
http://oldforge.etsi.org/mantis/file_download.php?file_id=3795&type=bug
docx CR7465-v4.docx (588,675) 11-10-2018 10:22
http://oldforge.etsi.org/mantis/file_download.php?file_id=3800&type=bug
Issue History
Date ModifiedUsernameFieldChange
27-07-2016 13:12Jacob Wieland - SpirentNew Issue
15-08-2016 11:01Jens GrabowskiNote Added: 0014068
15-08-2016 11:01Jens GrabowskiAssigned To => Jens Grabowski
15-08-2016 11:01Jens GrabowskiPrioritynormal => low
15-08-2016 11:01Jens GrabowskiStatusnew => assigned
17-08-2016 11:21Jacob Wieland - SpirentProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
17-08-2016 11:21Jacob Wieland - SpirentProduct Version => v4.8.1 (published 2016-07)
17-08-2016 11:21Jacob Wieland - SpirentTarget Version => v4.9.1 (published 2017-05)
16-11-2016 14:36Jens GrabowskiNote Added: 0014269
16-11-2016 14:36Jens GrabowskiTarget Versionv4.9.1 (published 2017-05) => v4.10.1 (published 2018-05)
26-10-2017 11:33Jens GrabowskiAssigned ToJens Grabowski => Tomas Urban
26-10-2017 13:56Tomas UrbanNote Added: 0014895
26-10-2017 14:01Tomas UrbanNote Edited: 0014895bug_revision_view_page.php?bugnote_id=14895#r444
27-10-2017 12:17Tomas UrbanFile Added: CR7465-v1.docx
27-10-2017 12:18Tomas UrbanNote Added: 0014913
27-10-2017 12:18Tomas UrbanAssigned ToTomas Urban => Jacob Wieland - Spirent
27-10-2017 12:18Tomas UrbanStatusassigned => confirmed
05-01-2018 13:31Gyorgy RethyTarget Versionv4.10.1 (published 2018-05) => 4.11.1 (published 2019-05)
05-01-2018 13:58Gyorgy RethyNote Added: 0015017
15-01-2018 13:13Jacob Wieland - SpirentNote Added: 0015029
15-01-2018 13:14Jacob Wieland - SpirentNote Edited: 0015029bug_revision_view_page.php?bugnote_id=15029#r460
10-10-2018 08:02Jacob Wieland - SpirentFile Added: CR7465-v2.docx
10-10-2018 08:07Jacob Wieland - SpirentNote Added: 0015236
10-10-2018 08:07Jacob Wieland - SpirentStatusconfirmed => new
10-10-2018 08:08Jacob Wieland - SpirentNote Added: 0015237
10-10-2018 08:08Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Tomas Urban
10-10-2018 08:08Jacob Wieland - SpirentStatusnew => confirmed
10-10-2018 11:22Tomas UrbanFile Added: CR7465-v3.docx
10-10-2018 11:27Tomas UrbanNote Added: 0015240
10-10-2018 11:27Tomas UrbanAssigned ToTomas Urban => Jacob Wieland - Spirent
10-10-2018 11:32Tomas UrbanRelationship addedrelated to 0007806
10-10-2018 16:48Jacob Wieland - SpirentNote Added: 0015244
10-10-2018 16:48Jacob Wieland - SpirentStatusconfirmed => resolved
10-10-2018 16:48Jacob Wieland - SpirentFixed in Version => 4.11.1 (published 2019-05)
10-10-2018 16:48Jacob Wieland - SpirentResolutionopen => fixed
10-10-2018 16:48Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Jens Grabowski
11-10-2018 10:21Kristóf SzabadosAssigned ToJens Grabowski => Kristóf Szabados
11-10-2018 10:21Kristóf SzabadosStatusresolved => acknowledged
11-10-2018 10:22Kristóf SzabadosFile Added: CR7465-v4.docx
11-10-2018 10:23Kristóf SzabadosAssigned ToKristóf Szabados => Jacob Wieland - Spirent
11-10-2018 10:23Kristóf SzabadosStatusacknowledged => assigned
11-10-2018 10:23Kristóf SzabadosNote Added: 0015249
11-10-2018 11:12Jacob Wieland - SpirentNote Added: 0015250
11-10-2018 11:12Jacob Wieland - SpirentStatusassigned => resolved
11-10-2018 11:12Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Jens Grabowski
24-12-2018 15:22Jens GrabowskiAssigned ToJens Grabowski => Gyorgy Rethy
24-12-2018 15:22Jens GrabowskiStatusresolved => assigned
24-12-2018 15:23Jens GrabowskiStatusassigned => resolved
04-01-2019 13:27Gyorgy RethyNote Added: 0015294
04-01-2019 13:27Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014068) +
+ Jens Grabowski    +
+ 15-08-2016 11:01    +
+ 		+ + + + +
+ STF discussion: Resonable extension. Low Priority, to be done if time or in the context of the next ToR
+
+
+
+ + + + + + + + + + +
+ (0014269) +
+ Jens Grabowski    +
+ 16-11-2016 14:36    +
+ 		+ + + + +
+ Moved to the 2017 Maintenance STF. Candidate for OO discussions.
+
+
+
+ + + + + + + + + + +
+ (0014895) +
+ Tomas Urban    +
+ 26-10-2017 13:56    +
(edited on: 26-10-2017 14:01)
+ 		+ + + + +
+ Result of the STF discussion:
+
+The control part is a short-hand notation for a function with the following syntax:
+function @control control() { ... }
+
+In order to harmonize the concept with the remaining rules on functions the following shall be changed in the core language standard:
+
+1. In the BNF, the control section should be moved under function definitions
+2. The control function can have parameters, return value and "runs on" clause
+3. The component type in the runs on clause shall not contain any ports
+4. The @control modifier shall be introduced. The functions with this modifier can be called only from the control part.
+5. The control function can be used as any other function
+6. The control function is automatically imported when importing all definitions of a module, all functions and a group where it is specified
+7. TCI has to be changed in order to support the added features (new CR is required)
+
+
+
+
+
+ + + + + + + + + + +
+ (0014913) +
+ Tomas Urban    +
+ 27-10-2017 12:18    +
+ 		+ + + + +
+ Resolution uploaded. Please check. Again, there's a lot of changes in the terminology and many deleted sections.
+
+
+
+ + + + + + + + + + +
+ (0015017) +
+ Gyorgy Rethy    +
+ 05-01-2018 13:58    +
+ 		+ + + + +
+ I agree that making control parts more flexible to use, i.e. be call-able by other control parts, parameterize-able etc. may be useful. Also agree that de-facto control parts are a special kind of functions.
+
+However, unclear to me
+- what complication of the syntax would give to the user? Testcases are also a special kind of functions, but we are not calling them
+function @testcase MyTest1()...
+On the other hand, control parts (we can even call them test control functions) has a specific role in testing: test execution control. If they are defined as "just another kind of function", they will loose this specific role in the head of many...
+I think this would be a loss to the language. I propose to stay with the simple syntax control()[runs on XY]{...} and use the name "test control [function]" in the textual descriptions.
+- Just from the short notes below not clear was meant by "5. The control function can be used as any other function" at the discussion, but see my comment above: the point of the control part is that they ROLE is not like other types of functions - though their USE may be made similar to the use of "ordinary" functions.
+
+
+
+ + + + + + + + + + +
+ (0015029) +
+ Jacob Wieland - Spirent    +
+ 15-01-2018 13:13    +
(edited on: 15-01-2018 13:14)
+ 		+ + + + +
+ I agree with using the terminology 'test control [function]' or 'control function' with the short 'control part' notation still usable for convenience/backward compatibility.
+
+I think what the text wants to convey is that these control functions behave like any other functions in regard to function calling, parameter passing, runs on compatibility etc. with the additional restrictions imposed on all behaviors running in a test control context.
+
+As it is today, normal functions cannot be distinguished from control functions so static analysis has a hard time to determine whether the control-behavior restrictions are/need to be met in a function.
+
+By explicitly marking control functions, the static analysis becomes able to distinguish and check them.
+
+For further harmonization, one could even think about parallel control components (PCCs) (analogous to PTCs, but governed by the main control component (MCC)) which could be allowed to communicate with each other or the upper tester.
+
+With such an approach, a common scenario of running a testcase vs. a simulation testcase that simulates the system under test could be achieved by a control part which starts these two testcases in parallel (where each testcase of course still has the usual closed-world of MTC/PTCs that cannot interact with the ones in the other testcase directly).
+
+
+
+
+
+ + + + + + + + + + +
+ (0015236) +
+ Jacob Wieland - Spirent    +
+ 10-10-2018 08:07    +
+ 		+ + + + +
+ I have rearranged the sections somewhat and introduced the terminology control behaviour, control function, control altstep and explicit control behaviour/function/altstep in the definitions section to be referred to in the rest of the text (instead of 'behaviour running on control component' and suchlike).
+
+I have also added the possibility to call other control parts (i.e. control functions defined by current shorthand notation) without parameter list, i.e.
+
+module M0 {
+  ...
+  control {
+    M1.control;
+    M2.control;
+  }
+}
+
+
+
+ + + + + + + + + + +
+ (0015237) +
+ Jacob Wieland - Spirent    +
+ 10-10-2018 08:08    +
+ 		+ + + + +
+ please review
+
+
+
+ + + + + + + + + + +
+ (0015240) +
+ Tomas Urban    +
+ 10-10-2018 11:27    +
+ 		+ + + + +
+ I am fine with the proposal. However, I still made some minor changes, mostly in terminology and in the scheme for scope units (which is not marked as a change by Word). Please check and if you don't find any major issues, the CR can be marked as resolved.
+
+
+
+ + + + + + + + + + +
+ (0015244) +
+ Jacob Wieland - Spirent    +
+ 10-10-2018 16:48    +
+ 		+ + + + +
+ consider this resolved
+
+
+
+ + + + + + + + + + +
+ (0015249) +
+ Kristóf Szabados    +
+ 11-10-2018 10:23    +
+ 		+ + + + +
+ I have added to note to clarify that each module can have at most 1 control part. Please check.
+
+
+
+ + + + + + + + + + +
+ (0015250) +
+ Jacob Wieland - Spirent    +
+ 11-10-2018 11:12    +
+ 		+ + + + +
+ comment is fine
+
+
+
+ + + + + + + + + + +
+ (0015294) +
+ Gyorgy Rethy    +
+ 04-01-2019 13:27    +
+ 		+ + + + +
+ Added to draft version 4.10.2.
+
+ + diff --git a/docs/mantis/CR7466.md b/docs/mantis/CR7466.md new file mode 100644 index 0000000000000000000000000000000000000000..49ff68d20124649ff40faefefe9374ce7bf3f21e --- /dev/null +++ b/docs/mantis/CR7466.md @@ -0,0 +1,201 @@ + + + + + + + + + + + + + 0007466: editorial: indentation, hyperlink, typo fixes in part - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007466Part 09: Using XML with TTCN-3Editorialpublic30-07-2016 10:1813-12-2016 16:41
ReporterKristóf Szabados 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.8.1 (published 2017-05)Fixed in Versionv4.8.1 (published 2017-05) 
Clause Reference(s)part 9 of the TTCN-3 language standard
For STF discussion
Source (company - Author)L.M.Ericsson
Summary0007466: editorial: indentation, hyperlink, typo fixes in part
DescriptionThere are several places in part where examples contain clickable hyperlinks.
+Some examples are badly indented, reducing easy of understanding.
++typos
Steps To Reproduceupdated document attached
Additional Information
TagsNo tags attached.
Relationships
related to 0007368closed Gyorgy Rethy Check the use of "may"-s in the standard 
Attached Filesdocx part9_editorial.docx (487,792) 30-07-2016 10:18
http://oldforge.etsi.org/mantis/file_download.php?file_id=3437&type=bug
Issue History
Date ModifiedUsernameFieldChange
30-07-2016 10:18Kristóf SzabadosNew Issue
30-07-2016 10:18Kristóf SzabadosFile Added: part9_editorial.docx
15-08-2016 10:53Jens GrabowskiAssigned To => Axel Rennoch
15-08-2016 10:53Jens GrabowskiStatusnew => assigned
16-08-2016 16:27Axel RennochRelationship addedrelated to 0007368
17-08-2016 11:29Jacob Wieland - SpirentProjectTTCN-3 Change Requests => Part 09: Using XML with TTCN-3
17-08-2016 11:29Jacob Wieland - SpirentTarget Version => v4.8.1 (published 2017-05)
19-08-2016 09:25Axel RennochNote Added: 0014170
19-08-2016 09:25Axel RennochAssigned ToAxel Rennoch => Kristóf Szabados
19-08-2016 09:25Axel RennochStatusassigned => acknowledged
19-08-2016 10:08Axel RennochNote Added: 0014173
19-08-2016 10:08Axel RennochStatusacknowledged => confirmed
19-08-2016 15:21Kristóf SzabadosNote Added: 0014190
19-08-2016 15:21Kristóf SzabadosStatusconfirmed => resolved
19-08-2016 15:21Kristóf SzabadosFixed in Version => v4.9.1 (published 2018-05)
19-08-2016 15:21Kristóf SzabadosResolutionopen => fixed
19-08-2016 15:21Kristóf SzabadosAssigned ToKristóf Szabados => Gyorgy Rethy
17-11-2016 14:44Kristóf SzabadosNote Added: 0014314
17-11-2016 14:44Kristóf SzabadosStatusresolved => feedback
17-11-2016 14:44Kristóf SzabadosResolutionfixed => reopened
17-11-2016 14:44Kristóf SzabadosStatusfeedback => resolved
17-11-2016 14:44Kristóf SzabadosFixed in Versionv4.9.1 (published 2018-05) => v4.8.1 (published 2017-05)
17-11-2016 14:44Kristóf SzabadosResolutionreopened => fixed
13-12-2016 16:41Gyorgy RethyNote Added: 0014428
13-12-2016 16:41Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014170) +
+ Axel Rennoch    +
+ 19-08-2016 09:25    +
+ 		+ + + + +
+ please see proposed resolution in CR7368
+
+
+
+ + + + + + + + + + +
+ (0014173) +
+ Axel Rennoch    +
+ 19-08-2016 10:08    +
+ 		+ + + + +
+ status correction
+
+
+
+ + + + + + + + + + +
+ (0014190) +
+ Kristóf Szabados    +
+ 19-08-2016 15:21    +
+ 		+ + + + +
+ Resolved in CR7368
+
+
+
+ + + + + + + + + + +
+ (0014314) +
+ Kristóf Szabados    +
+ 17-11-2016 14:44    +
+ 		+ + + + +
+ actually fixed in the ongoing version
+
+
+
+ + + + + + + + + + +
+ (0014428) +
+ Gyorgy Rethy    +
+ 13-12-2016 16:41    +
+ 		+ + + + +
+ Added to draft V4.7.2
+
+ + diff --git a/docs/mantis/CR7467.md b/docs/mantis/CR7467.md new file mode 100644 index 0000000000000000000000000000000000000000..a6be18a04c6767729fa67bc8541bade54fe78187 --- /dev/null +++ b/docs/mantis/CR7467.md @@ -0,0 +1,165 @@ + + + + + + + + + + + + + 0007467: Handling of NumberOfBits in TriAddressType is missing in C# mapping - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 05: TTCN-3 Runtime Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007467Part 05: TTCN-3 Runtime Interface Technicalpublic02-08-2016 14:5421-12-2016 14:24
Reportertepelmann 
Assigned ToTomas Urban 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.7.1 (published 2015-06) 
Target VersionNext version (to be defined)Fixed in VersionNext version (to be defined) 
Clause Reference(s)9.4.2.7
Source (company - Author)    Spirent - tepelmann
Summary0007467: Handling of NumberOfBits in TriAddressType is missing in C# mapping
DescriptionIn all language mappings the TriAddressType does handle the number of bits encoded, however in the C# mapping this methods are missing.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7467-1.docx (16,731) 17-08-2016 16:24
http://oldforge.etsi.org/mantis/file_download.php?file_id=3480&type=bug
Issue History
Date ModifiedUsernameFieldChange
02-08-2016 14:54tepelmannNew Issue
15-08-2016 10:53Jens GrabowskiAssigned To => Tomas Urban
15-08-2016 10:53Jens GrabowskiStatusnew => assigned
17-08-2016 11:41Jacob Wieland - SpirentTarget Version => Next version (to be defined)
17-08-2016 16:24Tomas UrbanFile Added: CR7467-1.docx
17-08-2016 16:24Tomas UrbanNote Added: 0014138
17-08-2016 16:24Tomas UrbanAssigned ToTomas Urban => Axel Rennoch
17-08-2016 16:24Tomas UrbanStatusassigned => confirmed
18-08-2016 13:22Axel RennochNote Added: 0014155
18-08-2016 13:22Axel RennochAssigned ToAxel Rennoch => Tomas Urban
18-08-2016 13:22Axel RennochStatusconfirmed => acknowledged
19-08-2016 08:36Tomas UrbanNote Added: 0014166
19-08-2016 08:36Tomas UrbanStatusacknowledged => resolved
19-08-2016 08:36Tomas UrbanFixed in Version => Next version (to be defined)
19-08-2016 08:36Tomas UrbanResolutionopen => fixed
21-12-2016 14:24Tomas UrbanNote Added: 0014474
21-12-2016 14:24Tomas UrbanStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014138) +
+ Tomas Urban    +
+ 17-08-2016 16:24    +
+ 		+ + + + +
+ Resolution proposal uploaded. Please check.
+
+
+
+ + + + + + + + + + +
+ (0014155) +
+ Axel Rennoch    +
+ 18-08-2016 13:22    +
+ 		+ + + + +
+ ok
+
+
+
+ + + + + + + + + + +
+ (0014166) +
+ Tomas Urban    +
+ 19-08-2016 08:36    +
+ 		+ + + + +
+ Ready to be added to the next version of the TCI specification.
+
+
+
+ + + + + + + + + + +
+ (0014474) +
+ Tomas Urban    +
+ 21-12-2016 14:24    +
+ 		+ + + + +
+ Added to draft 4.7.2
+
+ + diff --git a/docs/mantis/CR7468.md b/docs/mantis/CR7468.md new file mode 100644 index 0000000000000000000000000000000000000000..1068ccc42994733827c5b7a6290161b2f5e972ab --- /dev/null +++ b/docs/mantis/CR7468.md @@ -0,0 +1,165 @@ + + + + + + + + + + + + + 0007468: Handling of NumberOfBits in TriParameterType is missing in C# mapping - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 05: TTCN-3 Runtime Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007468Part 05: TTCN-3 Runtime Interface Technicalpublic02-08-2016 15:2121-12-2016 14:26
Reportertepelmann 
Assigned ToTomas Urban 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.7.1 (published 2015-06) 
Target VersionNext version (to be defined)Fixed in VersionNext version (to be defined) 
Clause Reference(s)9.4.2.11
Source (company - Author)     Spirent - tepelmann
Summary0007468: Handling of NumberOfBits in TriParameterType is missing in C# mapping
DescriptionIn all language mappings the TriParameterType does handle the number of bits encoded, however in the C# mapping this methods are missing.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7468-1.docx (17,525) 17-08-2016 16:07
http://oldforge.etsi.org/mantis/file_download.php?file_id=3478&type=bug
Issue History
Date ModifiedUsernameFieldChange
02-08-2016 15:21tepelmannNew Issue
15-08-2016 10:53Jens GrabowskiAssigned To => Tomas Urban
15-08-2016 10:53Jens GrabowskiStatusnew => assigned
17-08-2016 11:42Jacob Wieland - SpirentTarget Version => Next version (to be defined)
17-08-2016 16:03Tomas UrbanFile Added: CR7468-1.docx
17-08-2016 16:07Tomas UrbanFile Deleted: CR7468-1.docx
17-08-2016 16:07Tomas UrbanFile Added: CR7468-1.docx
17-08-2016 16:08Tomas UrbanNote Added: 0014135
17-08-2016 16:08Tomas UrbanAssigned ToTomas Urban => Axel Rennoch
17-08-2016 16:08Tomas UrbanStatusassigned => confirmed
18-08-2016 13:22Axel RennochNote Added: 0014154
18-08-2016 13:22Axel RennochAssigned ToAxel Rennoch => Tomas Urban
18-08-2016 13:22Axel RennochStatusconfirmed => acknowledged
19-08-2016 08:36Tomas UrbanNote Added: 0014167
19-08-2016 08:36Tomas UrbanStatusacknowledged => resolved
19-08-2016 08:36Tomas UrbanFixed in Version => Next version (to be defined)
19-08-2016 08:36Tomas UrbanResolutionopen => fixed
21-12-2016 14:26Tomas UrbanNote Added: 0014475
21-12-2016 14:26Tomas UrbanStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014135) +
+ Tomas Urban    +
+ 17-08-2016 16:08    +
+ 		+ + + + +
+ Resolution proposal uploaded. Please check.
+
+
+
+ + + + + + + + + + +
+ (0014154) +
+ Axel Rennoch    +
+ 18-08-2016 13:22    +
+ 		+ + + + +
+ ok
+
+
+
+ + + + + + + + + + +
+ (0014167) +
+ Tomas Urban    +
+ 19-08-2016 08:36    +
+ 		+ + + + +
+ Ready to be added to the next version of the TCI specification.
+
+
+
+ + + + + + + + + + +
+ (0014475) +
+ Tomas Urban    +
+ 21-12-2016 14:26    +
+ 		+ + + + +
+ Added to draft 4.7.2
+
+ + diff --git a/docs/mantis/CR7469.md b/docs/mantis/CR7469.md new file mode 100644 index 0000000000000000000000000000000000000000..36961a99bb144a32466eed67296992039ea2b17f --- /dev/null +++ b/docs/mantis/CR7469.md @@ -0,0 +1,166 @@ + + + + + + + + + + + + + 0007469: Handling of NumberOfBits in TriExceptionType is missing in C# mapping - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 05: TTCN-3 Runtime Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007469Part 05: TTCN-3 Runtime Interface Technicalpublic02-08-2016 15:4621-12-2016 14:27
Reportertepelmann 
Assigned ToTomas Urban 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.7.1 (published 2015-06) 
Target VersionNext version (to be defined)Fixed in VersionNext version (to be defined) 
Clause Reference(s)9.4.2.13
Source (company - Author)     Spirent - tepelmann
Summary0007469: Handling of NumberOfBits in TriExceptionType is missing in C# mapping
DescriptionIn all language mappings the TriExceptionType does handle the number of bits
+encoded, however in the C# mapping this methods are missing.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7469-1.docx (16,812) 17-08-2016 16:13
http://oldforge.etsi.org/mantis/file_download.php?file_id=3479&type=bug
docx CR7469-2.docx (18,013) 18-08-2016 13:16
http://oldforge.etsi.org/mantis/file_download.php?file_id=3488&type=bug
Issue History
Date ModifiedUsernameFieldChange
02-08-2016 15:46tepelmannNew Issue
15-08-2016 10:52Jens GrabowskiAssigned To => Tomas Urban
15-08-2016 10:52Jens GrabowskiStatusnew => assigned
17-08-2016 11:41Jacob Wieland - SpirentTarget Version => Next version (to be defined)
17-08-2016 16:13Tomas UrbanFile Added: CR7469-1.docx
17-08-2016 16:14Tomas UrbanNote Added: 0014137
17-08-2016 16:14Tomas UrbanAssigned ToTomas Urban => Axel Rennoch
17-08-2016 16:14Tomas UrbanStatusassigned => confirmed
18-08-2016 13:16Axel RennochFile Added: CR7469-2.docx
18-08-2016 13:21Axel RennochNote Added: 0014153
18-08-2016 13:21Axel RennochAssigned ToAxel Rennoch => Tomas Urban
18-08-2016 13:21Axel RennochStatusconfirmed => acknowledged
19-08-2016 08:35Tomas UrbanNote Added: 0014164
19-08-2016 08:35Tomas UrbanStatusacknowledged => resolved
19-08-2016 08:35Tomas UrbanFixed in Version => Next version (to be defined)
19-08-2016 08:35Tomas UrbanResolutionopen => fixed
21-12-2016 14:27Tomas UrbanNote Added: 0014476
21-12-2016 14:27Tomas UrbanStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014137) +
+ Tomas Urban    +
+ 17-08-2016 16:14    +
+ 		+ + + + +
+ Resolution proposal uploaded. Please check.
+
+
+
+ + + + + + + + + + +
+ (0014153) +
+ Axel Rennoch    +
+ 18-08-2016 13:21    +
+ 		+ + + + +
+ changed order to be aligned with other interface mappings
+
+
+
+ + + + + + + + + + +
+ (0014164) +
+ Tomas Urban    +
+ 19-08-2016 08:35    +
+ 		+ + + + +
+ Ready to be added to the next version of the TCI specification.
+
+
+
+ + + + + + + + + + +
+ (0014476) +
+ Tomas Urban    +
+ 21-12-2016 14:27    +
+ 		+ + + + +
+ Added to draft 4.7.2
+
+ + diff --git a/docs/mantis/CR7470.md b/docs/mantis/CR7470.md new file mode 100644 index 0000000000000000000000000000000000000000..b9c08a62de7b8842f5297f89ee0816f23018a4e4 --- /dev/null +++ b/docs/mantis/CR7470.md @@ -0,0 +1,158 @@ + + + + + + + + + + + + + 0007470: editorial: inconsistent namespace names - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007470Part 09: Using XML with TTCN-3Editorialpublic04-08-2016 11:4113-12-2016 20:54
ReporterKristóf Szabados 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.7.1 (published 2016-07) 
Target Versionv4.8.1 (published 2017-05)Fixed in Versionv4.8.1 (published 2017-05) 
Clause Reference(s)7.5.3, 8.2
For STF discussion
Source (company - Author)L.M.Ericsson
Summary0007470: editorial: inconsistent namespace names
DescriptionIn the current version of part9 the "http://" [^] prefix is used inconsistently in the examples. This can lead to incorrect examples.
+
+For example in section 7.5.3, example 1 has:
+<?xml version="1.0" encoding="UTF-8"?>
+    <xsd:schema
+    xmlns:xsd="http://www.w3.org/2001/XMLSchema" [^]
+    xmlns:ns=http://www.example.org/union [^]
+    targetNamespace="http://www.example.org/union"> [^]
+
+This is converted into:
+(please note the namespace loosing the http:// part)
+with {
+        encode "XML";
+        variant "namespace as 'www.example.org/union' prefix 'ns'";
+        variant "controlNamespace 'http://www.w3.org/2001/XMLSchema-instance' [^] prefix 'xsi'";
+    }
+
+And so the resulting encoding is:
+<?xml version="1.0" encoding="UTF-8"?>
+    <ns:e21namedElement xmlns:ns='www.example.org/union' xmlns:xsd='http://www.w3.org/2001/XMLSchema' [^] xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance' [^] xsi:type= 'xsd:integer'>1</ns:e21namedElement>
+
+But 'www.example.org/union' and "http://www.example.org/union" [^] might not be recognized as the same namespace.
+
+I believe this is just an editorial issue.
+Having the "http://" [^] present consistently could solve it
+
+
Steps To Reproduce
Additional InformationPlease note that in some example the "http://" [^] -less form used correctly.
+Still, for consistency reasons it would make the standard more readable to have the paths in a consistent form.
TagsNo tags attached.
Relationships
related to 0007368closed Gyorgy Rethy Check the use of "may"-s in the standard 
related to 0007520closed Gyorgy Rethy Error in union example clause 7.5.3 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
04-08-2016 11:41Kristóf SzabadosNew Issue
15-08-2016 10:51Jens GrabowskiAssigned To => Axel Rennoch
15-08-2016 10:51Jens GrabowskiStatusnew => assigned
16-08-2016 16:27Axel RennochRelationship addedrelated to 0007368
19-08-2016 09:24Axel RennochNote Added: 0014169
19-08-2016 09:24Axel RennochAssigned ToAxel Rennoch => Kristóf Szabados
19-08-2016 09:24Axel RennochStatusassigned => acknowledged
19-08-2016 10:08Axel RennochNote Added: 0014174
19-08-2016 10:08Axel RennochStatusacknowledged => confirmed
19-08-2016 15:21Kristóf SzabadosNote Added: 0014191
19-08-2016 15:21Kristóf SzabadosStatusconfirmed => resolved
19-08-2016 15:21Kristóf SzabadosFixed in Version => v4.9.1 (published 2018-05)
19-08-2016 15:21Kristóf SzabadosResolutionopen => fixed
19-08-2016 15:21Kristóf SzabadosAssigned ToKristóf Szabados => Gyorgy Rethy
05-11-2016 17:35Kristóf SzabadosRelationship addedrelated to 0007520
13-12-2016 20:54Gyorgy RethyStatusresolved => closed
13-12-2016 20:54Gyorgy RethyFixed in Versionv4.9.1 (published 2018-05) => v4.8.1 (published 2017-05)
13-12-2016 20:54Gyorgy RethyTarget Version => v4.8.1 (published 2017-05)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014169) +
+ Axel Rennoch    +
+ 19-08-2016 09:24    +
+ 		+ + + + +
+ please see proposed resolution in CR7368
+
+
+
+ + + + + + + + + + +
+ (0014174) +
+ Axel Rennoch    +
+ 19-08-2016 10:08    +
+ 		+ + + + +
+ status correction
+
+
+
+ + + + + + + + + + +
+ (0014191) +
+ Kristóf Szabados    +
+ 19-08-2016 15:21    +
+ 		+ + + + +
+ Resolved in CR7368
+
+ + diff --git a/docs/mantis/CR7471.md b/docs/mantis/CR7471.md new file mode 100644 index 0000000000000000000000000000000000000000..4c223fa5a117e9ddd873f29250cae4ab4680b245 --- /dev/null +++ b/docs/mantis/CR7471.md @@ -0,0 +1,475 @@ + + + + + + + + + + + + + 0007471: editorial: inconsistency in the standard regarding partially initialized values - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007471Part 01: TTCN-3 Core LanguageEditorialpublic08-08-2016 14:0009-12-2016 15:43
ReporterKristóf Szabados 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.9.1 (published 2017-05)Fixed in Versionv4.9.1 (published 2017-05) 
Clause Reference(s)6.2.1, 19.1
Source (company - Author)L. M. Ericsson
Summary0007471: editorial: inconsistency in the standard regarding partially initialized values
DescriptionIn his feedback Martin Hauch pointed out an inconsistency in the core standard.
+
+"
+Another point regarding assignments of structured types which is related and should also be clarified:
+
+Chapter 19.1 :
+A structured value on the right-hand side of the assignment shall be assigned completely to the variable on the left-hand side of the assignment, If a partially initialized value is assigned to a completely initialized variable, fields uninitialized at the right-hand side of the assignment shall also become uninitialized at the left-hand side.
+But in Chapter 6.2.1 "Record type and values" there are many examples that contradict this statement e.g. EXAMPLE 5
+
+var MyRecordType MyVariable :=
+           {
+                     field1 := '111'B,
+                     field2 := false,
+                     field3 := -
+           }
+ 
+
+           MyVariable :=
+           {
+                     field2 := true
+           }
+           // after this, MyVariable contains:
+           // { '111'B /* unchanged */, true, <undefined> /* unchanged */ }
+
+In my opinion (regarding chapter 19.1) fields field1 and field3 are not assigned and so must be unitialized after the assignment. If I only want to change the second field of the variable, it should be written:
+
+    MyVariable.field2 := true;
+
+In case of more complex situations, the usage of modified templates is semantically a better solution to change complex values, when some special fields should be assigned to a new value. The concept of "modified templates" is a clear semantic, how templates can be defined using base template definitions. This also would make the use of the "-" in assignments unnecessary.
+
+I think the sentence in 19.1 is more clear and intuitive, than the long description in chapter 6.2.1 Record type and values. In 6.2.1, fields on the left hand side are kept unchanged implicitly, which can lead to side effects and is completely against the way assignments should work in my opinion.
+"
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0007473closed Gyorgy Rethy Chapter 6.2.1 inconsitencies in optionial attribute "explicit omit" 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
08-08-2016 14:00Kristóf SzabadosNew Issue
08-08-2016 15:49Jacob Wieland - SpirentNote Added: 0014046
09-08-2016 10:43Martin HauchNote Added: 0014047
09-08-2016 15:48Jacob Wieland - SpirentNote Edited: 0014046bug_revision_view_page.php?bugnote_id=14046#r314
09-08-2016 15:51Jacob Wieland - SpirentNote Edited: 0014046bug_revision_view_page.php?bugnote_id=14046#r315
09-08-2016 15:55Jacob Wieland - SpirentNote Added: 0014048
10-08-2016 13:08Martin HauchNote Added: 0014049
10-08-2016 15:11Jacob Wieland - SpirentNote Added: 0014050
15-08-2016 10:31Jens GrabowskiAssigned To => Kristóf Szabados
15-08-2016 10:31Jens GrabowskiStatusnew => assigned
15-08-2016 10:37Jens GrabowskiRelationship addedrelated to 0007473
17-08-2016 11:49Jacob Wieland - SpirentTarget Version => v4.9.1 (published 2017-05)
14-11-2016 16:32Jens GrabowskiNote Added: 0014233
15-11-2016 16:54Kristóf SzabadosNote Added: 0014256
15-11-2016 16:54Kristóf SzabadosStatusassigned => resolved
15-11-2016 16:54Kristóf SzabadosFixed in Version => v4.10.1 (published 2018-05)
15-11-2016 16:54Kristóf SzabadosResolutionopen => fixed
17-11-2016 14:21Kristóf SzabadosNote Added: 0014311
17-11-2016 14:21Kristóf SzabadosStatusresolved => feedback
17-11-2016 14:21Kristóf SzabadosResolutionfixed => reopened
17-11-2016 14:22Kristóf SzabadosStatusfeedback => resolved
17-11-2016 14:22Kristóf SzabadosFixed in Versionv4.10.1 (published 2018-05) => v4.9.1 (published 2017-05)
17-11-2016 14:22Kristóf SzabadosResolutionreopened => fixed
17-11-2016 14:22Kristóf SzabadosAssigned ToKristóf Szabados => Gyorgy Rethy
09-12-2016 15:43Gyorgy RethyNote Added: 0014368
09-12-2016 15:43Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014046) +
+ Jacob Wieland - Spirent    +
+ 08-08-2016 15:49    +
(edited on: 09-08-2016 15:51)
+ 		+ + + + +
+ Here, the commenter confused the assignment syntax with the value-syntax. On the right-hand-side of an assignment, a structured expression is currently seen only as a short-hand notation for a lot of sub-structure assignments (i.e. only those fields that are written down, except those with the dash on the right-hand-side) are actually overwritten, everything else remains unchanged.
+
+I also think this is a weird interpretation of the syntax, as the same syntax used in a different context, e.g. as an actual parameter, has a different meaning than on the right-hand side of an assignment.
+
+The problem mainly here is the dash symbol which only has meaning on the right-hand-side of an assignment. It cannot be interpreted as 'uninitialized' as then the assignment would overwrite an already initialized field with 'uninitialized' unless the semantics is changed that this is always the case for assigning uninitialized.
+
+It is also weird that the expression that can be used on the right-hand-side (using dash) cannot be used as an actual parameter and then when the corresponding formal parameter is assigned does not have the same semantics as in a direct assignment.
+
+
+
+
+
+ + + + + + + + + + +
+ (0014047) +
+ Martin Hauch    +
+ 09-08-2016 10:43    +
+ 		+ + + + +
+ From example above (initialized value {field1 := '111'B,field2 := false,
+                     field3 := -}
+
+The right-hand-side of the assignment
+           MyVariable :=
+           {
+                     field2 := true
+           }
+
+contains a partial value. So as defined in chapter 19.1 the value after assignment is {field1 <unitialized>, field2 true, field3 <unitialized>}. The definition in 19.1 contradicts to chapter 6.2.1 which (implicitly) introduces the short hand notation you mention. Either chapter 6.2.1 must be changed or the sentence in 19.1, which defines the assignment-semantic, must be changed!
+
+I think it would be clearer to say 19.1 is correct! Use modified templates or syntax MyVariable.field1:='001'B, if only parts of a structure should be reassigned. The syntax and semantic of
+
+MyVariable.field1:='001'B,
+
+is much clearer than
+
+MyVariable :={field2 := true}
+
+where complicate descriptions have to be analysed to understand, what the assignment is exactly doing (depends on value-list-notation, assignment-notation,with "optional explicit omit", with "optional implicit omit").
+
+
+
+ + + + + + + + + + +
+ (0014048) +
+ Jacob Wieland - Spirent    +
+ 09-08-2016 15:55    +
+ 		+ + + + +
+ No, { field2 := true } on the right-hand-side of an assignment is not a value, but just syntax for several assignments rolled into one, which is why it is not in conflict with 19.1.
+
+The result of the assignment (if MyVariable has uninitialized fields other than field2 before the assignment) that is stored in MyVariable is then an partially initialized value. Using that (i.e. MyVariable) on the right-hand-side of an assignment would then invoke the rules in 19.1, i.e. the uninitialized fields would be treated differently than the left-out fields in the syntax above.
+
+The standard in 6.2.1. is very clear about this:
+
+
+I quote:
+
+When the assignment notation is used in a scope, where the optional attribute is implicitly or explicitly set to
+"explicit omit", fields, not explicitly referred to in the notation, shall remain unchanged.
+
+and also:
+
+When the assignment notation is used in a scope, where the optional attribute is set to "implicit omit",
+optional fields, not directly referred to in the notation, shall implicitly be set to omit, while mandatory fields shall
+remain unchanged (see also clause 27.7).
+
+
+
+ + + + + + + + + + +
+ (0014049) +
+ Martin Hauch    +
+ 10-08-2016 13:08    +
+ 		+ + + + +
+ Question 1:
+What are variable MyVariable2,MyVariable4 representing in the following example (btw. the type MyRecordType seems to be not the type that is used vor the defined variables in EXAMPLE 5 in chapter 6.2.1 of the core language):
+{
+  type record MyRecordType{
+        integer field1,
+        boolean field2 optional,
+        charstring field3
+  }
+
+var MyRecordType MyVariable:={field1:=1,field2:=false,field3:="hallo"};
+var MyRecordType MyVariable2:={field1:=1,field2:=false,field3:="hallo"};
+var MyRecordType MyVariable3,MyVariable4,;
+MyVariable:={field2:=True}; //MARK1 completely assigned variable
+MyVariable3:={field2:=True};//MARK2 partially assigned variable
+MyVariable2:=MyVariable3; //MARK3 partially or complete assigned variable??
+MyVariable4:=MyVariable3; //MARK4 partially assigned variable
+}
+From an intuitive view I would first expect that MyVariable and MyVariable3 are the same (because of the same rhs in MARK1 and MARK2) and MyVariable2 and MyVariable4 represent the same, i.e. ALL variables are identical. But respecting the definitions in 6.2.1 this is not the case. The content of MyVariable2 (MARK3) is not clear to me. Does the variable assignment overwrite initialized values with 'unitialized'? It is very unintuitive that you have to know the "history" of assignments to a variable to interpret the resulting value of obviously identical assignments like MARK1 and MARK2 correctly.
+
+Question 2:
+What is the complete notation for this shorthand notation:
+
+// MyVariable is uninitialized here
+MyVariable :={field2 := true}
+
+?
+
+I can only think of
+
+MyVariable:={field1:=MyVariable.field1,
+             field2:=true,
+         field3:=MyVariable.field3}
+
+because according to 19.1.a the rhs has to be type compatible with the lhs. But then, MyVariable.field1 and MyVariable.field3 are unbound and the assignment is invalid. The type compatibility according to 19.1.a is the main point for my concerns. In chapter 19.1 EXAMPLE 3 shows, how a variable could be partially assigned.
+So my conclusion from above definitions in 19.1 is:
+The assignment
+MyVariable :={field2 := true}
+is only allowed, if MyVariable has still assigned 'values' or 'omit to optional fields' "field1" and "field3". Otherwise it is an error.
+If this is correct, the examples above from question 1 are not allowed, because a variable could not be initialized partially this way!
+
+We have to be careful not to confuse/mix this with the optional omit attribute, because this is not allowed for variables yet (or at least it is unclear), and the described shorthand notation can also be used for variables with only mandatory fields.
+
+
+
+ + + + + + + + + + +
+ (0014050) +
+ Jacob Wieland - Spirent    +
+ 10-08-2016 15:11    +
+ 		+ + + + +
+ Answer to question 1:
+MARK1: {1,true,"hallo"} (field1/field3 remain unchanged)
+MARK2: {<undefined>,true,<undefined>} (field1/field3 remain unchanged, i.e. undefined)
+MARK3: {<undefined>,true,<undefined>} (all of MyVariable3 overwrites MyVariable2)
+MARK4: {<undefined>,true,<undefined>} (all of MyVariable3 overwrites MyVariable4)
+
+You have the same problem when assigning fields with individual assignment statements, you have to know the history of the whole variable to know the end-result. Again, the field-assignment notation is just a shorthand for a set of field assignments of the mentioned fields in the notation.
+
+In principle, I agree with your intuition, coming from other computer languages where such a notation would simply denote a (partial) value and would then be treated as such whereever it occurs, not differently just because it is on the rhs of an assignment. In that way, the language is inconsistent with other languages and the intuition they convey.
+
+Answer to question 2:
+The complete notation is
+
+MyVariable := {
+  field1 := - /* explicit unchanged */,
+  field2 := true,
+  field3 := -
+}
+
+which is again shorthand for:
+MyVariable.field1 := -;
+MyVariable.field2 := true;
+MyVariable.field3 := -;
+
+where, of course, the assignments with - (unchanged symbol) on the right-hand-side are NOPs.
+
+The 'shorthand' gain comes off only once you have larger structures with deep paths, that you have to repeat in each assignment statement over and over again otherwise.
+
+
+
+ + + + + + + + + + +
+ (0014233) +
+ Jens Grabowski    +
+ 14-11-2016 16:32    +
+ 		+ + + + +
+ Same as CR 0007473.
+
+
+
+ + + + + + + + + + +
+ (0014256) +
+ Kristóf Szabados    +
+ 15-11-2016 16:54    +
+ 		+ + + + +
+ Resolved in CR 7473
+
+
+
+ + + + + + + + + + +
+ (0014311) +
+ Kristóf Szabados    +
+ 17-11-2016 14:21    +
+ 		+ + + + +
+ incorrectly assigned at resolve
+
+
+
+ + + + + + + + + + +
+ (0014368) +
+ Gyorgy Rethy    +
+ 09-12-2016 15:43    +
+ 		+ + + + +
+ Resolution see in CR 7473
+
+ + diff --git a/docs/mantis/CR7472.md b/docs/mantis/CR7472.md new file mode 100644 index 0000000000000000000000000000000000000000..a5f15516a2bcc5fb22bea7360d6599374095e694 --- /dev/null +++ b/docs/mantis/CR7472.md @@ -0,0 +1,284 @@ + + + + + + + + + + + + + 0007472: mixed parameter-style lists should be allowed - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007472Part 01: TTCN-3 Core LanguageNew Featurepublic08-08-2016 15:3716-12-2016 19:25
ReporterJacob Wieland - Spirent 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.8.1 (published 2016-07) 
Target Versionv4.9.1 (published 2017-05)Fixed in Versionv4.9.1 (published 2017-05) 
Clause Reference(s)5.4.2
Source (company - Author)Spirent - Jacob Wieland
Summary0007472: mixed parameter-style lists should be allowed
DescriptionNormally, a paramterized entity has some mandatory parameters and possibly some optional ones. The mandatory are usually declared first in the formal parameter list and the optional ones later.
+
+Other languages like, for instance, Python allow the user to give the actual parameter list in a mixed style, where you would put first the parameters with a fixed place (i.e. the mandatory ones) and then can add additional ones in the named-parameter-style (i.e. assignment notation).
+
+This way, the user does not have to remember and over-and-over again write down the mandatory parameter names, but only has to write down what is absolutely necessary while still being concise.
Steps To Reproducetake the following function header
+
+function f(T1 mp1, ..., Tn mpn, O1 op1 := d1, ..., Om opm := dm);
+
+The instances of this function should be allowed to look like this:
+
+f(a1,...,an,opi := oai, opj := oaj)
Additional Information
TagsNo tags attached.
Relationships
related to 0007492closed Gyorgy Rethy duplication and ambiguity concerning actual par lists in BNF 
Attached Filesdocx CR7472.docx (236,213) 16-08-2016 13:16
http://oldforge.etsi.org/mantis/file_download.php?file_id=3461&type=bug
Issue History
Date ModifiedUsernameFieldChange
08-08-2016 15:37Jacob Wieland - SpirentNew Issue
15-08-2016 10:49Jens GrabowskiNote Added: 0014067
15-08-2016 10:50Jens GrabowskiAssigned To => Jacob Wieland - Spirent
15-08-2016 10:50Jens GrabowskiStatusnew => assigned
16-08-2016 12:07Jacob Wieland - SpirentRelationship addedrelated to 0007492
16-08-2016 13:16Jacob Wieland - SpirentFile Added: CR7472.docx
16-08-2016 13:16Jacob Wieland - SpirentNote Added: 0014107
16-08-2016 13:16Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Tomas Urban
16-08-2016 13:16Jacob Wieland - SpirentStatusassigned => confirmed
17-08-2016 10:27Tomas UrbanNote Added: 0014124
17-08-2016 10:27Tomas UrbanStatusconfirmed => resolved
17-08-2016 10:27Tomas UrbanResolutionopen => fixed
17-08-2016 10:27Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
17-08-2016 10:38Jacob Wieland - SpirentAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
17-08-2016 10:38Jacob Wieland - SpirentStatusresolved => feedback
17-08-2016 10:38Jacob Wieland - SpirentResolutionfixed => reopened
17-08-2016 10:42Jacob Wieland - SpirentNote Added: 0014126
17-08-2016 10:42Jacob Wieland - SpirentStatusfeedback => assigned
17-08-2016 10:42Jacob Wieland - SpirentStatusassigned => resolved
17-08-2016 10:42Jacob Wieland - SpirentResolutionreopened => fixed
17-08-2016 10:42Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
17-08-2016 11:20Jacob Wieland - SpirentProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
17-08-2016 11:20Jacob Wieland - SpirentStatusresolved => feedback
17-08-2016 11:20Jacob Wieland - SpirentResolutionfixed => reopened
17-08-2016 11:20Jacob Wieland - SpirentProduct Version => v4.8.1 (published 2016-07)
17-08-2016 11:20Jacob Wieland - SpirentTarget Version => v4.9.1 (published 2017-05)
17-08-2016 11:21Jacob Wieland - SpirentStatusfeedback => resolved
17-08-2016 11:21Jacob Wieland - SpirentFixed in Version => v4.9.1 (published 2017-05)
17-08-2016 11:21Jacob Wieland - SpirentResolutionreopened => fixed
13-12-2016 08:38Gyorgy RethyNote Added: 0014401
13-12-2016 08:40Gyorgy RethyStatusresolved => feedback
13-12-2016 08:40Gyorgy RethyResolutionfixed => reopened
14-12-2016 13:11Jacob Wieland - SpirentNote Added: 0014435
14-12-2016 13:11Jacob Wieland - SpirentStatusfeedback => assigned
16-12-2016 19:25Gyorgy RethyNote Added: 0014449
16-12-2016 19:25Gyorgy RethyStatusassigned => closed
16-12-2016 19:25Gyorgy RethyResolutionreopened => fixed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014067) +
+ Jens Grabowski    +
+ 15-08-2016 10:49    +
+ 		+ + + + +
+ STF discussion: resonable extension, Jacob prepares proposal.
+
+
+
+ + + + + + + + + + +
+ (0014107) +
+ Jacob Wieland - Spirent    +
+ 16-08-2016 13:16    +
+ 		+ + + + +
+ please review
+
+
+
+ + + + + + + + + + +
+ (0014124) +
+ Tomas Urban    +
+ 17-08-2016 10:27    +
+ 		+ + + + +
+ Proposal is ready to be included into the next version of the core language specification.
+
+
+
+ + + + + + + + + + +
+ (0014126) +
+ Jacob Wieland - Spirent    +
+ 17-08-2016 10:42    +
+ 		+ + + + +
+ please add a version number to this CR, if it is possible
+
+
+
+ + + + + + + + + + +
+ (0014401) +
+ Gyorgy Rethy    +
+ 13-12-2016 08:38    +
+ 		+ + + + +
+ Added to draft V4.8.2 with the addition to the new restriction m): "no value list notation shall be used following the first assignment notation"
+
+The whole restriction is now:
+"m) If the mixed notation is used, no value list notation shall be used following the first assignment notation and the parameters given in assignment notation shall not assign parameters that already have an actual parameter given in list notation."
+
+This is in line with the intention of the CR and the first paragraph of clause 5.4.2, but defines a formal rule for this requirement (otherwise we should define the semantics of a pure parameter value between two parameters with assignment notation).
+
+Please notify me if you disagree.
+
+
+
+ + + + + + + + + + +
+ (0014435) +
+ Jacob Wieland - Spirent    +
+ 14-12-2016 13:11    +
+ 		+ + + + +
+ Perfect!
+
+
+
+ + + + + + + + + + +
+ (0014449) +
+ Gyorgy Rethy    +
+ 16-12-2016 19:25    +
+ 		+ + + + +
+ Added to draft V4.8.2
+
+ + diff --git a/docs/mantis/CR7473.md b/docs/mantis/CR7473.md new file mode 100644 index 0000000000000000000000000000000000000000..e5ccd36c6f644264c7a9888babdae026edcd4fea --- /dev/null +++ b/docs/mantis/CR7473.md @@ -0,0 +1,527 @@ + + + + + + + + + + + + + 0007473: Chapter 6.2.1 inconsitencies in optionial attribute "explicit omit" - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007473Part 01: TTCN-3 Core LanguageEditorialpublic09-08-2016 11:3816-12-2016 21:37
ReporterMartin Hauch 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.9.1 (published 2017-05)Fixed in Versionv4.9.1 (published 2017-05) 
Clause Reference(s)6.2.1
Source (company - Author) Devoteam - Martin Hauch
Summary0007473: Chapter 6.2.1 inconsitencies in optionial attribute "explicit omit"
DescriptionThe "implicit explicit omit" rule applies also to variables, even if the optional attribute is not allowed for variables. There are 2 paragraphs in 6.2.1 which are not coherent, especially when reassigning variables:
+
+"
+Paragraph 1:
+When using the value list notation, all fields in the structure shall be specified either with a value, the not used symbol "-" or the omit keyword. The omit keyword shall only be used for optional fields. Its result is that the given field is not present in the given value. The first component of the list (a value, a "-" or omit) is associated with the first field, the second list component is associated with the second field, etc. No empty assignment is allowed (i.e. two commas, the second immediately following the first or only with white space between them). Fields or elements to be left unchanged shall be explicitly skipped in the list by using the not-used-symbol "-".
+
+Paragraph 2:
+When the value list notation is used in a scope, where the optional attribute is implicitly or explicitly set to "explicit omit, already initialized fields or elements left without an associated component in a value list notation (i.e. at the end of a value ) are becoming uninitialized. In this way, a value with initialized fields or elements can be made empty by using an empty pair of curly brackets ("{}").
+"
+
+Paragraph 1 says, ALL fields shall be specified. Paragraph 2 allows to leave out values if the optional attribute is implicitly set to explicit omit, which is the case in Paragraph 1!
+
+Also, paragraph 2 leads to the conclusion that if we have mandatory fields in the value, using "{}" to "clear" a value affects mandatory fields, whereas the "optional" attribute should only be related to optional fields in my opinion. This is very confusing and has to be clarified.
+
+As mentioned in CR7471 the assignment of sub-fields of a variable could be done by modified templates or
+myVar.field1[3]:= { ... }
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0007471closed Gyorgy Rethy editorial: inconsistency in the standard regarding partially initialized values 
related to 0007288closed Gyorgy Rethy Not described use cases for optional attribute 
Attached Filesdocx CR7288_CR7473_proposal.docx (160,152) 17-08-2016 10:16
http://oldforge.etsi.org/mantis/file_download.php?file_id=3468&type=bug
docx CR7288_CR7473_proposal_v2.docx (159,887) 17-08-2016 22:19
http://oldforge.etsi.org/mantis/file_download.php?file_id=3482&type=bug
docx CR7288_CR7473_proposal_v3.docx (163,514) 18-08-2016 14:12
http://oldforge.etsi.org/mantis/file_download.php?file_id=3489&type=bug
docx CR7288_CR7473_proposal_v4.docx (171,981) 01-09-2016 11:21
http://oldforge.etsi.org/mantis/file_download.php?file_id=3508&type=bug
docx CR7288_CR7473_proposal_v5.docx (172,677) 15-11-2016 16:42
http://oldforge.etsi.org/mantis/file_download.php?file_id=3527&type=bug
Issue History
Date ModifiedUsernameFieldChange
09-08-2016 11:38Martin HauchNew Issue
15-08-2016 10:36Jens GrabowskiAssigned To => Kristóf Szabados
15-08-2016 10:36Jens GrabowskiStatusnew => assigned
15-08-2016 10:37Jens GrabowskiRelationship addedrelated to 0007471
15-08-2016 10:42Jens GrabowskiNote Added: 0014066
17-08-2016 05:26Kristóf SzabadosRelationship addedrelated to 0007288
17-08-2016 05:32Kristóf SzabadosNote Added: 0014120
17-08-2016 07:04Martin HauchNote Added: 0014121
17-08-2016 10:16Kristóf SzabadosFile Added: CR7288_CR7473_proposal.docx
17-08-2016 11:03Jacob Wieland - SpirentTarget Version => v4.9.1 (published 2017-05)
17-08-2016 22:19Kristóf SzabadosFile Added: CR7288_CR7473_proposal_v2.docx
18-08-2016 14:12Kristóf SzabadosFile Added: CR7288_CR7473_proposal_v3.docx
19-08-2016 10:31Kristóf SzabadosNote Added: 0014175
22-08-2016 08:02Martin HauchNote Added: 0014193
01-09-2016 11:21Kristóf SzabadosFile Added: CR7288_CR7473_proposal_v4.docx
01-09-2016 11:47Kristóf SzabadosNote Added: 0014199
14-11-2016 16:31Jens GrabowskiAssigned ToKristóf Szabados => Axel Rennoch
14-11-2016 16:31Jens GrabowskiStatusassigned => confirmed
15-11-2016 16:42Axel RennochFile Added: CR7288_CR7473_proposal_v5.docx
15-11-2016 16:43Axel RennochNote Added: 0014255
15-11-2016 16:44Axel RennochAssigned ToAxel Rennoch => Gyorgy Rethy
15-11-2016 16:44Axel RennochStatusconfirmed => assigned
15-11-2016 16:44Axel RennochStatusassigned => resolved
15-11-2016 16:44Axel RennochResolutionopen => fixed
12-12-2016 09:43Gyorgy RethyNote Added: 0014369
12-12-2016 09:43Gyorgy RethyNote Edited: 0014369bug_revision_view_page.php?bugnote_id=14369#r338
12-12-2016 09:44Gyorgy RethyAssigned ToGyorgy Rethy => Jens Grabowski
12-12-2016 09:44Gyorgy RethyNote Added: 0014370
12-12-2016 09:44Gyorgy RethyStatusresolved => feedback
12-12-2016 09:44Gyorgy RethyResolutionfixed => reopened
12-12-2016 09:49Gyorgy RethyNote Deleted: 0014370
12-12-2016 11:18Jacob Wieland - SpirentNote Added: 0014380
12-12-2016 11:20Jacob Wieland - SpirentNote Edited: 0014380bug_revision_view_page.php?bugnote_id=14380#r340
14-12-2016 13:45Gyorgy RethyNote Added: 0014437
14-12-2016 16:34Jacob Wieland - SpirentNote Added: 0014438
16-12-2016 21:33Gyorgy RethyNote Added: 0014455
16-12-2016 21:37Gyorgy RethyStatusfeedback => closed
16-12-2016 21:37Gyorgy RethyAssigned ToJens Grabowski => Gyorgy Rethy
16-12-2016 21:37Gyorgy RethyResolutionreopened => fixed
16-12-2016 21:37Gyorgy RethyFixed in Version => v4.9.1 (published 2017-05)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014066) +
+ Jens Grabowski    +
+ 15-08-2016 10:42    +
+ 		+ + + + +
+ STF discussion:
+
+Paragraph 1: Makes only sense for "records"
+
+Paragraph 2: Makes only sense for "record of"
+
+
+
+ + + + + + + + + + +
+ (0014120) +
+ Kristóf Szabados    +
+ 17-08-2016 05:32    +
+ 		+ + + + +
+ CR7288 we also changed the example of section 6.2.1 where implicit/explicit omit is attached to variables, so that they are attached to constants.
+
+
+
+ + + + + + + + + + +
+ (0014121) +
+ Martin Hauch    +
+ 17-08-2016 07:04    +
+ 		+ + + + +
+ I agree, that paragraph 2 makes only sens for "record of", but it is defined in chapter "Record type and values" and all examples in this chapter are records.
+I also think the optional attribute is only allowed for record-values (not record- or set-of-values).
+So paragraph 2 either must be deleted or moved to chapter 6.2.3 "Records and sets of single types".
+
+
+
+ + + + + + + + + + +
+ (0014175) +
+ Kristóf Szabados    +
+ 19-08-2016 10:31    +
+ 		+ + + + +
+ STF discussion:
+- even in partial assignment cases fields in the assignment notation should be unique (section 6.2.0 2nd paragraph).
+- the same for index notation.
+
+- value list notation used on record/set type changes only the values listed in scopes where "optional omit" is set explicitly or implicitly
+
+- The first sentence of 15.5 (starting with "Normally, ") should be deleted as it does not introduce a new constraint.
+
+
+
+ + + + + + + + + + +
+ (0014193) +
+ Martin Hauch    +
+ 22-08-2016 08:02    +
+ 		+ + + + +
+ I think value list notation needs clarification: In my opinion value list needs complete value-assignment using '-' to let a field uninitialized or unchanged. Exception in case of "optional implicit omit", remaining optional fields at the end of the type definition (all remaining fields are optional), can be left out, if wished to be omitted.
+
+The first sentence of 15.5 should not be removed, as it clarifies that a modified template only changes values/matching-mechanisms for parts of a completely defined base-template. The base constraint is a complete assigned template. Templates need to be complete assigned, because they are used for sending and receiving (first sentence chapter 15 "Declaring templates".
+
+Remarks to changes in CR7288_CR7473_proposal_v3-1:
+
+Example 8 in chapter 6.2.1:
+const R c_x3 := { 1, -, 2 }
+// after the assignment c_x3 contains { 1, <undefined>, 2, <undefined>, <undefined>}
+const R c_x4 := c_x3 with { optional "implicit omit" }
+// after the assignment c_x4 contains { 1, omit, 2, omit, omit }
+
+Definition of c_x3 is not correct, because 6.2.1 says: "When using the value list notation, all fields in the notation shall be specified." There is no optional attribute "implicit omit" set. So, this line should look like
+
+const R c_x3 := { 1, -, 2, -, - };
+
+Remarks to examples in chapter 27.7:
+Templates definitions must be comlete in my opininion. Therefore i think most of the examples are not correct. Template are used for send/receive (as chapter 15 first sentence says) and this is only possible with complete defined templates!
+
+
+
+ + + + + + + + + + +
+ (0014199) +
+ Kristóf Szabados    +
+ 01-09-2016 11:47    +
+ 		+ + + + +
+ Sorry for the delay; uploaded the text version that is in line with the STF decision.
+
+The first sentence from 15.5 is removed as it does not add to or take away from the standard.
+It is read (and can be mentally extended with): normally, you should do something like this (at other times, other kinds of usages are fine too)
+
+Maybe we could add a note to show some generic programming best practices, something like this:
+"Those templates which will be used directly in send/receive operations shall be completely initialized, otherwise they would result in test case error at the time of the send/receive operation.
+On the other hand there are cases where some templates must, by design, never reach send/receive operations directly. For example partially initialized templates are to be used when one field must hold some unique identifier, that is not known statically. In these cases choosing any dummy number would run the risk of directing future tests, where the template is used and the field not overwritten, on unexpected execution paths. This would result in tests not testing what they were meant to be, and result in large debugging and maintenance cost where the problems is realised. Partially initialized templates can still be used to initialize other templates or as bases of modified templates; which have the uninitilized fields filled in, and can be used in send/receive operations"
+
+
+
+ + + + + + + + + + +
+ (0014255) +
+ Axel Rennoch    +
+ 15-11-2016 16:43    +
+ 		+ + + + +
+ just some small minor editorial modifications
+
+
+
+ + + + + + + + + + +
+ (0014369) +
+ Gyorgy Rethy    +
+ 12-12-2016 09:43    +
+ 		+ + + + +
+ Implemented the current v5 version of the resolution. During this I have noticed an issue.
+
+In clause 6.2.1.0 General, in the paragraph following example 4, is written
+"... The omit keyword shall only be used for optional fields. Its result is that the given field is not present in the given value. ..."
+
+The 2nd sentence is misleading as the field is not present in the ENCODED value, but present and perfectly defined in the abstract TTCN-3 value. I can see this type of misunderstanding at users several times.
+
+My proposals:
+a) delete the sentence
+b) move the sentence to a note and adding "...given field is not present in the encoded instance of the given value."
+
+What do you think?
+
+
+
+
+
+ + + + + + + + + + +
+ (0014380) +
+ Jacob Wieland - Spirent    +
+ 12-12-2016 11:18    +
(edited on: 12-12-2016 11:20)
+ 		+ + + + +
+ the concept of present-ness is tightly coupled with the optionality of fields, so I think it is perfectly alright stated as is. An optional field whose DEFINITION syntactically is present, but defined using omit is not present in the template(present) sense, i.e. ispresent() will yield false. Maybe this should be clarified in the definitions section, if not already clear enough.
+
+So, even unencoded, abstract TTCN-3 values can have optional field which are not present, not just encoded ones.
+
+
+
+
+
+ + + + + + + + + + +
+ (0014437) +
+ Gyorgy Rethy    +
+ 14-12-2016 13:45    +
+ 		+ + + + +
+ Seems we may have different understanding here.
+
+I think that
+template integer mw_int := omit;
+is an existing definition, i.e. present and defined at the abstract TTCN-3 level, it can be referenced in other definitions.
+
+To my view the same is true for optional fields:
+type record MyRec {
+  integer int optional
+}
+
+template MyRec mw_rec := {
+   int := omit
+}
+is not an empty record, but a record with one field, which has the omit property assigned (e.g. in PER it will even be encoded as a single "0" bit!); also isbound(mw_rec.int) will return true!
+
+At the abstract TTCN-3 level both the above template mw_int and template field mw_rec.int are reference-able and bound, therefore they shall exist (i.e. shall be present and set to the "special value" omit).
+
+PS: ispresent() is just a name given by us, the human meaning of a name doesn't define its semantics.
+
+
+
+ + + + + + + + + + +
+ (0014438) +
+ Jacob Wieland - Spirent    +
+ 14-12-2016 16:34    +
+ 		+ + + + +
+ Using that kind of definition of present-ness, pretty much everything is present, even the void, because that also can be referenced. Thus, such a definition is useless.
+
+Throughout the standard, we have a very clear understanding what 'being present' means in the context of an optional field of a value (i.e. it is initialized and not set to omit) or a template (it is initialized with a matching mechanism that does not match omit). This is captured by the semantics of the functions ispresent() and also by the template(present) restriction.
+
+To summarize: in my understanding explicitly or implicitly omitted fields are definitely not present in the value, they may be present in some form in the encoded value (i.e. their not-present-ness can take up some space in the encoded value), and of course they are present in some form also in the decoded value (i.e. represented by some data in the memory that captures the non-presentness), but from the TTCN-3 point of view, and that is what we are talking about in that section, they are not.
+
+
+
+ + + + + + + + + + +
+ (0014455) +
+ Gyorgy Rethy    +
+ 16-12-2016 21:33    +
+ 		+ + + + +
+ OK, it was just a side note for a possible last minute clarification; as the draft need to be submitted, I don't think we need to go into or have time for a discussion.
+
+ + diff --git a/docs/mantis/CR7474.md b/docs/mantis/CR7474.md new file mode 100644 index 0000000000000000000000000000000000000000..64c150cdc527c9cb70fe117a3c6140cc82e0a2b3 --- /dev/null +++ b/docs/mantis/CR7474.md @@ -0,0 +1,98 @@ + + + + + + + + + + + + + 0007474: Editorial issues in the core standard that look easy to fix - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007474Part 01: TTCN-3 Core LanguageEditorialpublic10-08-2016 15:0913-12-2016 14:22
ReporterKristóf Szabados 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.8.1 (published 2016-07) 
Target Versionv4.9.1 (published 2017-05)Fixed in Versionv4.9.1 (published 2017-05) 
Clause Reference(s)all over
Source (company - Author)L. M. Ericsson
Summary0007474: Editorial issues in the core standard that look easy to fix
DescriptionWe have found several problems in the core standard.
+This CR is for the typos, formatting problems which seem easy to fix.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR_7474.docx (1,393,200) 10-08-2016 15:11
http://oldforge.etsi.org/mantis/file_download.php?file_id=3438&type=bug
docx CR_7474-2.docx (1,778,099) 18-08-2016 14:18
http://oldforge.etsi.org/mantis/file_download.php?file_id=3490&type=bug
Issue History
Date ModifiedUsernameFieldChange
10-08-2016 15:09Kristóf SzabadosNew Issue
10-08-2016 15:11Kristóf SzabadosFile Added: CR_7474.docx
15-08-2016 10:32Jens GrabowskiAssigned To => Axel Rennoch
15-08-2016 10:32Jens GrabowskiStatusnew => assigned
17-08-2016 11:48Jacob Wieland - SpirentTarget Version => v4.9.1 (published 2017-05)
18-08-2016 14:18Axel RennochFile Added: CR_7474-2.docx
18-08-2016 14:23Axel RennochNote Added: 0014156
18-08-2016 14:23Axel RennochAssigned ToAxel Rennoch => Gyorgy Rethy
18-08-2016 14:23Axel RennochStatusassigned => acknowledged
13-12-2016 14:22Gyorgy RethyNote Added: 0014414
13-12-2016 14:22Gyorgy RethyStatusacknowledged => closed
13-12-2016 14:22Gyorgy RethyResolutionopen => fixed
13-12-2016 14:22Gyorgy RethyFixed in Version => v4.9.1 (published 2017-05)
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014156) +
+ Axel Rennoch    +
+ 18-08-2016 14:23    +
+ 		+ + + + +
+ Proposed changes have been checked, some minor corrections and update of figure 10 to be considered in next published version.
+
+
+
+ + + + + + + + + + +
+ (0014414) +
+ Gyorgy Rethy    +
+ 13-12-2016 14:22    +
+ 		+ + + + +
+ Added to draft V4.8.2
+
+ + diff --git a/docs/mantis/CR7475.md b/docs/mantis/CR7475.md new file mode 100644 index 0000000000000000000000000000000000000000..53bbb2ceee563e1188ab499847b785e00206e96c --- /dev/null +++ b/docs/mantis/CR7475.md @@ -0,0 +1,291 @@ + + + + + + + + + + + + + 0007475: Incorect example on indexing - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007475Part 01: TTCN-3 Core LanguageEditorialpublic11-08-2016 16:3512-12-2016 13:55
ReporterKristóf Szabados 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.8.1 (published 2016-07) 
Target Versionv4.9.1 (published 2017-05)Fixed in Versionv4.9.1 (published 2017-05) 
Clause Reference(s)6.2.3.0
Source (company - Author)L. M. Ericsson
Summary0007475: Incorect example on indexing
DescriptionIn section 6.2.3.0 the last example (on page 57) is incorrect:
+"
+var integer v_i[2] := { 1, 2 };
+v_myRecordOfArray [v_i] := 2;
+// is the same as assigning element v_myRecordOfArray[v_i[0]][v_i[1]]
+"
+
+The text of the standard implies that integers have to be used as index: "The index of the first element shall be zero and the index value shall not exceed the limitation placed by length subtyping"
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7475_resolution_v1.docx (158,138) 16-08-2016 09:02
http://oldforge.etsi.org/mantis/file_download.php?file_id=3447&type=bug
Issue History
Date ModifiedUsernameFieldChange
11-08-2016 16:35Kristóf SzabadosNew Issue
12-08-2016 12:51Jacob Wieland - SpirentNote Added: 0014055
12-08-2016 15:25Kristóf SzabadosNote Added: 0014056
14-08-2016 18:55Kristóf SzabadosNote Added: 0014057
15-08-2016 09:12Jacob Wieland - SpirentNote Added: 0014058
15-08-2016 09:50Jens GrabowskiAssigned To => Kristóf Szabados
15-08-2016 09:50Jens GrabowskiStatusnew => assigned
16-08-2016 09:02Kristóf SzabadosFile Added: CR7475_resolution_v1.docx
16-08-2016 09:04Kristóf SzabadosNote Added: 0014082
16-08-2016 09:04Kristóf SzabadosAssigned ToKristóf Szabados => Jacob Wieland - Spirent
16-08-2016 09:04Kristóf SzabadosStatusassigned => confirmed
16-08-2016 09:09Jacob Wieland - SpirentNote Added: 0014084
16-08-2016 09:09Jacob Wieland - SpirentStatusconfirmed => resolved
16-08-2016 09:09Jacob Wieland - SpirentFixed in Version => v4.8.1 (published 2016-07)
16-08-2016 09:09Jacob Wieland - SpirentResolutionopen => fixed
16-08-2016 09:09Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
17-08-2016 11:47Jacob Wieland - SpirentStatusresolved => feedback
17-08-2016 11:47Jacob Wieland - SpirentResolutionfixed => reopened
17-08-2016 11:48Jacob Wieland - SpirentFixed in Versionv4.8.1 (published 2016-07) => v4.9.1 (published 2017-05)
17-08-2016 11:48Jacob Wieland - SpirentTarget Version => v4.9.1 (published 2017-05)
17-08-2016 11:48Jacob Wieland - SpirentStatusfeedback => resolved
17-08-2016 11:48Jacob Wieland - SpirentResolutionreopened => fixed
12-12-2016 13:55Gyorgy RethyNote Added: 0014386
12-12-2016 13:55Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014055) +
+ Jacob Wieland - Spirent    +
+ 12-08-2016 12:51    +
+ 		+ + + + +
+ The feature that is exemplified by this example is introduced by the following sentence (same section):
+
+For nested record of or set of
+types, an array or record of integer restricted to a single size can be used as a short-hand notation for a nested index
+notation.
+
+
+
+ + + + + + + + + + +
+ (0014056) +
+ Kristóf Szabados    +
+ 12-08-2016 15:25    +
+ 		+ + + + +
+ But there is no word on how such notation works with loops, shift and rotate operations.
+At the same time mixing short-hand and not short-hand notations in the same context is a surefire way to create hard to understand and maintain code.
+
+Does not seem to be useful in practical situation currently.
+
+
+
+ + + + + + + + + + +
+ (0014057) +
+ Kristóf Szabados    +
+ 14-08-2016 18:55    +
+ 		+ + + + +
+ If I count right this notation is actually longer.
+In the example to save 2 characters, 24 were added (+ whitespaces).
+
+The notation only becomes shorter when working with >26 dimension matrices.
+
+
+
+ + + + + + + + + + +
+ (0014058) +
+ Jacob Wieland - Spirent    +
+ 15-08-2016 09:12    +
+ 		+ + + + +
+ To use the notation,of course, only makes sense if you use it multiple times. Normally, you would introduce more than one int variable instead of an int-array (so using the int-array is already kind of a shorthand notation).
+
+I really have no idea what you mean with 'how such notation works with loops, shift and rotate operations'. At the moment, these operations are not defined on index-arrays, if that is what you are implying. But, that is an interesting feature one might think about. Since an index-array always represents a flattened index in the corresponding flat array by multiplying with the dimension sizes, an algebra for such int-arrays could be thought defined.
+
+Anyway, at the moment, the standard does not concern itself with that, the only operation allowed as shorthand is the index-operation itself.
+
+
+
+ + + + + + + + + + +
+ (0014082) +
+ Kristóf Szabados    +
+ 16-08-2016 09:04    +
+ 		+ + + + +
+ Please review:
+- I have extracted the text of the short-hand notation into its own paragraph (this should not be hidden in something else)
+- I changed the example to show both the short and long notations.
+
+
+
+ + + + + + + + + + +
+ (0014084) +
+ Jacob Wieland - Spirent    +
+ 16-08-2016 09:09    +
+ 		+ + + + +
+ looks fine to me
+
+
+
+ + + + + + + + + + +
+ (0014386) +
+ Gyorgy Rethy    +
+ 12-12-2016 13:55    +
+ 		+ + + + +
+ Added to draft V4.8.2
+
+ + diff --git a/docs/mantis/CR7476.md b/docs/mantis/CR7476.md new file mode 100644 index 0000000000000000000000000000000000000000..58c5e7031a6bbd6d7a538c3f4c8fd230e476b6f3 --- /dev/null +++ b/docs/mantis/CR7476.md @@ -0,0 +1,218 @@ + + + + + + + + + + + + + 0007476: What does it mean to receive message from the null component? - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007476Part 01: TTCN-3 Core LanguageClarificationpublic11-08-2016 16:4612-12-2016 10:37
ReporterKristóf Szabados 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.8.1 (published 2016-07) 
Target Versionv4.9.1 (published 2017-05)Fixed in Versionv4.9.1 (published 2017-05) 
Clause Reference(s)6.2.11
Source (company - Author)L. M. Ericsson
Summary0007476: What does it mean to receive message from the null component?
Descriptionsection 6.2.11 example 4 (on page 70) shows:
+"
+var M1 v_myMessage, v_myResult;
+    var MyCompType1 myInst1 := null;
+    var MyCompType2 myInst2 := null;
+    var MyCompType3 myInst3 := null;
+     :
+    alt {
+        [] pCO1.receive(M1:?) from myInst1 -> value v_myMessage sender myInst1 {}
+        [] pCO1.receive(M1:?) from myInst2 -> value v_myMessage sender myInst2 {}
+        [] pCO1.receive(M1:?) from myInst3 -> value v_myMessage sender myInst3 {}
+    }
+"
+
+What does it mean to receive a message from the null component?
+
+I believe the components should be created in the example, so that messages can be received from them.
+This would also simplify the example.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7476-1.docx (21,194) 17-08-2016 14:19
http://oldforge.etsi.org/mantis/file_download.php?file_id=3475&type=bug
docx CR7476-2.docx (17,264) 17-08-2016 20:12
http://oldforge.etsi.org/mantis/file_download.php?file_id=3481&type=bug
docx CR7476-3.docx (22,227) 18-08-2016 09:11
http://oldforge.etsi.org/mantis/file_download.php?file_id=3485&type=bug
Issue History
Date ModifiedUsernameFieldChange
11-08-2016 16:46Kristóf SzabadosNew Issue
15-08-2016 10:28Jens GrabowskiAssigned To => Tomas Urban
15-08-2016 10:28Jens GrabowskiStatusnew => assigned
17-08-2016 11:46Jacob Wieland - SpirentTarget Version => v4.9.1 (published 2017-05)
17-08-2016 14:19Tomas UrbanFile Added: CR7476-1.docx
17-08-2016 14:20Tomas UrbanNote Added: 0014133
17-08-2016 14:20Tomas UrbanAssigned ToTomas Urban => Kristóf Szabados
17-08-2016 14:20Tomas UrbanStatusassigned => confirmed
17-08-2016 20:12Kristóf SzabadosFile Added: CR7476-2.docx
17-08-2016 20:14Kristóf SzabadosNote Added: 0014139
17-08-2016 20:14Kristóf SzabadosAssigned ToKristóf Szabados => Tomas Urban
17-08-2016 20:14Kristóf SzabadosStatusconfirmed => assigned
18-08-2016 09:11Tomas UrbanFile Added: CR7476-3.docx
18-08-2016 09:14Tomas UrbanNote Added: 0014148
18-08-2016 09:14Tomas UrbanAssigned ToTomas Urban => Kristóf Szabados
18-08-2016 09:14Tomas UrbanStatusassigned => confirmed
18-08-2016 09:34Kristóf SzabadosNote Added: 0014149
18-08-2016 09:34Kristóf SzabadosStatusconfirmed => resolved
18-08-2016 09:34Kristóf SzabadosFixed in Version => v4.9.1 (published 2017-05)
18-08-2016 09:34Kristóf SzabadosResolutionopen => fixed
18-08-2016 09:34Kristóf SzabadosAssigned ToKristóf Szabados => Gyorgy Rethy
12-12-2016 10:37Gyorgy RethyNote Added: 0014375
12-12-2016 10:37Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014133) +
+ Tomas Urban    +
+ 17-08-2016 14:20    +
+ 		+ + + + +
+ Change proposal uploaded. Please check.
+
+
+
+ + + + + + + + + + +
+ (0014139) +
+ Kristóf Szabados    +
+ 17-08-2016 20:14    +
+ 		+ + + + +
+ Your change looks fine by me.
+
+I just noticed the comment is using wrong type names, please check.
+
+
+
+ + + + + + + + + + +
+ (0014148) +
+ Tomas Urban    +
+ 18-08-2016 09:14    +
+ 		+ + + + +
+ That's correct. I also changed variable names so that there's a common naming convention in use. Please check.
+
+
+
+ + + + + + + + + + +
+ (0014149) +
+ Kristóf Szabados    +
+ 18-08-2016 09:34    +
+ 		+ + + + +
+ Looks fine by me.
+
+
+
+ + + + + + + + + + +
+ (0014375) +
+ Gyorgy Rethy    +
+ 12-12-2016 10:37    +
+ 		+ + + + +
+ Added to draft V4.8.2
+
+ + diff --git a/docs/mantis/CR7477.md b/docs/mantis/CR7477.md new file mode 100644 index 0000000000000000000000000000000000000000..861547b60979feade77f3e4bc2304dadf8f97993 --- /dev/null +++ b/docs/mantis/CR7477.md @@ -0,0 +1,78 @@ + + + + + + + + + + + + + 0007477: incorrect example reason for list subtyping - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007477Part 01: TTCN-3 Core LanguageClarificationpublic11-08-2016 17:0615-08-2016 10:24
ReporterKristóf Szabados 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionno change required 
PlatformOSOS Version
Product Versionv4.8.1 (published 2016-07) 
Target VersionFixed in Version 
Clause Reference(s)6.2.13.2
Source (company - Author)L. M. Ericsson
Summary0007477: incorrect example reason for list subtyping
Descriptionsection 6.2.13.2 shows an interesting reason at example1:
+"
+type MyRecordSub1 MyRecordSub3 (
+      { f1 := 1, f2 := "user", f3 := "password" },
+      { f1 := 1, f2 := "User", f3 := "Password" }
+    ) // invalid type as { f1 := 1, f2 := "user", f3 := "password" } is not a legal value of
+      // MyRecordSub1 (notice field f1)
+"
+
+Is this really an invalid type or an empty type as seen in example 2, a page later?
+1)
+as one of the restriction values is correct according to its parent type it should still be a valid type restricted to exactly one possible value.
+"Subtypes defined by a list subtyping restrict the allowed values of the subtype to the values matched by at least one of the constraints in the list"
+
+2)
+If all restriction values have to be valid in the parent type, like in StringArrayList4 in example2, it would still be an empty type.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
11-08-2016 17:06Kristóf SzabadosNew Issue
15-08-2016 10:23Jens GrabowskiNote Added: 0014065
15-08-2016 10:24Jens GrabowskiStatusnew => closed
15-08-2016 10:24Jens GrabowskiAssigned To => Jens Grabowski
15-08-2016 10:24Jens GrabowskiResolutionopen => no change required
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014065) +
+ Jens Grabowski    +
+ 15-08-2016 10:23    +
+ 		+ + + + +
+ Reject.
+
+ + diff --git a/docs/mantis/CR7478.md b/docs/mantis/CR7478.md new file mode 100644 index 0000000000000000000000000000000000000000..83d65feb0bfeba1570eb489e362c513ea0b5f708 --- /dev/null +++ b/docs/mantis/CR7478.md @@ -0,0 +1,134 @@ + + + + + + + + + + + + + 0007478: incorrect subtyping example - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007478Part 01: TTCN-3 Core LanguageEditorialpublic11-08-2016 17:1313-12-2016 15:06
ReporterKristóf Szabados 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionopen 
PlatformOSOS Version
Product Versionv4.8.1 (published 2016-07) 
Target Versionv4.10.1 (published 2018-05)Fixed in Versionv4.9.1 (published 2017-05) 
Clause Reference(s)6.2.13.3
Source (company - Author)L. M. Ericsson
Summary0007478: incorrect subtyping example
DescriptionIn section 6.2.13.3 the comment of "c_str12arr2D56_a" should mark it as erroneous, or there should be a type definition that makes it correct (to demonstrate correct usage).
+
+Currently it has type String12Array2D56 which "is an unordered two-dimensional array of the size 5*6 strings, each with exactly 12 characters".
+While it contains 2-3 character strings.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7478_resolution_v1.docx (81,909) 15-08-2016 15:00
http://oldforge.etsi.org/mantis/file_download.php?file_id=3445&type=bug
Issue History
Date ModifiedUsernameFieldChange
11-08-2016 17:13Kristóf SzabadosNew Issue
15-08-2016 10:16Jens GrabowskiNote Added: 0014064
15-08-2016 10:16Jens GrabowskiAssigned To => Axel Rennoch
15-08-2016 10:16Jens GrabowskiStatusnew => assigned
15-08-2016 15:00Axel RennochFile Added: CR7478_resolution_v1.docx
15-08-2016 15:01Axel RennochNote Added: 0014079
15-08-2016 15:01Axel RennochAssigned ToAxel Rennoch => Gyorgy Rethy
15-08-2016 15:01Axel RennochStatusassigned => confirmed
13-12-2016 15:06Gyorgy RethyNote Added: 0014419
13-12-2016 15:06Gyorgy RethyStatusconfirmed => closed
13-12-2016 15:06Gyorgy RethyProduct Version => v4.8.1 (published 2016-07)
13-12-2016 15:06Gyorgy RethyFixed in Version => v4.9.1 (published 2017-05)
13-12-2016 15:06Gyorgy RethyTarget Version => v4.10.1 (published 2018-05)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014064) +
+ Jens Grabowski    +
+ 15-08-2016 10:16    +
+ 		+ + + + +
+ STF discussion: Change String Length restriction.
+
+
+
+ + + + + + + + + + +
+ (0014079) +
+ Axel Rennoch    +
+ 15-08-2016 15:01    +
+ 		+ + + + +
+ Please check resolution and close CR.
+
+
+
+ + + + + + + + + + +
+ (0014419) +
+ Gyorgy Rethy    +
+ 13-12-2016 15:06    +
+ 		+ + + + +
+ Added to draft V4.8.2
+
+ + diff --git a/docs/mantis/CR7479.md b/docs/mantis/CR7479.md new file mode 100644 index 0000000000000000000000000000000000000000..0a084d2a75325d205f41e9af478ac42e101f388a --- /dev/null +++ b/docs/mantis/CR7479.md @@ -0,0 +1,145 @@ + + + + + + + + + + + + + 0007479: invalid examples where records and record ofs are compatible - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007479Part 01: TTCN-3 Core LanguageEditorialpublic11-08-2016 17:2512-12-2016 13:51
ReporterKristóf Szabados 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.8.1 (published 2016-07) 
Target Versionv4.9.1 (published 2017-05)Fixed in Versionv4.9.1 (published 2017-05) 
Clause Reference(s)6.3.2.2, 6.3.2.6
Source (company - Author)L. M. Ericsson
Summary0007479: invalid examples where records and record ofs are compatible
DescriptionThe compatibility of record and record of types is now deprecated, but there are some examples which were not rewritten.
+
+section 6.3.2.2, example 2:
+"
+v_myVarH := v_myVarI;
+    // is NOT a valid assignment as the mandatory field 'c' of Htype receives no value
+"
+They are also not compatible as v_myVarH is a record and v_myVarI is a record of variable.
+
+section 6.3.2.6:
+"
+v_myVarI := v_myVarJ.H;
+    // is a valid assignment as IType and the type of field H of JType are compatible
+"
+v_myVarI is a record of and v_myVarJ.H is a record
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7479-1.docx (21,041) 17-08-2016 11:38
http://oldforge.etsi.org/mantis/file_download.php?file_id=3471&type=bug
Issue History
Date ModifiedUsernameFieldChange
11-08-2016 17:25Kristóf SzabadosNew Issue
15-08-2016 10:13Jens GrabowskiAssigned To => Tomas Urban
15-08-2016 10:13Jens GrabowskiStatusnew => assigned
17-08-2016 11:38Tomas UrbanFile Added: CR7479-1.docx
17-08-2016 11:39Tomas UrbanNote Added: 0014129
17-08-2016 11:39Tomas UrbanAssigned ToTomas Urban => Kristóf Szabados
17-08-2016 11:39Tomas UrbanStatusassigned => confirmed
17-08-2016 11:45Jacob Wieland - SpirentTarget Version => v4.9.1 (published 2017-05)
17-08-2016 20:22Kristóf SzabadosNote Added: 0014140
17-08-2016 20:22Kristóf SzabadosStatusconfirmed => resolved
17-08-2016 20:22Kristóf SzabadosFixed in Version => v4.9.1 (published 2017-05)
17-08-2016 20:22Kristóf SzabadosResolutionopen => fixed
17-08-2016 20:22Kristóf SzabadosAssigned ToKristóf Szabados => Gyorgy Rethy
12-12-2016 13:51Gyorgy RethyNote Added: 0014385
12-12-2016 13:51Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014129) +
+ Tomas Urban    +
+ 17-08-2016 11:39    +
+ 		+ + + + +
+ Possible resolution uploaded. Please check.
+
+
+
+ + + + + + + + + + +
+ (0014140) +
+ Kristóf Szabados    +
+ 17-08-2016 20:22    +
+ 		+ + + + +
+ Looks fine by me.
+
+
+
+ + + + + + + + + + +
+ (0014385) +
+ Gyorgy Rethy    +
+ 12-12-2016 13:51    +
+ 		+ + + + +
+ Added to V4.8.2
+
+ + diff --git a/docs/mantis/CR7480.md b/docs/mantis/CR7480.md new file mode 100644 index 0000000000000000000000000000000000000000..8cbd1be27cd9636f70f8224b43769710d36b02eb --- /dev/null +++ b/docs/mantis/CR7480.md @@ -0,0 +1,104 @@ + + + + + + + + + + + + + 0007480: incorrect example for name clash - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007480Part 01: TTCN-3 Core LanguageEditorialpublic11-08-2016 18:0613-12-2016 14:52
ReporterKristóf Szabados 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.8.1 (published 2016-07) 
Target Versionv4.9.1 (published 2017-05)Fixed in Versionv4.9.1 (published 2017-05) 
Clause Reference(s)8.2.3.1
Source (company - Author)L. M. Ericsson
Summary0007480: incorrect example for name clash
Descriptionsection 8.2.3.1 example 4 contains:
+"
+const MyEnumType2 enumX := enumX;// this is likewise not allowed
+"
+where "type enumerated MyEnumType2 {enumY, enumZ}"
+
+The example could be improved if enumY or enumZ would be on the right hand side.
+Currently it is also erroneous as it references a non-existing enumerated value (or missing definition)
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7480_resolution_v1.docx (97,648) 15-08-2016 14:20
http://oldforge.etsi.org/mantis/file_download.php?file_id=3443&type=bug
Issue History
Date ModifiedUsernameFieldChange
11-08-2016 18:06Kristóf SzabadosNew Issue
15-08-2016 10:12Jens GrabowskiAssigned To => Axel Rennoch
15-08-2016 10:12Jens GrabowskiStatusnew => assigned
15-08-2016 14:20Axel RennochFile Added: CR7480_resolution_v1.docx
15-08-2016 14:21Axel RennochNote Added: 0014077
15-08-2016 14:21Axel RennochAssigned ToAxel Rennoch => Gyorgy Rethy
15-08-2016 14:21Axel RennochStatusassigned => confirmed
17-08-2016 11:43Jacob Wieland - SpirentTarget Version => v4.9.1 (published 2017-05)
13-12-2016 14:52Gyorgy RethyNote Added: 0014417
13-12-2016 14:52Gyorgy RethyStatusconfirmed => closed
13-12-2016 14:52Gyorgy RethyResolutionopen => fixed
13-12-2016 14:52Gyorgy RethyFixed in Version => v4.9.1 (published 2017-05)
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014077) +
+ Axel Rennoch    +
+ 15-08-2016 14:21    +
+ 		+ + + + +
+ Please check and close CR.
+
+
+
+ + + + + + + + + + +
+ (0014417) +
+ Gyorgy Rethy    +
+ 13-12-2016 14:52    +
+ 		+ + + + +
+ Added to draft V4.8.2
+
+ + diff --git a/docs/mantis/CR7481.md b/docs/mantis/CR7481.md new file mode 100644 index 0000000000000000000000000000000000000000..32b26f719dca22f31565ae82a7ee441fa30305de --- /dev/null +++ b/docs/mantis/CR7481.md @@ -0,0 +1,137 @@ + + + + + + + + + + + + + 0007481: fuzzy variables/parameters should be excluded from receiving communication operations - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007481Part 01: TTCN-3 Core LanguageClarificationpublic11-08-2016 18:5612-12-2016 10:41
ReporterKristóf Szabados 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.8.1 (published 2016-07) 
Target Versionv4.9.1 (published 2017-05)Fixed in Versionv4.9.1 (published 2017-05) 
Clause Reference(s)16.1.4
Source (company - Author)L. M. Ericsson
Summary0007481: fuzzy variables/parameters should be excluded from receiving communication operations
Descriptionin section 16.1.4 the list of all of the operations which shall not be used in functions called in receiving communication operations to avoid side effects, should be extended with fuzzy variables/parameters.
+
+Currently it is ok to call a function with a @fuzzy in parameter ... although these parameters might be evaluated to different values on every use.
+
+Adding:
+"k) Calling functions and external functions with @fuzzy formal parameters and variables"
+could solve the problem.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7481_resolution_v1.docx (153,317) 16-08-2016 14:03
http://oldforge.etsi.org/mantis/file_download.php?file_id=3462&type=bug
Issue History
Date ModifiedUsernameFieldChange
11-08-2016 18:56Kristóf SzabadosNew Issue
15-08-2016 10:12Jens GrabowskiNote Added: 0014063
15-08-2016 10:12Jens GrabowskiAssigned To => Kristóf Szabados
15-08-2016 10:12Jens GrabowskiStatusnew => assigned
16-08-2016 14:03Kristóf SzabadosFile Added: CR7481_resolution_v1.docx
17-08-2016 11:36Jacob Wieland - SpirentTarget Version => v4.9.1 (published 2017-05)
17-08-2016 20:24Kristóf SzabadosNote Added: 0014141
17-08-2016 20:24Kristóf SzabadosAssigned ToKristóf Szabados => Jens Grabowski
17-08-2016 20:24Kristóf SzabadosStatusassigned => confirmed
18-08-2016 09:20Jens GrabowskiStatusconfirmed => resolved
18-08-2016 09:20Jens GrabowskiFixed in Version => v4.9.1 (published 2017-05)
18-08-2016 09:20Jens GrabowskiResolutionopen => fixed
18-08-2016 09:20Jens GrabowskiAssigned ToJens Grabowski => Gyorgy Rethy
12-12-2016 10:41Gyorgy RethyNote Added: 0014376
12-12-2016 10:41Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014063) +
+ Jens Grabowski    +
+ 15-08-2016 10:12    +
+ 		+ + + + +
+ Kristof: Please crosscheck with György.
+
+
+
+ + + + + + + + + + +
+ (0014141) +
+ Kristóf Szabados    +
+ 17-08-2016 20:24    +
+ 		+ + + + +
+ Check with Gyorgy: most probably this was just left un-intentionally.
+
+
+
+ + + + + + + + + + +
+ (0014376) +
+ Gyorgy Rethy    +
+ 12-12-2016 10:41    +
+ 		+ + + + +
+ Added to V4.8.2
+
+ + diff --git a/docs/mantis/CR7482.md b/docs/mantis/CR7482.md new file mode 100644 index 0000000000000000000000000000000000000000..56e4c6e160e954fee717b830d07d6606c1bf10c7 --- /dev/null +++ b/docs/mantis/CR7482.md @@ -0,0 +1,148 @@ + + + + + + + + + + + + + 0007482: example implies that a done component might still be running - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007482Part 01: TTCN-3 Core LanguageClarificationpublic11-08-2016 19:2012-12-2016 13:36
ReporterKristóf Szabados 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.8.1 (published 2016-07) 
Target Versionv4.9.1 (published 2017-05)Fixed in Versionv4.9.1 (published 2017-05) 
Clause Reference(s)21.3.7
Source (company - Author)L. M. Ericsson
Summary0007482: example implies that a done component might still be running
DescriptionIn section 21.3.7 in the last example there is an interesting part:
+"
+v_c.done;
+        // matches as soon as the function f_myPTCBehaviour (or function/altstep called by it) stops
+    v_c.done;
+        // matches the end of f_myPTCBehaviour (or function/altstep called by it) too
+    if(v_c.running) {v_c.done}
+        // done here matches the end of the next behaviour only
+"
+
+If I understand correctly the first v_c.done waits until the end of v_c's behaviour terminates.
+
+1)
+In which case the second v_c.done is not needed or the comment should tell, why it is useful to wait or check the done state of that component.
+
+2)
+After 2 v_c.done operations the v_c.running should not be true.
+But the comment implies that the component referenced was somehow re-started.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7482.docx (155,711) 16-08-2016 09:58
http://oldforge.etsi.org/mantis/file_download.php?file_id=3456&type=bug
Issue History
Date ModifiedUsernameFieldChange
11-08-2016 19:20Kristóf SzabadosNew Issue
15-08-2016 10:11Jens GrabowskiAssigned To => Jacob Wieland - Spirent
15-08-2016 10:11Jens GrabowskiStatusnew => assigned
16-08-2016 09:58Jacob Wieland - SpirentFile Added: CR7482.docx
16-08-2016 09:58Jacob Wieland - SpirentNote Added: 0014095
16-08-2016 09:58Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Kristóf Szabados
16-08-2016 09:58Jacob Wieland - SpirentStatusassigned => confirmed
16-08-2016 10:02Kristóf SzabadosNote Added: 0014096
16-08-2016 10:03Kristóf SzabadosStatusconfirmed => resolved
16-08-2016 10:03Kristóf SzabadosFixed in Version => v4.8.1 (published 2016-07)
16-08-2016 10:03Kristóf SzabadosResolutionopen => fixed
16-08-2016 10:03Kristóf SzabadosAssigned ToKristóf Szabados => Gyorgy Rethy
12-12-2016 13:36Gyorgy RethyNote Added: 0014384
12-12-2016 13:36Gyorgy RethyStatusresolved => closed
12-12-2016 13:36Gyorgy RethyFixed in Versionv4.8.1 (published 2016-07) => v4.9.1 (published 2017-05)
12-12-2016 13:36Gyorgy RethyTarget Version => v4.9.1 (published 2017-05)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014095) +
+ Jacob Wieland - Spirent    +
+ 16-08-2016 09:58    +
+ 		+ + + + +
+ please review
+
+
+
+ + + + + + + + + + +
+ (0014096) +
+ Kristóf Szabados    +
+ 16-08-2016 10:02    +
+ 		+ + + + +
+ Looks fine by me.
+
+
+
+ + + + + + + + + + +
+ (0014384) +
+ Gyorgy Rethy    +
+ 12-12-2016 13:36    +
+ 		+ + + + +
+ Added to draft V4.8.2
+
+ + diff --git a/docs/mantis/CR7483.md b/docs/mantis/CR7483.md new file mode 100644 index 0000000000000000000000000000000000000000..6800d6b6217c8e034bb2dd2c4be4621f0794f690 --- /dev/null +++ b/docs/mantis/CR7483.md @@ -0,0 +1,170 @@ + + + + + + + + + + + + + 0007483: incorrect description of behaviour when a receive operation is not successful - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007483Part 01: TTCN-3 Core LanguageEditorialpublic11-08-2016 19:2812-12-2016 16:34
ReporterKristóf Szabados 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.8.1 (published 2016-07) 
Target VersionFixed in Versionv4.9.1 (published 2017-05) 
Clause Reference(s)22.2.2
Source (company - Author)L. M. Ericsson
Summary0007483: incorrect description of behaviour when a receive operation is not successful
Descriptionin section 22.2.2 the text says:
+"... if the receive operation is used as an alternative of an alt statement and it is not successful, the execution of the test case shall continue with the next alternative of the alt statement."
+
+I believe the execution should continue with the evaluation of the next alternative of the alt statement.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7483_resolution_v1.docx (160,177) 16-08-2016 09:05
http://oldforge.etsi.org/mantis/file_download.php?file_id=3448&type=bug
Issue History
Date ModifiedUsernameFieldChange
11-08-2016 19:28Kristóf SzabadosNew Issue
15-08-2016 10:07Jens GrabowskiNote Added: 0014062
15-08-2016 10:08Jens GrabowskiAssigned To => Kristóf Szabados
15-08-2016 10:08Jens GrabowskiStatusnew => assigned
16-08-2016 09:05Kristóf SzabadosFile Added: CR7483_resolution_v1.docx
16-08-2016 09:05Kristóf SzabadosNote Added: 0014083
16-08-2016 09:05Kristóf SzabadosAssigned ToKristóf Szabados => Jens Grabowski
16-08-2016 09:05Kristóf SzabadosStatusassigned => confirmed
16-08-2016 09:18Jens GrabowskiNote Added: 0014086
16-08-2016 09:18Jens GrabowskiStatusconfirmed => resolved
16-08-2016 09:18Jens GrabowskiResolutionopen => fixed
16-08-2016 09:18Jens GrabowskiAssigned ToJens Grabowski => Gyorgy Rethy
12-12-2016 16:34Gyorgy RethyNote Added: 0014391
12-12-2016 16:34Gyorgy RethyStatusresolved => closed
12-12-2016 16:34Gyorgy RethyFixed in Version => v4.9.1 (published 2017-05)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014062) +
+ Jens Grabowski    +
+ 15-08-2016 10:07    +
+ 		+ + + + +
+ Change to:
+
+"... if the receive operation is used as an alternative of an alt statement and it is not successful, the execution of alt statement shall continue with its next alternative."
+
+
+
+ + + + + + + + + + +
+ (0014083) +
+ Kristóf Szabados    +
+ 16-08-2016 09:05    +
+ 		+ + + + +
+ please review: text changed as aggreed.
+
+
+
+ + + + + + + + + + +
+ (0014086) +
+ Jens Grabowski    +
+ 16-08-2016 09:18    +
+ 		+ + + + +
+ Resolution as discussed in the STF.
+
+
+
+ + + + + + + + + + +
+ (0014391) +
+ Gyorgy Rethy    +
+ 12-12-2016 16:34    +
+ 		+ + + + +
+ Added to V4.8.2
+
+ + diff --git a/docs/mantis/CR7484.md b/docs/mantis/CR7484.md new file mode 100644 index 0000000000000000000000000000000000000000..d75f1ee386182073851ad1bb8432038de88250b9 --- /dev/null +++ b/docs/mantis/CR7484.md @@ -0,0 +1,206 @@ + + + + + + + + + + + + + 0007484: interesting timeout restriction - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007484Part 01: TTCN-3 Core LanguageClarificationpublic11-08-2016 19:3512-12-2016 11:09
ReporterKristóf Szabados 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.8.1 (published 2016-07) 
Target Versionv4.9.1 (published 2017-05)Fixed in Versionv4.9.1 (published 2017-05) 
Clause Reference(s)23.6
Source (company - Author)L. M. Ericsson
Summary0007484: interesting timeout restriction
Descriptionin section 23.6 there is a restriction:
+"
+a) The timeout shall not be used in a boolean expression.
+"
+
+If I understand correctly timeout does not have a return value, so it can not be used in any expression, regardless of the expression's type.
+
+Is there a reason for this specific restriction to exist?
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7484_resolution_v1.docx (80,467) 16-08-2016 12:56
http://oldforge.etsi.org/mantis/file_download.php?file_id=3460&type=bug
Issue History
Date ModifiedUsernameFieldChange
11-08-2016 19:35Kristóf SzabadosNew Issue
15-08-2016 09:57Jens GrabowskiNote Added: 0014060
15-08-2016 09:58Jens GrabowskiNote Added: 0014061
15-08-2016 09:58Jens GrabowskiAssigned To => Axel Rennoch
15-08-2016 09:58Jens GrabowskiStatusnew => assigned
16-08-2016 12:56Axel RennochFile Added: CR7484_resolution_v1.docx
16-08-2016 12:57Axel RennochNote Added: 0014105
16-08-2016 12:57Axel RennochAssigned ToAxel Rennoch => Kristóf Szabados
16-08-2016 12:57Axel RennochStatusassigned => acknowledged
16-08-2016 13:11Kristóf SzabadosNote Added: 0014106
16-08-2016 13:11Kristóf SzabadosStatusacknowledged => resolved
16-08-2016 13:11Kristóf SzabadosFixed in Version => v4.8.1 (published 2016-07)
16-08-2016 13:11Kristóf SzabadosResolutionopen => fixed
16-08-2016 13:11Kristóf SzabadosAssigned ToKristóf Szabados => Gyorgy Rethy
17-08-2016 10:53Jacob Wieland - SpirentStatusresolved => feedback
17-08-2016 10:53Jacob Wieland - SpirentResolutionfixed => reopened
17-08-2016 10:53Jacob Wieland - SpirentTarget Version => v4.9.1 (published 2017-05)
17-08-2016 10:53Jacob Wieland - SpirentStatusfeedback => resolved
17-08-2016 10:53Jacob Wieland - SpirentResolutionreopened => fixed
12-12-2016 11:09Gyorgy RethyNote Added: 0014379
12-12-2016 11:09Gyorgy RethyFixed in Versionv4.8.1 (published 2016-07) => v4.9.1 (published 2017-05)
12-12-2016 11:09Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014060) +
+ Jens Grabowski    +
+ 15-08-2016 09:57    +
+ 		+ + + + +
+ STF discussion: Remove Restriction
+
+
+
+ + + + + + + + + + +
+ (0014061) +
+ Jens Grabowski    +
+ 15-08-2016 09:58    +
+ 		+ + + + +
+ STF discussion Note 2: Change into a more general note: "can not be used in expressions"
+
+
+
+ + + + + + + + + + +
+ (0014105) +
+ Axel Rennoch    +
+ 16-08-2016 12:57    +
+ 		+ + + + +
+ Please check and confirm the modification in the draft resolution.
+
+
+
+ + + + + + + + + + +
+ (0014106) +
+ Kristóf Szabados    +
+ 16-08-2016 13:11    +
+ 		+ + + + +
+ Looks good to me.
+
+
+
+ + + + + + + + + + +
+ (0014379) +
+ Gyorgy Rethy    +
+ 12-12-2016 11:09    +
+ 		+ + + + +
+ Added to draft V4.8.2
+
+ + diff --git a/docs/mantis/CR7485.md b/docs/mantis/CR7485.md new file mode 100644 index 0000000000000000000000000000000000000000..2aaddcd84f960914dc7264ab8e67150d85f639d6 --- /dev/null +++ b/docs/mantis/CR7485.md @@ -0,0 +1,110 @@ + + + + + + + + + + + + + 0007485: duplicated example - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007485Part 01: TTCN-3 Core LanguageEditorialpublic11-08-2016 19:4113-12-2016 14:49
ReporterKristóf Szabados 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.8.1 (published 2016-07) 
Target Versionv4.9.1 (published 2017-05)Fixed in Versionv4.9.1 (published 2017-05) 
Clause Reference(s)26.1
Source (company - Author)L. M. Ericsson
Summary0007485: duplicated example
Descriptionin section 26.1 example 3 both examples are essentially the same.
+"
+v_myVerdict := execute(TC_MyTestCase3(),5E-3); // executes TC_MyTestCase3 and stores the
+                                                // resulting verdict in variable MyVerdict. If the
+                                                // test case does not terminate within 5ms,
+                                                // v_myVerdict will get the value 'error'
+
+    v_myReturnVal := execute (TC_MyTestCase(), 7E-3);
+    // Where the return verdict will be error if TC_MyTestCase does not complete execution
+    // within 7ms
+"
+
+The second example is unnecessary.
+Unless it originally tried to demonstrate some other behaviour (maybe an explicitly set unlimited timer)
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7485_resolution_v1.docx (82,505) 15-08-2016 14:04
http://oldforge.etsi.org/mantis/file_download.php?file_id=3441&type=bug
Issue History
Date ModifiedUsernameFieldChange
11-08-2016 19:41Kristóf SzabadosNew Issue
15-08-2016 09:55Jens GrabowskiAssigned To => Axel Rennoch
15-08-2016 09:55Jens GrabowskiStatusnew => assigned
15-08-2016 14:04Axel RennochFile Added: CR7485_resolution_v1.docx
15-08-2016 14:06Axel RennochNote Added: 0014074
15-08-2016 14:06Axel RennochAssigned ToAxel Rennoch => Gyorgy Rethy
15-08-2016 14:06Axel RennochStatusassigned => confirmed
17-08-2016 11:45Jacob Wieland - SpirentTarget Version => v4.9.1 (published 2017-05)
13-12-2016 14:49Gyorgy RethyNote Added: 0014416
13-12-2016 14:49Gyorgy RethyStatusconfirmed => closed
13-12-2016 14:49Gyorgy RethyResolutionopen => fixed
13-12-2016 14:49Gyorgy RethyFixed in Version => v4.9.1 (published 2017-05)
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014074) +
+ Axel Rennoch    +
+ 15-08-2016 14:06    +
+ 		+ + + + +
+ Please check corrections in resolution and close CR.
+
+
+
+ + + + + + + + + + +
+ (0014416) +
+ Gyorgy Rethy    +
+ 13-12-2016 14:49    +
+ 		+ + + + +
+ Added to draft V4.8.2
+
+ + diff --git a/docs/mantis/CR7486.md b/docs/mantis/CR7486.md new file mode 100644 index 0000000000000000000000000000000000000000..46c217412b09cf82ace507955467628fd802aa5a --- /dev/null +++ b/docs/mantis/CR7486.md @@ -0,0 +1,109 @@ + + + + + + + + + + + + + 0007486: incorrect example for the display attribute - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007486Part 01: TTCN-3 Core LanguageEditorialpublic11-08-2016 19:4513-12-2016 14:58
ReporterKristóf Szabados 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.8.1 (published 2016-07) 
Target Versionv4.9.1 (published 2017-05)Fixed in Versionv4.9.1 (published 2017-05) 
Clause Reference(s)27.1.1
Source (company - Author)L. M. Ericsson
Summary0007486: incorrect example for the display attribute
DescriptionIn section 27.1.1 the last example has incorrect comment.
+
+"
+type record of integer MyRecOfInteger
+    with { display ([-]) "colour green"
+    // all integer elements are displayed green
+...
+const MyRecOfInteger c_MyRecordOfInt := {0, 1, 2, 3}
+    with { display ([0]) "colour blue" }
+    // the first element is displayed blue, the other elements are displayed red
+"
+
+No display attribute is set to anything with "color red"
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7486_resolution_v1.docx (79,293) 15-08-2016 14:37
http://oldforge.etsi.org/mantis/file_download.php?file_id=3444&type=bug
Issue History
Date ModifiedUsernameFieldChange
11-08-2016 19:45Kristóf SzabadosNew Issue
15-08-2016 09:54Jens GrabowskiAssigned To => Axel Rennoch
15-08-2016 09:54Jens GrabowskiStatusnew => assigned
15-08-2016 14:37Axel RennochFile Added: CR7486_resolution_v1.docx
15-08-2016 14:37Axel RennochNote Added: 0014078
15-08-2016 14:37Axel RennochAssigned ToAxel Rennoch => Gyorgy Rethy
15-08-2016 14:37Axel RennochStatusassigned => confirmed
17-08-2016 11:37Jacob Wieland - SpirentTarget Version => v4.9.1 (published 2017-05)
13-12-2016 14:58Gyorgy RethyNote Added: 0014418
13-12-2016 14:58Gyorgy RethyStatusconfirmed => closed
13-12-2016 14:58Gyorgy RethyResolutionopen => fixed
13-12-2016 14:58Gyorgy RethyFixed in Version => v4.9.1 (published 2017-05)
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014078) +
+ Axel Rennoch    +
+ 15-08-2016 14:37    +
+ 		+ + + + +
+ Please check resolution and close CR.
+
+
+
+ + + + + + + + + + +
+ (0014418) +
+ Gyorgy Rethy    +
+ 13-12-2016 14:58    +
+ 		+ + + + +
+ Added to draft V4.8.2
+
+ + diff --git a/docs/mantis/CR7487.md b/docs/mantis/CR7487.md new file mode 100644 index 0000000000000000000000000000000000000000..0c1198abf316f422dd7adb1af4ced7c48844a775 --- /dev/null +++ b/docs/mantis/CR7487.md @@ -0,0 +1,213 @@ + + + + + + + + + + + + + 0007487: inconsistent examples and naming in Annex B - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007487Part 01: TTCN-3 Core LanguageEditorialpublic12-08-2016 08:2512-12-2016 13:30
ReporterKristóf Szabados 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.8.1 (published 2016-07) 
Target Versionv4.9.1 (published 2017-05)Fixed in Versionv4.9.1 (published 2017-05) 
Clause Reference(s)Annex B
Source (company - Author)L. M. Ericsson
Summary0007487: inconsistent examples and naming in Annex B
DescriptionIn Annex B has is very good design idea of declaring the type the examples work on, right before the example.
+
+but:
+1)
+in some cases this type definition is just not there. So it is not clear which type the name is referring to.
+
+Should be fixed by showing the declaration of the type.
+
+2)
+The name MyMessage should be consistently changed to MyMessageType in the chapter, to follow the naming conventions present here.
+When it is declared used as a type.
+
+
+
+These changes would make the chapter easier to follow.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0007488closed Gyorgy Rethy incorrect examples in annex B 
related to 0007271closed Gyorgy Rethy template(present) restriction shall also apply to individual elements of complement,superset,subset,permutation lists 
Attached Filesdocx CR7487_7488_resolution_v1.docx (157,987) 16-08-2016 09:24
http://oldforge.etsi.org/mantis/file_download.php?file_id=3452&type=bug
Issue History
Date ModifiedUsernameFieldChange
12-08-2016 08:25Kristóf SzabadosNew Issue
15-08-2016 09:53Jens GrabowskiAssigned To => Axel Rennoch
15-08-2016 09:53Jens GrabowskiStatusnew => assigned
16-08-2016 09:24Axel RennochFile Added: CR7487_7488_resolution_v1.docx
16-08-2016 09:25Axel RennochNote Added: 0014089
16-08-2016 09:28Axel RennochNote Added: 0014092
16-08-2016 09:28Axel RennochAssigned ToAxel Rennoch => Kristóf Szabados
16-08-2016 09:28Axel RennochStatusassigned => acknowledged
16-08-2016 10:02Jacob Wieland - SpirentRelationship addedrelated to 0007488
16-08-2016 10:13Kristóf SzabadosNote Added: 0014097
16-08-2016 10:13Kristóf SzabadosStatusacknowledged => resolved
16-08-2016 10:13Kristóf SzabadosFixed in Version => v4.8.1 (published 2016-07)
16-08-2016 10:13Kristóf SzabadosResolutionopen => fixed
16-08-2016 10:13Kristóf SzabadosAssigned ToKristóf Szabados => Gyorgy Rethy
16-08-2016 15:26Axel RennochNote Added: 0014113
16-08-2016 15:26Axel RennochStatusresolved => feedback
16-08-2016 15:26Axel RennochResolutionfixed => reopened
16-08-2016 15:26Axel RennochRelationship addedrelated to 0007271
17-08-2016 11:44Jacob Wieland - SpirentFixed in Versionv4.8.1 (published 2016-07) => v4.9.1 (published 2017-05)
17-08-2016 11:44Jacob Wieland - SpirentTarget Version => v4.9.1 (published 2017-05)
17-08-2016 11:44Jacob Wieland - SpirentStatusfeedback => resolved
17-08-2016 11:44Jacob Wieland - SpirentResolutionreopened => fixed
12-12-2016 13:30Gyorgy RethyNote Added: 0014381
12-12-2016 13:30Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014089) +
+ Axel Rennoch    +
+ 16-08-2016 09:25    +
+ 		+ + + + +
+ The resolution uploaded covers also 7488.
+
+
+
+ + + + + + + + + + +
+ (0014092) +
+ Axel Rennoch    +
+ 16-08-2016 09:28    +
+ 		+ + + + +
+ Please check the uploaded resolution and assign any updated/confirmed version to György.
+
+
+
+ + + + + + + + + + +
+ (0014097) +
+ Kristóf Szabados    +
+ 16-08-2016 10:13    +
+ 		+ + + + +
+ The resolution looks fine by me
+
+
+
+ + + + + + + + + + +
+ (0014113) +
+ Axel Rennoch    +
+ 16-08-2016 15:26    +
+ 		+ + + + +
+ actual resolution has been modified due to CR7271 resolution.
+
+
+
+ + + + + + + + + + +
+ (0014381) +
+ Gyorgy Rethy    +
+ 12-12-2016 13:30    +
+ 		+ + + + +
+ Implemented in CR 7271
+
+ + diff --git a/docs/mantis/CR7488.md b/docs/mantis/CR7488.md new file mode 100644 index 0000000000000000000000000000000000000000..90b6b29541406705c28f337225c09bf15b40a129 --- /dev/null +++ b/docs/mantis/CR7488.md @@ -0,0 +1,255 @@ + + + + + + + + + + + + + 0007488: incorrect examples in annex B - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007488Part 01: TTCN-3 Core LanguageEditorialpublic12-08-2016 08:5012-12-2016 13:31
ReporterKristóf Szabados 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.8.1 (published 2016-07) 
Target Versionv4.9.1 (published 2017-05)Fixed in Versionv4.9.1 (published 2017-05) 
Clause Reference(s)B.1.2.6
Source (company - Author)L.M. Ericsson
Summary0007488: incorrect examples in annex B
Description1)
+Section B.1.2.6 has the following example:
+"
+template MySetOfType mw_myTemplate7 := superset (1, 2, ?) length (7 .. infinity);
+    // matches any sequence of at least 7 integers which contains at least one occurrences of the
+    // numbers 1, 2 and 3 in any order and position
+"
+
+Incorrect: the value 3 is not required to be present for the template to match.
+It would be better to write "matches any sequence of at least 7 integer which contains at least one occurrences of the number 1,2 and at least 5 more valid integer values (i.e. between 0 and 10, inclusively) in any order and position"
+
+2)
+B.1.3.2.0 has the following example:
+"
+var charstring v_myStrings[4];
+    myPCO.receive(v_myStrings:{"abyz", *, "abc" });
+"
+
+"abc" should be changed to "abcd" to be 4 characters long, as the type requires.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0007487closed Gyorgy Rethy inconsistent examples and naming in Annex B 
Attached Filesdocx CR7488_resolution_v1.docx (147,384) 16-08-2016 09:22
http://oldforge.etsi.org/mantis/file_download.php?file_id=3451&type=bug
Issue History
Date ModifiedUsernameFieldChange
12-08-2016 08:50Kristóf SzabadosNew Issue
12-08-2016 12:04Jacob Wieland - SpirentNote Added: 0014052
12-08-2016 12:43Kristóf SzabadosNote Added: 0014054
15-08-2016 09:51Jens GrabowskiAssigned To => Axel Rennoch
15-08-2016 09:51Jens GrabowskiStatusnew => assigned
16-08-2016 09:22Axel RennochFile Added: CR7488_resolution_v1.docx
16-08-2016 09:24Axel RennochNote Added: 0014088
16-08-2016 09:30Axel RennochNote Added: 0014093
16-08-2016 09:30Axel RennochAssigned ToAxel Rennoch => Kristóf Szabados
16-08-2016 09:30Axel RennochStatusassigned => acknowledged
16-08-2016 10:02Jacob Wieland - SpirentRelationship addedrelated to 0007487
16-08-2016 10:14Kristóf SzabadosNote Added: 0014098
16-08-2016 10:14Kristóf SzabadosStatusacknowledged => resolved
16-08-2016 10:14Kristóf SzabadosFixed in Version => v4.8.1 (published 2016-07)
16-08-2016 10:14Kristóf SzabadosResolutionopen => fixed
16-08-2016 10:14Kristóf SzabadosAssigned ToKristóf Szabados => Gyorgy Rethy
17-08-2016 10:56Jacob Wieland - SpirentStatusresolved => feedback
17-08-2016 10:56Jacob Wieland - SpirentResolutionfixed => reopened
17-08-2016 10:57Jacob Wieland - SpirentStatusfeedback => resolved
17-08-2016 10:57Jacob Wieland - SpirentFixed in Versionv4.8.1 (published 2016-07) => v4.9.1 (published 2017-05)
17-08-2016 10:57Jacob Wieland - SpirentResolutionreopened => fixed
17-08-2016 10:57Jacob Wieland - SpirentStatusresolved => feedback
17-08-2016 10:57Jacob Wieland - SpirentResolutionfixed => reopened
17-08-2016 10:58Jacob Wieland - SpirentTarget Version => v4.9.1 (published 2017-05)
17-08-2016 10:58Jacob Wieland - SpirentStatusfeedback => resolved
17-08-2016 10:58Jacob Wieland - SpirentResolutionreopened => fixed
12-12-2016 13:31Gyorgy RethyNote Added: 0014382
12-12-2016 13:31Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014052) +
+ Jacob Wieland - Spirent    +
+ 12-08-2016 12:04    +
+ 		+ + + + +
+ The only thing wrong in the second example is the 'var' keyword which should be 'type' instead (as is apparent from its usage in an inline-template as the type).
+
+Then v_myStrings (which should probably be renamed) describes the type of 4-element-charstring arrays, i.e all arrays that contain 4 charstrings.
+
+
+
+ + + + + + + + + + +
+ (0014054) +
+ Kristóf Szabados    +
+ 12-08-2016 12:43    +
+ 		+ + + + +
+ "var" is truly a problem.
+
+Why is "abc" 4 characters long ... or needed in this example?
+
+
+
+ + + + + + + + + + +
+ (0014088) +
+ Axel Rennoch    +
+ 16-08-2016 09:24    +
+ 		+ + + + +
+ This CR has been covered by 7487, too.
+
+
+
+ + + + + + + + + + +
+ (0014093) +
+ Axel Rennoch    +
+ 16-08-2016 09:30    +
+ 		+ + + + +
+ This CR is covered by 7487.
+
+
+
+ + + + + + + + + + +
+ (0014098) +
+ Kristóf Szabados    +
+ 16-08-2016 10:14    +
+ 		+ + + + +
+ resolved in CR0007487
+
+
+
+ + + + + + + + + + +
+ (0014382) +
+ Gyorgy Rethy    +
+ 12-12-2016 13:31    +
+ 		+ + + + +
+ Implemented in CR 7271
+
+ + diff --git a/docs/mantis/CR7489.md b/docs/mantis/CR7489.md new file mode 100644 index 0000000000000000000000000000000000000000..7dbe55f10803c77aca6aa48fbdf1f3981c941cc3 --- /dev/null +++ b/docs/mantis/CR7489.md @@ -0,0 +1,218 @@ + + + + + + + + + + + + + 0007489: what does a permutation with repeating elements match on? - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007489Part 01: TTCN-3 Core LanguageClarificationpublic12-08-2016 08:5712-12-2016 10:50
ReporterKristóf Szabados 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.8.1 (published 2016-07) 
Target Versionv4.9.1 (published 2017-05)Fixed in Versionv4.9.1 (published 2017-05) 
Clause Reference(s)B.1.3.3
Source (company - Author)L. M. Ericsson
Summary0007489: what does a permutation with repeating elements match on?
Description1)
+In Annex B.1.3.3 there is no direct example to show what a permutation with repeating elements matches on.
+For example: permutation(1,1,2)
+
+2)
+The example
+"
+template integer mw_myInt1 := (1,2,3);
+...
+template MySequenceOfType mw_myTemplate10 := { permutation (mw_myInt1, 2, 3 ), 5 };
+    // matches any of the sequences of 4 integers:
+    // 1,3,2,5; 2,1,3,5; 2,3,1,5; 3,1,2,5; or 3,2,1,5;
+    // 2,3,2,5; 2,2,3,5; 2,3,2,5; 3,2,2,5; or 3,2,2,5;
+    // 3,3,2,5; 2,3,3,5; 2,3,3,5; 3,3,2,5; or 3,2,3,5;
+"
+is incorrect: if the permutation is applied to 5 values it should match to a sequence of 5 integers.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7489.docx (154,830) 16-08-2016 10:24
http://oldforge.etsi.org/mantis/file_download.php?file_id=3457&type=bug
Issue History
Date ModifiedUsernameFieldChange
12-08-2016 08:57Kristóf SzabadosNew Issue
12-08-2016 11:51Jacob Wieland - SpirentNote Added: 0014051
12-08-2016 12:42Kristóf SzabadosNote Added: 0014053
15-08-2016 09:52Jens GrabowskiAssigned To => Jacob Wieland - Spirent
15-08-2016 09:52Jens GrabowskiStatusnew => assigned
16-08-2016 10:24Jacob Wieland - SpirentFile Added: CR7489.docx
16-08-2016 10:25Jacob Wieland - SpirentNote Added: 0014100
16-08-2016 10:25Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Kristóf Szabados
16-08-2016 10:25Jacob Wieland - SpirentStatusassigned => confirmed
16-08-2016 11:45Kristóf SzabadosNote Added: 0014104
16-08-2016 11:45Kristóf SzabadosStatusconfirmed => resolved
16-08-2016 11:45Kristóf SzabadosFixed in Version => v4.8.1 (published 2016-07)
16-08-2016 11:45Kristóf SzabadosResolutionopen => fixed
16-08-2016 11:45Kristóf SzabadosAssigned ToKristóf Szabados => Gyorgy Rethy
17-08-2016 10:55Jacob Wieland - SpirentStatusresolved => feedback
17-08-2016 10:55Jacob Wieland - SpirentResolutionfixed => reopened
17-08-2016 10:55Jacob Wieland - SpirentFixed in Versionv4.8.1 (published 2016-07) => v4.9.1 (published 2017-05)
17-08-2016 10:55Jacob Wieland - SpirentTarget Version => v4.9.1 (published 2017-05)
17-08-2016 10:55Jacob Wieland - SpirentStatusfeedback => resolved
17-08-2016 10:55Jacob Wieland - SpirentResolutionreopened => fixed
12-12-2016 10:50Gyorgy RethyNote Added: 0014377
12-12-2016 10:50Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014051) +
+ Jacob Wieland - Spirent    +
+ 12-08-2016 11:51    +
+ 		+ + + + +
+ A permutation match is like a bag-subset-test. Each matching-mechanism (apart from *) inside the permutation-list must match one corresponding value-element and there must be a possible bijective mapping from matching-mechanisms to values, (i.e. if a matching mechanism matches on multiple values in the list of values to be matched by the permutation, one of those values needs to be chosen).
+
+In the example, a ValueList match (1,2,3) is used as a matching mechanism inside of the permutation. That is why the permutation alone matches only 3 values, followed by a 5, so the example is correct, in my opinion.
+
+
+
+ + + + + + + + + + +
+ (0014053) +
+ Kristóf Szabados    +
+ 12-08-2016 12:42    +
+ 		+ + + + +
+ You are right, I misread the second example.
+
+The first case should still be shown in an example.
+
+
+
+ + + + + + + + + + +
+ (0014100) +
+ Jacob Wieland - Spirent    +
+ 16-08-2016 10:25    +
+ 		+ + + + +
+ please review
+
+
+
+ + + + + + + + + + +
+ (0014104) +
+ Kristóf Szabados    +
+ 16-08-2016 11:45    +
+ 		+ + + + +
+ Looks good to me.
+
+
+
+ + + + + + + + + + +
+ (0014377) +
+ Gyorgy Rethy    +
+ 12-12-2016 10:50    +
+ 		+ + + + +
+ Added to draft V4.8.2
+
+ + diff --git a/docs/mantis/CR7490.md b/docs/mantis/CR7490.md new file mode 100644 index 0000000000000000000000000000000000000000..2fb5ac74a8254b9877934b78230b230f741ac9ec --- /dev/null +++ b/docs/mantis/CR7490.md @@ -0,0 +1,139 @@ + + + + + + + + + + + + + 0007490: confusing example - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007490Part 01: TTCN-3 Core LanguageEditorialpublic12-08-2016 09:2512-12-2016 13:59
ReporterKristóf Szabados 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.8.1 (published 2016-07) 
Target Versionv4.9.1 (published 2017-05)Fixed in Versionv4.9.1 (published 2017-05) 
Clause Reference(s)C.2.2
Source (company - Author)L. M. Ericsson
Summary0007490: confusing example
DescriptionIn section C.2.2 there is a confusing example:
+"
+template S mw_s3 := ({ f1 := 1, f2 := omit, f3 := "ABC" }, { f1 := 2, f3 := omit, f2 := '1'B })
+...
+sizeof(mw_s3) // returns 2
+"
+
+The example does not make it clear that the size of the structure is because each template in the list has 2 actual elements, or because he list itself has 2 elements.
+For didactic reasons it would be better to add a third element to the list, also having 2 actual elements.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7490_resolution_v1.docx (79,655) 16-08-2016 09:48
http://oldforge.etsi.org/mantis/file_download.php?file_id=3454&type=bug
Issue History
Date ModifiedUsernameFieldChange
12-08-2016 09:25Kristóf SzabadosNew Issue
15-08-2016 09:52Jens GrabowskiAssigned To => Axel Rennoch
15-08-2016 09:52Jens GrabowskiStatusnew => assigned
16-08-2016 09:48Axel RennochFile Added: CR7490_resolution_v1.docx
16-08-2016 09:49Axel RennochNote Added: 0014094
16-08-2016 09:49Axel RennochAssigned ToAxel Rennoch => Kristóf Szabados
16-08-2016 09:49Axel RennochStatusassigned => acknowledged
16-08-2016 10:20Kristóf SzabadosNote Added: 0014099
16-08-2016 10:20Kristóf SzabadosStatusacknowledged => resolved
16-08-2016 10:20Kristóf SzabadosFixed in Version => v4.8.1 (published 2016-07)
16-08-2016 10:20Kristóf SzabadosResolutionopen => fixed
16-08-2016 10:20Kristóf SzabadosAssigned ToKristóf Szabados => Gyorgy Rethy
17-08-2016 10:56Jacob Wieland - SpirentStatusresolved => feedback
17-08-2016 10:56Jacob Wieland - SpirentResolutionfixed => reopened
17-08-2016 10:56Jacob Wieland - SpirentStatusfeedback => resolved
17-08-2016 10:56Jacob Wieland - SpirentFixed in Versionv4.8.1 (published 2016-07) => v4.9.1 (published 2017-05)
17-08-2016 10:56Jacob Wieland - SpirentResolutionreopened => fixed
17-08-2016 10:59Jacob Wieland - SpirentStatusresolved => feedback
17-08-2016 10:59Jacob Wieland - SpirentResolutionfixed => reopened
17-08-2016 10:59Jacob Wieland - SpirentTarget Version => v4.9.1 (published 2017-05)
17-08-2016 11:00Jacob Wieland - SpirentStatusfeedback => resolved
17-08-2016 11:00Jacob Wieland - SpirentResolutionreopened => fixed
12-12-2016 13:59Gyorgy RethyNote Added: 0014387
12-12-2016 13:59Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014094) +
+ Axel Rennoch    +
+ 16-08-2016 09:49    +
+ 		+ + + + +
+ Please check and confirm the proposed resolution.
+
+
+
+ + + + + + + + + + +
+ (0014099) +
+ Kristóf Szabados    +
+ 16-08-2016 10:20    +
+ 		+ + + + +
+ The proposed resolution looks fine by me.
+
+
+
+ + + + + + + + + + +
+ (0014387) +
+ Gyorgy Rethy    +
+ 12-12-2016 13:59    +
+ 		+ + + + +
+ Added to draft V4.8.2
+
+ + diff --git a/docs/mantis/CR7491.md b/docs/mantis/CR7491.md new file mode 100644 index 0000000000000000000000000000000000000000..4f872227b8d12eb2f2e03183d51c2e722db1ccb1 --- /dev/null +++ b/docs/mantis/CR7491.md @@ -0,0 +1,153 @@ + + + + + + + + + + + + + 0007491: confusing/incorrect texts related to anytype behaviour - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007491Part 01: TTCN-3 Core LanguageClarificationpublic16-08-2016 09:0809-07-2017 12:12
ReporterKristóf Szabados 
Assigned ToKristóf Szabados 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionno change required 
PlatformOSOS Version
Product Versionv4.8.1 (published 2016-07) 
Target Versionv4.10.1 (published 2018-05)Fixed in Versionv4.10.1 (published 2018-05) 
Clause Reference(s)6.2.6
Source (company - Author)L. M. Ericsson
Summary0007491: confusing/incorrect texts related to anytype behaviour
DescriptionRecently the anytype type became global.
+But the text describing it was not changed in every place, or leaves room for interpretation.
+
+Anytype is global here:". the anytype shall comprise all the known data types but not the port, component, and default types"
+
+Here it is local: "The anytype is defined locally for each module"
+
+This just makes no sense in this context: "The address type shall be included if it has been explicitly defined within that module"
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7491_proposal_v1.docx (155,422) 16-08-2016 09:57
http://oldforge.etsi.org/mantis/file_download.php?file_id=3455&type=bug
Issue History
Date ModifiedUsernameFieldChange
16-08-2016 09:08Kristóf SzabadosNew Issue
16-08-2016 09:57Kristóf SzabadosFile Added: CR7491_proposal_v1.docx
16-08-2016 11:47Jens GrabowskiAssigned To => Axel Rennoch
16-08-2016 11:47Jens GrabowskiStatusnew => assigned
16-08-2016 13:35Axel RennochNote Added: 0014108
16-08-2016 13:35Axel RennochAssigned ToAxel Rennoch => Gyorgy Rethy
16-08-2016 13:35Axel RennochStatusassigned => confirmed
17-08-2016 11:39Jacob Wieland - SpirentTarget Version => v4.9.1 (published 2017-05)
13-12-2016 11:54Gyorgy RethyNote Added: 0014405
13-12-2016 11:54Gyorgy RethyAssigned ToGyorgy Rethy => Kristóf Szabados
13-12-2016 11:54Gyorgy RethyStatusconfirmed => assigned
13-12-2016 11:54Gyorgy RethyFixed in Version => v4.10.1 (published 2018-05)
13-12-2016 11:58Gyorgy RethyNote Edited: 0014405bug_revision_view_page.php?bugnote_id=14405#r346
24-12-2016 14:57Jens GrabowskiTarget Versionv4.9.1 (published 2017-05) => v4.10.1 (published 2018-05)
09-07-2017 12:12Kristóf SzabadosNote Added: 0014728
09-07-2017 12:12Kristóf SzabadosStatusassigned => closed
09-07-2017 12:12Kristóf SzabadosResolutionopen => no change required
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014108) +
+ Axel Rennoch    +
+ 16-08-2016 13:35    +
+ 		+ + + + +
+ The proposed text looks correct and the CR may be closed.
+
+
+
+ + + + + + + + + + +
+ (0014405) +
+ Gyorgy Rethy    +
+ 13-12-2016 11:54    +
(edited on: 13-12-2016 11:58)
+ 		+ + + + +
+ Currently, anytype is not defined to be a global type and there is no remark in the CR that the STF has decided to change this. If implementing, this CR would re-define the anytype, thus it is not implemented in the draft for the next version V4.9.1.
+
+The current definition is:
+In clause 6.2.6 The anytype:
+"The special type anytype is defined as a shorthand for the union of all known data types and the address type in a TTCN 3 module. The definition of the term known types is given in clause 3.1, i.e. the anytype shall comprise all the known data types but not the port, component, and default types. The address type shall be included if it has been explicitly defined within that module."
+In clause 3.1:
+"known types: set of all TTCN 3 predefined types, types defined in a TTCN 3 module and types imported into that module from other TTCN 3 modules or from non-TTCN 3 modules."
+
+Therefore anytype contains only the
+- locally defined data types
+- locally defined address type
+- imported (by an explicit import statement) data types
+
+Introductory text in clause 6.0 is corrected. Please check if any further correction is needed or the CR can be closed.
+
+
+
+
+
+ + + + + + + + + + +
+ (0014728) +
+ Kristóf Szabados    +
+ 09-07-2017 12:12    +
+ 		+ + + + +
+ was a misunderstanding on my side. The text is correct.
+
+ + diff --git a/docs/mantis/CR7492.md b/docs/mantis/CR7492.md new file mode 100644 index 0000000000000000000000000000000000000000..5937f932abfaa2159250b5bec90f8d2697898faf --- /dev/null +++ b/docs/mantis/CR7492.md @@ -0,0 +1,280 @@ + + + + + + + + + + + + + 0007492: duplication and ambiguity concerning actual par lists in BNF - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007492Part 01: TTCN-3 Core LanguageEditorialpublic16-08-2016 12:0616-12-2016 18:12
ReporterJacob Wieland - Spirent 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.9.1 (published 2017-05)Fixed in Versionv4.9.1 (published 2017-05) 
Clause Reference(s)A.1
Source (company - Author)Spirent - Jacob Wieland
Summary0007492: duplication and ambiguity concerning actual par lists in BNF
DescriptionTemplateActualParList and TestcaseActualParList have the same right-hand-side, so they can be unified to a single rule.
+
+Also FunctionActualParList which refers to FunctionActualPar could be also unified with TemplateActualParList because FunctionActualPar describes the same language as TemplateActualPar.
+
+In FunctionActualPar, there are two branches which are already subsumed by TemplateInstance: ArrayIdentifierRef via Value and and ComponentRef via OpCall. Therefore, these additional branches can be removed. Then, FunctionActualPar is the same as TemplateActualPar and therefore, FunctionActualParList can be replaced by TemplateActualParList.
+
+I propose to unify them and just drop the specific prefixes (Template/Testcase/Function) from the Nonterminals.
+
+Also, it needs to be checked whether the language packages which potentially reference these rules might also have to be changed.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0007472closed Gyorgy Rethy Part 01: TTCN-3 Core Language mixed parameter-style lists should be allowed 
related to 0007508closed Gyorgy Rethy Part 01: TTCN-3 Core Language some corrections in BNF (section A.1) 
related to 0007526closed Jens Grabowski Ext Pack: Config & Deployment Support (ES 202 781) BNF correction following update in core BNF 
related to 0007528closed Gyorgy Rethy Ext Pack: Behaviour Types (ES 202 785) BNF correction following update in core BNF 
related to 0007527closed Gyorgy Rethy Ext Pack: Advanced Parametrization (ES 202 784) BNF correction following update in core BNF 
related to 0007529closed Jens Grabowski Ext Pack: Continuous signal support (ES 202 786) BNF correction following update in core BNF 
Attached Filesdocx CR7492_resolution_v1.docx (59,373) 15-11-2016 09:58
http://oldforge.etsi.org/mantis/file_download.php?file_id=3516&type=bug
docx CR7492_resolution_v2.docx (76,435) 15-11-2016 10:20
http://oldforge.etsi.org/mantis/file_download.php?file_id=3518&type=bug
docx CR7492_resolution_v3.docx (67,922) 17-11-2016 11:36
http://oldforge.etsi.org/mantis/file_download.php?file_id=3553&type=bug
Issue History
Date ModifiedUsernameFieldChange
16-08-2016 12:06Jacob Wieland - SpirentNew Issue
16-08-2016 12:07Jacob Wieland - SpirentRelationship addedrelated to 0007472
16-08-2016 12:50Jens GrabowskiAssigned To => Axel Rennoch
16-08-2016 12:50Jens GrabowskiStatusnew => assigned
17-08-2016 11:19Jacob Wieland - SpirentProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
17-08-2016 11:19Jacob Wieland - SpirentTarget Version => v4.9.1 (published 2017-05)
15-11-2016 09:58Axel RennochFile Added: CR7492_resolution_v1.docx
15-11-2016 10:00Axel RennochNote Added: 0014236
15-11-2016 10:02Axel RennochAssigned ToAxel Rennoch => Jacob Wieland - Spirent
15-11-2016 10:04Axel RennochNote Added: 0014238
15-11-2016 10:04Axel RennochStatusassigned => confirmed
15-11-2016 10:08Axel RennochRelationship addedrelated to 0007508
15-11-2016 10:20Axel RennochFile Added: CR7492_resolution_v2.docx
15-11-2016 10:20Axel RennochNote Added: 0014242
15-11-2016 10:21Axel RennochAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
15-11-2016 10:21Axel RennochStatusconfirmed => assigned
15-11-2016 10:21Axel RennochNote Added: 0014243
15-11-2016 10:21Axel RennochStatusassigned => resolved
15-11-2016 10:21Axel RennochResolutionopen => fixed
17-11-2016 11:35Axel RennochAssigned ToGyorgy Rethy => Axel Rennoch
17-11-2016 11:35Axel RennochNote Added: 0014298
17-11-2016 11:35Axel RennochStatusresolved => feedback
17-11-2016 11:35Axel RennochResolutionfixed => reopened
17-11-2016 11:36Axel RennochFile Added: CR7492_resolution_v3.docx
17-11-2016 11:36Axel RennochNote Added: 0014299
17-11-2016 11:37Axel RennochAssigned ToAxel Rennoch => Gyorgy Rethy
17-11-2016 11:37Axel RennochStatusfeedback => assigned
17-11-2016 11:37Axel RennochStatusassigned => resolved
17-11-2016 11:37Axel RennochResolutionreopened => fixed
17-11-2016 11:37Axel RennochRelationship addedrelated to 0007526
17-11-2016 11:38Axel RennochRelationship addedrelated to 0007528
17-11-2016 11:38Axel RennochRelationship addedrelated to 0007527
17-11-2016 11:38Axel RennochRelationship addedrelated to 0007529
16-12-2016 18:12Gyorgy RethyNote Added: 0014446
16-12-2016 18:12Gyorgy RethyStatusresolved => closed
16-12-2016 18:12Gyorgy RethyFixed in Version => v4.9.1 (published 2017-05)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014236) +
+ Axel Rennoch    +
+ 15-11-2016 10:00    +
+ 		+ + + + +
+ Modified syntax checked with BNF tool from Göttingen.
+Modifications due to CR7472 have been considered in line 150.
+
+TODO: remove deleted lines and renumber!
+
+
+
+ + + + + + + + + + +
+ (0014238) +
+ Axel Rennoch    +
+ 15-11-2016 10:04    +
+ 		+ + + + +
+ modifications due to CR7492 and CR7472 considered and implemented in the attachment
+
+
+
+ + + + + + + + + + +
+ (0014242) +
+ Axel Rennoch    +
+ 15-11-2016 10:20    +
+ 		+ + + + +
+ simplification of rule 150 by Jacob
+
+
+
+ + + + + + + + + + +
+ (0014243) +
+ Axel Rennoch    +
+ 15-11-2016 10:21    +
+ 		+ + + + +
+ CR has been checked by Jacob and and BNF can be used for the target version
+
+
+
+ + + + + + + + + + +
+ (0014298) +
+ Axel Rennoch    +
+ 17-11-2016 11:35    +
+ 		+ + + + +
+ renumbering of rules required
+
+
+
+ + + + + + + + + + +
+ (0014299) +
+ Axel Rennoch    +
+ 17-11-2016 11:36    +
+ 		+ + + + +
+ unused rule removed, update of all rule numbers
+
+
+
+ + + + + + + + + + +
+ (0014446) +
+ Gyorgy Rethy    +
+ 16-12-2016 18:12    +
+ 		+ + + + +
+ Implemented in draft V4.8.3.
+
+ArrayIdentifierRefAssignment is also deleted, as after the changes is not used by any other production.
+
+ + diff --git a/docs/mantis/CR7493.md b/docs/mantis/CR7493.md new file mode 100644 index 0000000000000000000000000000000000000000..20dc02933a387692a317761647e2700a6c86c7ef --- /dev/null +++ b/docs/mantis/CR7493.md @@ -0,0 +1,808 @@ + + + + + + + + + + + + + 0007493: Add Wrapper-Union capability to the standard - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007493Part 01: TTCN-3 Core LanguageNew Featurepublic16-08-2016 16:3212-12-2016 20:22
ReporterJacob Wieland - Spirent 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.9.1 (published 2017-05)Fixed in Versionv4.9.1 (published 2017-05) 
Clause Reference(s)6.2.5, 6.3.2.4, A.1.5.0
Source (company - Author)Spirent - Jacob Wieland
Summary0007493: Add Wrapper-Union capability to the standard
DescriptionCR 7421 can be resolved if a special union modifier is introduced which adds type compatibility between union types and the type of one of their alternatives which is declared with this modifier.
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0007421closed Gyorgy Rethy Part 09: Using XML with TTCN-3 How to achieve full backward compatibility in case of element- and/or type-substitution 
Attached Filesdocx CR7493.docx (172,624) 17-08-2016 10:01
http://oldforge.etsi.org/mantis/file_download.php?file_id=3467&type=bug
docx CR7493v2.docx (175,366) 19-08-2016 11:35
http://oldforge.etsi.org/mantis/file_download.php?file_id=3497&type=bug
docx CR7493v3.docx (178,269) 11-09-2016 17:13
http://oldforge.etsi.org/mantis/file_download.php?file_id=3509&type=bug
docx CR7493v4.docx (178,732) 19-10-2016 14:47
http://oldforge.etsi.org/mantis/file_download.php?file_id=3512&type=bug
docx CR7493v5.docx (178,706) 15-11-2016 10:03
http://oldforge.etsi.org/mantis/file_download.php?file_id=3517&type=bug
docx CR7493v6.docx (207,265) 15-11-2016 15:15
http://oldforge.etsi.org/mantis/file_download.php?file_id=3524&type=bug
Issue History
Date ModifiedUsernameFieldChange
16-08-2016 16:32Jacob Wieland - SpirentNew Issue
16-08-2016 16:32Jacob Wieland - SpirentRelationship addedrelated to 0007421
16-08-2016 16:33Jacob Wieland - SpirentAssigned To => Jacob Wieland - Spirent
16-08-2016 16:33Jacob Wieland - SpirentStatusnew => assigned
17-08-2016 10:01Jacob Wieland - SpirentFile Added: CR7493.docx
17-08-2016 10:02Jacob Wieland - SpirentNote Added: 0014122
17-08-2016 10:02Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Tomas Urban
17-08-2016 10:02Jacob Wieland - SpirentStatusassigned => confirmed
17-08-2016 10:47Tomas UrbanNote Added: 0014127
17-08-2016 10:47Tomas UrbanStatusconfirmed => closed
17-08-2016 10:47Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
17-08-2016 10:47Tomas UrbanResolutionopen => fixed
17-08-2016 10:47Tomas UrbanAssigned ToGyorgy Rethy => Tomas Urban
17-08-2016 10:47Tomas UrbanStatusclosed => feedback
17-08-2016 10:47Tomas UrbanResolutionfixed => reopened
17-08-2016 10:48Tomas UrbanStatusfeedback => resolved
17-08-2016 10:48Tomas UrbanResolutionreopened => fixed
17-08-2016 10:48Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
17-08-2016 11:10Jacob Wieland - SpirentProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
17-08-2016 11:11Jacob Wieland - SpirentStatusresolved => feedback
17-08-2016 11:11Jacob Wieland - SpirentResolutionfixed => reopened
17-08-2016 11:11Jacob Wieland - SpirentTarget Version => v4.9.1 (published 2017-05)
17-08-2016 11:11Jacob Wieland - SpirentStatusfeedback => resolved
17-08-2016 11:11Jacob Wieland - SpirentFixed in Version => v4.9.1 (published 2017-05)
17-08-2016 11:11Jacob Wieland - SpirentResolutionreopened => fixed
19-08-2016 08:31Gyorgy RethyNote Added: 0014163
19-08-2016 08:32Gyorgy RethyStatusresolved => feedback
19-08-2016 08:32Gyorgy RethyResolutionfixed => reopened
19-08-2016 08:32Gyorgy RethyAssigned ToGyorgy Rethy => Tomas Urban
19-08-2016 08:32Gyorgy RethyStatusfeedback => assigned
19-08-2016 08:32Gyorgy RethyAssigned ToTomas Urban => Jacob Wieland - Spirent
19-08-2016 08:33Gyorgy RethyNote Edited: 0014163bug_revision_view_page.php?bugnote_id=14163#r317
19-08-2016 08:34Gyorgy RethyNote Edited: 0014163bug_revision_view_page.php?bugnote_id=14163#r318
19-08-2016 08:43Gyorgy RethyNote Edited: 0014163bug_revision_view_page.php?bugnote_id=14163#r319
19-08-2016 11:35Jacob Wieland - SpirentFile Added: CR7493v2.docx
19-08-2016 11:38Jacob Wieland - SpirentNote Added: 0014176
19-08-2016 11:38Jacob Wieland - SpirentStatusassigned => resolved
19-08-2016 11:38Jacob Wieland - SpirentResolutionreopened => fixed
19-08-2016 11:38Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
06-09-2016 07:37Kristóf SzabadosNote Added: 0014200
10-09-2016 16:30Kristóf SzabadosAssigned ToGyorgy Rethy => Kristóf Szabados
10-09-2016 16:30Kristóf SzabadosNote Added: 0014204
10-09-2016 16:30Kristóf SzabadosStatusresolved => feedback
10-09-2016 16:30Kristóf SzabadosResolutionfixed => reopened
11-09-2016 17:13Kristóf SzabadosFile Added: CR7493v3.docx
11-09-2016 17:13Kristóf SzabadosAssigned ToKristóf Szabados => Jacob Wieland - Spirent
11-09-2016 17:13Kristóf SzabadosStatusfeedback => assigned
12-09-2016 10:49Jacob Wieland - SpirentNote Added: 0014205
12-09-2016 10:49Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Kristóf Szabados
12-09-2016 10:50Jacob Wieland - SpirentNote Added: 0014206
15-09-2016 07:24Kristóf SzabadosNote Added: 0014207
15-09-2016 09:28Jacob Wieland - SpirentNote Added: 0014208
25-09-2016 17:19Kristóf SzabadosNote Added: 0014210
26-09-2016 09:24Jacob Wieland - SpirentNote Added: 0014211
26-09-2016 09:44Jacob Wieland - SpirentNote Added: 0014214
28-09-2016 13:52Kristóf SzabadosNote Added: 0014215
29-09-2016 08:38Jacob Wieland - SpirentNote Added: 0014216
19-10-2016 14:47Kristóf SzabadosFile Added: CR7493v4.docx
19-10-2016 14:49Kristóf SzabadosNote Added: 0014220
14-11-2016 12:50Kristóf SzabadosAssigned ToKristóf Szabados => Jacob Wieland - Spirent
14-11-2016 12:50Kristóf SzabadosNote Added: 0014227
15-11-2016 10:03Jacob Wieland - SpirentFile Added: CR7493v5.docx
15-11-2016 10:04Jacob Wieland - SpirentNote Added: 0014239
15-11-2016 10:04Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Tomas Urban
15-11-2016 10:04Jacob Wieland - SpirentStatusassigned => confirmed
15-11-2016 15:15Tomas UrbanFile Added: CR7493v6.docx
15-11-2016 15:27Tomas UrbanNote Added: 0014252
15-11-2016 15:27Tomas UrbanStatusconfirmed => resolved
15-11-2016 15:27Tomas UrbanResolutionreopened => fixed
15-11-2016 15:27Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
12-12-2016 19:58Gyorgy RethyNote Added: 0014396
12-12-2016 20:12Gyorgy RethyNote Added: 0014397
12-12-2016 20:12Gyorgy RethyStatusresolved => closed
12-12-2016 20:22Gyorgy RethyNote Edited: 0014396bug_revision_view_page.php?bugnote_id=14396#r342
12-12-2016 20:22Gyorgy RethyNote Deleted: 0014397
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014122) +
+ Jacob Wieland - Spirent    +
+ 17-08-2016 10:02    +
+ 		+ + + + +
+ please review
+
+
+
+ + + + + + + + + + +
+ (0014127) +
+ Tomas Urban    +
+ 17-08-2016 10:47    +
+ 		+ + + + +
+ The proposed solution resolves the CR and it is ready to be included into the next version of the core language specification.
+
+
+
+ + + + + + + + + + +
+ (0014163) +
+ Gyorgy Rethy    +
+ 19-08-2016 08:31    +
(edited on: 19-08-2016 08:43)
+ 		+ + + + +
+ While the solution technically is fine, its explanation is not aligned with the definitin how union is defined in TTCN-3; we define union as a set of possible choices, and thus the meaning of the sentence "declared as wrapped by using the @wrapped modifier..." doesn't sound obvious. I would prefer "declared as the default choice when no altetnative is explicitly identified by using the @default modifier...".
+As you note in the example,
+v_age := 34; shall automatically select the choice "number" and thus is the same as writing v_age := { number := 34 };
+
+The meaning of @default is also more intuitive when seen in a union type declaration.
+
+
+
+
+
+ + + + + + + + + + +
+ (0014176) +
+ Jacob Wieland - Spirent    +
+ 19-08-2016 11:38    +
+ 		+ + + + +
+ STF discussion: accept Gyorgy's proposal using @default instead of @wrapped.
+
+I recoined the termini 'wrapped alternative' to 'default alternative' and 'wrapped union' to 'union with default alternative' and reformulated the text accordingly.
+
+Hopefully, this is now clearer.
+
+
+
+ + + + + + + + + + +
+ (0014200) +
+ Kristóf Szabados    +
+ 06-09-2016 07:37    +
+ 		+ + + + +
+ Am I correct that this also applies to expressions?
+
+Like:
+type union U1 {@default integer i};
+type union U2 {@default integer j, boolean b};
+var U1 v_var1 := 1;
+var U2 v_var2 := 2;
+var integer v_var3 := v_var1 + v_var2; // this should be correct since we are adding 2 integers (after the automatic unboxing).
+var bitstring v_var4 := v_var1 + "something"; // this should be an error since an integer can not be added to a characterstring (v_var1 is an integer after unboxing)
+
+
+
+ + + + + + + + + + +
+ (0014204) +
+ Kristóf Szabados    +
+ 10-09-2016 16:30    +
+ 		+ + + + +
+ Reopening: we should add some more examples for the interesting cases.
+
+
+
+ + + + + + + + + + +
+ (0014205) +
+ Jacob Wieland - Spirent    +
+ 12-09-2016 10:49    +
+ 		+ + + + +
+ I take issue with two of the additional examples:
+
+1)
+
+log(v_u4); // results in “true” instead of “{ b:=true}” logged,
+       // resolving to the long notation happens before parameter passing.
+
+It should be the other way around. v_u4 *is* equal to { b := true } and therefore, that is what is being logged. The shorthand was only used in the assignment.
+
+2)
+
+log(v_u32); // test case error as “v_u32” would be treated as v_u32.i,
+        // which is not the selected alternative
+
+This is in my opinion plainly wrong. v_u32 is a union and therefore, whatever alternative is chosen in the union, that one will be reflected when using it as rhs-expression or logging it. The implicit unwrapping only happens when necessary,i.e. when the demanded type is only compatible with the default alternative but not with the union. The log-statement has no such restrictions.
+This example could be changed to:
+
+log(integer:v_u32)
+
+There, the demanded type becomes integer and thus forces unwrapping. If the default alternative is not chosen, that would then lead to an error. If it is chosen, then only the unwrapped value would be logged, not the whole union.
+
+That means, this statement is equivalent to:
+
+log(integer:v_u32.i)
+
+
+
+ + + + + + + + + + +
+ (0014206) +
+ Jacob Wieland - Spirent    +
+ 12-09-2016 10:50    +
+ 		+ + + + +
+ also, there is a v_u5 in the comment which should probably v_u4, i.e. a typo
+
+
+
+ + + + + + + + + + +
+ (0014207) +
+ Kristóf Szabados    +
+ 15-09-2016 07:24    +
+ 		+ + + + +
+ Could go that way too.
+We just need to clarify, what happens when.
+
+Log is just a good example as it is a notoriously hard situation for it does not provide a context.
+Raising the question: is this really a short hand, or not, or just in some cases and not in others.
+Do we want the to apply the short-hand resolution before the expression is evaluated, or not.
+for example:
+- log(v_u32 + v_u32 + v_u32) is an integer because v_u32 is a shorthand for an integer (and if the other branch is selected this results in testcase error).
+- log(v_u32 + v_u32) ... still logs an integer as v_u32 is a shorthand for an integer ...
+- log (v_u32) ... is a union ... inspite of being an integer everywhere else?
+- log((v_u32)) ... is an integer because of the brackets?
+
+I believe we need to specify exactly when it is a shorthand and when it is not, otherwise it leaves too much room for interpretation ... and users will also not like if the code will work with unexpected types.
+
+
+
+ + + + + + + + + + +
+ (0014208) +
+ Jacob Wieland - Spirent    +
+ 15-09-2016 09:28    +
+ 		+ + + + +
+ I would say that in an operand-position which implies the type (or possible types) of the operand, it is a shorthand notation.
+
+In a context-less position, it is never a shorthand notation.
+
+Basically, it is only a shorthand notation whenever it cannot be used as the long value, i.e. either there is no context, then the long value is applicable, or there is a type-context that demands the union type itself, then it is the long version, otherwise, it is the unwrapped/short version in case that is compatible with the demanded type context.
+
+Since simple parantheses don't supply any additional type context, the statements log(x) and log((x)) are semantically the same and will both log the long version of x.
+
+Interesting are the comparison operators where you could get in very complex situations. Here, it is imperative to first check for compatible long-versions and, if they are not compatible, you need to check whether there is an unambiguous interpretation of a combination of long/short, short/long or short/short interpretations of the operands so that they can actually be compared, i.e. have a compatible root type.
+
+All this is implicitly already described by the type-compatibility rules and the operators that require them.
+
+
+
+ + + + + + + + + + +
+ (0014210) +
+ Kristóf Szabados    +
+ 25-09-2016 17:19    +
+ 		+ + + + +
+ Wouldn't it be more "KISS" compatible to simply say that it is everywhere a shorthand notation, also noting that actual implementation might optimize the unboxing-boxing when they can?
+
+That way:
+- the rules would be much simpler and general. The meaning of a reference (for example v_u32) would be the same irrespective of what happens to be the context, what happens to be the type of the formal parameter, etc...
+- there would be no need for new type compatibility. Since consistent unboxing-boxing does not need it (yet allows such implementation if that is safe and better performing).
+- implementation itself would also be simpler, since there is no complex logic needed to be checked based on context, types and type compatibilities.
+- when the time comes for debugging/maintenance, this would be one thing less to worry about: the same thing happens everywhere, while otherwise one would also need to check the context, usage and in case it is used in calling a function there would be no need to manually check the formal parameter list of the function (in the current for we have to mix and match the formal and actual parameters to understand where will the boxing/unboxing happen).
+
+Admittedly this would mean that resolving the shorthand notation comes first, before passing to the log statement, to make it work consistently everywhere.
+
+
+
+ + + + + + + + + + +
+ (0014211) +
+ Jacob Wieland - Spirent    +
+ 26-09-2016 09:24    +
+ 		+ + + + +
+ On the meta-level, I have no idea what "KISS"-compatibility means.
+
+Also, I'm sorry, but I don't understand what you are proposing here, so please read what I am writing next with that in mind.
+
+If a right-hand-side reference to a union variable v with a default alternative a is ALWAYS expanded to its long form v.a, then how am I supposed to access v.b? Same argument applies to the left-hand-side. If it is always first expanded, then how am I supposed to set a different alternative than a? If I wanted something that is always just the type of a, I would use that type instead of the union with default alternative.
+
+Also, it would be weird that a variable behaves differently in regard to wrapping, depending on what alternative is chosen. Logging a union variable should not fail if a non-default alternative is chosen in it.
+
+So, while your proposal might make the life of the implementer simpler (though I don't see yet, how), it will definitely make the life of the user very much harder as these unions cannot be used in the normal way that they are used to anymore, but behave totally differently.
+
+As the proposal is today, resolving where the short form is to be expanded can be done statically from type-information at compile-time, so the compiler will probably already replace all short-forms with their respective long-forms before generating code and no additional runtime-effort is needed at all.
+
+
+
+ + + + + + + + + + +
+ (0014214) +
+ Jacob Wieland - Spirent    +
+ 26-09-2016 09:44    +
+ 		+ + + + +
+ Now I have found out what the KISS-principle means and I think my proposal is very much on par with it.
+
+Basically, the rule is pretty straightforward and simple:
+ 
+A union with a default alternative behaves like every other union except in those places where the usage of that union would be a semantic error (under normal union rules), so these previous error-cases get a semantic meaning.
+And in those cases, the usage is only allowed if the usage of the default alternative would not be an error and then it is interpreted as a short-form of the unwrapped default alternative.
+
+The first part of this is to adhere to the "principle of least surprise". If a thing is defined as a union, that semantics should come first.
+The next is semantic robustness: code that worked with a union type without a default alternative will work the same way if one of the alternatives is later changed to be default.
+
+
+
+ + + + + + + + + + +
+ (0014215) +
+ Kristóf Szabados    +
+ 28-09-2016 13:52    +
+ 		+ + + + +
+ in the case of using variable v with a default alternative I meant that "v.a" and "v.b" would still be possible, but when there is only "v" as the whole reference it could be treated as "v.a". So it would always be possible to reach other alternatives and read/assign value to them.
+
+
+
+ + + + + + + + + + +
+ (0014216) +
+ Jacob Wieland - Spirent    +
+ 29-09-2016 08:38    +
+ 		+ + + + +
+ But that does not work in those cases where v is used in its capacity as a union value (i.e. assigned to a union variable, used as actual union parameter, compared with another union variable/constant, matched against union template, etc.).
+
+So, all these currently normal cases would suddenly become the exceptional cases while the few instances (log, receive, send statements) where no type is required would behave differently.
+
+Also, it would be weird that log(v) works differently in case that v.a is chosen than when v.b is chosen. If you replace the v with v.a at compile time, it would be an error, if actually b is chosen in v at runtime. Otherwise, you obviously have to not replace it at compile-time and do runtime-checking instead. The same applies for all other untyped places. I really don't see the simplicity in that.
+
+
+
+ + + + + + + + + + +
+ (0014220) +
+ Kristóf Szabados    +
+ 19-10-2016 14:49    +
+ 		+ + + + +
+ Yes, we could have some special treatment for this in log statements, when it is not used in an expression (that would force the unwrapping).
+
+
+
+ + + + + + + + + + +
+ (0014227) +
+ Kristóf Szabados    +
+ 14-11-2016 12:50    +
+ 		+ + + + +
+ please review
+
+
+
+ + + + + + + + + + +
+ (0014239) +
+ Jacob Wieland - Spirent    +
+ 15-11-2016 10:04    +
+ 		+ + + + +
+ changed 'shall' in NOTE 3 to 'will'.
+
+Otherwise, ok, please review and resolve.
+
+
+
+ + + + + + + + + + +
+ (0014252) +
+ Tomas Urban    +
+ 15-11-2016 15:27    +
+ 		+ + + + +
+ I reviewed the proposal an made one cosmetic correction. The proposal contains reasonable changes and can be added to the next version of the core language standard.
+
+
+
+ + + + + + + + + + +
+ (0014396) +
+ Gyorgy Rethy    +
+ 12-12-2016 19:58    +
(edited on: 12-12-2016 20:22)
+ 		+ + + + +
+ Added to V4.8.2.
+Note 2 of 6.3.2.4 is extracted to a mandatory text, as in fact it specifies a requirement (order of using the rules for compatibility checking).
+
+
+
+ + diff --git a/docs/mantis/CR7494.md b/docs/mantis/CR7494.md new file mode 100644 index 0000000000000000000000000000000000000000..94e92a9eb63992e2cefdb3f2079fa88588d4a07e --- /dev/null +++ b/docs/mantis/CR7494.md @@ -0,0 +1,97 @@ + + + + + + + + + + + + + 0007494: TRI and TCI extensions for advanced matching - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Advanced Matching (ES 203 022)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007494Ext Pack: Advanced Matching (ES 203 022)New Featurepublic18-08-2016 14:1824-12-2016 11:51
ReporterTomas Urban 
Assigned ToJens Grabowski 
PriorityhighSeveritymajorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv1.1.1 (published 2017-07) 
Target Versionv1.1.1 (published 2017-07)Fixed in Version 
Clause Reference(s)5
Source (company - Author)STF 514
TS version1.1.1
Summary0007494: TRI and TCI extensions for advanced matching
DescriptionThis is a joint CR for TCI and TRI changes required for the extension package
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0007167closed Jens Grabowski Matching mechanism to match multiple items in arrays, records and sets of single types 
related to 0007175closed Jens Grabowski No easy way to describe conjunction matching mechanism. 
related to 0007174closed Jens Grabowski New matching mechanism: matching by function 
Attached Filesdocx CR7494-1.docx (238,159) 17-11-2016 16:18
http://oldforge.etsi.org/mantis/file_download.php?file_id=3561&type=bug
docx CR7494-2.docx (198,072) 18-11-2016 10:43
http://oldforge.etsi.org/mantis/file_download.php?file_id=3568&type=bug
Issue History
Date ModifiedUsernameFieldChange
18-08-2016 14:18Tomas UrbanNew Issue
18-08-2016 14:18Tomas UrbanStatusnew => assigned
18-08-2016 14:18Tomas UrbanAssigned To => Tomas Urban
18-08-2016 15:24Tomas UrbanRelationship addedrelated to 0007174
16-11-2016 14:39Tomas UrbanRelationship addedrelated to 0007167
16-11-2016 14:39Tomas UrbanRelationship addedrelated to 0007175
17-11-2016 16:18Tomas UrbanFile Added: CR7494-1.docx
17-11-2016 16:19Tomas UrbanNote Added: 0014321
17-11-2016 16:19Tomas UrbanAssigned ToTomas Urban => Jacob Wieland - Spirent
17-11-2016 16:19Tomas UrbanStatusassigned => confirmed
18-11-2016 10:43Jacob Wieland - SpirentFile Added: CR7494-2.docx
18-11-2016 10:43Jacob Wieland - SpirentStatusconfirmed => assigned
18-11-2016 10:44Jacob Wieland - SpirentNote Added: 0014333
18-11-2016 10:44Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Jens Grabowski
18-11-2016 10:44Jacob Wieland - SpirentStatusassigned => confirmed
24-12-2016 11:51Jens GrabowskiStatusconfirmed => closed
24-12-2016 11:51Jens GrabowskiResolutionopen => fixed
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014321) +
+ Tomas Urban    +
+ 17-11-2016 16:19    +
+ 		+ + + + +
+ Resolution draft uploaded. Please check.
+
+
+
+ + + + + + + + + + +
+ (0014333) +
+ Jacob Wieland - Spirent    +
+ 18-11-2016 10:44    +
+ 		+ + + + +
+ I reviewed and fixed some typos, added missing definite articles and replaced some copy-paste errors
+
+ + diff --git a/docs/mantis/CR7495.md b/docs/mantis/CR7495.md new file mode 100644 index 0000000000000000000000000000000000000000..f452284708a58742a6df0c8c7517604a49c0cced --- /dev/null +++ b/docs/mantis/CR7495.md @@ -0,0 +1,553 @@ + + + + + + + + + + + + + 0007495: out, inout and return value should be assignable via the done/killed statement redirect - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007495Part 01: TTCN-3 Core LanguageNew Featurepublic22-08-2016 15:0904-01-2019 16:13
ReporterJacob Wieland - Spirent 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.8.1 (published 2016-07) 
Target Version4.11.1 (published 2019-05)Fixed in Version4.11.1 (published 2019-05) 
Clause Reference(s)21.3.2
Source (company - Author)Spirent - Jacob Wieland
Summary0007495: out, inout and return value should be assignable via the done/killed statement redirect
DescriptionAt the moment, it is allowed to start functions that have inout or out parameters or return clauses but the result of the computation for these parameters/the result cannot be accessed.
+
+The verdict of a component can already be assigned via redirect statement, so it should be feasible to extend that to also include possible value/param clauses to assign the values of out/inout parameters/the return value in a deterministic way back to their original parts.
+
+function f(out integer p_o, inout integer p_i) return integer {}
+
+ptc.start(f(v_o, v_i));
+ptc.done -> v_verdict value v_result param(v_o := p_o, v_i := p_i)
+
+or alternatively
+
+ptc.done -> v_verdict value v_result param(v_o, v_i);
+
+(the short form should be the list notation supplying for all out or inout parameters).
+
+The only open question is the semantics when a ptc is stopped during such a behavior. But here, I would say the end-result should be the values of the parameters at the time of the stop statement. If no assignment has taken place during the behavior, the original value is returned. In that way, the function would behave exactly as if called locally. The return value will be unbound if the behavior was stopped before the return statement was executed.
+
+This way, there would be no shared memory between components and it is clear when the variables are changed and by whom (i.e. only by the owning component), so no read-write conflicts can occur in that regard.
+
+If the connection between start and stop is too loose, the start statement could give back a handle (like activate) which could then be used by the done statement as reference.
+
+var behavior b := ptc.start(f(i,o));
+ptc.done(b) -> ...
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0007598closed Gyorgy Rethy Part 01: TTCN-3 Core Language Invalid restriction on formal template parameters 
related to 0007786closed Tomas Urban Part 06: TTCN-3 Control Interface TciCallparameterListType needed to implement component call operation 
Attached Filesdocx CR7495.docx (158,806) 27-10-2017 10:46
http://oldforge.etsi.org/mantis/file_download.php?file_id=3721&type=bug
docx CR7495-v2.docx (181,450) 27-10-2017 14:31
http://oldforge.etsi.org/mantis/file_download.php?file_id=3724&type=bug
docx CR7495-v3.docx (183,174) 19-07-2018 15:52
http://oldforge.etsi.org/mantis/file_download.php?file_id=3779&type=bug
Issue History
Date ModifiedUsernameFieldChange
22-08-2016 15:09Jacob Wieland - SpirentNew Issue
22-08-2016 15:09Jacob Wieland - SpirentStatusnew => assigned
22-08-2016 15:09Jacob Wieland - SpirentAssigned To => Jacob Wieland - Spirent
15-11-2016 10:30Jacob Wieland - SpirentNote Added: 0014245
15-11-2016 11:21Jacob Wieland - SpirentNote Added: 0014246
17-11-2016 13:53Jens GrabowskiNote Added: 0014306
17-11-2016 13:53Jens GrabowskiTarget Versionv4.9.1 (published 2017-05) => v4.10.1 (published 2018-05)
06-06-2017 11:44Jens GrabowskiRelationship addedrelated to 0007598
05-09-2017 09:49Jacob Wieland - SpirentNote Added: 0014813
26-10-2017 16:49Jacob Wieland - SpirentNote Added: 0014902
27-10-2017 08:56Jacob Wieland - SpirentNote Edited: 0014902bug_revision_view_page.php?bugnote_id=14902#r446
27-10-2017 10:46Jacob Wieland - SpirentFile Added: CR7495.docx
27-10-2017 10:47Jacob Wieland - SpirentNote Added: 0014908
27-10-2017 10:47Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Tomas Urban
27-10-2017 10:47Jacob Wieland - SpirentStatusassigned => confirmed
27-10-2017 14:31Tomas UrbanFile Added: CR7495-v2.docx
27-10-2017 14:32Tomas UrbanNote Added: 0014920
27-10-2017 14:32Tomas UrbanAssigned ToTomas Urban => Jacob Wieland - Spirent
01-11-2017 15:21Jacob Wieland - SpirentNote Added: 0014921
01-11-2017 15:21Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Tomas Urban
05-01-2018 13:30Gyorgy RethyTarget Versionv4.10.1 (published 2018-05) => 4.11.1 (published 2019-05)
11-01-2018 11:50Jacob Wieland - SpirentNote Added: 0015026
19-07-2018 15:52Tomas UrbanFile Added: CR7495-v3.docx
19-07-2018 15:53Tomas UrbanAssigned ToTomas Urban => Jacob Wieland - Spirent
19-07-2018 15:53Tomas UrbanStatusconfirmed => assigned
19-07-2018 15:57Tomas UrbanNote Added: 0015180
20-07-2018 09:10Jacob Wieland - SpirentNote Added: 0015186
20-07-2018 09:10Jacob Wieland - SpirentStatusassigned => resolved
20-07-2018 09:10Jacob Wieland - SpirentFixed in Version => 4.11.1 (published 2019-05)
20-07-2018 09:10Jacob Wieland - SpirentResolutionopen => fixed
20-07-2018 09:10Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Jens Grabowski
20-07-2018 09:20Jacob Wieland - SpirentAssigned ToJens Grabowski => Jacob Wieland - Spirent
20-07-2018 09:20Jacob Wieland - SpirentStatusresolved => feedback
20-07-2018 09:20Jacob Wieland - SpirentResolutionfixed => reopened
20-07-2018 09:20Jacob Wieland - SpirentStatusfeedback => resolved
20-07-2018 09:20Jacob Wieland - SpirentResolutionreopened => fixed
20-07-2018 09:20Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
09-10-2018 09:38Tomas UrbanRelationship addedrelated to 0007786
04-01-2019 16:13Gyorgy RethyNote Added: 0015295
04-01-2019 16:13Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014245) +
+ Jacob Wieland - Spirent    +
+ 15-11-2016 10:30    +
+ 		+ + + + +
+ to allow static analysis of the done statment, the syntax should be made even more explicit:
+
+var behavior := ptc.start(f(...));
+ptc.done(b,f) -> [verdict v_verdict] [value v_value] [param(...)]
+
+The f in the done statement could be any function reference (i.e. also a function variable).
+
+The static analysis would check the param list and value types against the signature of the given function reference. The runtime would check whether the behavior is an actual instance of that function reference. If these checks fail, it would be an error.
+
+
+
+ + + + + + + + + + +
+ (0014246) +
+ Jacob Wieland - Spirent    +
+ 15-11-2016 11:21    +
+ 		+ + + + +
+ @STF discussion:
+
+var behavior v_handle := ptc.start(f(...));
+v_handle.done(f:{p_out := ?, p_inout := ?} value ? @verdict value ?)
+-> value v_result
+   @verdict value v_verdict
+   param(v_out := p_out, v_inout := p_inout)
+
+or direct combination:
+
+ptc.start(f(...)).done(...) -> ...
+
+all the matching parts and all the redirect parts are optional, the only non-optional thing is the f:<template> to allow checking types of return and parameters against f.
+
+A simple case would be: v_handle.done(f:?) -> value v_result
+
+The statement only matches in case the function returns gracefully (i.e. by using a return statement or for non-returning functions, reaches the end of the function body. It does specifically not match if the component is stopped either from outside or from inside.
+
+
+
+ + + + + + + + + + +
+ (0014306) +
+ Jens Grabowski    +
+ 17-11-2016 13:53    +
+ 		+ + + + +
+ Shifted to 2017 version.
+
+
+
+ + + + + + + + + + +
+ (0014813) +
+ Jacob Wieland - Spirent    +
+ 05-09-2017 09:49    +
+ 		+ + + + +
+ Thinking more about this, I think I would prefer to augment the component-done statement with this functionality rather than invent a new type.
+
+In that way, you could also react on non-normal execution of the function (if functions are allowed to throw exceptions).
+
+Example:
+
+ptc.start(f(...);
+alt {
+[] ptc.done(f:?) -> value v_result verdict v_verdict param (v_out := p_out, v_inout := v_inout) {
+  ...
+}
+[] ptc.catch(f, e) { // function raised exception that matches template e
+... }
+[] ptc.done { //terminated with stop or kill
+}
+[] t.timeout { // timeout how long to wait for termination of f
+}
+
+Another way would be reusing the call-statement syntax of ptcs by augmenting the start statement with a call-body:
+
+ptc.start(f(...), 3.0) {
+[] ptc.getreply(...) { // case where f returns gracefully
+}
+[] ptc.catch(f, e) { // case where f throws an exception that matches e
+}
+[] ptc.done { ... // case where f returns in another way
+}
+[] ptc.catch(timeout) { ... // case where f does not return
+}
+
+So, this would basically be the same syntax like for <port>.call, but using a ptc instead of a port for the getreply and catch statements.
+
+In both cases, if you want to implement a blocking call, it would look simply like
+
+ptc.start(f(...));
+ptc.done(f:?) -> ...
+
+
+
+ + + + + + + + + + +
+ (0014902) +
+ Jacob Wieland - Spirent    +
+ 26-10-2017 16:49    +
(edited on: 27-10-2017 08:56)
+ 		+ + + + +
+ Simplified version:
+
+for a blocking call that waits indefinitely and optionally assigns the result and verdict:
+
+ptc.call(f(...)) -> value v_result verdict v_verdict;
+
+Robust version that can deal with timeout and exceptions thrown from f:
+
+ptc.call(f(...), t)
+-> value v_result verdict v_verdict
+catch (timeout) { ... }
+catch (exceptiontype:?) { ... }
+
+
+
+
+
+ + + + + + + + + + +
+ (0014908) +
+ Jacob Wieland - Spirent    +
+ 27-10-2017 10:47    +
+ 		+ + + + +
+ first proposal draft, please review
+
+I've left the exception handling part out by now because that is not part of the core language, yet
+
+
+
+ + + + + + + + + + +
+ (0014920) +
+ Tomas Urban    +
+ 27-10-2017 14:32    +
+ 		+ + + + +
+ I made several changes in the document (adding some missing parts and additional restrictions). Please check and if you are fine with it, please assign it to Jens so that he can take a look at the feature too.
+
+
+
+ + + + + + + + + + +
+ (0014921) +
+ Jacob Wieland - Spirent    +
+ 01-11-2017 15:21    +
+ 		+ + + + +
+ I don't fully agree with the change in restriction f as the result needs to be compatible with the variable and not the other way around (i.e. valueset(type of var) >= valueset(type of result) or more specifically result-value must be element of valueset(type of variable) or it is a testcase error).
+
+If you look at the definitions for compatibility it always argues from the point of view of the value to be assigned, not from the type it assigned to.
+
+All other changes are fine.
+
+
+
+ + + + + + + + + + +
+ (0015026) +
+ Jacob Wieland - Spirent    +
+ 11-01-2018 11:50    +
+ 		+ + + + +
+ While implementing this feature, I've run into a few problems on the TCI-level.
+
+Using the TCI functions
+
+tciStartTestComponentReq,
+tciStartTestComponent,
+tciTestComponentTerminatedReq,
+tciTestComponentTerminated
+
+there is no totally obvious way to propagate back the final values of the out/inout parameters (though that can be achieved internally by the CH implementation)
+
+and there is no good way to propagate back the result value.
+
+I propose to enhance TciParameterList with an additional function/method getResult() which returns the handle for result propagation and is shall return the value-target variable for calls.
+
+
+
+ + + + + + + + + + +
+ (0015180) +
+ Tomas Urban    +
+ 19-07-2018 15:57    +
+ 		+ + + + +
+ I changed the terminology a bit: (un)successful termination => (in)complete execution and added necessary explanation of these terms. There are also two new additional rules:
+1. Implicit stop of the behaviour in case of timeout
+2. No assignments in case of incomplete execution
+
+Please check.
+
+
+
+ + + + + + + + + + +
+ (0015186) +
+ Jacob Wieland - Spirent    +
+ 20-07-2018 09:10    +
+ 		+ + + + +
+ To me this looks fine and complete, so I set this to resolved.
+
+
+
+ + + + + + + + + + +
+ (0015295) +
+ Gyorgy Rethy    +
+ 04-01-2019 16:13    +
+ 		+ + + + +
+ Added to draft V4.10.2.
+
+ + diff --git a/docs/mantis/CR7496.md b/docs/mantis/CR7496.md new file mode 100644 index 0000000000000000000000000000000000000000..e876c630de50998eb4fa953f8dbc04d9aafd4f2d --- /dev/null +++ b/docs/mantis/CR7496.md @@ -0,0 +1,202 @@ + + + + + + + + + + + + + 0007496: Formal parameters and return values should also be declarable as arrays. - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007496Part 01: TTCN-3 Core LanguageNew Featurepublic01-09-2016 09:5830-12-2017 18:57
ReporterJacob Wieland - Spirent 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.9.1 (published 2017-05) 
Target Versionv4.10.1 (published 2018-05)Fixed in Versionv4.10.1 (published 2018-05) 
Clause Reference(s)5.4.1, 16.1
Source (company - Author)Spirent - Jacob Wieland
Summary0007496: Formal parameters and return values should also be declarable as arrays.
DescriptionAt the moment, it is not possible to pass an array variable as an actual parameter without having to additionally define the corresponding array type (and use that as the formal parameter type).
+
+This makes refactoring of code when such array variables are involved and need to be passed as parameter either impossible or forces the refactoring process to add such artificial array types (if they don't exist already).
+
+Example:
+
+function f() {
+  var ptcType ptcs[10];
+  var integer i;
+  for (i := 0; i < 10; i := i + 1) { // <--------
+    ptcs[i] = ptcType.create; // <--------
+  } // <--------
+  for (i := 0; i < 10; i := i + 1) {
+    ptcs[i].start(ptcBehavior());
+  }
+}
+
+When trying to refactor the first for-loop, one would imagine a function like this:
+
+function createPtcs(inout ptcType ptcs[10], inout integer i) {
+  for (i := 0; i < 10; i := i + 1) {
+    ptcs[i] = ptcType.create;
+  }
+}
+
+to preserve the same semantics.
+
+But, because it is not possible to declare the first variable as an array, it is necessary to do it like this:
+
+type ptcType ptcTypeArray[10];
+function createPtcs(inout ptcTypeArray ptcs, inout integer i) {
+  for (i := 0; i < 10; i := i + 1) {
+    ptcs[i] = ptcType.create;
+  }
+}
+
+The same, of course, is also true if the array is to be passed as return value, but here, it is a bit more tricky because the syntax of the Type Expression after the return keyword can already include a [-] for referencing an element type of a record-of type. Fortunately, the syntax [-] can be clearly distinguished from [<length>], even though it is a bit subtle.
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7496-v1.docx (360,164) 25-07-2017 12:49
http://oldforge.etsi.org/mantis/file_download.php?file_id=3652&type=bug
Issue History
Date ModifiedUsernameFieldChange
01-09-2016 09:58Jacob Wieland - SpirentNew Issue
14-11-2016 13:40Jens GrabowskiAssigned To => Tomas Urban
14-11-2016 13:40Jens GrabowskiStatusnew => assigned
17-11-2016 13:49Jens GrabowskiNote Added: 0014305
17-11-2016 13:49Jens GrabowskiTarget Versionv4.9.1 (published 2017-05) => v4.10.1 (published 2018-05)
25-07-2017 12:49Tomas UrbanFile Added: CR7496-v1.docx
25-07-2017 12:49Tomas UrbanNote Added: 0014750
25-07-2017 12:49Tomas UrbanAssigned ToTomas Urban => Jacob Wieland - Spirent
25-07-2017 12:49Tomas UrbanStatusassigned => confirmed
26-07-2017 09:40Jacob Wieland - SpirentNote Added: 0014775
26-07-2017 09:40Jacob Wieland - SpirentStatusconfirmed => resolved
26-07-2017 09:40Jacob Wieland - SpirentFixed in Version => v4.9.1 (published 2017-05)
26-07-2017 09:40Jacob Wieland - SpirentResolutionopen => fixed
26-07-2017 09:40Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
30-12-2017 18:57Gyorgy RethyNote Added: 0014964
30-12-2017 18:57Gyorgy RethyStatusresolved => closed
30-12-2017 18:57Gyorgy RethyProduct Version => v4.9.1 (published 2017-05)
30-12-2017 18:57Gyorgy RethyFixed in Versionv4.9.1 (published 2017-05) => v4.10.1 (published 2018-05)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014305) +
+ Jens Grabowski    +
+ 17-11-2016 13:49    +
+ 		+ + + + +
+ Resolution postponed to 2017 version.
+
+
+
+ + + + + + + + + + +
+ (0014750) +
+ Tomas Urban    +
+ 25-07-2017 12:49    +
+ 		+ + + + +
+ Resolution uploaded. Please check.
+
+
+
+ + + + + + + + + + +
+ (0014775) +
+ Jacob Wieland - Spirent    +
+ 26-07-2017 09:40    +
+ 		+ + + + +
+ fine with me
+
+
+
+ + + + + + + + + + +
+ (0014964) +
+ Gyorgy Rethy    +
+ 30-12-2017 18:57    +
+ 		+ + + + +
+ Implemented in draft V4.9.2
+
+ + diff --git a/docs/mantis/CR7497.md b/docs/mantis/CR7497.md new file mode 100644 index 0000000000000000000000000000000000000000..3713fb8fd8d0c9b0722e45f82ac3f23766d64a87 --- /dev/null +++ b/docs/mantis/CR7497.md @@ -0,0 +1,174 @@ + + + + + + + + + + + + + 0007497: Support for optional fields in RecordValue - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007497Part 06: TTCN-3 Control InterfaceNew Featurepublic12-09-2016 10:5821-12-2016 10:52
ReporterTomas Urban 
Assigned ToTomas Urban 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.9.1(ongoing) 
Target VersionFixed in Version 
Clause Reference(s)7.2.2.2.10
Source (company - Author)Elvior
Summary0007497: Support for optional fields in RecordValue
DescriptionThe current version of the RecordValue abstract data type doesn't allow to check whether a field is optional or not. Many clients expects that the TCI offers experience similar to reflection in java or C# and field optionality is one of the properties TCI doesn't provide yet.
+
+Proposal:
+Add the following method to the RecordValue abstract data type:
+
+TBoolean isFieldOptional(in TString fieldName)
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7497-2.docx (1,339,614) 18-11-2016 11:19
http://oldforge.etsi.org/mantis/file_download.php?file_id=3570&type=bug
Issue History
Date ModifiedUsernameFieldChange
12-09-2016 10:58Tomas UrbanNew Issue
14-11-2016 13:35Jens GrabowskiAssigned To => Jacob Wieland - Spirent
14-11-2016 13:35Jens GrabowskiStatusnew => assigned
15-11-2016 13:13Jacob Wieland - SpirentNote Added: 0014248
18-11-2016 11:19Jacob Wieland - SpirentFile Added: CR7497-2.docx
18-11-2016 11:20Jacob Wieland - SpirentNote Added: 0014335
18-11-2016 11:20Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Tomas Urban
18-11-2016 11:20Jacob Wieland - SpirentStatusassigned => confirmed
18-11-2016 12:32Tomas UrbanNote Added: 0014340
18-11-2016 12:32Tomas UrbanStatusconfirmed => resolved
18-11-2016 12:32Tomas UrbanResolutionopen => fixed
21-12-2016 10:52Tomas UrbanNote Added: 0014472
21-12-2016 10:52Tomas UrbanStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014248) +
+ Jacob Wieland - Spirent    +
+ 15-11-2016 13:13    +
+ 		+ + + + +
+ I propose to add a function Value.isOptional() instead.
+
+The usage would then be: ((RecordValue)value).getField(name).isOptional().
+
+The benefit is that it can also be applied to Values which are templates (i.e. in an external function).
+
+
+
+ + + + + + + + + + +
+ (0014335) +
+ Jacob Wieland - Spirent    +
+ 18-11-2016 11:20    +
+ 		+ + + + +
+ implemented as proposed, please review
+
+
+
+ + + + + + + + + + +
+ (0014340) +
+ Tomas Urban    +
+ 18-11-2016 12:32    +
+ 		+ + + + +
+ Reviewed. No issues found. Ready to be added to the standard.
+
+
+
+ + + + + + + + + + +
+ (0014472) +
+ Tomas Urban    +
+ 21-12-2016 10:52    +
+ 		+ + + + +
+ Added to draft 4.8.2
+
+ + diff --git a/docs/mantis/CR7501.md b/docs/mantis/CR7501.md new file mode 100644 index 0000000000000000000000000000000000000000..2d2c034752d84921962090ada1557c38c8400e23 --- /dev/null +++ b/docs/mantis/CR7501.md @@ -0,0 +1,236 @@ + + + + + + + + + + + + + 0007501: Missing mapping of several methods of abstract TTCN-3 data types and values - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007501Part 06: TTCN-3 Control InterfaceTechnicalpublic27-09-2016 08:5521-12-2016 13:49
ReporterTomas Urban 
Assigned ToTomas Urban 
PrioritynormalSeveritymajorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.9.1(ongoing) 
Target Versionv4.9.1(ongoing)Fixed in Versionv4.9.1(ongoing) 
Clause Reference(s)8.3.3.1, 9.2, 10.5.3.2, 12.4.3.1
Source (company - Author)Elvior
Summary0007501: Missing mapping of several methods of abstract TTCN-3 data types and values
DescriptionThe methods getLowerTypeBoundary, getUpperTypeBoundary, getTypeLengthRestriction and getTypeMatchingMechanism defined in 7.2.2.1 are mapped only to C++, but not to other available languages (C, C++, C#). The same methods defined in 7.2.2.2.1 are mapped to java, C and C#, but not to C++. The newTemplate method is defined only for java, but not for C, C++ or C#.
+
+Proposal: add missing mapping
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7505-1.docx (164,993) 18-11-2016 11:46
http://oldforge.etsi.org/mantis/file_download.php?file_id=3572&type=bug
docx CR7505-2.docx (175,878) 02-12-2016 12:59
http://oldforge.etsi.org/mantis/file_download.php?file_id=3574&type=bug
Issue History
Date ModifiedUsernameFieldChange
27-09-2016 08:55Tomas UrbanNew Issue
14-11-2016 13:33Jens GrabowskiAssigned To => Jacob Wieland - Spirent
14-11-2016 13:33Jens GrabowskiStatusnew => assigned
18-11-2016 11:13Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Tomas Urban
18-11-2016 11:46Tomas UrbanFile Added: CR7505-1.docx
18-11-2016 11:49Tomas UrbanNote Added: 0014339
18-11-2016 11:49Tomas UrbanAssigned ToTomas Urban => Jacob Wieland - Spirent
18-11-2016 11:49Tomas UrbanStatusassigned => confirmed
29-11-2016 12:15Jacob Wieland - SpirentNote Added: 0014361
29-11-2016 12:15Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Tomas Urban
29-11-2016 12:15Jacob Wieland - SpirentStatusconfirmed => assigned
29-11-2016 13:49Tomas UrbanAssigned ToTomas Urban => Jacob Wieland - Spirent
29-11-2016 13:49Tomas UrbanNote Added: 0014362
02-12-2016 12:59Tomas UrbanFile Added: CR7505-2.docx
02-12-2016 12:59Tomas UrbanNote Added: 0014363
02-12-2016 14:44Jacob Wieland - SpirentNote Added: 0014364
02-12-2016 14:44Jacob Wieland - SpirentStatusassigned => resolved
02-12-2016 14:44Jacob Wieland - SpirentFixed in Version => v4.9.1(ongoing)
02-12-2016 14:44Jacob Wieland - SpirentResolutionopen => fixed
02-12-2016 14:44Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Tomas Urban
21-12-2016 13:49Tomas UrbanNote Added: 0014473
21-12-2016 13:49Tomas UrbanStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014339) +
+ Tomas Urban    +
+ 18-11-2016 11:49    +
+ 		+ + + + +
+ Proposal uploaded. Some C functions were added as a part of 0007505. Please review.
+
+
+
+ + + + + + + + + + +
+ (0014361) +
+ Jacob Wieland - Spirent    +
+ 29-11-2016 12:15    +
+ 		+ + + + +
+ why is the getTypeLengthRestriction, getTypeUpperBoundary, getTypeLowerBoundary and getTypeMatchingMechanism in the Value interface (and there with a different name)?
+
+
+
+ + + + + + + + + + +
+ (0014362) +
+ Tomas Urban    +
+ 29-11-2016 13:49    +
+ 		+ + + + +
+ That's because they are defined both for the Type and Value interface in the section 7. In my opinion, there should be just one definition on the Type level, but once we have both in the specification, it is simpler to provide mapping for both. Value function names are different, because C doesn't allow name overloading.
+
+
+
+ + + + + + + + + + +
+ (0014363) +
+ Tomas Urban    +
+ 02-12-2016 12:59    +
+ 		+ + + + +
+ The original proposal contained only C support. Java, C++ and C# were added to the second one. Please check.
+
+
+
+ + + + + + + + + + +
+ (0014364) +
+ Jacob Wieland - Spirent    +
+ 02-12-2016 14:44    +
+ 		+ + + + +
+ ok
+
+
+
+ + + + + + + + + + +
+ (0014473) +
+ Tomas Urban    +
+ 21-12-2016 13:49    +
+ 		+ + + + +
+ Added to draft 4.8.2
+
+ + diff --git a/docs/mantis/CR7502.md b/docs/mantis/CR7502.md new file mode 100644 index 0000000000000000000000000000000000000000..6ea411515512c7bba4e018808d561efc44a2586b --- /dev/null +++ b/docs/mantis/CR7502.md @@ -0,0 +1,97 @@ + + + + + + + + + + + + + 0007502: Missing semicolon in C# mapping of Permutation - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007502Part 06: TTCN-3 Control InterfaceTechnicalpublic27-09-2016 09:0821-12-2016 10:25
ReporterTomas Urban 
Assigned ToTomas Urban 
PrioritynormalSeveritytrivialReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.9.1(ongoing) 
Target Versionv4.9.1(ongoing)Fixed in Version 
Clause Reference(s)12.4.2.18
Source (company - Author)Elvior
Summary0007502: Missing semicolon in C# mapping of Permutation
DescriptionThere's a syntax error in the C# definition of ITciPermutation: the set keyword shall be followed by a semicolon.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0007504closed Tomas Urban Invalid syntax in C mapping 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
27-09-2016 09:08Tomas UrbanNew Issue
14-11-2016 13:31Jens GrabowskiAssigned To => Tomas Urban
14-11-2016 13:31Jens GrabowskiStatusnew => assigned
14-11-2016 16:21Tomas UrbanAssigned ToTomas Urban => Axel Rennoch
16-11-2016 16:39Axel RennochRelationship addedrelated to 0007504
16-11-2016 16:39Axel RennochNote Added: 0014277
16-11-2016 16:39Axel RennochAssigned ToAxel Rennoch => Tomas Urban
16-11-2016 16:39Axel RennochStatusassigned => resolved
16-11-2016 16:39Axel RennochResolutionopen => fixed
21-12-2016 10:25Tomas UrbanNote Added: 0014469
21-12-2016 10:25Tomas UrbanStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014277) +
+ Axel Rennoch    +
+ 16-11-2016 16:39    +
+ 		+ + + + +
+ correction/resolution done in 7504
+
+
+
+ + + + + + + + + + +
+ (0014469) +
+ Tomas Urban    +
+ 21-12-2016 10:25    +
+ 		+ + + + +
+ Added to draft 4.8.2
+
+ + diff --git a/docs/mantis/CR7503.md b/docs/mantis/CR7503.md new file mode 100644 index 0000000000000000000000000000000000000000..94268e146a20d665d994e49e958ce466dc098c7c --- /dev/null +++ b/docs/mantis/CR7503.md @@ -0,0 +1,298 @@ + + + + + + + + + + + + + 0007503: allowed elements in a permutation matching-mechanism - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007503Part 01: TTCN-3 Core LanguageClarificationpublic29-09-2016 13:3212-12-2016 10:02
ReporterMartin Hauch 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.8.1 (published 2016-07) 
Target Versionv4.9.1 (published 2017-05)Fixed in Versionv4.9.1 (published 2017-05) 
Clause Reference(s)B.1.3.3
Source (company - Author)Devoteam - Martin Hauch
Summary0007503: allowed elements in a permutation matching-mechanism
DescriptionChapter: B.1.3.3 Permutation
+As I understand restriction c) and d) in this chapter, elements of a permutation should only be SpecificValue, AnyElement and AnyElementsOrNone.
+
+But in the following examples (from EXAMPLE1:) ValueList is also used as permutation-element.
+
+        template integer mw_myInt1 := (1,2,3);
+    template integer mw_myInt2 := (1,2,?);
+
+    template MySequenceOfType mw_myTemplate10 := { permutation (mw_myInt1, 2, 3 ), 5 };
+    // matches any of the sequences of 4 integers:
+    // 1,3,2,5; 2,1,3,5; 2,3,1,5; 3,1,2,5; or 3,2,1,5;
+    // 2,3,2,5; 2,2,3,5; 2,3,2,5; 3,2,2,5; or 3,2,2,5;
+    // 3,3,2,5; 2,3,3,5; 2,3,3,5; 3,3,2,5; or 3,2,3,5;
+
+    template MySequenceOfType mw_myTemplate11 := { permutation (mw_myInt2, 2, 3 ), 5 };
+    // matches any sequence of 4 integers that ends with 5 and contains 2 and 3 at least once in
+    // other positions
+
+Please check the restrictions for permutations and the examples above.
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7503_proposal.docx (155,022) 16-11-2016 09:28
http://oldforge.etsi.org/mantis/file_download.php?file_id=3528&type=bug
docx CR7503_proposal_v2.docx (155,096) 16-11-2016 15:09
http://oldforge.etsi.org/mantis/file_download.php?file_id=3542&type=bug
docx CR7503_proposal_v3.docx (175,094) 17-11-2016 11:25
http://oldforge.etsi.org/mantis/file_download.php?file_id=3551&type=bug
docx CR7503_proposal_v4.docx (155,247) 17-11-2016 11:34
http://oldforge.etsi.org/mantis/file_download.php?file_id=3552&type=bug
Issue History
Date ModifiedUsernameFieldChange
29-09-2016 13:32Martin HauchNew Issue
14-11-2016 13:31Jens GrabowskiAssigned To => Kristóf Szabados
14-11-2016 13:31Jens GrabowskiStatusnew => assigned
15-11-2016 13:35Kristóf SzabadosNote Added: 0014250
16-11-2016 09:28Kristóf SzabadosStatusassigned => confirmed
16-11-2016 09:28Kristóf SzabadosFile Added: CR7503_proposal.docx
16-11-2016 15:09Kristóf SzabadosFile Added: CR7503_proposal_v2.docx
16-11-2016 15:09Kristóf SzabadosNote Added: 0014273
16-11-2016 16:59Kristóf SzabadosAssigned ToKristóf Szabados => Tomas Urban
16-11-2016 16:59Kristóf SzabadosStatusconfirmed => assigned
16-11-2016 16:59Kristóf SzabadosNote Added: 0014284
17-11-2016 11:25Tomas UrbanFile Added: CR7503_proposal_v3.docx
17-11-2016 11:28Tomas UrbanNote Added: 0014296
17-11-2016 11:28Tomas UrbanAssigned ToTomas Urban => Kristóf Szabados
17-11-2016 11:28Tomas UrbanStatusassigned => confirmed
17-11-2016 11:34Kristóf SzabadosFile Added: CR7503_proposal_v4.docx
17-11-2016 11:35Kristóf SzabadosNote Added: 0014297
17-11-2016 11:38Kristóf SzabadosStatusconfirmed => resolved
17-11-2016 11:38Kristóf SzabadosFixed in Version => v4.10.1 (published 2018-05)
17-11-2016 11:38Kristóf SzabadosResolutionopen => fixed
17-11-2016 11:38Kristóf SzabadosAssigned ToKristóf Szabados => Gyorgy Rethy
17-11-2016 14:42Kristóf SzabadosNote Added: 0014313
17-11-2016 14:42Kristóf SzabadosStatusresolved => feedback
17-11-2016 14:42Kristóf SzabadosResolutionfixed => reopened
17-11-2016 14:42Kristóf SzabadosStatusfeedback => resolved
17-11-2016 14:42Kristóf SzabadosFixed in Versionv4.10.1 (published 2018-05) => v4.9.1 (published 2017-05)
17-11-2016 14:42Kristóf SzabadosResolutionreopened => fixed
12-12-2016 10:02Gyorgy RethyStatusresolved => closed
12-12-2016 10:02Gyorgy RethyTarget Version => v4.9.1 (published 2017-05)
12-12-2016 10:02Gyorgy RethyNote Added: 0014371
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014250) +
+ Kristóf Szabados    +
+ 15-11-2016 13:35    +
+ 		+ + + + +
+ restriction "d" sounds strange:
+- restriction "c" already limits the template referred to in the all from clause and it's elements.
+- Expressions, templates and AnyElement and AnyElementsOrNone are allowed as permutation elements.
+
+I believe restriction "d" tried to make sure that the same all from related restrictions are present when the all from is written out directly inside the
+permutation and when it would be present in a template that is used in the permutation (so that restriction "c" can not be circumvented by extracting an incorrect all from into template and reference it).
+
+So I propose to change restriction "d" to:
+"
+For template used as individual members of a permutation and defined using all from, the template in their all from clause shall obey to restriction c) above.
+"
+
+
+
+ + + + + + + + + + +
+ (0014273) +
+ Kristóf Szabados    +
+ 16-11-2016 15:09    +
+ 		+ + + + +
+ hopefully simplified wording
+
+
+
+ + + + + + + + + + +
+ (0014284) +
+ Kristóf Szabados    +
+ 16-11-2016 16:59    +
+ 		+ + + + +
+ please check if this restriction wording is good
+
+
+
+ + + + + + + + + + +
+ (0014296) +
+ Tomas Urban    +
+ 17-11-2016 11:28    +
+ 		+ + + + +
+ According to STF discussion, I removed the restriction on content (all matching mechanisms/templates allowed) and the restriction d). The only restriction that remained is that permutation cannot be present in the template referenced in the all from clause. It is for consistency with all other rules using the all from clause.
+
+Please review.
+
+
+
+ + + + + + + + + + +
+ (0014297) +
+ Kristóf Szabados    +
+ 17-11-2016 11:35    +
+ 		+ + + + +
+ removed the void restriction
+
+
+
+ + + + + + + + + + +
+ (0014313) +
+ Kristóf Szabados    +
+ 17-11-2016 14:42    +
+ 		+ + + + +
+ incorrect assignment at resolution
+
+
+
+ + + + + + + + + + +
+ (0014371) +
+ Gyorgy Rethy    +
+ 12-12-2016 10:02    +
+ 		+ + + + +
+ Added to draft V4.8.2
+
+ + diff --git a/docs/mantis/CR7504.md b/docs/mantis/CR7504.md new file mode 100644 index 0000000000000000000000000000000000000000..43c6283e2460066e59e8563777b7dc8f8710d199 --- /dev/null +++ b/docs/mantis/CR7504.md @@ -0,0 +1,165 @@ + + + + + + + + + + + + + 0007504: Invalid syntax in C mapping - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007504Part 06: TTCN-3 Control InterfaceTechnicalpublic30-09-2016 13:0221-12-2016 10:25
ReporterTomas Urban 
Assigned ToTomas Urban 
PrioritynormalSeveritytrivialReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.8.1 (published 2016-07) 
Target Versionv4.9.1(ongoing)Fixed in Version 
Clause Reference(s)9.5
Source (company - Author)Elvior
Summary0007504: Invalid syntax in C mapping
DescriptionThe LengthRestriction, Permutation and RangeBoundary structures have invalid syntax. All structure members shall contain semicolon at the end.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0007502closed Tomas Urban Missing semicolon in C# mapping of Permutation 
related to 0007506closed Tomas Urban Typo in C# Type mapping 
related to 0007507closed Tomas Urban Typos in C# ITciValue definition 
related to 0007511closed Tomas Urban C# mapping of matching mechanisms contains wrong parent type 
related to 0007510closed Tomas Urban Invalid return type in C# ITciMatchingMechanism.MatchingType 
Attached Filesdocx CR7504.docx (1,339,704) 16-11-2016 16:36
http://oldforge.etsi.org/mantis/file_download.php?file_id=3544&type=bug
Issue History
Date ModifiedUsernameFieldChange
30-09-2016 13:02Tomas UrbanNew Issue
30-09-2016 13:14Tomas UrbanNote Added: 0014217
30-09-2016 13:27Tomas UrbanNote Added: 0014218
14-11-2016 13:23Jens GrabowskiAssigned To => Tomas Urban
14-11-2016 13:23Jens GrabowskiStatusnew => assigned
14-11-2016 16:22Tomas UrbanAssigned ToTomas Urban => Axel Rennoch
16-11-2016 16:36Axel RennochFile Added: CR7504.docx
16-11-2016 16:38Axel RennochNote Added: 0014276
16-11-2016 16:38Axel RennochAssigned ToAxel Rennoch => Tomas Urban
16-11-2016 16:38Axel RennochStatusassigned => resolved
16-11-2016 16:38Axel RennochResolutionopen => fixed
16-11-2016 16:39Axel RennochRelationship addedrelated to 0007502
16-11-2016 16:40Axel RennochRelationship addedrelated to 0007506
16-11-2016 16:40Axel RennochRelationship addedrelated to 0007507
16-11-2016 16:41Axel RennochRelationship addedrelated to 0007511
16-11-2016 16:41Axel RennochRelationship addedrelated to 0007510
21-12-2016 10:25Tomas UrbanNote Added: 0014470
21-12-2016 10:25Tomas UrbanStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014217) +
+ Tomas Urban    +
+ 30-09-2016 13:14    +
+ 		+ + + + +
+ The typedef keyword shall not start with a capital letter too.
+
+
+
+ + + + + + + + + + +
+ (0014218) +
+ Tomas Urban    +
+ 30-09-2016 13:27    +
+ 		+ + + + +
+ The second TciRangeBoundary identifier is missing in the definition of the type.
+
+
+
+ + + + + + + + + + +
+ (0014276) +
+ Axel Rennoch    +
+ 16-11-2016 16:38    +
+ 		+ + + + +
+ CRs 7502, 7504, 7506, 7507, 7510, 7511 done in the attached file
+
+
+
+ + + + + + + + + + +
+ (0014470) +
+ Tomas Urban    +
+ 21-12-2016 10:25    +
+ 		+ + + + +
+ Added to draft 4.8.2
+
+ + diff --git a/docs/mantis/CR7505.md b/docs/mantis/CR7505.md new file mode 100644 index 0000000000000000000000000000000000000000..f3f4f32a43d86172c6cb2cf93886bb70668b297a --- /dev/null +++ b/docs/mantis/CR7505.md @@ -0,0 +1,131 @@ + + + + + + + + + + + + + 0007505: The C mapping of several TCI function is wrong - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007505Part 06: TTCN-3 Control InterfaceTechnicalpublic30-09-2016 13:2021-12-2016 10:35
ReporterTomas Urban 
Assigned ToTomas Urban 
PrioritynormalSeveritymajorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.8.1 (published 2016-07) 
Target Versionv4.9.1(ongoing)Fixed in Version 
Clause Reference(s)9.2
Source (company - Author)Elvior
Summary0007505: The C mapping of several TCI function is wrong
DescriptionThe constraint and length restriction related functions (getTypeLengthRestriction, getLowerTypeBoundary, getUpperTypeBoundary, getTypeMatchingMechanism, getLengthRestriction, setLengthRestriction) shall use pointers as null is one of the possible values. It is not possible to provide the null value with the current mapping.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7505-1.docx (164,993) 18-11-2016 09:57
http://oldforge.etsi.org/mantis/file_download.php?file_id=3564&type=bug
docx CR7505-2.docx (149,679) 18-11-2016 10:33
http://oldforge.etsi.org/mantis/file_download.php?file_id=3567&type=bug
Issue History
Date ModifiedUsernameFieldChange
30-09-2016 13:20Tomas UrbanNew Issue
14-11-2016 13:28Jens GrabowskiAssigned To => Tomas Urban
14-11-2016 13:28Jens GrabowskiStatusnew => assigned
18-11-2016 09:57Tomas UrbanFile Added: CR7505-1.docx
18-11-2016 09:58Tomas UrbanNote Added: 0014327
18-11-2016 09:58Tomas UrbanAssigned ToTomas Urban => Axel Rennoch
18-11-2016 09:58Tomas UrbanStatusassigned => confirmed
18-11-2016 10:33Axel RennochFile Added: CR7505-2.docx
18-11-2016 10:33Axel RennochNote Added: 0014331
18-11-2016 10:33Axel RennochAssigned ToAxel Rennoch => Tomas Urban
18-11-2016 10:33Axel RennochStatusconfirmed => assigned
18-11-2016 10:33Axel RennochStatusassigned => resolved
18-11-2016 10:33Axel RennochResolutionopen => fixed
21-12-2016 10:35Tomas UrbanNote Added: 0014471
21-12-2016 10:35Tomas UrbanStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014327) +
+ Tomas Urban    +
+ 18-11-2016 09:58    +
+ 		+ + + + +
+ Proposal draft uploaded. Please review.
+
+
+
+ + + + + + + + + + +
+ (0014331) +
+ Axel Rennoch    +
+ 18-11-2016 10:33    +
+ 		+ + + + +
+ changes are ok, just one typo identified.
+
+
+
+ + + + + + + + + + +
+ (0014471) +
+ Tomas Urban    +
+ 21-12-2016 10:35    +
+ 		+ + + + +
+ Added to draft 4.8.2
+
+ + diff --git a/docs/mantis/CR7506.md b/docs/mantis/CR7506.md new file mode 100644 index 0000000000000000000000000000000000000000..ce39519324a157d5eb2d8a5e05fb4784ddb2c5f5 --- /dev/null +++ b/docs/mantis/CR7506.md @@ -0,0 +1,97 @@ + + + + + + + + + + + + + 0007506: Typo in C# Type mapping - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007506Part 06: TTCN-3 Control InterfaceTechnicalpublic07-10-2016 10:2521-12-2016 10:25
ReporterTomas Urban 
Assigned ToTomas Urban 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.8.1 (published 2016-07) 
Target Versionv4.9.1(ongoing)Fixed in Version 
Clause Reference(s)12.4.3.1
Source (company - Author)Elvior
Summary0007506: Typo in C# Type mapping
DescriptionThe return value of the ITciType.ParseValue method is misspelled: there should be ITciValue instead of ItciValue.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0007504closed Tomas Urban Invalid syntax in C mapping 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
07-10-2016 10:25Tomas UrbanNew Issue
14-11-2016 13:23Jens GrabowskiAssigned To => Tomas Urban
14-11-2016 13:23Jens GrabowskiStatusnew => assigned
14-11-2016 16:22Tomas UrbanAssigned ToTomas Urban => Axel Rennoch
16-11-2016 16:40Axel RennochNote Added: 0014278
16-11-2016 16:40Axel RennochRelationship addedrelated to 0007504
16-11-2016 16:40Axel RennochAssigned ToAxel Rennoch => Tomas Urban
16-11-2016 16:40Axel RennochStatusassigned => resolved
16-11-2016 16:40Axel RennochResolutionopen => fixed
21-12-2016 10:25Tomas UrbanNote Added: 0014468
21-12-2016 10:25Tomas UrbanStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014278) +
+ Axel Rennoch    +
+ 16-11-2016 16:40    +
+ 		+ + + + +
+ correction/resolution done in 7504
+
+
+
+ + + + + + + + + + +
+ (0014468) +
+ Tomas Urban    +
+ 21-12-2016 10:25    +
+ 		+ + + + +
+ Added to draft 4.8.2
+
+ + diff --git a/docs/mantis/CR7507.md b/docs/mantis/CR7507.md new file mode 100644 index 0000000000000000000000000000000000000000..6d3130d458d778f758829d5353a1436461ae80e6 --- /dev/null +++ b/docs/mantis/CR7507.md @@ -0,0 +1,98 @@ + + + + + + + + + + + + + 0007507: Typos in C# ITciValue definition - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007507Part 06: TTCN-3 Control InterfaceEditorialpublic07-10-2016 12:1421-12-2016 10:24
ReporterTomas Urban 
Assigned ToTomas Urban 
PrioritylowSeveritytextReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.8.1 (published 2016-07) 
Target Versionv4.9.1(ongoing)Fixed in Version 
Clause Reference(s)12.4.4.1
Source (company - Author)Elvior
Summary0007507: Typos in C# ITciValue definition
DescriptionThe ITciValue.newLengthRestriction method shall start with a capital letter.
+The public keyword should be removed from the IsIfPresentEnabled property.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0007504closed Tomas Urban Invalid syntax in C mapping 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
07-10-2016 12:14Tomas UrbanNew Issue
07-10-2016 12:16Tomas UrbanSummaryTypo in C# ITciValue definition => Typos in C# ITciValue definition
07-10-2016 12:16Tomas UrbanDescription Updatedbug_revision_view_page.php?rev_id=321#r321
14-11-2016 13:22Jens GrabowskiAssigned To => Tomas Urban
14-11-2016 13:22Jens GrabowskiStatusnew => assigned
14-11-2016 16:23Tomas UrbanAssigned ToTomas Urban => Axel Rennoch
16-11-2016 16:40Axel RennochNote Added: 0014279
16-11-2016 16:40Axel RennochRelationship addedrelated to 0007504
16-11-2016 16:40Axel RennochAssigned ToAxel Rennoch => Tomas Urban
16-11-2016 16:40Axel RennochStatusassigned => resolved
16-11-2016 16:40Axel RennochResolutionopen => fixed
21-12-2016 10:24Tomas UrbanNote Added: 0014467
21-12-2016 10:24Tomas UrbanStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014279) +
+ Axel Rennoch    +
+ 16-11-2016 16:40    +
+ 		+ + + + +
+ correction/resolution done in 7504
+
+
+
+ + + + + + + + + + +
+ (0014467) +
+ Tomas Urban    +
+ 21-12-2016 10:24    +
+ 		+ + + + +
+ Added to draft 4.8.2
+
+ + diff --git a/docs/mantis/CR7508.md b/docs/mantis/CR7508.md new file mode 100644 index 0000000000000000000000000000000000000000..ba4cbbae40d53c510463ae6f8425851ed6847c1f --- /dev/null +++ b/docs/mantis/CR7508.md @@ -0,0 +1,166 @@ + + + + + + + + + + + + + 0007508: some corrections in BNF (section A.1) - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007508Part 01: TTCN-3 Core LanguageEditorialpublic12-10-2016 14:2216-12-2016 18:19
ReporterAxel Rennoch 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.8.1 (published 2016-07) 
Target Versionv4.9.1 (published 2017-05)Fixed in Versionv4.9.1 (published 2017-05) 
Clause Reference(s)A.1
Source (company - Author)A. Rennoch (Fokus)
Summary0007508: some corrections in BNF (section A.1)
DescriptionA couple of small errors in the BNF: see attachment
+
Steps To Reproduceapplication of https://bnftools.informatik.uni-goettingen.de/trac#no1 [^]
Additional Information
TagsNo tags attached.
Relationships
related to 0007492closed Gyorgy Rethy duplication and ambiguity concerning actual par lists in BNF 
Attached Filesdocx Corrections for the BNF.docx (14,900) 12-10-2016 14:22
http://oldforge.etsi.org/mantis/file_download.php?file_id=3510&type=bug
docx CR7508_resolution_v1.docx (77,049) 12-10-2016 15:51
http://oldforge.etsi.org/mantis/file_download.php?file_id=3511&type=bug
Issue History
Date ModifiedUsernameFieldChange
12-10-2016 14:22Axel RennochNew Issue
12-10-2016 14:22Axel RennochStatusnew => assigned
12-10-2016 14:22Axel RennochAssigned To => Axel Rennoch
12-10-2016 14:22Axel RennochFile Added: Corrections for the BNF.docx
12-10-2016 15:51Axel RennochFile Added: CR7508_resolution_v1.docx
12-10-2016 15:52Axel RennochNote Added: 0014219
15-11-2016 10:08Axel RennochNote Added: 0014241
15-11-2016 10:08Axel RennochRelationship addedrelated to 0007492
15-11-2016 10:28Axel RennochAssigned ToAxel Rennoch => Gyorgy Rethy
15-11-2016 10:29Axel RennochNote Added: 0014244
15-11-2016 10:29Axel RennochStatusassigned => resolved
15-11-2016 10:29Axel RennochResolutionopen => fixed
16-12-2016 18:19Gyorgy RethyNote Added: 0014447
16-12-2016 18:19Gyorgy RethyStatusresolved => closed
16-12-2016 18:19Gyorgy RethyFixed in Version => v4.9.1 (published 2017-05)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014219) +
+ Axel Rennoch    +
+ 12-10-2016 15:52    +
+ 		+ + + + +
+ uploaded file includes corrected BNF (output from https://bnftools.informatik.uni-goettingen.de/trac#no1 [^])
+
+
+
+ + + + + + + + + + +
+ (0014241) +
+ Axel Rennoch    +
+ 15-11-2016 10:08    +
+ 		+ + + + +
+ covered by CR7492
+
+
+
+ + + + + + + + + + +
+ (0014244) +
+ Axel Rennoch    +
+ 15-11-2016 10:29    +
+ 		+ + + + +
+ resolved due to CR7492
+
+
+
+ + + + + + + + + + +
+ (0014447) +
+ Gyorgy Rethy    +
+ 16-12-2016 18:19    +
+ 		+ + + + +
+ Corrected to draft V4.8.3
+
+ + diff --git a/docs/mantis/CR7510.md b/docs/mantis/CR7510.md new file mode 100644 index 0000000000000000000000000000000000000000..da671899d065020de6484b005723b9a5f1e742fd --- /dev/null +++ b/docs/mantis/CR7510.md @@ -0,0 +1,97 @@ + + + + + + + + + + + + + 0007510: Invalid return type in C# ITciMatchingMechanism.MatchingType - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007510Part 06: TTCN-3 Control InterfaceTechnicalpublic17-10-2016 14:4221-12-2016 10:23
ReporterTomas Urban 
Assigned ToTomas Urban 
PrioritynormalSeveritytextReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.8.1 (published 2016-07) 
Target VersionFixed in Version 
Clause Reference(s)12.4.5.1
Source (company - Author)Elvior
Summary0007510: Invalid return type in C# ITciMatchingMechanism.MatchingType
DescriptionThe return type of the C# ITciMatchingMechanism.MatchingType shall be TciMatchingType (instead of ITciMatchingType).
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0007504closed Tomas Urban Invalid syntax in C mapping 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
17-10-2016 14:42Tomas UrbanNew Issue
14-11-2016 13:22Jens GrabowskiAssigned To => Tomas Urban
14-11-2016 13:22Jens GrabowskiStatusnew => assigned
14-11-2016 16:24Tomas UrbanAssigned ToTomas Urban => Axel Rennoch
16-11-2016 16:41Axel RennochNote Added: 0014281
16-11-2016 16:41Axel RennochRelationship addedrelated to 0007504
16-11-2016 16:41Axel RennochAssigned ToAxel Rennoch => Tomas Urban
16-11-2016 16:41Axel RennochStatusassigned => resolved
16-11-2016 16:41Axel RennochResolutionopen => fixed
21-12-2016 10:23Tomas UrbanNote Added: 0014465
21-12-2016 10:23Tomas UrbanStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014281) +
+ Axel Rennoch    +
+ 16-11-2016 16:41    +
+ 		+ + + + +
+ correction/resolution done in 7504
+
+
+
+ + + + + + + + + + +
+ (0014465) +
+ Tomas Urban    +
+ 21-12-2016 10:23    +
+ 		+ + + + +
+ Added to draft 4.8.2
+
+ + diff --git a/docs/mantis/CR7511.md b/docs/mantis/CR7511.md new file mode 100644 index 0000000000000000000000000000000000000000..8e04f9119c7897f03b3b210d1d829639eb0c1cd4 --- /dev/null +++ b/docs/mantis/CR7511.md @@ -0,0 +1,97 @@ + + + + + + + + + + + + + 0007511: C# mapping of matching mechanisms contains wrong parent type - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007511Part 06: TTCN-3 Control InterfaceEditorialpublic17-10-2016 14:4921-12-2016 10:24
ReporterTomas Urban 
Assigned ToTomas Urban 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.8.1 (published 2016-07) 
Target VersionFixed in Version 
Clause Reference(s)12.4.5
Source (company - Author)Elvior
Summary0007511: C# mapping of matching mechanisms contains wrong parent type
DescriptionThe parent type of ITciMatchingList, ITciValueRange, ITciCharacterPattern and ITciMatchDecodedContent should be ITciMatchingMechanism(and not IMatchingMechanism).
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0007504closed Tomas Urban Invalid syntax in C mapping 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
17-10-2016 14:49Tomas UrbanNew Issue
14-11-2016 13:22Jens GrabowskiAssigned To => Tomas Urban
14-11-2016 13:22Jens GrabowskiStatusnew => assigned
14-11-2016 16:24Tomas UrbanAssigned ToTomas Urban => Axel Rennoch
16-11-2016 16:41Axel RennochNote Added: 0014280
16-11-2016 16:41Axel RennochRelationship addedrelated to 0007504
16-11-2016 16:41Axel RennochAssigned ToAxel Rennoch => Tomas Urban
16-11-2016 16:41Axel RennochStatusassigned => resolved
16-11-2016 16:41Axel RennochResolutionopen => fixed
21-12-2016 10:24Tomas UrbanNote Added: 0014466
21-12-2016 10:24Tomas UrbanStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014280) +
+ Axel Rennoch    +
+ 16-11-2016 16:41    +
+ 		+ + + + +
+ correction/resolution done in 7504
+
+
+
+ + + + + + + + + + +
+ (0014466) +
+ Tomas Urban    +
+ 21-12-2016 10:24    +
+ 		+ + + + +
+ Added to draft 4.8.2
+
+ + diff --git a/docs/mantis/CR7512.md b/docs/mantis/CR7512.md new file mode 100644 index 0000000000000000000000000000000000000000..e8c72462b2bf66dedba6eeec722683264081dd2c --- /dev/null +++ b/docs/mantis/CR7512.md @@ -0,0 +1,631 @@ + + + + + + + + + + + + + 0007512: XML mapping of matching symbols - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007512Part 06: TTCN-3 Control InterfaceTechnicalpublic19-10-2016 13:1815-01-2018 07:53
ReporterTomas Urban 
Assigned ToTomas Urban 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.8.1 (published 2016-07) 
Target VersionNext version (to be defined)Fixed in Version 
Clause Reference(s)11.3.3
Source (company - Author)Elvior
Summary0007512: XML mapping of matching symbols
DescriptionThe XML mapping of TCI matching symbol type doesn't match the specification of the abstract data type defined in 7.2.2.3. At the moment the XSD type is defined as follows:
+
+<xsd:complexType name="MatchingSymbol">
+ <xsd:simpleContent>
+  <xsd:extension base="SimpleTypes:TString">
+   <xsd:attributeGroup ref="Values:ValueAtts"/>
+  </xsd:extension>
+  </xsd:simpleContent>
+</xsd:complexType>
+
+It is not explained what the string should contain. Attributes are superfluous as they are present at the wrapping value level.
+
+Correct mapping should be a choice of options defined in 7.2.2.3. Each option should contain all data fields specified for the data type:
+
+<xsd:complexType name="MatchingSymbol">
+  <xsd:choice>
+    <xsd:element name="any" type="SimpleTypes:TEmpty"/>
+    <xsd:element name="value_or_none" type="SimpleTypes:TEmpty"/>
+    <xsd:element name="any_element" type="SimpleTypes:TEmpty"/>
+    <xsd:element name="elements_or_none" type="SimpleTypes:TEmpty"/>
+    <xsd:element name="omit" type="SimpleTypes:TEmpty"/>
+    <xsd:element name="complemented_list" type="Templates:MatchingList"/>
+    <xsd:element name="template_list" type="Templates:MatchingList"/>
+    <xsd:element name="subset" type="Templates:MatchingList"/>
+    <xsd:element name="superset" type="Templates:MatchingList"/>
+    <xsd:element name="range" type="Templates:ValueRange"/>
+    <xsd:element name="pattern" type="SimpleTypes:TString"/>
+    <xsd:element name="dec_match" type="Templates:MatchDecodedContent"/>
+   </xsd:choice>
+</xsd:complexType>
+
+<xsd:complexType name="TEmpty" />
+
+<xsd:complexType name="MatchingList">
+ <xsd:choice>
+  <xsd:element name="integer" type="Values:IntegerValue" minOccurs="1"
+maxOccurs="unbounded" />
+  <xsd:element name="float" type="Values:FloatValue" minOccurs="1"
+maxOccurs="unbounded" />
+  <xsd:element name="boolean" type="Values:BooleanValue" minOccurs="1"
+maxOccurs="unbounded" />
+  <xsd:element name="verdicttype" type="Values:VerdictValue" minOccurs="1"
+maxOccurs="unbounded" />
+  <xsd:element name="bitstring" type="Values:BitstringValue" minOccurs="1"
+maxOccurs="unbounded" />
+  <xsd:element name="hexstring" type="Values:HexstringValue" minOccurs="1"
+maxOccurs="unbounded" />
+  <xsd:element name="octetstring" type="Values:OctetstringValue" minOccurs="1"
+maxOccurs="unbounded" />
+  <xsd:element name="charstring" type="Values:CharstringValue" minOccurs="1"
+maxOccurs="unbounded" />
+  <xsd:element name="universal_charstring" type="Values:UniversalCharstringValue" minOccurs="1"
+maxOccurs="unbounded" />
+  <xsd:element name="record" type="Values:RecordValue" minOccurs="1"
+maxOccurs="unbounded" />
+  <xsd:element name="record_of" type="Values:RecordOfValue" minOccurs="1"
+maxOccurs="unbounded" />
+  <xsd:element name="array" type="Values:ArrayValue" minOccurs="1"
+maxOccurs="unbounded" />
+  <xsd:element name="set" type="Values:SetValue" minOccurs="1"
+maxOccurs="unbounded" />
+  <xsd:element name="set_of" type="Values:SetOfValue" minOccurs="1"
+maxOccurs="unbounded" />
+  <xsd:element name="enumerated" type="Values:EnumeratedValue" minOccurs="1"
+maxOccurs="unbounded" />
+  <xsd:element name="union" type="Values:UnionValue" minOccurs="1"
+maxOccurs="unbounded" />
+  <xsd:element name="anytype" type="Values:AnytypeValue" minOccurs="1"
+maxOccurs="unbounded" />
+  <xsd:element name="address" type="Values:AddressValue" minOccurs="1"
+maxOccurs="unbounded" />
+  <xsd:element name="component" type="Values:ComponentValue" minOccurs="1"
+maxOccurs="unbounded" />
+  <xsd:element name="port" type="Values:PortValue" minOccurs="1"
+maxOccurs="unbounded" />
+  <xsd:element name="default" type="Values:DefaultValue" minOccurs="1"
+maxOccurs="unbounded" />
+  <xsd:element name="timer" type="Values:TimerValue" minOccurs="1"
+maxOccurs="unbounded" />
+ </xsd:choice>
+</xsd:complexType>
+
+<xsd:complexType name="ValueRange">
+ <xsd:sequence>
+  <xsd:element name="lower" type="Templates:RangeBoundary" />
+  <xsd:element name="upper" type="Templates:RangeBoundary" />
+ </xsd:sequence>
+</xsd:complexType>
+
+<xsd:complexType name="RangeBoundary">
+ <xsd:choice>
+  <xsd:sequence>
+   <xsd:choice>
+    <xsd:element name="integer" type="Values:IntegerValue" />
+    <xsd:element name="float" type="Values:FloatValue" />
+    <xsd:element name="charstring" type="Values:CharstringValue" />
+    <xsd:element name="universal_charstring" type="Values:UniversalCharstringValue" />
+   </xsd:choice>
+   <xsd:element name="exclusive" type="SimpleTypes:TEmpty" minOccurs="0"/>
+  </xsd:sequence>
+  <xsd:element name="infinity" type="SimpleTypes:TEmpty" />
+ </xsd:choice>
+</xsd:complexType>
+
+<xsd:complexType name="MatchDecodedContent">
+ <xsd:choice>
+  <xsd:element name="integer" type="Values:IntegerValue"/>
+  <xsd:element name="float" type="Values:FloatValue"/>
+  <xsd:element name="boolean" type="Values:BooleanValue"/>
+  <xsd:element name="verdicttype" type="Values:VerdictValue"/>
+  <xsd:element name="bitstring" type="Values:BitstringValue"/>
+  <xsd:element name="hexstring" type="Values:HexstringValue"/>
+  <xsd:element name="octetstring" type="Values:OctetstringValue"/>
+  <xsd:element name="charstring" type="Values:OctetstringValue"/>
+  <xsd:element name="universal_charstring" type="Values:UniversalCharstringValue"/>
+  <xsd:element name="record" type="Values:RecordValue"/>
+  <xsd:element name="record_of" type="Values:RecordOfValue"/>
+  <xsd:element name="array" type="Values:ArrayValue"/>
+  <xsd:element name="set" type="Values:SetValue"/>
+  <xsd:element name="set_of" type="Values:SetOfValue"/>
+  <xsd:element name="enumerated" type="Values:EnumeratedValue"/>
+  <xsd:element name="union" type="Values:UnionValue"/>
+  <xsd:element name="anytype" type="Values:AnytypeValue"/>
+ </xsd:choice>
+</xsd:complexType>
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0007519closed Tomas Urban Ifpresent and length matching attributes not defined in XML mapping 
Attached Files? Templates.xsd (17,143) 26-10-2017 10:40
http://oldforge.etsi.org/mantis/file_download.php?file_id=3709&type=bug
? Values.xsd (9,260) 26-10-2017 10:40
http://oldforge.etsi.org/mantis/file_download.php?file_id=3710&type=bug
? SimpleTypes_v4_10_1.xsd (2,599) 03-01-2018 11:49
http://oldforge.etsi.org/mantis/file_download.php?file_id=3729&type=bug
? Templates_v4_10_1.xsd (4,123) 03-01-2018 11:49
http://oldforge.etsi.org/mantis/file_download.php?file_id=3730&type=bug
? Values_v4_10_1.xsd (13,426) 03-01-2018 11:50
http://oldforge.etsi.org/mantis/file_download.php?file_id=3731&type=bug
docx CR7512-v1.docx (403,290) 04-01-2018 10:53
http://oldforge.etsi.org/mantis/file_download.php?file_id=3732&type=bug
docx CR7512-v2.docx (413,660) 10-01-2018 10:13
http://oldforge.etsi.org/mantis/file_download.php?file_id=3734&type=bug
Issue History
Date ModifiedUsernameFieldChange
19-10-2016 13:18Tomas UrbanNew Issue
19-10-2016 13:29Tomas UrbanDescription Updatedbug_revision_view_page.php?rev_id=323#r323
19-10-2016 13:34Tomas UrbanDescription Updatedbug_revision_view_page.php?rev_id=324#r324
19-10-2016 13:35Tomas UrbanDescription Updatedbug_revision_view_page.php?rev_id=325#r325
27-10-2016 09:18Tomas UrbanDescription Updatedbug_revision_view_page.php?rev_id=326#r326
27-10-2016 12:38Tomas UrbanDescription Updatedbug_revision_view_page.php?rev_id=327#r327
27-10-2016 13:02Tomas UrbanDescription Updatedbug_revision_view_page.php?rev_id=328#r328
14-11-2016 13:20Jens GrabowskiAssigned To => Jacob Wieland - Spirent
14-11-2016 13:20Jens GrabowskiStatusnew => assigned
14-11-2016 13:20Jens GrabowskiNote Added: 0014229
24-12-2016 15:07Jens GrabowskiTarget Version => Next version (to be defined)
24-10-2017 13:13Jens GrabowskiNote Added: 0014848
26-10-2017 10:40Jacob Wieland - SpirentFile Added: Templates.xsd
26-10-2017 10:40Jacob Wieland - SpirentFile Added: Values.xsd
26-10-2017 10:43Jacob Wieland - SpirentNote Added: 0014884
26-10-2017 10:43Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Tomas Urban
26-10-2017 10:44Jacob Wieland - SpirentRelationship addedrelated to 0007519
03-01-2018 11:49Tomas UrbanFile Added: SimpleTypes_v4_10_1.xsd
03-01-2018 11:49Tomas UrbanFile Added: Templates_v4_10_1.xsd
03-01-2018 11:50Tomas UrbanFile Added: Values_v4_10_1.xsd
03-01-2018 12:15Tomas UrbanAssigned ToTomas Urban => Jacob Wieland - Spirent
03-01-2018 12:17Tomas UrbanNote Added: 0014990
04-01-2018 10:53Tomas UrbanFile Added: CR7512-v1.docx
08-01-2018 13:22Jacob Wieland - SpirentNote Added: 0015018
08-01-2018 13:28Tomas UrbanNote Added: 0015019
08-01-2018 14:26Tomas UrbanNote Added: 0015020
10-01-2018 10:01Jacob Wieland - SpirentNote Added: 0015021
10-01-2018 10:03Jacob Wieland - SpirentNote Added: 0015022
10-01-2018 10:13Tomas UrbanNote Added: 0015023
10-01-2018 10:13Tomas UrbanFile Added: CR7512-v2.docx
10-01-2018 10:15Tomas UrbanNote Added: 0015024
10-01-2018 10:35Jacob Wieland - SpirentNote Added: 0015025
10-01-2018 10:35Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Tomas Urban
10-01-2018 10:35Jacob Wieland - SpirentStatusassigned => confirmed
15-01-2018 07:53Tomas UrbanNote Added: 0015027
15-01-2018 07:53Tomas UrbanStatusconfirmed => closed
15-01-2018 07:53Tomas UrbanResolutionopen => fixed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014229) +
+ Jens Grabowski    +
+ 14-11-2016 13:20    +
+ 		+ + + + +
+ Jacob will make a proposal.
+
+
+
+ + + + + + + + + + +
+ (0014848) +
+ Jens Grabowski    +
+ 24-10-2017 13:13    +
+ 		+ + + + +
+ (To be implemented until end of 2017)
+
+
+
+ + + + + + + + + + +
+ (0014884) +
+ Jacob Wieland - Spirent    +
+ 26-10-2017 10:43    +
+ 		+ + + + +
+ I have uploaded a new version of Values.xsd and Templates.xsd that should fix some bugs in the current xsd definition (wrong choice extensions between Values and Templates), reduce the amount of copy-paste-code by using groups.
+
+The element templateDef has been enlarged with constructs to model all currently existing (even advanced matching) matching mechanisms. I have not stuck too close to the naming in TCI, but if that is required, a renaming is of course possible.
+
+
+
+ + + + + + + + + + +
+ (0014990) +
+ Tomas Urban    +
+ 03-01-2018 12:17    +
+ 		+ + + + +
+ I like the idea of code reduction and I added it to the next version of the proposal. However, the proposed removal of matching_symbol element from the Values:Value types (present in individual choice options such as IntegerValue, FloatValue etc.) cannot be achieved. These types are used in logging and in case of several TLI events (such as SEnter), they can contain matching symbols.
+
+For that reason I modified the proposal in the following way:
+
+1. The BaseValue group contains an option to specify a matching symbol instead of a value or a special symbol (omit, null).
+2. I preserved the option for not-evaluated fuzzy or lazy value in BaseValue (it was removed for some reason and I don't think TLI should trigger evaluation)
+3. I reduced the number of types in the template schema. The TciValueTemplate and TciNonValueTemplate types can use Values:Value type for detailed description of the value or template - there's no need to have dedicated template types such as IntegerTemplate.
+4. I modified the existing Templates:MatchingSymbol type so that it can contain structured information about the template.
+5. The features from extension packages are not in the files, they have to be moved to the extension package specifications.
+
+Please let me know what do you think about the proposal. I am sorry for replying so late.
+
+
+
+ + + + + + + + + + +
+ (0015018) +
+ Jacob Wieland - Spirent    +
+ 08-01-2018 13:22    +
+ 		+ + + + +
+ While I principally like this further simplification, I don't think this is a backward compatible change.
+
+I am referring to the removal of the X-Template types, IntegerTemplate and so forth). Because they have the same element-names, but live in a different namespace, up till now we had <templates-ns>:omit and <values-ns>:omit which were different (same for all the other variants).
+
+To be sure, this is very annoying and therefore, I like this new approach better, but I am not sure if people will be happy if their old log files do not conform to the new schema anymore.
+
+Thus, I think we should leave these old types as alternatives in the standard and mark them (and their usage) as deprecated.
+
+
+
+ + + + + + + + + + +
+ (0015019) +
+ Tomas Urban    +
+ 08-01-2018 13:28    +
+ 		+ + + + +
+ OK, I will try to change the proposal accordingly.
+
+
+
+ + + + + + + + + + +
+ (0015020) +
+ Tomas Urban    +
+ 08-01-2018 14:26    +
+ 		+ + + + +
+ Jacob, I just wonder how big the compatibility issue might be. Our tool doesn't produce logs in this format, so we are not affected by this. Neither is Ericsson as they don't have TCI at all.
+
+How does your tool log e.g. "integer:?" into an XML element of the Templates:TciValueTemplate type? According to the current current schema, both the value and template part are mandatory which seems rather strange. What do you put to the value part in this case?
+
+
+
+ + + + + + + + + + +
+ (0015021) +
+ Jacob Wieland - Spirent    +
+ 10-01-2018 10:01    +
+ 		+ + + + +
+ It's just the difference between
+
+<Values:integer>
+
+and
+
+<Templates:integer>
+
+(or whatever namespace-prefix you choose for Values.xsd and Templates.xsd).
+
+If all elements had been defined as unqualified, there wouldn't be a problem.
+
+For Spiretn, it would definitely be a compatibility issue, though probably not something that can't be dealt with as we just need to replace namespace prefixes in old logs, but it is still effort.
+
+Thus, I would propose to escalate this to the other tool vendors before making this decision.
+
+
+
+ + + + + + + + + + +
+ (0015022) +
+ Jacob Wieland - Spirent    +
+ 10-01-2018 10:03    +
+ 		+ + + + +
+ Also, I think the old standard defined the whole schema wrong anyway, assuming that extending a choice with another choice produces a choice instead of a sequence of two choices.
+
+That's why I guess the whole discussion doesn't matter really as no log ever that involved templates was really standard conform anyway.
+
+
+
+ + + + + + + + + + +
+ (0015023) +
+ Tomas Urban    +
+ 10-01-2018 10:13    +
+ 		+ + + + +
+ Extending a choice with another choice produces a sequence of two choices, where the first (value) part is mandatory. This is rather strange approach, as I have no idea what would go to the value part in case of "integer:?" (assuming that matching symbols were not defined as it is in the current standard).
+
+
+
+ + + + + + + + + + +
+ (0015024) +
+ Tomas Urban    +
+ 10-01-2018 10:15    +
+ 		+ + + + +
+ Please check my second proposal where old elements from the Templates namespace are kept. However, that proposal removes the sequence of two choices. If it is necessary to keep it, it has to be updated.
+
+
+
+ + + + + + + + + + +
+ (0015025) +
+ Jacob Wieland - Spirent    +
+ 10-01-2018 10:35    +
+ 		+ + + + +
+ The proposal is fine. It rectifies the problems while keeping backward compatibility to the intention of the former version.
+
+
+
+ + + + + + + + + + +
+ (0015027) +
+ Tomas Urban    +
+ 15-01-2018 07:53    +
+ 		+ + + + +
+ Added to the specification.
+
+ + diff --git a/docs/mantis/CR7519.md b/docs/mantis/CR7519.md new file mode 100644 index 0000000000000000000000000000000000000000..48d6a6f4e406f111ec3d49450f9f7001a1df7bbc --- /dev/null +++ b/docs/mantis/CR7519.md @@ -0,0 +1,159 @@ + + + + + + + + + + + + + 0007519: Ifpresent and length matching attributes not defined in XML mapping - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007519Part 06: TTCN-3 Control InterfaceTechnicalpublic25-10-2016 10:4215-01-2018 07:54
ReporterTomas Urban 
Assigned ToTomas Urban 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.8.1 (published 2016-07) 
Target VersionNext version (to be defined)Fixed in Version 
Clause Reference(s)11.3.3
Source (company - Author)Elvior
Summary0007519: Ifpresent and length matching attributes not defined in XML mapping
DescriptionW3C XML mapping doesn't define support for ifpresent and length matching attributes.
+
+Proposal: extend the mapping of individual types changing the standard choice in the following way (using integer value as an example):
+
+<xsd:complexType name="IntegerValue">
+ <xsd:choice>
+  <xsd:sequence>
+   <xsd:choice>
+    <xsd:element name="value" type="SimpleTypes:TString"/>
+    <xsd:element name="matching_symbol" type="Templates:MatchingSymbol"/>
+   </xsd:choice>
+   <xsd:element name="ifpresent" type="SimpleTypes:TEmpty" minOccurs="0"/>
+   <xsd:element name="length" type="Values:LengthRestriction" minOccurs="0"/>
+  </xsd:sequence>
+  <xsd:element name="null" type="Templates:null"/>
+  <xsd:element name="omit" type="Templates:omit"/>
+  <xsd:element name="not_evaluated" type="Values:NotEvaluated"/>
+ </xsd:choice>
+ <xsd:attributeGroup ref="Values:ValueAtts"/>
+</xsd:complexType>
+
+<xsd:complexType name="TEmpty" />
+
+<xsd:complexType name="LengthRestriction">
+ <xsd:sequence>
+  <xsd:element name="lower" type="SimpleTypes:TInteger" />
+  <xsd:element name="upper" type="SimpleTypes:TInteger" minOccurs="0" />
+ </xsd:sequence>
+</xsd:complexType>
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0007512closed Tomas Urban XML mapping of matching symbols 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
25-10-2016 10:42Tomas UrbanNew Issue
14-11-2016 13:21Jens GrabowskiAssigned To => Jacob Wieland - Spirent
14-11-2016 13:21Jens GrabowskiStatusnew => assigned
24-12-2016 15:05Jens GrabowskiTarget Version => Next version (to be defined)
24-10-2017 13:13Jens GrabowskiNote Added: 0014849
26-10-2017 10:44Jacob Wieland - SpirentRelationship addedrelated to 0007512
26-10-2017 10:45Jacob Wieland - SpirentNote Added: 0014885
26-10-2017 10:45Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Tomas Urban
15-01-2018 07:54Tomas UrbanNote Added: 0015028
15-01-2018 07:54Tomas UrbanStatusassigned => closed
15-01-2018 07:54Tomas UrbanResolutionopen => fixed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014849) +
+ Jens Grabowski    +
+ 24-10-2017 13:13    +
+ 		+ + + + +
+ (To be implemented until end of 2017)
+
+
+
+ + + + + + + + + + +
+ (0014885) +
+ Jacob Wieland - Spirent    +
+ 26-10-2017 10:45    +
+ 		+ + + + +
+ I have put the proposal of solution to this issue in 7512 and added a relationship to that CR.
+
+
+
+ + + + + + + + + + +
+ (0015028) +
+ Tomas Urban    +
+ 15-01-2018 07:54    +
+ 		+ + + + +
+ Resolved together with 0007512
+
+ + diff --git a/docs/mantis/CR7520.md b/docs/mantis/CR7520.md new file mode 100644 index 0000000000000000000000000000000000000000..988b6755c470377a9f06874a2b4f9383fcf1e3e4 --- /dev/null +++ b/docs/mantis/CR7520.md @@ -0,0 +1,138 @@ + + + + + + + + + + + + + 0007520: Error in union example clause 7.5.3 - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007520Part 09: Using XML with TTCN-3Technicalpublic04-11-2016 08:5913-12-2016 20:53
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.7.1 (published 2016-07) 
Target VersionFixed in Versionv4.8.1 (published 2017-05) 
Clause Reference(s)7.5.3
For STF discussion
Source (company - Author)L.M.Ericsson
Summary0007520: Error in union example clause 7.5.3
DescriptionIn clause 7.5.3, example 2, in the translated TTCN-3 type E21unnamed_1, in the namespace as variant attribute attached to the type "http://" [^] is missing. Correctly it should be:
+   variant "namespace as 'http://www.example.org/union' [^] prefix 'ns' ";
+
+Consequently ""http://" [^] is also missing in the example XML encoding of the template, i.e. it should be:
+<?xml version="1.0" encoding="UTF-8"?>
+<ns:e21unnamed xmlns:ns='http://www.example.org/union' [^] xmlns:xsd="http://www.w3.org/2001/XMLSchema" [^] xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance' [^] xsi:type='xsd:integer'>1</ns:e21unnamed>
+
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0007470closed Gyorgy Rethy editorial: inconsistent namespace names 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
04-11-2016 08:59Gyorgy RethyNew Issue
05-11-2016 17:35Kristóf SzabadosRelationship addedrelated to 0007470
14-11-2016 13:17Jens GrabowskiAssigned To => Kristóf Szabados
14-11-2016 13:17Jens GrabowskiStatusnew => assigned
15-11-2016 10:03Kristóf SzabadosNote Added: 0014237
15-11-2016 10:05Kristóf SzabadosNote Added: 0014240
15-11-2016 10:05Kristóf SzabadosStatusassigned => resolved
15-11-2016 10:05Kristóf SzabadosFixed in Version => v4.9.1 (published 2018-05)
15-11-2016 10:05Kristóf SzabadosResolutionopen => fixed
15-11-2016 10:05Kristóf SzabadosAssigned ToKristóf Szabados => Gyorgy Rethy
13-12-2016 20:53Gyorgy RethyNote Added: 0014432
13-12-2016 20:53Gyorgy RethyStatusresolved => closed
13-12-2016 20:53Gyorgy RethyFixed in Versionv4.9.1 (published 2018-05) => v4.8.1 (published 2017-05)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014237) +
+ Kristóf Szabados    +
+ 15-11-2016 10:03    +
+ 		+ + + + +
+ already resolved as part of CR7470
+
+
+
+ + + + + + + + + + +
+ (0014240) +
+ Kristóf Szabados    +
+ 15-11-2016 10:05    +
+ 		+ + + + +
+ already resolved as part of CR7470
+
+
+
+ + + + + + + + + + +
+ (0014432) +
+ Gyorgy Rethy    +
+ 13-12-2016 20:53    +
+ 		+ + + + +
+ Resolved in CR 7470
+
+ + diff --git a/docs/mantis/CR7523.md b/docs/mantis/CR7523.md new file mode 100644 index 0000000000000000000000000000000000000000..22fd4b87900ea062df90c315125c0bc74ca02d2d --- /dev/null +++ b/docs/mantis/CR7523.md @@ -0,0 +1,99 @@ + + + + + + + + + + + + + 0007523: harmonized font for modifiers - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007523Part 01: TTCN-3 Core LanguageEditorialpublic15-11-2016 17:0113-12-2016 15:45
ReporterAxel Rennoch 
Assigned ToGyorgy Rethy 
PrioritylowSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.9.1 (published 2017-05)Fixed in Versionv4.9.1 (published 2017-05) 
Clause Reference(s)5.4.1.0, 11.0, 11.1, 11.2, 15.0, 15.5, 16.1.0, 16.1.3, 22.2.2, 22.2.3, 22.3.2, 22.3.4, 22.3.6, 22.4,
Source (company - Author)A. Rennoch (Fokus)
Summary0007523: harmonized font for modifiers
Descriptionthere are several different bold/unbold writings for the modifiers: "@" and related keywords that may be harmonized over the document for the final document version
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
15-11-2016 17:01Axel RennochNew Issue
17-11-2016 08:39Jens GrabowskiNote Added: 0014285
17-11-2016 08:39Jens GrabowskiAssigned To => Axel Rennoch
17-11-2016 08:39Jens GrabowskiStatusnew => assigned
13-12-2016 15:45Gyorgy RethyNote Added: 0014424
13-12-2016 15:45Gyorgy RethyStatusassigned => closed
13-12-2016 15:45Gyorgy RethyAssigned ToAxel Rennoch => Gyorgy Rethy
13-12-2016 15:45Gyorgy RethyResolutionopen => fixed
13-12-2016 15:45Gyorgy RethyFixed in Version => v4.9.1 (published 2017-05)
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014285) +
+ Jens Grabowski    +
+ 17-11-2016 08:39    +
+ 		+ + + + +
+ To be done at the end of editing.
+
+
+
+ + + + + + + + + + +
+ (0014424) +
+ Gyorgy Rethy    +
+ 13-12-2016 15:45    +
+ 		+ + + + +
+ Implemented in draft V4.8.2
+
+The same typographical convention is used as for keywords (courier new bold, except the BNF, where no bold font is used).
+
+ + diff --git a/docs/mantis/CR7524.md b/docs/mantis/CR7524.md new file mode 100644 index 0000000000000000000000000000000000000000..1e1e43bb3e0d75aa5225a088d5eb1bed07f61607 --- /dev/null +++ b/docs/mantis/CR7524.md @@ -0,0 +1,131 @@ + + + + + + + + + + + + + 0007524: TCI extension for multiple attributes - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007524Part 06: TTCN-3 Control InterfaceTechnicalpublic16-11-2016 11:1521-12-2016 10:15
ReporterTomas Urban 
Assigned ToTomas Urban 
PriorityhighSeveritymajorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.9.1(ongoing) 
Target Versionv4.9.1(ongoing)Fixed in Version 
Clause Reference(s)7.2.2.1, 7.2.2.2.1
Source (company - Author)STF 514
Summary0007524: TCI extension for multiple attributes
DescriptionThe new core language rules define rules for multiple encodings and attributes. The TCI interface has to be extended so that the users can receive the attributes as an array and get variants that are related to a particular encoding. In addition to that, new rules have to be added to the existing function retrieving encoding and variant attributes that would describe what happens in cases when multiple attributes of the same kind are present.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0007448closed Gyorgy Rethy Part 01: TTCN-3 Core Language Allowing multiple encodings for TTCN-3 types 
Attached Filesdocx CR7524-1.docx (227,720) 16-11-2016 14:32
http://oldforge.etsi.org/mantis/file_download.php?file_id=3537&type=bug
docx CR7524-2.docx (235,721) 16-11-2016 14:56
http://oldforge.etsi.org/mantis/file_download.php?file_id=3539&type=bug
docx CR7524-3.docx (199,008) 16-11-2016 15:11
http://oldforge.etsi.org/mantis/file_download.php?file_id=3543&type=bug
Issue History
Date ModifiedUsernameFieldChange
16-11-2016 11:15Tomas UrbanNew Issue
16-11-2016 11:15Tomas UrbanStatusnew => assigned
16-11-2016 11:15Tomas UrbanAssigned To => Tomas Urban
16-11-2016 11:15Tomas UrbanRelationship addedrelated to 0007448
16-11-2016 14:32Tomas UrbanFile Added: CR7524-1.docx
16-11-2016 14:32Tomas UrbanNote Added: 0014267
16-11-2016 14:32Tomas UrbanAssigned ToTomas Urban => Jens Grabowski
16-11-2016 14:32Tomas UrbanStatusassigned => confirmed
16-11-2016 14:56Tomas UrbanFile Added: CR7524-2.docx
16-11-2016 15:11Jens GrabowskiFile Added: CR7524-3.docx
16-11-2016 15:12Jens GrabowskiNote Added: 0014275
16-11-2016 15:12Jens GrabowskiStatusconfirmed => resolved
16-11-2016 15:12Jens GrabowskiResolutionopen => fixed
16-11-2016 15:12Jens GrabowskiAssigned ToJens Grabowski => Tomas Urban
21-12-2016 10:15Tomas UrbanNote Added: 0014464
21-12-2016 10:15Tomas UrbanStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014267) +
+ Tomas Urban    +
+ 16-11-2016 14:32    +
+ 		+ + + + +
+ Draft proposal uploaded. Please review.
+
+
+
+ + + + + + + + + + +
+ (0014275) +
+ Jens Grabowski    +
+ 16-11-2016 15:12    +
+ 		+ + + + +
+ Fixed a few typos. From my point of view ready for implementation.
+
+
+
+ + + + + + + + + + +
+ (0014464) +
+ Tomas Urban    +
+ 21-12-2016 10:15    +
+ 		+ + + + +
+ Added to draft 4.8.2
+
+ + diff --git a/docs/mantis/CR7525.md b/docs/mantis/CR7525.md new file mode 100644 index 0000000000000000000000000000000000000000..3de8a195fd8d9d0f119ca4869818bb3685a7920e --- /dev/null +++ b/docs/mantis/CR7525.md @@ -0,0 +1,137 @@ + + + + + + + + + + + + + 0007525: allow repetition (and maybe other regular expression syntax) also for binary string types - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Advanced Matching (ES 203 022)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007525Ext Pack: Advanced Matching (ES 203 022)New Featurepublic16-11-2016 13:0403-01-2018 13:04
ReporterJacob Wieland - Spirent 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv1.1.1 (published 2017-07) 
Target VersionFixed in Version 
Clause Reference(s)15.11
Source (company - Author)Spirent - Jacob Wieland
TS versionxxx
Summary0007525: allow repetition (and maybe other regular expression syntax) also for binary string types
DescriptionAt the moment, the only kinds of pattern-like syntax elements for binary string types are ? and * (matching either a single element or a sequence of unrestricted length).
+
+This leads to a restriction that for concatenation with an any template of such types, the any template can only have a fixed length restriction (which then would be replaced by a fixed amount of ? in the resulting template). This restriction then is also imposed on record of types where the original problem doesn't exist as expansion of ? length(x..y) would just be * length(x..y) inside the resulting concatenated template.
+
+With the new advanced matching features, we could lift these restrictions and map such concatenations using these features.
+
+We could also allow the same pattern syntax (or most of it) for binary string types.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0007628closed Gyorgy Rethy Part 01: TTCN-3 Core Language concatenation with wildcards should be allowed also for charstring types 
related to 0007629closed Jens Grabowski Ext Pack: Advanced Matching (ES 203 022) concatenation of arbitrary present list/string templates should be allowed 
Attached Filesdocx CR7525-v1.docx (150,031) 07-09-2017 09:32
http://oldforge.etsi.org/mantis/file_download.php?file_id=3681&type=bug
Issue History
Date ModifiedUsernameFieldChange
16-11-2016 13:04Jacob Wieland - SpirentNew Issue
17-11-2016 08:42Jens GrabowskiNote Added: 0014286
17-11-2016 08:42Jens GrabowskiAssigned To => Jens Grabowski
17-11-2016 08:42Jens GrabowskiStatusnew => assigned
04-09-2017 09:30Jens GrabowskiAssigned ToJens Grabowski => Tomas Urban
07-09-2017 09:01Tomas UrbanRelationship addedrelated to 0007628
07-09-2017 09:01Tomas UrbanRelationship addedrelated to 0007629
07-09-2017 09:32Tomas UrbanFile Added: CR7525-v1.docx
07-09-2017 09:33Tomas UrbanNote Added: 0014819
07-09-2017 09:33Tomas UrbanAssigned ToTomas Urban => Jacob Wieland - Spirent
07-09-2017 09:33Tomas UrbanStatusassigned => confirmed
24-10-2017 15:03Jacob Wieland - SpirentNote Added: 0014853
24-10-2017 15:03Jacob Wieland - SpirentStatusconfirmed => resolved
24-10-2017 15:03Jacob Wieland - SpirentFixed in Version => Next Version
24-10-2017 15:03Jacob Wieland - SpirentResolutionopen => fixed
24-10-2017 15:03Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
24-10-2017 15:03Jacob Wieland - SpirentAssigned ToGyorgy Rethy => Jens Grabowski
24-10-2017 15:03Jacob Wieland - SpirentStatusresolved => feedback
24-10-2017 15:03Jacob Wieland - SpirentResolutionfixed => reopened
24-10-2017 15:03Jacob Wieland - SpirentStatusfeedback => resolved
24-10-2017 15:03Jacob Wieland - SpirentResolutionreopened => fixed
03-01-2018 13:04Jens GrabowskiStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014286) +
+ Jens Grabowski    +
+ 17-11-2016 08:42    +
+ 		+ + + + +
+ For 2017. Proposal is missing.
+
+
+
+ + + + + + + + + + +
+ (0014819) +
+ Tomas Urban    +
+ 07-09-2017 09:33    +
+ 		+ + + + +
+ Resolution uploaded. Please check.
+
+
+
+ + + + + + + + + + +
+ (0014853) +
+ Jacob Wieland - Spirent    +
+ 24-10-2017 15:03    +
+ 		+ + + + +
+ issue is resolved
+
+ + diff --git a/docs/mantis/CR7526.md b/docs/mantis/CR7526.md new file mode 100644 index 0000000000000000000000000000000000000000..1c38d7206c26298a92e1525b86382eabad2f4053 --- /dev/null +++ b/docs/mantis/CR7526.md @@ -0,0 +1,166 @@ + + + + + + + + + + + + + 0007526: BNF correction following update in core BNF - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Config & Deployment Support (ES 202 781)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007526Ext Pack: Config & Deployment Support (ES 202 781)Editorialpublic16-11-2016 16:5823-12-2016 12:13
ReporterAxel Rennoch 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv1.4.1 (published 2015-06) 
Target Versionv1.5.1 (published 2017-05)Fixed in Versionv1.5.1 (published 2017-05) 
Clause Reference(s)A.2, A.3
Source (company - Author)A. Rennoch (Fokus)
TS versionN/A
Summary0007526: BNF correction following update in core BNF
Descriptionchange TestCaseActualParList -> ActualParList (rule 205, 903)
+consider renumbering of BNF rules
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0007492closed Gyorgy Rethy Part 01: TTCN-3 Core Language duplication and ambiguity concerning actual par lists in BNF 
Attached Filesdocx CR7526.docx (874,015) 17-11-2016 13:11
http://oldforge.etsi.org/mantis/file_download.php?file_id=3555&type=bug
docx CR7526_resolution_v2.docx (875,275) 17-11-2016 13:43
http://oldforge.etsi.org/mantis/file_download.php?file_id=3556&type=bug
docx CR7526_Config-Depl.docx (875,499) 23-12-2016 12:06
http://oldforge.etsi.org/mantis/file_download.php?file_id=3577&type=bug
Issue History
Date ModifiedUsernameFieldChange
16-11-2016 16:58Axel RennochNew Issue
16-11-2016 16:58Axel RennochStatusnew => assigned
16-11-2016 16:58Axel RennochAssigned To => Axel Rennoch
17-11-2016 11:37Axel RennochRelationship addedrelated to 0007492
17-11-2016 13:11Axel RennochFile Added: CR7526.docx
17-11-2016 13:12Axel RennochNote Added: 0014302
17-11-2016 13:43Axel RennochFile Added: CR7526_resolution_v2.docx
17-11-2016 13:44Axel RennochNote Added: 0014303
17-11-2016 14:06Axel RennochAssigned ToAxel Rennoch => Kristóf Szabados
17-11-2016 14:06Axel RennochNote Added: 0014308
17-11-2016 14:06Axel RennochStatusassigned => confirmed
17-11-2016 15:59Kristóf SzabadosNote Added: 0014319
17-11-2016 15:59Kristóf SzabadosStatusconfirmed => resolved
17-11-2016 15:59Kristóf SzabadosFixed in Version => v1.5.1 (published 2017-05)
17-11-2016 15:59Kristóf SzabadosResolutionopen => fixed
17-11-2016 15:59Kristóf SzabadosAssigned ToKristóf Szabados => Jens Grabowski
23-12-2016 12:06Jens GrabowskiFile Added: CR7526_Config-Depl.docx
23-12-2016 12:13Jens GrabowskiStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014302) +
+ Axel Rennoch    +
+ 17-11-2016 13:12    +
+ 		+ + + + +
+ BNF has been corrected and rules renumbered following the core BNF
+
+
+
+ + + + + + + + + + +
+ (0014303) +
+ Axel Rennoch    +
+ 17-11-2016 13:44    +
+ 		+ + + + +
+ use of "781" prefix for all new BNF rules
+
+
+
+ + + + + + + + + + +
+ (0014308) +
+ Axel Rennoch    +
+ 17-11-2016 14:06    +
+ 		+ + + + +
+ please have a final look and assign/resolve to the editor Jens
+
+
+
+ + + + + + + + + + +
+ (0014319) +
+ Kristóf Szabados    +
+ 17-11-2016 15:59    +
+ 		+ + + + +
+ looks good to me. In line with the rule numbers listed in document attached to CR7492, with name CR7492_resolution_v3.doc
+
+ + diff --git a/docs/mantis/CR7527.md b/docs/mantis/CR7527.md new file mode 100644 index 0000000000000000000000000000000000000000..3bd47bb416edaeb1d290ec7734d80102125756d3 --- /dev/null +++ b/docs/mantis/CR7527.md @@ -0,0 +1,169 @@ + + + + + + + + + + + + + 0007527: BNF correction following update in core BNF - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Advanced Parametrization (ES 202 784)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007527Ext Pack: Advanced Parametrization (ES 202 784)Editorialpublic17-11-2016 08:2216-12-2016 20:18
ReporterAxel Rennoch 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv1.5.1 (published 2015-06) 
Target Versionv1.6.1 (published 2017-04)Fixed in Versionv1.6.1 (published 2017-04) 
TS versionN/A
Clause Reference(s)5.5
Source (company - Author)A. Rennoch (Fokus)
Summary0007527: BNF correction following update in core BNF
Descriptionchange FunctionActualParList -> ActualParList (rule 170, 196)
+change TestCaseActualParList -> ActualParList (rule 189)
+consider renumbering of BNF rules
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0007492closed Gyorgy Rethy Part 01: TTCN-3 Core Language duplication and ambiguity concerning actual par lists in BNF 
Attached Filesdocx CR7527.docx (155,824) 17-11-2016 14:43
http://oldforge.etsi.org/mantis/file_download.php?file_id=3558&type=bug
Issue History
Date ModifiedUsernameFieldChange
17-11-2016 08:22Axel RennochNew Issue
17-11-2016 08:22Axel RennochStatusnew => assigned
17-11-2016 08:22Axel RennochAssigned To => Axel Rennoch
17-11-2016 11:38Axel RennochRelationship addedrelated to 0007492
17-11-2016 14:43Axel RennochFile Added: CR7527.docx
17-11-2016 14:44Axel RennochNote Added: 0014315
17-11-2016 14:44Axel RennochAssigned ToAxel Rennoch => Kristóf Szabados
17-11-2016 14:45Axel RennochNote Added: 0014316
17-11-2016 14:45Axel RennochStatusassigned => confirmed
17-11-2016 15:43Kristóf SzabadosNote Added: 0014318
17-11-2016 15:43Kristóf SzabadosStatusconfirmed => resolved
17-11-2016 15:43Kristóf SzabadosFixed in Version => v1.6.1 (published 2017-04)
17-11-2016 15:43Kristóf SzabadosResolutionopen => fixed
17-11-2016 15:43Kristóf SzabadosAssigned ToKristóf Szabados => Jens Grabowski
16-12-2016 20:18Gyorgy RethyNote Added: 0014452
16-12-2016 20:18Gyorgy RethyStatusresolved => closed
16-12-2016 20:18Gyorgy RethyAssigned ToJens Grabowski => Gyorgy Rethy
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014315) +
+ Axel Rennoch    +
+ 17-11-2016 14:44    +
+ 		+ + + + +
+ correction of BNF rules
+correction of numbers of core BNF rules
+removal of hyperlinks in BNF
+
+
+
+ + + + + + + + + + +
+ (0014316) +
+ Axel Rennoch    +
+ 17-11-2016 14:45    +
+ 		+ + + + +
+ please have a final look and assign/resolve to editor Jens
+
+
+
+ + + + + + + + + + +
+ (0014318) +
+ Kristóf Szabados    +
+ 17-11-2016 15:43    +
+ 		+ + + + +
+ in line with the rule number listed in document attached to CR7492, with name CR7492_resolution_v3.doc
+
+
+
+ + + + + + + + + + +
+ (0014452) +
+ Gyorgy Rethy    +
+ 16-12-2016 20:18    +
+ 		+ + + + +
+ Added to draft V1.5.3
+
+ + diff --git a/docs/mantis/CR7528.md b/docs/mantis/CR7528.md new file mode 100644 index 0000000000000000000000000000000000000000..04a7212d364059e87d8b632f3a5a858eab123559 --- /dev/null +++ b/docs/mantis/CR7528.md @@ -0,0 +1,99 @@ + + + + + + + + + + + + + 0007528: BNF correction following update in core BNF - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Behaviour Types (ES 202 785)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007528Ext Pack: Behaviour Types (ES 202 785)Editorialpublic17-11-2016 08:2516-12-2016 21:58
ReporterAxel Rennoch 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv1.4.1 (published 2015-06) 
Target Versionv1.5.1 (published 2017-08)Fixed in Versionv1.5.1 (published 2017-08) 
Clause Reference(s)5.13.1
Source (company - Author)A. Rennoch (Fokus)
Summary0007528: BNF correction following update in core BNF
Descriptionchange FunctionActualParList -> ActualParList (rule 170, 196)
+change TestCaseActualParList -> ActualParList (rule 189)
+consider renumbering of BNF rules
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0007492closed Gyorgy Rethy Part 01: TTCN-3 Core Language duplication and ambiguity concerning actual par lists in BNF 
Attached Filesdocx CR7528.docx (527,139) 17-11-2016 15:36
http://oldforge.etsi.org/mantis/file_download.php?file_id=3559&type=bug
Issue History
Date ModifiedUsernameFieldChange
17-11-2016 08:25Axel RennochNew Issue
17-11-2016 08:25Axel RennochStatusnew => assigned
17-11-2016 08:25Axel RennochAssigned To => Axel Rennoch
17-11-2016 11:38Axel RennochRelationship addedrelated to 0007492
17-11-2016 15:36Axel RennochFile Added: CR7528.docx
17-11-2016 15:38Axel RennochAssigned ToAxel Rennoch => Kristof.Szabados
17-11-2016 15:38Axel RennochNote Added: 0014317
17-11-2016 15:38Axel RennochStatusassigned => confirmed
16-12-2016 21:58Gyorgy RethyNote Added: 0014456
16-12-2016 21:58Gyorgy RethyStatusconfirmed => closed
16-12-2016 21:58Gyorgy RethyAssigned ToKristof.Szabados => Gyorgy Rethy
16-12-2016 21:58Gyorgy RethyResolutionopen => fixed
16-12-2016 21:58Gyorgy RethyFixed in Version => v1.5.1 (published 2017-08)
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014317) +
+ Axel Rennoch    +
+ 17-11-2016 15:38    +
+ 		+ + + + +
+ please have a final lookk and assign/resolve to editor Jens
+
+
+
+ + + + + + + + + + +
+ (0014456) +
+ Gyorgy Rethy    +
+ 16-12-2016 21:58    +
+ 		+ + + + +
+ Added to draft V1.4.2
+
+ + diff --git a/docs/mantis/CR7529.md b/docs/mantis/CR7529.md new file mode 100644 index 0000000000000000000000000000000000000000..c842f8ce648181adbdd5de76edab038d9681f816 --- /dev/null +++ b/docs/mantis/CR7529.md @@ -0,0 +1,169 @@ + + + + + + + + + + + + + 0007529: BNF correction following update in core BNF - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Continuous signal support (ES 202 786)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007529Ext Pack: Continuous signal support (ES 202 786)Editorialpublic17-11-2016 08:3023-12-2016 11:45
ReporterAxel Rennoch 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv1.3.1 (published 2015-06) 
Target Versionv1.4.1 (ongoing)Fixed in Version 
Summary0007529: BNF correction following update in core BNF
Descriptionsection A.3:
+============
+change FunctionActualParList -> ActualParList (rule 71)
+consider renumbering of BNF rules
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0007492closed Gyorgy Rethy Part 01: TTCN-3 Core Language duplication and ambiguity concerning actual par lists in BNF 
Attached Filesdocx CR7529.docx (253,346) 18-11-2016 09:15
http://oldforge.etsi.org/mantis/file_download.php?file_id=3563&type=bug
docx CR7529-ContSignals.docx (251,431) 23-12-2016 11:31
http://oldforge.etsi.org/mantis/file_download.php?file_id=3576&type=bug
Issue History
Date ModifiedUsernameFieldChange
17-11-2016 08:30Axel RennochNew Issue
17-11-2016 08:30Axel RennochStatusnew => assigned
17-11-2016 08:30Axel RennochAssigned To => Axel Rennoch
17-11-2016 11:38Axel RennochRelationship addedrelated to 0007492
18-11-2016 09:15Axel RennochFile Added: CR7529.docx
18-11-2016 09:18Axel RennochNote Added: 0014324
18-11-2016 09:18Axel RennochAssigned ToAxel Rennoch => Kristof.Szabados
18-11-2016 09:18Axel RennochNote Added: 0014325
18-11-2016 09:18Axel RennochStatusassigned => confirmed
18-11-2016 10:23Kristóf SzabadosNote Added: 0014329
18-11-2016 10:26Axel RennochAssigned ToKristof.Szabados => Jens Grabowski
18-11-2016 10:26Axel RennochStatusconfirmed => assigned
18-11-2016 10:26Axel RennochNote Added: 0014330
18-11-2016 10:26Axel RennochStatusassigned => resolved
18-11-2016 10:26Axel RennochResolutionopen => fixed
23-12-2016 11:31Jens GrabowskiFile Added: CR7529-ContSignals.docx
23-12-2016 11:45Jens GrabowskiStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014324) +
+ Axel Rennoch    +
+ 18-11-2016 09:18    +
+ 		+ + + + +
+ BNF has been corrected and rules renumbered following the core BNF
+use of "786" prefix for all new BNF rules
+
+
+
+ + + + + + + + + + +
+ (0014325) +
+ Axel Rennoch    +
+ 18-11-2016 09:18    +
+ 		+ + + + +
+ please have a final look and assign/resolve to the editor Jens
+
+
+
+ + + + + + + + + + +
+ (0014329) +
+ Kristóf Szabados    +
+ 18-11-2016 10:23    +
+ 		+ + + + +
+ looks good to me. In line with the rule numbers listed in document attached to CR7492, with name CR7492_resolution_v3.doc
+
+
+
+ + + + + + + + + + +
+ (0014330) +
+ Axel Rennoch    +
+ 18-11-2016 10:26    +
+ 		+ + + + +
+ resolved by Kristof
+
+ + diff --git a/docs/mantis/CR7530.md b/docs/mantis/CR7530.md new file mode 100644 index 0000000000000000000000000000000000000000..1a664b21b84abcde750c2ca0b17164188746cc70 --- /dev/null +++ b/docs/mantis/CR7530.md @@ -0,0 +1,393 @@ + + + + + + + + + + + + + 0007530: keywords should be escapable to be used as a TTCN-3 identifier. - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007530Part 01: TTCN-3 Core LanguageNew Featurepublic17-11-2016 16:3030-12-2017 15:41
ReporterJacob Wieland - Spirent 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionno change required 
PlatformOSOS Version
Product Version 
Target Versionv4.10.1 (published 2018-05)Fixed in Version 
Clause Reference(s)Appendix A.1.3
Source (company - Author)Spirent - Jacob Wieland
Summary0007530: keywords should be escapable to be used as a TTCN-3 identifier.
DescriptionNowadays, it is possible that an old module for a previous version of TTCN-3 is imported into a module with a newer language tag or that uses packages that the imported module does not use.
+
+This can lead to the situation that in the newer/more-package-heavy module some identifiers that are totally valid identifiers in the other module are keywords and thus, not valid identifiers anymore.
+
+The importing module would then not be able to reference the imported items.
+
+To solve this problem, an identifier escape mechanism should be introduced so that the importing module can use the escape-notation when using an identifier from the imported module that is a keyword in the importing one.
+
+A simple solution would be to allow the identifier to be put into single tick characters (same as octetstring etc):
+
+'value'
+.
+This syntax can be used everywhere that an identifier can be used, e.g.
+
+t.'value'
+
+On the lexer-level there is unfortunately a prefix-overlap with octetstring and hexstring literals that start with digits above 9 (i.e. A B C D E F), but since the new syntax would not end in 'O or 'H, this lexical issue can be resolved.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0007683closed Gyorgy Rethy Keywords (from packages) should be reserved in the Core Standard. 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
17-11-2016 16:30Jacob Wieland - SpirentNew Issue
17-11-2016 16:30Jacob Wieland - SpirentStatusnew => assigned
17-11-2016 16:30Jacob Wieland - SpirentAssigned To => Jacob Wieland - Spirent
24-12-2016 15:03Jens GrabowskiProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
24-12-2016 15:03Jens GrabowskiTarget Version => v4.10.1 (published 2018-05)
17-04-2017 15:13szabadosNote Added: 0014563
17-04-2017 15:13szabadosNote Deleted: 0014563
18-04-2017 15:21szabadosNote Added: 0014575
18-04-2017 15:24szabadosNote Added: 0014576
19-04-2017 11:53Jacob Wieland - SpirentNote Added: 0014579
19-04-2017 11:54Jacob Wieland - SpirentNote Added: 0014580
19-04-2017 11:54Jacob Wieland - SpirentNote Added: 0014581
19-04-2017 11:54Jacob Wieland - SpirentNote Added: 0014582
19-04-2017 11:55Jacob Wieland - SpirentNote Added: 0014583
19-04-2017 11:56Jacob Wieland - SpirentNote Added: 0014584
19-04-2017 11:56Jacob Wieland - SpirentNote Added: 0014585
19-04-2017 14:39Jacob Wieland - SpirentNote Added: 0014586
19-04-2017 14:39Jacob Wieland - SpirentNote Deleted: 0014586
09-06-2017 15:39Jacob Wieland - SpirentRelationship addedrelated to 0007683
26-07-2017 14:08Jacob Wieland - SpirentNote Added: 0014783
26-07-2017 14:08Jacob Wieland - SpirentStatusassigned => resolved
26-07-2017 14:08Jacob Wieland - SpirentResolutionopen => no change required
24-10-2017 13:57Jens GrabowskiAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
24-10-2017 13:57Jens GrabowskiStatusresolved => assigned
24-10-2017 13:58Jens GrabowskiStatusassigned => resolved
30-12-2017 15:41Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014575) +
+ szabados    +
+ 18-04-2017 15:21    +
+ 		+ + + + +
+ What was the original issue here?
+It sound like we need some mapping rules between the language versions in question. Like private to _private.
+
+I believe introducing a new sort of identifiers or way of writing identifiers could be an overkill if the actual issue only needs a transformation.
+
+
+
+ + + + + + + + + + +
+ (0014576) +
+ szabados    +
+ 18-04-2017 15:24    +
+ 		+ + + + +
+ Or it would be even better to ask users to upgrade their old modules.
+Mixing different language versions in the same project can be dangerous if users do not check the language identifier in each module before they change it.
+Also if users are not perfectly sure in the minute differences in each language version they are using.
+
+Would it be a good idea to include support for very old language version into the list of features that can be deprecated?
+What do you think, if the standard would only support old version only up to a specified time or version number difference - like usually done with software - would that be a good incentive for users to upgrade?
+
+
+
+ + + + + + + + + + +
+ (0014579) +
+ Jacob Wieland - Spirent    +
+ 19-04-2017 11:53    +
+ 		+ + + + +
+ I think I made the case pretty clear
+
+
+
+ + + + + + + + + + +
+ (0014580) +
+ Jacob Wieland - Spirent    +
+ 19-04-2017 11:54    +
+ 		+ + + + +
+ Module M1 that has package A with keyword X imports module M2 without package A e.g. just a normal XSD import. In the imported module, the identifier X will not be quoted as in that context, X is nothing special. But, in module M1 you cannot use X as identifier as it is a keyword.
+
+
+
+ + + + + + + + + + +
+ (0014581) +
+ Jacob Wieland - Spirent    +
+ 19-04-2017 11:54    +
+ 		+ + + + +
+ To still access the X, you need to quote it somehow. The proposed syntax for quoting X would be a normal quoting mechanism for identifiers that other languages allow. Prefixing with a dollar or a backslash could also work, but personally, I prefer the proposed option the most.
+
+
+
+ + + + + + + + + + +
+ (0014582) +
+ Jacob Wieland - Spirent    +
+ 19-04-2017 11:54    +
+ 		+ + + + +
+ Otherwise, there would need to be a mechanism that you can import an external language module with additional package options so that the mapping can take those into account.
+
+
+
+ + + + + + + + + + +
+ (0014583) +
+ Jacob Wieland - Spirent    +
+ 19-04-2017 11:55    +
+ 		+ + + + +
+ The same applies when you are using code you have no control over, like a library or a standardized test suite part that you are not allowed to change.
+
+
+
+ + + + + + + + + + +
+ (0014584) +
+ Jacob Wieland - Spirent    +
+ 19-04-2017 11:56    +
+ 		+ + + + +
+ Simply asking the user to change the problematic code isn't always an option.
+
+
+
+ + + + + + + + + + +
+ (0014585) +
+ Jacob Wieland - Spirent    +
+ 19-04-2017 11:56    +
+ 		+ + + + +
+ There is no actual real-life use-case for this, but the problem occurred to me at some point and I wanted to address it.
+
+
+
+ + + + + + + + + + +
+ (0014783) +
+ Jacob Wieland - Spirent    +
+ 26-07-2017 14:08    +
+ 		+ + + + +
+ With the solution that all keywords of packages shall also be reserved in the core document, this issue cannot happen anymore, so no change is required to address it.
+
+ + diff --git a/docs/mantis/CR7531.md b/docs/mantis/CR7531.md new file mode 100644 index 0000000000000000000000000000000000000000..c1fecb8bf25844d32f799a991cf126512ca258fb --- /dev/null +++ b/docs/mantis/CR7531.md @@ -0,0 +1,97 @@ + + + + + + + + + + + + + 0007531: Checking and Harmonization of BNF for the Advanced Matching Extension Package - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Advanced Matching (ES 203 022)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007531Ext Pack: Advanced Matching (ES 203 022)Technicalpublic18-11-2016 10:2524-12-2016 11:52
ReporterJens Grabowski 
Assigned ToJens Grabowski 
PriorityhighSeveritymajorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv1.1.1 (published 2017-07) 
Target Versionv1.1.1 (published 2017-07)Fixed in Version 
Clause Reference(s)Annex A
Source (company - Author)STF 514
TS versionN/A
Summary0007531: Checking and Harmonization of BNF for the Advanced Matching Extension Package
DescriptionBNF of all CRs related to the Advanced Matching Extension Package has to be checked and harmonized.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx BNF-Advanced-Matching.docx (130,666) 18-11-2016 10:25
http://oldforge.etsi.org/mantis/file_download.php?file_id=3566&type=bug
docx CR7531.docx (143,700) 18-11-2016 11:21
http://oldforge.etsi.org/mantis/file_download.php?file_id=3571&type=bug
Issue History
Date ModifiedUsernameFieldChange
18-11-2016 10:25Jens GrabowskiNew Issue
18-11-2016 10:25Jens GrabowskiStatusnew => assigned
18-11-2016 10:25Jens GrabowskiAssigned To => Axel Rennoch
18-11-2016 10:25Jens GrabowskiFile Added: BNF-Advanced-Matching.docx
18-11-2016 11:21Axel RennochFile Added: CR7531.docx
18-11-2016 11:22Axel RennochNote Added: 0014336
18-11-2016 11:22Axel RennochAssigned ToAxel Rennoch => Jens Grabowski
18-11-2016 11:23Axel RennochNote Added: 0014337
18-11-2016 11:23Axel RennochStatusassigned => confirmed
24-12-2016 11:52Jens GrabowskiStatusconfirmed => closed
24-12-2016 11:52Jens GrabowskiResolutionopen => fixed
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014336) +
+ Axel Rennoch    +
+ 18-11-2016 11:22    +
+ 		+ + + + +
+ BNF parts renumbered and checked with the tool.
+
+
+
+ + + + + + + + + + +
+ (0014337) +
+ Axel Rennoch    +
+ 18-11-2016 11:23    +
+ 		+ + + + +
+ BNF ready for inclusion to the final draft
+
+ + diff --git a/docs/mantis/CR7552.md b/docs/mantis/CR7552.md new file mode 100644 index 0000000000000000000000000000000000000000..0a630e0c133a1971b22c8ff9715d7e9821caa6df --- /dev/null +++ b/docs/mantis/CR7552.md @@ -0,0 +1,131 @@ + + + + + + + + + + + + + 0007552: Invalid C# mapping of tliRnd - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007552Part 06: TTCN-3 Control InterfaceEditorialpublic22-11-2016 09:2602-01-2018 12:24
ReporterTomas Urban 
Assigned ToTomas Urban 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.8.1 (published 2016-07) 
Target VersionFixed in Version 
Clause Reference(s)12.5.4.1
Source (company - Author)Elvior
Summary0007552: Invalid C# mapping of tliRnd
DescriptionFloat value parameters in the C# ITciTLProvided.TliRnd methods have incorrect class. Instead of FloatValue, ITciFloatValue should be used.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc 7552.doc (56,832) 07-06-2017 13:50
http://oldforge.etsi.org/mantis/file_download.php?file_id=3606&type=bug
Issue History
Date ModifiedUsernameFieldChange
22-11-2016 09:26Tomas UrbanNew Issue
06-06-2017 15:13Jens GrabowskiAssigned To => Julien Deltour
06-06-2017 15:13Jens GrabowskiStatusnew => assigned
07-06-2017 13:50Julien DeltourFile Added: 7552.doc
07-06-2017 13:50Julien DeltourNote Added: 0014649
07-06-2017 13:50Julien DeltourAssigned ToJulien Deltour => Tomas Urban
08-06-2017 08:46Jacob Wieland - SpirentStatusassigned => confirmed
08-06-2017 16:06Tomas UrbanNote Added: 0014657
08-06-2017 16:06Tomas UrbanStatusconfirmed => resolved
08-06-2017 16:06Tomas UrbanResolutionopen => fixed
02-01-2018 12:24Tomas UrbanNote Added: 0014978
02-01-2018 12:24Tomas UrbanStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014649) +
+ Julien Deltour    +
+ 07-06-2017 13:50    +
+ 		+ + + + +
+ Please check for resolution.
+
+
+
+ + + + + + + + + + +
+ (0014657) +
+ Tomas Urban    +
+ 08-06-2017 16:06    +
+ 		+ + + + +
+ The proposed resolution is ready to be added to the next version of the standard.
+
+
+
+ + + + + + + + + + +
+ (0014978) +
+ Tomas Urban    +
+ 02-01-2018 12:24    +
+ 		+ + + + +
+ Implemented in draft V4.9.2
+
+ + diff --git a/docs/mantis/CR7553.md b/docs/mantis/CR7553.md new file mode 100644 index 0000000000000000000000000000000000000000..280b2b3bd5dd2530bd07ec1fdb5b483fb755cb4a --- /dev/null +++ b/docs/mantis/CR7553.md @@ -0,0 +1,131 @@ + + + + + + + + + + + + + 0007553: Invalid return type in java MatchingMechanism.getMatchingType() - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007553Part 06: TTCN-3 Control InterfaceTechnicalpublic23-11-2016 08:4102-01-2018 12:27
ReporterTomas Urban 
Assigned ToTomas Urban 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.8.1 (published 2016-07) 
Target VersionFixed in Version 
Clause Reference(s)8.3.5.1
Source (company - Author)Elvior
Summary0007553: Invalid return type in java MatchingMechanism.getMatchingType()
DescriptionThe return type of MatchingMechanism.getMatchingType function should be int in java. For reference, see how Type.getTypeClass() is mapped to java.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc 7553.doc (11,776) 09-06-2017 08:31
http://oldforge.etsi.org/mantis/file_download.php?file_id=3621&type=bug
Issue History
Date ModifiedUsernameFieldChange
23-11-2016 08:41Tomas UrbanNew Issue
06-06-2017 15:12Jens GrabowskiAssigned To => Julien Deltour
06-06-2017 15:12Jens GrabowskiStatusnew => assigned
07-06-2017 09:40Julien DeltourNote Added: 0014639
09-06-2017 08:25Julien DeltourNote Deleted: 0014639
09-06-2017 08:31Julien DeltourFile Added: 7553.doc
09-06-2017 08:32Julien DeltourNote Added: 0014674
09-06-2017 08:32Julien DeltourStatusassigned => confirmed
09-06-2017 08:32Julien DeltourAssigned ToJulien Deltour => Tomas Urban
09-06-2017 08:32Julien DeltourStatusconfirmed => assigned
09-06-2017 08:52Tomas UrbanNote Added: 0014683
09-06-2017 08:52Tomas UrbanStatusassigned => resolved
09-06-2017 08:52Tomas UrbanResolutionopen => fixed
02-01-2018 12:27Tomas UrbanNote Added: 0014980
02-01-2018 12:27Tomas UrbanStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014674) +
+ Julien Deltour    +
+ 09-06-2017 08:32    +
+ 		+ + + + +
+ please review the proposal
+
+
+
+ + + + + + + + + + +
+ (0014683) +
+ Tomas Urban    +
+ 09-06-2017 08:52    +
+ 		+ + + + +
+ Ready to be added to the new version of the specification.
+
+
+
+ + + + + + + + + + +
+ (0014980) +
+ Tomas Urban    +
+ 02-01-2018 12:27    +
+ 		+ + + + +
+ Implemented in draft V4.9.2
+
+ + diff --git a/docs/mantis/CR7554.md b/docs/mantis/CR7554.md new file mode 100644 index 0000000000000000000000000000000000000000..8d25f5c5b05e0583f51a803e63b4b97b6e8c4b06 --- /dev/null +++ b/docs/mantis/CR7554.md @@ -0,0 +1,131 @@ + + + + + + + + + + + + + 0007554: Wrong text in the list of C# abstract data type Value mapping - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007554Part 06: TTCN-3 Control InterfaceEditorialpublic23-11-2016 09:2902-01-2018 12:26
ReporterTomas Urban 
Assigned ToTomas Urban 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.8.1 (published 2016-07) 
Target VersionFixed in Version 
Clause Reference(s)12.4.4.1
Source (company - Author)Elvior
Summary0007554: Wrong text in the list of C# abstract data type Value mapping
DescriptionThe method IsMatchingSymbol is called NotPresent in the description section (copy/paste error).
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc 7554.doc (17,920) 07-06-2017 13:49
http://oldforge.etsi.org/mantis/file_download.php?file_id=3605&type=bug
Issue History
Date ModifiedUsernameFieldChange
23-11-2016 09:29Tomas UrbanNew Issue
06-06-2017 15:12Jens GrabowskiAssigned To => Julien Deltour
06-06-2017 15:12Jens GrabowskiStatusnew => assigned
07-06-2017 13:49Julien DeltourFile Added: 7554.doc
07-06-2017 13:49Julien DeltourNote Added: 0014648
07-06-2017 13:49Julien DeltourAssigned ToJulien Deltour => Tomas Urban
08-06-2017 08:47Jacob Wieland - SpirentStatusassigned => confirmed
08-06-2017 16:07Tomas UrbanNote Added: 0014658
08-06-2017 16:07Tomas UrbanStatusconfirmed => resolved
08-06-2017 16:07Tomas UrbanResolutionopen => fixed
02-01-2018 12:26Tomas UrbanNote Added: 0014979
02-01-2018 12:26Tomas UrbanStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014648) +
+ Julien Deltour    +
+ 07-06-2017 13:49    +
+ 		+ + + + +
+ Please check for resolution.
+
+
+
+ + + + + + + + + + +
+ (0014658) +
+ Tomas Urban    +
+ 08-06-2017 16:07    +
+ 		+ + + + +
+ The proposed resolution is ready to be added to the next version of the standard.
+
+
+
+ + + + + + + + + + +
+ (0014979) +
+ Tomas Urban    +
+ 02-01-2018 12:26    +
+ 		+ + + + +
+ Implemented in draft V4.9.2
+
+ + diff --git a/docs/mantis/CR7561.md b/docs/mantis/CR7561.md new file mode 100644 index 0000000000000000000000000000000000000000..c959c53ab8b2f269a8a10ec24a7bf124ede2a6ed --- /dev/null +++ b/docs/mantis/CR7561.md @@ -0,0 +1,147 @@ + + + + + + + + + + + + + 0007561: Allow finally block or shutdown hook - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Object-oriented features (ES 203 790)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007561Ext Pack: Object-oriented features (ES 203 790)[All Projects] Generalpublic07-12-2016 16:3418-04-2018 09:52
ReporterJacob Wieland - Spirent 
Assigned ToKristóf Szabados 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0007561: Allow finally block or shutdown hook
DescriptionAt the moment, it is not possible for a test case (or a behavior in general) to clean up after itself in case that it does not terminate but is stopped from the outside (either by the control part that started it due to timeout or if testcase.stop is called or if some testcase error occurs).
+
+Consider a testcase that stores some information in a database (or the cloud) and at the end wants to remove that information again, so it can be run again. At the moment, if anything goes wrong in the testcase, no cleanup inside the testcase is possible anymore, so that needs to be shifted into the test adaptation or to the beginning of the testcase into some cleanup-preamble. All these approaches have the drawback that they are not explicit and information about what to clean up needs to flow either to the adaptation or to the next invocation of the testcase.
+
+To avoid such obvious workarounds, we should introduce a concept of statements that are executed whenever a testcase/component/behavior ends.
+
+One idea would be the introduction of a *finally* block which can be the last statement of the testcase body:
+
+testcase T() ... {
+  var charstring cleanupId;
+  ...
+  finally {
+    cleanup(cleanupId);
+  }
+}
+
+Another idea would be the resgistration of a shutdown hook similar to the activate statement (or the activate statement could be enhanced for this capability) that is invoked whenever a component terminates or dies. Of course, that shutdown hook can only access the component variables while the finally block could also access the local variables.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0007692closed Kristóf Szabados Exception handling with less code and less performance overhead 
related to 0007731closed Jens Grabowski Draft document for Object-oriented Extension 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
07-12-2016 16:34Jacob Wieland - SpirentNew Issue
06-06-2017 15:09Jens GrabowskiAssigned To => Jens Grabowski
06-06-2017 15:09Jens GrabowskiStatusnew => assigned
06-06-2017 15:10Jens GrabowskiNote Added: 0014635
27-07-2017 15:45Jens GrabowskiProjectPart 01: TTCN-3 Core Language => Ext Pack: Object-oriented features (ES 203 790)
27-07-2017 15:45Jens GrabowskiCategoryNew Feature => General
28-07-2017 12:28Jens GrabowskiAssigned ToJens Grabowski => Kristof.Szabados
28-07-2017 12:29Jens GrabowskiRelationship addedrelated to 0007692
28-07-2017 12:40Jens GrabowskiAssigned ToKristof.Szabados => Kristóf Szabados
27-10-2017 11:23Kristóf SzabadosNote Added: 0014911
18-04-2018 08:34Kristóf SzabadosRelationship addedrelated to 0007731
18-04-2018 09:52Kristóf SzabadosNote Added: 0015097
18-04-2018 09:52Kristóf SzabadosStatusassigned => closed
18-04-2018 09:52Kristóf SzabadosResolutionopen => fixed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014635) +
+ Jens Grabowski    +
+ 06-06-2017 15:10    +
+ 		+ + + + +
+ STF discussion: possible ways for implementation, e.g., exception handling, destructor (in OO)
+
+
+
+ + + + + + + + + + +
+ (0014911) +
+ Kristóf Szabados    +
+ 27-10-2017 11:23    +
+ 		+ + + + +
+ This CR will be resolved as part of CR7692
+
+
+
+ + + + + + + + + + +
+ (0015097) +
+ Kristóf Szabados    +
+ 18-04-2018 09:52    +
+ 		+ + + + +
+ Solved as part of the OO extension (CR 7731)
+
+ + diff --git a/docs/mantis/CR7562.md b/docs/mantis/CR7562.md new file mode 100644 index 0000000000000000000000000000000000000000..194f41cff1bb31a2e4e506e163826a6b94596687 --- /dev/null +++ b/docs/mantis/CR7562.md @@ -0,0 +1,265 @@ + + + + + + + + + + + + + 0007562: Clarification of order of XML to TTCN3 type conversion - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007562Part 09: Using XML with TTCN-3Clarificationpublic08-12-2016 15:4205-01-2018 11:55
ReporterHellen Griffiths 
Assigned ToGyorgy Rethy 
PriorityhighSeveritymajorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.8.1 (published 2017-05) 
Target Versionv4.9.1 (published 2018-05)Fixed in Versionv4.9.1 (published 2018-05) 
Clause Reference(s)5.2.2, 7.1.4
For STF discussion
Source (company - Author)     ETSI MCC TF160
Summary0007562: Clarification of order of XML to TTCN3 type conversion
DescriptionThe attached file includes the type definition 'UsageInformationReport-Info'. This complex type includes the field 'group'. When this file is translated into TTCN3, some tools convert this to 'group_list', whilst others convert this to 'group__list'. This means that MCC TF160 cannot refer to this field without causing an error in at least one tool that we support.
+
+The order different sections must be run when converting XML types is not clear in the TTCN3 standard. It must be clarified e.g. that clause 5.2.2 should be run last.
Steps To Reproduce-Start with the XML field name 'group'.
+Clause 5.2.2 clearly states that the naming rules must be followed in order. Rule d) specifies that a sequence of two or more low line characters must be replaced with a single low line characters.
+- Still have field name 'group'.
+Rule l) specifies if a name is the same as a TTCN3 keyword, a single low line character must be appended.
+- Now have 'group_'
+Finally, clause 7.1.4 specifies the postfix '_list' must be added for maxOccurs>1.
+- Result is 'group__list'
Additional Information
TagsNo tags attached.
Relationships
Attached Files? 24334_ProSePC3ch.xsd (9,779) 08-12-2016 15:42
http://oldforge.etsi.org/mantis/file_download.php?file_id=3575&type=bug
docx CR_7562.docx (543,068) 08-06-2017 14:17
http://oldforge.etsi.org/mantis/file_download.php?file_id=3607&type=bug
docx CR_7562_v2.docx (168,176) 09-06-2017 16:00
http://oldforge.etsi.org/mantis/file_download.php?file_id=3639&type=bug
Issue History
Date ModifiedUsernameFieldChange
08-12-2016 15:42Hellen GriffithsNew Issue
08-12-2016 15:42Hellen GriffithsFile Added: 24334_ProSePC3ch.xsd
07-04-2017 06:43travm1Note Added: 0014551
17-04-2017 14:33szabadosNote Added: 0014561
06-06-2017 14:13Jens GrabowskiProjectTTCN-3 Change Requests => Part 09: Using XML with TTCN-3
06-06-2017 14:17Jens GrabowskiNote Added: 0014630
06-06-2017 14:20Jens GrabowskiNote Edited: 0014630bug_revision_view_page.php?bugnote_id=14630#r417
06-06-2017 14:20Jens GrabowskiAssigned To => Kristóf Szabados
06-06-2017 14:20Jens GrabowskiStatusnew => assigned
08-06-2017 14:17Kristóf SzabadosFile Added: CR_7562.docx
09-06-2017 15:48Kristóf SzabadosNote Added: 0014704
09-06-2017 15:48Kristóf SzabadosAssigned ToKristóf Szabados => Jacob Wieland - Spirent
09-06-2017 15:48Kristóf SzabadosStatusassigned => confirmed
09-06-2017 16:00Kristóf SzabadosFile Added: CR_7562_v2.docx
09-06-2017 16:01Kristóf SzabadosNote Added: 0014705
24-07-2017 15:02Jacob Wieland - SpirentStatusconfirmed => resolved
24-07-2017 15:02Jacob Wieland - SpirentFixed in Version => v4.8.1 (published 2017-05)
24-07-2017 15:02Jacob Wieland - SpirentResolutionopen => fixed
24-07-2017 15:02Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
05-01-2018 11:55Gyorgy RethyNote Added: 0015016
05-01-2018 11:55Gyorgy RethyStatusresolved => closed
05-01-2018 11:55Gyorgy RethyProduct Version => v4.8.1 (published 2017-05)
05-01-2018 11:55Gyorgy RethyFixed in Versionv4.8.1 (published 2017-05) => v4.9.1 (published 2018-05)
05-01-2018 11:55Gyorgy RethyTarget Version => v4.9.1 (published 2018-05)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014551) +
+ travm1    +
+ 07-04-2017 06:43    +
+ 		+ + + + +
+ The wiki page for TTCN-3 is a good primer on this topic
+https://www.everipedia.com/TTCN-3/ [^]
+
+
+
+ + + + + + + + + + +
+ (0014561) +
+ szabados    +
+ 17-04-2017 14:33    +
+ 		+ + + + +
+ My understanding was the other way around: first the name to be mapped to should be calculated ... and if it is needed, correct it make sure a valid TTCN-3 name will be generated into the TTCN-3 files which also does not clash with anything else.
+
+Section 7.1.4 example 5 shows this:
+- "start" is first mapped to "start_list"
+- and as there would already be something with that name it is postfixed by "_1"
+   (using the rules of 5.2.2)
+
+It also does not make too much sense to first make sure that the name can be generated into TTCN-3 ... than change it without actually using it ... and use this changed name without making sure that this changed name can be safely used in the generated TTCN-3 code.
+Using the example:
+- according to 5.2.2 converting "group" to "group_" would serve to make sure the tools do not generate a TTCN-3 keyword as an identifier.
+  ... but as the example shows there is no intention to actually generate "group" into the TTCN-3 file (only the postfixed version), so there is no need for the protection in the first place.
+
+- at the same time as 7.1.4 example 5 shows the name postfixed with "_list" can very well clash with an other name ... so these checks/conversions need to be done after adding the "_list" postfix.
+
+
+
+ + + + + + + + + + +
+ (0014630) +
+ Jens Grabowski    +
+ 06-06-2017 14:17    +
(edited on: 06-06-2017 14:20)
+ 		+ + + + +
+ STF discussion: clarification needed, contact Helen for proofreading.
+
+
+
+
+
+ + + + + + + + + + +
+ (0014704) +
+ Kristóf Szabados    +
+ 09-06-2017 15:48    +
+ 		+ + + + +
+ I received feedback from Hellen
+"
+Hi Kristof,
+
+Thank you, this looks clear to me.
+Thanks and Regards,
+Hellen
+"
+
+Please check that the current description is clearer for you too.
+
+
+
+ + + + + + + + + + +
+ (0014705) +
+ Kristóf Szabados    +
+ 09-06-2017 16:01    +
+ 		+ + + + +
+ I corrected a typo and reduced the file size
+
+
+
+ + + + + + + + + + +
+ (0015016) +
+ Gyorgy Rethy    +
+ 05-01-2018 11:55    +
+ 		+ + + + +
+ Implemented in draft V4.8.3.
+
+ + diff --git a/docs/mantis/CR7573.md b/docs/mantis/CR7573.md new file mode 100644 index 0000000000000000000000000000000000000000..0ee58e32b394c08bfcf0a34a23900740cd3d4138 --- /dev/null +++ b/docs/mantis/CR7573.md @@ -0,0 +1,71 @@ + + + + + + + + + + + + + 0007573: Default types shall not refer to value parameters - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Advanced Parametrization (ES 202 784)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007573Ext Pack: Advanced Parametrization (ES 202 784)Technicalpublic16-12-2016 19:5016-12-2016 22:32
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv1.5.1 (published 2015-06) 
Target Versionv1.6.1 (published 2017-04)Fixed in Versionv1.6.1 (published 2017-04) 
TS version1.5.1
Clause Reference(s)5.2
Source (company - Author)L.M.Ericsson
Summary0007573: Default types shall not refer to value parameters
DescriptionCR 7294 restricts formal parameter default values to reference other formal parameters in the same parameter list for Part-1. The same apply as well for default values of type parameters (see example in CR 7294).
Steps To Reproduce
Additional InformationAdd the text to the clause describing changes to clause 5.4.1 of Part-1:
+
+Restriction e) is changed to:
+e) The expression of formal parameter’s default value has to be compatible with the type of the parameter. The expression may be any expression that is well-defined at the beginning of the scope of the parameterized entity, but shall not refer to other parameters of the same or any following parameter list.
+
+Clause 5.4.1.2 Formal parameters of kind template
+Restriction d) is changed to:
+d) The default template instance has to be compatible with the type of the parameter. The template instance may be any template expression that is well-defined at the beginning of the scope of the parameterized entity, but shall not refer to other parameters in the same or any following parameter list.
+
TagsNo tags attached.
Relationships
related to 0007294closed Gyorgy Rethy Part 01: TTCN-3 Core Language default values/templates of formal parameters should live in the runs-on scope 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
16-12-2016 19:50Gyorgy RethyNew Issue
16-12-2016 19:50Gyorgy RethyStatusnew => assigned
16-12-2016 19:50Gyorgy RethyAssigned To => Gyorgy Rethy
16-12-2016 19:53Gyorgy RethyNote Added: 0014451
16-12-2016 19:53Gyorgy RethyStatusassigned => closed
16-12-2016 19:53Gyorgy RethyResolutionopen => fixed
16-12-2016 19:53Gyorgy RethyFixed in Version => v1.6.1 (published 2017-04)
16-12-2016 22:32Gyorgy RethyRelationship addedrelated to 0007294
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014451) +
+ Gyorgy Rethy    +
+ 16-12-2016 19:53    +
+ 		+ + + + +
+ Restictions agreed in CR 7294, but related to this language extension has been added to draft V1.5.3
+
+ + diff --git a/docs/mantis/CR7590.md b/docs/mantis/CR7590.md new file mode 100644 index 0000000000000000000000000000000000000000..756fe4b76055f37be3548b4be223cedef9cd18c2 --- /dev/null +++ b/docs/mantis/CR7590.md @@ -0,0 +1,207 @@ + + + + + + + + + + + + + 0007590: BNF for select-case is not correct - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007590Part 01: TTCN-3 Core LanguageTechnicalpublic06-01-2017 13:3830-12-2017 20:28
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.8.1 (published 2016-07) 
Target Versionv4.10.1 (published 2018-05)Fixed in Versionv4.10.1 (published 2018-05) 
Clause Reference(s)A.1.6.8.3
Source (company - Author)Elvior
Summary0007590: BNF for select-case is not correct
DescriptionThe rule 570 of the BNF contains a reference to ElseKeyword. However, the case with the else keyword is already covered by the rule 571.
+
+Proposal:
+The rule shall be simplified to:
+570.SelectCase ::=
+CaseKeyword "(" TemplateInstance {"," TemplateInstance } ")" StatementBlock
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR_7590.docx (167,358) 08-06-2017 23:12
http://oldforge.etsi.org/mantis/file_download.php?file_id=3618&type=bug
docx CR_7590_v2.docx (192,014) 09-06-2017 08:33
http://oldforge.etsi.org/mantis/file_download.php?file_id=3622&type=bug
Issue History
Date ModifiedUsernameFieldChange
06-01-2017 13:38Tomas UrbanNew Issue
06-06-2017 15:04Jens GrabowskiAssigned To => Kristóf Szabados
06-06-2017 15:04Jens GrabowskiStatusnew => assigned
08-06-2017 23:12Kristóf SzabadosFile Added: CR_7590.docx
08-06-2017 23:13Kristóf SzabadosNote Added: 0014667
08-06-2017 23:13Kristóf SzabadosNote Added: 0014668
08-06-2017 23:13Kristóf SzabadosAssigned ToKristóf Szabados => Tomas Urban
08-06-2017 23:13Kristóf SzabadosStatusassigned => confirmed
09-06-2017 08:33Tomas UrbanNote Added: 0014675
09-06-2017 08:33Tomas UrbanAssigned ToTomas Urban => Kristóf Szabados
09-06-2017 08:33Tomas UrbanFile Added: CR_7590_v2.docx
09-06-2017 08:44Kristóf SzabadosNote Added: 0014678
09-06-2017 08:44Kristóf SzabadosStatusconfirmed => resolved
09-06-2017 08:44Kristóf SzabadosResolutionopen => fixed
09-06-2017 08:44Kristóf SzabadosAssigned ToKristóf Szabados => Gyorgy Rethy
30-12-2017 20:28Gyorgy RethyNote Added: 0014972
30-12-2017 20:28Gyorgy RethyStatusresolved => closed
30-12-2017 20:28Gyorgy RethyFixed in Version => v4.10.1 (published 2018-05)
30-12-2017 20:28Gyorgy RethyTarget Version => v4.10.1 (published 2018-05)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014667) +
+ Kristóf Szabados    +
+ 08-06-2017 23:13    +
+ 		+ + + + +
+ Added as deprecated feature and updated the description of the select and select union statements.
+I have kept the syntax to keep the backward compatibility (but noted in G.13 that it is deprecated and could be removed in a future version)
+
+
+
+ + + + + + + + + + +
+ (0014668) +
+ Kristóf Szabados    +
+ 08-06-2017 23:13    +
+ 		+ + + + +
+ Please review
+
+
+
+ + + + + + + + + + +
+ (0014675) +
+ Tomas Urban    +
+ 09-06-2017 08:33    +
+ 		+ + + + +
+ Basically, I am fine with the resolution, I only removed the paragraph about syntax. There are other deprecated features that still have a valid BNF support (external constant, mixed ports etc.), but this fact is never mentioned in the section G. The other option would be to add similar text to all other deprecated features that are still present in the BNF.
+
+Please review and if you are fine with the proposed change, you can mark the CR as resolved.
+
+
+
+ + + + + + + + + + +
+ (0014678) +
+ Kristóf Szabados    +
+ 09-06-2017 08:44    +
+ 		+ + + + +
+ The proposal resolves the CR and is ready to be included in the next version of the core language specification
+
+
+
+ + + + + + + + + + +
+ (0014972) +
+ Gyorgy Rethy    +
+ 30-12-2017 20:28    +
+ 		+ + + + +
+ Implemented in draft V4.9.2
+
+ + diff --git a/docs/mantis/CR7593.md b/docs/mantis/CR7593.md new file mode 100644 index 0000000000000000000000000000000000000000..58f6a46197700bc095df5f91e4a96698c2033b7b --- /dev/null +++ b/docs/mantis/CR7593.md @@ -0,0 +1,255 @@ + + + + + + + + + + + + + 0007593: Part-1, Sec.15.11: Template concatenation drops omit and type restrictions - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007593Part 01: TTCN-3 Core LanguageClarificationpublic09-01-2017 13:4330-12-2017 18:00
ReporterThilo Lauer 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.9.1 (published 2017-05) 
Target Versionv4.10.1 (published 2018-05)Fixed in Versionv4.10.1 (published 2018-05) 
Clause Reference(s)TTCN-3 Part-1, Section 15.11 (MTS-201873-1 T3ed481v475)
Source (company - Author)     Devoteam - Thilo Lauer
Summary0007593: Part-1, Sec.15.11: Template concatenation drops omit and type restrictions
DescriptionWhen templates are concatenated according to section 15.11
+the resulting template does not and cannot(!) contain type restrictions assigned to types of the concatenated templates.
+
+There is a similar situation if
+
+    template bitstring myBitStr_AnyValueOrNone := * length(5);
+    // that stands for either '?????'B or omit
+
+is mapped to
+
+    '?????'B
+
+Here the "value" omit gets lost by template concatenation acc. to. sec. 15.11.
+
+The reported issues apply to all types mentioned in section 15.11.
+
+Our Suggestion:
+As there is an TTCN-3 Extension "Advanced Matching" planned,
+we suggest to add e.g. the examples shown above to section 15.11 to make users aware of these pitfalls and to handle all issues of more complex pattern matching in the planned TTCN-3 extension.
+
+For more details, please see the enclosed document.
+
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx 2017-01-09_Devoteam_Clarification to TTCN-3 Part-1 Section 15.11.docx (1,392,446) 09-01-2017 13:43
http://oldforge.etsi.org/mantis/file_download.php?file_id=3578&type=bug
docx CR7593-v1.docx (178,621) 28-07-2017 11:15
http://oldforge.etsi.org/mantis/file_download.php?file_id=3669&type=bug
Issue History
Date ModifiedUsernameFieldChange
09-01-2017 13:43Thilo LauerNew Issue
09-01-2017 13:43Thilo LauerFile Added: 2017-01-09_Devoteam_Clarification to TTCN-3 Part-1 Section 15.11.docx
09-01-2017 13:46Thilo LauerNote Added: 0014477
06-06-2017 15:03Jens GrabowskiAssigned To => Jens Grabowski
06-06-2017 15:03Jens GrabowskiStatusnew => assigned
24-07-2017 13:36Jens GrabowskiProjectPart 04: TTCN-3 Operational Semantics => Part 01: TTCN-3 Core Language
27-07-2017 15:40Jens GrabowskiNote Added: 0014789
27-07-2017 15:40Jens GrabowskiAssigned ToJens Grabowski => Tomas Urban
28-07-2017 10:11Tomas UrbanNote Added: 0014791
28-07-2017 11:15Tomas UrbanFile Added: CR7593-v1.docx
28-07-2017 11:16Tomas UrbanNote Added: 0014793
28-07-2017 11:16Tomas UrbanAssigned ToTomas Urban => Jens Grabowski
28-07-2017 11:16Tomas UrbanStatusassigned => confirmed
04-09-2017 12:40Jens GrabowskiNote Added: 0014810
04-09-2017 12:40Jens GrabowskiStatusconfirmed => resolved
04-09-2017 12:40Jens GrabowskiResolutionopen => fixed
04-09-2017 12:40Jens GrabowskiAssigned ToJens Grabowski => Gyorgy Rethy
30-12-2017 18:00Gyorgy RethyNote Added: 0014960
30-12-2017 18:00Gyorgy RethyStatusresolved => closed
30-12-2017 18:00Gyorgy RethyProduct Version => v4.9.1 (published 2017-05)
30-12-2017 18:00Gyorgy RethyFixed in Version => v4.10.1 (published 2018-05)
30-12-2017 18:00Gyorgy RethyTarget Version => v4.10.1 (published 2018-05)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014477) +
+ Thilo Lauer    +
+ 09-01-2017 13:46    +
+ 		+ + + + +
+ ... sorry, this issue should be moved to TTCN-3 Part-1
+
+
+
+ + + + + + + + + + +
+ (0014789) +
+ Jens Grabowski    +
+ 27-07-2017 15:40    +
+ 		+ + + + +
+ Tomas, can you have a look. I have no problems to add the examples.
+
+
+
+ + + + + + + + + + +
+ (0014791) +
+ Tomas Urban    +
+ 28-07-2017 10:11    +
+ 		+ + + + +
+ It is correct that the omit property and type constraints are ignored during concatenation of the string and list templates. There are several reasons for this behaviour, but the main idea is to keep the rules as simple as possible. I will add examples demonstrating both describe pitfalls to the core language standard so that users are aware of possible consequences.
+
+
+
+ + + + + + + + + + +
+ (0014793) +
+ Tomas Urban    +
+ 28-07-2017 11:16    +
+ 		+ + + + +
+ Resolution uploaded. Please check.
+
+
+
+ + + + + + + + + + +
+ (0014810) +
+ Jens Grabowski    +
+ 04-09-2017 12:40    +
+ 		+ + + + +
+ Ready for implementation
+
+
+
+ + + + + + + + + + +
+ (0014960) +
+ Gyorgy Rethy    +
+ 30-12-2017 18:00    +
+ 		+ + + + +
+ Added to draft V4.9.2
+
+ + diff --git a/docs/mantis/CR7594.md b/docs/mantis/CR7594.md new file mode 100644 index 0000000000000000000000000000000000000000..7da146a9d53b0d2763096ebc59ce9821d5fe8b42 --- /dev/null +++ b/docs/mantis/CR7594.md @@ -0,0 +1,131 @@ + + + + + + + + + + + + + 0007594: Wrong parameter type in C mapping of the tliRnd function - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007594Part 06: TTCN-3 Control InterfaceTechnicalpublic19-01-2017 08:5402-01-2018 12:28
ReporterTomas Urban 
Assigned ToTomas Urban 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.9.1(ongoing) 
Target VersionFixed in Versionv4.9.1(ongoing) 
Clause Reference(s)9.4.4.1
Source (company - Author)Elvior
Summary0007594: Wrong parameter type in C mapping of the tliRnd function
DescriptionThe C mapping of the tliRnd function contains incorrectly mapped parameters val and seed. These parameters are of the type "TFloat" which isn't defined anywhere. The correct type for both would be Value (as in all other mappings)
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7594.docx (152,418) 09-06-2017 09:44
http://oldforge.etsi.org/mantis/file_download.php?file_id=3628&type=bug
Issue History
Date ModifiedUsernameFieldChange
19-01-2017 08:54Tomas UrbanNew Issue
06-06-2017 15:02Jens GrabowskiNote Added: 0014634
06-06-2017 15:02Jens GrabowskiAssigned To => Tomas Urban
06-06-2017 15:02Jens GrabowskiStatusnew => assigned
09-06-2017 09:26Tomas UrbanDescription Updatedbug_revision_view_page.php?rev_id=421#r421
09-06-2017 09:44Tomas UrbanFile Added: CR7594.docx
09-06-2017 09:45Tomas UrbanNote Added: 0014688
09-06-2017 09:45Tomas UrbanAssigned ToTomas Urban => Jacob Wieland - Spirent
09-06-2017 09:45Tomas UrbanStatusassigned => confirmed
09-06-2017 12:41Jacob Wieland - SpirentStatusconfirmed => resolved
09-06-2017 12:41Jacob Wieland - SpirentFixed in Version => v4.9.1(ongoing)
09-06-2017 12:41Jacob Wieland - SpirentResolutionopen => fixed
09-06-2017 12:41Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Tomas Urban
02-01-2018 12:28Tomas UrbanNote Added: 0014981
02-01-2018 12:28Tomas UrbanStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014634) +
+ Jens Grabowski    +
+ 06-06-2017 15:02    +
+ 		+ + + + +
+ STF discussion: Tomas please provide resolution, Jacob does proofreading
+
+
+
+ + + + + + + + + + +
+ (0014688) +
+ Tomas Urban    +
+ 09-06-2017 09:45    +
+ 		+ + + + +
+ Please check.
+
+
+
+ + + + + + + + + + +
+ (0014981) +
+ Tomas Urban    +
+ 02-01-2018 12:28    +
+ 		+ + + + +
+ Implemented in draft V4.9.2
+
+ + diff --git a/docs/mantis/CR7598.md b/docs/mantis/CR7598.md new file mode 100644 index 0000000000000000000000000000000000000000..aeaa72d1707a7915ea4007ffa1d298571607e430 --- /dev/null +++ b/docs/mantis/CR7598.md @@ -0,0 +1,245 @@ + + + + + + + + + + + + + 0007598: Invalid restriction on formal template parameters - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007598Part 01: TTCN-3 Core LanguageTechnicalpublic26-01-2017 14:2130-12-2017 15:40
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.9.1 (published 2017-05) 
Target Versionv4.10.1 (published 2018-05)Fixed in Versionv4.10.1 (published 2018-05) 
Clause Reference(s)5.4.1.2
Source (company - Author)STF 521
Summary0007598: Invalid restriction on formal template parameters
DescriptionThe restriction 5.4.1.2.b shall be changed, so that it does not mention functions and altsteps used in the component.start operation. This restriction is not present in the rules for formal value parameters (5.4.1.1.b) and the rules on starting a component explicitly mention that out and inout parameters are allowed and describe how they are handled in this case.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0007495closed Gyorgy Rethy out, inout and return value should be assignable via the done/killed statement redirect 
Attached Filesdocx CR7598-v1.docx (175,808) 08-09-2017 10:14
http://oldforge.etsi.org/mantis/file_download.php?file_id=3685&type=bug
Issue History
Date ModifiedUsernameFieldChange
26-01-2017 14:21Tomas UrbanNew Issue
18-04-2017 16:35szabadosNote Added: 0014577
02-05-2017 09:34Jacob Wieland - SpirentNote Added: 0014611
06-06-2017 11:44Jens GrabowskiRelationship addedrelated to 0007495
06-06-2017 11:44Jens GrabowskiNote Added: 0014622
06-06-2017 11:45Jens GrabowskiAssigned To => Jacob Wieland - Spirent
06-06-2017 11:45Jens GrabowskiStatusnew => assigned
08-09-2017 10:14Tomas UrbanFile Added: CR7598-v1.docx
08-09-2017 10:16Tomas UrbanNote Added: 0014825
08-09-2017 10:16Tomas UrbanStatusassigned => confirmed
24-10-2017 14:58Jacob Wieland - SpirentNote Added: 0014852
24-10-2017 14:58Jacob Wieland - SpirentStatusconfirmed => resolved
24-10-2017 14:58Jacob Wieland - SpirentFixed in Version => v4.9.1 (published 2017-05)
24-10-2017 14:58Jacob Wieland - SpirentResolutionopen => fixed
24-10-2017 14:58Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
30-12-2017 15:40Gyorgy RethyNote Added: 0014956
30-12-2017 15:40Gyorgy RethyStatusresolved => closed
30-12-2017 15:40Gyorgy RethyFixed in Versionv4.9.1 (published 2017-05) => v4.10.1 (published 2018-05)
30-12-2017 15:40Gyorgy RethyTarget Version => v4.10.1 (published 2018-05)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014577) +
+ szabados    +
+ 18-04-2017 16:35    +
+ 		+ + + + +
+ On one hand yes, the limitation should be removed.
+
+On the other hand using out and inout parameters in start does not make too much sense.
+According to 21.3.2 inout parameters are to be treated like in parameters.
+And out parameters remain unchanged by the started behaviour if the started behaviour changes it during its execution.
+
+So by removing the limitation the standard becomes more consistent, and also more error prone.
+Why is it allowed to start a function that has an out parameter, if the value can not be returned and also out parameters get unbound before the first statement is executed?
+No information can go in or out this way.
+
+
+
+ + + + + + + + + + +
+ (0014611) +
+ Jacob Wieland - Spirent    +
+ 02-05-2017 09:34    +
+ 		+ + + + +
+ I think it is a matter freedom vs. correctness. On the one hand, the current situation allows you to use code that might not be intended for that use but is still sufficient for your needs, so you don't have to write a similar function.
+
+On the other hand, it always leads to the situation that people are not aware of the current rule and are surprised by it, because they don't think of the deeper implications of how it would be otherwise.
+
+Thus, it clearly violates the principle of least surprise and should be changed (if possible).
+
+
+
+ + + + + + + + + + +
+ (0014622) +
+ Jens Grabowski    +
+ 06-06-2017 11:44    +
+ 		+ + + + +
+ STF discussion: To be resolved with CR 7495
+
+
+
+ + + + + + + + + + +
+ (0014825) +
+ Tomas Urban    +
+ 08-09-2017 10:16    +
+ 		+ + + + +
+ Only the original issue has been resolved, the remaining problems will be resolved in the related CR 0007495. Please check.
+
+
+
+ + + + + + + + + + +
+ (0014852) +
+ Jacob Wieland - Spirent    +
+ 24-10-2017 14:58    +
+ 		+ + + + +
+ issue is resolved
+
+
+
+ + + + + + + + + + +
+ (0014956) +
+ Gyorgy Rethy    +
+ 30-12-2017 15:40    +
+ 		+ + + + +
+ Added to draft V4.9.2
+
+ + diff --git a/docs/mantis/CR7599.md b/docs/mantis/CR7599.md new file mode 100644 index 0000000000000000000000000000000000000000..628f42a6954ff832eee496c52466d3be4ec8233e --- /dev/null +++ b/docs/mantis/CR7599.md @@ -0,0 +1,209 @@ + + + + + + + + + + + + + 0007599: Rules for actual parameterers with template restriction - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007599Part 01: TTCN-3 Core LanguageTechnicalpublic27-01-2017 08:5630-12-2017 16:08
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.9.1 (published 2017-05) 
Target Versionv4.10.1 (published 2018-05)Fixed in Versionv4.10.1 (published 2018-05) 
Clause Reference(s)5.4.2
Source (company - Author)STF 521
Summary0007599: Rules for actual parameterers with template restriction
DescriptionThe rules for template restrictions of actual in and out parameters in the restriction 5.4.2.d do not match those described in 15.8.b.
+
+The first set of rules (5.4.2.d) say that templates with certain restriction cannot be used at all as an actual parameter while the second set of rules (15.8.b) states that only the content should be checked at the time of parameter assignment (dependent on the tool, in compile time or runtime).
+
+Proposal:
+Remove the hard restriction for in and out parameters from 5.4.2.d and replace it with a soft (content-related) restriction or a reference to the rules described in 15.8.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0007603closed Gyorgy Rethy Delete note on template restriction passing table 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
27-01-2017 08:56Tomas UrbanNew Issue
27-01-2017 10:49Jacob Wieland - SpirentNote Added: 0014522
06-03-2017 12:21Tomas UrbanRelationship addedrelated to 0007603
17-04-2017 14:39szabadosNote Added: 0014562
06-06-2017 14:10Jens GrabowskiNote Added: 0014628
06-06-2017 14:11Jens GrabowskiAssigned To => Tomas Urban
06-06-2017 14:11Jens GrabowskiStatusnew => assigned
27-07-2017 11:31Tomas UrbanNote Added: 0014785
08-09-2017 07:45Tomas UrbanNote Added: 0014823
08-09-2017 07:45Tomas UrbanStatusassigned => resolved
08-09-2017 07:45Tomas UrbanResolutionopen => fixed
08-09-2017 07:45Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
30-12-2017 16:08Gyorgy RethyStatusresolved => closed
30-12-2017 16:08Gyorgy RethyProduct Version => v4.9.1 (published 2017-05)
30-12-2017 16:08Gyorgy RethyFixed in Version => v4.10.1 (published 2018-05)
30-12-2017 16:08Gyorgy RethyTarget Version => v4.10.1 (published 2018-05)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014522) +
+ Jacob Wieland - Spirent    +
+ 27-01-2017 10:49    +
+ 		+ + + + +
+ The rules have been designed specifically to allow tools that do compile-time checking to help the user avoid unwanted situations and also allow tools to avoid runtime-checking.
+
+Of course, this could also be changed into (then probably oftimes ignored) warnings and runtime-checks that only are done in case that a warning was issued, i.e. when the current hard conditions are violated.
+
+From the user perspective, I still think that the hard restriction is more helpful as it helps identify potential problems better. These problems can be solved by adding/removing template restrictions to declarations and we often have found lots of real errors that way at compile-time which otherwise would have been very hidden and hard to trace back at runtime.
+
+
+
+ + + + + + + + + + +
+ (0014562) +
+ szabados    +
+ 17-04-2017 14:39    +
+ 		+ + + + +
+ Breaking the harder rules sounds very much like a badly constructed test architecture ... that might or might not run into an error.
++ these new cases will require some runtime overhead people might not be prepared for.
+
+
+
+ + + + + + + + + + +
+ (0014628) +
+ Jens Grabowski    +
+ 06-06-2017 14:10    +
+ 		+ + + + +
+ STF discussion: to be discussed during the week, Tomas to prepare discussion
+
+
+
+ + + + + + + + + + +
+ (0014785) +
+ Tomas Urban    +
+ 27-07-2017 11:31    +
+ 		+ + + + +
+ Resolution being prepared together with the resolution of 0007603.
+
+
+
+ + + + + + + + + + +
+ (0014823) +
+ Tomas Urban    +
+ 08-09-2017 07:45    +
+ 		+ + + + +
+ Resolved as a part of 0007603 (hard restriction will be used).
+
+ + diff --git a/docs/mantis/CR7601.md b/docs/mantis/CR7601.md new file mode 100644 index 0000000000000000000000000000000000000000..e9ff5cc1ad7ca8204bd9b91980548221d75c53b4 --- /dev/null +++ b/docs/mantis/CR7601.md @@ -0,0 +1,97 @@ + + + + + + + + + + + + + 0007601: Misspelled word in 20.2.c - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007601Part 01: TTCN-3 Core LanguageEditorialpublic02-02-2017 09:0230-12-2017 15:02
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritylowSeveritytrivialReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.8.1 (published 2016-07) 
Target VersionFixed in Versionv4.10.1 (published 2018-05) 
Clause Reference(s)20.2
Source (company - Author)STF 521
Summary0007601: Misspelled word in 20.2.c
DescriptionThere's a misspelled word "re-evalution" in 20.2 restriction c. The correct version should be "re-evaluation".
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR-7601-170724.docx (69,655) 24-07-2017 13:06
http://oldforge.etsi.org/mantis/file_download.php?file_id=3647&type=bug
Issue History
Date ModifiedUsernameFieldChange
02-02-2017 09:02Tomas UrbanNew Issue
06-06-2017 15:00Jens GrabowskiAssigned To => Jens Grabowski
06-06-2017 15:00Jens GrabowskiStatusnew => assigned
24-07-2017 13:06Jens GrabowskiFile Added: CR-7601-170724.docx
24-07-2017 13:07Jens GrabowskiNote Added: 0014735
24-07-2017 13:07Jens GrabowskiStatusassigned => resolved
24-07-2017 13:07Jens GrabowskiResolutionopen => fixed
24-07-2017 13:07Jens GrabowskiAssigned ToJens Grabowski => Gyorgy Rethy
30-12-2017 15:02Gyorgy RethyNote Added: 0014952
30-12-2017 15:02Gyorgy RethyStatusresolved => closed
30-12-2017 15:02Gyorgy RethyFixed in Version => v4.10.1 (published 2018-05)
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014735) +
+ Jens Grabowski    +
+ 24-07-2017 13:07    +
+ 		+ + + + +
+ Resolution needs no further proofreading. Ready for Implementation.
+
+
+
+ + + + + + + + + + +
+ (0014952) +
+ Gyorgy Rethy    +
+ 30-12-2017 15:02    +
+ 		+ + + + +
+ Correction is included to draft V4.9.2
+
+ + diff --git a/docs/mantis/CR7602.md b/docs/mantis/CR7602.md new file mode 100644 index 0000000000000000000000000000000000000000..9d5145b3f88d46195b3dc8bad6117a13b5f9ffd5 --- /dev/null +++ b/docs/mantis/CR7602.md @@ -0,0 +1,343 @@ + + + + + + + + + + + + + 0007602: Three options of handling blocking multicast and broadcast calls - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007602Part 01: TTCN-3 Core LanguageClarificationpublic03-02-2017 10:4830-12-2017 17:31
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritylowSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.9.1 (published 2017-05) 
Target Versionv4.10.1 (published 2018-05)Fixed in Versionv4.10.1 (published 2018-05) 
Clause Reference(s)22.3.1
Source (company - Author)STF 521
Summary0007602: Three options of handling blocking multicast and broadcast calls
DescriptionThe description of handling multicast and broadcast blocking calls claims that: "In case of a multicast or broadcast call operation of a blocking procedure, two options exist." It also provides a description of these two options. However, that's not completely true, because there's a third option: the call can be executed with the nowait parameter in which case all responses are handled in the subsequent alt or interleave block.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR-7602-170727.docx (70,249) 27-07-2017 14:36
http://oldforge.etsi.org/mantis/file_download.php?file_id=3666&type=bug
docx CR-7602-170727-v2.docx (91,888) 27-07-2017 15:35
http://oldforge.etsi.org/mantis/file_download.php?file_id=3667&type=bug
docx CR-7602-170727-v3.docx (71,995) 04-09-2017 12:37
http://oldforge.etsi.org/mantis/file_download.php?file_id=3676&type=bug
Issue History
Date ModifiedUsernameFieldChange
03-02-2017 10:48Tomas UrbanNew Issue
24-04-2017 16:10szabadosNote Added: 0014603
24-04-2017 16:22szabadosNote Added: 0014604
06-06-2017 12:00Jens GrabowskiAssigned To => Jens Grabowski
06-06-2017 12:00Jens GrabowskiStatusnew => assigned
27-07-2017 14:36Jens GrabowskiFile Added: CR-7602-170727.docx
27-07-2017 14:38Jens GrabowskiNote Added: 0014787
27-07-2017 14:39Jens GrabowskiAssigned ToJens Grabowski => Tomas Urban
27-07-2017 14:39Jens GrabowskiStatusassigned => confirmed
27-07-2017 15:35Tomas UrbanFile Added: CR-7602-170727-v2.docx
27-07-2017 15:36Tomas UrbanNote Added: 0014788
27-07-2017 15:36Tomas UrbanAssigned ToTomas Urban => Jens Grabowski
27-07-2017 15:43Jens GrabowskiNote Added: 0014790
27-07-2017 15:44Jens GrabowskiAssigned ToJens Grabowski => Kristóf Szabados
27-07-2017 15:44Jens GrabowskiStatusconfirmed => assigned
27-07-2017 15:44Jens GrabowskiStatusassigned => confirmed
04-09-2017 12:37Kristóf SzabadosFile Added: CR-7602-170727-v3.docx
04-09-2017 12:39Kristóf SzabadosNote Added: 0014808
04-09-2017 12:39Kristóf SzabadosAssigned ToKristóf Szabados => Jens Grabowski
04-09-2017 12:39Kristóf SzabadosStatusconfirmed => assigned
04-09-2017 12:40Kristóf SzabadosNote Added: 0014809
04-09-2017 12:40Kristóf SzabadosStatusassigned => confirmed
04-09-2017 12:43Jens GrabowskiNote Added: 0014811
04-09-2017 12:43Jens GrabowskiStatusconfirmed => resolved
04-09-2017 12:43Jens GrabowskiResolutionopen => fixed
04-09-2017 12:43Jens GrabowskiAssigned ToJens Grabowski => Gyorgy Rethy
30-12-2017 17:31Gyorgy RethyNote Added: 0014959
30-12-2017 17:31Gyorgy RethyStatusresolved => closed
30-12-2017 17:31Gyorgy RethyFixed in Version => v4.10.1 (published 2018-05)
30-12-2017 17:31Gyorgy RethyTarget Version => v4.10.1 (published 2018-05)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014603) +
+ szabados    +
+ 24-04-2017 16:10    +
+ 		+ + + + +
+ I'm also wondering if repeat is really the only option to handle the responses or exceptions in the response or exception handling part.(2nd option)
+
+
+
+ + + + + + + + + + +
+ (0014604) +
+ szabados    +
+ 24-04-2017 16:22    +
+ 		+ + + + +
+ Also what is example 6 trying to do here?
+If I understand correctly it will only accept the first reply (from one of 2 components) ... there is no point using repeat if the guards have no chance to be fulfilled the second time around.
+
+Also if the guard is fulfilled by a variable the example checks if the variable is true ... the if -s don't seem to have a function?
+
+
+
+ + + + + + + + + + +
+ (0014787) +
+ Jens Grabowski    +
+ 27-07-2017 14:38    +
+ 		+ + + + +
+ I changed the description of the possibilities, changed the example 6 and also added the keyword "nowait" to the syntax description.
+
+Tomas, please check.
+
+
+
+ + + + + + + + + + +
+ (0014788) +
+ Tomas Urban    +
+ 27-07-2017 15:36    +
+ 		+ + + + +
+ It is fine by me, I only made several formatting changes in the added text and slightly modified the example. Please check.
+
+
+
+ + + + + + + + + + +
+ (0014790) +
+ Jens Grabowski    +
+ 27-07-2017 15:43    +
+ 		+ + + + +
+ Fine for me, Kristof: If also ok for you, please resolve and assign to György.
+
+
+
+ + + + + + + + + + +
+ (0014808) +
+ Kristóf Szabados    +
+ 04-09-2017 12:39    +
+ 		+ + + + +
+ I simplified a bit example 6 and tried to give it a reasonably good description (to see what the example is trying to show).
+Please check.
+
+Otherwise it looks ok for me and can be resolved.
+
+
+
+ + + + + + + + + + +
+ (0014809) +
+ Kristóf Szabados    +
+ 04-09-2017 12:40    +
+ 		+ + + + +
+ please check the simplification of example 6, and resolve if ok.
+
+
+
+ + + + + + + + + + +
+ (0014811) +
+ Jens Grabowski    +
+ 04-09-2017 12:43    +
+ 		+ + + + +
+ Ready for implementation.
+
+
+
+ + + + + + + + + + +
+ (0014959) +
+ Gyorgy Rethy    +
+ 30-12-2017 17:31    +
+ 		+ + + + +
+ Added to draft V4.9.2
+
+ + diff --git a/docs/mantis/CR7603.md b/docs/mantis/CR7603.md new file mode 100644 index 0000000000000000000000000000000000000000..0882e84015afe5b9b8730417001ee7b5fb7efb48 --- /dev/null +++ b/docs/mantis/CR7603.md @@ -0,0 +1,285 @@ + + + + + + + + + + + + + 0007603: Delete note on template restriction passing table - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007603Part 01: TTCN-3 Core LanguageTechnicalpublic03-02-2017 11:3905-09-2019 10:34
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.9.1 (published 2017-05) 
Target Versionv4.10.1 (published 2018-05)Fixed in Versionv4.10.1 (published 2018-05) 
Clause Reference(s)15.8
Source (company - Author)L.M.Ericsson
Summary0007603: Delete note on template restriction passing table
DescriptionTable 13 (clause 15.8) specifies the compatibility of different template restrictions of formal and actual parameters (and left-right hand sides).
+
+When introducing the feature, no hard restriction has been defined for the incompatible combination, but a note has been added (that the content has to be compatible). The reason was backward compatibility with (that time) existing TTCN-3 code.
+
+However, by now all code using template restrictions should have been updated.
+
+It is proposed to delete the note to the table and replace "(see note)" with "No" in the table's body.
+
+If wished, the change can be mentioned in the deprecated features annex, but I cannot see it necessary.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0007599closed Gyorgy Rethy Rules for actual parameterers with template restriction 
related to 0007874closed Gyorgy Rethy Reintroduce restriction on restricted modified templates 
Attached Filesdocx CR7603-v1.docx (263,873) 27-07-2017 11:16
http://oldforge.etsi.org/mantis/file_download.php?file_id=3664&type=bug
docx CR7603-v2.docx (226,882) 04-09-2017 10:55
http://oldforge.etsi.org/mantis/file_download.php?file_id=3674&type=bug
Issue History
Date ModifiedUsernameFieldChange
03-02-2017 11:39Gyorgy RethyNew Issue
06-03-2017 12:21Tomas UrbanRelationship addedrelated to 0007599
06-06-2017 14:11Jens GrabowskiNote Added: 0014629
06-06-2017 14:12Jens GrabowskiAssigned To => Tomas Urban
06-06-2017 14:12Jens GrabowskiStatusnew => assigned
26-07-2017 10:14Jens GrabowskiNote Added: 0014778
26-07-2017 10:15Jens GrabowskiNote Added: 0014779
27-07-2017 11:16Tomas UrbanFile Added: CR7603-v1.docx
27-07-2017 11:30Tomas UrbanNote Added: 0014784
27-07-2017 11:30Tomas UrbanAssigned ToTomas Urban => Kristóf Szabados
27-07-2017 11:30Tomas UrbanStatusassigned => confirmed
04-09-2017 10:55Kristóf SzabadosFile Added: CR7603-v2.docx
04-09-2017 10:56Kristóf SzabadosNote Added: 0014805
04-09-2017 10:59Kristóf SzabadosNote Added: 0014806
04-09-2017 10:59Kristóf SzabadosStatusconfirmed => resolved
04-09-2017 10:59Kristóf SzabadosResolutionopen => fixed
04-09-2017 10:59Kristóf SzabadosAssigned ToKristóf Szabados => Gyorgy Rethy
30-12-2017 18:31Gyorgy RethyNote Added: 0014962
30-12-2017 18:31Gyorgy RethyStatusresolved => closed
30-12-2017 18:31Gyorgy RethyFixed in Version => v4.10.1 (published 2018-05)
05-09-2019 10:34Tomas UrbanRelationship addedrelated to 0007874
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014629) +
+ Jens Grabowski    +
+ 06-06-2017 14:11    +
+ 		+ + + + +
+ STF discussion: to be discussed with 7599, Tomas to prepare discussion
+
+
+
+ + + + + + + + + + +
+ (0014778) +
+ Jens Grabowski    +
+ 26-07-2017 10:14    +
+ 		+ + + + +
+ STF discussion: Follow CR, deprecate feature (to support test suites that have not been updated until now)
+
+
+
+ + + + + + + + + + +
+ (0014779) +
+ Jens Grabowski    +
+ 26-07-2017 10:15    +
+ 		+ + + + +
+ CR resolved together with CR 7599.
+
+
+
+ + + + + + + + + + +
+ (0014784) +
+ Tomas Urban    +
+ 27-07-2017 11:30    +
+ 		+ + + + +
+ Please check the resolution.
+
+However, maybe we should consider additional conversion functions. In case of conversions to template(value), the user can call the valueof operation. Conversion to template(omit) is also possible:
+var template(omit) v_omit;
+if (isvalue(v_sourceTemplate)) {
+  v_omit := valueof(v_sourceTemplate);
+} else if (istemplatekind(v_sourceTemplate, "omit") {
+  v_omit := omit;
+}
+However, conversion to the present template is not possible. The user can detect that an unrestricted template fulfils the present restriction by calling ispresent(v_sourceTemplate), but there's no way how assign the content of the template to a template with a present restriction.
+   
+
+
+
+ + + + + + + + + + +
+ (0014805) +
+ Kristóf Szabados    +
+ 04-09-2017 10:56    +
+ 		+ + + + +
+ only a trivial change: the new item in the deprecated language feature list should be G.13 as a G12 already exists.
+
+
+
+ + + + + + + + + + +
+ (0014806) +
+ Kristóf Szabados    +
+ 04-09-2017 10:59    +
+ 		+ + + + +
+ Looks good to me. Can be included in the next version.
+
+
+
+ + + + + + + + + + +
+ (0014962) +
+ Gyorgy Rethy    +
+ 30-12-2017 18:31    +
+ 		+ + + + +
+ Added to draft V4.9.2
+
+ + diff --git a/docs/mantis/CR7605.md b/docs/mantis/CR7605.md new file mode 100644 index 0000000000000000000000000000000000000000..342adeb321607a1aea6c9306607e290d343a2924 --- /dev/null +++ b/docs/mantis/CR7605.md @@ -0,0 +1,313 @@ + + + + + + + + + + + + + 0007605: Logging of constructive values - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007605Part 01: TTCN-3 Core LanguageTechnicalpublic09-02-2017 09:4530-12-2017 19:03
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.9.1 (published 2017-05) 
Target Versionv4.10.1 (published 2018-05)Fixed in Versionv4.10.1 (published 2018-05) 
Clause Reference(s)19.11
Source (company - Author)STF 521
Summary0007605: Logging of constructive values
DescriptionThe description of the log procedure doesn't describe precisely how uninitialized fields of constructive values should be logged. For variables, there's an option to use "UNINITIALIZED" string, but it seems it is intended for the top level only. However, this is never clearly stated and that might lead to different interpretations. Besides, using "UNINITIALIZED" strings inside of a value doesn't produce a valid TTCN-3 syntax.
+
+For that reason, I propose to add a rule saying that "UNINITIALIZED" is used for the top level only (if the whole value or template is uninitialized) and uninitialized fields inside partially initialized constructive values/templates shall be either marked with the skip symbol "-" or in case of the value list notation completely missing if they are at the end of the value. This will produce a correct TTCN-3 syntax of a partially initialized value which can be copied and pasted to the code without any additional modifications.
+
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0007681closed Tomas Urban Part 06: TTCN-3 Control Interface adapt TCI to the hanges in any2unistr predefined function changes 
Attached Filesdocx CR_7605.docx (170,774) 09-06-2017 14:22
http://oldforge.etsi.org/mantis/file_download.php?file_id=3634&type=bug
docx CR_7605-v2.docx (195,708) 09-06-2017 15:41
http://oldforge.etsi.org/mantis/file_download.php?file_id=3637&type=bug
docx CR_7605-v3.docx (171,627) 09-06-2017 16:09
http://oldforge.etsi.org/mantis/file_download.php?file_id=3640&type=bug
Issue History
Date ModifiedUsernameFieldChange
09-02-2017 09:45Tomas UrbanNew Issue
24-04-2017 12:00szabadosNote Added: 0014600
06-06-2017 12:11Jens GrabowskiNote Added: 0014624
06-06-2017 12:11Jens GrabowskiAssigned To => Kristóf Szabados
06-06-2017 12:11Jens GrabowskiStatusnew => assigned
09-06-2017 11:20Kristóf SzabadosNote Added: 0014694
09-06-2017 14:22Kristóf SzabadosFile Added: CR_7605.docx
09-06-2017 14:23Kristóf SzabadosNote Added: 0014697
09-06-2017 14:23Kristóf SzabadosAssigned ToKristóf Szabados => Tomas Urban
09-06-2017 14:23Kristóf SzabadosStatusassigned => confirmed
09-06-2017 15:41Tomas UrbanFile Added: CR_7605-v2.docx
09-06-2017 15:43Tomas UrbanNote Added: 0014703
09-06-2017 15:43Tomas UrbanAssigned ToTomas Urban => Kristóf Szabados
09-06-2017 16:04Kristóf SzabadosAssigned ToKristóf Szabados => Jacob Wieland - Spirent
09-06-2017 16:04Kristóf SzabadosStatusconfirmed => assigned
09-06-2017 16:04Kristóf SzabadosNote Added: 0014706
09-06-2017 16:04Kristóf SzabadosStatusassigned => confirmed
09-06-2017 16:09Jacob Wieland - SpirentFile Added: CR_7605-v3.docx
24-07-2017 10:43Jacob Wieland - SpirentNote Added: 0014732
24-07-2017 10:43Jacob Wieland - SpirentStatusconfirmed => resolved
24-07-2017 10:43Jacob Wieland - SpirentFixed in Version => v4.9.1 (published 2017-05)
24-07-2017 10:43Jacob Wieland - SpirentResolutionopen => fixed
24-07-2017 10:43Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
26-07-2017 09:25Jacob Wieland - SpirentRelationship addedrelated to 0007681
30-12-2017 19:03Gyorgy RethyNote Added: 0014965
30-12-2017 19:03Gyorgy RethyStatusresolved => closed
30-12-2017 19:03Gyorgy RethyFixed in Versionv4.9.1 (published 2017-05) => v4.10.1 (published 2018-05)
30-12-2017 19:03Gyorgy RethyTarget Version => v4.10.1 (published 2018-05)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014600) +
+ szabados    +
+ 24-04-2017 12:00    +
+ 		+ + + + +
+ In theory I agree, in practice I would not constrain the logging too much more than this.
+
+As an example of a small difference in Titan ... we put a timestamp in the beginning of the logged message (beside the 100+ other logging options).
+
+For a bigger difference we provide extension plugins for logging information into different formats. Some of which are simple texts, some simple text with some advance features, some tool specific (JUnit, LTTNG, etc..) and users can write their own too.
+Where the logging might follow different rules.
+
+
+
+ + + + + + + + + + +
+ (0014624) +
+ Jens Grabowski    +
+ 06-06-2017 12:11    +
+ 		+ + + + +
+ STF discussion: to be checked if "-" can be a synoym for UNINIATIALIZED. Different semantics for "-" and UNINIATIALIZED should not be implemented.
+
+
+
+ + + + + + + + + + +
+ (0014694) +
+ Kristóf Szabados    +
+ 09-06-2017 11:20    +
+ 		+ + + + +
+ STF discussion: as the logging of structured entities was not specified in the standard for a long time, we decided to:
+- add a note the the log statement pointing out, that there might be vendor specific solution in logging structured entities
+- extend the any2unistr predefined function with on optional parameter, whereby the user could ask for TTCN-3 notation in the logged text.
+- create a CR to handle the TCI implications of this change.
+
+
+
+ + + + + + + + + + +
+ (0014697) +
+ Kristóf Szabados    +
+ 09-06-2017 14:23    +
+ 		+ + + + +
+ Please check.
+
+
+
+ + + + + + + + + + +
+ (0014703) +
+ Tomas Urban    +
+ 09-06-2017 15:43    +
+ 		+ + + + +
+ I am fine with most of the proposed changes, but I added a new rule for custom formats. Please check.
+
+
+
+ + + + + + + + + + +
+ (0014706) +
+ Kristóf Szabados    +
+ 09-06-2017 16:04    +
+ 		+ + + + +
+ I am fine with the changes. Please check.
+
+
+
+ + + + + + + + + + +
+ (0014732) +
+ Jacob Wieland - Spirent    +
+ 24-07-2017 10:43    +
+ 		+ + + + +
+ fine with me
+
+
+
+ + + + + + + + + + +
+ (0014965) +
+ Gyorgy Rethy    +
+ 30-12-2017 19:03    +
+ 		+ + + + +
+ Added to draft V4.9.2
+
+ + diff --git a/docs/mantis/CR7606.md b/docs/mantis/CR7606.md new file mode 100644 index 0000000000000000000000000000000000000000..09834e2e65dd3e04378fadd762c0b2f0f4b375b9 --- /dev/null +++ b/docs/mantis/CR7606.md @@ -0,0 +1,270 @@ + + + + + + + + + + + + + 0007606: Operations missing in the list of TTCN-3 elements that can be logged - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007606Part 01: TTCN-3 Core LanguageTechnicalpublic09-02-2017 09:5430-12-2017 21:16
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.9.1 (published 2017-05) 
Target Versionv4.10.1 (published 2018-05)Fixed in Versionv4.10.1 (published 2018-05) 
Clause Reference(s)19.11
Source (company - Author)STF 521
Summary0007606: Operations missing in the list of TTCN-3 elements that can be logged
DescriptionThe table 17 doesn't contain a description for several operations that can be syntactically present in the log operation: create, checkstate, valueof, activate.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc 7606.doc (37,888) 08-06-2017 14:36
http://oldforge.etsi.org/mantis/file_download.php?file_id=3608&type=bug
Issue History
Date ModifiedUsernameFieldChange
09-02-2017 09:54Tomas UrbanNew Issue
09-02-2017 11:56Jacob Wieland - SpirentNote Added: 0014523
09-02-2017 11:59Tomas UrbanNote Added: 0014524
09-02-2017 12:03Tomas UrbanNote Edited: 0014524bug_revision_view_page.php?bugnote_id=14524#r381
06-06-2017 15:00Jens GrabowskiAssigned To => Julien Deltour
06-06-2017 15:00Jens GrabowskiStatusnew => assigned
07-06-2017 09:05szabadosNote Added: 0014637
07-06-2017 09:46Julien DeltourNote Added: 0014640
08-06-2017 14:36Julien DeltourFile Added: 7606.doc
08-06-2017 14:37Julien DeltourNote Added: 0014651
08-06-2017 14:38Julien DeltourAssigned ToJulien Deltour => Tomas Urban
08-06-2017 15:07Tomas UrbanNote Added: 0014653
08-06-2017 15:07Tomas UrbanStatusassigned => resolved
08-06-2017 15:07Tomas UrbanResolutionopen => fixed
08-06-2017 15:07Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
30-12-2017 21:16Gyorgy RethyNote Added: 0014974
30-12-2017 21:16Gyorgy RethyStatusresolved => closed
30-12-2017 21:16Gyorgy RethyProduct Version => v4.9.1 (published 2017-05)
30-12-2017 21:16Gyorgy RethyFixed in Version => v4.10.1 (published 2018-05)
30-12-2017 21:16Gyorgy RethyTarget Version => v4.10.1 (published 2018-05)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014523) +
+ Jacob Wieland - Spirent    +
+ 09-02-2017 11:56    +
+ 		+ + + + +
+ Why should it? The results of these operations are logged and for those, descriptions should exist.
+
+
+
+ + + + + + + + + + +
+ (0014524) +
+ Tomas Urban    +
+ 09-02-2017 11:59    +
(edited on: 09-02-2017 12:03)
+ 		+ + + + +
+ Why should it? For the same reason, why operations like running, alive, read or match are listed in the same table.
+
+
+
+
+
+ + + + + + + + + + +
+ (0014637) +
+ szabados    +
+ 07-06-2017 09:05    +
+ 		+ + + + +
+ why is the comment of "read" refering to getverdict in this table?
+Also why is the comment of logging match empty if getverdict lists the actual values possible?
+
+
+
+ + + + + + + + + + +
+ (0014640) +
+ Julien Deltour    +
+ 07-06-2017 09:46    +
+ 		+ + + + +
+ For the comment of read, it is a typo mistake, it is 23.4 instead of 24.3.
+
+
+
+ + + + + + + + + + +
+ (0014651) +
+ Julien Deltour    +
+ 08-06-2017 14:37    +
+ 		+ + + + +
+ please review the proposal
+
+
+
+ + + + + + + + + + +
+ (0014653) +
+ Tomas Urban    +
+ 08-06-2017 15:07    +
+ 		+ + + + +
+ Proposed draft resolves the issue described in the CR and is ready to be included in the next core language specification.
+
+
+
+ + + + + + + + + + +
+ (0014974) +
+ Gyorgy Rethy    +
+ 30-12-2017 21:16    +
+ 		+ + + + +
+ Added to draft V4.9.2
+
+ + diff --git a/docs/mantis/CR7607.md b/docs/mantis/CR7607.md new file mode 100644 index 0000000000000000000000000000000000000000..10c58a72a724fabd67a41a62b95dc1acc41cdd88 --- /dev/null +++ b/docs/mantis/CR7607.md @@ -0,0 +1,463 @@ + + + + + + + + + + + + + 0007607: Additional restriction for the connect operation - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007607Part 01: TTCN-3 Core LanguageTechnicalpublic09-02-2017 14:0030-12-2017 20:55
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.9.1 (published 2017-05) 
Target Versionv4.10.1 (published 2018-05)Fixed in Versionv4.10.1 (published 2018-05) 
Clause Reference(s)21.1.1
Source (company - Author)STF 521
Summary0007607: Additional restriction for the connect operation
DescriptionThe current rules for the connect operation allow to establish a connection where no communication is possible without violating the current restrictions. Let's demonstrate it on an example:
+
+type port P message { in integer; }
+type component C { port P p; }
+testcase TC() runs on C system C {
+  var C v_ptc := C.create;
+  connect(self:p, v_ptc:p);
+}
+
+The rule 21.1.1.c says the connect operation is allowed if outlist-PORT1 subsetof inlist-PORT2 and outlist-PORT2 subsetof inlist-PORT1, which is fulfilled as the empty outlists are valid subsets of inlists.
+
+However, since no messages can be sent over such a connection from either side, it should not be allowed to create it. For that reason, I propose to extend the restriction c) by adding an additional condition: "where at least one of the outlists is not empty".
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0007677closed Gyorgy Rethy Additional restriction for the disconnect operation 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
09-02-2017 14:00Tomas UrbanNew Issue
09-02-2017 14:14Tomas UrbanNote Added: 0014525
10-02-2017 09:37Jacob Wieland - SpirentNote Added: 0014526
20-04-2017 17:39szabadosNote Added: 0014594
21-04-2017 09:40Jacob Wieland - SpirentNote Added: 0014595
21-04-2017 10:59Tomas UrbanNote Added: 0014596
21-04-2017 14:51Jacob Wieland - SpirentNote Added: 0014597
21-04-2017 15:09Tomas UrbanNote Added: 0014598
21-04-2017 15:09Tomas UrbanNote Edited: 0014598bug_revision_view_page.php?bugnote_id=14598#r411
21-04-2017 16:01Jacob Wieland - SpirentNote Added: 0014599
21-04-2017 16:02Jacob Wieland - SpirentNote Edited: 0014599bug_revision_view_page.php?bugnote_id=14599#r413
03-05-2017 10:40Tomas UrbanNote Added: 0014612
03-05-2017 11:00Jacob Wieland - SpirentNote Added: 0014613
06-06-2017 11:32Jens GrabowskiAssigned To => Kristóf Szabados
06-06-2017 11:32Jens GrabowskiStatusnew => assigned
06-06-2017 11:33Jens GrabowskiNote Added: 0014621
08-06-2017 20:34Kristóf SzabadosRelationship addedrelated to 0007677
09-06-2017 08:15Tomas UrbanNote Added: 0014673
09-06-2017 08:15Tomas UrbanStatusassigned => resolved
09-06-2017 08:15Tomas UrbanResolutionopen => fixed
09-06-2017 08:15Tomas UrbanAssigned ToKristóf Szabados => Gyorgy Rethy
30-12-2017 20:55Gyorgy RethyStatusresolved => closed
30-12-2017 20:55Gyorgy RethyProduct Version => v4.9.1 (published 2017-05)
30-12-2017 20:55Gyorgy RethyFixed in Version => v4.10.1 (published 2018-05)
30-12-2017 20:55Gyorgy RethyTarget Version => v4.10.1 (published 2018-05)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014525) +
+ Tomas Urban    +
+ 09-02-2017 14:14    +
+ 		+ + + + +
+ A similar problem affects the restriction d on the mapping operation. In this case, the additional rule should state that either outlist-PORT1 or inlist-PORT2 (or both of them) shall not be empty.
+
+
+
+ + + + + + + + + + +
+ (0014526) +
+ Jacob Wieland - Spirent    +
+ 10-02-2017 09:37    +
+ 		+ + + + +
+ This would be a valid but useless restriction. The actual resulting problem only occurs once you try to send something over the port at which point a (probably even static) error would occur. As long as you don't use the connection to send something, it doesn't pose an actual problem.
+
+
+
+ + + + + + + + + + +
+ (0014594) +
+ szabados    +
+ 20-04-2017 17:39    +
+ 		+ + + + +
+ I'm for extending the restriction.
+
+I just registered a request for Titan to report these situations.
+This is something that we can detect statically and save potentially hours of debugging for our users.
+
+
+
+ + + + + + + + + + +
+ (0014595) +
+ Jacob Wieland - Spirent    +
+ 21-04-2017 09:40    +
+ 		+ + + + +
+ How can this be a debugging problem? Does Titan not check whether a message over a port can be sent statically? Once you try to send a message over a port that is not allowed to be sent, the (probable) error in the port definition will become apparent and can be fixed. No debugging involved.
+
+
+
+ + + + + + + + + + +
+ (0014596) +
+ Tomas Urban    +
+ 21-04-2017 10:59    +
+ 		+ + + + +
+ I agree that it is not a problem for sending. However, in the case of receiving operations an unexperienced user might wonder why no messages are ever delivered to a legally mapped/connected port. If he/she gets a static error when compiling the connect operation, it will save a lot of time.
+
+We had this case some time ago and it really took some time to find the cause of the problem which occurred after removing some messages from the port list (the test suite worked well before). Of course it was an error of the person who made this change and didn't thought it through, but with proper compiler support, it would have been discovered earlier.
+
+
+
+ + + + + + + + + + +
+ (0014597) +
+ Jacob Wieland - Spirent    +
+ 21-04-2017 14:51    +
+ 		+ + + + +
+ But what would this restriction help you in that case? Did the person remove ALL the types in the out list of the connected port or just some? In the latter case, the additional restriction would not help you at all.
+
+
+
+ + + + + + + + + + +
+ (0014598) +
+ Tomas Urban    +
+ 21-04-2017 15:09    +
+ 		+ + + + +
+ The person didn't remove all types from the port type, but unfortunately the removed types were the only ones which were present in the other port type in-list.
+
+I admit it is not a usual issue, but I don't see any harm having an additional restriction here. Our compiler does detect the problem and issues a warning, but since the common approach of typical users to warnings is to ignore them, I would prefer an outright error during compilation of the connect (or map operation). It just doesn't seem reasonable to allow connections that are completely useless.
+
+
+
+
+
+ + + + + + + + + + +
+ (0014599) +
+ Jacob Wieland - Spirent    +
+ 21-04-2017 16:01    +
(edited on: 21-04-2017 16:02)
+ 		+ + + + +
+ But then this is already covered with the current restriction in place.
+
+The out-list of port A was X and the in-list of B was Y and Y was not a superset of X, then the restriction is violated and connect should be reported as erroneous. Or what am I missing?
+
+
+
+
+
+ + + + + + + + + + +
+ (0014612) +
+ Tomas Urban    +
+ 03-05-2017 10:40    +
+ 		+ + + + +
+ I am sorry, Jacob. I wrote the comment without checking the exact details. You are indeed correct that the described situation is covered by the current restrictions.
+
+It turns out that the problem our testers had concerned mapped ports. They actually did delete (or rather commented out) the whole in-list of the system port. It happened by accident, it was not an intentional change. The mapped component port had no out-list, because it was used only for notifications. The adapter still kept enqueuing messages which led to a runtime error during a test session. It took them some time to figure out the reason.
+
+
+
+ + + + + + + + + + +
+ (0014613) +
+ Jacob Wieland - Spirent    +
+ 03-05-2017 11:00    +
+ 		+ + + + +
+ sorry, can you just give the problematic example in TTCN-3 form to better understand the issue. I am still confused.
+
+
+
+ + + + + + + + + + +
+ (0014621) +
+ Jens Grabowski    +
+ 06-06-2017 11:33    +
+ 		+ + + + +
+ STF dicussion: check, if a note is sufficient for this issue.
+
+
+
+ + + + + + + + + + +
+ (0014673) +
+ Tomas Urban    +
+ 09-06-2017 08:15    +
+ 		+ + + + +
+ Resolved as a part of the resolution o 0007677.
+
+ + diff --git a/docs/mantis/CR7610.md b/docs/mantis/CR7610.md new file mode 100644 index 0000000000000000000000000000000000000000..7b003c83486c51f79c3249e928815afa67c82735 --- /dev/null +++ b/docs/mantis/CR7610.md @@ -0,0 +1,249 @@ + + + + + + + + + + + + + 0007610: Missing rules for return value of the reply operation - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007610Part 01: TTCN-3 Core LanguageTechnicalpublic10-02-2017 14:4230-12-2017 18:05
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.9.1 (published 2017-05) 
Target Versionv4.10.1 (published 2018-05)Fixed in Versionv4.10.1 (published 2018-05) 
Clause Reference(s)22.3.3
Source (company - Author)STF 521
Summary0007610: Missing rules for return value of the reply operation
DescriptionThe rules on the return value are insufficient. Only the following rules are present at the moment in the chapter 22.3.3:
+
+The value part of the reply operation consists of a signature reference with an associated actual parameter list and (optional) return value.
+
+A return value or template shall be explicitly stated with the value keyword and is first evaluated before returning.
+
+If a value is to be returned to the calling party, this shall be explicitly stated using the value keyword. The TemplateBody in the value clause shall conform to the template(value) restriction.
+
+So what is missing or not sufficiently explained:
+1. The rules shall more precisely describe the relation between the signature template (which defines the signature reference and signature parameters) and the optional return value template (which is a separate entity). The first cited rule doesn't connect these two entities very well, even though this relation is esential for type checks of the return value.
+2. It should be clearly said that optionality of the return value is related to the signature definition. If the signature defines a return value, the value clause shall be present in the reply operation. If the signature doesn't define a return value, the value clause shall be missing.
+
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR-7610-170728.docx (64,452) 28-07-2017 10:19
http://oldforge.etsi.org/mantis/file_download.php?file_id=3668&type=bug
docx CR-7610-170728-v2.docx (84,492) 28-07-2017 11:29
http://oldforge.etsi.org/mantis/file_download.php?file_id=3670&type=bug
Issue History
Date ModifiedUsernameFieldChange
10-02-2017 14:42Tomas UrbanNew Issue
24-04-2017 15:36szabadosNote Added: 0014602
02-05-2017 09:25Jacob Wieland - SpirentNote Added: 0014609
06-06-2017 11:53Jens GrabowskiAssigned To => Jens Grabowski
06-06-2017 11:53Jens GrabowskiStatusnew => assigned
28-07-2017 10:18Jens GrabowskiNote Added: 0014792
28-07-2017 10:19Jens GrabowskiFile Added: CR-7610-170728.docx
28-07-2017 10:19Jens GrabowskiAssigned ToJens Grabowski => Tomas Urban
28-07-2017 10:19Jens GrabowskiStatusassigned => confirmed
28-07-2017 11:29Tomas UrbanFile Added: CR-7610-170728-v2.docx
28-07-2017 11:31Tomas UrbanNote Added: 0014794
28-07-2017 11:31Tomas UrbanAssigned ToTomas Urban => Jens Grabowski
04-09-2017 12:35Jens GrabowskiNote Added: 0014807
04-09-2017 12:35Jens GrabowskiStatusconfirmed => resolved
04-09-2017 12:35Jens GrabowskiResolutionopen => fixed
04-09-2017 12:35Jens GrabowskiAssigned ToJens Grabowski => Gyorgy Rethy
30-12-2017 18:05Gyorgy RethyNote Added: 0014961
30-12-2017 18:05Gyorgy RethyStatusresolved => closed
30-12-2017 18:05Gyorgy RethyProduct Version => v4.9.1 (published 2017-05)
30-12-2017 18:05Gyorgy RethyFixed in Version => v4.10.1 (published 2018-05)
30-12-2017 18:05Gyorgy RethyTarget Version => v4.10.1 (published 2018-05)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014602) +
+ szabados    +
+ 24-04-2017 15:36    +
+ 		+ + + + +
+ True, we already have checks for these issues.
+
+
+
+ + + + + + + + + + +
+ (0014609) +
+ Jacob Wieland - Spirent    +
+ 02-05-2017 09:25    +
+ 		+ + + + +
+ agreed
+
+
+
+ + + + + + + + + + +
+ (0014792) +
+ Jens Grabowski    +
+ 28-07-2017 10:18    +
+ 		+ + + + +
+ Please check resolution proposal (restrictions c and f). If ok, assign to György for implementation.
+
+
+
+ + + + + + + + + + +
+ (0014794) +
+ Tomas Urban    +
+ 28-07-2017 11:31    +
+ 		+ + + + +
+ I am fine with the changes, but I made two more modifications in the following restriction g:
+1. I removed the first sentences as it is covered now by the new restriction f
+2. I added a rule about type compatibility of the return value
+
+Please check and if fine, it can be assigned to György for implementation.
+
+
+
+ + + + + + + + + + +
+ (0014807) +
+ Jens Grabowski    +
+ 04-09-2017 12:35    +
+ 		+ + + + +
+ Ready for Implementation
+
+
+
+ + + + + + + + + + +
+ (0014961) +
+ Gyorgy Rethy    +
+ 30-12-2017 18:05    +
+ 		+ + + + +
+ Added to draft V4.9.2
+
+ + diff --git a/docs/mantis/CR7611.md b/docs/mantis/CR7611.md new file mode 100644 index 0000000000000000000000000000000000000000..9336ae9716ed0090a68f67d90558c522e56b9fd6 --- /dev/null +++ b/docs/mantis/CR7611.md @@ -0,0 +1,297 @@ + + + + + + + + + + + + + 0007611: Valid port lists for the procedure operations - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007611Part 01: TTCN-3 Core LanguageClarificationpublic13-02-2017 11:2723-08-2019 09:39
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.9.1 (published 2017-05) 
Target Versionv4.10.1 (published 2018-05)Fixed in Versionv4.10.1 (published 2018-05) 
Clause Reference(s)6.2.9, 22.3
Source (company - Author)STF 521
Summary0007611: Valid port lists for the procedure operations
DescriptionThe clause 6.2.9 and related sections of 22.3 don't provide sufficient rules on how signatures listed in the in-list and out-list of port definitions restrict which signatures can be used in procedure-based communication. The used logic is not straightforward, as the in/out directions are assessed from the caller's point of view. Let's demonstrate it on an example with the following definitions:
+
+type signature S() exception (charstring);
+port PClient procedure { out S; }
+port PServer procedure { in S; }
+
+With these definitions, the following operations using the signature S shall be possible for a port of the PClient type:
+- call
+- getreply
+- catch
+
+And the following operations using the signature S shall be possible for a port of the PServer type:
+- getcall
+- reply
+- raise
+
+There are some hints on how this should work in the core language specification, especially in the way how system adapter works (in 6.2.9, but getcall, reply, raise are not explicitly mentioned) and in the description of the call (22.3.1 restriction a), getcall (22.3.2 restriction b) and raise (22.3.5 restriction b). However, the reply, getreply and catch operations do not contain any relevant restriction and there's no general explanation of the whole logic in 6.2.9.
+
+Proposal:
+1. In 6.2.9, explicitly list procedure-based communication operations associated with the in-list and out-list.
+2. Extend the list of in and out directions of the system adapter by adding the missing operations.
+3. Add the missing restrictions to the reply, getreply and catch operation clauses
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0007860closed Gyorgy Rethy CR 7611 wasn't properly added to the specification 
Attached Filesdoc 7611.doc (171,008) 09-06-2017 08:34
http://oldforge.etsi.org/mantis/file_download.php?file_id=3623&type=bug
doc 7611-v2.doc (159,232) 09-06-2017 09:23
http://oldforge.etsi.org/mantis/file_download.php?file_id=3625&type=bug
doc 7611-v3.doc (175,616) 09-06-2017 09:49
http://oldforge.etsi.org/mantis/file_download.php?file_id=3630&type=bug
doc 7611-v4.doc (146,944) 09-06-2017 10:17
http://oldforge.etsi.org/mantis/file_download.php?file_id=3632&type=bug
Issue History
Date ModifiedUsernameFieldChange
13-02-2017 11:27Tomas UrbanNew Issue
15-02-2017 11:33Jacob Wieland - SpirentNote Added: 0014528
15-02-2017 12:15Tomas UrbanNote Added: 0014529
06-06-2017 14:56Jens GrabowskiAssigned To => Julien Deltour
06-06-2017 14:56Jens GrabowskiStatusnew => assigned
09-06-2017 08:34Julien DeltourFile Added: 7611.doc
09-06-2017 08:35Julien DeltourNote Added: 0014676
09-06-2017 08:36Julien DeltourStatusassigned => confirmed
09-06-2017 08:36Julien DeltourAssigned ToJulien Deltour => Tomas Urban
09-06-2017 08:36Julien DeltourStatusconfirmed => assigned
09-06-2017 09:23Tomas UrbanFile Added: 7611-v2.doc
09-06-2017 09:24Tomas UrbanNote Added: 0014685
09-06-2017 09:24Tomas UrbanAssigned ToTomas Urban => Julien Deltour
09-06-2017 09:24Tomas UrbanStatusassigned => confirmed
09-06-2017 09:48Julien DeltourFile Added: 7611-v3.doc
09-06-2017 09:48Julien DeltourFile Deleted: 7611-v3.doc
09-06-2017 09:49Julien DeltourFile Added: 7611-v3.doc
09-06-2017 09:50Julien DeltourNote Added: 0014690
09-06-2017 09:53Julien DeltourAssigned ToJulien Deltour => Tomas Urban
09-06-2017 10:17Tomas UrbanFile Added: 7611-v4.doc
09-06-2017 10:18Tomas UrbanNote Added: 0014693
09-06-2017 10:18Tomas UrbanStatusconfirmed => resolved
09-06-2017 10:18Tomas UrbanResolutionopen => fixed
09-06-2017 10:18Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
30-12-2017 20:15Gyorgy RethyNote Added: 0014971
30-12-2017 20:15Gyorgy RethyStatusresolved => closed
30-12-2017 20:15Gyorgy RethyProduct Version => v4.9.1 (published 2017-05)
30-12-2017 20:15Gyorgy RethyFixed in Version => v4.10.1 (published 2018-05)
30-12-2017 20:15Gyorgy RethyTarget Version => v4.10.1 (published 2018-05)
23-08-2019 09:39Tomas UrbanRelationship addedrelated to 0007860
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014528) +
+ Jacob Wieland - Spirent    +
+ 15-02-2017 11:33    +
+ 		+ + + + +
+ I am confused by this part of the proposal:
+
+" Extend the list of in and out directions of the system adapter by adding the missing operations."
+
+I have no idea what you mean specifically by that statement.
+
+
+
+ + + + + + + + + + +
+ (0014529) +
+ Tomas Urban    +
+ 15-02-2017 12:15    +
+ 		+ + + + +
+ Detailed explanation:
+
+The original sentence "...with the exception of the test system interface, where in identifies the direction of message sending or procedure call and out identifies the direction of message receive, get reply or catch exception from the point of view of the test component connected to the test system interface port."
+
+The proposed sentence: "...with the exception of the test system interface, where the communication operations are seen from the point of view of the test component port mapped to the test system interface port. The in-list of the test system interface port contains messages or signatures for which the mapped component port allows the following operations: receive, trigger, getcall, reply or raise. The out-list of the test system interface port contains messages or signatures for which the mapped component port allows the following operations: send, call, getreply or catch."
+
+
+
+ + + + + + + + + + +
+ (0014676) +
+ Julien Deltour    +
+ 09-06-2017 08:35    +
+ 		+ + + + +
+ Please review the proposal
+
+
+
+ + + + + + + + + + +
+ (0014685) +
+ Tomas Urban    +
+ 09-06-2017 09:24    +
+ 		+ + + + +
+ I made several minor changes in the document. Please review and if you are fine with the resolution, you can mark the CR as resolved and assign it to Gyorgy for implementation.
+
+
+
+ + + + + + + + + + +
+ (0014690) +
+ Julien Deltour    +
+ 09-06-2017 09:50    +
+ 		+ + + + +
+ for consistency in restrictions rules, I have made two more changes. Please review
+
+
+
+ + + + + + + + + + +
+ (0014693) +
+ Tomas Urban    +
+ 09-06-2017 10:18    +
+ 		+ + + + +
+ The last revision contains only cosmetic changes and the resolution is ready to be added to the next version of the core language specification.
+
+
+
+ + + + + + + + + + +
+ (0014971) +
+ Gyorgy Rethy    +
+ 30-12-2017 20:15    +
+ 		+ + + + +
+ Implemented in draft V4.9.2
+
+ + diff --git a/docs/mantis/CR7618.md b/docs/mantis/CR7618.md new file mode 100644 index 0000000000000000000000000000000000000000..19704786a2e9f14b9cd882a72de38c7f063015e9 --- /dev/null +++ b/docs/mantis/CR7618.md @@ -0,0 +1,210 @@ + + + + + + + + + + + + + 0007618: alternative event headers could allow a boolean combinators - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007618Part 01: TTCN-3 Core LanguageNew Featurepublic16-02-2017 14:3706-08-2019 11:44
ReporterJacob Wieland - Spirent 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionno change required 
PlatformOSOS Version
Product Version 
Target Version4.11.1 (published 2019-05)Fixed in Version 
Clause Reference(s)20.2
Source (company - Author)Spirent - Jacob Wieland
Summary0007618: alternative event headers could allow a boolean combinators
DescriptionSometimes, in an alt statement, different alternatives have the same alternative body, i.e.
+
+alt {
+[] <event 1> { S }
+[] <event 2> { S }
+...
+}
+
+In such a case, it would be convenient to only have to write the body once, e.g.
+
+alt {
+[] <event 1> or <event 2> { S }
+...
+}
+
+In a similar fashion, some conditions to be waited on are more complex and cannot be modeled with a single event, like awaiting two messages from different ports. Though this can be modeled now by nested alt statements or using marker flags and the repeat statement (if entering the alt-branch is undesirable as other alternatives might still be active in the top-alt which then would need to be copied to the sub-level alt), it would be more convenient if an and operation could be employed instead, e.g.
+
+alt {
+[] <event 1> and <event 2> { ... }
+}
+
+Of course, all events treated by such boolean combinations shall be visible in the same snapshot, so it makes no sense to combine two receive statements on the same port handling consecutive messages.
+
+Thus, the proposal is to allow any boolean and/or-combination of allowed events that can be active in the same snapshot.
+
+Care must be taken when combining different events with attached redirects by disjunction as only a subset of the events could be active and thus only a subset of the redirects might occur, e.g.
+
+alt {
+[] p1.receive(t1) -> value v1 or p2.receive(t2) -> value v2 {
+   // here, v1 or v2 might not be bound
+}
+
+Finally, similar to the any from P construct for port arrays, a similar construct to await a message from all ports in an array might be added, as well as a base event.
+
+type record of P Ports;
+type record of Message Messages;
+
+var Ports ports := { p1, p2, p3 }
+var Messages v_msgs;
+ 
+alt {
+[] all from ports.receive(Message:?) -> value v_msgs[@index] {
+// the @index reference allows association of the received messages
+// to the port it was received from, i.e. v_msgs[i] was received from ports[i]
+}
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filespptx CR-7618-Discussion.pptx (49,271) 08-09-2017 08:00
http://oldforge.etsi.org/mantis/file_download.php?file_id=3683&type=bug
Issue History
Date ModifiedUsernameFieldChange
16-02-2017 14:37Jacob Wieland - SpirentNew Issue
06-06-2017 14:38Jens GrabowskiProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
06-06-2017 14:52Jens GrabowskiNote Added: 0014633
06-06-2017 14:53Jens GrabowskiAssigned To => Jens Grabowski
06-06-2017 14:53Jens GrabowskiStatusnew => assigned
08-09-2017 07:40Jens GrabowskiNote Added: 0014822
08-09-2017 08:00Jens GrabowskiFile Added: CR-7618-Discussion.pptx
24-10-2017 12:39Jens GrabowskiNote Added: 0014843
05-01-2018 13:29Gyorgy RethyTarget Version => 4.11.1 (published 2019-05)
06-08-2019 11:44Kristóf SzabadosNote Added: 0015373
06-08-2019 11:44Kristóf SzabadosStatusassigned => closed
06-08-2019 11:44Kristóf SzabadosResolutionopen => no change required
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014633) +
+ Jens Grabowski    +
+ 06-06-2017 14:52    +
+ 		+ + + + +
+ STF discussion: interesting feature, implications need to be studied, maybe feature for another package
+
+
+
+ + + + + + + + + + +
+ (0014822) +
+ Jens Grabowski    +
+ 08-09-2017 07:40    +
+ 		+ + + + +
+ STF discussion: concentrate on OR semantics (for avoiding code duplication), Case one in slides to be uploaded.
+
+
+
+ + + + + + + + + + +
+ (0014843) +
+ Jens Grabowski    +
+ 24-10-2017 12:39    +
+ 		+ + + + +
+ STF decision: requires further discussion. To be shifted to 2018 maintenance. Maybe candidate for advanced matching extension package.
+
+
+
+ + + + + + + + + + +
+ (0015373) +
+ Kristóf Szabados    +
+ 06-08-2019 11:44    +
+ 		+ + + + +
+ STF discussion: valid inut for TTCN-5. At the moment this would not provide much gain.
+
+ + diff --git a/docs/mantis/CR7619.md b/docs/mantis/CR7619.md new file mode 100644 index 0000000000000000000000000000000000000000..1b9679689fd1f90603ef52584d4ba51cac4d2515 --- /dev/null +++ b/docs/mantis/CR7619.md @@ -0,0 +1,256 @@ + + + + + + + + + + + + + 0007619: No named interleave construct available. - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007619Part 01: TTCN-3 Core LanguageNew Featurepublic16-02-2017 14:5904-01-2019 16:17
ReporterJacob Wieland - Spirent 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.9.1 (published 2017-05) 
Target Version4.11.1 (published 2019-05)Fixed in Version4.11.1 (published 2019-05) 
Clause Reference(s)16.2, 20.2, 20.4
Source (company - Author)Spirent - Jacob Wieland
Summary0007619: No named interleave construct available.
DescriptionThe interleave statement is explained as shorthand notation for more complicated alt-statements processing the interleave branches in an interleaving-parallel fashion.
+
+For normal alt statements, the possibility to de-inline them by defining them as a teststep and then referencing them from multiple places exists, while for interleave, this is not possible. That means that if the same interleave statement is needed in multiple places, it needs to be copied which is bad for code maintenance and readability.
+
+As a workaround, at the moment, the interleave statement can be put into a function, but then this cannot be used in the place of altsteps in the event-part of an alt-statement, but only as a new top-level interleave.
+
+For better compositionality and consistency, we thus propose to allow to define interleave altsteps and to allow to use such altsteps wherever a normal altstep reference is allowed, i.e.
+
+altstep I() interleave {
+< local variable declarations that live during the duration of this block >
+[] ...
+[] ...
+}
+
+alt {
+[] I() { ... }
+[] ...
+}
+
+The syntactic changes to the language would be minimal and fully backward compatible.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx 7619.docx (101,443) 13-12-2017 12:43
http://oldforge.etsi.org/mantis/file_download.php?file_id=3727&type=bug
docx CR7619-2.docx (161,943) 20-07-2018 08:59
http://oldforge.etsi.org/mantis/file_download.php?file_id=3782&type=bug
Issue History
Date ModifiedUsernameFieldChange
16-02-2017 14:59Jacob Wieland - SpirentNew Issue
06-06-2017 14:38Jens GrabowskiProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
06-06-2017 14:39Jens GrabowskiAssigned To => Julien Deltour
06-06-2017 14:39Jens GrabowskiStatusnew => assigned
24-10-2017 13:05Jens GrabowskiNote Added: 0014846
13-12-2017 12:43Julien DeltourFile Added: 7619.docx
13-12-2017 12:43Julien DeltourNote Added: 0014942
13-12-2017 12:43Julien DeltourStatusassigned => confirmed
13-12-2017 12:43Julien DeltourAssigned ToJulien Deltour => Jens Grabowski
13-12-2017 12:43Julien DeltourStatusconfirmed => assigned
05-01-2018 13:27Gyorgy RethyProduct Version => v4.9.1 (published 2017-05)
05-01-2018 13:27Gyorgy RethyTarget Version => 4.11.1 (published 2019-05)
05-02-2018 12:15Jacob Wieland - SpirentNote Added: 0015055
05-02-2018 12:15Jacob Wieland - SpirentStatusassigned => confirmed
18-07-2018 15:37Jens GrabowskiAssigned ToJens Grabowski => Jacob Wieland - Spirent
18-07-2018 15:37Jens GrabowskiStatusconfirmed => assigned
20-07-2018 08:59Jacob Wieland - SpirentFile Added: CR7619-2.docx
20-07-2018 09:00Jacob Wieland - SpirentNote Added: 0015184
20-07-2018 09:00Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Tomas Urban
20-07-2018 09:00Jacob Wieland - SpirentStatusassigned => confirmed
20-07-2018 11:41Tomas UrbanNote Added: 0015189
20-07-2018 11:41Tomas UrbanStatusconfirmed => resolved
20-07-2018 11:41Tomas UrbanResolutionopen => fixed
20-07-2018 11:41Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
04-01-2019 16:17Gyorgy RethyNote Added: 0015296
04-01-2019 16:17Gyorgy RethyStatusresolved => closed
04-01-2019 16:17Gyorgy RethyFixed in Version => 4.11.1 (published 2019-05)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014846) +
+ Jens Grabowski    +
+ 24-10-2017 13:05    +
+ 		+ + + + +
+ STF discussion: Requires proposal and possibly further discussion.
+
+
+
+ + + + + + + + + + +
+ (0014942) +
+ Julien Deltour    +
+ 13-12-2017 12:43    +
+ 		+ + + + +
+ Porposal uploaded.
+
+
+
+ + + + + + + + + + +
+ (0015055) +
+ Jacob Wieland - Spirent    +
+ 05-02-2018 12:15    +
+ 		+ + + + +
+ I have looked over the proposal.
+
+There are some small English grammar issues (missing articles and suchlike).
+
+There is no restriction section. (The same restrictions as for normal interleave shall apply)
+
+
+
+ + + + + + + + + + +
+ (0015184) +
+ Jacob Wieland - Spirent    +
+ 20-07-2018 09:00    +
+ 		+ + + + +
+ please review
+
+
+
+ + + + + + + + + + +
+ (0015189) +
+ Tomas Urban    +
+ 20-07-2018 11:41    +
+ 		+ + + + +
+ Reviewed, no issues found. The proposal is ready to be added to the next version of the core language standard.
+
+
+
+ + + + + + + + + + +
+ (0015296) +
+ Gyorgy Rethy    +
+ 04-01-2019 16:17    +
+ 		+ + + + +
+ Added to draft V4.10.2
+
+ + diff --git a/docs/mantis/CR7620.md b/docs/mantis/CR7620.md new file mode 100644 index 0000000000000000000000000000000000000000..5026cef17dfce39d40137c1c88e86598dca2f872 --- /dev/null +++ b/docs/mantis/CR7620.md @@ -0,0 +1,385 @@ + + + + + + + + + + + + + 0007620: Constraining of array types - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007620Part 01: TTCN-3 Core LanguageTechnicalpublic16-02-2017 15:0830-12-2017 19:48
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.9.1 (published 2017-05) 
Target Versionv4.10.1 (published 2018-05)Fixed in Versionv4.10.1 (published 2018-05) 
Clause Reference(s)6.2.13
Source (company - Author)STF 521
Summary0007620: Constraining of array types
DescriptionThe core language (in particular the BNF section) allows to add a constraint definition to an array type. However, it does not specify if the constraint is related to the member type (as it is the case of the record of and set of) or to the whole array.
+
+My opinion is that the former is the case, since list subtyping of structured types should be possible only "when defining a new type based on an existing parent type, but not directly at the declaration of the first parent type" (6.2.13.2). However, it would still be better to explicitly describe the behaviour of the contraint in this case. Besides, the array type is missing from the table 3 and it should be listed in 6.2.13.2 as a legal target of a list constraint.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR_7620.docx (268,985) 25-06-2017 14:33
http://oldforge.etsi.org/mantis/file_download.php?file_id=3642&type=bug
Issue History
Date ModifiedUsernameFieldChange
16-02-2017 15:08Tomas UrbanNew Issue
19-04-2017 11:21Gyorgy RethyNote Added: 0014578
24-04-2017 12:25szabadosNote Added: 0014601
02-05-2017 09:27Jacob Wieland - SpirentNote Added: 0014610
06-06-2017 11:50Jens GrabowskiNote Added: 0014623
06-06-2017 11:50Jens GrabowskiAssigned To => Kristóf Szabados
06-06-2017 11:50Jens GrabowskiStatusnew => assigned
25-06-2017 14:33Kristóf SzabadosFile Added: CR_7620.docx
25-06-2017 14:35Kristóf SzabadosNote Added: 0014712
25-06-2017 14:35Kristóf SzabadosAssigned ToKristóf Szabados => Tomas Urban
25-06-2017 14:35Kristóf SzabadosStatusassigned => confirmed
24-07-2017 16:12Tomas UrbanAssigned ToTomas Urban => Kristóf Szabados
24-07-2017 16:12Tomas UrbanStatusconfirmed => assigned
24-07-2017 16:12Tomas UrbanNote Added: 0014743
25-07-2017 08:51Jacob Wieland - SpirentNote Added: 0014747
25-07-2017 15:28Kristóf SzabadosFile Added: CR_7620_v2.docx
25-07-2017 15:31Kristóf SzabadosNote Added: 0014755
25-07-2017 15:31Kristóf SzabadosAssigned ToKristóf Szabados => Tomas Urban
25-07-2017 15:31Kristóf SzabadosStatusassigned => confirmed
25-07-2017 15:54Tomas UrbanFile Deleted: CR_7620_v2.docx
25-07-2017 15:55Tomas UrbanNote Added: 0014757
25-07-2017 15:55Tomas UrbanStatusconfirmed => resolved
25-07-2017 15:55Tomas UrbanResolutionopen => fixed
25-07-2017 15:55Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
30-12-2017 19:48Gyorgy RethyNote Added: 0014967
30-12-2017 19:48Gyorgy RethyStatusresolved => closed
30-12-2017 19:48Gyorgy RethyFixed in Version => v4.10.1 (published 2018-05)
30-12-2017 19:48Gyorgy RethyTarget Version => v4.10.1 (published 2018-05)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014578) +
+ Gyorgy Rethy    +
+ 19-04-2017 11:21    +
+ 		+ + + + +
+ test note, please ignore.
+
+
+
+ + + + + + + + + + +
+ (0014601) +
+ szabados    +
+ 24-04-2017 12:25    +
+ 		+ + + + +
+ yes, arrays are generally described as shorthand of record of descriptions, so they should behave similarly.
+
+
+
+ + + + + + + + + + +
+ (0014610) +
+ Jacob Wieland - Spirent    +
+ 02-05-2017 09:27    +
+ 		+ + + + +
+ agreed, in direct definitions with trailing constraints, always the element type is constrained.
+
+
+
+ + + + + + + + + + +
+ (0014623) +
+ Jens Grabowski    +
+ 06-06-2017 11:50    +
+ 		+ + + + +
+ STF discussion: Agreed
+
+
+
+ + + + + + + + + + +
+ (0014712) +
+ Kristóf Szabados    +
+ 25-06-2017 14:35    +
+ 		+ + + + +
+ Please review the uploaded proposal document
+
+
+
+ + + + + + + + + + +
+ (0014743) +
+ Tomas Urban    +
+ 24-07-2017 16:12    +
+ 		+ + + + +
+ I am fine with most of the changes in the proposal, but it ignores the fact that constraints can appear directly in the array type definition, e.g:
+type charstring MyArray[1..2] ({"aa", "bb"}, { "cc", "dd"})
+
+The BNF allows it in the rule 41:
+41.SubTypeDef ::= Type (Identifier | AddressKeyword) [ArrayDef] [SubTypeSpec]
+
+We could also disallow such a constraint by changing the rule to:
+41.SubTypeDef ::= Type (Identifier | AddressKeyword) [ ArrayDef | SubTypeSpec ]
+
+
+
+ + + + + + + + + + +
+ (0014747) +
+ Jacob Wieland - Spirent    +
+ 25-07-2017 08:51    +
+ 		+ + + + +
+ But for record of, the subtype constraint directly in the definition is applied to the element type and not the array type itself, so
+
+type charstring MyArray[1..2] ({"aa", "bb"}, { "cc", "dd"})
+
+wouldn't be semantically valid.
+
+To achieve that you need to use a subtype definition of the unconstrained charstring array type.
+
+
+
+ + + + + + + + + + +
+ (0014755) +
+ Kristóf Szabados    +
+ 25-07-2017 15:31    +
+ 		+ + + + +
+ updated the BNF rule 41 too.
+Please check.
+
+
+
+ + + + + + + + + + +
+ (0014757) +
+ Tomas Urban    +
+ 25-07-2017 15:55    +
+ 		+ + + + +
+ After discussion, we returned back to the first resolution which should resolve the raised issue completely.
+
+
+
+ + + + + + + + + + +
+ (0014967) +
+ Gyorgy Rethy    +
+ 30-12-2017 19:48    +
+ 		+ + + + +
+ Added to draft V4.9.2
+
+ + diff --git a/docs/mantis/CR7624.md b/docs/mantis/CR7624.md new file mode 100644 index 0000000000000000000000000000000000000000..c4e8f0a9ffc82de9da409851c57124d4b20b283c --- /dev/null +++ b/docs/mantis/CR7624.md @@ -0,0 +1,343 @@ + + + + + + + + + + + + + 0007624: Local declarations should be allowed to be declared everywhere in a statement block - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007624Part 01: TTCN-3 Core LanguageNew Featurepublic07-03-2017 11:0230-12-2017 17:20
ReporterJacob Wieland - Spirent 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.9.1 (published 2017-05) 
Target Versionv4.10.1 (published 2018-05)Fixed in Versionv4.10.1 (published 2018-05) 
Clause Reference(s)A.1.6.1.4
Source (company - Author)Spirent - Jacob Wieland
Summary0007624: Local declarations should be allowed to be declared everywhere in a statement block
DescriptionThe current situation that a statement block has first a sequence of declarations and then a sequence of non-declaration statements should be changed so that a statement block shall consist of a sequence of declaration and non-declaration statements with the other restrictions as before (i.e. that you can not forward-reference an entity that is declared textually after the reference).
+
+The reason for this is harmonization with other languages. Modern programming languages allow declaration anywhere and ofttimes it makes code more clear to read if the declared item is declared textually close to its usage.
+
+It would also make the usage of constants more flexible. Constants need to be initialized in their declaration, therefore all information for that initialization must be available already at the place of the declaration. If the value is dependent on some behavior before the usage of the constant, this can pose problems at the moment (leading to workarounds that you need a helper-function to compute the const-initialization-value).
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7624-1.docx (44,390) 08-06-2017 15:55
http://oldforge.etsi.org/mantis/file_download.php?file_id=3610&type=bug
docx CR7624-2.docx (36,423) 09-06-2017 09:43
http://oldforge.etsi.org/mantis/file_download.php?file_id=3627&type=bug
Issue History
Date ModifiedUsernameFieldChange
07-03-2017 11:02Jacob Wieland - SpirentNew Issue
07-03-2017 11:03Jacob Wieland - SpirentSummaryVariables should be allowed to be declared everywhere in a statement block (instead of a statement) => Local declarations should be allowed to be declared everywhere in a statement block
19-04-2017 15:02szabadosNote Added: 0014588
19-04-2017 15:16Jacob Wieland - SpirentNote Added: 0014589
06-06-2017 12:15Jens GrabowskiNote Added: 0014625
06-06-2017 12:15Jens GrabowskiAssigned To => Tomas Urban
06-06-2017 12:15Jens GrabowskiStatusnew => assigned
07-06-2017 09:12Tomas UrbanNote Added: 0014638
08-06-2017 15:55Tomas UrbanFile Added: CR7624-1.docx
08-06-2017 15:56Tomas UrbanNote Added: 0014655
08-06-2017 15:56Tomas UrbanAssigned ToTomas Urban => Jacob Wieland - Spirent
08-06-2017 15:56Tomas UrbanStatusassigned => confirmed
09-06-2017 09:43Jacob Wieland - SpirentFile Added: CR7624-2.docx
09-06-2017 09:44Jacob Wieland - SpirentStatusconfirmed => new
09-06-2017 09:44Jacob Wieland - SpirentNote Added: 0014687
09-06-2017 09:44Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Kristóf Szabados
09-06-2017 09:44Jacob Wieland - SpirentStatusnew => confirmed
09-06-2017 14:36Kristóf SzabadosNote Added: 0014698
09-06-2017 14:36Kristóf SzabadosStatusconfirmed => resolved
09-06-2017 14:36Kristóf SzabadosResolutionopen => fixed
09-06-2017 14:36Kristóf SzabadosAssigned ToKristóf Szabados => Gyorgy Rethy
07-09-2017 08:44Tomas UrbanProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
30-12-2017 17:20Gyorgy RethyNote Added: 0014958
30-12-2017 17:20Gyorgy RethyStatusresolved => closed
30-12-2017 17:20Gyorgy RethyProduct Version => v4.9.1 (published 2017-05)
30-12-2017 17:20Gyorgy RethyFixed in Version => v4.10.1 (published 2018-05)
30-12-2017 17:20Gyorgy RethyTarget Version => v4.10.1 (published 2018-05)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014588) +
+ szabados    +
+ 19-04-2017 15:02    +
+ 		+ + + + +
+ In Titan we allow declarations everywhere in the statement block.
+
+Maybe the BNF could be modified like this:
+168.StatementBlock ::= "{" [FunctionDefList] [FunctionStatementList] "}"
+169.FunctionDefList ::= {(FunctionLocalDef | FunctionLocalInst) [WithStatement]
+                          [SemiColon]}+
+170.FunctionStatementList ::= {FunctionStatement [SemiColon]}+
+171.FunctionLocalInst ::= VarInstance | TimerInstance
+172.FunctionLocalDef ::= ConstDef | TemplateDef
+173.FunctionStatement ::= ConfigurationStatements |
+                           TimerStatements |
+                           CommunicationStatements |
+                           BasicStatements |
+                           BehaviourStatements |
+                           SetLocalVerdict |
+                           SUTStatements |
+                           TestcaseOperation
+
+
+==>
+
+StatementBlock ::= "{" [FunctionStatementOrDefList ] "}"
+FunctionStatementOrDefList ::= {FunctionStatementOrDef [SemiColon] }+
+FunctionStatementOrDef ::= FunctionLocalInst |
+                FunctionLocalDef |
+                FunctionStatement
+
+FunctionLocalInst ::= (VarInstance | TimerInstance) [WithStatement]
+
+FunctionLocalDef ::= ( ConstDef | TemplateDef ) [WithStatement]
+
+FunctionStatement ::= ( ConfigurationStatements |
+                           TimerStatements |
+                           CommunicationStatements |
+                           BasicStatements |
+                           BehaviourStatements |
+                           SetLocalVerdict |
+                           SUTStatements |
+                           TestcaseOperation )
+
+
+
+ + + + + + + + + + +
+ (0014589) +
+ Jacob Wieland - Spirent    +
+ 19-04-2017 15:16    +
+ 		+ + + + +
+ we also have had this feature in our tool in non-standard-compliant mode since the beginning, so, I guess, it really makes sense.
+
+
+
+ + + + + + + + + + +
+ (0014625) +
+ Jens Grabowski    +
+ 06-06-2017 12:15    +
+ 		+ + + + +
+ STF discussion: ok, check with Tomas
+
+
+
+ + + + + + + + + + +
+ (0014638) +
+ Tomas Urban    +
+ 07-06-2017 09:12    +
+ 		+ + + + +
+ We have the described feature in our tool as well. I will prepare a detailed draft so that we can discuss the details.
+
+
+
+ + + + + + + + + + +
+ (0014655) +
+ Tomas Urban    +
+ 08-06-2017 15:56    +
+ 		+ + + + +
+ Proposal draft uploaded. Please check.
+
+
+
+ + + + + + + + + + +
+ (0014687) +
+ Jacob Wieland - Spirent    +
+ 09-06-2017 09:44    +
+ 		+ + + + +
+ please review
+
+
+
+ + + + + + + + + + +
+ (0014698) +
+ Kristóf Szabados    +
+ 09-06-2017 14:36    +
+ 		+ + + + +
+ The resolution is ready to be added to the next version of the core language specification
+
+
+
+ + + + + + + + + + +
+ (0014958) +
+ Gyorgy Rethy    +
+ 30-12-2017 17:20    +
+ 		+ + + + +
+ Added to draft V4.9.2
+
+ + diff --git a/docs/mantis/CR7625.md b/docs/mantis/CR7625.md new file mode 100644 index 0000000000000000000000000000000000000000..4597b0474787747c1554558e52d51088a522fe68 --- /dev/null +++ b/docs/mantis/CR7625.md @@ -0,0 +1,181 @@ + + + + + + + + + + + + + 0007625: Harminozation: the behaviour extension package does not mention modifiers when describing compatibility. - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Behaviour Types (ES 202 785)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007625Ext Pack: Behaviour Types (ES 202 785)Clarificationpublic07-03-2017 13:3703-01-2018 11:59
Reporterszabados 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv1.4.1 (published 2015-06) 
Target VersionFixed in Version 
Clause Reference(s)6.3 (inside section 5.2)
Source (company - Author)LM. Ericsson
Summary0007625: Harminozation: the behaviour extension package does not mention modifiers when describing compatibility.
DescriptionThe core TTCN-3 standard and the behaviour types extension is not in synch.
+
+The behaviour type extension states in section 6.3.5 (describing the compatibility of behaviour type)
+"
+The parameter list of an object is compatible with the parameter list of a type if the order of the parameters is identical,
+as well as direction, kind, type, name of the parameters, and whether a default exists. If the parameter is of kind
+template
+, then also potential template restrictions have to be identical. Compatibility of parameter lists applies to the
+type parameter list, if exists (i.e. when the advanced parameterization package [6] is also supported and a type
+parameter list is defined), and the value parameter list separately.
+"
+
+I believe this should be extended to require identical modifiers (@lazy, @fuzzy, etc..) at formal parameters of the object and type.
+And modifiers of the whole object and behaviour type should also be the same.
+For example:
+- if the behaviour type has a "@deterministic" modifier it should be compatible only with functions also having "@deterministic" modifier.
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR-7625.docx (33,580) 25-10-2017 11:04
http://oldforge.etsi.org/mantis/file_download.php?file_id=3696&type=bug
Issue History
Date ModifiedUsernameFieldChange
07-03-2017 13:37szabadosNew Issue
06-06-2017 14:37Jens GrabowskiAssigned To => Jens Grabowski
06-06-2017 14:37Jens GrabowskiStatusnew => assigned
24-10-2017 13:10Jens GrabowskiNote Added: 0014847
25-10-2017 11:04Jens GrabowskiFile Added: CR-7625.docx
25-10-2017 11:05Jens GrabowskiNote Added: 0014870
25-10-2017 11:05Jens GrabowskiAssigned ToJens Grabowski => Kristof.Szabados
02-01-2018 19:53Kristóf SzabadosNote Added: 0014988
02-01-2018 19:58Kristóf SzabadosNote Added: 0014989
03-01-2018 11:59Jens GrabowskiStatusassigned => closed
03-01-2018 11:59Jens GrabowskiAssigned ToKristof.Szabados => Jens Grabowski
03-01-2018 11:59Jens GrabowskiResolutionopen => fixed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014847) +
+ Jens Grabowski    +
+ 24-10-2017 13:10    +
+ 		+ + + + +
+ (To be implemented until end of 2017)
+
+
+
+ + + + + + + + + + +
+ (0014870) +
+ Jens Grabowski    +
+ 25-10-2017 11:05    +
+ 		+ + + + +
+ Kristof, can you check if the minimal textual addition is sufficient?
+
+
+
+ + + + + + + + + + +
+ (0014988) +
+ Kristóf Szabados    +
+ 02-01-2018 19:53    +
+ 		+ + + + +
+ The updated text looks good and sufficient to me.
+
+
+
+ + + + + + + + + + +
+ (0014989) +
+ Kristóf Szabados    +
+ 02-01-2018 19:58    +
+ 		+ + + + +
+ For some reason I don't have rights to resolve it
+
+ + diff --git a/docs/mantis/CR7626.md b/docs/mantis/CR7626.md new file mode 100644 index 0000000000000000000000000000000000000000..7318b411023a217199da7614ddfcfa59d72a4bd0 --- /dev/null +++ b/docs/mantis/CR7626.md @@ -0,0 +1,104 @@ + + + + + + + + + + + + + 0007626: editorial: syntactical structure parts are not properly "spaced"/"indented" - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Config & Deployment Support (ES 202 781)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007626Ext Pack: Config & Deployment Support (ES 202 781)Editorialpublic07-03-2017 13:5102-01-2018 12:19
Reporterszabados 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv1.4.1 (published 2015-06) 
Target VersionFixed in Version 
Clause Reference(s)5.2.0
Source (company - Author)L.M.Ericsson
TS versionn/a
Summary0007626: editorial: syntactical structure parts are not properly "spaced"/"indented"
DescriptionIn section 5.2.0 of configuration and deployment extension thesyntactic description part is unnecessarily hard to read/understand.
+For exmaple:
+" (in{InnerInType [from {OuterInType with InFunction"("")"[","]}+][","]}+| "
+
+This could be made much easier to read if there were some more spaces inserted.
+
+In other parts of the document these parts are much more readable:
+for example this: "(" TestcaseRef "(" [ { TemplateInstance [","] } ] ...
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR-7626-V170609.docx (35,883) 09-06-2017 17:07
http://oldforge.etsi.org/mantis/file_download.php?file_id=3641&type=bug
Issue History
Date ModifiedUsernameFieldChange
07-03-2017 13:51szabadosNew Issue
06-06-2017 14:35Jens GrabowskiAssigned To => Jens Grabowski
06-06-2017 14:35Jens GrabowskiStatusnew => assigned
09-06-2017 17:07Jens GrabowskiFile Added: CR-7626-V170609.docx
09-06-2017 17:07Jens GrabowskiNote Added: 0014707
09-06-2017 17:07Jens GrabowskiAssigned ToJens Grabowski => Kristóf Szabados
09-06-2017 17:08Jens GrabowskiStatusassigned => confirmed
24-07-2017 12:41Kristóf SzabadosNote Added: 0014734
24-07-2017 12:41Kristóf SzabadosStatusconfirmed => resolved
24-07-2017 12:41Kristóf SzabadosResolutionopen => fixed
24-07-2017 12:41Kristóf SzabadosAssigned ToKristóf Szabados => Jens Grabowski
02-01-2018 12:19Jens GrabowskiStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014707) +
+ Jens Grabowski    +
+ 09-06-2017 17:07    +
+ 		+ + + + +
+ Please check resolution proposal.
+
+
+
+ + + + + + + + + + +
+ (0014734) +
+ Kristóf Szabados    +
+ 24-07-2017 12:41    +
+ 		+ + + + +
+ The proposed fix is ready to be used in the next version of the specification.
+
+ + diff --git a/docs/mantis/CR7628.md b/docs/mantis/CR7628.md new file mode 100644 index 0000000000000000000000000000000000000000..8c913a3f3d7b9363782a99f7895454c7e045a35b --- /dev/null +++ b/docs/mantis/CR7628.md @@ -0,0 +1,309 @@ + + + + + + + + + + + + + 0007628: concatenation with wildcards should be allowed also for charstring types - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007628Part 01: TTCN-3 Core LanguageNew Featurepublic09-03-2017 12:1930-12-2017 17:10
ReporterJacob Wieland - Spirent 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.9.1 (published 2017-05) 
Target Versionv4.10.1 (published 2018-05)Fixed in Versionv4.10.1 (published 2018-05) 
Clause Reference(s)15.11
Source (company - Author)Spirent - Jacob Wieland
Summary0007628: concatenation with wildcards should be allowed also for charstring types
DescriptionHarmonization:
+
+At the moment, it is allowed to concatenate string literals and (length-restricted) wildcards (*,?) for the binary string types, but not for the character string types.
+
+For consistency's sake, all string types should allow the same for concatenation. Singling charstring types out because there is a different pattern mechanism that has a similar effect seems an inconsistency which is hard to understand by the user (who just sees this as an arbitrary restriction with no real purpose).
+
+Dropping a restriction does not create backward compatibility issues.
+
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0007525closed Jens Grabowski Ext Pack: Advanced Matching (ES 203 022) allow repetition (and maybe other regular expression syntax) also for binary string types 
related to 0007629closed Jens Grabowski Ext Pack: Advanced Matching (ES 203 022) concatenation of arbitrary present list/string templates should be allowed 
Attached Filesdocx CR7628-v1.docx (191,831) 08-06-2017 15:09
http://oldforge.etsi.org/mantis/file_download.php?file_id=3609&type=bug
docx CR7628-v2.docx (168,395) 09-06-2017 12:31
http://oldforge.etsi.org/mantis/file_download.php?file_id=3633&type=bug
docx CR7628-v3.docx (194,486) 09-06-2017 15:13
http://oldforge.etsi.org/mantis/file_download.php?file_id=3636&type=bug
docx CR7628-v4.docx (192,910) 26-07-2017 10:00
http://oldforge.etsi.org/mantis/file_download.php?file_id=3663&type=bug
Issue History
Date ModifiedUsernameFieldChange
09-03-2017 12:19Jacob Wieland - SpirentNew Issue
18-04-2017 11:27szabadosNote Added: 0014569
06-06-2017 14:01Jens GrabowskiNote Added: 0014627
06-06-2017 14:01Jens GrabowskiAssigned To => Tomas Urban
06-06-2017 14:01Jens GrabowskiStatusnew => assigned
08-06-2017 15:09Tomas UrbanNote Added: 0014654
08-06-2017 15:09Tomas UrbanAssigned ToTomas Urban => Jacob Wieland - Spirent
08-06-2017 15:09Tomas UrbanStatusassigned => confirmed
08-06-2017 15:09Tomas UrbanFile Added: CR7628-v1.docx
09-06-2017 12:31Jacob Wieland - SpirentFile Added: CR7628-v2.docx
09-06-2017 12:31Jacob Wieland - SpirentStatusconfirmed => new
09-06-2017 12:32Jacob Wieland - SpirentNote Added: 0014695
09-06-2017 12:32Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Tomas Urban
09-06-2017 12:32Jacob Wieland - SpirentStatusnew => confirmed
09-06-2017 15:13Tomas UrbanFile Added: CR7628-v3.docx
09-06-2017 15:14Tomas UrbanNote Added: 0014702
09-06-2017 15:14Tomas UrbanAssigned ToTomas Urban => Jacob Wieland - Spirent
26-07-2017 10:00Tomas UrbanFile Added: CR7628-v4.docx
26-07-2017 10:00Tomas UrbanNote Added: 0014777
26-07-2017 14:01Jacob Wieland - SpirentNote Added: 0014781
26-07-2017 14:01Jacob Wieland - SpirentStatusconfirmed => resolved
26-07-2017 14:01Jacob Wieland - SpirentResolutionopen => fixed
26-07-2017 14:01Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
07-09-2017 08:43Tomas UrbanProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
07-09-2017 09:01Tomas UrbanRelationship addedrelated to 0007525
07-09-2017 09:01Tomas UrbanRelationship addedrelated to 0007629
30-12-2017 17:10Gyorgy RethyNote Added: 0014957
30-12-2017 17:10Gyorgy RethyStatusresolved => closed
30-12-2017 17:10Gyorgy RethyProduct Version => v4.9.1 (published 2017-05)
30-12-2017 17:10Gyorgy RethyFixed in Version => v4.10.1 (published 2018-05)
30-12-2017 17:10Gyorgy RethyTarget Version => v4.10.1 (published 2018-05)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014569) +
+ szabados    +
+ 18-04-2017 11:27    +
+ 		+ + + + +
+ Sounds fine.
+
+
+
+ + + + + + + + + + +
+ (0014627) +
+ Jens Grabowski    +
+ 06-06-2017 14:01    +
+ 		+ + + + +
+ Tomas, check if ok for you.
+
+
+
+ + + + + + + + + + +
+ (0014654) +
+ Tomas Urban    +
+ 08-06-2017 15:09    +
+ 		+ + + + +
+ Proposal draft uploaded. Please check.
+
+
+
+ + + + + + + + + + +
+ (0014695) +
+ Jacob Wieland - Spirent    +
+ 09-06-2017 12:32    +
+ 		+ + + + +
+ please review my changes
+
+
+
+ + + + + + + + + + +
+ (0014702) +
+ Tomas Urban    +
+ 09-06-2017 15:14    +
+ 		+ + + + +
+ Minor changes made (mostly added "combined template"). Please check.
+
+
+
+ + + + + + + + + + +
+ (0014777) +
+ Tomas Urban    +
+ 26-07-2017 10:00    +
+ 		+ + + + +
+ Explanation to the example with a parameterized template added.
+
+
+
+ + + + + + + + + + +
+ (0014781) +
+ Jacob Wieland - Spirent    +
+ 26-07-2017 14:01    +
+ 		+ + + + +
+ fine with me
+
+
+
+ + + + + + + + + + +
+ (0014957) +
+ Gyorgy Rethy    +
+ 30-12-2017 17:10    +
+ 		+ + + + +
+ Added to draft V4.9.2
+
+ + diff --git a/docs/mantis/CR7629.md b/docs/mantis/CR7629.md new file mode 100644 index 0000000000000000000000000000000000000000..1bea150a3d5e2bb1b0154ed0668885dff8748671 --- /dev/null +++ b/docs/mantis/CR7629.md @@ -0,0 +1,103 @@ + + + + + + + + + + + + + 0007629: concatenation of arbitrary present list/string templates should be allowed - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Advanced Matching (ES 203 022)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007629Ext Pack: Advanced Matching (ES 203 022)New Featurepublic09-03-2017 12:3203-01-2018 13:04
ReporterJacob Wieland - Spirent 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Clause Reference(s)15.11
Source (company - Author)Spirent - Jacob Wieland
TS version?
Summary0007629: concatenation of arbitrary present list/string templates should be allowed
DescriptionAt the moment, concatenation is only allowed between list values/string literals, wildcards and single-length-restricted wildcards.
+
+This should be enhanced to allow concatenation between arbitrary list/string templates (of the same root type), where the semantics of the concatenated template is the following:
+
+if T1 ... Tn are list/string templates and L(Ti) is the set of values matched by template Ti, then L(T1 & ... & Tn) == { s1 & ... & sn | si from L(Ti) for all i in 1 to n } (which could be written short as L(T1) & ... & L(Tn)), i.e. the set of concatenated values from the different value-sets.
+
+Obviously, concatenation templates must be comprised only of templates with the present template restriction as concatenation with omit is not allowed.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0007628closed Gyorgy Rethy Part 01: TTCN-3 Core Language concatenation with wildcards should be allowed also for charstring types 
related to 0007525closed Jens Grabowski Ext Pack: Advanced Matching (ES 203 022) allow repetition (and maybe other regular expression syntax) also for binary string types 
Attached Filesdocx CR7629-v1.docx (133,398) 07-09-2017 09:25
http://oldforge.etsi.org/mantis/file_download.php?file_id=3680&type=bug
docx CR7629-v2.docx (133,800) 24-10-2017 15:30
http://oldforge.etsi.org/mantis/file_download.php?file_id=3686&type=bug
Issue History
Date ModifiedUsernameFieldChange
09-03-2017 12:32Jacob Wieland - SpirentNew Issue
06-06-2017 14:34Jens GrabowskiAssigned To => Jens Grabowski
06-06-2017 14:34Jens GrabowskiStatusnew => assigned
04-09-2017 09:29Jens GrabowskiAssigned ToJens Grabowski => Tomas Urban
07-09-2017 09:01Tomas UrbanRelationship addedrelated to 0007628
07-09-2017 09:01Tomas UrbanRelationship addedrelated to 0007525
07-09-2017 09:25Tomas UrbanFile Added: CR7629-v1.docx
07-09-2017 09:25Tomas UrbanNote Added: 0014817
07-09-2017 09:25Tomas UrbanAssigned ToTomas Urban => Jacob Wieland - Spirent
07-09-2017 09:25Tomas UrbanStatusassigned => confirmed
24-10-2017 15:30Tomas UrbanFile Added: CR7629-v2.docx
24-10-2017 15:44Jacob Wieland - SpirentNote Added: 0014854
24-10-2017 15:44Jacob Wieland - SpirentStatusconfirmed => resolved
24-10-2017 15:44Jacob Wieland - SpirentFixed in Version => Next Version
24-10-2017 15:44Jacob Wieland - SpirentResolutionopen => fixed
24-10-2017 15:44Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Jens Grabowski
03-01-2018 13:04Jens GrabowskiStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014817) +
+ Tomas Urban    +
+ 07-09-2017 09:25    +
+ 		+ + + + +
+ Resolution uploaded. Please check.
+
+
+
+ + + + + + + + + + +
+ (0014854) +
+ Jacob Wieland - Spirent    +
+ 24-10-2017 15:44    +
+ 		+ + + + +
+ resolved
+
+ + diff --git a/docs/mantis/CR7630.md b/docs/mantis/CR7630.md new file mode 100644 index 0000000000000000000000000000000000000000..9109de2d48dc25ec74896ad27c3b65fda8118e44 --- /dev/null +++ b/docs/mantis/CR7630.md @@ -0,0 +1,272 @@ + + + + + + + + + + + + + 0007630: example creating empty template is wrong - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007630Part 01: TTCN-3 Core LanguageClarificationpublic09-03-2017 12:4030-12-2017 20:02
ReporterJacob Wieland - Spirent 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.9.1 (published 2017-05) 
Target Versionv4.10.1 (published 2018-05)Fixed in Versionv4.10.1 (published 2018-05) 
Clause Reference(s)15.11
Source (company - Author)Spirent - Jacob Wieland
Summary0007630: example creating empty template is wrong
Descriptionin section 15.11 in EXAMPLE 1 can be found the following sub-example:
+
+"
+template octetstring mw_myoct3 := ('ABCD'O & ? length(2)) length (1..3);
+ // However, this is correct but will not match any value;
+"
+
+According to the definition of template in the definitions in section 3, a template must match at least one value.
+
+"
+A TTCN-3 template identifies a subset of the
+values of its type (where the subset may contain a single instance of the type, several instances or all instances) or the
+matching mechanism omit.
+"
+
+Since great pains have been taken to assure that no empty types (types containing no value) can be defined in TTCN-3, the above definition excludes also all empty template definitions from validity.
+
+Therefore, the example is wrong insofar that it explicitly allows such an empty template and should be corrected.
+
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc 7630.doc (23,552) 09-06-2017 08:59
http://oldforge.etsi.org/mantis/file_download.php?file_id=3624&type=bug
Issue History
Date ModifiedUsernameFieldChange
09-03-2017 12:40Jacob Wieland - SpirentNew Issue
11-04-2017 15:22szabadosNote Added: 0014552
12-04-2017 08:17Jacob Wieland - SpirentNote Added: 0014553
12-04-2017 08:17Jacob Wieland - SpirentNote Deleted: 0014553
12-04-2017 08:20Jacob Wieland - SpirentNote Added: 0014554
12-04-2017 08:22Jacob Wieland - SpirentNote Added: 0014555
12-04-2017 08:24Jacob Wieland - SpirentNote Added: 0014556
12-04-2017 08:24Jacob Wieland - SpirentNote Deleted: 0014555
12-04-2017 08:24Jacob Wieland - SpirentNote Deleted: 0014554
17-04-2017 13:18szabadosNote Added: 0014557
17-04-2017 13:18szabadosNote Deleted: 0014557
17-04-2017 13:26szabadosNote Added: 0014558
17-04-2017 13:26szabadosNote Deleted: 0014558
17-04-2017 13:26szabadosNote Added: 0014559
17-04-2017 13:26szabadosNote Deleted: 0014559
17-04-2017 13:28szabadosNote Added: 0014560
17-04-2017 13:28szabadosNote Deleted: 0014560
18-04-2017 07:12szabadosNote Added: 0014564
18-04-2017 07:12szabadosNote Deleted: 0014564
18-04-2017 07:16szabadosNote Added: 0014565
18-04-2017 07:16szabadosNote Deleted: 0014565
18-04-2017 07:18szabadosNote Added: 0014566
18-04-2017 07:19szabadosNote Deleted: 0014566
18-04-2017 07:21szabadosNote Added: 0014567
06-06-2017 14:07Jens GrabowskiProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
06-06-2017 14:08Jens GrabowskiAssigned To => Julien Deltour
06-06-2017 14:08Jens GrabowskiStatusnew => assigned
09-06-2017 08:59Julien DeltourFile Added: 7630.doc
09-06-2017 08:59Julien DeltourNote Added: 0014684
09-06-2017 08:59Julien DeltourStatusassigned => confirmed
09-06-2017 08:59Julien DeltourAssigned ToJulien Deltour => Jacob Wieland - Spirent
09-06-2017 08:59Julien DeltourStatusconfirmed => assigned
09-06-2017 15:13Jacob Wieland - SpirentNote Added: 0014701
09-06-2017 15:13Jacob Wieland - SpirentStatusassigned => resolved
09-06-2017 15:13Jacob Wieland - SpirentFixed in Version => v4.10.1 (published 2018-05)
09-06-2017 15:13Jacob Wieland - SpirentResolutionopen => fixed
09-06-2017 15:13Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
30-12-2017 20:02Gyorgy RethyNote Added: 0014970
30-12-2017 20:02Gyorgy RethyStatusresolved => closed
30-12-2017 20:02Gyorgy RethyProduct Version => v4.9.1 (published 2017-05)
30-12-2017 20:02Gyorgy RethyTarget Version => v4.10.1 (published 2018-05)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014552) +
+ szabados    +
+ 11-04-2017 15:22    +
+ 		+ + + + +
+ If I understand correctly it should be corrected to:
+template octetstring mw_myoct3 := ('ABCD'O & ? length(2)) length (4);
+// However, this is correct.
+// results in the template 'ABCD??'O
+
+Maybe we should also add an example, which demonstrates that templates that look fine might actually not match to anything. This is incorrect ... but given the complexity tools might not be able to detect this situation during static analysis.
+
+
+
+ + + + + + + + + + +
+ (0014556) +
+ Jacob Wieland - Spirent    +
+ 12-04-2017 08:24    +
+ 		+ + + + +
+ In principle,the restriction of no empty-set-templates is a bit pointless. For me, this should just be a warning and not an error, same as if I write down if false or a false comparison of 1 and 2.
+
+I mean, what harm can an empty template do? It just never matches, so all branches it guards will not be entered.
+
+Yes, if they are empty because of a mistake the test writer made, the tool should help and point it out. But, the same can happen with a template that accidentally only matches 10 values instead of an infinte number, so the distinction between 0 and non-0 seems a bit arbitrary.
+
+The same argument can be made for empty types. What harm can they do? Absolutely none. You simply cannot instantiate any value for those types and their emptiness propagates to surrounding record-layers, if they are the type of non-optional fields. Thus, if they are empty by mistake, the mistake will become apparent as soon as an instance is to be created.
+
+
+
+ + + + + + + + + + +
+ (0014567) +
+ szabados    +
+ 18-04-2017 07:21    +
+ 		+ + + + +
+ Please note that detecting and reporting quality problems does make a difference.
+
+A template not matching anything -whether because of a typo or architectural misunderstandings- can lead to an incorrect testcase:
+- waste of execution time
+- increased maintenance cost
+- incorrect/misleading result ... leading to faults left in the products
+
+A distinction between 0/unbound and non-0/bound_with_incorrect_value sound like a technical and theoretical limitation:
+At current level of call/data flow checking ... 0/unbound -issues are much easier to detect than off-by-1 issues.
+And I believe it might also be theoretically impossible to tell just from the source code, that the requirement of a protocol was mentioning an off-by-1 value.
+
+
+
+ + + + + + + + + + +
+ (0014684) +
+ Julien Deltour    +
+ 09-06-2017 08:59    +
+ 		+ + + + +
+ Please review the proposal
+
+
+
+ + + + + + + + + + +
+ (0014701) +
+ Jacob Wieland - Spirent    +
+ 09-06-2017 15:13    +
+ 		+ + + + +
+ looks fine
+
+
+
+ + + + + + + + + + +
+ (0014970) +
+ Gyorgy Rethy    +
+ 30-12-2017 20:02    +
+ 		+ + + + +
+ Added to draft V4.9.2
+
+ + diff --git a/docs/mantis/CR7631.md b/docs/mantis/CR7631.md new file mode 100644 index 0000000000000000000000000000000000000000..effe560fe36aae6b63b5e5546a1d2c29c6701357 --- /dev/null +++ b/docs/mantis/CR7631.md @@ -0,0 +1,139 @@ + + + + + + + + + + + + + 0007631: Typos in the XML specification - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007631Part 09: Using XML with TTCN-3Editorialpublic09-03-2017 14:3405-01-2018 11:07
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritylowSeveritytrivialReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.7.1 (published 2016-07) 
Target Versionv4.9.1 (published 2018-05)Fixed in Versionv4.9.1 (published 2018-05) 
Clause Reference(s)5.2.2, 7.1.5, 7.4.1, 7.3, 6.1
For STF discussion
Source (company - Author)STF 521
Summary0007631: Typos in the XML specification
DescriptionSeveral typos in the specification shall be fixed:
+
+- Section 5.2.2: two colons in "Will be mapped to the TTCN-3 type assignment e.g. as::"
+- Section 7.1.5: two colons in "Will be translated to TTCN-3 e.g. as::"
+- Section 7.4.1: "itype typename E17" instead of "type Typename E17"
+- Section 7.6.1.1: word "translatde" is misspelled in: "Will be translatde to the TTCN-3 module, e.g. as:"
+- Section 6.1.7, 6.1.8, 6.1.9, 6.1.10: different colour of the text than black
+- Section 7.3: type name starting with low-case letter: "type typename E16a" (should be "type Typename E16a")
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR_7631.docx (178,873) 07-06-2017 10:27
http://oldforge.etsi.org/mantis/file_download.php?file_id=3598&type=bug
Issue History
Date ModifiedUsernameFieldChange
09-03-2017 14:34Tomas UrbanNew Issue
06-06-2017 14:32Jens GrabowskiAssigned To => Kristóf Szabados
06-06-2017 14:32Jens GrabowskiStatusnew => assigned
07-06-2017 10:27szabadosFile Added: CR_7631.docx
09-06-2017 05:59Kristóf SzabadosNote Added: 0014671
09-06-2017 05:59Kristóf SzabadosAssigned ToKristóf Szabados => Tomas Urban
09-06-2017 05:59Kristóf SzabadosStatusassigned => confirmed
09-06-2017 08:36Tomas UrbanNote Added: 0014677
09-06-2017 08:36Tomas UrbanStatusconfirmed => resolved
09-06-2017 08:36Tomas UrbanResolutionopen => fixed
09-06-2017 08:36Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
05-01-2018 11:07Gyorgy RethyNote Added: 0015006
05-01-2018 11:07Gyorgy RethyFixed in Version => v4.9.1 (published 2018-05)
05-01-2018 11:07Gyorgy RethyTarget Version => v4.9.1 (published 2018-05)
05-01-2018 11:07Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014671) +
+ Kristóf Szabados    +
+ 09-06-2017 05:59    +
+ 		+ + + + +
+ Please check
+
+
+
+ + + + + + + + + + +
+ (0014677) +
+ Tomas Urban    +
+ 09-06-2017 08:36    +
+ 		+ + + + +
+ Ready to be added to the new version of the specification.
+
+
+
+ + + + + + + + + + +
+ (0015006) +
+ Gyorgy Rethy    +
+ 05-01-2018 11:07    +
+ 		+ + + + +
+ Corrected in draft V4.8.3.
+
+ + diff --git a/docs/mantis/CR7634.md b/docs/mantis/CR7634.md new file mode 100644 index 0000000000000000000000000000000000000000..a7bd174d87e4e258e25974fa0d1e7a70e4e34658 --- /dev/null +++ b/docs/mantis/CR7634.md @@ -0,0 +1,180 @@ + + + + + + + + + + + + + 0007634: Missing prefixes in facet mapping examples - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007634Part 09: Using XML with TTCN-3Editorialpublic13-03-2017 14:0205-01-2018 11:42
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.7.1 (published 2016-07) 
Target Versionv4.9.1 (published 2018-05)Fixed in Versionv4.9.1 (published 2018-05) 
Clause Reference(s)6.1
For STF discussion
Source (company - Author)STF 521
Summary0007634: Missing prefixes in facet mapping examples
DescriptionThe examples on mapping of facets contain several XML elements and type attributes without the xsd prefix:
+
+6.1.7:
+base="float"
+<restriction base="float">
+<minInclusive value="NaN"/>
+
+6.1.8:
+base="positiveInteger"
+<maxInclusive value="100"/>
+base="float"
+<maxInclusive value="-5"/>
+base="float"
+<maxInclusive value="INF"/>
+base="float"
+<maxInclusive value="NaN"/>
+
+6.1.9
+base="integer"
+<minExclusive value="-5"/>
+base="float"
+<minExclusive value="-5"/>
+<minExclusive value="-6"/>
+base="float"
+<minExclusive value="INF"/>
+
+6.1.10
+base="positiveInteger"
+<maxExclusive value="100"/>
+base="float"
+<maxExclusive value="-5"/>
+<maxExclusive value="-4"/>
+base="float"
+<maxExclusive value="-INF"/>
+
+6.1.11
+base="negativeInteger"
+<totalDigits value="3"/>
+base='decimal'
+<totalDigits value='4'/>
+
+6.1.12
+base='decimal'
+<totalDigits value='4'/>
+<fractionDigits value='1'/>
+
+6.1.13
+base="decimal"
+<pattern value="[0-9][.][0-9]*"/>
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR_7634.docx (158,472) 08-06-2017 21:23
http://oldforge.etsi.org/mantis/file_download.php?file_id=3615&type=bug
Issue History
Date ModifiedUsernameFieldChange
13-03-2017 14:02Tomas UrbanNew Issue
06-06-2017 14:31Jens GrabowskiAssigned To => Kristóf Szabados
06-06-2017 14:31Jens GrabowskiStatusnew => assigned
08-06-2017 21:23Kristóf SzabadosFile Added: CR_7634.docx
09-06-2017 05:59Kristóf SzabadosNote Added: 0014670
09-06-2017 05:59Kristóf SzabadosAssigned ToKristóf Szabados => Tomas Urban
09-06-2017 05:59Kristóf SzabadosStatusassigned => confirmed
09-06-2017 08:51Tomas UrbanNote Added: 0014682
09-06-2017 08:51Tomas UrbanStatusconfirmed => resolved
09-06-2017 08:51Tomas UrbanResolutionopen => fixed
09-06-2017 08:51Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
05-01-2018 11:42Gyorgy RethyNote Added: 0015012
05-01-2018 11:42Gyorgy RethyStatusresolved => closed
05-01-2018 11:42Gyorgy RethyFixed in Version => v4.9.1 (published 2018-05)
05-01-2018 11:42Gyorgy RethyTarget Version => v4.9.1 (published 2018-05)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014670) +
+ Kristóf Szabados    +
+ 09-06-2017 05:59    +
+ 		+ + + + +
+ Please check
+
+
+
+ + + + + + + + + + +
+ (0014682) +
+ Tomas Urban    +
+ 09-06-2017 08:51    +
+ 		+ + + + +
+ Ready to be added to the new version of the specification.
+
+
+
+ + + + + + + + + + +
+ (0015012) +
+ Gyorgy Rethy    +
+ 05-01-2018 11:42    +
+ 		+ + + + +
+ Corrected in V4.8.3.
+
+ + diff --git a/docs/mantis/CR7653.md b/docs/mantis/CR7653.md new file mode 100644 index 0000000000000000000000000000000000000000..b1a9a0528593e800aac9db9b5bf87ccd4746e62c --- /dev/null +++ b/docs/mantis/CR7653.md @@ -0,0 +1,175 @@ + + + + + + + + + + + + + 0007653: Incorrect mapping of enumerated type in example 1 on element substitution - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007653Part 09: Using XML with TTCN-3Technicalpublic16-03-2017 14:2605-01-2018 11:47
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.7.1 (published 2016-07) 
Target Versionv4.9.1 (published 2018-05)Fixed in Versionv4.9.1 (published 2018-05) 
Clause Reference(s)8.1.1
For STF discussion
Source (company - Author)STF 521
Summary0007653: Incorrect mapping of enumerated type in example 1 on element substitution
DescriptionThe StringEnum type is not correctly defined. The current definition is:
+type enumerated StringEnum { something, else }
+with {
+    variant "name as uncapitalized";
+}
+
+while it should be:
+type enumerated StringEnum { something, else_ } with {
+    variant "text 'else_' as 'else'";
+    variant "name as uncapitalized"
+}
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR_7653.docx (154,563) 08-06-2017 21:51
http://oldforge.etsi.org/mantis/file_download.php?file_id=3616&type=bug
Issue History
Date ModifiedUsernameFieldChange
16-03-2017 14:26Tomas UrbanNew Issue
06-06-2017 14:31Jens GrabowskiAssigned To => Kristóf Szabados
06-06-2017 14:31Jens GrabowskiStatusnew => assigned
08-06-2017 21:51Kristóf SzabadosFile Added: CR_7653.docx
08-06-2017 21:53Kristóf SzabadosNote Added: 0014663
08-06-2017 21:53Kristóf SzabadosNote Added: 0014664
08-06-2017 21:53Kristóf SzabadosAssigned ToKristóf Szabados => Tomas Urban
08-06-2017 21:53Kristóf SzabadosStatusassigned => confirmed
09-06-2017 08:37Tomas UrbanDescription Updatedbug_revision_view_page.php?rev_id=419#r419
09-06-2017 08:46Tomas UrbanNote Added: 0014679
09-06-2017 08:46Tomas UrbanStatusconfirmed => resolved
09-06-2017 08:46Tomas UrbanResolutionopen => fixed
09-06-2017 08:46Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
05-01-2018 11:47Gyorgy RethyNote Added: 0015014
05-01-2018 11:47Gyorgy RethyStatusresolved => closed
05-01-2018 11:47Gyorgy RethyFixed in Version => v4.9.1 (published 2018-05)
05-01-2018 11:47Gyorgy RethyTarget Version => v4.9.1 (published 2018-05)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014663) +
+ Kristóf Szabados    +
+ 08-06-2017 21:53    +
+ 		+ + + + +
+ also "else_" has to come before "something" according to section 6.1.5 c) (before note 1)
+
+
+
+ + + + + + + + + + +
+ (0014664) +
+ Kristóf Szabados    +
+ 08-06-2017 21:53    +
+ 		+ + + + +
+ please review
+
+
+
+ + + + + + + + + + +
+ (0014679) +
+ Tomas Urban    +
+ 09-06-2017 08:46    +
+ 		+ + + + +
+ Ready to be added to the new version of the specification.
+
+
+
+ + + + + + + + + + +
+ (0015014) +
+ Gyorgy Rethy    +
+ 05-01-2018 11:47    +
+ 		+ + + + +
+ Corrected in draft V4.8.3
+
+ + diff --git a/docs/mantis/CR7654.md b/docs/mantis/CR7654.md new file mode 100644 index 0000000000000000000000000000000000000000..3d5a75263e7a370937643c8233b6a11edfd750ca --- /dev/null +++ b/docs/mantis/CR7654.md @@ -0,0 +1,209 @@ + + + + + + + + + + + + + 0007654: Invalid encoding instruction in the example on type substitution - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007654Part 09: Using XML with TTCN-3Technicalpublic16-03-2017 14:4905-01-2018 11:28
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.7.1 (published 2016-07) 
Target Versionv4.9.1 (published 2018-05)Fixed in Versionv4.9.1 (published 2018-05) 
Clause Reference(s)8.2
For STF discussion
Source (company - Author)STF 521
Summary0007654: Invalid encoding instruction in the example on type substitution
DescriptionThe union RequestType_derivations contains a variant "name as uncapitalized". However, since the type is a result of type substitution mapping and doesn't constitute an element or attribute, the variant should not be present.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7654-v1.docx (171,200) 25-07-2017 17:11
http://oldforge.etsi.org/mantis/file_download.php?file_id=3657&type=bug
Issue History
Date ModifiedUsernameFieldChange
16-03-2017 14:49Tomas UrbanNew Issue
06-06-2017 14:30Jens GrabowskiAssigned To => Kristóf Szabados
06-06-2017 14:30Jens GrabowskiStatusnew => assigned
09-06-2017 10:17Kristóf SzabadosNote Added: 0014692
09-06-2017 10:17Kristóf SzabadosAssigned ToKristóf Szabados => Tomas Urban
09-06-2017 10:17Kristóf SzabadosStatusassigned => feedback
09-06-2017 12:45Jacob Wieland - SpirentNote Added: 0014696
25-07-2017 17:07Tomas UrbanFile Added: CR7654-v1.docx
25-07-2017 17:09Tomas UrbanNote Added: 0014765
25-07-2017 17:09Tomas UrbanStatusfeedback => assigned
25-07-2017 17:09Tomas UrbanAssigned ToTomas Urban => Kristóf Szabados
25-07-2017 17:09Tomas UrbanStatusassigned => confirmed
25-07-2017 17:11Tomas UrbanFile Deleted: CR7654-v1.docx
25-07-2017 17:11Tomas UrbanFile Added: CR7654-v1.docx
26-07-2017 09:20Kristóf SzabadosNote Added: 0014773
26-07-2017 09:20Kristóf SzabadosStatusconfirmed => resolved
26-07-2017 09:20Kristóf SzabadosResolutionopen => fixed
26-07-2017 09:20Kristóf SzabadosAssigned ToKristóf Szabados => Gyorgy Rethy
05-01-2018 11:28Gyorgy RethyNote Added: 0015009
05-01-2018 11:28Gyorgy RethyStatusresolved => closed
05-01-2018 11:28Gyorgy RethyFixed in Version => v4.9.1 (published 2018-05)
05-01-2018 11:28Gyorgy RethyTarget Version => v4.9.1 (published 2018-05)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014692) +
+ Kristóf Szabados    +
+ 09-06-2017 10:17    +
+ 		+ + + + +
+ According to 5.2.2 f), on page 17: "if a character string that is to be used as a name of a TTCN-3 type starts with a lower-case letter, the first letter shall be capitalized (converted to upper-case);"
+
+The variant seems to be fine.
+According to 5.2.2 f) (on page 17) the name of the TTCN-3 type to be generated is capitalized ... and according to 5.2.2 a) (on page 20) if the name of the generated TTCN-3 is different from the original name only in the first letter the "name as uncapitalized" variant attribute shall be used.
+
+In this case we start from "requestType" add the "_derivations" because of the type substitution; according to 5.2.2 in the generated TTCN-3 this has to be "RequestType_derivations" and so also have the variant attribute to note the change in the first letter.
+
+
+
+ + + + + + + + + + +
+ (0014696) +
+ Jacob Wieland - Spirent    +
+ 09-06-2017 12:45    +
+ 		+ + + + +
+ but what does the variant attribute accomplish? The name of the type will never appear in an XML, so the codec does not need to know whether the type name was capitalized or not.
+
+
+
+ + + + + + + + + + +
+ (0014765) +
+ Tomas Urban    +
+ 25-07-2017 17:09    +
+ 		+ + + + +
+ The rule 5.2.2.a (on page 20) cannot be applied in this case, because it works only for "an element declaration, attribute declaration, top-level complex type definition or user-defined top-level simple type definition if the type definition name generated is different from the value of the name attribute of the corresponding schema component".
+
+The mentioned type is neither of those and it is not present in the schema. Besides as Jacob said, it doesn't make much sense to generate the instruction.
+
+I uploaded a resolution proposal which simply removes the attributes from the examples. Please check.
+
+
+
+ + + + + + + + + + +
+ (0014773) +
+ Kristóf Szabados    +
+ 26-07-2017 09:20    +
+ 		+ + + + +
+ Looks good by me.
+Ready to be added to the next version of the core language specification.
+
+
+
+ + + + + + + + + + +
+ (0015009) +
+ Gyorgy Rethy    +
+ 05-01-2018 11:28    +
+ 		+ + + + +
+ Implemented in draft V4.8.3.
+
+ + diff --git a/docs/mantis/CR7655.md b/docs/mantis/CR7655.md new file mode 100644 index 0000000000000000000000000000000000000000..a27d7718b699820c4ac44efdc06a51730321f96a --- /dev/null +++ b/docs/mantis/CR7655.md @@ -0,0 +1,278 @@ + + + + + + + + + + + + + 0007655: mixed list/assignment-notation should also be allowed for record/set types - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007655Part 01: TTCN-3 Core LanguageNew Featurepublic17-03-2017 11:4830-12-2017 21:44
ReporterJacob Wieland - Spirent 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.9.1 (published 2017-05) 
Target Versionv4.10.1 (published 2018-05)Fixed in Versionv4.10.1 (published 2018-05) 
Clause Reference(s)6.2.0, A.1.5
Source (company - Author)Spirent - Jacob Wieland
Summary0007655: mixed list/assignment-notation should also be allowed for record/set types
DescriptionIn a scenario where there exist record types with a few mandatory fields at the beginning and man optional fields at the end where in each instance, only a few of the optional fields are present, usage of the assignment-notation syntax is very useful.
+
+However, it is tedious insofar as the names of the mandatory parameters at the beginning have to be repeated for every instance.
+
+Thus, alike to the mixed notation for actual parameter lists, the same mixed notation with the same constraints should be allowed also for recor/set instances as well.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7655.docx (240,019) 07-06-2017 10:29
http://oldforge.etsi.org/mantis/file_download.php?file_id=3599&type=bug
Issue History
Date ModifiedUsernameFieldChange
17-03-2017 11:48Jacob Wieland - SpirentNew Issue
18-04-2017 10:38szabadosNote Added: 0014568
18-04-2017 12:25Denis FilatovFile Added: a.jpg
18-04-2017 12:26Denis FilatovFile Deleted: a.jpg
18-04-2017 12:26Jacob Wieland - SpirentNote Added: 0014573
18-04-2017 12:27Denis FilatovFile Added: test.txt
18-04-2017 12:27Denis FilatovFile Deleted: test.txt
06-06-2017 13:55Jens GrabowskiNote Added: 0014626
06-06-2017 13:59Jens GrabowskiAssigned To => Jacob Wieland - Spirent
06-06-2017 13:59Jens GrabowskiStatusnew => assigned
07-06-2017 10:29Jacob Wieland - SpirentFile Added: CR7655.docx
07-06-2017 10:30Jacob Wieland - SpirentNote Added: 0014641
07-06-2017 10:33Jacob Wieland - SpirentNote Added: 0014642
07-06-2017 10:33Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Julien Deltour
07-06-2017 10:33Jacob Wieland - SpirentStatusassigned => confirmed
08-06-2017 14:55Julien DeltourNote Added: 0014652
08-06-2017 14:55Julien DeltourStatusconfirmed => resolved
08-06-2017 14:55Julien DeltourResolutionopen => fixed
08-06-2017 14:55Julien DeltourAssigned ToJulien Deltour => Gyorgy Rethy
30-12-2017 21:44Gyorgy RethyNote Added: 0014975
30-12-2017 21:44Gyorgy RethyStatusresolved => closed
30-12-2017 21:44Gyorgy RethyFixed in Version => v4.10.1 (published 2018-05)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014568) +
+ szabados    +
+ 18-04-2017 10:38    +
+ 		+ + + + +
+ Just a short note, section 5.4.2 restriction b, on page 36 says:
+Either list notation or assignment notation shall be used in a single parameter list. They shall not be mixed.
+
+Do I remember right that it was allowed to use list notation followed by assignment notation in function calls?
+
+
+
+ + + + + + + + + + +
+ (0014573) +
+ Jacob Wieland - Spirent    +
+ 18-04-2017 12:26    +
+ 		+ + + + +
+ yes, we changed that, did we miss to delete that restriction?
+
+
+
+ + + + + + + + + + +
+ (0014626) +
+ Jens Grabowski    +
+ 06-06-2017 13:55    +
+ 		+ + + + +
+ STF discussion: agreed, check where we missed the deletion of the restriction.
+
+
+
+ + + + + + + + + + +
+ (0014641) +
+ Jacob Wieland - Spirent    +
+ 07-06-2017 10:30    +
+ 		+ + + + +
+ deleted the restriction (set to Void)
+
+changed BNF (ArrayExpression renamed to ArrayOrMixedExpression)
+
+added description and example of mixed notation also for structured values
+
+
+
+ + + + + + + + + + +
+ (0014642) +
+ Jacob Wieland - Spirent    +
+ 07-06-2017 10:33    +
+ 		+ + + + +
+ please review the proposal document
+
+
+
+ + + + + + + + + + +
+ (0014652) +
+ Julien Deltour    +
+ 08-06-2017 14:55    +
+ 		+ + + + +
+ Acceptable
+
+
+
+ + + + + + + + + + +
+ (0014975) +
+ Gyorgy Rethy    +
+ 30-12-2017 21:44    +
+ 		+ + + + +
+ Added to draft V4.9.2
+
+ + diff --git a/docs/mantis/CR7656.md b/docs/mantis/CR7656.md new file mode 100644 index 0000000000000000000000000000000000000000..4c76fb1509dffa3c455408d91cf568b26150175e --- /dev/null +++ b/docs/mantis/CR7656.md @@ -0,0 +1,226 @@ + + + + + + + + + + + + + 0007656: Invalid examples on simple content mapping - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007656Part 09: Using XML with TTCN-3Technicalpublic20-03-2017 12:5805-01-2018 11:19
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.7.1 (published 2016-07) 
Target Versionv4.9.1 (published 2018-05)Fixed in Versionv4.9.1 (published 2018-05) 
Clause Reference(s)7.6.1
For STF discussion
Source (company - Author)STF 521
Summary0007656: Invalid examples on simple content mapping
DescriptionIn the section 7.6.1.1 on mapping of simple content, there's a following XSD type:
+
+<xsd:complexType name="complex-base-simple">
+ <xsd:simpleContent>
+   <xsd:extension base="xsd:integer"/>
+  </xsd:simpleContent>
+</xsd:complexType>
+
+In my opinion, it shall be mapped to:
+type XSD.Integer Complex_base_simple
+with {
+ variant "name as 'complex-base-simple'";
+};
+
+That's because the existing rules states: "If the definition of a new named or unnamed complex type uses another simple or complex type as the base of the extension without changing the base type (i.e. no facet is applied and no attribute is added), it shall be translated to a TTCN-3 type synonym to the base type."
+
+The XSD type definition shown above fullfils all conditions stipulated by the rule: there are no additional attributes nor facets (which is actually always true as simple content extensions never contain any facets). Nevertheless, the mapping used in the example is different from the one I consider correct:
+
+type record Complex_base_simple
+{
+  XSD.Integer base
+}
+with {
+  variant "name as 'complex-base-simple'";
+  variant (base) "untagged";
+};
+
+The same problem affects the example 1 on simple content restriction in 7.6.1.2
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0006867closed Gyorgy Rethy Handling XSD type aliases 
Attached Filesdocx CR7656-v1.docx (164,207) 27-07-2017 12:38
http://oldforge.etsi.org/mantis/file_download.php?file_id=3665&type=bug
Issue History
Date ModifiedUsernameFieldChange
20-03-2017 12:58Tomas UrbanNew Issue
06-06-2017 14:29Jens GrabowskiNote Added: 0014632
06-06-2017 14:29Jens GrabowskiAssigned To => Tomas Urban
06-06-2017 14:29Jens GrabowskiStatusnew => assigned
25-07-2017 08:19Tomas UrbanDescription Updatedbug_revision_view_page.php?rev_id=428#r428
26-07-2017 10:31Tomas UrbanRelationship addedrelated to 0006867
26-07-2017 10:33Jens GrabowskiNote Added: 0014780
27-07-2017 12:38Tomas UrbanFile Added: CR7656-v1.docx
27-07-2017 12:39Tomas UrbanNote Added: 0014786
27-07-2017 12:39Tomas UrbanAssigned ToTomas Urban => Kristóf Szabados
27-07-2017 12:39Tomas UrbanStatusassigned => confirmed
04-09-2017 13:17Kristóf SzabadosNote Added: 0014812
04-09-2017 13:17Kristóf SzabadosStatusconfirmed => resolved
04-09-2017 13:17Kristóf SzabadosResolutionopen => fixed
04-09-2017 13:17Kristóf SzabadosAssigned ToKristóf Szabados => Gyorgy Rethy
05-01-2018 11:19Gyorgy RethyNote Added: 0015008
05-01-2018 11:19Gyorgy RethyStatusresolved => closed
05-01-2018 11:19Gyorgy RethyFixed in Version => v4.9.1 (published 2018-05)
05-01-2018 11:19Gyorgy RethyTarget Version => v4.9.1 (published 2018-05)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014632) +
+ Jens Grabowski    +
+ 06-06-2017 14:29    +
+ 		+ + + + +
+ Tomas, to prepare discussion.
+
+
+
+ + + + + + + + + + +
+ (0014780) +
+ Jens Grabowski    +
+ 26-07-2017 10:33    +
+ 		+ + + + +
+ STF discussion: Tomas to write a proposal. Further discussion with György required (via Kristof). Originial CR introduced an non-backwards compatible change.
+
+
+
+ + + + + + + + + + +
+ (0014786) +
+ Tomas Urban    +
+ 27-07-2017 12:39    +
+ 		+ + + + +
+ Resolved by keeping the rule and changing the examples mentioned in the CR. Please check.
+
+
+
+ + + + + + + + + + +
+ (0014812) +
+ Kristóf Szabados    +
+ 04-09-2017 13:17    +
+ 		+ + + + +
+ Looks fine for me.
+
+
+
+ + + + + + + + + + +
+ (0015008) +
+ Gyorgy Rethy    +
+ 05-01-2018 11:19    +
+ 		+ + + + +
+ Added to draft V4.8.3.
+
+ + diff --git a/docs/mantis/CR7657.md b/docs/mantis/CR7657.md new file mode 100644 index 0000000000000000000000000000000000000000..f911d01e443d1c396ea7480f81743d54244bb322 --- /dev/null +++ b/docs/mantis/CR7657.md @@ -0,0 +1,150 @@ + + + + + + + + + + + + + 0007657: Name of anyAttribute and anyElement fields are not encoded - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007657Part 09: Using XML with TTCN-3Clarificationpublic24-03-2017 15:0105-01-2018 11:32
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.8.1 (published 2017-05) 
Target Versionv4.9.1 (published 2018-05)Fixed in Versionv4.9.1 (published 2018-05) 
Clause Reference(s)B.3.2 and B.3.3
For STF discussion
Source (company - Author)L.M.Ericsson
Summary0007657: Name of anyAttribute and anyElement fields are not encoded
DescriptionXSD <any> elements are translated in TTCN-3 to one of the
+XSD.String elem
+anytype elem
+record of XSD.String elem_list
+record of anytype elem_list
+
+TTCN-3 fields, and the field receives an
+variant(elem) "anyElement";
+or
+variant(elem_list) "anyElement";
+encoding instruction.
+
+At encoding this TTCN-3 field in XML, the name of the field (elem or elem_list correspondingly) itself is not encoded, only its content. And similarly, the name elem|elem_list is not expected when decoding an XML document to TTCN-3.
+However, this is not explicitly specified at the description of anyElement in clause B.3.2 (implicitly can be assumed as the description talks about the content, still it may leave some ambiguity).
+
+Proposed solution: specify in the description part of clause B.3.2 explicitly that the TTCN-3 field *containing* the "any" element or elements is not encoded, only its content.
+
+----------------------------------------------------------------------------
+
+The same is true for the XSD anyAttribute element and the description of the "anyAttribute" encoding instruction in clause B.3.3.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7657.docx (155,583) 09-06-2017 10:12
http://oldforge.etsi.org/mantis/file_download.php?file_id=3631&type=bug
Issue History
Date ModifiedUsernameFieldChange
24-03-2017 15:01Gyorgy RethyNew Issue
06-06-2017 14:26Jens GrabowskiAssigned To => Tomas Urban
06-06-2017 14:26Jens GrabowskiStatusnew => assigned
09-06-2017 10:12Tomas UrbanFile Added: CR7657.docx
09-06-2017 10:12Tomas UrbanNote Added: 0014691
09-06-2017 10:12Tomas UrbanAssigned ToTomas Urban => Kristóf Szabados
09-06-2017 10:12Tomas UrbanStatusassigned => confirmed
09-06-2017 15:07Kristóf SzabadosNote Added: 0014700
09-06-2017 15:07Kristóf SzabadosStatusconfirmed => resolved
09-06-2017 15:07Kristóf SzabadosResolutionopen => fixed
09-06-2017 15:07Kristóf SzabadosAssigned ToKristóf Szabados => Gyorgy Rethy
05-01-2018 11:32Gyorgy RethyNote Added: 0015010
05-01-2018 11:32Gyorgy RethyStatusresolved => closed
05-01-2018 11:32Gyorgy RethyFixed in Version => v4.9.1 (published 2018-05)
05-01-2018 11:32Gyorgy RethyTarget Version => v4.9.1 (published 2018-05)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014691) +
+ Tomas Urban    +
+ 09-06-2017 10:12    +
+ 		+ + + + +
+ Resolution proposal uploaded. Please check.
+
+
+
+ + + + + + + + + + +
+ (0014700) +
+ Kristóf Szabados    +
+ 09-06-2017 15:07    +
+ 		+ + + + +
+ The proposal is ready to be added to the next version of the specification.
+
+
+
+ + + + + + + + + + +
+ (0015010) +
+ Gyorgy Rethy    +
+ 05-01-2018 11:32    +
+ 		+ + + + +
+ Added to draft V4.8.3.
+
+ + diff --git a/docs/mantis/CR7658.md b/docs/mantis/CR7658.md new file mode 100644 index 0000000000000000000000000000000000000000..e73313b1e6c20e48d5f493836bb2a19ee69a3176 --- /dev/null +++ b/docs/mantis/CR7658.md @@ -0,0 +1,136 @@ + + + + + + + + + + + + + 0007658: Missing support for leap seconds in mapping of XSD time types - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007658Part 09: Using XML with TTCN-3Technicalpublic27-03-2017 14:0905-01-2018 11:34
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.7.1 (published 2016-07) 
Target Versionv4.9.1 (published 2018-05)Fixed in Versionv4.9.1 (published 2018-05) 
Clause Reference(s)6.5
For STF discussion
Source (company - Author)STF 521
Summary0007658: Missing support for leap seconds in mapping of XSD time types
DescriptionThe XSD.second constant is defined as:
+const charstring second := "([0-5][0-9])"
+
+This is incorrect as leap seconds are not supported (see ISO 8601 for more details). The correct definition would be:
+const charstring second := "([0-5][0-9]|60)"
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR_7658.docx (140,617) 09-06-2017 09:28
http://oldforge.etsi.org/mantis/file_download.php?file_id=3626&type=bug
Issue History
Date ModifiedUsernameFieldChange
27-03-2017 14:09Tomas UrbanNew Issue
27-03-2017 14:17Tomas UrbanDescription Updatedbug_revision_view_page.php?rev_id=385#r385
06-06-2017 14:25Jens GrabowskiAssigned To => Kristóf Szabados
06-06-2017 14:25Jens GrabowskiStatusnew => assigned
09-06-2017 09:28Kristóf SzabadosFile Added: CR_7658.docx
09-06-2017 09:29Kristóf SzabadosNote Added: 0014686
09-06-2017 09:29Kristóf SzabadosAssigned ToKristóf Szabados => Tomas Urban
09-06-2017 09:29Kristóf SzabadosStatusassigned => confirmed
09-06-2017 09:47Tomas UrbanNote Added: 0014689
09-06-2017 09:47Tomas UrbanStatusconfirmed => resolved
09-06-2017 09:47Tomas UrbanResolutionopen => fixed
09-06-2017 09:47Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
05-01-2018 11:34Gyorgy RethyNote Added: 0015011
05-01-2018 11:34Gyorgy RethyStatusresolved => closed
05-01-2018 11:34Gyorgy RethyFixed in Version => v4.9.1 (published 2018-05)
05-01-2018 11:34Gyorgy RethyTarget Version => v4.9.1 (published 2018-05)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014686) +
+ Kristóf Szabados    +
+ 09-06-2017 09:29    +
+ 		+ + + + +
+ Please check.
+
+
+
+ + + + + + + + + + +
+ (0014689) +
+ Tomas Urban    +
+ 09-06-2017 09:47    +
+ 		+ + + + +
+ The proposal is ready to be added to the next version of the specification.
+
+
+
+ + + + + + + + + + +
+ (0015011) +
+ Gyorgy Rethy    +
+ 05-01-2018 11:34    +
+ 		+ + + + +
+ Added to draft V4.8.3
+
+ + diff --git a/docs/mantis/CR7662.md b/docs/mantis/CR7662.md new file mode 100644 index 0000000000000000000000000000000000000000..c42c60a9385160ad9375951f2e1b922b65b137ac --- /dev/null +++ b/docs/mantis/CR7662.md @@ -0,0 +1,165 @@ + + + + + + + + + + + + + 0007662: Invalid field names in example on nested sequence inside choice - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007662Part 09: Using XML with TTCN-3Editorialpublic30-03-2017 12:0605-01-2018 11:44
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.7.1 (published 2016-07) 
Target Versionv4.9.1 (published 2018-05)Fixed in Versionv4.9.1 (published 2018-05) 
Clause Reference(s)7.6.5.4
For STF discussion
Source (company - Author)STF 521
Summary0007662: Invalid field names in example on nested sequence inside choice
DescriptionThe example 2 of 7.6.5.4 incorrectly maps the second "foo" and "bar" elements into fields called "foo_" and "bar_". According to the rule 5.2.2.l, the names should be "foo_1" and "bar_1".
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR_7662.docx (140,765) 08-06-2017 22:09
http://oldforge.etsi.org/mantis/file_download.php?file_id=3617&type=bug
Issue History
Date ModifiedUsernameFieldChange
30-03-2017 12:06Tomas UrbanNew Issue
06-06-2017 14:24Jens GrabowskiAssigned To => Kristóf Szabados
06-06-2017 14:24Jens GrabowskiStatusnew => assigned
08-06-2017 22:09Kristóf SzabadosFile Added: CR_7662.docx
08-06-2017 22:09Kristóf SzabadosNote Added: 0014665
08-06-2017 22:10Kristóf SzabadosNote Added: 0014666
08-06-2017 22:10Kristóf SzabadosAssigned ToKristóf Szabados => Tomas Urban
08-06-2017 22:10Kristóf SzabadosStatusassigned => confirmed
09-06-2017 08:47Tomas UrbanNote Added: 0014680
09-06-2017 08:47Tomas UrbanStatusconfirmed => resolved
09-06-2017 08:47Tomas UrbanResolutionopen => fixed
09-06-2017 08:47Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
05-01-2018 11:44Gyorgy RethyNote Added: 0015013
05-01-2018 11:44Gyorgy RethyStatusresolved => closed
05-01-2018 11:44Gyorgy RethyFixed in Version => v4.9.1 (published 2018-05)
05-01-2018 11:44Gyorgy RethyTarget Version => v4.9.1 (published 2018-05)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014665) +
+ Kristóf Szabados    +
+ 08-06-2017 22:09    +
+ 		+ + + + +
+ and 2 more variants were missing.
+
+
+
+ + + + + + + + + + +
+ (0014666) +
+ Kristóf Szabados    +
+ 08-06-2017 22:10    +
+ 		+ + + + +
+ Please review
+
+
+
+ + + + + + + + + + +
+ (0014680) +
+ Tomas Urban    +
+ 09-06-2017 08:47    +
+ 		+ + + + +
+ Ready to be added to the new version of the specification.
+
+
+
+ + + + + + + + + + +
+ (0015013) +
+ Gyorgy Rethy    +
+ 05-01-2018 11:44    +
+ 		+ + + + +
+ Corrected in draft V4.8.3
+
+ + diff --git a/docs/mantis/CR7664.md b/docs/mantis/CR7664.md new file mode 100644 index 0000000000000000000000000000000000000000..d123a0f79c8d67779bdac4797a1e84345cbd118c --- /dev/null +++ b/docs/mantis/CR7664.md @@ -0,0 +1,137 @@ + + + + + + + + + + + + + 0007664: Example on base64Binary mapping - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007664Part 09: Using XML with TTCN-3Technicalpublic05-04-2017 13:0605-01-2018 11:51
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.7.1 (published 2016-07) 
Target Versionv4.9.1 (published 2018-05)Fixed in Versionv4.9.1 (published 2018-05) 
Clause Reference(s)6.2.11
For STF discussion
Source (company - Author)STF 521
Summary0007664: Example on base64Binary mapping
DescriptionThere are several issues with the example on base64Binary mapping in the section 6.2.11:
+
+1. The example contains a XSD type conversion to TTCN-3. The template of the TTCN-3 type is then used for encoding which is incorrect as XSD types cannot be encoded (see the rules in Annex B). Only elements and attributes can be processed by the codec.
+
+2. The produced encoding is incorrect as it contains \r\n at the end
+
+3. The octet string value breaches the condition of neutrality of the specification and shall be replaced with something that does not contain a (hidden) reference to an existing TTCN-3 tool.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7664.docx (139,874) 07-06-2017 11:19
http://oldforge.etsi.org/mantis/file_download.php?file_id=3602&type=bug
docx CR7664-v2.docx (153,434) 08-06-2017 16:02
http://oldforge.etsi.org/mantis/file_download.php?file_id=3611&type=bug
Issue History
Date ModifiedUsernameFieldChange
05-04-2017 13:06Tomas UrbanNew Issue
06-06-2017 14:23Jens GrabowskiAssigned To => Jacob Wieland - Spirent
06-06-2017 14:23Jens GrabowskiStatusnew => assigned
07-06-2017 11:19Jacob Wieland - SpirentFile Added: CR7664.docx
07-06-2017 11:20Jacob Wieland - SpirentNote Added: 0014645
07-06-2017 11:20Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Tomas Urban
07-06-2017 11:20Jacob Wieland - SpirentStatusassigned => confirmed
08-06-2017 16:02Tomas UrbanFile Added: CR7664-v2.docx
08-06-2017 16:04Tomas UrbanNote Added: 0014656
08-06-2017 16:04Tomas UrbanStatusconfirmed => resolved
08-06-2017 16:04Tomas UrbanResolutionopen => fixed
08-06-2017 16:04Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
05-01-2018 11:51Gyorgy RethyNote Added: 0015015
05-01-2018 11:51Gyorgy RethyStatusresolved => closed
05-01-2018 11:51Gyorgy RethyFixed in Version => v4.9.1 (published 2018-05)
05-01-2018 11:51Gyorgy RethyTarget Version => v4.9.1 (published 2018-05)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014645) +
+ Jacob Wieland - Spirent    +
+ 07-06-2017 11:20    +
+ 		+ + + + +
+ please review
+
+
+
+ + + + + + + + + + +
+ (0014656) +
+ Tomas Urban    +
+ 08-06-2017 16:04    +
+ 		+ + + + +
+ Cosmetic changes were made in the draft (correct quota characters). Otherwise, the proposed resolution is ready to be included in the next version of the standard.
+
+
+
+ + + + + + + + + + +
+ (0015015) +
+ Gyorgy Rethy    +
+ 05-01-2018 11:51    +
+ 		+ + + + +
+ Added to draft V4.8.3
+
+ + diff --git a/docs/mantis/CR7665.md b/docs/mantis/CR7665.md new file mode 100644 index 0000000000000000000000000000000000000000..9a3e78b78c765ae415b40b25c898ff81b92ac196 --- /dev/null +++ b/docs/mantis/CR7665.md @@ -0,0 +1,165 @@ + + + + + + + + + + + + + 0007665: Missing XSD definition in example on QName - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007665Part 09: Using XML with TTCN-3Editorialpublic06-04-2017 09:0405-01-2018 10:50
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeveritytrivialReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.7.1 (published 2016-07) 
Target Versionv4.9.1 (published 2018-05)Fixed in Versionv4.9.1 (published 2018-05) 
Clause Reference(s)6.6.4
For STF discussion
Source (company - Author)STF 521
Summary0007665: Missing XSD definition in example on QName
DescriptionThe example in the section 6.6.4 on QName mapping doesn't contain a XSD definition of the element E14a. The missing definition should be added.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR_7665.docx (140,526) 09-06-2017 05:56
http://oldforge.etsi.org/mantis/file_download.php?file_id=3620&type=bug
Issue History
Date ModifiedUsernameFieldChange
06-04-2017 09:04Tomas UrbanNew Issue
06-06-2017 14:21Jens GrabowskiNote Added: 0014631
06-06-2017 14:21Jens GrabowskiAssigned To => Kristóf Szabados
06-06-2017 14:21Jens GrabowskiStatusnew => assigned
09-06-2017 05:47Kristóf SzabadosFile Added: CR_7665.docx
09-06-2017 05:54Kristóf SzabadosFile Deleted: CR_7665.docx
09-06-2017 05:56Kristóf SzabadosFile Added: CR_7665.docx
09-06-2017 05:56Kristóf SzabadosNote Added: 0014669
09-06-2017 05:56Kristóf SzabadosAssigned ToKristóf Szabados => Tomas Urban
09-06-2017 05:56Kristóf SzabadosStatusassigned => confirmed
09-06-2017 08:48Tomas UrbanNote Added: 0014681
09-06-2017 08:48Tomas UrbanStatusconfirmed => resolved
09-06-2017 08:48Tomas UrbanResolutionopen => fixed
09-06-2017 08:48Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
05-01-2018 10:50Gyorgy RethyNote Added: 0015005
05-01-2018 10:50Gyorgy RethyStatusresolved => closed
05-01-2018 10:50Gyorgy RethyFixed in Version => v4.9.1 (published 2018-05)
05-01-2018 10:50Gyorgy RethyTarget Version => v4.9.1 (published 2018-05)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014631) +
+ Jens Grabowski    +
+ 06-06-2017 14:21    +
+ 		+ + + + +
+ STF discussion: to be checked.
+
+
+
+ + + + + + + + + + +
+ (0014669) +
+ Kristóf Szabados    +
+ 09-06-2017 05:56    +
+ 		+ + + + +
+ Please review
+
+
+
+ + + + + + + + + + +
+ (0014681) +
+ Tomas Urban    +
+ 09-06-2017 08:48    +
+ 		+ + + + +
+ Ready to be added to the new version of the specification.
+
+
+
+ + + + + + + + + + +
+ (0015005) +
+ Gyorgy Rethy    +
+ 05-01-2018 10:50    +
+ 		+ + + + +
+ Added to draft V4.8.3.
+
+ + diff --git a/docs/mantis/CR7669.md b/docs/mantis/CR7669.md new file mode 100644 index 0000000000000000000000000000000000000000..10ce13259042b7e97194e1a21b665d7f574bda45 --- /dev/null +++ b/docs/mantis/CR7669.md @@ -0,0 +1,171 @@ + + + + + + + + + + + + + 0007669: wording problem in the definitions - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007669Part 01: TTCN-3 Core LanguageEditorialpublic29-04-2017 13:4530-12-2017 21:48
Reporterszabados 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.9.1 (published 2017-05) 
Target Versionv4.10.1 (published 2018-05)Fixed in Versionv4.10.1 (published 2018-05) 
Clause Reference(s)3.1
Source (company - Author)     L.M. Ericsson
Summary0007669: wording problem in the definitions
DescriptionNote 3 of out parametrization is:
+"An out formal parameter is uninitialized (unbound) when the invoked object is entered"
+
+It would be better to write it something like this: "Out formal parameters are uninitialized (unbound) when the invoked object is entered".
+
+The old wording can be misunderstood to mean that only one of many out parameters need to be uninitialized upon entering the invoked object.
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR_7669.docx (164,130) 07-06-2017 10:39
http://oldforge.etsi.org/mantis/file_download.php?file_id=3600&type=bug
docx CR_7669-2.docx (164,416) 07-06-2017 11:03
http://oldforge.etsi.org/mantis/file_download.php?file_id=3601&type=bug
Issue History
Date ModifiedUsernameFieldChange
29-04-2017 13:45szabadosNew Issue
02-05-2017 09:21Jacob Wieland - SpirentNote Added: 0014608
06-06-2017 11:55Jens GrabowskiAssigned To => Kristóf Szabados
06-06-2017 11:55Jens GrabowskiStatusnew => assigned
07-06-2017 10:39szabadosFile Added: CR_7669.docx
07-06-2017 10:49Kristóf SzabadosNote Added: 0014643
07-06-2017 10:49Kristóf SzabadosAssigned ToKristóf Szabados => Jacob Wieland - Spirent
07-06-2017 10:49Kristóf SzabadosStatusassigned => confirmed
07-06-2017 11:03Jacob Wieland - SpirentFile Added: CR_7669-2.docx
07-06-2017 11:04Jacob Wieland - SpirentNote Added: 0014644
07-06-2017 11:06Jacob Wieland - SpirentStatusconfirmed => resolved
07-06-2017 11:06Jacob Wieland - SpirentFixed in Version => v4.9.1 (published 2017-05)
07-06-2017 11:06Jacob Wieland - SpirentResolutionopen => fixed
07-06-2017 11:06Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
30-12-2017 21:48Gyorgy RethyNote Added: 0014976
30-12-2017 21:48Gyorgy RethyStatusresolved => closed
30-12-2017 21:48Gyorgy RethyProduct Version => v4.9.1 (published 2017-05)
30-12-2017 21:48Gyorgy RethyFixed in Versionv4.9.1 (published 2017-05) => v4.10.1 (published 2018-05)
30-12-2017 21:48Gyorgy RethyTarget Version => v4.10.1 (published 2018-05)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014608) +
+ Jacob Wieland - Spirent    +
+ 02-05-2017 09:21    +
+ 		+ + + + +
+ While I totally disagree that in a legal document (as I see these standards) this can be misunderstood, as it is clear that any randomly chosen out parameter is talked about and thus, the proposition stands for each one, I have no problem with rewording it, if we really want to spend this effort.
+
+
+
+ + + + + + + + + + +
+ (0014643) +
+ Kristóf Szabados    +
+ 07-06-2017 10:49    +
+ 		+ + + + +
+ please check wording.
+
+
+
+ + + + + + + + + + +
+ (0014644) +
+ Jacob Wieland - Spirent    +
+ 07-06-2017 11:04    +
+ 		+ + + + +
+ Changed order or words (to "formal out parameter") to be more consistent with rest of the standard.
+
+
+
+ + + + + + + + + + +
+ (0014976) +
+ Gyorgy Rethy    +
+ 30-12-2017 21:48    +
+ 		+ + + + +
+ Corrected in draft V4.9.2
+
+ + diff --git a/docs/mantis/CR7672.md b/docs/mantis/CR7672.md new file mode 100644 index 0000000000000000000000000000000000000000..edcca89c778fb17bd41e3466ba07bfc2375eb993 --- /dev/null +++ b/docs/mantis/CR7672.md @@ -0,0 +1,565 @@ + + + + + + + + + + + + + 0007672: Compatibility of enumerated types - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007672Part 01: TTCN-3 Core LanguageTechnicalpublic03-05-2017 11:0005-01-2018 09:55
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.9.1 (published 2017-05) 
Target Versionv4.10.1 (published 2018-05)Fixed in Versionv4.10.1 (published 2018-05) 
Clause Reference(s)6.3.2.1
Source (company - Author)Elvior
Summary0007672: Compatibility of enumerated types
DescriptionThe new rules on compatibility of enumerated types are based on individual enumerated values which means that types are sometimes compatible and sometimes not. That makes static semantic analysis quite difficult and leads to runtime errors.
+
+Example:
+type enumerated EWorkDays { Mon, Tue, Wed, Thu, Fri }
+type enumerated EWeekDays { Mon, Tue, Wed, Thu, Fri, Sat, Sun }
+...
+var EWorkDays v_workDay := Mon;
+var EWeekDays v_weekDay := Mon;
+log (v_workDay == v_weekDay); // ok, logs "true"
+v_weekDay := Sat;
+log (v_workDay == v_weekDay); // leads to type compatibility error
+
+Proposal:
+1. Add an additional rule to the relation operations that would produce false in case of comparing non-compatible values of partially compatible enumerations as in the example above.
+2. Describe in detail the assignment process with all possible errors and create examples (v_weekDay := v_workDay should be always possible, v_workDay := v_weekDay could work, but it can produce runtime errors too).
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc 7672.doc (15,360) 24-07-2017 07:36
http://oldforge.etsi.org/mantis/file_download.php?file_id=3646&type=bug
doc 7672_2.doc (16,896) 25-07-2017 10:59
http://oldforge.etsi.org/mantis/file_download.php?file_id=3651&type=bug
doc 7672_3.doc (31,232) 26-10-2017 11:40
http://oldforge.etsi.org/mantis/file_download.php?file_id=3711&type=bug
doc 7672_4.doc (32,256) 26-10-2017 14:46
http://oldforge.etsi.org/mantis/file_download.php?file_id=3716&type=bug
docx CR7276_5.docx (74,327) 04-01-2018 11:36
http://oldforge.etsi.org/mantis/file_download.php?file_id=3733&type=bug
Issue History
Date ModifiedUsernameFieldChange
03-05-2017 11:00Tomas UrbanNew Issue
03-05-2017 11:12Jacob Wieland - SpirentNote Added: 0014614
06-06-2017 11:23Jens GrabowskiAssigned To => Julien Deltour
06-06-2017 11:23Jens GrabowskiStatusnew => assigned
07-06-2017 08:45szabadosNote Added: 0014636
24-07-2017 07:36Julien DeltourFile Added: 7672.doc
24-07-2017 07:36Julien DeltourNote Added: 0014730
24-07-2017 07:37Julien DeltourStatusassigned => confirmed
24-07-2017 07:37Julien DeltourAssigned ToJulien Deltour => Tomas Urban
24-07-2017 07:37Julien DeltourStatusconfirmed => assigned
24-07-2017 10:33Jacob Wieland - SpirentNote Added: 0014731
24-07-2017 16:18Tomas UrbanAssigned ToTomas Urban => Julien Deltour
25-07-2017 10:59Julien DeltourFile Added: 7672_2.doc
25-07-2017 11:00Julien DeltourNote Added: 0014749
25-07-2017 11:00Julien DeltourAssigned ToJulien Deltour => Jacob Wieland - Spirent
25-07-2017 11:00Julien DeltourStatusassigned => confirmed
25-07-2017 16:32Kristóf SzabadosNote Added: 0014760
25-07-2017 16:33Kristóf SzabadosNote Deleted: 0014760
26-07-2017 09:01Jacob Wieland - SpirentNote Added: 0014770
26-07-2017 09:02Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Julien Deltour
26-07-2017 09:02Jacob Wieland - SpirentStatusconfirmed => assigned
26-10-2017 11:40Julien DeltourFile Added: 7672_3.doc
26-10-2017 11:40Julien DeltourNote Added: 0014886
26-10-2017 11:41Julien DeltourStatusassigned => confirmed
26-10-2017 11:41Julien DeltourAssigned ToJulien Deltour => Jacob Wieland - Spirent
26-10-2017 11:41Julien DeltourStatusconfirmed => assigned
26-10-2017 14:46Jacob Wieland - SpirentNote Added: 0014897
26-10-2017 14:46Jacob Wieland - SpirentFile Added: 7672_4.doc
26-10-2017 14:47Jacob Wieland - SpirentNote Added: 0014898
26-10-2017 14:47Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Jens Grabowski
26-10-2017 14:47Jacob Wieland - SpirentStatusassigned => confirmed
02-01-2018 13:32Jens GrabowskiNote Added: 0014986
02-01-2018 13:32Jens GrabowskiNote Added: 0014987
02-01-2018 13:32Jens GrabowskiStatusconfirmed => resolved
02-01-2018 13:32Jens GrabowskiResolutionopen => fixed
02-01-2018 13:32Jens GrabowskiAssigned ToJens Grabowski => Gyorgy Rethy
04-01-2018 11:36Gyorgy RethyNote Added: 0014992
04-01-2018 11:36Gyorgy RethyFile Added: CR7276_5.docx
04-01-2018 11:37Gyorgy RethyAssigned ToGyorgy Rethy => Jens Grabowski
04-01-2018 11:37Gyorgy RethyStatusresolved => confirmed
04-01-2018 11:38Gyorgy RethyNote Edited: 0014992bug_revision_view_page.php?bugnote_id=14992#r454
04-01-2018 11:40Gyorgy RethyNote Edited: 0014992bug_revision_view_page.php?bugnote_id=14992#r455
04-01-2018 11:40Gyorgy RethyNote Edited: 0014992bug_revision_view_page.php?bugnote_id=14992#r456
04-01-2018 11:41Gyorgy RethyNote Edited: 0014992bug_revision_view_page.php?bugnote_id=14992#r457
04-01-2018 11:51Gyorgy RethyTarget Version => v4.10.1 (published 2018-05)
05-01-2018 09:08Jens GrabowskiNote Added: 0014998
05-01-2018 09:08Jens GrabowskiStatusconfirmed => resolved
05-01-2018 09:08Jens GrabowskiAssigned ToJens Grabowski => Gyorgy Rethy
05-01-2018 09:46Gyorgy RethyNote Edited: 0014992bug_revision_view_page.php?bugnote_id=14992#r458
05-01-2018 09:55Gyorgy RethyNote Added: 0015003
05-01-2018 09:55Gyorgy RethyStatusresolved => closed
05-01-2018 09:55Gyorgy RethyFixed in Version => v4.10.1 (published 2018-05)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014614) +
+ Jacob Wieland - Spirent    +
+ 03-05-2017 11:12    +
+ 		+ + + + +
+ It should behave the same way as for restricted integer types.
+
+type integer I1 (1 .. 10);
+type integer I2 (5 .. 50);
+
+var I1 v_1 := 5;
+var I2 v_2 := 5;
+log(v_1 == v2); // should produce true
+v_1 := 1;
+log(v_1 == v_2);// should produce false
+
+Basically, the comparison should work on the least-upper-bound of the two enumerated types, i.e. an (imaginary) enumerated type that contains all named values from both involved enumerated types. If they are not compatible, there is no least-upper-bound.
+
+This is the same principle as for the integer-comparison, here, the base type (which is an upper bound of all integer types) is used for the actual comparison semantics.
+
+
+
+ + + + + + + + + + +
+ (0014636) +
+ szabados    +
+ 07-06-2017 08:45    +
+ 		+ + + + +
+ I believe, that this understanding would require some examples in standard.
+example1:
+ 2 enums compatible if the only difference is that in one of them has the numbers explicitly set, the other not.
+  "
+type enumerated EWeekDays2 { Mon(0), Tue(1), Wed(2), Thu(3), Fri(4), Sat(5), Sun(6) }
+var EWeekDays2 v_weekDay2 := Mon;
+log (v_weekDay == v_weekDay2); // ok, logs "true"
+  "
+
+example2:
+ 2 enums that contain the same value and have the same semantic meaning are not compatible if the values are listed in a different order.
+"
+type enumerated EWeekDaysReordered { Sun, Mon, Tue, Wed, Thu, Fri, Sat }
+var EWeekDaysReordered v_weekDayReordered := Mon;
+log (v_weekDay == EWeekDaysReordered); // ok, logs "false"
+"
+
+
+
+ + + + + + + + + + +
+ (0014730) +
+ Julien Deltour    +
+ 24-07-2017 07:36    +
+ 		+ + + + +
+ Please review
+
+
+
+ + + + + + + + + + +
+ (0014731) +
+ Jacob Wieland - Spirent    +
+ 24-07-2017 10:33    +
+ 		+ + + + +
+ while the examples are very good, the description why comparing two enumerated types who are only partly (or not at all) compatible leads to false is somehow missing in the description text.
+
+
+
+ + + + + + + + + + +
+ (0014749) +
+ Julien Deltour    +
+ 25-07-2017 11:00    +
+ 		+ + + + +
+ The description of why two partially compatible enumerated types can return false has been added. Can you please review.
+
+
+
+ + + + + + + + + + +
+ (0014770) +
+ Jacob Wieland - Spirent    +
+ 26-07-2017 09:01    +
+ 		+ + + + +
+ I have not found it. Also, I would expect this description in the definition of the equality operator, not in the type compatibility section.
+
+The description should define that values of two enumerated types which can be combined to a larger enumerated type by merging their members together can be compared and will lead to true if the value with the same number associated exists in both enumerated types is the same on both sides of the equality operator, otherwise, the expression will evaluate to false.
+
+Thus, equality can only produce an error if the two types cannot be merged,i.e. if a number value is associated with two different names after the merging process.
+
+
+
+ + + + + + + + + + +
+ (0014886) +
+ Julien Deltour    +
+ 26-10-2017 11:40    +
+ 		+ + + + +
+ Please can you check for this new proposal ?
+
+
+
+ + + + + + + + + + +
+ (0014897) +
+ Jacob Wieland - Spirent    +
+ 26-10-2017 14:46    +
+ 		+ + + + +
+ I have reworded it slightly and in a way that is consistent with the proposal that two enumerated entities can only be compared if their types are mergeable. Otherwise, it is a static error.
+
+I have removed the assignment part as that has nothing to do with the mergeability of the enumerated types, but only with the simple compatibility rule. (a can be assigned to var of type B if a is compatible to B)
+
+The comparison examples should probably be moved to the section defining the comparison operators.
+
+
+
+ + + + + + + + + + +
+ (0014898) +
+ Jacob Wieland - Spirent    +
+ 26-10-2017 14:47    +
+ 		+ + + + +
+ please check as well
+
+
+
+ + + + + + + + + + +
+ (0014986) +
+ Jens Grabowski    +
+ 02-01-2018 13:32    +
+ 		+ + + + +
+ Ok
+
+
+
+ + + + + + + + + + +
+ (0014987) +
+ Jens Grabowski    +
+ 02-01-2018 13:32    +
+ 		+ + + + +
+ György, please have a final check.
+
+
+
+ + + + + + + + + + +
+ (0014992) +
+ Gyorgy Rethy    +
+ 04-01-2018 11:36    +
(edited on: 05-01-2018 09:46)
+ 		+ + + + +
+ Example 2 is showing cases of compatible/incompatible assignments. This is OK.
+
+But the new text and example 1 are related to comparing enum. values, which is described in clause 7.1.3 Relational operators. Now, the new text 6.3.2.1 and the current text in 7.1.3 are contradicting. In 7.1.3: "The relational operators less than (<), greater than (>), greater than or equal to (>=), and less than or equal to (<=) shall have only operands... or instances of the same enumerated type. It is not allowed to compare instances of different root types.
+...
+Operands of equality (==) and non-equality (!=) shall be ... of type compatible root types ..."
+
+New text in the CR allows comparing values of different, non-compatible enumerated types, while current 7.1.3 text forbids this. So, I propose to replace the current rule in 7.1.3 with the new one in this CR.
+
+See my resolution text proposal in CR7672_5.doc
+
+
+
+
+
+ + + + + + + + + + +
+ (0014998) +
+ Jens Grabowski    +
+ 05-01-2018 09:08    +
+ 		+ + + + +
+ Yes, looks good.
+
+
+
+ + + + + + + + + + +
+ (0015003) +
+ Gyorgy Rethy    +
+ 05-01-2018 09:55    +
+ 		+ + + + +
+ Implemented in draft V4.9.3.
+
+ + diff --git a/docs/mantis/CR7673.md b/docs/mantis/CR7673.md new file mode 100644 index 0000000000000000000000000000000000000000..3136f2462b920c0f879e6c223895c7a79bfa1af7 --- /dev/null +++ b/docs/mantis/CR7673.md @@ -0,0 +1,204 @@ + + + + + + + + + + + + + 0007673: dynamic_encoding parameter missing in encvalue_o and decvalue_o - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007673Part 01: TTCN-3 Core LanguageTechnicalpublic03-05-2017 13:2030-12-2017 19:58
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.9.1 (published 2017-05) 
Target Versionv4.10.1 (published 2018-05)Fixed in Versionv4.10.1 (published 2018-05) 
Clause Reference(s)C.5.5, C.5.6
Source (company - Author)Elvior
Summary0007673: dynamic_encoding parameter missing in encvalue_o and decvalue_o
DescriptionThe dynamic_encoding parameter hasn't been added to the new codec functions encvalue_o and decvalue_o.
+
+Besides, there's another small issue concerning these functions: the signature doesn't contain the keyword "function".
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7673.docx (163,772) 07-06-2017 13:45
http://oldforge.etsi.org/mantis/file_download.php?file_id=3604&type=bug
docx CR7673_v2.docx (174,180) 08-06-2017 20:55
http://oldforge.etsi.org/mantis/file_download.php?file_id=3614&type=bug
Issue History
Date ModifiedUsernameFieldChange
03-05-2017 13:20Tomas UrbanNew Issue
06-06-2017 11:17Jens GrabowskiNote Added: 0014620
06-06-2017 11:17Jens GrabowskiAssigned To => Jacob Wieland - Spirent
06-06-2017 11:17Jens GrabowskiStatusnew => assigned
07-06-2017 13:45Jacob Wieland - SpirentFile Added: CR7673.docx
07-06-2017 13:46Jacob Wieland - SpirentNote Added: 0014647
07-06-2017 13:46Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Kristóf Szabados
07-06-2017 13:46Jacob Wieland - SpirentStatusassigned => confirmed
08-06-2017 20:55Kristóf SzabadosFile Added: CR7673_v2.docx
08-06-2017 20:56Kristóf SzabadosAssigned ToKristóf Szabados => Jens Grabowski
08-06-2017 20:56Kristóf SzabadosStatusconfirmed => assigned
08-06-2017 20:57Kristóf SzabadosNote Added: 0014662
24-07-2017 11:02Jens GrabowskiNote Added: 0014733
24-07-2017 11:02Jens GrabowskiStatusassigned => resolved
24-07-2017 11:02Jens GrabowskiResolutionopen => fixed
24-07-2017 11:02Jens GrabowskiAssigned ToJens Grabowski => Gyorgy Rethy
30-12-2017 19:58Gyorgy RethyNote Added: 0014969
30-12-2017 19:58Gyorgy RethyStatusresolved => closed
30-12-2017 19:58Gyorgy RethyFixed in Version => v4.10.1 (published 2018-05)
30-12-2017 19:58Gyorgy RethyTarget Version => v4.10.1 (published 2018-05)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014620) +
+ Jens Grabowski    +
+ 06-06-2017 11:17    +
+ 		+ + + + +
+ STF discussion: agreed
+
+
+
+ + + + + + + + + + +
+ (0014647) +
+ Jacob Wieland - Spirent    +
+ 07-06-2017 13:46    +
+ 		+ + + + +
+ added missing parameters
+
+did not add'function' keyword as that is missing in the other signatures in this section as well (mostly)
+
+
+
+ + + + + + + + + + +
+ (0014662) +
+ Kristóf Szabados    +
+ 08-06-2017 20:57    +
+ 		+ + + + +
+ section 16.1.2 also lists these functions, so I corrected the syntax there too.
+Please check.
+
+
+
+ + + + + + + + + + +
+ (0014733) +
+ Jens Grabowski    +
+ 24-07-2017 11:02    +
+ 		+ + + + +
+ Ready for implementation
+
+
+
+ + + + + + + + + + +
+ (0014969) +
+ Gyorgy Rethy    +
+ 30-12-2017 19:58    +
+ 		+ + + + +
+ Added to draft V4.9.2
+
+ + diff --git a/docs/mantis/CR7677.md b/docs/mantis/CR7677.md new file mode 100644 index 0000000000000000000000000000000000000000..9d915145fd7f3df5699e50c09d2651f6dc67c49a --- /dev/null +++ b/docs/mantis/CR7677.md @@ -0,0 +1,374 @@ + + + + + + + + + + + + + 0007677: Additional restriction for the disconnect operation - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007677Part 01: TTCN-3 Core LanguageTechnicalpublic05-06-2017 14:2130-12-2017 21:08
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.9.1 (published 2017-05) 
Target Versionv4.10.1 (published 2018-05)Fixed in Versionv4.10.1 (published 2018-05) 
Clause Reference(s)21.1.2
Source (company - Author)Elvior
Summary0007677: Additional restriction for the disconnect operation
DescriptionAccording to the current rules, if the disconnect operation is applied to a mapped port, it has no effect. However, it doesn't make much sense to allow the disconnect operation when one of the parameters is a system port as such operation will never do anything and the user most likely made a mistake. System port references are detectable during compilation as they are always in the format "system:portName".
+
+For that reason, I propose to add the following restriction to the chapter 21.1.2:
+
+The disconnect operation parameters shall not contain an explicit system port reference.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0007607closed Gyorgy Rethy Additional restriction for the connect operation 
Attached Filesdocx CR_7677.docx (162,654) 07-06-2017 11:30
http://oldforge.etsi.org/mantis/file_download.php?file_id=3603&type=bug
docx CR_7677-v2.docx (187,145) 08-06-2017 16:32
http://oldforge.etsi.org/mantis/file_download.php?file_id=3612&type=bug
docx CR_7677-v2_CR_7607.docx (164,539) 08-06-2017 20:40
http://oldforge.etsi.org/mantis/file_download.php?file_id=3613&type=bug
Issue History
Date ModifiedUsernameFieldChange
05-06-2017 14:21Tomas UrbanNew Issue
06-06-2017 09:32Jacob Wieland - SpirentNote Added: 0014617
06-06-2017 10:06szabadosNote Added: 0014618
06-06-2017 11:09Jens GrabowskiNote Added: 0014619
06-06-2017 11:11Jens GrabowskiAssigned To => Kristóf Szabados
06-06-2017 11:11Jens GrabowskiStatusnew => assigned
07-06-2017 11:30Kristóf SzabadosFile Added: CR_7677.docx
07-06-2017 11:31Kristóf SzabadosNote Added: 0014646
07-06-2017 11:31Kristóf SzabadosAssigned ToKristóf Szabados => Tomas Urban
07-06-2017 11:31Kristóf SzabadosStatusassigned => confirmed
08-06-2017 08:56Jacob Wieland - SpirentNote Added: 0014650
08-06-2017 16:32Tomas UrbanFile Added: CR_7677-v2.docx
08-06-2017 16:32Tomas UrbanAssigned ToTomas Urban => Kristóf Szabados
08-06-2017 16:32Tomas UrbanStatusconfirmed => assigned
08-06-2017 16:35Tomas UrbanNote Added: 0014659
08-06-2017 16:35Tomas UrbanStatusassigned => confirmed
08-06-2017 20:34Kristóf SzabadosRelationship addedrelated to 0007607
08-06-2017 20:40Kristóf SzabadosFile Added: CR_7677-v2_CR_7607.docx
08-06-2017 20:41Kristóf SzabadosNote Added: 0014660
08-06-2017 20:42Kristóf SzabadosAssigned ToKristóf Szabados => Tomas Urban
08-06-2017 20:42Kristóf SzabadosStatusconfirmed => assigned
08-06-2017 20:42Kristóf SzabadosNote Added: 0014661
09-06-2017 08:13Tomas UrbanNote Added: 0014672
09-06-2017 08:13Tomas UrbanStatusassigned => resolved
09-06-2017 08:13Tomas UrbanResolutionopen => fixed
09-06-2017 08:13Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
30-12-2017 21:00Gyorgy RethyNote Added: 0014973
30-12-2017 21:00Gyorgy RethyProduct Versionv4.10.1 (published 2018-05) => v4.9.1 (published 2017-05)
30-12-2017 21:00Gyorgy RethyFixed in Version => v4.10.1 (published 2018-05)
30-12-2017 21:00Gyorgy RethyTarget Version => v4.10.1 (published 2018-05)
30-12-2017 21:08Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014617) +
+ Jacob Wieland - Spirent    +
+ 06-06-2017 09:32    +
+ 		+ + + + +
+ that is only partly correct. Any component reference given as a parameter could be the system component, so any <component_ref>:<port_ref> could be a system port reference that is only detectable at runtime, if <component_ref> is a parameter or other component-type variable.
+
+
+
+ + + + + + + + + + +
+ (0014618) +
+ szabados    +
+ 06-06-2017 10:06    +
+ 		+ + + + +
+ The restriction could also be written to the connect operation.
+Although from the description of the operation it comes that system should not be used ... it is better to explicitly state this fr both connect and disconnect.
+
+
+
+ + + + + + + + + + +
+ (0014619) +
+ Jens Grabowski    +
+ 06-06-2017 11:09    +
+ 		+ + + + +
+ STF discussion: add restriction, check also for connect, map, unmap
+
+
+
+ + + + + + + + + + +
+ (0014646) +
+ Kristóf Szabados    +
+ 07-06-2017 11:31    +
+ 		+ + + + +
+ could you please review the changes?
+
+
+
+ + + + + + + + + + +
+ (0014650) +
+ Jacob Wieland - Spirent    +
+ 08-06-2017 08:56    +
+ 		+ + + + +
+ I would strike the word 'explicit'. connect is not allowed if either of the components is the system component. If a tool can determine that statically, it can decide to reject that at compile time, otherwise, it shall be rejected at runtime at the latest.
+
+
+
+ + + + + + + + + + +
+ (0014659) +
+ Tomas Urban    +
+ 08-06-2017 16:35    +
+ 		+ + + + +
+ I made some changes according to the Jacob's proposal. Error handling is done according to the restriction 21.1.1.e, i.e. in compile time if possible and in runtime otherwise. I added a similar restriction to the map operation which should always contain one component port and one system port. Please check.
+
+
+
+ + + + + + + + + + +
+ (0014660) +
+ Kristóf Szabados    +
+ 08-06-2017 20:41    +
+ 		+ + + + +
+ as the edited text overlaps with CR 7607 I "related" the 2 CRs together to solve them in 1 document.
+
+
+
+ + + + + + + + + + +
+ (0014661) +
+ Kristóf Szabados    +
+ 08-06-2017 20:42    +
+ 		+ + + + +
+ Please review
+
+
+
+ + + + + + + + + + +
+ (0014672) +
+ Tomas Urban    +
+ 09-06-2017 08:13    +
+ 		+ + + + +
+ Reviewed, no more issues found. The proposal resolves the CR and is ready to be included in the next version of the core language specification.
+
+
+
+ + + + + + + + + + +
+ (0014973) +
+ Gyorgy Rethy    +
+ 30-12-2017 21:00    +
+ 		+ + + + +
+ Implemented in draft V4.9.2
+
+ + diff --git a/docs/mantis/CR7678.md b/docs/mantis/CR7678.md new file mode 100644 index 0000000000000000000000000000000000000000..39d945b0710dbab62294f7af2b530dde89c31e74 --- /dev/null +++ b/docs/mantis/CR7678.md @@ -0,0 +1,306 @@ + + + + + + + + + + + + + 0007678: Rename a module - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007678Part 01: TTCN-3 Core LanguageNew Featurepublic08-06-2017 14:2130-12-2017 15:17
ReporterJulien Deltour 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.9.1 (published 2017-05) 
Target Versionv4.10.1 (published 2018-05)Fixed in Versionv4.10.1 (published 2018-05) 
Clause Reference(s)8.2.3
Source (company - Author)STF 533
Summary0007678: Rename a module
DescriptionBecause module name can be very long, it will be interesting to add the possibility to rename a module during its import.
+For example :
+import VeryLongModuleName used/as shortName
+As a restriction, if an alias has been done, only shortName could be used.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc 7678.doc (120,832) 26-10-2017 08:46
http://oldforge.etsi.org/mantis/file_download.php?file_id=3703&type=bug
doc 7678_2.doc (526,336) 27-10-2017 11:34
http://oldforge.etsi.org/mantis/file_download.php?file_id=3722&type=bug
docx CR7678-v3.docx (281,802) 06-12-2017 05:30
http://oldforge.etsi.org/mantis/file_download.php?file_id=3726&type=bug
Issue History
Date ModifiedUsernameFieldChange
08-06-2017 14:21Julien DeltourNew Issue
24-07-2017 14:45Jens GrabowskiAssigned To => Julien Deltour
24-07-2017 14:45Jens GrabowskiStatusnew => assigned
24-07-2017 14:46Jens GrabowskiNote Added: 0014740
07-09-2017 08:44Tomas UrbanProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
26-10-2017 08:46Julien DeltourFile Added: 7678.doc
27-10-2017 09:36Jens GrabowskiNote Added: 0014905
27-10-2017 11:34Julien DeltourFile Added: 7678_2.doc
27-10-2017 11:34Julien DeltourNote Added: 0014912
27-10-2017 11:35Julien DeltourStatusassigned => confirmed
27-10-2017 11:35Julien DeltourAssigned ToJulien Deltour => Tomas Urban
27-10-2017 11:35Julien DeltourStatusconfirmed => assigned
27-10-2017 13:59Tomas UrbanNote Added: 0014919
27-10-2017 13:59Tomas UrbanAssigned ToTomas Urban => Julien Deltour
27-10-2017 13:59Tomas UrbanStatusassigned => confirmed
06-11-2017 11:22Julien DeltourNote Added: 0014922
06-11-2017 11:23Julien DeltourAssigned ToJulien Deltour => Tomas Urban
06-11-2017 11:23Julien DeltourStatusconfirmed => assigned
06-12-2017 05:30Tomas UrbanFile Added: CR7678-v3.docx
11-12-2017 08:40Julien DeltourNote Added: 0014927
11-12-2017 08:40Julien DeltourStatusassigned => resolved
11-12-2017 08:40Julien DeltourResolutionopen => fixed
11-12-2017 08:53Tomas UrbanStatusresolved => feedback
11-12-2017 08:53Tomas UrbanResolutionfixed => reopened
11-12-2017 08:53Tomas UrbanNote Added: 0014928
11-12-2017 08:53Tomas UrbanStatusfeedback => resolved
11-12-2017 08:53Tomas UrbanResolutionreopened => fixed
11-12-2017 08:53Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
30-12-2017 15:17Gyorgy RethyNote Added: 0014953
30-12-2017 15:17Gyorgy RethyStatusresolved => closed
30-12-2017 15:17Gyorgy RethyProduct Version => v4.9.1 (published 2017-05)
30-12-2017 15:17Gyorgy RethyFixed in Version => v4.10.1 (published 2018-05)
30-12-2017 15:17Gyorgy RethyTarget Version => v4.10.1 (published 2018-05)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014740) +
+ Jens Grabowski    +
+ 24-07-2017 14:46    +
+ 		+ + + + +
+ Please develop a proposal.
+
+
+
+ + + + + + + + + + +
+ (0014905) +
+ Jens Grabowski    +
+ 27-10-2017 09:36    +
+ 		+ + + + +
+ STF discussion:
+1) both original and new name shall be unique
+2) change new keyword "as" to "->"
+
+
+
+ + + + + + + + + + +
+ (0014912) +
+ Julien Deltour    +
+ 27-10-2017 11:34    +
+ 		+ + + + +
+ Modifications have been done. Please review.
+
+
+
+ + + + + + + + + + +
+ (0014919) +
+ Tomas Urban    +
+ 27-10-2017 13:59    +
+ 		+ + + + +
+ I made some changes in the used terms and corrected the example (it used the old syntax). Please check.
+
+
+
+ + + + + + + + + + +
+ (0014922) +
+ Julien Deltour    +
+ 06-11-2017 11:22    +
+ 		+ + + + +
+ Sorry Tomas but you have not uploaded any document.
+
+
+
+ + + + + + + + + + +
+ (0014927) +
+ Julien Deltour    +
+ 11-12-2017 08:40    +
+ 		+ + + + +
+ Ok for me
+
+
+
+ + + + + + + + + + +
+ (0014928) +
+ Tomas Urban    +
+ 11-12-2017 08:53    +
+ 		+ + + + +
+ Ready to be added to the next version of the core language specification.
+
+
+
+ + + + + + + + + + +
+ (0014953) +
+ Gyorgy Rethy    +
+ 30-12-2017 15:17    +
+ 		+ + + + +
+ Added to draft V4.9.2
+
+ + diff --git a/docs/mantis/CR7679.md b/docs/mantis/CR7679.md new file mode 100644 index 0000000000000000000000000000000000000000..66cf6b926c00bb1297ae93a2dd49f9c6a2a054b7 --- /dev/null +++ b/docs/mantis/CR7679.md @@ -0,0 +1,456 @@ + + + + + + + + + + + + + 0007679: Class Concept to be added - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Object-oriented features (ES 203 790)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007679Ext Pack: Object-oriented features (ES 203 790)[All Projects] Generalpublic09-06-2017 05:0707-05-2018 12:34
ReporterJacob Wieland - Spirent 
Assigned ToJens Grabowski 
PrioritynormalSeveritymajorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0007679: Class Concept to be added
DescriptionCurrently the language already contains certain kinds of object classes like components, ports and timers which are passed by reference and used with object-oriented-like syntax in their operations (start,stop,running,send,receive,etc.)
+
+Also, there is a demand to allow user-defined objects with encapsulated state and behavior that is not visible/accessible and public functionality that allows manipulation of that state.
+
+Thus, a class concept shall be introduced to TTCN-3 that addresses this demand but also allows the expression of the existing concepts as special kinds of classes.
+
+Features that the class concept need to encompass (to allow mapping of the old concepts to the new ones):
+- constructors (create)
+- readonly (dynamic) properties (like running, alive, started)
+- methods without parameter lists (like stop, kill)
+- events (like timeout, receive, getcall, getreply, catch, done, killed, check) with additional output channels (-> value, sender, param)
+- polymorphic methods (like send, call, reply, raise)
+
+The basic builtin class hierarchy would be:
+object
+- active object
+- - timer
+- - component
+- port
+- - message port
+- - procedure port
+- - mixed port (maybe extending both message and procedure port)
+
+The instances of classes, in contrast to the values of data types are objects that are always passed by reference-value, i.e. the value that is passed to in parameters is a reference to the object given as actual parameter, not a copy of that object.
+
+Members of objects can be accessed via dotted notation.
+
+The basic syntax of a class definition could be something like:
+
+type class <name> [extends <super_classes>] {
+  <member declarations>
+}
+
+It has to be discussed how clashing function definitions from two or more superclasses are to be handled.
+
+Forcing the user to override these functions (with allowed access to the super-implementations) is probably the best way with the following restrictions.
+
+Two classes containing a function of the same name can only be inherited together if the signature of the function is the same (or the formal parameter list of one is a prefix of the other and all additional formal parameters are either out parameters or in parameters with a default). If a function is overriding a function in an ancestor, its formal parameter list must the formal parameter list of the overriden function from as a prefix and all additional parameters must either be out parameters or in parameters with a default.
+
+Example:
+
+type class A {
+  function f(integer a)...
+}
+
+type class B {
+  function f(integer a, float b :- 0.0) ...
+}
+
+type class C extends A, B {
+  function f(integer a, float b, charstring c := "") ...
+}
+
+These restrictions ensure that whether an object of class C is used as an object of class A (in which only f(integer) can be called) or of class B (in which f(integer) and f(integer,float) can be called) all different versions of calling f are valid instances of the lowest function definition (the one in C).
+
+For other non-private members than functions, the same restrictions as for members of component types apply, i.e. they have to be unique in their class hierarchy.
+
+Special classes can be declared external. Both the state and the function of these classes are implemented outside of the language and their functionality provided via the Platform Adapter (x)triExternalFunction (the external functions get the object reference as their first parameter).
+This allows platform native implementations like Collection types or other libraries to be lifted in an abstract way into TTCN-3 without the need to reimplement them in TTCN-3, providing the functionality without great loss of efficiency or tool independence.
+
+Types defined by class definition are subtypes of their superclasses, e.g. their instances can be used as instances of their superclasses as well.
+
+A component or port type definition is a syntactic shortcut of a class definition extending either the base component/port type (if no supertypes are given) or their supertypes with special functions that depend on the new component/port type. In case of the component type, the start function is overridden to allow only behaviors that run on that component type to be started.
+
+type port P message { in <in_types>; out <out_types>; }
+
+would be equivalent with something like:
+
+type class P extends 'message port' {
+  @implicit function
+  send<<in_types> I, A>(template(value) I msg,
+             template(present) A 'to' := null);
+  @implicit @event
+  function receive<<out_types> O, A>(template(present) O msg,
+                                     template(present) A 'from' := ?,
+                                     out T 'value',
+                                     out A 'sender') return boolean;
+}
+
+where MessagePort is defined like:
+
+type class 'message port' extends 'port' {
+// message port specifics
+}
+
+type class 'port' extends 'active object' {
+  @implicit function checkstate(charstring state_kind) return boolean;
+  @implicit function 'stop';
+  @implicit function halt;
+  @implicit function start;
+  @implicit function clear;
+}
+
+type class 'active object' extends 'object' {
+  @implicit function 'running' return boolean;
+}
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0007731closed Jens Grabowski Draft document for Object-oriented Extension 
related to 0007693closed Kristóf Szabados component members with visibility and functions inside the components 
related to 0006801closed Kristóf Szabados Visibility of component definitions 
Attached Filesdocx ToC-Draft-OO2.docx (29,920) 04-09-2017 12:11
http://oldforge.etsi.org/mantis/file_download.php?file_id=3675&type=bug
? OO-Presentation.pptm (56,122) 07-09-2017 14:43
http://oldforge.etsi.org/mantis/file_download.php?file_id=3682&type=bug
docx OO-Draft-3.docx (29,595) 25-10-2017 08:30
http://oldforge.etsi.org/mantis/file_download.php?file_id=3688&type=bug
docx MTS-203790-00F_ed111v001.docx (168,418) 26-10-2017 09:16
http://oldforge.etsi.org/mantis/file_download.php?file_id=3705&type=bug
Issue History
Date ModifiedUsernameFieldChange
09-06-2017 05:07Jacob Wieland - SpirentNew Issue
09-06-2017 05:07Jacob Wieland - SpirentStatusnew => assigned
09-06-2017 05:07Jacob Wieland - SpirentAssigned To => Jacob Wieland - Spirent
09-06-2017 13:10Jacob Wieland - SpirentDescription Updatedbug_revision_view_page.php?rev_id=423#r423
25-07-2017 14:34Jens GrabowskiNote Added: 0014752
25-07-2017 16:21Jacob Wieland - SpirentNote Added: 0014759
25-07-2017 16:44Jacob Wieland - SpirentNote Added: 0014763
25-07-2017 16:54Jacob Wieland - SpirentNote Added: 0014764
25-07-2017 17:07Jacob Wieland - SpirentNote Edited: 0014759bug_revision_view_page.php?bugnote_id=14759#r430
26-07-2017 08:32Jacob Wieland - SpirentNote Edited: 0014763bug_revision_view_page.php?bugnote_id=14763#r432
26-07-2017 08:36Jacob Wieland - SpirentNote Edited: 0014764bug_revision_view_page.php?bugnote_id=14764#r434
04-09-2017 09:04Jens GrabowskiProjectTTCN-3 Change Requests => Ext Pack: Object-oriented features (ES 203 790)
04-09-2017 09:04Jens GrabowskiCategoryNew Feature => General
04-09-2017 12:11Jacob Wieland - SpirentFile Added: ToC-Draft-OO2.docx
07-09-2017 14:43Jacob Wieland - SpirentFile Added: OO-Presentation.pptm
24-10-2017 13:48Jens GrabowskiNote Added: 0014851
25-10-2017 08:30Jacob Wieland - SpirentFile Added: OO-Draft-3.docx
25-10-2017 08:40Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Julien Deltour
25-10-2017 08:40Jacob Wieland - SpirentNote Added: 0014857
26-10-2017 09:16Julien DeltourFile Added: MTS-203790-00F_ed111v001.docx
27-10-2017 11:19Kristóf SzabadosRelationship addedrelated to 0007693
27-10-2017 11:20Kristóf SzabadosRelationship addedrelated to 0006801
04-12-2017 15:42Julien DeltourRelationship addedrelated to 0007731
04-12-2017 15:43Julien DeltourNote Added: 0014925
04-12-2017 15:43Julien DeltourStatusassigned => confirmed
04-12-2017 15:43Julien DeltourAssigned ToJulien Deltour => Jens Grabowski
04-12-2017 15:43Julien DeltourStatusconfirmed => assigned
07-05-2018 12:34Jens GrabowskiStatusassigned => closed
07-05-2018 12:34Jens GrabowskiResolutionopen => fixed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014752) +
+ Jens Grabowski    +
+ 25-07-2017 14:34    +
+ 		+ + + + +
+ STF discussion: Jacob will provide a TTCN-3 OO code example.
+
+
+
+ + + + + + + + + + +
+ (0014759) +
+ Jacob Wieland - Spirent    +
+ 25-07-2017 16:21    +
(edited on: 25-07-2017 17:07)
+ 		+ + + + +
+ As per our discussion, we have identified a distinction between object-oriented operations between inter-component calls and intra-component calls.
+
+Inter-component operations are start, running, done, stop, kill, killed, alive
+
+An inter-component method call is the calling of a member-function inside a component context (or thread) to one of the components' objects. The set of components' objects are the component itself and all objects that it has created (component ports and timers as well as local objects) except other components.
+
+For example:
+
+external type class Stack<T> {
+  function push(T i);
+  function T pop();
+}
+
+type component StackComponent<T> {
+  var Stack<T> v_stack := Stack<T>.create;
+
+}
+
+In this scenario, a function that runs on StackComponent<T> would be allowed to call v_stack.push(t) and t := v_stack.pop()
+
+I think it should be allowed to share references to inner-component objects, but only behavior running on the owning component is allowed to access the members while other behavior can only pass the reference around and compare it with other references of compatible type. This is similar to sharing component references where all you can access are the inter-component operations but not the members of the referenced component.
+
+
+
+
+
+ + + + + + + + + + +
+ (0014763) +
+ Jacob Wieland - Spirent    +
+ 25-07-2017 16:44    +
(edited on: 26-07-2017 08:32)
+ 		+ + + + +
+ For port types, all port operations (send,receive,stop,halt,running,etc.) are (external) (generic) members that can be used inside the owning component.
+
+type class MessagePort<I,O> {
+  @implicit
+  function send(template(value) O msg, (ComponentType,address) 'to');
+  
+  @implicit
+  @event
+  function receive(template(present) I msg,
+                   out I 'value',
+                   out (Componenttype,address), 'sender')
+    return boolean;
+  
+  @remote
+  function start, stop, halt;
+  
+  @remote
+  function running return boolean;
+}
+
+A declaration
+
+type port P message { in I1, I2; out O1, O2 }
+
+would be equivalent with
+
+type class P extends MessagePort<(I1,I2), (O1, O2)>;
+
+
+
+
+
+ + + + + + + + + + +
+ (0014764) +
+ Jacob Wieland - Spirent    +
+ 25-07-2017 16:54    +
(edited on: 26-07-2017 08:36)
+ 		+ + + + +
+ For the moment, we have opted not to include multiple class inheritance into the OO language part.
+
+A component type which extends multiple component types T1, ..., Tn will be mapped to a class derived from the first type T1 with all fields only inherited from T2,...,Tn copied into the class body.
+
+For example:
+
+type component A {
+  var integer a;
+}
+
+type copmponent B extends A {
+  var integer b;
+}
+
+type component C extends A {
+  var integer c;
+}
+
+type component D extends B, C {
+  var integer d;
+}
+
+would result in the following type class definitions:
+
+type class A extends ComponentType {
+  var integer a;
+}
+
+type class B extends A {
+  var integer b;
+}
+
+type class C extends A {
+  var integer c;
+}
+
+type class D extends B {
+  var integer d;
+  var integer c;
+  // a from C is not copied because it is already inherited via B
+}
+
+For this to work, there needs to be a restriction on 'private' members that their names cannot clash (i.e. the same restriction as for non-private members applies). I think we should provide a new visibility modifier @invisible for that to avoid confusion with the normal understanding of 'private' (i.e. a name that is not visible anywhere outside the context which declares it).
+
+
+
+
+
+ + + + + + + + + + +
+ (0014851) +
+ Jens Grabowski    +
+ 24-10-2017 13:48    +
+ 		+ + + + +
+ STF decision: Textual proposal re-checked by Jacob and then assigned to Julien. Julien will put the text into the draft document.
+
+
+
+ + + + + + + + + + +
+ (0014857) +
+ Jacob Wieland - Spirent    +
+ 25-10-2017 08:40    +
+ 		+ + + + +
+ Please integrate the text from the latest Draft into the draft document.
+
+
+
+ + + + + + + + + + +
+ (0014925) +
+ Julien Deltour    +
+ 04-12-2017 15:43    +
+ 		+ + + + +
+ Full draft document has been created in a specific CR.
+
+ + diff --git a/docs/mantis/CR7680.md b/docs/mantis/CR7680.md new file mode 100644 index 0000000000000000000000000000000000000000..0de7757b002464dc113fc01bdc6ead89231f3a46 --- /dev/null +++ b/docs/mantis/CR7680.md @@ -0,0 +1,137 @@ + + + + + + + + + + + + + 0007680: A matching mechanism term for templates containing other matching mechanisms shall be added. - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007680Part 01: TTCN-3 Core LanguageClarificationpublic09-06-2017 11:1804-01-2018 16:48
ReporterJacob Wieland - Spirent 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.9.1 (published 2017-05) 
Target Versionv4.10.1 (published 2018-05)Fixed in Versionv4.10.1 (published 2018-05) 
Clause Reference(s)15,7, B.5
Source (company - Author)Spirent Jacob Wieland
Summary0007680: A matching mechanism term for templates containing other matching mechanisms shall be added.
DescriptionAt the moment, lots of places of the standard mention 'specific value' templates, intending for types like binary strings, lists, records and unions also structures which are not pure values but can contain also templates as elements.
+
+A specific value is of course a special case of such a template, but the set of such expressions is much larger.
+
+We propose to add the new term 'combined template' to describe a structured or string template that contains matching mechanisms as a new instead-of-value matching mechanism and use that new term in all places where specific value is used to signify such matching mechanism (e.g. in the all-from construct)
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7680.docx (230,165) 09-06-2017 15:56
http://oldforge.etsi.org/mantis/file_download.php?file_id=3638&type=bug
Issue History
Date ModifiedUsernameFieldChange
09-06-2017 11:18Jacob Wieland - SpirentNew Issue
09-06-2017 11:18Jacob Wieland - SpirentStatusnew => assigned
09-06-2017 11:18Jacob Wieland - SpirentAssigned To => Tomas Urban
09-06-2017 14:49Tomas UrbanFile Added: CR7680.docx
09-06-2017 14:54Tomas UrbanNote Added: 0014699
09-06-2017 14:54Tomas UrbanAssigned ToTomas Urban => Jacob Wieland - Spirent
09-06-2017 15:56Tomas UrbanFile Deleted: CR7680.docx
09-06-2017 15:56Tomas UrbanFile Added: CR7680.docx
28-07-2017 15:52Jacob Wieland - SpirentNote Added: 0014797
28-07-2017 15:52Jacob Wieland - SpirentStatusassigned => resolved
28-07-2017 15:52Jacob Wieland - SpirentResolutionopen => fixed
28-07-2017 15:52Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
04-01-2018 16:16Gyorgy RethyProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
04-01-2018 16:48Gyorgy RethyNote Added: 0014994
04-01-2018 16:48Gyorgy RethyProduct Version => v4.9.1 (published 2017-05)
04-01-2018 16:48Gyorgy RethyFixed in Version => v4.10.1 (published 2018-05)
04-01-2018 16:48Gyorgy RethyTarget Version => v4.10.1 (published 2018-05)
04-01-2018 16:48Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014699) +
+ Tomas Urban    +
+ 09-06-2017 14:54    +
+ 		+ + + + +
+ Initial draft uploaded. Please check.
+
+When adding the new term, I found several other terminology-related issues (such as binary strings not defined, references to matching symbols inside a value instead of metacharacters in case of pattern etc.) All these issues are addressed in the draft.
+
+
+
+ + + + + + + + + + +
+ (0014797) +
+ Jacob Wieland - Spirent    +
+ 28-07-2017 15:52    +
+ 		+ + + + +
+ seems fine to me
+
+
+
+ + + + + + + + + + +
+ (0014994) +
+ Gyorgy Rethy    +
+ 04-01-2018 16:48    +
+ 		+ + + + +
+ Added to draft V4.9.3
+
+ + diff --git a/docs/mantis/CR7681.md b/docs/mantis/CR7681.md new file mode 100644 index 0000000000000000000000000000000000000000..6ff68c9ecfac6c2d32d59586d9e8e9ca4b8f7199 --- /dev/null +++ b/docs/mantis/CR7681.md @@ -0,0 +1,201 @@ + + + + + + + + + + + + + 0007681: adapt TCI to the hanges in any2unistr predefined function changes - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007681Part 06: TTCN-3 Control InterfaceNew Featurepublic09-06-2017 14:2802-01-2018 12:39
ReporterKristóf Szabados 
Assigned ToTomas Urban 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Versionv4.9.1(ongoing) 
Clause Reference(s)16.1.2, 19.11, C.1.33
Source (company - Author)     LM. Ericsson
Summary0007681: adapt TCI to the hanges in any2unistr predefined function changes
DescriptionTo resolve CR 7605 we have added one optional parameter to the any2unistr predefined function.
+
+Upon the CR being resolved, TCI will also need to be updated.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0007605closed Gyorgy Rethy Part 01: TTCN-3 Core Language Logging of constructive values 
Attached Filesdocx CR7681-v1.docx (206,374) 24-07-2017 15:52
http://oldforge.etsi.org/mantis/file_download.php?file_id=3648&type=bug
Issue History
Date ModifiedUsernameFieldChange
09-06-2017 14:28Kristóf SzabadosNew Issue
09-06-2017 14:28Kristóf SzabadosStatusnew => assigned
09-06-2017 14:28Kristóf SzabadosAssigned To => Tomas Urban
24-07-2017 15:52Tomas UrbanFile Added: CR7681-v1.docx
24-07-2017 15:53Tomas UrbanNote Added: 0014741
24-07-2017 15:53Tomas UrbanAssigned ToTomas Urban => Kristóf Szabados
24-07-2017 15:53Tomas UrbanStatusassigned => confirmed
25-07-2017 15:10Kristóf SzabadosAssigned ToKristóf Szabados => Jacob Wieland - Spirent
25-07-2017 15:10Kristóf SzabadosStatusconfirmed => assigned
25-07-2017 15:10Kristóf SzabadosNote Added: 0014753
25-07-2017 15:11Kristóf SzabadosNote Added: 0014754
25-07-2017 15:11Kristóf SzabadosStatusassigned => confirmed
26-07-2017 09:25Jacob Wieland - SpirentRelationship addedrelated to 0007605
26-07-2017 09:26Jacob Wieland - SpirentProjectPart 01: TTCN-3 Core Language => Part 06: TTCN-3 Control Interface
24-10-2017 15:47Jacob Wieland - SpirentNote Added: 0014855
24-10-2017 15:47Jacob Wieland - SpirentStatusconfirmed => resolved
24-10-2017 15:47Jacob Wieland - SpirentFixed in Version => v4.9.1(ongoing)
24-10-2017 15:47Jacob Wieland - SpirentResolutionopen => fixed
24-10-2017 15:47Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Tomas Urban
02-01-2018 12:39Tomas UrbanNote Added: 0014983
02-01-2018 12:39Tomas UrbanStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014741) +
+ Tomas Urban    +
+ 24-07-2017 15:53    +
+ 		+ + + + +
+ Resolution uploaded, please check.
+
+
+
+ + + + + + + + + + +
+ (0014753) +
+ Kristóf Szabados    +
+ 25-07-2017 15:10    +
+ 		+ + + + +
+ Looks good for me, please check.
+
+
+
+ + + + + + + + + + +
+ (0014754) +
+ Kristóf Szabados    +
+ 25-07-2017 15:11    +
+ 		+ + + + +
+ actually this CR should be kept in confirmed state.
+
+
+
+ + + + + + + + + + +
+ (0014855) +
+ Jacob Wieland - Spirent    +
+ 24-10-2017 15:47    +
+ 		+ + + + +
+ as the core issue is resolved, we can resolve this as well
+
+
+
+ + + + + + + + + + +
+ (0014983) +
+ Tomas Urban    +
+ 02-01-2018 12:39    +
+ 		+ + + + +
+ Implemented in draft V4.9.2
+
+ + diff --git a/docs/mantis/CR7682.md b/docs/mantis/CR7682.md new file mode 100644 index 0000000000000000000000000000000000000000..b939c77f1f1026887c0d945c7a147a56e1295e43 --- /dev/null +++ b/docs/mantis/CR7682.md @@ -0,0 +1,608 @@ + + + + + + + + + + + + + 0007682: Table with index-operators using keys as indices should be supported - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007682Part 01: TTCN-3 Core LanguageNew Featurepublic09-06-2017 14:3028-12-2019 15:07
ReporterJacob Wieland - Spirent 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.9.1 (published 2017-05) 
Target Version4.11.1 (published 2019-05)Fixed in Version4.12.1 (published 2020-05) 
Clause Reference(s)6.2
Source (company - Author)Spirent Jacob Wieland
Summary0007682: Table with index-operators using keys as indices should be supported
DescriptionTables (or Dictionaries) that associate unique keys with values are a central programming tool in any programming language useful for multitude of algorithms.
+
+A table type concept should be introduced in TTCN-3 to allow definition and usage of tables.
+
+The basic type definiton could look like this:
+
+type table T from IndexType to ValueType;
+
+Operations on table variables would be:
+- indexing: t[key] where key needs to be of type IndexType
+  on the right hand side it yields the value associated with key of ValueType
+  on the left hand side it associates a new value with the key
+  If key is not associated to any value, either omit or null could be the result (and could also be used to delete entries from the table).
+
+The index-assignment syntax could be used as a table-value notation:
+
+{ [key1] := value1,
+  [key2] := value2,
+  ...
+}
+
+The same properties as for record of values would apply, record ofs being essentially a special table with integer as key.
+
+At first, this new type needs not to be considered in the context of codecs and TCI because they are to be used for easing implementation of testcases, not as messages.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7682.docx (263,410) 09-08-2019 10:53
http://oldforge.etsi.org/mantis/file_download.php?file_id=3851&type=bug
docx CR7682-2.docx (254,596) 16-12-2019 12:22
http://oldforge.etsi.org/mantis/file_download.php?file_id=3869&type=bug
Issue History
Date ModifiedUsernameFieldChange
09-06-2017 14:30Jacob Wieland - SpirentNew Issue
09-06-2017 14:30Jacob Wieland - SpirentStatusnew => assigned
09-06-2017 14:30Jacob Wieland - SpirentAssigned To => Jacob Wieland - Spirent
09-06-2017 15:45Jacob Wieland - SpirentStatusassigned => new
04-09-2017 09:25Jens GrabowskiNote Added: 0014804
04-09-2017 09:26Jens GrabowskiStatusnew => assigned
24-10-2017 12:48Jens GrabowskiNote Added: 0014845
24-10-2017 12:48Jens GrabowskiAssigned ToJacob Wieland - Spirent => Jens Grabowski
05-01-2018 13:29Gyorgy RethyTarget Versionv4.10.1 (published 2018-05) => 4.11.1 (published 2019-05)
06-08-2019 12:54Kristóf SzabadosNote Added: 0015375
08-08-2019 14:20Kristóf SzabadosNote Added: 0015434
08-08-2019 14:20Kristóf SzabadosAssigned ToJens Grabowski => Jacob Wieland - Spirent
09-08-2019 10:53Jacob Wieland - SpirentFile Added: CR7682.docx
09-08-2019 10:56Jacob Wieland - SpirentNote Added: 0015439
09-08-2019 10:56Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Tomas Urban
09-08-2019 10:56Jacob Wieland - SpirentStatusassigned => confirmed
13-08-2019 16:44Kristóf SzabadosNote Added: 0015440
14-08-2019 09:47Jacob Wieland - SpirentNote Added: 0015441
14-08-2019 12:52Kristóf SzabadosNote Added: 0015442
23-08-2019 15:05Kristóf SzabadosNote Added: 0015447
26-08-2019 08:19Jacob Wieland - SpirentNote Added: 0015448
26-08-2019 09:49Kristóf SzabadosNote Added: 0015449
26-08-2019 11:25Jacob Wieland - SpirentNote Added: 0015456
26-08-2019 11:26Jacob Wieland - SpirentAssigned ToTomas Urban => Jacob Wieland - Spirent
26-08-2019 11:26Jacob Wieland - SpirentStatusconfirmed => assigned
16-12-2019 12:12Jacob Wieland - SpirentFile Added: CR7682-2.docx
16-12-2019 12:22Jacob Wieland - SpirentFile Deleted: CR7682-2.docx
16-12-2019 12:22Jacob Wieland - SpirentFile Added: CR7682-2.docx
16-12-2019 12:24Jacob Wieland - SpirentNote Added: 0015520
16-12-2019 12:24Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Kristóf Szabados
16-12-2019 12:24Jacob Wieland - SpirentStatusassigned => confirmed
17-12-2019 09:00Kristóf SzabadosNote Added: 0015539
17-12-2019 09:00Kristóf SzabadosStatusconfirmed => resolved
17-12-2019 09:00Kristóf SzabadosFixed in Version => 4.11.1 (published 2019-05)
17-12-2019 09:00Kristóf SzabadosResolutionopen => fixed
28-12-2019 12:54Gyorgy RethyAssigned ToKristóf Szabados => Gyorgy Rethy
28-12-2019 12:54Gyorgy RethyStatusresolved => assigned
28-12-2019 15:07Gyorgy RethyNote Added: 0015588
28-12-2019 15:07Gyorgy RethyStatusassigned => closed
28-12-2019 15:07Gyorgy RethyFixed in Version4.11.1 (published 2019-05) => 4.12.1 (published 2020-05)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014804) +
+ Jens Grabowski    +
+ 04-09-2017 09:25    +
+ 		+ + + + +
+ - Jacob, can you provide a use case?
+- Is it sufficient to build hash tables/trees with objects in the Java style?
+
+
+
+ + + + + + + + + + +
+ (0014845) +
+ Jens Grabowski    +
+ 24-10-2017 12:48    +
+ 		+ + + + +
+ STF decision: To be shifted to 2018 maintenance.
+
+
+
+ + + + + + + + + + +
+ (0015375) +
+ Kristóf Szabados    +
+ 06-08-2019 12:54    +
+ 		+ + + + +
+ STF discussion: this can be seen as a short hand notation for a record of record structure, with implicit coding/decoding. And intuitive syntax for element access.
+
+
+
+ + + + + + + + + + +
+ (0015434) +
+ Kristóf Szabados    +
+ 08-08-2019 14:20    +
+ 		+ + + + +
+ STF discussion: Jacob makes a proposal. STF aggress that the feature is useful.
+
+
+
+ + + + + + + + + + +
+ (0015439) +
+ Jacob Wieland - Spirent    +
+ 09-08-2019 10:56    +
+ 		+ + + + +
+ Added first draft including the following features:
+- map type definition
+- indexed assignment notation (for map values)
+- index operation for accessing elements
+- from operation for accessing the key set
+- to operation for accessing the value set
+- type compatibility
+
+Please review
+
+
+
+ + + + + + + + + + +
+ (0015440) +
+ Kristóf Szabados    +
+ 13-08-2019 16:44    +
+ 		+ + + + +
+ The described behavior does not sound to be consistent with the already existing parts of the standard.
+
+When the assignment notation is used on the right hand side, with a key that has no associated value, the index notation shall cause a semantic or runtime error Just like in the case of record of and set of types when the indexed element is undefined or uninitialized.
+
+To check if a key-value mapping is present in the map, the ispresent predefined function should be used.
+
+
+
+ + + + + + + + + + +
+ (0015441) +
+ Jacob Wieland - Spirent    +
+ 14-08-2019 09:47    +
+ 		+ + + + +
+ I don't understand what you mean with 'When the assignment notation is used on the right hand side with a key that has no associated value'. If you use the assignment notation (i.e. { [key] := value }) on the right hand side, the assignment to the key associates it to a value (or -). I have kept that part the same as for record of values, so this is consistent.
+
+Maybe you are referring to the index notation (i.e. m[key]) on the right hand side?
+
+If you read carefully, for the index notation it is exactly as you describe in the proposal, using it on the right hand side in anything else than a null-comparison shall result in an error. So, the null-comparison is just a way of checking for presentness.
+
+It seemed strange to me that assigning null to a field should be possible and not checking via equality, so allowing comparison with null seemed kind of natural/intuitive. But I am also fine with disallowing even the null-check.
+
+So, if you want to always cause it an error, the isbound/ispresent/isvalue functions can all be used for checking if a key has an associated value (by basically checking that the expression doesn't cause an error).
+
+Are you okay with the null-assignment for removing a key-association or do we need to invent some other syntax for that?
+
+
+
+ + + + + + + + + + +
+ (0015442) +
+ Kristóf Szabados    +
+ 14-08-2019 12:52    +
+ 		+ + + + +
+ True, I ment index notation.
+Yes, I would find it better if we would disallow the null-check.
+
+
+
+ + + + + + + + + + +
+ (0015447) +
+ Kristóf Szabados    +
+ 23-08-2019 15:05    +
+ 		+ + + + +
+ maybe the replace predefined function would be better for deleting/replacing existing mappings.
+For example:
+type map from charstring to charstring charToCharMap; // much like record of charstring;
+var chartoCharMap myMap:= {["1"] := "1", ["2"] := "2", ["3"] := "3", ["4"] := "4"};
+then use something like replace(myMap, "1", 1, {} ) to delete the first mapping, replace (myMap, "1", 2, {}) to replace/delete the first 2 mappings.
+
+This way we could work with multiple mappings at the same time.
+Maybe even the substring predefined function could be used like this.
+And it would be consistent with a maps are record of record understanding.
+
+
+
+ + + + + + + + + + +
+ (0015448) +
+ Jacob Wieland - Spirent    +
+ 26-08-2019 08:19    +
+ 		+ + + + +
+ I don't think this is a good idea for several reasons:
+
+- replace doesn't work in place on variables, but produces a copy, so this is a costly operation if the tables are large
+- so far, there is no order to the keys imposed, so it would be unintuitive to assume one but you need it to specify something like the 'first two mappings'
+
+As an alternative, we could overload the unmap operation to unmap a key in a table:
+
+                    unmap(v_table, v_key)
+
+
+
+ + + + + + + + + + +
+ (0015449) +
+ Kristóf Szabados    +
+ 26-08-2019 09:49    +
+ 		+ + + + +
+ unmap might also be fine.
+
+please note, that the order in which the mappings are "added" to the table, intuitively create and ordering.
+Just like with database tables, the order you insert the rows is the order people will expect to read them.
+
+
+
+ + + + + + + + + + +
+ (0015456) +
+ Jacob Wieland - Spirent    +
+ 26-08-2019 11:25    +
+ 		+ + + + +
+ STF discussion: overload the unmap operation also to delete keys from map variables.
+
+
+
+ + + + + + + + + + +
+ (0015520) +
+ Jacob Wieland - Spirent    +
+ 16-12-2019 12:24    +
+ 		+ + + + +
+ Changed according to discussion. Unmap to be used to remove key-value associations. isbound etc to be used to check for association. referencing of undefined association on right hand side causes error.
+
+Also amended BNF accordingly.
+
+Please check.
+
+
+
+ + + + + + + + + + +
+ (0015539) +
+ Kristóf Szabados    +
+ 17-12-2019 09:00    +
+ 		+ + + + +
+ Looks good to me, can be included in the standard.
+
+
+
+ + + + + + + + + + +
+ (0015588) +
+ Gyorgy Rethy    +
+ 28-12-2019 15:07    +
+ 		+ + + + +
+ Included to final draft 4.11.2.
+
+ + diff --git a/docs/mantis/CR7683.md b/docs/mantis/CR7683.md new file mode 100644 index 0000000000000000000000000000000000000000..6dc6446baa9a7097136896c9eb3a71c9ce1fb53e --- /dev/null +++ b/docs/mantis/CR7683.md @@ -0,0 +1,205 @@ + + + + + + + + + + + + + 0007683: Keywords (from packages) should be reserved in the Core Standard. - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007683Part 01: TTCN-3 Core LanguageTechnicalpublic09-06-2017 15:3830-12-2017 19:16
ReporterJacob Wieland - Spirent 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.9.1 (published 2017-05) 
Target Versionv4.10.1 (published 2018-05)Fixed in Versionv4.10.1 (published 2018-05) 
Clause Reference(s)Table A.3 in A.1.5.0
Source (company - Author)Spirent Jacob Wieland
Summary0007683: Keywords (from packages) should be reserved in the Core Standard.
DescriptionTo remove the problem that something is a keyword in some context and not in another context (depending on what packages are used in a module), all keywords used by any package should be put into the reserved words table of the core language standard.
+
+That way, the set of keywords is only dependent on the TTCN-3 language version and not on the set of used packages which.
+
+This will remove a lot of potential confusion and tool-incorrectness (most language mappings depend on the set of keywords in their name-mangling algorithms).
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0007530closed Gyorgy Rethy keywords should be escapable to be used as a TTCN-3 identifier. 
Attached Filesdocx CR_7683_core.docx (166,242) 26-07-2017 08:56
http://oldforge.etsi.org/mantis/file_download.php?file_id=3659&type=bug
docx CR_7863_XML.docx (172,774) 26-07-2017 08:56
http://oldforge.etsi.org/mantis/file_download.php?file_id=3660&type=bug
docx CR_7683_core_v2.docx (165,700) 26-07-2017 09:17
http://oldforge.etsi.org/mantis/file_download.php?file_id=3661&type=bug
Issue History
Date ModifiedUsernameFieldChange
09-06-2017 15:38Jacob Wieland - SpirentNew Issue
09-06-2017 15:39Jacob Wieland - SpirentRelationship addedrelated to 0007530
24-07-2017 14:44Jens GrabowskiNote Added: 0014739
24-07-2017 14:44Jens GrabowskiAssigned To => Kristóf Szabados
24-07-2017 14:44Jens GrabowskiStatusnew => assigned
26-07-2017 08:56Kristóf SzabadosFile Added: CR_7683_core.docx
26-07-2017 08:56Kristóf SzabadosFile Added: CR_7863_XML.docx
26-07-2017 08:58Kristóf SzabadosNote Added: 0014769
26-07-2017 08:58Kristóf SzabadosAssigned ToKristóf Szabados => Jacob Wieland - Spirent
26-07-2017 08:58Kristóf SzabadosStatusassigned => confirmed
26-07-2017 09:17Kristóf SzabadosFile Added: CR_7683_core_v2.docx
26-07-2017 09:17Kristóf SzabadosNote Added: 0014771
26-07-2017 09:19Jacob Wieland - SpirentNote Added: 0014772
26-07-2017 09:19Jacob Wieland - SpirentStatusconfirmed => resolved
26-07-2017 09:19Jacob Wieland - SpirentFixed in Version => v4.9.1 (published 2017-05)
26-07-2017 09:19Jacob Wieland - SpirentResolutionopen => fixed
26-07-2017 09:19Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
30-12-2017 19:16Gyorgy RethyNote Added: 0014966
30-12-2017 19:16Gyorgy RethyStatusresolved => closed
30-12-2017 19:16Gyorgy RethyFixed in Versionv4.9.1 (published 2017-05) => v4.10.1 (published 2018-05)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014739) +
+ Jens Grabowski    +
+ 24-07-2017 14:44    +
+ 		+ + + + +
+ STF discussion: Ext. package keywords should be mentioned in Core Language, but possibly as some sort of warning. Name transformation rules shall be applied to all Ext. package keywords.
+
+
+
+ + + + + + + + + + +
+ (0014769) +
+ Kristóf Szabados    +
+ 26-07-2017 08:58    +
+ 		+ + + + +
+ I have uploaded the updated core part, and also the updated Part9 (Using XML schema with TTCN-3).
+
+Please check.
+
+
+
+ + + + + + + + + + +
+ (0014771) +
+ Kristóf Szabados    +
+ 26-07-2017 09:17    +
+ 		+ + + + +
+ fixed the typo.
+
+
+
+ + + + + + + + + + +
+ (0014772) +
+ Jacob Wieland - Spirent    +
+ 26-07-2017 09:19    +
+ 		+ + + + +
+ fine by me
+
+
+
+ + + + + + + + + + +
+ (0014966) +
+ Gyorgy Rethy    +
+ 30-12-2017 19:16    +
+ 		+ + + + +
+ Added to draft V4.9.2(core) and V4.8.2(XML).
+
+ + diff --git a/docs/mantis/CR7684.md b/docs/mantis/CR7684.md new file mode 100644 index 0000000000000000000000000000000000000000..eb360d01393c2a94fc9c174c99bd36d4d54a975b --- /dev/null +++ b/docs/mantis/CR7684.md @@ -0,0 +1,132 @@ + + + + + + + + + + + + + 0007684: Language version string - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007684Part 01: TTCN-3 Core LanguageEditorialpublic15-06-2017 14:4230-12-2017 22:15
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeveritymajorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.9.1 (published 2017-05) 
Target Versionv4.10.1 (published 2018-05)Fixed in Versionv4.10.1 (published 2018-05) 
Clause Reference(s)8.1
Source (company - Author)Elvior
Summary0007684: Language version string
DescriptionIt seems that language version string was omitted in 4.9.1. The section 8.1 should describe "TTCN-3:2017". Since there's a new version being prepared, "TTCN-3:2018" should be specified as well.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR_7684.docx (159,310) 25-07-2017 16:08
http://oldforge.etsi.org/mantis/file_download.php?file_id=3654&type=bug
Issue History
Date ModifiedUsernameFieldChange
15-06-2017 14:42Tomas UrbanNew Issue
24-07-2017 14:25Jens GrabowskiAssigned To => Kristóf Szabados
24-07-2017 14:25Jens GrabowskiStatusnew => assigned
25-07-2017 16:08Kristóf SzabadosFile Added: CR_7684.docx
25-07-2017 16:09Kristóf SzabadosNote Added: 0014758
25-07-2017 16:09Kristóf SzabadosAssigned ToKristóf Szabados => Tomas Urban
25-07-2017 16:09Kristóf SzabadosStatusassigned => confirmed
25-07-2017 16:36Tomas UrbanNote Added: 0014762
25-07-2017 16:36Tomas UrbanStatusconfirmed => resolved
25-07-2017 16:36Tomas UrbanFixed in Version => v4.10.1 (published 2018-05)
25-07-2017 16:36Tomas UrbanResolutionopen => fixed
25-07-2017 16:36Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
30-12-2017 22:15Gyorgy RethyNote Added: 0014977
30-12-2017 22:15Gyorgy RethyStatusresolved => closed
30-12-2017 22:15Gyorgy RethyTarget Version => v4.10.1 (published 2018-05)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014758) +
+ Kristóf Szabados    +
+ 25-07-2017 16:09    +
+ 		+ + + + +
+ I have extended section 8.1 and updated annex H.
+Please check.
+
+
+
+ + + + + + + + + + +
+ (0014762) +
+ Tomas Urban    +
+ 25-07-2017 16:36    +
+ 		+ + + + +
+ No problems found. Ready to be added to the next version of the core language specification.
+
+
+
+ + + + + + + + + + +
+ (0014977) +
+ Gyorgy Rethy    +
+ 30-12-2017 22:15    +
+ 		+ + + + +
+ Implemented in draft V4.9.2
+
+ + diff --git a/docs/mantis/CR7688.md b/docs/mantis/CR7688.md new file mode 100644 index 0000000000000000000000000000000000000000..39d6074ed0ce7b9c585b39985443217a3c6f0f6a --- /dev/null +++ b/docs/mantis/CR7688.md @@ -0,0 +1,293 @@ + + + + + + + + + + + + + 0007688: The rule for loops inside interleave is too restrictive - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007688Part 01: TTCN-3 Core LanguageTechnicalpublic27-06-2017 10:5630-12-2017 18:34
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.9.1 (published 2017-05) 
Target Versionv4.10.1 (published 2018-05)Fixed in Versionv4.10.1 (published 2018-05) 
Clause Reference(s)20.4
Source (company - Author)Elvior
Summary0007688: The rule for loops inside interleave is too restrictive
DescriptionThe rule for loops inside interleave (20.4.d) should restrict the use of loops only if the reception statement is inside the loop statement. The current rule leads to an absurd situation when the code in the first of the following examples is not allowed, but the second one is perfectly valid:
+
+Example 1:
+interleave {
+  [] pCO1.receive(mw_mySig1) {
+     for (var integer i := 0; i < 3; i := i + 1) { // not OK, the following receive is within the same statement block as the for loop
+        log("test");
+     }
+     PCO1.receive(mw_mySig3);
+  }
+  [] pCO2.receive(mw_mySig4) {
+  }
+}
+
+Example 2:
+interleave {
+  [] pCO1.receive(mw_mySig1) {
+     {
+        for (var integer i := 0; i < 3; i := i + 1) { // OK, the following receive is NOT in same statement block as the for loop
+           log("test");
+        }
+     }
+     PCO1.receive(mw_mySig3);
+  }
+  [] pCO2.receive(mw_mySig4) {
+  }
+}
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files? 7688.odt (26,188) 24-07-2017 16:04
http://oldforge.etsi.org/mantis/file_download.php?file_id=3649&type=bug
doc 7688.doc (22,528) 26-07-2017 09:44
http://oldforge.etsi.org/mantis/file_download.php?file_id=3662&type=bug
Issue History
Date ModifiedUsernameFieldChange
27-06-2017 10:56Tomas UrbanNew Issue
27-06-2017 11:43Jacob Wieland - SpirentNote Added: 0014716
27-06-2017 11:46Jacob Wieland - SpirentNote Added: 0014717
24-07-2017 14:24Jens GrabowskiNote Added: 0014738
24-07-2017 14:24Jens GrabowskiAssigned To => Julien Deltour
24-07-2017 14:24Jens GrabowskiStatusnew => assigned
24-07-2017 16:04Julien DeltourFile Added: 7688.odt
24-07-2017 16:04Julien DeltourNote Added: 0014742
24-07-2017 16:05Julien DeltourAssigned ToJulien Deltour => Jacob Wieland - Spirent
24-07-2017 16:05Julien DeltourStatusassigned => confirmed
26-07-2017 09:44Julien DeltourFile Added: 7688.doc
26-07-2017 09:44Julien DeltourNote Added: 0014776
26-07-2017 14:06Jacob Wieland - SpirentNote Added: 0014782
26-07-2017 14:06Jacob Wieland - SpirentStatusconfirmed => resolved
26-07-2017 14:06Jacob Wieland - SpirentFixed in Version => v4.9.1 (published 2017-05)
26-07-2017 14:06Jacob Wieland - SpirentResolutionopen => fixed
26-07-2017 14:06Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
30-12-2017 18:34Gyorgy RethyNote Added: 0014963
30-12-2017 18:34Gyorgy RethyStatusresolved => closed
30-12-2017 18:34Gyorgy RethyFixed in Versionv4.9.1 (published 2017-05) => v4.10.1 (published 2018-05)
30-12-2017 18:34Gyorgy RethyTarget Version => v4.10.1 (published 2018-05)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014716) +
+ Jacob Wieland - Spirent    +
+ 27-06-2017 11:43    +
+ 		+ + + + +
+ What part of the rule disallows the first example?
+
+
+
+ + + + + + + + + + +
+ (0014717) +
+ Jacob Wieland - Spirent    +
+ 27-06-2017 11:46    +
+ 		+ + + + +
+ ah, I think this is a typo: the 'within' should be 'with'. At least that was the intention of the CR that introduced this.
+
+
+
+ + + + + + + + + + +
+ (0014738) +
+ Jens Grabowski    +
+ 24-07-2017 14:24    +
+ 		+ + + + +
+ STF discussion: Wording Problem.
+
+
+
+ + + + + + + + + + +
+ (0014742) +
+ Julien Deltour    +
+ 24-07-2017 16:04    +
+ 		+ + + + +
+ Please review.
+
+
+
+ + + + + + + + + + +
+ (0014776) +
+ Julien Deltour    +
+ 26-07-2017 09:44    +
+ 		+ + + + +
+ Add a new document with the correct format (doc file)
+
+
+
+ + + + + + + + + + +
+ (0014782) +
+ Jacob Wieland - Spirent    +
+ 26-07-2017 14:06    +
+ 		+ + + + +
+ ok
+
+
+
+ + + + + + + + + + +
+ (0014963) +
+ Gyorgy Rethy    +
+ 30-12-2017 18:34    +
+ 		+ + + + +
+ Added to draft V4.9.2
+
+ + diff --git a/docs/mantis/CR7689.md b/docs/mantis/CR7689.md new file mode 100644 index 0000000000000000000000000000000000000000..8d50713f2743d7ca86a3907b02964f1b8760e59e --- /dev/null +++ b/docs/mantis/CR7689.md @@ -0,0 +1,317 @@ + + + + + + + + + + + + + 0007689: Unconditional goto in interleave - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007689Part 01: TTCN-3 Core LanguageTechnicalpublic27-06-2017 12:5330-12-2017 19:51
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.9.1 (published 2017-05) 
Target Versionv4.10.1 (published 2018-05)Fixed in Versionv4.10.1 (published 2018-05) 
Clause Reference(s)20.4
Source (company - Author)Elvior
Summary0007689: Unconditional goto in interleave
DescriptionWhat exactly does the term unconditional goto (used in 20.4. restriction d) mean? The term is not precisely specified and might be interpreted in different ways. My interpretation is that goto cannot occur inside if-else, select-case, for and while. However, I do not understand the reason why this restriction is used when other similar jumps (break, return) can be "conditional".
+
+I would prefer to remove the "unconditional" word completely. If that is not possible, the term should be precisely specified.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR-7689-170725.docx (65,693) 25-07-2017 08:51
http://oldforge.etsi.org/mantis/file_download.php?file_id=3650&type=bug
Issue History
Date ModifiedUsernameFieldChange
27-06-2017 12:53Tomas UrbanNew Issue
28-06-2017 09:09Jacob Wieland - SpirentNote Added: 0014722
28-06-2017 09:10Jacob Wieland - SpirentNote Added: 0014723
28-06-2017 09:50Tomas UrbanNote Added: 0014724
28-06-2017 10:20Jacob Wieland - SpirentNote Added: 0014725
28-06-2017 10:21Jacob Wieland - SpirentNote Edited: 0014725bug_revision_view_page.php?bugnote_id=14725#r425
28-06-2017 10:22Jacob Wieland - SpirentNote Edited: 0014725bug_revision_view_page.php?bugnote_id=14725#r426
24-07-2017 14:18Jens GrabowskiAssigned To => Jens Grabowski
24-07-2017 14:18Jens GrabowskiStatusnew => assigned
25-07-2017 08:48Jens GrabowskiNote Added: 0014746
25-07-2017 08:51Jens GrabowskiFile Added: CR-7689-170725.docx
25-07-2017 08:52Jens GrabowskiNote Added: 0014748
25-07-2017 08:52Jens GrabowskiAssigned ToJens Grabowski => Tomas Urban
25-07-2017 08:52Jens GrabowskiStatusassigned => confirmed
25-07-2017 13:05Tomas UrbanNote Added: 0014751
25-07-2017 13:05Tomas UrbanStatusconfirmed => resolved
25-07-2017 13:05Tomas UrbanFixed in Version => v4.10.1 (published 2018-05)
25-07-2017 13:05Tomas UrbanResolutionopen => fixed
25-07-2017 13:05Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
30-12-2017 19:51Gyorgy RethyNote Added: 0014968
30-12-2017 19:51Gyorgy RethyStatusresolved => closed
30-12-2017 19:51Gyorgy RethyTarget Versionv4.9.1 (published 2017-05) => v4.10.1 (published 2018-05)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014722) +
+ Jacob Wieland - Spirent    +
+ 28-06-2017 09:09    +
+ 		+ + + + +
+ I think the whole idea of these restrictions was that there should be a linear path from the start of a block to the next reception statement to still allow the unfolding of the interleave to an alt-statement.
+
+If-statements that include goto statements don't fit into that. In my opinion, goto statements that do not jump out of the interleave also don't really fit into that.
+
+Additionally, if statements are not treated by this clause, though similar constructs are allowed if they don't contain reception statements.
+
+const boolean E := C; while (E) { S1; break } while (not E) { S2; break; }
+
+is equlivalent to
+
+if (C) { S1 } else { S2 }
+
+So, allowing if-statements that contain no reception statements should also be considered.
+
+
+
+ + + + + + + + + + +
+ (0014723) +
+ Jacob Wieland - Spirent    +
+ 28-06-2017 09:10    +
+ 		+ + + + +
+ you could say that goto statements should only be allowed if they don't jump over any reception statement.
+
+
+
+ + + + + + + + + + +
+ (0014724) +
+ Tomas Urban    +
+ 28-06-2017 09:50    +
+ 		+ + + + +
+ At the moment, if statements are implicitly allowed (there's no restriction saying that they cannot be used inside interleave statements).
+
+
+
+ + + + + + + + + + +
+ (0014725) +
+ Jacob Wieland - Spirent    +
+ 28-06-2017 10:20    +
(edited on: 28-06-2017 10:22)
+ 		+ + + + +
+ ah, yes, true, they don't even break the to-alt-mapping if they contain reception statements
+
+
+
+
+
+ + + + + + + + + + +
+ (0014746) +
+ Jens Grabowski    +
+ 25-07-2017 08:48    +
+ 		+ + + + +
+ The term "unconditional goto" is not used, the term "unconditional jump" only describes what a goto is. However, the term "unconditional" is only used in this section and we can savely remove it. See attached resolution.
+
+
+
+ + + + + + + + + + +
+ (0014748) +
+ Jens Grabowski    +
+ 25-07-2017 08:52    +
+ 		+ + + + +
+ If, ok, please assignt to György as resolved.
+
+
+
+ + + + + + + + + + +
+ (0014751) +
+ Tomas Urban    +
+ 25-07-2017 13:05    +
+ 		+ + + + +
+ The proposed resolution fixes the issue.
+
+
+
+ + + + + + + + + + +
+ (0014968) +
+ Gyorgy Rethy    +
+ 30-12-2017 19:51    +
+ 		+ + + + +
+ Added to draft V4.9.2
+
+ + diff --git a/docs/mantis/CR7692.md b/docs/mantis/CR7692.md new file mode 100644 index 0000000000000000000000000000000000000000..3d386ece2bde090799436f1ace6387c9ce08e037 --- /dev/null +++ b/docs/mantis/CR7692.md @@ -0,0 +1,482 @@ + + + + + + + + + + + + + 0007692: Exception handling with less code and less performance overhead - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Object-oriented features (ES 203 790)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007692Ext Pack: Object-oriented features (ES 203 790)[All Projects] Generalpublic09-07-2017 12:1818-04-2018 09:51
ReporterKristóf Szabados 
Assigned ToKristóf Szabados 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0007692: Exception handling with less code and less performance overhead
DescriptionThere are many kinds of testing scenarios, where a few issues are to be expected because of the purpose of the test.
+For example when we need to check what happens if the SUT is driven to very high loads for several hours/days, or when the upper limit of stable parallel connections/bandwith is tested.
+In these cases the SUT not being able to handle a few messages in a large timeframe can be expected and should not stop the test from execution.
+
+In TTCN-3 it is already possible to use exception handling to write the needed safe code.
+The code parts in question need to be executed on parallel components, and exception handling done via ports.
+But this has a high overhead in performance and in code size.
+It would be better if the try-catch style mechanism of other languages would be available.
+TTCN-3 already has the raise and catch keywords, that could be used.
+
+
+Lets see a trivial example to demonstrate the idea: We wish to divide 2 numbers safely.
+
+Right now one can do this by:
+- Defining a signature for the function that will do the safe division.
+    signature MySafeDivision(in integer Par1,in integer Par2)
+    return integer
+    exception(charstring);
+
+- defining some templates:
+  template MySafeDivision MySafeDivisionTemplate1 := {
+    Par1 := ?,
+    Par2 := 0
+  }
+  template MySafeDivision MySafeDivisionTemplate2 := {
+    Par1 := ?,
+    Par2 := ?
+  }
+
+- the function that will do the safe division:
+  function getSafeDivisionCall() runs on MyComponent {
+    while (true) {
+      alt {
+        [] Port0.getCall(MySafeDivisionTemplate1) {
+           Port0.raise(MySafeDivision, "Error: division by zero");
+        }
+        [] Port0.getCall(MySafeDivisionTemplate2) { ... }
+        ...
+      }
+    }
+  }
+
+- At the location where we wish to do the safe division:
+  myComponentVar := MyComponent.create;
+  myComponentVar.start(getSafeDivisionCall());
+  connect(self:Port0, myComponentVar:Port1);
+  Port0.call(/*actual template to be used*/);
+  alt{
+    [] Port0.catch(MySafeDivision, charstring:"Error: division by zero") {
+      // some sort of error handling
+    }
+    [] Port0.getReplay(...) {
+      // handling for the good case
+    }
+    [] Port0.catch(timeout) {
+      // handle running out of time
+    }
+  }
+
+---
+
+The above example solves the task at hand and as a pattern it could be used for more complex situations.
+But it involves lots of code and communication between parallel components.
+
+If TTCN-3 would support exception handling the same could be solved like this:
+- the safe division function:
+  function MySafeDivision(in integer Par1,in integer Par2) return integer exception(charstring) {
+    if (Par2 == 0) {
+      raise(charstring:"Error: division by zero");
+    }
+    return Par1 / Par2;
+  }
+
+- At the location where we wish to do the safe division:
+  ...
+  try {
+    result := MySafeDivision(x, y);
+  } catch (charstring v_exception) {
+    log("There was an exception:", v_exception, ", but execution can continue safely");
+  }
+  ...
+
+This solution has the same safety and granularity.
+Using much less code ... that also makes it much easier to see what is happening in the code.
+Using much less resources ... there is no need for a parallel component and remote procedure calls, etc...
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0007731closed Jens Grabowski Draft document for Object-oriented Extension 
related to 0007561closed Kristóf Szabados Allow finally block or shutdown hook 
Attached Filesdocx CR7692.docx (279,126) 28-07-2017 14:11
http://oldforge.etsi.org/mantis/file_download.php?file_id=3672&type=bug
docx CR7692_v2.docx (281,583) 05-09-2017 11:38
http://oldforge.etsi.org/mantis/file_download.php?file_id=3677&type=bug
docx CR7692_v3.docx (288,770) 08-09-2017 09:48
http://oldforge.etsi.org/mantis/file_download.php?file_id=3684&type=bug
docx MTS-203790-00F_ed111v001_with_exceptions_v2.docx (180,702) 26-10-2017 08:48
http://oldforge.etsi.org/mantis/file_download.php?file_id=3704&type=bug
docx MTS-203790-00F_ed111v001_with_exceptions_v4.docx (182,754) 31-03-2018 09:11
http://oldforge.etsi.org/mantis/file_download.php?file_id=3735&type=bug
Issue History
Date ModifiedUsernameFieldChange
09-07-2017 12:18Kristóf SzabadosNew Issue
10-07-2017 09:57Jacob Wieland - SpirentNote Added: 0014729
24-07-2017 14:15Jens GrabowskiAssigned To => Jacob Wieland - Spirent
24-07-2017 14:15Jens GrabowskiStatusnew => assigned
24-07-2017 14:15Jens GrabowskiNote Added: 0014737
28-07-2017 12:29Jens GrabowskiRelationship addedrelated to 0007561
28-07-2017 12:41Jens GrabowskiProjectTTCN-3 Change Requests => Ext Pack: Object-oriented features (ES 203 790)
28-07-2017 12:41Jens GrabowskiCategoryNew Feature => General
28-07-2017 14:11Kristóf SzabadosFile Added: CR7692.docx
28-07-2017 14:13Kristóf SzabadosNote Added: 0014796
05-09-2017 11:38Kristóf SzabadosFile Added: CR7692_v2.docx
05-09-2017 11:38Kristóf SzabadosNote Added: 0014814
08-09-2017 07:45Jens GrabowskiAssigned ToJacob Wieland - Spirent => Kristóf Szabados
08-09-2017 09:48Kristóf SzabadosFile Added: CR7692_v3.docx
08-09-2017 09:58Kristóf SzabadosNote Added: 0014824
26-10-2017 08:48Kristóf SzabadosFile Added: MTS-203790-00F_ed111v001_with_exceptions_v2.docx
26-10-2017 08:48Kristóf SzabadosNote Added: 0014878
26-10-2017 14:41Kristóf SzabadosNote Added: 0014896
26-10-2017 14:41Kristóf SzabadosAssigned ToKristóf Szabados => Jens Grabowski
26-10-2017 14:41Kristóf SzabadosStatusassigned => confirmed
31-03-2018 09:11Kristóf SzabadosFile Added: MTS-203790-00F_ed111v001_with_exceptions_v4.docx
31-03-2018 09:12Kristóf SzabadosNote Added: 0015073
16-04-2018 09:44Jens GrabowskiAssigned ToJens Grabowski => Kristof.Szabados
16-04-2018 09:44Jens GrabowskiStatusconfirmed => assigned
17-04-2018 09:04Kristóf SzabadosAssigned ToKristof.Szabados => Kristóf Szabados
17-04-2018 09:05Kristóf SzabadosNote Added: 0015088
17-04-2018 14:06Tomas UrbanFile Added: CR7731-TRI-TCI-1.docx
17-04-2018 14:06Tomas UrbanFile Deleted: CR7731-TRI-TCI-1.docx
18-04-2018 08:34Kristóf SzabadosRelationship addedrelated to 0007731
18-04-2018 09:51Kristóf SzabadosNote Added: 0015096
18-04-2018 09:51Kristóf SzabadosStatusassigned => closed
18-04-2018 09:51Kristóf SzabadosResolutionopen => fixed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014729) +
+ Jacob Wieland - Spirent    +
+ 10-07-2017 09:57    +
+ 		+ + + + +
+ Unfortunately, this isn't really true about the granularity.
+
+If an exception occurs on one component, only that component state can be affected, i.e. only that component's data can be in a possibly inconsistent state.
+
+The call/getreply/catch pattern is much safer in that regard, as it can not lead to the caller getting into an inconsistent state because the control flow is in their hands (and not in the hands of the called function).
+
+Just some things that need to be considered/addressed.
+
+
+
+ + + + + + + + + + +
+ (0014737) +
+ Jens Grabowski    +
+ 24-07-2017 14:15    +
+ 		+ + + + +
+ To be discussed in the STF.
+
+
+
+ + + + + + + + + + +
+ (0014796) +
+ Kristóf Szabados    +
+ 28-07-2017 14:13    +
+ 		+ + + + +
+ I have uploaded a first draft of the proposal.
+
+Please Note 0: still work in progress.
+
+Please Note 1: for the time being I had to start from the core standard, but the final version will be part of the Object Oriented extension ... modification will be needed
+
+Please Note 2: for the time being I had to start from the concepts of the core standard. These should be updated/harmonized with the concepts of the Object Oriented extension once they are available.
+
+
+
+ + + + + + + + + + +
+ (0014814) +
+ Kristóf Szabados    +
+ 05-09-2017 11:38    +
+ 		+ + + + +
+ some editorial fixes and added the changes to external functions
+
+
+
+ + + + + + + + + + +
+ (0014824) +
+ Kristóf Szabados    +
+ 08-09-2017 09:58    +
+ 		+ + + + +
+ After feedback from Jacob there were some fixes:
+- a ',' is needed between the types in the exception list
+- "[{" is not useful in the syntactical structure examples
+- the exception list must have at least one element
+- the exception list might not be exhaustive, for backward compatibility.
+  (but is recommended to be updated to precisely communicate to callers (user/tool) what exceptions to prepare for, or even to expect the possibility of exceptions)
+- Statementblock -> statement block
+- there is no need for '('')' after the raise keyword.
+- some re-phrasing to make the sentences easier to read.
+- added note to draw attention to exceptions are caught precisely by their type, so even for literals it is advised to write them down.
+- added note saying that an exception not handled latest in the testcase results in a dynamic error ... where the error is not the throwing of the exception, but not handling it.
+- it became disallowed to raise an exception or use return statement in a finally block (for now), as that might result in un-intuitive behaviour.
+- raising exceptions are not allowed in certain places (together with other execution altering operations) where they could alter snapshot semantics.
+
+We received one more feedback that the "finally" keyword might not be the best choice as the Object-oriented extension might use it in a slightly different meaning.
+
+
+
+ + + + + + + + + + +
+ (0014878) +
+ Kristóf Szabados    +
+ 26-10-2017 08:48    +
+ 		+ + + + +
+ uploaded the same content in the new extension package format (work in progress)
+
+
+
+ + + + + + + + + + +
+ (0014896) +
+ Kristóf Szabados    +
+ 26-10-2017 14:41    +
+ 		+ + + + +
+ Could you please check the latest version (MTS-203790-00F_ed111v001_with_exceptions_v2.docx).
+
+I tried to use the list of extensions style present in the advanced parameterization ... should I restructure the text?
+
+
+
+ + + + + + + + + + +
+ (0015073) +
+ Kristóf Szabados    +
+ 31-03-2018 09:12    +
+ 		+ + + + +
+ improved the text (fixed typos, phrases, some numbering, etc..)
+
+
+
+ + + + + + + + + + +
+ (0015088) +
+ Kristóf Szabados    +
+ 17-04-2018 09:05    +
+ 		+ + + + +
+ Updated CR 7731 based on these changes (MTS-203790-00F_ed111v002.docx)
+
+
+
+ + + + + + + + + + +
+ (0015096) +
+ Kristóf Szabados    +
+ 18-04-2018 09:51    +
+ 		+ + + + +
+ Solved as part of the OO extension (CR 7731)
+
+ + diff --git a/docs/mantis/CR7693.md b/docs/mantis/CR7693.md new file mode 100644 index 0000000000000000000000000000000000000000..b526821972fdc2e70284268775e3080943024551 --- /dev/null +++ b/docs/mantis/CR7693.md @@ -0,0 +1,283 @@ + + + + + + + + + + + + + 0007693: component members with visibility and functions inside the components - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Object-oriented features (ES 203 790)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007693Ext Pack: Object-oriented features (ES 203 790)[All Projects] Generalpublic16-07-2017 13:1011-10-2018 14:21
ReporterKristóf Szabados 
Assigned ToKristóf Szabados 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionwon't fix 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0007693: component members with visibility and functions inside the components
DescriptionWhen defining libraries, it is often the case that some data shall not be manipulated by the users of the library directly; e.g. the internal database of a test framework, storing entity states, simulated entity-related data, temporary data like session ids etc. These are typically defined as component variables.
+
+One reason is that the type and structure of framework-internal data may (in fact WILL) change over time, as the framework is developed further. But if the user access framework-internal data directly, these changes causes the user code be broken.
+An other reason might be, that the library uses some special representation, that users could corrupt, if they can access (for example a charstring storing encrypted information, or a record of integer representing a tree data structure).
+
+The solution of the problem is to introduce visibily within components for component definitions as well, and functions written inside the components to manipulate such members:
+In component member definitions they mean the following:
+• The public modifier means that any function/testcase/altstep running on that component instance can access the member definition directly.
+• The private modifier means that only those functions can access the definition which are directly written "into the body" of the component. Functions running on a component type extending the one containing the definition, will not be able to see them.
+• functions written into the "body" of the component can also be public or private. Public functions can be called from functions/altstep/testcases running on the component, or on a component extending their component. Private functions can only be called from functions written inside the "body" of the same component.
+• the frend modifier is not available inside components.
+
+This feature can also be seen as a Object-Oriented extension of current components.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0006801closed Kristóf Szabados Visibility of component definitions 
related to 0007679closed Jens Grabowski Class Concept to be added 
Attached Filesdocx CR7693.docx (318,212) 28-07-2017 13:18
http://oldforge.etsi.org/mantis/file_download.php?file_id=3671&type=bug
Issue History
Date ModifiedUsernameFieldChange
16-07-2017 13:10Kristóf SzabadosNew Issue
16-07-2017 13:10Kristóf SzabadosRelationship addedrelated to 0006801
24-07-2017 14:12Jens GrabowskiAssigned To => Kristóf Szabados
24-07-2017 14:12Jens GrabowskiStatusnew => assigned
28-07-2017 12:36Jens GrabowskiProjectTTCN-3 Change Requests => Ext Pack: Object-oriented features (ES 203 790)
28-07-2017 12:36Jens GrabowskiCategoryNew Feature => General
28-07-2017 13:18Kristóf SzabadosFile Added: CR7693.docx
28-07-2017 13:22Kristóf SzabadosNote Added: 0014795
27-10-2017 11:19Kristóf SzabadosRelationship addedrelated to 0007679
27-10-2017 11:20Kristóf SzabadosNote Added: 0014909
16-04-2018 11:57Jens GrabowskiNote Added: 0015081
16-04-2018 11:57Jens GrabowskiStatusassigned => closed
16-04-2018 11:57Jens GrabowskiResolutionopen => fixed
17-04-2018 08:29Kristóf SzabadosNote Added: 0015086
17-04-2018 08:29Kristóf SzabadosStatusclosed => feedback
17-04-2018 08:29Kristóf SzabadosResolutionfixed => reopened
17-04-2018 08:30Kristóf SzabadosAssigned ToKristóf Szabados => Jacob Wieland - Spirent
17-04-2018 08:30Kristóf SzabadosStatusfeedback => assigned
17-04-2018 08:30Kristóf SzabadosNote Added: 0015087
18-04-2018 08:02Kristóf SzabadosAssigned ToJacob Wieland - Spirent => Kristóf Szabados
18-04-2018 09:53Kristóf SzabadosNote Added: 0015098
11-10-2018 14:21Kristóf SzabadosNote Added: 0015256
11-10-2018 14:21Kristóf SzabadosStatusassigned => closed
11-10-2018 14:21Kristóf SzabadosResolutionreopened => won't fix
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014795) +
+ Kristóf Szabados    +
+ 28-07-2017 13:22    +
+ 		+ + + + +
+ I have uploaded the first version of the proposal.
+
+Please Note 1: for the time being I had to start from the core standard, but the final version will be part of the Object Oriented extension ... modification will be needed
+
+Please Note 2: for the time being I had to start from the concepts of the core standard. These should be updated/harmonized with the concepts of the Object Oriented extension once they are available.
+
+
+
+ + + + + + + + + + +
+ (0014909) +
+ Kristóf Szabados    +
+ 27-10-2017 11:20    +
+ 		+ + + + +
+ This cr will be solved as part of the Object-Oriented Extension (CR7679)
+
+
+
+ + + + + + + + + + +
+ (0015081) +
+ Jens Grabowski    +
+ 16-04-2018 11:57    +
+ 		+ + + + +
+ solved as part of the OO extension
+
+
+
+ + + + + + + + + + +
+ (0015086) +
+ Kristóf Szabados    +
+ 17-04-2018 08:29    +
+ 		+ + + + +
+ Reopened for discussion, as this might not make into the current Object-Oriented extension.
+
+
+
+ + + + + + + + + + +
+ (0015087) +
+ Kristóf Szabados    +
+ 17-04-2018 08:30    +
+ 		+ + + + +
+ Jacob please check.
+
+
+
+ + + + + + + + + + +
+ (0015098) +
+ Kristóf Szabados    +
+ 18-04-2018 09:53    +
+ 		+ + + + +
+ I would like to keep this CR open for the next STF session to get feedback from our users.
+
+
+
+ + + + + + + + + + +
+ (0015256) +
+ Kristóf Szabados    +
+ 11-10-2018 14:21    +
+ 		+ + + + +
+ Fixed with OO.
+
+ + diff --git a/docs/mantis/CR7694.md b/docs/mantis/CR7694.md new file mode 100644 index 0000000000000000000000000000000000000000..432df675e7df8d83053342efeeff77340fb0bc54 --- /dev/null +++ b/docs/mantis/CR7694.md @@ -0,0 +1,424 @@ + + + + + + + + + + + + + 0007694: dynamic encoding (usage of statement port.setencode(type,"EncodingRule1"); - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007694Part 06: TTCN-3 Control InterfaceTechnicalpublic24-07-2017 10:1602-01-2018 12:34
ReporterMartin Hauch 
Assigned ToTomas Urban 
PriorityhighSeveritymajorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Clause Reference(s)Encode/Decode handling TCI-interface 7.3.2.2.1 ff
Source (company - Author)Devoteam, Martin Hauch
Summary0007694: dynamic encoding (usage of statement port.setencode(type,"EncodingRule1");
DescriptionWith introduction of multiple encoding rules and the setencode-statement the following problem for tci-Codec interface has to be solved:
+
+The information about the encoding-rule, which should be used is not available for the tci-interface (Chapter 7.3.2.2.2 in document ETSI ES 201 873-6 V4.9.1 (2017-05))! The interface description encode(in Value value) does not provide any information about the encoding set for the type of this value on the port.
+The same problem is present for decode (Chapter 7.3.2.2.1)!
+In a similar way this also concerns the TTCN-3 predefined functions encvalue, encvalue_unichar, decvalue, decvalue_unichar and the tci-codec interface functions encodeValue and decodeValue ( Chapter 7.3.2.2.3f).
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7694-v1.docx (204,639) 25-07-2017 16:34
http://oldforge.etsi.org/mantis/file_download.php?file_id=3655&type=bug
docx CR7694-v2.docx (205,136) 26-07-2017 08:50
http://oldforge.etsi.org/mantis/file_download.php?file_id=3658&type=bug
Issue History
Date ModifiedUsernameFieldChange
24-07-2017 10:16Martin HauchNew Issue
24-07-2017 14:08Jens GrabowskiAssigned To => Tomas Urban
24-07-2017 14:08Jens GrabowskiStatusnew => assigned
24-07-2017 14:11Jens GrabowskiNote Added: 0014736
24-07-2017 16:50Tomas UrbanNote Added: 0014744
25-07-2017 07:32Martin HauchNote Added: 0014745
25-07-2017 15:46Tomas UrbanNote Added: 0014756
25-07-2017 16:34Tomas UrbanFile Added: CR7694-v1.docx
25-07-2017 16:35Tomas UrbanNote Added: 0014761
25-07-2017 16:35Tomas UrbanAssigned ToTomas Urban => Jacob Wieland - Spirent
25-07-2017 16:35Tomas UrbanStatusassigned => confirmed
26-07-2017 08:48Jacob Wieland - SpirentNote Added: 0014766
26-07-2017 08:49Jacob Wieland - SpirentNote Added: 0014767
26-07-2017 08:49Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Tomas Urban
26-07-2017 08:49Jacob Wieland - SpirentStatusconfirmed => assigned
26-07-2017 08:50Tomas UrbanFile Added: CR7694-v2.docx
26-07-2017 08:51Tomas UrbanNote Added: 0014768
26-07-2017 08:51Tomas UrbanAssigned ToTomas Urban => Jacob Wieland - Spirent
26-07-2017 08:51Tomas UrbanStatusassigned => confirmed
26-07-2017 09:23Jacob Wieland - SpirentNote Added: 0014774
26-07-2017 09:23Jacob Wieland - SpirentStatusconfirmed => resolved
26-07-2017 09:23Jacob Wieland - SpirentResolutionopen => fixed
26-07-2017 09:23Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Tomas Urban
26-07-2017 09:24Jacob Wieland - SpirentProjectTTCN-3 Change Requests => Part 06: TTCN-3 Control Interface
02-01-2018 12:34Tomas UrbanNote Added: 0014982
02-01-2018 12:34Tomas UrbanStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014736) +
+ Jens Grabowski    +
+ 24-07-2017 14:11    +
+ 		+ + + + +
+ To be checked how the different tools (Jacob, Kristof) interpret this feature.
+
+
+
+ + + + + + + + + + +
+ (0014744) +
+ Tomas Urban    +
+ 24-07-2017 16:50    +
+ 		+ + + + +
+ Dear Martin,
+
+It is correct that the encode and decode operations do not contain information on the selected encoding (and related variants) in a dedicated parameter. However, this information is available in the value (encode) or decodingHypothesis parameters (decode). When generating the TCI Type and Value instances, the TE shall take into account all previous setencode calls and the context from which the codec operation is called and pass such a Value or Type instance to the TCI that contains only the selected encoding and related variants.
+
+Example:
+
+type charstring MyString with { encode "binary" encode "text" }
+....
+p.setencode(MyString, "binary");
+p.receive(MyString:?);
+// at this point, TCI decode is called
+// if the user calls decodingHypothesis.getTypeEncoding, the returned value will be "binary"
+p.setencode(MyString, "text");
+p.receive(MyString:?);
+// at this point, TCI decode is called again
+// however, if the user calls decodingHypothesis.getTypeEncoding, the returned value will be "text" this time
+enc_value(MyString:"abc");
+// inside the TCI encode operation, the value.getValueEncoding call will return "binary<CR><LF>text"
+// because the dynamic_encoding parameter is not used and no self.setencode call has been made so far
+
+Could you please say if the provided explanation is satisfactory? If there are any questions, please feel free to ask.
+
+
+
+ + + + + + + + + + +
+ (0014745) +
+ Martin Hauch    +
+ 25-07-2017 07:32    +
+ 		+ + + + +
+ Dear Thomas,
+I do not agree to this. It is possible that for the same type various encoding-types are active in parallel.
+p1.setencode(MyString,"binary");
+p2.setencode(MyString,"text");
+p3.setencode(MyString,"something else");
+As far as I understand the TCI-interface the method getTypeEncoding() returns type encoding as defined in the TTCN-3 module, means encode-attributes, that belong to the type e.g.:
+with { encode "binary"; encode "text"} getTypeEncoding should return always "binary<CR><LF>text" as it is the information, that belongs to the type and this information is independent from dynamic setencode-statements!
+
+Also if the interleave-statement is used or there are parallel test-components using the same types, the same type may be used in parallel with different encoding-rules. In my opinion an extra parameter representing the dynamic setencode-settings is necessary. The dynamic setencode information belongs to the port or component, not to the type. So you could define an interface function like
+String getDyanmicEncodingDescription(EncodingSettings setEncodeSettings,Type type)
+
+Another point should be clarified:
+
+p1.setencode(MyString,"binary");
+self.setencode(MyString,"text");
+/* which encoding is to be used for p1.send(Mystring:"...");
+   does self.setencode() overwrite port.setencode()?
+   does self.setencode() only overwrite type encoding from p1.setencode or
+   are all type encodings of p1.setencode() calls deleted and only the
+   encodings of self.setencode() are valid? */
+
+
+
+ + + + + + + + + + +
+ (0014756) +
+ Tomas Urban    +
+ 25-07-2017 15:46    +
+ 		+ + + + +
+ The intended way of using multiple encodings is as I described above, i.e. the TCI Type instance doesn't have to be related to the TTCN-3 type definition in the source code. Instead, the TE might create an anonymous TCI Type instance with different attributes according to the context from which the TCI call is made. We will rephrase the TCI description to explain this in detail.
+
+This principle is already used in several places of TTCN-3, e.g. when a type is imported to two different modules with different attributes or when a receive statement uses templates of the same type but with different attributes.
+
+The solution you propose has several drawbacks:
+1. Adding the additional parameter(s) to the existing methods is not possible because of backwards compatibility.
+2. Eventual new methods for types with multiple encodings:
+   a. Make the creation of the codec more complicated
+   b. Require update of existing codec so that they can be compiled with the new TCI
+   c. Should contain several (more or less) mandatory calls to get the actual encoding
+3. There will still be situation when more encodings are possible for the same type (e.g. the case with two templates).
+
+As regards the p1.setencode call followed by self.setencode, it will indeed override the encoding setting for p1, because the self.setencode call is valid for all communication operations of the current component (including the ones made from p1).
+
+
+
+ + + + + + + + + + +
+ (0014761) +
+ Tomas Urban    +
+ 25-07-2017 16:35    +
+ 		+ + + + +
+ Please check the update of the TCI standard.
+
+
+
+ + + + + + + + + + +
+ (0014766) +
+ Jacob Wieland - Spirent    +
+ 26-07-2017 08:48    +
+ 		+ + + + +
+ other than the one missing 'variant' word before 'encoding attribute' for getTypeEncodingVariant, it's fine
+
+
+
+ + + + + + + + + + +
+ (0014767) +
+ Jacob Wieland - Spirent    +
+ 26-07-2017 08:49    +
+ 		+ + + + +
+ please add the missing word
+
+
+
+ + + + + + + + + + +
+ (0014768) +
+ Tomas Urban    +
+ 26-07-2017 08:51    +
+ 		+ + + + +
+ Missing word added. Please check.
+
+
+
+ + + + + + + + + + +
+ (0014774) +
+ Jacob Wieland - Spirent    +
+ 26-07-2017 09:23    +
+ 		+ + + + +
+ fine with me
+
+
+
+ + + + + + + + + + +
+ (0014982) +
+ Tomas Urban    +
+ 02-01-2018 12:34    +
+ 		+ + + + +
+ Implemented in draft V4.9.2
+
+ + diff --git a/docs/mantis/CR7703.md b/docs/mantis/CR7703.md new file mode 100644 index 0000000000000000000000000000000000000000..b565f86a745ba894d711a591ad544567599e1a68 --- /dev/null +++ b/docs/mantis/CR7703.md @@ -0,0 +1,408 @@ + + + + + + + + + + + + + 0007703: the xml schema for the log events is inconsistent with the rest of the specification - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007703Part 06: TTCN-3 Control InterfaceEditorialpublic05-09-2017 08:0102-01-2018 13:03
ReporterJacob Wieland - Spirent 
Assigned ToTomas Urban 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.8.1 (published 2016-07) 
Target Versionv4.9.1(ongoing)Fixed in Versionv4.9.1(ongoing) 
Clause Reference(s)11.4.1, B.5
Source (company - Author)Spirent - Jacob Wieland
Summary0007703: the xml schema for the log events is inconsistent with the rest of the specification
DescriptionThe newer 'Checked' versions of the Receive/GetCall/GetReply/Catch have wrong fields, using tri instead of values and having a wrong port field.
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
05-09-2017 08:01Jacob Wieland - SpirentNew Issue
05-09-2017 08:01Jacob Wieland - SpirentStatusnew => assigned
05-09-2017 08:01Jacob Wieland - SpirentAssigned To => Jacob Wieland - Spirent
24-10-2017 12:47Jens GrabowskiNote Added: 0014844
25-10-2017 09:38Jacob Wieland - SpirentNote Added: 0014862
25-10-2017 09:58Jacob Wieland - SpirentNote Edited: 0014862bug_revision_view_page.php?bugnote_id=14862#r442
26-10-2017 13:52Jacob Wieland - SpirentNote Added: 0014894
26-10-2017 13:52Jacob Wieland - SpirentStatusassigned => resolved
26-10-2017 13:52Jacob Wieland - SpirentFixed in Version => v4.9.1(ongoing)
26-10-2017 13:52Jacob Wieland - SpirentResolutionopen => fixed
26-10-2017 13:52Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Tomas Urban
02-01-2018 13:03Tomas UrbanNote Added: 0014984
02-01-2018 13:03Tomas UrbanStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014844) +
+ Jens Grabowski    +
+ 24-10-2017 12:47    +
+ 		+ + + + +
+ (To be implemented until end of 2017)
+
+
+
+ + + + + + + + + + +
+ (0014862) +
+ Jacob Wieland - Spirent    +
+ 25-10-2017 09:38    +
(edited on: 25-10-2017 09:58)
+ 		+ + + + +
+ In Types.xsd:
+
+complex Type TciValueList must be renamed TciValueListType as that is referenced with the last name in the Events.xsd schema.
+
+In Events.xsd
+
+in tliMDetected_m, msg -> msgValue
+
+in tliPrGetCallMismatch_c, fromTmpl needs to have type TciNonValueTemplate
+
+
+Also the -Checked events need to be more consistent with the -Receive events :
+
+        <xsd:complexType name="tliMChecked_m">
+        <xsd:complexContent mixed="true">
+            <xsd:extension base="Events:Event">
+                <xsd:sequence>
+                    <xsd:element name="at" type="Types:TriPortIdType" />
+                    <xsd:element name="msgValue" type="Values:Value" />
+                    <xsd:element name="msgTmpl" type="Templates:TciValueTemplate"
+                        minOccurs="0" />
+                    <xsd:element name="addrValue" type="Values:Value"
+                        minOccurs="0" />
+                    <xsd:element name="addressTmpl" type="Templates:TciValueTemplate"
+                        minOccurs="0" />
+                </xsd:sequence>
+            </xsd:extension>
+        </xsd:complexContent>
+    </xsd:complexType>
+
+    <xsd:complexType name="tliMChecked_c">
+        <xsd:complexContent mixed="true">
+            <xsd:extension base="Events:Event">
+                <xsd:sequence>
+                    <xsd:element name="at" type="Types:TriPortIdType" />
+                    <xsd:element name="msgValue" type="Values:Value" />
+                    <xsd:element name="msgTmpl" type="Templates:TciValueTemplate"
+            minOccurs="0" />
+          <xsd:element name="from" type="Types:TriComponentIdType"
+            minOccurs="0" />
+          <xsd:element name="fromTmpl" type="Templates:TciNonValueTemplate"
+            minOccurs="0" />
+                </xsd:sequence>
+            </xsd:extension>
+        </xsd:complexContent>
+    </xsd:complexType>
+
+    <xsd:complexType name="tliPrGetCallChecked_m">
+        <xsd:complexContent mixed="true">
+            <xsd:extension base="Events:Event">
+                <xsd:sequence>
+                    <xsd:element name="at" type="Types:TriPortIdType" />
+                    <xsd:element name="signature" type="Types:TriSignatureIdType" />
+                    <xsd:element name="tciPars" type="Types:TciParameterListType"
+            minOccurs="0" />
+          <xsd:element name="parsTmpl" type="Templates:TciValueTemplate"
+            minOccurs="0" />
+          <xsd:element name="addrValue" type="Values:Value"
+            minOccurs="0" />
+          <xsd:element name="addressTmpl" type="Templates:TciValueTemplate"
+            minOccurs="0" />
+                </xsd:sequence>
+            </xsd:extension>
+        </xsd:complexContent>
+    </xsd:complexType>
+
+    <xsd:complexType name="tliPrGetCallChecked_c">
+        <xsd:complexContent mixed="true">
+            <xsd:extension base="Events:Event">
+                <xsd:sequence>
+                    <xsd:element name="at" type="Types:TriPortIdType" />
+                    <xsd:element name="signature" type="Types:TriSignatureIdType" />
+                    <xsd:element name="tciPars" type="Types:TciParameterListType"
+                        minOccurs="0" />
+                    <xsd:element name="parsTmpl" type="Templates:TciValueTemplate"
+            minOccurs="0" />
+                    <xsd:element name="from" type="Types:TriComponentIdType"
+            minOccurs="0" />
+          <xsd:element name="fromTmpl" type="Templates:TciNonValueTemplate"
+            minOccurs="0" />
+                </xsd:sequence>
+            </xsd:extension>
+        </xsd:complexContent>
+    </xsd:complexType>
+    <xsd:complexType name="tliPrGetReplyChecked_m">
+        <xsd:complexContent mixed="true">
+            <xsd:extension base="Events:Event">
+                <xsd:sequence>
+                    <xsd:element name="at" type="Types:TriPortIdType" />
+                    <xsd:element name="signature" type="Types:TriSignatureIdType" />
+                    <xsd:element name="tciPars" type="Types:TciParameterListType"
+            minOccurs="0" />
+          <xsd:element name="parsTmpl" type="Templates:TciValueTemplate"
+            minOccurs="0" />
+                    <xsd:element name="replValue" type="Values:Value"
+                        minOccurs="0" />
+                    <xsd:element name="replTmpl" type="Templates:TciValueTemplate"
+            minOccurs="0" />
+                    <xsd:element name="addrValue" type="Values:Value"
+            minOccurs="0" />
+          <xsd:element name="addressTmpl" type="Templates:TciValueTemplate"
+            minOccurs="0" />
+                </xsd:sequence>
+            </xsd:extension>
+        </xsd:complexContent>
+    </xsd:complexType>
+
+    <xsd:complexType name="tliPrGetReplyChecked_c">
+        <xsd:complexContent mixed="true">
+            <xsd:extension base="Events:Event">
+                <xsd:sequence>
+                    <xsd:element name="at" type="Types:TriPortIdType" />
+        <xsd:element name="signature" type="Types:TriSignatureIdType" />
+        <xsd:element name="tciPars" type="Types:TciParameterListType"
+            minOccurs="0" />
+        <xsd:element name="parsTmpl" type="Templates:TciValueTemplate"
+            minOccurs="0" />
+        <xsd:element name="replValue" type="Values:Value"
+            minOccurs="0" />
+        <xsd:element name="replTmpl" type="Templates:TciValueTemplate"
+            minOccurs="0" />
+        <xsd:element name="from" type="Types:TriComponentIdType"
+            minOccurs="0" />
+        <xsd:element name="fromTmpl" type="Templates:TciNonValueTemplate"
+            minOccurs="0" />
+                </xsd:sequence>
+            </xsd:extension>
+        </xsd:complexContent>
+    </xsd:complexType>
+
+    <xsd:complexType name="tliPrCatchChecked_m">
+        <xsd:complexContent mixed="true">
+            <xsd:extension base="Events:Event">
+                <xsd:sequence>
+                    <xsd:element name="at" type="Types:TriPortIdType" />
+                    <xsd:element name="signature" type="Types:TriSignatureIdType" />
+                    <xsd:element name="excValue" type="Values:Value" />
+          <xsd:element name="excTmpl" type="Templates:TciValueTemplate" />
+          <xsd:element name="addrValue" type="Values:Value"
+            minOccurs="0" />
+          <xsd:element name="addressTmpl" type="Templates:TciValueTemplate"
+            minOccurs="0" />
+                </xsd:sequence>
+            </xsd:extension>
+        </xsd:complexContent>
+    </xsd:complexType>
+
+    <xsd:complexType name="tliPrCatchChecked_c">
+        <xsd:complexContent mixed="true">
+            <xsd:extension base="Events:Event">
+                <xsd:sequence>
+                    <xsd:element name="at" type="Types:TriPortIdType" />
+                    <xsd:element name="signature" type="Types:TriSignatureIdType" />
+                    <xsd:element name="excValue" type="Values:Value"
+                        minOccurs="0" />
+                    <xsd:element name="excTmpl" type="Templates:TciValueTemplate" />
+                    <xsd:element name="from" type="Types:TriComponentIdType"
+            minOccurs="0" />
+          <xsd:element name="fromTmpl" type="Templates:TciNonValueTemplate"
+            minOccurs="0" />
+        </xsd:sequence>
+            </xsd:extension>
+        </xsd:complexContent>
+    </xsd:complexType>
+    
+    <xsd:complexType name="tliCheckedAny_m">
+        <xsd:complexContent mixed="true">
+            <xsd:extension base="Events:Event">
+                <xsd:sequence>
+                    <xsd:element name="at" type="Types:TriPortIdType" />
+                    <xsd:element name="addrValue" type="Values:Value"
+            minOccurs="0" />
+          <xsd:element name="addressTmpl" type="Templates:TciValueTemplate"
+            minOccurs="0" />
+                </xsd:sequence>
+            </xsd:extension>
+        </xsd:complexContent>
+    </xsd:complexType>
+
+    <xsd:complexType name="tliCheckedAny_c">
+        <xsd:complexContent mixed="true">
+            <xsd:extension base="Events:Event">
+                <xsd:sequence>
+                    <xsd:element name="at" type="Types:TriPortIdType" />
+                    <xsd:element name="from" type="Types:TriComponentIdType"
+            minOccurs="0" />
+          <xsd:element name="fromTmpl" type="Templates:TciNonValueTemplate"
+            minOccurs="0" />
+                </xsd:sequence>
+            </xsd:extension>
+        </xsd:complexContent>
+    </xsd:complexType>
+
+    <xsd:complexType name="tliCheckAnyMismatch_m">
+        <xsd:complexContent mixed="true">
+            <xsd:extension base="Events:Event">
+                <xsd:sequence>
+                    <xsd:element name="at" type="Types:TriPortIdType" />
+                    <xsd:element name="addrValue" type="Values:Value"
+                        minOccurs="0" />
+                    <xsd:element name="addressTmpl" type="Templates:TciValueTemplate"
+                        minOccurs="0" />
+                </xsd:sequence>
+            </xsd:extension>
+        </xsd:complexContent>
+    </xsd:complexType>
+
+    <xsd:complexType name="tliCheckAnyMismatch_c">
+        <xsd:complexContent mixed="true">
+            <xsd:extension base="Events:Event">
+                <xsd:sequence>
+                    <xsd:element name="at" type="Types:TriPortIdType" />
+                    <xsd:element name="from" type="Types:TriComponentIdType"
+                        minOccurs="0" />
+                    <xsd:element name="fromTmpl" type="Templates:TciNonValueTemplate"
+                        minOccurs="0" />
+                </xsd:sequence>
+            </xsd:extension>
+        </xsd:complexContent>
+    </xsd:complexType>
+    <xsd:complexType name="tliRnd">
+        <xsd:complexContent mixed="true">
+            <xsd:extension base="Events:Event">
+                <xsd:sequence>
+                    <xsd:element name="val" type="Values:FloatValue" />
+                    <xsd:element name="seed" type="Values:FloatValue" />
+                </xsd:sequence>
+            </xsd:extension>
+        </xsd:complexContent>
+    </xsd:complexType>
+    <xsd:complexType name="tliEvaluate">
+        <xsd:complexContent mixed="true">
+            <xsd:extension base="Events:Event">
+                <xsd:sequence>
+                    <xsd:element name="name" type="Types:QualifiedName" />
+                    <xsd:element name="evalResult" type="Values:Value"
+                        minOccurs="0" />
+                </xsd:sequence>
+            </xsd:extension>
+        </xsd:complexContent>
+    </xsd:complexType>
+
+
+
+
+
+ + + + + + + + + + +
+ (0014894) +
+ Jacob Wieland - Spirent    +
+ 26-10-2017 13:52    +
+ 		+ + + + +
+ after discussion with Tomas who has reviewed this already, I'll set this to resolved and he will use the text from the NOTEs as a basis for the changes in the text document
+
+
+
+ + + + + + + + + + +
+ (0014984) +
+ Tomas Urban    +
+ 02-01-2018 13:03    +
+ 		+ + + + +
+ Implemented in draft V4.9.2
+
+ + diff --git a/docs/mantis/CR7707.md b/docs/mantis/CR7707.md new file mode 100644 index 0000000000000000000000000000000000000000..b5517a3b5132c56ba7988d73778e76afb1ec1c22 --- /dev/null +++ b/docs/mantis/CR7707.md @@ -0,0 +1,277 @@ + + + + + + + + + + + + + 0007707: Port and timer variables and structured types containing ports and timers - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007707Part 01: TTCN-3 Core LanguageNew Featurepublic08-09-2017 10:4204-01-2018 16:12
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeveritymajorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.9.1 (published 2017-05) 
Target Versionv4.10.1 (published 2018-05)Fixed in Versionv4.10.1 (published 2018-05) 
Clause Reference(s)6.2, 10, 11
Source (company - Author)STF 533
Summary0007707: Port and timer variables and structured types containing ports and timers
DescriptionWith the introduction of object-oriented feature, it is necessary to allow port and timer variables and a possibility of using ports and timers in definitions of structured types. In addition to that, port variables are requested by CR 0007445.
+
+As a part of the harmonization work, the STF 533 decided to add these features directly to the core language standard, because they are not directly dependent on the object-oriented features and would be beneficial even for the users that don't use objects.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0007445closed Tomas Urban usage of encode/variant attributes should be enhanced 
Attached Filesdocx CR7707-v1.docx (403,748) 24-10-2017 16:29
http://oldforge.etsi.org/mantis/file_download.php?file_id=3687&type=bug
docx CR7707-v2.docx (501,878) 25-10-2017 09:56
http://oldforge.etsi.org/mantis/file_download.php?file_id=3693&type=bug
docx CR7707-v3.docx (411,452) 25-10-2017 13:56
http://oldforge.etsi.org/mantis/file_download.php?file_id=3699&type=bug
docx CR7707-v4.docx (549,044) 26-10-2017 15:16
http://oldforge.etsi.org/mantis/file_download.php?file_id=3717&type=bug
docx CR7707-v5.docx (445,755) 26-10-2017 16:08
http://oldforge.etsi.org/mantis/file_download.php?file_id=3719&type=bug
Issue History
Date ModifiedUsernameFieldChange
08-09-2017 10:42Tomas UrbanNew Issue
08-09-2017 10:42Tomas UrbanStatusnew => assigned
08-09-2017 10:42Tomas UrbanAssigned To => Tomas Urban
08-09-2017 10:43Tomas UrbanRelationship addedrelated to 0007445
08-09-2017 10:43Tomas UrbanProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
24-10-2017 12:34Jens GrabowskiNote Added: 0014842
24-10-2017 16:29Tomas UrbanFile Added: CR7707-v1.docx
24-10-2017 16:30Tomas UrbanNote Added: 0014856
24-10-2017 16:30Tomas UrbanAssigned ToTomas Urban => Jacob Wieland - Spirent
24-10-2017 16:30Tomas UrbanStatusassigned => confirmed
25-10-2017 09:56Tomas UrbanFile Added: CR7707-v2.docx
25-10-2017 09:56Tomas UrbanNote Added: 0014863
25-10-2017 13:56Jacob Wieland - SpirentFile Added: CR7707-v3.docx
25-10-2017 13:57Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Tomas Urban
25-10-2017 13:57Jacob Wieland - SpirentStatusconfirmed => assigned
26-10-2017 12:04Tomas UrbanFile Added: CR7714-v1.docx
26-10-2017 12:10Tomas UrbanNote Added: 0014889
26-10-2017 12:10Tomas UrbanAssigned ToTomas Urban => Jacob Wieland - Spirent
26-10-2017 14:48Jacob Wieland - SpirentStatusassigned => confirmed
26-10-2017 15:02Jacob Wieland - SpirentFile Deleted: CR7714-v1.docx
26-10-2017 15:16Tomas UrbanFile Added: CR7707-v4.docx
26-10-2017 16:08Jacob Wieland - SpirentFile Added: CR7707-v5.docx
26-10-2017 16:10Jacob Wieland - SpirentNote Added: 0014900
26-10-2017 16:11Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Jens Grabowski
02-01-2018 13:27Jens GrabowskiNote Added: 0014985
02-01-2018 13:27Jens GrabowskiStatusconfirmed => resolved
02-01-2018 13:27Jens GrabowskiResolutionopen => fixed
02-01-2018 13:27Jens GrabowskiAssigned ToJens Grabowski => Gyorgy Rethy
04-01-2018 16:12Gyorgy RethyNote Added: 0014993
04-01-2018 16:12Gyorgy RethyStatusresolved => closed
04-01-2018 16:12Gyorgy RethyProduct Version => v4.9.1 (published 2017-05)
04-01-2018 16:12Gyorgy RethyFixed in Version => v4.10.1 (published 2018-05)
04-01-2018 16:12Gyorgy RethyTarget Version => v4.10.1 (published 2018-05)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014842) +
+ Jens Grabowski    +
+ 24-10-2017 12:34    +
+ 		+ + + + +
+ (To be implemented until end of 2017)
+
+
+
+ + + + + + + + + + +
+ (0014856) +
+ Tomas Urban    +
+ 24-10-2017 16:30    +
+ 		+ + + + +
+ Resolution uploaded. Please check.
+
+
+
+ + + + + + + + + + +
+ (0014863) +
+ Tomas Urban    +
+ 25-10-2017 09:56    +
+ 		+ + + + +
+ The second version of the resolution uploaded. Please check.
+
+
+
+ + + + + + + + + + +
+ (0014889) +
+ Tomas Urban    +
+ 26-10-2017 12:10    +
+ 		+ + + + +
+ More changes:
+1. BNF changes to support object references in timer and port operations
+2. BNF naming update:
+   VariableRef -> ValueRef (not always referring to a variable, it might be a constant, parameter, timer instance etc.)
+   ComponentOrDefaultReference -> ObjectReference
+3. In syntactical rules present in the textual part, Expression was changed into ValueRef | FunctionInstance and the related restriction was updated accordingly (using a similar rule for component operations)
+4. Template-related restriction added to component operations
+
+Please check and if you are find with the resolution, assign it to Jens so that he can check it too
+
+
+
+ + + + + + + + + + +
+ (0014900) +
+ Jacob Wieland - Spirent    +
+ 26-10-2017 16:10    +
+ 		+ + + + +
+ In accordance with Tomas, I have replaced all ValueRef | FunctionInstance with ObjectReference and I have replaced all remaining ValueRef occurrences with simply Ref because they might also refer to other things than values (templates, constants, functions etc.)
+
+
+
+ + + + + + + + + + +
+ (0014985) +
+ Jens Grabowski    +
+ 02-01-2018 13:27    +
+ 		+ + + + +
+ Ok, I put in resolved and assign it to György.
+
+
+
+ + + + + + + + + + +
+ (0014993) +
+ Gyorgy Rethy    +
+ 04-01-2018 16:12    +
+ 		+ + + + +
+ Implemented in draft V4.9.3
+
+ + diff --git a/docs/mantis/CR7708.md b/docs/mantis/CR7708.md new file mode 100644 index 0000000000000000000000000000000000000000..11df0b6b42bbd60a8375a720f7d34bfcce45d5c5 --- /dev/null +++ b/docs/mantis/CR7708.md @@ -0,0 +1,267 @@ + + + + + + + + + + + + + 0007708: Using dot notation with @default union values - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007708Part 01: TTCN-3 Core LanguageClarificationpublic13-09-2017 10:2630-12-2017 14:35
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.9.1 (published 2017-05) 
Target VersionFixed in Versionv4.10.1 (published 2018-05) 
Clause Reference(s)6.2.5, 6.3.2.4
Source (company - Author)Elvior
Summary0007708: Using dot notation with @default union values
DescriptionThe last version of the core language specification introduced unions with default alternative which were required for resolving the problem with enabling XSD type or element substition in existing test suites.
+
+The current rules use special compatibility rules that make the default alternative implicitly available. This is fine for assignments and expressions where the target type can be determined from the other operand or operator or their combination.
+
+With dot notation, the situation is more complicated. First of all, dot notation is available for the union itself. For fields that are defined within the default field (e.g. if it is a record) and not inside the union, this should be fine as the compiler should be able to distinguish to which type the field belongs. However, if the field occurs in both types (union and default records), the situation is somehow ambiguous as shown in the following example:
+
+type union U {
+  @default record {
+    record {
+      integer field
+    } equalName
+  } opt1,
+  record equalName {
+    bitstring field
+  }
+}
+...
+var U v_union := {...}
+var integer v_int := v_union.equalName.field;
+
+Does this code reference a field inside the default alternative and pass without a problem (provided the default value is select) or the field points to the second alternative of the union and cause a static type incompatibility error?
+
+My opinion is that the latter is true because of operator precedence rules. Dot notation operations are processed from left to right, thus the first dot resolves to the reference to the second alternative of the union variable and only after that the second dot is resolved (which references a bitstring that is incopatible with the variable of the LHS).
+
+Of course technically it is possible (but much more complicated) to compile it so that the dot notation takes into account the type required by the assignment. However, I struggle to interpret the existing rules on compatibility of union types so that they support that idea.
+
+In any case, the specification should provide more examples on using dot notation with unions containing a default alternative (including the example above) and if necessary, additional rules for this situation.
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0007726closed Gyorgy Rethy Part 09: Using XML with TTCN-3 Naming rules for unions with default alternative (used in substitutions) 
Attached Filesdocx CR7708-v1.docx (181,915) 25-10-2017 15:06
http://oldforge.etsi.org/mantis/file_download.php?file_id=3700&type=bug
docx CR7708-v2.docx (181,866) 25-10-2017 15:56
http://oldforge.etsi.org/mantis/file_download.php?file_id=3701&type=bug
docx CR7708-v3.docx (162,361) 26-10-2017 13:32
http://oldforge.etsi.org/mantis/file_download.php?file_id=3714&type=bug
Issue History
Date ModifiedUsernameFieldChange
13-09-2017 10:26Tomas UrbanNew Issue
14-09-2017 10:39Jacob Wieland - SpirentNote Added: 0014827
24-10-2017 11:24Jens GrabowskiNote Added: 0014840
24-10-2017 11:24Jens GrabowskiAssigned To => Tomas Urban
24-10-2017 11:24Jens GrabowskiStatusnew => assigned
24-10-2017 11:25Jens GrabowskiNote Added: 0014841
25-10-2017 15:06Tomas UrbanFile Added: CR7708-v1.docx
25-10-2017 15:06Tomas UrbanNote Added: 0014876
25-10-2017 15:06Tomas UrbanAssigned ToTomas Urban => Jacob Wieland - Spirent
25-10-2017 15:06Tomas UrbanStatusassigned => confirmed
25-10-2017 15:56Tomas UrbanRelationship addedrelated to 0007726
25-10-2017 15:56Tomas UrbanFile Added: CR7708-v2.docx
26-10-2017 13:32Jacob Wieland - SpirentFile Added: CR7708-v3.docx
26-10-2017 13:33Jacob Wieland - SpirentNote Added: 0014890
26-10-2017 13:33Jacob Wieland - SpirentStatusconfirmed => resolved
26-10-2017 13:33Jacob Wieland - SpirentFixed in Version => v4.9.1 (published 2017-05)
26-10-2017 13:33Jacob Wieland - SpirentResolutionopen => fixed
26-10-2017 13:33Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
30-12-2017 14:35Gyorgy RethyStatusresolved => closed
30-12-2017 14:35Gyorgy RethyFixed in Versionv4.9.1 (published 2017-05) => v4.10.1 (published 2018-05)
30-12-2017 14:35Gyorgy RethyNote Added: 0014949
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014827) +
+ Jacob Wieland - Spirent    +
+ 14-09-2017 10:39    +
+ 		+ + + + +
+ Interesting case.
+
+I think we need a clarification that explicit dot-notation is preferred to implicit @default-unwrapping when there is a conflict like in the given example.
+
+I.e. the implicit interpretation of a union value should only be considered if the explicit is statically unsound.
+
+Another way to go would, of course, be to disallow such definitions in the first place, i.e. not only need the field names on the union level be unique, they also shall not clash with potential field names from the type of the @default alternative. To me, that would be an acceptable restriction.
+
+
+
+ + + + + + + + + + +
+ (0014840) +
+ Jens Grabowski    +
+ 24-10-2017 11:24    +
+ 		+ + + + +
+ STF decision: 1) Follow Jacob's second proposal (i.e., "Another ...).
+2) New CR for XML part required (to be submitted by Tomas)
+
+
+
+ + + + + + + + + + +
+ (0014841) +
+ Jens Grabowski    +
+ 24-10-2017 11:25    +
+ 		+ + + + +
+ (To be implemented until end of 2017)
+
+
+
+ + + + + + + + + + +
+ (0014876) +
+ Tomas Urban    +
+ 25-10-2017 15:06    +
+ 		+ + + + +
+ Resolution uploaded. Please check.
+
+
+
+ + + + + + + + + + +
+ (0014890) +
+ Jacob Wieland - Spirent    +
+ 26-10-2017 13:33    +
+ 		+ + + + +
+ some small reformulation which has been approved by Tomas has been done and then it is resolved
+
+
+
+ + + + + + + + + + +
+ (0014949) +
+ Gyorgy Rethy    +
+ 30-12-2017 14:35    +
+ 		+ + + + +
+ Added to master copy V4.9.2
+
+ + diff --git a/docs/mantis/CR7709.md b/docs/mantis/CR7709.md new file mode 100644 index 0000000000000000000000000000000000000000..0a4d917fcd39ace7e6456128c676e386c9ace21b --- /dev/null +++ b/docs/mantis/CR7709.md @@ -0,0 +1,329 @@ + + + + + + + + + + + + + 0007709: Invalid template in the example on enumerated templates - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007709Part 01: TTCN-3 Core LanguageEditorialpublic15-09-2017 09:4330-12-2017 14:56
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeveritytrivialReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.9.1 (published 2017-05) 
Target VersionFixed in Versionv4.10.1 (published 2018-05) 
Clause Reference(s)6.2.4
Source (company - Author)Elvior
Summary0007709: Invalid template in the example on enumerated templates
DescriptionThe example 3 in the clause 6.2.4 defines a template for an enumerated type in the following way:
+
+match(v_color, Other(6..10))
+
+However, this cannot be correct as according to the BNF and semantic rules defined in 6.2.4, the content of the parentheses shall be a template body. In case of the range template, the correct syntax is with parentheses:
+
+match(v_color, Other((6..10)))
+
+If the intention was to allow inserting ranges directly (which might be quite reasonable), this specific syntax has to be added to the BNF and semantic rules. The other option is to correct the example.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7709.docx (157,384) 25-10-2017 09:23
http://oldforge.etsi.org/mantis/file_download.php?file_id=3692&type=bug
docx CR7709_v2.docx (165,848) 25-10-2017 10:14
http://oldforge.etsi.org/mantis/file_download.php?file_id=3694&type=bug
docx CR7709_v3.docx (165,800) 25-10-2017 10:56
http://oldforge.etsi.org/mantis/file_download.php?file_id=3695&type=bug
Issue History
Date ModifiedUsernameFieldChange
15-09-2017 09:43Tomas UrbanNew Issue
18-09-2017 12:00Jacob Wieland - SpirentNote Added: 0014828
24-10-2017 11:12Jens GrabowskiAssigned To => Kristóf Szabados
24-10-2017 11:12Jens GrabowskiStatusnew => assigned
24-10-2017 11:13Jens GrabowskiNote Added: 0014839
25-10-2017 09:17Kristóf SzabadosNote Added: 0014861
25-10-2017 09:23Kristóf SzabadosFile Added: CR7709.docx
25-10-2017 10:12Kristóf SzabadosNote Added: 0014867
25-10-2017 10:14Kristóf SzabadosFile Added: CR7709_v2.docx
25-10-2017 10:15Kristóf SzabadosNote Added: 0014868
25-10-2017 10:15Kristóf SzabadosAssigned ToKristóf Szabados => Tomas Urban
25-10-2017 10:15Kristóf SzabadosStatusassigned => confirmed
25-10-2017 10:56Kristóf SzabadosFile Added: CR7709_v3.docx
25-10-2017 10:57Kristóf SzabadosNote Added: 0014869
25-10-2017 11:06Tomas UrbanNote Added: 0014871
25-10-2017 11:06Tomas UrbanStatusconfirmed => resolved
25-10-2017 11:06Tomas UrbanResolutionopen => fixed
25-10-2017 11:06Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
30-12-2017 14:56Gyorgy RethyNote Added: 0014950
30-12-2017 14:56Gyorgy RethyStatusresolved => closed
30-12-2017 14:56Gyorgy RethyFixed in Version => v4.10.1 (published 2018-05)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014828) +
+ Jacob Wieland - Spirent    +
+ 18-09-2017 12:00    +
+ 		+ + + + +
+ Are you sure that X .. Y is not a template body already (and (X .. Y) not just a combination of value-list with range?
+
+If you're sure, I would suggest we add this possibility, as otherwise, the same problem arises in a lot of places
+
+receive(integer:3 .. 4)
+
+select(v) { case (3..4) ...
+
+match(x, 3 .. 4)
+
+
+etc.
+
+
+
+ + + + + + + + + + +
+ (0014839) +
+ Jens Grabowski    +
+ 24-10-2017 11:13    +
+ 		+ + + + +
+ To be checked for all cases.
+(To be implemented until end of 2017)
+
+
+
+ + + + + + + + + + +
+ (0014861) +
+ Kristóf Szabados    +
+ 25-10-2017 09:17    +
+ 		+ + + + +
+ Right now the example is erroneous and needs to be corrected.
+According to the BNF the EnumTemplateExtension has to contain templateBody -s ... where range requires the '('')'
+
+I would separate adding this syntax into a different task if needed, as it might need its own discussion/investigation.
+For example for the current situation templateBody would not need to be extended, only EnumTemplateExtension would need to be changed.
+
+Also changing templatebody could introduce confusing syntax, that needs to be handled carefully.
+For example seeing something like subset(1, 3.. 10, 12) looks like a subset allowing at most 10 different values, while actually with the current syntax it is subset(1, (3..10), 12)
+
+
+
+ + + + + + + + + + +
+ (0014867) +
+ Kristóf Szabados    +
+ 25-10-2017 10:12    +
+ 		+ + + + +
+ STF discussion: the EnumTemplateExtension should be extended to allow lists of templatebodies and ranges of integer values.
+
+
+
+ + + + + + + + + + +
+ (0014868) +
+ Kristóf Szabados    +
+ 25-10-2017 10:15    +
+ 		+ + + + +
+ I have added the possibility of using ranges in the EnumTemplateExtension together with templatebodies.
+Please check.
+
+
+
+ + + + + + + + + + +
+ (0014869) +
+ Kristóf Szabados    +
+ 25-10-2017 10:57    +
+ 		+ + + + +
+ minor change uploaded: we no longer need to change the original example.
+
+
+
+ + + + + + + + + + +
+ (0014871) +
+ Tomas Urban    +
+ 25-10-2017 11:06    +
+ 		+ + + + +
+ The resolution is correct and can be added to the next version of the core language specification.
+
+
+
+ + + + + + + + + + +
+ (0014950) +
+ Gyorgy Rethy    +
+ 30-12-2017 14:56    +
+ 		+ + + + +
+ Added to draft V4.9.2
+
+ + diff --git a/docs/mantis/CR7710.md b/docs/mantis/CR7710.md new file mode 100644 index 0000000000000000000000000000000000000000..5e33200a0db9fe6b249badb5fc8c1c90b2f15bc9 --- /dev/null +++ b/docs/mantis/CR7710.md @@ -0,0 +1,165 @@ + + + + + + + + + + + + + 0007710: Superfluous record keywords - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007710Part 01: TTCN-3 Core LanguageEditorialpublic22-09-2017 10:2330-12-2017 14:59
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeveritytrivialReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.9.1 (published 2017-05) 
Target VersionFixed in Versionv4.10.1 (published 2018-05) 
Clause Reference(s)27.1.2.0
Source (company - Author)Elvior
Summary0007710: Superfluous record keywords
DescriptionThe declaration of synonym type (SynonymType1, SynonymType2) in the example 3 of the section 27.1.2.0 shall not contain the "record" keyword.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx 7710.docx (16,013) 25-10-2017 09:04
http://oldforge.etsi.org/mantis/file_download.php?file_id=3690&type=bug
Issue History
Date ModifiedUsernameFieldChange
22-09-2017 10:23Tomas UrbanNew Issue
24-10-2017 11:00Jens GrabowskiAssigned To => Julien Deltour
24-10-2017 11:00Jens GrabowskiStatusnew => assigned
24-10-2017 11:00Jens GrabowskiNote Added: 0014838
25-10-2017 09:04Julien DeltourFile Added: 7710.docx
25-10-2017 09:04Julien DeltourNote Added: 0014859
25-10-2017 09:05Julien DeltourStatusassigned => confirmed
25-10-2017 09:05Julien DeltourAssigned ToJulien Deltour => Tomas Urban
25-10-2017 09:05Julien DeltourStatusconfirmed => assigned
25-10-2017 09:58Tomas UrbanNote Added: 0014864
25-10-2017 09:58Tomas UrbanStatusassigned => resolved
25-10-2017 09:58Tomas UrbanResolutionopen => fixed
25-10-2017 09:58Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
30-12-2017 14:59Gyorgy RethyNote Added: 0014951
30-12-2017 14:59Gyorgy RethyStatusresolved => closed
30-12-2017 14:59Gyorgy RethyProduct Versionv4.10.1 (published 2018-05) => v4.9.1 (published 2017-05)
30-12-2017 14:59Gyorgy RethyFixed in Version => v4.10.1 (published 2018-05)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014838) +
+ Jens Grabowski    +
+ 24-10-2017 11:00    +
+ 		+ + + + +
+ (To be implemented until end of 2017)
+
+
+
+ + + + + + + + + + +
+ (0014859) +
+ Julien Deltour    +
+ 25-10-2017 09:04    +
+ 		+ + + + +
+ PLease check.
+
+
+
+ + + + + + + + + + +
+ (0014864) +
+ Tomas Urban    +
+ 25-10-2017 09:58    +
+ 		+ + + + +
+ The resolution is fine and can be added to the new version of the core language specification.
+
+
+
+ + + + + + + + + + +
+ (0014951) +
+ Gyorgy Rethy    +
+ 30-12-2017 14:59    +
+ 		+ + + + +
+ Added to draft V4.9.2
+
+ + diff --git a/docs/mantis/CR7711.md b/docs/mantis/CR7711.md new file mode 100644 index 0000000000000000000000000000000000000000..e13931bd83c9d79d8add20261657ab1ec44da15e --- /dev/null +++ b/docs/mantis/CR7711.md @@ -0,0 +1,180 @@ + + + + + + + + + + + + + 0007711: editorial: syntactical structure parts are not properly "spaced"/"indented" - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Config & Deployment Support (ES 202 781)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007711Ext Pack: Config & Deployment Support (ES 202 781)Editorialpublic26-09-2017 09:5202-01-2018 12:19
ReporterKristóf Szabados 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Versionv1.5.1 (published 2017-05) 
Clause Reference(s)5.2.1, 5.2.2, 5.2.3
Source (company - Author)     L.M. Ericsson
TS versionn/a
Summary0007711: editorial: syntactical structure parts are not properly "spaced"/"indented"
DescriptionIn section 5.2.1 the example is missing some extra spaces:
+"
+inDataMessage fromTransportMessage withtransportToData();
+outDataMessage toTransportMessage withdataToTransport();
+"
+
+5.2.2 too:
+"
+typecomponent SystemComponent{
+portDataPort dataPort;
+portTransportPort transportPort;
+}
+"
+
+and many other places in the document.
+The examples in this document should be checked.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx 7711.docx (340,584) 25-10-2017 09:05
http://oldforge.etsi.org/mantis/file_download.php?file_id=3691&type=bug
docx 7711_v2.docx (340,941) 25-10-2017 11:37
http://oldforge.etsi.org/mantis/file_download.php?file_id=3697&type=bug
Issue History
Date ModifiedUsernameFieldChange
26-09-2017 09:52Kristóf SzabadosNew Issue
24-10-2017 11:00Jens GrabowskiAssigned To => Julien Deltour
24-10-2017 11:00Jens GrabowskiStatusnew => assigned
24-10-2017 11:00Jens GrabowskiNote Added: 0014837
25-10-2017 09:05Julien DeltourFile Added: 7711.docx
25-10-2017 09:05Julien DeltourNote Added: 0014860
25-10-2017 09:06Julien DeltourStatusassigned => confirmed
25-10-2017 09:06Julien DeltourAssigned ToJulien Deltour => Kristóf Szabados
25-10-2017 09:06Julien DeltourStatusconfirmed => assigned
25-10-2017 11:37Kristóf SzabadosFile Added: 7711_v2.docx
25-10-2017 11:38Kristóf SzabadosNote Added: 0014872
25-10-2017 11:41Kristóf SzabadosStatusassigned => confirmed
25-10-2017 11:41Kristóf SzabadosNote Added: 0014873
25-10-2017 11:41Kristóf SzabadosStatusconfirmed => resolved
25-10-2017 11:41Kristóf SzabadosResolutionopen => fixed
25-10-2017 11:41Kristóf SzabadosAssigned ToKristóf Szabados => Jens Grabowski
02-01-2018 12:19Jens GrabowskiStatusresolved => closed
02-01-2018 12:19Jens GrabowskiFixed in Version => v1.5.1 (published 2017-05)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014837) +
+ Jens Grabowski    +
+ 24-10-2017 11:00    +
+ 		+ + + + +
+ (To be implemented until end of 2017)
+
+
+
+ + + + + + + + + + +
+ (0014860) +
+ Julien Deltour    +
+ 25-10-2017 09:05    +
+ 		+ + + + +
+ Please check.
+
+
+
+ + + + + + + + + + +
+ (0014872) +
+ Kristóf Szabados    +
+ 25-10-2017 11:38    +
+ 		+ + + + +
+ The correction looks fine to me ... I just noticed one more location, so refreshed the document.
+
+
+
+ + + + + + + + + + +
+ (0014873) +
+ Kristóf Szabados    +
+ 25-10-2017 11:41    +
+ 		+ + + + +
+ The fixes look fine for me
+
+ + diff --git a/docs/mantis/CR7712.md b/docs/mantis/CR7712.md new file mode 100644 index 0000000000000000000000000000000000000000..ecce74248cafb606af78c40e0175f3f4c42eb474 --- /dev/null +++ b/docs/mantis/CR7712.md @@ -0,0 +1,169 @@ + + + + + + + + + + + + + 0007712: Errors in the example on retrieving attribute values - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007712Part 01: TTCN-3 Core LanguageEditorialpublic27-09-2017 12:3930-12-2017 15:38
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.9.1 (published 2017-05) 
Target Versionv4.10.1 (published 2018-05)Fixed in Versionv4.10.1 (published 2018-05) 
Clause Reference(s)27.8
Source (company - Author)Elvior
Summary0007712: Errors in the example on retrieving attribute values
DescriptionThe example in the section 27.8 specifies a variant attribute "CommonRule". Although the original proposal for multiple encodings allowed common variants, the feature was withdrawn later and the final version requires all variants to contain an explicit encoding reference if multiple encodings are used (see 27.5 for more details).
+
+Proposed changes in the example:
+1. Remove the "CommonRule" variant from the type definition
+2. Change the comment of "v_variants := v_pdu.variant;" code line to "v_variants will contain {} as all variants are bound to encode attributes"
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx 7712.docx (17,568) 25-10-2017 09:02
http://oldforge.etsi.org/mantis/file_download.php?file_id=3689&type=bug
Issue History
Date ModifiedUsernameFieldChange
27-09-2017 12:39Tomas UrbanNew Issue
24-10-2017 10:56Jens GrabowskiAssigned To => Julien Deltour
24-10-2017 10:56Jens GrabowskiStatusnew => assigned
24-10-2017 10:57Jens GrabowskiNote Added: 0014836
25-10-2017 09:02Julien DeltourFile Added: 7712.docx
25-10-2017 09:03Julien DeltourNote Added: 0014858
25-10-2017 09:03Julien DeltourAssigned ToJulien Deltour => Tomas Urban
25-10-2017 09:04Julien DeltourStatusassigned => confirmed
25-10-2017 09:25Julien DeltourStatusconfirmed => assigned
25-10-2017 10:00Tomas UrbanNote Added: 0014865
25-10-2017 10:00Tomas UrbanStatusassigned => resolved
25-10-2017 10:00Tomas UrbanResolutionopen => fixed
25-10-2017 10:01Tomas UrbanStatusresolved => feedback
25-10-2017 10:01Tomas UrbanResolutionfixed => reopened
25-10-2017 10:01Tomas UrbanStatusfeedback => resolved
25-10-2017 10:01Tomas UrbanResolutionreopened => fixed
25-10-2017 10:01Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
30-12-2017 15:38Gyorgy RethyNote Added: 0014955
30-12-2017 15:38Gyorgy RethyStatusresolved => closed
30-12-2017 15:38Gyorgy RethyFixed in Version => v4.10.1 (published 2018-05)
30-12-2017 15:38Gyorgy RethyTarget Version => v4.10.1 (published 2018-05)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014836) +
+ Jens Grabowski    +
+ 24-10-2017 10:57    +
+ 		+ + + + +
+ (To be implemented until end of 2017)
+
+
+
+ + + + + + + + + + +
+ (0014858) +
+ Julien Deltour    +
+ 25-10-2017 09:03    +
+ 		+ + + + +
+ Please check.
+
+
+
+ + + + + + + + + + +
+ (0014865) +
+ Tomas Urban    +
+ 25-10-2017 10:00    +
+ 		+ + + + +
+ The resolution is fine and can be added to the new version of the core language specification.
+
+
+
+ + + + + + + + + + +
+ (0014955) +
+ Gyorgy Rethy    +
+ 30-12-2017 15:38    +
+ 		+ + + + +
+ Added to draft V4.9.2
+
+ + diff --git a/docs/mantis/CR7714.md b/docs/mantis/CR7714.md new file mode 100644 index 0000000000000000000000000000000000000000..febebc58f12cdf5165339199bde61fe274cfeb4b --- /dev/null +++ b/docs/mantis/CR7714.md @@ -0,0 +1,205 @@ + + + + + + + + + + + + + 0007714: Several issues with the setencode operation - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007714Part 01: TTCN-3 Core LanguageEditorialpublic03-10-2017 08:0930-12-2017 15:34
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.9.1 (published 2017-05) 
Target Versionv4.10.1 (published 2018-05)Fixed in Versionv4.10.1 (published 2018-05) 
Clause Reference(s)27.9
Source (company - Author)Elvior
Summary0007714: Several issues with the setencode operation
DescriptionThe definition of setencode operation introduced in the last version of the core language standard contains several minor errors:
+
+1. The syntax is missing from the BNF
+2. The syntax definition in the section 27.9 contains a superfluous keyword "optional" which should be removed.
+3. The examples contain a command for reseting the filter (using hyphen). This syntax was present in the original proposal, but it was later removed from the text. It should be taken away from the examples as well.
+4. There should be an additional restriction saying that the all port syntax can be used only in functions, test cases and altsteps that contain the "runs on" clause.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7714-v1.docx (287,117) 25-10-2017 12:49
http://oldforge.etsi.org/mantis/file_download.php?file_id=3698&type=bug
Issue History
Date ModifiedUsernameFieldChange
03-10-2017 08:09Tomas UrbanNew Issue
04-10-2017 10:52Jacob Wieland - SpirentNote Added: 0014830
24-10-2017 10:53Jens GrabowskiAssigned To => Tomas Urban
24-10-2017 10:53Jens GrabowskiStatusnew => assigned
24-10-2017 10:56Jens GrabowskiNote Added: 0014835
25-10-2017 12:49Tomas UrbanFile Added: CR7714-v1.docx
25-10-2017 12:50Tomas UrbanNote Added: 0014874
25-10-2017 12:50Tomas UrbanAssigned ToTomas Urban => Julien Deltour
25-10-2017 12:50Tomas UrbanStatusassigned => confirmed
25-10-2017 13:10Julien DeltourNote Added: 0014875
25-10-2017 13:10Julien DeltourStatusconfirmed => resolved
25-10-2017 13:10Julien DeltourResolutionopen => fixed
25-10-2017 13:11Julien DeltourStatusresolved => feedback
25-10-2017 13:11Julien DeltourResolutionfixed => reopened
25-10-2017 13:12Julien DeltourStatusfeedback => resolved
25-10-2017 13:12Julien DeltourResolutionreopened => fixed
25-10-2017 13:12Julien DeltourAssigned ToJulien Deltour => Gyorgy Rethy
30-12-2017 15:34Gyorgy RethyNote Added: 0014954
30-12-2017 15:34Gyorgy RethyStatusresolved => closed
30-12-2017 15:34Gyorgy RethyProduct Version => v4.9.1 (published 2017-05)
30-12-2017 15:34Gyorgy RethyFixed in Version => v4.10.1 (published 2018-05)
30-12-2017 15:34Gyorgy RethyTarget Version => v4.10.1 (published 2018-05)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014830) +
+ Jacob Wieland - Spirent    +
+ 04-10-2017 10:52    +
+ 		+ + + + +
+ I don't see the reason for number 4.
+
+
+
+ + + + + + + + + + +
+ (0014835) +
+ Jens Grabowski    +
+ 24-10-2017 10:56    +
+ 		+ + + + +
+ STF discussion: Tomas will continue with this issue.
+(To be implemented until end of 2017)
+
+
+
+ + + + + + + + + + +
+ (0014874) +
+ Tomas Urban    +
+ 25-10-2017 12:50    +
+ 		+ + + + +
+ Proposal uploaded. It solves the problems 1, 2 and 3, the 4th issue is currently not included as it was considered unnecessary. Please check.
+
+
+
+ + + + + + + + + + +
+ (0014875) +
+ Julien Deltour    +
+ 25-10-2017 13:10    +
+ 		+ + + + +
+ Resolution looks fine for me.
+
+
+
+ + + + + + + + + + +
+ (0014954) +
+ Gyorgy Rethy    +
+ 30-12-2017 15:34    +
+ 		+ + + + +
+ Implemented in V4.9.2
+
+ + diff --git a/docs/mantis/CR7718.md b/docs/mantis/CR7718.md new file mode 100644 index 0000000000000000000000000000000000000000..7f500f9d7573b10e7c841560f57942b6e6ed6371 --- /dev/null +++ b/docs/mantis/CR7718.md @@ -0,0 +1,99 @@ + + + + + + + + + + + + + 0007718: There is no "Part 11: Using JSON with TTCN-3" category in Mantis - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - TTCN-3 Change Requests
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007718TTCN-3 Change RequestsNew Featurepublic19-10-2017 14:3404-01-2018 17:10
Reporternikolajev 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Clause Reference(s)1
For STF discussion
Source (company - Author)     Elvior - Janek Nikolajev
Summary0007718: There is no "Part 11: Using JSON with TTCN-3" category in Mantis
DescriptionPlease add "Part 11: Using JSON with TTCN-3" category to Mantis bug tracker so issues related to that specification can be properly reported.
+
+Currently "TTCN-3 Change Request" project only contains parts 1-10 of TTCN-3 specification.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
19-10-2017 14:34nikolajevNew Issue
24-10-2017 10:52Jens GrabowskiAssigned To => Jens Grabowski
24-10-2017 10:52Jens GrabowskiStatusnew => assigned
24-10-2017 10:52Jens GrabowskiNote Added: 0014834
04-01-2018 17:10Gyorgy RethyNote Added: 0014995
04-01-2018 17:10Gyorgy RethyAssigned ToJens Grabowski => Gyorgy Rethy
04-01-2018 17:10Gyorgy RethyStatusassigned => closed
04-01-2018 17:10Gyorgy RethyResolutionopen => fixed
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014834) +
+ Jens Grabowski    +
+ 24-10-2017 10:52    +
+ 		+ + + + +
+ Initiated today.
+
+
+
+ + + + + + + + + + +
+ (0014995) +
+ Gyorgy Rethy    +
+ 04-01-2018 17:10    +
+ 		+ + + + +
+ Subproject has been created in Mantis.
+
+ + diff --git a/docs/mantis/CR7719.md b/docs/mantis/CR7719.md new file mode 100644 index 0000000000000000000000000000000000000000..1ada462df9dcd79e078553a4245cefd2be4c29e4 --- /dev/null +++ b/docs/mantis/CR7719.md @@ -0,0 +1,275 @@ + + + + + + + + + + + + + 0007719: Errors in examples for "Part 11: Using JSON with TTCN-3", "6.4.2 JSON Strings" - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 11: Using JSON with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007719Part 11: Using JSON with TTCN-3[TTCN-3 Change Requests] Editorialpublic19-10-2017 15:1305-01-2018 10:36
Reporternikolajev 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product VersionV4.7.1 (published 2017-06) 
Target VersionV4.8.1 (published 2020-05)Fixed in VersionV4.8.1 (published 2020-05) 
Summary0007719: Errors in examples for "Part 11: Using JSON with TTCN-3", "6.4.2 JSON Strings"
DescriptionIn "Part 11: Using JSON with TTCN-3" specification V4.7.1, examples under "6.4.2 JSON Strings" cannot work as shown in specification.
+
+1) In example for:
+const JSON.String c_string1 := <actual value> with (variant "escape as short");
+
+where <actual value> is:
+"ab" & char(U7) &cu_ht & "cd"
+
+and JSON character sequence is:
+"ab\u0007\u0009cd"
+
+"Note" in example states:
+The horizontal tab character is encoded according to the encoding instruction of the referenced definition ("escape as usi") and not according to the referencing definition ("escape as short")
+
+This however cannot work with current TTCN-3 specification, as strings are concatenated first and encoded later, encoding variant of referenced "cu_ht" string has no effect on encoding of "c_string1", entire string will use "short" escape sequence.
+
+2) In example for:
+const JSON.String c_string1 := <actual value> with (variant "escape as usi");
+
+The same issue applies, encoding variant of referenced "cs_ht" string has no effect on encoding of "c_string1", entire string will use "usi" escape sequence.
+
+3) In example for:
+const JSON.String c_string1 := <actual value> with (variant "escape as transparent");
+
+where <actual value> is:
+"ab" & char(U7) & "cd"
+
+and JSON character sequence is:
+"ab\u0007cd"
+
+and UTF-8 serialization of the JSON value:
+2261625C75303030375C74636422
+
+UTF-8 serialization contains 5C74 encoding of a character (horizontal tab I assume) that is not present in <actual value> or "JSON character sequence"
+
+
+4) Please change to valid TTCN-3 syntax.
+Attributes are enclosed in curly brackets {}, not parentheses () as used in specification:
+const JSON.String c_string1 := <actual value> with (variant "...");
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7719.docx (227,069) 26-10-2017 09:57
http://oldforge.etsi.org/mantis/file_download.php?file_id=3706&type=bug
docx CR7719_v2.docx (148,630) 26-10-2017 15:49
http://oldforge.etsi.org/mantis/file_download.php?file_id=3718&type=bug
Issue History
Date ModifiedUsernameFieldChange
19-10-2017 15:13nikolajevNew Issue
24-10-2017 10:51Jens GrabowskiAssigned To => Kristóf Szabados
24-10-2017 10:51Jens GrabowskiStatusnew => assigned
24-10-2017 10:52Jens GrabowskiNote Added: 0014833
26-10-2017 09:57Kristóf SzabadosFile Added: CR7719.docx
26-10-2017 09:58Kristóf SzabadosNote Added: 0014881
26-10-2017 09:58Kristóf SzabadosStatusassigned => confirmed
26-10-2017 10:17Kristóf SzabadosNote Added: 0014882
26-10-2017 10:17Kristóf SzabadosStatusconfirmed => assigned
26-10-2017 15:49Kristóf SzabadosFile Added: CR7719_v2.docx
26-10-2017 15:50Kristóf SzabadosNote Added: 0014899
26-10-2017 15:50Kristóf SzabadosAssigned ToKristóf Szabados => Tomas Urban
26-10-2017 15:50Kristóf SzabadosStatusassigned => confirmed
27-10-2017 13:00Tomas UrbanNote Added: 0014918
27-10-2017 13:00Tomas UrbanStatusconfirmed => resolved
27-10-2017 13:00Tomas UrbanResolutionopen => fixed
27-10-2017 13:00Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
04-01-2018 17:00Gyorgy RethyProjectTTCN-3 Change Requests => Part 11: Using JSON with TTCN-3
05-01-2018 10:36Gyorgy RethyNote Added: 0015004
05-01-2018 10:36Gyorgy RethyStatusresolved => closed
05-01-2018 10:36Gyorgy RethyProduct Version => V4.7.1 (published 2017-06)
05-01-2018 10:36Gyorgy RethyFixed in Version => V4.8.1 (published 2020-05)
05-01-2018 10:36Gyorgy RethyTarget Version => V4.8.1 (published 2020-05)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014833) +
+ Jens Grabowski    +
+ 24-10-2017 10:52    +
+ 		+ + + + +
+ STF decision: Kristof to check with György.
+
+
+
+ + + + + + + + + + +
+ (0014881) +
+ Kristóf Szabados    +
+ 26-10-2017 09:58    +
+ 		+ + + + +
+ uploaded fix for issues 3 and 4.
+
+Issues 1 and 2 need more discussion (might need to be handled in separate CR).
+
+
+
+ + + + + + + + + + +
+ (0014882) +
+ Kristóf Szabados    +
+ 26-10-2017 10:17    +
+ 		+ + + + +
+ incorrectly set to confirmed
+
+
+
+ + + + + + + + + + +
+ (0014899) +
+ Kristóf Szabados    +
+ 26-10-2017 15:50    +
+ 		+ + + + +
+ The examples mentioned in issue 1 and 2 are corrected too.
+
+Please check.
+
+
+
+ + + + + + + + + + +
+ (0014918) +
+ Tomas Urban    +
+ 27-10-2017 13:00    +
+ 		+ + + + +
+ No problems found, the resolution is ready to be included in the next version of the "Using JSON with TTCN-3" specification.
+
+
+
+ + + + + + + + + + +
+ (0015004) +
+ Gyorgy Rethy    +
+ 05-01-2018 10:36    +
+ 		+ + + + +
+ Implemented in draft version V4.7.2.
+
+ + diff --git a/docs/mantis/CR7720.md b/docs/mantis/CR7720.md new file mode 100644 index 0000000000000000000000000000000000000000..82525955a843db57fc9b852d74a2ecaaed2c24ce --- /dev/null +++ b/docs/mantis/CR7720.md @@ -0,0 +1,408 @@ + + + + + + + + + + + + + 0007720: Removal of deprecated features from the TTCN-3 core language - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007720Part 01: TTCN-3 Core LanguageTechnicalpublic25-10-2017 10:0104-01-2019 16:29
ReporterJens Grabowski 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.10.1 (published 2018-05) 
Target Version4.11.1 (published 2019-05)Fixed in Version4.11.1 (published 2019-05) 
Clause Reference(s)Annex G
Source (company - Author) Jens Grabowski (STF 533)
Summary0007720: Removal of deprecated features from the TTCN-3 core language
DescriptionAnnex G of the TTCN-3 core language standard includes a list of 12 deprecated languages features.
+
+As part of the language harmonization, whereever possible, deprecated features shall be removed from the standard. Apart from textual removal, this may include changes in the BNF.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR-7720-180417.docx (198,366) 17-04-2018 14:39
http://oldforge.etsi.org/mantis/file_download.php?file_id=3740&type=bug
Issue History
Date ModifiedUsernameFieldChange
25-10-2017 10:01Jens GrabowskiNew Issue
25-10-2017 10:01Jens GrabowskiStatusnew => assigned
25-10-2017 10:01Jens GrabowskiAssigned To => Jens Grabowski
25-10-2017 10:02Jens GrabowskiNote Added: 0014866
26-10-2017 13:50Jens GrabowskiNote Added: 0014893
27-10-2017 10:40Kristóf SzabadosNote Added: 0014906
27-10-2017 10:43Kristóf SzabadosNote Added: 0014907
05-01-2018 13:27Gyorgy RethyTarget Versionv4.10.1 (published 2018-05) => 4.11.1 (published 2019-05)
17-04-2018 09:09Jens GrabowskiNote Added: 0015089
17-04-2018 09:09Jens GrabowskiAssigned ToJens Grabowski => Jacob Wieland - Spirent
17-04-2018 09:34Jacob Wieland - SpirentNote Added: 0015090
17-04-2018 09:35Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Jens Grabowski
17-04-2018 14:39Jens GrabowskiFile Added: CR-7720-180417.docx
17-04-2018 14:41Jens GrabowskiNote Added: 0015092
17-04-2018 14:44Jens GrabowskiNote Added: 0015094
17-04-2018 14:44Jens GrabowskiStatusassigned => resolved
17-04-2018 14:44Jens GrabowskiFixed in Version => 4.11.1 (published 2019-05)
17-04-2018 14:44Jens GrabowskiResolutionopen => fixed
17-04-2018 14:44Jens GrabowskiAssigned ToJens Grabowski => Gyorgy Rethy
04-01-2019 16:29Gyorgy RethyNote Added: 0015297
04-01-2019 16:29Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014866) +
+ Jens Grabowski    +
+ 25-10-2017 10:02    +
+ 		+ + + + +
+ Email sent to Tool vendors to collect input regarding the deprecated features which can be removed without harm.
+
+
+
+ + + + + + + + + + +
+ (0014893) +
+ Jens Grabowski    +
+ 26-10-2017 13:50    +
+ 		+ + + + +
+ Reaction from Elvior:
+
+Am 26.10.2017 um 12:58 schrieb Tomáš Urban:
+> Hi Jens.
+>
+> The situation with our tool is as follows:
+>
+> Not supported features:
+> G.7 External constants
+>
+> Supported features our clients most likely don't use:
+> G.2 Recursive import
+> G.5 sizeoftype predefined function
+> G.8 Prefixing enumerated values
+> G.9 Record of/arrays not compatible to record; set of not compatible
+> with set
+> G.10 The "UCS-2" predefined variant attribute string
+> G.11 Prefixing identifiers of local definitions with module
+> G.12 Matching expressions of incompatible types
+>
+> Supported features that occur in legacy test suites (it shouldn't be a
+> problem to update these tests):
+> G.1 Group style definition of module parameters
+> G.6 Mixed ports
+>
+> Supported and used in test suites:
+> G.3 Using all in port type definitions
+> G.4 sizeof for length of lists
+>
+> BR
+> --Tomas
+
+
+
+ + + + + + + + + + +
+ (0014906) +
+ Kristóf Szabados    +
+ 27-10-2017 10:40    +
+ 		+ + + + +
+ Ericsson response.
+
+Features that appear in test suites:
+G.1 Group style definition of module parameters
+G.4 sizeof for length of lists
+
+Featues not supported:
+G.2 Recursive import
+G.5 sizeoftype predefined function
+G.8 Prefixing enumerated values
+G.10 The "UCS-2" predefined variant attribute string
+G.11 Prefixing identifiers of local definitions with module
+
+
+
+ + + + + + + + + + +
+ (0014907) +
+ Kristóf Szabados    +
+ 27-10-2017 10:43    +
+ 		+ + + + +
+ We have support for these feature, and have not found them used (but still might be used in products we could not contact):
+
+G.3 Using all in port type definitions
+G.6 Mixed ports
+G.7 External constants
+G.9 Record of/arrays not compatible to record; set of not compatible
+with set
+G.12 Matching expressions of incompatible types
+
+Please note that G.9 and G.12 became deprecated only recently.
+
+
+
+ + + + + + + + + + +
+ (0015089) +
+ Jens Grabowski    +
+ 17-04-2018 09:09    +
+ 		+ + + + +
+ Proposal:
+
+We keep:
+
+G.1 Group style definition of module parameters
+G.3 Using all in port type definitions
+G.4 sizeof for length of lists
+G.6 Mixed ports
+
+We delete:
+
+G.2 Recursive import
+G.5 sizeoftype predefined function
+G.7 External constants
+G.8 Prefixing enumerated values
+G.9 Record of/arrays not compatible to record; set of not compatible with set
+G.10 The "UCS-2" predefined variant attribute string
+G.11 Prefixing identifiers of local definitions with module
+G.12 Matching expressions of incompatible types
+
+@Jacob: Is this ok with Spirent
+
+
+
+ + + + + + + + + + +
+ (0015090) +
+ Jacob Wieland - Spirent    +
+ 17-04-2018 09:34    +
+ 		+ + + + +
+ Fine with Spirent.
+
+
+
+ + + + + + + + + + +
+ (0015092) +
+ Jens Grabowski    +
+ 17-04-2018 14:41    +
+ 		+ + + + +
+ Resolution upladed.
+Resolution includes the changes in Annex G and necessary changes in Annex A (BNF). During validation Problems with parentheses rules 95 and 151 have been detected. They should be investigated when implementing this CR.
+
+
+
+ + + + + + + + + + +
+ (0015094) +
+ Jens Grabowski    +
+ 17-04-2018 14:44    +
+ 		+ + + + +
+ Ready for implementation. Please have a look to the rules 95 and 151 in the core language BNF
+
+
+
+ + + + + + + + + + +
+ (0015297) +
+ Gyorgy Rethy    +
+ 04-01-2019 16:29    +
+ 		+ + + + +
+ Added to draft V4.10.2
+
+ + diff --git a/docs/mantis/CR7721.md b/docs/mantis/CR7721.md new file mode 100644 index 0000000000000000000000000000000000000000..c831874b1ddf74f5b84238779fdc1e29f8be70c8 --- /dev/null +++ b/docs/mantis/CR7721.md @@ -0,0 +1,175 @@ + + + + + + + + + + + + + 0007721: Possibility to catch any exception of a specified signature - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007721Part 01: TTCN-3 Core LanguageNew Featurepublic25-10-2017 10:5304-01-2019 16:38
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.9.1 (published 2017-05) 
Target Version4.11.1 (published 2019-05)Fixed in Version4.11.1 (published 2019-05) 
Clause Reference(s)22.3.6
Source (company - Author)STF 533
Summary0007721: Possibility to catch any exception of a specified signature
DescriptionThe catch operation can either catch a specific exception of a referenced signature or any exception of any signature. However, it would be useful to have a third option: to catch any exception of a specified signature. In order to do that, the currently mandatory template instance part in the operation parameter section should be changed into optional:
+
+( Port | any port | any from PortArrayRef ) "." catch
+[ "(" ( Signature "," TemplateInstance ) | TimeoutKeyword ")" ]
+
+->
+
+( Port | any port | any from PortArrayRef ) "." catch
+[ "(" ( Signature [ "," TemplateInstance ] ) | TimeoutKeyword ")" ]
+
+If accepted, the TCI section has to be updated as well (especially the XML mapping)
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0007809closed Tomas Urban Part 06: TTCN-3 Control Interface TLI: Possibility to catch any exception of a specified signature 
Attached Filesdocx CR7721.docx (174,633) 11-10-2018 16:14
http://oldforge.etsi.org/mantis/file_download.php?file_id=3806&type=bug
Issue History
Date ModifiedUsernameFieldChange
25-10-2017 10:53Tomas UrbanNew Issue
27-10-2017 09:20Jens GrabowskiNote Added: 0014904
27-10-2017 09:20Jens GrabowskiAssigned To => Jens Grabowski
27-10-2017 09:20Jens GrabowskiStatusnew => assigned
05-01-2018 13:28Gyorgy RethyTarget Version => 4.11.1 (published 2019-05)
11-10-2018 15:14Jens GrabowskiAssigned ToJens Grabowski => Jacob Wieland - Spirent
11-10-2018 15:30Jacob Wieland - SpirentRelationship addedrelated to 0007809
11-10-2018 16:14Jacob Wieland - SpirentFile Added: CR7721.docx
11-10-2018 16:31Jacob Wieland - SpirentNote Added: 0015260
11-10-2018 16:31Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Tomas Urban
11-10-2018 16:31Jacob Wieland - SpirentStatusassigned => confirmed
12-10-2018 08:18Tomas UrbanNote Added: 0015265
12-10-2018 08:18Tomas UrbanStatusconfirmed => resolved
12-10-2018 08:18Tomas UrbanResolutionopen => fixed
12-10-2018 08:18Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
04-01-2019 16:38Gyorgy RethyNote Added: 0015298
04-01-2019 16:38Gyorgy RethyStatusresolved => closed
04-01-2019 16:38Gyorgy RethyFixed in Version => 4.11.1 (published 2019-05)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014904) +
+ Jens Grabowski    +
+ 27-10-2017 09:20    +
+ 		+ + + + +
+ STF decision: Postponed to 2018 maintenance STF.
+
+
+
+ + + + + + + + + + +
+ (0015260) +
+ Jacob Wieland - Spirent    +
+ 11-10-2018 16:31    +
+ 		+ + + + +
+ I have made a proposal for the changes in Part 1. Please Review
+
+
+
+ + + + + + + + + + +
+ (0015265) +
+ Tomas Urban    +
+ 12-10-2018 08:18    +
+ 		+ + + + +
+ Reviewed. No issues found. Can be added to the next version of the core language specification.
+
+
+
+ + + + + + + + + + +
+ (0015298) +
+ Gyorgy Rethy    +
+ 04-01-2019 16:38    +
+ 		+ + + + +
+ Added to draft V4.10.2
+
+ + diff --git a/docs/mantis/CR7722.md b/docs/mantis/CR7722.md new file mode 100644 index 0000000000000000000000000000000000000000..5451ceafb7311251b8ef15f71542ac56007b7715 --- /dev/null +++ b/docs/mantis/CR7722.md @@ -0,0 +1,188 @@ + + + + + + + + + + + + + 0007722: "Part 11: Using JSON with TTCN-3":"B.3.4 Name as" syntax is confusing, does not match examples throughout specification - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 11: Using JSON with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007722Part 11: Using JSON with TTCN-3[TTCN-3 Change Requests] Clarificationpublic25-10-2017 10:5705-01-2018 09:34
Reporternikolajev 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product VersionV4.7.1 (published 2017-06) 
Target VersionV4.8.1 (published 2020-05)Fixed in VersionV4.8.1 (published 2020-05) 
Summary0007722: "Part 11: Using JSON with TTCN-3":"B.3.4 Name as" syntax is confusing, does not match examples throughout specification
Description1) Single quotes or not for freetext?
+There are multiple examples in specification
+with { variant "name as 'freetext'"} and without
+with { variant "name as freetext"}
+
+2) What can "freetext" or "alias" contain?
+B.3.4 description states "The syntax of the alias is the same as the syntax of TTCN-3 identifiers (regex: [A-Za-z][A-Za-z0-9_]*)."
+
+But some examples of the specification show "name as 'house no.' "
+There are 2 characters that are not allowed in TTCN-3 identifier " ", ".".
+
+If alias syntax is the same of TTCN-3 identifiers, why is alias used at all?
+TTCN-3 field name is a TTCN-3 identifier, which makes alias and field name syntax exactly the same.
+Alias only makes sense if any JSON string is allowed to be used.
+
+3) In "B.3.4 Name as" examples contain "JSON:" prefix inside "name as ..." variant:
+variant(numericID) "JSON:name as ID";
+variant(email) "JSON:name as Email";
+variant(name) "JSON:name as Name";
+
+prefix should be removed.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7722.docx (142,072) 26-10-2017 11:53
http://oldforge.etsi.org/mantis/file_download.php?file_id=3712&type=bug
Issue History
Date ModifiedUsernameFieldChange
25-10-2017 10:57nikolajevNew Issue
26-10-2017 11:44Kristóf SzabadosAssigned To => Kristóf Szabados
26-10-2017 11:44Kristóf SzabadosStatusnew => assigned
26-10-2017 11:49Kristóf SzabadosNote Added: 0014887
26-10-2017 11:53Kristóf SzabadosFile Added: CR7722.docx
26-10-2017 11:54Kristóf SzabadosNote Added: 0014888
26-10-2017 11:54Kristóf SzabadosAssigned ToKristóf Szabados => Tomas Urban
26-10-2017 11:54Kristóf SzabadosStatusassigned => confirmed
27-10-2017 12:43Tomas UrbanNote Added: 0014916
27-10-2017 12:43Tomas UrbanStatusconfirmed => resolved
27-10-2017 12:43Tomas UrbanResolutionopen => fixed
27-10-2017 12:43Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
04-01-2018 17:01Gyorgy RethyProjectTTCN-3 Change Requests => Part 11: Using JSON with TTCN-3
05-01-2018 09:34Gyorgy RethyNote Added: 0015001
05-01-2018 09:34Gyorgy RethyStatusresolved => closed
05-01-2018 09:34Gyorgy RethyProduct Version => V4.7.1 (published 2017-06)
05-01-2018 09:34Gyorgy RethyFixed in Version => V4.8.1 (published 2020-05)
05-01-2018 09:34Gyorgy RethyTarget Version => V4.8.1 (published 2020-05)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014887) +
+ Kristóf Szabados    +
+ 26-10-2017 11:49    +
+ 		+ + + + +
+ STF discussion:
+- the freetext should be in '', otherwise it could be confused with definitions and the changeCase options
+- the "JSON:" is also to be removed. The core standard desribes the "variant
+ {"Codec1","Codec2"}."Rule1"" format to specify if a variant is related to a specific encoding.
+
+
+
+ + + + + + + + + + +
+ (0014888) +
+ Kristóf Szabados    +
+ 26-10-2017 11:54    +
+ 		+ + + + +
+ Please check
+
+
+
+ + + + + + + + + + +
+ (0014916) +
+ Tomas Urban    +
+ 27-10-2017 12:43    +
+ 		+ + + + +
+ No problems found, the resolution is ready to be included in the next version of the "Using JSON with TTCN-3" specification.
+
+
+
+ + + + + + + + + + +
+ (0015001) +
+ Gyorgy Rethy    +
+ 05-01-2018 09:34    +
+ 		+ + + + +
+ Corrected in draft V4.7.2.
+
+ + diff --git a/docs/mantis/CR7723.md b/docs/mantis/CR7723.md new file mode 100644 index 0000000000000000000000000000000000000000..ade91918ffa6f838219b8cdaa248ff49ee6dbb99 --- /dev/null +++ b/docs/mantis/CR7723.md @@ -0,0 +1,146 @@ + + + + + + + + + + + + + 0007723: "Part 11: Using JSON with TTCN-3":"7.2.8 Record and set" invalid JSON syntax in example - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 11: Using JSON with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007723Part 11: Using JSON with TTCN-3[TTCN-3 Change Requests] Editorialpublic25-10-2017 11:3205-01-2018 09:23
Reporternikolajev 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product VersionV4.7.1 (published 2017-06) 
Target VersionV4.8.1 (published 2020-05)Fixed in VersionV4.8.1 (published 2020-05) 
Summary0007723: "Part 11: Using JSON with TTCN-3":"7.2.8 Record and set" invalid JSON syntax in example
DescriptionIn "7.2.8 Record and set" example 1 and 2, JSON encoded value is shown as:
+Example 1:
+{ "MyRecExample1.MyRecord" : { "int":5 , { "myset" : { "value_":5.5, "case_":true }}}}
+
+Example 2:
+{ "int":5 , { "myset" : { "value_":5.5, "case":true }}}
+
+in both cases JSON object key value pairs are invalid because "myset" is enclosed in {}, which breaks the structure of parent JSON object.
+
+Corrected example 1:
+{ "MyRecExample1.MyRecord" : { "int":5 , "myset" : { "value_":5.5, "case_":true }}}
+
+Corrected example 2:
+{ "int":5 , "myset" : { "value_":5.5, "case":true }}
+
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7723.docx (144,319) 26-10-2017 10:27
http://oldforge.etsi.org/mantis/file_download.php?file_id=3708&type=bug
Issue History
Date ModifiedUsernameFieldChange
25-10-2017 11:32nikolajevNew Issue
26-10-2017 10:25Kristóf SzabadosAssigned To => Kristóf Szabados
26-10-2017 10:25Kristóf SzabadosStatusnew => assigned
26-10-2017 10:27Kristóf SzabadosFile Added: CR7723.docx
26-10-2017 10:28Kristóf SzabadosNote Added: 0014883
26-10-2017 10:28Kristóf SzabadosAssigned ToKristóf Szabados => Tomas Urban
26-10-2017 10:28Kristóf SzabadosStatusassigned => confirmed
27-10-2017 12:42Tomas UrbanNote Added: 0014915
27-10-2017 12:42Tomas UrbanStatusconfirmed => resolved
27-10-2017 12:42Tomas UrbanResolutionopen => fixed
27-10-2017 12:42Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
04-01-2018 17:01Gyorgy RethyProjectTTCN-3 Change Requests => Part 11: Using JSON with TTCN-3
05-01-2018 09:23Gyorgy RethyNote Added: 0015000
05-01-2018 09:23Gyorgy RethyStatusresolved => closed
05-01-2018 09:23Gyorgy RethyProduct Version => V4.7.1 (published 2017-06)
05-01-2018 09:23Gyorgy RethyFixed in Version => V4.8.1 (published 2020-05)
05-01-2018 09:23Gyorgy RethyTarget Version => V4.8.1 (published 2020-05)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014883) +
+ Kristóf Szabados    +
+ 26-10-2017 10:28    +
+ 		+ + + + +
+ please check
+
+
+
+ + + + + + + + + + +
+ (0014915) +
+ Tomas Urban    +
+ 27-10-2017 12:42    +
+ 		+ + + + +
+ No problems found, the resolution is ready to be included in the next version of the "Unsing JSON with TTCN-3" specification.
+
+
+
+ + + + + + + + + + +
+ (0015000) +
+ Gyorgy Rethy    +
+ 05-01-2018 09:23    +
+ 		+ + + + +
+ Corrected in draft V4.7.2.
+
+ + diff --git a/docs/mantis/CR7724.md b/docs/mantis/CR7724.md new file mode 100644 index 0000000000000000000000000000000000000000..770cc0f8d63a860e489f0aa7f30fc8270b5631c8 --- /dev/null +++ b/docs/mantis/CR7724.md @@ -0,0 +1,181 @@ + + + + + + + + + + + + + 0007724: "Part 11: Using JSON with TTCN-3":"B.3.5 Number of fraction digits" use 0E0 instead of 0E1 - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 11: Using JSON with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007724Part 11: Using JSON with TTCN-3[TTCN-3 Change Requests] Editorialpublic25-10-2017 11:4705-01-2018 09:41
Reporternikolajev 
Assigned ToGyorgy Rethy 
PrioritylowSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product VersionV4.7.1 (published 2017-06) 
Target VersionV4.8.1 (published 2020-05)Fixed in VersionV4.8.1 (published 2020-05) 
Summary0007724: "Part 11: Using JSON with TTCN-3":"B.3.5 Number of fraction digits" use 0E0 instead of 0E1
DescriptionIn "B.3.5 Number of fraction digits" examples, in case of "fractionDigits 0" encoding of <actual value> 0.0 is shown in JSON as "0E1 or 0E1" which is correct, but means 0.0x10.
+In case of 0, 0E999 is also correct representation, but maybe it would be better to use E0 exponent this way it would look similar for all single digit integers:
+
+0.0 would be 0E0 or 0e0
+1.0 would be 1E0 or 1e0
+
+otherwise it seems like 0E1 is a special case of JSON encoding.
+ 
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7724.docx (142,671) 26-10-2017 16:46
http://oldforge.etsi.org/mantis/file_download.php?file_id=3720&type=bug
Issue History
Date ModifiedUsernameFieldChange
25-10-2017 11:47nikolajevNew Issue
26-10-2017 13:41Kristóf SzabadosAssigned To => Kristóf Szabados
26-10-2017 13:41Kristóf SzabadosStatusnew => assigned
26-10-2017 16:36Kristóf SzabadosNote Added: 0014901
26-10-2017 16:46Kristóf SzabadosFile Added: CR7724.docx
26-10-2017 16:51Kristóf SzabadosNote Added: 0014903
26-10-2017 16:51Kristóf SzabadosAssigned ToKristóf Szabados => Tomas Urban
26-10-2017 16:51Kristóf SzabadosStatusassigned => confirmed
27-10-2017 12:55Tomas UrbanNote Added: 0014917
27-10-2017 12:55Tomas UrbanStatusconfirmed => resolved
27-10-2017 12:55Tomas UrbanResolutionopen => fixed
27-10-2017 12:55Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
04-01-2018 17:00Gyorgy RethyProjectTTCN-3 Change Requests => Part 11: Using JSON with TTCN-3
05-01-2018 09:41Gyorgy RethyNote Added: 0015002
05-01-2018 09:41Gyorgy RethyStatusresolved => closed
05-01-2018 09:41Gyorgy RethyProduct Version => V4.7.1 (published 2017-06)
05-01-2018 09:41Gyorgy RethyFixed in Version => V4.8.1 (published 2020-05)
05-01-2018 09:41Gyorgy RethyTarget Version => V4.8.1 (published 2020-05)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014901) +
+ Kristóf Szabados    +
+ 26-10-2017 16:36    +
+ 		+ + + + +
+ Talking with Thomas we found that 0E-1 might be the best way to represent the value 0.0 if variant "fractionDigits 0" is in effect.
+This follows the usual algorithm, that when the number of fraction digits needed is greater than the number of fractional digits allowed: the exponent is the number of fraction digits allowed minus the number of fraction digits needed.
+
+This way:
+3.1415 -> 31415E-4
+3.142 -> 3142E-3
+3.14 -> 314E-2
+3.1 -> 31E-1
+so
+0.0 -> 0E-1
+
+
+
+ + + + + + + + + + +
+ (0014903) +
+ Kristóf Szabados    +
+ 26-10-2017 16:51    +
+ 		+ + + + +
+ please check
+
+
+
+ + + + + + + + + + +
+ (0014917) +
+ Tomas Urban    +
+ 27-10-2017 12:55    +
+ 		+ + + + +
+ Though different from requested, the proposed solution seems to be logical and acceptable. The resolution is ready to be included in the next version of the "Unsing JSON with TTCN-3" specification.
+
+
+
+ + + + + + + + + + +
+ (0015002) +
+ Gyorgy Rethy    +
+ 05-01-2018 09:41    +
+ 		+ + + + +
+ Added to draft V4.7.2.
+
+ + diff --git a/docs/mantis/CR7725.md b/docs/mantis/CR7725.md new file mode 100644 index 0000000000000000000000000000000000000000..e90cda1b1cf49dae33b1b02903237a362ffa663a --- /dev/null +++ b/docs/mantis/CR7725.md @@ -0,0 +1,222 @@ + + + + + + + + + + + + + 0007725: "Part 11: Using JSON with TTCN-3":"B.3.6 Use the Minus sign" assumptions for TTCN-3 Core Language spec - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 11: Using JSON with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007725Part 11: Using JSON with TTCN-3[TTCN-3 Change Requests] Clarificationpublic25-10-2017 12:0005-01-2018 09:19
Reporternikolajev 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product VersionV4.7.1 (published 2017-06) 
Target VersionV4.8.1 (published 2020-05)Fixed in VersionV4.8.1 (published 2020-05) 
Summary0007725: "Part 11: Using JSON with TTCN-3":"B.3.6 Use the Minus sign" assumptions for TTCN-3 Core Language spec
Description"B.3.6 Use the Minus sign" makes the assumption that TTCN-3 Core Language specification distinguishes signed +0/-0 integers and +0.0/-0.0 float values.
+
+In TTCN-3 Core Language specification "6.1.0 Simple basic types and values", under:
+ "a) integer: ..." it is stated that "the value zero shall be represented by a single zero" without specifying that it must be signed.
+
+float type description does not indicate any requirements for signed 0.0 value.
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7725.docx (144,285) 26-10-2017 10:14
http://oldforge.etsi.org/mantis/file_download.php?file_id=3707&type=bug
docx CR7725-v2.docx (162,983) 26-10-2017 13:38
http://oldforge.etsi.org/mantis/file_download.php?file_id=3715&type=bug
Issue History
Date ModifiedUsernameFieldChange
25-10-2017 12:00nikolajevNew Issue
26-10-2017 09:53Kristóf SzabadosNote Added: 0014879
26-10-2017 09:53Kristóf SzabadosAssigned To => Kristóf Szabados
26-10-2017 09:53Kristóf SzabadosStatusnew => assigned
26-10-2017 09:56Kristóf SzabadosNote Added: 0014880
26-10-2017 10:02Kristóf SzabadosStatusassigned => confirmed
26-10-2017 10:14Kristóf SzabadosFile Added: CR7725.docx
26-10-2017 10:18Kristóf SzabadosAssigned ToKristóf Szabados => Tomas Urban
26-10-2017 10:18Kristóf SzabadosStatusconfirmed => assigned
26-10-2017 10:18Kristóf SzabadosStatusassigned => confirmed
26-10-2017 13:38Tomas UrbanFile Added: CR7725-v2.docx
26-10-2017 13:41Tomas UrbanNote Added: 0014891
26-10-2017 13:41Tomas UrbanAssigned ToTomas Urban => Kristóf Szabados
27-10-2017 12:40Kristóf SzabadosNote Added: 0014914
27-10-2017 12:40Kristóf SzabadosStatusconfirmed => resolved
27-10-2017 12:40Kristóf SzabadosResolutionopen => fixed
27-10-2017 12:40Kristóf SzabadosAssigned ToKristóf Szabados => Gyorgy Rethy
04-01-2018 17:01Gyorgy RethyProjectTTCN-3 Change Requests => Part 11: Using JSON with TTCN-3
05-01-2018 09:19Gyorgy RethyNote Added: 0014999
05-01-2018 09:19Gyorgy RethyStatusresolved => closed
05-01-2018 09:19Gyorgy RethyProduct Version => V4.7.1 (published 2017-06)
05-01-2018 09:19Gyorgy RethyFixed in Version => V4.8.1 (published 2020-05)
05-01-2018 09:19Gyorgy RethyTarget Version => V4.8.1 (published 2020-05)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014879) +
+ Kristóf Szabados    +
+ 26-10-2017 09:53    +
+ 		+ + + + +
+ For float values the core standard allows the mantissa to be a negative integer.
+
+C.1.29 also gives an example:
+"str2float("-0.0") // returns a float value equal to -0.0"
+
+In section 7.1.3 Relational Operators states
+"Two floating-point numbers are equal if and only if they contain the same value. The values minus zero and
+plus zero are two distinct values (e.g. they are encoded differently in some standardized languages) and minus
+zero is less than plus zero, which represents zero."
+
+
+
+ + + + + + + + + + +
+ (0014880) +
+ Kristóf Szabados    +
+ 26-10-2017 09:56    +
+ 		+ + + + +
+ Section B.3.6 (Use the Minus sign) describes how to decode the different zero kinds by default and using the "useMinus" encoding instruction.
+
+But this part also describes that the -0 JSON value to be decoded as a negative 0 in TTCN-3.
+
+during STF discussion we decided to change this so that the -0 JSON value is decoded into the -0.0 TTCN-3 value.
+
+
+
+ + + + + + + + + + +
+ (0014891) +
+ Tomas Urban    +
+ 26-10-2017 13:41    +
+ 		+ + + + +
+ I made some additional changes to the text:
+1. Minus sign is always discarded during decoding of integer types
+2. The user has an option to use a float-point type instead (there's a note about that)
+3. The "useMinus" instruction is available for a float-point type values only.
+
+
+
+ + + + + + + + + + +
+ (0014914) +
+ Kristóf Szabados    +
+ 27-10-2017 12:40    +
+ 		+ + + + +
+ looks good to me.
+
+
+
+ + + + + + + + + + +
+ (0014999) +
+ Gyorgy Rethy    +
+ 05-01-2018 09:19    +
+ 		+ + + + +
+ Implemented with slight modification: first sentence in B.3.6 is clarified;
+old text: "By default, TTCN-3 values of JSON.Number and JSON.Integer and IEEE 754 float useful types are decoded by their values, i.e. ..." (but in fact JSON values are decoded TO JSON.Number ... types).
+new text: "By default, without the “useMinus” instruction, JSON numbers are decoded to TTCN-3 JSON.Number and IEEE 754 float useful types by their values; i.e. ..."
+
+ + diff --git a/docs/mantis/CR7726.md b/docs/mantis/CR7726.md new file mode 100644 index 0000000000000000000000000000000000000000..254db70e62503824e8ed3a1c8bca00b651bb104e --- /dev/null +++ b/docs/mantis/CR7726.md @@ -0,0 +1,131 @@ + + + + + + + + + + + + + 0007726: Naming rules for unions with default alternative (used in substitutions) - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007726Part 09: Using XML with TTCN-3Technicalpublic25-10-2017 15:1005-01-2018 11:10
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.8.1 (published 2017-05) 
Target Versionv4.9.1 (published 2018-05)Fixed in Versionv4.9.1 (published 2018-05) 
Clause Reference(s)8
For STF discussion
Source (company - Author)STF 533
Summary0007726: Naming rules for unions with default alternative (used in substitutions)
DescriptionThe CR 0007708 introduced new restrictions on names of alternatives in unions with a default alternative. These rules should be taken into account in the section on type and element substitution.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0007708closed Gyorgy Rethy Part 01: TTCN-3 Core Language Using dot notation with @default union values 
Attached Filesdocx CR7726-v1.docx (168,025) 25-10-2017 16:04
http://oldforge.etsi.org/mantis/file_download.php?file_id=3702&type=bug
Issue History
Date ModifiedUsernameFieldChange
25-10-2017 15:10Tomas UrbanNew Issue
25-10-2017 15:10Tomas UrbanStatusnew => assigned
25-10-2017 15:10Tomas UrbanAssigned To => Tomas Urban
25-10-2017 15:56Tomas UrbanRelationship addedrelated to 0007708
25-10-2017 16:04Tomas UrbanFile Added: CR7726-v1.docx
25-10-2017 16:05Tomas UrbanNote Added: 0014877
25-10-2017 16:05Tomas UrbanAssigned ToTomas Urban => Jacob Wieland - Spirent
25-10-2017 16:05Tomas UrbanStatusassigned => confirmed
26-10-2017 13:49Jacob Wieland - SpirentNote Added: 0014892
26-10-2017 13:49Jacob Wieland - SpirentStatusconfirmed => resolved
26-10-2017 13:49Jacob Wieland - SpirentFixed in Version => v4.8.1 (published 2017-05)
26-10-2017 13:49Jacob Wieland - SpirentResolutionopen => fixed
26-10-2017 13:50Jacob Wieland - SpirentStatusresolved => feedback
26-10-2017 13:50Jacob Wieland - SpirentResolutionfixed => reopened
26-10-2017 13:50Jacob Wieland - SpirentStatusfeedback => resolved
26-10-2017 13:50Jacob Wieland - SpirentResolutionreopened => fixed
26-10-2017 13:50Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
05-01-2018 11:10Gyorgy RethyNote Added: 0015007
05-01-2018 11:10Gyorgy RethyStatusresolved => closed
05-01-2018 11:10Gyorgy RethyFixed in Versionv4.8.1 (published 2017-05) => v4.9.1 (published 2018-05)
05-01-2018 11:10Gyorgy RethyTarget Version => v4.9.1 (published 2018-05)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014877) +
+ Tomas Urban    +
+ 25-10-2017 16:05    +
+ 		+ + + + +
+ Resolution uploaded. Please check.
+
+
+
+ + + + + + + + + + +
+ (0014892) +
+ Jacob Wieland - Spirent    +
+ 26-10-2017 13:49    +
+ 		+ + + + +
+ resolved in alliance with core language
+
+
+
+ + + + + + + + + + +
+ (0015007) +
+ Gyorgy Rethy    +
+ 05-01-2018 11:10    +
+ 		+ + + + +
+ Added to draft V4.8.3
+
+ + diff --git a/docs/mantis/CR7728.md b/docs/mantis/CR7728.md new file mode 100644 index 0000000000000000000000000000000000000000..64a2154b66b02e6d873c1b80e860dc1bb054f63e --- /dev/null +++ b/docs/mantis/CR7728.md @@ -0,0 +1,102 @@ + + + + + + + + + + + + + 0007728: OER support - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 07: Using ASN.1 with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007728Part 07: Using ASN.1 with TTCN-3New Featurepublic16-11-2017 11:3603-01-2018 16:53
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.6.1 (published 2017-05) 
Target Versionv4.7.1 (published 2018-05)Fixed in Versionv4.7.1 (published 2018-05) 
Clause Reference(s)12
Source (company - Author)Elvior
Summary0007728: OER support
DescriptionOctet encoding rules (OER, defined in ITU-T X.696) support should be added.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx es_20187307v040602.docx (286,813) 29-12-2017 15:18
http://oldforge.etsi.org/mantis/file_download.php?file_id=3728&type=bug
Issue History
Date ModifiedUsernameFieldChange
16-11-2017 11:36Tomas UrbanNew Issue
29-12-2017 15:17Gyorgy RethyNote Added: 0014948
29-12-2017 15:17Gyorgy RethyAssigned To => Gyorgy Rethy
29-12-2017 15:17Gyorgy RethyStatusnew => resolved
29-12-2017 15:17Gyorgy RethyResolutionopen => fixed
29-12-2017 15:17Gyorgy RethyFixed in Version => v4.7.1 (published 2018-05)
29-12-2017 15:17Gyorgy RethyTarget Version => v4.7.1 (published 2018-05)
29-12-2017 15:17Gyorgy RethyDescription Updatedbug_revision_view_page.php?rev_id=450#r450
29-12-2017 15:18Gyorgy RethyFile Added: es_20187307v040602.docx
29-12-2017 15:18Gyorgy RethyNote Edited: 0014948bug_revision_view_page.php?bugnote_id=14948#r452
29-12-2017 15:19Gyorgy RethyAssigned ToGyorgy Rethy => Tomas Urban
29-12-2017 15:19Gyorgy RethyStatusresolved => confirmed
03-01-2018 13:24Tomas UrbanNote Added: 0014991
03-01-2018 13:24Tomas UrbanStatusconfirmed => resolved
03-01-2018 13:24Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
03-01-2018 16:53Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014948) +
+ Gyorgy Rethy    +
+ 29-12-2017 15:17    +
(edited on: 29-12-2017 15:18)
+ 		+ + + + +
+ Done.
+Reference to X.696, the 'with encode' string "OER:2015" and OER short and long forms added to 'with variant' strings "length form 1" and "length form 2" respec tively.
+
+To be cross-checked.
+
+
+
+
+
+ + + + + + + + + + +
+ (0014991) +
+ Tomas Urban    +
+ 03-01-2018 13:24    +
+ 		+ + + + +
+ Fine by me. The proposal resolves the issue and it can be added to the next version of the specification.
+
+ + diff --git a/docs/mantis/CR7729.md b/docs/mantis/CR7729.md new file mode 100644 index 0000000000000000000000000000000000000000..33e0ffb28be24ee98d460f8d4abdd872996911ab --- /dev/null +++ b/docs/mantis/CR7729.md @@ -0,0 +1,264 @@ + + + + + + + + + + + + + 0007729: There seems to be a mistake in Example 4 on Page 108 (v4.9.1) - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007729Part 01: TTCN-3 Core LanguageEditorialpublic22-11-2017 13:2804-01-2019 16:45
ReporterPhilip Makedonski 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.8.1 (published 2016-07) 
Target Version4.11.1 (published 2019-05)Fixed in Version4.11.1 (published 2019-05) 
Clause Reference(s)Clause 8.2.3.1
Source (company - Author)     University of Göttingen, Philip Makedonski
Summary0007729: There seems to be a mistake in Example 4 on Page 108 (v4.9.1)
DescriptionThere seems to be a mistake in Example 4 in Clause 8.2.3.1 on Page 108 (v4.9.1):
+
+EXAMPLE 4: Name clash between enumerated values and global definitions
+module A {
+  type enumerated MyEnumType {enumX, enumY}
+  type enumerated MyEnumType2 {enumY, enumZ}
+}
+
+module B {
+  import from A all;
+  const MyEnumType enumY := enumX; // this is not allowed as enumerated values restrict
+                                                                     // global names (see clause 6.2.4)
+  const MyEnumType2 enumX := enumY; // this is likewise not allowed
+                                                                       // PM: WRONG! It should either be noted as allowed
+                                                                       // or changed to MyEnumType2 enumZ := enumY
+                                                                       // since MyEnumType2 does not contain enumX
+  const MyEnumType enumZ := enumX; // allowed as MyEnumType does not contain enumZ
+}
+
+I'm guessing what was intended was "const MyEnumType2 enumZ := enumY", especially, considering the fact that the same example continues with:
+
+module C {
+  import from A all;
+  import from B all;
+  const integer enumZ := 0;
+  const integer enumY := 1;
+  const MyEnumType2 enumX := enumY; // PM: this is identical to the example above and should be allowed
+  //...
+}
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7729.docx (183,748) 19-07-2018 10:03
http://oldforge.etsi.org/mantis/file_download.php?file_id=3772&type=bug
Issue History
Date ModifiedUsernameFieldChange
22-11-2017 13:28Philip MakedonskiNew Issue
24-11-2017 12:00Jacob Wieland - SpirentNote Added: 0014923
04-01-2018 17:27Gyorgy RethyNote Added: 0014997
05-01-2018 13:59Gyorgy RethyTarget Version => 4.11.1 (published 2019-05)
16-07-2018 13:27Jens GrabowskiNote Added: 0015127
16-07-2018 13:27Jens GrabowskiAssigned To => Jacob Wieland - Spirent
16-07-2018 13:27Jens GrabowskiStatusnew => assigned
19-07-2018 10:03Jacob Wieland - SpirentFile Added: CR7729.docx
19-07-2018 10:04Jacob Wieland - SpirentNote Added: 0015169
19-07-2018 10:04Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Tomas Urban
19-07-2018 10:04Jacob Wieland - SpirentStatusassigned => confirmed
19-07-2018 10:43Tomas UrbanNote Added: 0015170
19-07-2018 10:43Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
19-07-2018 10:43Tomas UrbanStatusconfirmed => resolved
04-01-2019 16:45Gyorgy RethyNote Added: 0015299
04-01-2019 16:45Gyorgy RethyStatusresolved => closed
04-01-2019 16:45Gyorgy RethyResolutionopen => fixed
04-01-2019 16:45Gyorgy RethyFixed in Version => 4.11.1 (published 2019-05)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014923) +
+ Jacob Wieland - Spirent    +
+ 24-11-2017 12:00    +
+ 		+ + + + +
+ I think the first examples were originally also in the same module as the enum type definitions and thus giving the module-prefix was not resolving the ambiguity (which is why that is disallowed).
+
+So, I think the complaint is correct.
+
+
+
+ + + + + + + + + + +
+ (0014997) +
+ Gyorgy Rethy    +
+ 04-01-2018 17:27    +
+ 		+ + + + +
+ I also think the CR is correct, if it can be agreed by mid January, could be corrected in the coming version V4.10.1.
+
+
+
+ + + + + + + + + + +
+ (0015127) +
+ Jens Grabowski    +
+ 16-07-2018 13:27    +
+ 		+ + + + +
+ STF discussion: CR is correct. Jacob will work on a proposal.
+
+
+
+ + + + + + + + + + +
+ (0015169) +
+ Jacob Wieland - Spirent    +
+ 19-07-2018 10:04    +
+ 		+ + + + +
+ please review, I simply changed the wrong comment
+
+
+
+ + + + + + + + + + +
+ (0015170) +
+ Tomas Urban    +
+ 19-07-2018 10:43    +
+ 		+ + + + +
+ Reviewed, no issues found. The proposal is ready to be added to the next version of the core language standard.
+
+
+
+ + + + + + + + + + +
+ (0015299) +
+ Gyorgy Rethy    +
+ 04-01-2019 16:45    +
+ 		+ + + + +
+ Added to draft V4.10.2
+
+ + diff --git a/docs/mantis/CR7730.md b/docs/mantis/CR7730.md new file mode 100644 index 0000000000000000000000000000000000000000..18793b7f7d4fbb72458ab072b36b6731acaa0574 --- /dev/null +++ b/docs/mantis/CR7730.md @@ -0,0 +1,75 @@ + + + + + + + + + + + + + 0007730: "not_a_number" is not listed as a keyword but is used as such - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007730Part 01: TTCN-3 Core LanguageEditorialpublic29-11-2017 12:3004-01-2018 17:13
ReporterKristóf Szabados 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.9.1 (published 2017-05) 
Target Versionv4.10.1 (published 2018-05)Fixed in Versionv4.10.1 (published 2018-05) 
Clause Reference(s)A.1.5.0, A.1.6.6
Source (company - Author)     L.M. Ericsson
Summary0007730: "not_a_number" is not listed as a keyword but is used as such
DescriptionThe special value "not_a_number" is not listed as keyword in table A.3
+
+But at the same time the BNF defines it as a keyword:
+"
+421.NaNKeyword ::= "not_a_number"
+"
+And the text of the standard consistently treats it as a keyword.
+For example:
+"seed is infinity, -infinity or not_a_number. "
+"The special values of the float type consist of infinity (positive infinity), -infinity (negative infinity) and the value not_a_number"
+" typefloat Wrong (-infinity .. not_a_number);"
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
29-11-2017 12:30Kristóf SzabadosNew Issue
04-01-2018 17:08Gyorgy RethyProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
04-01-2018 17:13Gyorgy RethyNote Added: 0014996
04-01-2018 17:13Gyorgy RethyAssigned To => Gyorgy Rethy
04-01-2018 17:13Gyorgy RethyStatusnew => closed
04-01-2018 17:13Gyorgy RethyResolutionopen => fixed
04-01-2018 17:13Gyorgy RethyProduct Version => v4.9.1 (published 2017-05)
04-01-2018 17:13Gyorgy RethyFixed in Version => v4.10.1 (published 2018-05)
04-01-2018 17:13Gyorgy RethyTarget Version => v4.10.1 (published 2018-05)
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014996) +
+ Gyorgy Rethy    +
+ 04-01-2018 17:13    +
+ 		+ + + + +
+ Implemented in V4.9.3.
+
+Problem existed, its resolution is trivial, resolved as proposed.
+
+ + diff --git a/docs/mantis/CR7731.md b/docs/mantis/CR7731.md new file mode 100644 index 0000000000000000000000000000000000000000..21c5f7982d6f8c77651018f1af7aab24ef49f0e8 --- /dev/null +++ b/docs/mantis/CR7731.md @@ -0,0 +1,746 @@ + + + + + + + + + + + + + 0007731: Draft document for Object-oriented Extension - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Object-oriented features (ES 203 790)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007731Ext Pack: Object-oriented features (ES 203 790)[All Projects] Generalpublic30-11-2017 10:3925-12-2018 11:18
ReporterJulien Deltour 
Assigned ToJens Grabowski 
PrioritynormalSeveritymajorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0007731: Draft document for Object-oriented Extension
DescriptionAggregate all documents written for object-oriented extension in one general draft document.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0007679closed Jens Grabowski Class Concept to be added 
related to 0007692closed Kristóf Szabados Exception handling with less code and less performance overhead 
related to 0007561closed Kristóf Szabados Allow finally block or shutdown hook 
Attached Filesdocx MTS-203790-00F_ed111v001.docx (246,510) 04-12-2017 15:34
http://oldforge.etsi.org/mantis/file_download.php?file_id=3725&type=bug
docx MTS-203790-00F_ed111v002.docx (207,918) 16-04-2018 14:08
http://oldforge.etsi.org/mantis/file_download.php?file_id=3736&type=bug
docx MTS-203790-00F_jw01.docx (216,497) 17-04-2018 11:54
http://oldforge.etsi.org/mantis/file_download.php?file_id=3737&type=bug
docx CR7731-TRI-TCI-1.docx (349,085) 17-04-2018 14:07
http://oldforge.etsi.org/mantis/file_download.php?file_id=3739&type=bug
docx MTS-203790-00F_jw_01_ksz01.docx (222,062) 17-04-2018 14:40
http://oldforge.etsi.org/mantis/file_download.php?file_id=3741&type=bug
docx MTS-203790-00F_jw_01_ksz02.docx (225,767) 17-04-2018 15:26
http://oldforge.etsi.org/mantis/file_download.php?file_id=3742&type=bug
docx CR7731-TRI-TCI-2.docx (280,144) 17-04-2018 15:46
http://oldforge.etsi.org/mantis/file_download.php?file_id=3743&type=bug
docx MTS-203790-00F_jw_02.docx (226,765) 17-04-2018 16:29
http://oldforge.etsi.org/mantis/file_download.php?file_id=3744&type=bug
docx CR7731-TRI-TCI-3.docx (353,577) 18-04-2018 08:26
http://oldforge.etsi.org/mantis/file_download.php?file_id=3745&type=bug
docx MTS-203790-00F_jw_03.docx (409,147) 18-04-2018 14:01
http://oldforge.etsi.org/mantis/file_download.php?file_id=3746&type=bug
docx MTS-203790-00F_jw_04.docx (327,041) 18-04-2018 14:47
http://oldforge.etsi.org/mantis/file_download.php?file_id=3748&type=bug
docx MTS-OO-Extension-Final.docx.docx (270,834) 07-05-2018 12:29
http://oldforge.etsi.org/mantis/file_download.php?file_id=3749&type=bug
docx OO-draft.docx (279,807) 16-07-2018 11:25
http://oldforge.etsi.org/mantis/file_download.php?file_id=3756&type=bug
Issue History
Date ModifiedUsernameFieldChange
30-11-2017 10:39Julien DeltourNew Issue
30-11-2017 10:39Julien DeltourStatusnew => assigned
30-11-2017 10:39Julien DeltourAssigned To => Julien Deltour
04-12-2017 15:34Julien DeltourFile Added: MTS-203790-00F_ed111v001.docx
04-12-2017 15:37Julien DeltourNote Added: 0014924
04-12-2017 15:37Julien DeltourStatusassigned => confirmed
04-12-2017 15:37Julien DeltourAssigned ToJulien Deltour => Jens Grabowski
04-12-2017 15:37Julien DeltourStatusconfirmed => assigned
04-12-2017 15:42Julien DeltourRelationship addedrelated to 0007679
28-03-2018 16:44Jacob Wieland - SpirentNote Added: 0015070
16-04-2018 09:44Jacob Wieland - SpirentNote Edited: 0015070bug_revision_view_page.php?bugnote_id=15070#r468
16-04-2018 10:09Jens GrabowskiNote Added: 0015076
16-04-2018 10:18Jens GrabowskiNote Added: 0015077
16-04-2018 10:32Jens GrabowskiNote Added: 0015078
16-04-2018 10:46Jens GrabowskiNote Added: 0015079
16-04-2018 12:10Jacob Wieland - SpirentNote Edited: 0015070bug_revision_view_page.php?bugnote_id=15070#r469
16-04-2018 13:44Jacob Wieland - SpirentNote Added: 0015082
16-04-2018 13:45Jacob Wieland - SpirentNote Edited: 0015082bug_revision_view_page.php?bugnote_id=15082#r471
16-04-2018 14:08Kristóf SzabadosFile Added: MTS-203790-00F_ed111v002.docx
16-04-2018 14:08Kristóf SzabadosNote Added: 0015083
16-04-2018 15:56Jacob Wieland - SpirentNote Edited: 0015070bug_revision_view_page.php?bugnote_id=15070#r472
16-04-2018 16:01Jacob Wieland - SpirentNote Edited: 0015070bug_revision_view_page.php?bugnote_id=15070#r473
17-04-2018 11:54Jacob Wieland - SpirentFile Added: MTS-203790-00F_jw01.docx
17-04-2018 11:55Jacob Wieland - SpirentNote Added: 0015091
17-04-2018 11:55Jacob Wieland - SpirentAssigned ToJens Grabowski => Kristóf Szabados
17-04-2018 13:10Jacob Wieland - SpirentNote Edited: 0015070bug_revision_view_page.php?bugnote_id=15070#r474
17-04-2018 13:15Jacob Wieland - SpirentNote Edited: 0015070bug_revision_view_page.php?bugnote_id=15070#r475
17-04-2018 14:07Tomas UrbanFile Added: CR7731-TRI-TCI-1.docx
17-04-2018 14:40Kristóf SzabadosFile Added: MTS-203790-00F_jw_01_ksz01.docx
17-04-2018 14:42Kristóf SzabadosNote Added: 0015093
17-04-2018 15:26Kristóf SzabadosFile Added: MTS-203790-00F_jw_01_ksz02.docx
17-04-2018 15:27Kristóf SzabadosNote Added: 0015095
17-04-2018 15:27Kristóf SzabadosAssigned ToKristóf Szabados => Jacob Wieland - Spirent
17-04-2018 15:46Jacob Wieland - SpirentFile Added: CR7731-TRI-TCI-2.docx
17-04-2018 16:29Jacob Wieland - SpirentFile Added: MTS-203790-00F_jw_02.docx
18-04-2018 07:49Kristóf SzabadosAssigned ToJacob Wieland - Spirent => Tomas Urban
18-04-2018 08:26Tomas UrbanFile Added: CR7731-TRI-TCI-3.docx
18-04-2018 08:34Kristóf SzabadosRelationship addedrelated to 0007692
18-04-2018 08:34Kristóf SzabadosRelationship addedrelated to 0007561
18-04-2018 10:22Jacob Wieland - SpirentNote Added: 0015099
18-04-2018 10:27Jacob Wieland - SpirentNote Edited: 0015099bug_revision_view_page.php?bugnote_id=15099#r477
18-04-2018 14:01Tomas UrbanFile Added: MTS-203790-00F_jw_03.docx
18-04-2018 14:42Jacob Wieland - SpirentFile Added: MTS-203790-00F_jw_04.docx
18-04-2018 14:47Jacob Wieland - SpirentFile Deleted: MTS-203790-00F_jw_04.docx
18-04-2018 14:47Jacob Wieland - SpirentFile Added: MTS-203790-00F_jw_04.docx
18-04-2018 15:03Tomas UrbanNote Added: 0015100
18-04-2018 15:03Tomas UrbanAssigned ToTomas Urban => Jens Grabowski
18-04-2018 15:03Tomas UrbanStatusassigned => confirmed
07-05-2018 12:28Jens GrabowskiStatusconfirmed => assigned
07-05-2018 12:29Jens GrabowskiFile Added: MTS-OO-Extension-Final.docx.docx
07-05-2018 12:30Jens GrabowskiNote Added: 0015101
07-05-2018 12:30Jens GrabowskiStatusassigned => closed
07-05-2018 12:30Jens GrabowskiResolutionopen => fixed
16-07-2018 11:24Jacob Wieland - SpirentAssigned ToJens Grabowski => Kristof.Szabados
16-07-2018 11:24Jacob Wieland - SpirentNote Added: 0015122
16-07-2018 11:24Jacob Wieland - SpirentStatusclosed => feedback
16-07-2018 11:24Jacob Wieland - SpirentResolutionfixed => reopened
16-07-2018 11:25Jacob Wieland - SpirentFile Added: OO-draft.docx
17-07-2018 12:32Kristóf SzabadosAssigned ToKristof.Szabados => Kristóf Szabados
17-07-2018 12:32Kristóf SzabadosStatusfeedback => assigned
17-07-2018 12:32Kristóf SzabadosNote Added: 0015148
17-07-2018 12:32Kristóf SzabadosStatusassigned => feedback
08-10-2018 14:53Jens GrabowskiAssigned ToKristóf Szabados => Jens Grabowski
08-10-2018 14:53Jens GrabowskiStatusfeedback => assigned
09-10-2018 09:23Jens GrabowskiNote Added: 0015216
09-10-2018 09:23Jens GrabowskiStatusassigned => resolved
09-10-2018 09:23Jens GrabowskiResolutionreopened => fixed
25-12-2018 11:18Jens GrabowskiNote Added: 0015293
25-12-2018 11:18Jens GrabowskiStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014924) +
+ Julien Deltour    +
+ 04-12-2017 15:37    +
+ 		+ + + + +
+ Uploaded a draft document for object oriented extension.
+This draft has been build from document of following CRs :
+6801, 7679, 7692, 7693
+
+
+
+ + + + + + + + + + +
+ (0015070) +
+ Jacob Wieland - Spirent    +
+ 28-03-2018 16:44    +
(edited on: 17-04-2018 13:15)
+ 		+ + + + +
+ BNF:
+
+/** Changed Rules **/
+RelOp ::= "<" | ">" | ">=" | "<=" | OfKeyword
+ConfigurationOps ::=
+   CreateOp |
+   SelfOp |
+   SystemKeyword |
+   MTCKeyword |
+   RunningOp |
+   AliveOp |
+   ThisOp |
+   SuperOp
+
+StructuredTypeDef ::=
+   RecordDef |
+   UnionDef |
+   SetDef |
+   RecordOfDef |
+   SetOfDef |
+   EnumDef |
+   PortDef |
+   ComponentDef |
+   ClassDef
+
+PredefinedType ::=
+   BitStringKeyword |
+   BooleanKeyword |
+   CharStringKeyword |
+   UniversalCharString |
+   IntegerKeyword |
+   OctetStringKeyword |
+   HexStringKeyword |
+   VerdictTypeKeyword |
+   FloatKeyword |
+   AddressKeyword |
+   DefaultKeyword |
+   AnyTypeKeyword |
+   ObjectType
+
+/** New Rules **/
+ClassDef ::= [ ExternalKeyword ]
+             ClassKeyword
+             [ FinalModifier | AbstractModifier ]
+             Identifier
+             [ExtendsKeyword Type]
+             [RunsOnSpec] [MtcSpec] [SystemSpec]
+             "{" ClassMemberList "}"
+             [FinallyKeyword StatementBlock]
+
+ClassKeyword ::= "class"
+ThisOp ::= "this"
+SuperOp ::= "super"
+FinalModifier ::= "@final"
+AbstractModifier ::= "@abstract"
+FinallyKeyword ::= "finally"
+ObjectType ::= "object"
+
+ClassMemberList ::= {ClassMember [WithStatement] [SemiColon]}
+
+ClassMember ::=
+   [MemberVisibility]
+   (VarInstance |
+   TimerInstance |
+   ConstDef |
+   TemplateDef |
+   ClassFunctionDef |
+   ConstructorDef)
+   
+MemberVisibility ::=
+   "public" |
+   "protected" |
+   "private"
+
+ClassFunctionDef ::= [ExternalKeyword] FunctionKeyword
+                     [FinalModifier | AbstractModifier]
+                     [DeterministicModifier]
+                     Identifier
+                     "(" [FunctionFormalParList] ")"
+                     [ReturnType] [StatementBlock]
+
+ConstructorDef ::= CreateKeyword "(" FunctionFormalParList ")"
+                   [":" FunctionInstance] [StatementBlock]
+
+
+
+
+
+ + + + + + + + + + +
+ (0015076) +
+ Jens Grabowski    +
+ 16-04-2018 10:09    +
+ 		+ + + + +
+ Cast operator ":" vs. "=>", to be checked by Kristof and Jacob.
+
+
+
+ + + + + + + + + + +
+ (0015077) +
+ Jens Grabowski    +
+ 16-04-2018 10:18    +
+ 		+ + + + +
+ Jacob: Is check method call involving casts allowed on statement level?
+
+
+
+ + + + + + + + + + +
+ (0015078) +
+ Jens Grabowski    +
+ 16-04-2018 10:32    +
+ 		+ + + + +
+ Jacob/Kristof: Basic Object Type to be added, BNF to be extended
+
+
+
+ + + + + + + + + + +
+ (0015079) +
+ Jens Grabowski    +
+ 16-04-2018 10:46    +
+ 		+ + + + +
+ STF discussion on Logging of Components: go for simple solution.
+
+
+
+ + + + + + + + + + +
+ (0015082) +
+ Jacob Wieland - Spirent    +
+ 16-04-2018 13:44    +
(edited on: 16-04-2018 13:45)
+ 		+ + + + +
+ To allow a method call syntactially, the rule
+
+FunctionRef ::= [Identifier Dot] (Identifier | PreDefFunctionIdentifier)
+
+should be changed to
+
+FunctionRef ::= [(Identifier | ObjectInstance) Dot] (Identifier | PreDefFunctionIdentifier)
+
+ObjectInstance ::= (ExtendedIdentifier | FunctionInstance) [ExtendedFieldReference]
+
+
+
+
+
+ + + + + + + + + + +
+ (0015083) +
+ Kristóf Szabados    +
+ 16-04-2018 14:08    +
+ 		+ + + + +
+ fixed some wording issues in the exception handling part.
+
+
+
+ + + + + + + + + + +
+ (0015091) +
+ Jacob Wieland - Spirent    +
+ 17-04-2018 11:55    +
+ 		+ + + + +
+ updated object oriented features according to agreements, deleted some sections that are not yet relevant
+
+
+
+ + + + + + + + + + +
+ (0015093) +
+ Kristóf Szabados    +
+ 17-04-2018 14:42    +
+ 		+ + + + +
+ Some types corrected, BNF changes related to Object Orientation included, component visibility part deleted.
+
+The changes due to all statementblock can have catch and finally are still on the way.
+
+
+
+ + + + + + + + + + +
+ (0015095) +
+ Kristóf Szabados    +
+ 17-04-2018 15:27    +
+ 		+ + + + +
+ The changes due to all statementblock can have catch and finally are now in the text.
+Please review.
+
+
+
+ + + + + + + + + + +
+ (0015099) +
+ Jacob Wieland - Spirent    +
+ 18-04-2018 10:22    +
(edited on: 18-04-2018 10:27)
+ 		+ + + + +
+ The (pseudo) definition for the builtin object class:
+
+type class @abstract @builtin object {
+  public function toString() return universal charstring;
+}
+
+
+
+
+
+ + + + + + + + + + +
+ (0015100) +
+ Tomas Urban    +
+ 18-04-2018 15:03    +
+ 		+ + + + +
+ The main part of the document is ready. Please check, add the preamble and prepare it for releasing.
+
+
+
+ + + + + + + + + + +
+ (0015101) +
+ Jens Grabowski    +
+ 07-05-2018 12:30    +
+ 		+ + + + +
+ Resolution in File, uploaded in MTS DRAFT area for approval.
+
+
+
+ + + + + + + + + + +
+ (0015122) +
+ Jacob Wieland - Spirent    +
+ 16-07-2018 11:24    +
+ 		+ + + + +
+ please confirm acceptability of changes
+
+
+
+ + + + + + + + + + +
+ (0015148) +
+ Kristóf Szabados    +
+ 17-07-2018 12:32    +
+ 		+ + + + +
+ just moved the feedback request to my current account.
+
+
+
+ + + + + + + + + + +
+ (0015216) +
+ Jens Grabowski    +
+ 09-10-2018 09:23    +
+ 		+ + + + +
+ Document has gone for final editing.
+
+
+
+ + + + + + + + + + +
+ (0015293) +
+ Jens Grabowski    +
+ 25-12-2018 11:18    +
+ 		+ + + + +
+ Document is published
+
+ + diff --git a/docs/mantis/CR7733.md b/docs/mantis/CR7733.md new file mode 100644 index 0000000000000000000000000000000000000000..f57d1fba40febc85312f32eb59b5908b5d932225 --- /dev/null +++ b/docs/mantis/CR7733.md @@ -0,0 +1,167 @@ + + + + + + + + + + + + + 0007733: Dynamic match and default parameter values - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Advanced Matching (ES 203 022)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007733Ext Pack: Advanced Matching (ES 203 022)Clarificationpublic06-12-2017 11:5805-01-2019 12:08
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Versionv1.3.1 (ongoing) 
Clause Reference(s)5.1
Source (company - Author)Elvior
TS version?
Summary0007733: Dynamic match and default parameter values
DescriptionThe short notation for dynamic matching is defined as @dynamic FunctionRef where FunctionRef is a reference to a Boolean function with a single parameter compatible with the template's type.
+
+In my opinion, the rule is too restrictive. It should also allow functions with more than 1 parameter if all parameters following the first one have a default value.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7733-1.docx (134,032) 17-07-2018 10:17
http://oldforge.etsi.org/mantis/file_download.php?file_id=3761&type=bug
Issue History
Date ModifiedUsernameFieldChange
06-12-2017 11:58Tomas UrbanNew Issue
16-07-2018 13:11Jens GrabowskiAssigned To => Tomas Urban
16-07-2018 13:11Jens GrabowskiStatusnew => assigned
16-07-2018 13:12Jens GrabowskiNote Added: 0015123
17-07-2018 10:17Tomas UrbanFile Added: CR7733-1.docx
17-07-2018 10:17Tomas UrbanNote Added: 0015141
17-07-2018 10:17Tomas UrbanAssigned ToTomas Urban => Jacob Wieland - Spirent
17-07-2018 10:17Tomas UrbanStatusassigned => confirmed
19-07-2018 08:40Jacob Wieland - SpirentNote Added: 0015166
19-07-2018 08:40Jacob Wieland - SpirentStatusconfirmed => resolved
19-07-2018 08:40Jacob Wieland - SpirentFixed in Version => Next Version
19-07-2018 08:40Jacob Wieland - SpirentResolutionopen => fixed
19-07-2018 10:30Jens GrabowskiAssigned ToJacob Wieland - Spirent => Jens Grabowski
19-07-2018 10:30Jens GrabowskiStatusresolved => assigned
19-07-2018 10:30Jens GrabowskiStatusassigned => resolved
05-01-2019 12:08Gyorgy RethyNote Added: 0015317
05-01-2019 12:08Gyorgy RethyStatusresolved => closed
05-01-2019 12:08Gyorgy RethyAssigned ToJens Grabowski => Gyorgy Rethy
05-01-2019 12:08Gyorgy RethyFixed in Version => v1.3.1 (ongoing)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015123) +
+ Jens Grabowski    +
+ 16-07-2018 13:12    +
+ 		+ + + + +
+ Tomas, please develop proposal.
+
+
+
+ + + + + + + + + + +
+ (0015141) +
+ Tomas Urban    +
+ 17-07-2018 10:17    +
+ 		+ + + + +
+ Proposal uploaded, please check.
+
+
+
+ + + + + + + + + + +
+ (0015166) +
+ Jacob Wieland - Spirent    +
+ 19-07-2018 08:40    +
+ 		+ + + + +
+ ok
+
+
+
+ + + + + + + + + + +
+ (0015317) +
+ Gyorgy Rethy    +
+ 05-01-2019 12:08    +
+ 		+ + + + +
+ Added to draft v1.2.2
+
+ + diff --git a/docs/mantis/CR7734.md b/docs/mantis/CR7734.md new file mode 100644 index 0000000000000000000000000000000000000000..efba7256af110bd82dd17ff2fbe56686f9b7a53e --- /dev/null +++ b/docs/mantis/CR7734.md @@ -0,0 +1,245 @@ + + + + + + + + + + + + + 0007734: Runs on in dynamic matching - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Advanced Matching (ES 203 022)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007734Ext Pack: Advanced Matching (ES 203 022)Clarificationpublic06-12-2017 12:1205-01-2019 12:10
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv1.1.1 (published 2017-07) 
Target VersionFixed in Versionv1.3.1 (ongoing) 
Clause Reference(s)5.1
Source (company - Author)Elvior
TS version?
Summary0007734: Runs on in dynamic matching
DescriptionThere are no rules for referencing functions with the runs on clause in the dynamic matching mechanism.
+
+The specification should clearly state if it is allowed or not. Probably it is easier not to allow it, otherwise there should be additional rules:
+1. Error when used for matching on incompatible component
+2. Read access to component variables (it should be safe as the component variables are not destroyed during component lifetime)
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7734.docx (123,605) 17-07-2018 08:16
http://oldforge.etsi.org/mantis/file_download.php?file_id=3757&type=bug
Issue History
Date ModifiedUsernameFieldChange
06-12-2017 12:12Tomas UrbanNew Issue
07-12-2017 08:46Tomas UrbanNote Added: 0014926
16-07-2018 13:19Jens GrabowskiNote Added: 0015124
16-07-2018 13:20Jens GrabowskiAssigned To => Jacob Wieland - Spirent
16-07-2018 13:20Jens GrabowskiStatusnew => assigned
16-07-2018 13:20Jens GrabowskiNote Added: 0015125
17-07-2018 08:16Jacob Wieland - SpirentFile Added: CR7734.docx
17-07-2018 08:17Jacob Wieland - SpirentNote Added: 0015138
17-07-2018 08:17Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Tomas Urban
17-07-2018 08:17Jacob Wieland - SpirentStatusassigned => confirmed
18-07-2018 13:25Tomas UrbanNote Added: 0015160
18-07-2018 13:25Tomas UrbanStatusconfirmed => resolved
18-07-2018 13:25Tomas UrbanResolutionopen => fixed
18-07-2018 13:25Tomas UrbanAssigned ToTomas Urban => Jens Grabowski
05-01-2019 12:10Gyorgy RethyNote Added: 0015318
05-01-2019 12:10Gyorgy RethyStatusresolved => closed
05-01-2019 12:10Gyorgy RethyAssigned ToJens Grabowski => Gyorgy Rethy
05-01-2019 12:10Gyorgy RethyFixed in Version => v1.3.1 (ongoing)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014926) +
+ Tomas Urban    +
+ 07-12-2017 08:46    +
+ 		+ + + + +
+ Elvior currently uses the following extension rules for the runs on issue:
+
+1. The function referenced in the short version of the @dynamic matching mechanism can have the runs clause. Such a matching mechanism is allowed to be declared only on compatible components (i.e. in a function, altstep, test case with a compatible component in the "runs on" clause or in a component type declaration).
+
+2. When using the verbose version of the @dynamic matching mechanism, an anonymous function is created from the statement block. This function has an implicit runs on block when it was created in a code running on a component (i.e. in a function, altstep, test case with a "runs on" clause or in a component type declaration).
+
+3. Component variable references are allowed on the RHS of assignments.
+
+4. An error is generated when an actual template parameter of a function used in the component.start operation contains a @dynamic matching mechanism that invokes a function with a "runs on" clause containing a component type that is incompatible with the PTC being started.
+
+
+
+ + + + + + + + + + +
+ (0015124) +
+ Jens Grabowski    +
+ 16-07-2018 13:19    +
+ 		+ + + + +
+ STF discussion: Runs on clause shall not be used in dynamic matching functions in order to avoid side effects.
+
+
+
+ + + + + + + + + + +
+ (0015125) +
+ Jens Grabowski    +
+ 16-07-2018 13:20    +
+ 		+ + + + +
+ Jacob to add restriction.
+
+
+
+ + + + + + + + + + +
+ (0015138) +
+ Jacob Wieland - Spirent    +
+ 17-07-2018 08:17    +
+ 		+ + + + +
+ please review
+
+
+
+ + + + + + + + + + +
+ (0015160) +
+ Tomas Urban    +
+ 18-07-2018 13:25    +
+ 		+ + + + +
+ Reviewed, no issues found. The proposal can be added to the next version of the extension package.
+
+
+
+ + + + + + + + + + +
+ (0015318) +
+ Gyorgy Rethy    +
+ 05-01-2019 12:10    +
+ 		+ + + + +
+ Added to draft v1.2.2
+
+ + diff --git a/docs/mantis/CR7737.md b/docs/mantis/CR7737.md new file mode 100644 index 0000000000000000000000000000000000000000..c92325bb7ccb222ee6d10371beb0af01db08eabc --- /dev/null +++ b/docs/mantis/CR7737.md @@ -0,0 +1,207 @@ + + + + + + + + + + + + + 0007737: Padding bits in encvalue_o result and decvalue_o input - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007737Part 01: TTCN-3 Core LanguageTechnicalpublic15-12-2017 14:4704-01-2019 16:48
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.9.1 (published 2017-05) 
Target Version4.11.1 (published 2019-05)Fixed in Version4.11.1 (published 2019-05) 
Clause Reference(s)C.5.5, C.5.6
Source (company - Author)Elvior
Summary0007737: Padding bits in encvalue_o result and decvalue_o input
DescriptionThe specification doesn't explain how padding bits are handled by the encvalue_o and decvalue_o functions in bit-oriented encodings. I assume that padding bits are located at the end of the octetstring, but the specification should state that explicitly.
+
+The specification should also mention what the content of the padding bits should be, especially if they shall be set to zero (error when 1 is detected during decoding) or if 1s are allowed too.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7737.docx (157,368) 19-07-2018 13:30
http://oldforge.etsi.org/mantis/file_download.php?file_id=3777&type=bug
docx CR7737-2.docx (177,120) 19-07-2018 13:43
http://oldforge.etsi.org/mantis/file_download.php?file_id=3778&type=bug
Issue History
Date ModifiedUsernameFieldChange
15-12-2017 14:47Tomas UrbanNew Issue
15-12-2017 15:20Jacob Wieland - SpirentNote Added: 0014944
15-12-2017 15:20Jacob Wieland - SpirentNote Edited: 0014944bug_revision_view_page.php?rev_id=448
18-12-2017 16:39Jacob Wieland - SpirentNote Added: 0014945
19-12-2017 15:15Jacob Wieland - SpirentNote Deleted: 0014944
19-12-2017 15:15Jacob Wieland - SpirentNote Deleted: 0014945
19-12-2017 15:23Jacob Wieland - SpirentNote Added: 0014946
05-01-2018 13:59Gyorgy RethyProduct Version => v4.9.1 (published 2017-05)
05-01-2018 13:59Gyorgy RethyTarget Version => 4.11.1 (published 2019-05)
16-07-2018 13:36Jens GrabowskiNote Added: 0015128
16-07-2018 13:37Jens GrabowskiAssigned To => Jacob Wieland - Spirent
16-07-2018 13:37Jens GrabowskiStatusnew => assigned
19-07-2018 12:44Jacob Wieland - SpirentNote Added: 0015175
19-07-2018 12:44Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Tomas Urban
19-07-2018 12:44Jacob Wieland - SpirentStatusassigned => confirmed
19-07-2018 13:30Jacob Wieland - SpirentFile Added: CR7737.docx
19-07-2018 13:43Tomas UrbanFile Added: CR7737-2.docx
19-07-2018 13:44Tomas UrbanNote Added: 0015178
19-07-2018 13:44Tomas UrbanStatusconfirmed => resolved
19-07-2018 13:44Tomas UrbanResolutionopen => fixed
19-07-2018 13:44Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
04-01-2019 16:48Gyorgy RethyNote Added: 0015300
04-01-2019 16:48Gyorgy RethyStatusresolved => closed
04-01-2019 16:48Gyorgy RethyFixed in Version => 4.11.1 (published 2019-05)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0014946) +
+ Jacob Wieland - Spirent    +
+ 19-12-2017 15:23    +
+ 		+ + + + +
+ From our tool vendors' discussion, I think there was consensus that the normal case is padding to the right. That would be consistent with the result of tciEncodeValue which delivers a TriMessage which contains a left-aligned byte-array and the the bit-length.
+
+Thus, it would make sense to also expose the bit-length information to the TTCN-3 layer via an additional out parameter. If someone wants to turn the left-alignment to right-alignment, all they need to do is rotate the value by length-minus-bit-length to the right.
+
+var integer bitlength;
+var octetstring o := encvalue_o(v, bitlength := bitlength);
+o := bit2oct(oct2bit(o) @> (lengthof(o)*8-bitlength))
+
+
+
+ + + + + + + + + + +
+ (0015128) +
+ Jens Grabowski    +
+ 16-07-2018 13:36    +
+ 		+ + + + +
+ STF discussion: Clarification needed.
+
+
+
+ + + + + + + + + + +
+ (0015175) +
+ Jacob Wieland - Spirent    +
+ 19-07-2018 12:44    +
+ 		+ + + + +
+ please review
+
+
+
+ + + + + + + + + + +
+ (0015178) +
+ Tomas Urban    +
+ 19-07-2018 13:44    +
+ 		+ + + + +
+ Reviewed, one minor correction made (mod instead of % for the modulo operation). The updated proposal can be added to the new version of the core language specification.
+
+
+
+ + + + + + + + + + +
+ (0015300) +
+ Gyorgy Rethy    +
+ 04-01-2019 16:48    +
+ 		+ + + + +
+ Added to draft V4.10.2
+
+ + diff --git a/docs/mantis/CR7738.md b/docs/mantis/CR7738.md new file mode 100644 index 0000000000000000000000000000000000000000..5fd7db52e81f19e9f737077832122488b73f4e0b --- /dev/null +++ b/docs/mantis/CR7738.md @@ -0,0 +1,137 @@ + + + + + + + + + + + + + 0007738: TriMessage should be enhanced with a stream-like API - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007738Part 06: TTCN-3 Control InterfaceNew Featurepublic19-12-2017 15:4316-01-2019 12:42
ReporterJacob Wieland - Spirent 
Assigned ToTomas Urban 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.9.1(ongoing) 
Target VersionNext version (to be defined)Fixed in VersionNext version (to be defined) 
Clause Reference(s)6.3.2.5, 8.5.2.8, 9.4.2.6
Source (company - Author)Spirent - Jacob Wieland
Summary0007738: TriMessage should be enhanced with a stream-like API
DescriptionAt the moment, the contents of TriMessage can be accessed/configured via byte-arrays. While this approach is fine for short messages, it can become very tedious/inefficient in cases where the message is very large (several MB) is fragmented (arrives in chunks) needs to be processed in a stream-like fashion (as normally every codec does).
+
+To that end, I would propose to add an API to TriMessage which allows fragmented filling of the message and one which allows accessing only parts of the message without having to copy the whole message first.
+
+If that is the case, implementations of TriMessage can internally hold the data anyway they want as long as they allow access to it and potentially the whole data never needs to be copied.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7738-TRI-1.docx (140,216) 18-07-2018 13:06
http://oldforge.etsi.org/mantis/file_download.php?file_id=3768&type=bug
docx CR7738-TCI-1.docx (169,079) 18-07-2018 13:06
http://oldforge.etsi.org/mantis/file_download.php?file_id=3769&type=bug
Issue History
Date ModifiedUsernameFieldChange
19-12-2017 15:43Jacob Wieland - SpirentNew Issue
06-06-2018 09:18Jacob Wieland - SpirentNote Added: 0015109
16-07-2018 14:37Jens GrabowskiAssigned To => Tomas Urban
16-07-2018 14:37Jens GrabowskiStatusnew => assigned
18-07-2018 13:06Tomas UrbanFile Added: CR7738-TRI-1.docx
18-07-2018 13:06Tomas UrbanFile Added: CR7738-TCI-1.docx
18-07-2018 13:06Tomas UrbanNote Added: 0015158
18-07-2018 13:06Tomas UrbanAssigned ToTomas Urban => Jacob Wieland - Spirent
18-07-2018 13:06Tomas UrbanStatusassigned => confirmed
19-07-2018 09:09Jacob Wieland - SpirentNote Added: 0015168
19-07-2018 09:09Jacob Wieland - SpirentStatusconfirmed => resolved
19-07-2018 09:09Jacob Wieland - SpirentFixed in Version => Next version (to be defined)
19-07-2018 09:09Jacob Wieland - SpirentResolutionopen => fixed
19-07-2018 09:09Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Tomas Urban
16-01-2019 12:42Tomas UrbanStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015109) +
+ Jacob Wieland - Spirent    +
+ 06-06-2018 09:18    +
+ 		+ + + + +
+ The same problems can also occur for any string-type, e.g. for octetstrings representing big files/attachments. Therefore, the OctetStringValue api (and similar) should als be enhanced with stream-based functionality so that it can be filled from a stream and also the contents read by a stream.
+
+This allows implementations to more efficiently store the data dependent on the memory-management of their platform (chunked, file-based etc.) and thus allows handling of much larger strings than is often possible until now.
+
+
+
+ + + + + + + + + + +
+ (0015158) +
+ Tomas Urban    +
+ 18-07-2018 13:06    +
+ 		+ + + + +
+ Proposal uploaded. Please check.
+
+
+
+ + + + + + + + + + +
+ (0015168) +
+ Jacob Wieland - Spirent    +
+ 19-07-2018 09:09    +
+ 		+ + + + +
+ changes are fine
+
+ + diff --git a/docs/mantis/CR7739.md b/docs/mantis/CR7739.md new file mode 100644 index 0000000000000000000000000000000000000000..b4291e293e1c8bd3b9270ad26da7e00b0a5477a5 --- /dev/null +++ b/docs/mantis/CR7739.md @@ -0,0 +1,167 @@ + + + + + + + + + + + + + 0007739: Error in the example on dynamic matching - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Advanced Matching (ES 203 022)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007739Ext Pack: Advanced Matching (ES 203 022)Editorialpublic20-12-2017 15:5105-01-2019 12:12
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Versionv1.3.1 (ongoing) 
Clause Reference(s)5.1
Source (company - Author)Elvior
TS version?
Summary0007739: Error in the example on dynamic matching
DescriptionThe example on dynamic matching references two external functions. However, these functions are non-deterministic, thus not allowed (restriction 5.1.c referencing restriction 16.1.4.e of the core language specification).
+
+Proposal: add the @deterministic modifier to all external functions defined in the example.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7739-1.docx (133,804) 17-07-2018 10:50
http://oldforge.etsi.org/mantis/file_download.php?file_id=3763&type=bug
Issue History
Date ModifiedUsernameFieldChange
20-12-2017 15:51Tomas UrbanNew Issue
16-07-2018 13:21Jens GrabowskiAssigned To => Tomas Urban
16-07-2018 13:21Jens GrabowskiStatusnew => assigned
16-07-2018 13:22Jens GrabowskiNote Added: 0015126
17-07-2018 10:50Tomas UrbanFile Added: CR7739-1.docx
17-07-2018 10:50Tomas UrbanNote Added: 0015144
17-07-2018 10:50Tomas UrbanAssigned ToTomas Urban => Jacob Wieland - Spirent
17-07-2018 10:50Tomas UrbanStatusassigned => confirmed
19-07-2018 08:34Jacob Wieland - SpirentNote Added: 0015165
19-07-2018 08:34Jacob Wieland - SpirentStatusconfirmed => resolved
19-07-2018 08:34Jacob Wieland - SpirentFixed in Version => Next Version
19-07-2018 08:34Jacob Wieland - SpirentResolutionopen => fixed
19-07-2018 08:34Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Jens Grabowski
05-01-2019 12:12Gyorgy RethyNote Added: 0015319
05-01-2019 12:12Gyorgy RethyStatusresolved => closed
05-01-2019 12:12Gyorgy RethyAssigned ToJens Grabowski => Gyorgy Rethy
05-01-2019 12:12Gyorgy RethyFixed in Version => v1.3.1 (ongoing)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015126) +
+ Jens Grabowski    +
+ 16-07-2018 13:22    +
+ 		+ + + + +
+ Resolution agreed, develop proposal.
+
+
+
+ + + + + + + + + + +
+ (0015144) +
+ Tomas Urban    +
+ 17-07-2018 10:50    +
+ 		+ + + + +
+ Proposal uploaded, please check.
+
+
+
+ + + + + + + + + + +
+ (0015165) +
+ Jacob Wieland - Spirent    +
+ 19-07-2018 08:34    +
+ 		+ + + + +
+ looks fine
+
+
+
+ + + + + + + + + + +
+ (0015319) +
+ Gyorgy Rethy    +
+ 05-01-2019 12:12    +
+ 		+ + + + +
+ Added to draft v1.2.2
+
+ + diff --git a/docs/mantis/CR7742.md b/docs/mantis/CR7742.md new file mode 100644 index 0000000000000000000000000000000000000000..377beea108b316d5ea9bb5359b4793f20eddb836 --- /dev/null +++ b/docs/mantis/CR7742.md @@ -0,0 +1,274 @@ + + + + + + + + + + + + + 0007742: Allow passing instances of templates with out parameters/value redirects as specially marked actual template in parameters - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Advanced Matching (ES 203 022)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007742Ext Pack: Advanced Matching (ES 203 022)New Featurepublic25-01-2018 17:0305-01-2019 12:26
ReporterJacob Wieland - Spirent 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Versionv1.3.1 (ongoing) 
Clause Reference(s)?
Source (company - Author)Spirent - Jacob Wieland
TS version1
Summary0007742: Allow passing instances of templates with out parameters/value redirects as specially marked actual template in parameters
DescriptionAt the moment, instances of templates with out parameters or inline templates with value redirects are allowed to be used only in a match operation, select case or receive operation template.
+
+They cannot be assigned to variables or returned from a function.
+The reason for this is that if that were allowed, it cannot be controlled where the template ends up and whether the variables bound to it are still valid at the point when the template is used for matching.
+
+This restriction should be lessened to allow passing such template instances to template-in-parameters of functions with a special modifier (e.g. @redirect or @match). Such in parameters would be subject to the same restriction as these instances have, i.e. they can be used only for matching or as @match-in-parameters of called functions.
+
+Any template instance using a @match-parameter automatically becomes a redirect template and thus is also limited to these restrictions.
Steps To ReproduceWe had a use-case with a deeply nested template with several decmatch-layers where each layer potentially could contribute redirected values.
+
+At the moment, it is not possible to pass an instance of such a template to a general-purpose function which tries to receive a message matching the template and deal with timeouts or other messages in a different way.
+
+Since that template-instance lives only as long (or shorter) as the variables it uses as its out parameters, there is no harm in such a usage and thus it should be allowed.
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7742.docx (374,856) 11-10-2018 11:34
http://oldforge.etsi.org/mantis/file_download.php?file_id=3801&type=bug
docx CR7742-v2.docx (427,898) 11-10-2018 15:15
http://oldforge.etsi.org/mantis/file_download.php?file_id=3803&type=bug
Issue History
Date ModifiedUsernameFieldChange
25-01-2018 17:03Jacob Wieland - SpirentNew Issue
16-07-2018 13:40Jens GrabowskiNote Added: 0015129
16-07-2018 13:41Jens GrabowskiAssigned To => Jacob Wieland - Spirent
16-07-2018 13:41Jens GrabowskiStatusnew => assigned
11-10-2018 09:15Jacob Wieland - SpirentNote Added: 0015246
11-10-2018 11:34Jacob Wieland - SpirentFile Added: CR7742.docx
11-10-2018 11:36Jacob Wieland - SpirentNote Added: 0015252
11-10-2018 11:36Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Tomas Urban
11-10-2018 11:36Jacob Wieland - SpirentStatusassigned => confirmed
11-10-2018 15:15Tomas UrbanFile Added: CR7742-v2.docx
11-10-2018 15:16Tomas UrbanNote Added: 0015257
11-10-2018 15:16Tomas UrbanAssigned ToTomas Urban => Jacob Wieland - Spirent
11-10-2018 16:48Jacob Wieland - SpirentNote Added: 0015261
11-10-2018 16:48Jacob Wieland - SpirentStatusconfirmed => resolved
11-10-2018 16:48Jacob Wieland - SpirentResolutionopen => fixed
11-10-2018 16:48Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Tomas Urban
11-10-2018 16:48Jacob Wieland - SpirentAssigned ToTomas Urban => Jens Grabowski
11-10-2018 16:48Jacob Wieland - SpirentStatusresolved => feedback
11-10-2018 16:48Jacob Wieland - SpirentResolutionfixed => reopened
11-10-2018 16:48Jacob Wieland - SpirentStatusfeedback => resolved
11-10-2018 16:48Jacob Wieland - SpirentResolutionreopened => fixed
05-01-2019 12:26Gyorgy RethyNote Added: 0015320
05-01-2019 12:26Gyorgy RethyStatusresolved => closed
05-01-2019 12:26Gyorgy RethyAssigned ToJens Grabowski => Gyorgy Rethy
05-01-2019 12:26Gyorgy RethyFixed in Version => v1.3.1 (ongoing)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015129) +
+ Jens Grabowski    +
+ 16-07-2018 13:40    +
+ 		+ + + + +
+ STF discussion: Some examples are needed.
+
+
+
+ + + + + + + + + + +
+ (0015246) +
+ Jacob Wieland - Spirent    +
+ 11-10-2018 09:15    +
+ 		+ + + + +
+ Suppose you have a general purpose function
+
+function f_receiveMessage(template(present) MsgType p_expectedMsg, out MsgType p_result) runs on Mtc return MsgType {
+   timer t := 5.0;
+   t.start;
+   alt {
+   [] msgPort.receive(p_expectedMsg) -> value p_result { }
+   [] msgPort.receive { setverdict(fail); }
+   [] t.timeout { setverdict(inconc); }
+   }
+}
+
+You then have a template with variable assignments of type MsgType
+
+template MsgType mySpecialTemplate(out integer p_deepNestedField) := {
+
+... ... ... ... ? -> p_deepNestedField
+... ... ... ...
+}
+
+Now, because of the out parameter, it's not possible to call
+
+f_receiveMessage(mySpecialTemplate(v_fieldresult), v_msg)
+
+even though the template instance mySpecialTemplate(v_fieldresult) lives only as long as the function call (and never longer than the scope of v_fieldResult, if it is a local variable because you cannot return such an inline template).
+
+The purpose of the CR is to allow adding a @match modifier in front of parameters and variables so that they are allowed to store templates that can only be used for matching and assignment to variables/parameters that also have the @match modifier and nothing else.
+
+The restriction that templates with out parameters/contained redirect symbols cannot be used as actual parameters can be lessened with the exception that they can be used as in parameters with modifier @match.
+
+
+
+ + + + + + + + + + +
+ (0015252) +
+ Jacob Wieland - Spirent    +
+ 11-10-2018 11:36    +
+ 		+ + + + +
+ I have uploaded a proposal which both restricts the general passing around of value-retrieval templates (which wasn't done properly before now) and allows special cases when the newly introduced @match modifier is used.
+
+Please review
+
+
+
+ + + + + + + + + + +
+ (0015257) +
+ Tomas Urban    +
+ 11-10-2018 15:16    +
+ 		+ + + + +
+ I made some modifications to the first proposal. Please check.
+
+
+
+ + + + + + + + + + +
+ (0015261) +
+ Jacob Wieland - Spirent    +
+ 11-10-2018 16:48    +
+ 		+ + + + +
+ Changes are fine. I consider this resolved.
+
+
+
+ + + + + + + + + + +
+ (0015320) +
+ Gyorgy Rethy    +
+ 05-01-2019 12:26    +
+ 		+ + + + +
+ Added to draft v1.2.2
+
+ + diff --git a/docs/mantis/CR7754.md b/docs/mantis/CR7754.md new file mode 100644 index 0000000000000000000000000000000000000000..85b282dbce6ccdd58ff5c86931754d28c1536b78 --- /dev/null +++ b/docs/mantis/CR7754.md @@ -0,0 +1,447 @@ + + + + + + + + + + + + + 0007754: Clarify initialization of constants and module parameters - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007754Part 01: TTCN-3 Core LanguageClarificationpublic08-03-2018 09:3204-01-2019 16:53
ReporterThilo Lauer 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.9.1 (published 2017-05) 
Target VersionFixed in Version4.11.1 (published 2019-05) 
Clause Reference(s)ES 201 873-1 v4.9.1
Source (company - Author)Devoteam - Thilo Lauer
Summary0007754: Clarify initialization of constants and module parameters
DescriptionClarification required on following subject:
+
+The current standard version does not clearly define, wheather initialization of a constant with module parameters is allowed or not.
+
+If constant initializations by module parameters shall be permitted, than the semantic for default values of such module parameters needs to be clarified.
+
+Example 1:
+
+  modulepar integer px_int1 := tsc_const1 + 3;
+  modulepar integer px_int2; // note: no default value assigned here!
+  const integer tsc_const1 := px_int2;
+
+Should this example be allowed and what is the semantic of it?
+
+Notes:
+- px_int2 must be provided at runtime (e.g. by a module-parameter file)
+- px_int1 could be provided at runtime, but if not, it can be computed by
+  the default-expression
+- tsc_const1 must be computed at runtime as its value depends on
+  module parameters
+- if px_int2 value is NOT provided at runtime, should this lead to
+  an error message anyway or only if px_int1, px_int2, tsc_const1 are
+  really used in a test run?
+  And should there be a warning issued at compile time, that this may
+  lead to an error at runtime?
+
+If it should be allowed to init a constant by module parameter values, what about the following example:
+
+Example 2:
+
+  modulepar integer px_int3 := tsc_const2 + 3;
+  const integer tsc_const2 := px_int3;
+
+
+Our clarification suggestion would be:
+- module parameters can be initialized by using constants, but
+- constant values SHALL NOT depend on module parameters
+
+A clarification would be helpful here.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR-7754 Clarify initialization of constants and module parameters.docx (69,445) 19-07-2018 11:07
http://oldforge.etsi.org/mantis/file_download.php?file_id=3774&type=bug
Issue History
Date ModifiedUsernameFieldChange
08-03-2018 09:32Thilo LauerNew Issue
08-03-2018 13:09Jacob Wieland - SpirentNote Added: 0015063
16-07-2018 13:48Jens GrabowskiNote Added: 0015130
16-07-2018 13:49Jens GrabowskiAssigned To => Jens Grabowski
16-07-2018 13:49Jens GrabowskiStatusnew => assigned
18-07-2018 10:39Jens GrabowskiNote Added: 0015156
18-07-2018 11:02Jens GrabowskiNote Added: 0015157
18-07-2018 15:08Jens GrabowskiNote Added: 0015164
19-07-2018 11:01Jens GrabowskiNote Added: 0015171
19-07-2018 11:07Jens GrabowskiFile Added: CR-7754 Clarify initialization of constants and module parameters.docx
19-07-2018 11:08Jens GrabowskiNote Added: 0015173
19-07-2018 11:08Jens GrabowskiAssigned ToJens Grabowski => Tomas Urban
19-07-2018 11:08Jens GrabowskiStatusassigned => confirmed
19-07-2018 13:29Tomas UrbanNote Added: 0015177
19-07-2018 13:29Tomas UrbanStatusconfirmed => resolved
19-07-2018 13:29Tomas UrbanResolutionopen => fixed
19-07-2018 13:29Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
04-01-2019 16:53Gyorgy RethyNote Added: 0015301
04-01-2019 16:53Gyorgy RethyStatusresolved => closed
04-01-2019 16:53Gyorgy RethyFixed in Version => 4.11.1 (published 2019-05)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015063) +
+ Jacob Wieland - Spirent    +
+ 08-03-2018 13:09    +
+ 		+ + + + +
+ I think the actual issue here is the circularity of the default values (const-value being used that is also dependent on that usage).
+
+That, of course, must be disallowed (and probably is).
+
+Otherwise, I see no problem with non-circular usage between constants and modulepar-defaults.
+
+In essence, modulepars are just constants with an unknown value at compile-time, so a constant filled with something depending on a modulepar is also just a constant with an unknown value.
+
+Thus, if it would be allowed for two modulepars, why would it not be allowed for a combination of const and modulepar?
+
+Constants are just values that are initialized once (at the latest before their first usage) and never changed afterwards (during the life-cycle of a testsystem or at least a single testcase-run).
+
+The same is true for modulepars with the additional feature that they can be configured explicitly and can be provided a default value.
+
+
+
+ + + + + + + + + + +
+ (0015130) +
+ Jens Grabowski    +
+ 16-07-2018 13:48    +
+ 		+ + + + +
+ STF discussion: Check standard regarding current rules.
+
+
+
+ + + + + + + + + + +
+ (0015156) +
+ Jens Grabowski    +
+ 18-07-2018 10:39    +
+ 		+ + + + +
+ The example
+
+Example 2:
+
+  modulepar integer px_int3 := tsc_const2 + 3;
+  const integer tsc_const2 := px_int3;
+
+
+is not allowed. The general clause "5.5 Cyclic Definitions" should apply.
+(The notions "definition" and "declaration" of variables, constants, types and other language elements are used interchangeably.)
+
+
+
+ + + + + + + + + + +
+ (0015157) +
+ Jens Grabowski    +
+ 18-07-2018 11:02    +
+ 		+ + + + +
+ > Example 1:
+>
+> modulepar integer px_int1 := tsc_const1 + 3;
+> modulepar integer px_int2; // note: no default value assigned here!
+> const integer tsc_const1 := px_int2;
+>
+> Should this example be allowed and what is the semantic of it?
+>
+> Notes:
+> - px_int2 must be provided at runtime (e.g. by a module-parameter file)
+
+YES
+
+> - px_int1 could be provided at runtime, but if not, it can be computed by
+> the default-expression
+
+YES
+
+> - tsc_const1 must be computed at runtime as its value depends on
+> module parameters
+
+YES
+
+> - if px_int2 value is NOT provided at runtime, should this lead to
+> an error message anyway or only if px_int1, px_int2, tsc_const1 are
+> really used in a test run?
+
+The standard states:
+"If the test system does not provide an actual runtime value for a module parameter, the default value shall be used during test execution, otherwise the actual value provided by the test system."
+I.e., the otherwise part applies, but includes a least a typo. I believe the words "shall be" are missing. The correction needs a discussion within the STF.
+
+
+> And should there be a warning issued at compile time, that this may
+> lead to an error at runtime?
+
+A warning is a tool specific issue. The standard cannot prescribe the tool capabilities. However, note may be added.
+
+
+
+ + + + + + + + + + +
+ (0015164) +
+ Jens Grabowski    +
+ 18-07-2018 15:08    +
+ 		+ + + + +
+ STF discussion:
+
+Restriction "The expression shall evaluate to a value, which is at least partially initialized." has to be added to constant declaration section.
+
+Add sentence to Clause 8.2.0: Module definitions can be evaluated at runtime and can be evaluated in any order. A definition shall be evaluated latest before the first reference to it.
+
+Add note: If a definition is not used, it may not be evaluated at all.
+
+
+
+ + + + + + + + + + +
+ (0015171) +
+ Jens Grabowski    +
+ 19-07-2018 11:01    +
+ 		+ + + + +
+ The CR is resolved as follows:
+
+In Clause "10 Declaring constants" the restriction
+
+"d) The right hand side of the assignment that initializes a constant shall evaluate to an object that is at least partially initialized."
+
+In the "Semantic Description" part of Clause "8.2.0 General" behind the sentence "Definitions in the module definitions part may be made in any order." the following sentences an note have been added:
+
+"Module definitions can be evaluated at runtime and can be evaluated in any order. A definition shall be evaluated latest before the first reference to it.
+
+NOTE: If a definition is not used, it may not be evaluated at all."
+
+The circularity of the default values is covered by Clause "5.5 Cyclic Definitions".
+
+
+
+ + + + + + + + + + +
+ (0015173) +
+ Jens Grabowski    +
+ 19-07-2018 11:08    +
+ 		+ + + + +
+ Tomas, please crosscheck.
+
+
+
+ + + + + + + + + + +
+ (0015177) +
+ Tomas Urban    +
+ 19-07-2018 13:29    +
+ 		+ + + + +
+ Reviewed, no issues found. The proposal is ready to be added to the next version of the core language specification.
+
+
+
+ + + + + + + + + + +
+ (0015301) +
+ Gyorgy Rethy    +
+ 04-01-2019 16:53    +
+ 		+ + + + +
+ Added to draft V4.10.2
+
+ + diff --git a/docs/mantis/CR7757.md b/docs/mantis/CR7757.md new file mode 100644 index 0000000000000000000000000000000000000000..a393cd124000805c4fc4d491ce688a1e73b95f61 --- /dev/null +++ b/docs/mantis/CR7757.md @@ -0,0 +1,133 @@ + + + + + + + + + + + + + 0007757: the mapping of \s in pattern facets uses wrong ASCII code for SPACE - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007757Part 09: Using XML with TTCN-3Editorialpublic06-04-2018 14:3505-01-2019 10:19
ReporterJacob Wieland - Spirent 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.8.1 (published 2017-05) 
Target Versionv4.9.1 (published 2018-05)Fixed in Versionv4.10.1 (published 2019-05) 
Clause Reference(s)6.1.4
For STF discussion
Source (company - Author)Spirent - Jacob Wieland
Summary0007757: the mapping of \s in pattern facets uses wrong ASCII code for SPACE
Descriptionin table 3 (section 6.1.4) the mapping of \s and \S is defined.
+
+Both mappings use \q{0,0,0,20} instead of the correct \q{0,0,0,32}.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR_7757.docx (143,339) 17-07-2018 11:09
http://oldforge.etsi.org/mantis/file_download.php?file_id=3766&type=bug
Issue History
Date ModifiedUsernameFieldChange
06-04-2018 14:35Jacob Wieland - SpirentNew Issue
16-07-2018 13:49Jens GrabowskiAssigned To => Kristóf Szabados
16-07-2018 13:49Jens GrabowskiStatusnew => assigned
17-07-2018 11:09Kristóf SzabadosFile Added: CR_7757.docx
18-07-2018 07:53Kristóf SzabadosNote Added: 0015150
18-07-2018 07:53Kristóf SzabadosAssigned ToKristóf Szabados => Jacob Wieland - Spirent
18-07-2018 07:53Kristóf SzabadosStatusassigned => confirmed
19-07-2018 08:43Jacob Wieland - SpirentNote Added: 0015167
19-07-2018 08:43Jacob Wieland - SpirentStatusconfirmed => resolved
19-07-2018 08:43Jacob Wieland - SpirentFixed in Version => v4.10.1 (published 2019-05)
19-07-2018 08:43Jacob Wieland - SpirentResolutionopen => fixed
20-07-2018 09:32Jens GrabowskiAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
20-07-2018 09:32Jens GrabowskiStatusresolved => assigned
20-07-2018 09:33Jens GrabowskiStatusassigned => resolved
05-01-2019 10:19Gyorgy RethyNote Added: 0015313
05-01-2019 10:19Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015150) +
+ Kristóf Szabados    +
+ 18-07-2018 07:53    +
+ 		+ + + + +
+ please check the proposed changes.
+
+
+
+ + + + + + + + + + +
+ (0015167) +
+ Jacob Wieland - Spirent    +
+ 19-07-2018 08:43    +
+ 		+ + + + +
+ looks ok to me
+
+
+
+ + + + + + + + + + +
+ (0015313) +
+ Gyorgy Rethy    +
+ 05-01-2019 10:19    +
+ 		+ + + + +
+ Added to draft V4.9.2
+
+ + diff --git a/docs/mantis/CR7761.md b/docs/mantis/CR7761.md new file mode 100644 index 0000000000000000000000000000000000000000..7c80f6d7d4313f8ac3ce54c8cb05b8e4834e0ecd --- /dev/null +++ b/docs/mantis/CR7761.md @@ -0,0 +1,97 @@ + + + + + + + + + + + + + 0007761: Template name in the example on overwriting rules - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007761Part 01: TTCN-3 Core LanguageEditorialpublic09-05-2018 09:4204-01-2019 16:55
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeveritytrivialReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.10.1 (published 2018-05) 
Target VersionFixed in Version4.11.1 (published 2019-05) 
Clause Reference(s)27.1.2.0
Source (company - Author)STF 548
Summary0007761: Template name in the example on overwriting rules
DescriptionIn the description of the example 6 of the clause 27.1.2.0, there's a small typo: the text "mw_msg_template" should be changed to "mw_msg template" (i.e. the underline symbol should be removed).
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR-7761-Template name in the example on overwriting rules.docx (71,439) 17-07-2018 11:03
http://oldforge.etsi.org/mantis/file_download.php?file_id=3765&type=bug
Issue History
Date ModifiedUsernameFieldChange
09-05-2018 09:42Tomas UrbanNew Issue
09-05-2018 09:44Tomas UrbanSummaryTemplate name in the example => Template name in the example on overwriting rules
16-07-2018 13:50Jens GrabowskiAssigned To => Jens Grabowski
16-07-2018 13:50Jens GrabowskiStatusnew => assigned
17-07-2018 11:03Jens GrabowskiFile Added: CR-7761-Template name in the example on overwriting rules.docx
17-07-2018 11:04Jens GrabowskiNote Added: 0015147
17-07-2018 11:04Jens GrabowskiStatusassigned => resolved
17-07-2018 11:04Jens GrabowskiResolutionopen => fixed
17-07-2018 11:04Jens GrabowskiAssigned ToJens Grabowski => Gyorgy Rethy
04-01-2019 16:55Gyorgy RethyNote Added: 0015302
04-01-2019 16:55Gyorgy RethyStatusresolved => closed
04-01-2019 16:55Gyorgy RethyFixed in Version => 4.11.1 (published 2019-05)
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015147) +
+ Jens Grabowski    +
+ 17-07-2018 11:04    +
+ 		+ + + + +
+ See resolution
+
+
+
+ + + + + + + + + + +
+ (0015302) +
+ Gyorgy Rethy    +
+ 04-01-2019 16:55    +
+ 		+ + + + +
+ Added to draft V4.10.2
+
+ + diff --git a/docs/mantis/CR7763.md b/docs/mantis/CR7763.md new file mode 100644 index 0000000000000000000000000000000000000000..6db13030b2c74e8fc9de2172c20658ad66271afa --- /dev/null +++ b/docs/mantis/CR7763.md @@ -0,0 +1,279 @@ + + + + + + + + + + + + + 0007763: add support for sending erroneous messages - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Advanced Matching (ES 203 022)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007763Ext Pack: Advanced Matching (ES 203 022)New Featurepublic15-05-2018 09:3105-01-2019 14:06
ReporterKristóf Szabados 
Assigned ToGyorgy Rethy 
PrioritynormalSeveritymajorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Versionv1.3.1 (ongoing) 
Clause Reference(s)27
Source (company - Author)L.M. Ericsson
TS version
Summary0007763: add support for sending erroneous messages
DescriptionNegative testing is a part of testing when the tester send incorrect/malformed messages to the SUT, to see how it will react.
+
+TTCN-3 currently is not able to support this kind of testing, as it is only able to send correctly encoded messages. But supporting this kind of operation is needed, to ensure the high quality of the tested systems.
+
+To support this behaviour 2 (a static and a dynamic) support for negativ testing would be needed.
+Please note, that:
+- this would only need to have an effect on the transfer syntax of the send messages, the abstract values does not need to be changed.
+- As these incorrect messages are used to test the SUT, it is not needed for the codecs to support decoding them.
+- Also as this is special way of coding data, while it should be handled similar to alrady existing encoding/variant attributes ... it would be better have a new attribute kind for it.
+
+Support for static negativ testing:
+  The request here is to be able to tell the system, that during encoding the message needs to be altered in some user specified way.
+  This only needs to apply values and templates of record, set, record of, set of and union types.
+  Currently we have identified the following needs:
+  - inserting some data before a field in the encoded message.
+  - overwriting the encoded value of a field (also setting mandatory fields to omit)
+  - inserting some extra data after the encoded value of a field.
+  For example:
+    template CX_Frame t_CX_Frame:=
+    {
+        data_length:=0,
+        data_stream:='AAABBCCDDEEFF1122‘O
+    } with
+    {
+    erroneous (data_length) “after(raw) := 'FF'O “;
+    erroneous (data_length) “value(raw) := 'AABBCC'O “;
+        erroneous (data_length) “before(raw) := 'FF'O “;
+     }
+    Would like this encoded: ‘FFAABBCCFFAAABBCCDDEEFF112’O
+    /* the data_length fields encoded value is replaced by 'AABBCC' and also prefixed and postfixed with 'FF'O */
+  This static encoding has the benefits of being static (efficiently optimizable before execution) and for its attributes the mechanisms existing for encode/variant attributes can be used.
+
+Support for dynamic negativ testing:
+  Extending the static support for negativ testing, it would also be needed to have a machanism for dynamically altering the erroneous attributes of values and templates.
+  for example having a value like:
+  "const MyRec c_myrec := { i:=1, b:=true }
+    with {
+      erroneous (i) “before := 123”
+      erroneous (b) “value := omit”
+    }
+  "
+  Inside the body of functions, altsteps, testcases these attributes could be updated like:
+  - @update(c_myrec) with { erroneous(i) “value := 3.5” } // the field i's value shall be overwritten, but nothing is inserted before field i and field b is also not omitted.
+  - @update(c_myrec); // no longer erroneous, all arreneous attributes are removed
+
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0007785closed Jens Grabowski Add Mutation annotations to the Value data type 
Attached Filesdocx CR7763.docx (123,228) 17-07-2018 16:45
http://oldforge.etsi.org/mantis/file_download.php?file_id=3767&type=bug
docx CR7763-2.docx (133,303) 20-07-2018 09:01
http://oldforge.etsi.org/mantis/file_download.php?file_id=3783&type=bug
Issue History
Date ModifiedUsernameFieldChange
15-05-2018 09:31Kristóf SzabadosNew Issue
15-05-2018 09:34Kristóf SzabadosNote Added: 0015102
16-07-2018 14:06Jens GrabowskiNote Added: 0015131
16-07-2018 14:07Jens GrabowskiAssigned To => Tomas Urban
16-07-2018 14:07Jens GrabowskiStatusnew => assigned
16-07-2018 14:09Kristóf SzabadosProjectTTCN-3 Change Requests => Ext Pack: Advanced Matching (ES 203 022)
17-07-2018 13:50Tomas UrbanAssigned ToTomas Urban => Kristóf Szabados
17-07-2018 13:50Tomas UrbanAssigned ToKristóf Szabados => Jacob Wieland - Spirent
17-07-2018 16:45Jacob Wieland - SpirentFile Added: CR7763.docx
17-07-2018 16:46Jacob Wieland - SpirentNote Added: 0015149
19-07-2018 16:02Jacob Wieland - SpirentRelationship addedrelated to 0007785
20-07-2018 09:01Jacob Wieland - SpirentFile Added: CR7763-2.docx
20-07-2018 09:01Jacob Wieland - SpirentNote Added: 0015185
20-07-2018 09:01Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Kristóf Szabados
20-07-2018 09:01Jacob Wieland - SpirentStatusassigned => confirmed
17-11-2018 15:18Kristóf SzabadosNote Added: 0015278
17-11-2018 15:18Kristóf SzabadosStatusconfirmed => resolved
17-11-2018 15:18Kristóf SzabadosResolutionopen => fixed
17-11-2018 15:18Kristóf SzabadosAssigned ToKristóf Szabados => Jens Grabowski
05-01-2019 14:06Gyorgy RethyNote Added: 0015321
05-01-2019 14:06Gyorgy RethyStatusresolved => closed
05-01-2019 14:06Gyorgy RethyAssigned ToJens Grabowski => Gyorgy Rethy
05-01-2019 14:06Gyorgy RethyFixed in Version => v1.3.1 (ongoing)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015102) +
+ Kristóf Szabados    +
+ 15-05-2018 09:34    +
+ 		+ + + + +
+ Please note that this would enable fuzz testing in TTCN-3.
+As a fuzzer algorithm could automatically craft and send messages involving invalid, unexpected or even random data as the input for the SUT.
+
+
+
+ + + + + + + + + + +
+ (0015131) +
+ Jens Grabowski    +
+ 16-07-2018 14:06    +
+ 		+ + + + +
+ STF discussion: Interesting feature, feature should be made for flexible. Feature should go to Advanced Matching Ext. package.
+
+
+
+ + + + + + + + + + +
+ (0015149) +
+ Jacob Wieland - Spirent    +
+ 17-07-2018 16:46    +
+ 		+ + + + +
+ uploaded a first draft of a description of mutation annotation templates
+
+
+
+ + + + + + + + + + +
+ (0015185) +
+ Jacob Wieland - Spirent    +
+ 20-07-2018 09:01    +
+ 		+ + + + +
+ please review the latest draft
+
+
+
+ + + + + + + + + + +
+ (0015278) +
+ Kristóf Szabados    +
+ 17-11-2018 15:18    +
+ 		+ + + + +
+ looks fine for me, can be included in the next version.
+
+
+
+ + + + + + + + + + +
+ (0015321) +
+ Gyorgy Rethy    +
+ 05-01-2019 14:06    +
+ 		+ + + + +
+ Added to draft v1.2.2 as new clause 5.6!
+
+ + diff --git a/docs/mantis/CR7764.md b/docs/mantis/CR7764.md new file mode 100644 index 0000000000000000000000000000000000000000..264ddcb4e78eb808bba0af6e24ba49a7374d512b --- /dev/null +++ b/docs/mantis/CR7764.md @@ -0,0 +1,97 @@ + + + + + + + + + + + + + 0007764: Syntax error in example on attributes with AllRef - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007764Part 01: TTCN-3 Core LanguageEditorialpublic15-05-2018 14:4304-01-2019 16:58
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeveritytrivialReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version4.11.1 (published 2019-05) 
Target VersionFixed in Version4.11.1 (published 2019-05) 
Clause Reference(s)27.2
Source (company - Author)STF 548
Summary0007764: Syntax error in example on attributes with AllRef
DescriptionThe example in the clause 27.2 contains a syntax error. It uses parentheses for the identifier list in the except part of the AllRef section while curly brackets should be used (BNF rule 478).
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR-7764-Syntax error in example on attributes with AllRef.docx (67,333) 17-07-2018 10:53
http://oldforge.etsi.org/mantis/file_download.php?file_id=3764&type=bug
Issue History
Date ModifiedUsernameFieldChange
15-05-2018 14:43Tomas UrbanNew Issue
16-07-2018 14:10Jens GrabowskiAssigned To => Jens Grabowski
16-07-2018 14:10Jens GrabowskiStatusnew => assigned
17-07-2018 10:53Jens GrabowskiFile Added: CR-7764-Syntax error in example on attributes with AllRef.docx
17-07-2018 10:54Jens GrabowskiNote Added: 0015145
17-07-2018 10:54Jens GrabowskiStatusassigned => resolved
17-07-2018 10:54Jens GrabowskiResolutionopen => fixed
17-07-2018 10:54Jens GrabowskiAssigned ToJens Grabowski => Gyorgy Rethy
04-01-2019 16:58Gyorgy RethyNote Added: 0015303
04-01-2019 16:58Gyorgy RethyStatusresolved => closed
04-01-2019 16:58Gyorgy RethyFixed in Version => 4.11.1 (published 2019-05)
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015145) +
+ Jens Grabowski    +
+ 17-07-2018 10:54    +
+ 		+ + + + +
+ See resolution
+
+
+
+ + + + + + + + + + +
+ (0015303) +
+ Gyorgy Rethy    +
+ 04-01-2019 16:58    +
+ 		+ + + + +
+ Added to V4.10.2
+
+ + diff --git a/docs/mantis/CR7765.md b/docs/mantis/CR7765.md new file mode 100644 index 0000000000000000000000000000000000000000..8a7a4592904e8616e515b226e1d360db580b59ae --- /dev/null +++ b/docs/mantis/CR7765.md @@ -0,0 +1,175 @@ + + + + + + + + + + + + + 0007765: add discard state to the states of ports with translation capability - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Config & Deployment Support (ES 202 781)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007765Ext Pack: Config & Deployment Support (ES 202 781)New Featurepublic24-05-2018 07:4605-01-2019 10:44
ReporterKristóf Szabados 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Versionv1.7.1 (published 2019-04) 
Clause Reference(s)5.2.4
Source (company - Author)L.M. Ericsson
TS versionn/a
Summary0007765: add discard state to the states of ports with translation capability
DescriptionAccording to the current standards ports with translation cabailities can be of several states: unset, not translated, fragmanted, translated, partially translated.
+This list should be extended with the "discarded" state.
+
+It is very usefull in testing to discard some of the incoming messages, that would just complicate the testing logic on TTCN-3 level.
+Right now using translation ports this is possible, but when the writer of the translation function wants to indicate the discarding of a message ... the port has to be set to the state of "fragmented".
+
+Which is very confusing.
+For users the translation port being in the fragmented state indicates, that there is some incoming message, that needs to be handled, but has not fully arrived yet (and so might need special attention).
+While having a "discarded" state would clearly indicate, that the message was descarded intentionally, and no extra attention is needed.
+/*basically the first version indicates incompleteness or some sort of error, while the discarded state indicates a deliberate and correct decision */
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR_7765.docx (159,787) 18-07-2018 13:23
http://oldforge.etsi.org/mantis/file_download.php?file_id=3770&type=bug
docx CR_7765-2.docx (179,053) 18-07-2018 13:27
http://oldforge.etsi.org/mantis/file_download.php?file_id=3771&type=bug
Issue History
Date ModifiedUsernameFieldChange
24-05-2018 07:46Kristóf SzabadosNew Issue
16-07-2018 14:20Jens GrabowskiNote Added: 0015132
16-07-2018 14:20Jens GrabowskiAssigned To => Kristóf Szabados
16-07-2018 14:20Jens GrabowskiStatusnew => assigned
18-07-2018 08:05Kristóf SzabadosNote Added: 0015152
18-07-2018 08:05Kristóf SzabadosAssigned ToKristóf Szabados => Tomas Urban
18-07-2018 08:05Kristóf SzabadosStatusassigned => confirmed
18-07-2018 13:23Kristóf SzabadosFile Added: CR_7765.docx
18-07-2018 13:27Tomas UrbanFile Added: CR_7765-2.docx
18-07-2018 13:29Tomas UrbanNote Added: 0015161
18-07-2018 13:29Tomas UrbanStatusconfirmed => resolved
18-07-2018 13:29Tomas UrbanResolutionopen => fixed
18-07-2018 13:29Tomas UrbanAssigned ToTomas Urban => Jens Grabowski
05-01-2019 10:44Gyorgy RethyNote Added: 0015314
05-01-2019 10:44Gyorgy RethyStatusresolved => closed
05-01-2019 10:44Gyorgy RethyAssigned ToJens Grabowski => Gyorgy Rethy
05-01-2019 10:44Gyorgy RethyFixed in Version => v1.7.1 (published 2019-04)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015132) +
+ Jens Grabowski    +
+ 16-07-2018 14:20    +
+ 		+ + + + +
+ STF dicussion: Proposal ok, Kristof will develop proposal.
+
+
+
+ + + + + + + + + + +
+ (0015152) +
+ Kristóf Szabados    +
+ 18-07-2018 08:05    +
+ 		+ + + + +
+ Please check.
+
+
+
+ + + + + + + + + + +
+ (0015161) +
+ Tomas Urban    +
+ 18-07-2018 13:29    +
+ 		+ + + + +
+ Reviewed. There are no major concerns, I only made two typo corrections. The proposal is ready to be added to the next version of the extension package.
+
+
+
+ + + + + + + + + + +
+ (0015314) +
+ Gyorgy Rethy    +
+ 05-01-2019 10:44    +
+ 		+ + + + +
+ Added to draft v4.6.2
+
+ + diff --git a/docs/mantis/CR7766.md b/docs/mantis/CR7766.md new file mode 100644 index 0000000000000000000000000000000000000000..94242365bd92f22211b3509b924b82cfa81f0722 --- /dev/null +++ b/docs/mantis/CR7766.md @@ -0,0 +1,223 @@ + + + + + + + + + + + + + 0007766: enumeration items should accept any value that can be statically evaluated to an integer - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007766Part 01: TTCN-3 Core LanguageNew Featurepublic24-05-2018 12:4306-01-2019 08:58
ReporterKristóf Szabados 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version4.11.1 (published 2019-05) 
Clause Reference(s)6.2.4
Source (company - Author)L.M. Ericsson
Summary0007766: enumeration items should accept any value that can be statically evaluated to an integer
DescriptionIn the current standard enumeration items can have user specified values. But only integer numeric values.
+
+Actually it would be possible and usefull for user, to allow using any value that can be evaluated and converted to an integer number statically.
+
+For example:
+const integer c_int := 45;
+const bitstring c_bit := '10101111'B;
+
+type enumerated MyEnum {
+  e_num (1),
+  e_bin ('10'B),
+  e_oct ('12'O),
+  e_hex ('AB'H),
+  e_bin_conv (bit2int('0111'B)),
+  e_oct_conv (oct2int('34'O)),
+  e_hex_conv (hex2int('AC'H)),
+  e_num_const (c_int),
+  e_bin_const (c_bit)
+}
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR_7766.docx (164,136) 17-07-2018 10:12
http://oldforge.etsi.org/mantis/file_download.php?file_id=3758&type=bug
docx CR_7766-2.docx (186,559) 19-07-2018 11:02
http://oldforge.etsi.org/mantis/file_download.php?file_id=3773&type=bug
Issue History
Date ModifiedUsernameFieldChange
24-05-2018 12:43Kristóf SzabadosNew Issue
05-06-2018 14:57Jacob Wieland - SpirentNote Added: 0015108
16-07-2018 14:37Jens GrabowskiNote Added: 0015136
16-07-2018 14:37Jens GrabowskiAssigned To => Kristóf Szabados
16-07-2018 14:37Jens GrabowskiStatusnew => assigned
17-07-2018 10:12Kristóf SzabadosFile Added: CR_7766.docx
18-07-2018 08:05Kristóf SzabadosNote Added: 0015151
18-07-2018 08:05Kristóf SzabadosAssigned ToKristóf Szabados => Tomas Urban
18-07-2018 08:05Kristóf SzabadosStatusassigned => confirmed
19-07-2018 11:02Tomas UrbanFile Added: CR_7766-2.docx
19-07-2018 11:04Tomas UrbanNote Added: 0015172
19-07-2018 11:04Tomas UrbanStatusconfirmed => resolved
19-07-2018 11:04Tomas UrbanResolutionopen => fixed
19-07-2018 11:04Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
06-01-2019 08:35Gyorgy RethyProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
06-01-2019 08:58Gyorgy RethyNote Added: 0015326
06-01-2019 08:58Gyorgy RethyStatusresolved => closed
06-01-2019 08:58Gyorgy RethyFixed in Version => 4.11.1 (published 2019-05)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015108) +
+ Jacob Wieland - Spirent    +
+ 05-06-2018 14:57    +
+ 		+ + + + +
+ What is the benefit of this feature?
+
+It just puts strain on the tool to be able to evaluate all these expressions at compile-time to ensure a) the consistency of the enumerated type (no number used twice) and b) the actual value of un-numbered enumerated values which are dependent on the values of numbered ones.
+
+If at all, the only things I would allow would be usages of constant literals and calls, shift/rotate operators and predefined functions.
+
+Otherwise, the boundary of what is still (feasibly) statically evaluatable is fuzzy and some tools would define that boundary differently than others.
+
+
+
+ + + + + + + + + + +
+ (0015136) +
+ Jens Grabowski    +
+ 16-07-2018 14:37    +
+ 		+ + + + +
+ STF discussion: ok, but only with the restrictions valid for type definintions and should be of type integer
+
+
+
+ + + + + + + + + + +
+ (0015151) +
+ Kristóf Szabados    +
+ 18-07-2018 08:05    +
+ 		+ + + + +
+ Please check.
+
+
+
+ + + + + + + + + + +
+ (0015172) +
+ Tomas Urban    +
+ 19-07-2018 11:04    +
+ 		+ + + + +
+ Review, no major issues found, I only corrected two capitalized identifiers. Ready to be added to the next version of the core language standard.
+
+
+
+ + + + + + + + + + +
+ (0015326) +
+ Gyorgy Rethy    +
+ 06-01-2019 08:58    +
+ 		+ + + + +
+ Added to draft v4.10.2
+
+ + diff --git a/docs/mantis/CR7768.md b/docs/mantis/CR7768.md new file mode 100644 index 0000000000000000000000000000000000000000..407c6b7bf38ed87373f2ac92559e14ae71d07754 --- /dev/null +++ b/docs/mantis/CR7768.md @@ -0,0 +1,249 @@ + + + + + + + + + + + + + 0007768: add support for stateful translation ports - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Config & Deployment Support (ES 202 781)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007768Ext Pack: Config & Deployment Support (ES 202 781)New Featurepublic25-05-2018 12:0105-01-2019 11:01
ReporterKristóf Szabados 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Versionv1.7.1 (published 2019-04) 
Clause Reference(s)5.2.4
Source (company - Author)L.M. Ericsson
TS versionn/a
Summary0007768: add support for stateful translation ports
DescriptionSection 5.2.4 in the Configuration and deployment extension pack describes how one can create ports with translation capability.
+
+In the text and syntactical structure this section shows that ports can have variables, that can be accessed from translation functions referencing that port.
+The example on page 21 also shows that the port of translation functions (with a port identifier) is accessible from within the translation function using the "port" keyword.
+
+From this it would naturally follow, and be very usefull if users could declare statefull ports, to simplify their tests.
+For example when someone just wants to send single message and check the response to it in the current core standard he/she has to write the entire protocol handling in TTCN-3 just to get to the point of sending the message.
+With statefull behaviour allowed inside translation ports the translation function itself could take the responsibility (by implementing a statemachine) ... signifficantly reducing the complexity on the user's side.
+
+For a detailed example with MQTT please look at: https://www.eclipse.org/forums/index.php/t/1092981/ [^]
+
+---
+
+Please note that, the current wording does not seem to restrict the above behaviour.
+So we might just need to add more detailed examples and text, that actually show : how port variables can be accessed from the translation function, and send/receive operations called on the "port" in translation functions.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR_7768.docx (145,240) 20-07-2018 08:31
http://oldforge.etsi.org/mantis/file_download.php?file_id=3780&type=bug
docx CR_7768-v2.docx (181,275) 11-10-2018 09:42
http://oldforge.etsi.org/mantis/file_download.php?file_id=3798&type=bug
Issue History
Date ModifiedUsernameFieldChange
25-05-2018 12:01Kristóf SzabadosNew Issue
16-07-2018 14:21Jens GrabowskiAssigned To => Kristóf Szabados
16-07-2018 14:21Jens GrabowskiStatusnew => assigned
16-07-2018 14:21Jens GrabowskiNote Added: 0015133
20-07-2018 08:31Kristóf SzabadosFile Added: CR_7768.docx
20-07-2018 08:32Kristóf SzabadosNote Added: 0015182
20-07-2018 08:32Kristóf SzabadosAssigned ToKristóf Szabados => Tomas Urban
20-07-2018 08:32Kristóf SzabadosStatusassigned => confirmed
20-07-2018 09:30Jens GrabowskiStatusconfirmed => assigned
20-07-2018 12:59Jacob Wieland - SpirentNote Added: 0015190
11-10-2018 09:42Tomas UrbanFile Added: CR_7768-v2.docx
11-10-2018 09:42Tomas UrbanNote Added: 0015247
11-10-2018 09:42Tomas UrbanAssigned ToTomas Urban => Kristof.Szabados
11-10-2018 09:42Tomas UrbanStatusassigned => confirmed
11-10-2018 11:20Kristóf SzabadosAssigned ToKristof.Szabados => Kristóf Szabados
11-10-2018 11:20Kristóf SzabadosStatusconfirmed => assigned
11-10-2018 11:21Kristóf SzabadosStatusassigned => confirmed
12-10-2018 08:25Kristóf SzabadosNote Added: 0015267
12-10-2018 08:25Kristóf SzabadosStatusconfirmed => resolved
12-10-2018 08:25Kristóf SzabadosResolutionopen => fixed
12-10-2018 08:25Kristóf SzabadosAssigned ToKristóf Szabados => Jens Grabowski
05-01-2019 10:56Gyorgy RethyNote Added: 0015315
05-01-2019 10:56Gyorgy RethyStatusresolved => closed
05-01-2019 10:56Gyorgy RethyFixed in Version => v1.7.1 (published 2019-04)
05-01-2019 11:00Gyorgy RethyAssigned ToJens Grabowski => Gyorgy Rethy
05-01-2019 11:00Gyorgy RethyStatusclosed => assigned
05-01-2019 11:01Gyorgy RethyStatusassigned => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015133) +
+ Jens Grabowski    +
+ 16-07-2018 14:21    +
+ 		+ + + + +
+ STF discussion: Kristof to develop a proposal.
+
+
+
+ + + + + + + + + + +
+ (0015182) +
+ Kristóf Szabados    +
+ 20-07-2018 08:32    +
+ 		+ + + + +
+ Please check.
+
+
+
+ + + + + + + + + + +
+ (0015190) +
+ Jacob Wieland - Spirent    +
+ 20-07-2018 12:59    +
+ 		+ + + + +
+ in the STF discussion about this, we came to the opinion that one way to solve this issue is to declare some component types as 'bridge' or 'translation' components which can execute full-fledged behavior without any additional restrictions.
+
+These translation components should mark pairs of in/out ports as some sort of 'connection' so that whenever a translated message that is received from the in-port of a connection is sent over the out-port of a connection, this is traceable at runtime so that the ingoing connection/mapping and the outgoing connection/mapping can be connected to a single 'arrow' from first source to last destination. Tools can then filter out displaying of such translation ports and treat messages to and from like direct messages between the other ends of the connections.
+
+
+
+ + + + + + + + + + +
+ (0015247) +
+ Tomas Urban    +
+ 11-10-2018 09:42    +
+ 		+ + + + +
+ Resolution proposal uploaded, please check.
+
+
+
+ + + + + + + + + + +
+ (0015267) +
+ Kristóf Szabados    +
+ 12-10-2018 08:25    +
+ 		+ + + + +
+ looks fine to me.
+
+
+
+ + + + + + + + + + +
+ (0015315) +
+ Gyorgy Rethy    +
+ 05-01-2019 10:56    +
+ 		+ + + + +
+ Added to v4.6.2
+
+ + diff --git a/docs/mantis/CR7769.md b/docs/mantis/CR7769.md new file mode 100644 index 0000000000000000000000000000000000000000..a453af2a97451d6d3626207d2e162c5e8fbad742 --- /dev/null +++ b/docs/mantis/CR7769.md @@ -0,0 +1,100 @@ + + + + + + + + + + + + + 0007769: Errors in example on variant attributes - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007769Part 01: TTCN-3 Core LanguageTechnicalpublic29-05-2018 08:4304-01-2019 17:02
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version4.11.1 (published 2019-05) 
Clause Reference(s)27.5
Source (company - Author)STF 548
Summary0007769: Errors in example on variant attributes
DescriptionThe example in the section 27.5 contains two errors:
+
+1. MyPDU1.field3 type should be MyType (currently Mytype)
+2. The valid encode attribute for MyPDU1.field3 is "General encoding rule" and not "Rule 2" as currently stated in the comment. That's because the field inherits the encode attribute from two places (MyType reference and myRecords group). One of the main rules for attributes overriding specified in 27.1.2.0 states: "Attributes inherited from a type reference will override general attributes from a higher scope unit containing the type reference." Thus, the encode attribute is inherited from MyType reference whose encode attribute equals to "General encoding rule" (inherited from the module level).
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR-7769-Errors in example on variant attributes.docx (70,785) 17-07-2018 10:27
http://oldforge.etsi.org/mantis/file_download.php?file_id=3762&type=bug
Issue History
Date ModifiedUsernameFieldChange
29-05-2018 08:43Tomas UrbanNew Issue
16-07-2018 14:22Jens GrabowskiAssigned To => Jens Grabowski
16-07-2018 14:22Jens GrabowskiStatusnew => assigned
17-07-2018 10:27Jens GrabowskiFile Added: CR-7769-Errors in example on variant attributes.docx
17-07-2018 10:28Jens GrabowskiNote Added: 0015143
17-07-2018 10:28Jens GrabowskiStatusassigned => resolved
17-07-2018 10:28Jens GrabowskiResolutionopen => fixed
17-07-2018 10:28Jens GrabowskiAssigned ToJens Grabowski => Gyorgy Rethy
04-01-2019 17:02Gyorgy RethyNote Added: 0015304
04-01-2019 17:02Gyorgy RethyStatusresolved => closed
04-01-2019 17:02Gyorgy RethyFixed in Version => 4.11.1 (published 2019-05)
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015143) +
+ Jens Grabowski    +
+ 17-07-2018 10:28    +
+ 		+ + + + +
+ see resolution
+
+
+
+ + + + + + + + + + +
+ (0015304) +
+ Gyorgy Rethy    +
+ 04-01-2019 17:02    +
+ 		+ + + + +
+ Added to draft V4.10.2
+
+ + diff --git a/docs/mantis/CR7772.md b/docs/mantis/CR7772.md new file mode 100644 index 0000000000000000000000000000000000000000..5905780360a2c4bea70ba55c1b22d82c856b3fea --- /dev/null +++ b/docs/mantis/CR7772.md @@ -0,0 +1,103 @@ + + + + + + + + + + + + + 0007772: Typos in section 27.9 - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007772Part 01: TTCN-3 Core LanguageEditorialpublic31-05-2018 10:0004-01-2019 17:04
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeveritytrivialReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.9.1 (published 2017-05) 
Target VersionFixed in Version4.11.1 (published 2019-05) 
Clause Reference(s)27.9
Source (company - Author)STF 548
Summary0007772: Typos in section 27.9
DescriptionPlural form missing in the following text:
+...for all codec function and communication operation of the current component...
+
+Correct would be:
+...for all codec functions and communication operations of the current component...
+
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR-7772-Typos in section 27.9.docx (67,534) 17-07-2018 10:14
http://oldforge.etsi.org/mantis/file_download.php?file_id=3759&type=bug
Issue History
Date ModifiedUsernameFieldChange
31-05-2018 10:00Tomas UrbanNew Issue
16-07-2018 14:22Jens GrabowskiAssigned To => Jens Grabowski
16-07-2018 14:22Jens GrabowskiStatusnew => assigned
17-07-2018 10:14Jens GrabowskiFile Added: CR-7772-Typos in section 27.9.docx
17-07-2018 10:15Jens GrabowskiNote Added: 0015140
17-07-2018 10:15Jens GrabowskiStatusassigned => resolved
17-07-2018 10:15Jens GrabowskiResolutionopen => fixed
17-07-2018 10:15Jens GrabowskiAssigned ToJens Grabowski => Gyorgy Rethy
04-01-2019 17:04Gyorgy RethyNote Added: 0015305
04-01-2019 17:04Gyorgy RethyStatusresolved => closed
04-01-2019 17:04Gyorgy RethyFixed in Version => 4.11.1 (published 2019-05)
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015140) +
+ Jens Grabowski    +
+ 17-07-2018 10:15    +
+ 		+ + + + +
+ Typo, see resolution.
+
+
+
+ + + + + + + + + + +
+ (0015305) +
+ Gyorgy Rethy    +
+ 04-01-2019 17:04    +
+ 		+ + + + +
+ Added to V4.10.2
+
+ + diff --git a/docs/mantis/CR7774.md b/docs/mantis/CR7774.md new file mode 100644 index 0000000000000000000000000000000000000000..c181d296097454a50d9cfe52baf53b0a45298611 --- /dev/null +++ b/docs/mantis/CR7774.md @@ -0,0 +1,378 @@ + + + + + + + + + + + + + 0007774: Is replace function applicable to variables/templates of string/record of types with values containing matching mechanisms - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007774Part 01: TTCN-3 Core LanguageClarificationpublic04-06-2018 14:2718-12-2018 11:49
ReporterThilo Lauer 
Assigned ToTomas Urban 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionno change required 
PlatformOSOS Version
Product Versionv4.9.1 (published 2017-05) 
Target VersionFixed in Version 
Clause Reference(s)TTCN-3 Standard, Part 1 completely
Source (company - Author)    Devoteam - Thilo Lauer
Summary0007774: Is replace function applicable to variables/templates of string/record of types with values containing matching mechanisms
DescriptionCan the replace function be used for variables or templates assigned by a matching-mechanism/symbol (OmitValue, AnyValue, AnyValueOrNone, AnyElementOrNone, ValueList, Complement, Permutation, Superset, Subset)?
+
+We would like to get a clarification as the standard is here too unspecific currently.
+
+Please note:
+we are NOT(!) voting for permitting replace for variables/templates of string/record of types with values containing matching mechanisms/symbols.
+We simply want to get a clarification how to handle such cases if permitted.
+
+For a number of examples, please see the uploaded file.
Steps To Reproducesee the uploaded file
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR_replace AnyValueOrNone in strings, rec. of, etc. (clarification).docx (28,357) 04-06-2018 14:27
http://oldforge.etsi.org/mantis/file_download.php?file_id=3752&type=bug
Issue History
Date ModifiedUsernameFieldChange
04-06-2018 14:27Thilo LauerNew Issue
04-06-2018 14:27Thilo LauerFile Added: CR_replace AnyValueOrNone in strings, rec. of, etc. (clarification).docx
05-06-2018 14:45Jacob Wieland - SpirentNote Added: 0015107
05-06-2018 14:50Jacob Wieland - SpirentNote Edited: 0015107bug_revision_view_page.php?bugnote_id=15107#r481
16-07-2018 14:31Jens GrabowskiAssigned To => Jens Grabowski
16-07-2018 14:31Jens GrabowskiStatusnew => assigned
16-07-2018 14:32Jens GrabowskiNote Added: 0015135
16-07-2018 14:32Jens GrabowskiStatusassigned => feedback
18-07-2018 09:51Jens GrabowskiNote Added: 0015154
18-07-2018 09:52Jens GrabowskiAssigned ToJens Grabowski => Jacob Wieland - Spirent
18-07-2018 09:52Jens GrabowskiStatusfeedback => assigned
18-07-2018 10:33Jacob Wieland - SpirentNote Added: 0015155
19-07-2018 10:04Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Jens Grabowski
19-07-2018 10:04Jacob Wieland - SpirentStatusassigned => feedback
11-10-2018 14:37Kristóf SzabadosAssigned ToJens Grabowski => Tomas Urban
11-10-2018 14:37Kristóf SzabadosStatusfeedback => assigned
11-10-2018 16:26Tomas UrbanNote Added: 0015259
11-10-2018 16:27Tomas UrbanNote Edited: 0015259bug_revision_view_page.php?bugnote_id=15259#r489
11-10-2018 16:28Tomas UrbanNote Edited: 0015259bug_revision_view_page.php?bugnote_id=15259#r490
11-10-2018 16:29Tomas UrbanNote Edited: 0015259bug_revision_view_page.php?bugnote_id=15259#r491
18-12-2018 11:49Jens GrabowskiNote Added: 0015292
18-12-2018 11:49Jens GrabowskiStatusassigned => closed
18-12-2018 11:49Jens GrabowskiResolutionopen => no change required
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015107) +
+ Jacob Wieland - Spirent    +
+ 05-06-2018 14:45    +
(edited on: 05-06-2018 14:50)
+ 		+ + + + +
+ According to the standard, the first parameter of the replace function must be a value. Therefore, any list that contains a matching mechanism is not allowed.
+
+This is apparent from the signature given in section C.4.3:
+
+replace(
+ in any_string_or_sequence_type inpar,
+ in integer index,
+ in integer len,
+ in any_string_or_sequence_type repl
+) return any_string_or_sequence_type
+
+And also from the first sentence of the description:
+
+"This function replaces the substring or subsequence of value inpar at index index of length len with the string or
+sequence value repl and returns the resulting string or sequence."
+
+If you compare that, for instance with the substr function:
+
+substr(
+ in template (present) any_string_or_sequence_type inpar,
+ in integer index,
+ in integer count
+) return input_string_or_sequence_type
+
+the difference should become clear.
+
+So, as far as I can see, the standard is already clear in that regard.
+
+
+
+
+
+ + + + + + + + + + +
+ (0015135) +
+ Jens Grabowski    +
+ 16-07-2018 14:32    +
+ 		+ + + + +
+ STF does not a see a need for further clarification. Devoteam should check comment from Jacob.
+
+
+
+ + + + + + + + + + +
+ (0015154) +
+ Jens Grabowski    +
+ 18-07-2018 09:51    +
+ 		+ + + + +
+ Answer from Mr. Lauer regarding feedback (received via Email on 17.07.18):
+
+Dear Mr. Grabowski,
+
+Thanks for your request regarding our CR.
+
+Recently we had a request from one of our customers, who wants to compile the following code:
+
+    function f_Check_UE_NetworkCap_CIOT(UE_NetworkCap p_UE_NetworkCap,
+                                          UE_NetworkCap_ToBeTested p_ToBeTested) return Boolean
+
+      {
+        var template (present) B8_Type v_Expected := ?; // seems not to be allowed, see examples 1 and 2 below
+
+        ...
+
+        v_Expected := replace (v_Expected, 1, 1, f_ConvertBoolToBit (pc_HCCPCIoT));
+
+        ...
+      }
+
+      }
+
+
+The substr() statement allows AnyElementOrNone and AnyElement but no example is given in the standard. Here are some of our examples:
+
+Example 1: substr(?,1,2); // What is the result? Seems to be not allowed as ? (=any value) is not used as matching symbol inside a string
+Example 2: substr(*,1,2); // What is the result? Seems to be not allowed as ? (=any value) is not used as matching symbol inside a string
+
+Example 3: substr(pattern "?*A",1,2); // What is the result? Seems to be allowed, result = "*A"; "*" = literal char, acc. to C.4.2
+Example 4: substr(pattern "*?*A",1,2); // What is the result? Seems to be allowed, result = "?*" = literal chars , acc. to C.4.2
+
+If examples 3 and 4 are allowed, it is possible to define:
+
+a:=substr(pattern "*?*",1,2); // result is a characterstring of length 2 (not a template): result = "?*"
+b:=replace(a,0,2,"asdf"); // result: b = "asdf"
+c:=substr(pattern "*?*",0,1) & b; // result: c = "*asdf"
+
+But using replace as a shortcut for the statements above - to our standard interpretation - is not allowed:
+
+d:=replace(pattern"*?*",1,2,"asdf"); // result: should be: d = "*asdf", but this is currently not allowed.
+
+There are a number of combinations between substring, replace, stringop (&) operating on values and/or (matching) templates
+that are not yet described clearly enough in the current standard.
+
+
+Especially stringop (&) allows much with templates:
+
+Let us point to another example in the current standard:
+
+    Section 15.11: Concatenating templates of string and list types
+
+
+    EXAMPLE 1: Composing templates of binary string types
+
+
+    template bitstring mw_mybit := '010'B & ? & '1'B & ? length(1) & '1'B;
+
+             // results in the template '010*1?1'B
+
+             // note that & ? & turns to * within the resulting bitstring as the original ?
+
+             // stands for a bitstring of any length
+
+
+    "? (any value) stands for a bitstring of any length"
+    is a bit imprecise: ? (any value) stands here for a bitstring of length 1 .. infinite.
+
+    Replacing it by an * (any value or none) modifies the original pattern part to: a bitstring of length 0 .. infinite - which is slightly different.
+
+    Of course one can declare this to be the meaning of bitstring template concatenation ...
+
+    ... and in case of stringop (&) it was made obvious by an example.
+
+
+Our point here is, that there are a number of combinations of substring, replace, stringop (&) operating on values and/or (matching) templates ...
+... that are not specified clearly enough - but they should be. Especially such "subtle" stringop details (as shown above) do not become obvious as long as there is no explicit example.
+
+We can live with such imprecisions, but they rise the probability that compilers work differently - and users have different interpretations of the same TTCN-3 code.
+
+General statements only helps, if they are valid in any case.
+If general statements only describe the general direction, you have to deal with a lot of exceptions, that are often not or poorly defined ...
+
+Hope this helps.
+Regards,
+
+Thilo Lauer
+Principal Consultant
+Solution Architect
+
+
+
+ + + + + + + + + + +
+ (0015155) +
+ Jacob Wieland - Spirent    +
+ 18-07-2018 10:33    +
+ 		+ + + + +
+ I don't concur with that analysis.
+
+? stands for any value, that means also bitstrings of length 0, not only with length > 0. The equivalent on the pattern level for that is *, so example 1 is fully correct and there is nothing imprecise in (that part of) the text.
+
+One could argue that the replace function could have the same strange allowance for dealing with occurrences of only the metacharacters ? and *, but in my opinion already the usage of substr on pattern is questionable as you change the semantics of the metacharacters to normal characters.
+
+Thus, if at all, the standard should be changed that substr on a pattern again yields a pattern so that the semantics of the characters are retained. But, of course, that would be a backward incompatible change, so that will not happen.
+
+
+
+ + + + + + + + + + +
+ (0015259) +
+ Tomas Urban    +
+ 11-10-2018 16:26    +
(edited on: 11-10-2018 16:29)
+ 		+ + + + +
+ 1. replace (v_Expected, 1, 1, f_ConvertBoolToBit (pc_HCCPCIoT))
+
+This is an invalid code and shall not be compiled as the first formal parameter of the replace function is a value parameter. Because the declaration of the inpar is not completely standard, this is explicitly stated in the section C.4.3. The section 5.4.2 of the core language specification clearly states what actual parameters can be passed to in formal value parameters:
+
+Actual parameters that are passed by value to in formal value parameters shall be variables, literal values, module parameters, constants, value variables, invocations of value returning (external) functions, formal value parameters (of in, inout or out parameterization) of the current scope or expressions composed of the above.
+
+2. The substr function examples:
+Example 1 and 2 are invalid, as the type context of the matching symbol is not set. If the AnyValue template was typed, then the error would occur because of other restriction mentioned in C.4.2 (AnyValue is not listed as a valid content of inpar)
+Example 3 and 4 work as described and the following code as well. The replace function indeed doesn't work, but the original CR didn't request the change of its functionality! The question was if the rules were clear enough. If it is necessary to change the replace function functionality, a new CR should be submitted.
+
+3. String concatenation
+As Jacob pointed out, the following statement is absolutely wrong: "? (any value) stands here for a bitstring of length 1 .. infinite". There's no reason why "match(''B, ?)" should yield false as empty bitstring is not the same thing as an omitted bitstring. Naturally, all subsequent conclusions are incorrect as well, including the statement that different interpretations are possible. This is simply not the case.
+
+My conclusion is that the presented examples failed to demonstrate any ambiguity or imprecision in the TTCN-3 core language standard.
+
+
+
+
+
+ + + + + + + + + + +
+ (0015292) +
+ Jens Grabowski    +
+ 18-12-2018 11:49    +
+ 		+ + + + +
+ STF decision: The presented examples failed to demonstrate any ambiguity or imprecision in the TTCN-3 core language standard. No change seems to be necessary.
+
+ + diff --git a/docs/mantis/CR7775.md b/docs/mantis/CR7775.md new file mode 100644 index 0000000000000000000000000000000000000000..4f3c9229ba54c2b31a4070be19919ba76bec8db1 --- /dev/null +++ b/docs/mantis/CR7775.md @@ -0,0 +1,205 @@ + + + + + + + + + + + + + 0007775: matching mechanism for concatenation of strings needed - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Advanced Matching (ES 203 022)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007775Ext Pack: Advanced Matching (ES 203 022)Technicalpublic05-06-2018 13:3605-01-2019 14:13
ReporterJacob Wieland - Spirent 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv1.1.1 (published 2017-07) 
Target VersionFixed in Versionv1.3.1 (ongoing) 
Clause Reference(s)15.11
Source (company - Author)Spirent - Jacob Wieland
TS version?
Summary0007775: matching mechanism for concatenation of strings needed
DescriptionAt the moment, there is no standardized way to represent concatenated string templates, like
+
+"Reporter: " & ("Jacob", "Tomas", "Jens", "Kristof")
+
+In my view, it would be necessary to define a new MatchingMechanism (e.g. Concatenation) and also the logging needs to be enhanced to allow to log such a matching mechanism.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0007782closed Gyorgy Rethy Additional parameter values for istemplatekind function 
Attached Filesdocx CR7775.docx (136,593) 09-10-2018 11:18
http://oldforge.etsi.org/mantis/file_download.php?file_id=3786&type=bug
Issue History
Date ModifiedUsernameFieldChange
05-06-2018 13:36Jacob Wieland - SpirentNew Issue
16-07-2018 14:28Jens GrabowskiAssigned To => Jacob Wieland - Spirent
16-07-2018 14:28Jens GrabowskiStatusnew => assigned
16-07-2018 14:29Jens GrabowskiNote Added: 0015134
09-10-2018 11:18Jacob Wieland - SpirentFile Added: CR7775.docx
09-10-2018 11:21Jacob Wieland - SpirentNote Added: 0015222
09-10-2018 11:21Jacob Wieland - SpirentNote Added: 0015223
09-10-2018 11:21Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Tomas Urban
09-10-2018 11:21Jacob Wieland - SpirentStatusassigned => confirmed
09-10-2018 11:41Jacob Wieland - SpirentRelationship addedrelated to 0007782
10-10-2018 07:27Tomas UrbanNote Added: 0015235
10-10-2018 07:27Tomas UrbanStatusconfirmed => resolved
10-10-2018 07:27Tomas UrbanResolutionopen => fixed
10-10-2018 07:27Tomas UrbanAssigned ToTomas Urban => Jens Grabowski
05-01-2019 14:13Gyorgy RethyNote Added: 0015322
05-01-2019 14:13Gyorgy RethyStatusresolved => closed
05-01-2019 14:13Gyorgy RethyAssigned ToJens Grabowski => Gyorgy Rethy
05-01-2019 14:13Gyorgy RethyFixed in Version => v1.3.1 (ongoing)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015134) +
+ Jens Grabowski    +
+ 16-07-2018 14:29    +
+ 		+ + + + +
+ STF discussion: Jacob will develop a proposal.
+
+
+
+ + + + + + + + + + +
+ (0015222) +
+ Jacob Wieland - Spirent    +
+ 09-10-2018 11:21    +
+ 		+ + + + +
+ As we have already introduced general concatenation matching in Advanced Matching, I have added the necessary changes to the TCI standard as change descriptions in the Advanced Matching document.
+
+I have also fixed a slight inconsistency in the example of 5.4.4.2 (added a star to the beginning of the complement because that describes all strings which don't end in the given suffix.
+
+
+
+ + + + + + + + + + +
+ (0015223) +
+ Jacob Wieland - Spirent    +
+ 09-10-2018 11:21    +
+ 		+ + + + +
+ please review
+
+
+
+ + + + + + + + + + +
+ (0015235) +
+ Tomas Urban    +
+ 10-10-2018 07:27    +
+ 		+ + + + +
+ Reviewed, no issues found. The proposed changes can be added to the next version of the advanced matching extension package.
+
+
+
+ + + + + + + + + + +
+ (0015322) +
+ Gyorgy Rethy    +
+ 05-01-2019 14:13    +
+ 		+ + + + +
+ Added to draft v1.2.2
+
+ + diff --git a/docs/mantis/CR7776.md b/docs/mantis/CR7776.md new file mode 100644 index 0000000000000000000000000000000000000000..91395b5d5aaae1a684c27f2bc1601b58adbc1f8f --- /dev/null +++ b/docs/mantis/CR7776.md @@ -0,0 +1,165 @@ + + + + + + + + + + + + + 0007776: Invalid conversion of type derived by union with enumeration facets - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007776Part 09: Using XML with TTCN-3Technicalpublic14-06-2018 13:4305-01-2019 10:02
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.8.1 (published 2017-05) 
Target VersionFixed in Versionv4.10.1 (published 2019-05) 
Clause Reference(s)7.5.3
For STF discussion
Source (company - Author)STF 548
Summary0007776: Invalid conversion of type derived by union with enumeration facets
DescriptionThe example 5 of 7.5.3 restricts the ns:e21unnamed type. However, the result of trasformation to TTCN-3 is not correct, because the referenced type contains anonymous simple types which should be transformed to alt_, alt_1 and alt_2 enumerated items. The current result of trasformation would be correct if the referenced types was ns:e21memberlist.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR_7776.docx (152,814) 20-07-2018 09:19
http://oldforge.etsi.org/mantis/file_download.php?file_id=3784&type=bug
Issue History
Date ModifiedUsernameFieldChange
14-06-2018 13:43Tomas UrbanNew Issue
15-06-2018 08:07Tomas UrbanNote Added: 0015110
16-07-2018 14:40Jens GrabowskiAssigned To => Kristóf Szabados
16-07-2018 14:40Jens GrabowskiStatusnew => assigned
20-07-2018 09:19Kristóf SzabadosFile Added: CR_7776.docx
20-07-2018 09:19Kristóf SzabadosNote Added: 0015187
20-07-2018 09:19Kristóf SzabadosAssigned ToKristóf Szabados => Tomas Urban
20-07-2018 09:19Kristóf SzabadosStatusassigned => confirmed
20-07-2018 10:48Tomas UrbanNote Added: 0015188
20-07-2018 10:48Tomas UrbanStatusconfirmed => resolved
20-07-2018 10:48Tomas UrbanResolutionopen => fixed
20-07-2018 10:48Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
05-01-2019 10:02Gyorgy RethyNote Added: 0015312
05-01-2019 10:02Gyorgy RethyStatusresolved => closed
05-01-2019 10:02Gyorgy RethyFixed in Version => v4.10.1 (published 2019-05)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015110) +
+ Tomas Urban    +
+ 15-06-2018 08:07    +
+ 		+ + + + +
+ One additional issue: the xsiType field is optional in the example 5, but the rules of 7.5.3 don't mention that the field shall be optional.
+
+
+
+ + + + + + + + + + +
+ (0015187) +
+ Kristóf Szabados    +
+ 20-07-2018 09:19    +
+ 		+ + + + +
+ please check.
+
+
+
+ + + + + + + + + + +
+ (0015188) +
+ Tomas Urban    +
+ 20-07-2018 10:48    +
+ 		+ + + + +
+ Reviewed, no issues found. The proposal can be added to the next version of the standard.
+
+
+
+ + + + + + + + + + +
+ (0015312) +
+ Gyorgy Rethy    +
+ 05-01-2019 10:02    +
+ 		+ + + + +
+ Added to draft v4.9.2
+
+ + diff --git a/docs/mantis/CR7779.md b/docs/mantis/CR7779.md new file mode 100644 index 0000000000000000000000000000000000000000..9168a59f07df05fa5193815fd8944104f18951da --- /dev/null +++ b/docs/mantis/CR7779.md @@ -0,0 +1,135 @@ + + + + + + + + + + + + + 0007779: Functions with 'port'clause should not be startable - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Config & Deployment Support (ES 202 781)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007779Ext Pack: Config & Deployment Support (ES 202 781)Clarificationpublic10-07-2018 08:1308-10-2018 17:23
ReporterKristóf Szabados 
Assigned ToKristóf Szabados 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionno change required 
PlatformOSOS Version
Product Versionv1.5.1 (published 2017-05) 
Target VersionFixed in Version 
Clause Reference(s)5.2.3
Source (company - Author)L.M. Ericsson
TS versionn/a
Summary0007779: Functions with 'port'clause should not be startable
DescriptionCurrently section 5.2.3 "translation functions" does not restrict the starting of functions with a 'port' clause on remote components.
+
+The list of restrictions should be extended with this restriction.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
10-07-2018 08:13Kristóf SzabadosNew Issue
16-07-2018 14:41Jens GrabowskiAssigned To => Tomas Urban
16-07-2018 14:41Jens GrabowskiStatusnew => assigned
17-07-2018 08:54Kristóf SzabadosAssigned ToTomas Urban => Kristóf Szabados
17-07-2018 08:55Kristóf SzabadosAssigned ToKristóf Szabados => Tomas Urban
17-07-2018 09:27Tomas UrbanNote Added: 0015139
17-07-2018 09:27Tomas UrbanProduct Version => v1.5.1 (published 2017-05)
17-07-2018 09:27Tomas UrbanAssigned ToTomas Urban => Kristóf Szabados
17-07-2018 10:55Kristóf SzabadosNote Added: 0015146
17-07-2018 10:55Kristóf SzabadosStatusassigned => resolved
17-07-2018 10:55Kristóf SzabadosResolutionopen => no change required
08-10-2018 14:53Jens GrabowskiAssigned ToKristóf Szabados => Jens Grabowski
08-10-2018 14:53Jens GrabowskiStatusresolved => assigned
08-10-2018 14:54Jens GrabowskiAssigned ToJens Grabowski => Kristof.Szabados
08-10-2018 17:18Kristóf SzabadosAssigned ToKristof.Szabados => Kristóf Szabados
08-10-2018 17:22Kristóf SzabadosStatusassigned => resolved
08-10-2018 17:23Kristóf SzabadosNote Added: 0015209
08-10-2018 17:23Kristóf SzabadosStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015139) +
+ Tomas Urban    +
+ 17-07-2018 09:27    +
+ 		+ + + + +
+ The restriction 5.2.3.i states that "Invoking a function with a port clause explicitly shall cause an error."
+
+Explicit invocation should cover the described case (invocation in the component.start operation), so I don't think an additional rule is necessary.
+
+
+
+ + + + + + + + + + +
+ (0015146) +
+ Kristóf Szabados    +
+ 17-07-2018 10:55    +
+ 		+ + + + +
+ True, the already present restriction is enough.
+
+
+
+ + + + + + + + + + +
+ (0015209) +
+ Kristóf Szabados    +
+ 08-10-2018 17:23    +
+ 		+ + + + +
+ no change needed
+
+ + diff --git a/docs/mantis/CR7780.md b/docs/mantis/CR7780.md new file mode 100644 index 0000000000000000000000000000000000000000..d97ca7cd428e4e8d876f2eeef862f6c28ac1871c --- /dev/null +++ b/docs/mantis/CR7780.md @@ -0,0 +1,205 @@ + + + + + + + + + + + + + 0007780: Template module parameters - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007780Part 01: TTCN-3 Core LanguageNew Featurepublic12-07-2018 13:0004-01-2019 17:10
ReporterJacob Wieland - Spirent 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.9.1 (published 2017-05) 
Target VersionFixed in Version4.11.1 (published 2019-05) 
Clause Reference(s)8.2.1
Source (company - Author)Spirent - Jacob Wieland
Summary0007780: Template module parameters
DescriptionThere are some use cases where it makes sense to allow wildcards for some module parameters that are used in (receiving) templates.
+
+At the moment, this can only be (elegantly) achieved with a function that consumes a module parameter and depending on the input yields either a value or a template.
+
+Of course, this is very static and does not allow the full range of templates so it is very dependent on what usage scenarios the developer of a testsuite foresaw which might be at odds with the actually occurring scenarios.
+
+Of course, this would be quite a substantial change on the TCI level regarding all things related to module parameters which at the moment are assumed to be values.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7780.docx (235,327) 17-07-2018 10:16
http://oldforge.etsi.org/mantis/file_download.php?file_id=3760&type=bug
Issue History
Date ModifiedUsernameFieldChange
12-07-2018 13:00Jacob Wieland - SpirentNew Issue
16-07-2018 14:46Jens GrabowskiNote Added: 0015137
16-07-2018 14:46Jens GrabowskiAssigned To => Jacob Wieland - Spirent
16-07-2018 14:46Jens GrabowskiStatusnew => assigned
17-07-2018 10:16Jacob Wieland - SpirentFile Added: CR7780.docx
17-07-2018 10:17Jacob Wieland - SpirentNote Added: 0015142
17-07-2018 10:17Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Kristóf Szabados
17-07-2018 10:17Jacob Wieland - SpirentStatusassigned => confirmed
18-07-2018 09:18Kristóf SzabadosNote Added: 0015153
18-07-2018 09:18Kristóf SzabadosAssigned ToKristóf Szabados => Tomas Urban
18-07-2018 09:18Kristóf SzabadosStatusconfirmed => assigned
18-07-2018 09:19Kristóf SzabadosStatusassigned => confirmed
18-07-2018 13:21Tomas UrbanNote Added: 0015159
18-07-2018 13:21Tomas UrbanStatusconfirmed => resolved
18-07-2018 13:21Tomas UrbanResolutionopen => fixed
18-07-2018 13:21Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
04-01-2019 17:10Gyorgy RethyNote Added: 0015306
04-01-2019 17:10Gyorgy RethyStatusresolved => closed
04-01-2019 17:10Gyorgy RethyFixed in Version => 4.11.1 (published 2019-05)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015137) +
+ Jens Grabowski    +
+ 16-07-2018 14:46    +
+ 		+ + + + +
+ STF discussion: reasonable extension, Jacob will develop a proposal.
+
+
+
+ + + + + + + + + + +
+ (0015142) +
+ Jacob Wieland - Spirent    +
+ 17-07-2018 10:17    +
+ 		+ + + + +
+ Please review my changes. I have removed some redundancies.
+
+
+
+ + + + + + + + + + +
+ (0015153) +
+ Kristóf Szabados    +
+ 18-07-2018 09:18    +
+ 		+ + + + +
+ Looks correct for me.
+
+
+
+ + + + + + + + + + +
+ (0015159) +
+ Tomas Urban    +
+ 18-07-2018 13:21    +
+ 		+ + + + +
+ I also didn't find any issues. The proposed resolution can be added to the next version of the core language standard.
+
+
+
+ + + + + + + + + + +
+ (0015306) +
+ Gyorgy Rethy    +
+ 04-01-2019 17:10    +
+ 		+ + + + +
+ Added to V4.10.2
+
+ + diff --git a/docs/mantis/CR7782.md b/docs/mantis/CR7782.md new file mode 100644 index 0000000000000000000000000000000000000000..021c9489458894147a3e10e4c50f71a34adcffad --- /dev/null +++ b/docs/mantis/CR7782.md @@ -0,0 +1,233 @@ + + + + + + + + + + + + + 0007782: Additional parameter values for istemplatekind function - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Advanced Matching (ES 203 022)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007782Ext Pack: Advanced Matching (ES 203 022)Technicalpublic18-07-2018 08:1305-01-2019 14:56
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv1.1.1 (published 2017-07) 
Target VersionFixed in Versionv1.3.1 (ongoing) 
Clause Reference(s)5
Source (company - Author)STF 550
TS versionN/A
Summary0007782: Additional parameter values for istemplatekind function
DescriptionMatching mechanisms defined in the extension package "Advanced matching" are not supported by the istemplatekind function. New parameter values should be added to enable detection of these matching mechanisms.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0007775closed Gyorgy Rethy matching mechanism for concatenation of strings needed 
Attached Filesdocx CR7782-1.docx (134,365) 20-07-2018 08:42
http://oldforge.etsi.org/mantis/file_download.php?file_id=3781&type=bug
docx CR7782-2.docx (124,440) 09-10-2018 11:43
http://oldforge.etsi.org/mantis/file_download.php?file_id=3787&type=bug
Issue History
Date ModifiedUsernameFieldChange
18-07-2018 08:13Tomas UrbanNew Issue
18-07-2018 13:34Jens GrabowskiAssigned To => Tomas Urban
18-07-2018 13:34Jens GrabowskiStatusnew => assigned
18-07-2018 13:34Jens GrabowskiNote Added: 0015162
20-07-2018 08:42Tomas UrbanFile Added: CR7782-1.docx
20-07-2018 08:43Tomas UrbanNote Added: 0015183
20-07-2018 08:43Tomas UrbanAssigned ToTomas Urban => Jacob Wieland - Spirent
20-07-2018 08:43Tomas UrbanStatusassigned => confirmed
09-10-2018 11:41Jacob Wieland - SpirentRelationship addedrelated to 0007775
09-10-2018 11:42Jacob Wieland - SpirentNote Added: 0015224
09-10-2018 11:42Jacob Wieland - SpirentStatusconfirmed => new
09-10-2018 11:42Jacob Wieland - SpirentNote Added: 0015225
09-10-2018 11:42Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Tomas Urban
09-10-2018 11:42Jacob Wieland - SpirentStatusnew => confirmed
09-10-2018 11:43Jacob Wieland - SpirentFile Added: CR7782-2.docx
10-10-2018 07:25Tomas UrbanNote Added: 0015234
10-10-2018 07:25Tomas UrbanStatusconfirmed => resolved
10-10-2018 07:25Tomas UrbanResolutionopen => fixed
10-10-2018 07:25Tomas UrbanAssigned ToTomas Urban => Jens Grabowski
05-01-2019 14:56Gyorgy RethyNote Added: 0015323
05-01-2019 14:56Gyorgy RethyStatusresolved => closed
05-01-2019 14:56Gyorgy RethyAssigned ToJens Grabowski => Gyorgy Rethy
05-01-2019 14:56Gyorgy RethyFixed in Version => v1.3.1 (ongoing)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015162) +
+ Jens Grabowski    +
+ 18-07-2018 13:34    +
+ 		+ + + + +
+ Proposal to be prepared by Tomas.
+
+
+
+ + + + + + + + + + +
+ (0015183) +
+ Tomas Urban    +
+ 20-07-2018 08:43    +
+ 		+ + + + +
+ Proposal uploaded, please check.
+
+
+
+ + + + + + + + + + +
+ (0015224) +
+ Jacob Wieland - Spirent    +
+ 09-10-2018 11:42    +
+ 		+ + + + +
+ proposal accepted, added also concatenation as additional kind
+
+
+
+ + + + + + + + + + +
+ (0015225) +
+ Jacob Wieland - Spirent    +
+ 09-10-2018 11:42    +
+ 		+ + + + +
+ please review
+
+
+
+ + + + + + + + + + +
+ (0015234) +
+ Tomas Urban    +
+ 10-10-2018 07:25    +
+ 		+ + + + +
+ Reviewed, no issues found. The proposed changes can be added to the next version of the advanced matching extension package.
+
+
+
+ + + + + + + + + + +
+ (0015323) +
+ Gyorgy Rethy    +
+ 05-01-2019 14:56    +
+ 		+ + + + +
+ Added to draft v1.2.2
+
+ + diff --git a/docs/mantis/CR7783.md b/docs/mantis/CR7783.md new file mode 100644 index 0000000000000000000000000000000000000000..259a7610b6c1d383cba0984e9d87e7f2cad627fe --- /dev/null +++ b/docs/mantis/CR7783.md @@ -0,0 +1,167 @@ + + + + + + + + + + + + + 0007783: Qualified notation for enumerated values - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007783Part 01: TTCN-3 Core LanguageTechnicalpublic18-07-2018 08:3304-01-2019 17:17
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version4.11.1 (published 2019-05) 
Clause Reference(s)6.2.4
Source (company - Author)STF 550
Summary0007783: Qualified notation for enumerated values
DescriptionIn addition to the current notation, the core language standard should allow to reference enumerated values together with their type prefix, i.e. in the qualified form. On the syntax level, either dot notation should be used (preferred, similar to current syntax for qualified names) or colon notation (like in inline templates; it might be supported already by some tools, but this approach could cause compilation issues, because such notation creates a template entity and not a value).
+
+Using qualified enumerated values would bring TTCN-3 closer to common programming languages (java, C#) and prepare ground for possible removal of unqualified enumerated values in the next generation of the TTCN language standard (TTCN-4) because of complicated name conflict and context-based identifier resolution rules.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7783-1.docx (197,816) 19-07-2018 13:10
http://oldforge.etsi.org/mantis/file_download.php?file_id=3776&type=bug
Issue History
Date ModifiedUsernameFieldChange
18-07-2018 08:33Tomas UrbanNew Issue
18-07-2018 13:46Jens GrabowskiAssigned To => Tomas Urban
18-07-2018 13:46Jens GrabowskiStatusnew => assigned
18-07-2018 13:48Jens GrabowskiNote Added: 0015163
19-07-2018 13:10Tomas UrbanFile Added: CR7783-1.docx
19-07-2018 13:11Tomas UrbanNote Added: 0015176
19-07-2018 13:11Tomas UrbanAssigned ToTomas Urban => Kristóf Szabados
19-07-2018 13:11Tomas UrbanStatusassigned => confirmed
20-07-2018 07:46Kristóf SzabadosNote Added: 0015181
20-07-2018 07:46Kristóf SzabadosStatusconfirmed => resolved
20-07-2018 07:46Kristóf SzabadosFixed in Version => v4.10.1 (published 2018-05)
20-07-2018 07:46Kristóf SzabadosResolutionopen => fixed
20-07-2018 07:46Kristóf SzabadosAssigned ToKristóf Szabados => Gyorgy Rethy
04-01-2019 17:17Gyorgy RethyNote Added: 0015307
04-01-2019 17:17Gyorgy RethyStatusresolved => closed
04-01-2019 17:17Gyorgy RethyFixed in Versionv4.10.1 (published 2018-05) => 4.11.1 (published 2019-05)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015163) +
+ Jens Grabowski    +
+ 18-07-2018 13:48    +
+ 		+ + + + +
+ STF discussion: Tomas will make a proposal, Kristof will crosscheck and will have a look regarding performance.
+
+
+
+ + + + + + + + + + +
+ (0015176) +
+ Tomas Urban    +
+ 19-07-2018 13:11    +
+ 		+ + + + +
+ Proposed resolution uploaded. Please check.
+
+
+
+ + + + + + + + + + +
+ (0015181) +
+ Kristóf Szabados    +
+ 20-07-2018 07:46    +
+ 		+ + + + +
+ Reviewed. Can be added to the next version of the core language specification.
+
+
+
+ + + + + + + + + + +
+ (0015307) +
+ Gyorgy Rethy    +
+ 04-01-2019 17:17    +
+ 		+ + + + +
+ Added to V4.10.2
+
+ + diff --git a/docs/mantis/CR7784.md b/docs/mantis/CR7784.md new file mode 100644 index 0000000000000000000000000000000000000000..88ac96dad84124fc0bdc2dd0a9d78a16eea004b2 --- /dev/null +++ b/docs/mantis/CR7784.md @@ -0,0 +1,134 @@ + + + + + + + + + + + + + 0007784: setstate is incorrect in the example - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Config & Deployment Support (ES 202 781)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007784Ext Pack: Config & Deployment Support (ES 202 781)Editorialpublic19-07-2018 11:1305-01-2019 11:00
ReporterKristóf Szabados 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Versionv1.7.1 (published 2019-04) 
Clause Reference(s)5.2.3; 5.2.4
Source (company - Author)L.M. Ericsson
TS versionn/a
Summary0007784: setstate is incorrect in the example
DescriptionAccoding to 5.2.4 restriction a)
+"The value passed to the setstate operation in the first parameter shall be of the integer type and shall have one of the following values"
+
+Yet the examples in section 5.2.3 show port.setstate("Translated");
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR_7784.docx (129,971) 19-07-2018 11:19
http://oldforge.etsi.org/mantis/file_download.php?file_id=3775&type=bug
Issue History
Date ModifiedUsernameFieldChange
19-07-2018 11:13Kristóf SzabadosNew Issue
19-07-2018 11:15Kristóf SzabadosAssigned To => Kristóf Szabados
19-07-2018 11:15Kristóf SzabadosStatusnew => assigned
19-07-2018 11:19Kristóf SzabadosFile Added: CR_7784.docx
19-07-2018 11:19Kristóf SzabadosNote Added: 0015174
19-07-2018 11:19Kristóf SzabadosAssigned ToKristóf Szabados => Tomas Urban
19-07-2018 11:19Kristóf SzabadosStatusassigned => confirmed
19-07-2018 13:56Tomas UrbanNote Added: 0015179
19-07-2018 13:56Tomas UrbanStatusconfirmed => resolved
19-07-2018 13:56Tomas UrbanResolutionopen => fixed
19-07-2018 13:56Tomas UrbanAssigned ToTomas Urban => Jens Grabowski
05-01-2019 11:00Gyorgy RethyNote Added: 0015316
05-01-2019 11:00Gyorgy RethyStatusresolved => closed
05-01-2019 11:00Gyorgy RethyAssigned ToJens Grabowski => Gyorgy Rethy
05-01-2019 11:00Gyorgy RethyFixed in Version => v1.7.1 (published 2019-04)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015174) +
+ Kristóf Szabados    +
+ 19-07-2018 11:19    +
+ 		+ + + + +
+ please check.
+
+
+
+ + + + + + + + + + +
+ (0015179) +
+ Tomas Urban    +
+ 19-07-2018 13:56    +
+ 		+ + + + +
+ Reviewed, no issues found. The proposal is ready to be added to the next version of the extension package.
+
+
+
+ + + + + + + + + + +
+ (0015316) +
+ Gyorgy Rethy    +
+ 05-01-2019 11:00    +
+ 		+ + + + +
+ Added to draft v4.6.2
+
+ + diff --git a/docs/mantis/CR7785.md b/docs/mantis/CR7785.md new file mode 100644 index 0000000000000000000000000000000000000000..83faea74dbcc6f557f2361f369f758324c5a682f --- /dev/null +++ b/docs/mantis/CR7785.md @@ -0,0 +1,144 @@ + + + + + + + + + + + + + 0007785: Add Mutation annotations to the Value data type - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Advanced Matching (ES 203 022)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007785Ext Pack: Advanced Matching (ES 203 022)New Featurepublic19-07-2018 16:0218-12-2019 08:08
ReporterJacob Wieland - Spirent 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Clause Reference(s)??
Source (company - Author)Spirent - Jacob Wieland
TS version
Summary0007785: Add Mutation annotations to the Value data type
DescriptionThe abstract value data type shall have an additional method:
+
+Mutation getMutation();
+
+interface Mutation {
+  // this function shall return true if the mutation is to be applied to the encoded sub-message of an actual value, otherwise false
+  boolean needsMessage();
+
+  // this function is called by the encoder with the encoded sub-message of the value that contains this mutation or null if needsMessage() == false
+  // it returns the mutated message that will be included into the result-message by the calling encoder.
+  TriMessage mutate(TriMessage message);
+}
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0007763closed Gyorgy Rethy add support for sending erroneous messages 
Attached Filesdocx CR7785-v1.docx (161,642) 09-10-2018 16:24
http://oldforge.etsi.org/mantis/file_download.php?file_id=3792&type=bug
docx CR7785-v2.docx (140,716) 10-10-2018 08:38
http://oldforge.etsi.org/mantis/file_download.php?file_id=3794&type=bug
Issue History
Date ModifiedUsernameFieldChange
19-07-2018 16:02Jacob Wieland - SpirentNew Issue
19-07-2018 16:02Jacob Wieland - SpirentStatusnew => assigned
19-07-2018 16:02Jacob Wieland - SpirentAssigned To => Tomas Urban
19-07-2018 16:02Jacob Wieland - SpirentRelationship addedrelated to 0007763
09-10-2018 16:24Tomas UrbanFile Added: CR7785-v1.docx
09-10-2018 16:25Tomas UrbanNote Added: 0015233
09-10-2018 16:25Tomas UrbanAssigned ToTomas Urban => Jacob Wieland - Spirent
09-10-2018 16:25Tomas UrbanStatusassigned => confirmed
10-10-2018 08:38Jacob Wieland - SpirentFile Added: CR7785-v2.docx
10-10-2018 08:39Jacob Wieland - SpirentNote Added: 0015238
10-10-2018 08:47Jacob Wieland - SpirentStatusconfirmed => new
10-10-2018 08:49Jacob Wieland - SpirentStatusnew => resolved
10-10-2018 08:49Jacob Wieland - SpirentFixed in Version => v4.9.1(ongoing)
10-10-2018 08:49Jacob Wieland - SpirentResolutionopen => fixed
10-10-2018 08:49Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Jens Grabowski
08-08-2019 11:02Jens GrabowskiAssigned ToJens Grabowski => Tomas Urban
08-08-2019 11:02Jens GrabowskiStatusresolved => assigned
08-08-2019 11:02Tomas UrbanStatusassigned => resolved
17-12-2019 12:27Jens GrabowskiAssigned ToTomas Urban => Jens Grabowski
17-12-2019 12:27Jens GrabowskiStatusresolved => assigned
17-12-2019 12:29Jens GrabowskiProjectPart 06: TTCN-3 Control Interface => Ext Pack: Advanced Parametrization (ES 202 784)
17-12-2019 12:30Jens GrabowskiNote Added: 0015549
17-12-2019 12:30Jens GrabowskiStatusassigned => resolved
17-12-2019 12:30Jens GrabowskiFixed in Versionv4.9.1(ongoing) =>
18-12-2019 07:13Jens GrabowskiProjectExt Pack: Advanced Parametrization (ES 202 784) => Ext Pack: Advanced Matching (ES 203 022)
18-12-2019 08:08Jens GrabowskiStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015233) +
+ Tomas Urban    +
+ 09-10-2018 16:25    +
+ 		+ + + + +
+ Proposal created. Please check.
+
+
+
+ + + + + + + + + + +
+ (0015238) +
+ Jacob Wieland - Spirent    +
+ 10-10-2018 08:39    +
+ 		+ + + + +
+ I have checked it and corrected the copy/paste error in the C++ mapping for == and < operators.
+
+Otherwise, seems fine to me.
+
+
+
+ + + + + + + + + + +
+ (0015549) +
+ Jens Grabowski    +
+ 17-12-2019 12:30    +
+ 		+ + + + +
+ Moved from Part 6
+
+ + diff --git a/docs/mantis/CR7786.md b/docs/mantis/CR7786.md new file mode 100644 index 0000000000000000000000000000000000000000..815b43dbc9c66d1bb84e5def13d3b08e7f8e81b2 --- /dev/null +++ b/docs/mantis/CR7786.md @@ -0,0 +1,213 @@ + + + + + + + + + + + + + 0007786: TciCallparameterListType needed to implement component call operation - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007786Part 06: TTCN-3 Control InterfaceNew Featurepublic19-07-2018 16:0716-01-2019 12:42
ReporterJacob Wieland - Spirent 
Assigned ToTomas Urban 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionNext version (to be defined)Fixed in VersionNext version (to be defined) 
Clause Reference(s)??
Source (company - Author)Spirent - Jacob Wieland
Summary0007786: TciCallparameterListType needed to implement component call operation
Descriptionto be able to use the same tci functionality to start and notify termination of a component as it is done with start/done statements for the component call operation, a new sub-interface of TciParameterList is needed that can be used as stand-in for the TciParameterList used by tciStartTC().
+
+public interface TciCallParameterList extends TciParameterList {
+    public Value getResult();
+
+    public void setResult(Value result);
+}
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0007495closed Gyorgy Rethy Part 01: TTCN-3 Core Language out, inout and return value should be assignable via the done/killed statement redirect 
Attached Filesdocx CR7786-v1.docx (261,181) 09-10-2018 13:57
http://oldforge.etsi.org/mantis/file_download.php?file_id=3788&type=bug
docx CR7786-v2.docx (220,753) 10-10-2018 17:10
http://oldforge.etsi.org/mantis/file_download.php?file_id=3797&type=bug
docx CR7786-v3.docx (332,434) 12-10-2018 08:14
http://oldforge.etsi.org/mantis/file_download.php?file_id=3808&type=bug
docx CR7786-v4.docx (272,342) 12-10-2018 08:28
http://oldforge.etsi.org/mantis/file_download.php?file_id=3809&type=bug
Issue History
Date ModifiedUsernameFieldChange
19-07-2018 16:07Jacob Wieland - SpirentNew Issue
19-07-2018 16:07Jacob Wieland - SpirentStatusnew => assigned
19-07-2018 16:07Jacob Wieland - SpirentAssigned To => Tomas Urban
09-10-2018 09:33Tomas UrbanNote Added: 0015217
09-10-2018 09:38Tomas UrbanRelationship addedrelated to 0007495
09-10-2018 13:57Tomas UrbanFile Added: CR7786-v1.docx
09-10-2018 13:58Tomas UrbanNote Added: 0015227
09-10-2018 13:58Tomas UrbanAssigned ToTomas Urban => Jacob Wieland - Spirent
09-10-2018 13:58Tomas UrbanStatusassigned => confirmed
10-10-2018 17:10Jacob Wieland - SpirentFile Added: CR7786-v2.docx
10-10-2018 17:11Jacob Wieland - SpirentNote Added: 0015245
10-10-2018 17:11Jacob Wieland - SpirentStatusconfirmed => resolved
10-10-2018 17:11Jacob Wieland - SpirentFixed in Version => Next version (to be defined)
10-10-2018 17:11Jacob Wieland - SpirentResolutionopen => fixed
10-10-2018 17:11Jacob Wieland - SpirentStatusresolved => feedback
10-10-2018 17:11Jacob Wieland - SpirentResolutionfixed => reopened
10-10-2018 17:11Jacob Wieland - SpirentStatusfeedback => resolved
10-10-2018 17:11Jacob Wieland - SpirentResolutionreopened => fixed
10-10-2018 17:11Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Tomas Urban
11-10-2018 14:16Jens GrabowskiStatusresolved => assigned
12-10-2018 08:14Tomas UrbanFile Added: CR7786-v3.docx
12-10-2018 08:16Tomas UrbanNote Added: 0015263
12-10-2018 08:16Tomas UrbanAssigned ToTomas Urban => Jacob Wieland - Spirent
12-10-2018 08:28Jacob Wieland - SpirentFile Added: CR7786-v4.docx
12-10-2018 08:29Jacob Wieland - SpirentNote Added: 0015268
12-10-2018 08:29Jacob Wieland - SpirentStatusassigned => resolved
12-10-2018 08:29Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Tomas Urban
16-01-2019 12:42Tomas UrbanStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015217) +
+ Tomas Urban    +
+ 09-10-2018 09:33    +
+ 		+ + + + +
+ STF discussion: For backwards compatibility reasons and in order to support remote procedure calls, a different proposal will be implemented:
+1. Two new method pairs will be added to TCI-CH:
+   a. tciCallTestComponent and tciCallTestComponentReq that indicate a start of a call
+   b. tciTestComponentCallOver and tciTestComponentCallOverReq to notify the calling component that call is over and to pass the return value and values of output parameters
+2. No changes in the type system are required
+
+
+
+ + + + + + + + + + +
+ (0015227) +
+ Tomas Urban    +
+ 09-10-2018 13:58    +
+ 		+ + + + +
+ TCI functions and their mapping added. Please check.
+
+
+
+ + + + + + + + + + +
+ (0015245) +
+ Jacob Wieland - Spirent    +
+ 10-10-2018 17:11    +
+ 		+ + + + +
+ changed CallOver to CallTerminated and fixed a typo (was tc instead of tci)
+
+otherwise, fine
+
+
+
+ + + + + + + + + + +
+ (0015263) +
+ Tomas Urban    +
+ 12-10-2018 08:16    +
+ 		+ + + + +
+ TLI changes added to annexes A and B, otherwise unchanged. Please check and if fine mark it as resolved.
+
+
+
+ + + + + + + + + + +
+ (0015268) +
+ Jacob Wieland - Spirent    +
+ 12-10-2018 08:29    +
+ 		+ + + + +
+ small correction evalResult -> tciPars in one place
+
+otherwise, fine
+
+ + diff --git a/docs/mantis/CR7787.md b/docs/mantis/CR7787.md new file mode 100644 index 0000000000000000000000000000000000000000..0d4eb54b9a8b46a8ff43dd01ba9af171eb39eca7 --- /dev/null +++ b/docs/mantis/CR7787.md @@ -0,0 +1,135 @@ + + + + + + + + + + + + + 0007787: typo in section 5.4.1.0 - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007787Part 01: TTCN-3 Core LanguageEditorialpublic14-08-2018 14:2305-01-2019 09:14
ReporterKristóf Szabados 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.10.1 (published 2018-05) 
Target VersionFixed in Version4.11.1 (published 2019-05) 
Clause Reference(s)5.4.1.0
Source (company - Author)L.M. Ericsson
Summary0007787: typo in section 5.4.1.0
Descriptionin section 5.4.1.0 there are these sentences:
+"Formal value or template parameters may be declared fuzzy using the
+@fuzzy modifier. The behaviour of lazy parameters is defined in clause 3.1, definition of fuzzy values or templates."
+
+I believe lazy in the second sentence should be fuzzy
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR-7787-Typo in section 5.4.1.0.docx (66,534) 09-10-2018 09:47
http://oldforge.etsi.org/mantis/file_download.php?file_id=3785&type=bug
Issue History
Date ModifiedUsernameFieldChange
14-08-2018 14:23Kristóf SzabadosNew Issue
08-10-2018 12:38Jens GrabowskiAssigned To => Jens Grabowski
08-10-2018 12:38Jens GrabowskiStatusnew => assigned
09-10-2018 09:47Jens GrabowskiFile Added: CR-7787-Typo in section 5.4.1.0.docx
09-10-2018 09:47Jens GrabowskiNote Added: 0015218
09-10-2018 09:49Jens GrabowskiNote Added: 0015220
09-10-2018 09:49Jens GrabowskiStatusassigned => resolved
09-10-2018 09:49Jens GrabowskiFixed in Version => 4.11.1 (published 2019-05)
09-10-2018 09:49Jens GrabowskiResolutionopen => fixed
09-10-2018 09:49Jens GrabowskiAssigned ToJens Grabowski => Gyorgy Rethy
05-01-2019 09:14Gyorgy RethyNote Added: 0015308
05-01-2019 09:14Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015218) +
+ Jens Grabowski    +
+ 09-10-2018 09:47    +
+ 		+ + + + +
+ Resolved as proposed by reporter.
+
+
+
+ + + + + + + + + + +
+ (0015220) +
+ Jens Grabowski    +
+ 09-10-2018 09:49    +
+ 		+ + + + +
+ Resolved as proposed by reporter.
+
+
+
+ + + + + + + + + + +
+ (0015308) +
+ Gyorgy Rethy    +
+ 05-01-2019 09:14    +
+ 		+ + + + +
+ Added to draft V4.10.2
+
+ + diff --git a/docs/mantis/CR7790.md b/docs/mantis/CR7790.md new file mode 100644 index 0000000000000000000000000000000000000000..ed5ed7a06d9f2eb9e39eaa3589f6fcdb29ff1647 --- /dev/null +++ b/docs/mantis/CR7790.md @@ -0,0 +1,250 @@ + + + + + + + + + + + + + 0007790: Using fuzzy templates in reception statements - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007790Part 01: TTCN-3 Core LanguageClarificationpublic07-09-2018 12:4406-01-2019 09:23
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version4.11.1 (published 2019-05) 
Clause Reference(s)16.1.4
Source (company - Author)STF 548
Summary0007790: Using fuzzy templates in reception statements
DescriptionThe current specification doesn't restrict the use of fuzzy templates in reception statements. There are two rules related to this issue:
+16.1.4.k doesn't allow using fuzzy variables in functions called from special places
+11.2.j sets a restriction on fuzzy template variables content when these variables are used in deterministic context.
+
+When discussing the details with Jacob, the following problem emerged:
+1. There's absolutely no rule for using fuzzy templates that are neither variables nor parameters (static global, local or component-specific templates) in special places listed in 16.1.4
+2. There seem to be different understanding of what the expression "shall not be used" mean in 16.1.4 - does it mean that the listed statements cannot be present at all in called functions (making a static check possible) or that they just cannot be executed during evaluation of the snapshot(implying runtime check for most cases)
+3. It would be useful to allow adding @deterministic modifier to fuzzy template to mark templates that do recalculate their value, but the result of this calculation is always deterministic. It would be especially beneficial if we decide in favour of the static check.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7790.docx (193,698) 10-10-2018 16:27
http://oldforge.etsi.org/mantis/file_download.php?file_id=3796&type=bug
docx CR7790-v2.docx (248,796) 11-10-2018 10:10
http://oldforge.etsi.org/mantis/file_download.php?file_id=3799&type=bug
Issue History
Date ModifiedUsernameFieldChange
07-09-2018 12:44Tomas UrbanNew Issue
08-10-2018 13:15Jens GrabowskiAssigned To => Jacob Wieland - Spirent
08-10-2018 13:15Jens GrabowskiStatusnew => assigned
08-10-2018 13:19Jens GrabowskiNote Added: 0015201
08-10-2018 13:34Jens GrabowskiNote Added: 0015202
10-10-2018 16:27Jacob Wieland - SpirentFile Added: CR7790.docx
10-10-2018 16:29Jacob Wieland - SpirentNote Added: 0015243
10-10-2018 16:29Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Tomas Urban
10-10-2018 16:29Jacob Wieland - SpirentStatusassigned => confirmed
11-10-2018 10:10Tomas UrbanFile Added: CR7790-v2.docx
11-10-2018 10:18Tomas UrbanNote Added: 0015248
11-10-2018 10:18Tomas UrbanAssigned ToTomas Urban => Jacob Wieland - Spirent
11-10-2018 11:17Jacob Wieland - SpirentNote Added: 0015251
11-10-2018 11:17Jacob Wieland - SpirentStatusconfirmed => resolved
11-10-2018 11:17Jacob Wieland - SpirentResolutionopen => fixed
11-10-2018 11:17Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Jens Grabowski
06-01-2019 08:34Gyorgy RethyProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
06-01-2019 09:23Gyorgy RethyNote Added: 0015327
06-01-2019 09:23Gyorgy RethyStatusresolved => closed
06-01-2019 09:23Gyorgy RethyAssigned ToJens Grabowski => Gyorgy Rethy
06-01-2019 09:23Gyorgy RethyFixed in Version => 4.11.1 (published 2019-05)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015201) +
+ Jens Grabowski    +
+ 08-10-2018 13:19    +
+ 		+ + + + +
+ STF discussion: "shall not be used" will be changed to "shall not be present"
+
+(Please have a short look on other usages of "shall not be used". Alternative solution: if "shall not be used" is used consistently used in the standard, then we should define the meaning in the definitions clause.)
+
+
+
+ + + + + + + + + + +
+ (0015202) +
+ Jens Grabowski    +
+ 08-10-2018 13:34    +
+ 		+ + + + +
+ STF discussion: Changes may also be needed in clause 15.0 (add restriction: non-deterministic fuzzy templates cannot be used in deterministic contexts). Changes may also be needed 11.2 (j).
+
+
+
+ + + + + + + + + + +
+ (0015243) +
+ Jacob Wieland - Spirent    +
+ 10-10-2018 16:29    +
+ 		+ + + + +
+ I have added the deterministic modifier to variables (value/template) template definitions, and parameter declarations (value/template). also updated the grammar for this.
+
+Please review
+
+
+
+ + + + + + + + + + +
+ (0015248) +
+ Tomas Urban    +
+ 11-10-2018 10:18    +
+ 		+ + + + +
+ I made some minor corrections:
+
+1. I removed the restriction on actual parameters passed to fuzzy and lazy formal parameters from the section 5.4.1. (formal parameters) and put it with some minor modifications to the section 5.4.2 (actual parameters).
+
+2. Changed the word "value" to "expression" in the restriction on deterministic fuzzy and lazy variable, because IMHO it better describes the content of the RHS (value could also mean the result of evaluation).
+
+Please check and if you are fine with the changes, the CR can be marked as resolved.
+
+
+
+ + + + + + + + + + +
+ (0015251) +
+ Jacob Wieland - Spirent    +
+ 11-10-2018 11:17    +
+ 		+ + + + +
+ change is ok
+
+
+
+ + + + + + + + + + +
+ (0015327) +
+ Gyorgy Rethy    +
+ 06-01-2019 09:23    +
+ 		+ + + + +
+ Added to v4.10.2
+
+ + diff --git a/docs/mantis/CR7791.md b/docs/mantis/CR7791.md new file mode 100644 index 0000000000000000000000000000000000000000..fe73c0df532302f92aa280c24b8b9654654012bb --- /dev/null +++ b/docs/mantis/CR7791.md @@ -0,0 +1,117 @@ + + + + + + + + + + + + + 0007791: Misformulation of clause 19.3 / restriction b) - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - TTCN-3 Change Requests
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007791TTCN-3 Change RequestsClarificationpublic09-09-2018 06:0208-10-2018 13:46
Reporterkovacsa 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionno change required 
PlatformOSOS Version
Clause Reference(s)19.3 / restriction b)
For STF discussion
Source (company - Author)STF 548
Summary0007791: Misformulation of clause 19.3 / restriction b)
DescriptionThe restriction says: "When all templateInstances of all branches can be statically evaluated in compile time to specific values or value ranges no two branches shall match the same value."
+
+However, a case is only bad (i.e. unreachable code) if ALL of its sub-cases are covered by previous cases.
+For the covered cases, one may expect tools to just display a warning.
Steps To ReproduceExample of formulation to be clarified:
+ var integer v_i := 2;
+ 
+ select (v_i) {
+  case(1) {
+   setverdict(fail);
+  }
+  case(0, 2) {
+   setverdict(pass);
+  }
+  case(4, 5, 2) {
+   setverdict(fail);
+  }
+  case else {
+   setverdict(fail);
+  }
+ }
+
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
09-09-2018 06:02kovacsaNew Issue
08-10-2018 13:45Jens GrabowskiNote Added: 0015203
08-10-2018 13:46Jens GrabowskiNote Added: 0015204
08-10-2018 13:46Jens GrabowskiStatusnew => closed
08-10-2018 13:46Jens GrabowskiAssigned To => Jens Grabowski
08-10-2018 13:46Jens GrabowskiResolutionopen => no change required
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015203) +
+ Jens Grabowski    +
+ 08-10-2018 13:45    +
+ 		+ + + + +
+ STF decision: Standard is correct. Duplicate cases should not occur.
+
+
+
+ + + + + + + + + + +
+ (0015204) +
+ Jens Grabowski    +
+ 08-10-2018 13:46    +
+ 		+ + + + +
+ See last comment
+
+ + diff --git a/docs/mantis/CR7797.md b/docs/mantis/CR7797.md new file mode 100644 index 0000000000000000000000000000000000000000..94b5afaf899d0f0bf4637f934599ece496464fae --- /dev/null +++ b/docs/mantis/CR7797.md @@ -0,0 +1,205 @@ + + + + + + + + + + + + + 0007797: Used syntax for length restriction - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007797Part 01: TTCN-3 Core LanguageEditorialpublic20-09-2018 12:1005-01-2019 09:19
ReporterMartin Hauch 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version4.11.1 (published 2019-05) 
Clause Reference(s)ETSI ES 201 873-1 V4.10.1, Chapter 15.11
Source (company - Author)Devoteam- Martin Hauch
Summary0007797: Used syntax for length restriction
DescriptionCore language version 4.10.1 Chapter 15.11
+wrong syntax notation for length restrictions used e.g.
+? length(1, infinity)
+? length(v_int, v_int + 2)
+but should be
+? length(1..infinity)
+? length(v_int .. v_int + 2)
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR-7797-Used syntax for length restriction.docx (72,361) 09-10-2018 14:45
http://oldforge.etsi.org/mantis/file_download.php?file_id=3791&type=bug
Issue History
Date ModifiedUsernameFieldChange
20-09-2018 12:10Martin HauchNew Issue
08-10-2018 13:53Jens GrabowskiAssigned To => Jens Grabowski
08-10-2018 13:53Jens GrabowskiStatusnew => assigned
08-10-2018 13:54Jens GrabowskiNote Added: 0015205
09-10-2018 14:45Jens GrabowskiFile Added: CR-7797-Used syntax for length restriction.docx
09-10-2018 14:46Jens GrabowskiAssigned ToJens Grabowski => Kristóf Szabados
09-10-2018 14:47Jens GrabowskiNote Added: 0015230
09-10-2018 14:47Jens GrabowskiStatusassigned => confirmed
09-10-2018 14:56Kristóf SzabadosNote Added: 0015231
09-10-2018 15:01Kristóf SzabadosProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
09-10-2018 15:02Kristóf SzabadosNote Added: 0015232
09-10-2018 15:02Kristóf SzabadosStatusconfirmed => resolved
09-10-2018 15:02Kristóf SzabadosFixed in Version => 4.11.1 (published 2019-05)
09-10-2018 15:02Kristóf SzabadosResolutionopen => fixed
09-10-2018 15:02Kristóf SzabadosAssigned ToKristóf Szabados => Gyorgy Rethy
05-01-2019 09:19Gyorgy RethyNote Added: 0015309
05-01-2019 09:19Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015205) +
+ Jens Grabowski    +
+ 08-10-2018 13:54    +
+ 		+ + + + +
+ STF discussion: check other length restrictions
+
+
+
+ + + + + + + + + + +
+ (0015230) +
+ Jens Grabowski    +
+ 09-10-2018 14:47    +
+ 		+ + + + +
+ Kristof, please check if I changed the examples correctly.
+
+
+
+ + + + + + + + + + +
+ (0015231) +
+ Kristóf Szabados    +
+ 09-10-2018 14:56    +
+ 		+ + + + +
+ The corrections look fine, and as far as I can tell all length restriction examples in the core standard will now use the correct syntax.
+
+
+
+ + + + + + + + + + +
+ (0015232) +
+ Kristóf Szabados    +
+ 09-10-2018 15:02    +
+ 		+ + + + +
+ fixed, can be included in the next version.
+
+
+
+ + + + + + + + + + +
+ (0015309) +
+ Gyorgy Rethy    +
+ 05-01-2019 09:19    +
+ 		+ + + + +
+ Added to draft V4.10.2
+
+ + diff --git a/docs/mantis/CR7798.md b/docs/mantis/CR7798.md new file mode 100644 index 0000000000000000000000000000000000000000..831a29f346cffefdcc9b7c1152fae1d8fd09ea4e --- /dev/null +++ b/docs/mantis/CR7798.md @@ -0,0 +1,277 @@ + + + + + + + + + + + + + 0007798: Address problems with implicit default alt invocation - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007798Part 01: TTCN-3 Core LanguageNew Featurepublic21-09-2018 08:0708-01-2020 09:25
ReporterJacob Wieland - Spirent 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version4.12.1 (published 2020-05) 
Clause Reference(s)20.2, C.5
Source (company - Author)Spirent - Jacob Wieland
Summary0007798: Address problems with implicit default alt invocation
DescriptionThere's some problems with default alts that sometimes lead to surprising/unexpected results for those developing testcases.
+
+A very common pattern is:
+
+t.start;
+t.timeout;
+
+Almost nobody expects default alternatives to be evaluated when checking for the timeout. But, if some default alternative like
+
+alt { [] p.receive { repeat } }
+
+is active, this will read all messages from the port p while waiting for the timeout (which might carry significance for the rest of the testcase).
+
+Another of those patterns is
+
+comp.start(..)
+comp.done;
+
+A similar problem is if there are multiple channels of communication like the sync communication between components or upper tester communication.
+In such instances, while waiting for the answer on port p1, default alts reading messages from another port can influence the test result negatively.
+
+A possible way to deal with this problem is to add boolean component variables and use them for all guards in default alternatives that should not be active all the time. It is then necessary to set/unset these flags before every alt statement.
+
+Of course, this requires a lot of additional code and is very error prone if the number of flags gets bigger and possibly needs to be amended whenever a new default alternative is added to the testcase.
+
+Ideas to address this problem:
+
+1)
+Default alternatives should be added a category upon activation and alt statements should allow giving one (or maybe a list) of such categories whose defaults should be active.
+
+2)
+For simple non-port alternatives (short form without syntactically enclosing alt like given above), normal defaults should either never be active (unless they are marked specially upon activation) or some modifier @nodefault could be placed in front of them to make it more explicit (to avoid backward incompatibility issues)
+
+3)
+Implicity deactivate all alternatives in defaults which do not deal with the entities in the non-default alt-part. E.g. if an alt statement only treats messages on port p (like the upper tester port), alternatives for ports mapped to the system under test should be inactive for the duration of that alt statement.
+
+Of course, while option 3, in my opinion, would be the most logical solution wich requires the least amount of change by the users and as it is the closest to what people expect when they write an alt statement, it is also the most backward incompatible one (though some of the 'incompability' would probably result in fixing unintended behavior in existing, standardized test suites)
+
+As a compromise between 1 and 3 which is not backward incompatible, the categories given to the alt statement could be the the covered ports/timers/components as a list (normally one) with an additional short-form which results in the semantics of 3 (i.e. active for those entities that are covered by the non-default alternatives).
+
+alt (p, t) { [] p.receive(X) {} [] t.timeout {} }
+// no default alternatives for things not happening on p or t
+
+alt (?) { [] p.receive(X) {} [] t.timeout {} }
+// same semantics as above
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7798.docx (192,796) 06-08-2019 14:59
http://oldforge.etsi.org/mantis/file_download.php?file_id=3819&type=bug
docx CR7798-2.docx (366,108) 07-08-2019 12:47
http://oldforge.etsi.org/mantis/file_download.php?file_id=3831&type=bug
docx CR7798-3.docx (296,378) 07-08-2019 13:34
http://oldforge.etsi.org/mantis/file_download.php?file_id=3835&type=bug
Issue History
Date ModifiedUsernameFieldChange
21-09-2018 08:07Jacob Wieland - SpirentNew Issue
08-10-2018 14:49Jens GrabowskiNote Added: 0015207
08-10-2018 14:50Jens GrabowskiAssigned To => Jens Grabowski
08-10-2018 14:50Jens GrabowskiStatusnew => assigned
06-08-2019 12:28Kristóf SzabadosNote Added: 0015374
06-08-2019 12:28Kristóf SzabadosAssigned ToJens Grabowski => Jacob Wieland - Spirent
06-08-2019 14:59Jacob Wieland - SpirentFile Added: CR7798.docx
06-08-2019 14:59Jacob Wieland - SpirentNote Added: 0015376
06-08-2019 14:59Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Tomas Urban
06-08-2019 14:59Jacob Wieland - SpirentStatusassigned => confirmed
07-08-2019 12:47Tomas UrbanFile Added: CR7798-2.docx
07-08-2019 12:50Tomas UrbanNote Added: 0015401
07-08-2019 12:50Tomas UrbanAssigned ToTomas Urban => Jacob Wieland - Spirent
07-08-2019 13:34Jacob Wieland - SpirentFile Added: CR7798-3.docx
07-08-2019 13:34Jacob Wieland - SpirentNote Added: 0015405
07-08-2019 13:35Jacob Wieland - SpirentStatusconfirmed => resolved
07-08-2019 13:35Jacob Wieland - SpirentResolutionopen => fixed
07-08-2019 13:35Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
08-01-2020 08:54Gyorgy RethyProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
08-01-2020 09:25Gyorgy RethyNote Added: 0015606
08-01-2020 09:25Gyorgy RethyStatusresolved => closed
08-01-2020 09:25Gyorgy RethyFixed in Version => 4.12.1 (published 2020-05)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015207) +
+ Jens Grabowski    +
+ 08-10-2018 14:49    +
+ 		+ + + + +
+ STF discussion: Usefull extensions. It needs to be checked how the extensions may become part of existing features (e.g., call, wait (RT extension), stopping/starting of ports).
+
+
+
+ + + + + + + + + + +
+ (0015374) +
+ Kristóf Szabados    +
+ 06-08-2019 12:28    +
+ 		+ + + + +
+ STF discussion: the @nodefault solution will be elaborated. The semantics should be to ignore all activated defaults for the duration of the following alt statement.
+
+
+
+ + + + + + + + + + +
+ (0015376) +
+ Jacob Wieland - Spirent    +
+ 06-08-2019 14:59    +
+ 		+ + + + +
+ please review
+
+
+
+ + + + + + + + + + +
+ (0015401) +
+ Tomas Urban    +
+ 07-08-2019 12:50    +
+ 		+ + + + +
+ The proposal is fine. I only added missing BNF rules, updated syntax of the related statements and added a restriction on when the modifier can be used. Please check.
+
+
+
+ + + + + + + + + + +
+ (0015405) +
+ Jacob Wieland - Spirent    +
+ 07-08-2019 13:34    +
+ 		+ + + + +
+ Renamed ReceivingCommunicationStatement to ReceivingStatement and added missing CheckStatement to it in BNF
+
+
+
+ + + + + + + + + + +
+ (0015606) +
+ Gyorgy Rethy    +
+ 08-01-2020 09:25    +
+ 		+ + + + +
+ Implemented in final draft V4.11.4
+
+ + diff --git a/docs/mantis/CR7801.md b/docs/mantis/CR7801.md new file mode 100644 index 0000000000000000000000000000000000000000..c5f900a346b2f1b31495b9f648447f0b74aea1bf --- /dev/null +++ b/docs/mantis/CR7801.md @@ -0,0 +1,100 @@ + + + + + + + + + + + + + 0007801: Wrong variable name in example on template concatenation - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007801Part 01: TTCN-3 Core LanguageEditorialpublic26-09-2018 09:1105-01-2019 09:23
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeveritytrivialReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.10.1 (published 2018-05) 
Target VersionFixed in Version4.11.1 (published 2019-05) 
Clause Reference(s)15.11
Source (company - Author)Elvior
Summary0007801: Wrong variable name in example on template concatenation
DescriptionThere's an error in the following line:
+template bitstring mw_mybit4 := '010'B & mw_bit3;
+
+The variable "mw_bit3" is no defined; the correct name should be "mw_mybit3". The variable is mentioned in the comment too.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR-7801-Wrong variable name in example on template concatenation.docx (70,135) 09-10-2018 14:04
http://oldforge.etsi.org/mantis/file_download.php?file_id=3789&type=bug
Issue History
Date ModifiedUsernameFieldChange
26-09-2018 09:11Tomas UrbanNew Issue
08-10-2018 13:47Jens GrabowskiAssigned To => Jens Grabowski
08-10-2018 13:47Jens GrabowskiStatusnew => assigned
09-10-2018 14:04Jens GrabowskiFile Added: CR-7801-Wrong variable name in example on template concatenation.docx
09-10-2018 14:05Jens GrabowskiNote Added: 0015228
09-10-2018 14:05Jens GrabowskiStatusassigned => resolved
09-10-2018 14:05Jens GrabowskiFixed in Version => 4.11.1 (published 2019-05)
09-10-2018 14:05Jens GrabowskiResolutionopen => fixed
09-10-2018 14:05Jens GrabowskiAssigned ToJens Grabowski => Gyorgy Rethy
09-10-2018 14:05Jens GrabowskiStatusresolved => assigned
09-10-2018 14:05Jens GrabowskiStatusassigned => resolved
05-01-2019 09:23Gyorgy RethyNote Added: 0015310
05-01-2019 09:23Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015228) +
+ Jens Grabowski    +
+ 09-10-2018 14:05    +
+ 		+ + + + +
+ Resolved as proposed by reporter.
+
+
+
+ + + + + + + + + + +
+ (0015310) +
+ Gyorgy Rethy    +
+ 05-01-2019 09:23    +
+ 		+ + + + +
+ Added to V4.10.2
+
+ + diff --git a/docs/mantis/CR7804.md b/docs/mantis/CR7804.md new file mode 100644 index 0000000000000000000000000000000000000000..591628aa29092f512de67ae0754f1f40b20a430e --- /dev/null +++ b/docs/mantis/CR7804.md @@ -0,0 +1,109 @@ + + + + + + + + + + + + + 0007804: Wrong result in examples on list template concatenation - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007804Part 01: TTCN-3 Core LanguageEditorialpublic26-09-2018 13:1705-01-2019 09:33
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.10.1 (published 2018-05) 
Target VersionFixed in Version4.11.1 (published 2019-05) 
Clause Reference(s)15.11
Source (company - Author)Elvior
Summary0007804: Wrong result in examples on list template concatenation
DescriptionIn the example 2 on template concatenation the following part contains wrong results:
+
+:
+          v_recofChar := { "ABC" } & ? length(v_int) & { "EF" };
+        //results in the template { "ABC", ?, ?, ?, "EF" }
+      p.receive ( mw_myRecofCharPar(3) );
+        //actual content of mw_myRecofCharPar is { "ABC", ?, ?, ?, ?, "EF" }
+
+the results should be:
+{ "ABC", * length(3), "EF" }
+{ "ABC", *, * length(3), "EF" }
+
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR-7804-Wrong result in examples on list template concatenation.docx (72,133) 09-10-2018 14:15
http://oldforge.etsi.org/mantis/file_download.php?file_id=3790&type=bug
Issue History
Date ModifiedUsernameFieldChange
26-09-2018 13:17Tomas UrbanNew Issue
08-10-2018 13:52Jens GrabowskiAssigned To => Jens Grabowski
08-10-2018 13:52Jens GrabowskiStatusnew => assigned
09-10-2018 14:15Jens GrabowskiFile Added: CR-7804-Wrong result in examples on list template concatenation.docx
09-10-2018 14:16Jens GrabowskiNote Added: 0015229
09-10-2018 14:16Jens GrabowskiStatusassigned => resolved
09-10-2018 14:16Jens GrabowskiFixed in Version => 4.11.1 (published 2019-05)
09-10-2018 14:16Jens GrabowskiResolutionopen => fixed
09-10-2018 14:16Jens GrabowskiAssigned ToJens Grabowski => Gyorgy Rethy
05-01-2019 09:33Gyorgy RethyNote Added: 0015311
05-01-2019 09:33Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015229) +
+ Jens Grabowski    +
+ 09-10-2018 14:16    +
+ 		+ + + + +
+ Resolved according to the proposal of the reporter.
+
+
+
+ + + + + + + + + + +
+ (0015311) +
+ Gyorgy Rethy    +
+ 05-01-2019 09:33    +
+ 		+ + + + +
+ Added to draft V4.10.2
+
+ + diff --git a/docs/mantis/CR7805.md b/docs/mantis/CR7805.md new file mode 100644 index 0000000000000000000000000000000000000000..cc5b31f1d70c4c6fbbd019aabffbb00aa48290c6 --- /dev/null +++ b/docs/mantis/CR7805.md @@ -0,0 +1,1073 @@ + + + + + + + + + + + + + 0007805: Support of ASN.1 sequence with extension containing mandatory fields - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 07: Using ASN.1 with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007805Part 07: Using ASN.1 with TTCN-3Technicalpublic07-10-2018 11:5229-12-2019 14:22
ReporterWolfgang Seka 
Assigned ToGyorgy Rethy 
PriorityhighSeveritymajorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Versionv4.8.1 (published 2020-05) 
Clause Reference(s)ES 201 873-1 clause 15
Source (company - Author)     MCC160 (Wolfgang)
Summary0007805: Support of ASN.1 sequence with extension containing mandatory fields
DescriptionThe extension of an ASN.1 sequence may consist of optional and mandatory fields.
+Nevertheless even if it has mandatory fields the extension as a whole need not to be present in a message.
+But it seems that TTCN-3 has no means to express this properly in templates: There is no way to explicitly address an extension and therefore no way to specify its presence.
+In addition at least some of the tools do not allow to omit the mandatory fields of an extension (what could be considered as workaround even though it is not really a solution).
+
+
+EXAMPLE:
+ASN.1 type definition
+    My-Field-Type ::= INTEGER (0..255)
+    My-Extended-Sequence ::= SEQUENCE {
+        field1 My-Field-Type,
+        ...
+        [[
+            field2 My-Field-Type,
+            field3 My-Field-Type OPTIONAL
+        ]]
+    }
+
+In TTCN there is no way to have a template explicitly specifying that the extension with field2, field3 shall not be there in a message to be sent out and there is no way to specify something like "{field2:=*, field3:=?} ifpresent" in a receive template.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7805.docx (158,802) 11-10-2018 15:20
http://oldforge.etsi.org/mantis/file_download.php?file_id=3804&type=bug
docx CR7805_v2.docx (158,108) 11-10-2018 16:43
http://oldforge.etsi.org/mantis/file_download.php?file_id=3807&type=bug
Issue History
Date ModifiedUsernameFieldChange
07-10-2018 11:52Wolfgang SekaNew Issue
07-10-2018 12:44Wolfgang SekaNote Added: 0015195
08-10-2018 11:35Jacob Wieland - SpirentNote Added: 0015196
08-10-2018 11:36Jacob Wieland - SpirentNote Added: 0015197
08-10-2018 11:40Jacob Wieland - SpirentNote Edited: 0015197bug_revision_view_page.php?bugnote_id=15197#r485
08-10-2018 11:44Wolfgang SekaNote Added: 0015198
08-10-2018 12:24Jacob Wieland - SpirentNote Added: 0015199
08-10-2018 12:25Jacob Wieland - SpirentNote Edited: 0015199bug_revision_view_page.php?bugnote_id=15199#r487
08-10-2018 13:09Wolfgang SekaNote Added: 0015200
08-10-2018 14:14Jens GrabowskiAssigned To => Kristóf Szabados
08-10-2018 14:14Jens GrabowskiStatusnew => assigned
08-10-2018 14:23Martin HauchNote Added: 0015206
08-10-2018 15:23Jens GrabowskiNote Added: 0015208
09-10-2018 07:57Jacob Wieland - SpirentNote Added: 0015210
09-10-2018 08:14Jacob Wieland - SpirentNote Added: 0015211
09-10-2018 08:38Jacob Wieland - SpirentNote Added: 0015212
09-10-2018 08:47Martin HauchNote Added: 0015213
09-10-2018 09:04Jacob Wieland - SpirentNote Added: 0015214
09-10-2018 09:21Martin HauchNote Added: 0015215
09-10-2018 09:48Jacob Wieland - SpirentNote Added: 0015219
09-10-2018 10:20Wolfgang SekaNote Added: 0015221
09-10-2018 12:52Martin HauchNote Added: 0015226
10-10-2018 10:08Jacob Wieland - SpirentNote Added: 0015239
11-10-2018 15:20Kristóf SzabadosFile Added: CR7805.docx
11-10-2018 15:20Kristóf SzabadosAssigned ToKristóf Szabados => Gyorgy Rethy
11-10-2018 15:21Kristóf SzabadosNote Added: 0015258
11-10-2018 16:43Kristóf SzabadosFile Added: CR7805_v2.docx
07-08-2019 12:25Kristóf SzabadosNote Added: 0015398
07-08-2019 12:25Kristóf SzabadosStatusassigned => resolved
07-08-2019 12:25Kristóf SzabadosResolutionopen => fixed
29-12-2019 11:34Gyorgy RethyNote Added: 0015603
29-12-2019 11:36Gyorgy RethyNote Edited: 0015603bug_revision_view_page.php?bugnote_id=15603#r505
29-12-2019 14:19Gyorgy RethyProjectTTCN-3 Change Requests => Part 07: Using ASN.1 with TTCN-3
29-12-2019 14:22Gyorgy RethyNote Added: 0015605
29-12-2019 14:22Gyorgy RethyStatusresolved => closed
29-12-2019 14:22Gyorgy RethyFixed in Version => v4.8.1 (published 2020-05)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015195) +
+ Wolfgang Seka    +
+ 07-10-2018 12:44    +
+ 		+ + + + +
+ Correction: In the example it shall be "{field2:=?, field3:=*} ifpresent"
+
+
+
+ + + + + + + + + + +
+ (0015196) +
+ Jacob Wieland - Spirent    +
+ 08-10-2018 11:35    +
+ 		+ + + + +
+ The solution could be to map the type to a (private) type with all extension fields optional and then derive a subtype of that type with a restriction:
+
+({field2 := omit, field3 := omit},{field2 := ?})
+
+or to be general, if your extension fields are named f1 ... fn and of those fields g1 .. gm are mandatory:
+
+({f1 := omit, ..., fn := omit},{g1 := ?, ..., gm := ?})
+
+
+
+ + + + + + + + + + +
+ (0015197) +
+ Jacob Wieland - Spirent    +
+ 08-10-2018 11:36    +
(edited on: 08-10-2018 11:40)
+ 		+ + + + +
+ The base type could simply be named like the original type with an underscore added at the end. Since there's no hyphen allowed at the end of ASN.1 identifiers, this can't clash with any other mapped names.
+
+Thus, the whole mapping of your example would be:
+
+    type integer My_Field_Type (0..255);
+
+    private type record My_Extended_Sequence_ {
+        My_Field_Type field1,
+        My_Field_Type field2 optional,
+        My_Field_Type field3 optional
+    }
+    
+    type My_Extended_Sequence_ My_Extended_Sequence
+    ({field2:= omit, field3 := omit},
+     {field2:=?})
+
+
+
+
+
+ + + + + + + + + + +
+ (0015198) +
+ Wolfgang Seka    +
+ 08-10-2018 11:44    +
+ 		+ + + + +
+ An important requirement which I've forgotten to mention:
+Any potential solution needs to be backward compatible as we already have hundreds of ASN.1 type definitions with extensions (but most of them with all fields being optional).
+
+
+
+ + + + + + + + + + +
+ (0015199) +
+ Jacob Wieland - Spirent    +
+ 08-10-2018 12:24    +
(edited on: 08-10-2018 12:25)
+ 		+ + + + +
+ Well, I assumed that, which is why I proposed my solution which should be fully backward compatible with former mapping and all values that conform to the ASN.1 restrictions.
+
+The additional private type is just necessary because for now it is not possible to add subtype restrictions directly to structured type definitions.
+
+
+
+
+
+ + + + + + + + + + +
+ (0015200) +
+ Wolfgang Seka    +
+ 08-10-2018 13:09    +
+ 		+ + + + +
+ OK - with the proposed mapping it means that the following templates are supported:
+
+    template (value) My_Extended_Sequence cs_My_Extended_Sequence1 := {
+      field1 := 42,
+      field2 := omit,
+      field3 := omit
+    };
+    template (value) My_Extended_Sequence cs_My_Extended_Sequence2 := {
+      field1 := 42,
+      field2 := 49,
+      field3 := omit // or any valid value
+    };
+    template (present) My_Extended_Sequence cr_My_Extended_Sequence1 := {
+      field1 := ?,
+      field2 := omit,
+      field3 := omit
+    };
+    template (present) My_Extended_Sequence cr_My_Extended_Sequence2 := {
+      field1 := ?,
+      field2 := *,
+      field3 := *
+    };
+the following template may/should cause a compiler error
+    template (present) My_Extended_Sequence cr_My_Extended_Sequence3 := {
+      field1 := ?,
+      field2 := *,
+      field3 := ?
+    };
+
+=> there would be no issue for the TTCN-3 core language (part 1) but a requirement for compilers what may need clarification in part 9 (as at least for now there are compilers raising an error if field2 is omitted).
+
+=> even though it is not a perfect solution (as it may cause confusions for TTCN writers and readers), assuming that mandatory fields in ASN.1 extensions are an exceptional case, the proposed solution would serve the purpose.
+
+
+
+ + + + + + + + + + +
+ (0015206) +
+ Martin Hauch    +
+ 08-10-2018 14:23    +
+ 		+ + + + +
+ The mapping to a (new and different) private type seems to be no solution, because the new defined type is not compatible to the original type (see chapter 6.3.2 core language):
+
+record types are compatible if the number, and optional aspect of the fields in the textual order of definition are identical, the types of each field are compatible and the value of each existing field of the value "b" is compatible with the type of its corresponding field in type "A". The value of each field in the value "b" is assigned to the corresponding field in the value of type "A".
+
+Also the encoding result (e.g. in PER encoding) is not the same for both types.
+
+In my opinion the writing of templates for extended ASN.1 types must be rendered more precisely to represent the ASN.1 semantic correctly. E.g. in templates of types with extensions, the extended fields can be set to omit or left out at all, although they are mandatory. This should be posssible, because the import-statement from ASN.1 modules is like
+
+    import from EUTRA_RRC_ASN1_Definitions language "ASN.1:2002" all with {encode "UNALIGNED_PER_OctetAligned"};
+
+This declares the semantic of types from this module kind and corresponding templates!
+
+
+Templates of the protocol version1 of an extensible type cannot know names of extension-fields and so fields of extensions cannot
+be assigned:
+
+// version1
+My-Extended-Sequence ::= SEQUENCE {
+    field1 My-Field-Type,
+    ...
+}
+
+template My_Extended_Sequence tVersion1:= { field1:=0 };
+
+
+In a later protocol version2 the type might be extended. But the old template must still be valid.
+
+// version2
+My-Extended-Sequence ::= SEQUENCE {
+    field1 My-Field-Type,
+    ...
+    [[
+        field2 My-Field-Type,
+        field3 My-Field-Type OPTIONAL
+    ]]
+}
+
+// version2
+template My_Extended_Sequence tVersion2_2:= {
+    field1:=0,
+    field2:=1, // this field is mandatory if an extension is present
+    field3:=omit
+}
+
+And if we receive a message with template tVersion2_2 from a version2 SUT by protocol version1, this should match template tVersion1, because all conditions of protocol version1 are fulfilled!
+The received message might have additional extended information (which will be skipped by protocol version1), but this was the reason to define the type extensible!
+
+Also, a template definition like tVersion1 in version1 must be valid in version2:
+
+// version2
+template My_Extended_Sequence tVersion2_1:= { field1:=0 };
+
+Because of the semantic for extensible ASN.1-types and the backwards compatibility to previous protocol versions, this is a valid template! The mandatory/optional semantic of TTCN-3 can only be applied
+for the root-fields of the sequence-type. Template definitions for extended types have to respect the semantic of the ASN.1 definition.
+
+
+
+ + + + + + + + + + +
+ (0015208) +
+ Jens Grabowski    +
+ 08-10-2018 15:23    +
+ 		+ + + + +
+ STF proposal:
+Dedicated syntax for record and set types, some examples.
+
+type record MyRecord {
+ integer field1,
+ extension {
+   integer field2,
+   integer field3 optional
+ }
+}
+
+
+
+ + + + + + + + + + +
+ (0015210) +
+ Jacob Wieland - Spirent    +
+ 09-10-2018 07:57    +
+ 		+ + + + +
+ In response to Martin Hauch's comment:
+
+First of all, type compatibility is given, have no idea what would violate the rules. There's no new type introduced for protocol version 2, the old type is replaced and if you defined the templates properly future-proof, they will be compatible with the new extended type without any change.
+
+Second of all, if you want to have that kind of backward compatibility for receive templates of extensible types, you need to define them future-proof, for instance by using modifies:
+
+template My_Extended_Sequence tVersion1:= modifies ? := { field1:=0 };
+// will set all optional fields (of extensions) to *
+
+This will match both a message of protocol version 1 and will ignore additional fields of newer protocol versions.
+
+For send templates, you need to declare them with the attribute optional "implicit omit" to have that kind of backward compatibility.
+
+
+
+ + + + + + + + + + +
+ (0015211) +
+ Jacob Wieland - Spirent    +
+ 09-10-2018 08:14    +
+ 		+ + + + +
+ We propose to to simply change the extension mandatory fields to TTCN-3 optional fields in the ASN.1 to TTCN-3 mapping and tools should check for the addtional constraints concerning these fields.
+
+This will allow defining templates in the way described above so that they will work with all protocol versions.
+
+Also, if a tool doesn't check for the additional constraints, at least it won't reject values/templates statically which define the mandatory fields with omit anymore.
+
+
+
+ + + + + + + + + + +
+ (0015212) +
+ Jacob Wieland - Spirent    +
+ 09-10-2018 08:38    +
+ 		+ + + + +
+ Regarding your question about how to express templates that check for constraints on extensions only if they are there you can use the following coding pattern for each extension:
+
+template My_Extended_Sequence ifpresentExt1(template My_Extended_Sequence t) :=
+  (t, modifies ? := {field2 := omit, field3 := omit})
+
+Each template that checks just for some constraints on the extension part should be formulated like this:
+
+template My_Extended_Sequence mwExt1 :=
+  modifies ? := { field2 := ..., field3 := ... }
+
+Then template ifpresentExt1(mwExt1) checks the constraints for extension 1 only if at least one of its fields is present.
+
+With advanced matching templates, you can then combine such templates with other templates (say, if you want to check for constraints on multiple extensions simultaneaously)
+
+
+
+ + + + + + + + + + +
+ (0015213) +
+ Martin Hauch    +
+ 09-10-2018 08:47    +
+ 		+ + + + +
+ RESPONSE to Jakob Wieland (15210,15211)
+
+The type
+    private type record My_Extended_Sequence_ {
+        My_Field_Type field1,
+        My_Field_Type field2 optional,
+        My_Field_Type field3 optional
+    }
+is not compatible to
+    My-Extended-Sequence ::= SEQUENCE {
+        field1 My-Field-Type,
+        ...
+        [[
+            field2 My-Field-Type,
+            field3 My-Field-Type OPTIONAL
+        ]]
+    }
+because field2 must be present if the extension group is used. The TTCN-3 type also allows omit as value!
+The TTCN-3 type does not represent the extensions and groups, so encoding and decoding cannot be handled correctly.
+
+template MyExtended_Sequence_ tInvalid:= {field1:=1, field2:=omit, field3:=3};
+This is not a valid template for the original type definition My-Extended-Sequence in the ASN.1-module, but for type My_Extended_Sequence_!
+
+
+
+ + + + + + + + + + +
+ (0015214) +
+ Jacob Wieland - Spirent    +
+ 09-10-2018 09:04    +
+ 		+ + + + +
+ Sorry, the type is compatible with what is described by the ASN.1 type. In general, the extension fields are all optional, they just need to be present under some circumstances.
+
+There is no way in TTCN-3 to express such conditional optionality on the type level (unless using subtype restrictions, as proposed in comment http://oldforge.etsi.org/mantis/view.php?id=7805#c15197 [^]).
+
+Subtype restrictions do not have an effect on type compatibility (other than that empty types are not allowed).
+
+template MyExtended_Sequence_ tInvalid:= {field1:=1, field2:=omit, field3:=3}
+
+is an invalid template as it would violate the subtyping constraints: not both extension fields are omit, therefore, field2 must be matched by ? which is only the case if it is not omit, therefore, any tool that would check for the proposed subtyping constraints would reject the template as invalid.
+
+
+
+ + + + + + + + + + +
+ (0015215) +
+ Martin Hauch    +
+ 09-10-2018 09:21    +
+ 		+ + + + +
+ RESPONSE to Jens Grabowski (15208)
+
+Mapping the ASN.1 extensible types to a new type-definition does not solve the problem.
+1. No backward compatibility, because definitions of templates for existing extended types are no longer valid.
+2. The result of encoding a value of the new type is generally not the same as the encoding of the original type.
+3. New rules for renaming fields have to be assigned, because "extension" could also be the name of a root field or later defined extensions.
+
+Again the definition of templates for extensible ASN.1 types simply has to be described more precisely, and type mapping as proposed is not necessary.
+
+Templates for extensible ASN.1 types allow to leave out mandatory fields of extensions. This ensures the backward compatibility for
+templates that are defined using only root-fields (e.g. templates of the 1st version of the ASN.1 module definition). Semantic-Checker
+for TTCN-3 and ASN.1 should be able to recognize extended type-fields and allow to leave out these fields in template definition. And the
+semantic check should also be able to recognize incorrect templates for an extended ASN.1 type.
+
+Look the following extended type:
+
+My-Extended-Sequence ::= SEQUENCE {
+    field1 My-Field-Type,
+    ...
+    [[
+        field2 My-Field-Type,
+        field3 My-Field-Type OPTIONAL
+    ]],
+    field4 My-Field-Type,
+    field5 MyField-Type OPTIONAL,
+    field6 My-Field-Type
+}
+
+
+template My_Extended_Sequence t1:={field1:=1};
+// is valid, all root-fields are assigned, the value is not extended in case of sending.
+// an extended received value is not known in version 1 and the extended fields cannot be checked (skipped).
+// an extended received value in a later version can be checked if the template uses the extension-fields.
+// This template could be used for all current and future versions of this type.
+
+template My_Extended_Sequence t2:={field1:=1, field2:= 2, field3:=omit};
+// is valid,all root-fields are assigned, all fields of the first group-extension are assigned.
+
+template My_Extended_Sequence t3_invalid:= {field1:=1, field4:=4};
+// is invalid because extension field4 is assigned and previous defined extensions are missing.
+
+template My_Extended_Sequence t3:= {field1:=1, field2:= 2, field3:=omit, field4:=4};
+// is valid, all root-fields are assigned, all fields of the first group-extension are assigned, extension field4 is assigned.
+
+template MyExtended_Sequence t3:= {field1:=1, field2:= 2, field3:=omit, field4:=4, field6:=6};
+// Either the template is valid, because field5 is optional (and is handled implicit as omit),
+// or it is not valid because the template is not completely assigned ( omit must be assigned explicit to field5).
+
+template MyExtended_Sequence t4:= {field1:=1, field2:= 2, field3:=omit, field4:=4, field5:= omit, field6:=6};
+// is valid, all root-fields are assigned, all extension-fields up to field6 are assigned, omit is allowed for optional field5.
+
+template MyExtended_Sequence t5:= {field1:=1, field2:= 2, field3:=omit, field4:=4, field5:= 5};
+// is valid, all root-fields are assigned, all extension-fields up to field5 are assigned.
+
+This semantic has to be checked by the TTCN-3 compiler and ASN.1 tools. This should be possible, as the
+TTCN-3 parser recognizes, that an imported module is an ASN.1 module (from import statement in TTCN-3 module)!
+This is also completely backward compatible, because nothing has to be changed in the syntax for templates.
+So simply, only the semantic for ASN.1 extensible type templates must be defined more precisely.
+
+_
+
+
+
+ + + + + + + + + + +
+ (0015219) +
+ Jacob Wieland - Spirent    +
+ 09-10-2018 09:48    +
+ 		+ + + + +
+ In response to http://oldforge.etsi.org/mantis/view.php?id=7805#c15215 [^]
+
+The templates t1, t2 are only valid, if you add the 'optional' attribute as "implicit omit". Otherwise, they will be invalid. There is no way to express non-root fields in TTCN-3 as you are suggesting. TTCN-3 does not distinguish between root fields and extension fields. This would have to be a completely new feature (with probably wide-ranging consequences for type compatibility etc.).
+
+t3_invalid would be valid if optional "implicit omit" is added (This should be done in general for templates of extensible types, that's what we introduced the feature for).
+
+t3 (both versions) again is only valid if 'implicit omit' is given. Otherwise, it's invalid as TTCN-3 forces you to give all fields explicitly or leaves them uninitialized (which has a different semantic than omit).
+
+t4 is valid
+
+t5 is invalid (see above)
+
+Also, the TTCN-3 abstracts from encoding, so dealing with the encoding of extension fields is outside of the scope of the ASN.1 to TTCN-3 mapping. Codecs have to deal with it properly, of course (they need to know which fields are root, which are non-root and which are extension). This has no bearing on the mapping to TTCN-3 types and their corresponding templates/values.
+
+Giving the proposed subtype constraints models the ASN.1 type semantics on TTCN-3 values precisely (it accepts all valid, fully specified values/templates and rejects all invalid ones).
+
+
+
+ + + + + + + + + + +
+ (0015221) +
+ Wolfgang Seka    +
+ 09-10-2018 10:20    +
+ 		+ + + + +
+ First of all - as said already - I can live with the approach to treat all fields of ASN.1 extensions as being optional in the first place even though from TTCN-3 user's point of view this may be confusing.
+Nevertheless there is another aspect:
+Assuming all fields on an extension being optional it may make a difference whether the whole extension is not present or it is present but all its fields are omitted.
+According to my knowledge this cannot be distinguished by current means of TTCN.
+=> in principle a notation as proposed by Jens would be the real and easy-to-understand solution but I don't know how this approach could be made backward compatible.
+(somehow an optional sub-grouping notation for templates would be needed ...)
+
+
+
+ + + + + + + + + + +
+ (0015226) +
+ Martin Hauch    +
+ 09-10-2018 12:52    +
+ 		+ + + + +
+ RESPONSE to Wolfgang Seka (0015221):
+As far as I analyze the ASN.1 syntax, it is not possible to specify an extended type value without defining at least one extension-field with a value. As ASN.1 values could not assign omit to a field (omit is handled by field is not assigned in value-notation) an extended message-value without at least one extension field value, cannot be defined. If not at least one exteded field is assigned, then the value is not extended (e.g.only uses the root-fields of the type).
+The sub-grouping solution complicates the template-definitions, because rules for field-renaming must be defined. Also this type-mapping does not represent the ASN.1 semantic.
+Handling ASN.1 extensions as being optional is ok, but the name of the type should be the original mapping of ASN.1 type identifier to TTCN-3 type identifier (without appending '_')!
+
+
+
+ + + + + + + + + + +
+ (0015239) +
+ Jacob Wieland - Spirent    +
+ 10-10-2018 10:08    +
+ 		+ + + + +
+ Response to: http://oldforge.etsi.org/mantis/view.php?id=7805#c15226 [^]
+
+First of all, for the ASN.1 to TTCN-3 mapping, it is completely irrelevant how values are represented in ASN.1 language notation or in encodings. We are only concerned how they are represented in TTCN-3 and that it is possible with the information contained in these values to encode/decode them correctly according to the ASN.1 specification of their type (and of course that the TTCN-3 value universe of the type is isomorphic to the ASN.1 value universe of the corresponding ASN.1 type). Thus, we do not distinguish on the TTCN-3 level between extended and unextended values. All must conform to the same type specification.
+
+The internal (hence, private!, i.e. invisible, inaccessible to the user) name with the underscore is just a proposed workaround around the syntactical TTCN-3 restriction that a subtype restriction cannot be added directly to a record type definition.
+
+Ideally, of course, we would like to map it to a definition like this:
+
+type record My_Extended_Type { ... }
+(extRestriction1)
+(extRestriction2)
+...
+(extRestrictionN)
+
+But, since that isn't allowed, a chain of type definitions needs to be used ending with the non-internal type definition with the equivalent semantic of the ASN.1 type.
+If there are several extensions, you need one subtyping definition for each additional extension to get the final public type (with the proper original name) to have a conjunction constraint of all the chained subtyping constraints.
+Finally, subtypes are always type compatible with their supertypes and the root type is obviously the one where all the extension fields are optional.
+All values of these types would have the potential for all the extension fields, it's just a matter of taste whether you define them with implicit or explicit omits and whether you want to use refactoring on old templates when the type system is updated with new extension or want to use future-proof code instead (as has been outlined).
+
+The proposal with the new extension syntax given by Jens does not introduce new fields with the name 'extension'. The proposed extension keyword followed by a field declaration block would have exactly the same syntactic and semantic function as the [[ ]] brackets in ASN.1, i.e. it would introduce all the fields contained as optional fields of the containing type while implicitly adding the proper constraints on those fields to the type (i.e. mandatory fields present if one of the fields contained is present). Therefore, there's no nameclashing problem, as there is no new name introduced and also no new scope in the value. That means, there is no complication added and the type mapping is a 1-to-1 representation of the ASN.1 semantic.
+
+
+
+ + + + + + + + + + +
+ (0015258) +
+ Kristóf Szabados    +
+ 11-10-2018 15:21    +
+ 		+ + + + +
+ Gyorgy, please check the uploaded proposal.
+
+
+
+ + + + + + + + + + +
+ (0015398) +
+ Kristóf Szabados    +
+ 07-08-2019 12:25    +
+ 		+ + + + +
+ Please check it.
+
+
+
+ + + + + + + + + + +
+ (0015603) +
+ Gyorgy Rethy    +
+ 29-12-2019 11:34    +
(edited on: 29-12-2019 11:36)
+ 		+ + + + +
+ Resolution is OK with me.
+
+
+
+
+
+ + + + + + + + + + +
+ (0015605) +
+ Gyorgy Rethy    +
+ 29-12-2019 14:22    +
+ 		+ + + + +
+ Included in final draft V4.7.2
+
+ + diff --git a/docs/mantis/CR7806.md b/docs/mantis/CR7806.md new file mode 100644 index 0000000000000000000000000000000000000000..b06af0a6b035b5addcc6626d518c10881a2c0790 --- /dev/null +++ b/docs/mantis/CR7806.md @@ -0,0 +1,97 @@ + + + + + + + + + + + + + 0007806: TCI update: module control function - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007806Part 06: TTCN-3 Control InterfaceTechnicalpublic10-10-2018 11:3216-01-2019 12:42
ReporterTomas Urban 
Assigned ToTomas Urban 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Clause Reference(s)6.1.1
Source (company - Author)STF 550
Summary0007806: TCI update: module control function
DescriptionThe new version of the core language standard allows to use parameters and return values in the module control function. Support for these entities shall be added to the TCI.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0007465closed Gyorgy Rethy Part 01: TTCN-3 Core Language control part should be able to have a runs on clause and call other control parts 
Attached Filesdocx CR7806-v1.docx (726,053) 11-10-2018 13:05
http://oldforge.etsi.org/mantis/file_download.php?file_id=3802&type=bug
Issue History
Date ModifiedUsernameFieldChange
10-10-2018 11:32Tomas UrbanNew Issue
10-10-2018 11:32Tomas UrbanStatusnew => assigned
10-10-2018 11:32Tomas UrbanAssigned To => Tomas Urban
10-10-2018 11:32Tomas UrbanRelationship addedrelated to 0007465
11-10-2018 13:05Tomas UrbanFile Added: CR7806-v1.docx
11-10-2018 13:06Tomas UrbanNote Added: 0015254
11-10-2018 13:06Tomas UrbanAssigned ToTomas Urban => Jacob Wieland - Spirent
11-10-2018 13:06Tomas UrbanStatusassigned => confirmed
11-10-2018 16:57Jacob Wieland - SpirentNote Added: 0015262
11-10-2018 16:57Jacob Wieland - SpirentStatusconfirmed => resolved
11-10-2018 16:57Jacob Wieland - SpirentResolutionopen => fixed
11-10-2018 16:57Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Tomas Urban
16-01-2019 12:42Tomas UrbanStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015254) +
+ Tomas Urban    +
+ 11-10-2018 13:06    +
+ 		+ + + + +
+ Proposal uploaded. Please check.
+
+
+
+ + + + + + + + + + +
+ (0015262) +
+ Jacob Wieland - Spirent    +
+ 11-10-2018 16:57    +
+ 		+ + + + +
+ looks good to me
+
+ + diff --git a/docs/mantis/CR7807.md b/docs/mantis/CR7807.md new file mode 100644 index 0000000000000000000000000000000000000000..ef3957ad9674ed9c84718a7dea31e59c3801bed1 --- /dev/null +++ b/docs/mantis/CR7807.md @@ -0,0 +1,163 @@ + + + + + + + + + + + + + 0007807: Generalizing the modifies operation - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007807Part 01: TTCN-3 Core LanguageNew Featurepublic11-10-2018 08:5806-01-2019 08:50
ReporterJacob Wieland - Spirent 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version4.11.1 (published 2019-05) 
Clause Reference(s)15.4
Source (company - Author)Spirent - Jacob Wieland
Summary0007807: Generalizing the modifies operation
DescriptionAt the moment, it is very restricted where you can use modifies, even though it is a powerful and useful construct.
+
+It would be useful if the result of a modification could be directly used inside of a template expression (TemplateBody).
+
+Also, at the moment, it is unclear what it means if a partially initialized variable (template or not) appears in the modification operand of the modifies construct. From the text it appears that it would possibly just overwrite the corresponding part in the parent template, but that would lead to assignments of uninitialized parts (circumventing the rule that you cannot un-initialize something already initialized).
+
+Instead, uninitialized fields in the modification part should be treated as 'unchanged' for the purpose of the modification algorithm.
+
+This has the property that it doesn't matter whether I first assign the modification to a variable and then use the variable or write the same syntax in the modification directly:
+
+var MyRecord x := { f1 := 1, f2 := - } // f2 remains uninitialized
+template MyRecord t modifies t2 := x; // f2 remains unchanged
+
+would be the same as
+
+template MyRecord t modifies t2 := { f1 := 1, f2 := - }
+
+This has the advantage that modifications can be stored in variables, passed around as parameters and be reused and even modified themselves.
+
+Syntactically, because the current 'inline' version of modifies has the confusing assignment symbol, we should instead introduce a new mixfix operator:
+
+modifies <ParentTemplate> { with <ModificationTemplate> }+
+
+The grammar should be amended in the following way:
+
+Rename the rule of TemplateBody to BaseTemplateBody
+
+Introduce new rules:
+
+TemplateBody ::= BaseTemplateBody | DerivedTemplateBody
+DerivedTemplateBody ::= ModifiesKeyword BaseTemplateBody {WithKeyword BaseTemplateBody}+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7807.docx (181,870) 12-10-2018 10:01
http://oldforge.etsi.org/mantis/file_download.php?file_id=3810&type=bug
Issue History
Date ModifiedUsernameFieldChange
11-10-2018 08:58Jacob Wieland - SpirentNew Issue
11-10-2018 11:58Jacob Wieland - SpirentAssigned To => Jacob Wieland - Spirent
11-10-2018 11:58Jacob Wieland - SpirentStatusnew => assigned
12-10-2018 10:01Jacob Wieland - SpirentFile Added: CR7807.docx
12-10-2018 10:03Jacob Wieland - SpirentNote Added: 0015269
12-10-2018 10:04Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Tomas Urban
12-10-2018 10:04Jacob Wieland - SpirentStatusassigned => confirmed
12-10-2018 10:57Tomas UrbanNote Added: 0015270
12-10-2018 10:57Tomas UrbanStatusconfirmed => resolved
12-10-2018 10:57Tomas UrbanResolutionopen => fixed
12-10-2018 10:57Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
06-01-2019 08:22Gyorgy RethyProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
06-01-2019 08:50Gyorgy RethyNote Added: 0015325
06-01-2019 08:50Gyorgy RethyStatusresolved => closed
06-01-2019 08:50Gyorgy RethyFixed in Version => 4.11.1 (published 2019-05)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015269) +
+ Jacob Wieland - Spirent    +
+ 12-10-2018 10:03    +
+ 		+ + + + +
+ As the 'with' clashes with the with-part (at least if repeated) and the := syntax and the with syntax are so similar in placement, I just generalized the modified template to a TemplateBody and distinguish between TemplateBody, DerivedTemplateBody (the inline modifies construct) and BaseTemplateBody (all other template body constructions) where the left and right hand side of DerivedTemplateBody can only be BaseTemplateBody (to avoid weird stacking of modifies without giving parantheses).
+
+Please check.
+
+
+
+ + + + + + + + + + +
+ (0015270) +
+ Tomas Urban    +
+ 12-10-2018 10:57    +
+ 		+ + + + +
+ Reviewed. No issues found. Can be added to the next version of the core language specification.
+
+
+
+ + + + + + + + + + +
+ (0015325) +
+ Gyorgy Rethy    +
+ 06-01-2019 08:50    +
+ 		+ + + + +
+ Added to draft v4.10.2
+
+ + diff --git a/docs/mantis/CR7809.md b/docs/mantis/CR7809.md new file mode 100644 index 0000000000000000000000000000000000000000..f8404faab8d1f05e0739f8ed15b587becb5c84a7 --- /dev/null +++ b/docs/mantis/CR7809.md @@ -0,0 +1,99 @@ + + + + + + + + + + + + + 0007809: TLI: Possibility to catch any exception of a specified signature - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007809Part 06: TTCN-3 Control InterfaceNew Featurepublic11-10-2018 15:2812-10-2018 08:19
ReporterJacob Wieland - Spirent 
Assigned ToTomas Urban 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionno change required 
PlatformOSOS Version
Product Version 
Target VersionNext version (to be defined)Fixed in Version 
Clause Reference(s)7, 8, 9, 10, 11, 12, A, B.5
Source (company - Author)Spirent - Jacob Wieland
Summary0007809: TLI: Possibility to catch any exception of a specified signature
DescriptionIf the expected exception of the signature is optional, the respective fields in the TLI also need to be optional.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0007721closed Gyorgy Rethy Part 01: TTCN-3 Core Language Possibility to catch any exception of a specified signature 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
11-10-2018 15:28Jacob Wieland - SpirentNew Issue
11-10-2018 15:28Jacob Wieland - SpirentStatusnew => assigned
11-10-2018 15:28Jacob Wieland - SpirentAssigned To => Jacob Wieland - Spirent
11-10-2018 15:30Jacob Wieland - SpirentRelationship addedrelated to 0007721
12-10-2018 08:16Jacob Wieland - SpirentNote Added: 0015264
12-10-2018 08:17Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Tomas Urban
12-10-2018 08:17Jacob Wieland - SpirentStatusassigned => confirmed
12-10-2018 08:19Tomas UrbanNote Added: 0015266
12-10-2018 08:19Tomas UrbanStatusconfirmed => closed
12-10-2018 08:19Tomas UrbanResolutionopen => no change required
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015264) +
+ Jacob Wieland - Spirent    +
+ 12-10-2018 08:16    +
+ 		+ + + + +
+ The relevant parameter excTmpl in the tliPrCatch-family is already modelled as a TciValueTemplate which can be used to describe an untyped 'any' (and is used for untyped receive for instance).
+
+So, nothing needs to be done here.
+
+
+
+ + + + + + + + + + +
+ (0015266) +
+ Tomas Urban    +
+ 12-10-2018 08:19    +
+ 		+ + + + +
+ Issue closed as no changes are required in the TCI standard.
+
+ + diff --git a/docs/mantis/CR7812.md b/docs/mantis/CR7812.md new file mode 100644 index 0000000000000000000000000000000000000000..ce3ee747319a0e3a69f8f61e5f3083ca356dbd9b --- /dev/null +++ b/docs/mantis/CR7812.md @@ -0,0 +1,272 @@ + + + + + + + + + + + + + 0007812: mtc and system clauses in behaviour types - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Behaviour Types (ES 202 785)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007812Ext Pack: Behaviour Types (ES 202 785)New Featurepublic07-11-2018 10:2017-12-2019 11:03
ReporterTomas Urban 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv1.5.1 (published 2017-08) 
Target VersionFixed in Versionv1.7.1 (published 2020-05) 
Clause Reference(s)5.2
Source (company - Author)Elvior
Summary0007812: mtc and system clauses in behaviour types
DescriptionThe specification doesn't contain any rule for the mtc clause. The system clause is possible only on test case level while it can occur on the function and altstep level as well.
+Support for the missing clauses should be added to the BNF, behaviour type definition and compatibility rules.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7812-1.docx (160,126) 07-08-2019 11:46
http://oldforge.etsi.org/mantis/file_download.php?file_id=3829&type=bug
docx CR7812-2.docx (162,773) 07-08-2019 13:28
http://oldforge.etsi.org/mantis/file_download.php?file_id=3834&type=bug
docx CR7812-3.docx (142,525) 07-08-2019 13:40
http://oldforge.etsi.org/mantis/file_download.php?file_id=3836&type=bug
Issue History
Date ModifiedUsernameFieldChange
07-11-2018 10:20Tomas UrbanNew Issue
07-11-2018 10:37Tomas UrbanNote Added: 0015277
18-12-2018 11:40Jens GrabowskiNote Added: 0015286
18-12-2018 11:40Jens GrabowskiAssigned To => Tomas Urban
18-12-2018 11:40Jens GrabowskiStatusnew => assigned
18-12-2018 11:41Jens GrabowskiNote Added: 0015287
07-08-2019 11:46Tomas UrbanFile Added: CR7812-1.docx
07-08-2019 11:46Tomas UrbanNote Added: 0015393
07-08-2019 11:46Tomas UrbanAssigned ToTomas Urban => Jacob Wieland - Spirent
07-08-2019 11:46Tomas UrbanStatusassigned => confirmed
07-08-2019 13:20Jacob Wieland - SpirentNote Added: 0015402
07-08-2019 13:20Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Tomas Urban
07-08-2019 13:20Jacob Wieland - SpirentStatusconfirmed => assigned
07-08-2019 13:21Tomas UrbanFile Added: CR7812-2.docx
07-08-2019 13:22Tomas UrbanFile Deleted: CR7812-2.docx
07-08-2019 13:28Tomas UrbanFile Added: CR7812-2.docx
07-08-2019 13:29Tomas UrbanNote Added: 0015404
07-08-2019 13:29Tomas UrbanAssigned ToTomas Urban => Jacob Wieland - Spirent
07-08-2019 13:29Tomas UrbanStatusassigned => confirmed
07-08-2019 13:40Jacob Wieland - SpirentFile Added: CR7812-3.docx
07-08-2019 13:41Jacob Wieland - SpirentNote Added: 0015406
07-08-2019 13:41Jacob Wieland - SpirentStatusconfirmed => resolved
07-08-2019 13:41Jacob Wieland - SpirentFixed in Version => v1.7.1 (published 2020-05)
07-08-2019 13:41Jacob Wieland - SpirentResolutionopen => fixed
07-08-2019 13:41Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Jens Grabowski
17-12-2019 11:03Jens GrabowskiStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015277) +
+ Tomas Urban    +
+ 07-11-2018 10:37    +
+ 		+ + + + +
+ The clauses are defined for deferred behaviour types only.
+
+
+
+ + + + + + + + + + +
+ (0015286) +
+ Jens Grabowski    +
+ 18-12-2018 11:40    +
+ 		+ + + + +
+ STF discussion: Tomas will provide a solution.
+
+
+
+ + + + + + + + + + +
+ (0015287) +
+ Jens Grabowski    +
+ 18-12-2018 11:41    +
+ 		+ + + + +
+ Moved to 2019 STF.
+
+
+
+ + + + + + + + + + +
+ (0015393) +
+ Tomas Urban    +
+ 07-08-2019 11:46    +
+ 		+ + + + +
+ Proposal uploaded, please check.
+
+
+
+ + + + + + + + + + +
+ (0015402) +
+ Jacob Wieland - Spirent    +
+ 07-08-2019 13:20    +
+ 		+ + + + +
+ use testcase in bold form to reference testcase types
+
+reference the clauses for runs on, system and mtc compatibility for describing the compatibility of objects with their types.
+
+
+
+ + + + + + + + + + +
+ (0015404) +
+ Tomas Urban    +
+ 07-08-2019 13:29    +
+ 		+ + + + +
+ Please check the updated version.
+
+
+
+ + + + + + + + + + +
+ (0015406) +
+ Jacob Wieland - Spirent    +
+ 07-08-2019 13:41    +
+ 		+ + + + +
+ fixed a typo (replacement of runs on with mtc for the mtc clause compatibility)
+
+Otherwise, ok.
+
+ + diff --git a/docs/mantis/CR7813.md b/docs/mantis/CR7813.md new file mode 100644 index 0000000000000000000000000000000000000000..8479c1118caa2653a0fc642bcc6261bbeddee31f --- /dev/null +++ b/docs/mantis/CR7813.md @@ -0,0 +1,235 @@ + + + + + + + + + + + + + 0007813: Missing template restrictions in return clause declaration - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007813Part 01: TTCN-3 Core LanguageEditorialpublic07-11-2018 13:2228-12-2019 17:08
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeveritytrivialReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version4.12.1 (published 2020-05) 
Clause Reference(s)16.1.0
Source (company - Author)Elvior
Summary0007813: Missing template restrictions in return clause declaration
DescriptionAt the moment, the syntactical description of the function return clause in 16.1.0 doesn't contain template restrictions. However, this restriction is allowed by the BNF and it is also mentioned in the semantic description of 16.1.0.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7813-1.docx (188,171) 07-08-2019 07:51
http://oldforge.etsi.org/mantis/file_download.php?file_id=3822&type=bug
docx CR7813-2.docx (200,985) 07-08-2019 15:14
http://oldforge.etsi.org/mantis/file_download.php?file_id=3838&type=bug
Issue History
Date ModifiedUsernameFieldChange
07-11-2018 13:22Tomas UrbanNew Issue
18-12-2018 11:43Jens GrabowskiNote Added: 0015288
18-12-2018 11:43Jens GrabowskiAssigned To => Tomas Urban
18-12-2018 11:43Jens GrabowskiStatusnew => assigned
18-12-2018 11:43Jens GrabowskiNote Added: 0015289
07-08-2019 07:51Tomas UrbanFile Added: CR7813-1.docx
07-08-2019 07:51Tomas UrbanNote Added: 0015379
07-08-2019 07:51Tomas UrbanAssigned ToTomas Urban => Jacob Wieland - Spirent
07-08-2019 07:51Tomas UrbanStatusassigned => confirmed
07-08-2019 15:14Jacob Wieland - SpirentFile Added: CR7813-2.docx
07-08-2019 15:16Jacob Wieland - SpirentNote Added: 0015415
07-08-2019 15:16Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Tomas Urban
07-08-2019 15:16Jacob Wieland - SpirentStatusconfirmed => assigned
07-08-2019 15:16Jacob Wieland - SpirentStatusassigned => confirmed
08-08-2019 07:46Tomas UrbanNote Added: 0015418
08-08-2019 07:46Tomas UrbanStatusconfirmed => resolved
08-08-2019 07:46Tomas UrbanResolutionopen => fixed
08-08-2019 07:46Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
28-12-2019 17:08Gyorgy RethyNote Added: 0015598
28-12-2019 17:08Gyorgy RethyStatusresolved => closed
28-12-2019 17:08Gyorgy RethyFixed in Version => 4.12.1 (published 2020-05)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015288) +
+ Jens Grabowski    +
+ 18-12-2018 11:43    +
+ 		+ + + + +
+ STF 550: Update the syntactical syntax structure.
+
+
+
+ + + + + + + + + + +
+ (0015289) +
+ Jens Grabowski    +
+ 18-12-2018 11:43    +
+ 		+ + + + +
+ Proposal will be developed by 2019 STF.
+
+
+
+ + + + + + + + + + +
+ (0015379) +
+ Tomas Urban    +
+ 07-08-2019 07:51    +
+ 		+ + + + +
+ Resolution uploaded. Please check.
+
+
+
+ + + + + + + + + + +
+ (0015415) +
+ Jacob Wieland - Spirent    +
+ 07-08-2019 15:16    +
+ 		+ + + + +
+ I have replaced the common 'template [restriction]' with TemplateModifier and for global template definitions with template [TemplateRestriction].
+
+I have also added a new rule TemplateModifier which maps to (TemplateKeyword | RestrictedTemplate) and replaced all occurrences of this pattern with references to TemplateModifier
+
+
+
+ + + + + + + + + + +
+ (0015418) +
+ Tomas Urban    +
+ 08-08-2019 07:46    +
+ 		+ + + + +
+ The proposed changes resolve the described issue and fix the problem with the omit keyword. The changes can be added to the next version of the core language specification.
+
+
+
+ + + + + + + + + + +
+ (0015598) +
+ Gyorgy Rethy    +
+ 28-12-2019 17:08    +
+ 		+ + + + +
+ Included to final draft V4.11.2.
+
+ + diff --git a/docs/mantis/CR7816.md b/docs/mantis/CR7816.md new file mode 100644 index 0000000000000000000000000000000000000000..238e5e75a65681f80cf5445d477d9546ed8f68c5 --- /dev/null +++ b/docs/mantis/CR7816.md @@ -0,0 +1,237 @@ + + + + + + + + + + + + + 0007816: There should be some way to determine what to log as 'TriMessage' for xtriSend - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Extended TRI (ES 202 789)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007816Ext Pack: Extended TRI (ES 202 789)New Featurepublic03-12-2018 17:4317-12-2019 14:15
ReporterJacob Wieland - Spirent 
Assigned ToTomas Urban 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv1.5.1 (ongoing) 
Target VersionNext version (to be defined)Fixed in Version 
Clause Reference(s)7, 8, 9, 10, 11, 12, A, B.5
Source (company - Author)Spirent - Jacob Wieland
Summary0007816: There should be some way to determine what to log as 'TriMessage' for xtriSend
DescriptionWhen sending values over a port that is implemented via xtriSend, no encoding needs to take place before calling the xtriSend function and there might even be no codec for the value in question as the 'send' might convert the value to some other data structure and not really produce a 'message'.
+
+Nevertheless, it would be useful if the user could provide some way of display string for the sent value so that can be logged via the msg parameter in the tliMSend_m function.
+
+Thus we propose to introduce a function xtriDisplay(Value) which returns a TriMessage which then can be logged. This should also be called for all parameters in procedure based communication as well as the reply value to provide useful input for the appropriate logging functions.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7816-1.docx (153,209) 08-08-2019 09:34
http://oldforge.etsi.org/mantis/file_download.php?file_id=3844&type=bug
Issue History
Date ModifiedUsernameFieldChange
03-12-2018 17:43Jacob Wieland - SpirentNew Issue
18-12-2018 11:44Jens GrabowskiNote Added: 0015290
18-12-2018 11:44Jens GrabowskiAssigned To => Jens Grabowski
18-12-2018 11:44Jens GrabowskiStatusnew => assigned
06-08-2019 08:30Jens GrabowskiNote Added: 0015362
06-08-2019 08:31Jens GrabowskiAssigned ToJens Grabowski => Tomas Urban
07-08-2019 12:08Kristóf SzabadosNote Added: 0015396
08-08-2019 09:34Tomas UrbanFile Added: CR7816-1.docx
08-08-2019 09:35Tomas UrbanNote Added: 0015424
08-08-2019 09:35Tomas UrbanAssigned ToTomas Urban => Jacob Wieland - Spirent
08-08-2019 09:35Tomas UrbanStatusassigned => confirmed
08-08-2019 10:17Jacob Wieland - SpirentNote Added: 0015431
08-08-2019 10:17Jacob Wieland - SpirentStatusconfirmed => resolved
08-08-2019 10:17Jacob Wieland - SpirentResolutionopen => fixed
08-08-2019 10:17Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Tomas Urban
17-12-2019 14:15Tomas UrbanNote Added: 0015560
17-12-2019 14:15Tomas UrbanStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015290) +
+ Jens Grabowski    +
+ 18-12-2018 11:44    +
+ 		+ + + + +
+ STF decision: To be discussed in 2019.
+
+
+
+ + + + + + + + + + +
+ (0015362) +
+ Jens Grabowski    +
+ 06-08-2019 08:30    +
+ 		+ + + + +
+ Tomas, can you have a look?
+
+
+
+ + + + + + + + + + +
+ (0015396) +
+ Kristóf Szabados    +
+ 07-08-2019 12:08    +
+ 		+ + + + +
+ STF discussion: proposal accepted.
+
+
+
+ + + + + + + + + + +
+ (0015424) +
+ Tomas Urban    +
+ 08-08-2019 09:35    +
+ 		+ + + + +
+ Resolution uploaded. Please check.
+
+
+
+ + + + + + + + + + +
+ (0015431) +
+ Jacob Wieland - Spirent    +
+ 08-08-2019 10:17    +
+ 		+ + + + +
+ resolution is ok
+
+
+
+ + + + + + + + + + +
+ (0015560) +
+ Tomas Urban    +
+ 17-12-2019 14:15    +
+ 		+ + + + +
+ Added to the final draft for approval.
+
+ + diff --git a/docs/mantis/CR7817.md b/docs/mantis/CR7817.md new file mode 100644 index 0000000000000000000000000000000000000000..aa346b2a693a8d214af283d398a1089126cd10e4 --- /dev/null +++ b/docs/mantis/CR7817.md @@ -0,0 +1,111 @@ + + + + + + + + + + + + + 0007817: Invalid conversion of complex type with simple content in example - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007817Part 09: Using XML with TTCN-3Technicalpublic05-12-2018 08:5012-03-2019 14:33
ReporterTomas Urban 
Assigned To 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionno change required 
PlatformOSOS Version
Product Versionv4.9.1 (published 2018-05) 
Target VersionFixed in Version 
Clause Reference(s)7.6.1.1
For STF discussion
Source (company - Author)Elvior
Summary0007817: Invalid conversion of complex type with simple content in example
DescriptionThe example 1 of 7.6.1.1 converts two types correctly as a synonym type, but the first type called "complex-base-simple" is converted to a type with a record wrapper.
+
+This should not be the case, because there's no exception to the synonym rule: "If the definition of a new named or unnamed complex type uses another simple or complex type as the base of the extension without changing the base type (i.e. no facet is applied and no attribute is added), it shall be translated to a TTCN-3 type synonym to the base type (see clause 6.4 of ETSI ES 201 873-1 [1]), completed with necessary additional encoding instructions (see clause 7.6 rule 1)."
+
+The correct result of the conversion should be:
+type XSD.Integer Complex_base_simple
+with {
+   variant "name as 'complex-base-simple'"
+}
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
05-12-2018 08:50Tomas UrbanNew Issue
15-12-2018 08:38Kristóf SzabadosNote Added: 0015280
17-12-2018 09:34Tomas UrbanNote Added: 0015281
17-12-2018 09:34Tomas UrbanStatusnew => closed
17-12-2018 09:34Tomas UrbanResolutionopen => no change required
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015280) +
+ Kristóf Szabados    +
+ 15-12-2018 08:38    +
+ 		+ + + + +
+ I might be missing something, but the result mentioned to be correct looks like the same as the one in section 7.6.1.1 at the bottom of the page.
+"
+type XSD.Integer Complex_base_simple
+with {
+  variant "name as 'complex-base-simple'"
+};
+"
+
+
+
+ + + + + + + + + + +
+ (0015281) +
+ Tomas Urban    +
+ 17-12-2018 09:34    +
+ 		+ + + + +
+ Correct. Unfortunately I checked the older standard where the example wasn't corrected. Changed to closed.
+
+ + diff --git a/docs/mantis/CR7818.md b/docs/mantis/CR7818.md new file mode 100644 index 0000000000000000000000000000000000000000..f757cbef7ea510a97558bf0b61afd9a198d4c8ab --- /dev/null +++ b/docs/mantis/CR7818.md @@ -0,0 +1,132 @@ + + + + + + + + + + + + + 0007818: Dynamic Matching: wrong type used for template mw_closeTo - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Advanced Matching (ES 203 022)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007818Ext Pack: Advanced Matching (ES 203 022)Editorialpublic05-12-2018 15:1417-12-2019 10:11
ReporterMartin Hauch 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Clause Reference(s)5.1
Source (company - Author)Devoteam - Martin Hauch
TS version?
Summary0007818: Dynamic Matching: wrong type used for template mw_closeTo
DescriptionExample in Chapter 5.1:
+Type of template mw_closeTo must be changed to Coordinate, because the @dynamic match-code uses 'value' as a parameter of type Coordinate (function fx_distance)
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7818.docx (124,351) 06-08-2019 08:17
http://oldforge.etsi.org/mantis/file_download.php?file_id=3813&type=bug
Issue History
Date ModifiedUsernameFieldChange
05-12-2018 15:14Martin HauchNew Issue
18-12-2018 11:13Jens GrabowskiNote Added: 0015282
18-12-2018 11:13Jens GrabowskiAssigned To => Jacob Wieland - Spirent
18-12-2018 11:13Jens GrabowskiStatusnew => assigned
06-08-2019 08:17Jacob Wieland - SpirentFile Added: CR7818.docx
06-08-2019 08:17Jacob Wieland - SpirentNote Added: 0015358
06-08-2019 08:17Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Tomas Urban
06-08-2019 08:17Jacob Wieland - SpirentStatusassigned => confirmed
07-08-2019 09:02Tomas UrbanNote Added: 0015388
07-08-2019 09:02Tomas UrbanStatusconfirmed => resolved
07-08-2019 09:02Tomas UrbanResolutionopen => fixed
07-08-2019 09:02Tomas UrbanAssigned ToTomas Urban => Jens Grabowski
17-12-2019 10:11Jens GrabowskiStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015282) +
+ Jens Grabowski    +
+ 18-12-2018 11:13    +
+ 		+ + + + +
+ STF decision: CR is correct, editorial change will be implemented in 2019.
+
+
+
+ + + + + + + + + + +
+ (0015358) +
+ Jacob Wieland - Spirent    +
+ 06-08-2019 08:17    +
+ 		+ + + + +
+ please review
+
+
+
+ + + + + + + + + + +
+ (0015388) +
+ Tomas Urban    +
+ 07-08-2019 09:02    +
+ 		+ + + + +
+ Proposed resolution fixes the reported issue and it can be added to the next version of the standard.
+
+ + diff --git a/docs/mantis/CR7819.md b/docs/mantis/CR7819.md new file mode 100644 index 0000000000000000000000000000000000000000..85aeca9b6305026ee71ff579e55a9a72e1c17e57 --- /dev/null +++ b/docs/mantis/CR7819.md @@ -0,0 +1,213 @@ + + + + + + + + + + + + + 0007819: semantic of (Restriction a):The dynamic matching syntax shall only be used in a typed context. - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Advanced Matching (ES 203 022)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007819Ext Pack: Advanced Matching (ES 203 022)Clarificationpublic05-12-2018 15:3017-12-2019 10:10
ReporterMartin Hauch 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Clause Reference(s)5.1
Source (company - Author)Devoteam - Martin Hauch
TS version?
Summary0007819: semantic of (Restriction a):The dynamic matching syntax shall only be used in a typed context.
DescriptionWhat exactly does this mean? Which of the following examples are allowed or not?
+p.receive(@dynamic { if (5==value) { return true;} else {return false;}}
+
+p.receive(@dynamic { if (fx_distance({0.0,0.0},value)<10.0 and value.x>5.0)
+                        {return true;}
+                      else {return false;}
+
+function anytypeEval(anytype param) return boolean { .....return(true);}
+// type is determined by receive-parameter
+p.receive(integer:@dynamic anytypeEval);
+
+// type is determined by function fx_isPrime
+p.receive (@dynamic {return fx_isPrime(value);}
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7819.docx (124,478) 08-08-2019 08:49
http://oldforge.etsi.org/mantis/file_download.php?file_id=3841&type=bug
Issue History
Date ModifiedUsernameFieldChange
05-12-2018 15:30Martin HauchNew Issue
18-12-2018 11:27Jens GrabowskiNote Added: 0015284
18-12-2018 11:28Jens GrabowskiAssigned To => Jacob Wieland - Spirent
18-12-2018 11:28Jens GrabowskiStatusnew => assigned
06-08-2019 07:52Jacob Wieland - SpirentNote Added: 0015354
07-08-2019 12:21Kristóf SzabadosNote Added: 0015397
08-08-2019 08:49Jacob Wieland - SpirentFile Added: CR7819.docx
08-08-2019 08:50Jacob Wieland - SpirentNote Added: 0015421
08-08-2019 08:50Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Tomas Urban
08-08-2019 08:50Jacob Wieland - SpirentStatusassigned => confirmed
08-08-2019 09:57Tomas UrbanNote Added: 0015428
08-08-2019 09:57Tomas UrbanStatusconfirmed => resolved
08-08-2019 09:57Tomas UrbanResolutionopen => fixed
08-08-2019 09:57Tomas UrbanAssigned ToTomas Urban => Jens Grabowski
17-12-2019 10:10Jens GrabowskiStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015284) +
+ Jens Grabowski    +
+ 18-12-2018 11:27    +
+ 		+ + + + +
+ STF discussion: TTCN-3 maintenance STF in 2019 will check if additional clarification for "typed context" is needed. First 2 examples are not allowed, third example is wrong, fourth example requires discussion.
+
+
+
+ + + + + + + + + + +
+ (0015354) +
+ Jacob Wieland - Spirent    +
+ 06-08-2019 07:52    +
+ 		+ + + + +
+ The core standard document defines "type context" in the definitions section. In that document, it is mainly used for disambiguation of enumeration literals, but the usage is the same for the @dynamic matching construct, i.e. the type where the @dynamic is used must be known, either from the place of usage (actual parameter to a typed formal parameter, right hand side of a typed declaration) or from prefixing it with the type in otherwise untyped contexts (like receive, log arguments or arguments of other operations that have no typed parameters like isvalue).
+
+Therefore, I think the standard is clear enough on that issue. We could do a slight rewording from "a typed context" to "the context of a type" (which is used in the definitions section), but I am unsure whether this will lead to a higher clarity.
+
+
+
+ + + + + + + + + + +
+ (0015397) +
+ Kristóf Szabados    +
+ 07-08-2019 12:21    +
+ 		+ + + + +
+ STF discussion: change typed context to inner type context and reference core standard definitions part. Allow exception for that rule for short notation.
+
+
+
+ + + + + + + + + + +
+ (0015421) +
+ Jacob Wieland - Spirent    +
+ 08-08-2019 08:50    +
+ 		+ + + + +
+ please review
+
+
+
+ + + + + + + + + + +
+ (0015428) +
+ Tomas Urban    +
+ 08-08-2019 09:57    +
+ 		+ + + + +
+ The proposal resolves the described issue and can be added to the next version of the specification.
+
+ + diff --git a/docs/mantis/CR7820.md b/docs/mantis/CR7820.md new file mode 100644 index 0000000000000000000000000000000000000000..774e5e62d2a58a65460257257a99c5aaa9bedbca --- /dev/null +++ b/docs/mantis/CR7820.md @@ -0,0 +1,139 @@ + + + + + + + + + + + + + 0007820: Wrong definition of templates in EXAMPLE. - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Advanced Matching (ES 203 022)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007820Ext Pack: Advanced Matching (ES 203 022)Editorialpublic06-12-2018 07:0017-12-2019 10:11
ReporterMartin Hauch 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Clause Reference(s)5.2.1
Source (company - Author)Devoteam - Martin Hauch
TS version?
Summary0007820: Wrong definition of templates in EXAMPLE.
DescriptionThe examples for template mw_t1 and mw_t2 are defined without parameters,although they are defined with a "value retrieval assignment".
+correct definition:
+template integer mw_t1(out integer v) := (?, (1..3) -> v); // mw_t1 always matches, but if the (1..3) does not
+// contribute to the successful match
+// then v is not assigned a value
+template integer mw_t2(out integer v_small,out integer v_big) :=
+      ((1..3) -> v_small, (3..5) -> v_big)
+// matching mw_t2 to number in (1..3) will cause only v_small to be assigned,
+// matching it to number in (4..5) will cause only v_big to be assigned (preference of (1..3))
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0007821closed Jens Grabowski Clarify semantic of examples (usage of value-lists and value retrieval assignment) 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
06-12-2018 07:00Martin HauchNew Issue
18-12-2018 11:18Jens GrabowskiNote Added: 0015283
18-12-2018 11:18Jens GrabowskiAssigned To => Jacob Wieland - Spirent
18-12-2018 11:18Jens GrabowskiStatusnew => assigned
06-08-2019 08:19Jacob Wieland - SpirentRelationship addedrelated to 0007821
06-08-2019 08:19Jacob Wieland - SpirentNote Added: 0015359
06-08-2019 08:20Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Tomas Urban
06-08-2019 08:20Jacob Wieland - SpirentStatusassigned => confirmed
07-08-2019 08:59Tomas UrbanNote Added: 0015387
07-08-2019 08:59Tomas UrbanStatusconfirmed => resolved
07-08-2019 08:59Tomas UrbanResolutionopen => fixed
07-08-2019 08:59Tomas UrbanAssigned ToTomas Urban => Jens Grabowski
17-12-2019 10:11Jens GrabowskiStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015283) +
+ Jens Grabowski    +
+ 18-12-2018 11:18    +
+ 		+ + + + +
+ STF discussion: Missing parameters will be added in 2019.
+
+
+
+ + + + + + + + + + +
+ (0015359) +
+ Jacob Wieland - Spirent    +
+ 06-08-2019 08:19    +
+ 		+ + + + +
+ change implemented in proposal of 7821
+
+
+
+ + + + + + + + + + +
+ (0015387) +
+ Tomas Urban    +
+ 07-08-2019 08:59    +
+ 		+ + + + +
+ The resolution of the related CR fixes the reported issue.
+
+ + diff --git a/docs/mantis/CR7821.md b/docs/mantis/CR7821.md new file mode 100644 index 0000000000000000000000000000000000000000..efe35cc6da7d13bf924550f80837ca6022d2cbb9 --- /dev/null +++ b/docs/mantis/CR7821.md @@ -0,0 +1,226 @@ + + + + + + + + + + + + + 0007821: Clarify semantic of examples (usage of value-lists and value retrieval assignment) - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Advanced Matching (ES 203 022)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007821Ext Pack: Advanced Matching (ES 203 022)Clarificationpublic06-12-2018 07:4417-12-2019 10:12
ReporterMartin Hauch 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Clause Reference(s)5.2.1
Source (company - Author)Devoteam - Martin Hauch
TS version?
Summary0007821: Clarify semantic of examples (usage of value-lists and value retrieval assignment)
DescriptionComments of template mw_t1 definition describes, that variable v is assigned for values 1..3 (previous matching-value AnyValue in the value-list also matches these values).
+Comments of template mw_t2 definition describes, that in case of value 3 only v_small is assigend (preference of (1..3))
+
+mw_t2 seems to be clear, as the first matching-value in the value-list is taken and the belonging value retrieval assignment is executed.
+But in mw_t1 the first matching-value in the value-list matches, why should further values also be checked? Or should they only be checked if a value retrieval assignment is used?
+What about the following example:
+type record MyMessage {
+integer f1,
+integer f2
+}
+template MyMessage t1(out integer p_f1) :={f1:=? ->p_f1,f2:=10};
+template MyMessage t2(out integer p_f2) :={f1:=10,f2:=? ->p_f2};
+template MyMessage t3 :={f1:=(1..10),f2:=10};
+template MyMessage tVal(out integer p_f1, out integer p_f2):=(t3, t1(p_f1),t2(p_f2));
+Which elements of the value-list should be evaluated in case of {f1:=10, f2:=10}?
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0007820closed Jens Grabowski Wrong definition of templates in EXAMPLE. 
Attached Filesdocx CR7821.docx (125,746) 06-08-2019 08:10
http://oldforge.etsi.org/mantis/file_download.php?file_id=3812&type=bug
Issue History
Date ModifiedUsernameFieldChange
06-12-2018 07:44Martin HauchNew Issue
18-12-2018 11:37Jens GrabowskiNote Added: 0015285
18-12-2018 11:37Jens GrabowskiAssigned To => Jacob Wieland - Spirent
18-12-2018 11:37Jens GrabowskiStatusnew => assigned
14-01-2019 09:25Martin HauchNote Added: 0015328
22-01-2019 14:21Jacob Wieland - SpirentNote Added: 0015329
06-08-2019 08:10Jacob Wieland - SpirentFile Added: CR7821.docx
06-08-2019 08:11Jacob Wieland - SpirentNote Added: 0015356
06-08-2019 08:11Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Tomas Urban
06-08-2019 08:11Jacob Wieland - SpirentStatusassigned => confirmed
06-08-2019 08:19Jacob Wieland - SpirentRelationship addedrelated to 0007820
07-08-2019 08:58Tomas UrbanNote Added: 0015386
07-08-2019 08:58Tomas UrbanStatusconfirmed => resolved
07-08-2019 08:58Tomas UrbanResolutionopen => fixed
07-08-2019 08:58Tomas UrbanAssigned ToTomas Urban => Jens Grabowski
17-12-2019 10:12Jens GrabowskiStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015285) +
+ Jens Grabowski    +
+ 18-12-2018 11:37    +
+ 		+ + + + +
+ STF discussion: the example is correct (except missing parameters) and the variables are not assigned while matching. Same is true for the example provided by the reporter. Next TTCN-3 maintenance STF will check if a clarification is needed.
+
+
+(@Martin Hauch: Can you pinpoint the sentences which are unclear in the description?)
+
+
+
+ + + + + + + + + + +
+ (0015328) +
+ Martin Hauch    +
+ 14-01-2019 09:25    +
+ 		+ + + + +
+ The comments regarding the tempates mw_t1, mw_t2 contradict themselves.
+Comment regarding template mw_t1 suggests, that v is assigned in case of value in range (1..3), but first value-list-elemnt '?'
+still matches any integer value and so in my opinion variable v should never be assgigned!
+Comment regarding template mw_t2 suggests, that v_big is not assigned in case of value 3, but value 3 also matches range (3..5)!
+So the comments to these examples contradict themselves, because first example always tries to match second value-list-element, but
+second example does not match the 2nd value-list-element (in case of value 3).
+
+(@Jens Grabowski: Which parameters to you mean are missing in the example with templates t1,t2,t3,tVal?)
+
+
+
+ + + + + + + + + + +
+ (0015329) +
+ Jacob Wieland - Spirent    +
+ 22-01-2019 14:21    +
+ 		+ + + + +
+ There is no contradiction. It is clearly stated that only those templates that contribute to the matching will lead to assignments. And these examples demonstrate exactly that: Since ? always matches in mw_t1, the other alternative never contributes to a successful match and is therefore ignored, together with it's assignment. And since 1..3 already matches 3, v_big is only assigned in case 4..5, but not for 3.
+
+I would accede that the 'if' in the comment of mw_t1 should be replaced with a 'since', though, since it is always true in this example that the first part always matches.
+
+
+
+ + + + + + + + + + +
+ (0015356) +
+ Jacob Wieland - Spirent    +
+ 06-08-2019 08:11    +
+ 		+ + + + +
+ please review proposal
+
+
+
+ + + + + + + + + + +
+ (0015386) +
+ Tomas Urban    +
+ 07-08-2019 08:58    +
+ 		+ + + + +
+ Proposed resolution fixes the reported issue and it can be added to the next version of the standard.
+
+ + diff --git a/docs/mantis/CR7822.md b/docs/mantis/CR7822.md new file mode 100644 index 0000000000000000000000000000000000000000..973af88e8b7384702144ad08bd305596ad42de46 --- /dev/null +++ b/docs/mantis/CR7822.md @@ -0,0 +1,143 @@ + + + + + + + + + + + + + 0007822: Invalid restriction on values of behaviour types - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Behaviour Types (ES 202 785)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007822Ext Pack: Behaviour Types (ES 202 785)Clarificationpublic06-12-2018 12:2817-12-2019 11:03
ReporterTomas Urban 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Versionv1.7.1 (published 2020-05) 
Clause Reference(s)6.3.6
Source (company - Author)Elvior
Summary0007822: Invalid restriction on values of behaviour types
DescriptionThe restrictions a) and b) in 6.3.6 (Type compatibility of behaviour types with runs on self) are probably related to behaviour types with the "runs on self" clause, because the section 6.3.6 is dedicated to these behaviour types.
+
+However, the text of the restrictions doesn't contain the word "self", thus the restriction is valid to all behaviour types with the "runs on" clause which doesn't make much sense:
+
+a) Values of test case behaviour types are typically used only in module control part and test case behaviour type always contains the "runs on" clause.
+b) Global constants or module parameters of behaviour types with a "runs on" clause can be safely referenced in functions with a "runs on" clause.
+
+Besides, TTCN-3:2019 introduces the "runs on" clause for the control function (formerly known as the module control part) which makes the restriction b completely obsolete.
+
+Proposal:
+1. Remove restriction b completely
+2. Change "runs on" to "runs on self" in the restriction a
+3. Remove redundant 2nd paragraph of the semantic description ("The compatibility check...") or change it to a note attached to the restriction a, because the same rule is described in the restriction a
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7822-1.docx (152,714) 07-08-2019 09:35
http://oldforge.etsi.org/mantis/file_download.php?file_id=3828&type=bug
Issue History
Date ModifiedUsernameFieldChange
06-12-2018 12:28Tomas UrbanNew Issue
18-12-2018 11:45Jens GrabowskiNote Added: 0015291
18-12-2018 11:45Jens GrabowskiAssigned To => Tomas Urban
18-12-2018 11:45Jens GrabowskiStatusnew => assigned
07-08-2019 09:35Tomas UrbanFile Added: CR7822-1.docx
07-08-2019 09:35Tomas UrbanNote Added: 0015390
07-08-2019 09:35Tomas UrbanAssigned ToTomas Urban => Laurent VRECK
07-08-2019 09:35Tomas UrbanStatusassigned => confirmed
07-08-2019 09:44Tomas UrbanAssigned ToLaurent VRECK => Jacob Wieland - Spirent
07-08-2019 13:46Jacob Wieland - SpirentNote Added: 0015407
07-08-2019 13:46Jacob Wieland - SpirentStatusconfirmed => resolved
07-08-2019 13:46Jacob Wieland - SpirentFixed in Version => v1.7.1 (published 2020-05)
07-08-2019 13:46Jacob Wieland - SpirentResolutionopen => fixed
07-08-2019 13:46Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Jens Grabowski
17-12-2019 11:03Jens GrabowskiStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015291) +
+ Jens Grabowski    +
+ 18-12-2018 11:45    +
+ 		+ + + + +
+ STF decision: Tomas will make a proposal in the context of the next TTCN-3 maintenance STF.
+
+
+
+ + + + + + + + + + +
+ (0015390) +
+ Tomas Urban    +
+ 07-08-2019 09:35    +
+ 		+ + + + +
+ Proposal uploaded. Please check.
+
+
+
+ + + + + + + + + + +
+ (0015407) +
+ Jacob Wieland - Spirent    +
+ 07-08-2019 13:46    +
+ 		+ + + + +
+ ok with me
+
+ + diff --git a/docs/mantis/CR7825.md b/docs/mantis/CR7825.md new file mode 100644 index 0000000000000000000000000000000000000000..69d8085ff90b0afde58e4a59dda1258d83a0ac11 --- /dev/null +++ b/docs/mantis/CR7825.md @@ -0,0 +1,67 @@ + + + + + + + + + + + + + 0007825: minor typo in get_stringencoding example - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007825Part 01: TTCN-3 Core LanguageEditorialpublic05-01-2019 13:3406-01-2019 08:39
ReporterKristóf Szabados 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version4.11.1 (published 2019-05) 
Clause Reference(s)C.5.7
Source (company - Author)L.M. Ericsson
Summary0007825: minor typo in get_stringencoding example
DescriptionThere is a parentheses issue in the example of get_stringencoding:
+"match ( get_stringencoding('6869C3BA7A'O,charstring:"UTF-8") )"
+
+It should be:
+"match ( get_stringencoding('6869C3BA7A'O),charstring:"UTF-8" )"
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
05-01-2019 13:34Kristóf SzabadosNew Issue
06-01-2019 08:39Gyorgy RethyNote Added: 0015324
06-01-2019 08:39Gyorgy RethyStatusnew => closed
06-01-2019 08:39Gyorgy RethyAssigned To => Gyorgy Rethy
06-01-2019 08:39Gyorgy RethyResolutionopen => fixed
06-01-2019 08:39Gyorgy RethyFixed in Version => 4.11.1 (published 2019-05)
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015324) +
+ Gyorgy Rethy    +
+ 06-01-2019 08:39    +
+ 		+ + + + +
+ Fixed in draft v4.10.2
+
+ + diff --git a/docs/mantis/CR7826.md b/docs/mantis/CR7826.md new file mode 100644 index 0000000000000000000000000000000000000000..4c086dadba47a5f1baa27a916f5fac51db1676e2 --- /dev/null +++ b/docs/mantis/CR7826.md @@ -0,0 +1,284 @@ + + + + + + + + + + + + + 0007826: Non-backward compatibility issue with reserved words of extension packages - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007826Part 01: TTCN-3 Core LanguageTechnicalpublic13-02-2019 08:2629-12-2019 13:04
ReporterWolfgang Seka 
Assigned ToGyorgy Rethy 
PriorityhighSeveritymajorReproducibilityhave not tried
StatusclosedResolutionno change required 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version4.12.1 (published 2020-05) 
Clause Reference(s)Annex A.1.5 (maybe others)
Source (company - Author)MCC160 (Wolfgang)
Summary0007826: Non-backward compatibility issue with reserved words of extension packages
DescriptionTable A.5 defines reserved words in extension packages but it is not clear how these shall be treated in test suites not using extensions:
+1. TTCN-3 type definitions: Annex A says "... Using these terminals in the code is not recommended as it might lead to issues in the future"
+This is not a technical specification and therefore does not say exactly whether or not a TTCN-3 type may use one of the keywords (e.g. as field name in a record).
+On the other hand if it would not be allowed to use the extension package keywords in TTCN-3 type definitions there is not backward compatibility anymore with TTCN projects being older than the extension.
+2. It is not clear whether or under which condition for fieldnames in external type definition a "_" extension is needed. If it would be needed for keywords of extension packages - again - there would be a compatibility issue.
+On the other hand it is not clear whether or not compilers expect the "_" (e.g. if we add the "_", do all tools and compilers accept this ??).
+In practice different compiler behaviour can be observed and it seems that some compilers are changing (=> compatibility issues).
+
+Conclusions:
+To avoid compatibility issues reserved words of extension packages shall not affect test suites which do not use any extension. It is up to tool implementation to cope with potential extensions but tools shall be able to cope with test suites which ignore reserved words of extension packages.
Steps To Reproduce
Additional InformationExample: "timestamp" is used as field name in ETSI's "LibSip" and in several XSD type definitions.
TagsNo tags attached.
Relationships
Attached Filesdocx CR7826.docx (166,693) 08-08-2019 09:24
http://oldforge.etsi.org/mantis/file_download.php?file_id=3843&type=bug
docx CR7826-2.docx (166,436) 08-08-2019 10:08
http://oldforge.etsi.org/mantis/file_download.php?file_id=3846&type=bug
Issue History
Date ModifiedUsernameFieldChange
13-02-2019 08:26Wolfgang SekaNew Issue
13-02-2019 11:00Jacob Wieland - SpirentNote Added: 0015332
27-05-2019 11:26Jacob Wieland - SpirentNote Added: 0015345
06-08-2019 10:01Kristóf SzabadosNote Added: 0015371
06-08-2019 10:01Kristóf SzabadosStatusnew => resolved
06-08-2019 10:01Kristóf SzabadosResolutionopen => no change required
06-08-2019 10:01Kristóf SzabadosAssigned To => Gyorgy Rethy
08-08-2019 07:39Kristóf SzabadosNote Added: 0015416
08-08-2019 07:39Kristóf SzabadosAssigned ToGyorgy Rethy => Kristóf Szabados
08-08-2019 07:39Kristóf SzabadosStatusresolved => assigned
08-08-2019 09:24Kristóf SzabadosFile Added: CR7826.docx
08-08-2019 09:25Kristóf SzabadosNote Added: 0015423
08-08-2019 09:25Kristóf SzabadosAssigned ToKristóf Szabados => Jacob Wieland - Spirent
08-08-2019 09:25Kristóf SzabadosStatusassigned => confirmed
08-08-2019 10:08Jacob Wieland - SpirentFile Added: CR7826-2.docx
08-08-2019 10:09Jacob Wieland - SpirentNote Added: 0015430
08-08-2019 10:09Jacob Wieland - SpirentStatusconfirmed => resolved
08-08-2019 10:09Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
29-12-2019 11:27Gyorgy RethyProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
29-12-2019 13:04Gyorgy RethyNote Added: 0015604
29-12-2019 13:04Gyorgy RethyStatusresolved => closed
29-12-2019 13:04Gyorgy RethyFixed in Version => 4.12.1 (published 2020-05)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015332) +
+ Jacob Wieland - Spirent    +
+ 13-02-2019 11:00    +
+ 		+ + + + +
+ This is basically how it was handled in the past. However, this carries its own set of problems that need solving as well.
+
+If you import from a module of a different language, it is dependent on what languages your module uses how the identifiers of the other module are mapped to TTCN-3. Thus, it could even be the case that the same external module used by two different modules would need a different mapping on import.
+
+This causes maintenance nightmares and as soon as some additional language is used in a later version of that module, it would introduce backward incompatibility for the other definitions in that module as well.
+
+That is why we decided that all reserved words should be treated equally, no matter what language features are used. It is then the only responsibility of the tool providers to deal with the global list of reserved words (which should be in the core standard document so they are mandatory). Also, we (the Evolution STF) try to stay away from new non-@ keywords (we introduced the @-words for exactly that reason) when introducing new language constructs to not cause backward compatibility issues in the future.
+
+However, there's no perfect fully non-backward-incompatible solution of this problem, so we opted for one where we thought it would cause the least amount of problems, i.e. necessity for refactoring of old code.
+
+
+
+ + + + + + + + + + +
+ (0015345) +
+ Jacob Wieland - Spirent    +
+ 27-05-2019 11:26    +
+ 		+ + + + +
+ To avoid compatibility issues in test suites, the modules of these test suites should always be marked with the language version. If that is the case, no backward compatibility issues should occur with correct tools as the tools would treat the package keywords as reserved in all cases only for languagues after the version where this was introduced.
+
+
+
+ + + + + + + + + + +
+ (0015371) +
+ Kristóf Szabados    +
+ 06-08-2019 10:01    +
+ 		+ + + + +
+ STF discussion: we aggree that this is a tool issue. Tools should correctly implement the reserved word mapping based on the language version of the importing module.
+
+
+
+ + + + + + + + + + +
+ (0015416) +
+ Kristóf Szabados    +
+ 08-08-2019 07:39    +
+ 		+ + + + +
+ STF discussion: make the sentence in question more clear.
+
+
+
+ + + + + + + + + + +
+ (0015423) +
+ Kristóf Szabados    +
+ 08-08-2019 09:25    +
+ 		+ + + + +
+ Please check.
+
+
+
+ + + + + + + + + + +
+ (0015430) +
+ Jacob Wieland - Spirent    +
+ 08-08-2019 10:09    +
+ 		+ + + + +
+ deleted doubled sentence, otherwise ok
+
+
+
+ + + + + + + + + + +
+ (0015604) +
+ Gyorgy Rethy    +
+ 29-12-2019 13:04    +
+ 		+ + + + +
+ Included in final draft V4.11.3
+
+ + diff --git a/docs/mantis/CR7827.md b/docs/mantis/CR7827.md new file mode 100644 index 0000000000000000000000000000000000000000..3427dc3e91a49e89aff0f9f35069958254e6a1f1 --- /dev/null +++ b/docs/mantis/CR7827.md @@ -0,0 +1,148 @@ + + + + + + + + + + + + + 0007827: Semantic of disjunction - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Advanced Matching (ES 203 022)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007827Ext Pack: Advanced Matching (ES 203 022)Clarificationpublic07-03-2019 12:2917-12-2019 10:11
ReporterMartin Hauch 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv1.2.1 (published 2018-05) 
Target VersionFixed in Version 
Clause Reference(s)5.3.4
Source (company - Author)Devoteam - Martin Hauch
TS version?
Summary0007827: Semantic of disjunction
DescriptionIn chapter 5.3.4 one sentence is:
+It provides a successful match, if
+and only if one of the disjunction alternatives matches the maximal subset of still unmatched elements inside the value
+that still allows the containing template to match the whole value.
+
+This means, if more than on disjunction alternatives are matching the result is mismatch.
+
+Other sentence is:
+The disjunction alternatives are matched in the order of their specification inside the disjunction matching mechanism
+(i.e. from left to right) so that the leftmost alternative that fulfils the above condition contributes to the successful match
+while the following disjunction alternatives are ignored.
+
+If one disjunction alternative is matching all following alternatives are not checked, which leads to a different result?
+Could this be clarified? Perhaps change 1st sentence to:
+It provides a successful match, if
+and only if at least one of the disjunction alternatives ...
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7827.docx (124,502) 06-08-2019 08:54
http://oldforge.etsi.org/mantis/file_download.php?file_id=3818&type=bug
Issue History
Date ModifiedUsernameFieldChange
07-03-2019 12:29Martin HauchNew Issue
07-03-2019 13:58Jacob Wieland - SpirentNote Added: 0015335
06-08-2019 08:54Jacob Wieland - SpirentFile Added: CR7827.docx
06-08-2019 08:54Jacob Wieland - SpirentNote Added: 0015367
06-08-2019 08:54Jacob Wieland - SpirentAssigned To => Tomas Urban
06-08-2019 08:54Jacob Wieland - SpirentStatusnew => confirmed
07-08-2019 09:19Tomas UrbanNote Added: 0015389
07-08-2019 09:19Tomas UrbanStatusconfirmed => resolved
07-08-2019 09:19Tomas UrbanResolutionopen => fixed
07-08-2019 09:19Tomas UrbanAssigned ToTomas Urban => Jens Grabowski
17-12-2019 10:11Jens GrabowskiStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015335) +
+ Jacob Wieland - Spirent    +
+ 07-03-2019 13:58    +
+ 		+ + + + +
+ Yes, the intention of the sentence was 'one' in the sense of 'at least one', not in the sense of 'exactly one'.
+
+We'll clarify this.
+
+
+
+ + + + + + + + + + +
+ (0015367) +
+ Jacob Wieland - Spirent    +
+ 06-08-2019 08:54    +
+ 		+ + + + +
+ please review
+
+
+
+ + + + + + + + + + +
+ (0015389) +
+ Tomas Urban    +
+ 07-08-2019 09:19    +
+ 		+ + + + +
+ Proposed resolution fixes the reported issue and it can be added to the next version of the standard.
+
+ + diff --git a/docs/mantis/CR7829.md b/docs/mantis/CR7829.md new file mode 100644 index 0000000000000000000000000000000000000000..b0b1238c9d8f0e360e390bfd1b9da5a249bbb612 --- /dev/null +++ b/docs/mantis/CR7829.md @@ -0,0 +1,192 @@ + + + + + + + + + + + + + 0007829: Syntax of repetion for arrays and of types - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Advanced Matching (ES 203 022)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007829Ext Pack: Advanced Matching (ES 203 022)Clarificationpublic21-03-2019 07:2317-12-2019 10:11
ReporterMartin Hauch 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv1.2.1 (published 2018-05) 
Target VersionFixed in Versionv1.3.1 (ongoing) 
Clause Reference(s)5.4.2
Source (company - Author)DVT - Martin Hauch
TS version?
Summary0007829: Syntax of repetion for arrays and of types
DescriptionThe examples in chapter 5.4.2 uses additional '{' '}':
+template RoN mw_a := { { { givenName := "John", surname := ?} } #(2, 5) }
+
+As I interpret the Bnf I would expect
+template RoN mw_a := { { givenName := "John", surname := ?} } #(2, 5);
+because rules
+022003. RepetitionMatch ::= TemplateBody RepetitionCountSpec
+022004. RepetitionCountSpec ::= "#" "(" [SingleExpression] ["," [SingleExpression]] ")"
+do not add '{' '}' around TemplateBody RepetitonCountSpec. I think the BNF is ok, but the example above (original from document) represents a value of type
+record of RoN.
+Could this be clarified?
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7829.docx (127,583) 07-08-2019 08:06
http://oldforge.etsi.org/mantis/file_download.php?file_id=3824&type=bug
Issue History
Date ModifiedUsernameFieldChange
21-03-2019 07:23Martin HauchNew Issue
21-03-2019 12:20Jacob Wieland - SpirentNote Added: 0015339
06-08-2019 10:15Kristóf SzabadosAssigned To => Kristóf Szabados
06-08-2019 10:15Kristóf SzabadosStatusnew => assigned
07-08-2019 07:53Kristóf SzabadosNote Added: 0015380
07-08-2019 08:06Kristóf SzabadosFile Added: CR7829.docx
07-08-2019 08:07Kristóf SzabadosNote Added: 0015382
07-08-2019 08:07Kristóf SzabadosAssigned ToKristóf Szabados => Jacob Wieland - Spirent
07-08-2019 08:07Kristóf SzabadosStatusassigned => acknowledged
07-08-2019 14:08Jacob Wieland - SpirentNote Added: 0015412
07-08-2019 14:08Jacob Wieland - SpirentStatusacknowledged => resolved
07-08-2019 14:08Jacob Wieland - SpirentFixed in Version => v1.3.1 (ongoing)
07-08-2019 14:08Jacob Wieland - SpirentResolutionopen => fixed
07-08-2019 14:08Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Jens Grabowski
17-12-2019 10:11Jens GrabowskiStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015339) +
+ Jacob Wieland - Spirent    +
+ 21-03-2019 12:20    +
+ 		+ + + + +
+ The example is correct and it's as clear as it needs to be in the standard.
+
+The relevant rule is:
+
+ArrayElementSpec ::= Minus |
+ PermutationMatch |
+ TemplateBody |
+ DisjunctionMatch |
+ RepetitionMatch
+
+This is where RepetitionMatch is derived which, as it is an inside-value matching mechanism like permutation, can only occur inside a compound expression, i.e. inside curly brackets (to be looked up in the core standard of the usage of ArrayElementSpec).
+
+Therefore, the example is correct, it describes a list where there is a repetition of 2 to 5 iterations of sublists list containing only one element which matches the given record template.
+
+
+
+ + + + + + + + + + +
+ (0015380) +
+ Kristóf Szabados    +
+ 07-08-2019 07:53    +
+ 		+ + + + +
+ The example looks to be correct (regarding the BNF).
+
+As it demonstrated how a list of a single element repeated 2 to 5 times should be the part of the list.
+
+Maybe we should add a bit more complex example, to demonstrate this better.
+
+
+
+ + + + + + + + + + +
+ (0015382) +
+ Kristóf Szabados    +
+ 07-08-2019 08:07    +
+ 		+ + + + +
+ Please check the new example.
+
+
+
+ + + + + + + + + + +
+ (0015412) +
+ Jacob Wieland - Spirent    +
+ 07-08-2019 14:08    +
+ 		+ + + + +
+ new example looks good
+
+ + diff --git a/docs/mantis/CR7830.md b/docs/mantis/CR7830.md new file mode 100644 index 0000000000000000000000000000000000000000..6ef2c62dbaec126cca70431ddc08d17357f80f9a --- /dev/null +++ b/docs/mantis/CR7830.md @@ -0,0 +1,239 @@ + + + + + + + + + + + + + 0007830: Clarification request for OO features (order or member initializer and constructor) - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Object-oriented features (ES 203 790)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007830Ext Pack: Object-oriented features (ES 203 790)[All Projects] Generalpublic30-03-2019 16:0109-01-2020 16:02
ReporterKristóf Szabados 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0007830: Clarification request for OO features (order or member initializer and constructor)
DescriptionFrom the text it is not clear in what order the direct initializations of class members and the constructor of the class is executed and if multiple initialization is allowed.
+
+Is it possible to initialize a member variable via its direct initializing value first and override it in the constructor?
+(this I guess should be possible although not very efficient)
+
+What if a constant member has direct initializer and would also get a value in the constructor? (this I believe should be a compile time error if can be detected)
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0007868closed Jens Grabowski External classes should be allowed internal members (direct and inherited) 
Attached Filesdocx CR7830.docx (130,991) 07-08-2019 08:16
http://oldforge.etsi.org/mantis/file_download.php?file_id=3826&type=bug
docx CR7830_v2.docx (131,620) 07-08-2019 13:21
http://oldforge.etsi.org/mantis/file_download.php?file_id=3832&type=bug
Issue History
Date ModifiedUsernameFieldChange
30-03-2019 16:01Kristóf SzabadosNew Issue
06-08-2019 10:12Kristóf SzabadosNote Added: 0015372
06-08-2019 10:12Kristóf SzabadosAssigned To => Jacob Wieland - Spirent
06-08-2019 10:12Kristóf SzabadosStatusnew => assigned
06-08-2019 15:59Jacob Wieland - SpirentFile Added: CR7830.docx
06-08-2019 15:59Jacob Wieland - SpirentNote Added: 0015378
06-08-2019 15:59Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Tomas Urban
06-08-2019 15:59Jacob Wieland - SpirentStatusassigned => confirmed
07-08-2019 07:33Jacob Wieland - SpirentFile Deleted: CR7830.docx
07-08-2019 07:33Jacob Wieland - SpirentAssigned ToTomas Urban => Jacob Wieland - Spirent
07-08-2019 07:33Jacob Wieland - SpirentStatusconfirmed => assigned
07-08-2019 08:16Jacob Wieland - SpirentFile Added: CR7830.docx
07-08-2019 08:16Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Tomas Urban
07-08-2019 08:16Jacob Wieland - SpirentStatusassigned => confirmed
07-08-2019 13:21Kristóf SzabadosFile Added: CR7830_v2.docx
07-08-2019 13:22Kristóf SzabadosNote Added: 0015403
07-08-2019 14:30Tomas UrbanNote Added: 0015414
07-08-2019 14:30Tomas UrbanStatusconfirmed => resolved
07-08-2019 14:30Tomas UrbanResolutionopen => fixed
08-08-2019 10:59Jens GrabowskiAssigned ToTomas Urban => Jens Grabowski
08-08-2019 10:59Jens GrabowskiStatusresolved => assigned
08-08-2019 10:59Jens GrabowskiStatusassigned => resolved
18-12-2019 09:27Tomas UrbanRelationship addedrelated to 0007868
18-12-2019 09:29Jens GrabowskiNote Added: 0015571
18-12-2019 09:29Jens GrabowskiAssigned ToJens Grabowski => Tomas Urban
18-12-2019 09:29Jens GrabowskiStatusresolved => assigned
18-12-2019 10:24Tomas UrbanNote Added: 0015575
18-12-2019 10:24Tomas UrbanAssigned ToTomas Urban => Jacob Wieland - Spirent
18-12-2019 10:24Tomas UrbanStatusassigned => confirmed
18-12-2019 11:05Jacob Wieland - SpirentStatusconfirmed => resolved
18-12-2019 11:05Jacob Wieland - SpirentStatusresolved => feedback
18-12-2019 11:05Jacob Wieland - SpirentResolutionfixed => reopened
18-12-2019 11:05Jacob Wieland - SpirentStatusfeedback => resolved
18-12-2019 11:05Jacob Wieland - SpirentResolutionreopened => fixed
18-12-2019 11:05Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Jens Grabowski
09-01-2020 16:02Jens GrabowskiStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015372) +
+ Kristóf Szabados    +
+ 06-08-2019 10:12    +
+ 		+ + + + +
+ STF discussion: first all the right hand side of the member declarations, second the initializer, third the constructor. Constants should be assigned only once. And that in class hierarchy, from the topmost super class to the lowest nd than call the constructor of the lowest class.
+
+
+
+ + + + + + + + + + +
+ (0015378) +
+ Jacob Wieland - Spirent    +
+ 06-08-2019 15:59    +
+ 		+ + + + +
+ please review
+
+
+
+ + + + + + + + + + +
+ (0015403) +
+ Kristóf Szabados    +
+ 07-08-2019 13:22    +
+ 		+ + + + +
+ fixed a minor typo and emphasized a bit more that cyclic initialization is not allowed.
+
+
+
+ + + + + + + + + + +
+ (0015414) +
+ Tomas Urban    +
+ 07-08-2019 14:30    +
+ 		+ + + + +
+ No errors found in the proposal, it can be added to the specification.
+
+
+
+ + + + + + + + + + +
+ (0015571) +
+ Jens Grabowski    +
+ 18-12-2019 09:29    +
+ 		+ + + + +
+ conflicts with 7856, 7868
+
+
+
+ + + + + + + + + + +
+ (0015575) +
+ Tomas Urban    +
+ 18-12-2019 10:24    +
+ 		+ + + + +
+ Merged with changes from 0007868 and 0007856. The merged document is in 0007868. Please mark this CR as resolved if the review of the document yield a positive result.
+
+ + diff --git a/docs/mantis/CR7831.md b/docs/mantis/CR7831.md new file mode 100644 index 0000000000000000000000000000000000000000..fbaed9c3d4fcd6f8abb01031f938ae6c27f32f3b --- /dev/null +++ b/docs/mantis/CR7831.md @@ -0,0 +1,211 @@ + + + + + + + + + + + + + 0007831: Clarification request for OO features (reaching super super class) - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Object-oriented features (ES 203 790)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007831Ext Pack: Object-oriented features (ES 203 790)[All Projects] Generalpublic30-03-2019 16:0509-01-2020 16:04
ReporterKristóf Szabados 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0007831: Clarification request for OO features (reaching super super class)
DescriptionDo I understand correctly that right now when I wish to reach the super class of a super class I can write this.
+
+type class SubClass extends BaseClass {
+  public function f(in integer x) return integer {
+    return super.f(x) - 1;
+  }
+}
+type class @final FinalClass extends SubClass {
+  public function f(in integer x) return integer {
+    return super.super.f(x) + 1; // ???
+    // The way to reach BaseClass.f?
+  }
+}
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7831.docx (126,856) 06-08-2019 15:17
http://oldforge.etsi.org/mantis/file_download.php?file_id=3820&type=bug
docx CR7831-v2.docx (127,437) 07-08-2019 09:35
http://oldforge.etsi.org/mantis/file_download.php?file_id=3827&type=bug
Issue History
Date ModifiedUsernameFieldChange
30-03-2019 16:05Kristóf SzabadosNew Issue
06-08-2019 08:45Jacob Wieland - SpirentNote Added: 0015366
06-08-2019 09:23Kristóf SzabadosNote Added: 0015369
06-08-2019 09:24Kristóf SzabadosAssigned To => Jacob Wieland - Spirent
06-08-2019 09:24Kristóf SzabadosStatusnew => assigned
06-08-2019 15:17Jacob Wieland - SpirentFile Added: CR7831.docx
06-08-2019 15:17Jacob Wieland - SpirentNote Added: 0015377
06-08-2019 15:17Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Kristóf Szabados
06-08-2019 15:17Jacob Wieland - SpirentStatusassigned => confirmed
07-08-2019 09:35Kristóf SzabadosFile Added: CR7831-v2.docx
07-08-2019 09:36Kristóf SzabadosNote Added: 0015391
07-08-2019 09:36Kristóf SzabadosAssigned ToKristóf Szabados => Jacob Wieland - Spirent
07-08-2019 09:36Kristóf SzabadosStatusconfirmed => assigned
07-08-2019 12:02Jacob Wieland - SpirentNote Added: 0015395
07-08-2019 12:02Jacob Wieland - SpirentStatusassigned => resolved
07-08-2019 12:02Jacob Wieland - SpirentResolutionopen => fixed
07-08-2019 12:02Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Jens Grabowski
09-01-2020 16:04Jens GrabowskiStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015366) +
+ Jacob Wieland - Spirent    +
+ 06-08-2019 08:45    +
+ 		+ + + + +
+ So far, this was not an intended semantical use. This should be discussed.
+
+
+
+ + + + + + + + + + +
+ (0015369) +
+ Kristóf Szabados    +
+ 06-08-2019 09:23    +
+ 		+ + + + +
+ STF discussion: super.super should not be allowed (only allow reaching first visible class, not deeper).
+
+
+
+ + + + + + + + + + +
+ (0015377) +
+ Jacob Wieland - Spirent    +
+ 06-08-2019 15:17    +
+ 		+ + + + +
+ please review
+
+
+
+ + + + + + + + + + +
+ (0015391) +
+ Kristóf Szabados    +
+ 07-08-2019 09:36    +
+ 		+ + + + +
+ updated the functionref in the BNF. Please check.
+
+
+
+ + + + + + + + + + +
+ (0015395) +
+ Jacob Wieland - Spirent    +
+ 07-08-2019 12:02    +
+ 		+ + + + +
+ changes are ok
+
+ + diff --git a/docs/mantis/CR7832.md b/docs/mantis/CR7832.md new file mode 100644 index 0000000000000000000000000000000000000000..db791da1de2a5d18526ae919e39cb8ead2a61ca3 --- /dev/null +++ b/docs/mantis/CR7832.md @@ -0,0 +1,189 @@ + + + + + + + + + + + + + 0007832: incorrect syntax used in example - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Object-oriented features (ES 203 790)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007832Ext Pack: Object-oriented features (ES 203 790)[All Projects] Generalpublic30-03-2019 16:0809-01-2020 16:05
ReporterKristóf Szabados 
Assigned ToJens Grabowski 
PrioritynormalSeveritytextReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0007832: incorrect syntax used in example
DescriptionSection 5.1.1.3 show an example for an external class, using incorrect syntax.
+
+this:
+"
+external type class Stack {
+function push(integer v);
+function pop() return integer;
+function isEmpty() return boolean;
+}
+"
+should be:
+"
+type external class Stack {
+external function push(integer v);
+external function pop() return integer;
+external function isEmpty() return boolean;
+}
+"
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7832.docx (127,423) 06-08-2019 08:28
http://oldforge.etsi.org/mantis/file_download.php?file_id=3815&type=bug
Issue History
Date ModifiedUsernameFieldChange
30-03-2019 16:08Kristóf SzabadosNew Issue
02-04-2019 15:34Jacob Wieland - SpirentNote Added: 0015340
05-08-2019 11:46Kristóf SzabadosNote Added: 0015352
06-08-2019 08:20Jacob Wieland - SpirentAssigned To => Jacob Wieland - Spirent
06-08-2019 08:20Jacob Wieland - SpirentStatusnew => assigned
06-08-2019 08:28Jacob Wieland - SpirentFile Added: CR7832.docx
06-08-2019 08:29Jacob Wieland - SpirentNote Added: 0015361
06-08-2019 08:29Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Kristóf Szabados
06-08-2019 08:29Jacob Wieland - SpirentStatusassigned => confirmed
06-08-2019 08:37Kristóf SzabadosNote Added: 0015363
06-08-2019 08:37Kristóf SzabadosStatusconfirmed => resolved
06-08-2019 08:37Kristóf SzabadosResolutionopen => fixed
06-08-2019 08:37Kristóf SzabadosAssigned ToKristóf Szabados => Jens Grabowski
09-01-2020 16:05Jens GrabowskiStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015340) +
+ Jacob Wieland - Spirent    +
+ 02-04-2019 15:34    +
+ 		+ + + + +
+ section 5.1.1.3 states explicitly:
+
+"It is allowed to omit the external keyword from these function declarations."
+
+So, this is correct syntax.
+
+
+
+ + + + + + + + + + +
+ (0015352) +
+ Kristóf Szabados    +
+ 05-08-2019 11:46    +
+ 		+ + + + +
+ True, the inner external keywords are optional.
+
+But "exteral type" still should be "type external"
+
+
+
+ + + + + + + + + + +
+ (0015361) +
+ Jacob Wieland - Spirent    +
+ 06-08-2019 08:29    +
+ 		+ + + + +
+ please review
+
+
+
+ + + + + + + + + + +
+ (0015363) +
+ Kristóf Szabados    +
+ 06-08-2019 08:37    +
+ 		+ + + + +
+ looks fine by me.
+
+ + diff --git a/docs/mantis/CR7833.md b/docs/mantis/CR7833.md new file mode 100644 index 0000000000000000000000000000000000000000..b6f23868dd43d6760e7dbe803eaa6ac58ea7572e --- /dev/null +++ b/docs/mantis/CR7833.md @@ -0,0 +1,102 @@ + + + + + + + + + + + + + 0007833: typo in comment - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Object-oriented features (ES 203 790)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007833Ext Pack: Object-oriented features (ES 203 790)[All Projects] Generalpublic30-03-2019 16:1209-01-2020 16:05
ReporterKristóf Szabados 
Assigned ToJens Grabowski 
PrioritynormalSeveritytextReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0007833: typo in comment
DescriptionIn Example 4 on page 21
+"// the exception is not cought."
+should be
+"// the exception is not caught."
+
+And also happens in other locations.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7833.docx (131,489) 06-08-2019 08:44
http://oldforge.etsi.org/mantis/file_download.php?file_id=3817&type=bug
Issue History
Date ModifiedUsernameFieldChange
30-03-2019 16:12Kristóf SzabadosNew Issue
06-08-2019 08:43Jacob Wieland - SpirentAssigned To => Jacob Wieland - Spirent
06-08-2019 08:43Jacob Wieland - SpirentStatusnew => assigned
06-08-2019 08:44Jacob Wieland - SpirentFile Added: CR7833.docx
06-08-2019 08:44Jacob Wieland - SpirentNote Added: 0015365
06-08-2019 08:44Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Kristóf Szabados
06-08-2019 08:44Jacob Wieland - SpirentStatusassigned => confirmed
06-08-2019 09:05Kristóf SzabadosNote Added: 0015368
06-08-2019 09:05Kristóf SzabadosStatusconfirmed => resolved
06-08-2019 09:05Kristóf SzabadosResolutionopen => fixed
06-08-2019 09:05Kristóf SzabadosAssigned ToKristóf Szabados => Jens Grabowski
09-01-2020 16:05Jens GrabowskiStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015365) +
+ Jacob Wieland - Spirent    +
+ 06-08-2019 08:44    +
+ 		+ + + + +
+ please review
+
+
+
+ + + + + + + + + + +
+ (0015368) +
+ Kristóf Szabados    +
+ 06-08-2019 09:05    +
+ 		+ + + + +
+ looks fine by me.
+
+ + diff --git a/docs/mantis/CR7834.md b/docs/mantis/CR7834.md new file mode 100644 index 0000000000000000000000000000000000000000..02f7cf1a0d2e34dd09018538d3a5987cf1416c45 --- /dev/null +++ b/docs/mantis/CR7834.md @@ -0,0 +1,99 @@ + + + + + + + + + + + + + 0007834: case else in the select case is not described - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Object-oriented features (ES 203 790)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007834Ext Pack: Object-oriented features (ES 203 790)[All Projects] Generalpublic02-04-2019 14:5609-01-2020 16:05
ReporterKristóf Szabados 
Assigned ToJens Grabowski 
PrioritynormalSeveritytextReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0007834: case else in the select case is not described
DescriptionAccording to 5.1.2.4 the select class statement can have a case else branch.
+
+There should be at least 1 sentence on what how it works.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7834.docx (127,172) 06-08-2019 08:39
http://oldforge.etsi.org/mantis/file_download.php?file_id=3816&type=bug
Issue History
Date ModifiedUsernameFieldChange
02-04-2019 14:56Kristóf SzabadosNew Issue
06-08-2019 08:39Jacob Wieland - SpirentAssigned To => Jacob Wieland - Spirent
06-08-2019 08:39Jacob Wieland - SpirentStatusnew => assigned
06-08-2019 08:39Jacob Wieland - SpirentFile Added: CR7834.docx
06-08-2019 08:40Jacob Wieland - SpirentNote Added: 0015364
06-08-2019 08:40Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Kristóf Szabados
06-08-2019 08:40Jacob Wieland - SpirentStatusassigned => confirmed
07-08-2019 09:39Kristóf SzabadosNote Added: 0015392
07-08-2019 09:39Kristóf SzabadosStatusconfirmed => resolved
07-08-2019 09:39Kristóf SzabadosResolutionopen => fixed
07-08-2019 09:39Kristóf SzabadosAssigned ToKristóf Szabados => Jens Grabowski
09-01-2020 16:05Jens GrabowskiStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015364) +
+ Jacob Wieland - Spirent    +
+ 06-08-2019 08:40    +
+ 		+ + + + +
+ please review
+
+
+
+ + + + + + + + + + +
+ (0015392) +
+ Kristóf Szabados    +
+ 07-08-2019 09:39    +
+ 		+ + + + +
+ looks fine by me.
+
+ + diff --git a/docs/mantis/CR7835.md b/docs/mantis/CR7835.md new file mode 100644 index 0000000000000000000000000000000000000000..73412a4f49237ef1a533457433459cd05a356f72 --- /dev/null +++ b/docs/mantis/CR7835.md @@ -0,0 +1,160 @@ + + + + + + + + + + + + + 0007835: incorrect example? - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007835Part 09: Using XML with TTCN-3Editorialpublic11-04-2019 08:4228-12-2019 12:26
ReporterKristóf Szabados 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version4.11.1 (published 2020-05) 
Clause Reference(s)7.5.3
For STF discussion
Source (company - Author)L.M. Ericsson
Summary0007835: incorrect example?
DescriptionIn section 7.5.3 in example 3 there might be a string field missing.
+
+"
+<xsd:simpleType name="Time-or-int-or-boolean-or-dateRestricted">
+<xsd:union memberTypes="xsd:time e21memberlist">
+<xsd:simpleType>
+<xsd:restriction base="xsd:date"/>
+</xsd:simpleType>
+</xsd:union>
+</xsd:simpleType>
+"
+
+is mapped to this TTCN-3 type:
+"
+type union Time_or_int_or_boolean_or_dateRestricted {
+XSD.Time time,
+XSD.Integer integer_,
+XSD.Boolean boolean_,
+XSD.Date alt_
+}
+with {
+variant "name as 'Time-or-int-or-boolean-or-dateRestricted'";
+variant "useUnion";
+variant (integer_) "name as 'integer'";
+variant (boolean_) "name as 'boolean'";
+variant (alt_) "name as ''";
+}
+"
+
+but e21memberlist on page 69, section 7.5.3, example 1 also has a xsd:strnig member, that looks like missing from here.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7835.docx (152,780) 06-08-2019 08:20
http://oldforge.etsi.org/mantis/file_download.php?file_id=3814&type=bug
Issue History
Date ModifiedUsernameFieldChange
11-04-2019 08:42Kristóf SzabadosNew Issue
05-08-2019 10:04Jens GrabowskiAssigned To => Kristóf Szabados
05-08-2019 10:04Jens GrabowskiStatusnew => assigned
06-08-2019 08:20Kristóf SzabadosFile Added: CR7835.docx
06-08-2019 08:24Kristóf SzabadosAssigned ToKristóf Szabados => Tomas Urban
06-08-2019 08:24Kristóf SzabadosNote Added: 0015360
07-08-2019 08:27Tomas UrbanNote Added: 0015384
07-08-2019 08:27Tomas UrbanStatusassigned => resolved
07-08-2019 08:27Tomas UrbanResolutionopen => fixed
07-08-2019 08:27Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
28-12-2019 12:26Gyorgy RethyNote Added: 0015586
28-12-2019 12:26Gyorgy RethyStatusresolved => closed
28-12-2019 12:26Gyorgy RethyFixed in Version => 4.11.1 (published 2020-05)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015360) +
+ Kristóf Szabados    +
+ 06-08-2019 08:24    +
+ 		+ + + + +
+ please check proposed fix.
+
+
+
+ + + + + + + + + + +
+ (0015384) +
+ Tomas Urban    +
+ 07-08-2019 08:27    +
+ 		+ + + + +
+ Resolution is correct and can be added to the next version of the specification.
+
+
+
+ + + + + + + + + + +
+ (0015586) +
+ Gyorgy Rethy    +
+ 28-12-2019 12:26    +
+ 		+ + + + +
+ Implemented in final draft 4.10.2.
+
+ + diff --git a/docs/mantis/CR7846.md b/docs/mantis/CR7846.md new file mode 100644 index 0000000000000000000000000000000000000000..a253a9cd0916eb8ba789764a81f04ef6fe847137 --- /dev/null +++ b/docs/mantis/CR7846.md @@ -0,0 +1,165 @@ + + + + + + + + + + + + + 0007846: Preprocessing macro _SCOPE_ value "control" to be clarified - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007846Part 01: TTCN-3 Core LanguageClarificationpublic06-05-2019 09:2428-12-2019 16:47
ReporterAxel Rennoch (old account) 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version4.12.1 (published 2020-05) 
Clause Reference(s)D.5
Source (company - Author)Axel Rennoch (FOKUS)
Summary0007846: Preprocessing macro _SCOPE_ value "control" to be clarified
DescriptionAfter the replacement of the module control part by a control function the "control" value of _SCOPE_ need to be explained using the new terminology.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7846.docx (163,317) 06-08-2019 07:47
http://oldforge.etsi.org/mantis/file_download.php?file_id=3811&type=bug
Issue History
Date ModifiedUsernameFieldChange
06-05-2019 09:24Axel Rennoch (old account)New Issue
05-08-2019 10:06Jens GrabowskiProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
05-08-2019 10:06Jens GrabowskiAssigned To => Kristóf Szabados
05-08-2019 10:06Jens GrabowskiStatusnew => assigned
06-08-2019 07:47Kristóf SzabadosFile Added: CR7846.docx
06-08-2019 07:49Kristóf SzabadosNote Added: 0015353
06-08-2019 07:49Kristóf SzabadosAssigned ToKristóf Szabados => Axel Rennoch
06-08-2019 07:49Kristóf SzabadosStatusassigned => acknowledged
06-08-2019 07:57Axel Rennoch (old account)Note Added: 0015355
06-08-2019 08:10Axel Rennoch (old account)Assigned ToAxel Rennoch => Gyorgy Rethy
06-08-2019 08:10Axel Rennoch (old account)Statusacknowledged => assigned
06-08-2019 08:11Axel Rennoch (old account)Note Added: 0015357
06-08-2019 08:11Axel Rennoch (old account)Statusassigned => confirmed
08-08-2019 13:43Kristóf SzabadosStatusconfirmed => resolved
08-08-2019 13:43Kristóf SzabadosResolutionopen => fixed
28-12-2019 16:47Gyorgy RethyNote Added: 0015595
28-12-2019 16:47Gyorgy RethyStatusresolved => closed
28-12-2019 16:47Gyorgy RethyFixed in Version => 4.12.1 (published 2020-05)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015353) +
+ Kristóf Szabados    +
+ 06-08-2019 07:49    +
+ 		+ + + + +
+ Please check the proposed text.
+
+
+
+ + + + + + + + + + +
+ (0015355) +
+ Axel Rennoch (old account)    +
+ 06-08-2019 07:57    +
+ 		+ + + + +
+ resolution is fine
+
+
+
+ + + + + + + + + + +
+ (0015357) +
+ Axel Rennoch (old account)    +
+ 06-08-2019 08:11    +
+ 		+ + + + +
+ resolution confirmed
+
+
+
+ + + + + + + + + + +
+ (0015595) +
+ Gyorgy Rethy    +
+ 28-12-2019 16:47    +
+ 		+ + + + +
+ Included to final draft V4.11.2.
+
+ + diff --git a/docs/mantis/CR7847.md b/docs/mantis/CR7847.md new file mode 100644 index 0000000000000000000000000000000000000000..65343fec8c8fb4661ee6b97255e8c9d4aeb59091 --- /dev/null +++ b/docs/mantis/CR7847.md @@ -0,0 +1,131 @@ + + + + + + + + + + + + + 0007847: Java mapping of tliPrCatchChecked_c - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007847Part 06: TTCN-3 Control InterfaceTechnicalpublic13-06-2019 14:2617-12-2019 12:42
ReporterTomas Urban 
Assigned ToTomas Urban 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Versionv4.9.1(ongoing) 
Clause Reference(s)8.5.4.1
Source (company - Author)Elvior
Summary0007847: Java mapping of tliPrCatchChecked_c
DescriptionThe Java mapping of the TCI-TL method tliPrCatchChecked_c contains two parameters called "from". The first one is not described in the interface specification and shall be removed.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7847-1.docx (158,499) 07-08-2019 08:01
http://oldforge.etsi.org/mantis/file_download.php?file_id=3823&type=bug
Issue History
Date ModifiedUsernameFieldChange
13-06-2019 14:26Tomas UrbanNew Issue
06-08-2019 09:49Tomas UrbanAssigned To => Tomas Urban
06-08-2019 09:49Tomas UrbanStatusnew => assigned
07-08-2019 08:01Tomas UrbanFile Added: CR7847-1.docx
07-08-2019 08:01Tomas UrbanNote Added: 0015381
07-08-2019 08:01Tomas UrbanAssigned ToTomas Urban => Jacob Wieland - Spirent
07-08-2019 08:01Tomas UrbanStatusassigned => confirmed
07-08-2019 14:10Jacob Wieland - SpirentNote Added: 0015413
07-08-2019 14:10Jacob Wieland - SpirentStatusconfirmed => resolved
07-08-2019 14:10Jacob Wieland - SpirentFixed in Version => v4.9.1(ongoing)
07-08-2019 14:10Jacob Wieland - SpirentResolutionopen => fixed
07-08-2019 14:10Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Tomas Urban
17-12-2019 12:42Tomas UrbanNote Added: 0015552
17-12-2019 12:42Tomas UrbanStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015381) +
+ Tomas Urban    +
+ 07-08-2019 08:01    +
+ 		+ + + + +
+ Proposal uploaded. Please check.
+
+
+
+ + + + + + + + + + +
+ (0015413) +
+ Jacob Wieland - Spirent    +
+ 07-08-2019 14:10    +
+ 		+ + + + +
+ ok
+
+
+
+ + + + + + + + + + +
+ (0015552) +
+ Tomas Urban    +
+ 17-12-2019 12:42    +
+ 		+ + + + +
+ Added to the final draft.
+
+ + diff --git a/docs/mantis/CR7848.md b/docs/mantis/CR7848.md new file mode 100644 index 0000000000000000000000000000000000000000..052302271bdb7e9ec15b19e9c9697c2f8a87804d --- /dev/null +++ b/docs/mantis/CR7848.md @@ -0,0 +1,323 @@ + + + + + + + + + + + + + 0007848: Mapping XML Schemas: Name clashes in NoTargetNamespace - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007848Part 09: Using XML with TTCN-3Technicalpublic14-06-2019 09:0328-12-2019 12:27
ReporterWolfgang Seka 
Assigned ToGyorgy Rethy 
PriorityurgentSeverityblockReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version4.11.1 (published 2020-05) 
Clause Reference(s)ES 201 873-9 clause 5.1.1 (mainly)
For STF discussion
Source (company - Author)MCC160 (Wolfgang)
Summary0007848: Mapping XML Schemas: Name clashes in NoTargetNamespace
DescriptionAccording to ES 201 873-9 all XSDs with no target namespace go into one and the same TTCN module (NoTargetNamespace), i.e. in TTCN they are in the same scope.
+But in practice XSDs with no target namespace do not belong to one and the same scope or context but they are independent from each other.
+This results in a name clash when different XSDs use the same name for global elements or types.
+EXAMPLE: The XSDs from annex D.2.2 of TS 24.237 and clause 5.1.3.4 of TS 24.390 both define <xs:complexType name="anyExtType">.
+
+NOTE: Even though in the above example the definitions are identical, in general this does not need to be the case.
+
+A related issue is, that different test suites may need different flavours of "NoTargetNamespace" i.e. "NoTargetNamespace" modules with different content.
+
+=> XSDs with no target namespace shall not be treated as if they would belong to one common namespace but a one-by-one mapping of XSD and target TTCN module should be applied, e.g. for each "no-target-namespace-X.xsd" a "no-target-namespace-X.ttcn" should be generated (implicitly or explicitly).
+
+As short-term workaround we have patched one of the XSDs an added a namespace but this will result in wrong coding as the patched schema will require the namespace to be included in the corresponding XML document.
+I don't know whether there is any hack with encoding rules for templates in TTCN to get around this.
+
+Another potential workaround could be the use of a proxy XSD (with namespace) including the no-target-namespace XSD; but again I don't know what to do to get rid of the namespace for encoding/decoding of XML instances.
+
+=> There seems to be no straight forward solution or workaround but part 9 should be changed to get away from the one-and-only NoTargetNamespace
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7848.docx (145,448) 08-08-2019 06:01
http://oldforge.etsi.org/mantis/file_download.php?file_id=3839&type=bug
docx CR7848-2.docx (145,195) 08-08-2019 08:31
http://oldforge.etsi.org/mantis/file_download.php?file_id=3840&type=bug
Issue History
Date ModifiedUsernameFieldChange
14-06-2019 09:03Wolfgang SekaNew Issue
06-08-2019 09:41Kristóf SzabadosNote Added: 0015370
06-08-2019 09:42Kristóf SzabadosStatusnew => resolved
06-08-2019 09:42Kristóf SzabadosResolutionopen => won't fix
06-08-2019 09:42Kristóf SzabadosAssigned To => Gyorgy Rethy
07-08-2019 08:46Kristóf SzabadosAssigned ToGyorgy Rethy => Kristóf Szabados
07-08-2019 08:46Kristóf SzabadosStatusresolved => new
07-08-2019 08:52Kristóf SzabadosNote Added: 0015385
07-08-2019 11:49Kristóf SzabadosProjectTTCN-3 Change Requests => Part 09: Using XML with TTCN-3
07-08-2019 12:02Kristóf SzabadosStatusnew => assigned
08-08-2019 06:01Kristóf SzabadosFile Added: CR7848.docx
08-08-2019 07:41Kristóf SzabadosAssigned ToKristóf Szabados => Jacob Wieland - Spirent
08-08-2019 07:41Kristóf SzabadosNote Added: 0015417
08-08-2019 08:31Jacob Wieland - SpirentFile Added: CR7848-2.docx
08-08-2019 08:32Jacob Wieland - SpirentNote Added: 0015419
08-08-2019 08:33Jacob Wieland - SpirentNote Added: 0015420
08-08-2019 08:33Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Tomas Urban
08-08-2019 08:33Jacob Wieland - SpirentStatusassigned => confirmed
08-08-2019 09:46Tomas UrbanNote Added: 0015425
08-08-2019 09:46Tomas UrbanAssigned ToTomas Urban => Kristóf Szabados
08-08-2019 09:54Kristóf SzabadosNote Added: 0015426
08-08-2019 09:54Kristóf SzabadosStatusconfirmed => resolved
08-08-2019 09:54Kristóf SzabadosFixed in Version => v4.10.1 (published 2019-05)
08-08-2019 09:54Kristóf SzabadosResolutionwon't fix => fixed
08-08-2019 09:54Kristóf SzabadosAssigned ToKristóf Szabados => Gyorgy Rethy
28-12-2019 11:39Gyorgy RethyNote Added: 0015585
28-12-2019 11:39Gyorgy RethyStatusresolved => closed
28-12-2019 12:27Gyorgy RethyFixed in Versionv4.10.1 (published 2019-05) => 4.11.1 (published 2020-05)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015370) +
+ Kristóf Szabados    +
+ 06-08-2019 09:41    +
+ 		+ + + + +
+ STF discussion: These kind of issues always need to be resolved on the XSD side. In your case delete one of the element types.
+
+
+
+ + + + + + + + + + +
+ (0015385) +
+ Kristóf Szabados    +
+ 07-08-2019 08:52    +
+ 		+ + + + +
+ STF discussion: On further inspection. This could be supported by a combination of tool dependent option and standardized support.
+The standard could describe how each xsd file that has no target namespace should be converted into separate TTCN-3 modules.
+
+As this feature would break backward compatibility it will also have the tool dependent part, that users should be allowed to choose if they wish to convert XSDs according to the old conversion rules, or the new one.
+The backward compatilibility breaking comes as all previously written TTCN-3 files importing from such a generated module will have to be updated, to import from one or more of the newly generated modules.
+
+
+
+ + + + + + + + + + +
+ (0015417) +
+ Kristóf Szabados    +
+ 08-08-2019 07:41    +
+ 		+ + + + +
+ Please review
+
+
+
+ + + + + + + + + + +
+ (0015419) +
+ Jacob Wieland - Spirent    +
+ 08-08-2019 08:32    +
+ 		+ + + + +
+ Made the second part a bit less ambiguous (one sentence stated that NoTargetNamespace should be used, another stated, that that should be used only sometimes.
+
+Also fixed some typos.
+
+
+
+ + + + + + + + + + +
+ (0015420) +
+ Jacob Wieland - Spirent    +
+ 08-08-2019 08:33    +
+ 		+ + + + +
+ please review
+
+
+
+ + + + + + + + + + +
+ (0015425) +
+ Tomas Urban    +
+ 08-08-2019 09:46    +
+ 		+ + + + +
+ I haven't found any issues, Kristof, could you please also check?
+
+
+
+ + + + + + + + + + +
+ (0015426) +
+ Kristóf Szabados    +
+ 08-08-2019 09:54    +
+ 		+ + + + +
+ Looks good to me, can be included in the next version.
+
+
+
+ + + + + + + + + + +
+ (0015585) +
+ Gyorgy Rethy    +
+ 28-12-2019 11:39    +
+ 		+ + + + +
+ Implemented in final draft 4.10.2.
+
+ + diff --git a/docs/mantis/CR7849.md b/docs/mantis/CR7849.md new file mode 100644 index 0000000000000000000000000000000000000000..ca2f07283a337755eda10b933967c9f67364bfb0 --- /dev/null +++ b/docs/mantis/CR7849.md @@ -0,0 +1,131 @@ + + + + + + + + + + + + + 0007849: C++ mapping of address parameter in TCI-TL check operation - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007849Part 06: TTCN-3 Control InterfaceTechnicalpublic14-06-2019 11:3617-12-2019 12:42
ReporterTomas Urban 
Assigned ToTomas Urban 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Versionv4.9.1(ongoing) 
Clause Reference(s)10.6.4
Source (company - Author) Elvior
Summary0007849: C++ mapping of address parameter in TCI-TL check operation
DescriptionThe address parameter of all checked_m operations is mapped to TriAddress. However, accoding to the abtract interface definition, it should be mapped into TciValue.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7849-1.docx (158,132) 07-08-2019 08:07
http://oldforge.etsi.org/mantis/file_download.php?file_id=3825&type=bug
Issue History
Date ModifiedUsernameFieldChange
14-06-2019 11:36Tomas UrbanNew Issue
06-08-2019 09:26Tomas UrbanAssigned To => Tomas Urban
06-08-2019 09:26Tomas UrbanStatusnew => assigned
07-08-2019 08:07Tomas UrbanFile Added: CR7849-1.docx
07-08-2019 08:08Tomas UrbanNote Added: 0015383
07-08-2019 08:08Tomas UrbanAssigned ToTomas Urban => Jacob Wieland - Spirent
07-08-2019 08:08Tomas UrbanStatusassigned => confirmed
07-08-2019 13:49Jacob Wieland - SpirentNote Added: 0015408
07-08-2019 13:49Jacob Wieland - SpirentStatusconfirmed => resolved
07-08-2019 13:49Jacob Wieland - SpirentFixed in Version => v4.9.1(ongoing)
07-08-2019 13:49Jacob Wieland - SpirentResolutionopen => fixed
07-08-2019 13:49Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Tomas Urban
17-12-2019 12:42Tomas UrbanNote Added: 0015551
17-12-2019 12:42Tomas UrbanStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015383) +
+ Tomas Urban    +
+ 07-08-2019 08:08    +
+ 		+ + + + +
+ Resolution uploaded. Please check.
+
+
+
+ + + + + + + + + + +
+ (0015408) +
+ Jacob Wieland - Spirent    +
+ 07-08-2019 13:49    +
+ 		+ + + + +
+ seems ok
+
+
+
+ + + + + + + + + + +
+ (0015551) +
+ Tomas Urban    +
+ 17-12-2019 12:42    +
+ 		+ + + + +
+ Added to the final draft.
+
+ + diff --git a/docs/mantis/CR7852.md b/docs/mantis/CR7852.md new file mode 100644 index 0000000000000000000000000000000000000000..385798a44c8d16f59ccef0edc30a1dfd176fd457 --- /dev/null +++ b/docs/mantis/CR7852.md @@ -0,0 +1,143 @@ + + + + + + + + + + + + + 0007852: Allow inline type expressions also as actual type parameters. - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Advanced Parametrization (ES 202 784)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007852Ext Pack: Advanced Parametrization (ES 202 784)New Featurepublic06-08-2019 16:3317-12-2019 10:23
ReporterJacob Wieland - Spirent 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product VersionNext version (to be defined) 
Target VersionNext version (to be defined)Fixed in Version 
TS versionX
Clause Reference(s)5.2, 5.5
Source (company - Author)Spirent - Jacob Wieland
Summary0007852: Allow inline type expressions also as actual type parameters.
DescriptionConsider the following definition
+
+type record of union {
+  @default
+  T val,
+  record { Annotations ann, T val } annotated
+} AnnotatedList<T>;
+
+In case that the actual type parameter for T shall be a structured type, as well, at the moment a new type definition has to be provided for that actual parameter, even if that is the only place of usage.
+
+Instead, something like this should be allowed as a type expression:
+
+AnnotatedList<record { integer a, AnnotatedList<enumerated { a, b }> b }>
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7852.docx (128,132) 08-08-2019 09:17
http://oldforge.etsi.org/mantis/file_download.php?file_id=3842&type=bug
Issue History
Date ModifiedUsernameFieldChange
06-08-2019 16:33Jacob Wieland - SpirentNew Issue
07-08-2019 12:38Jacob Wieland - SpirentNote Added: 0015399
07-08-2019 12:38Jacob Wieland - SpirentAssigned To => Jacob Wieland - Spirent
07-08-2019 12:38Jacob Wieland - SpirentStatusnew => assigned
08-08-2019 09:17Jacob Wieland - SpirentFile Added: CR7852.docx
08-08-2019 09:18Jacob Wieland - SpirentNote Added: 0015422
08-08-2019 09:18Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Tomas Urban
08-08-2019 09:18Jacob Wieland - SpirentStatusassigned => confirmed
08-08-2019 09:54Tomas UrbanNote Added: 0015427
08-08-2019 09:54Tomas UrbanStatusconfirmed => resolved
08-08-2019 09:54Tomas UrbanResolutionopen => fixed
08-08-2019 09:54Tomas UrbanAssigned ToTomas Urban => Jens Grabowski
17-12-2019 10:23Jens GrabowskiStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015399) +
+ Jacob Wieland - Spirent    +
+ 07-08-2019 12:38    +
+ 		+ + + + +
+ STF discussion: proposal accepted
+
+
+
+ + + + + + + + + + +
+ (0015422) +
+ Jacob Wieland - Spirent    +
+ 08-08-2019 09:18    +
+ 		+ + + + +
+ please review
+
+
+
+ + + + + + + + + + +
+ (0015427) +
+ Tomas Urban    +
+ 08-08-2019 09:54    +
+ 		+ + + + +
+ The proposal resolves the described issue and is ready to be added to the next version of the specification.
+
+ + diff --git a/docs/mantis/CR7853.md b/docs/mantis/CR7853.md new file mode 100644 index 0000000000000000000000000000000000000000..089292db48d14429ebf70266ebaac6272b0b3de9 --- /dev/null +++ b/docs/mantis/CR7853.md @@ -0,0 +1,134 @@ + + + + + + + + + + + + + 0007853: classes should allow type parameterization - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Advanced Parametrization (ES 202 784)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007853Ext Pack: Advanced Parametrization (ES 202 784)Clarificationpublic07-08-2019 09:4017-12-2019 10:22
ReporterJacob Wieland - Spirent 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Versionv1.6.1 (published 2017-04) 
TS version
Clause Reference(s)
Source (company - Author)
Summary0007853: classes should allow type parameterization
DescriptionIf a TTCN-3 class shall be mapped to an external class which is generic over types, it should be possible to also model this in TTCN-3 as a generic class.
+
+This will allow mapping of external generic libraries like collections to TTCN-3 without loss of generality.
+
+Example:
+
+type external class @abstract Iterator<T> {
+  function hasNext() return boolean;
+  function next() return T;
+}
+
+type external class @abstract Container<T> {
+  function iterator() return Iterator<T>;
+  function size() return integer;
+  function isEmpty() return boolean;
+}
+
+type external class Set<T> extends Container<T> {
+}
+
+type external class List<T> extends Container<T> {
+}
+
+type external class MapEntr<Key, Value> {
+  function getKey() return Key;
+  function getValue() return Value;
+}
+
+type external class Map<Key,Value> {
+  function get(Key key) return Value;
+  function put(Key key, Value val);
+  function keySet() return Set<Key>;
+  function values() return List<Value>;
+  function entrySet() return Set<MapEntry<Key, Value>>;
+  function containsKey(Key key) return boolean;
+  function contains(Value val) return boolean;
+}
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7853.docx (153,932) 08-08-2019 10:02
http://oldforge.etsi.org/mantis/file_download.php?file_id=3845&type=bug
docx CR7853-2.docx (179,778) 08-08-2019 11:29
http://oldforge.etsi.org/mantis/file_download.php?file_id=3847&type=bug
Issue History
Date ModifiedUsernameFieldChange
07-08-2019 09:40Jacob Wieland - SpirentNew Issue
07-08-2019 09:40Jacob Wieland - SpirentStatusnew => assigned
07-08-2019 09:40Jacob Wieland - SpirentAssigned To => Jacob Wieland - Spirent
07-08-2019 12:30Kristóf SzabadosProjectExt Pack: Object-oriented features (ES 203 790) => Ext Pack: Advanced Parametrization (ES 202 784)
08-08-2019 10:02Jacob Wieland - SpirentFile Added: CR7853.docx
08-08-2019 10:03Jacob Wieland - SpirentNote Added: 0015429
08-08-2019 10:03Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Tomas Urban
08-08-2019 10:03Jacob Wieland - SpirentStatusassigned => confirmed
08-08-2019 11:29Tomas UrbanFile Added: CR7853-2.docx
08-08-2019 11:32Tomas UrbanNote Added: 0015432
08-08-2019 11:32Tomas UrbanAssigned ToTomas Urban => Jacob Wieland - Spirent
08-08-2019 11:32Tomas UrbanCategoryGeneral => Clarification
08-08-2019 13:12Jacob Wieland - SpirentStatusconfirmed => resolved
08-08-2019 13:12Jacob Wieland - SpirentFixed in Version => v1.6.1 (published 2017-04)
08-08-2019 13:12Jacob Wieland - SpirentResolutionopen => fixed
08-08-2019 13:12Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Jens Grabowski
17-12-2019 10:22Jens GrabowskiStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015429) +
+ Jacob Wieland - Spirent    +
+ 08-08-2019 10:03    +
+ 		+ + + + +
+ please review
+
+
+
+ + + + + + + + + + +
+ (0015432) +
+ Tomas Urban    +
+ 08-08-2019 11:32    +
+ 		+ + + + +
+ The proposal is fine. I only changed the font from bold to normal in the example (only keywords should be bold) and added p_ prefixes to the parameters to follow the standard naming convention. Please check.
+
+ + diff --git a/docs/mantis/CR7854.md b/docs/mantis/CR7854.md new file mode 100644 index 0000000000000000000000000000000000000000..9c5efe8a358e0d66a3a1fb155a1348217f5bb17e --- /dev/null +++ b/docs/mantis/CR7854.md @@ -0,0 +1,182 @@ + + + + + + + + + + + + + 0007854: Better BNF derivations for 'this' and this-related entities are necessary - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Object-oriented features (ES 203 790)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007854Ext Pack: Object-oriented features (ES 203 790)[All Projects] Generalpublic07-08-2019 11:2809-01-2020 16:04
ReporterJacob Wieland - Spirent 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0007854: Better BNF derivations for 'this' and this-related entities are necessary
DescriptionTo allow method calls on 'this' as well as referencing fields of this on the left hand side and fields of 'this' and 'this' itself on the right hand side, the following changes need to be made:
+
+Change the BNF rule for ObjectInstance to:
+
+ObjectInstance ::= ThisOp
+                 | ValueRef
+                 | FunctionInstance [ ExtendedFieldReference ]
+
+Add a change for BNF rule ValueRef (to allow assignments to object fields):
+
+ValueRef ::= ( Identifier | ThisOp Dot Identifier ) [ExtendedFieldReference]
+
+Add a change for BNF rule ReferencedValue:
+
+ReferencedValue ::= ( ( Identifier | ThisOp ) [ExtendedFieldReference] )
+                  | ReferencedEnumValue
+
+Remove the BNF rule change for ConfigurationOps
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7854.docx (131,342) 07-08-2019 11:49
http://oldforge.etsi.org/mantis/file_download.php?file_id=3830&type=bug
docx CR7854-2.docx (133,828) 07-08-2019 14:01
http://oldforge.etsi.org/mantis/file_download.php?file_id=3837&type=bug
Issue History
Date ModifiedUsernameFieldChange
07-08-2019 11:28Jacob Wieland - SpirentNew Issue
07-08-2019 11:28Jacob Wieland - SpirentStatusnew => assigned
07-08-2019 11:28Jacob Wieland - SpirentAssigned To => Jacob Wieland - Spirent
07-08-2019 11:49Jacob Wieland - SpirentFile Added: CR7854.docx
07-08-2019 11:49Jacob Wieland - SpirentNote Added: 0015394
07-08-2019 11:49Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Tomas Urban
07-08-2019 11:49Jacob Wieland - SpirentStatusassigned => confirmed
07-08-2019 13:55Tomas UrbanAssigned ToTomas Urban => Jacob Wieland - Spirent
07-08-2019 13:55Tomas UrbanStatusconfirmed => assigned
07-08-2019 13:56Tomas UrbanNote Added: 0015409
07-08-2019 14:01Jacob Wieland - SpirentFile Added: CR7854-2.docx
07-08-2019 14:02Jacob Wieland - SpirentNote Added: 0015410
07-08-2019 14:02Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Tomas Urban
07-08-2019 14:02Jacob Wieland - SpirentStatusassigned => confirmed
07-08-2019 14:08Tomas UrbanNote Added: 0015411
07-08-2019 14:08Tomas UrbanStatusconfirmed => resolved
07-08-2019 14:08Tomas UrbanResolutionopen => fixed
07-08-2019 14:08Tomas UrbanAssigned ToTomas Urban => Jens Grabowski
09-01-2020 16:04Jens GrabowskiStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015394) +
+ Jacob Wieland - Spirent    +
+ 07-08-2019 11:49    +
+ 		+ + + + +
+ please review
+
+
+
+ + + + + + + + + + +
+ (0015409) +
+ Tomas Urban    +
+ 07-08-2019 13:56    +
+ 		+ + + + +
+ The proposal is fine, but BNF support for object method calls should be added in order to support constructions like this.myMethod()
+
+
+
+ + + + + + + + + + +
+ (0015410) +
+ Jacob Wieland - Spirent    +
+ 07-08-2019 14:02    +
+ 		+ + + + +
+ re added change to ObjectInstance, please check
+
+
+
+ + + + + + + + + + +
+ (0015411) +
+ Tomas Urban    +
+ 07-08-2019 14:08    +
+ 		+ + + + +
+ The proposal is fine and it can be added to next version of the specification.
+
+ + diff --git a/docs/mantis/CR7855.md b/docs/mantis/CR7855.md new file mode 100644 index 0000000000000000000000000000000000000000..25e4bceede05a764fa928dfcc812614a32b9fbab --- /dev/null +++ b/docs/mantis/CR7855.md @@ -0,0 +1,103 @@ + + + + + + + + + + + + + 0007855: BNF for ClassMember should not allow more than one ConstructorDef - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Object-oriented features (ES 203 790)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007855Ext Pack: Object-oriented features (ES 203 790)[All Projects] Generalpublic07-08-2019 12:0909-01-2020 16:04
ReporterAxel Rennoch (old account) 
Assigned ToKristóf Szabados 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionno change required 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0007855: BNF for ClassMember should not allow more than one ConstructorDef
DescriptionIn section A.3 the TTCN-3 syntax BNF production allows more than one instance of ConstructorDef.
+
+Since section 5.1.1.5 introduces one constructor only the BNF rules need to be corrected.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
07-08-2019 12:09Axel Rennoch (old account)New Issue
07-08-2019 12:44Jacob Wieland - SpirentNote Added: 0015400
08-08-2019 14:29Kristóf SzabadosNote Added: 0015437
08-08-2019 14:30Kristóf SzabadosStatusnew => resolved
08-08-2019 14:30Kristóf SzabadosResolutionopen => no change required
08-08-2019 14:30Kristóf SzabadosAssigned To => Kristóf Szabados
09-01-2020 16:04Jens GrabowskiStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015400) +
+ Jacob Wieland - Spirent    +
+ 07-08-2019 12:44    +
+ 		+ + + + +
+ This is covered by the scoping rules. The constructor introduces a name create and two definitions of the same name in the same scope are not allowed.
+
+Therefore, no BNF change is necessary.
+
+Also, it would not be easy to formulate this on the BNF level.
+
+
+
+ + + + + + + + + + +
+ (0015437) +
+ Kristóf Szabados    +
+ 08-08-2019 14:29    +
+ 		+ + + + +
+ STF discussion: not necessary to restrict syntactically, the check is easier on semantic level.
+
+ + diff --git a/docs/mantis/CR7856.md b/docs/mantis/CR7856.md new file mode 100644 index 0000000000000000000000000000000000000000..f34ffe11811cdad978e768a480ac42a98d7e37a5 --- /dev/null +++ b/docs/mantis/CR7856.md @@ -0,0 +1,219 @@ + + + + + + + + + + + + + 0007856: Implicit constructor shall only provide parameters for non-var fields without initializer - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Object-oriented features (ES 203 790)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007856Ext Pack: Object-oriented features (ES 203 790)[All Projects] Generalpublic08-08-2019 12:1009-01-2020 16:03
ReporterJacob Wieland - Spirent 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0007856: Implicit constructor shall only provide parameters for non-var fields without initializer
DescriptionIn the case that a constant or template field of a class already has an initializer, the implicit constructor would violate the rule that a constant/template should only be initialized once and the initialization would fail because these fields are already initialized.
+
+Example:
+
+type class C {
+  const integer i := 5;
+  const integer j;
+  // implicit constructor
+  create(integer i, integer j) {
+    this.i := i;
+    this.j := j;
+  }
+}
+
+Therefore, the implicit constructor derivation should be changed that it excludes all const and template fields that already have an initializer from the parameter list:
+
+==>
+
+create(integer j) {
+  this.j := j;
+}
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0007868closed Jens Grabowski External classes should be allowed internal members (direct and inherited) 
Attached Filesdocx CR7856.docx (141,386) 08-08-2019 13:08
http://oldforge.etsi.org/mantis/file_download.php?file_id=3848&type=bug
docx CR7856-2.docx (164,514) 08-08-2019 14:21
http://oldforge.etsi.org/mantis/file_download.php?file_id=3849&type=bug
docx CR7856-3.docx (143,222) 08-08-2019 14:38
http://oldforge.etsi.org/mantis/file_download.php?file_id=3850&type=bug
Issue History
Date ModifiedUsernameFieldChange
08-08-2019 12:10Jacob Wieland - SpirentNew Issue
08-08-2019 12:10Jacob Wieland - SpirentStatusnew => assigned
08-08-2019 12:10Jacob Wieland - SpirentAssigned To => Jacob Wieland - Spirent
08-08-2019 13:08Jacob Wieland - SpirentFile Added: CR7856.docx
08-08-2019 13:09Jacob Wieland - SpirentNote Added: 0015433
08-08-2019 13:09Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Tomas Urban
08-08-2019 13:09Jacob Wieland - SpirentStatusassigned => confirmed
08-08-2019 14:21Tomas UrbanFile Added: CR7856-2.docx
08-08-2019 14:28Tomas UrbanNote Added: 0015436
08-08-2019 14:28Tomas UrbanAssigned ToTomas Urban => Jacob Wieland - Spirent
08-08-2019 14:38Jacob Wieland - SpirentFile Added: CR7856-3.docx
08-08-2019 14:39Jacob Wieland - SpirentNote Added: 0015438
08-08-2019 14:39Jacob Wieland - SpirentStatusconfirmed => resolved
08-08-2019 14:39Jacob Wieland - SpirentResolutionopen => fixed
08-08-2019 14:39Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Jens Grabowski
18-12-2019 09:27Tomas UrbanRelationship addedrelated to 0007868
18-12-2019 09:27Jens GrabowskiNote Added: 0015570
18-12-2019 09:28Jens GrabowskiAssigned ToJens Grabowski => Tomas Urban
18-12-2019 09:28Jens GrabowskiStatusresolved => assigned
18-12-2019 10:23Tomas UrbanNote Added: 0015574
18-12-2019 10:23Tomas UrbanAssigned ToTomas Urban => Jacob Wieland - Spirent
18-12-2019 10:23Tomas UrbanStatusassigned => confirmed
18-12-2019 11:04Jacob Wieland - SpirentStatusconfirmed => resolved
18-12-2019 11:04Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Jens Grabowski
09-01-2020 16:03Jens GrabowskiStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015433) +
+ Jacob Wieland - Spirent    +
+ 08-08-2019 13:09    +
+ 		+ + + + +
+ please review
+
+
+
+ + + + + + + + + + +
+ (0015436) +
+ Tomas Urban    +
+ 08-08-2019 14:28    +
+ 		+ + + + +
+ Mostly OK, I slightly modified syntax description and added one sentence to the constructor rules. Please check.
+
+
+
+ + + + + + + + + + +
+ (0015438) +
+ Jacob Wieland - Spirent    +
+ 08-08-2019 14:39    +
+ 		+ + + + +
+ another small correction Type -> ReferencedType in the super-constructor call
+
+
+
+ + + + + + + + + + +
+ (0015570) +
+ Jens Grabowski    +
+ 18-12-2019 09:27    +
+ 		+ + + + +
+ conflicts with 7868, 7830
+
+
+
+ + + + + + + + + + +
+ (0015574) +
+ Tomas Urban    +
+ 18-12-2019 10:23    +
+ 		+ + + + +
+ Merged with changes from 0007868 and 0007830. The merged document is in 0007868. Please mark this CR as resolved if review of the document yield a positive result.
+
+ + diff --git a/docs/mantis/CR7857.md b/docs/mantis/CR7857.md new file mode 100644 index 0000000000000000000000000000000000000000..ba457dbec3f5e9eab61424802db2595496b771a7 --- /dev/null +++ b/docs/mantis/CR7857.md @@ -0,0 +1,173 @@ + + + + + + + + + + + + + 0007857: Superfluos restriction 16.1.4.k - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007857Part 01: TTCN-3 Core LanguageTechnicalpublic14-08-2019 14:0426-08-2019 11:15
ReporterTomas Urban 
Assigned ToJacob Wieland - Spirent 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionno change required 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version4.12.1 (published 2020-05) 
Clause Reference(s)16.1.4
Source (company - Author)STF 472
Summary0007857: Superfluos restriction 16.1.4.k
DescriptionThe restriction 16.1.4.j should be removed, because the restriction 16.1.4.m already covers all relevant cases and the restriction j also doesn't count with deterministic parameters which don't affect snapshots.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
14-08-2019 14:04Tomas UrbanNew Issue
14-08-2019 15:20Tomas UrbanDescription Updatedbug_revision_view_page.php?rev_id=497#r497
15-08-2019 12:37Kristóf SzabadosNote Added: 0015443
15-08-2019 12:57Tomas UrbanNote Added: 0015444
15-08-2019 12:57Tomas UrbanSummarySuperfluos restriction 16.1.4.j => Superfluos restriction 16.1.4.k
26-08-2019 11:14Jacob Wieland - SpirentNote Added: 0015453
26-08-2019 11:15Jacob Wieland - SpirentStatusnew => resolved
26-08-2019 11:15Jacob Wieland - SpirentFixed in Version => 4.12.1 (published 2020-05)
26-08-2019 11:15Jacob Wieland - SpirentResolutionopen => no change required
26-08-2019 11:15Jacob Wieland - SpirentAssigned To => Jacob Wieland - Spirent
26-08-2019 11:15Jacob Wieland - SpirentNote Added: 0015454
26-08-2019 11:15Jacob Wieland - SpirentStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015443) +
+ Kristóf Szabados    +
+ 15-08-2019 12:37    +
+ 		+ + + + +
+ If I unsertand it correctly they don't overlap perfectly.
+
+16.1.4.m is about referencing variables, parameters or templates that are lazy or fuzzy.
+
+While 16.1.4.j is about functions and external functions that have out or inout parameters (which parameters are not required to be lazy or fuzzy).
+
+
+
+ + + + + + + + + + +
+ (0015444) +
+ Tomas Urban    +
+ 15-08-2019 12:57    +
+ 		+ + + + +
+ I am sorry, you are absolutely correct, the restriction I meant is 16.1.4.k:
+
+k) Calling functions and external functions with @fuzzy formal parameters and variables
+
+I changed the summary to reflect this.
+
+
+
+ + + + + + + + + + +
+ (0015453) +
+ Jacob Wieland - Spirent    +
+ 26-08-2019 11:14    +
+ 		+ + + + +
+ STF discussion: Even though other rules already imply restriction k) we leave this rule in the standard as it doesn't do any harm.
+
+
+
+ + + + + + + + + + +
+ (0015454) +
+ Jacob Wieland - Spirent    +
+ 26-08-2019 11:15    +
+ 		+ + + + +
+ nothing to do
+
+ + diff --git a/docs/mantis/CR7858.md b/docs/mantis/CR7858.md new file mode 100644 index 0000000000000000000000000000000000000000..c527bd8ca9557c541f3e380672ab490e72a2496f --- /dev/null +++ b/docs/mantis/CR7858.md @@ -0,0 +1,133 @@ + + + + + + + + + + + + + 0007858: Invalid restriction for non-deterministic lazy and fuzzy parameters - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007858Part 01: TTCN-3 Core LanguageTechnicalpublic21-08-2019 10:5428-12-2019 16:41
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version4.12.1 (published 2020-05) 
Clause Reference(s)5.4.2
Source (company - Author)STF 572
Summary0007858: Invalid restriction for non-deterministic lazy and fuzzy parameters
DescriptionRestriction 5.4.2.p says that rules for functions called from special places shall apply to actual parameters passed to lazy and fuzzy formal parameters.
+
+However, this rule should apply only to actual parameters passed to @deterministic lazy and fuzzy formal paramateres. Non-deterministic parameters can contain non-deterministic content, that's what they are meant for.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7858-1.docx (195,041) 26-08-2019 14:48
http://oldforge.etsi.org/mantis/file_download.php?file_id=3854&type=bug
Issue History
Date ModifiedUsernameFieldChange
21-08-2019 10:54Tomas UrbanNew Issue
26-08-2019 11:03Jacob Wieland - SpirentNote Added: 0015452
26-08-2019 11:03Jacob Wieland - SpirentAssigned To => Tomas Urban
26-08-2019 11:03Jacob Wieland - SpirentStatusnew => assigned
26-08-2019 14:48Tomas UrbanFile Added: CR7858-1.docx
26-08-2019 14:51Tomas UrbanNote Added: 0015458
26-08-2019 14:51Tomas UrbanStatusassigned => resolved
26-08-2019 14:51Tomas UrbanFixed in Version => 4.12.1 (published 2020-05)
26-08-2019 14:51Tomas UrbanResolutionopen => fixed
26-08-2019 14:51Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
28-12-2019 16:41Gyorgy RethyNote Added: 0015594
28-12-2019 16:41Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015452) +
+ Jacob Wieland - Spirent    +
+ 26-08-2019 11:03    +
+ 		+ + + + +
+ STF discussion: add @deterministic before fuzzy or lazy in restriction p.
+
+
+
+ + + + + + + + + + +
+ (0015458) +
+ Tomas Urban    +
+ 26-08-2019 14:51    +
+ 		+ + + + +
+ This trivial correction is ready to be added to the next version of the core language standard.
+
+
+
+ + + + + + + + + + +
+ (0015594) +
+ Gyorgy Rethy    +
+ 28-12-2019 16:41    +
+ 		+ + + + +
+ Included to final draft V4.11.2
+
+ + diff --git a/docs/mantis/CR7859.md b/docs/mantis/CR7859.md new file mode 100644 index 0000000000000000000000000000000000000000..8c571fcc3daf0e3e2a5bd6816358cca7a3262237 --- /dev/null +++ b/docs/mantis/CR7859.md @@ -0,0 +1,170 @@ + + + + + + + + + + + + + 0007859: Modified BNF/restrictions for functions, external functions and altsteps - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Object-oriented features (ES 203 790)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007859Ext Pack: Object-oriented features (ES 203 790)[All Projects] Generalpublic21-08-2019 15:5009-01-2020 16:04
ReporterAxel Rennoch (old account) 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0007859: Modified BNF/restrictions for functions, external functions and altsteps
DescriptionIn sections 5.2.1, 5.2.2 and 5.2.4 the extended BNF should be aligned with the BNF of part 1:
+
+- removal of: FormalTimerPar and FormalPortPar (already covered by FormalValueVar and FormalTemplatePar)
+- ControlModifier is missing; if this is intended it shall be stated as a new restriction
+
+In section 5.2.3 the additional restriction in clause 16.1.4 (part 1) is "n" (not "m")
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7859.docx (137,131) 16-12-2019 12:38
http://oldforge.etsi.org/mantis/file_download.php?file_id=3870&type=bug
docx CR7859-2.docx (156,871) 17-12-2019 11:30
http://oldforge.etsi.org/mantis/file_download.php?file_id=3883&type=bug
Issue History
Date ModifiedUsernameFieldChange
21-08-2019 15:50Axel Rennoch (old account)New Issue
26-08-2019 11:18Jacob Wieland - SpirentNote Added: 0015455
26-08-2019 11:23Jacob Wieland - SpirentAssigned To => Jacob Wieland - Spirent
26-08-2019 11:23Jacob Wieland - SpirentStatusnew => assigned
16-12-2019 12:38Jacob Wieland - SpirentFile Added: CR7859.docx
16-12-2019 12:39Jacob Wieland - SpirentNote Added: 0015521
16-12-2019 12:39Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Tomas Urban
16-12-2019 12:39Jacob Wieland - SpirentStatusassigned => confirmed
17-12-2019 11:30Tomas UrbanFile Added: CR7859-2.docx
17-12-2019 11:32Tomas UrbanNote Added: 0015545
17-12-2019 11:32Tomas UrbanAssigned ToTomas Urban => Jacob Wieland - Spirent
17-12-2019 13:46Jacob Wieland - SpirentNote Added: 0015556
17-12-2019 13:46Jacob Wieland - SpirentStatusconfirmed => resolved
17-12-2019 13:46Jacob Wieland - SpirentResolutionopen => fixed
17-12-2019 13:46Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Jens Grabowski
09-01-2020 16:04Jens GrabowskiStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015455) +
+ Jacob Wieland - Spirent    +
+ 26-08-2019 11:18    +
+ 		+ + + + +
+ STF-discussion: align grammar with core, allow @control modifier and keyword for function definitions, delete FormalTimerPar and FormalPortPar, rename restriction to proper letter.
+
+
+
+ + + + + + + + + + +
+ (0015521) +
+ Jacob Wieland - Spirent    +
+ 16-12-2019 12:39    +
+ 		+ + + + +
+ added proposal, please check
+
+
+
+ + + + + + + + + + +
+ (0015545) +
+ Tomas Urban    +
+ 17-12-2019 11:32    +
+ 		+ + + + +
+ I made some minor changes in the BNF and syntax description (missing control and interleave clauses). Please review and if you are fine with the changes, the CR can be marked as resolved.
+
+
+
+ + + + + + + + + + +
+ (0015556) +
+ Jacob Wieland - Spirent    +
+ 17-12-2019 13:46    +
+ 		+ + + + +
+ changes are ok
+
+ + diff --git a/docs/mantis/CR7860.md b/docs/mantis/CR7860.md new file mode 100644 index 0000000000000000000000000000000000000000..317cbb8b4c46e9dfecdc2104824896ef04c757f6 --- /dev/null +++ b/docs/mantis/CR7860.md @@ -0,0 +1,165 @@ + + + + + + + + + + + + + 0007860: CR 7611 wasn't properly added to the specification - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007860Part 01: TTCN-3 Core LanguageEditorialpublic23-08-2019 09:3828-12-2019 17:23
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version4.12.1 (published 2020-05) 
Clause Reference(s)6.2.9
Source (company - Author)STF 572
Summary0007860: CR 7611 wasn't properly added to the specification
DescriptionResolution of CR 0007611 wasn't propertly added to the specification. The first sentence added to the section 6.2.9 was inserted twice and the second one was not inserted at all.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0007611closed Gyorgy Rethy Valid port lists for the procedure operations 
Attached Filesdocx CR7860-1.docx (183,498) 26-08-2019 15:09
http://oldforge.etsi.org/mantis/file_download.php?file_id=3856&type=bug
Issue History
Date ModifiedUsernameFieldChange
23-08-2019 09:38Tomas UrbanNew Issue
23-08-2019 09:39Tomas UrbanRelationship addedrelated to 0007611
26-08-2019 10:40Jacob Wieland - SpirentNote Added: 0015451
26-08-2019 10:40Jacob Wieland - SpirentAssigned To => Tomas Urban
26-08-2019 10:40Jacob Wieland - SpirentStatusnew => assigned
26-08-2019 15:09Tomas UrbanFile Added: CR7860-1.docx
26-08-2019 15:09Tomas UrbanNote Added: 0015461
26-08-2019 15:09Tomas UrbanAssigned ToTomas Urban => Kristóf Szabados
26-08-2019 15:09Tomas UrbanStatusassigned => confirmed
27-08-2019 10:42Kristóf SzabadosNote Added: 0015467
27-08-2019 10:42Kristóf SzabadosStatusconfirmed => resolved
27-08-2019 10:42Kristóf SzabadosFixed in Version => 4.12.1 (published 2020-05)
27-08-2019 10:42Kristóf SzabadosResolutionopen => fixed
27-08-2019 10:42Kristóf SzabadosAssigned ToKristóf Szabados => Gyorgy Rethy
28-12-2019 17:23Gyorgy RethyNote Added: 0015602
28-12-2019 17:23Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015451) +
+ Jacob Wieland - Spirent    +
+ 26-08-2019 10:40    +
+ 		+ + + + +
+ STF-discussion: agreed as proposed
+
+
+
+ + + + + + + + + + +
+ (0015461) +
+ Tomas Urban    +
+ 26-08-2019 15:09    +
+ 		+ + + + +
+ Resolution uploaded, please check.
+
+
+
+ + + + + + + + + + +
+ (0015467) +
+ Kristóf Szabados    +
+ 27-08-2019 10:42    +
+ 		+ + + + +
+ The solution looks good. Can be added to the next version of the standard.
+
+
+
+ + + + + + + + + + +
+ (0015602) +
+ Gyorgy Rethy    +
+ 28-12-2019 17:23    +
+ 		+ + + + +
+ Included to final draft V4.11.2.
+
+ + diff --git a/docs/mantis/CR7861.md b/docs/mantis/CR7861.md new file mode 100644 index 0000000000000000000000000000000000000000..7c3c31bfdc4a3b0975fd75e7f05396949742e2fd --- /dev/null +++ b/docs/mantis/CR7861.md @@ -0,0 +1,233 @@ + + + + + + + + + + + + + 0007861: Indirect reference to a deprecated feature - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007861Part 01: TTCN-3 Core LanguageEditorialpublic23-08-2019 09:5628-12-2019 17:19
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version4.12.1 (published 2020-05) 
Clause Reference(s)6.2.10.1
Source (company - Author)STF 572
Summary0007861: Indirect reference to a deprecated feature
DescriptionThe example 1 of 6.2.10.1 contains a reference to a port type called "MyAllMesssagesPortType". This type used to be defined in another example in older versions of the specification and allowed all messages to be sent. However, the "all" syntax for ports have been deprecated and the example together with definition of the MyAllMesssagesPortType type removed from the specification. Thus, the reference to the MyAllMessagesPortType type should be removed from the example 1 of 6.2.10.1 as well.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7861-1.docx (186,152) 26-08-2019 14:55
http://oldforge.etsi.org/mantis/file_download.php?file_id=3855&type=bug
Issue History
Date ModifiedUsernameFieldChange
23-08-2019 09:56Tomas UrbanNew Issue
23-08-2019 10:06Tomas UrbanNote Added: 0015445
23-08-2019 10:22Tomas UrbanNote Added: 0015446
26-08-2019 10:36Jacob Wieland - SpirentNote Added: 0015450
26-08-2019 10:37Jacob Wieland - SpirentAssigned To => Tomas Urban
26-08-2019 10:37Jacob Wieland - SpirentStatusnew => assigned
26-08-2019 14:55Tomas UrbanFile Added: CR7861-1.docx
26-08-2019 14:56Tomas UrbanNote Added: 0015460
26-08-2019 14:56Tomas UrbanAssigned ToTomas Urban => Kristóf Szabados
26-08-2019 14:56Tomas UrbanStatusassigned => confirmed
27-08-2019 10:50Kristóf SzabadosNote Added: 0015468
27-08-2019 10:50Kristóf SzabadosStatusconfirmed => resolved
27-08-2019 10:50Kristóf SzabadosFixed in Version => 4.12.1 (published 2020-05)
27-08-2019 10:50Kristóf SzabadosResolutionopen => fixed
27-08-2019 10:50Kristóf SzabadosAssigned ToKristóf Szabados => Gyorgy Rethy
28-12-2019 17:19Gyorgy RethyNote Added: 0015601
28-12-2019 17:19Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015445) +
+ Tomas Urban    +
+ 23-08-2019 10:06    +
+ 		+ + + + +
+ There's a related issues with type naming of types in the example 3 of the same chapter. The types MyMessageInterfaceType and MyProcedureInterfaceType are not defined in the document. It would be convenient to use already defined types: MyMessagePortType and MyProcedurePortType (which are used in examples 1 and 2).
+
+
+
+ + + + + + + + + + +
+ (0015446) +
+ Tomas Urban    +
+ 23-08-2019 10:22    +
+ 		+ + + + +
+ The example 3 is also missing a semi-colon in the definition of pCO. According to A.1.2, the semi-colon is mandatory in this type of declaration.
+
+
+
+ + + + + + + + + + +
+ (0015450) +
+ Jacob Wieland - Spirent    +
+ 26-08-2019 10:36    +
+ 		+ + + + +
+ STF discussion: agreed as proposed
+
+
+
+ + + + + + + + + + +
+ (0015460) +
+ Tomas Urban    +
+ 26-08-2019 14:56    +
+ 		+ + + + +
+ Resolution uploaded. Please check.
+
+
+
+ + + + + + + + + + +
+ (0015468) +
+ Kristóf Szabados    +
+ 27-08-2019 10:50    +
+ 		+ + + + +
+ The solution looks fine for me.
+
+
+
+ + + + + + + + + + +
+ (0015601) +
+ Gyorgy Rethy    +
+ 28-12-2019 17:19    +
+ 		+ + + + +
+ Corrected in final draft V4.11.2
+
+ + diff --git a/docs/mantis/CR7862.md b/docs/mantis/CR7862.md new file mode 100644 index 0000000000000000000000000000000000000000..50c3bc048e6f63375acf5082fd95a2f953dfc654 --- /dev/null +++ b/docs/mantis/CR7862.md @@ -0,0 +1,1078 @@ + + + + + + + + + + + + + 0007862: Allow trait classes and multiple inheritance - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Object-oriented features (ES 203 790)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007862Ext Pack: Object-oriented features (ES 203 790)[All Projects] Generalpublic26-08-2019 12:5828-12-2020 13:04
ReporterJacob Wieland - Spirent 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product VersionV1.2.1 (published 2020-05) 
Target VersionV1.3.1 (ongoing)Fixed in Version 
Summary0007862: Allow trait classes and multiple inheritance
DescriptionA trait class is a form of abstract class that can not be created but only extended. It can only extend other trait classes.
+
+A normal class should be allowed to extend a list of trait classes beside its superclass. It inherits all members from all the trait classes it extends.
+
+If a class extends two classes which both provide a member with the same name, that member shall be inherited from the same *defining* class (the most concrete extended class defining or overriding that member). If a trait and a class both need to access the same field, that field shall be inherited from the same defining trait class.
+
+Fields of trait classes shall not have an initializer. Trait classes also do not have a constructor.
+
+Example:
+
+external function newGlobalId() return charstring;
+
+type class @trait Identifiable {
+  private var charstring id;
+  public function setId(charstring id) {
+    this.id := id;
+  }
+
+  public function getId() return charstring {
+    return id;
+  }
+}
+
+type class MyIdentifiableClass extends Identifiable {
+  create(charstring id) {
+    setId(id);
+  }
+}
+
+var Identifiable v_idObj := MyIdentifiableClass.create("1");
+var charstring v_id := v_idObj.getId();
+
+Example 2: parallel inheritance
+
+type class @trait A {
+  function @abstract f();
+}
+
+type class @trait B {
+  function @abstract f();
+}
+
+type class C extends A, B {
+  // illegal, as it inherits A.f() and B.f()
+}
+
+type class @trait B2 extends A {}
+
+type class C2 extends A, B2 { // legal, as it inherits only A.f()
+  function f() { ... }
+}
+
+type class C3 extends A {
+  function f() { ... }
+}
+
+type class D extends C2, C3 {
+  // illegal, as it inherits C2.f() and C3.f()
+}
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7862.docx (146,209) 28-08-2019 12:10
http://oldforge.etsi.org/mantis/file_download.php?file_id=3862&type=bug
docx CR7862-2.docx (167,362) 28-08-2019 13:51
http://oldforge.etsi.org/mantis/file_download.php?file_id=3863&type=bug
docx CR7862-3.docx (148,469) 28-08-2019 14:17
http://oldforge.etsi.org/mantis/file_download.php?file_id=3864&type=bug
docx CR7862-4.docx (148,365) 07-10-2020 12:26
http://oldforge.etsi.org/mantis/file_download.php?file_id=3957&type=bug
docx CR7862-5.docx (148,418) 07-12-2020 13:18
http://oldforge.etsi.org/mantis/file_download.php?file_id=3966&type=bug
docx CR7862-6.docx (149,147) 09-12-2020 19:11
http://oldforge.etsi.org/mantis/file_download.php?file_id=3983&type=bug
Issue History
Date ModifiedUsernameFieldChange
26-08-2019 12:58Jacob Wieland - SpirentNew Issue
26-08-2019 12:58Jacob Wieland - SpirentStatusnew => assigned
26-08-2019 12:58Jacob Wieland - SpirentAssigned To => Jacob Wieland - Spirent
26-08-2019 14:28Jacob Wieland - SpirentStatusassigned => new
27-08-2019 09:41Kristóf SzabadosNote Added: 0015466
27-08-2019 11:59Jacob Wieland - SpirentNote Added: 0015469
27-08-2019 12:03Jacob Wieland - SpirentNote Added: 0015470
27-08-2019 14:50Jacob Wieland - SpirentNote Added: 0015477
27-08-2019 14:50Jacob Wieland - SpirentStatusnew => assigned
28-08-2019 12:10Jacob Wieland - SpirentFile Added: CR7862.docx
28-08-2019 12:20Jacob Wieland - SpirentNote Added: 0015482
28-08-2019 12:29Kristóf SzabadosNote Added: 0015484
28-08-2019 12:37Jacob Wieland - SpirentNote Added: 0015485
28-08-2019 12:37Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Tomas Urban
28-08-2019 12:37Jacob Wieland - SpirentStatusassigned => confirmed
28-08-2019 13:32Kristóf SzabadosNote Added: 0015487
28-08-2019 13:51Tomas UrbanFile Added: CR7862-2.docx
28-08-2019 13:53Tomas UrbanNote Added: 0015488
28-08-2019 13:53Tomas UrbanAssigned ToTomas Urban => Kristof.Szabados
28-08-2019 14:17Kristóf SzabadosFile Added: CR7862-3.docx
28-08-2019 14:20Kristóf SzabadosNote Added: 0015489
28-08-2019 14:20Kristóf SzabadosAssigned ToKristof.Szabados => Tomas Urban
28-08-2019 14:20Kristóf SzabadosStatusconfirmed => assigned
28-08-2019 14:21Kristóf SzabadosStatusassigned => confirmed
28-08-2019 14:40Tomas UrbanNote Added: 0015490
28-08-2019 14:40Tomas UrbanAssigned ToTomas Urban => Jens Grabowski
17-12-2019 11:22Jens GrabowskiAssigned ToJens Grabowski => Kristóf Szabados
17-12-2019 11:22Jens GrabowskiStatusconfirmed => assigned
18-12-2019 07:41Kristóf SzabadosNote Added: 0015565
18-12-2019 11:10Jacob Wieland - SpirentNote Added: 0015578
18-12-2019 11:35Jens GrabowskiNote Added: 0015580
18-12-2019 11:35Jens GrabowskiAssigned ToKristóf Szabados => Jens Grabowski
14-08-2020 11:26Jens GrabowskiAssigned ToJens Grabowski => Kristóf Szabados
06-10-2020 13:53Jens GrabowskiAssigned ToKristóf Szabados => Jacob Wieland - Spirent
06-10-2020 13:54Jens GrabowskiNote Added: 0015761
07-10-2020 12:26Jacob Wieland - SpirentFile Added: CR7862-4.docx
07-10-2020 12:27Jacob Wieland - SpirentNote Added: 0015774
07-10-2020 12:27Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Kristof.Szabados
07-10-2020 12:27Jacob Wieland - SpirentStatusassigned => confirmed
08-10-2020 13:28Kristóf SzabadosNote Added: 0015780
08-10-2020 13:29Kristóf SzabadosAssigned ToKristof.Szabados => Jacob Wieland - Spirent
08-10-2020 13:29Kristóf SzabadosStatusconfirmed => assigned
08-10-2020 13:29Kristóf SzabadosStatusassigned => confirmed
08-10-2020 15:50Jacob Wieland - SpirentNote Added: 0015784
08-10-2020 15:55Jacob Wieland - SpirentNote Added: 0015785
07-12-2020 13:18Jacob Wieland - SpirentFile Added: CR7862-5.docx
07-12-2020 13:19Jacob Wieland - SpirentStatusconfirmed => new
07-12-2020 13:20Jacob Wieland - SpirentNote Added: 0015797
07-12-2020 13:20Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Tomas Urban
07-12-2020 13:20Jacob Wieland - SpirentStatusnew => confirmed
09-12-2020 08:02Tomas UrbanNote Added: 0015819
09-12-2020 08:02Tomas UrbanAssigned ToTomas Urban => Kristóf Szabados
09-12-2020 19:11Kristóf SzabadosFile Added: CR7862-6.docx
09-12-2020 19:16Kristóf SzabadosNote Added: 0015828
09-12-2020 19:17Kristóf SzabadosNote Added: 0015829
09-12-2020 19:17Kristóf SzabadosAssigned ToKristóf Szabados => Tomas Urban
09-12-2020 19:17Kristóf SzabadosStatusconfirmed => assigned
10-12-2020 07:33Tomas UrbanNote Added: 0015832
10-12-2020 07:33Tomas UrbanAssigned ToTomas Urban => Jacob Wieland - Spirent
10-12-2020 07:33Tomas UrbanStatusassigned => confirmed
10-12-2020 09:21Jens GrabowskiNote Added: 0015839
10-12-2020 09:22Jens GrabowskiStatusconfirmed => resolved
10-12-2020 09:22Jens GrabowskiResolutionopen => fixed
10-12-2020 09:22Jens GrabowskiAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
17-12-2020 16:18Gyorgy RethyAssigned ToGyorgy Rethy => Jens Grabowski
17-12-2020 16:18Gyorgy RethyProduct Version => V1.2.1 (published 2020-05)
17-12-2020 16:18Gyorgy RethyTarget Version => V1.3.1 (ongoing)
28-12-2020 13:04Jens GrabowskiStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015466) +
+ Kristóf Szabados    +
+ 27-08-2019 09:41    +
+ 		+ + + + +
+ so multiple extension is only allowed for extending trait classes, and this extension behaves as a copy-paste of the trait's content, right?
+
+
+
+ + + + + + + + + + +
+ (0015469) +
+ Jacob Wieland - Spirent    +
+ 27-08-2019 11:59    +
+ 		+ + + + +
+ I would consider it more as a sort of flattening where first you flatten the definition of each extended class (keeping track of the original class of each member) and then merge the resulting class bodies of the flattened classes into one effective superclass while removing duplicates that come from the same (non-flattened) class body.
+
+type class @trait A {
+  var integer a;
+}
+
+type class @trait B {
+  var integer b;
+}
+
+type class @trait C {
+  var integer c;
+}
+
+type class @trait D extends B, C {
+}
+
+==> D is the same (ignoring subtyping) as:
+
+type class @trait D {
+  var integer a; // a is inherited via B and C, but only added once!
+  var integer b;
+  var integer c;
+}
+
+
+
+ + + + + + + + + + +
+ (0015470) +
+ Jacob Wieland - Spirent    +
+ 27-08-2019 12:03    +
+ 		+ + + + +
+ flattened B:
+
+type class @trait B {
+  var integer a; [from A]
+  var integer b; [from B]
+}
+
+flattened C:
+
+type class @trait C {
+  var integer a; [from A]
+  var integer c; [from C]
+}
+
+If we now add a class C2:
+
+type class @trait C2 {
+  var integer c;
+}
+
+then
+
+type class @trait D2 extends C, C2 {
+}
+
+would result in a flattened class:
+
+type class @trait D2 {
+  var integer a; [from A]
+  var integer c; [from C]
+  var integer c; [from C2]
+}
+
+which is illegal (it has c from C and C2)
+
+
+
+ + + + + + + + + + +
+ (0015477) +
+ Jacob Wieland - Spirent    +
+ 27-08-2019 14:50    +
+ 		+ + + + +
+ STF discussions: maybe not allow fields in trait classes
+
+
+
+ + + + + + + + + + +
+ (0015482) +
+ Jacob Wieland - Spirent    +
+ 28-08-2019 12:20    +
+ 		+ + + + +
+ I have uploaded a proposal.
+
+I have kept the possibility of fields (as the same problem already occurs with components and the same solution can be used).
+
+I also relaxed the parallel inheritance restriction somewhat insofar that if you inherit from one class A function A.f() and from another class you inherit B.f() which overrides A.f() (directly or indirectly) through extension, then this shall also be allowed.
+
+Consider the following rather typical scenario.
+
+type class @trait HasX {
+  function @abstract getX() return integer;
+}
+
+type class @abstract A extends HasX {
+  // implementation using getX()
+}
+
+type class @trait HasXImpl {
+  var integer x;
+  function getX() return integer {
+    return x;
+  }
+}
+
+type class AImpl extends A, HasXImpl {
+  // inherits only HasXImpl.getX() because it overrides HasX.getX()
+  create(integer x) {
+    this.x := x;
+  }
+}
+
+So, one version of an implementation can only 'win' over another if there is a clear overriding relationship between them (which can be established via topological sorting).
+
+
+
+ + + + + + + + + + +
+ (0015484) +
+ Kristóf Szabados    +
+ 28-08-2019 12:29    +
+ 		+ + + + +
+ Shouldn't HasXImpl extend HasX for this to work?
+Now they are just 2 classes that happen to have functions with the same name.
+
+
+
+ + + + + + + + + + +
+ (0015485) +
+ Jacob Wieland - Spirent    +
+ 28-08-2019 12:37    +
+ 		+ + + + +
+ Please review
+
+
+
+ + + + + + + + + + +
+ (0015487) +
+ Kristóf Szabados    +
+ 28-08-2019 13:32    +
+ 		+ + + + +
+ The wording is a bit strange now.
+in 5.1.1.0 the new J restriction sounds like saying no 2 (even unrelated) classes can have fields with the same name (the same extending class would have to extend both classes for this to be problem, even then it would not be a problem with the fields, but the extension).
+
+restriction k sounds like implying a direct extension tree.
+
+restriction m is saying that each class can be extended only once (which not be very useful)
+
+
+
+ + + + + + + + + + +
+ (0015488) +
+ Tomas Urban    +
+ 28-08-2019 13:53    +
+ 		+ + + + +
+ I made changes to the revisions j, k and m. Please review.
+
+
+
+ + + + + + + + + + +
+ (0015489) +
+ Kristóf Szabados    +
+ 28-08-2019 14:20    +
+ 		+ + + + +
+ Added a note on the not so obvious way of making a backward incompatible change, please check.
+
+The rest of the text is fine, but maybe we should sleep on it to see if we can come up with a wording, that is not suggesting multiple inheritance support this much.
+
+
+
+ + + + + + + + + + +
+ (0015490) +
+ Tomas Urban    +
+ 28-08-2019 14:40    +
+ 		+ + + + +
+ The note added by Kristof is fine. The proposal can be added to the specification, but since Kristof suggests postponing, I won't mark it as resolved yet.
+
+
+
+ + + + + + + + + + +
+ (0015565) +
+ Kristóf Szabados    +
+ 18-12-2019 07:41    +
+ 		+ + + + +
+ To me the current text still sounds very much like a normal multiple inheritance feature, which we aggreed to not have as a general guideline in the beginning.
+
+Ok it is cumbersome for a multiple-inheritance, since one has to write his own initializer functions, and create some "dummy" class on the top of the hierarchy to be able to instantiate it ... yet it still is multiple-inheritance.
+
+Or I might miss some part that forbids this kind of understanding and emphasizes flattening.
+
+
+
+ + + + + + + + + + +
+ (0015578) +
+ Jacob Wieland - Spirent    +
+ 18-12-2019 11:10    +
+ 		+ + + + +
+ Yes, it is multiple inheritence but much more restrictive than C++ multiple inheritance, avoiding diamond problems and clashing definitions.
+
+Also, the general guidelines in the beginning were (as far as I remember) meant for the first version of the OO feature where we explicitly kept the possibility of multiple inheritance open, so I don't understand why this is relevant for this additional OO feature.
+
+
+
+ + + + + + + + + + +
+ (0015580) +
+ Jens Grabowski    +
+ 18-12-2019 11:35    +
+ 		+ + + + +
+ STF discussion: It was agreed that some sort of multiple inheritance should be supported. The concrete implementation, e.g., interfaces or trait classes or something else, need to be discussed in 2020.
+
+
+
+ + + + + + + + + + +
+ (0015761) +
+ Jens Grabowski    +
+ 06-10-2020 13:54    +
+ 		+ + + + +
+ STF decision: Only JAVA-like interfaces without defaults.
+
+
+
+ + + + + + + + + + +
+ (0015774) +
+ Jacob Wieland - Spirent    +
+ 07-10-2020 12:27    +
+ 		+ + + + +
+ updated with the agreed-on restrictions, please review
+
+
+
+ + + + + + + + + + +
+ (0015780) +
+ Kristóf Szabados    +
+ 08-10-2020 13:28    +
+ 		+ + + + +
+ Some notes:
+1)
+"adding a new overriding function to an existing normal or trait class is semantically valid in its own context"
+What is the purpose of a trait class overriding a function of an other trait class?
+As neither can have bodies, this sounds questionable.
+
+2)
+Other than the previous question why would it be non-backward compatible if a normal class extends two independend trait classes, that are added new overriding functions?
+As these functions can not have bodies, and have the same signature, if this repetition/oberriding is allowed, it just repeats that the extending normal classes have to have a function with that signature.
+
+3)
+"type class C2 extends A, B2 { // legal, as it inherits only B2.f()"
+and
+"type class E extends A, C2 {
+  // legal, it does not inherit A.f() as this is overriden by C2.f()
+"
+It is actually not trivial. While I could agree it is not trivial why inheriting via 2 different inheritance trees of trait classes is allowed. As far as I understand the reason, is that both inheritance trees in the end define that there must be a function with that signature in the extending normal class, and none of the functions in the trait classes has bodies. As such it might be better to say, that it is legal since both traits being extended require the presence of a function with the exact same signature and there is no normal class extended.
+
+
+
+ + + + + + + + + + +
+ (0015784) +
+ Jacob Wieland - Spirent    +
+ 08-10-2020 15:50    +
+ 		+ + + + +
+ 1) is for future expansion of the trait concept, if both traits add the same function, this shall be a clash, so one needs to override the other.
+
+But, of course, we could remove that restriction for now, would also need to be done in the example.
+
+I don't understand question 2.
+
+3) is in essence also to avoid confusion, if you inherit two functions of the same name from different sources, you would have to check whether they have the same parameters. With this, you can only inherit it from one source, so the question of comparison side-by-side inherited things becomes moot.
+
+Again, we can also remove this, it will have to be re-added once we allow trait-members with bodies, though.
+
+
+
+ + + + + + + + + + +
+ (0015785) +
+ Jacob Wieland - Spirent    +
+ 08-10-2020 15:55    +
+ 		+ + + + +
+ Adding functions to traits is potentially non-backward compatible as it cannot be assured that all classes inheriting the trait directly or indirectly already implement that new function. Even if you implement it in all classes that are under your control, some other source can have used a class implementing the former version of the trait and not implement the new function. Thereby, you are potentially breaking the using code.
+
+Same is true for adding any members in any class (even private), as you can never know if a subclass already has a member of that name and thus would be broken by your change. This is normal, except for private members.
+
+
+
+ + + + + + + + + + +
+ (0015797) +
+ Jacob Wieland - Spirent    +
+ 07-12-2020 13:20    +
+ 		+ + + + +
+ I have removed the trait-related restrictions not necessary for only-interface-traits and changed the examples accordingly. Please review.
+
+
+
+ + + + + + + + + + +
+ (0015819) +
+ Tomas Urban    +
+ 09-12-2020 08:02    +
+ 		+ + + + +
+ It looks fine by me. It is quite restrictive at moment, but it is possible to add more complicated features (like non-abstract functions on the trait level) in the future.
+
+I have only two technical comments:
+1. Since the restrictions j and k were added in this proposal, I would not mark them as "Void", but remove completely so that we won't accidentally add them to the standard.
+2. The note for the restriction k should be moved to the semantic rules.
+
+Kristof, you revised the previous versions of the proposed changes. Could you please check this one as well?
+
+
+
+ + + + + + + + + + +
+ (0015828) +
+ Kristóf Szabados    +
+ 09-12-2020 19:16    +
+ 		+ + + + +
+ For the first point I have removed restriction j and k (that were changed to void.
+
+For the second point I have just removed the note as the situation described in it is not possible.
+The note said: ... "if they also extend an other (possibly independent) trait that also overrides the same function but with different formal parameters or return clause"
+
+This is not possible as section 5.1.1.7 declares:
+- "A method inherited from a superclass can be overridden by the subclass by redefining a function of the same name and with the same formal parameter list."
+- "The return type of an overriding function shall be the same as the return type of the overridden function with the same template restrictions and modifiers"
+
+
+
+ + + + + + + + + + +
+ (0015829) +
+ Kristóf Szabados    +
+ 09-12-2020 19:17    +
+ 		+ + + + +
+ Please check the new version.
+
+
+
+ + + + + + + + + + +
+ (0015832) +
+ Tomas Urban    +
+ 10-12-2020 07:33    +
+ 		+ + + + +
+ Well, I think that what Jacob meant is that developers have to be careful when adding new methods to classes and traits if these are extended in other projects that are not under their control. You are right that it would produce an error. However, it is true only if the developer can compile the whole code and that's not always the case.
+
+The question is if we need this kind of note or not. From my point of view, it is not necessary because (as Kristof pointed out) there are clear rules for parameters and return values of methods whose name is present on a superclass or supertrait level. Jacob, could you please comment the note issue? If you don't insist on having it, I think it is possible to resolve the CR.
+
+
+
+ + + + + + + + + + +
+ (0015839) +
+ Jens Grabowski    +
+ 10-12-2020 09:21    +
+ 		+ + + + +
+ STF discussion: Note should be added in a more prominent place. This CR is resolved with version 6 of the resolution.
+
+ + diff --git a/docs/mantis/CR7863.md b/docs/mantis/CR7863.md new file mode 100644 index 0000000000000000000000000000000000000000..286c3f2b71673ce01f43c24b4d0dc6625c45cc43 --- /dev/null +++ b/docs/mantis/CR7863.md @@ -0,0 +1,575 @@ + + + + + + + + + + + + + 0007863: libraries that could be added to OO - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Object-oriented features (ES 203 790)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007863Ext Pack: Object-oriented features (ES 203 790)[All Projects] Generalpublic26-08-2019 13:4909-01-2020 16:02
ReporterKristóf Szabados 
Assigned ToJens Grabowski 
PrioritynormalSeverityfeatureReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0007863: libraries that could be added to OO
DescriptionThis CR is a placeholder to collect ideas for libraries, that can be implemented with the new Object Oriented features and provided with the standard.
+
+For example collections like in Java.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR_7863.docx (153,941) 17-12-2019 08:57
http://oldforge.etsi.org/mantis/file_download.php?file_id=3880&type=bug
docx CR_7863_with_generics.docx (155,714) 17-12-2019 12:31
http://oldforge.etsi.org/mantis/file_download.php?file_id=3885&type=bug
docx CR_7863_v2.docx (163,142) 17-12-2019 20:07
http://oldforge.etsi.org/mantis/file_download.php?file_id=3888&type=bug
docx CR_7863_v3.docx (170,593) 18-12-2019 10:12
http://oldforge.etsi.org/mantis/file_download.php?file_id=3889&type=bug
docx CR_7863_v4.docx (170,486) 18-12-2019 11:47
http://oldforge.etsi.org/mantis/file_download.php?file_id=3893&type=bug
Issue History
Date ModifiedUsernameFieldChange
26-08-2019 13:49Kristóf SzabadosNew Issue
27-08-2019 09:02Kristóf SzabadosNote Added: 0015464
27-08-2019 09:28Kristóf SzabadosAssigned To => Kristóf Szabados
27-08-2019 09:28Kristóf SzabadosStatusnew => assigned
28-08-2019 12:25Kristóf SzabadosNote Added: 0015483
28-08-2019 13:17Kristóf SzabadosNote Added: 0015486
17-12-2019 08:57Kristóf SzabadosFile Added: CR_7863.docx
17-12-2019 08:58Kristóf SzabadosNote Added: 0015538
17-12-2019 09:09Kristóf SzabadosAssigned ToKristóf Szabados => Jacob Wieland - Spirent
17-12-2019 09:29Jacob Wieland - SpirentNote Added: 0015540
17-12-2019 10:09Jacob Wieland - SpirentNote Added: 0015542
17-12-2019 10:12Jacob Wieland - SpirentNote Added: 0015543
17-12-2019 12:29Kristóf SzabadosNote Added: 0015548
17-12-2019 12:29Kristóf SzabadosAssigned ToJacob Wieland - Spirent => Kristof.Szabados
17-12-2019 12:29Kristóf SzabadosAssigned ToKristof.Szabados => Kristóf Szabados
17-12-2019 12:31Jacob Wieland - SpirentFile Added: CR_7863_with_generics.docx
17-12-2019 12:32Jacob Wieland - SpirentNote Added: 0015550
17-12-2019 20:07Kristóf SzabadosFile Added: CR_7863_v2.docx
17-12-2019 20:08Kristóf SzabadosNote Added: 0015562
17-12-2019 20:09Kristóf SzabadosAssigned ToKristóf Szabados => Jacob Wieland - Spirent
17-12-2019 20:09Kristóf SzabadosStatusassigned => confirmed
18-12-2019 08:06Jacob Wieland - SpirentNote Added: 0015567
18-12-2019 08:13Kristóf SzabadosNote Added: 0015568
18-12-2019 10:12Jacob Wieland - SpirentFile Added: CR_7863_v3.docx
18-12-2019 10:13Jacob Wieland - SpirentStatusconfirmed => new
18-12-2019 10:13Jacob Wieland - SpirentNote Added: 0015572
18-12-2019 10:13Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Kristóf Szabados
18-12-2019 10:13Jacob Wieland - SpirentStatusnew => confirmed
18-12-2019 11:18Kristóf SzabadosAssigned ToKristóf Szabados => Tomas Urban
18-12-2019 11:18Kristóf SzabadosStatusconfirmed => assigned
18-12-2019 11:18Kristóf SzabadosNote Added: 0015579
18-12-2019 11:37Jens GrabowskiAssigned ToTomas Urban => Jacob Wieland - Spirent
18-12-2019 11:47Jacob Wieland - SpirentFile Added: CR_7863_v4.docx
18-12-2019 11:47Jacob Wieland - SpirentNote Added: 0015581
18-12-2019 11:48Jacob Wieland - SpirentStatusassigned => resolved
18-12-2019 11:48Jacob Wieland - SpirentResolutionopen => fixed
18-12-2019 11:48Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Jens Grabowski
09-01-2020 16:02Jens GrabowskiStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015464) +
+ Kristóf Szabados    +
+ 27-08-2019 09:02    +
+ 		+ + + + +
+ Data structures I have found to be used in products:
+- Queue (First-in First-out, linked)
+- Stack (Last-in First-out)
+- RingBuffer (fixed size list whose head indicator can move)
+- HashMap (buckets based)
+
+- Free-Busy Queue
+- Red-Black Tree
+
+
+
+ + + + + + + + + + +
+ (0015483) +
+ Kristóf Szabados    +
+ 28-08-2019 12:25    +
+ 		+ + + + +
+ Would it be useful to have some non-OO libraries, that demonstrate some general TTCN-3 usage, that can also be useful when writing tests?
+
+For example a "Math" module with functions like this:
+function f_MinI(in integer i1, in integer i2) return integer {
+  if( i1 <= i2) {
+    return i1;
+  } else {
+    return i2;
+  }
+}
+
+
+
+ + + + + + + + + + +
+ (0015486) +
+ Kristóf Szabados    +
+ 28-08-2019 13:17    +
+ 		+ + + + +
+ STF discussion: we should provide only module with abstract classes. The semantics should be described in both the module and the standard.
+These classes should become an annex to the Object-Oriented extension.
+
+
+
+ + + + + + + + + + +
+ (0015538) +
+ Kristóf Szabados    +
+ 17-12-2019 08:58    +
+ 		+ + + + +
+ First version uploaded to start discussion.
+
+
+
+ + + + + + + + + + +
+ (0015540) +
+ Jacob Wieland - Spirent    +
+ 17-12-2019 09:29    +
+ 		+ + + + +
+ - there should be a Set class
+- for use together with Advanced Parameterization, there should be a generic version using type parameters (HashMap<Key, Value>)
+- collection types should have iterators (at least for lists, sets and maps this is often used)
+- maybe we could also add PriorityQueue (a queue where elements are inserted depending on their order)
+
+
+
+ + + + + + + + + + +
+ (0015542) +
+ Jacob Wieland - Spirent    +
+ 17-12-2019 10:09    +
+ 		+ + + + +
+ - the ring buffer should have a function which yields its capacity so that one does not accidentally write over the size limit
+
+
+
+ + + + + + + + + + +
+ (0015543) +
+ Jacob Wieland - Spirent    +
+ 17-12-2019 10:12    +
+ 		+ + + + +
+ - the raised exceptions should be derived from an abstract exception type class so that subclasses can raise specializations of that type
+
+
+
+ + + + + + + + + + +
+ (0015548) +
+ Kristóf Szabados    +
+ 17-12-2019 12:29    +
+ 		+ + + + +
+ STF discussion: instead of charstring exception lets raise a generic exception of class Exception. Later this can be refined to a list of more specific exceptions.
+
+
+
+ + + + + + + + + + +
+ (0015550) +
+ Jacob Wieland - Spirent    +
+ 17-12-2019 12:32    +
+ 		+ + + + +
+ added a document containing the generic version of the library
+
+
+
+ + + + + + + + + + +
+ (0015562) +
+ Kristóf Szabados    +
+ 17-12-2019 20:08    +
+ 		+ + + + +
+ Added set and priorityqueue, iterators.
+
+question: should we use a naming convention of abstractSomething for abstract classes?
+
+
+
+ + + + + + + + + + +
+ (0015567) +
+ Jacob Wieland - Spirent    +
+ 18-12-2019 08:06    +
+ 		+ + + + +
+ I don't think that such naming conventions help the readability of the using code, especially if those names are the ones most commonly used. The names they have should reflect the concepts they embody.
+
+
+
+ + + + + + + + + + +
+ (0015568) +
+ Kristóf Szabados    +
+ 18-12-2019 08:13    +
+ 		+ + + + +
+ For the "generics" version ... I don't think the current way of parameterisation is suitable here.
+
+1)
+In the current way, one can only semantically check a construct once it is used with an actual parameter.
+This would mean, that it is not possible to ensure that libraries are safe, without trying for all possible types.
+
+2)
+As each actual instance (with for example an actual type parameter) has to be checked, that would lead to an explosion in semantic checking duration.
+Just think of not checking the hashmap only once, but once for each and every time it is instantiated (maybe even used)
+
+3)
+To solve the above problems, we would need some kind of type-erasure logic ... which does not yet exists in the advanced parameterisation.
+Or concepts (with which C++ has been strugling in the last few decades)
+
+
+
+ + + + + + + + + + +
+ (0015572) +
+ Jacob Wieland - Spirent    +
+ 18-12-2019 10:13    +
+ 		+ + + + +
+ added updated version, please review
+
+
+
+ + + + + + + + + + +
+ (0015579) +
+ Kristóf Szabados    +
+ 18-12-2019 11:18    +
+ 		+ + + + +
+ looks fine for me, please check.
+
+
+
+ + + + + + + + + + +
+ (0015581) +
+ Jacob Wieland - Spirent    +
+ 18-12-2019 11:47    +
+ 		+ + + + +
+ uploaded a version that only uses single inheritance
+
+ + diff --git a/docs/mantis/CR7864.md b/docs/mantis/CR7864.md new file mode 100644 index 0000000000000000000000000000000000000000..63a73c4404eb208a3d354070aaa3acb6f83021b7 --- /dev/null +++ b/docs/mantis/CR7864.md @@ -0,0 +1,164 @@ + + + + + + + + + + + + + 0007864: Allow overloading for object methods. - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Object-oriented features (ES 203 790)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007864Ext Pack: Object-oriented features (ES 203 790)[All Projects] Generalpublic26-08-2019 14:2814-08-2020 11:15
ReporterJacob Wieland - Spirent 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionwon't fix 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0007864: Allow overloading for object methods.
DescriptionSince most object-oriented languages allow at least parameter-side overloading of methods (i.e. methods of the same name with different parameter lists in the same class), this should be allowed in some fashion also for TTCN-3 classes.
+
+To allow this, it needs to be possible to distinguish which version of the invoked overloaded method is to be called statically by analyzing the given actual parameters or to report that the invocation is ambiguous as at least two versions both match the actual parameter list.
+
+To make two overloaded versions of a function of the same name distinguishable, one of the following criteria must be fulfilled:
+- the set of mandatory formal parameter names of one version shall not be contained in the set of formal parameter names of the other version
+- otherwise, for at least one mandatory parameter of one version the type of that parameter must be incompatible with the type of the formal parameter of the same name in the other version.
+- otherwise, for at least one mandatory formal parameter of the version with the lesser number of formal parameters, the type of the formal parameter is incompatible with the type of the formal parameter at the same position in the other version.
+
+This criterion is chosen to be robust against the later addition of new optional parameters. In the worst case, adding a new parameter to one version of an overloaded function shall render the calls of the other version ambiguous, but it shall not change their semantics to calls of the changed version.
+
+I have also chosen the restrictions in such a way that in future versions, adding some less restrictive overloading that allows best-type-match overload-resolution as it is done in other object-oriented languages should still be possible.
+
+EXAMPLE:
+
+type class external StringBuilder {
+  // overloading by using different parameter names:
+  function append(charstring p_charstring) return StringBuilder;
+  function append(universal charstring p_ucharstring) return StringBuilder;
+  // overloading by using incompatible types for
+  // the same parameter name/position
+  function append(integer p_num) return StringBuilder;
+  function append(float p_num) return StringBuilder;
+}
+
+var StringBuilder sb := StringBuilder.create();
+sb.append("foobar"); // ambiguous, can't be distinguished by type
+sb.append(p_charstring := "foobar"); // unambiguous by name
+sb.append(3); // unambiguous by type, can't be distinguished by parameter name
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
26-08-2019 14:28Jacob Wieland - SpirentNew Issue
27-08-2019 08:34Kristóf SzabadosNote Added: 0015463
27-08-2019 15:05Jacob Wieland - SpirentNote Added: 0015478
27-08-2019 15:05Jacob Wieland - SpirentAssigned To => Jens Grabowski
27-08-2019 15:05Jacob Wieland - SpirentStatusnew => assigned
14-08-2020 11:15Jens GrabowskiNote Added: 0015749
14-08-2020 11:15Jens GrabowskiStatusassigned => closed
14-08-2020 11:15Jens GrabowskiResolutionopen => won't fix
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015463) +
+ Kristóf Szabados    +
+ 27-08-2019 08:34    +
+ 		+ + + + +
+ please note that, just beacuse something is done by others it does not mean we also need to do the same.
+
+It is important to note, that overloading can always leed to confusion (as of using the same name), that will make it more costly to develop and maintain.
+Please keep in mind that this will also make checking the code slower, since you will no longer be able to assume there is only one function with a name.
+
+
+
+ + + + + + + + + + +
+ (0015478) +
+ Jacob Wieland - Spirent    +
+ 27-08-2019 15:05    +
+ 		+ + + + +
+ STF-discussion: we mostly agree with the above observations.
+
+So, we will not implement it for now.
+
+
+
+ + + + + + + + + + +
+ (0015749) +
+ Jens Grabowski    +
+ 14-08-2020 11:15    +
+ 		+ + + + +
+ The discussion on this proposal will not be continued.
+
+ + diff --git a/docs/mantis/CR7865.md b/docs/mantis/CR7865.md new file mode 100644 index 0000000000000000000000000000000000000000..95f5b36b4c8c020bec0d549537b37133ff45c850 --- /dev/null +++ b/docs/mantis/CR7865.md @@ -0,0 +1,170 @@ + + + + + + + + + + + + + 0007865: the text for union alternatives can be easily missunderstood to support omit being assigned to alternatives - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007865Part 01: TTCN-3 Core LanguageEditorialpublic26-08-2019 14:5328-12-2019 17:12
ReporterKristóf Szabados 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version4.12.1 (published 2020-05) 
Clause Reference(s)15.6.5
Source (company - Author)     TestCom ou
Summary0007865: the text for union alternatives can be easily missunderstood to support omit being assigned to alternatives
Descriptionin section 15.6.5 "Referencing union alternatives" the description can easily be read as if assigning omit to a template union alternative would be supported.
+
+Somewhat like this: referencing an alternative of a union (template or template field) to which Omit, AnyValueOrNone, a template list or a complemented list is assigned, at the right hand side of an assignment, shall cause an error.
+// I inserted () to emphasize to part in question.
+
+We should add one example that clearly shows that this is not the case (especially as unions have alternatives not fields)
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR_7865.docx (160,625) 27-08-2019 10:31
http://oldforge.etsi.org/mantis/file_download.php?file_id=3858&type=bug
docx CR7865-2.docx (181,714) 28-08-2019 08:26
http://oldforge.etsi.org/mantis/file_download.php?file_id=3861&type=bug
Issue History
Date ModifiedUsernameFieldChange
26-08-2019 14:53Kristóf SzabadosNew Issue
26-08-2019 14:55Kristóf SzabadosNote Added: 0015459
27-08-2019 09:03Kristóf SzabadosAssigned To => Kristóf Szabados
27-08-2019 09:03Kristóf SzabadosStatusnew => assigned
27-08-2019 10:31Kristóf SzabadosFile Added: CR_7865.docx
27-08-2019 12:27Kristóf SzabadosNote Added: 0015472
27-08-2019 12:27Kristóf SzabadosAssigned ToKristóf Szabados => Tomas Urban
27-08-2019 12:27Kristóf SzabadosStatusassigned => confirmed
28-08-2019 08:26Tomas UrbanFile Added: CR7865-2.docx
28-08-2019 08:29Tomas UrbanNote Added: 0015481
28-08-2019 08:29Tomas UrbanStatusconfirmed => resolved
28-08-2019 08:29Tomas UrbanResolutionopen => fixed
28-08-2019 13:54Tomas UrbanStatusresolved => feedback
28-08-2019 13:54Tomas UrbanResolutionfixed => reopened
28-08-2019 13:55Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
28-08-2019 13:55Tomas UrbanStatusfeedback => resolved
28-08-2019 13:55Tomas UrbanResolutionreopened => fixed
28-12-2019 17:12Gyorgy RethyNote Added: 0015599
28-12-2019 17:12Gyorgy RethyStatusresolved => closed
28-12-2019 17:12Gyorgy RethyFixed in Version => 4.12.1 (published 2020-05)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015459) +
+ Kristóf Szabados    +
+ 26-08-2019 14:55    +
+ 		+ + + + +
+ also the omit in example a in "v_t1.g2 := omit; " should be bold.
+
+
+
+ + + + + + + + + + +
+ (0015472) +
+ Kristóf Szabados    +
+ 27-08-2019 12:27    +
+ 		+ + + + +
+ please check
+
+
+
+ + + + + + + + + + +
+ (0015481) +
+ Tomas Urban    +
+ 28-08-2019 08:29    +
+ 		+ + + + +
+ The resolution is correct, I only made some cosmetic changes. It can be added to the next version of the core language standard.
+
+
+
+ + + + + + + + + + +
+ (0015599) +
+ Gyorgy Rethy    +
+ 28-12-2019 17:12    +
+ 		+ + + + +
+ Included to final draft V4.11.2
+
+ + diff --git a/docs/mantis/CR7866.md b/docs/mantis/CR7866.md new file mode 100644 index 0000000000000000000000000000000000000000..1de74ac0405a183b0f7e7f61d3977c182c64ef46 --- /dev/null +++ b/docs/mantis/CR7866.md @@ -0,0 +1,384 @@ + + + + + + + + + + + + + 0007866: Allow nested classes - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Object-oriented features (ES 203 790)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007866Ext Pack: Object-oriented features (ES 203 790)[All Projects] Generalpublic26-08-2019 14:5709-01-2020 16:03
ReporterJacob Wieland - Spirent 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0007866: Allow nested classes
DescriptionAs it is often more convenient for some implementations, TTCN-3 should allow the definition of nested classes.
+
+A nested class is a class defined inside another class body with access to the containing class's protected and public members.
+
+A nested class shall not define (neither directly nor through inheritance from superclasses) a member with the same name as one of the members of the outer class or its runs on type. If no runs on type is given to the inner class, it inherits it from the outer class. However, it may declare a runs on type which is runs-on compatible with the one from the outer class.
+
+EXAMPLE:
+
+type record of charstring Strings;
+
+type class @abstract StringIterator {
+  function @abstract hasNext() return boolean;
+  function @abstract next() return charstring;
+}
+
+
+type class StringList {
+  var Strings v_strings;
+  
+  type class Iterator extends StringIterator {
+     var integer v_pos := 0;
+     
+     public function hasNext() return boolean {
+       return v_pos < lengthof(v_strings);
+     }
+
+     public function next() return charstring {
+       v_pos := v_pos + 1;
+       return v_strings[v_pos-1];
+     }
+  }
+
+  function iterator() return Iterator {
+    return Iterator.create();
+  }
+}
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7866.docx (136,387) 17-12-2019 08:31
http://oldforge.etsi.org/mantis/file_download.php?file_id=3878&type=bug
docx CR7866-2.docx (154,353) 17-12-2019 10:25
http://oldforge.etsi.org/mantis/file_download.php?file_id=3882&type=bug
docx CR7866-3.docx (154,411) 17-12-2019 14:26
http://oldforge.etsi.org/mantis/file_download.php?file_id=3887&type=bug
Issue History
Date ModifiedUsernameFieldChange
26-08-2019 14:57Jacob Wieland - SpirentNew Issue
27-08-2019 13:39Jacob Wieland - SpirentNote Added: 0015474
27-08-2019 13:39Jacob Wieland - SpirentAssigned To => Jacob Wieland - Spirent
27-08-2019 13:39Jacob Wieland - SpirentStatusnew => assigned
17-12-2019 08:31Jacob Wieland - SpirentFile Added: CR7866.docx
17-12-2019 08:32Jacob Wieland - SpirentNote Added: 0015533
17-12-2019 08:32Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Tomas Urban
17-12-2019 08:32Jacob Wieland - SpirentStatusassigned => confirmed
17-12-2019 10:25Tomas UrbanFile Added: CR7866-2.docx
17-12-2019 10:26Tomas UrbanNote Added: 0015544
17-12-2019 10:26Tomas UrbanAssigned ToTomas Urban => Jacob Wieland - Spirent
17-12-2019 12:44Kristóf SzabadosNote Added: 0015553
17-12-2019 13:28Jacob Wieland - SpirentNote Added: 0015554
17-12-2019 13:29Jacob Wieland - SpirentStatusconfirmed => assigned
17-12-2019 13:29Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Kristóf Szabados
17-12-2019 13:29Jacob Wieland - SpirentStatusassigned => confirmed
17-12-2019 13:36Jacob Wieland - SpirentAssigned ToKristóf Szabados => Tomas Urban
17-12-2019 13:36Jacob Wieland - SpirentStatusconfirmed => assigned
17-12-2019 14:06Kristóf SzabadosNote Added: 0015557
17-12-2019 14:26Tomas UrbanFile Added: CR7866-3.docx
17-12-2019 14:28Tomas UrbanNote Added: 0015561
17-12-2019 14:28Tomas UrbanAssigned ToTomas Urban => Kristóf Szabados
17-12-2019 14:28Tomas UrbanStatusassigned => confirmed
18-12-2019 07:10Kristóf SzabadosAssigned ToKristóf Szabados => Jacob Wieland - Spirent
18-12-2019 07:10Kristóf SzabadosStatusconfirmed => assigned
18-12-2019 07:10Kristóf SzabadosNote Added: 0015563
18-12-2019 07:58Jacob Wieland - SpirentNote Added: 0015566
18-12-2019 07:58Jacob Wieland - SpirentStatusassigned => resolved
18-12-2019 07:58Jacob Wieland - SpirentResolutionopen => fixed
18-12-2019 07:58Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Jens Grabowski
09-01-2020 16:03Jens GrabowskiStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015474) +
+ Jacob Wieland - Spirent    +
+ 27-08-2019 13:39    +
+ 		+ + + + +
+ Inner class type : StringList.Iterator
+
+instantiating inner class from outside:
+
+var StringList v_list := StringList.create();
+...
+var StringList.Iterator v_iterator := v_list.Iterator.create();
+
+
+
+ + + + + + + + + + +
+ (0015533) +
+ Jacob Wieland - Spirent    +
+ 17-12-2019 08:32    +
+ 		+ + + + +
+ please review proposal
+
+
+
+ + + + + + + + + + +
+ (0015544) +
+ Tomas Urban    +
+ 17-12-2019 10:26    +
+ 		+ + + + +
+ I made some minor corrections to the text. Please review the corrections and if you are fine with them, the CR can be marked as resolved.
+
+
+
+ + + + + + + + + + +
+ (0015553) +
+ Kristóf Szabados    +
+ 17-12-2019 12:44    +
+ 		+ + + + +
+ Do I understand correctly right now it is possible to instantiate an object of the nested class, with no object of the containing class?
+In which case using member fields of the containing class, does not have any meaning.
+
+
+
+ + + + + + + + + + +
+ (0015554) +
+ Jacob Wieland - Spirent    +
+ 17-12-2019 13:28    +
+ 		+ + + + +
+ No, there is restriction b) which disallows this:
+
+b) Referencing the name of a nested class in a null reference via dotted notation shall cause an error.
+
+How else would you instantiate the object from outside? And if you are inside, the object is 'this'
+
+
+
+ + + + + + + + + + +
+ (0015557) +
+ Kristóf Szabados    +
+ 17-12-2019 14:06    +
+ 		+ + + + +
+ Technically there is no object involved according to the current text, so there can be no null reference:
+"The constructor of a nested class may be invoked on a reference composed of the containing and nested class identifier separated by a dot"
+
+In my understanding this talks about class names, not object instances, and class names can not be null ... so the restriction in this setup is not sensible and it is only possible to instantiate a nested class without an object of the containing class.
+
+
+
+ + + + + + + + + + +
+ (0015561) +
+ Tomas Urban    +
+ 17-12-2019 14:28    +
+ 		+ + + + +
+ New resolution uploaded, please review.
+
+
+
+ + + + + + + + + + +
+ (0015563) +
+ Kristóf Szabados    +
+ 18-12-2019 07:10    +
+ 		+ + + + +
+ Looks fine for me, please review.
+
+
+
+ + + + + + + + + + +
+ (0015566) +
+ Jacob Wieland - Spirent    +
+ 18-12-2019 07:58    +
+ 		+ + + + +
+ resolved
+
+ + diff --git a/docs/mantis/CR7867.md b/docs/mantis/CR7867.md new file mode 100644 index 0000000000000000000000000000000000000000..9d8f2ce447ada3715d99c1d3b336f15a0bccab7b --- /dev/null +++ b/docs/mantis/CR7867.md @@ -0,0 +1,173 @@ + + + + + + + + + + + + + 0007867: the ispresent, ischosen, isvalue, isbound predefined functions should be moved to operations. - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007867Part 01: TTCN-3 Core LanguageTechnicalpublic26-08-2019 15:1828-12-2019 16:35
ReporterKristóf Szabados 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version4.12.1 (published 2020-05) 
Clause Reference(s)C.3
Source (company - Author)Testcom ou
Summary0007867: the ispresent, ischosen, isvalue, isbound predefined functions should be moved to operations.
DescriptionCurrently the ispresent, ischose, isbound, isvalue are described in the core standard as predefined functions, in section C.3
+
+But actually they work much more like operators/operations.
+As they process their parameters differently (to be very robust).
+
+Describing them as operators (and moving them there):
+- would be better from consistency point of view.
+- if done correctly should also not create any backward compatible issues.
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0007455closed Gyorgy Rethy The type of formal in parameters of external functions should be allowed to be 'any' 
Attached Filesdocx CR7867-1.docx (376,890) 27-08-2019 13:23
http://oldforge.etsi.org/mantis/file_download.php?file_id=3860&type=bug
docx CR7867-2.docx (305,322) 16-12-2019 13:19
http://oldforge.etsi.org/mantis/file_download.php?file_id=3871&type=bug
docx CR7867-3.docx (305,800) 16-12-2019 17:39
http://oldforge.etsi.org/mantis/file_download.php?file_id=3877&type=bug
Issue History
Date ModifiedUsernameFieldChange
26-08-2019 15:18Kristóf SzabadosNew Issue
26-08-2019 15:19Kristóf SzabadosRelationship addedrelated to 0007455
27-08-2019 08:16Tomas UrbanAssigned To => Tomas Urban
27-08-2019 08:16Tomas UrbanStatusnew => assigned
27-08-2019 13:23Tomas UrbanFile Added: CR7867-1.docx
27-08-2019 13:28Tomas UrbanNote Added: 0015473
27-08-2019 13:28Tomas UrbanAssigned ToTomas Urban => Jacob Wieland - Spirent
27-08-2019 13:28Tomas UrbanStatusassigned => confirmed
16-12-2019 13:19Jacob Wieland - SpirentFile Added: CR7867-2.docx
16-12-2019 13:20Jacob Wieland - SpirentNote Added: 0015522
16-12-2019 13:21Jacob Wieland - SpirentStatusconfirmed => resolved
16-12-2019 13:21Jacob Wieland - SpirentFixed in Version => 4.11.1 (published 2019-05)
16-12-2019 13:21Jacob Wieland - SpirentResolutionopen => fixed
16-12-2019 13:21Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Jens Grabowski
16-12-2019 17:39Kristóf SzabadosFile Added: CR7867-3.docx
16-12-2019 17:39Kristóf SzabadosNote Added: 0015530
28-12-2019 16:02Gyorgy RethyAssigned ToJens Grabowski => Gyorgy Rethy
28-12-2019 16:35Gyorgy RethyNote Added: 0015592
28-12-2019 16:35Gyorgy RethyStatusresolved => closed
28-12-2019 16:35Gyorgy RethyFixed in Version4.11.1 (published 2019-05) => 4.12.1 (published 2020-05)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015473) +
+ Tomas Urban    +
+ 27-08-2019 13:28    +
+ 		+ + + + +
+ Resolution uploaded. Text of the new operators is mostly a copy of the original text of the original predefined functions. Special attention should be paid to the section 7.1.8.0, which contains updated rules on special error handling for references. The rule is now common for all presence checking operators. Please check.
+
+
+
+ + + + + + + + + + +
+ (0015522) +
+ Jacob Wieland - Spirent    +
+ 16-12-2019 13:20    +
+ 		+ + + + +
+ Changed an Ispresent to ispresent and deleted superfluous NOTE saying basically the same thing as the preceding paragraph.
+
+
+
+ + + + + + + + + + +
+ (0015530) +
+ Kristóf Szabados    +
+ 16-12-2019 17:39    +
+ 		+ + + + +
+ removed the empty lines from table 15.
+
+
+
+ + + + + + + + + + +
+ (0015592) +
+ Gyorgy Rethy    +
+ 28-12-2019 16:35    +
+ 		+ + + + +
+ Included to final draft V4.11.2.
+
+ + diff --git a/docs/mantis/CR7868.md b/docs/mantis/CR7868.md new file mode 100644 index 0000000000000000000000000000000000000000..0d1ea9ecbbf686319ee866803dbfed7046526659 --- /dev/null +++ b/docs/mantis/CR7868.md @@ -0,0 +1,375 @@ + + + + + + + + + + + + + 0007868: External classes should be allowed internal members (direct and inherited) - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Object-oriented features (ES 203 790)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007868Ext Pack: Object-oriented features (ES 203 790)[All Projects] Generalpublic26-08-2019 15:2909-01-2020 16:03
ReporterJacob Wieland - Spirent 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0007868: External classes should be allowed internal members (direct and inherited)
DescriptionAn external class at the moment is not allowed any internal members.
+
+But, sometimes a default implementation based on the external functions (and possibly using some additional internal state) would be useful. At the moment, this implementation needs to be added for every internal class extending the same external class.
+
+As this restriction does not really add anything useful and just forces duplication of code, it should be removed.
+
+All classes marked as @external and their subclasses may add functions without bodies. These functions are implicitly external methods. Abstract methods in external classes which are also marked @abstract shall be marked @abstract (to distinguish them from the external methods). Abstract methods can also be implemented by external methods.
+
+EXAMPLE:
+
+type component Counter {
+  var integer v_counter := 0;
+}
+
+function nextCounter() runs on Counter return integer {
+  v_counter := v_counter + 1;
+  return v_counter;
+}
+
+type class @abstract MyObject runs on Counter {
+  const integer id;
+  create() {
+    this.id := nextCounter();
+  }
+
+  public function @abstract getName() return charstring;
+  
+  public function getId() return integer {
+    return id;
+  }
+
+  public function toString() return charstring {
+    return getName() & int2str(id);
+  }
+ 
+}
+
+type class external MyExternalObject extens MyObject {
+  function getName() return charstring;
+}
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0007856closed Jens Grabowski Implicit constructor shall only provide parameters for non-var fields without initializer 
related to 0007830closed Jens Grabowski Clarification request for OO features (order or member initializer and constructor) 
Attached Filesdocx CR7868.docx (156,261) 28-08-2019 15:17
http://oldforge.etsi.org/mantis/file_download.php?file_id=3865&type=bug
docx CR7868-2.docx (177,833) 16-12-2019 11:41
http://oldforge.etsi.org/mantis/file_download.php?file_id=3867&type=bug
docx CR7868-3.docx (156,299) 16-12-2019 17:23
http://oldforge.etsi.org/mantis/file_download.php?file_id=3876&type=bug
docx CR7868-4.docx (186,802) 18-12-2019 10:17
http://oldforge.etsi.org/mantis/file_download.php?file_id=3890&type=bug
docx CR7868-5.docx (160,510) 18-12-2019 11:02
http://oldforge.etsi.org/mantis/file_download.php?file_id=3892&type=bug
Issue History
Date ModifiedUsernameFieldChange
26-08-2019 15:29Jacob Wieland - SpirentNew Issue
27-08-2019 09:35Kristóf SzabadosNote Added: 0015465
27-08-2019 14:31Jacob Wieland - SpirentNote Added: 0015476
27-08-2019 14:31Jacob Wieland - SpirentAssigned To => Jacob Wieland - Spirent
27-08-2019 14:31Jacob Wieland - SpirentStatusnew => assigned
28-08-2019 08:19Kristóf SzabadosNote Added: 0015479
28-08-2019 15:17Jacob Wieland - SpirentFile Added: CR7868.docx
28-08-2019 15:17Jacob Wieland - SpirentNote Added: 0015491
28-08-2019 15:17Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Tomas Urban
28-08-2019 15:17Jacob Wieland - SpirentStatusassigned => confirmed
16-12-2019 11:41Tomas UrbanFile Added: CR7868-2.docx
16-12-2019 11:44Tomas UrbanNote Added: 0015519
16-12-2019 11:44Tomas UrbanStatusconfirmed => resolved
16-12-2019 11:44Tomas UrbanResolutionopen => fixed
16-12-2019 11:44Tomas UrbanAssigned ToTomas Urban => Jens Grabowski
16-12-2019 17:23Kristóf SzabadosFile Added: CR7868-3.docx
16-12-2019 17:23Kristóf SzabadosNote Added: 0015529
18-12-2019 09:25Jens GrabowskiAssigned ToJens Grabowski => Tomas Urban
18-12-2019 09:25Jens GrabowskiStatusresolved => assigned
18-12-2019 09:26Jens GrabowskiNote Added: 0015569
18-12-2019 09:27Tomas UrbanRelationship addedrelated to 0007856
18-12-2019 09:27Tomas UrbanRelationship addedrelated to 0007830
18-12-2019 10:17Tomas UrbanFile Added: CR7868-4.docx
18-12-2019 10:19Tomas UrbanNote Added: 0015573
18-12-2019 10:19Tomas UrbanAssigned ToTomas Urban => Jacob Wieland - Spirent
18-12-2019 10:19Tomas UrbanStatusassigned => confirmed
18-12-2019 11:02Jacob Wieland - SpirentFile Added: CR7868-5.docx
18-12-2019 11:03Jacob Wieland - SpirentNote Added: 0015577
18-12-2019 11:03Jacob Wieland - SpirentStatusconfirmed => resolved
18-12-2019 11:03Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Jens Grabowski
09-01-2020 16:03Jens GrabowskiStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015465) +
+ Kristóf Szabados    +
+ 27-08-2019 09:35    +
+ 		+ + + + +
+ please note, that external classes can currently not derive from non-external classes (in your example).
+
+
+
+ + + + + + + + + + +
+ (0015476) +
+ Jacob Wieland - Spirent    +
+ 27-08-2019 14:31    +
+ 		+ + + + +
+ STF-discussions: allow mixing of internal members and external members in external classes and also allow deriving external classes from non classes with internal implementation parts.
+
+
+
+ + + + + + + + + + +
+ (0015479) +
+ Kristóf Szabados    +
+ 28-08-2019 08:19    +
+ 		+ + + + +
+ "allow deriving external classes from non classes" was actually "allow deriving external classes from non external classes"
+
+
+
+ + + + + + + + + + +
+ (0015491) +
+ Jacob Wieland - Spirent    +
+ 28-08-2019 15:17    +
+ 		+ + + + +
+ please review
+
+
+
+ + + + + + + + + + +
+ (0015519) +
+ Tomas Urban    +
+ 16-12-2019 11:44    +
+ 		+ + + + +
+ I made one simple correction, otherwise the CR is fine and resolves the raised issue. It can be added to the next version of the specification.
+
+
+
+ + + + + + + + + + +
+ (0015529) +
+ Kristóf Szabados    +
+ 16-12-2019 17:23    +
+ 		+ + + + +
+ minor typo fix.
+"Es the underlying external constructor " -> "As the underlying external constructor "
+
+
+
+ + + + + + + + + + +
+ (0015569) +
+ Jens Grabowski    +
+ 18-12-2019 09:26    +
+ 		+ + + + +
+ conflicts with 7856, 7830
+
+
+
+ + + + + + + + + + +
+ (0015573) +
+ Tomas Urban    +
+ 18-12-2019 10:19    +
+ 		+ + + + +
+ Merged with changes from 0007856 and 0007830. Please review the merged document.
+
+
+
+ + + + + + + + + + +
+ (0015577) +
+ Jacob Wieland - Spirent    +
+ 18-12-2019 11:03    +
+ 		+ + + + +
+ Changed an are back to an is but otherwise, it seems fine to me.
+
+ + diff --git a/docs/mantis/CR7869.md b/docs/mantis/CR7869.md new file mode 100644 index 0000000000000000000000000000000000000000..ac86cd044014a9c3c35dac045e5cad71721e90ed --- /dev/null +++ b/docs/mantis/CR7869.md @@ -0,0 +1,136 @@ + + + + + + + + + + + + + 0007869: unfortunate wording - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007869Part 01: TTCN-3 Core LanguageEditorialpublic27-08-2019 10:5328-12-2019 17:15
ReporterKristóf Szabados 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version4.11.1 (published 2019-05) 
Target VersionFixed in Version4.12.1 (published 2020-05) 
Clause Reference(s)6.2.10.1
Source (company - Author)Testcom ou
Summary0007869: unfortunate wording
Descriptionsection 6.2.10.1 has the following sentence:
+"Every instance of a component type has its own fresh copy of the port, constant, variable, template and timer instances defined in the component type definition."
+
+Using the word "copy" is unfortunate here as it might misslead the readers to think something is copied.
+
+Instead we should have something like "Every instance of a component type has its own new instances of the ports, constants, variables, templates and timers defined in the component type definition."
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR_7869.docx (165,490) 27-08-2019 12:26
http://oldforge.etsi.org/mantis/file_download.php?file_id=3859&type=bug
Issue History
Date ModifiedUsernameFieldChange
27-08-2019 10:53Kristóf SzabadosNew Issue
27-08-2019 12:26Kristóf SzabadosFile Added: CR_7869.docx
27-08-2019 12:26Kristóf SzabadosAssigned To => Kristóf Szabados
27-08-2019 12:26Kristóf SzabadosStatusnew => assigned
27-08-2019 12:26Kristóf SzabadosNote Added: 0015471
27-08-2019 12:26Kristóf SzabadosAssigned ToKristóf Szabados => Tomas Urban
27-08-2019 12:26Kristóf SzabadosStatusassigned => confirmed
28-08-2019 08:22Tomas UrbanNote Added: 0015480
28-08-2019 08:22Tomas UrbanStatusconfirmed => resolved
28-08-2019 08:22Tomas UrbanResolutionopen => fixed
28-08-2019 08:22Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
28-12-2019 17:15Gyorgy RethyNote Added: 0015600
28-12-2019 17:15Gyorgy RethyStatusresolved => closed
28-12-2019 17:15Gyorgy RethyFixed in Version => 4.12.1 (published 2020-05)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015471) +
+ Kristóf Szabados    +
+ 27-08-2019 12:26    +
+ 		+ + + + +
+ please check
+
+
+
+ + + + + + + + + + +
+ (0015480) +
+ Tomas Urban    +
+ 28-08-2019 08:22    +
+ 		+ + + + +
+ No issues found in the resolution. It can be added to the next version of the core language standard.
+
+
+
+ + + + + + + + + + +
+ (0015600) +
+ Gyorgy Rethy    +
+ 28-12-2019 17:15    +
+ 		+ + + + +
+ Corrected in final draft V4.11.2.
+
+ + diff --git a/docs/mantis/CR7870.md b/docs/mantis/CR7870.md new file mode 100644 index 0000000000000000000000000000000000000000..a05d561da9eab5aabb108d1172e72d73cf5af6c9 --- /dev/null +++ b/docs/mantis/CR7870.md @@ -0,0 +1,638 @@ + + + + + + + + + + + + + 0007870: Allow definition of class properties - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Object-oriented features (ES 203 790)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007870Ext Pack: Object-oriented features (ES 203 790)[All Projects] Generalpublic27-08-2019 11:4828-12-2020 12:21
ReporterJacob Wieland - Spirent 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product VersionV1.2.1 (published 2020-05) 
Target VersionV1.3.1 (ongoing)Fixed in Version 
Summary0007870: Allow definition of class properties
DescriptionA class property is a class member which is referenced like a record field for reading and writing with the dotted notation, but implemented via getter and setter functions that are provided in the definition of the property (allowing value checking/normalization/conversion when setting a value and on-the-fly computation when getting the value).
+
+In C#, this looks like this:
+
+[<visibility>] <type> <identifier> {
+  [<getter>]
+  [<setter>]
+} [= <initial_value>];
+
+<getter> and <setter> have different possible syntaxes:
+
+- [<visibility>] get { <body_returning value> }
+- [<visibility>] set { <body assigning value> }
+- [<visibility>] get => <result_value>;
+- [<visibility>] set => <value_assignment>;
+- [<visibility>] get;
+- [<visibility>] set;
+
+In the case that there is only a getter there is also a short version
+
+<visibility> <type> <identifier> => <result_value>;
+
+Thus, I propose the following syntaxes for TTCN-3 to define properties.
+
+var <template_modifier> <type>
+@property <modifiers>
+{<identifier> [<property_body>] [= <initial_value>] [","]}+ [";"]
+
+<property_body> has the following structure:
+"=>" <expression> |
+"{" (<getter> [<setter>] | <setter> [<getter>) "}"
+
+<getter> has the following structure:
+<modifiers> @get ("=>" <expression> [";"] | "{" { <statement> }+ "}")
+
+<setter> has the following structure:
+<modifiers> @set ("=>" <assignment> [";"] | "{" { <statement> } "}")
+
+We don't allow the { get; set; } syntax for automatic properties (without backing extra fields), instead, a @property variable without a <property_body> is treated as an automatic read/write property.
+
+When a property variable with a given <setter> is accessed on the left hand side of an assignment, the setter statements will be evaluated with the formal parameter 'value' being bound to the actual parameter of the right-hand-side. Accessing a non-automatic property value without a given <setter> on the left-hand side shall result in an error.
+
+When a property variable with a given <getter> is evaluated on the right hand side, the getter statements or expression will be evaluated and the resulting value will be the result of the evaluation. Accessing a non-automatic property value without a given <getter> on the right-hand side shall result in an error.
+
+Properties can be declared public and can be overridden by subclasses with the same visibility restrictions as for methods.
+
+Properties as well as their getters and setters can also be declared @abstract inside @abstract classes. If a property is declared abstract, the getter and/or setter does not need a body.
+
+A property, as well as getters and setters can also be declared @final. If a property is declared @final then neither the getter nor the setter can be overridden, otherwise, if a getter or setter itself is declared @final, then it shall not be overridden.
+
+Properties can be overridden by subclasses if they are not declared @final.
+
+EXAMPLE:
+
+type class MyPropertyClass {
+  private var charstring v_color;
+
+  // read-write property with backing variable
+  public var charstring @property color {
+   // getter in short form
+   @get => v_color;
+   @set {
+     if (isColor(value)) { v_color := value }
+     else { raise v_color&" is not a color" }
+    }
+  }
+  
+  // read-only property with computed value
+  public var RGB @property rgb {
+     // getter in long form
+     @get { return computeRGB(v_color) }
+  }
+  
+  // automatic property with initial value
+  public var float @property size := 0.0;
+
+  // read-only property with derived result in short form
+  public var float @property square => size*size;
+
+  // write-only property with short form
+  public var float @property half_size {
+    @set => size := half_size*2.0;
+  }
+}
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7870-1.docx (153,433) 12-10-2020 13:39
http://oldforge.etsi.org/mantis/file_download.php?file_id=3964&type=bug
docx CR7870-2.docx (139,957) 07-12-2020 10:59
http://oldforge.etsi.org/mantis/file_download.php?file_id=3965&type=bug
docx CR7870-3.docx (156,726) 08-12-2020 13:30
http://oldforge.etsi.org/mantis/file_download.php?file_id=3974&type=bug
docx CR7870-4.docx (204,111) 09-12-2020 08:37
http://oldforge.etsi.org/mantis/file_download.php?file_id=3978&type=bug
docx CR7870-5.docx (186,391) 09-12-2020 14:41
http://oldforge.etsi.org/mantis/file_download.php?file_id=3981&type=bug
Issue History
Date ModifiedUsernameFieldChange
27-08-2019 11:48Jacob Wieland - SpirentNew Issue
27-08-2019 13:04Jacob Wieland - SpirentDescription Updatedbug_revision_view_page.php?rev_id=499#r499
27-08-2019 14:23Jacob Wieland - SpirentNote Added: 0015475
27-08-2019 15:06Jacob Wieland - SpirentAssigned To => Jens Grabowski
27-08-2019 15:06Jacob Wieland - SpirentStatusnew => assigned
14-08-2020 11:20Jens GrabowskiAssigned ToJens Grabowski => Tomas Urban
12-10-2020 13:39Tomas UrbanFile Added: CR7870-1.docx
12-10-2020 13:42Tomas UrbanNote Added: 0015791
12-10-2020 13:42Tomas UrbanAssigned ToTomas Urban => Jacob Wieland - Spirent
07-12-2020 10:32Jacob Wieland - SpirentNote Added: 0015793
07-12-2020 10:38Jacob Wieland - SpirentNote Added: 0015794
07-12-2020 10:59Jacob Wieland - SpirentFile Added: CR7870-2.docx
07-12-2020 11:00Jacob Wieland - SpirentNote Added: 0015795
07-12-2020 11:00Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Tomas Urban
07-12-2020 11:03Jacob Wieland - SpirentNote Added: 0015796
08-12-2020 09:19Jens GrabowskiNote Added: 0015807
08-12-2020 09:39Jens GrabowskiNote Added: 0015808
08-12-2020 09:49Jens GrabowskiNote Added: 0015809
08-12-2020 13:30Tomas UrbanFile Added: CR7870-3.docx
08-12-2020 13:39Tomas UrbanNote Added: 0015813
08-12-2020 13:39Tomas UrbanAssigned ToTomas Urban => Jacob Wieland - Spirent
09-12-2020 08:37Tomas UrbanFile Added: CR7870-4.docx
09-12-2020 08:38Tomas UrbanNote Added: 0015820
09-12-2020 09:16Jens GrabowskiNote Added: 0015823
09-12-2020 14:37Jacob Wieland - SpirentFile Added: CR7870-5.docx
09-12-2020 14:38Jacob Wieland - SpirentNote Added: 0015825
09-12-2020 14:38Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Tomas Urban
09-12-2020 14:38Jacob Wieland - SpirentStatusassigned => confirmed
09-12-2020 14:41Jacob Wieland - SpirentFile Deleted: CR7870-5.docx
09-12-2020 14:41Jacob Wieland - SpirentFile Added: CR7870-5.docx
09-12-2020 15:10Tomas UrbanNote Added: 0015826
09-12-2020 15:10Tomas UrbanAssigned ToTomas Urban => Jacob Wieland - Spirent
10-12-2020 13:31Jacob Wieland - SpirentNote Added: 0015841
10-12-2020 13:31Jacob Wieland - SpirentStatusconfirmed => resolved
10-12-2020 13:31Jacob Wieland - SpirentResolutionopen => fixed
10-12-2020 13:31Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Jens Grabowski
17-12-2020 16:17Gyorgy RethyProduct Version => V1.2.1 (published 2020-05)
17-12-2020 16:17Gyorgy RethyTarget Version => V1.3.1 (ongoing)
28-12-2020 12:21Jens GrabowskiStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015475) +
+ Jacob Wieland - Spirent    +
+ 27-08-2019 14:23    +
+ 		+ + + + +
+ STF-discussion: this is a maybe feature
+
+
+
+ + + + + + + + + + +
+ (0015791) +
+ Tomas Urban    +
+ 12-10-2020 13:42    +
+ 		+ + + + +
+ I put together a basic draft of the functionality. Although there are some important parts still missing (BNF, TCI), I think it is worth to first check if the proposal goes in the right direction. Jacob, could you please comment the proposed rules?
+
+
+
+ + + + + + + + + + +
+ (0015793) +
+ Jacob Wieland - Spirent    +
+ 07-12-2020 10:32    +
+ 		+ + + + +
+ The following things need to be discussed.
+
+What about the setters of list/array properties, is it allowed to use the index operation on them and if so, how to reference the index in the setter?
+
+Similarly, is it allowed to use a property in the middle of a dotted notation on the left hand side of an assignment? And if so, what does it mean? Does it invoke the getter, changes the resulting sub-value in the result and then invokes the setter with the changed value? If so, this approach could also be used to deal with question 1.
+
+
+
+ + + + + + + + + + +
+ (0015794) +
+ Jacob Wieland - Spirent    +
+ 07-12-2020 10:38    +
+ 		+ + + + +
+ We should also discuss the following:
+
+. The initial value is automatically passed to the setter when an instance of the defining class is created. This automatic invocation takes place after execution of a constructor of the parent class and before execution of the constructor of the defining class. Properties are automatically initialized in the declaration order.
+
+I think, since properties are often derived from other variables, they should be initialized after the constructor of the declaring class so that they can safely be executed. There should also be a restriction that the constructor or any non-property member shall reference a property member on the right hand side.
+
+
+
+ + + + + + + + + + +
+ (0015795) +
+ Jacob Wieland - Spirent    +
+ 07-12-2020 11:00    +
+ 		+ + + + +
+ Moved some descriptions that were not really restrictions to the Semantic Description part. Fixed some typos, expandend the example a little bit. Please review
+
+
+
+ + + + + + + + + + +
+ (0015796) +
+ Jacob Wieland - Spirent    +
+ 07-12-2020 11:03    +
+ 		+ + + + +
+ Maybe there should be a @derived modifier for variables/properties that shall not be added as parameters to the implicit constructor.
+
+
+
+ + + + + + + + + + +
+ (0015807) +
+ Jens Grabowski    +
+ 08-12-2020 09:19    +
+ 		+ + + + +
+ STF Discussion: Add restriction that index notation on properties is not allowed on the left hand side of assignments.
+
+
+
+ + + + + + + + + + +
+ (0015808) +
+ Jens Grabowski    +
+ 08-12-2020 09:39    +
+ 		+ + + + +
+ STF Discussion: Initializer before Constructor
+
+
+
+ + + + + + + + + + +
+ (0015809) +
+ Jens Grabowski    +
+ 08-12-2020 09:49    +
+ 		+ + + + +
+ STF Discussion: (1) Automatic properties need to be added to implicit constructors (2) Add internal modifier (@internal or @derived)
+
+
+
+ + + + + + + + + + +
+ (0015813) +
+ Tomas Urban    +
+ 08-12-2020 13:39    +
+ 		+ + + + +
+ I made those two small changes we discussed at the meeting. The initialization didn't require any change as the original design used initialization before the constructor.
+
+Since there's no section on member variables, I added the @internal modifier description only to the section describing constructors (and syntax description of properties).
+
+Jacob, please check if these changes are fine by you. However, the document is still quite far from final. Since you mentioned that you didn't have many tasks assigned to you, could you please also create the BNF and eventually address the visibility issue (especially visibility on the getter and setter level).
+
+I could meanwhile deal with the TCI.
+
+
+
+ + + + + + + + + + +
+ (0015820) +
+ Tomas Urban    +
+ 09-12-2020 08:38    +
+ 		+ + + + +
+ I added the TCI section to the document.
+
+
+
+ + + + + + + + + + +
+ (0015823) +
+ Jens Grabowski    +
+ 09-12-2020 09:16    +
+ 		+ + + + +
+ STF Discussion: Visibility should be considered in the proposal.
+
+
+
+ + + + + + + + + + +
+ (0015825) +
+ Jacob Wieland - Spirent    +
+ 09-12-2020 14:38    +
+ 		+ + + + +
+ Added visibility and BNF rules. Also changed/simplified syntactical structure.
+
+Please review
+
+
+
+ + + + + + + + + + +
+ (0015826) +
+ Tomas Urban    +
+ 09-12-2020 15:10    +
+ 		+ + + + +
+ It looks fine to me. Could you please check the TCI section and either assign to Kristof for the final check or mark it directly as resolved if you find no issues.
+
+
+
+ + + + + + + + + + +
+ (0015841) +
+ Jacob Wieland - Spirent    +
+ 10-12-2020 13:31    +
+ 		+ + + + +
+ TCI part looks fine.
+
+ + diff --git a/docs/mantis/CR7871.md b/docs/mantis/CR7871.md new file mode 100644 index 0000000000000000000000000000000000000000..9b7e2961cf6609f50ac6f240db6a70fb97d19dce --- /dev/null +++ b/docs/mantis/CR7871.md @@ -0,0 +1,446 @@ + + + + + + + + + + + + + 0007871: Class templates to be added to the language? - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Object-oriented features (ES 203 790)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007871Ext Pack: Object-oriented features (ES 203 790)[All Projects] Generalpublic27-08-2019 15:1528-12-2020 13:44
ReporterJacob Wieland - Spirent 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product VersionV1.2.1 (published 2020-05) 
Target VersionV1.3.1 (ongoing)Fixed in Version 
Summary0007871: Class templates to be added to the language?
DescriptionIt should be investigated whether there are use cases that are facilitated by some class template mechanisms (outside which those that are already possible with the ones that we already have).
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7871-1.docx (134,973) 11-12-2020 12:48
http://oldforge.etsi.org/mantis/file_download.php?file_id=3988&type=bug
docx CR7871-2.docx (136,182) 11-12-2020 13:21
http://oldforge.etsi.org/mantis/file_download.php?file_id=3990&type=bug
docx CR7871-3.docx (148,597) 11-12-2020 13:22
http://oldforge.etsi.org/mantis/file_download.php?file_id=3991&type=bug
docx CR7871-4.docx (148,246) 11-12-2020 13:30
http://oldforge.etsi.org/mantis/file_download.php?file_id=3992&type=bug
docx CR7871-5.docx (137,390) 11-12-2020 13:34
http://oldforge.etsi.org/mantis/file_download.php?file_id=3993&type=bug
Issue History
Date ModifiedUsernameFieldChange
27-08-2019 15:15Jacob Wieland - SpirentNew Issue
27-08-2019 15:23Jacob Wieland - SpirentAssigned To => Jens Grabowski
27-08-2019 15:23Jacob Wieland - SpirentStatusnew => assigned
17-12-2019 08:34Jacob Wieland - SpirentNote Added: 0015534
10-12-2020 14:10Jacob Wieland - SpirentNote Added: 0015843
10-12-2020 15:30Jacob Wieland - SpirentNote Added: 0015844
10-12-2020 15:36Jacob Wieland - SpirentNote Edited: 0015844bug_revision_view_page.php?bugnote_id=15844#r532
11-12-2020 11:07Jens GrabowskiAssigned ToJens Grabowski => Jacob Wieland - Spirent
11-12-2020 12:48Jacob Wieland - SpirentFile Added: CR7871-1.docx
11-12-2020 12:49Jacob Wieland - SpirentNote Added: 0015850
11-12-2020 12:49Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Tomas Urban
11-12-2020 12:50Jacob Wieland - SpirentNote Added: 0015851
11-12-2020 13:05Jacob Wieland - SpirentNote Added: 0015852
11-12-2020 13:06Jacob Wieland - SpirentFile Added: CR7871-2.docx
11-12-2020 13:07Jacob Wieland - SpirentNote Added: 0015853
11-12-2020 13:21Jacob Wieland - SpirentFile Deleted: CR7871-2.docx
11-12-2020 13:21Jacob Wieland - SpirentFile Added: CR7871-2.docx
11-12-2020 13:22Tomas UrbanFile Added: CR7871-3.docx
11-12-2020 13:22Jacob Wieland - SpirentNote Added: 0015854
11-12-2020 13:23Tomas UrbanNote Added: 0015855
11-12-2020 13:23Tomas UrbanAssigned ToTomas Urban => Jacob Wieland - Spirent
11-12-2020 13:23Tomas UrbanStatusassigned => confirmed
11-12-2020 13:30Tomas UrbanFile Added: CR7871-4.docx
11-12-2020 13:34Jacob Wieland - SpirentFile Added: CR7871-5.docx
11-12-2020 13:35Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Tomas Urban
11-12-2020 13:35Jacob Wieland - SpirentStatusconfirmed => assigned
11-12-2020 13:35Jacob Wieland - SpirentNote Added: 0015856
11-12-2020 13:35Jacob Wieland - SpirentStatusassigned => confirmed
11-12-2020 13:40Tomas UrbanNote Added: 0015857
11-12-2020 13:40Tomas UrbanStatusconfirmed => resolved
11-12-2020 13:40Tomas UrbanResolutionopen => fixed
11-12-2020 13:40Tomas UrbanAssigned ToTomas Urban => Jens Grabowski
17-12-2020 16:17Gyorgy RethyProduct Version => V1.2.1 (published 2020-05)
17-12-2020 16:17Gyorgy RethyTarget Version => V1.3.1 (ongoing)
28-12-2020 13:44Jens GrabowskiStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015534) +
+ Jacob Wieland - Spirent    +
+ 17-12-2019 08:34    +
+ 		+ + + + +
+ Interesting in this regard would be to look at Class patterns introduced by Java or Scala.
+
+
+
+ + + + + + + + + + +
+ (0015843) +
+ Jacob Wieland - Spirent    +
+ 10-12-2020 14:10    +
+ 		+ + + + +
+ The only idea that I can come up with so far that is in sync with the design principles of TTCN-3 is to allow compound-assignment-notation as class templates.
+
+Only those fields that are to be constrained should have to be mentioned, all unmentioned fields should implicitly be 'don't care'. That way, a template for class A can also be used for all subclasses of A that add additional fields. Otherwise, you would always have to use the mofifies contruct like A:modifies ? := { ... } instead of simply A:{ ... }
+
+Only field members should be referenced on the left sides of the field assignments inside the compound assignment.
+
+Example:
+
+type class Pair { var integer a, b }
+
+template Pair t := { a := (1 .. 20) }
+
+type class Triple extends Pair { var integer c }
+
+match(Triple.create(1,2,3), t) // returns true
+
+Additionally, method calls of non-void methods of the class could also be allowed on the left hand side of the assignment notation.
+
+For example:
+
+type class @abstract Shape { function @abstract area() return float; }
+
+template Shape smallShape := { area() := (0 .. 20.0) }
+
+smallShape would match for all objects whose class is derived from Shape and where the result of the method call to area() fulfills the constraint.
+
+For this extension, of course, multiple "assignments" for the same method shall be allowed in the compound assignment. As always, the semantics would be that for all assignments the constraint needs to be fulfilled so that the template matches.
+
+Drawback here is that empty templates that do not match anything can be declared, as in
+
+template Shape empty := {
+  area() := (0.0 .. infinity),
+  area() := {-infinity .. !0.0)
+}
+
+A similar such conflict can occur between an assignment of a field member and a method-call constraint.
+
+So, maybe this advanced assignment notation with method calls should only be added to the advanced matching package.
+
+
+
+ + + + + + + + + + +
+ (0015844) +
+ Jacob Wieland - Spirent    +
+ 10-12-2020 15:30    +
(edited on: 10-12-2020 15:36)
+ 		+ + + + +
+ Probably only non-private fields should be possible to be used in class templates, as otherwise, private fields could be implicitly accessed.
+
+Maybe this should even only be allowed for public property fields (and public methods), i.e. those things that you can access from outside.
+
+
+
+
+
+ + + + + + + + + + +
+ (0015850) +
+ Jacob Wieland - Spirent    +
+ 11-12-2020 12:49    +
+ 		+ + + + +
+ Please review first draft.
+
+
+
+ + + + + + + + + + +
+ (0015851) +
+ Jacob Wieland - Spirent    +
+ 11-12-2020 12:50    +
+ 		+ + + + +
+ TODO: BNF rules
+
+
+
+ + + + + + + + + + +
+ (0015852) +
+ Jacob Wieland - Spirent    +
+ 11-12-2020 13:05    +
+ 		+ + + + +
+ TODO: Delete the sentence that there are no object/class templates.
+
+
+
+ + + + + + + + + + +
+ (0015853) +
+ Jacob Wieland - Spirent    +
+ 11-12-2020 13:07    +
+ 		+ + + + +
+ Added second draft with additional restriction about object templates not being allowed to be used as values or converted into values.
+
+Also added BNF rules (draft)
+
+
+
+ + + + + + + + + + +
+ (0015854) +
+ Jacob Wieland - Spirent    +
+ 11-12-2020 13:22    +
+ 		+ + + + +
+ Replaced draft 2 with version with simpler BNF change that also does not introduce BNF ambiguity by changing only the rule for FieldSpec
+
+
+
+ + + + + + + + + + +
+ (0015855) +
+ Tomas Urban    +
+ 11-12-2020 13:23    +
+ 		+ + + + +
+ It seems fine to me. I only made two small changes, please check.
+
+
+
+ + + + + + + + + + +
+ (0015856) +
+ Jacob Wieland - Spirent    +
+ 11-12-2020 13:35    +
+ 		+ + + + +
+ ok, also added the deletion of the restriction that there are no class templates to the draft, please check and resolve, if ok
+
+
+
+ + + + + + + + + + +
+ (0015857) +
+ Tomas Urban    +
+ 11-12-2020 13:40    +
+ 		+ + + + +
+ Reviewed, no issues found. The proposal is ready to be added to the next version of the specification.
+
+ + diff --git a/docs/mantis/CR7874.md b/docs/mantis/CR7874.md new file mode 100644 index 0000000000000000000000000000000000000000..9eaab53c9faeda5bab853f427fc750c5f7278368 --- /dev/null +++ b/docs/mantis/CR7874.md @@ -0,0 +1,717 @@ + + + + + + + + + + + + + 0007874: Reintroduce restriction on restricted modified templates - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007874Part 01: TTCN-3 Core LanguageTechnicalpublic05-09-2019 10:3415-12-2020 16:53
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version4.13.1 (ongoing) 
Target Version4.13.1 (ongoing)Fixed in Version4.13.1 (ongoing) 
Clause Reference(s)15.8
Source (company - Author)STF 572
Summary0007874: Reintroduce restriction on restricted modified templates
DescriptionCR 0007603 introduced compile-time checks on template restrictions. It should be considered to reintroduce the restriction 15.8.c which was removed from the standard in its TTCN-3:2013 version in order to comply with the "soft" interpretation of template restrictions.
+
+This is the original text of the restriction (with minor modification: has to -> shall):
+
+A restricted, modified template shall have the same or more restrictive restriction as the base template. A restricted parameter of a modified template shall have the same or a more restrictive restriction as the corresponding parameter of the base template. The allowed restrictions are listed in table 14.
+
+Table 14: Restricting modified templates
+Restriction in base template | Allowed restrictions in modified template
+template | template, template(present), template(omit), template(value)
+template(present) | template(present), template(value)
+template(omit) | template(omit), template(value)
+template(value) | template(value)
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0007603closed Gyorgy Rethy Delete note on template restriction passing table 
Attached Filesdocx CR_7874.docx (315,106) 18-12-2019 10:29
http://oldforge.etsi.org/mantis/file_download.php?file_id=3891&type=bug
docx CR_7874-2.docx (349,256) 18-12-2019 12:35
http://oldforge.etsi.org/mantis/file_download.php?file_id=3894&type=bug
docx CR_7874-3.docx (292,638) 18-12-2019 13:10
http://oldforge.etsi.org/mantis/file_download.php?file_id=3895&type=bug
Issue History
Date ModifiedUsernameFieldChange
05-09-2019 10:34Tomas UrbanNew Issue
05-09-2019 10:34Tomas UrbanRelationship addedrelated to 0007603
05-09-2019 12:27Tomas UrbanNote Added: 0015492
05-09-2019 14:27Tomas UrbanNote Added: 0015493
05-09-2019 15:17Jacob Wieland - SpirentNote Added: 0015494
06-09-2019 08:08Tomas UrbanNote Edited: 0015493bug_revision_view_page.php?bugnote_id=15493#r503
06-09-2019 08:11Tomas UrbanNote Added: 0015495
06-09-2019 08:37Jacob Wieland - SpirentNote Added: 0015496
06-09-2019 09:03Tomas UrbanNote Added: 0015497
06-09-2019 10:01Jacob Wieland - SpirentNote Added: 0015498
06-09-2019 10:12Tomas UrbanNote Added: 0015499
16-12-2019 09:37Jens GrabowskiNote Added: 0015517
16-12-2019 09:37Jens GrabowskiAssigned To => Kristóf Szabados
16-12-2019 09:37Jens GrabowskiStatusnew => assigned
16-12-2019 09:49Jens GrabowskiNote Added: 0015518
17-12-2019 12:23Kristóf SzabadosNote Added: 0015547
18-12-2019 10:29Kristóf SzabadosFile Added: CR_7874.docx
18-12-2019 10:30Kristóf SzabadosAssigned ToKristóf Szabados => Tomas Urban
18-12-2019 10:30Kristóf SzabadosNote Added: 0015576
18-12-2019 12:35Tomas UrbanFile Added: CR_7874-2.docx
18-12-2019 12:42Tomas UrbanNote Added: 0015582
18-12-2019 12:42Tomas UrbanAssigned ToTomas Urban => Kristóf Szabados
18-12-2019 13:02Kristóf SzabadosNote Added: 0015583
18-12-2019 13:10Kristóf SzabadosFile Added: CR_7874-3.docx
18-12-2019 13:11Kristóf SzabadosNote Added: 0015584
18-12-2019 13:11Kristóf SzabadosAssigned ToKristóf Szabados => Jacob Wieland - Spirent
24-01-2020 14:14Jacob Wieland - SpirentNote Added: 0015608
24-01-2020 14:14Jacob Wieland - SpirentStatusassigned => resolved
24-01-2020 14:14Jacob Wieland - SpirentFixed in Version => 4.13.1 (ongoing)
24-01-2020 14:14Jacob Wieland - SpirentResolutionopen => fixed
24-01-2020 14:14Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Jens Grabowski
24-01-2020 14:20Jacob Wieland - SpirentStatusresolved => feedback
24-01-2020 14:20Jacob Wieland - SpirentResolutionfixed => reopened
24-01-2020 14:21Jacob Wieland - SpirentStatusfeedback => resolved
24-01-2020 14:21Jacob Wieland - SpirentResolutionreopened => fixed
24-01-2020 14:21Jacob Wieland - SpirentAssigned ToJens Grabowski => Gyorgy Rethy
15-12-2020 16:53Gyorgy RethyNote Added: 0015859
15-12-2020 16:53Gyorgy RethyStatusresolved => closed
15-12-2020 16:53Gyorgy RethyProduct Version => 4.13.1 (ongoing)
15-12-2020 16:53Gyorgy RethyTarget Version => 4.13.1 (ongoing)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015492) +
+ Tomas Urban    +
+ 05-09-2019 12:27    +
+ 		+ + + + +
+ Actually, the first part of the restriction is problematic and in my opinion it should be vice versa, i.e. the modified template should have the same restriction or be less restrictive than the base template. That's because there are always some unmodified fields and if these fields do not comply with the restriction of the modified template, the content of the template would be invalid.
+
+
+
+ + + + + + + + + + +
+ (0015493) +
+ Tomas Urban    +
+ 05-09-2019 14:27    +
(edited on: 06-09-2019 08:08)
+ 		+ + + + +
+ Example demonstrating possible error when using stronger restriction:
+
+type record R {
+  integer field1,
+  integer field2
+}
+...
+{
+  var template R vm_base := ?;
+  var template(value) R vm_modified := modifies vm_base := { field1 := 1 }
+  // after the assignment vm_modified.field1 contains ? which is not complient with the value restriction
+}
+
+
+
+
+
+ + + + + + + + + + +
+ (0015494) +
+ Jacob Wieland - Spirent    +
+ 05-09-2019 15:17    +
+ 		+ + + + +
+ This restriction should only apply when modifying template variables (since the content of the variable is unknown).
+
+When modifying static templates, the restriction is not necessary. The only unknowns in there are formal parameters. In a value or omit template, the formal parameters are restricted to value/omit templates, as well, so it is always safe to modify a value/omit template with another value/omit-only modification because the result will be a value template.
+
+If the base template was a present template, it cannot become a non-present template by modification with a body, so here again, the restriction cannot become worse.
+
+
+
+ + + + + + + + + + +
+ (0015495) +
+ Tomas Urban    +
+ 06-09-2019 08:11    +
+ 		+ + + + +
+ Since the original restriction 15.8.c is problematic, I would make a proposal for the new restrictions so that it is clear what we are discussing about:
+
+c) A restricted, modified template shall have the same or less restrictive restriction as the base template. The allowed restrictions are listed in table 14.
+
+Table 14: Restricting modified templates
+Restriction of base template | Allowed restrictions of modified template
+template | template
+template(present) | template(present), template
+template(omit) | template(omit), template
+template(value) | template(value), template, template(present), template(omit)
+
+d) A restricted parameter of a modified template shall have the same or a more restrictive restriction as the corresponding parameter of the base template. The allowed restrictions are listed in table 15.
+
+Table 15: Changing restriction of formal parameters of modified templates
+Parameter restriction in base template | Allowed parameter restrictions in modified template
+template | template, template(present), template(omit), template(value)
+template(present) | template(present), template(value)
+template(omit) | template(omit), template(value)
+template(value) | template(value)
+
+Now some comments to Jacob's note:
+1. Static templates declared in statement blocks might be dependent on variables. Even static templates from component blocks can have content that is not resolved during compilation (fields initialized by functions, dependent on module parameters, fuzzy templates).
+
+2. I couldn't find a rule or restriction saying that formal parameters of a restricted template shall have the same or stronger restriction than the template. In my opinion, it is completely legal to define a template like this:
+
+function f_testTemplate(template integer p_par) return integer {
+   if (isvalue(p_par)) { return valueof(p_par); }
+   else { return 0; }
+}
+
+template(value) R m_myMsg (template integer p_par) { // unrestricted template parameter p_par is not used in the template body directly thus it does not violate any rules on restricted templates
+   field1 := f_testTemplate(p_par),
+   field2 := 2019
+}
+
+// m_myMsg(?) would yield { field1 := 0, field2 := 2019 }
+
+3. Example on problematic modification of a base template with a present restriction (currently allowed, leads to a runtime error):
+
+  var template(present) R vm_base := ?;
+  template(value) R vm_modified modifies vm_base := { field1 := 1 }
+
+4. I don't agree that the rule should be restricted to variables. In TTCN-3:2018 we made a major change in the rules on restrictions saying that the content doesn't matter. E.g. this is not allowed any more, even though it would be perfectly legal in older versions of TTCN-3 and it wouldn't cause any error:
+
+template R m_base2 := { field1 := 1, field2 := 2}
+template(value) R m_valueTmpt := m_base2;
+
+Why should a similar modification (see below) be legal just because it is static? The rules on restrictions should be universal and not consider the content in any case.
+
+template(value) R m_modified2 modifies m_base2 := { field2 := 10 };
+
+
+
+ + + + + + + + + + +
+ (0015496) +
+ Jacob Wieland - Spirent    +
+ 06-09-2019 08:37    +
+ 		+ + + + +
+ The example you give in 3 is simply an erroneous usage that will yield a dynamic error, one that can already be warned about at compile-time (modifying a present template will not necessarily yield a value template).
+
+There is no need for a backward-incompatible restriction, even for variables. There are myriad examples where modifying a present-template will yield a value-template. Such checks need only be done in special situations, so if the code uses the restrictions in a proper way, the executed won't even be inefficient.
+
+This is pretty much on par with assigning a less restricted template (e.g. the result of a function) to a more restricted template variable. It's not forbidden (as far as I know) but it can fail, same as with type restrictions if the types just overlap.
+
+
+
+ + + + + + + + + + +
+ (0015497) +
+ Tomas Urban    +
+ 06-09-2019 09:03    +
+ 		+ + + + +
+ It is forbidden to assign a less restrictive template to a more restrictive template variable because of the restriction 15.8.b which applies to the example you provided (the less restrictive template returned by the function is on the right hand side of the assignment).
+
+My argument for extension of the rule to modification is language consistency. The core lanugage specification should not allow something in one language statement and disallow it in another closely related one. If the restriction 15.8.b says that assignment of less restrictive template to a more restrictive one is not allowed regardless of the template content, a similar rule should be present for modification which is just a different kind of assignment.
+
+As regards backwards incompatibility, the change made in 0007603 was also backwards incompatible and we resolved it by moving the old rules to the deprecated section. In reality it means that compilers issue warnings instead of errors in these case anyway (and generate runtime validation code for such assignments). The same principle could be used for modified templates as well.
+
+
+
+ + + + + + + + + + +
+ (0015498) +
+ Jacob Wieland - Spirent    +
+ 06-09-2019 10:01    +
+ 		+ + + + +
+ Please consider the following NOTE about this (from 15.8.)
+
+NOTE: Template restrictions allow TTCN-3 tools to check more easily at compile time whether templates and
+matching expressions are used correctly. Whether the checks are performed at compile time and invalid
+code is rejected or whether the checks are performed at execution time and dynamic errors are raised, is
+outside the scope of the present document.
+
+
+
+ + + + + + + + + + +
+ (0015499) +
+ Tomas Urban    +
+ 06-09-2019 10:12    +
+ 		+ + + + +
+ I am aware of this note and I think it is consistent with the proposed restrictions. According to the note, tools would still have a legal option to issue just a warning as it is the case with the restriction 15.8.b.
+
+
+
+ + + + + + + + + + +
+ (0015517) +
+ Jens Grabowski    +
+ 16-12-2019 09:37    +
+ 		+ + + + +
+ STF discussion: Kristof will prepare the discussion.
+
+
+
+ + + + + + + + + + +
+ (0015518) +
+ Jens Grabowski    +
+ 16-12-2019 09:49    +
+ 		+ + + + +
+ STF discussion: To be done:
+1) Decision on restriction of modified templates.
+2) Definition of "stricter" has to be added. This is related to 15.5 restriction b.2.
+
+
+
+ + + + + + + + + + +
+ (0015547) +
+ Kristóf Szabados    +
+ 17-12-2019 12:23    +
+ 		+ + + + +
+ STF discussion:
+- the template result of modifies has the same restriveness as the base template.
+- introduce the omit(template) and present(template) operators, that yield a template with omit and present restriction respectively.
+- the parameters can be changed for stricter ones.
+- add definition of strictness (as it is referenced).
+- move to deprecated the current modifies behavior (where the result could be stricter)
+
+
+
+ + + + + + + + + + +
+ (0015576) +
+ Kristóf Szabados    +
+ 18-12-2019 10:30    +
+ 		+ + + + +
+ uploaded first draft, please review.
+
+
+
+ + + + + + + + + + +
+ (0015582) +
+ Tomas Urban    +
+ 18-12-2019 12:42    +
+ 		+ + + + +
+ New version of the resolution with three bigger changes:
+- Template restriction operators changed to template operations and moved to the chapter 15 (also in the BNF)
+- Modify the rule on restriction of modified templates so that the modified template can have less strict restriction and added a related table
+- Added a description to the table 14
+
+There are also some minor corrections in the text.
+
+Please review
+
+
+
+ + + + + + + + + + +
+ (0015583) +
+ Kristóf Szabados    +
+ 18-12-2019 13:02    +
+ 		+ + + + +
+ Just a little notice: "A template with the omit restriction if the operand fulfils conditions of the omit template restriction as described in clause 15.8"
+Does not indicate any connection between the resulting template and the operand.
+
+
+
+ + + + + + + + + + +
+ (0015584) +
+ Kristóf Szabados    +
+ 18-12-2019 13:11    +
+ 		+ + + + +
+ fixed + typos, please review.
+
+
+
+ + + + + + + + + + +
+ (0015608) +
+ Jacob Wieland - Spirent    +
+ 24-01-2020 14:14    +
+ 		+ + + + +
+ Seems fine to me.
+
+Because this issue was assigned instead of confirmed, I missed it.
+
+Hope it can still be included.
+
+
+
+ + + + + + + + + + +
+ (0015859) +
+ Gyorgy Rethy    +
+ 15-12-2020 16:53    +
+ 		+ + + + +
+ Implemented in draft 4.12.2
+
+ + diff --git a/docs/mantis/CR7875.md b/docs/mantis/CR7875.md new file mode 100644 index 0000000000000000000000000000000000000000..429d245517dd865e77ac216d44ec18a61bfc4e70 --- /dev/null +++ b/docs/mantis/CR7875.md @@ -0,0 +1,135 @@ + + + + + + + + + + + + + 0007875: Typos in the section 21.3.10 - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007875Part 01: TTCN-3 Core LanguageEditorialpublic16-09-2019 10:2328-12-2019 16:51
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeveritytrivialReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version4.12.1 (published 2020-05) 
Clause Reference(s)21.3.10
Source (company - Author)STF 572
Summary0007875: Typos in the section 21.3.10
DescriptionThere two typos in the rules on the component call operation:
+
+Superfuous "i": If the i incomplete execution occurs because the called component...
+
+Missing space in "theexecution": In all other cases when theexecution is incomplete...
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7875.docx (69,257) 16-12-2019 13:26
http://oldforge.etsi.org/mantis/file_download.php?file_id=3872&type=bug
Issue History
Date ModifiedUsernameFieldChange
16-09-2019 10:23Tomas UrbanNew Issue
16-12-2019 09:23Jens GrabowskiNote Added: 0015516
16-12-2019 09:23Jens GrabowskiAssigned To => Jens Grabowski
16-12-2019 09:23Jens GrabowskiStatusnew => assigned
16-12-2019 13:26Jens GrabowskiFile Added: CR7875.docx
16-12-2019 13:28Jens GrabowskiNote Added: 0015523
16-12-2019 13:28Jens GrabowskiStatusassigned => resolved
16-12-2019 13:28Jens GrabowskiResolutionopen => fixed
16-12-2019 13:28Jens GrabowskiAssigned ToJens Grabowski => Gyorgy Rethy
28-12-2019 16:51Gyorgy RethyNote Added: 0015597
28-12-2019 16:51Gyorgy RethyStatusresolved => closed
28-12-2019 16:51Gyorgy RethyFixed in Version => 4.12.1 (published 2020-05)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015516) +
+ Jens Grabowski    +
+ 16-12-2019 09:23    +
+ 		+ + + + +
+ STF discussion: agreed
+
+
+
+ + + + + + + + + + +
+ (0015523) +
+ Jens Grabowski    +
+ 16-12-2019 13:28    +
+ 		+ + + + +
+ Typos corrected as proposed.
+
+
+
+ + + + + + + + + + +
+ (0015597) +
+ Gyorgy Rethy    +
+ 28-12-2019 16:51    +
+ 		+ + + + +
+ Corrected in final draft V4.11.2
+
+ + diff --git a/docs/mantis/CR7876.md b/docs/mantis/CR7876.md new file mode 100644 index 0000000000000000000000000000000000000000..7cdef85aaa10c4ca349a595a3913201220223bc2 --- /dev/null +++ b/docs/mantis/CR7876.md @@ -0,0 +1,131 @@ + + + + + + + + + + + + + 0007876: Restrictions in 21.3.10 are incorrectly numbered - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007876Part 01: TTCN-3 Core LanguageEditorialpublic17-09-2019 10:5428-12-2019 16:49
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeveritytrivialReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version4.12.1 (published 2020-05) 
Clause Reference(s)21.3.10
Source (company - Author)STF 572
Summary0007876: Restrictions in 21.3.10 are incorrectly numbered
DescriptionThe restrictions in the section 21.3.10 start from d) instead of a)
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7876.docx (68,135) 16-12-2019 13:39
http://oldforge.etsi.org/mantis/file_download.php?file_id=3873&type=bug
Issue History
Date ModifiedUsernameFieldChange
17-09-2019 10:54Tomas UrbanNew Issue
16-12-2019 09:22Jens GrabowskiNote Added: 0015515
16-12-2019 09:23Jens GrabowskiAssigned To => Jens Grabowski
16-12-2019 09:23Jens GrabowskiStatusnew => assigned
16-12-2019 13:39Jens GrabowskiFile Added: CR7876.docx
16-12-2019 13:41Jens GrabowskiNote Added: 0015525
16-12-2019 13:41Jens GrabowskiStatusassigned => resolved
16-12-2019 13:41Jens GrabowskiResolutionopen => fixed
16-12-2019 13:41Jens GrabowskiAssigned ToJens Grabowski => Gyorgy Rethy
28-12-2019 16:49Gyorgy RethyNote Added: 0015596
28-12-2019 16:49Gyorgy RethyStatusresolved => closed
28-12-2019 16:49Gyorgy RethyFixed in Version => 4.12.1 (published 2020-05)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015515) +
+ Jens Grabowski    +
+ 16-12-2019 09:22    +
+ 		+ + + + +
+ STF discussion: agreed
+
+
+
+ + + + + + + + + + +
+ (0015525) +
+ Jens Grabowski    +
+ 16-12-2019 13:41    +
+ 		+ + + + +
+ Typo fixed as proposed.
+
+
+
+ + + + + + + + + + +
+ (0015596) +
+ Gyorgy Rethy    +
+ 28-12-2019 16:49    +
+ 		+ + + + +
+ Corrected in final draft V4.11.2
+
+ + diff --git a/docs/mantis/CR7877.md b/docs/mantis/CR7877.md new file mode 100644 index 0000000000000000000000000000000000000000..f4ebc93d3c2bf8e81aa81fda8765fac6fb120c1b --- /dev/null +++ b/docs/mantis/CR7877.md @@ -0,0 +1,135 @@ + + + + + + + + + + + + + 0007877: Invalid reference to alstep return value - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007877Part 01: TTCN-3 Core LanguageTechnicalpublic17-09-2019 12:0328-12-2019 16:38
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version4.12.1 (published 2020-05) 
Clause Reference(s)21.3.10
Source (company - Author)STF 572
Summary0007877: Invalid reference to alstep return value
DescriptionRestriction g of 21.3.10 states that:
+The return value of the function or altstep invoked from a call test component operation neither be of a port, default or timer type nor should contain a direct or indirect element or field of a port, default or timer type.
+
+However, altsteps cannot have a return value. I suggest to remove "or alstep" from the restriction.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7877.docx (68,099) 16-12-2019 13:53
http://oldforge.etsi.org/mantis/file_download.php?file_id=3875&type=bug
Issue History
Date ModifiedUsernameFieldChange
17-09-2019 12:03Tomas UrbanNew Issue
16-12-2019 09:22Jens GrabowskiNote Added: 0015514
16-12-2019 09:22Jens GrabowskiAssigned To => Jens Grabowski
16-12-2019 09:22Jens GrabowskiStatusnew => assigned
16-12-2019 13:53Jens GrabowskiFile Added: CR7877.docx
16-12-2019 13:55Jens GrabowskiNote Added: 0015527
16-12-2019 13:55Jens GrabowskiStatusassigned => resolved
16-12-2019 13:55Jens GrabowskiResolutionopen => fixed
16-12-2019 13:55Jens GrabowskiAssigned ToJens Grabowski => Gyorgy Rethy
28-12-2019 16:38Gyorgy RethyNote Added: 0015593
28-12-2019 16:38Gyorgy RethyStatusresolved => closed
28-12-2019 16:38Gyorgy RethyFixed in Version => 4.12.1 (published 2020-05)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015514) +
+ Jens Grabowski    +
+ 16-12-2019 09:22    +
+ 		+ + + + +
+ STF discussion: agreed
+
+
+
+ + + + + + + + + + +
+ (0015527) +
+ Jens Grabowski    +
+ 16-12-2019 13:55    +
+ 		+ + + + +
+ 1) the restriction is d) and not g)
+2) resolved as proposed
+
+
+
+ + + + + + + + + + +
+ (0015593) +
+ Gyorgy Rethy    +
+ 28-12-2019 16:38    +
+ 		+ + + + +
+ Included to final draft V4.11.2
+
+ + diff --git a/docs/mantis/CR7883.md b/docs/mantis/CR7883.md new file mode 100644 index 0000000000000000000000000000000000000000..b6c8b8892cd97395cd19b7d3518de3c76d46a8f4 --- /dev/null +++ b/docs/mantis/CR7883.md @@ -0,0 +1,222 @@ + + + + + + + + + + + + + 0007883: Fully initialized templates - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007883Part 01: TTCN-3 Core LanguageNew Featurepublic15-10-2019 09:3228-12-2019 12:54
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version4.12.1 (published 2020-05) 
Clause Reference(s)15.0
Source (company - Author)Elvior
Summary0007883: Fully initialized templates
DescriptionThe current standard requires templates to be at least partially initialized:
+
+15.0.d The expression or template body initializing a template shall evaluate to a value or a template that is at least partially initialized or to a matching mechanism.
+
+This is useful in cases when some templates are used as abstract, containing just some basic values and the missing values are added in templates derived from them.
+
+However, TTCN-3 language doesn't contain any mechanism that would allow the user to distinguish between abstract templates containing partially initialized values and fully initialized ones which could be safely used in communication operations.
+
+Proposal:
+Add a specific modifier that would require a static template to be fully initialized, e.g.
+
+template @concrete MyType mw_msg ....
+
+Since most templates are actually defined as fully initialized, more logical would be to mark the abstract ones:
+
+template @abstract MyType mw_msgBase ....
+
+However, this approach would create a change that is not backwards compatible.
+
+It should be also explained in detail whether restricted templates can or may not be partially initialized.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7883-1.docx (221,192) 17-12-2019 08:54
http://oldforge.etsi.org/mantis/file_download.php?file_id=3879&type=bug
Issue History
Date ModifiedUsernameFieldChange
15-10-2019 09:32Tomas UrbanNew Issue
22-10-2019 07:53Kristóf SzabadosNote Added: 0015505
16-12-2019 09:21Jens GrabowskiNote Added: 0015513
16-12-2019 09:21Jens GrabowskiAssigned To => Tomas Urban
16-12-2019 09:21Jens GrabowskiStatusnew => assigned
17-12-2019 08:54Tomas UrbanFile Added: CR7883-1.docx
17-12-2019 08:55Tomas UrbanNote Added: 0015537
17-12-2019 08:55Tomas UrbanAssigned ToTomas Urban => Jacob Wieland - Spirent
17-12-2019 08:55Tomas UrbanStatusassigned => confirmed
17-12-2019 14:08Jacob Wieland - SpirentNote Added: 0015559
17-12-2019 14:08Jacob Wieland - SpirentStatusconfirmed => resolved
17-12-2019 14:08Jacob Wieland - SpirentFixed in Version => 4.11.1 (published 2019-05)
17-12-2019 14:08Jacob Wieland - SpirentResolutionopen => fixed
17-12-2019 14:08Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Jens Grabowski
28-12-2019 12:54Gyorgy RethyAssigned ToJens Grabowski => Gyorgy Rethy
28-12-2019 12:54Gyorgy RethyStatusresolved => assigned
28-12-2019 12:54Gyorgy RethyNote Added: 0015587
28-12-2019 12:54Gyorgy RethyStatusassigned => closed
28-12-2019 12:54Gyorgy RethyFixed in Version4.11.1 (published 2019-05) => 4.12.1 (published 2020-05)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015505) +
+ Kristóf Szabados    +
+ 22-10-2019 07:53    +
+ 		+ + + + +
+ If I remember correctly the current template restrictions can be used to check if a template can be safely sent on the network (value).
+
+This might also be a tooling issue.
+For example we have a code quality check for partially initialized items. So that users can pay special attention when working with them (+ creation and maintenance).
+This way does not have any runtime performance overhead, since it is done on the code statically.
+
+
+
+ + + + + + + + + + +
+ (0015513) +
+ Jens Grabowski    +
+ 16-12-2019 09:21    +
+ 		+ + + + +
+ STF discussion: The introduction of "@abstract" as optional modifier is reasonable. The usage of partially initialized templates without "@abstract" should be deprecated in the future (put a warning into the standard).
+
+
+
+ + + + + + + + + + +
+ (0015537) +
+ Tomas Urban    +
+ 17-12-2019 08:55    +
+ 		+ + + + +
+ Resolution uploaded, please review.
+
+
+
+ + + + + + + + + + +
+ (0015559) +
+ Jacob Wieland - Spirent    +
+ 17-12-2019 14:08    +
+ 		+ + + + +
+ proposal is fine
+
+
+
+ + + + + + + + + + +
+ (0015587) +
+ Gyorgy Rethy    +
+ 28-12-2019 12:54    +
+ 		+ + + + +
+ Implemented in final draft 4.11.2.
+
+ + diff --git a/docs/mantis/CR7884.md b/docs/mantis/CR7884.md new file mode 100644 index 0000000000000000000000000000000000000000..94782d2d48af47a97dc53b673140387c8a7d758a --- /dev/null +++ b/docs/mantis/CR7884.md @@ -0,0 +1,423 @@ + + + + + + + + + + + + + 0007884: the current standard is not really specific on how records with port types as field work - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007884Part 01: TTCN-3 Core LanguageTechnicalpublic21-11-2019 10:5828-12-2019 15:55
ReporterKristóf Szabados 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version4.12.1 (published 2020-05) 
Clause Reference(s)many
Source (company - Author)TestCom ou
Summary0007884: the current standard is not really specific on how records with port types as field work
DescriptionIn previous versions of the TTCN-3 core standard it was not allowed to have a record field with component/port/timer as its type.
+This restriction is no longer present in the current latest version.
+
+But this leaves some situations in the current version ambiguous.
+For example:
+- There is no restriction on sending values of structured type that have a port as a field. But there is also no description on what sending a port through a network is supposed to mean.
+- In the usual case when a record variable is assigned a value of a second record variable, operations on the fields of the second variable are not expected to change fields of the first variable. But with ports this either has to change both variables (in case the port typed field is a reference), or there should be some description on copiing port.
+- The life of ports should also be clarified. As long as they were component members it was clear that they are created/initialized with the component, and die with the component ... but creating copies inside records and sending them around, might lead to confusion if not clarified.
+
+- There does not seem to be any restriction on using record type with port fields as in/out/inout message type of on a port ... but as creating templates of such type is not allowed the "?" in "someport.receive(?)..." becomes erroneous.
+etc...
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7884-1.docx (218,074) 16-12-2019 13:52
http://oldforge.etsi.org/mantis/file_download.php?file_id=3874&type=bug
docx CR7884-2.docx (255,004) 17-12-2019 10:04
http://oldforge.etsi.org/mantis/file_download.php?file_id=3881&type=bug
docx CR7884-3.docx (213,892) 17-12-2019 14:07
http://oldforge.etsi.org/mantis/file_download.php?file_id=3886&type=bug
Issue History
Date ModifiedUsernameFieldChange
21-11-2019 10:58Kristóf SzabadosNew Issue
21-11-2019 11:08Jacob Wieland - SpirentNote Added: 0015506
21-11-2019 11:57Jacob Wieland - SpirentNote Added: 0015507
12-12-2019 12:53Kristóf SzabadosNote Added: 0015509
16-12-2019 09:02Jens GrabowskiNote Added: 0015512
16-12-2019 09:02Jens GrabowskiAssigned To => Tomas Urban
16-12-2019 09:02Jens GrabowskiStatusnew => assigned
16-12-2019 13:52Tomas UrbanFile Added: CR7884-1.docx
16-12-2019 13:53Tomas UrbanNote Added: 0015526
16-12-2019 13:53Tomas UrbanAssigned ToTomas Urban => Kristóf Szabados
16-12-2019 13:53Tomas UrbanStatusassigned => confirmed
17-12-2019 08:46Jacob Wieland - SpirentNote Added: 0015535
17-12-2019 08:47Kristóf SzabadosNote Added: 0015536
17-12-2019 08:47Kristóf SzabadosStatusconfirmed => resolved
17-12-2019 08:47Kristóf SzabadosFixed in Version => 4.11.1 (published 2019-05)
17-12-2019 08:47Kristóf SzabadosResolutionopen => fixed
17-12-2019 08:47Kristóf SzabadosAssigned ToKristóf Szabados => Jens Grabowski
17-12-2019 08:54Jacob Wieland - SpirentAssigned ToJens Grabowski => Tomas Urban
17-12-2019 08:54Jacob Wieland - SpirentStatusresolved => feedback
17-12-2019 08:54Jacob Wieland - SpirentResolutionfixed => reopened
17-12-2019 08:54Jacob Wieland - SpirentStatusfeedback => assigned
17-12-2019 10:04Tomas UrbanFile Added: CR7884-2.docx
17-12-2019 10:05Tomas UrbanNote Added: 0015541
17-12-2019 10:05Tomas UrbanAssigned ToTomas Urban => Jacob Wieland - Spirent
17-12-2019 10:05Tomas UrbanStatusassigned => confirmed
17-12-2019 14:06Jacob Wieland - SpirentStatusconfirmed => new
17-12-2019 14:07Jacob Wieland - SpirentFile Added: CR7884-3.docx
17-12-2019 14:07Jacob Wieland - SpirentNote Added: 0015558
17-12-2019 14:07Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Kristóf Szabados
17-12-2019 14:07Jacob Wieland - SpirentStatusnew => confirmed
18-12-2019 07:17Kristóf SzabadosNote Added: 0015564
18-12-2019 07:17Kristóf SzabadosStatusconfirmed => resolved
18-12-2019 07:17Kristóf SzabadosResolutionreopened => fixed
18-12-2019 07:17Kristóf SzabadosAssigned ToKristóf Szabados => Gyorgy Rethy
28-12-2019 15:55Gyorgy RethyNote Added: 0015590
28-12-2019 15:55Gyorgy RethyStatusresolved => closed
28-12-2019 15:55Gyorgy RethyFixed in Version4.11.1 (published 2019-05) => 4.12.1 (published 2020-05)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015506) +
+ Jacob Wieland - Spirent    +
+ 21-11-2019 11:08    +
+ 		+ + + + +
+ As far as I know only data types can be sent/received and data types cannot contain port/component/object/default references.
+
+
+
+ + + + + + + + + + +
+ (0015507) +
+ Jacob Wieland - Spirent    +
+ 21-11-2019 11:57    +
+ 		+ + + + +
+ Hmm, somehow I can't find that definition or restrictions related to it anymore in the standard.
+
+In my recollection, a data type was a type that didn't contain reference types and only data types can be sent/received or used as parameters to functions started on other components.
+
+We should (re)introduce those definitions/restrictions again.
+
+
+
+ + + + + + + + + + +
+ (0015509) +
+ Kristóf Szabados    +
+ 12-12-2019 12:53    +
+ 		+ + + + +
+ Maybe the restrictions were removed by accident?
+For me it would sound ok if we could reintroduce them.
+
+
+
+ + + + + + + + + + +
+ (0015512) +
+ Jens Grabowski    +
+ 16-12-2019 09:02    +
+ 		+ + + + +
+ STF discussion: The restriction shall be reintroduced.
+
+
+
+ + + + + + + + + + +
+ (0015526) +
+ Tomas Urban    +
+ 16-12-2019 13:53    +
+ 		+ + + + +
+ Resolution uploaded, please check.
+
+
+
+ + + + + + + + + + +
+ (0015535) +
+ Jacob Wieland - Spirent    +
+ 17-12-2019 08:46    +
+ 		+ + + + +
+ I am not convinced that this is a good solution for several reasons:
+ 
+- You repeat the same list over and over and this will have to be amended for class types in the OO package.
+- the only exception are component references for the parameters of start-functions (how is it for component-call?)
+
+It would be easier to have two kinds of definitions: data-type (all except these reference types) and component data types that also allow components (these could also be allowed to be sent via inter-component communication). Then, we would only have to amend these two definitions in the OO package.
+
+
+
+ + + + + + + + + + +
+ (0015536) +
+ Kristóf Szabados    +
+ 17-12-2019 08:47    +
+ 		+ + + + +
+ Looks fine for me, can be included to the standard.
+
+
+
+ + + + + + + + + + +
+ (0015541) +
+ Tomas Urban    +
+ 17-12-2019 10:05    +
+ 		+ + + + +
+ Data types and component data types added to the CR. Please review.
+
+
+
+ + + + + + + + + + +
+ (0015558) +
+ Jacob Wieland - Spirent    +
+ 17-12-2019 14:07    +
+ 		+ + + + +
+ simplified the recursive definitions and removed components from parameters of testcases
+
+
+
+ + + + + + + + + + +
+ (0015564) +
+ Kristóf Szabados    +
+ 18-12-2019 07:17    +
+ 		+ + + + +
+ Looks good to me. Can be included in the standard.
+
+
+
+ + + + + + + + + + +
+ (0015590) +
+ Gyorgy Rethy    +
+ 28-12-2019 15:55    +
+ 		+ + + + +
+ Included in final draft V4.11.2
+
+ + diff --git a/docs/mantis/CR7890.md b/docs/mantis/CR7890.md new file mode 100644 index 0000000000000000000000000000000000000000..49c87d4bbda4dd6df96cb5feb0a5edfb0b9cbc4b --- /dev/null +++ b/docs/mantis/CR7890.md @@ -0,0 +1,175 @@ + + + + + + + + + + + + + 0007890: module parameters should behave like variables during control part execution - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007890Part 01: TTCN-3 Core LanguageNew Featurepublic11-12-2019 11:4514-08-2020 11:41
ReporterJacob Wieland - Spirent 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionwon't fix 
PlatformOSOS Version
Product Version4.11.1 (published 2019-05) 
Target VersionFixed in Version 
Clause Reference(s)8.2.1
Source (company - Author)Spirent - Jacob Wieland
Summary0007890: module parameters should behave like variables during control part execution
DescriptionModule parameters are supposed to be constant during a testcase execution.
+However, test management that allows the execution of multiple testcases allows changing module parameters between the exeuction of testcases.
+
+Maybe it could be allowed to treat module parameters as variables during the control execution so that the control part can assign new values before execution.
+
+An additional benefit of this comes into play in the following scenario.
+
+A library providing module parameters doesn't provide default values because it can be used in very different contexts so that no default parameter binding can be established. Thus, it would be beneficial if you could declare these parameters without defaults and in the different scenarios define initialization-control parts that fill the module parameters context-sensitive with proper defaults.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
11-12-2019 11:45Jacob Wieland - SpirentNew Issue
12-12-2019 12:50Kristóf SzabadosNote Added: 0015508
13-12-2019 10:07Jacob Wieland - SpirentNote Added: 0015510
16-12-2019 08:56Jens GrabowskiNote Added: 0015511
16-12-2019 08:57Jens GrabowskiAssigned To => Jens Grabowski
16-12-2019 08:57Jens GrabowskiStatusnew => assigned
14-08-2020 11:41Jens GrabowskiNote Added: 0015750
14-08-2020 11:41Jens GrabowskiStatusassigned => closed
14-08-2020 11:41Jens GrabowskiAssigned ToJens Grabowski => Gyorgy Rethy
14-08-2020 11:41Jens GrabowskiResolutionopen => won't fix
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015508) +
+ Kristóf Szabados    +
+ 12-12-2019 12:50    +
+ 		+ + + + +
+ For me module parameters were always about parameterising modules not testcases.
+So I would prefer to have module parameters behave as contants in the control part.
+
+
+
+ + + + + + + + + + +
+ (0015510) +
+ Jacob Wieland - Spirent    +
+ 13-12-2019 10:07    +
+ 		+ + + + +
+ What is the parameterization of modules for, though if not for usage inside testcases? We also want to parameterize the modules, but the parameterization should be possible to change between testcases, or at least, be flexible BEFORE the start of testcases.
+
+So, at least the initialization of module parameters inside the control part (especially those that have no default value) should be possible. That would already help immensely as then different control parts could initialize the module parameters differently before the start of testcases.
+
+
+
+ + + + + + + + + + +
+ (0015511) +
+ Jens Grabowski    +
+ 16-12-2019 08:56    +
+ 		+ + + + +
+ STF discussion: There are pros and cons for this proposal. The feature may be a candidate for the configuration and deployment package. To be revisited in 2020.
+
+
+
+ + + + + + + + + + +
+ (0015750) +
+ Jens Grabowski    +
+ 14-08-2020 11:41    +
+ 		+ + + + +
+ STF will not continue discussions on this CR.
+
+ + diff --git a/docs/mantis/CR7891.md b/docs/mantis/CR7891.md new file mode 100644 index 0000000000000000000000000000000000000000..e06e1f77f5663584e6453d6050529fb737db585c --- /dev/null +++ b/docs/mantis/CR7891.md @@ -0,0 +1,133 @@ + + + + + + + + + + + + + 0007891: Missing syntax rules for functions and altsteps in BNF - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007891Part 01: TTCN-3 Core LanguageTechnicalpublic17-12-2019 11:3828-12-2019 16:02
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version4.11.1 (published 2019-05) 
Target VersionFixed in Version4.12.1 (published 2020-05) 
Clause Reference(s)A.1.6.1
Source (company - Author)STF 573
Summary0007891: Missing syntax rules for functions and altsteps in BNF
DescriptionThe BNF doesn't contain a rule for @control modifier in external functions and interleave keyword in altstep definitions.
+
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7891-1.docx (179,332) 17-12-2019 11:50
http://oldforge.etsi.org/mantis/file_download.php?file_id=3884&type=bug
Issue History
Date ModifiedUsernameFieldChange
17-12-2019 11:38Tomas UrbanNew Issue
17-12-2019 11:38Tomas UrbanStatusnew => assigned
17-12-2019 11:38Tomas UrbanAssigned To => Tomas Urban
17-12-2019 11:50Tomas UrbanFile Added: CR7891-1.docx
17-12-2019 11:52Tomas UrbanNote Added: 0015546
17-12-2019 11:52Tomas UrbanAssigned ToTomas Urban => Jacob Wieland - Spirent
17-12-2019 11:52Tomas UrbanStatusassigned => confirmed
17-12-2019 13:44Jacob Wieland - SpirentNote Added: 0015555
17-12-2019 13:44Jacob Wieland - SpirentStatusconfirmed => resolved
17-12-2019 13:44Jacob Wieland - SpirentFixed in Version => 4.11.1 (published 2019-05)
17-12-2019 13:44Jacob Wieland - SpirentResolutionopen => fixed
17-12-2019 13:44Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Jens Grabowski
28-12-2019 16:01Gyorgy RethyAssigned ToJens Grabowski => Gyorgy Rethy
28-12-2019 16:02Gyorgy RethyNote Added: 0015591
28-12-2019 16:02Gyorgy RethyStatusresolved => closed
28-12-2019 16:02Gyorgy RethyFixed in Version4.11.1 (published 2019-05) => 4.12.1 (published 2020-05)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015546) +
+ Tomas Urban    +
+ 17-12-2019 11:52    +
+ 		+ + + + +
+ Resolution uploaded, please review.
+
+
+
+ + + + + + + + + + +
+ (0015555) +
+ Jacob Wieland - Spirent    +
+ 17-12-2019 13:44    +
+ 		+ + + + +
+ BNF now reflects the syntactical structure of the main part.
+
+
+
+ + + + + + + + + + +
+ (0015591) +
+ Gyorgy Rethy    +
+ 28-12-2019 16:02    +
+ 		+ + + + +
+ Included to final draft V4.11.2.
+
+ + diff --git a/docs/mantis/CR7892.md b/docs/mantis/CR7892.md new file mode 100644 index 0000000000000000000000000000000000000000..b93b737aaa067ac05b8d4314a47e3ae15158d3af --- /dev/null +++ b/docs/mantis/CR7892.md @@ -0,0 +1,145 @@ + + + + + + + + + + + + + 0007892: Allow modification of matching symbols on static template level - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007892Part 01: TTCN-3 Core LanguageTechnicalpublic23-01-2020 10:3615-12-2020 17:01
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version4.12.1 (published 2020-05) 
Target Version4.13.1 (ongoing)Fixed in Version4.13.1 (ongoing) 
Clause Reference(s)15.5
Source (company - Author)Elvior
Summary0007892: Allow modification of matching symbols on static template level
DescriptionModification of matching symbols is currently supported only in inline templates. Static templates can only modify already declared templates (the modify keyword has to be followed by a reference). I think this restriction is not justified and it should be possible to modify matching symbols in static template declarations too.
+
+Example:
+var template MyRec v_template := modifies ? := { field1 := 1; } // Allowed
+template MyRec mw_template modifies ? := { field1 := 1; } // Currently not allowed
+
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7892-1.docx (208,623) 12-08-2020 09:50
http://oldforge.etsi.org/mantis/file_download.php?file_id=3919&type=bug
Issue History
Date ModifiedUsernameFieldChange
23-01-2020 10:36Tomas UrbanNew Issue
24-01-2020 14:06Jacob Wieland - SpirentNote Added: 0015607
10-08-2020 11:09Jens GrabowskiAssigned To => Tomas Urban
10-08-2020 11:09Jens GrabowskiStatusnew => assigned
12-08-2020 09:30Tomas UrbanDescription Updatedbug_revision_view_page.php?rev_id=522#r522
12-08-2020 09:50Tomas UrbanFile Added: CR7892-1.docx
12-08-2020 09:54Tomas UrbanNote Added: 0015706
12-08-2020 09:54Tomas UrbanAssigned ToTomas Urban => Jacob Wieland - Spirent
12-08-2020 09:54Tomas UrbanStatusassigned => confirmed
12-08-2020 14:41Jacob Wieland - SpirentStatusconfirmed => resolved
12-08-2020 14:41Jacob Wieland - SpirentResolutionopen => fixed
12-08-2020 14:41Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
15-12-2020 17:01Gyorgy RethyNote Added: 0015860
15-12-2020 17:01Gyorgy RethyStatusresolved => closed
15-12-2020 17:01Gyorgy RethyFixed in Version => 4.13.1 (ongoing)
15-12-2020 17:01Gyorgy RethyTarget Version => 4.13.1 (ongoing)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015607) +
+ Jacob Wieland - Spirent    +
+ 24-01-2020 14:06    +
+ 		+ + + + +
+ TO be fair, I think that
+
+template MyRec mw_template := modifies ? := { field1 := 1 }
+
+is allowed.
+
+I agree though, that the other syntax should also be allowed.
+
+
+
+ + + + + + + + + + +
+ (0015706) +
+ Tomas Urban    +
+ 12-08-2020 09:54    +
+ 		+ + + + +
+ Resolution uploaded. I only modified the syntactical section adding BaseTemplateBody into it as an alternative option to the existing reference. They partially overlap, but not completely as BaseTemplateBody doesn't represent a reference to a parametrized template without a parameter list.
+
+Please check.
+
+
+
+ + + + + + + + + + +
+ (0015860) +
+ Gyorgy Rethy    +
+ 15-12-2020 17:01    +
+ 		+ + + + +
+ Implemented in draft 4.12.2
+
+ + diff --git a/docs/mantis/CR7893.md b/docs/mantis/CR7893.md new file mode 100644 index 0000000000000000000000000000000000000000..fd7fdd9f62aeaf88811c02b17617f2f048734e4d --- /dev/null +++ b/docs/mantis/CR7893.md @@ -0,0 +1,171 @@ + + + + + + + + + + + + + 0007893: Allow use of non-deterministic functions in alt-statement header - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007893Part 01: TTCN-3 Core LanguageNew Featurepublic24-01-2020 11:2516-12-2020 14:55
ReporterJacob Wieland - Spirent 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version4.12.1 (published 2020-05) 
Target Version4.13.1 (ongoing)Fixed in Version4.13.1 (ongoing) 
Clause Reference(s)20.2.
Source (company - Author)Spirent - Jacob Wieland
Summary0007893: Allow use of non-deterministic functions in alt-statement header
DescriptionAt the moment, inside alt-statements, no function can be invoked that is non-deterministic to preserve the alt-statement-snapshot semantics.
+
+However, it would sometimes be convenient to allow initialization of local alt-variables by use of nondeterministic (especially time-related) functions.
+As an alt-statement is needs to enter the snapshot-semantic only before the evaluation of alternatives, this would not violate the snapshot-semantic.
+
+The evaluation would be:
+1) Initialization of local-alt-variables
+2) Enter snapshot
+3) Evaluate alternatives
+4) Leave snapshot
+
+If the alt-statement is re-evaluated (either because of repeat or because no alternative was chosen), the whole process would be repeated, i.e. the local-alt-variables are re-initialized for every alt-cycle.
Steps To ReproduceConsider the following use case:
+
+We have messages that contain a timestamp in the form of a date-string.
+
+type charstring UTCTimestamp;
+
+And we have a functions
+
+external function f_currentTime() return integer;
+function f_convertToTimeMillis(UTCTimestamp p_timestamp) return integer { ... }
+
+And a template (advanced matching)
+
+template UTCTimestamp isCloseTo(integer timeMillis, int tolerance) := @dynamic {
+  return Math.abs(f_convertToTimeMillis(value) - timeMillis) <= tolerance
+}
+
+Now, we want to check whether the field of a message is close to a timestamp that is determined shortly before awaiting/expecting the message.
+
+alt {
+  var integer currentTime := f_getCurrentTime();
+[] p.receive(Message:{ ..., ts := isCloseTo(currentTime, 10) }) { ... }
+...
+}
+
+
+
+
Additional InformationThis feature is especially useful if the alt-statement uses repeat statements (otherwise, the assignments could simply be placed before the alt-statement).
+
+This feature would only be allowed for top-level alt-statements, not for altstep definitions. Alternatively, it could be allowed for altstep-definitions as well, but these altstep-definitions then shall only be usable for top-level invocations (not as alternative-headers in other alt-statements or altsteps).
TagsNo tags attached.
Relationships
Attached Filesdocx CR7893.docx (270,972) 12-08-2020 13:00
http://oldforge.etsi.org/mantis/file_download.php?file_id=3922&type=bug
docx CR7893-2.docx (327,153) 13-08-2020 10:29
http://oldforge.etsi.org/mantis/file_download.php?file_id=3933&type=bug
Issue History
Date ModifiedUsernameFieldChange
24-01-2020 11:25Jacob Wieland - SpirentNew Issue
10-08-2020 11:19Jens GrabowskiAssigned To => Jacob Wieland - Spirent
10-08-2020 11:19Jens GrabowskiStatusnew => assigned
10-08-2020 11:19Jens GrabowskiProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
12-08-2020 13:00Jacob Wieland - SpirentFile Added: CR7893.docx
12-08-2020 13:01Jacob Wieland - SpirentNote Added: 0015709
12-08-2020 13:01Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Tomas Urban
12-08-2020 13:01Jacob Wieland - SpirentStatusassigned => confirmed
13-08-2020 10:29Tomas UrbanFile Added: CR7893-2.docx
13-08-2020 10:31Tomas UrbanNote Added: 0015724
13-08-2020 10:31Tomas UrbanStatusconfirmed => resolved
13-08-2020 10:31Tomas UrbanResolutionopen => fixed
13-08-2020 10:31Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
16-12-2020 14:55Gyorgy RethyNote Added: 0015863
16-12-2020 14:55Gyorgy RethyStatusresolved => closed
16-12-2020 14:55Gyorgy RethyProduct Version => 4.12.1 (published 2020-05)
16-12-2020 14:55Gyorgy RethyFixed in Version => 4.13.1 (ongoing)
16-12-2020 14:55Gyorgy RethyTarget Version => 4.13.1 (ongoing)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015709) +
+ Jacob Wieland - Spirent    +
+ 12-08-2020 13:01    +
+ 		+ + + + +
+ added propoosal, please review
+
+
+
+ + + + + + + + + + +
+ (0015724) +
+ Tomas Urban    +
+ 13-08-2020 10:31    +
+ 		+ + + + +
+ I made a single font change in the draft. Otherwise, it looks good. The proposed change resolves the issue described in this CR and is ready to be added to the next version of the core language standard.
+
+
+
+ + + + + + + + + + +
+ (0015863) +
+ Gyorgy Rethy    +
+ 16-12-2020 14:55    +
+ 		+ + + + +
+ Implemented in draft 4.12.2
+
+ + diff --git a/docs/mantis/CR7910.md b/docs/mantis/CR7910.md new file mode 100644 index 0000000000000000000000000000000000000000..275078328b0dd903124a15d842c91cac5d308f1a --- /dev/null +++ b/docs/mantis/CR7910.md @@ -0,0 +1,420 @@ + + + + + + + + + + + + + 0007910: Allow parallel control parts/components - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007910Part 01: TTCN-3 Core LanguageNew Featurepublic13-02-2020 15:2623-11-2021 09:34
ReporterJacob Wieland - Spirent 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version4.12.1 (published 2020-05) 
Target Version4.13.1 (ongoing)Fixed in Version4.13.1 (ongoing) 
Clause Reference(s)8.3, 21.3
Source (company - Author)Spirent - Jacob Wieland
Summary0007910: Allow parallel control parts/components
DescriptionProposal:
+
+Allow creation of components (called maybe parallel control components or PCC) from a control component. The current main control part would run on the MCC (master control component).
+
+Example:
+
+control {
+  var ControlComponent pcc1 := ControlComponent.create;
+  var ControlComponent pcc2 := ControlComponent.create;
+  pcc1.start(f_start_testcase());
+  pcc2.start(f_start_mirror_testcase());
+  all component.done;
+}
+
+function @control f_start_testcase() {
+  execute(TC());
+}
+
+function @control f_start_mirror_testcase() {
+  execute(TC_mirror());
+}
+
+Semantics:
+
+Every parallel control part has the same semantics and capabilities as the current control part. Since there are no global variables in TTCN-3, there should be no interference between the testcases, so parallelization should not be an issue.
+ 
+The semantics of 'all component', 'any component' would need to be defined in the control context. It should refer only to the control components.
+Stopping and killing of control components should kill the testcase currently running on the component (if any).
+
+Intercomponent communication for synchronization purposes between control components could also be allowed (for instance if information needs to flow between the MCC and the PCCs).
+
+Even system communication could be allowed, e.g. when system resources need to be allocated globally for a parallel testcase run or other upper tester communication.
+
Steps To ReproduceUse cases:
+
+- running actual testcase and mock/mirror-testcase in parallel
+- running testcases in parallel to use system resources (multiple cores etc.) more efficiently and thus being able to produce test results faster
+
+Of course, only those testcases that don't interfere with each other (for instance by trying to use the same system ports) can be parallelized, but that is outside the scope of TTCN-3 (the same problem arises if you start multiple TTCN-3 tools in parallel).
Additional Information
TagsNo tags attached.
Relationships
related to 0007978closed Gyorgy Rethy Ext Pack: Config & Deployment Support (ES 202 781) Dealing with parallel control components 
Attached Filesdocx CR7910.docx (262,278) 13-08-2020 14:49
http://oldforge.etsi.org/mantis/file_download.php?file_id=3936&type=bug
Issue History
Date ModifiedUsernameFieldChange
13-02-2020 15:26Jacob Wieland - SpirentNew Issue
15-03-2020 13:58Kristóf SzabadosNote Added: 0015618
15-03-2020 14:01Kristóf SzabadosNote Added: 0015619
16-03-2020 11:40Jacob Wieland - SpirentNote Added: 0015620
10-08-2020 10:36Jens GrabowskiProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
10-08-2020 10:51Jens GrabowskiAssigned To => Jacob Wieland - Spirent
10-08-2020 10:51Jens GrabowskiStatusnew => assigned
13-08-2020 14:49Jacob Wieland - SpirentFile Added: CR7910.docx
13-08-2020 14:49Jacob Wieland - SpirentNote Added: 0015731
13-08-2020 14:49Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Tomas Urban
13-08-2020 14:49Jacob Wieland - SpirentStatusassigned => confirmed
13-08-2020 15:01Jacob Wieland - SpirentRelationship addedrelated to 0007978
14-08-2020 11:52Tomas UrbanAssigned ToTomas Urban => Jacob Wieland - Spirent
14-08-2020 11:52Tomas UrbanStatusconfirmed => assigned
14-08-2020 11:53Tomas UrbanNote Added: 0015751
09-10-2020 15:13Jacob Wieland - SpirentProjectPart 01: TTCN-3 Core Language => Ext Pack: Config & Deployment Support (ES 202 781)
07-12-2020 14:56Jacob Wieland - SpirentNote Added: 0015801
07-12-2020 14:56Jacob Wieland - SpirentStatusassigned => resolved
07-12-2020 14:56Jacob Wieland - SpirentResolutionopen => fixed
10-12-2020 09:27Jens GrabowskiAssigned ToJacob Wieland - Spirent => Jens Grabowski
10-12-2020 09:27Jens GrabowskiStatusresolved => assigned
10-12-2020 09:27Jens GrabowskiStatusassigned => resolved
17-12-2020 16:11Gyorgy RethyAssigned ToJens Grabowski => Gyorgy Rethy
17-12-2020 16:11Gyorgy RethyStatusresolved => assigned
17-12-2020 16:12Gyorgy RethyStatusassigned => resolved
17-12-2020 16:12Gyorgy RethyDescription Updatedbug_revision_view_page.php?rev_id=535#r535
17-12-2020 16:12Gyorgy RethySteps to Reproduce Updatedbug_revision_view_page.php?rev_id=537#r537
17-12-2020 17:19Gyorgy RethyProjectExt Pack: Config & Deployment Support (ES 202 781) => Part 01: TTCN-3 Core Language
17-12-2020 17:20Gyorgy RethyNote Added: 0015890
17-12-2020 17:20Gyorgy RethyStatusresolved => closed
17-12-2020 17:20Gyorgy RethyProduct Version => 4.12.1 (published 2020-05)
17-12-2020 17:20Gyorgy RethyFixed in Version => 4.13.1 (ongoing)
17-12-2020 17:20Gyorgy RethyTarget Version => 4.13.1 (ongoing)
17-12-2020 17:20Gyorgy RethyDescription Updatedbug_revision_view_page.php?rev_id=538#r538
17-12-2020 17:20Gyorgy RethyNote Edited: 0015890bug_revision_view_page.php?bugnote_id=15890#r540
09-09-2021 09:36Jens GrabowskiAssigned ToGyorgy Rethy => Jens Grabowski
09-09-2021 09:36Jens GrabowskiNote Added: 0015963
09-09-2021 09:36Jens GrabowskiStatusclosed => feedback
09-09-2021 09:36Jens GrabowskiResolutionfixed => reopened
10-09-2021 16:09Jacob Wieland - SpirentNote Added: 0015986
10-09-2021 16:09Jacob Wieland - SpirentStatusfeedback => assigned
10-09-2021 16:09Jacob Wieland - SpirentStatusassigned => resolved
10-09-2021 16:09Jacob Wieland - SpirentResolutionreopened => fixed
23-11-2021 09:34Jens GrabowskiNote Added: 0016090
23-11-2021 09:34Jens GrabowskiStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015618) +
+ Kristóf Szabados    +
+ 15-03-2020 13:58    +
+ 		+ + + + +
+ hmmm ... this make quite a big change in the language.
+We will need a new way of passing parameters to testcases, which are both in and out at the same time, but not inout as in that case both testcases could modify them at the same time.
+
+We might also need to introduce synchronization into the standard.
+It is right now taken as granted, that const and module parameters are read from only one place at one time ... being read in parallel might not be the same (if for example a tool vendor uses lazy initialization).
+
+
+
+ + + + + + + + + + +
+ (0015619) +
+ Kristóf Szabados    +
+ 15-03-2020 14:01    +
+ 		+ + + + +
+ This might also cause some practical issues, when already existing external functions (and other user implemented pieces of functionality) is not consistently updated before the first use.
+
+For example and external function used for acessing some efficient data structure, might no longer be safe to be used from parallel environments.
+There is so much already existing code of this kind, that need to think of this situation (most probably such codes will not be updated all at once).
+
+
+
+ + + + + + + + + + +
+ (0015620) +
+ Jacob Wieland - Spirent    +
+ 16-03-2020 11:40    +
+ 		+ + + + +
+ I don't see the parameter passing problems. Parameter passing should work the same way as now with a single control component. Every parallel control component can run at most one execute statement at a time as it is blocking and can pass only its own variables into possible inout/out parameters of the testcase, same as now. Other information flow should be done via ports between the components.
+
+As module parameters are to initialized deterministic, as far as I can remember (same for templates and constants), I also don't see the synchronization issue, though of course, we need to investigate that properly.
+
+To avoid synchronization issues of old external function implementations, a tool vendor could take a sort of sandbox approach where each parallel control component code runs on its own resources (similar to now where you would have to start two different processes if you want to run testcases in parallel).
+I would say, though, that this is beyond the scope of the standard and more of a tooling issue (as pretty much everything related to external function implementation is).
+
+
+
+ + + + + + + + + + +
+ (0015731) +
+ Jacob Wieland - Spirent    +
+ 13-08-2020 14:49    +
+ 		+ + + + +
+ added proposal for main part, please review
+
+
+
+ + + + + + + + + + +
+ (0015751) +
+ Tomas Urban    +
+ 14-08-2020 11:53    +
+ 		+ + + + +
+ Please move the feature to the configuration and deployment package.
+
+
+
+ + + + + + + + + + +
+ (0015801) +
+ Jacob Wieland - Spirent    +
+ 07-12-2020 14:56    +
+ 		+ + + + +
+ Is resolved in related issue 7978
+
+
+
+ + + + + + + + + + +
+ (0015890) +
+ Gyorgy Rethy    +
+ 17-12-2020 17:20    +
+ 		+ + + + +
+ Implemented in draft 4.12.3
+
+
+
+
+
+ + + + + + + + + + +
+ (0015963) +
+ Jens Grabowski    +
+ 09-09-2021 09:36    +
+ 		+ + + + +
+ CR has been mistakenly implemented in the wrong TTCN-3 part. Further discussion is needed.
+
+
+
+ + + + + + + + + + +
+ (0015986) +
+ Jacob Wieland - Spirent    +
+ 10-09-2021 16:09    +
+ 		+ + + + +
+ I have verified that the changes in the Core Language have been successfully reverted.
+
+
+
+ + + + + + + + + + +
+ (0016090) +
+ Jens Grabowski    +
+ 23-11-2021 09:34    +
+ 		+ + + + +
+ Document successfully reverted. The feature has already been implemented in the configuration and deployment extension
+
+ + diff --git a/docs/mantis/CR7911.md b/docs/mantis/CR7911.md new file mode 100644 index 0000000000000000000000000000000000000000..4b1d7c569bca81ec5ae7339bb424c4aa1929abbe --- /dev/null +++ b/docs/mantis/CR7911.md @@ -0,0 +1,149 @@ + + + + + + + + + + + + + 0007911: Correct TTCN-3 Parts list in Foreword - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007911Part 01: TTCN-3 Core LanguageEditorialpublic24-02-2020 15:4616-12-2020 16:13
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version4.11.1 (published 2019-05) 
Target Version4.13.1 (ongoing)Fixed in Version4.13.1 (ongoing) 
Clause Reference(s)Foreword
Source (company - Author)Ericsson AB
Summary0007911: Correct TTCN-3 Parts list in Foreword
DescriptionCurrently in the Foreword all parts are listed.
+
+Proposed:
+
+The present document is part 1 of a multi-part deliverable covering the Testing and Test Control Notation version 3, as identified below:
+Part 1: "TTCN-3 Core Language";
+Part 3: "TTCN-3 Graphical presentation Format (GFT)";
+Part 4: "TTCN-3 Operational Semantics";
+Part 5: "TTCN-3 Runtime Interface (TRI)";
+Part 6: "TTCN-3 Control Interface (TCI)";
+Part 7: "Using ASN.1 with TTCN-3";
+Part 8: "The IDL to TTCN-3 Mapping";
+Part 9: "Using XML schema with TTCN-3";
+Part 10: "TTCN-3 Documentation Comment Specification";
+Part 11: "Using JSON with TTCN-3".
+NOTE 1: Part 2: "TTCN-3 Tabular presentation Format (TFT)" of this multi-part deliverable is in status "historical".
+Note 2: Part 3 of this multi-part deliverable is not maintained.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx es_20187301v041201p-0007911.docx (193,836) 11-08-2020 12:06
http://oldforge.etsi.org/mantis/file_download.php?file_id=3909&type=bug
Issue History
Date ModifiedUsernameFieldChange
24-02-2020 15:46Gyorgy RethyNew Issue
10-08-2020 11:07Jens GrabowskiAssigned To => Axel Rennoch (old account)
10-08-2020 11:07Jens GrabowskiStatusnew => assigned
10-08-2020 17:04Axel RennochAssigned ToAxel Rennoch (old account) => Axel Rennoch
11-08-2020 12:06Axel RennochNote Added: 0015686
11-08-2020 12:06Axel RennochFile Added: es_20187301v041201p-0007911.docx
11-08-2020 12:08Axel RennochNote Added: 0015688
11-08-2020 12:08Axel RennochAssigned ToAxel Rennoch => Jens Grabowski
11-08-2020 12:08Axel RennochStatusassigned => acknowledged
11-08-2020 13:27Axel RennochStatusacknowledged => confirmed
14-08-2020 08:35Jens GrabowskiStatusconfirmed => resolved
14-08-2020 08:35Jens GrabowskiResolutionopen => fixed
14-08-2020 08:35Jens GrabowskiAssigned ToJens Grabowski => Gyorgy Rethy
16-12-2020 16:13Gyorgy RethyNote Added: 0015868
16-12-2020 16:13Gyorgy RethyStatusresolved => closed
16-12-2020 16:13Gyorgy RethyFixed in Version => 4.13.1 (ongoing)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015686) +
+ Axel Rennoch    +
+ 11-08-2020 12:06    +
+ 		+ + + + +
+ The proposed listing and notes have been copied to the Foreword.
+
+The Informative references have been extended with the missing older versions of ETSI ES 201 873-1.
+
+
+
+ + + + + + + + + + +
+ (0015688) +
+ Axel Rennoch    +
+ 11-08-2020 12:08    +
+ 		+ + + + +
+ Proposed changes have been done and should be confirmed.
+
+
+
+ + + + + + + + + + +
+ (0015868) +
+ Gyorgy Rethy    +
+ 16-12-2020 16:13    +
+ 		+ + + + +
+ Implemented in draft 4.12.2
+
+ + diff --git a/docs/mantis/CR7912.md b/docs/mantis/CR7912.md new file mode 100644 index 0000000000000000000000000000000000000000..94bafc21ea148170601916ffc93155c346b9ed3d --- /dev/null +++ b/docs/mantis/CR7912.md @@ -0,0 +1,135 @@ + + + + + + + + + + + + + 0007912: Missing reference - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Advanced Parametrization (ES 202 784)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007912Ext Pack: Advanced Parametrization (ES 202 784)Editorialpublic27-02-2020 12:2018-12-2020 14:54
ReporterGyorgy Rethy 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv1.7.1 (published 2020-05) 
Target Versionv1.8.1 (ongoing)Fixed in Versionv1.8.1 (ongoing) 
TS versionV1.6.1
Clause Reference(s)Normative References, Foreword
Source (company - Author)Ericsson AB
Summary0007912: Missing reference
Description1) V1.6.1 introduced amendments to ES 202 790, but this language extension is missing in the Normative References clause. Add ES 202 790 to the references.
+
+2) As this extension contains extensions to both ES 202 789 and ES 202 790, the relation of this extension and the two other extensions should be mentioned in the Foreword.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx es_202784v010701p-0007912.docx (236,791) 11-08-2020 10:58
http://oldforge.etsi.org/mantis/file_download.php?file_id=3908&type=bug
Issue History
Date ModifiedUsernameFieldChange
27-02-2020 12:20Gyorgy RethyNew Issue
10-08-2020 11:07Jens GrabowskiAssigned To => Axel Rennoch
10-08-2020 11:07Jens GrabowskiStatusnew => assigned
11-08-2020 10:57Axel RennochNote Added: 0015681
11-08-2020 10:58Axel RennochFile Added: es_202784v010701p-0007912.docx
11-08-2020 11:17Axel RennochNote Added: 0015683
11-08-2020 11:17Axel RennochAssigned ToAxel Rennoch => Jens Grabowski
11-08-2020 11:17Axel RennochStatusassigned => acknowledged
11-08-2020 13:26Axel RennochStatusacknowledged => confirmed
14-08-2020 07:44Jens GrabowskiStatusconfirmed => resolved
14-08-2020 07:44Jens GrabowskiResolutionopen => fixed
14-08-2020 07:44Jens GrabowskiAssigned ToJens Grabowski => Gyorgy Rethy
18-12-2020 14:54Gyorgy RethyNote Added: 0015892
18-12-2020 14:54Gyorgy RethyStatusresolved => closed
18-12-2020 14:54Gyorgy RethyProduct Versionv1.6.1 (published 2017-04) => v1.7.1 (published 2020-05)
18-12-2020 14:54Gyorgy RethyFixed in Version => v1.8.1 (ongoing)
18-12-2020 14:54Gyorgy RethyTarget Version => v1.8.1 (ongoing)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015681) +
+ Axel Rennoch    +
+ 11-08-2020 10:57    +
+ 		+ + + + +
+ ad 1) In V1.7.1 the reference to ES 203 790 is already present in the Norvative References clause
+
+ad 2) The Foreword has been extended with a list of the different parts of 201 873 (similar to the Foreword in ETSI ES 202 781) and the two affected extensions.
+
+
+
+ + + + + + + + + + +
+ (0015683) +
+ Axel Rennoch    +
+ 11-08-2020 11:17    +
+ 		+ + + + +
+ Extended Foreword need to be discussed/confirmed.
+
+
+
+ + + + + + + + + + +
+ (0015892) +
+ Gyorgy Rethy    +
+ 18-12-2020 14:54    +
+ 		+ + + + +
+ Implemented in draft 1.7.2
+
+ + diff --git a/docs/mantis/CR7913.md b/docs/mantis/CR7913.md new file mode 100644 index 0000000000000000000000000000000000000000..76d383f7499e6f52f06f2c8d8837cc5722b5a9df --- /dev/null +++ b/docs/mantis/CR7913.md @@ -0,0 +1,279 @@ + + + + + + + + + + + + + 0007913: conflicting examples for solidus encoding - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 11: Using JSON with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007913Part 11: Using JSON with TTCN-3[TTCN-3 Change Requests] Editorialpublic05-03-2020 06:0317-12-2020 15:29
ReporterKristóf Szabados 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product VersionV4.8.1 (published 2020-05) 
Target VersionV4.9.1 (ongoing)Fixed in VersionV4.9.1 (ongoing) 
Summary0007913: conflicting examples for solidus encoding
DescriptionThe example in section 6.4.2 for encoding the solidus character with "escape as usi" variant shows:
+"ab/cd" | "ab/cd" | 2261622F636422 | JSON doesn't require to escape the solidus character
+
+But the example in Annex A shows:
+const JSON.String_usi cu_sol := "/"; // encoded as "\u002F" (Solidus or Slash)
+
+It might happen that JSON does not require the escaping of the solidus, but from a didactical point of view:
+- either the first example should also show an example of the escaped version (to give a consistent view with the end example)
+- or in the end example also point out that there are 2 equally valid ways to encode the solidus character.
+
+Right now the standard sounds confusing, becuse the annex clearly chooses 1 way of encoding, yet 6.4.2 sound to imply that the standard is not choosing 1 way of encoding.
Steps To Reproduce
Additional InformationI was looking at version v4.8.1 (2018-05) available from www.ttcn-3.org
TagsNo tags attached.
Relationships
Attached Filesdocx CR_7913.docx (156,117) 10-08-2020 19:20
http://oldforge.etsi.org/mantis/file_download.php?file_id=3903&type=bug
docx CR_7913_v2.docx (154,710) 11-08-2020 15:28
http://oldforge.etsi.org/mantis/file_download.php?file_id=3913&type=bug
Issue History
Date ModifiedUsernameFieldChange
05-03-2020 06:03Kristóf SzabadosNew Issue
10-08-2020 11:05Jens GrabowskiAssigned To => Kristóf Szabados
10-08-2020 11:05Jens GrabowskiStatusnew => assigned
10-08-2020 19:20Kristóf SzabadosFile Added: CR_7913.docx
10-08-2020 19:21Kristóf SzabadosNote Added: 0015674
11-08-2020 10:11Kristóf SzabadosNote Added: 0015675
11-08-2020 10:12Kristóf SzabadosAssigned ToKristóf Szabados => Jacob Wieland - Spirent
11-08-2020 12:06Jacob Wieland - SpirentNote Added: 0015687
11-08-2020 12:06Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Kristóf Szabados
11-08-2020 12:33Kristóf SzabadosNote Added: 0015692
11-08-2020 15:28Kristóf SzabadosFile Added: CR_7913_v2.docx
11-08-2020 15:29Kristóf SzabadosNote Added: 0015697
11-08-2020 15:29Kristóf SzabadosAssigned ToKristóf Szabados => Jacob Wieland - Spirent
11-08-2020 15:43Jacob Wieland - SpirentNote Added: 0015698
11-08-2020 15:43Jacob Wieland - SpirentStatusassigned => resolved
11-08-2020 15:43Jacob Wieland - SpirentResolutionopen => fixed
11-08-2020 15:43Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
17-12-2020 15:29Gyorgy RethyNote Added: 0015887
17-12-2020 15:29Gyorgy RethyStatusresolved => closed
17-12-2020 15:29Gyorgy RethyFixed in Version => V4.9.1 (ongoing)
17-12-2020 15:29Gyorgy RethyTarget Version => V4.9.1 (ongoing)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015674) +
+ Kristóf Szabados    +
+ 10-08-2020 19:21    +
+ 		+ + + + +
+ updated example to show escaped form consistent with example in annex.
+
+
+
+ + + + + + + + + + +
+ (0015675) +
+ Kristóf Szabados    +
+ 11-08-2020 10:11    +
+ 		+ + + + +
+ please review
+
+
+
+ + + + + + + + + + +
+ (0015687) +
+ Jacob Wieland - Spirent    +
+ 11-08-2020 12:06    +
+ 		+ + + + +
+ the changed commment isn't gramatically correct, I have no idea what it means.
+
+
+
+ + + + + + + + + + +
+ (0015692) +
+ Kristóf Szabados    +
+ 11-08-2020 12:33    +
+ 		+ + + + +
+ Would it be better to phrase it like this?
+
+Escaped solidus character (escaping solidus is optional in JSON)
+
+
+
+ + + + + + + + + + +
+ (0015697) +
+ Kristóf Szabados    +
+ 11-08-2020 15:29    +
+ 		+ + + + +
+ changed comment. please review.
+
+
+
+ + + + + + + + + + +
+ (0015698) +
+ Jacob Wieland - Spirent    +
+ 11-08-2020 15:43    +
+ 		+ + + + +
+ ok, fine
+
+
+
+ + + + + + + + + + +
+ (0015887) +
+ Gyorgy Rethy    +
+ 17-12-2020 15:29    +
+ 		+ + + + +
+ Implemented in draft 4.8.2
+
+ + diff --git a/docs/mantis/CR7914.md b/docs/mantis/CR7914.md new file mode 100644 index 0000000000000000000000000000000000000000..a7b6fda0aecb46887b430311ac0620387ac0086c --- /dev/null +++ b/docs/mantis/CR7914.md @@ -0,0 +1,244 @@ + + + + + + + + + + + + + 0007914: conflicting definition and examples for usi encoding - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 11: Using JSON with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007914Part 11: Using JSON with TTCN-3[TTCN-3 Change Requests] Editorialpublic05-03-2020 06:0823-12-2020 13:59
ReporterKristóf Szabados 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product VersionV4.8.1 (published 2020-05) 
Target VersionV4.9.1 (ongoing)Fixed in VersionV4.9.1 (ongoing) 
Summary0007914: conflicting definition and examples for usi encoding
DescriptionSection B.3.7 clearly states that using the "escape as usi" encoding instruction, all characters in the TTCN-3 value shall be encoded using the USI-like escape sequence "\u<HHHH>"
+
+Yet the example for "escape as usi" in section 6.4.2 clearly show that only special characters need to encoded like that.
+None of the examples uses the \u<HHHH> format for the abcd letters.
Steps To Reproduce
Additional InformationI was looking at version v4.8.1 (2018-05)
TagsNo tags attached.
Relationships
Attached Filesdocx CR_7914.docx (150,351) 06-10-2020 11:08
http://oldforge.etsi.org/mantis/file_download.php?file_id=3956&type=bug
docx CR_7914_v2.docx (150,303) 08-10-2020 14:35
http://oldforge.etsi.org/mantis/file_download.php?file_id=3960&type=bug
Issue History
Date ModifiedUsernameFieldChange
05-03-2020 06:08Kristóf SzabadosNew Issue
10-08-2020 11:02Jens GrabowskiAssigned To => Kristóf Szabados
10-08-2020 11:02Jens GrabowskiStatusnew => assigned
24-08-2020 11:31Gyorgy RethyNote Added: 0015753
06-10-2020 11:08Kristóf SzabadosFile Added: CR_7914.docx
06-10-2020 11:09Kristóf SzabadosNote Added: 0015759
06-10-2020 13:47Jens GrabowskiAssigned ToKristóf Szabados => Jacob Wieland - Spirent
06-10-2020 14:15Jacob Wieland - SpirentNote Added: 0015762
06-10-2020 14:16Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Kristóf Szabados
08-10-2020 14:35Kristóf SzabadosFile Added: CR_7914_v2.docx
08-10-2020 14:35Kristóf SzabadosNote Added: 0015781
08-10-2020 14:36Kristóf SzabadosAssigned ToKristóf Szabados => Jacob Wieland - Spirent
08-10-2020 14:36Kristóf SzabadosStatusassigned => confirmed
08-10-2020 15:43Jacob Wieland - SpirentNote Added: 0015783
08-10-2020 15:43Jacob Wieland - SpirentStatusconfirmed => resolved
08-10-2020 15:43Jacob Wieland - SpirentResolutionopen => fixed
08-10-2020 15:43Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Jens Grabowski
17-12-2020 14:30Gyorgy RethyNote Added: 0015883
17-12-2020 14:30Gyorgy RethyStatusresolved => closed
17-12-2020 14:30Gyorgy RethyFixed in Version => V4.9.1 (ongoing)
17-12-2020 14:30Gyorgy RethyTarget Version => V4.9.1 (ongoing)
23-12-2020 13:59Jens GrabowskiAssigned ToJens Grabowski => Gyorgy Rethy
23-12-2020 13:59Jens GrabowskiStatusclosed => assigned
23-12-2020 13:59Jens GrabowskiStatusassigned => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015753) +
+ Gyorgy Rethy    +
+ 24-08-2020 11:31    +
+ 		+ + + + +
+ Actually, I think clause 6.4.2 is correct and B.3.7 should be amended. The intension of the encoding instruction is not forcing the replacement of "normal" characters with their escape codes, but rather enable to control which way of escaping to use, IF a character is being escaped.
+
+BUT, to provide a backward compatible correction, tool implementations should be checked and choose the solution, which majority of the tools support.
+
+
+
+ + + + + + + + + + +
+ (0015759) +
+ Kristóf Szabados    +
+ 06-10-2020 11:09    +
+ 		+ + + + +
+ Uploaded initial proposal.
+
+
+
+ + + + + + + + + + +
+ (0015762) +
+ Jacob Wieland - Spirent    +
+ 06-10-2020 14:15    +
+ 		+ + + + +
+ I would also think that only those characters that MUST be escaped should be escaped:
+
+From the standard:
+
+except for the characters that must be escaped:
+   quotation mark, reverse solidus, and the control characters (U+0000
+   through U+001F)
+
+
+
+ + + + + + + + + + +
+ (0015781) +
+ Kristóf Szabados    +
+ 08-10-2020 14:35    +
+ 		+ + + + +
+ re-phrased accordingly. Please check.
+
+
+
+ + + + + + + + + + +
+ (0015783) +
+ Jacob Wieland - Spirent    +
+ 08-10-2020 15:43    +
+ 		+ + + + +
+ fine with me
+
+
+
+ + + + + + + + + + +
+ (0015883) +
+ Gyorgy Rethy    +
+ 17-12-2020 14:30    +
+ 		+ + + + +
+ Implemented in draft 4.8.2
+
+ + diff --git a/docs/mantis/CR7915.md b/docs/mantis/CR7915.md new file mode 100644 index 0000000000000000000000000000000000000000..a62455aaf89c7ad19aa6f817d395bc7e0c29b2b8 --- /dev/null +++ b/docs/mantis/CR7915.md @@ -0,0 +1,141 @@ + + + + + + + + + + + + + 0007915: Wrong field older in the example union - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 11: Using JSON with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007915Part 11: Using JSON with TTCN-3[TTCN-3 Change Requests] Editorialpublic05-03-2020 06:2017-12-2020 15:36
ReporterKristóf Szabados 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product VersionV4.8.1 (published 2020-05) 
Target VersionV4.9.1 (ongoing)Fixed in VersionV4.9.1 (ongoing) 
Summary0007915: Wrong field older in the example union
DescriptionThe "Values" union in Annex A. has its fields in a possibly incorrect order.
+
+The field "int" shoud be preceeding field "num" otherwise all integers will be decoded as Number -s. Making the "int" field effectively unreachable/unsuable.
+
+The same goes for the fields "numArray" and "intArray"
+
+Also the field "array" should be after all other array fields.
+With the current description all array (even the ones where all elements are of the same type, like integers) will be decoded as generic array, making the "strArray", "numArray", "intArray", "boolArray", "objArray" unreachable/useless.
+
+Please note the same union data type is present in section 6.4.3 too.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR_7915.docx (154,908) 11-08-2020 10:44
http://oldforge.etsi.org/mantis/file_download.php?file_id=3905&type=bug
Issue History
Date ModifiedUsernameFieldChange
05-03-2020 06:20Kristóf SzabadosNew Issue
10-08-2020 10:59Jens GrabowskiAssigned To => Kristóf Szabados
10-08-2020 10:59Jens GrabowskiStatusnew => assigned
11-08-2020 10:44Kristóf SzabadosFile Added: CR_7915.docx
11-08-2020 10:45Kristóf SzabadosNote Added: 0015679
11-08-2020 10:45Kristóf SzabadosAssigned ToKristóf Szabados => Jacob Wieland - Spirent
11-08-2020 12:00Jacob Wieland - SpirentNote Added: 0015685
11-08-2020 12:00Jacob Wieland - SpirentStatusassigned => resolved
11-08-2020 12:00Jacob Wieland - SpirentResolutionopen => fixed
11-08-2020 12:00Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
17-12-2020 15:36Gyorgy RethyNote Added: 0015888
17-12-2020 15:36Gyorgy RethyStatusresolved => closed
17-12-2020 15:36Gyorgy RethyFixed in Version => V4.9.1 (ongoing)
17-12-2020 15:36Gyorgy RethyTarget Version => V4.9.1 (ongoing)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015679) +
+ Kristóf Szabados    +
+ 11-08-2020 10:45    +
+ 		+ + + + +
+ fixed field orders.
+please review.
+
+
+
+ + + + + + + + + + +
+ (0015685) +
+ Jacob Wieland - Spirent    +
+ 11-08-2020 12:00    +
+ 		+ + + + +
+ seems fine
+
+
+
+ + + + + + + + + + +
+ (0015888) +
+ Gyorgy Rethy    +
+ 17-12-2020 15:36    +
+ 		+ + + + +
+ Implemented in draft 4.8.2
+
+ + diff --git a/docs/mantis/CR7916.md b/docs/mantis/CR7916.md new file mode 100644 index 0000000000000000000000000000000000000000..e5552d1f76ea32d5a083c9818960d669d2dc2edc --- /dev/null +++ b/docs/mantis/CR7916.md @@ -0,0 +1,140 @@ + + + + + + + + + + + + + 0007916: The name "Values" does not seem to follow the naming convention of other types - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 11: Using JSON with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007916Part 11: Using JSON with TTCN-3[TTCN-3 Change Requests] Editorialpublic05-03-2020 06:2817-12-2020 15:40
ReporterKristóf Szabados 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product VersionV4.8.1 (published 2020-05) 
Target VersionV4.9.1 (ongoing)Fixed in VersionV4.9.1 (ongoing) 
Summary0007916: The name "Values" does not seem to follow the naming convention of other types
DescriptionAnnex A lists Types to define JSON Schemas.
+
+In this list the only type with a name in plural form is the "Values" type.
+
+This does not look like fitting into the naming convention all other types follow.
+- for type representing a single value that is also a simple value singular form is used (ex. Number, Integer, etc..)
+- for type representing a single value that can have several fields/elements the same singular form is used (ex. array, BoolArray, Object)
+
+It would follow logically, that as the "Values" union is also always representing a single value it sohuld also have a name in singular form.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR_7916.docx (149,766) 11-08-2020 10:57
http://oldforge.etsi.org/mantis/file_download.php?file_id=3907&type=bug
Issue History
Date ModifiedUsernameFieldChange
05-03-2020 06:28Kristóf SzabadosNew Issue
10-08-2020 10:57Jens GrabowskiAssigned To => Kristóf Szabados
10-08-2020 10:57Jens GrabowskiStatusnew => assigned
11-08-2020 10:57Kristóf SzabadosFile Added: CR_7916.docx
11-08-2020 10:57Kristóf SzabadosNote Added: 0015682
11-08-2020 10:57Kristóf SzabadosAssigned ToKristóf Szabados => Jacob Wieland - Spirent
11-08-2020 11:55Jacob Wieland - SpirentStatusassigned => confirmed
11-08-2020 11:57Jacob Wieland - SpirentNote Added: 0015684
11-08-2020 11:57Jacob Wieland - SpirentStatusconfirmed => resolved
11-08-2020 11:57Jacob Wieland - SpirentResolutionopen => fixed
11-08-2020 11:57Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
17-12-2020 15:40Gyorgy RethyNote Added: 0015889
17-12-2020 15:40Gyorgy RethyStatusresolved => closed
17-12-2020 15:40Gyorgy RethyFixed in Version => V4.9.1 (ongoing)
17-12-2020 15:40Gyorgy RethyTarget Version => V4.9.1 (ongoing)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015682) +
+ Kristóf Szabados    +
+ 11-08-2020 10:57    +
+ 		+ + + + +
+ I have added the singular synonym.
+please review.
+
+
+
+ + + + + + + + + + +
+ (0015684) +
+ Jacob Wieland - Spirent    +
+ 11-08-2020 11:57    +
+ 		+ + + + +
+ seems fine to me
+
+
+
+ + + + + + + + + + +
+ (0015889) +
+ Gyorgy Rethy    +
+ 17-12-2020 15:40    +
+ 		+ + + + +
+ Implemented in draft 4.8.2
+
+ + diff --git a/docs/mantis/CR7917.md b/docs/mantis/CR7917.md new file mode 100644 index 0000000000000000000000000000000000000000..ae59159590c80af6334600b4eab8741bac8f74f2 --- /dev/null +++ b/docs/mantis/CR7917.md @@ -0,0 +1,137 @@ + + + + + + + + + + + + + 0007917: please add an example for number forbidden in JSON - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 11: Using JSON with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007917Part 11: Using JSON with TTCN-3[TTCN-3 Change Requests] Clarificationpublic05-03-2020 16:1417-12-2020 15:24
ReporterKristóf Szabados 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product VersionV4.8.1 (published 2020-05) 
Target VersionV4.9.1 (ongoing)Fixed in VersionV4.9.1 (ongoing) 
Summary0007917: please add an example for number forbidden in JSON
DescriptionIn section B.3.7 it is written that the "escapse as" encoding instruction is applicable to types and fields JSON.Number types.
+But there is no example for such an escaping.
+
+Also section 6.4.1 "JSON Numbers" does not list the "escape as ..." encoding instruction as applicable.
+
+Is there really a number that is forbidden in JSON?
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR_7917.docx (143,602) 11-08-2020 12:29
http://oldforge.etsi.org/mantis/file_download.php?file_id=3911&type=bug
Issue History
Date ModifiedUsernameFieldChange
05-03-2020 16:14Kristóf SzabadosNew Issue
10-08-2020 10:54Jens GrabowskiAssigned To => Kristóf Szabados
10-08-2020 10:54Jens GrabowskiStatusnew => assigned
11-08-2020 12:29Kristóf SzabadosFile Added: CR_7917.docx
11-08-2020 12:30Kristóf SzabadosNote Added: 0015691
11-08-2020 12:30Kristóf SzabadosAssigned ToKristóf Szabados => Jacob Wieland - Spirent
11-08-2020 15:52Jacob Wieland - SpirentNote Added: 0015700
11-08-2020 15:52Jacob Wieland - SpirentStatusassigned => resolved
11-08-2020 15:52Jacob Wieland - SpirentResolutionopen => fixed
11-08-2020 15:52Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
17-12-2020 15:24Gyorgy RethyNote Added: 0015886
17-12-2020 15:24Gyorgy RethyStatusresolved => closed
17-12-2020 15:24Gyorgy RethyFixed in Version => V4.9.1 (ongoing)
17-12-2020 15:24Gyorgy RethyTarget Version => V4.9.1 (ongoing)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015691) +
+ Kristóf Szabados    +
+ 11-08-2020 12:30    +
+ 		+ + + + +
+ modified so that "escape as" is only applicable to strings.
+Please check.
+
+
+
+ + + + + + + + + + +
+ (0015700) +
+ Jacob Wieland - Spirent    +
+ 11-08-2020 15:52    +
+ 		+ + + + +
+ ok
+
+
+
+ + + + + + + + + + +
+ (0015886) +
+ Gyorgy Rethy    +
+ 17-12-2020 15:24    +
+ 		+ + + + +
+ Implemented in draft 4.8.2
+
+ + diff --git a/docs/mantis/CR7919.md b/docs/mantis/CR7919.md new file mode 100644 index 0000000000000000000000000000000000000000..c8999f33f047c986a50a187def62d310beea067e --- /dev/null +++ b/docs/mantis/CR7919.md @@ -0,0 +1,144 @@ + + + + + + + + + + + + + 0007919: testcase should be possible to be defined without runs on - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007919Part 01: TTCN-3 Core LanguageNew Featurepublic13-03-2020 10:3516-12-2020 14:31
ReporterJacob Wieland - Spirent 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version4.12.1 (published 2020-05) 
Target Version4.13.1 (ongoing)Fixed in Version4.13.1 (ongoing) 
Clause Reference(s)16.3, A.1.6.1.6
Source (company - Author)Spirent - Jacob Wieland
Summary0007919: testcase should be possible to be defined without runs on
DescriptionWhen writing testcases where the main test component doesn't use any component variables or ports, it would be convenient if it were possible to leave out the runs on clause.
+
+For unit tests or tests where the mtc just starts a lot of ptcs and waits for them, it is often necessary to write this pattern:
+
+type component C {}
+
+testcase T() runs on C { ... }
+
+The same restrictions shall apply as if an empty component type was declared in a runs on clause.
+
+As there is clearly no gain from this, it should be allowed to define this instead of like this:
+
+testcase T() { ... }
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7919-1.docx (185,476) 12-08-2020 09:25
http://oldforge.etsi.org/mantis/file_download.php?file_id=3918&type=bug
Issue History
Date ModifiedUsernameFieldChange
13-03-2020 10:35Jacob Wieland - SpirentNew Issue
15-03-2020 13:52Kristóf SzabadosNote Added: 0015617
10-08-2020 10:52Jens GrabowskiAssigned To => Tomas Urban
10-08-2020 10:52Jens GrabowskiStatusnew => assigned
10-08-2020 11:20Jens GrabowskiProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
12-08-2020 09:25Tomas UrbanFile Added: CR7919-1.docx
12-08-2020 09:28Tomas UrbanNote Added: 0015705
12-08-2020 09:28Tomas UrbanAssigned ToTomas Urban => Jacob Wieland - Spirent
12-08-2020 09:28Tomas UrbanStatusassigned => confirmed
12-08-2020 14:48Jacob Wieland - SpirentStatusconfirmed => resolved
12-08-2020 14:48Jacob Wieland - SpirentResolutionopen => fixed
12-08-2020 14:48Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
16-12-2020 14:31Gyorgy RethyNote Added: 0015861
16-12-2020 14:31Gyorgy RethyStatusresolved => closed
16-12-2020 14:31Gyorgy RethyProduct Version => 4.12.1 (published 2020-05)
16-12-2020 14:31Gyorgy RethyFixed in Version => 4.13.1 (ongoing)
16-12-2020 14:31Gyorgy RethyTarget Version => 4.13.1 (ongoing)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015617) +
+ Kristóf Szabados    +
+ 15-03-2020 13:52    +
+ 		+ + + + +
+ Sound reasonable.
+We could just say, that if the runs on clause is missing, the testcase is implicitly taken as if running on an empty component.
+
+
+
+ + + + + + + + + + +
+ (0015705) +
+ Tomas Urban    +
+ 12-08-2020 09:28    +
+ 		+ + + + +
+ Resolution uploaded. Please check.
+
+
+
+ + + + + + + + + + +
+ (0015861) +
+ Gyorgy Rethy    +
+ 16-12-2020 14:31    +
+ 		+ + + + +
+ Implemented in draft 4.12.2
+
+ + diff --git a/docs/mantis/CR7920.md b/docs/mantis/CR7920.md new file mode 100644 index 0000000000000000000000000000000000000000..627a3ee2b6b0c0e55cc633c58a85714d19aafff3 --- /dev/null +++ b/docs/mantis/CR7920.md @@ -0,0 +1,171 @@ + + + + + + + + + + + + + 0007920: Clarification request: how should equality/inequality work for objects? - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Object-oriented features (ES 203 790)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007920Ext Pack: Object-oriented features (ES 203 790)[All Projects] Generalpublic09-04-2020 09:1228-12-2020 11:09
ReporterKristóf Szabados 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product VersionV1.2.1 (published 2020-05) 
Target VersionV1.3.1 (ongoing)Fixed in Version 
Summary0007920: Clarification request: how should equality/inequality work for objects?
DescriptionAccording to the currently available version of the OO extension (v1.1.1) the equality/inequality operators can be used with object instances, but only to check if they are null or not.
+"An object variable or parameter may be compared with the special value null with the equality and inequality operators or can be assigned the special value null explicitly."
+
+It would be benefitial if objects could be compared.
+Also it should be done by their references to see if two object instances are actually the same.
+
+But comparing based on members (like done for record/set and other types) should not work for objects. Since objects of very different types might have the same member fields and function names, but very different operational semantics described within those functions.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7920.docx (131,696) 11-08-2020 10:10
http://oldforge.etsi.org/mantis/file_download.php?file_id=3904&type=bug
Issue History
Date ModifiedUsernameFieldChange
09-04-2020 09:12Kristóf SzabadosNew Issue
14-04-2020 12:31Kristóf SzabadosSummaryClarification request: who should equality/inequality work for objects? => Clarification request: how should equality/inequality work for objects?
28-05-2020 09:12Jacob Wieland - SpirentNote Added: 0015656
10-08-2020 10:26Jens GrabowskiAssigned To => Jacob Wieland - Spirent
10-08-2020 10:26Jens GrabowskiStatusnew => assigned
11-08-2020 10:10Jacob Wieland - SpirentFile Added: CR7920.docx
11-08-2020 10:11Jacob Wieland - SpirentNote Added: 0015676
11-08-2020 10:11Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Tomas Urban
11-08-2020 10:11Jacob Wieland - SpirentStatusassigned => confirmed
11-08-2020 15:27Kristóf SzabadosNote Added: 0015696
13-08-2020 08:51Tomas UrbanNote Added: 0015720
13-08-2020 08:51Tomas UrbanStatusconfirmed => resolved
13-08-2020 08:51Tomas UrbanResolutionopen => fixed
13-08-2020 08:51Tomas UrbanAssigned ToTomas Urban => Jens Grabowski
17-12-2020 16:22Gyorgy RethyProduct Version => V1.2.1 (published 2020-05)
17-12-2020 16:22Gyorgy RethyTarget Version => V1.3.1 (ongoing)
28-12-2020 11:09Jens GrabowskiStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015656) +
+ Jacob Wieland - Spirent    +
+ 28-05-2020 09:12    +
+ 		+ + + + +
+ Of course, the intention was that object can be compared via comparing their instances as is usual in object-oriented languages. If that is not yet in the standard, that needs to be added.
+
+
+
+ + + + + + + + + + +
+ (0015676) +
+ Jacob Wieland - Spirent    +
+ 11-08-2020 10:11    +
+ 		+ + + + +
+ added section on comparison operators in the objects section, please review
+
+
+
+ + + + + + + + + + +
+ (0015696) +
+ Kristóf Szabados    +
+ 11-08-2020 15:27    +
+ 		+ + + + +
+ looks good for me.
+
+
+
+ + + + + + + + + + +
+ (0015720) +
+ Tomas Urban    +
+ 13-08-2020 08:51    +
+ 		+ + + + +
+ The proposed solution fixes the issue described in this CR and can be added to the next version of the standard.
+
+ + diff --git a/docs/mantis/CR7925.md b/docs/mantis/CR7925.md new file mode 100644 index 0000000000000000000000000000000000000000..94904acf88693fa4a3fbc5573b9f3012cb469d64 --- /dev/null +++ b/docs/mantis/CR7925.md @@ -0,0 +1,362 @@ + + + + + + + + + + + + + 0007925: Non-abstract signature templates - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007925Part 01: TTCN-3 Core LanguageTechnicalpublic22-04-2020 08:0816-12-2020 16:55
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version4.12.1 (published 2020-05) 
Target Version4.13.1 (ongoing)Fixed in Version4.13.1 (ongoing) 
Clause Reference(s)15.3
Source (company - Author)Elvior
Summary0007925: Non-abstract signature templates
DescriptionThe restriction on non-abstract templates 15.3.d should apply to message templates only. In case of signature templates, the restriction shall say that either all in parameters or all out parameters (or both) shall be fully initialized if the template is not marked as abstract.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7925-1.docx (182,874) 12-08-2020 08:57
http://oldforge.etsi.org/mantis/file_download.php?file_id=3917&type=bug
docx CR7925-2.docx (183,621) 13-08-2020 11:21
http://oldforge.etsi.org/mantis/file_download.php?file_id=3934&type=bug
Issue History
Date ModifiedUsernameFieldChange
22-04-2020 08:08Tomas UrbanNew Issue
10-08-2020 10:35Jens GrabowskiAssigned To => Tomas Urban
10-08-2020 10:35Jens GrabowskiStatusnew => assigned
12-08-2020 08:52Tomas UrbanFile Added: CR7925.docx
12-08-2020 08:57Tomas UrbanFile Deleted: CR7925.docx
12-08-2020 08:57Tomas UrbanFile Added: CR7925-1.docx
12-08-2020 08:57Tomas UrbanAssigned ToTomas Urban => Jacob Wieland - Spirent
12-08-2020 08:57Tomas UrbanNote Added: 0015704
12-08-2020 09:28Tomas UrbanStatusassigned => confirmed
12-08-2020 14:56Jacob Wieland - SpirentNote Added: 0015713
12-08-2020 14:56Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Tomas Urban
12-08-2020 14:56Jacob Wieland - SpirentStatusconfirmed => assigned
13-08-2020 08:36Tomas UrbanFile Added: CR7969-2.docx
13-08-2020 08:46Tomas UrbanNote Added: 0015719
13-08-2020 08:46Tomas UrbanAssigned ToTomas Urban => Jacob Wieland - Spirent
13-08-2020 08:46Tomas UrbanStatusassigned => confirmed
13-08-2020 08:46Tomas UrbanNote Edited: 0015719bug_revision_view_page.php?bugnote_id=15719#r524
13-08-2020 10:10Jacob Wieland - SpirentNote Added: 0015723
13-08-2020 10:10Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Tomas Urban
13-08-2020 10:10Jacob Wieland - SpirentStatusconfirmed => assigned
13-08-2020 11:21Tomas UrbanFile Deleted: CR7969-2.docx
13-08-2020 11:21Tomas UrbanFile Added: CR7925-2.docx
13-08-2020 11:21Tomas UrbanNote Added: 0015726
13-08-2020 11:22Tomas UrbanAssigned ToTomas Urban => Jacob Wieland - Spirent
13-08-2020 11:22Tomas UrbanStatusassigned => confirmed
13-08-2020 13:33Jens GrabowskiAssigned ToJacob Wieland - Spirent => Kristóf Szabados
13-08-2020 13:33Jens GrabowskiStatusconfirmed => assigned
14-08-2020 09:56Kristóf SzabadosNote Added: 0015748
14-08-2020 09:56Kristóf SzabadosAssigned ToKristóf Szabados => Tomas Urban
07-10-2020 09:57Tomas UrbanNote Added: 0015764
07-10-2020 10:26Tomas UrbanNote Added: 0015771
07-10-2020 10:26Tomas UrbanStatusassigned => resolved
07-10-2020 10:26Tomas UrbanResolutionopen => fixed
07-10-2020 10:26Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
16-12-2020 16:55Gyorgy RethyNote Added: 0015870
16-12-2020 16:55Gyorgy RethyStatusresolved => closed
16-12-2020 16:55Gyorgy RethyProduct Version => 4.12.1 (published 2020-05)
16-12-2020 16:55Gyorgy RethyFixed in Version => 4.13.1 (ongoing)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015704) +
+ Tomas Urban    +
+ 12-08-2020 08:57    +
+ 		+ + + + +
+ Resolution uploaded. Please check.
+
+
+
+ + + + + + + + + + +
+ (0015713) +
+ Jacob Wieland - Spirent    +
+ 12-08-2020 14:56    +
+ 		+ + + + +
+ I think the proposal is still problematic.
+
+A completely initialized reply template (out/inout initialized) which is not completely initialized as a call template should not be used in call/getcall and vice versa.
+
+Thus, this should probably be clarified that for certain operations, the template need to be completely initialized in a specific way (and not one of two possible ways).
+
+
+
+ + + + + + + + + + +
+ (0015719) +
+ Tomas Urban    +
+ 13-08-2020 08:46    +
+ 		+ + + + +
+ I added related rules to these cases (in + inout -> only call and getcall; out + inout -> only reply and getreply). That should hopefully resolve the issue and allow compilers to detect some errors while still being backwards compatible.
+
+
+
+
+
+ + + + + + + + + + +
+ (0015723) +
+ Jacob Wieland - Spirent    +
+ 13-08-2020 10:10    +
+ 		+ + + + +
+ unfortunately, the last proposal is one for a different CR, please replace with correct one.
+
+
+
+ + + + + + + + + + +
+ (0015726) +
+ Tomas Urban    +
+ 13-08-2020 11:21    +
+ 		+ + + + +
+ Please check now.
+
+
+
+ + + + + + + + + + +
+ (0015748) +
+ Kristóf Szabados    +
+ 14-08-2020 09:56    +
+ 		+ + + + +
+ Maybe the current text is a bit too restrictive?
+
+"
+• All procedure parameters are fully initialized.
+• All in and inout procedure parameters are completely initialized and all out procedure parameters are either unitialized or marked as not relevant using the NotUsedSymbol. Templates declared this way are safe to be used in call and getcall operations, but they shall not be used in reply and getreply operations.
+"
+
+What if my signature has 2 out parameters, I set one of it to a "normal" value and the other is left uninitialized/set to notusedsymbol ?
+This should still be safe to be used in call and getcall operations, since the values of the out parameters are simply ignored.
+Maybe it is not the most performant code to set an ignored parameter to som value ... but should not cause harm.
+
+The same argument can also be said with in parameters and reply operations. They will be ignored .. that is not really efficient, but also not a reason for error either.
+
+
+
+ + + + + + + + + + +
+ (0015764) +
+ Tomas Urban    +
+ 07-10-2020 09:57    +
+ 		+ + + + +
+ What is the use case for creating such a non-abstract template? I cannot figure out any other than further extension in which case the template should be marked as abstract.
+
+On many occasions you emphasized that language design should encourage good coding practices. Writing inefficient code (though a safe one) is definitely not a good coding practice.
+
+Partially defined templates cause real problems, because they are usally discovered late in production testing. The common way how they get into the code is when new elements are added to types (or parameters in case of signatures) and the related templates are not updated.
+
+Consider this:
+signature S(in integer p1, in integer p2);
+template S mw_sign1 := { p1:= 2 }
+
+According to my proposal, this should produce an error. However, if we apply the rules you suggest, this is a completey fine template for reply and getreply operations. In my opinion, it would be quite misleading.
+
+
+
+ + + + + + + + + + +
+ (0015771) +
+ Tomas Urban    +
+ 07-10-2020 10:26    +
+ 		+ + + + +
+ After TTF discussion it was decided to go on with the more restrictive option.
+
+
+
+ + + + + + + + + + +
+ (0015870) +
+ Gyorgy Rethy    +
+ 16-12-2020 16:55    +
+ 		+ + + + +
+ Implemented in draft 4.12.2
+
+ + diff --git a/docs/mantis/CR7952.md b/docs/mantis/CR7952.md new file mode 100644 index 0000000000000000000000000000000000000000..57cd69343a30c20fa9845df24ff58d725b19e170 --- /dev/null +++ b/docs/mantis/CR7952.md @@ -0,0 +1,106 @@ + + + + + + + + + + + + + 0007952: ispresent, isvalue and isbound on objects - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Object-oriented features (ES 203 790)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007952Ext Pack: Object-oriented features (ES 203 790)[All Projects] Generalpublic12-05-2020 09:0928-12-2020 11:02
ReporterKristóf Szabados 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product VersionV1.2.1 (published 2020-05) 
Target VersionV1.3.1 (ongoing)Fixed in Version 
Summary0007952: ispresent, isvalue and isbound on objects
DescriptionPlease note that the behaviour of operators isbound, ispresent, isvalue is not declared in the OO extension.
+
+1)
+The OO extnsion does not mention how ispresent, isbound or isvalue should be understood on objects.
+
+Though I believe they could easily apply to see if the variable was not yet assigned a value.
+And also references to members and fields of members could be reasonably accepted as parameters.
+
+2)
+The core standard talks about "data objects" and templateinstances as parameters to these operators, which sound like they could not be used with variables/formal parameters of class type.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR_7952.docx (136,307) 13-08-2020 12:42
http://oldforge.etsi.org/mantis/file_download.php?file_id=3935&type=bug
docx CR_7952-2.docx (136,251) 14-08-2020 12:50
http://oldforge.etsi.org/mantis/file_download.php?file_id=3953&type=bug
Issue History
Date ModifiedUsernameFieldChange
12-05-2020 09:09Kristóf SzabadosNew Issue
10-08-2020 10:34Jens GrabowskiAssigned To => Kristóf Szabados
10-08-2020 10:34Jens GrabowskiStatusnew => assigned
13-08-2020 12:42Kristóf SzabadosFile Added: CR_7952.docx
13-08-2020 12:42Kristóf SzabadosNote Added: 0015728
13-08-2020 12:42Kristóf SzabadosAssigned ToKristóf Szabados => Jacob Wieland - Spirent
13-08-2020 12:42Kristóf SzabadosStatusassigned => confirmed
14-08-2020 12:50Jacob Wieland - SpirentFile Added: CR_7952-2.docx
14-08-2020 12:50Jacob Wieland - SpirentNote Added: 0015752
14-08-2020 12:50Jacob Wieland - SpirentStatusconfirmed => resolved
14-08-2020 12:50Jacob Wieland - SpirentResolutionopen => fixed
14-08-2020 12:50Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Jens Grabowski
17-12-2020 16:19Gyorgy RethyProduct Version => V1.2.1 (published 2020-05)
17-12-2020 16:19Gyorgy RethyTarget Version => V1.3.1 (ongoing)
28-12-2020 11:02Jens GrabowskiStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015728) +
+ Kristóf Szabados    +
+ 13-08-2020 12:42    +
+ 		+ + + + +
+ uploaded first proposal. please review.
+
+
+
+ + + + + + + + + + +
+ (0015752) +
+ Jacob Wieland - Spirent    +
+ 14-08-2020 12:50    +
+ 		+ + + + +
+ fixed typo otherwise ok
+
+ + diff --git a/docs/mantis/CR7957.md b/docs/mantis/CR7957.md new file mode 100644 index 0000000000000000000000000000000000000000..66073f2f28b6a8878f5695398fcb0cfb1eb772d7 --- /dev/null +++ b/docs/mantis/CR7957.md @@ -0,0 +1,144 @@ + + + + + + + + + + + + + 0007957: add equals function to the object - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Object-oriented features (ES 203 790)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007957Ext Pack: Object-oriented features (ES 203 790)[All Projects] Generalpublic21-05-2020 10:1027-12-2020 13:24
ReporterKristóf Szabados 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product VersionV1.2.1 (published 2020-05) 
Target VersionV1.3.1 (ongoing)Fixed in Version 
Summary0007957: add equals function to the object
DescriptionWhen starting to use Object Oriented approaches to write a common library ( like the ones present in C++ and Java) it became apparrent, that the built in object class should have an equals function.
+"equals(in object Other)"
+
+Without it becomes necessary to create a common base class (comparable) from which all other classes must be derived from, in order to use common data structures and algorithms.
+If this function could be added to the object class, an unnecessary layer of abstraction would be elimintaed.
+
+Also would make it possible (as in C++ and Java) to compare objects based on the internal meaning, rather then their object instances.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR_7957.docx (134,667) 12-08-2020 11:50
http://oldforge.etsi.org/mantis/file_download.php?file_id=3921&type=bug
docx CR_7957-2.docx (135,905) 12-08-2020 13:55
http://oldforge.etsi.org/mantis/file_download.php?file_id=3924&type=bug
docx CR_7957-3.docx (152,677) 13-08-2020 09:46
http://oldforge.etsi.org/mantis/file_download.php?file_id=3931&type=bug
docx CR_7957-4.docx (138,091) 13-08-2020 10:06
http://oldforge.etsi.org/mantis/file_download.php?file_id=3932&type=bug
Issue History
Date ModifiedUsernameFieldChange
21-05-2020 10:10Kristóf SzabadosNew Issue
10-08-2020 10:31Jens GrabowskiAssigned To => Kristóf Szabados
10-08-2020 10:31Jens GrabowskiStatusnew => assigned
12-08-2020 11:50Kristóf SzabadosFile Added: CR_7957.docx
12-08-2020 11:51Kristóf SzabadosAssigned ToKristóf Szabados => Jacob Wieland - Spirent
12-08-2020 13:04Jacob Wieland - SpirentStatusassigned => confirmed
12-08-2020 13:38Jacob Wieland - SpirentFile Added: CR_7957-2.docx
12-08-2020 13:55Jacob Wieland - SpirentFile Deleted: CR_7957-2.docx
12-08-2020 13:55Jacob Wieland - SpirentFile Added: CR_7957-2.docx
12-08-2020 13:56Jacob Wieland - SpirentNote Added: 0015710
12-08-2020 13:56Jacob Wieland - SpirentStatusconfirmed => new
12-08-2020 13:57Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Tomas Urban
12-08-2020 13:57Jacob Wieland - SpirentStatusnew => confirmed
13-08-2020 09:35Tomas UrbanFile Added: CR_7957-3.docx
13-08-2020 09:42Tomas UrbanFile Deleted: CR_7957-3.docx
13-08-2020 09:46Tomas UrbanFile Added: CR_7957-3.docx
13-08-2020 09:51Tomas UrbanNote Added: 0015721
13-08-2020 09:51Tomas UrbanAssigned ToTomas Urban => Jacob Wieland - Spirent
13-08-2020 09:51Tomas UrbanNote Edited: 0015721bug_revision_view_page.php?bugnote_id=15721#r526
13-08-2020 10:06Jacob Wieland - SpirentFile Added: CR_7957-4.docx
13-08-2020 10:07Jacob Wieland - SpirentNote Added: 0015722
13-08-2020 10:07Jacob Wieland - SpirentStatusconfirmed => resolved
13-08-2020 10:07Jacob Wieland - SpirentResolutionopen => fixed
13-08-2020 10:07Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Jens Grabowski
17-12-2020 16:21Gyorgy RethyProduct Version => V1.2.1 (published 2020-05)
17-12-2020 16:21Gyorgy RethyTarget Version => V1.3.1 (ongoing)
27-12-2020 13:24Jens GrabowskiStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015710) +
+ Jacob Wieland - Spirent    +
+ 12-08-2020 13:56    +
+ 		+ + + + +
+ I have fixed the example so that it actually does what one would expect from a comparison between rectangles and squares, please review
+
+
+
+ + + + + + + + + + +
+ (0015721) +
+ Tomas Urban    +
+ 13-08-2020 09:51    +
+ 		+ + + + +
+ I optimized it a little bit further:
+1. The comparison to this is the first type of check, because it is the fastest one
+2. Rectangle has always 4 sides, so there's no need to check the number of sides nor have a function returning it in this example.
+3. I replaced the function for returning a length of a rectangle side with functions returning its width and height which are the properties one would usually expect from a rectangle object.
+
+Please check.
+
+
+
+
+
+ + + + + + + + + + +
+ (0015722) +
+ Jacob Wieland - Spirent    +
+ 13-08-2020 10:07    +
+ 		+ + + + +
+ changes ok, deleted erroneous comment
+
+ + diff --git a/docs/mantis/CR7958.md b/docs/mantis/CR7958.md new file mode 100644 index 0000000000000000000000000000000000000000..7e147ecaf04ac212b60d2354f6d90537f66eba82 --- /dev/null +++ b/docs/mantis/CR7958.md @@ -0,0 +1,327 @@ + + + + + + + + + + + + + 0007958: semantic of interleave altsteps - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007958Part 01: TTCN-3 Core LanguageClarificationpublic27-05-2020 07:3516-12-2020 14:46
ReporterMartin Hauch 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version4.11.1 (published 2019-05) 
Target Version4.13.1 (ongoing)Fixed in Version4.13.1 (ongoing) 
Clause Reference(s)Core language 4.11.1 chapter 16.2.0
Source (company - Author)Devoteam (Martin Hauch)
Summary0007958: semantic of interleave altsteps
DescriptionChapter 16.2.0 General
+NOTE 1: As an interleave statement is semantically equivalent with an alt statement...
+
+I do not think that interleave- and alt-semantic are the same!
+
+Example 3:
+altstep interleave a_interleaveAltStep(in integer p_myPar1, in integer p_myPar2)
+        runs on MyComponentType {
+        var integer v_myLocalVar := f_myFunction(); // local variable
+        [] pCO1.receive(MyTemplate(p_myPar1, v_myLocalVar)) {}
+        [] pCO1.receive(MyTemplate(p_myPar2, v_myLocalVar)) {}
+    }
+
+What does it mean to use the alstep in the following contexts:
+var default vMyDefault:=activate(a_interleaveAltStep(5,5);
+...
+a_interleaveAltStep(3,5);
+...
+alt {
+   [] pCO1.receive(MyTemplate(9, 19)) {}
+   [] a_interleaveAltStep(3,5) {}
+   [] pCO1.receive(MyTemplate(10, 20)) {}
+}
+
+What is the semantic of an interleave altstep in an activate-statement? Does it mean, if default is executed, all branches of the interleave alstep must be executed?
+
+What is the semantic of using interleave altstep by invoking without alt statement?
+What is the semantich of using interleave altstep as branch in an alt statement?
+Changes the semantic of the interleave altstep a_interleaeAltStep, if it is called in an alt statetment or if it is invoked without an alt statement?
+
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR_7958.docx (213,821) 11-08-2020 12:20
http://oldforge.etsi.org/mantis/file_download.php?file_id=3910&type=bug
docx CR_7958_v2.docx (213,959) 12-08-2020 17:14
http://oldforge.etsi.org/mantis/file_download.php?file_id=3927&type=bug
Issue History
Date ModifiedUsernameFieldChange
27-05-2020 07:35Martin HauchNew Issue
27-05-2020 11:57Jacob Wieland - SpirentNote Added: 0015655
27-05-2020 11:59Jacob Wieland - SpirentNote Edited: 0015655bug_revision_view_page.php?bugnote_id=15655#r516
10-08-2020 10:29Jens GrabowskiAssigned To => Kristóf Szabados
10-08-2020 10:29Jens GrabowskiStatusnew => assigned
11-08-2020 12:20Kristóf SzabadosFile Added: CR_7958.docx
11-08-2020 12:21Kristóf SzabadosNote Added: 0015690
11-08-2020 12:21Kristóf SzabadosAssigned ToKristóf Szabados => Jacob Wieland - Spirent
11-08-2020 15:49Jacob Wieland - SpirentNote Added: 0015699
11-08-2020 15:50Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Kristóf Szabados
11-08-2020 16:05Kristóf SzabadosNote Added: 0015702
12-08-2020 13:22Kristóf SzabadosStatusassigned => resolved
12-08-2020 13:22Kristóf SzabadosResolutionopen => fixed
12-08-2020 13:22Kristóf SzabadosAssigned ToKristóf Szabados => Gyorgy Rethy
12-08-2020 17:10Kristóf SzabadosNote Added: 0015714
12-08-2020 17:10Kristóf SzabadosAssigned ToGyorgy Rethy => Kristóf Szabados
12-08-2020 17:10Kristóf SzabadosStatusresolved => confirmed
12-08-2020 17:14Kristóf SzabadosFile Added: CR_7958_v2.docx
12-08-2020 17:15Kristóf SzabadosNote Added: 0015715
12-08-2020 17:15Kristóf SzabadosAssigned ToKristóf Szabados => Jacob Wieland - Spirent
12-08-2020 17:15Kristóf SzabadosStatusconfirmed => assigned
13-08-2020 10:13Jacob Wieland - SpirentStatusassigned => resolved
13-08-2020 10:13Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
16-12-2020 14:46Gyorgy RethyNote Added: 0015862
16-12-2020 14:46Gyorgy RethyStatusresolved => closed
16-12-2020 14:46Gyorgy RethyFixed in Version => 4.13.1 (ongoing)
16-12-2020 14:46Gyorgy RethyTarget Version => 4.13.1 (ongoing)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015655) +
+ Jacob Wieland - Spirent    +
+ 27-05-2020 11:57    +
(edited on: 27-05-2020 11:59)
+ 		+ + + + +
+ An interleave statement has an equivalent alt-statement expansion.
+
+In this example, this would be:
+
+altstep a_interleaveAltStep(in integer p_myPar1, in integer p_myPar2)
+        runs on MyComponentType {
+  var integer v_myLocalVar := f_myFunction(); // local variable
+[] pCO1.receive(MyTemplate(p_myPar1, v_myLocalVar)) {
+  alt {
+  [] pCO1.receive(MyTemplate(p_myPar2, v_myLocalVar)) {}
+  }
+}
+[] pCO1.receive(MyTemplate(p_myPar2, v_myLocalVar)) {
+  alt {
+  [] pCO1.receive(MyTemplate(p_myPar1, v_myLocalVar)) {}
+  }
+}
+}
+
+Thus, the same semantics as for this alt-exansion also apply to the unexpanded interleave statement.
+
+Following this:
+
+If activated as a default, if the head of any interleave branch matches, then all branches must be executed. If no branch is entered, the next default (if any) is tried. (The same is true for any nested alt statement).
+
+If used as top-level statement, the same semantic as for a top-level alt-invocation is used. It is wrapped into an alt-statement with a single alternative.
+
+If used as the match-part of an alternative in an alt-statement, the same semantic applies as for the extended alt-statement (i.e. the branches of the extended alt statement replace the single branch with the statement block of the original branch appended to the last statement blocks of the expanded alternatives).
+
+
+
+
+
+ + + + + + + + + + +
+ (0015690) +
+ Kristóf Szabados    +
+ 11-08-2020 12:21    +
+ 		+ + + + +
+ I have added an example to show how the interleave altstep could be replaced with a simple altstep, using the expansion rules of interleaves.
+Please review.
+
+
+
+ + + + + + + + + + +
+ (0015699) +
+ Jacob Wieland - Spirent    +
+ 11-08-2020 15:49    +
+ 		+ + + + +
+ how is that more helpful than what is already in the standard?
+
+
+
+ + + + + + + + + + +
+ (0015702) +
+ Kristóf Szabados    +
+ 11-08-2020 16:05    +
+ 		+ + + + +
+ During the first meeting we agreed to add an example that shows how "expansion" could be used to interleave altsteps, to make the equivalence more pronounced (with respect of the restrictions also present in the standard).
+
+
+
+ + + + + + + + + + +
+ (0015714) +
+ Kristóf Szabados    +
+ 12-08-2020 17:10    +
+ 		+ + + + +
+ reopening, to add one more clarification.
+
+
+
+ + + + + + + + + + +
+ (0015715) +
+ Kristóf Szabados    +
+ 12-08-2020 17:15    +
+ 		+ + + + +
+ please review.
+
+
+
+ + + + + + + + + + +
+ (0015862) +
+ Gyorgy Rethy    +
+ 16-12-2020 14:46    +
+ 		+ + + + +
+ Implemented in draft 4.12.2
+
+ + diff --git a/docs/mantis/CR7959.md b/docs/mantis/CR7959.md new file mode 100644 index 0000000000000000000000000000000000000000..fc7be7cdab2846305c29a19eeac850908d30d42c --- /dev/null +++ b/docs/mantis/CR7959.md @@ -0,0 +1,167 @@ + + + + + + + + + + + + + 0007959: language keyword strings - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007959Part 01: TTCN-3 Core LanguageEditorialpublic02-06-2020 15:5316-12-2020 15:15
ReporterAxel Rennoch (old account) 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version4.12.1 (published 2020-05) 
Target Version4.13.1 (ongoing)Fixed in Version4.13.1 (ongoing) 
Clause Reference(s)Section 8.1
Source (company - Author)Axel Rennoch (FOKUS)
Summary0007959: language keyword strings
DescriptionThe definition of a module may include an optional language attribute. In this context a list of language keyword strings is provided regarding previous TTCN-3 versions since 2001. The list may need an update to cover latest version 2019 and 2020.
+
+Furthermore the list of language extensions (for package tags) should mention/cover latest extension packages (e.g OO features).
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx es_20187301v041201p-0007959.docx (198,348) 11-08-2020 12:45
http://oldforge.etsi.org/mantis/file_download.php?file_id=3912&type=bug
Issue History
Date ModifiedUsernameFieldChange
02-06-2020 15:53Axel Rennoch (old account)New Issue
10-08-2020 10:24Jens GrabowskiAssigned To => Axel Rennoch (old account)
10-08-2020 10:24Jens GrabowskiStatusnew => assigned
10-08-2020 16:56Jens GrabowskiAssigned ToAxel Rennoch (old account) => Axel Rennoch
11-08-2020 12:45Axel RennochNote Added: 0015693
11-08-2020 12:45Axel RennochFile Added: es_20187301v041201p-0007959.docx
11-08-2020 12:47Axel RennochNote Added: 0015694
11-08-2020 12:47Axel RennochAssigned ToAxel Rennoch => Jens Grabowski
11-08-2020 12:47Axel RennochStatusassigned => acknowledged
11-08-2020 13:22Jens GrabowskiStatusacknowledged => confirmed
14-08-2020 07:36Jens GrabowskiNote Added: 0015737
14-08-2020 07:36Jens GrabowskiStatusconfirmed => resolved
14-08-2020 07:36Jens GrabowskiFixed in Version => 4.13.1 (ongoing)
14-08-2020 07:36Jens GrabowskiResolutionopen => fixed
14-08-2020 07:36Jens GrabowskiAssigned ToJens Grabowski => Gyorgy Rethy
16-12-2020 15:15Gyorgy RethyNote Added: 0015865
16-12-2020 15:15Gyorgy RethyStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015693) +
+ Axel Rennoch    +
+ 11-08-2020 12:45    +
+ 		+ + + + +
+ Missing language keyword strings and language extensions have been added.
+
+
+
+ + + + + + + + + + +
+ (0015694) +
+ Axel Rennoch    +
+ 11-08-2020 12:47    +
+ 		+ + + + +
+ List of added items need to be confirmed.
+
+
+
+ + + + + + + + + + +
+ (0015737) +
+ Jens Grabowski    +
+ 14-08-2020 07:36    +
+ 		+ + + + +
+ Resolved
+
+
+
+ + + + + + + + + + +
+ (0015865) +
+ Gyorgy Rethy    +
+ 16-12-2020 15:15    +
+ 		+ + + + +
+ Implemented in draft 4.12.2
+
+ + diff --git a/docs/mantis/CR7961.md b/docs/mantis/CR7961.md new file mode 100644 index 0000000000000000000000000000000000000000..9c9179bc20496cfcf29e2938be200805f53c463d --- /dev/null +++ b/docs/mantis/CR7961.md @@ -0,0 +1,34 @@ + + + + + + + + + + + + + 0007961: type in function description - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Object-oriented features (ES 203 790)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007961Ext Pack: Object-oriented features (ES 203 790)[All Projects] Generalpublic29-06-2020 08:5327-12-2020 12:36
ReporterKristóf Szabados 
Assigned ToJens Grabowski 
PrioritynormalSeveritytextReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product VersionV1.2.1 (published 2020-05) 
Target VersionV1.3.1 (ongoing)Fixed in Version 
Summary0007961: type in function description
DescriptionIn section B.1.9 describing the external function and class methods of the methodsSet class there is a typo.
+
+"Returns the number of elements stored in the Queue."
+
+Should be:
+"Returns the number of elements stored in the Set."
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7961-V1-20200814.docx (32,342) 14-08-2020 07:55
http://oldforge.etsi.org/mantis/file_download.php?file_id=3943&type=bug
Issue History
Date ModifiedUsernameFieldChange
29-06-2020 08:53Kristóf SzabadosNew Issue
10-08-2020 10:24Jens GrabowskiAssigned To => Jens Grabowski
10-08-2020 10:24Jens GrabowskiStatusnew => assigned
14-08-2020 07:55Jens GrabowskiFile Added: CR7961-V1-20200814.docx
14-08-2020 07:56Jens GrabowskiStatusassigned => resolved
14-08-2020 07:56Jens GrabowskiResolutionopen => fixed
14-08-2020 07:56Jens GrabowskiAssigned ToJens Grabowski => Gyorgy Rethy
17-12-2020 16:21Gyorgy RethyAssigned ToGyorgy Rethy => Jens Grabowski
17-12-2020 16:21Gyorgy RethyProduct Version => V1.2.1 (published 2020-05)
17-12-2020 16:21Gyorgy RethyTarget Version => V1.3.1 (ongoing)
27-12-2020 12:36Jens GrabowskiStatusresolved => closed
+
+ + + + +
+ There are no notes attached to this issue.
+ + diff --git a/docs/mantis/CR7962.md b/docs/mantis/CR7962.md new file mode 100644 index 0000000000000000000000000000000000000000..efb3dd9bdcb6375c9a40ae7a78ac1aa5ad50c806 --- /dev/null +++ b/docs/mantis/CR7962.md @@ -0,0 +1,34 @@ + + + + + + + + + + + + + 0007962: type in Queue description - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Object-oriented features (ES 203 790)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007962Ext Pack: Object-oriented features (ES 203 790)[All Projects] Generalpublic29-06-2020 08:5427-12-2020 12:33
ReporterKristóf Szabados 
Assigned ToJens Grabowski 
PrioritynormalSeveritytextReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product VersionV1.2.1 (published 2020-05) 
Target VersionV1.3.1 (ongoing)Fixed in Version 
Summary0007962: type in Queue description
DescriptionIn section B.1.4
+
+"Adds an element to the end Queue if this is possible."
+
+should be:
+"Adds an element to the end of the Queue if this is possible."
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7962-V1-20200814.docx (32,182) 14-08-2020 07:58
http://oldforge.etsi.org/mantis/file_download.php?file_id=3944&type=bug
Issue History
Date ModifiedUsernameFieldChange
29-06-2020 08:54Kristóf SzabadosNew Issue
10-08-2020 10:23Jens GrabowskiAssigned To => Jens Grabowski
10-08-2020 10:23Jens GrabowskiStatusnew => assigned
14-08-2020 07:58Jens GrabowskiFile Added: CR7962-V1-20200814.docx
14-08-2020 07:59Jens GrabowskiStatusassigned => resolved
14-08-2020 07:59Jens GrabowskiResolutionopen => fixed
14-08-2020 07:59Jens GrabowskiAssigned ToJens Grabowski => Gyorgy Rethy
17-12-2020 16:21Gyorgy RethyAssigned ToGyorgy Rethy => Jens Grabowski
17-12-2020 16:21Gyorgy RethyProduct Version => V1.2.1 (published 2020-05)
17-12-2020 16:21Gyorgy RethyTarget Version => V1.3.1 (ongoing)
27-12-2020 12:33Jens GrabowskiStatusresolved => closed
+
+ + + + +
+ There are no notes attached to this issue.
+ + diff --git a/docs/mantis/CR7963.md b/docs/mantis/CR7963.md new file mode 100644 index 0000000000000000000000000000000000000000..ae70b196fe5bd2265081a7646e342151cc1d902f --- /dev/null +++ b/docs/mantis/CR7963.md @@ -0,0 +1,42 @@ + + + + + + + + + + + + + 0007963: incorect text formatting in section B.1.0 - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Object-oriented features (ES 203 790)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007963Ext Pack: Object-oriented features (ES 203 790)[All Projects] Generalpublic29-06-2020 09:0127-12-2020 12:50
ReporterKristóf Szabados 
Assigned ToJens Grabowski 
PrioritynormalSeveritytextReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product VersionV1.2.1 (published 2020-05) 
Target VersionV1.3.1 (ongoing)Fixed in Version 
Summary0007963: incorect text formatting in section B.1.0
DescriptionIn section B.1.0 some code parts are not formatted correctly.
+
+for example:
+1)
+For the Collection class the "abstract" keyword for the iterator should be bold.
+
+2)
+In the description of the List class, all the "public function @abstract" should be bold, and indented correctly.
+
+3)
+description of the "equalsFunctionType" function for RingBuffer class
+
+4)
+"values" function for HashMap
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7963-V1-20200814.docx (34,344) 14-08-2020 08:23
http://oldforge.etsi.org/mantis/file_download.php?file_id=3947&type=bug
Issue History
Date ModifiedUsernameFieldChange
29-06-2020 09:01Kristóf SzabadosNew Issue
10-08-2020 10:23Jens GrabowskiAssigned To => Jens Grabowski
10-08-2020 10:23Jens GrabowskiStatusnew => assigned
14-08-2020 08:23Jens GrabowskiFile Added: CR7963-V1-20200814.docx
14-08-2020 08:23Jens GrabowskiStatusassigned => resolved
14-08-2020 08:23Jens GrabowskiResolutionopen => fixed
14-08-2020 08:23Jens GrabowskiAssigned ToJens Grabowski => Gyorgy Rethy
17-12-2020 16:20Gyorgy RethyAssigned ToGyorgy Rethy => Jens Grabowski
17-12-2020 16:20Gyorgy RethyProduct Version => V1.2.1 (published 2020-05)
17-12-2020 16:20Gyorgy RethyTarget Version => V1.3.1 (ongoing)
27-12-2020 12:50Jens GrabowskiStatusresolved => closed
+
+ + + + +
+ There are no notes attached to this issue.
+ + diff --git a/docs/mantis/CR7964.md b/docs/mantis/CR7964.md new file mode 100644 index 0000000000000000000000000000000000000000..73de1bd44380eee8de3a81e7373c9fa34436e3c9 --- /dev/null +++ b/docs/mantis/CR7964.md @@ -0,0 +1,336 @@ + + + + + + + + + + + + + 0007964: Assigning a universal charstring value to a charstring variable is now allowed, but very error prone - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007964Part 01: TTCN-3 Core LanguageNew Featurepublic29-06-2020 20:0216-12-2020 15:02
ReporterKristóf Szabados 
Assigned ToGyorgy Rethy 
PrioritynormalSeveritymajorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version4.12.1 (published 2020-05) 
Target Version4.13.1 (ongoing)Fixed in Version4.13.1 (ongoing) 
Clause Reference(s)6.3.1
Source (company - Author)     L.M. Ericsson
Summary0007964: Assigning a universal charstring value to a charstring variable is now allowed, but very error prone
DescriptionThe current type compatibility rules of the TTCN-3 standard allows to assign a universal charstring value to a charstring variable.
+See section 6.3.1
+There is an actual example in example 4.
+
+This is very error prone:
+- if the universal charstring has even a single character that does not fit into the charstring, a runtime error has to be produced.
+- Most of the time universal charstrings are used when the expected values, do not fit into the charstring restrictions.
+- In most practical situations, this is impossible to check in compilation time ... leading to unexpected runtime errors.
+
+If this kind of assignment is needed maybe we could have a predefined function, that converts only the universal characters that are actually characters and never fails.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR_7964.docx (201,496) 11-08-2020 16:55
http://oldforge.etsi.org/mantis/file_download.php?file_id=3915&type=bug
docx CR_7964-2.docx (201,261) 12-08-2020 14:30
http://oldforge.etsi.org/mantis/file_download.php?file_id=3926&type=bug
Issue History
Date ModifiedUsernameFieldChange
29-06-2020 20:02Kristóf SzabadosNew Issue
01-07-2020 10:14Wolfgang SekaNote Added: 0015665
10-08-2020 10:22Jens GrabowskiProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
10-08-2020 10:23Jens GrabowskiAssigned To => Jacob Wieland - Spirent
10-08-2020 10:23Jens GrabowskiStatusnew => assigned
11-08-2020 12:14Jacob Wieland - SpirentNote Added: 0015689
11-08-2020 13:19Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Kristóf Szabados
11-08-2020 13:20Jacob Wieland - SpirentNote Added: 0015695
11-08-2020 16:55Kristóf SzabadosFile Added: CR_7964.docx
11-08-2020 16:55Kristóf SzabadosNote Added: 0015703
11-08-2020 16:55Kristóf SzabadosAssigned ToKristóf Szabados => Jacob Wieland - Spirent
12-08-2020 13:03Jacob Wieland - SpirentStatusassigned => confirmed
12-08-2020 14:30Jacob Wieland - SpirentFile Added: CR_7964-2.docx
12-08-2020 14:33Jacob Wieland - SpirentNote Added: 0015712
12-08-2020 14:33Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Kristóf Szabados
12-08-2020 14:33Jacob Wieland - SpirentStatusconfirmed => assigned
12-08-2020 14:33Jacob Wieland - SpirentStatusassigned => confirmed
12-08-2020 17:21Kristóf SzabadosNote Added: 0015716
13-08-2020 11:47Kristóf SzabadosAssigned ToKristóf Szabados => Jacob Wieland - Spirent
13-08-2020 11:47Kristóf SzabadosStatusconfirmed => assigned
13-08-2020 11:47Kristóf SzabadosStatusassigned => confirmed
13-08-2020 13:02Jacob Wieland - SpirentNote Added: 0015729
13-08-2020 13:08Jacob Wieland - SpirentStatusconfirmed => resolved
13-08-2020 13:08Jacob Wieland - SpirentResolutionopen => fixed
13-08-2020 13:08Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
16-12-2020 15:02Gyorgy RethyNote Added: 0015864
16-12-2020 15:02Gyorgy RethyStatusresolved => closed
16-12-2020 15:02Gyorgy RethyProduct Version => 4.12.1 (published 2020-05)
16-12-2020 15:02Gyorgy RethyFixed in Version => 4.13.1 (ongoing)
16-12-2020 15:02Gyorgy RethyTarget Version => 4.13.1 (ongoing)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015665) +
+ Wolfgang Seka    +
+ 01-07-2020 10:14    +
+ 		+ + + + +
+ According to my understanding charstring and universal charstring are compatible types (ES 201 873-1 clause 6.3.1).
+=> assignments shall be possible in both directions and shall not cause a compilation error.
+Whether tools generate a run-time error seems to be tool dependent.
+(Nevertheless on my opinion it shall be the codec raising the error - if needed)
+
+Any further restrictions in the TTCN language would be non-compatible.
+Please note in this context that the only reason why we (MCC160) need to care about universal charstring is due to definitions in XSD.ttcn.
+
+Furthermore on my opinion there is no benefit or need for any conversion function:
+A conversion function may
+- raise a run time error when the universal charstring contains non-charstring characters => no benefit
+- skip non-charstring characters => unpredictable side-effects
+But instead there could be a build-in function to check whether a string complies to a particular character set (even though by the time being there is no need for such function from our side).
+
+Nevertheless ES 201 873-1 may be improved to clarify that charstring is sub-type of universal charstring and shall be treated like this.
+(a more progressive approach would be to go for a single character string type)
+
+
+
+ + + + + + + + + + +
+ (0015689) +
+ Jacob Wieland - Spirent    +
+ 11-08-2020 12:14    +
+ 		+ + + + +
+ As I can see it, the standard is perfectly clear when a universal charstring is compatible with charstring:
+
+For variables, constants, templates, etc. of charstring type, value 'b' is compatible with a universal charstring type 'A' unless it violates any type constraint specification (range, list or length) of type "A".
+For variables, constants, templates, etc. of universal charstring type, value 'b' is compatible with a charstring type 'A' if all characters used in value 'b' have their corresponding characters (i.e. the same control or graphical character using the same character code) in the type charstring and it does not violate any type constraint specification (range, list or length) of type "A".
+
+When not compatible, the assignment will raise an error the same as for all other types when they are not compatible.
+
+In my opinion, nothing needs to be done. It is a tool issue to warn the user of possible runtime problems. In that case, they are not unexpected either.
+
+
+
+ + + + + + + + + + +
+ (0015695) +
+ Jacob Wieland - Spirent    +
+ 11-08-2020 13:20    +
+ 		+ + + + +
+ STF discussion: add a definition for invalid expressions/operations in the definitions part describing that invalid things will lead to errors being raised
+
+
+
+ + + + + + + + + + +
+ (0015703) +
+ Kristóf Szabados    +
+ 11-08-2020 16:55    +
+ 		+ + + + +
+ Please review.
+
+
+
+ + + + + + + + + + +
+ (0015712) +
+ Jacob Wieland - Spirent    +
+ 12-08-2020 14:33    +
+ 		+ + + + +
+ I changed the wording of the proposal to not reference compilation but use static analysis instead (a tool could just do static analysis and not produce any executable at all). I also removed the 'if possible' part. Many things are possible to do but impracticle in practice (halting problem etc.), so compilers will not always do what is possible but only a subset. The standard should not force them to do all that is theoretically possible. Also, the invalid expressions will only cause runtime errors when they are actually evaluated, so I also included that part.
+
+Please review.
+
+
+
+ + + + + + + + + + +
+ (0015716) +
+ Kristóf Szabados    +
+ 12-08-2020 17:21    +
+ 		+ + + + +
+ "Possibly invalid expressions should be warned about during static analysis.."
+
+That would all of the cases when a universal charstring variable or formal parameter is assigned to a charstring variable. If a tool can not evaluate constants ... also for constant of the universal charstring type.
+
+
+
+ + + + + + + + + + +
+ (0015729) +
+ Jacob Wieland - Spirent    +
+ 13-08-2020 13:02    +
+ 		+ + + + +
+ Yes, that is correct, all universal charstrings who the static analysis does not determine to contain only charstring characters should be warned about so that the runtime error is not unexpected anymore.
+
+
+
+ + + + + + + + + + +
+ (0015864) +
+ Gyorgy Rethy    +
+ 16-12-2020 15:02    +
+ 		+ + + + +
+ Implemented in draft 4.12.2
+
+ + diff --git a/docs/mantis/CR7965.md b/docs/mantis/CR7965.md new file mode 100644 index 0000000000000000000000000000000000000000..7b0b4a2563d5bc6008b31bffdce1347136b42407 --- /dev/null +++ b/docs/mantis/CR7965.md @@ -0,0 +1,36 @@ + + + + + + + + + + + + + 0007965: typo in B.1.8 - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Object-oriented features (ES 203 790)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007965Ext Pack: Object-oriented features (ES 203 790)[All Projects] Generalpublic02-07-2020 10:3127-12-2020 12:32
ReporterKristóf Szabados 
Assigned ToJens Grabowski 
PrioritynormalSeveritytextReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product VersionV1.2.1 (published 2020-05) 
Target VersionV1.3.1 (ongoing)Fixed in Version 
Summary0007965: typo in B.1.8
DescriptionIn section B.1.8 there is a typo.
+
+"Pleae note that each key has to be unique..."
+
+should be
+
+"Please note that each key has to be unique..."
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7965-V1-20200814.docx (33,233) 14-08-2020 08:03
http://oldforge.etsi.org/mantis/file_download.php?file_id=3945&type=bug
Issue History
Date ModifiedUsernameFieldChange
02-07-2020 10:31Kristóf SzabadosNew Issue
10-08-2020 10:19Jens GrabowskiAssigned To => Jens Grabowski
10-08-2020 10:19Jens GrabowskiStatusnew => assigned
14-08-2020 08:03Jens GrabowskiFile Added: CR7965-V1-20200814.docx
14-08-2020 08:03Jens GrabowskiStatusassigned => resolved
14-08-2020 08:03Jens GrabowskiResolutionopen => fixed
14-08-2020 08:03Jens GrabowskiAssigned ToJens Grabowski => Gyorgy Rethy
17-12-2020 16:20Gyorgy RethyAssigned ToGyorgy Rethy => Jens Grabowski
17-12-2020 16:20Gyorgy RethyProduct Version => V1.2.1 (published 2020-05)
17-12-2020 16:20Gyorgy RethyTarget Version => V1.3.1 (ongoing)
27-12-2020 12:32Jens GrabowskiStatusresolved => closed
+
+ + + + +
+ There are no notes attached to this issue.
+ + diff --git a/docs/mantis/CR7968.md b/docs/mantis/CR7968.md new file mode 100644 index 0000000000000000000000000000000000000000..7d5b38599fe324d0ce43edbb27fdba1b91752b1a --- /dev/null +++ b/docs/mantis/CR7968.md @@ -0,0 +1,533 @@ + + + + + + + + + + + + + 0007968: unclear description on what can be inside of a default - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 11: Using JSON with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007968Part 11: Using JSON with TTCN-3[TTCN-3 Change Requests] Clarificationpublic23-07-2020 08:5117-12-2020 15:19
ReporterKristóf Szabados 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product VersionV4.8.1 (published 2020-05) 
Target VersionV4.9.1 (ongoing)Fixed in VersionV4.9.1 (ongoing) 
Summary0007968: unclear description on what can be inside of a default
DescriptionSection B.3.9 "Default" describes the acceptable <value> part as such
+"The <value> shall contain a valid TTCN-3 value of the field's type, but string types do not need the starting and ending quotes. All JSON escaped characters can be used, plus the escape sequence '\)' will add a ')' (right round bracket) character."
+
+However as the only example is for charstrings, this leaves some questions unanswered.
+
+For example if it is set for a universal charstring field like this:
+type record RecDef {
+  universal charstring ucs
+} with {
+  variant(ucs) "JSON:default(<value>)";
+}
+
+is
+char(1,2,3,4) & char(5,6,7,8) & "?"
+Acceptable for <value>?
+
+The text also sais that the ending quotes are not needed.
+Which could indicate that this would also be ok
+char(1,2,3,4) & char(5,6,7,8) & "?
+An expression not acceptable anywhere else.
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR_7968.docx (147,206) 10-08-2020 16:34
http://oldforge.etsi.org/mantis/file_download.php?file_id=3901&type=bug
docx CR_7968_v2.docx (148,334) 10-08-2020 17:51
http://oldforge.etsi.org/mantis/file_download.php?file_id=3902&type=bug
docx CR_7968_v3.docx (148,304) 11-08-2020 10:48
http://oldforge.etsi.org/mantis/file_download.php?file_id=3906&type=bug
docx CR_7968_v4.docx (148,961) 11-08-2020 16:01
http://oldforge.etsi.org/mantis/file_download.php?file_id=3914&type=bug
docx CR_7968_v5.docx (149,860) 12-08-2020 14:16
http://oldforge.etsi.org/mantis/file_download.php?file_id=3925&type=bug
Issue History
Date ModifiedUsernameFieldChange
23-07-2020 08:51Kristóf SzabadosNew Issue
23-07-2020 09:13Kristóf SzabadosNote Added: 0015666
25-07-2020 17:23Kristóf SzabadosNote Added: 0015668
25-07-2020 17:31Kristóf SzabadosNote Added: 0015669
10-08-2020 10:19Jens GrabowskiAssigned To => Kristóf Szabados
10-08-2020 10:19Jens GrabowskiStatusnew => assigned
10-08-2020 16:34Kristóf SzabadosFile Added: CR_7968.docx
10-08-2020 16:37Kristóf SzabadosNote Added: 0015672
10-08-2020 17:51Kristóf SzabadosFile Added: CR_7968_v2.docx
10-08-2020 17:52Kristóf SzabadosNote Added: 0015673
11-08-2020 10:12Kristóf SzabadosNote Added: 0015677
11-08-2020 10:12Kristóf SzabadosAssigned ToKristóf Szabados => Jacob Wieland - Spirent
11-08-2020 10:13Jacob Wieland - SpirentStatusassigned => confirmed
11-08-2020 10:33Jacob Wieland - SpirentNote Added: 0015678
11-08-2020 10:34Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Kristóf Szabados
11-08-2020 10:34Jacob Wieland - SpirentStatusconfirmed => assigned
11-08-2020 10:48Kristóf SzabadosFile Added: CR_7968_v3.docx
11-08-2020 10:49Kristóf SzabadosNote Added: 0015680
11-08-2020 16:01Kristóf SzabadosFile Added: CR_7968_v4.docx
11-08-2020 16:01Kristóf SzabadosNote Added: 0015701
11-08-2020 16:02Kristóf SzabadosAssigned ToKristóf Szabados => Jacob Wieland - Spirent
12-08-2020 13:04Jacob Wieland - SpirentStatusassigned => confirmed
12-08-2020 14:16Jacob Wieland - SpirentFile Added: CR_7968_v5.docx
12-08-2020 14:18Jacob Wieland - SpirentNote Added: 0015711
12-08-2020 14:18Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Kristóf Szabados
12-08-2020 14:18Jacob Wieland - SpirentStatusconfirmed => assigned
12-08-2020 14:18Jacob Wieland - SpirentStatusassigned => confirmed
12-08-2020 17:30Kristóf SzabadosNote Added: 0015717
12-08-2020 17:30Kristóf SzabadosAssigned ToKristóf Szabados => Tomas Urban
12-08-2020 17:30Kristóf SzabadosStatusconfirmed => assigned
13-08-2020 11:58Tomas UrbanNote Added: 0015727
13-08-2020 11:58Tomas UrbanStatusassigned => resolved
13-08-2020 11:58Tomas UrbanResolutionopen => fixed
13-08-2020 11:58Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
17-12-2020 15:19Gyorgy RethyNote Added: 0015885
17-12-2020 15:19Gyorgy RethyStatusresolved => closed
17-12-2020 15:19Gyorgy RethyProduct Version => V4.8.1 (published 2020-05)
17-12-2020 15:19Gyorgy RethyFixed in Version => V4.9.1 (ongoing)
17-12-2020 15:19Gyorgy RethyTarget Version => V4.9.1 (ongoing)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015666) +
+ Kristóf Szabados    +
+ 23-07-2020 09:13    +
+ 		+ + + + +
+ Also can this <value> be a value of a structured type?
+
+
+
+ + + + + + + + + + +
+ (0015668) +
+ Kristóf Szabados    +
+ 25-07-2020 17:23    +
+ 		+ + + + +
+ the part of "string types do not need the starting and ending quotes" creates a problem for error reporting.
+
+In this example:
+type record RecDef {
+  integer ucs
+} with {
+  variant(ucs) "JSON:default(1.2.3)";
+}
+
+Should the tools report an error for the syntactically incorrect float value, or should they warn the user that a charstring value can not be assigned to an integer field.
+According to the current text of the standard, during lexical anaysis if the tools find a syntactic error in the value ... they should assume that it is a charstring value without quotes. Which might not be the expected behaviour from the user's point of view.
+
+This logic can be very limiting for tools and result in very bad service for the users in more complex cases.
+for example:
+type record RecDef {
+  SomeRecordType field
+} with {
+  variant(field) "JSON:default({x1:=1,x2:=1.2,x3:=xx2,x4=omit})";
+}
+
+In this case should the tools report to the user that there is a syntax error just after x4, or should they report that a charstring value can not be assigned to a field of SomeRecordType.
+Right now the standard seems to suggest the second option ... but from a users point of view the first one would be much more useful.
+
+
+
+ + + + + + + + + + +
+ (0015669) +
+ Kristóf Szabados    +
+ 25-07-2020 17:31    +
+ 		+ + + + +
+ Please note, that the option to leave out starting and ending quotes is also bad for parsers, as it creates ambiguous situations.
+
+For example:
+In this example:
+type record RecDef {
+  charstring field1
+  charstring field2
+} with {
+  variant(field1) "JSON:default( )"; variant(field2) "JSON:default( )";
+}
+
+Are we here setting the " " (single space) value as default for both fields?
+Or the " )\"; variant(field2) \"JSON:default( " to field1 with improperly un-escaped quotes (which happens in practice)?
+
+
+
+ + + + + + + + + + +
+ (0015672) +
+ Kristóf Szabados    +
+ 10-08-2020 16:37    +
+ 		+ + + + +
+ Added first proposal version.
+- removed the option to leave out string opening-closing characters otherwise required in other places in TTCN-3 (", 'O ...etc).
+- added example for a default with a record value.
+- added example for a syntactically erroneous default value (to show that it is not to be recognized as a correct charstring
+
+
+
+ + + + + + + + + + +
+ (0015673) +
+ Kristóf Szabados    +
+ 10-08-2020 17:52    +
+ 		+ + + + +
+ _v2 also allows referencing const values, as long as the referenced values are statically bound, i.e. known in compile time.
++ example.
+
+
+
+ + + + + + + + + + +
+ (0015677) +
+ Kristóf Szabados    +
+ 11-08-2020 10:12    +
+ 		+ + + + +
+ please review
+
+
+
+ + + + + + + + + + +
+ (0015678) +
+ Jacob Wieland - Spirent    +
+ 11-08-2020 10:33    +
+ 		+ + + + +
+ I don't think allowing sub-expressions to be constant references is really necessary. It makes things complicated and if they user wants that, they can simply define the whole value as a constant and reference that instead. That way, the normal type and context checking mechanisms are used and do not have to be empployed recursively on the codec generator level.
+
+Also, the quoting of strings seems to be wrong. You are often using triple quotes where only double quotes should be.
+
+
+
+ + + + + + + + + + +
+ (0015680) +
+ Kristóf Szabados    +
+ 11-08-2020 10:49    +
+ 		+ + + + +
+ fixed the triple quote issue.
+please check.
+
+
+
+ + + + + + + + + + +
+ (0015701) +
+ Kristóf Szabados    +
+ 11-08-2020 16:01    +
+ 		+ + + + +
+ modified so that references are only allowed on top level.
+Please review.
+
+
+
+ + + + + + + + + + +
+ (0015711) +
+ Jacob Wieland - Spirent    +
+ 12-08-2020 14:18    +
+ 		+ + + + +
+ Changed the wording slightly and fixed the examples. 'from' is a keyword so I replaced it with origin, also fixed some syntactical errors. Please review
+
+
+
+ + + + + + + + + + +
+ (0015717) +
+ Kristóf Szabados    +
+ 12-08-2020 17:30    +
+ 		+ + + + +
+ looks good for me.
+Tomas should also take a look.
+
+
+
+ + + + + + + + + + +
+ (0015727) +
+ Tomas Urban    +
+ 13-08-2020 11:58    +
+ 		+ + + + +
+ The proposed change resolves the issue described in the CR and it is ready to be added to the next version of the specification.
+
+
+
+ + + + + + + + + + +
+ (0015885) +
+ Gyorgy Rethy    +
+ 17-12-2020 15:19    +
+ 		+ + + + +
+ Implemented in draft 4.8.2
+
+ + diff --git a/docs/mantis/CR7969.md b/docs/mantis/CR7969.md new file mode 100644 index 0000000000000000000000000000000000000000..a1b804871aa0fb17ab66793f2e408a459434833b --- /dev/null +++ b/docs/mantis/CR7969.md @@ -0,0 +1,219 @@ + + + + + + + + + + + + + 0007969: Ambiguity with decoding of embed_values - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007969Part 09: Using XML with TTCN-3Technicalpublic27-07-2020 10:1717-12-2020 12:09
ReporterWolfgang Seka 
Assigned ToGyorgy Rethy 
PrioritynormalSeveritymajorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version4.11.1 (published 2020-05) 
Target Version4.12.1 (ongoing)Fixed in Version4.12.1 (ongoing) 
Clause Reference(s)ES 201 873-9 clause 7.6.8, B.3.10
For STF discussion
Source (company - Author)     MCC160
Summary0007969: Ambiguity with decoding of embed_values
DescriptionAccording to ES 201 873-9 clause 7.6.8 for mixed xml content in TTCN templates there is a list of strings which carries the embedded text of the xml element: "record of XSD.String embed_values".
+In addition, clause 7.6.8 specifies that the length of this list "shall not exceed" the number of elements plus one.
+
+=> The wording according to clause 7.6.8 allows in a template that embed_values contains 0 .. N+1 strings.
+
+This causes a problem for writing receive templates as in general it is up to codec implementation how many empty strings it adds to embed_values.
+
+Example: Assuming a "mixed type" with two elements and no embedded text being expected in the received xml document in principle it would be necessary to specify embed_values as
+         embed_values := ({}, {""}, {"", ""}, {"", "", ""})
+to cope with all possible variants of codec behaviour.
+
+In addition, when there is an elem_list it seems that the maximum length of embed_values is even unpredictable.
+
+NOTE: In practice there is especially the question whether the codec generates '{}' or '{""}'.
+
+Conclusion: There shall be a rule for codec implementation not to provide any empty strings at the end of embed_values
+=> when there is no embedded text it shall result in embed_values := {}
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7969-1.docx (152,514) 12-08-2020 10:57
http://oldforge.etsi.org/mantis/file_download.php?file_id=3920&type=bug
docx CR7969-2.docx (152,943) 13-08-2020 08:08
http://oldforge.etsi.org/mantis/file_download.php?file_id=3928&type=bug
Issue History
Date ModifiedUsernameFieldChange
27-07-2020 10:17Wolfgang SekaNew Issue
10-08-2020 10:05Jens GrabowskiProjectTTCN-3 Change Requests => Part 09: Using XML with TTCN-3
10-08-2020 10:08Jens GrabowskiAssigned To => Tomas Urban
10-08-2020 10:08Jens GrabowskiStatusnew => assigned
12-08-2020 10:57Tomas UrbanFile Added: CR7969-1.docx
12-08-2020 10:59Tomas UrbanNote Added: 0015707
12-08-2020 10:59Tomas UrbanAssigned ToTomas Urban => Kristóf Szabados
12-08-2020 10:59Tomas UrbanStatusassigned => confirmed
12-08-2020 12:02Kristóf SzabadosNote Added: 0015708
12-08-2020 12:40Kristóf SzabadosAssigned ToKristóf Szabados => Tomas Urban
12-08-2020 12:40Kristóf SzabadosStatusconfirmed => assigned
13-08-2020 08:08Tomas UrbanFile Added: CR7969-2.docx
13-08-2020 08:09Tomas UrbanNote Added: 0015718
13-08-2020 08:09Tomas UrbanAssigned ToTomas Urban => Kristóf Szabados
13-08-2020 08:09Tomas UrbanStatusassigned => confirmed
13-08-2020 10:37Kristóf SzabadosNote Added: 0015725
13-08-2020 10:38Kristóf SzabadosStatusconfirmed => resolved
13-08-2020 10:38Kristóf SzabadosResolutionopen => fixed
13-08-2020 10:38Kristóf SzabadosAssigned ToKristóf Szabados => Gyorgy Rethy
17-12-2020 12:09Gyorgy RethyNote Added: 0015881
17-12-2020 12:09Gyorgy RethyStatusresolved => closed
17-12-2020 12:09Gyorgy RethyProduct Version => 4.11.1 (published 2020-05)
17-12-2020 12:09Gyorgy RethyFixed in Version => 4.12.1 (ongoing)
17-12-2020 12:09Gyorgy RethyTarget Version => 4.12.1 (ongoing)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015707) +
+ Tomas Urban    +
+ 12-08-2020 10:59    +
+ 		+ + + + +
+ I added a rule to the section B that instructs the codec to automatically remove all empty strings from the end of the embed_values field at the end of decoding.
+
+Please check.
+
+
+
+ + + + + + + + + + +
+ (0015708) +
+ Kristóf Szabados    +
+ 12-08-2020 12:02    +
+ 		+ + + + +
+ Just one note: currently the description makes it sound like decoding is a part of encoding.
+
+Othwerwise the change looks good.
+
+
+
+ + + + + + + + + + +
+ (0015718) +
+ Tomas Urban    +
+ 13-08-2020 08:09    +
+ 		+ + + + +
+ I separated the decoding rules from encoding rules. Please check.
+
+
+
+ + + + + + + + + + +
+ (0015725) +
+ Kristóf Szabados    +
+ 13-08-2020 10:37    +
+ 		+ + + + +
+ Looks good to me, can be added to the next version of the standard.
+
+
+
+ + + + + + + + + + +
+ (0015881) +
+ Gyorgy Rethy    +
+ 17-12-2020 12:09    +
+ 		+ + + + +
+ Implemented in draft 4.11.2
+
+ + diff --git a/docs/mantis/CR7971.md b/docs/mantis/CR7971.md new file mode 100644 index 0000000000000000000000000000000000000000..f7e9a0564b15ad2c428d751b6fd8b0a25465a3ad --- /dev/null +++ b/docs/mantis/CR7971.md @@ -0,0 +1,110 @@ + + + + + + + + + + + + + 0007971: typo in 5.2.2 - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007971Part 01: TTCN-3 Core LanguageEditorialpublic13-08-2020 10:4616-12-2020 16:07
ReporterKristóf Szabados 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version4.12.1 (published 2020-05) 
Target Version4.13.1 (ongoing)Fixed in Version4.13.1 (ongoing) 
Clause Reference(s)5.2.2
Source (company - Author)L.M. Ericsson
Summary0007971: typo in 5.2.2
DescriptionIn section 5.2.2 in Example 3 there are 2 typos.
+
+"
+module MyModuleB {
+import from MyModuleA { … }
+function f_myFunction() {
+var integer MyModuleB:= 1; // Is NOT allowed: class with module name
+:
+}
+type boolean MyModuleA; // Is NOT allowed: class with imported module name
+}
+"
+
+Please note the example does not show classes as implied in the comments.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7971-V1-20200814.docx (69,909) 14-08-2020 07:51
http://oldforge.etsi.org/mantis/file_download.php?file_id=3942&type=bug
Issue History
Date ModifiedUsernameFieldChange
13-08-2020 10:46Kristóf SzabadosNew Issue
13-08-2020 13:39Jens GrabowskiNote Added: 0015730
13-08-2020 13:39Jens GrabowskiAssigned To => Jens Grabowski
13-08-2020 13:39Jens GrabowskiStatusnew => assigned
14-08-2020 07:51Jens GrabowskiFile Added: CR7971-V1-20200814.docx
14-08-2020 07:52Jens GrabowskiStatusassigned => resolved
14-08-2020 07:52Jens GrabowskiResolutionopen => fixed
14-08-2020 07:52Jens GrabowskiAssigned ToJens Grabowski => Gyorgy Rethy
16-12-2020 16:07Gyorgy RethyNote Added: 0015866
16-12-2020 16:07Gyorgy RethyStatusresolved => closed
16-12-2020 16:07Gyorgy RethyProduct Version => 4.12.1 (published 2020-05)
16-12-2020 16:07Gyorgy RethyFixed in Version => 4.13.1 (ongoing)
16-12-2020 16:07Gyorgy RethyTarget Version => 4.13.1 (ongoing)
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015730) +
+ Jens Grabowski    +
+ 13-08-2020 13:39    +
+ 		+ + + + +
+ Use clash instead of class.
+
+
+
+ + + + + + + + + + +
+ (0015866) +
+ Gyorgy Rethy    +
+ 16-12-2020 16:07    +
+ 		+ + + + +
+ Implemented in draft 4.12.2
+
+ + diff --git a/docs/mantis/CR7972.md b/docs/mantis/CR7972.md new file mode 100644 index 0000000000000000000000000000000000000000..b9e732c910beadf37bb0bc298fa3583868c8e4ba --- /dev/null +++ b/docs/mantis/CR7972.md @@ -0,0 +1,71 @@ + + + + + + + + + + + + + 0007972: bad formatting in 16.1.5 - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007972Part 01: TTCN-3 Core LanguageEditorialpublic13-08-2020 12:4716-12-2020 16:10
ReporterKristóf Szabados 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version4.12.1 (published 2020-05) 
Target Version4.13.1 (ongoing)Fixed in Version4.13.1 (ongoing) 
Clause Reference(s)16.1.5
Source (company - Author)L.M. Ericsson
Summary0007972: bad formatting in 16.1.5
DescriptionSection 16.1.5 has a bad formatting issue.
+
+"
+Explicit control functions are declared either by use of the name control or by use of the @controlmodifier.Restrictions
+
+In addition to the general static
+"
+
+"Restrictions" is usually a new paragraph
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7972-V1-20200814.docx (68,871) 14-08-2020 08:10
http://oldforge.etsi.org/mantis/file_download.php?file_id=3946&type=bug
Issue History
Date ModifiedUsernameFieldChange
13-08-2020 12:47Kristóf SzabadosNew Issue
13-08-2020 13:38Jens GrabowskiAssigned To => Jens Grabowski
13-08-2020 13:38Jens GrabowskiStatusnew => assigned
14-08-2020 08:10Jens GrabowskiFile Added: CR7972-V1-20200814.docx
14-08-2020 08:10Jens GrabowskiStatusassigned => resolved
14-08-2020 08:10Jens GrabowskiResolutionopen => fixed
14-08-2020 08:10Jens GrabowskiAssigned ToJens Grabowski => Gyorgy Rethy
16-12-2020 16:10Gyorgy RethyNote Added: 0015867
16-12-2020 16:10Gyorgy RethyStatusresolved => closed
16-12-2020 16:10Gyorgy RethyProduct Version => 4.12.1 (published 2020-05)
16-12-2020 16:10Gyorgy RethyFixed in Version => 4.13.1 (ongoing)
16-12-2020 16:10Gyorgy RethyTarget Version => 4.13.1 (ongoing)
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015867) +
+ Gyorgy Rethy    +
+ 16-12-2020 16:10    +
+ 		+ + + + +
+ Implemented in draft 4.12.2
+
+ + diff --git a/docs/mantis/CR7973.md b/docs/mantis/CR7973.md new file mode 100644 index 0000000000000000000000000000000000000000..65d0172453f2e91706a4b5bb09f5215d955b54d2 --- /dev/null +++ b/docs/mantis/CR7973.md @@ -0,0 +1,171 @@ + + + + + + + + + + + + + 0007973: Update of Figure 1 in TTCN-3 part 1 - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007973Part 01: TTCN-3 Core LanguageEditorialpublic13-08-2020 12:5516-12-2020 16:37
ReporterAxel Rennoch 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version4.12.1 (published 2020-05) 
Target Version4.13.1 (ongoing)Fixed in Version4.13.1 (ongoing) 
Clause Reference(s)part 1, clause 4
Source (company - Author)Axel Rennoch (FOKUS)
Summary0007973: Update of Figure 1 in TTCN-3 part 1
DescriptionFigure 1 "User's view of the core language and the various presentation formats" is present in TTCN-3 parts 1, 7, 8, 9 and 11.
+
+The most complete picture is given in part 1. However it is missing some boxes (parts and packages). The figures in parts 7 and 9 are not correct, since the relevant box is shaded (but should be not shaded).
+
+The figures should be updated, corrected and aligned to provide a complete unique view on the different parts and packages.
+
+Boxes related to presentation formats shall be removed, since TFT and GFT are not maintained.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0007977closed Gyorgy Rethy Part 11: Using JSON with TTCN-3 Update of Figure 1 in TTCN-3 part 11 
related to 0007976closed Gyorgy Rethy Part 09: Using XML with TTCN-3 Update of Figure 1 in TTCN-3 part 9 
related to 0007975closed Gyorgy Rethy Part 08: Using IDL with TTCN-3 Update of Figure 1 in TTCN-3 part 8 
related to 0007974closed Gyorgy Rethy Part 07: Using ASN.1 with TTCN-3 Update of Figure 1 in TTCN-3 part 7 
Attached Filesdocx es_20187301v041201p-0007973.docx (188,695) 13-08-2020 16:17
http://oldforge.etsi.org/mantis/file_download.php?file_id=3937&type=bug
docx es_20187301v041201p-0007973r1.docx (188,804) 14-08-2020 09:05
http://oldforge.etsi.org/mantis/file_download.php?file_id=3948&type=bug
Issue History
Date ModifiedUsernameFieldChange
13-08-2020 12:55Axel RennochNew Issue
13-08-2020 13:35Jens GrabowskiAssigned To => Axel Rennoch
13-08-2020 13:35Jens GrabowskiStatusnew => assigned
13-08-2020 14:20Axel RennochClause Reference(s)4 => part 1, clause 4
13-08-2020 14:20Axel RennochSummaryUpdate of Figure 1 in TTCN-3 parts 1, 7, 8, 9 and 11 => Update of Figure 1 in TTCN-3 part 1
13-08-2020 14:20Axel RennochDescription Updatedbug_revision_view_page.php?rev_id=528#r528
13-08-2020 14:30Axel RennochRelationship addedrelated to 0007977
13-08-2020 14:30Axel RennochRelationship addedrelated to 0007976
13-08-2020 14:31Axel RennochRelationship addedrelated to 0007975
13-08-2020 14:31Axel RennochRelationship addedrelated to 0007974
13-08-2020 16:17Axel RennochFile Added: es_20187301v041201p-0007973.docx
13-08-2020 16:18Axel RennochAssigned ToAxel Rennoch => Jens Grabowski
13-08-2020 16:18Axel RennochNote Added: 0015732
13-08-2020 16:18Axel RennochStatusassigned => confirmed
14-08-2020 08:31Jens GrabowskiNote Added: 0015742
14-08-2020 08:31Jens GrabowskiStatusconfirmed => assigned
14-08-2020 08:32Jens GrabowskiProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
14-08-2020 08:36Jens GrabowskiAssigned ToJens Grabowski => Axel Rennoch
14-08-2020 09:05Axel RennochFile Added: es_20187301v041201p-0007973r1.docx
14-08-2020 09:06Axel RennochAssigned ToAxel Rennoch => Jens Grabowski
14-08-2020 09:07Axel RennochNote Added: 0015743
14-08-2020 09:07Axel RennochStatusassigned => acknowledged
14-08-2020 09:10Axel RennochStatusacknowledged => confirmed
14-08-2020 09:34Jens GrabowskiStatusconfirmed => resolved
14-08-2020 09:34Jens GrabowskiResolutionopen => fixed
14-08-2020 09:34Jens GrabowskiAssigned ToJens Grabowski => Gyorgy Rethy
16-12-2020 16:37Gyorgy RethyNote Added: 0015869
16-12-2020 16:37Gyorgy RethyStatusresolved => closed
16-12-2020 16:37Gyorgy RethyProduct Version => 4.12.1 (published 2020-05)
16-12-2020 16:37Gyorgy RethyFixed in Version => 4.13.1 (ongoing)
16-12-2020 16:37Gyorgy RethyTarget Version => 4.13.1 (ongoing)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015732) +
+ Axel Rennoch    +
+ 13-08-2020 16:18    +
+ 		+ + + + +
+ please see new figure
+
+
+
+ + + + + + + + + + +
+ (0015742) +
+ Jens Grabowski    +
+ 14-08-2020 08:31    +
+ 		+ + + + +
+ see 0007977 (no reference to a presentation format)
+
+
+
+ + + + + + + + + + +
+ (0015743) +
+ Axel Rennoch    +
+ 14-08-2020 09:07    +
+ 		+ + + + +
+ caption changed
+
+
+
+ + + + + + + + + + +
+ (0015869) +
+ Gyorgy Rethy    +
+ 16-12-2020 16:37    +
+ 		+ + + + +
+ Implemented in draft 4.12.2
+
+ + diff --git a/docs/mantis/CR7974.md b/docs/mantis/CR7974.md new file mode 100644 index 0000000000000000000000000000000000000000..8ae5a361c5b26e1c0e4400b568861072d727c967 --- /dev/null +++ b/docs/mantis/CR7974.md @@ -0,0 +1,171 @@ + + + + + + + + + + + + + 0007974: Update of Figure 1 in TTCN-3 part 7 - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 07: Using ASN.1 with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007974Part 07: Using ASN.1 with TTCN-3Editorialpublic13-08-2020 14:2317-12-2020 11:34
ReporterAxel Rennoch 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.8.1 (published 2020-05) 
Target Versionv4.9.1 (ongoing)Fixed in Versionv4.9.1 (ongoing) 
Clause Reference(s)part 7, clause 4
Source (company - Author)Axel Rennoch (FOKUS)
Summary0007974: Update of Figure 1 in TTCN-3 part 7
DescriptionFigure 1 "User's view of the core language and the various presentation formats" is present in TTCN-3 parts 1, 7, 8, 9 and 11.
+
+The most complete picture is given in part 1. However it is missing some boxes (parts and packages). The figures in parts 7 and 9 are not correct, since the relevant box is shaded (but should be not shaded).
+
+The figures should be updated, corrected and aligned to provide a complete unique view on the different parts and packages.
+
+Boxes related to presentation formats shall be removed, since TFT and GFT are not maintained.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0007973closed Gyorgy Rethy Part 01: TTCN-3 Core Language Update of Figure 1 in TTCN-3 part 1 
Attached Filesdocx es_20187307v040801p-0007974.docx (88,105) 13-08-2020 16:19
http://oldforge.etsi.org/mantis/file_download.php?file_id=3938&type=bug
docx es_20187307v040801p-0007974r1.docx (88,192) 14-08-2020 09:07
http://oldforge.etsi.org/mantis/file_download.php?file_id=3949&type=bug
Issue History
Date ModifiedUsernameFieldChange
13-08-2020 14:23Axel RennochNew Issue
13-08-2020 14:23Axel RennochStatusnew => assigned
13-08-2020 14:23Axel RennochAssigned To => Axel Rennoch
13-08-2020 14:31Axel RennochRelationship addedrelated to 0007973
13-08-2020 16:19Axel RennochFile Added: es_20187307v040801p-0007974.docx
13-08-2020 16:19Axel RennochNote Added: 0015733
13-08-2020 16:19Axel RennochAssigned ToAxel Rennoch => Jens Grabowski
13-08-2020 16:19Axel RennochStatusassigned => confirmed
14-08-2020 08:31Jens GrabowskiNote Added: 0015741
14-08-2020 08:31Jens GrabowskiAssigned ToJens Grabowski => Axel Rennoch
14-08-2020 08:31Jens GrabowskiStatusconfirmed => assigned
14-08-2020 09:07Axel RennochFile Added: es_20187307v040801p-0007974r1.docx
14-08-2020 09:08Axel RennochNote Added: 0015744
14-08-2020 09:08Axel RennochAssigned ToAxel Rennoch => Jens Grabowski
14-08-2020 09:08Axel RennochStatusassigned => acknowledged
14-08-2020 09:10Axel RennochStatusacknowledged => confirmed
14-08-2020 09:34Jens GrabowskiStatusconfirmed => resolved
14-08-2020 09:34Jens GrabowskiResolutionopen => fixed
14-08-2020 09:34Jens GrabowskiAssigned ToJens Grabowski => Gyorgy Rethy
17-12-2020 11:34Gyorgy RethyNote Added: 0015877
17-12-2020 11:34Gyorgy RethyStatusresolved => closed
17-12-2020 11:34Gyorgy RethyFixed in Version => v4.9.1 (ongoing)
17-12-2020 11:34Gyorgy RethyTarget VersionNext version (to be defined) => v4.9.1 (ongoing)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015733) +
+ Axel Rennoch    +
+ 13-08-2020 16:19    +
+ 		+ + + + +
+ please see new figure
+
+
+
+ + + + + + + + + + +
+ (0015741) +
+ Jens Grabowski    +
+ 14-08-2020 08:31    +
+ 		+ + + + +
+ see 0007977 (no reference to a presentation format)
+
+
+
+ + + + + + + + + + +
+ (0015744) +
+ Axel Rennoch    +
+ 14-08-2020 09:08    +
+ 		+ + + + +
+ caption changed
+
+
+
+ + + + + + + + + + +
+ (0015877) +
+ Gyorgy Rethy    +
+ 17-12-2020 11:34    +
+ 		+ + + + +
+ Implemented in draft 4.8.2
+
+ + diff --git a/docs/mantis/CR7975.md b/docs/mantis/CR7975.md new file mode 100644 index 0000000000000000000000000000000000000000..edf1f2f3bb1c021d8c59aaf91eae83d01842c894 --- /dev/null +++ b/docs/mantis/CR7975.md @@ -0,0 +1,171 @@ + + + + + + + + + + + + + 0007975: Update of Figure 1 in TTCN-3 part 8 - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 08: Using IDL with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007975Part 08: Using IDL with TTCN-3Editorialpublic13-08-2020 14:2517-12-2020 11:48
ReporterAxel Rennoch 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.7.1 (published 2017-05) 
Target Versionv4.8.1 (ongoing)Fixed in Versionv4.8.1 (ongoing) 
Clause Reference(s)part 8, clause 4
Source (company - Author)Axel Rennoch (FOKUS)
Summary0007975: Update of Figure 1 in TTCN-3 part 8
DescriptionFigure 1 "User's view of the core language and the various presentation formats" is present in TTCN-3 parts 1, 7, 8, 9 and 11.
+
+The most complete picture is given in part 1. However it is missing some boxes (parts and packages). The figures in parts 7 and 9 are not correct, since the relevant box is shaded (but should be not shaded).
+
+The figures should be updated, corrected and aligned to provide a complete unique view on the different parts and packages.
+
+Boxes related to presentation formats shall be removed, since TFT and GFT are not maintained.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0007973closed Gyorgy Rethy Part 01: TTCN-3 Core Language Update of Figure 1 in TTCN-3 part 1 
Attached Filesdocx es_20187308v040701p-0007975.docx (168,407) 13-08-2020 16:20
http://oldforge.etsi.org/mantis/file_download.php?file_id=3939&type=bug
docx es_20187308v040701p-0007975r1.docx (168,646) 14-08-2020 09:08
http://oldforge.etsi.org/mantis/file_download.php?file_id=3950&type=bug
Issue History
Date ModifiedUsernameFieldChange
13-08-2020 14:25Axel RennochNew Issue
13-08-2020 14:25Axel RennochStatusnew => assigned
13-08-2020 14:25Axel RennochAssigned To => Axel Rennoch
13-08-2020 14:31Axel RennochRelationship addedrelated to 0007973
13-08-2020 16:20Axel RennochFile Added: es_20187308v040701p-0007975.docx
13-08-2020 16:20Axel RennochNote Added: 0015734
13-08-2020 16:20Axel RennochAssigned ToAxel Rennoch => Jens Grabowski
13-08-2020 16:20Axel RennochStatusassigned => confirmed
14-08-2020 08:30Jens GrabowskiNote Added: 0015740
14-08-2020 08:30Jens GrabowskiAssigned ToJens Grabowski => Axel Rennoch
14-08-2020 08:30Jens GrabowskiStatusconfirmed => assigned
14-08-2020 09:08Axel RennochFile Added: es_20187308v040701p-0007975r1.docx
14-08-2020 09:08Axel RennochNote Added: 0015745
14-08-2020 09:08Axel RennochAssigned ToAxel Rennoch => Jens Grabowski
14-08-2020 09:08Axel RennochStatusassigned => confirmed
14-08-2020 09:37Jens GrabowskiStatusconfirmed => resolved
14-08-2020 09:37Jens GrabowskiResolutionopen => fixed
14-08-2020 09:37Jens GrabowskiAssigned ToJens Grabowski => Gyorgy Rethy
17-12-2020 11:48Gyorgy RethyNote Added: 0015878
17-12-2020 11:48Gyorgy RethyStatusresolved => closed
17-12-2020 11:48Gyorgy RethyFixed in Version => v4.8.1 (ongoing)
17-12-2020 11:48Gyorgy RethyTarget VersionNext version (to be defined) => v4.8.1 (ongoing)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015734) +
+ Axel Rennoch    +
+ 13-08-2020 16:20    +
+ 		+ + + + +
+ please see new figure
+
+
+
+ + + + + + + + + + +
+ (0015740) +
+ Jens Grabowski    +
+ 14-08-2020 08:30    +
+ 		+ + + + +
+ see 0007977 (no reference to a presentation format)
+
+
+
+ + + + + + + + + + +
+ (0015745) +
+ Axel Rennoch    +
+ 14-08-2020 09:08    +
+ 		+ + + + +
+ caption changed
+
+
+
+ + + + + + + + + + +
+ (0015878) +
+ Gyorgy Rethy    +
+ 17-12-2020 11:48    +
+ 		+ + + + +
+ Implemented in draft 4.7.2
+
+ + diff --git a/docs/mantis/CR7976.md b/docs/mantis/CR7976.md new file mode 100644 index 0000000000000000000000000000000000000000..c780eaaf17e6e6f7fbf147317e21babf6b803c9a --- /dev/null +++ b/docs/mantis/CR7976.md @@ -0,0 +1,171 @@ + + + + + + + + + + + + + 0007976: Update of Figure 1 in TTCN-3 part 9 - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007976Part 09: Using XML with TTCN-3Editorialpublic13-08-2020 14:2717-12-2020 12:03
ReporterAxel Rennoch 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version4.11.1 (published 2020-05) 
Target Version4.12.1 (ongoing)Fixed in Version4.12.1 (ongoing) 
Clause Reference(s)part 9, clause 4
For STF discussion
Source (company - Author)Axel Rennoch (FOKUS)
Summary0007976: Update of Figure 1 in TTCN-3 part 9
DescriptionFigure 1 "User's view of the core language and the various presentation formats" is present in TTCN-3 parts 1, 7, 8, 9 and 11.
+
+The most complete picture is given in part 1. However it is missing some boxes (parts and packages). The figures in parts 7 and 9 are not correct, since the relevant box is shaded (but should be not shaded).
+
+The figures should be updated, corrected and aligned to provide a complete unique view on the different parts and packages.
+
+Boxes related to presentation formats shall be removed, since TFT and GFT are not maintained.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0007973closed Gyorgy Rethy Part 01: TTCN-3 Core Language Update of Figure 1 in TTCN-3 part 1 
Attached Filesdocx es_20187309v041101p-0007976.docx (184,485) 13-08-2020 16:20
http://oldforge.etsi.org/mantis/file_download.php?file_id=3940&type=bug
docx es_20187309v041101p-0007976r1.docx (184,608) 14-08-2020 09:09
http://oldforge.etsi.org/mantis/file_download.php?file_id=3951&type=bug
Issue History
Date ModifiedUsernameFieldChange
13-08-2020 14:27Axel RennochNew Issue
13-08-2020 14:27Axel RennochStatusnew => assigned
13-08-2020 14:27Axel RennochAssigned To => Axel Rennoch
13-08-2020 14:30Axel RennochRelationship addedrelated to 0007973
13-08-2020 16:20Axel RennochFile Added: es_20187309v041101p-0007976.docx
13-08-2020 16:21Axel RennochNote Added: 0015735
13-08-2020 16:21Axel RennochAssigned ToAxel Rennoch => Jens Grabowski
13-08-2020 16:21Axel RennochStatusassigned => confirmed
14-08-2020 08:29Jens GrabowskiNote Added: 0015739
14-08-2020 08:30Jens GrabowskiAssigned ToJens Grabowski => Axel Rennoch
14-08-2020 08:30Jens GrabowskiStatusconfirmed => assigned
14-08-2020 09:09Axel RennochFile Added: es_20187309v041101p-0007976r1.docx
14-08-2020 09:09Axel RennochNote Added: 0015746
14-08-2020 09:09Axel RennochAssigned ToAxel Rennoch => Jens Grabowski
14-08-2020 09:09Axel RennochStatusassigned => confirmed
14-08-2020 09:36Jens GrabowskiStatusconfirmed => resolved
14-08-2020 09:36Jens GrabowskiResolutionopen => fixed
14-08-2020 09:36Jens GrabowskiAssigned ToJens Grabowski => Gyorgy Rethy
17-12-2020 12:03Gyorgy RethyNote Added: 0015880
17-12-2020 12:03Gyorgy RethyStatusresolved => closed
17-12-2020 12:03Gyorgy RethyFixed in Version => 4.12.1 (ongoing)
17-12-2020 12:03Gyorgy RethyTarget Version4.11.1 (published 2020-05) => 4.12.1 (ongoing)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015735) +
+ Axel Rennoch    +
+ 13-08-2020 16:21    +
+ 		+ + + + +
+ please see new figure
+
+
+
+ + + + + + + + + + +
+ (0015739) +
+ Jens Grabowski    +
+ 14-08-2020 08:29    +
+ 		+ + + + +
+ see 0007977 (no reference to a presentation format)
+
+
+
+ + + + + + + + + + +
+ (0015746) +
+ Axel Rennoch    +
+ 14-08-2020 09:09    +
+ 		+ + + + +
+ caption changed
+
+
+
+ + + + + + + + + + +
+ (0015880) +
+ Gyorgy Rethy    +
+ 17-12-2020 12:03    +
+ 		+ + + + +
+ Implemented in draft 4.11.2
+
+ + diff --git a/docs/mantis/CR7977.md b/docs/mantis/CR7977.md new file mode 100644 index 0000000000000000000000000000000000000000..f98a92da31c8da9ad3bb702bdfea70a05dfaa8fd --- /dev/null +++ b/docs/mantis/CR7977.md @@ -0,0 +1,171 @@ + + + + + + + + + + + + + 0007977: Update of Figure 1 in TTCN-3 part 11 - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 11: Using JSON with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007977Part 11: Using JSON with TTCN-3[TTCN-3 Change Requests] Editorialpublic13-08-2020 14:2917-12-2020 15:02
ReporterAxel Rennoch 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product VersionV4.8.1 (published 2020-05) 
Target VersionV4.9.1 (ongoing)Fixed in VersionV4.9.1 (ongoing) 
Summary0007977: Update of Figure 1 in TTCN-3 part 11
DescriptionFigure 1 "User's view of the core language and the various presentation formats" is present in TTCN-3 parts 1, 7, 8, 9 and 11.
+
+The most complete picture is given in part 1. However it is missing some boxes (parts and packages). The figures in parts 7 and 9 are not correct, since the relevant box is shaded (but should be not shaded).
+
+The figures should be updated, corrected and aligned to provide a complete unique view on the different parts and packages.
+
+Boxes related to presentation formats shall be removed, since TFT and GFT are not maintained.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0007973closed Gyorgy Rethy Part 01: TTCN-3 Core Language Update of Figure 1 in TTCN-3 part 1 
Attached Filesdocx es_20187311v040801p-0007977.docx (186,568) 13-08-2020 16:21
http://oldforge.etsi.org/mantis/file_download.php?file_id=3941&type=bug
docx es_20187311v040801p-0007977r1.docx (186,660) 14-08-2020 09:09
http://oldforge.etsi.org/mantis/file_download.php?file_id=3952&type=bug
Issue History
Date ModifiedUsernameFieldChange
13-08-2020 14:29Axel RennochNew Issue
13-08-2020 14:29Axel RennochStatusnew => assigned
13-08-2020 14:29Axel RennochAssigned To => Axel Rennoch
13-08-2020 14:30Axel RennochRelationship addedrelated to 0007973
13-08-2020 16:21Axel RennochFile Added: es_20187311v040801p-0007977.docx
13-08-2020 16:21Axel RennochNote Added: 0015736
13-08-2020 16:21Axel RennochAssigned ToAxel Rennoch => Jens Grabowski
13-08-2020 16:21Axel RennochStatusassigned => confirmed
14-08-2020 08:28Jens GrabowskiNote Added: 0015738
14-08-2020 08:28Jens GrabowskiAssigned ToJens Grabowski => Axel Rennoch
14-08-2020 08:28Jens GrabowskiStatusconfirmed => assigned
14-08-2020 09:09Axel RennochFile Added: es_20187311v040801p-0007977r1.docx
14-08-2020 09:09Axel RennochNote Added: 0015747
14-08-2020 09:09Axel RennochAssigned ToAxel Rennoch => Jens Grabowski
14-08-2020 09:09Axel RennochStatusassigned => confirmed
14-08-2020 09:35Jens GrabowskiStatusconfirmed => resolved
14-08-2020 09:35Jens GrabowskiResolutionopen => fixed
14-08-2020 09:35Jens GrabowskiAssigned ToJens Grabowski => Gyorgy Rethy
17-12-2020 15:02Gyorgy RethyNote Added: 0015884
17-12-2020 15:02Gyorgy RethyStatusresolved => closed
17-12-2020 15:02Gyorgy RethyFixed in Version => V4.9.1 (ongoing)
17-12-2020 15:02Gyorgy RethyTarget VersionV4.8.1 (published 2020-05) => V4.9.1 (ongoing)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015736) +
+ Axel Rennoch    +
+ 13-08-2020 16:21    +
+ 		+ + + + +
+ please see new figure
+
+
+
+ + + + + + + + + + +
+ (0015738) +
+ Jens Grabowski    +
+ 14-08-2020 08:28    +
+ 		+ + + + +
+ Axel: The caption of the figure says "User's view of the core language and the various presentation formats", but the figure does not include any reference to a presentation format. We may delete "and the various presentation formats".
+
+
+
+ + + + + + + + + + +
+ (0015747) +
+ Axel Rennoch    +
+ 14-08-2020 09:09    +
+ 		+ + + + +
+ caption changed
+
+
+
+ + + + + + + + + + +
+ (0015884) +
+ Gyorgy Rethy    +
+ 17-12-2020 15:02    +
+ 		+ + + + +
+ Implemented in draft 4.8.2
+
+ + diff --git a/docs/mantis/CR7978.md b/docs/mantis/CR7978.md new file mode 100644 index 0000000000000000000000000000000000000000..a000f5272f8bf26979cadbecf0918f2e50eccedd --- /dev/null +++ b/docs/mantis/CR7978.md @@ -0,0 +1,676 @@ + + + + + + + + + + + + + 0007978: Dealing with parallel control components - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Config & Deployment Support (ES 202 781)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007978Ext Pack: Config & Deployment Support (ES 202 781)New Featurepublic13-08-2020 15:0018-12-2020 14:36
ReporterJacob Wieland - Spirent 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv1.7.1 (published 2019-04) 
Target Versionv1.8.1 (ongoing)Fixed in Versionv1.8.1 (ongoing) 
Clause Reference(s)6.1.13, 7.3.3, 8.5.3, 9.4.3, 10.6.3,12.5.3, C.3
Source (company - Author)Spirent - Jacob Wieland
TS version
Summary0007978: Dealing with parallel control components
DescriptionTCI functions should be added to the CH interface to deal with:
+- creation of parallel control components
+- starting of PCCs
+- termination of PCCs
+- done/killed of PCCs
+- alive/running of PCCs
+
+These should mainly be copies of the same functionality for PTCs with the exception of verdict handling
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0007910closed Jens Grabowski Part 01: TTCN-3 Core Language Allow parallel control parts/components 
Attached Filesdocx CR7978.docx (1,419,628) 05-10-2020 13:26
http://oldforge.etsi.org/mantis/file_download.php?file_id=3955&type=bug
docx CR7978-2.docx (923,429) 08-10-2020 15:40
http://oldforge.etsi.org/mantis/file_download.php?file_id=3961&type=bug
docx CR7978-3.docx (933,358) 07-12-2020 14:53
http://oldforge.etsi.org/mantis/file_download.php?file_id=3970&type=bug
docx CR7978-4.docx (1,112,937) 08-12-2020 13:08
http://oldforge.etsi.org/mantis/file_download.php?file_id=3973&type=bug
docx CR7978-5.docx (231,066) 10-12-2020 13:19
http://oldforge.etsi.org/mantis/file_download.php?file_id=3985&type=bug
docx CR7978-6.docx (231,344) 11-12-2020 11:58
http://oldforge.etsi.org/mantis/file_download.php?file_id=3986&type=bug
docx CR7978-7.docx (275,617) 11-12-2020 12:27
http://oldforge.etsi.org/mantis/file_download.php?file_id=3987&type=bug
Issue History
Date ModifiedUsernameFieldChange
13-08-2020 15:00Jacob Wieland - SpirentNew Issue
13-08-2020 15:00Jacob Wieland - SpirentStatusnew => assigned
13-08-2020 15:00Jacob Wieland - SpirentAssigned To => Jacob Wieland - Spirent
13-08-2020 15:01Jacob Wieland - SpirentRelationship addedrelated to 0007910
05-10-2020 12:42Jacob Wieland - SpirentNote Added: 0015757
05-10-2020 13:26Jacob Wieland - SpirentFile Added: CR7978.docx
05-10-2020 13:27Jacob Wieland - SpirentNote Added: 0015758
05-10-2020 13:27Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Tomas Urban
05-10-2020 13:27Jacob Wieland - SpirentStatusassigned => confirmed
06-10-2020 13:26Jens GrabowskiAssigned ToTomas Urban => Jacob Wieland - Spirent
06-10-2020 13:26Jens GrabowskiStatusconfirmed => assigned
08-10-2020 15:40Jacob Wieland - SpirentFile Added: CR7978-2.docx
08-10-2020 15:41Jacob Wieland - SpirentNote Added: 0015782
08-10-2020 15:41Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Tomas Urban
08-10-2020 15:41Jacob Wieland - SpirentStatusassigned => confirmed
09-10-2020 08:28Tomas UrbanAssigned ToTomas Urban => Jacob Wieland - Spirent
09-10-2020 08:28Tomas UrbanStatusconfirmed => assigned
09-10-2020 08:35Tomas UrbanNote Added: 0015788
09-10-2020 15:14Jacob Wieland - SpirentProjectPart 06: TTCN-3 Control Interface => Ext Pack: Config & Deployment Support (ES 202 781)
07-12-2020 14:45Jacob Wieland - SpirentFile Added: CR7978-3.docx
07-12-2020 14:52Jacob Wieland - SpirentFile Deleted: CR7978-3.docx
07-12-2020 14:53Jacob Wieland - SpirentFile Added: CR7978-3.docx
07-12-2020 14:55Jacob Wieland - SpirentNote Added: 0015800
07-12-2020 14:55Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Tomas Urban
07-12-2020 14:55Jacob Wieland - SpirentStatusassigned => confirmed
08-12-2020 13:08Tomas UrbanFile Added: CR7978-4.docx
08-12-2020 13:12Tomas UrbanNote Added: 0015812
08-12-2020 13:12Tomas UrbanAssigned ToTomas Urban => Kristóf Szabados
09-12-2020 21:23Kristóf SzabadosNote Added: 0015830
09-12-2020 21:40Kristóf SzabadosNote Added: 0015831
09-12-2020 21:41Kristóf SzabadosAssigned ToKristóf Szabados => Jacob Wieland - Spirent
09-12-2020 21:41Kristóf SzabadosStatusconfirmed => assigned
10-12-2020 08:02Tomas UrbanNote Added: 0015834
10-12-2020 13:19Jacob Wieland - SpirentFile Added: CR7978-5.docx
10-12-2020 13:21Jacob Wieland - SpirentNote Added: 0015840
10-12-2020 13:21Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Kristof.Szabados
10-12-2020 13:21Jacob Wieland - SpirentStatusassigned => confirmed
10-12-2020 13:52Kristóf SzabadosAssigned ToKristof.Szabados => Kristóf Szabados
10-12-2020 13:52Kristóf SzabadosStatusconfirmed => assigned
10-12-2020 14:13Jacob Wieland - SpirentStatusassigned => confirmed
11-12-2020 10:29Kristóf SzabadosNote Added: 0015845
11-12-2020 10:29Kristóf SzabadosNote Added: 0015846
11-12-2020 10:30Kristóf SzabadosNote Added: 0015847
11-12-2020 10:30Kristóf SzabadosAssigned ToKristóf Szabados => Jacob Wieland - Spirent
11-12-2020 10:30Kristóf SzabadosStatusconfirmed => assigned
11-12-2020 11:58Jacob Wieland - SpirentFile Added: CR7978-6.docx
11-12-2020 11:59Jacob Wieland - SpirentNote Added: 0015848
11-12-2020 11:59Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Tomas Urban
11-12-2020 11:59Jacob Wieland - SpirentStatusassigned => confirmed
11-12-2020 12:27Tomas UrbanFile Added: CR7978-7.docx
11-12-2020 12:34Tomas UrbanNote Added: 0015849
11-12-2020 12:34Tomas UrbanStatusconfirmed => resolved
11-12-2020 12:34Tomas UrbanResolutionopen => fixed
11-12-2020 12:34Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
18-12-2020 14:36Gyorgy RethyNote Added: 0015891
18-12-2020 14:36Gyorgy RethyStatusresolved => closed
18-12-2020 14:36Gyorgy RethyProduct VersionNext version (to be defined) => v1.7.1 (published 2019-04)
18-12-2020 14:36Gyorgy RethyFixed in Version => v1.8.1 (ongoing)
18-12-2020 14:36Gyorgy RethyTarget VersionNext version (to be defined) => v1.8.1 (ongoing)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015757) +
+ Jacob Wieland - Spirent    +
+ 05-10-2020 12:42    +
+ 		+ + + + +
+ Having reviewed the existing TCI for component handling, I don't think new functionality needs to be introduced for handling of control components after all, as the CH is completely agnostic to what purpose a component has.
+
+The only exception is the functionality tciGetMTCReq/tciGetMTC.
+
+This should be supplemented by tciGetParallelMTC(TriComponentId pcc) to provide the mtc associated with the given pcc. As before, tciGetMTC() should give back the mtc executed by the MCC (if any).
+
+
+
+ + + + + + + + + + +
+ (0015758) +
+ Jacob Wieland - Spirent    +
+ 05-10-2020 13:27    +
+ 		+ + + + +
+ please review
+
+
+
+ + + + + + + + + + +
+ (0015782) +
+ Jacob Wieland - Spirent    +
+ 08-10-2020 15:41    +
+ 		+ + + + +
+ please review draft in Config&Deployment (still without TCI)
+
+
+
+ + + + + + + + + + +
+ (0015788) +
+ Tomas Urban    +
+ 09-10-2020 08:35    +
+ 		+ + + + +
+ I am basically fine with the proposed draft. However, I found three issues:
+1. any and all component operations cannot have exactly the same semantics as in the core language standard as they are related to PTCs, while they should be related to PCCs in this case.
+2. What is the use case for allowing map and connect operations in MCC and PCCs? I thought that communication operations are used only for controlling the test execution, i.e. for exchanging data between the control components. Are they supposed to be used for setting up the test run on the SUT side? If it is so, we should add a note explaining this so that users don't start to implement test logic directly in the control components.
+3. There's a typo in the 2nd paragraph of 5.3.0 exected -> executed
+
+
+
+ + + + + + + + + + +
+ (0015800) +
+ Jacob Wieland - Spirent    +
+ 07-12-2020 14:55    +
+ 		+ + + + +
+ I have addressed the issues and added the other changes to the TciCHRequired/TciCHProvided interfaces in the different language mappings needed for getting the mtc associated with a running pcc.
+
+
+
+ + + + + + + + + + +
+ (0015812) +
+ Tomas Urban    +
+ 08-12-2020 13:12    +
+ 		+ + + + +
+ I am mostly fine with the last proposal, I only made two minor changes:
+- changed "testcase" to "test case" as the core language specification usually uses the latter term
+- added a note describing the purpose of communication between MCC/PCC and the SUT
+
+Since it is a long proposal, could you please check it two and if you are fine with it, assign it back to Jacob for final acceptance.
+
+
+
+ + + + + + + + + + +
+ (0015830) +
+ Kristóf Szabados    +
+ 09-12-2020 21:23    +
+ 		+ + + + +
+ 1)
+Teh description sounds a bit confusing. There is nothing on what an MCC or PCC is, but there is a description on what it might do.
+
+2)
+I know this is nitpicking, but according to the current description an MCC may create PCC while "executing" a control function ... but is also allowed for it to simply not do anything, irrespective of what the user wanted.
+
+Please note that the core in similar circumstances talks about executing the behaviour defined in the body of the test case ... aka. the behaviour is performed, while the current description allows to simply write out onto the screen "executig the control function".
+
+Also in the core the behaviour shall execute on the component ... not may do something.
+
+3)
+Please note that according to the current description parallel test execution is not yet allowed.
+The core states: "Within every configuration there shall be one (and only one) Main Test Component (MTC)"
+
+As this is not overriden here, effectively it does not matter how many PCC there are in the system, only one of them can have a test case executing at any point in time.
+
+
+
+ + + + + + + + + + +
+ (0015831) +
+ Kristóf Szabados    +
+ 09-12-2020 21:40    +
+ 		+ + + + +
+ 4)
+It is not clear how the existing component operations, like any component, changes.
+
+The current description contains: "coordinated parallel execution of independent test cases "
+
+However if each test cases running parallelly on PCCs is independent, than any component and all component shall refer only to the components started on the PCC they are invoked on, not every component in the whole system irrespective of which PCC they were started on.
+
+Otherwise the test cases are not independent.
+
+5)
+Actually any component and all component, if I understand correctly should refer to different set of PTCs on each PCC and a separate set of PCCs on the MCC.
+
+6)
+According to the core standard the create operation shall return a unique component reference of the newly created instance.
+
+In the context of MCC and PCCs, it needs to be clarified if that means systemwide uniqueness or uniqueness only in the context of a given PCC.
+(for example when tools log something also containing the component reference do we wish to allow to have the same component reference on several PCC -s confusing the user or not)
+
+
+
+ + + + + + + + + + +
+ (0015834) +
+ Tomas Urban    +
+ 10-12-2020 08:02    +
+ 		+ + + + +
+ I think Kristof's remarks are addressed to Jacob, who is the author of the proposal. Jacob, could you please comment?
+
+
+
+ + + + + + + + + + +
+ (0015840) +
+ Jacob Wieland - Spirent    +
+ 10-12-2020 13:21    +
+ 		+ + + + +
+ I have addressed all your points in the last draft. Please review.
+
+
+
+ + + + + + + + + + +
+ (0015845) +
+ Kristóf Szabados    +
+ 11-12-2020 10:29    +
+ 		+ + + + +
+ 1)
+maybe there should be a note for implementors, that while the local ids of components can be the same in different testcases, they can also differ (having a benefit during human processing of logs)
+
+2)
+"test`case " might be a typo.
+
+3)
+"When the main control function is started"
+Please note, that the term "main control function" is not defined.
+
+Maybe we could say that the "control function started first is called/becomes the main control function"
+
+
+
+ + + + + + + + + + +
+ (0015846) +
+ Kristóf Szabados    +
+ 11-12-2020 10:29    +
+ 		+ + + + +
+ 4)
+"Inside the behaviour definition being executed by a control component it is allowed to dynamically create additional parallel control components (PCCs) and start them with other control behaviour "
+
+This seems to contradict itself.
+If control components are not allowed to execute behaviour (other than creating additional parallel control components), there is no point in trying to start them with a behaviour (PCC -s are also control components).
+
+5)
+"The restriction that in every configuration there shall be one (and only one) MTC is amended to that in every test case configuration shall be exactly one MTC"
+
+This is a strange sentence.
+If there is only one MTC, than that is the only one MTC in every test case configuration.
+
+6)
+"Control hehaviour has no way of referencing components created for an executed test case"
+
+A control behaviour can be any function called by control directly or indirectly.
+The exact same function could also be called by a testcase directly or indirectly.
+This might cause confusion in users, regarding what exactly for example any component will mean, loking at only the code of the function.
+
+
+
+ + + + + + + + + + +
+ (0015847) +
+ Kristóf Szabados    +
+ 11-12-2020 10:30    +
+ 		+ + + + +
+ 7)
+"The component operations create, start, call, stop, kill, running, alive, done, killed shall be allowed to be used also in control behaviour with the same semantics and the same restrictions as for test components inside test behaviour "
+
+Can PCC -s be alive?
+And this way, transfer information from 1 test case to the next?
+
+8)
+"The semantics of alt statements and interleave statements as well as the activate and deactivate operations are the same as for test case behaviour"
+
+I would believe they should rather work like any component and all component, in the sense that each test case behaiour and each PCC should have their own distinct set of activated defaults ... otherwise there can be sideeffects between the tests.
+
+9)
+"As for the MCC, the execute operation inside PCC behaviour will block until either the executed test case has terminated or the given timeout has occurred and test execution has been stopped"
+
+This sounds strange.
+Like ... lets talk about the MCC! <switching topic> the PCC behaves like this and that.
+
+There was also no mention of the MCC being a PCC so far.
+
+
+
+ + + + + + + + + + +
+ (0015848) +
+ Jacob Wieland - Spirent    +
+ 11-12-2020 11:59    +
+ 		+ + + + +
+ Addressed the issues as discussed in the meeting. please check.
+
+
+
+ + + + + + + + + + +
+ (0015849) +
+ Tomas Urban    +
+ 11-12-2020 12:34    +
+ 		+ + + + +
+ The proposal is mostly fine, but I made three changes in the final draft:
+
+1. Added the following sentence to address Kristof's points 0000004 and 0000005:
+PCCs are allowed to execute test cases independently and in parallel with test cases being executed on other PCCs and the MCC.
+
+2. Changed the expression "test case behaviour" to "behaviour executed on a test component" to address Kristof's point 0000008
+
+3. Replaced TTCN-3 upper case letter with lower case in TTCN-3 operations listed in the table 2.
+
+All these changes were discussed with Jacob who approved them.
+
+With these small updates, the proposal is ready to be included in the next version of the specification.
+
+
+
+ + + + + + + + + + +
+ (0015891) +
+ Gyorgy Rethy    +
+ 18-12-2020 14:36    +
+ 		+ + + + +
+ Implemented in draft 1.7.2
+
+ + diff --git a/docs/mantis/CR7981.md b/docs/mantis/CR7981.md new file mode 100644 index 0000000000000000000000000000000000000000..a35d5d838577ee89ee89fca1e82bed9ab14d2602 --- /dev/null +++ b/docs/mantis/CR7981.md @@ -0,0 +1,215 @@ + + + + + + + + + + + + + 0007981: Support for REST APIs (HTTP) - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - TTCN-3 Change Requests
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007981TTCN-3 Change RequestsNew Featurepublic09-09-2020 14:3508-11-2023 13:48
ReporterMartti Käärik 
Assigned ToJens Grabowski 
PriorityhighSeveritymajorReproducibilityhave not tried
StatusclosedResolutionwon't fix 
PlatformOSOS Version
Clause Reference(s)NA
For STF discussion
Source (company - Author)STF576
Summary0007981: Support for REST APIs (HTTP)
DescriptionETSI CTI and MTS have been jointly working on establishing unified methodology for specification and testing of REST APIs. The activities have been carried out by STF576 (https://portal.etsi.org/STF/STFs/STF-HomePages/STF576 [^]) and resulted in an initial version of a guide document: EG 203 647 (https://portal.etsi.org/webapp/WorkProgram/Report_WorkItem.asp?WKI_ID=56708 [^]).
+
+STF576 has integrated several existing methodologies and languages developed within MTS in the guide, to the extent that those are suitable for REST APIs. This includes TTCN-3. However, to support standardized specification and testing process, TTCN-3 should provide means for describing REST API interface specific artifacts in test cases in tool agnostic manner.
+
+Although there are several protocols that may be used for implementing REST APIs, the initial effort has implicitly focused on HTTP.
Steps To Reproduce
Additional InformationSTF576 has no intention to dictate the design of the new feature. However, example test suite is provided with this request to better explain the requirements for the feature.
+
+To avoid confusion, please note that the example follows ES 203 119-6 (The Test Description Language (TDL); Part 6: Mapping to TTCN-3) with regard to implementation of test behavior.
+
+The examples re available at https://forge.etsi.org/rep/mts/eg-203647-restful-api-guide/tree/master/TC/Manual [^]
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
09-09-2020 14:35Martti KäärikNew Issue
05-10-2020 08:18Jens GrabowskiAssigned To => Kristóf Szabados
05-10-2020 08:18Jens GrabowskiStatusnew => assigned
07-10-2020 12:11Kristóf SzabadosNote Added: 0015773
08-10-2020 12:40Kristóf SzabadosNote Added: 0015779
11-12-2020 11:07Jens GrabowskiAssigned ToKristóf Szabados => Jens Grabowski
07-12-2022 08:46Jens GrabowskiNote Added: 0016365
08-11-2023 13:47Jens GrabowskiNote Added: 0016554
08-11-2023 13:48Jens GrabowskiNote Added: 0016555
08-11-2023 13:48Jens GrabowskiStatusassigned => closed
08-11-2023 13:48Jens GrabowskiResolutionopen => won't fix
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015773) +
+ Kristóf Szabados    +
+ 07-10-2020 12:11    +
+ 		+ + + + +
+ I will try to contact Martti Käärik to better understand the request.
+At thid point it is not clear if we should provide a extension descriping how to work with HTTP (similar to the XML, JSON extensions), or we should provide some generic types and templates, or something else.
+
+
+
+ + + + + + + + + + +
+ (0015779) +
+ Kristóf Szabados    +
+ 08-10-2020 12:40    +
+ 		+ + + + +
+ Answer from Martti:
+"
+Yes, we are basically talking about a standardized mapping from TTCN-3 types/templates to HTTP requests/responses (as you describe). Including a way to specify message bodies with some other (standardized) encoding (such as JSON).
+
+With HTTP (and JSON) mapping, pretty much all of the OpenAPI specification would be supported and no additional work would be required, in my opinion.
+"
+
+So the task at hand is to create a new extension to the core language, similar to ES 201 873-11 (Using JSON with TTCN-3) and ES 201 873-9 (Using XML schema with TTCN-3) for HTTP requests and responses.
+
+
+
+ + + + + + + + + + +
+ (0016365) +
+ Jens Grabowski    +
+ 07-12-2022 08:46    +
+ 		+ + + + +
+ TTF dicussion: Input from Nokia is possible. Without further input, the CR should be closed next year.
+
+
+
+ + + + + + + + + + +
+ (0016554) +
+ Jens Grabowski    +
+ 08-11-2023 13:47    +
+ 		+ + + + +
+ TTF discussion: No further input received. CR will be closed.
+
+
+
+ + + + + + + + + + +
+ (0016555) +
+ Jens Grabowski    +
+ 08-11-2023 13:48    +
+ 		+ + + + +
+ TTF discussion: No further input received. CR will be closed.
+
+ + diff --git a/docs/mantis/CR7982.md b/docs/mantis/CR7982.md new file mode 100644 index 0000000000000000000000000000000000000000..f573ef5707827d00924e75c33aecec71fe3e2d9b --- /dev/null +++ b/docs/mantis/CR7982.md @@ -0,0 +1,329 @@ + + + + + + + + + + + + + 0007982: Ambiguous decoding of xml - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007982Part 09: Using XML with TTCN-3Technicalpublic18-09-2020 10:5917-12-2020 12:00
ReporterWolfgang Seka 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version4.11.1 (published 2020-05) 
Target Version4.12.1 (ongoing)Fixed in Version4.12.1 (ongoing) 
Clause Reference(s)Part 9
For STF discussion
Source (company - Author)MCC160 - Wolfgang
Summary0007982: Ambiguous decoding of xml
DescriptionThere are XSD definitions which may cause ambiguities at decoding:
+E.g. RFC4745 defines
+
+   <xs:complexType name="manyType">
+        <xs:complexContent>
+            <xs:restriction base="xs:anyType">
+                <xs:choice minOccurs="0" maxOccurs="unbounded">
+                    <xs:element name="except" type="cp:exceptType"/>
+                    <xs:any namespace="##other"
+                        minOccurs="0" processContents="lax"/>
+                </xs:choice>
+                <xs:attribute name="domain"
+                use="optional" type="xs:string"/>
+            </xs:restriction>
+        </xs:complexContent>
+    </xs:complexType>
+    <xs:complexType name="exceptType">
+        <xs:attribute name="domain" type="xs:string" use="optional"/>
+        <xs:attribute name="id" type="xs:anyURI" use="optional"/>
+    </xs:complexType>
+
+The corresponding TTCN-3 definition are
+
+        type record ExceptType {
+              XSD.String domain optional,
+              XSD.AnyURI id optional
+        }
+        type record ManyType
+        {
+            XSD.String domain optional,
+            record of union {
+                ExceptType except_,
+                record length(0 .. 1) of XSD.String elem_list
+            } choice_list
+        };
+       
+This results in ambiguities as e.g.
+        { domain:="...",
+           choice_list:={elem_list:={} }
+        }
+        and
+        { domain:="...",
+           choice_list:={}
+        }
+result in the same xml-value, but in TTCN-3 these are distinct values.
+
+=> Clarification is needed to ensure tool compatibility.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7982.docx (51,519) 08-12-2020 14:22
http://oldforge.etsi.org/mantis/file_download.php?file_id=3975&type=bug
Issue History
Date ModifiedUsernameFieldChange
18-09-2020 10:59Wolfgang SekaNew Issue
21-09-2020 15:51Jacob Wieland - SpirentNote Added: 0015755
05-10-2020 08:19Jens GrabowskiAssigned To => Tomas Urban
05-10-2020 08:19Jens GrabowskiStatusnew => assigned
05-10-2020 08:20Jens GrabowskiProjectTTCN-3 Change Requests => Part 09: Using XML with TTCN-3
07-10-2020 08:52Tomas UrbanNote Added: 0015763
08-10-2020 12:00Wolfgang SekaNote Added: 0015778
09-10-2020 10:25Jens GrabowskiNote Added: 0015789
09-10-2020 10:25Jens GrabowskiAssigned ToTomas Urban => Jens Grabowski
08-12-2020 14:22Jens GrabowskiFile Added: CR7982.docx
08-12-2020 14:24Jens GrabowskiNote Added: 0015814
08-12-2020 14:24Jens GrabowskiAssigned ToJens Grabowski => Tomas Urban
08-12-2020 14:25Jens GrabowskiStatusassigned => confirmed
09-12-2020 07:40Tomas UrbanNote Added: 0015818
09-12-2020 07:40Tomas UrbanStatusconfirmed => resolved
09-12-2020 07:40Tomas UrbanResolutionopen => fixed
09-12-2020 07:40Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
17-12-2020 12:00Gyorgy RethyNote Added: 0015879
17-12-2020 12:00Gyorgy RethyStatusresolved => closed
17-12-2020 12:00Gyorgy RethyProduct Version => 4.11.1 (published 2020-05)
17-12-2020 12:00Gyorgy RethyFixed in Version => 4.12.1 (ongoing)
17-12-2020 12:00Gyorgy RethyTarget Version => 4.12.1 (ongoing)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015755) +
+ Jacob Wieland - Spirent    +
+ 21-09-2020 15:51    +
+ 		+ + + + +
+ the ambiguity exists already on the XSD level, as it is not clear if the empty content is the empty list of outer-choice or an arbitary amount of outer-choice instances that always contain an empty inner choice.
+
+As all are valid interpretations of the empty content, it is unclear why the decoder should prefer one over the others.
+
+Thus, all correct interpretations that the codec can give back should be acceptable.
+
+A template matching all the empty-values could be defined using the AdvancedMatching @dynamic template matching mechanism.
+
+Making the XSD unambiguous by declaring the inner choice with minOccurs="1" would also be a simple solution, if available.
+
+
+
+ + + + + + + + + + +
+ (0015763) +
+ Tomas Urban    +
+ 07-10-2020 08:52    +
+ 		+ + + + +
+ I think that one solution to the problem is that we could introduce a canonical form of decoding. In this form, the decoded value would have the smallest possible amount of elements that still properly represent the encoded value. The canonical decoding form would be activated in a similar fashion as substitution (i.e. on the tool level).
+
+We would have to think carefully how to specify the rules. Some examples:
+Places that can be simplified:
+- optional fields of records (empty valus are transformed to omitted ones)
+- elements of record of (empty values are removed from the record of)
+Values that could be considered empty:
+- Empty "record of" value
+- Union value if the selected option is an empty value
+
+
+
+ + + + + + + + + + +
+ (0015778) +
+ Wolfgang Seka    +
+ 08-10-2020 12:00    +
+ 		+ + + + +
+ Tomas' approach sounds reasonable even though I don't know the technical impact for tool development.
+
+
+
+ + + + + + + + + + +
+ (0015789) +
+ Jens Grabowski    +
+ 09-10-2020 10:25    +
+ 		+ + + + +
+ STF decision: For the moment a note should be added that ambiguities in the XSD source are not resolved on TTCN-3 level.
+
+
+
+ + + + + + + + + + +
+ (0015814) +
+ Jens Grabowski    +
+ 08-12-2020 14:24    +
+ 		+ + + + +
+ Tomas, I'm not sure I put the note in the appropriate section. Check and move if necessary.
+
+
+
+ + + + + + + + + + +
+ (0015818) +
+ Tomas Urban    +
+ 09-12-2020 07:40    +
+ 		+ + + + +
+ The note seems to be in the correct location. The proposal is therefore ready to be included in the next version of the standard.
+
+
+
+ + + + + + + + + + +
+ (0015879) +
+ Gyorgy Rethy    +
+ 17-12-2020 12:00    +
+ 		+ + + + +
+ Implemented in draft 4.11.2
+
+ + diff --git a/docs/mantis/CR7983.md b/docs/mantis/CR7983.md new file mode 100644 index 0000000000000000000000000000000000000000..436343a35e4095d49c5c7017eca6612074df6fc3 --- /dev/null +++ b/docs/mantis/CR7983.md @@ -0,0 +1,103 @@ + + + + + + + + + + + + + 0007983: tliObj*Enter/Leave events should also get the class scope name - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Object-oriented features (ES 203 790)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007983Ext Pack: Object-oriented features (ES 203 790)[All Projects] Generalpublic23-09-2020 16:4828-12-2020 11:49
ReporterJacob Wieland - Spirent 
Assigned ToJens Grabowski 
PrioritynormalSeveritymajorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product VersionV1.2.1 (published 2020-05) 
Target VersionV1.3.1 (ongoing)Fixed in Version 
Summary0007983: tliObj*Enter/Leave events should also get the class scope name
DescriptionSo far, the tli events tliObjCreateEnter, tliObjCreateLeave, tliObjFinallyEnter, tliObjFinallyLeave, tliObjMethodEnter, tliObjMethodLeave only get the obj instance and the parameter lists/result values.
+
+However, when a constructor, finalizer or method is called, this can be any one in the class hierarchy of the object, resulting in nested calls that so far can only be distinguished by their location information.
+
+However, it would be interesting to find out what actual constructor/finalizer/method implementation is entered/left without consulting the source code.
+
+Therefore, an additional class identifier should be added to these events, referencing the full type class name of the class that contains the entered/left method/constructor/finalizer.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7983.docx (293,127) 07-10-2020 15:47
http://oldforge.etsi.org/mantis/file_download.php?file_id=3958&type=bug
Issue History
Date ModifiedUsernameFieldChange
23-09-2020 16:48Jacob Wieland - SpirentNew Issue
06-10-2020 13:26Jens GrabowskiAssigned To => Jacob Wieland - Spirent
06-10-2020 13:26Jens GrabowskiStatusnew => assigned
07-10-2020 15:47Jacob Wieland - SpirentFile Added: CR7983.docx
07-10-2020 15:47Jacob Wieland - SpirentNote Added: 0015775
07-10-2020 15:47Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Tomas Urban
07-10-2020 15:47Jacob Wieland - SpirentStatusassigned => confirmed
08-10-2020 09:01Tomas UrbanNote Added: 0015777
08-10-2020 09:01Tomas UrbanStatusconfirmed => resolved
08-10-2020 09:01Tomas UrbanResolutionopen => fixed
08-10-2020 09:01Tomas UrbanAssigned ToTomas Urban => Jens Grabowski
17-12-2020 16:19Gyorgy RethyProduct Version => V1.2.1 (published 2020-05)
17-12-2020 16:19Gyorgy RethyTarget Version => V1.3.1 (ongoing)
28-12-2020 11:49Jens GrabowskiStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015775) +
+ Jacob Wieland - Spirent    +
+ 07-10-2020 15:47    +
+ 		+ + + + +
+ please review
+
+
+
+ + + + + + + + + + +
+ (0015777) +
+ Tomas Urban    +
+ 08-10-2020 09:01    +
+ 		+ + + + +
+ The proposal resolves the CR and can be added to the next version of the specification.
+
+ + diff --git a/docs/mantis/CR7984.md b/docs/mantis/CR7984.md new file mode 100644 index 0000000000000000000000000000000000000000..2db3e52a0b9b745a1f91913500f63d9b98e5ffc7 --- /dev/null +++ b/docs/mantis/CR7984.md @@ -0,0 +1,167 @@ + + + + + + + + + + + + + 0007984: sequence of RunsOnSpec, MtcSpec, SystemSpec in BehaviourType definitions - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Behaviour Types (ES 202 785)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007984Ext Pack: Behaviour Types (ES 202 785)Clarificationpublic01-10-2020 06:5618-12-2020 15:17
ReporterMartin Hauch 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv1.7.1 (published 2020-05) 
Target Versionv1.8.1 (ongoing)Fixed in Versionv1.8.1 (ongoing) 
Clause Reference(s)5.2
Source (company - Author)Devoteam - Martin Hauch
Summary0007984: sequence of RunsOnSpec, MtcSpec, SystemSpec in BehaviourType definitions
DescriptionIn "Part 1: TTCN-3 Core Language" the following rules are defined for functions and altsteps:
+A.1.6.1.4 Function definitions
+160.FunctionDef ::= FunctionKeyword [ DeterministicModifier | ControlModifier ]
+                     IdentifierOrControl
+                     "(" [FunctionFormalParList] ")" [RunsOnSpec] [MtcSpec]
+                     [SystemSpec] [ReturnType] StatementBlock
+
+A.1.6.1.7 Altstep definitions
+194.AltstepDef ::= AltstepKeyword [ ControlModifier ] [ InterleavedKeyword ] Identifier
+                  "(" [FunctionFormalParList]
+                    ")" [RunsOnSpec] [MtcSpec] [SystemSpec]
+                  "{" AltstepLocalDefList
+                    AltGuardList "}"
+
+
+In Document of Change-Request 7812 (CR7812-3.docx) the following definition is defined:
+
+TTCN-3 Language Extensions: Behaviour Types
+type function BehaviourTypeIdentifier
+[ "<" { FormalTypePar [","] } ">" ] NOTE1
+"(" [ { ( FormalValuePar | FormalTimerPar | FormalTemplatePar | FormalPortPar ) [","] } ] ")"
+[ runs on ( ComponentType | self ] NOTE2
+[ system ComponentType ]
+[ mtc ComponentType ]
+[ return [ template ] Type ]
+
+type altstep BehaviourTypeIdentifier
+[ "<" { FormalTypePar [","] } ">" ] NOTE1
+"(" [ { ( FormalValuePar | FormalTimerPar | FormalTemplatePar | FormalPortPar ) [","] } ] ")"
+[ runs on ( ComponentType | self ] NOTE2
+[ system ComponentType ]
+[ mtc ComponentType ]
+
+Why is the sequence of 'RunsOnSpec, MtcSpec, SystemSpec' in core language
+changed to 'RunsOnSpec,SystemSpec,MtcSpec' for BehaviourTypes?
+
+Perhaps this sequence should be adapted for behaviour types to definition in TTCN-3 core language!
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7984.docx (137,341) 05-10-2020 09:36
http://oldforge.etsi.org/mantis/file_download.php?file_id=3954&type=bug
Issue History
Date ModifiedUsernameFieldChange
01-10-2020 06:56Martin HauchNew Issue
05-10-2020 08:21Jens GrabowskiAssigned To => Jacob Wieland - Spirent
05-10-2020 08:21Jens GrabowskiStatusnew => assigned
05-10-2020 09:36Jacob Wieland - SpirentFile Added: CR7984.docx
05-10-2020 09:36Jacob Wieland - SpirentNote Added: 0015756
05-10-2020 09:36Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Tomas Urban
05-10-2020 09:36Jacob Wieland - SpirentStatusassigned => confirmed
06-10-2020 13:33Tomas UrbanNote Added: 0015760
06-10-2020 13:33Tomas UrbanStatusconfirmed => resolved
06-10-2020 13:33Tomas UrbanResolutionopen => fixed
06-10-2020 13:33Tomas UrbanAssigned ToTomas Urban => Jens Grabowski
17-12-2020 16:13Gyorgy RethyAssigned ToJens Grabowski => Gyorgy Rethy
18-12-2020 15:17Gyorgy RethyNote Added: 0015893
18-12-2020 15:17Gyorgy RethyStatusresolved => closed
18-12-2020 15:17Gyorgy RethyProduct Versionv1.6.1 (published 2018-05) => v1.7.1 (published 2020-05)
18-12-2020 15:17Gyorgy RethyFixed in Version => v1.8.1 (ongoing)
18-12-2020 15:17Gyorgy RethyTarget Version => v1.8.1 (ongoing)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015756) +
+ Jacob Wieland - Spirent    +
+ 05-10-2020 09:36    +
+ 		+ + + + +
+ added proposal, please review
+
+
+
+ + + + + + + + + + +
+ (0015760) +
+ Tomas Urban    +
+ 06-10-2020 13:33    +
+ 		+ + + + +
+ The order of clauses has been corrected and the proposed resolution can be added to the specification.
+
+
+
+ + + + + + + + + + +
+ (0015893) +
+ Gyorgy Rethy    +
+ 18-12-2020 15:17    +
+ 		+ + + + +
+ Implemented in draft 1.7.2
+
+ + diff --git a/docs/mantis/CR7985.md b/docs/mantis/CR7985.md new file mode 100644 index 0000000000000000000000000000000000000000..c0e87a83ee25b761a5083255f9609f140de3eecf --- /dev/null +++ b/docs/mantis/CR7985.md @@ -0,0 +1,214 @@ + + + + + + + + + + + + + 0007985: allow objects inside record of/array - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Object-oriented features (ES 203 790)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007985Ext Pack: Object-oriented features (ES 203 790)[All Projects] Generalpublic05-10-2020 06:3628-12-2020 10:58
ReporterKristóf Szabados 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product VersionV1.2.1 (published 2020-05) 
Target VersionV1.3.1 (ongoing)Fixed in Version 
Summary0007985: allow objects inside record of/array
DescriptionCurrently Object in TTCN-3 are not allowed as elements of Record of structures.
+This creates a limitation in how usable they are.
+
+For example: while it is possible to implement linkedlist like datastructures, it is not possible to implement arraylists, vectors, or open address hashing.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR_7985.docx (135,403) 08-10-2020 08:21
http://oldforge.etsi.org/mantis/file_download.php?file_id=3959&type=bug
docx CR_7985_v2.docx (135,738) 08-10-2020 20:52
http://oldforge.etsi.org/mantis/file_download.php?file_id=3962&type=bug
docx CR_7985_v3.docx (135,772) 09-10-2020 15:10
http://oldforge.etsi.org/mantis/file_download.php?file_id=3963&type=bug
Issue History
Date ModifiedUsernameFieldChange
05-10-2020 06:36Kristóf SzabadosNew Issue
05-10-2020 08:27Jens GrabowskiAssigned To => Kristóf Szabados
05-10-2020 08:27Jens GrabowskiStatusnew => assigned
08-10-2020 08:21Kristóf SzabadosFile Added: CR_7985.docx
08-10-2020 08:21Kristóf SzabadosNote Added: 0015776
08-10-2020 08:22Kristóf SzabadosAssigned ToKristóf Szabados => Jacob Wieland - Spirent
08-10-2020 09:39Jens GrabowskiStatusassigned => confirmed
08-10-2020 16:07Jacob Wieland - SpirentNote Added: 0015786
08-10-2020 16:08Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Kristóf Szabados
08-10-2020 16:08Jacob Wieland - SpirentStatusconfirmed => assigned
08-10-2020 16:09Jacob Wieland - SpirentNote Edited: 0015786bug_revision_view_page.php?bugnote_id=15786#r530
08-10-2020 20:52Kristóf SzabadosFile Added: CR_7985_v2.docx
08-10-2020 20:53Kristóf SzabadosNote Added: 0015787
08-10-2020 20:53Kristóf SzabadosAssigned ToKristóf Szabados => Jacob Wieland - Spirent
08-10-2020 20:53Kristóf SzabadosStatusassigned => confirmed
09-10-2020 15:10Jacob Wieland - SpirentFile Added: CR_7985_v3.docx
09-10-2020 15:12Jacob Wieland - SpirentNote Added: 0015790
09-10-2020 15:12Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Kristóf Szabados
09-10-2020 15:12Jacob Wieland - SpirentStatusconfirmed => assigned
09-10-2020 15:12Jacob Wieland - SpirentStatusassigned => confirmed
16-10-2020 13:04Kristóf SzabadosNote Added: 0015792
16-10-2020 13:04Kristóf SzabadosStatusconfirmed => resolved
16-10-2020 13:04Kristóf SzabadosResolutionopen => fixed
16-10-2020 13:04Kristóf SzabadosAssigned ToKristóf Szabados => Gyorgy Rethy
17-12-2020 16:13Gyorgy RethyAssigned ToGyorgy Rethy => Jens Grabowski
17-12-2020 16:16Gyorgy RethyProduct Version => V1.2.1 (published 2020-05)
17-12-2020 16:16Gyorgy RethyTarget Version => V1.3.1 (ongoing)
28-12-2020 10:58Jens GrabowskiStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015776) +
+ Kristóf Szabados    +
+ 08-10-2020 08:21    +
+ 		+ + + + +
+ uploaded first proposal, please check.
+
+
+
+ + + + + + + + + + +
+ (0015786) +
+ Jacob Wieland - Spirent    +
+ 08-10-2020 16:07    +
(edited on: 08-10-2020 16:09)
+ 		+ + + + +
+ What is the purpose of this sentence:
+If a structured type contains a field of a class type, this type is not seen as a data type and its values cannot be used for sending and receiving or as an argument to any expression other than the equality/inequality operator.
+
+of course the type can be used for lots of other things. Parameter passing, assignment, field selection, pretty much anything except encoding and passing to another component.
+
+So, I would reformulate it to:
+If a structured type contains a field of a class type, this type is not seen as a data type and its values cannot be used for encoding or decoding, sending or receiving and neither used as an actual parameter (or part therof) to a function started on another component.
+
+Maybe this should be formulated as (different) restrictions in a restrictios section.
+
+
+
+
+
+ + + + + + + + + + +
+ (0015787) +
+ Kristóf Szabados    +
+ 08-10-2020 20:53    +
+ 		+ + + + +
+ I aggree. Please review.
+
+
+
+ + + + + + + + + + +
+ (0015790) +
+ Jacob Wieland - Spirent    +
+ 09-10-2020 15:12    +
+ 		+ + + + +
+ I have deleted the additional restriction on subtyping structured types that have class type eleements/fields because that is not necessary, as they do not introduce a subtype for the field, just for the container.
+
+Please confirm, and, if ok, please resolve.
+
+
+
+ + + + + + + + + + +
+ (0015792) +
+ Kristóf Szabados    +
+ 16-10-2020 13:04    +
+ 		+ + + + +
+ can be part of the next version of th extension.
+
+ + diff --git a/docs/mantis/CR7986.md b/docs/mantis/CR7986.md new file mode 100644 index 0000000000000000000000000000000000000000..e1affb42c4bc6599957bd0528ad02331a2ea7ed2 --- /dev/null +++ b/docs/mantis/CR7986.md @@ -0,0 +1,147 @@ + + + + + + + + + + + + + 0007986: usage of the "data type" term is a bit confusing - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007986Part 01: TTCN-3 Core LanguageClarificationpublic07-10-2020 12:4117-12-2020 10:41
ReporterKristóf Szabados 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version4.12.1 (published 2020-05) 
Target Version4.13.1 (ongoing)Fixed in Version4.13.1 (ongoing) 
Clause Reference(s)3.1, 5.0, 6.2.
Source (company - Author)L.M. Ericsson
Summary0007986: usage of the "data type" term is a bit confusing
DescriptionSection 3.1 defines the term "data type" as such
+"
+data types: all types whose values or sub-elements cannot contain object references.
+NOTE: Data types include simple basic types, basic string types, and the special data type anytype. Data types also include all structured types where all their sub-elements are of a data type. All user defined types based on a data type are data types as well. See more details in table 3 of the present document.
+"
+
+Later section 5.0 states:
+"A module consists of a set of definitions that define test components, communication ports, data types, constants, test data templates, functions including the module control function, signatures for procedure calls at ports, test cases, etc. "
+This might indicate that is a module can not have a type definition whose sub element can contain an object reference.
+
+And
+"TTCN-3 has a number of predefined basic data types as well as structured types such as records, sets, unions, enumerated types and arrays."
+But structured types are also data types, or are they explicitly mentioned here to indicate structured types containing object references?
+
+section 6.2.6 states:
+"the anytype shall comprise all the known data types but not the port, component, default and timer types"
+But types like timers are not data types, so the exclusion makes no difference here.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7986.docx (1,416,591) 09-12-2020 16:43
http://oldforge.etsi.org/mantis/file_download.php?file_id=3982&type=bug
Issue History
Date ModifiedUsernameFieldChange
07-10-2020 12:41Kristóf SzabadosNew Issue
08-10-2020 09:37Jens GrabowskiAssigned To => Jens Grabowski
08-10-2020 09:37Jens GrabowskiStatusnew => assigned
07-12-2020 12:09Jens GrabowskiProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
09-12-2020 16:43Jens GrabowskiFile Added: CR7986.docx
09-12-2020 16:47Jens GrabowskiNote Added: 0015827
09-12-2020 16:47Jens GrabowskiAssigned ToJens Grabowski => Tomas Urban
10-12-2020 07:48Tomas UrbanNote Added: 0015833
10-12-2020 07:48Tomas UrbanStatusassigned => resolved
10-12-2020 07:48Tomas UrbanResolutionopen => fixed
10-12-2020 07:48Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
17-12-2020 10:41Gyorgy RethyNote Added: 0015876
17-12-2020 10:41Gyorgy RethyStatusresolved => closed
17-12-2020 10:41Gyorgy RethyProduct Version => 4.12.1 (published 2020-05)
17-12-2020 10:41Gyorgy RethyFixed in Version => 4.13.1 (ongoing)
17-12-2020 10:41Gyorgy RethyTarget Version => 4.13.1 (ongoing)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015827) +
+ Jens Grabowski    +
+ 09-12-2020 16:47    +
+ 		+ + + + +
+ Tomas, please check. I looked through the cases specified above, changed "address data type" to "address type" and checked all other occurrences of data type.
+
+
+
+ + + + + + + + + + +
+ (0015833) +
+ Tomas Urban    +
+ 10-12-2020 07:48    +
+ 		+ + + + +
+ Looks fine to me. I think it can be added to the next verions of the core language specification.
+
+
+
+ + + + + + + + + + +
+ (0015876) +
+ Gyorgy Rethy    +
+ 17-12-2020 10:41    +
+ 		+ + + + +
+ Implemented in draft 4.12.2
+
+ + diff --git a/docs/mantis/CR7988.md b/docs/mantis/CR7988.md new file mode 100644 index 0000000000000000000000000000000000000000..aba87ba94c0ea170686b6121a49218f1fd23a64d --- /dev/null +++ b/docs/mantis/CR7988.md @@ -0,0 +1,178 @@ + + + + + + + + + + + + + 0007988: Clarification of a restriction on map types - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007988Part 01: TTCN-3 Core LanguageClarificationpublic27-10-2020 10:1116-12-2020 16:58
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version4.12.1 (published 2020-05) 
Target Version4.13.1 (ongoing)Fixed in Version4.13.1 (ongoing) 
Clause Reference(s)6.2.15.1
Source (company - Author)TTF T003
Summary0007988: Clarification of a restriction on map types
DescriptionThe restriction 6.2.15.1 states that: "... expressions of type map or any structured type containing a field or element of type map directly or indirectly are not allowed."
+
+What exactly does it mean? An expression is usually of a certain type if its result is of this type. However, there are no operands that could produce a result of a map type.
+
+The other possibility is that the restriction is related to operands of expressions. That would make more sense as map values could occur e.g. in comparison expressions and there's no explicit guidance on how to compare two map values in the standand.
+
+If the latter is true, I would prefer the restriction to be split into two:
+a) Templates of a map type or any structured type containing a field or element of a map type on any level of nesting are not allowed.
+b) Operands of expressions shall not be of a map type or any structured type containing a field or element of a map type on any level of nesting.
+
+Eventually we could add an explicit rule on comparison of two maps:
+Two map values are equal if they are mutually compatible with the type of the other operand (see clause 6.3.8), both values contain the same amount of key value pairs and each value associated with a key in one value is a equal to a value associated with an equal key in the other value.
+
+If the intention of the existing restriction is indeed to forbid comparison of maps then there's a problem with the anytype. The anytype automatically contains all map types declared in the module and therefore it is not possible to use it in comparison operations, because it is a constucted type containing an element of a map type.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7988-1.docx (181,289) 07-12-2020 13:31
http://oldforge.etsi.org/mantis/file_download.php?file_id=3967&type=bug
Issue History
Date ModifiedUsernameFieldChange
27-10-2020 10:11Tomas UrbanNew Issue
07-12-2020 11:58Jens GrabowskiAssigned To => Tomas Urban
07-12-2020 11:58Jens GrabowskiStatusnew => assigned
07-12-2020 13:31Tomas UrbanFile Added: CR7988-1.docx
07-12-2020 13:32Tomas UrbanNote Added: 0015798
07-12-2020 13:32Tomas UrbanAssigned ToTomas Urban => Kristóf Szabados
07-12-2020 13:32Tomas UrbanStatusassigned => confirmed
07-12-2020 17:08Kristóf SzabadosNote Added: 0015804
07-12-2020 17:09Kristóf SzabadosNote Added: 0015805
07-12-2020 17:09Kristóf SzabadosStatusconfirmed => resolved
07-12-2020 17:09Kristóf SzabadosResolutionopen => fixed
07-12-2020 17:09Kristóf SzabadosAssigned ToKristóf Szabados => Gyorgy Rethy
16-12-2020 16:58Gyorgy RethyNote Added: 0015871
16-12-2020 16:58Gyorgy RethyStatusresolved => closed
16-12-2020 16:58Gyorgy RethyProduct Version => 4.12.1 (published 2020-05)
16-12-2020 16:58Gyorgy RethyFixed in Version => 4.13.1 (ongoing)
16-12-2020 16:58Gyorgy RethyTarget Version => 4.13.1 (ongoing)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015798) +
+ Tomas Urban    +
+ 07-12-2020 13:32    +
+ 		+ + + + +
+ Resolution uploaded. Please check.
+
+
+
+ + + + + + + + + + +
+ (0015804) +
+ Kristóf Szabados    +
+ 07-12-2020 17:08    +
+ 		+ + + + +
+ Looks fine to me.
+
+
+
+ + + + + + + + + + +
+ (0015805) +
+ Kristóf Szabados    +
+ 07-12-2020 17:09    +
+ 		+ + + + +
+ Can be included in the next version of the standard.
+
+
+
+ + + + + + + + + + +
+ (0015871) +
+ Gyorgy Rethy    +
+ 16-12-2020 16:58    +
+ 		+ + + + +
+ Implemented in draft 4.12.2
+
+ + diff --git a/docs/mantis/CR7989.md b/docs/mantis/CR7989.md new file mode 100644 index 0000000000000000000000000000000000000000..d4c637c1ce5364bb63122b6aade9df10fe933fb7 --- /dev/null +++ b/docs/mantis/CR7989.md @@ -0,0 +1,98 @@ + + + + + + + + + + + + + 0007989: Incorrect references to compatibility rules - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007989Part 01: TTCN-3 Core LanguageEditorialpublic27-10-2020 10:2716-12-2020 17:15
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version4.12.1 (published 2020-05) 
Target Version4.13.1 (ongoing)Fixed in Version4.13.1 (ongoing) 
Clause Reference(s)7.1.3
Source (company - Author)TTF T003
Summary0007989: Incorrect references to compatibility rules
DescriptionThe section 7.1.3 (Relational operators) contains two incorrect references to the section 6.2.15 which describes a map type. Both references shall be replaced with 6.3.2.2 (compatibility of records) and 6.3.2.3 (compatibility of sets).
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7989.docx (82,862) 08-12-2020 12:41
http://oldforge.etsi.org/mantis/file_download.php?file_id=3972&type=bug
Issue History
Date ModifiedUsernameFieldChange
27-10-2020 10:27Tomas UrbanNew Issue
07-12-2020 11:59Jens GrabowskiAssigned To => Jens Grabowski
07-12-2020 11:59Jens GrabowskiStatusnew => assigned
08-12-2020 12:41Jens GrabowskiFile Added: CR7989.docx
08-12-2020 12:42Jens GrabowskiAssigned ToJens Grabowski => Gyorgy Rethy
08-12-2020 12:42Jens GrabowskiNote Added: 0015811
08-12-2020 12:42Jens GrabowskiStatusassigned => resolved
08-12-2020 12:42Jens GrabowskiResolutionopen => fixed
16-12-2020 17:15Gyorgy RethyNote Added: 0015873
16-12-2020 17:15Gyorgy RethyStatusresolved => closed
16-12-2020 17:15Gyorgy RethyProduct Version => 4.12.1 (published 2020-05)
16-12-2020 17:15Gyorgy RethyFixed in Version => 4.13.1 (ongoing)
16-12-2020 17:15Gyorgy RethyTarget Version => 4.13.1 (ongoing)
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015811) +
+ Jens Grabowski    +
+ 08-12-2020 12:42    +
+ 		+ + + + +
+ Resolved as proposed by reporter.
+
+
+
+ + + + + + + + + + +
+ (0015873) +
+ Gyorgy Rethy    +
+ 16-12-2020 17:15    +
+ 		+ + + + +
+ Implemented in draft 4.12.2
+
+ + diff --git a/docs/mantis/CR7990.md b/docs/mantis/CR7990.md new file mode 100644 index 0000000000000000000000000000000000000000..3e62dd103cf7dc3d6c376ebe138e8bfa266a2d6e --- /dev/null +++ b/docs/mantis/CR7990.md @@ -0,0 +1,139 @@ + + + + + + + + + + + + + 0007990: lengthof for maps - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007990Part 01: TTCN-3 Core LanguageNew Featurepublic29-10-2020 07:3017-12-2020 10:24
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeveritytrivialReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version4.12.1 (published 2020-05) 
Target Version4.13.1 (ongoing)Fixed in Version4.13.1 (ongoing) 
Clause Reference(s)C.2.1
Source (company - Author)TTF T003
Summary0007990: lengthof for maps
DescriptionThe predefined function lengthof should accept parameters of map types and return the number of key/value pairs in the map.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
parent of 0007998closed Jens Grabowski lengthof for maps 
Attached Filesdocx CR7990-1.docx (186,079) 07-12-2020 13:41
http://oldforge.etsi.org/mantis/file_download.php?file_id=3968&type=bug
Issue History
Date ModifiedUsernameFieldChange
29-10-2020 07:30Tomas UrbanNew Issue
07-12-2020 12:02Jens GrabowskiAssigned To => Tomas Urban
07-12-2020 12:02Jens GrabowskiStatusnew => assigned
07-12-2020 13:41Tomas UrbanFile Added: CR7990-1.docx
07-12-2020 13:42Tomas UrbanNote Added: 0015799
07-12-2020 13:42Tomas UrbanAssigned ToTomas Urban => Kristóf Szabados
07-12-2020 13:42Tomas UrbanStatusassigned => confirmed
07-12-2020 17:04Kristóf SzabadosNote Added: 0015803
09-12-2020 09:23Jens GrabowskiAssigned ToKristóf Szabados => Tomas Urban
09-12-2020 09:23Jens GrabowskiStatusconfirmed => assigned
09-12-2020 09:30Jens GrabowskiAssigned ToTomas Urban => Gyorgy Rethy
09-12-2020 09:30Jens GrabowskiStatusassigned => resolved
09-12-2020 09:30Jens GrabowskiResolutionopen => fixed
17-12-2020 10:17Gyorgy RethyNote Added: 0015875
17-12-2020 10:17Gyorgy RethyStatusresolved => closed
17-12-2020 10:17Gyorgy RethyProduct Version => 4.12.1 (published 2020-05)
17-12-2020 10:17Gyorgy RethyFixed in Version => 4.13.1 (ongoing)
17-12-2020 10:17Gyorgy RethyTarget Version => 4.13.1 (ongoing)
17-12-2020 10:24Gyorgy RethyIssue cloned: 0007998
17-12-2020 10:24Gyorgy RethyRelationship addedparent of 0007998
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015799) +
+ Tomas Urban    +
+ 07-12-2020 13:42    +
+ 		+ + + + +
+ Resolution uploaded. Please check.
+
+
+
+ + + + + + + + + + +
+ (0015803) +
+ Kristóf Szabados    +
+ 07-12-2020 17:04    +
+ 		+ + + + +
+ In theory this looks fine for a general case.
+I just have noticed some interesting properties of the current map description, where it might not work:
+1)
+There is no rule saying that the keys or the values need to be unique.
+That is if the numerical value 1 is stored in 2 variables and both are used as keys ... this definition my return the value 2, but when asking for the keys of the map, as it returns a set of structure it might have only a single element.
+
+2)
+There is no example for what happens, when a key is mapped to the not used symbol.
+If this is to be handled as a special case, and could be assigned to 2 different keys ... than the above definition would not be usable with the to selector, that also returns a set of values.
+
+
+
+ + + + + + + + + + +
+ (0015875) +
+ Gyorgy Rethy    +
+ 17-12-2020 10:17    +
+ 		+ + + + +
+ Implemented in draft 4.12.2
+
+ + diff --git a/docs/mantis/CR7991.md b/docs/mantis/CR7991.md new file mode 100644 index 0000000000000000000000000000000000000000..596c0a9cbb7fe3b6552342f20e93f846d5650dec --- /dev/null +++ b/docs/mantis/CR7991.md @@ -0,0 +1,210 @@ + + + + + + + + + + + + + 0007991: @nodefault for interleave - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007991Part 01: TTCN-3 Core LanguageTechnicalpublic03-11-2020 08:3716-12-2020 17:27
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version4.12.1 (published 2020-05) 
Target Version4.13.1 (ongoing)Fixed in Version4.13.1 (ongoing) 
Clause Reference(s)20.4
Source (company - Author)Elvior OÜ
Summary0007991: @nodefault for interleave
DescriptionThe @nodefault modifier should be avaliable in the interleave statement as well.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR_7991.docx (302,815) 08-12-2020 20:44
http://oldforge.etsi.org/mantis/file_download.php?file_id=3976&type=bug
docx CR_7991_v2.docx (302,802) 09-12-2020 09:01
http://oldforge.etsi.org/mantis/file_download.php?file_id=3979&type=bug
Issue History
Date ModifiedUsernameFieldChange
03-11-2020 08:37Tomas UrbanNew Issue
07-12-2020 12:03Jens GrabowskiAssigned To => Kristóf Szabados
07-12-2020 12:03Jens GrabowskiStatusnew => assigned
08-12-2020 20:44Kristóf SzabadosFile Added: CR_7991.docx
08-12-2020 20:46Kristóf SzabadosNote Added: 0015815
08-12-2020 20:46Kristóf SzabadosAssigned ToKristóf Szabados => Tomas Urban
08-12-2020 20:46Kristóf SzabadosStatusassigned => confirmed
09-12-2020 07:38Tomas UrbanNote Added: 0015817
09-12-2020 07:38Tomas UrbanAssigned ToTomas Urban => Kristóf Szabados
09-12-2020 07:38Tomas UrbanStatusconfirmed => assigned
09-12-2020 09:01Kristóf SzabadosFile Added: CR_7991_v2.docx
09-12-2020 09:01Kristóf SzabadosNote Added: 0015821
09-12-2020 09:01Kristóf SzabadosAssigned ToKristóf Szabados => Tomas Urban
09-12-2020 09:01Kristóf SzabadosStatusassigned => confirmed
09-12-2020 09:05Tomas UrbanNote Added: 0015822
09-12-2020 09:05Tomas UrbanStatusconfirmed => resolved
09-12-2020 09:05Tomas UrbanResolutionopen => fixed
09-12-2020 09:05Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
16-12-2020 17:27Gyorgy RethyNote Added: 0015874
16-12-2020 17:27Gyorgy RethyStatusresolved => closed
16-12-2020 17:27Gyorgy RethyProduct Version => 4.12.1 (published 2020-05)
16-12-2020 17:27Gyorgy RethyFixed in Version => 4.13.1 (ongoing)
16-12-2020 17:27Gyorgy RethyTarget Version => 4.13.1 (ongoing)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015815) +
+ Kristóf Szabados    +
+ 08-12-2020 20:46    +
+ 		+ + + + +
+ I have added the first proposal, please check.
+
+Please note, that the BNF was not updated for the alt statement with the @nodefault modifier. I have updated it, but there might be other locations with such issues too.
+
+
+
+ + + + + + + + + + +
+ (0015817) +
+ Tomas Urban    +
+ 09-12-2020 07:38    +
+ 		+ + + + +
+ I am afraid that some contradiction in the proposal. The proposed rule says that "If the interleave statement contains the @nodefault modifier, all active default alternatives are ignored for the execution of this interleave statement." In my understanding it virtually switches off defaults inside the transformed alt block, thus behaves as if every nested alt statement had the @nodefault modifier.
+
+However, the note says that only the outermost alt is generated with the @nodefault modifier.
+
+In my opinion, the rule is correct and the note isn't, because as a user, I would expect that by switching off the default handling I make sure I get all the messages I included in the interleave without any single of them being replaced by a random default.
+
+We should also consider what happens when we combine present/missing @nodefault modifier on the interleave level with a present/missing @nodefault modifier of an alt statement (including implicit one such as a stanalone receive) inside it. For simplicity, I would prefer that all transformed alt statements would have the same modifier as the interleave statement.
+
+Thumbs up for detecting the issue with the alt statement BNF rule.
+
+
+
+ + + + + + + + + + +
+ (0015821) +
+ Kristóf Szabados    +
+ 09-12-2020 09:01    +
+ 		+ + + + +
+ Fixed the note.
+Please check it.
+
+
+
+ + + + + + + + + + +
+ (0015822) +
+ Tomas Urban    +
+ 09-12-2020 09:05    +
+ 		+ + + + +
+ The proposal can be added to the next version of the core language specification.
+
+
+
+ + + + + + + + + + +
+ (0015874) +
+ Gyorgy Rethy    +
+ 16-12-2020 17:27    +
+ 		+ + + + +
+ Implemented in draft 4.12.2
+
+ + diff --git a/docs/mantis/CR7992.md b/docs/mantis/CR7992.md new file mode 100644 index 0000000000000000000000000000000000000000..81f47a24277fcf0143ac71ab571dcb2bbb89a7ef --- /dev/null +++ b/docs/mantis/CR7992.md @@ -0,0 +1,137 @@ + + + + + + + + + + + + + 0007992: Only signature parameters are restricted to be data types, return types not - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007992Part 01: TTCN-3 Core LanguageEditorialpublic10-11-2020 16:3616-12-2020 17:01
ReporterKristóf Szabados 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version4.12.1 (published 2020-05) 
Target Version4.13.1 (ongoing)Fixed in Version4.13.1 (ongoing) 
Clause Reference(s)14
Source (company - Author)L.M. Ericsson
Summary0007992: Only signature parameters are restricted to be data types, return types not
DescriptionRestriction b of section 14 of the core standard:
+"Signature parameters shall be of a data type."
+
+Which is necessary so that the parameters could sent over the network when calling a procedure on a remote component.
+
+But the return type must also be restricted to be a data type, so that it could also be sent back.
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR_7992.docx (163,340) 07-12-2020 16:51
http://oldforge.etsi.org/mantis/file_download.php?file_id=3971&type=bug
Issue History
Date ModifiedUsernameFieldChange
10-11-2020 16:36Kristóf SzabadosNew Issue
07-12-2020 12:06Jens GrabowskiAssigned To => Kristóf Szabados
07-12-2020 12:06Jens GrabowskiStatusnew => assigned
07-12-2020 12:07Jens GrabowskiProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
07-12-2020 16:51Kristóf SzabadosFile Added: CR_7992.docx
07-12-2020 16:51Kristóf SzabadosNote Added: 0015802
07-12-2020 16:52Kristóf SzabadosAssigned ToKristóf Szabados => Tomas Urban
07-12-2020 16:52Kristóf SzabadosStatusassigned => confirmed
08-12-2020 08:36Tomas UrbanNote Added: 0015806
08-12-2020 08:36Tomas UrbanStatusconfirmed => resolved
08-12-2020 08:36Tomas UrbanResolutionopen => fixed
08-12-2020 08:36Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
16-12-2020 17:01Gyorgy RethyNote Added: 0015872
16-12-2020 17:01Gyorgy RethyStatusresolved => closed
16-12-2020 17:01Gyorgy RethyProduct Version => 4.12.1 (published 2020-05)
16-12-2020 17:01Gyorgy RethyFixed in Version => 4.13.1 (ongoing)
16-12-2020 17:01Gyorgy RethyTarget Version => 4.13.1 (ongoing)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015802) +
+ Kristóf Szabados    +
+ 07-12-2020 16:51    +
+ 		+ + + + +
+ please check.
+
+
+
+ + + + + + + + + + +
+ (0015806) +
+ Tomas Urban    +
+ 08-12-2020 08:36    +
+ 		+ + + + +
+ The proposed changes resolve the issue raised in the CR and can be added to the next version of the specification.
+
+
+
+ + + + + + + + + + +
+ (0015872) +
+ Gyorgy Rethy    +
+ 16-12-2020 17:01    +
+ 		+ + + + +
+ Implemented in draft 4.12.2
+
+ + diff --git a/docs/mantis/CR7993.md b/docs/mantis/CR7993.md new file mode 100644 index 0000000000000000000000000000000000000000..adb10fcb9b669612f6b469717c39402aee38a007 --- /dev/null +++ b/docs/mantis/CR7993.md @@ -0,0 +1,109 @@ + + + + + + + + + + + + + 0007993: Ambiguous description and example for constructors - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Object-oriented features (ES 203 790)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007993Ext Pack: Object-oriented features (ES 203 790)[All Projects] Generalpublic26-11-2020 10:4127-12-2020 13:04
ReporterKristóf Szabados 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product VersionV1.2.1 (published 2020-05) 
Target VersionV1.3.1 (ongoing)Fixed in Version 
Summary0007993: Ambiguous description and example for constructors
DescriptionSection 5.1.1.5 states:
+"and one additional formal in parameter for each declared var field of the class itself and also all const or template fields with no initializer"
+
+This is a bit confusing, as it can be read like:
+- there is always a formal in parameter for each var
+- there is a formal in parameter for a var if an only if it has no initializer.
+
+This description also does not make it clear if var template are counted as var, or they are always excluded from having a formal in parameter.
+
+Please note that example 2 is supposed to demonstrate what happens, but it is also confusing.
+for example:
+ "varinteger a := 5; // 1"
+Why does "a" become one, when it is clealy assigned the value 5 and the value 1 does not show up anywhere in the example?
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR_7993.docx (136,900) 08-12-2020 21:16
http://oldforge.etsi.org/mantis/file_download.php?file_id=3977&type=bug
Issue History
Date ModifiedUsernameFieldChange
26-11-2020 10:41Kristóf SzabadosNew Issue
07-12-2020 12:24Jens GrabowskiAssigned To => Kristóf Szabados
07-12-2020 12:24Jens GrabowskiStatusnew => assigned
08-12-2020 21:16Kristóf SzabadosFile Added: CR_7993.docx
08-12-2020 21:17Kristóf SzabadosNote Added: 0015816
08-12-2020 21:17Kristóf SzabadosAssigned ToKristóf Szabados => Jacob Wieland - Spirent
08-12-2020 21:17Kristóf SzabadosStatusassigned => confirmed
09-12-2020 11:10Jacob Wieland - SpirentNote Added: 0015824
09-12-2020 11:10Jacob Wieland - SpirentStatusconfirmed => resolved
09-12-2020 11:10Jacob Wieland - SpirentResolutionopen => fixed
09-12-2020 11:10Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Jens Grabowski
17-12-2020 16:19Gyorgy RethyProduct Version => V1.2.1 (published 2020-05)
17-12-2020 16:19Gyorgy RethyTarget Version => V1.3.1 (ongoing)
27-12-2020 13:04Jens GrabowskiStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015816) +
+ Kristóf Szabados    +
+ 08-12-2020 21:17    +
+ 		+ + + + +
+ Uploaded the first version of the proposal, please check.
+
+
+
+ + + + + + + + + + +
+ (0015824) +
+ Jacob Wieland - Spirent    +
+ 09-12-2020 11:10    +
+ 		+ + + + +
+ All ok, resolved
+
+ + diff --git a/docs/mantis/CR7994.md b/docs/mantis/CR7994.md new file mode 100644 index 0000000000000000000000000000000000000000..c4192c7b20429567191fae24ad983a67d21a4ea7 --- /dev/null +++ b/docs/mantis/CR7994.md @@ -0,0 +1,350 @@ + + + + + + + + + + + + + 0007994: Allow coordinated shared access to component variables. - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007994Part 01: TTCN-3 Core LanguageNew Featurepublic08-12-2020 12:0307-12-2022 08:20
ReporterJacob Wieland - Spirent 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionwon't fix 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Clause Reference(s)?
Source (company - Author)Spirent - Jacob Wieland
Summary0007994: Allow coordinated shared access to component variables.
DescriptionAt the moment, there are no shared global variables in TTCN-3. If data are to be shared, they must be communicated over message channels between components, causing the usual problems of keeping everything in sync. This obfuscates the intention of the test code and makes it unmanageable.
+
+We propose a new statement of the form
+
+on <component-ref> [@readonly] StatementBlock
+
+where inside StatementBlock expressions of the form <component-ref>.<component-var> are allowed, in case of a @readonly on-statement only on the right-hand side, otherwise also on the left hand side of assignments (i.e. also as out parameters to functions).
+
+An on-statement can only be entered if the referenced component itself is either not running a behavior or is in the waiting state of an alt-statement, and no other component is inside an write-on-statement block. A write-on-statement block can also not be entered if at least one other component is in a readonly on-statement. readonly on-statements are not mutually exclusive, though, so concurrent read-access is possible.
+
+For example:
+
+on inventoryComp { // acquire read-write lock on inventoryComp
+  if (inventoryCom.inventory > 0) {
+    inventoryComp.inventory := inventoryComp.inventory - 1;
+    state := "in_stock";
+  } else {
+    state := "out_of_stock";
+  }
+  sut.send("purchase");
+  alt {
+  [] sut.receive(state) { setverdict(pass) }
+  [] sut.receive { setverdict(fail) }
+  }
+} // leave on-block and release read-write-lock of inventoryComp
+
+
Steps To ReproduceThis idea was developed for a use case of concurrent testing of web-service where one PTC can change the state of the SUT and thus a global oracle needs to be updated so that the other PTCs know what response of the SUT to expect.
+
+See the paper discussing different approaches to solve this problem here:
+
+https://www.thinkmind.org/articles/soft_v13_n34_2020_7.pdf [^]
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
08-12-2020 12:03Jacob Wieland - SpirentNew Issue
08-12-2020 12:06Jacob Wieland - SpirentNote Added: 0015810
09-12-2020 09:09Jens GrabowskiProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
09-12-2020 09:32Jens GrabowskiAssigned To => Jacob Wieland - Spirent
09-12-2020 09:32Jens GrabowskiStatusnew => assigned
09-12-2020 09:33Jens GrabowskiAssigned ToJacob Wieland - Spirent => Tomas Urban
10-12-2020 13:49Jacob Wieland - SpirentNote Added: 0015842
18-12-2020 15:39Gyorgy RethyNote Added: 0015894
10-09-2021 14:32Jens GrabowskiNote Added: 0015983
10-09-2021 14:32Jens GrabowskiAssigned ToTomas Urban => Gusztáv Adamis
10-11-2021 12:36Jens GrabowskiNote Added: 0016052
10-11-2021 12:36Jens GrabowskiAssigned ToGusztáv Adamis => Jacob Wieland - Spirent
11-11-2021 15:06Jacob Wieland - SpirentSteps to Reproduce Updatedbug_revision_view_page.php?rev_id=574#r574
11-11-2021 15:06Jacob Wieland - SpirentNote Added: 0016068
11-11-2021 15:07Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gusztáv Adamis
17-08-2022 08:09Jens GrabowskiAssigned ToGusztáv Adamis => Matthias Simon
10-11-2022 20:51Matthias SimonNote Added: 0016300
10-11-2022 20:53Matthias SimonAssigned ToMatthias Simon => Jens Grabowski
07-12-2022 08:20Jens GrabowskiNote Added: 0016362
07-12-2022 08:20Jens GrabowskiStatusassigned => closed
07-12-2022 08:20Jens GrabowskiResolutionopen => won't fix
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015810) +
+ Jacob Wieland - Spirent    +
+ 08-12-2020 12:06    +
+ 		+ + + + +
+ In the object-oriented setting, this feature could also grant access to call methods in another component's objects.
+
+
+
+ + + + + + + + + + +
+ (0015842) +
+ Jacob Wieland - Spirent    +
+ 10-12-2020 13:49    +
+ 		+ + + + +
+ Concerns so far:
+
+1) New/additional way of communication/data transfer between components.
+
+2) Maybe too coarse on the component level, possibly the concept of a (readonly or read-write) monitor associated with variables to be accessible through it should be introduced.
+The on statement would then work on that monitor.
+The component could be a default monitor allowing access to its members.
+In this approach, also the owning component needs to access its monitored variables through the monitor, i.e. it would also need to use on-blocks in its own behaviour (though this added explicitness is probably a good thing). With the originally proposed approach, this is implicitly done with the 'runs on' clause.
+
+3) Maybe access to variables should be somehow explicitly granted in the component or class definition so that normal members can not be accessed by foreign components but specifically accessible members can be. That way, the implementation has full control over its internal variables and exposes only those it wants others to access/change. Needs a new "external accessibility" concept similar to visibility. Access could be granted as readonly or read-write.
+
+This would also make it easier to implement performantly as otherwise, monitoring capabilities would need to be provided potentially for all component members.
+
+4) Changing the variable holding the component/monitor reference in an on-block shall be disallowed to ensure static checkability.
+
+
+
+ + + + + + + + + + +
+ (0015894) +
+ Gyorgy Rethy    +
+ 18-12-2020 15:39    +
+ 		+ + + + +
+ Global variables were available in TTCN-2/TTCN-2+. It was an deliberate design decision NOT TO INCLUDE GLOBAL VARIABLES in TTCN-3, due to the bad experience in TTCN-2.
+
+In case of distributed test environment, what is very common, they would result execution ambiguity due to race conditions, what would hurt one of the basic principles of testing: repeatability.
+
+Ericsson doesn't support this idea.
+
+
+
+ + + + + + + + + + +
+ (0015983) +
+ Jens Grabowski    +
+ 10-09-2021 14:32    +
+ 		+ + + + +
+ STF discussion: will be discussed during the next session.
+
+
+
+ + + + + + + + + + +
+ (0016052) +
+ Jens Grabowski    +
+ 10-11-2021 12:36    +
+ 		+ + + + +
+ STF discussion: Jacob to provide complete use case and further information (link to paper) about the proposal. Proposal: implement feature in deployment and configuration package.
+
+
+
+ + + + + + + + + + +
+ (0016068) +
+ Jacob Wieland - Spirent    +
+ 11-11-2021 15:06    +
+ 		+ + + + +
+ Added a link to the paper in (Steps to Reproduce above).
+
+
+
+ + + + + + + + + + +
+ (0016300) +
+ Matthias Simon    +
+ 10-11-2022 20:51    +
+ 		+ + + + +
+ Access to component variables seems like a good compromise to create a shared state without global variables.
+
+However I don't support this CR, because there are still too many open questions.
+
+
+
+ + + + + + + + + + +
+ (0016362) +
+ Jens Grabowski    +
+ 07-12-2022 08:20    +
+ 		+ + + + +
+ TTF discussion: The TTF decides to close the topic. More examples of usage would be helpful. The CR may be reopened in case of new insights.
+
+ + diff --git a/docs/mantis/CR7996.md b/docs/mantis/CR7996.md new file mode 100644 index 0000000000000000000000000000000000000000..4c55d019e8ea7ce63d5abfbe83e937f7d4f0256b --- /dev/null +++ b/docs/mantis/CR7996.md @@ -0,0 +1,226 @@ + + + + + + + + + + + + + 0007996: Are the keys of a set type unique? - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007996Part 01: TTCN-3 Core LanguageClarificationpublic09-12-2020 18:1815-12-2020 16:20
ReporterKristóf Szabados 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version4.13.1 (ongoing) 
Target Version4.13.1 (ongoing)Fixed in Version4.13.1 (ongoing) 
Clause Reference(s)6.2.15
Source (company - Author)L.M. Ericsson
Summary0007996: Are the keys of a set type unique?
DescriptionThere seems to be an interesting issue with the current description of how map types work: it is not clear if the keys of the map have to be unique or not.
+
+Section 6.2.15.0:
+"TTCN-3 supports the specification of map types that map from a set of keys to a set of values in such a way that each value in the set of key is associated with exactly one value in the set of values."
+Please note, that there is no requirement for the keys to be unique ... a set of type in TTCN-3 can contain the same value several times.
+
+This is important to clarify as a map with unique keys differs greatly from a map that would allow the same value for multiple keys at the same time.
+For example:
+- if the keys are unique, index notation used in the right hand side can refers to only a single element (or results in an error), but if the keys are not unique it needs to return a set of values that migth be associated with that key value (in this case a not existing key could return an empty set of instead of resulting in error).
+- In the case of left hand side usage, if the keys are unique the behaviour is quite well definied ... but if the keys are not unique, will it change all values mapped to the same key value, or only one of them?
+
+etc...
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR7996-1.docx (189,697) 10-12-2020 09:07
http://oldforge.etsi.org/mantis/file_download.php?file_id=3984&type=bug
Issue History
Date ModifiedUsernameFieldChange
09-12-2020 18:18Kristóf SzabadosNew Issue
10-12-2020 08:52Kristóf SzabadosNote Added: 0015835
10-12-2020 08:53Tomas UrbanNote Added: 0015836
10-12-2020 08:53Tomas UrbanAssigned To => Kristóf Szabados
10-12-2020 08:53Tomas UrbanStatusnew => confirmed
10-12-2020 08:58Kristóf SzabadosNote Added: 0015837
10-12-2020 08:59Kristóf SzabadosNote Added: 0015838
10-12-2020 08:59Kristóf SzabadosStatusconfirmed => assigned
10-12-2020 09:00Kristóf SzabadosAssigned ToKristóf Szabados => Tomas Urban
10-12-2020 09:07Tomas UrbanFile Added: CR7996-1.docx
10-12-2020 09:12Jens GrabowskiStatusassigned => resolved
10-12-2020 09:12Jens GrabowskiResolutionopen => fixed
10-12-2020 09:12Jens GrabowskiAssigned ToTomas Urban => Gyorgy Rethy
15-12-2020 16:19Gyorgy RethyStatusresolved => closed
15-12-2020 16:19Gyorgy RethyProduct Version => 4.13.1 (ongoing)
15-12-2020 16:19Gyorgy RethyFixed in Version => 4.13.1 (ongoing)
15-12-2020 16:19Gyorgy RethyTarget Version => 4.13.1 (ongoing)
15-12-2020 16:20Gyorgy RethyNote Added: 0015858
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015835) +
+ Kristóf Szabados    +
+ 10-12-2020 08:52    +
+ 		+ + + + +
+ Please note, that we should somehow warn the users, that accessing map elements is a O(n*m) operation.
+
+As there is no hashing function, the indexing itself has to linearly check each element in the map to determine which the key is refering to making it a O(n) operation in worst case (the average might be around O(n/2)).
+
+And as the keys can be complex types too, the checks of the index value against the set of keys might also be a costly operation O(m) where m stands for the elements/fields of the type of the key.
+
+
+
+ + + + + + + + + + +
+ (0015836) +
+ Tomas Urban    +
+ 10-12-2020 08:53    +
+ 		+ + + + +
+ In my opinion the keys are required to be unique. Although the specification doesn't state it explicitly, there are rules that actually mean that.
+
+1. In 6.2.15.2 (indexed assignment) the rules say that re-assignment occurs if an existing key is used and requires the index expressions (i.e. the keys) to be unique.
+
+2. In 6.2.15.4 (index notation) the rules say that if an existing key is used on the left hand side of an assignment, the value associated with it is overwritten.
+
+Since these are the only two ways of adding values to the map, I think the current rules grant uniqueness of keys. Nevertheless, I made small modifications to the text in order avoid possible misinterpretation.
+
+Please check.
+
+
+
+ + + + + + + + + + +
+ (0015837) +
+ Kristóf Szabados    +
+ 10-12-2020 08:58    +
+ 		+ + + + +
+ Yes in fact 6.2.15.2 restriction a also describes that in index assignment notation, the indexes have to be unique.
+That, however is still not a property of the map type, but the notation.
+
+Please note that while both of your point is valid in the context of us assuming unique keys, if we do not have this assumption they become underspecified (which key and value are they applyed to)
+
+
+
+ + + + + + + + + + +
+ (0015838) +
+ Kristóf Szabados    +
+ 10-12-2020 08:59    +
+ 		+ + + + +
+ Also you mention of having changed something in the text, but there is no new attachment.
+
+
+
+ + + + + + + + + + +
+ (0015858) +
+ Gyorgy Rethy    +
+ 15-12-2020 16:20    +
+ 		+ + + + +
+ Implemented in draft 4.12.2
+
+ + diff --git a/docs/mantis/CR7998.md b/docs/mantis/CR7998.md new file mode 100644 index 0000000000000000000000000000000000000000..af5def24f49a57bca756f67fe13b6f4ce8587ec7 --- /dev/null +++ b/docs/mantis/CR7998.md @@ -0,0 +1,209 @@ + + + + + + + + + + + + + 0007998: lengthof for maps - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007998Part 01: TTCN-3 Core LanguageClarificationpublic17-12-2020 10:2423-11-2021 09:46
ReporterGyorgy Rethy 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version4.13.1 (ongoing) 
Target VersionNext version (to be decided)Fixed in Version 
Clause Reference(s)C.2.1
Source (company - Author)TTF T003
Summary0007998: lengthof for maps
DescriptionThis is a follow-up CR of 7990, which has been implemented in v4.13.1.
+I have noticed during its implementation that there was a comment from Kristóf, which was not covered by the solution:
+"There is no example for what happens, when a key is mapped to the not used symbol. If this is to be handled as a special case, and could be assigned to 2 different keys ... than the above definition would not be usable with the to selector, that also returns a set of values."
+
+So, let discuss and decide if any further action/clarification is needed or not.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
child of 0007990closed Gyorgy Rethy lengthof for maps 
Attached Filesdocx CR7998.docx (171,127) 07-09-2021 16:53
http://oldforge.etsi.org/mantis/file_download.php?file_id=4005&type=bug
Issue History
Date ModifiedUsernameFieldChange
17-12-2020 10:24Gyorgy RethyNew Issue
17-12-2020 10:24Gyorgy RethyStatusnew => assigned
17-12-2020 10:24Gyorgy RethyAssigned To => Gyorgy Rethy
17-12-2020 10:24Gyorgy RethyIssue generated from: 0007990
17-12-2020 10:24Gyorgy RethyRelationship addedchild of 0007990
17-12-2020 10:25Gyorgy RethyAssigned ToGyorgy Rethy =>
17-12-2020 10:25Gyorgy RethyStatusassigned => new
06-09-2021 10:55Jens GrabowskiAssigned To => Jacob Wieland - Spirent
06-09-2021 10:55Jens GrabowskiStatusnew => assigned
06-09-2021 14:53Jacob Wieland - SpirentNote Added: 0015938
06-09-2021 14:54Jacob Wieland - SpirentNote Edited: 0015938bug_revision_view_page.php?bugnote_id=15938#r555
07-09-2021 16:53Jacob Wieland - SpirentFile Added: CR7998.docx
07-09-2021 16:54Jacob Wieland - SpirentNote Added: 0015954
07-09-2021 16:54Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Tomas Urban
07-09-2021 16:54Jacob Wieland - SpirentStatusassigned => confirmed
09-09-2021 06:55Tomas UrbanNote Added: 0015958
09-09-2021 06:55Tomas UrbanStatusconfirmed => resolved
09-09-2021 06:55Tomas UrbanResolutionopen => fixed
09-09-2021 06:56Tomas UrbanStatusresolved => feedback
09-09-2021 06:56Tomas UrbanResolutionfixed => reopened
09-09-2021 06:59Tomas UrbanNote Added: 0015959
09-09-2021 06:59Tomas UrbanStatusfeedback => resolved
09-09-2021 06:59Tomas UrbanResolutionreopened => fixed
09-09-2021 06:59Tomas UrbanAssigned ToTomas Urban => Jens Grabowski
23-11-2021 09:46Jens GrabowskiNote Added: 0016091
23-11-2021 09:46Jens GrabowskiStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015938) +
+ Jacob Wieland - Spirent    +
+ 06-09-2021 14:53    +
(edited on: 06-09-2021 14:54)
+ 		+ + + + +
+ Assigning the 'not used' symbol (I guess you mean the '-') to any key is just a notation for not changing that key's association, i.e. if the key was not mapped to a value it is not mapped to a value afterwards and if it was mapped to the value, that mapping does not change. If the symbol is assigned to two or more keys in parallel, the same applies for all the mappings of all those keys.
+
+The to operator on a map returns a 'set of ToType', which is a (mathematical) multi-set. Thus, if multiple keys are mapped to the same value by the map, the to operator will yield a set of (i.e. the values in no particular order) containing the same value multiple times.
+
+Thus, the following property holds: lengthof(m) == lengthof(m.from) == lengthof(m.to)
+
+
+
+
+
+ + + + + + + + + + +
+ (0015954) +
+ Jacob Wieland - Spirent    +
+ 07-09-2021 16:54    +
+ 		+ + + + +
+ please review
+
+
+
+ + + + + + + + + + +
+ (0015958) +
+ Tomas Urban    +
+ 09-09-2021 06:55    +
+ 		+ + + + +
+ I have found no issues in the proposed resolution. It can be added to the next version of the core language specification.
+
+
+
+ + + + + + + + + + +
+ (0015959) +
+ Tomas Urban    +
+ 09-09-2021 06:59    +
+ 		+ + + + +
+ Reassigning to Jens (until it becomes clear who will prepare the final draft of the core language)
+
+
+
+ + + + + + + + + + +
+ (0016091) +
+ Jens Grabowski    +
+ 23-11-2021 09:46    +
+ 		+ + + + +
+ implemented
+
+ + diff --git a/docs/mantis/CR7999.md b/docs/mantis/CR7999.md new file mode 100644 index 0000000000000000000000000000000000000000..bce6208efd5318eec465d2562e0816661b82fd4b --- /dev/null +++ b/docs/mantis/CR7999.md @@ -0,0 +1,905 @@ + + + + + + + + + + + + + 0007999: Evaluation of function calls in templates - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007999Part 01: TTCN-3 Core LanguageTechnicalpublic15-01-2021 10:2001-12-2021 08:25
ReporterWolfgang Seka 
Assigned ToJens Grabowski 
PrioritynormalSeveritymajorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version4.13.1 (ongoing) 
Clause Reference(s)15.3
Source (company - Author)     MCC TF160 - Wolfgang
Summary0007999: Evaluation of function calls in templates
DescriptionES 201 873-1 clause 15.3 distinguishes template fields affected by parameterisation from (static) template fields not affected by parameterisation: "Both global and local templates are initialized at the place of their declaration. This means, all template fields which are not affected by parameterization shall receive a value or matching mechanism. Template fields affected by parameterization are initialized at the time of template use."
+
+Use of pre-defined (built-in) functions (e.g. testcasename) or external functions does not seem to have been considered (yet).
+
+Strictly applying clause 15.3 may cause non-deterministic behaviour as a function call from a template, not using any parameter of this template, may be treated as static and therefore done only once at the point in time when the static fields are evaluated. This point in time depends on the compiler implementation and on the test environment.
+
+=> When e.g. using, in a send-template, an external function retrieving the system time, the used time value may not be the time when sending the message but a non-deterministic time somewhere in the past. This is surely not what a user wants or expects.
+
+=> We would like to propose to clarify ES 201 873-1 clause 15.3 to explicitly state that template fields using function calls shall be treated like template fields which are affected by parameterization. Hereafter is an example text update to exemplify what we have in mind:
+
+"Both global and local templates are initialized at the place of their declaration. This means, all template fields which are not affected by parameterization shall receive a value or matching mechanism. Template fields affected by parameterization or using function calls are initialized at the time of template use."
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0008032closed Jens Grabowski BNF links and formatting 
Attached Filesdocx CR7999.docx (173,425) 05-02-2021 12:39
http://oldforge.etsi.org/mantis/file_download.php?file_id=3995&type=bug
docx CR7999-v2.docx (198,269) 07-02-2021 09:33
http://oldforge.etsi.org/mantis/file_download.php?file_id=3996&type=bug
docx CR7999-v3.docx (253,255) 09-09-2021 11:30
http://oldforge.etsi.org/mantis/file_download.php?file_id=4010&type=bug
docx CR7999-v4.docx (332,918) 08-11-2021 10:36
http://oldforge.etsi.org/mantis/file_download.php?file_id=4017&type=bug
docx CR7999-v5.docx (279,176) 08-11-2021 14:35
http://oldforge.etsi.org/mantis/file_download.php?file_id=4027&type=bug
Issue History
Date ModifiedUsernameFieldChange
15-01-2021 10:20Wolfgang SekaNew Issue
20-01-2021 18:01Jacob Wieland - SpirentNote Added: 0015901
21-01-2021 09:43Thilo LauerNote Added: 0015902
25-01-2021 11:01Wolfgang SekaNote Added: 0015903
04-02-2021 09:51Jens GrabowskiNote Added: 0015904
05-02-2021 12:39Jacob Wieland - SpirentFile Added: CR7999.docx
05-02-2021 12:40Jacob Wieland - SpirentNote Added: 0015905
05-02-2021 12:40Jacob Wieland - SpirentAssigned To => Tomas Urban
05-02-2021 12:40Jacob Wieland - SpirentStatusnew => confirmed
07-02-2021 09:33Tomas UrbanFile Added: CR7999-v2.docx
07-02-2021 09:50Tomas UrbanNote Added: 0015906
07-02-2021 09:50Tomas UrbanAssigned ToTomas Urban => Jacob Wieland - Spirent
09-02-2021 14:36Jacob Wieland - SpirentNote Added: 0015907
10-02-2021 11:35Tomas UrbanNote Added: 0015908
11-02-2021 11:10Gyorgy RethyNote Added: 0015909
11-02-2021 11:10Gyorgy RethyNote Edited: 0015909bug_revision_view_page.php?bugnote_id=15909#r544
15-02-2021 10:28Jacob Wieland - SpirentNote Added: 0015910
24-02-2021 13:54Thilo LauerNote Added: 0015911
25-02-2021 10:30Jacob Wieland - SpirentNote Added: 0015912
23-03-2021 15:59Jens GrabowskiProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
09-09-2021 11:26Jacob Wieland - SpirentFile Added: CR7999-v3.docx
09-09-2021 11:26Jacob Wieland - SpirentFile Deleted: CR7999-v3.docx
09-09-2021 11:30Jacob Wieland - SpirentFile Added: CR7999-v3.docx
09-09-2021 11:47Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent =>
09-09-2021 11:47Jacob Wieland - SpirentAssigned To => Jacob Wieland - Spirent
09-09-2021 11:47Jacob Wieland - SpirentStatusconfirmed => assigned
09-09-2021 11:48Jacob Wieland - SpirentNote Added: 0015966
09-09-2021 11:48Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Tomas Urban
09-09-2021 11:48Jacob Wieland - SpirentStatusassigned => confirmed
14-09-2021 11:39sekawNote Added: 0015992
08-11-2021 10:36Tomas UrbanFile Added: CR7999-v4.docx
08-11-2021 10:54Tomas UrbanNote Added: 0015994
08-11-2021 10:56Tomas UrbanNote Added: 0015995
08-11-2021 10:56Tomas UrbanAssigned ToTomas Urban => Jacob Wieland - Spirent
08-11-2021 14:35Jacob Wieland - SpirentFile Added: CR7999-v5.docx
08-11-2021 14:36Jacob Wieland - SpirentNote Added: 0016005
08-11-2021 14:36Jacob Wieland - SpirentStatusconfirmed => resolved
08-11-2021 14:36Jacob Wieland - SpirentFixed in Version => 4.13.1 (ongoing)
08-11-2021 14:36Jacob Wieland - SpirentResolutionopen => fixed
08-11-2021 14:36Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Jens Grabowski
23-11-2021 11:17Jens GrabowskiNote Added: 0016092
23-11-2021 11:17Jens GrabowskiStatusresolved => closed
23-11-2021 15:28Jens GrabowskiNote Added: 0016099
23-11-2021 15:28Jens GrabowskiStatusclosed => confirmed
30-11-2021 12:14Jens GrabowskiAssigned ToJens Grabowski => Axel Rennoch
30-11-2021 12:14Jens GrabowskiStatusconfirmed => assigned
01-12-2021 07:18Axel RennochRelationship addedrelated to 0008032
01-12-2021 07:25Axel RennochNote Added: 0016135
01-12-2021 07:25Axel RennochAssigned ToAxel Rennoch => Jens Grabowski
01-12-2021 07:25Axel RennochStatusassigned => confirmed
01-12-2021 08:25Jens GrabowskiNote Added: 0016140
01-12-2021 08:25Jens GrabowskiStatusconfirmed => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015901) +
+ Jacob Wieland - Spirent    +
+ 20-01-2021 18:01    +
+ 		+ + + + +
+ The intention of the standard so far is to say that it basically should not matter where a template body is evaluated, it should have the same value in the same context. This implies that all the fields whose right-hand-side is not dependent of a parameter should be initializeable at the point of declaration of the template, while, of course, the fields that are dependent on a template parameter can only be evaluated once the formal parameter is instantiated with an actual parameter at the point of usage of the template:
+
+To illustrate this, consider the following example:
+
+type record R { integer a, integer b }
+function f(integer x) return integer { ... }
+
+function g() {
+  var integer a := 3;
+  template R t := { a, f(a) };
+  a := 5;
+
+  if (match({3,f(3)}, t)) { ... // true with the standard until now
+  }
+  if (match({3,f(5)}, t)) { ... // true with the proposal, but unexpected/confusing
+  }
+  if (match({5,f(5)}, t)) { ... // expectation if templates are fully evaluated lazy
+  }
+
+}
+
+For this reason, this would be backward incompatible change.
+
+If you want the template to consider the change of a, you should make a a parameter of the template:
+
+template R t(integer x) := { x, f(x) }
+
+and then use t(a) whereever you want { a, f(a) }
+
+
+
+ + + + + + + + + + +
+ (0015902) +
+ Thilo Lauer    +
+ 21-01-2021 09:43    +
+ 		+ + + + +
+ Additionally we would like to get a question clarified, that is related this discussion, but not covered by CR7999 Subject yet:
+
+Question, regarding the direct use of variable a:
+Using the modified function g() below, what is the expected behaviour?
+
+function g() {
+  var integer a;
+  template R t := { a, f(a) }; // local template declaration: here a is undefined; CR7999 covers f(a), but not yet the direct use of variable a
+  a := 3;
+  ...
+  a := 5;
+  p.send(t); // Question: is it a test case error (as a is not initialized at template declaration), is it { 3, f(3) } (first bound value to a is 3) or is it { 5, f(5) } (value bound to a when t is used for the first time) ?
+  ...
+}
+
+
+
+ + + + + + + + + + +
+ (0015903) +
+ Wolfgang Seka    +
+ 25-01-2021 11:01    +
+ 		+ + + + +
+ Some remarks:
+a) First of all I'm confused about Jacob's note: In your first mail you've stated that the Spirent compiler behaves as we expect i.e. evaluates function when a template is used. Or is it different for global and local templates ??
+
+b) Generally it seems that there are differences for global and local templates:
+- It is pretty clear and visible for users when a local template gets initialised; from a user's point of view it is similar to a template variable.
+- With literal interpretation of 15.3 the initialisation of a global template is unpredictable when it uses a function call like retrieving the system time. On the other hand the common expectation by users might be, that global templates behave like function calls (predictable and easy to understand).
+
+c) Different compilers seem to use different interpretations regarding global templates => the TTCN-3 standard may not be clear enough and independent of outcome of this discussion there might always be a compatibility issue:
+For MCC160 test suites it would be a severe issue when we would need to change our code to align it with changes of the compiler(s) (please note that we are using testcasename() in templates since at least ten years). And if so, the criteria for users are still not clear (as templates may use other templates using functions; in this case all templates are affected)
+
+Conclusion:
+We (MCC160) need a solution with minimum impact on our code. This would be served with the proposed clarification of 15.3. In addition global and local templates may need to be distinguished. As alternative some global directive may be introduced to specify whether or not global and/or local templates are treated as "fuzzy".
+
+
+
+ + + + + + + + + + +
+ (0015904) +
+ Jens Grabowski    +
+ 04-02-2021 09:51    +
+ 		+ + + + +
+ TTF discussion: TTF agrees that a solution is required. The TTF proposes to follow the idea of a global "fuzzy" directive (maybe as an attribute on groups or modules).
+
+
+
+ + + + + + + + + + +
+ (0015905) +
+ Jacob Wieland - Spirent    +
+ 05-02-2021 12:40    +
+ 		+ + + + +
+ uploaded draft proposal, please review
+
+
+
+ + + + + + + + + + +
+ (0015906) +
+ Tomas Urban    +
+ 07-02-2021 09:50    +
+ 		+ + + + +
+ I removed the reference to explicit lazy templates, because there's no such option in TTCN-3 at the moment. Static templates can be either fuzzy or without a modifier.
+
+However, I think we still have to discuss two aspects of the added feature:
+1. Is it necessary to change how local templates behave? Their lifetime is limited to the lifetime of their parent block and their place in the code determines quite precisely when they are initialized. I would prefer that only global templates would be affected.
+2. In case we decide in favour of local templates, there's a question what to do with template variables and parameters (which are always local). Technically they are not affected by the rule as they are quite different entities. But it might not be so obvious without detailed knowledge of the specification, so I would prefer to add a note saying they are not affected by the rule.
+
+
+
+ + + + + + + + + + +
+ (0015907) +
+ Jacob Wieland - Spirent    +
+ 09-02-2021 14:36    +
+ 		+ + + + +
+ The initializer in a template variable declaration is a place of usage, so, of course, the value (unless lazy/fuzzy) is evaluated before the assignment to the variable, at the place of the declaration of the variable.
+
+I don't see why it should be different for local and global templates. That will just add another source of confusion in my opinion. The semantics should not change if I move a local template into the global scope, if it was already independent from its context. With your proposal, suddenly the semantics could change from non-fuzzy to fuzzy.
+
+
+
+ + + + + + + + + + +
+ (0015908) +
+ Tomas Urban    +
+ 10-02-2021 11:35    +
+ 		+ + + + +
+ I admit that for the sake of consistency, it is better to have a rule that affects all static templates.
+
+However, I would still like to have the note about template variables and paremeters.
+
+We should also consider what happens, if how nesting works in case of groups. Does a group with a missing @fuzzy modifier turn off a @fuzzy setting of the surrounding module?
+
+In my opinion, it would be better if a missing modifier on a group level meant that the setting is inherited. In order to allow overwriting, I propose to introduce another modifier (e.g. @static) that would mean the old "resolve as early as possible" mode and could be used for overwriting the mode set on a higher level (both on group level and in template declarations).
+
+We should also consider adding @lazy modifier support to static templates, modules and groups. I dont'n see a reason, why it should be missing.
+
+
+
+ + + + + + + + + + +
+ (0015909) +
+ Gyorgy Rethy    +
+ 11-02-2021 11:10    +
+ 		+ + + + +
+ Hi,
+In general I disagree with the module and group @fuzzy solution for two reasons:
+- that would complicate user's life even more (and what is worth, decrease their productivity, that managers are looking at when choosing a tool/language for a new project...); a typical workflow is: user is writing/debugging a function, which uses a template. In Eclipse ctrl+F3 -> jump to definition, looks at the template; it will see the template ALONE but not it's context in term of group/module; this 'feature' could just increase users' frustration, while not really giving too much to him/her.
+- the second is Jacob's point: a definition's behavior shall not change just by moving it out of a group, into another group, other module etc. In the course of normal development re-structuring the code happens quite open in the way from a prototype to a more and more feature-rich 'product'. This could easily lead to chaos in case of such restructurings.
+
+On Thilo's question: TTCN-3 code is executed statement-by-statement. As template t is declared completely, i.e. not parameterized, it is evaluated at the place of its declaration, and as 'a' is unbound, and used as a value of a field, the send operation shall cause an error as trying to send a not completely initialized template.
+
+In summary: as a general rule, the standard should state, that the template shall be evaluated at the place where it gets completely defined. This would be a simple, easy to remember rule and remove ambiguities.
+
+
+
+
+
+ + + + + + + + + + +
+ (0015910) +
+ Jacob Wieland - Spirent    +
+ 15-02-2021 10:28    +
+ 		+ + + + +
+ I agree with Georgys assessment completely and I always thought that this was the intended way of the standard. Unfortunately, this clarification seems to cause trouble for people because some tools misinterpreted the standard (or did not read it as it was intended) and this led to problems with certain code when used by different tools that interepreted it more like the standard intended.
+
+This will then lead to the old code having to be rewritten. In general, I am confused about the whole situation as we informed people that were using our tools some years ago what the problem with their code was (when the problem first cropped up after testcasename was introduced) and they obviously did not heed our advice and instead chose to use other tools which now cause this problem.
+
+
+
+ + + + + + + + + + +
+ (0015911) +
+ Thilo Lauer    +
+ 24-02-2021 13:54    +
+ 		+ + + + +
+ In preparation of tomorrow's GoToMeeting:
+-----------------------------------------
+To get back to FACTS and towards a COMMON understanding of the TTCN-3 standard
+let's have a look at this enhanced example and questions Q1 .. Q4:
+
+type record R { integer a, integer b, integer c }
+function f(integer x) return integer { ... }
+function g() {
+  var integer a, c:=2;
+  // local template declarations:
+  template R t := { a, f(a), c}; // field 'a' is undefined; field 'c' is NOT parameterized
+  template R u(integer k) := {k * a, k* f(a), c}; // field 'a' is undefined, param 'k' has NO default value, field 'c' is NOT parameterized
+  template R v := {8, f(9), c}; // all fields are defined at template declaration time
+  template R w(integer m := 1) := {m * 8, m * f(9), m * c}; // param 'm' has default value, all fields are parameterized
+  a := 3;
+  ...
+  a := 5;
+  c := 10;
+
+  // Question 1:
+  p.send(t);
+    // Q1a: ==> ERROR as 'a' is not initialized at template declaration or
+    // Q1b: ==> { 3, f(3), 2} (first bound value to 'a' is 3 and to 'c' is 2)
+    // Q1c: ==> { 5, f(5), 2} (value bound to 'a' when 't' is used for the first time)
+    // Q1d: ==> { 5, f(5), 10} (completely evaluated at time of use)
+
+  // Question 2:
+  p.send(u(1)); // note: p should be a LOOPBACK port (!)
+  p.receive(t); // should it match?, see Question 1 above
+    // Q2a: p.send(u(1)); ==> { 1*5, 1*f(5), 2} ==> { 5, f(5), 2} (only parameterized fields are evaluated, 'c' is 2 at decl. time)
+    // Q2b: p.send(u(1)); ==> { 1*5, 1*f(5), 10} ==> { 5, f(5), 10} (completely evaluated at time of use)
+
+  // Question 3: How to explain possible differences to TTCN-3 users / test suite maintainers?
+  p.send(v()); // Q3a: ==> { 8, f(9), 2} (completely assigned at decl. time; although c==10 when template is used)
+  p.send(w); // Q3b: ==> { 1*8, 1*f(9), 1*2} ==> { 8, f(9), 2 } (completely assigned at decl. time; although DECLARATION is parameterized)
+                // Q3c: ==> { 1*8, 1*f(9), 1*10} ==> { 8, f(9), 10 } (completely evaluated at time of use)
+  p.send(w(1)); // Q3d: ==> { 1*8, 1*f(9), 1*10} ==> { 8, f(9), 10 } (all fields are parameterized and therefore evaluated at time of use)
+
+  // Q4: Generally asking from a TTCN-3 user's perspective:
+  // ======================================================
+  // How to remember easily the differences between u(1) and t AND between v, w and w(1) ???
+  // Why do we need different handling rules for parameterized and non-parameterized templates?
+}
+
+
+
+ + + + + + + + + + +
+ (0015912) +
+ Jacob Wieland - Spirent    +
+ 25-02-2021 10:30    +
+ 		+ + + + +
+ Discussion with STF 160: We propose to introduce a template-field modifier @fuzzy into the standard that signifies that the evaluation of the right-hand-side of the field is deferred until the place of usage of the field (where modification of the template or instantiation of the template inside another template does not count as 'place of usage').
+
+Such a fuzzy field shall only be evaluated inside a template-structure when the whole template-structure is evaluated for use (i.e. for sending, for isvalue, for matching or other places that require templates to be evaluated like actual parameters).
+
+Here a few examples to my current understanding of the new feature:
+
+template R base := { @fuzzy name := testcasename() }
+
+template R modifiedR modifies base := { a := 5 } // name-field is still fuzzy
+
+template R modifiedR2 modifies base := { name := "foobar" } // name-field not fuzzy
+
+When a fuzzy field is used in some non-fuzzy evaluation, it needs to be evaluated.
+
+template R modifiedR3 modifies base := { name := base.name & "_used" } // base.name is evaluated, so this might lead to global evaluation of the name field
+
+template R modifiedR4 modifies base := { @fuzzy name := base.name & "_used" } // here, base.name would only be evaluated when modifiedR4.name is evaluated (fuzzy field assignment overridden by new fuzzy assignment)
+
+
+
+ + + + + + + + + + +
+ (0015966) +
+ Jacob Wieland - Spirent    +
+ 09-09-2021 11:48    +
+ 		+ + + + +
+ Please review
+
+
+
+ + + + + + + + + + +
+ (0015992) +
+ sekaw    +
+ 14-09-2021 11:39    +
+ 		+ + + + +
+ A minor issue:
+The new text says "... shall only be evaluated when ...".
+So, I wonder in which cases the assignment shall not be evaluated when it would be evaluated without the "@fuzzy" modifier.
+According to my understanding the "@fuzzy" modifier should force the evaluation to be done whenever the template is used - or do I miss anything ??
+
+Furthermore the examples modifiedR3 and modifiedR4 are hard to understand (at least for me):
+Assuming that testcasename() returns "" at the time the templates are created (as no testcase is running yet), in modifiedR3 base.n is still "" and modifiedR3.n will be " used" where ever used, but modifiedR4.n is "<test case> used" with the name of the test case in which modifiedR4 is used.
+Is this correct ??
+
+And another question:
+Even though in general we are not using local templates (e.g. declared in a function) - is there any difference ??
+Is the local template of a function without any parameters and without "@fuzzy" modifier instantiated (and therefore evaluated) whenever the function is called or only once at the very beginning of a test campaign ??.
+(in the first case modifiedR3 and modifiedR4 would be effectively the same).
+
+
+
+ + + + + + + + + + +
+ (0015994) +
+ Tomas Urban    +
+ 08-11-2021 10:54    +
+ 		+ + + + +
+ Regarding Wolfgang's questions:
+
+1. Basically you are correct. However, templates with the @fuzzy modifier can be used in lazy/fuzzy context which doesn't trigger evaluation. For that reason we cannot just write "whenever the template is used", but list either the cases that trigger evaluation or the exception. We chose the fist option.
+
+2. Correct. However, there are diffirences between various tools, because the original version of the TTCN-3 core language specification didn't precisely when this evaluation should take place. Unfortunately it is impossible to overcome this issue at this point as setting a hard limit would make some of the tools incompatible with the standard.
+
+3. There are no major functional differences, both fuzzy and local templates will be evaluated inside test cases (when called). You could also use templates decladed inside component types.
+
+
+
+ + + + + + + + + + +
+ (0015995) +
+ Tomas Urban    +
+ 08-11-2021 10:56    +
+ 		+ + + + +
+ I moved the rules concerning modifications to 15.5 and made a couple of minor adjustments. Please check.
+
+
+
+ + + + + + + + + + +
+ (0016005) +
+ Jacob Wieland - Spirent    +
+ 08-11-2021 14:36    +
+ 		+ + + + +
+ Fixed one typo (modifier -> modified) but otherwise ok.
+
+
+
+ + + + + + + + + + +
+ (0016092) +
+ Jens Grabowski    +
+ 23-11-2021 11:17    +
+ 		+ + + + +
+ implemented
+
+
+
+ + + + + + + + + + +
+ (0016099) +
+ Jens Grabowski    +
+ 23-11-2021 15:28    +
+ 		+ + + + +
+ BNF needs to be checked
+
+
+
+ + + + + + + + + + +
+ (0016135) +
+ Axel Rennoch    +
+ 01-12-2021 07:25    +
+ 		+ + + + +
+ BNF changes in CR 7999 have been implemented in CR0008031+32_Core-Language-without-CR7910-r1.docx
+
+
+
+ + + + + + + + + + +
+ (0016140) +
+ Jens Grabowski    +
+ 01-12-2021 08:25    +
+ 		+ + + + +
+ Implemented
+
+ + diff --git a/docs/mantis/CR8000.md b/docs/mantis/CR8000.md new file mode 100644 index 0000000000000000000000000000000000000000..735d586b474ee228e8b737eb46cd028dd697fb61 --- /dev/null +++ b/docs/mantis/CR8000.md @@ -0,0 +1,98 @@ + + + + + + + + + + + + + 0008000: ES 201 873-1, clause 5.4.1.1, EXAMPLE 5 - v_int - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008000Part 01: TTCN-3 Core LanguageTechnicalpublic18-01-2021 10:0123-11-2021 11:23
ReporterOlivier Genoud 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Clause Reference(s)5.4.1.1
Source (company - Author)MCC TF160 - Olivier Genoud
Summary0008000: ES 201 873-1, clause 5.4.1.1, EXAMPLE 5 - v_int
DescriptionIn ES 201 873-1, clause 5.4.1.1, EXAMPLE 5: there are three occurrences of v_int, where we think it should actually be vc_int. We have attached a screenshot showing two occurrences (the third one is the TTCN comment text).
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesjpg v_int.jpg (94,500) 18-01-2021 10:01
http://oldforge.etsi.org/mantis/file_download.php?file_id=3994&type=bug
jpg

docx CR8000-210907.docx (70,255) 07-09-2021 14:16
http://oldforge.etsi.org/mantis/file_download.php?file_id=4002&type=bug
Issue History
Date ModifiedUsernameFieldChange
18-01-2021 10:01Olivier GenoudNew Issue
18-01-2021 10:01Olivier GenoudFile Added: v_int.jpg
23-03-2021 16:14Jens GrabowskiProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
06-09-2021 10:10Jens GrabowskiAssigned To => Jens Grabowski
06-09-2021 10:10Jens GrabowskiStatusnew => assigned
07-09-2021 14:16Jens GrabowskiFile Added: CR8000-210907.docx
07-09-2021 14:17Jens GrabowskiNote Added: 0015945
07-09-2021 14:17Jens GrabowskiStatusassigned => confirmed
10-09-2021 07:54Jens GrabowskiStatusconfirmed => resolved
10-09-2021 07:54Jens GrabowskiResolutionopen => fixed
23-11-2021 11:23Jens GrabowskiNote Added: 0016093
23-11-2021 11:23Jens GrabowskiStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015945) +
+ Jens Grabowski    +
+ 07-09-2021 14:17    +
+ 		+ + + + +
+ Corrected as proposed.
+
+
+
+ + + + + + + + + + +
+ (0016093) +
+ Jens Grabowski    +
+ 23-11-2021 11:23    +
+ 		+ + + + +
+ implemented
+
+ + diff --git a/docs/mantis/CR8001.md b/docs/mantis/CR8001.md new file mode 100644 index 0000000000000000000000000000000000000000..606fa06d420c835e2dd662852628c64d02db5de0 --- /dev/null +++ b/docs/mantis/CR8001.md @@ -0,0 +1,179 @@ + + + + + + + + + + + + + 0008001: Syntax Error in Constructor invocation - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Object-oriented features (ES 203 790)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008001Ext Pack: Object-oriented features (ES 203 790)[All Projects] Generalpublic26-01-2021 13:0912-11-2021 12:21
Reporterramon.barakat 
Assigned ToJens Grabowski 
PrioritylowSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0008001: Syntax Error in Constructor invocation
DescriptionIn Section 5.1.1.6 of ETSI ES203 790V1.2.1(2020-05):
+
+In the Syntactic Structure as well as in the last Example
+“var Stack v_stack := Stack.create;”
+the brackets ‘(‘, ‘)’ are missing which is against the BNF in A3.
Steps To ReproduceSee section 5.1.1.6 of ETSI ES203 790V1.2.1(2020-05)
Additional InformationThe error still exists in V1.3.1
TagsNo tags attached.
Relationships
Attached Filesdocx CR8001-210907.docx (33,752) 07-09-2021 09:31
http://oldforge.etsi.org/mantis/file_download.php?file_id=3999&type=bug
docx CR8001-rev1-210908.docx (33,939) 08-09-2021 08:58
http://oldforge.etsi.org/mantis/file_download.php?file_id=4006&type=bug
Issue History
Date ModifiedUsernameFieldChange
26-01-2021 13:09ramon.barakatNew Issue
06-09-2021 10:48Jens GrabowskiAssigned To => Jens Grabowski
06-09-2021 10:48Jens GrabowskiStatusnew => assigned
07-09-2021 09:31Jens GrabowskiFile Added: CR8001-210907.docx
07-09-2021 09:38Jens GrabowskiNote Added: 0015939
07-09-2021 09:38Jens GrabowskiAssigned ToJens Grabowski => Axel Rennoch
07-09-2021 15:21Axel RennochNote Added: 0015951
07-09-2021 15:23Axel RennochAssigned ToAxel Rennoch => Jens Grabowski
08-09-2021 08:58Jens GrabowskiNote Added: 0015955
08-09-2021 08:58Jens GrabowskiFile Added: CR8001-rev1-210908.docx
08-09-2021 08:59Jens GrabowskiStatusassigned => confirmed
10-09-2021 07:43Jens GrabowskiStatusconfirmed => resolved
10-09-2021 07:43Jens GrabowskiResolutionopen => fixed
12-11-2021 12:21Jens GrabowskiNote Added: 0016076
12-11-2021 12:21Jens GrabowskiStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015939) +
+ Jens Grabowski    +
+ 07-09-2021 09:38    +
+ 		+ + + + +
+ Axel, please check and if correct, set to confirmed.
+
+
+
+ + + + + + + + + + +
+ (0015951) +
+ Axel Rennoch    +
+ 07-09-2021 15:21    +
+ 		+ + + + +
+ The changes are NOT required since the BNF rule (TTCN-3 part 1) for "[ActualParlist]" already include the parentheses:
+
+152.ActualParList ::= "(" [(ActualPar {"," ActualPar })
+{"," ActualParAssignment} |
+(ActualParAssignment {"," ActualParAssignment})]
+")"
+
+However, in section A.2, BNF changes in clause A.1.6.4.1, the modification for "CreateOp" may be aligned with the latest rule of "CreateOp" in part 1 (now it is rule 269):
+
+CreateOp ::= ComponentType Dot CreateKeyword ["(" (SingleExpression |
+Minus) ["," SingleExpression] ")"] [AliveKeyword]
+
+
+
+ + + + + + + + + + +
+ (0015955) +
+ Jens Grabowski    +
+ 08-09-2021 08:58    +
+ 		+ + + + +
+ Parenthesis removed from syntactic structure.
+
+
+
+ + + + + + + + + + +
+ (0016076) +
+ Jens Grabowski    +
+ 12-11-2021 12:21    +
+ 		+ + + + +
+ Implemented
+
+ + diff --git a/docs/mantis/CR8002.md b/docs/mantis/CR8002.md new file mode 100644 index 0000000000000000000000000000000000000000..550b62c5e35e0bc7185b4307819f673830b15e37 --- /dev/null +++ b/docs/mantis/CR8002.md @@ -0,0 +1,201 @@ + + + + + + + + + + + + + 0008002: Operatiobn "Select class" is missing in Overview of program statements and operations - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Object-oriented features (ES 203 790)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008002Ext Pack: Object-oriented features (ES 203 790)[All Projects] Generalpublic26-01-2021 13:1712-11-2021 12:21
Reporterramon.barakat 
Assigned ToJens Grabowski 
PrioritylowSeveritytextReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0008002: Operatiobn "Select class" is missing in Overview of program statements and operations
DescriptionDocument ETSI ES203 790V1.2.1(2020-05)Section 5.2.6:
+
+The "Select class" operation is missing in the table "Extension to ETSI ES 201 873-1, clause 18 (Overview of program statements and operations)"
Steps To Reproduce
Additional InformationAuthor: TTF T003
TagsNo tags attached.
Relationships
Attached Filesdocx CR8002-210907.docx (42,260) 07-09-2021 13:49
http://oldforge.etsi.org/mantis/file_download.php?file_id=4000&type=bug
Issue History
Date ModifiedUsernameFieldChange
26-01-2021 13:17ramon.barakatNew Issue
06-09-2021 10:47Jens GrabowskiAssigned To => Jens Grabowski
06-09-2021 10:47Jens GrabowskiStatusnew => assigned
07-09-2021 13:41Jacob Wieland - SpirentNote Added: 0015940
07-09-2021 13:48Jens GrabowskiNote Added: 0015941
07-09-2021 13:48Jens GrabowskiNote Added: 0015942
07-09-2021 13:49Jens GrabowskiFile Added: CR8002-210907.docx
07-09-2021 13:50Jens GrabowskiAssigned ToJens Grabowski => Axel Rennoch
07-09-2021 15:08Axel RennochNote Added: 0015950
07-09-2021 15:08Axel RennochAssigned ToAxel Rennoch => Jens Grabowski
07-09-2021 15:08Axel RennochStatusassigned => confirmed
10-09-2021 07:44Jens GrabowskiStatusconfirmed => resolved
10-09-2021 07:44Jens GrabowskiResolutionopen => fixed
12-11-2021 12:21Jens GrabowskiNote Added: 0016075
12-11-2021 12:21Jens GrabowskiStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015940) +
+ Jacob Wieland - Spirent    +
+ 07-09-2021 13:41    +
+ 		+ + + + +
+ In my opinion, the select class case statement is not really a different statement than the select case statement, just a variant of the same. Thus, it could either be added or the other amended.
+
+
+
+ + + + + + + + + + +
+ (0015941) +
+ Jens Grabowski    +
+ 07-09-2021 13:48    +
+ 		+ + + + +
+ "Select Class" also added in the table in Clause 5.2.7
+
+
+
+ + + + + + + + + + +
+ (0015942) +
+ Jens Grabowski    +
+ 07-09-2021 13:48    +
+ 		+ + + + +
+ Axel, please check.
+
+
+
+ + + + + + + + + + +
+ (0015950) +
+ Axel Rennoch    +
+ 07-09-2021 15:08    +
+ 		+ + + + +
+ The proposed addition is fine.
+
+
+
+ + + + + + + + + + +
+ (0016075) +
+ Jens Grabowski    +
+ 12-11-2021 12:21    +
+ 		+ + + + +
+ Implemented
+
+ + diff --git a/docs/mantis/CR8003.md b/docs/mantis/CR8003.md new file mode 100644 index 0000000000000000000000000000000000000000..33d9ac9f7f3ea2f87a21de8fcd2e44df122addcb --- /dev/null +++ b/docs/mantis/CR8003.md @@ -0,0 +1,131 @@ + + + + + + + + + + + + + 0008003: Typo in Section 6.2.16 - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008003Part 01: TTCN-3 Core LanguageEditorialpublic26-01-2021 13:2923-11-2021 11:27
Reporterramon.barakat 
Assigned ToJens Grabowski 
PrioritylowSeveritytrivialReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version4.12.1 (published 2020-05) 
Target VersionFixed in Version 
Clause Reference(s)Section 6.2.16
Source (company - Author)TTF T003
Summary0008003: Typo in Section 6.2.16
Description“The open type is represented by the keyword any. It shall onlz be used in…“ needs to be „only”.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR8003-210907.docx (69,292) 07-09-2021 13:57
http://oldforge.etsi.org/mantis/file_download.php?file_id=4001&type=bug
Issue History
Date ModifiedUsernameFieldChange
26-01-2021 13:29ramon.barakatNew Issue
06-09-2021 10:47Jens GrabowskiAssigned To => Jens Grabowski
06-09-2021 10:47Jens GrabowskiStatusnew => assigned
07-09-2021 13:57Jens GrabowskiFile Added: CR8003-210907.docx
07-09-2021 13:57Jens GrabowskiNote Added: 0015943
07-09-2021 13:58Jens GrabowskiNote Added: 0015944
07-09-2021 13:58Jens GrabowskiStatusassigned => resolved
07-09-2021 13:58Jens GrabowskiResolutionopen => fixed
07-09-2021 13:58Jens GrabowskiStatusresolved => confirmed
10-09-2021 07:55Jens GrabowskiStatusconfirmed => resolved
23-11-2021 11:27Jens GrabowskiNote Added: 0016094
23-11-2021 11:27Jens GrabowskiStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015943) +
+ Jens Grabowski    +
+ 07-09-2021 13:57    +
+ 		+ + + + +
+ Typo, directly set to "confirmed"
+
+
+
+ + + + + + + + + + +
+ (0015944) +
+ Jens Grabowski    +
+ 07-09-2021 13:58    +
+ 		+ + + + +
+ Typo
+
+
+
+ + + + + + + + + + +
+ (0016094) +
+ Jens Grabowski    +
+ 23-11-2021 11:27    +
+ 		+ + + + +
+ implemented
+
+ + diff --git a/docs/mantis/CR8004.md b/docs/mantis/CR8004.md new file mode 100644 index 0000000000000000000000000000000000000000..bbf2db9db8b4db38089d873e7cf691009c01feb1 --- /dev/null +++ b/docs/mantis/CR8004.md @@ -0,0 +1,246 @@ + + + + + + + + + + + + + 0008004: Unassigned variables in return statements - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008004Part 01: TTCN-3 Core LanguageClarificationpublic16-02-2021 08:5023-11-2021 11:42
ReporterTomas Urban 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Clause Reference(s)11.1, 11.2, 16.1.0
Source (company - Author)Elvior OÜ
Summary0008004: Unassigned variables in return statements
DescriptionThe rules for using unassigned variables seem to be inconsistent. The rule for template variables (11.2.d) states:
+"Use of uninitialized template variables at other places than the left hand side of assignments, in return statements, or as actual parameters passed to formal parameters shall cause an error."
+
+There's a similar rule for value variables (11.1.d).
+
+However, the rule for functions returning templates 16.1.0.h states: "The return statement shall return a template that is at least partially initialized."
+
+Functions returning values are not restricted in such a way which makes returning an uninitialized value theoretically possible. But what are the rules for assignment in such case? Will it overwrite a variable or leave it unchanged? And if there's this option why it is not possible to use an uninitialized variable on the right side of an assignment directly?
+
+In my opinion, uninitialized values should not occur in return statements at all. I suggest to modify the rules 11.1.d and 11.2.d and remove the words "return statement" from them. In addition to that, the rules for functions should contain a new restriction saying that the value or template returned by a function should be at least partially initialized. The restriction 16.1.0 can be shortened then.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR8004-1.docx (200,095) 09-09-2021 07:35
http://oldforge.etsi.org/mantis/file_download.php?file_id=4007&type=bug
docx CR8004-2.docx (177,281) 09-09-2021 12:17
http://oldforge.etsi.org/mantis/file_download.php?file_id=4012&type=bug
Issue History
Date ModifiedUsernameFieldChange
16-02-2021 08:50Tomas UrbanNew Issue
23-03-2021 16:15Jens GrabowskiProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
27-04-2021 13:18Wolfgang SekaNote Added: 0015929
06-09-2021 09:55Jens GrabowskiNote Added: 0015935
06-09-2021 09:56Jens GrabowskiAssigned To => Tomas Urban
06-09-2021 09:56Jens GrabowskiStatusnew => assigned
09-09-2021 07:35Tomas UrbanFile Added: CR8004-1.docx
09-09-2021 07:35Tomas UrbanNote Added: 0015961
09-09-2021 07:35Tomas UrbanAssigned ToTomas Urban => Jacob Wieland - Spirent
09-09-2021 07:35Tomas UrbanStatusassigned => confirmed
09-09-2021 12:17Jacob Wieland - SpirentFile Added: CR8004-2.docx
09-09-2021 12:18Jacob Wieland - SpirentStatusconfirmed => assigned
09-09-2021 12:18Jacob Wieland - SpirentNote Added: 0015968
09-09-2021 12:18Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Tomas Urban
09-09-2021 12:18Jacob Wieland - SpirentStatusassigned => confirmed
10-09-2021 08:22Tomas UrbanNote Added: 0015973
10-09-2021 08:22Tomas UrbanStatusconfirmed => resolved
10-09-2021 08:22Tomas UrbanResolutionopen => fixed
10-09-2021 08:22Tomas UrbanAssigned ToTomas Urban => Jens Grabowski
23-11-2021 11:42Jens GrabowskiNote Added: 0016095
23-11-2021 11:42Jens GrabowskiStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015929) +
+ Wolfgang Seka    +
+ 27-04-2021 13:18    +
+ 		+ + + + +
+ We've had a discussion in this area some year ago already:
+We have cases where the return value of a function is only used in specific cases (depending on the parameters).
+=> For these functions it needs to be allowed to return an uninitialised variable (or more precise, to use an uninitialised variable in the return statement).
+Nevertheless in cases when the function returns an uninitialised variable, the return value shall not be used, i.e. the function call shall not be at the right hand side of an assignment.
+This is what we have in our test suites and therefore any further restriction would be a non-backward (i.e. not acceptable) change.
+
+
+
+ + + + + + + + + + +
+ (0015935) +
+ Jens Grabowski    +
+ 06-09-2021 09:55    +
+ 		+ + + + +
+ STF discussion: Remove resctriction 16.1.0.h and add a rule for functions returning uninitialized values (maybe as 16.1.1 g).
+
+
+
+ + + + + + + + + + +
+ (0015961) +
+ Tomas Urban    +
+ 09-09-2021 07:35    +
+ 		+ + + + +
+ Resolution uploaded, please review.
+
+
+
+ + + + + + + + + + +
+ (0015968) +
+ Jacob Wieland - Spirent    +
+ 09-09-2021 12:18    +
+ 		+ + + + +
+ Fixed a typo and changed some wording. Please review
+
+
+
+ + + + + + + + + + +
+ (0015973) +
+ Tomas Urban    +
+ 10-09-2021 08:22    +
+ 		+ + + + +
+ I agree with the corrections made by Jacob. The last draft resolves the issue raised in this CR and can be added to the next version of the core language specification.
+
+
+
+ + + + + + + + + + +
+ (0016095) +
+ Jens Grabowski    +
+ 23-11-2021 11:42    +
+ 		+ + + + +
+ implemented
+
+ + diff --git a/docs/mantis/CR8005.md b/docs/mantis/CR8005.md new file mode 100644 index 0000000000000000000000000000000000000000..5bf20fa4a3a7639afa5b9b0282bc0a9b2c2fba12 --- /dev/null +++ b/docs/mantis/CR8005.md @@ -0,0 +1,213 @@ + + + + + + + + + + + + + 0008005: It should be possible to reactivate a default - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008005Part 01: TTCN-3 Core LanguageTechnicalpublic16-02-2021 09:4323-11-2021 13:25
ReporterTomas Urban 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Clause Reference(s)20.5.2
Source (company - Author)Elvior OÜ
Summary0008005: It should be possible to reactivate a default
DescriptionCurrently the only way to activate defaults is to use a function instance in the activate statement. However, sometimes there's a need to disable a default just temporarily and reactivate it again. All defaults can be disabled in an easy way by using the @nodefault modifier. However, there are situations when it is required to suspend a single default or several, but not all of them. When reactivating it again, it doesn't seem wise to repeat the parameters again. The parameter values might not even be available in the place of activation. It would be much simpler to use the same default reference that was used in the deactivate call, to activate the default again:
+
+var default v_def := activate(a_myDefaultBehaviour());
+...
+deactivate(v_def); // deactivate the default
+alt {...} // alt block without the suspended default
+activate(v_def); // activate the default again
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR0008005.docx (28,061) 09-09-2021 14:41
http://oldforge.etsi.org/mantis/file_download.php?file_id=4015&type=bug
Issue History
Date ModifiedUsernameFieldChange
16-02-2021 09:43Tomas UrbanNew Issue
06-09-2021 16:40Jens GrabowskiAssigned To => Gusztáv Adamis
06-09-2021 16:40Jens GrabowskiStatusnew => assigned
07-09-2021 16:23Gusztáv AdamisNote Added: 0015952
07-09-2021 16:23Gusztáv AdamisNote Added: 0015953
08-09-2021 09:06Gusztáv AdamisStatusassigned => confirmed
08-09-2021 12:02Gusztáv AdamisStatusconfirmed => assigned
09-09-2021 14:30Gusztáv AdamisFile Added: DefaultSuspendResume.docx
09-09-2021 14:39Gusztáv AdamisFile Deleted: DefaultSuspendResume.docx
09-09-2021 14:41Gusztáv AdamisFile Added: CR0008005.docx
09-09-2021 14:42Gusztáv AdamisAssigned ToGusztáv Adamis => Jacob Wieland - Spirent
10-09-2021 13:28Gusztáv AdamisNote Added: 0015979
10-09-2021 13:28Gusztáv AdamisStatusassigned => confirmed
10-09-2021 16:16Jacob Wieland - SpirentNote Added: 0015987
10-09-2021 16:16Jacob Wieland - SpirentStatusconfirmed => resolved
10-09-2021 16:16Jacob Wieland - SpirentResolutionopen => fixed
10-09-2021 16:16Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Jens Grabowski
23-11-2021 13:25Jens GrabowskiNote Added: 0016096
23-11-2021 13:25Jens GrabowskiStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015952) +
+ Gusztáv Adamis    +
+ 07-09-2021 16:23    +
+ 		+ + + + +
+ After the discussion in STF the more detailed example of the request:
+
+var default v_def1 := activate(a_myDefaultBehaviour1());
+var default v_def2 := activate(a_myDefaultBehaviour2());
+var default v_def3 := activate(a_myDefaultBehaviour3());
+...
+deactivate(v_def2, true); // deactivate the default temporarily, with a second optional argument (default value false: finally deactivated as it is now; true: temporarily deactivated, suspended)
+alt {...} // alt block without the suspended default v_def2
+activate(v_def2); // re-activate the default again and the priorities of the defaults shall be the same as before suspension: v_def3 highest prio, v_def2, v_def1
+
+
+
+ + + + + + + + + + +
+ (0015953) +
+ Gusztáv Adamis    +
+ 07-09-2021 16:23    +
+ 		+ + + + +
+ After internal analysis Ericsson can support this proposal
+
+
+
+ + + + + + + + + + +
+ (0015979) +
+ Gusztáv Adamis    +
+ 10-09-2021 13:28    +
+ 		+ + + + +
+ @Jacob: pls. review the suggested solution
+
+
+
+ + + + + + + + + + +
+ (0015987) +
+ Jacob Wieland - Spirent    +
+ 10-09-2021 16:16    +
+ 		+ + + + +
+ The proposal is fine.
+
+
+
+ + + + + + + + + + +
+ (0016096) +
+ Jens Grabowski    +
+ 23-11-2021 13:25    +
+ 		+ + + + +
+ implemented
+
+ + diff --git a/docs/mantis/CR8006.md b/docs/mantis/CR8006.md new file mode 100644 index 0000000000000000000000000000000000000000..e5ce75c666bae4fb5d353e43d591de2a2d7b1267 --- /dev/null +++ b/docs/mantis/CR8006.md @@ -0,0 +1,655 @@ + + + + + + + + + + + + + 0008006: Unnecessary Restriction 15.6.1 should be removed. - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008006Part 01: TTCN-3 Core LanguageNew Featurepublic17-02-2021 12:5523-11-2021 14:57
ReporterJacob Wieland - Spirent 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version4.13.1 (ongoing) 
Clause Reference(s)15.6.1
Source (company - Author)Spirent - Jacob Wieland
Summary0008006: Unnecessary Restriction 15.6.1 should be removed.
DescriptionThe completely arbitrary restriction
+
+15.6.1 Referencing individual string elements
+It is not allowed to reference individual string elements inside templates or template fields. Instead, the substr
+function (see clause C.4.2) shall be used.
+
+should be removed from the standard. The index notation is problematic in the same cases as the substr function would be problematic (i.e. if there are matching mechanisms inside the template before the given index or index-range), so why would one be allowed and one not?
+
+This is just a confusing rule and should be removed as it serves no purpose.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0008067closed Jens Grabowski Postfix value notation for templates 
Attached Filesdocx CR8006-210907.docx (72,608) 07-09-2021 14:39
http://oldforge.etsi.org/mantis/file_download.php?file_id=4004&type=bug
docx CR8006-2.docx (100,024) 09-09-2021 09:15
http://oldforge.etsi.org/mantis/file_download.php?file_id=4008&type=bug
docx CR8006-3.docx (111,431) 10-11-2021 07:52
http://oldforge.etsi.org/mantis/file_download.php?file_id=4046&type=bug
docx CR8006-4.docx (138,520) 11-11-2021 12:47
http://oldforge.etsi.org/mantis/file_download.php?file_id=4054&type=bug
docx CR8006-5.docx (104,805) 11-11-2021 15:00
http://oldforge.etsi.org/mantis/file_download.php?file_id=4056&type=bug
docx CR8006-6.docx (145,910) 12-11-2021 10:39
http://oldforge.etsi.org/mantis/file_download.php?file_id=4059&type=bug
Issue History
Date ModifiedUsernameFieldChange
17-02-2021 12:55Jacob Wieland - SpirentNew Issue
23-03-2021 16:16Jens GrabowskiProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
27-04-2021 12:57sekawNote Added: 0015928
06-09-2021 10:09Jens GrabowskiNote Added: 0015936
06-09-2021 10:09Jens GrabowskiAssigned To => Jens Grabowski
06-09-2021 10:09Jens GrabowskiStatusnew => assigned
07-09-2021 14:38Jens GrabowskiNote Added: 0015947
07-09-2021 14:39Jens GrabowskiFile Added: CR8006-210907.docx
07-09-2021 14:41Jens GrabowskiNote Added: 0015948
07-09-2021 14:41Jens GrabowskiAssigned ToJens Grabowski => Tomas Urban
09-09-2021 09:15Tomas UrbanFile Added: CR8006-2.docx
09-09-2021 09:26Tomas UrbanNote Added: 0015962
09-09-2021 09:26Tomas UrbanAssigned ToTomas Urban => Jacob Wieland - Spirent
09-09-2021 09:26Tomas UrbanStatusassigned => confirmed
09-09-2021 10:58Jacob Wieland - SpirentNote Added: 0015964
09-09-2021 11:09Jacob Wieland - SpirentNote Added: 0015965
09-09-2021 11:48Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Tomas Urban
09-09-2021 11:48Jacob Wieland - SpirentStatusconfirmed => assigned
10-09-2021 08:44Tomas UrbanNote Added: 0015974
10-09-2021 14:24Jens GrabowskiNote Added: 0015980
10-09-2021 14:25Jens GrabowskiNote Added: 0015981
10-09-2021 14:27Jens GrabowskiNote Added: 0015982
08-11-2021 13:16Tomas UrbanRelationship addedrelated to 0008067
10-11-2021 07:52Tomas UrbanFile Added: CR8006-3.docx
10-11-2021 07:52Tomas UrbanAssigned ToTomas Urban => Jacob Wieland - Spirent
10-11-2021 07:55Tomas UrbanNote Added: 0016048
10-11-2021 14:57Jacob Wieland - SpirentNote Added: 0016056
10-11-2021 14:58Jacob Wieland - SpirentNote Edited: 0016056bug_revision_view_page.php?bugnote_id=16056#r568
10-11-2021 14:58Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Tomas Urban
11-11-2021 12:47Tomas UrbanFile Added: CR8006-4.docx
11-11-2021 12:52Tomas UrbanNote Added: 0016063
11-11-2021 12:52Tomas UrbanStatusassigned => confirmed
11-11-2021 12:52Tomas UrbanAssigned ToTomas Urban => Jacob Wieland - Spirent
11-11-2021 15:00Jacob Wieland - SpirentFile Added: CR8006-5.docx
11-11-2021 15:00Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Tomas Urban
11-11-2021 15:00Jacob Wieland - SpirentStatusconfirmed => assigned
11-11-2021 15:02Jacob Wieland - SpirentNote Added: 0016067
12-11-2021 10:39Tomas UrbanFile Added: CR8006-6.docx
12-11-2021 10:40Tomas UrbanNote Added: 0016073
12-11-2021 10:40Tomas UrbanAssigned ToTomas Urban => Jacob Wieland - Spirent
12-11-2021 10:40Tomas UrbanStatusassigned => confirmed
12-11-2021 15:38Jacob Wieland - SpirentStatusconfirmed => resolved
12-11-2021 15:38Jacob Wieland - SpirentFixed in Version => 4.13.1 (ongoing)
12-11-2021 15:38Jacob Wieland - SpirentResolutionopen => fixed
12-11-2021 15:38Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Jens Grabowski
23-11-2021 14:57Jens GrabowskiNote Added: 0016097
23-11-2021 14:57Jens GrabowskiStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015928) +
+ sekaw    +
+ 27-04-2021 12:57    +
+ 		+ + + + +
+ I appreciate this proposal !!
+
+
+
+ + + + + + + + + + +
+ (0015936) +
+ Jens Grabowski    +
+ 06-09-2021 10:09    +
+ 		+ + + + +
+ STF discussion: Restriction should be removed.
+
+
+
+ + + + + + + + + + +
+ (0015947) +
+ Jens Grabowski    +
+ 07-09-2021 14:38    +
+ 		+ + + + +
+ Clause 15.6.1 deleted.
+
+
+
+ + + + + + + + + + +
+ (0015948) +
+ Jens Grabowski    +
+ 07-09-2021 14:41    +
+ 		+ + + + +
+ Tomas you can confirm that deleting is sufficient for resolving this CR.
+
+
+
+ + + + + + + + + + +
+ (0015962) +
+ Tomas Urban    +
+ 09-09-2021 09:26    +
+ 		+ + + + +
+ I was not happy with just removing the rules as it gave no guidance what to do when the template contains something different than a specific value. So I changed the section in a similar way how the substr function works.
+
+But it would cernainly be possible to do more than that, e.g. index applied to AnyValue could yield '?'B or pattern "?". We could also return a template instead of a value (e.g. var hexstring v_hex := 'AB?CD'H; return v_hex[2]; would return '?'H), various metacharacters matching a single value (such as \s, \n etc.) could count as a single item allowing us to return a pattern.
+
+Please let me know if the proposed changes are sufficient or we need something more elaborate.
+
+
+
+ + + + + + + + + + +
+ (0015964) +
+ Jacob Wieland - Spirent    +
+ 09-09-2021 10:58    +
+ 		+ + + + +
+ I like the idea of being able to deconstruct string patterns element-wise. Maybe it would be less restrictive if the result of accessing a pattern element would also yield a pattern and that all concatenable matching elements are seen as a single element:
+
+- meta characters count as a single element and are mapped to their character.
+- AnyValue and AnyValueOrNone count as a single element
+- character groups ([a-z]) count as a single elemnet and are mapped to a pattern containing them
+- repeated elements (X#(a,b)) count as a single element
+- disjunction elements (X|Y) count as a single element
+- reference elements ({<name>}) count as a single element
+
+
+
+ + + + + + + + + + +
+ (0015965) +
+ Jacob Wieland - Spirent    +
+ 09-09-2021 11:09    +
+ 		+ + + + +
+ It would also be nice to have a function which converts a pattern into its string representation (unpattern operator, so to speak),i.e. (unpattern pattern X) == X
+
+
+
+ + + + + + + + + + +
+ (0015974) +
+ Tomas Urban    +
+ 10-09-2021 08:44    +
+ 		+ + + + +
+ I think we should discuss the details first. This kind of a change would probably require a change of the rules for the substr function (and maybe the replace function) so that they would use the same set of rules.
+
+My proposal should be changed anyway as I realized that the rules are written just for the RHS of an assignment (without actually saying that!) and we would need guidance for the LHS as well.
+
+As regards the "unpattern" operation, I generally agree that is would be a useful feature. I think we could overload the valuof operation, in which case we wouldn't need any changes on the syntax level and new keywords. But we should create a separate CR for that.
+
+
+
+ + + + + + + + + + +
+ (0015980) +
+ Jens Grabowski    +
+ 10-09-2021 14:24    +
+ 		+ + + + +
+ STF discussion: Proposal to be prepared.
+
+
+
+ + + + + + + + + + +
+ (0015981) +
+ Jens Grabowski    +
+ 10-09-2021 14:25    +
+ 		+ + + + +
+ STF discussion: New CR for value conversion required.
+
+
+
+ + + + + + + + + + +
+ (0015982) +
+ Jens Grabowski    +
+ 10-09-2021 14:27    +
+ 		+ + + + +
+ STF discussion: Index operator on string pattern should reference pattern elements and not on string elements.
+
+
+
+ + + + + + + + + + +
+ (0016048) +
+ Tomas Urban    +
+ 10-11-2021 07:55    +
+ 		+ + + + +
+ I uploaded a modified proposal that includes indexing of metacharacters and matching symbols inside templates for binary strings. The proposal doesn't include any substr and replace function modifications and examples as I think we should first agree if the proposed changes are suitable.
+
+Please check.
+
+
+
+ + + + + + + + + + +
+ (0016056) +
+ Jacob Wieland - Spirent    +
+ 10-11-2021 14:57    +
(edited on: 10-11-2021 14:58)
+ 		+ + + + +
+ 1) right-hand-side rule b is just a special case of c (the number of added ? is 0)
+
+2) Why is appending a specific character to a value-template not allowed? (in the proposal, it would have to be changed into a pattern first before appending acc. to rule e))
+
+3) Again, rule g) is just a special case of rule h)
+
+4) Rule m) should be reformulated to an If ... construction like the other rules.
+
+5) Why not treat AnyValueOrNone like AnyValue ifpresent? i.e. the result will be an ifpresent template where the AnyValue has been replaced with the appropriate string?
+
+6) In the EXAMPLE, the result for the character group shall be pattern "[a-z]"
+
+7) IN the table in the indexing column, the 3 cases of Without the preceding expression need to be changed to Including the preceding expression (as #n, #() and + constructions on their own do not constitute a proper pattern element without the expression they are applied to)
+
+8) In rule e) the to-pattern conversion should add escape backslashes for all special characters contained in the value before adding the pattern keyword.
+
+
+There also are some typos: 3 times ispresent instead of ifpresent
+
+
+
+
+
+ + + + + + + + + + +
+ (0016063) +
+ Tomas Urban    +
+ 11-11-2021 12:52    +
+ 		+ + + + +
+ I made corrections according to Jacob's feedback and changed several predefined functions to use similar rules for string templates as indexing does.
+
+Please check.
+
+I haven't added any examples yet, so please feel free to do so. But if you don't find any time for it I can add them once the rule changes are accepted.
+
+
+
+ + + + + + + + + + +
+ (0016067) +
+ Jacob Wieland - Spirent    +
+ 11-11-2021 15:02    +
+ 		+ + + + +
+ I have made some corrections to the text. Please review and then add the examples.
+
+
+
+ + + + + + + + + + +
+ (0016073) +
+ Tomas Urban    +
+ 12-11-2021 10:40    +
+ 		+ + + + +
+ Examples added. Please check.
+
+
+
+ + + + + + + + + + +
+ (0016097) +
+ Jens Grabowski    +
+ 23-11-2021 14:57    +
+ 		+ + + + +
+ implemented
+
+ + diff --git a/docs/mantis/CR8007.md b/docs/mantis/CR8007.md new file mode 100644 index 0000000000000000000000000000000000000000..b2b36d352832085f5e368169a67927315872162e --- /dev/null +++ b/docs/mantis/CR8007.md @@ -0,0 +1,199 @@ + + + + + + + + + + + + + 0008007: Nested maps should be allowed - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008007Part 01: TTCN-3 Core LanguageTechnicalpublic22-02-2021 10:3101-12-2021 08:24
ReporterTomas Urban 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Clause Reference(s)6.2.1.3, 6.2.3.1, 6.2.15.8, A.1.6.1.1
Source (company - Author)Elvior OÜ
Summary0008007: Nested maps should be allowed
DescriptionAt the moment, map types can be nested only inside map type definitions. Since already defined map types can be referenced inside other constructive types, it should be possible to use nested map types there too.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0008032closed Jens Grabowski BNF links and formatting 
Attached Filesdocx CR8007.docx (179,212) 09-09-2021 13:21
http://oldforge.etsi.org/mantis/file_download.php?file_id=4013&type=bug
Issue History
Date ModifiedUsernameFieldChange
22-02-2021 10:31Tomas UrbanNew Issue
06-09-2021 10:29Jens GrabowskiAssigned To => Jacob Wieland - Spirent
06-09-2021 10:29Jens GrabowskiStatusnew => assigned
09-09-2021 13:21Jacob Wieland - SpirentFile Added: CR8007.docx
09-09-2021 13:23Jacob Wieland - SpirentNote Added: 0015969
09-09-2021 13:23Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Tomas Urban
09-09-2021 13:23Jacob Wieland - SpirentStatusassigned => confirmed
10-09-2021 08:17Tomas UrbanNote Added: 0015972
10-09-2021 08:17Tomas UrbanStatusconfirmed => resolved
10-09-2021 08:17Tomas UrbanResolutionopen => fixed
10-09-2021 08:17Tomas UrbanAssigned ToTomas Urban => Jens Grabowski
23-11-2021 15:27Jens GrabowskiNote Added: 0016098
23-11-2021 15:27Jens GrabowskiStatusresolved => confirmed
30-11-2021 12:14Jens GrabowskiAssigned ToJens Grabowski => Axel Rennoch
30-11-2021 12:14Jens GrabowskiStatusconfirmed => assigned
01-12-2021 07:18Axel RennochRelationship addedrelated to 0008032
01-12-2021 07:24Axel RennochNote Added: 0016133
01-12-2021 07:24Axel RennochAssigned ToAxel Rennoch => Jens Grabowski
01-12-2021 07:24Axel RennochStatusassigned => confirmed
01-12-2021 08:24Jens GrabowskiNote Added: 0016138
01-12-2021 08:24Jens GrabowskiStatusconfirmed => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015969) +
+ Jacob Wieland - Spirent    +
+ 09-09-2021 13:23    +
+ 		+ + + + +
+ please review
+
+
+
+ + + + + + + + + + +
+ (0015972) +
+ Tomas Urban    +
+ 10-09-2021 08:17    +
+ 		+ + + + +
+ I have found no issues in the provided draft. The proposed changes resolve the issue raised in this CR and can be added to the next version of the core language specification.
+
+
+
+ + + + + + + + + + +
+ (0016098) +
+ Jens Grabowski    +
+ 23-11-2021 15:27    +
+ 		+ + + + +
+ BNF needs to be checked.
+
+
+
+ + + + + + + + + + +
+ (0016133) +
+ Axel Rennoch    +
+ 01-12-2021 07:24    +
+ 		+ + + + +
+ BNF changes in CR 8007 have been implemented in CR0008031+32_Core-Language-without-CR7910-r1.docx
+
+
+
+ + + + + + + + + + +
+ (0016138) +
+ Jens Grabowski    +
+ 01-12-2021 08:24    +
+ 		+ + + + +
+ Implemented
+
+ + diff --git a/docs/mantis/CR8009.md b/docs/mantis/CR8009.md new file mode 100644 index 0000000000000000000000000000000000000000..ea6d4453131392f6b04972ee6aa5a6242280ab22 --- /dev/null +++ b/docs/mantis/CR8009.md @@ -0,0 +1,149 @@ + + + + + + + + + + + + + 0008009: Missing rule for no optional attribute (or default value of the optional attribute) - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008009Part 01: TTCN-3 Core LanguageTechnicalpublic01-03-2021 10:3623-11-2021 15:40
ReporterTomas Urban 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Clause Reference(s)6.2.1.1
Source (company - Author)Elvior OÜ
Summary0008009: Missing rule for no optional attribute (or default value of the optional attribute)
DescriptionTTCN-3 core language standard defines no implicit value of the optional attribute. The rules are usually composed in such a way that there are common basic rules that always apply and then specific rules for cases when either "explicit omit" or "implicit omit" is defined. E.g. rules on list notation of record values defined in 6.2.1.0 say that "Fields not mentioned are implicitly left uninitialized." This is followed by rules for "explicit omit" which basically say the same and rules for "implicit omit" that define a different behaviour.
+
+Unfortunately, this is not always the case. E.g. rules for expansion of record values defined in 6.2.1.1.a have only two alternatives: one for "explicit omit" and the other for "implicit omit". With no default value of the optional attribute it is unclear what should happen in this case. Our tool has always used "explicit omit" for these cases, but we have recently encountered a situation when the testing environment was made in other tool which used "implicit omit".
+
+Proposal:
+Option 1: Add the following rule to the chapter 27: If no optional attribute is specified or its value is different than the standardized strings (i.e. "explicit omit", "implicit omit"), rules for "explicit omit" apply.
+
+Option 2: Change some rules in 6.2.1.0, 6.2.1.1.a and 27:
+[6.2.1.0 - assignment list notation]
+When the assignment notation is used in a scope, where the optional attribute is either unspecified or set to "explicit omit", optional and mandatory fields, not directly referred to in the notation shall remain unchanged. When optional fields of variables are not assigned explicitly, they are uninitialized (i.e. the optional attribute shall not have any effect on variables as described in clause 27.7 restriction a)).
+
+[6.2.1.0 - value list notation]
+When using value list notation in a scope where the optional attribute is either unspecified or set to "explicit omit", all remaining fields at the end of the type definition, missing from the value list notation, are left unchanged.
+
+[6.2.1.1.a]
+When expanding a value or value field of record type, the subfield referenced in the dot notation shall be set to present and all unreferenced mandatory subfields shall be left uninitialized; when the assignment is used in a scope where the optional attribute is either unspecified or equal to "explicit omit", all unreferenced optional subfields shall be left undefined. When the assignment is used in a scope where the optional attribute is equal to "implicit omit", all unreferenced optional subfields shall be set to omit.
+
+[27]
+Add the following rule: If the optional attribute has a different value than the standardized string (i.e. "explicit omit", "implicit omit"), it is considered as if the optional attribute was unspecified.
Steps To Reproduce
Additional InformationNote: There's a danger that when opting for "explicit omit" as proposed would lead to backwards incompatibility if some tools use "implicit omit" as the default option.
TagsNo tags attached.
Relationships
Attached Filesdocx CR8009.docx (172,161) 07-09-2021 14:30
http://oldforge.etsi.org/mantis/file_download.php?file_id=4003&type=bug
Issue History
Date ModifiedUsernameFieldChange
01-03-2021 10:36Tomas UrbanNew Issue
01-03-2021 10:38Tomas UrbanDescription Updatedbug_revision_view_page.php?rev_id=547#r547
01-03-2021 10:40Tomas UrbanDescription Updatedbug_revision_view_page.php?rev_id=548#r548
06-09-2021 10:22Jens GrabowskiAssigned To => Jacob Wieland - Spirent
06-09-2021 10:22Jens GrabowskiStatusnew => assigned
07-09-2021 14:30Jacob Wieland - SpirentFile Added: CR8009.docx
07-09-2021 14:31Jacob Wieland - SpirentNote Added: 0015946
07-09-2021 14:31Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Tomas Urban
07-09-2021 14:31Jacob Wieland - SpirentStatusassigned => confirmed
09-09-2021 07:01Tomas UrbanNote Added: 0015960
09-09-2021 07:01Tomas UrbanStatusconfirmed => resolved
09-09-2021 07:01Tomas UrbanResolutionopen => fixed
09-09-2021 07:01Tomas UrbanAssigned ToTomas Urban => Jens Grabowski
23-11-2021 15:40Jens GrabowskiNote Added: 0016100
23-11-2021 15:40Jens GrabowskiStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015946) +
+ Jacob Wieland - Spirent    +
+ 07-09-2021 14:31    +
+ 		+ + + + +
+ Please review (I have chosen to word it using 'implicitly' so it aligns with the other places that mention this way of definition)
+
+
+
+ + + + + + + + + + +
+ (0015960) +
+ Tomas Urban    +
+ 09-09-2021 07:01    +
+ 		+ + + + +
+ The proposed resolution addresses the issues raised in the CR and can be added to the next version of the core language specification.
+
+
+
+ + + + + + + + + + +
+ (0016100) +
+ Jens Grabowski    +
+ 23-11-2021 15:40    +
+ 		+ + + + +
+ implemented
+
+ + diff --git a/docs/mantis/CR8010.md b/docs/mantis/CR8010.md new file mode 100644 index 0000000000000000000000000000000000000000..98cb318d023e9670cc140edd7723f9d269993f6a --- /dev/null +++ b/docs/mantis/CR8010.md @@ -0,0 +1,169 @@ + + + + + + + + + + + + + 0008010: When does tliModulePar trigger? - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008010Part 06: TTCN-3 Control InterfaceClarificationpublic02-03-2021 07:1115-11-2021 12:30
ReporterTomas Urban 
Assigned To 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Clause Reference(s)7.3.4.1.92
Source (company - Author)Elvior OÜ
Summary0008010: When does tliModulePar trigger?
DescriptionThe description of the tliModulePar operation is as follows: [The tliModulePar operation] shall be called by TE to log the value of a module parameter. This event occurs after the access to the value of a module parameter.
+
+It is unclear what exactly is meant by the word "access". Is it a write access or read access or both?
+
+In my opinion there's no reason to log read access to module parameters and the operation should trigger only after setting the module parameter value.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR8010-1.docx (155,121) 10-09-2021 12:10
http://oldforge.etsi.org/mantis/file_download.php?file_id=4016&type=bug
Issue History
Date ModifiedUsernameFieldChange
02-03-2021 07:11Tomas UrbanNew Issue
06-09-2021 10:15Jens GrabowskiAssigned To => Tomas Urban
06-09-2021 10:15Jens GrabowskiStatusnew => assigned
06-09-2021 10:15Jens GrabowskiNote Added: 0015937
10-09-2021 12:10Tomas UrbanFile Added: CR8010-1.docx
10-09-2021 12:11Tomas UrbanNote Added: 0015976
10-09-2021 12:11Tomas UrbanAssigned ToTomas Urban => Jacob Wieland - Spirent
10-09-2021 12:11Tomas UrbanStatusassigned => confirmed
08-11-2021 15:21Jacob Wieland - SpirentNote Added: 0016008
08-11-2021 15:21Jacob Wieland - SpirentStatusconfirmed => resolved
08-11-2021 15:21Jacob Wieland - SpirentResolutionopen => fixed
08-11-2021 15:21Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Tomas Urban
15-11-2021 12:30Tomas UrbanNote Added: 0016086
15-11-2021 12:30Tomas UrbanStatusresolved => closed
15-11-2021 12:30Tomas UrbanAssigned ToTomas Urban =>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015937) +
+ Jens Grabowski    +
+ 06-09-2021 10:15    +
+ 		+ + + + +
+ STF discussion: Agreement
+
+
+
+ + + + + + + + + + +
+ (0015976) +
+ Tomas Urban    +
+ 10-09-2021 12:11    +
+ 		+ + + + +
+ Resolution uploaded, please check.
+
+
+
+ + + + + + + + + + +
+ (0016008) +
+ Jacob Wieland - Spirent    +
+ 08-11-2021 15:21    +
+ 		+ + + + +
+ looks fine to me
+
+
+
+ + + + + + + + + + +
+ (0016086) +
+ Tomas Urban    +
+ 15-11-2021 12:30    +
+ 		+ + + + +
+ Added to the draft 4.12.2
+
+ + diff --git a/docs/mantis/CR8017.md b/docs/mantis/CR8017.md new file mode 100644 index 0000000000000000000000000000000000000000..1daea4ee0493808b0e810ec156e60d9ece977468 --- /dev/null +++ b/docs/mantis/CR8017.md @@ -0,0 +1,552 @@ + + + + + + + + + + + + + 0008017: Useless restriction for "*" - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008017Part 01: TTCN-3 Core LanguageTechnicalpublic27-04-2021 13:3701-12-2021 08:25
ReporterWolfgang Seka 
Assigned ToJens Grabowski 
PrioritynormalSeveritymajorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Clause Reference(s)B.1.2.4
Source (company - Author)     Wolfgang - MCC160
Summary0008017: Useless restriction for "*"
DescriptionB.1.2.4 restricts the use of "*" to optional fields:
+"At the time of matching during a receiving operation, it shall be applied to optional fields of record and set templates only."
+
+It seems that there is a compiler even generating a run time error in case of a mandatory field of a template has assigned a "*", even though in this case, in contrast to other cases, there is no explicit statement to raise an error in ES 201 873-1.
+In addition it is not clear what the use of such runtime error is and there seems to be no need to do this.
+
+=> The above restriction is useless from a user's point of view and shall be removed.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0008032closed Jens Grabowski BNF links and formatting 
Attached Filesdocx CR8017-1.docx (317,682) 12-11-2021 13:47
http://oldforge.etsi.org/mantis/file_download.php?file_id=4060&type=bug
docx CR8017-2.docx (271,889) 12-11-2021 15:29
http://oldforge.etsi.org/mantis/file_download.php?file_id=4063&type=bug
Issue History
Date ModifiedUsernameFieldChange
27-04-2021 13:37Wolfgang SekaNew Issue
06-09-2021 09:22Jens GrabowskiAssigned To => Tomas Urban
06-09-2021 09:22Jens GrabowskiStatusnew => assigned
09-09-2021 09:31Jens GrabowskiProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
10-09-2021 09:58Tomas UrbanNote Added: 0015975
10-09-2021 10:00Tomas UrbanNote Edited: 0015975bug_revision_view_page.php?bugnote_id=15975#r561
10-09-2021 12:52sekawNote Added: 0015977
10-09-2021 15:42Jens GrabowskiNote Added: 0015985
08-11-2021 13:14Tomas UrbanRelationship addedrelated to 0008067
08-11-2021 13:15Tomas UrbanRelationship deletedrelated to 0008067
10-11-2021 12:18Jens GrabowskiNote Added: 0016051
10-11-2021 13:39sekawNote Added: 0016054
11-11-2021 13:49Tomas UrbanNote Added: 0016065
11-11-2021 13:49Tomas UrbanNote Edited: 0016065bug_revision_view_page.php?bugnote_id=16065#r570
11-11-2021 13:51Tomas UrbanNote Edited: 0016065bug_revision_view_page.php?bugnote_id=16065#r571
11-11-2021 14:10Tomas UrbanNote Edited: 0016065bug_revision_view_page.php?bugnote_id=16065#r572
12-11-2021 09:51Jens GrabowskiNote Added: 0016072
12-11-2021 12:33Tomas UrbanNote Edited: 0016065bug_revision_view_page.php?bugnote_id=16065#r575
12-11-2021 13:47Tomas UrbanFile Added: CR8017-1.docx
12-11-2021 13:48Tomas UrbanNote Added: 0016079
12-11-2021 13:48Tomas UrbanAssigned ToTomas Urban => Jacob Wieland - Spirent
12-11-2021 13:48Tomas UrbanStatusassigned => confirmed
12-11-2021 15:29Jacob Wieland - SpirentFile Added: CR8017-2.docx
12-11-2021 15:29Jacob Wieland - SpirentStatusconfirmed => assigned
12-11-2021 15:30Jacob Wieland - SpirentNote Added: 0016081
12-11-2021 15:30Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Tomas Urban
12-11-2021 15:30Jacob Wieland - SpirentStatusassigned => confirmed
15-11-2021 07:23Tomas UrbanNote Added: 0016082
15-11-2021 07:23Tomas UrbanStatusconfirmed => resolved
15-11-2021 07:23Tomas UrbanResolutionopen => fixed
15-11-2021 07:23Tomas UrbanAssigned ToTomas Urban => Jens Grabowski
29-11-2021 11:51Jens GrabowskiNote Added: 0016128
29-11-2021 11:51Jens GrabowskiStatusresolved => confirmed
30-11-2021 12:14Jens GrabowskiAssigned ToJens Grabowski => Axel Rennoch
30-11-2021 12:14Jens GrabowskiStatusconfirmed => assigned
01-12-2021 07:18Axel RennochRelationship addedrelated to 0008032
01-12-2021 07:25Axel RennochNote Added: 0016134
01-12-2021 07:25Axel RennochAssigned ToAxel Rennoch => Jens Grabowski
01-12-2021 07:25Axel RennochStatusassigned => confirmed
01-12-2021 08:25Jens GrabowskiNote Added: 0016139
01-12-2021 08:25Jens GrabowskiStatusconfirmed => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015975) +
+ Tomas Urban    +
+ 10-09-2021 09:58    +
(edited on: 10-09-2021 10:00)
+ 		+ + + + +
+ The statements in this CR are not correct. ES 201 873-1 contains a rule that unambiguously restricts the use of the AnyValueOrNone matching mechanism in B.1.2.4:
+
+The matching symbol "*" (AnyValueOrNone) is used to indicate that any valid value and the omission of the given optional field are acceptable. It can be assigned to templates of any type as a whole or to optional fields of set or record templates.
+
+There are also several notes about this behaviour in the section 15.7.2
+
+In my opinion the CR should be rejected. First, as stated above, there's a clear and unambiguous rule in the core language specification that lists all possible assignment targets for this symbol. Mandatory fields are not listed and therefore cannot be considered to be a valid assignment target. Second, TTCN-3 language design uses this kind of restrictions for detecting possible errors early in the compilation stage or during initialization stage of a testing environment. It also leads to faster execution of the generated code as mandatory field -> template(present) assignments can be always considered safe and the TE doesn't have to verify the content of the source field on the RHS. Third, there are significant differences in semantic rules for field referencing between AnyValue and AnyValueOrNone. The latter one produces errors in most cases which might not be caught by the compiler (in case of runtime-resolved templates). Such errors are completely unexpected for mandatory fields.
+
+However, we could consider to extend the functionality of the present operator so that it doesn't just check if the template fulfils the present restriction, but it could also convert AnyValueOrNone to AnyValue and remove ifpresent extension:
+
+type record MyTypeMandatory {
+  integer field1,
+  integer field2
+}
+
+type record MyTypeOpt {
+  integer field1 optional,
+  integer field2 optional
+}
+
+template MyTypeOpt mw_optional := {
+   field1 := *,
+   field2 := 10 ifpresent
+}
+
+template MyTypeMandatory mw_mandatory := {
+  field1 := present(mw_optional.field1),
+  field2 := present(mw_optional.field2)
+}
+// equal to:
+// template MyTypeMandatory mw_mandatory := {
+// field1 := ?,
+// field2 := 10
+//}
+
+
+
+
+
+ + + + + + + + + + +
+ (0015977) +
+ sekaw    +
+ 10-09-2021 12:52    +
+ 		+ + + + +
+ First of all I don't understand why (and have no sympathy for) you are claiming that "The statements in this CR are not correct".
+The intention of the CR is to remove a - from a user's point of view - useless rule causing a - from a user's point of view - useless and annoying runtime error.
+I think, even when you don't like it, it is still a valid request (whether it gets finally agreed is a different story).
+
+So - the main problem in this case is the runtime error, which does not bring any benefit to the user (please let me know, if you can give an example where for this case a runtime error brings a benefit for the user).
+=> As there is no common don't-raise-stupid-runtime-errors rule in the TTCN-3 core language, the easiest way seems to be to remove the rule causing the runtime error.
+
+Please note, that the problem may occur mainly as TTCN writers just don't care whether a field is optional or mandatory. They just want to express, that for a particular receive or match operation they don't care about this field at all.
+=> new rules or functionalities will not help anything as the user in general is not aware that there is any problem at all.
+
+Of course it may help when a compiler would give a hint at compilation time to make the user aware of the issue.
+But with this we would somehow end up in a don't-raise-stupid-runtime-errors rule as the compiler may raise a warning at compilation time to give the TTCN writer the chance for potential improvements of the code, but the compiler shall not raise a runtime error.
+
+Summary: I don't agree to your argumentation and would like to kindly ask the TTCN maintenance STF to think about a solution to avoid such costly and annoying runtime errors.
+
+
+
+ + + + + + + + + + +
+ (0015985) +
+ Jens Grabowski    +
+ 10-09-2021 15:42    +
+ 		+ + + + +
+ Sorry, the Mantis notes prepare and document discussions of the maintenance team. Decisions regarding further study, acceptance or rejection of CRs are made by the whole team. We are very thankful for every comment and clarification during our discussions from outside the team, e.g., reporter or observer, and will consider them during our discussions. The impression that one person can decide is wrong.
+
+For this CR, the TTF discussed the topic in detail and decided to examine the reasons for the introduction of the restriction in more detail. The TTF will then discus ways of relaxing or even removing the restriction.
+
+
+
+ + + + + + + + + + +
+ (0016051) +
+ Jens Grabowski    +
+ 10-11-2021 12:18    +
+ 		+ + + + +
+ STF disussion: Introduce proposal for ".present" operation which yields a template with a present restriction from any template. I.e., "*.present" will be interpreted as "?".
+
+
+
+ + + + + + + + + + +
+ (0016054) +
+ sekaw    +
+ 10-11-2021 13:39    +
+ 		+ + + + +
+ First of all please note, that we are currently in the middle of a RAN5 meeting so that I'm not able to check all details, but so far I don't see how another operation helps anything in this case:
+The major problem is, that "*" may unintendedly be used as parameter for a mandatory field, what is not detected by any tool at compilation time but nevertheless causes a - in my opinion useless - runtime error with some compiler.
+
+=> I don't see how another operation could solve this problem.
+NOTE: If we are aware that we are using "*" where "?" would be more appropriate we could easily change it (without any further operation)
+Only in cases where in first place it is not known whether a parameter results in "*" or "?" the operation may help, but only if people are aware that they need to use to operation (what most likely is not the case => we still end up with a useless run-time error).
+
+
+
+ + + + + + + + + + +
+ (0016065) +
+ Tomas Urban    +
+ 11-11-2021 13:49    +
(edited on: 12-11-2021 12:33)
+ 		+ + + + +
+ Unfortunately this is a case of a bad language design. At the moment, TTCN-3 disallows certain content in mandatory fields, but assignments described by Wolfgang are not restricted (i.e. assignment of an unrestricted template to a mandatory field, assignment of an optional field to a mandatory field). This leads to runtime errors which are hard to notice in the design stage and very annoying. TTCN-3 has quite elaborate rules for the present restriction, but these unfortunately do not apply in these cases.
+
+In my opinion, there are just three options how to resolve this:
+
+1. All mandatory fields shall have an implicit present restriction and then the rules specified in 15.8 would apply (according to the table 13). This feature would allow to detect (potential) issues already during compilation time and the test case designer would be forced to use either an explicit present() operation (15.13) to verify the content or the new .present operation for removing optionality from the template, depending on what their intentions are. On the minus side, this will require modification of existing test suites and the existing functionality would be just deprecated, causing only warnings in most compilers working in the default mode for a certain period of time.
+
+2. Allow assignment of matching mechanisms that match omit to mandatory fields without any restrictions as Wolfgang proposed. However, it is not as easy as it might seem. This option would lead to situations when the "omit" symbol could be accidentaly assigned to mandatory fields in the same way as * gets there in the described case. This would make the template unusable (as it can never match) and cause trouble with the valueof operation (which would require a new rule for handling this case). This issue could be prevented by specifically disallowing assignment of the "omit" symbol, but that would mean that the issue with hard-to-detect error would prevail (though in a reduced form). Besides, a new rule should be added to the section for referencing template fields so that AnyValueOrNone is treated as AnyValue if assigned to a mandatory field.
+
+3. The TE could also perform an implicit .present conversion in this case (maybe issuing a compiler warning). Compared to the 2nd solution, nothing would have to be added to the section on template field references, but the issue with omit causing a runtime error would be the same. In addition to that, such an operation would be connected with information loss and people usually prefer explicit approach in these cases.
+
+Unfortunately all approaches have some issues and are more or less backwards incompatible. That makes things quite complicated as tool providers and test developers have different preferences. I propose to discuss it again in the next TTF meeting. I personally think we should not leave it as it is, because the problem is real and affects quite many people. Wolfgang, please feel free to comment, we appreciate your input.
+
+
+
+
+
+ + + + + + + + + + +
+ (0016072) +
+ Jens Grabowski    +
+ 12-11-2021 09:51    +
+ 		+ + + + +
+ TTF discussion: After a longer discussion, the TTF will focus on option 1. Option 1 allows to detect the issue at compile or validation time and the .present operation allows explicit conversion. Note, deprecation means that the current features is still available for a certain period of time.
+
+Reason for not supporting Option 2: It would be unclear what will be the contents of a mandatory field in a template, i.e., if it would be present or not. The problem will be shifted to a later assignment.
+
+Reason for not supporting Option 3: Implicit conversion should not be introduced here as all other conversions are explicit.
+
+
+
+ + + + + + + + + + +
+ (0016079) +
+ Tomas Urban    +
+ 12-11-2021 13:48    +
+ 		+ + + + +
+ Resolution uploaded. Please check.
+
+
+
+ + + + + + + + + + +
+ (0016081) +
+ Jacob Wieland - Spirent    +
+ 12-11-2021 15:30    +
+ 		+ + + + +
+ just a small change as a sentence was grammatically incorrect. please check if my change reflects your intended meaning (in the section about implicit restrictions)
+
+please review
+
+
+
+ + + + + + + + + + +
+ (0016082) +
+ Tomas Urban    +
+ 15-11-2021 07:23    +
+ 		+ + + + +
+ Thanx for the correction.
+
+The last version of the proposal (CR8017-2.docx) can be added to the next version of the core language specification.
+
+
+
+ + + + + + + + + + +
+ (0016128) +
+ Jens Grabowski    +
+ 29-11-2021 11:51    +
+ 		+ + + + +
+ BNF needs to be checked.
+
+
+
+ + + + + + + + + + +
+ (0016134) +
+ Axel Rennoch    +
+ 01-12-2021 07:25    +
+ 		+ + + + +
+ BNF changes in CR 8017 have been implemented in CR0008031+32_Core-Language-without-CR7910-r1.docx
+
+
+
+ + + + + + + + + + +
+ (0016139) +
+ Jens Grabowski    +
+ 01-12-2021 08:25    +
+ 		+ + + + +
+ Implemented
+
+ + diff --git a/docs/mantis/CR8031.md b/docs/mantis/CR8031.md new file mode 100644 index 0000000000000000000000000000000000000000..83ba0757cc64a9c6f0ebb7a8d7b2bf84ea3953c4 --- /dev/null +++ b/docs/mantis/CR8031.md @@ -0,0 +1,146 @@ + + + + + + + + + + + + + 0008031: TTCN-3 syntax BNF productions - corrections - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008031Part 01: TTCN-3 Core LanguageTechnicalpublic11-08-2021 17:5201-12-2021 08:26
ReporterAxel Rennoch 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionNext version (to be decided)Fixed in Version 
Clause Reference(s)A.1.6
Source (company - Author)Axel Rennoch, Claude Desroches (blukaktus.com)
Summary0008031: TTCN-3 syntax BNF productions - corrections
DescriptionThe following rules contain errors:
+
+
+97.SingleTemplateExpression ::= MatchingSymbol |
+                               ({TemplateRefWithParList [ExtendedFieldReference]) | // missing closing "}"
+                                ExtendedIdentifier EnumTemplateExtension
+
+257.VarInstance ::= VarKeyword (([(LazyModifier | FuzzyModifier) [DeterministicModifier] ]
+                                  Type VarList) | ( TemplateModifier
+                                  [(LazyModifier | FuzzyModifier) ) [DeterministicModifier] ]
+                                  Type TempVarList) ) // one parenthesis ")" too many
+                                  
+466.FormalValuePar ::= [InParKeyword | InOutParKeyword | OutParKeyword )] // missing opening "("
+                       [(LazyModifier | FuzzyModifier) [DeterministicModifier] ]
+                       Type Identifier [ArrayDef] [":=" (Expression | Minus)]
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0008032closed Jens Grabowski BNF links and formatting 
Attached Filesdocx CR0008031_Core-Language-without-CR7910.docx (149,225) 10-11-2021 14:39
http://oldforge.etsi.org/mantis/file_download.php?file_id=4049&type=bug
Issue History
Date ModifiedUsernameFieldChange
11-08-2021 17:52Axel RennochNew Issue
06-09-2021 09:13Jens GrabowskiAssigned To => Axel Rennoch
06-09-2021 09:13Jens GrabowskiStatusnew => assigned
10-11-2021 14:39Axel RennochFile Added: CR0008031_Core-Language-without-CR7910.docx
10-11-2021 14:41Axel RennochRelationship addedrelated to 0008032
10-11-2021 14:43Axel RennochNote Added: 0016055
10-11-2021 14:43Axel RennochAssigned ToAxel Rennoch => Jens Grabowski
10-11-2021 14:43Axel RennochStatusassigned => confirmed
30-11-2021 12:15Jens GrabowskiAssigned ToJens Grabowski => Axel Rennoch
30-11-2021 12:15Jens GrabowskiStatusconfirmed => assigned
01-12-2021 07:26Axel RennochNote Added: 0016136
01-12-2021 07:26Axel RennochAssigned ToAxel Rennoch => Jens Grabowski
01-12-2021 07:26Axel RennochStatusassigned => confirmed
01-12-2021 08:26Jens GrabowskiNote Added: 0016141
01-12-2021 08:26Jens GrabowskiStatusconfirmed => closed
01-12-2021 08:26Jens GrabowskiResolutionopen => fixed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0016055) +
+ Axel Rennoch    +
+ 10-11-2021 14:43    +
+ 		+ + + + +
+ Please check the resolution file. All changes will also be implemented in CR 8032.
+
+
+
+ + + + + + + + + + +
+ (0016136) +
+ Axel Rennoch    +
+ 01-12-2021 07:26    +
+ 		+ + + + +
+ BNF changes in CR 8031 have been implemented in CR0008031+32_Core-Language-without-CR7910-r1.docx
+
+
+
+ + + + + + + + + + +
+ (0016141) +
+ Jens Grabowski    +
+ 01-12-2021 08:26    +
+ 		+ + + + +
+ Implemented
+
+ + diff --git a/docs/mantis/CR8032.md b/docs/mantis/CR8032.md new file mode 100644 index 0000000000000000000000000000000000000000..57058ba8f447998cba103dc892beacb4e6f39e6d --- /dev/null +++ b/docs/mantis/CR8032.md @@ -0,0 +1,173 @@ + + + + + + + + + + + + + 0008032: BNF links and formatting - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008032Part 01: TTCN-3 Core LanguageEditorialpublic18-08-2021 13:2702-12-2021 08:56
ReporterAxel Rennoch 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version4.13.1 (ongoing) 
Target VersionNext version (to be decided)Fixed in Version 
Clause Reference(s)A.1.6
Source (company - Author)Axel Rennoch, Claude Desroches (blukaktus.com)
Summary0008032: BNF links and formatting
DescriptionMost of the hyperlinks to productions are not working in the public PDF document.
+
+The formatting (colors and underlines) of keywords with existing or non-existing hyperlinks is not consistent.
+
+Indentations etc. may be aligned, space characters and brackets do not need underlines.
+
+Multiple definitions (e.g. FunctionDef) should be avoided.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0007999closed Jens Grabowski Evaluation of function calls in templates 
related to 0008017closed Jens Grabowski Useless restriction for "*" 
related to 0008007closed Jens Grabowski Nested maps should be allowed 
related to 0008067closed Jens Grabowski Postfix value notation for templates 
related to 0008031closed Jens Grabowski TTCN-3 syntax BNF productions - corrections 
Attached Filesdocx CR0008031+32_Core-Language-without-CR7910.docx (163,055) 11-11-2021 12:16
http://oldforge.etsi.org/mantis/file_download.php?file_id=4053&type=bug
docx CR0008031+32_Core-Language-without-CR7910-r1.docx (161,679) 01-12-2021 07:17
http://oldforge.etsi.org/mantis/file_download.php?file_id=4066&type=bug
docx CR0008031+32_Core-Language-without-CR7910-r2.docx (164,251) 01-12-2021 07:38
http://oldforge.etsi.org/mantis/file_download.php?file_id=4067&type=bug
Issue History
Date ModifiedUsernameFieldChange
18-08-2021 13:27Axel RennochNew Issue
06-09-2021 09:12Jens GrabowskiAssigned To => Axel Rennoch
06-09-2021 09:12Jens GrabowskiStatusnew => assigned
10-11-2021 14:41Axel RennochRelationship addedrelated to 0008031
11-11-2021 12:16Axel RennochFile Added: CR0008031+32_Core-Language-without-CR7910.docx
11-11-2021 12:22Axel RennochNote Added: 0016062
11-11-2021 12:22Axel RennochAssigned ToAxel Rennoch => Jens Grabowski
11-11-2021 12:22Axel RennochStatusassigned => confirmed
30-11-2021 12:15Jens GrabowskiAssigned ToJens Grabowski => Axel Rennoch
30-11-2021 12:15Jens GrabowskiStatusconfirmed => assigned
01-12-2021 07:17Axel RennochFile Added: CR0008031+32_Core-Language-without-CR7910-r1.docx
01-12-2021 07:18Axel RennochRelationship addedrelated to 0007999
01-12-2021 07:18Axel RennochRelationship addedrelated to 0008017
01-12-2021 07:18Axel RennochRelationship addedrelated to 0008007
01-12-2021 07:21Axel RennochNote Added: 0016132
01-12-2021 07:21Axel RennochAssigned ToAxel Rennoch => Jens Grabowski
01-12-2021 07:21Axel RennochStatusassigned => confirmed
01-12-2021 07:38Axel RennochFile Added: CR0008031+32_Core-Language-without-CR7910-r2.docx
01-12-2021 07:39Axel RennochRelationship addedrelated to 0008067
01-12-2021 07:40Axel RennochNote Added: 0016137
02-12-2021 08:56Jens GrabowskiNote Added: 0016143
02-12-2021 08:56Jens GrabowskiStatusconfirmed => closed
02-12-2021 08:56Jens GrabowskiResolutionopen => fixed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0016062) +
+ Axel Rennoch    +
+ 11-11-2021 12:22    +
+ 		+ + + + +
+ The identified issues have been considered in the resolution file.
+
+Since hyperlinks after the transformation to PDF still do not work we may create a html file from the final word document (and publish this at the TTCN-3 homepage).
+
+
+
+ + + + + + + + + + +
+ (0016132) +
+ Axel Rennoch    +
+ 01-12-2021 07:21    +
+ 		+ + + + +
+ BNF changes from CRs 7999, 8007 and 8017 have been implemented in the revised uploaded file CR0008031+32_Core-Language-without-CR7910-r1. This completes the BNF updated for the core notation.
+
+
+
+ + + + + + + + + + +
+ (0016137) +
+ Axel Rennoch    +
+ 01-12-2021 07:40    +
+ 		+ + + + +
+ Final CR0008031+32_Core-Language-without-CR7910-r2 has been added to cover BNF changes from CR 8067, too.
+
+
+
+ + + + + + + + + + +
+ (0016143) +
+ Jens Grabowski    +
+ 02-12-2021 08:56    +
+ 		+ + + + +
+ Implemented
+
+ + diff --git a/docs/mantis/CR8035.md b/docs/mantis/CR8035.md new file mode 100644 index 0000000000000000000000000000000000000000..0affe70f21cafe653b4f4bbced4965c582e739a3 --- /dev/null +++ b/docs/mantis/CR8035.md @@ -0,0 +1,136 @@ + + + + + + + + + + + + + 0008035: Wrong clause reference - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008035Part 01: TTCN-3 Core LanguageEditorialpublic07-09-2021 09:3824-11-2021 08:26
ReporterGusztáv Adamis 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Clause Reference(s)3.1
Source (company - Author)    Gusztáv Adamis Ericsson
Summary0008035: Wrong clause reference
DescriptionWrong clause reference
+
+compatible type: TTCN 3 is not strongly typed but the language does require type compatibility
+NOTE: Variables, constants, templates, etc. have compatible types if conditions in clause 6.2.15 are met.
+
+Shall be clause 3.1
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR8035-211108.docx (71,207) 08-11-2021 16:35
http://oldforge.etsi.org/mantis/file_download.php?file_id=4031&type=bug
Issue History
Date ModifiedUsernameFieldChange
07-09-2021 09:38Gusztáv AdamisNew Issue
09-09-2021 09:29Jens GrabowskiProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
09-09-2021 09:33Jens GrabowskiAssigned To => Jens Grabowski
09-09-2021 09:33Jens GrabowskiStatusnew => assigned
08-11-2021 16:35Jens GrabowskiNote Added: 0016014
08-11-2021 16:35Jens GrabowskiFile Added: CR8035-211108.docx
08-11-2021 16:36Jens GrabowskiAssigned ToJens Grabowski => Gusztáv Adamis
08-11-2021 16:36Jens GrabowskiStatusassigned => confirmed
08-11-2021 17:26Gusztáv AdamisNote Added: 0016022
08-11-2021 17:27Gusztáv AdamisAssigned ToGusztáv Adamis => Jens Grabowski
08-11-2021 17:27Gusztáv AdamisStatusconfirmed => resolved
08-11-2021 17:27Gusztáv AdamisResolutionopen => fixed
24-11-2021 08:26Jens GrabowskiNote Added: 0016101
24-11-2021 08:26Jens GrabowskiStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0016014) +
+ Jens Grabowski    +
+ 08-11-2021 16:35    +
+ 		+ + + + +
+ Gustav please check, I believe section 6.3 has to be referenced and not 3.1.
+
+
+
+ + + + + + + + + + +
+ (0016022) +
+ Gusztáv Adamis    +
+ 08-11-2021 17:26    +
+ 		+ + + + +
+ Yes, that was a copy/paste mistake in CR. 6.3 is the right clause.
+
+
+
+ + + + + + + + + + +
+ (0016101) +
+ Jens Grabowski    +
+ 24-11-2021 08:26    +
+ 		+ + + + +
+ Implemented
+
+ + diff --git a/docs/mantis/CR8036.md b/docs/mantis/CR8036.md new file mode 100644 index 0000000000000000000000000000000000000000..21ab749ac5609dbe6363819389e8627b89087685 --- /dev/null +++ b/docs/mantis/CR8036.md @@ -0,0 +1,136 @@ + + + + + + + + + + + + + 0008036: Definition of "existing TTCN-3 types" missing - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008036Part 01: TTCN-3 Core LanguageClarificationpublic07-09-2021 09:4924-11-2021 08:31
ReporterGusztáv Adamis 
Assigned ToJens Grabowski 
PrioritylowSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Clause Reference(s)6.2.16
Source (company - Author)     Gusztáv Adamis Ericsson
Summary0008036: Definition of "existing TTCN-3 types" missing
DescriptionThe open type is represented by the keyword any. ... Values of all existing TTCN-3 types can be directly passed as actual parameters to formal parameters of the open type without the need to explicitly specify a type context.
+
+Term "existing TTCN-3 types" is never defined.
+
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR8036-1.docx (189,804) 08-11-2021 12:58
http://oldforge.etsi.org/mantis/file_download.php?file_id=4026&type=bug
Issue History
Date ModifiedUsernameFieldChange
07-09-2021 09:49Gusztáv AdamisNew Issue
08-09-2021 11:43Jens GrabowskiAssigned To => Tomas Urban
08-09-2021 11:43Jens GrabowskiStatusnew => assigned
09-09-2021 09:19Jens GrabowskiProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
08-11-2021 12:56Tomas UrbanFile Added: CR8036-1.docx
08-11-2021 12:58Tomas UrbanFile Deleted: CR8036-1.docx
08-11-2021 12:58Tomas UrbanFile Added: CR8036-1.docx
08-11-2021 13:00Tomas UrbanNote Added: 0016003
08-11-2021 13:00Tomas UrbanAssigned ToTomas Urban => Gusztáv Adamis
08-11-2021 13:00Tomas UrbanStatusassigned => confirmed
08-11-2021 15:45Gusztáv AdamisNote Added: 0016010
08-11-2021 15:45Gusztáv AdamisAssigned ToGusztáv Adamis => Jens Grabowski
08-11-2021 15:45Gusztáv AdamisStatusconfirmed => resolved
08-11-2021 15:45Gusztáv AdamisResolutionopen => fixed
24-11-2021 08:31Jens GrabowskiNote Added: 0016102
24-11-2021 08:31Jens GrabowskiStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0016003) +
+ Tomas Urban    +
+ 08-11-2021 13:00    +
+ 		+ + + + +
+ I removed the words "existing TTCN-3" which should hopefully make the text more consistent and in line with the existing definitions. Please check.
+
+
+
+ + + + + + + + + + +
+ (0016010) +
+ Gusztáv Adamis    +
+ 08-11-2021 15:45    +
+ 		+ + + + +
+
+OK, acceptable.
+
+
+
+ + + + + + + + + + +
+ (0016102) +
+ Jens Grabowski    +
+ 24-11-2021 08:31    +
+ 		+ + + + +
+ Implemented
+
+ + diff --git a/docs/mantis/CR8037.md b/docs/mantis/CR8037.md new file mode 100644 index 0000000000000000000000000000000000000000..6a1824e174144d95680d03f3c7ab146d90cbed00 --- /dev/null +++ b/docs/mantis/CR8037.md @@ -0,0 +1,140 @@ + + + + + + + + + + + + + 0008037: Wrong assignment in an example - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008037Part 01: TTCN-3 Core LanguageEditorialpublic07-09-2021 09:5424-11-2021 08:39
ReporterGusztáv Adamis 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Clause Reference(s)6.3.2.2 EXAMPLE 2
Source (company - Author)     Gusztáv Adamis Ericsson
Summary0008037: Wrong assignment in an example
DescriptionEXAMPLE 2:
+    // Given
+    
+    type record of integer IType;
+
+    type record of float HType;
+
+    var HType v_myVarH := { 1, omit, 2};
+
+Since HType is a record of float, the assigned value shall be { 1.0, omit, 2.0 }
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR8037-211108.docx (71,974) 08-11-2021 16:45
http://oldforge.etsi.org/mantis/file_download.php?file_id=4032&type=bug
Issue History
Date ModifiedUsernameFieldChange
07-09-2021 09:54Gusztáv AdamisNew Issue
08-09-2021 11:42Jens GrabowskiAssigned To => Jens Grabowski
08-09-2021 11:42Jens GrabowskiStatusnew => assigned
09-09-2021 09:20Jens GrabowskiProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
08-11-2021 16:45Jens GrabowskiFile Added: CR8037-211108.docx
08-11-2021 16:45Jens GrabowskiNote Added: 0016015
08-11-2021 16:45Jens GrabowskiStatusassigned => confirmed
08-11-2021 16:46Jens GrabowskiNote Added: 0016016
08-11-2021 16:46Jens GrabowskiStatusconfirmed => resolved
08-11-2021 16:46Jens GrabowskiResolutionopen => fixed
24-11-2021 08:39Jens GrabowskiNote Added: 0016103
24-11-2021 08:39Jens GrabowskiStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0016015) +
+ Jens Grabowski    +
+ 08-11-2021 16:45    +
+ 		+ + + + +
+ typo
+
+
+
+ + + + + + + + + + +
+ (0016016) +
+ Jens Grabowski    +
+ 08-11-2021 16:46    +
+ 		+ + + + +
+ typo
+
+
+
+ + + + + + + + + + +
+ (0016103) +
+ Jens Grabowski    +
+ 24-11-2021 08:39    +
+ 		+ + + + +
+ Implemented
+
+ + diff --git a/docs/mantis/CR8038.md b/docs/mantis/CR8038.md new file mode 100644 index 0000000000000000000000000000000000000000..a770d0544bb7f9c871adbfeae46172cfccc7731b --- /dev/null +++ b/docs/mantis/CR8038.md @@ -0,0 +1,175 @@ + + + + + + + + + + + + + 0008038: Explanation in an example - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008038Part 01: TTCN-3 Core LanguageClarificationpublic07-09-2021 09:5924-11-2021 08:48
ReporterGusztáv Adamis 
Assigned ToJens Grabowski 
PrioritylowSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Clause Reference(s)6.3.2.4. EXAMPLE 2
Source (company - Author)     Gusztáv Adamis Ericsson
Summary0008038: Explanation in an example
Description    v_u2 := v_u1.i; // incorrect
+    v_u3 := v_u1.i; // correct
+
+I would have some explanation why they are incorrect/correct, as in the other lines in this example
+
+    v_int := v_u4 *2; // incorrect as v_u4 is treated as a boolean, and cannot be multiplied
+    v_int := v_u32 *2; // test case error as "v_u32" would be treated as v_u32.i,
+                            // which is not the selected alternative
+
+The comment of the examples should be the same (incorrect OR t.c. error in all lines.
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR8038.docx (170,610) 09-11-2021 14:05
http://oldforge.etsi.org/mantis/file_download.php?file_id=4041&type=bug
Issue History
Date ModifiedUsernameFieldChange
07-09-2021 09:59Gusztáv AdamisNew Issue
08-09-2021 11:41Jens GrabowskiAssigned To => Jens Grabowski
08-09-2021 11:41Jens GrabowskiStatusnew => assigned
09-09-2021 09:20Jens GrabowskiProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
09-11-2021 09:38Jens GrabowskiAssigned ToJens Grabowski => Jacob Wieland - Spirent
09-11-2021 09:38Jens GrabowskiNote Added: 0016037
09-11-2021 14:05Jacob Wieland - SpirentFile Added: CR8038.docx
09-11-2021 14:05Jacob Wieland - SpirentNote Added: 0016039
09-11-2021 14:05Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gusztáv Adamis
09-11-2021 14:05Jacob Wieland - SpirentStatusassigned => confirmed
09-11-2021 15:31Gusztáv AdamisNote Added: 0016041
09-11-2021 15:32Gusztáv AdamisAssigned ToGusztáv Adamis => Jens Grabowski
09-11-2021 15:32Gusztáv AdamisStatusconfirmed => resolved
09-11-2021 15:32Gusztáv AdamisResolutionopen => fixed
24-11-2021 08:48Jens GrabowskiNote Added: 0016104
24-11-2021 08:48Jens GrabowskiStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0016037) +
+ Jens Grabowski    +
+ 09-11-2021 09:38    +
+ 		+ + + + +
+ Jacob, can you add the comments.
+
+
+
+ + + + + + + + + + +
+ (0016039) +
+ Jacob Wieland - Spirent    +
+ 09-11-2021 14:05    +
+ 		+ + + + +
+ please review and resolve if acceptable
+
+
+
+ + + + + + + + + + +
+ (0016041) +
+ Gusztáv Adamis    +
+ 09-11-2021 15:31    +
+ 		+ + + + +
+ Reviewed and the changes are accepted
+
+
+
+ + + + + + + + + + +
+ (0016104) +
+ Jens Grabowski    +
+ 24-11-2021 08:48    +
+ 		+ + + + +
+ Implemented
+
+ + diff --git a/docs/mantis/CR8039.md b/docs/mantis/CR8039.md new file mode 100644 index 0000000000000000000000000000000000000000..b6eec122dac3f9ef033bf7567c4dcadbc4f8e3fb --- /dev/null +++ b/docs/mantis/CR8039.md @@ -0,0 +1,103 @@ + + + + + + + + + + + + + 0008039: Declarations too far - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008039Part 01: TTCN-3 Core LanguageEditorialpublic07-09-2021 10:2224-11-2021 08:52
ReporterGusztáv Adamis 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Clause Reference(s)6.3.2.6 EXAMPLE
Source (company - Author)     Gusztáv Adamis Ericsson
Summary0008039: Declarations too far
DescriptionIn EXAMPLE
+
+    // If considering the declarations above, then
+
+Since the declarations are pages and several clauses before, I would explicitly reference them
+
+    // If considering the declarations 6.3.2.2. EXAMPLE 1 above, then
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR8039-211109.docx (69,346) 09-11-2021 09:27
http://oldforge.etsi.org/mantis/file_download.php?file_id=4040&type=bug
Issue History
Date ModifiedUsernameFieldChange
07-09-2021 10:22Gusztáv AdamisNew Issue
08-09-2021 11:40Jens GrabowskiAssigned To => Jens Grabowski
08-09-2021 11:40Jens GrabowskiStatusnew => assigned
09-09-2021 09:31Jens GrabowskiProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
09-11-2021 09:27Jens GrabowskiFile Added: CR8039-211109.docx
09-11-2021 09:29Jens GrabowskiNote Added: 0016036
09-11-2021 09:29Jens GrabowskiStatusassigned => resolved
09-11-2021 09:29Jens GrabowskiResolutionopen => fixed
24-11-2021 08:52Jens GrabowskiNote Added: 0016105
24-11-2021 08:52Jens GrabowskiStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0016036) +
+ Jens Grabowski    +
+ 09-11-2021 09:29    +
+ 		+ + + + +
+ Trivial addition
+
+
+
+ + + + + + + + + + +
+ (0016105) +
+ Jens Grabowski    +
+ 24-11-2021 08:52    +
+ 		+ + + + +
+ Implemented
+
+ + diff --git a/docs/mantis/CR8040.md b/docs/mantis/CR8040.md new file mode 100644 index 0000000000000000000000000000000000000000..672e3c2f828331aed67487ebed0e67a116c998f8 --- /dev/null +++ b/docs/mantis/CR8040.md @@ -0,0 +1,347 @@ + + + + + + + + + + + + + 0008040: => operator is missing from List of TTCN-3 operators and Precedence of Operators tables - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008040Part 01: TTCN-3 Core LanguageClarificationpublic07-09-2021 10:3024-11-2021 09:17
ReporterGusztáv Adamis 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Clause Reference(s)7.1.0 and 7.3
Source (company - Author)     Gusztáv Adamis Ericsson
Summary0008040: => operator is missing from List of TTCN-3 operators and Precedence of Operators tables
DescriptionIn 7.3 "he string value preceding the => operator shall be decoded into a value of the type following the => operator."
+
+
+But => operator is missing from List of TTCN-3 operators (7.1.0 Table 5) and Precedence of Operators (7.1.0 Table 6) tables
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR0008040.docx (175,404) 10-11-2021 15:51
http://oldforge.etsi.org/mantis/file_download.php?file_id=4050&type=bug
docx CR0008040-2.docx (176,015) 11-11-2021 15:23
http://oldforge.etsi.org/mantis/file_download.php?file_id=4057&type=bug
docx CR0008040-3.docx (175,660) 11-11-2021 15:31
http://oldforge.etsi.org/mantis/file_download.php?file_id=4058&type=bug
Issue History
Date ModifiedUsernameFieldChange
07-09-2021 10:30Gusztáv AdamisNew Issue
07-09-2021 14:42Jacob Wieland - SpirentNote Added: 0015949
08-09-2021 11:39Jens GrabowskiAssigned To => Jens Grabowski
08-09-2021 11:39Jens GrabowskiStatusnew => assigned
09-09-2021 09:31Jens GrabowskiProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
09-11-2021 09:18Jens GrabowskiNote Added: 0016035
09-11-2021 09:18Jens GrabowskiAssigned ToJens Grabowski => Jacob Wieland - Spirent
09-11-2021 12:38Jacob Wieland - SpirentNote Added: 0016038
09-11-2021 12:47Jacob Wieland - SpirentNote Edited: 0016038bug_revision_view_page.php?bugnote_id=16038#r566
10-11-2021 12:57Jens GrabowskiNote Added: 0016053
10-11-2021 12:58Jens GrabowskiAssigned ToJacob Wieland - Spirent => Gusztáv Adamis
10-11-2021 15:51Gusztáv AdamisFile Added: CR0008040.docx
10-11-2021 15:56Gusztáv AdamisNote Added: 0016058
10-11-2021 15:56Gusztáv AdamisAssigned ToGusztáv Adamis => Jacob Wieland - Spirent
10-11-2021 15:56Gusztáv AdamisStatusassigned => confirmed
11-11-2021 15:23Jacob Wieland - SpirentFile Added: CR0008040-2.docx
11-11-2021 15:24Jacob Wieland - SpirentStatusconfirmed => assigned
11-11-2021 15:25Jacob Wieland - SpirentNote Added: 0016069
11-11-2021 15:25Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Tomas Urban
11-11-2021 15:25Jacob Wieland - SpirentStatusassigned => confirmed
11-11-2021 15:31Gusztáv AdamisFile Added: CR0008040-3.docx
11-11-2021 15:35Gusztáv AdamisNote Added: 0016070
12-11-2021 08:44Tomas UrbanNote Added: 0016071
12-11-2021 08:44Tomas UrbanStatusconfirmed => resolved
12-11-2021 08:44Tomas UrbanResolutionopen => fixed
12-11-2021 08:44Tomas UrbanAssigned ToTomas Urban => Jens Grabowski
24-11-2021 09:17Jens GrabowskiNote Added: 0016106
24-11-2021 09:17Jens GrabowskiStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015949) +
+ Jacob Wieland - Spirent    +
+ 07-09-2021 14:42    +
+ 		+ + + + +
+ It is supposed to be of equal precedence with the '.' (Dot) operator.
+
+
+
+ + + + + + + + + + +
+ (0016035) +
+ Jens Grabowski    +
+ 09-11-2021 09:18    +
+ 		+ + + + +
+ Sorry, but the tables do not include a Dot operator. Please have a look. Might be easier to resolve the CR directly.
+
+
+
+ + + + + + + + + + +
+ (0016038) +
+ Jacob Wieland - Spirent    +
+ 09-11-2021 12:38    +
(edited on: 09-11-2021 12:47)
+ 		+ + + + +
+ Well, the problem is that the dot operator is not really an operator in the classical sense between two expressions (it has an expression on the left and an identifier/selector on the right). It is on the same precedence level as the indexing notation and the decoding operation, all of them are left-associative to each other.
+(This can be seen in the BNF in the rule for ExtendedFieldReference)
+
+a.b[x].d=>e.f == ((((a.b)[x]).d)=>e).f
+
+So, I would propose to introduce a sort of meta-line as 2nd highest precedence in the precedence table where all these postfix-notations are listed (selection, indexing, decoding)
+
+
+
+
+
+ + + + + + + + + + +
+ (0016053) +
+ Jens Grabowski    +
+ 10-11-2021 12:57    +
+ 		+ + + + +
+ STF discussion: Rename "=>" operator to "=>" notation, e.g., decoding notation and possibly add a note about left associativity of Dot notation, Index notation and Decoding notation.
+
+
+
+ + + + + + + + + + +
+ (0016058) +
+ Gusztáv Adamis    +
+ 10-11-2021 15:56    +
+ 		+ + + + +
+ @Jacob pls check it, and if ok, forward it to @Jens
+
+
+
+ + + + + + + + + + +
+ (0016069) +
+ Jacob Wieland - Spirent    +
+ 11-11-2021 15:25    +
+ 		+ + + + +
+ Added some changes (mostly removal of the words operand for the decoding notation to not implicitly make this into an operator). Please review
+
+
+
+ + + + + + + + + + +
+ (0016070) +
+ Gusztáv Adamis    +
+ 11-11-2021 15:35    +
+ 		+ + + + +
+ Just one thing: from the NOTE I have removed the == in front of the 'is equivalent to' that @Jacob added.
+
+If you accept it, can be closed and sent to @Jens
+
+
+
+ + + + + + + + + + +
+ (0016071) +
+ Tomas Urban    +
+ 12-11-2021 08:44    +
+ 		+ + + + +
+ Fine by me. The last draft (CR0008040-3.docx) can be added to the core language specification.
+
+
+
+ + + + + + + + + + +
+ (0016106) +
+ Jens Grabowski    +
+ 24-11-2021 09:17    +
+ 		+ + + + +
+ Implemented
+
+ + diff --git a/docs/mantis/CR8041.md b/docs/mantis/CR8041.md new file mode 100644 index 0000000000000000000000000000000000000000..f43622a042adf76080da30ce95687a9cd40e388e --- /dev/null +++ b/docs/mantis/CR8041.md @@ -0,0 +1,99 @@ + + + + + + + + + + + + + 0008041: Typos in 15.12 - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008041Part 01: TTCN-3 Core LanguageEditorialpublic07-09-2021 10:3406-12-2021 09:46
ReporterGusztáv Adamis 
Assigned ToJens Grabowski 
PrioritylowSeveritytrivialReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Clause Reference(s)15.12
Source (company - Author)     Gusztáv Adamis Ericsson
Summary0008041: Typos in 15.12
DescriptionIn first sentence: operatoion => operation
+
+In EXAMPLE last but 3rd line : template(omit) ExampleType m_targetOmit := omit(m_riginalOmit); => m_originalOmit (o is missing)
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR8041-211108.docx (70,064) 08-11-2021 16:22
http://oldforge.etsi.org/mantis/file_download.php?file_id=4030&type=bug
docx CR8041-v2-211206.docx (70,322) 06-12-2021 09:46
http://oldforge.etsi.org/mantis/file_download.php?file_id=4068&type=bug
Issue History
Date ModifiedUsernameFieldChange
07-09-2021 10:34Gusztáv AdamisNew Issue
07-09-2021 10:36Gusztáv AdamisSummaryTypo in 15.12 => Typos in 15.12
07-09-2021 10:36Gusztáv AdamisDescription Updatedbug_revision_view_page.php?rev_id=557#r557
09-09-2021 09:29Jens GrabowskiProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
09-09-2021 09:32Jens GrabowskiAssigned To => Jens Grabowski
09-09-2021 09:32Jens GrabowskiStatusnew => assigned
08-11-2021 16:22Jens GrabowskiFile Added: CR8041-211108.docx
08-11-2021 16:22Jens GrabowskiNote Added: 0016013
08-11-2021 16:22Jens GrabowskiStatusassigned => resolved
08-11-2021 16:22Jens GrabowskiResolutionopen => fixed
24-11-2021 09:22Jens GrabowskiNote Added: 0016107
24-11-2021 09:22Jens GrabowskiStatusresolved => closed
06-12-2021 09:46Jens GrabowskiFile Added: CR8041-v2-211206.docx
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0016013) +
+ Jens Grabowski    +
+ 08-11-2021 16:22    +
+ 		+ + + + +
+ Typo
+
+
+
+ + + + + + + + + + +
+ (0016107) +
+ Jens Grabowski    +
+ 24-11-2021 09:22    +
+ 		+ + + + +
+ Implemented
+
+ + diff --git a/docs/mantis/CR8042.md b/docs/mantis/CR8042.md new file mode 100644 index 0000000000000000000000000000000000000000..3711a28ff2d719d67875f434fffbf25d38f22402 --- /dev/null +++ b/docs/mantis/CR8042.md @@ -0,0 +1,101 @@ + + + + + + + + + + + + + 0008042: Wrong reference in 16.1.3 - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008042Part 01: TTCN-3 Core LanguageEditorialpublic07-09-2021 15:4124-11-2021 15:18
ReporterGusztáv Adamis 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Clause Reference(s)16.1.3
Source (company - Author)     Gusztáv Adamis Ericsson
Summary0008042: Wrong reference in 16.1.3
DescriptionThe @control modifier is used in the same way as described in the clause 16.1.0.
+
+16.1.0 does not mention @control.
+
+16.1.5 should be the referred clause
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR8042-211108.docx (70,365) 08-11-2021 16:59
http://oldforge.etsi.org/mantis/file_download.php?file_id=4035&type=bug
Issue History
Date ModifiedUsernameFieldChange
07-09-2021 15:41Gusztáv AdamisNew Issue
09-09-2021 09:29Jens GrabowskiProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
09-09-2021 09:32Jens GrabowskiAssigned To => Jens Grabowski
09-09-2021 09:32Jens GrabowskiStatusnew => assigned
08-11-2021 16:59Jens GrabowskiFile Added: CR8042-211108.docx
08-11-2021 16:59Jens GrabowskiNote Added: 0016019
08-11-2021 16:59Jens GrabowskiStatusassigned => resolved
08-11-2021 16:59Jens GrabowskiResolutionopen => fixed
24-11-2021 15:18Jens GrabowskiNote Added: 0016112
24-11-2021 15:18Jens GrabowskiStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0016019) +
+ Jens Grabowski    +
+ 08-11-2021 16:59    +
+ 		+ + + + +
+ Typo
+
+
+
+ + + + + + + + + + +
+ (0016112) +
+ Jens Grabowski    +
+ 24-11-2021 15:18    +
+ 		+ + + + +
+ Implemented
+
+ + diff --git a/docs/mantis/CR8043.md b/docs/mantis/CR8043.md new file mode 100644 index 0000000000000000000000000000000000000000..4ffcc170b50c9005d884ed02a82b1e4381f2771c --- /dev/null +++ b/docs/mantis/CR8043.md @@ -0,0 +1,97 @@ + + + + + + + + + + + + + 0008043: typo in 20.2 - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008043Part 01: TTCN-3 Core LanguageEditorialpublic07-09-2021 15:4724-11-2021 15:22
ReporterGusztáv Adamis 
Assigned ToJens Grabowski 
PrioritylowSeveritytrivialReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Clause Reference(s)20.2
Source (company - Author)     Gusztáv Adamis Ericsson
Summary0008043: typo in 20.2
DescriptionAn altstep-branche => An altstep-branch
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR8043-211108.docx (77,663) 08-11-2021 17:05
http://oldforge.etsi.org/mantis/file_download.php?file_id=4036&type=bug
Issue History
Date ModifiedUsernameFieldChange
07-09-2021 15:47Gusztáv AdamisNew Issue
09-09-2021 09:29Jens GrabowskiProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
09-09-2021 09:32Jens GrabowskiAssigned To => Jens Grabowski
09-09-2021 09:32Jens GrabowskiStatusnew => assigned
08-11-2021 17:05Jens GrabowskiFile Added: CR8043-211108.docx
08-11-2021 17:05Jens GrabowskiNote Added: 0016020
08-11-2021 17:05Jens GrabowskiStatusassigned => resolved
08-11-2021 17:05Jens GrabowskiResolutionopen => fixed
24-11-2021 15:22Jens GrabowskiNote Added: 0016113
24-11-2021 15:22Jens GrabowskiStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0016020) +
+ Jens Grabowski    +
+ 08-11-2021 17:05    +
+ 		+ + + + +
+ Typo
+
+
+
+ + + + + + + + + + +
+ (0016113) +
+ Jens Grabowski    +
+ 24-11-2021 15:22    +
+ 		+ + + + +
+ implemented
+
+ + diff --git a/docs/mantis/CR8044.md b/docs/mantis/CR8044.md new file mode 100644 index 0000000000000000000000000000000000000000..c528b1fd2e9cedaae5cc65b8eb77999e29c10496 --- /dev/null +++ b/docs/mantis/CR8044.md @@ -0,0 +1,133 @@ + + + + + + + + + + + + + 0008044: Component creation - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008044Part 01: TTCN-3 Core LanguageClarificationpublic07-09-2021 15:5124-11-2021 15:23
ReporterGusztáv Adamis 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Clause Reference(s)21.3.1
Source (company - Author)     Gusztáv Adamis Ericsson
Summary0008044: Component creation
DescriptionComponents can be created at any point in a behaviour definition providing full flexibility with regard to dynamic configurations (i.e. any component can create any other parallel component).
+
+The explanation in parentheses is not correct, a test component cannot creater control component and vice versa.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
07-09-2021 15:51Gusztáv AdamisNew Issue
08-09-2021 11:38Jens GrabowskiAssigned To => Jens Grabowski
08-09-2021 11:38Jens GrabowskiStatusnew => assigned
09-09-2021 09:31Jens GrabowskiProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
09-11-2021 08:57Jens GrabowskiNote Added: 0016032
09-11-2021 08:58Jens GrabowskiNote Added: 0016033
09-11-2021 08:58Jens GrabowskiStatusassigned => resolved
09-11-2021 08:58Jens GrabowskiResolutionopen => fixed
24-11-2021 15:23Jens GrabowskiNote Added: 0016114
24-11-2021 15:23Jens GrabowskiStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0016032) +
+ Jens Grabowski    +
+ 09-11-2021 08:57    +
+ 		+ + + + +
+ Follow up to CR 7910. Disappeared due to resolution/removal of changes related to CR 7910.
+
+
+
+ + + + + + + + + + +
+ (0016033) +
+ Jens Grabowski    +
+ 09-11-2021 08:58    +
+ 		+ + + + +
+ Follow up to CR 7910. Disappeared due to resolution/removal of changes related to CR 7910.
+
+
+
+ + + + + + + + + + +
+ (0016114) +
+ Jens Grabowski    +
+ 24-11-2021 15:23    +
+ 		+ + + + +
+ See comment on CR 7910
+
+ + diff --git a/docs/mantis/CR8045.md b/docs/mantis/CR8045.md new file mode 100644 index 0000000000000000000000000000000000000000..bc57c995b956ee0c4931c4fd3314a1dc56dabac2 --- /dev/null +++ b/docs/mantis/CR8045.md @@ -0,0 +1,136 @@ + + + + + + + + + + + + + 0008045: Start component operation can also be applied on control components - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008045Part 01: TTCN-3 Core LanguageClarificationpublic07-09-2021 15:5624-11-2021 15:25
ReporterGusztáv Adamis 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Clause Reference(s)21.3.2
Source (company - Author)     Gusztáv Adamis Ericsson
Summary0008045: Start component operation can also be applied on control components
DescriptionThe start operation is used to associate a test behaviour to a test component, which is then being executed by that test component.
+
+test behaviour => behaviour
+test component => component except for MTC and MCC / or parallel component
+
+Throughout the Semantic Description component shall be replaced by parallel component
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
07-09-2021 15:56Gusztáv AdamisNew Issue
08-09-2021 11:38Jens GrabowskiAssigned To => Jens Grabowski
08-09-2021 11:38Jens GrabowskiStatusnew => assigned
09-09-2021 09:31Jens GrabowskiProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
09-11-2021 08:51Jens GrabowskiNote Added: 0016028
09-11-2021 08:52Jens GrabowskiNote Added: 0016029
09-11-2021 08:52Jens GrabowskiStatusassigned => resolved
09-11-2021 08:52Jens GrabowskiResolutionopen => fixed
24-11-2021 15:25Jens GrabowskiNote Added: 0016115
24-11-2021 15:25Jens GrabowskiStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0016028) +
+ Jens Grabowski    +
+ 09-11-2021 08:51    +
+ 		+ + + + +
+ Follow up to CR 7910. Disappeared due to resolution/removal of changes related to CR 7910.
+
+
+
+ + + + + + + + + + +
+ (0016029) +
+ Jens Grabowski    +
+ 09-11-2021 08:52    +
+ 		+ + + + +
+ Follow up to CR 7910. Disappeared due to resolution/removal of changes related to CR 7910.
+
+
+
+ + + + + + + + + + +
+ (0016115) +
+ Jens Grabowski    +
+ 24-11-2021 15:25    +
+ 		+ + + + +
+ See comment regarding CR 7910.
+
+ + diff --git a/docs/mantis/CR8046.md b/docs/mantis/CR8046.md new file mode 100644 index 0000000000000000000000000000000000000000..f00b7251c8a950cbaeceab2190b3368f9f5085b5 --- /dev/null +++ b/docs/mantis/CR8046.md @@ -0,0 +1,133 @@ + + + + + + + + + + + + + 0008046: master control component - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008046Part 01: TTCN-3 Core LanguageEditorialpublic07-09-2021 15:5824-11-2021 15:28
ReporterGusztáv Adamis 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Clause Reference(s)21.3.3
Source (company - Author)     Gusztáv Adamis Ericsson
Summary0008046: master control component
DescriptionThe all keyword can be used by the MTC only in order to stop all running PTCs but the MTC itself. The all component construct can also be used by the master control component to stop all running parallel control components but itself.
+
+master => main
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
07-09-2021 15:58Gusztáv AdamisNew Issue
08-09-2021 11:37Jens GrabowskiAssigned To => Jens Grabowski
08-09-2021 11:37Jens GrabowskiStatusnew => assigned
09-09-2021 09:31Jens GrabowskiProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
09-11-2021 08:48Jens GrabowskiNote Added: 0016026
09-11-2021 08:49Jens GrabowskiNote Added: 0016027
09-11-2021 08:49Jens GrabowskiStatusassigned => resolved
09-11-2021 08:49Jens GrabowskiResolutionopen => fixed
24-11-2021 15:28Jens GrabowskiNote Added: 0016116
24-11-2021 15:28Jens GrabowskiStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0016026) +
+ Jens Grabowski    +
+ 09-11-2021 08:48    +
+ 		+ + + + +
+ Issue disappeared due to CR 7910.
+
+
+
+ + + + + + + + + + +
+ (0016027) +
+ Jens Grabowski    +
+ 09-11-2021 08:49    +
+ 		+ + + + +
+ Follow up to CR 7910. Disappeared due to resolution/removal of changes related to CR 7910.
+
+
+
+ + + + + + + + + + +
+ (0016116) +
+ Jens Grabowski    +
+ 24-11-2021 15:28    +
+ 		+ + + + +
+ See comment regarding CR 7910.
+
+ + diff --git a/docs/mantis/CR8047.md b/docs/mantis/CR8047.md new file mode 100644 index 0000000000000000000000000000000000000000..3659aadb37b8a245a776248fab6b3524e11d0a6e --- /dev/null +++ b/docs/mantis/CR8047.md @@ -0,0 +1,133 @@ + + + + + + + + + + + + + 0008047: Clarification in Kill component operation - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008047Part 01: TTCN-3 Core LanguageClarificationpublic07-09-2021 16:0424-11-2021 15:29
ReporterGusztáv Adamis 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Clause Reference(s)21.3.4
Source (company - Author)     Gusztáv Adamis Ericsson
Summary0008047: Clarification in Kill component operation
DescriptionThis text should be re-worded, since not only MTC can use the all, as it is stated in the first sentence: The all keyword can be used by the MTC only in order to stop and kill all running PTCs but the MTC itself. The all component construct can also be used by the main control component to stop and kill all running parallel control components but itself.
+
+Similar notes as NOTE 2 & 3 of 21.3.3 Stop component operation clause shall be added.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
07-09-2021 16:04Gusztáv AdamisNew Issue
08-09-2021 11:36Jens GrabowskiAssigned To => Jens Grabowski
08-09-2021 11:36Jens GrabowskiStatusnew => assigned
09-09-2021 09:31Jens GrabowskiProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
09-11-2021 08:55Jens GrabowskiNote Added: 0016030
09-11-2021 08:55Jens GrabowskiNote Added: 0016031
09-11-2021 08:55Jens GrabowskiStatusassigned => resolved
09-11-2021 08:55Jens GrabowskiResolutionopen => fixed
24-11-2021 15:29Jens GrabowskiNote Added: 0016117
24-11-2021 15:29Jens GrabowskiStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0016030) +
+ Jens Grabowski    +
+ 09-11-2021 08:55    +
+ 		+ + + + +
+ Follow up to CR 7910. Disappeared due to resolution/removal of changes related to CR 7910.
+
+
+
+ + + + + + + + + + +
+ (0016031) +
+ Jens Grabowski    +
+ 09-11-2021 08:55    +
+ 		+ + + + +
+ Follow up to CR 7910. Disappeared due to resolution/removal of changes related to CR 7910.
+
+
+
+ + + + + + + + + + +
+ (0016117) +
+ Jens Grabowski    +
+ 24-11-2021 15:29    +
+ 		+ + + + +
+ See comment regarding CR 7910.
+
+ + diff --git a/docs/mantis/CR8048.md b/docs/mantis/CR8048.md new file mode 100644 index 0000000000000000000000000000000000000000..c187a70c36fb9e4bad532e24207224cc01915e68 --- /dev/null +++ b/docs/mantis/CR8048.md @@ -0,0 +1,101 @@ + + + + + + + + + + + + + 0008048: Keywords shall be bold - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008048Part 01: TTCN-3 Core LanguageEditorialpublic07-09-2021 16:0824-11-2021 15:37
ReporterGusztáv Adamis 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Clause Reference(s)21.3.10
Source (company - Author)     Gusztáv Adamis Ericsson
Summary0008048: Keywords shall be bold
DescriptionIn the last but one example value and verdict shall be typed in bold, since they are keywords
+
+v_myAlivePTC.call(f_myThirdBehaviour(v_out,v_inout)) // v_out/v_inout can be changed
+-> value v_result verdict v_verdict;
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR8048-211109.docx (72,343) 09-11-2021 08:30
http://oldforge.etsi.org/mantis/file_download.php?file_id=4037&type=bug
Issue History
Date ModifiedUsernameFieldChange
07-09-2021 16:08Gusztáv AdamisNew Issue
09-09-2021 09:29Jens GrabowskiProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
09-09-2021 09:32Jens GrabowskiAssigned To => Jens Grabowski
09-09-2021 09:32Jens GrabowskiStatusnew => assigned
09-11-2021 08:30Jens GrabowskiFile Added: CR8048-211109.docx
09-11-2021 08:30Jens GrabowskiNote Added: 0016024
09-11-2021 08:30Jens GrabowskiStatusassigned => resolved
09-11-2021 08:30Jens GrabowskiResolutionopen => fixed
24-11-2021 15:37Jens GrabowskiNote Added: 0016118
24-11-2021 15:37Jens GrabowskiStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0016024) +
+ Jens Grabowski    +
+ 09-11-2021 08:30    +
+ 		+ + + + +
+ typo
+
+
+
+ + + + + + + + + + +
+ (0016118) +
+ Jens Grabowski    +
+ 24-11-2021 15:37    +
+ 		+ + + + +
+ implemented
+
+ + diff --git a/docs/mantis/CR8049.md b/docs/mantis/CR8049.md new file mode 100644 index 0000000000000000000000000000000000000000..66e270a3c4a564226567f146d83ba68400675746 --- /dev/null +++ b/docs/mantis/CR8049.md @@ -0,0 +1,138 @@ + + + + + + + + + + + + + 0008049: Value part in receiving operators - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008049Part 01: TTCN-3 Core LanguageEditorialpublic07-09-2021 16:1324-11-2021 15:47
ReporterGusztáv Adamis 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Clause Reference(s)22.1.4.2
Source (company - Author)     Gusztáv Adamis Ericsson
Summary0008049: Value part in receiving operators
DescriptionA receiving operation consists of a receive part and an (optional) assignment part.
+The receive part:
+a) specifies the port at which the operation shall take place;
+b) defines a matching part which specifies the acceptable input which will match the statement;
+c) gives an (optional) address expression that uniquely identifies the communication partner (in case of one-to-many connections).
+The port name, operation name and value part of all receiving operations shall be present.
+
+The points a)-c) do not specify a value part, so in the last sentence it should be changed to matching part
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR8049.docx (171,925) 09-09-2021 12:08
http://oldforge.etsi.org/mantis/file_download.php?file_id=4011&type=bug
Issue History
Date ModifiedUsernameFieldChange
07-09-2021 16:13Gusztáv AdamisNew Issue
08-09-2021 11:31Jens GrabowskiAssigned To => Jacob Wieland - Spirent
08-09-2021 11:31Jens GrabowskiStatusnew => assigned
09-09-2021 09:31Jens GrabowskiProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
09-09-2021 12:08Jacob Wieland - SpirentFile Added: CR8049.docx
09-09-2021 12:09Jacob Wieland - SpirentNote Added: 0015967
09-09-2021 12:09Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gusztáv Adamis
09-09-2021 12:09Jacob Wieland - SpirentStatusassigned => confirmed
10-09-2021 13:25Gusztáv AdamisNote Added: 0015978
10-09-2021 13:25Gusztáv AdamisStatusconfirmed => resolved
11-09-2021 00:25Gusztáv AdamisStatusresolved => feedback
11-09-2021 00:25Gusztáv AdamisResolutionopen => reopened
11-09-2021 00:26Gusztáv AdamisAssigned ToGusztáv Adamis => Jens Grabowski
11-09-2021 00:26Gusztáv AdamisStatusfeedback => resolved
11-09-2021 00:26Gusztáv AdamisResolutionreopened => fixed
24-11-2021 15:47Jens GrabowskiNote Added: 0016119
24-11-2021 15:47Jens GrabowskiStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015967) +
+ Jacob Wieland - Spirent    +
+ 09-09-2021 12:09    +
+ 		+ + + + +
+ please review the uploaded proposal
+
+
+
+ + + + + + + + + + +
+ (0015978) +
+ Gusztáv Adamis    +
+ 10-09-2021 13:25    +
+ 		+ + + + +
+ Agree with the proposal
+
+
+
+ + + + + + + + + + +
+ (0016119) +
+ Jens Grabowski    +
+ 24-11-2021 15:47    +
+ 		+ + + + +
+ implemented
+
+ + diff --git a/docs/mantis/CR8050.md b/docs/mantis/CR8050.md new file mode 100644 index 0000000000000000000000000000000000000000..76159952bfefff7214996c6274efc25435b1c548 --- /dev/null +++ b/docs/mantis/CR8050.md @@ -0,0 +1,97 @@ + + + + + + + + + + + + + 0008050: Typo in 23.1 - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008050Part 01: TTCN-3 Core LanguageEditorialpublic07-09-2021 16:1529-11-2021 09:34
ReporterGusztáv Adamis 
Assigned ToJens Grabowski 
PrioritynormalSeveritytrivialReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Clause Reference(s)23.1
Source (company - Author)     Gusztáv Adamis Ericsson
Summary0008050: Typo in 23.1
Descriptiontimeout-list of a are updated => timeout-list are updated
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR8050-211108.docx (69,867) 08-11-2021 16:51
http://oldforge.etsi.org/mantis/file_download.php?file_id=4033&type=bug
Issue History
Date ModifiedUsernameFieldChange
07-09-2021 16:15Gusztáv AdamisNew Issue
09-09-2021 09:29Jens GrabowskiProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
09-09-2021 09:31Jens GrabowskiAssigned To => Jens Grabowski
09-09-2021 09:31Jens GrabowskiStatusnew => assigned
08-11-2021 16:51Jens GrabowskiFile Added: CR8050-211108.docx
08-11-2021 16:51Jens GrabowskiNote Added: 0016017
08-11-2021 16:51Jens GrabowskiStatusassigned => resolved
08-11-2021 16:51Jens GrabowskiResolutionopen => fixed
29-11-2021 09:34Jens GrabowskiNote Added: 0016120
29-11-2021 09:34Jens GrabowskiStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0016017) +
+ Jens Grabowski    +
+ 08-11-2021 16:51    +
+ 		+ + + + +
+ typo
+
+
+
+ + + + + + + + + + +
+ (0016120) +
+ Jens Grabowski    +
+ 29-11-2021 09:34    +
+ 		+ + + + +
+ Implemented
+
+ + diff --git a/docs/mantis/CR8051.md b/docs/mantis/CR8051.md new file mode 100644 index 0000000000000000000000000000000000000000..9b6f066cb014859a392a981686899b8aa2ad1de6 --- /dev/null +++ b/docs/mantis/CR8051.md @@ -0,0 +1,100 @@ + + + + + + + + + + + + + 0008051: Typo in 26.2 - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008051Part 01: TTCN-3 Core LanguageEditorialpublic07-09-2021 16:1729-11-2021 09:48
ReporterGusztáv Adamis 
Assigned ToJens Grabowski 
PrioritynormalSeveritytrivialReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Clause Reference(s)26.2
Source (company - Author)     Gusztáv Adamis Ericsson
Summary0008051: Typo in 26.2
DescriptionExecution and control component
+The module control function is an entry point for execution of a TTCN-3 test suite. If the function contains formal parameters, their actual values shall be provided. When the control function is started, the TE creates a test component called control component. The component contains variables, constants, templates and times
+
+times => timers
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR8051-211109.docx (72,179) 09-11-2021 08:34
http://oldforge.etsi.org/mantis/file_download.php?file_id=4038&type=bug
Issue History
Date ModifiedUsernameFieldChange
07-09-2021 16:17Gusztáv AdamisNew Issue
09-09-2021 09:29Jens GrabowskiProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
09-09-2021 09:31Jens GrabowskiAssigned To => Jens Grabowski
09-09-2021 09:31Jens GrabowskiStatusnew => assigned
09-11-2021 08:34Jens GrabowskiFile Added: CR8051-211109.docx
09-11-2021 08:35Jens GrabowskiNote Added: 0016025
09-11-2021 08:35Jens GrabowskiStatusassigned => resolved
09-11-2021 08:35Jens GrabowskiResolutionopen => fixed
29-11-2021 09:48Jens GrabowskiNote Added: 0016121
29-11-2021 09:48Jens GrabowskiStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0016025) +
+ Jens Grabowski    +
+ 09-11-2021 08:35    +
+ 		+ + + + +
+ Typo
+
+
+
+ + + + + + + + + + +
+ (0016121) +
+ Jens Grabowski    +
+ 29-11-2021 09:48    +
+ 		+ + + + +
+ Implemented
+
+ + diff --git a/docs/mantis/CR8052.md b/docs/mantis/CR8052.md new file mode 100644 index 0000000000000000000000000000000000000000..f6b68f090ad6741222bd0839729e9e6b568d4c6d --- /dev/null +++ b/docs/mantis/CR8052.md @@ -0,0 +1,99 @@ + + + + + + + + + + + + + 0008052: Typo in 27.1.2.0 - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008052Part 01: TTCN-3 Core LanguageEditorialpublic07-09-2021 16:2029-11-2021 09:52
ReporterGusztáv Adamis 
Assigned ToJens Grabowski 
PrioritylowSeveritytrivialReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Clause Reference(s)27.1.2.0
Source (company - Author)     Gusztáv Adamis Ericsson
Summary0008052: Typo in 27.1.2.0
DescriptionIn the following sentence the starting o of override is typed in courier.
+
+Attributes with the @local modifier override attributes from higher scope, but they are valid for the associated language element only.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR8052-211109.docx (74,837) 09-11-2021 09:05
http://oldforge.etsi.org/mantis/file_download.php?file_id=4039&type=bug
Issue History
Date ModifiedUsernameFieldChange
07-09-2021 16:20Gusztáv AdamisNew Issue
09-09-2021 09:21Jens GrabowskiProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
09-09-2021 09:21Jens GrabowskiAssigned To => Jens Grabowski
09-09-2021 09:21Jens GrabowskiStatusnew => assigned
09-11-2021 09:05Jens GrabowskiFile Added: CR8052-211109.docx
09-11-2021 09:05Jens GrabowskiNote Added: 0016034
09-11-2021 09:05Jens GrabowskiStatusassigned => resolved
09-11-2021 09:05Jens GrabowskiResolutionopen => fixed
29-11-2021 09:52Jens GrabowskiNote Added: 0016122
29-11-2021 09:52Jens GrabowskiStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0016034) +
+ Jens Grabowski    +
+ 09-11-2021 09:05    +
+ 		+ + + + +
+ Typo
+
+
+
+ + + + + + + + + + +
+ (0016122) +
+ Jens Grabowski    +
+ 29-11-2021 09:52    +
+ 		+ + + + +
+ Implemented
+
+ + diff --git a/docs/mantis/CR8053.md b/docs/mantis/CR8053.md new file mode 100644 index 0000000000000000000000000000000000000000..6ea6ebaa0f9790752bdc5b337aca5aee787c32fb --- /dev/null +++ b/docs/mantis/CR8053.md @@ -0,0 +1,173 @@ + + + + + + + + + + + + + 0008053: Start a previously expired timer - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008053Part 01: TTCN-3 Core LanguageClarificationpublic07-09-2021 16:2929-11-2021 10:17
ReporterGusztáv Adamis 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Clause Reference(s)23.2
Source (company - Author)     Gusztáv Adamis Ericsson
Summary0008053: Start a previously expired timer
DescriptionThe start operation may be applied to a running timer, in which case the timer is stopped and re-started. Any entry in a timeout-list for this timer shall be removed from the timeout-list.
+
+But the timer shall also be removed from timeout-list (if it is expired before and timeout is not processed on it), if a non-running timer is started (again).
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR8053-211111.docx (70,910) 11-11-2021 12:11
http://oldforge.etsi.org/mantis/file_download.php?file_id=4052&type=bug
docx CR8053-211111-V2.docx (71,322) 11-11-2021 14:02
http://oldforge.etsi.org/mantis/file_download.php?file_id=4055&type=bug
Issue History
Date ModifiedUsernameFieldChange
07-09-2021 16:29Gusztáv AdamisNew Issue
08-09-2021 11:08Jens GrabowskiProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
08-09-2021 11:28Jens GrabowskiAssigned To => Jens Grabowski
08-09-2021 11:28Jens GrabowskiStatusnew => assigned
11-11-2021 12:11Jens GrabowskiFile Added: CR8053-211111.docx
11-11-2021 12:12Jens GrabowskiNote Added: 0016061
11-11-2021 12:12Jens GrabowskiAssigned ToJens Grabowski => Gusztáv Adamis
11-11-2021 12:12Jens GrabowskiStatusassigned => confirmed
11-11-2021 13:39Gusztáv AdamisNote Added: 0016064
11-11-2021 13:40Gusztáv AdamisAssigned ToGusztáv Adamis => Jens Grabowski
11-11-2021 14:02Jens GrabowskiFile Added: CR8053-211111-V2.docx
11-11-2021 14:02Jens GrabowskiNote Added: 0016066
11-11-2021 14:02Jens GrabowskiStatusconfirmed => resolved
11-11-2021 14:02Jens GrabowskiResolutionopen => fixed
29-11-2021 10:17Jens GrabowskiNote Added: 0016123
29-11-2021 10:17Jens GrabowskiStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0016061) +
+ Jens Grabowski    +
+ 11-11-2021 12:12    +
+ 		+ + + + +
+ Gusztav, please check and assign it back to me.
+
+
+
+ + + + + + + + + + +
+ (0016064) +
+ Gusztáv Adamis    +
+ 11-11-2021 13:39    +
+ 		+ + + + +
+ Timeout list is 2x in the sentence, and according to the new ETSI terminology instead of is -> shall be has to be used.
+
+I guess this would enough:
+
+The start operation may be applied to a timer that has already expired; in this case, any entry in the timeout list for this timer shall be removed.
+
+But I can accept the sentence you offered.
+
+
+
+ + + + + + + + + + +
+ (0016066) +
+ Jens Grabowski    +
+ 11-11-2021 14:02    +
+ 		+ + + + +
+ Resolved as dicussed.
+
+
+
+ + + + + + + + + + +
+ (0016123) +
+ Jens Grabowski    +
+ 29-11-2021 10:17    +
+ 		+ + + + +
+ Implemented
+
+ + diff --git a/docs/mantis/CR8054.md b/docs/mantis/CR8054.md new file mode 100644 index 0000000000000000000000000000000000000000..55b2d1ea4bdda29938251a82112976b9d35bc0ea --- /dev/null +++ b/docs/mantis/CR8054.md @@ -0,0 +1,313 @@ + + + + + + + + + + + + + 0008054: What happens if same verdict but with different text is set by setverdict - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008054Part 01: TTCN-3 Core LanguageClarificationpublic07-09-2021 16:4129-11-2021 10:30
ReporterGusztáv Adamis 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Clause Reference(s)24.2
Source (company - Author)     Gusztáv Adamis Ericsson
Summary0008054: What happens if same verdict but with different text is set by setverdict
DescriptionWhat will be the result of this sequence?
+
+setverdict (pass, "text1");
+setverdict (pass, "text2");
+
+At least a note or an example shall be added to clarify it
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR008054.docx (171,457) 08-11-2021 16:55
http://oldforge.etsi.org/mantis/file_download.php?file_id=4034&type=bug
Issue History
Date ModifiedUsernameFieldChange
07-09-2021 16:41Gusztáv AdamisNew Issue
08-09-2021 11:06Jens GrabowskiProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
08-09-2021 11:06Jens GrabowskiNote Added: 0015957
08-09-2021 11:07Jens GrabowskiAssigned To => Gusztáv Adamis
08-09-2021 11:07Jens GrabowskiStatusnew => assigned
09-09-2021 15:13Gusztáv AdamisNote Added: 0015970
09-09-2021 15:13Gusztáv AdamisNote Edited: 0015970bug_revision_view_page.php?bugnote_id=15970#r559
09-09-2021 15:18Gusztáv AdamisNote Added: 0015971
10-09-2021 15:08Jens GrabowskiNote Added: 0015984
11-09-2021 00:04Gusztáv AdamisNote Added: 0015991
08-11-2021 16:53Gusztáv AdamisNote Added: 0016018
08-11-2021 16:55Gusztáv AdamisFile Added: CR008054.docx
08-11-2021 17:21Gusztáv AdamisNote Added: 0016021
08-11-2021 17:21Gusztáv AdamisAssigned ToGusztáv Adamis => Jacob Wieland - Spirent
08-11-2021 17:21Gusztáv AdamisStatusassigned => confirmed
09-11-2021 14:16Jacob Wieland - SpirentStatusconfirmed => resolved
09-11-2021 14:16Jacob Wieland - SpirentResolutionopen => fixed
09-11-2021 14:16Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Jens Grabowski
29-11-2021 10:30Jens GrabowskiNote Added: 0016124
29-11-2021 10:30Jens GrabowskiStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015957) +
+ Jens Grabowski    +
+ 08-09-2021 11:06    +
+ 		+ + + + +
+ STF discussion: Check how the different tool works.
+
+
+
+ + + + + + + + + + +
+ (0015970) +
+ Gusztáv Adamis    +
+ 09-09-2021 15:13    +
+ 		+ + + + +
+ According to current standard, the text argument of the setverdict is used only for logging purposes. This text is not accessible from the code. It is logged, when a component terminates, so e.g. the text of a PTC is not passed to MTC, so we do not have to deal with this issue.
+
+"The optional parameters allow to provide information that explain the reasons for assigning the verdict. This information is composed to a string and stored in an implicit charstring variable. On termination of the test component, the actual local verdict is logged together with the implicit charstring variable. Since the optional parameters can be seen as log information, the same rules and restrictions as for the parameters of the log statement (clause 19.11) apply."
+
+
+
+
+
+ + + + + + + + + + +
+ (0015971) +
+ Gusztáv Adamis    +
+ 09-09-2021 15:18    +
+ 		+ + + + +
+ I would suggest to add a short explanation to 'overwritten' into Semantic Description, like
+
+As the result of the setverdict operation, the implicit charstring variable is overwritten whenever the local verdict of a test component is overwritten (I.E. A NEW VALUE IS ASSIGNED TO IT).
+
+
+
+ + + + + + + + + + +
+ (0015984) +
+ Jens Grabowski    +
+ 10-09-2021 15:08    +
+ 		+ + + + +
+ STF discussion: Further discussion required for verdict text for final test case verdict.
+
+
+
+ + + + + + + + + + +
+ (0015991) +
+ Gusztáv Adamis    +
+ 11-09-2021 00:04    +
+ 		+ + + + +
+ STF decision: Under this CR, only the clarification of the overwriting is required. If specification of what the text of the final verdict of a test case is required, either in core language or in TCI is required, a new TC will be submitted.
+
+
+
+ + + + + + + + + + +
+ (0016018) +
+ Gusztáv Adamis    +
+ 08-11-2021 16:53    +
+ 		+ + + + +
+ Meaning of verdict overwriting explained, a new example added
+
+
+
+ + + + + + + + + + +
+ (0016021) +
+ Gusztáv Adamis    +
+ 08-11-2021 17:21    +
+ 		+ + + + +
+ @Jacob, pls check it
+
+
+
+ + + + + + + + + + +
+ (0016124) +
+ Jens Grabowski    +
+ 29-11-2021 10:30    +
+ 		+ + + + +
+ Implemented
+
+ + diff --git a/docs/mantis/CR8055.md b/docs/mantis/CR8055.md new file mode 100644 index 0000000000000000000000000000000000000000..70405d8f106286166cb8366163800d0331dcfaa6 --- /dev/null +++ b/docs/mantis/CR8055.md @@ -0,0 +1,169 @@ + + + + + + + + + + + + + 0008055: Arguments of External actions shall be same as log - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008055Part 01: TTCN-3 Core LanguageNew Featurepublic07-09-2021 16:4629-11-2021 11:23
ReporterGusztáv Adamis 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version4.13.1 (ongoing) 
Clause Reference(s)25
Source (company - Author)     Gusztáv Adamis Ericsson
Summary0008055: Arguments of External actions shall be same as log
DescriptionSince the Ext.action and log can be used in similar way, the difference between them is basically the default output device, the arguments of the action should be the same as of log.
+
+log "(" { ( FreeText | TemplateInstance ) [","] } ")" => action "(" { ( FreeText | TemplateInstance ) [","] } ")"
+
+instead of the current action "(" { ( FreeText | Expression ) ["&"] } ")"
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0008064closed  Part 05: TTCN-3 Runtime Interface  add triSUTAction function that gets a parameter list 
related to 0008065closed  Ext Pack: Extended TRI (ES 202 789) add xtriSUTAction function that gets a parameter list 
Attached Filesdocx CR0008055.docx (170,459) 09-11-2021 17:28
http://oldforge.etsi.org/mantis/file_download.php?file_id=4044&type=bug
Issue History
Date ModifiedUsernameFieldChange
07-09-2021 16:46Gusztáv AdamisNew Issue
08-09-2021 10:56Jens GrabowskiNote Added: 0015956
08-09-2021 10:56Jens GrabowskiAssigned To => Jacob Wieland - Spirent
08-09-2021 10:56Jens GrabowskiStatusnew => assigned
08-09-2021 10:57Jens GrabowskiProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
10-09-2021 11:23Jacob Wieland - SpirentRelationship addedrelated to 0008064
10-09-2021 11:35Jacob Wieland - SpirentRelationship addedrelated to 0008065
10-09-2021 16:17Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gusztáv Adamis
09-11-2021 17:28Gusztáv AdamisFile Added: CR0008055.docx
09-11-2021 17:30Gusztáv AdamisNote Added: 0016045
09-11-2021 17:30Gusztáv AdamisNote Added: 0016046
09-11-2021 17:30Gusztáv AdamisAssigned ToGusztáv Adamis => Jacob Wieland - Spirent
09-11-2021 17:30Gusztáv AdamisStatusassigned => confirmed
10-11-2021 15:45Jacob Wieland - SpirentStatusconfirmed => resolved
10-11-2021 15:45Jacob Wieland - SpirentFixed in Version => 4.13.1 (ongoing)
10-11-2021 15:45Jacob Wieland - SpirentResolutionopen => fixed
10-11-2021 15:45Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Jens Grabowski
29-11-2021 11:23Jens GrabowskiNote Added: 0016125
29-11-2021 11:23Jens GrabowskiStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015956) +
+ Jens Grabowski    +
+ 08-09-2021 10:56    +
+ 		+ + + + +
+ STF discussion: agreement, Jacob will submit a corresponding TRI CR.
+
+
+
+ + + + + + + + + + +
+ (0016045) +
+ Gusztáv Adamis    +
+ 09-11-2021 17:30    +
+ 		+ + + + +
+ action description and arguments are aligned with log; the example extended
+
+
+
+ + + + + + + + + + +
+ (0016046) +
+ Gusztáv Adamis    +
+ 09-11-2021 17:30    +
+ 		+ + + + +
+ Pls review
+
+
+
+ + + + + + + + + + +
+ (0016125) +
+ Jens Grabowski    +
+ 29-11-2021 11:23    +
+ 		+ + + + +
+ Implemented
+
+ + diff --git a/docs/mantis/CR8056.md b/docs/mantis/CR8056.md new file mode 100644 index 0000000000000000000000000000000000000000..cefae95d24a5677236bc8624f3ddd568db4314d0 --- /dev/null +++ b/docs/mantis/CR8056.md @@ -0,0 +1,97 @@ + + + + + + + + + + + + + 0008056: BNF updates and formatting - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 07: Using ASN.1 with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008056Part 07: Using ASN.1 with TTCN-3Technicalpublic08-09-2021 15:5015-11-2021 12:31
ReporterAxel Rennoch 
Assigned To 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.9.1 (ongoing) 
Target VersionNext version (to be defined)Fixed in Versionv4.9.1 (ongoing) 
Clause Reference(s)A.2
Source (company - Author)Axel Rennoch (FOKUS)
Summary0008056: BNF updates and formatting
DescriptionThe BNF rules are not aligned with the actual BNF rules in part 1, numbers need to be updated (455->405, 474->424), several productions in part 1 have been removed/changed in the latest versions (e.g. GlobalModuleId).
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR0008056_es_20187307v040901p.docx (48,694) 08-11-2021 10:59
http://oldforge.etsi.org/mantis/file_download.php?file_id=4018&type=bug
Issue History
Date ModifiedUsernameFieldChange
08-09-2021 15:50Axel RennochNew Issue
09-09-2021 09:24Jens GrabowskiAssigned To => Axel Rennoch
09-09-2021 09:24Jens GrabowskiStatusnew => assigned
08-11-2021 10:59Axel RennochFile Added: CR0008056_es_20187307v040901p.docx
08-11-2021 11:00Axel RennochNote Added: 0015996
08-11-2021 11:00Axel RennochAssigned ToAxel Rennoch => Jacob Wieland - Spirent
08-11-2021 11:00Axel RennochStatusassigned => confirmed
10-11-2021 15:35Jacob Wieland - SpirentStatusconfirmed => resolved
10-11-2021 15:35Jacob Wieland - SpirentFixed in Version => v4.9.1 (ongoing)
10-11-2021 15:35Jacob Wieland - SpirentResolutionopen => fixed
12-11-2021 15:40Jacob Wieland - SpirentStatusresolved => feedback
12-11-2021 15:40Jacob Wieland - SpirentResolutionfixed => reopened
12-11-2021 15:40Jacob Wieland - SpirentStatusfeedback => resolved
12-11-2021 15:40Jacob Wieland - SpirentResolutionreopened => fixed
12-11-2021 15:40Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Tomas Urban
15-11-2021 12:31Tomas UrbanNote Added: 0016088
15-11-2021 12:31Tomas UrbanStatusresolved => closed
15-11-2021 12:31Tomas UrbanAssigned ToTomas Urban =>
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015996) +
+ Axel Rennoch    +
+ 08-11-2021 11:00    +
+ 		+ + + + +
+ Please check the resolution file.
+
+
+
+ + + + + + + + + + +
+ (0016088) +
+ Tomas Urban    +
+ 15-11-2021 12:31    +
+ 		+ + + + +
+ Added to the draft 4.9.2
+
+ + diff --git a/docs/mantis/CR8057.md b/docs/mantis/CR8057.md new file mode 100644 index 0000000000000000000000000000000000000000..36aaaa50b90f5138ffa3feb11ca2451f853c5398 --- /dev/null +++ b/docs/mantis/CR8057.md @@ -0,0 +1,65 @@ + + + + + + + + + + + + + 0008057: BNF updates and formatting - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Config & Deployment Support (ES 202 781)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008057Ext Pack: Config & Deployment Support (ES 202 781)Technicalpublic08-09-2021 15:5730-11-2021 18:43
ReporterAxel Rennoch 
Assigned ToJacob Wieland - Spirent 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv1.8.1 (ongoing) 
Target VersionNext version (to be defined)Fixed in Versionv1.8.1 (ongoing) 
Clause Reference(s)A.2 and related clauses
Source (company - Author)Axel Rennoch (FOKUS)
TS versionETSI ES 202 781
Summary0008057: BNF updates and formatting
DescriptionThe introduction and content of the productions need to be updated. Some rules (e.g. TestCaseRef) do not exist in part 1 anymore, rule numbers are not aligned and consistent (e.g. 186->188, 192->193).
+
+Any changes need to be aligned with the syntax in the chapters, e.g. 5.1.8.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR0008057_es_202781v010801p.docx (56,279) 08-11-2021 11:00
http://oldforge.etsi.org/mantis/file_download.php?file_id=4019&type=bug
Issue History
Date ModifiedUsernameFieldChange
08-09-2021 15:57Axel RennochNew Issue
09-09-2021 09:23Jens GrabowskiAssigned To => Axel Rennoch
09-09-2021 09:23Jens GrabowskiStatusnew => assigned
08-11-2021 11:00Axel RennochFile Added: CR0008057_es_202781v010801p.docx
08-11-2021 11:01Axel RennochNote Added: 0015997
08-11-2021 11:01Axel RennochAssigned ToAxel Rennoch => Jacob Wieland - Spirent
08-11-2021 11:01Axel RennochStatusassigned => confirmed
10-11-2021 15:33Jacob Wieland - SpirentStatusconfirmed => resolved
10-11-2021 15:33Jacob Wieland - SpirentFixed in Version => v1.8.1 (ongoing)
10-11-2021 15:33Jacob Wieland - SpirentResolutionopen => fixed
30-11-2021 18:43Jacob Wieland - SpirentStatusresolved => closed
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015997) +
+ Axel Rennoch    +
+ 08-11-2021 11:01    +
+ 		+ + + + +
+ Please check the resolution file.
+
+ + diff --git a/docs/mantis/CR8058.md b/docs/mantis/CR8058.md new file mode 100644 index 0000000000000000000000000000000000000000..59b4330a10a1baa721edc97d353c56cd9ca2bb67 --- /dev/null +++ b/docs/mantis/CR8058.md @@ -0,0 +1,63 @@ + + + + + + + + + + + + + 0008058: BNF updates and formatting - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Perf & Real Time Testing (ES 202 782)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008058Ext Pack: Perf & Real Time Testing (ES 202 782)Technicalpublic08-09-2021 16:0130-11-2021 18:45
ReporterAxel Rennoch 
Assigned ToJacob Wieland - Spirent 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv1.4.1 (ongoing) 
Target VersionNext version (to be defined)Fixed in Versionv1.4.1 (ongoing) 
Clause Reference(s)Annex A
Source (company - Author)Axel Rennoch (FOKUS)
TS versionETSI ES 202 782
Summary0008058: BNF updates and formatting
DescriptionThe Annex A need an introduction to the BNF rules. The changed and new productions do not have any numbers (to be added). Conflicts with BNF in TTCN-3 part 1 need to be considered (e.g. PortRedirect).
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR0008058_es_202782v010301p.docx (33,235) 08-11-2021 11:01
http://oldforge.etsi.org/mantis/file_download.php?file_id=4020&type=bug
Issue History
Date ModifiedUsernameFieldChange
08-09-2021 16:01Axel RennochNew Issue
09-09-2021 09:23Jens GrabowskiAssigned To => Axel Rennoch
09-09-2021 09:23Jens GrabowskiStatusnew => assigned
08-11-2021 11:01Axel RennochFile Added: CR0008058_es_202782v010301p.docx
08-11-2021 11:01Axel RennochNote Added: 0015998
08-11-2021 11:01Axel RennochAssigned ToAxel Rennoch => Jacob Wieland - Spirent
08-11-2021 11:01Axel RennochStatusassigned => confirmed
10-11-2021 15:30Jacob Wieland - SpirentStatusconfirmed => resolved
10-11-2021 15:30Jacob Wieland - SpirentFixed in Version => v1.4.1 (ongoing)
10-11-2021 15:30Jacob Wieland - SpirentResolutionopen => fixed
30-11-2021 18:45Jacob Wieland - SpirentStatusresolved => closed
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015998) +
+ Axel Rennoch    +
+ 08-11-2021 11:01    +
+ 		+ + + + +
+ Please check the resolution file.
+
+ + diff --git a/docs/mantis/CR8059.md b/docs/mantis/CR8059.md new file mode 100644 index 0000000000000000000000000000000000000000..f3d51cff0f34aa1cb4ac8573f11d1a1198741bf8 --- /dev/null +++ b/docs/mantis/CR8059.md @@ -0,0 +1,144 @@ + + + + + + + + + + + + + 0008059: BNF updates and formatting - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Advanced Parametrization (ES 202 784)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008059Ext Pack: Advanced Parametrization (ES 202 784)Technicalpublic08-09-2021 16:0530-11-2021 18:50
ReporterAxel Rennoch 
Assigned ToJacob Wieland - Spirent 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv1.8.1 (ongoing) 
Target VersionNext version (to be defined)Fixed in Versionv1.8.1 (ongoing) 
TS versionETSI ES 202 784
Clause Reference(s)5.5
Source (company - Author)Axel Rennoch (FOKUS)
Summary0008059: BNF updates and formatting
DescriptionThe section 5.5 need some more introduction explaining changed against TTCN-3 part 1. Changed rules need to be updated (numbers and content), e.g. 15->16, 33->34, etc.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR0008059_es_202784v010801p.docx (51,632) 08-11-2021 11:02
http://oldforge.etsi.org/mantis/file_download.php?file_id=4021&type=bug
docx CR0008059_es_202784v010801p-r1.docx (52,160) 09-11-2021 16:39
http://oldforge.etsi.org/mantis/file_download.php?file_id=4043&type=bug
Issue History
Date ModifiedUsernameFieldChange
08-09-2021 16:05Axel RennochNew Issue
09-09-2021 09:23Jens GrabowskiAssigned To => Axel Rennoch
09-09-2021 09:23Jens GrabowskiStatusnew => assigned
08-11-2021 11:02Axel RennochFile Added: CR0008059_es_202784v010801p.docx
08-11-2021 11:02Axel RennochNote Added: 0015999
08-11-2021 11:02Axel RennochAssigned ToAxel Rennoch => Jacob Wieland - Spirent
08-11-2021 11:02Axel RennochStatusassigned => confirmed
09-11-2021 15:55Jacob Wieland - SpirentNote Added: 0016043
09-11-2021 15:56Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Axel Rennoch
09-11-2021 15:56Jacob Wieland - SpirentStatusconfirmed => assigned
09-11-2021 16:39Axel RennochFile Added: CR0008059_es_202784v010801p-r1.docx
09-11-2021 16:44Axel RennochNote Added: 0016044
09-11-2021 16:44Axel RennochAssigned ToAxel Rennoch => Jacob Wieland - Spirent
09-11-2021 16:44Axel RennochStatusassigned => confirmed
10-11-2021 15:28Jacob Wieland - SpirentStatusconfirmed => resolved
10-11-2021 15:28Jacob Wieland - SpirentFixed in Version => v1.8.1 (ongoing)
10-11-2021 15:28Jacob Wieland - SpirentResolutionopen => fixed
30-11-2021 18:50Jacob Wieland - SpirentStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0015999) +
+ Axel Rennoch    +
+ 08-11-2021 11:02    +
+ 		+ + + + +
+ Please check the resolution file.
+
+
+
+ + + + + + + + + + +
+ (0016043) +
+ Jacob Wieland - Spirent    +
+ 09-11-2021 15:55    +
+ 		+ + + + +
+ The last two rules seem to be wrong:
+
+ReferencedType ::= ExtendedIdentifier [TypeActualParList]
+                        [ExtendedTypeFieldReference]
+
+should be
+
+ReferencedType ::= ExtendedIdentifier [ActualTypeParList] [TypeActualParList]
+                        [ExtendedTypeFieldReference]
+
+
+and I have no idea where the Identifier [ActualTypeParList] [TypeActualParList] in the rule for ExtendedTypeFieldReference would be useful (as fields cannot be declared parameterized)
+
+
+
+ + + + + + + + + + +
+ (0016044) +
+ Axel Rennoch    +
+ 09-11-2021 16:44    +
+ 		+ + + + +
+ The first comment has been used/corrected in the revision file.
+
+Regarding the second comment, it seems that the rule for ExtendedFieldReference should have be used and the related STATIC SEMANTIC may answer the question?
+
+ + diff --git a/docs/mantis/CR8060.md b/docs/mantis/CR8060.md new file mode 100644 index 0000000000000000000000000000000000000000..7144c8800f85a0a32a7424bee10878c0793af985 --- /dev/null +++ b/docs/mantis/CR8060.md @@ -0,0 +1,203 @@ + + + + + + + + + + + + + 0008060: BNF updates and formatting - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Behaviour Types (ES 202 785)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008060Ext Pack: Behaviour Types (ES 202 785)Technicalpublic08-09-2021 16:0930-11-2021 18:46
ReporterAxel Rennoch 
Assigned ToJacob Wieland - Spirent 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product VersionNext version (to be defined) 
Target Versionv1.8.1 (ongoing)Fixed in Versionv1.8.1 (ongoing) 
Clause Reference(s)5.13
Source (company - Author)Axel Rennoch (FOKUS)
Summary0008060: BNF updates and formatting
DescriptionThe clause need some more introduction explaining the difference against BNF in TTCN-3 part 1. Rules need to be aligned with the BNF core notation.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR0008060_es_202785v010801p.docx (47,760) 08-11-2021 11:02
http://oldforge.etsi.org/mantis/file_download.php?file_id=4022&type=bug
docx CR0008060_es_202785v010801p-r1.docx (48,108) 09-11-2021 15:35
http://oldforge.etsi.org/mantis/file_download.php?file_id=4042&type=bug
docx CR0008060_es_202785v010801p-r2a.docx (20,561) 11-11-2021 10:30
http://oldforge.etsi.org/mantis/file_download.php?file_id=4051&type=bug
Issue History
Date ModifiedUsernameFieldChange
08-09-2021 16:09Axel RennochNew Issue
09-09-2021 09:22Jens GrabowskiAssigned To => Axel Rennoch
09-09-2021 09:22Jens GrabowskiStatusnew => assigned
08-11-2021 11:02Axel RennochFile Added: CR0008060_es_202785v010801p.docx
08-11-2021 11:02Axel RennochNote Added: 0016000
08-11-2021 11:02Axel RennochAssigned ToAxel Rennoch => Jacob Wieland - Spirent
08-11-2021 11:02Axel RennochStatusassigned => confirmed
09-11-2021 15:13Jacob Wieland - SpirentNote Added: 0016040
09-11-2021 15:14Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Axel Rennoch
09-11-2021 15:14Jacob Wieland - SpirentStatusconfirmed => assigned
09-11-2021 15:35Axel RennochFile Added: CR0008060_es_202785v010801p-r1.docx
09-11-2021 15:36Axel RennochNote Added: 0016042
09-11-2021 15:36Axel RennochAssigned ToAxel Rennoch => Jacob Wieland - Spirent
09-11-2021 15:36Axel RennochStatusassigned => confirmed
10-11-2021 15:24Jacob Wieland - SpirentNote Added: 0016057
10-11-2021 15:25Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Axel Rennoch
10-11-2021 15:25Jacob Wieland - SpirentStatusconfirmed => assigned
11-11-2021 10:30Axel RennochFile Added: CR0008060_es_202785v010801p-r2a.docx
11-11-2021 10:32Axel RennochNote Added: 0016059
11-11-2021 10:32Axel RennochAssigned ToAxel Rennoch => Jacob Wieland - Spirent
11-11-2021 10:32Axel RennochStatusassigned => confirmed
11-11-2021 15:03Jacob Wieland - SpirentStatusconfirmed => resolved
11-11-2021 15:03Jacob Wieland - SpirentFixed in Version => v1.8.1 (ongoing)
11-11-2021 15:03Jacob Wieland - SpirentResolutionopen => fixed
30-11-2021 18:46Jacob Wieland - SpirentStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0016000) +
+ Axel Rennoch    +
+ 08-11-2021 11:02    +
+ 		+ + + + +
+ Please check the resolution file.
+
+
+
+ + + + + + + + + + +
+ (0016040) +
+ Jacob Wieland - Spirent    +
+ 09-11-2021 15:13    +
+ 		+ + + + +
+ I don't understand the underlining policy in the second section at all
+
+Should BehaviorValue not be underlined?
+
+Why are the apply-rules only partially underlined?
+
+
+
+ + + + + + + + + + +
+ (0016042) +
+ Axel Rennoch    +
+ 09-11-2021 15:36    +
+ 		+ + + + +
+ Your comment is absolut right. Please find a revision "CR0008060_es_202785v010801p-r1.docx" for the resolution.
+
+
+
+ + + + + + + + + + +
+ (0016057) +
+ Jacob Wieland - Spirent    +
+ 10-11-2021 15:24    +
+ 		+ + + + +
+ Sorry, but the new proposal looks the same as the old one concerning the underlining.
+
+
+
+ + + + + + + + + + +
+ (0016059) +
+ Axel Rennoch    +
+ 11-11-2021 10:32    +
+ 		+ + + + +
+ Due to some issues with MS Word, I created a new resolution file CR0008060_es_202785v010801p-r2a.docx that now should display the latest changes.
+
+ + diff --git a/docs/mantis/CR8061.md b/docs/mantis/CR8061.md new file mode 100644 index 0000000000000000000000000000000000000000..4f3982a4752b3b04e94762d4c8a134008e1ed68f --- /dev/null +++ b/docs/mantis/CR8061.md @@ -0,0 +1,63 @@ + + + + + + + + + + + + + 0008061: BNF updates and formatting - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Continuous signal support (ES 202 786)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008061Ext Pack: Continuous signal support (ES 202 786)Technicalpublic08-09-2021 16:1230-11-2021 18:47
ReporterAxel Rennoch 
Assigned ToJacob Wieland - Spirent 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv1.4.1 (ongoing) 
Target VersionNext version (to be defined)Fixed in Version 
Summary0008061: BNF updates and formatting
DescriptionAnnex A.2 need to be updated, e.g. addition of explanations/introduction and alignment of the rules against BNF in TTCN-3 part 1 (e.g. rule 466->479).
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR0008061_es_202786v010401p.docx (52,335) 08-11-2021 11:03
http://oldforge.etsi.org/mantis/file_download.php?file_id=4023&type=bug
Issue History
Date ModifiedUsernameFieldChange
08-09-2021 16:12Axel RennochNew Issue
09-09-2021 09:22Jens GrabowskiAssigned To => Axel Rennoch
09-09-2021 09:22Jens GrabowskiStatusnew => assigned
08-11-2021 11:03Axel RennochFile Added: CR0008061_es_202786v010401p.docx
08-11-2021 11:03Axel RennochNote Added: 0016001
08-11-2021 11:03Axel RennochAssigned ToAxel Rennoch => Jacob Wieland - Spirent
08-11-2021 11:03Axel RennochStatusassigned => confirmed
09-11-2021 14:40Jacob Wieland - SpirentStatusconfirmed => resolved
09-11-2021 14:40Jacob Wieland - SpirentResolutionopen => fixed
30-11-2021 18:47Jacob Wieland - SpirentStatusresolved => closed
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0016001) +
+ Axel Rennoch    +
+ 08-11-2021 11:03    +
+ 		+ + + + +
+ Please check the resolution file.
+
+ + diff --git a/docs/mantis/CR8062.md b/docs/mantis/CR8062.md new file mode 100644 index 0000000000000000000000000000000000000000..210fbdea3d470809ce29e6db7527be35501611fa --- /dev/null +++ b/docs/mantis/CR8062.md @@ -0,0 +1,63 @@ + + + + + + + + + + + + + 0008062: BNF updates and formatting - V1.4.1 (2020-05) - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Advanced Matching (ES 203 022)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008062Ext Pack: Advanced Matching (ES 203 022)Technicalpublic08-09-2021 16:1730-11-2021 18:46
ReporterAxel Rennoch 
Assigned ToJacob Wieland - Spirent 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionNext version (to be decided)Fixed in Version 
Clause Reference(s)A.1
Source (company - Author)Axel Rennoch (FOKUS)
TS versionETSI ES 203 022
Summary0008062: BNF updates and formatting - V1.4.1 (2020-05)
DescriptionUpdate introduction text (add of explanations regarding usage of fonts) and align productions numbers and content w.r.t. BNF in TTCN-3 part 1.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR0008062_es_203022v010401p.docx (44,902) 08-11-2021 11:04
http://oldforge.etsi.org/mantis/file_download.php?file_id=4024&type=bug
Issue History
Date ModifiedUsernameFieldChange
08-09-2021 16:17Axel RennochNew Issue
09-09-2021 09:22Jens GrabowskiAssigned To => Axel Rennoch
09-09-2021 09:22Jens GrabowskiStatusnew => assigned
08-11-2021 11:04Axel RennochFile Added: CR0008062_es_203022v010401p.docx
08-11-2021 11:04Axel RennochNote Added: 0016002
08-11-2021 11:04Axel RennochAssigned ToAxel Rennoch => Jacob Wieland - Spirent
08-11-2021 11:04Axel RennochStatusassigned => confirmed
09-11-2021 12:04Jacob Wieland - SpirentStatusconfirmed => resolved
09-11-2021 12:04Jacob Wieland - SpirentResolutionopen => fixed
30-11-2021 18:46Jacob Wieland - SpirentStatusresolved => closed
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0016002) +
+ Axel Rennoch    +
+ 08-11-2021 11:04    +
+ 		+ + + + +
+ Please check the resolution file.
+
+ + diff --git a/docs/mantis/CR8063.md b/docs/mantis/CR8063.md new file mode 100644 index 0000000000000000000000000000000000000000..277b429507a763e03e55a9b145f37b4e396324c2 --- /dev/null +++ b/docs/mantis/CR8063.md @@ -0,0 +1,97 @@ + + + + + + + + + + + + + 0008063: BNF updates and formatting - clause A.2 - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Object-oriented features (ES 203 790)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008063Ext Pack: Object-oriented features (ES 203 790)[All Projects] Generalpublic08-09-2021 16:1912-11-2021 12:21
ReporterAxel Rennoch 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product VersionV1.3.1 (ongoing) 
Target VersionNext version (to be decided)Fixed in Version 
Summary0008063: BNF updates and formatting - clause A.2
DescriptionUpdate introduction text (add of explanations regarding usage of fonts) and align productions numbers and content w.r.t. BNF in TTCN-3 part 1.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR0008063_es_203790v010301p.docx (52,341) 08-11-2021 15:06
http://oldforge.etsi.org/mantis/file_download.php?file_id=4028&type=bug
Issue History
Date ModifiedUsernameFieldChange
08-09-2021 16:19Axel RennochNew Issue
09-09-2021 09:22Jens GrabowskiAssigned To => Axel Rennoch
09-09-2021 09:22Jens GrabowskiStatusnew => assigned
08-11-2021 15:06Axel RennochFile Added: CR0008063_es_203790v010301p.docx
08-11-2021 15:07Axel RennochNote Added: 0016007
08-11-2021 15:07Axel RennochAssigned ToAxel Rennoch => Jacob Wieland - Spirent
08-11-2021 15:07Axel RennochStatusassigned => confirmed
08-11-2021 15:59Jacob Wieland - SpirentStatusconfirmed => resolved
08-11-2021 15:59Jacob Wieland - SpirentResolutionopen => fixed
08-11-2021 15:59Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Jens Grabowski
12-11-2021 12:21Jens GrabowskiNote Added: 0016074
12-11-2021 12:21Jens GrabowskiStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0016007) +
+ Axel Rennoch    +
+ 08-11-2021 15:07    +
+ 		+ + + + +
+ Please check the resolution file.
+
+
+
+ + + + + + + + + + +
+ (0016074) +
+ Jens Grabowski    +
+ 12-11-2021 12:21    +
+ 		+ + + + +
+ Implemented
+
+ + diff --git a/docs/mantis/CR8064.md b/docs/mantis/CR8064.md new file mode 100644 index 0000000000000000000000000000000000000000..21e5989e8c07695548a857f94fe1b3a3bc2e0242 --- /dev/null +++ b/docs/mantis/CR8064.md @@ -0,0 +1,98 @@ + + + + + + + + + + + + + 0008064: add triSUTAction function that gets a parameter list - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 05: TTCN-3 Runtime Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008064Part 05: TTCN-3 Runtime Interface New Featurepublic10-09-2021 11:2315-11-2021 12:30
ReporterJacob Wieland - Spirent 
Assigned To 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Versionv4.8.1 (ongoing) 
Clause Reference(s)5.5.5
Source (company - Author)Spirent - Jacob Wieland
Summary0008064: add triSUTAction function that gets a parameter list
DescriptionAllowing the sut action statement with a list of arbitrary (not necessarily string) parameters instead of a single string parameter necessitates introducing a new tri function
+triSUTAction (beside triSUTActionInformal) which should get a TriParameterListType as an argument representing the parameters given to the action statement in TTCN-3.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0008055closed Jens Grabowski Part 01: TTCN-3 Core Language Arguments of External actions shall be same as log 
Attached Filesdocx CR8064-1.docx (160,257) 10-11-2021 09:08
http://oldforge.etsi.org/mantis/file_download.php?file_id=4047&type=bug
Issue History
Date ModifiedUsernameFieldChange
10-09-2021 11:23Jacob Wieland - SpirentNew Issue
10-09-2021 11:23Jacob Wieland - SpirentRelationship addedrelated to 0008055
10-09-2021 15:43Jens GrabowskiAssigned To => Tomas Urban
10-09-2021 15:43Jens GrabowskiStatusnew => assigned
10-11-2021 09:08Tomas UrbanFile Added: CR8064-1.docx
10-11-2021 09:08Tomas UrbanNote Added: 0016049
10-11-2021 09:08Tomas UrbanAssigned ToTomas Urban => Jacob Wieland - Spirent
10-11-2021 09:08Tomas UrbanStatusassigned => confirmed
10-11-2021 15:49Jacob Wieland - SpirentStatusconfirmed => resolved
10-11-2021 15:49Jacob Wieland - SpirentFixed in Version => v4.8.1 (ongoing)
10-11-2021 15:49Jacob Wieland - SpirentResolutionopen => fixed
10-11-2021 15:49Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Tomas Urban
15-11-2021 12:30Tomas UrbanNote Added: 0016087
15-11-2021 12:30Tomas UrbanStatusresolved => closed
15-11-2021 12:30Tomas UrbanAssigned ToTomas Urban =>
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0016049) +
+ Tomas Urban    +
+ 10-11-2021 09:08    +
+ 		+ + + + +
+ Resolution uploaded. Please check.
+
+
+
+ + + + + + + + + + +
+ (0016087) +
+ Tomas Urban    +
+ 15-11-2021 12:30    +
+ 		+ + + + +
+ Added to the draft 4.8.2
+
+ + diff --git a/docs/mantis/CR8065.md b/docs/mantis/CR8065.md new file mode 100644 index 0000000000000000000000000000000000000000..973212e8f91fec43fadd8a715665bfdc04d18275 --- /dev/null +++ b/docs/mantis/CR8065.md @@ -0,0 +1,98 @@ + + + + + + + + + + + + + 0008065: add xtriSUTAction function that gets a parameter list - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Extended TRI (ES 202 789)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008065Ext Pack: Extended TRI (ES 202 789)New Featurepublic10-09-2021 11:3415-11-2021 12:29
ReporterJacob Wieland - Spirent 
Assigned To 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Clause Reference(s)7.5A
Source (company - Author)Spirent - Jacob Wieland
Summary0008065: add xtriSUTAction function that gets a parameter list
DescriptionAllowing the sut action statement with a list of arbitrary (not necessarily string) parameters instead of a single string parameter necessitates introducing a new tri function
+xtriSUTAction which should get a ValueList as an argument representing the parameters given to the action statement in TTCN-3.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0008055closed Jens Grabowski Part 01: TTCN-3 Core Language Arguments of External actions shall be same as log 
Attached Filesdocx CR8065-1.docx (154,691) 10-11-2021 09:36
http://oldforge.etsi.org/mantis/file_download.php?file_id=4048&type=bug
Issue History
Date ModifiedUsernameFieldChange
10-09-2021 11:34Jacob Wieland - SpirentNew Issue
10-09-2021 11:35Jacob Wieland - SpirentRelationship addedrelated to 0008055
10-09-2021 15:43Jens GrabowskiAssigned To => Tomas Urban
10-09-2021 15:43Jens GrabowskiStatusnew => assigned
10-11-2021 09:36Tomas UrbanFile Added: CR8065-1.docx
10-11-2021 09:36Tomas UrbanNote Added: 0016050
10-11-2021 09:36Tomas UrbanAssigned ToTomas Urban => Jacob Wieland - Spirent
10-11-2021 09:36Tomas UrbanStatusassigned => confirmed
11-11-2021 15:46Jacob Wieland - SpirentStatusconfirmed => resolved
11-11-2021 15:46Jacob Wieland - SpirentResolutionopen => fixed
11-11-2021 15:46Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Tomas Urban
15-11-2021 12:29Tomas UrbanNote Added: 0016085
15-11-2021 12:29Tomas UrbanStatusresolved => closed
15-11-2021 12:29Tomas UrbanAssigned ToTomas Urban =>
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0016050) +
+ Tomas Urban    +
+ 10-11-2021 09:36    +
+ 		+ + + + +
+ Resolution uploaded. Please check.
+
+
+
+ + + + + + + + + + +
+ (0016085) +
+ Tomas Urban    +
+ 15-11-2021 12:29    +
+ 		+ + + + +
+ Added to the draft 1.5.2
+
+ + diff --git a/docs/mantis/CR8066.md b/docs/mantis/CR8066.md new file mode 100644 index 0000000000000000000000000000000000000000..fb319f87d518575167d1e765fd258c4c2c21fc8a --- /dev/null +++ b/docs/mantis/CR8066.md @@ -0,0 +1,140 @@ + + + + + + + + + + + + + 0008066: Invalid example on modified templates - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008066Part 01: TTCN-3 Core LanguageTechnicalpublic05-11-2021 09:1829-11-2021 11:31
ReporterTomas Urban 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Clause Reference(s)15.8
Source (company - Author)TTF 014
Summary0008066: Invalid example on modified templates
DescriptionExample 8 located in the section 15.5 contains the following TTCN-3 statements:
+
+template(value) MyRecordType m_myValueRecTemplate1 := {...}
+template MyRecordType m_myUnrestrictedRecTemplate3 modifies m_myValueRecTemplate1 := {...}
+// ERROR the modified template has different restriction from the base template
+
+However, there should be no error in this case as according to the table 13B (located in the section 15.8) this kind of modification is allowed.
+
+Proposal:
+The example is fine and should be kept, but the comment should be removed or replaced with: // Allowed modification as the modified template is less restrictive than the base template
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR8066-211108.docx (78,741) 08-11-2021 16:17
http://oldforge.etsi.org/mantis/file_download.php?file_id=4029&type=bug
Issue History
Date ModifiedUsernameFieldChange
05-11-2021 09:18Tomas UrbanNew Issue
08-11-2021 09:27Jens GrabowskiAssigned To => Jens Grabowski
08-11-2021 09:27Jens GrabowskiStatusnew => assigned
08-11-2021 15:17Jens GrabowskiProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
08-11-2021 16:16Jens GrabowskiNote Added: 0016011
08-11-2021 16:17Jens GrabowskiFile Added: CR8066-211108.docx
08-11-2021 16:18Jens GrabowskiNote Added: 0016012
08-11-2021 16:18Jens GrabowskiStatusassigned => resolved
08-11-2021 16:18Jens GrabowskiResolutionopen => fixed
29-11-2021 11:31Jens GrabowskiNote Added: 0016126
29-11-2021 11:31Jens GrabowskiStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0016011) +
+ Jens Grabowski    +
+ 08-11-2021 16:16    +
+ 		+ + + + +
+ Comment replaced as suggested by the reporter.
+
+
+
+ + + + + + + + + + +
+ (0016012) +
+ Jens Grabowski    +
+ 08-11-2021 16:18    +
+ 		+ + + + +
+ Typo
+
+
+
+ + + + + + + + + + +
+ (0016126) +
+ Jens Grabowski    +
+ 29-11-2021 11:31    +
+ 		+ + + + +
+ Implemented
+
+ + diff --git a/docs/mantis/CR8067.md b/docs/mantis/CR8067.md new file mode 100644 index 0000000000000000000000000000000000000000..27ace01ead13a248ff9819597db432fa14f25880 --- /dev/null +++ b/docs/mantis/CR8067.md @@ -0,0 +1,365 @@ + + + + + + + + + + + + + 0008067: Postfix value notation for templates - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008067Part 01: TTCN-3 Core LanguageTechnicalpublic08-11-2021 13:1420-12-2021 09:57
ReporterTomas Urban 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Clause Reference(s)15.10
Source (company - Author)TTF T014
Summary0008067: Postfix value notation for templates
DescriptionThe valueof operation could be extended and support the following the features:
+- it converts patterns into their textual representation: valueof (pattern "a?b") would yield "a?b"
+- it removes matching attributes if the matching symbol that contains these attributes can be converted into a value: valueof ("abc" ifpresent) would yield "abc"
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0008006closed Jens Grabowski Unnecessary Restriction 15.6.1 should be removed. 
related to 0008032closed Jens Grabowski BNF links and formatting 
Attached Filesdocx CR8067.docx (181,714) 12-11-2021 15:15
http://oldforge.etsi.org/mantis/file_download.php?file_id=4062&type=bug
docx CR8067-2.docx (208,894) 15-11-2021 07:35
http://oldforge.etsi.org/mantis/file_download.php?file_id=4065&type=bug
Issue History
Date ModifiedUsernameFieldChange
08-11-2021 13:14Tomas UrbanNew Issue
08-11-2021 13:14Tomas UrbanStatusnew => assigned
08-11-2021 13:14Tomas UrbanAssigned To => Jacob Wieland - Spirent
08-11-2021 13:14Tomas UrbanRelationship addedrelated to 0008017
08-11-2021 13:15Tomas UrbanRelationship deletedrelated to 0008017
08-11-2021 13:16Tomas UrbanRelationship addedrelated to 0008006
08-11-2021 14:07Martin HauchNote Added: 0016004
08-11-2021 15:05Jacob Wieland - SpirentNote Added: 0016006
08-11-2021 15:26Jacob Wieland - SpirentNote Added: 0016009
09-11-2021 07:13Tomas UrbanNote Added: 0016023
09-11-2021 07:13Tomas UrbanSummaryExtended functionality of the valuof operation => Postfix value notation for templates
09-11-2021 07:14Tomas UrbanNote Edited: 0016023bug_revision_view_page.php?bugnote_id=16023#r563
09-11-2021 07:14Tomas UrbanNote Edited: 0016023bug_revision_view_page.php?bugnote_id=16023#r564
12-11-2021 14:54Jacob Wieland - SpirentFile Added: CR8067.docx
12-11-2021 15:15Jacob Wieland - SpirentFile Deleted: CR8067.docx
12-11-2021 15:15Jacob Wieland - SpirentFile Added: CR8067.docx
12-11-2021 15:16Jacob Wieland - SpirentNote Added: 0016080
12-11-2021 15:16Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Tomas Urban
12-11-2021 15:16Jacob Wieland - SpirentStatusassigned => confirmed
15-11-2021 07:32Tomas UrbanFile Added: CR8067-2.docx
15-11-2021 07:34Tomas UrbanFile Deleted: CR8067-2.docx
15-11-2021 07:35Tomas UrbanFile Added: CR8067-2.docx
15-11-2021 07:39Tomas UrbanNote Added: 0016083
15-11-2021 07:39Tomas UrbanAssigned ToTomas Urban => Jacob Wieland - Spirent
15-11-2021 07:58Martin HauchNote Added: 0016084
30-11-2021 16:45Jacob Wieland - SpirentNote Added: 0016129
01-12-2021 07:39Axel RennochRelationship addedrelated to 0008032
09-12-2021 08:59Jacob Wieland - SpirentStatusconfirmed => resolved
09-12-2021 08:59Jacob Wieland - SpirentResolutionopen => fixed
09-12-2021 08:59Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Jens Grabowski
20-12-2021 09:57Jens GrabowskiNote Added: 0016148
20-12-2021 09:57Jens GrabowskiStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0016004) +
+ Martin Hauch    +
+ 08-11-2021 14:07    +
+ 		+ + + + +
+ This would change the semantic of valueof-operation. In my opinion the current version would cause an error for both examples above.
+Further question: How should regular expressions be handled, e.g.
+pattern "ab?#(1,1)"
+pattern "ab\?#(1,1)"
+
+
+
+ + + + + + + + + + +
+ (0016006) +
+ Jacob Wieland - Spirent    +
+ 08-11-2021 15:05    +
+ 		+ + + + +
+ Yes, this would change the semantics of the valueof operation for cases where at the moment it has no valid semantics, i.e. would cause a runtime-error.
+
+So, this would not cause a backwards incompatible change.
+
+In regard to your question, for the first expression the result would be "ab?#(1,1)" and for the second it would be "ab\?#(1,1)", following the idea that valueof(pattern X) == X.
+
+
+
+ + + + + + + + + + +
+ (0016009) +
+ Jacob Wieland - Spirent    +
+ 08-11-2021 15:26    +
+ 		+ + + + +
+ What is problematic with this proposal is that the current relationship that isvalue(X) == true iff valueof(X) is a valid expression is not true anymore.
+
+(but it is still true that if isvalue(X) is true, then valueof(X) == X)
+
+Alternative proposal could be to allow .value as a dotted postif notation. The value keyword is already used in other places, so this does not introduce a new keyword.
+
+It would then need to be defined for what kind of template expressions the .value operation would yield what.
+
+
+
+ + + + + + + + + + +
+ (0016023) +
+ Tomas Urban    +
+ 09-11-2021 07:13    +
(edited on: 09-11-2021 07:14)
+ 		+ + + + +
+ Jacob's proposal for using the postfix value notation for this functionality seems better than overloading the valueof function. I renamed the CR accordingly.
+
+As regards Martin's question, the conversion would just remove the pattern keyword, thus the backslash character would be kept:
+
+template charstring mw_tmp := pattern "ab\?#(1,1)";
+var charstring v_str := mw_tmp.value; // v_str will be equal to "ab\?#(1,1)" after the assignment
+
+
+
+
+
+ + + + + + + + + + +
+ (0016080) +
+ Jacob Wieland - Spirent    +
+ 12-11-2021 15:16    +
+ 		+ + + + +
+ please review
+
+
+
+ + + + + + + + + + +
+ (0016083) +
+ Tomas Urban    +
+ 15-11-2021 07:39    +
+ 		+ + + + +
+ I am fine with the proposed changes, but I added one additional rule concerning removal of matching attributes from patterns so that the following would work:
+
+var template charstring v_pattern := pattern "[abc]+" length(3..5);
+var charstring v_patternValue := v_pattern.value; // assigns "[abc]+"
+v_pattern := pattern "[abc]+" ifpresent;
+v_patternValue := v_pattern.value; // assigns "[abc]+"
+
+Please review.
+
+
+
+ + + + + + + + + + +
+ (0016084) +
+ Martin Hauch    +
+ 15-11-2021 07:58    +
+ 		+ + + + +
+ Question: Is ".value" only allowed for types charstring and universal charstring or also for other types (structured-types, union-types,other basic-types) ? Should ".value" always be the last element of an ExtendedFieldReference? If it's also allowed for structured types, I think an example might be helpful.
+
+
+
+ + + + + + + + + + +
+ (0016129) +
+ Jacob Wieland - Spirent    +
+ 30-11-2021 16:45    +
+ 		+ + + + +
+ The ifpresent removal is also applicable to other types than charstring and universal charstring, therefore, the .value can appear anywhere inside an ExtendedFieldReference, the type of the operand to .value and the type of the resulting value are the same (just template-ness is removed).
+
+
+
+ + + + + + + + + + +
+ (0016148) +
+ Jens Grabowski    +
+ 20-12-2021 09:57    +
+ 		+ + + + +
+ Implemented
+
+ + diff --git a/docs/mantis/CR8068.md b/docs/mantis/CR8068.md new file mode 100644 index 0000000000000000000000000000000000000000..40b8bc9729536deaea26f02cc6e725aebb92dcef --- /dev/null +++ b/docs/mantis/CR8068.md @@ -0,0 +1,135 @@ + + + + + + + + + + + + + 0008068: Wrong table reference in log - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008068Part 01: TTCN-3 Core LanguageEditorialpublic09-11-2021 17:3429-11-2021 11:37
ReporterGusztáv Adamis 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version4.13.1 (ongoing) 
Target VersionFixed in Version 
Clause Reference(s)19.11
Source (company - Author)     Gusztáv Adamis Ericsson
Summary0008068: Wrong table reference in log
DescriptionSemantic Description
+The log statement provides the means to write one or more log items to some logging device associated with the test control or the test component in which the statement is used. Items to be logged shall be identified by a comma separated list in the argument of the log statement. Log items may be individual language elements specified in table 20 or expressions composed of such log items.
+
+table 20 -> table 18
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR0008068.docx (172,803) 09-11-2021 17:41
http://oldforge.etsi.org/mantis/file_download.php?file_id=4045&type=bug
Issue History
Date ModifiedUsernameFieldChange
09-11-2021 17:34Gusztáv AdamisNew Issue
09-11-2021 17:38Gusztáv AdamisAssigned To => Gusztáv Adamis
09-11-2021 17:38Gusztáv AdamisStatusnew => assigned
09-11-2021 17:41Gusztáv AdamisFile Added: CR0008068.docx
09-11-2021 17:42Gusztáv AdamisNote Added: 0016047
09-11-2021 17:42Gusztáv AdamisAssigned ToGusztáv Adamis => Jens Grabowski
09-11-2021 17:42Gusztáv AdamisStatusassigned => confirmed
11-11-2021 11:39Jens GrabowskiNote Added: 0016060
11-11-2021 11:39Jens GrabowskiStatusconfirmed => resolved
11-11-2021 11:39Jens GrabowskiResolutionopen => fixed
29-11-2021 11:37Jens GrabowskiNote Added: 0016127
29-11-2021 11:37Jens GrabowskiStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0016047) +
+ Gusztáv Adamis    +
+ 09-11-2021 17:42    +
+ 		+ + + + +
+ Typo, @Jens pls check it
+
+
+
+ + + + + + + + + + +
+ (0016060) +
+ Jens Grabowski    +
+ 11-11-2021 11:39    +
+ 		+ + + + +
+ typo
+
+
+
+ + + + + + + + + + +
+ (0016127) +
+ Jens Grabowski    +
+ 29-11-2021 11:37    +
+ 		+ + + + +
+ implemented
+
+ + diff --git a/docs/mantis/CR8069.md b/docs/mantis/CR8069.md new file mode 100644 index 0000000000000000000000000000000000000000..4c0b82da159e232ad782e7f280131ea5873cb031 --- /dev/null +++ b/docs/mantis/CR8069.md @@ -0,0 +1,478 @@ + + + + + + + + + + + + + 0008069: Range-based for loop - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008069Part 01: TTCN-3 Core LanguageNew Featurepublic06-12-2021 15:0403-01-2023 12:44
ReporterMatthias Simon 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Clause Reference(s)19.4 The For statement
Source (company - Author)Matthias Simon - Nokia
Summary0008069: Range-based for loop
DescriptionSUMMARY
+
+Allow range clause as a second form of for-loops, to improve developer convenience and readability of TTCN-3 source code.
+
+
+MOTIVATION
+
+Many programming languages (C++, Python, Go, Perl, Rust, ...) provide ranged loops as a concise and convenient alternative to the classic C-style loop.
+Most developers would probably benefit from having this kind of loop in TTCN-3, as well:
+The Nokia TTCN-3 code base for 4G and 5G C-Plane contains over 14000 for-loops; 99 percent could be simplified into ranged loops. Other TTCN-3 code bases show a similar picture [1].
+
+A key idea of TTCN-3 is having the look and feel of a regular programming language, without distracting complexity [2]. A ranged for-loop reduces complexity.
+
+
+PROPOSAL
+
+**Syntactical Structure**
+
+    for "(" (VarInstance|ValueRef) ":=" "range" Expression ")" StatementBlock
+
+
+**Semantic Description**
+
+A _for_ statement with a range clause iterates through all entries of a _record of_, _set of_, _array_, _map_ type or string type (bitstring, hextstring, octettstring, charstring, universal charstring). For each entry it assigns an iteration value to corresponding iteration variable and then executed the statement block.
+
+Iteration values must be compatible with the iteration variable. Rules for accessing single elements apply (15.6, ...).
+
+The iteration order over maps is not specified and is not guaranteed to be the same from one iteration to the next.
+
+The expression on the right in the "range" clause is evaluated once before beginning the loop.
+
+
+**Examples**
+
+    // Iterating over an array variable
+    var charstring myArray[3] := { "foo", "bar", "baz" }
+    for (var charstring s := range myArray) {
+        // ...
+    }
+
+    // Iterating over maps
+    var map from charstring to boolean visited := {
+        ["A"] := true,
+        ["B"] := true,
+        ["C"] := true,
+    }
+
+    // Use "from" to iterate over map keys
+    for (var charstring k := range visited.from) {
+        // ...
+    }
+
+    // Use "to" to iterate over map values
+    for (var charstring v := range visited.to) {
+        // ...
+    }
+
+    // Iterating over expressions and literal values
+    for (var integer x := range {1, 1, 2} & {3, 5, 8}) {
+        // ...
+    }
+
+    // Modifying length has no impact on iteration,
+    // because range expression is evaluated only once.
+    type record of integer RoI;
+    var RoI ints := {2, 4}
+    for (var integer i := range ints) {
+        ints[lengthof(ints)] = i*3 // append
+    }
+    log(int) // {2, 4, 6, 12}
+
+    // Iterating over templates could use some examples
+
+OPEN QUESTIONS
+
+**Keywords**
+
+It might be a good idea to reuse existing keywords, instead of adding a new one. Some suggestions are:
+
+* "all from": for (var integer i := all from myArray)
+* "repeat": for (var integer i := repeat myArray)
+* "select": for (var integer i := select myArray)
+* no keyword: for (var integer i := myArray)
+
+
+**Expanding Values**
+
+Expanding value lists in range loops could be an interesting feature worth exploring:
+
+    // Example 1:
+    for (var integer i := range (0..2, 4, 6) {
+        // this loop will repeat five times: i:= 0, 1, 2, 4, 6
+    }
+
+    // Example 2: generating permutations
+    for (var RoI r := range permutation({1,2,3}) {
+        // this loop will repeat six time: r := {1, 2, 3}, {2, 1, 3}, {2, 3, 1}, ...
+    }
+
+
+
+REFERENCES
+
+[1](https://github.com/osmocom/osmo-ttcn3-hacks [^])
+[2](http://www.ttcn-3.org/index.php/about/why-use-ttcn3 [^])
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR8069.docx (117,554) 11-12-2022 09:06
http://oldforge.etsi.org/mantis/file_download.php?file_id=4091&type=bug
docx CR8069(1).docx (117,436) 12-12-2022 14:23
http://oldforge.etsi.org/mantis/file_download.php?file_id=4097&type=bug
docx CR8069(2).docx (136,085) 13-12-2022 15:11
http://oldforge.etsi.org/mantis/file_download.php?file_id=4098&type=bug
Issue History
Date ModifiedUsernameFieldChange
06-12-2021 15:04Matthias SimonNew Issue
09-12-2021 09:02Jacob Wieland - SpirentNote Added: 0016145
09-12-2021 12:51Matthias SimonNote Added: 0016147
16-08-2022 14:17Jens GrabowskiProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
17-08-2022 11:31Jens GrabowskiNote Added: 0016236
17-08-2022 11:31Jens GrabowskiAssigned To => Matthias Simon
17-08-2022 11:31Jens GrabowskiStatusnew => assigned
11-12-2022 09:06Matthias SimonFile Added: CR8069.docx
11-12-2022 09:08Matthias SimonNote Added: 0016373
11-12-2022 09:08Matthias SimonNote Added: 0016374
11-12-2022 09:08Matthias SimonAssigned ToMatthias Simon => Axel Rennoch
11-12-2022 09:08Matthias SimonStatusassigned => confirmed
11-12-2022 09:08Matthias SimonNote Deleted: 0016373
11-12-2022 09:25Matthias SimonNote Added: 0016375
12-12-2022 12:47Axel RennochNote Added: 0016384
12-12-2022 12:47Axel RennochAssigned ToAxel Rennoch => Matthias Simon
12-12-2022 12:47Axel RennochStatusconfirmed => assigned
12-12-2022 14:23Matthias SimonNote Added: 0016386
12-12-2022 14:23Matthias SimonFile Added: CR8069(1).docx
12-12-2022 14:24Matthias SimonNote Added: 0016387
12-12-2022 14:24Matthias SimonAssigned ToMatthias Simon => Axel Rennoch
12-12-2022 14:24Matthias SimonStatusassigned => confirmed
12-12-2022 14:25Matthias SimonNote Deleted: 0016386
13-12-2022 15:11Axel RennochFile Added: CR8069(2).docx
13-12-2022 15:13Axel RennochNote Added: 0016389
13-12-2022 15:13Axel RennochStatusconfirmed => resolved
13-12-2022 15:13Axel RennochResolutionopen => fixed
13-12-2022 15:13Axel RennochAssigned ToAxel Rennoch => Jens Grabowski
03-01-2023 12:44Jens GrabowskiNote Added: 0016448
03-01-2023 12:44Jens GrabowskiStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0016145) +
+ Jacob Wieland - Spirent    +
+ 09-12-2021 09:02    +
+ 		+ + + + +
+ how about
+
+for (var <type> <name> from <record of/set of/array>) { ... }
+
+
+
+ + + + + + + + + + +
+ (0016147) +
+ Matthias Simon    +
+ 09-12-2021 12:51    +
+ 		+ + + + +
+ What about:
+
+    for (var <type> <name> in <record of/set of/array>) { ... }
+
+
+The "in" form looks a little more python-ish.
+I am missing ":=", though. Maybe it's just habit, but:
+
+        for (var Rec r := all from myArray) { ... }
+
+looks more familiar than:
+
+        for (var Rec r from myArray) { ...}
+
+
+
+One (minor) advantage of keeping the ":=" is less syntactic variation.
+
+
+
+ + + + + + + + + + +
+ (0016236) +
+ Jens Grabowski    +
+ 17-08-2022 11:31    +
+ 		+ + + + +
+ TTF discussion: Useful feature. Details to be studied.
+
+
+
+ + + + + + + + + + +
+ (0016374) +
+ Matthias Simon    +
+ 11-12-2022 09:08    +
+ 		+ + + + +
+ The first version of the resolution uploaded. Please check and let me know what should be changed or added.
+
+
+
+ + + + + + + + + + +
+ (0016375) +
+ Matthias Simon    +
+ 11-12-2022 09:25    +
+ 		+ + + + +
+ NOTE: There's an issue with iterating template strings. For example:
+
+    template hexstring t := '1*D'H;
+    for (var x in t) {
+        log(x);
+    }
+
+
+Above code could be translated to:
+
+    _r := t;
+    _l := lengthof(_r) // <-- here's the problem
+    for (var integer _i := 0; _i<_l; i++) {
+        var x := _r[_i];
+        log(x);
+    }
+
+Problem: We cannot retrieve the length of template strings for the iteration, because lengthof('1*D'H) causes an error.
+
+
+
+ + + + + + + + + + +
+ (0016384) +
+ Axel Rennoch    +
+ 12-12-2022 12:47    +
+ 		+ + + + +
+ It would be better to separate the different loop forms using different subsections 19.4.1 and 19.4.2.
+
+According to the reported note #16375 the solution contains an issue that needs to be solved in the solution first.
+
+
+
+ + + + + + + + + + +
+ (0016387) +
+ Matthias Simon    +
+ 12-12-2022 14:24    +
+ 		+ + + + +
+ Updated version using different subsections.
+
+The lengthof issue is independent of this CR and can be solved in an new CR independently: http://oldforge.etsi.org/mantis/view.php?id=8155 [^]
+
+
+
+ + + + + + + + + + +
+ (0016389) +
+ Axel Rennoch    +
+ 13-12-2022 15:13    +
+ 		+ + + + +
+ The proposed solution file looks right and just has been updated a bit for editorial issues.
+
+
+
+ + + + + + + + + + +
+ (0016448) +
+ Jens Grabowski    +
+ 03-01-2023 12:44    +
+ 		+ + + + +
+ Implemented as proposed
+
+ + diff --git a/docs/mantis/CR8070.md b/docs/mantis/CR8070.md new file mode 100644 index 0000000000000000000000000000000000000000..7ec60fd3b9a8dc582682850ae8295e95b46f0be2 --- /dev/null +++ b/docs/mantis/CR8070.md @@ -0,0 +1,284 @@ + + + + + + + + + + + + + 0008070: If-else statements with initializers - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008070Part 01: TTCN-3 Core LanguageNew Featurepublic06-12-2021 16:0103-01-2023 11:50
ReporterMatthias Simon 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Clause Reference(s)19.2 The If-else statement
Source (company - Author)Matthias Simon - Nokia
Summary0008070: If-else statements with initializers
DescriptionSUMMARY
+
+Allow initializers in conditional statements, similar to for loops: if (init-statement; condition). This statement simplifies common code patterns and helps developers keep scopes tight.
+
+
+MOTIVATION
+
+In many cases we check a return value and perform conditional operations on this value. TTCN-3 code looks like this usually:
+
+    type record of charstring Users
+    var Users ret := getUsers()
+    if (lengthof(ret) > 0) {
+        // do something with "users"
+    }
+
+
+There are two issues, because the variable "ret" leaks into surrounding scope:
+
+1) You must take extra care not to access variables outside intended scope:
+
+    type record of charstring Users
+    var Users ret := getUsers()
+    if (lengthof(ret) > 0) {
+        // do something with "users"
+    }
+
+    var Users users = ret;
+    log(users[0]) // ERROR: index out of bounds, or worse.
+
+
+2) You cannot reuse variable "ret" with different types in the same scope anymore:
+
+    var Users ret := getUsers()
+    if (lengthof(ret) > 0) {
+        // ...
+    }
+
+    var float ret := rnd() // ERROR: "ret" already defined.
+    if (ret > 0.5) {
+        // ...
+    }
+
+
+PROPOSAL
+
+**Semantic Description**
+
+    if "(" [ VarInstance ";"] BooleanExpression ")" StatementBlock
+
+The branching of the control flow is decided upon the value of the Boolean expressions - the condition. A statement
+block - and only one - will be executed, if its condition evaluates to true.
+
+An optional variable (or constant) can be declared and initialized before being used in the if statement. The scope of the variable is limited to the statement block, i.e. it is only visible inside the statement block.
+
+
+**Examples**
+
+    // Example 1: improved getUsers
+    type record of charstring Users
+    if (var Users ret := getUsers(); lengthof(ret) > 0 ) {
+        // do something with "users"
+    }
+
+    // Example 2: else-if statements
+    if (var charstring ret := hostname(); ret == "localhost") {
+        // do something with ret (charstring)
+    } else if (var float ret := rnd(); rnd > 0.4) {
+        // do something with ret (float)
+    } else {
+        // "ret" variable is not accessible in this scope
+    }
+
+
+OPEN QUESTIONS
+
+Should we allow initializers in switch-statements as well?
+
+    switch (var Person p := createPerson(); p.Name)
+    {
+        case ("Alice") { /* ... */ }
+        case ("Bob") { /* ... */ }
+        case else { /* ... */ }
+    }
+
+What are the scopes of variable "p".
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR8070.docx (118,037) 11-12-2022 12:26
http://oldforge.etsi.org/mantis/file_download.php?file_id=4092&type=bug
Issue History
Date ModifiedUsernameFieldChange
06-12-2021 16:01Matthias SimonNew Issue
09-12-2021 09:07Jacob Wieland - SpirentNote Added: 0016146
16-08-2022 14:17Jens GrabowskiProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
17-08-2022 11:14Jens GrabowskiAssigned To => Matthias Simon
17-08-2022 11:14Jens GrabowskiStatusnew => assigned
17-08-2022 11:17Jens GrabowskiNote Added: 0016235
11-12-2022 12:26Matthias SimonFile Added: CR8070.docx
11-12-2022 12:26Matthias SimonNote Added: 0016376
11-12-2022 12:26Matthias SimonAssigned ToMatthias Simon => Axel Rennoch
11-12-2022 12:26Matthias SimonStatusassigned => confirmed
12-12-2022 12:31Axel RennochNote Added: 0016383
12-12-2022 12:31Axel RennochStatusconfirmed => resolved
12-12-2022 12:31Axel RennochResolutionopen => fixed
12-12-2022 12:31Axel RennochAssigned ToAxel Rennoch => Jens Grabowski
03-01-2023 11:50Jens GrabowskiNote Added: 0016446
03-01-2023 11:50Jens GrabowskiStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0016146) +
+ Jacob Wieland - Spirent    +
+ 09-12-2021 09:07    +
+ 		+ + + + +
+ I support this proposal. It could be a number of declarations, too.
+
+
+
+ + + + + + + + + + +
+ (0016235) +
+ Jens Grabowski    +
+ 17-08-2022 11:17    +
+ 		+ + + + +
+ TTF dicussion: Scope of variables needs to be studied. If we go for this approach, variables may be added to all constructs that define their own scope unit.
+
+
+
+ + + + + + + + + + +
+ (0016376) +
+ Matthias Simon    +
+ 11-12-2022 12:26    +
+ 		+ + + + +
+ The first version of the resolution uploaded. Please check and let me know what should be changed or added.
+
+
+
+ + + + + + + + + + +
+ (0016383) +
+ Axel Rennoch    +
+ 12-12-2022 12:31    +
+ 		+ + + + +
+ The solution files looks correct.
+
+
+
+ + + + + + + + + + +
+ (0016446) +
+ Jens Grabowski    +
+ 03-01-2023 11:50    +
+ 		+ + + + +
+ Implemented as proposed.
+
+ + diff --git a/docs/mantis/CR8078.md b/docs/mantis/CR8078.md new file mode 100644 index 0000000000000000000000000000000000000000..48fabf07533b36dcd0854a2a2b81da2b28942dc7 --- /dev/null +++ b/docs/mantis/CR8078.md @@ -0,0 +1,179 @@ + + + + + + + + + + + + + 0008078: Incorrect example for present operation (Remove "causes error" comment) - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008078Part 01: TTCN-3 Core LanguageEditorialpublic07-02-2022 12:0004-01-2023 09:27
Reporterbarakatr 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionNext version (to be decided)Fixed in Version 
Clause Reference(s)15.13 of ETSI ES201 873-1V4.13.1(2021-08)
Source (company - Author)     Fraunhofer FOKUS
Summary0008078: Incorrect example for present operation (Remove "causes error" comment)
DescriptionIn Section 15.13 of ETSI ES201 873-1V4.13.1(2021-08):
+
+In the examples listed for the present operator, the following example is given as producing an error:
+
+
+template ExampleType m_originalAny := ?;
+template(present) ExampleType m_targetAny := present(m_originalAny); // causes error
+
+
+The presents operator is specified as follow:
+"A template with the present restriction and with the same content as the operand, if the operand fulfils conditions of the present template"
+
+The above example does not violate the present operator specification because the operand fulfils the conditions of the present template.
+
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR-8078-Res-221107.docx (79,674) 07-11-2022 14:11
http://oldforge.etsi.org/mantis/file_download.php?file_id=4070&type=bug
Issue History
Date ModifiedUsernameFieldChange
07-02-2022 12:00barakatrNew Issue
07-02-2022 12:45Axel RennochCategoryNew Feature => Editorial
07-02-2022 12:45Axel RennochTarget Version => Next version (to be decided)
07-02-2022 12:45Axel RennochSummaryIncorrect example for present operation => Incorrect example for present operation (Remove "causes error" comment)
07-02-2022 12:45Axel RennochSteps to Reproduce Updatedbug_revision_view_page.php?rev_id=581#r581
17-08-2022 11:04Jens GrabowskiNote Added: 0016234
17-08-2022 11:04Jens GrabowskiAssigned To => Jens Grabowski
17-08-2022 11:04Jens GrabowskiStatusnew => assigned
07-11-2022 14:11Jens GrabowskiFile Added: CR-8078-Res-221107.docx
07-11-2022 14:12Jens GrabowskiNote Added: 0016265
07-11-2022 14:12Jens GrabowskiNote Added: 0016266
07-11-2022 14:12Jens GrabowskiStatusassigned => resolved
07-11-2022 14:12Jens GrabowskiResolutionopen => fixed
04-01-2023 09:27Jens GrabowskiNote Added: 0016453
04-01-2023 09:27Jens GrabowskiStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0016234) +
+ Jens Grabowski    +
+ 17-08-2022 11:04    +
+ 		+ + + + +
+ TTF discussion: accepted
+
+
+
+ + + + + + + + + + +
+ (0016265) +
+ Jens Grabowski    +
+ 07-11-2022 14:12    +
+ 		+ + + + +
+ Resolved as proposed by reporter.
+
+
+
+ + + + + + + + + + +
+ (0016266) +
+ Jens Grabowski    +
+ 07-11-2022 14:12    +
+ 		+ + + + +
+ Resolved as proposed by reporter.
+
+
+
+ + + + + + + + + + +
+ (0016453) +
+ Jens Grabowski    +
+ 04-01-2023 09:27    +
+ 		+ + + + +
+ Implemented as proposed.
+
+ + diff --git a/docs/mantis/CR8090.md b/docs/mantis/CR8090.md new file mode 100644 index 0000000000000000000000000000000000000000..23c9b591397f1dac2e403c911ab80e1e0149df6c --- /dev/null +++ b/docs/mantis/CR8090.md @@ -0,0 +1,249 @@ + + + + + + + + + + + + + 0008090: Deprecate `lengthof` in favor of `length` - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008090Part 01: TTCN-3 Core LanguageNew Featurepublic23-03-2022 15:4326-01-2024 16:24
ReporterMatthias Simon 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionwon't fix 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Clause Reference(s)C.2.1 Length of strings and lists
Source (company - Author)Nokia - Matthias Simon
Summary0008090: Deprecate `lengthof` in favor of `length`
DescriptionI often accidentally use keyword `length` instead of predefined function `lengthof`. The result is an irritating syntax error ala `unexpected length, expecting expression`.
+
+This mistake is easy to make. Hence I propose to rename predefined function `lengthof` to `length`. And begin deprecation process for the `lengthof` keyword.
+
+This would become valid TTCN-3 code:
+
+    for (i := 0; i < length('1100101'b); i := i + 1) { /* ... */ }
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
23-03-2022 15:43Matthias SimonNew Issue
16-08-2022 14:17Jens GrabowskiProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
17-08-2022 11:02Jens GrabowskiNote Added: 0016233
17-08-2022 11:02Jens GrabowskiAssigned To => Tomas Urban
17-08-2022 11:02Jens GrabowskiStatusnew => assigned
09-11-2022 10:42Tomas UrbanNote Added: 0016272
09-11-2022 11:56Matthias SimonNote Added: 0016277
09-11-2022 12:35Jens GrabowskiNote Added: 0016278
09-11-2022 12:36Jens GrabowskiAssigned ToTomas Urban => Jens Grabowski
09-11-2023 11:24Jens GrabowskiNote Added: 0016566
09-11-2023 11:24Jens GrabowskiStatusassigned => closed
09-11-2023 11:24Jens GrabowskiResolutionopen => won't fix
26-01-2024 16:24Olivier GenoudNote Added: 0016604
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0016233) +
+ Jens Grabowski    +
+ 17-08-2022 11:02    +
+ 		+ + + + +
+ TTF discussion: Similar argumentation as for operators. Needs to be studied. There might be a potential grammer conflict.
+
+
+
+ + + + + + + + + + +
+ (0016272) +
+ Tomas Urban    +
+ 09-11-2022 10:42    +
+ 		+ + + + +
+ Input for a discussion:
+The proposed change is technically possible, there are no grammar conflicts. Unfortunately it is not so straightforward. As "length" is one of the keywords, it is not possible to keep this statement in the category of predefined functions and it has to be changed to a unary expression operator. There were similar changes of this type in the past (e.g. isvalue), but the reasons were different - these function calls required specific handling for parameters which differed from standard function calls. This time we are dealing just with naming.
+There are two minor drawbacks when changing a predefined function into an operator:
+1. The function can no-longer be used as an standalone statement (irrelevant in case of lengthof as a standalone lengthof call does nothing).
+2. Impossibility to use function pointers with lengthof (this functionality is specified in an extension package, extremely unlikely option)
+I can prepare a proposal but I need an approval of the TTF for this kind of change.
+
+
+
+ + + + + + + + + + +
+ (0016277) +
+ Matthias Simon    +
+ 09-11-2022 11:56    +
+ 		+ + + + +
+ > it is not possible to keep this statement in the category of predefined functions
+
+Why can't predefined functions with a reserved name be a statement?
+I would have excepted the situation is similar to predefined type or builtin functions like `log` oder `match`.
+
+
+
+ + + + + + + + + + +
+ (0016278) +
+ Jens Grabowski    +
+ 09-11-2022 12:35    +
+ 		+ + + + +
+ TTF discussion: CR is postponed and should become part of a larger discussion about the further development of the standard.
+
+
+
+ + + + + + + + + + +
+ (0016566) +
+ Jens Grabowski    +
+ 09-11-2023 11:24    +
+ 		+ + + + +
+ CR is postponed and should become part of a larger discussion. CR will become part of CR 8180.
+
+
+
+ + + + + + + + + + +
+ (0016604) +
+ Olivier Genoud    +
+ 26-01-2024 16:24    +
+ 		+ + + + +
+ This change is non-backwards compatible, so it would need a grace period in which "lengthof" still needs to be supported by TTCN-3 tools.
+On the other hand, there seems to be no technical benefit, "lengthof" and "length" are different things, so why shall they have the same name?
+=> TF160 does not support this proposal.
+
+ + diff --git a/docs/mantis/CR8091.md b/docs/mantis/CR8091.md new file mode 100644 index 0000000000000000000000000000000000000000..6dcaf7001ae5b0bb61f9593f9e006e0862a8242b --- /dev/null +++ b/docs/mantis/CR8091.md @@ -0,0 +1,333 @@ + + + + + + + + + + + + + 0008091: Add the not-implemented-function `???` - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008091Part 01: TTCN-3 Core LanguageNew Featurepublic23-03-2022 16:1504-01-2023 10:52
ReporterMatthias Simon 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Clause Reference(s)C 6.4 -- The not implemented function `???`
Source (company - Author)Nokia - Matthias Simon
Summary0008091: Add the not-implemented-function `???`
DescriptionC 6.4 -- The not-implemented function `???`
+
+    ??? [return any]
+
+The not-implemented function `???` is an expression and can be used for code that remain to be implemented.
+
+Only when executed `???` shall cause a runtime error to indicate not yet implemented code.
+
+
+EXAMPLES:
+
+    function double(integer p := ???) return integer { return p*2)
+    control {
+        log(double(8)); // Is okay, because default value for p has not been evaluated.
+        log(double()); // Runtime error to signal the user execution of not implemented code.
+    }
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdoc CR8091.doc (116,408) 11-11-2022 08:33
http://oldforge.etsi.org/mantis/file_download.php?file_id=4077&type=bug
doc CR8091(2).doc (116,610) 06-12-2022 08:51
http://oldforge.etsi.org/mantis/file_download.php?file_id=4083&type=bug
docx CR8091(3).docx (147,395) 06-12-2022 10:21
http://oldforge.etsi.org/mantis/file_download.php?file_id=4084&type=bug
Issue History
Date ModifiedUsernameFieldChange
23-03-2022 16:15Matthias SimonNew Issue
16-08-2022 14:17Jens GrabowskiProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
17-08-2022 10:44Jens GrabowskiProjectPart 01: TTCN-3 Core Language => TTCN-3 Change Requests
17-08-2022 10:54Jens GrabowskiNote Added: 0016232
17-08-2022 10:54Jens GrabowskiAssigned To => Matthias Simon
17-08-2022 10:54Jens GrabowskiStatusnew => assigned
10-11-2022 22:29Matthias SimonFile Added: CR8091.doc
10-11-2022 22:30Matthias SimonNote Added: 0016302
10-11-2022 22:30Matthias SimonAssigned ToMatthias Simon => Tomas Urban
10-11-2022 22:30Matthias SimonStatusassigned => confirmed
11-11-2022 08:33Matthias SimonFile Deleted: CR8091.doc
11-11-2022 08:33Matthias SimonFile Added: CR8091.doc
11-11-2022 08:34Matthias SimonNote Added: 0016306
06-12-2022 08:16Tomas UrbanAssigned ToTomas Urban => Matthias Simon
06-12-2022 08:16Tomas UrbanStatusconfirmed => assigned
06-12-2022 08:16Tomas UrbanNote Added: 0016318
06-12-2022 08:32Matthias SimonNote Added: 0016319
06-12-2022 08:51Matthias SimonFile Added: CR8091(2).doc
06-12-2022 08:52Matthias SimonAssigned ToMatthias Simon =>
06-12-2022 08:52Matthias SimonAssigned To => Tomas Urban
06-12-2022 10:21Tomas UrbanFile Added: CR8091(3).docx
06-12-2022 10:23Tomas UrbanNote Added: 0016357
06-12-2022 10:23Tomas UrbanAssigned ToTomas Urban => Jens Grabowski
06-12-2022 10:23Tomas UrbanStatusassigned => confirmed
16-12-2022 09:26Jens GrabowskiProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
16-12-2022 09:26Jens GrabowskiNote Added: 0016427
16-12-2022 09:26Jens GrabowskiStatusconfirmed => resolved
16-12-2022 09:26Jens GrabowskiResolutionopen => fixed
04-01-2023 10:52Jens GrabowskiNote Added: 0016460
04-01-2023 10:52Jens GrabowskiStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0016232) +
+ Jens Grabowski    +
+ 17-08-2022 10:54    +
+ 		+ + + + +
+ TTF discussion: Usefull feature for TTCN-3 development. Proposal to be provided.
+
+
+
+ + + + + + + + + + +
+ (0016302) +
+ Matthias Simon    +
+ 10-11-2022 22:30    +
+ 		+ + + + +
+ Proposal has been attached. Please review.
+
+
+
+ + + + + + + + + + +
+ (0016306) +
+ Matthias Simon    +
+ 11-11-2022 08:34    +
+ 		+ + + + +
+ Note: This CR requires a new TCI operation. I will provide the missing document shorty.
+
+
+
+ + + + + + + + + + +
+ (0016318) +
+ Tomas Urban    +
+ 06-12-2022 08:16    +
+ 		+ + + + +
+ The rules are clear, I found no errors except incorrect quote type in the added BNF rules.
+
+However, there are two topics for further discussion:
+
+1. I think the symbol shall not be added as a predefined function to the section C, but as a specific function-related notation to the section 16.
+
+2. Since the feature is intended for interactive development, It would be beneficial to add have an optional string parameter that would provide some context, e.g.: ??? ("TODO: XYZ unit start-up")
+
+
+
+ + + + + + + + + + +
+ (0016319) +
+ Matthias Simon    +
+ 06-12-2022 08:32    +
+ 		+ + + + +
+ > [...] the symbol shall not be added as a predefined function [...]
+
+Fine with me.
+
+> [...] add an optional string parameter
+
+Brilliant!
+
+
+FYI: I will drop the new TCI operation, because it's difficult to specify (slightly out of scope).
+
+
+
+ + + + + + + + + + +
+ (0016357) +
+ Tomas Urban    +
+ 06-12-2022 10:23    +
+ 		+ + + + +
+ I am fine with the provided resolution. I only make a couple of cosmetic changes.
+Jens, could you please check it as well?
+
+
+
+ + + + + + + + + + +
+ (0016427) +
+ Jens Grabowski    +
+ 16-12-2022 09:26    +
+ 		+ + + + +
+ ok
+
+
+
+ + + + + + + + + + +
+ (0016460) +
+ Jens Grabowski    +
+ 04-01-2023 10:52    +
+ 		+ + + + +
+ Implemented according to resolution in attached file.
+
+ + diff --git a/docs/mantis/CR8093.md b/docs/mantis/CR8093.md new file mode 100644 index 0000000000000000000000000000000000000000..32d0ba1e4f54804d381eb1bd212045f6f33454a1 --- /dev/null +++ b/docs/mantis/CR8093.md @@ -0,0 +1,132 @@ + + + + + + + + + + + + + 0008093: object not listed as a keyword in table A.5 - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008093Part 01: TTCN-3 Core LanguageTechnicalpublic05-04-2022 08:4004-01-2023 11:07
ReporterTomas Urban 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version4.12.1 (published 2020-05) 
Target VersionFixed in Version 
Clause Reference(s)A.1.5.0
Source (company - Author)Elvior OÜ
Summary0008093: object not listed as a keyword in table A.5
DescriptionThe table A.5 doesn't contain the "object" keyword from ES 203 790 (Object-Oriented Features).
+Please note that this keyword is used in JSON structures.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0008181closed  Part 11: Using JSON with TTCN-3 object used as an identifier 
Attached Filesdocx CR-8093-Res-221216.docx (85,255) 16-12-2022 12:17
http://oldforge.etsi.org/mantis/file_download.php?file_id=4102&type=bug
Issue History
Date ModifiedUsernameFieldChange
05-04-2022 08:40Tomas UrbanNew Issue
16-08-2022 13:39Jens GrabowskiAssigned To => Jens Grabowski
16-08-2022 13:39Jens GrabowskiStatusnew => assigned
16-12-2022 12:17Jens GrabowskiFile Added: CR-8093-Res-221216.docx
16-12-2022 12:18Jens GrabowskiStatusassigned => confirmed
20-12-2022 12:32Jens GrabowskiNote Added: 0016439
20-12-2022 12:34Jens GrabowskiNote Added: 0016440
20-12-2022 12:34Jens GrabowskiStatusconfirmed => resolved
20-12-2022 12:34Jens GrabowskiResolutionopen => fixed
04-01-2023 11:03Jens GrabowskiRelationship addedrelated to 0008181
04-01-2023 11:07Jens GrabowskiNote Added: 0016462
04-01-2023 11:07Jens GrabowskiStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0016439) +
+ Jens Grabowski    +
+ 20-12-2022 12:32    +
+ 		+ + + + +
+ TTF discussion: The addition of the keyword "object" in the Core language leads to inconsistencies with JSON. A new CR regarding changes in part 11 is required. The required change will be backwards incompatible.
+
+
+
+ + + + + + + + + + +
+ (0016440) +
+ Jens Grabowski    +
+ 20-12-2022 12:34    +
+ 		+ + + + +
+ To be included. New CR for part 11 will be issued.
+
+
+
+ + + + + + + + + + +
+ (0016462) +
+ Jens Grabowski    +
+ 04-01-2023 11:07    +
+ 		+ + + + +
+ object added as reserved word. The JSON issue regarding the reserved word object will be addressed in CR 8181
+
+ + diff --git a/docs/mantis/CR8094.md b/docs/mantis/CR8094.md new file mode 100644 index 0000000000000000000000000000000000000000..73198c6c1101c4b7d467733a40e9f469ce1fde5d --- /dev/null +++ b/docs/mantis/CR8094.md @@ -0,0 +1,254 @@ + + + + + + + + + + + + + 0008094: Provide a canonical style for source code layout - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008094Part 01: TTCN-3 Core LanguageNew Featurepublic04-05-2022 09:0316-12-2024 11:11
ReporterMatthias Simon 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusresolvedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Clause Reference(s)none so far
Source (company - Author)Nokia - Matthias Simon
Summary0008094: Provide a canonical style for source code layout
DescriptionA clear recommendation how TTCN-3 source code should be formatted would be beneficial:
+
+* Tool-vendors had a solid ground to implement automatic formatter tools.
+
+* Less time would be spent on "bike-shedding" discussions (e.g. tabs vs. spaces).
+
+* A canonical style improves readability of TTCN-3 source code (e.g. of conformance tests, code examples, ...).
+
+
+
+
+
+
+
+
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
04-05-2022 09:03Matthias SimonNew Issue
16-08-2022 13:37Jens GrabowskiNote Added: 0016226
16-08-2022 13:38Jens GrabowskiAssigned To => Jens Grabowski
16-08-2022 13:38Jens GrabowskiStatusnew => assigned
16-08-2022 14:13Jens GrabowskiProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
11-11-2022 13:09Jens GrabowskiNote Added: 0016312
11-11-2022 15:12Matthias SimonNote Added: 0016313
26-01-2024 16:25Olivier GenoudNote Added: 0016605
19-11-2024 13:47Jens GrabowskiNote Added: 0016694
16-12-2024 11:11Jens GrabowskiNote Added: 0016719
16-12-2024 11:11Jens GrabowskiStatusassigned => resolved
16-12-2024 11:11Jens GrabowskiResolutionopen => fixed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0016226) +
+ Jens Grabowski    +
+ 16-08-2022 13:37    +
+ 		+ + + + +
+ TTF discussion: Nice to have, possibly these guidelines may be put into an annex (style guide) together with valuable compiler switches.
+
+
+
+ + + + + + + + + + +
+ (0016312) +
+ Jens Grabowski    +
+ 11-11-2022 13:09    +
+ 		+ + + + +
+ TTF discussion: Code style should not become part of the standard. Maybe guidelines should be added to the TTCN-3 Web pages in the same manner as the already existing naming conventions.
+
+
+
+ + + + + + + + + + +
+ (0016313) +
+ Matthias Simon    +
+ 11-11-2022 15:12    +
+ 		+ + + + +
+ I might have put my CR into the wrong category/project. It is not my intention to standardize a specific code style.
+
+Adding the recommendations to the web pages is a good idea, clearly.
+
+We agree on recommending a preferred/canonical code style, but details about what style and where to put it are still to be figured out. Correct?
+
+So the next step would be creating a recommendation draft?
+
+
+
+ + + + + + + + + + +
+ (0016605) +
+ Olivier Genoud    +
+ 26-01-2024 16:25    +
+ 		+ + + + +
+ Core language shall not be mixed up with coding style guides and in general the coding style shall be project specific. Nevertheless, a configurable 'beautifier' tool could be helpful, e.g. to achieve a common indentation.
+
+
+
+ + + + + + + + + + +
+ (0016694) +
+ Jens Grabowski    +
+ 19-11-2024 13:47    +
+ 		+ + + + +
+ At least TTCN-3 standards should follow the same style rules and name conventions.
+
+
+
+ + + + + + + + + + +
+ (0016719) +
+ Jens Grabowski    +
+ 16-12-2024 11:11    +
+ 		+ + + + +
+ Dicussion continued in Gitlab
+
+ + diff --git a/docs/mantis/CR8095.md b/docs/mantis/CR8095.md new file mode 100644 index 0000000000000000000000000000000000000000..ddfec17bc2c64a92541ba999b88a007f5606cb45 --- /dev/null +++ b/docs/mantis/CR8095.md @@ -0,0 +1,176 @@ + + + + + + + + + + + + + 0008095: Provide a TTCN-3 specification for TCI and TRI - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008095Part 06: TTCN-3 Control InterfaceNew Featurepublic10-05-2022 08:3716-12-2024 13:04
ReporterMatthias Simon 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusresolvedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Clause Reference(s)n/a
Source (company - Author)Nokia - Matthias Simon
Summary0008095: Provide a TTCN-3 specification for TCI and TRI
DescriptionSUMMARY
+
+Provide specifications using TTCN-3 for TCI and TRI.
+
+
+RATIONAL
+
+Various TTCN-3 deliverables provide specifications per IDL (interface description language). IDL tools however are slowly becoming obsolete and do not provide good support for modern languages or other RPC stacks (gRPC, Thrift, JSONRPC, ...).
+
+A specification using TTCN-3 mitigates this dependency to third-party technologies.
+
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
10-05-2022 08:37Matthias SimonNew Issue
16-08-2022 13:20Jens GrabowskiProjectTTCN-3 Change Requests => Part 06: TTCN-3 Control Interface
16-08-2022 13:27Jens GrabowskiNote Added: 0016224
16-08-2022 13:28Jens GrabowskiNote Added: 0016225
16-08-2022 13:29Jens GrabowskiAssigned To => Tomas Urban
16-08-2022 13:29Jens GrabowskiStatusnew => assigned
07-12-2022 08:09Jens GrabowskiNote Added: 0016361
07-12-2022 08:10Jens GrabowskiAssigned ToTomas Urban => Jens Grabowski
16-12-2024 13:04Jens GrabowskiNote Added: 0016729
16-12-2024 13:04Jens GrabowskiStatusassigned => resolved
16-12-2024 13:04Jens GrabowskiResolutionopen => fixed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0016224) +
+ Jens Grabowski    +
+ 16-08-2022 13:27    +
+ 		+ + + + +
+ TTF discussion: Idea to be checked.
+
+
+
+ + + + + + + + + + +
+ (0016225) +
+ Jens Grabowski    +
+ 16-08-2022 13:28    +
+ 		+ + + + +
+ Input for discussion: https://github.com/ttcn3/specs/blob/main/control_and_runtime_interface.ttcn3 [^]
+
+
+
+ + + + + + + + + + +
+ (0016361) +
+ Jens Grabowski    +
+ 07-12-2022 08:09    +
+ 		+ + + + +
+ TTF discussion: Nice to have. However, details regarding the interface to the "real world" need to be studied. Advantages not completely clear.
+
+
+
+ + + + + + + + + + +
+ (0016729) +
+ Jens Grabowski    +
+ 16-12-2024 13:04    +
+ 		+ + + + +
+ Discussion continues in Gitlab.
+
+ + diff --git a/docs/mantis/CR8097.md b/docs/mantis/CR8097.md new file mode 100644 index 0000000000000000000000000000000000000000..5f03028c15b301c0b6eef8f57418287cff552ae6 --- /dev/null +++ b/docs/mantis/CR8097.md @@ -0,0 +1,147 @@ + + + + + + + + + + + + + 0008097: Optional return values - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008097Part 01: TTCN-3 Core LanguageClarificationpublic05-08-2022 07:1604-01-2023 09:37
ReporterMatthias Simon 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Clause Reference(s)16.1.1 -- Invoking Functions
Source (company - Author)Nokia - Matthias Simon
Summary0008097: Optional return values
DescriptionRestriction a of Section 16.1.1 Invoking Functions states:
+
+> Functions that return values may be invoked directly [...]
+
+Does this mean that the return value of a function may be omitted? Perhaps an example would help to clarify:
+
+    // Definition of f_myFunction which has no parameters
+    function f_myFunction() return integer
+    {
+        return 7; // returns the integer value 7 when the function terminates
+    }
+    
+    // Example of omitting return value of f_myFunction (direct use)
+    f_myFunction()
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR8097.docx (80,286) 08-11-2022 11:00
http://oldforge.etsi.org/mantis/file_download.php?file_id=4071&type=bug
Issue History
Date ModifiedUsernameFieldChange
05-08-2022 07:16Matthias SimonNew Issue
16-08-2022 13:17Jens GrabowskiNote Added: 0016223
16-08-2022 13:17Jens GrabowskiAssigned To => Axel Rennoch
16-08-2022 13:17Jens GrabowskiStatusnew => assigned
16-08-2022 13:18Jens GrabowskiProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
08-11-2022 11:00Axel RennochFile Added: CR8097.docx
08-11-2022 11:01Axel RennochNote Added: 0016268
08-11-2022 11:01Axel RennochAssigned ToAxel Rennoch => Matthias Simon
08-11-2022 11:01Axel RennochStatusassigned => confirmed
08-11-2022 12:20Matthias SimonAssigned ToMatthias Simon => Jens Grabowski
08-11-2022 12:20Matthias SimonStatusconfirmed => resolved
04-01-2023 09:37Jens GrabowskiNote Added: 0016454
04-01-2023 09:37Jens GrabowskiStatusresolved => closed
04-01-2023 09:37Jens GrabowskiResolutionopen => fixed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0016223) +
+ Jens Grabowski    +
+ 16-08-2022 13:17    +
+ 		+ + + + +
+ TTF discussion: It is allowed. To be checked if/where it is stated.
+
+
+
+ + + + + + + + + + +
+ (0016268) +
+ Axel Rennoch    +
+ 08-11-2022 11:01    +
+ 		+ + + + +
+ An example has been added for the optional direct invocation.
+
+Please check the proposed solutin in the attachment.
+
+
+
+ + + + + + + + + + +
+ (0016454) +
+ Jens Grabowski    +
+ 04-01-2023 09:37    +
+ 		+ + + + +
+ Implemented as proposed.
+
+ + diff --git a/docs/mantis/CR8098.md b/docs/mantis/CR8098.md new file mode 100644 index 0000000000000000000000000000000000000000..5405cb9b06815541de660ee0bdd9bc5629af2f87 --- /dev/null +++ b/docs/mantis/CR8098.md @@ -0,0 +1,137 @@ + + + + + + + + + + + + + 0008098: Mandatory module prefix for imported module defintitions - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008098Part 01: TTCN-3 Core LanguageTechnicalpublic09-08-2022 13:2726-01-2024 16:30
ReporterMatthias Simon 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionwon't fix 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Clause Reference(s)8.2.3.1 -- General format of import
Source (company - Author)Nokia - Matthias Simon
Summary0008098: Mandatory module prefix for imported module defintitions
DescriptionSUMMARY
+
+Make the module prefix mandatory for imported module definitions, to improve TTCN-3 readability.
+
+
+DESCRIPTION
+
+Module definitions usually have some kind of module-prefix or suffix in their name to communicate their ownership/domain (similar to C).
+Here's one example from an ETSI SIP module:
+
+    module LibSip_Interface {
+
+        type record Address4SIP ...
+        signature s_SIP_conversation ...
+        type port SipPort ...
+    type port OperatorPort ...
+
+
+There are some issues which make this module harder to use and harder to comprehend:
+
+* Names are difficult to remember, because of inconsistent naming schemes.
+* Cumbersome and long disambiguation (`LibSip_Interface.s_SIP_conversation`).
+* Missing/optional module names make it difficult to find the owning module of a definition (e.g. `OperatorPort`).
+
+Looking at languages like Go or C++, there's a better way to name things: Encourage (or enforce) developers to drop the custom prefixes/suffixes and consistently use the full qualified name of imported module definitions:
+
+    module SIP {
+        type record Address ...
+    signature s_conversation ...
+    type port Port ...
+    type port OperatorPort ...
+
+The usage of module definitions would be easier to understand: `SIP.s_conversation` vs. `LibSip_Interface.s_SIP_conversation`, `SIP.OperatorPort` vs `OperatorPort`.
+
+
+PROPOSAL
+
+Make the module prefix mandatory for referencing imported module definitions.
+
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
09-08-2022 13:27Matthias SimonNew Issue
16-08-2022 13:15Jens GrabowskiNote Added: 0016222
16-08-2022 13:15Jens GrabowskiProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
17-08-2022 08:14Jens GrabowskiAssigned To => Jens Grabowski
17-08-2022 08:14Jens GrabowskiStatusnew => assigned
17-08-2022 08:14Jens GrabowskiStatusassigned => closed
17-08-2022 08:14Jens GrabowskiResolutionopen => won't fix
26-01-2024 16:30Olivier GenoudNote Added: 0016613
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0016222) +
+ Jens Grabowski    +
+ 16-08-2022 13:15    +
+ 		+ + + + +
+ TTF discussion: Not backwards compatible.
+
+
+
+ + + + + + + + + + +
+ (0016613) +
+ Olivier Genoud    +
+ 26-01-2024 16:30    +
+ 		+ + + + +
+ The proposal is not backward compatible and would cause us(TF160) to change everything (all function calls would need a module prefix)!
+In general naming conventions shall be project-specific with project specific tools checking them.
+
+ + diff --git a/docs/mantis/CR8099.md b/docs/mantis/CR8099.md new file mode 100644 index 0000000000000000000000000000000000000000..721f6965572cbdcf916bdd3410970964adce41a3 --- /dev/null +++ b/docs/mantis/CR8099.md @@ -0,0 +1,101 @@ + + + + + + + + + + + + + 0008099: Disallow circular imports - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008099Part 01: TTCN-3 Core LanguageTechnicalpublic09-08-2022 14:3626-01-2024 16:31
ReporterMatthias Simon 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionwon't fix 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Clause Reference(s)5.5 Cyclic Definitions
Source (company - Author)Nokia - Matthias Simon
Summary0008099: Disallow circular imports
DescriptionCircular imports should be disallowed.
+
+At Nokia we identified circular imports as code smell. Many import cycles we analyzed violated the test suite architecture by importing test case specific modules into common libraries. All cycles could have easily been prevented.
+
+Circular imports have a serious impact on incremental compilation and on test suite architecture.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
09-08-2022 14:36Matthias SimonNew Issue
16-08-2022 13:01Jens GrabowskiNote Added: 0016221
16-08-2022 13:01Jens GrabowskiAssigned To => Jens Grabowski
16-08-2022 13:01Jens GrabowskiStatusnew => assigned
16-08-2022 13:02Jens GrabowskiProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
16-08-2022 13:03Jens GrabowskiStatusassigned => closed
16-08-2022 13:03Jens GrabowskiResolutionopen => won't fix
26-01-2024 16:31Olivier GenoudNote Added: 0016614
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0016221) +
+ Jens Grabowski    +
+ 16-08-2022 13:01    +
+ 		+ + + + +
+ TTF discussion: Circular imports is heavily used in several places and cannot be removed due to backwards compatability issues. Future features (e.g., interfaces) may be used to avoid circular imports.
+
+
+
+ + + + + + + + + + +
+ (0016614) +
+ Olivier Genoud    +
+ 26-01-2024 16:31    +
+ 		+ + + + +
+ There is no need to handle potential code smells at core language level, but projects may define what shall be considered as code smell and how to avoid these code smells (e.g. by appropriate tools).
+
+ + diff --git a/docs/mantis/CR8100.md b/docs/mantis/CR8100.md new file mode 100644 index 0000000000000000000000000000000000000000..4373d66a74d53baa569f028b718aa78f106b2112 --- /dev/null +++ b/docs/mantis/CR8100.md @@ -0,0 +1,147 @@ + + + + + + + + + + + + + 0008100: Inline terminal productions - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008100Part 01: TTCN-3 Core LanguageEditorialpublic09-08-2022 14:4216-12-2024 13:10
ReporterMatthias Simon 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusresolvedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Clause Reference(s)Annex A -- BNF and static semantics
Source (company - Author)Nokia - Matthias Simon
Summary0008100: Inline terminal productions
DescriptionInlining terminal production would make the grammar easier to comprehend. For example:
+
+- 1.TTCN3Module ::= TTCN3ModuleKeyword ModuleId "{" ...
+- 2.TTCN3ModuleKeyword ::= "module"
++ 1.TTCN3Module ::= "module" ModuleId "{" ...
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filespptx CR-8100-Analysis-Keyword-Definitions-in-TTCN-3-BNF.pptx (49,036) 11-11-2022 10:59
http://oldforge.etsi.org/mantis/file_download.php?file_id=4080&type=bug
Issue History
Date ModifiedUsernameFieldChange
09-08-2022 14:42Matthias SimonNew Issue
16-08-2022 12:47Jens GrabowskiNote Added: 0016220
16-08-2022 12:47Jens GrabowskiAssigned To => Jens Grabowski
16-08-2022 12:47Jens GrabowskiStatusnew => assigned
16-08-2022 14:14Jens GrabowskiProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
11-11-2022 10:58Jens GrabowskiNote Added: 0016309
11-11-2022 10:59Jens GrabowskiFile Added: CR-8100-Analysis-Keyword-Definitions-in-TTCN-3-BNF.pptx
16-12-2024 13:10Jens GrabowskiNote Added: 0016730
16-12-2024 13:10Jens GrabowskiStatusassigned => resolved
16-12-2024 13:10Jens GrabowskiResolutionopen => fixed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0016220) +
+ Jens Grabowski    +
+ 16-08-2022 12:47    +
+ 		+ + + + +
+ TTF discussion: Not highest priority. Effect on extension packages needs to be studied.
+
+
+
+ + + + + + + + + + +
+ (0016309) +
+ Jens Grabowski    +
+ 11-11-2022 10:58    +
+ 		+ + + + +
+ See attached file for further information:
+
+In total: 154 Keyword Definitions
+search „string: Keyword ::=“
+
+In total: 482 Keyword References
+search string: „Keyword“ (only in BNF, Keyword definitions are not considered)
+
+Observation 1: Some BNF rules (in several standards) already include inlined keywords (or reserved words)
+
+Observation 2: Not all non-terminals of productions for defining keywords/reserved words end with “Keyword”.
+
+Observation 3: The rules describing the syntactical structure of language elements inline keywords (for readability purposes)
+
+
+
+ + + + + + + + + + +
+ (0016730) +
+ Jens Grabowski    +
+ 16-12-2024 13:10    +
+ 		+ + + + +
+ Discussion continues in Gitlab.
+
+ + diff --git a/docs/mantis/CR8101.md b/docs/mantis/CR8101.md new file mode 100644 index 0000000000000000000000000000000000000000..896dc83149e6597033e6bc39b5500104ebe0595b --- /dev/null +++ b/docs/mantis/CR8101.md @@ -0,0 +1,194 @@ + + + + + + + + + + + + + 0008101: Allow trailing comma - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008101Part 01: TTCN-3 Core LanguageTechnicalpublic09-08-2022 14:5004-01-2023 13:11
ReporterMatthias Simon 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Clause Reference(s)Core Language Spec
Source (company - Author)Nokia - Matthias Simon
Summary0008101: Allow trailing comma
DescriptionAllowing a trailing comma in comma separated lists, such as record members, would be a convenient relaxation. For example:
+
+    type record Point {
+        integer x,
+        integer y,
+        integer z, // <-- trailing comma
+    }
+
+An optional trailing comma increases code uniformity and improves readability (of code-diffs).
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR-8101-Res-221216.docx (147,954) 16-12-2022 11:42
http://oldforge.etsi.org/mantis/file_download.php?file_id=4100&type=bug
docx CR-8101-2.docx (199,428) 20-12-2022 11:23
http://oldforge.etsi.org/mantis/file_download.php?file_id=4110&type=bug
Issue History
Date ModifiedUsernameFieldChange
09-08-2022 14:50Matthias SimonNew Issue
16-08-2022 12:36Jens GrabowskiNote Added: 0016219
16-08-2022 12:36Jens GrabowskiAssigned To => Jens Grabowski
16-08-2022 12:36Jens GrabowskiStatusnew => assigned
16-08-2022 14:14Jens GrabowskiProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
16-12-2022 11:42Jens GrabowskiFile Added: CR-8101-Res-221216.docx
16-12-2022 11:45Jens GrabowskiNote Added: 0016428
16-12-2022 11:45Jens GrabowskiAssigned ToJens Grabowski => Tomas Urban
20-12-2022 10:50Tomas UrbanFile Added: CR-8101-2.docx
20-12-2022 10:50Tomas UrbanAssigned ToTomas Urban => Jens Grabowski
20-12-2022 10:58Tomas UrbanFile Deleted: CR-8101-2.docx
20-12-2022 10:58Tomas UrbanAssigned ToJens Grabowski => Tomas Urban
20-12-2022 11:23Tomas UrbanFile Added: CR-8101-2.docx
20-12-2022 11:25Tomas UrbanNote Added: 0016436
20-12-2022 11:25Tomas UrbanAssigned ToTomas Urban => Jens Grabowski
20-12-2022 11:25Tomas UrbanStatusassigned => confirmed
20-12-2022 12:34Jens GrabowskiStatusconfirmed => resolved
20-12-2022 12:34Jens GrabowskiResolutionopen => fixed
04-01-2023 13:11Jens GrabowskiNote Added: 0016466
04-01-2023 13:11Jens GrabowskiStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0016219) +
+ Jens Grabowski    +
+ 16-08-2022 12:36    +
+ 		+ + + + +
+ TTF discussion: Proposal appreciated. Proposal needed. Proposal maybe according to A1.2
+
+
+
+ + + + + + + + + + +
+ (0016428) +
+ Jens Grabowski    +
+ 16-12-2022 11:45    +
+ 		+ + + + +
+ Tomas, please check. I added round about 80 optional commas, i.e., [","], but some rules look a little bit strange. Please check carefully.
+
+
+
+ + + + + + + + + + +
+ (0016436) +
+ Tomas Urban    +
+ 20-12-2022 11:25    +
+ 		+ + + + +
+ I made some changes in the document
+
+1. Not all comma-separated lists ends with } or ). Some of them are part of statements or declaration and the terminator is then { or ; Examples: variable declaration, port type message list. I changed the text accordingly.
+
+2. I removed the trailing comma from statements with a fixed number of elements. It doesn't make much sense to have it there. List of changed rules:
+123. PatternElement
+129. PatternQuadruple
+156. MatchOp
+287. SingleConnectionSpec
+298. UnmapStatement
+307. SetEncodeStatement
+333. PortRaiseOp
+429. Quadruple
+
+3. I changed the grammar of some rules allowing the trailing comma only in cases when a parameter is missing. List of changed rules:
+270. CreateOp
+380. CatchOpParameter
+557. DecodedFieldType
+
+4. I added the trailing comma to the rule 4. LanguageSpec
+
+Please check the changes I made and if there are no major issues, I think we could accept the proposal.
+
+
+
+ + + + + + + + + + +
+ (0016466) +
+ Jens Grabowski    +
+ 04-01-2023 13:11    +
+ 		+ + + + +
+ Implemented according to resolution document.
+
+ + diff --git a/docs/mantis/CR8102.md b/docs/mantis/CR8102.md new file mode 100644 index 0000000000000000000000000000000000000000..251434581d1926a37de747569ec82b7cc745f319 --- /dev/null +++ b/docs/mantis/CR8102.md @@ -0,0 +1,245 @@ + + + + + + + + + + + + + 0008102: Optional semicolon - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - TTCN-3 Change Requests
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008102TTCN-3 Change RequestsTechnicalpublic09-08-2022 15:0116-12-2024 10:11
ReporterMatthias Simon 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusresolvedResolutionfixed 
PlatformOSOS Version
Clause Reference(s)A.1.2 -- Statement terminator symbols
For STF discussion
Source (company - Author)Nokia - Matthias Simon
Summary0008102: Optional semicolon
DescriptionCurrent semicolon rules are context sensitive and are impossible to be defined properly in grammars without not-predicates/look-ahead (yacc, Bison, ...).
+
+I propose to make the semicolon optional.
+
+Open question: How could we handle conflicts such as:
+
+    alt {
+        var integer a[x]
+        [y] p.receive
+    }
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
09-08-2022 15:01Matthias SimonNew Issue
16-08-2022 09:30Jens GrabowskiNote Added: 0016213
16-08-2022 09:31Jens GrabowskiAssigned To => Jens Grabowski
16-08-2022 09:31Jens GrabowskiStatusnew => assigned
10-11-2022 10:23Jens GrabowskiNote Added: 0016288
10-11-2022 10:23Jens GrabowskiAssigned ToJens Grabowski => Axel Rennoch
10-11-2022 11:01Axel RennochNote Added: 0016292
10-11-2022 11:02Axel RennochAssigned ToAxel Rennoch => Matthias Simon
10-11-2022 13:12Jens GrabowskiNote Added: 0016297
10-11-2022 13:13Jens GrabowskiStatusassigned => closed
10-11-2022 13:13Jens GrabowskiResolutionopen => fixed
26-01-2024 16:32Olivier GenoudNote Added: 0016616
11-12-2024 09:14Jens GrabowskiNote Added: 0016716
16-12-2024 10:11Jens GrabowskiAssigned ToMatthias Simon => Jens Grabowski
16-12-2024 10:11Jens GrabowskiStatusclosed => resolved
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0016213) +
+ Jens Grabowski    +
+ 16-08-2022 09:30    +
+ 		+ + + + +
+ TTF Discussion: Benefits unclear, tools are differently implemented.
+
+
+
+ + + + + + + + + + +
+ (0016288) +
+ Jens Grabowski    +
+ 10-11-2022 10:23    +
+ 		+ + + + +
+ Axel, can you have a look?
+
+
+
+ + + + + + + + + + +
+ (0016292) +
+ Axel Rennoch    +
+ 10-11-2022 11:01    +
+ 		+ + + + +
+ From the user perspective the semicolon supports readability and avoids unnecessary conflicts or misunderstanding. TTCN-3 is still a specification language and not only for implementation/programming.
+
+In certain cases the semicolon might be avoided and become optional and specified in A.1.2. These explicit cases should be proposed and checked.
+
+
+
+ + + + + + + + + + +
+ (0016297) +
+ Jens Grabowski    +
+ 10-11-2022 13:12    +
+ 		+ + + + +
+ TTF discussion: CR cannot be implemented at the moment. TTF agrees that semicolons support readability and understandability of the language.
+
+
+
+ + + + + + + + + + +
+ (0016616) +
+ Olivier Genoud    +
+ 26-01-2024 16:32    +
+ 		+ + + + +
+ In general, we(TF160) like the strict use of semicolons not at least as it may help tools to do automatic indentation. In addition, there seems to be no real benefit from a user's point of view to allow semicolons to be optional.
+
+
+
+ + + + + + + + + + +
+ (0016716) +
+ Jens Grabowski    +
+ 11-12-2024 09:14    +
+ 		+ + + + +
+ To be continued in Gitlab
+
+ + diff --git a/docs/mantis/CR8103.md b/docs/mantis/CR8103.md new file mode 100644 index 0000000000000000000000000000000000000000..8f768480ea1db097c8401e8e652861a2ec7078ca --- /dev/null +++ b/docs/mantis/CR8103.md @@ -0,0 +1,281 @@ + + + + + + + + + + + + + 0008103: Add increment and decrement statement - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008103Part 01: TTCN-3 Core LanguageNew Featurepublic09-08-2022 15:1003-01-2023 13:12
ReporterMatthias Simon 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Clause Reference(s)19 -- Basic program statements
Source (company - Author)Nokia - Matthias Simon
Summary0008103: Add increment and decrement statement
DescriptionSUMMARY
+
+The post increment operator in C has a bad reputation, because its unfavorable specification creates multiple undefined behavior scenarios.
+
+However, incrementing by one is so common in TTCN-3 that introducing some kind of increment instruction is justified.
+
+PROPOSAL
+
+Introduce a increment and decrement *statement*. A statement cannot be used in expressions, only in places where it's safe. Examples:
+
+    for(i:=0; i<10; i++) // okay.
+    log(i++) // not okay.
+ 
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR8103.docx (139,230) 07-12-2022 11:54
http://oldforge.etsi.org/mantis/file_download.php?file_id=4088&type=bug
Issue History
Date ModifiedUsernameFieldChange
09-08-2022 15:10Matthias SimonNew Issue
16-08-2022 12:18Jens GrabowskiNote Added: 0016218
16-08-2022 12:19Jens GrabowskiAssigned To => Jens Grabowski
16-08-2022 12:19Jens GrabowskiStatusnew => assigned
16-08-2022 14:14Jens GrabowskiProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
11-11-2022 11:36Jens GrabowskiNote Added: 0016310
11-11-2022 11:36Jens GrabowskiAssigned ToJens Grabowski => Axel Rennoch
06-12-2022 14:15Axel RennochNote Added: 0016360
06-12-2022 14:15Axel RennochAssigned ToAxel Rennoch => Jens Grabowski
07-12-2022 09:15Jens GrabowskiNote Added: 0016367
07-12-2022 09:15Jens GrabowskiAssigned ToJens Grabowski => Axel Rennoch
07-12-2022 11:54Axel RennochFile Added: CR8103.docx
07-12-2022 11:55Axel RennochNote Added: 0016370
07-12-2022 11:55Axel RennochAssigned ToAxel Rennoch => Jens Grabowski
07-12-2022 11:55Axel RennochStatusassigned => confirmed
16-12-2022 09:22Jens GrabowskiNote Added: 0016425
16-12-2022 09:22Jens GrabowskiStatusconfirmed => resolved
16-12-2022 09:22Jens GrabowskiResolutionopen => fixed
03-01-2023 13:12Jens GrabowskiNote Added: 0016449
03-01-2023 13:12Jens GrabowskiStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0016218) +
+ Jens Grabowski    +
+ 16-08-2022 12:18    +
+ 		+ + + + +
+ TTF discussion: Idea appreciated. Decrement should also be added.
+
+
+
+ + + + + + + + + + +
+ (0016310) +
+ Jens Grabowski    +
+ 11-11-2022 11:36    +
+ 		+ + + + +
+ Axel, can you have a look?
+
+
+
+ + + + + + + + + + +
+ (0016360) +
+ Axel Rennoch    +
+ 06-12-2022 14:15    +
+ 		+ + + + +
+ The approach may be to add a new subsection "7.1.8 Increment and Decrement operators" to explain the functionality of "++" and "--".
+
+In addition the section "19.1 Assignments" and the BNF rule 539 may be subject to an update to allow the new sytax: ValueRef"++" and ValueRef"--".
+
+
+
+ + + + + + + + + + +
+ (0016367) +
+ Jens Grabowski    +
+ 07-12-2022 09:15    +
+ 		+ + + + +
+ TTF discussion: Increment and Decrement should become stand-alone statements and not operators. They may become subsections of 19.1. The BNF change in assignment rules looks ok.
+
+
+
+ + + + + + + + + + +
+ (0016370) +
+ Axel Rennoch    +
+ 07-12-2022 11:55    +
+ 		+ + + + +
+ Please check the proposed solution file.
+
+
+
+ + + + + + + + + + +
+ (0016425) +
+ Jens Grabowski    +
+ 16-12-2022 09:22    +
+ 		+ + + + +
+ ok
+
+
+
+ + + + + + + + + + +
+ (0016449) +
+ Jens Grabowski    +
+ 03-01-2023 13:12    +
+ 		+ + + + +
+ Implemented as proposed
+
+ + diff --git a/docs/mantis/CR8104.md b/docs/mantis/CR8104.md new file mode 100644 index 0000000000000000000000000000000000000000..ff99c5de3a4ca1284ae746911e76c1b01232b5d4 --- /dev/null +++ b/docs/mantis/CR8104.md @@ -0,0 +1,399 @@ + + + + + + + + + + + + + 0008104: Automatic type inference - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008104Part 01: TTCN-3 Core LanguageNew Featurepublic09-08-2022 16:3204-01-2023 12:25
ReporterMatthias Simon 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Clause Reference(s)Core Language Spec
Source (company - Author)Nokia - Matthias Simon
Summary0008104: Automatic type inference
DescriptionAutomatic type inference is a powerful feature where you allow the compiler to infer the type of a declaration by using the special type `auto`.
+
+Example:
+
+    var auto u := getUser("Foo");
+
+
+Open question: Do we allow `auto` only in declarations or also in formal parameters, return types, nested types and templates?
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR8104.docx (309,467) 14-11-2022 12:51
http://oldforge.etsi.org/mantis/file_download.php?file_id=4081&type=bug
docx CR8104-2.docx (316,772) 07-12-2022 10:35
http://oldforge.etsi.org/mantis/file_download.php?file_id=4087&type=bug
docx CR8104-3.docx (317,153) 20-12-2022 09:29
http://oldforge.etsi.org/mantis/file_download.php?file_id=4107&type=bug
Issue History
Date ModifiedUsernameFieldChange
09-08-2022 16:32Matthias SimonNew Issue
16-08-2022 11:06Jens GrabowskiNote Added: 0016217
16-08-2022 11:06Jens GrabowskiAssigned To => Tomas Urban
16-08-2022 11:06Jens GrabowskiStatusnew => assigned
16-08-2022 14:14Jens GrabowskiProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
11-11-2022 12:30Jens GrabowskiNote Added: 0016311
14-11-2022 12:51Tomas UrbanFile Added: CR8104.docx
14-11-2022 12:53Tomas UrbanNote Added: 0016314
14-11-2022 12:53Tomas UrbanAssigned ToTomas Urban => Jens Grabowski
14-11-2022 12:53Tomas UrbanStatusassigned => confirmed
14-11-2022 19:46Matthias SimonNote Added: 0016315
06-12-2022 12:57Matthias SimonAssigned ToJens Grabowski => Tomas Urban
06-12-2022 12:57Matthias SimonStatusconfirmed => assigned
07-12-2022 10:35Tomas UrbanFile Added: CR8104-2.docx
07-12-2022 10:53Tomas UrbanNote Added: 0016369
07-12-2022 10:53Tomas UrbanAssigned ToTomas Urban => Matthias Simon
07-12-2022 10:53Tomas UrbanStatusassigned => confirmed
12-12-2022 08:39Matthias SimonNote Added: 0016381
12-12-2022 08:39Matthias SimonAssigned ToMatthias Simon => Tomas Urban
12-12-2022 08:39Matthias SimonStatusconfirmed => assigned
20-12-2022 09:28Tomas UrbanFile Added: CR-8105-3.docx
20-12-2022 09:29Tomas UrbanFile Deleted: CR-8105-3.docx
20-12-2022 09:29Tomas UrbanFile Added: CR8104-3.docx
20-12-2022 09:36Tomas UrbanNote Added: 0016432
20-12-2022 09:36Tomas UrbanAssigned ToTomas Urban => Matthias Simon
20-12-2022 09:36Tomas UrbanStatusassigned => confirmed
20-12-2022 11:02Matthias SimonStatusconfirmed => resolved
20-12-2022 11:02Matthias SimonResolutionopen => fixed
20-12-2022 11:02Matthias SimonAssigned ToMatthias Simon => Jens Grabowski
04-01-2023 12:25Jens GrabowskiNote Added: 0016465
04-01-2023 12:25Jens GrabowskiStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0016217) +
+ Jens Grabowski    +
+ 16-08-2022 11:06    +
+ 		+ + + + +
+ TTF discussion: Interesting feature. Details need to be studied. Possible restriction: Auto-feature are restricted to var, const, (maybe) module parameter. Usage for templates may require further discussions.
+
+
+
+ + + + + + + + + + +
+ (0016311) +
+ Jens Grabowski    +
+ 11-11-2022 12:30    +
+ 		+ + + + +
+ TTF discussion: We introduce the feature for var, const and module parameter.
+
+
+
+ + + + + + + + + + +
+ (0016314) +
+ Tomas Urban    +
+ 14-11-2022 12:53    +
+ 		+ + + + +
+ The first version of the resolution uploaded. Please check and let me know what should be changed or added.
+
+
+
+ + + + + + + + + + +
+ (0016315) +
+ Matthias Simon    +
+ 14-11-2022 19:46    +
+ 		+ + + + +
+ Explaining this feature in the glossary is a great idea.
+
+> 6.5. Automatic Type
+> The expression or template body shall be one of the following...
+> a) Reference to ...
+Does this also include enumerated values?
+
+> a) Reference to an [...] parameter
+Probably timers should be excluded:
+
+    function f(timer t) {
+        var t2 := t;
+    }
+
+How about ports?
+
+> b) Function call returning a value.
+Does this include macros, predefined functions and operations (`__LINE__`, `int2str`, `match`, `create`, ...)?
+
+> d) Literal of ...
+What about verdict literals and inline templates?
+
+> g) Field assignment notation
+Composite literals with field assignment notation create a anonymous records? Example:
+
+    module M {
+        type record Point { integer x, integer y }
+        control {
+            var p := { x := 23, y := 5 }; // Interred type is not "Point", but "record { integer x, integer y }"
+        }
+    }
+
+Did I understand this correctly?
+
+How do unions fit into this picture?
+
+I found some examples where function argument type inference is be necessary:
+
+    var a := replace('00000110'B, 1, 3, '111'B), // type is bitstring
+        b := replace("My name is JJ", 13, 0, "xx") // type is charstring
+
+
+How do we distinguish between list of templates and expressions?
+Example:
+
+    var a := (1,2,3) // Okay: list of integer templates
+    var b := (1+2*3) // Okay: integer
+    var c := (1) // Error or integer?
+
+
+> // automatic type: map from charst[r]ing to float
+Typo in examples.
+
+
+I noticed you replaced `Type` with `[TypeOrNestedTypeDef]`. Is the nested types on purpose?
+
+> the ArrayDef part shall be missing as well
+Why should be array part be omitted? Seems to me not necessary:
+
+    var a[] := {1,2,3} // a is an integer array of length 3
+
+
+
+ + + + + + + + + + +
+ (0016369) +
+ Tomas Urban    +
+ 07-12-2022 10:53    +
+ 		+ + + + +
+ New version uploaded, please check.
+I addressed several issues: missing enumerated items, verdict literals, inline templates and TTCN-3 operators.
+
+The following issues were not necessary to address in the draft:
+1. As timer an port variables, constants and module parameters (with an explicitly specified type) are supported, there's no reason to restrict these type in automatic typing.
+2. Preprocessor macros are conversted into charstring literals before compilation and then the rule f. is used
+3. Composite literals create indeed anonymous records
+4. (Anonymous) unions cannot be created by automatic typing as the notation is equal to a record with a single field
+5. List of templates and an expression inside parenthesis are syntactically equal. The current proposal doesn't address this issue explicitly, but it is implicitly assumed the this kind of construction will be resolved as an expression.
+6. The array notation [] (i.e. without dimensions) is definitely an interesting feature, but it would require more changes in the specification, because typed variables could also use automatic dimensions. I guess that is a topic for another CR.
+
+
+
+ + + + + + + + + + +
+ (0016381) +
+ Matthias Simon    +
+ 12-12-2022 08:39    +
+ 		+ + + + +
+ > p) Superset and subset [...] provide an [...] record of
+
+I think the type of superset, subset, permutation, ... should be "template of set of {element type}".
+
+
+> where all items are of the same type as the first item
+
+We could phrase this requirement slightly different and allow cases where the first element has no concrete (or a misleading) type, such as:
+  1) {"Ilusat", "päeva!"} // record of universal charstring
+  2) {1, -, 3} // record of integer
+  3) {-, 2, 3} // record of integer
+  4) (*, 2, 3) // integer template
+
+How about "where all items have a common type"?
+
+
+I have some questions about template variables. Are these all template variables with integer type:
+
+    var template a := integer:?;
+    var template b := 1;
+    var value c := 1;
+    var d := integer:?;
+
+
+
+ + + + + + + + + + +
+ (0016432) +
+ Tomas Urban    +
+ 20-12-2022 09:36    +
+ 		+ + + + +
+ I fixed the issue with superset/subset and changed the text so that the expression "have a common type" is used wherever possible. That was an excellent suggestion and it makes the rules much simpler.
+Regarding the last question, my opinion is that according to the proposed rules the keyword "template" is still mandatory, i.e. if you try to assign a matching symbol to a non-template automatic variable, you will get an error. Nevertheless, I am open to a discussion in this case, but I think such a change would require a different CR.
+
+
+
+ + + + + + + + + + +
+ (0016465) +
+ Jens Grabowski    +
+ 04-01-2023 12:25    +
+ 		+ + + + +
+ Implemented according to the resolution.
+
+ + diff --git a/docs/mantis/CR8105.md b/docs/mantis/CR8105.md new file mode 100644 index 0000000000000000000000000000000000000000..df4eb693f83deb3011b8f193954ad99c91d30d68 --- /dev/null +++ b/docs/mantis/CR8105.md @@ -0,0 +1,330 @@ + + + + + + + + + + + + + 0008105: Extend allowed usage of nested types - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008105Part 01: TTCN-3 Core LanguageTechnicalpublic09-08-2022 16:3803-01-2023 11:25
ReporterMatthias Simon 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Clause Reference(s)Core Language Spec
Source (company - Author)Nokia - Matthias Simon
Summary0008105: Extend allowed usage of nested types
DescriptionAllow the usage of nested types in more places. For example:
+
+* Functions: external function f() return record of charstring;
+* Local variables: var record of integer a;
+* Parameters: testcase tc(record of PTC ptcs) { ... }
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR-8105.docx (294,286) 10-11-2022 10:47
http://oldforge.etsi.org/mantis/file_download.php?file_id=4075&type=bug
docx CR-8105-2.docx (313,601) 11-11-2022 09:55
http://oldforge.etsi.org/mantis/file_download.php?file_id=4078&type=bug
docx CR-8105-3.docx (320,794) 07-12-2022 12:55
http://oldforge.etsi.org/mantis/file_download.php?file_id=4089&type=bug
docx CR-8105-4.docx (173,623) 12-12-2022 07:24
http://oldforge.etsi.org/mantis/file_download.php?file_id=4094&type=bug
Issue History
Date ModifiedUsernameFieldChange
09-08-2022 16:38Matthias SimonNew Issue
16-08-2022 10:37Jens GrabowskiNote Added: 0016216
16-08-2022 10:40Jens GrabowskiAssigned To => Tomas Urban
16-08-2022 10:40Jens GrabowskiStatusnew => assigned
16-08-2022 14:14Jens GrabowskiProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
10-11-2022 10:47Tomas UrbanFile Added: CR-8105.docx
10-11-2022 10:51Tomas UrbanNote Added: 0016291
10-11-2022 10:51Tomas UrbanAssigned ToTomas Urban => Matthias Simon
10-11-2022 10:51Tomas UrbanStatusassigned => confirmed
10-11-2022 12:16Jens GrabowskiAssigned ToMatthias Simon => Tomas Urban
10-11-2022 12:16Jens GrabowskiStatusconfirmed => assigned
10-11-2022 20:54Matthias SimonNote Added: 0016301
11-11-2022 09:55Tomas UrbanFile Added: CR-8105-2.docx
11-11-2022 09:56Tomas UrbanNote Added: 0016307
11-11-2022 09:56Tomas UrbanAssigned ToTomas Urban => Matthias Simon
11-11-2022 09:56Tomas UrbanStatusassigned => confirmed
06-12-2022 10:40Matthias SimonNote Added: 0016358
06-12-2022 10:40Matthias SimonNote Edited: 0016358bug_revision_view_page.php?bugnote_id=16358#r605
06-12-2022 10:40Matthias SimonAssigned ToMatthias Simon => Tomas Urban
06-12-2022 10:40Matthias SimonStatusconfirmed => assigned
07-12-2022 12:55Tomas UrbanFile Added: CR-8105-3.docx
07-12-2022 12:55Tomas UrbanNote Added: 0016371
07-12-2022 12:55Tomas UrbanAssigned ToTomas Urban => Matthias Simon
07-12-2022 12:55Tomas UrbanStatusassigned => confirmed
12-12-2022 07:24Matthias SimonFile Added: CR-8105-4.docx
12-12-2022 07:27Matthias SimonNote Added: 0016380
12-12-2022 07:27Matthias SimonStatusconfirmed => resolved
12-12-2022 07:27Matthias SimonResolutionopen => fixed
12-12-2022 07:27Matthias SimonAssigned ToMatthias Simon => Jens Grabowski
03-01-2023 11:25Jens GrabowskiNote Added: 0016445
03-01-2023 11:25Jens GrabowskiStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0016216) +
+ Jens Grabowski    +
+ 16-08-2022 10:37    +
+ 		+ + + + +
+ TTF discussion: The places where nested types should be used, need to be identified.
+
+
+
+ + + + + + + + + + +
+ (0016291) +
+ Tomas Urban    +
+ 10-11-2022 10:51    +
+ 		+ + + + +
+ Proposal uploaded, please review.
+I didn't add inline types to templates (with exception of template variables and template parameters) as templates require strong typing for communication operations and it wouldn't make much sense to have static templates with not much practical use. Template parameters and variables are fine though as they are often used withing the code for passing data around.
+
+
+
+ + + + + + + + + + +
+ (0016301) +
+ Matthias Simon    +
+ 10-11-2022 20:54    +
+ 		+ + + + +
+ This feature is very subtle. I think it would be nice we'd add one or two examples.
+
+
+
+ + + + + + + + + + +
+ (0016307) +
+ Tomas Urban    +
+ 11-11-2022 09:56    +
+ 		+ + + + +
+ Second version with signatures, constants and couple of examples. Different naming for the new BNF rule is used as well.
+Please check.
+
+
+
+ + + + + + + + + + +
+ (0016358) +
+ Matthias Simon    +
+ 06-12-2022 10:40    +
+ 		+ + + + +
+ We should clarify the section about reference-parameters and strong-typing:
+
+> 5.4.1 Formal parameters:
+> When parameters are passed by reference, strong typing is required.
+> Both the actual and formal parameter shall be of the same type.
+
+> 3.1 Terms:
+> strong typing: strict enforcement of type compatibility
+> by type name equivalence with no exceptions.
+
+
+    type record of integer RoI;
+    function f(inout record of integer a) {
+        a[1] := 23
+    }
+    control {
+        var RoI r := {1,2,3};
+        f(r); // Should this be allowed?
+    }
+
+
+
+
+
+ + + + + + + + + + +
+ (0016371) +
+ Tomas Urban    +
+ 07-12-2022 12:55    +
+ 		+ + + + +
+ Added a note on strong typing concerning nested types.
+Please check
+
+
+
+ + + + + + + + + + +
+ (0016380) +
+ Matthias Simon    +
+ 12-12-2022 07:27    +
+ 		+ + + + +
+ Looks good to me.
+
+Note, I corrected a small mistake in the BNF rules for formal parameters.
+
+
+
+ + + + + + + + + + +
+ (0016445) +
+ Jens Grabowski    +
+ 03-01-2023 11:25    +
+ 		+ + + + +
+ Implemented as proposed.
+
+ + diff --git a/docs/mantis/CR8106.md b/docs/mantis/CR8106.md new file mode 100644 index 0000000000000000000000000000000000000000..f1a899e3ebcb31a2b0dbfadfe02230e0679c7fe7 --- /dev/null +++ b/docs/mantis/CR8106.md @@ -0,0 +1,136 @@ + + + + + + + + + + + + + 0008106: Provide TTCN-3 defintions for predefined types - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008106Part 01: TTCN-3 Core LanguageTechnicalpublic09-08-2022 17:0016-12-2024 12:58
ReporterMatthias Simon 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusresolvedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Clause Reference(s)Core Language Spec
Source (company - Author)Nokia - Matthias Simon
Summary0008106: Provide TTCN-3 defintions for predefined types
DescriptionPredefined functions and some operations like log, match, setverdict, ... can be specified as external function using valid TTCN-3 syntax (see https://github.com/ttcn3/specs/blob/main/predefined_functions.ttcn3#L692-L713 [^]).
+Those functions could form some kind of standard library. This would make the core language specification slimmer and the tools easier to implement and maintain.
+
+If the object oriented extension is available, operations of ports, testcases, components and timers could possibly be specified as method of external abtract classes.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
09-08-2022 17:00Matthias SimonNew Issue
16-08-2022 10:26Jens GrabowskiNote Added: 0016215
16-08-2022 14:17Jens GrabowskiProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
17-08-2022 08:09Jens GrabowskiAssigned To => Matthias Simon
17-08-2022 08:09Jens GrabowskiStatusnew => assigned
07-12-2022 08:42Jens GrabowskiNote Added: 0016364
07-12-2022 08:43Jens GrabowskiAssigned ToMatthias Simon => Jens Grabowski
16-12-2024 12:58Jens GrabowskiNote Added: 0016728
16-12-2024 12:58Jens GrabowskiStatusassigned => resolved
16-12-2024 12:58Jens GrabowskiResolutionopen => fixed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0016215) +
+ Jens Grabowski    +
+ 16-08-2022 10:26    +
+ 		+ + + + +
+ TTF discussion: (a) Predefined function definitions should follow TTCN-3 syntax (if not, this should be corrected). (b) Putting core functionality into annexes needs further discussion (possibly in context to standards allignment). (c) Standard extensions may be provided in form of TTCN-3 modules.
+
+Matthias to provide a list with problematic predefined functions not in TTCN-3 syntax.
+
+
+
+ + + + + + + + + + +
+ (0016364) +
+ Jens Grabowski    +
+ 07-12-2022 08:42    +
+ 		+ + + + +
+ TTF discussion: Should be discussed in the scope of language renovation. Possibly, standard libraries may be provided.
+
+
+
+ + + + + + + + + + +
+ (0016728) +
+ Jens Grabowski    +
+ 16-12-2024 12:58    +
+ 		+ + + + +
+ Discussion continues in Gitlab.
+
+ + diff --git a/docs/mantis/CR8107.md b/docs/mantis/CR8107.md new file mode 100644 index 0000000000000000000000000000000000000000..6f76d63fa13a42d90c42d9c64ae4468bcb976139 --- /dev/null +++ b/docs/mantis/CR8107.md @@ -0,0 +1,258 @@ + + + + + + + + + + + + + 0008107: Support for variadic functions - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008107Part 01: TTCN-3 Core LanguageNew Featurepublic09-08-2022 20:1004-01-2023 11:59
ReporterMatthias Simon 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Clause Reference(s)Core Language Spec
Source (company - Author)Nokia - Matthias Simon
Summary0008107: Support for variadic functions
DescriptionAdd support for variadic functions.
+
+DESCRIPTION
+
+The last formal parameter of a (external) function, altstep, testcase, ... may have a type suffixed with ... . A function with such a parameter is called variadic and may be invoked with zero or more arguments for that parameter.
+
+If f is variadic with a last formal parameter p of type T..., then within f the type of p is equivalent to type record of T.
+ 
+Examples:
+    external function printf(charstring fmt, any... args);
+    
+    function avg(integer... values) return integer {
+        var integer sum;
+        for (var integer i := 0; i < lengthof(values); i := i + 1) {
+            sum := sum + values[i]
+        }
+        return sum / lengthof(values)
+    }
+
+    avg() // returns 0
+    avg(1) // returns 1
+    avg(1, 3) // returns 2
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR8107.docx (116,155) 06-12-2022 14:51
http://oldforge.etsi.org/mantis/file_download.php?file_id=4085&type=bug
docx CR8107(1).docx (115,214) 12-12-2022 12:57
http://oldforge.etsi.org/mantis/file_download.php?file_id=4095&type=bug
docx CR8107-2.docx (147,240) 20-12-2022 09:13
http://oldforge.etsi.org/mantis/file_download.php?file_id=4105&type=bug
Issue History
Date ModifiedUsernameFieldChange
09-08-2022 20:10Matthias SimonNew Issue
16-08-2022 09:51Jens GrabowskiNote Added: 0016214
16-08-2022 14:17Jens GrabowskiProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
17-08-2022 08:11Jens GrabowskiAssigned To => Matthias Simon
17-08-2022 08:11Jens GrabowskiStatusnew => assigned
06-12-2022 14:51Matthias SimonFile Added: CR8107.docx
06-12-2022 14:53Matthias SimonStatusassigned => confirmed
11-12-2022 12:27Matthias SimonStatusconfirmed => assigned
11-12-2022 12:29Matthias SimonNote Added: 0016377
11-12-2022 12:29Matthias SimonAssigned ToMatthias Simon => Tomas Urban
11-12-2022 12:29Matthias SimonStatusassigned => confirmed
11-12-2022 16:22Matthias SimonNote Added: 0016378
11-12-2022 16:22Matthias SimonAssigned ToTomas Urban => Matthias Simon
11-12-2022 16:22Matthias SimonStatusconfirmed => new
11-12-2022 16:23Matthias SimonNote Added: 0016379
11-12-2022 16:23Matthias SimonAssigned ToMatthias Simon => Tomas Urban
11-12-2022 16:23Matthias SimonStatusnew => confirmed
12-12-2022 12:31Matthias SimonNote Deleted: 0016378
12-12-2022 12:31Matthias SimonNote Deleted: 0016379
12-12-2022 12:57Matthias SimonFile Added: CR8107(1).docx
12-12-2022 12:59Matthias SimonNote Added: 0016385
20-12-2022 09:13Tomas UrbanFile Added: CR8107-2.docx
20-12-2022 09:17Tomas UrbanNote Added: 0016430
20-12-2022 09:17Tomas UrbanAssigned ToTomas Urban => Matthias Simon
20-12-2022 09:26Matthias SimonNote Added: 0016431
20-12-2022 09:27Matthias SimonAssigned ToMatthias Simon => Jens Grabowski
20-12-2022 09:27Matthias SimonStatusconfirmed => assigned
20-12-2022 11:47Jens GrabowskiStatusassigned => confirmed
04-01-2023 11:59Jens GrabowskiNote Added: 0016464
04-01-2023 11:59Jens GrabowskiStatusconfirmed => closed
04-01-2023 11:59Jens GrabowskiResolutionopen => fixed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0016214) +
+ Jens Grabowski    +
+ 16-08-2022 09:51    +
+ 		+ + + + +
+ TTF Discussion: Matthias will develop a proposal.
+
+
+
+ + + + + + + + + + +
+ (0016377) +
+ Matthias Simon    +
+ 11-12-2022 12:29    +
+ 		+ + + + +
+ The first version of the resolution uploaded. Please check and let me know what should be changed or added.
+
+
+
+ + + + + + + + + + +
+ (0016385) +
+ Matthias Simon    +
+ 12-12-2022 12:59    +
+ 		+ + + + +
+ Added missing syntax for passing "record of" parameters directly. Example:
+
+   function f1(integer args...) {}
+   var record of integer r := {1,2,3}
+   f1(r...);
+
+
+
+ + + + + + + + + + +
+ (0016430) +
+ Tomas Urban    +
+ 20-12-2022 09:17    +
+ 		+ + + + +
+ I added missing rules and modified the existing ones. The main principles remained the same. If you are happy with the changes or make only minor correction, please pass it to Jens so that he can take a look too.
+
+
+
+ + + + + + + + + + +
+ (0016431) +
+ Matthias Simon    +
+ 20-12-2022 09:26    +
+ 		+ + + + +
+ Much better. Thank you Tomas.
+
+
+
+ + + + + + + + + + +
+ (0016464) +
+ Jens Grabowski    +
+ 04-01-2023 11:59    +
+ 		+ + + + +
+ Implemented as proposed.
+
+ + diff --git a/docs/mantis/CR8108.md b/docs/mantis/CR8108.md new file mode 100644 index 0000000000000000000000000000000000000000..d4f5c81315bbbb1990b2928c9a75681a37228939 --- /dev/null +++ b/docs/mantis/CR8108.md @@ -0,0 +1,294 @@ + + + + + + + + + + + + + 0008108: Uniqueness of identifiers for fields and enumerations - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - TTCN-3 Change Requests
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008108TTCN-3 Change RequestsClarificationpublic16-08-2022 07:4304-01-2023 11:12
ReporterMatthias Simon 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Clause Reference(s)5.2.2 Uniqueness of identifiers
For STF discussion
Source (company - Author)Nokia -- Matthias Simon
Summary0008108: Uniqueness of identifiers for fields and enumerations
DescriptionThe core language standard states that identifiers of scope units shall be unique:
+
+> TTCN-3 requires uniqueness of identifiers, i.e. all identifiers in the same scope hierarchy shall be distinctive.
+> This means that a declaration in a lower level of scope shall not re-use the same identifier as a declaration in
+> a higher level of scope in the same branch of the scope hierarchy.
+
+However it is not clear if this requirement includes field identifiers of records or enumeration labels or not.
+
+I'd argue they are not included. Hence I propose to add some clarifying examples:
+
+
+EXAMPLE 3: Explicit scopes
+
+// The following IS allowed as the custom type definition provide an explicit scope for fields and enumeration labels
+module A {
+  type record B {
+      integer A,
+      integer B
+  }
+
+  type enumerated C { A, B }
+}
+
+
+
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR8108.docx (80,337) 09-11-2022 11:44
http://oldforge.etsi.org/mantis/file_download.php?file_id=4074&type=bug
docx CR8108-r1.docx (80,749) 11-11-2022 10:53
http://oldforge.etsi.org/mantis/file_download.php?file_id=4079&type=bug
Issue History
Date ModifiedUsernameFieldChange
16-08-2022 07:43Matthias SimonNew Issue
16-08-2022 09:03Jens GrabowskiNote Added: 0016212
16-08-2022 09:04Jens GrabowskiAssigned To => Jens Grabowski
16-08-2022 09:04Jens GrabowskiStatusnew => assigned
08-11-2022 11:59Jens GrabowskiAssigned ToJens Grabowski => Axel Rennoch
09-11-2022 11:44Axel RennochFile Added: CR8108.docx
09-11-2022 11:45Axel RennochNote Added: 0016274
09-11-2022 11:45Axel RennochAssigned ToAxel Rennoch => Matthias Simon
09-11-2022 11:45Axel RennochStatusassigned => confirmed
09-11-2022 15:46Matthias SimonNote Added: 0016281
09-11-2022 15:51Matthias SimonNote Edited: 0016281bug_revision_view_page.php?bugnote_id=16281#r599
09-11-2022 16:25Matthias SimonNote Added: 0016282
10-11-2022 21:05Matthias SimonAssigned ToMatthias Simon => Axel Rennoch
11-11-2022 10:53Axel RennochFile Added: CR8108-r1.docx
11-11-2022 10:54Axel RennochAssigned ToAxel Rennoch => Matthias Simon
11-11-2022 10:54Axel RennochStatusconfirmed => assigned
11-11-2022 10:55Axel RennochNote Added: 0016308
06-12-2022 10:08Matthias SimonAssigned ToMatthias Simon => Axel Rennoch
06-12-2022 13:12Jens GrabowskiStatusassigned => resolved
06-12-2022 13:12Jens GrabowskiResolutionopen => fixed
06-12-2022 13:12Jens GrabowskiAssigned ToAxel Rennoch => Jens Grabowski
04-01-2023 11:12Jens GrabowskiNote Added: 0016463
04-01-2023 11:12Jens GrabowskiStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0016212) +
+ Jens Grabowski    +
+ 16-08-2022 09:03    +
+ 		+ + + + +
+ TTF Discussion: Examples are correct and should be added.
+
+
+
+ + + + + + + + + + +
+ (0016274) +
+ Axel Rennoch    +
+ 09-11-2022 11:45    +
+ 		+ + + + +
+ Examples have been added.
+
+Please check to resolve the issue.
+
+
+
+ + + + + + + + + + +
+ (0016281) +
+ Matthias Simon    +
+ 09-11-2022 15:46    +
(edited on: 09-11-2022 15:51)
+ 		+ + + + +
+ Do you think we should find a different term for "explicit scopes"?
+Because we don't use "explicit scope" anywhere else in the standard. Similarly, I would suggest to rename:
+* "field labels" to "field identifiers"
+* "enumeration labels" to "enumerated values"
+
+I think a consistent use of terms is beneficial. How about:
+
+EXAMPLE 4: User defined type scopes
+
+    module A {
+        type record B { // Identifiers for fields of structured types do not have to be globally unique identifiers
+            integer A, // no name clash with module identifier
+            integer B // no name clash with record identifier
+        }
+
+        type enumerated C { // Identifiers for enumerated do not have to be globally unique
+            // TODO: See follow up comment.
+    }
+
+Further I think we have to discuss, if my proposed example for enumerated types is not correct.
+
+
+
+
+
+ + + + + + + + + + +
+ (0016282) +
+ Matthias Simon    +
+ 09-11-2022 16:25    +
+ 		+ + + + +
+ I believe my enumerated type example is not correct:
+
+    type enumerated C {
+        A, // name clash with module identifier
+        B, // name clash with identifier of previous record definition
+        C, // name clash with identifier of enumerated type
+    }
+
+The enumerated values violate restriction [1]:
+
+> # Chapter 5.2.2 "Uniqueness of identifiers":
+> [1] enumerated values [...] within the same module [...] shall only be reused:
+> [1a] for enumerated values within other enumerated types
+> [1b] as identifiers for fields of structured types
+
+
+
+ + + + + + + + + + +
+ (0016308) +
+ Axel Rennoch    +
+ 11-11-2022 10:55    +
+ 		+ + + + +
+ Please check the modified solution following your notes.
+
+
+
+ + + + + + + + + + +
+ (0016463) +
+ Jens Grabowski    +
+ 04-01-2023 11:12    +
+ 		+ + + + +
+ Implemented as proposed in resolution.
+
+ + diff --git a/docs/mantis/CR8109.md b/docs/mantis/CR8109.md new file mode 100644 index 0000000000000000000000000000000000000000..042d13e572951da90358296baa62f768b3f6d06e --- /dev/null +++ b/docs/mantis/CR8109.md @@ -0,0 +1,72 @@ + + + + + + + + + + + + + 0008109: Examples for map templates needed - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008109Part 01: TTCN-3 Core LanguageClarificationpublic16-08-2022 07:5117-08-2022 08:12
ReporterMatthias Simon 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionwon't fix 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Clause Reference(s)Core Language Spec
Source (company - Author)Nokia - Matthias Simon
Summary0008109: Examples for map templates needed
DescriptionThe core language standard states that all component data types my be used to create templates. It should include the map data types.
+However I am missing some examples, how matching would look like. Would this be valid TTCN-3:
+
+// type map from integer to integer M;
+
+var M m := { [1] := 1, [2] := 4, [3] := 9, [4] := 16 }
+log(match(m, M:{[3]:=9, *}) // logs true
+log(match(m.to, M.to:{9, *}) // logs true
+
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
16-08-2022 07:51Matthias SimonNew Issue
16-08-2022 08:40Jens GrabowskiNote Added: 0016211
16-08-2022 14:17Jens GrabowskiProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
17-08-2022 08:12Jens GrabowskiAssigned To => Jens Grabowski
17-08-2022 08:12Jens GrabowskiStatusnew => assigned
17-08-2022 08:12Jens GrabowskiStatusassigned => closed
17-08-2022 08:12Jens GrabowskiResolutionopen => won't fix
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0016211) +
+ Jens Grabowski    +
+ 16-08-2022 08:40    +
+ 		+ + + + +
+ TTF Discussion: Templates of map types are not allowed, see Rule 6.2.15.1 Map Type Definition, Restriction (a)
+
+ + diff --git a/docs/mantis/CR8110.md b/docs/mantis/CR8110.md new file mode 100644 index 0000000000000000000000000000000000000000..dbe5b5ccdc80b56ac0c6517fbdd011bcce10d31b --- /dev/null +++ b/docs/mantis/CR8110.md @@ -0,0 +1,161 @@ + + + + + + + + + + + + + 0008110: When are global constants evaluated? - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008110Part 06: TTCN-3 Control InterfaceClarificationpublic17-08-2022 06:5704-01-2023 10:46
ReporterMatthias Simon 
Assigned ToTomas Urban 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Clause Reference(s)Operational semantics
Source (company - Author)Nokia -- Matthias Simon
Summary0008110: When are global constants evaluated?
DescriptionConsider following example:
+
+    module M {
+            // Constant c is depending on module parameter mpar
+        const integer c := mpar*2;
+
+                // Module parameter is initialized, when a control or testcase is executed.
+        modulepar integer mpar
+
+        control {
+           execute(tc1());
+           execute(tc2());
+        }
+
+        testcase tc1() { log(c); }
+        testcase tc2() { log(c); }
+
+    }
+
+Scenario 1: Control part is executed via `tciRootModule M; tciStartControl` operations.
+Expected: I'd expect the module parameter mpar will be initialized only once and we'll observe
+the same value for c logged twice (once by M.tc1 and once by M.tc2).
+
+Scenario 2: Testcases M.tc1 and M.tc2 are executed sequentally via `tciRootModule M; tciStartTestCase M.tc1; tciStartTestCase M.tc2` operations.
+Expected: I'd expect the module parameter mpar will be initialized once by M.tc1 and
+later again possibly with a different value by M.tc2. We would observe
+different values for c.
+
+Are my expectations accurate? I could not find details about that in the standards.
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR-8110.docx (159,893) 06-12-2022 08:01
http://oldforge.etsi.org/mantis/file_download.php?file_id=4082&type=bug
Issue History
Date ModifiedUsernameFieldChange
17-08-2022 06:57Matthias SimonNew Issue
17-08-2022 10:40Jens GrabowskiAssigned To => Tomas Urban
17-08-2022 10:40Jens GrabowskiStatusnew => assigned
17-08-2022 10:41Jens GrabowskiProjectTTCN-3 Change Requests => Part 06: TTCN-3 Control Interface
17-08-2022 10:41Jens GrabowskiNote Added: 0016231
06-12-2022 08:01Tomas UrbanFile Added: CR-8110.docx
06-12-2022 08:02Tomas UrbanNote Added: 0016317
06-12-2022 08:02Tomas UrbanAssigned ToTomas Urban => Matthias Simon
06-12-2022 08:02Tomas UrbanStatusassigned => confirmed
06-12-2022 10:43Matthias SimonAssigned ToMatthias Simon => Tomas Urban
06-12-2022 10:43Matthias SimonStatusconfirmed => assigned
06-12-2022 10:44Tomas UrbanStatusassigned => resolved
06-12-2022 10:44Tomas UrbanResolutionopen => fixed
04-01-2023 10:46Tomas UrbanNote Added: 0016459
04-01-2023 10:46Tomas UrbanStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0016231) +
+ Jens Grabowski    +
+ 17-08-2022 10:41    +
+ 		+ + + + +
+ TTF discussion: Tomas will study the issue.
+
+
+
+ + + + + + + + + + +
+ (0016317) +
+ Tomas Urban    +
+ 06-12-2022 08:02    +
+ 		+ + + + +
+ Resolution uploaded.
+Please check.
+
+
+
+ + + + + + + + + + +
+ (0016459) +
+ Tomas Urban    +
+ 04-01-2023 10:46    +
+ 		+ + + + +
+ Added to the TCI stable draft.
+
+ + diff --git a/docs/mantis/CR8111.md b/docs/mantis/CR8111.md new file mode 100644 index 0000000000000000000000000000000000000000..081225381723cd578b8bc940d6f05435b14a97dc --- /dev/null +++ b/docs/mantis/CR8111.md @@ -0,0 +1,357 @@ + + + + + + + + + + + + + 0008111: Allow UTF-8 for charstrings? - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008111Part 01: TTCN-3 Core LanguageNew Featurepublic17-08-2022 06:5822-11-2024 09:45
ReporterMatthias Simon 
Assigned ToTomas Urban 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusresolvedResolutionopen 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Clause Reference(s)Core Language Spec
Source (company - Author)Nokia -- Matthias Simon
Summary0008111: Allow UTF-8 for charstrings?
DescriptionIn recent years UTF-8 has become the de-facto standard for encoding strings.
+TTCN-3 files are also encoded using UTF-8.
+Maybe we should allow UTF-8 encoding for charstrings as well?
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
17-08-2022 06:58Matthias SimonNew Issue
17-08-2022 10:17Jens GrabowskiProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
17-08-2022 10:32Jens GrabowskiNote Added: 0016230
17-08-2022 10:32Jens GrabowskiAssigned To => Jens Grabowski
17-08-2022 10:32Jens GrabowskiStatusnew => assigned
10-11-2022 10:23Jens GrabowskiNote Added: 0016289
10-11-2022 10:23Jens GrabowskiAssigned ToJens Grabowski => Axel Rennoch
10-11-2022 11:56Axel RennochNote Added: 0016293
10-11-2022 11:57Axel RennochAssigned ToAxel Rennoch => Matthias Simon
10-11-2022 13:45Jens GrabowskiNote Added: 0016298
10-11-2022 13:49Jens GrabowskiNote Added: 0016299
10-11-2022 13:50Jens GrabowskiAssigned ToMatthias Simon => Tomas Urban
06-12-2022 09:47Tomas UrbanNote Added: 0016331
08-09-2023 22:45Jens GrabowskiAssigned ToTomas Urban => Gusztáv Adamis
07-11-2023 13:23Jens GrabowskiNote Added: 0016530
07-11-2023 13:24Jens GrabowskiAssigned ToGusztáv Adamis => Tomas Urban
26-01-2024 16:26Olivier GenoudNote Added: 0016606
22-11-2024 09:45Tomas UrbanNote Added: 0016703
22-11-2024 09:45Tomas UrbanStatusassigned => resolved
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0016230) +
+ Jens Grabowski    +
+ 17-08-2022 10:32    +
+ 		+ + + + +
+ TTF discussion: Encoding of charstring should not matter. The encoding should be handled by on encoder level and not on language level. The duality of character encoding should be removed, if not possible deprecated.
+
+
+
+ + + + + + + + + + +
+ (0016289) +
+ Jens Grabowski    +
+ 10-11-2022 10:23    +
+ 		+ + + + +
+ Axel, can you have a look?
+
+
+
+ + + + + + + + + + +
+ (0016293) +
+ Axel Rennoch    +
+ 10-11-2022 11:56    +
+ 		+ + + + +
+ Currently "charstring" is based on Recommendation ITU-T T.50, a document referenced multiple times in TTCN-3. Other character standards like e.g. ISO/IEC 10646 are possible using "universal charstring".
+
+TTCN-3 had been created in the telecommunition domain and is also published by ITU-T. Any changes for the current definitions may effect the ITU-T position.
+
+
+
+ + + + + + + + + + +
+ (0016298) +
+ Jens Grabowski    +
+ 10-11-2022 13:45    +
+ 		+ + + + +
+ TTF discussion: Charstring and Universal Charstring should become synonyms.
+
+
+
+ + + + + + + + + + +
+ (0016299) +
+ Jens Grabowski    +
+ 10-11-2022 13:49    +
+ 		+ + + + +
+ TTF discussion: Tomas to look into consequences for TCI.
+
+
+
+ + + + + + + + + + +
+ (0016331) +
+ Tomas Urban    +
+ 06-12-2022 09:47    +
+ 		+ + + + +
+ TCI constitutes a serious problem. Unfortunately there's no way to have a Java class that implements both CharstringValue and UniversalCharstringValue interfaces. The interfaces contain the same method getChar with different return types. All other language mappings work fine though.
+
+There are two possible solutions, but both have drawbacks:
+1. Introduce a new interface that could be implemented along the existing ones where the getChar method is replaced with getAt (and setChar replaced with setAt for consistency reasons):
+
+package org.etsi.ttcn.tci;
+public interface CStringValue {
+String getString ();
+void setString (String value);
+int getAt (int position);
+void setAt (int position, int value);
+int getLength ();
+void setLength (int len);
+}
+
+Newly written code can use the new interface and legacy code would still work. The old interfaces would be changed to deprecated, but continue to work in order to provide backwards compatible solution for legacy code. However, it means that the TE would still have to track whether the underlying type is charstring or universal charstring in order to provide a correct legacy interface to Java-based TCI implementations.
+
+2. We could modify the getChar in the Java CharstringValue interface to return an integer value. It is a backwards incompatible change, so this might be a red flag for us. However, the fix in legacy software would be an easy one: explicitly casting the return value to char. All places requiring the fix would be detected by the compiler. A similar change would be made in the setChar method, but this one is backwards compatible. The biggest advantage comparing to the first approach is that charstring and universal charstring types would become true synonyms as the TE wouldn't have to consider the underlying type when passing the data to the TCI.
+
+
+
+ + + + + + + + + + +
+ (0016530) +
+ Jens Grabowski    +
+ 07-11-2023 13:23    +
+ 		+ + + + +
+ TTF discussion: To be resolved in the 2024 series of standards. Tomas to take care of TCI.
+
+
+
+ + + + + + + + + + +
+ (0016606) +
+ Olivier Genoud    +
+ 26-01-2024 16:26    +
+ 		+ + + + +
+ It would be appreciated when there is only one 'charstring' type instead of 'charstring' and 'univer-sal charstring'.
+
+
+
+ + + + + + + + + + +
+ (0016703) +
+ Tomas Urban    +
+ 22-11-2024 09:45    +
+ 		+ + + + +
+ Moved to gitlab: https://labs.etsi.org/rep/mts/ttcn3/standard/-/issues/27 [^]
+
+ + diff --git a/docs/mantis/CR8112.md b/docs/mantis/CR8112.md new file mode 100644 index 0000000000000000000000000000000000000000..7777488b39ddc5ffc6bb4644b875002c96cc3ca2 --- /dev/null +++ b/docs/mantis/CR8112.md @@ -0,0 +1,179 @@ + + + + + + + + + + + + + 0008112: Combine boolean and bitwise operators. - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - TTCN-3 Change Requests
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008112TTCN-3 Change RequestsNew Featurepublic17-08-2022 07:1223-01-2024 09:57
ReporterMatthias Simon 
Assigned ToTomas Urban 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionwon't fix 
PlatformOSOS Version
Clause Reference(s)Core Language Spec
For STF discussion
Source (company - Author)Nokia -- Matthias Simon
Summary0008112: Combine boolean and bitwise operators.
DescriptionCurrently TTCN-3 distinguishes between boolean operators (and, or, not, ...) and bitwise operators (xor4b, and4b, or4b, not4b, ...) for bit string types.
+ 
+Combining those operators would reduce diversity towards a simpler TTCN-3 grammar.
+
+Examples:
+
+    0b'1100' xor 0b'1010' // 0b'0110'
+    false xor false // false
+    true xor false // true
+
+
+The original bitwise operators would be deprecated.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
17-08-2022 07:12Matthias SimonNew Issue
17-08-2022 10:04Jens GrabowskiAssigned To => Tomas Urban
17-08-2022 10:04Jens GrabowskiStatusnew => assigned
17-08-2022 10:07Jens GrabowskiNote Added: 0016229
09-11-2022 11:33Tomas UrbanNote Added: 0016273
09-11-2022 12:46Jens GrabowskiNote Added: 0016279
09-11-2022 12:46Jens GrabowskiNote Added: 0016280
09-11-2022 12:46Jens GrabowskiStatusassigned => closed
09-11-2022 12:46Jens GrabowskiResolutionopen => won't fix
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0016229) +
+ Jens Grabowski    +
+ 17-08-2022 10:07    +
+ 		+ + + + +
+ TTF discussion: "Merging" of all operators should be checked.
+
+
+
+ + + + + + + + + + +
+ (0016273) +
+ Tomas Urban    +
+ 09-11-2022 11:33    +
+ 		+ + + + +
+ Input for discussion:
+Impossible to achieve as proposed as the change would break operator precedence.
+Simplification in java/C++/C# style is possible for logical operators: &&, ||, ! (^^ could be introduced for logical xor) and most of bitwise operators: |, ^, ~
+A similar change is problematic for bitwise operators as & is used for concatenation with a similar scope. Could be resolved with a different symbol, such as #, $ or combination of symbols e.g. :&
+
+
+
+ + + + + + + + + + +
+ (0016279) +
+ Jens Grabowski    +
+ 09-11-2022 12:46    +
+ 		+ + + + +
+ TTF discussion: Operators are in use and a change would not be backwards compatible. Therefore the change cannot be done.
+
+
+
+ + + + + + + + + + +
+ (0016280) +
+ Jens Grabowski    +
+ 09-11-2022 12:46    +
+ 		+ + + + +
+ Non backwards compatible change.
+
+ + diff --git a/docs/mantis/CR8113.md b/docs/mantis/CR8113.md new file mode 100644 index 0000000000000000000000000000000000000000..214aeb8d604daf878f48083b4cd8590b354782be --- /dev/null +++ b/docs/mantis/CR8113.md @@ -0,0 +1,559 @@ + + + + + + + + + + + + + 0008113: Type traits and user defined methods - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - TTCN-3 Change Requests
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008113TTCN-3 Change RequestsNew Featurepublic17-08-2022 07:1416-12-2024 12:49
ReporterMatthias Simon 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusresolvedResolutionfixed 
PlatformOSOS Version
Clause Reference(s)New Extension
For STF discussion
Source (company - Author)Nokia -- Matthias Simon
Summary0008113: Type traits and user defined methods
DescriptionType traits allow to compose behavior in a lightweight, but powerful way.
+
+## Methods
+
+This extensions allows to specify methods for any user defined types. The
+receiver type is specified using the "for" keyword. Inside the behavior the
+receiver value is accessible via "this" symbol:
+
+        module Example {
+        type integer Timestamp
+        function year() for Timestamp return string {
+            return int2str(1970+this/SECONDS_PER_YEAR);
+        }
+
+        control {
+            const Timestamp t := 1660681400;
+            log(t.year()) // logs "2022"
+        }
+    }
+
+
+## Traits
+
+A trait is a set of methods and can be defined using the "trait" keyword:
+
+    trait Stringer {
+        function String() charstring;
+    }
+
+A variable of a trait type can hold any value that implements the trait:
+
+    module Example {
+
+        type record Point2D { integer x, integer y }
+        function string() for Point3D return charstring {
+            return sprintf("(%d|%d)", this.x, this.y)
+        }
+
+        type record Point3D { integer x, integer y, integer z }
+        function string() for Point2D return charstring {
+            return sprintf("(%d|%d|%d)", this.x, this.y, this.z)
+        }
+
+        trait Stringer {
+            function string() charstring;
+        }
+
+        function logPoints(Stringer s) {
+            log(s.string())
+        }
+
+        control {
+            var Point2D p1 := {1,2};
+            var Point3D p2 := {1,2,3}
+
+            logPoints(p1); // okay because Point2D implements Stringer trait
+            logPoints(p2); // okay because Point3D also implements Stringer trait
+        }
+    }
+
+
+## Embedding
+
+When the field name is omitted, the field is called an embedded field:
+
+    type integer Timestamp;
+    external function year() for Timestamp return charstring;
+
+    type record Date {
+        Timestamp, // embedded field
+        charstring zone // regular field
+    }
+
+
+An embedded field is accessible by its type name:
+
+    var Data d := { Timestamp := 1660681400, zone := "GMT+2" };
+    d.Timestamp := d.Timestamp + 3600;
+
+
+Embedded fields must be unique:
+
+    type record Date {
+        Timestamp,
+        Timestamp // not allowed.
+    }
+
+
+Methods of an embedded field are promoted and become methods of the embedding type:
+
+    var Data d := { Timestamp := 1660681400, zone := "GMT+2" };
+    log(d.year()); // year is a promoted method implemented by the Timestamp type
+
+
+Conflicting promoted methods have to be resolved explicitly:
+
+    type integer Duration;
+    external function year() for Duration return charstring;
+
+    type record Event {
+        Timestamp,
+        Duration
+    }
+
+    // Timestamp and Duration both provide a "year"-method. Event type need
+    // to resolve this conflict explicitly:
+    function year() for Event return charstring {
+        return sprintf("start=%s, duration=%s", this.Timestamp, this.Duration)
+    }
+
+
+## Notes and Open Questions
+
+* Should we call it "trait" or rather "interface" like in Java, C# and Go?
+* Should we support default implementations for traits (requires "implements" keyword)?
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
17-08-2022 07:14Matthias SimonNew Issue
17-08-2022 07:16Matthias SimonDescription Updatedbug_revision_view_page.php?rev_id=587#r587
17-08-2022 09:53Jens GrabowskiNote Added: 0016228
17-08-2022 09:53Jens GrabowskiAssigned To => Matthias Simon
17-08-2022 09:53Jens GrabowskiStatusnew => assigned
08-11-2022 08:15Matthias SimonNote Added: 0016267
08-11-2022 08:22Matthias SimonNote Edited: 0016267bug_revision_view_page.php?rev_id=595
08-11-2022 08:23Matthias SimonNote Edited: 0016267bug_revision_view_page.php?rev_id=596
08-11-2022 08:25Matthias SimonNote Edited: 0016267bug_revision_view_page.php?rev_id=597
10-11-2022 09:05Matthias SimonNote Edited: 0016267bug_revision_view_page.php?rev_id=600
10-11-2022 09:24Matthias SimonNote Deleted: 0016267
10-11-2022 09:52Matthias SimonNote Added: 0016287
10-11-2022 10:06Matthias SimonNote Edited: 0016287bug_revision_view_page.php?bugnote_id=16287#r602
10-11-2022 10:46Tomas UrbanNote Added: 0016290
10-11-2022 12:50Matthias SimonNote Edited: 0016287bug_revision_view_page.php?bugnote_id=16287#r603
07-12-2022 08:26Jens GrabowskiNote Added: 0016363
12-12-2022 09:01Matthias SimonNote Added: 0016382
12-12-2022 14:37Matthias SimonNote Added: 0016388
20-12-2022 11:45Jens GrabowskiNote Added: 0016437
08-11-2023 13:01Jens GrabowskiNote Added: 0016552
08-11-2023 13:01Jens GrabowskiAssigned ToMatthias Simon => Jens Grabowski
26-01-2024 16:27Olivier GenoudNote Added: 0016607
16-12-2024 12:49Jens GrabowskiNote Added: 0016726
16-12-2024 12:49Jens GrabowskiStatusassigned => resolved
16-12-2024 12:49Jens GrabowskiResolutionopen => fixed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0016228) +
+ Jens Grabowski    +
+ 17-08-2022 09:53    +
+ 		+ + + + +
+ TTF discussion: CR should be splitted into Methods & Traits and Embedded Fields. Matthias will make more complete proposals. Questions to be answered are related to import and type compatibility.
+
+
+
+ + + + + + + + + + +
+ (0016287) +
+ Matthias Simon    +
+ 10-11-2022 09:52    +
(edited on: 10-11-2022 12:50)
+ 		+ + + + +
+ What syntax for defining methods do your prefer?
+
+# Free floating (like in Go, Perl, ...)
+
+Example:
+    function F() for T runs on C return boolean {
+        return this > 5;
+    }
+
+Variations:
+    function F() with T ...
+    function F() extends T ...
+    function F() on T ...
+    function F() to T ...
+    function F() at T ...
+    function F() in T ...
+    function F() -> T ...
+    function F() => T ...
+    on T function F() ...
+    function for T F() ...
+
+     
+# Qualified names (like in C++)
+
+Example:
+    function T::F() runs on C return boolean {
+        return this > 5;
+    }
+
+Variations:
+    function T.F() ...
+    function T:F() ...
+
+
+# Nested declarations (like in Java, Python, ...)
+
+Example:
+    type record T {
+        integer x,
+        function F() runs on C return boolean { return true },
+        integer y
+    }
+
+    type integer I8 (-127..128) {
+        function F() runs on C return boolean { return true };
+    }
+
+
+# Dedicated method block
+
+Example:
+    type record T {
+        integer x,
+        integer y
+    } with {
+        function F() runs on C return boolean { return true };
+    }
+
+    type integer I8 (-127..128) with {
+        function F() runs T return boolean { return true };
+    }
+
+Variations:
+    type integer I8 extends { ... }
+    type integer I8 implements { ... }
+    type integer I8 group { ... }
+    type integer I8 bind { ... }
+    type integer I8 connect { ... }
+
+
+
+
+
+ + + + + + + + + + +
+ (0016290) +
+ Tomas Urban    +
+ 10-11-2022 10:46    +
+ 		+ + + + +
+ This is a topic for a discussion.
+
+Free floating syntax resembles what we already have in TTCN-3. It can extend built-in types as well. However, there are two major problems that are not easy to resolve (valid for qualified names too):
+1. Import of traits, especially when they are defined in a different module than the type (could be resolved by dedicated import rules)
+2. Violation of scoping principles of TTCN-3: So far all lower scopes are declared inside a definition. Using free floating could lead to traits with the same name but different functionality being present in more than one module and we would need a whole set of rule for handling that.
+
+For these reasons, I would prefer an encapsulation approach. Out of the proposed options I like nested declarations more, because the syntax doesn't use excess symbols.
+
+
+
+ + + + + + + + + + +
+ (0016363) +
+ Jens Grabowski    +
+ 07-12-2022 08:26    +
+ 		+ + + + +
+ TTF discussion: Open questions are related to syntax and semantics. Unclear where to put this CR. May become part of core language or may become part of the OO extension. Resolution of issues should be discussed in the scope of language renovation.
+
+
+
+ + + + + + + + + + +
+ (0016382) +
+ Matthias Simon    +
+ 12-12-2022 09:01    +
+ 		+ + + + +
+ Split of embedded fields part: http://oldforge.etsi.org/mantis/view.php?id=8154 [^]
+
+
+
+ + + + + + + + + + +
+ (0016388) +
+ Matthias Simon    +
+ 12-12-2022 14:37    +
+ 		+ + + + +
+ Split of methods part: http://oldforge.etsi.org/mantis/view.php?id=8156 [^]
+
+
+
+ + + + + + + + + + +
+ (0016437) +
+ Jens Grabowski    +
+ 20-12-2022 11:45    +
+ 		+ + + + +
+ TTF discussion: Proposal will not be finalized and agreed upon until end of year. Proposal will be prepared until end of the year. To be shifted into the next TTF.
+
+
+
+ + + + + + + + + + +
+ (0016552) +
+ Jens Grabowski    +
+ 08-11-2023 13:01    +
+ 		+ + + + +
+ TTF discussion: To be discussed in the scope of OO features in new major release.
+
+
+
+ + + + + + + + + + +
+ (0016607) +
+ Olivier Genoud    +
+ 26-01-2024 16:27    +
+ 		+ + + + +
+ We assume/expect that this CR will not become part of the core language but will become part of an extension or be added to an extension (e.g. OO extension).
+
+
+
+ + + + + + + + + + +
+ (0016726) +
+ Jens Grabowski    +
+ 16-12-2024 12:49    +
+ 		+ + + + +
+ Discussion continues in Gitlab
+
+ + diff --git a/docs/mantis/CR8114.md b/docs/mantis/CR8114.md new file mode 100644 index 0000000000000000000000000000000000000000..ed859a5d300cdd44236498b9040a2671b462cbe2 --- /dev/null +++ b/docs/mantis/CR8114.md @@ -0,0 +1,207 @@ + + + + + + + + + + + + + 0008114: Template support for the map type - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008114Part 01: TTCN-3 Core LanguageTechnicalpublic17-08-2022 09:1004-01-2023 08:53
ReporterTomas Urban 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Clause Reference(s)6.2.15, 15
Source (company - Author)TTFT023
Summary0008114: Template support for the map type
DescriptionAdd all necessary features allowing to create and use templates of the map type.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR-8114.docx (263,875) 08-12-2022 09:47
http://oldforge.etsi.org/mantis/file_download.php?file_id=4090&type=bug
Issue History
Date ModifiedUsernameFieldChange
17-08-2022 09:10Tomas UrbanNew Issue
17-08-2022 09:21Jens GrabowskiProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
17-08-2022 09:24Jens GrabowskiNote Added: 0016227
17-08-2022 09:24Jens GrabowskiAssigned To => Tomas Urban
17-08-2022 09:24Jens GrabowskiStatusnew => assigned
06-12-2022 12:53Tomas UrbanNote Added: 0016359
08-12-2022 09:47Tomas UrbanFile Added: CR-8114.docx
08-12-2022 09:47Tomas UrbanNote Added: 0016372
08-12-2022 09:47Tomas UrbanAssigned ToTomas Urban => Jens Grabowski
08-12-2022 09:47Tomas UrbanStatusassigned => confirmed
16-12-2022 09:19Jens GrabowskiNote Added: 0016424
16-12-2022 09:19Jens GrabowskiStatusconfirmed => resolved
16-12-2022 09:19Jens GrabowskiResolutionopen => fixed
04-01-2023 08:53Jens GrabowskiNote Added: 0016450
04-01-2023 08:53Jens GrabowskiStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0016227) +
+ Jens Grabowski    +
+ 17-08-2022 09:24    +
+ 		+ + + + +
+ TTF discussion: Support may be beneficially (e.g., in the context of JSON). Not highest priority. Tomas will study the subject.
+
+
+
+ + + + + + + + + + +
+ (0016359) +
+ Tomas Urban    +
+ 06-12-2022 12:53    +
+ 		+ + + + +
+ Matching symbols for the whole map can be easily supported (?, *, omit). The biggest issue is on the element level where the standard should provide support for two different situations:
+1. A template that matches only the specified elements (and no other elements can be present).
+2. A template that matches the specified elements and all unspecified elements are ignored.
+
+Possible syntax proposal for 0000002 (but there might be better ideas):
+type map from charstring to integer MyMapType;
+template MyMapType mw_map1 := { ["black"] := 23, ["white"] := ?, * } // asterisk as the last symbol
+
+I my opinion, the elements inside matching templates of the map should behave as optional items in records, so that the user can use ?, *, omit and ifpresent for them.
+
+
+
+ + + + + + + + + + +
+ (0016372) +
+ Tomas Urban    +
+ 08-12-2022 09:47    +
+ 		+ + + + +
+ Resolution uploaded. Please check.
+
+
+
+ + + + + + + + + + +
+ (0016424) +
+ Jens Grabowski    +
+ 16-12-2022 09:19    +
+ 		+ + + + +
+ ok from my side
+
+
+
+ + + + + + + + + + +
+ (0016450) +
+ Jens Grabowski    +
+ 04-01-2023 08:53    +
+ 		+ + + + +
+ Implemented as proposed.
+
+ + diff --git a/docs/mantis/CR8115.md b/docs/mantis/CR8115.md new file mode 100644 index 0000000000000000000000000000000000000000..8ff0c77d0c0a1499a9e8aa5d837396faac145888 --- /dev/null +++ b/docs/mantis/CR8115.md @@ -0,0 +1,138 @@ + + + + + + + + + + + + + 0008115: Explanation fuzzy/lazy is the opposite - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008115Part 01: TTCN-3 Core LanguageEditorialpublic23-08-2022 15:4704-01-2023 09:43
ReporterGusztáv Adamis 
Assigned ToJens Grabowski 
PrioritylowSeveritytextReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version4.12.1 (published 2020-05) 
Target VersionFixed in Version 
Clause Reference(s)5.4.1.0
Source (company - Author)     Gusztáv Adamis Ericsson
Summary0008115: Explanation fuzzy/lazy is the opposite
DescriptionIn 5.4.1.0
+"Formal value or template parameters may be declared lazy using the @lazy modifier. The behaviour of fuzzy parameters is defined in clause 3.1, definition of lazy values or templates. See examples in clause 5.4.1.1.
+Formal value or template parameters may be declared fuzzy using the @fuzzy modifier. The behaviour of lazy parameters is defined in clause 3.1, definition of fuzzy values or templates. See examples in clause 5.4.1.1."
+
+In these paragraphs in the second sentences the fuzzy used to explain lazy, and vice versa, so they shall be changed to:
+Formal value or template parameters may be declared lazy using the @lazy modifier. The behaviour of lazy parameters is defined in clause 3.1, definition of lazy values or templates. See examples in clause 5.4.1.1.
+Formal value or template parameters may be declared fuzzy using the @fuzzy modifier. The behaviour of fuzzy parameters is defined in clause 3.1, definition of fuzzy values or templates. See examples in clause 5.4.1.1.
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR-8115.docx (195,137) 09-11-2022 09:36
http://oldforge.etsi.org/mantis/file_download.php?file_id=4072&type=bug
Issue History
Date ModifiedUsernameFieldChange
23-08-2022 15:47Gusztáv AdamisNew Issue
07-11-2022 09:12Jens GrabowskiAssigned To => Tomas Urban
07-11-2022 09:12Jens GrabowskiStatusnew => assigned
09-11-2022 09:36Tomas UrbanFile Added: CR-8115.docx
09-11-2022 09:37Tomas UrbanNote Added: 0016270
09-11-2022 09:37Tomas UrbanAssigned ToTomas Urban => Axel Rennoch
09-11-2022 09:37Tomas UrbanStatusassigned => confirmed
09-11-2022 11:51Axel RennochNote Added: 0016275
09-11-2022 11:51Axel RennochStatusconfirmed => resolved
09-11-2022 11:51Axel RennochResolutionopen => fixed
09-11-2022 11:51Axel RennochAssigned ToAxel Rennoch => Jens Grabowski
04-01-2023 09:43Jens GrabowskiNote Added: 0016455
04-01-2023 09:43Jens GrabowskiStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0016270) +
+ Tomas Urban    +
+ 09-11-2022 09:37    +
+ 		+ + + + +
+ Changed as proposed. Please check.
+
+
+
+ + + + + + + + + + +
+ (0016275) +
+ Axel Rennoch    +
+ 09-11-2022 11:51    +
+ 		+ + + + +
+ The proposed solution/changes are correct.
+
+
+
+ + + + + + + + + + +
+ (0016455) +
+ Jens Grabowski    +
+ 04-01-2023 09:43    +
+ 		+ + + + +
+ Implemented as proposed.
+
+ + diff --git a/docs/mantis/CR8119.md b/docs/mantis/CR8119.md new file mode 100644 index 0000000000000000000000000000000000000000..b341b44df781ce582321c75c7e93099155c07172 --- /dev/null +++ b/docs/mantis/CR8119.md @@ -0,0 +1,183 @@ + + + + + + + + + + + + + 0008119: Wrong clause references to 16.1.5 -> 16.2.1 - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008119Part 01: TTCN-3 Core LanguageEditorialpublic13-09-2022 15:0404-01-2023 09:24
ReporterGusztáv Adamis 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Clause Reference(s)6.2.8, 16.1.4, 19.12, 20.5.0, 20.5.1
Source (company - Author)     Gusztáv Adamis Ericsson
Summary0008119: Wrong clause references to 16.1.5 -> 16.2.1
DescriptionIn the following clauses the reference to 16.1.5 16.1.5 Explicit control functions
+shall be replaced to 16.2.1 Invoking altsteps
+
+6.2.8 The default type
+TTCN-3 allows the activation of altsteps (see clause 16.1.5) as defaults to capture recurring behaviour.
+
+16.1.4 Invoking functions from specific places
+or in initializations of altstep local definitions (see clause 16.1.5)
+
+19.12 The Break statement
+Altsteps are always executed within a surrounding alt statement. If the execution of a top alternative of an altstep (see
+clause 16.1.5) ends with a break statement
+
+20.5.0 General
+TTCN-3 allows the activation of altsteps (see clause 16.1.5) as defaults.
+
+20.5.1 The default mechanism
+Unsuccessful means that none of the top alternatives of the altstep
+(see clause 16.1.5)
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR-8119-Res-221107.docx (1,405,422) 07-11-2022 13:59
http://oldforge.etsi.org/mantis/file_download.php?file_id=4069&type=bug
Issue History
Date ModifiedUsernameFieldChange
13-09-2022 15:04Gusztáv AdamisNew Issue
13-09-2022 15:17Gusztáv AdamisNote Added: 0016240
07-11-2022 09:11Jens GrabowskiAssigned To => Jens Grabowski
07-11-2022 09:11Jens GrabowskiStatusnew => assigned
07-11-2022 13:59Jens GrabowskiFile Added: CR-8119-Res-221107.docx
07-11-2022 13:59Jens GrabowskiNote Added: 0016263
07-11-2022 14:00Jens GrabowskiProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
07-11-2022 14:00Jens GrabowskiNote Added: 0016264
07-11-2022 14:00Jens GrabowskiStatusassigned => resolved
07-11-2022 14:00Jens GrabowskiResolutionopen => fixed
04-01-2023 09:24Jens GrabowskiNote Added: 0016452
04-01-2023 09:24Jens GrabowskiStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0016240) +
+ Gusztáv Adamis    +
+ 13-09-2022 15:17    +
+ 		+ + + + +
+ Shall be moved to Part01: TTCN-3 Core Language
+
+
+
+ + + + + + + + + + +
+ (0016263) +
+ Jens Grabowski    +
+ 07-11-2022 13:59    +
+ 		+ + + + +
+ Resolved as proposed by reporter.
+
+
+
+ + + + + + + + + + +
+ (0016264) +
+ Jens Grabowski    +
+ 07-11-2022 14:00    +
+ 		+ + + + +
+ Resolved as proposed by reporter
+
+
+
+ + + + + + + + + + +
+ (0016452) +
+ Jens Grabowski    +
+ 04-01-2023 09:24    +
+ 		+ + + + +
+ Implemented as proposed.
+
+ + diff --git a/docs/mantis/CR8120.md b/docs/mantis/CR8120.md new file mode 100644 index 0000000000000000000000000000000000000000..9a1f41e3dde00756d741182ef1944bb200c72f23 --- /dev/null +++ b/docs/mantis/CR8120.md @@ -0,0 +1,170 @@ + + + + + + + + + + + + + 0008120: activate/deactivate explanation shall be modified - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008120Part 01: TTCN-3 Core LanguageClarificationpublic13-09-2022 15:2204-01-2023 09:52
ReporterGusztáv Adamis 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Clause Reference(s)20.5.0
Source (company - Author)     Gusztáv Adamis Ericsson
Summary0008120: activate/deactivate explanation shall be modified
DescriptionSince the activate/deactivate have been extended by enabling suspending of defaults, the general description in 20.5.0 shall also reflect this.
+
+"An activate puts a new default
+as the first element into the list and a deactivate removes a default from the list." - it is not true in case of suspending/resuming a default
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR-8120.docx (196,032) 09-11-2022 09:55
http://oldforge.etsi.org/mantis/file_download.php?file_id=4073&type=bug
Issue History
Date ModifiedUsernameFieldChange
13-09-2022 15:22Gusztáv AdamisNew Issue
07-11-2022 09:10Jens GrabowskiNote Added: 0016262
07-11-2022 09:10Jens GrabowskiAssigned To => Tomas Urban
07-11-2022 09:10Jens GrabowskiStatusnew => assigned
09-11-2022 09:55Tomas UrbanFile Added: CR-8120.docx
09-11-2022 09:58Tomas UrbanNote Added: 0016271
09-11-2022 09:58Tomas UrbanAssigned ToTomas Urban => Axel Rennoch
09-11-2022 09:58Tomas UrbanStatusassigned => confirmed
09-11-2022 11:55Axel RennochNote Added: 0016276
09-11-2022 11:55Axel RennochStatusconfirmed => resolved
09-11-2022 11:55Axel RennochResolutionopen => fixed
09-11-2022 11:55Axel RennochAssigned ToAxel Rennoch => Jens Grabowski
04-01-2023 09:52Jens GrabowskiNote Added: 0016456
04-01-2023 09:52Jens GrabowskiStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0016262) +
+ Jens Grabowski    +
+ 07-11-2022 09:10    +
+ 		+ + + + +
+ TTF discussion: To be checked if somewhere this is defined. Sentence needs to be modified.
+
+
+
+ + + + + + + + + + +
+ (0016271) +
+ Tomas Urban    +
+ 09-11-2022 09:58    +
+ 		+ + + + +
+ I changed sections 20.5.0 and 20.5.1 adding rules on handling suspended defaults.
+
+Please review.
+
+
+
+ + + + + + + + + + +
+ (0016276) +
+ Axel Rennoch    +
+ 09-11-2022 11:55    +
+ 		+ + + + +
+ The proposed solution/changes reflect the reported issues about suspended and reactivated defaults.
+
+
+
+ + + + + + + + + + +
+ (0016456) +
+ Jens Grabowski    +
+ 04-01-2023 09:52    +
+ 		+ + + + +
+ Implemented according to resolution attached to the CR.
+
+ + diff --git a/docs/mantis/CR8136.md b/docs/mantis/CR8136.md new file mode 100644 index 0000000000000000000000000000000000000000..af5afbea74f86a1631adf2a0cb1180929e2c9f40 --- /dev/null +++ b/docs/mantis/CR8136.md @@ -0,0 +1,66 @@ + + + + + + + + + + + + + 0008136: Outdated reference in chapter 5.2.2 "Uniqueness of identifiers" - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008136Part 01: TTCN-3 Core LanguageEditorialpublic09-11-2022 16:3204-01-2023 10:24
ReporterMatthias Simon 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Clause Reference(s)5.2.2 Uniqueness of identifiers
Source (company - Author)Nokia - Matthias Simon
Summary0008136: Outdated reference in chapter 5.2.2 "Uniqueness of identifiers"
DescriptionThe reference in the second paragraph of chapter 5.2.2 "Uniqueness of identifiers" is out of date and should be updated:
+
+-see also clause 8.2.3.1, example 4
++see also clause 8.2.3.1, example 5
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR-8136-Res-221216.docx (129,024) 16-12-2022 12:34
http://oldforge.etsi.org/mantis/file_download.php?file_id=4103&type=bug
Issue History
Date ModifiedUsernameFieldChange
09-11-2022 16:32Matthias SimonNew Issue
10-11-2022 13:04Jens GrabowskiAssigned To => Jens Grabowski
10-11-2022 13:04Jens GrabowskiStatusnew => assigned
16-12-2022 12:34Jens GrabowskiFile Added: CR-8136-Res-221216.docx
16-12-2022 12:34Jens GrabowskiStatusassigned => resolved
16-12-2022 12:34Jens GrabowskiResolutionopen => fixed
04-01-2023 10:24Jens GrabowskiNote Added: 0016457
04-01-2023 10:24Jens GrabowskiStatusresolved => closed
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0016457) +
+ Jens Grabowski    +
+ 04-01-2023 10:24    +
+ 		+ + + + +
+ Implemented as proposed.
+
+ + diff --git a/docs/mantis/CR8151.md b/docs/mantis/CR8151.md new file mode 100644 index 0000000000000000000000000000000000000000..7fc76aa457921ee3c43f7e9ae586eb5766b90ac1 --- /dev/null +++ b/docs/mantis/CR8151.md @@ -0,0 +1,141 @@ + + + + + + + + + + + + + 0008151: Update of TTCN-3 version references - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008151Part 01: TTCN-3 Core LanguageEditorialpublic06-12-2022 14:3104-01-2023 09:02
ReporterAxel Rennoch 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionNext version (to be decided)Fixed in Version 
Clause Reference(s)8.1 and 2.2
Source (company - Author)Axel Rennoch
Summary0008151: Update of TTCN-3 version references
DescriptionIn section 8.1:
+---------------
+The language string list need to be updated with:
+"TTCN-3:2021 - to be used with modules complying with V4.13.1 [i.xx] of the present document."
+"TTCN-3:2022 - to be used with modules complying with V4.14.1 [i.yy] of the present document."
+"TTCN-3:2023" - to be used with modules complying with the present document."
+
+In section 2.2:
+----------------
+[i.xx] ETSI ES 201 873-1 (V4.13.1): "Methods for Testing and Specification (MTS); The Testing and Test Control Notation version 3; Part 1: TTCN-3 Core Language", 2021.
+[i.yy] ETSI ES 201 873-1 (V4.14.1): "Methods for Testing and Specification (MTS); The Testing and Test Control Notation version 3; Part 1: TTCN-3 Core Language", 2022.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR8151.docx (84,959) 07-12-2022 10:12
http://oldforge.etsi.org/mantis/file_download.php?file_id=4086&type=bug
Issue History
Date ModifiedUsernameFieldChange
06-12-2022 14:31Axel RennochNew Issue
07-12-2022 08:03Jens GrabowskiAssigned To => Axel Rennoch
07-12-2022 08:03Jens GrabowskiStatusnew => assigned
07-12-2022 10:12Axel RennochFile Added: CR8151.docx
07-12-2022 10:13Axel RennochNote Added: 0016368
07-12-2022 10:13Axel RennochAssigned ToAxel Rennoch => Jens Grabowski
07-12-2022 10:13Axel RennochStatusassigned => confirmed
16-12-2022 09:24Jens GrabowskiNote Added: 0016426
16-12-2022 09:24Jens GrabowskiStatusconfirmed => resolved
16-12-2022 09:24Jens GrabowskiResolutionopen => fixed
04-01-2023 09:02Jens GrabowskiNote Added: 0016451
04-01-2023 09:02Jens GrabowskiStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0016368) +
+ Axel Rennoch    +
+ 07-12-2022 10:13    +
+ 		+ + + + +
+ Please see/use the proposed solution file.
+
+
+
+ + + + + + + + + + +
+ (0016426) +
+ Jens Grabowski    +
+ 16-12-2022 09:24    +
+ 		+ + + + +
+ ok
+
+
+
+ + + + + + + + + + +
+ (0016451) +
+ Jens Grabowski    +
+ 04-01-2023 09:02    +
+ 		+ + + + +
+ Implemented as proposed.
+
+ + diff --git a/docs/mantis/CR8152.md b/docs/mantis/CR8152.md new file mode 100644 index 0000000000000000000000000000000000000000..80ee0e904789cf9c53e2bc42e96da7a8ae75616d --- /dev/null +++ b/docs/mantis/CR8152.md @@ -0,0 +1,238 @@ + + + + + + + + + + + + + 0008152: Harmonize string literals - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008152Part 01: TTCN-3 Core LanguageTechnicalpublic07-12-2022 08:0123-01-2024 09:58
ReporterMatthias Simon 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Clause Reference(s)n/a
Source (company - Author)Nokia - Matthias Simon
Summary0008152: Harmonize string literals
DescriptionIdeas to discuss:
+* Allow pattern string quoting in character strings
+* Allow line breaks in character strings and patterns
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR8152-v1.docx (196,456) 10-11-2023 09:45
http://oldforge.etsi.org/mantis/file_download.php?file_id=4128&type=bug
Issue History
Date ModifiedUsernameFieldChange
07-12-2022 08:01Matthias SimonNew Issue
07-12-2022 08:54Jens GrabowskiNote Added: 0016366
07-12-2022 08:54Jens GrabowskiAssigned To => Jens Grabowski
07-12-2022 08:54Jens GrabowskiStatusnew => assigned
08-11-2023 13:43Jens GrabowskiNote Added: 0016553
08-11-2023 13:50Jens GrabowskiAssigned ToJens Grabowski => Tomas Urban
08-11-2023 13:52Jens GrabowskiNote Added: 0016556
10-11-2023 09:45Tomas UrbanFile Added: CR8152-v1.docx
10-11-2023 09:52Tomas UrbanNote Added: 0016573
10-11-2023 09:52Tomas UrbanAssigned ToTomas Urban => Matthias Simon
10-11-2023 09:52Tomas UrbanStatusassigned => confirmed
10-11-2023 10:56Matthias SimonNote Added: 0016578
10-11-2023 10:56Matthias SimonAssigned ToMatthias Simon => Jens Grabowski
10-11-2023 10:56Matthias SimonStatusconfirmed => resolved
21-12-2023 14:51Jens GrabowskiNote Added: 0016589
21-12-2023 14:51Jens GrabowskiStatusresolved => closed
21-12-2023 14:51Jens GrabowskiResolutionopen => fixed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0016366) +
+ Jens Grabowski    +
+ 07-12-2022 08:54    +
+ 		+ + + + +
+ TTF discussion: Harmonization required because some tools allow string quoting and line breaks. Should be discussed in a broader context regarding string and char handling.
+
+
+
+ + + + + + + + + + +
+ (0016553) +
+ Jens Grabowski    +
+ 08-11-2023 13:43    +
+ 		+ + + + +
+ TTF discussion: CR should be considered in the context of char string harmonization. Not considered in the current TTF.
+
+
+
+ + + + + + + + + + +
+ (0016556) +
+ Jens Grabowski    +
+ 08-11-2023 13:52    +
+ 		+ + + + +
+ TTF discussion: small clarification regarding universial charstring will be implemented.
+
+
+
+ + + + + + + + + + +
+ (0016573) +
+ Tomas Urban    +
+ 10-11-2023 09:52    +
+ 		+ + + + +
+ Since control characters cannot be used in charstrings, I changed the metacharacter definition in patterns so that they reference ISO/IEC 10646 instead of ITU-T T.50 emphasizing the usage in universal charstrings. I removed references to annex A as this connection was coincidental and changing annex A would have more significant impact.
+Please check.
+
+
+
+ + + + + + + + + + +
+ (0016578) +
+ Matthias Simon    +
+ 10-11-2023 10:56    +
+ 		+ + + + +
+ Metacharacter definition has been aligned with universal charstring.
+
+Quoting for other string literals like charstring or hextstring requires more investigation and will be covered by 0008111 (Allow UTF-8 for charstrings).
+
+
+
+ + + + + + + + + + +
+ (0016589) +
+ Jens Grabowski    +
+ 21-12-2023 14:51    +
+ 		+ + + + +
+ Implemented as proposed
+
+ + diff --git a/docs/mantis/CR8153.md b/docs/mantis/CR8153.md new file mode 100644 index 0000000000000000000000000000000000000000..719447ecb42287338e88e11c4825598095f41836 --- /dev/null +++ b/docs/mantis/CR8153.md @@ -0,0 +1,392 @@ + + + + + + + + + + + + + 0008153: Extend usage of break and continue statements - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008153Part 01: TTCN-3 Core LanguageNew Featurepublic11-12-2022 19:2116-12-2024 10:26
ReporterMatthias Simon 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusresolvedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Clause Reference(s)19.2, 19.3
Source (company - Author)Nokia - Matthias Simon
Summary0008153: Extend usage of break and continue statements
Description* Allow break statements in select statements.
+* Allow optional label to break/continue from nested loops
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR8153.docx (114,777) 11-12-2022 20:07
http://oldforge.etsi.org/mantis/file_download.php?file_id=4093&type=bug
Issue History
Date ModifiedUsernameFieldChange
11-12-2022 19:21Matthias SimonNew Issue
11-12-2022 20:07Matthias SimonSummaryAdd optional label to break and continue => Extend usage of break and continue statements
11-12-2022 20:07Matthias SimonDescription Updatedbug_revision_view_page.php?rev_id=607#r607
11-12-2022 20:07Matthias SimonFile Added: CR8153.docx
20-12-2022 12:49Jens GrabowskiNote Added: 0016441
20-12-2022 12:49Jens GrabowskiAssigned To => Jens Grabowski
20-12-2022 12:49Jens GrabowskiStatusnew => assigned
07-11-2023 17:01Jens GrabowskiNote Added: 0016542
09-11-2023 21:15Gusztáv AdamisNote Added: 0016570
10-11-2023 12:03Gusztáv AdamisNote Added: 0016581
26-01-2024 16:27Olivier GenoudNote Added: 0016608
21-11-2024 18:33Matthias SimonNote Added: 0016700
21-11-2024 18:37Matthias SimonNote Edited: 0016700bug_revision_view_page.php?bugnote_id=16700#r625
16-12-2024 10:26Jens GrabowskiNote Added: 0016718
16-12-2024 10:26Jens GrabowskiStatusassigned => resolved
16-12-2024 10:26Jens GrabowskiResolutionopen => fixed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0016441) +
+ Jens Grabowski    +
+ 20-12-2022 12:49    +
+ 		+ + + + +
+ Additional idea: Add label to loop header.
+
+TTF discussion: To be discussed in the scope of the next TTF. Proposal cannot be implemented as proposed for select case statement. It would lead to a backwards incompatible change.
+
+
+
+ + + + + + + + + + +
+ (0016542) +
+ Jens Grabowski    +
+ 07-11-2023 17:01    +
+ 		+ + + + +
+ TTF discussion: Break and Continue shall be analysed in the scope of the major release. Additional ideas include the deprecation of Goto as well as introduction of breaks/continue across several scope units.
+
+
+
+ + + + + + + + + + +
+ (0016570) +
+ Gusztáv Adamis    +
+ 09-11-2023 21:15    +
+ 		+ + + + +
+ After diiscussions within TTF:
+
+Possible solution can be "named cycles"
+while (...) {
+   while (...){
+      break w1; //or continue w1;
+      }
+   } : w1
+
+break w1; will terminate both cycles, execution continues with the next instruction after w1.
+continue w1; will terminate the innermost cycle and takes the next iteration of the "w1" cycle.
+
+Similar construct can be applied for nested alt instructions with break/repeat "named alt").
+
+alt {
+  [] ...{
+          alt {
+            [] ... {break a1;}
+            ...
+          }
+        ...
+  [] ....
+        }
+}: a1;
+
+"altlabels" and "cyclelabels" can be mixed, until they do not "jump" out of the scope.
+
+alt {
+[] ... { while (...) { break a2;}}
+...
+}: a2
+
+If this construct is implemented it may cause to deprecate the goto/label.
+
+
+
+ + + + + + + + + + +
+ (0016581) +
+ Gusztáv Adamis    +
+ 10-11-2023 12:03    +
+ 		+ + + + +
+ The resolution of the ticket shall be postponed to the next major revision.
+
+
+
+ + + + + + + + + + +
+ (0016608) +
+ Olivier Genoud    +
+ 26-01-2024 16:27    +
+ 		+ + + + +
+ It seems to be another flavour of "goto", so we do not see the benefit. On the other hand, it is increasing the complexity of the language allowing further flavours of code writing. Also, we are not aware that code cannot be written using existing means.
+
+
+
+ + + + + + + + + + +
+ (0016700) +
+ Matthias Simon    +
+ 21-11-2024 18:33    +
(edited on: 21-11-2024 18:37)
+ 		+ + + + +
+ I think you are right. A goto to break a loop is perfectly fine, even for Dijkstra's standards.
+
+However, breaking out of loops without using any kind of goto is possible, but cumbersome and inefficient. For example compare this linear search algorithm.
+
+// Using goto
+var integer x,y,z;
+for (x := 0; x < width; x++) {
+    for (y := 0; y < height; y++) {
+        for (z := 0; z < depth; z++) {
+            if (space[x][y][z] == RedDwarf) {
+                goto end;
+            }
+        }
+    }
+}
+label end;
+log("found red dwarf at coords", x,y,z)
+
+// Using named loops
+var integer x,y,z;
+L1:
+for (x := 0; x < width; x++) {
+    for (y := 0; y < height; y++) {
+        for (z := 0; z < depth; z++) {
+            if (space[x][y][z] == RedDwarf) {
+                break L1;
+            }
+        }
+    }
+}
+log("found red dwarf at coords", x,y,z)
+
+// Without Goto using booleans
+var integer x,y,z;
+var boolean found;
+for (x := 0; x < width && not found; x++) {
+    for (y := 0; y < height && not found; y++) {
+        for (z := 0; z < depth && not found; z++) {
+            if (space[x][y][z] == RedDwarf) {
+                found := true;
+            }
+        }
+    }
+}
+log("found red dwarf at coords", x-1,y-1,z-1)
+
+
+// Without Goto using functions
+var integer x, y, z;
+searchSpaceXYZ(space, x, y, z);
+log("found red dwarf at coords:, x, y, z);
+
+function searchSpaceXYZ(record of record of record of Obj space, inout integer x, inout integer y, inout integer z) boolean {
+    for (x := 0; x < lengthof(space); x++) {
+        if (searchSpaceYZ(space, x, y, z)) {
+            return true;
+        }
+    }
+    return false;
+}
+
+function searchSpaceYZ(record of record of record of Obj space, inout integer x, inout integer y, inout integer z) boolean {
+    for (y := 0; y < lengthof(space[x]); y++) {
+        if (searchSpaceZ(space, x, y, z)) {
+            return true;
+        }
+    }
+    return false;
+}
+
+function searchSpaceZ(record of record of record of Obj space, inout integer x, inout integer y, inout integer z) boolean {
+    for (z := 0; z < lengthof(space[x][y]); z++) {
+        if (space[x][y][z] == RedDwarf) {
+            return true;
+        }
+    }
+    return false;
+}
+
+
+If I had to rate existing means for readability and code-quality I'd say:
+1. Goto
+2. Named-loop
+3. Boolean-loop
+4. Function-loop
+
+Place 2 and 3 are very close, because for simple loops boolean-loops are easier to comprehend. But they can become very ugly and inefficient very fast.
+
+After reviewing available options, I personally would stick with the goto.
+
+
+
+
+
+ + + + + + + + + + +
+ (0016718) +
+ Jens Grabowski    +
+ 16-12-2024 10:26    +
+ 		+ + + + +
+ Discussion will be continued in Gitlab.
+
+ + diff --git a/docs/mantis/CR8154.md b/docs/mantis/CR8154.md new file mode 100644 index 0000000000000000000000000000000000000000..51b79ddfaa372aaf2eec13e7c2b9c9d698614af1 --- /dev/null +++ b/docs/mantis/CR8154.md @@ -0,0 +1,98 @@ + + + + + + + + + + + + + 0008154: Embedded Fields - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008154Part 01: TTCN-3 Core LanguageNew Featurepublic12-12-2022 08:5904-01-2023 10:35
ReporterMatthias Simon 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Clause Reference(s)6.2 -- Structured Types and Values
Source (company - Author)Nokia - Matthias Simon
Summary0008154: Embedded Fields
DescriptionEmbedded Fields improve readability of composed types.
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR8154.docx (112,727) 12-12-2022 13:32
http://oldforge.etsi.org/mantis/file_download.php?file_id=4096&type=bug
Issue History
Date ModifiedUsernameFieldChange
12-12-2022 08:59Matthias SimonNew Issue
12-12-2022 13:32Matthias SimonFile Added: CR8154.docx
16-12-2022 11:49Matthias SimonAssigned To => Matthias Simon
16-12-2022 11:49Matthias SimonStatusnew => assigned
19-12-2022 13:01Matthias SimonAssigned ToMatthias Simon => Axel Rennoch
19-12-2022 13:01Matthias SimonStatusassigned => confirmed
20-12-2022 10:24Axel RennochNote Added: 0016434
20-12-2022 10:24Axel RennochStatusconfirmed => resolved
20-12-2022 10:24Axel RennochResolutionopen => fixed
20-12-2022 10:24Axel RennochAssigned ToAxel Rennoch => Jens Grabowski
04-01-2023 10:35Jens GrabowskiNote Added: 0016458
04-01-2023 10:35Jens GrabowskiStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0016434) +
+ Axel Rennoch    +
+ 20-12-2022 10:24    +
+ 		+ + + + +
+ The proposed solution is readable, appears correct and can be understood.
+
+
+
+ + + + + + + + + + +
+ (0016458) +
+ Jens Grabowski    +
+ 04-01-2023 10:35    +
+ 		+ + + + +
+ Implemented as proposed.
+
+ + diff --git a/docs/mantis/CR8155.md b/docs/mantis/CR8155.md new file mode 100644 index 0000000000000000000000000000000000000000..fa455ffec5a65683bd232c14394a122403a4fb32 --- /dev/null +++ b/docs/mantis/CR8155.md @@ -0,0 +1,327 @@ + + + + + + + + + + + + + 0008155: Issue with the number of elements of templates - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008155Part 01: TTCN-3 Core LanguageTechnicalpublic12-12-2022 14:2015-01-2024 12:22
ReporterMatthias Simon 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionwon't fix 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Clause Reference(s)n/a
Source (company - Author)Nokia - Matthias Simon
Summary0008155: Issue with the number of elements of templates
DescriptionHow do I get the number of elements of a string or list?
+For example of a hexstring template:
+
+    template hexstring s := '1*F'H
+    for (var integer i := 0; i<lengthof(s); i := i + 1) {
+        log(s[i]);
+    }
+
+I would expect the number of elements in this template would be 3 (as suggested by clause 15.6.1). However lengthof produces a (justified) runtime error and sizeof is deprecated.
+
+Is there a mechanism for retrieving the number of elements in a string or list in TTCN-3 or do we need a new predefined function?
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
12-12-2022 14:20Matthias SimonNew Issue
20-12-2022 13:03Jens GrabowskiNote Added: 0016442
20-12-2022 13:03Jens GrabowskiAssigned To => Jens Grabowski
20-12-2022 13:03Jens GrabowskiStatusnew => assigned
20-12-2022 13:12Jens GrabowskiNote Added: 0016443
07-11-2023 16:25Jens GrabowskiAssigned ToJens Grabowski => Matthias Simon
07-11-2023 16:26Jens GrabowskiNote Added: 0016541
08-11-2023 10:49Matthias SimonNote Added: 0016544
08-11-2023 23:48Gusztáv AdamisNote Added: 0016558
08-11-2023 23:49Gusztáv AdamisNote Added: 0016559
08-11-2023 23:49Gusztáv AdamisNote Deleted: 0016559
08-11-2023 23:50Gusztáv AdamisNote Edited: 0016558bug_revision_view_page.php?bugnote_id=16558#r623
10-11-2023 08:25Matthias SimonNote Added: 0016571
10-11-2023 08:25Matthias SimonAssigned ToMatthias Simon => Jens Grabowski
10-11-2023 08:25Matthias SimonStatusassigned => resolved
10-11-2023 08:25Matthias SimonResolutionopen => won't fix
15-01-2024 12:22Jens GrabowskiNote Added: 0016591
15-01-2024 12:22Jens GrabowskiStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0016442) +
+ Jens Grabowski    +
+ 20-12-2022 13:03    +
+ 		+ + + + +
+ TTF discussion: Has to be studied. Cannot be resolved for the next version. To be shifted into 2023.
+
+
+
+ + + + + + + + + + +
+ (0016443) +
+ Jens Grabowski    +
+ 20-12-2022 13:12    +
+ 		+ + + + +
+ TTF discussion: lenghtof function needs to be revised.
+
+
+
+ + + + + + + + + + +
+ (0016541) +
+ Jens Grabowski    +
+ 07-11-2023 16:26    +
+ 		+ + + + +
+ TTF discussion: Resolution will be based on an optional parameter.
+
+
+
+ + + + + + + + + + +
+ (0016544) +
+ Matthias Simon    +
+ 08-11-2023 10:49    +
+ 		+ + + + +
+ We should reconsider our resolution, because a new proposal has come up (method-syntax).
+
+Following options are available for discussion (only the first 3 are relevant in my opinion):
+
+1. Optional Parameter
+   Example: lengthof({1,*,5}, true) // true uses new lengthof behaviour
+   + Backwards compatible
+   - Surprising users can get surprising runtime errors, because behavior is aligned with length-constraint-assignment-rules
+   - Clumsy design (but seldom used, most users won't notice)
+
+2. Just Change Behavior
+   Example: lengthof({1,*,5}) // returns 3
+   + Expected behavior aligned with index-access-rules
+   + easy to understand, good design
+   - Backwards incompatible (but only for rare corner cases, for fix an easy fix is available)
+
+3. Method Syntax:
+   Example: {1,*,5}.lengthof()
+   + Does not pollute existing namespaces
+   + Easy to understand
+   - Method syntax is not very common in TTCN-3
+   - Grammar needs restructuring
+   - two different lengthof functionalities is confusing
+
+4. New Syntax:
+   Random Example: lengthof @lastindex ({1,*,5})
+   + Backwards compatible
+   + Could be easy to understand,
+   + New syntax could unlock other features (e.g. a[lengthof] := 23)
+   - New syntax increases language complexity
+   - We have no proposal how such syntax could look like
+
+4. New Function:
+   Example: lastindex({1,*,3})
+   + Easy to understand, no confusion about different lengthof behaviors
+   + Could unlock other features by circumventing making lengthof issue
+   - Backwards incompatible, due to new keywords
+
+5. Using length
+   Example: length({1,*,3})
+   + Backwards compatible
+   + Could reduce keywords by making lengthof superfluous
+   - Having two different length functions is confusing
+
+
+
+ + + + + + + + + + +
+ (0016558) +
+ Gusztáv Adamis    +
+ 08-11-2023 23:48    +
(edited on: 08-11-2023 23:50)
+ 		+ + + + +
+ Ericsson can accept backward incompability, so the lengthof() function can be extended (without adding an extra optional parameter) to reach the desired behaviour also for templates instead of resulting in a run-time error.
+
+
+
+
+
+ + + + + + + + + + +
+ (0016571) +
+ Matthias Simon    +
+ 10-11-2023 08:25    +
+ 		+ + + + +
+ Summary:
+A deeper investigation is required, because the situation is unclear.
+There seem to be contradictions between the lengthof-spec and its examples; also between binary-string values/templates and indexing rules, ...
+
+A new CR for this topic will be created.
+
+
+
+
+
+ + + + + + + + + + +
+ (0016591) +
+ Jens Grabowski    +
+ 15-01-2024 12:22    +
+ 		+ + + + +
+ No action required at the moment.
+
+ + diff --git a/docs/mantis/CR8156.md b/docs/mantis/CR8156.md new file mode 100644 index 0000000000000000000000000000000000000000..cdfe3de18c21f049c29a83acf8602e37c151eb68 --- /dev/null +++ b/docs/mantis/CR8156.md @@ -0,0 +1,359 @@ + + + + + + + + + + + + + 0008156: Introduce user defined methods - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008156Part 01: TTCN-3 Core LanguageNew Featurepublic12-12-2022 14:3616-12-2024 12:39
ReporterMatthias Simon 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusresolvedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Clause Reference(s)16.4 -- Methods
Source (company - Author)Nokia - Matthias Simon
Summary0008156: Introduce user defined methods
DescriptionThis CR is a part of splitting http://oldforge.etsi.org/mantis/view.php?id=8113 [^]
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR8156.docx (127,086) 16-12-2022 11:53
http://oldforge.etsi.org/mantis/file_download.php?file_id=4101&type=bug
docx CR8156-2.docx (162,277) 20-12-2022 10:19
http://oldforge.etsi.org/mantis/file_download.php?file_id=4108&type=bug
Issue History
Date ModifiedUsernameFieldChange
12-12-2022 14:36Matthias SimonNew Issue
13-12-2022 20:50Matthias SimonFile Added: CR8156.docx
16-12-2022 11:50Matthias SimonAssigned To => Matthias Simon
16-12-2022 11:50Matthias SimonStatusnew => assigned
16-12-2022 11:53Matthias SimonFile Deleted: CR8156.docx
16-12-2022 11:53Matthias SimonFile Added: CR8156.docx
19-12-2022 13:19Matthias SimonNote Added: 0016429
19-12-2022 13:19Matthias SimonAssigned ToMatthias Simon => Tomas Urban
19-12-2022 13:19Matthias SimonStatusassigned => confirmed
20-12-2022 10:19Tomas UrbanFile Added: CR8156-2.docx
20-12-2022 10:23Tomas UrbanNote Added: 0016433
20-12-2022 10:23Tomas UrbanAssigned ToTomas Urban => Matthias Simon
20-12-2022 11:08Matthias SimonNote Added: 0016435
20-12-2022 12:26Jens GrabowskiNote Added: 0016438
20-12-2022 12:26Jens GrabowskiStatusconfirmed => assigned
03-01-2023 12:13Matthias SimonNote Added: 0016447
07-11-2023 15:10Jens GrabowskiNote Added: 0016540
07-11-2023 15:10Jens GrabowskiAssigned ToMatthias Simon => Jens Grabowski
08-11-2023 11:19Matthias SimonNote Added: 0016547
26-01-2024 16:28Olivier GenoudNote Added: 0016609
16-12-2024 12:39Jens GrabowskiNote Added: 0016725
16-12-2024 12:39Jens GrabowskiStatusassigned => resolved
16-12-2024 12:39Jens GrabowskiResolutionopen => fixed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0016429) +
+ Matthias Simon    +
+ 19-12-2022 13:19    +
+ 		+ + + + +
+ Uploaded initial proposal for methods, please review.
+
+Please note, after a good while of consideration I finally went with the free-floating syntax. Because it's the least intrusive. It doesn't fit perfectly with the OOP extension, but with the rest of the standard, though.
+
+What I also value high is that free-floating syntax makes it easy to retro-fit existing operations and demote them to some kind of a standard library, without breaking compatibility. For example:
+
+    external function start(in float duration) extends timer;
+    external function stop() extends timer;
+
+
+
+ + + + + + + + + + +
+ (0016433) +
+ Tomas Urban    +
+ 20-12-2022 10:23    +
+ 		+ + + + +
+ I made some changes in the document, adding an explanatory rule for imports and a couple of rules for type synonyms.
+
+The document also references a new clause 6.2.1.4 (promoted methods). Could you please add a reference to a CR where this clause was introduced?
+
+If you are happy with the changes I made or make just minor corrections, please assign the document to Jens for final reading.
+
+
+
+ + + + + + + + + + +
+ (0016435) +
+ Matthias Simon    +
+ 20-12-2022 11:08    +
+ 		+ + + + +
+ Good catch on the rule for imports, thanks.
+
+I'd like to discuss about the additional rule for type synonym, though.
+
+Embedded fields are proposed in this CR: http://oldforge.etsi.org/mantis/view.php?id=8154 [^]
+
+
+
+ + + + + + + + + + +
+ (0016438) +
+ Jens Grabowski    +
+ 20-12-2022 12:26    +
+ 		+ + + + +
+ TTF discussion: Open questions: (1) Is the same thing as methods in OO extension package? (2) In case a component type extends another component: How do methods behave? TTF requires answers before the feature can be introduced.
+
+
+
+ + + + + + + + + + +
+ (0016447) +
+ Matthias Simon    +
+ 03-01-2023 12:13    +
+ 		+ + + + +
+ The method specifications differ in various aspects, such as visibility, receiver type semantics or applicability.
+
+Proposal should be discussed during the next TTF.
+
+
+
+ + + + + + + + + + +
+ (0016540) +
+ Jens Grabowski    +
+ 07-11-2023 15:10    +
+ 		+ + + + +
+ TTF discussion: Further discussions regarding OO features in TTCN-3 are needed. Discussion should be done in the context of new major revision.
+
+
+
+ + + + + + + + + + +
+ (0016547) +
+ Matthias Simon    +
+ 08-11-2023 11:19    +
+ 		+ + + + +
+ For documentation purposes:
+
+The method proposal has some benefits:
+* methods for all TTCN-3 types (not only objects)
+* simple syntax and semantics (no new rules for visibility, importing, ...)
+* it's possible bind behaviour to a type without changing its representation.
+
+This proposal has to be harmonized with the OOP-extension, because introducing a second, slightly different OOP-style is counter to our efforts in unifying and simplifying TTCN-3.
+
+
+
+ + + + + + + + + + +
+ (0016609) +
+ Olivier Genoud    +
+ 26-01-2024 16:28    +
+ 		+ + + + +
+ OO features shall be kept out of the core language but kept as extension packages (e.g. OO extension).
+
+
+
+ + + + + + + + + + +
+ (0016725) +
+ Jens Grabowski    +
+ 16-12-2024 12:39    +
+ 		+ + + + +
+ Discussion continues in Gitlab
+
+ + diff --git a/docs/mantis/CR8180.md b/docs/mantis/CR8180.md new file mode 100644 index 0000000000000000000000000000000000000000..991ef58e780d09ecd9c6ea572a5fc2ebf9901531 --- /dev/null +++ b/docs/mantis/CR8180.md @@ -0,0 +1,242 @@ + + + + + + + + + + + + + 0008180: Next major version of TTCN-3 - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - TTCN-3 Change Requests
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008180TTCN-3 Change RequestsTechnicalpublic19-12-2022 12:0016-12-2024 13:19
ReporterJens Grabowski 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusresolvedResolutionfixed 
PlatformOSOS Version
Clause Reference(s)All clauses
For STF discussion
Source (company - Author)   TTF T023 (Jens Grabowski)
Summary0008180: Next major version of TTCN-3
DescriptionThis CR summarizes issues on which a TTF should work in order to produce the next major version of TTCN-3, i.e., version 4.15.x.
+
+Issues for discussion include:
+
+- technical refactoring (i.e., keywords, reserved words, BNF restructuring),
+- issues increasing the comfortable usage of the language (i.e., char handling, more obvious keywords, e.g., length instead of lengthof)
+- new features and moving features from extension packages into the core language.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR8180-Discussio-on-new-major-release.docx (16,885) 19-12-2022 14:43
http://oldforge.etsi.org/mantis/file_download.php?file_id=4104&type=bug
docx CR8180-Discussion-on-new-major-release-2.docx (13,561) 20-01-2023 14:06
http://oldforge.etsi.org/mantis/file_download.php?file_id=4114&type=bug
docx CR8180-Discussion-on-new-major-release-3_Devoteam Comments.docx (51,548) 18-01-2024 16:14
http://oldforge.etsi.org/mantis/file_download.php?file_id=4130&type=bug
docx CR8180-Discussion-on-new-major-release-3r1_Devoteam Comments.docx (47,264) 19-01-2024 10:15
http://oldforge.etsi.org/mantis/file_download.php?file_id=4131&type=bug
docx CR8180-Discussion-on-new-major-release-4_Devoteam_TF160 Comments.docx (60,449) 22-01-2024 14:15
http://oldforge.etsi.org/mantis/file_download.php?file_id=4132&type=bug
docx CR8180-Discussion-on-new-major-release-4r1_Devoteam_TF160 Comments.docx (59,244) 22-01-2024 18:09
http://oldforge.etsi.org/mantis/file_download.php?file_id=4133&type=bug
Issue History
Date ModifiedUsernameFieldChange
19-12-2022 12:00Jens GrabowskiNew Issue
19-12-2022 14:43Jens GrabowskiFile Added: CR8180-Discussio-on-new-major-release.docx
20-01-2023 14:06Matthias SimonFile Added: CR8180-Discussion-on-new-major-release-2.docx
20-01-2023 14:11Matthias SimonNote Added: 0016470
18-01-2024 16:14Thilo LauerFile Added: CR8180-Discussion-on-new-major-release-3_Devoteam Comments.docx
18-01-2024 16:18Thilo LauerNote Added: 0016597
19-01-2024 10:15Thilo LauerFile Added: CR8180-Discussion-on-new-major-release-3r1_Devoteam Comments.docx
19-01-2024 10:16Thilo LauerNote Added: 0016598
22-01-2024 14:15Olivier GenoudFile Added: CR8180-Discussion-on-new-major-release-4_Devoteam_TF160 Comments.docx
22-01-2024 14:15Olivier GenoudNote Added: 0016602
22-01-2024 18:09Olivier GenoudFile Added: CR8180-Discussion-on-new-major-release-4r1_Devoteam_TF160 Comments.docx
22-01-2024 18:10Olivier GenoudNote Added: 0016603
16-12-2024 13:19Jens GrabowskiNote Added: 0016731
16-12-2024 13:19Jens GrabowskiStatusnew => resolved
16-12-2024 13:19Jens GrabowskiResolutionopen => fixed
16-12-2024 13:19Jens GrabowskiAssigned To => Jens Grabowski
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0016470) +
+ Matthias Simon    +
+ 20-01-2023 14:11    +
+ 		+ + + + +
+ I created some CR and updated the document.
+
+About 10 CRs I'd have to write still. I am not sure if I can finish those before the upcoming plenary. Would this be a problem?
+
+
+
+ + + + + + + + + + +
+ (0016597) +
+ Thilo Lauer    +
+ 18-01-2024 16:18    +
+ 		+ + + + +
+ I have uploaded our comments for discussion at next week's
+MTS-WORKSHOP-Brainstorm meeting
+
+
+
+ + + + + + + + + + +
+ (0016598) +
+ Thilo Lauer    +
+ 19-01-2024 10:16    +
+ 		+ + + + +
+ I have uploaded a revised version of our comments regarding promoted fields
+
+
+
+ + + + + + + + + + +
+ (0016602) +
+ Olivier Genoud    +
+ 22-01-2024 14:15    +
+ 		+ + + + +
+ I have uploaded a revised version 4, which includes review feedback from 3GPP TF160 project, on top of the Devoteam version 3r1.
+
+
+
+ + + + + + + + + + +
+ (0016603) +
+ Olivier Genoud    +
+ 22-01-2024 18:10    +
+ 		+ + + + +
+ I have uploaded a revised version 4r1: the only change is addition of TF160 review feedback for CR#8102, which we missed in the previous version.
+
+
+
+ + + + + + + + + + +
+ (0016731) +
+ Jens Grabowski    +
+ 16-12-2024 13:19    +
+ 		+ + + + +
+ Discussion continues in Gitlab.
+
+ + diff --git a/docs/mantis/CR8181.md b/docs/mantis/CR8181.md new file mode 100644 index 0000000000000000000000000000000000000000..9c22f0b2c6282336f1304113aa6df64fbb0b89bc --- /dev/null +++ b/docs/mantis/CR8181.md @@ -0,0 +1,64 @@ + + + + + + + + + + + + + 0008181: object used as an identifier - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 11: Using JSON with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008181Part 11: Using JSON with TTCN-3[TTCN-3 Change Requests] Technicalpublic20-12-2022 13:2905-01-2023 07:09
ReporterTomas Urban 
Assigned To 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product VersionV4.9.1 (ongoing) 
Target VersionNext version (to be decided)Fixed in Version 
Summary0008181: object used as an identifier
DescriptionThe standard uses "object" as an identifier. However, "object" is a keyword in the ES 203 790 (Object Oriented Features). The core language standard rules state that keywords from external packages shall not be used as identifiers and the JSON specification should be changed accordingly. It is a backwards incompatible change, but it is impossible to use JSON together with object oriented features without it.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0008093closed Jens Grabowski Part 01: TTCN-3 Core Language object not listed as a keyword in table A.5 
Attached Filesdocx CR-8181-1.docx (176,470) 21-12-2022 09:37
http://oldforge.etsi.org/mantis/file_download.php?file_id=4111&type=bug
Issue History
Date ModifiedUsernameFieldChange
20-12-2022 13:29Tomas UrbanNew Issue
20-12-2022 13:29Tomas UrbanStatusnew => assigned
20-12-2022 13:29Tomas UrbanAssigned To => Tomas Urban
21-12-2022 09:37Tomas UrbanFile Added: CR-8181-1.docx
21-12-2022 09:42Tomas UrbanNote Added: 0016444
21-12-2022 09:42Tomas UrbanAssigned ToTomas Urban => Jens Grabowski
21-12-2022 09:42Tomas UrbanStatusassigned => confirmed
04-01-2023 11:03Jens GrabowskiRelationship addedrelated to 0008093
04-01-2023 14:16Jens GrabowskiAssigned ToJens Grabowski => Tomas Urban
04-01-2023 14:16Jens GrabowskiStatusconfirmed => assigned
04-01-2023 14:16Jens GrabowskiStatusassigned => resolved
04-01-2023 14:16Jens GrabowskiResolutionopen => fixed
05-01-2023 07:09Tomas UrbanStatusresolved => closed
05-01-2023 07:09Tomas UrbanAssigned ToTomas Urban =>
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0016444) +
+ Tomas Urban    +
+ 21-12-2022 09:42    +
+ 		+ + + + +
+ I changed the problematic identifier in the JSON specification. The new identifier is called "obj". It follows the naming convention used in the document (integer -> int, string -> str etc.).
+Please check.
+
+ + diff --git a/docs/mantis/CR8182.md b/docs/mantis/CR8182.md new file mode 100644 index 0000000000000000000000000000000000000000..6a5bf03f0cddd6ac8b372e7165c0897942cb4f29 --- /dev/null +++ b/docs/mantis/CR8182.md @@ -0,0 +1,172 @@ + + + + + + + + + + + + + 0008182: Old module template parameter rules in 5.4.1.2 - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008182Part 01: TTCN-3 Core LanguageTechnicalpublic27-12-2022 10:2415-01-2024 12:54
ReporterTomas Urban 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product VersionNext version (to be decided) 
Target VersionFixed in Version 
Clause Reference(s)5.4.1.2
Source (company - Author)Elvior OÜ
Summary0008182: Old module template parameter rules in 5.4.1.2
DescriptionOne of the recent versions of the core language standard added rules allowing to use template kind of module parameters (see 8.2.1 for more details). Unfortunately, no changes were made in the section 5.4.1.2 causing the rules to be inconsistent.
+
+In order to fix this issue I propose to change the section 5.4.1.2 in the following way:
+
+Remove the first sentence of the semantic description: "Template parameters can be defined for templates, functions, altsteps, and test cases." The only entity not mentioned here is a module.
+
+Change the restriction a. ("Only function, testcase, altstep and template definitions may have formal template parameters.") to "Restrictions on module parameters are given in clause 8.2.1." This text is used in the section on formal value parameters.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR8182-v1.docx (191,800) 08-11-2023 11:10
http://oldforge.etsi.org/mantis/file_download.php?file_id=4120&type=bug
Issue History
Date ModifiedUsernameFieldChange
27-12-2022 10:24Tomas UrbanNew Issue
05-09-2023 11:25Jens GrabowskiAssigned To => Tomas Urban
05-09-2023 11:25Jens GrabowskiStatusnew => assigned
07-11-2023 13:32Jens GrabowskiNote Added: 0016532
08-11-2023 11:10Tomas UrbanFile Added: CR8182-v1.docx
08-11-2023 11:11Tomas UrbanNote Added: 0016545
08-11-2023 11:11Tomas UrbanAssigned ToTomas Urban => Jens Grabowski
08-11-2023 11:11Tomas UrbanStatusassigned => confirmed
09-11-2023 10:04Jens GrabowskiNote Added: 0016562
09-11-2023 10:04Jens GrabowskiStatusconfirmed => resolved
09-11-2023 10:04Jens GrabowskiResolutionopen => fixed
15-01-2024 12:54Jens GrabowskiNote Added: 0016594
15-01-2024 12:54Jens GrabowskiStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0016532) +
+ Jens Grabowski    +
+ 07-11-2023 13:32    +
+ 		+ + + + +
+ TTF discussion: To be resolved in the 2024 series of standards.
+
+
+
+ + + + + + + + + + +
+ (0016545) +
+ Tomas Urban    +
+ 08-11-2023 11:11    +
+ 		+ + + + +
+ Resolution uploaded.
+Please review.
+
+
+
+ + + + + + + + + + +
+ (0016562) +
+ Jens Grabowski    +
+ 09-11-2023 10:04    +
+ 		+ + + + +
+ Will be implemented as proposed.
+
+
+
+ + + + + + + + + + +
+ (0016594) +
+ Jens Grabowski    +
+ 15-01-2024 12:54    +
+ 		+ + + + +
+ implemented as suggested
+
+ + diff --git a/docs/mantis/CR8183.md b/docs/mantis/CR8183.md new file mode 100644 index 0000000000000000000000000000000000000000..dec639e01425c40a725192514fda9dace83508b6 --- /dev/null +++ b/docs/mantis/CR8183.md @@ -0,0 +1,70 @@ + + + + + + + + + + + + + 0008183: Wrong BNF rules for enumerated types - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008183Part 01: TTCN-3 Core LanguageTechnicalpublic27-12-2022 11:2804-01-2023 13:17
ReporterTomas Urban 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product VersionNext version (to be decided) 
Target VersionFixed in Version 
Clause Reference(s)A.1.6.1.1
Source (company - Author)Elvior OÜ
Summary0008183: Wrong BNF rules for enumerated types
DescriptionCR 0007766 allowed to use integer expressions in enum type definitions. However, no change was made in the BNF where the affected rules are as follows:
+
+41.IntegerValueOrRange ::= IntegerValue [".." IntegerValue]
+42.IntegerValue ::= [Minus] Number
+
+These rules should be replaced with the following one:
+41.IntegerValueOrRange ::= SingleExpression [".." SingleExpression]
+/* STATIC SEMANTICS - SingleExpression shall evaluate to a statically bound integer value */
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
27-12-2022 11:28Tomas UrbanNew Issue
04-01-2023 13:16Jens GrabowskiAssigned To => Jens Grabowski
04-01-2023 13:16Jens GrabowskiStatusnew => assigned
04-01-2023 13:17Jens GrabowskiNote Added: 0016467
04-01-2023 13:17Jens GrabowskiStatusassigned => closed
04-01-2023 13:17Jens GrabowskiResolutionopen => fixed
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0016467) +
+ Jens Grabowski    +
+ 04-01-2023 13:17    +
+ 		+ + + + +
+ Implemented according to proposal.
+
+ + diff --git a/docs/mantis/CR8184.md b/docs/mantis/CR8184.md new file mode 100644 index 0000000000000000000000000000000000000000..1c2330b67661870aa7a747e6ceb554410adfffca --- /dev/null +++ b/docs/mantis/CR8184.md @@ -0,0 +1,166 @@ + + + + + + + + + + + + + 0008184: Implicit template restriction should mention the map type - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008184Part 01: TTCN-3 Core LanguageTechnicalpublic28-12-2022 10:3015-01-2024 13:24
ReporterTomas Urban 
Assigned ToJens Grabowski 
PrioritylowSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product VersionNext version (to be decided) 
Target VersionFixed in Version 
Clause Reference(s)15.8.2
Source (company - Author)Elvior OÜ
Summary0008184: Implicit template restriction should mention the map type
DescriptionThe table 13C should contain an explicit reference to the map type.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR8184-v1.docx (188,109) 08-11-2023 11:15
http://oldforge.etsi.org/mantis/file_download.php?file_id=4121&type=bug
Issue History
Date ModifiedUsernameFieldChange
28-12-2022 10:30Tomas UrbanNew Issue
05-09-2023 11:23Jens GrabowskiAssigned To => Tomas Urban
05-09-2023 11:23Jens GrabowskiStatusnew => assigned
07-11-2023 13:33Jens GrabowskiNote Added: 0016533
08-11-2023 11:15Tomas UrbanFile Added: CR8184-v1.docx
08-11-2023 11:16Tomas UrbanNote Added: 0016546
08-11-2023 11:16Tomas UrbanAssigned ToTomas Urban => Jens Grabowski
08-11-2023 11:16Tomas UrbanStatusassigned => confirmed
09-11-2023 10:02Jens GrabowskiNote Added: 0016561
09-11-2023 10:02Jens GrabowskiStatusconfirmed => resolved
09-11-2023 10:02Jens GrabowskiResolutionopen => fixed
15-01-2024 13:24Jens GrabowskiNote Added: 0016595
15-01-2024 13:24Jens GrabowskiStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0016533) +
+ Jens Grabowski    +
+ 07-11-2023 13:33    +
+ 		+ + + + +
+ TTF discussion: To be resolved as proposed for next version.
+
+
+
+ + + + + + + + + + +
+ (0016546) +
+ Tomas Urban    +
+ 08-11-2023 11:16    +
+ 		+ + + + +
+ Resolution uploaded.
+Please review.
+
+
+
+ + + + + + + + + + +
+ (0016561) +
+ Jens Grabowski    +
+ 09-11-2023 10:02    +
+ 		+ + + + +
+ Will be implemented as proposed.
+
+
+
+ + + + + + + + + + +
+ (0016595) +
+ Jens Grabowski    +
+ 15-01-2024 13:24    +
+ 		+ + + + +
+ implemented as proposed
+
+ + diff --git a/docs/mantis/CR8185.md b/docs/mantis/CR8185.md new file mode 100644 index 0000000000000000000000000000000000000000..a380fd1753dd9e5397058f0c4658befa3a58ddaf --- /dev/null +++ b/docs/mantis/CR8185.md @@ -0,0 +1,166 @@ + + + + + + + + + + + + + 0008185: Implicit template restrictions for compound expressions - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008185Part 01: TTCN-3 Core LanguageTechnicalpublic29-12-2022 11:0315-01-2024 13:30
ReporterTomas Urban 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product VersionNext version (to be decided) 
Target VersionFixed in Version 
Clause Reference(s)15.8.2
Source (company - Author)Elvior OÜ
Summary0008185: Implicit template restrictions for compound expressions
DescriptionImplicit template restrictions should apply to items of compound expressions (i.e. assignment and value lists). This would add the parameters of signature templates to the equation and signature templates should be mentioned in the text and table 13C.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR8185-v1.docx (188,598) 08-11-2023 12:30
http://oldforge.etsi.org/mantis/file_download.php?file_id=4122&type=bug
Issue History
Date ModifiedUsernameFieldChange
29-12-2022 11:03Tomas UrbanNew Issue
05-09-2023 11:21Jens GrabowskiAssigned To => Tomas Urban
05-09-2023 11:21Jens GrabowskiStatusnew => assigned
07-11-2023 13:34Jens GrabowskiNote Added: 0016534
08-11-2023 12:30Tomas UrbanFile Added: CR8185-v1.docx
08-11-2023 12:31Tomas UrbanNote Added: 0016548
08-11-2023 12:31Tomas UrbanAssigned ToTomas Urban => Jens Grabowski
08-11-2023 12:31Tomas UrbanStatusassigned => confirmed
09-11-2023 10:02Jens GrabowskiNote Added: 0016560
09-11-2023 10:02Jens GrabowskiStatusconfirmed => resolved
09-11-2023 10:02Jens GrabowskiResolutionopen => fixed
15-01-2024 13:30Jens GrabowskiNote Added: 0016596
15-01-2024 13:30Jens GrabowskiStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0016534) +
+ Jens Grabowski    +
+ 07-11-2023 13:34    +
+ 		+ + + + +
+ TTF discussion: To be resolved as proposed for next version.
+
+
+
+ + + + + + + + + + +
+ (0016548) +
+ Tomas Urban    +
+ 08-11-2023 12:31    +
+ 		+ + + + +
+ Resolution uploaded.
+Please check.
+
+
+
+ + + + + + + + + + +
+ (0016560) +
+ Jens Grabowski    +
+ 09-11-2023 10:02    +
+ 		+ + + + +
+ Will be implemented as proposed.
+
+
+
+ + + + + + + + + + +
+ (0016596) +
+ Jens Grabowski    +
+ 15-01-2024 13:30    +
+ 		+ + + + +
+ implemented as proposed
+
+ + diff --git a/docs/mantis/CR8186.md b/docs/mantis/CR8186.md new file mode 100644 index 0000000000000000000000000000000000000000..5c22d3ebe1bc0eda361caa48abf10a27ef6922ed --- /dev/null +++ b/docs/mantis/CR8186.md @@ -0,0 +1,63 @@ + + + + + + + + + + + + + 0008186: object is a reserved word in OO extension package and JSON - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 11: Using JSON with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008186Part 11: Using JSON with TTCN-3[TTCN-3 Change Requests] Technicalpublic04-01-2023 11:0004-01-2023 11:02
ReporterJens Grabowski 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionwon't fix 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0008186: object is a reserved word in OO extension package and JSON
Descriptionobject is a reserved word in OO extension package and JSON. This leads to a conflict as reserved words shall not be used as identifiers in TTCN-3 modules.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
04-01-2023 11:00Jens GrabowskiNew Issue
04-01-2023 11:02Jens GrabowskiNote Added: 0016461
04-01-2023 11:02Jens GrabowskiStatusnew => closed
04-01-2023 11:02Jens GrabowskiAssigned To => Jens Grabowski
04-01-2023 11:02Jens GrabowskiResolutionopen => won't fix
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0016461) +
+ Jens Grabowski    +
+ 04-01-2023 11:02    +
+ 		+ + + + +
+ Already addressed in CR 8186
+
+ + diff --git a/docs/mantis/CR8187.md b/docs/mantis/CR8187.md new file mode 100644 index 0000000000000000000000000000000000000000..79a50db52616bf8636f3bed22c027180b3dd2e1a --- /dev/null +++ b/docs/mantis/CR8187.md @@ -0,0 +1,97 @@ + + + + + + + + + + + + + 0008187: Check of Core Language BNF rules - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008187Part 01: TTCN-3 Core LanguageTechnicalpublic04-01-2023 13:2313-01-2023 14:21
ReporterJens Grabowski 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Clause Reference(s)BNF Annex A
Source (company - Author)     TTF T023 (Jens Grabowski)
Summary0008187: Check of Core Language BNF rules
DescriptionAfter several additions and modifications the BNF of the core language requires a tool-based validation.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx Core-with-CR-8105-8070-8069-8103-8114-8151-8119-8078-8097-8115-8120-8136-8154-8091-8093-8108-8107-8104-8101-8183.docx (1,440,418) 04-01-2023 13:23
http://oldforge.etsi.org/mantis/file_download.php?file_id=4112&type=bug
docx Core-with-CR-8105-8070-8069-8103-8114-8151-8119-8078-8097-8115-8120-8136-8154-8091-8093-8108-8107-8104-8101-8183-8187.docx (1,440,499) 06-01-2023 11:27
http://oldforge.etsi.org/mantis/file_download.php?file_id=4113&type=bug
Issue History
Date ModifiedUsernameFieldChange
04-01-2023 13:23Jens GrabowskiNew Issue
04-01-2023 13:23Jens GrabowskiFile Added: Core-with-CR-8105-8070-8069-8103-8114-8151-8119-8078-8097-8115-8120-8136-8154-8091-8093-8108-8107-8104-8101-8183.docx
04-01-2023 13:24Jens GrabowskiAssigned To => Axel Rennoch
04-01-2023 13:24Jens GrabowskiStatusnew => assigned
04-01-2023 13:25Jens GrabowskiProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
06-01-2023 11:27Axel RennochFile Added: Core-with-CR-8105-8070-8069-8103-8114-8151-8119-8078-8097-8115-8120-8136-8154-8091-8093-8108-8107-8104-8101-8183-8187.docx
06-01-2023 11:31Axel RennochNote Added: 0016468
06-01-2023 11:31Axel RennochAssigned ToAxel Rennoch => Jens Grabowski
06-01-2023 11:31Axel RennochStatusassigned => confirmed
13-01-2023 14:21Jens GrabowskiNote Added: 0016469
13-01-2023 14:21Jens GrabowskiStatusconfirmed => closed
13-01-2023 14:21Jens GrabowskiResolutionopen => fixed
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0016468) +
+ Axel Rennoch    +
+ 06-01-2023 11:31    +
+ 		+ + + + +
+ The BNF has been checked (using tool support from uni-goettingen.de and blukaktus.com) and corrected. All changes have been implemented in the attachment.
+
+
+
+ + + + + + + + + + +
+ (0016469) +
+ Jens Grabowski    +
+ 13-01-2023 14:21    +
+ 		+ + + + +
+ Implemented as proposed in attachment.
+
+ + diff --git a/docs/mantis/CR8188.md b/docs/mantis/CR8188.md new file mode 100644 index 0000000000000000000000000000000000000000..5674f12eacdf6823d5f2bef2a66879ffe26cff26 --- /dev/null +++ b/docs/mantis/CR8188.md @@ -0,0 +1,315 @@ + + + + + + + + + + + + + 0008188: Support for function literals - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Behaviour Types (ES 202 785)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008188Ext Pack: Behaviour Types (ES 202 785)New Featurepublic11-01-2023 12:5716-12-2024 13:25
ReporterMatthias Simon 
Assigned ToGusztáv Adamis 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusresolvedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Clause Reference(s)n/a
Source (company - Author)Nokia - Matthias Simon
Summary0008188: Support for function literals
DescriptionA function literal, also known as lambda function or anonymous function, is a function definition without name. Example:
+
+    var fn := function (integer x) return boolean { return x mod 2 == 0 }
+    apply(fn(23));
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
11-01-2023 12:57Matthias SimonNew Issue
05-09-2023 11:06Jens GrabowskiNote Added: 0016522
05-09-2023 11:07Jens GrabowskiAssigned To => Matthias Simon
05-09-2023 11:07Jens GrabowskiStatusnew => assigned
08-11-2023 12:35Matthias SimonNote Added: 0016549
08-11-2023 13:54Jens GrabowskiAssigned ToMatthias Simon => Jens Grabowski
08-11-2023 13:54Jens GrabowskiAssigned ToJens Grabowski => Matthias Simon
08-11-2023 13:54Jens GrabowskiAssigned ToMatthias Simon => Gusztáv Adamis
09-11-2023 20:52Gusztáv AdamisNote Added: 0016569
26-01-2024 16:28Olivier GenoudNote Added: 0016610
16-12-2024 13:25Jens GrabowskiNote Added: 0016732
16-12-2024 13:25Jens GrabowskiStatusassigned => resolved
16-12-2024 13:25Jens GrabowskiResolutionopen => fixed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0016522) +
+ Jens Grabowski    +
+ 05-09-2023 11:06    +
+ 		+ + + + +
+ TTF discussion: More elaborated example needed.
+
+
+
+ + + + + + + + + + +
+ (0016549) +
+ Matthias Simon    +
+ 08-11-2023 12:35    +
+ 		+ + + + +
+ Function literals are evaluated lazily and capture their context. This makes implementation of deferred functions feasible. For example:
+ 
+
+    type function CancelFunc();
+
+    testcase Example() runs on MTC {
+        // start fixtures
+        var cancel := SetupDatabase();
+
+        // do some testing
+
+        // handle graceful shutdown
+        cancel();
+    }
+
+    function SetupDatabase() return CancelFunc
+    {
+        var db := DatabaseComponent.create;
+        db.start(listen());
+        return function() {
+            db.stop; // Captures db and allows to call methods, locally
+        }
+    }
+
+
+Another use-case is parametrizing callbacks:
+
+    module Service
+    {
+        type component Component { /* ... */ }
+
+        function Start(in ExitFunc ef := withSuccess) return Component
+        {
+            var c := Component.create;
+            c.start(mainLoop(ef));
+            return c;
+        }
+
+        private function mainLoop(ExitFunc ef) runs on Component {
+            p.receive(ProcessState:{started := ?});
+            log("Service is up and running");
+
+            var ExitCode ec;
+            p.receive(ProcessState:{exited := ?}) -> value ec;
+            f(ec);
+        }
+
+        type function ExitFunc(ExitCode ec) runs on Component;
+
+        type enumerated ExitCode {
+            SUCCESS(0),
+            ERROR(1..127),
+            SIGTERM(-15),
+            SIGKILL(-9),
+        }
+
+        group helpers
+        {
+            function withSuccess(in ExitCode ec) runs on Component {
+                if (ec != SUCCESS) {
+                    setverdict(fail, "want=0, got=" & ec);
+                    stop;
+                }
+            }
+
+            function withError(in ExitCode ec) runs on Component {
+                if (ec != ERROR) {
+                    setverdict(fail, "want!=0, got=" & ec);
+                    stop;
+                }
+            }
+
+            function withSignal(in ExitCode sig) return ExitFunc
+            {
+                return function(in ExitCode ec) runs on Component {
+                    if (ec != sig) {
+                        setverdict(fail, "want=" & sig, got=" & ec);
+                        stop;
+                    }
+                }
+            }
+
+            function withTimeout(in float duration) return ExitFunc
+            {
+                return function(in ExitCode ec) runs on Component {
+                    // ...
+                }
+        }
+    }
+
+    module Example
+    {
+        testcase SunnyDay()
+        {
+            var service1 := Service.Start();
+            var service2 := Service.Start(Service.withError);
+
+            // do some API testing...
+
+            all components.done;
+        }
+
+
+        testcase ResilianceTest_ServiceCrashes()
+        {
+            var service1 := Service.Start(Service.withSignal(Service.SIGTERM));
+            var service2 := Service.Start(Service.withTimeout(60.0));
+
+            // do some API testing...
+
+            all components.done;
+        }
+
+    }
+
+
+
+ + + + + + + + + + +
+ (0016569) +
+ Gusztáv Adamis    +
+ 09-11-2023 20:52    +
+ 		+ + + + +
+ The problems in examples can be solved with the existing TTCN-3 instructions.
+
+
+
+ + + + + + + + + + +
+ (0016610) +
+ Olivier Genoud    +
+ 26-01-2024 16:28    +
+ 		+ + + + +
+ We assume/expect that this CR will not become part of the core language but will become part of an extension or be added to an extension (e.g. OO extension).
+
+
+
+ + + + + + + + + + +
+ (0016732) +
+ Jens Grabowski    +
+ 16-12-2024 13:25    +
+ 		+ + + + +
+ Discussion continues in Gitlab.
+
+ + diff --git a/docs/mantis/CR8189.md b/docs/mantis/CR8189.md new file mode 100644 index 0000000000000000000000000000000000000000..4bac4a173eaa500820e66cb4a0997274a7cf17e5 --- /dev/null +++ b/docs/mantis/CR8189.md @@ -0,0 +1,170 @@ + + + + + + + + + + + + + 0008189: Implicit apply - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Behaviour Types (ES 202 785)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008189Ext Pack: Behaviour Types (ES 202 785)New Featurepublic11-01-2023 13:0326-01-2024 16:29
ReporterMatthias Simon 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionwon't fix 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Clause Reference(s)n/a
Source (company - Author)Nokia - Matthias Simon
Summary0008189: Implicit apply
DescriptionMake `apply` optional, when invoking behavior type values:
+
+    type function Handler();
+    var Handler fn := someFunction;
+    fn(); // <-- shorthand for: apply(fn());
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
11-01-2023 13:03Matthias SimonNew Issue
05-09-2023 11:17Jens GrabowskiNote Added: 0016525
08-09-2023 22:44Jens GrabowskiAssigned To => Gusztáv Adamis
08-09-2023 22:44Jens GrabowskiStatusnew => assigned
08-11-2023 12:59Jens GrabowskiNote Added: 0016551
08-11-2023 12:59Jens GrabowskiAssigned ToGusztáv Adamis => Jens Grabowski
09-11-2023 11:09Jens GrabowskiNote Added: 0016565
09-11-2023 11:09Jens GrabowskiStatusassigned => closed
09-11-2023 11:09Jens GrabowskiResolutionopen => won't fix
26-01-2024 16:29Olivier GenoudNote Added: 0016611
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0016525) +
+ Jens Grabowski    +
+ 05-09-2023 11:17    +
+ 		+ + + + +
+ TTF discussion: Ericsson to check if "apply" is used.
+
+
+
+ + + + + + + + + + +
+ (0016551) +
+ Jens Grabowski    +
+ 08-11-2023 12:59    +
+ 		+ + + + +
+ TTF discussion: "apply" is supported. Explicit specification style is preferred.
+To be reconsidered in the scope of new major revision.
+
+
+
+ + + + + + + + + + +
+ (0016565) +
+ Jens Grabowski    +
+ 09-11-2023 11:09    +
+ 		+ + + + +
+ The issue will be discussed in the scope of the 2024 major release. The appy operation is not need for compiler or parser reasons, but supports an explicit specification style. CR becomes part of CR 8180.
+
+
+
+ + + + + + + + + + +
+ (0016611) +
+ Olivier Genoud    +
+ 26-01-2024 16:29    +
+ 		+ + + + +
+ We assume/expect that this CR will not become part of the core language but will become part of an extension or be added to an extension (e.g. OO extension).
+
+ + diff --git a/docs/mantis/CR8190.md b/docs/mantis/CR8190.md new file mode 100644 index 0000000000000000000000000000000000000000..510fb6c8d59858e4681a23917cf6893441425430 --- /dev/null +++ b/docs/mantis/CR8190.md @@ -0,0 +1,206 @@ + + + + + + + + + + + + + 0008190: Expression Bodies - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Behaviour Types (ES 202 785)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008190Ext Pack: Behaviour Types (ES 202 785)New Featurepublic11-01-2023 13:0916-12-2024 12:09
ReporterMatthias Simon 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusresolvedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Clause Reference(s)n/a
Source (company - Author)Nokia - Matthias Simon
Summary0008190: Expression Bodies
DescriptionExpression bodies are a shorthand for function literals. Example:
+
+    var even := (integer x) => x mod 2 == 0;
+
+is a shorthand for:
+
+   var even := function (integer x) return boolen { return x mod 2 == 0 }
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
11-01-2023 13:09Matthias SimonNew Issue
05-09-2023 11:09Jens GrabowskiNote Added: 0016523
05-09-2023 11:09Jens GrabowskiAssigned To => Matthias Simon
05-09-2023 11:09Jens GrabowskiStatusnew => assigned
05-09-2023 11:11Jens GrabowskiNote Added: 0016524
10-11-2023 10:17Jens GrabowskiNote Added: 0016575
10-11-2023 10:17Jens GrabowskiAssigned ToMatthias Simon => Jens Grabowski
26-01-2024 16:29Olivier GenoudNote Added: 0016612
16-12-2024 12:09Jens GrabowskiNote Added: 0016724
16-12-2024 12:09Jens GrabowskiStatusassigned => resolved
16-12-2024 12:09Jens GrabowskiResolutionopen => fixed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0016523) +
+ Jens Grabowski    +
+ 05-09-2023 11:09    +
+ 		+ + + + +
+ TTF discussion: Dependent on 8189
+
+
+
+ + + + + + + + + + +
+ (0016524) +
+ Jens Grabowski    +
+ 05-09-2023 11:11    +
+ 		+ + + + +
+ Correction CR 8188
+
+
+
+ + + + + + + + + + +
+ (0016575) +
+ Jens Grabowski    +
+ 10-11-2023 10:17    +
+ 		+ + + + +
+ TTF discussion: without anonymuous functions (lambda expressions) this CR cannot be resolved. Shifted to 2024 TTF.
+
+
+
+ + + + + + + + + + +
+ (0016612) +
+ Olivier Genoud    +
+ 26-01-2024 16:29    +
+ 		+ + + + +
+ We assume/expect that this CR will not become part of the core language but will become part of an extension or be added to an extension (e.g. OO extension).
+
+
+
+ + + + + + + + + + +
+ (0016724) +
+ Jens Grabowski    +
+ 16-12-2024 12:09    +
+ 		+ + + + +
+ Discussion will continue in Gitlab.
+
+ + diff --git a/docs/mantis/CR8191.md b/docs/mantis/CR8191.md new file mode 100644 index 0000000000000000000000000000000000000000..5169f54045d0fa01f195ac2dcd8069a90c44de4b --- /dev/null +++ b/docs/mantis/CR8191.md @@ -0,0 +1,182 @@ + + + + + + + + + + + + + 0008191: Strict Rules - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008191Part 01: TTCN-3 Core LanguageNew Featurepublic12-01-2023 14:0916-12-2024 11:49
ReporterMatthias Simon 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusresolvedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Clause Reference(s)n/a
Source (company - Author)Nokia - Matthias Simon
Summary0008191: Strict Rules
DescriptionStricter TTCN-3 language rules are beneficial for avoiding code smells. For example:
+
+* 8094: Provide a canonical style for source code layout
+* 8098: Mandatory module prefix for imported module definitions
+* 8099: Disallow circular imports
+* xxxx: Private as default visibility for module definitions
+* xxxx: Disallow references in pattern strings
+* xxxx: Explicit imports
+* ...
+
+Individual rules should be optional to assure backwards compatibility. Those rule could be configured by some kind of project manifest, or file-local by pragma directives. Examples from other languages:
+
+* Perl: use strict;
+* Python: from __future__ import nested_scopes
+* Visual Basic: Option Strict On
+* C#: #pragma warning disable 414, CS3021
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
12-01-2023 14:09Matthias SimonNew Issue
05-09-2023 10:50Jens GrabowskiNote Added: 0016521
05-09-2023 10:50Jens GrabowskiAssigned To => Jens Grabowski
05-09-2023 10:50Jens GrabowskiStatusnew => assigned
07-11-2023 13:40Jens GrabowskiNote Added: 0016535
26-01-2024 16:31Olivier GenoudNote Added: 0016615
16-12-2024 11:49Jens GrabowskiNote Added: 0016723
16-12-2024 11:49Jens GrabowskiStatusassigned => resolved
16-12-2024 11:49Jens GrabowskiResolutionopen => fixed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0016521) +
+ Jens Grabowski    +
+ 05-09-2023 10:50    +
+ 		+ + + + +
+ TTF discussion: Interesting proposal. Recoomendations for TTCN-3 usage might be of interest for the future. List may be extended.
+
+
+
+ + + + + + + + + + +
+ (0016535) +
+ Jens Grabowski    +
+ 07-11-2023 13:40    +
+ 		+ + + + +
+ TTF discussion: Umbrella CR for new major release of TTCN-3.
+
+
+
+ + + + + + + + + + +
+ (0016615) +
+ Olivier Genoud    +
+ 26-01-2024 16:31    +
+ 		+ + + + +
+ - 8094: Core language shall not be mixed up with coding style guides and in general the coding style shall be project specific. Nevertheless, a configurable 'beautifier' tool could be helpful, e.g. to achieve a common indentation.
+- 8098: The proposal is not backward compatible and would cause us to change everything (all function calls would need a module prefix)! In general naming conventions shall be project-specific with project specific tools checking them.
+- 8099: There is no need to handle potential code smells at core language level, but projects may define what shall be considered as code smell and how to avoid these code smells (e.g. by appropriate tools).
+
+
+
+ + + + + + + + + + +
+ (0016723) +
+ Jens Grabowski    +
+ 16-12-2024 11:49    +
+ 		+ + + + +
+ Discussion will continue in Gitlab.
+
+ + diff --git a/docs/mantis/CR8192.md b/docs/mantis/CR8192.md new file mode 100644 index 0000000000000000000000000000000000000000..3fb4b395fed884f985803e05d0e61a89aa5e02d1 --- /dev/null +++ b/docs/mantis/CR8192.md @@ -0,0 +1,105 @@ + + + + + + + + + + + + + 0008192: Simplify import statement - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008192Part 01: TTCN-3 Core LanguageNew Featurepublic12-01-2023 14:5309-11-2023 10:48
ReporterMatthias Simon 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionwon't fix 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Clause Reference(s)8.2.3 -- Importing from Modules
Source (company - Author)Nokia - Matthias Simon
Summary0008192: Simplify import statement
DescriptionThe current specification supports a very fine-grained -- and often unnecessary -- control over importing symbols.
+
+Simplifying the specification could be beneficial:
+
+ImportDef ::= "import" ( "all" | IdentifierList ) "from" Identifier ["->" Identifier] ";"
+
+Examples:
+   import a,b,c from M -> OtherName;
+   import all from M;
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
12-01-2023 14:53Matthias SimonNew Issue
05-09-2023 10:33Jens GrabowskiNote Added: 0016520
05-09-2023 10:34Jens GrabowskiAssigned To => Jens Grabowski
05-09-2023 10:34Jens GrabowskiStatusnew => assigned
08-09-2023 22:36Jens GrabowskiProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
09-11-2023 10:48Jens GrabowskiNote Added: 0016564
09-11-2023 10:48Jens GrabowskiStatusassigned => closed
09-11-2023 10:48Jens GrabowskiResolutionopen => won't fix
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0016520) +
+ Jens Grabowski    +
+ 05-09-2023 10:33    +
+ 		+ + + + +
+ TTF discussion: To be discussed for next major release.
+
+
+
+ + + + + + + + + + +
+ (0016564) +
+ Jens Grabowski    +
+ 09-11-2023 10:48    +
+ 		+ + + + +
+ Issue will be discussed in next TTF dealing with TTCN-3 major revision. Issue will be part of CR 8180.
+
+ + diff --git a/docs/mantis/CR8193.md b/docs/mantis/CR8193.md new file mode 100644 index 0000000000000000000000000000000000000000..e38b258b67835248708a61d5157c9f213007f24f --- /dev/null +++ b/docs/mantis/CR8193.md @@ -0,0 +1,107 @@ + + + + + + + + + + + + + 0008193: Redefine keywords and reserved words - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008193Part 01: TTCN-3 Core LanguageTechnicalpublic19-01-2023 10:1516-12-2024 12:54
ReporterMatthias Simon 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusresolvedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Clause Reference(s)n/a
Source (company - Author)Nokia - Matthias Simon
Summary0008193: Redefine keywords and reserved words
DescriptionAn explicit distinction between keywords and reserved words is a prerequisite for moving language parts, such as predefined functions, matching-mechanism or timers to some kind of predefined standard library. It would also simplify BNF rules.
+
+Where's the difference?
+
+A _reserved word_ is an identifier which cannot be used as a name for user-defined variables, functions, parameters, etc. For example the identifiers "int2str", "integer", "this" or "object" are reserved words and have not special syntactic meaning except for being predefined or reserved. In some scopes reserved words are allowed to be used by the user (for example as name in field-definitions).
+
+A _keyword_ is a word with special meaning in a particular context. Keywords should not be used as identifiers (for example "for", "while", ...). There are some few exceptions however ("testcase", "class", "all", "any", ...):
+
+    testcase.stop; // "testcase" is used as identifier referencing the current testcase
+    testcase TC1() {} // "testcase" is a keyword introducing a testcase definition
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
19-01-2023 10:15Matthias SimonNew Issue
05-09-2023 10:22Jens GrabowskiNote Added: 0016519
05-09-2023 10:24Jens GrabowskiAssigned To => Jens Grabowski
05-09-2023 10:24Jens GrabowskiStatusnew => assigned
16-12-2024 12:54Jens GrabowskiNote Added: 0016727
16-12-2024 12:54Jens GrabowskiStatusassigned => resolved
16-12-2024 12:54Jens GrabowskiResolutionopen => fixed
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0016519) +
+ Jens Grabowski    +
+ 05-09-2023 10:22    +
+ 		+ + + + +
+ TTF discussion: To be discussed in the context of the next major release.
+
+
+
+ + + + + + + + + + +
+ (0016727) +
+ Jens Grabowski    +
+ 16-12-2024 12:54    +
+ 		+ + + + +
+ Discussion continues in Gitlab.
+
+ + diff --git a/docs/mantis/CR8194.md b/docs/mantis/CR8194.md new file mode 100644 index 0000000000000000000000000000000000000000..114ea3c5126f271de9e45d98345c33d01bdb8e8f --- /dev/null +++ b/docs/mantis/CR8194.md @@ -0,0 +1,212 @@ + + + + + + + + + + + + + 0008194: Optional Names for Formal Parameters - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008194Part 01: TTCN-3 Core LanguageNew Featurepublic20-01-2023 13:2621-11-2024 17:56
ReporterMatthias Simon 
Assigned ToMatthias Simon 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusresolvedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Clause Reference(s)5.4.1 -- Formal Parameters
Source (company - Author)Nokia - Matthias Simon
Summary0008194: Optional Names for Formal Parameters
DescriptionThe current TTCN-3 specification requires formal parameters to have names, even when they are not used in the code, which can create confusion when using assignment notation and make the code harder to read.
+
+To solve this problem, I propose that we allow developers to omit the names of formal parameters.
+
+This change would reduce noise in the code, as unnecessary parameter names would no longer be required. It would be especially useful when specifying built-in functions and interfaces, as it would make the code more readable and easier to understand.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
20-01-2023 13:26Matthias SimonNew Issue
05-09-2023 10:13Jens GrabowskiNote Added: 0016518
05-09-2023 10:13Jens GrabowskiAssigned To => Matthias Simon
05-09-2023 10:13Jens GrabowskiStatusnew => assigned
10-11-2023 10:19Jens GrabowskiNote Added: 0016576
21-12-2023 09:01Matthias SimonNote Added: 0016583
26-01-2024 16:32Olivier GenoudNote Added: 0016617
21-11-2024 17:56Matthias SimonNote Added: 0016699
21-11-2024 17:56Matthias SimonStatusassigned => resolved
21-11-2024 17:56Matthias SimonResolutionopen => fixed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0016518) +
+ Jens Grabowski    +
+ 05-09-2023 10:13    +
+ 		+ + + + +
+ TTF discussion: Benefit is not obvious. Examples are needed.
+
+
+
+ + + + + + + + + + +
+ (0016576) +
+ Jens Grabowski    +
+ 10-11-2023 10:19    +
+ 		+ + + + +
+ TTF discussion: Matthias will provide examples and proposal.
+
+
+
+ + + + + + + + + + +
+ (0016583) +
+ Matthias Simon    +
+ 21-12-2023 09:01    +
+ 		+ + + + +
+ It's helpful when parameters are not used, but mandatory. This happens for behaviour-types, abstract classes, traits and external functions:
+
+    type function HandlerFunc(in Request) return Response;
+    
+    external function registerHandler(in HandlerFunc);
+
+    // emptyHandler always returns an empty Response value
+    function emptyHandler(in Request) return Response {
+        return Response:{}
+    }
+
+
+
+ + + + + + + + + + +
+ (0016617) +
+ Olivier Genoud    +
+ 26-01-2024 16:32    +
+ 		+ + + + +
+ According to the example it seems, that purpose of the CR is for use of a function as parameter or variable which is not part of the core language => The CR may enable a notation which only makes sense in the context of an extension package. On the other hand, the mentioned confusion can also be avoided by appropriate naming (e.g. "p_Dummy" or "p_NotUsed"). i.e. the issue can be solved by project-specific naming conventions rather than changing the core language.
+
+
+
+ + + + + + + + + + +
+ (0016699) +
+ Matthias Simon    +
+ 21-11-2024 17:56    +
+ 		+ + + + +
+ Work continues here: https://labs.etsi.org/rep/mts/ttcn3/standard/-/issues/24 [^]
+
+ + diff --git a/docs/mantis/CR8195.md b/docs/mantis/CR8195.md new file mode 100644 index 0000000000000000000000000000000000000000..bd10df388bf178c75433d5fe3284f0d6aa67859b --- /dev/null +++ b/docs/mantis/CR8195.md @@ -0,0 +1,169 @@ + + + + + + + + + + + + + 0008195: Make specification updates easier to find - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - TTCN-3 Change Requests
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008195TTCN-3 Change RequestsEditorialpublic20-01-2023 13:3819-11-2024 13:37
ReporterMatthias Simon 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusresolvedResolutionfixed 
PlatformOSOS Version
Clause Reference(s)n/a
For STF discussion
Source (company - Author)Nokia - Matthias Simon
Summary0008195: Make specification updates easier to find
DescriptionThe TTCN-3 specification is a constantly evolving standard, making it sometimes difficult for users to find and understand the changes made.
+
+To solve this problem, I propose making the diffs of changes easier to find and providing release notes that summarize the changes, new features and any other important information.
+
+This will make it easier for users to familiarize themselves with the updated standard, and for vendors to implement the changes.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR8195-release-notes.docx (14,292) 19-03-2024 09:38
http://oldforge.etsi.org/mantis/file_download.php?file_id=4134&type=bug
Issue History
Date ModifiedUsernameFieldChange
20-01-2023 13:38Matthias SimonNew Issue
05-09-2023 09:57Jens GrabowskiAssigned To => Axel Rennoch
05-09-2023 09:57Jens GrabowskiStatusnew => assigned
05-09-2023 10:01Jens GrabowskiNote Added: 0016517
19-03-2024 09:38Axel RennochFile Added: CR8195-release-notes.docx
19-03-2024 09:39Axel RennochNote Added: 0016621
19-03-2024 09:40Axel RennochAssigned ToAxel Rennoch => Jens Grabowski
19-03-2024 09:40Axel RennochStatusassigned => acknowledged
19-11-2024 13:35Jens GrabowskiNote Added: 0016691
19-11-2024 13:37Jens GrabowskiNote Added: 0016692
19-11-2024 13:37Jens GrabowskiStatusacknowledged => resolved
19-11-2024 13:37Jens GrabowskiResolutionopen => fixed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0016517) +
+ Jens Grabowski    +
+ 05-09-2023 10:01    +
+ 		+ + + + +
+ TTF discussion: Axel will provide release notes on the TTCN-3 Web page based on latest draft before editing/voting/publication.
+
+
+
+ + + + + + + + + + +
+ (0016621) +
+ Axel Rennoch    +
+ 19-03-2024 09:39    +
+ 		+ + + + +
+ Release notes for upcoming TTCN-3 core notation (part 1) have been uploaded.
+
+
+
+ + + + + + + + + + +
+ (0016691) +
+ Jens Grabowski    +
+ 19-11-2024 13:35    +
+ 		+ + + + +
+ Done
+
+
+
+ + + + + + + + + + +
+ (0016692) +
+ Jens Grabowski    +
+ 19-11-2024 13:37    +
+ 		+ + + + +
+ Done
+
+ + diff --git a/docs/mantis/CR8196.md b/docs/mantis/CR8196.md new file mode 100644 index 0000000000000000000000000000000000000000..dc2c6611675ddaa3f99a3fba18b614749ea3551c --- /dev/null +++ b/docs/mantis/CR8196.md @@ -0,0 +1,305 @@ + + + + + + + + + + + + + 0008196: Redefining Macros as Predefined Constants - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008196Part 01: TTCN-3 Core LanguageTechnicalpublic20-01-2023 13:4216-12-2024 11:28
ReporterMatthias Simon 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusresolvedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Clause Reference(s)Annex D -- Preprocessing macros
Source (company - Author)Nokia - Matthias Simon
Summary0008196: Redefining Macros as Predefined Constants
DescriptionA problem with the current TTCN-3 specification its diversity of the language. To address this, I propose that we define macros such as _FILE__, __SCOPE__, and others, as predefined constants. This will make the language model a little smaller.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
20-01-2023 13:42Matthias SimonNew Issue
05-09-2023 09:52Jens GrabowskiNote Added: 0016515
05-09-2023 09:54Jens GrabowskiNote Added: 0016516
05-09-2023 09:54Jens GrabowskiAssigned To => Jens Grabowski
05-09-2023 09:54Jens GrabowskiStatusnew => assigned
07-11-2023 14:12Jens GrabowskiNote Added: 0016536
07-11-2023 14:14Jens GrabowskiAssigned ToJens Grabowski => Matthias Simon
08-11-2023 14:06Jens GrabowskiNote Added: 0016557
08-11-2023 14:06Jens GrabowskiAssigned ToMatthias Simon => Jens Grabowski
10-11-2023 11:05Gusztáv AdamisNote Added: 0016580
26-01-2024 16:33Olivier GenoudNote Added: 0016618
19-11-2024 13:38Jens GrabowskiNote Added: 0016693
16-12-2024 11:28Jens GrabowskiNote Added: 0016720
16-12-2024 11:28Jens GrabowskiStatusassigned => resolved
16-12-2024 11:28Jens GrabowskiResolutionopen => fixed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0016515) +
+ Jens Grabowski    +
+ 05-09-2023 09:52    +
+ 		+ + + + +
+ TTF discussion: Change macros to predefined constants. Preprocessing is not needed/used in the current standard.
+
+
+
+ + + + + + + + + + +
+ (0016516) +
+ Jens Grabowski    +
+ 05-09-2023 09:54    +
+ 		+ + + + +
+ TTF discussion: Description of macro in annex may disappear.
+
+
+
+ + + + + + + + + + +
+ (0016536) +
+ Jens Grabowski    +
+ 07-11-2023 14:12    +
+ 		+ + + + +
+ TTF discussion: Handling of preprocessing macros in the different tools has to be studied, i.e., tool vendors need to be asked.
+
+
+
+ + + + + + + + + + +
+ (0016557) +
+ Jens Grabowski    +
+ 08-11-2023 14:06    +
+ 		+ + + + +
+ TTF discussion: Feature is implemented differently in different tools. Resolution may introduce further ambiguities.
+
+
+
+ + + + + + + + + + +
+ (0016580) +
+ Gusztáv Adamis    +
+ 10-11-2023 11:05    +
+ 		+ + + + +
+ During the discussionswithin TTF it turned out, that the macros cannot be simply renamed to constants, because the macros shall be used before compilation and not during running time.
+
+Ericsson would keep this definition as it is in the current version of the standard, and if during the major revision it turns out that a new term, predefined constant shall be introduced for other reasons, then a new CR shall be raised for that.
+
+Suggest to close this CR.
+
+
+
+ + + + + + + + + + +
+ (0016618) +
+ Olivier Genoud    +
+ 26-01-2024 16:33    +
+ 		+ + + + +
+ It is not clear to us(TF160) how e.g. __LINE__ can be a constant.
+
+
+
+ + + + + + + + + + +
+ (0016693) +
+ Jens Grabowski    +
+ 19-11-2024 13:38    +
+ 		+ + + + +
+ To be discussed in the scope of TTF T40.
+
+
+
+ + + + + + + + + + +
+ (0016720) +
+ Jens Grabowski    +
+ 16-12-2024 11:28    +
+ 		+ + + + +
+ Discussion continued in Gitlab.
+
+ + diff --git a/docs/mantis/CR8197.md b/docs/mantis/CR8197.md new file mode 100644 index 0000000000000000000000000000000000000000..c7d33d431b044def50c7711f2c9831cf0c2c1284 --- /dev/null +++ b/docs/mantis/CR8197.md @@ -0,0 +1,190 @@ + + + + + + + + + + + + + 0008197: Automatic Alternative Selection for Unions - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008197Part 01: TTCN-3 Core LanguageNew Featurepublic20-01-2023 13:5923-01-2024 10:17
ReporterMatthias Simon 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionwon't fix 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Clause Reference(s)6.2.5 -- Unions
Source (company - Author)Nokia - Matthias Simon
Summary0008197: Automatic Alternative Selection for Unions
DescriptionI suggest support for automatic alternative selection for unions.
+
+This feature would make the use of unions more convenient and less verbose. Additionally, it would also be helpful for specifying useful predefined types such as Optional, Result, and others.
+Examples:
+
+type union Payload {
+    charstring name,
+    integer number,
+}
+
+var Payload p := "Joseph Malik"; // implicit field name is chosen automatically
+
+// Question: automatic selection also for right hand side contexts?
+if (p != 23) {
+   setverdict(fail, "unexpected payload");
+}
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
20-01-2023 13:59Matthias SimonNew Issue
25-07-2023 12:30Gusztáv AdamisNote Added: 0016498
26-07-2023 10:45Matthias SimonNote Added: 0016502
05-09-2023 09:06Jens GrabowskiNote Added: 0016510
05-09-2023 09:06Jens GrabowskiAssigned To => Matthias Simon
05-09-2023 09:06Jens GrabowskiStatusnew => assigned
07-11-2023 14:28Jens GrabowskiNote Added: 0016538
07-11-2023 14:28Jens GrabowskiStatusassigned => closed
07-11-2023 14:28Jens GrabowskiAssigned ToMatthias Simon => Jens Grabowski
07-11-2023 14:28Jens GrabowskiResolutionopen => won't fix
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0016498) +
+ Gusztáv Adamis    +
+ 25-07-2023 12:30    +
+ 		+ + + + +
+ It will not work, if a union has two fields of the same type
+
+type union Payload {
+    charstring name,
+    charstring birthplace,
+}
+
+var Payload p := "Joseph Malik"; // name or birthplace to be chosen?
+
+
+
+ + + + + + + + + + +
+ (0016502) +
+ Matthias Simon    +
+ 26-07-2023 10:45    +
+ 		+ + + + +
+ Yes, that's correct. The selection rules must include that alternative selections shall be unambiguous.
+
+Thanks for the mention.
+
+
+
+ + + + + + + + + + +
+ (0016510) +
+ Jens Grabowski    +
+ 05-09-2023 09:06    +
+ 		+ + + + +
+ TTF discussion: Proposal is not acceptable in its current form. Matthias will work on a new proposal.
+
+
+
+ + + + + + + + + + +
+ (0016538) +
+ Jens Grabowski    +
+ 07-11-2023 14:28    +
+ 		+ + + + +
+ TTF discussion: Problems are bigger than benefit.
+
+ + diff --git a/docs/mantis/CR8198.md b/docs/mantis/CR8198.md new file mode 100644 index 0000000000000000000000000000000000000000..c0f5591377ed6d5885a4341261a62cf44c8ea54b --- /dev/null +++ b/docs/mantis/CR8198.md @@ -0,0 +1,251 @@ + + + + + + + + + + + + + 0008198: Type requirement of value variable assignment is too restrictive. - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008198Part 01: TTCN-3 Core LanguageClarificationpublic01-02-2023 11:0915-01-2024 12:51
ReporterLevente Eros 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Clause Reference(s)11.1
Source (company - Author)
Summary0008198: Type requirement of value variable assignment is too restrictive.
DescriptionSection 11.1, Restriction a) of the TTCN-3 standard does not take into account subtypes when saying that the type of the variable being assigned a value shall be the same as the type of the assigned expression. The value of the assigned expression shall be though compatible with the type of the assignee.
Steps To ReproduceUse this:
+
+type integer positive (0..infinity);
+
+testcase exp_type() runs on ct_empty{
+  var integer i1 := 1;
+  var integer i2 := 2;
+  var positive p := i1+i2;
+}
+
+p has type positive, while i1+i2 is an integer. The two types are not the same, but the value of i1+i2 is compatible with the custom type positive too.
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR_0008198.docx (179,770) 08-11-2023 12:36
http://oldforge.etsi.org/mantis/file_download.php?file_id=4123&type=bug
Issue History
Date ModifiedUsernameFieldChange
01-02-2023 11:09Levente ErosNew Issue
04-09-2023 22:13Gusztáv AdamisNote Added: 0016506
05-09-2023 08:27Jens GrabowskiNote Added: 0016508
08-09-2023 22:34Jens GrabowskiProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
08-09-2023 22:42Jens GrabowskiAssigned To => Gusztáv Adamis
08-09-2023 22:42Jens GrabowskiStatusnew => assigned
07-11-2023 13:25Jens GrabowskiNote Added: 0016531
08-11-2023 12:36Gusztáv AdamisFile Added: CR_0008198.docx
08-11-2023 12:38Gusztáv AdamisNote Added: 0016550
08-11-2023 12:43Gusztáv AdamisNote Edited: 0016550bug_revision_view_page.php?bugnote_id=16550#r621
08-11-2023 23:42Gusztáv AdamisStatusassigned => confirmed
08-11-2023 23:42Gusztáv AdamisResolutionopen => fixed
10-11-2023 10:15Jens GrabowskiAssigned ToGusztáv Adamis => Jens Grabowski
10-11-2023 10:15Jens GrabowskiStatusconfirmed => assigned
10-11-2023 10:15Jens GrabowskiNote Added: 0016574
10-11-2023 10:15Jens GrabowskiStatusassigned => confirmed
15-01-2024 12:44Jens GrabowskiStatusconfirmed => resolved
15-01-2024 12:51Jens GrabowskiNote Added: 0016593
15-01-2024 12:51Jens GrabowskiStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0016506) +
+ Gusztáv Adamis    +
+ 04-09-2023 22:13    +
+ 		+ + + + +
+ I guess the restriction a.) "Expression shall be of type TypeOrNestedTypeDef." shall be similar to the restriction e.) of 10. Decleraring constants "e) ConstantExpression shall evaluate to a value which is type compatible TypeOrNestedTypeDef"
+
+
+Expression shall evaluate to a value which is type compatible TypeOrNestedTypeDef
+
+
+
+ + + + + + + + + + +
+ (0016508) +
+ Jens Grabowski    +
+ 05-09-2023 08:27    +
+ 		+ + + + +
+ TTF discussion: Valid issue, to be corrected. BNF has to be checked.
+
+
+
+ + + + + + + + + + +
+ (0016531) +
+ Jens Grabowski    +
+ 07-11-2023 13:25    +
+ 		+ + + + +
+ TTF discussion: To be resolved in the 2024 series of standards.
+
+
+
+ + + + + + + + + + +
+ (0016550) +
+ Gusztáv Adamis    +
+ 08-11-2023 12:38    +
(edited on: 08-11-2023 12:43)
+ 		+ + + + +
+ Expression shall evaluate to a value which is type compatible with TypeOrNestedTypeDef
+has been added. A typo is also corrected in Clause 10.
+
+Modification does not require modification in BNF.
+
+
+
+
+
+ + + + + + + + + + +
+ (0016574) +
+ Jens Grabowski    +
+ 10-11-2023 10:15    +
+ 		+ + + + +
+ ok
+
+
+
+ + + + + + + + + + +
+ (0016593) +
+ Jens Grabowski    +
+ 15-01-2024 12:51    +
+ 		+ + + + +
+ implemented as suggested
+
+ + diff --git a/docs/mantis/CR8201.md b/docs/mantis/CR8201.md new file mode 100644 index 0000000000000000000000000000000000000000..2e9bf73878aa1fd1aa271f8d0e0b849bee23777c --- /dev/null +++ b/docs/mantis/CR8201.md @@ -0,0 +1,149 @@ + + + + + + + + + + + + + 0008201: Handling empty element-values - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008201Part 09: Using XML with TTCN-3Clarificationpublic20-03-2023 09:4819-01-2024 11:25
ReporterMartin Hauch 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionwon't fix 
PlatformOSOS Version
Product Version4.11.1 (published 2020-05) 
Target VersionFixed in Version 
Clause Reference(s)6.2.11 but same problem for other base-types
For STF discussion
Source (company - Author)Devoteam GmbH, Martin Hauch
Summary0008201: Handling empty element-values
Description<element name="DigestValue" type="ds:DigestValueType"/>
+<simpleType name="DigestValueType">
+  <restriction base="base64Binary"/>
+</simpleType>
+
+How should the following value be handled in TTCN-3?
+<DigestValue/>
+
+The element DigestValue is present so it is valid xml-value. But which template in TTCN-3 matches this value?
+template DigestValue tOmit:=omit; // should not match as the element is present
+template DigestValue tAnyValue:=?; // perhaps should match as the element is present, but what is the value, if you try to save it to a variable?
+
+
Steps To Reproduce
Additional InformationExample is taken from file xmldsig-core-schema.xsd from project MCX_eutra_IWD22wk49
+
+
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
20-03-2023 09:48Martin HauchNew Issue
05-09-2023 09:21Jens GrabowskiNote Added: 0016512
05-09-2023 09:22Jens GrabowskiAssigned To => Tomas Urban
05-09-2023 09:22Jens GrabowskiStatusnew => assigned
10-11-2023 10:58Tomas UrbanNote Added: 0016579
10-11-2023 10:59Tomas UrbanAssigned ToTomas Urban => Jens Grabowski
10-11-2023 10:59Tomas UrbanStatusassigned => confirmed
19-01-2024 11:25Jens GrabowskiNote Added: 0016599
19-01-2024 11:25Jens GrabowskiStatusconfirmed => closed
19-01-2024 11:25Jens GrabowskiResolutionopen => won't fix
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0016512) +
+ Jens Grabowski    +
+ 05-09-2023 09:21    +
+ 		+ + + + +
+ TTF discussion: Clarification needed.
+
+
+
+ + + + + + + + + + +
+ (0016579) +
+ Tomas Urban    +
+ 10-11-2023 10:58    +
+ 		+ + + + +
+ The value of an empty element is an empty string. You can find the main guidelines in clause 3.1 of World Wide Web Consortium W3C® Recommendation: "Extensible Markup Language (XML) 1.1". Additionally, the concept of empty elements and their string value can be derived from the definition of elements with no content described in this specification.
+
+As the XSD base64Binary type translates to an octetstring in TTCN-3, the correct result of decoding would be ''O meaning that tOmit wouldn't match and tAnyValue would produce a successful match, exactly as assumed.
+
+Hopefully this clarification is satisfactory. I don't think it is necessary to change anything in part 9 as the rules specifying values of XML elements are described in the XML specification.
+
+
+
+ + + + + + + + + + +
+ (0016599) +
+ Jens Grabowski    +
+ 19-01-2024 11:25    +
+ 		+ + + + +
+ Explanation in comment from 10-11-2023, 10:58.
+
+ + diff --git a/docs/mantis/CR8210.md b/docs/mantis/CR8210.md new file mode 100644 index 0000000000000000000000000000000000000000..70be1927d2c1ee7d0d4fed326aa73a2f331d8945 --- /dev/null +++ b/docs/mantis/CR8210.md @@ -0,0 +1,301 @@ + + + + + + + + + + + + + 0008210: Clarify list subtyping of record of types - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008210Part 01: TTCN-3 Core LanguageClarificationpublic13-07-2023 09:4621-12-2023 14:44
ReporterMatthias Simon 
Assigned ToGusztáv Adamis 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Clause Reference(s)6.2.13.2 -- List subtyping of structured types and anytype
Source (company - Author)Nokia - Matthias Simon
Summary0008210: Clarify list subtyping of record of types
DescriptionClarification is needed for example 2 in section "6.2.13.2 -- List subtyping of structured types and anytype".
+
+A comment in example 2 states that type `MyRecordOfSub4` is an empty type, because the second constraint is not a possible value of `MyRecordOfSub1`.
+
+I believe this comment contradicts previous specification:
+
+> [1] Subtyping is possible [...] on an existing parent type,
+> [2] [the constraining values] shall be valid templates of the first parent type
+
+The first parent type of `MyRecordOfSub4` is `MyRecordOf` (not not `MyRecordOfSub1`).
+
+I would expect the allowed values for `MyRecordOfSub4` to be {"aa"} and {"bbb","cc"}.
+
+Rationale:
+
+1. a type is a set of allowed values. These sets can be finite (e.g. boolean, integer (1..10), ...) or infinite (e.g. integer). `any` represents the set of all possible values TTCN-3 can represent.
+2. a subtype S is the intersection of its parent type P with the set of its value constraints C (S := P*C). When C is omitted we assume it's the `any` type.
+
+Applying above definitions to `MyRecordOfSub4`:
+
+MyRecordOfSub4 := MyRecordOfSub1 * (MyRecordOfSub2, {"ddd","ee","fff"})
+MyRecordOfSub4 := ({"aa"},{"bbb","cc"},{"ddd","ee","ff"}) * ({"aa"},{"bbb","cc"},{"ddd","ee","fff"})
+MyRecordOfSub4 := ({"aa"},{"bbb","cc"})
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR8210-v1.docx (227,442) 10-11-2023 08:47
http://oldforge.etsi.org/mantis/file_download.php?file_id=4127&type=bug
docx CR8210-v2.docx (137,589) 21-12-2023 09:26
http://oldforge.etsi.org/mantis/file_download.php?file_id=4129&type=bug
Issue History
Date ModifiedUsernameFieldChange
13-07-2023 09:46Matthias SimonNew Issue
05-09-2023 09:14Jens GrabowskiNote Added: 0016511
05-09-2023 09:14Jens GrabowskiAssigned To => Tomas Urban
05-09-2023 09:14Jens GrabowskiStatusnew => assigned
05-09-2023 09:27Jens GrabowskiNote Added: 0016513
05-09-2023 09:38Jens GrabowskiNote Added: 0016514
07-11-2023 14:20Jens GrabowskiNote Added: 0016537
10-11-2023 08:47Tomas UrbanFile Added: CR8210-v1.docx
10-11-2023 09:04Tomas UrbanNote Added: 0016572
10-11-2023 09:04Tomas UrbanAssigned ToTomas Urban => Matthias Simon
10-11-2023 09:04Tomas UrbanStatusassigned => confirmed
21-12-2023 09:26Matthias SimonFile Added: CR8210-v2.docx
21-12-2023 09:29Matthias SimonNote Added: 0016584
21-12-2023 09:30Matthias SimonAssigned ToMatthias Simon => Gusztáv Adamis
21-12-2023 09:30Matthias SimonStatusconfirmed => resolved
21-12-2023 14:44Jens GrabowskiNote Added: 0016588
21-12-2023 14:44Jens GrabowskiStatusresolved => closed
21-12-2023 14:44Jens GrabowskiResolutionopen => fixed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0016511) +
+ Jens Grabowski    +
+ 05-09-2023 09:14    +
+ 		+ + + + +
+ TTF discussion: Example should be updated.
+
+
+
+ + + + + + + + + + +
+ (0016513) +
+ Jens Grabowski    +
+ 05-09-2023 09:27    +
+ 		+ + + + +
+ TTF discussion: Example should be updated. The term "first parent type" needs to be specified/clarified. Definitions have to be checked.
+
+
+
+ + + + + + + + + + +
+ (0016514) +
+ Jens Grabowski    +
+ 05-09-2023 09:38    +
+ 		+ + + + +
+ TTF discussions: Definitions to be clarified/specified: parent type, root type, first parent type, base type
+
+
+
+ + + + + + + + + + +
+ (0016537) +
+ Jens Grabowski    +
+ 07-11-2023 14:20    +
+ 		+ + + + +
+ TTF discussion: To be resolved in the next version.
+
+
+
+ + + + + + + + + + +
+ (0016572) +
+ Tomas Urban    +
+ 10-11-2023 09:04    +
+ 		+ + + + +
+ I uploaded the first draft. The mentioned example has a new comment saying that this definition is invalid. I also changed all comments that contained words "causes an error" replacing this expression with "an invalid type" in order to have the same commenting style in all examples.
+
+Terminology changes:
+Root type - kept. The meaning is narrower, basically equal to TTCN-3 type keywords
+Base type - removed, because it was rarely used, had no fixed meaning and it was possible to replace with other terms. Besides, it was too similar to the basic type.
+Parent type - kept. The meaning is narrower, it is used in subtyping only. Components use a different mechanism so they got a different term
+First parent type - removed, replaced with a core type
+Core type - equal to the root type for basic types, default, timer and open type. In case of all other types, it is basically the type whose declaration defines the type structure and dimensions. Explained in the terminology section.
+Supertype - new term for component types, similar to terminology used in the object extension (class -> superclass)
+
+
+
+ + + + + + + + + + +
+ (0016584) +
+ Matthias Simon    +
+ 21-12-2023 09:29    +
+ 		+ + + + +
+ Great work. It's much easier to understand.
+
+I uploaded another version of the document containing a fix for the invalid example and a definition for "supertype".
+
+Note, we have not defined what "invalid type" implies. This is a discussion for another TF, though.
+
+
+
+ + + + + + + + + + +
+ (0016588) +
+ Jens Grabowski    +
+ 21-12-2023 14:44    +
+ 		+ + + + +
+ implemented as suggested.
+
+ + diff --git a/docs/mantis/CR8211.md b/docs/mantis/CR8211.md new file mode 100644 index 0000000000000000000000000000000000000000..3240e626ca502cc0d354af2521ea34336af2f5c7 --- /dev/null +++ b/docs/mantis/CR8211.md @@ -0,0 +1,266 @@ + + + + + + + + + + + + + 0008211: Obsolete restriction for subtyping list-types? - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008211Part 01: TTCN-3 Core LanguageClarificationpublic13-07-2023 10:0621-12-2023 12:38
ReporterMatthias Simon 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionwon't fix 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Clause Reference(s)6.2.13.2 -- List subtyping of structured types and anytype
Source (company - Author)Nokia - Matthias Simon
Summary0008211: Obsolete restriction for subtyping list-types?
DescriptionIt seems section "6.2.13.2 -- List subtyping of structured types and anytype" restricts the use of value constraints for list types:
+
+> List subtyping is [not] possible [on] the declaration of the first parent type
+
+Does this mean that the first subtype declaration is not allowed to have a value constraint?
+
+    type record of charstring MyRecordOf ({"aa", "bb"}) // constraint not allowed?
+
+If find the subtyping rules difficult to comprehend and to reason about. I believe a we could simplify sections about type handling (subtypes, compatibility, equality).
+
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
13-07-2023 10:06Matthias SimonNew Issue
04-09-2023 16:37Gusztáv AdamisNote Added: 0016505
05-09-2023 08:44Jens GrabowskiNote Added: 0016509
05-09-2023 08:44Jens GrabowskiAssigned To => Matthias Simon
05-09-2023 08:44Jens GrabowskiStatusnew => assigned
10-11-2023 10:21Jens GrabowskiNote Added: 0016577
21-12-2023 09:38Matthias SimonNote Added: 0016585
21-12-2023 09:38Matthias SimonAssigned ToMatthias Simon => Jens Grabowski
21-12-2023 09:38Matthias SimonStatusassigned => confirmed
21-12-2023 12:37Jens GrabowskiNote Added: 0016586
21-12-2023 12:37Jens GrabowskiStatusconfirmed => resolved
21-12-2023 12:37Jens GrabowskiResolutionopen => won't fix
21-12-2023 12:38Jens GrabowskiNote Added: 0016587
21-12-2023 12:38Jens GrabowskiStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0016505) +
+ Gusztáv Adamis    +
+ 04-09-2023 16:37    +
+ 		+ + + + +
+ Not understand. It is not a subtype, but a type declaration (with a wrong
+ syntax)
+ type record of charstring MyRecordOf ("aa", "bb") works
+
+
+
+ + + + + + + + + + +
+ (0016509) +
+ Jens Grabowski    +
+ 05-09-2023 08:44    +
+ 		+ + + + +
+ TTF discussion: Matthias will provide additional examples where the standard contradicts itself. Matthias will study if harmonization/simplification is possible.
+
+
+
+ + + + + + + + + + +
+ (0016577) +
+ Jens Grabowski    +
+ 10-11-2023 10:21    +
+ 		+ + + + +
+ TTF discussion: Matthias will check if CR can be closed after resolution of CR 8210.
+
+
+
+ + + + + + + + + + +
+ (0016585) +
+ Matthias Simon    +
+ 21-12-2023 09:38    +
+ 		+ + + + +
+ Only sub-type definitions allow the specification of constraints (record-of is a bit of an outlyer):
+
+   type record { integer x } A // Not a sub-type. No constraints allowed
+   type ParentType B // Constraints allowed.
+
+
+Resolution of CR8210 makes this part much easiert to understand.
+Hence, this CR can be closed.
+
+
+
+ + + + + + + + + + +
+ (0016586) +
+ Jens Grabowski    +
+ 21-12-2023 12:37    +
+ 		+ + + + +
+ Only sub-type definitions allow the specification of constraints (record-of is a bit of an outlyer):
+
+   type record { integer x } A // Not a sub-type. No constraints allowed
+   type ParentType B // Constraints allowed.
+
+
+Resolution of CR8210 makes this part much easiert to understand.
+Hence, this CR can be closed.
+
+
+
+ + + + + + + + + + +
+ (0016587) +
+ Jens Grabowski    +
+ 21-12-2023 12:38    +
+ 		+ + + + +
+ Only sub-type definitions allow the specification of constraints (record-of is a bit of an outlyer):
+
+   type record { integer x } A // Not a sub-type. No constraints allowed
+   type ParentType B // Constraints allowed.
+
+
+Resolution of CR8210 makes this part much easiert to understand.
+Hence, this CR can be closed.
+
+ + diff --git a/docs/mantis/CR8212.md b/docs/mantis/CR8212.md new file mode 100644 index 0000000000000000000000000000000000000000..0eb2ae865f30a5dcf5ee46949b950b3488159d0b --- /dev/null +++ b/docs/mantis/CR8212.md @@ -0,0 +1,107 @@ + + + + + + + + + + + + + 0008212: Dot missing in Example 4 of chapter 8.2.3.1 - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008212Part 01: TTCN-3 Core LanguageEditorialpublic04-09-2023 22:3121-12-2023 14:55
ReporterGusztáv Adamis 
Assigned ToJens Grabowski 
PrioritylowSeveritytrivialReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Clause Reference(s)8.2.3.1
Source (company - Author)     Gusztáv Adamis Ericsson
Summary0008212: Dot missing in Example 4 of chapter 8.2.3.1
Descriptionvar VeryLongModuleNameB MyTypeA v_myVar2 := "Test String"; // Causes an error
+// as the original module name cannot be used for referencing if the
+// imported module has been renamed.
+
+shall be corrected to
+
+var VeryLongModuleNameB.MyTypeA v_myVar2 := "Test String"; // Causes an error
+// as the original module name cannot be used for referencing if the
+// imported module has been renamed.
+
+(dot ('.') added between VeryLongModuleNameB.MyTypeA)
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR8212-v231109.docx (183,479) 09-11-2023 10:35
http://oldforge.etsi.org/mantis/file_download.php?file_id=4124&type=bug
Issue History
Date ModifiedUsernameFieldChange
04-09-2023 22:31Gusztáv AdamisNew Issue
05-09-2023 08:19Jens GrabowskiAssigned To => Jens Grabowski
05-09-2023 08:19Jens GrabowskiStatusnew => assigned
08-09-2023 22:36Jens GrabowskiProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
09-11-2023 10:35Jens GrabowskiFile Added: CR8212-v231109.docx
09-11-2023 10:35Jens GrabowskiNote Added: 0016563
09-11-2023 10:35Jens GrabowskiStatusassigned => resolved
09-11-2023 10:35Jens GrabowskiResolutionopen => fixed
21-12-2023 14:55Jens GrabowskiNote Added: 0016590
21-12-2023 14:55Jens GrabowskiStatusresolved => closed
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0016563) +
+ Jens Grabowski    +
+ 09-11-2023 10:35    +
+ 		+ + + + +
+ Typo correction will be implemented
+
+
+
+ + + + + + + + + + +
+ (0016590) +
+ Jens Grabowski    +
+ 21-12-2023 14:55    +
+ 		+ + + + +
+ Implemented as proposed
+
+ + diff --git a/docs/mantis/CR8213.md b/docs/mantis/CR8213.md new file mode 100644 index 0000000000000000000000000000000000000000..f4e75b963f2b08703d7d928d4431123efa56fd51 --- /dev/null +++ b/docs/mantis/CR8213.md @@ -0,0 +1,249 @@ + + + + + + + + + + + + + 0008213: Is map a data or a reference type? - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008213Part 01: TTCN-3 Core LanguageClarificationpublic05-09-2023 08:1915-01-2024 12:43
ReporterMatthias Simon 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Clause Reference(s)6.15.2 -- Map types
Source (company - Author)Nokia - Matthias Simon
Summary0008213: Is map a data or a reference type?
DescriptionIs map a data or a reference type?
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdocx CR8213-v1.docx (204,048) 08-11-2023 10:39
http://oldforge.etsi.org/mantis/file_download.php?file_id=4119&type=bug
docx CR8213-v2.docx (122,892) 09-11-2023 11:02
http://oldforge.etsi.org/mantis/file_download.php?file_id=4125&type=bug
docx CR8213-v3.docx (123,044) 09-11-2023 15:16
http://oldforge.etsi.org/mantis/file_download.php?file_id=4126&type=bug
Issue History
Date ModifiedUsernameFieldChange
05-09-2023 08:19Matthias SimonNew Issue
05-09-2023 08:23Jens GrabowskiNote Added: 0016507
05-09-2023 08:23Jens GrabowskiAssigned To => Tomas Urban
05-09-2023 08:23Jens GrabowskiStatusnew => assigned
07-11-2023 14:40Jens GrabowskiNote Added: 0016539
08-11-2023 10:39Tomas UrbanFile Added: CR8213-v1.docx
08-11-2023 10:44Tomas UrbanNote Added: 0016543
08-11-2023 10:44Tomas UrbanStatusassigned => confirmed
08-11-2023 10:45Tomas UrbanAssigned ToTomas Urban => Matthias Simon
09-11-2023 11:02Matthias SimonFile Added: CR8213-v2.docx
09-11-2023 15:06Matthias SimonNote Added: 0016567
09-11-2023 15:06Matthias SimonAssigned ToMatthias Simon => Jens Grabowski
09-11-2023 15:06Matthias SimonStatusconfirmed => resolved
09-11-2023 15:15Matthias SimonAssigned ToJens Grabowski => Matthias Simon
09-11-2023 15:15Matthias SimonStatusresolved => feedback
09-11-2023 15:15Matthias SimonResolutionopen => reopened
09-11-2023 15:16Matthias SimonFile Added: CR8213-v3.docx
09-11-2023 15:16Matthias SimonNote Added: 0016568
09-11-2023 15:16Matthias SimonStatusfeedback => assigned
09-11-2023 15:16Matthias SimonAssigned ToMatthias Simon => Jens Grabowski
09-11-2023 15:16Matthias SimonStatusassigned => resolved
15-01-2024 12:43Jens GrabowskiNote Added: 0016592
15-01-2024 12:43Jens GrabowskiStatusresolved => closed
15-01-2024 12:43Jens GrabowskiResolutionreopened => fixed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0016507) +
+ Jens Grabowski    +
+ 05-09-2023 08:23    +
+ 		+ + + + +
+ TTF Discussion: Clarification needed. Data type preferred due to current usage.
+
+
+
+ + + + + + + + + + +
+ (0016539) +
+ Jens Grabowski    +
+ 07-11-2023 14:40    +
+ 		+ + + + +
+ TTF discussion: To be resolved in next version.
+
+
+
+ + + + + + + + + + +
+ (0016543) +
+ Tomas Urban    +
+ 08-11-2023 10:44    +
+ 		+ + + + +
+ Resolution uploaded.
+I didn't add a specific rule saying that the map type is a data type, because such rules are already present:
+
+3.1
+data types: all types whose values or sub-elements cannot contain object references
+
+5.0
+TTCN-3 has a number of predefined data types that include basic types (such as integer, float, boolean, verdicttyte and string types) as well as structured types (such as records, sets, unions, enumerated and map types and arrays)
+
+However, I found that it would be still beneficial to add an explanatory note to map type general rules. During the resolution, I found that the map type was missing from table 3 and subtyping rules, so I added it there as well.
+
+Please check.
+
+
+
+ + + + + + + + + + +
+ (0016567) +
+ Matthias Simon    +
+ 09-11-2023 15:06    +
+ 		+ + + + +
+ Uploaded final version.
+
+Summary of resolution:
+Two places in the standard already describe map as a value type and not as reference type (7.1.3 and 19.1.1). The mentioning of "map" was missing in some places and tables and added accordingly.
+Any further clarification or notes are not required.
+
+
+
+
+ + + + + + + + + + +
+ (0016568) +
+ Matthias Simon    +
+ 09-11-2023 15:16    +
+ 		+ + + + +
+ Aligned wording with other CR ("causes an error" --> "invalid type").
+
+
+
+ + + + + + + + + + +
+ (0016592) +
+ Jens Grabowski    +
+ 15-01-2024 12:43    +
+ 		+ + + + +
+ implemented as suggested
+
+ + diff --git a/docs/mantis/CR8215.md b/docs/mantis/CR8215.md new file mode 100644 index 0000000000000000000000000000000000000000..a63b518b251ae17786f4161c7f065dddbb8cb6ae --- /dev/null +++ b/docs/mantis/CR8215.md @@ -0,0 +1,74 @@ + + + + + + + + + + + + + 0008215: Typo in 15.6.3 Example1 - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008215Part 01: TTCN-3 Core LanguageEditorialpublic09-11-2023 11:1619-01-2024 15:07
ReporterGusztáv Adamis 
Assigned ToJens Grabowski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Clause Reference(s)15.6.3
Source (company - Author)     Gusztáv Adamis Ericsson
Summary0008215: Typo in 15.6.3 Example1
DescriptionA typo:
+
+EXAMPLE 1:
+    type record of integer RoI;
+    :
+    var template RoI v_roI;
+    var template integer v_int;
+    v_roI := ({},{0},{0,0},{0,0,0});
+    v_int := t_RoI[0];
+        // shall cause an error as template list is assigned to v_roI
+
+v_int := t_RoI[0]; shall be v_int := v_RoI[0];
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
09-11-2023 11:16Gusztáv AdamisNew Issue
09-11-2023 11:16Gusztáv AdamisStatusnew => assigned
09-11-2023 11:16Gusztáv AdamisAssigned To => Jens Grabowski
09-11-2023 11:25Jens GrabowskiProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
19-01-2024 15:07Jens GrabowskiNote Added: 0016601
19-01-2024 15:07Jens GrabowskiStatusassigned => closed
19-01-2024 15:07Jens GrabowskiResolutionopen => fixed
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0016601) +
+ Jens Grabowski    +
+ 19-01-2024 15:07    +
+ 		+ + + + +
+ implemented as proposed
+
+ + diff --git a/docs/mantis/CR8216.md b/docs/mantis/CR8216.md new file mode 100644 index 0000000000000000000000000000000000000000..2938f22e62ddc2f2042a6d44a1ab2f085a715803 --- /dev/null +++ b/docs/mantis/CR8216.md @@ -0,0 +1,75 @@ + + + + + + + + + + + + + 0008216: Typos in 15.6.3. Example 8 - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008216Part 01: TTCN-3 Core LanguageEditorialpublic09-11-2023 11:3419-01-2024 15:03
ReporterGusztáv Adamis 
Assigned ToJens Grabowski 
PrioritylowSeveritytrivialReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Clause Reference(s)15.6.3
Source (company - Author)     Gusztáv Adamis Ericsson
Summary0008216: Typos in 15.6.3. Example 8
DescriptionEXAMPLE 8:
+type record of integer RoI;
+:
+var template RoI v_roI := {1, 2, * length(2), 5};
+    // transformed form: {1, 2, ?, ?, 5}
+v_roI [1] := 10; // after the assignment, t_RoI will be {1, 10, * length(2), 5}
+v_roI [2] := 3; // after the assignment, t_RoI will be {1, 10, 3, ?, 5}
+
+In the last 2 lines at the explaining comment part v_roI shall stand instead of t_RoI
+
+v_roI [1] := 10; // after the assignment, v_roI will be {1, 10, * length(2), 5}
+v_roI [2] := 3; // after the assignment, v_roI will be {1, 10, 3, ?, 5}
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
09-11-2023 11:34Gusztáv AdamisNew Issue
09-11-2023 11:34Gusztáv AdamisStatusnew => assigned
09-11-2023 11:34Gusztáv AdamisAssigned To => Jens Grabowski
19-01-2024 15:03Jens GrabowskiNote Added: 0016600
19-01-2024 15:03Jens GrabowskiStatusassigned => closed
19-01-2024 15:03Jens GrabowskiResolutionopen => fixed
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0016600) +
+ Jens Grabowski    +
+ 19-01-2024 15:03    +
+ 		+ + + + +
+ resolved as proposed
+
+ + diff --git a/docs/mantis/CR8217.md b/docs/mantis/CR8217.md new file mode 100644 index 0000000000000000000000000000000000000000..48a4f6595241337a8368737716f898ba812736d6 --- /dev/null +++ b/docs/mantis/CR8217.md @@ -0,0 +1,122 @@ + + + + + + + + + + + + + 0008217: Harmonisation needed btw 6.2.3.0 and C.2.1 (Lengthof does not count last, but not initialized elements.) - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008217Part 01: TTCN-3 Core LanguageClarificationpublic10-11-2023 10:5121-11-2024 15:04
ReporterGusztáv Adamis 
Assigned ToMatthias Simon 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusresolvedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Clause Reference(s)6.2.3.0 and C.2.1
Source (company - Author)     Gusztáv Adamis Ericsson
Summary0008217: Harmonisation needed btw 6.2.3.0 and C.2.1 (Lengthof does not count last, but not initialized elements.)
DescriptionIn 6.2.3.0 (Records and sets of single types/General) and C.2.1 (Length of strings and lists)
+
+In Example 2 of 6.2.3.0 says that this array has 3 elements
+EXAMPLE 2:
+    var MyRecordOfType v_myVariable := {
+        [0] := '111'B,
+        [1] := '101'B,
+        [2] := -
+    }
+
+    v_myVariable := { '10111'B, -, - };
+    // after this, v_myVariable contains:
+    // { '10111'B, '101'B /* unchanged */, <undefined> /* unchanged */ }
+
+while the definition of the lengthof does not count this last, existing, but not initialized element. It is emphasized at the end of Example 1 of C.2.1.
+
+
+    // Given
+    type record length(0..10) of integer MyList;
+    var MyList v_myListVar := { 0, 1, -, 2, - };
+
+    lengthof(v_myListVar);
+    // returns 4 without respect to the fact, that the element v_myListVar[2] is not initialized
+
+This is according to the specification of lengthof, but normally we would wait 5 in this situation (as is suggested in 6.2.3.0.)
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
10-11-2023 10:51Gusztáv AdamisNew Issue
19-11-2024 13:50Jens GrabowskiNote Added: 0016695
19-11-2024 13:50Jens GrabowskiAssigned To => Matthias Simon
19-11-2024 13:50Jens GrabowskiStatusnew => assigned
21-11-2024 15:04Matthias SimonNote Added: 0016696
21-11-2024 15:04Matthias SimonStatusassigned => resolved
21-11-2024 15:04Matthias SimonResolutionopen => fixed
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0016695) +
+ Jens Grabowski    +
+ 19-11-2024 13:50    +
+ 		+ + + + +
+ Please have a look and check this specific case.
+
+
+
+ + + + + + + + + + +
+ (0016696) +
+ Matthias Simon    +
+ 21-11-2024 15:04    +
+ 		+ + + + +
+ Work on this CR will continue here: https://labs.etsi.org/rep/mts/ttcn3/standard/-/issues/22 [^]
+
+ + diff --git a/docs/mantis/CR8221.md b/docs/mantis/CR8221.md new file mode 100644 index 0000000000000000000000000000000000000000..fe87f192147e4e6b511f24a7d31ab696fb04d151 --- /dev/null +++ b/docs/mantis/CR8221.md @@ -0,0 +1,66 @@ + + + + + + + + + + + + + 0008221: Typo in 6.2.13.3 Example 1 - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Ext Pack: Behaviour Types (ES 202 785)
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008221Ext Pack: Behaviour Types (ES 202 785)Editorialpublic18-01-2024 17:3216-12-2024 11:36
ReporterGusztáv Adamis 
Assigned ToJens Grabowski 
PrioritylowSeveritytrivialReproducibilityhave not tried
StatusresolvedResolutionfixed 
PlatformOSOS Version
Product Versionv1.8.1 (ongoing) 
Target VersionFixed in Version 
Clause Reference(s)6.2.13.3
Source (company - Author)     Gusztáv Adamis Ericsson
Summary0008221: Typo in 6.2.13.3 Example 1
DescriptionEXAMPLE 1: Deferred function type with.
+type function MyFunc1;
+
+with not needed.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
18-01-2024 17:32Gusztáv AdamisNew Issue
19-11-2024 13:32Jens GrabowskiAssigned To => Jens Grabowski
19-11-2024 13:32Jens GrabowskiStatusnew => assigned
16-12-2024 11:36Jens GrabowskiNote Added: 0016721
16-12-2024 11:36Jens GrabowskiStatusassigned => resolved
16-12-2024 11:36Jens GrabowskiResolutionopen => fixed
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0016721) +
+ Jens Grabowski    +
+ 16-12-2024 11:36    +
+ 		+ + + + +
+ Resolution will be done in Gitlab
+
+ + diff --git a/docs/mantis/CR8222.md b/docs/mantis/CR8222.md new file mode 100644 index 0000000000000000000000000000000000000000..152716e8a3dac92d590567a409893fe5aaf2bfd7 --- /dev/null +++ b/docs/mantis/CR8222.md @@ -0,0 +1,111 @@ + + + + + + + + + + + + + 0008222: Clarification for renaming module - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - TTCN-3 Change Requests
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008222TTCN-3 Change RequestsClarificationpublic15-03-2024 08:3422-11-2024 09:59
ReporterMartin Hauch 
Assigned ToTomas Urban 
PrioritynormalSeverityfeatureReproducibilityhave not tried
StatusresolvedResolutionopen 
PlatformOSOS Version
Clause Reference(s)TTCN-3 core language, chapter 8.2.3.1, EXAMPLE 4
For STF discussion
Source (company - Author)    Devoteam GmbH, Martin Hauch
Summary0008222: Clarification for renaming module
DescriptionIt is possible to import multiple times from one module. What is allowed for the renaming?
+1. Always the same renamed-name
+2. diffent names are allowed for each import-statement
+
+import from VerylongModuleNameB -> ShortRule1 { type MytypeA} with {encode "Rule1"};
+import from VerylongModuleNameB -> ShortRule2 { type MytypeB} with {encode "Rule2"};
+
+If 'VerylongModuleNameB' should further not be used to avoid type-clash for the type, VerylongModuleNameB could also not used for the second import?
+I.e.
+import from VerylongModuleNameB -> ShortRule1 { type MytypeA} with {encode "Rule1"};
+import from ShortRule1 -> ShortRule2 { type MytypeB} with {encode "Rule2"};
+should be used, but this means that ShortRule1 is also not usable to identify a type. In case of the renaming semantic should the original module-name be usable to define a new module-definition, or should the name be usable for field- or enumeration-values in type definitions?
+
+In my opinion the semantic of an alias-name would be easier to understand. This would allow multiple aliases for a module-name and the module-name itself is still valid to identify an object uniquely. The usage of the alias-names should be handled in the same manner as the module-name.
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
15-03-2024 08:34Martin HauchNew Issue
19-11-2024 13:30Jens GrabowskiNote Added: 0016690
19-11-2024 13:31Jens GrabowskiAssigned To => Jens Grabowski
19-11-2024 13:31Jens GrabowskiStatusnew => assigned
22-11-2024 09:22Jens GrabowskiAssigned ToJens Grabowski => Tomas Urban
22-11-2024 09:59Tomas UrbanNote Added: 0016704
22-11-2024 09:59Tomas UrbanStatusassigned => resolved
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0016690) +
+ Jens Grabowski    +
+ 19-11-2024 13:30    +
+ 		+ + + + +
+ To be considered for implementation in major release.
+
+
+
+ + + + + + + + + + +
+ (0016704) +
+ Tomas Urban    +
+ 22-11-2024 09:59    +
+ 		+ + + + +
+ Moved to gitlab: https://labs.etsi.org/rep/mts/ttcn3/standard/-/issues/28 [^]
+
+ + diff --git a/docs/mantis/CR8223.md b/docs/mantis/CR8223.md new file mode 100644 index 0000000000000000000000000000000000000000..f6aa64e6e3cb9037d41a82ac25154eb6f6818371 --- /dev/null +++ b/docs/mantis/CR8223.md @@ -0,0 +1,162 @@ + + + + + + + + + + + + + 0008223: Invalid example - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008223Part 01: TTCN-3 Core LanguageEditorialpublic28-03-2024 10:4221-11-2024 15:14
ReporterMatthias Simon 
Assigned ToMatthias Simon 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusresolvedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Clause Reference(s)19.4.2 -- The range based loop
Source (company - Author)Nokia - Matthias Simon
Summary0008223: Invalid example
DescriptionEXAMPLE 3:
+// Iterate over partially initialized ranges
+//
+var integer e, i := 0;
+for (e in {1, -, -}) {
+    i++;
+}
+log("final value:", e);
+// Output:
+// 0
+// 1
+// 2
+//final value: -
+
+Output does not match expected behavior. Example should be:
+EXAMPLE 3:
+// Iterate over partially initialized ranges
+//
+var integer e, i := 0;
+for (e in {1, -, 3}) {
+    log(i, e)
+    i++;
+}
+log("final value:", e);
+// Output:
+// 0 1
+// 1 UNINITIALIZED
+// 2 3
+// final value: 3
+//final value: -
+
+ 
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
28-03-2024 10:42Matthias SimonNew Issue
28-03-2024 11:23Matthias SimonNote Added: 0016622
19-11-2024 13:28Jens GrabowskiAssigned To => Matthias Simon
19-11-2024 13:28Jens GrabowskiStatusnew => assigned
19-11-2024 13:29Jens GrabowskiNote Added: 0016689
21-11-2024 15:14Matthias SimonNote Added: 0016697
21-11-2024 15:14Matthias SimonStatusassigned => resolved
21-11-2024 15:14Matthias SimonResolutionopen => fixed
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0016622) +
+ Matthias Simon    +
+ 28-03-2024 11:23    +
+ 		+ + + + +
+ Last line was left by accident `//final value: -` and should be removed.
+
+
+
+ + + + + + + + + + +
+ (0016689) +
+ Jens Grabowski    +
+ 19-11-2024 13:29    +
+ 		+ + + + +
+ Correct example, to be implemented in v4.17
+
+
+
+ + + + + + + + + + +
+ (0016697) +
+ Matthias Simon    +
+ 21-11-2024 15:14    +
+ 		+ + + + +
+ Will be continued here: https://labs.etsi.org/rep/mts/ttcn3/standard/-/issues/23 [^]
+
+ + diff --git a/docs/mantis/CR8224.md b/docs/mantis/CR8224.md new file mode 100644 index 0000000000000000000000000000000000000000..367c54b3245b5d8aeed8189aeb5e0a68c78fc9a1 --- /dev/null +++ b/docs/mantis/CR8224.md @@ -0,0 +1,81 @@ + + + + + + + + + + + + + 0008224: Support of XML schema version 1.1 - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - TTCN-3 Change Requests
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008224TTCN-3 Change RequestsNew Featurepublic10-09-2024 09:5522-11-2024 09:09
ReporterOlivier Genoud 
Assigned ToTomas Urban 
PriorityhighSeveritymajorReproducibilityhave not tried
StatusresolvedResolutionopen 
PlatformOSOS Version
Clause Reference(s)ES 201 873-9
For STF discussion
Source (company - Author) MCC TF160 - Olivier Genoud
Summary0008224: Support of XML schema version 1.1
DescriptionAt 3GPP RAN5, several new Mission Critical Data Message Store test cases require use of new XSDs:
+- http://www.openmobilealliance.org/tech/profiles/rest_netapi_common-v1_0.xsd [^]
+- http://www.openmobilealliance.org/tech/profiles/rest_netapi_nms-v1_0.xsd [^]
+It seems that these definitions require support of XML schema 1.1 (at least XMLSchema:dateTimeStamp from v1.1 is used).
+
+XML schema 1.0 is specified at
+  http://www.w3.org/TR/xmlschema-0 [^] XML Schema Part 0: Primer Second Edition W3C Recommendation 28 October 2004
+  http://www.w3.org/TR/xmlschema-1 [^] XML Schema Part 1: Structures Second Edition W3C Recommendation 28 October 2004
+  http://www.w3.org/TR/xmlschema-2 [^] XML Schema Part 2: Datatypes Second Edition W3C Recommendation 28 October 2004
+
+XML schema 1.1 is specified at
+  https://www.w3.org/TR/xmlschema11-1 [^] W3C XML Schema Definition Language (XSD) 1.1 Part 1: Structures W3C Recommendation 5 April 2012
+  https://www.w3.org/TR/xmlschema11-2 [^] W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes W3C Recommendation 5 April 2012
+
+ES 201 873-9 refers to XML schema 1.0 ([7], [8], [9]) but there is Note 2 in clause 6.5.0 referring to a difference between 1.0 and 1.1 for dateTime.
+=> It is not fully clear whether or up-to-which degree ES 201 873-9 supports XML schema 1.1
+
+So this ticket is to request that ES 201 873-9 is enhanced (if needed) to support XML schema 1.1 (in addition to XML schema 1.0, whose support needs to be maintained in a compatible manner).
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
10-09-2024 09:55Olivier GenoudNew Issue
10-09-2024 09:55Olivier GenoudStatusnew => assigned
10-09-2024 09:55Olivier GenoudAssigned To => Jens Grabowski
19-11-2024 13:34Jens GrabowskiAssigned ToJens Grabowski => Tomas Urban
22-11-2024 09:09Tomas UrbanNote Added: 0016701
22-11-2024 09:09Tomas UrbanStatusassigned => resolved
+
+ + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0016701) +
+ Tomas Urban    +
+ 22-11-2024 09:09    +
+ 		+ + + + +
+ Moved to gitlab.
+
+ + diff --git a/docs/mantis/CR8225.md b/docs/mantis/CR8225.md new file mode 100644 index 0000000000000000000000000000000000000000..aad046068a0232c1e78d14638f45b2ea6e5bdd19 --- /dev/null +++ b/docs/mantis/CR8225.md @@ -0,0 +1,97 @@ + + + + + + + + + + + + + 0008225: Typo in 3.1. out parameterization NOTE 3 - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008225Part 01: TTCN-3 Core LanguageEditorialpublic16-10-2024 14:5116-12-2024 11:41
ReporterGusztáv Adamis 
Assigned ToJens Grabowski 
PrioritylowSeveritytextReproducibilityhave not tried
StatusresolvedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Clause Reference(s)3.1
Source (company - Author)     Gusztáv Adamis Ericsson
Summary0008225: Typo in 3.1. out parameterization NOTE 3
DescriptionFormal an out parameters -> Formal out parameters
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
16-10-2024 14:51Gusztáv AdamisNew Issue
19-11-2024 13:15Jens GrabowskiAssigned To => Jens Grabowski
19-11-2024 13:15Jens GrabowskiStatusnew => assigned
19-11-2024 13:16Jens GrabowskiNote Added: 0016688
16-12-2024 11:41Jens GrabowskiNote Added: 0016722
16-12-2024 11:41Jens GrabowskiStatusassigned => resolved
16-12-2024 11:41Jens GrabowskiResolutionopen => fixed
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0016688) +
+ Jens Grabowski    +
+ 19-11-2024 13:16    +
+ 		+ + + + +
+ To be implemented in v4.17
+
+
+
+ + + + + + + + + + +
+ (0016722) +
+ Jens Grabowski    +
+ 16-12-2024 11:41    +
+ 		+ + + + +
+ Further processing will be done in Gitlab.
+
+ + diff --git a/docs/mantis/CR8226.md b/docs/mantis/CR8226.md new file mode 100644 index 0000000000000000000000000000000000000000..8d270547c077586b9561b4f9ebab8cf97fbc5d3e --- /dev/null +++ b/docs/mantis/CR8226.md @@ -0,0 +1,97 @@ + + + + + + + + + + + + + 0008226: 6.2.15.2 Example - declarations missing - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008226Part 01: TTCN-3 Core LanguageClarificationpublic16-10-2024 14:5811-12-2024 09:14
ReporterGusztáv Adamis 
Assigned ToGusztáv Adamis 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusresolvedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Clause Reference(s)6.2.15.2 Example
Source (company - Author)     Gusztáv Adamis Ericsson
Summary0008226: 6.2.15.2 Example - declarations missing
DescriptionIn 6.2.15.2 Example: the declarations for Connection0, ... and client0, ... are missing
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
16-10-2024 14:58Gusztáv AdamisNew Issue
19-11-2024 12:31Jens GrabowskiAssigned To => Gusztáv Adamis
19-11-2024 12:31Jens GrabowskiStatusnew => assigned
19-11-2024 13:06Jens GrabowskiNote Added: 0016686
11-12-2024 09:14Jens GrabowskiNote Added: 0016717
11-12-2024 09:14Jens GrabowskiStatusassigned => resolved
11-12-2024 09:14Jens GrabowskiResolutionopen => fixed
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0016686) +
+ Jens Grabowski    +
+ 19-11-2024 13:06    +
+ 		+ + + + +
+ To be implemented in v.4.17
+
+
+
+ + + + + + + + + + +
+ (0016717) +
+ Jens Grabowski    +
+ 11-12-2024 09:14    +
+ 		+ + + + +
+ To be continued in Gitlab
+
+ + diff --git a/docs/mantis/CR8227.md b/docs/mantis/CR8227.md new file mode 100644 index 0000000000000000000000000000000000000000..68a8ec64ec62356ce51adbc2d9326391f55b6aed --- /dev/null +++ b/docs/mantis/CR8227.md @@ -0,0 +1,108 @@ + + + + + + + + + + + + + 0008227: lengthof for map - ambigous - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008227Part 01: TTCN-3 Core LanguageClarificationpublic16-10-2024 15:0521-11-2024 16:09
ReporterGusztáv Adamis 
Assigned ToMatthias Simon 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusresolvedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Clause Reference(s)16.1.2. Table15 and C.2.1
Source (company - Author)     Gusztáv Adamis Ericsson
Summary0008227: lengthof for map - ambigous
DescriptionAccording to
+16.1.2. Table15 lengthof for map is not allowed: Return the length of a value or template of any string type, record of, set of or array lengthof
+
+While according to C.2.1 it is allowed: Length of strings and lists
+lengthof(in template (present) any inpar) return integer
+This function returns the length of a value or template that is of type bitstring, hexstring, octetstring,
+charstring, universal charstring, record of, set of, array or map.
+...
+For values of the map type, the fuction returns the number of key value pairs in the map.
+
+Guess the Table 15 was not updated when introducing map.
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
16-10-2024 15:05Gusztáv AdamisNew Issue
19-11-2024 12:56Axel RennochAssigned To => Matthias Simon
19-11-2024 12:56Axel RennochStatusnew => assigned
19-11-2024 13:05Jens GrabowskiNote Added: 0016685
21-11-2024 16:09Matthias SimonNote Added: 0016698
21-11-2024 16:09Matthias SimonStatusassigned => resolved
21-11-2024 16:09Matthias SimonResolutionopen => fixed
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0016685) +
+ Jens Grabowski    +
+ 19-11-2024 13:05    +
+ 		+ + + + +
+ To be implemented in v.4.17
+
+
+
+ + + + + + + + + + +
+ (0016698) +
+ Matthias Simon    +
+ 21-11-2024 16:09    +
+ 		+ + + + +
+ Work continues here: https://labs.etsi.org/rep/mts/ttcn3/standard/-/issues/19 [^]
+
+ + diff --git a/docs/mantis/CR8228.md b/docs/mantis/CR8228.md new file mode 100644 index 0000000000000000000000000000000000000000..0bcf93f84d7e306a3efcc91409b9bdb74888581b --- /dev/null +++ b/docs/mantis/CR8228.md @@ -0,0 +1,109 @@ + + + + + + + + + + + + + 0008228: Length of map definition - ETSI's Bug Tracker + + + + +
ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008228Part 01: TTCN-3 Core LanguageClarificationpublic16-10-2024 15:1022-11-2024 09:15
ReporterGusztáv Adamis 
Assigned ToTomas Urban 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusresolvedResolutionopen 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Clause Reference(s)6.2.15.5, 6.2.15.6, C.2.1
Source (company - Author)     Gusztáv Adamis Ericsson
Summary0008228: Length of map definition
DescriptionThe length of 'map' is defined in 3 different ways (though - at least according to the current version of the standard - they seem to mean the same
+ 
+6.2.15.5. Since there is at most one value mapped to each key in a map value, the values in the set of keys will be unique. The
+length of the map value is equal to the length of the set of keys.
+
+6.2.15.6. Since two different keys might be mapped to the same value in a map value, the values in the set of values might not be
+unique. The set of values will contain one value for each key value pair in the map. The length of the map value is equal
+to the length of the set of values.
+
+C.2.1 (implicitly): For values of the map type, the (lengthof – AG) fuction returns the number of key value pairs in the map.
+
+
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
16-10-2024 15:10Gusztáv AdamisNew Issue
19-11-2024 13:08Jens GrabowskiNote Added: 0016687
19-11-2024 13:14Jens GrabowskiAssigned To => Tomas Urban
19-11-2024 13:14Jens GrabowskiStatusnew => assigned
22-11-2024 09:15Tomas UrbanNote Added: 0016702
22-11-2024 09:15Tomas UrbanStatusassigned => resolved
+
+ + + + + + + + + + + + + + + + + + +
+ Notes
+
+
+ + + + + + + + + + +
+ (0016687) +
+ Jens Grabowski    +
+ 19-11-2024 13:08    +
+ 		+ + + + +
+ Tomas to check and think about harmonization.
+On agreement: To be implemented in v.4.17
+
+
+
+ + + + + + + + + + +
+ (0016702) +
+ Tomas Urban    +
+ 22-11-2024 09:15    +
+ 		+ + + + +
+ Moved to gitlab: https://labs.etsi.org/rep/mts/ttcn3/standard/-/issues/26 [^]
+
+ + diff --git a/docs/mantis/README.md b/docs/mantis/README.md new file mode 100644 index 0000000000000000000000000000000000000000..d66dcfbd5366ab35078818a3b637092d6ddda0da --- /dev/null +++ b/docs/mantis/README.md @@ -0,0 +1,6 @@ +# Mantis CR + +This folder contains a copy of our Mantis CRs. + +Mantis is was the bug tracking system used by the project before it was +replaced by GitLab.