Last modified by Artur on 2025/09/13 19:50
Summary
-
Page properties (1 modified, 0 added, 0 removed)
Details
- Page properties
-
- Content
-
... ... @@ -52,17 +52,15 @@ 52 52 53 53 Reference Metadata reported against a Dataflow and / or Provision Agreement can be used as an alternative to the Advanced Release Calendar. 54 54 55 - 1.//2.2 Removal of Version on Categorisation//55 +== 2.2 Removal of Version on Categorisation == 56 56 57 57 The Categorisation structural artefact has no use case for undergoing version changes, the version was therefore removed. 58 58 59 +Guidance for Implementors 59 59 60 -//Guidance for Implementors// 61 - 62 62 If multiple versions of a Categorisation exist where the source or target differs, these Categorisations should be given a unique ID. 63 63 64 -1. 65 -11. Information Model 63 += 3. Information Model = 66 66 67 67 The changes to the information model support two distinct use cases: 68 68 ... ... @@ -71,23 +71,17 @@ 71 71 72 72 These changes are described in below. 73 73 74 - 1.//3.1 Horizontally Complex Data Structure Definitions//72 +== 3.1 Horizontally Complex Data Structure Definitions == 75 75 76 76 An explanation of this use case, with additional details can be found under Section 6 - Technical Notes, under heading ‘10.3 Dimension Constraint’. 77 77 78 78 The following changes to the model have been made to satisfy this use case. 79 79 80 -1. 81 -11. 82 -111. 83 -1111. Data Structure Definition 78 +Data Structure Definition 84 84 85 85 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. 86 86 87 -1. 88 -11. 89 -111. 90 -1111. Dataflow 82 +Dataflow 91 91 92 92 The Dataflow has a new Dimension Constraint property, which is used to reference a subset of Dimensions which it uses from the referenced DSD. 93 93 ... ... @@ -95,22 +95,16 @@ 95 95 96 96 The Dimension Constraint property is only required if the DSD sets the evolving structure property to true. 97 97 98 - 1.//3.2Constraint Cohesion//90 +== 3.2 Constraint Cohesion == 99 99 100 100 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. 101 101 102 -1. 103 -11. 104 -111. 105 -1111. Data Constraint 94 +Data Constraint 106 106 107 107 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. 108 108 109 109 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. 110 110 111 -1. 112 -11. 113 -111. 114 -1111. Availability Constraint 100 +Availability Constraint 115 115 116 116 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