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

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

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