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

ID | Project | Category | View Status | Date Submitted | Last Update
0006798 | Part 09: Using XML with TTCN-3 | New Feature | public | 08-10-2014 13:06 | 02-07-2017 09:51

Reporter | Thilo Lauer |
Assigned To | KristÃ³f Szabados |
Priority | high | Severity | major | Reproducibility | have not tried
Status | closed | Resolution | fixed |
Platform |  | OS |  | OS Version |
Product Version | v4.5.1 (published 2013-04) |
Target Version | v4.9.1 (published 2018-05) | Fixed in Version | v4.8.1 (published 2017-05) |
Clause Reference(s) | TTCN-3, Part 9
For STF discussion |
Source (company - Author) | Devoteam - Thilo Lauer

Summary | 0006798: TTCN-3 Alias_or_Synonym Type Def. of an XSD Type

Description

XSD types/elements contain at source level as well as at byte/character stream level a number of additional informations compared to TTCN-3 types,
e.g. (target) namespace, attribute (yes,no), type/element name (seen at XML character stream level!). (See also Part 9, B.3 Encoding instructions).
As soon as you define an alias type definition in a TTCN-3 module, normally all this additional information from the original XSD type/element will get lost. As far as I know, Part 9 of the standard does not cover how to handle this this case.
At the last Telco, we got the issue, that RAN5 requires alias definitions,
but without the necessity to add all the XML encoding instructions.
Therefore for alias types we would like to suggest an implicit copy mechanism by the compiler at compile time:
If an TTCN-3 alias type is defined for an XSD type/element, the compiler
implicitly copies all relevant XML encoding instructions to the TTCN-3 alias type as well.
Additionally the "namespace as ... " XML encoding instruction is implicitly added to the TTCN-3 alias type. This allows to combine TTCN-3 alias types of XSD types/elements from different targetNamespaces in one (!) TTCN-3 module.
Note:
This works only for pure alias definitions.
As soon as you do more in TTCN-3, e.g. if you define a TTCN-3 record containing a field of an XSD_elementType, and some more fields with pure TTCN-3 types ...
and ...
you want to encode this TTCN-3 record type with XML, you have to add all the additional XSD information required, using the "B.3 Encoding instructions" of Part 9.
Please have a look in the uploaded PowerPoint file. It explains this issue a bit more in detail.

Steps To Reproduce |
Additional Information |
Tags | No tags attached.

Relationships

child of | 0006389 | closed | Gyorgy Rethy | Variant overwriting rules are not correct

Attached Files | CR_TTCN-3 Alias_or_Synonym Type Def. of an XSD Type.pptx (854,258) 08-10-2014 13:06 http://oldforge.etsi.org/mantis/file_download.php?file_id=3113&type=bug

Issue History
Date Modified | Username | Field | Change
08-10-2014 13:06 | Thilo Lauer | New Issue |
08-10-2014 13:06 | Thilo Lauer | File Added: CR_TTCN-3 Alias_or_Synonym Type Def. of an XSD Type.pptx |
08-10-2014 16:06 | Jacob Wieland - Spirent | Note Added: 0012292 |
08-10-2014 16:40 | Thilo Lauer | Note Added: 0012302 |
08-10-2014 16:56 | Jacob Wieland - Spirent | Note Added: 0012306 |
08-10-2014 17:01 | Thilo Lauer | Note Added: 0012307 |
09-10-2014 09:13 | Thilo Lauer | Note Deleted: 0012307 |
03-11-2014 14:17 | Gyorgy Rethy | Target Version | => v4.6.1 (published 2015-06)
03-11-2014 16:30 | Gyorgy Rethy | Note Added: 0012385 |
03-11-2014 16:30 | Gyorgy Rethy | Assigned To | => Gyorgy Rethy
03-11-2014 16:30 | Gyorgy Rethy | Status | new => assigned
04-11-2014 15:25 | Gyorgy Rethy | Relationship added | child of 0006389
04-11-2014 15:34 | Gyorgy Rethy | Note Edited: 0012385 | bug_revision_view_page.php?bugnote_id=12385#r91
04-11-2014 15:41 | Gyorgy Rethy | Note Added: 0012404 |
04-11-2014 15:44 | Gyorgy Rethy | Note Edited: 0012404 | bug_revision_view_page.php?bugnote_id=12404#r93
06-11-2014 10:12 | Gyorgy Rethy | Note Added: 0012450 |
06-11-2014 10:13 | Gyorgy Rethy | Assigned To | Gyorgy Rethy => Tomas Urban
06-11-2014 15:19 | Tomas Urban | Assigned To | Tomas Urban => Gyorgy Rethy
06-11-2014 15:20 | Tomas Urban | Note Added: 0012475 |
26-01-2015 10:11 | Gyorgy Rethy | Target Version | v4.6.1 (published 2015-06) => v4.7.1 (published 2016-07)
18-07-2016 14:52 | Jens Grabowski | Assigned To | Gyorgy Rethy => KristÃ³f Szabados
17-08-2016 12:05 | Jacob Wieland - Spirent | Target Version | v4.7.1 (published 2016-07) => v4.8.1 (published 2017-05)
17-11-2016 13:46 | Jens Grabowski | Note Added: 0014304 |
17-11-2016 13:47 | Jens Grabowski | Target Version | v4.8.1 (published 2017-05) => v4.9.1 (published 2018-05)
02-07-2017 09:51 | KristÃ³f Szabados | Note Added: 0014727 |
02-07-2017 09:51 | KristÃ³f Szabados | Status | assigned => closed
02-07-2017 09:51 | KristÃ³f Szabados | Resolution | open => fixed
02-07-2017 09:51 | KristÃ³f Szabados | Fixed in Version | => v4.8.1 (published 2017-05)

Notes

(0012292)
Jacob Wieland - Spirent
08-10-2014 16:06

I still think the aliasing should only work for XSD-element-TTCN-3 types and not for XSD-type-TTCN-3 types (as those do not carry the relevant information and could be referenced from serveral element-types, so it is not clear where to copy the element-information from).

(0012302)
Thilo Lauer
08-10-2014 16:40

You are right! I have raised CR_6800 for clarification of this issue (mostly for TTCN-3 users!) By the way: is there any meaningful use of "XSD-type-TTCN-3 types" ?

(0012306)
Jacob Wieland - Spirent
08-10-2014 16:56

the use of any non-PDU-types, I guess. Storing it in variables for more simple access for manipulation, for instance. Also, if two elements share the same type, a variable of the type-type can be used for transfer. In principle, I agree, it would have been more prudent to hide the type-types from the user somehow, but since they can be used from different other definitions, this would have been hard to achieve.

(0012385)
Gyorgy Rethy
03-11-2014 16:30 (edited on: 04-11-2014 15:34)

STF discussion: investigate the proposal, according to the proposed solution of the reporter.

(0012404)
Gyorgy Rethy
04-11-2014 15:41 (edited on: 04-11-2014 15:44)

Actually, this can/shall be handled as a subcase of the variant attribute overwriting rules within the context of the XML encode attribute, therefore to be handled within CR6389. in practical term, this would mean that the XML encode attribute shall also be attached to the module collecting the aliases (or to groups containing the aliases or to the aliases themselves).

(0012450)
Gyorgy Rethy
06-11-2014 10:12

STF discussion: to be able to resolve this request this year the rules relevant for the partial case to be defined; they shall be compatible with the general rules to be added later. name as instruction needs specific discussion.

(0012475)
Tomas Urban
06-11-2014 15:20

This issue can be fully resolve only after the rules on attributes defined in the part 9 are fully compatible with the attribute mechanism defined in the part 1 (see 0006389 for more details). Without achieving full compatibility, we would have to solve many issues similar to this one. For that reason, I propose to postpone the resolution of this CR to the next year.

(0014304)
Jens Grabowski
17-11-2016 13:46

STF is working on the overwriting rules of attributes in part 1. With a planned extension, the CR will be resolved with fewer changes than are necessary now. Complete resolution shifted to 2017 version.

(0014727)
KristÃ³f Szabados
02-07-2017 09:51

Contacting the reporter of the CR he agreed that last year's changes can solve this CR. The CR can be closed now.