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

ID | Project | Category | View Status | Date Submitted | Last Update
0008111 | Part 01: TTCN-3 Core Language | New Feature | public | 17-08-2022 06:58 | 22-11-2024 09:45

Reporter | Matthias Simon |
Assigned To | Tomas Urban |
Priority | normal | Severity | minor | Reproducibility | have not tried
Status | resolved | Resolution | open |
Platform |  | OS |  | OS Version |
Product Version |  |
Target Version |  | Fixed in Version |  |
Clause Reference(s) | Core Language Spec
Source (company - Author) | Nokia -- Matthias Simon

Summary | 0008111: Allow UTF-8 for charstrings?
Description | In 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 |
Tags | No tags attached.
Relationships |
Attached Files |

Issue History
Date Modified | Username | Field | Change
17-08-2022 06:58 | Matthias Simon | New Issue |
17-08-2022 10:17 | Jens Grabowski | Project | TTCN-3 Change Requests => Part 01: TTCN-3 Core Language
17-08-2022 10:32 | Jens Grabowski | Note Added: 0016230 |
17-08-2022 10:32 | Jens Grabowski | Assigned To | => Jens Grabowski
17-08-2022 10:32 | Jens Grabowski | Status | new => assigned
10-11-2022 10:23 | Jens Grabowski | Note Added: 0016289 |
10-11-2022 10:23 | Jens Grabowski | Assigned To | Jens Grabowski => Axel Rennoch
10-11-2022 11:56 | Axel Rennoch | Note Added: 0016293 |
10-11-2022 11:57 | Axel Rennoch | Assigned To | Axel Rennoch => Matthias Simon
10-11-2022 13:45 | Jens Grabowski | Note Added: 0016298 |
10-11-2022 13:49 | Jens Grabowski | Note Added: 0016299 |
10-11-2022 13:50 | Jens Grabowski | Assigned To | Matthias Simon => Tomas Urban
06-12-2022 09:47 | Tomas Urban | Note Added: 0016331 |
08-09-2023 22:45 | Jens Grabowski | Assigned To | Tomas Urban => Gusztáv Adamis
07-11-2023 13:23 | Jens Grabowski | Note Added: 0016530 |
07-11-2023 13:24 | Jens Grabowski | Assigned To | Gusztáv Adamis => Tomas Urban
26-01-2024 16:26 | Olivier Genoud | Note Added: 0016606 |
22-11-2024 09:45 | Tomas Urban | Note Added: 0016703 |
22-11-2024 09:45 | Tomas Urban | Status | assigned => 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 [^]