Skip to Content
Last modified by Helena on 2025/09/10 11:19
From version 29.2
edited by Helena
on 2025/05/16 14:06
Change comment: There is no comment for this version
To version 23.1
edited by Helena
on 2025/05/15 14:34
Change comment: There is no comment for this version

Summary

Details

Page properties
Content
... ... @@ -183,11 +183,11 @@
183 183  
184 184  === {{id name="_Toc93847"/}}5.2.2 Structure Submission Service ===
185 185  
186 -The registry must support a mechanism for submitting structural metadata. This mechanism can be the SDMX REST interface for structural metadata (this is defined in the corresponding GitHub project, dedicated to the SDMX REST API: [[__https:~~/~~/github.com/sdmx-twg/sdmx-rest__>>https://https:github.comsdmx-twgsdmx-rest]]). In order for the architecture to be scalable, the finest-grained piece of structural metadata that can be processed by the SDMX-RR is a MaintainableArtefact, with the exception of Item Schemes, where changes at an Item level is also possible (see next section on the SDMX Information Model).
186 +The registry must support a mechanism for submitting structural metadata. This mechanism can be the SDMX REST interface for structural metadata (this is defined in the corresponding GitHub project, dedicated to the SDMX REST API: __[[https:~~/~~/github.com/sdmx>>url:https://github.com/sdmx-twg/sdmx-rest]][[->>url:https://github.com/sdmx-twg/sdmx-rest]][[twg/sdmx>>url:https://github.com/sdmx-twg/sdmx-rest]][[->>url:https://github.com/sdmx-twg/sdmx-rest]][[rest>>url:https://github.com/sdmx-twg/sdmx-rest]]__[[)>>url:https://github.com/sdmx-twg/sdmx-rest]]. In order for the architecture to be scalable, the finest-grained piece of structural metadata that can be processed by the SDMX-RR is a MaintainableArtefact, with the exception of Item Schemes, where changes at an Item level is also possible (see next section on the SDMX Information Model).
187 187  
188 188  === {{id name="_Toc93848"/}}5.2.3 Structure Query Service ===
189 189  
190 -The registry must support a mechanism for querying for structural metadata. This mechanism can be the SDMX REST interface for structural metadata (this is defined in the corresponding GitHub project, dedicated to the SDMX REST API: [[__https:~~/~~/github.com/sdmx-twg/sdmx-rest__>>https://https:github.comsdmx-twgsdmx-rest]]). The registry response to this query mechanism is the SDMX Structure message, which has as its root node:
190 +The registry must support a mechanism for querying for structural metadata. This mechanism can be the SDMX REST interface for structural metadata (this is defined in the corresponding GitHub project, dedicated to the SDMX REST API: __[[https:~~/~~/github.com/sdmx>>url:https://github.com/sdmx-twg/sdmx-rest]][[->>url:https://github.com/sdmx-twg/sdmx-rest]][[twg/sdmx>>url:https://github.com/sdmx-twg/sdmx-rest]][[->>url:https://github.com/sdmx-twg/sdmx-rest]][[rest>>url:https://github.com/sdmx-twg/sdmx-rest]]__ [[)>>url:https://github.com/sdmx-twg/sdmx-rest]]. The registry response to this query mechanism is the SDMX Structure message, which has as its root node:
191 191  
192 192  * Structure
193 193  
... ... @@ -280,7 +280,7 @@
280 280  Subscription management involves a user submitting a subscription request which contains:
281 281  
282 282  * a query or constraint expression in terms of a filter which defines the events for which the user is interested (e.g., new data for a specific dataflow, or for a domain category, or changes to a Data Structure Definition).
283 -* a list of URIs or endpoints to which an XML notification message can be sent. Supported endpoint types will be email (mailto~: ) and HTTP POST (a normal http:~/~/ address);
283 +* a list of URIs or endpoints to which an XML notification message can be sent. Supported endpoint types will be email (mailto~:) and HTTP POST (a normal http:~/~/ address);
284 284  * request for a list of submitted subscriptions;
285 285  * deletion of a subscription;
286 286  
... ... @@ -304,6 +304,7 @@
304 304  |(% style="width:188px" %)**Interface**|(% style="width:542px" %)**Behaviour**
305 305  |(% style="width:188px" %) |(% style="width:542px" %)(((
306 306  b) Not be explicitly{{footnote}}With semantic versioning, it is allowed to reference a range of artefacts, e.g., a DSD referencing a Codelist with version 1.2.3+ means all patch versions greater than 1.2.3. This means that deleting 1.2.4-draft does not break integrity of the aforementioned DSD.{{/footnote}} referenced from any other object in the Registry.
307 +
307 307  4) The semantic versioning rules in the SDMX documentation MUST be obeyed.
308 308  )))
309 309  |(% style="width:188px" %)Structure submission|(% style="width:542px" %)Structures are submitted at the level of the Maintainable Artefact and the behaviour in “All” above is therefore at the level of the Maintainable Artefact.
... ... @@ -740,7 +740,7 @@
740 740  
741 741  === {{id name="_Toc93862"/}}7.1 Structural Definition Metadata ===
742 742  
743 -=== {{id name="_Toc93863"/}}7.1.1 Introduction ===
744 +===== {{id name="_Toc93863"/}}7.1.1 Introduction =====
744 744  
745 745  The SDMX Registry must have the ability to support agencies in their role of defining and disseminating structural metadata artefacts. These artefacts include data structure definitions, code lists, concepts etc. and are fully defined in the SDMX-IM. An authenticated agency may submit valid structural metadata definitions which must be stored in the registry. Note that the term “structural metadata” refers as a general term to all structural components (Data Structure Definitions, Metadata Structure Definitions, Code Lists, Concept Schemes, etc.)
746 746  
... ... @@ -807,7 +807,7 @@
807 807  
808 808  **Table 4: Table of Maintainable Artefacts for Structural Definition Metadata**
809 809  
810 -=== {{id name="_Toc93864"/}}7.1.2 Item Scheme, Structure ===
811 +===== {{id name="_Toc93864"/}}7.1.2 Item Scheme, Structure =====
811 811  
812 812  The artefacts included in the structural definitions are:
813 813  
... ... @@ -816,19 +816,19 @@
816 816  * All types of Structure (Data Structure Definition, Metadata Structure Definition)
817 817  * All types of Structure Usage (Dataflow, Metadataflow)
818 818  
819 -=== {{id name="_Toc93865"/}}7.1.3 Structure Usage ===
820 +===== {{id name="_Toc93865"/}}7.1.3 Structure Usage =====
820 820  
821 -==== 7.1.3.1 Structure Usage: Basic Concepts ====
822 +**7.1.3.1 Structure Usage: Basic Concepts**
822 822  
823 823  The Structure Usage defines, in its concrete classes of Dataflow and Metadataflow, which flows of data and metadata use which specific Structure, and importantly for the support of data and metadata discovery, the Structure Usage can be linked to one or more Category in one or more Category Scheme using the Categorisation mechanism. This gives the ability for an application to discover data and metadata by “drilling down” the Category Schemes.
824 824  
825 -==== 7.1.3.2 Structure Usage Schematic ====
826 +**7.1.3.2 Structure Usage Schematic**
826 826  
827 827  [[image:SDMX 3-0-0 SECTION 5 FINAL-1.0_en_52097ab5.jpg||height="246" width="438"]]
828 828  
829 829  **Figure 9: Schematic of Linking the Data and Metadata Flows to Categories and Structure Definitions**
830 830  
831 -==== 7.1.3.3 Structure Usage Model ====
832 +**7.1.3.3 Structure Usage Model**
832 832  
833 833  [[image:SDMX 3-0-0 SECTION 5 FINAL-1.0_en_302cc1a2.jpg||height="548" width="578"]]
834 834  
SUZ.Methodology.Code.MethodologyClass[0]