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

ID | Project | Category | View Status | Date Submitted | Last Update
0003313 | Part 09: Using XML with TTCN-3 | New Feature | public | 06-05-2008 13:35 | 18-07-2008 09:45

Reporter | user363 |
Assigned To | Gyorgy Rethy |
Priority | normal | Severity | major | Reproducibility | N/A
Status | closed | Resolution | won't fix |
Platform |  | OS |  | OS Version |
Product Version | v3.3.1 (published 2008-04) |
Target Version | v4.1.1 (published 2009-06) | Fixed in Version |  |
Clause Reference(s) | 7.6.4
For STF discussion |
Source (company - Author) |

Summary | 0003313: XSD-type "all" shall be mapped to the TTCN-3 type "set"

Description

The XSD-type "all" shall be mapped to the TTCN-3-type "set" (instead of "record"). Proposed text (replacing the two sentences at the start of 7.6.4):
"An /all/ content structure defines an unordered collection of optional elements. This is translated in TTCN-3 as a set with optional elements:"
The result of the mapping of the example below must be changed as well and shall be:
type set E29
{
XSD.Integer foo optional,
XSD.Float bar optional,
XSD.String ding optional
}
with
{
variant "name â€˜E29â€™ as uncapitalized";
};
Reasoning:
Both types (XSD-all and TTCN-set) represent an unordered set of fields and are therefore alike in all matters of structure and meaning. To map XSD-"all" to TTCN-3-"record" is not intuitive for the user. The additional field containing the (per definition irrelevant) order of the elements, as proposed by the draft, makes the handling of the resulting TTCN-3 type even more cumbersome.
As the mapping proposed by this CR seems to create doubts in Ericson whether this could raise problems in conjunction with special encodings like the PER, we want to point out that the codec may very well choose any fixed order it likes, e. g. the one given in the XSD files. Neither the XSD-"all" type nor the TTCN-3-"set" type regard the order of the elements as relevant, so any order must be okay by definition, and consequently the codec can choose any, also a fixed one.

Steps To Reproduce |
Additional Information |
Tags | No tags attached.
Relationships |
Attached Files | CR3313_analysis_2008-07.ppt (62,976) 18-07-2008 09:39 http://oldforge.etsi.org/mantis/file_download.php?file_id=1560&type=bug

Issue History
Date Modified | Username | Field | Change
06-05-2008 13:35 | user363 | New Issue |
06-05-2008 13:35 | user363 | Status | new => assigned
06-05-2008 13:35 | user363 | Assigned To | => Gyorgy Rethy
06-05-2008 13:35 | user363 | Clause Reference(s) | => 7.6.4
06-05-2008 13:35 | user363 | Source (company - Author) | =>
09-05-2008 10:39 | Ina Schieferdecker | Target Version | => Edition 4.1.1 (not yet published)
18-07-2008 09:39 | Gyorgy Rethy | File Added: CR3313_analysis_2008-07.ppt |
18-07-2008 09:45 | Gyorgy Rethy | Note Added: 0006325 |
18-07-2008 09:45 | Gyorgy Rethy | Status | assigned => closed
18-07-2008 09:45 | Gyorgy Rethy | Resolution | open => won't fix

Notes

(0006325)
Gyorgy Rethy
18-07-2008 09:45

Additional record of enumerated field is needed to control the order of elements in the encoded XML document explicitly (in case of XML encoding) or pass on the information transparently (i.e. in case of PER encoding) independently of the actually used codec type. Mapping to record is preserved for X.694 compatibility.