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