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

Summary

• Page properties (1 modified, 0 added, 0 removed)

Details

Page properties

Content

...	...	@@ -163,8 +163,9 @@
163	163
164	164	The registry interfaces are invoked in one of two ways:
165	165
166		-1. The interface is the name of the root node of the SDMX-ML document
167		-1. The interface is invoked as a child element of the RegistryInterface message where the RegistryInterface is the root node of the SDMX-ML document.
	166	+*
	167	+*1. The interface is the name of the root node of the SDMX-ML document
	168	+*1. The interface is invoked as a child element of the RegistryInterface message where the RegistryInterface is the root node of the SDMX-ML document.
168	168
169	169	In addition to these interfaces the registry must support a mechanism for submitting and querying for structural metadata. This is detailed in sections 5.2.2 and 5.2.3.
170	170
...	...	@@ -180,15 +180,15 @@
180	180
181	181	=== 5.2.2 Structure Submission Service ===
182	182
183		-The registry must support a mechanism for submitting structural metadata. This mechanism can be the SDMX REST interface for structural metadata (this is defined in the corresponding GitHub project, dedicated to the SDMX REST API: [[__https:~~/~~/github.com/sdmx-twg/sdmx-rest__>>https://https:github.comsdmx-twgsdmx-rest]]). In order for the architecture to be scalable, the finest-grained piece of structural metadata that can be processed by the SDMX-RR is a MaintainableArtefact, with the exception of Item Schemes, where changes at an Item level is also possible (see next section on the SDMX Information Model).
	184	+The registry must support a mechanism for submitting structural metadata. This mechanism can be the SDMX REST interface for structural metadata (this is defined in the corresponding GitHub project, dedicated to the SDMX REST API: __[[https:~~/~~/github.com/sdmx>>url:https://github.com/sdmx-twg/sdmx-rest]][[->>url:https://github.com/sdmx-twg/sdmx-rest]][[twg/sdmx>>url:https://github.com/sdmx-twg/sdmx-rest]][[->>url:https://github.com/sdmx-twg/sdmx-rest]][[rest>>url:https://github.com/sdmx-twg/sdmx-rest]]__[[)>>url:https://github.com/sdmx-twg/sdmx-rest]]. In order for the architecture to be scalable, the finest-grained piece of structural metadata that can be processed by the SDMX-RR is a MaintainableArtefact, with the exception of Item Schemes, where changes at an Item level is also possible (see next section on the SDMX Information Model).
184	184
185	185	=== 5.2.3 Structure Query Service ===
186	186
187		-The registry must support a mechanism for querying for structural metadata. This mechanism can be the SDMX REST interface for structural metadata (this is defined in the corresponding GitHub project, dedicated to the SDMX REST API: [[__https:~~/~~/github.com/sdmx-twg/sdmx-rest__>>https://https:github.comsdmx-twgsdmx-rest]]). The registry response to this query mechanism is the SDMX Structure message, which has as its root node:
	188	+The registry must support a mechanism for querying for structural metadata. This mechanism can be the SDMX REST interface for structural metadata (this is defined in the corresponding GitHub project, dedicated to the SDMX REST API: __[[https:~~/~~/github.com/sdmx>>url:https://github.com/sdmx-twg/sdmx-rest]][[->>url:https://github.com/sdmx-twg/sdmx-rest]][[twg/sdmx>>url:https://github.com/sdmx-twg/sdmx-rest]][[->>url:https://github.com/sdmx-twg/sdmx-rest]][[rest>>url:https://github.com/sdmx-twg/sdmx-rest]]__[[)>>url:https://github.com/sdmx-twg/sdmx-rest]]. The registry response to this query mechanism is the SDMX Structure message, which has as its root node:
188	188
189		-* Structure
	190	+• Structure
190	190
191		-The SDMX structural artefacts that may be queried are defined in the SDMX structure web service specification which is compatible with this release of the standard __[[https:~~/~~/github.com/sdmx-twg/sdmx-rest/blob/master/doc/structures.md>>https://github.com/sdmx-twg/sdmx-rest/blob/master/doc/structures.md]] __[[https:~~/~~/github.com/sdmx-twg/sdmx-rest/blob/master/doc/structures.md>>https://github.com/sdmx-twg/sdmx-rest/blob/master/doc/structures.md]]
	192	+The SDMX structural artefacts that may be queried are defined in the SDMX structure web service specification which is compatible with this release of the standard __[[https:~~/~~/github.com/sdmx>>url:https://github.com/sdmx-twg/sdmx-rest/blob/master/doc/structures.md]][[->>url:https://github.com/sdmx-twg/sdmx-rest/blob/master/doc/structures.md]][[twg/sdmx>>url:https://github.com/sdmx-twg/sdmx-rest/blob/master/doc/structures.md]][[->>url:https://github.com/sdmx-twg/sdmx-rest/blob/master/doc/structures.md]][[rest/blob/master/doc/structures.md>>url:https://github.com/sdmx-twg/sdmx-rest/blob/master/doc/structures.md]]__[[url:https://github.com/sdmx-twg/sdmx-rest/blob/master/doc/structures.md]]
192	192
193	193	=== 5.2.4 Data and Reference Metadata Registration Service ===
194	194
...	...	@@ -270,7 +270,7 @@
270	270	1. If the action is set to “delete” (or a maintainable Artefact is DELETEd) then the Registry MUST verify that the object can be deleted. In order to qualify for deletion, the object must:
271	271
272	272	a) Be a draft version.
273		-b) Not be explicitly{{footnote}}With semantic versioning, it is allowed to reference a range of artefacts, e.g., a DSD referencing a Codelist with version 1.2.3+ means all patch versions greater than 1.2.3. This means that deleting 1.2.4draft does not break integrity of the aforementioned DSD.{{/footnote}} referenced from any other object in the Registry.
	274	+b) Not be explicitly^^[[(% class="wikiinternallink wikiinternallink wikiinternallink" %)^^1^^>>path:#sdfootnote1sym||name="sdfootnote1anc"]](%%)^^ referenced from any other object in the Registry.
274	274
275	275	4) The semantic versioning rules in the SDMX documentation MUST be obeyed.
276	276	)))
...	...	@@ -304,40 +304,47 @@
304	304	* //Versionable//
305	305	* //Maintainable//
306	306
307		-(% style="width:1038.83px" %)
308		-|(% colspan="2" %)**Object Type**|(% colspan="2" %)**Data Attributes**|(% colspan="2" %)**Status**|(% colspan="2" %)**Data type**|(% colspan="2" %)**Notes**
309		-|(% colspan="2" rowspan="4" %)//Annotable//|(% colspan="2" %)AnnotationTitle|(% colspan="2" %)C|(% colspan="2" %)string|(% colspan="2" %)
310		-|(% colspan="2" %)AnnotationType|(% colspan="2" %)C|(% colspan="2" %)string|(% colspan="2" %)
311		-|(% colspan="2" %)AnnotationURN|(% colspan="2" %)C|(% colspan="2" %)string|(% colspan="2" %)
312		-|(% colspan="2" %)(((
313		-AnnotationText in the form of InternationalString
	308	+| |(% colspan="2" %)**Object Type**|(% colspan="2" %)**Data Attributes**|(% colspan="2" %)**Status**|(% colspan="2" %)**Data type**|(% colspan="2" %)**Notes**
	309	+| |(% colspan="2" rowspan="4" %)//Annotable//|(% colspan="2" %)AnnotationTitle|(% colspan="2" %)C|(% colspan="2" %)string|(% colspan="2" %)
	310	+| |(% colspan="2" %)AnnotationType|(% colspan="2" %)C|(% colspan="2" %)string|(% colspan="2" %)
	311	+| |(% colspan="2" %)AnnotationURN|(% colspan="2" %)C|(% colspan="2" %)string|(% colspan="2" %)
	312	+| |(% colspan="2" %)(((
	313	+AnnotationText in the form of
	314	+
	315	+InternationalString
314	314	)))|(% colspan="2" %)C|(% colspan="2" %) |(% colspan="2" %)This can have languagespecific variants
315		-|(% colspan="2" rowspan="4" %)//Identifiable//|(% colspan="2" %)All content as for //Annotable// plus|(% colspan="2" %) |(% colspan="2" %) |(% colspan="2" %)
316		-|(% colspan="2" %)id|(% colspan="2" %)M|(% colspan="2" %)string|(% colspan="2" %)
317		-|(% colspan="2" %)uri|(% colspan="2" %)C|(% colspan="2" %)string|(% colspan="2" %)
318		-|(% colspan="2" %)urn|(% colspan="2" %)C|(% colspan="2" %)string|(% colspan="2" %)Although the urn is computable and therefore may not be submitted or stored physically, the Registry must return the urn for each object, and must be able to service a query on an object referenced solely by its urn.
319		-|(% colspan="2" rowspan="3" %)//Nameable//|(% colspan="2" %)(((
320		-All content as for //Identifiable// plus
	317	+| |(% colspan="2" rowspan="4" %)//Identifiable//|(% colspan="2" %)All content as for //Annotable// plus|(% colspan="2" %) |(% colspan="2" %) |(% colspan="2" %)
	318	+| |(% colspan="2" %)id|(% colspan="2" %)M|(% colspan="2" %)string|(% colspan="2" %)
	319	+| |(% colspan="2" %)uri|(% colspan="2" %)C|(% colspan="2" %)string|(% colspan="2" %)
	320	+| |(% colspan="2" %)urn|(% colspan="2" %)C|(% colspan="2" %)string|(% colspan="2" %)Although the urn is computable and therefore may not be submitted or stored physically, the Registry must return the urn for each object, and must be able to service a query on an object referenced solely by its urn.
	321	+| |(% colspan="2" rowspan="3" %)//Nameable//|(% colspan="2" %)(((
	322	+All content as for
	323	+
	324	+//Identifiable// plus
321	321	)))|(% colspan="2" %) |(% colspan="2" %) |(% colspan="2" %)
322		-|(% colspan="2" %)(((
323		-Name in the form of InternationalString
	326	+| |(% colspan="2" %)(((
	327	+Name in the form of
	328	+
	329	+InternationalString
324	324	)))|(% colspan="2" %)M|(% colspan="2" %)string|(% colspan="2" %)This can have language specific variants.
325		-|(% colspan="2" %)(((
326		-Description in the form of InternationalString
	331	+| |(% colspan="2" %)(((
	332	+Description in the form of
	333	+
	334	+InternationalString
327	327	)))|(% colspan="2" %)C|(% colspan="2" %)string|(% colspan="2" %)This can have language specific variants.
328		-|(% colspan="2" rowspan="4" %)//Versionable//|(% colspan="2" %)(((
	336	+| |(% colspan="2" rowspan="4" %)//Versionable//|(% colspan="2" %)(((
329	329	All content as for
330	330
331	331	//Identifiable// plus
332	332	)))|(% colspan="2" %) |(% colspan="2" %) |(% colspan="2" %)
333		-|(% colspan="2" %)version|(% colspan="2" %)M|(% colspan="2" %)string|(% colspan="2" %)This is the version number according to SDMX versioning rules.
334		-|(% colspan="2" %)validFrom|(% colspan="2" %)C|(% colspan="2" %)Date/time|(% colspan="2" %)
335		-|(% colspan="2" %)validTo|(% colspan="2" %)C|(% colspan="2" %)Date/time|(% colspan="2" %)
336		-|(% colspan="2" %)//Maintainable//|(% colspan="2" %)All content as for //Versionable// plus|(% colspan="2" %) |(% colspan="2" %) |(% colspan="2" %)
337		-|(% colspan="2" %) |(% colspan="2" %)isExternalReference|(% colspan="2" %)C|(% colspan="2" %)boolean|(% colspan="2" %)Value of “true” indicates that the actual resource is held outside of this registry. The actual reference is given in the registry URI or the structureURL, each of which must return a valid SDMX-ML file.
338		-|(% colspan="2" %) |(% colspan="2" %)serviceURL|(% colspan="2" %)C|(% colspan="2" %)string|(% colspan="2" %)The url of the service that can be queried for this resource.
339		-|(% colspan="2" %) |(% colspan="2" %)structureURL|(% colspan="2" %)C|(% colspan="2" %)string|(% colspan="2" %)The url of the resource.
340		-|(% colspan="2" %) |(% colspan="2" %)(Maintenance) organisationId|(% colspan="2" %)M|(% colspan="2" %)string|(% colspan="2" %)The object must be linked to a maintenance organisation, i.e., Agency or Metadata Provider.
	341	+| |(% colspan="2" %)version|(% colspan="2" %)M|(% colspan="2" %)string|(% colspan="2" %)This is the version number according to SDMX versioning rules.
	342	+| |(% colspan="2" %)validFrom|(% colspan="2" %)C|(% colspan="2" %)Date/time|(% colspan="2" %)
	343	+| |(% colspan="2" %)validTo|(% colspan="2" %)C|(% colspan="2" %)Date/time|(% colspan="2" %)
	344	+|(% colspan="2" rowspan="5" %)//Maintainable//|(% colspan="2" %)All content as for //Versionable// plus|(% colspan="2" %) |(% colspan="2" %) |(% colspan="2" %) |
	345	+|(% colspan="2" %)isExternalReference|(% colspan="2" %)C|(% colspan="2" %)boolean|(% colspan="2" %)Value of “true” indicates that the actual resource is held outside of this registry. The actual reference is given in the registry URI or the structureURL, each of which must return a valid SDMX-ML file.|
	346	+|(% colspan="2" %)serviceURL|(% colspan="2" %)C|(% colspan="2" %)string|(% colspan="2" %)The url of the service that can be queried for this resource.|
	347	+|(% colspan="2" %)structureURL|(% colspan="2" %)C|(% colspan="2" %)string|(% colspan="2" %)The url of the resource.|
	348	+|(% colspan="2" %)(Maintenance) organisationId|(% colspan="2" %)M|(% colspan="2" %)string|(% colspan="2" %)The object must be linked to a maintenance organisation, i.e., Agency or Metadata Provider.|
341	341
342	342	**Table 1: Common Attributes of Object Types**
343	343
...	...	@@ -361,9 +361,11 @@
361	361	* Agencies registered in the top-level scheme can themselves maintain a single Agency Scheme. Agencies in these second-tier schemes can themselves maintain a single Agency Scheme and so on.
362	362	* The AgencyScheme has a fixed version, i.e., ‘1.0’, hence it is an exception from the Semantic Versioning that other Artefacts follow.
363	363	* There can be only one AgencyScheme maintained by any one Agency. It has a fixed id of AGENCIES.
364		-* The /hierarchy of Organisation is not inherited by Maintenance Agency – thus each Agency Scheme is a flat list of Maintenance Agencies.
365		-* The format of the agency identifier is agencyID.agencyID etc. The top-level agency in this identification mechanism is the agency registered in the SDMX agency scheme. In other words, SDMX is not a part of the hierarchical ID structure for agencies. However, SDMX is, itself, a maintenance agency and is contained in the top-level Agency Scheme.
366	366
	373	+• The /hierarchy of Organisation is not inherited by Maintenance Agency – thus each Agency Scheme is a flat list of Maintenance Agencies.
	374	+
	375	+• The format of the agency identifier is agencyID.agencyID etc. The top-level agency in this identification mechanism is the agency registered in the SDMX agency scheme. In other words, SDMX is not a part of the hierarchical ID structure for agencies. However, SDMX is, itself, a maintenance agency and is contained in the top-level Agency Scheme.
	376	+
367	367	This supports a hierarchical structure of agencyID.
368	368
369	369	An example is shown below.
...	...	@@ -374,11 +374,14 @@
374	374
375	375	The following organizations maintain an Agency Scheme.
376	376
377		-* SDMX – contains Agencies AA, BB
378		-* AA – contains Agencies CC, DD
379		-* BB – contains Agencies CC, DD
380		-* DD – Contains Agency EE
	387	+• SDMX – contains Agencies AA, BB
381	381
	389	+• AA – contains Agencies CC, DD
	390	+
	391	+• BB – contains Agencies CC, DD
	392	+
	393	+• DD – Contains Agency EE
	394	+
382	382	Each agency is identified by its full hierarchy excluding SDMX.
383	383
384	384	e.g., the id of EE as an agencyID is AA.DD.EE
...	...	@@ -391,13 +391,13 @@
391	391
392	392	Following the same principles, the Metadata Provider is the maintenance organisation for a special subset of Maintainable Artefacts, i.e., the Metadatasets; the latter are the containers of reference metadata combined with a target that those metadata refer to.
393	393
394		-=== 6.2.2 Universal Resource Name (URN) ===
	407	+===== {{id name="_Toc90807"/}}6.2.2 Universal Resource Name (URN) =====
395	395
396		-==== 6.2.2.1 Introduction ====
	409	+**6.2.2.1 Introduction**
397	397
398	398	To provide interoperability between SDMX Registry/Repositories in a distributed network environment, it is important to have a scheme for uniquely identifying (and thus accessing) all first-class (Identifiable) SDMX-IM objects. Most of these unique identifiers are composite (containing maintenance agency, or parent object identifiers), and there is a need to be able to construct a unique reference as a single string. This is achieved by having a globally unique identifier called a universal resource name (URN) which is generated from the actual identification components in the SDMX-RR APIs. In other words, the URN for any Identifiable Artefact is constructed from its component identifiers (agency, id, version etc.).
399	399
400		-==== 6.2.2.2 URN Structure //__Case Rules for URN__// ====
	413	+**6.2.2.2 URN Structure //__Case Rules for URN__//**// //
401	401
402	402	For the URN, all parts of the string are case sensitive. The generic structure of the URN is as follows:
403	403
...	...	@@ -409,7 +409,7 @@
409	409
410	410	The Maintenance agency identifier is separated from the maintainable artefact identifier by a colon ‘:’. All other identifiers in the SDMX URN syntax are separated by a period ‘.’. The version information is encapsulated in parentheses ‘()’ and adheres to the SDMX versioning rules, as explained in SDMX Standards Section 6 “Technical Notes”, paragraph “4.3 Versioning.
411	411
412		-==== 6.2.2.3 Explanation of the generic structure ====
	425	+**6.2.2.3 Explanation of the generic structure**
413	413
414	414	In the explanation below the actual object that is the target of the URN is called the **actual object**.
415	415
...	...	@@ -488,103 +488,103 @@
488	488
489	489	The SDMX-RR MUST be able to resolve the unique identifier of an SDMX artefact and to produce an SDMX-ML rendering of that artefact if it is located in the Registry.
490	490
491		-=== 6.2.3 Table of SDMX-IM Packages and Classes ===
	504	+===== {{id name="_Toc90808"/}}6.2.3 Table of SDMX-IM Packages and Classes =====
492	492
493	493	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.
494	494
495		-(% style="width:750.835px" %)
496		-|(% style="width:222px" %)**Package**|(% style="width:526px" %)**URN class name (model class name where this is different)**
497		-|(% style="width:222px" %)base|(% style="width:526px" %)Agency
498		-|(% style="width:222px" %) |(% style="width:526px" %)AgencyScheme
499		-|(% style="width:222px" %) |(% style="width:526px" %)DataConsumer
500		-|(% style="width:222px" %) |(% style="width:526px" %)DataConsumerScheme
501		-|(% style="width:222px" %) |(% style="width:526px" %)DataProvider
502		-|(% style="width:222px" %) |(% style="width:526px" %)DataProviderScheme
503		-|(% style="width:222px" %) |(% style="width:526px" %)MetadataProvider
504		-|(% style="width:222px" %) |(% style="width:526px" %)MetadataProviderScheme
505		-|(% style="width:222px" %) |(% style="width:526px" %)OrganisationUnit
506		-|(% style="width:222px" %) |(% style="width:526px" %)OrganisationUnitScheme
507		-|(% style="width:222px" %) |(% style="width:526px" %)
508		-|(% style="width:222px" %)datastructure|(% style="width:526px" %)AttributeDescriptor
509		-|(% style="width:222px" %) |(% style="width:526px" %)DataAttribute
510		-|(% style="width:222px" %) |(% style="width:526px" %)Dataflow
511		-|(% style="width:222px" %) |(% style="width:526px" %)DataStructure (DataStructureDefinition)
512		-|(% style="width:222px" %) |(% style="width:526px" %)Dimension
513		-|(% style="width:222px" %) |(% style="width:526px" %)DimensionDescriptor
514		-|(% style="width:222px" %) |(% style="width:526px" %)GroupDimensionDescriptor
515		-|(% style="width:222px" %) |(% style="width:526px" %)Measure
516		-|(% style="width:222px" %) |(% style="width:526px" %)MeasureDescriptor
517		-|(% style="width:222px" %) |(% style="width:526px" %)TimeDimension
518		-|(% style="width:222px" %) |(% style="width:526px" %)
519		-|(% style="width:222px" %)metadatastructure|(% style="width:526px" %)MetadataAttribute
520		-|(% style="width:222px" %) |(% style="width:526px" %)MetadataAttributeDescriptor
521		-|(% style="width:222px" %) |(% style="width:526px" %)(((
	508	+|**Package**|**URN class name (model class name where this is different)**
	509	+|base|Agency
	510	+| |AgencyScheme
	511	+| |DataConsumer
	512	+| |DataConsumerScheme
	513	+| |DataProvider
	514	+| |DataProviderScheme
	515	+| |MetadataProvider
	516	+| |MetadataProviderScheme
	517	+| |OrganisationUnit
	518	+| |OrganisationUnitScheme
	519	+| |
	520	+|datastructure|AttributeDescriptor
	521	+| |DataAttribute
	522	+| |Dataflow
	523	+| |DataStructure (DataStructureDefinition)
	524	+| |Dimension
	525	+| |DimensionDescriptor
	526	+| |GroupDimensionDescriptor
	527	+| |Measure
	528	+| |MeasureDescriptor
	529	+| |TimeDimension
	530	+| |
	531	+|metadatastructure|MetadataAttribute
	532	+| |MetadataAttributeDescriptor
	533	+| |(((
522	522	MetadataStructure
523	523
524	524	(MetadataStructureDefinition)
525	525	)))
526	526
	539	+:
	540	+
527	527	(((
528		-(% style="width:751.835px" %)
529		-|(% style="width:221px" %)**Package**|(% style="width:528px" %)**URN class name (model class name where this is different)**
530		-|(% style="width:221px" %) |(% style="width:528px" %)Metadataflow
531		-|(% style="width:221px" %) |(% style="width:528px" %)MetadataSet
532		-|(% style="width:221px" %) |(% style="width:528px" %)
533		-|(% style="width:221px" %)process|(% style="width:528px" %)Process
534		-|(% style="width:221px" %) |(% style="width:528px" %)ProcessStep
535		-|(% style="width:221px" %) |(% style="width:528px" %)Transition
536		-|(% style="width:221px" %) |(% style="width:528px" %)
537		-|(% style="width:221px" %)registry|(% style="width:528px" %)DataConstraint
538		-|(% style="width:221px" %) |(% style="width:528px" %)MetadataConstraint
539		-|(% style="width:221px" %) |(% style="width:528px" %)MetadataProvisionAgreement
540		-|(% style="width:221px" %) |(% style="width:528px" %)ProvisionAgreement
541		-|(% style="width:221px" %) |(% style="width:528px" %)Subscription
542		-|(% style="width:221px" %) |(% style="width:528px" %)
543		-|(% style="width:221px" %)structuremapping|(% style="width:528px" %)CategorySchemeMap
544		-|(% style="width:221px" %) |(% style="width:528px" %)ConceptSchemeMap
545		-|(% style="width:221px" %) |(% style="width:528px" %)OrganisationSchemeMap
546		-|(% style="width:221px" %) |(% style="width:528px" %)ReportingTaxonomyMap
547		-|(% style="width:221px" %) |(% style="width:528px" %)RepresentationMap
548		-|(% style="width:221px" %) |(% style="width:528px" %)StructureMap
549		-|(% style="width:221px" %) |(% style="width:528px" %)
550		-|(% style="width:221px" %)codelist|(% style="width:528px" %)Code
551		-|(% style="width:221px" %) |(% style="width:528px" %)Codelist
552		-|(% style="width:221px" %) |(% style="width:528px" %)HierarchicalCode
553		-|(% style="width:221px" %) |(% style="width:528px" %)Hierarchy
554		-|(% style="width:221px" %) |(% style="width:528px" %)HierarchyAssociation
555		-|(% style="width:221px" %) |(% style="width:528px" %)Level
556		-|(% style="width:221px" %) |(% style="width:528px" %)ValueList
557		-|(% style="width:221px" %) |(% style="width:528px" %)
558		-|(% style="width:221px" %)categoryscheme|(% style="width:528px" %)Categorisation
559		-|(% style="width:221px" %) |(% style="width:528px" %)Category
560		-|(% style="width:221px" %) |(% style="width:528px" %)CategoryScheme
561		-|(% style="width:221px" %) |(% style="width:528px" %)ReportingCategory
562		-|(% style="width:221px" %) |(% style="width:528px" %)ReportingTaxonomy
563		-|(% style="width:221px" %)**Package**|(% style="width:528px" %)**URN class name (model class name where this is different)**
564		-|(% style="width:221px" %) |(% style="width:528px" %)
565		-|(% style="width:221px" %)conceptscheme|(% style="width:528px" %)Concept
566		-|(% style="width:221px" %) |(% style="width:528px" %)ConceptScheme
567		-|(% style="width:221px" %) |(% style="width:528px" %)
568		-|(% style="width:221px" %)transformation|(% style="width:528px" %)CustomType
569		-|(% style="width:221px" %) |(% style="width:528px" %)CustomTypeScheme
570		-|(% style="width:221px" %) |(% style="width:528px" %)NamePersonalisation
571		-|(% style="width:221px" %) |(% style="width:528px" %)NamePersonalisationScheme
572		-|(% style="width:221px" %) |(% style="width:528px" %)Ruleset
573		-|(% style="width:221px" %) |(% style="width:528px" %)RulesetScheme
574		-|(% style="width:221px" %) |(% style="width:528px" %)Transformation
575		-|(% style="width:221px" %) |(% style="width:528px" %)TransformationScheme
576		-|(% style="width:221px" %) |(% style="width:528px" %)UserDefinedOperator
577		-|(% style="width:221px" %) |(% style="width:528px" %)UserDefinedOperatorScheme
578		-|(% style="width:221px" %) |(% style="width:528px" %)VtlCodelistMapping
579		-|(% style="width:221px" %) |(% style="width:528px" %)VtlConceptMapping
580		-|(% style="width:221px" %) |(% style="width:528px" %)VtlDataflowMapping
581		-|(% style="width:221px" %) |(% style="width:528px" %)VtlMappingScheme
582		-|(% style="width:221px" %) |(% style="width:528px" %)
	542	+|**Package**|**URN class name (model class name where this is different)**
	543	+| |Metadataflow
	544	+| |MetadataSet
	545	+| |
	546	+|process|Process
	547	+| |ProcessStep
	548	+| |Transition
	549	+| |
	550	+|registry|DataConstraint
	551	+| |MetadataConstraint
	552	+| |MetadataProvisionAgreement
	553	+| |ProvisionAgreement
	554	+| |Subscription
	555	+| |
	556	+|structuremapping|CategorySchemeMap
	557	+| |ConceptSchemeMap
	558	+| |OrganisationSchemeMap
	559	+| |ReportingTaxonomyMap
	560	+| |RepresentationMap
	561	+| |StructureMap
	562	+| |
	563	+|codelist|Code
	564	+| |Codelist
	565	+| |HierarchicalCode
	566	+| |Hierarchy
	567	+| |HierarchyAssociation
	568	+| |Level
	569	+| |ValueList
	570	+| |
	571	+|categoryscheme|Categorisation
	572	+| |Category
	573	+| |CategoryScheme
	574	+| |ReportingCategory
	575	+| |ReportingTaxonomy
	576	+|**Package**|**URN class name (model class name where this is different)**
	577	+| |
	578	+|conceptscheme|Concept
	579	+| |ConceptScheme
	580	+| |
	581	+|transformation|CustomType
	582	+| |CustomTypeScheme
	583	+| |NamePersonalisation
	584	+| |NamePersonalisationScheme
	585	+| |Ruleset
	586	+| |RulesetScheme
	587	+| |Transformation
	588	+| |TransformationScheme
	589	+| |UserDefinedOperator
	590	+| |UserDefinedOperatorScheme
	591	+| |VtlCodelistMapping
	592	+| |VtlConceptMapping
	593	+| |VtlDataflowMapping
	594	+| |VtlMappingScheme
	595	+| |
583	583	)))
584	584
585	585	**Table 2: SDMX-IM Packages and Contained Classes**
586	586
587		-=== 6.2.4 URN Identification components of SDMX objects ===
	600	+===== {{id name="_Toc90809"/}}6.2.4 URN Identification components of SDMX objects =====
588	588
589	589	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.
590	590
...	...	@@ -592,56 +592,67 @@
592	592
593	593	urn:sdmx.org.sdmx.infomodel.{package}.{classname}=
594	594
595		-(% style="width:1272.83px" %)
596		-|(% style="width:290px" %)**Classname**|(% style="width:649px" %)**Ending URN pattern**|(% style="width:332px" %)**Example**
597		-|(% style="width:290px" %)Agency^^[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^2^^>>path:#sdfootnote2sym||name="sdfootnote2anc"]](%%)^^|(% style="width:649px" %)agencySchemeAgencyId:**AGENCIES**(**1.0**).agencyId|(% style="width:332px" %)ECB:**AGENCIES**(**1.0**).AA
598		-|(% style="width:290px" %)//AgencyScheme//|(% style="width:649px" %)agencySchemeAgencyId:**AGENCIES**(**1.0**)|(% style="width:332px" %)ECB:**AGENCIES**(**1.0**)
599		-|(% style="width:290px" %)//Categorisation//|(% style="width:649px" %)categorisationAgencyId:categorisationId(version)|(% style="width:332px" %)IMF:cat001(1.0.0)
600		-|(% style="width:290px" %)Category|(% style="width:649px" %)categorySchemeAgencyId:categorySchemeId(versi on).categoryId.categoryId.categoryId etc.|(% style="width:332px" %)IMF:SDDS(1.0.0):level_1_category.level_2_category …
601		-|(% style="width:290px" %)//CategoryScheme//|(% style="width:649px" %)categorySchemeAgencyId:categorySchemeId(versi on)|(% style="width:332px" %)IMF:SDDS(1.0.0)
	608	+|**Classname**|**Ending URN pattern**|**Example**
	609	+|Agency^^[[(% class="wikiinternallink wikiinternallink wikiinternallink" %)^^2^^>>path:#sdfootnote2sym||name="sdfootnote2anc"]](%%)^^|agencySchemeAgencyId:**AGENCIES**(**1.0**).agencyId|ECB:**AGENCIES**(**1.0**).AA
	610	+|//AgencyScheme//|agencySchemeAgencyId:**AGENCIES**(**1.0**)|ECB:**AGENCIES**(**1.0**)
	611	+|//Categorisation//|categorisationAgencyId:categorisationId(version)|IMF:cat001(1.0.0)
	612	+|Category|categorySchemeAgencyId:categorySchemeId(versi on).categoryId.categoryId.categoryId etc.|IMF:SDDS(1.0.0):level_1_category.level_2_category …
	613	+|//CategoryScheme//|categorySchemeAgencyId:categorySchemeId(versi on)|IMF:SDDS(1.0.0)
602	602
603		-|(% style="width:292px" %)**Classname**|(% style="width:647px" %)**Ending URN pattern**|(% style="width:742px" %)**Example**
604		-|(% style="width:292px" %)//CategorySchemeMap//|(% style="width:647px" %)(((
605		-catSchemeMapAgencyId:catSchemeMapId(version)
606		-)))|(% style="width:742px" %)SDMX:EUROSTAT_SUBJECT_DOMAIN(1.0.0)
607		-|(% style="width:292px" %)Code|(% style="width:647px" %)codeListAgencyId:codelistId(version).codeId|(% style="width:742px" %)SDMX:CL_FREQ(1.0.0).Q
608		-|(% style="width:292px" %)//Codelist//|(% style="width:647px" %)codeListAgencyId:codeListId(version)|(% style="width:742px" %)SDMX:CL_FREQ(1.0.0)
609		-|(% style="width:292px" %)ComponentMap|(% style="width:647px" %)structureMapAgencyId:structureMap(version).com ponentMapId|(% style="width:742px" %)SDMX:BOP_STRUCTURES(1.0.0).REF_AREA_TO_COUNT RY
610		-|(% style="width:292px" %)Concept|(% style="width:647px" %)conceptSchemeAgencyId:conceptSchemeId(versio n).conceptId|(% style="width:742px" %)SDMX:CROSS_DOMAIN_CONCEPTS(1.0.0).FREQ
611		-|(% style="width:292px" %)//ConceptScheme//|(% style="width:647px" %)conceptSchemeAgencyId:conceptSchemeId(versio n)|(% style="width:742px" %)SDMX:CROSS_DOMAIN_CONCEPTS(1.0.0)
612		-|(% style="width:292px" %)//ConceptSchemeMap//|(% style="width:647px" %)(((
613		-conceptSchemeMapAgencyId:conceptSchemeMap Id(version)
614		-)))|(% style="width:742px" %)SDMX:CONCEPT_MAP(1.0.0)
615		-|(% style="width:292px" %)CustomType|(% style="width:647px" %)customTypeSchemeAgencyId customTypeSchemeId(version) customTypeId|(% style="width:742px" %)ECB: CUSTOM_TYPE_SCHEME(1.0.0).CUSTOM_TYPE_1
616		-|(% style="width:292px" %)//CustomTypeScheme//|(% style="width:647px" %)customTypeSchemeAgencyId customTypeSchemeId(version)|(% style="width:742px" %)ECB:CUSTOM_TYPE_SCHEME(1.0.0)
617		-|(% style="width:292px" %)DataAttrribute|(% style="width:647px" %)dataStructureDefinitionAgencyId:dataStructureDef initionId(version).dataAttributeId|(% style="width:742px" %)TFFS:EXT_DEBT(1.0.0).OBS_STATUS
618		-|(% style="width:292px" %)//DataConstraint//|(% style="width:647px" %)dataConstraintAgencyId:dataConstraintId(version)|(% style="width:742px" %)TFFS:CREDITOR_DATA_CONTENT(1.0.0)
	615	+|**Classname**|**Ending URN pattern**|**Example**
	616	+|//CategorySchemeMap//|(((
	617	+catSchemeMapAgencyId:catSchemeMapId(version
619	619
620		-|(% style="width:294px" %)**Classname**|(% style="width:645px" %)**Ending URN pattern**|(% style="width:742px" %)**Example**
621		-|(% style="width:294px" %)DataConsumer|(% style="width:645px" %)dataConsumerSchemeAgencyId:**DATA_CONSUME RS**(**1.0**).dataConsumerId|(% style="width:742px" %)SDMX:**DATA_CONSUMERS**(**1.0**).CONSUMER_1
622		-|(% style="width:294px" %)//DataConsumerScheme//|(% style="width:645px" %)(((
623		-dataConsumerSchemeAgencyId:**DATA_CONSUME RS**(**1.0**)
624		-)))|(% style="width:742px" %)SDMX:**DATA_CONSUMERS**(**1.0**)
625		-|(% style="width:294px" %)//Dataflow//|(% style="width:645px" %)dataflowAgencyId:dataflowId(version)|(% style="width:742px" %)TFFS:CRED_EXT_DEBT(1.0.0)
626		-|(% style="width:294px" %)DataProvider|(% style="width:645px" %)(((
627		-dataProviderSchemeAgencyId:**DATA_PROVIDERS**(**1.0**).dataProviderId
628		-)))|(% style="width:742px" %)SDMX:**DATA_PROVIDERS**(**1.0**).PROVIDER_1
629		-|(% style="width:294px" %)//DataProviderScheme//|(% style="width:645px" %)(((
630		-dataProviderSchemeAgencyId:**DATA_PROVIDERS**(**1.0**)
631		-)))|(% style="width:742px" %)SDMX:**DATA_PROVIDERS**(**1.0**)
632		-|(% style="width:294px" %)//DataStructure//|(% style="width:645px" %)dataStructureDefinitionAgencyId:dataStructureDef initionId(version)|(% style="width:742px" %)TFFS:EXT_DEBT(1.0.0)
633		-|(% style="width:294px" %)Dimension|(% style="width:645px" %)dataStructureDefinitionAgencyId:dataStructureDef initionId(version).dimensionId|(% style="width:742px" %)TFFS:EXT_DEBT(1.0.0).FREQ
634		-|(% style="width:294px" %)(((
	619	+)
	620	+)))|SDMX:EUROSTAT_SUBJECT_DOMAIN(1.0.0)
	621	+|Code|codeListAgencyId:codelistId(version).codeId|SDMX:CL_FREQ(1.0.0).Q
	622	+|//Codelist//|codeListAgencyId:codeListId(version)|SDMX:CL_FREQ(1.0.0)
	623	+|ComponentMap|structureMapAgencyId:structureMap(version).com ponentMapId|SDMX:BOP_STRUCTURES(1.0.0).REF_AREA_TO_COUNT RY
	624	+|Concept|conceptSchemeAgencyId:conceptSchemeId(versio n).conceptId|SDMX:CROSS_DOMAIN_CONCEPTS(1.0.0).FREQ
	625	+|//ConceptScheme//|conceptSchemeAgencyId:conceptSchemeId(versio n)|SDMX:CROSS_DOMAIN_CONCEPTS(1.0.0)
	626	+|//ConceptSchemeMap//|(((
	627	+conceptSchemeMapAgencyId:conceptSchemeMap
	628	+
	629	+Id(version)
	630	+)))|SDMX:CONCEPT_MAP(1.0.0)
	631	+|CustomType|customTypeSchemeAgencyId customTypeSchemeId(version) customTypeId|ECB: CUSTOM_TYPE_SCHEME(1.0.0).CUSTOM_TYPE_1
	632	+|//CustomTypeScheme//|customTypeSchemeAgencyId customTypeSchemeId(version)|ECB:CUSTOM_TYPE_SCHEME(1.0.0)
	633	+|DataAttrribute|dataStructureDefinitionAgencyId:dataStructureDef initionId(version).dataAttributeId|TFFS:EXT_DEBT(1.0.0).OBS_STATUS
	634	+|//DataConstraint//|dataConstraintAgencyId:dataConstraintId(version)|TFFS:CREDITOR_DATA_CONTENT(1.0.0)
	635	+
	636	+|**Classname**|**Ending URN pattern**|**Example**
	637	+|DataConsumer|dataConsumerSchemeAgencyId:**DATA_CONSUME RS**(**1.0**).dataConsumerId|SDMX:**DATA_CONSUMERS**(**1.0**).CONSUMER_1
	638	+|//DataConsumerScheme//|(((
	639	+dataConsumerSchemeAgencyId:**DATA_CONSUME**
	640	+
	641	+**RS**(**1.0**)
	642	+)))|SDMX:**DATA_CONSUMERS**(**1.0**)
	643	+|//Dataflow//|dataflowAgencyId:dataflowId(version)|TFFS:CRED_EXT_DEBT(1.0.0)
	644	+|DataProvider|(((
	645	+dataProviderSchemeAgencyId:**DATA_PROVIDERS**(
	646	+
	647	+**1.0**).dataProviderId
	648	+)))|SDMX:**DATA_PROVIDERS**(**1.0**).PROVIDER_1
	649	+|//DataProviderScheme//|(((
	650	+dataProviderSchemeAgencyId:**DATA_PROVIDERS**(
	651	+
	652	+**1.0**)
	653	+)))|SDMX:**DATA_PROVIDERS**(**1.0**)
	654	+|//DataStructure//|dataStructureDefinitionAgencyId:dataStructureDef initionId(version)|TFFS:EXT_DEBT(1.0.0)
	655	+|Dimension|dataStructureDefinitionAgencyId:dataStructureDef initionId(version).dimensionId|TFFS:EXT_DEBT(1.0.0).FREQ
	656	+|(((
635	635	DimensionDescriptor
636	636
637	637	MeasureDescriptor
638	638
639	639	AttributeDescriptor
640		-)))|(% style="width:645px" %)(((
	662	+)))|(((
641	641	dataStructureDefinitionAgencyId:dataStructureDef initionId(version).componentListId
642	642
643		-where the componentListId is the name of the class (there is only one occurrence of each in the Data Structure Definition)
644		-)))|(% style="width:742px" %)(((
	665	+where the componentListId is the name of the class (there is only one occurrence of each in the
	666	+
	667	+Data Structure Definition)
	668	+)))|(((
645	645	TFFS:EXT_DEBT(1.0.0).DimensionDescriptor
646	646
647	647	TFFS:EXT_DEBT(1.0.0).MeasureDescriptor
...	...	@@ -648,81 +648,83 @@
648	648
649	649	TFFS:EXT_DEBT(1.0.0).AttributeDescriptor
650	650	)))
651		-|(% style="width:294px" %)GroupDimensionDescriptor|(% style="width:645px" %)dataStructureDefinitionAgencyId:dataStructureDef initionId(version).groupDimensionDescriptorId|(% style="width:742px" %)TFFS:EXT_DEBT(1.0.0).SIBLING
652		-|(% style="width:294px" %)HierarchicalCode|(% style="width:645px" %)hierarchyAgencyId:hierarchyId(version).hierarchica lCode.hierarchicalCode|(% style="width:742px" %)UNESCO:H-C-GOV(1.0.0).GOV_CODE1.GOV_CODE1_1
	675	+|GroupDimensionDescriptor|dataStructureDefinitionAgencyId:dataStructureDef initionId(version).groupDimensionDescriptorId|TFFS:EXT_DEBT(1.0.0).SIBLING
	676	+|HierarchicalCode|hierarchyAgencyId:hierarchyId(version).hierarchica lCode.hierarchicalCode|UNESCO:H-C-GOV(1.0.0).GOV_CODE1.GOV_CODE1_1
653	653
654		-|**Classname**|(% style="width:644px" %)**Ending URN pattern**|(% style="width:743px" %)**Example**
655		-|//Hierarchy//|(% style="width:644px" %)hierarchyAgencyId:hierarchyId(version)|(% style="width:743px" %)UNESCO:H-C-GOV(1.0.0)
656		-|//HierarchyAssociation//|(% style="width:644px" %)hierarchyAssociationAgencyId:hierarchyAssociatio nId(version)|(% style="width:743px" %)UNESCO:CL_EXP_SOURCE(1.0.0)
657		-|Level|(% style="width:644px" %)hierarchyAgencyId:hierarchyId(version).level|(% style="width:743px" %)UNESCO:H-C-GOV(1.0.0).LVL1
658		-|Measure|(% style="width:644px" %)dataStructureDefinitionAgencyId:dataStructureDef initionId(version).measureId|(% style="width:743px" %)TFFS:EXT_DEBT(1.0.0).OBS_VALUE
659		-|MetadataAttribute|(% style="width:644px" %)(((
	678	+|**Classname**|**Ending URN pattern**|**Example**
	679	+|//Hierarchy//|hierarchyAgencyId:hierarchyId(version)|UNESCO:H-C-GOV(1.0.0)
	680	+|//HierarchyAssociation//|hierarchyAssociationAgencyId:hierarchyAssociatio nId(version)|UNESCO:CL_EXP_SOURCE(1.0.0)
	681	+|Level|hierarchyAgencyId:hierarchyId(version).level|UNESCO:H-C-GOV(1.0.0).LVL1
	682	+|Measure|dataStructureDefinitionAgencyId:dataStructureDef initionId(version).measureId|TFFS:EXT_DEBT(1.0.0).OBS_VALUE
	683	+|MetadataAttribute|(((
660	660	msdAgencyId:msdId(version).metadataAttributeId.
661	661
662	662	metadataAttributeId
663		-)))|(% style="width:743px" %)IMF:SDDS_MSD(1.0.0).COMPILATION.METHOD
664		-|MetadataAttributeDescriptor|(% style="width:644px" %)msdAgencyId:msdId(version).metadataAttributeDe scriptorId|(% style="width:743px" %)IMF:SDDS_MSD(1.0.0).MetadataAttributeDescriptor
665		-|//MetadataConstraint//|(% style="width:644px" %)metadataConstraintAgencyId:metadataConstraintI d(version)|(% style="width:743px" %)TFFS:CREDITOR_METADATA_CONTENT(1.0.0)
666		-|//Metadataflow//|(% style="width:644px" %)metadataflowAgencyId:metadataflowId(version)|(% style="width:743px" %)IMF:SDDS_MDF(1.0.0)
667		-|MetadataProvider|(% style="width:644px" %)metadataProviderSchemeAgencyId:**METADATA_P ROVIDERS**(**1.0**).metadataProviderId|(% style="width:743px" %)SDMX:**METADATA_PROVIDERS**(**1.0**).MD_PROVIDER_1
668		-|//MetadataProviderScheme//|(% style="width:644px" %)metadataProviderSchemeAgencyId:**METADATA_P ROVIDERS**(**1.0**)|(% style="width:743px" %)SDMX:**METADATA_PROVIDERS**(**1.0**)
669		-|//MetadataProvisionAgreement//|(% style="width:644px" %)metadataProvisionAgreementAgencyId:metadataP rovisionAgreementId(version)|(% style="width:743px" %)IMF:SDDS_MDF_AB(1.0.0)
670		-|//MetadataSet//|(% style="width:644px" %)metadataProviderId:metadataSetId(version)|(% style="width:743px" %)MD_PROVIDER:METADATASET(1.0.0)
671		-|//MetadataStructure//|(% style="width:644px" %)msdAgencyId:msdId(version)|(% style="width:743px" %)IMF:SDDS_MSD(1.0.0)
	687	+)))|IMF:SDDS_MSD(1.0.0).COMPILATION.METHOD
	688	+|MetadataAttributeDescriptor|msdAgencyId:msdId(version).metadataAttributeDe scriptorId|IMF:SDDS_MSD(1.0.0).MetadataAttributeDescriptor
	689	+|//MetadataConstraint//|metadataConstraintAgencyId:metadataConstraintI d(version)|TFFS:CREDITOR_METADATA_CONTENT(1.0.0)
	690	+|//Metadataflow//|metadataflowAgencyId:metadataflowId(version)|IMF:SDDS_MDF(1.0.0)
	691	+|MetadataProvider|metadataProviderSchemeAgencyId:**METADATA_P ROVIDERS**(**1.0**).metadataProviderId|SDMX:**METADATA_PROVIDERS**(**1.0**).MD_PROVIDER_1
	692	+|//MetadataProviderScheme//|metadataProviderSchemeAgencyId:**METADATA_P ROVIDERS**(**1.0**)|SDMX:**METADATA_PROVIDERS**(**1.0**)
	693	+|//MetadataProvisionAgreement//|metadataProvisionAgreementAgencyId:metadataP rovisionAgreementId(version)|IMF:SDDS_MDF_AB(1.0.0)
	694	+|//MetadataSet//|metadataProviderId:metadataSetId(version)|MD_PROVIDER:METADATASET(1.0.0)
	695	+|//MetadataStructure//|msdAgencyId:msdId(version)|IMF:SDDS_MSD(1.0.0)
672	672
673		-|(% style="width:296px" %)**Classname**|(% style="width:646px" %)**Ending URN pattern**|(% style="width:739px" %)**Example**
674		-|(% style="width:296px" %)NamePersonalisation|(% style="width:646px" %)namePersonalisationSchemeAgencyId namePersonalisationSchemeId(version) namePersonalisationId|(% style="width:739px" %)ECB:PSN_SCHEME(1.0.0).PSN1234
675		-|(% style="width:296px" %)//NamePersonalisationScheme//|(% style="width:646px" %)namePersonalisationSchemeAgencyId namePersonalisationSchemeId(version)|(% style="width:739px" %)ECB:PSN_SCHEME(1.0.0)
676		-|(% style="width:296px" %)//OrganisationSchemeMap//|(% style="width:646px" %)orgSchemeMapAgencyId:orgSchemeMapId(versio n)|(% style="width:739px" %)SDMX:AGENCIES_PROVIDERS(1.0.0)
677		-|(% style="width:296px" %)OrganisationUnit|(% style="width:646px" %)organisationUnitSchemeAgencyId:organisationUni tSchemeId(version).organisationUnitId|(% style="width:739px" %)ECB:ORGANISATIONS(1.0.0).1F
678		-|(% style="width:296px" %)//OrganisationUnitScheme//|(% style="width:646px" %)organisationUnitSchemeAgencyId:organisationUni tSchemeId(version)|(% style="width:739px" %)ECB:ORGANISATIONS(1.0.0)
679		-|(% style="width:296px" %)//Process//|(% style="width:646px" %)processAgencyId:processId{version)|(% style="width:739px" %)BIS:PROCESS1(1.0.0)
680		-|(% style="width:296px" %)ProcessStep|(% style="width:646px" %)(((
	697	+|**Classname**|**Ending URN pattern**|**Example**
	698	+|NamePersonalisation|namePersonalisationSchemeAgencyId namePersonalisationSchemeId(version) namePersonalisationId|ECB:PSN_SCHEME(1.0.0).PSN1234
	699	+|//NamePersonalisationScheme//|namePersonalisationSchemeAgencyId namePersonalisationSchemeId(version)|ECB:PSN_SCHEME(1.0.0)
	700	+|//OrganisationSchemeMap//|orgSchemeMapAgencyId:orgSchemeMapId(versio n)|SDMX:AGENCIES_PROVIDERS(1.0.0)
	701	+|OrganisationUnit|organisationUnitSchemeAgencyId:organisationUni tSchemeId(version).organisationUnitId|ECB:ORGANISATIONS(1.0.0).1F
	702	+|//OrganisationUnitScheme//|organisationUnitSchemeAgencyId:organisationUni tSchemeId(version)|ECB:ORGANISATIONS(1.0.0)
	703	+|//Process//|processAgencyId:processId{version)|BIS:PROCESS1(1.0.0)
	704	+|ProcessStep|(((
681	681	processAgencyId:processId(version).processStepId.
682	682
683	683	processStepId
684		-)))|(% style="width:739px" %)BIS:PROCESS1(1.0.0).STEP1.STEP1_1
685		-|(% style="width:296px" %)//ProvisionAgreement//|(% style="width:646px" %)provisionAgreementAgencyId:provisionAgreement Id(version)|(% style="width:739px" %)TFFS:CRED_EXT_DEBT_AB(1.0.0)
686		-|(% style="width:296px" %)ReportingCategory|(% style="width:646px" %)(((
	708	+)))|BIS:PROCESS1(1.0.0).STEP1.STEP1_1
	709	+|//ProvisionAgreement//|provisionAgreementAgencyId:provisionAgreement Id(version)|TFFS:CRED_EXT_DEBT_AB(1.0.0)
	710	+|ReportingCategory|(((
687	687	reportingTaxonomyAgencyId:
688	688
689	689	reportingTaxonomyId(version).reportingCategoryI d.reportingCategoryId
690		-)))|(% style="width:739px" %)IMF:REP_1(1.0.0):LVL1_REP_CAT.LVL2_REP_CAT
691		-|(% style="width:296px" %)//ReportingTaxonomy//|(% style="width:646px" %)reportingTaxonomyAgencyId:reportingTaxonomyI d(version)|(% style="width:739px" %)IMF:REP_1(1.0.0)
692		-|(% style="width:296px" %)//ReportingTaxonomyMap//|(% style="width:646px" %)repTaxonomyAgencyId:repTaxonomyId(version)|(% style="width:739px" %)SDMX:RT_MAP(1.0.0)
	714	+)))|IMF:REP_1(1.0.0):LVL1_REP_CAT.LVL2_REP_CAT
	715	+|//ReportingTaxonomy//|reportingTaxonomyAgencyId:reportingTaxonomyI d(version)|IMF:REP_1(1.0.0)
	716	+|//ReportingTaxonomyMap//|repTaxonomyAgencyId:repTaxonomyId(version)|SDMX:RT_MAP(1.0.0)
693	693
694		-|(% style="width:297px" %)**Classname**|(% style="width:647px" %)**Ending URN pattern**|(% style="width:737px" %)**Example**
695		-|(% style="width:297px" %)//RepresentationMap//|(% style="width:647px" %)repMapAgencyId:repMapId(version)|(% style="width:737px" %)SDMX:REF_AREA_MAPPING(1.0.0)
696		-|(% style="width:297px" %)Ruleset|(% style="width:647px" %)rulesetSchemeAgencyId rulesetSchemeId(version) rulesetId|(% style="width:737px" %)ECB:RULESET_23(1.0.0).SET111
697		-|(% style="width:297px" %)//RulesetScheme//|(% style="width:647px" %)rulesetSchemeAgencyId rulesetSchemeId(version)|(% style="width:737px" %)ECB:RULESET_23(1.0.0)
698		-|(% style="width:297px" %)//StructureMap//|(% style="width:647px" %)structureMapAgencyId:structureMap(version)|(% style="width:737px" %)SDMX:BOP_STRUCTURES(1.0.0)
699		-|(% style="width:297px" %)Subscription|(% style="width:647px" %)(((
	718	+|**Classname**|**Ending URN pattern**|**Example**
	719	+|//RepresentationMap//|repMapAgencyId:repMapId(version)|SDMX:REF_AREA_MAPPING(1.0.0)
	720	+|Ruleset|rulesetSchemeAgencyId rulesetSchemeId(version) rulesetId|ECB:RULESET_23(1.0.0).SET111
	721	+|//RulesetScheme//|rulesetSchemeAgencyId rulesetSchemeId(version)|ECB:RULESET_23(1.0.0)
	722	+|//StructureMap//|structureMapAgencyId:structureMap(version)|SDMX:BOP_STRUCTURES(1.0.0)
	723	+|Subscription|(((
700	700	The Subscription is not itself an Identifiable Artefact and therefore it does not follow the rules for URN structure.
	725	+
701	701	The name of the URN is registryURN There is no pre-determined format.
702		-)))|(% style="width:737px" %)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 registry URN that is returned from the registry in the subscription response message.
703		-|(% style="width:297px" %)TimeDimension|(% style="width:647px" %)dataStructureDefinitionAgencyId:dataStructureDef initionId(version).timeDimensionId|(% style="width:737px" %)TFFS:EXT_DEBT(1.0.0).TIME_PERIOD
704		-|(% style="width:297px" %)Transformation|(% style="width:647px" %)transformationSchemeAgencyId transformationSchemeId(version) transformationId|(% style="width:737px" %)ECB:TRANSFORMATION_SCHEME(1.0.0).TRANS_1
705		-|(% style="width:297px" %)//TransformationScheme//|(% style="width:647px" %)transformationSchemeAgencyId transformationSchemeId(version)|(% style="width:737px" %)ECB: TRANSFORMATION_SCHEME(1.0.0)
706		-|(% style="width:297px" %)**Classname**|(% style="width:647px" %)**Ending URN pattern**|(% style="width:737px" %)**Example**
707		-|(% style="width:297px" %)Transition|(% style="width:647px" %)(((
	727	+)))|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 registry URN that is returned from the registry in the subscription response message.
	728	+|TimeDimension|dataStructureDefinitionAgencyId:dataStructureDef initionId(version).timeDimensionId|TFFS:EXT_DEBT(1.0.0).TIME_PERIOD
	729	+|Transformation|transformationSchemeAgencyId transformationSchemeId(version) transformationId|ECB:TRANSFORMATION_SCHEME(1.0.0).TRANS_1
	730	+|//TransformationScheme//|transformationSchemeAgencyId transformationSchemeId(version)|ECB: TRANSFORMATION_SCHEME(1.0.0)
	731	+|**Classname**|**Ending URN pattern**|**Example**
	732	+|Transition|(((
708	708	processAgencyId:processId(version).processStepId.
	734	+
709	709	transitionId
710		-)))|(% style="width:737px" %)BIS:PROCESS1(1.0.0).STEP1.TRANSITION1
711		-|(% style="width:297px" %)UserDefinedOperator|(% style="width:647px" %)userDefinedOperatorSchemeAgencyId userDefinedOperatorSchemeId(version) usserDefinedOperatorId|(% style="width:737px" %)ECB:OS_CALC(1.2.0).OS267
712		-|(% style="width:297px" %)//UserDefinedOperatorScheme//|(% style="width:647px" %)userDefinedOperatorSchemeAgencyId userDefinedOperatorSchemeId(version)|(% style="width:737px" %)ECB:OS_CALC(1.2.0)
713		-|(% style="width:297px" %)//ValueList//|(% style="width:647px" %)valuelistAgencyId:valuelistId(version)|(% style="width:737px" %)SDMX:VLIST(1.0.0)
714		-|(% style="width:297px" %)VtlCodelistMapping|(% style="width:647px" %)vtlMappingSchemeAgencyId vtlMappingSchemeId(version) vtlCodelistMappingId|(% style="width:737px" %)ECB:CLIST_MP(2.0.0).ABZ
715		-|(% style="width:297px" %)VtlConceptMapping|(% style="width:647px" %)vtlMappingSchemeAgencyId vtlMappingSchemeId(version) vtlConceptMappingId|(% style="width:737px" %)ECB:CLIST_MP(1.0.0).XYA
716		-|(% style="width:297px" %)VtlDataflowMapping|(% style="width:647px" %)vtlMappingSchemeAgencyId vtlMappingSchemeId(version) vtlDataflowMappingId|(% style="width:737px" %)ECB:CLIST_MP(1.0.0).MOQ
717		-|(% style="width:297px" %)//VtlMappingScheme//|(% style="width:647px" %)vtlMappingSchemeAgencyId VtlMappingSchemeId(version)|(% style="width:737px" %)ECB:CLIST_MP(2.0.0)
	736	+)))|BIS:PROCESS1(1.0.0).STEP1.TRANSITION1
	737	+|UserDefinedOperator|userDefinedOperatorSchemeAgencyId userDefinedOperatorSchemeId(version) usserDefinedOperatorId|ECB:OS_CALC(1.2.0).OS267
	738	+|//UserDefinedOperatorScheme//|userDefinedOperatorSchemeAgencyId userDefinedOperatorSchemeId(version)|ECB:OS_CALC(1.2.0)
	739	+|//ValueList//|valuelistAgencyId:valuelistId(version)|SDMX:VLIST(1.0.0)
	740	+|VtlCodelistMapping|vtlMappingSchemeAgencyId vtlMappingSchemeId(version) vtlCodelistMappingId|ECB:CLIST_MP(2.0.0).ABZ
	741	+|VtlConceptMapping|vtlMappingSchemeAgencyId vtlMappingSchemeId(version) vtlConceptMappingId|ECB:CLIST_MP(1.0.0).XYA
	742	+|VtlDataflowMapping|vtlMappingSchemeAgencyId vtlMappingSchemeId(version) vtlDataflowMappingId|ECB:CLIST_MP(1.0.0).MOQ
	743	+|//VtlMappingScheme//|vtlMappingSchemeAgencyId VtlMappingSchemeId(version)|ECB:CLIST_MP(2.0.0)
718	718
719	719	5**Table 3: Table of identification components for SDMX Identifiable Artefacts**
720	720
721		-= 7 Implementation Notes =
	747	+= {{id name="_Toc90810"/}}7 Implementation Notes =
722	722
723		-== 7.1 Structural Definition Metadata ==
	749	+=== {{id name="_Toc90811"/}}7.1 Structural Definition Metadata ===
724	724
725		-=== 7.1.1 Introduction ===
	751	+===== {{id name="_Toc90812"/}}7.1.1 Introduction =====
726	726
727	727	The SDMX Registry must have the ability to support agencies in their role of defining and disseminating structural metadata artefacts. These artefacts include data structure definitions, code lists, concepts etc. and are fully defined in the SDMX-IM. An authenticated agency may submit valid structural metadata definitions which must be stored in the registry. Note that the term “structural metadata” refers as a general term to all structural components (Data Structure Definitions, Metadata Structure Definitions, Code Lists, Concept Schemes, etc.)
728	728
...	...	@@ -738,40 +738,46 @@
738	738
739	739	The following table lists the Maintainable Artefacts.
740	740
741		-(% style="width:825.835px" %)
742		-|(% colspan="2" style="width:455px" %)**Maintainable Artefacts**|(% style="width:367px" %)**Content**
743		-|(% style="width:160px" %)**Abstract Class**|(% style="width:295px" %)**Concrete Class**|(% style="width:367px" %)
744		-|(% style="width:160px" %)Item Scheme|(% style="width:295px" %)Codelist|(% style="width:367px" %)Code
745		-|(% style="width:160px" %) |(% style="width:295px" %)Concept Scheme|(% style="width:367px" %)Concept
746		-|(% style="width:160px" %) |(% style="width:295px" %)Category Scheme|(% style="width:367px" %)Category
747		-|(% style="width:160px" %) |(% style="width:295px" %)Organisation Unit Scheme|(% style="width:367px" %)Organisation Unit
748		-|(% style="width:160px" %) |(% style="width:295px" %)Agency Scheme|(% style="width:367px" %)Agency
749		-|(% style="width:160px" %) |(% style="width:295px" %)Data Provider Scheme|(% style="width:367px" %)Data Provider
750		-|(% style="width:160px" %) |(% style="width:295px" %)Metadata Provider Scheme|(% style="width:367px" %)Metadata Provider
751		-|(% style="width:160px" %) |(% style="width:295px" %)Data Consumer Scheme|(% style="width:367px" %)Data Consumer
752		-|(% style="width:160px" %) |(% style="width:295px" %)Reporting Taxonomy|(% style="width:367px" %)Reporting Category
753		-|(% style="width:160px" %) |(% style="width:295px" %)Transformation Scheme|(% style="width:367px" %)Transformation
754		-|(% style="width:160px" %) |(% style="width:295px" %)Custom Type Scheme|(% style="width:367px" %)Custom Type
755		-|(% style="width:160px" %) |(% style="width:295px" %)Name Personalisation Scheme|(% style="width:367px" %)Name Personalisation
756		-|(% style="width:160px" %) |(% style="width:295px" %)Vtl Mapping Scheme|(% style="width:367px" %)Vtl Codelist Mapping Vtl Concept Mapping
757		-|(% style="width:160px" %) |(% style="width:295px" %)Ruleset Scheme|(% style="width:367px" %)Ruleset
758		-|(% style="width:160px" %) |(% style="width:295px" %)User Defined Operator Scheme|(% style="width:367px" %)User Defined Operator
759		-|(% style="width:160px" %)Enumerated List|(% style="width:295px" %)ValueList|(% style="width:367px" %)Value Item
760		-|(% style="width:160px" %)Structure|(% style="width:295px" %)Data Structure Definition|(% style="width:367px" %)(((
	767	+|(% colspan="2" %)**Maintainable Artefacts**|**Content**
	768	+|**Abstract Class**|**Concrete Class**|
	769	+|Item Scheme|Codelist|Code
	770	+| |Concept Scheme|Concept
	771	+| |Category Scheme|Category
	772	+| |Organisation Unit Scheme|Organisation Unit
	773	+| |Agency Scheme|Agency
	774	+| |Data Provider Scheme|Data Provider
	775	+| |Metadata Provider Scheme|Metadata Provider
	776	+| |Data Consumer Scheme|Data Consumer
	777	+| |Reporting Taxonomy|Reporting Category
	778	+| |Transformation Scheme|Transformation
	779	+| |Custom Type Scheme|Custom Type
	780	+| |Name Personalisation Scheme|Name Personalisation
	781	+| |Vtl Mapping Scheme|Vtl Codelist Mapping Vtl Concept Mapping
	782	+| |Ruleset Scheme|Ruleset
	783	+| |User Defined Operator Scheme|User Defined Operator
	784	+|Enumerated List|ValueList|Value Item
	785	+|Structure|Data Structure Definition|(((
761	761	Dimension Descriptor
	787	+
762	762	Group Dimension Descriptor
	789	+
763	763	Dimension
	791	+
764	764	Time Dimension
	793	+
765	765	Attribute Descriptor
	795	+
766	766	Data Attribute
	797	+
767	767	Measure Descriptor
	799	+
768	768	Measure
769	769	)))
770		-|(% style="width:160px" %) |(% style="width:295px" %)Metadata Structure Definition|(% style="width:367px" %)Metadata Attribute Descriptor Metadata Attribute
771		-|(% style="width:160px" %)Structure Usage|(% style="width:295px" %)Dataflow|(% style="width:367px" %)
772		-|(% style="width:160px" %) |(% style="width:295px" %)Metadataflow|(% style="width:367px" %)
773		-|(% style="width:160px" %)None|(% style="width:295px" %)Process|(% style="width:367px" %)Process Step
774		-|(% style="width:160px" %)None|(% style="width:295px" %)Structure Map|(% style="width:367px" %)(((
	802	+| |Metadata Structure Definition|Metadata Attribute Descriptor Metadata Attribute
	803	+|Structure Usage|Dataflow|
	804	+| |Metadataflow|
	805	+|None|Process|Process Step
	806	+|None|Structure Map|(((
775	775	Component Map
776	776
777	777	Epoch Map
...	...	@@ -778,44 +778,44 @@
778	778
779	779	Date Pattern Map
780	780	)))
781		-|(% style="width:160px" %)None|(% style="width:295px" %)Representation Map|(% style="width:367px" %)Representation Mapping
782		-|(% style="width:160px" %)Item Scheme Map|(% style="width:295px" %)Organisation Scheme Map|(% style="width:367px" %)Item Map
783		-|(% style="width:160px" %) |(% style="width:295px" %)Concept Scheme Map|(% style="width:367px" %)Item Map
784		-|(% style="width:160px" %) |(% style="width:295px" %)Category Scheme Map|(% style="width:367px" %)Item Map
785		-|(% style="width:160px" %) |(% style="width:295px" %)Reporting Taxonomy Map|(% style="width:367px" %)Item Map
786		-|(% style="width:160px" %)None|(% style="width:295px" %)Provision Agreement|(% style="width:367px" %)
787		-|(% style="width:160px" %)None|(% style="width:295px" %)Metadata Provision Agreement|(% style="width:367px" %)
788		-|(% style="width:160px" %)None|(% style="width:295px" %)Hierarchy|(% style="width:367px" %)Hierarchical Code
789		-|(% style="width:160px" %)None|(% style="width:295px" %)Hierarchy Association|(% style="width:367px" %)
790		-|(% style="width:160px" %)None|(% style="width:295px" %)Categorisation|(% style="width:367px" %)
791		-|(% style="width:160px" %)Constraint|(% style="width:295px" %)Data Constraint|(% style="width:367px" %)DataKeySet
792		-|(% style="width:160px" %) |(% style="width:295px" %) |(% style="width:367px" %)CubeRegion
793		-|(% style="width:160px" %)Constraint|(% style="width:295px" %)Metadata Constraint|(% style="width:367px" %)MetadataTargetRegion
	813	+|None|Representation Map|Representation Mapping
	814	+|Item Scheme Map|Organisation Scheme Map|Item Map
	815	+| |Concept Scheme Map|Item Map
	816	+| |Category Scheme Map|Item Map
	817	+| |Reporting Taxonomy Map|Item Map
	818	+|None|Provision Agreement|
	819	+|None|Metadata Provision Agreement|
	820	+|None|Hierarchy|Hierarchical Code
	821	+|None|Hierarchy Association|
	822	+|None|Categorisation|
	823	+|Constraint|Data Constraint|DataKeySet
	824	+| | |CubeRegion
	825	+|Constraint|Metadata Constraint|MetadataTargetRegion
794	794
795	795	**Table 4: Table of Maintainable Artefacts for Structural Definition Metadata**
796	796
797		-=== 7.1.2 Item Scheme, Structure ===
	829	+===== {{id name="_Toc90813"/}}7.1.2 Item Scheme, Structure =====
798	798
799	799	The artefacts included in the structural definitions are:
800	800
801	801	* All types of Item Scheme (Codelist, Concept Scheme, Category Scheme, Organisation Scheme, Agency Scheme, Data Provider Scheme, Metadata Provider Scheme, Data Consumer Scheme, Organisation Unit Scheme, Transformation Scheme, Name Personalisation Scheme, Custom Type Scheme, Vtl Mapping Scheme, Ruleset Scheme, User Defined Operator Scheme)
802		-* All types of Enumerated List (ValueList)^^[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^3^^>>path:#sdfootnote3sym||name="sdfootnote3anc"]](%%)^^
	834	+* All types of Enumerated List (ValueList)^^[[(% class="wikiinternallink wikiinternallink wikiinternallink" %)^^3^^>>path:#sdfootnote3sym||name="sdfootnote3anc"]](%%)^^
803	803	* All types of Structure (Data Structure Definition, Metadata Structure Definition)
804	804	* All types of Structure Usage (Dataflow, Metadataflow)
805	805
806		-=== 7.1.3 Structure Usage ===
	838	+===== {{id name="_Toc90814"/}}7.1.3 Structure Usage =====
807	807
808		-==== 7.1.3.1 Structure Usage: Basic Concepts ====
	840	+**7.1.3.1 Structure Usage: Basic Concepts**
809	809
810	810	The Structure Usage defines, in its concrete classes of Dataflow and Metadataflow, which flows of data and metadata use which specific Structure, and importantly for the support of data and metadata discovery, the Structure Usage can be linked to one or more Category in one or more Category Scheme using the Categorisation mechanism. This gives the ability for an application to discover data and metadata by “drilling down” the Category Schemes.
811	811
812		-==== 7.1.3.2 Structure Usage Schematic ====
	844	+**7.1.3.2 Structure Usage Schematic**
813	813
814	814	[[image:SDMX 3.1 Section 5_en_9b750e13.jpg||height="246" width="438"]]
815	815
816	816	**Figure 9: Schematic of Linking the Data and Metadata Flows to Categories and Structure Definitions**
817	817
818		-==== 7.1.3.3 Structure Usage Model ====
	850	+**7.1.3.3 Structure Usage Model**
819	819
820	820	[[image:SDMX 3.1 Section 5_en_1c94cbe.jpg||height="548" width="578"]]
821	821
...	...	@@ -823,19 +823,19 @@
823	823
824	824	In addition to the maintenance of the Dataflow and the Metadataflow, the following links must be maintained in the registry:
825	825
826		-1.
	858	+1.
827	827	1*. Dataflow to Data Structure Definition
828	828	1*. Metadataflow to Metadata Structure Definition
829	829
830	830	The following links may be created by means of a Categorisation
831	831
832		-1.
	864	+1.
833	833	1*. Categorisation to Dataflow and Category
834	834	1*. Categorisation to Metadataflow and Category
835	835
836		-== 7.2 Data and Metadata Provisioning ==
	868	+=== {{id name="_Toc90815"/}}7.2 Data and Metadata Provisioning ===
837	837
838		-=== 7.2.1 Provisioning Agreement: Basic concepts ===
	870	+===== {{id name="_Toc90816"/}}7.2.1 Provisioning Agreement: Basic concepts =====
839	839
840	840	Data/Metadata provisioning defines a framework in which the provision of different types of statistical data and metadata by various data/metadata providers can be specified and controlled. This framework is the basis on which the existence of data can be made known to the SDMX-enabled community and hence the basis on which data can subsequently be discovered. Such a framework can be used to regulate the data content to facilitate the building of intelligent applications. It can also be used to facilitate the processing implied by service level agreements, or other provisioning agreements in those scenarios that are based on legal directives. Additionally, quality and timeliness metadata can be supported by this framework which makes it practical to implement information supply chain monitoring.
841	841
...	...	@@ -843,7 +843,7 @@
843	843
844	844	Although the Provision Agreement directly supports the data-sharing “pull” model, it is also useful in “push” exchanges (bilateral and gateway scenarios), or in a dissemination environment. It should be noted, too, that in any exchange scenario, the registry functions as a repository of structural metadata.
845	845
846		-=== 7.2.2 Provisioning Agreement Model – pull use case ===
	878	+===== {{id name="_Toc90817"/}}7.2.2 Provisioning Agreement Model – pull use case =====
847	847
848	848	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.
849	849
...	...	@@ -865,9 +865,9 @@
865	865
866	866	A Provision Agreement is structural metadata. Each Provision Agreement must reference a Data Provider or Metadata Provider and a Dataflow or Metadataflow Definition. The Data/Metadata Provider and the Dataflow/Metadataflow must exist already in order to set up a Metadata Provision or Provision Agreement.
867	867
868		-== 7.3 Data and Metadata Constraints ==
	900	+=== {{id name="_Toc90818"/}}7.3 Data and Metadata Constraints ===
869	869
870		-=== 7.3.1 Data and Metadata Constraints: Basic Concepts ===
	902	+===== {{id name="_Toc90819"/}}7.3.1 Data and Metadata Constraints: Basic Concepts =====
871	871
872	872	Constraints are, effectively, lists of the valid or actual content of data and metadata. Constraints can be used to specify a subset of the theoretical content of data set or metadata set which can be derived from the specification of the DSD or MSD. A Constraint can comprise a list of keys or a list of content (usually code values) of a specific component such as a dimension or attribute.
873	873
...	...	@@ -881,13 +881,13 @@
881	881
882	882	In addition, DataAvailabilityConstraints can be extremely useful in a data visualisation system, such as dissemination of statistics on a website. In such a system a Cube Region can be used to specify the Dimension codes that actually exist in a data source (these can be used to build relevant selection tables).
883	883
884		-=== 7.3.2 Data and Metadata Constraints: Schematic ===
	916	+===== {{id name="_Toc90820"/}}7.3.2 Data and Metadata Constraints: Schematic =====
885	885
886	886	[[image:SDMX 3.1 Section 5_en_28d0cadc.jpg||height="326" width="580"]]
887	887
888	888	**Figure 14: Schematic of the Constraint and the Artefacts that can be constrained**
889	889
890		-=== 7.3.3 Data and Metadata Constraints: Model ===
	922	+===== {{id name="_Toc90821"/}}7.3.3 Data and Metadata Constraints: Model =====
891	891
892	892	[[image:SDMX 3.1 Section 5_en_a3184f6a.jpg||height="298" width="579"]]
893	893
...	...	@@ -903,9 +903,9 @@
903	903
904	904	The content of the Constraint can be found in the SDMX Information Model document.
905	905
906		-== 7.4 Data Registration ==
	938	+=== {{id name="_Toc90822"/}}7.4 Data Registration ===
907	907
908		-=== 7.4.1 Basic Concepts ===
	940	+===== {{id name="_Toc90823"/}}7.4.1 Basic Concepts =====
909	909
910	910	A Data Provider has published a new dataset conforming to an existing Dataflow (and hence Data Structure Definition). This is implemented as either a web-accessible SDMXML file, or in a database which has a web-services interface capable of responding to an SDMX RESTful query with an SDMX-ML data stream.
911	911
...	...	@@ -915,15 +915,15 @@
915	915
916	916	SDMX-RR supports dataset registration via the Registration Request, which can be created by the Data Provider (giving the Data Provider maximum control). The registry responds to the registration request with a registration response which indicates if the registration was successful. In the event of an error, the error messages are returned as a registry exception within the response.
917	917
918		-=== 7.4.2 The Registration Request ===
	950	+===== {{id name="_Toc90824"/}}7.4.2 The Registration Request =====
919	919
920		-==== 7.4.2.1 Registration Request Schematic ====
	952	+**7.4.2.1 Registration Request Schematic**
921	921
922	922	[[image:SDMX 3.1 Section 5_en_293a2ea6.jpg||height="337" width="554"]]
923	923
924	924	**Figure 16: Schematic of the Objects Concerned with Registration**
925	925
926		-==== 7.4.2.2 Registration Request Model ====
	958	+**7.4.2.2 Registration Request Model**
927	927
928	928	The following UML diagram shows the composition of the registration request. Each request is made up of one or more Registrations, one per dataset to be registered. The Registration can optionally have information, which has been extracted from the Registration:
929	929
...	...	@@ -935,11 +935,13 @@
935	935
936	936	The Registration has an action attribute which takes one of the following values:
937	937
	970	+:
	971	+
938	938	(((
939		-|(% style="width:224px" %)**Action Attribute Value**|(% style="width:1457px" %)**Behaviour**
940		-|(% style="width:224px" %)Append|(% style="width:1457px" %)Add this Registration to the registry
941		-|(% style="width:224px" %)Replace|(% style="width:1457px" %)Replace the existing Registration with identified by the id in the Registration of the SubmitRegistrationRequest
942		-|(% style="width:224px" %)Delete|(% style="width:1457px" %)Delete the existing Registration identified by the id in the Registration of the SubmitRegistrationRequest
	973	+|**Action Attribute Value**|**Behaviour**
	974	+|Append|Add this Registration to the registry
	975	+|Replace|Replace the existing Registration with identified by the id in the Registration of the SubmitRegistrationRequest
	976	+|Delete|Delete the existing Registration identified by the id in the Registration of the SubmitRegistrationRequest
943	943	)))
944	944
945	945	[[image:SDMX 3.1 Section 5_en_90b3c64a.jpg||height="434" width="579"]]
...	...	@@ -958,24 +958,30 @@
958	958
959	959	https:~/~/github.com/sdmx-twg/sdmx-rest/blob/master/doc/availability.md
960	960
	995	+:
	996	+
961	961	(((
962		-(% style="width:918.835px" %)
963		-|**Indexing Required**|(% style="width:745px" %)**Registration Process Activity**
964		-|indexTimeSeries|(% style="width:745px" %)Extract all the series keys and create a KeySet(s) Constraint.
965		-|indexDataSet|(% style="width:745px" %)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.
966		-|indexReportingPeriod|(% style="width:745px" %)(((
	998	+|**Indexing Required**|**Registration Process Activity**
	999	+|indexTimeSeries|Extract all the series keys and create a KeySet(s) Constraint.
	1000	+|indexDataSet|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.
	1001	+|indexReportingPeriod|(((
967	967	This applies only to a registered __dataset__.
	1003	+
968	968	Extract the Reporting Begin and Reporting End from the Header of the Message containing the data set, and create a Reference Period constraint.
969	969	)))
970		-|indexAttributes|(% style="width:745px" %)(((
	1006	+|indexAttributes|(((
971	971	**Data Set**
	1008	+
972	972	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
973	973
974	974	**Metadata Set**
975		-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
	1012	+
	1013	+Indicate the presence of a Reported Attribute by creating one or more Cube Regions containing Member Selections of Metadata Attribute
	1014	+
	1015	+Components of the Constraints model in the
976	976	)))
977		-|**Indexing Required**|(% style="width:745px" %)**Registration Process Activity**
978		-| |(% style="width:745px" %)SDMX-IM. Note that the content is not stored in the Selection Value.
	1017	+|**Indexing Required**|**Registration Process Activity**
	1018	+| |SDMX-IM. Note that the content is not stored in the Selection Value.
979	979	)))
980	980
981	981	Constraints that specify the contents of a //QueryDatasource// are submitted to the Registry via the structure submission service (i.e., the RESTful API).
...	...	@@ -982,7 +982,7 @@
982	982
983	983	The Registration must reference the ProvisionAgreement to which it relates.
984	984
985		-=== 7.4.3 Registration Response ===
	1025	+===== {{id name="_Toc90825"/}}7.4.3 Registration Response =====
986	986
987	987	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 SubmitRegistration class has a status field, which is either set to “Success”, “Warning” or “Failure”.
988	988
...	...	@@ -994,7 +994,7 @@
994	994
995	995	**Figure 18: Logical class diagram showing the registration response**
996	996
997		-== 7.5 Subscription and Notification Service ==
	1037	+=== {{id name="_Toc90826"/}}7.5 Subscription and Notification Service ===
998	998
999	999	The contents of the SDMX Registry/Repository will change regularly: new code lists and key families will be published and new datasets and metadata-sets will be registered. To obviate the need for users to repeatedly query the registry to see when new information is available, a mechanism is provided to allow users to be notified when these events happen.
1000	1000
...	...	@@ -1002,13 +1002,13 @@
1002	1002
1003	1003	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”.
1004	1004
1005		-=== 7.5.1 Subscription Logical Class Diagram ===
	1045	+===== {{id name="_Toc90827"/}}7.5.1 Subscription Logical Class Diagram =====
1006	1006
1007	1007	[[image:SDMX 3.1 Section 5_en_1433df5d.jpg||height="680" width="587"]]
1008	1008
1009	1009	**Figure 19: Logical Class Diagram of the Subscription**
1010	1010
1011		-=== 7.5.2 Subscription Information ===
	1051	+===== {{id name="_Toc90828"/}}7.5.2 Subscription Information =====
1012	1012
1013	1013	Regardless of the type of registry/repository events being observed, a subscription always contains:
1014	1014
...	...	@@ -1017,16 +1017,18 @@
1017	1017	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.
1018	1018	1. A selector which specifies which type of events are of interest. The set of event types is:
1019	1019
	1060	+:
	1061	+::
	1062	+
1020	1020	(((
1021		-(% style="width:1061.83px" %)
1022		-|**Event Type**|(% style="width:660px" %)**Comment**
1023		-|STRUCTURAL_REPOSITORY_EVENTS|(% style="width:660px" %)Life-cycle changes to Maintainable Artefacts in the structural metadata repository.
1024		-|DATA_REGISTRATION_EVENTS|(% style="width:660px" %)Whenever a published dataset is registered. This can be either a SDMXML data file or an SDMX conformant database.
1025		-|METADATA_REGISTRATION_EVENTS|(% style="width:660px" %)Whenever a published metadataset is registered. This can be either a SDMXML reference metadata file or an SDMX conformant database.
1026		-|ALL_EVENTS|(% style="width:660px" %)All events of the specified EventType
	1064	+|**Event Type**|**Comment**
	1065	+|STRUCTURAL_REPOSITORY_EVENTS|Life-cycle changes to Maintainable Artefacts in the structural metadata repository.
	1066	+|DATA_REGISTRATION_EVENTS|Whenever a published dataset is registered. This can be either a SDMXML data file or an SDMX conformant database.
	1067	+|METADATA_REGISTRATION_EVENTS|Whenever a published metadataset is registered. This can be either a SDMXML reference metadata file or an SDMX conformant database.
	1068	+|ALL_EVENTS|All events of the specified EventType
1027	1027	)))
1028	1028
1029		-=== 7.5.3 Wildcard Facility ===
	1071	+===== {{id name="_Toc90829"/}}7.5.3 Wildcard Facility =====
1030	1030
1031	1031	Subscription notification supports wildcarded identifier components URNs, which are identifiers which have some or all of their component parts replaced by the wildcard character `*`. Identifier components comprise:
1032	1032
...	...	@@ -1082,29 +1082,30 @@
1082	1082
1083	1083	The complete SDMX versioning syntax can be found in the SDMX Standards Section 6 “Technical Notes”, paragraph “4.3 Versioning”.
1084	1084
1085		-=== 7.5.4 Structural Repository Events ===
	1127	+===== {{id name="_Toc90830"/}}7.5.4 Structural Repository Events =====
1086	1086
1087	1087	Whenever a maintainable artefact (data structure definition, concept scheme, codelist, metadata structure definition, category scheme, etc.) is added to, deleted from, or modified in the structural metadata repository, a structural metadata event is triggered. Subscriptions may be set up to monitor all such events, or focus on specific artefacts such as a Data Structure Definition.
1088	1088
1089		-=== 7.5.5 Registration Events ===
	1131	+===== {{id name="_Toc90831"/}}7.5.5 Registration Events =====
1090	1090
1091	1091	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:
1092	1092
	1135	+:
	1136	+
1093	1093	(((
1094		-(% style="width:1082.83px" %)
1095		-|(% style="width:230px" %)**Selector**|(% style="width:850px" %)**Comment**
1096		-|(% style="width:230px" %)DataProvider|(% style="width:850px" %)Any datasets registered by the specified dataprovider will activate the notification.
1097		-|(% style="width:230px" %)ProvisionAgreement|(% style="width:850px" %)Any datasets for the agreement will activate the notification.
1098		-|(% style="width:230px" %)Dataflow|(% style="width:850px" %)Any datasets for the specified dataflow will activate the notification.
1099		-|(% style="width:230px" %)DataStructureDefinition|(% style="width:850px" %)Any datasets for those dataflows that are based on the specified Data Structure Definition will activate the notification
1100		-|(% style="width:230px" %)Category|(% style="width:850px" %)Any datasets registered for those dataflows, provision agreements that are categorised by the category.
	1138	+|**Selector**|**Comment**
	1139	+|DataProvider|Any datasets registered by the specified dataprovider will activate the notification.
	1140	+|ProvisionAgreement|Any datasets for the agreement will activate the notification.
	1141	+|Dataflow|Any datasets for the specified dataflow will activate the notification.
	1142	+|DataStructureDefinition|Any datasets for those dataflows that are based on the specified Data Structure Definition will activate the notification
	1143	+|Category|Any datasets registered for those dataflows, provision agreements that are categorised by the category.
1101	1101	)))
1102	1102
1103	1103	The event will also capture the semantic of the registration: deletion or replacement of an existing registration or a new registration.
1104	1104
1105		-== 7.6 Notification ==
	1148	+== {{id name="_Toc90832"/}}7.6 Notification ==
1106	1106
1107		-=== 7.6.1 Logical Class Diagram ===
	1150	+==== {{id name="_Toc90833"/}}7.6.1 Logical Class Diagram ====
1108	1108
1109	1109	[[image:SDMX 3.1 Section 5_en_8bc1b889.jpg||height="379" width="579"]]
1110	1110
...	...	@@ -1121,15 +1121,15 @@
1121	1121
1122	1122	Additionally, supplementary information may be contained in the notification as detailed below.
1123	1123
1124		-=== 7.6.2 Structural Event Component ===
	1167	+==== {{id name="_Toc90834"/}}7.6.2 Structural Event Component ====
1125	1125
1126	1126	The notification will contain the MaintainableArtefact that triggered the event in a form similar to the SDMX-ML structural message (using elements from that namespace).
1127	1127
1128		-=== 7.6.3 Registration Event Component ===
	1171	+==== {{id name="_Toc90835"/}}7.6.3 Registration Event Component ====
1129	1129
1130	1130	The notification will contain the Registration.
1131	1131
1132		-----
	1175	+[[1>>path:#sdfootnote1anc||name="sdfootnote1sym"]] With semantic versioning, it is allowed to reference a range of artefacts, e.g., a DSD referencing a Codelist with version 1.2.3+ means all patch versions greater than 1.2.3. This means that deleting 1.2.4draft does not break integrity of the aforementioned DSD.
1133	1133
1134	1134	[[2>>path:#sdfootnote2anc||name="sdfootnote2sym"]] 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. For example, a sub-agency of IMF is referred like this:
1135	1135
...	...	@@ -1136,5 +1136,3 @@
1136	1136	IMF.SubAgency1
1137	1137
1138	1138	[[3>>path:#sdfootnote3anc||name="sdfootnote3sym"]] Note that Codelist is also an EnumeratedList.
1139		-
1140		-{{putFootnotes/}}