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

Summary

• Page properties (1 modified, 0 added, 0 removed)
• Attachments (0 modified, 8 added, 0 removed)
  • 1747829078194-749.png
  • 1747829109466-595.png
  • 1747829139951-378.png
  • 1747829204737-370.png
  • 1747829290890-122.png
  • 1747829477882-750.png
  • 1747829554603-150.png
  • 1747829675568-610.png

Details

Page properties

Content

...	...	@@ -340,8 +340,8 @@
340	340
341	341	The following table defines the behaviour of the SDMX Registry for the various Registry Interface messages.
342	342
343		-|(% style="width:143px" %)**Interface**|(% style="width:1729px" %)**Behaviour**
344		-|(% style="width:143px" %)All|(% style="width:1729px" %)(((
	343	+|(% style="width:244px" %)**Interface**|**Behaviour**
	344	+|(% style="width:244px" %)All|(((
345	345	1) If the action is set to “replace” then the entire contents of the existing maintainable object in the Registry MUST be replaced by the object submitted, unless the final attribute is set to “true” in which case the only changes that are allowed are to the following constructs:
346	346
347	347	* Name – this applies to the Maintainable object and its contained elements, such a Code in a Code list.
...	...	@@ -365,11 +365,10 @@
365	365
366	366	5) The specific rules for the elements and attributes documented in the SDMX Schema MUST be obeyed.
367	367	)))
368		-|(% style="width:143px" %)SubmitStructureRequest|(% style="width:1729px" %)Structures are submitted at the level of the Maintainable Artefact and the behaviour in “All” above is therefore at the level of the Maintainable Artefact.
369		-|(% style="width:143px" %)SubmitProvisioningRequest|(% style="width:1729px" %)No additional behaviour.
370		-|(% style="width:143px" %)Submit Registration Request|(% style="width:1729px" %)(((
	368	+|(% style="width:244px" %)SubmitStructureRequest|Structures are submitted at the level of the Maintainable Artefact and the behaviour in “All” above is therefore at the level of the Maintainable Artefact.
	369	+|(% style="width:244px" %)SubmitProvisioningRequest|No additional behaviour.
	370	+|(% style="width:244px" %)Submit Registration Request|(((
371	371	If the datasource is a file (simple datasource) then the file MAY be retrieved and indexed according to the Boolean attributes set in the Registration.
372		-
373	373	For a queryable datasource the Registry MAY validate that the source exists and can accept an SDMX-ML data query.
374	374	)))
375	375
...	...	@@ -470,9 +470,10 @@
470	470
471	471	An example of this is shown in the XML snippet below.
472	472
473		-[[image:1747824123013-196.jpeg]]
	472	+[[image:1747824123013-196.jpeg||height="309" width="446"]]
474	474
475		-==== Figure 8: Example Showing Use of Agency Identifiers ====
	474	+(% class="wikigeneratedid" id="HFigure8:ExampleShowingUseofAgencyIdentifiers" %)
	475	+**Figure 8: Example Showing Use of Agency Identifiers**
476	476
477	477	Each of these maintenance agencies has an identical Code list with the Id CL_BOP. However, each is uniquely identified by means of the hierarchic agency structure.
478	478
...	...	@@ -512,10 +512,8 @@
512	512
513	513	**(maintainable-object-version)** is the version of the maintainable object and is enclosed in round brackets (). It will always be present.
514	514
515		-**container-object-id** is the identifier of an intermediary object that contains the actual object which the URN is identifying. It is not mandatory as many actual objects do not have an intermediary container object. For instance, a Code is in a maintained object (Code List) and has no intermediary container object, whereas a Metadata Attribute has an intermediary container object (Report Structure) and may have an intermediary container object which is its parent Metadata Attribute. For this reason the container object id may repeat, with each repetition identifying the object at the next-lower level in its hierarchy. Note that if there is only a single containing object in the model then it is NOT included in the URN structure. This applies to Attribute Descriptor, Dimension Descriptor, and Measure Descriptor where there can be only one such object and this object has a fixed id. Therefore, whilst each of these has a
	515	+**container-object-id** is the identifier of an intermediary object that contains the actual object which the URN is identifying. It is not mandatory as many actual objects do not have an intermediary container object. For instance, a Code is in a maintained object (Code List) and has no intermediary container object, whereas a Metadata Attribute has an intermediary container object (Report Structure) and may have an intermediary container object which is its parent Metadata Attribute. For this reason the container object id may repeat, with each repetition identifying the object at the next-lower level in its hierarchy. Note that if there is only a single containing object in the model then it is NOT included in the URN structure. This applies to Attribute Descriptor, Dimension Descriptor, and Measure Descriptor where there can be only one such object and this object has a fixed id. Therefore, whilst each of these has a URN, the id of the Attribute Descriptor, Dimension Descriptor, and Measure Descriptor is not included when the actual object is a Data Attribute or a Dimension/Measure Dimension/ Time Dimension, or a Measure.
516	516
517		-URN, the id of the Attribute Descriptor, Dimension Descriptor, and Measure Descriptor is not included when the actual object is a Data Attribute or a Dimension/Measure Dimension/ Time Dimension, or a Measure.
518		-
519	519	Note that although a Code can have a parent Code and a Concept can have a parent Concept these are maintained in a flat structure and therefore do not have a container-object-id.
520	520
521	521	For example the sequence is agency:DSDid(version).DimensionId and not agency:DSDid(version).DimensionDescriptorId.DimensionId.
...	...	@@ -522,58 +522,57 @@
522	522
523	523	**object-id** is the identifier of the actual object unless the actual object is a maintainable object. If present it is always the last id and is not followed by any other character.
524	524
525		-===== //Generic Examples of the URN Structure// =====
	523	+===== __**//Generic Examples of the URN Structure//**__ =====
526	526
	525	+__Actual object is a maintainable__
527	527
528		-Actual object is a maintainable
	527	+> SDMXPrefix.SDMX-IM package name.classname=agency id:maintained-object-id(version)
529	529
530		-SDMXPrefix.SDMX-IM package name.classname=agency id:maintained-object-id(version)
	529	+__Actual object is contained in a maintained object with no intermediate containing object__
531	531
532		-Actual object is contained in a maintained object with no intermediate containing object
	531	+> SDMXPrefix.SDMX-IM package name.classname=agency id:maintained-object-id(version).object-id
533	533
534		-SDMXPrefix.SDMX-IM package name.classname=agency id:maintained-object-id(version).object-id
	533	+__Actual object is contained in a maintained object with an intermediate containing object__
535	535
536		-Actual object is contained in a maintained object with an intermediate containing object
	535	+> SDMXPrefix.SDMX-IM package name.classname=agency
537	537
538		-SDMXPrefix.SDMX-IM package name.classname=agency
539		-
540	540	id:maintained-object-id(version).contained-object-id.object-id
541	541
542		-Actual object is contained in a maintained object with no intermediate containing object but the object type itself is hierarchical
	539	+__Actual object is contained in a maintained object with no intermediate containing object but the object type itself is hierarchical__
543	543
544	544	In this case the object id may not be unique in itself but only within the context of the hierarchy. In the general syntax of the URN all intermediary objects in the structure (with the exception, of course, of the maintained object) are shown as a contained object. An example here would be a Category in a Category Scheme. The Category is hierarchical and all intermediate Categories are shown as a contained object. The example below shows the generic structure for Category Scheme/Category/Category
545	545
546		-SDMXPrefix.SDMX-IM package name.classname=agency id:maintained-object-id(version).contained-object-id.object-id
	543	+> SDMXPrefix.SDMX-IM package name.classname=agency id:maintained-object-id(version).contained-object-id.object-id
547	547
548		-Actual object is contained in a maintained object with an intermediate containing object and the object type itself is hierarchical
	545	+__Actual object is contained in a maintained object with an intermediate containing object and the object type itself is hierarchical__
549	549
550	550	In this case the generic syntax is the same as for the example above as the parent object is regarded as a containing object, even if it is of the same type. An example here is a Metadata Attribute where the contained objects are Report Structure (first contained object id) and Metadata Attribute (subsequent contained object Ids). The example below shows the generic structure for MSD/Report Structure/Metadata Attribute/Metadata Attribute
551	551
552		-SDMXPrefix.SDMX-IM package name.classname=agency id:maintained-object-id(version).contained-object-id. contained-object-id contained-object-id.object-id
	549	+> SDMXPrefix.SDMX-IM package name.classname=agency id:maintained-object-id(version).contained-object-id. contained-object-id contained-object-id.object-id
553	553
554		-===== //Concrete Examples of the URN Structure// =====
	551	+===== __**//Concrete Examples of the URN Structure//**__ =====
555	555
556	556	The Data Structure Definition CRED_EXT_DEBT version 1.0 maintained by the top level Agency TFFS would have the URN:
557	557
558		-urn:sdmx:org.sdmx.infomodel.datastructure.DataStucture=TFFS:CRED_EXT_ DEBT(1.0)
	555	+> urn:sdmx:org.sdmx.infomodel.datastructure.DataStucture=TFFS:CRED_EXT_ DEBT(1.0)
559	559
560	560	The URN for a code for Argentina maintained by ISO in the code list CL_3166A2 version 1.0 would be:
561	561
562		-urn:sdmx:org.sdmx.infomodel.codelist.Code=ISO:CL_3166A2(1.0).AR
	559	+> urn:sdmx:org.sdmx.infomodel.codelist.Code=ISO:CL_3166A2(1.0).AR
563	563
564	564	The URN for a category (id of 1) which has parent category (id of 2) maintained by SDMX in the category scheme SUBJECT_MATTER_DOMAINS version 1.0 would be:
565	565
566		-urn:sdmx:org.sdmx.infomodel.categoryscheme.Category=SDMX:SUBJE CT_MATTER_DOMAINS(1.0).1.2
	563	+> urn:sdmx:org.sdmx.infomodel.categoryscheme.Category=SDMX:SUBJE CT_MATTER_DOMAINS(1.0).1.2
567	567
568	568	The URN for a Metadata Attribute maintained by SDMX in the MSD CONTACT_METADATA version 1.0 in the Report Structure CONTACT_REPORT where the hierarchy of the Metadata Attribute is
569	569
570	570	CONTACT_DETAILS/CONTACT_NAME would be:
571	571
572		-urn:sdmx:org.sdmx.infomodel.metadatastructure.MetadataAttribut e=SDMX:CONTACT_METADATA(1.0).CONTACT_REPORT.CONTACT_DETAILS.CO NTACT_NAME
	569	+> urn:sdmx:org.sdmx.infomodel.metadatastructure.MetadataAttribut e=SDMX:CONTACT_METADATA(1.0).CONTACT_REPORT.CONTACT_DETAILS.CO NTACT_NAME
573	573
574	574	The TFFS defines ABC as a sub Agency of TFFS then the URN of a Dataflow maintained by ABC and identified as EXTERNAL_DEBT version 1.0 would be:
575	575
576		-urn:sdmx:org.sdmx.infomodel.datastructure.Dataflow=TFFS.ABC:EX
	573	+> urn:sdmx:org.sdmx.infomodel.datastructure.Dataflow=TFFS.ABC:EX
577	577
578	578	TERNAL_DEBT(1.0)
579	579
...	...	@@ -588,112 +588,94 @@
588	588
589	589	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.
590	590
591		-|**Package**|(((
592		-**URN Classname (model classname**
593		-
594		-**where this is different)**
	588	+|(% style="width:127px" %)**Package**|(% style="width:1745px" %)(((
	589	+**URN Classname (model classname where this is different)**
595	595	)))
596		-|base|Agency
597		-| |OrganisationUnitScheme
598		-| |AgencyScheme
599		-| |DataProviderScheme
600		-| |DataConsumerScheme
601		-| |OrganisationUnit
602		-| |DataProvider
603		-| |DataConsumer
604		-| |
605		-|datastructure|DataStructure (DataStructureDefinition)
606		-| |AttributeDescriptor
607		-| |DataAttribute
608		-| |GroupDimensionDescriptor
609		-| |DimensionDescriptor
610		-| |Dimension
611		-| |MeasureDimension
612		-| |TimeDimension
613		-| |MeasureDescriptor
614		-| |PrimaryMeasure
615		-| |Dataflow (DataflowDefinition)
616		-| |
617		-|metadatastructure|MetadataTarget
618		-| |DimensionDescriptorValueTarget
619		-| |IdentifiableObjectTarget
620		-| |ReportPeriodTarget
621		-| |DataSetTarget
622		-| |ReportStructure
623		-| |MetadataAttribute
624		-| |(((
	591	+|(% style="width:127px" %)base|(% style="width:45px" %)Agency
	592	+|(% style="width:127px" %) |(% style="width:45px" %)OrganisationUnitScheme
	593	+|(% style="width:127px" %) |(% style="width:45px" %)AgencyScheme
	594	+|(% style="width:127px" %) |(% style="width:45px" %)DataProviderScheme
	595	+|(% style="width:127px" %) |(% style="width:45px" %)DataConsumerScheme
	596	+|(% style="width:127px" %) |(% style="width:45px" %)OrganisationUnit
	597	+|(% style="width:127px" %) |(% style="width:45px" %)DataProvider
	598	+|(% style="width:127px" %) |(% style="width:45px" %)DataConsumer
	599	+|(% style="width:127px" %)datastructure|(% style="width:45px" %)DataStructure (DataStructureDefinition)
	600	+|(% style="width:127px" %) |(% style="width:45px" %)AttributeDescriptor
	601	+|(% style="width:127px" %) |(% style="width:45px" %)DataAttribute
	602	+|(% style="width:127px" %) |(% style="width:45px" %)GroupDimensionDescriptor
	603	+|(% style="width:127px" %) |(% style="width:45px" %)DimensionDescriptor
	604	+|(% style="width:127px" %) |(% style="width:45px" %)Dimension
	605	+|(% style="width:127px" %) |(% style="width:45px" %)MeasureDimension
	606	+|(% style="width:127px" %) |(% style="width:45px" %)TimeDimension
	607	+|(% style="width:127px" %) |(% style="width:45px" %)MeasureDescriptor
	608	+|(% style="width:127px" %) |(% style="width:45px" %)PrimaryMeasure
	609	+|(% style="width:127px" %) |(% style="width:45px" %)Dataflow (DataflowDefinition)
	610	+|(% style="width:127px" %)metadatastructure|(% style="width:45px" %)MetadataTarget
	611	+|(% style="width:127px" %) |(% style="width:45px" %)DimensionDescriptorValueTarget
	612	+|(% style="width:127px" %) |(% style="width:45px" %)IdentifiableObjectTarget
	613	+|(% style="width:127px" %) |(% style="width:45px" %)ReportPeriodTarget
	614	+|(% style="width:127px" %) |(% style="width:45px" %)DataSetTarget
	615	+|(% style="width:127px" %) |(% style="width:45px" %)ReportStructure
	616	+|(% style="width:127px" %) |(% style="width:45px" %)MetadataAttribute
	617	+|(% style="width:127px" %) |(% style="width:45px" %)(((
625	625	MetadataStructure
626	626
627	627	(MetadataStructureDefinition)
628	628	)))
629		-| |Metadataflow (MetadataflowDefinition)
630		-| |
631		-|process|Process
632		-| |ProcessStep
633		-| |Transition
634		-| |
635		-|registry|ProvisionAgreement
636		-| |AttachmentConstraint
637		-| |ContentConstraint
638		-| |Subscription
639		-| |
640		-|mapping|StructureMap
641		-| |StructureSet
642		-| |ComponentMap
643		-|**Package**|(((
644		-**URN Classname (model classname**
	622	+|(% style="width:127px" %) |(% style="width:45px" %)Metadataflow (MetadataflowDefinition)
	623	+|(% style="width:127px" %)process|(% style="width:45px" %)Process
	624	+|(% style="width:127px" %) |(% style="width:45px" %)ProcessStep
	625	+|(% style="width:127px" %) |(% style="width:45px" %)Transition
	626	+|(% style="width:127px" %)registry|(% style="width:45px" %)ProvisionAgreement
	627	+|(% style="width:127px" %) |(% style="width:45px" %)AttachmentConstraint
	628	+|(% style="width:127px" %) |(% style="width:45px" %)ContentConstraint
	629	+|(% style="width:127px" %) |(% style="width:45px" %)Subscription
	630	+|(% style="width:127px" %)mapping|(% style="width:45px" %)StructureMap
	631	+|(% style="width:127px" %) |(% style="width:45px" %)StructureSet
	632	+|(% style="width:127px" %) |(% style="width:45px" %)ComponentMap
	633	+|(% style="width:127px" %) |(% style="width:1745px" %)ConceptSchemeMap
	634	+|(% style="width:127px" %) |(% style="width:1745px" %)OrganisationSchemeMap
	635	+|(% style="width:127px" %) |(% style="width:1745px" %)CodelistMap
	636	+|(% style="width:127px" %) |(% style="width:1745px" %)CategorySchemeMap
	637	+|(% style="width:127px" %) |(% style="width:1745px" %)ReportingTaxonomyMap
	638	+|(% style="width:127px" %) |(% style="width:1745px" %)ConceptMap
	639	+|(% style="width:127px" %) |(% style="width:1745px" %)OrganisationMap
	640	+|(% style="width:127px" %) |(% style="width:1745px" %)CodeMap
	641	+|(% style="width:127px" %) |(% style="width:1745px" %)HybridCodelistMap
	642	+|(% style="width:127px" %) |(% style="width:1745px" %)CategoryMap
	643	+|(% style="width:127px" %) |(% style="width:1745px" %)HybridCodeMap
	644	+|(% style="width:127px" %) |(% style="width:1745px" %)ReportingCategoryMap
	645	+|(% style="width:127px" %)codelist|(% style="width:1745px" %)Codelist
	646	+|(% style="width:127px" %) |(% style="width:1745px" %)HierarchicalCodelist
	647	+|(% style="width:127px" %) |(% style="width:1745px" %)Hierarchy
	648	+|(% style="width:127px" %) |(% style="width:1745px" %)Hierarchy
	649	+|(% style="width:127px" %) |(% style="width:1745px" %)Code
	650	+|(% style="width:127px" %) |(% style="width:1745px" %)HierarchicalCode
	651	+|(% style="width:127px" %) |(% style="width:1745px" %)Level
	652	+|(% style="width:127px" %)categoryscheme|(% style="width:1745px" %)CategoryScheme
	653	+|(% style="width:127px" %) |(% style="width:1745px" %)Category
	654	+|(% style="width:127px" %) |(% style="width:1745px" %)Categorisation
	655	+|(% style="width:127px" %) |(% style="width:1745px" %)ReportingTaxonomy
	656	+|(% style="width:127px" %) |(% style="width:1745px" %)ReportingCategory
	657	+|(% style="width:127px" %)conceptscheme|(% style="width:1745px" %)ConceptScheme
	658	+|(% style="width:127px" %) |(% style="width:1745px" %)Concept
	659	+|(% style="width:127px" %)transformation|(% style="width:1745px" %)TransformationScheme
	660	+|(% style="width:127px" %) |(% style="width:1745px" %)Transformation
	661	+|(% style="width:127px" %) |(% style="width:1745px" %)CustomTypeScheme
	662	+|(% style="width:127px" %) |(% style="width:1745px" %)CustomType
	663	+|(% style="width:127px" %) |(% style="width:1745px" %)NamePersonalisationScheme
	664	+|(% style="width:127px" %) |(% style="width:1745px" %)NamePersonalisation
	665	+|(% style="width:127px" %) |(% style="width:1745px" %)VtlCodelistMapping
	666	+|(% style="width:127px" %) |(% style="width:1745px" %)VtlConceptMapping
	667	+|(% style="width:127px" %) |(% style="width:1745px" %)VtlDataflowMapping
	668	+|(% style="width:127px" %) |(% style="width:1745px" %)VtlConceptSchemeMapping
	669	+|(% style="width:127px" %) |(% style="width:1745px" %)RulesetScheme
	670	+|(% style="width:127px" %) |(% style="width:1745px" %)Ruleset
	671	+|(% style="width:127px" %) |(% style="width:1745px" %)UserDefinedOperatorScheme
	672	+|(% style="width:127px" %) |(% style="width:1745px" %)UserDefinedOperator
645	645
646		-**where this is different)**
647		-)))
648		-| |ConceptSchemeMap
649		-| |OrganisationSchemeMap
650		-| |CodelistMap
651		-| |CategorySchemeMap
652		-| |ReportingTaxonomyMap
653		-| |ConceptMap
654		-| |OrganisationMap
655		-| |CodeMap
656		-| |HybridCodelistMap
657		-| |CategoryMap
658		-| |HybridCodeMap
659		-| |ReportingCategoryMap
660		-| |
661		-|codelist|Codelist
662		-| |HierarchicalCodelist
663		-| |Hierarchy
664		-| |Hierarchy
665		-| |Code
666		-| |HierarchicalCode
667		-| |Level
668		-| |
669		-|categoryscheme|CategoryScheme
670		-| |Category
671		-| |Categorisation
672		-| |ReportingTaxonomy
673		-| |ReportingCategory
674		-| |
675		-|conceptscheme|ConceptScheme
676		-| |Concept
677		-| |
678		-|transformation|TransformationScheme
679		-| |Transformation
680		-| |CustomTypeScheme
681		-| |CustomType
682		-| |NamePersonalisationScheme
683		-| |NamePersonalisation
684		-| |VtlCodelistMapping
685		-| |VtlConceptMapping
686		-| |VtlDataflowMapping
687		-| |VtlConceptSchemeMapping
688		-| |RulesetScheme
689		-| |Ruleset
690		-| |UserDefinedOperatorScheme
691		-| |UserDefinedOperator
692		-| |
693		-
694	694	**Table 2: SDMX-IM Packages and Contained Classes**
695	695
696		-
697	697	=== 6.2.4 URN Identification components of SDMX objects ===
698	698
699	699	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.
...	...	@@ -702,78 +702,52 @@
702	702
703	703	Note that for brevity the URN examples omit the prefix. All URNs have the prefix
704	704
705		-urn:sdmx.org.sdmx.infomodel.{package}.{classname}=
	684	+> urn:sdmx.org.sdmx.infomodel.{package}.{classname}=
706	706
707		-
708		-|**SDMX Class**|**Key attribute(s)**|**Example of URN**
709		-|Agency|The URN for an Agency is shown later in this table. The identification of an Agency in the URN structure for the maintainable object is by means of the agencyId. The AgencyScheme is not identified as SDMX has a mechanism for identifying an Agency uniquely by its Id. Note that this Id may be hierarchical.|(((
	686	+(% style="width:1091.29px" %)
	687	+|(% style="width:250px" %)**SDMX Class**|(% style="width:444px" %)**Key attribute(s)**|(% style="width:396px" %)**Example of URN**
	688	+|(% style="width:250px" %)Agency|(% style="width:444px" %)The URN for an Agency is shown later in this table. The identification of an Agency in the URN structure for the maintainable object is by means of the agencyId. The AgencyScheme is not identified as SDMX has a mechanism for identifying an Agency uniquely by its Id. Note that this Id may be hierarchical.|(% style="width:396px" %)(((
710	710	IMF
711		-
712		-
713	713	Sub agency in the IMF AGENCIES
714		-
715		-
716	716	IMF.SubAgency1
717	717	)))
718		-|*ConceptScheme|conceptSchemeAgencyId:conceptSchemeId(ve rsion)|SDMX:CROSS_DOMAIN_CONCEPTS(1.0)
719		-|Concept|(((
720		-conceptSchemeAgencyId:
721		-
722		-conceptSchemeId(version).conceptId
723		-)))|SDMX:CROSS_DOMAIN_CONCEPTS(1.0).FREQ
724		-|*Codelist|codeListAgencyId:codeListId(version)|SDMX:CL_FREQ(1.0)
725		-|Code|codeListAgencyId:codelistId(version).codeId|(((
726		-SDMX:CL_FREQ(1.0).Q
727		-
728		-
	693	+|(% style="width:250px" %)*ConceptScheme|(% style="width:444px" %)conceptSchemeAgencyId:conceptSchemeId(ve rsion)|(% style="width:396px" %)SDMX:CROSS_DOMAIN_CONCEPTS(1.0)
	694	+|(% style="width:250px" %)Concept|(% style="width:444px" %)conceptSchemeAgencyId:
	695	+conceptSchemeId(version).conceptId|(% style="width:396px" %)SDMX:CROSS_DOMAIN_CONCEPTS(1.0).FREQ
	696	+|(% style="width:250px" %)*Codelist|(% style="width:444px" %)codeListAgencyId:codeListId(version)|(% style="width:396px" %)SDMX:CL_FREQ(1.0)
	697	+|(% style="width:250px" %)Code|(% style="width:444px" %)codeListAgencyId:codelistId(version).codeId|(% style="width:396px" %)SDMX:CL_FREQ(1.0).Q
	698	+|(% style="width:250px" %)(((
	699	+*Hierarchical Codelist
	700	+)))|(% style="width:444px" %)hierachicalCodelistAgencyId: hierarchicalCodelistId(version)|(% style="width:396px" %)(((
	701	+UNESCO:CL_EXP_SOURCE(1.0(% style="background-color:transparent" %))
729	729	)))
730		-
731		-
732		-
733		-|(((
734		-*Hierarchical
735		-
736		-Codelist
737		-)))|hierachicalCodelistAgencyId: hierarchicalCodelistId(version)|(((
738		-UNESCO:CL_EXP_SOURCE(1.0)
739		-
740		-
741		-)))
742		-|Hierarchy|(((
	703	+|(% style="width:250px" %)Hierarchy|(% style="width:444px" %)(((
743	743	hierachicalcodeListAgencyId:
744		-
745	745	hierarchicalcodelistId(version).Hierarchy
746		-)))|UNESCO:CL_EXP_SOURCE(1.0). H-C-GOV
747		-|Level|(((
	706	+)))|(% style="width:396px" %)UNESCO:CL_EXP_SOURCE(1.0).
	707	+H-C-GOV
	708	+|(% style="width:250px" %)Level|(% style="width:444px" %)(((
748	748	hierachicalcodeListAgencyId:
749		-
750	750	hierarchicalcodelistId(version).Hierarchy.Level
751		-)))|(((
	711	+)))|(% style="width:396px" %)(((
752	752	ESTAT:HCL_REGION(1.0).H_1.COUNTRY
753	753
754	754
755	755	)))
756		-|HierarchicalCode|hierachicalCodeListAgencyId: hierarchicalcodelistId(version).hierarchy.hierarc hicalCode|UNESCO:CL_EXP_SOURCE(1.0). H-C-GOV.GOV_CODE1
757		-|*DataStructure|dataStructureDefintitionAgencyId: dataStructureDefintitionId(version)|TFFS:EXT_DEBT(1.0)
758		-|(((
	716	+|(% style="width:250px" %)HierarchicalCode|(% style="width:444px" %)hierachicalCodeListAgencyId: hierarchicalcodelistId(version).hierarchy.hierarc hicalCode|(% style="width:396px" %)UNESCO:CL_EXP_SOURCE(1.0). H-C-GOV.GOV_CODE1
	717	+|(% style="width:250px" %)*DataStructure|(% style="width:444px" %)dataStructureDefintitionAgencyId: dataStructureDefintitionId(version)|(% style="width:396px" %)TFFS:EXT_DEBT(1.0)
	718	+|(% style="width:250px" %)(((
759	759	Dimension
760		-
761	761	Descriptor
762		-
763	763	Measure
764		-
765	765	Descriptor
766		-
767	767	Attribute
768		-
769	769	Descriptor
770		-)))|(((
	725	+)))|(% style="width:444px" %)(((
771	771	dataStructureDefinitionAgencyId: dataStructureDefinitionId(version).
772		-
773	773	componentListId
774		-
775	775	where the componentListId is the name of the class (there is only one occurrence of each in the Data Structure Definition)
776		-)))|(((
	729	+)))|(% style="width:396px" %)(((
777	777	TFFS:EXT_DEBT(1.0).DimensionDescriptor
778	778
779	779	TFFS:EXT_DEBT(1.0).MeasureDescriptor
...	...	@@ -780,181 +780,132 @@
780	780
781	781	TFFS:EXT_DEBT(1.0).AttributeDescriptor
782	782	)))
783		-|(((
	736	+|(% style="width:250px" %)(((
784	784	GroupDimension
785		-
786	786	Descriptor
787		-)))|(((
	739	+)))|(% style="width:444px" %)(((
788	788	dataStructureDefinitionAgencyId: dataStructureDefinitionId(version).
789		-
790	790	groupDimensionDescriptorId
791		-)))|TFFS:EXT_DEBT(1.0).SIBLING
792		-|Dimension|(((
	742	+)))|(% style="width:396px" %)TFFS:EXT_DEBT(1.0).SIBLING
	743	+|(% style="width:250px" %)Dimension|(% style="width:444px" %)(((
793	793	dataStructureDefinitionAgencyId: dataStructureDefinition (version).
794		-
795	795	dimensionId
796		-)))|TFFS:EXT_DEBT(1.0).FREQ
797		-|TimeDimension|(((
	746	+)))|(% style="width:396px" %)TFFS:EXT_DEBT(1.0).FREQ
	747	+|(% style="width:250px" %)TimeDimension|(% style="width:444px" %)(((
798	798	dataStructureDefinitionAgencyId: dataStructureDefinition (version).
799		-
800	800	timeDimensionId
801		-)))|TFFS:EXT_DEBT(1.0).TIME_PERIOD
802		-|Measure Dimension|dataStructureDefinitionAgencyId: dataStructureDefinition (version).|TFFS:EXT_DEBT(1.0).STOCK_FLOW
803		-
804		-
805		-
806		-| |measureDimensionId|
807		-|DataAttrribute|dataStructureDefinitionAgencyId: dataStructureDefinition (version). dataAttributeId|TFFS:EXT_DEBT(1.0).OBS_STATUS
808		-|PrimaryMeasure|(((
	750	+)))|(% style="width:396px" %)TFFS:EXT_DEBT(1.0).TIME_PERIOD
	751	+|(% style="width:250px" %)Measure Dimension|(% style="width:444px" %)dataStructureDefinitionAgencyId: dataStructureDefinition (version).
	752	+measureDimensionId|(% style="width:396px" %)TFFS:EXT_DEBT(1.0).STOCK_FLOW
	753	+|(% style="width:250px" %)DataAttrribute|(% style="width:444px" %)dataStructureDefinitionAgencyId: dataStructureDefinition (version). dataAttributeId|(% style="width:396px" %)TFFS:EXT_DEBT(1.0).OBS_STATUS
	754	+|(% style="width:250px" %)PrimaryMeasure|(% style="width:444px" %)(((
809	809	dataStructureDefinitionAgencyId: dataStructureDefinition (version).
810		-
811	811	primaryMeasureId
812		-)))|TFFS:EXT_DEBT(1.0).OBS_VALUE
813		-|(((
814		-*Category
815		-
816		-Scheme
817		-)))|categorySchemeAgencyId: categorySchemeId(version)|IMF:SDDS(1.0)
818		-|Category|categorySchemeAgencyId: categorySchemeId(version). categoryId.categoryId categoryId.categoryId etc.|(((
	757	+)))|(% style="width:396px" %)TFFS:EXT_DEBT(1.0).OBS_VALUE
	758	+|(% style="width:250px" %)(((
	759	+*Category Scheme
	760	+)))|(% style="width:444px" %)categorySchemeAgencyId:
	761	+categorySchemeId(version)|(% style="width:396px" %)IMF:SDDS(1.0)
	762	+|(% style="width:250px" %)Category|(% style="width:444px" %)categorySchemeAgencyId:
	763	+categorySchemeId(version).
	764	+categoryId.categoryId categoryId.categoryId etc.|(% style="width:396px" %)(((
819	819	IMF:SDDS(1.0):
820		-
821	821	level_1_category.level_2_category …
822	822	)))
823		-|(((
824		-*Reporting
825		-
826		-Taxonomy
827		-)))|reportingTaxonomyAgencyId: reportingTaxonomyId(version)| IMF:REP_1(1.0)
828		-|ReportingCategory|reportingTaxonomyAgencyId: reportingTaxonomyId(version) reportingcategoryId.reportingcategoryId|(((
	768	+|(% style="width:250px" %)(((
	769	+*Reporting Taxonomy
	770	+)))|(% style="width:444px" %)reportingTaxonomyAgencyId: reportingTaxonomyId(version)|(% style="width:396px" %) IMF:REP_1(1.0)
	771	+|(% style="width:250px" %)ReportingCategory|(% style="width:444px" %)reportingTaxonomyAgencyId: reportingTaxonomyId(version) reportingcategoryId.reportingcategoryId|(% style="width:396px" %)(((
829	829	IMF:REP_1(1.0):
830		-
831	831	level_1_repcategory.level_2_repcategory …
832	832	)))
833		-|*Categorisation|categorisationAgencyId: categorisationId(version)|IMF:cat001(1.0)
834		-|(((
835		-*Organisation
	775	+|(% style="width:250px" %)*Categorisation|(% style="width:444px" %)categorisationAgencyId: categorisationId(version)|(% style="width:396px" %)IMF:cat001(1.0)
	776	+|(% style="width:250px" %)(((
	777	+*Organisation Unit Scheme
	778	+)))|(% style="width:444px" %)organisationUnitSchemeAgencyId: organisationUnitSchemeId(version)|(% style="width:396px" %)ECB:ORGANISATIONS(1.0)
	779	+|(% style="width:250px" %)Organisation Unit|(% style="width:444px" %)organisationUnitSchemeAgencyId: organisationUnitSchemeId(version). organisationUnitId|(% style="width:396px" %)ECB:ORGANISATIONS(1.0).1F
	780	+|(% style="width:250px" %)*AgencyScheme|(% style="width:444px" %)agencySchemeAgencyId: agencySchemeId(version)|(% style="width:396px" %)ECB:AGENCIES(1.0)
836	836
837		-Unit Scheme
838		-)))|organisationUnitSchemeAgencyId: organisationUnitSchemeId(version)|ECB:ORGANISATIONS(1.0)
839		-|Organisation Unit|organisationUnitSchemeAgencyId: organisationUnitSchemeId(version). organisationUnitId|ECB:ORGANISATIONS(1.0).1F
840		-|*AgencyScheme|agencySchemeAgencyId: agencySchemeId(version)|ECB:AGENCIES(1.0)
841		-
842		-
843		-
844		-|Agency|agencySchemeAgencyId: agencySchemeId(version). agencyId|ECB:AGENCY(1.0).AA
845		-|(((
846		-*DataProvider
847		-
848		-Scheme
849		-)))|dataProviderSchemeAgencyId: dataProviderSchemeId(version)|SDMX:DATA_PROVIDERS(1.0)
850		-|DataProvider|dataProviderSchemeAgencyId: dataProviderSchemeId(version) dataProviderId|SDMX:DATA_PROVIDERS(1.0).PROVIDER_1
851		-|(((
852		-*DataConsumer
853		-
854		-Scheme
855		-)))|dataConsumerSchemeAgencyId: dataConsumerSchemeId(version)|SDMX:DATA_CONSUMERS(1.0)
856		-|Data Consumer|dataConsumerSchemeAgencyId: dataConsumerSchemeId(version) dataConsumerId|SDMX:DATA_CONSUMERS(1.0).CONSUMER_1
857		-|(((
858		-*Metadata
859		-
860		-Structure
861		-)))|MSDAgencyId:MSDId(version)|IMF:SDDS_MSD(1.0)
862		-|MetadataTarget|(((
	782	+|(% style="width:262px" %)Agency|(% style="width:369px" %)agencySchemeAgencyId: agencySchemeId(version). agencyId|(% style="width:1262px" %)ECB:AGENCY(1.0).AA
	783	+|(% style="width:262px" %)(((
	784	+*DataProvider Scheme
	785	+)))|(% style="width:369px" %)dataProviderSchemeAgencyId: dataProviderSchemeId(version)|(% style="width:1262px" %)SDMX:DATA_PROVIDERS(1.0)
	786	+|(% style="width:262px" %)DataProvider|(% style="width:369px" %)dataProviderSchemeAgencyId: dataProviderSchemeId(version) dataProviderId|(% style="width:1262px" %)SDMX:DATA_PROVIDERS(1.0).PROVIDER_1
	787	+|(% style="width:262px" %)(((
	788	+*DataConsumer Scheme
	789	+)))|(% style="width:369px" %)dataConsumerSchemeAgencyId: dataConsumerSchemeId(version)|(% style="width:1262px" %)SDMX:DATA_CONSUMERS(1.0)
	790	+|(% style="width:262px" %)Data Consumer|(% style="width:369px" %)dataConsumerSchemeAgencyId: dataConsumerSchemeId(version) dataConsumerId|(% style="width:1262px" %)SDMX:DATA_CONSUMERS(1.0).CONSUMER_1
	791	+|(% style="width:262px" %)(((
	792	+*Metadata Structure
	793	+)))|(% style="width:369px" %)MSDAgencyId:MSDId(version)|(% style="width:1262px" %)IMF:SDDS_MSD(1.0)
	794	+|(% style="width:262px" %)MetadataTarget|(% style="width:369px" %)(((
863	863	MSDAgencyId:
864		-
865	865	MSDId(version).metadataTargetId
866		-)))|IMF:SDDS_MSD(1.0).AGENCY
867		-|(((
	797	+)))|(% style="width:1262px" %)IMF:SDDS_MSD(1.0).AGENCY
	798	+|(% style="width:262px" %)(((
868	868	Dimension
869		-
870	870	DescriptorValues
871		-
872	872	Target
873		-)))|(((
	802	+)))|(% style="width:369px" %)(((
874	874	MSDAgencyId: MSDId(version).
875		-
876	876	metadataTargetId.keyDescriptorValueTargetId
877		-)))|IMF:SDDS_MSD(1.0).AGENCY.KEY
878		-|Identifiable ObjectTarget|(((
	805	+)))|(% style="width:1262px" %)IMF:SDDS_MSD(1.0).AGENCY.KEY
	806	+|(% style="width:262px" %)Identifiable Object Target|(% style="width:369px" %)(((
	807	+MSDAgencyId: MSDId(version).metadataTargetId.identifiableObjectTargetId
	808	+)))|(% style="width:1262px" %)IMF:SDDS_MSD(1.0).AGENCY.STR-OBJECT
	809	+|(% style="width:262px" %)DataSetTarget|(% style="width:369px" %)(((
879	879	MSDAgencyId:
	811	+MSDId(version).metadataTargetId.dataSetTargetId
	812	+)))|(% style="width:1262px" %)IMF:SDDS_MSD(1.0).AGENCY.D1101
	813	+|(% style="width:262px" %)PeportPeriod Target|(% style="width:369px" %)(((
	814	+MSDAgencyId: MSDId(version).metadataTargetId.reportPeriodTargetId
	815	+)))|(% style="width:1262px" %)IMF:SDDS_MSD(1.0).AGENCY.REP_PER
880	880
881		-MSDId(version).metadataTargetId.identifiable
882		-
883		-ObjectTargetId
884		-)))|IMF:SDDS_MSD(1.0).AGENCY.STR-OBJECT
885		-|DataSetTarget|(((
886		-MSDAgencyId:
887		-
888		-MSDId(version).metadataTargetId.dataSet
889		-
890		-TargetId
891		-)))|IMF:SDDS_MSD(1.0).AGENCY.D1101
892		-|PeportPeriod Target|(((
893		-MSDAgencyId:
894		-
895		-MSDId(version).metadataTargetId.reportPeriod
896		-
897		-TargetId
898		-)))|IMF:SDDS_MSD(1.0).AGENCY.REP_PER
899		-
900		-
901		-
902		-|(((
	817	+|(% style="width:251px" %)(((
903	903	ReportStructure
904	904
905	905
906		-)))|(((
907		-MSDAgencyId:
908		-
909		-MSDId(version).reportStructureId
910		-)))|IMF:SDDS_MSD(1.0).AGENCY_REPORT
911		-|(((
	821	+)))|(% style="width:442px" %)(((
	822	+MSDAgencyId: MSDId(version).reportStructureId
	823	+)))|(% style="width:1178px" %)IMF:SDDS_MSD(1.0).AGENCY_REPORT
	824	+|(% style="width:251px" %)(((
912	912	Metadata
913	913
914	914	Attribute
915		-)))|(((
916		-MSDAgencyId:
917		-
918		-MSDId(version).reportStructureId.metadataattri buteID
919		-)))|IMF:SDDS_MSD(1.0).AGENCY_REPORT.COMPILATION
920		-|*Dataflow|dataflowAgencyId: dataflowId(version)|TFFS:CRED_EXT_DEBT(1.0)
921		-|*Provision Agreement|(((
	828	+)))|(% style="width:442px" %)(((
	829	+MSDAgencyId: MSDId(version).reportStructureId.metadataattri buteID
	830	+)))|(% style="width:1178px" %)IMF:SDDS_MSD(1.0).AGENCY_REPORT.COMPILATION
	831	+|(% style="width:251px" %)*Dataflow|(% style="width:442px" %)dataflowAgencyId: dataflowId(version)|(% style="width:1178px" %)TFFS:CRED_EXT_DEBT(1.0)
	832	+|(% style="width:251px" %)*Provision Agreement|(% style="width:442px" %)(((
922	922	provisionAgreementAgencyId:provisionAgreem entId(version)
923		-
924		-
925		-)))|(((
	834	+)))|(% style="width:1178px" %)(((
926	926	TFFS:CRED_EXT_DEBT_AB(1.0)
927		-
928		-
929		-
930	930	)))
931		-|(((
	837	+|(% style="width:251px" %)(((
932	932	*Content
933	933
934	934	Constraint
935		-)))|constraintAgencyId:ContentConstraintId(versio n)|TFFS:CREDITOR_DATA_CONTENT(1.0)
936		-|(((
	841	+)))|(% style="width:442px" %)constraintAgencyId:ContentConstraintId(versio n)|(% style="width:1178px" %)TFFS:CREDITOR_DATA_CONTENT(1.0)
	842	+|(% style="width:251px" %)(((
937	937	*Attachment
938	938
939	939	Constraint
940		-)))|(((
	846	+)))|(% style="width:442px" %)(((
941	941	constraintAgencyId:
942	942
943	943	attachmentConstraintId(version)
944		-)))|TFFS:CREDITOR_DATA_ATTACHMENT_CONSTRAINT_ONE(1.0)
945		-|*Metadataflow|metadataflowAgencyId: metadataflowId(version)|IMF:SDDS_FLOW(1.0)
946		-|*StructureSet|structureSetAgencyId: structureSetId(version)|SDMX:BOP_STRUCTURES(1.0)
947		-|StructureMap|structureSetAgencyId: structureSetId(version). structureMapId|SDMX:BOP_STRUCTURES(1.0).TABLE1_TABLE2
948		-|Component Map|(((
	850	+)))|(% style="width:1178px" %)TFFS:CREDITOR_DATA_ATTACHMENT_CONSTRAINT_ONE(1.0)
	851	+|(% style="width:251px" %)*Metadataflow|(% style="width:442px" %)metadataflowAgencyId: metadataflowId(version)|(% style="width:1178px" %)IMF:SDDS_FLOW(1.0)
	852	+|(% style="width:251px" %)*StructureSet|(% style="width:442px" %)structureSetAgencyId: structureSetId(version)|(% style="width:1178px" %)SDMX:BOP_STRUCTURES(1.0)
	853	+|(% style="width:251px" %)StructureMap|(% style="width:442px" %)structureSetAgencyId: structureSetId(version). structureMapId|(% style="width:1178px" %)SDMX:BOP_STRUCTURES(1.0).TABLE1_TABLE2
	854	+|(% style="width:251px" %)Component Map|(% style="width:442px" %)(((
949	949	structureSetAgencyId: structureSetId(version).
950	950
951	951	structureMapId. componentMapId
952		-)))|SDMX:BOP_STRUCTURES(1.0).TABLE1_TABLE2. REFAREA_REPCOUNTRY
953		-|CodelistMap|structureSetAgencyId: structureSetId(version). codelistMapId|SDMX:BOP_STRUCTURES(1.0).CLREFAREA_CLREPCOUNTRY
954		-|CodeMap|structureSetAgencyId: structureSetId(version).|SDMX:BOP_STRUCTURES(1.0).CLREFAREA_CLREPCOUNTRY. DE_GER
	858	+)))|(% style="width:1178px" %)SDMX:BOP_STRUCTURES(1.0).TABLE1_TABLE2. REFAREA_REPCOUNTRY
	859	+|(% style="width:251px" %)CodelistMap|(% style="width:442px" %)structureSetAgencyId: structureSetId(version). codelistMapId|(% style="width:1178px" %)SDMX:BOP_STRUCTURES(1.0).CLREFAREA_CLREPCOUNTRY
	860	+|(% style="width:251px" %)CodeMap|(% style="width:442px" %)structureSetAgencyId: structureSetId(version).|(% style="width:1178px" %)SDMX:BOP_STRUCTURES(1.0).CLREFAREA_CLREPCOUNTRY. DE_GER
955	955
956		-
957		-
958	958	| |(((
959	959	codeListMapId.
960	960
...	...	@@ -1062,7 +1062,6 @@
1062	1062
1063	1063	7**Table 3: Table of identification components for SDMX Identifiable Artefacts**
1064	1064
1065		-
1066	1066	= 7 Implementation Notes =
1067	1067
1068	1068	== 7.1 Structural Definition Metadata ==
...	...	@@ -1083,109 +1083,72 @@
1083	1083
1084	1084	The following table lists the Maintainable Artefacts.
1085	1085
1086		-|(% colspan="4" %)**Maintainable Artefacts**|(% colspan="2" %)**Content**|
1087		-|(% colspan="2" %)**Abstract Class**|(% colspan="2" %)**Concrete Class**|(% colspan="2" %) |
1088		-|(% colspan="2" %)Item Scheme|(% colspan="2" %)Codelist|(% colspan="2" %)Code|
1089		-|(% colspan="2" %) |(% colspan="2" %)Concept Scheme|(% colspan="2" %)Concept|
1090		-|(% colspan="2" %) |(% colspan="2" %)Category Scheme|(% colspan="2" %)Category|
1091		-|(% colspan="2" %) |(% colspan="2" %)Organisation Unit Scheme|(% colspan="2" %)Organisation Unit|
1092		-|(% colspan="2" %) |(% colspan="2" %)Agency Scheme|(% colspan="2" %)Agency|
1093		-|(% colspan="2" %) |(% colspan="2" %)Data Provider Scheme|(% colspan="2" %)Data Provider|
1094		-|(% colspan="2" %) |(% colspan="2" %)Data Consumer Scheme|(% colspan="2" %)Data Consumer|
1095		-|(% colspan="2" %) |(% colspan="2" %)Reporting Taxonomy|(% colspan="2" %)Reporting Category|
1096		-|(% colspan="2" %) |(% colspan="2" %)Transformation Scheme|(% colspan="2" %)Transformation|
1097		-|(% colspan="2" %) |(% colspan="2" %)Custom Type Scheme|(% colspan="2" %)Custom Type|
1098		-| |(% colspan="4" %)**Maintainable Artefacts**|(% colspan="2" %)**Content**
1099		-| |(% colspan="2" %)**Abstract Class**|(% colspan="2" %)**Concrete Class**|(% colspan="2" %)
1100		-| |(% colspan="2" %) |(% colspan="2" %)Name Personalisation Scheme|(% colspan="2" %)Name Personalisation
1101		-| |(% colspan="2" %) |(% colspan="2" %)Vtl Mapping Scheme|(% colspan="2" %)Vtl Codelist Mapping
1102		-| |(% colspan="2" %) |(% colspan="2" %) |(% colspan="2" %)Vtl Concept Mapping
1103		-| |(% colspan="2" %) |(% colspan="2" %) |(% colspan="2" %)Vtl Dataflow Mapping
1104		-| |(% colspan="2" %) |(% colspan="2" %) |(% colspan="2" %)(((
1105		-Vtl Concept Scheme
1106		-
1107		-Mapping
1108		-)))
1109		-| |(% colspan="2" %) |(% colspan="2" %)Ruleset Scheme|(% colspan="2" %)Ruleset
1110		-| |(% colspan="2" %) |(% colspan="2" %)User Defined Operator Scheme|(% colspan="2" %)User Defined Operator
1111		-| |(% colspan="2" %) |(% colspan="2" %) |(% colspan="2" %)
1112		-| |(% colspan="2" %)Structure|(% colspan="2" %)Data Structure Definition|(% colspan="2" %)(((
	989	+(% style="width:640.294px" %)
	990	+|(% colspan="2" rowspan="1" style="width:186px" %)**Maintainable Artefacts**|(% style="width:206px" %)**Content**
	991	+|(% style="width:171px" %)**Abstract Class**|(% style="width:232px" %)**Concrete Class**|(% style="width:206px" %)
	992	+|(% style="width:171px" %)Item Scheme|(% style="width:232px" %)Codelist|(% style="width:206px" %)Code
	993	+|(% style="width:171px" %) |(% style="width:232px" %)Concept Scheme|(% style="width:206px" %)Concept
	994	+|(% style="width:171px" %) |(% style="width:232px" %)Category Scheme|(% style="width:206px" %)Category
	995	+|(% style="width:171px" %) |(% style="width:232px" %)Organisation Unit Scheme|(% style="width:206px" %)Organisation Unit
	996	+|(% style="width:171px" %) |(% style="width:232px" %)Agency Scheme|(% style="width:206px" %)Agency
	997	+|(% style="width:171px" %) |(% style="width:232px" %)Data Provider Scheme|(% style="width:206px" %)Data Provider
	998	+|(% style="width:171px" %) |(% style="width:232px" %)Data Consumer Scheme|(% style="width:206px" %)Data Consumer
	999	+|(% style="width:171px" %) |(% style="width:232px" %)Reporting Taxonomy|(% style="width:206px" %)Reporting Category
	1000	+|(% style="width:171px" %) |(% style="width:232px" %)Transformation Scheme|(% style="width:206px" %)Transformation
	1001	+|(% style="width:171px" %) |(% style="width:232px" %)Custom Type Scheme|(% style="width:206px" %)Custom Type
	1002	+|(% style="width:171px" %) |(% style="width:232px" %)Name Personalisation Scheme|(% style="width:206px" %)Name Personalisation
	1003	+|(% style="width:171px" %) |(% style="width:232px" %)Vtl Mapping Scheme|(% style="width:206px" %)Vtl Codelist Mapping
	1004	+|(% style="width:171px" %) |(% style="width:232px" %) |(% style="width:206px" %)Vtl Dataflow Mapping
	1005	+|(% style="width:171px" %) |(% style="width:232px" %) |(% style="width:206px" %)Vtl Concept Scheme Mapping
	1006	+|(% style="width:171px" %) |(% style="width:232px" %)Ruleset Scheme|(% style="width:206px" %)Ruleset
	1007	+|(% style="width:171px" %) |(% style="width:232px" %)User Defined Operator Scheme|(% style="width:206px" %)User Defined Operator
	1008	+|(% style="width:171px" %) |(% style="width:232px" %) |(% style="width:206px" %)User Defined Operator
	1009	+|(% style="width:171px" %)Structure|(% style="width:232px" %)Data Structure Definition|(% style="width:206px" %)(((
1113	1113	Dimension Descriptor
1114		-
1115	1115	Group Dimension
1116		-
1117	1117	Descriptor
1118		-
1119	1119	Dimension
1120		-
1121	1121	Measure Dimension
1122		-
1123	1123	Time Dimension
1124		-
1125	1125	Attribute Descriptor
1126		-
1127	1127	Data Attribute
1128		-
1129	1129	Measure Descriptor
1130		-
1131	1131	Primary Measure
1132	1132	)))
1133		-| |(% colspan="2" %) |(% colspan="2" %)Metadata Structure Definition|(% colspan="2" %)(((
1134		-Metadata Target,
1135		-
1136		-Dimension Descriptor
1137		-
	1021	+|(% style="width:171px" %) |(% style="width:232px" %)Metadata Structure Definition|(% style="width:206px" %)(((
	1022	+Metadata Target, Dimension Descriptor
1138	1138	Values Target Identifiable
1139		-
1140	1140	Object Target
1141		-
1142	1142	Report Period Target
1143		-
1144	1144	Data SetTarget
1145		-
1146	1146	Report Structure
1147		-
1148	1148	Metadata Attribute
1149	1149	)))
1150		-| |(% colspan="2" %)Structure Usage|(% colspan="2" %)Dataflow Definition|(% colspan="2" %)
1151		-| |(% colspan="2" %) |(% colspan="2" %)Metadataflow Definition|(% colspan="2" %)
1152		-| |(% colspan="2" %)None|(% colspan="2" %)Process|(% colspan="2" %)Process Step
1153		-| |(% colspan="2" %)None|(% colspan="2" %)Structure Set|(% colspan="2" %)(((
	1030	+|(% style="width:171px" %)Structure Usage|(% style="width:232px" %)Dataflow Definition|(% style="width:206px" %)
	1031	+|(% style="width:171px" %) |(% style="width:232px" %)Metadataflow Definition|(% style="width:206px" %)
	1032	+|(% style="width:171px" %)None|(% style="width:232px" %)Process|(% style="width:206px" %)Process Step
	1033	+|(% style="width:171px" %)None|(% style="width:232px" %)Structure Set|(% style="width:206px" %)(((
1154	1154	Component Map
1155		-
1156	1156	Concept Scheme Map
1157		-
1158	1158	Codelist Map
1159		-
1160	1160	Category Scheme Map
1161		-
1162	1162	Reporting Taxonomy Map
1163		-
1164	1164	Organisation Scheme Map
1165		-
1166	1166	Concept Map
1167		-
1168	1168	Code Map
1169		-
1170	1170	Category Map
1171		-
1172	1172	Organisation Map
1173		-
1174	1174	Reporting Category Map
1175		-
1176	1176	Hybrid Codelist Map
1177		-
1178	1178	Hybrid Code Map
1179	1179	)))
1180		-| |(% colspan="2" %)None|(% colspan="2" %)Provision Agreement|(% colspan="2" %)
1181		-| |(% colspan="2" %)None|(% colspan="2" %)Hierarchical Codelist|(% colspan="2" %)(((
	1048	+|(% style="width:171px" %)None|(% style="width:232px" %)Provision Agreement|(% style="width:206px" %)
	1049	+|(% style="width:171px" %)None|(% style="width:232px" %)Hierarchical Codelist|(% style="width:206px" %)(((
1182	1182	Hierarchy
1183		-
1184	1184	Hierarchical Code
1185	1185	)))
1186		-| | | | | | |
1187	1187
1188		-**Table 4: Table of Maintainable Artefacts for Structural Definition Metadata**
	1054	+**able 4: Table of Maintainable Artefacts for Structural Definition Metadata**
1189	1189
1190	1190	=== 7.1.2 Item Scheme, Structure ===
1191	1191
...	...	@@ -1192,10 +1192,7 @@
1192	1192	The artefacts included in the structural definitions are:
1193	1193
1194	1194	* All types of Item Scheme (Codelist, Concept Scheme, Category Scheme, Organisation Scheme - Agency Scheme, Data Provider Scheme, Data Consumer Scheme, Organisation Unit Scheme)
1195		-* All types of Structure (Data Structure Definition, Metadata Structure
1196		-
1197		-Definition)
1198		-
	1061	+* All types of Structure (Data Structure Definition, Metadata Structure Definition)
1199	1199	* All types of Structure Usage (Dataflow Definition, Metadataflow Definition)
1200	1200
1201	1201	=== 7.1.3 Structure Usage ===
...	...	@@ -1214,6 +1214,8 @@
1214	1214
1215	1215	==== 7.1.3.3 Structure Usage Model ====
1216	1216
	1080	+[[image:1747829078194-749.png]]
	1081	+
1217	1217	**Figure 10: SDMX-IM of links from Structure Usage to Category**
1218	1218
1219	1219	In addition to the maintenance of the Dataflow Definition and the Metadataflow Definition the following links must be maintained in the registry:
...	...	@@ -1240,10 +1240,10 @@
1240	1240
1241	1241	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.
1242	1242
	1108	+[[image:1747829109466-595.png]]
1243	1243
1244	1244	**Figure 11: SDMX-IM of the Data Provider**
1245	1245
1246		-
1247	1247	Note that the Data Provider does not inherit the hierarchy association. The diagram below shows a logical schematic of the data model classes required to maintain provision agreements
1248	1248
1249	1249	[[image:1747824123019-181.jpeg]]
...	...	@@ -1252,8 +1252,10 @@
1252	1252
1253	1253	The diagram below is a logical representation of the data required in order to maintain Provision Agreements.
1254	1254
	1120	+[[image:1747829139951-378.png]]
1255	1255
1256		-==== Figure 13: Logical class diagram of the information contained in the Provision Agreement ====
	1122	+(% class="wikigeneratedid" id="HFigure13:LogicalclassdiagramoftheinformationcontainedintheProvisionAgreement" %)
	1123	+**Figure 13: Logical class diagram of the information contained in the Provision Agreement**
1257	1257
1258	1258	A Provision Agreement is structural metadata. Each Provision Agreement must reference a Data Provider and a Dataflow or Metadataflow Definition. The Data Provider and the Dataflow/Metadataflow Definition must exist already in order to set up a Provision Agreement.
1259	1259
...	...	@@ -1281,13 +1281,12 @@
1281	1281
1282	1282	=== 7.3.3 Data and Metadata Constraints: Model ===
1283	1283
	1151	+[[image:1747829204737-370.png]]
1284	1284
	1153	+**Figure 15: Logical class diagram showing inheritance between and reference to constrainable artifacts**
1285	1285
1286		-==== Figure 15: Logical class diagram showing inheritance between and reference to constrainable artifacts ====
	1155	+The class diagram above shows that DataProvider, DataflowDefinition, MetadataflowDefinition, ProvisionAgreement, DataStructureDefinition, MetadataStructureDefinition, SimpleDatasource and QueryDatasource are all concrete sub-classes of ConstrainableArtefact and can therefore have Constraints specified. Note that the actual Constraint as submitted is associated to the reference classes which inherit from ConstrainableRef: these are used to refer to the classes to which the Constraint applies.
1287	1287
1288		-The class diagram above shows that DataProvider, DataflowDefinition, MetadataflowDefinition, ProvisionAgreement, DataStructureDefinition, MetadataStructureDefinition, SimpleDatasource and QueryDatasource are all concrete sub-classes of ConstrainableArtefact and can therefore have Constraints specified. Note that the actual Constraint as submitted is associated to the reference classes which inherit from ConstrainableRef: these are used to refer to the classes to which the Constraint applies.
1289		-
1290		-
1291	1291	The content of the Constraint can be found in the SDMX Information Model document.
1292	1292
1293	1293	== 7.4 Data and Metadata Registration ==
...	...	@@ -1322,11 +1322,14 @@
1322	1322
1323	1323	The Registration has an action attribute which takes one of the following values:
1324	1324
1325		-|**Action Attribute Value**|**Behaviour**
1326		-|Append|Add this Registration to the registry
1327		-|Replace|Replace the existing Registration with identified by the id in the Registration of the Submit Registration Request
1328		-|Delete|Delete the existing Registration identified by the id in the Registration of the Submit Registration Request
	1191	+(% style="width:970.294px" %)
	1192	+|(% style="width:212px" %)**Action Attribute Value**|(% style="width:756px" %)**Behaviour**
	1193	+|(% style="width:212px" %)Append|(% style="width:756px" %)Add this Registration to the registry
	1194	+|(% style="width:212px" %)Replace|(% style="width:756px" %)Replace the existing Registration with identified by the id in the Registration of the Submit Registration Request
	1195	+|(% style="width:212px" %)Delete|(% style="width:756px" %)Delete the existing Registration identified by the id in the Registration of the Submit Registration Request
1329	1329
	1197	+[[image:1747829290890-122.png]]
	1198	+
1330	1330	**Figure 17: Logical Class Diagram of Registration of Data and Metadata**
1331	1331
1332	1332	The Query Datasource is an abstract class that represents a data source which can understand an SDMX-ML query (SOAPDatasource) or RESTful query
...	...	@@ -1341,25 +1341,19 @@
1341	1341
1342	1342	Information in the data or metadata set is extracted and placed in one or more Content Constraints (see the Constraints model in the SDMX Information Model – Section 2 of the SDMX Standards). The information to be extracted is indicated by the Boolean values set on the Provision Agreement as shown in the table below.
1343	1343
1344		-|**Indexing Required**|**Registration Process Activity**
1345		-|indexTimeSeries|Extract all the series keys and create a KeySet(s) Constraint.
1346		-|indexDataSet|(((
1347		-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
1348		-
1349		-Regions containing Member Selections of Dimension Components of the Constraints model in the SDMX-IM, and the associated Selection Value.
	1213	+|(% style="width:185px" %)**Indexing Required**|(% style="width:1686px" %)**Registration Process Activity**
	1214	+|(% style="width:185px" %)indexTimeSeries|(% style="width:1686px" %)Extract all the series keys and create a KeySet(s) Constraint.
	1215	+|(% style="width:185px" %)indexDataSet|(% style="width:1686px" %)(((
	1216	+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.
1350	1350	)))
1351		-|indexReportingPeriod|(((
	1218	+|(% style="width:185px" %)indexReportingPeriod|(% style="width:1686px" %)(((
1352	1352	This applies only to a registered dataset.
1353		-
1354	1354	Extract the Reporting Begin and Reporting End from the Header of the Message containing the data set, and create a Reference Period constraint.
1355	1355	)))
1356		-|indexAttributes|(((
	1222	+|(% style="width:185px" %)indexAttributes|(% style="width:1686px" %)(((
1357	1357	**Data Set**
1358		-
1359	1359	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
1360		-
1361	1361	**Metadata Set**
1362		-
1363	1363	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.
1364	1364	)))
1365	1365
...	...	@@ -1369,14 +1369,13 @@
1369	1369
1370	1370	=== 7.4.3 Registration Response ===
1371	1371
1372		-After a registration request has been submitted to the registry, a response is returned to the submitter indicating success or failure. Given that a registration request can hold many Registrations, then there must be a registration status for each Registration. The Submit Registration class has a status field which is either set to
	1235	+After a registration request has been submitted to the registry, a response is returned to the submitter indicating success or failure. Given that a registration request can hold many Registrations, then there must be a registration status for each Registration. The Submit Registration class has a status field which is either set to “Success”, “Warning” or “Failure”.
1373	1373
1374		-“Success”, “Warning” or “Failure”.
1375		-
1376	1376	If the registration has succeeded, a Registration will be returned - this holds the Registry-allocated Id of the newly registered Datasource plus a Datasource holding the URL to access the dataset, metadataset, or query service.
1377	1377
1378	1378	The Registration Response returns set of registration status (one for each registration submitted) in terms of a Status Message (this is common to all Registry Responses) that indicates success or failure. In the event of registration failure, a set of Message Text are returned, giving the error messages that occurred during registration. It is entirely possible when registering a batch of datasets, that the response will contain some successful and some failed statuses. The logical model for the Registration Response is shown below:
1379	1379
	1241	+[[image:1747829477882-750.png]]
1380	1380
1381	1381	**Figure 18: Logical class diagram showing the registration response**
1382	1382
...	...	@@ -1386,15 +1386,12 @@
1386	1386
1387	1387	A user can submit a subscription in the registry that defines which events are of interest, and either an email and/or an HTTP address to which a notification of qualifying events will be delivered. The subscription will be identified in the registry by a URN which is returned to the user when the subscription is created. If the user wants to delete the subscription at a later point, the subscription URN is used as identification. Subscriptions have a validity period expressed as a date range (startDate, endDate) and the registry may delete any expired subscriptions, and will notify the subscriber on expiry.
1388	1388
1389		-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
	1251	+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”.
1390	1390
1391		-“notification”.
	1253	+=== 7.5.1Subscription Logical Class Diagram ===
1392	1392
1393		- 7.5.1Subscription Logical Class Diagram
	1255	+[[image:1747829554603-150.png]]
1394	1394
1395		-
1396		-[[image:1747824123028-257.png]]
1397		-
1398	1398	**Figure 19: Logical Class Diagram of the Subscription**
1399	1399
1400	1400	=== 7.5.2 Subscription Information ===
...	...	@@ -1401,73 +1401,58 @@
1401	1401
1402	1402	Regardless of the type of registry/repository events being observed, a subscription always contains:
1403	1403
1404		-~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.
	1263	+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.
	1264	+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.
	1265	+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.
	1266	+1. A selector which specifies which type of events are of interest. The set of event types is:
1405	1405
1406		-2. A user-defined identifier which is returned in the response to the subscription request. This helps with asynchronous processing and is NOT stored in the Registry.
	1268	+|(% style="width:327px" %)**Event Type**|(% style="width:1545px" %)**Comment**
	1269	+|(% style="width:327px" %)STRUCTURAL_REPOSITORY_EVENTS|(% style="width:1545px" %)Life-cycle changes to Maintainable Artefacts in the structural metadata repository.
	1270	+|(% style="width:327px" %)DATA_REGISTRATION_EVENTS|(% style="width:1545px" %)Whenever a published dataset is registered. This can be either a SDMXML data file or an SDMX conformant database.
	1271	+|(% style="width:327px" %)METADATA_REGISTRATION_EVENTS|(% style="width:1545px" %)Whenever a published metadataset is registered. This can be either a SDMXML reference metadata file or an SDMX conformant database.
	1272	+|(% style="width:327px" %)ALL_EVENTS|(% style="width:1545px" %)All events of the specified EventType
1407	1407
1408		-3. A validity period which defines both when the subscription becomes active and expires. The subscriber may be sent a notification on expiration of the subscription.
1409		-
1410		-4. A selector which specifies which type of events are of interest. The set of event types is:
1411		-
1412		-|**Event Type**|**Comment**
1413		-|STRUCTURAL_REPOSITORY_EVENTS|Life-cycle changes to Maintainable Artefacts in the structural metadata repository.
1414		-|DATA_REGISTRATION_EVENTS|Whenever a published dataset is registered. This can be either a SDMXML data file or an SDMX conformant database.
1415		-|METADATA_REGISTRATION_EVENTS|Whenever a published metadataset is registered. This can be either a SDMXML reference metadata file or an SDMX conformant database.
1416		-|ALL_EVENTS|All events of the specified EventType
1417		-
1418	1418	=== 7.5.3 Wildcard Facility ===
1419	1419
1420	1420	Subscription notification supports wildcarded identifier components URNs, which are identiiers which have some or all of their component parts replaced by the wildcard character `%`. Identifier components comprise:
1421	1421
1422		- agencyID
	1278	+* agencyID
	1279	+* id
	1280	+* version
1423	1423
1424		- id
1425		-
1426		- version
1427		-
1428	1428	Examples of wildcarded identifier components for an identified object type of Codelist are shown below.
1429	1429
1430		-AgencyID = %
1431		-
	1284	+//AgencyID = %
1432	1432	Id = %
	1286	+Version = %//
1433	1433
1434		-Version = %
1435		-
1436	1436	This subscribes to all Codelists of all versions for all agencies.
1437	1437
1438		-AgencyID = AGENCY1
1439		-
	1290	+//AgencyID = AGENCY1
1440	1440	Id = CODELIST1
	1292	+Version = %//
1441	1441
1442		-Version = %
1443		-
1444	1444	This subscribes to all versions of Codelist CODELIST1 maintained by the agency
1445	1445
1446		-AGENCY1
1447		-
	1296	+//AGENCY1
1448	1448	AgencyID = AGENCY1
1449		-
1450	1450	Id = %
	1299	+Version = %//
1451	1451
1452		-Version = %
1453		-
1454	1454	This subscribes to all versions of all Codelist objects maintained by the agency
1455	1455
1456		-AGENCY1
1457		-
	1303	+//AGENCY1
1458	1458	AgencyID = %
1459		-
1460	1460	Id = CODELIST1
	1306	+Version = %//
1461	1461
1462		-Version = %
1463		-
1464	1464	This subscribes to all versions of Codelist CODELIST1 maintained by the agency
1465	1465
1466		-AGENCY1
	1310	+//AGENCY1//
1467	1467
1468	1468	Note that if the subscription is to the latest version then this can be achieved by the * character
1469	1469
1470		-i.e. Version = *
	1314	+//i.e. Version = *//
1471	1471
1472	1472	Note that a subscription using the URN mechanism cannot use wildcard characters.
1473	1473
...	...	@@ -1479,16 +1479,15 @@
1479	1479
1480	1480	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:
1481	1481
	1326	+|(% style="width:405px" %)**Selector**|(% style="width:1467px" %)**Comment**
	1327	+|(% style="width:405px" %)DataProvider|(% style="width:1467px" %)Any datasets or metadata sets registered by the specified data provider will activate the notification.
	1328	+|(% style="width:405px" %)ProvisionAgreement|(% style="width:1467px" %)Any datasets or metadata sets registered for the provision agreement will activate the notification.
	1329	+|(% style="width:405px" %)Dataflow (&Metadataflow)|(% style="width:1467px" %)Any datasets or metadata sets registered for the specified dataflow (or metadataflow) will activate the notification.
	1330	+|(% style="width:405px" %)DataStructureDefinition & MetadataStructureDefinition|(% style="width:1467px" %)Any datasets or metadata sets registered for those dataflows (or metadataflows) that are based on the specified Data Structure Definition will
	1331	+|(% style="width:405px" %)**Selector**|(% style="width:1467px" %)**Comment**
	1332	+|(% style="width:405px" %) |(% style="width:1467px" %)activate the notification.
	1333	+|(% style="width:405px" %)Category|(% style="width:1467px" %)Any datasets or metadata sets registered for those dataflows, metadataflows, provision agreements that are categorised by the category.
1482	1482
1483		-|**Selector**|**Comment**
1484		-|DataProvider|Any datasets or metadata sets registered by the specified data provider will activate the notification.
1485		-|ProvisionAgreement|Any datasets or metadata sets registered for the provision agreement will activate the notification.
1486		-|Dataflow (&Metadataflow)|Any datasets or metadata sets registered for the specified dataflow (or metadataflow) will activate the notification.
1487		-|DataStructureDefinition & MetadataStructureDefinition|Any datasets or metadata sets registered for those dataflows (or metadataflows) that are based on the specified Data Structure Definition will
1488		-|**Selector**|**Comment**
1489		-| |activate the notification.
1490		-|Category|Any datasets or metadata sets registered for those dataflows, metadataflows, provision agreements that are categorised by the category.
1491		-
1492	1492	The event will also capture the semantic of the registration: deletion or replacement of an existing registration or a new registration.
1493	1493
1494	1494	== 7.6 Notification ==
...	...	@@ -1495,8 +1495,10 @@
1495	1495
1496	1496	=== 7.6.1 Logical Class Diagram ===
1497	1497
	1341	+[[image:1747829675568-610.png]]
1498	1498
1499		-==== Figure 20: Logical Class Diagram of the Notification ====
	1343	+(% class="wikigeneratedid" id="HFigure20:LogicalClassDiagramoftheNotification" %)
	1344	+**Figure 20: Logical Class Diagram of the Notification**
1500	1500
1501	1501	A notification is an XML document that is sent to a user via email or http POST whenever a subscription is activated. It is an asynchronous one-way message.
1502	1502
...	...	@@ -1516,5 +1516,3 @@
1516	1516	=== 7.6.3 Registration Event Component ===
1517	1517
1518	1518	The notification will contain the Registration.
1519		-
1520		-

1747829078194-749.png

Author

...	...	@@ -1,0 +1,1 @@
	1	+xwiki:XWiki.helena

Size

...	...	@@ -1,0 +1,1 @@
	1	+40.4 KB

Content

1747829109466-595.png

Author

...	...	@@ -1,0 +1,1 @@
	1	+xwiki:XWiki.helena

Size

...	...	@@ -1,0 +1,1 @@
	1	+30.4 KB

Content

1747829139951-378.png

Author

...	...	@@ -1,0 +1,1 @@
	1	+xwiki:XWiki.helena

Size

...	...	@@ -1,0 +1,1 @@
	1	+21.1 KB

Content

1747829204737-370.png

Author

...	...	@@ -1,0 +1,1 @@
	1	+xwiki:XWiki.helena

Size

...	...	@@ -1,0 +1,1 @@
	1	+55.8 KB

Content

1747829290890-122.png

Author

...	...	@@ -1,0 +1,1 @@
	1	+xwiki:XWiki.helena

Size

...	...	@@ -1,0 +1,1 @@
	1	+41.4 KB

Content

1747829477882-750.png

Author

...	...	@@ -1,0 +1,1 @@
	1	+xwiki:XWiki.helena

Size

...	...	@@ -1,0 +1,1 @@
	1	+24.6 KB

Content

1747829554603-150.png

Author

...	...	@@ -1,0 +1,1 @@
	1	+xwiki:XWiki.helena

Size

...	...	@@ -1,0 +1,1 @@
	1	+99.1 KB

Content

1747829675568-610.png

Author

...	...	@@ -1,0 +1,1 @@
	1	+xwiki:XWiki.helena

Size

...	...	@@ -1,0 +1,1 @@
	1	+31.1 KB

Content