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

ID | Project | Category | View Status | Date Submitted | Last Update
0006735 | Part 09: Using XML with TTCN-3 | Clarification | public | 21-04-2014 11:00 | 26-01-2015 11:22

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.5.2 (interim 2014) |
Clause Reference(s) | 5.2.2
For STF discussion |
Source (company - Author) | STF 475

Summary | 0006735: Missing rules for transforming XSD namespaces into TTCN-3 module names

Description

The section 5.1.1 containing the rules for transformation of XSD namespaces into TTCN-3 module names refers to the chapter 5.2.2: The names of the TTCN 3 modules generated based on this clause shall be the result of applying the name transformation rules in clause 5.2.2 to the related target namespace.
The section 5.2.2 provides good guidelines for transforming the module name so that it contains characters allowed in TTCN-3, but there are no rules for handling name clashes. In particular, there should be a dedicated rule saying what happens if transformation of several distinct namespace into TTCN-3 module yields the same result or results into a TTCN-3 keyword or a name of a predefined function (similar to the rules j, k and l for types, field names and enumerated items).
It is also not known what rule for X-prefixing should be applied. Is the X character capitalized as for types (rules f, h) or uncapitalized as for field names(rules g, i)?
In addition to that, the section 5.2.3 should contain rules for ordering namespaces before transformation takes place. These rules should take into account existence of the predefined "NoTargetNamespace" module for items without namespace so that it is known which namespace takes precedence during tranformation in the unlikely case when there's another namespace that transforms to "NoTargetNamespace" as well.

Steps To Reproduce |
Additional Information |
Tags | No tags attached.

Relationships

related to | 0006777 | closed | Axel Rennoch | Normalization of target namespace values to be clarified
related to | 0006734 | closed | Gyorgy Rethy | Extension of the rule on same type identifiers

Attached Files

CR6735_resolution_v1.doc (114,176) 16-06-2014 17:31
http://oldforge.etsi.org/mantis/file_download.php?file_id=3034&type=bug
CR6735_resolution_v2.doc (114,688) 17-06-2014 09:21
http://oldforge.etsi.org/mantis/file_download.php?file_id=3036&type=bug
CR6735_resolution_v3.doc (114,688) 19-06-2014 16:39
http://oldforge.etsi.org/mantis/file_download.php?file_id=3061&type=bug
CR6735_resolution_v4.doc (115,200) 20-06-2014 08:51
http://oldforge.etsi.org/mantis/file_download.php?file_id=3067&type=bug

Issue History
Date Modified | Username | Field | Change
21-04-2014 11:00 | Tomas Urban | New Issue |
22-04-2014 08:32 | Jacob Wieland - Spirent | Note Added: 0012043 |
15-06-2014 17:47 | Gyorgy Rethy | Assigned To | => Gyorgy Rethy
15-06-2014 17:47 | Gyorgy Rethy | Status | new => assigned
15-06-2014 18:03 | Gyorgy Rethy | Target Version | => v4.6.1 (published 2015-06)
16-06-2014 16:18 | Gyorgy Rethy | Note Added: 0012091 |
16-06-2014 17:06 | Gyorgy Rethy | Note Edited: 0012091 | bug_revision_view_page.php?bugnote_id=12091#r23
16-06-2014 17:06 | Gyorgy Rethy | Note Edited: 0012091 | bug_revision_view_page.php?bugnote_id=12091#r24
16-06-2014 17:31 | Gyorgy Rethy | Relationship added | related to 0006777
16-06-2014 17:31 | Gyorgy Rethy | File Added: CR6735_resolution_v1.doc |
16-06-2014 17:32 | Gyorgy Rethy | Note Edited: 0012091 | bug_revision_view_page.php?bugnote_id=12091#r25
16-06-2014 17:33 | Gyorgy Rethy | Assigned To | Gyorgy Rethy => Tomas Urban
16-06-2014 17:33 | Gyorgy Rethy | Status | assigned => confirmed
16-06-2014 17:33 | Gyorgy Rethy | Resolution | open => fixed
17-06-2014 07:16 | Jacob Wieland - Spirent | Note Added: 0012093 |
17-06-2014 09:21 | Gyorgy Rethy | File Added: CR6735_resolution_v2.doc |
17-06-2014 09:27 | Gyorgy Rethy | Note Added: 0012098 |
17-06-2014 12:17 | Jacob Wieland - Spirent | Note Added: 0012102 |
17-06-2014 13:17 | Tomas Urban | Relationship added | related to 0006734
17-06-2014 13:24 | Tomas Urban | Note Added: 0012103 |
17-06-2014 13:24 | Tomas Urban | Assigned To | Tomas Urban => Gyorgy Rethy
19-06-2014 16:18 | Gyorgy Rethy | Note Added: 0012154 |
19-06-2014 16:19 | Gyorgy Rethy | Note Edited: 0012154 | bug_revision_view_page.php?rev_id=50
19-06-2014 16:20 | Gyorgy Rethy | Note Edited: 0012154 | bug_revision_view_page.php?rev_id=51
19-06-2014 16:21 | Gyorgy Rethy | Note Edited: 0012154 | bug_revision_view_page.php?rev_id=52
19-06-2014 16:25 | Gyorgy Rethy | Note Deleted: 0012154 |
19-06-2014 16:38 | Gyorgy Rethy | Note Added: 0012156 |
19-06-2014 16:38 | Gyorgy Rethy | Note Edited: 0012156 | bug_revision_view_page.php?bugnote_id=12156#r54
19-06-2014 16:39 | Gyorgy Rethy | File Added: CR6735_resolution_v3.doc |
19-06-2014 16:41 | Gyorgy Rethy | Note Edited: 0012156 | bug_revision_view_page.php?bugnote_id=12156#r55
19-06-2014 16:41 | Gyorgy Rethy | Assigned To | Gyorgy Rethy => Tomas Urban
19-06-2014 16:41 | Gyorgy Rethy | Status | confirmed => assigned
20-06-2014 07:49 | Tomas Urban | Note Added: 0012166 |
20-06-2014 07:49 | Tomas Urban | Status | assigned => resolved
20-06-2014 07:49 | Tomas Urban | Assigned To | Tomas Urban => Gyorgy Rethy
20-06-2014 08:02 | Jacob Wieland - Spirent | Note Added: 0012167 |
20-06-2014 08:02 | Jacob Wieland - Spirent | Status | resolved => feedback
20-06-2014 08:02 | Jacob Wieland - Spirent | Resolution | fixed => reopened
20-06-2014 08:02 | Jacob Wieland - Spirent | Status | feedback => assigned
20-06-2014 08:51 | Tomas Urban | File Added: CR6735_resolution_v4.doc |
20-06-2014 08:53 | Tomas Urban | Note Added: 0012172 |
20-06-2014 08:53 | Tomas Urban | Status | assigned => confirmed
24-06-2014 09:49 | Gyorgy Rethy | Note Edited: 0012156 | bug_revision_view_page.php?bugnote_id=12156#r63
24-06-2014 09:54 | Gyorgy Rethy | Note Added: 0012196 |
24-06-2014 09:54 | Gyorgy Rethy | Status | confirmed => closed
24-06-2014 09:54 | Gyorgy Rethy | Resolution | reopened => fixed
24-06-2014 09:54 | Gyorgy Rethy | Fixed in Version | => 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:22 | Gyorgy Rethy | Fixed in Version | v4.6.1 (published 2015-06) => v4.5.2 (interim 2014)

Notes

(0012043)
Jacob Wieland - Spirent
22-04-2014 08:32

I think first the namespaces should be ordered alphabetically/lexicographically where the non-existent namespace (yielding NoTargetNamespace) should be the smallest item for comparison, even smaller than the empty string (which would yield namespace X or x, in my opinion, it should be capitalized).
Then, after applying the mapping-rules, if nameclashes occur, it is clear which namespace gets which number, dependent on the above ordering.
In my opinion, no two modules can have the NoTargetNamespace as all schemas without namespace are all collected in the NoTargetNamespace module (they all have the same namespace, i.e. none). Using the no-namespace as smallest element in the ordering ensures that all actual namespaces which yield NoTargetNamespace will be numbered. That way, NoTargetNamespace is unambiguously the module for all definitions without a namespace.

(0012091)
Gyorgy Rethy
16-06-2014 16:18 (edited on: 16-06-2014 17:32)

See proposed resolution in CR6735_resolution_v1.doc.
Rule to order target namespace values before converting them to TTCN-3 is added to 5.2.2 a). New rule m) is added to postfix clashing module names.
A rule to use the target namespace values *before* converting them to TTCN-3 module names is added to clause 5.2.3.
Clause 2.2. of "Namespaces in XML 1.0 (Second Edition)" disallows empty character string as XML namespace, hence no additional rule is needed for this case (no X substitution).
Correct, no two modules can have the name NoTargetNamespace, as XSD documents without a namespace are collected into it and "NoTargetNamespace" is not a valid namespace value.

(0012093)
Jacob Wieland - Spirent
17-06-2014 07:16

Why the exception in 5.2.2 e) for namespaces, since there is already a way to resolve the nameclashes, what is that exception good for?
http://www.example.org/ [^] and http://www.example.org/Ü/ [^] would still result in the same (base)namespace because of the underscore-collapsing-rule and this would lead to double-underscores when appending the suffix.
Why not keep the same rules as for other names?

(0012098)
Gyorgy Rethy
17-06-2014 09:27

See CR6735_resolution_v2.doc.
We have discussed this with Tomas, it would be better to leave the trailing _ in module names, but not to add another one when postfixing the module name. The reason is that the kind of
http://www.example.org [^] vs. http://www.example.org/ [^] case is more frequent than http://www.example.org/ [^] vs. http://www.example.org/Ü/. [^]
It would be better if in the first case users could see the difference also in the generated module names.
I have also added that module names shall also be prefixed, when it is clashing with a definition name in the same module.

(0012102)
Jacob Wieland - Spirent
17-06-2014 12:17

The module names being generated should be independent of the contents of the modules, as they should be the same as seen from all modules. Basically, first all module names shall be generated and then the names of the contents of the module. So, the name of a definition inside a target-namespace should never have any influence on the name of a module. Only the set of namespaces should be the deciding factor.

(0012103)
Tomas Urban
17-06-2014 13:24

I agree with Jacob. The resolution of name clashes should go from top to bottom, not vice versa. The proposed solution doesn't take into account the use of module identifiers in import clauses too. When adding import dependencies, the amount of definitions to check for name clashes would significantly grow and make the procedure inefficient. See also the related issue 0006734.

(0012156)
Gyorgy Rethy
19-06-2014 16:38 (edited on: 24-06-2014 09:49)

OK. Taking into account the probability of such a name clash, I think it is a low-probability case, but for this reason it can be either ways. I have changed it that the module names are generated first and the definition names are postfixed (or postfix is shifted) in case of name clash.
Rule m) in ~_v2 become rule j) and rule k) (old j)) is extended with module names. No other change in the document!
Pls. review CR6735_resolution_v3.doc.

(0012166)
Tomas Urban
20-06-2014 07:49

I found no problems in the last draft. The proposal resolves the described issue and it is ready to be included in the next version of standard.

(0012167)
Jacob Wieland - Spirent
20-06-2014 08:02

Sorry, I have to slightly disagree with Tomas.
In rule k) the sub-sentence
"is identical to the name of the TTCN-3 module the definitions is being placed to" is neither grammatically correct nor does it describe what we intend.
As I understoot it, it should be more on the line of
"is identitcal to the name of the TTCN-3 module generated for its target namespace or one of the modules imported into that module"

(0012172)
Tomas Urban
20-06-2014 08:53

I modified the mentioned sub-sentence: the original sentence was made gramatically correct and a clause on imported modules was added as well.

(0012196)
Gyorgy Rethy
24-06-2014 09:54

Implemented in master copy V4.5.2.