View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
000351310000-006: MappingsSpecpublic2016-08-19 07:122016-12-14 18:01
ReporterBjarneBostrom Assigned Torandyarmstrong  
PrioritynormalSeverityminorReproducibilityhave not tried
Status closedResolutionfixed 
Summary0003513: Clarify the place of EncodingMask when Optional Structure is part of an inheritance chain
Description

Spec Part 6 (ver 1.03) section 5.2.6 needs in my opinion a bit clarifying that where the EncodingMask should be placed if

  1. An optional Structure is subtype of non-optional Structure (i.e. since normally the fields of the supertype are first, however based on experimentation with latest uamodeler the EncodingMask is always the first field)

  2. Should there be a single EncodingMask at the begining of the encoding when an Optional Structure is a subtype of an optional Structure or an EncodingMask for the supertype and one for the subtype (after supertype fields). Experimentations with uamodeler gives that there is always only one EncodingMask at the begining of the encoding.

It does state "Structures with optional fields are encoded with an encoding mask and as a sequence of fields in the order that they appear in the definition.", but e.g. "The EncodingMask shall be always first even before supertype fields" or equivalent would make it clear.

TagsNo tags attached.
Commit Version
Fix Due Date

Activities

randyarmstrong

2016-12-04 23:26

administrator   ~0007410

Added this text to 1.04 DRAFT 09:

If a Structure with optional fields is subtyped it shall not add any new optional fields. If optional fields are required then the optional fields should be nested by creating a mandatory field with a new Structure that defines the optional fields needed for the subtype.

I could not think of a way to allow this without creating a mess by either creating non-intuitive dependencies on the parent type or adding complexity with separate masks for every level in the tree (which causes a lot of problems for the XML encoding).

Matthias Damm

2016-12-10 22:19

developer   ~0007506

This topic may need clarification but I do not see such a general problem that we need to disallow creating subtypes of structures with optional fields.

There are companion specifications that make already heavily use of this feature. Therefore we cannot restrict something that is possible and already used.

randyarmstrong

2016-12-14 18:01

administrator   ~0007533

Resolved interactively during Dallas F2F.

EncodingMask is extended by subtypes and stated that explicitly.

Jim Luth

2016-12-14 18:01

administrator   ~0007534

agreed to changes in meeting.

Issue History

Date Modified Username Field Change
2016-08-19 07:12 BjarneBostrom New Issue
2016-08-30 15:38 Jim Luth Target Version => 1.04
2016-08-30 15:39 Jim Luth Assigned To => randyarmstrong
2016-08-30 15:39 Jim Luth Status new => assigned
2016-12-04 23:26 randyarmstrong Note Added: 0007410
2016-12-04 23:26 randyarmstrong Status assigned => resolved
2016-12-04 23:26 randyarmstrong Resolution open => fixed
2016-12-10 22:19 Matthias Damm Note Added: 0007506
2016-12-10 22:19 Matthias Damm Status resolved => feedback
2016-12-10 22:19 Matthias Damm Resolution fixed => reopened
2016-12-14 18:01 randyarmstrong Note Added: 0007533
2016-12-14 18:01 randyarmstrong Status feedback => resolved
2016-12-14 18:01 randyarmstrong Resolution reopened => fixed
2016-12-14 18:01 Jim Luth Note Added: 0007534
2016-12-14 18:01 Jim Luth Status resolved => closed
2016-12-14 18:01 Jim Luth Fixed in Version => 1.04