Skip to Content
Last modified by Artur on 2025/09/13 19:50
From version 1.6
edited by Helena
on 2025/07/01 17:54
Change comment: There is no comment for this version
To version 1.5
edited by Helena
on 2025/07/01 17:54
Change comment: There is no comment for this version

Summary

Details

Page properties
Content
... ... @@ -49,6 +49,7 @@
49 49  The Data Constraint was simplified to become a cohesive structural artefact focussed solely on the restriction of values that can be reported. As part of this remodelling the Advanced Release Calendar was removed as it does not play a restrictive role.
50 50  
51 51  //Guidance for Implementors//
52 +
52 52  Reference Metadata reported against a Dataflow and / or Provision Agreement can be used as an alternative to the Advanced Release Calendar.
53 53  
54 54  == 2.2 Removal of Version on Categorisation ==
... ... @@ -55,7 +55,8 @@
55 55  
56 56  The Categorisation structural artefact has no use case for undergoing version changes, the version was therefore removed.
57 57  
58 -//Guidance for Implementors//
59 +Guidance for Implementors
60 +
59 59  If multiple versions of a Categorisation exist where the source or target differs, these Categorisations should be given a unique ID.
60 60  
61 61  = 3. Information Model =
... ... @@ -73,11 +73,11 @@
73 73  
74 74  The following changes to the model have been made to satisfy this use case.
75 75  
76 -**Data Structure Definition**
78 +Data Structure Definition
77 77  
78 78  The Data Structure Definition has a new ‘evolving structure’ property, this is a Boolean property, when set to ‘true’ it indicates to the users of the DSD that new Dimensions may be added without the DSD undergoing a change to its major version number.
79 79  
80 -**Dataflow**
82 +Dataflow
81 81  
82 82  The Dataflow has a new Dimension Constraint property, which is used to reference a subset of Dimensions which it uses from the referenced DSD.
83 83  
... ... @@ -89,12 +89,12 @@
89 89  
90 90  The Constraint model in SDMX 3.1 has been made more cohesive by separating the Data Constraint into two distinct structures; the Data Constraint which describes reporting restrictions, and the Availability Constraint, which describes data content from a data source. In SDMX 3.0 these distinctions were made using the ‘type’ property on a Data Constraint.
91 91  
92 -**Data Constraint**
94 +Data Constraint
93 93  
94 94  The Data Constraint has had the ‘type’ property removed; the Data Constraint in SDMX 3.1 is always used to describe restrictions on content for data reporting purposes.
95 95  
96 96  The attachment of the Data Constraint in SDMX 3.0 included Data Sources, in SDMX 3.1 these attachments have been removed as these are not relevant for restricting reported data.
97 97  
98 -**Availability Constraint**
100 +Availability Constraint
99 99  
100 100  The Availability Constraint is a new Structure introduced to describe data that exists, it is generated in the response to the Availability REST API. It is not a maintained structure, and as such has no maintenance agency, identity or version