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:5826-01-2024 16:26
ReporterMatthias Simon 
Assigned ToTomas Urban 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusassignedResolutionopen 
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

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'.