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

ID | Project | Category | View Status | Date Submitted | Last Update
0006696 | Part 09: Using XML with TTCN-3 | Technical | public | 05-03-2014 16:26 | 26-01-2015 11:26

Reporter | Tomas Urban |
Assigned To | Gyorgy Rethy |
Priority | urgent | Severity | minor | Reproducibility | N/A
Status | closed | Resolution | fixed |
Platform |  | OS |  | OS Version |
Product Version | v4.5.1 (published 2013-04) |
Target Version | v4.6.1 (published 2015-06) | Fixed in Version | v4.5.2 (interim 2014) |
Clause Reference(s) | 5
For STF discussion |
Source (company - Author) | STF 475

Summary | 0006696: Import of the XSD module

Description

The specification contains different rules for using the built-in XSD data types in case of implicit and explicit mapping:
Built-in data types, described in detail in clause 6, in case of an implicit conversion are internal to the tool and can be referenced directly by the user, while in case of an explicit conversion, the user shall have to import the XSD.ttcn module (see annex A) in addition to the TTCN-3 modules resulted from the conversion.
First, it is not obvious what the scope of this rule is. Is the rule related just to the internal represantation (that is invisible to the user) in case of implicit conversion and to the generated TTCN-3 modules in case of explicit conversion or is it a rule for all modules that import anything from XSD or is it a general rule for all modules in the test suite (if XSD support is available/switched on)? The specification should provide a clear answer to this question to avoid different interpretations by tool vendors.
Dependent on the answer to the above mentioned questions there are additional issues concerning the situation when the user has to use any of the definitions from the XSD module in the code, e.g. when writing functions that use the types from the XSD module as arguments/return types.
I will start with the situation when XSD types are visible in the user code. In this case, the rule causes a significant problem when writing test suites that should work with both approaches. If the test suite requires to use any of the built-in types, it has to explicitly import the XSD module in order to support explicit conversion. However, it is not clear if this will work with implicit conversion, because the specification doesn't require that a tool using implicit conversion shall support explicit import of the XSD module (even though it is not forbiden either).
It is also not obvious what are the namespace impacts of the "built-in data types ... can be referenced" rule in case of implicit conversion. Does it mean that these names are inserted into the namespace (together with the XSD module) in the same way as in case of an imported module?
In case the above mentioned rule concerns the internal representation/generated modules only, there's a question if a tool using implicit conversion should support explicit import the XSD module in order to use the types defined in it. Again, this is related to the fact that the specification doesn't require the tools using implicit conversion shall support explicit import of the XSD module.
The solution I propose is following:
1. The rule is related only to the internal representation (in case of implicit approach) and to the generated code (in case of explicit approach), i.e. the definitions from the XSD module cannot be automatically referenced in the modules written by the user.
2. Tools that use implicit approach should allow explicit import of the XSD module (even if it is not physically present in the test suite, i.e. it is provided by the tool), in order to allow using definitions from it in the modules written by the user.
There is also one minor additional problem connected with the above mentioned rule: it mentions a file name (XSD.ttcn), but the core language specification considers file system mapping to be tool-specific. In my opinion, module name shall be used instead.

Steps To Reproduce |
Additional Information |
Tags | No tags attached.
Relationships |
Attached Files | CR6696_resolution_v1.doc (89,600) 20-06-2014 10:54 http://oldforge.etsi.org/mantis/file_download.php?file_id=3073&type=bug CR6696_resolution_v2.doc (90,112) 20-06-2014 11:45 http://oldforge.etsi.org/mantis/file_download.php?file_id=3074&type=bug CR6696_resolution_v3.doc (90,624) 23-06-2014 15:49 http://oldforge.etsi.org/mantis/file_download.php?file_id=3075&type=bug

Issue History
Date Modified | Username | Field | Change
05-03-2014 16:26 | Tomas Urban | New Issue |
08-04-2014 09:12 | Gyorgy Rethy | Assigned To | => Gyorgy Rethy
08-04-2014 09:12 | Gyorgy Rethy | Priority | normal => high
08-04-2014 09:12 | Gyorgy Rethy | Status | new => assigned
08-04-2014 09:12 | Gyorgy Rethy | Target Version | => v4.6.1 (published 2015-06)
20-06-2014 10:01 | Gyorgy Rethy | Priority | high => urgent
20-06-2014 10:54 | Gyorgy Rethy | File Added: CR6696_resolution_v1.doc |
20-06-2014 10:55 | Gyorgy Rethy | Note Added: 0012184 |
20-06-2014 10:55 | Gyorgy Rethy | Assigned To | Gyorgy Rethy => Tomas Urban
20-06-2014 10:55 | Gyorgy Rethy | Status | assigned => confirmed
20-06-2014 11:45 | Tomas Urban | File Added: CR6696_resolution_v2.doc |
20-06-2014 11:49 | Tomas Urban | Note Added: 0012187 |
20-06-2014 11:49 | Tomas Urban | Assigned To | Tomas Urban => Gyorgy Rethy
20-06-2014 11:50 | Tomas Urban | Note Edited: 0012187 | bug_revision_view_page.php?bugnote_id=12187#r61
20-06-2014 11:50 | Tomas Urban | Note Edited: 0012187 | bug_revision_view_page.php?bugnote_id=12187#r62
23-06-2014 15:49 | Gyorgy Rethy | File Added: CR6696_resolution_v3.doc |
23-06-2014 15:51 | Gyorgy Rethy | Note Added: 0012194 |
23-06-2014 15:51 | Gyorgy Rethy | Status | confirmed => resolved
23-06-2014 15:51 | Gyorgy Rethy | Fixed in Version | => v4.6.1 (published 2015-06)
23-06-2014 15:51 | Gyorgy Rethy | Resolution | open => fixed
24-06-2014 09:30 | Gyorgy Rethy | Note Added: 0012195 |
24-06-2014 09:30 | Gyorgy Rethy | Status | resolved => closed
24-06-2014 09:30 | Gyorgy Rethy | Fixed in Version | v4.6.1 (published 2015-06) => v4.5.2 (interim 2014)
26-01-2015 11:21 | Gyorgy Rethy | Fixed in Version | v4.5.2 (interim 2014) => v4.6.1 (published 2015-06)
26-01-2015 11:26 | Gyorgy Rethy | Fixed in Version | v4.6.1 (published 2015-06) => v4.5.2 (interim 2014)

Notes

(0012184)
Gyorgy Rethy
20-06-2014 10:55

Proposed resolution draft is in CR6696_resolution_v1.doc. Pls. review.

(0012187)
Tomas Urban
20-06-2014 11:49 (edited on: 20-06-2014 11:50)

Besides editorial changes, I made two modifications: 1. Explicit import of the XSD module is possible in case of implicit mapping 2. Explicit mapping allows to use the "XSD" language tag for importing generated modules as an option. Both changes are required for writing code that will compile in all TTCN-3 tools regardless of whether they use one or the other conversion.

(0012194)
Gyorgy Rethy
23-06-2014 15:51

Final text in CR6696_resolution_v3.doc. Added: if importing a TTCN-3 module and the import statement uses the language "XSD" clause, the imported module shall have an XML encode attribute attached.

(0012195)
Gyorgy Rethy
24-06-2014 09:30

Implemented in master copy of V4.5.2.