Last modified by Artur on 2025/09/30 13:28

From version 21.12
edited by Helena
on 2025/06/08 16:42
Change comment: There is no comment for this version
To version 21.5
edited by Helena
on 2025/06/08 16:29
Change comment: There is no comment for this version

Summary

Details

Page properties
Content
... ... @@ -191,7 +191,7 @@
191 191  
192 192  The SDMX structural artefacts that may be queried are defined in the SDMX structure web service specification which is compatible with this release of the standard __[[https:~~/~~/github.com/sdmx>>url:https://github.com/sdmx-twg/sdmx-rest/blob/master/doc/structures.md]][[->>url:https://github.com/sdmx-twg/sdmx-rest/blob/master/doc/structures.md]][[twg/sdmx>>url:https://github.com/sdmx-twg/sdmx-rest/blob/master/doc/structures.md]][[->>url:https://github.com/sdmx-twg/sdmx-rest/blob/master/doc/structures.md]][[rest/blob/master/doc/structures.md>>url:https://github.com/sdmx-twg/sdmx-rest/blob/master/doc/structures.md]]__[[url:https://github.com/sdmx-twg/sdmx-rest/blob/master/doc/structures.md]]
193 193  
194 -=== 5.2.4 Data and Reference Metadata Registration Service ===
194 +===== {{id name="_Toc90798"/}}5.2.4 Data and Reference Metadata Registration Service =====
195 195  
196 196  This service must implement the following Registry Interfaces:
197 197  
... ... @@ -214,24 +214,23 @@
214 214  
215 215  The Registration has an action attribute which takes one of the following values:
216 216  
217 -(% style="width:893.835px" %)
218 -|(% style="width:241px" %)**Action Attribute Value**|(% style="width:650px" %)**Behaviour**
219 -|(% style="width:241px" %)Append|(% style="width:650px" %)Add this registration to the registry
220 -|(% style="width:241px" %)Replace|(% style="width:650px" %)Replace the existing Registration with this Registration identified by the id in the Registration of the Submit Registration Request
221 -|(% style="width:241px" %)Delete|(% style="width:650px" %)Delete the existing Registration identified by the id in the Registration of the Submit Registration Request
217 +|**Action Attribute Value**|**Behaviour**
218 +|Append|Add this registration to the registry
219 +|Replace|Replace the existing Registration with this Registration identified by the id in the Registration of the Submit Registration Request
220 +|Delete|Delete the existing Registration identified by the id in the Registration of the Submit Registration Request
222 222  
223 223  The Registration has three Boolean attributes which may be present to determine how an SDMX compliant dataset or metadataset indexing application must index the datasets or metadatasets upon registration. The indexing application behaviour is as follows:
224 224  
225 -(% style="width:896.835px" %)
226 -|**Boolean Attribute**|(% style="width:712px" %)**Behaviour if Value is “true”**
227 -|indexTimeSeries|(% style="width:712px" %)A compliant indexing application must index all the time series keys
228 -|indexDataSet|(% style="width:712px" %)(((
224 +|**Boolean Attribute**|**Behaviour if Value is “true”**
225 +|indexTimeSeries|A compliant indexing application must index all the time series keys
226 +|indexDataSet|(((
229 229  A compliant indexing application must index the range of actual (present) values for each dimension of the Dataset.
228 +
230 230  Note that for data this requires much less storage than full key indexing, but this method cannot guarantee that a specific combination of Dimension values (the Key) is actually present in the Dataset
231 231  )))
232 -|indexReportingPeriod|(% style="width:712px" %)A compliant indexing application must index the time period range(s) for which data are present in the Dataset.
231 +|indexReportingPeriod|A compliant indexing application must index the time period range(s) for which data are present in the Dataset.
233 233  
234 -=== 5.2.5 Data Discovery ===
233 +===== {{id name="_Toc90799"/}}5.2.5 Data Discovery =====
235 235  
236 236  The Data Discovery Service implements the following Registry Interfaces:
237 237  
... ... @@ -238,7 +238,7 @@
238 238  * QueryRegistrationRequest
239 239  * QueryRegistrationResponse
240 240  
241 -=== 5.2.6 Subscription and Notification ===
240 +===== {{id name="_Toc90800"/}}5.2.6 Subscription and Notification =====
242 242  
243 243  The Subscription and Notification Service implements the following Registry Interfaces:
244 244  
... ... @@ -257,32 +257,34 @@
257 257  
258 258  Notification requires that the structural metadata repository and the provisioning metadata repository monitor any event which is of interest to a user (the object of a subscription request query), and to issue an SDMX notification document to the endpoints specified in the relevant subscriptions.
259 259  
260 -=== 5.2.7 Registry Behaviour ===
259 +===== {{id name="_Toc90801"/}}5.2.7 Registry Behaviour =====
261 261  
262 262  The following table defines the behaviour of the SDMX Registry for the various Registry Interface messages. It should be noted, though, that as of SDMX 3.0, an extended versioning scheme newly including semantic versioning is foreseen for all Maintainable Artefacts. Moreover, while the old versioning scheme is allowed, given there is no more a "final" flag, there is no way guaranteeing the consistency across version of a Maintainable, unless semantic versioning is used.
263 263  
264 264  Given the above, the behaviour described in the following table concerns either draft Artefacts using semantic versioning or any Artefacts using the old versioning scheme. Nevertheless, in the case of semantic versioning the registry must respect the versioning rules when performing the actions below. For example, it is not possible to replace a non-draft Artefact that follows semantic versioning, unless a newer version is introduced according to the semantic versioning rules. Furthermore, even when draft Artefacts are submitted, the registry has to verify semantic versioning is respected against the previous non-draft versions. It is worth noting that the rules for semantic versioning and replacing or maintaining semantically versioned Artefacts applies to externally shared Artefacts. This means that any system may internally perform any change within a version of an Artefact, until the latter is shared outside of that system or becomes public. Then (as also explained in the SDMX Standards Section 6 “Technical Notes”) the Artefacts must adhere to the Semantic Versioning rules.
265 265  
266 -(% style="width:982.835px" %)
267 -|(% style="width:217px" %)**Interface**|(% style="width:763px" %)**Behaviour**
268 -|(% style="width:217px" %)All|(% style="width:763px" %)(((
265 +|**Interface**|**Behaviour**
266 +|All|(((
269 269  1. If the action is set to “replace” (or a maintainable Artefact is PUT or POSTed) then the entire contents of the existing maintainable object in the Registry MUST be replaced by the object submitted.
270 270  1. Cross referenced structures MUST exist in either the submitted document (in Structures or Structure Location) or in the registry to which the request is submitted.
271 271  1. If the action is set to “delete” (or a maintainable Artefact is DELETEd) then the Registry MUST verify that the object can be deleted. In order to qualify for deletion, the object must:
272 272  
273 -a) Be a draft version.
274 -b) Not be explicitly^^[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^1^^>>path:#sdfootnote1sym||name="sdfootnote1anc"]](%%)^^ referenced from any other object in the Registry.
271 +1. Be a draft version.
275 275  
273 +b) Not be explicitly^^[[(% class="wikiinternallink wikiinternallink" %)^^1^^>>path:#sdfootnote1sym||name="sdfootnote1anc"]](%%)^^ referenced from any other object in the Registry.
274 +
276 276  4) The semantic versioning rules in the SDMX documentation MUST be obeyed.
277 277  )))
278 -|(% style="width:217px" %)Structure submission|(% style="width:763px" %)(((
279 -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.
277 +|Structure submission|(((
278 +Structures are submitted at the level of the
279 +
280 +Maintainable Artefact and the behaviour in “All” above is therefore at the level of the Maintainable Artefact.
280 280  )))
281 -|(% style="width:217px" %)SubmitRegistrationRequest|(% style="width:763px" %)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. For a queryable datasource the Registry MAY validate that the source exists and can accept an SDMX data query.
282 +|SubmitRegistrationRequest|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. For a queryable datasource the Registry MAY validate that the source exists and can accept an SDMX data query.
282 282  
283 -= 6 Identification of SDMX Objects =
284 += {{id name="_Toc90802"/}}6 Identification of SDMX Objects =
284 284  
285 -== 6.1 Identification, Versioning, and Maintenance ==
286 +=== {{id name="_Toc90803"/}}6.1 Identification, Versioning, and Maintenance ===
286 286  
287 287  All major classes of the SDMX Information model inherit from one of:
288 288  
... ... @@ -291,7 +291,7 @@
291 291  * //**VersionableArtefact**// – this has all of the above features plus a version number, according to the SDMX versioning rules in SDMX Standards Section 6 “Technical Notes”, paragraph “4.3 Versioning”, and a validity period.
292 292  * //**MaintainableArtefact**// – this has all of the above features, plus registry and structure URIs, and an association to the maintenance organisation of the object.
293 293  
294 -=== 6.1.1 Identification, Naming, Versioning, and Maintenance Model ===
295 +===== {{id name="_Toc90804"/}}6.1.1 Identification, Naming, Versioning, and Maintenance Model =====
295 295  
296 296  [[image:SDMX 3.1 Section 5_en_4a9b2cfc.jpg||height="688" width="587"]]
297 297  
... ... @@ -300,11 +300,13 @@
300 300  The table below shows the identification and related data attributes to be stored in a registry for objects that are one of:
301 301  
302 302  * //Annotable//
303 -* //Identifiable//
304 -* //Nameable//
305 -* //Versionable//
306 -* //Maintainable//
307 307  
305 +//Identifiable// • //Nameable//
306 +
307 +• //Versionable//
308 +
309 +• //Maintainable//
310 +
308 308  | |(% colspan="2" %)**Object Type**|(% colspan="2" %)**Data Attributes**|(% colspan="2" %)**Status**|(% colspan="2" %)**Data type**|(% colspan="2" %)**Notes**
309 309  | |(% colspan="2" rowspan="4" %)//Annotable//|(% colspan="2" %)AnnotationTitle|(% colspan="2" %)C|(% colspan="2" %)string|(% colspan="2" %)
310 310  | |(% colspan="2" %)AnnotationType|(% colspan="2" %)C|(% colspan="2" %)string|(% colspan="2" %)
... ... @@ -349,9 +349,9 @@
349 349  
350 350  **Table 1: Common Attributes of Object Types**
351 351  
352 -== 6.2 Unique identification of SDMX objects ==
355 +=== {{id name="_Toc90805"/}}6.2 Unique identification of SDMX objects ===
353 353  
354 -=== 6.2.1 Agencies and Metadata Providers ===
357 +===== {{id name="_Toc90806"/}}6.2.1 Agencies and Metadata Providers =====
355 355  
356 356  The Maintenance Agency in SDMX is maintained in an Agency Scheme which itself is a sub class of Organisation Scheme – this is shown in the class diagram below.
357 357  
... ... @@ -384,11 +384,14 @@
384 384  
385 385  The following organizations maintain an Agency Scheme.
386 386  
387 -* SDMX – contains Agencies AA, BB
388 -* AA – contains Agencies CC, DD
389 -* BB – contains Agencies CC, DD
390 -* DD – Contains Agency EE
390 +• SDMX – contains Agencies AA, BB
391 391  
392 +• AA – contains Agencies CC, DD
393 +
394 +• BB – contains Agencies CC, DD
395 +
396 +• DD – Contains Agency EE
397 +
392 392  Each agency is identified by its full hierarchy excluding SDMX.
393 393  
394 394  e.g., the id of EE as an agencyID is AA.DD.EE
... ... @@ -401,13 +401,13 @@
401 401  
402 402  Following the same principles, the Metadata Provider is the maintenance organisation for a special subset of Maintainable Artefacts, i.e., the Metadatasets; the latter are the containers of reference metadata combined with a target that those metadata refer to.
403 403  
404 -=== 6.2.2 Universal Resource Name (URN) ===
410 +===== {{id name="_Toc90807"/}}6.2.2 Universal Resource Name (URN) =====
405 405  
406 -==== 6.2.2.1 Introduction ====
412 +**6.2.2.1 Introduction**
407 407  
408 408  To provide interoperability between SDMX Registry/Repositories in a distributed network environment, it is important to have a scheme for uniquely identifying (and thus accessing) all first-class (Identifiable) SDMX-IM objects. Most of these unique identifiers are composite (containing maintenance agency, or parent object identifiers), and there is a need to be able to construct a unique reference as a single string. This is achieved by having a globally unique identifier called a universal resource name (URN) which is generated from the actual identification components in the SDMX-RR APIs. In other words, the URN for any Identifiable Artefact is constructed from its component identifiers (agency, id, version etc.).
409 409  
410 -==== 6.2.2.2 URN Structure //__Case Rules for URN__// ====
416 +**6.2.2.2 URN Structure //__Case Rules for URN__//**// //
411 411  
412 412  For the URN, all parts of the string are case sensitive. The generic structure of the URN is as follows:
413 413  
... ... @@ -419,7 +419,7 @@
419 419  
420 420  The Maintenance agency identifier is separated from the maintainable artefact identifier by a colon ‘:’. All other identifiers in the SDMX URN syntax are separated by a period ‘.’. The version information is encapsulated in parentheses ‘()’ and adheres to the SDMX versioning rules, as explained in SDMX Standards Section 6 “Technical Notes”, paragraph “4.3 Versioning.
421 421  
422 -==== 6.2.2.3 Explanation of the generic structure ====
428 +**6.2.2.3 Explanation of the generic structure**
423 423  
424 424  In the explanation below the actual object that is the target of the URN is called the **actual object**.
425 425  
... ... @@ -498,103 +498,103 @@
498 498  
499 499  The SDMX-RR MUST be able to resolve the unique identifier of an SDMX artefact and to produce an SDMX-ML rendering of that artefact if it is located in the Registry.
500 500  
501 -=== 6.2.3 Table of SDMX-IM Packages and Classes ===
507 +===== {{id name="_Toc90808"/}}6.2.3 Table of SDMX-IM Packages and Classes =====
502 502  
503 503  The table below lists all of the packages in the SDMX-IM together with the concrete classes that are in these packages and whose objects have a URN.
504 504  
505 -(% style="width:750.835px" %)
506 -|(% style="width:222px" %)**Package**|(% style="width:526px" %)**URN class name (model class name where this is different)**
507 -|(% style="width:222px" %)base|(% style="width:526px" %)Agency
508 -|(% style="width:222px" %) |(% style="width:526px" %)AgencyScheme
509 -|(% style="width:222px" %) |(% style="width:526px" %)DataConsumer
510 -|(% style="width:222px" %) |(% style="width:526px" %)DataConsumerScheme
511 -|(% style="width:222px" %) |(% style="width:526px" %)DataProvider
512 -|(% style="width:222px" %) |(% style="width:526px" %)DataProviderScheme
513 -|(% style="width:222px" %) |(% style="width:526px" %)MetadataProvider
514 -|(% style="width:222px" %) |(% style="width:526px" %)MetadataProviderScheme
515 -|(% style="width:222px" %) |(% style="width:526px" %)OrganisationUnit
516 -|(% style="width:222px" %) |(% style="width:526px" %)OrganisationUnitScheme
517 -|(% style="width:222px" %) |(% style="width:526px" %)
518 -|(% style="width:222px" %)datastructure|(% style="width:526px" %)AttributeDescriptor
519 -|(% style="width:222px" %) |(% style="width:526px" %)DataAttribute
520 -|(% style="width:222px" %) |(% style="width:526px" %)Dataflow
521 -|(% style="width:222px" %) |(% style="width:526px" %)DataStructure (DataStructureDefinition)
522 -|(% style="width:222px" %) |(% style="width:526px" %)Dimension
523 -|(% style="width:222px" %) |(% style="width:526px" %)DimensionDescriptor
524 -|(% style="width:222px" %) |(% style="width:526px" %)GroupDimensionDescriptor
525 -|(% style="width:222px" %) |(% style="width:526px" %)Measure
526 -|(% style="width:222px" %) |(% style="width:526px" %)MeasureDescriptor
527 -|(% style="width:222px" %) |(% style="width:526px" %)TimeDimension
528 -|(% style="width:222px" %) |(% style="width:526px" %)
529 -|(% style="width:222px" %)metadatastructure|(% style="width:526px" %)MetadataAttribute
530 -|(% style="width:222px" %) |(% style="width:526px" %)MetadataAttributeDescriptor
531 -|(% style="width:222px" %) |(% style="width:526px" %)(((
511 +|**Package**|**URN class name (model class name where this is different)**
512 +|base|Agency
513 +| |AgencyScheme
514 +| |DataConsumer
515 +| |DataConsumerScheme
516 +| |DataProvider
517 +| |DataProviderScheme
518 +| |MetadataProvider
519 +| |MetadataProviderScheme
520 +| |OrganisationUnit
521 +| |OrganisationUnitScheme
522 +| |
523 +|datastructure|AttributeDescriptor
524 +| |DataAttribute
525 +| |Dataflow
526 +| |DataStructure (DataStructureDefinition)
527 +| |Dimension
528 +| |DimensionDescriptor
529 +| |GroupDimensionDescriptor
530 +| |Measure
531 +| |MeasureDescriptor
532 +| |TimeDimension
533 +| |
534 +|metadatastructure|MetadataAttribute
535 +| |MetadataAttributeDescriptor
536 +| |(((
532 532  MetadataStructure
533 533  
534 534  (MetadataStructureDefinition)
535 535  )))
536 536  
542 +:
543 +
537 537  (((
538 -(% style="width:751.835px" %)
539 -|(% style="width:221px" %)**Package**|(% style="width:528px" %)**URN class name (model class name where this is different)**
540 -|(% style="width:221px" %) |(% style="width:528px" %)Metadataflow
541 -|(% style="width:221px" %) |(% style="width:528px" %)MetadataSet
542 -|(% style="width:221px" %) |(% style="width:528px" %)
543 -|(% style="width:221px" %)process|(% style="width:528px" %)Process
544 -|(% style="width:221px" %) |(% style="width:528px" %)ProcessStep
545 -|(% style="width:221px" %) |(% style="width:528px" %)Transition
546 -|(% style="width:221px" %) |(% style="width:528px" %)
547 -|(% style="width:221px" %)registry|(% style="width:528px" %)DataConstraint
548 -|(% style="width:221px" %) |(% style="width:528px" %)MetadataConstraint
549 -|(% style="width:221px" %) |(% style="width:528px" %)MetadataProvisionAgreement
550 -|(% style="width:221px" %) |(% style="width:528px" %)ProvisionAgreement
551 -|(% style="width:221px" %) |(% style="width:528px" %)Subscription
552 -|(% style="width:221px" %) |(% style="width:528px" %)
553 -|(% style="width:221px" %)structuremapping|(% style="width:528px" %)CategorySchemeMap
554 -|(% style="width:221px" %) |(% style="width:528px" %)ConceptSchemeMap
555 -|(% style="width:221px" %) |(% style="width:528px" %)OrganisationSchemeMap
556 -|(% style="width:221px" %) |(% style="width:528px" %)ReportingTaxonomyMap
557 -|(% style="width:221px" %) |(% style="width:528px" %)RepresentationMap
558 -|(% style="width:221px" %) |(% style="width:528px" %)StructureMap
559 -|(% style="width:221px" %) |(% style="width:528px" %)
560 -|(% style="width:221px" %)codelist|(% style="width:528px" %)Code
561 -|(% style="width:221px" %) |(% style="width:528px" %)Codelist
562 -|(% style="width:221px" %) |(% style="width:528px" %)HierarchicalCode
563 -|(% style="width:221px" %) |(% style="width:528px" %)Hierarchy
564 -|(% style="width:221px" %) |(% style="width:528px" %)HierarchyAssociation
565 -|(% style="width:221px" %) |(% style="width:528px" %)Level
566 -|(% style="width:221px" %) |(% style="width:528px" %)ValueList
567 -|(% style="width:221px" %) |(% style="width:528px" %)
568 -|(% style="width:221px" %)categoryscheme|(% style="width:528px" %)Categorisation
569 -|(% style="width:221px" %) |(% style="width:528px" %)Category
570 -|(% style="width:221px" %) |(% style="width:528px" %)CategoryScheme
571 -|(% style="width:221px" %) |(% style="width:528px" %)ReportingCategory
572 -|(% style="width:221px" %) |(% style="width:528px" %)ReportingTaxonomy
573 -|(% style="width:221px" %)**Package**|(% style="width:528px" %)**URN class name (model class name where this is different)**
574 -|(% style="width:221px" %) |(% style="width:528px" %)
575 -|(% style="width:221px" %)conceptscheme|(% style="width:528px" %)Concept
576 -|(% style="width:221px" %) |(% style="width:528px" %)ConceptScheme
577 -|(% style="width:221px" %) |(% style="width:528px" %)
578 -|(% style="width:221px" %)transformation|(% style="width:528px" %)CustomType
579 -|(% style="width:221px" %) |(% style="width:528px" %)CustomTypeScheme
580 -|(% style="width:221px" %) |(% style="width:528px" %)NamePersonalisation
581 -|(% style="width:221px" %) |(% style="width:528px" %)NamePersonalisationScheme
582 -|(% style="width:221px" %) |(% style="width:528px" %)Ruleset
583 -|(% style="width:221px" %) |(% style="width:528px" %)RulesetScheme
584 -|(% style="width:221px" %) |(% style="width:528px" %)Transformation
585 -|(% style="width:221px" %) |(% style="width:528px" %)TransformationScheme
586 -|(% style="width:221px" %) |(% style="width:528px" %)UserDefinedOperator
587 -|(% style="width:221px" %) |(% style="width:528px" %)UserDefinedOperatorScheme
588 -|(% style="width:221px" %) |(% style="width:528px" %)VtlCodelistMapping
589 -|(% style="width:221px" %) |(% style="width:528px" %)VtlConceptMapping
590 -|(% style="width:221px" %) |(% style="width:528px" %)VtlDataflowMapping
591 -|(% style="width:221px" %) |(% style="width:528px" %)VtlMappingScheme
592 -|(% style="width:221px" %) |(% style="width:528px" %)
545 +|**Package**|**URN class name (model class name where this is different)**
546 +| |Metadataflow
547 +| |MetadataSet
548 +| |
549 +|process|Process
550 +| |ProcessStep
551 +| |Transition
552 +| |
553 +|registry|DataConstraint
554 +| |MetadataConstraint
555 +| |MetadataProvisionAgreement
556 +| |ProvisionAgreement
557 +| |Subscription
558 +| |
559 +|structuremapping|CategorySchemeMap
560 +| |ConceptSchemeMap
561 +| |OrganisationSchemeMap
562 +| |ReportingTaxonomyMap
563 +| |RepresentationMap
564 +| |StructureMap
565 +| |
566 +|codelist|Code
567 +| |Codelist
568 +| |HierarchicalCode
569 +| |Hierarchy
570 +| |HierarchyAssociation
571 +| |Level
572 +| |ValueList
573 +| |
574 +|categoryscheme|Categorisation
575 +| |Category
576 +| |CategoryScheme
577 +| |ReportingCategory
578 +| |ReportingTaxonomy
579 +|**Package**|**URN class name (model class name where this is different)**
580 +| |
581 +|conceptscheme|Concept
582 +| |ConceptScheme
583 +| |
584 +|transformation|CustomType
585 +| |CustomTypeScheme
586 +| |NamePersonalisation
587 +| |NamePersonalisationScheme
588 +| |Ruleset
589 +| |RulesetScheme
590 +| |Transformation
591 +| |TransformationScheme
592 +| |UserDefinedOperator
593 +| |UserDefinedOperatorScheme
594 +| |VtlCodelistMapping
595 +| |VtlConceptMapping
596 +| |VtlDataflowMapping
597 +| |VtlMappingScheme
598 +| |
593 593  )))
594 594  
595 595  **Table 2: SDMX-IM Packages and Contained Classes**
596 596  
597 -=== 6.2.4 URN Identification components of SDMX objects ===
603 +===== {{id name="_Toc90809"/}}6.2.4 URN Identification components of SDMX objects =====
598 598  
599 599  The table below describes the identification components for all SDMX object types that have identification. Note the actual attributes are all ‘id’ but have been prefixed by their class name or multiple class names to show navigation, e.g., ‘conceptSchemeAgencyId’ is really the ‘Id’ attribute of the Agency class that is associated to the ConceptScheme.
600 600  
... ... @@ -602,56 +602,67 @@
602 602  
603 603  urn:sdmx.org.sdmx.infomodel.{package}.{classname}=
604 604  
605 -(% style="width:1272.83px" %)
606 -|(% style="width:290px" %)**Classname**|(% style="width:649px" %)**Ending URN pattern**|(% style="width:332px" %)**Example**
607 -|(% style="width:290px" %)Agency^^[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^2^^>>path:#sdfootnote2sym||name="sdfootnote2anc"]](%%)^^|(% style="width:649px" %)agencySchemeAgencyId:**AGENCIES**(**1.0**).agencyId|(% style="width:332px" %)ECB:**AGENCIES**(**1.0**).AA
608 -|(% style="width:290px" %)//AgencyScheme//|(% style="width:649px" %)agencySchemeAgencyId:**AGENCIES**(**1.0**)|(% style="width:332px" %)ECB:**AGENCIES**(**1.0**)
609 -|(% style="width:290px" %)//Categorisation//|(% style="width:649px" %)categorisationAgencyId:categorisationId(version)|(% style="width:332px" %)IMF:cat001(1.0.0)
610 -|(% style="width:290px" %)Category|(% style="width:649px" %)categorySchemeAgencyId:categorySchemeId(versi on).categoryId.categoryId.categoryId etc.|(% style="width:332px" %)IMF:SDDS(1.0.0):level_1_category.level_2_category …
611 -|(% style="width:290px" %)//CategoryScheme//|(% style="width:649px" %)categorySchemeAgencyId:categorySchemeId(versi on)|(% style="width:332px" %)IMF:SDDS(1.0.0)
611 +|**Classname**|**Ending URN pattern**|**Example**
612 +|Agency^^[[(% class="wikiinternallink wikiinternallink" %)^^2^^>>path:#sdfootnote2sym||name="sdfootnote2anc"]](%%)^^|agencySchemeAgencyId:**AGENCIES**(**1.0**).agencyId|ECB:**AGENCIES**(**1.0**).AA
613 +|//AgencyScheme//|agencySchemeAgencyId:**AGENCIES**(**1.0**)|ECB:**AGENCIES**(**1.0**)
614 +|//Categorisation//|categorisationAgencyId:categorisationId(version)|IMF:cat001(1.0.0)
615 +|Category|categorySchemeAgencyId:categorySchemeId(versi on).categoryId.categoryId.categoryId etc.|IMF:SDDS(1.0.0):level_1_category.level_2_category …
616 +|//CategoryScheme//|categorySchemeAgencyId:categorySchemeId(versi on)|IMF:SDDS(1.0.0)
612 612  
613 -|(% style="width:292px" %)**Classname**|(% style="width:647px" %)**Ending URN pattern**|(% style="width:742px" %)**Example**
614 -|(% style="width:292px" %)//CategorySchemeMap//|(% style="width:647px" %)(((
615 -catSchemeMapAgencyId:catSchemeMapId(version)
616 -)))|(% style="width:742px" %)SDMX:EUROSTAT_SUBJECT_DOMAIN(1.0.0)
617 -|(% style="width:292px" %)Code|(% style="width:647px" %)codeListAgencyId:codelistId(version).codeId|(% style="width:742px" %)SDMX:CL_FREQ(1.0.0).Q
618 -|(% style="width:292px" %)//Codelist//|(% style="width:647px" %)codeListAgencyId:codeListId(version)|(% style="width:742px" %)SDMX:CL_FREQ(1.0.0)
619 -|(% style="width:292px" %)ComponentMap|(% style="width:647px" %)structureMapAgencyId:structureMap(version).com ponentMapId|(% style="width:742px" %)SDMX:BOP_STRUCTURES(1.0.0).REF_AREA_TO_COUNT RY
620 -|(% style="width:292px" %)Concept|(% style="width:647px" %)conceptSchemeAgencyId:conceptSchemeId(versio n).conceptId|(% style="width:742px" %)SDMX:CROSS_DOMAIN_CONCEPTS(1.0.0).FREQ
621 -|(% style="width:292px" %)//ConceptScheme//|(% style="width:647px" %)conceptSchemeAgencyId:conceptSchemeId(versio n)|(% style="width:742px" %)SDMX:CROSS_DOMAIN_CONCEPTS(1.0.0)
622 -|(% style="width:292px" %)//ConceptSchemeMap//|(% style="width:647px" %)(((
623 -conceptSchemeMapAgencyId:conceptSchemeMap Id(version)
624 -)))|(% style="width:742px" %)SDMX:CONCEPT_MAP(1.0.0)
625 -|(% style="width:292px" %)CustomType|(% style="width:647px" %)customTypeSchemeAgencyId customTypeSchemeId(version) customTypeId|(% style="width:742px" %)ECB: CUSTOM_TYPE_SCHEME(1.0.0).CUSTOM_TYPE_1
626 -|(% style="width:292px" %)//CustomTypeScheme//|(% style="width:647px" %)customTypeSchemeAgencyId customTypeSchemeId(version)|(% style="width:742px" %)ECB:CUSTOM_TYPE_SCHEME(1.0.0)
627 -|(% style="width:292px" %)DataAttrribute|(% style="width:647px" %)dataStructureDefinitionAgencyId:dataStructureDef initionId(version).dataAttributeId|(% style="width:742px" %)TFFS:EXT_DEBT(1.0.0).OBS_STATUS
628 -|(% style="width:292px" %)//DataConstraint//|(% style="width:647px" %)dataConstraintAgencyId:dataConstraintId(version)|(% style="width:742px" %)TFFS:CREDITOR_DATA_CONTENT(1.0.0)
618 +|**Classname**|**Ending URN pattern**|**Example**
619 +|//CategorySchemeMap//|(((
620 +catSchemeMapAgencyId:catSchemeMapId(version
629 629  
630 -|(% style="width:294px" %)**Classname**|(% style="width:645px" %)**Ending URN pattern**|(% style="width:742px" %)**Example**
631 -|(% style="width:294px" %)DataConsumer|(% style="width:645px" %)dataConsumerSchemeAgencyId:**DATA_CONSUME RS**(**1.0**).dataConsumerId|(% style="width:742px" %)SDMX:**DATA_CONSUMERS**(**1.0**).CONSUMER_1
632 -|(% style="width:294px" %)//DataConsumerScheme//|(% style="width:645px" %)(((
633 -dataConsumerSchemeAgencyId:**DATA_CONSUME RS**(**1.0**)
634 -)))|(% style="width:742px" %)SDMX:**DATA_CONSUMERS**(**1.0**)
635 -|(% style="width:294px" %)//Dataflow//|(% style="width:645px" %)dataflowAgencyId:dataflowId(version)|(% style="width:742px" %)TFFS:CRED_EXT_DEBT(1.0.0)
636 -|(% style="width:294px" %)DataProvider|(% style="width:645px" %)(((
637 -dataProviderSchemeAgencyId:**DATA_PROVIDERS**(**1.0**).dataProviderId
638 -)))|(% style="width:742px" %)SDMX:**DATA_PROVIDERS**(**1.0**).PROVIDER_1
639 -|(% style="width:294px" %)//DataProviderScheme//|(% style="width:645px" %)(((
640 -dataProviderSchemeAgencyId:**DATA_PROVIDERS**(**1.0**)
641 -)))|(% style="width:742px" %)SDMX:**DATA_PROVIDERS**(**1.0**)
642 -|(% style="width:294px" %)//DataStructure//|(% style="width:645px" %)dataStructureDefinitionAgencyId:dataStructureDef initionId(version)|(% style="width:742px" %)TFFS:EXT_DEBT(1.0.0)
643 -|(% style="width:294px" %)Dimension|(% style="width:645px" %)dataStructureDefinitionAgencyId:dataStructureDef initionId(version).dimensionId|(% style="width:742px" %)TFFS:EXT_DEBT(1.0.0).FREQ
644 -|(% style="width:294px" %)(((
622 +)
623 +)))|SDMX:EUROSTAT_SUBJECT_DOMAIN(1.0.0)
624 +|Code|codeListAgencyId:codelistId(version).codeId|SDMX:CL_FREQ(1.0.0).Q
625 +|//Codelist//|codeListAgencyId:codeListId(version)|SDMX:CL_FREQ(1.0.0)
626 +|ComponentMap|structureMapAgencyId:structureMap(version).com ponentMapId|SDMX:BOP_STRUCTURES(1.0.0).REF_AREA_TO_COUNT RY
627 +|Concept|conceptSchemeAgencyId:conceptSchemeId(versio n).conceptId|SDMX:CROSS_DOMAIN_CONCEPTS(1.0.0).FREQ
628 +|//ConceptScheme//|conceptSchemeAgencyId:conceptSchemeId(versio n)|SDMX:CROSS_DOMAIN_CONCEPTS(1.0.0)
629 +|//ConceptSchemeMap//|(((
630 +conceptSchemeMapAgencyId:conceptSchemeMap
631 +
632 +Id(version)
633 +)))|SDMX:CONCEPT_MAP(1.0.0)
634 +|CustomType|customTypeSchemeAgencyId customTypeSchemeId(version) customTypeId|ECB: CUSTOM_TYPE_SCHEME(1.0.0).CUSTOM_TYPE_1
635 +|//CustomTypeScheme//|customTypeSchemeAgencyId customTypeSchemeId(version)|ECB:CUSTOM_TYPE_SCHEME(1.0.0)
636 +|DataAttrribute|dataStructureDefinitionAgencyId:dataStructureDef initionId(version).dataAttributeId|TFFS:EXT_DEBT(1.0.0).OBS_STATUS
637 +|//DataConstraint//|dataConstraintAgencyId:dataConstraintId(version)|TFFS:CREDITOR_DATA_CONTENT(1.0.0)
638 +
639 +|**Classname**|**Ending URN pattern**|**Example**
640 +|DataConsumer|dataConsumerSchemeAgencyId:**DATA_CONSUME RS**(**1.0**).dataConsumerId|SDMX:**DATA_CONSUMERS**(**1.0**).CONSUMER_1
641 +|//DataConsumerScheme//|(((
642 +dataConsumerSchemeAgencyId:**DATA_CONSUME**
643 +
644 +**RS**(**1.0**)
645 +)))|SDMX:**DATA_CONSUMERS**(**1.0**)
646 +|//Dataflow//|dataflowAgencyId:dataflowId(version)|TFFS:CRED_EXT_DEBT(1.0.0)
647 +|DataProvider|(((
648 +dataProviderSchemeAgencyId:**DATA_PROVIDERS**(
649 +
650 +**1.0**).dataProviderId
651 +)))|SDMX:**DATA_PROVIDERS**(**1.0**).PROVIDER_1
652 +|//DataProviderScheme//|(((
653 +dataProviderSchemeAgencyId:**DATA_PROVIDERS**(
654 +
655 +**1.0**)
656 +)))|SDMX:**DATA_PROVIDERS**(**1.0**)
657 +|//DataStructure//|dataStructureDefinitionAgencyId:dataStructureDef initionId(version)|TFFS:EXT_DEBT(1.0.0)
658 +|Dimension|dataStructureDefinitionAgencyId:dataStructureDef initionId(version).dimensionId|TFFS:EXT_DEBT(1.0.0).FREQ
659 +|(((
645 645  DimensionDescriptor
646 646  
647 647  MeasureDescriptor
648 648  
649 649  AttributeDescriptor
650 -)))|(% style="width:645px" %)(((
665 +)))|(((
651 651  dataStructureDefinitionAgencyId:dataStructureDef initionId(version).componentListId
652 652  
653 -where the componentListId is the name of the class (there is only one occurrence of each in the Data Structure Definition)
654 -)))|(% style="width:742px" %)(((
668 +where the componentListId is the name of the class (there is only one occurrence of each in the
669 +
670 +Data Structure Definition)
671 +)))|(((
655 655  TFFS:EXT_DEBT(1.0.0).DimensionDescriptor
656 656  
657 657  TFFS:EXT_DEBT(1.0.0).MeasureDescriptor
... ... @@ -658,81 +658,83 @@
658 658  
659 659  TFFS:EXT_DEBT(1.0.0).AttributeDescriptor
660 660  )))
661 -|(% style="width:294px" %)GroupDimensionDescriptor|(% style="width:645px" %)dataStructureDefinitionAgencyId:dataStructureDef initionId(version).groupDimensionDescriptorId|(% style="width:742px" %)TFFS:EXT_DEBT(1.0.0).SIBLING
662 -|(% style="width:294px" %)HierarchicalCode|(% style="width:645px" %)hierarchyAgencyId:hierarchyId(version).hierarchica lCode.hierarchicalCode|(% style="width:742px" %)UNESCO:H-C-GOV(1.0.0).GOV_CODE1.GOV_CODE1_1
678 +|GroupDimensionDescriptor|dataStructureDefinitionAgencyId:dataStructureDef initionId(version).groupDimensionDescriptorId|TFFS:EXT_DEBT(1.0.0).SIBLING
679 +|HierarchicalCode|hierarchyAgencyId:hierarchyId(version).hierarchica lCode.hierarchicalCode|UNESCO:H-C-GOV(1.0.0).GOV_CODE1.GOV_CODE1_1
663 663  
664 -|**Classname**|(% style="width:644px" %)**Ending URN pattern**|(% style="width:743px" %)**Example**
665 -|//Hierarchy//|(% style="width:644px" %)hierarchyAgencyId:hierarchyId(version)|(% style="width:743px" %)UNESCO:H-C-GOV(1.0.0)
666 -|//HierarchyAssociation//|(% style="width:644px" %)hierarchyAssociationAgencyId:hierarchyAssociatio nId(version)|(% style="width:743px" %)UNESCO:CL_EXP_SOURCE(1.0.0)
667 -|Level|(% style="width:644px" %)hierarchyAgencyId:hierarchyId(version).level|(% style="width:743px" %)UNESCO:H-C-GOV(1.0.0).LVL1
668 -|Measure|(% style="width:644px" %)dataStructureDefinitionAgencyId:dataStructureDef initionId(version).measureId|(% style="width:743px" %)TFFS:EXT_DEBT(1.0.0).OBS_VALUE
669 -|MetadataAttribute|(% style="width:644px" %)(((
681 +|**Classname**|**Ending URN pattern**|**Example**
682 +|//Hierarchy//|hierarchyAgencyId:hierarchyId(version)|UNESCO:H-C-GOV(1.0.0)
683 +|//HierarchyAssociation//|hierarchyAssociationAgencyId:hierarchyAssociatio nId(version)|UNESCO:CL_EXP_SOURCE(1.0.0)
684 +|Level|hierarchyAgencyId:hierarchyId(version).level|UNESCO:H-C-GOV(1.0.0).LVL1
685 +|Measure|dataStructureDefinitionAgencyId:dataStructureDef initionId(version).measureId|TFFS:EXT_DEBT(1.0.0).OBS_VALUE
686 +|MetadataAttribute|(((
670 670  msdAgencyId:msdId(version).metadataAttributeId.
671 671  
672 672  metadataAttributeId
673 -)))|(% style="width:743px" %)IMF:SDDS_MSD(1.0.0).COMPILATION.METHOD
674 -|MetadataAttributeDescriptor|(% style="width:644px" %)msdAgencyId:msdId(version).metadataAttributeDe scriptorId|(% style="width:743px" %)IMF:SDDS_MSD(1.0.0).MetadataAttributeDescriptor
675 -|//MetadataConstraint//|(% style="width:644px" %)metadataConstraintAgencyId:metadataConstraintI d(version)|(% style="width:743px" %)TFFS:CREDITOR_METADATA_CONTENT(1.0.0)
676 -|//Metadataflow//|(% style="width:644px" %)metadataflowAgencyId:metadataflowId(version)|(% style="width:743px" %)IMF:SDDS_MDF(1.0.0)
677 -|MetadataProvider|(% style="width:644px" %)metadataProviderSchemeAgencyId:**METADATA_P ROVIDERS**(**1.0**).metadataProviderId|(% style="width:743px" %)SDMX:**METADATA_PROVIDERS**(**1.0**).MD_PROVIDER_1
678 -|//MetadataProviderScheme//|(% style="width:644px" %)metadataProviderSchemeAgencyId:**METADATA_P ROVIDERS**(**1.0**)|(% style="width:743px" %)SDMX:**METADATA_PROVIDERS**(**1.0**)
679 -|//MetadataProvisionAgreement//|(% style="width:644px" %)metadataProvisionAgreementAgencyId:metadataP rovisionAgreementId(version)|(% style="width:743px" %)IMF:SDDS_MDF_AB(1.0.0)
680 -|//MetadataSet//|(% style="width:644px" %)metadataProviderId:metadataSetId(version)|(% style="width:743px" %)MD_PROVIDER:METADATASET(1.0.0)
681 -|//MetadataStructure//|(% style="width:644px" %)msdAgencyId:msdId(version)|(% style="width:743px" %)IMF:SDDS_MSD(1.0.0)
690 +)))|IMF:SDDS_MSD(1.0.0).COMPILATION.METHOD
691 +|MetadataAttributeDescriptor|msdAgencyId:msdId(version).metadataAttributeDe scriptorId|IMF:SDDS_MSD(1.0.0).MetadataAttributeDescriptor
692 +|//MetadataConstraint//|metadataConstraintAgencyId:metadataConstraintI d(version)|TFFS:CREDITOR_METADATA_CONTENT(1.0.0)
693 +|//Metadataflow//|metadataflowAgencyId:metadataflowId(version)|IMF:SDDS_MDF(1.0.0)
694 +|MetadataProvider|metadataProviderSchemeAgencyId:**METADATA_P ROVIDERS**(**1.0**).metadataProviderId|SDMX:**METADATA_PROVIDERS**(**1.0**).MD_PROVIDER_1
695 +|//MetadataProviderScheme//|metadataProviderSchemeAgencyId:**METADATA_P ROVIDERS**(**1.0**)|SDMX:**METADATA_PROVIDERS**(**1.0**)
696 +|//MetadataProvisionAgreement//|metadataProvisionAgreementAgencyId:metadataP rovisionAgreementId(version)|IMF:SDDS_MDF_AB(1.0.0)
697 +|//MetadataSet//|metadataProviderId:metadataSetId(version)|MD_PROVIDER:METADATASET(1.0.0)
698 +|//MetadataStructure//|msdAgencyId:msdId(version)|IMF:SDDS_MSD(1.0.0)
682 682  
683 -|(% style="width:296px" %)**Classname**|(% style="width:646px" %)**Ending URN pattern**|(% style="width:739px" %)**Example**
684 -|(% style="width:296px" %)NamePersonalisation|(% style="width:646px" %)namePersonalisationSchemeAgencyId namePersonalisationSchemeId(version) namePersonalisationId|(% style="width:739px" %)ECB:PSN_SCHEME(1.0.0).PSN1234
685 -|(% style="width:296px" %)//NamePersonalisationScheme//|(% style="width:646px" %)namePersonalisationSchemeAgencyId namePersonalisationSchemeId(version)|(% style="width:739px" %)ECB:PSN_SCHEME(1.0.0)
686 -|(% style="width:296px" %)//OrganisationSchemeMap//|(% style="width:646px" %)orgSchemeMapAgencyId:orgSchemeMapId(versio n)|(% style="width:739px" %)SDMX:AGENCIES_PROVIDERS(1.0.0)
687 -|(% style="width:296px" %)OrganisationUnit|(% style="width:646px" %)organisationUnitSchemeAgencyId:organisationUni tSchemeId(version).organisationUnitId|(% style="width:739px" %)ECB:ORGANISATIONS(1.0.0).1F
688 -|(% style="width:296px" %)//OrganisationUnitScheme//|(% style="width:646px" %)organisationUnitSchemeAgencyId:organisationUni tSchemeId(version)|(% style="width:739px" %)ECB:ORGANISATIONS(1.0.0)
689 -|(% style="width:296px" %)//Process//|(% style="width:646px" %)processAgencyId:processId{version)|(% style="width:739px" %)BIS:PROCESS1(1.0.0)
690 -|(% style="width:296px" %)ProcessStep|(% style="width:646px" %)(((
700 +|**Classname**|**Ending URN pattern**|**Example**
701 +|NamePersonalisation|namePersonalisationSchemeAgencyId namePersonalisationSchemeId(version) namePersonalisationId|ECB:PSN_SCHEME(1.0.0).PSN1234
702 +|//NamePersonalisationScheme//|namePersonalisationSchemeAgencyId namePersonalisationSchemeId(version)|ECB:PSN_SCHEME(1.0.0)
703 +|//OrganisationSchemeMap//|orgSchemeMapAgencyId:orgSchemeMapId(versio n)|SDMX:AGENCIES_PROVIDERS(1.0.0)
704 +|OrganisationUnit|organisationUnitSchemeAgencyId:organisationUni tSchemeId(version).organisationUnitId|ECB:ORGANISATIONS(1.0.0).1F
705 +|//OrganisationUnitScheme//|organisationUnitSchemeAgencyId:organisationUni tSchemeId(version)|ECB:ORGANISATIONS(1.0.0)
706 +|//Process//|processAgencyId:processId{version)|BIS:PROCESS1(1.0.0)
707 +|ProcessStep|(((
691 691  processAgencyId:processId(version).processStepId.
692 692  
693 693  processStepId
694 -)))|(% style="width:739px" %)BIS:PROCESS1(1.0.0).STEP1.STEP1_1
695 -|(% style="width:296px" %)//ProvisionAgreement//|(% style="width:646px" %)provisionAgreementAgencyId:provisionAgreement Id(version)|(% style="width:739px" %)TFFS:CRED_EXT_DEBT_AB(1.0.0)
696 -|(% style="width:296px" %)ReportingCategory|(% style="width:646px" %)(((
711 +)))|BIS:PROCESS1(1.0.0).STEP1.STEP1_1
712 +|//ProvisionAgreement//|provisionAgreementAgencyId:provisionAgreement Id(version)|TFFS:CRED_EXT_DEBT_AB(1.0.0)
713 +|ReportingCategory|(((
697 697  reportingTaxonomyAgencyId:
698 698  
699 699  reportingTaxonomyId(version).reportingCategoryI d.reportingCategoryId
700 -)))|(% style="width:739px" %)IMF:REP_1(1.0.0):LVL1_REP_CAT.LVL2_REP_CAT
701 -|(% style="width:296px" %)//ReportingTaxonomy//|(% style="width:646px" %)reportingTaxonomyAgencyId:reportingTaxonomyI d(version)|(% style="width:739px" %)IMF:REP_1(1.0.0)
702 -|(% style="width:296px" %)//ReportingTaxonomyMap//|(% style="width:646px" %)repTaxonomyAgencyId:repTaxonomyId(version)|(% style="width:739px" %)SDMX:RT_MAP(1.0.0)
717 +)))|IMF:REP_1(1.0.0):LVL1_REP_CAT.LVL2_REP_CAT
718 +|//ReportingTaxonomy//|reportingTaxonomyAgencyId:reportingTaxonomyI d(version)|IMF:REP_1(1.0.0)
719 +|//ReportingTaxonomyMap//|repTaxonomyAgencyId:repTaxonomyId(version)|SDMX:RT_MAP(1.0.0)
703 703  
704 -|(% style="width:297px" %)**Classname**|(% style="width:647px" %)**Ending URN pattern**|(% style="width:737px" %)**Example**
705 -|(% style="width:297px" %)//RepresentationMap//|(% style="width:647px" %)repMapAgencyId:repMapId(version)|(% style="width:737px" %)SDMX:REF_AREA_MAPPING(1.0.0)
706 -|(% style="width:297px" %)Ruleset|(% style="width:647px" %)rulesetSchemeAgencyId rulesetSchemeId(version) rulesetId|(% style="width:737px" %)ECB:RULESET_23(1.0.0).SET111
707 -|(% style="width:297px" %)//RulesetScheme//|(% style="width:647px" %)rulesetSchemeAgencyId rulesetSchemeId(version)|(% style="width:737px" %)ECB:RULESET_23(1.0.0)
708 -|(% style="width:297px" %)//StructureMap//|(% style="width:647px" %)structureMapAgencyId:structureMap(version)|(% style="width:737px" %)SDMX:BOP_STRUCTURES(1.0.0)
709 -|(% style="width:297px" %)Subscription|(% style="width:647px" %)(((
721 +|**Classname**|**Ending URN pattern**|**Example**
722 +|//RepresentationMap//|repMapAgencyId:repMapId(version)|SDMX:REF_AREA_MAPPING(1.0.0)
723 +|Ruleset|rulesetSchemeAgencyId rulesetSchemeId(version) rulesetId|ECB:RULESET_23(1.0.0).SET111
724 +|//RulesetScheme//|rulesetSchemeAgencyId rulesetSchemeId(version)|ECB:RULESET_23(1.0.0)
725 +|//StructureMap//|structureMapAgencyId:structureMap(version)|SDMX:BOP_STRUCTURES(1.0.0)
726 +|Subscription|(((
710 710  The Subscription is not itself an Identifiable Artefact and therefore it does not follow the rules for URN structure.
728 +
711 711  The name of the URN is registryURN There is no pre-determined format.
712 -)))|(% style="width:737px" %)This cannot be generated by a common mechanism as subscriptions, although maintainable in the sense that they can be submitted and deleted, are not mandated to be created by a maintenance agency and have no versioning mechanism. It is therefore the responsibility of the target registry to generate a unique Id for the Subscription, and for the application creating the subscription to store the registry URN that is returned from the registry in the subscription response message.
713 -|(% style="width:297px" %)TimeDimension|(% style="width:647px" %)dataStructureDefinitionAgencyId:dataStructureDef initionId(version).timeDimensionId|(% style="width:737px" %)TFFS:EXT_DEBT(1.0.0).TIME_PERIOD
714 -|(% style="width:297px" %)Transformation|(% style="width:647px" %)transformationSchemeAgencyId transformationSchemeId(version) transformationId|(% style="width:737px" %)ECB:TRANSFORMATION_SCHEME(1.0.0).TRANS_1
715 -|(% style="width:297px" %)//TransformationScheme//|(% style="width:647px" %)transformationSchemeAgencyId transformationSchemeId(version)|(% style="width:737px" %)ECB: TRANSFORMATION_SCHEME(1.0.0)
716 -|(% style="width:297px" %)**Classname**|(% style="width:647px" %)**Ending URN pattern**|(% style="width:737px" %)**Example**
717 -|(% style="width:297px" %)Transition|(% style="width:647px" %)(((
730 +)))|This cannot be generated by a common mechanism as subscriptions, although maintainable in the sense that they can be submitted and deleted, are not mandated to be created by a maintenance agency and have no versioning mechanism. It is therefore the responsibility of the target registry to generate a unique Id for the Subscription, and for the application creating the subscription to store the registry URN that is returned from the registry in the subscription response message.
731 +|TimeDimension|dataStructureDefinitionAgencyId:dataStructureDef initionId(version).timeDimensionId|TFFS:EXT_DEBT(1.0.0).TIME_PERIOD
732 +|Transformation|transformationSchemeAgencyId transformationSchemeId(version) transformationId|ECB:TRANSFORMATION_SCHEME(1.0.0).TRANS_1
733 +|//TransformationScheme//|transformationSchemeAgencyId transformationSchemeId(version)|ECB: TRANSFORMATION_SCHEME(1.0.0)
734 +|**Classname**|**Ending URN pattern**|**Example**
735 +|Transition|(((
718 718  processAgencyId:processId(version).processStepId.
737 +
719 719  transitionId
720 -)))|(% style="width:737px" %)BIS:PROCESS1(1.0.0).STEP1.TRANSITION1
721 -|(% style="width:297px" %)UserDefinedOperator|(% style="width:647px" %)userDefinedOperatorSchemeAgencyId userDefinedOperatorSchemeId(version) usserDefinedOperatorId|(% style="width:737px" %)ECB:OS_CALC(1.2.0).OS267
722 -|(% style="width:297px" %)//UserDefinedOperatorScheme//|(% style="width:647px" %)userDefinedOperatorSchemeAgencyId userDefinedOperatorSchemeId(version)|(% style="width:737px" %)ECB:OS_CALC(1.2.0)
723 -|(% style="width:297px" %)//ValueList//|(% style="width:647px" %)valuelistAgencyId:valuelistId(version)|(% style="width:737px" %)SDMX:VLIST(1.0.0)
724 -|(% style="width:297px" %)VtlCodelistMapping|(% style="width:647px" %)vtlMappingSchemeAgencyId vtlMappingSchemeId(version) vtlCodelistMappingId|(% style="width:737px" %)ECB:CLIST_MP(2.0.0).ABZ
725 -|(% style="width:297px" %)VtlConceptMapping|(% style="width:647px" %)vtlMappingSchemeAgencyId vtlMappingSchemeId(version) vtlConceptMappingId|(% style="width:737px" %)ECB:CLIST_MP(1.0.0).XYA
726 -|(% style="width:297px" %)VtlDataflowMapping|(% style="width:647px" %)vtlMappingSchemeAgencyId vtlMappingSchemeId(version) vtlDataflowMappingId|(% style="width:737px" %)ECB:CLIST_MP(1.0.0).MOQ
727 -|(% style="width:297px" %)//VtlMappingScheme//|(% style="width:647px" %)vtlMappingSchemeAgencyId VtlMappingSchemeId(version)|(% style="width:737px" %)ECB:CLIST_MP(2.0.0)
739 +)))|BIS:PROCESS1(1.0.0).STEP1.TRANSITION1
740 +|UserDefinedOperator|userDefinedOperatorSchemeAgencyId userDefinedOperatorSchemeId(version) usserDefinedOperatorId|ECB:OS_CALC(1.2.0).OS267
741 +|//UserDefinedOperatorScheme//|userDefinedOperatorSchemeAgencyId userDefinedOperatorSchemeId(version)|ECB:OS_CALC(1.2.0)
742 +|//ValueList//|valuelistAgencyId:valuelistId(version)|SDMX:VLIST(1.0.0)
743 +|VtlCodelistMapping|vtlMappingSchemeAgencyId vtlMappingSchemeId(version) vtlCodelistMappingId|ECB:CLIST_MP(2.0.0).ABZ
744 +|VtlConceptMapping|vtlMappingSchemeAgencyId vtlMappingSchemeId(version) vtlConceptMappingId|ECB:CLIST_MP(1.0.0).XYA
745 +|VtlDataflowMapping|vtlMappingSchemeAgencyId vtlMappingSchemeId(version) vtlDataflowMappingId|ECB:CLIST_MP(1.0.0).MOQ
746 +|//VtlMappingScheme//|vtlMappingSchemeAgencyId VtlMappingSchemeId(version)|ECB:CLIST_MP(2.0.0)
728 728  
729 729  5**Table 3: Table of identification components for SDMX Identifiable Artefacts**
730 730  
731 -= 7 Implementation Notes =
750 += {{id name="_Toc90810"/}}7 Implementation Notes =
732 732  
733 -== 7.1 Structural Definition Metadata ==
752 +=== {{id name="_Toc90811"/}}7.1 Structural Definition Metadata ===
734 734  
735 -=== 7.1.1 Introduction ===
754 +===== {{id name="_Toc90812"/}}7.1.1 Introduction =====
736 736  
737 737  The SDMX Registry must have the ability to support agencies in their role of defining and disseminating structural metadata artefacts. These artefacts include data structure definitions, code lists, concepts etc. and are fully defined in the SDMX-IM. An authenticated agency may submit valid structural metadata definitions which must be stored in the registry. Note that the term “structural metadata” refers as a general term to all structural components (Data Structure Definitions, Metadata Structure Definitions, Code Lists, Concept Schemes, etc.)
738 738  
... ... @@ -748,40 +748,46 @@
748 748  
749 749  The following table lists the Maintainable Artefacts.
750 750  
751 -(% style="width:825.835px" %)
752 -|(% colspan="2" style="width:455px" %)**Maintainable Artefacts**|(% style="width:367px" %)**Content**
753 -|(% style="width:160px" %)**Abstract Class**|(% style="width:295px" %)**Concrete Class**|(% style="width:367px" %)
754 -|(% style="width:160px" %)Item Scheme|(% style="width:295px" %)Codelist|(% style="width:367px" %)Code
755 -|(% style="width:160px" %) |(% style="width:295px" %)Concept Scheme|(% style="width:367px" %)Concept
756 -|(% style="width:160px" %) |(% style="width:295px" %)Category Scheme|(% style="width:367px" %)Category
757 -|(% style="width:160px" %) |(% style="width:295px" %)Organisation Unit Scheme|(% style="width:367px" %)Organisation Unit
758 -|(% style="width:160px" %) |(% style="width:295px" %)Agency Scheme|(% style="width:367px" %)Agency
759 -|(% style="width:160px" %) |(% style="width:295px" %)Data Provider Scheme|(% style="width:367px" %)Data Provider
760 -|(% style="width:160px" %) |(% style="width:295px" %)Metadata Provider Scheme|(% style="width:367px" %)Metadata Provider
761 -|(% style="width:160px" %) |(% style="width:295px" %)Data Consumer Scheme|(% style="width:367px" %)Data Consumer
762 -|(% style="width:160px" %) |(% style="width:295px" %)Reporting Taxonomy|(% style="width:367px" %)Reporting Category
763 -|(% style="width:160px" %) |(% style="width:295px" %)Transformation Scheme|(% style="width:367px" %)Transformation
764 -|(% style="width:160px" %) |(% style="width:295px" %)Custom Type Scheme|(% style="width:367px" %)Custom Type
765 -|(% style="width:160px" %) |(% style="width:295px" %)Name Personalisation Scheme|(% style="width:367px" %)Name Personalisation
766 -|(% style="width:160px" %) |(% style="width:295px" %)Vtl Mapping Scheme|(% style="width:367px" %)Vtl Codelist Mapping Vtl Concept Mapping
767 -|(% style="width:160px" %) |(% style="width:295px" %)Ruleset Scheme|(% style="width:367px" %)Ruleset
768 -|(% style="width:160px" %) |(% style="width:295px" %)User Defined Operator Scheme|(% style="width:367px" %)User Defined Operator
769 -|(% style="width:160px" %)Enumerated List|(% style="width:295px" %)ValueList|(% style="width:367px" %)Value Item
770 -|(% style="width:160px" %)Structure|(% style="width:295px" %)Data Structure Definition|(% style="width:367px" %)(((
770 +|(% colspan="2" %)**Maintainable Artefacts**|**Content**
771 +|**Abstract Class**|**Concrete Class**|
772 +|Item Scheme|Codelist|Code
773 +| |Concept Scheme|Concept
774 +| |Category Scheme|Category
775 +| |Organisation Unit Scheme|Organisation Unit
776 +| |Agency Scheme|Agency
777 +| |Data Provider Scheme|Data Provider
778 +| |Metadata Provider Scheme|Metadata Provider
779 +| |Data Consumer Scheme|Data Consumer
780 +| |Reporting Taxonomy|Reporting Category
781 +| |Transformation Scheme|Transformation
782 +| |Custom Type Scheme|Custom Type
783 +| |Name Personalisation Scheme|Name Personalisation
784 +| |Vtl Mapping Scheme|Vtl Codelist Mapping Vtl Concept Mapping
785 +| |Ruleset Scheme|Ruleset
786 +| |User Defined Operator Scheme|User Defined Operator
787 +|Enumerated List|ValueList|Value Item
788 +|Structure|Data Structure Definition|(((
771 771  Dimension Descriptor
790 +
772 772  Group Dimension Descriptor
792 +
773 773  Dimension
794 +
774 774  Time Dimension
796 +
775 775  Attribute Descriptor
798 +
776 776  Data Attribute
800 +
777 777  Measure Descriptor
802 +
778 778  Measure
779 779  )))
780 -|(% style="width:160px" %) |(% style="width:295px" %)Metadata Structure Definition|(% style="width:367px" %)Metadata Attribute Descriptor Metadata Attribute
781 -|(% style="width:160px" %)Structure Usage|(% style="width:295px" %)Dataflow|(% style="width:367px" %)
782 -|(% style="width:160px" %) |(% style="width:295px" %)Metadataflow|(% style="width:367px" %)
783 -|(% style="width:160px" %)None|(% style="width:295px" %)Process|(% style="width:367px" %)Process Step
784 -|(% style="width:160px" %)None|(% style="width:295px" %)Structure Map|(% style="width:367px" %)(((
805 +| |Metadata Structure Definition|Metadata Attribute Descriptor Metadata Attribute
806 +|Structure Usage|Dataflow|
807 +| |Metadataflow|
808 +|None|Process|Process Step
809 +|None|Structure Map|(((
785 785  Component Map
786 786  
787 787  Epoch Map
... ... @@ -788,44 +788,44 @@
788 788  
789 789  Date Pattern Map
790 790  )))
791 -|(% style="width:160px" %)None|(% style="width:295px" %)Representation Map|(% style="width:367px" %)Representation Mapping
792 -|(% style="width:160px" %)Item Scheme Map|(% style="width:295px" %)Organisation Scheme Map|(% style="width:367px" %)Item Map
793 -|(% style="width:160px" %) |(% style="width:295px" %)Concept Scheme Map|(% style="width:367px" %)Item Map
794 -|(% style="width:160px" %) |(% style="width:295px" %)Category Scheme Map|(% style="width:367px" %)Item Map
795 -|(% style="width:160px" %) |(% style="width:295px" %)Reporting Taxonomy Map|(% style="width:367px" %)Item Map
796 -|(% style="width:160px" %)None|(% style="width:295px" %)Provision Agreement|(% style="width:367px" %)
797 -|(% style="width:160px" %)None|(% style="width:295px" %)Metadata Provision Agreement|(% style="width:367px" %)
798 -|(% style="width:160px" %)None|(% style="width:295px" %)Hierarchy|(% style="width:367px" %)Hierarchical Code
799 -|(% style="width:160px" %)None|(% style="width:295px" %)Hierarchy Association|(% style="width:367px" %)
800 -|(% style="width:160px" %)None|(% style="width:295px" %)Categorisation|(% style="width:367px" %)
801 -|(% style="width:160px" %)Constraint|(% style="width:295px" %)Data Constraint|(% style="width:367px" %)DataKeySet
802 -|(% style="width:160px" %) |(% style="width:295px" %) |(% style="width:367px" %)CubeRegion
803 -|(% style="width:160px" %)Constraint|(% style="width:295px" %)Metadata Constraint|(% style="width:367px" %)MetadataTargetRegion
816 +|None|Representation Map|Representation Mapping
817 +|Item Scheme Map|Organisation Scheme Map|Item Map
818 +| |Concept Scheme Map|Item Map
819 +| |Category Scheme Map|Item Map
820 +| |Reporting Taxonomy Map|Item Map
821 +|None|Provision Agreement|
822 +|None|Metadata Provision Agreement|
823 +|None|Hierarchy|Hierarchical Code
824 +|None|Hierarchy Association|
825 +|None|Categorisation|
826 +|Constraint|Data Constraint|DataKeySet
827 +| | |CubeRegion
828 +|Constraint|Metadata Constraint|MetadataTargetRegion
804 804  
805 805  **Table 4: Table of Maintainable Artefacts for Structural Definition Metadata**
806 806  
807 -=== 7.1.2 Item Scheme, Structure ===
832 +===== {{id name="_Toc90813"/}}7.1.2 Item Scheme, Structure =====
808 808  
809 809  The artefacts included in the structural definitions are:
810 810  
811 811  * All types of Item Scheme (Codelist, Concept Scheme, Category Scheme, Organisation Scheme, Agency Scheme, Data Provider Scheme, Metadata Provider Scheme, Data Consumer Scheme, Organisation Unit Scheme, Transformation Scheme, Name Personalisation Scheme, Custom Type Scheme, Vtl Mapping Scheme, Ruleset Scheme, User Defined Operator Scheme)
812 -* All types of Enumerated List (ValueList)^^[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^3^^>>path:#sdfootnote3sym||name="sdfootnote3anc"]](%%)^^
837 +* All types of Enumerated List (ValueList)^^[[(% class="wikiinternallink wikiinternallink" %)^^3^^>>path:#sdfootnote3sym||name="sdfootnote3anc"]](%%)^^
813 813  * All types of Structure (Data Structure Definition, Metadata Structure Definition)
814 814  * All types of Structure Usage (Dataflow, Metadataflow)
815 815  
816 -=== 7.1.3 Structure Usage ===
841 +===== {{id name="_Toc90814"/}}7.1.3 Structure Usage =====
817 817  
818 -==== 7.1.3.1 Structure Usage: Basic Concepts ====
843 +**7.1.3.1 Structure Usage: Basic Concepts**
819 819  
820 820  The Structure Usage defines, in its concrete classes of Dataflow and Metadataflow, which flows of data and metadata use which specific Structure, and importantly for the support of data and metadata discovery, the Structure Usage can be linked to one or more Category in one or more Category Scheme using the Categorisation mechanism. This gives the ability for an application to discover data and metadata by “drilling down” the Category Schemes.
821 821  
822 -==== 7.1.3.2 Structure Usage Schematic ====
847 +**7.1.3.2 Structure Usage Schematic**
823 823  
824 824  [[image:SDMX 3.1 Section 5_en_9b750e13.jpg||height="246" width="438"]]
825 825  
826 826  **Figure 9: Schematic of Linking the Data and Metadata Flows to Categories and Structure Definitions**
827 827  
828 -==== 7.1.3.3 Structure Usage Model ====
853 +**7.1.3.3 Structure Usage Model**
829 829  
830 830  [[image:SDMX 3.1 Section 5_en_1c94cbe.jpg||height="548" width="578"]]
831 831  
... ... @@ -843,9 +843,9 @@
843 843  1*. Categorisation to Dataflow and Category
844 844  1*. Categorisation to Metadataflow and Category
845 845  
846 -== 7.2 Data and Metadata Provisioning ==
871 +=== {{id name="_Toc90815"/}}7.2 Data and Metadata Provisioning ===
847 847  
848 -=== 7.2.1 Provisioning Agreement: Basic concepts ===
873 +===== {{id name="_Toc90816"/}}7.2.1 Provisioning Agreement: Basic concepts =====
849 849  
850 850  Data/Metadata provisioning defines a framework in which the provision of different types of statistical data and metadata by various data/metadata providers can be specified and controlled. This framework is the basis on which the existence of data can be made known to the SDMX-enabled community and hence the basis on which data can subsequently be discovered. Such a framework can be used to regulate the data content to facilitate the building of intelligent applications. It can also be used to facilitate the processing implied by service level agreements, or other provisioning agreements in those scenarios that are based on legal directives. Additionally, quality and timeliness metadata can be supported by this framework which makes it practical to implement information supply chain monitoring.
851 851  
... ... @@ -853,7 +853,7 @@
853 853  
854 854  Although the Provision Agreement directly supports the data-sharing “pull” model, it is also useful in “push” exchanges (bilateral and gateway scenarios), or in a dissemination environment. It should be noted, too, that in any exchange scenario, the registry functions as a repository of structural metadata.
855 855  
856 -=== 7.2.2 Provisioning Agreement Model – pull use case ===
881 +===== {{id name="_Toc90817"/}}7.2.2 Provisioning Agreement Model – pull use case =====
857 857  
858 858  An organisation which publishes statistical data or reference metadata and wishes to make it available to an SDMX enabled community is called a Data Provider. In terms of the SDMX Information Model, the Data Provider is maintained in a Data Provider Scheme.
859 859  
... ... @@ -875,9 +875,9 @@
875 875  
876 876  A Provision Agreement is structural metadata. Each Provision Agreement must reference a Data Provider or Metadata Provider and a Dataflow or Metadataflow Definition. The Data/Metadata Provider and the Dataflow/Metadataflow must exist already in order to set up a Metadata Provision or Provision Agreement.
877 877  
878 -== 7.3 Data and Metadata Constraints ==
903 +=== {{id name="_Toc90818"/}}7.3 Data and Metadata Constraints ===
879 879  
880 -=== 7.3.1 Data and Metadata Constraints: Basic Concepts ===
905 +===== {{id name="_Toc90819"/}}7.3.1 Data and Metadata Constraints: Basic Concepts =====
881 881  
882 882  Constraints are, effectively, lists of the valid or actual content of data and metadata. Constraints can be used to specify a subset of the theoretical content of data set or metadata set which can be derived from the specification of the DSD or MSD. A Constraint can comprise a list of keys or a list of content (usually code values) of a specific component such as a dimension or attribute.
883 883  
... ... @@ -891,13 +891,13 @@
891 891  
892 892  In addition, DataAvailabilityConstraints can be extremely useful in a data visualisation system, such as dissemination of statistics on a website. In such a system a Cube Region can be used to specify the Dimension codes that actually exist in a data source (these can be used to build relevant selection tables).
893 893  
894 -=== 7.3.2 Data and Metadata Constraints: Schematic ===
919 +===== {{id name="_Toc90820"/}}7.3.2 Data and Metadata Constraints: Schematic =====
895 895  
896 896  [[image:SDMX 3.1 Section 5_en_28d0cadc.jpg||height="326" width="580"]]
897 897  
898 898  **Figure 14: Schematic of the Constraint and the Artefacts that can be constrained**
899 899  
900 -=== 7.3.3 Data and Metadata Constraints: Model ===
925 +===== {{id name="_Toc90821"/}}7.3.3 Data and Metadata Constraints: Model =====
901 901  
902 902  [[image:SDMX 3.1 Section 5_en_a3184f6a.jpg||height="298" width="579"]]
903 903  
... ... @@ -913,9 +913,9 @@
913 913  
914 914  The content of the Constraint can be found in the SDMX Information Model document.
915 915  
916 -== 7.4 Data Registration ==
941 +=== {{id name="_Toc90822"/}}7.4 Data Registration ===
917 917  
918 -=== 7.4.1 Basic Concepts ===
943 +===== {{id name="_Toc90823"/}}7.4.1 Basic Concepts =====
919 919  
920 920  A Data Provider has published a new dataset conforming to an existing Dataflow (and hence Data Structure Definition). This is implemented as either a web-accessible SDMXML file, or in a database which has a web-services interface capable of responding to an SDMX RESTful query with an SDMX-ML data stream.
921 921  
... ... @@ -925,15 +925,15 @@
925 925  
926 926  SDMX-RR supports dataset registration via the Registration Request, which can be created by the Data Provider (giving the Data Provider maximum control). The registry responds to the registration request with a registration response which indicates if the registration was successful. In the event of an error, the error messages are returned as a registry exception within the response.
927 927  
928 -=== 7.4.2 The Registration Request ===
953 +===== {{id name="_Toc90824"/}}7.4.2 The Registration Request =====
929 929  
930 -==== 7.4.2.1 Registration Request Schematic ====
955 +**7.4.2.1 Registration Request Schematic**
931 931  
932 932  [[image:SDMX 3.1 Section 5_en_293a2ea6.jpg||height="337" width="554"]]
933 933  
934 934  **Figure 16: Schematic of the Objects Concerned with Registration**
935 935  
936 -==== 7.4.2.2 Registration Request Model ====
961 +**7.4.2.2 Registration Request Model**
937 937  
938 938  The following UML diagram shows the composition of the registration request. Each request is made up of one or more Registrations, one per dataset to be registered. The Registration can optionally have information, which has been extracted from the Registration:
939 939  
... ... @@ -945,11 +945,13 @@
945 945  
946 946  The Registration has an action attribute which takes one of the following values:
947 947  
973 +:
974 +
948 948  (((
949 -|(% style="width:224px" %)**Action Attribute Value**|(% style="width:1457px" %)**Behaviour**
950 -|(% style="width:224px" %)Append|(% style="width:1457px" %)Add this Registration to the registry
951 -|(% style="width:224px" %)Replace|(% style="width:1457px" %)Replace the existing Registration with identified by the id in the Registration of the SubmitRegistrationRequest
952 -|(% style="width:224px" %)Delete|(% style="width:1457px" %)Delete the existing Registration identified by the id in the Registration of the SubmitRegistrationRequest
976 +|**Action Attribute Value**|**Behaviour**
977 +|Append|Add this Registration to the registry
978 +|Replace|Replace the existing Registration with identified by the id in the Registration of the SubmitRegistrationRequest
979 +|Delete|Delete the existing Registration identified by the id in the Registration of the SubmitRegistrationRequest
953 953  )))
954 954  
955 955  [[image:SDMX 3.1 Section 5_en_90b3c64a.jpg||height="434" width="579"]]
... ... @@ -968,24 +968,30 @@
968 968  
969 969  https:~/~/github.com/sdmx-twg/sdmx-rest/blob/master/doc/availability.md
970 970  
998 +:
999 +
971 971  (((
972 -(% style="width:918.835px" %)
973 -|**Indexing Required**|(% style="width:745px" %)**Registration Process Activity**
974 -|indexTimeSeries|(% style="width:745px" %)Extract all the series keys and create a KeySet(s) Constraint.
975 -|indexDataSet|(% style="width:745px" %)Extract all the codes and other content of the Key value of the Series Key in a Data Set and create one or more Cube Regions containing Member Selections of Dimension Components of the Constraints model in the SDMX-IM, and the associated Selection Value.
976 -|indexReportingPeriod|(% style="width:745px" %)(((
1001 +|**Indexing Required**|**Registration Process Activity**
1002 +|indexTimeSeries|Extract all the series keys and create a KeySet(s) Constraint.
1003 +|indexDataSet|Extract all the codes and other content of the Key value of the Series Key in a Data Set and create one or more Cube Regions containing Member Selections of Dimension Components of the Constraints model in the SDMX-IM, and the associated Selection Value.
1004 +|indexReportingPeriod|(((
977 977  This applies only to a registered __dataset__.
1006 +
978 978  Extract the Reporting Begin and Reporting End from the Header of the Message containing the data set, and create a Reference Period constraint.
979 979  )))
980 -|indexAttributes|(% style="width:745px" %)(((
1009 +|indexAttributes|(((
981 981  **Data Set**
1011 +
982 982  Extract the content of the Attribute Values in a Data Set and create one or more Cube Regions containing Member Selections of Data Attribute Components of the Constraints model in the SDMXIM, and the associated Selection Value
983 983  
984 984  **Metadata Set**
985 -Indicate the presence of a Reported Attribute by creating one or more Cube Regions containing Member Selections of Metadata Attribute Components of the Constraints model in the
1015 +
1016 +Indicate the presence of a Reported Attribute by creating one or more Cube Regions containing Member Selections of Metadata Attribute
1017 +
1018 +Components of the Constraints model in the
986 986  )))
987 -|**Indexing Required**|(% style="width:745px" %)**Registration Process Activity**
988 -| |(% style="width:745px" %)SDMX-IM. Note that the content is not stored in the Selection Value.
1020 +|**Indexing Required**|**Registration Process Activity**
1021 +| |SDMX-IM. Note that the content is not stored in the Selection Value.
989 989  )))
990 990  
991 991  Constraints that specify the contents of a //QueryDatasource// are submitted to the Registry via the structure submission service (i.e., the RESTful API).