Skip to Content
Last modified by Helena on 2025/09/10 11:19
From version 2.5
edited by Helena
on 2025/05/21 14:21
Change comment: There is no comment for this version
To version 1.7
edited by Helena
on 2025/05/21 13:49
Change comment: There is no comment for this version

Summary

Details

Page properties
Content
... ... @@ -340,8 +340,8 @@
340 340  
341 341  The following table defines the behaviour of the SDMX Registry for the various Registry Interface messages.
342 342  
343 -|(% style="width:244px" %)**Interface**|**Behaviour**
344 -|(% style="width:244px" %)All|(((
343 +|(% style="width:143px" %)**Interface**|(% style="width:1729px" %)**Behaviour**
344 +|(% style="width:143px" %)All|(% style="width:1729px" %)(((
345 345  1) If the action is set to “replace” then the entire contents of the existing maintainable object in the Registry MUST be replaced by the object submitted, unless the final attribute is set to “true” in which case the only changes that are allowed are to the following constructs:
346 346  
347 347  * Name – this applies to the Maintainable object and its contained elements, such a Code in a Code list.
... ... @@ -365,10 +365,11 @@
365 365  
366 366  5) The specific rules for the elements and attributes documented in the SDMX Schema MUST be obeyed.
367 367  )))
368 -|(% style="width:244px" %)SubmitStructureRequest|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.
369 -|(% style="width:244px" %)SubmitProvisioningRequest|No additional behaviour.
370 -|(% style="width:244px" %)Submit Registration Request|(((
368 +|(% style="width:143px" %)SubmitStructureRequest|(% style="width:1729px" %)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.
369 +|(% style="width:143px" %)SubmitProvisioningRequest|(% style="width:1729px" %)No additional behaviour.
370 +|(% style="width:143px" %)Submit Registration Request|(% style="width:1729px" %)(((
371 371  If the datasource is a file (simple datasource) then the file MAY be retrieved and indexed according to the Boolean attributes set in the Registration.
372 +
372 372  For a queryable datasource the Registry MAY validate that the source exists and can accept an SDMX-ML data query.
373 373  )))
374 374  
... ... @@ -469,10 +469,9 @@
469 469  
470 470  An example of this is shown in the XML snippet below.
471 471  
472 -[[image:1747824123013-196.jpeg||height="309" width="446"]]
473 +[[image:1747824123013-196.jpeg]]
473 473  
474 -(% class="wikigeneratedid" id="HFigure8:ExampleShowingUseofAgencyIdentifiers" %)
475 -**Figure 8: Example Showing Use of Agency Identifiers**
475 +==== Figure 8: Example Showing Use of Agency Identifiers ====
476 476  
477 477  Each of these maintenance agencies has an identical Code list with the Id CL_BOP. However, each is uniquely identified by means of the hierarchic agency structure.
478 478  
... ... @@ -512,8 +512,10 @@
512 512  
513 513  **(maintainable-object-version)** is the version of the maintainable object and is enclosed in round brackets (). It will always be present.
514 514  
515 -**container-object-id** is the identifier of an intermediary object that contains the actual object which the URN is identifying. It is not mandatory as many actual objects do not have an intermediary container object. For instance, a Code is in a maintained object (Code List) and has no intermediary container object, whereas a Metadata Attribute has an intermediary container object (Report Structure) and may have an intermediary container object which is its parent Metadata Attribute. For this reason the container object id may repeat, with each repetition identifying the object at the next-lower level in its hierarchy. Note that if there is only a single containing object in the model then it is NOT included in the URN structure. This applies to Attribute Descriptor, Dimension Descriptor, and Measure Descriptor where there can be only one such object and this object has a fixed id. Therefore, whilst each of these has a URN, the id of the Attribute Descriptor, Dimension Descriptor, and Measure Descriptor is not included when the actual object is a Data Attribute or a Dimension/Measure Dimension/ Time Dimension, or a Measure.
515 +**container-object-id** is the identifier of an intermediary object that contains the actual object which the URN is identifying. It is not mandatory as many actual objects do not have an intermediary container object. For instance, a Code is in a maintained object (Code List) and has no intermediary container object, whereas a Metadata Attribute has an intermediary container object (Report Structure) and may have an intermediary container object which is its parent Metadata Attribute. For this reason the container object id may repeat, with each repetition identifying the object at the next-lower level in its hierarchy. Note that if there is only a single containing object in the model then it is NOT included in the URN structure. This applies to Attribute Descriptor, Dimension Descriptor, and Measure Descriptor where there can be only one such object and this object has a fixed id. Therefore, whilst each of these has a
516 516  
517 +URN, the id of the Attribute Descriptor, Dimension Descriptor, and Measure Descriptor is not included when the actual object is a Data Attribute or a Dimension/Measure Dimension/ Time Dimension, or a Measure.
518 +
517 517  Note that although a Code can have a parent Code and a Concept can have a parent Concept these are maintained in a flat structure and therefore do not have a container-object-id.
518 518  
519 519  For example the sequence is agency:DSDid(version).DimensionId and not agency:DSDid(version).DimensionDescriptorId.DimensionId.
... ... @@ -520,57 +520,58 @@
520 520  
521 521  **object-id** is the identifier of the actual object unless the actual object is a maintainable object. If present it is always the last id and is not followed by any other character.
522 522  
523 -===== __**//Generic Examples of the URN Structure//**__ =====
525 +===== //Generic Examples of the URN Structure// =====
524 524  
525 -__Actual object is a maintainable__
526 526  
527 -> SDMXPrefix.SDMX-IM package name.classname=agency id:maintained-object-id(version)
528 +Actual object is a maintainable
528 528  
529 -__Actual object is contained in a maintained object with no intermediate containing object__
530 +SDMXPrefix.SDMX-IM package name.classname=agency id:maintained-object-id(version)
530 530  
531 -> SDMXPrefix.SDMX-IM package name.classname=agency id:maintained-object-id(version).object-id
532 +Actual object is contained in a maintained object with no intermediate containing object
532 532  
533 -__Actual object is contained in a maintained object with an intermediate containing object__
534 +SDMXPrefix.SDMX-IM package name.classname=agency id:maintained-object-id(version).object-id
534 534  
535 -> SDMXPrefix.SDMX-IM package name.classname=agency
536 +Actual object is contained in a maintained object with an intermediate containing object
536 536  
538 +SDMXPrefix.SDMX-IM package name.classname=agency
539 +
537 537  id:maintained-object-id(version).contained-object-id.object-id
538 538  
539 -__Actual object is contained in a maintained object with no intermediate containing object but the object type itself is hierarchical__
542 +Actual object is contained in a maintained object with no intermediate containing object but the object type itself is hierarchical
540 540  
541 541  In this case the object id may not be unique in itself but only within the context of the hierarchy. In the general syntax of the URN all intermediary objects in the structure (with the exception, of course, of the maintained object) are shown as a contained object. An example here would be a Category in a Category Scheme. The Category is hierarchical and all intermediate Categories are shown as a contained object. The example below shows the generic structure for Category Scheme/Category/Category
542 542  
543 -> SDMXPrefix.SDMX-IM package name.classname=agency id:maintained-object-id(version).contained-object-id.object-id
546 +SDMXPrefix.SDMX-IM package name.classname=agency id:maintained-object-id(version).contained-object-id.object-id
544 544  
545 -__Actual object is contained in a maintained object with an intermediate containing object and the object type itself is hierarchical__
548 +Actual object is contained in a maintained object with an intermediate containing object and the object type itself is hierarchical
546 546  
547 547  In this case the generic syntax is the same as for the example above as the parent object is regarded as a containing object, even if it is of the same type. An example here is a Metadata Attribute where the contained objects are Report Structure (first contained object id) and Metadata Attribute (subsequent contained object Ids). The example below shows the generic structure for MSD/Report Structure/Metadata Attribute/Metadata Attribute
548 548  
549 -> SDMXPrefix.SDMX-IM package name.classname=agency id:maintained-object-id(version).contained-object-id. contained-object-id contained-object-id.object-id
552 +SDMXPrefix.SDMX-IM package name.classname=agency id:maintained-object-id(version).contained-object-id. contained-object-id contained-object-id.object-id
550 550  
551 -===== __**//Concrete Examples of the URN Structure//**__ =====
554 +===== //Concrete Examples of the URN Structure// =====
552 552  
553 553  The Data Structure Definition CRED_EXT_DEBT version 1.0 maintained by the top level Agency TFFS would have the URN:
554 554  
555 -> urn:sdmx:org.sdmx.infomodel.datastructure.DataStucture=TFFS:CRED_EXT_ DEBT(1.0)
558 +urn:sdmx:org.sdmx.infomodel.datastructure.DataStucture=TFFS:CRED_EXT_ DEBT(1.0)
556 556  
557 557  The URN for a code for Argentina maintained by ISO in the code list CL_3166A2 version 1.0 would be:
558 558  
559 -> urn:sdmx:org.sdmx.infomodel.codelist.Code=ISO:CL_3166A2(1.0).AR
562 +urn:sdmx:org.sdmx.infomodel.codelist.Code=ISO:CL_3166A2(1.0).AR
560 560  
561 561  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 version 1.0 would be:
562 562  
563 -> urn:sdmx:org.sdmx.infomodel.categoryscheme.Category=SDMX:SUBJE CT_MATTER_DOMAINS(1.0).1.2
566 +urn:sdmx:org.sdmx.infomodel.categoryscheme.Category=SDMX:SUBJE CT_MATTER_DOMAINS(1.0).1.2
564 564  
565 565  The URN for a Metadata Attribute maintained by SDMX in the MSD CONTACT_METADATA version 1.0 in the Report Structure CONTACT_REPORT where the hierarchy of the Metadata Attribute is
566 566  
567 567  CONTACT_DETAILS/CONTACT_NAME would be:
568 568  
569 -> urn:sdmx:org.sdmx.infomodel.metadatastructure.MetadataAttribut e=SDMX:CONTACT_METADATA(1.0).CONTACT_REPORT.CONTACT_DETAILS.CO NTACT_NAME
572 +urn:sdmx:org.sdmx.infomodel.metadatastructure.MetadataAttribut e=SDMX:CONTACT_METADATA(1.0).CONTACT_REPORT.CONTACT_DETAILS.CO NTACT_NAME
570 570  
571 571  The TFFS defines ABC as a sub Agency of TFFS then the URN of a Dataflow maintained by ABC and identified as EXTERNAL_DEBT version 1.0 would be:
572 572  
573 -> urn:sdmx:org.sdmx.infomodel.datastructure.Dataflow=TFFS.ABC:EX
576 +urn:sdmx:org.sdmx.infomodel.datastructure.Dataflow=TFFS.ABC:EX
574 574  
575 575  TERNAL_DEBT(1.0)
576 576