Skip to Content
Last modified by Artur on 2025/08/19 10:43
From version 7.8
edited by Helena
on 2025/05/21 22:20
Change comment: There is no comment for this version
To version 6.1
edited by Helena
on 2025/05/21 21:55
Change comment: There is no comment for this version

Summary

Details

Page properties
Content
... ... @@ -69,15 +69,13 @@
69 69  
70 70  To allow for applications which only understand time series data, variations of these formats have been introduced in the form of two data messages; //GenericTimeSeriesData// and //StructureSpecificTimeSeriesData//. It is important to note that these variations are built on the same root structure and can be processed in the same manner as the base format so that they do NOT introduce additional processing requirements.
71 71  
72 -(% class="wikigeneratedid" id="HStructureDefinition" %)
73 -**//Structure Definition//**
72 +=== //Structure Definition// ===
74 74  
75 75  The SDMX-ML Structure Message supports the use of annotations to the structure, which is not supported by the SDMX-EDI syntax.
76 76  
77 77  The SDMX-ML Structure Message allows for the structures on which a Data Structure Definition depends – that is, codelists and concepts – to be either included in the message or to be referenced by the message containing the data structure definition. XML syntax is designed to leverage URIs and other Internet-based referencing mechanisms, and these are used in the SDMX-ML message. This option is not available to those using the SDMX-EDI structure message.
78 78  
79 -(% class="wikigeneratedid" id="HValidation" %)
80 -**//Validation//**
78 +=== //Validation// ===
81 81  
82 82  SDMX-EDI – as is typical of EDIFACT syntax messages – leaves validation to dedicated applications (“validation” being the checking of syntax, data typing, and adherence of the data message to the structure as described in the structural definition.)
83 83  
... ... @@ -85,22 +85,19 @@
85 85  
86 86  The SDMX-ML DSD-specific messages will allow validation of XML syntax and datatyping to be performed with a generic XML parser, and enforce agreement between the structural definition and the data to a moderate degree with the same tool.
87 87  
88 -(% class="wikigeneratedid" id="HUpdateandDeleteMessagesandDocumentationMessages" %)
89 -//Update and Delete Messages and Documentation Messages//
86 +=== //Update and Delete Messages and Documentation Messages// ===
90 90  
91 91  All SDMX data messages allow for both delete messages and messages consisting of only data or only documentation.
92 92  
93 -(% class="wikigeneratedid" id="HCharacterEncodings" %)
94 -**//Character Encodings//**
90 +=== //Character Encodings// ===
95 95  
96 96  All SDMX-ML messages use the UTF-8 encoding, while SDMX-EDI uses the ISO 8879-1 character encoding. There is a greater capacity with UTF-8 to express some character sets (see the “APPENDIX: MAP OF ISO 8859-1 (UNOC) CHARACTER SET (LATIN 1 OR “WESTERN”) in the document “SYNTAX AND DOCUMENTATION VERSION 2.0”.) Many transformation tools are available which allow XML instances with UTF-8 encodings to be expressed as ISO 8879-1-encoded characters, and to transform UTF-8 into ISO 8879-1. Such tools should be used when transforming SDMX-ML messages into SDMX-EDI messages and vice-versa.
97 97  
98 -(% class="wikigeneratedid" id="HDataTyping" %)
99 -**//Data Typing//**
94 +=== //Data Typing// ===
100 100  
101 101  The XML syntax and EDIFACT syntax have different data-typing mechanisms. The section below provides a set of conventions to be observed when support for messages in both syntaxes is required. For more information on the SDMX-ML representations of data, see below.
102 102  
103 -=== 3.3.2 Data Types ===
98 +==== 3.3.2 Data Types ====
104 104  
105 105  The XML syntax has a very different mechanism for data-typing than the EDIFACT syntax, and this difference may create some difficulties for applications which support both EDIFACT-based and XML-based SDMX data formats. This section provides a set of conventions for the expression in data in all formats, to allow for clean interoperability between them.
106 106  
... ... @@ -414,7 +414,7 @@
414 414  
415 415  This is used to unambiguously state that a date-time represents an observation at a single point in time. Therefore, if one wants to use SDMX for data which is measured at a distinct point in time rather than being reported over a period, the date-time representation can be used.
416 416  
417 -Representation: xs:dateTime (YYYY-MM-DDThh:mm:ss)[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^~[1~]^^>>path:#_ftn1]]
412 +Representation: xs:dateTime (YYYY-MM-DDThh:mm:ss)[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^~[1~]^^>>path:#_ftn1]]
418 418  
419 419  === 4.2.6 Standard Reporting Period ===
420 420  
... ... @@ -463,7 +463,7 @@
463 463  Period Duration: P7D (seven days)
464 464  Limit per year: 53
465 465  Representation: common:ReportingWeekType (YYYY-Www, e.g. 2000-W53)
466 -Notes: There are either 52 or 53 weeks in a reporting year. This is based on the ISO 8601 definition of a week (Monday - Saturday), where the first week of a reporting year is defined as the week with the first Thursday on or after the reporting year start day.[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^~[2~]^^>>path:#_ftn2]](%%) The reporting week is always represented as two digits, therefore 1-9 are 0 padded (e.g. 01). This allows the values to be sorted chronologically using textual sorting methods.
461 +Notes: There are either 52 or 53 weeks in a reporting year. This is based on the ISO 8601 definition of a week (Monday - Saturday), where the first week of a reporting year is defined as the week with the first Thursday on or after the reporting year start day.[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^~[2~]^^>>path:#_ftn2]](%%) The reporting week is always represented as two digits, therefore 1-9 are 0 padded (e.g. 01). This allows the values to be sorted chronologically using textual sorting methods.
467 467  
468 468  **Reporting Day**:
469 469  Period Indicator: D
... ... @@ -486,7 +486,7 @@
486 486  ~1. If [REPORTING_YEAR_START_DATE] is a Friday, Saturday, or Sunday:**
487 487  Add^^3^^ (P3D, P2D, or P1D respectively) to the [REPORTING_YEAR_START_DATE]. The result is the [REPORTING_YEAR_BASE].
488 488  
489 -2. **If [REPORTING_YEAR_START_DATE] is a Monday, Tuesday, Wednesday, or Thursday:**
484 +​​​​​​​2. **If [REPORTING_YEAR_START_DATE] is a Monday, Tuesday, Wednesday, or Thursday:**
490 490  Add^^3^^ (P0D, -P1D, -P2D, or -P3D respectively) to the [REPORTING_YEAR_START_DATE]. The result is the [REPORTING_YEAR_BASE].
491 491  b) **Else:** 
492 492  The [REPORTING_YEAR_START_DATE] is the [REPORTING_YEAR_BASE]
... ... @@ -502,7 +502,7 @@
502 502  g) If the [PERIOD_INDICATOR] is D, the [PERIOD_DURATION] is P1D.
503 503  
504 504  **3. Determine [PERIOD_START]:**
505 -Subtract one from the [PERIOD_VALUE] and multiply this by the [PERIOD_DURATION]. Add[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^~[3~]^^>>path:#_ftn3]](%%) this to the [REPORTING_YEAR_BASE]. The result is the [PERIOD_START].
500 +Subtract one from the [PERIOD_VALUE] and multiply this by the [PERIOD_DURATION]. Add[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^~[3~]^^>>path:#_ftn3]](%%) this to the [REPORTING_YEAR_BASE]. The result is the [PERIOD_START].
506 506  
507 507  **4. Determine the [PERIOD_END]:**
508 508  Multiply the [PERIOD_VALUE] by the [PERIOD_DURATION]. Add^^3^^ this to the [REPORTING_YEAR_BASE] add^^3^^ -P1D. The result is the [PERIOD_END].
... ... @@ -647,7 +647,9 @@
647 647  **Examples:**
648 648  
649 649  **Gregorian Period**
645 +
650 650  Query Parameter: Greater than 2010
647 +
651 651  Literal Interpretation: Any data where the start period occurs after 2010-1231T23:59:59.
652 652  
653 653  Example Matches:
... ... @@ -665,11 +665,15 @@
665 665  * 2010-D185 or later (reporting year start day ~-~-07-01 or later)
666 666  
667 667  **Reporting Period with explicit start day**
665 +
668 668  Query Parameter: Greater than or equal to 2009-Q3, reporting year start day = "-07-01"
667 +
669 669  Literal Interpretation: Any data where the start period occurs on after 2010-0101T00:00:00 (Note that in this case 2009-Q3 is converted to the explicit date range of 2010-01-01/2010-03-31 because of the reporting year start day value). Example Matches: Same as previous example
670 670  
671 671  **Reporting Period with "Any" start day**
671 +
672 672  Query Parameter: Greater than or equal to 2010-Q3, reporting year start day = "Any"
673 +
673 673  Literal Interpretation: Any data with a reporting period where the start period is on or after the start period of 2010-Q3 for the same reporting year start day, or and data where the start period is on or after 2010-07-01. Example Matches:
674 674  
675 675  * 2011 or later
... ... @@ -681,10 +681,13 @@
681 681  * 2010-T3 (any reporting year start day)
682 682  * 2010-Q3 or later (any reporting year start day)
683 683  * 2010-M07 or later (any reporting year start day)
684 -* 2010-W27 or later (reporting year start day ~-~-01-01){{footnote}}2010-Q3 (with a reporting year start day of --01-01) starts on 2010-07-01. This is day 4 of week 26, therefore the first week matched is week 27.{{/footnote}}  2010-D182 or later (reporting year start day ~-~-01-01)
685 -* 2010-W28 or later (reporting year start day ~-~-07-01){{footnote}}2010-Q3 (with a reporting year start day of --07-01) starts on 2011-01-01. This is day 6 of week 27, therefore the first week matched is week 28.{{/footnote}}
686 -* 2010-D185 or later (reporting year start day ~-~-07-01)
685 +* 2010-W27 or later (reporting year start day ~-~-01-01)^^4^^  2010-D182 or later (reporting year start day ~-~-01-01)
686 +* 2010-W28 or later (reporting year start day ~-~-07-01)^^5^^
687 687  
688 +^^4^^ 2010-Q3 (with a reporting year start day of ~-~-01-01) starts on 2010-07-01. This is day 4 of week 26, therefore the first week matched is week 27.
689 +
690 + 2010-D185 or later (reporting year start day ~-~-07-01)
691 +
688 688  == 4.3 Structural Metadata Querying Best Practices ==
689 689  
690 690  When querying for structural metadata, the ability to state how references should be resolved is quite powerful. However, this mechanism is not always necessary and can create an undue burden on the systems processing the queries if it is not used properly.
... ... @@ -701,6 +701,8 @@
701 701  
702 702  This mechanism is an “early binding” one – everything with a versioned identity is a known quantity, and will not change. It is worth pointing out that in some cases relationships are essentially one-way references: an illustrative case is that of Categories. While a Category may be referenced by many dataflows and metadata flows, the addition of more references from flow objects does not version the Category. This is because the flows are not properties of the Categories – they merely make references to it. If the name of a Category changed, or its subCategories changed, then versioning would be necessary.
703 703  
708 +^^5^^ 2010-Q3 (with a reporting year start day of ~-~-07-01) starts on 2011-01-01. This is day 6 of week 27, therefore the first week matched is week 28.
709 +
704 704  Versioning operates at the level of versionable and maintainable objects in the SDMX information model. If any of the children of objects at these levels change, then the objects themselves are versioned.
705 705  
706 706  One area which is much impacted by this versioning scheme is the ability to reference external objects. With the many dependencies within the various structural objects in SDMX, it is useful to have a scheme for external referencing. This is done at the level of maintainable objects (DSDs, code lists, concept schemes, etc.) In an SDMX-ML Structure Message, whenever an “isExternalReference” attribute is set to true, then the application must resolve the address provided in the associated “uri” attribute and use the SDMX-ML Structure Message stored at that location for the full definition of the object in question. Alternately, if a registry “urn” attribute has been provided, the registry can be used to supply the full details of the object.
... ... @@ -723,13 +723,13 @@
723 723  
724 724  [[image:1747836776649-282.jpeg]]
725 725  
726 -**Figure 1: Schematic of the Metadata Structure Definition**
732 +1. **1: Schematic of the Metadata Structure Definition**
727 727  
728 728  The MSD comprises the specification of the object types to which metadata can be reported in a Metadata Set (Metadata Target(s)), and the Report Structure(s) comprising the Metadata Attributes that identify the Concept for which metadata may be reported in the Metadata Set. Importantly, one Report Structure references the Metadata Target for which it is relevant. One Report Structure can reference many Metadata Target i.e. the same Report Structure can be used for different target objects.
729 729  
730 730  [[image:1747836776655-364.jpeg]]
731 731  
732 -**Figure 2: Example MSD showing Metadata Targets**
738 +1. **2: Example MSD showing Metadata Targets**
733 733  
734 734  Note that the SDMX-ML schemas have explicit XML elements for each identifiable object type because identifying, for instance, a Maintainable Object has different properties from an Identifiable Object which must also include the agencyId, version, and id of the Maintainable Object in which it resides.
735 735  
... ... @@ -739,10 +739,8 @@
739 739  
740 740  [[image:1747836776658-510.jpeg]]
741 741  
742 -**Figure 3: Example MSD showing specification of three Metadata Attributes**
748 +**Figure 3: Example MSD showing specification of three Metadata Attributes **This example shows the following hierarchy of Metadata Attributes:
743 743  
744 -This example shows the following hierarchy of Metadata Attributes:
745 -
746 746  Source – this is presentational and no metadata is expected to be reported at this level
747 747  
748 748  * Source Type
... ... @@ -756,7 +756,10 @@
756 756  
757 757   **Figure 4: Example Metadata Set **This example shows:
758 758  
759 -1. The reference to the MSD, Metadata Report, and Metadata Target (MetadataTargetValue)
763 +1. The reference to the MSD, Metadata Report, and Metadata Target
764 +
765 +(MetadataTargetValue)
766 +
760 760  1. The reported metadata attributes (AttributeValueSet)
761 761  
762 762  = 6 Maintenance Agencies =
... ... @@ -813,9 +813,8 @@
813 813  
814 814  The Information Model for this is shown below:
815 815  
816 -[[image:1747855024745-946.png]]
817 817  
818 -**Figure 8: Information Model Extract for Concept Role**
824 + **Figure 8: Information Model Extract for Concept Role**
819 819  
820 820  It is possible to specify zero or more concept roles for a Dimension, Measure Dimension and Data Attribute (but not the ReportingYearStartDay). The Time Dimension, Primary Measure, and the  Attribute ReportingYearStartDay have explicitly defined roles and cannot be further specified with additional concept roles.
821 821  
... ... @@ -835,14 +835,13 @@
835 835  
836 836  The Cross-Domain Concept Scheme maintained by SDMX contains concept role concepts (FREQ chosen as an example).
837 837  
838 -[[image:1747855054559-410.png]]
844 +[[image:1747836776691-440.jpeg]]
839 839  
840 -
841 841  Whether this is a role or not depends upon the application understanding that FREQ in the Cross-Domain Concept Scheme is a role of Frequency.
842 842  
843 843  Using a Concept Scheme that is not the Cross-Domain Concept Scheme where it is required to assign a role using the Cross-Domain Concept Scheme. Again FREQ is chosen as the example.
844 844  
845 -[[image:1747855075263-887.png]]
850 +[[image:1747836776693-898.jpeg]]
846 846  
847 847  
848 848  This explicitly states that this Dimension is playing a role identified by the FREQ concept in the Cross-Domain Concept Scheme. Again the application needs to understand what FREQ in the Cross-Domain Concept Scheme implies in terms of a role.
... ... @@ -892,7 +892,7 @@
892 892  
893 893  == 8.3 Rules for a Content Constraint ==
894 894  
895 -=== 8.3.1 (% style="color:inherit; font-family:inherit; font-size:max(21px, min(23px, 17.4444px + 0.462963vw))" %)Scope of a Content Constraint(%%) ===
900 +=== 8.3.1 Scope of a Content Constraint ===
896 896  
897 897  A Content Constraint is used specify the content of a data or metadata source in terms of the component values or the keys.
898 898  
... ... @@ -931,29 +931,29 @@
931 931  
932 932  In view of the flexibility of constraints attachment, clear rules on their usage are required. These are elaborated below.
933 933  
934 -=== 8.3.2 Multiple Content Constraints ===
939 +=== 8.3.2 Multiple Content Constraints ===
935 935  
936 936  There can be many Content Constraints for any Constrainable Artefact (e.g. DSD), subject to the following restrictions:
937 937  
938 -==== 8.3.2.1 Cube Region ====
943 +**8.3.2.1 Cube Region**
939 939  
940 940  1. The constraint can contain multiple Member Selections (e.g. Dimension) but:
941 941  1. A specific  Member Selection (e.g. Dimension FREQ)  can only be contained in one Content Constraint for any one attached object (e.g. a specific DSD or specific Dataflow)
942 942  
943 -==== 8.3.2.2 Key Set ====
948 +**8.3.2.2 Key Set**
944 944  
945 945  Key Sets will be processed in the order they appear in the Constraint and wildcards can be used (e.g. any key position not reference explicitly is deemed to be “all values”). As the Key Sets can be “included” or “excluded” it is recommended that Key Sets with wildcards are declared before KeySets with specific series keys. This will minimize the risk that keys are inadvertently included or excluded.  
946 946  
947 -=== 8.3.3 Inheritance of a Content Constraint ===
952 +=== 8.3.3 Inheritance of a Content Constraint ===
948 948  
949 -==== 8.3.3.1 Attachment levels of a Content Constraint ====
954 +**8.3.3.1 Attachment levels of a Content Constraint**
950 950  
951 951  There are three levels of constraint attachment for which these inheritance rules apply:
952 952  
953 -* DSD/MSD – top level
954 -** Dataflow/Metadataflow – second level
955 -*** Provision Agreement – third level
958 + DSD/MSD – top level o Dataflow/Metadataflow – second level
956 956  
960 +§ Provision Agreement – third level
961 +
957 957  Note that these rules do not apply to the Simple Datasoucre or Queryable Datasource: the Content Constraint(s) attached to these artefacts are resolved for this artefact only and do not take into account Constraints attached to other artefacts (e.g. Provision Agreement. Dataflow, DSD).
958 958  
959 959  It is not necessary for a Content Constraint to be attached to higher level artifact. e.g. it is valid to have a Content Constraint for a Provision Agreement where there are no constraints attached the relevant dataflow or DSD.
... ... @@ -1167,7 +1167,7 @@
1167 1167  
1168 1168  == 10.1 Introduction ==
1169 1169  
1170 -The Validation and Transformation Language (VTL) supports the definition of Transformations, which are algorithms to calculate new data starting from already existing ones[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^~[4~]^^>>path:#_ftn4]](%%). The purpose of the VTL in the SDMX context is to enable the:
1175 +The Validation and Transformation Language (VTL) supports the definition of Transformations, which are algorithms to calculate new data starting from already existing ones[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^~[4~]^^>>path:#_ftn4]](%%). The purpose of the VTL in the SDMX context is to enable the:
1171 1171  
1172 1172  * definition of validation and transformation algorithms, in order to specify how to calculate new data  from existing ones;
1173 1173  * exchange of the definition of VTL algorithms, also together the definition of the data structures of the involved data (for example, exchange the data structures of a reporting framework together with the validation rules to be applied, exchange the input and output data structures of a calculation task together with the VTL Transformations describing the calculation algorithms);
... ... @@ -1191,7 +1191,7 @@
1191 1191  
1192 1192  In any case, the aliases used in the VTL transformations have to be mapped to the
1193 1193  
1194 -SDMX artefacts through the VtlMappingScheme and VtlMapping classes (see the section of the SDMX IM relevant to the VTL). A VtlMapping allows specifying the aliases to be used in the VTL transformations, rulesets[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^~[5~]^^>>path:#_ftn5]](%%) or user defined operators[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^~[6~]^^>>path:#_ftn6]](%%)  to reference SDMX artefacts. A VtlMappingScheme is a container for zero or more VtlMapping. 
1199 +SDMX artefacts through the VtlMappingScheme and VtlMapping classes (see the section of the SDMX IM relevant to the VTL). A VtlMapping allows specifying the aliases to be used in the VTL transformations, rulesets[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^~[5~]^^>>path:#_ftn5]](%%) or user defined operators[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^~[6~]^^>>path:#_ftn6]](%%)  to reference SDMX artefacts. A VtlMappingScheme is a container for zero or more VtlMapping. 
1195 1195  
1196 1196  The correspondence between an alias and a SDMX artefact must be one-to-one, meaning that a generic alias  identifies one and just one SDMX artefact while a SDMX artefact is identified by one and just one alias. In other words, within a VtlMappingScheme an artefact can have just one alias and different artefacts cannot have the same alias.
1197 1197  
... ... @@ -1201,7 +1201,7 @@
1201 1201  
1202 1202  This approach has the advantage that in the VTL code the URN of the referenced artefacts is directly intelligible by a human reader but has the drawback that the references are verbose.
1203 1203  
1204 -The SDMX URN[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^~[7~]^^>>path:#_ftn7]](%%) is the concatenation of the following parts, separated by special symbols like dot, equal, asterisk, comma, and parenthesis:^^ ^^
1209 +The SDMX URN[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^~[7~]^^>>path:#_ftn7]](%%) is the concatenation of the following parts, separated by special symbols like dot, equal, asterisk, comma, and parenthesis:^^ ^^
1205 1205  
1206 1206  * SDMXprefix                                                                                   
1207 1207  * SDMX-IM-package-name             
... ... @@ -1209,7 +1209,7 @@
1209 1209  * agency-id                                                                          
1210 1210  * maintainedobject-id
1211 1211  * maintainedobject-version
1212 -* container-object-id [[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^~[8~]^^>>path:#_ftn8]]
1217 +* container-object-id [[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^~[8~]^^>>path:#_ftn8]]
1213 1213  * object-id
1214 1214  
1215 1215  The generic structure of the URN is the following:
... ... @@ -1228,7 +1228,7 @@
1228 1228  
1229 1229  The **agency-id** is the acronym of the agency that owns the definition of the artefact, for example for the Eurostat artefacts the agency-id is “ESTAT”). The agency-id can be composite (for example AgencyA.Dept1.Unit2).
1230 1230  
1231 -The **maintainedobject-id** is the name of the maintained object which the artefact belongs to, and in case the artefact itself is maintainable[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^~[9~]^^>>path:#_ftn9]](%%), coincides with the name of the artefact. Therefore the maintainedobject-id depends on the class of the artefact:
1236 +The **maintainedobject-id** is the name of the maintained object which the artefact belongs to, and in case the artefact itself is maintainable[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^~[9~]^^>>path:#_ftn9]](%%), coincides with the name of the artefact. Therefore the maintainedobject-id depends on the class of the artefact:
1232 1232  
1233 1233  * if the artefact is a ,,Dataflow,,, which is a maintainable class,  the maintainedobject-id is the Dataflow name (dataflow-id);
1234 1234  * if the artefact is a Dimension, MeasureDimension, TimeDimension, PrimaryMeasure or DataAttribute, which are not maintainable and belong to the ,,DataStructure,, maintainable class, the maintainedobject-id is the name of the DataStructure (dataStructure-id) which the artefact belongs to;
... ... @@ -1248,7 +1248,7 @@
1248 1248  
1249 1249  * if the artefact is a ,,Concept ,,(the object-id is the name of the ,,Concept,,)
1250 1250  
1251 -For example, by using the URN, the VTL transformation that sums two SDMX dataflows DF1 and DF2 and assigns the result to a third persistent dataflow DFR, assuming that DF1, DF2  and  DFR are the maintainedobject-id of the three dataflows, that their version is 1.0 and their Agency is AG, would be written as[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^~[10~]^^>>path:#_ftn10]](%%):
1256 +For example, by using the URN, the VTL transformation that sums two SDMX dataflows DF1 and DF2 and assigns the result to a third persistent dataflow DFR, assuming that DF1, DF2  and  DFR are the maintainedobject-id of the three dataflows, that their version is 1.0 and their Agency is AG, would be written as[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^~[10~]^^>>path:#_ftn10]](%%):
1252 1252  
1253 1253  ‘urn:sdmx:org.sdmx.infomodel.datastructure.Dataflow=AG:DFR(1.0)’  <-
1254 1254  
... ... @@ -1266,14 +1266,14 @@
1266 1266  * The **SDMX-IM-package-name **can be omitted as well because it can be deduced from the class-name that follows it (the table of the SDMX-IM packages and classes that allows this deduction is in the SDMX 2.1 Standards - Section 5 -  Registry Specifications, paragraph 6.2.3). In particular, considering the object classes of the artefacts that VTL can reference, the package is: 
1267 1267  ** “datastructure” for the classes Dataflow, Dimension, MeasureDimension, TimeDimension, PrimaryMeasure, DataAttribute,  
1268 1268  ** “conceptscheme” for the classes Concept and ConceptScheme o “codelist” for the class Codelist.
1269 -* The **class-name** can be omitted as it can be deduced from the VTL invocation.  In particular, starting from the VTL class of the invoked artefact (e.g. dataset, component, identifier, measure, attribute, variable, valuedomain),  which is known given the syntax of the invoking VTL operator[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^~[11~]^^>>path:#_ftn11]](%%), the SDMX class can be deduced from the mapping rules between VTL and SDMX (see the section “Mapping between VTL and SDMX” hereinafter)[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^~[12~]^^>>path:#_ftn12]](%%).
1270 -* If the **agency-id** is not specified, it is assumed by default equal to the agency-id of the TransformationScheme, UserDefinedOperatorScheme or RulesetScheme from which the artefact is invoked. For example, the agency-id can be omitted if it is the same as the invoking T,,ransformationScheme,, and cannot be omitted if the artefact comes from another agency.[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^~[13~]^^>>path:#_ftn13]](%%)  Take also into account that, according to the VTL consistency rules, the agency of the result of a ,,Transformation,, must be the same as its ,,TransformationScheme,,, therefore the agency-id can be omitted for all the results (left part of ,,Transformation,, statements).
1274 +* The **class-name** can be omitted as it can be deduced from the VTL invocation.  In particular, starting from the VTL class of the invoked artefact (e.g. dataset, component, identifier, measure, attribute, variable, valuedomain),  which is known given the syntax of the invoking VTL operator[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^~[11~]^^>>path:#_ftn11]](%%), the SDMX class can be deduced from the mapping rules between VTL and SDMX (see the section “Mapping between VTL and SDMX” hereinafter)[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^~[12~]^^>>path:#_ftn12]](%%).
1275 +* If the **agency-id** is not specified, it is assumed by default equal to the agency-id of the TransformationScheme, UserDefinedOperatorScheme or RulesetScheme from which the artefact is invoked. For example, the agency-id can be omitted if it is the same as the invoking T,,ransformationScheme,, and cannot be omitted if the artefact comes from another agency.[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^~[13~]^^>>path:#_ftn13]](%%)  Take also into account that, according to the VTL consistency rules, the agency of the result of a ,,Transformation,, must be the same as its ,,TransformationScheme,,, therefore the agency-id can be omitted for all the results (left part of ,,Transformation,, statements).
1271 1271  * As for the **maintainedobject-id**, this is essential in some cases while in other cases it can be omitted: o if the referenced artefact is a ,,Dataflow,,, which is a maintainable class, the maintainedobject-id is the dataflow-id and obviously cannot be omitted;
1272 1272  ** if the referenced artefact is a Dimension, MeasureDimension, TimeDimension, PrimaryMeasure, DataAttribute, which are not maintainable and belong to the ,,DataStructure,, maintainable class, the maintainedobject-id is the dataStructure-id and can be omitted, given that these components are always invoked within the invocation of a ,,Dataflow,,, whose dataStructure-id can be deduced from the
1273 1273  
1274 1274  SDMX structural definitions;  o if the referenced artefact is a ,,Concept, ,,which is not maintainable and belong to the ,,ConceptScheme ,,maintainable class,,, ,,the maintained object is the conceptScheme-id and cannot be omitted;
1275 1275  
1276 -*
1281 +*
1277 1277  ** if the referenced artefact is a ,,ConceptScheme, ,,which is a,, ,,maintainable class,,, ,,the maintained object is the ,,conceptScheme-id,, and obviously cannot be omitted;
1278 1278  ** if the referenced artefact is a ,,Codelist, ,,which is a maintainable class, the maintainedobject-id is the ,,codelist-id,, and obviously cannot be omitted.
1279 1279  * When the maintainedobject-id is omitted, the **maintainedobject-version** is omitted too. When the maintainedobject-id is not omitted and the maintainedobject-version is omitted, the version 1.0 is assumed by default.,, ,,
... ... @@ -1294,11 +1294,11 @@
1294 1294  
1295 1295  DFR  :=  DF1 + DF2
1296 1296  
1297 -The references to the ,,Codelists,, can be simplified similarly. For example, given the non-abbreviated reference to the ,,Codelist,,  AG:CL_FREQ(1.0), which is[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^~[14~]^^>>path:#_ftn14]](%%):
1302 +The references to the ,,Codelists,, can be simplified similarly. For example, given the non-abbreviated reference to the ,,Codelist,,  AG:CL_FREQ(1.0), which is[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^~[14~]^^>>path:#_ftn14]](%%):
1298 1298  
1299 1299  ‘urn:sdmx:org.sdmx.infomodel.codelist.Codelist=AG:CL_FREQ(1.0)’
1300 1300  
1301 -if the ,,Codelist,, is referenced from a ruleset scheme belonging to the agency AG, omitting all the optional parts, the abbreviated reference would become simply[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^~[15~]^^>>path:#_ftn15]](%%):
1306 +if the ,,Codelist,, is referenced from a ruleset scheme belonging to the agency AG, omitting all the optional parts, the abbreviated reference would become simply[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^~[15~]^^>>path:#_ftn15]](%%):
1302 1302  
1303 1303  CL_FREQ
1304 1304  
... ... @@ -1308,7 +1308,7 @@
1308 1308  
1309 1309  SECTOR
1310 1310  
1311 -For example, the transformation for renaming the component SECTOR of the dataflow DF1 into SEC can be written as[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^~[16~]^^>>path:#_ftn16]](%%):
1316 +For example, the transformation for renaming the component SECTOR of the dataflow DF1 into SEC can be written as[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^~[16~]^^>>path:#_ftn16]](%%):
1312 1312  
1313 1313  ‘DFR(1.0)’ := ‘DF1(1.0)’ [rename SECTOR to SEC]
1314 1314  
... ... @@ -1342,9 +1342,9 @@
1342 1342  
1343 1343  The VTL Rulesets have a signature, in which the Value Domains or the Variables on which the Ruleset is defined are declared, and a body, which contains the rules. 
1344 1344  
1345 -In the signature, given the mapping between VTL and SDMX better described in the following paragraphs, a reference to a VTL Value Domain becomes a reference to a SDMX Codelist or to a SDMX ConceptScheme (for SDMX measure dimensions), while a reference to a VTL Represented Variable becomes a reference to a SDMX Concept, assuming for it a definite representation[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^~[17~]^^>>path:#_ftn17]](%%).
1350 +In the signature, given the mapping between VTL and SDMX better described in the following paragraphs, a reference to a VTL Value Domain becomes a reference to a SDMX Codelist or to a SDMX ConceptScheme (for SDMX measure dimensions), while a reference to a VTL Represented Variable becomes a reference to a SDMX Concept, assuming for it a definite representation[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^~[17~]^^>>path:#_ftn17]](%%).
1346 1346  
1347 -In general, for referencing SDMX Codelists and Concepts, the conventions described in the previous paragraphs apply. In the Ruleset syntax, the elements that reference SDMX artefacts are called “valueDomain” and “variable” for the Datapoint Rulesets and “ruleValueDomain”, “ruleVariable”, “condValueDomain” “condVariable” for the Hierarchical Rulesets). The syntax of the Ruleset signature allows also to define aliases of the elements above, these aliases are valid only within the specific ruleset definition statement and cannot be mapped to SDMX.[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^~[18~]^^>>path:#_ftn18]](%%)
1352 +In general, for referencing SDMX Codelists and Concepts, the conventions described in the previous paragraphs apply. In the Ruleset syntax, the elements that reference SDMX artefacts are called “valueDomain” and “variable” for the Datapoint Rulesets and “ruleValueDomain”, “ruleVariable”, “condValueDomain” “condVariable” for the Hierarchical Rulesets). The syntax of the Ruleset signature allows also to define aliases of the elements above, these aliases are valid only within the specific ruleset definition statement and cannot be mapped to SDMX.[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^~[18~]^^>>path:#_ftn18]](%%)
1348 1348  
1349 1349  In the body of the Rulesets, the Codes and in general all the Values can be written without any other specification, because the artefact  which the Values are referred (Codelist, ConceptScheme, Concept) to can be deduced from the Ruleset signature.
1350 1350  
... ... @@ -1358,15 +1358,15 @@
1358 1358  
1359 1359  Every time a SDMX object is referenced in a VTL Transformation as an input operand, there is the need to generate a VTL definition of the object, so that the VTL operations can take place. This can be made starting from the SDMX definition and applying a SDMX-VTL mapping method in the direction from SDMX to VTL. The possible mapping methods from SDMX to VTL are described in the following paragraphs and are conceived to allow the automatic deduction of the VTL definition of the object from the knowledge of the SDMX definition. 
1360 1360  
1361 -In the opposite direction, every time an object calculated by means of VTL must be treated as a SDMX object (for example for exchanging it through SDMX), there is the need of a SDMX definition of the object, so that the SDMX operations can take place.  The SDMX definition is needed for the VTL objects for which a SDMX use is envisaged[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^~[19~]^^>>path:#_ftn19]](%%).
1366 +In the opposite direction, every time an object calculated by means of VTL must be treated as a SDMX object (for example for exchanging it through SDMX), there is the need of a SDMX definition of the object, so that the SDMX operations can take place.  The SDMX definition is needed for the VTL objects for which a SDMX use is envisaged[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^~[19~]^^>>path:#_ftn19]](%%).
1362 1362  
1363 1363  The mapping methods from VTL to SDMX are described in the following paragraphs as well, however they do not allow the complete SDMX definition to be automatically deduced from the VTL definition,  more than all because the former typically contains additional information in respect to the latter. For example, the definition of a SDMX DSD includes also some mandatory information not available in VTL (like the concept scheme to which the SDMX components refer, the assignmentStatus and attributeRelationship for the DataAttributes and so on). Therefore the mapping methods from VTL to SDMX provide only a general guidance for generating SDMX definitions properly starting from the information available in VTL, independently of how the SDMX definition it is actually generated (manually, automatically or part and part). 
1364 1364  
1365 1365  === 10.3.2 General mapping of VTL and SDMX data structures ===
1366 1366  
1367 -This section makes reference to the VTL “Model for data and their structure”[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^~[20~]^^>>path:#_ftn20]](%%) and the correspondent SDMX “Data Structure Definition”[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^~[21~]^^>>path:#_ftn21]](%%).
1372 +This section makes reference to the VTL “Model for data and their structure”[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^~[20~]^^>>path:#_ftn20]](%%) and the correspondent SDMX “Data Structure Definition”[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^~[21~]^^>>path:#_ftn21]](%%).
1368 1368  
1369 -The main type of artefact that the VTL can manipulate is the VTL Data Set, which in general is mapped to the SDMX Dataflow. This means that a VTL Transformation, in the SDMX context, expresses the algorithm for calculating a derived Dataflow starting from some already existing Dataflows (either collected or derived).[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^~[22~]^^>>path:#_ftn22]](%%)
1374 +The main type of artefact that the VTL can manipulate is the VTL Data Set, which in general is mapped to the SDMX Dataflow. This means that a VTL Transformation, in the SDMX context, expresses the algorithm for calculating a derived Dataflow starting from some already existing Dataflows (either collected or derived).[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^~[22~]^^>>path:#_ftn22]](%%)
1370 1370  
1371 1371  While the VTL Transformations are defined in term of Dataflow definitions, they are assumed to be executed on instances of such Dataflows, provided at runtime to the VTL engine (the mechanism for identifying the instances to be processed are not part of the VTL specifications and depend on the implementation of the VTL-based systems).  As already said, the SDMX Datasets are instances of SDMX Dataflows, therefore a VTL Transformation defined on some SDMX Dataflows can be applied on some corresponding SDMX Datasets.
1372 1372  
... ... @@ -1376,7 +1376,7 @@
1376 1376  
1377 1377  SDMX DimensionComponent can be a Dimension, a TimeDimension or a MeasureDimension. Correspondingly, in the SDMX implementation of the VTL, the VTL Identifiers can be (optionally) distinguished in three sub-classes (Simple Identifier, Time Identifier, Measure Identifier) even if such a distinction is not evidenced in the VTL IM. 
1378 1378  
1379 -However, a VTL Data Structure can have any number of Identifiers, Measures and Attributes, while a SDMX 2.1 DataStructureDefinition can have any number of Dimensions and DataAttributes but just one PrimaryMeasure[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^~[23~]^^>>path:#_ftn23]](%%). This is due to a difference between SDMX 2.1 and VTL in the possible representation methods of the data that contain more measures.
1384 +However, a VTL Data Structure can have any number of Identifiers, Measures and Attributes, while a SDMX 2.1 DataStructureDefinition can have any number of Dimensions and DataAttributes but just one PrimaryMeasure[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^~[23~]^^>>path:#_ftn23]](%%). This is due to a difference between SDMX 2.1 and VTL in the possible representation methods of the data that contain more measures.
1380 1380  
1381 1381  As for SDMX, because the data structure cannot contain more than one measure component (i.e., the primaryMeasure), the representation of data having more measures is possible only by means of a particular dimension, called MeasureDimension, which is aimed at containing the name of the measure concepts, so that for each observation the value contained in the PrimaryMeasure component is the value of the measure concept reported in the MeasureDimension component. 
1382 1382  
... ... @@ -1440,7 +1440,7 @@
1440 1440  
1441 1441   The set of SDMX observations having the same values for all the Dimensions except than the MeasureDimension become one multi-measure VTL Data Point, having one Measure for each Concept Cj of the SDMX MeasureDimension;
1442 1442  
1443 -*
1448 +*
1444 1444  ** The values of the SDMX simple Dimensions, TimeDimension and DataAttributes not depending on the MeasureDimension (these components by definition have always the same values for all the observations of the set above) become the values of the corresponding VTL (simple) Identifiers, (time) Identifier and Attributes.
1445 1445  ** The value of the PrimaryMeasure of the SDMX observation belonging to the set above and having MeasureDimension=Cj becomes the value of the VTL Measure Cj
1446 1446  ** For the SDMX DataAttributes depending on the MeasureDimension, the value of the DataAttribute DA of the SDMX observation belonging to the set above and having MeasureDimension=Cj becomes the value of the VTL Attribute DA_Cj
... ... @@ -1447,7 +1447,7 @@
1447 1447  
1448 1448  **10.3.3.3 From SDMX DataAttributes to VTL Measures **
1449 1449  
1450 -*
1455 +*
1451 1451  ** In some cases it may happen that the DataAttributes of the SDMX DataStructure need to be managed as Measures in VTL. Therefore, a variant of both the methods above consists in transforming all the SDMX DataAttributes in VTL Measures. When DataAttributes are converted to Measures, the  two methods above are called Basic_A2M and Pivot_A2M (the suffix “A2M” stands for Attributes to Measures). Obviously, the resulting VTL data structure is, in general, multi-measure and does not contain Attributes.
1452 1452  
1453 1453  The Basic_A2M and Pivot_A2M behaves respectively like the Basic and Pivot methods, except that the final VTL components, which according to the Basic and Pivot methods would have had the role of Attribute, assume instead the role of Measure.
... ... @@ -1466,7 +1466,7 @@
1466 1466  
1467 1467  This mapping method cannot be applied for SDMX 2.1 if the VTL data structure has more than one measure component, given that the SDMX 2.1 DataStructureDefinition allows just one measure component (the
1468 1468  
1469 -PrimaryMeasure). In this case it becomes mandatory to specify a different 1958 mapping method through the VtlMappingScheme and VtlDataflowMapping 1959 classes.[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^~[24~]^^>>path:#_ftn24]](%%)
1474 +PrimaryMeasure). In this case it becomes mandatory to specify a different 1958 mapping method through the VtlMappingScheme and VtlDataflowMapping 1959 classes.[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^~[24~]^^>>path:#_ftn24]](%%)
1470 1470  
1471 1471  1960 Please note that the VTL measures can have any name while in SDMX 2.1 the 1961 MeasureComponent has the mandatory name “obs_value”, therefore the name of the VTL measure name must become “obs_value” in SDMX 2.1. 
1472 1472  
... ... @@ -1533,7 +1533,7 @@
1533 1533  
1534 1534   the values of the VTL identifiers become the values of the corresponding SDMX Dimensions, for all the observations of the set above
1535 1535  
1536 -*
1541 +*
1537 1537  ** the name of the j^^th^^ VTL measure (e.g. “Cj”) becomes the value of the SDMX MeasureDimension of the j^^th^^ observation of the set (i.e. the Concept Cj)
1538 1538  ** the value of the j^^th^^ VTL measure becomes the value of the SDMX PrimaryMeasure of the j^^th^^ observation of the set
1539 1539  ** the values of the VTL Attributes become the values of the corresponding SDMX DataAttributes (in principle for all the observations of the set above)
... ... @@ -1583,15 +1583,15 @@
1583 1583  
1584 1584   The VtlMappingScheme is a container for zero or more VtlDataflowMapping (besides possible mappings to artefacts other than dataflows).
1585 1585  
1586 -=== 10.3.6 Mapping dataflow subsets to distinct VTL data sets[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^**~[25~]**^^>>path:#_ftn25]](%%) ===
1591 +=== 10.3.6 Mapping dataflow subsets to distinct VTL data sets[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^**~[25~]**^^>>path:#_ftn25]](%%) ===
1587 1587  
1588 1588  Until now it as been assumed to map one SMDX Dataflow to one VTL dataset and vice-versa. This mapping one-to-one is not mandatory according to VTL because a VTL data set is meant to be a set of observations (data points) on a logical plane, having the same logical data structure and the same general meaning, independently of the possible physical representation or storage (see VTL 2.0 User Manual page
1589 1589  
1590 1590  24), therefore a SDMX Dataflow can be seen either as a unique set of data observations (corresponding to one VTL data set) or as the union of many sets of data observations (each one corresponding to a distinct VTL data set).
1591 1591  
1592 -As a matter of fact, in some cases it can be useful to define VTL operations involving definite parts of a SDMX Dataflow instead than the whole.[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^~[26~]^^>>path:#_ftn26]](%%)
1597 +As a matter of fact, in some cases it can be useful to define VTL operations involving definite parts of a SDMX Dataflow instead than the whole.[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^~[26~]^^>>path:#_ftn26]](%%)
1593 1593  
1594 -Therefore, in order to make the coding of  VTL operations simpler when applied on parts of SDMX Dataflows, it is allowed to map distinct parts of a SDMX Dataflow to distinct VTL data sets according to the following rules and conventions. This kind of mapping is possible both from SDMX to VTL and from VTL to SDMX, as better explained below.[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^~[27~]^^>>path:#_ftn27]](%%)
1599 +Therefore, in order to make the coding of  VTL operations simpler when applied on parts of SDMX Dataflows, it is allowed to map distinct parts of a SDMX Dataflow to distinct VTL data sets according to the following rules and conventions. This kind of mapping is possible both from SDMX to VTL and from VTL to SDMX, as better explained below.[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^~[27~]^^>>path:#_ftn27]](%%)
1595 1595  
1596 1596   Given a SDMX Dataflow and some predefined Dimensions of its
1597 1597  
... ... @@ -1603,14 +1603,14 @@
1603 1603  
1604 1604  In practice, this kind mapping is obtained like follows:
1605 1605  
1606 -* For a given SDMX dataflow, the user (VTL definer) declares  the dimension components on which the mapping will be based, in a given order.[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^~[28~]^^>>path:#_ftn28]](%%) Following the example above, imagine that the user declares the dimensions INDICATOR and COUNTRY.
1611 +* For a given SDMX dataflow, the user (VTL definer) declares  the dimension components on which the mapping will be based, in a given order.[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^~[28~]^^>>path:#_ftn28]](%%) Following the example above, imagine that the user declares the dimensions INDICATOR and COUNTRY.
1607 1607  * The VTL dataset is given a name using a special notation also called “ordered concatenation” and composed of the following parts: 
1608 1608  ** The reference to the SDMX dataflow (expressed according to the rules described in the previous paragraphs, i.e. URN, abbreviated
1609 1609  
1610 -URN or another alias); for example DF(1.0); o a slash (“/”) as a separator; [[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^~[29~]^^>>path:#_ftn29]]
1615 +URN or another alias); for example DF(1.0); o a slash (“/”) as a separator; [[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^~[29~]^^>>path:#_ftn29]]
1611 1611  
1612 -*
1613 -** The reference to a specific part of the SDMX dataflow above, expressed as the concatenation of the values that the SDMX dimensions declared above must have, separated by dots (“.”) and written in the order in which these dimensions are defined[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^~[30~]^^>>path:#_ftn30]](%%) . For example  POPULATION.USA would mean that such a VTL dataset is mapped to the SDMX observations for which the dimension  //INDICATOR// is equal to POPULATION and the dimension //COUNTRY// is equal to USA.
1617 +*
1618 +** The reference to a specific part of the SDMX dataflow above, expressed as the concatenation of the values that the SDMX dimensions declared above must have, separated by dots (“.”) and written in the order in which these dimensions are defined[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^~[30~]^^>>path:#_ftn30]](%%) . For example  POPULATION.USA would mean that such a VTL dataset is mapped to the SDMX observations for which the dimension  //INDICATOR// is equal to POPULATION and the dimension //COUNTRY// is equal to USA.
1614 1614  
1615 1615  In the VTL transformations, this kind of dataset name must be referenced between single quotes because the slash (“/”) is not a regular character according to the VTL rules.
1616 1616  
... ... @@ -1628,7 +1628,7 @@
1628 1628  
1629 1629  Let us now analyse the different meaning of this kind of mapping in the two mapping directions, i.e. from SDMX to VTL and from VTL to SDMX.
1630 1630  
1631 -As already said, the mapping from SDMX to VTL happens when the VTL datasets are operand of VTL transformations, instead the mapping from VTL to SDMX happens when the VTL datasets are result of VTL transformations[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^~[31~]^^>>path:#_ftn31]](%%) and need to be treated as SDMX objects. This kind of mapping can be applied independently in the two directions and the Dimensions on which the mapping is based can be different in the two directions: these Dimensions are defined in the ToVtlSpaceKey and in the FromVtlSpaceKey classes respectively.
1636 +As already said, the mapping from SDMX to VTL happens when the VTL datasets are operand of VTL transformations, instead the mapping from VTL to SDMX happens when the VTL datasets are result of VTL transformations[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^~[31~]^^>>path:#_ftn31]](%%) and need to be treated as SDMX objects. This kind of mapping can be applied independently in the two directions and the Dimensions on which the mapping is based can be different in the two directions: these Dimensions are defined in the ToVtlSpaceKey and in the FromVtlSpaceKey classes respectively.
1632 1632  
1633 1633  First, let us see what happens in the mapping direction from SDMX to VTL, i.e. when parts of a SDMX dataflow (e.g. DF1(1.0)) need to be mapped to distinct VTL datasets that are operand of some VTL transformations.
1634 1634  
... ... @@ -1638,7 +1638,7 @@
1638 1638  
1639 1639  //COUNTRYvalue//. For example, the VTL dataset ‘DF1(1.0)/POPULATION.USA’ would contain all the observations of DF1(1.0) having INDICATOR = POPULATION and COUNTRY = USA.
1640 1640  
1641 -In order to obtain the data structure of these VTL datasets from the SDMX one, it is assumed that the SDMX dimensions on which the mapping is based are dropped, i.e. not maintained in the VTL data structure; this is possible because their values are fixed for each one of the invoked VTL datasets[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^~[32~]^^>>path:#_ftn32]](%%). After that, the mapping method from SDMX to VTL specified for the dataflow DF1(1.0) is applied (i.e. basic, pivot …). 
1646 +In order to obtain the data structure of these VTL datasets from the SDMX one, it is assumed that the SDMX dimensions on which the mapping is based are dropped, i.e. not maintained in the VTL data structure; this is possible because their values are fixed for each one of the invoked VTL datasets[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^~[32~]^^>>path:#_ftn32]](%%). After that, the mapping method from SDMX to VTL specified for the dataflow DF1(1.0) is applied (i.e. basic, pivot …). 
1642 1642  
1643 1643  In the example above, for all the datasets of the kind
1644 1644  
... ... @@ -1658,7 +1658,7 @@
1658 1658  
1659 1659  …   …   …
1660 1660  
1661 -In fact the VTL operator “sub” has exactly the same behaviour. Therefore, mapping different parts of a SDMX dataflow to different VTL datasets in the direction from SDMX to VTL through the ordered concatenation notation is equivalent to a proper use of the operator “**sub**” on such a dataflow. [[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^~[33~]^^>>path:#_ftn33]]
1666 +In fact the VTL operator “sub” has exactly the same behaviour. Therefore, mapping different parts of a SDMX dataflow to different VTL datasets in the direction from SDMX to VTL through the ordered concatenation notation is equivalent to a proper use of the operator “**sub**” on such a dataflow. [[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^~[33~]^^>>path:#_ftn33]]
1662 1662  
1663 1663  In the direction from SDMX to VTL it is allowed to omit the value of one or more Dimensions on which the mapping is based, but maintaining all the separating dots (therefore it may happen to find two or more consecutive dots and dots in the beginning or in the end). The absence of value means that for the corresponding Dimension all the values are kept and the Dimension is not dropped.
1664 1664  
... ... @@ -1681,12 +1681,12 @@
1681 1681  
1682 1682  For example, let us assume that the VTL programmer wants to calculate the SDMX dataflow DF2(1.0) having the Dimensions TIME_PERIOD, INDICATOR, and COUNTRY and that such a programmer finds it convenient to calculate separately the parts of DF2(1.0) that have different combinations of values for INDICATOR and COUNTRY:
1683 1683  
1684 -* each part is calculated as a  VTL derived dataset, result of a dedicated VTL transformation; [[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^~[34~]^^>>path:#_ftn34]](%%)
1685 -* the data structure of all these VTL datasets has the TIME_PERIOD identifier and does not have the INDICATOR and COUNTRY identifiers.[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^~[35~]^^>>path:#_ftn35]]
1689 +* each part is calculated as a  VTL derived dataset, result of a dedicated VTL transformation; [[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^~[34~]^^>>path:#_ftn34]](%%)
1690 +* the data structure of all these VTL datasets has the TIME_PERIOD identifier and does not have the INDICATOR and COUNTRY identifiers.[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^~[35~]^^>>path:#_ftn35]]
1686 1686  
1687 -Under these hypothesis, such derived VTL datasets can be mapped to DF2(1.0) by declaring the Dimensions INDICATOR and COUNTRY as mapping dimensions[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^~[36~]^^>>path:#_ftn36]](%%).
1692 +Under these hypothesis, such derived VTL datasets can be mapped to DF2(1.0) by declaring the Dimensions INDICATOR and COUNTRY as mapping dimensions[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^~[36~]^^>>path:#_ftn36]](%%).
1688 1688  
1689 -The corresponding VTL transformations, assuming that the result needs to be persistent, would be of this kind:^^ ^^[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^~[37~]^^>>path:#_ftn37]]
1694 +The corresponding VTL transformations, assuming that the result needs to be persistent, would be of this kind:^^ ^^[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^~[37~]^^>>path:#_ftn37]]
1690 1690  
1691 1691  ‘DF2(1.0)///INDICATORvalue//.//COUNTRYvalue//’  <-  expression
1692 1692  
... ... @@ -1753,9 +1753,9 @@
1753 1753  
1754 1754  …);
1755 1755  
1756 -In other words, starting from the datasets explicitly calculated through VTL (in the example ‘DF2(1.0)/GDPPERCAPITA.USA’ and so on), the first step consists in calculating other (non-persistent) VTL datasets (in the example DF2bis_GDPPERCAPITA_USA and so on) by adding the identifiers INDICATOR and COUNTRY with the desired values (//INDICATORvalue// and //COUNTRYvalue)//. Finally, all these non-persistent data sets are united and give the final result DF2(1.0)[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^~[38~]^^>>path:#_ftn38]](%%), which can be mapped one-to-one to the homonymous SDMX dataflow having the dimension components TIME_PERIOD, INDICATOR and COUNTRY.
1761 +In other words, starting from the datasets explicitly calculated through VTL (in the example ‘DF2(1.0)/GDPPERCAPITA.USA’ and so on), the first step consists in calculating other (non-persistent) VTL datasets (in the example DF2bis_GDPPERCAPITA_USA and so on) by adding the identifiers INDICATOR and COUNTRY with the desired values (//INDICATORvalue// and //COUNTRYvalue)//. Finally, all these non-persistent data sets are united and give the final result DF2(1.0)[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^~[38~]^^>>path:#_ftn38]](%%), which can be mapped one-to-one to the homonymous SDMX dataflow having the dimension components TIME_PERIOD, INDICATOR and COUNTRY.
1757 1757  
1758 -Therefore, mapping different VTL datasets having the same data structure to different parts of a SDMX dataflow, i.e. in the direction from VTL to SDMX, through the ordered concatenation notation is equivalent to a proper use of the operators “calc” and “union” on such datasets. [[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^~[39~]^^>>path:#_ftn39]](%%)[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^~[40~]^^>>path:#_ftn40]]
1763 +Therefore, mapping different VTL datasets having the same data structure to different parts of a SDMX dataflow, i.e. in the direction from VTL to SDMX, through the ordered concatenation notation is equivalent to a proper use of the operators “calc” and “union” on such datasets. [[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^~[39~]^^>>path:#_ftn39]](%%)[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^~[40~]^^>>path:#_ftn40]]
1759 1759  
1760 1760  It is worth noting that in the direction from VTL to SDMX it is mandatory to specify the value for every Dimension on which the mapping is based (in other word, in the name of the calculated VTL dataset is not possible to omit the value of some of the Dimensions).
1761 1761  
... ... @@ -1804,7 +1804,7 @@
1804 1804  
1805 1805  Domain) is not identifiable. As a consequence, the definition of the VTL rulesets, which in VTL can refer either to enumerated or non-enumerated value domains, in SDMX can refer only to enumerated Value Domains (i.e. to SDMX Codelists). 
1806 1806  
1807 -As for the mapping between VTL variables and SDMX Concepts, it should be noted that these artefacts do not coincide perfectly. In fact, the VTL variables are  represented variables, defined always on the same Value Domain (“Representation” in SDMX) independently of the data set / data structure in which they appear[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^~[41~]^^>>path:#_ftn41]](%%), while the SDMX Concepts can have different Representations in different DataStructures.[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^~[42~]^^>>path:#_ftn42]](%%) This means that one SDMX Concept can correspond to many VTL Variables, one for each representation the Concept has.
1812 +As for the mapping between VTL variables and SDMX Concepts, it should be noted that these artefacts do not coincide perfectly. In fact, the VTL variables are  represented variables, defined always on the same Value Domain (“Representation” in SDMX) independently of the data set / data structure in which they appear[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^~[41~]^^>>path:#_ftn41]](%%), while the SDMX Concepts can have different Representations in different DataStructures.[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^~[42~]^^>>path:#_ftn42]](%%) This means that one SDMX Concept can correspond to many VTL Variables, one for each representation the Concept has.
1808 1808  
1809 1809  Therefore, it is important to be aware that some VTL operations (for example the binary operations at data set level) are consistent only if the components having the same names in the operated VTL data sets have also the same representation (i.e. the same Value Domain as for VTL).   For example, it is possible to obtain correct results from the VTL expression
1810 1810  
... ... @@ -2093,12 +2093,12 @@
2093 2093  “true” or “false”
2094 2094  )))
2095 2095  
2096 -
2097 -
2098 2098  **Figure 14 – Mappings from SDMX data types to VTL Basic Scalar Types**
2099 2099  
2100 -In case a different default conversion is desired, it can be achieved through the CustomTypeScheme and CustomType artefacts (see also the section Transformations and Expressions of the SDMX information model).
2103 +In case a different default conversion is desired, it can be achieved through the
2101 2101  
2105 +CustomTypeScheme and CustomType artefacts (see also the section Transformations and Expressions of the SDMX information model).
2106 +
2102 2102  The custom output formats can be specified by means of the VTL formatting mask described in the section “Type Conversion and Formatting Mask” of the VTL Reference Manual. Such a section describes the masks for the VTL basic scalar types “number”, “integer”, “date”, “time”, “time_period” and “duration” and gives examples. As for the types “string” and “boolean” the VTL conventions are extended with some other special characters as described in the following table.
2103 2103  
2104 2104  |(% colspan="2" %)**VTL special characters for the formatting masks**
... ... @@ -2149,7 +2149,7 @@
2149 2149  |N|fixed number of digits used in the preceding  textual representation of the month or the day
2150 2150  | |
2151 2151  
2152 -The default conversion, either standard or customized, can be used to deduce automatically the representation of the components of the result of a VTL transformation. In alternative, the representation of the resulting SDMX Dataflow can be given explicitly by providing its DataStructureDefinition. In other words, the representation specified in the DSD, if available, overrides any default conversion[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^~[43~]^^>>path:#_ftn43]](%%).
2157 +The default conversion, either standard or customized, can be used to deduce automatically the representation of the components of the result of a VTL transformation. In alternative, the representation of the resulting SDMX Dataflow can be given explicitly by providing its DataStructureDefinition. In other words, the representation specified in the DSD, if available, overrides any default conversion[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^~[43~]^^>>path:#_ftn43]](%%).
2153 2153  
2154 2154  === 10.4.5 Null Values ===
2155 2155  
... ... @@ -2181,18 +2181,12 @@
2181 2181  
2182 2182  For implementing an SDMX compliant Web Service the standardised WSDL file should be used that describes the expected request/response structure. The request message of the operation contains a wrapper element (e.g. “GetGenericData”) that wraps a tag called “GenericDataQuery”, which is the actual SDMX query XML message that contains the query to be processed by the Web Service. In the same way the response is formulated in a wrapper element “GetGenericDataResponse”.
2183 2183  
2184 -As defined in the SOAP specification, the root element of a SOAP message is the Envelope, which contains an optional Header and a mandatory Body. These are illustrated below along with the Body contents according to the WSDL:
2189 +As defined in the SOAP specification, the root element of a SOAP message is the Envelope, which contains an optional Header and a mandatory Body. These are illustrated below along with the Body contents according to the WSDL:
2185 2185  
2186 -[[image:1747854006117-843.png]]
2187 -
2188 2188  The problem that initiated the present analysis refers to the difference in the way SOAP requests are when trying to implement the aforementioned Web Service in .NET framework.
2189 2189  
2190 2190  Building such a Web Service using the .NET framework is done by exposing a method (i.e. the getGenericData in the example) with an XML document argument (lets name it “Query”). **The difference that appears in Microsoft .Net implementations is that there is a need for an extra XML container around the SDMX GenericDataQuery.** This is the expected behavior since the framework is let to publish automatically the Web Service as a remote procedure call, thus wraps each parameter into an extra element. The .NET request is illustrated below:
2191 2191  
2192 -[[image:1747854039499-443.png]]
2193 -
2194 -[[image:1747854067769-691.png]]
2195 -
2196 2196  Furthermore this extra element is also inserted in the automatically generated WSDL from the framework. Therefore this particularity requires custom clients for the .NET Web Services that is not an interoperable solution.
2197 2197  
2198 2198  == 11.2 Solution ==
... ... @@ -2213,30 +2213,20 @@
2213 2213  
2214 2214  To understand how the **XmlAnyElement** attribute works we present the following two web methods:
2215 2215  
2216 -[[image:1747854096778-844.png]]
2215 +In this method the **input** parameter is decorated with the **XmlAnyElement** parameter. This is a hint that this parameter will be de-serialized from an **xsd:any** element. Since the attribute is not passed any parameters, it means that the entire XML element for this parameter in the SOAP message will be in the Infoset that is represented by this **XmlElement** parameter.
2217 2217  
2218 -In this method the **input** parameter is decorated with the **XmlAnyElement** parameter. This is a hint that this parameter will be de-serialized from an **xsd:any** element. Since the attribute is not passed any parameters, it means that the entire XML element for this parameter in the SOAP message will be in the Infoset that is represented by this **XmlElement** parameter.
2217 +The difference between the two is that for the first method, **SubmitXml**, the
2219 2219  
2220 -[[image:1747854127303-270.png]]
2219 +XmlSerializer will expect an element named **input** to be an immediate child of the **SubmitXml** element in the SOAP body. The second method, **SubmitXmlAny**, will not care what the name of the child of the **SubmitXmlAny** element is. It will plug whatever XML is included into the input parameter. The message style from ASP.NET Help for the two methods is shown below. First we look at the message for the method without the **XmlAnyElement** attribute.
2221 2221  
2222 -The difference between the two is that for the first method, **SubmitXml**, the XmlSerializer will expect an element named **input** to be an immediate child of the **SubmitXml** element in the SOAP body. The second method, **SubmitXmlAny**, will not care what the name of the child of the **SubmitXmlAny** element is. It will plug whatever XML is included into the input parameter. The message style from ASP.NET Help for the two methods is shown below. First we look at the message for the method without the **XmlAnyElement** attribute.
2223 -
2224 -[[image:1747854163928-581.png]]
2225 -
2226 2226  Now we look at the message for the method that uses the **XmlAnyElement** attribute.
2227 2227  
2228 -[[image:1747854190641-364.png]]
2229 -
2230 -[[image:1747854236732-512.png]]
2231 -
2232 2232  The method decorated with the **XmlAnyElement** attribute has one fewer wrapping elements. Only an element with the name of the method wraps what is passed to the **input** parameter.
2233 2233  
2234 -For more information please consult: [[http:~~/~~/msdn.microsoft.com/en-us/library/aa480498.aspx>>http://msdn.microsoft.com/en-us/library/aa480498.aspx]]
2225 +For more information please consult:  [[http:~~/~~/msdn.microsoft.com/en>>url:http://msdn.microsoft.com/en-us/library/aa480498.aspx]][[->>url:http://msdn.microsoft.com/en-us/library/aa480498.aspx]][[us/library/aa480498.aspx>>url:http://msdn.microsoft.com/en-us/library/aa480498.aspx]][[url:http://msdn.microsoft.com/en-us/library/aa480498.aspx]]
2235 2235  
2236 2236  Furthermore at this point the problem with the different requests has been solved. However there is still the difference in the produced WSDL that has to be taken care. The automatic generated WSDL now doesn’t insert the extra element, but defines the content of the operation wrapper element as “xsd:any” type.
2237 2237  
2238 -[[image:1747854286398-614.png]]
2239 -
2240 2240  Without a common WSDL still the solution doesn’t enforce interoperability. In order to
2241 2241  
2242 2242  “fix” the WSDL, there two approaches. The first is to intervene in the generation process. This is a complicated approach, compared to the second approach, which overrides the generation process and returns the envisioned WSDL for the SDMX Web Service.
... ... @@ -2249,27 +2249,16 @@
2249 2249  
2250 2250  In the context of the SDMX Web Service, applying the above solution translates into the following:
2251 2251  
2252 -[[image:1747854385465-132.png]]
2253 -
2254 2254  The SOAP request/response will then be as follows:
2255 2255  
2256 2256  **GenericData Request**
2257 2257  
2258 -[[image:1747854406014-782.png]]
2259 -
2260 2260  **GenericData Response**
2261 2261  
2262 -[[image:1747854424488-855.png]]
2263 -
2264 2264  For overriding the automatically produced WSDL, in the solution explorer right click the project and select “Add” -> “New item…”. Then select the “Global Application Class”. This will create “.asax” class file in which the following code should replace the existing empty method:
2265 2265  
2266 -[[image:1747854453895-524.png]]
2267 -
2268 -[[image:1747854476631-125.png]]
2269 -
2270 2270  The SDMX_WSDL.wsdl should reside in the in the root directory of the application. After applying this solution the returned WSDL is the envisioned. Thus in the request message definition contains:
2271 2271  
2272 -[[image:1747854493363-776.png]]
2273 2273  
2274 2274  ----
2275 2275  
... ... @@ -2362,5 +2362,3 @@
2362 2362  [[~[42~]>>path:#_ftnref42]] A Concept becomes a Component in a DataStructureDefinition, and Components can have different LocalRepresentations in different DataStructureDefinitions, also overriding the (possible) base representation of the Concept.
2363 2363  
2364 2364  [[~[43~]>>path:#_ftnref43]] The representation given in the DSD should obviously be compatible with the VTL data type.
2365 -
2366 -{{putFootnotes/}}
1747854006117-843.png
Author
... ... @@ -1,1 +1,0 @@
1 -xwiki:XWiki.helena
Size
... ... @@ -1,1 +1,0 @@
1 -18.7 KB
Content
1747854039499-443.png
Author
... ... @@ -1,1 +1,0 @@
1 -xwiki:XWiki.helena
Size
... ... @@ -1,1 +1,0 @@
1 -3.0 KB
Content
1747854067769-691.png
Author
... ... @@ -1,1 +1,0 @@
1 -xwiki:XWiki.helena
Size
... ... @@ -1,1 +1,0 @@
1 -21.4 KB
Content
1747854096778-844.png
Author
... ... @@ -1,1 +1,0 @@
1 -xwiki:XWiki.helena
Size
... ... @@ -1,1 +1,0 @@
1 -10.6 KB
Content
1747854127303-270.png
Author
... ... @@ -1,1 +1,0 @@
1 -xwiki:XWiki.helena
Size
... ... @@ -1,1 +1,0 @@
1 -12.1 KB
Content
1747854163928-581.png
Author
... ... @@ -1,1 +1,0 @@
1 -xwiki:XWiki.helena
Size
... ... @@ -1,1 +1,0 @@
1 -29.8 KB
Content
1747854190641-364.png
Author
... ... @@ -1,1 +1,0 @@
1 -xwiki:XWiki.helena
Size
... ... @@ -1,1 +1,0 @@
1 -31.5 KB
Content
1747854236732-512.png
Author
... ... @@ -1,1 +1,0 @@
1 -xwiki:XWiki.helena
Size
... ... @@ -1,1 +1,0 @@
1 -2.0 KB
Content
1747854286398-614.png
Author
... ... @@ -1,1 +1,0 @@
1 -xwiki:XWiki.helena
Size
... ... @@ -1,1 +1,0 @@
1 -55.0 KB
Content
1747854385465-132.png
Author
... ... @@ -1,1 +1,0 @@
1 -xwiki:XWiki.helena
Size
... ... @@ -1,1 +1,0 @@
1 -55.0 KB
Content
1747854406014-782.png
Author
... ... @@ -1,1 +1,0 @@
1 -xwiki:XWiki.helena
Size
... ... @@ -1,1 +1,0 @@
1 -55.0 KB
Content
1747854424488-855.png
Author
... ... @@ -1,1 +1,0 @@
1 -xwiki:XWiki.helena
Size
... ... @@ -1,1 +1,0 @@
1 -55.0 KB
Content
1747854453895-524.png
Author
... ... @@ -1,1 +1,0 @@
1 -xwiki:XWiki.helena
Size
... ... @@ -1,1 +1,0 @@
1 -55.0 KB
Content
1747854476631-125.png
Author
... ... @@ -1,1 +1,0 @@
1 -xwiki:XWiki.helena
Size
... ... @@ -1,1 +1,0 @@
1 -55.0 KB
Content
1747854493363-776.png
Author
... ... @@ -1,1 +1,0 @@
1 -xwiki:XWiki.helena
Size
... ... @@ -1,1 +1,0 @@
1 -55.0 KB
Content
1747855024745-946.png
Author
... ... @@ -1,1 +1,0 @@
1 -xwiki:XWiki.helena
Size
... ... @@ -1,1 +1,0 @@
1 -55.0 KB
Content
1747855054559-410.png
Author
... ... @@ -1,1 +1,0 @@
1 -xwiki:XWiki.helena
Size
... ... @@ -1,1 +1,0 @@
1 -55.0 KB
Content
1747855075263-887.png
Author
... ... @@ -1,1 +1,0 @@
1 -xwiki:XWiki.helena
Size
... ... @@ -1,1 +1,0 @@
1 -55.0 KB
Content