Skip to Content
Last modified by Helena on 2025/09/10 11:19
From version 1.2
edited by Helena
on 2025/05/26 11:13
Change comment: Update document after refactoring.
To version 8.1
edited by Artur
on 2025/05/27 15:50
Change comment: There is no comment for this version

Summary

Details

Page properties
Author
... ... @@ -1,1 +1,1 @@
1 -xwiki:XWiki.helena
1 +xwiki:XWiki.arturkryazhev
Content
... ... @@ -1,8 +1,10 @@
1 -= 10 Validation and Transformation Language (VTL) =
1 +{{box title="**Contents**"}}
2 +{{toc/}}
3 +{{/box}}
2 2  
3 3  == 10.1 Introduction ==
4 4  
5 -The [[Validation and Transformation Language>>doc:sdmx:Glossary.Validation and transformation language.WebHome]] ([[VTL>>doc:sdmx:Glossary.Validation and transformation language.WebHome]]) supports the definition of Transformations, which are algorithms to calculate new data starting from already existing ones{{footnote}}The Validation and Transformation Language is a standard language designed and published under the SDMX initiative. VTL is described in the VTL User and Reference Guides available on the SDMX website https://sdmx.org.{{/footnote}}. The purpose of the [[VTL>>doc:sdmx:Glossary.Validation and transformation language.WebHome]] in the [[SDMX>>doc:sdmx:Glossary.Statistical data and metadata exchange.WebHome]] context is to enable the:
7 +The [[Validation and Transformation Language>>doc:sdmx:Glossary.Validation and transformation language.WebHome]] ([[VTL>>doc:sdmx:Glossary.Validation and transformation language.WebHome]]) supports the definition of Transformations, which are algorithms to calculate new data starting from already existing ones{{footnote}}The Validation and Transformation Language is a standard language designed and published under the SDMX initiative. VTL is described in the VTL User and Reference Guides available on the SDMX website [[https://sdmx.org]].{{/footnote}}. The purpose of the [[VTL>>doc:sdmx:Glossary.Validation and transformation language.WebHome]] in the [[SDMX>>doc:sdmx:Glossary.Statistical data and metadata exchange.WebHome]] context is to enable the:
6 6  
7 7  * definition of validation and transformation algorithms, in order to specify how to calculate new data from existing ones;
8 8  * exchange of the definition of [[VTL>>doc:sdmx:Glossary.Validation and transformation language.WebHome]] 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>>doc:sdmx:Glossary.Validation and transformation language.WebHome]] Transformations describing the calculation algorithms);
... ... @@ -539,7 +539,7 @@
539 539  
540 540  The [[VTL>>doc:sdmx:Glossary.Validation and transformation language.WebHome]] data types are sub-divided in scalar types (like integers, strings, etc.), which are the types of the scalar values, and compound types (like [[data sets>>doc:sdmx:Glossary.Data set.WebHome]], [[components>>doc:sdmx:Glossary.Component.WebHome]], rulesets, etc.), which are the types of the compound structures. See below the diagram of the [[VTL>>doc:sdmx:Glossary.Validation and transformation language.WebHome]] data types, taken from the [[VTL>>doc:sdmx:Glossary.Validation and transformation language.WebHome]] User Manual:
541 541  
542 -[[image:1747836776716-178.png]]
544 +[[image:1748249281218-402.png]]
543 543  
544 544  **Figure 12 – VTL Data Types**
545 545  
... ... @@ -547,7 +547,7 @@
547 547  
548 548  The [[VTL>>doc:sdmx:Glossary.Validation and transformation language.WebHome]] basic scalar types are listed below and follow a hierarchical structure in terms of supersets/subsets (e.g. “scalar” is the superset of all the basic scalar types):
549 549  
550 -[[image:1747859722732-549.png||height="283" width="224"]]
552 +[[image:1748249306075-938.png]]
551 551  
552 552  **Figure 13 – VTL Basic Scalar Types**
553 553  
... ... @@ -838,101 +838,3 @@
838 838  
839 839  In case a literal is operand of a [[VTL>>doc:sdmx:Glossary.Validation and transformation language.WebHome]] Cast operation, the format specified in the Cast overrides all the possible otherwise specified formats.
840 840  
841 -= 11 Annex I: How to eliminate extra element in the .NET SDMX Web Service =
842 -
843 -== 11.1 Problem statement ==
844 -
845 -For implementing an [[SDMX>>doc:sdmx:Glossary.Statistical data and metadata exchange.WebHome]] 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>>doc:sdmx:Glossary.Statistical data and metadata exchange.WebHome]] 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”.
846 -
847 -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:
848 -
849 -[[image:1747854006117-843.png]]
850 -
851 -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.
852 -
853 -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>>doc:sdmx:Glossary.Statistical data and metadata exchange.WebHome]] 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:
854 -
855 -[[image:1747854039499-443.png]]
856 -
857 -[[image:1747854067769-691.png]]
858 -
859 -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.
860 -
861 -== 11.2 Solution ==
862 -
863 -The solution proposed for conforming the .NET implementation to the envisioned SOAP requests has to do with the manual intervention to the serialisation and deserialisation of the XML payloads. Since it is a Web Service of already prepared XML messages requests/responses this is the indicate way so as to have full control on the XML messages. This is the way the Java implementation (using Apache Axis) of the [[SDMX>>doc:sdmx:Glossary.Statistical data and metadata exchange.WebHome]] Web Service has adopted.
864 -
865 -As regards the .NET platform this is related with the usage of **XmlAnyElement** parameter for the .NET web methods.
866 -
867 -Web methods use XmlSerializer in the .NET Framework to invoke methods and build the response.
868 -
869 -[[image:1747836776717-914.jpeg]]
870 -
871 -The XML is passed to the XmlSerializer to de-serialize it into the instances of classes in managed [[code>>doc:sdmx:Glossary.Code.WebHome]] that (% style="color:#e74c3c" %)map(%%) to the input parameters for the Web method. Likewise, the output parameters and return values of the Web method are serialized into XML in order to create the body of the SOAP response message.
872 -
873 -In case the developer wants more control over the serialization and de-serialization process a solution is represented by the usage of **XmlElement** parameters. This offers the opportunity of validating the XML against a schema before de-serializing it, avoiding de-serialization in the first place, analyzing the XML to determine how you want to de-serialize it, or using the many powerful XML APIs that are available to deal with the XML directly. This also gives the developer the control to handle errors in a particular way instead of using the faults that the XmlSerializer might generate under the covers.
874 -
875 -In order to control the de-serialization process of the XmlSerializer for a Web method, **XmlAnyElement** is a simple solution to use.
876 -
877 -To understand how the **XmlAnyElement** [[attribute>>doc:sdmx:Glossary.Attribute.WebHome]] works we present the following two web methods:
878 -
879 -[[image:1747854096778-844.png]]
880 -
881 -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>>doc:sdmx:Glossary.Attribute.WebHome]] 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.
882 -
883 -[[image:1747854127303-270.png]]
884 -
885 -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>>doc:sdmx:Glossary.Attribute.WebHome]].
886 -
887 -[[image:1747854163928-581.png]]
888 -
889 -Now we look at the message for the method that uses the **XmlAnyElement** [[attribute>>doc:sdmx:Glossary.Attribute.WebHome]].
890 -
891 -[[image:1747854190641-364.png]]
892 -
893 -[[image:1747854236732-512.png]]
894 -
895 -The method decorated with the **XmlAnyElement** [[attribute>>doc:sdmx:Glossary.Attribute.WebHome]] has one fewer wrapping elements. Only an element with the name of the method wraps what is passed to the **input** parameter.
896 -
897 -For more information please consult: [[http:~~/~~/msdn.microsoft.com/en-us/library/aa480498.aspx>>http://msdn.microsoft.com/en-us/library/aa480498.aspx]]
898 -
899 -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.
900 -
901 -[[image:1747854286398-614.png]]
902 -
903 -Without a common WSDL still the solution doesn’t enforce interoperability. In order to
904 -
905 -“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>>doc:sdmx:Glossary.Statistical data and metadata exchange.WebHome]] Web Service.
906 -
907 -This is done by redirecting the request to the “/Service?WSDL” to the envisioned WSDL stored locally into the application. To do this, from the project add a “Global Application Class” item (.asax file) and override the request in the “Application_BeginRequest” method. This is demonstrated in detail in the next section.
908 -
909 -This approach has the disadvantage that for each deployment the WSDL end point has to be changed to reflect the current URL. However this inconvenience can be easily eliminated if a developer implements a simple rewriting module for changing the end point to the one of the current deployment.
910 -
911 -== 11.3 Applying the solution ==
912 -
913 -In the context of the [[SDMX>>doc:sdmx:Glossary.Statistical data and metadata exchange.WebHome]] Web Service, applying the above solution translates into the following:
914 -
915 -[[image:1747854385465-132.png]]
916 -
917 -The SOAP request/response will then be as follows:
918 -
919 -**GenericData Request**
920 -
921 -[[image:1747854406014-782.png]]
922 -
923 -**GenericData Response**
924 -
925 -[[image:1747854424488-855.png]]
926 -
927 -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>>doc:sdmx:Glossary.Code.WebHome]] should replace the existing empty method:
928 -
929 -[[image:1747854453895-524.png]]
930 -
931 -[[image:1747854476631-125.png]]
932 -
933 -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:
934 -
935 -[[image:1747854493363-776.png]]
936 -
937 -
938 -{{putFootnotes/}}
1748249281218-402.png
Author
... ... @@ -1,0 +1,1 @@
1 +xwiki:XWiki.helena
Size
... ... @@ -1,0 +1,1 @@
1 +36.0 KB
Content
1748249306075-938.png
Author
... ... @@ -1,0 +1,1 @@
1 +xwiki:XWiki.helena
Size
... ... @@ -1,0 +1,1 @@
1 +14.7 KB
Content
SUZ.Methodology.Code.MethodologyClass[0]
index
... ... @@ -1,0 +1,1 @@
1 +10