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

ID | Project | Category | View Status | Date Submitted | Last Update
0005978 | Part 09: Using XML with TTCN-3 | Clarification | public | 01-12-2011 09:53 | 01-12-2011 16:35

Reporter | Tomas Urban |
Assigned To | Gyorgy Rethy |
Priority | normal | Severity | minor | Reproducibility | always
Status | closed | Resolution | fixed |
Platform |  | OS |  | OS Version |
Product Version | v4.3.1 (published 2011-06) |
Target Version | v4.4.1 (published 2012-04) | Fixed in Version | v4.4.1 (published 2012-04) |
Clause Reference(s) | 7.7.2
For STF discussion |
Source (company - Author) | Elvior

Summary | 0005978: Position of attr in enframing record

Description

The chapter 7.7 (7.7.2 in the 4.3.2 draft) doesn't contain any direct instruction on the position of the attr field (i.e. the result of anyAttribute transformation) in the enframing record. There's only a note that anyAttribute should be processed in the same way as other attributes, so I assume the rules specified in the clause 7.6.7 should be applied (even though there's no reference to 7.6.7 in the anyAttribute transformation rules).
If this is correct, I have several questions:
1. Does it mean that the attr field should be a part of the sorting procedure? E.g. if there's an attribute called 'bar', would the attr field precede it in the enframing record?
2. If the sorting procedure is indeed invoked, what is the namespace related to the attr field? How are wildcards (such as #local, #other etc.) interpreted?
I would prefer if the specification contained a precise definition of the position of the attr field in the enframing record, e.g.: The attr field is inserted to the enframing record together with other attributes according to the rules specified in the clause 7.6.7. For the purposes of the ordering procedure, it is assumed that the attr field has no target namespace.
It would be very nice to include an example of a sequence that contains several attributes and elements and anyAttribute field in the specification to provide a comprehensive guidence on this issue.

Steps To Reproduce |
Additional Information |
Tags | No tags attached.
Relationships |
Attached Files | CR5978.doc (93,696) 01-12-2011 16:09 http://oldforge.etsi.org/mantis/file_download.php?file_id=2649&type=bug

Issue History
Date Modified | Username | Field | Change
01-12-2011 09:53 | Tomas Urban | New Issue |
01-12-2011 09:53 | Tomas Urban | Clause Reference(s) | => 7.7.2
01-12-2011 09:53 | Tomas Urban | Source (company - Author) | => Elvior
01-12-2011 10:46 | Jacob Wieland - Spirent | Note Added: 0010464 |
01-12-2011 10:57 | Tomas Urban | Note Added: 0010465 |
01-12-2011 11:27 | Jacob Wieland - Spirent | Note Added: 0010468 |
01-12-2011 14:31 | Gyorgy Rethy | Assigned To | => Gyorgy Rethy
01-12-2011 14:31 | Gyorgy Rethy | Status | new => assigned
01-12-2011 14:31 | Gyorgy Rethy | Target Version | => Edition 4.4.1
01-12-2011 16:09 | Jacob Wieland - Spirent | File Added: CR5978.doc |
01-12-2011 16:10 | Jacob Wieland - Spirent | Note Added: 0010491 |
01-12-2011 16:35 | Gyorgy Rethy | Note Added: 0010494 |
01-12-2011 16:35 | Gyorgy Rethy | Reproducibility | N/A => always
01-12-2011 16:35 | Gyorgy Rethy | Status | assigned => closed
01-12-2011 16:35 | Gyorgy Rethy | Resolution | open => fixed
01-12-2011 16:35 | Gyorgy Rethy | Fixed in Version | => Edition 4.4.1

Notes

(0010464)
Jacob Wieland - Spirent
01-12-2011 10:46

I think the standard is clear that the "attr" field should be treated like any other attribute field from the ordering perspective.
Unfortunately I agree on the part of the namespace of the anyAttribute which shall be considered during ordering.
Shall the namespace be considered NoTargetNamespace (which I would favour) or should it be the namespace of the type introducing the anyAttribute.
If the latter is the case then the question arises which target namespace is correct if multiple anyAttribute declarations exist in the same type due to type derivation: shall the namespace of the uppermost base type introducing the anyAttribute be the targetnamespace or shall the namespace of the last derivation introducing anyAttributes be the targetnamespace.
To keep it as simple as possible I would opt for the NoTargetNamespace option which would normally lead to the "attr" field being the first of the attribute fields (unless a schema without target namespace is part of the schema space which should be rare).

(0010465)
Tomas Urban
01-12-2011 10:57

OK, I agree that the standard is quite clear regarding the participation in the sorting procedure, but for better comprehensibility, it would be nice to add an explicit reference to the clause 7.6.7, i.e. to change the following sentence:
The anyAttribute element shall be translated, like other attributes, to a field ... (see clauses 7.6, 7.6.5 and 7.6.6).
-->
The anyAttribute element shall be translated, like other attributes, to a field ... (see clause 7.6.7).

(0010468)
Jacob Wieland - Spirent
01-12-2011 11:27

Comparing the mapping with the XSD-to-ASN.1 mapping, it appears that there the component generated for the anyAttributes are added to the record AFTER all components for the (sorted) named attributes have been added to it. So, the attr-field would always appear as the first field after all the other attribute fields.
If we want to stay in sync with that mapping, we should specify it the same way in the XSD-to-TTCN-3 mapping. I think this would be another viable option and since the standard is not clear on that until now, backward compatibility issues will occur with any solution anyhow.

(0010491)
Jacob Wieland - Spirent
01-12-2011 16:10

implemented as in XSD to ASN.1 mapping: position after other attributes (if any). Amended an example to that effect.

(0010494)
Gyorgy Rethy
01-12-2011 16:35

Implemented according to Jacob's draft.