Changes for page SDMX 2.1 Standards. Section 5. Registry Specification: Logical Interfaces

Summary

• Page properties (1 modified, 0 added, 0 removed)
• Attachments (0 modified, 9 added, 0 removed)
  • 1747824504225-229.png
  • 1747829078194-749.png
  • 1747829109466-595.png
  • 1747829139951-378.png
  • 1747829204737-370.png
  • 1747829290890-122.png
  • 1747829477882-750.png
  • 1747829554603-150.png
  • 1747829675568-610.png

Details

Page properties

Content

...	...	@@ -192,10 +192,8 @@
192	192
193	193	In addition to these interfaces the registry must support a mechanism for querying for structural metadata. This is detailed in 5.2.2.
194	194
195		-All these interactions with the Registry – with the exception of Notify Registry Event – are designed in pairs. The first document – the one which invokes the SDMX-RR interface, is a “Request” document. The message returned by the interface is a
	195	+All these interactions with the Registry – with the exception of Notify Registry Event – are designed in pairs. The first document – the one which invokes the SDMX-RR interface, is a “Request” document. The message returned by the interface is a “Response” document.
196	196
197		-“Response” document.
198		-
199	199	It should be noted that all interactions are assumed to be synchronous, with the exception of Notify Registry Event. This document is sent by the SDMX-RR to all subscribers whenever an even occurs to which any users have subscribed. Thus, it does not conform to the request-response pattern, because it is inherently asynchronous.
200	200
201	201	== 5.2 Registry Services ==
...	...	@@ -290,38 +290,33 @@
290	290	* that a queryable data source exists - this would necessitate the registration service querying the service to determine its existence
291	291	* that a simple data source exists (i.e. a file accessible at a URL)
292	292	* 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
293		-*  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
	291	+* 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
294	294
295	295	3The Registration has an action attribute which takes one of the following values:
296	296
297		-|(((
298		-**Action**
299		-
300		-**Attribute Value**
301		-)))|**Behaviour**
302		-|Append|Add this registration to the registry
303		-|Replace|Replace the existing Registration with this Registration identified by the id in the Registration of the Submit Registration Request
304		-|Delete|Delete the existing Registration identified by the id in the Registration of the Submit Registration Request
305		-
	295	+(% style="margin-left:auto; margin-right:auto" %)
	296	+|(% style="width:200px" %)(((
	297	+**Action Attribute Value**
	298	+)))|(% style="width:1672px" %)**Behaviour**
	299	+|(% style="width:200px" %)Append|(% style="width:1672px" %)Add this registration to the registry
	300	+|(% style="width:200px" %)Replace|(% style="width:1672px" %)Replace the existing Registration with this Registration identified by the id in the Registration of the Submit Registration Request
	301	+|(% style="width:200px" %)Delete|(% style="width:1672px" %)Delete the existing Registration identified by the id in the Registration of the Submit Registration Request
306	306	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:
307		-
308		-|**Boolean Attribute**|**Behaviour if Value is “true”**
309		-|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)
310		-|indexDataSet|(((
	303	+|(% style="width:200px" %)**Boolean Attribute**|(% style="width:1672px" %)**Behaviour if Value is “true”**
	304	+|(% style="width:200px" %)indexTimeSeries|(% style="width:1672px" %)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:200px" %)indexDataSet|(% style="width:1672px" %)(((
311	311	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.
312		-
313	313	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
314	314	)))
315		-|indexReportingPeriod|A compliant indexing application must index the time period range(s) for which data are present in the Dataset or Metadata Set
	309	+|(% style="width:200px" %)indexReportingPeriod|(% style="width:1672px" %)A compliant indexing application must index the time period range(s) for which data are present in the Dataset or Metadata Set
316	316
317	317	=== 5.2.5 Data and Reference Metadata Discovery ===
318	318
319	319	The Data and Metadata Discovery Service implements the following Registry Interfaces:
320	320
321		- QueryRegistrationRequest
	315	+* QueryRegistrationRequest
	316	+* QueryRegistrationResponse
322	322
323		- QueryRegistrationResponse
324		-
325	325	=== 5.2.6 Subscription and Notification ===
326	326
327	327	The Subscription and Notification Service implements the following Registry Interfaces:
...	...	@@ -345,13 +345,12 @@
345	345
346	346	The following table defines the behaviour of the SDMX Registry for the various Registry Interface messages.
347	347
348		-|**Interface**|**Behaviour**
349		-|All|(((
	341	+|(% style="width:227px" %)**Interface**|(% style="width:1644px" %)**Behaviour**
	342	+|(% style="width:227px" %)All|(% style="width:1644px" %)(((
350	350	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:
351	351
352	352	* Name – this applies to the Maintainable object and its contained elements, such a Code in a Code list.
353	353	* Description - this applies to the Maintainable object and its contained elements, such a Code in a Code list.
354		-
355	355	* Annotation - this applies to the Maintainable object and its contained elements, such a Code in a Code list.
356	356	* validTo
357	357	* validFrom
...	...	@@ -360,26 +360,22 @@
360	360	* uri
361	361	* isExternalReference
362	362
363		-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.
364		-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	+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.
	356	+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:
365	365
366		-1. Not have the final attribute set to “true”
367		-1. Not be referenced from any other object in the Registry.
	358	+а) Not have the final attribute set to “true”
	359	+b) Not be referenced from any other object in the Registry.
368	368
369		-1. The version rules in the SDMX Schema documentation MUST be obeyed.
370		-
371		-* The specific rules for the elements and attributes documented in the SDMX Schema MUST be obeyed.
	361	+4) The version rules in the SDMX Schema documentation MUST be obeyed.
	362	+5) The specific rules for the elements and attributes documented in the SDMX Schema MUST be obeyed.
372	372	)))
373		-|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.
374		-|SubmitProvisioningRequest|No additional behaviour.
375		-|Submit Registration Request|(((
	364	+|(% 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.
	365	+|(% style="width:227px" %)SubmitProvisioningRequest|(% style="width:1644px" %)No additional behaviour.
	366	+|(% style="width:227px" %)Submit Registration Request|(% style="width:1644px" %)(((
376	376	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.
377		-
378	378	For a queryable datasource the Registry MAY validate that the source exists and can accept an SDMX-ML data query.
379	379	)))
380	380
381		-
382		-
383	383	= 6 Identification of SDMX Objects =
384	384
385	385	== 6.1 Identification, Versioning, and Maintenance ==
...	...	@@ -386,7 +386,6 @@
386	386
387	387	All major classes of the SDMX Information model inherit from one of:
388	388
389		-
390	390	* **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.
391	391	* **NamableArtefact **- this has all of the features of IdentifiableArtefact plus the ability to have a multi-lingual name and description,
392	392	* **VersionableArtefact **– this has all of the above features plus a version number and a validity period.
...	...	@@ -394,6 +394,8 @@
394	394
395	395	=== 6.1.1 Identification, Naming, Versioning, and Maintenance Model ===
396	396
	384	+[[image:1747824504225-229.png]]
	385	+
397	397	**Figure 5: Class diagram of fundamental artefacts in the SDMX-IM**
398	398
399	399	The table below shows the identification and related data attributes to be stored in a registry for objects that are one of:
...	...	@@ -404,38 +404,34 @@
404	404	* Versionable
405	405	* Maintainable
406	406
407		-|**Object Type**|**Data Attributes**|**Status**|**Data type**|**Notes**
408		-|Annotable|AnnotationTitle|C|string|
409		-| |AnnotationType|C|string|
410		-| |AnnotationURN|C|string|
411		-| |(((
412		-AnnotationText in the form of
	396	+(% style="width:935.294px" %)
	397	+|**Object Type**|(% style="width:244px" %)**Data Attributes**|(% style="width:99px" %)**Status**|**Data type**|(% style="width:389px" %)**Notes**
	398	+|Annotable|(% style="width:244px" %)AnnotationTitle|(% style="width:99px" %)C|string|(% style="width:389px" %)
	399	+| |(% style="width:244px" %)AnnotationType|(% style="width:99px" %)C|string|(% style="width:389px" %)
	400	+| |(% style="width:244px" %)AnnotationURN|(% style="width:99px" %)C|string|(% style="width:389px" %)
	401	+| |(% style="width:244px" %)(((
	402	+AnnotationText in the form of International String
	403	+)))|(% style="width:99px" %)C| |(% style="width:389px" %)This can have languagespecific variants.
	404	+|Identifiable|(% style="width:244px" %)all content as for Annotable plus|(% style="width:99px" %) | |(% style="width:389px" %)
	405	+| |(% style="width:244px" %)id|(% style="width:99px" %)M|string|(% style="width:389px" %)
	406	+| |(% style="width:244px" %)uri|(% style="width:99px" %)C|string|(% style="width:389px" %)
	407	+| |(% 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.
	408	+|Nameable|(% style="width:244px" %)all content as for Identifiable plus|(% style="width:99px" %) | |(% style="width:389px" %)
	409	+| |(% style="width:244px" %)Name in the form of International String|(% style="width:99px" %)M|string|(% style="width:389px" %)This can have languagespecific variants.
	410	+| |(% style="width:244px" %)(((
	411	+Description in the form of International String
	412	+)))|(% style="width:99px" %)C|string|(% style="width:389px" %)This can have languagespecific variants.
	413	+|Versionable|(% style="width:244px" %)All content as for Identifiable plus|(% style="width:99px" %) | |(% style="width:389px" %)
	414	+| |(% 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
	415	+| |(% style="width:244px" %)validFrom|(% style="width:99px" %)C|Date/time|(% style="width:389px" %)
	416	+| |(% style="width:244px" %)validTo|(% style="width:99px" %)C|Date/time|(% style="width:389px" %)
	417	+|Maintainable|(% style="width:244px" %)All content as for Versionable plus|(% style="width:99px" %) | |(% style="width:389px" %)
	418	+| |(% 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.
	419	+| |(% 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.
	420	+| |(% style="width:244px" %)serviceURL|(% style="width:99px" %)C|string|(% style="width:389px" %)The url of the service that can be queried for this resource
	421	+| |(% style="width:244px" %)structureURL|(% style="width:99px" %)C|string|(% style="width:389px" %)The url of the resource.
	422	+| |(% style="width:244px" %)(Maintenance) agencyId|(% style="width:99px" %)M|string|(% style="width:389px" %)The object must be linked to a maintenance agency.
413	413
414		-International String
415		-)))|C| |This can have languagespecific variants.
416		-| | | | |
417		-|Identifiable|all content as for Annotable plus| | |
418		-| |id|M|string|
419		-| |uri|C|string|
420		-| |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.
421		-|Nameable|all content as for Identifiable plus| | |
422		-| |Name in the form of International String|M|string|This can have languagespecific variants.
423		-| |(((
424		-Description in the form of International
425		-
426		-String
427		-)))|C|string|This can have languagespecific variants.
428		-|Versionable|All content as for Identifiable plus| | |
429		-| |version|C|string|This is the version number. If not present the default is 1.0
430		-| |validFrom|C|Date/time|
431		-| |validTo|C|Date/time|
432		-|Maintainable|All content as for Versionable plus| | |
433		-| |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.
434		-| |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.
435		-| |serviceURL|C|string|The url of the service that can be queried for this resource
436		-| |structureURL|C|string|The url of the resource.
437		-| |(Maintenance) agencyId|M|string|The object must be linked to a maintenance agency.
438		-
439	439	**Table 1: Common Attributes of Object Types**
440	440
441	441	== 6.2 Unique identification of SDMX objects ==
...	...	@@ -480,11 +480,11 @@
480	480
481	481	An example of this is shown in the XML snippet below.
482	482
	468	+[[image:1747824123013-196.jpeg||height="309" width="446"]]
483	483
484		-[[image:1747824123013-196.jpeg]]
	470	+(% class="wikigeneratedid" id="HFigure8:ExampleShowingUseofAgencyIdentifiers" %)
	471	+**Figure 8: Example Showing Use of Agency Identifiers**
485	485
486		-==== Figure 8: Example Showing Use of Agency Identifiers ====
487		-
488	488	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.
489	489
490	490	=== 6.2.2 Universal Resource Name (URN) ===
...	...	@@ -501,7 +501,7 @@
501	501
502	502	The generic structure of the URN is as follows:
503	503
504		-SDMXprefix.SDMX-IM-package-name.class-name=agencyid:maintainedobject-id(maintainedobject-version).*containerobject-id.object-id
	489	+>SDMXprefix.SDMX-IM-package-name.class-name=agencyid:maintainedobject-id(maintainedobject-version).*containerobject-id.object-id
505	505
506	506	~* this can repeat and may not be present (see explanation below)
507	507
...	...	@@ -513,7 +513,7 @@
513	513
514	514	In the explanation below the actual object that is the target of the URN is called the **//actual object//**.
515	515
516		-**SDMXPrefix:** urn:sdmx:org.
	501	+**SDMXPrefix:** urn:sdmx:org.
517	517
518	518	**SDMX-IM package name:** sdmx.infomodel.package=
519	519
...	...	@@ -523,10 +523,8 @@
523	523
524	524	**(maintainable-object-version)** is the version of the maintainable object and is enclosed in round brackets (). It will always be present.
525	525
526		-**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
	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.
527	527
528		-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.
529		-
530	530	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.
531	531
532	532	For example the sequence is agency:DSDid(version).DimensionId and not agency:DSDid(version).DimensionDescriptorId.DimensionId.
...	...	@@ -533,58 +533,57 @@
533	533
534	534	**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.
535	535
536		-===== //Generic Examples of the URN Structure// =====
	519	+===== __**//Generic Examples of the URN Structure//**__ =====
537	537
	521	+__Actual object is a maintainable__
538	538
539		-Actual object is a maintainable
	523	+> SDMXPrefix.SDMX-IM package name.classname=agency id:maintained-object-id(version)
540	540
541		-SDMXPrefix.SDMX-IM package name.classname=agency id:maintained-object-id(version)
	525	+__Actual object is contained in a maintained object with no intermediate containing object__
542	542
543		-Actual object is contained in a maintained object with no intermediate containing object
	527	+> SDMXPrefix.SDMX-IM package name.classname=agency id:maintained-object-id(version).object-id
544	544
545		-SDMXPrefix.SDMX-IM package name.classname=agency id:maintained-object-id(version).object-id
	529	+__Actual object is contained in a maintained object with an intermediate containing object__
546	546
547		-Actual object is contained in a maintained object with an intermediate containing object
	531	+> SDMXPrefix.SDMX-IM package name.classname=agency
548	548
549		-SDMXPrefix.SDMX-IM package name.classname=agency
550		-
551	551	id:maintained-object-id(version).contained-object-id.object-id
552	552
553		-Actual object is contained in a maintained object with no intermediate containing object but the object type itself is hierarchical
	535	+__Actual object is contained in a maintained object with no intermediate containing object but the object type itself is hierarchical__
554	554
555	555	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
556	556
557		-SDMXPrefix.SDMX-IM package name.classname=agency id:maintained-object-id(version).contained-object-id.object-id
	539	+> SDMXPrefix.SDMX-IM package name.classname=agency id:maintained-object-id(version).contained-object-id.object-id
558	558
559		-Actual object is contained in a maintained object with an intermediate containing object and the object type itself is hierarchical
	541	+__Actual object is contained in a maintained object with an intermediate containing object and the object type itself is hierarchical__
560	560
561	561	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
562	562
563		-SDMXPrefix.SDMX-IM package name.classname=agency id:maintained-object-id(version).contained-object-id. contained-object-id contained-object-id.object-id
	545	+> SDMXPrefix.SDMX-IM package name.classname=agency id:maintained-object-id(version).contained-object-id. contained-object-id contained-object-id.object-id
564	564
565		-===== //Concrete Examples of the URN Structure// =====
	547	+===== __**//Concrete Examples of the URN Structure//**__ =====
566	566
567	567	The Data Structure Definition CRED_EXT_DEBT version 1.0 maintained by the top level Agency TFFS would have the URN:
568	568
569		-urn:sdmx:org.sdmx.infomodel.datastructure.DataStucture=TFFS:CRED_EXT_ DEBT(1.0)
	551	+> urn:sdmx:org.sdmx.infomodel.datastructure.DataStucture=TFFS:CRED_EXT_ DEBT(1.0)
570	570
571	571	The URN for a code for Argentina maintained by ISO in the code list CL_3166A2 version 1.0 would be:
572	572
573		-urn:sdmx:org.sdmx.infomodel.codelist.Code=ISO:CL_3166A2(1.0).AR
	555	+> urn:sdmx:org.sdmx.infomodel.codelist.Code=ISO:CL_3166A2(1.0).AR
574	574
575	575	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:
576	576
577		-urn:sdmx:org.sdmx.infomodel.categoryscheme.Category=SDMX:SUBJE CT_MATTER_DOMAINS(1.0).1.2
	559	+> urn:sdmx:org.sdmx.infomodel.categoryscheme.Category=SDMX:SUBJE CT_MATTER_DOMAINS(1.0).1.2
578	578
579	579	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
580	580
581	581	CONTACT_DETAILS/CONTACT_NAME would be:
582	582
583		-urn:sdmx:org.sdmx.infomodel.metadatastructure.MetadataAttribut e=SDMX:CONTACT_METADATA(1.0).CONTACT_REPORT.CONTACT_DETAILS.CO NTACT_NAME
	565	+> urn:sdmx:org.sdmx.infomodel.metadatastructure.MetadataAttribut e=SDMX:CONTACT_METADATA(1.0).CONTACT_REPORT.CONTACT_DETAILS.CO NTACT_NAME
584	584
585	585	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:
586	586
587		-urn:sdmx:org.sdmx.infomodel.datastructure.Dataflow=TFFS.ABC:EX
	569	+> urn:sdmx:org.sdmx.infomodel.datastructure.Dataflow=TFFS.ABC:EX
588	588
589	589	TERNAL_DEBT(1.0)
590	590
...	...	@@ -599,112 +599,94 @@
599	599
600	600	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.
601	601
602		-|**Package**|(((
603		-**URN Classname (model classname**
604		-
605		-**where this is different)**
	584	+|(% style="width:127px" %)**Package**|(% style="width:1745px" %)(((
	585	+**URN Classname (model classname where this is different)**
606	606	)))
607		-|base|Agency
608		-| |OrganisationUnitScheme
609		-| |AgencyScheme
610		-| |DataProviderScheme
611		-| |DataConsumerScheme
612		-| |OrganisationUnit
613		-| |DataProvider
614		-| |DataConsumer
615		-| |
616		-|datastructure|DataStructure (DataStructureDefinition)
617		-| |AttributeDescriptor
618		-| |DataAttribute
619		-| |GroupDimensionDescriptor
620		-| |DimensionDescriptor
621		-| |Dimension
622		-| |MeasureDimension
623		-| |TimeDimension
624		-| |MeasureDescriptor
625		-| |PrimaryMeasure
626		-| |Dataflow (DataflowDefinition)
627		-| |
628		-|metadatastructure|MetadataTarget
629		-| |DimensionDescriptorValueTarget
630		-| |IdentifiableObjectTarget
631		-| |ReportPeriodTarget
632		-| |DataSetTarget
633		-| |ReportStructure
634		-| |MetadataAttribute
635		-| |(((
	587	+|(% style="width:127px" %)base|(% style="width:45px" %)Agency
	588	+|(% style="width:127px" %) |(% style="width:45px" %)OrganisationUnitScheme
	589	+|(% style="width:127px" %) |(% style="width:45px" %)AgencyScheme
	590	+|(% style="width:127px" %) |(% style="width:45px" %)DataProviderScheme
	591	+|(% style="width:127px" %) |(% style="width:45px" %)DataConsumerScheme
	592	+|(% style="width:127px" %) |(% style="width:45px" %)OrganisationUnit
	593	+|(% style="width:127px" %) |(% style="width:45px" %)DataProvider
	594	+|(% style="width:127px" %) |(% style="width:45px" %)DataConsumer
	595	+|(% style="width:127px" %)datastructure|(% style="width:45px" %)DataStructure (DataStructureDefinition)
	596	+|(% style="width:127px" %) |(% style="width:45px" %)AttributeDescriptor
	597	+|(% style="width:127px" %) |(% style="width:45px" %)DataAttribute
	598	+|(% style="width:127px" %) |(% style="width:45px" %)GroupDimensionDescriptor
	599	+|(% style="width:127px" %) |(% style="width:45px" %)DimensionDescriptor
	600	+|(% style="width:127px" %) |(% style="width:45px" %)Dimension
	601	+|(% style="width:127px" %) |(% style="width:45px" %)MeasureDimension
	602	+|(% style="width:127px" %) |(% style="width:45px" %)TimeDimension
	603	+|(% style="width:127px" %) |(% style="width:45px" %)MeasureDescriptor
	604	+|(% style="width:127px" %) |(% style="width:45px" %)PrimaryMeasure
	605	+|(% style="width:127px" %) |(% style="width:45px" %)Dataflow (DataflowDefinition)
	606	+|(% style="width:127px" %)metadatastructure|(% style="width:45px" %)MetadataTarget
	607	+|(% style="width:127px" %) |(% style="width:45px" %)DimensionDescriptorValueTarget
	608	+|(% style="width:127px" %) |(% style="width:45px" %)IdentifiableObjectTarget
	609	+|(% style="width:127px" %) |(% style="width:45px" %)ReportPeriodTarget
	610	+|(% style="width:127px" %) |(% style="width:45px" %)DataSetTarget
	611	+|(% style="width:127px" %) |(% style="width:45px" %)ReportStructure
	612	+|(% style="width:127px" %) |(% style="width:45px" %)MetadataAttribute
	613	+|(% style="width:127px" %) |(% style="width:45px" %)(((
636	636	MetadataStructure
637	637
638	638	(MetadataStructureDefinition)
639	639	)))
640		-| |Metadataflow (MetadataflowDefinition)
641		-| |
642		-|process|Process
643		-| |ProcessStep
644		-| |Transition
645		-| |
646		-|registry|ProvisionAgreement
647		-| |AttachmentConstraint
648		-| |ContentConstraint
649		-| |Subscription
650		-| |
651		-|mapping|StructureMap
652		-| |StructureSet
653		-| |ComponentMap
654		-|**Package**|(((
655		-**URN Classname (model classname**
	618	+|(% style="width:127px" %) |(% style="width:45px" %)Metadataflow (MetadataflowDefinition)
	619	+|(% style="width:127px" %)process|(% style="width:45px" %)Process
	620	+|(% style="width:127px" %) |(% style="width:45px" %)ProcessStep
	621	+|(% style="width:127px" %) |(% style="width:45px" %)Transition
	622	+|(% style="width:127px" %)registry|(% style="width:45px" %)ProvisionAgreement
	623	+|(% style="width:127px" %) |(% style="width:45px" %)AttachmentConstraint
	624	+|(% style="width:127px" %) |(% style="width:45px" %)ContentConstraint
	625	+|(% style="width:127px" %) |(% style="width:45px" %)Subscription
	626	+|(% style="width:127px" %)mapping|(% style="width:45px" %)StructureMap
	627	+|(% style="width:127px" %) |(% style="width:45px" %)StructureSet
	628	+|(% style="width:127px" %) |(% style="width:45px" %)ComponentMap
	629	+|(% style="width:127px" %) |(% style="width:1745px" %)ConceptSchemeMap
	630	+|(% style="width:127px" %) |(% style="width:1745px" %)OrganisationSchemeMap
	631	+|(% style="width:127px" %) |(% style="width:1745px" %)CodelistMap
	632	+|(% style="width:127px" %) |(% style="width:1745px" %)CategorySchemeMap
	633	+|(% style="width:127px" %) |(% style="width:1745px" %)ReportingTaxonomyMap
	634	+|(% style="width:127px" %) |(% style="width:1745px" %)ConceptMap
	635	+|(% style="width:127px" %) |(% style="width:1745px" %)OrganisationMap
	636	+|(% style="width:127px" %) |(% style="width:1745px" %)CodeMap
	637	+|(% style="width:127px" %) |(% style="width:1745px" %)HybridCodelistMap
	638	+|(% style="width:127px" %) |(% style="width:1745px" %)CategoryMap
	639	+|(% style="width:127px" %) |(% style="width:1745px" %)HybridCodeMap
	640	+|(% style="width:127px" %) |(% style="width:1745px" %)ReportingCategoryMap
	641	+|(% style="width:127px" %)codelist|(% style="width:1745px" %)Codelist
	642	+|(% style="width:127px" %) |(% style="width:1745px" %)HierarchicalCodelist
	643	+|(% style="width:127px" %) |(% style="width:1745px" %)Hierarchy
	644	+|(% style="width:127px" %) |(% style="width:1745px" %)Hierarchy
	645	+|(% style="width:127px" %) |(% style="width:1745px" %)Code
	646	+|(% style="width:127px" %) |(% style="width:1745px" %)HierarchicalCode
	647	+|(% style="width:127px" %) |(% style="width:1745px" %)Level
	648	+|(% style="width:127px" %)categoryscheme|(% style="width:1745px" %)CategoryScheme
	649	+|(% style="width:127px" %) |(% style="width:1745px" %)Category
	650	+|(% style="width:127px" %) |(% style="width:1745px" %)Categorisation
	651	+|(% style="width:127px" %) |(% style="width:1745px" %)ReportingTaxonomy
	652	+|(% style="width:127px" %) |(% style="width:1745px" %)ReportingCategory
	653	+|(% style="width:127px" %)conceptscheme|(% style="width:1745px" %)ConceptScheme
	654	+|(% style="width:127px" %) |(% style="width:1745px" %)Concept
	655	+|(% style="width:127px" %)transformation|(% style="width:1745px" %)TransformationScheme
	656	+|(% style="width:127px" %) |(% style="width:1745px" %)Transformation
	657	+|(% style="width:127px" %) |(% style="width:1745px" %)CustomTypeScheme
	658	+|(% style="width:127px" %) |(% style="width:1745px" %)CustomType
	659	+|(% style="width:127px" %) |(% style="width:1745px" %)NamePersonalisationScheme
	660	+|(% style="width:127px" %) |(% style="width:1745px" %)NamePersonalisation
	661	+|(% style="width:127px" %) |(% style="width:1745px" %)VtlCodelistMapping
	662	+|(% style="width:127px" %) |(% style="width:1745px" %)VtlConceptMapping
	663	+|(% style="width:127px" %) |(% style="width:1745px" %)VtlDataflowMapping
	664	+|(% style="width:127px" %) |(% style="width:1745px" %)VtlConceptSchemeMapping
	665	+|(% style="width:127px" %) |(% style="width:1745px" %)RulesetScheme
	666	+|(% style="width:127px" %) |(% style="width:1745px" %)Ruleset
	667	+|(% style="width:127px" %) |(% style="width:1745px" %)UserDefinedOperatorScheme
	668	+|(% style="width:127px" %) |(% style="width:1745px" %)UserDefinedOperator
656	656
657		-**where this is different)**
658		-)))
659		-| |ConceptSchemeMap
660		-| |OrganisationSchemeMap
661		-| |CodelistMap
662		-| |CategorySchemeMap
663		-| |ReportingTaxonomyMap
664		-| |ConceptMap
665		-| |OrganisationMap
666		-| |CodeMap
667		-| |HybridCodelistMap
668		-| |CategoryMap
669		-| |HybridCodeMap
670		-| |ReportingCategoryMap
671		-| |
672		-|codelist|Codelist
673		-| |HierarchicalCodelist
674		-| |Hierarchy
675		-| |Hierarchy
676		-| |Code
677		-| |HierarchicalCode
678		-| |Level
679		-| |
680		-|categoryscheme|CategoryScheme
681		-| |Category
682		-| |Categorisation
683		-| |ReportingTaxonomy
684		-| |ReportingCategory
685		-| |
686		-|conceptscheme|ConceptScheme
687		-| |Concept
688		-| |
689		-|transformation|TransformationScheme
690		-| |Transformation
691		-| |CustomTypeScheme
692		-| |CustomType
693		-| |NamePersonalisationScheme
694		-| |NamePersonalisation
695		-| |VtlCodelistMapping
696		-| |VtlConceptMapping
697		-| |VtlDataflowMapping
698		-| |VtlConceptSchemeMapping
699		-| |RulesetScheme
700		-| |Ruleset
701		-| |UserDefinedOperatorScheme
702		-| |UserDefinedOperator
703		-| |
704		-
705	705	**Table 2: SDMX-IM Packages and Contained Classes**
706	706
707		-
708	708	=== 6.2.4 URN Identification components of SDMX objects ===
709	709
710	710	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.
...	...	@@ -713,78 +713,52 @@
713	713
714	714	Note that for brevity the URN examples omit the prefix. All URNs have the prefix
715	715
716		-urn:sdmx.org.sdmx.infomodel.{package}.{classname}=
	680	+> urn:sdmx.org.sdmx.infomodel.{package}.{classname}=
717	717
718		-
719		-|**SDMX Class**|**Key attribute(s)**|**Example of URN**
720		-|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.|(((
	682	+(% style="width:1091.29px" %)
	683	+|(% style="width:250px" %)**SDMX Class**|(% style="width:444px" %)**Key attribute(s)**|(% style="width:396px" %)**Example of URN**
	684	+|(% style="width:250px" %)Agency|(% style="width:444px" %)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:396px" %)(((
721	721	IMF
722		-
723		-
724	724	Sub agency in the IMF AGENCIES
725		-
726		-
727	727	IMF.SubAgency1
728	728	)))
729		-|*ConceptScheme|conceptSchemeAgencyId:conceptSchemeId(ve rsion)|SDMX:CROSS_DOMAIN_CONCEPTS(1.0)
730		-|Concept|(((
731		-conceptSchemeAgencyId:
732		-
733		-conceptSchemeId(version).conceptId
734		-)))|SDMX:CROSS_DOMAIN_CONCEPTS(1.0).FREQ
735		-|*Codelist|codeListAgencyId:codeListId(version)|SDMX:CL_FREQ(1.0)
736		-|Code|codeListAgencyId:codelistId(version).codeId|(((
737		-SDMX:CL_FREQ(1.0).Q
738		-
739		-
	689	+|(% style="width:250px" %)*ConceptScheme|(% style="width:444px" %)conceptSchemeAgencyId:conceptSchemeId(ve rsion)|(% style="width:396px" %)SDMX:CROSS_DOMAIN_CONCEPTS(1.0)
	690	+|(% style="width:250px" %)Concept|(% style="width:444px" %)conceptSchemeAgencyId:
	691	+conceptSchemeId(version).conceptId|(% style="width:396px" %)SDMX:CROSS_DOMAIN_CONCEPTS(1.0).FREQ
	692	+|(% style="width:250px" %)*Codelist|(% style="width:444px" %)codeListAgencyId:codeListId(version)|(% style="width:396px" %)SDMX:CL_FREQ(1.0)
	693	+|(% style="width:250px" %)Code|(% style="width:444px" %)codeListAgencyId:codelistId(version).codeId|(% style="width:396px" %)SDMX:CL_FREQ(1.0).Q
	694	+|(% style="width:250px" %)(((
	695	+*Hierarchical Codelist
	696	+)))|(% style="width:444px" %)hierachicalCodelistAgencyId: hierarchicalCodelistId(version)|(% style="width:396px" %)(((
	697	+UNESCO:CL_EXP_SOURCE(1.0(% style="background-color:transparent" %))
740	740	)))
741		-
742		-
743		-
744		-|(((
745		-*Hierarchical
746		-
747		-Codelist
748		-)))|hierachicalCodelistAgencyId: hierarchicalCodelistId(version)|(((
749		-UNESCO:CL_EXP_SOURCE(1.0)
750		-
751		-
752		-)))
753		-|Hierarchy|(((
	699	+|(% style="width:250px" %)Hierarchy|(% style="width:444px" %)(((
754	754	hierachicalcodeListAgencyId:
755		-
756	756	hierarchicalcodelistId(version).Hierarchy
757		-)))|UNESCO:CL_EXP_SOURCE(1.0). H-C-GOV
758		-|Level|(((
	702	+)))|(% style="width:396px" %)UNESCO:CL_EXP_SOURCE(1.0).
	703	+H-C-GOV
	704	+|(% style="width:250px" %)Level|(% style="width:444px" %)(((
759	759	hierachicalcodeListAgencyId:
760		-
761	761	hierarchicalcodelistId(version).Hierarchy.Level
762		-)))|(((
	707	+)))|(% style="width:396px" %)(((
763	763	ESTAT:HCL_REGION(1.0).H_1.COUNTRY
764	764
765	765
766	766	)))
767		-|HierarchicalCode|hierachicalCodeListAgencyId: hierarchicalcodelistId(version).hierarchy.hierarc hicalCode|UNESCO:CL_EXP_SOURCE(1.0). H-C-GOV.GOV_CODE1
768		-|*DataStructure|dataStructureDefintitionAgencyId: dataStructureDefintitionId(version)|TFFS:EXT_DEBT(1.0)
769		-|(((
	712	+|(% style="width:250px" %)HierarchicalCode|(% style="width:444px" %)hierachicalCodeListAgencyId: hierarchicalcodelistId(version).hierarchy.hierarc hicalCode|(% style="width:396px" %)UNESCO:CL_EXP_SOURCE(1.0). H-C-GOV.GOV_CODE1
	713	+|(% style="width:250px" %)*DataStructure|(% style="width:444px" %)dataStructureDefintitionAgencyId: dataStructureDefintitionId(version)|(% style="width:396px" %)TFFS:EXT_DEBT(1.0)
	714	+|(% style="width:250px" %)(((
770	770	Dimension
771		-
772	772	Descriptor
773		-
774	774	Measure
775		-
776	776	Descriptor
777		-
778	778	Attribute
779		-
780	780	Descriptor
781		-)))|(((
	721	+)))|(% style="width:444px" %)(((
782	782	dataStructureDefinitionAgencyId: dataStructureDefinitionId(version).
783		-
784	784	componentListId
785		-
786	786	where the componentListId is the name of the class (there is only one occurrence of each in the Data Structure Definition)
787		-)))|(((
	725	+)))|(% style="width:396px" %)(((
788	788	TFFS:EXT_DEBT(1.0).DimensionDescriptor
789	789
790	790	TFFS:EXT_DEBT(1.0).MeasureDescriptor
...	...	@@ -791,181 +791,132 @@
791	791
792	792	TFFS:EXT_DEBT(1.0).AttributeDescriptor
793	793	)))
794		-|(((
	732	+|(% style="width:250px" %)(((
795	795	GroupDimension
796		-
797	797	Descriptor
798		-)))|(((
	735	+)))|(% style="width:444px" %)(((
799	799	dataStructureDefinitionAgencyId: dataStructureDefinitionId(version).
800		-
801	801	groupDimensionDescriptorId
802		-)))|TFFS:EXT_DEBT(1.0).SIBLING
803		-|Dimension|(((
	738	+)))|(% style="width:396px" %)TFFS:EXT_DEBT(1.0).SIBLING
	739	+|(% style="width:250px" %)Dimension|(% style="width:444px" %)(((
804	804	dataStructureDefinitionAgencyId: dataStructureDefinition (version).
805		-
806	806	dimensionId
807		-)))|TFFS:EXT_DEBT(1.0).FREQ
808		-|TimeDimension|(((
	742	+)))|(% style="width:396px" %)TFFS:EXT_DEBT(1.0).FREQ
	743	+|(% style="width:250px" %)TimeDimension|(% style="width:444px" %)(((
809	809	dataStructureDefinitionAgencyId: dataStructureDefinition (version).
810		-
811	811	timeDimensionId
812		-)))|TFFS:EXT_DEBT(1.0).TIME_PERIOD
813		-|Measure Dimension|dataStructureDefinitionAgencyId: dataStructureDefinition (version).|TFFS:EXT_DEBT(1.0).STOCK_FLOW
814		-
815		-
816		-
817		-| |measureDimensionId|
818		-|DataAttrribute|dataStructureDefinitionAgencyId: dataStructureDefinition (version). dataAttributeId|TFFS:EXT_DEBT(1.0).OBS_STATUS
819		-|PrimaryMeasure|(((
	746	+)))|(% style="width:396px" %)TFFS:EXT_DEBT(1.0).TIME_PERIOD
	747	+|(% style="width:250px" %)Measure Dimension|(% style="width:444px" %)dataStructureDefinitionAgencyId: dataStructureDefinition (version).
	748	+measureDimensionId|(% style="width:396px" %)TFFS:EXT_DEBT(1.0).STOCK_FLOW
	749	+|(% style="width:250px" %)DataAttrribute|(% style="width:444px" %)dataStructureDefinitionAgencyId: dataStructureDefinition (version). dataAttributeId|(% style="width:396px" %)TFFS:EXT_DEBT(1.0).OBS_STATUS
	750	+|(% style="width:250px" %)PrimaryMeasure|(% style="width:444px" %)(((
820	820	dataStructureDefinitionAgencyId: dataStructureDefinition (version).
821		-
822	822	primaryMeasureId
823		-)))|TFFS:EXT_DEBT(1.0).OBS_VALUE
824		-|(((
825		-*Category
826		-
827		-Scheme
828		-)))|categorySchemeAgencyId: categorySchemeId(version)|IMF:SDDS(1.0)
829		-|Category|categorySchemeAgencyId: categorySchemeId(version). categoryId.categoryId categoryId.categoryId etc.|(((
	753	+)))|(% style="width:396px" %)TFFS:EXT_DEBT(1.0).OBS_VALUE
	754	+|(% style="width:250px" %)(((
	755	+*Category Scheme
	756	+)))|(% style="width:444px" %)categorySchemeAgencyId:
	757	+categorySchemeId(version)|(% style="width:396px" %)IMF:SDDS(1.0)
	758	+|(% style="width:250px" %)Category|(% style="width:444px" %)categorySchemeAgencyId:
	759	+categorySchemeId(version).
	760	+categoryId.categoryId categoryId.categoryId etc.|(% style="width:396px" %)(((
830	830	IMF:SDDS(1.0):
831		-
832	832	level_1_category.level_2_category …
833	833	)))
834		-|(((
835		-*Reporting
836		-
837		-Taxonomy
838		-)))|reportingTaxonomyAgencyId: reportingTaxonomyId(version)| IMF:REP_1(1.0)
839		-|ReportingCategory|reportingTaxonomyAgencyId: reportingTaxonomyId(version) reportingcategoryId.reportingcategoryId|(((
	764	+|(% style="width:250px" %)(((
	765	+*Reporting Taxonomy
	766	+)))|(% style="width:444px" %)reportingTaxonomyAgencyId: reportingTaxonomyId(version)|(% style="width:396px" %) IMF:REP_1(1.0)
	767	+|(% style="width:250px" %)ReportingCategory|(% style="width:444px" %)reportingTaxonomyAgencyId: reportingTaxonomyId(version) reportingcategoryId.reportingcategoryId|(% style="width:396px" %)(((
840	840	IMF:REP_1(1.0):
841		-
842	842	level_1_repcategory.level_2_repcategory …
843	843	)))
844		-|*Categorisation|categorisationAgencyId: categorisationId(version)|IMF:cat001(1.0)
845		-|(((
846		-*Organisation
	771	+|(% style="width:250px" %)*Categorisation|(% style="width:444px" %)categorisationAgencyId: categorisationId(version)|(% style="width:396px" %)IMF:cat001(1.0)
	772	+|(% style="width:250px" %)(((
	773	+*Organisation Unit Scheme
	774	+)))|(% style="width:444px" %)organisationUnitSchemeAgencyId: organisationUnitSchemeId(version)|(% style="width:396px" %)ECB:ORGANISATIONS(1.0)
	775	+|(% style="width:250px" %)Organisation Unit|(% style="width:444px" %)organisationUnitSchemeAgencyId: organisationUnitSchemeId(version). organisationUnitId|(% style="width:396px" %)ECB:ORGANISATIONS(1.0).1F
	776	+|(% style="width:250px" %)*AgencyScheme|(% style="width:444px" %)agencySchemeAgencyId: agencySchemeId(version)|(% style="width:396px" %)ECB:AGENCIES(1.0)
847	847
848		-Unit Scheme
849		-)))|organisationUnitSchemeAgencyId: organisationUnitSchemeId(version)|ECB:ORGANISATIONS(1.0)
850		-|Organisation Unit|organisationUnitSchemeAgencyId: organisationUnitSchemeId(version). organisationUnitId|ECB:ORGANISATIONS(1.0).1F
851		-|*AgencyScheme|agencySchemeAgencyId: agencySchemeId(version)|ECB:AGENCIES(1.0)
852		-
853		-
854		-
855		-|Agency|agencySchemeAgencyId: agencySchemeId(version). agencyId|ECB:AGENCY(1.0).AA
856		-|(((
857		-*DataProvider
858		-
859		-Scheme
860		-)))|dataProviderSchemeAgencyId: dataProviderSchemeId(version)|SDMX:DATA_PROVIDERS(1.0)
861		-|DataProvider|dataProviderSchemeAgencyId: dataProviderSchemeId(version) dataProviderId|SDMX:DATA_PROVIDERS(1.0).PROVIDER_1
862		-|(((
863		-*DataConsumer
864		-
865		-Scheme
866		-)))|dataConsumerSchemeAgencyId: dataConsumerSchemeId(version)|SDMX:DATA_CONSUMERS(1.0)
867		-|Data Consumer|dataConsumerSchemeAgencyId: dataConsumerSchemeId(version) dataConsumerId|SDMX:DATA_CONSUMERS(1.0).CONSUMER_1
868		-|(((
869		-*Metadata
870		-
871		-Structure
872		-)))|MSDAgencyId:MSDId(version)|IMF:SDDS_MSD(1.0)
873		-|MetadataTarget|(((
	778	+|(% style="width:262px" %)Agency|(% style="width:369px" %)agencySchemeAgencyId: agencySchemeId(version). agencyId|(% style="width:1262px" %)ECB:AGENCY(1.0).AA
	779	+|(% style="width:262px" %)(((
	780	+*DataProvider Scheme
	781	+)))|(% style="width:369px" %)dataProviderSchemeAgencyId: dataProviderSchemeId(version)|(% style="width:1262px" %)SDMX:DATA_PROVIDERS(1.0)
	782	+|(% style="width:262px" %)DataProvider|(% style="width:369px" %)dataProviderSchemeAgencyId: dataProviderSchemeId(version) dataProviderId|(% style="width:1262px" %)SDMX:DATA_PROVIDERS(1.0).PROVIDER_1
	783	+|(% style="width:262px" %)(((
	784	+*DataConsumer Scheme
	785	+)))|(% style="width:369px" %)dataConsumerSchemeAgencyId: dataConsumerSchemeId(version)|(% style="width:1262px" %)SDMX:DATA_CONSUMERS(1.0)
	786	+|(% style="width:262px" %)Data Consumer|(% style="width:369px" %)dataConsumerSchemeAgencyId: dataConsumerSchemeId(version) dataConsumerId|(% style="width:1262px" %)SDMX:DATA_CONSUMERS(1.0).CONSUMER_1
	787	+|(% style="width:262px" %)(((
	788	+*Metadata Structure
	789	+)))|(% style="width:369px" %)MSDAgencyId:MSDId(version)|(% style="width:1262px" %)IMF:SDDS_MSD(1.0)
	790	+|(% style="width:262px" %)MetadataTarget|(% style="width:369px" %)(((
874	874	MSDAgencyId:
875		-
876	876	MSDId(version).metadataTargetId
877		-)))|IMF:SDDS_MSD(1.0).AGENCY
878		-|(((
	793	+)))|(% style="width:1262px" %)IMF:SDDS_MSD(1.0).AGENCY
	794	+|(% style="width:262px" %)(((
879	879	Dimension
880		-
881	881	DescriptorValues
882		-
883	883	Target
884		-)))|(((
	798	+)))|(% style="width:369px" %)(((
885	885	MSDAgencyId: MSDId(version).
886		-
887	887	metadataTargetId.keyDescriptorValueTargetId
888		-)))|IMF:SDDS_MSD(1.0).AGENCY.KEY
889		-|Identifiable ObjectTarget|(((
	801	+)))|(% style="width:1262px" %)IMF:SDDS_MSD(1.0).AGENCY.KEY
	802	+|(% style="width:262px" %)Identifiable Object Target|(% style="width:369px" %)(((
	803	+MSDAgencyId: MSDId(version).metadataTargetId.identifiableObjectTargetId
	804	+)))|(% style="width:1262px" %)IMF:SDDS_MSD(1.0).AGENCY.STR-OBJECT
	805	+|(% style="width:262px" %)DataSetTarget|(% style="width:369px" %)(((
890	890	MSDAgencyId:
	807	+MSDId(version).metadataTargetId.dataSetTargetId
	808	+)))|(% style="width:1262px" %)IMF:SDDS_MSD(1.0).AGENCY.D1101
	809	+|(% style="width:262px" %)PeportPeriod Target|(% style="width:369px" %)(((
	810	+MSDAgencyId: MSDId(version).metadataTargetId.reportPeriodTargetId
	811	+)))|(% style="width:1262px" %)IMF:SDDS_MSD(1.0).AGENCY.REP_PER
891	891
892		-MSDId(version).metadataTargetId.identifiable
893		-
894		-ObjectTargetId
895		-)))|IMF:SDDS_MSD(1.0).AGENCY.STR-OBJECT
896		-|DataSetTarget|(((
897		-MSDAgencyId:
898		-
899		-MSDId(version).metadataTargetId.dataSet
900		-
901		-TargetId
902		-)))|IMF:SDDS_MSD(1.0).AGENCY.D1101
903		-|PeportPeriod Target|(((
904		-MSDAgencyId:
905		-
906		-MSDId(version).metadataTargetId.reportPeriod
907		-
908		-TargetId
909		-)))|IMF:SDDS_MSD(1.0).AGENCY.REP_PER
910		-
911		-
912		-
913		-|(((
	813	+|(% style="width:251px" %)(((
914	914	ReportStructure
915	915
916	916
917		-)))|(((
918		-MSDAgencyId:
919		-
920		-MSDId(version).reportStructureId
921		-)))|IMF:SDDS_MSD(1.0).AGENCY_REPORT
922		-|(((
	817	+)))|(% style="width:442px" %)(((
	818	+MSDAgencyId: MSDId(version).reportStructureId
	819	+)))|(% style="width:1178px" %)IMF:SDDS_MSD(1.0).AGENCY_REPORT
	820	+|(% style="width:251px" %)(((
923	923	Metadata
924	924
925	925	Attribute
926		-)))|(((
927		-MSDAgencyId:
928		-
929		-MSDId(version).reportStructureId.metadataattri buteID
930		-)))|IMF:SDDS_MSD(1.0).AGENCY_REPORT.COMPILATION
931		-|*Dataflow|dataflowAgencyId: dataflowId(version)|TFFS:CRED_EXT_DEBT(1.0)
932		-|*Provision Agreement|(((
	824	+)))|(% style="width:442px" %)(((
	825	+MSDAgencyId: MSDId(version).reportStructureId.metadataattri buteID
	826	+)))|(% style="width:1178px" %)IMF:SDDS_MSD(1.0).AGENCY_REPORT.COMPILATION
	827	+|(% style="width:251px" %)*Dataflow|(% style="width:442px" %)dataflowAgencyId: dataflowId(version)|(% style="width:1178px" %)TFFS:CRED_EXT_DEBT(1.0)
	828	+|(% style="width:251px" %)*Provision Agreement|(% style="width:442px" %)(((
933	933	provisionAgreementAgencyId:provisionAgreem entId(version)
934		-
935		-
936		-)))|(((
	830	+)))|(% style="width:1178px" %)(((
937	937	TFFS:CRED_EXT_DEBT_AB(1.0)
938		-
939		-
940		-
941	941	)))
942		-|(((
	833	+|(% style="width:251px" %)(((
943	943	*Content
944	944
945	945	Constraint
946		-)))|constraintAgencyId:ContentConstraintId(versio n)|TFFS:CREDITOR_DATA_CONTENT(1.0)
947		-|(((
	837	+)))|(% style="width:442px" %)constraintAgencyId:ContentConstraintId(versio n)|(% style="width:1178px" %)TFFS:CREDITOR_DATA_CONTENT(1.0)
	838	+|(% style="width:251px" %)(((
948	948	*Attachment
949	949
950	950	Constraint
951		-)))|(((
	842	+)))|(% style="width:442px" %)(((
952	952	constraintAgencyId:
953	953
954	954	attachmentConstraintId(version)
955		-)))|TFFS:CREDITOR_DATA_ATTACHMENT_CONSTRAINT_ONE(1.0)
956		-|*Metadataflow|metadataflowAgencyId: metadataflowId(version)|IMF:SDDS_FLOW(1.0)
957		-|*StructureSet|structureSetAgencyId: structureSetId(version)|SDMX:BOP_STRUCTURES(1.0)
958		-|StructureMap|structureSetAgencyId: structureSetId(version). structureMapId|SDMX:BOP_STRUCTURES(1.0).TABLE1_TABLE2
959		-|Component Map|(((
	846	+)))|(% style="width:1178px" %)TFFS:CREDITOR_DATA_ATTACHMENT_CONSTRAINT_ONE(1.0)
	847	+|(% style="width:251px" %)*Metadataflow|(% style="width:442px" %)metadataflowAgencyId: metadataflowId(version)|(% style="width:1178px" %)IMF:SDDS_FLOW(1.0)
	848	+|(% style="width:251px" %)*StructureSet|(% style="width:442px" %)structureSetAgencyId: structureSetId(version)|(% style="width:1178px" %)SDMX:BOP_STRUCTURES(1.0)
	849	+|(% style="width:251px" %)StructureMap|(% style="width:442px" %)structureSetAgencyId: structureSetId(version). structureMapId|(% style="width:1178px" %)SDMX:BOP_STRUCTURES(1.0).TABLE1_TABLE2
	850	+|(% style="width:251px" %)Component Map|(% style="width:442px" %)(((
960	960	structureSetAgencyId: structureSetId(version).
961	961
962	962	structureMapId. componentMapId
963		-)))|SDMX:BOP_STRUCTURES(1.0).TABLE1_TABLE2. REFAREA_REPCOUNTRY
964		-|CodelistMap|structureSetAgencyId: structureSetId(version). codelistMapId|SDMX:BOP_STRUCTURES(1.0).CLREFAREA_CLREPCOUNTRY
965		-|CodeMap|structureSetAgencyId: structureSetId(version).|SDMX:BOP_STRUCTURES(1.0).CLREFAREA_CLREPCOUNTRY. DE_GER
	854	+)))|(% style="width:1178px" %)SDMX:BOP_STRUCTURES(1.0).TABLE1_TABLE2. REFAREA_REPCOUNTRY
	855	+|(% style="width:251px" %)CodelistMap|(% style="width:442px" %)structureSetAgencyId: structureSetId(version). codelistMapId|(% style="width:1178px" %)SDMX:BOP_STRUCTURES(1.0).CLREFAREA_CLREPCOUNTRY
	856	+|(% style="width:251px" %)CodeMap|(% style="width:442px" %)structureSetAgencyId: structureSetId(version).|(% style="width:1178px" %)SDMX:BOP_STRUCTURES(1.0).CLREFAREA_CLREPCOUNTRY. DE_GER
966	966
967		-
968		-
969	969	| |(((
970	970	codeListMapId.
971	971
...	...	@@ -1073,7 +1073,6 @@
1073	1073
1074	1074	7**Table 3: Table of identification components for SDMX Identifiable Artefacts**
1075	1075
1076		-
1077	1077	= 7 Implementation Notes =
1078	1078
1079	1079	== 7.1 Structural Definition Metadata ==
...	...	@@ -1094,109 +1094,72 @@
1094	1094
1095	1095	The following table lists the Maintainable Artefacts.
1096	1096
1097		-|(% colspan="4" %)**Maintainable Artefacts**|(% colspan="2" %)**Content**|
1098		-|(% colspan="2" %)**Abstract Class**|(% colspan="2" %)**Concrete Class**|(% colspan="2" %) |
1099		-|(% colspan="2" %)Item Scheme|(% colspan="2" %)Codelist|(% colspan="2" %)Code|
1100		-|(% colspan="2" %) |(% colspan="2" %)Concept Scheme|(% colspan="2" %)Concept|
1101		-|(% colspan="2" %) |(% colspan="2" %)Category Scheme|(% colspan="2" %)Category|
1102		-|(% colspan="2" %) |(% colspan="2" %)Organisation Unit Scheme|(% colspan="2" %)Organisation Unit|
1103		-|(% colspan="2" %) |(% colspan="2" %)Agency Scheme|(% colspan="2" %)Agency|
1104		-|(% colspan="2" %) |(% colspan="2" %)Data Provider Scheme|(% colspan="2" %)Data Provider|
1105		-|(% colspan="2" %) |(% colspan="2" %)Data Consumer Scheme|(% colspan="2" %)Data Consumer|
1106		-|(% colspan="2" %) |(% colspan="2" %)Reporting Taxonomy|(% colspan="2" %)Reporting Category|
1107		-|(% colspan="2" %) |(% colspan="2" %)Transformation Scheme|(% colspan="2" %)Transformation|
1108		-|(% colspan="2" %) |(% colspan="2" %)Custom Type Scheme|(% colspan="2" %)Custom Type|
1109		-| |(% colspan="4" %)**Maintainable Artefacts**|(% colspan="2" %)**Content**
1110		-| |(% colspan="2" %)**Abstract Class**|(% colspan="2" %)**Concrete Class**|(% colspan="2" %)
1111		-| |(% colspan="2" %) |(% colspan="2" %)Name Personalisation Scheme|(% colspan="2" %)Name Personalisation
1112		-| |(% colspan="2" %) |(% colspan="2" %)Vtl Mapping Scheme|(% colspan="2" %)Vtl Codelist Mapping
1113		-| |(% colspan="2" %) |(% colspan="2" %) |(% colspan="2" %)Vtl Concept Mapping
1114		-| |(% colspan="2" %) |(% colspan="2" %) |(% colspan="2" %)Vtl Dataflow Mapping
1115		-| |(% colspan="2" %) |(% colspan="2" %) |(% colspan="2" %)(((
1116		-Vtl Concept Scheme
1117		-
1118		-Mapping
1119		-)))
1120		-| |(% colspan="2" %) |(% colspan="2" %)Ruleset Scheme|(% colspan="2" %)Ruleset
1121		-| |(% colspan="2" %) |(% colspan="2" %)User Defined Operator Scheme|(% colspan="2" %)User Defined Operator
1122		-| |(% colspan="2" %) |(% colspan="2" %) |(% colspan="2" %)
1123		-| |(% colspan="2" %)Structure|(% colspan="2" %)Data Structure Definition|(% colspan="2" %)(((
	985	+(% style="width:640.294px" %)
	986	+|(% colspan="2" rowspan="1" style="width:186px" %)**Maintainable Artefacts**|(% style="width:206px" %)**Content**
	987	+|(% style="width:171px" %)**Abstract Class**|(% style="width:232px" %)**Concrete Class**|(% style="width:206px" %)
	988	+|(% style="width:171px" %)Item Scheme|(% style="width:232px" %)Codelist|(% style="width:206px" %)Code
	989	+|(% style="width:171px" %) |(% style="width:232px" %)Concept Scheme|(% style="width:206px" %)Concept
	990	+|(% style="width:171px" %) |(% style="width:232px" %)Category Scheme|(% style="width:206px" %)Category
	991	+|(% style="width:171px" %) |(% style="width:232px" %)Organisation Unit Scheme|(% style="width:206px" %)Organisation Unit
	992	+|(% style="width:171px" %) |(% style="width:232px" %)Agency Scheme|(% style="width:206px" %)Agency
	993	+|(% style="width:171px" %) |(% style="width:232px" %)Data Provider Scheme|(% style="width:206px" %)Data Provider
	994	+|(% style="width:171px" %) |(% style="width:232px" %)Data Consumer Scheme|(% style="width:206px" %)Data Consumer
	995	+|(% style="width:171px" %) |(% style="width:232px" %)Reporting Taxonomy|(% style="width:206px" %)Reporting Category
	996	+|(% style="width:171px" %) |(% style="width:232px" %)Transformation Scheme|(% style="width:206px" %)Transformation
	997	+|(% style="width:171px" %) |(% style="width:232px" %)Custom Type Scheme|(% style="width:206px" %)Custom Type
	998	+|(% style="width:171px" %) |(% style="width:232px" %)Name Personalisation Scheme|(% style="width:206px" %)Name Personalisation
	999	+|(% style="width:171px" %) |(% style="width:232px" %)Vtl Mapping Scheme|(% style="width:206px" %)Vtl Codelist Mapping
	1000	+|(% style="width:171px" %) |(% style="width:232px" %) |(% style="width:206px" %)Vtl Dataflow Mapping
	1001	+|(% style="width:171px" %) |(% style="width:232px" %) |(% style="width:206px" %)Vtl Concept Scheme Mapping
	1002	+|(% style="width:171px" %) |(% style="width:232px" %)Ruleset Scheme|(% style="width:206px" %)Ruleset
	1003	+|(% style="width:171px" %) |(% style="width:232px" %)User Defined Operator Scheme|(% style="width:206px" %)User Defined Operator
	1004	+|(% style="width:171px" %) |(% style="width:232px" %) |(% style="width:206px" %)User Defined Operator
	1005	+|(% style="width:171px" %)Structure|(% style="width:232px" %)Data Structure Definition|(% style="width:206px" %)(((
1124	1124	Dimension Descriptor
1125		-
1126	1126	Group Dimension
1127		-
1128	1128	Descriptor
1129		-
1130	1130	Dimension
1131		-
1132	1132	Measure Dimension
1133		-
1134	1134	Time Dimension
1135		-
1136	1136	Attribute Descriptor
1137		-
1138	1138	Data Attribute
1139		-
1140	1140	Measure Descriptor
1141		-
1142	1142	Primary Measure
1143	1143	)))
1144		-| |(% colspan="2" %) |(% colspan="2" %)Metadata Structure Definition|(% colspan="2" %)(((
1145		-Metadata Target,
1146		-
1147		-Dimension Descriptor
1148		-
	1017	+|(% style="width:171px" %) |(% style="width:232px" %)Metadata Structure Definition|(% style="width:206px" %)(((
	1018	+Metadata Target, Dimension Descriptor
1149	1149	Values Target Identifiable
1150		-
1151	1151	Object Target
1152		-
1153	1153	Report Period Target
1154		-
1155	1155	Data SetTarget
1156		-
1157	1157	Report Structure
1158		-
1159	1159	Metadata Attribute
1160	1160	)))
1161		-| |(% colspan="2" %)Structure Usage|(% colspan="2" %)Dataflow Definition|(% colspan="2" %)
1162		-| |(% colspan="2" %) |(% colspan="2" %)Metadataflow Definition|(% colspan="2" %)
1163		-| |(% colspan="2" %)None|(% colspan="2" %)Process|(% colspan="2" %)Process Step
1164		-| |(% colspan="2" %)None|(% colspan="2" %)Structure Set|(% colspan="2" %)(((
	1026	+|(% style="width:171px" %)Structure Usage|(% style="width:232px" %)Dataflow Definition|(% style="width:206px" %)
	1027	+|(% style="width:171px" %) |(% style="width:232px" %)Metadataflow Definition|(% style="width:206px" %)
	1028	+|(% style="width:171px" %)None|(% style="width:232px" %)Process|(% style="width:206px" %)Process Step
	1029	+|(% style="width:171px" %)None|(% style="width:232px" %)Structure Set|(% style="width:206px" %)(((
1165	1165	Component Map
1166		-
1167	1167	Concept Scheme Map
1168		-
1169	1169	Codelist Map
1170		-
1171	1171	Category Scheme Map
1172		-
1173	1173	Reporting Taxonomy Map
1174		-
1175	1175	Organisation Scheme Map
1176		-
1177	1177	Concept Map
1178		-
1179	1179	Code Map
1180		-
1181	1181	Category Map
1182		-
1183	1183	Organisation Map
1184		-
1185	1185	Reporting Category Map
1186		-
1187	1187	Hybrid Codelist Map
1188		-
1189	1189	Hybrid Code Map
1190	1190	)))
1191		-| |(% colspan="2" %)None|(% colspan="2" %)Provision Agreement|(% colspan="2" %)
1192		-| |(% colspan="2" %)None|(% colspan="2" %)Hierarchical Codelist|(% colspan="2" %)(((
	1044	+|(% style="width:171px" %)None|(% style="width:232px" %)Provision Agreement|(% style="width:206px" %)
	1045	+|(% style="width:171px" %)None|(% style="width:232px" %)Hierarchical Codelist|(% style="width:206px" %)(((
1193	1193	Hierarchy
1194		-
1195	1195	Hierarchical Code
1196	1196	)))
1197		-| | | | | | |
1198	1198
1199		-**Table 4: Table of Maintainable Artefacts for Structural Definition Metadata**
	1050	+**able 4: Table of Maintainable Artefacts for Structural Definition Metadata**
1200	1200
1201	1201	=== 7.1.2 Item Scheme, Structure ===
1202	1202
...	...	@@ -1203,10 +1203,7 @@
1203	1203	The artefacts included in the structural definitions are:
1204	1204
1205	1205	* All types of Item Scheme (Codelist, Concept Scheme, Category Scheme, Organisation Scheme - Agency Scheme, Data Provider Scheme, Data Consumer Scheme, Organisation Unit Scheme)
1206		-* All types of Structure (Data Structure Definition, Metadata Structure
1207		-
1208		-Definition)
1209		-
	1057	+* All types of Structure (Data Structure Definition, Metadata Structure Definition)
1210	1210	* All types of Structure Usage (Dataflow Definition, Metadataflow Definition)
1211	1211
1212	1212	=== 7.1.3 Structure Usage ===
...	...	@@ -1225,6 +1225,8 @@
1225	1225
1226	1226	==== 7.1.3.3 Structure Usage Model ====
1227	1227
	1076	+[[image:1747829078194-749.png]]
	1077	+
1228	1228	**Figure 10: SDMX-IM of links from Structure Usage to Category**
1229	1229
1230	1230	In addition to the maintenance of the Dataflow Definition and the Metadataflow Definition the following links must be maintained in the registry:
...	...	@@ -1251,10 +1251,10 @@
1251	1251
1252	1252	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.
1253	1253
	1104	+[[image:1747829109466-595.png]]
1254	1254
1255	1255	**Figure 11: SDMX-IM of the Data Provider**
1256	1256
1257		-
1258	1258	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
1259	1259
1260	1260	[[image:1747824123019-181.jpeg]]
...	...	@@ -1263,8 +1263,10 @@
1263	1263
1264	1264	The diagram below is a logical representation of the data required in order to maintain Provision Agreements.
1265	1265
	1116	+[[image:1747829139951-378.png]]
1266	1266
1267		-==== Figure 13: Logical class diagram of the information contained in the Provision Agreement ====
	1118	+(% class="wikigeneratedid" id="HFigure13:LogicalclassdiagramoftheinformationcontainedintheProvisionAgreement" %)
	1119	+**Figure 13: Logical class diagram of the information contained in the Provision Agreement**
1268	1268
1269	1269	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.
1270	1270
...	...	@@ -1292,13 +1292,12 @@
1292	1292
1293	1293	=== 7.3.3 Data and Metadata Constraints: Model ===
1294	1294
	1147	+[[image:1747829204737-370.png]]
1295	1295
	1149	+**Figure 15: Logical class diagram showing inheritance between and reference to constrainable artifacts**
1296	1296
1297		-==== Figure 15: Logical class diagram showing inheritance between and reference to constrainable artifacts ====
	1151	+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.
1298	1298
1299		-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.
1300		-
1301		-
1302	1302	The content of the Constraint can be found in the SDMX Information Model document.
1303	1303
1304	1304	== 7.4 Data and Metadata Registration ==
...	...	@@ -1319,7 +1319,7 @@
1319	1319
1320	1320	[[image:1747824123025-411.jpeg]]
1321	1321
1322		- **Figure 16: Schematic of the Objects Concerned with Registration**
	1173	+**Figure 16: Schematic of the Objects Concerned with Registration**
1323	1323
1324	1324	==== 7.4.2.2 Registration Request Model ====
1325	1325
...	...	@@ -1333,11 +1333,14 @@
1333	1333
1334	1334	The Registration has an action attribute which takes one of the following values:
1335	1335
1336		-|**Action Attribute Value**|**Behaviour**
1337		-|Append|Add this Registration to the registry
1338		-|Replace|Replace the existing Registration with identified by the id in the Registration of the Submit Registration Request
1339		-|Delete|Delete the existing Registration identified by the id in the Registration of the Submit Registration Request
	1187	+(% style="width:970.294px" %)
	1188	+|(% style="width:212px" %)**Action Attribute Value**|(% style="width:756px" %)**Behaviour**
	1189	+|(% style="width:212px" %)Append|(% style="width:756px" %)Add this Registration to the registry
	1190	+|(% style="width:212px" %)Replace|(% style="width:756px" %)Replace the existing Registration with identified by the id in the Registration of the Submit Registration Request
	1191	+|(% style="width:212px" %)Delete|(% style="width:756px" %)Delete the existing Registration identified by the id in the Registration of the Submit Registration Request
1340	1340
	1193	+[[image:1747829290890-122.png]]
	1194	+
1341	1341	**Figure 17: Logical Class Diagram of Registration of Data and Metadata**
1342	1342
1343	1343	The Query Datasource is an abstract class that represents a data source which can understand an SDMX-ML query (SOAPDatasource) or RESTful query
...	...	@@ -1352,25 +1352,19 @@
1352	1352
1353	1353	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.
1354	1354
1355		-|**Indexing Required**|**Registration Process Activity**
1356		-|indexTimeSeries|Extract all the series keys and create a KeySet(s) Constraint.
1357		-|indexDataSet|(((
1358		-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
1359		-
1360		-Regions containing Member Selections of Dimension Components of the Constraints model in the SDMX-IM, and the associated Selection Value.
	1209	+|(% style="width:185px" %)**Indexing Required**|(% style="width:1686px" %)**Registration Process Activity**
	1210	+|(% style="width:185px" %)indexTimeSeries|(% style="width:1686px" %)Extract all the series keys and create a KeySet(s) Constraint.
	1211	+|(% style="width:185px" %)indexDataSet|(% style="width:1686px" %)(((
	1212	+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.
1361	1361	)))
1362		-|indexReportingPeriod|(((
	1214	+|(% style="width:185px" %)indexReportingPeriod|(% style="width:1686px" %)(((
1363	1363	This applies only to a registered dataset.
1364		-
1365	1365	Extract the Reporting Begin and Reporting End from the Header of the Message containing the data set, and create a Reference Period constraint.
1366	1366	)))
1367		-|indexAttributes|(((
	1218	+|(% style="width:185px" %)indexAttributes|(% style="width:1686px" %)(((
1368	1368	**Data Set**
1369		-
1370	1370	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
1371		-
1372	1372	**Metadata Set**
1373		-
1374	1374	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.
1375	1375	)))
1376	1376
...	...	@@ -1380,14 +1380,13 @@
1380	1380
1381	1381	=== 7.4.3 Registration Response ===
1382	1382
1383		-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
	1231	+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”.
1384	1384
1385		-“Success”, “Warning” or “Failure”.
1386		-
1387	1387	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.
1388	1388
1389	1389	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:
1390	1390
	1237	+[[image:1747829477882-750.png]]
1391	1391
1392	1392	**Figure 18: Logical class diagram showing the registration response**
1393	1393
...	...	@@ -1397,15 +1397,12 @@
1397	1397
1398	1398	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.
1399	1399
1400		-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
	1247	+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”.
1401	1401
1402		-“notification”.
	1249	+=== 7.5.1Subscription Logical Class Diagram ===
1403	1403
1404		- 7.5.1Subscription Logical Class Diagram
	1251	+[[image:1747829554603-150.png]]
1405	1405
1406		-
1407		-[[image:1747824123028-257.png]]
1408		-
1409	1409	**Figure 19: Logical Class Diagram of the Subscription**
1410	1410
1411	1411	=== 7.5.2 Subscription Information ===
...	...	@@ -1412,73 +1412,58 @@
1412	1412
1413	1413	Regardless of the type of registry/repository events being observed, a subscription always contains:
1414	1414
1415		-~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.
	1259	+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.
	1260	+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.
	1261	+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.
	1262	+1. A selector which specifies which type of events are of interest. The set of event types is:
1416	1416
1417		-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.
	1264	+|(% style="width:327px" %)**Event Type**|(% style="width:1545px" %)**Comment**
	1265	+|(% style="width:327px" %)STRUCTURAL_REPOSITORY_EVENTS|(% style="width:1545px" %)Life-cycle changes to Maintainable Artefacts in the structural metadata repository.
	1266	+|(% style="width:327px" %)DATA_REGISTRATION_EVENTS|(% style="width:1545px" %)Whenever a published dataset is registered. This can be either a SDMXML data file or an SDMX conformant database.
	1267	+|(% style="width:327px" %)METADATA_REGISTRATION_EVENTS|(% style="width:1545px" %)Whenever a published metadataset is registered. This can be either a SDMXML reference metadata file or an SDMX conformant database.
	1268	+|(% style="width:327px" %)ALL_EVENTS|(% style="width:1545px" %)All events of the specified EventType
1418	1418
1419		-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.
1420		-
1421		-4. A selector which specifies which type of events are of interest. The set of event types is:
1422		-
1423		-|**Event Type**|**Comment**
1424		-|STRUCTURAL_REPOSITORY_EVENTS|Life-cycle changes to Maintainable Artefacts in the structural metadata repository.
1425		-|DATA_REGISTRATION_EVENTS|Whenever a published dataset is registered. This can be either a SDMXML data file or an SDMX conformant database.
1426		-|METADATA_REGISTRATION_EVENTS|Whenever a published metadataset is registered. This can be either a SDMXML reference metadata file or an SDMX conformant database.
1427		-|ALL_EVENTS|All events of the specified EventType
1428		-
1429	1429	=== 7.5.3 Wildcard Facility ===
1430	1430
1431	1431	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:
1432	1432
1433		- agencyID
	1274	+* agencyID
	1275	+* id
	1276	+* version
1434	1434
1435		- id
1436		-
1437		- version
1438		-
1439	1439	Examples of wildcarded identifier components for an identified object type of Codelist are shown below.
1440	1440
1441		-AgencyID = %
1442		-
	1280	+//AgencyID = %
1443	1443	Id = %
	1282	+Version = %//
1444	1444
1445		-Version = %
1446		-
1447	1447	This subscribes to all Codelists of all versions for all agencies.
1448	1448
1449		-AgencyID = AGENCY1
1450		-
	1286	+//AgencyID = AGENCY1
1451	1451	Id = CODELIST1
	1288	+Version = %//
1452	1452
1453		-Version = %
1454		-
1455	1455	This subscribes to all versions of Codelist CODELIST1 maintained by the agency
1456	1456
1457		-AGENCY1
1458		-
	1292	+//AGENCY1
1459	1459	AgencyID = AGENCY1
1460		-
1461	1461	Id = %
	1295	+Version = %//
1462	1462
1463		-Version = %
1464		-
1465	1465	This subscribes to all versions of all Codelist objects maintained by the agency
1466	1466
1467		-AGENCY1
1468		-
	1299	+//AGENCY1
1469	1469	AgencyID = %
1470		-
1471	1471	Id = CODELIST1
	1302	+Version = %//
1472	1472
1473		-Version = %
1474		-
1475	1475	This subscribes to all versions of Codelist CODELIST1 maintained by the agency
1476	1476
1477		-AGENCY1
	1306	+//AGENCY1//
1478	1478
1479	1479	Note that if the subscription is to the latest version then this can be achieved by the * character
1480	1480
1481		-i.e. Version = *
	1310	+//i.e. Version = *//
1482	1482
1483	1483	Note that a subscription using the URN mechanism cannot use wildcard characters.
1484	1484
...	...	@@ -1490,16 +1490,15 @@
1490	1490
1491	1491	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:
1492	1492
	1322	+|(% style="width:405px" %)**Selector**|(% style="width:1467px" %)**Comment**
	1323	+|(% style="width:405px" %)DataProvider|(% style="width:1467px" %)Any datasets or metadata sets registered by the specified data provider will activate the notification.
	1324	+|(% style="width:405px" %)ProvisionAgreement|(% style="width:1467px" %)Any datasets or metadata sets registered for the provision agreement will activate the notification.
	1325	+|(% style="width:405px" %)Dataflow (&Metadataflow)|(% style="width:1467px" %)Any datasets or metadata sets registered for the specified dataflow (or metadataflow) will activate the notification.
	1326	+|(% 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
	1327	+|(% style="width:405px" %)**Selector**|(% style="width:1467px" %)**Comment**
	1328	+|(% style="width:405px" %) |(% style="width:1467px" %)activate the notification.
	1329	+|(% 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.
1493	1493
1494		-|**Selector**|**Comment**
1495		-|DataProvider|Any datasets or metadata sets registered by the specified data provider will activate the notification.
1496		-|ProvisionAgreement|Any datasets or metadata sets registered for the provision agreement will activate the notification.
1497		-|Dataflow (&Metadataflow)|Any datasets or metadata sets registered for the specified dataflow (or metadataflow) will activate the notification.
1498		-|DataStructureDefinition & MetadataStructureDefinition|Any datasets or metadata sets registered for those dataflows (or metadataflows) that are based on the specified Data Structure Definition will
1499		-|**Selector**|**Comment**
1500		-| |activate the notification.
1501		-|Category|Any datasets or metadata sets registered for those dataflows, metadataflows, provision agreements that are categorised by the category.
1502		-
1503	1503	The event will also capture the semantic of the registration: deletion or replacement of an existing registration or a new registration.
1504	1504
1505	1505	== 7.6 Notification ==
...	...	@@ -1506,8 +1506,10 @@
1506	1506
1507	1507	=== 7.6.1 Logical Class Diagram ===
1508	1508
	1337	+[[image:1747829675568-610.png]]
1509	1509
1510		-==== Figure 20: Logical Class Diagram of the Notification ====
	1339	+(% class="wikigeneratedid" id="HFigure20:LogicalClassDiagramoftheNotification" %)
	1340	+**Figure 20: Logical Class Diagram of the Notification**
1511	1511
1512	1512	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.
1513	1513
...	...	@@ -1527,5 +1527,3 @@
1527	1527	=== 7.6.3 Registration Event Component ===
1528	1528
1529	1529	The notification will contain the Registration.
1530		-
1531		-

1747824504225-229.png

Author

...	...	@@ -1,0 +1,1 @@
	1	+xwiki:XWiki.helena

Size

...	...	@@ -1,0 +1,1 @@
	1	+52.8 KB

Content

1747829078194-749.png

Author

...	...	@@ -1,0 +1,1 @@
	1	+xwiki:XWiki.helena

Size

...	...	@@ -1,0 +1,1 @@
	1	+40.4 KB

Content

1747829109466-595.png

Author

...	...	@@ -1,0 +1,1 @@
	1	+xwiki:XWiki.helena

Size

...	...	@@ -1,0 +1,1 @@
	1	+30.4 KB

Content

1747829139951-378.png

Author

...	...	@@ -1,0 +1,1 @@
	1	+xwiki:XWiki.helena

Size

...	...	@@ -1,0 +1,1 @@
	1	+21.1 KB

Content

1747829204737-370.png

Author

...	...	@@ -1,0 +1,1 @@
	1	+xwiki:XWiki.helena

Size

...	...	@@ -1,0 +1,1 @@
	1	+55.8 KB

Content

1747829290890-122.png

Author

...	...	@@ -1,0 +1,1 @@
	1	+xwiki:XWiki.helena

Size

...	...	@@ -1,0 +1,1 @@
	1	+41.4 KB

Content

1747829477882-750.png

Author

...	...	@@ -1,0 +1,1 @@
	1	+xwiki:XWiki.helena

Size

...	...	@@ -1,0 +1,1 @@
	1	+24.6 KB

Content

1747829554603-150.png

Author

...	...	@@ -1,0 +1,1 @@
	1	+xwiki:XWiki.helena

Size

...	...	@@ -1,0 +1,1 @@
	1	+99.1 KB

Content

1747829675568-610.png

Author

...	...	@@ -1,0 +1,1 @@
	1	+xwiki:XWiki.helena

Size

...	...	@@ -1,0 +1,1 @@
	1	+31.1 KB

Content