Reference documents:
Problem statement:
- Unique (ref. metadata) attribute values per DSD respond to a business need
- Also dataflow-level (ref. metadata) attribute (values) (especially those with empty keys (“
..~”)) respond to a business need
- But attaching (ref. metadata) attribute (values) to a dataflow (as currently defined in the DSD) creates conflicts
3 alternative solutions proposed:
- Full context preservation - approach
- All 3, DF, DSD and PA-specific (ref. metadata) attribute values are allowed for any attachment (full, partial, empty key)
- The current “DF-level” attribute attachment becomes “dimension-independent”
- Partial context preservation - approach - Due to inconsistencies, this solutions was discarded by the TWG (Jan 2026 meeting)
- All 3, DF, DSD and PA-specific (ref. metadata) attribute values are allowed for attachments without dimensions, e.g., “
..~”, thus all partial and full attachments remain unique per DSD
- The current “DF-level” attribute attachment becomes “dimension-independent”
- Only unique values per DSD - approach
- Only DSD-specific (ref. metadata) attribute values are allowed whatever the attachment (full, partial or empty, e.g., “
..~”), the corresponding values are unique per DSD
- The current “DF-level” attribute attachment is promoted to DSD-level
- DF-level (ref. metadata) attributes (defined with DSD/MSD) are not supported
- DF-specific ref. metadata can be provided through MSD/MDF/Report
There might be contradicting needs thus separate mechanisms might be necessary for context-specific values and for simple views on sub-cubes.
Reference documents:
Problem statement:
..~”)) respond to a business need3 alternative solutions proposed:
..~”, thus all partial and full attachments remain unique per DSD..~”), the corresponding values are unique per DSDThere might be contradicting needs thus separate mechanisms might be necessary for context-specific values and for simple views on sub-cubes.