Data Cube CR Exit Criteria

Exit Criteria

The working group intends to submit this document for consideration as a W3C Proposed Recommendation after having met the following criteria:

• Two independently developed data sources have been demonstrated which comprise either well-formed abbreviated Data Cubes or well-formed Data Cubes which pass all retained integrity checks.

The notion of retention is described below.

The majority of vocabulary terms are needed in order to represent a well-formed Data Cube. The working group will track and analyse usage of other substantive but optional terms and include this analysis in the implementation report when requesting transition to Proposed Recommendation. These terms are defined below.

At Risk features

Two aspects of the specification were marked At Risk at Last Call and remain At Risk for the CR period.

The normalization algorithm is at risk. If implementation experience reveals a problem with the normalization algorithm but the CR exit criteria are met by two independent implementations demonstrating well-formed (non-abbreviated) Data Cubes then the specification MAY proceed with the at risk algorithm removed.

The specific set of integrity checks is at risk. The implementation experience may reveal technical errors in one or more rules, or may indicate that one or more of the constraints is too onerous. We anticipate that if such a problem is revealed then one option would be to remove the flawed at risk rule, retaining the rest of the rules. If that situation arises the Working Group will consider whether to recommend:

• that the specification should proceed retaining just the subset of at risk rules which have been validated by the implementation phase;
• or, that a specification revision cycle is required.

This decision will be based on the number of rules which prove problematic and whether the issue is with the technical implementation or the intent of the rules. If too few rules are retained then the robustness of the CR exit criteria would be in doubt. If an isolated rule is deemed inappropriate, and its loss would not impact interoperability, then the Working Group could reasonably recommend proceeding on the basis of the retained subset of rules.

Substantive but optional terms

For the purposes of implementation tracking then terms in the vocabulary can be divided into three categories:

• core terms which are used in any typical well-formed cube,
• optional terms which provide for extension points or optional features of cubes,
• internal terms which are part of the scaffolding of the vocabulary design.

The exit criteria directly cover core and internal terms (the latter because the scaffolding is used within the vocabulary itself and the integrity checks).

The optional terms need not appear in all well-formed cubes, though when they do their correct usage is covered by the integrity checks. The working group will track usage of these optional terms in building the case for transition to Proposed Recommendation.

The terms in each category are listed below.

Optional

• qb:ObservationGroup, qb:observationGroup
• qb:concept
• qb:measureDimension
• qb:measureType
• qb:componentRequired
• qb:order
• qb:HierarchicalCodeList, qb:parentChildProperty, qb:hierarchyRoot

Core

• qb:AttributeProperty
• qb:CodedProperty
• qb:ComponentProperty
• qb:DataSet
• qb:DataStructureDefinition
• qb:DimensionProperty
• qb:Observation
• qb:MeasureProperty
• qb:attribute
• qb:codeList
• qb:dimension
• qb:dataSet
• qb:measure
• qb:observation
• qb:structure

The follow terms are using in any well-formed cube that uses slices. Since a large number of known existing implementations do use slices separate tracking of these terms is not required.

• qb:Slice
• qb:SliceKey
• qb:slice
• qb:sliceKey
• qb:sliceStructure

Internal

• qb:Attachable
• qb:ComponentSet
• qb:ComponentSpecification
• qb:component
• qb:componentAttachment
• qb:componentProperty