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

ID | Project | Category | View Status | Date Submitted | Last Update
0003309 | Part 09: Using XML with TTCN-3 | Technical | public | 06-05-2008 13:15 | 18-07-2008 09:35

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.7
For STF discussion |
Source (company - Author) |

Summary | 0003309: XSD-type "any" shall be mapped to TTCN-3-type "anytype"

Description

The first two sentences of clause 7.7 shall be replaced by the following text:
"The XSD-type 'any' shall be mapped to the TTCN-3 type 'anytype'. A decoder which encounters a known and decodable (see below) type at the place the XSD-'any' was declared shall decode this type to the corresponding TTCN-3 value and place a value of this type in the field declared as TTCN-3-'anytype'.
If the type is not known (because XSD-'any' can be used as an extension point and consequently be used for elements not known within the current Schema), the contents shall be decoded to a value of an XML string type.
Also, if the type is not decodable (e. g. due to an encoding which does not allow the recognition of the type of a value), the value shall be decoded to a value of an XML string type."
The examples below will have to be adjusted as well (replace "XSD.String" by "anytype").
Reasoning:
XSD-"any" often is used for elements declared in the same Schema, i. e. for known types. This is widely analog to the meaning of the TTCN-3 type "anytype". To leave the user with an unparsed XML string in such cases (as proposed by the draft) would pose a rather cumbersome solution and force the users to parse the unparsed XML themselves.
The proposal also does not lead to any ambiguity or variability in the behavior of the decoder; only in the case of switching from one codec to another the behavior could change (if any or both codecs disallow decoding); but in this case the unparsed contents would change anyway if it stays undecoded, i. e. encoded in the one or the other code (which certainly are not alike).

Steps To Reproduce |
Additional Information |
Tags | No tags attached.
Relationships |
Attached Files | CR3309_analysis_2008-07.ppt (73,216) 18-07-2008 09:30 http://oldforge.etsi.org/mantis/file_download.php?file_id=1557&type=bug

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

Notes

(0006322)
Gyorgy Rethy
18-07-2008 09:35

Decided not to change current mapping. There are several reasons (see attached .ppt file) but the major one is that it would make the runtime behaviour of test suites tool-dependent.