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,11 +470,11 @@
470	470
471	471	An example of this is shown in the XML snippet below.
472	472
	472	+[[image:1747824123013-196.jpeg||height="309" width="446"]]
473	473
474		-[[image:1747824123013-196.jpeg]]
	474	+(% class="wikigeneratedid" id="HFigure8:ExampleShowingUseofAgencyIdentifiers" %)
	475	+**Figure 8: Example Showing Use of Agency Identifiers**
475	475
476		-==== Figure 8: Example Showing Use of Agency Identifiers ====
477		-
478	478	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.
479	479
480	480	=== 6.2.2 Universal Resource Name (URN) ===
...	...	@@ -503,7 +503,7 @@
503	503
504	504	In the explanation below the actual object that is the target of the URN is called the **//actual object//**.
505	505
506		-**SDMXPrefix:** urn:sdmx:org.
	505	+**SDMXPrefix:** urn:sdmx:org.
507	507
508	508	**SDMX-IM package name:** sdmx.infomodel.package=
509	509
...	...	@@ -513,10 +513,8 @@
513	513
514	514	**(maintainable-object-version)** is the version of the maintainable object and is enclosed in round brackets (). It will always be present.
515	515
516		-**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.
517	517
518		-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.
519		-
520	520	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.
521	521
522	522	For example the sequence is agency:DSDid(version).DimensionId and not agency:DSDid(version).DimensionDescriptorId.DimensionId.
...	...	@@ -523,58 +523,57 @@
523	523
524	524	**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.
525	525
526		-===== //Generic Examples of the URN Structure// =====
	523	+===== __**//Generic Examples of the URN Structure//**__ =====
527	527
	525	+__Actual object is a maintainable__
528	528
529		-Actual object is a maintainable
	527	+> SDMXPrefix.SDMX-IM package name.classname=agency id:maintained-object-id(version)
530	530
531		-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__
532	532
533		-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
534	534
535		-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__
536	536
537		-Actual object is contained in a maintained object with an intermediate containing object
	535	+> SDMXPrefix.SDMX-IM package name.classname=agency
538	538
539		-SDMXPrefix.SDMX-IM package name.classname=agency
540		-
541	541	id:maintained-object-id(version).contained-object-id.object-id
542	542
543		-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__
544	544
545	545	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
546	546
547		-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
548	548
549		-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__
550	550
551	551	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
552	552
553		-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
554	554
555		-===== //Concrete Examples of the URN Structure// =====
	551	+===== __**//Concrete Examples of the URN Structure//**__ =====
556	556
557	557	The Data Structure Definition CRED_EXT_DEBT version 1.0 maintained by the top level Agency TFFS would have the URN:
558	558
559		-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)
560	560
561	561	The URN for a code for Argentina maintained by ISO in the code list CL_3166A2 version 1.0 would be:
562	562
563		-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
564	564
565	565	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:
566	566
567		-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
568	568
569	569	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
570	570
571	571	CONTACT_DETAILS/CONTACT_NAME would be:
572	572
573		-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
574	574
575	575	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:
576	576
577		-urn:sdmx:org.sdmx.infomodel.datastructure.Dataflow=TFFS.ABC:EX
	573	+> urn:sdmx:org.sdmx.infomodel.datastructure.Dataflow=TFFS.ABC:EX
578	578
579	579	TERNAL_DEBT(1.0)
580	580
...	...	@@ -589,112 +589,94 @@
589	589
590	590	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.
591	591
592		-|**Package**|(((
593		-**URN Classname (model classname**
594		-
595		-**where this is different)**
	588	+|(% style="width:127px" %)**Package**|(% style="width:1745px" %)(((
	589	+**URN Classname (model classname where this is different)**
596	596	)))
597		-|base|Agency
598		-| |OrganisationUnitScheme
599		-| |AgencyScheme
600		-| |DataProviderScheme
601		-| |DataConsumerScheme
602		-| |OrganisationUnit
603		-| |DataProvider
604		-| |DataConsumer
605		-| |
606		-|datastructure|DataStructure (DataStructureDefinition)
607		-| |AttributeDescriptor
608		-| |DataAttribute
609		-| |GroupDimensionDescriptor
610		-| |DimensionDescriptor
611		-| |Dimension
612		-| |MeasureDimension
613		-| |TimeDimension
614		-| |MeasureDescriptor
615		-| |PrimaryMeasure
616		-| |Dataflow (DataflowDefinition)
617		-| |
618		-|metadatastructure|MetadataTarget
619		-| |DimensionDescriptorValueTarget
620		-| |IdentifiableObjectTarget
621		-| |ReportPeriodTarget
622		-| |DataSetTarget
623		-| |ReportStructure
624		-| |MetadataAttribute
625		-| |(((
	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" %)(((
626	626	MetadataStructure
627	627
628	628	(MetadataStructureDefinition)
629	629	)))
630		-| |Metadataflow (MetadataflowDefinition)
631		-| |
632		-|process|Process
633		-| |ProcessStep
634		-| |Transition
635		-| |
636		-|registry|ProvisionAgreement
637		-| |AttachmentConstraint
638		-| |ContentConstraint
639		-| |Subscription
640		-| |
641		-|mapping|StructureMap
642		-| |StructureSet
643		-| |ComponentMap
644		-|**Package**|(((
645		-**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
646	646
647		-**where this is different)**
648		-)))
649		-| |ConceptSchemeMap
650		-| |OrganisationSchemeMap
651		-| |CodelistMap
652		-| |CategorySchemeMap
653		-| |ReportingTaxonomyMap
654		-| |ConceptMap
655		-| |OrganisationMap
656		-| |CodeMap
657		-| |HybridCodelistMap
658		-| |CategoryMap
659		-| |HybridCodeMap
660		-| |ReportingCategoryMap
661		-| |
662		-|codelist|Codelist
663		-| |HierarchicalCodelist
664		-| |Hierarchy
665		-| |Hierarchy
666		-| |Code
667		-| |HierarchicalCode
668		-| |Level
669		-| |
670		-|categoryscheme|CategoryScheme
671		-| |Category
672		-| |Categorisation
673		-| |ReportingTaxonomy
674		-| |ReportingCategory
675		-| |
676		-|conceptscheme|ConceptScheme
677		-| |Concept
678		-| |
679		-|transformation|TransformationScheme
680		-| |Transformation
681		-| |CustomTypeScheme
682		-| |CustomType
683		-| |NamePersonalisationScheme
684		-| |NamePersonalisation
685		-| |VtlCodelistMapping
686		-| |VtlConceptMapping
687		-| |VtlDataflowMapping
688		-| |VtlConceptSchemeMapping
689		-| |RulesetScheme
690		-| |Ruleset
691		-| |UserDefinedOperatorScheme
692		-| |UserDefinedOperator
693		-| |
694		-
695	695	**Table 2: SDMX-IM Packages and Contained Classes**
696	696
697		-
698	698	=== 6.2.4 URN Identification components of SDMX objects ===
699	699
700	700	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.
...	...	@@ -703,78 +703,52 @@
703	703
704	704	Note that for brevity the URN examples omit the prefix. All URNs have the prefix
705	705
706		-urn:sdmx.org.sdmx.infomodel.{package}.{classname}=
	684	+> urn:sdmx.org.sdmx.infomodel.{package}.{classname}=
707	707
708		-
709		-|**SDMX Class**|**Key attribute(s)**|**Example of URN**
710		-|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" %)(((
711	711	IMF
712		-
713		-
714	714	Sub agency in the IMF AGENCIES
715		-
716		-
717	717	IMF.SubAgency1
718	718	)))
719		-|*ConceptScheme|conceptSchemeAgencyId:conceptSchemeId(ve rsion)|SDMX:CROSS_DOMAIN_CONCEPTS(1.0)
720		-|Concept|(((
721		-conceptSchemeAgencyId:
722		-
723		-conceptSchemeId(version).conceptId
724		-)))|SDMX:CROSS_DOMAIN_CONCEPTS(1.0).FREQ
725		-|*Codelist|codeListAgencyId:codeListId(version)|SDMX:CL_FREQ(1.0)
726		-|Code|codeListAgencyId:codelistId(version).codeId|(((
727		-SDMX:CL_FREQ(1.0).Q
728		-
729		-
	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" %))
730	730	)))
731		-
732		-
733		-
734		-|(((
735		-*Hierarchical
736		-
737		-Codelist
738		-)))|hierachicalCodelistAgencyId: hierarchicalCodelistId(version)|(((
739		-UNESCO:CL_EXP_SOURCE(1.0)
740		-
741		-
742		-)))
743		-|Hierarchy|(((
	703	+|(% style="width:250px" %)Hierarchy|(% style="width:444px" %)(((
744	744	hierachicalcodeListAgencyId:
745		-
746	746	hierarchicalcodelistId(version).Hierarchy
747		-)))|UNESCO:CL_EXP_SOURCE(1.0). H-C-GOV
748		-|Level|(((
	706	+)))|(% style="width:396px" %)UNESCO:CL_EXP_SOURCE(1.0).
	707	+H-C-GOV
	708	+|(% style="width:250px" %)Level|(% style="width:444px" %)(((
749	749	hierachicalcodeListAgencyId:
750		-
751	751	hierarchicalcodelistId(version).Hierarchy.Level
752		-)))|(((
	711	+)))|(% style="width:396px" %)(((
753	753	ESTAT:HCL_REGION(1.0).H_1.COUNTRY
754	754
755	755
756	756	)))
757		-|HierarchicalCode|hierachicalCodeListAgencyId: hierarchicalcodelistId(version).hierarchy.hierarc hicalCode|UNESCO:CL_EXP_SOURCE(1.0). H-C-GOV.GOV_CODE1
758		-|*DataStructure|dataStructureDefintitionAgencyId: dataStructureDefintitionId(version)|TFFS:EXT_DEBT(1.0)
759		-|(((
	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" %)(((
760	760	Dimension
761		-
762	762	Descriptor
763		-
764	764	Measure
765		-
766	766	Descriptor
767		-
768	768	Attribute
769		-
770	770	Descriptor
771		-)))|(((
	725	+)))|(% style="width:444px" %)(((
772	772	dataStructureDefinitionAgencyId: dataStructureDefinitionId(version).
773		-
774	774	componentListId
775		-
776	776	where the componentListId is the name of the class (there is only one occurrence of each in the Data Structure Definition)
777		-)))|(((
	729	+)))|(% style="width:396px" %)(((
778	778	TFFS:EXT_DEBT(1.0).DimensionDescriptor
779	779
780	780	TFFS:EXT_DEBT(1.0).MeasureDescriptor
...	...	@@ -781,181 +781,132 @@
781	781
782	782	TFFS:EXT_DEBT(1.0).AttributeDescriptor
783	783	)))
784		-|(((
	736	+|(% style="width:250px" %)(((
785	785	GroupDimension
786		-
787	787	Descriptor
788		-)))|(((
	739	+)))|(% style="width:444px" %)(((
789	789	dataStructureDefinitionAgencyId: dataStructureDefinitionId(version).
790		-
791	791	groupDimensionDescriptorId
792		-)))|TFFS:EXT_DEBT(1.0).SIBLING
793		-|Dimension|(((
	742	+)))|(% style="width:396px" %)TFFS:EXT_DEBT(1.0).SIBLING
	743	+|(% style="width:250px" %)Dimension|(% style="width:444px" %)(((
794	794	dataStructureDefinitionAgencyId: dataStructureDefinition (version).
795		-
796	796	dimensionId
797		-)))|TFFS:EXT_DEBT(1.0).FREQ
798		-|TimeDimension|(((
	746	+)))|(% style="width:396px" %)TFFS:EXT_DEBT(1.0).FREQ
	747	+|(% style="width:250px" %)TimeDimension|(% style="width:444px" %)(((
799	799	dataStructureDefinitionAgencyId: dataStructureDefinition (version).
800		-
801	801	timeDimensionId
802		-)))|TFFS:EXT_DEBT(1.0).TIME_PERIOD
803		-|Measure Dimension|dataStructureDefinitionAgencyId: dataStructureDefinition (version).|TFFS:EXT_DEBT(1.0).STOCK_FLOW
804		-
805		-
806		-
807		-| |measureDimensionId|
808		-|DataAttrribute|dataStructureDefinitionAgencyId: dataStructureDefinition (version). dataAttributeId|TFFS:EXT_DEBT(1.0).OBS_STATUS
809		-|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" %)(((
810	810	dataStructureDefinitionAgencyId: dataStructureDefinition (version).
811		-
812	812	primaryMeasureId
813		-)))|TFFS:EXT_DEBT(1.0).OBS_VALUE
814		-|(((
815		-*Category
816		-
817		-Scheme
818		-)))|categorySchemeAgencyId: categorySchemeId(version)|IMF:SDDS(1.0)
819		-|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" %)(((
820	820	IMF:SDDS(1.0):
821		-
822	822	level_1_category.level_2_category …
823	823	)))
824		-|(((
825		-*Reporting
826		-
827		-Taxonomy
828		-)))|reportingTaxonomyAgencyId: reportingTaxonomyId(version)| IMF:REP_1(1.0)
829		-|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" %)(((
830	830	IMF:REP_1(1.0):
831		-
832	832	level_1_repcategory.level_2_repcategory …
833	833	)))
834		-|*Categorisation|categorisationAgencyId: categorisationId(version)|IMF:cat001(1.0)
835		-|(((
836		-*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)
837	837
838		-Unit Scheme
839		-)))|organisationUnitSchemeAgencyId: organisationUnitSchemeId(version)|ECB:ORGANISATIONS(1.0)
840		-|Organisation Unit|organisationUnitSchemeAgencyId: organisationUnitSchemeId(version). organisationUnitId|ECB:ORGANISATIONS(1.0).1F
841		-|*AgencyScheme|agencySchemeAgencyId: agencySchemeId(version)|ECB:AGENCIES(1.0)
842		-
843		-
844		-
845		-|Agency|agencySchemeAgencyId: agencySchemeId(version). agencyId|ECB:AGENCY(1.0).AA
846		-|(((
847		-*DataProvider
848		-
849		-Scheme
850		-)))|dataProviderSchemeAgencyId: dataProviderSchemeId(version)|SDMX:DATA_PROVIDERS(1.0)
851		-|DataProvider|dataProviderSchemeAgencyId: dataProviderSchemeId(version) dataProviderId|SDMX:DATA_PROVIDERS(1.0).PROVIDER_1
852		-|(((
853		-*DataConsumer
854		-
855		-Scheme
856		-)))|dataConsumerSchemeAgencyId: dataConsumerSchemeId(version)|SDMX:DATA_CONSUMERS(1.0)
857		-|Data Consumer|dataConsumerSchemeAgencyId: dataConsumerSchemeId(version) dataConsumerId|SDMX:DATA_CONSUMERS(1.0).CONSUMER_1
858		-|(((
859		-*Metadata
860		-
861		-Structure
862		-)))|MSDAgencyId:MSDId(version)|IMF:SDDS_MSD(1.0)
863		-|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" %)(((
864	864	MSDAgencyId:
865		-
866	866	MSDId(version).metadataTargetId
867		-)))|IMF:SDDS_MSD(1.0).AGENCY
868		-|(((
	797	+)))|(% style="width:1262px" %)IMF:SDDS_MSD(1.0).AGENCY
	798	+|(% style="width:262px" %)(((
869	869	Dimension
870		-
871	871	DescriptorValues
872		-
873	873	Target
874		-)))|(((
	802	+)))|(% style="width:369px" %)(((
875	875	MSDAgencyId: MSDId(version).
876		-
877	877	metadataTargetId.keyDescriptorValueTargetId
878		-)))|IMF:SDDS_MSD(1.0).AGENCY.KEY
879		-|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" %)(((
880	880	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
881	881
882		-MSDId(version).metadataTargetId.identifiable
883		-
884		-ObjectTargetId
885		-)))|IMF:SDDS_MSD(1.0).AGENCY.STR-OBJECT
886		-|DataSetTarget|(((
887		-MSDAgencyId:
888		-
889		-MSDId(version).metadataTargetId.dataSet
890		-
891		-TargetId
892		-)))|IMF:SDDS_MSD(1.0).AGENCY.D1101
893		-|PeportPeriod Target|(((
894		-MSDAgencyId:
895		-
896		-MSDId(version).metadataTargetId.reportPeriod
897		-
898		-TargetId
899		-)))|IMF:SDDS_MSD(1.0).AGENCY.REP_PER
900		-
901		-
902		-
903		-|(((
	817	+|(% style="width:251px" %)(((
904	904	ReportStructure
905	905
906	906
907		-)))|(((
908		-MSDAgencyId:
909		-
910		-MSDId(version).reportStructureId
911		-)))|IMF:SDDS_MSD(1.0).AGENCY_REPORT
912		-|(((
	821	+)))|(% style="width:442px" %)(((
	822	+MSDAgencyId: MSDId(version).reportStructureId
	823	+)))|(% style="width:1178px" %)IMF:SDDS_MSD(1.0).AGENCY_REPORT
	824	+|(% style="width:251px" %)(((
913	913	Metadata
914	914
915	915	Attribute
916		-)))|(((
917		-MSDAgencyId:
918		-
919		-MSDId(version).reportStructureId.metadataattri buteID
920		-)))|IMF:SDDS_MSD(1.0).AGENCY_REPORT.COMPILATION
921		-|*Dataflow|dataflowAgencyId: dataflowId(version)|TFFS:CRED_EXT_DEBT(1.0)
922		-|*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" %)(((
923	923	provisionAgreementAgencyId:provisionAgreem entId(version)
924		-
925		-
926		-)))|(((
	834	+)))|(% style="width:1178px" %)(((
927	927	TFFS:CRED_EXT_DEBT_AB(1.0)
928		-
929		-
930		-
931	931	)))
932		-|(((
	837	+|(% style="width:251px" %)(((
933	933	*Content
934	934
935	935	Constraint
936		-)))|constraintAgencyId:ContentConstraintId(versio n)|TFFS:CREDITOR_DATA_CONTENT(1.0)
937		-|(((
	841	+)))|(% style="width:442px" %)constraintAgencyId:ContentConstraintId(versio n)|(% style="width:1178px" %)TFFS:CREDITOR_DATA_CONTENT(1.0)
	842	+|(% style="width:251px" %)(((
938	938	*Attachment
939	939
940	940	Constraint
941		-)))|(((
	846	+)))|(% style="width:442px" %)(((
942	942	constraintAgencyId:
943	943
944	944	attachmentConstraintId(version)
945		-)))|TFFS:CREDITOR_DATA_ATTACHMENT_CONSTRAINT_ONE(1.0)
946		-|*Metadataflow|metadataflowAgencyId: metadataflowId(version)|IMF:SDDS_FLOW(1.0)
947		-|*StructureSet|structureSetAgencyId: structureSetId(version)|SDMX:BOP_STRUCTURES(1.0)
948		-|StructureMap|structureSetAgencyId: structureSetId(version). structureMapId|SDMX:BOP_STRUCTURES(1.0).TABLE1_TABLE2
949		-|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" %)(((
950	950	structureSetAgencyId: structureSetId(version).
951	951
952	952	structureMapId. componentMapId
953		-)))|SDMX:BOP_STRUCTURES(1.0).TABLE1_TABLE2. REFAREA_REPCOUNTRY
954		-|CodelistMap|structureSetAgencyId: structureSetId(version). codelistMapId|SDMX:BOP_STRUCTURES(1.0).CLREFAREA_CLREPCOUNTRY
955		-|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
956	956
957		-
958		-
959	959	| |(((
960	960	codeListMapId.
961	961
...	...	@@ -1063,7 +1063,6 @@
1063	1063
1064	1064	7**Table 3: Table of identification components for SDMX Identifiable Artefacts**
1065	1065
1066		-
1067	1067	= 7 Implementation Notes =
1068	1068
1069	1069	== 7.1 Structural Definition Metadata ==
...	...	@@ -1084,109 +1084,72 @@
1084	1084
1085	1085	The following table lists the Maintainable Artefacts.
1086	1086
1087		-|(% colspan="4" %)**Maintainable Artefacts**|(% colspan="2" %)**Content**|
1088		-|(% colspan="2" %)**Abstract Class**|(% colspan="2" %)**Concrete Class**|(% colspan="2" %) |
1089		-|(% colspan="2" %)Item Scheme|(% colspan="2" %)Codelist|(% colspan="2" %)Code|
1090		-|(% colspan="2" %) |(% colspan="2" %)Concept Scheme|(% colspan="2" %)Concept|
1091		-|(% colspan="2" %) |(% colspan="2" %)Category Scheme|(% colspan="2" %)Category|
1092		-|(% colspan="2" %) |(% colspan="2" %)Organisation Unit Scheme|(% colspan="2" %)Organisation Unit|
1093		-|(% colspan="2" %) |(% colspan="2" %)Agency Scheme|(% colspan="2" %)Agency|
1094		-|(% colspan="2" %) |(% colspan="2" %)Data Provider Scheme|(% colspan="2" %)Data Provider|
1095		-|(% colspan="2" %) |(% colspan="2" %)Data Consumer Scheme|(% colspan="2" %)Data Consumer|
1096		-|(% colspan="2" %) |(% colspan="2" %)Reporting Taxonomy|(% colspan="2" %)Reporting Category|
1097		-|(% colspan="2" %) |(% colspan="2" %)Transformation Scheme|(% colspan="2" %)Transformation|
1098		-|(% colspan="2" %) |(% colspan="2" %)Custom Type Scheme|(% colspan="2" %)Custom Type|
1099		-| |(% colspan="4" %)**Maintainable Artefacts**|(% colspan="2" %)**Content**
1100		-| |(% colspan="2" %)**Abstract Class**|(% colspan="2" %)**Concrete Class**|(% colspan="2" %)
1101		-| |(% colspan="2" %) |(% colspan="2" %)Name Personalisation Scheme|(% colspan="2" %)Name Personalisation
1102		-| |(% colspan="2" %) |(% colspan="2" %)Vtl Mapping Scheme|(% colspan="2" %)Vtl Codelist Mapping
1103		-| |(% colspan="2" %) |(% colspan="2" %) |(% colspan="2" %)Vtl Concept Mapping
1104		-| |(% colspan="2" %) |(% colspan="2" %) |(% colspan="2" %)Vtl Dataflow Mapping
1105		-| |(% colspan="2" %) |(% colspan="2" %) |(% colspan="2" %)(((
1106		-Vtl Concept Scheme
1107		-
1108		-Mapping
1109		-)))
1110		-| |(% colspan="2" %) |(% colspan="2" %)Ruleset Scheme|(% colspan="2" %)Ruleset
1111		-| |(% colspan="2" %) |(% colspan="2" %)User Defined Operator Scheme|(% colspan="2" %)User Defined Operator
1112		-| |(% colspan="2" %) |(% colspan="2" %) |(% colspan="2" %)
1113		-| |(% 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" %)(((
1114	1114	Dimension Descriptor
1115		-
1116	1116	Group Dimension
1117		-
1118	1118	Descriptor
1119		-
1120	1120	Dimension
1121		-
1122	1122	Measure Dimension
1123		-
1124	1124	Time Dimension
1125		-
1126	1126	Attribute Descriptor
1127		-
1128	1128	Data Attribute
1129		-
1130	1130	Measure Descriptor
1131		-
1132	1132	Primary Measure
1133	1133	)))
1134		-| |(% colspan="2" %) |(% colspan="2" %)Metadata Structure Definition|(% colspan="2" %)(((
1135		-Metadata Target,
1136		-
1137		-Dimension Descriptor
1138		-
	1021	+|(% style="width:171px" %) |(% style="width:232px" %)Metadata Structure Definition|(% style="width:206px" %)(((
	1022	+Metadata Target, Dimension Descriptor
1139	1139	Values Target Identifiable
1140		-
1141	1141	Object Target
1142		-
1143	1143	Report Period Target
1144		-
1145	1145	Data SetTarget
1146		-
1147	1147	Report Structure
1148		-
1149	1149	Metadata Attribute
1150	1150	)))
1151		-| |(% colspan="2" %)Structure Usage|(% colspan="2" %)Dataflow Definition|(% colspan="2" %)
1152		-| |(% colspan="2" %) |(% colspan="2" %)Metadataflow Definition|(% colspan="2" %)
1153		-| |(% colspan="2" %)None|(% colspan="2" %)Process|(% colspan="2" %)Process Step
1154		-| |(% 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" %)(((
1155	1155	Component Map
1156		-
1157	1157	Concept Scheme Map
1158		-
1159	1159	Codelist Map
1160		-
1161	1161	Category Scheme Map
1162		-
1163	1163	Reporting Taxonomy Map
1164		-
1165	1165	Organisation Scheme Map
1166		-
1167	1167	Concept Map
1168		-
1169	1169	Code Map
1170		-
1171	1171	Category Map
1172		-
1173	1173	Organisation Map
1174		-
1175	1175	Reporting Category Map
1176		-
1177	1177	Hybrid Codelist Map
1178		-
1179	1179	Hybrid Code Map
1180	1180	)))
1181		-| |(% colspan="2" %)None|(% colspan="2" %)Provision Agreement|(% colspan="2" %)
1182		-| |(% 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" %)(((
1183	1183	Hierarchy
1184		-
1185	1185	Hierarchical Code
1186	1186	)))
1187		-| | | | | | |
1188	1188
1189		-**Table 4: Table of Maintainable Artefacts for Structural Definition Metadata**
	1054	+**able 4: Table of Maintainable Artefacts for Structural Definition Metadata**
1190	1190
1191	1191	=== 7.1.2 Item Scheme, Structure ===
1192	1192
...	...	@@ -1193,10 +1193,7 @@
1193	1193	The artefacts included in the structural definitions are:
1194	1194
1195	1195	* All types of Item Scheme (Codelist, Concept Scheme, Category Scheme, Organisation Scheme - Agency Scheme, Data Provider Scheme, Data Consumer Scheme, Organisation Unit Scheme)
1196		-* All types of Structure (Data Structure Definition, Metadata Structure
1197		-
1198		-Definition)
1199		-
	1061	+* All types of Structure (Data Structure Definition, Metadata Structure Definition)
1200	1200	* All types of Structure Usage (Dataflow Definition, Metadataflow Definition)
1201	1201
1202	1202	=== 7.1.3 Structure Usage ===
...	...	@@ -1215,6 +1215,8 @@
1215	1215
1216	1216	==== 7.1.3.3 Structure Usage Model ====
1217	1217
	1080	+[[image:1747829078194-749.png]]
	1081	+
1218	1218	**Figure 10: SDMX-IM of links from Structure Usage to Category**
1219	1219
1220	1220	In addition to the maintenance of the Dataflow Definition and the Metadataflow Definition the following links must be maintained in the registry:
...	...	@@ -1241,10 +1241,10 @@
1241	1241
1242	1242	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.
1243	1243
	1108	+[[image:1747829109466-595.png]]
1244	1244
1245	1245	**Figure 11: SDMX-IM of the Data Provider**
1246	1246
1247		-
1248	1248	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
1249	1249
1250	1250	[[image:1747824123019-181.jpeg]]
...	...	@@ -1253,8 +1253,10 @@
1253	1253
1254	1254	The diagram below is a logical representation of the data required in order to maintain Provision Agreements.
1255	1255
	1120	+[[image:1747829139951-378.png]]
1256	1256
1257		-==== 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**
1258	1258
1259	1259	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.
1260	1260
...	...	@@ -1282,13 +1282,12 @@
1282	1282
1283	1283	=== 7.3.3 Data and Metadata Constraints: Model ===
1284	1284
	1151	+[[image:1747829204737-370.png]]
1285	1285
	1153	+**Figure 15: Logical class diagram showing inheritance between and reference to constrainable artifacts**
1286	1286
1287		-==== 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.
1288	1288
1289		-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.
1290		-
1291		-
1292	1292	The content of the Constraint can be found in the SDMX Information Model document.
1293	1293
1294	1294	== 7.4 Data and Metadata Registration ==
...	...	@@ -1323,11 +1323,14 @@
1323	1323
1324	1324	The Registration has an action attribute which takes one of the following values:
1325	1325
1326		-|**Action Attribute Value**|**Behaviour**
1327		-|Append|Add this Registration to the registry
1328		-|Replace|Replace the existing Registration with identified by the id in the Registration of the Submit Registration Request
1329		-|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
1330	1330
	1197	+[[image:1747829290890-122.png]]
	1198	+
1331	1331	**Figure 17: Logical Class Diagram of Registration of Data and Metadata**
1332	1332
1333	1333	The Query Datasource is an abstract class that represents a data source which can understand an SDMX-ML query (SOAPDatasource) or RESTful query
...	...	@@ -1342,25 +1342,19 @@
1342	1342
1343	1343	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.
1344	1344
1345		-|**Indexing Required**|**Registration Process Activity**
1346		-|indexTimeSeries|Extract all the series keys and create a KeySet(s) Constraint.
1347		-|indexDataSet|(((
1348		-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
1349		-
1350		-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.
1351	1351	)))
1352		-|indexReportingPeriod|(((
	1218	+|(% style="width:185px" %)indexReportingPeriod|(% style="width:1686px" %)(((
1353	1353	This applies only to a registered dataset.
1354		-
1355	1355	Extract the Reporting Begin and Reporting End from the Header of the Message containing the data set, and create a Reference Period constraint.
1356	1356	)))
1357		-|indexAttributes|(((
	1222	+|(% style="width:185px" %)indexAttributes|(% style="width:1686px" %)(((
1358	1358	**Data Set**
1359		-
1360	1360	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
1361		-
1362	1362	**Metadata Set**
1363		-
1364	1364	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.
1365	1365	)))
1366	1366
...	...	@@ -1370,14 +1370,13 @@
1370	1370
1371	1371	=== 7.4.3 Registration Response ===
1372	1372
1373		-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”.
1374	1374
1375		-“Success”, “Warning” or “Failure”.
1376		-
1377	1377	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.
1378	1378
1379	1379	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:
1380	1380
	1241	+[[image:1747829477882-750.png]]
1381	1381
1382	1382	**Figure 18: Logical class diagram showing the registration response**
1383	1383
...	...	@@ -1387,15 +1387,12 @@
1387	1387
1388	1388	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.
1389	1389
1390		-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”.
1391	1391
1392		-“notification”.
	1253	+=== 7.5.1Subscription Logical Class Diagram ===
1393	1393
1394		- 7.5.1Subscription Logical Class Diagram
	1255	+[[image:1747829554603-150.png]]
1395	1395
1396		-
1397		-[[image:1747824123028-257.png]]
1398		-
1399	1399	**Figure 19: Logical Class Diagram of the Subscription**
1400	1400
1401	1401	=== 7.5.2 Subscription Information ===
...	...	@@ -1402,73 +1402,58 @@
1402	1402
1403	1403	Regardless of the type of registry/repository events being observed, a subscription always contains:
1404	1404
1405		-~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:
1406	1406
1407		-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
1408	1408
1409		-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.
1410		-
1411		-4. A selector which specifies which type of events are of interest. The set of event types is:
1412		-
1413		-|**Event Type**|**Comment**
1414		-|STRUCTURAL_REPOSITORY_EVENTS|Life-cycle changes to Maintainable Artefacts in the structural metadata repository.
1415		-|DATA_REGISTRATION_EVENTS|Whenever a published dataset is registered. This can be either a SDMXML data file or an SDMX conformant database.
1416		-|METADATA_REGISTRATION_EVENTS|Whenever a published metadataset is registered. This can be either a SDMXML reference metadata file or an SDMX conformant database.
1417		-|ALL_EVENTS|All events of the specified EventType
1418		-
1419	1419	=== 7.5.3 Wildcard Facility ===
1420	1420
1421	1421	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:
1422	1422
1423		- agencyID
	1278	+* agencyID
	1279	+* id
	1280	+* version
1424	1424
1425		- id
1426		-
1427		- version
1428		-
1429	1429	Examples of wildcarded identifier components for an identified object type of Codelist are shown below.
1430	1430
1431		-AgencyID = %
1432		-
	1284	+//AgencyID = %
1433	1433	Id = %
	1286	+Version = %//
1434	1434
1435		-Version = %
1436		-
1437	1437	This subscribes to all Codelists of all versions for all agencies.
1438	1438
1439		-AgencyID = AGENCY1
1440		-
	1290	+//AgencyID = AGENCY1
1441	1441	Id = CODELIST1
	1292	+Version = %//
1442	1442
1443		-Version = %
1444		-
1445	1445	This subscribes to all versions of Codelist CODELIST1 maintained by the agency
1446	1446
1447		-AGENCY1
1448		-
	1296	+//AGENCY1
1449	1449	AgencyID = AGENCY1
1450		-
1451	1451	Id = %
	1299	+Version = %//
1452	1452
1453		-Version = %
1454		-
1455	1455	This subscribes to all versions of all Codelist objects maintained by the agency
1456	1456
1457		-AGENCY1
1458		-
	1303	+//AGENCY1
1459	1459	AgencyID = %
1460		-
1461	1461	Id = CODELIST1
	1306	+Version = %//
1462	1462
1463		-Version = %
1464		-
1465	1465	This subscribes to all versions of Codelist CODELIST1 maintained by the agency
1466	1466
1467		-AGENCY1
	1310	+//AGENCY1//
1468	1468
1469	1469	Note that if the subscription is to the latest version then this can be achieved by the * character
1470	1470
1471		-i.e. Version = *
	1314	+//i.e. Version = *//
1472	1472
1473	1473	Note that a subscription using the URN mechanism cannot use wildcard characters.
1474	1474
...	...	@@ -1480,16 +1480,15 @@
1480	1480
1481	1481	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:
1482	1482
	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.
1483	1483
1484		-|**Selector**|**Comment**
1485		-|DataProvider|Any datasets or metadata sets registered by the specified data provider will activate the notification.
1486		-|ProvisionAgreement|Any datasets or metadata sets registered for the provision agreement will activate the notification.
1487		-|Dataflow (&Metadataflow)|Any datasets or metadata sets registered for the specified dataflow (or metadataflow) will activate the notification.
1488		-|DataStructureDefinition & MetadataStructureDefinition|Any datasets or metadata sets registered for those dataflows (or metadataflows) that are based on the specified Data Structure Definition will
1489		-|**Selector**|**Comment**
1490		-| |activate the notification.
1491		-|Category|Any datasets or metadata sets registered for those dataflows, metadataflows, provision agreements that are categorised by the category.
1492		-
1493	1493	The event will also capture the semantic of the registration: deletion or replacement of an existing registration or a new registration.
1494	1494
1495	1495	== 7.6 Notification ==
...	...	@@ -1496,8 +1496,10 @@
1496	1496
1497	1497	=== 7.6.1 Logical Class Diagram ===
1498	1498
	1341	+[[image:1747829675568-610.png]]
1499	1499
1500		-==== Figure 20: Logical Class Diagram of the Notification ====
	1343	+(% class="wikigeneratedid" id="HFigure20:LogicalClassDiagramoftheNotification" %)
	1344	+**Figure 20: Logical Class Diagram of the Notification**
1501	1501
1502	1502	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.
1503	1503
...	...	@@ -1517,5 +1517,3 @@
1517	1517	=== 7.6.3 Registration Event Component ===
1518	1518
1519	1519	The notification will contain the Registration.
1520		-
1521		-

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