Last modified by Helena on 2025/09/10 11:19
Summary
-
Page properties (2 modified, 0 added, 0 removed)
-
Attachments (0 modified, 0 added, 11 removed)
Details
- Page properties
-
- Title
-
... ... @@ -1,1 +1,1 @@ 1 -SDMX 2.1 Standards. Section 5. Registry Specification – Logical Interfaces 1 +SDMX 2.1 Standards. Section. 5. Registry Specification – Logical Interfaces - Content
-
... ... @@ -4,11 +4,10 @@ 4 4 5 5 **Revision History** 6 6 7 -(% style="width:833.294px" %) 8 -|(% style="width:122px" %)**Revision**|(% style="width:126px" %)**Date**|(% style="width:581px" %)**Contents** 9 -|(% style="width:122px" %) |(% style="width:126px" %)April 2011|(% style="width:581px" %)Initial release 10 -|(% style="width:122px" %)1.0|(% style="width:126px" %)July 2011|(% style="width:581px" %)Rectification of problems of the specifications dated April 2011 11 -|(% style="width:122px" %)2.0|(% style="width:126px" %)July 2020|(% style="width:581px" %)Addition of VTL (Validation and Transformation Language) package, maintainable artefacts, nameable artefacts to 5.2.3, 6.2.2, 6.2.3, 6.2.4, 7.1.1 7 +|**Revision**|**Date**|**Contents** 8 +| |April 2011|Initial release 9 +|1.0|July 2011|Rectification of problems of the specifications dated April 2011 10 +|2.0|July 2020|Addition of VTL (Validation and Transformation Language) package, maintainable artefacts, nameable artefacts to 5.2.3, 6.2.2, 6.2.3, 6.2.4, 7.1.1 12 12 13 13 **Corrigendum** 14 14 ... ... @@ -289,22 +289,27 @@ 289 289 * that a queryable data source exists - this would necessitate the registration service querying the service to determine its existence 290 290 * that a simple data source exists (i.e. a file accessible at a URL) 291 291 * that the correct Data Structure Definition or Metadata Structure Definition is used by the registered data that the components (Dimensions, Attributes, Measures, Identifier Components etc.) are consistent with the Data Structure Definition or Metadata Structure Definition 292 -* that the valid representations of the concepts to which these components correspond conform to the definition in the Data Structure Definition or Metadata Structure Definition 291 +* that the valid representations of the concepts to which these components 382 correspond conform to the definition in the Data Structure Definition or Metadata Structure Definition 293 293 294 -The Registration has an action attribute which takes one of the following values: 293 +3The Registration has an action attribute which takes one of the following values: 295 295 296 -|(% style="width:219px" %)**Action Attribute Value**|(% style="width:1652px" %)**Behaviour** 297 -|(% style="width:219px" %)Append|(% style="width:1652px" %)Add this registration to the registry 298 -|(% style="width:219px" %)Replace|(% style="width:1652px" %)Replace the existing Registration with this Registration identified by the id in the Registration of the Submit Registration Request 299 -|(% style="width:219px" %)Delete|(% style="width:1652px" %)Delete the existing Registration identified by the id in the Registration of the Submit Registration Request 295 +|(% style="width:249px" %)((( 296 +**Action Attribute Value** 297 +)))|(% style="width:1622px" %)**Behaviour** 298 +|(% style="width:249px" %)Append|(% style="width:1622px" %)Add this registration to the registry 299 +|(% style="width:249px" %)Replace|(% style="width:1622px" %)Replace the existing Registration with this Registration identified by the id in the Registration of the Submit Registration Request 300 +|(% style="width:249px" %)Delete|(% style="width:1622px" %)Delete the existing Registration identified by the id in the Registration of the Submit Registration Request 300 300 301 301 The Registration has three Boolean attributes which may be present to determine how an SDMX compliant Dataset or Metadata Set indexing application must index the Datasets or Metadata Set upon registration. The indexing application behaviour is as follows: 302 302 303 -|(% style="width:228px" %)**Boolean Attribute**|(% style="width:1644px" %)**Behaviour if Value is “true”** 304 -|(% style="width:228px" %)indexTimeSeries|(% style="width:1644px" %)A compliant indexing application must index all the time series keys (for a Dataset registration) or metadata target values (for a Metadata Set registration) 305 -|(% style="width:228px" %)indexDataSet|(% style="width:1644px" %)A compliant indexing application must index the range of actual (present) values for each dimension of the Dataset (for a Dataset registration) or the range of actual (present) values for each Metadata Attribute which takes an enumerated value. 304 +|**Boolean Attribute**|**Behaviour if Value is “true”** 305 +|indexTimeSeries|A compliant indexing application must index all the time series keys (for a Dataset registration) or metadata target values (for a Metadata Set registration) 306 +|indexDataSet|((( 307 +A compliant indexing application must index the range of actual (present) values for each dimension of the Dataset (for a Dataset registration) or the range of actual (present) values for each Metadata Attribute which takes an enumerated value. 308 + 306 306 Note that for data this requires much less storage than full key indexing, but this method cannot guarantee that a specific combination of Dimension values (the Key) is actually present in the Dataset 307 -|(% style="width:228px" %)indexReportingPeriod|(% style="width:1644px" %)A compliant indexing application must index the time period range(s) for which data are present in the Dataset or Metadata Set 310 +))) 311 +|indexReportingPeriod|A compliant indexing application must index the time period range(s) for which data are present in the Dataset or Metadata Set 308 308 309 309 === 5.2.5 Data and Reference Metadata Discovery === 310 310 ... ... @@ -326,7 +326,7 @@ 326 326 Subscription management involves a user submitting a subscription request which contains: 327 327 328 328 * 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). 329 -* a list of URIs or end-points to which an XML notification message can be sent. Supported end-point types will be email (mailto :) and HTTP POST (a normal http:~/~/ address)333 +* a list of URIs or end-points to which an XML notification message can be sent. Supported end-point types will be email (mailto~:) and HTTP POST (a normal http:~/~/ address) 330 330 * request for a list of submitted subscriptions 331 331 * deletion of a subscription 332 332 ... ... @@ -336,12 +336,13 @@ 336 336 337 337 The following table defines the behaviour of the SDMX Registry for the various Registry Interface messages. 338 338 339 -| (% style="width:227px" %)**Interface**|(% style="width:1644px" %)**Behaviour**340 -| (% style="width:227px" %)All|(% style="width:1644px" %)(((343 +|**Interface**|**Behaviour** 344 +|All|((( 341 341 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: 342 342 343 343 * Name – this applies to the Maintainable object and its contained elements, such a Code in a Code list. 344 344 * Description - this applies to the Maintainable object and its contained elements, such a Code in a Code list. 349 + 345 345 * Annotation - this applies to the Maintainable object and its contained elements, such a Code in a Code list. 346 346 * validTo 347 347 * validFrom ... ... @@ -350,22 +350,26 @@ 350 350 * uri 351 351 * isExternalReference 352 352 353 - 2)Cross referenced structures MUST exist in either the submitted document (in Structures or Structure Location) or in the registry to which the request is submitted.354 - 3)If the action is set to “delete” then the Registry MUST verify that the object can deleted. In order to qualify for deletion the object must:358 +1. Cross referenced structures MUST exist in either the submitted document (in Structures or Structure Location) or in the registry to which the request is submitted. 359 +1. If the action is set to “delete” then the Registry MUST verify that the object can deleted. In order to qualify for deletion the object must: 355 355 356 - а)Not have the final attribute set to “true”357 - b)Not be referenced from any other object in the Registry.361 +1. Not have the final attribute set to “true” 362 +1. Not be referenced from any other object in the Registry. 358 358 359 -4) The version rules in the SDMX Schema documentation MUST be obeyed. 360 -5) The specific rules for the elements and attributes documented in the SDMX Schema MUST be obeyed. 364 +1. The version rules in the SDMX Schema documentation MUST be obeyed. 365 + 366 +* The specific rules for the elements and attributes documented in the SDMX Schema MUST be obeyed. 361 361 ))) 362 -| (% style="width:227px" %)SubmitStructureRequest|(% style="width:1644px" %)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.363 -| (% style="width:227px" %)SubmitProvisioningRequest|(% style="width:1644px" %)No additional behaviour.364 -| (% style="width:227px" %)Submit Registration Request|(% style="width:1644px" %)(((368 +|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 +|SubmitProvisioningRequest|No additional behaviour. 370 +|Submit Registration Request|((( 365 365 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 + 366 366 For a queryable datasource the Registry MAY validate that the source exists and can accept an SDMX-ML data query. 367 367 ))) 368 368 376 + 377 + 369 369 = 6 Identification of SDMX Objects = 370 370 371 371 == 6.1 Identification, Versioning, and Maintenance == ... ... @@ -372,6 +372,7 @@ 372 372 373 373 All major classes of the SDMX Information model inherit from one of: 374 374 384 + 375 375 * **IdentifiableArtefact** - this gives an object the ability to be uniquely identified (see following section on identification), to have a user-defined URI, and to have multi-lingual annotations. 376 376 * **NamableArtefact **- this has all of the features of IdentifiableArtefact plus the ability to have a multi-lingual name and description, 377 377 * **VersionableArtefact **– this has all of the above features plus a version number and a validity period. ... ... @@ -379,8 +379,6 @@ 379 379 380 380 === 6.1.1 Identification, Naming, Versioning, and Maintenance Model === 381 381 382 -[[image:1747824504225-229.png]] 383 - 384 384 **Figure 5: Class diagram of fundamental artefacts in the SDMX-IM** 385 385 386 386 The table below shows the identification and related data attributes to be stored in a registry for objects that are one of: ... ... @@ -391,34 +391,38 @@ 391 391 * Versionable 392 392 * Maintainable 393 393 394 -(% style="width:935.294px" %) 395 -|**Object Type**|(% style="width:244px" %)**Data Attributes**|(% style="width:99px" %)**Status**|**Data type**|(% style="width:389px" %)**Notes** 396 -|Annotable|(% style="width:244px" %)AnnotationTitle|(% style="width:99px" %)C|string|(% style="width:389px" %) 397 -| |(% style="width:244px" %)AnnotationType|(% style="width:99px" %)C|string|(% style="width:389px" %) 398 -| |(% style="width:244px" %)AnnotationURN|(% style="width:99px" %)C|string|(% style="width:389px" %) 399 -| |(% style="width:244px" %)((( 400 -AnnotationText in the form of International String 401 -)))|(% style="width:99px" %)C| |(% style="width:389px" %)This can have languagespecific variants. 402 -|Identifiable|(% style="width:244px" %)all content as for Annotable plus|(% style="width:99px" %) | |(% style="width:389px" %) 403 -| |(% style="width:244px" %)id|(% style="width:99px" %)M|string|(% style="width:389px" %) 404 -| |(% style="width:244px" %)uri|(% style="width:99px" %)C|string|(% style="width:389px" %) 405 -| |(% style="width:244px" %)urn|(% style="width:99px" %)C|string|(% style="width:389px" %)Although the urn is computable and therefore may not be submitted or stored physically, the Registry must return the urn for each object, and must be able to service a query on an object referenced solely by its urn. 406 -|Nameable|(% style="width:244px" %)all content as for Identifiable plus|(% style="width:99px" %) | |(% style="width:389px" %) 407 -| |(% style="width:244px" %)Name in the form of International String|(% style="width:99px" %)M|string|(% style="width:389px" %)This can have languagespecific variants. 408 -| |(% style="width:244px" %)((( 409 -Description in the form of International String 410 -)))|(% style="width:99px" %)C|string|(% style="width:389px" %)This can have languagespecific variants. 411 -|Versionable|(% style="width:244px" %)All content as for Identifiable plus|(% style="width:99px" %) | |(% style="width:389px" %) 412 -| |(% style="width:244px" %)version|(% style="width:99px" %)C|string|(% style="width:389px" %)This is the version number. If not present the default is 1.0 413 -| |(% style="width:244px" %)validFrom|(% style="width:99px" %)C|Date/time|(% style="width:389px" %) 414 -| |(% style="width:244px" %)validTo|(% style="width:99px" %)C|Date/time|(% style="width:389px" %) 415 -|Maintainable|(% style="width:244px" %)All content as for Versionable plus|(% style="width:99px" %) | |(% style="width:389px" %) 416 -| |(% style="width:244px" %)final|(% style="width:99px" %) |boolean|(% style="width:389px" %)Value of “true” indicates that this is a final specification and it cannot be changed except as a new version. Note that providing a “final’ object is not referenced from another object then it may be deleted. 417 -| |(% style="width:244px" %)isExternalReference|(% style="width:99px" %)C|boolean|(% style="width:389px" %)Value of “true” indicates that the actual resource is held outside of this registry. The actual reference is given in the registry URI or the structureURI, each of which must return a valid SDMX-ML file. 418 -| |(% style="width:244px" %)serviceURL|(% style="width:99px" %)C|string|(% style="width:389px" %)The url of the service that can be queried for this resource 419 -| |(% style="width:244px" %)structureURL|(% style="width:99px" %)C|string|(% style="width:389px" %)The url of the resource. 420 -| |(% style="width:244px" %)(Maintenance) agencyId|(% style="width:99px" %)M|string|(% style="width:389px" %)The object must be linked to a maintenance agency. 402 +|**Object Type**|**Data Attributes**|**Status**|**Data type**|**Notes** 403 +|Annotable|AnnotationTitle|C|string| 404 +| |AnnotationType|C|string| 405 +| |AnnotationURN|C|string| 406 +| |((( 407 +AnnotationText in the form of 421 421 409 +International String 410 +)))|C| |This can have languagespecific variants. 411 +| | | | | 412 +|Identifiable|all content as for Annotable plus| | | 413 +| |id|M|string| 414 +| |uri|C|string| 415 +| |urn|C|string|Although the urn is computable and therefore may not be submitted or stored physically, the Registry must return the urn for each object, and must be able to service a query on an object referenced solely by its urn. 416 +|Nameable|all content as for Identifiable plus| | | 417 +| |Name in the form of International String|M|string|This can have languagespecific variants. 418 +| |((( 419 +Description in the form of International 420 + 421 +String 422 +)))|C|string|This can have languagespecific variants. 423 +|Versionable|All content as for Identifiable plus| | | 424 +| |version|C|string|This is the version number. If not present the default is 1.0 425 +| |validFrom|C|Date/time| 426 +| |validTo|C|Date/time| 427 +|Maintainable|All content as for Versionable plus| | | 428 +| |final| |boolean|Value of “true” indicates that this is a final specification and it cannot be changed except as a new version. Note that providing a “final’ object is not referenced from another object then it may be deleted. 429 +| |isExternalReference|C|boolean|Value of “true” indicates that the actual resource is held outside of this registry. The actual reference is given in the registry URI or the structureURI, each of which must return a valid SDMX-ML file. 430 +| |serviceURL|C|string|The url of the service that can be queried for this resource 431 +| |structureURL|C|string|The url of the resource. 432 +| |(Maintenance) agencyId|M|string|The object must be linked to a maintenance agency. 433 + 422 422 **Table 1: Common Attributes of Object Types** 423 423 424 424 == 6.2 Unique identification of SDMX objects == ... ... @@ -427,8 +427,6 @@ 427 427 428 428 The Maintenance Agency in SDMX is maintained in an Agency Scheme which itself is a sub class of Organisation Scheme – this is shown in the class diagram below. 429 429 430 -[[image:1747994320263-112.png]] 431 - 432 432 **Figure 6: Agency Scheme Model** 433 433 434 434 The Agency in SDMX is extremely important. The Agency Id system used in SDMX is an n-level structure. The top level of this structure is maintained by SDMX. Any Agency in this top level can declare sub agencies and any sub agency can also declare sub agencies. The Agency Scheme has a fixed id and version and is never declared explicitly in the SDMX object identification mechanism. ... ... @@ -450,7 +450,7 @@ 450 450 451 451 [[image:1747824123012-527.jpeg]] 452 452 453 - **Figure 7: Example of Hierarchic Structure of Agencies**463 +==== Figure 7: Example of Hierarchic Structure of Agencies ==== 454 454 455 455 The following organizations maintain an Agency Scheme. 456 456 ... ... @@ -465,10 +465,11 @@ 465 465 466 466 An example of this is shown in the XML snippet below. 467 467 468 -[[image:1747832400104-286.png]] 469 469 470 - **Figure8:ExampleShowingUse of Agency Identifiers**479 +[[image:1747824123013-196.jpeg]] 471 471 481 +==== Figure 8: Example Showing Use of Agency Identifiers ==== 482 + 472 472 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. 473 473 474 474 === 6.2.2 Universal Resource Name (URN) === ... ... @@ -479,14 +479,13 @@ 479 479 480 480 ==== 6.2.2.2 URN Structure ==== 481 481 482 -(% class="wikigeneratedid" id="HCaseRulesforURN" %) 483 -//Case Rules for URN// 493 +===== //Case Rules for URN// ===== 484 484 485 485 For the URN, all parts of the string are case sensitive. The Id of any object must be UPPER CASE. Therefore, CRED_ext_Debt is invalid and it should be CRED_EXT_DEBT. 486 486 487 487 The generic structure of the URN is as follows: 488 488 489 - >SDMXprefix.SDMX-IM-package-name.class-name=agencyid:maintainedobject-id(maintainedobject-version).*containerobject-id.object-id499 +SDMXprefix.SDMX-IM-package-name.class-name=agencyid:maintainedobject-id(maintainedobject-version).*containerobject-id.object-id 490 490 491 491 ~* this can repeat and may not be present (see explanation below) 492 492 ... ... @@ -498,7 +498,7 @@ 498 498 499 499 In the explanation below the actual object that is the target of the URN is called the **//actual object//**. 500 500 501 -**SDMXPrefix:** urn:sdmx:org. 511 +**SDMXPrefix:** urn:sdmx:org. 502 502 503 503 **SDMX-IM package name:** sdmx.infomodel.package= 504 504 ... ... @@ -508,8 +508,10 @@ 508 508 509 509 **(maintainable-object-version)** is the version of the maintainable object and is enclosed in round brackets (). It will always be present. 510 510 511 -**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.521 +**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 512 512 523 +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. 524 + 513 513 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. 514 514 515 515 For example the sequence is agency:DSDid(version).DimensionId and not agency:DSDid(version).DimensionDescriptorId.DimensionId. ... ... @@ -516,57 +516,58 @@ 516 516 517 517 **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. 518 518 519 -===== __**//Generic Examples of the URN Structure//**__=====531 +===== //Generic Examples of the URN Structure// ===== 520 520 521 -__Actual object is a maintainable__ 522 522 523 - > SDMXPrefix.SDMX-IM packagename.classname=agencyid:maintained-object-id(version)534 +Actual object is a maintainable 524 524 525 - __Actualobject iscontained inamaintainedobjectwith no intermediate containing object__536 +SDMXPrefix.SDMX-IM package name.classname=agency id:maintained-object-id(version) 526 526 527 - > SDMXPrefix.SDMX-IM packagename.classname=agencyid:maintained-object-id(version).object-id538 +Actual object is contained in a maintained object with no intermediate containing object 528 528 529 - __Actualobject iscontained inamaintainedobjectwith an intermediate containingobject__540 +SDMXPrefix.SDMX-IM package name.classname=agency id:maintained-object-id(version).object-id 530 530 531 - >SDMXPrefix.SDMX-IMpackage name.classname=agency542 +Actual object is contained in a maintained object with an intermediate containing object 532 532 544 +SDMXPrefix.SDMX-IM package name.classname=agency 545 + 533 533 id:maintained-object-id(version).contained-object-id.object-id 534 534 535 - __Actual object is contained in a maintained object with no intermediate containing object but the object type itself is hierarchical__548 +Actual object is contained in a maintained object with no intermediate containing object but the object type itself is hierarchical 536 536 537 537 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 538 538 539 - >SDMXPrefix.SDMX-IM package name.classname=agency id:maintained-object-id(version).contained-object-id.object-id552 +SDMXPrefix.SDMX-IM package name.classname=agency id:maintained-object-id(version).contained-object-id.object-id 540 540 541 - __Actual object is contained in a maintained object with an intermediate containing object and the object type itself is hierarchical__554 +Actual object is contained in a maintained object with an intermediate containing object and the object type itself is hierarchical 542 542 543 543 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 544 544 545 - >SDMXPrefix.SDMX-IM package name.classname=agency id:maintained-object-id(version).contained-object-id. contained-object-id contained-object-id.object-id558 +SDMXPrefix.SDMX-IM package name.classname=agency id:maintained-object-id(version).contained-object-id. contained-object-id contained-object-id.object-id 546 546 547 -===== __**//Concrete Examples of the URN Structure//**__=====560 +===== //Concrete Examples of the URN Structure// ===== 548 548 549 549 The Data Structure Definition CRED_EXT_DEBT version 1.0 maintained by the top level Agency TFFS would have the URN: 550 550 551 - >urn:sdmx:org.sdmx.infomodel.datastructure.DataStucture=TFFS:CRED_EXT_ DEBT(1.0)564 +urn:sdmx:org.sdmx.infomodel.datastructure.DataStucture=TFFS:CRED_EXT_ DEBT(1.0) 552 552 553 553 The URN for a code for Argentina maintained by ISO in the code list CL_3166A2 version 1.0 would be: 554 554 555 - >urn:sdmx:org.sdmx.infomodel.codelist.Code=ISO:CL_3166A2(1.0).AR568 +urn:sdmx:org.sdmx.infomodel.codelist.Code=ISO:CL_3166A2(1.0).AR 556 556 557 557 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: 558 558 559 - >urn:sdmx:org.sdmx.infomodel.categoryscheme.Category=SDMX:SUBJE CT_MATTER_DOMAINS(1.0).1.2572 +urn:sdmx:org.sdmx.infomodel.categoryscheme.Category=SDMX:SUBJE CT_MATTER_DOMAINS(1.0).1.2 560 560 561 561 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 562 562 563 563 CONTACT_DETAILS/CONTACT_NAME would be: 564 564 565 - >urn:sdmx:org.sdmx.infomodel.metadatastructure.MetadataAttribut e=SDMX:CONTACT_METADATA(1.0).CONTACT_REPORT.CONTACT_DETAILS.CO NTACT_NAME578 +urn:sdmx:org.sdmx.infomodel.metadatastructure.MetadataAttribut e=SDMX:CONTACT_METADATA(1.0).CONTACT_REPORT.CONTACT_DETAILS.CO NTACT_NAME 566 566 567 567 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: 568 568 569 - >urn:sdmx:org.sdmx.infomodel.datastructure.Dataflow=TFFS.ABC:EX582 +urn:sdmx:org.sdmx.infomodel.datastructure.Dataflow=TFFS.ABC:EX 570 570 571 571 TERNAL_DEBT(1.0) 572 572 ... ... @@ -581,95 +581,112 @@ 581 581 582 582 The table below lists all of the packages in the SDMX-IM together with the concrete classes that are in these packages and whose objects have a URN. 583 583 584 -(% style="width:644.294px" %) 585 -|(% style="width:127px" %)**Package**|(% style="width:494px" %)((( 586 -**URN Classname (model classname where this is different)** 597 +|**Package**|((( 598 +**URN Classname (model classname** 599 + 600 +**where this is different)** 587 587 ))) 588 -|(% style="width:127px" %)base|(% style="width:494px" %)Agency 589 -|(% style="width:127px" %) |(% style="width:494px" %)OrganisationUnitScheme 590 -|(% style="width:127px" %) |(% style="width:494px" %)AgencyScheme 591 -|(% style="width:127px" %) |(% style="width:494px" %)DataProviderScheme 592 -|(% style="width:127px" %) |(% style="width:494px" %)DataConsumerScheme 593 -|(% style="width:127px" %) |(% style="width:494px" %)OrganisationUnit 594 -|(% style="width:127px" %) |(% style="width:494px" %)DataProvider 595 -|(% style="width:127px" %) |(% style="width:494px" %)DataConsumer 596 -|(% style="width:127px" %)datastructure|(% style="width:494px" %)DataStructure (DataStructureDefinition) 597 -|(% style="width:127px" %) |(% style="width:494px" %)AttributeDescriptor 598 -|(% style="width:127px" %) |(% style="width:494px" %)DataAttribute 599 -|(% style="width:127px" %) |(% style="width:494px" %)GroupDimensionDescriptor 600 -|(% style="width:127px" %) |(% style="width:494px" %)DimensionDescriptor 601 -|(% style="width:127px" %) |(% style="width:494px" %)Dimension 602 -|(% style="width:127px" %) |(% style="width:494px" %)MeasureDimension 603 -|(% style="width:127px" %) |(% style="width:494px" %)TimeDimension 604 -|(% style="width:127px" %) |(% style="width:494px" %)MeasureDescriptor 605 -|(% style="width:127px" %) |(% style="width:494px" %)PrimaryMeasure 606 -|(% style="width:127px" %) |(% style="width:494px" %)Dataflow (DataflowDefinition) 607 -|(% style="width:127px" %)metadatastructure|(% style="width:494px" %)MetadataTarget 608 -|(% style="width:127px" %) |(% style="width:494px" %)DimensionDescriptorValueTarget 609 -|(% style="width:127px" %) |(% style="width:494px" %)IdentifiableObjectTarget 610 -|(% style="width:127px" %) |(% style="width:494px" %)ReportPeriodTarget 611 -|(% style="width:127px" %) |(% style="width:494px" %)DataSetTarget 612 -|(% style="width:127px" %) |(% style="width:494px" %)ReportStructure 613 -|(% style="width:127px" %) |(% style="width:494px" %)MetadataAttribute 614 -|(% style="width:127px" %) |(% style="width:494px" %)((( 602 +|base|Agency 603 +| |OrganisationUnitScheme 604 +| |AgencyScheme 605 +| |DataProviderScheme 606 +| |DataConsumerScheme 607 +| |OrganisationUnit 608 +| |DataProvider 609 +| |DataConsumer 610 +| | 611 +|datastructure|DataStructure (DataStructureDefinition) 612 +| |AttributeDescriptor 613 +| |DataAttribute 614 +| |GroupDimensionDescriptor 615 +| |DimensionDescriptor 616 +| |Dimension 617 +| |MeasureDimension 618 +| |TimeDimension 619 +| |MeasureDescriptor 620 +| |PrimaryMeasure 621 +| |Dataflow (DataflowDefinition) 622 +| | 623 +|metadatastructure|MetadataTarget 624 +| |DimensionDescriptorValueTarget 625 +| |IdentifiableObjectTarget 626 +| |ReportPeriodTarget 627 +| |DataSetTarget 628 +| |ReportStructure 629 +| |MetadataAttribute 630 +| |((( 615 615 MetadataStructure 616 616 617 617 (MetadataStructureDefinition) 618 618 ))) 619 -|(% style="width:127px" %) |(% style="width:494px" %)Metadataflow (MetadataflowDefinition) 620 -|(% style="width:127px" %)process|(% style="width:494px" %)Process 621 -|(% style="width:127px" %) |(% style="width:494px" %)ProcessStep 622 -|(% style="width:127px" %) |(% style="width:494px" %)Transition 623 -|(% style="width:127px" %)registry|(% style="width:494px" %)ProvisionAgreement 624 -|(% style="width:127px" %) |(% style="width:494px" %)AttachmentConstraint 625 -|(% style="width:127px" %) |(% style="width:494px" %)ContentConstraint 626 -|(% style="width:127px" %) |(% style="width:494px" %)Subscription 627 -|(% style="width:127px" %)mapping|(% style="width:494px" %)StructureMap 628 -|(% style="width:127px" %) |(% style="width:494px" %)StructureSet 629 -|(% style="width:127px" %) |(% style="width:494px" %)ComponentMap 630 -|(% style="width:127px" %) |(% style="width:494px" %)ConceptSchemeMap 631 -|(% style="width:127px" %) |(% style="width:494px" %)OrganisationSchemeMap 632 -|(% style="width:127px" %) |(% style="width:494px" %)CodelistMap 633 -|(% style="width:127px" %) |(% style="width:494px" %)CategorySchemeMap 634 -|(% style="width:127px" %) |(% style="width:494px" %)ReportingTaxonomyMap 635 -|(% style="width:127px" %) |(% style="width:494px" %)ConceptMap 636 -|(% style="width:127px" %) |(% style="width:494px" %)OrganisationMap 637 -|(% style="width:127px" %) |(% style="width:494px" %)CodeMap 638 -|(% style="width:127px" %) |(% style="width:494px" %)HybridCodelistMap 639 -|(% style="width:127px" %) |(% style="width:494px" %)CategoryMap 640 -|(% style="width:127px" %) |(% style="width:494px" %)HybridCodeMap 641 -|(% style="width:127px" %) |(% style="width:494px" %)ReportingCategoryMap 642 -|(% style="width:127px" %)codelist|(% style="width:494px" %)Codelist 643 -|(% style="width:127px" %) |(% style="width:494px" %)HierarchicalCodelist 644 -|(% style="width:127px" %) |(% style="width:494px" %)Hierarchy 645 -|(% style="width:127px" %) |(% style="width:494px" %)Hierarchy 646 -|(% style="width:127px" %) |(% style="width:494px" %)Code 647 -|(% style="width:127px" %) |(% style="width:494px" %)HierarchicalCode 648 -|(% style="width:127px" %) |(% style="width:494px" %)Level 649 -|(% style="width:127px" %)categoryscheme|(% style="width:494px" %)CategoryScheme 650 -|(% style="width:127px" %) |(% style="width:494px" %)Category 651 -|(% style="width:127px" %) |(% style="width:494px" %)Categorisation 652 -|(% style="width:127px" %) |(% style="width:494px" %)ReportingTaxonomy 653 -|(% style="width:127px" %) |(% style="width:494px" %)ReportingCategory 654 -|(% style="width:127px" %)conceptscheme|(% style="width:494px" %)ConceptScheme 655 -|(% style="width:127px" %) |(% style="width:494px" %)Concept 656 -|(% style="width:127px" %)transformation|(% style="width:494px" %)TransformationScheme 657 -|(% style="width:127px" %) |(% style="width:494px" %)Transformation 658 -|(% style="width:127px" %) |(% style="width:494px" %)CustomTypeScheme 659 -|(% style="width:127px" %) |(% style="width:494px" %)CustomType 660 -|(% style="width:127px" %) |(% style="width:494px" %)NamePersonalisationScheme 661 -|(% style="width:127px" %) |(% style="width:494px" %)NamePersonalisation 662 -|(% style="width:127px" %) |(% style="width:494px" %)VtlCodelistMapping 663 -|(% style="width:127px" %) |(% style="width:494px" %)VtlConceptMapping 664 -|(% style="width:127px" %) |(% style="width:494px" %)VtlDataflowMapping 665 -|(% style="width:127px" %) |(% style="width:494px" %)VtlConceptSchemeMapping 666 -|(% style="width:127px" %) |(% style="width:494px" %)RulesetScheme 667 -|(% style="width:127px" %) |(% style="width:494px" %)Ruleset 668 -|(% style="width:127px" %) |(% style="width:494px" %)UserDefinedOperatorScheme 669 -|(% style="width:127px" %) |(% style="width:494px" %)UserDefinedOperator 635 +| |Metadataflow (MetadataflowDefinition) 636 +| | 637 +|process|Process 638 +| |ProcessStep 639 +| |Transition 640 +| | 641 +|registry|ProvisionAgreement 642 +| |AttachmentConstraint 643 +| |ContentConstraint 644 +| |Subscription 645 +| | 646 +|mapping|StructureMap 647 +| |StructureSet 648 +| |ComponentMap 649 +|**Package**|((( 650 +**URN Classname (model classname** 670 670 652 +**where this is different)** 653 +))) 654 +| |ConceptSchemeMap 655 +| |OrganisationSchemeMap 656 +| |CodelistMap 657 +| |CategorySchemeMap 658 +| |ReportingTaxonomyMap 659 +| |ConceptMap 660 +| |OrganisationMap 661 +| |CodeMap 662 +| |HybridCodelistMap 663 +| |CategoryMap 664 +| |HybridCodeMap 665 +| |ReportingCategoryMap 666 +| | 667 +|codelist|Codelist 668 +| |HierarchicalCodelist 669 +| |Hierarchy 670 +| |Hierarchy 671 +| |Code 672 +| |HierarchicalCode 673 +| |Level 674 +| | 675 +|categoryscheme|CategoryScheme 676 +| |Category 677 +| |Categorisation 678 +| |ReportingTaxonomy 679 +| |ReportingCategory 680 +| | 681 +|conceptscheme|ConceptScheme 682 +| |Concept 683 +| | 684 +|transformation|TransformationScheme 685 +| |Transformation 686 +| |CustomTypeScheme 687 +| |CustomType 688 +| |NamePersonalisationScheme 689 +| |NamePersonalisation 690 +| |VtlCodelistMapping 691 +| |VtlConceptMapping 692 +| |VtlDataflowMapping 693 +| |VtlConceptSchemeMapping 694 +| |RulesetScheme 695 +| |Ruleset 696 +| |UserDefinedOperatorScheme 697 +| |UserDefinedOperator 698 +| | 699 + 671 671 **Table 2: SDMX-IM Packages and Contained Classes** 672 672 702 + 673 673 === 6.2.4 URN Identification components of SDMX objects === 674 674 675 675 The table below describes the identification components for all SDMX object types that have identification. Note the actual attributes are all Id, but have been prefixed by their class name or multiple class names to show navigation, e.g. conceptSchemeAgencyId is really the Id attribute of the Agency class that is associated to the ConceptScheme. ... ... @@ -678,51 +678,78 @@ 678 678 679 679 Note that for brevity the URN examples omit the prefix. All URNs have the prefix 680 680 681 - >urn:sdmx.org.sdmx.infomodel.{package}.{classname}=711 +urn:sdmx.org.sdmx.infomodel.{package}.{classname}= 682 682 683 - (% style="width:1277.29px" %)684 -| (% style="width:269px" %)**SDMX Class**|(% style="width:453px" %)**Key attribute(s)**|(% style="width:550px" %)**Example of URN**685 -| (% style="width:269px" %)Agency|(% style="width:453px" %)The URN for an Agency is shown later in this table. The identification of an Agency in the URN structure for the maintainable object is by means of the agencyId. The AgencyScheme is not identified as SDMX has a mechanism for identifying an Agency uniquely by its Id. Note that this Id may be hierarchical.|(% style="width:550px" %)(((713 + 714 +|**SDMX Class**|**Key attribute(s)**|**Example of URN** 715 +|Agency|The URN for an Agency is shown later in this table. The identification of an Agency in the URN structure for the maintainable object is by means of the agencyId. The AgencyScheme is not identified as SDMX has a mechanism for identifying an Agency uniquely by its Id. Note that this Id may be hierarchical.|((( 686 686 IMF 717 + 718 + 687 687 Sub agency in the IMF AGENCIES 720 + 721 + 688 688 IMF.SubAgency1 689 689 ))) 690 -|(% style="width:269px" %)*ConceptScheme|(% style="width:453px" %)conceptSchemeAgencyId:conceptSchemeId(ve rsion)|(% style="width:550px" %)SDMX:CROSS_DOMAIN_CONCEPTS(1.0) 691 -|(% style="width:269px" %)Concept|(% style="width:453px" %)conceptSchemeAgencyId: 692 -conceptSchemeId(version).conceptId|(% style="width:550px" %)SDMX:CROSS_DOMAIN_CONCEPTS(1.0).FREQ 693 -|(% style="width:269px" %)*Codelist|(% style="width:453px" %)codeListAgencyId:codeListId(version)|(% style="width:550px" %)SDMX:CL_FREQ(1.0) 694 -|(% style="width:269px" %)Code|(% style="width:453px" %)codeListAgencyId:codelistId(version).codeId|(% style="width:550px" %)SDMX:CL_FREQ(1.0).Q 695 -|(% style="width:269px" %)((( 696 -*Hierarchical Codelist 697 -)))|(% style="width:453px" %)hierachicalCodelistAgencyId: 698 -hierarchicalCodelistId(version)|(% style="width:550px" %)((( 699 -UNESCO:CL_EXP_SOURCE(1.0(% style="background-color:transparent" %)) 724 +|*ConceptScheme|conceptSchemeAgencyId:conceptSchemeId(ve rsion)|SDMX:CROSS_DOMAIN_CONCEPTS(1.0) 725 +|Concept|((( 726 +conceptSchemeAgencyId: 727 + 728 +conceptSchemeId(version).conceptId 729 +)))|SDMX:CROSS_DOMAIN_CONCEPTS(1.0).FREQ 730 +|*Codelist|codeListAgencyId:codeListId(version)|SDMX:CL_FREQ(1.0) 731 +|Code|codeListAgencyId:codelistId(version).codeId|((( 732 +SDMX:CL_FREQ(1.0).Q 733 + 734 + 700 700 ))) 701 -|(% style="width:269px" %)Hierarchy|(% style="width:453px" %)((( 736 + 737 + 738 + 739 +|((( 740 +*Hierarchical 741 + 742 +Codelist 743 +)))|hierachicalCodelistAgencyId: hierarchicalCodelistId(version)|((( 744 +UNESCO:CL_EXP_SOURCE(1.0) 745 + 746 + 747 +))) 748 +|Hierarchy|((( 702 702 hierachicalcodeListAgencyId: 750 + 703 703 hierarchicalcodelistId(version).Hierarchy 704 -)))|(% style="width:550px" %)UNESCO:CL_EXP_SOURCE(1.0). 705 -H-C-GOV 706 -|(% style="width:269px" %)Level|(% style="width:453px" %)((( 752 +)))|UNESCO:CL_EXP_SOURCE(1.0). H-C-GOV 753 +|Level|((( 707 707 hierachicalcodeListAgencyId: 755 + 708 708 hierarchicalcodelistId(version).Hierarchy.Level 709 -)))|( % style="width:550px" %)(((757 +)))|((( 710 710 ESTAT:HCL_REGION(1.0).H_1.COUNTRY 759 + 760 + 711 711 ))) 712 -| (% style="width:269px" %)HierarchicalCode|(% style="width:453px" %)hierachicalCodeListAgencyId: hierarchicalcodelistId(version).hierarchy.hierarc hicalCode|(% style="width:550px" %)UNESCO:CL_EXP_SOURCE(1.0). H-C-GOV.GOV_CODE1713 -| (% style="width:269px" %)*DataStructure|(% style="width:453px" %)dataStructureDefintitionAgencyId: dataStructureDefintitionId(version)|(% style="width:550px" %)TFFS:EXT_DEBT(1.0)714 -|( % style="width:269px" %)(((762 +|HierarchicalCode|hierachicalCodeListAgencyId: hierarchicalcodelistId(version).hierarchy.hierarc hicalCode|UNESCO:CL_EXP_SOURCE(1.0). H-C-GOV.GOV_CODE1 763 +|*DataStructure|dataStructureDefintitionAgencyId: dataStructureDefintitionId(version)|TFFS:EXT_DEBT(1.0) 764 +|((( 715 715 Dimension 766 + 716 716 Descriptor 768 + 717 717 Measure 770 + 718 718 Descriptor 772 + 719 719 Attribute 774 + 720 720 Descriptor 721 -)))|( % style="width:453px" %)(((776 +)))|((( 722 722 dataStructureDefinitionAgencyId: dataStructureDefinitionId(version). 778 + 723 723 componentListId 780 + 724 724 where the componentListId is the name of the class (there is only one occurrence of each in the Data Structure Definition) 725 -)))|( % style="width:550px" %)(((782 +)))|((( 726 726 TFFS:EXT_DEBT(1.0).DimensionDescriptor 727 727 728 728 TFFS:EXT_DEBT(1.0).MeasureDescriptor ... ... @@ -729,209 +729,289 @@ 729 729 730 730 TFFS:EXT_DEBT(1.0).AttributeDescriptor 731 731 ))) 732 -|( % style="width:269px" %)(((789 +|((( 733 733 GroupDimension 791 + 734 734 Descriptor 735 -)))|( % style="width:453px" %)(((793 +)))|((( 736 736 dataStructureDefinitionAgencyId: dataStructureDefinitionId(version). 795 + 737 737 groupDimensionDescriptorId 738 -)))| (% style="width:550px" %)TFFS:EXT_DEBT(1.0).SIBLING739 -| (% style="width:269px" %)Dimension|(% style="width:453px" %)(((797 +)))|TFFS:EXT_DEBT(1.0).SIBLING 798 +|Dimension|((( 740 740 dataStructureDefinitionAgencyId: dataStructureDefinition (version). 800 + 741 741 dimensionId 742 -)))| (% style="width:550px" %)TFFS:EXT_DEBT(1.0).FREQ743 -| (% style="width:269px" %)TimeDimension|(% style="width:453px" %)(((802 +)))|TFFS:EXT_DEBT(1.0).FREQ 803 +|TimeDimension|((( 744 744 dataStructureDefinitionAgencyId: dataStructureDefinition (version). 805 + 745 745 timeDimensionId 746 -)))|(% style="width:550px" %)TFFS:EXT_DEBT(1.0).TIME_PERIOD 747 -|(% style="width:269px" %)Measure Dimension|(% style="width:453px" %)dataStructureDefinitionAgencyId: dataStructureDefinition (version). 748 -measureDimensionId|(% style="width:550px" %)TFFS:EXT_DEBT(1.0).STOCK_FLOW 749 -|(% style="width:269px" %)DataAttrribute|(% style="width:453px" %)dataStructureDefinitionAgencyId: dataStructureDefinition (version). dataAttributeId|(% style="width:550px" %)TFFS:EXT_DEBT(1.0).OBS_STATUS 750 -|(% style="width:269px" %)PrimaryMeasure|(% style="width:453px" %)((( 807 +)))|TFFS:EXT_DEBT(1.0).TIME_PERIOD 808 +|Measure Dimension|dataStructureDefinitionAgencyId: dataStructureDefinition (version).|TFFS:EXT_DEBT(1.0).STOCK_FLOW 809 + 810 + 811 + 812 +| |measureDimensionId| 813 +|DataAttrribute|dataStructureDefinitionAgencyId: dataStructureDefinition (version). dataAttributeId|TFFS:EXT_DEBT(1.0).OBS_STATUS 814 +|PrimaryMeasure|((( 751 751 dataStructureDefinitionAgencyId: dataStructureDefinition (version). 816 + 752 752 primaryMeasureId 753 -)))|(% style="width:550px" %)TFFS:EXT_DEBT(1.0).OBS_VALUE 754 -|(% style="width:269px" %)((( 755 -*Category Scheme 756 -)))|(% style="width:453px" %)categorySchemeAgencyId: 757 -categorySchemeId(version)|(% style="width:550px" %)IMF:SDDS(1.0) 758 -|(% style="width:269px" %)Category|(% style="width:453px" %)categorySchemeAgencyId: 759 -categorySchemeId(version). 760 -categoryId.categoryId categoryId.categoryId etc.|(% style="width:550px" %)((( 818 +)))|TFFS:EXT_DEBT(1.0).OBS_VALUE 819 +|((( 820 +*Category 821 + 822 +Scheme 823 +)))|categorySchemeAgencyId: categorySchemeId(version)|IMF:SDDS(1.0) 824 +|Category|categorySchemeAgencyId: categorySchemeId(version). categoryId.categoryId categoryId.categoryId etc.|((( 761 761 IMF:SDDS(1.0): 826 + 762 762 level_1_category.level_2_category … 763 763 ))) 764 -|(% style="width:269px" %)((( 765 -*Reporting Taxonomy 766 -)))|(% style="width:453px" %)reportingTaxonomyAgencyId: reportingTaxonomyId(version)|(% style="width:550px" %) IMF:REP_1(1.0) 767 -|(% style="width:269px" %)ReportingCategory|(% style="width:453px" %)reportingTaxonomyAgencyId: reportingTaxonomyId(version) reportingcategoryId.reportingcategoryId|(% style="width:550px" %)((( 829 +|((( 830 +*Reporting 831 + 832 +Taxonomy 833 +)))|reportingTaxonomyAgencyId: reportingTaxonomyId(version)| IMF:REP_1(1.0) 834 +|ReportingCategory|reportingTaxonomyAgencyId: reportingTaxonomyId(version) reportingcategoryId.reportingcategoryId|((( 768 768 IMF:REP_1(1.0): 836 + 769 769 level_1_repcategory.level_2_repcategory … 770 770 ))) 771 -|(% style="width:269px" %)*Categorisation|(% style="width:453px" %)categorisationAgencyId: categorisationId(version)|(% style="width:550px" %)IMF:cat001(1.0) 772 -|(% style="width:269px" %)((( 773 -*Organisation Unit Scheme 774 -)))|(% style="width:453px" %)organisationUnitSchemeAgencyId: organisationUnitSchemeId(version)|(% style="width:550px" %)ECB:ORGANISATIONS(1.0) 775 -|(% style="width:269px" %)Organisation Unit|(% style="width:453px" %)organisationUnitSchemeAgencyId: organisationUnitSchemeId(version). organisationUnitId|(% style="width:550px" %)ECB:ORGANISATIONS(1.0).1F 776 -|(% style="width:269px" %)*AgencyScheme|(% style="width:453px" %)agencySchemeAgencyId: agencySchemeId(version)|(% style="width:550px" %)ECB:AGENCIES(1.0) 839 +|*Categorisation|categorisationAgencyId: categorisationId(version)|IMF:cat001(1.0) 840 +|((( 841 +*Organisation 777 777 778 -(% style="width:1274.29px" %) 779 -|(% style="width:262px" %)Agency|(% style="width:369px" %)agencySchemeAgencyId: agencySchemeId(version). agencyId|(% style="width:535px" %)ECB:AGENCY(1.0).AA 780 -|(% style="width:262px" %)((( 781 -*DataProvider Scheme 782 -)))|(% style="width:369px" %)dataProviderSchemeAgencyId: dataProviderSchemeId(version)|(% style="width:535px" %)SDMX:DATA_PROVIDERS(1.0) 783 -|(% style="width:262px" %)DataProvider|(% style="width:369px" %)dataProviderSchemeAgencyId: dataProviderSchemeId(version) dataProviderId|(% style="width:535px" %)SDMX:DATA_PROVIDERS(1.0).PROVIDER_1 784 -|(% style="width:262px" %)((( 785 -*DataConsumer Scheme 786 -)))|(% style="width:369px" %)dataConsumerSchemeAgencyId: dataConsumerSchemeId(version)|(% style="width:535px" %)SDMX:DATA_CONSUMERS(1.0) 787 -|(% style="width:262px" %)Data Consumer|(% style="width:369px" %)dataConsumerSchemeAgencyId: dataConsumerSchemeId(version) dataConsumerId|(% style="width:535px" %)SDMX:DATA_CONSUMERS(1.0).CONSUMER_1 788 -|(% style="width:262px" %)((( 789 -*Metadata Structure 790 -)))|(% style="width:369px" %)MSDAgencyId:MSDId(version)|(% style="width:535px" %)IMF:SDDS_MSD(1.0) 791 -|(% style="width:262px" %)MetadataTarget|(% style="width:369px" %)((( 843 +Unit Scheme 844 +)))|organisationUnitSchemeAgencyId: organisationUnitSchemeId(version)|ECB:ORGANISATIONS(1.0) 845 +|Organisation Unit|organisationUnitSchemeAgencyId: organisationUnitSchemeId(version). organisationUnitId|ECB:ORGANISATIONS(1.0).1F 846 +|*AgencyScheme|agencySchemeAgencyId: agencySchemeId(version)|ECB:AGENCIES(1.0) 847 + 848 + 849 + 850 +|Agency|agencySchemeAgencyId: agencySchemeId(version). agencyId|ECB:AGENCY(1.0).AA 851 +|((( 852 +*DataProvider 853 + 854 +Scheme 855 +)))|dataProviderSchemeAgencyId: dataProviderSchemeId(version)|SDMX:DATA_PROVIDERS(1.0) 856 +|DataProvider|dataProviderSchemeAgencyId: dataProviderSchemeId(version) dataProviderId|SDMX:DATA_PROVIDERS(1.0).PROVIDER_1 857 +|((( 858 +*DataConsumer 859 + 860 +Scheme 861 +)))|dataConsumerSchemeAgencyId: dataConsumerSchemeId(version)|SDMX:DATA_CONSUMERS(1.0) 862 +|Data Consumer|dataConsumerSchemeAgencyId: dataConsumerSchemeId(version) dataConsumerId|SDMX:DATA_CONSUMERS(1.0).CONSUMER_1 863 +|((( 864 +*Metadata 865 + 866 +Structure 867 +)))|MSDAgencyId:MSDId(version)|IMF:SDDS_MSD(1.0) 868 +|MetadataTarget|((( 792 792 MSDAgencyId: 870 + 793 793 MSDId(version).metadataTargetId 794 -)))| (% style="width:535px" %)IMF:SDDS_MSD(1.0).AGENCY795 -|( % style="width:262px" %)(((872 +)))|IMF:SDDS_MSD(1.0).AGENCY 873 +|((( 796 796 Dimension 875 + 797 797 DescriptorValues 877 + 798 798 Target 799 -)))|( % style="width:369px" %)(((879 +)))|((( 800 800 MSDAgencyId: MSDId(version). 881 + 801 801 metadataTargetId.keyDescriptorValueTargetId 802 -)))|(% style="width:535px" %)IMF:SDDS_MSD(1.0).AGENCY.KEY 803 -|(% style="width:262px" %)Identifiable Object Target|(% style="width:369px" %)((( 804 -MSDAgencyId: MSDId(version).metadataTargetId.identifiableObjectTargetId 805 -)))|(% style="width:535px" %)IMF:SDDS_MSD(1.0).AGENCY.STR-OBJECT 806 -|(% style="width:262px" %)DataSetTarget|(% style="width:369px" %)((( 883 +)))|IMF:SDDS_MSD(1.0).AGENCY.KEY 884 +|Identifiable ObjectTarget|((( 807 807 MSDAgencyId: 808 -MSDId(version).metadataTargetId.dataSetTargetId 809 -)))|(% style="width:535px" %)IMF:SDDS_MSD(1.0).AGENCY.D1101 810 -|(% style="width:262px" %)PeportPeriod Target|(% style="width:369px" %)((( 811 -MSDAgencyId: MSDId(version).metadataTargetId.reportPeriodTargetId 812 -)))|(% style="width:535px" %)IMF:SDDS_MSD(1.0).AGENCY.REP_PER 813 813 814 -(% style="width:1277.29px" %) 815 -|(% style="width:270px" %)((( 887 +MSDId(version).metadataTargetId.identifiable 888 + 889 +ObjectTargetId 890 +)))|IMF:SDDS_MSD(1.0).AGENCY.STR-OBJECT 891 +|DataSetTarget|((( 892 +MSDAgencyId: 893 + 894 +MSDId(version).metadataTargetId.dataSet 895 + 896 +TargetId 897 +)))|IMF:SDDS_MSD(1.0).AGENCY.D1101 898 +|PeportPeriod Target|((( 899 +MSDAgencyId: 900 + 901 +MSDId(version).metadataTargetId.reportPeriod 902 + 903 +TargetId 904 +)))|IMF:SDDS_MSD(1.0).AGENCY.REP_PER 905 + 906 + 907 + 908 +|((( 816 816 ReportStructure 817 -)))|(% style="width:454px" %)((( 818 -MSDAgencyId: MSDId(version).reportStructureId 819 -)))|(% style="width:549px" %)IMF:SDDS_MSD(1.0).AGENCY_REPORT 820 -|(% style="width:270px" %)((( 821 -Metadata Attribute 822 -)))|(% style="width:454px" %)((( 823 -MSDAgencyId: MSDId(version).reportStructureId.metadataattri buteID 824 -)))|(% style="width:549px" %)IMF:SDDS_MSD(1.0).AGENCY_REPORT.COMPILATION 825 -|(% style="width:270px" %)*Dataflow|(% style="width:454px" %)dataflowAgencyId: dataflowId(version)|(% style="width:549px" %)TFFS:CRED_EXT_DEBT(1.0) 826 -|(% style="width:270px" %)*Provision Agreement|(% style="width:454px" %)((( 910 + 911 + 912 +)))|((( 913 +MSDAgencyId: 914 + 915 +MSDId(version).reportStructureId 916 +)))|IMF:SDDS_MSD(1.0).AGENCY_REPORT 917 +|((( 918 +Metadata 919 + 920 +Attribute 921 +)))|((( 922 +MSDAgencyId: 923 + 924 +MSDId(version).reportStructureId.metadataattri buteID 925 +)))|IMF:SDDS_MSD(1.0).AGENCY_REPORT.COMPILATION 926 +|*Dataflow|dataflowAgencyId: dataflowId(version)|TFFS:CRED_EXT_DEBT(1.0) 927 +|*Provision Agreement|((( 827 827 provisionAgreementAgencyId:provisionAgreem entId(version) 828 -)))|(% style="width:549px" %)((( 929 + 930 + 931 +)))|((( 829 829 TFFS:CRED_EXT_DEBT_AB(1.0) 933 + 934 + 935 + 830 830 ))) 831 -|(% style="width:270px" %)((( 832 -*Content Constraint 833 -)))|(% style="width:454px" %)constraintAgencyId:ContentConstraintId(versio n)|(% style="width:549px" %)TFFS:CREDITOR_DATA_CONTENT(1.0) 834 -|(% style="width:270px" %)((( 835 -*Attachment Constraint 836 -)))|(% style="width:454px" %)((( 937 +|((( 938 +*Content 939 + 940 +Constraint 941 +)))|constraintAgencyId:ContentConstraintId(versio n)|TFFS:CREDITOR_DATA_CONTENT(1.0) 942 +|((( 943 +*Attachment 944 + 945 +Constraint 946 +)))|((( 837 837 constraintAgencyId: 838 838 839 839 attachmentConstraintId(version) 840 -)))| (% style="width:549px" %)TFFS:CREDITOR_DATA_ATTACHMENT_CONSTRAINT_ONE(1.0)841 -| (% style="width:270px" %)*Metadataflow|(% style="width:454px" %)metadataflowAgencyId: metadataflowId(version)|(% style="width:549px" %)IMF:SDDS_FLOW(1.0)842 -| (% style="width:270px" %)*StructureSet|(%style="width:454px" %)structureSetAgencyId: structureSetId(version)|(% style="width:549px" %)SDMX:BOP_STRUCTURES(1.0)843 -| (% style="width:270px" %)StructureMap|(%style="width:454px" %)structureSetAgencyId: structureSetId(version). structureMapId|(% style="width:549px" %)SDMX:BOP_STRUCTURES(1.0).TABLE1_TABLE2844 -| (% style="width:270px" %)Component Map|(% style="width:454px" %)(((950 +)))|TFFS:CREDITOR_DATA_ATTACHMENT_CONSTRAINT_ONE(1.0) 951 +|*Metadataflow|metadataflowAgencyId: metadataflowId(version)|IMF:SDDS_FLOW(1.0) 952 +|*StructureSet|structureSetAgencyId: structureSetId(version)|SDMX:BOP_STRUCTURES(1.0) 953 +|StructureMap|structureSetAgencyId: structureSetId(version). structureMapId|SDMX:BOP_STRUCTURES(1.0).TABLE1_TABLE2 954 +|Component Map|((( 845 845 structureSetAgencyId: structureSetId(version). 846 846 847 847 structureMapId. componentMapId 848 -)))|(% style="width:549px" %)SDMX:BOP_STRUCTURES(1.0).TABLE1_TABLE2. REFAREA_REPCOUNTRY 849 -|(% style="width:270px" %)CodelistMap|(% style="width:454px" %)structureSetAgencyId: structureSetId(version). codelistMapId|(% style="width:549px" %)SDMX:BOP_STRUCTURES(1.0).CLREFAREA_CLREPCOUNTRY 850 -|(% style="width:270px" %)CodeMap|(% style="width:454px" %)structureSetAgencyId: structureSetId(version). 958 +)))|SDMX:BOP_STRUCTURES(1.0).TABLE1_TABLE2. REFAREA_REPCOUNTRY 959 +|CodelistMap|structureSetAgencyId: structureSetId(version). codelistMapId|SDMX:BOP_STRUCTURES(1.0).CLREFAREA_CLREPCOUNTRY 960 +|CodeMap|structureSetAgencyId: structureSetId(version).|SDMX:BOP_STRUCTURES(1.0).CLREFAREA_CLREPCOUNTRY. DE_GER 961 + 962 + 963 + 964 +| |((( 851 851 codeListMapId. 852 -codeMapId|(% style="width:549px" %)SDMX:BOP_STRUCTURES(1.0).CLREFAREA_CLREPCOUNTRY. DE_GER 853 853 854 -(% style="width:1279.29px" %) 855 -|(% style="width:271px" %)((( 856 -CategorySchemeMap 857 -)))|(% style="width:453px" %)structureSetAgencyId: structureSetId(version). categorySchemeMapId|(% style="width:551px" %)SDMX:BOP_STRUCTURES(1.0).SDMX_EUROSTAT 858 -|(% style="width:271px" %)CategoryMap|(% style="width:453px" %)structureSetAgencyId: structureSetId(version). categorySchemeMapId. categoryMapId|(% style="width:551px" %)SDMX:BOP_STRUCTURES(1.0).SDMX_EUROSTAT.TOURISM_MAP 859 -|(% style="width:271px" %)Organisation SchemeMap|(% style="width:453px" %)structureSetAgencyId: structureSetId(version). organisationSchemeMapId|(% style="width:551px" %)SDMX:BOP_STRUCTURES(1.0).DATA_PROVIDER_MAP 860 -|(% style="width:271px" %)Organisation Map|(% style="width:453px" %)structureSetAgencyId: structureSetId(version). organisationSchemeMapId. organisationMapId|(% style="width:551px" %)SDMX:BOP_STRUCTURES(1.0).DATA_PROVIDER_MAP.IMF_1C0 861 -|(% style="width:271px" %)((( 967 +codeMapId 968 +)))| 969 +|((( 970 +Category 971 + 972 +SchemeMap 973 +)))|structureSetAgencyId: structureSetId(version). categorySchemeMapId|SDMX:BOP_STRUCTURES(1.0).SDMX_EUROSTAT 974 +|CategoryMap|structureSetAgencyId: structureSetId(version). categorySchemeMapId. categoryMapId|SDMX:BOP_STRUCTURES(1.0).SDMX_EUROSTAT.TOURISM_M AP 975 +|Organisation SchemeMap|structureSetAgencyId: structureSetId(version). organisationSchemeMapId|SDMX:BOP_STRUCTURES(1.0).DATA_PROVIDER_MAP 976 +|Organisation Map|structureSetAgencyId: structureSetId(version). organisationSchemeMapId. organisationMapId|SDMX:BOP_STRUCTURES(1.0).DATA_PROVIDER_MAP.IMF_1C0 977 +|((( 862 862 Concept 863 863 864 864 SchemeMap 865 -)))| (%style="width:453px" %)structureSetAgencyId: structureSetId(version). conceptSchemeMapId|(% style="width:551px" %)SDMX:BOP_STRUCTURES(1.0).SDMX_OECD866 -| (% style="width:271px" %)ConceptMap|(% style="width:453px" %)(((981 +)))|structureSetAgencyId: structureSetId(version). conceptSchemeMapId|SDMX:BOP_STRUCTURES(1.0).SDMX_OECD 982 +|ConceptMap|((( 867 867 structureSetAgencyId: structureSetId(version). conceptSchemeMapId. 984 + 868 868 conceptMapId 869 -)))|(% style="width:551px" %)SDMX:BOP_STRUCTURES(1.0).SDMX_OECD.COVERAGE_AVAI LABILITY 870 -|(% style="width:271px" %)((( 871 -ReportingTaxonomyMap 872 -)))|(% style="width:453px" %)structureSetAgencyId: structureSetId(version). reportingTaxonomyMapId|(% style="width:551px" %)SDMX:BOP_STRUCTURES(1.0).TAXMAP 873 -|(% style="width:271px" %)((( 874 -ReportingCategoryMap 875 -)))|(% style="width:453px" %)((( 986 + 987 + 988 +)))|SDMX:BOP_STRUCTURES(1.0).SDMX_OECD.COVERAGE_AVAI LABILITY 989 +|((( 990 +Reporting 991 + 992 +TaxonomyMap 993 +)))|structureSetAgencyId: structureSetId(version). reportingTaxonomyMapId|SDMX:BOP_STRUCTURES(1.0).TAXMAP 994 +|((( 995 +Reporting 996 + 997 +CategoryMap 998 +)))|((( 876 876 structureSetAgencyId: structureSetId(version). 1000 + 877 877 reportngCategoryId 878 -)))| (% style="width:551px" %)SDMX:BOP_STRUCTURES(1.0).TAXMAP.TOPCAT1002 +)))|SDMX:BOP_STRUCTURES(1.0).TAXMAP.TOPCAT 879 879 880 -(% style="width:1282.29px" %) 881 -|(% style="width:272px" %)((( 882 -HybridCodelistMap 883 -)))|(% style="width:450px" %)structureSetAgencyId: structureSetId(version). 884 -hybridCodelistMapId.|(% style="width:557px" %)SDMX:BOP_STRUCTURES(1.0).COUNTRY_HIERARCHYMAP 885 -|(% style="width:272px" %)HybridCodeMap|(% style="width:450px" %)structureSetAgencyId: structureSetId(version). hybridCodelistMapId. hybridCodeMapId|(% style="width:557px" %)SDMX:BOP_STRUCTURES(1.0).COUNTRY_HIERARCHYMAP.CO DEMAP1 886 -|(% style="width:272px" %)*Process|(% style="width:450px" %)processAgencyId: processId{version]|(% style="width:557px" %)BIS:PROCESS1(1.0) 887 -|(% style="width:272px" %)ProcessStep|(% style="width:450px" %)((( 1004 + 1005 + 1006 +|((( 1007 +HybridCodelist 1008 + 1009 +Map 1010 +)))|structureSetAgencyId: structureSetId(version). hybridCodelistMapId.|SDMX:BOP_STRUCTURES(1.0).COUNTRY_HIERARCHYMAP 1011 +|HybridCodeMap|structureSetAgencyId: structureSetId(version). hybridCodelistMapId. hybridCodeMapId|SDMX:BOP_STRUCTURES(1.0).COUNTRY_HIERARCHYMAP.CO DEMAP1 1012 +|*Process|processAgencyId: processId{version]|BIS:PROCESS1(1.0) 1013 +|ProcessStep|((( 888 888 processAgencyId: processId(version). 1015 + 889 889 processStepId 890 -)))| (% style="width:557px" %)BIS:PROCESS1(1.0).STEP1891 -| (% style="width:272px" %)Transition|(% style="width:450px" %)(((1017 +)))|BIS:PROCESS1(1.0).STEP1 1018 +|Transition|((( 892 892 processAgencyId: processId(version). 1020 + 893 893 processStepId transitionId 894 -)))|(% style="width:557px" %)BIS:PROCESS1(1.0).STEP1.TRANSITION1 895 -|(% style="width:272px" %)Subscription|(% style="width:450px" %)The Subscription is not itself an Identifiable Artefact and therefore it does not follow the rules for URN structure, The name of the URN is registryURN There is no pre-determined format.|(% style="width:557px" %)This cannot be generated by a common mechanism as subscriptions, although maintainable in the sense that they can be submitted and deleted, are not mandated to be created by a maintenance agency, and have no versioning mechanism. It is therefore the responsibility of the target registry to generate a unique Id for the Subscription, and for the application creating the subscription to store the registryURN that is returned from the registry in the subscription response message. 896 -|(% style="width:272px" %)((( 897 -*Transformation Scheme 898 -)))|(% style="width:450px" %)transformationSchemeAgencyId transformationSchemeId(version)|(% style="width:557px" %)ECB: TRANSFORMATION_SCHEME(1.0) 899 -|(% style="width:272px" %)Transformation|(% style="width:450px" %)((( 1022 +)))|BIS:PROCESS1(1.0).STEP1.TRANSITION1 1023 +|Subscription|The Subscription is not itself an Identifiable Artefact and therefore it does not follow the rules for URN structure, The name of the URN is registryURN There is no pre-determined format.|This cannot be generated by a common mechanism as subscriptions, although maintainable in the sense that they can be submitted and deleted, are not mandated to be created by a maintenance agency, and have no versioning mechanism. It is therefore the responsibility of the target registry to generate a unique Id for the Subscription, and for the application creating the subscription to store the registryURN that is returned from the registry in the subscription response message. 1024 +|((( 1025 +*Transformation 1026 + 1027 +Scheme 1028 +)))|transformationSchemeAgencyId transformationSchemeId(version)|ECB: TRANSFORMATION_SCHEME(1.0) 1029 +|Transformation|((( 900 900 transformationSchemeAgencyId transformationSchemeId(version) 1031 + 901 901 transformationId 902 -)))| (% style="width:557px" %)ECB:TRANSFORMATION_SCHEME(1.0).TRANS_1903 -| (% style="width:272px" %)CustomType Scheme|(% style="width:450px" %)customTypeSchemeAgencyId customTypeSchemeId(version)|(% style="width:557px" %)ECB:CUSTOM_TYPE_SCHEME(1.0)1033 +)))|ECB:TRANSFORMATION_SCHEME(1.0).TRANS_1 1034 +|CustomType Scheme|customTypeSchemeAgencyId customTypeSchemeId(version)|ECB:CUSTOM_TYPE_SCHEME(1.0) 904 904 905 -(% style="width:1281.29px" %) 906 -|(% style="width:275px" %)CustomType|(% style="width:450px" %)customTypeSchemeAgencyId customTypeSchemeId(version) customTypeId|(% style="width:552px" %)ECB: CUSTOM_TYPE_SCHEME(1.0).CUSTOM_TYPE_1 907 -|(% style="width:275px" %)((( 1036 + 1037 + 1038 +|CustomType|customTypeSchemeAgencyId customTypeSchemeId(version) customTypeId|ECB: CUSTOM_TYPE_SCHEME(1.0).CUSTOM_TYPE_1 1039 +|((( 908 908 Name 1041 + 909 909 Personalisation 1043 + 910 910 Scheme 911 -)))| (% style="width:450px" %)namePersonalisationSchemeAgencyId namePersonalisationSchemeId(version)|(% style="width:552px" %)ECB:PSN_SCHEME(1.0)912 -|( % style="width:275px" %)(((1045 +)))|namePersonalisationSchemeAgencyId namePersonalisationSchemeId(version)|ECB:PSN_SCHEME(1.0) 1046 +|((( 913 913 Name 1048 + 914 914 Personalisation 915 -)))|(% style="width:450px" %)namePersonalisationSchemeAgencyId namePersonalisationSchemeId(version) 916 -namePersonalisationId|(% style="width:552px" %)ECB:PSN_SCHEME(1.0).PSN1234 917 -|(% style="width:275px" %)VtlMapping Scheme|(% style="width:450px" %)vtlMappingSchemeAgencyId VtlMappingSchemeId(version)|(% style="width:552px" %)ECB:CLIST_MP(2.0) 918 -|(% style="width:275px" %)VtlCodelist Mapping|(% style="width:450px" %)vtlMappingSchemeAgencyId vtlMappingSchemeId(version) vtlCodelistMappingId|(% style="width:552px" %)ECB:CLIST_MP(2.0).ABZ 919 -|(% style="width:275px" %)VtlConcept Mapping|(% style="width:450px" %)vtlMappingSchemeAgencyId vtlMappingSchemeId(version) vtlConceptMappingId|(% style="width:552px" %)ECB:CLIST_MP(1.0).XYA 920 -|(% style="width:275px" %)VtlDataflow Mapping|(% style="width:450px" %)vtlMappingSchemeAgencyId vtlMappingSchemeId(version) vtlDataflowMappingId|(% style="width:552px" %)ECB:CLIST_MP(1.0).MOQ 921 -|(% style="width:275px" %)((( 1050 +)))|namePersonalisationSchemeAgencyId namePersonalisationSchemeId(version) namePersonalisationId|ECB:PSN_SCHEME(1.0).PSN1234 1051 +|VtlMapping Scheme|vtlMappingSchemeAgencyId VtlMappingSchemeId(version)|ECB:CLIST_MP(2.0) 1052 +|VtlCodelist Mapping|vtlMappingSchemeAgencyId vtlMappingSchemeId(version) vtlCodelistMappingId|ECB:CLIST_MP(2.0).ABZ 1053 +|VtlConcept Mapping|vtlMappingSchemeAgencyId vtlMappingSchemeId(version) vtlConceptMappingId|ECB:CLIST_MP(1.0).XYA 1054 +|VtlDataflow Mapping|vtlMappingSchemeAgencyId vtlMappingSchemeId(version) vtlDataflowMappingId|ECB:CLIST_MP(1.0).MOQ 1055 +|((( 922 922 VtlConcept 923 923 924 924 SchemeMapping 925 -)))|(% style="width:450px" %)vtlMappingSchemeAgencyId vtlMappingSchemeId(version) vtlConceptSchemeId|(% style="width:552px" %)ECB:CLIST_MP(1.0).Z11 926 -|(% style="width:275px" %)RulesetScheme|(% style="width:450px" %)rulesetSchemeAgencyId rulesetSchemeId(version)|(% style="width:552px" %)ECB:RULESET_23(1.0) 927 -|(% style="width:275px" %)Ruleset|(% style="width:450px" %)rulesetSchemeAgencyId rulesetSchemeId(version) rulesetId|(% style="width:552px" %)ECB:RULESET_23(1.0).SET111 928 -|(% style="width:275px" %)((( 929 -UserDefinedOperatorScheme 930 -)))|(% style="width:450px" %)userDefinedOperatorSchemeAgencyId userDefinedOperatorSchemeId(version)|(% style="width:552px" %)ECB:OS_CALC(1.2) 931 -|(% style="width:275px" %)UserDefined Operator|(% style="width:450px" %)userDefinedOperatorSchemeAgencyId userDefinedOperatorSchemeId(version) usserDefinedOperatorId|(% style="width:552px" %)ECB:OS_CALC(1.2).OS267 1059 +)))|vtlMappingSchemeAgencyId vtlMappingSchemeId(version) vtlConceptSchemeId|ECB:CLIST_MP(1.0).Z11 1060 +|RulesetScheme|rulesetSchemeAgencyId rulesetSchemeId(version)|ECB:RULESET_23(1.0) 1061 +|Ruleset|rulesetSchemeAgencyId rulesetSchemeId(version) rulesetId|ECB:RULESET_23(1.0).SET111 1062 +|((( 1063 +UserDefined 932 932 933 -**Table 3: Table of identification components for SDMX Identifiable Artefacts** 1065 +OperatorScheme 1066 +)))|userDefinedOperatorSchemeAgencyId userDefinedOperatorSchemeId(version)|ECB:OS_CALC(1.2) 1067 +|UserDefined Operator|userDefinedOperatorSchemeAgencyId userDefinedOperatorSchemeId(version) usserDefinedOperatorId|ECB:OS_CALC(1.2).OS267 934 934 1069 +7**Table 3: Table of identification components for SDMX Identifiable Artefacts** 1070 + 1071 + 935 935 = 7 Implementation Notes = 936 936 937 937 == 7.1 Structural Definition Metadata == ... ... @@ -952,72 +952,109 @@ 952 952 953 953 The following table lists the Maintainable Artefacts. 954 954 955 -(% style="width:640.294px" %) 956 -|(% colspan="2" rowspan="1" style="width:186px" %)**Maintainable Artefacts**|(% style="width:206px" %)**Content** 957 -|(% style="width:171px" %)**Abstract Class**|(% style="width:232px" %)**Concrete Class**|(% style="width:206px" %) 958 -|(% style="width:171px" %)Item Scheme|(% style="width:232px" %)Codelist|(% style="width:206px" %)Code 959 -|(% style="width:171px" %) |(% style="width:232px" %)Concept Scheme|(% style="width:206px" %)Concept 960 -|(% style="width:171px" %) |(% style="width:232px" %)Category Scheme|(% style="width:206px" %)Category 961 -|(% style="width:171px" %) |(% style="width:232px" %)Organisation Unit Scheme|(% style="width:206px" %)Organisation Unit 962 -|(% style="width:171px" %) |(% style="width:232px" %)Agency Scheme|(% style="width:206px" %)Agency 963 -|(% style="width:171px" %) |(% style="width:232px" %)Data Provider Scheme|(% style="width:206px" %)Data Provider 964 -|(% style="width:171px" %) |(% style="width:232px" %)Data Consumer Scheme|(% style="width:206px" %)Data Consumer 965 -|(% style="width:171px" %) |(% style="width:232px" %)Reporting Taxonomy|(% style="width:206px" %)Reporting Category 966 -|(% style="width:171px" %) |(% style="width:232px" %)Transformation Scheme|(% style="width:206px" %)Transformation 967 -|(% style="width:171px" %) |(% style="width:232px" %)Custom Type Scheme|(% style="width:206px" %)Custom Type 968 -|(% style="width:171px" %) |(% style="width:232px" %)Name Personalisation Scheme|(% style="width:206px" %)Name Personalisation 969 -|(% style="width:171px" %) |(% style="width:232px" %)Vtl Mapping Scheme|(% style="width:206px" %)Vtl Codelist Mapping 970 -|(% style="width:171px" %) |(% style="width:232px" %) |(% style="width:206px" %)Vtl Dataflow Mapping 971 -|(% style="width:171px" %) |(% style="width:232px" %) |(% style="width:206px" %)Vtl Concept Scheme Mapping 972 -|(% style="width:171px" %) |(% style="width:232px" %)Ruleset Scheme|(% style="width:206px" %)Ruleset 973 -|(% style="width:171px" %) |(% style="width:232px" %)User Defined Operator Scheme|(% style="width:206px" %)User Defined Operator 974 -|(% style="width:171px" %) |(% style="width:232px" %) |(% style="width:206px" %)User Defined Operator 975 -|(% style="width:171px" %)Structure|(% style="width:232px" %)Data Structure Definition|(% style="width:206px" %)((( 1092 +|(% colspan="4" %)**Maintainable Artefacts**|(% colspan="2" %)**Content**| 1093 +|(% colspan="2" %)**Abstract Class**|(% colspan="2" %)**Concrete Class**|(% colspan="2" %) | 1094 +|(% colspan="2" %)Item Scheme|(% colspan="2" %)Codelist|(% colspan="2" %)Code| 1095 +|(% colspan="2" %) |(% colspan="2" %)Concept Scheme|(% colspan="2" %)Concept| 1096 +|(% colspan="2" %) |(% colspan="2" %)Category Scheme|(% colspan="2" %)Category| 1097 +|(% colspan="2" %) |(% colspan="2" %)Organisation Unit Scheme|(% colspan="2" %)Organisation Unit| 1098 +|(% colspan="2" %) |(% colspan="2" %)Agency Scheme|(% colspan="2" %)Agency| 1099 +|(% colspan="2" %) |(% colspan="2" %)Data Provider Scheme|(% colspan="2" %)Data Provider| 1100 +|(% colspan="2" %) |(% colspan="2" %)Data Consumer Scheme|(% colspan="2" %)Data Consumer| 1101 +|(% colspan="2" %) |(% colspan="2" %)Reporting Taxonomy|(% colspan="2" %)Reporting Category| 1102 +|(% colspan="2" %) |(% colspan="2" %)Transformation Scheme|(% colspan="2" %)Transformation| 1103 +|(% colspan="2" %) |(% colspan="2" %)Custom Type Scheme|(% colspan="2" %)Custom Type| 1104 +| |(% colspan="4" %)**Maintainable Artefacts**|(% colspan="2" %)**Content** 1105 +| |(% colspan="2" %)**Abstract Class**|(% colspan="2" %)**Concrete Class**|(% colspan="2" %) 1106 +| |(% colspan="2" %) |(% colspan="2" %)Name Personalisation Scheme|(% colspan="2" %)Name Personalisation 1107 +| |(% colspan="2" %) |(% colspan="2" %)Vtl Mapping Scheme|(% colspan="2" %)Vtl Codelist Mapping 1108 +| |(% colspan="2" %) |(% colspan="2" %) |(% colspan="2" %)Vtl Concept Mapping 1109 +| |(% colspan="2" %) |(% colspan="2" %) |(% colspan="2" %)Vtl Dataflow Mapping 1110 +| |(% colspan="2" %) |(% colspan="2" %) |(% colspan="2" %)((( 1111 +Vtl Concept Scheme 1112 + 1113 +Mapping 1114 +))) 1115 +| |(% colspan="2" %) |(% colspan="2" %)Ruleset Scheme|(% colspan="2" %)Ruleset 1116 +| |(% colspan="2" %) |(% colspan="2" %)User Defined Operator Scheme|(% colspan="2" %)User Defined Operator 1117 +| |(% colspan="2" %) |(% colspan="2" %) |(% colspan="2" %) 1118 +| |(% colspan="2" %)Structure|(% colspan="2" %)Data Structure Definition|(% colspan="2" %)((( 976 976 Dimension Descriptor 1120 + 977 977 Group Dimension 1122 + 978 978 Descriptor 1124 + 979 979 Dimension 1126 + 980 980 Measure Dimension 1128 + 981 981 Time Dimension 1130 + 982 982 Attribute Descriptor 1132 + 983 983 Data Attribute 1134 + 984 984 Measure Descriptor 1136 + 985 985 Primary Measure 986 986 ))) 987 -|(% style="width:171px" %) |(% style="width:232px" %)Metadata Structure Definition|(% style="width:206px" %)((( 988 -Metadata Target, Dimension Descriptor 1139 +| |(% colspan="2" %) |(% colspan="2" %)Metadata Structure Definition|(% colspan="2" %)((( 1140 +Metadata Target, 1141 + 1142 +Dimension Descriptor 1143 + 989 989 Values Target Identifiable 1145 + 990 990 Object Target 1147 + 991 991 Report Period Target 1149 + 992 992 Data SetTarget 1151 + 993 993 Report Structure 1153 + 994 994 Metadata Attribute 995 995 ))) 996 -|(% style="width:171px" %)Structure Usage|(%style="width:232px" %)Dataflow Definition|(%style="width:206px" %)997 -|(% style="width:171px" %) |(%style="width:232px" %)Metadataflow Definition|(%style="width:206px" %)998 -|(% style="width:171px" %)None|(%style="width:232px" %)Process|(%style="width:206px" %)Process Step999 -|(% style="width:171px" %)None|(%style="width:232px" %)Structure Set|(%style="width:206px" %)(((1156 +| |(% colspan="2" %)Structure Usage|(% colspan="2" %)Dataflow Definition|(% colspan="2" %) 1157 +| |(% colspan="2" %) |(% colspan="2" %)Metadataflow Definition|(% colspan="2" %) 1158 +| |(% colspan="2" %)None|(% colspan="2" %)Process|(% colspan="2" %)Process Step 1159 +| |(% colspan="2" %)None|(% colspan="2" %)Structure Set|(% colspan="2" %)((( 1000 1000 Component Map 1161 + 1001 1001 Concept Scheme Map 1163 + 1002 1002 Codelist Map 1165 + 1003 1003 Category Scheme Map 1167 + 1004 1004 Reporting Taxonomy Map 1169 + 1005 1005 Organisation Scheme Map 1171 + 1006 1006 Concept Map 1173 + 1007 1007 Code Map 1175 + 1008 1008 Category Map 1177 + 1009 1009 Organisation Map 1179 + 1010 1010 Reporting Category Map 1181 + 1011 1011 Hybrid Codelist Map 1183 + 1012 1012 Hybrid Code Map 1013 1013 ))) 1014 -|(% style="width:171px" %)None|(%style="width:232px" %)Provision Agreement|(%style="width:206px" %)1015 -|(% style="width:171px" %)None|(%style="width:232px" %)Hierarchical Codelist|(%style="width:206px" %)(((1186 +| |(% colspan="2" %)None|(% colspan="2" %)Provision Agreement|(% colspan="2" %) 1187 +| |(% colspan="2" %)None|(% colspan="2" %)Hierarchical Codelist|(% colspan="2" %)((( 1016 1016 Hierarchy 1189 + 1017 1017 Hierarchical Code 1018 1018 ))) 1192 +| | | | | | | 1019 1019 1020 -**able 4: Table of Maintainable Artefacts for Structural Definition Metadata** 1194 +**Table 4: Table of Maintainable Artefacts for Structural Definition Metadata** 1021 1021 1022 1022 === 7.1.2 Item Scheme, Structure === 1023 1023 ... ... @@ -1024,7 +1024,10 @@ 1024 1024 The artefacts included in the structural definitions are: 1025 1025 1026 1026 * All types of Item Scheme (Codelist, Concept Scheme, Category Scheme, Organisation Scheme - Agency Scheme, Data Provider Scheme, Data Consumer Scheme, Organisation Unit Scheme) 1027 -* All types of Structure (Data Structure Definition, Metadata Structure Definition) 1201 +* All types of Structure (Data Structure Definition, Metadata Structure 1202 + 1203 +Definition) 1204 + 1028 1028 * All types of Structure Usage (Dataflow Definition, Metadataflow Definition) 1029 1029 1030 1030 === 7.1.3 Structure Usage === ... ... @@ -1043,8 +1043,6 @@ 1043 1043 1044 1044 ==== 7.1.3.3 Structure Usage Model ==== 1045 1045 1046 -[[image:1747829078194-749.png]] 1047 - 1048 1048 **Figure 10: SDMX-IM of links from Structure Usage to Category** 1049 1049 1050 1050 In addition to the maintenance of the Dataflow Definition and the Metadataflow Definition the following links must be maintained in the registry: ... ... @@ -1071,10 +1071,10 @@ 1071 1071 1072 1072 An organisation which publishes statistical data or reference metadata and wishes to make it available to an SDMX enabled community is called a Data Provider. In terms of the SDMX Information Model, the Data Provider is maintained in a Data Provider Scheme. 1073 1073 1074 -[[image:1747829109466-595.png]] 1075 1075 1076 1076 **Figure 11: SDMX-IM of the Data Provider** 1077 1077 1252 + 1078 1078 Note that the Data Provider does not inherit the hierarchy association. The diagram below shows a logical schematic of the data model classes required to maintain provision agreements 1079 1079 1080 1080 [[image:1747824123019-181.jpeg]] ... ... @@ -1083,10 +1083,8 @@ 1083 1083 1084 1084 The diagram below is a logical representation of the data required in order to maintain Provision Agreements. 1085 1085 1086 -[[image:1747829139951-378.png]] 1087 1087 1088 -(% class="wikigeneratedid" id="HFigure13:LogicalclassdiagramoftheinformationcontainedintheProvisionAgreement" %) 1089 -**Figure 13: Logical class diagram of the information contained in the Provision Agreement** 1262 +==== Figure 13: Logical class diagram of the information contained in the Provision Agreement ==== 1090 1090 1091 1091 A Provision Agreement is structural metadata. Each Provision Agreement must reference a Data Provider and a Dataflow or Metadataflow Definition. The Data Provider and the Dataflow/Metadataflow Definition must exist already in order to set up a Provision Agreement. 1092 1092 ... ... @@ -1114,12 +1114,13 @@ 1114 1114 1115 1115 === 7.3.3 Data and Metadata Constraints: Model === 1116 1116 1117 -[[image:1747829204737-370.png]] 1118 1118 1119 -**Figure 15: Logical class diagram showing inheritance between and reference to constrainable artifacts** 1120 1120 1121 - The class diagramaboveshows that DataProvider, DataflowDefinition, MetadataflowDefinition, ProvisionAgreement,DataStructureDefinition, MetadataStructureDefinition, SimpleDatasource and QueryDatasourceare all concrete sub-classes of ConstrainableArtefactandcan thereforehave Constraints specified. Note that the actual Constraint as submitted is associatedtothe reference classes which inherit from ConstrainableRef:theseare usedto refer to the classes to whichthe Constraintapplies.1292 +==== Figure 15: Logical class diagram showing inheritance between and reference to constrainable artifacts ==== 1122 1122 1294 +The class diagram above shows that DataProvider, DataflowDefinition, MetadataflowDefinition, ProvisionAgreement, DataStructureDefinition, MetadataStructureDefinition, SimpleDatasource and QueryDatasource are all concrete sub-classes of ConstrainableArtefact and can therefore have Constraints specified. Note that the actual Constraint as submitted is associated to the reference classes which inherit from ConstrainableRef: these are used to refer to the classes to which the Constraint applies. 1295 + 1296 + 1123 1123 The content of the Constraint can be found in the SDMX Information Model document. 1124 1124 1125 1125 == 7.4 Data and Metadata Registration == ... ... @@ -1140,7 +1140,7 @@ 1140 1140 1141 1141 [[image:1747824123025-411.jpeg]] 1142 1142 1143 -**Figure 16: Schematic of the Objects Concerned with Registration** 1317 + **Figure 16: Schematic of the Objects Concerned with Registration** 1144 1144 1145 1145 ==== 7.4.2.2 Registration Request Model ==== 1146 1146 ... ... @@ -1154,14 +1154,11 @@ 1154 1154 1155 1155 The Registration has an action attribute which takes one of the following values: 1156 1156 1157 -(% style="width:970.294px" %) 1158 -|(% style="width:212px" %)**Action Attribute Value**|(% style="width:756px" %)**Behaviour** 1159 -|(% style="width:212px" %)Append|(% style="width:756px" %)Add this Registration to the registry 1160 -|(% style="width:212px" %)Replace|(% style="width:756px" %)Replace the existing Registration with identified by the id in the Registration of the Submit Registration Request 1161 -|(% style="width:212px" %)Delete|(% style="width:756px" %)Delete the existing Registration identified by the id in the Registration of the Submit Registration Request 1331 +|**Action Attribute Value**|**Behaviour** 1332 +|Append|Add this Registration to the registry 1333 +|Replace|Replace the existing Registration with identified by the id in the Registration of the Submit Registration Request 1334 +|Delete|Delete the existing Registration identified by the id in the Registration of the Submit Registration Request 1162 1162 1163 -[[image:1747829290890-122.png]] 1164 - 1165 1165 **Figure 17: Logical Class Diagram of Registration of Data and Metadata** 1166 1166 1167 1167 The Query Datasource is an abstract class that represents a data source which can understand an SDMX-ML query (SOAPDatasource) or RESTful query ... ... @@ -1176,19 +1176,25 @@ 1176 1176 1177 1177 Information in the data or metadata set is extracted and placed in one or more Content Constraints (see the Constraints model in the SDMX Information Model – Section 2 of the SDMX Standards). The information to be extracted is indicated by the Boolean values set on the Provision Agreement as shown in the table below. 1178 1178 1179 -|(% style="width:185px" %)**Indexing Required**|(% style="width:1686px" %)**Registration Process Activity** 1180 -|(% style="width:185px" %)indexTimeSeries|(% style="width:1686px" %)Extract all the series keys and create a KeySet(s) Constraint. 1181 -|(% style="width:185px" %)indexDataSet|(% style="width:1686px" %)((( 1182 -Extract all the codes and other content of the Key value of the Series Key in a Data Set and create one or more Cube Regions containing Member Selections of Dimension Components of the Constraints model in the SDMX-IM, and the associated Selection Value. 1350 +|**Indexing Required**|**Registration Process Activity** 1351 +|indexTimeSeries|Extract all the series keys and create a KeySet(s) Constraint. 1352 +|indexDataSet|((( 1353 +Extract all the codes and other content of the Key value of the Series Key in a Data Set and create one or more Cube 1354 + 1355 +Regions containing Member Selections of Dimension Components of the Constraints model in the SDMX-IM, and the associated Selection Value. 1183 1183 ))) 1184 -| (% style="width:185px" %)indexReportingPeriod|(% style="width:1686px" %)(((1357 +|indexReportingPeriod|((( 1185 1185 This applies only to a registered dataset. 1359 + 1186 1186 Extract the Reporting Begin and Reporting End from the Header of the Message containing the data set, and create a Reference Period constraint. 1187 1187 ))) 1188 -| (% style="width:185px" %)indexAttributes|(% style="width:1686px" %)(((1362 +|indexAttributes|((( 1189 1189 **Data Set** 1364 + 1190 1190 Extract the content of the Attribute Values in a Data Set and create one or more Cube Regions containing Member Selections of Data Attribute Components of the Constraints model in the SDMXIM, and the associated Selection Value 1366 + 1191 1191 **Metadata Set** 1368 + 1192 1192 Indicate the presence of a Reported Attribute by creating one or more Cube Regions containing Member Selections of Metadata Attribute Components of the Constraints model in the SDMX-IM. Note that the content is not stored in the Selection Value. 1193 1193 ))) 1194 1194 ... ... @@ -1198,13 +1198,14 @@ 1198 1198 1199 1199 === 7.4.3 Registration Response === 1200 1200 1201 -After a registration request has been submitted to the registry, a response is returned to the submitter indicating success or failure. Given that a registration request can hold many Registrations, then there must be a registration status for each Registration. The Submit Registration class has a status field which is either set to “Success”, “Warning” or “Failure”.1378 +After a registration request has been submitted to the registry, a response is returned to the submitter indicating success or failure. Given that a registration request can hold many Registrations, then there must be a registration status for each Registration. The Submit Registration class has a status field which is either set to 1202 1202 1380 +“Success”, “Warning” or “Failure”. 1381 + 1203 1203 If the registration has succeeded, a Registration will be returned - this holds the Registry-allocated Id of the newly registered Datasource plus a Datasource holding the URL to access the dataset, metadataset, or query service. 1204 1204 1205 1205 The Registration Response returns set of registration status (one for each registration submitted) in terms of a Status Message (this is common to all Registry Responses) that indicates success or failure. In the event of registration failure, a set of Message Text are returned, giving the error messages that occurred during registration. It is entirely possible when registering a batch of datasets, that the response will contain some successful and some failed statuses. The logical model for the Registration Response is shown below: 1206 1206 1207 -[[image:1747829477882-750.png]] 1208 1208 1209 1209 **Figure 18: Logical class diagram showing the registration response** 1210 1210 ... ... @@ -1214,12 +1214,15 @@ 1214 1214 1215 1215 A user can submit a subscription in the registry that defines which events are of interest, and either an email and/or an HTTP address to which a notification of qualifying events will be delivered. The subscription will be identified in the registry by a URN which is returned to the user when the subscription is created. If the user wants to delete the subscription at a later point, the subscription URN is used as identification. Subscriptions have a validity period expressed as a date range (startDate, endDate) and the registry may delete any expired subscriptions, and will notify the subscriber on expiry. 1216 1216 1217 -When a registry/repository artefact is modified, any subscriptions which are observing the object are activated, and either an email or HTTP POST is instigated to report details of the changes to the user specified in the subscription. This is called a “notification”.1395 +When a registry/repository artefact is modified, any subscriptions which are observing the object are activated, and either an email or HTTP POST is instigated to report details of the changes to the user specified in the subscription. This is called a 1218 1218 1219 - === 7.5.1SubscriptionLogical Class Diagram ===1397 +“notification”. 1220 1220 1221 - [[image:1747829554603-150.png]]1399 + 7.5.1Subscription Logical Class Diagram 1222 1222 1401 + 1402 +[[image:1747824123028-257.png]] 1403 + 1223 1223 **Figure 19: Logical Class Diagram of the Subscription** 1224 1224 1225 1225 === 7.5.2 Subscription Information === ... ... @@ -1226,58 +1226,73 @@ 1226 1226 1227 1227 Regardless of the type of registry/repository events being observed, a subscription always contains: 1228 1228 1229 -1. A set of URIs describing the end-points to which notifications must be sent if the subscription is activated. The URIs can be either mailto~: or http: protocol. In the former case an email notification is sent; in the latter an HTTP POST notification is sent. 1230 -1. A user-defined identifier which is returned in the response to the subscription request. This helps with asynchronous processing and is NOT stored in the Registry. 1231 -1. A validity period which defines both when the subscription becomes active and expires. The subscriber may be sent a notification on expiration of the subscription. 1232 -1. A selector which specifies which type of events are of interest. The set of event types is: 1410 +~1. A set of URIs describing the end-points to which notifications must be sent if the subscription is activated. The URIs can be either mailto~: or http: protocol. In the former case an email notification is sent; in the latter an HTTP POST notification is sent. 1233 1233 1234 -|(% style="width:319px" %)**Event Type**|(% style="width:1553px" %)**Comment** 1235 -|(% style="width:319px" %)STRUCTURAL_REPOSITORY_EVENTS|(% style="width:1553px" %)Life-cycle changes to Maintainable Artefacts in the structural metadata repository. 1236 -|(% style="width:319px" %)DATA_REGISTRATION_EVENTS|(% style="width:1553px" %)Whenever a published dataset is registered. This can be either a SDMXML data file or an SDMX conformant database. 1237 -|(% style="width:319px" %)METADATA_REGISTRATION_EVENTS|(% style="width:1553px" %)Whenever a published metadataset is registered. This can be either a SDMXML reference metadata file or an SDMX conformant database. 1238 -|(% style="width:319px" %)ALL_EVENTS|(% style="width:1553px" %)All events of the specified EventType 1412 +2. A user-defined identifier which is returned in the response to the subscription request. This helps with asynchronous processing and is NOT stored in the Registry. 1239 1239 1414 +3. A validity period which defines both when the subscription becomes active and expires. The subscriber may be sent a notification on expiration of the subscription. 1415 + 1416 +4. A selector which specifies which type of events are of interest. The set of event types is: 1417 + 1418 +|**Event Type**|**Comment** 1419 +|STRUCTURAL_REPOSITORY_EVENTS|Life-cycle changes to Maintainable Artefacts in the structural metadata repository. 1420 +|DATA_REGISTRATION_EVENTS|Whenever a published dataset is registered. This can be either a SDMXML data file or an SDMX conformant database. 1421 +|METADATA_REGISTRATION_EVENTS|Whenever a published metadataset is registered. This can be either a SDMXML reference metadata file or an SDMX conformant database. 1422 +|ALL_EVENTS|All events of the specified EventType 1423 + 1240 1240 === 7.5.3 Wildcard Facility === 1241 1241 1242 1242 Subscription notification supports wildcarded identifier components URNs, which are identiiers which have some or all of their component parts replaced by the wildcard character `%`. Identifier components comprise: 1243 1243 1244 -* agencyID 1245 -* id 1246 -* version 1428 + agencyID 1247 1247 1430 + id 1431 + 1432 + version 1433 + 1248 1248 Examples of wildcarded identifier components for an identified object type of Codelist are shown below. 1249 1249 1250 -//AgencyID = % 1436 +AgencyID = % 1437 + 1251 1251 Id = % 1252 -Version = %// 1253 1253 1440 +Version = % 1441 + 1254 1254 This subscribes to all Codelists of all versions for all agencies. 1255 1255 1256 -//AgencyID = AGENCY1 1444 +AgencyID = AGENCY1 1445 + 1257 1257 Id = CODELIST1 1258 -Version = %// 1259 1259 1448 +Version = % 1449 + 1260 1260 This subscribes to all versions of Codelist CODELIST1 maintained by the agency 1261 1261 1262 -//AGENCY1 1452 +AGENCY1 1453 + 1263 1263 AgencyID = AGENCY1 1455 + 1264 1264 Id = % 1265 -Version = %// 1266 1266 1458 +Version = % 1459 + 1267 1267 This subscribes to all versions of all Codelist objects maintained by the agency 1268 1268 1269 -//AGENCY1 1462 +AGENCY1 1463 + 1270 1270 AgencyID = % 1465 + 1271 1271 Id = CODELIST1 1272 -Version = %// 1273 1273 1468 +Version = % 1469 + 1274 1274 This subscribes to all versions of Codelist CODELIST1 maintained by the agency 1275 1275 1276 - //AGENCY1//1472 +AGENCY1 1277 1277 1278 1278 Note that if the subscription is to the latest version then this can be achieved by the * character 1279 1279 1280 - //i.e. Version = *//1476 +i.e. Version = * 1281 1281 1282 1282 Note that a subscription using the URN mechanism cannot use wildcard characters. 1283 1283 ... ... @@ -1289,15 +1289,16 @@ 1289 1289 1290 1290 Whenever a dataset or metadata-set is registered a registration event is created. A subscription may be observing all data or metadata registrations, or it may focus on specific registrations as shown in the table below: 1291 1291 1292 -|(% style="width:405px" %)**Selector**|(% style="width:1467px" %)**Comment** 1293 -|(% style="width:405px" %)DataProvider|(% style="width:1467px" %)Any datasets or metadata sets registered by the specified data provider will activate the notification. 1294 -|(% style="width:405px" %)ProvisionAgreement|(% style="width:1467px" %)Any datasets or metadata sets registered for the provision agreement will activate the notification. 1295 -|(% style="width:405px" %)Dataflow (&Metadataflow)|(% style="width:1467px" %)Any datasets or metadata sets registered for the specified dataflow (or metadataflow) will activate the notification. 1296 -|(% style="width:405px" %)DataStructureDefinition & MetadataStructureDefinition|(% style="width:1467px" %)Any datasets or metadata sets registered for those dataflows (or metadataflows) that are based on the specified Data Structure Definition will 1297 -|(% style="width:405px" %)**Selector**|(% style="width:1467px" %)**Comment** 1298 -|(% style="width:405px" %) |(% style="width:1467px" %)activate the notification. 1299 -|(% style="width:405px" %)Category|(% style="width:1467px" %)Any datasets or metadata sets registered for those dataflows, metadataflows, provision agreements that are categorised by the category. 1300 1300 1489 +|**Selector**|**Comment** 1490 +|DataProvider|Any datasets or metadata sets registered by the specified data provider will activate the notification. 1491 +|ProvisionAgreement|Any datasets or metadata sets registered for the provision agreement will activate the notification. 1492 +|Dataflow (&Metadataflow)|Any datasets or metadata sets registered for the specified dataflow (or metadataflow) will activate the notification. 1493 +|DataStructureDefinition & MetadataStructureDefinition|Any datasets or metadata sets registered for those dataflows (or metadataflows) that are based on the specified Data Structure Definition will 1494 +|**Selector**|**Comment** 1495 +| |activate the notification. 1496 +|Category|Any datasets or metadata sets registered for those dataflows, metadataflows, provision agreements that are categorised by the category. 1497 + 1301 1301 The event will also capture the semantic of the registration: deletion or replacement of an existing registration or a new registration. 1302 1302 1303 1303 == 7.6 Notification == ... ... @@ -1304,10 +1304,8 @@ 1304 1304 1305 1305 === 7.6.1 Logical Class Diagram === 1306 1306 1307 -[[image:1747829675568-610.png]] 1308 1308 1309 -(% class="wikigeneratedid" id="HFigure20:LogicalClassDiagramoftheNotification" %) 1310 -**Figure 20: Logical Class Diagram of the Notification** 1505 +==== Figure 20: Logical Class Diagram of the Notification ==== 1311 1311 1312 1312 A notification is an XML document that is sent to a user via email or http POST whenever a subscription is activated. It is an asynchronous one-way message. 1313 1313 ... ... @@ -1327,3 +1327,5 @@ 1327 1327 === 7.6.3 Registration Event Component === 1328 1328 1329 1329 The notification will contain the Registration. 1525 + 1526 +
- 1747824504225-229.png
-
- Author
-
... ... @@ -1,1 +1,0 @@ 1 -xwiki:XWiki.helena - Size
-
... ... @@ -1,1 +1,0 @@ 1 -52.8 KB - Content
- 1747829078194-749.png
-
- Author
-
... ... @@ -1,1 +1,0 @@ 1 -xwiki:XWiki.helena - Size
-
... ... @@ -1,1 +1,0 @@ 1 -40.4 KB - Content
- 1747829109466-595.png
-
- Author
-
... ... @@ -1,1 +1,0 @@ 1 -xwiki:XWiki.helena - Size
-
... ... @@ -1,1 +1,0 @@ 1 -30.4 KB - Content
- 1747829139951-378.png
-
- Author
-
... ... @@ -1,1 +1,0 @@ 1 -xwiki:XWiki.helena - Size
-
... ... @@ -1,1 +1,0 @@ 1 -21.1 KB - Content
- 1747829204737-370.png
-
- Author
-
... ... @@ -1,1 +1,0 @@ 1 -xwiki:XWiki.helena - Size
-
... ... @@ -1,1 +1,0 @@ 1 -55.8 KB - Content
- 1747829290890-122.png
-
- Author
-
... ... @@ -1,1 +1,0 @@ 1 -xwiki:XWiki.helena - Size
-
... ... @@ -1,1 +1,0 @@ 1 -41.4 KB - Content
- 1747829477882-750.png
-
- Author
-
... ... @@ -1,1 +1,0 @@ 1 -xwiki:XWiki.helena - Size
-
... ... @@ -1,1 +1,0 @@ 1 -24.6 KB - Content
- 1747829554603-150.png
-
- Author
-
... ... @@ -1,1 +1,0 @@ 1 -xwiki:XWiki.helena - Size
-
... ... @@ -1,1 +1,0 @@ 1 -99.1 KB - Content
- 1747829675568-610.png
-
- Author
-
... ... @@ -1,1 +1,0 @@ 1 -xwiki:XWiki.helena - Size
-
... ... @@ -1,1 +1,0 @@ 1 -31.1 KB - Content
- 1747832400104-286.png
-
- Author
-
... ... @@ -1,1 +1,0 @@ 1 -xwiki:XWiki.helena - Size
-
... ... @@ -1,1 +1,0 @@ 1 -172.3 KB - Content
- 1747994320263-112.png
-
- Author
-
... ... @@ -1,1 +1,0 @@ 1 -xwiki:XWiki.helena - Size
-
... ... @@ -1,1 +1,0 @@ 1 -13.9 KB - Content