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

ID | Project | Category | View Status | Date Submitted | Last Update
0006766 | Part 09: Using XML with TTCN-3 | Technical | public | 03-06-2014 15:46 | 04-01-2016 11:01

Reporter | Jacob Wieland - Spirent |
Assigned To | Gyorgy Rethy |
Priority | normal | Severity | minor | Reproducibility | have not tried
Status | closed | Resolution | fixed |
Platform |  | OS |  | OS Version |
Product Version | v4.6.1 (published 2015-06) |
Target Version | v4.7.1 (published 2016-07) | Fixed in Version | v4.7.1 (published 2016-07) |
Clause Reference(s) | 7.5.3, 6.1.5
For STF discussion |
Source (company - Author) | Testing Technologies - Jacob Wieland

Summary | 0006766: enumeration facet applied to a union-simple-type-derivation should yield an enumeration type

Description

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

Relationships

duplicate of | 0006752 | closed | Gyorgy Rethy | Rules for transformation of enumerated facet applied to union content

Attached Files |

Issue History
Date Modified | Username | Field | Change
03-06-2014 15:46 | Jacob Wieland - Spirent | New Issue |
03-06-2014 15:46 | Jacob Wieland - Spirent | Status | new => assigned
03-06-2014 15:46 | Jacob Wieland - Spirent | Assigned To | => Gyorgy Rethy
03-06-2014 15:47 | Jacob Wieland - Spirent | Relationship added | related to 0006725
03-06-2014 15:47 | Jacob Wieland - Spirent | Relationship added | related to 0006752
03-06-2014 15:47 | Jacob Wieland - Spirent | Relationship deleted | related to 0006725
05-11-2014 09:12 | Gyorgy Rethy | Assigned To | Gyorgy Rethy => Tomas Urban
05-11-2014 09:14 | Gyorgy Rethy | Assigned To | Tomas Urban => Gyorgy Rethy
05-11-2014 09:14 | Gyorgy Rethy | Relationship replaced | duplicate of 0006752
18-12-2014 13:44 | Gyorgy Rethy | Note Added: 0012563 |
18-12-2014 13:44 | Gyorgy Rethy | Status | assigned => confirmed
29-12-2014 15:00 | Gyorgy Rethy | Note Added: 0012587 |
29-12-2014 15:00 | Gyorgy Rethy | Target Version | v4.6.1 (published 2015-06) => v4.7.1 (published 2016-07)
05-11-2015 08:44 | Gyorgy Rethy | Assigned To | Gyorgy Rethy => Axel Rennoch
05-11-2015 08:44 | Gyorgy Rethy | Status | confirmed => assigned
27-12-2015 11:23 | Axel Rennoch | Note Added: 0013648 |
27-12-2015 11:23 | Axel Rennoch | Status | assigned => resolved
27-12-2015 11:23 | Axel Rennoch | Resolution | open => fixed
27-12-2015 11:23 | Axel Rennoch | Assigned To | Axel Rennoch => Gyorgy Rethy
04-01-2016 11:01 | Gyorgy Rethy | Fixed in Version | => v4.7.1 (published 2016-07)
04-01-2016 11:01 | Gyorgy Rethy | Note Added: 0013651 |
04-01-2016 11:01 | Gyorgy Rethy | Status | resolved => 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