Logo etsi

ETSI's Bug Tracker
Main | My View | View Issues | Change Log | Roadmap | Monitor project
  
Notice: information submitted on the ETSI issue Tracker may be incorporated in ETSI publication(s) and therefore subject to the ETSI IPR policy.

View Issue Details [ Jump to Notes ] [ Issue History ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0005978Part 09: Using XML with TTCN-3Clarificationpublic01-12-2011 09:5301-12-2011 16:35
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.3.1 (published 2011-06) 
Target Versionv4.4.1 (published 2012-04)Fixed in Versionv4.4.1 (published 2012-04) 
Summary0005978: Position of attr in enframing record
DescriptionThe 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.
TagsNo tags attached.
Clause Reference(s)7.7.2
For STF discussion
Source (company - Author)Elvior
Attached Filesdoc file icon CR5978.doc [^] (93,696 bytes) 01-12-2011 16:09

- Relationships

-  Notes
(0010464)
Jacob Wieland - Spirent (reporter)
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 (developer)
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 (reporter)
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 (reporter)
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 (reporter)
01-12-2011 16:35

 Implemented according to Jacob's draft.

- 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

MantisBT 1.2.14 [^]
Copyright © 2000 - 2024 MantisBT Team
Powered by Mantis Bugtracker