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,22 @@
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		-3The Registration has an action attribute which takes one of the following values:
	294	+The Registration has an action attribute which takes one of the following values:
294	294
295		-|(% style="width:249px" %)(((
296		-**Action Attribute Value**
297		-)))|(% style="width:1622px" %)**Behaviour**
298		-|(% style="width:249px" %)Append|(% style="width:1622px" %)Add this registration to the registry
299		-|(% style="width:249px" %)Replace|(% style="width:1622px" %)Replace the existing Registration with this Registration identified by the id in the Registration of the Submit Registration Request
300		-|(% style="width:249px" %)Delete|(% style="width:1622px" %)Delete the existing Registration identified by the id in the Registration of the Submit Registration Request
	296	+|(% style="width:219px" %)**Action Attribute Value**|(% style="width:1652px" %)**Behaviour**
	297	+|(% style="width:219px" %)Append|(% style="width:1652px" %)Add this registration to the registry
	298	+|(% style="width:219px" %)Replace|(% style="width:1652px" %)Replace the existing Registration with this Registration identified by the id in the Registration of the Submit Registration Request
	299	+|(% style="width:219px" %)Delete|(% style="width:1652px" %)Delete the existing Registration identified by the id in the Registration of the Submit Registration Request
301	301
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	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|(((
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		-
	303	+|(% style="width:228px" %)**Boolean Attribute**|(% style="width:1644px" %)**Behaviour if Value is “true”**
	304	+|(% style="width:228px" %)indexTimeSeries|(% style="width:1644px" %)A compliant indexing application must index all the time series keys (for a Dataset registration) or metadata target values (for a Metadata Set registration)
	305	+|(% style="width:228px" %)indexDataSet|(% style="width:1644px" %)A compliant indexing application must index the range of actual (present) values for each dimension of the Dataset (for a Dataset registration) or the range of actual (present) values for each Metadata Attribute which takes an enumerated value.
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		-)))
311		-|indexReportingPeriod|A compliant indexing application must index the time period range(s) for which data are present in the Dataset or Metadata Set
	307	+|(% style="width:228px" %)indexReportingPeriod|(% style="width:1644px" %)A compliant indexing application must index the time period range(s) for which data are present in the Dataset or Metadata Set
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" %)(((
	339	+|(% style="width:227px" %)**Interface**|(% style="width:1644px" %)**Behaviour**
	340	+|(% 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" %)(((
	362	+|(% style="width:227px" %)SubmitStructureRequest|(% style="width:1644px" %)Structures are submitted at the level of the Maintainable Artefact and the behaviour in “All” above is therefore at the level of the Maintainable Artefact.
	363	+|(% style="width:227px" %)SubmitProvisioningRequest|(% style="width:1644px" %)No additional behaviour.
	364	+|(% style="width:227px" %)Submit Registration Request|(% style="width:1644px" %)(((
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
...	...	@@ -455,7 +455,8 @@
455	455
456	456	[[image:1747824123012-527.jpeg]]
457	457
458		-==== Figure 7: Example of Hierarchic Structure of Agencies ====
	451	+*
	452	+** Figure 7: Example of Hierarchic Structure of Agencies
459	459
460	460	The following organizations maintain an Agency Scheme.
461	461
...	...	@@ -472,7 +472,6 @@
472	472
473	473	[[image:1747824123013-196.jpeg||height="309" width="446"]]
474	474
475		-(% class="wikigeneratedid" id="HFigure8:ExampleShowingUseofAgencyIdentifiers" %)
476	476	**Figure 8: Example Showing Use of Agency Identifiers**
477	477
478	478	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.
...	...	@@ -491,7 +491,7 @@
491	491
492	492	The generic structure of the URN is as follows:
493	493
494		-SDMXprefix.SDMX-IM-package-name.class-name=agencyid:maintainedobject-id(maintainedobject-version).*containerobject-id.object-id
	487	+>SDMXprefix.SDMX-IM-package-name.class-name=agencyid:maintainedobject-id(maintainedobject-version).*containerobject-id.object-id
495	495
496	496	~* this can repeat and may not be present (see explanation below)
497	497
...	...	@@ -503,7 +503,7 @@
503	503
504	504	In the explanation below the actual object that is the target of the URN is called the **//actual object//**.
505	505
506		-**SDMXPrefix:** urn:sdmx:org.
	499	+**SDMXPrefix:** urn:sdmx:org.
507	507
508	508	**SDMX-IM package name:** sdmx.infomodel.package=
509	509
...	...	@@ -513,10 +513,8 @@
513	513
514	514	**(maintainable-object-version)** is the version of the maintainable object and is enclosed in round brackets (). It will always be present.
515	515
516		-**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
	509	+**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.
517	517
518		-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.
519		-
520	520	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.
521	521
522	522	For example the sequence is agency:DSDid(version).DimensionId and not agency:DSDid(version).DimensionDescriptorId.DimensionId.
...	...	@@ -523,58 +523,57 @@
523	523
524	524	**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.
525	525
526		-===== //Generic Examples of the URN Structure// =====
	517	+===== __**//Generic Examples of the URN Structure//**__ =====
527	527
	519	+__Actual object is a maintainable__
528	528
529		-Actual object is a maintainable
	521	+> SDMXPrefix.SDMX-IM package name.classname=agency id:maintained-object-id(version)
530	530
531		-SDMXPrefix.SDMX-IM package name.classname=agency id:maintained-object-id(version)
	523	+__Actual object is contained in a maintained object with no intermediate containing object__
532	532
533		-Actual object is contained in a maintained object with no intermediate containing object
	525	+> SDMXPrefix.SDMX-IM package name.classname=agency id:maintained-object-id(version).object-id
534	534
535		-SDMXPrefix.SDMX-IM package name.classname=agency id:maintained-object-id(version).object-id
	527	+__Actual object is contained in a maintained object with an intermediate containing object__
536	536
537		-Actual object is contained in a maintained object with an intermediate containing object
	529	+> SDMXPrefix.SDMX-IM package name.classname=agency
538	538
539		-SDMXPrefix.SDMX-IM package name.classname=agency
540		-
541	541	id:maintained-object-id(version).contained-object-id.object-id
542	542
543		-Actual object is contained in a maintained object with no intermediate containing object but the object type itself is hierarchical
	533	+__Actual object is contained in a maintained object with no intermediate containing object but the object type itself is hierarchical__
544	544
545	545	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
546	546
547		-SDMXPrefix.SDMX-IM package name.classname=agency id:maintained-object-id(version).contained-object-id.object-id
	537	+> SDMXPrefix.SDMX-IM package name.classname=agency id:maintained-object-id(version).contained-object-id.object-id
548	548
549		-Actual object is contained in a maintained object with an intermediate containing object and the object type itself is hierarchical
	539	+__Actual object is contained in a maintained object with an intermediate containing object and the object type itself is hierarchical__
550	550
551	551	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
552	552
553		-SDMXPrefix.SDMX-IM package name.classname=agency id:maintained-object-id(version).contained-object-id. contained-object-id contained-object-id.object-id
	543	+> SDMXPrefix.SDMX-IM package name.classname=agency id:maintained-object-id(version).contained-object-id. contained-object-id contained-object-id.object-id
554	554
555		-===== //Concrete Examples of the URN Structure// =====
	545	+===== __**//Concrete Examples of the URN Structure//**__ =====
556	556
557	557	The Data Structure Definition CRED_EXT_DEBT version 1.0 maintained by the top level Agency TFFS would have the URN:
558	558
559		-urn:sdmx:org.sdmx.infomodel.datastructure.DataStucture=TFFS:CRED_EXT_ DEBT(1.0)
	549	+> urn:sdmx:org.sdmx.infomodel.datastructure.DataStucture=TFFS:CRED_EXT_ DEBT(1.0)
560	560
561	561	The URN for a code for Argentina maintained by ISO in the code list CL_3166A2 version 1.0 would be:
562	562
563		-urn:sdmx:org.sdmx.infomodel.codelist.Code=ISO:CL_3166A2(1.0).AR
	553	+> urn:sdmx:org.sdmx.infomodel.codelist.Code=ISO:CL_3166A2(1.0).AR
564	564
565	565	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:
566	566
567		-urn:sdmx:org.sdmx.infomodel.categoryscheme.Category=SDMX:SUBJE CT_MATTER_DOMAINS(1.0).1.2
	557	+> urn:sdmx:org.sdmx.infomodel.categoryscheme.Category=SDMX:SUBJE CT_MATTER_DOMAINS(1.0).1.2
568	568
569	569	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
570	570
571	571	CONTACT_DETAILS/CONTACT_NAME would be:
572	572
573		-urn:sdmx:org.sdmx.infomodel.metadatastructure.MetadataAttribut e=SDMX:CONTACT_METADATA(1.0).CONTACT_REPORT.CONTACT_DETAILS.CO NTACT_NAME
	563	+> urn:sdmx:org.sdmx.infomodel.metadatastructure.MetadataAttribut e=SDMX:CONTACT_METADATA(1.0).CONTACT_REPORT.CONTACT_DETAILS.CO NTACT_NAME
574	574
575	575	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:
576	576
577		-urn:sdmx:org.sdmx.infomodel.datastructure.Dataflow=TFFS.ABC:EX
	567	+> urn:sdmx:org.sdmx.infomodel.datastructure.Dataflow=TFFS.ABC:EX
578	578
579	579	TERNAL_DEBT(1.0)
580	580
...	...	@@ -589,112 +589,94 @@
589	589
590	590	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.
591	591
592		-|**Package**|(((
593		-**URN Classname (model classname**
594		-
595		-**where this is different)**
	582	+|(% style="width:127px" %)**Package**|(% style="width:1745px" %)(((
	583	+**URN Classname (model classname where this is different)**
596	596	)))
597		-|base|Agency
598		-| |OrganisationUnitScheme
599		-| |AgencyScheme
600		-| |DataProviderScheme
601		-| |DataConsumerScheme
602		-| |OrganisationUnit
603		-| |DataProvider
604		-| |DataConsumer
605		-| |
606		-|datastructure|DataStructure (DataStructureDefinition)
607		-| |AttributeDescriptor
608		-| |DataAttribute
609		-| |GroupDimensionDescriptor
610		-| |DimensionDescriptor
611		-| |Dimension
612		-| |MeasureDimension
613		-| |TimeDimension
614		-| |MeasureDescriptor
615		-| |PrimaryMeasure
616		-| |Dataflow (DataflowDefinition)
617		-| |
618		-|metadatastructure|MetadataTarget
619		-| |DimensionDescriptorValueTarget
620		-| |IdentifiableObjectTarget
621		-| |ReportPeriodTarget
622		-| |DataSetTarget
623		-| |ReportStructure
624		-| |MetadataAttribute
625		-| |(((
	585	+|(% style="width:127px" %)base|(% style="width:45px" %)Agency
	586	+|(% style="width:127px" %) |(% style="width:45px" %)OrganisationUnitScheme
	587	+|(% style="width:127px" %) |(% style="width:45px" %)AgencyScheme
	588	+|(% style="width:127px" %) |(% style="width:45px" %)DataProviderScheme
	589	+|(% style="width:127px" %) |(% style="width:45px" %)DataConsumerScheme
	590	+|(% style="width:127px" %) |(% style="width:45px" %)OrganisationUnit
	591	+|(% style="width:127px" %) |(% style="width:45px" %)DataProvider
	592	+|(% style="width:127px" %) |(% style="width:45px" %)DataConsumer
	593	+|(% style="width:127px" %)datastructure|(% style="width:45px" %)DataStructure (DataStructureDefinition)
	594	+|(% style="width:127px" %) |(% style="width:45px" %)AttributeDescriptor
	595	+|(% style="width:127px" %) |(% style="width:45px" %)DataAttribute
	596	+|(% style="width:127px" %) |(% style="width:45px" %)GroupDimensionDescriptor
	597	+|(% style="width:127px" %) |(% style="width:45px" %)DimensionDescriptor
	598	+|(% style="width:127px" %) |(% style="width:45px" %)Dimension
	599	+|(% style="width:127px" %) |(% style="width:45px" %)MeasureDimension
	600	+|(% style="width:127px" %) |(% style="width:45px" %)TimeDimension
	601	+|(% style="width:127px" %) |(% style="width:45px" %)MeasureDescriptor
	602	+|(% style="width:127px" %) |(% style="width:45px" %)PrimaryMeasure
	603	+|(% style="width:127px" %) |(% style="width:45px" %)Dataflow (DataflowDefinition)
	604	+|(% style="width:127px" %)metadatastructure|(% style="width:45px" %)MetadataTarget
	605	+|(% style="width:127px" %) |(% style="width:45px" %)DimensionDescriptorValueTarget
	606	+|(% style="width:127px" %) |(% style="width:45px" %)IdentifiableObjectTarget
	607	+|(% style="width:127px" %) |(% style="width:45px" %)ReportPeriodTarget
	608	+|(% style="width:127px" %) |(% style="width:45px" %)DataSetTarget
	609	+|(% style="width:127px" %) |(% style="width:45px" %)ReportStructure
	610	+|(% style="width:127px" %) |(% style="width:45px" %)MetadataAttribute
	611	+|(% style="width:127px" %) |(% style="width:45px" %)(((
626	626	MetadataStructure
627	627
628	628	(MetadataStructureDefinition)
629	629	)))
630		-| |Metadataflow (MetadataflowDefinition)
631		-| |
632		-|process|Process
633		-| |ProcessStep
634		-| |Transition
635		-| |
636		-|registry|ProvisionAgreement
637		-| |AttachmentConstraint
638		-| |ContentConstraint
639		-| |Subscription
640		-| |
641		-|mapping|StructureMap
642		-| |StructureSet
643		-| |ComponentMap
644		-|**Package**|(((
645		-**URN Classname (model classname**
	616	+|(% style="width:127px" %) |(% style="width:45px" %)Metadataflow (MetadataflowDefinition)
	617	+|(% style="width:127px" %)process|(% style="width:45px" %)Process
	618	+|(% style="width:127px" %) |(% style="width:45px" %)ProcessStep
	619	+|(% style="width:127px" %) |(% style="width:45px" %)Transition
	620	+|(% style="width:127px" %)registry|(% style="width:45px" %)ProvisionAgreement
	621	+|(% style="width:127px" %) |(% style="width:45px" %)AttachmentConstraint
	622	+|(% style="width:127px" %) |(% style="width:45px" %)ContentConstraint
	623	+|(% style="width:127px" %) |(% style="width:45px" %)Subscription
	624	+|(% style="width:127px" %)mapping|(% style="width:45px" %)StructureMap
	625	+|(% style="width:127px" %) |(% style="width:45px" %)StructureSet
	626	+|(% style="width:127px" %) |(% style="width:45px" %)ComponentMap
	627	+|(% style="width:127px" %) |(% style="width:1745px" %)ConceptSchemeMap
	628	+|(% style="width:127px" %) |(% style="width:1745px" %)OrganisationSchemeMap
	629	+|(% style="width:127px" %) |(% style="width:1745px" %)CodelistMap
	630	+|(% style="width:127px" %) |(% style="width:1745px" %)CategorySchemeMap
	631	+|(% style="width:127px" %) |(% style="width:1745px" %)ReportingTaxonomyMap
	632	+|(% style="width:127px" %) |(% style="width:1745px" %)ConceptMap
	633	+|(% style="width:127px" %) |(% style="width:1745px" %)OrganisationMap
	634	+|(% style="width:127px" %) |(% style="width:1745px" %)CodeMap
	635	+|(% style="width:127px" %) |(% style="width:1745px" %)HybridCodelistMap
	636	+|(% style="width:127px" %) |(% style="width:1745px" %)CategoryMap
	637	+|(% style="width:127px" %) |(% style="width:1745px" %)HybridCodeMap
	638	+|(% style="width:127px" %) |(% style="width:1745px" %)ReportingCategoryMap
	639	+|(% style="width:127px" %)codelist|(% style="width:1745px" %)Codelist
	640	+|(% style="width:127px" %) |(% style="width:1745px" %)HierarchicalCodelist
	641	+|(% style="width:127px" %) |(% style="width:1745px" %)Hierarchy
	642	+|(% style="width:127px" %) |(% style="width:1745px" %)Hierarchy
	643	+|(% style="width:127px" %) |(% style="width:1745px" %)Code
	644	+|(% style="width:127px" %) |(% style="width:1745px" %)HierarchicalCode
	645	+|(% style="width:127px" %) |(% style="width:1745px" %)Level
	646	+|(% style="width:127px" %)categoryscheme|(% style="width:1745px" %)CategoryScheme
	647	+|(% style="width:127px" %) |(% style="width:1745px" %)Category
	648	+|(% style="width:127px" %) |(% style="width:1745px" %)Categorisation
	649	+|(% style="width:127px" %) |(% style="width:1745px" %)ReportingTaxonomy
	650	+|(% style="width:127px" %) |(% style="width:1745px" %)ReportingCategory
	651	+|(% style="width:127px" %)conceptscheme|(% style="width:1745px" %)ConceptScheme
	652	+|(% style="width:127px" %) |(% style="width:1745px" %)Concept
	653	+|(% style="width:127px" %)transformation|(% style="width:1745px" %)TransformationScheme
	654	+|(% style="width:127px" %) |(% style="width:1745px" %)Transformation
	655	+|(% style="width:127px" %) |(% style="width:1745px" %)CustomTypeScheme
	656	+|(% style="width:127px" %) |(% style="width:1745px" %)CustomType
	657	+|(% style="width:127px" %) |(% style="width:1745px" %)NamePersonalisationScheme
	658	+|(% style="width:127px" %) |(% style="width:1745px" %)NamePersonalisation
	659	+|(% style="width:127px" %) |(% style="width:1745px" %)VtlCodelistMapping
	660	+|(% style="width:127px" %) |(% style="width:1745px" %)VtlConceptMapping
	661	+|(% style="width:127px" %) |(% style="width:1745px" %)VtlDataflowMapping
	662	+|(% style="width:127px" %) |(% style="width:1745px" %)VtlConceptSchemeMapping
	663	+|(% style="width:127px" %) |(% style="width:1745px" %)RulesetScheme
	664	+|(% style="width:127px" %) |(% style="width:1745px" %)Ruleset
	665	+|(% style="width:127px" %) |(% style="width:1745px" %)UserDefinedOperatorScheme
	666	+|(% style="width:127px" %) |(% style="width:1745px" %)UserDefinedOperator
646	646
647		-**where this is different)**
648		-)))
649		-| |ConceptSchemeMap
650		-| |OrganisationSchemeMap
651		-| |CodelistMap
652		-| |CategorySchemeMap
653		-| |ReportingTaxonomyMap
654		-| |ConceptMap
655		-| |OrganisationMap
656		-| |CodeMap
657		-| |HybridCodelistMap
658		-| |CategoryMap
659		-| |HybridCodeMap
660		-| |ReportingCategoryMap
661		-| |
662		-|codelist|Codelist
663		-| |HierarchicalCodelist
664		-| |Hierarchy
665		-| |Hierarchy
666		-| |Code
667		-| |HierarchicalCode
668		-| |Level
669		-| |
670		-|categoryscheme|CategoryScheme
671		-| |Category
672		-| |Categorisation
673		-| |ReportingTaxonomy
674		-| |ReportingCategory
675		-| |
676		-|conceptscheme|ConceptScheme
677		-| |Concept
678		-| |
679		-|transformation|TransformationScheme
680		-| |Transformation
681		-| |CustomTypeScheme
682		-| |CustomType
683		-| |NamePersonalisationScheme
684		-| |NamePersonalisation
685		-| |VtlCodelistMapping
686		-| |VtlConceptMapping
687		-| |VtlDataflowMapping
688		-| |VtlConceptSchemeMapping
689		-| |RulesetScheme
690		-| |Ruleset
691		-| |UserDefinedOperatorScheme
692		-| |UserDefinedOperator
693		-| |
694		-
695	695	**Table 2: SDMX-IM Packages and Contained Classes**
696	696
697		-
698	698	=== 6.2.4 URN Identification components of SDMX objects ===
699	699
700	700	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.
...	...	@@ -703,78 +703,50 @@
703	703
704	704	Note that for brevity the URN examples omit the prefix. All URNs have the prefix
705	705
706		-urn:sdmx.org.sdmx.infomodel.{package}.{classname}=
	678	+> urn:sdmx.org.sdmx.infomodel.{package}.{classname}=
707	707
708		-
709		-|**SDMX Class**|**Key attribute(s)**|**Example of URN**
710		-|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.|(((
	680	+(% style="width:1091.29px" %)
	681	+|(% style="width:250px" %)**SDMX Class**|(% style="width:444px" %)**Key attribute(s)**|(% style="width:396px" %)**Example of URN**
	682	+|(% 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" %)(((
711	711	IMF
712		-
713		-
714	714	Sub agency in the IMF AGENCIES
715		-
716		-
717	717	IMF.SubAgency1
718	718	)))
719		-|*ConceptScheme|conceptSchemeAgencyId:conceptSchemeId(ve rsion)|SDMX:CROSS_DOMAIN_CONCEPTS(1.0)
720		-|Concept|(((
721		-conceptSchemeAgencyId:
722		-
723		-conceptSchemeId(version).conceptId
724		-)))|SDMX:CROSS_DOMAIN_CONCEPTS(1.0).FREQ
725		-|*Codelist|codeListAgencyId:codeListId(version)|SDMX:CL_FREQ(1.0)
726		-|Code|codeListAgencyId:codelistId(version).codeId|(((
727		-SDMX:CL_FREQ(1.0).Q
728		-
729		-
	687	+|(% style="width:250px" %)*ConceptScheme|(% style="width:444px" %)conceptSchemeAgencyId:conceptSchemeId(ve rsion)|(% style="width:396px" %)SDMX:CROSS_DOMAIN_CONCEPTS(1.0)
	688	+|(% style="width:250px" %)Concept|(% style="width:444px" %)conceptSchemeAgencyId:
	689	+conceptSchemeId(version).conceptId|(% style="width:396px" %)SDMX:CROSS_DOMAIN_CONCEPTS(1.0).FREQ
	690	+|(% style="width:250px" %)*Codelist|(% style="width:444px" %)codeListAgencyId:codeListId(version)|(% style="width:396px" %)SDMX:CL_FREQ(1.0)
	691	+|(% style="width:250px" %)Code|(% style="width:444px" %)codeListAgencyId:codelistId(version).codeId|(% style="width:396px" %)SDMX:CL_FREQ(1.0).Q
	692	+|(% style="width:250px" %)(((
	693	+*Hierarchical Codelist
	694	+)))|(% style="width:444px" %)hierachicalCodelistAgencyId: hierarchicalCodelistId(version)|(% style="width:396px" %)(((
	695	+UNESCO:CL_EXP_SOURCE(1.0(% style="background-color:transparent" %))
730	730	)))
731		-
732		-
733		-
734		-|(((
735		-*Hierarchical
736		-
737		-Codelist
738		-)))|hierachicalCodelistAgencyId: hierarchicalCodelistId(version)|(((
739		-UNESCO:CL_EXP_SOURCE(1.0)
740		-
741		-
742		-)))
743		-|Hierarchy|(((
	697	+|(% style="width:250px" %)Hierarchy|(% style="width:444px" %)(((
744	744	hierachicalcodeListAgencyId:
745		-
746	746	hierarchicalcodelistId(version).Hierarchy
747		-)))|UNESCO:CL_EXP_SOURCE(1.0). H-C-GOV
748		-|Level|(((
	700	+)))|(% style="width:396px" %)UNESCO:CL_EXP_SOURCE(1.0).
	701	+H-C-GOV
	702	+|(% style="width:250px" %)Level|(% style="width:444px" %)(((
749	749	hierachicalcodeListAgencyId:
750		-
751	751	hierarchicalcodelistId(version).Hierarchy.Level
752		-)))|(((
	705	+)))|(% style="width:396px" %)(((
753	753	ESTAT:HCL_REGION(1.0).H_1.COUNTRY
754		-
755		-
756	756	)))
757		-|HierarchicalCode|hierachicalCodeListAgencyId: hierarchicalcodelistId(version).hierarchy.hierarc hicalCode|UNESCO:CL_EXP_SOURCE(1.0). H-C-GOV.GOV_CODE1
758		-|*DataStructure|dataStructureDefintitionAgencyId: dataStructureDefintitionId(version)|TFFS:EXT_DEBT(1.0)
759		-|(((
	708	+|(% 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
	709	+|(% style="width:250px" %)*DataStructure|(% style="width:444px" %)dataStructureDefintitionAgencyId: dataStructureDefintitionId(version)|(% style="width:396px" %)TFFS:EXT_DEBT(1.0)
	710	+|(% style="width:250px" %)(((
760	760	Dimension
761		-
762	762	Descriptor
763		-
764	764	Measure
765		-
766	766	Descriptor
767		-
768	768	Attribute
769		-
770	770	Descriptor
771		-)))|(((
	717	+)))|(% style="width:444px" %)(((
772	772	dataStructureDefinitionAgencyId: dataStructureDefinitionId(version).
773		-
774	774	componentListId
775		-
776	776	where the componentListId is the name of the class (there is only one occurrence of each in the Data Structure Definition)
777		-)))|(((
	721	+)))|(% style="width:396px" %)(((
778	778	TFFS:EXT_DEBT(1.0).DimensionDescriptor
779	779
780	780	TFFS:EXT_DEBT(1.0).MeasureDescriptor
...	...	@@ -781,181 +781,124 @@
781	781
782	782	TFFS:EXT_DEBT(1.0).AttributeDescriptor
783	783	)))
784		-|(((
	728	+|(% style="width:250px" %)(((
785	785	GroupDimension
786		-
787	787	Descriptor
788		-)))|(((
	731	+)))|(% style="width:444px" %)(((
789	789	dataStructureDefinitionAgencyId: dataStructureDefinitionId(version).
790		-
791	791	groupDimensionDescriptorId
792		-)))|TFFS:EXT_DEBT(1.0).SIBLING
793		-|Dimension|(((
	734	+)))|(% style="width:396px" %)TFFS:EXT_DEBT(1.0).SIBLING
	735	+|(% style="width:250px" %)Dimension|(% style="width:444px" %)(((
794	794	dataStructureDefinitionAgencyId: dataStructureDefinition (version).
795		-
796	796	dimensionId
797		-)))|TFFS:EXT_DEBT(1.0).FREQ
798		-|TimeDimension|(((
	738	+)))|(% style="width:396px" %)TFFS:EXT_DEBT(1.0).FREQ
	739	+|(% style="width:250px" %)TimeDimension|(% style="width:444px" %)(((
799	799	dataStructureDefinitionAgencyId: dataStructureDefinition (version).
800		-
801	801	timeDimensionId
802		-)))|TFFS:EXT_DEBT(1.0).TIME_PERIOD
803		-|Measure Dimension|dataStructureDefinitionAgencyId: dataStructureDefinition (version).|TFFS:EXT_DEBT(1.0).STOCK_FLOW
804		-
805		-
806		-
807		-| |measureDimensionId|
808		-|DataAttrribute|dataStructureDefinitionAgencyId: dataStructureDefinition (version). dataAttributeId|TFFS:EXT_DEBT(1.0).OBS_STATUS
809		-|PrimaryMeasure|(((
	742	+)))|(% style="width:396px" %)TFFS:EXT_DEBT(1.0).TIME_PERIOD
	743	+|(% style="width:250px" %)Measure Dimension|(% style="width:444px" %)dataStructureDefinitionAgencyId: dataStructureDefinition (version).
	744	+measureDimensionId|(% style="width:396px" %)TFFS:EXT_DEBT(1.0).STOCK_FLOW
	745	+|(% style="width:250px" %)DataAttrribute|(% style="width:444px" %)dataStructureDefinitionAgencyId: dataStructureDefinition (version). dataAttributeId|(% style="width:396px" %)TFFS:EXT_DEBT(1.0).OBS_STATUS
	746	+|(% style="width:250px" %)PrimaryMeasure|(% style="width:444px" %)(((
810	810	dataStructureDefinitionAgencyId: dataStructureDefinition (version).
811		-
812	812	primaryMeasureId
813		-)))|TFFS:EXT_DEBT(1.0).OBS_VALUE
814		-|(((
815		-*Category
816		-
817		-Scheme
818		-)))|categorySchemeAgencyId: categorySchemeId(version)|IMF:SDDS(1.0)
819		-|Category|categorySchemeAgencyId: categorySchemeId(version). categoryId.categoryId categoryId.categoryId etc.|(((
	749	+)))|(% style="width:396px" %)TFFS:EXT_DEBT(1.0).OBS_VALUE
	750	+|(% style="width:250px" %)(((
	751	+*Category Scheme
	752	+)))|(% style="width:444px" %)categorySchemeAgencyId:
	753	+categorySchemeId(version)|(% style="width:396px" %)IMF:SDDS(1.0)
	754	+|(% style="width:250px" %)Category|(% style="width:444px" %)categorySchemeAgencyId:
	755	+categorySchemeId(version).
	756	+categoryId.categoryId categoryId.categoryId etc.|(% style="width:396px" %)(((
820	820	IMF:SDDS(1.0):
821		-
822	822	level_1_category.level_2_category …
823	823	)))
824		-|(((
825		-*Reporting
826		-
827		-Taxonomy
828		-)))|reportingTaxonomyAgencyId: reportingTaxonomyId(version)| IMF:REP_1(1.0)
829		-|ReportingCategory|reportingTaxonomyAgencyId: reportingTaxonomyId(version) reportingcategoryId.reportingcategoryId|(((
	760	+|(% style="width:250px" %)(((
	761	+*Reporting Taxonomy
	762	+)))|(% style="width:444px" %)reportingTaxonomyAgencyId: reportingTaxonomyId(version)|(% style="width:396px" %) IMF:REP_1(1.0)
	763	+|(% style="width:250px" %)ReportingCategory|(% style="width:444px" %)reportingTaxonomyAgencyId: reportingTaxonomyId(version) reportingcategoryId.reportingcategoryId|(% style="width:396px" %)(((
830	830	IMF:REP_1(1.0):
831		-
832	832	level_1_repcategory.level_2_repcategory …
833	833	)))
834		-|*Categorisation|categorisationAgencyId: categorisationId(version)|IMF:cat001(1.0)
835		-|(((
836		-*Organisation
	767	+|(% style="width:250px" %)*Categorisation|(% style="width:444px" %)categorisationAgencyId: categorisationId(version)|(% style="width:396px" %)IMF:cat001(1.0)
	768	+|(% style="width:250px" %)(((
	769	+*Organisation Unit Scheme
	770	+)))|(% style="width:444px" %)organisationUnitSchemeAgencyId: organisationUnitSchemeId(version)|(% style="width:396px" %)ECB:ORGANISATIONS(1.0)
	771	+|(% style="width:250px" %)Organisation Unit|(% style="width:444px" %)organisationUnitSchemeAgencyId: organisationUnitSchemeId(version). organisationUnitId|(% style="width:396px" %)ECB:ORGANISATIONS(1.0).1F
	772	+|(% style="width:250px" %)*AgencyScheme|(% style="width:444px" %)agencySchemeAgencyId: agencySchemeId(version)|(% style="width:396px" %)ECB:AGENCIES(1.0)
837	837
838		-Unit Scheme
839		-)))|organisationUnitSchemeAgencyId: organisationUnitSchemeId(version)|ECB:ORGANISATIONS(1.0)
840		-|Organisation Unit|organisationUnitSchemeAgencyId: organisationUnitSchemeId(version). organisationUnitId|ECB:ORGANISATIONS(1.0).1F
841		-|*AgencyScheme|agencySchemeAgencyId: agencySchemeId(version)|ECB:AGENCIES(1.0)
842		-
843		-
844		-
845		-|Agency|agencySchemeAgencyId: agencySchemeId(version). agencyId|ECB:AGENCY(1.0).AA
846		-|(((
847		-*DataProvider
848		-
849		-Scheme
850		-)))|dataProviderSchemeAgencyId: dataProviderSchemeId(version)|SDMX:DATA_PROVIDERS(1.0)
851		-|DataProvider|dataProviderSchemeAgencyId: dataProviderSchemeId(version) dataProviderId|SDMX:DATA_PROVIDERS(1.0).PROVIDER_1
852		-|(((
853		-*DataConsumer
854		-
855		-Scheme
856		-)))|dataConsumerSchemeAgencyId: dataConsumerSchemeId(version)|SDMX:DATA_CONSUMERS(1.0)
857		-|Data Consumer|dataConsumerSchemeAgencyId: dataConsumerSchemeId(version) dataConsumerId|SDMX:DATA_CONSUMERS(1.0).CONSUMER_1
858		-|(((
859		-*Metadata
860		-
861		-Structure
862		-)))|MSDAgencyId:MSDId(version)|IMF:SDDS_MSD(1.0)
863		-|MetadataTarget|(((
	774	+|(% style="width:262px" %)Agency|(% style="width:369px" %)agencySchemeAgencyId: agencySchemeId(version). agencyId|(% style="width:1262px" %)ECB:AGENCY(1.0).AA
	775	+|(% style="width:262px" %)(((
	776	+*DataProvider Scheme
	777	+)))|(% style="width:369px" %)dataProviderSchemeAgencyId: dataProviderSchemeId(version)|(% style="width:1262px" %)SDMX:DATA_PROVIDERS(1.0)
	778	+|(% style="width:262px" %)DataProvider|(% style="width:369px" %)dataProviderSchemeAgencyId: dataProviderSchemeId(version) dataProviderId|(% style="width:1262px" %)SDMX:DATA_PROVIDERS(1.0).PROVIDER_1
	779	+|(% style="width:262px" %)(((
	780	+*DataConsumer Scheme
	781	+)))|(% style="width:369px" %)dataConsumerSchemeAgencyId: dataConsumerSchemeId(version)|(% style="width:1262px" %)SDMX:DATA_CONSUMERS(1.0)
	782	+|(% style="width:262px" %)Data Consumer|(% style="width:369px" %)dataConsumerSchemeAgencyId: dataConsumerSchemeId(version) dataConsumerId|(% style="width:1262px" %)SDMX:DATA_CONSUMERS(1.0).CONSUMER_1
	783	+|(% style="width:262px" %)(((
	784	+*Metadata Structure
	785	+)))|(% style="width:369px" %)MSDAgencyId:MSDId(version)|(% style="width:1262px" %)IMF:SDDS_MSD(1.0)
	786	+|(% style="width:262px" %)MetadataTarget|(% style="width:369px" %)(((
864	864	MSDAgencyId:
865		-
866	866	MSDId(version).metadataTargetId
867		-)))|IMF:SDDS_MSD(1.0).AGENCY
868		-|(((
	789	+)))|(% style="width:1262px" %)IMF:SDDS_MSD(1.0).AGENCY
	790	+|(% style="width:262px" %)(((
869	869	Dimension
870		-
871	871	DescriptorValues
872		-
873	873	Target
874		-)))|(((
	794	+)))|(% style="width:369px" %)(((
875	875	MSDAgencyId: MSDId(version).
876		-
877	877	metadataTargetId.keyDescriptorValueTargetId
878		-)))|IMF:SDDS_MSD(1.0).AGENCY.KEY
879		-|Identifiable ObjectTarget|(((
	797	+)))|(% style="width:1262px" %)IMF:SDDS_MSD(1.0).AGENCY.KEY
	798	+|(% style="width:262px" %)Identifiable Object Target|(% style="width:369px" %)(((
	799	+MSDAgencyId: MSDId(version).metadataTargetId.identifiableObjectTargetId
	800	+)))|(% style="width:1262px" %)IMF:SDDS_MSD(1.0).AGENCY.STR-OBJECT
	801	+|(% style="width:262px" %)DataSetTarget|(% style="width:369px" %)(((
880	880	MSDAgencyId:
	803	+MSDId(version).metadataTargetId.dataSetTargetId
	804	+)))|(% style="width:1262px" %)IMF:SDDS_MSD(1.0).AGENCY.D1101
	805	+|(% style="width:262px" %)PeportPeriod Target|(% style="width:369px" %)(((
	806	+MSDAgencyId: MSDId(version).metadataTargetId.reportPeriodTargetId
	807	+)))|(% style="width:1262px" %)IMF:SDDS_MSD(1.0).AGENCY.REP_PER
881	881
882		-MSDId(version).metadataTargetId.identifiable
883		-
884		-ObjectTargetId
885		-)))|IMF:SDDS_MSD(1.0).AGENCY.STR-OBJECT
886		-|DataSetTarget|(((
887		-MSDAgencyId:
888		-
889		-MSDId(version).metadataTargetId.dataSet
890		-
891		-TargetId
892		-)))|IMF:SDDS_MSD(1.0).AGENCY.D1101
893		-|PeportPeriod Target|(((
894		-MSDAgencyId:
895		-
896		-MSDId(version).metadataTargetId.reportPeriod
897		-
898		-TargetId
899		-)))|IMF:SDDS_MSD(1.0).AGENCY.REP_PER
900		-
901		-
902		-
903		-|(((
	809	+|(% style="width:251px" %)(((
904	904	ReportStructure
905		-
906		-
907		-)))|(((
908		-MSDAgencyId:
909		-
910		-MSDId(version).reportStructureId
911		-)))|IMF:SDDS_MSD(1.0).AGENCY_REPORT
912		-|(((
913		-Metadata
914		-
915		-Attribute
916		-)))|(((
917		-MSDAgencyId:
918		-
919		-MSDId(version).reportStructureId.metadataattri buteID
920		-)))|IMF:SDDS_MSD(1.0).AGENCY_REPORT.COMPILATION
921		-|*Dataflow|dataflowAgencyId: dataflowId(version)|TFFS:CRED_EXT_DEBT(1.0)
922		-|*Provision Agreement|(((
	811	+)))|(% style="width:442px" %)(((
	812	+MSDAgencyId: MSDId(version).reportStructureId
	813	+)))|(% style="width:1178px" %)IMF:SDDS_MSD(1.0).AGENCY_REPORT
	814	+|(% style="width:251px" %)(((
	815	+Metadata Attribute
	816	+)))|(% style="width:442px" %)(((
	817	+MSDAgencyId: MSDId(version).reportStructureId.metadataattri buteID
	818	+)))|(% style="width:1178px" %)IMF:SDDS_MSD(1.0).AGENCY_REPORT.COMPILATION
	819	+|(% style="width:251px" %)*Dataflow|(% style="width:442px" %)dataflowAgencyId: dataflowId(version)|(% style="width:1178px" %)TFFS:CRED_EXT_DEBT(1.0)
	820	+|(% style="width:251px" %)*Provision Agreement|(% style="width:442px" %)(((
923	923	provisionAgreementAgencyId:provisionAgreem entId(version)
924		-
925		-
926		-)))|(((
	822	+)))|(% style="width:1178px" %)(((
927	927	TFFS:CRED_EXT_DEBT_AB(1.0)
928		-
929		-
930		-
931	931	)))
932		-|(((
933		-*Content
934		-
935		-Constraint
936		-)))|constraintAgencyId:ContentConstraintId(versio n)|TFFS:CREDITOR_DATA_CONTENT(1.0)
937		-|(((
938		-*Attachment
939		-
940		-Constraint
941		-)))|(((
	825	+|(% style="width:251px" %)(((
	826	+*Content Constraint
	827	+)))|(% style="width:442px" %)constraintAgencyId:ContentConstraintId(versio n)|(% style="width:1178px" %)TFFS:CREDITOR_DATA_CONTENT(1.0)
	828	+|(% style="width:251px" %)(((
	829	+*Attachment Constraint
	830	+)))|(% style="width:442px" %)(((
942	942	constraintAgencyId:
943	943
944	944	attachmentConstraintId(version)
945		-)))|TFFS:CREDITOR_DATA_ATTACHMENT_CONSTRAINT_ONE(1.0)
946		-|*Metadataflow|metadataflowAgencyId: metadataflowId(version)|IMF:SDDS_FLOW(1.0)
947		-|*StructureSet|structureSetAgencyId: structureSetId(version)|SDMX:BOP_STRUCTURES(1.0)
948		-|StructureMap|structureSetAgencyId: structureSetId(version). structureMapId|SDMX:BOP_STRUCTURES(1.0).TABLE1_TABLE2
949		-|Component Map|(((
	834	+)))|(% style="width:1178px" %)TFFS:CREDITOR_DATA_ATTACHMENT_CONSTRAINT_ONE(1.0)
	835	+|(% style="width:251px" %)*Metadataflow|(% style="width:442px" %)metadataflowAgencyId: metadataflowId(version)|(% style="width:1178px" %)IMF:SDDS_FLOW(1.0)
	836	+|(% style="width:251px" %)*StructureSet|(% style="width:442px" %)structureSetAgencyId: structureSetId(version)|(% style="width:1178px" %)SDMX:BOP_STRUCTURES(1.0)
	837	+|(% style="width:251px" %)StructureMap|(% style="width:442px" %)structureSetAgencyId: structureSetId(version). structureMapId|(% style="width:1178px" %)SDMX:BOP_STRUCTURES(1.0).TABLE1_TABLE2
	838	+|(% style="width:251px" %)Component Map|(% style="width:442px" %)(((
950	950	structureSetAgencyId: structureSetId(version).
951	951
952	952	structureMapId. componentMapId
953		-)))|SDMX:BOP_STRUCTURES(1.0).TABLE1_TABLE2. REFAREA_REPCOUNTRY
954		-|CodelistMap|structureSetAgencyId: structureSetId(version). codelistMapId|SDMX:BOP_STRUCTURES(1.0).CLREFAREA_CLREPCOUNTRY
955		-|CodeMap|structureSetAgencyId: structureSetId(version).|SDMX:BOP_STRUCTURES(1.0).CLREFAREA_CLREPCOUNTRY. DE_GER
	842	+)))|(% style="width:1178px" %)SDMX:BOP_STRUCTURES(1.0).TABLE1_TABLE2. REFAREA_REPCOUNTRY
	843	+|(% style="width:251px" %)CodelistMap|(% style="width:442px" %)structureSetAgencyId: structureSetId(version). codelistMapId|(% style="width:1178px" %)SDMX:BOP_STRUCTURES(1.0).CLREFAREA_CLREPCOUNTRY
	844	+|(% style="width:251px" %)CodeMap|(% style="width:442px" %)structureSetAgencyId: structureSetId(version).|(% style="width:1178px" %)SDMX:BOP_STRUCTURES(1.0).CLREFAREA_CLREPCOUNTRY. DE_GER
956	956
957		-
958		-
959	959	| |(((
960	960	codeListMapId.
961	961
...	...	@@ -962,9 +962,7 @@
962	962	codeMapId
963	963	)))|
964	964	|(((
965		-Category
966		-
967		-SchemeMap
	852	+CategorySchemeMap
968	968	)))|structureSetAgencyId: structureSetId(version). categorySchemeMapId|SDMX:BOP_STRUCTURES(1.0).SDMX_EUROSTAT
969	969	|CategoryMap|structureSetAgencyId: structureSetId(version). categorySchemeMapId. categoryMapId|SDMX:BOP_STRUCTURES(1.0).SDMX_EUROSTAT.TOURISM_M AP
970	970	|Organisation SchemeMap|structureSetAgencyId: structureSetId(version). organisationSchemeMapId|SDMX:BOP_STRUCTURES(1.0).DATA_PROVIDER_MAP
...	...	@@ -978,71 +978,53 @@
978	978	structureSetAgencyId: structureSetId(version). conceptSchemeMapId.
979	979
980	980	conceptMapId
981		-
982	982
983	983	)))|SDMX:BOP_STRUCTURES(1.0).SDMX_OECD.COVERAGE_AVAI LABILITY
984	984	|(((
985		-Reporting
986		-
987		-TaxonomyMap
	869	+ReportingTaxonomyMap
988	988	)))|structureSetAgencyId: structureSetId(version). reportingTaxonomyMapId|SDMX:BOP_STRUCTURES(1.0).TAXMAP
989	989	|(((
990		-Reporting
991		-
992		-CategoryMap
	872	+ReportingCategoryMap
993	993	)))|(((
994	994	structureSetAgencyId: structureSetId(version).
995		-
996	996	reportngCategoryId
997	997	)))|SDMX:BOP_STRUCTURES(1.0).TAXMAP.TOPCAT
998	998
999		-
1000		-
1001	1001	|(((
1002		-HybridCodelist
1003		-
1004		-Map
1005		-)))|structureSetAgencyId: structureSetId(version). hybridCodelistMapId.|SDMX:BOP_STRUCTURES(1.0).COUNTRY_HIERARCHYMAP
	879	+HybridCodelistMap
	880	+)))|structureSetAgencyId: structureSetId(version).
	881	+hybridCodelistMapId.|SDMX:BOP_STRUCTURES(1.0).COUNTRY_HIERARCHYMAP
1006	1006	|HybridCodeMap|structureSetAgencyId: structureSetId(version). hybridCodelistMapId. hybridCodeMapId|SDMX:BOP_STRUCTURES(1.0).COUNTRY_HIERARCHYMAP.CO DEMAP1
1007	1007	|*Process|processAgencyId: processId{version]|BIS:PROCESS1(1.0)
1008	1008	|ProcessStep|(((
1009	1009	processAgencyId: processId(version).
1010		-
1011	1011	processStepId
1012	1012	)))|BIS:PROCESS1(1.0).STEP1
1013	1013	|Transition|(((
1014	1014	processAgencyId: processId(version).
1015		-
1016	1016	processStepId transitionId
1017	1017	)))|BIS:PROCESS1(1.0).STEP1.TRANSITION1
1018	1018	|Subscription|The Subscription is not itself an Identifiable Artefact and therefore it does not follow the rules for URN structure, The name of the URN is registryURN There is no pre-determined format.|This cannot be generated by a common mechanism as subscriptions, although maintainable in the sense that they can be submitted and deleted, are not mandated to be created by a maintenance agency, and have no versioning mechanism. It is therefore the responsibility of the target registry to generate a unique Id for the Subscription, and for the application creating the subscription to store the registryURN that is returned from the registry in the subscription response message.
1019	1019	|(((
1020		-*Transformation
1021		-
1022		-Scheme
	894	+*Transformation Scheme
1023	1023	)))|transformationSchemeAgencyId transformationSchemeId(version)|ECB: TRANSFORMATION_SCHEME(1.0)
1024	1024	|Transformation|(((
1025	1025	transformationSchemeAgencyId transformationSchemeId(version)
1026		-
1027	1027	transformationId
1028	1028	)))|ECB:TRANSFORMATION_SCHEME(1.0).TRANS_1
1029	1029	|CustomType Scheme|customTypeSchemeAgencyId customTypeSchemeId(version)|ECB:CUSTOM_TYPE_SCHEME(1.0)
1030	1030
1031		-
1032		-
1033	1033	|CustomType|customTypeSchemeAgencyId customTypeSchemeId(version) customTypeId|ECB: CUSTOM_TYPE_SCHEME(1.0).CUSTOM_TYPE_1
1034	1034	|(((
1035	1035	Name
1036		-
1037	1037	Personalisation
1038		-
1039	1039	Scheme
1040	1040	)))|namePersonalisationSchemeAgencyId namePersonalisationSchemeId(version)|ECB:PSN_SCHEME(1.0)
1041	1041	|(((
1042	1042	Name
1043		-
1044	1044	Personalisation
1045		-)))|namePersonalisationSchemeAgencyId namePersonalisationSchemeId(version) namePersonalisationId|ECB:PSN_SCHEME(1.0).PSN1234
	911	+)))|namePersonalisationSchemeAgencyId namePersonalisationSchemeId(version)
	912	+namePersonalisationId|ECB:PSN_SCHEME(1.0).PSN1234
1046	1046	|VtlMapping Scheme|vtlMappingSchemeAgencyId VtlMappingSchemeId(version)|ECB:CLIST_MP(2.0)
1047	1047	|VtlCodelist Mapping|vtlMappingSchemeAgencyId vtlMappingSchemeId(version) vtlCodelistMappingId|ECB:CLIST_MP(2.0).ABZ
1048	1048	|VtlConcept Mapping|vtlMappingSchemeAgencyId vtlMappingSchemeId(version) vtlConceptMappingId|ECB:CLIST_MP(1.0).XYA
...	...	@@ -1055,15 +1055,12 @@
1055	1055	|RulesetScheme|rulesetSchemeAgencyId rulesetSchemeId(version)|ECB:RULESET_23(1.0)
1056	1056	|Ruleset|rulesetSchemeAgencyId rulesetSchemeId(version) rulesetId|ECB:RULESET_23(1.0).SET111
1057	1057	|(((
1058		-UserDefined
1059		-
1060		-OperatorScheme
	925	+UserDefinedOperatorScheme
1061	1061	)))|userDefinedOperatorSchemeAgencyId userDefinedOperatorSchemeId(version)|ECB:OS_CALC(1.2)
1062	1062	|UserDefined Operator|userDefinedOperatorSchemeAgencyId userDefinedOperatorSchemeId(version) usserDefinedOperatorId|ECB:OS_CALC(1.2).OS267
1063	1063
1064		-7**Table 3: Table of identification components for SDMX Identifiable Artefacts**
	929	+**Table 3: Table of identification components for SDMX Identifiable Artefacts**
1065	1065
1066		-
1067	1067	= 7 Implementation Notes =
1068	1068
1069	1069	== 7.1 Structural Definition Metadata ==
...	...	@@ -1084,109 +1084,72 @@
1084	1084
1085	1085	The following table lists the Maintainable Artefacts.
1086	1086
1087		-|(% colspan="4" %)**Maintainable Artefacts**|(% colspan="2" %)**Content**|
1088		-|(% colspan="2" %)**Abstract Class**|(% colspan="2" %)**Concrete Class**|(% colspan="2" %) |
1089		-|(% colspan="2" %)Item Scheme|(% colspan="2" %)Codelist|(% colspan="2" %)Code|
1090		-|(% colspan="2" %) |(% colspan="2" %)Concept Scheme|(% colspan="2" %)Concept|
1091		-|(% colspan="2" %) |(% colspan="2" %)Category Scheme|(% colspan="2" %)Category|
1092		-|(% colspan="2" %) |(% colspan="2" %)Organisation Unit Scheme|(% colspan="2" %)Organisation Unit|
1093		-|(% colspan="2" %) |(% colspan="2" %)Agency Scheme|(% colspan="2" %)Agency|
1094		-|(% colspan="2" %) |(% colspan="2" %)Data Provider Scheme|(% colspan="2" %)Data Provider|
1095		-|(% colspan="2" %) |(% colspan="2" %)Data Consumer Scheme|(% colspan="2" %)Data Consumer|
1096		-|(% colspan="2" %) |(% colspan="2" %)Reporting Taxonomy|(% colspan="2" %)Reporting Category|
1097		-|(% colspan="2" %) |(% colspan="2" %)Transformation Scheme|(% colspan="2" %)Transformation|
1098		-|(% colspan="2" %) |(% colspan="2" %)Custom Type Scheme|(% colspan="2" %)Custom Type|
1099		-| |(% colspan="4" %)**Maintainable Artefacts**|(% colspan="2" %)**Content**
1100		-| |(% colspan="2" %)**Abstract Class**|(% colspan="2" %)**Concrete Class**|(% colspan="2" %)
1101		-| |(% colspan="2" %) |(% colspan="2" %)Name Personalisation Scheme|(% colspan="2" %)Name Personalisation
1102		-| |(% colspan="2" %) |(% colspan="2" %)Vtl Mapping Scheme|(% colspan="2" %)Vtl Codelist Mapping
1103		-| |(% colspan="2" %) |(% colspan="2" %) |(% colspan="2" %)Vtl Concept Mapping
1104		-| |(% colspan="2" %) |(% colspan="2" %) |(% colspan="2" %)Vtl Dataflow Mapping
1105		-| |(% colspan="2" %) |(% colspan="2" %) |(% colspan="2" %)(((
1106		-Vtl Concept Scheme
1107		-
1108		-Mapping
1109		-)))
1110		-| |(% colspan="2" %) |(% colspan="2" %)Ruleset Scheme|(% colspan="2" %)Ruleset
1111		-| |(% colspan="2" %) |(% colspan="2" %)User Defined Operator Scheme|(% colspan="2" %)User Defined Operator
1112		-| |(% colspan="2" %) |(% colspan="2" %) |(% colspan="2" %)
1113		-| |(% colspan="2" %)Structure|(% colspan="2" %)Data Structure Definition|(% colspan="2" %)(((
	951	+(% style="width:640.294px" %)
	952	+|(% colspan="2" rowspan="1" style="width:186px" %)**Maintainable Artefacts**|(% style="width:206px" %)**Content**
	953	+|(% style="width:171px" %)**Abstract Class**|(% style="width:232px" %)**Concrete Class**|(% style="width:206px" %)
	954	+|(% style="width:171px" %)Item Scheme|(% style="width:232px" %)Codelist|(% style="width:206px" %)Code
	955	+|(% style="width:171px" %) |(% style="width:232px" %)Concept Scheme|(% style="width:206px" %)Concept
	956	+|(% style="width:171px" %) |(% style="width:232px" %)Category Scheme|(% style="width:206px" %)Category
	957	+|(% style="width:171px" %) |(% style="width:232px" %)Organisation Unit Scheme|(% style="width:206px" %)Organisation Unit
	958	+|(% style="width:171px" %) |(% style="width:232px" %)Agency Scheme|(% style="width:206px" %)Agency
	959	+|(% style="width:171px" %) |(% style="width:232px" %)Data Provider Scheme|(% style="width:206px" %)Data Provider
	960	+|(% style="width:171px" %) |(% style="width:232px" %)Data Consumer Scheme|(% style="width:206px" %)Data Consumer
	961	+|(% style="width:171px" %) |(% style="width:232px" %)Reporting Taxonomy|(% style="width:206px" %)Reporting Category
	962	+|(% style="width:171px" %) |(% style="width:232px" %)Transformation Scheme|(% style="width:206px" %)Transformation
	963	+|(% style="width:171px" %) |(% style="width:232px" %)Custom Type Scheme|(% style="width:206px" %)Custom Type
	964	+|(% style="width:171px" %) |(% style="width:232px" %)Name Personalisation Scheme|(% style="width:206px" %)Name Personalisation
	965	+|(% style="width:171px" %) |(% style="width:232px" %)Vtl Mapping Scheme|(% style="width:206px" %)Vtl Codelist Mapping
	966	+|(% style="width:171px" %) |(% style="width:232px" %) |(% style="width:206px" %)Vtl Dataflow Mapping
	967	+|(% style="width:171px" %) |(% style="width:232px" %) |(% style="width:206px" %)Vtl Concept Scheme Mapping
	968	+|(% style="width:171px" %) |(% style="width:232px" %)Ruleset Scheme|(% style="width:206px" %)Ruleset
	969	+|(% style="width:171px" %) |(% style="width:232px" %)User Defined Operator Scheme|(% style="width:206px" %)User Defined Operator
	970	+|(% style="width:171px" %) |(% style="width:232px" %) |(% style="width:206px" %)User Defined Operator
	971	+|(% style="width:171px" %)Structure|(% style="width:232px" %)Data Structure Definition|(% style="width:206px" %)(((
1114	1114	Dimension Descriptor
1115		-
1116	1116	Group Dimension
1117		-
1118	1118	Descriptor
1119		-
1120	1120	Dimension
1121		-
1122	1122	Measure Dimension
1123		-
1124	1124	Time Dimension
1125		-
1126	1126	Attribute Descriptor
1127		-
1128	1128	Data Attribute
1129		-
1130	1130	Measure Descriptor
1131		-
1132	1132	Primary Measure
1133	1133	)))
1134		-| |(% colspan="2" %) |(% colspan="2" %)Metadata Structure Definition|(% colspan="2" %)(((
1135		-Metadata Target,
1136		-
1137		-Dimension Descriptor
1138		-
	983	+|(% style="width:171px" %) |(% style="width:232px" %)Metadata Structure Definition|(% style="width:206px" %)(((
	984	+Metadata Target, Dimension Descriptor
1139	1139	Values Target Identifiable
1140		-
1141	1141	Object Target
1142		-
1143	1143	Report Period Target
1144		-
1145	1145	Data SetTarget
1146		-
1147	1147	Report Structure
1148		-
1149	1149	Metadata Attribute
1150	1150	)))
1151		-| |(% colspan="2" %)Structure Usage|(% colspan="2" %)Dataflow Definition|(% colspan="2" %)
1152		-| |(% colspan="2" %) |(% colspan="2" %)Metadataflow Definition|(% colspan="2" %)
1153		-| |(% colspan="2" %)None|(% colspan="2" %)Process|(% colspan="2" %)Process Step
1154		-| |(% colspan="2" %)None|(% colspan="2" %)Structure Set|(% colspan="2" %)(((
	992	+|(% style="width:171px" %)Structure Usage|(% style="width:232px" %)Dataflow Definition|(% style="width:206px" %)
	993	+|(% style="width:171px" %) |(% style="width:232px" %)Metadataflow Definition|(% style="width:206px" %)
	994	+|(% style="width:171px" %)None|(% style="width:232px" %)Process|(% style="width:206px" %)Process Step
	995	+|(% style="width:171px" %)None|(% style="width:232px" %)Structure Set|(% style="width:206px" %)(((
1155	1155	Component Map
1156		-
1157	1157	Concept Scheme Map
1158		-
1159	1159	Codelist Map
1160		-
1161	1161	Category Scheme Map
1162		-
1163	1163	Reporting Taxonomy Map
1164		-
1165	1165	Organisation Scheme Map
1166		-
1167	1167	Concept Map
1168		-
1169	1169	Code Map
1170		-
1171	1171	Category Map
1172		-
1173	1173	Organisation Map
1174		-
1175	1175	Reporting Category Map
1176		-
1177	1177	Hybrid Codelist Map
1178		-
1179	1179	Hybrid Code Map
1180	1180	)))
1181		-| |(% colspan="2" %)None|(% colspan="2" %)Provision Agreement|(% colspan="2" %)
1182		-| |(% colspan="2" %)None|(% colspan="2" %)Hierarchical Codelist|(% colspan="2" %)(((
	1010	+|(% style="width:171px" %)None|(% style="width:232px" %)Provision Agreement|(% style="width:206px" %)
	1011	+|(% style="width:171px" %)None|(% style="width:232px" %)Hierarchical Codelist|(% style="width:206px" %)(((
1183	1183	Hierarchy
1184		-
1185	1185	Hierarchical Code
1186	1186	)))
1187		-| | | | | | |
1188	1188
1189		-**Table 4: Table of Maintainable Artefacts for Structural Definition Metadata**
	1016	+**able 4: Table of Maintainable Artefacts for Structural Definition Metadata**
1190	1190
1191	1191	=== 7.1.2 Item Scheme, Structure ===
1192	1192
...	...	@@ -1193,10 +1193,7 @@
1193	1193	The artefacts included in the structural definitions are:
1194	1194
1195	1195	* All types of Item Scheme (Codelist, Concept Scheme, Category Scheme, Organisation Scheme - Agency Scheme, Data Provider Scheme, Data Consumer Scheme, Organisation Unit Scheme)
1196		-* All types of Structure (Data Structure Definition, Metadata Structure
1197		-
1198		-Definition)
1199		-
	1023	+* All types of Structure (Data Structure Definition, Metadata Structure Definition)
1200	1200	* All types of Structure Usage (Dataflow Definition, Metadataflow Definition)
1201	1201
1202	1202	=== 7.1.3 Structure Usage ===
...	...	@@ -1215,6 +1215,8 @@
1215	1215
1216	1216	==== 7.1.3.3 Structure Usage Model ====
1217	1217
	1042	+[[image:1747829078194-749.png]]
	1043	+
1218	1218	**Figure 10: SDMX-IM of links from Structure Usage to Category**
1219	1219
1220	1220	In addition to the maintenance of the Dataflow Definition and the Metadataflow Definition the following links must be maintained in the registry:
...	...	@@ -1241,10 +1241,10 @@
1241	1241
1242	1242	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.
1243	1243
	1070	+[[image:1747829109466-595.png]]
1244	1244
1245	1245	**Figure 11: SDMX-IM of the Data Provider**
1246	1246
1247		-
1248	1248	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
1249	1249
1250	1250	[[image:1747824123019-181.jpeg]]
...	...	@@ -1253,8 +1253,10 @@
1253	1253
1254	1254	The diagram below is a logical representation of the data required in order to maintain Provision Agreements.
1255	1255
	1082	+[[image:1747829139951-378.png]]
1256	1256
1257		-==== Figure 13: Logical class diagram of the information contained in the Provision Agreement ====
	1084	+(% class="wikigeneratedid" id="HFigure13:LogicalclassdiagramoftheinformationcontainedintheProvisionAgreement" %)
	1085	+**Figure 13: Logical class diagram of the information contained in the Provision Agreement**
1258	1258
1259	1259	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.
1260	1260
...	...	@@ -1282,13 +1282,12 @@
1282	1282
1283	1283	=== 7.3.3 Data and Metadata Constraints: Model ===
1284	1284
	1113	+[[image:1747829204737-370.png]]
1285	1285
	1115	+**Figure 15: Logical class diagram showing inheritance between and reference to constrainable artifacts**
1286	1286
1287		-==== Figure 15: Logical class diagram showing inheritance between and reference to constrainable artifacts ====
	1117	+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.
1288	1288
1289		-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.
1290		-
1291		-
1292	1292	The content of the Constraint can be found in the SDMX Information Model document.
1293	1293
1294	1294	== 7.4 Data and Metadata Registration ==
...	...	@@ -1309,7 +1309,7 @@
1309	1309
1310	1310	[[image:1747824123025-411.jpeg]]
1311	1311
1312		- **Figure 16: Schematic of the Objects Concerned with Registration**
	1139	+**Figure 16: Schematic of the Objects Concerned with Registration**
1313	1313
1314	1314	==== 7.4.2.2 Registration Request Model ====
1315	1315
...	...	@@ -1323,11 +1323,14 @@
1323	1323
1324	1324	The Registration has an action attribute which takes one of the following values:
1325	1325
1326		-|**Action Attribute Value**|**Behaviour**
1327		-|Append|Add this Registration to the registry
1328		-|Replace|Replace the existing Registration with identified by the id in the Registration of the Submit Registration Request
1329		-|Delete|Delete the existing Registration identified by the id in the Registration of the Submit Registration Request
	1153	+(% style="width:970.294px" %)
	1154	+|(% style="width:212px" %)**Action Attribute Value**|(% style="width:756px" %)**Behaviour**
	1155	+|(% style="width:212px" %)Append|(% style="width:756px" %)Add this Registration to the registry
	1156	+|(% style="width:212px" %)Replace|(% style="width:756px" %)Replace the existing Registration with identified by the id in the Registration of the Submit Registration Request
	1157	+|(% style="width:212px" %)Delete|(% style="width:756px" %)Delete the existing Registration identified by the id in the Registration of the Submit Registration Request
1330	1330
	1159	+[[image:1747829290890-122.png]]
	1160	+
1331	1331	**Figure 17: Logical Class Diagram of Registration of Data and Metadata**
1332	1332
1333	1333	The Query Datasource is an abstract class that represents a data source which can understand an SDMX-ML query (SOAPDatasource) or RESTful query
...	...	@@ -1342,25 +1342,19 @@
1342	1342
1343	1343	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.
1344	1344
1345		-|**Indexing Required**|**Registration Process Activity**
1346		-|indexTimeSeries|Extract all the series keys and create a KeySet(s) Constraint.
1347		-|indexDataSet|(((
1348		-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
1349		-
1350		-Regions containing Member Selections of Dimension Components of the Constraints model in the SDMX-IM, and the associated Selection Value.
	1175	+|(% style="width:185px" %)**Indexing Required**|(% style="width:1686px" %)**Registration Process Activity**
	1176	+|(% style="width:185px" %)indexTimeSeries|(% style="width:1686px" %)Extract all the series keys and create a KeySet(s) Constraint.
	1177	+|(% style="width:185px" %)indexDataSet|(% style="width:1686px" %)(((
	1178	+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.
1351	1351	)))
1352		-|indexReportingPeriod|(((
	1180	+|(% style="width:185px" %)indexReportingPeriod|(% style="width:1686px" %)(((
1353	1353	This applies only to a registered dataset.
1354		-
1355	1355	Extract the Reporting Begin and Reporting End from the Header of the Message containing the data set, and create a Reference Period constraint.
1356	1356	)))
1357		-|indexAttributes|(((
	1184	+|(% style="width:185px" %)indexAttributes|(% style="width:1686px" %)(((
1358	1358	**Data Set**
1359		-
1360	1360	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
1361		-
1362	1362	**Metadata Set**
1363		-
1364	1364	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.
1365	1365	)))
1366	1366
...	...	@@ -1370,14 +1370,13 @@
1370	1370
1371	1371	=== 7.4.3 Registration Response ===
1372	1372
1373		-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
	1197	+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”.
1374	1374
1375		-“Success”, “Warning” or “Failure”.
1376		-
1377	1377	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.
1378	1378
1379	1379	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:
1380	1380
	1203	+[[image:1747829477882-750.png]]
1381	1381
1382	1382	**Figure 18: Logical class diagram showing the registration response**
1383	1383
...	...	@@ -1387,15 +1387,12 @@
1387	1387
1388	1388	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.
1389	1389
1390		-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
	1213	+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”.
1391	1391
1392		-“notification”.
	1215	+=== 7.5.1Subscription Logical Class Diagram ===
1393	1393
1394		- 7.5.1Subscription Logical Class Diagram
	1217	+[[image:1747829554603-150.png]]
1395	1395
1396		-
1397		-[[image:1747824123028-257.png]]
1398		-
1399	1399	**Figure 19: Logical Class Diagram of the Subscription**
1400	1400
1401	1401	=== 7.5.2 Subscription Information ===
...	...	@@ -1402,73 +1402,58 @@
1402	1402
1403	1403	Regardless of the type of registry/repository events being observed, a subscription always contains:
1404	1404
1405		-~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.
	1225	+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.
	1226	+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.
	1227	+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.
	1228	+1. A selector which specifies which type of events are of interest. The set of event types is:
1406	1406
1407		-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.
	1230	+|(% style="width:327px" %)**Event Type**|(% style="width:1545px" %)**Comment**
	1231	+|(% style="width:327px" %)STRUCTURAL_REPOSITORY_EVENTS|(% style="width:1545px" %)Life-cycle changes to Maintainable Artefacts in the structural metadata repository.
	1232	+|(% 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.
	1233	+|(% 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.
	1234	+|(% style="width:327px" %)ALL_EVENTS|(% style="width:1545px" %)All events of the specified EventType
1408	1408
1409		-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.
1410		-
1411		-4. A selector which specifies which type of events are of interest. The set of event types is:
1412		-
1413		-|**Event Type**|**Comment**
1414		-|STRUCTURAL_REPOSITORY_EVENTS|Life-cycle changes to Maintainable Artefacts in the structural metadata repository.
1415		-|DATA_REGISTRATION_EVENTS|Whenever a published dataset is registered. This can be either a SDMXML data file or an SDMX conformant database.
1416		-|METADATA_REGISTRATION_EVENTS|Whenever a published metadataset is registered. This can be either a SDMXML reference metadata file or an SDMX conformant database.
1417		-|ALL_EVENTS|All events of the specified EventType
1418		-
1419	1419	=== 7.5.3 Wildcard Facility ===
1420	1420
1421	1421	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:
1422	1422
1423		- agencyID
	1240	+* agencyID
	1241	+* id
	1242	+* version
1424	1424
1425		- id
1426		-
1427		- version
1428		-
1429	1429	Examples of wildcarded identifier components for an identified object type of Codelist are shown below.
1430	1430
1431		-AgencyID = %
1432		-
	1246	+//AgencyID = %
1433	1433	Id = %
	1248	+Version = %//
1434	1434
1435		-Version = %
1436		-
1437	1437	This subscribes to all Codelists of all versions for all agencies.
1438	1438
1439		-AgencyID = AGENCY1
1440		-
	1252	+//AgencyID = AGENCY1
1441	1441	Id = CODELIST1
	1254	+Version = %//
1442	1442
1443		-Version = %
1444		-
1445	1445	This subscribes to all versions of Codelist CODELIST1 maintained by the agency
1446	1446
1447		-AGENCY1
1448		-
	1258	+//AGENCY1
1449	1449	AgencyID = AGENCY1
1450		-
1451	1451	Id = %
	1261	+Version = %//
1452	1452
1453		-Version = %
1454		-
1455	1455	This subscribes to all versions of all Codelist objects maintained by the agency
1456	1456
1457		-AGENCY1
1458		-
	1265	+//AGENCY1
1459	1459	AgencyID = %
1460		-
1461	1461	Id = CODELIST1
	1268	+Version = %//
1462	1462
1463		-Version = %
1464		-
1465	1465	This subscribes to all versions of Codelist CODELIST1 maintained by the agency
1466	1466
1467		-AGENCY1
	1272	+//AGENCY1//
1468	1468
1469	1469	Note that if the subscription is to the latest version then this can be achieved by the * character
1470	1470
1471		-i.e. Version = *
	1276	+//i.e. Version = *//
1472	1472
1473	1473	Note that a subscription using the URN mechanism cannot use wildcard characters.
1474	1474
...	...	@@ -1480,16 +1480,15 @@
1480	1480
1481	1481	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:
1482	1482
	1288	+|(% style="width:405px" %)**Selector**|(% style="width:1467px" %)**Comment**
	1289	+|(% style="width:405px" %)DataProvider|(% style="width:1467px" %)Any datasets or metadata sets registered by the specified data provider will activate the notification.
	1290	+|(% style="width:405px" %)ProvisionAgreement|(% style="width:1467px" %)Any datasets or metadata sets registered for the provision agreement will activate the notification.
	1291	+|(% style="width:405px" %)Dataflow (&Metadataflow)|(% style="width:1467px" %)Any datasets or metadata sets registered for the specified dataflow (or metadataflow) will activate the notification.
	1292	+|(% 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
	1293	+|(% style="width:405px" %)**Selector**|(% style="width:1467px" %)**Comment**
	1294	+|(% style="width:405px" %) |(% style="width:1467px" %)activate the notification.
	1295	+|(% 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.
1483	1483
1484		-|**Selector**|**Comment**
1485		-|DataProvider|Any datasets or metadata sets registered by the specified data provider will activate the notification.
1486		-|ProvisionAgreement|Any datasets or metadata sets registered for the provision agreement will activate the notification.
1487		-|Dataflow (&Metadataflow)|Any datasets or metadata sets registered for the specified dataflow (or metadataflow) will activate the notification.
1488		-|DataStructureDefinition & MetadataStructureDefinition|Any datasets or metadata sets registered for those dataflows (or metadataflows) that are based on the specified Data Structure Definition will
1489		-|**Selector**|**Comment**
1490		-| |activate the notification.
1491		-|Category|Any datasets or metadata sets registered for those dataflows, metadataflows, provision agreements that are categorised by the category.
1492		-
1493	1493	The event will also capture the semantic of the registration: deletion or replacement of an existing registration or a new registration.
1494	1494
1495	1495	== 7.6 Notification ==
...	...	@@ -1496,8 +1496,10 @@
1496	1496
1497	1497	=== 7.6.1 Logical Class Diagram ===
1498	1498
	1303	+[[image:1747829675568-610.png]]
1499	1499
1500		-==== Figure 20: Logical Class Diagram of the Notification ====
	1305	+(% class="wikigeneratedid" id="HFigure20:LogicalClassDiagramoftheNotification" %)
	1306	+**Figure 20: Logical Class Diagram of the Notification**
1501	1501
1502	1502	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.
1503	1503
...	...	@@ -1517,5 +1517,3 @@
1517	1517	=== 7.6.3 Registration Event Component ===
1518	1518
1519	1519	The notification will contain the Registration.
1520		-
1521		-

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