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

ID | Project | Category | View Status | Date Submitted | Last Update
0005897 | Part 09: Using XML with TTCN-3 | New Feature | public | 14-06-2011 12:37 | 01-12-2011 14:07

Reporter | Jacob Wieland - Spirent |
Assigned To | Gyorgy Rethy |
Priority | high | Severity | minor | Reproducibility | have not tried
Status | closed | Resolution | fixed |
Platform |  | OS |  | OS Version |
Product Version |  |
Target Version | v4.4.1 (published 2012-04) | Fixed in Version | v4.4.1 (published 2012-04) |
Clause Reference(s) | XSD Language Mapping, section 7.7
For STF discussion |
Source (company - Author) | Testing Technologies - Jacob Wieland

Summary | 0005897: attr-field should be optional

Description

When the XSD type definition contains an anyAttributes element, this at the moment is mapped to a field named 'attr' which is a record of XSD.string.
For user friendliness this field should be optional as in probably 99% of the cases, the field will be the empty list and thus it is nicer to just be able to omit it.
To avoid confusion between the empty list and omit, the field could get a length restriction of at least 1.
The only drawback that I see is a backward compatibility issue where ?-templates used for that field would need to be changed to * to keep the same meaning.

Steps To Reproduce |
Additional Information |
Tags | No tags attached.
Relationships |
Attached Files | CR5897_resolution_v2.doc (97,792) 29-09-2011 14:56 http://oldforge.etsi.org/mantis/file_download.php?file_id=2576&type=bug CR5897_resolution_v3.doc (99,840) 01-12-2011 08:52 http://oldforge.etsi.org/mantis/file_download.php?file_id=2630&type=bug

Issue History
Date Modified | Username | Field | Change
14-06-2011 12:37 | Jacob Wieland - Spirent | New Issue |
14-06-2011 12:37 | Jacob Wieland - Spirent | Clause Reference(s) | => XSD Language Mapping, section 7.7
14-06-2011 12:37 | Jacob Wieland - Spirent | Source (company - Author) | => Testing Technologies - Jacob Wieland
29-06-2011 12:59 | Gyorgy Rethy | Note Added: 0010143 |
29-06-2011 13:01 | Gyorgy Rethy | Status | new => assigned
29-06-2011 13:01 | Gyorgy Rethy | Assigned To | => Gyorgy Rethy
13-07-2011 17:06 | Gyorgy Rethy | Target Version | => Edition 4.4.1
28-09-2011 12:45 | Gyorgy Rethy | Note Added: 0010272 |
28-09-2011 12:55 | Gyorgy Rethy | File Added: CR5897_resolution_v1.doc |
28-09-2011 12:57 | Gyorgy Rethy | Note Edited: 0010272 |
28-09-2011 12:57 | Gyorgy Rethy | Assigned To | Gyorgy Rethy => Jacob Wieland - Spirent
28-09-2011 12:58 | Gyorgy Rethy | Note Edited: 0010272 |
28-09-2011 13:06 | Jacob Wieland - Spirent | Note Added: 0010274 |
28-09-2011 14:00 | Jacob Wieland - Spirent | Assigned To | Jacob Wieland - Spirent => Gyorgy Rethy
28-09-2011 14:25 | Gyorgy Rethy | Note Added: 0010276 |
29-09-2011 09:55 | Gyorgy Rethy | Note Added: 0010290 |
29-09-2011 10:01 | Gyorgy Rethy | Note Edited: 0010290 |
29-09-2011 14:53 | Gyorgy Rethy | File Deleted: CR5897_resolution_v1.doc |
29-09-2011 14:56 | Gyorgy Rethy | File Added: CR5897_resolution_v2.doc |
29-09-2011 14:57 | Gyorgy Rethy | Note Added: 0010300 |
29-09-2011 14:57 | Gyorgy Rethy | Assigned To | Gyorgy Rethy => Jacob Wieland - Spirent
29-09-2011 15:39 | Jacob Wieland - Spirent | Note Added: 0010302 |
29-09-2011 15:42 | Jacob Wieland - Spirent | Assigned To | Jacob Wieland - Spirent => Gyorgy Rethy
29-09-2011 16:11 | Gyorgy Rethy | Note Added: 0010304 |
29-09-2011 16:13 | Gyorgy Rethy | Note Edited: 0010304 |
29-09-2011 16:22 | Gyorgy Rethy | Note Edited: 0010304 |
29-09-2011 16:27 | Jacob Wieland - Spirent | Note Added: 0010305 |
28-11-2011 13:24 | Gyorgy Rethy | Note Added: 0010346 |
01-12-2011 08:20 | Gyorgy Rethy | Note Edited: 0010346 |
01-12-2011 08:52 | Gyorgy Rethy | File Added: CR5897_resolution_v3.doc |
01-12-2011 08:54 | Gyorgy Rethy | Note Added: 0010454 |
01-12-2011 08:56 | Gyorgy Rethy | Note Edited: 0010454 |
01-12-2011 08:56 | Gyorgy Rethy | Assigned To | Gyorgy Rethy => Jacob Wieland - Spirent
01-12-2011 09:33 | Jacob Wieland - Spirent | Assigned To | Jacob Wieland - Spirent => Gyorgy Rethy
01-12-2011 09:33 | Jacob Wieland - Spirent | Status | assigned => resolved
01-12-2011 09:33 | Jacob Wieland - Spirent | Resolution | open => fixed
01-12-2011 09:33 | Jacob Wieland - Spirent | Note Added: 0010458 |
01-12-2011 14:07 | Gyorgy Rethy | Status | resolved => closed
01-12-2011 14:07 | Gyorgy Rethy | Note Added: 0010483 |
01-12-2011 14:07 | Gyorgy Rethy | Fixed in Version | => Edition 4.4.1

Notes

(0010143)
Gyorgy Rethy
29-06-2011 12:59

Would provide a translation that can handle backward compatible XSD changes but also TTCN-3 backward compatibility of decoded TTCN-3 values shall be considered (e.g. a decoder option?)

(0010272)
Gyorgy Rethy
28-09-2011 12:45 (edited on: 28-09-2011 12:58)

Actually, may be omit would be more intiutive, but now it cannot be introduced without breaking backward compatibility. On the other hand, writing {} is not more difficult than write omit. Also, not less intuitive regarding its meaning. But currently this is not clearly specified, therefore I propose to add this case explicitly. See draft in CR5897_resolution_v1

(0010274)
Jacob Wieland - Spirent
28-09-2011 13:06

You forget all the people that use implicit omit. For them it is a BIG difference if they have to add attr := {} in every element which is declared with anyAttributes instead of writing nothing. Also, it clutters the code unnecessarily. So, I think a decoder option would still be a better solution.
Basically, I think the rule should be: If you can omit it in XSD, you should be able to implicitly omit it in TTCN-3 as well.

(0010276)
Gyorgy Rethy
28-09-2011 14:25

Jacob, your notes are all correct, the only my concern is backward compatibility. As thinking further on, unfortunately decoder option is not a solution here. How the user should know what type/kind of codec will be used at execution time. The two things are de-coupled by default. And, in practice, no one can guarantee that {}-s and omits are not mixing within the same code. We have to go definitely to one (optional record length(1) of) or the other ({})direction. Let discuss this.

(0010290)
Gyorgy Rethy
29-09-2011 09:55 (edited on: 29-09-2011 10:01)

STF discussion on 2011-09-29: propose the record lenght (1..infinity) of XSD.String optional solution. Ask tool vendors and warn MTS about the change.

(0010300)
Gyorgy Rethy
29-09-2011 14:57

Draft is uploaded in CR5897_resolution_v2.doc, pls. review.

(0010302)
Jacob Wieland - Spirent
29-09-2011 15:39

It is ok, I think, but I don't know why there are so many cases listed? Isn't anyAttributes always part of a complex type definition which describes the content of an element which is always mapped to a record type?

(0010304)
Gyorgy Rethy
29-09-2011 16:11 (edited on: 29-09-2011 16:22)

Thanks. Yes, it is always mapped to a record field, the examples are not about the different mappings of the anyAttribute element, but about the mappings of the different wildcards (namespace attribute of anyAttribute).
Mail to vendors and MTS-GEN has been sent, any further action shall be postponed till 21th November (deadline for answering the mail). In case of no objection, the CR can be put to the resolved state.

(0010305)
Jacob Wieland - Spirent
29-09-2011 16:27

I was referring to the sentence:
"
The anyAttribute element shall be translated, like other attributes, to a field of the enframing record type or field or union field (...). The type of this field shall be record length (1..infinity) of XSD.String, the name of the field shall be the result of applying clause ... "attr" and the field, when the enframing type is a record, shall be optional.
"
Since, I think the enframing type is always a record, the if-clause in this sentence is superfluous.

(0010346)
Gyorgy Rethy
28-11-2011 13:24 (edited on: 01-12-2011 08:20)

Elvior, OpenTTCN and TestingTech supports the proposed solution.

(0010454)
Gyorgy Rethy
01-12-2011 08:54 (edited on: 01-12-2011 08:56)

Jacob, you comment is correct, I have ammended the text accordingly (see CR5897_resolution_v3.doc). Pls. do a final cross-check. If OK, pls. set the CR to the resolved state and assign it to me.

(0010458)
Jacob Wieland - Spirent
01-12-2011 09:33

ok with me.

(0010483)
Gyorgy Rethy
01-12-2011 14:07

Added to master copy.