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

ID | Project | Category | View Status | Date Submitted | Last Update
0005975 | Part 09: Using XML with TTCN-3 | Technical | public | 28-11-2011 14:58 | 16-12-2011 16:49

Reporter | Tomas Urban |
Assigned To | Gyorgy Rethy |
Priority | normal | Severity | minor | Reproducibility | N/A
Status | closed | Resolution | no change required |
Platform |  | OS |  | OS Version |
Product Version | v4.3.1 (published 2011-06) |
Target Version | v4.4.1 (published 2012-04) | Fixed in Version |  |
Clause Reference(s) | 7.6.4
For STF discussion |
Source (company - Author) | Elvior

Summary | 0005975: Tranformation of all compositor with minOccurs="0"

Description

In the current version of the specification, minOccurs="0" attribute applied directly to an all compositor, makes all elements of the generated TTCN-3 record optional. However, such a record type allows the user to create templates that omit some but not all of record elements. The message created from this template is invalid, it won't pass schema validation. The minOccurs="0" attribute means that either all elements are present or none of them is.
Proposal:
The correct transformation mechanism should be similar to the one used in sequence transformation, i.e. an additional untagged record wrapper shall be generated for the all compositor and the whole wrapper should be set to optional while the fields inside would stay mandatory (see 7.6.6.6 for more details).

Steps To Reproduce |
Additional Information |
Tags | No tags attached.
Relationships |
Attached Files |

Issue History
Date Modified | Username | Field | Change
28-11-2011 14:58 | Tomas Urban | New Issue |
28-11-2011 14:58 | Tomas Urban | Clause Reference(s) | => 7.6.4
28-11-2011 14:58 | Tomas Urban | Source (company - Author) | => Elvior
28-11-2011 16:33 | Gyorgy Rethy | Note Added: 0010363 |
28-11-2011 16:34 | Gyorgy Rethy | Assigned To | => Jacob Wieland - Spirent
28-11-2011 16:34 | Gyorgy Rethy | Status | new => assigned
28-11-2011 16:34 | Gyorgy Rethy | Target Version | => Edition 4.4.1
29-11-2011 09:18 | Jacob Wieland - Spirent | Note Added: 0010370 |
29-11-2011 09:18 | Jacob Wieland - Spirent | Assigned To | Jacob Wieland - Spirent => Gyorgy Rethy
02-12-2011 13:33 | Gyorgy Rethy | Note Added: 0010517 |
02-12-2011 13:34 | Gyorgy Rethy | Target Version | Edition 4.4.1 => v4.6.1 (published 2015-06)
02-12-2011 13:36 | Gyorgy Rethy | Note Edited: 0010517 |
16-12-2011 16:49 | Gyorgy Rethy | Note Added: 0010543 |
16-12-2011 16:49 | Gyorgy Rethy | Status | assigned => closed
16-12-2011 16:49 | Gyorgy Rethy | Resolution | open => no change required
16-12-2011 16:49 | Gyorgy Rethy | Target Version | v4.6.1 (published 2015-06) => Edition 4.4.1

Notes

(0010363)
Gyorgy Rethy
28-11-2011 16:33

STF discussion 28/11: to be checked, but backward compatibility shall be kept.

(0010370)
Jacob Wieland - Spirent
29-11-2011 09:18

Because of backward compatibility issues, we opt to leave the standard as it is.
Also, I could not find an explicit statement that for the all-compositor with minOccurs="0" that does not mean that it is implicitly inherited by all its children (although I think I remember reading a passage to that effect way back). I think that this was the reason why the mapping in TTCN-3 is also different than for the other cases.

(0010517)
Gyorgy Rethy
02-12-2011 13:33 (edited on: 02-12-2011 13:36)

This way of translation has been included to keep compatibility with ITU-T Recommendation X.694, i.e. users that used the path XSD->ASN.1(using X.694 and available converters)-> TTCN-3 (Part-7) could change to the direct mapping from XSD to TTCN-3 without changes in their existing code. By now, several years has passed from the first publication of Part-9. Probably (almost) all users has changed to the direct mapping, thus X.694 to Part-9 compatibility could be relaxed at some less frequently used places. However, now, backward compatibility with the already existing huge volume of TTCN-3 code is the important aspect. As the proposed change - though would unify mapping of sequence and all compositors - is not backward compatible, we cannot change the mapping in a rush. Including a tool-generated note saying that for correct message encoding all non-attribute fields shall be omitted could help (though not saving the user from making errors).
As we are finishing our last session in 2011 today, further discussions shall be postponed to 2012.

(0010543)
Gyorgy Rethy
16-12-2011 16:49

No change to maintain backward compatibility.