ETSI's Bug Tracker - Part 11: Using JSON with TTCN-3
View Issue Details

ID | Project | Category | View Status | Date Submitted | Last Update
0007968 | Part 11: Using JSON with TTCN-3 | [TTCN-3 Change Requests] Clarification | public | 23-07-2020 08:51 | 17-12-2020 15:19

Reporter | KristÃ³f Szabados |
Assigned To | Gyorgy Rethy |
Priority | normal | Severity | minor | Reproducibility | have not tried
Status | closed | Resolution | fixed |
Platform |  | OS |  | OS Version |
Product Version | V4.8.1 (published 2020-05) |
Target Version | V4.9.1 (ongoing) | Fixed in Version | V4.9.1 (ongoing) |

Summary | 0007968: unclear description on what can be inside of a default

Description

Section 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 |
Tags | No tags attached.
Relationships |

Attached Files

CR_7968.docx (147,206) 10-08-2020 16:34
http://oldforge.etsi.org/mantis/file_download.php?file_id=3901&type=bug
CR_7968_v2.docx (148,334) 10-08-2020 17:51
http://oldforge.etsi.org/mantis/file_download.php?file_id=3902&type=bug
CR_7968_v3.docx (148,304) 11-08-2020 10:48
http://oldforge.etsi.org/mantis/file_download.php?file_id=3906&type=bug
CR_7968_v4.docx (148,961) 11-08-2020 16:01
http://oldforge.etsi.org/mantis/file_download.php?file_id=3914&type=bug
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 Modified | Username | Field | Change
23-07-2020 08:51 | KristÃ³f Szabados | New Issue |
23-07-2020 09:13 | KristÃ³f Szabados | Note Added: 0015666 |
25-07-2020 17:23 | KristÃ³f Szabados | Note Added: 0015668 |
25-07-2020 17:31 | KristÃ³f Szabados | Note Added: 0015669 |
10-08-2020 10:19 | Jens Grabowski | Assigned To | => KristÃ³f Szabados
10-08-2020 10:19 | Jens Grabowski | Status | new => assigned
10-08-2020 16:34 | KristÃ³f Szabados | File Added: CR_7968.docx |
10-08-2020 16:37 | KristÃ³f Szabados | Note Added: 0015672 |
10-08-2020 17:51 | KristÃ³f Szabados | File Added: CR_7968_v2.docx |
10-08-2020 17:52 | KristÃ³f Szabados | Note Added: 0015673 |
11-08-2020 10:12 | KristÃ³f Szabados | Note Added: 0015677 |
11-08-2020 10:12 | KristÃ³f Szabados | Assigned To | KristÃ³f Szabados => Jacob Wieland - Spirent
11-08-2020 10:13 | Jacob Wieland - Spirent | Status | assigned => confirmed
11-08-2020 10:33 | Jacob Wieland - Spirent | Note Added: 0015678 |
11-08-2020 10:34 | Jacob Wieland - Spirent | Assigned To | Jacob Wieland - Spirent => KristÃ³f Szabados
11-08-2020 10:34 | Jacob Wieland - Spirent | Status | confirmed => assigned
11-08-2020 10:48 | KristÃ³f Szabados | File Added: CR_7968_v3.docx |
11-08-2020 10:49 | KristÃ³f Szabados | Note Added: 0015680 |
11-08-2020 16:01 | KristÃ³f Szabados | File Added: CR_7968_v4.docx |
11-08-2020 16:01 | KristÃ³f Szabados | Note Added: 0015701 |
11-08-2020 16:02 | KristÃ³f Szabados | Assigned To | KristÃ³f Szabados => Jacob Wieland - Spirent
12-08-2020 13:04 | Jacob Wieland - Spirent | Status | assigned => confirmed
12-08-2020 14:16 | Jacob Wieland - Spirent | File Added: CR_7968_v5.docx |
12-08-2020 14:18 | Jacob Wieland - Spirent | Note Added: 0015711 |
12-08-2020 14:18 | Jacob Wieland - Spirent | Assigned To | Jacob Wieland - Spirent => KristÃ³f Szabados
12-08-2020 14:18 | Jacob Wieland - Spirent | Status | confirmed => assigned
12-08-2020 14:18 | Jacob Wieland - Spirent | Status | assigned => confirmed
12-08-2020 17:30 | KristÃ³f Szabados | Note Added: 0015717 |
12-08-2020 17:30 | KristÃ³f Szabados | Assigned To | KristÃ³f Szabados => Tomas Urban
12-08-2020 17:30 | KristÃ³f Szabados | Status | confirmed => assigned
13-08-2020 11:58 | Tomas Urban | Note Added: 0015727 |
13-08-2020 11:58 | Tomas Urban | Status | assigned => resolved
13-08-2020 11:58 | Tomas Urban | Resolution | open => fixed
13-08-2020 11:58 | Tomas Urban | Assigned To | Tomas Urban => Gyorgy Rethy
17-12-2020 15:19 | Gyorgy Rethy | Note Added: 0015885 |
17-12-2020 15:19 | Gyorgy Rethy | Status | resolved => closed
17-12-2020 15:19 | Gyorgy Rethy | Product Version | => V4.8.1 (published 2020-05)
17-12-2020 15:19 | Gyorgy Rethy | Fixed in Version | => V4.9.1 (ongoing)
17-12-2020 15:19 | Gyorgy Rethy | Target 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