Changes for page Part IV. Data and Reference Metadata Namespaces
Last modified by Elena on 2025/09/10 11:19
Summary
-
Page properties (1 modified, 0 added, 0 removed)
Details
- Page properties
-
- Content
-
... ... @@ -788,27 +788,31 @@ 788 788 789 789 A complex type named AttsType must be created. Its content model will be derived via restriction of dsd:AttsType. The complex type content model will be as follows: 790 790 791 -1. A sequence consisting of: 792 -1. An element reference to common:Annotations, with a minimum occurrence of 0 793 - 2. If any attributes with complex representation are defined in the data structure, a Comp element with a form of unqualified, a minimum occurrence of 0, a maximum occurrence of unbounded, and a type of dsd:CompType 791 +~1. A sequence consisting of: 792 + 793 +* i. An element reference to common:Annotations, with a minimum occurrence of 0 794 +* ii. If any attributes with complex representation are defined in the data structure, a Comp element with a form of unqualified, a minimum occurrence of 0, a maximum occurrence of unbounded, and a type of dsd:CompType 795 + 794 794 2. If there is no dimension (TIME\_PERIOD) defined by the data structure, an attribute named TIME\_PERIOD with a type of common:ObservationalTimePeriod, and a usage of prohibited 795 -3. An attribute for all dimension defined by the data structure definition. The XML attribute [name](#331-Component-Name-Determination)and[type](#333-Simple--Primitive-Type-Determination) are defined according to the general rules defined in the previous section, and the usage is optional796 -4. An attribute for each data attribute defined with simple representation in the data structure. The XML attribute [name](#331-Component-Name-Determination)and[type](#333-Simple--Primitive-Type-Determination)are defined according to the general rules defined in the previous section, and the usage is optional797 +3. An attribute for all dimension defined by the data structure definition. The XML attribute name and type are defined according to the general rules defined in the previous section, and the usage is optional 798 +4. An attribute for each data attribute defined with simple representation in the data structure. The XML attribute name and type are defined according to the general rules defined in the previous section, and the usage is optional 797 797 798 798 === 3.4.5 ObsType === 799 799 800 800 A complex type name ObsType must be created. Its content model will be derived via restriction of the base type dsd:ObsType. The complex type content model will be as follows: 801 801 802 -1. A sequence consisting of: 803 -1. An element reference to common:Annotations, with a minimum occurrence of 0 804 - 2. If any measures with complex representations are defined in the data structure, any attributes with complex representation that declare an attribute relationship with the observation, a Comp element with a form of unqualified, a minimum occurrence of 0, a maximum occurrence of unbounded, and a type of dsd:CompType 805 - 3. If any metadata attribute usages defined in the data structure that declares an attribute relationship with the observation, a local element named Metadata with the type metadata:MetadataSetType a form of unqualified, and a minimum occurrence of 0 804 +~1. A sequence consisting of: 805 + 806 +* i. An element reference to common:Annotations, with a minimum occurrence of 0 807 +* ii. If any measures with complex representations are defined in the data structure, any attributes with complex representation that declare an attribute relationship with the observation, a Comp element with a form of unqualified, a minimum occurrence of 0, a maximum occurrence of unbounded, and a type of dsd:CompType 808 +* iii. If any metadata attribute usages defined in the data structure that declares an attribute relationship with the observation, a local element named Metadata with the type metadata:MetadataSetType a form of unqualified, and a minimum occurrence of 0 809 + 806 806 2. An attribute named TIME\_PERIOD with a type of common: 807 807 ObservationalTimePeriodValueType. If the dimension at the observation level is the time dimension (TIME\_PERIOD) or all dimensions and the time dimension is defined by the data structure, a usage of required; otherwise, a usage of prohibited 808 -3. If the dimension at the observation level is not all dimensions or the time dimension (TIME\_PERIOD), an attribute for the dimension at the observation level. The XML attribute [name](#331-Component-Name-Determination)and[type](#333-Simple--Primitive-Type-Determination) are defined according to the general rules defined in the previous section, and the usage is required809 -4. If the dimension at the observation level is all dimensions, an attribute for each dimension defined by the data structure definition, except for the time dimension (TIME\_PERIOD). The XML attribute [name](#331-Component-Name-Determination)and[type](#333-Simple--Primitive-Type-Determination)are defined according to the general rules defined in the previous section, and the usage is required810 -5. An attribute for each measure with simple representation defined by the data structure definition. The XML attribute [name](#331-Component-Name-Determination)and[type](#333-Simple--Primitive-Type-Determination) is defined according to the general rules defined in the previous section, and the usage is optional811 -6. An attribute for each data attribute with simple representation defined in the data structure that declares an attribute relationship with the observation. The XML attribute [name](#331-Component-Name-Determination)and[type](#333-Simple--Primitive-Type-Determination)are defined according to the general rules defined in the previous section, and the usage is optional812 +3. If the dimension at the observation level is not all dimensions or the time dimension (TIME\_PERIOD), an attribute for the dimension at the observation level. The XML attribute name and type are defined according to the general rules defined in the previous section, and the usage is required 813 +4. If the dimension at the observation level is all dimensions, an attribute for each dimension defined by the data structure definition, except for the time dimension (TIME\_PERIOD). The XML attribute name and type are defined according to the general rules defined in the previous section, and the usage is required 814 +5. An attribute for each measure with simple representation defined by the data structure definition. The XML attribute name and type is defined according to the general rules defined in the previous section, and the usage is optional 815 +6. An attribute for each data attribute with simple representation defined in the data structure that declares an attribute relationship with the observation. The XML attribute name and type are defined according to the general rules defined in the previous section, and the usage is optional 812 812 813 813 === 3.4.6 CompType === 814 814 ... ... @@ -839,7 +839,7 @@ 839 839 840 840 === 4.1.2 Replace Action === 841 841 842 -Data or data-related reference metadata is to be replaced, through either update, insert or delete depending on already existing information. A full replacement is hereby assumed to take place at specific “replacement levels”: for entire observations and for any specific dimension combination for data-related reference metadata attributes. Within these “replacement levels” the provided values are inserted or updated, and omitted values are deleted. Values provided for the other attributes (those above the observation level) are merged (see *Merge*action).846 +Data or data-related reference metadata is to be replaced, through either update, insert or delete depending on already existing information. A full replacement is hereby assumed to take place at specific “//replacement levels//”: for entire observations and for any specific dimension combination for data-related reference metadata attributes. Within these “replacement levels” the provided values are inserted or updated, and omitted values are deleted. Values provided for the other attributes (those above the observation level) are merged (see //Merge// action). 843 843 844 844 Only non-dimensional components (measure, attribute or reference metadata values) can be **omitted** (null or absent). Bulk replacing is thus not supported. 845 845 ... ... @@ -847,9 +847,9 @@ 847 847 848 848 Replacing non-existing elements is not resulting in an error. 849 849 850 -All observations as well as the sets of data-related reference metadata attributes at specific dimension combinations impacted by the *Replace*action change their time stamp when used to update an SDMX storage system.854 +All observations as well as the sets of data-related reference metadata attributes at specific dimension combinations impacted by the //Replace// action change their time stamp when used to update an SDMX storage system. 851 851 852 -Because the *replace*action always takes place at specific levels, it cannot be used to replace a whole dataset or a whole series. However, a “*replace all*” effect can be achieved by combining a*Delete*dataset containing a completely wildcarded key (where all dimension values are omitted) with a*Merge*or*Replace*dataset within the same data message. Similarly, to replace a whole series, a message can combine a*delete*dataset containing only the partial key of the series (where the not used dimension values are omitted) with a*Merge*or*Replace*dataset for that series.856 +Because the //replace// action always takes place at specific levels, it cannot be used to replace a whole dataset or a whole series. However, a //“replace all”// effect can be achieved by combining a //Delete// dataset containing a completely wildcarded key (where all dimension values are omitted) with a //Merge// or //Replace// dataset within the same data message. Similarly, to replace a whole series, a message can combine a //delete// dataset containing only the partial key of the series (where the not used dimension values are omitted) with a //Merge// or //Replace// dataset for that series. 853 853 854 854 === 4.1.3 Delete Action === 855 855 ... ... @@ -869,58 +869,59 @@ 869 869 870 870 The following convention is used to indicate the state of components in data messages: 871 871 872 -| | |**Dimension value is**| |**Measure, attribute or reference metadata value is**| | 873 -| | |**Omitted**|**switched off**|**Omitted**|**Present**| 874 -|Action|Delete|bulk deletion: dimension value doesn't matter|only for irrelevant dimensions:1) higher-level (reference metadata) attributes not attached to this dimension(incl. TIME\_PERIOD)2) measures and attributes not attached to this dimension if the DSD allows for an ‘evolving structure’ (excl. TIME\_PERIOD)|to be deleted only if **all** non-dimension components are omitted|to be deleted| 875 -| |Merge|*bulk merge is not permitted*|(see above)|not to be changed|to be updated/inserted| 876 -| |Replace|*bulk replace is not permitted*|(see above)|at permitted replacement levels: to be deleted, otherwise not to be changed|to be updated/inserted| 877 -|Format|XML|xml element/attribute is absent|~|xml element/attribute is absent|any valid or intentionally missing value| 878 -| |JSON|\<empty\>|““|NULL or absent|(see above)| 879 -| |CSV|\<empty\> cell or column is absent|~|<empty> cell or column is absent|(see above)| 876 +(% style="width:1364.29px" %) 877 +| | |(% style="width:260px" %)**Dimension value is**|(% style="width:391px" %) |(% style="width:383px" %)**Measure, attribute or reference metadata value is**|(% style="width:184px" %) 878 +| | |(% style="width:260px" %)**Omitted**|(% style="width:391px" %)**switched off**|(% style="width:383px" %)**Omitted**|(% style="width:184px" %)**Present** 879 +|Action|Delete|(% style="width:260px" %)bulk deletion: dimension value doesn't matter|(% style="width:391px" %)only for irrelevant dimensions:1) higher-level (reference metadata) attributes not attached to this dimension(incl. TIME\_PERIOD)2) measures and attributes not attached to this dimension if the DSD allows for an ‘evolving structure’ (excl. TIME\_PERIOD)|(% style="width:383px" %)to be deleted only if **all** non-dimension components are omitted|(% style="width:184px" %)to be deleted 880 +| |Merge|(% style="width:260px" %)//bulk merge is not permitted//|(% style="width:391px" %)(see above)|(% style="width:383px" %)not to be changed|(% style="width:184px" %)to be updated/inserted 881 +| |Replace|(% style="width:260px" %)//bulk replace is not permitted//|(% style="width:391px" %)(see above)|(% style="width:383px" %)at permitted replacement levels: to be deleted, otherwise not to be changed|(% style="width:184px" %)to be updated/inserted 882 +|Format|XML|(% style="width:260px" %)xml element/attribute is absent|(% style="width:391px" %)~|xml element/attribute is absent|(% style="width:383px" %)any valid or intentionally missing value|(% style="width:184px" %) 883 +| |JSON|(% style="width:260px" %)\<empty\>|(% style="width:391px" %)““|(% style="width:383px" %)NULL or absent|(% style="width:184px" %)(see above) 884 +| |CSV|(% style="width:260px" %)\<empty\> cell or column is absent|(% style="width:391px" %)~|<empty> cell or column is absent|(% style="width:383px" %)(see above)|(% style="width:184px" %) 880 880 881 881 **Important notes:** 882 882 883 -The terms “ *delete*”, “*merge*” and “*replace*” do **not** imply a physical replacement or deletion of values in the underlying database. To minimize the physical resource requirements, SDMX web service implementations that do not support the*includeHistory*and*asOf*URL parameters might physically replace the existing values in the database. SDMX web services that neither support the *updatedAfter* URL parameter might also implement physical deletions. However, SDMX web services that support these parameters (or other time-machine features), would not overwrite or delete the physical values.888 +The terms “//delete//”, “//merge//” and “//replace//” do **not** imply a physical replacement or deletion of values in the underlying database. To minimize the physical resource requirements, SDMX web service implementations that do not support the //includeHistory// and //asOf// URL parameters might physically replace the existing values in the database. SDMX web services that neither support the *updatedAfter* URL parameter might also implement physical deletions. However, SDMX web services that support these parameters (or other time-machine features), would not overwrite or delete the physical values. 884 884 885 -SDMX web services that support the *includeHistory*or*asOf*URL parameters should never allow deleting their **historic** data content because this would interfere with the interests of data consumers, such as data aggregators. Therefore, a specific feature to physically delete previous (outdated) content is intentionally not added to the SDMX standard syntax. If such a feature is required by an organisation, then it needs to be implemented as a custom feature outside the SDMX standard.890 +SDMX web services that support the //includeHistory// or //asOf// URL parameters should never allow deleting their **historic** data content because this would interfere with the interests of data consumers, such as data aggregators. Therefore, a specific feature to physically delete previous (outdated) content is intentionally not added to the SDMX standard syntax. If such a feature is required by an organisation, then it needs to be implemented as a custom feature outside the SDMX standard. 886 886 887 -Likewise, all SDMX-compliant systems that do (or are configured to) support the *updatedAfter*URL parameter need to systematically retain the information about deleted data (or data-related reference metadata).892 +Likewise, all SDMX-compliant systems that do (or are configured to) support the //updatedAfter// URL parameter need to systematically retain the information about deleted data (or data-related reference metadata). 888 888 889 -All datasets – even with varying actions – within a single data message have always to be treated as **ACID transaction** to guarantee “transactional safety” (full data consistency and validity despite errors, power failures, and other mishaps). These datasets are to be processed in the order of appearance in the message. The advantage of such data messages is thus the ability to bundle separate *delete*and*replace*or*merge*actions into one transactional data message.894 +All datasets – even with varying actions – within a single data message have always to be treated as **ACID transaction** to guarantee “transactional safety” (full data consistency and validity despite errors, power failures, and other mishaps). These datasets are to be processed in the order of appearance in the message. The advantage of such data messages is thus the ability to bundle separate //delete// and //replace// or //merge// actions into one transactional data message. 890 890 891 -**Recommended [^2]dataset actions in SDMX web service responses to GET data queries:**896 +**Recommended{{footnote}}So far this is recommended for systems that do not require backward-compatibility. Later, with SDMX 4.0, this may generally be made mandatory{{/footnote}} dataset actions in SDMX web service responses to GET data queries:** 892 892 893 -1. Without the *updatedAfter*, *includeHistory*, *detail*, *attributes* or *measures* URL parameters: 894 - 895 - The response message should contain the retrieved data in a *Replace* dataset (instead of the previous *information* dataset). 898 +~1. Without the //updatedAfter//, //includeHistory//, //detail//, //attributes// or //measures// URL parameters: 896 896 897 -1. Without the *updatedAfter* and *includeHistory*, but with *detail*, *attributes* or *measures* URL parameters: 898 - 899 - The response message should contain the retrieved data in a *Merge* dataset (instead of the previous *Information* dataset). 900 +The response message should contain the retrieved data in a //Replace// dataset (instead of the previous *information* dataset). 900 900 901 -1. With the *updatedAfter* URL parameter: 902 - 903 - The response must include the information of all previously updated, inserted and deleted data or data-related reference metadata, even if bulk deletions have been used. One of the two approaches are possible: 902 +2. Without the //updatedAfter// and //includeHistory//, but with //detail//, //attributes// or //measures// URL parameters: 904 904 905 -* a *Delete* dataset for entirely deleted observations and for entirely deleted sets of (data-related reference metadata) attribute values attached to specific dimension combinations and 906 - a *Replace* dataset for all other changed observations and changed attribute and data-related reference metadata values attached to specific dimension combinations, or 907 -* a *Delete* dataset for entirely deleted observations, for entirely deleted sets of (data-related reference metadata) attribute values attached to specific dimension combinations and for individually deleted mesure, attribute and reference metadata values and 908 - a *Merge* dataset for all other updated or inserted observation, attribute and data-related reference metadata values. 909 - 910 - The DB synchronization use case requires that the generated response must always allow achieving to replicate the exact same punctual data content as currently stored in the queried data source. 904 +The response message should contain the retrieved data in a //Merge// dataset (instead of the previous *Information* dataset). 911 911 912 -1. With the *includeHistory* URL parameter: 913 - 914 - Using a number of datasets with *Delete*, *Replace* or *Merge* actions and limited in their validity time span that allow achieving to replicate the exact same punctual data contents as previously stored in the queried data source. 906 +3. With the //updatedAfter// URL parameter: 915 915 916 -1. With the *asOf* URL parameter: 917 - 918 - The recommendations of 1 and 2 apply depending on the other parameters. In addition, the returned dataset should have its validity time span limited to the point in time requested in the *asOf* parameter. 908 +The response must include the information of all previously updated, inserted and deleted data or data-related reference metadata, even if bulk deletions have been used. One of the two approaches are possible: 919 919 920 -[^2]: So far this is recommended for systems that do not require backward-compatibility. Later, with SDMX 4.0, this may generally be made mandatory. 910 +* a //Delete// dataset for entirely deleted observations and for entirely deleted sets of (data-related reference metadata) attribute values attached to specific dimension combinations and 911 +a //Replace// dataset for all other changed observations and changed attribute and data-related reference metadata values attached to specific dimension combinations, or 912 +* a //Delete// dataset for entirely deleted observations, for entirely deleted sets of (data-related reference metadata) attribute values attached to specific dimension combinations and for individually deleted mesure, attribute and reference metadata values and 913 +a //Merge// dataset for all other updated or inserted observation, attribute and data-related reference metadata values. 921 921 915 +The DB synchronization use case requires that the generated response must always allow achieving to replicate the exact same punctual data content as currently stored in the queried data source. 916 + 917 +~1. With the *includeHistory* URL parameter: 918 + 919 +Using a number of datasets with *Delete*, *Replace* or *Merge* actions and limited in their validity time span that allow achieving to replicate the exact same punctual data contents as previously stored in the queried data source. 920 + 921 +2. With the *asOf* URL parameter: 922 + 923 +The recommendations of 1 and 2 apply depending on the other parameters. In addition, the returned dataset should have its validity time span limited to the point in time requested in the *asOf* parameter. 924 + 922 922 == 4.2 Reference Metadata Actions == 923 923 924 924 Reference metadata defined by a Metadataflow or a MetadataProvisionAgreement are exchanged within reference metadatasets, which are maintainable and thus for actions behave like structural metadata (artefacts): When interacting with SDMX Rest web services, the HTTP action verbs GET, PUT and POST are used to indicate the intended action per web request. Consequently, different actions cannot be bundled and executed with “transactional ACIDity”. Note that metadatasets retrieved using the HTTP header “Accept-Language” may contain only partial languages, and thus should be marked with its *isPartialLanguage* property set to true. Submitting such a partial metadataset to update an SDMX storage system will only add or update the included languages but not change other languages. 925 925 926 926 The former message header or metadataset property *DataSetAction* is deprecated. To avoid conflicts, it is now ignored if still present. 930 + 931 +{{putFootnotes/}}