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, 8 added, 0 removed)
  • 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,27 +288,25 @@
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		-|(% style="width:249px" %)(((
	296	+(% style="margin-left:auto; margin-right:auto" %)
	297	+|(% style="width:200px" %)(((
296	296	**Action Attribute Value**
297		-)))|(% style="width:1622px" %)**Behaviour**
298		-|(% style="width:249px" %)Append|(% style="width:1622px" %)Add this registration to the registry
299		-|(% style="width:249px" %)Replace|(% style="width:1622px" %)Replace the existing Registration with this Registration identified by the id in the Registration of the Submit Registration Request
300		-|(% style="width:249px" %)Delete|(% style="width:1622px" %)Delete the existing Registration identified by the id in the Registration of the Submit Registration Request
301		-
	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
302	302	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:
303		-
304		-|**Boolean Attribute**|**Behaviour if Value is “true”**
305		-|indexTimeSeries|A compliant indexing application must index all the time series keys (for a Dataset registration) or metadata target values (for a Metadata Set registration)
306		-|indexDataSet|(((
	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" %)(((
307	307	A compliant indexing application must index the range of actual (present) values for each dimension of the Dataset (for a Dataset registration) or the range of actual (present) values for each Metadata Attribute which takes an enumerated value.
308		-
309	309	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
310	310	)))
311		-|indexReportingPeriod|A compliant indexing application must index the time period range(s) for which data are present in the Dataset or Metadata Set
	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
312	312
313	313	=== 5.2.5 Data and Reference Metadata Discovery ===
314	314
...	...	@@ -340,8 +340,8 @@
340	340
341	341	The following table defines the behaviour of the SDMX Registry for the various Registry Interface messages.
342	342
343		-|(% style="width:143px" %)**Interface**|(% style="width:1729px" %)**Behaviour**
344		-|(% style="width:143px" %)All|(% style="width:1729px" %)(((
	342	+|(% style="width:227px" %)**Interface**|(% style="width:1644px" %)**Behaviour**
	343	+|(% style="width:227px" %)All|(% style="width:1644px" %)(((
345	345	1) If the action is set to “replace” then the entire contents of the existing maintainable object in the Registry MUST be replaced by the object submitted, unless the final attribute is set to “true” in which case the only changes that are allowed are to the following constructs:
346	346
347	347	* Name – this applies to the Maintainable object and its contained elements, such a Code in a Code list.
...	...	@@ -355,7 +355,6 @@
355	355	* isExternalReference
356	356
357	357	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.
358		-
359	359	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:
360	360
361	361	а) Not have the final attribute set to “true”
...	...	@@ -362,14 +362,12 @@
362	362	b) Not be referenced from any other object in the Registry.
363	363
364	364	4) The version rules in the SDMX Schema documentation MUST be obeyed.
365		-
366	366	5) The specific rules for the elements and attributes documented in the SDMX Schema MUST be obeyed.
367	367	)))
368		-|(% style="width:143px" %)SubmitStructureRequest|(% style="width:1729px" %)Structures are submitted at the level of the Maintainable Artefact and the behaviour in “All” above is therefore at the level of the Maintainable Artefact.
369		-|(% style="width:143px" %)SubmitProvisioningRequest|(% style="width:1729px" %)No additional behaviour.
370		-|(% style="width:143px" %)Submit Registration Request|(% style="width:1729px" %)(((
	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" %)(((
371	371	If the datasource is a file (simple datasource) then the file MAY be retrieved and indexed according to the Boolean attributes set in the Registration.
372		-
373	373	For a queryable datasource the Registry MAY validate that the source exists and can accept an SDMX-ML data query.
374	374	)))
375	375
...	...	@@ -470,9 +470,10 @@
470	470
471	471	An example of this is shown in the XML snippet below.
472	472
473		-[[image:1747824123013-196.jpeg]]
	469	+[[image:1747824123013-196.jpeg||height="309" width="446"]]
474	474
475		-==== Figure 8: Example Showing Use of Agency Identifiers ====
	471	+(% class="wikigeneratedid" id="HFigure8:ExampleShowingUseofAgencyIdentifiers" %)
	472	+**Figure 8: Example Showing Use of Agency Identifiers**
476	476
477	477	Each of these maintenance agencies has an identical Code list with the Id CL_BOP. However, each is uniquely identified by means of the hierarchic agency structure.
478	478
...	...	@@ -490,7 +490,7 @@
490	490
491	491	The generic structure of the URN is as follows:
492	492
493		-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
494	494
495	495	~* this can repeat and may not be present (see explanation below)
496	496
...	...	@@ -502,7 +502,7 @@
502	502
503	503	In the explanation below the actual object that is the target of the URN is called the **//actual object//**.
504	504
505		-**SDMXPrefix:** urn:sdmx:org.
	502	+**SDMXPrefix:** urn:sdmx:org.
506	506
507	507	**SDMX-IM package name:** sdmx.infomodel.package=
508	508
...	...	@@ -512,10 +512,8 @@
512	512
513	513	**(maintainable-object-version)** is the version of the maintainable object and is enclosed in round brackets (). It will always be present.
514	514
515		-**container-object-id** is the identifier of an intermediary object that contains the actual object which the URN is identifying. It is not mandatory as many actual objects do not have an intermediary container object. For instance, a Code is in a maintained object (Code List) and has no intermediary container object, whereas a Metadata Attribute has an intermediary container object (Report Structure) and may have an intermediary container object which is its parent Metadata Attribute. For this reason the container object id may repeat, with each repetition identifying the object at the next-lower level in its hierarchy. Note that if there is only a single containing object in the model then it is NOT included in the URN structure. This applies to Attribute Descriptor, Dimension Descriptor, and Measure Descriptor where there can be only one such object and this object has a fixed id. Therefore, whilst each of these has a
	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.
516	516
517		-URN, the id of the Attribute Descriptor, Dimension Descriptor, and Measure Descriptor is not included when the actual object is a Data Attribute or a Dimension/Measure Dimension/ Time Dimension, or a Measure.
518		-
519	519	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.
520	520
521	521	For example the sequence is agency:DSDid(version).DimensionId and not agency:DSDid(version).DimensionDescriptorId.DimensionId.
...	...	@@ -522,58 +522,57 @@
522	522
523	523	**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.
524	524
525		-===== //Generic Examples of the URN Structure// =====
	520	+===== __**//Generic Examples of the URN Structure//**__ =====
526	526
	522	+__Actual object is a maintainable__
527	527
528		-Actual object is a maintainable
	524	+> SDMXPrefix.SDMX-IM package name.classname=agency id:maintained-object-id(version)
529	529
530		-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__
531	531
532		-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
533	533
534		-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__
535	535
536		-Actual object is contained in a maintained object with an intermediate containing object
	532	+> SDMXPrefix.SDMX-IM package name.classname=agency
537	537
538		-SDMXPrefix.SDMX-IM package name.classname=agency
539		-
540	540	id:maintained-object-id(version).contained-object-id.object-id
541	541
542		-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__
543	543
544	544	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
545	545
546		-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
547	547
548		-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__
549	549
550	550	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
551	551
552		-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
553	553
554		-===== //Concrete Examples of the URN Structure// =====
	548	+===== __**//Concrete Examples of the URN Structure//**__ =====
555	555
556	556	The Data Structure Definition CRED_EXT_DEBT version 1.0 maintained by the top level Agency TFFS would have the URN:
557	557
558		-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)
559	559
560	560	The URN for a code for Argentina maintained by ISO in the code list CL_3166A2 version 1.0 would be:
561	561
562		-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
563	563
564	564	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:
565	565
566		-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
567	567
568	568	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
569	569
570	570	CONTACT_DETAILS/CONTACT_NAME would be:
571	571
572		-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
573	573
574	574	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:
575	575
576		-urn:sdmx:org.sdmx.infomodel.datastructure.Dataflow=TFFS.ABC:EX
	570	+> urn:sdmx:org.sdmx.infomodel.datastructure.Dataflow=TFFS.ABC:EX
577	577
578	578	TERNAL_DEBT(1.0)
579	579
...	...	@@ -588,112 +588,94 @@
588	588
589	589	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.
590	590
591		-|**Package**|(((
592		-**URN Classname (model classname**
593		-
594		-**where this is different)**
	585	+|(% style="width:127px" %)**Package**|(% style="width:1745px" %)(((
	586	+**URN Classname (model classname where this is different)**
595	595	)))
596		-|base|Agency
597		-| |OrganisationUnitScheme
598		-| |AgencyScheme
599		-| |DataProviderScheme
600		-| |DataConsumerScheme
601		-| |OrganisationUnit
602		-| |DataProvider
603		-| |DataConsumer
604		-| |
605		-|datastructure|DataStructure (DataStructureDefinition)
606		-| |AttributeDescriptor
607		-| |DataAttribute
608		-| |GroupDimensionDescriptor
609		-| |DimensionDescriptor
610		-| |Dimension
611		-| |MeasureDimension
612		-| |TimeDimension
613		-| |MeasureDescriptor
614		-| |PrimaryMeasure
615		-| |Dataflow (DataflowDefinition)
616		-| |
617		-|metadatastructure|MetadataTarget
618		-| |DimensionDescriptorValueTarget
619		-| |IdentifiableObjectTarget
620		-| |ReportPeriodTarget
621		-| |DataSetTarget
622		-| |ReportStructure
623		-| |MetadataAttribute
624		-| |(((
	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" %)(((
625	625	MetadataStructure
626	626
627	627	(MetadataStructureDefinition)
628	628	)))
629		-| |Metadataflow (MetadataflowDefinition)
630		-| |
631		-|process|Process
632		-| |ProcessStep
633		-| |Transition
634		-| |
635		-|registry|ProvisionAgreement
636		-| |AttachmentConstraint
637		-| |ContentConstraint
638		-| |Subscription
639		-| |
640		-|mapping|StructureMap
641		-| |StructureSet
642		-| |ComponentMap
643		-|**Package**|(((
644		-**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
645	645
646		-**where this is different)**
647		-)))
648		-| |ConceptSchemeMap
649		-| |OrganisationSchemeMap
650		-| |CodelistMap
651		-| |CategorySchemeMap
652		-| |ReportingTaxonomyMap
653		-| |ConceptMap
654		-| |OrganisationMap
655		-| |CodeMap
656		-| |HybridCodelistMap
657		-| |CategoryMap
658		-| |HybridCodeMap
659		-| |ReportingCategoryMap
660		-| |
661		-|codelist|Codelist
662		-| |HierarchicalCodelist
663		-| |Hierarchy
664		-| |Hierarchy
665		-| |Code
666		-| |HierarchicalCode
667		-| |Level
668		-| |
669		-|categoryscheme|CategoryScheme
670		-| |Category
671		-| |Categorisation
672		-| |ReportingTaxonomy
673		-| |ReportingCategory
674		-| |
675		-|conceptscheme|ConceptScheme
676		-| |Concept
677		-| |
678		-|transformation|TransformationScheme
679		-| |Transformation
680		-| |CustomTypeScheme
681		-| |CustomType
682		-| |NamePersonalisationScheme
683		-| |NamePersonalisation
684		-| |VtlCodelistMapping
685		-| |VtlConceptMapping
686		-| |VtlDataflowMapping
687		-| |VtlConceptSchemeMapping
688		-| |RulesetScheme
689		-| |Ruleset
690		-| |UserDefinedOperatorScheme
691		-| |UserDefinedOperator
692		-| |
693		-
694	694	**Table 2: SDMX-IM Packages and Contained Classes**
695	695
696		-
697	697	=== 6.2.4 URN Identification components of SDMX objects ===
698	698
699	699	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.
...	...	@@ -702,78 +702,52 @@
702	702
703	703	Note that for brevity the URN examples omit the prefix. All URNs have the prefix
704	704
705		-urn:sdmx.org.sdmx.infomodel.{package}.{classname}=
	681	+> urn:sdmx.org.sdmx.infomodel.{package}.{classname}=
706	706
707		-
708		-|**SDMX Class**|**Key attribute(s)**|**Example of URN**
709		-|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" %)(((
710	710	IMF
711		-
712		-
713	713	Sub agency in the IMF AGENCIES
714		-
715		-
716	716	IMF.SubAgency1
717	717	)))
718		-|*ConceptScheme|conceptSchemeAgencyId:conceptSchemeId(ve rsion)|SDMX:CROSS_DOMAIN_CONCEPTS(1.0)
719		-|Concept|(((
720		-conceptSchemeAgencyId:
721		-
722		-conceptSchemeId(version).conceptId
723		-)))|SDMX:CROSS_DOMAIN_CONCEPTS(1.0).FREQ
724		-|*Codelist|codeListAgencyId:codeListId(version)|SDMX:CL_FREQ(1.0)
725		-|Code|codeListAgencyId:codelistId(version).codeId|(((
726		-SDMX:CL_FREQ(1.0).Q
727		-
728		-
	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" %))
729	729	)))
730		-
731		-
732		-
733		-|(((
734		-*Hierarchical
735		-
736		-Codelist
737		-)))|hierachicalCodelistAgencyId: hierarchicalCodelistId(version)|(((
738		-UNESCO:CL_EXP_SOURCE(1.0)
739		-
740		-
741		-)))
742		-|Hierarchy|(((
	700	+|(% style="width:250px" %)Hierarchy|(% style="width:444px" %)(((
743	743	hierachicalcodeListAgencyId:
744		-
745	745	hierarchicalcodelistId(version).Hierarchy
746		-)))|UNESCO:CL_EXP_SOURCE(1.0). H-C-GOV
747		-|Level|(((
	703	+)))|(% style="width:396px" %)UNESCO:CL_EXP_SOURCE(1.0).
	704	+H-C-GOV
	705	+|(% style="width:250px" %)Level|(% style="width:444px" %)(((
748	748	hierachicalcodeListAgencyId:
749		-
750	750	hierarchicalcodelistId(version).Hierarchy.Level
751		-)))|(((
	708	+)))|(% style="width:396px" %)(((
752	752	ESTAT:HCL_REGION(1.0).H_1.COUNTRY
753	753
754	754
755	755	)))
756		-|HierarchicalCode|hierachicalCodeListAgencyId: hierarchicalcodelistId(version).hierarchy.hierarc hicalCode|UNESCO:CL_EXP_SOURCE(1.0). H-C-GOV.GOV_CODE1
757		-|*DataStructure|dataStructureDefintitionAgencyId: dataStructureDefintitionId(version)|TFFS:EXT_DEBT(1.0)
758		-|(((
	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" %)(((
759	759	Dimension
760		-
761	761	Descriptor
762		-
763	763	Measure
764		-
765	765	Descriptor
766		-
767	767	Attribute
768		-
769	769	Descriptor
770		-)))|(((
	722	+)))|(% style="width:444px" %)(((
771	771	dataStructureDefinitionAgencyId: dataStructureDefinitionId(version).
772		-
773	773	componentListId
774		-
775	775	where the componentListId is the name of the class (there is only one occurrence of each in the Data Structure Definition)
776		-)))|(((
	726	+)))|(% style="width:396px" %)(((
777	777	TFFS:EXT_DEBT(1.0).DimensionDescriptor
778	778
779	779	TFFS:EXT_DEBT(1.0).MeasureDescriptor
...	...	@@ -780,181 +780,132 @@
780	780
781	781	TFFS:EXT_DEBT(1.0).AttributeDescriptor
782	782	)))
783		-|(((
	733	+|(% style="width:250px" %)(((
784	784	GroupDimension
785		-
786	786	Descriptor
787		-)))|(((
	736	+)))|(% style="width:444px" %)(((
788	788	dataStructureDefinitionAgencyId: dataStructureDefinitionId(version).
789		-
790	790	groupDimensionDescriptorId
791		-)))|TFFS:EXT_DEBT(1.0).SIBLING
792		-|Dimension|(((
	739	+)))|(% style="width:396px" %)TFFS:EXT_DEBT(1.0).SIBLING
	740	+|(% style="width:250px" %)Dimension|(% style="width:444px" %)(((
793	793	dataStructureDefinitionAgencyId: dataStructureDefinition (version).
794		-
795	795	dimensionId
796		-)))|TFFS:EXT_DEBT(1.0).FREQ
797		-|TimeDimension|(((
	743	+)))|(% style="width:396px" %)TFFS:EXT_DEBT(1.0).FREQ
	744	+|(% style="width:250px" %)TimeDimension|(% style="width:444px" %)(((
798	798	dataStructureDefinitionAgencyId: dataStructureDefinition (version).
799		-
800	800	timeDimensionId
801		-)))|TFFS:EXT_DEBT(1.0).TIME_PERIOD
802		-|Measure Dimension|dataStructureDefinitionAgencyId: dataStructureDefinition (version).|TFFS:EXT_DEBT(1.0).STOCK_FLOW
803		-
804		-
805		-
806		-| |measureDimensionId|
807		-|DataAttrribute|dataStructureDefinitionAgencyId: dataStructureDefinition (version). dataAttributeId|TFFS:EXT_DEBT(1.0).OBS_STATUS
808		-|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" %)(((
809	809	dataStructureDefinitionAgencyId: dataStructureDefinition (version).
810		-
811	811	primaryMeasureId
812		-)))|TFFS:EXT_DEBT(1.0).OBS_VALUE
813		-|(((
814		-*Category
815		-
816		-Scheme
817		-)))|categorySchemeAgencyId: categorySchemeId(version)|IMF:SDDS(1.0)
818		-|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" %)(((
819	819	IMF:SDDS(1.0):
820		-
821	821	level_1_category.level_2_category …
822	822	)))
823		-|(((
824		-*Reporting
825		-
826		-Taxonomy
827		-)))|reportingTaxonomyAgencyId: reportingTaxonomyId(version)| IMF:REP_1(1.0)
828		-|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" %)(((
829	829	IMF:REP_1(1.0):
830		-
831	831	level_1_repcategory.level_2_repcategory …
832	832	)))
833		-|*Categorisation|categorisationAgencyId: categorisationId(version)|IMF:cat001(1.0)
834		-|(((
835		-*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)
836	836
837		-Unit Scheme
838		-)))|organisationUnitSchemeAgencyId: organisationUnitSchemeId(version)|ECB:ORGANISATIONS(1.0)
839		-|Organisation Unit|organisationUnitSchemeAgencyId: organisationUnitSchemeId(version). organisationUnitId|ECB:ORGANISATIONS(1.0).1F
840		-|*AgencyScheme|agencySchemeAgencyId: agencySchemeId(version)|ECB:AGENCIES(1.0)
841		-
842		-
843		-
844		-|Agency|agencySchemeAgencyId: agencySchemeId(version). agencyId|ECB:AGENCY(1.0).AA
845		-|(((
846		-*DataProvider
847		-
848		-Scheme
849		-)))|dataProviderSchemeAgencyId: dataProviderSchemeId(version)|SDMX:DATA_PROVIDERS(1.0)
850		-|DataProvider|dataProviderSchemeAgencyId: dataProviderSchemeId(version) dataProviderId|SDMX:DATA_PROVIDERS(1.0).PROVIDER_1
851		-|(((
852		-*DataConsumer
853		-
854		-Scheme
855		-)))|dataConsumerSchemeAgencyId: dataConsumerSchemeId(version)|SDMX:DATA_CONSUMERS(1.0)
856		-|Data Consumer|dataConsumerSchemeAgencyId: dataConsumerSchemeId(version) dataConsumerId|SDMX:DATA_CONSUMERS(1.0).CONSUMER_1
857		-|(((
858		-*Metadata
859		-
860		-Structure
861		-)))|MSDAgencyId:MSDId(version)|IMF:SDDS_MSD(1.0)
862		-|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" %)(((
863	863	MSDAgencyId:
864		-
865	865	MSDId(version).metadataTargetId
866		-)))|IMF:SDDS_MSD(1.0).AGENCY
867		-|(((
	794	+)))|(% style="width:1262px" %)IMF:SDDS_MSD(1.0).AGENCY
	795	+|(% style="width:262px" %)(((
868	868	Dimension
869		-
870	870	DescriptorValues
871		-
872	872	Target
873		-)))|(((
	799	+)))|(% style="width:369px" %)(((
874	874	MSDAgencyId: MSDId(version).
875		-
876	876	metadataTargetId.keyDescriptorValueTargetId
877		-)))|IMF:SDDS_MSD(1.0).AGENCY.KEY
878		-|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" %)(((
879	879	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
880	880
881		-MSDId(version).metadataTargetId.identifiable
882		-
883		-ObjectTargetId
884		-)))|IMF:SDDS_MSD(1.0).AGENCY.STR-OBJECT
885		-|DataSetTarget|(((
886		-MSDAgencyId:
887		-
888		-MSDId(version).metadataTargetId.dataSet
889		-
890		-TargetId
891		-)))|IMF:SDDS_MSD(1.0).AGENCY.D1101
892		-|PeportPeriod Target|(((
893		-MSDAgencyId:
894		-
895		-MSDId(version).metadataTargetId.reportPeriod
896		-
897		-TargetId
898		-)))|IMF:SDDS_MSD(1.0).AGENCY.REP_PER
899		-
900		-
901		-
902		-|(((
	814	+|(% style="width:251px" %)(((
903	903	ReportStructure
904	904
905	905
906		-)))|(((
907		-MSDAgencyId:
908		-
909		-MSDId(version).reportStructureId
910		-)))|IMF:SDDS_MSD(1.0).AGENCY_REPORT
911		-|(((
	818	+)))|(% style="width:442px" %)(((
	819	+MSDAgencyId: MSDId(version).reportStructureId
	820	+)))|(% style="width:1178px" %)IMF:SDDS_MSD(1.0).AGENCY_REPORT
	821	+|(% style="width:251px" %)(((
912	912	Metadata
913	913
914	914	Attribute
915		-)))|(((
916		-MSDAgencyId:
917		-
918		-MSDId(version).reportStructureId.metadataattri buteID
919		-)))|IMF:SDDS_MSD(1.0).AGENCY_REPORT.COMPILATION
920		-|*Dataflow|dataflowAgencyId: dataflowId(version)|TFFS:CRED_EXT_DEBT(1.0)
921		-|*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" %)(((
922	922	provisionAgreementAgencyId:provisionAgreem entId(version)
923		-
924		-
925		-)))|(((
	831	+)))|(% style="width:1178px" %)(((
926	926	TFFS:CRED_EXT_DEBT_AB(1.0)
927		-
928		-
929		-
930	930	)))
931		-|(((
	834	+|(% style="width:251px" %)(((
932	932	*Content
933	933
934	934	Constraint
935		-)))|constraintAgencyId:ContentConstraintId(versio n)|TFFS:CREDITOR_DATA_CONTENT(1.0)
936		-|(((
	838	+)))|(% style="width:442px" %)constraintAgencyId:ContentConstraintId(versio n)|(% style="width:1178px" %)TFFS:CREDITOR_DATA_CONTENT(1.0)
	839	+|(% style="width:251px" %)(((
937	937	*Attachment
938	938
939	939	Constraint
940		-)))|(((
	843	+)))|(% style="width:442px" %)(((
941	941	constraintAgencyId:
942	942
943	943	attachmentConstraintId(version)
944		-)))|TFFS:CREDITOR_DATA_ATTACHMENT_CONSTRAINT_ONE(1.0)
945		-|*Metadataflow|metadataflowAgencyId: metadataflowId(version)|IMF:SDDS_FLOW(1.0)
946		-|*StructureSet|structureSetAgencyId: structureSetId(version)|SDMX:BOP_STRUCTURES(1.0)
947		-|StructureMap|structureSetAgencyId: structureSetId(version). structureMapId|SDMX:BOP_STRUCTURES(1.0).TABLE1_TABLE2
948		-|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" %)(((
949	949	structureSetAgencyId: structureSetId(version).
950	950
951	951	structureMapId. componentMapId
952		-)))|SDMX:BOP_STRUCTURES(1.0).TABLE1_TABLE2. REFAREA_REPCOUNTRY
953		-|CodelistMap|structureSetAgencyId: structureSetId(version). codelistMapId|SDMX:BOP_STRUCTURES(1.0).CLREFAREA_CLREPCOUNTRY
954		-|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
955	955
956		-
957		-
958	958	| |(((
959	959	codeListMapId.
960	960
...	...	@@ -1062,7 +1062,6 @@
1062	1062
1063	1063	7**Table 3: Table of identification components for SDMX Identifiable Artefacts**
1064	1064
1065		-
1066	1066	= 7 Implementation Notes =
1067	1067
1068	1068	== 7.1 Structural Definition Metadata ==
...	...	@@ -1083,109 +1083,72 @@
1083	1083
1084	1084	The following table lists the Maintainable Artefacts.
1085	1085
1086		-|(% colspan="4" %)**Maintainable Artefacts**|(% colspan="2" %)**Content**|
1087		-|(% colspan="2" %)**Abstract Class**|(% colspan="2" %)**Concrete Class**|(% colspan="2" %) |
1088		-|(% colspan="2" %)Item Scheme|(% colspan="2" %)Codelist|(% colspan="2" %)Code|
1089		-|(% colspan="2" %) |(% colspan="2" %)Concept Scheme|(% colspan="2" %)Concept|
1090		-|(% colspan="2" %) |(% colspan="2" %)Category Scheme|(% colspan="2" %)Category|
1091		-|(% colspan="2" %) |(% colspan="2" %)Organisation Unit Scheme|(% colspan="2" %)Organisation Unit|
1092		-|(% colspan="2" %) |(% colspan="2" %)Agency Scheme|(% colspan="2" %)Agency|
1093		-|(% colspan="2" %) |(% colspan="2" %)Data Provider Scheme|(% colspan="2" %)Data Provider|
1094		-|(% colspan="2" %) |(% colspan="2" %)Data Consumer Scheme|(% colspan="2" %)Data Consumer|
1095		-|(% colspan="2" %) |(% colspan="2" %)Reporting Taxonomy|(% colspan="2" %)Reporting Category|
1096		-|(% colspan="2" %) |(% colspan="2" %)Transformation Scheme|(% colspan="2" %)Transformation|
1097		-|(% colspan="2" %) |(% colspan="2" %)Custom Type Scheme|(% colspan="2" %)Custom Type|
1098		-| |(% colspan="4" %)**Maintainable Artefacts**|(% colspan="2" %)**Content**
1099		-| |(% colspan="2" %)**Abstract Class**|(% colspan="2" %)**Concrete Class**|(% colspan="2" %)
1100		-| |(% colspan="2" %) |(% colspan="2" %)Name Personalisation Scheme|(% colspan="2" %)Name Personalisation
1101		-| |(% colspan="2" %) |(% colspan="2" %)Vtl Mapping Scheme|(% colspan="2" %)Vtl Codelist Mapping
1102		-| |(% colspan="2" %) |(% colspan="2" %) |(% colspan="2" %)Vtl Concept Mapping
1103		-| |(% colspan="2" %) |(% colspan="2" %) |(% colspan="2" %)Vtl Dataflow Mapping
1104		-| |(% colspan="2" %) |(% colspan="2" %) |(% colspan="2" %)(((
1105		-Vtl Concept Scheme
1106		-
1107		-Mapping
1108		-)))
1109		-| |(% colspan="2" %) |(% colspan="2" %)Ruleset Scheme|(% colspan="2" %)Ruleset
1110		-| |(% colspan="2" %) |(% colspan="2" %)User Defined Operator Scheme|(% colspan="2" %)User Defined Operator
1111		-| |(% colspan="2" %) |(% colspan="2" %) |(% colspan="2" %)
1112		-| |(% 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" %)(((
1113	1113	Dimension Descriptor
1114		-
1115	1115	Group Dimension
1116		-
1117	1117	Descriptor
1118		-
1119	1119	Dimension
1120		-
1121	1121	Measure Dimension
1122		-
1123	1123	Time Dimension
1124		-
1125	1125	Attribute Descriptor
1126		-
1127	1127	Data Attribute
1128		-
1129	1129	Measure Descriptor
1130		-
1131	1131	Primary Measure
1132	1132	)))
1133		-| |(% colspan="2" %) |(% colspan="2" %)Metadata Structure Definition|(% colspan="2" %)(((
1134		-Metadata Target,
1135		-
1136		-Dimension Descriptor
1137		-
	1018	+|(% style="width:171px" %) |(% style="width:232px" %)Metadata Structure Definition|(% style="width:206px" %)(((
	1019	+Metadata Target, Dimension Descriptor
1138	1138	Values Target Identifiable
1139		-
1140	1140	Object Target
1141		-
1142	1142	Report Period Target
1143		-
1144	1144	Data SetTarget
1145		-
1146	1146	Report Structure
1147		-
1148	1148	Metadata Attribute
1149	1149	)))
1150		-| |(% colspan="2" %)Structure Usage|(% colspan="2" %)Dataflow Definition|(% colspan="2" %)
1151		-| |(% colspan="2" %) |(% colspan="2" %)Metadataflow Definition|(% colspan="2" %)
1152		-| |(% colspan="2" %)None|(% colspan="2" %)Process|(% colspan="2" %)Process Step
1153		-| |(% 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" %)(((
1154	1154	Component Map
1155		-
1156	1156	Concept Scheme Map
1157		-
1158	1158	Codelist Map
1159		-
1160	1160	Category Scheme Map
1161		-
1162	1162	Reporting Taxonomy Map
1163		-
1164	1164	Organisation Scheme Map
1165		-
1166	1166	Concept Map
1167		-
1168	1168	Code Map
1169		-
1170	1170	Category Map
1171		-
1172	1172	Organisation Map
1173		-
1174	1174	Reporting Category Map
1175		-
1176	1176	Hybrid Codelist Map
1177		-
1178	1178	Hybrid Code Map
1179	1179	)))
1180		-| |(% colspan="2" %)None|(% colspan="2" %)Provision Agreement|(% colspan="2" %)
1181		-| |(% 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" %)(((
1182	1182	Hierarchy
1183		-
1184	1184	Hierarchical Code
1185	1185	)))
1186		-| | | | | | |
1187	1187
1188		-**Table 4: Table of Maintainable Artefacts for Structural Definition Metadata**
	1051	+**able 4: Table of Maintainable Artefacts for Structural Definition Metadata**
1189	1189
1190	1190	=== 7.1.2 Item Scheme, Structure ===
1191	1191
...	...	@@ -1192,10 +1192,7 @@
1192	1192	The artefacts included in the structural definitions are:
1193	1193
1194	1194	* All types of Item Scheme (Codelist, Concept Scheme, Category Scheme, Organisation Scheme - Agency Scheme, Data Provider Scheme, Data Consumer Scheme, Organisation Unit Scheme)
1195		-* All types of Structure (Data Structure Definition, Metadata Structure
1196		-
1197		-Definition)
1198		-
	1058	+* All types of Structure (Data Structure Definition, Metadata Structure Definition)
1199	1199	* All types of Structure Usage (Dataflow Definition, Metadataflow Definition)
1200	1200
1201	1201	=== 7.1.3 Structure Usage ===
...	...	@@ -1214,6 +1214,8 @@
1214	1214
1215	1215	==== 7.1.3.3 Structure Usage Model ====
1216	1216
	1077	+[[image:1747829078194-749.png]]
	1078	+
1217	1217	**Figure 10: SDMX-IM of links from Structure Usage to Category**
1218	1218
1219	1219	In addition to the maintenance of the Dataflow Definition and the Metadataflow Definition the following links must be maintained in the registry:
...	...	@@ -1240,10 +1240,10 @@
1240	1240
1241	1241	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.
1242	1242
	1105	+[[image:1747829109466-595.png]]
1243	1243
1244	1244	**Figure 11: SDMX-IM of the Data Provider**
1245	1245
1246		-
1247	1247	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
1248	1248
1249	1249	[[image:1747824123019-181.jpeg]]
...	...	@@ -1252,8 +1252,10 @@
1252	1252
1253	1253	The diagram below is a logical representation of the data required in order to maintain Provision Agreements.
1254	1254
	1117	+[[image:1747829139951-378.png]]
1255	1255
1256		-==== 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**
1257	1257
1258	1258	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.
1259	1259
...	...	@@ -1281,13 +1281,12 @@
1281	1281
1282	1282	=== 7.3.3 Data and Metadata Constraints: Model ===
1283	1283
	1148	+[[image:1747829204737-370.png]]
1284	1284
	1150	+**Figure 15: Logical class diagram showing inheritance between and reference to constrainable artifacts**
1285	1285
1286		-==== 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.
1287	1287
1288		-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.
1289		-
1290		-
1291	1291	The content of the Constraint can be found in the SDMX Information Model document.
1292	1292
1293	1293	== 7.4 Data and Metadata Registration ==
...	...	@@ -1308,7 +1308,7 @@
1308	1308
1309	1309	[[image:1747824123025-411.jpeg]]
1310	1310
1311		- **Figure 16: Schematic of the Objects Concerned with Registration**
	1174	+**Figure 16: Schematic of the Objects Concerned with Registration**
1312	1312
1313	1313	==== 7.4.2.2 Registration Request Model ====
1314	1314
...	...	@@ -1322,11 +1322,14 @@
1322	1322
1323	1323	The Registration has an action attribute which takes one of the following values:
1324	1324
1325		-|**Action Attribute Value**|**Behaviour**
1326		-|Append|Add this Registration to the registry
1327		-|Replace|Replace the existing Registration with identified by the id in the Registration of the Submit Registration Request
1328		-|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
1329	1329
	1194	+[[image:1747829290890-122.png]]
	1195	+
1330	1330	**Figure 17: Logical Class Diagram of Registration of Data and Metadata**
1331	1331
1332	1332	The Query Datasource is an abstract class that represents a data source which can understand an SDMX-ML query (SOAPDatasource) or RESTful query
...	...	@@ -1341,25 +1341,19 @@
1341	1341
1342	1342	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.
1343	1343
1344		-|**Indexing Required**|**Registration Process Activity**
1345		-|indexTimeSeries|Extract all the series keys and create a KeySet(s) Constraint.
1346		-|indexDataSet|(((
1347		-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
1348		-
1349		-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.
1350	1350	)))
1351		-|indexReportingPeriod|(((
	1215	+|(% style="width:185px" %)indexReportingPeriod|(% style="width:1686px" %)(((
1352	1352	This applies only to a registered dataset.
1353		-
1354	1354	Extract the Reporting Begin and Reporting End from the Header of the Message containing the data set, and create a Reference Period constraint.
1355	1355	)))
1356		-|indexAttributes|(((
	1219	+|(% style="width:185px" %)indexAttributes|(% style="width:1686px" %)(((
1357	1357	**Data Set**
1358		-
1359	1359	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
1360		-
1361	1361	**Metadata Set**
1362		-
1363	1363	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.
1364	1364	)))
1365	1365
...	...	@@ -1369,14 +1369,13 @@
1369	1369
1370	1370	=== 7.4.3 Registration Response ===
1371	1371
1372		-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”.
1373	1373
1374		-“Success”, “Warning” or “Failure”.
1375		-
1376	1376	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.
1377	1377
1378	1378	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:
1379	1379
	1238	+[[image:1747829477882-750.png]]
1380	1380
1381	1381	**Figure 18: Logical class diagram showing the registration response**
1382	1382
...	...	@@ -1386,15 +1386,12 @@
1386	1386
1387	1387	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.
1388	1388
1389		-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”.
1390	1390
1391		-“notification”.
	1250	+=== 7.5.1Subscription Logical Class Diagram ===
1392	1392
1393		- 7.5.1Subscription Logical Class Diagram
	1252	+[[image:1747829554603-150.png]]
1394	1394
1395		-
1396		-[[image:1747824123028-257.png]]
1397		-
1398	1398	**Figure 19: Logical Class Diagram of the Subscription**
1399	1399
1400	1400	=== 7.5.2 Subscription Information ===
...	...	@@ -1401,73 +1401,58 @@
1401	1401
1402	1402	Regardless of the type of registry/repository events being observed, a subscription always contains:
1403	1403
1404		-~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:
1405	1405
1406		-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
1407	1407
1408		-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.
1409		-
1410		-4. A selector which specifies which type of events are of interest. The set of event types is:
1411		-
1412		-|**Event Type**|**Comment**
1413		-|STRUCTURAL_REPOSITORY_EVENTS|Life-cycle changes to Maintainable Artefacts in the structural metadata repository.
1414		-|DATA_REGISTRATION_EVENTS|Whenever a published dataset is registered. This can be either a SDMXML data file or an SDMX conformant database.
1415		-|METADATA_REGISTRATION_EVENTS|Whenever a published metadataset is registered. This can be either a SDMXML reference metadata file or an SDMX conformant database.
1416		-|ALL_EVENTS|All events of the specified EventType
1417		-
1418	1418	=== 7.5.3 Wildcard Facility ===
1419	1419
1420	1420	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:
1421	1421
1422		- agencyID
	1275	+* agencyID
	1276	+* id
	1277	+* version
1423	1423
1424		- id
1425		-
1426		- version
1427		-
1428	1428	Examples of wildcarded identifier components for an identified object type of Codelist are shown below.
1429	1429
1430		-AgencyID = %
1431		-
	1281	+//AgencyID = %
1432	1432	Id = %
	1283	+Version = %//
1433	1433
1434		-Version = %
1435		-
1436	1436	This subscribes to all Codelists of all versions for all agencies.
1437	1437
1438		-AgencyID = AGENCY1
1439		-
	1287	+//AgencyID = AGENCY1
1440	1440	Id = CODELIST1
	1289	+Version = %//
1441	1441
1442		-Version = %
1443		-
1444	1444	This subscribes to all versions of Codelist CODELIST1 maintained by the agency
1445	1445
1446		-AGENCY1
1447		-
	1293	+//AGENCY1
1448	1448	AgencyID = AGENCY1
1449		-
1450	1450	Id = %
	1296	+Version = %//
1451	1451
1452		-Version = %
1453		-
1454	1454	This subscribes to all versions of all Codelist objects maintained by the agency
1455	1455
1456		-AGENCY1
1457		-
	1300	+//AGENCY1
1458	1458	AgencyID = %
1459		-
1460	1460	Id = CODELIST1
	1303	+Version = %//
1461	1461
1462		-Version = %
1463		-
1464	1464	This subscribes to all versions of Codelist CODELIST1 maintained by the agency
1465	1465
1466		-AGENCY1
	1307	+//AGENCY1//
1467	1467
1468	1468	Note that if the subscription is to the latest version then this can be achieved by the * character
1469	1469
1470		-i.e. Version = *
	1311	+//i.e. Version = *//
1471	1471
1472	1472	Note that a subscription using the URN mechanism cannot use wildcard characters.
1473	1473
...	...	@@ -1479,16 +1479,15 @@
1479	1479
1480	1480	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:
1481	1481
	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.
1482	1482
1483		-|**Selector**|**Comment**
1484		-|DataProvider|Any datasets or metadata sets registered by the specified data provider will activate the notification.
1485		-|ProvisionAgreement|Any datasets or metadata sets registered for the provision agreement will activate the notification.
1486		-|Dataflow (&Metadataflow)|Any datasets or metadata sets registered for the specified dataflow (or metadataflow) will activate the notification.
1487		-|DataStructureDefinition & MetadataStructureDefinition|Any datasets or metadata sets registered for those dataflows (or metadataflows) that are based on the specified Data Structure Definition will
1488		-|**Selector**|**Comment**
1489		-| |activate the notification.
1490		-|Category|Any datasets or metadata sets registered for those dataflows, metadataflows, provision agreements that are categorised by the category.
1491		-
1492	1492	The event will also capture the semantic of the registration: deletion or replacement of an existing registration or a new registration.
1493	1493
1494	1494	== 7.6 Notification ==
...	...	@@ -1495,8 +1495,10 @@
1495	1495
1496	1496	=== 7.6.1 Logical Class Diagram ===
1497	1497
	1338	+[[image:1747829675568-610.png]]
1498	1498
1499		-==== Figure 20: Logical Class Diagram of the Notification ====
	1340	+(% class="wikigeneratedid" id="HFigure20:LogicalClassDiagramoftheNotification" %)
	1341	+**Figure 20: Logical Class Diagram of the Notification**
1500	1500
1501	1501	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.
1502	1502
...	...	@@ -1516,5 +1516,3 @@
1516	1516	=== 7.6.3 Registration Event Component ===
1517	1517
1518	1518	The notification will contain the Registration.
1519		-
1520		-

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