ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details

ID | Project | Category | View Status | Date Submitted | Last Update
0006752 | Part 09: Using XML with TTCN-3 | Clarification | public | 25-04-2014 08:54 | 20-12-2016 09:07

Reporter | Tomas Urban |
Assigned To | Gyorgy Rethy |
Priority | normal | Severity | minor | Reproducibility | N/A
Status | closed | Resolution | fixed |
Platform |  | OS |  | OS Version |
Product Version | v4.5.1 (published 2013-04) |
Target Version | v4.8.1 (published 2017-05) | Fixed in Version | v4.8.1 (published 2017-05) |
Clause Reference(s) | 7.5.3
For STF discussion |
Source (company - Author) | STF 475

Summary | 0006752: Rules for transformation of enumerated facet applied to union content

Description

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

Relationships

has duplicate | 0006766 | closed | Gyorgy Rethy | enumeration facet applied to a union-simple-type-derivation should yield an enumeration type

Attached Files

CR6752_resolution_v1.doc (115,200) 11-12-2014 13:27
http://oldforge.etsi.org/mantis/file_download.php?file_id=3195&type=bug
CR6752_resolution_v2.docx (72,576) 06-11-2015 10:57
http://oldforge.etsi.org/mantis/file_download.php?file_id=3371&type=bug
CR6752_resolution_v3.docx (73,277) 10-11-2015 15:28
http://oldforge.etsi.org/mantis/file_download.php?file_id=3372&type=bug
CR6752_resolution_v4.docx (74,058) 22-12-2015 08:26
http://oldforge.etsi.org/mantis/file_download.php?file_id=3396&type=bug
CR6752_resolution_v5.docx (59,285) 14-11-2016 10:00
http://oldforge.etsi.org/mantis/file_download.php?file_id=3514&type=bug
CR6752_resolution_v6.docx (61,056) 15-11-2016 09:29
http://oldforge.etsi.org/mantis/file_download.php?file_id=3515&type=bug
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 Modified | Username | Field | Change
25-04-2014 08:54 | Tomas Urban | New Issue |
25-04-2014 09:33 | Tomas Urban | Note Added: 0012054 |
03-06-2014 15:47 | Jacob Wieland - Spirent | Relationship added | related to 0006766
13-06-2014 15:41 | Gyorgy Rethy | Target Version | => v4.6.1 (published 2015-06)
15-06-2014 17:08 | Gyorgy Rethy | Assigned To | => Gyorgy Rethy
15-06-2014 17:08 | Gyorgy Rethy | Status | new => assigned
05-11-2014 09:14 | Gyorgy Rethy | Relationship replaced | has duplicate 0006766
10-12-2014 15:35 | Gyorgy Rethy | Note Added: 0012538 |
11-12-2014 13:27 | Gyorgy Rethy | File Added: CR6752_resolution_v1.doc |
11-12-2014 13:28 | Gyorgy Rethy | Note Added: 0012540 |
11-12-2014 13:29 | Gyorgy Rethy | Assigned To | Gyorgy Rethy => Tomas Urban
11-12-2014 13:29 | Gyorgy Rethy | Status | assigned => confirmed
11-12-2014 22:27 | Jacob Wieland - Spirent | Note Added: 0012542 |
15-12-2014 09:11 | Tomas Urban | Note Added: 0012547 |
15-12-2014 09:11 | Tomas Urban | Assigned To | Tomas Urban => Gyorgy Rethy
29-12-2014 14:59 | Gyorgy Rethy | Note Added: 0012586 |
29-12-2014 14:59 | Gyorgy Rethy | Target Version | v4.6.1 (published 2015-06) => v4.7.1 (published 2016-07)
05-08-2015 12:00 | Jacob Wieland - Spirent | Note Added: 0013083 |
05-08-2015 12:00 | Jacob Wieland - Spirent | Status | confirmed => assigned
07-08-2015 14:34 | Jacob Wieland - Spirent | Note Added: 0013150 |
10-08-2015 09:00 | Jacob Wieland - Spirent | Note Added: 0013151 |
05-11-2015 08:44 | Gyorgy Rethy | Assigned To | Gyorgy Rethy => Axel Rennoch
06-11-2015 10:57 | Axel Rennoch | File Added: CR6752_resolution_v2.docx |
10-11-2015 15:28 | Axel Rennoch | File Added: CR6752_resolution_v3.docx |
10-11-2015 15:30 | Axel Rennoch | Note Added: 0013520 |
10-11-2015 15:30 | Axel Rennoch | Assigned To | Axel Rennoch => Jacob Wieland - Spirent
10-11-2015 15:30 | Axel Rennoch | Status | assigned => feedback
23-11-2015 10:47 | Jacob Wieland - Spirent | Note Added: 0013535 |
23-11-2015 10:47 | Jacob Wieland - Spirent | Assigned To | Jacob Wieland - Spirent => Axel Rennoch
23-11-2015 10:47 | Jacob Wieland - Spirent | Status | feedback => assigned
22-12-2015 08:26 | Gyorgy Rethy | File Added: CR6752_resolution_v4.docx |
22-12-2015 08:26 | Gyorgy Rethy | Status | assigned => confirmed
22-12-2015 12:01 | Jacob Wieland - Spirent | Note Added: 0013647 |
22-12-2015 12:01 | Jacob Wieland - Spirent | Status | confirmed => resolved
22-12-2015 12:01 | Jacob Wieland - Spirent | Fixed in Version | => v4.7.1 (published 2016-07)
22-12-2015 12:01 | Jacob Wieland - Spirent | Resolution | open => fixed
22-12-2015 12:01 | Jacob Wieland - Spirent | Assigned To | Axel Rennoch => Gyorgy Rethy
04-01-2016 16:46 | Gyorgy Rethy | Note Added: 0013657 |
04-01-2016 16:47 | Gyorgy Rethy | Status | resolved => confirmed
05-01-2016 08:19 | Gyorgy Rethy | Note Edited: 0013657 | bug_revision_view_page.php?bugnote_id=13657#r259
05-01-2016 08:19 | Gyorgy Rethy | Assigned To | Gyorgy Rethy => Jacob Wieland - Spirent
05-01-2016 08:19 | Gyorgy Rethy | Status | confirmed => assigned
05-01-2016 08:19 | Gyorgy Rethy | Status | assigned => confirmed
05-01-2016 08:39 | Gyorgy Rethy | Note Edited: 0013657 | bug_revision_view_page.php?bugnote_id=13657#r260
05-01-2016 08:40 | Gyorgy Rethy | Note Edited: 0013657 | bug_revision_view_page.php?bugnote_id=13657#r261
05-01-2016 10:29 | Jacob Wieland - Spirent | Note Added: 0013659 |
21-07-2016 11:30 | Jacob Wieland - Spirent | Assigned To | Jacob Wieland - Spirent => KristÃ³f Szabados
21-07-2016 11:30 | Jacob Wieland - Spirent | Status | confirmed => assigned
17-08-2016 12:06 | Jacob Wieland - Spirent | Fixed in Version | v4.7.1 (published 2016-07) =>
17-08-2016 12:06 | Jacob Wieland - Spirent | Target Version | v4.7.1 (published 2016-07) => v4.8.1 (published 2017-05)
14-11-2016 10:00 | KristÃ³f Szabados | File Added: CR6752_resolution_v5.docx |
15-11-2016 09:29 | KristÃ³f Szabados | File Added: CR6752_resolution_v6.docx |
15-11-2016 09:30 | KristÃ³f Szabados | Assigned To | KristÃ³f Szabados => Axel Rennoch
15-11-2016 09:31 | KristÃ³f Szabados | Note Added: 0014234 |
16-11-2016 13:15 | Axel Rennoch | File Added: CR6752_resolution_v7.docx |
16-11-2016 13:20 | Axel Rennoch | File Deleted: CR6752_resolution_v7.docx |
16-11-2016 13:21 | Axel Rennoch | File Added: CR6752_resolution_v7.docx |
16-11-2016 13:21 | Axel Rennoch | Note Added: 0014264 |
16-11-2016 13:23 | Axel Rennoch | Assigned To | Axel Rennoch => Gyorgy Rethy
16-11-2016 13:23 | Axel Rennoch | Status | assigned => resolved
20-12-2016 09:07 | Gyorgy Rethy | Note Added: 0014463 |
20-12-2016 09:07 | Gyorgy Rethy | Status | resolved => closed
20-12-2016 09:07 | Gyorgy Rethy | Fixed 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