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
...	...	@@ -411,7 +411,7 @@
411	411
412	412	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.
413	413
414		-==== 6.2.2.3 Explanation of the generic structure ====
	422	+**6.2.2.3 Explanation of the generic structure**
415	415
416	416	In the explanation below the actual object that is the target of the URN is called the **actual object**.
417	417
...	...	@@ -490,103 +490,103 @@
490	490
491	491	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.
492	492
493		-=== 6.2.3 Table of SDMX-IM Packages and Classes ===
	501	+===== {{id name="_Toc90808"/}}6.2.3 Table of SDMX-IM Packages and Classes =====
494	494
495	495	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.
496	496
497		-(% style="width:750.835px" %)
498		-|(% style="width:222px" %)**Package**|(% style="width:526px" %)**URN class name (model class name where this is different)**
499		-|(% style="width:222px" %)base|(% style="width:526px" %)Agency
500		-|(% style="width:222px" %) |(% style="width:526px" %)AgencyScheme
501		-|(% style="width:222px" %) |(% style="width:526px" %)DataConsumer
502		-|(% style="width:222px" %) |(% style="width:526px" %)DataConsumerScheme
503		-|(% style="width:222px" %) |(% style="width:526px" %)DataProvider
504		-|(% style="width:222px" %) |(% style="width:526px" %)DataProviderScheme
505		-|(% style="width:222px" %) |(% style="width:526px" %)MetadataProvider
506		-|(% style="width:222px" %) |(% style="width:526px" %)MetadataProviderScheme
507		-|(% style="width:222px" %) |(% style="width:526px" %)OrganisationUnit
508		-|(% style="width:222px" %) |(% style="width:526px" %)OrganisationUnitScheme
509		-|(% style="width:222px" %) |(% style="width:526px" %)
510		-|(% style="width:222px" %)datastructure|(% style="width:526px" %)AttributeDescriptor
511		-|(% style="width:222px" %) |(% style="width:526px" %)DataAttribute
512		-|(% style="width:222px" %) |(% style="width:526px" %)Dataflow
513		-|(% style="width:222px" %) |(% style="width:526px" %)DataStructure (DataStructureDefinition)
514		-|(% style="width:222px" %) |(% style="width:526px" %)Dimension
515		-|(% style="width:222px" %) |(% style="width:526px" %)DimensionDescriptor
516		-|(% style="width:222px" %) |(% style="width:526px" %)GroupDimensionDescriptor
517		-|(% style="width:222px" %) |(% style="width:526px" %)Measure
518		-|(% style="width:222px" %) |(% style="width:526px" %)MeasureDescriptor
519		-|(% style="width:222px" %) |(% style="width:526px" %)TimeDimension
520		-|(% style="width:222px" %) |(% style="width:526px" %)
521		-|(% style="width:222px" %)metadatastructure|(% style="width:526px" %)MetadataAttribute
522		-|(% style="width:222px" %) |(% style="width:526px" %)MetadataAttributeDescriptor
523		-|(% style="width:222px" %) |(% style="width:526px" %)(((
	505	+|**Package**|**URN class name (model class name where this is different)**
	506	+|base|Agency
	507	+| |AgencyScheme
	508	+| |DataConsumer
	509	+| |DataConsumerScheme
	510	+| |DataProvider
	511	+| |DataProviderScheme
	512	+| |MetadataProvider
	513	+| |MetadataProviderScheme
	514	+| |OrganisationUnit
	515	+| |OrganisationUnitScheme
	516	+| |
	517	+|datastructure|AttributeDescriptor
	518	+| |DataAttribute
	519	+| |Dataflow
	520	+| |DataStructure (DataStructureDefinition)
	521	+| |Dimension
	522	+| |DimensionDescriptor
	523	+| |GroupDimensionDescriptor
	524	+| |Measure
	525	+| |MeasureDescriptor
	526	+| |TimeDimension
	527	+| |
	528	+|metadatastructure|MetadataAttribute
	529	+| |MetadataAttributeDescriptor
	530	+| |(((
524	524	MetadataStructure
525	525
526	526	(MetadataStructureDefinition)
527	527	)))
528	528
	536	+:
	537	+
529	529	(((
530		-(% style="width:751.835px" %)
531		-|(% style="width:221px" %)**Package**|(% style="width:528px" %)**URN class name (model class name where this is different)**
532		-|(% style="width:221px" %) |(% style="width:528px" %)Metadataflow
533		-|(% style="width:221px" %) |(% style="width:528px" %)MetadataSet
534		-|(% style="width:221px" %) |(% style="width:528px" %)
535		-|(% style="width:221px" %)process|(% style="width:528px" %)Process
536		-|(% style="width:221px" %) |(% style="width:528px" %)ProcessStep
537		-|(% style="width:221px" %) |(% style="width:528px" %)Transition
538		-|(% style="width:221px" %) |(% style="width:528px" %)
539		-|(% style="width:221px" %)registry|(% style="width:528px" %)DataConstraint
540		-|(% style="width:221px" %) |(% style="width:528px" %)MetadataConstraint
541		-|(% style="width:221px" %) |(% style="width:528px" %)MetadataProvisionAgreement
542		-|(% style="width:221px" %) |(% style="width:528px" %)ProvisionAgreement
543		-|(% style="width:221px" %) |(% style="width:528px" %)Subscription
544		-|(% style="width:221px" %) |(% style="width:528px" %)
545		-|(% style="width:221px" %)structuremapping|(% style="width:528px" %)CategorySchemeMap
546		-|(% style="width:221px" %) |(% style="width:528px" %)ConceptSchemeMap
547		-|(% style="width:221px" %) |(% style="width:528px" %)OrganisationSchemeMap
548		-|(% style="width:221px" %) |(% style="width:528px" %)ReportingTaxonomyMap
549		-|(% style="width:221px" %) |(% style="width:528px" %)RepresentationMap
550		-|(% style="width:221px" %) |(% style="width:528px" %)StructureMap
551		-|(% style="width:221px" %) |(% style="width:528px" %)
552		-|(% style="width:221px" %)codelist|(% style="width:528px" %)Code
553		-|(% style="width:221px" %) |(% style="width:528px" %)Codelist
554		-|(% style="width:221px" %) |(% style="width:528px" %)HierarchicalCode
555		-|(% style="width:221px" %) |(% style="width:528px" %)Hierarchy
556		-|(% style="width:221px" %) |(% style="width:528px" %)HierarchyAssociation
557		-|(% style="width:221px" %) |(% style="width:528px" %)Level
558		-|(% style="width:221px" %) |(% style="width:528px" %)ValueList
559		-|(% style="width:221px" %) |(% style="width:528px" %)
560		-|(% style="width:221px" %)categoryscheme|(% style="width:528px" %)Categorisation
561		-|(% style="width:221px" %) |(% style="width:528px" %)Category
562		-|(% style="width:221px" %) |(% style="width:528px" %)CategoryScheme
563		-|(% style="width:221px" %) |(% style="width:528px" %)ReportingCategory
564		-|(% style="width:221px" %) |(% style="width:528px" %)ReportingTaxonomy
565		-|(% style="width:221px" %)**Package**|(% style="width:528px" %)**URN class name (model class name where this is different)**
566		-|(% style="width:221px" %) |(% style="width:528px" %)
567		-|(% style="width:221px" %)conceptscheme|(% style="width:528px" %)Concept
568		-|(% style="width:221px" %) |(% style="width:528px" %)ConceptScheme
569		-|(% style="width:221px" %) |(% style="width:528px" %)
570		-|(% style="width:221px" %)transformation|(% style="width:528px" %)CustomType
571		-|(% style="width:221px" %) |(% style="width:528px" %)CustomTypeScheme
572		-|(% style="width:221px" %) |(% style="width:528px" %)NamePersonalisation
573		-|(% style="width:221px" %) |(% style="width:528px" %)NamePersonalisationScheme
574		-|(% style="width:221px" %) |(% style="width:528px" %)Ruleset
575		-|(% style="width:221px" %) |(% style="width:528px" %)RulesetScheme
576		-|(% style="width:221px" %) |(% style="width:528px" %)Transformation
577		-|(% style="width:221px" %) |(% style="width:528px" %)TransformationScheme
578		-|(% style="width:221px" %) |(% style="width:528px" %)UserDefinedOperator
579		-|(% style="width:221px" %) |(% style="width:528px" %)UserDefinedOperatorScheme
580		-|(% style="width:221px" %) |(% style="width:528px" %)VtlCodelistMapping
581		-|(% style="width:221px" %) |(% style="width:528px" %)VtlConceptMapping
582		-|(% style="width:221px" %) |(% style="width:528px" %)VtlDataflowMapping
583		-|(% style="width:221px" %) |(% style="width:528px" %)VtlMappingScheme
584		-|(% style="width:221px" %) |(% style="width:528px" %)
	539	+|**Package**|**URN class name (model class name where this is different)**
	540	+| |Metadataflow
	541	+| |MetadataSet
	542	+| |
	543	+|process|Process
	544	+| |ProcessStep
	545	+| |Transition
	546	+| |
	547	+|registry|DataConstraint
	548	+| |MetadataConstraint
	549	+| |MetadataProvisionAgreement
	550	+| |ProvisionAgreement
	551	+| |Subscription
	552	+| |
	553	+|structuremapping|CategorySchemeMap
	554	+| |ConceptSchemeMap
	555	+| |OrganisationSchemeMap
	556	+| |ReportingTaxonomyMap
	557	+| |RepresentationMap
	558	+| |StructureMap
	559	+| |
	560	+|codelist|Code
	561	+| |Codelist
	562	+| |HierarchicalCode
	563	+| |Hierarchy
	564	+| |HierarchyAssociation
	565	+| |Level
	566	+| |ValueList
	567	+| |
	568	+|categoryscheme|Categorisation
	569	+| |Category
	570	+| |CategoryScheme
	571	+| |ReportingCategory
	572	+| |ReportingTaxonomy
	573	+|**Package**|**URN class name (model class name where this is different)**
	574	+| |
	575	+|conceptscheme|Concept
	576	+| |ConceptScheme
	577	+| |
	578	+|transformation|CustomType
	579	+| |CustomTypeScheme
	580	+| |NamePersonalisation
	581	+| |NamePersonalisationScheme
	582	+| |Ruleset
	583	+| |RulesetScheme
	584	+| |Transformation
	585	+| |TransformationScheme
	586	+| |UserDefinedOperator
	587	+| |UserDefinedOperatorScheme
	588	+| |VtlCodelistMapping
	589	+| |VtlConceptMapping
	590	+| |VtlDataflowMapping
	591	+| |VtlMappingScheme
	592	+| |
585	585	)))
586	586
587	587	**Table 2: SDMX-IM Packages and Contained Classes**
588	588
589		-=== 6.2.4 URN Identification components of SDMX objects ===
	597	+===== {{id name="_Toc90809"/}}6.2.4 URN Identification components of SDMX objects =====
590	590
591	591	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.
592	592
...	...	@@ -594,56 +594,67 @@
594	594
595	595	urn:sdmx.org.sdmx.infomodel.{package}.{classname}=
596	596
597		-(% style="width:1272.83px" %)
598		-|(% style="width:290px" %)**Classname**|(% style="width:649px" %)**Ending URN pattern**|(% style="width:332px" %)**Example**
599		-|(% 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
600		-|(% style="width:290px" %)//AgencyScheme//|(% style="width:649px" %)agencySchemeAgencyId:**AGENCIES**(**1.0**)|(% style="width:332px" %)ECB:**AGENCIES**(**1.0**)
601		-|(% style="width:290px" %)//Categorisation//|(% style="width:649px" %)categorisationAgencyId:categorisationId(version)|(% style="width:332px" %)IMF:cat001(1.0.0)
602		-|(% 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 …
603		-|(% style="width:290px" %)//CategoryScheme//|(% style="width:649px" %)categorySchemeAgencyId:categorySchemeId(versi on)|(% style="width:332px" %)IMF:SDDS(1.0.0)
	605	+|**Classname**|**Ending URN pattern**|**Example**
	606	+|Agency^^[[(% class="wikiinternallink wikiinternallink wikiinternallink" %)^^2^^>>path:#sdfootnote2sym||name="sdfootnote2anc"]](%%)^^|agencySchemeAgencyId:**AGENCIES**(**1.0**).agencyId|ECB:**AGENCIES**(**1.0**).AA
	607	+|//AgencyScheme//|agencySchemeAgencyId:**AGENCIES**(**1.0**)|ECB:**AGENCIES**(**1.0**)
	608	+|//Categorisation//|categorisationAgencyId:categorisationId(version)|IMF:cat001(1.0.0)
	609	+|Category|categorySchemeAgencyId:categorySchemeId(versi on).categoryId.categoryId.categoryId etc.|IMF:SDDS(1.0.0):level_1_category.level_2_category …
	610	+|//CategoryScheme//|categorySchemeAgencyId:categorySchemeId(versi on)|IMF:SDDS(1.0.0)
604	604
605		-|(% style="width:292px" %)**Classname**|(% style="width:647px" %)**Ending URN pattern**|(% style="width:742px" %)**Example**
606		-|(% style="width:292px" %)//CategorySchemeMap//|(% style="width:647px" %)(((
607		-catSchemeMapAgencyId:catSchemeMapId(version)
608		-)))|(% style="width:742px" %)SDMX:EUROSTAT_SUBJECT_DOMAIN(1.0.0)
609		-|(% style="width:292px" %)Code|(% style="width:647px" %)codeListAgencyId:codelistId(version).codeId|(% style="width:742px" %)SDMX:CL_FREQ(1.0.0).Q
610		-|(% style="width:292px" %)//Codelist//|(% style="width:647px" %)codeListAgencyId:codeListId(version)|(% style="width:742px" %)SDMX:CL_FREQ(1.0.0)
611		-|(% 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
612		-|(% style="width:292px" %)Concept|(% style="width:647px" %)conceptSchemeAgencyId:conceptSchemeId(versio n).conceptId|(% style="width:742px" %)SDMX:CROSS_DOMAIN_CONCEPTS(1.0.0).FREQ
613		-|(% style="width:292px" %)//ConceptScheme//|(% style="width:647px" %)conceptSchemeAgencyId:conceptSchemeId(versio n)|(% style="width:742px" %)SDMX:CROSS_DOMAIN_CONCEPTS(1.0.0)
614		-|(% style="width:292px" %)//ConceptSchemeMap//|(% style="width:647px" %)(((
615		-conceptSchemeMapAgencyId:conceptSchemeMap Id(version)
616		-)))|(% style="width:742px" %)SDMX:CONCEPT_MAP(1.0.0)
617		-|(% style="width:292px" %)CustomType|(% style="width:647px" %)customTypeSchemeAgencyId customTypeSchemeId(version) customTypeId|(% style="width:742px" %)ECB: CUSTOM_TYPE_SCHEME(1.0.0).CUSTOM_TYPE_1
618		-|(% style="width:292px" %)//CustomTypeScheme//|(% style="width:647px" %)customTypeSchemeAgencyId customTypeSchemeId(version)|(% style="width:742px" %)ECB:CUSTOM_TYPE_SCHEME(1.0.0)
619		-|(% style="width:292px" %)DataAttrribute|(% style="width:647px" %)dataStructureDefinitionAgencyId:dataStructureDef initionId(version).dataAttributeId|(% style="width:742px" %)TFFS:EXT_DEBT(1.0.0).OBS_STATUS
620		-|(% style="width:292px" %)//DataConstraint//|(% style="width:647px" %)dataConstraintAgencyId:dataConstraintId(version)|(% style="width:742px" %)TFFS:CREDITOR_DATA_CONTENT(1.0.0)
	612	+|**Classname**|**Ending URN pattern**|**Example**
	613	+|//CategorySchemeMap//|(((
	614	+catSchemeMapAgencyId:catSchemeMapId(version
621	621
622		-|(% style="width:294px" %)**Classname**|(% style="width:645px" %)**Ending URN pattern**|(% style="width:742px" %)**Example**
623		-|(% style="width:294px" %)DataConsumer|(% style="width:645px" %)dataConsumerSchemeAgencyId:**DATA_CONSUME RS**(**1.0**).dataConsumerId|(% style="width:742px" %)SDMX:**DATA_CONSUMERS**(**1.0**).CONSUMER_1
624		-|(% style="width:294px" %)//DataConsumerScheme//|(% style="width:645px" %)(((
625		-dataConsumerSchemeAgencyId:**DATA_CONSUME RS**(**1.0**)
626		-)))|(% style="width:742px" %)SDMX:**DATA_CONSUMERS**(**1.0**)
627		-|(% style="width:294px" %)//Dataflow//|(% style="width:645px" %)dataflowAgencyId:dataflowId(version)|(% style="width:742px" %)TFFS:CRED_EXT_DEBT(1.0.0)
628		-|(% style="width:294px" %)DataProvider|(% style="width:645px" %)(((
629		-dataProviderSchemeAgencyId:**DATA_PROVIDERS**(**1.0**).dataProviderId
630		-)))|(% style="width:742px" %)SDMX:**DATA_PROVIDERS**(**1.0**).PROVIDER_1
631		-|(% style="width:294px" %)//DataProviderScheme//|(% style="width:645px" %)(((
632		-dataProviderSchemeAgencyId:**DATA_PROVIDERS**(**1.0**)
633		-)))|(% style="width:742px" %)SDMX:**DATA_PROVIDERS**(**1.0**)
634		-|(% style="width:294px" %)//DataStructure//|(% style="width:645px" %)dataStructureDefinitionAgencyId:dataStructureDef initionId(version)|(% style="width:742px" %)TFFS:EXT_DEBT(1.0.0)
635		-|(% style="width:294px" %)Dimension|(% style="width:645px" %)dataStructureDefinitionAgencyId:dataStructureDef initionId(version).dimensionId|(% style="width:742px" %)TFFS:EXT_DEBT(1.0.0).FREQ
636		-|(% style="width:294px" %)(((
	616	+)
	617	+)))|SDMX:EUROSTAT_SUBJECT_DOMAIN(1.0.0)
	618	+|Code|codeListAgencyId:codelistId(version).codeId|SDMX:CL_FREQ(1.0.0).Q
	619	+|//Codelist//|codeListAgencyId:codeListId(version)|SDMX:CL_FREQ(1.0.0)
	620	+|ComponentMap|structureMapAgencyId:structureMap(version).com ponentMapId|SDMX:BOP_STRUCTURES(1.0.0).REF_AREA_TO_COUNT RY
	621	+|Concept|conceptSchemeAgencyId:conceptSchemeId(versio n).conceptId|SDMX:CROSS_DOMAIN_CONCEPTS(1.0.0).FREQ
	622	+|//ConceptScheme//|conceptSchemeAgencyId:conceptSchemeId(versio n)|SDMX:CROSS_DOMAIN_CONCEPTS(1.0.0)
	623	+|//ConceptSchemeMap//|(((
	624	+conceptSchemeMapAgencyId:conceptSchemeMap
	625	+
	626	+Id(version)
	627	+)))|SDMX:CONCEPT_MAP(1.0.0)
	628	+|CustomType|customTypeSchemeAgencyId customTypeSchemeId(version) customTypeId|ECB: CUSTOM_TYPE_SCHEME(1.0.0).CUSTOM_TYPE_1
	629	+|//CustomTypeScheme//|customTypeSchemeAgencyId customTypeSchemeId(version)|ECB:CUSTOM_TYPE_SCHEME(1.0.0)
	630	+|DataAttrribute|dataStructureDefinitionAgencyId:dataStructureDef initionId(version).dataAttributeId|TFFS:EXT_DEBT(1.0.0).OBS_STATUS
	631	+|//DataConstraint//|dataConstraintAgencyId:dataConstraintId(version)|TFFS:CREDITOR_DATA_CONTENT(1.0.0)
	632	+
	633	+|**Classname**|**Ending URN pattern**|**Example**
	634	+|DataConsumer|dataConsumerSchemeAgencyId:**DATA_CONSUME RS**(**1.0**).dataConsumerId|SDMX:**DATA_CONSUMERS**(**1.0**).CONSUMER_1
	635	+|//DataConsumerScheme//|(((
	636	+dataConsumerSchemeAgencyId:**DATA_CONSUME**
	637	+
	638	+**RS**(**1.0**)
	639	+)))|SDMX:**DATA_CONSUMERS**(**1.0**)
	640	+|//Dataflow//|dataflowAgencyId:dataflowId(version)|TFFS:CRED_EXT_DEBT(1.0.0)
	641	+|DataProvider|(((
	642	+dataProviderSchemeAgencyId:**DATA_PROVIDERS**(
	643	+
	644	+**1.0**).dataProviderId
	645	+)))|SDMX:**DATA_PROVIDERS**(**1.0**).PROVIDER_1
	646	+|//DataProviderScheme//|(((
	647	+dataProviderSchemeAgencyId:**DATA_PROVIDERS**(
	648	+
	649	+**1.0**)
	650	+)))|SDMX:**DATA_PROVIDERS**(**1.0**)
	651	+|//DataStructure//|dataStructureDefinitionAgencyId:dataStructureDef initionId(version)|TFFS:EXT_DEBT(1.0.0)
	652	+|Dimension|dataStructureDefinitionAgencyId:dataStructureDef initionId(version).dimensionId|TFFS:EXT_DEBT(1.0.0).FREQ
	653	+|(((
637	637	DimensionDescriptor
638	638
639	639	MeasureDescriptor
640	640
641	641	AttributeDescriptor
642		-)))|(% style="width:645px" %)(((
	659	+)))|(((
643	643	dataStructureDefinitionAgencyId:dataStructureDef initionId(version).componentListId
644	644
645		-where the componentListId is the name of the class (there is only one occurrence of each in the Data Structure Definition)
646		-)))|(% style="width:742px" %)(((
	662	+where the componentListId is the name of the class (there is only one occurrence of each in the
	663	+
	664	+Data Structure Definition)
	665	+)))|(((
647	647	TFFS:EXT_DEBT(1.0.0).DimensionDescriptor
648	648
649	649	TFFS:EXT_DEBT(1.0.0).MeasureDescriptor
...	...	@@ -650,81 +650,83 @@
650	650
651	651	TFFS:EXT_DEBT(1.0.0).AttributeDescriptor
652	652	)))
653		-|(% style="width:294px" %)GroupDimensionDescriptor|(% style="width:645px" %)dataStructureDefinitionAgencyId:dataStructureDef initionId(version).groupDimensionDescriptorId|(% style="width:742px" %)TFFS:EXT_DEBT(1.0.0).SIBLING
654		-|(% 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
	672	+|GroupDimensionDescriptor|dataStructureDefinitionAgencyId:dataStructureDef initionId(version).groupDimensionDescriptorId|TFFS:EXT_DEBT(1.0.0).SIBLING
	673	+|HierarchicalCode|hierarchyAgencyId:hierarchyId(version).hierarchica lCode.hierarchicalCode|UNESCO:H-C-GOV(1.0.0).GOV_CODE1.GOV_CODE1_1
655	655
656		-|**Classname**|(% style="width:644px" %)**Ending URN pattern**|(% style="width:743px" %)**Example**
657		-|//Hierarchy//|(% style="width:644px" %)hierarchyAgencyId:hierarchyId(version)|(% style="width:743px" %)UNESCO:H-C-GOV(1.0.0)
658		-|//HierarchyAssociation//|(% style="width:644px" %)hierarchyAssociationAgencyId:hierarchyAssociatio nId(version)|(% style="width:743px" %)UNESCO:CL_EXP_SOURCE(1.0.0)
659		-|Level|(% style="width:644px" %)hierarchyAgencyId:hierarchyId(version).level|(% style="width:743px" %)UNESCO:H-C-GOV(1.0.0).LVL1
660		-|Measure|(% style="width:644px" %)dataStructureDefinitionAgencyId:dataStructureDef initionId(version).measureId|(% style="width:743px" %)TFFS:EXT_DEBT(1.0.0).OBS_VALUE
661		-|MetadataAttribute|(% style="width:644px" %)(((
	675	+|**Classname**|**Ending URN pattern**|**Example**
	676	+|//Hierarchy//|hierarchyAgencyId:hierarchyId(version)|UNESCO:H-C-GOV(1.0.0)
	677	+|//HierarchyAssociation//|hierarchyAssociationAgencyId:hierarchyAssociatio nId(version)|UNESCO:CL_EXP_SOURCE(1.0.0)
	678	+|Level|hierarchyAgencyId:hierarchyId(version).level|UNESCO:H-C-GOV(1.0.0).LVL1
	679	+|Measure|dataStructureDefinitionAgencyId:dataStructureDef initionId(version).measureId|TFFS:EXT_DEBT(1.0.0).OBS_VALUE
	680	+|MetadataAttribute|(((
662	662	msdAgencyId:msdId(version).metadataAttributeId.
663	663
664	664	metadataAttributeId
665		-)))|(% style="width:743px" %)IMF:SDDS_MSD(1.0.0).COMPILATION.METHOD
666		-|MetadataAttributeDescriptor|(% style="width:644px" %)msdAgencyId:msdId(version).metadataAttributeDe scriptorId|(% style="width:743px" %)IMF:SDDS_MSD(1.0.0).MetadataAttributeDescriptor
667		-|//MetadataConstraint//|(% style="width:644px" %)metadataConstraintAgencyId:metadataConstraintI d(version)|(% style="width:743px" %)TFFS:CREDITOR_METADATA_CONTENT(1.0.0)
668		-|//Metadataflow//|(% style="width:644px" %)metadataflowAgencyId:metadataflowId(version)|(% style="width:743px" %)IMF:SDDS_MDF(1.0.0)
669		-|MetadataProvider|(% style="width:644px" %)metadataProviderSchemeAgencyId:**METADATA_P ROVIDERS**(**1.0**).metadataProviderId|(% style="width:743px" %)SDMX:**METADATA_PROVIDERS**(**1.0**).MD_PROVIDER_1
670		-|//MetadataProviderScheme//|(% style="width:644px" %)metadataProviderSchemeAgencyId:**METADATA_P ROVIDERS**(**1.0**)|(% style="width:743px" %)SDMX:**METADATA_PROVIDERS**(**1.0**)
671		-|//MetadataProvisionAgreement//|(% style="width:644px" %)metadataProvisionAgreementAgencyId:metadataP rovisionAgreementId(version)|(% style="width:743px" %)IMF:SDDS_MDF_AB(1.0.0)
672		-|//MetadataSet//|(% style="width:644px" %)metadataProviderId:metadataSetId(version)|(% style="width:743px" %)MD_PROVIDER:METADATASET(1.0.0)
673		-|//MetadataStructure//|(% style="width:644px" %)msdAgencyId:msdId(version)|(% style="width:743px" %)IMF:SDDS_MSD(1.0.0)
	684	+)))|IMF:SDDS_MSD(1.0.0).COMPILATION.METHOD
	685	+|MetadataAttributeDescriptor|msdAgencyId:msdId(version).metadataAttributeDe scriptorId|IMF:SDDS_MSD(1.0.0).MetadataAttributeDescriptor
	686	+|//MetadataConstraint//|metadataConstraintAgencyId:metadataConstraintI d(version)|TFFS:CREDITOR_METADATA_CONTENT(1.0.0)
	687	+|//Metadataflow//|metadataflowAgencyId:metadataflowId(version)|IMF:SDDS_MDF(1.0.0)
	688	+|MetadataProvider|metadataProviderSchemeAgencyId:**METADATA_P ROVIDERS**(**1.0**).metadataProviderId|SDMX:**METADATA_PROVIDERS**(**1.0**).MD_PROVIDER_1
	689	+|//MetadataProviderScheme//|metadataProviderSchemeAgencyId:**METADATA_P ROVIDERS**(**1.0**)|SDMX:**METADATA_PROVIDERS**(**1.0**)
	690	+|//MetadataProvisionAgreement//|metadataProvisionAgreementAgencyId:metadataP rovisionAgreementId(version)|IMF:SDDS_MDF_AB(1.0.0)
	691	+|//MetadataSet//|metadataProviderId:metadataSetId(version)|MD_PROVIDER:METADATASET(1.0.0)
	692	+|//MetadataStructure//|msdAgencyId:msdId(version)|IMF:SDDS_MSD(1.0.0)
674	674
675		-|(% style="width:296px" %)**Classname**|(% style="width:646px" %)**Ending URN pattern**|(% style="width:739px" %)**Example**
676		-|(% style="width:296px" %)NamePersonalisation|(% style="width:646px" %)namePersonalisationSchemeAgencyId namePersonalisationSchemeId(version) namePersonalisationId|(% style="width:739px" %)ECB:PSN_SCHEME(1.0.0).PSN1234
677		-|(% style="width:296px" %)//NamePersonalisationScheme//|(% style="width:646px" %)namePersonalisationSchemeAgencyId namePersonalisationSchemeId(version)|(% style="width:739px" %)ECB:PSN_SCHEME(1.0.0)
678		-|(% style="width:296px" %)//OrganisationSchemeMap//|(% style="width:646px" %)orgSchemeMapAgencyId:orgSchemeMapId(versio n)|(% style="width:739px" %)SDMX:AGENCIES_PROVIDERS(1.0.0)
679		-|(% style="width:296px" %)OrganisationUnit|(% style="width:646px" %)organisationUnitSchemeAgencyId:organisationUni tSchemeId(version).organisationUnitId|(% style="width:739px" %)ECB:ORGANISATIONS(1.0.0).1F
680		-|(% style="width:296px" %)//OrganisationUnitScheme//|(% style="width:646px" %)organisationUnitSchemeAgencyId:organisationUni tSchemeId(version)|(% style="width:739px" %)ECB:ORGANISATIONS(1.0.0)
681		-|(% style="width:296px" %)//Process//|(% style="width:646px" %)processAgencyId:processId{version)|(% style="width:739px" %)BIS:PROCESS1(1.0.0)
682		-|(% style="width:296px" %)ProcessStep|(% style="width:646px" %)(((
	694	+|**Classname**|**Ending URN pattern**|**Example**
	695	+|NamePersonalisation|namePersonalisationSchemeAgencyId namePersonalisationSchemeId(version) namePersonalisationId|ECB:PSN_SCHEME(1.0.0).PSN1234
	696	+|//NamePersonalisationScheme//|namePersonalisationSchemeAgencyId namePersonalisationSchemeId(version)|ECB:PSN_SCHEME(1.0.0)
	697	+|//OrganisationSchemeMap//|orgSchemeMapAgencyId:orgSchemeMapId(versio n)|SDMX:AGENCIES_PROVIDERS(1.0.0)
	698	+|OrganisationUnit|organisationUnitSchemeAgencyId:organisationUni tSchemeId(version).organisationUnitId|ECB:ORGANISATIONS(1.0.0).1F
	699	+|//OrganisationUnitScheme//|organisationUnitSchemeAgencyId:organisationUni tSchemeId(version)|ECB:ORGANISATIONS(1.0.0)
	700	+|//Process//|processAgencyId:processId{version)|BIS:PROCESS1(1.0.0)
	701	+|ProcessStep|(((
683	683	processAgencyId:processId(version).processStepId.
684	684
685	685	processStepId
686		-)))|(% style="width:739px" %)BIS:PROCESS1(1.0.0).STEP1.STEP1_1
687		-|(% style="width:296px" %)//ProvisionAgreement//|(% style="width:646px" %)provisionAgreementAgencyId:provisionAgreement Id(version)|(% style="width:739px" %)TFFS:CRED_EXT_DEBT_AB(1.0.0)
688		-|(% style="width:296px" %)ReportingCategory|(% style="width:646px" %)(((
	705	+)))|BIS:PROCESS1(1.0.0).STEP1.STEP1_1
	706	+|//ProvisionAgreement//|provisionAgreementAgencyId:provisionAgreement Id(version)|TFFS:CRED_EXT_DEBT_AB(1.0.0)
	707	+|ReportingCategory|(((
689	689	reportingTaxonomyAgencyId:
690	690
691	691	reportingTaxonomyId(version).reportingCategoryI d.reportingCategoryId
692		-)))|(% style="width:739px" %)IMF:REP_1(1.0.0):LVL1_REP_CAT.LVL2_REP_CAT
693		-|(% style="width:296px" %)//ReportingTaxonomy//|(% style="width:646px" %)reportingTaxonomyAgencyId:reportingTaxonomyI d(version)|(% style="width:739px" %)IMF:REP_1(1.0.0)
694		-|(% style="width:296px" %)//ReportingTaxonomyMap//|(% style="width:646px" %)repTaxonomyAgencyId:repTaxonomyId(version)|(% style="width:739px" %)SDMX:RT_MAP(1.0.0)
	711	+)))|IMF:REP_1(1.0.0):LVL1_REP_CAT.LVL2_REP_CAT
	712	+|//ReportingTaxonomy//|reportingTaxonomyAgencyId:reportingTaxonomyI d(version)|IMF:REP_1(1.0.0)
	713	+|//ReportingTaxonomyMap//|repTaxonomyAgencyId:repTaxonomyId(version)|SDMX:RT_MAP(1.0.0)
695	695
696		-|(% style="width:297px" %)**Classname**|(% style="width:647px" %)**Ending URN pattern**|(% style="width:737px" %)**Example**
697		-|(% style="width:297px" %)//RepresentationMap//|(% style="width:647px" %)repMapAgencyId:repMapId(version)|(% style="width:737px" %)SDMX:REF_AREA_MAPPING(1.0.0)
698		-|(% style="width:297px" %)Ruleset|(% style="width:647px" %)rulesetSchemeAgencyId rulesetSchemeId(version) rulesetId|(% style="width:737px" %)ECB:RULESET_23(1.0.0).SET111
699		-|(% style="width:297px" %)//RulesetScheme//|(% style="width:647px" %)rulesetSchemeAgencyId rulesetSchemeId(version)|(% style="width:737px" %)ECB:RULESET_23(1.0.0)
700		-|(% style="width:297px" %)//StructureMap//|(% style="width:647px" %)structureMapAgencyId:structureMap(version)|(% style="width:737px" %)SDMX:BOP_STRUCTURES(1.0.0)
701		-|(% style="width:297px" %)Subscription|(% style="width:647px" %)(((
	715	+|**Classname**|**Ending URN pattern**|**Example**
	716	+|//RepresentationMap//|repMapAgencyId:repMapId(version)|SDMX:REF_AREA_MAPPING(1.0.0)
	717	+|Ruleset|rulesetSchemeAgencyId rulesetSchemeId(version) rulesetId|ECB:RULESET_23(1.0.0).SET111
	718	+|//RulesetScheme//|rulesetSchemeAgencyId rulesetSchemeId(version)|ECB:RULESET_23(1.0.0)
	719	+|//StructureMap//|structureMapAgencyId:structureMap(version)|SDMX:BOP_STRUCTURES(1.0.0)
	720	+|Subscription|(((
702	702	The Subscription is not itself an Identifiable Artefact and therefore it does not follow the rules for URN structure.
	722	+
703	703	The name of the URN is registryURN There is no pre-determined format.
704		-)))|(% 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.
705		-|(% style="width:297px" %)TimeDimension|(% style="width:647px" %)dataStructureDefinitionAgencyId:dataStructureDef initionId(version).timeDimensionId|(% style="width:737px" %)TFFS:EXT_DEBT(1.0.0).TIME_PERIOD
706		-|(% style="width:297px" %)Transformation|(% style="width:647px" %)transformationSchemeAgencyId transformationSchemeId(version) transformationId|(% style="width:737px" %)ECB:TRANSFORMATION_SCHEME(1.0.0).TRANS_1
707		-|(% style="width:297px" %)//TransformationScheme//|(% style="width:647px" %)transformationSchemeAgencyId transformationSchemeId(version)|(% style="width:737px" %)ECB: TRANSFORMATION_SCHEME(1.0.0)
708		-|(% style="width:297px" %)**Classname**|(% style="width:647px" %)**Ending URN pattern**|(% style="width:737px" %)**Example**
709		-|(% style="width:297px" %)Transition|(% style="width:647px" %)(((
	724	+)))|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.
	725	+|TimeDimension|dataStructureDefinitionAgencyId:dataStructureDef initionId(version).timeDimensionId|TFFS:EXT_DEBT(1.0.0).TIME_PERIOD
	726	+|Transformation|transformationSchemeAgencyId transformationSchemeId(version) transformationId|ECB:TRANSFORMATION_SCHEME(1.0.0).TRANS_1
	727	+|//TransformationScheme//|transformationSchemeAgencyId transformationSchemeId(version)|ECB: TRANSFORMATION_SCHEME(1.0.0)
	728	+|**Classname**|**Ending URN pattern**|**Example**
	729	+|Transition|(((
710	710	processAgencyId:processId(version).processStepId.
	731	+
711	711	transitionId
712		-)))|(% style="width:737px" %)BIS:PROCESS1(1.0.0).STEP1.TRANSITION1
713		-|(% style="width:297px" %)UserDefinedOperator|(% style="width:647px" %)userDefinedOperatorSchemeAgencyId userDefinedOperatorSchemeId(version) usserDefinedOperatorId|(% style="width:737px" %)ECB:OS_CALC(1.2.0).OS267
714		-|(% style="width:297px" %)//UserDefinedOperatorScheme//|(% style="width:647px" %)userDefinedOperatorSchemeAgencyId userDefinedOperatorSchemeId(version)|(% style="width:737px" %)ECB:OS_CALC(1.2.0)
715		-|(% style="width:297px" %)//ValueList//|(% style="width:647px" %)valuelistAgencyId:valuelistId(version)|(% style="width:737px" %)SDMX:VLIST(1.0.0)
716		-|(% style="width:297px" %)VtlCodelistMapping|(% style="width:647px" %)vtlMappingSchemeAgencyId vtlMappingSchemeId(version) vtlCodelistMappingId|(% style="width:737px" %)ECB:CLIST_MP(2.0.0).ABZ
717		-|(% style="width:297px" %)VtlConceptMapping|(% style="width:647px" %)vtlMappingSchemeAgencyId vtlMappingSchemeId(version) vtlConceptMappingId|(% style="width:737px" %)ECB:CLIST_MP(1.0.0).XYA
718		-|(% style="width:297px" %)VtlDataflowMapping|(% style="width:647px" %)vtlMappingSchemeAgencyId vtlMappingSchemeId(version) vtlDataflowMappingId|(% style="width:737px" %)ECB:CLIST_MP(1.0.0).MOQ
719		-|(% style="width:297px" %)//VtlMappingScheme//|(% style="width:647px" %)vtlMappingSchemeAgencyId VtlMappingSchemeId(version)|(% style="width:737px" %)ECB:CLIST_MP(2.0.0)
	733	+)))|BIS:PROCESS1(1.0.0).STEP1.TRANSITION1
	734	+|UserDefinedOperator|userDefinedOperatorSchemeAgencyId userDefinedOperatorSchemeId(version) usserDefinedOperatorId|ECB:OS_CALC(1.2.0).OS267
	735	+|//UserDefinedOperatorScheme//|userDefinedOperatorSchemeAgencyId userDefinedOperatorSchemeId(version)|ECB:OS_CALC(1.2.0)
	736	+|//ValueList//|valuelistAgencyId:valuelistId(version)|SDMX:VLIST(1.0.0)
	737	+|VtlCodelistMapping|vtlMappingSchemeAgencyId vtlMappingSchemeId(version) vtlCodelistMappingId|ECB:CLIST_MP(2.0.0).ABZ
	738	+|VtlConceptMapping|vtlMappingSchemeAgencyId vtlMappingSchemeId(version) vtlConceptMappingId|ECB:CLIST_MP(1.0.0).XYA
	739	+|VtlDataflowMapping|vtlMappingSchemeAgencyId vtlMappingSchemeId(version) vtlDataflowMappingId|ECB:CLIST_MP(1.0.0).MOQ
	740	+|//VtlMappingScheme//|vtlMappingSchemeAgencyId VtlMappingSchemeId(version)|ECB:CLIST_MP(2.0.0)
720	720
721	721	5**Table 3: Table of identification components for SDMX Identifiable Artefacts**
722	722
723		-= 7 Implementation Notes =
	744	+= {{id name="_Toc90810"/}}7 Implementation Notes =
724	724
725		-== 7.1 Structural Definition Metadata ==
	746	+=== {{id name="_Toc90811"/}}7.1 Structural Definition Metadata ===
726	726
727		-=== 7.1.1 Introduction ===
	748	+===== {{id name="_Toc90812"/}}7.1.1 Introduction =====
728	728
729	729	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.)
730	730
...	...	@@ -740,40 +740,46 @@
740	740
741	741	The following table lists the Maintainable Artefacts.
742	742
743		-(% style="width:825.835px" %)
744		-|(% colspan="2" style="width:455px" %)**Maintainable Artefacts**|(% style="width:367px" %)**Content**
745		-|(% style="width:160px" %)**Abstract Class**|(% style="width:295px" %)**Concrete Class**|(% style="width:367px" %)
746		-|(% style="width:160px" %)Item Scheme|(% style="width:295px" %)Codelist|(% style="width:367px" %)Code
747		-|(% style="width:160px" %) |(% style="width:295px" %)Concept Scheme|(% style="width:367px" %)Concept
748		-|(% style="width:160px" %) |(% style="width:295px" %)Category Scheme|(% style="width:367px" %)Category
749		-|(% style="width:160px" %) |(% style="width:295px" %)Organisation Unit Scheme|(% style="width:367px" %)Organisation Unit
750		-|(% style="width:160px" %) |(% style="width:295px" %)Agency Scheme|(% style="width:367px" %)Agency
751		-|(% style="width:160px" %) |(% style="width:295px" %)Data Provider Scheme|(% style="width:367px" %)Data Provider
752		-|(% style="width:160px" %) |(% style="width:295px" %)Metadata Provider Scheme|(% style="width:367px" %)Metadata Provider
753		-|(% style="width:160px" %) |(% style="width:295px" %)Data Consumer Scheme|(% style="width:367px" %)Data Consumer
754		-|(% style="width:160px" %) |(% style="width:295px" %)Reporting Taxonomy|(% style="width:367px" %)Reporting Category
755		-|(% style="width:160px" %) |(% style="width:295px" %)Transformation Scheme|(% style="width:367px" %)Transformation
756		-|(% style="width:160px" %) |(% style="width:295px" %)Custom Type Scheme|(% style="width:367px" %)Custom Type
757		-|(% style="width:160px" %) |(% style="width:295px" %)Name Personalisation Scheme|(% style="width:367px" %)Name Personalisation
758		-|(% style="width:160px" %) |(% style="width:295px" %)Vtl Mapping Scheme|(% style="width:367px" %)Vtl Codelist Mapping Vtl Concept Mapping
759		-|(% style="width:160px" %) |(% style="width:295px" %)Ruleset Scheme|(% style="width:367px" %)Ruleset
760		-|(% style="width:160px" %) |(% style="width:295px" %)User Defined Operator Scheme|(% style="width:367px" %)User Defined Operator
761		-|(% style="width:160px" %)Enumerated List|(% style="width:295px" %)ValueList|(% style="width:367px" %)Value Item
762		-|(% style="width:160px" %)Structure|(% style="width:295px" %)Data Structure Definition|(% style="width:367px" %)(((
	764	+|(% colspan="2" %)**Maintainable Artefacts**|**Content**
	765	+|**Abstract Class**|**Concrete Class**|
	766	+|Item Scheme|Codelist|Code
	767	+| |Concept Scheme|Concept
	768	+| |Category Scheme|Category
	769	+| |Organisation Unit Scheme|Organisation Unit
	770	+| |Agency Scheme|Agency
	771	+| |Data Provider Scheme|Data Provider
	772	+| |Metadata Provider Scheme|Metadata Provider
	773	+| |Data Consumer Scheme|Data Consumer
	774	+| |Reporting Taxonomy|Reporting Category
	775	+| |Transformation Scheme|Transformation
	776	+| |Custom Type Scheme|Custom Type
	777	+| |Name Personalisation Scheme|Name Personalisation
	778	+| |Vtl Mapping Scheme|Vtl Codelist Mapping Vtl Concept Mapping
	779	+| |Ruleset Scheme|Ruleset
	780	+| |User Defined Operator Scheme|User Defined Operator
	781	+|Enumerated List|ValueList|Value Item
	782	+|Structure|Data Structure Definition|(((
763	763	Dimension Descriptor
	784	+
764	764	Group Dimension Descriptor
	786	+
765	765	Dimension
	788	+
766	766	Time Dimension
	790	+
767	767	Attribute Descriptor
	792	+
768	768	Data Attribute
	794	+
769	769	Measure Descriptor
	796	+
770	770	Measure
771	771	)))
772		-|(% style="width:160px" %) |(% style="width:295px" %)Metadata Structure Definition|(% style="width:367px" %)Metadata Attribute Descriptor Metadata Attribute
773		-|(% style="width:160px" %)Structure Usage|(% style="width:295px" %)Dataflow|(% style="width:367px" %)
774		-|(% style="width:160px" %) |(% style="width:295px" %)Metadataflow|(% style="width:367px" %)
775		-|(% style="width:160px" %)None|(% style="width:295px" %)Process|(% style="width:367px" %)Process Step
776		-|(% style="width:160px" %)None|(% style="width:295px" %)Structure Map|(% style="width:367px" %)(((
	799	+| |Metadata Structure Definition|Metadata Attribute Descriptor Metadata Attribute
	800	+|Structure Usage|Dataflow|
	801	+| |Metadataflow|
	802	+|None|Process|Process Step
	803	+|None|Structure Map|(((
777	777	Component Map
778	778
779	779	Epoch Map
...	...	@@ -780,44 +780,44 @@
780	780
781	781	Date Pattern Map
782	782	)))
783		-|(% style="width:160px" %)None|(% style="width:295px" %)Representation Map|(% style="width:367px" %)Representation Mapping
784		-|(% style="width:160px" %)Item Scheme Map|(% style="width:295px" %)Organisation Scheme Map|(% style="width:367px" %)Item Map
785		-|(% style="width:160px" %) |(% style="width:295px" %)Concept Scheme Map|(% style="width:367px" %)Item Map
786		-|(% style="width:160px" %) |(% style="width:295px" %)Category Scheme Map|(% style="width:367px" %)Item Map
787		-|(% style="width:160px" %) |(% style="width:295px" %)Reporting Taxonomy Map|(% style="width:367px" %)Item Map
788		-|(% style="width:160px" %)None|(% style="width:295px" %)Provision Agreement|(% style="width:367px" %)
789		-|(% style="width:160px" %)None|(% style="width:295px" %)Metadata Provision Agreement|(% style="width:367px" %)
790		-|(% style="width:160px" %)None|(% style="width:295px" %)Hierarchy|(% style="width:367px" %)Hierarchical Code
791		-|(% style="width:160px" %)None|(% style="width:295px" %)Hierarchy Association|(% style="width:367px" %)
792		-|(% style="width:160px" %)None|(% style="width:295px" %)Categorisation|(% style="width:367px" %)
793		-|(% style="width:160px" %)Constraint|(% style="width:295px" %)Data Constraint|(% style="width:367px" %)DataKeySet
794		-|(% style="width:160px" %) |(% style="width:295px" %) |(% style="width:367px" %)CubeRegion
795		-|(% style="width:160px" %)Constraint|(% style="width:295px" %)Metadata Constraint|(% style="width:367px" %)MetadataTargetRegion
	810	+|None|Representation Map|Representation Mapping
	811	+|Item Scheme Map|Organisation Scheme Map|Item Map
	812	+| |Concept Scheme Map|Item Map
	813	+| |Category Scheme Map|Item Map
	814	+| |Reporting Taxonomy Map|Item Map
	815	+|None|Provision Agreement|
	816	+|None|Metadata Provision Agreement|
	817	+|None|Hierarchy|Hierarchical Code
	818	+|None|Hierarchy Association|
	819	+|None|Categorisation|
	820	+|Constraint|Data Constraint|DataKeySet
	821	+| | |CubeRegion
	822	+|Constraint|Metadata Constraint|MetadataTargetRegion
796	796
797	797	**Table 4: Table of Maintainable Artefacts for Structural Definition Metadata**
798	798
799		-=== 7.1.2 Item Scheme, Structure ===
	826	+===== {{id name="_Toc90813"/}}7.1.2 Item Scheme, Structure =====
800	800
801	801	The artefacts included in the structural definitions are:
802	802
803	803	* 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)
804		-* All types of Enumerated List (ValueList)^^[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^3^^>>path:#sdfootnote3sym||name="sdfootnote3anc"]](%%)^^
	831	+* All types of Enumerated List (ValueList)^^[[(% class="wikiinternallink wikiinternallink wikiinternallink" %)^^3^^>>path:#sdfootnote3sym||name="sdfootnote3anc"]](%%)^^
805	805	* All types of Structure (Data Structure Definition, Metadata Structure Definition)
806	806	* All types of Structure Usage (Dataflow, Metadataflow)
807	807
808		-=== 7.1.3 Structure Usage ===
	835	+===== {{id name="_Toc90814"/}}7.1.3 Structure Usage =====
809	809
810		-==== 7.1.3.1 Structure Usage: Basic Concepts ====
	837	+**7.1.3.1 Structure Usage: Basic Concepts**
811	811
812	812	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.
813	813
814		-==== 7.1.3.2 Structure Usage Schematic ====
	841	+**7.1.3.2 Structure Usage Schematic**
815	815
816	816	[[image:SDMX 3.1 Section 5_en_9b750e13.jpg||height="246" width="438"]]
817	817
818	818	**Figure 9: Schematic of Linking the Data and Metadata Flows to Categories and Structure Definitions**
819	819
820		-==== 7.1.3.3 Structure Usage Model ====
	847	+**7.1.3.3 Structure Usage Model**
821	821
822	822	[[image:SDMX 3.1 Section 5_en_1c94cbe.jpg||height="548" width="578"]]
823	823
...	...	@@ -825,19 +825,19 @@
825	825
826	826	In addition to the maintenance of the Dataflow and the Metadataflow, the following links must be maintained in the registry:
827	827
828		-1.
	855	+1.
829	829	1*. Dataflow to Data Structure Definition
830	830	1*. Metadataflow to Metadata Structure Definition
831	831
832	832	The following links may be created by means of a Categorisation
833	833
834		-1.
	861	+1.
835	835	1*. Categorisation to Dataflow and Category
836	836	1*. Categorisation to Metadataflow and Category
837	837
838		-== 7.2 Data and Metadata Provisioning ==
	865	+=== {{id name="_Toc90815"/}}7.2 Data and Metadata Provisioning ===
839	839
840		-=== 7.2.1 Provisioning Agreement: Basic concepts ===
	867	+===== {{id name="_Toc90816"/}}7.2.1 Provisioning Agreement: Basic concepts =====
841	841
842	842	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.
843	843
...	...	@@ -845,7 +845,7 @@
845	845
846	846	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.
847	847
848		-=== 7.2.2 Provisioning Agreement Model – pull use case ===
	875	+===== {{id name="_Toc90817"/}}7.2.2 Provisioning Agreement Model – pull use case =====
849	849
850	850	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.
851	851
...	...	@@ -867,9 +867,9 @@
867	867
868	868	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.
869	869
870		-== 7.3 Data and Metadata Constraints ==
	897	+=== {{id name="_Toc90818"/}}7.3 Data and Metadata Constraints ===
871	871
872		-=== 7.3.1 Data and Metadata Constraints: Basic Concepts ===
	899	+===== {{id name="_Toc90819"/}}7.3.1 Data and Metadata Constraints: Basic Concepts =====
873	873
874	874	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.
875	875
...	...	@@ -883,13 +883,13 @@
883	883
884	884	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).
885	885
886		-=== 7.3.2 Data and Metadata Constraints: Schematic ===
	913	+===== {{id name="_Toc90820"/}}7.3.2 Data and Metadata Constraints: Schematic =====
887	887
888	888	[[image:SDMX 3.1 Section 5_en_28d0cadc.jpg||height="326" width="580"]]
889	889
890	890	**Figure 14: Schematic of the Constraint and the Artefacts that can be constrained**
891	891
892		-=== 7.3.3 Data and Metadata Constraints: Model ===
	919	+===== {{id name="_Toc90821"/}}7.3.3 Data and Metadata Constraints: Model =====
893	893
894	894	[[image:SDMX 3.1 Section 5_en_a3184f6a.jpg||height="298" width="579"]]
895	895
...	...	@@ -905,9 +905,9 @@
905	905
906	906	The content of the Constraint can be found in the SDMX Information Model document.
907	907
908		-== 7.4 Data Registration ==
	935	+=== {{id name="_Toc90822"/}}7.4 Data Registration ===
909	909
910		-=== 7.4.1 Basic Concepts ===
	937	+===== {{id name="_Toc90823"/}}7.4.1 Basic Concepts =====
911	911
912	912	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.
913	913
...	...	@@ -917,15 +917,15 @@
917	917
918	918	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.
919	919
920		-=== 7.4.2 The Registration Request ===
	947	+===== {{id name="_Toc90824"/}}7.4.2 The Registration Request =====
921	921
922		-==== 7.4.2.1 Registration Request Schematic ====
	949	+**7.4.2.1 Registration Request Schematic**
923	923
924	924	[[image:SDMX 3.1 Section 5_en_293a2ea6.jpg||height="337" width="554"]]
925	925
926	926	**Figure 16: Schematic of the Objects Concerned with Registration**
927	927
928		-==== 7.4.2.2 Registration Request Model ====
	955	+**7.4.2.2 Registration Request Model**
929	929
930	930	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:
931	931
...	...	@@ -937,11 +937,13 @@
937	937
938	938	The Registration has an action attribute which takes one of the following values:
939	939
	967	+:
	968	+
940	940	(((
941		-|(% style="width:224px" %)**Action Attribute Value**|(% style="width:1457px" %)**Behaviour**
942		-|(% style="width:224px" %)Append|(% style="width:1457px" %)Add this Registration to the registry
943		-|(% style="width:224px" %)Replace|(% style="width:1457px" %)Replace the existing Registration with identified by the id in the Registration of the SubmitRegistrationRequest
944		-|(% style="width:224px" %)Delete|(% style="width:1457px" %)Delete the existing Registration identified by the id in the Registration of the SubmitRegistrationRequest
	970	+|**Action Attribute Value**|**Behaviour**
	971	+|Append|Add this Registration to the registry
	972	+|Replace|Replace the existing Registration with identified by the id in the Registration of the SubmitRegistrationRequest
	973	+|Delete|Delete the existing Registration identified by the id in the Registration of the SubmitRegistrationRequest
945	945	)))
946	946
947	947	[[image:SDMX 3.1 Section 5_en_90b3c64a.jpg||height="434" width="579"]]
...	...	@@ -960,24 +960,30 @@
960	960
961	961	https:~/~/github.com/sdmx-twg/sdmx-rest/blob/master/doc/availability.md
962	962
	992	+:
	993	+
963	963	(((
964		-(% style="width:918.835px" %)
965		-|**Indexing Required**|(% style="width:745px" %)**Registration Process Activity**
966		-|indexTimeSeries|(% style="width:745px" %)Extract all the series keys and create a KeySet(s) Constraint.
967		-|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.
968		-|indexReportingPeriod|(% style="width:745px" %)(((
	995	+|**Indexing Required**|**Registration Process Activity**
	996	+|indexTimeSeries|Extract all the series keys and create a KeySet(s) Constraint.
	997	+|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.
	998	+|indexReportingPeriod|(((
969	969	This applies only to a registered __dataset__.
	1000	+
970	970	Extract the Reporting Begin and Reporting End from the Header of the Message containing the data set, and create a Reference Period constraint.
971	971	)))
972		-|indexAttributes|(% style="width:745px" %)(((
	1003	+|indexAttributes|(((
973	973	**Data Set**
	1005	+
974	974	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
975	975
976	976	**Metadata Set**
977		-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
	1009	+
	1010	+Indicate the presence of a Reported Attribute by creating one or more Cube Regions containing Member Selections of Metadata Attribute
	1011	+
	1012	+Components of the Constraints model in the
978	978	)))
979		-|**Indexing Required**|(% style="width:745px" %)**Registration Process Activity**
980		-| |(% style="width:745px" %)SDMX-IM. Note that the content is not stored in the Selection Value.
	1014	+|**Indexing Required**|**Registration Process Activity**
	1015	+| |SDMX-IM. Note that the content is not stored in the Selection Value.
981	981	)))
982	982
983	983	Constraints that specify the contents of a //QueryDatasource// are submitted to the Registry via the structure submission service (i.e., the RESTful API).
...	...	@@ -984,7 +984,7 @@
984	984
985	985	The Registration must reference the ProvisionAgreement to which it relates.
986	986
987		-=== 7.4.3 Registration Response ===
	1022	+===== {{id name="_Toc90825"/}}7.4.3 Registration Response =====
988	988
989	989	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”.
990	990
...	...	@@ -996,7 +996,7 @@
996	996
997	997	**Figure 18: Logical class diagram showing the registration response**
998	998
999		-== 7.5 Subscription and Notification Service ==
	1034	+=== {{id name="_Toc90826"/}}7.5 Subscription and Notification Service ===
1000	1000
1001	1001	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.
1002	1002
...	...	@@ -1004,13 +1004,13 @@
1004	1004
1005	1005	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”.
1006	1006
1007		-=== 7.5.1 Subscription Logical Class Diagram ===
	1042	+===== {{id name="_Toc90827"/}}7.5.1 Subscription Logical Class Diagram =====
1008	1008
1009	1009	[[image:SDMX 3.1 Section 5_en_1433df5d.jpg||height="680" width="587"]]
1010	1010
1011	1011	**Figure 19: Logical Class Diagram of the Subscription**
1012	1012
1013		-=== 7.5.2 Subscription Information ===
	1048	+===== {{id name="_Toc90828"/}}7.5.2 Subscription Information =====
1014	1014
1015	1015	Regardless of the type of registry/repository events being observed, a subscription always contains:
1016	1016
...	...	@@ -1019,16 +1019,18 @@
1019	1019	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.
1020	1020	1. A selector which specifies which type of events are of interest. The set of event types is:
1021	1021
	1057	+:
	1058	+::
	1059	+
1022	1022	(((
1023		-(% style="width:1061.83px" %)
1024		-|**Event Type**|(% style="width:660px" %)**Comment**
1025		-|STRUCTURAL_REPOSITORY_EVENTS|(% style="width:660px" %)Life-cycle changes to Maintainable Artefacts in the structural metadata repository.
1026		-|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.
1027		-|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.
1028		-|ALL_EVENTS|(% style="width:660px" %)All events of the specified EventType
	1061	+|**Event Type**|**Comment**
	1062	+|STRUCTURAL_REPOSITORY_EVENTS|Life-cycle changes to Maintainable Artefacts in the structural metadata repository.
	1063	+|DATA_REGISTRATION_EVENTS|Whenever a published dataset is registered. This can be either a SDMXML data file or an SDMX conformant database.
	1064	+|METADATA_REGISTRATION_EVENTS|Whenever a published metadataset is registered. This can be either a SDMXML reference metadata file or an SDMX conformant database.
	1065	+|ALL_EVENTS|All events of the specified EventType
1029	1029	)))
1030	1030
1031		-=== 7.5.3 Wildcard Facility ===
	1068	+===== {{id name="_Toc90829"/}}7.5.3 Wildcard Facility =====
1032	1032
1033	1033	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:
1034	1034
...	...	@@ -1084,29 +1084,30 @@
1084	1084
1085	1085	The complete SDMX versioning syntax can be found in the SDMX Standards Section 6 “Technical Notes”, paragraph “4.3 Versioning”.
1086	1086
1087		-=== 7.5.4 Structural Repository Events ===
	1124	+===== {{id name="_Toc90830"/}}7.5.4 Structural Repository Events =====
1088	1088
1089	1089	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.
1090	1090
1091		-=== 7.5.5 Registration Events ===
	1128	+===== {{id name="_Toc90831"/}}7.5.5 Registration Events =====
1092	1092
1093	1093	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:
1094	1094
	1132	+:
	1133	+
1095	1095	(((
1096		-(% style="width:1082.83px" %)
1097		-|(% style="width:230px" %)**Selector**|(% style="width:850px" %)**Comment**
1098		-|(% style="width:230px" %)DataProvider|(% style="width:850px" %)Any datasets registered by the specified dataprovider will activate the notification.
1099		-|(% style="width:230px" %)ProvisionAgreement|(% style="width:850px" %)Any datasets for the agreement will activate the notification.
1100		-|(% style="width:230px" %)Dataflow|(% style="width:850px" %)Any datasets for the specified dataflow will activate the notification.
1101		-|(% 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
1102		-|(% style="width:230px" %)Category|(% style="width:850px" %)Any datasets registered for those dataflows, provision agreements that are categorised by the category.
	1135	+|**Selector**|**Comment**
	1136	+|DataProvider|Any datasets registered by the specified dataprovider will activate the notification.
	1137	+|ProvisionAgreement|Any datasets for the agreement will activate the notification.
	1138	+|Dataflow|Any datasets for the specified dataflow will activate the notification.
	1139	+|DataStructureDefinition|Any datasets for those dataflows that are based on the specified Data Structure Definition will activate the notification
	1140	+|Category|Any datasets registered for those dataflows, provision agreements that are categorised by the category.
1103	1103	)))
1104	1104
1105	1105	The event will also capture the semantic of the registration: deletion or replacement of an existing registration or a new registration.
1106	1106
1107		-== 7.6 Notification ==
	1145	+== {{id name="_Toc90832"/}}7.6 Notification ==
1108	1108
1109		-=== 7.6.1 Logical Class Diagram ===
	1147	+==== {{id name="_Toc90833"/}}7.6.1 Logical Class Diagram ====
1110	1110
1111	1111	[[image:SDMX 3.1 Section 5_en_8bc1b889.jpg||height="379" width="579"]]
1112	1112
...	...	@@ -1123,15 +1123,15 @@
1123	1123
1124	1124	Additionally, supplementary information may be contained in the notification as detailed below.
1125	1125
1126		-=== 7.6.2 Structural Event Component ===
	1164	+==== {{id name="_Toc90834"/}}7.6.2 Structural Event Component ====
1127	1127
1128	1128	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).
1129	1129
1130		-=== 7.6.3 Registration Event Component ===
	1168	+==== {{id name="_Toc90835"/}}7.6.3 Registration Event Component ====
1131	1131
1132	1132	The notification will contain the Registration.
1133	1133
1134		-----
	1172	+[[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.
1135	1135
1136	1136	[[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:
1137	1137
...	...	@@ -1138,5 +1138,3 @@
1138	1138	IMF.SubAgency1
1139	1139
1140	1140	[[3>>path:#sdfootnote3anc||name="sdfootnote3sym"]] Note that Codelist is also an EnumeratedList.
1141		-
1142		-{{putFootnotes/}}