ABS.Stat SDMX web service


This service gives access to .Stat data and tries to be fully SDMX 2.0 compliant. However, the following additional rules are applied:

(1) .Stat provides currently only annual, bi-annual, quarterly, monthly and non-time-series data.
Independently from the presence of a FREQUENCY dimension, the requested time frequency should be specified using the TIME_FORMAT attribute as in this example:

<And>
  <Attribute name="TIME_FORMAT">P1M</Attribute>
  <Time>
    <StartTime>1960-01</StartTime>
    <EndTime>2005-10</EndTime>
  </Time>
</And>

The TIME_FORMAT attribute should have the following value: 'P1Y' for annual, 'P6M' for bi-annual, 'P3M' for quarterly and 'P1M' for monthly data. This attribute is then also present in the resulting generic data message at the Series level of time-series data.
For non-time-series data, the TIME_PERIOD attribute and the 'Time' node should be omitted in the query message. In this case, the response messages use '9999' for the obligatory time periods.

(2) In the .Stat data warehouse each dataset (multidimensional cube) has its own Data Structure Definition.

(3) Structure your query by defining separate data 'cubes'. Each data cube must have a 'DataSet' node. This 'DataSet' node must be a direct child of one separate 'And' clause which must include all necessary dimension codes at any lower (child) level, and which itself must be a direct child of either of the clauses 'DataWhere' or 'Or'.

(4) For simplification reasons in this web service, the returned message headers only contain required information. As the 'message:ID' field is not (yet) used, its content is filled with a placeholder to conform to the standard.

(5) Our new SDMX web service version implements Streaming, and can therefore not set the 'Truncated' element in the response message. We are thus unable to take the 'defaultLimit' attribute in the Query message into account. To avoid errors, either implement streaming also at your (client) side to allow for greater-sized results or restrict the selection in the query message according to your limitation. In any case, please don't use the 'defaultLimit' attribute in the Query message.

The following operations are supported. For a formal definition, please review the Service Description.