Changes for page SDMX 3.0 Standards. Section 5. Registry Specification: Logical Functionality

Summary

• Page properties (2 modified, 0 added, 0 removed)
• Objects (0 modified, 0 added, 1 removed)
  • SUZ.Methodology.Code.MethodologyClass[0]

Details

Page properties

Content

...	...	@@ -183,11 +183,11 @@
183	183
184	184	=== {{id name="_Toc93847"/}}5.2.2 Structure Submission Service ===
185	185
186		-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).
	186	+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).
187	187
188	188	=== {{id name="_Toc93848"/}}5.2.3 Structure Query Service ===
189	189
190		-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:
	190	+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:
191	191
192	192	* Structure
193	193
...	...	@@ -280,7 +280,7 @@
280	280	Subscription management involves a user submitting a subscription request which contains:
281	281
282	282	* a query or constraint expression in terms of a filter which defines the events for which the user is interested (e.g., new data for a specific dataflow, or for a domain category, or changes to a Data Structure Definition).
283		-* a list of URIs or endpoints to which an XML notification message can be sent. Supported endpoint types will be email (mailto~: ) and HTTP POST (a normal http:~/~/ address);
	283	+* a list of URIs or endpoints to which an XML notification message can be sent. Supported endpoint types will be email (mailto~:) and HTTP POST (a normal http:~/~/ address);
284	284	* request for a list of submitted subscriptions;
285	285	* deletion of a subscription;
286	286
...	...	@@ -301,8 +301,10 @@
301	301
302	302	a) Be a draft version.
303	303	)))
	304	+|(% style="width:188px" %)**Interface**|(% style="width:542px" %)**Behaviour**
304	304	|(% style="width:188px" %) |(% style="width:542px" %)(((
305	305	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.4-draft does not break integrity of the aforementioned DSD.{{/footnote}} referenced from any other object in the Registry.
	307	+
306	306	4) The semantic versioning rules in the SDMX documentation MUST be obeyed.
307	307	)))
308	308	|(% style="width:188px" %)Structure submission|(% style="width:542px" %)Structures are submitted at the level of the Maintainable Artefact and the behaviour in “All” above is therefore at the level of the Maintainable Artefact.
...	...	@@ -327,12 +327,14 @@
327	327
328	328	The table below shows the identification and related data attributes to be stored in a registry for objects that are one of:
329	329
330		-* //nnotable//
	332	+* //Annotable//
331	331	* //Identifiable//
332	332	* //Nameable//
333	333	* //Versionable//
334	334	* //Maintainable//
335	335
	338	+:
	339	+
336	336	(((
337	337	(% style="width:1052.29px" %)
338	338	|**Object Type**|(% style="width:241px" %)**Data Attributes**|(% style="width:156px" %)**Status**|**Data type**|(% style="width:457px" %)**Notes**
...	...	@@ -360,9 +360,9 @@
360	360
361	361	**Table 1: Common Attributes of Object Types**
362	362
363		-== {{id name="_Toc93856"/}}6.2 Unique identification of SDMX objects ==
	367	+=== {{id name="_Toc93856"/}}6.2 Unique identification of SDMX objects ===
364	364
365		-=== {{id name="_Toc93857"/}}6.2.1 Agencies and Metadata Providers ===
	369	+===== {{id name="_Toc93857"/}}6.2.1 Agencies and Metadata Providers =====
366	366
367	367	The Maintenance Agency in SDMX is maintained in an Agency Scheme which itself is a sub class of Organisation Scheme – this is shown in the class diagram below.
368	368
...	...	@@ -443,14 +443,23 @@
443	443	The packages are:
444	444
445	445	base
	450	+
446	446	codelist
	452	+
447	447	conceptscheme
	454	+
448	448	datastructure
	456	+
449	449	categoryscheme
	458	+
450	450	registry
	460	+
451	451	metadatastructure
	462	+
452	452	process
	464	+
453	453	structuremapping
	466	+
454	454	transformation
455	455
456	456	**maintainable-object-id** is the identifier of the maintainable object. This will always be present as all identifiable objects are either a maintainable object or contained in a maintainable object.
...	...	@@ -495,23 +495,23 @@
495	495
496	496	The Data Structure Definition CRED_EXT_DEBT of legacy version 2.1 maintained by the toplevel Agency TFFS would have the URN:
497	497
498		- urn:sdmx:org.sdmx.infomodel.datastructure.DataStucture=TFFS:CRED_EXT_ DEBT(2.1)
	511	+urn:sdmx:org.sdmx.infomodel.datastructure.DataStucture=TFFS:CRED_EXT_ DEBT(2.1)
499	499
500	500	The URN for a code for Argentina maintained by ISO in the code list CL_3166A2 of semantic version 1.0.0 would be:
501	501
502		- urn:sdmx:org.sdmx.infomodel.codelist.Code=ISO:CL_3166A2(1.0.0).AR
	515	+urn:sdmx:org.sdmx.infomodel.codelist.Code=ISO:CL_3166A2(1.0.0).AR
503	503
504	504	The URN for a category (id of 1) which has parent category (id of 2) maintained by SDMX in the category scheme SUBJECT_MATTER_DOMAINS of the semantic extended version 1.0.0draft would be:
505	505
506		- urn:sdmx:org.sdmx.infomodel.categoryscheme.Category=SDMX:SUBJECT_MATT ER_DOMAINS(1.0.0-draft).1.2
	519	+urn:sdmx:org.sdmx.infomodel.categoryscheme.Category=SDMX:SUBJECT_MATT ER_DOMAINS(1.0.0-draft).1.2
507	507
508	508	The URN for a Metadata Attribute maintained by SDMX in the MSD CONTACT_METADATA of semantic version 1.0.0 where the hierarchy of the Metadata Attribute is CONTACT_DETAILS/CONTACT_NAME would be:
509	509
510		- urn:sdmx:org.sdmx.infomodel.metadatastructure.MetadataAttribute=SDMX: CONTACT_METADATA(1.0.0).CONTACT_DETAILS.CONTACT_NAME
	523	+urn:sdmx:org.sdmx.infomodel.metadatastructure.MetadataAttribute=SDMX: CONTACT_METADATA(1.0.0).CONTACT_DETAILS.CONTACT_NAME
511	511
512	512	The TFFS defines ABC as a sub-Agency of TFFS then the URN of a Dataflow maintained by ABC and identified as EXTERNAL_DEBT of semantic version 1.0.0 would be:
513	513
514		- urn:sdmx:org.sdmx.infomodel.datastructure.Dataflow=TFFS.ABC:EXTERNAL_ DEBT(1.0.0)
	527	+urn:sdmx:org.sdmx.infomodel.datastructure.Dataflow=TFFS.ABC:EXTERNAL_ DEBT(1.0.0)
515	515
516	516	The SDMX-RR MUST support this globally unique identification scheme. The SDMX-RR MUST be able to create the URN from the individual identification attributes submitted and to transform the URN to these identification attributes. The identification attributes are:
517	517
...	...	@@ -612,68 +612,74 @@
612	612	urn:sdmx.org.sdmx.infomodel.{package}.{classname}=
613	613
614	614	(% style="width:1311.29px" %)
615		-|(% style="width:227px" %)**Classname**|(% style="width:525px" %)**Ending URN pattern**|(% style="width:558px" %)**Example**
616		-|(% style="width:227px" %)Agency{{footnote}}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: IMF.SubAgency1{{/footnote}}|(% style="width:525px" %)agencySchemeAgencyId:**AGENCIES**(**1.0**).agencyId|(% style="width:558px" %)ECB:**AGENCIES**(**1.0**).AA
617		-|(% style="width:227px" %)//AgencyScheme//|(% style="width:525px" %)agencySchemeAgencyId:**AGENCIES**(**1.0**)|(% style="width:558px" %)ECB:**AGENCIES**(**1.0**)
618		-|(% style="width:227px" %)//Categorisation//|(% style="width:525px" %)categorisationAgencyId:categorisationId(version)|(% style="width:558px" %)IMF:cat001(1.0.0)
619		-|(% style="width:227px" %)Category|(% style="width:525px" %)categorySchemeAgencyId:categorySchemeId(versi on).categoryId.categoryId.categoryId etc.|(% style="width:558px" %)IMF:SDDS(1.0.0):level_1_category.level_2_category …
620		-|(% style="width:227px" %)//CategoryScheme//|(% style="width:525px" %)categorySchemeAgencyId:categorySchemeId(versi on)|(% style="width:558px" %)IMF:SDDS(1.0.0)
621		-|(% style="width:227px" %)//CategorySchemeMap//|(% style="width:525px" %)(((
	628	+|(% style="width:252px" %)**Classname**|(% style="width:639px" %)**Ending URN pattern**|(% style="width:418px" %)**Example**
	629	+|(% style="width:252px" %)Agency{{footnote}}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: IMF.SubAgency1{{/footnote}}|(% style="width:639px" %)agencySchemeAgencyId:**AGENCIES**(**1.0**).agencyId|(% style="width:418px" %)ECB:**AGENCIES**(**1.0**).AA
	630	+|(% style="width:252px" %)//AgencyScheme//|(% style="width:639px" %)agencySchemeAgencyId:**AGENCIES**(**1.0**)|(% style="width:418px" %)ECB:**AGENCIES**(**1.0**)
	631	+|(% style="width:252px" %)//Categorisation//|(% style="width:639px" %)categorisationAgencyId:categorisationId(version)|(% style="width:418px" %)IMF:cat001(1.0.0)
	632	+|(% style="width:252px" %)Category|(% style="width:639px" %)categorySchemeAgencyId:categorySchemeId(versi on).categoryId.categoryId.categoryId etc.|(% style="width:418px" %)IMF:SDDS(1.0.0):level_1_category.level_2_category …
	633	+|(% style="width:252px" %)//CategoryScheme//|(% style="width:639px" %)categorySchemeAgencyId:categorySchemeId(versi on)|(% style="width:418px" %)IMF:SDDS(1.0.0)
	634	+
	635	+|(% style="width:250px" %)**Classname**|(% style="width:639px" %)**Ending URN pattern**|(% style="width:1049px" %)**Example**
	636	+|(% style="width:250px" %)//CategorySchemeMap//|(% style="width:639px" %)(((
622	622	catSchemeMapAgencyId:catSchemeMapId(version)
623		-)))|(% style="width:558px" %)SDMX:EUROSTAT_SUBJECT_DOMAIN(1.0.0)
624		-|(% style="width:227px" %)Code|(% style="width:525px" %)codeListAgencyId:codelistId(version).codeId|(% style="width:558px" %)SDMX:CL_FREQ(1.0.0).Q
625		-|(% style="width:227px" %)//Codelist//|(% style="width:525px" %)codeListAgencyId:codeListId(version)|(% style="width:558px" %)SDMX:CL_FREQ(1.0.0)
626		-|(% style="width:227px" %)ComponentMap|(% style="width:525px" %)structureMapAgencyId:structureMap(version).com ponentMapId|(% style="width:558px" %)SDMX:BOP_STRUCTURES(1.0.0).REF_AREA_TO_COUNT RY
627		-|(% style="width:227px" %)Concept|(% style="width:525px" %)conceptSchemeAgencyId:conceptSchemeId(versio n).conceptId|(% style="width:558px" %)SDMX:CROSS_DOMAIN_CONCEPTS(1.0.0).FREQ
628		-|(% style="width:227px" %)//ConceptScheme//|(% style="width:525px" %)conceptSchemeAgencyId:conceptSchemeId(versio n)|(% style="width:558px" %)SDMX:CROSS_DOMAIN_CONCEPTS(1.0.0)
629		-|(% style="width:227px" %)//ConceptSchemeMap//|(% style="width:525px" %)(((
	638	+)))|(% style="width:1049px" %)SDMX:EUROSTAT_SUBJECT_DOMAIN(1.0.0)
	639	+|(% style="width:250px" %)Code|(% style="width:639px" %)codeListAgencyId:codelistId(version).codeId|(% style="width:1049px" %)SDMX:CL_FREQ(1.0.0).Q
	640	+|(% style="width:250px" %)//Codelist//|(% style="width:639px" %)codeListAgencyId:codeListId(version)|(% style="width:1049px" %)SDMX:CL_FREQ(1.0.0)
	641	+|(% style="width:250px" %)ComponentMap|(% style="width:639px" %)structureMapAgencyId:structureMap(version).com ponentMapId|(% style="width:1049px" %)SDMX:BOP_STRUCTURES(1.0.0).REF_AREA_TO_COUNT RY
	642	+|(% style="width:250px" %)Concept|(% style="width:639px" %)conceptSchemeAgencyId:conceptSchemeId(versio n).conceptId|(% style="width:1049px" %)SDMX:CROSS_DOMAIN_CONCEPTS(1.0.0).FREQ
	643	+|(% style="width:250px" %)//ConceptScheme//|(% style="width:639px" %)conceptSchemeAgencyId:conceptSchemeId(versio n)|(% style="width:1049px" %)SDMX:CROSS_DOMAIN_CONCEPTS(1.0.0)
	644	+|(% style="width:250px" %)//ConceptSchemeMap//|(% style="width:639px" %)(((
630	630	conceptSchemeMapAgencyId:conceptSchemeMap
631	631	Id(version)
632		-)))|(% style="width:558px" %)SDMX:CONCEPT_MAP(1.0.0)
633		-|(% style="width:227px" %)CustomType|(% style="width:525px" %)customTypeSchemeAgencyId customTypeSchemeId(version) customTypeId|(% style="width:558px" %)ECB: CUSTOM_TYPE_SCHEME(1.0.0).CUSTOM_TYPE_1
634		-|(% style="width:227px" %)//CustomTypeScheme//|(% style="width:525px" %)customTypeSchemeAgencyId customTypeSchemeId(version)|(% style="width:558px" %)ECB:CUSTOM_TYPE_SCHEME(1.0.0)
635		-|(% style="width:227px" %)DataAttrribute|(% style="width:525px" %)dataStructureDefinitionAgencyId:dataStructureDef initionId(version).dataAttributeId|(% style="width:558px" %)TFFS:EXT_DEBT(1.0.0).OBS_STATUS
636		-|(% style="width:227px" %)//DataConstraint//|(% style="width:525px" %)dataConstraintAgencyId:dataConstraintId(version)|(% style="width:558px" %)TFFS:CREDITOR_DATA_CONTENT(1.0.0)
637		-|(% style="width:229px" %)DataConsumer|(% style="width:515px" %)dataConsumerSchemeAgencyId:**DATA_CONSUME RS**(**1.0**).dataConsumerId|(% style="width:567px" %)SDMX:**DATA_CONSUMERS**(**1.0**).CONSUMER_1
638		-|(% style="width:229px" %)//DataConsumerScheme//|(% style="width:515px" %)(((
	647	+)))|(% style="width:1049px" %)SDMX:CONCEPT_MAP(1.0.0)
	648	+|(% style="width:250px" %)CustomType|(% style="width:639px" %)customTypeSchemeAgencyId customTypeSchemeId(version) customTypeId|(% style="width:1049px" %)ECB: CUSTOM_TYPE_SCHEME(1.0.0).CUSTOM_TYPE_1
	649	+|(% style="width:250px" %)//CustomTypeScheme//|(% style="width:639px" %)customTypeSchemeAgencyId customTypeSchemeId(version)|(% style="width:1049px" %)ECB:CUSTOM_TYPE_SCHEME(1.0.0)
	650	+|(% style="width:250px" %)DataAttrribute|(% style="width:639px" %)dataStructureDefinitionAgencyId:dataStructureDef initionId(version).dataAttributeId|(% style="width:1049px" %)TFFS:EXT_DEBT(1.0.0).OBS_STATUS
	651	+|(% style="width:250px" %)//DataConstraint//|(% style="width:639px" %)dataConstraintAgencyId:dataConstraintId(version)|(% style="width:1049px" %)TFFS:CREDITOR_DATA_CONTENT(1.0.0)
	652	+
	653	+|(% style="width:248px" %)**Classname**|(% style="width:643px" %)**Ending URN pattern**|(% style="width:1047px" %)**Example**
	654	+|(% style="width:248px" %)DataConsumer|(% style="width:643px" %)dataConsumerSchemeAgencyId:**DATA_CONSUME RS**(**1.0**).dataConsumerId|(% style="width:1047px" %)SDMX:**DATA_CONSUMERS**(**1.0**).CONSUMER_1
	655	+|(% style="width:248px" %)//DataConsumerScheme//|(% style="width:643px" %)(((
639	639	dataConsumerSchemeAgencyId:**DATA_CONSUME RS**(**1.0**)
640		-)))|(% style="width:567px" %)SDMX:**DATA_CONSUMERS**(**1.0**)
641		-|(% style="width:229px" %)//Dataflow//|(% style="width:515px" %)dataflowAgencyId:dataflowId(version)|(% style="width:567px" %)TFFS:CRED_EXT_DEBT(1.0.0)
642		-|(% style="width:229px" %)DataProvider|(% style="width:515px" %)(((
	657	+)))|(% style="width:1047px" %)SDMX:**DATA_CONSUMERS**(**1.0**)
	658	+|(% style="width:248px" %)//Dataflow//|(% style="width:643px" %)dataflowAgencyId:dataflowId(version)|(% style="width:1047px" %)TFFS:CRED_EXT_DEBT(1.0.0)
	659	+|(% style="width:248px" %)DataProvider|(% style="width:643px" %)(((
643	643	dataProviderSchemeAgencyId:**DATA_PROVIDERS**(**1.0**).dataProviderId
644		-)))|(% style="width:567px" %)SDMX:**DATA_PROVIDERS**(**1.0**).PROVIDER_1
645		-|(% style="width:229px" %)//DataProviderScheme//|(% style="width:515px" %)(((
	661	+)))|(% style="width:1047px" %)SDMX:**DATA_PROVIDERS**(**1.0**).PROVIDER_1
	662	+|(% style="width:248px" %)//DataProviderScheme//|(% style="width:643px" %)(((
646	646	dataProviderSchemeAgencyId:**DATA_PROVIDERS**(**1.0**)
647		-)))|(% style="width:567px" %)SDMX:**DATA_PROVIDERS**(**1.0**)
648		-|(% style="width:229px" %)//DataStructure//|(% style="width:515px" %)dataStructureDefinitionAgencyId:dataStructureDef initionId(version)|(% style="width:567px" %)TFFS:EXT_DEBT(1.0.0)
649		-|(% style="width:229px" %)Dimension|(% style="width:515px" %)dataStructureDefinitionAgencyId:dataStructureDef initionId(version).dimensionId|(% style="width:567px" %)TFFS:EXT_DEBT(1.0.0).FREQ
650		-|(% style="width:229px" %)(((
	664	+)))|(% style="width:1047px" %)SDMX:**DATA_PROVIDERS**(**1.0**)
	665	+|(% style="width:248px" %)//DataStructure//|(% style="width:643px" %)dataStructureDefinitionAgencyId:dataStructureDef initionId(version)|(% style="width:1047px" %)TFFS:EXT_DEBT(1.0.0)
	666	+|(% style="width:248px" %)Dimension|(% style="width:643px" %)dataStructureDefinitionAgencyId:dataStructureDef initionId(version).dimensionId|(% style="width:1047px" %)TFFS:EXT_DEBT(1.0.0).FREQ
	667	+|(% style="width:248px" %)(((
651	651	DimensionDescriptor
652	652	MeasureDescriptor
653	653	AttributeDescriptor
654		-)))|(% style="width:515px" %)dataStructureDefinitionAgencyId:dataStructureDef initionId(version).componentListId where the componentListId is the name of the class (there is only one occurrence of each in the Data Structure Definition)|(% style="width:567px" %)(((
	671	+)))|(% style="width:643px" %)dataStructureDefinitionAgencyId:dataStructureDef initionId(version).componentListId where the componentListId is the name of the class (there is only one occurrence of each in the Data Structure Definition)|(% style="width:1047px" %)(((
655	655	TFFS:EXT_DEBT(1.0.0).DimensionDescriptor
656	656	TFFS:EXT_DEBT(1.0.0).MeasureDescriptor
657	657	TFFS:EXT_DEBT(1.0.0).AttributeDescriptor
658	658	)))
659		-|(% style="width:229px" %)GroupDimensionDescriptor|(% style="width:515px" %)dataStructureDefinitionAgencyId:dataStructureDef initionId(version).groupDimensionDescriptorId|(% style="width:567px" %)TFFS:EXT_DEBT(1.0.0).SIBLING
660		-|(% style="width:229px" %)HierarchicalCode|(% style="width:515px" %)hierarchyAgencyId:hierarchyId(version).hierarchica lCode.hierarchicalCode|(% style="width:567px" %)UNESCO:H-C-GOV(1.0.0).GOV_CODE1.GOV_CODE1_1
661		-|(% style="width:206px" %)//Hierarchy//|(% style="width:525px" %)hierarchyAgencyId:hierarchyId(version)|(% style="width:558px" %)UNESCO:H-C-GOV(1.0.0)
662		-|(% style="width:206px" %)//HierarchyAssociation//|(% style="width:525px" %)hierarchyAssociationAgencyId:hierarchyAssociatio nId(version)|(% style="width:558px" %)UNESCO:CL_EXP_SOURCE(1.0.0)
663		-|(% style="width:206px" %)Level|(% style="width:525px" %)hierarchyAgencyId:hierarchyId(version).level|(% style="width:558px" %)UNESCO:H-C-GOV(1.0.0).LVL1
664		-|(% style="width:206px" %)Measure|(% style="width:525px" %)dataStructureDefinitionAgencyId:dataStructureDef initionId(version).measureId|(% style="width:558px" %)TFFS:EXT_DEBT(1.0.0).OBS_VALUE
665		-|(% style="width:206px" %)MetadataAttribute|(% style="width:525px" %)(((
	676	+|(% style="width:248px" %)GroupDimensionDescriptor|(% style="width:643px" %)dataStructureDefinitionAgencyId:dataStructureDef initionId(version).groupDimensionDescriptorId|(% style="width:1047px" %)TFFS:EXT_DEBT(1.0.0).SIBLING
	677	+|(% style="width:248px" %)HierarchicalCode|(% style="width:643px" %)hierarchyAgencyId:hierarchyId(version).hierarchica lCode.hierarchicalCode|(% style="width:1047px" %)UNESCO:H-C-GOV(1.0.0).GOV_CODE1.GOV_CODE1_1
	678	+
	679	+|(% style="width:248px" %)**Classname**|(% style="width:646px" %)**Ending URN pattern**|(% style="width:1044px" %)**Example**
	680	+|(% style="width:248px" %)//Hierarchy//|(% style="width:646px" %)hierarchyAgencyId:hierarchyId(version)|(% style="width:1044px" %)UNESCO:H-C-GOV(1.0.0)
	681	+|(% style="width:248px" %)//HierarchyAssociation//|(% style="width:646px" %)hierarchyAssociationAgencyId:hierarchyAssociatio nId(version)|(% style="width:1044px" %)UNESCO:CL_EXP_SOURCE(1.0.0)
	682	+|(% style="width:248px" %)Level|(% style="width:646px" %)hierarchyAgencyId:hierarchyId(version).level|(% style="width:1044px" %)UNESCO:H-C-GOV(1.0.0).LVL1
	683	+|(% style="width:248px" %)Measure|(% style="width:646px" %)dataStructureDefinitionAgencyId:dataStructureDef initionId(version).measureId|(% style="width:1044px" %)TFFS:EXT_DEBT(1.0.0).OBS_VALUE
	684	+|(% style="width:248px" %)MetadataAttribute|(% style="width:646px" %)(((
666	666	msdAgencyId:msdId(version).metadataAttributeId.
667	667	metadataAttributeId
668		-)))|(% style="width:558px" %)IMF:SDDS_MSD(1.0.0).COMPILATION.METHOD
669		-|(% style="width:206px" %)MetadataAttributeDescriptor|(% style="width:525px" %)msdAgencyId:msdId(version).metadataAttributeDe scriptorId|(% style="width:558px" %)IMF:SDDS_MSD(1.0.0).MetadataAttributeDescriptor
670		-|(% style="width:206px" %)//MetadataConstraint//|(% style="width:525px" %)metadataConstraintAgencyId:metadataConstraintI d(version)|(% style="width:558px" %)TFFS:CREDITOR_METADATA_CONTENT(1.0.0)
671		-|(% style="width:206px" %)//Metadataflow//|(% style="width:525px" %)metadataflowAgencyId:metadataflowId(version)|(% style="width:558px" %)IMF:SDDS_MDF(1.0.0)
672		-|(% style="width:206px" %)MetadataProvider|(% style="width:525px" %)metadataProviderSchemeAgencyId:**METADATA_P ROVIDERS**(**1.0**).metadataProviderId|(% style="width:558px" %)SDMX:**METADATA_PROVIDERS**(**1.0**).MD_PROVIDER_1
673		-|(% style="width:206px" %)//MetadataProviderScheme//|(% style="width:525px" %)metadataProviderSchemeAgencyId:**METADATA_P ROVIDERS**(**1.0**)|(% style="width:558px" %)SDMX:**METADATA_PROVIDERS**(**1.0**)
674		-|(% style="width:206px" %)//MetadataProvisionAgreement//|(% style="width:525px" %)metadataProvisionAgreementAgencyId:metadataP rovisionAgreementId(version)|(% style="width:558px" %)IMF:SDDS_MDF_AB(1.0.0)
675		-|(% style="width:206px" %)//MetadataSet//|(% style="width:525px" %)metadataProviderId:metadataSetId(version)|(% style="width:558px" %)MD_PROVIDER:METADATASET(1.0.0)
676		-|(% style="width:206px" %)//MetadataStructure//|(% style="width:525px" %)msdAgencyId:msdId(version)|(% style="width:558px" %)IMF:SDDS_MSD(1.0.0)
	687	+)))|(% style="width:1044px" %)IMF:SDDS_MSD(1.0.0).COMPILATION.METHOD
	688	+|(% style="width:248px" %)MetadataAttributeDescriptor|(% style="width:646px" %)msdAgencyId:msdId(version).metadataAttributeDe scriptorId|(% style="width:1044px" %)IMF:SDDS_MSD(1.0.0).MetadataAttributeDescriptor
	689	+|(% style="width:248px" %)//MetadataConstraint//|(% style="width:646px" %)metadataConstraintAgencyId:metadataConstraintI d(version)|(% style="width:1044px" %)TFFS:CREDITOR_METADATA_CONTENT(1.0.0)
	690	+|(% style="width:248px" %)//Metadataflow//|(% style="width:646px" %)metadataflowAgencyId:metadataflowId(version)|(% style="width:1044px" %)IMF:SDDS_MDF(1.0.0)
	691	+|(% style="width:248px" %)MetadataProvider|(% style="width:646px" %)metadataProviderSchemeAgencyId:**METADATA_P ROVIDERS**(**1.0**).metadataProviderId|(% style="width:1044px" %)SDMX:**METADATA_PROVIDERS**(**1.0**).MD_PROVIDER_1
	692	+|(% style="width:248px" %)//MetadataProviderScheme//|(% style="width:646px" %)metadataProviderSchemeAgencyId:**METADATA_P ROVIDERS**(**1.0**)|(% style="width:1044px" %)SDMX:**METADATA_PROVIDERS**(**1.0**)
	693	+|(% style="width:248px" %)//MetadataProvisionAgreement//|(% style="width:646px" %)metadataProvisionAgreementAgencyId:metadataP rovisionAgreementId(version)|(% style="width:1044px" %)IMF:SDDS_MDF_AB(1.0.0)
	694	+|(% style="width:248px" %)//MetadataSet//|(% style="width:646px" %)metadataProviderId:metadataSetId(version)|(% style="width:1044px" %)MD_PROVIDER:METADATASET(1.0.0)
	695	+|(% style="width:248px" %)//MetadataStructure//|(% style="width:646px" %)msdAgencyId:msdId(version)|(% style="width:1044px" %)IMF:SDDS_MSD(1.0.0)
677	677
678	678	|(% style="width:248px" %)**Classname**|(% style="width:629px" %)**Ending URN pattern**|(% style="width:1061px" %)**Example**
679	679	|(% style="width:248px" %)NamePersonalisation|(% style="width:629px" %)namePersonalisationSchemeAgencyId namePersonalisationSchemeId(version) namePersonalisationId|(% style="width:1061px" %)ECB:PSN_SCHEME(1.0.0).PSN1234
...	...	@@ -724,7 +724,7 @@
724	724
725	725	=== {{id name="_Toc93862"/}}7.1 Structural Definition Metadata ===
726	726
727		-=== {{id name="_Toc93863"/}}7.1.1 Introduction ===
	746	+===== {{id name="_Toc93863"/}}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
...	...	@@ -791,7 +791,7 @@
791	791
792	792	**Table 4: Table of Maintainable Artefacts for Structural Definition Metadata**
793	793
794		-=== {{id name="_Toc93864"/}}7.1.2 Item Scheme, Structure ===
	813	+===== {{id name="_Toc93864"/}}7.1.2 Item Scheme, Structure =====
795	795
796	796	The artefacts included in the structural definitions are:
797	797
...	...	@@ -800,19 +800,19 @@
800	800	* All types of Structure (Data Structure Definition, Metadata Structure Definition)
801	801	* All types of Structure Usage (Dataflow, Metadataflow)
802	802
803		-=== {{id name="_Toc93865"/}}7.1.3 Structure Usage ===
	822	+===== {{id name="_Toc93865"/}}7.1.3 Structure Usage =====
804	804
805		-==== 7.1.3.1 Structure Usage: Basic Concepts ====
	824	+**7.1.3.1 Structure Usage: Basic Concepts**
806	806
807	807	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.
808	808
809		-==== 7.1.3.2 Structure Usage Schematic ====
	828	+**7.1.3.2 Structure Usage Schematic**
810	810
811	811	[[image:SDMX 3-0-0 SECTION 5 FINAL-1.0_en_52097ab5.jpg||height="246" width="438"]]
812	812
813	813	**Figure 9: Schematic of Linking the Data and Metadata Flows to Categories and Structure Definitions**
814	814
815		-==== 7.1.3.3 Structure Usage Model ====
	834	+**7.1.3.3 Structure Usage Model**
816	816
817	817	[[image:SDMX 3-0-0 SECTION 5 FINAL-1.0_en_302cc1a2.jpg||height="548" width="578"]]
818	818
...	...	@@ -927,13 +927,13 @@
927	927	The Registration has an action attribute which takes one of the following values:
928	928
929	929	(((
930		-(% style="width:761.294px" %)
931		-|(% style="width:196px" %)**Action Attribute Value**|(% style="width:561px" %)**Behaviour**
932		-|(% style="width:196px" %)Append|(% style="width:561px" %)Add this Registration to the registry
933		-|(% style="width:196px" %)Replace|(% style="width:561px" %)(((
	949	+(% style="width:679.294px" %)
	950	+|(% style="width:196px" %)**Action Attribute Value**|(% style="width:480px" %)**Behaviour**
	951	+|(% style="width:196px" %)Append|(% style="width:480px" %)Add this Registration to the registry
	952	+|(% style="width:196px" %)Replace|(% style="width:480px" %)(((
934	934	Replace the existing Registration with identified by the id in the Registration of the SubmitRegistrationRequest
935	935	)))
936		-|(% style="width:196px" %)Delete|(% style="width:561px" %)Delete the existing Registration identified by the id in the Registration of the SubmitRegistrationRequest
	955	+|(% style="width:196px" %)Delete|(% style="width:480px" %)Delete the existing Registration identified by the id in the Registration of the SubmitRegistrationRequest
937	937	)))
938	938
939	939	[[image:SDMX 3-0-0 SECTION 5 FINAL-1.0_en_bc1dcdec.jpg||height="575" width="579"]]
...	...	@@ -950,20 +950,27 @@
950	950
951	951	Information in the data or metadata set is extracted and placed in one or more //Constraint//s (see the //Constraint// model in the SDMX Information Model – Section 2 of the SDMX Standards). The information to be extracted is indicated by the Boolean values set on the ProvisionAgreement or MetadataProvisionAgreement as shown in the table below.
952	952
	972	+:
	973	+
953	953	(((
954		-(% style="width:678.294px" %)
955		-|**Indexing Required**|(% style="width:504px" %)**Registration Process Activity**
956		-|indexTimeSeries|(% style="width:504px" %)Extract all the series keys and create a KeySet(s) Constraint.
957		-|indexDataSet|(% style="width:504px" %)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.
958		-|indexReportingPeriod|(% style="width:504px" %)(((
	975	+|**Indexing Required**|**Registration Process Activity**
	976	+|indexTimeSeries|Extract all the series keys and create a KeySet(s) Constraint.
	977	+|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.
	978	+|indexReportingPeriod|(((
959	959	This applies only to a registered __dataset__.
	980	+
960	960	Extract the Reporting Begin and Reporting End from the Header of the Message containing the data set, and create a Reference Period constraint.
961	961	)))
962		-|**Indexing Required**|(% style="width:504px" %)**Registration Process Activity**
963		-|indexAttributes|(% style="width:504px" %)(((
	983	+|**Indexing Required**|**Registration Process Activity**
	984	+|indexAttributes|(((
964	964	**Data Set**
965		-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
	986	+
	987	+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
	988	+
	989	+SDMXIM, and the associated Selection Value
	990	+
966	966	**Metadata Set**
	992	+
967	967	Indicate the presence of a Reported Attribute by creating one or more Cube Regions containing Member Selections of Metadata Attribute Components of the Constraints model in the SDMX-IM. Note that the content is not stored in the Selection Value.
968	968	)))
969	969	)))
...	...	@@ -972,7 +972,7 @@
972	972
973	973	The Registration must reference the ProvisionAgreement or MetadataProvisionAgreement to which it relates.
974	974
975		-=== {{id name="_Toc93876"/}}7.4.3 Registration Response ===
	1001	+===== {{id name="_Toc93876"/}}7.4.3 Registration Response =====
976	976
977	977	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”.
978	978
...	...	@@ -1002,18 +1002,20 @@
1002	1002
1003	1003	Regardless of the type of registry/repository events being observed, a subscription always contains:
1004	1004
1005		-1. set of URIs describing the end-points to which notifications must be sent if the subscription is activated. The URIs can be either mailto~: or http: protocol. In the former case an email notification is sent; in the latter an HTTP POST notification is sent.
	1031	+1. A set of URIs describing the end-points to which notifications must be sent if the subscription is activated. The URIs can be either mailto~: or http: protocol. In the former case an email notification is sent; in the latter an HTTP POST notification is sent.
1006	1006	1. A user-defined identifier, which is returned in the response to the subscription request. This helps with asynchronous processing and is NOT stored in the Registry.
1007	1007	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.
1008	1008	1. A selector which specifies which type of events are of interest. The set of event types is:
1009	1009
	1036	+:
	1037	+::
	1038	+
1010	1010	(((
1011		-(% style="width:856.294px" %)
1012		-|(% style="width:320px" %)**Event Type**|(% style="width:532px" %)**Comment**
1013		-|(% style="width:320px" %)STRUCTURAL_REPOSITORY_EVENTS|(% style="width:532px" %)Life-cycle changes to Maintainable Artefacts in the structural metadata repository.
1014		-|(% style="width:320px" %)DATA_REGISTRATION_EVENTS|(% style="width:532px" %)Whenever a published dataset is registered. This can be either a SDMXML data file or an SDMX conformant database.
1015		-|(% style="width:320px" %)METADATA_REGISTRATION_EVENTS|(% style="width:532px" %)Whenever a published metadataset is registered. This can be either a SDMXML reference metadata file or an SDMX conformant database.
1016		-|(% style="width:320px" %)ALL_EVENTS|(% style="width:532px" %)All events of the specified EventType
	1040	+|**Event Type**|**Comment**
	1041	+|STRUCTURAL_REPOSITORY_EVENTS|Life-cycle changes to Maintainable Artefacts in the structural metadata repository.
	1042	+|DATA_REGISTRATION_EVENTS|Whenever a published dataset is registered. This can be either a SDMXML data file or an SDMX conformant database.
	1043	+|METADATA_REGISTRATION_EVENTS|Whenever a published metadataset is registered. This can be either a SDMXML reference metadata file or an SDMX conformant database.
	1044	+|ALL_EVENTS|All events of the specified EventType
1017	1017	)))
1018	1018
1019	1019	=== {{id name="_Toc93880"/}}7.5.3 Wildcard Facility ===
...	...	@@ -1027,25 +1027,33 @@
1027	1027	Examples of wildcarded identifier components for an identified object type of Codelist are shown below:
1028	1028
1029	1029	AgencyID = *
	1058	+
1030	1030	Id = *
	1060	+
1031	1031	Version = *
1032	1032
1033	1033	This subscribes to all Codelists of all versions for all agencies.
1034	1034
1035	1035	AgencyID = AGENCY1
	1066	+
1036	1036	Id = CODELIST1
	1068	+
1037	1037	Version = *
1038	1038
1039	1039	This subscribes to all versions of Codelist CODELIST1 maintained by the agency AGENCY1.
1040	1040
1041	1041	AgencyID = AGENCY1
	1074	+
1042	1042	Id = *
	1076	+
1043	1043	Version = *
1044	1044
1045	1045	This subscribes to all versions of all Codelist objects maintained by the agency AGENCY1.
1046	1046
1047	1047	AgencyID = *
	1082	+
1048	1048	Id = CODELIST1
	1084	+
1049	1049	Version = *
1050	1050
1051	1051	This subscribes to all versions of Codelist CODELIST1 maintained by any agency.
...	...	@@ -1072,14 +1072,15 @@
1072	1072
1073	1073	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:
1074	1074
	1111	+:
	1112	+
1075	1075	(((
1076		-(% style="width:1126.29px" %)
1077		-|(% style="width:382px" %)**Selector**|(% style="width:740px" %)**Comment**
1078		-|(% style="width:382px" %)DataProvider & MetadataProvider|(% style="width:740px" %)Any datasets or metadata sets registered by the specified data or metadata provider will activate the notification.
1079		-|(% style="width:382px" %)ProvisionAgreement & MetadataProvisionAgreement|(% style="width:740px" %)Any datasets or metadata sets registered for the agreement will activate the notification.
1080		-|(% style="width:382px" %)Dataflow & Metadataflow|(% style="width:740px" %)Any datasets or metadata sets registered for the specified dataflow (or metadataflow) will activate the notification.
1081		-|(% style="width:382px" %)DataStructureDefinition & MetadataStructureDefinition|(% style="width:740px" %)Any datasets or metadata sets registered for those dataflows (or metadataflows) that are based on the specified Data Structure Definition will activate the notification
1082		-|(% style="width:382px" %)Category|(% style="width:740px" %)Any datasets or metadata sets registered for those dataflows, metadataflows, provision agreements that are categorised by the category.
	1114	+|**Selector**|**Comment**
	1115	+|DataProvider & MetadataProvider|Any datasets or metadata sets registered by the specified data or metadata provider will activate the notification.
	1116	+|ProvisionAgreement & MetadataProvisionAgreement|Any datasets or metadata sets registered for the agreement will activate the notification.
	1117	+|Dataflow & Metadataflow|Any datasets or metadata sets registered for the specified dataflow (or metadataflow) will activate the notification.
	1118	+|DataStructureDefinition & MetadataStructureDefinition|Any datasets or metadata sets registered for those dataflows (or metadataflows) that are based on the specified Data Structure Definition will activate the notification
	1119	+|Category|Any datasets or metadata sets registered for those dataflows, metadataflows, provision agreements that are categorised by the category.
1083	1083	)))
1084	1084
1085	1085	The event will also capture the semantic of the registration: deletion or replacement of an existing registration or a new registration.
...	...	@@ -1111,6 +1111,12 @@
1111	1111
1112	1112	The notification will contain the Registration.
1113	1113
1114		-----
	1151	+[[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.
1115	1115
	1153	+[[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:
	1154	+
	1155	+IMF.SubAgency1
	1156	+
	1157	+[[3>>path:#sdfootnote3anc||name="sdfootnote3sym"]] Note that Codelist is also an EnumeratedList.
	1158	+
1116	1116	{{putFootnotes/}}

SUZ.Methodology.Code.MethodologyClass[0]