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

ID | Project | Category | View Status | Date Submitted | Last Update
0006734 | Part 09: Using XML with TTCN-3 | Technical | public | 17-04-2014 14:20 | 26-01-2015 11:45

Reporter | Tomas Urban |
Assigned To | Gyorgy Rethy |
Priority | normal | 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.6.1 (published 2015-06) |
Clause Reference(s) | 5.2.2
For STF discussion |
Source (company - Author) | STF 475

Summary | 0006734: Extension of the rule on same type identifiers
Description | The rule 5.2.2.j currently concerns only the situation when the type name is equal to another existing type name or reserved word. However, there are two more situations when a name clash can occur: conflict with the local module name and conflict with an imported module name (see 5.2.2 of the core language specification for more details). Both situations should be added to 5.2.2.j
Steps To Reproduce |
Additional Information |
Tags | No tags attached.

Relationships

related to | 0006735 | closed | Gyorgy Rethy | Missing rules for transforming XSD namespaces into TTCN-3 module names

Attached Files |

Issue History
Date Modified | Username | Field | Change
17-04-2014 14:20 | Tomas Urban | New Issue |
15-06-2014 18:02 | Gyorgy Rethy | Target Version | => v4.6.1 (published 2015-06)
16-06-2014 14:51 | Tomas Urban | File Added: CR6734_v1.docx |
16-06-2014 14:52 | Tomas Urban | Note Added: 0012087 |
16-06-2014 14:52 | Tomas Urban | Assigned To | => Gyorgy Rethy
16-06-2014 14:52 | Tomas Urban | Status | new => confirmed
16-06-2014 14:53 | Tomas Urban | File Deleted: CR6734_v1.docx |
16-06-2014 14:54 | Tomas Urban | Assigned To | Gyorgy Rethy => Tomas Urban
16-06-2014 14:54 | Tomas Urban | Status | confirmed => new
16-06-2014 14:55 | Tomas Urban | Assigned To | Tomas Urban => Gyorgy Rethy
16-06-2014 14:55 | Tomas Urban | Status | new => assigned
17-06-2014 13:17 | Tomas Urban | Note Deleted: 0012087 |
17-06-2014 13:17 | Tomas Urban | Relationship added | related to 0006735
18-06-2014 20:19 | Jacob Wieland - Spirent | Note Added: 0012136 |
19-06-2014 07:58 | Tomas Urban | Note Added: 0012137 |
19-06-2014 12:38 | Jacob Wieland - Spirent | Note Added: 0012142 |
05-11-2014 10:02 | Gyorgy Rethy | Note Added: 0012417 |
05-11-2014 10:02 | Gyorgy Rethy | Status | assigned => closed
05-11-2014 10:02 | Gyorgy Rethy | Resolution | open => fixed
05-11-2014 10:02 | Gyorgy Rethy | Fixed in Version | => v4.5.2 (interim 2014)
26-01-2015 11:45 | Gyorgy Rethy | Fixed in Version | v4.5.2 (interim 2014) => v4.6.1 (published 2015-06)

Notes

(0012136)
Jacob Wieland - Spirent
18-06-2014 20:19

Actually, I don't think there is a conflict with an imported module name as such name-clash can always be resolved by adding the local module name to the local definition. Then, using the unqualified clashing name always must mean the imported module. (The same issue exists in TTCN-3 core language and I am not aware of such a restriction there)

(0012137)
Tomas Urban
19-06-2014 07:58

I am afraid you are wrong. The core language specifications states (in 5.2.2): "The identifier of a module (its module name) or of an imported module belongs to the scope unit of the module and cannot be used as identifier for other definitions inside this module."
There's a good reason for that, see the example:
module M1 {
const integer x := 1;
}
module M2 {
import from M1 all;
type record R { integer x }
control {
const R M1 := { x:= 2 };
const integer y := M1.x; // imported constant or local definition?
}
}

(0012142)
Jacob Wieland - Spirent
19-06-2014 12:38

You are right. Still, as I have demonstrated, the restriction is unnecessary as the nameclash can be easily be resolved. The only difference to the normal nameclash-resolution wuld be that the local definition needs to be prefixed. Anyway, maybe food for a different CR. As it is, it makes sense (and avoids nameclashes) to number the local definitions if a module with clashing name is imported.

(0012417)
Gyorgy Rethy
05-11-2014 10:02

Solution to postfix clashing type names has been added to clause 5.2.2 k) in CR 6735 to the interim version V4.5.2.