Skip to Content
Last modified by Helena on 2025/09/10 11:19
From version 24.1
edited by Helena
on 2025/05/15 14:35
Change comment: There is no comment for this version
To version 29.3
edited by Helena
on 2025/05/16 14:09
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>>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).
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).
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>>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:
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:
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  
... ... @@ -301,10 +301,8 @@
301 301  
302 302  a) Be a draft version.
303 303  )))
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 -
308 308  4) The semantic versioning rules in the SDMX documentation MUST be obeyed.
309 309  )))
310 310  |(% 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.
... ... @@ -445,23 +445,14 @@
445 445  The packages are:
446 446  
447 447  base
448 -
449 449  codelist
450 -
451 451  conceptscheme
452 -
453 453  datastructure
454 -
455 455  categoryscheme
456 -
457 457  registry
458 -
459 459  metadatastructure
460 -
461 461  process
462 -
463 463  structuremapping
464 -
465 465  transformation
466 466  
467 467  **maintainable-object-id** is the identifier of the maintainable object. This will always be present as all identifiable objects are either a maintainable object or contained in a maintainable object.
... ... @@ -506,23 +506,23 @@
506 506  
507 507  The Data Structure Definition CRED_EXT_DEBT of legacy version 2.1 maintained by the toplevel Agency TFFS would have the URN:
508 508  
509 -urn:sdmx:org.sdmx.infomodel.datastructure.DataStucture=TFFS:CRED_EXT_ DEBT(2.1)
498 + urn:sdmx:org.sdmx.infomodel.datastructure.DataStucture=TFFS:CRED_EXT_ DEBT(2.1)
510 510  
511 511  The URN for a code for Argentina maintained by ISO in the code list CL_3166A2 of semantic version 1.0.0 would be:
512 512  
513 -urn:sdmx:org.sdmx.infomodel.codelist.Code=ISO:CL_3166A2(1.0.0).AR
502 + urn:sdmx:org.sdmx.infomodel.codelist.Code=ISO:CL_3166A2(1.0.0).AR
514 514  
515 515  The URN for a category (id of 1) which has parent category (id of 2) maintained by SDMX in the category scheme SUBJECT_MATTER_DOMAINS of the semantic extended version 1.0.0draft would be:
516 516  
517 -urn:sdmx:org.sdmx.infomodel.categoryscheme.Category=SDMX:SUBJECT_MATT ER_DOMAINS(1.0.0-draft).1.2
506 + urn:sdmx:org.sdmx.infomodel.categoryscheme.Category=SDMX:SUBJECT_MATT ER_DOMAINS(1.0.0-draft).1.2
518 518  
519 519  The URN for a Metadata Attribute maintained by SDMX in the MSD CONTACT_METADATA of semantic version 1.0.0 where the hierarchy of the Metadata Attribute is CONTACT_DETAILS/CONTACT_NAME would be:
520 520  
521 -urn:sdmx:org.sdmx.infomodel.metadatastructure.MetadataAttribute=SDMX: CONTACT_METADATA(1.0.0).CONTACT_DETAILS.CONTACT_NAME
510 + urn:sdmx:org.sdmx.infomodel.metadatastructure.MetadataAttribute=SDMX: CONTACT_METADATA(1.0.0).CONTACT_DETAILS.CONTACT_NAME
522 522  
523 523  The TFFS defines ABC as a sub-Agency of TFFS then the URN of a Dataflow maintained by ABC and identified as EXTERNAL_DEBT of semantic version 1.0.0 would be:
524 524  
525 -urn:sdmx:org.sdmx.infomodel.datastructure.Dataflow=TFFS.ABC:EXTERNAL_ DEBT(1.0.0)
514 + urn:sdmx:org.sdmx.infomodel.datastructure.Dataflow=TFFS.ABC:EXTERNAL_ DEBT(1.0.0)
526 526  
527 527  The SDMX-RR MUST support this globally unique identification scheme. The SDMX-RR MUST be able to create the URN from the individual identification attributes submitted and to transform the URN to these identification attributes. The identification attributes are:
528 528  
... ... @@ -817,7 +817,7 @@
817 817  * All types of Structure (Data Structure Definition, Metadata Structure Definition)
818 818  * All types of Structure Usage (Dataflow, Metadataflow)
819 819  
820 -===== {{id name="_Toc93865"/}}7.1.3 Structure Usage =====
809 +=== {{id name="_Toc93865"/}}7.1.3 Structure Usage ===
821 821  
822 822  ==== 7.1.3.1 Structure Usage: Basic Concepts ====
823 823  
SUZ.Methodology.Code.MethodologyClass[0]