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

ID | Project | Category | View Status | Date Submitted | Last Update
0006800 | Part 09: Using XML with TTCN-3 | Clarification | public | 08-10-2014 16:23 | 04-12-2015 15:04

Reporter | Thilo Lauer |
Assigned To | Gyorgy Rethy |
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.7.1 (published 2016-07) | Fixed in Version | v4.7.1 (published 2016-07) |
Clause Reference(s) | TTCN-3, Part 9
For STF discussion |
Source (company - Author) | Devoteam - Thilo Lauer

Summary | 0006800: In TTCN-3 "XSD_typeTypes" should never be used for sending XML messages, instead use "XSD_elementTypes"!

Description

1.) XML / XSD does not allow to send/receive XSD type definitions itself.
XML / XSD only allows to send/receive XSD element definitions.
2.) Part 9 defines a mapping for both XSD type def. and XSD element def. to TTCN-3 types. To distinguish both ones let's call these TTCN-3 types "XSD_typeTypes" and "XSD_elementTypes" here.
3.) As a consequence of 1.) in TTCN-3 only values and templates of "XSD_elementTypes" should be used to send/receive XML-messages.
This should be made obvious to TTCN-3 users/developers.
Sending/Receiving of "XSD_typeTypes" values/templates conform to XSD definitions is currently not covered by Part 9 nor by the XML / XSD standards and should therefore be avoided.
See the uploaded PowerPoint document for an LTE example.

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

Attached Files

CR_In TTCN-3 XSD_typeTypes should never be used for sending XML messages, instead use XSD_elementTypes.pptx (855,384) 08-10-2014 16:23
http://oldforge.etsi.org/mantis/file_download.php?file_id=3120&type=bug
TTCN-3 CR 6800 - XSD_typeTypes and XSD_elementTypes.msg (35,840) 04-11-2014 13:03
http://oldforge.etsi.org/mantis/file_download.php?file_id=3156&type=bug
CR6800_v1.docx (47,211) 06-11-2014 08:45
http://oldforge.etsi.org/mantis/file_download.php?file_id=3168&type=bug
CR6800_v2.docx (48,193) 06-11-2014 13:29
http://oldforge.etsi.org/mantis/file_download.php?file_id=3176&type=bug
CR6800_v3.docx (49,100) 02-11-2015 10:39
http://oldforge.etsi.org/mantis/file_download.php?file_id=3333&type=bug

Issue History
Date Modified | Username | Field | Change
08-10-2014 16:23 | Thilo Lauer | New Issue |
08-10-2014 16:23 | Thilo Lauer | File Added: CR_In TTCN-3 XSD_typeTypes should never be used for sending XML messages, instead use XSD_elementTypes.pptx |
03-11-2014 10:13 | Gyorgy Rethy | Target Version | => v4.6.1 (published 2015-06)
03-11-2014 14:32 | Gyorgy Rethy | Priority | high => urgent
03-11-2014 14:33 | Gyorgy Rethy | Priority | urgent => high
03-11-2014 16:23 | Gyorgy Rethy | Note Added: 0012384 |
03-11-2014 16:23 | Gyorgy Rethy | Assigned To | => Gyorgy Rethy
03-11-2014 16:23 | Gyorgy Rethy | Status | new => assigned
04-11-2014 13:03 | Gyorgy Rethy | File Added: TTCN-3 CR 6800 - XSD_typeTypes and XSD_elementTypes.msg |
04-11-2014 13:07 | Gyorgy Rethy | Note Added: 0012396 |
04-11-2014 13:07 | Gyorgy Rethy | File Added: CR6800_resolution_v1.doc |
04-11-2014 13:08 | Gyorgy Rethy | Note Added: 0012397 |
04-11-2014 17:18 | Gyorgy Rethy | File Deleted: CR6800_resolution_v1.doc |
04-11-2014 17:19 | Gyorgy Rethy | File Added: CR6800_resolution_v1.doc |
04-11-2014 17:19 | Gyorgy Rethy | Assigned To | Gyorgy Rethy => Tomas Urban
05-11-2014 08:38 | Tomas Urban | Note Added: 0012413 |
05-11-2014 08:38 | Tomas Urban | Assigned To | Tomas Urban => Gyorgy Rethy
05-11-2014 08:45 | Gyorgy Rethy | Assigned To | Gyorgy Rethy => Tomas Urban
05-11-2014 09:07 | Gyorgy Rethy | File Deleted: CR6800_resolution_v1.doc |
06-11-2014 08:45 | Tomas Urban | File Added: CR6800_v1.docx |
06-11-2014 08:51 | Tomas Urban | Note Added: 0012444 |
06-11-2014 08:51 | Tomas Urban | Assigned To | Tomas Urban => Gyorgy Rethy
06-11-2014 08:51 | Tomas Urban | Status | assigned => confirmed
06-11-2014 09:42 | Gyorgy Rethy | Note Added: 0012449 |
06-11-2014 09:43 | Gyorgy Rethy | Assigned To | Gyorgy Rethy => Tomas Urban
06-11-2014 09:43 | Gyorgy Rethy | Status | confirmed => assigned
06-11-2014 13:29 | Tomas Urban | File Added: CR6800_v2.docx |
06-11-2014 13:32 | Tomas Urban | Note Added: 0012465 |
06-11-2014 14:00 | Tomas Urban | Note Added: 0012468 |
06-11-2014 14:03 | Tomas Urban | Assigned To | Tomas Urban => Gyorgy Rethy
06-11-2014 14:03 | Tomas Urban | Status | assigned => confirmed
26-01-2015 10:11 | Gyorgy Rethy | Target Version | v4.6.1 (published 2015-06) => v4.7.1 (published 2016-07)
02-11-2015 10:39 | Gyorgy Rethy | File Added: CR6800_v3.docx |
02-11-2015 10:39 | Gyorgy Rethy | Note Added: 0013434 |
02-11-2015 10:40 | Gyorgy Rethy | Assigned To | Gyorgy Rethy => Jacob Wieland - Spirent
02-11-2015 10:40 | Gyorgy Rethy | Status | confirmed => assigned
02-11-2015 13:22 | Jacob Wieland - Spirent | Note Added: 0013435 |
02-11-2015 13:22 | Jacob Wieland - Spirent | Status | assigned => resolved
02-11-2015 13:22 | Jacob Wieland - Spirent | Fixed in Version | => v4.7.1 (published 2016-07)
02-11-2015 13:22 | Jacob Wieland - Spirent | Resolution | open => fixed
04-12-2015 15:04 | Gyorgy Rethy | Note Added: 0013557 |
04-12-2015 15:04 | Gyorgy Rethy | Status | resolved => closed
04-12-2015 15:04 | Gyorgy Rethy | Assigned To | Jacob Wieland - Spirent => Gyorgy Rethy

Notes

(0012384)
Gyorgy Rethy
03-11-2014 16:23

STF discussion: friend visibility could be used to make "XSD_Type_types" visible within modules converted fron XSD specs only. Think about possible side effects.

(0012396)
Gyorgy Rethy
04-11-2014 13:07

TTCN-3 CR 6800 - XSD_typeTypes and XSD_elementTypes.msg : mail sent to Thilo Lauer on this issue. Two options sketched: - leave policing of usage of TTCN-3 types generated for XSD types for tools - use friend visibility to make TTCN-3 types generated for XSD types unvisible outside of the generated set of modules.

(0012397)
Gyorgy Rethy
04-11-2014 13:08

CR6800_resolution_v1.doc: first draft for the second option. To be further refined if this option is decided.

(0012413)
Tomas Urban
05-11-2014 08:38

I am concerned about adding friend visibility to the XSD module type definitions. It is very likely that these types are used in function definitions of existing test suites, e.g. LTE. With friend visibility, these test suits won't compile.
Before going on with this change, we should carefully check the usage of XSD_typeTypes in the existing test suites (and especially the ones maintained by ETSI) so that we don't break anything.
An alternative solution to the visibility restriction would be introduction of a modifier for type definitions that would restrict the type from being used in communication operations:
type @TBD record Rec {...} // suitable modifier name has to be found
:
p.send(Rec:{...}) // produces an error because the Rec type has the modifier
Such a solution won't break any (correctly written) TTCN-3 code, but the disadvantage is that we would make the language even more complex by introducing a new modifier.

(0012444)
Tomas Urban
06-11-2014 08:51

Proposed solution: a restriction in clause B.2 saying that only values or templates that a result of transformation of XSD elements and attributes can be used in codec operations. Values and templates derived from other XSD definitions shall cause an error. It is up to TTCN-3 tool vendors to decide whether to detect this kind of error during static compilation checks (which should be possible as encoding variants are resolved during static analysis) or in runtime when invoking the codec.

(0012449)
Gyorgy Rethy
06-11-2014 09:42

STF discussion: we need continue discussion with STF160 to agree on a mutually suitable solution. We need to prepare a summary of the possible options, pros and cons.

(0012465)
Tomas Urban
06-11-2014 13:32

Proposed solution changes according to the conclusion of STF discussion: - the rules were moved to the first section of Annex B - the rules were split to communication operations (only elements allowed) and codec operations (elements and attributes) - additional notes added to point out the posibility of static semantic check by TTCN-3 tools

(0012468)
Tomas Urban
06-11-2014 14:00

Summary of solutions considered by the STF:
1. Friend visibility of TTCN-3 types that are based on XSD type definitions
Pros: TTCN-3 types are not visible outside of the modules that are result of the XSD-to-TTCN-3 mapping, it is not possible to use them for sending/receiving.
Cons: The types cannot be used in other places where it might be handy, e.g. in parameters of parameterized templates. There's a big probability that existing test suites use them this way. The change would cause problems with backward compatibility.
Conclusion: This approach was found too restrictive and backward compatibility issues are an obvious showstopper.
2. New modifier restricting the use of types in certain operations
Pros: It would efficiently solve the problem, because the tools would indicate an error when a type with the modifier is used in forbidden operations. There would not be any backward compatibility issues as the modifier was not present in the previous versions.
Cons: Introduction of a modifier increases complexity of the language and requires changes in the core language standard.
Conclusion: It was found that the case is not strong enough for introduction of a modifier. It is also a question if modifiers can actualy be used this way.
3. Restriction disallowing the use of TTCN-3 types derived from XSD types in templates
Pros: It would solve the issue as tools would announce an error when attempting to create such templates.
Cons: Similar to 1: too restrictive, the types might be already used e.g. in template parameters. Template parameters could be actually excluded from the rule, but that makes the rules more complicated. Besides, there is still a problem with predefined template fragments that are declared formally as templates, but never used directly in communication operations. Not backward compatible.
Conclusion: Reject for problems with backward compatibility issues and excesive restrictions imposed on the users.
4. Restriction disallowing the use of TTCN-3 types derived from XSD types in communication and encoding operations
Pros: Addresses the root of the problem, i.e. the use of types that should never be passed to the codec. It should be possible to detect the error at compilation time as variant attributes are statically resolved.
Cons: The problem cannot be detected when constructing templates (but that might be actually useful when creating template fragments).
Conclusion: This proposal was selected as the main candidate for resolving the CR.

(0013434)
Gyorgy Rethy
02-11-2015 10:39

CR6800_v3.docx, please check.

(0013435)
Jacob Wieland - Spirent
02-11-2015 13:22

looks ok to me

(0013557)
Gyorgy Rethy
04-12-2015 15:04

Added to draft V4.6.3