| XML encoding in TTCN-3 and Titan part 1: basics [message #1731681] |
Mon, 09 May 2016 08:38 |
|
Greetings.
Unlike the previously presented RAW and TEXT encoders, the XML encoder in Titan is standardized;
there's a separate part of the standard detailing XML and TTCN-3 interaction: Part 9: Using XML schema with TTCN-3
(http://www.etsi.org/deliver/etsi_es/201800_201899/20187309/04.06.01_60/es_20187309v040601p.pdf).
As explained in the JSON example https://www.eclipse.org/forums/index.php/t/1075601/:
"XML schemas are the conceptual equivalent of TTCN-3 type definitions: they describe information structures
based on which instances of such structures can be derived, such instances can be validated against etc.
In case of XML schemas instances are often referred to as documents, in TTCN-3 these can be variables, templates or constants.
As the two abstractions are not exactly equivalent, some structural information in XML schemas (XSD files)
can be translated directly into TTCN-3 structures, but some information can be retained only in form of additional encoding information,
the intention being that from the TTCN-3 structures and encoding information we generate an XML instance
that validates against the schema used as starting point. Ultimately, as the result of conversion, we will be able
to communicate with an SUT using XML-based messages: we can decode such messages and verify them with TTCN-3s powerful
template matching mechanism, and also encode TTCN-3 variables, templates etc. into well-formed (syntactically sound)
and valid( verifiable against the schema) XML."
Mapping XML Schemas to TTCN-3 can be done implicitly or explicitly.
In case of an implicit mapping an internal representation is produced from the XML Schema, which
representation retains all the structural and encoding information. This internal representation is typically not
accessible by the user. This is largely similar with ASN.1 to TTCN-3 integration, where TTCN-3 imports structural definitions directly
from ASN.1 modules , which can be used then as base for templates etc.
In case of an explicit conversion, the information present in the XML Schema is mapped into accessible TTCN-3 code
and - the XML structural information which does not have its correspondent in TTCN-3 code - into accessible encoding
instructions.
Titan prefers the latter approach , and this has to be taken into account for any code migration between tools.
A separate conversion utility xsd2ttcn is delivered together with other Titan binaries to perform the explicit conversion.
This utility processes the XML schema or schemas given as input and generates a TTCN-3 code decorated with a final
with { encode "XML" } instruction and types decorated with relevant
with { variant "" } instructions. The variants are detailed in the standard.
All that remains is to declare the external codec functions to make the auto-generated codecs visible from TTCN-3.
Needless to say , the auto-generated codecs can be directly used from C++, say from within a test port etc.
For instance, we can have a test port that accepts types converted from an XML schema; when sending, the templates are first XML-encoded,
then this XML is embedded into an HTTP message with appropriate headers and sent to SUT; at reception, the HTTP message is received, the
body extracted, XML-decoded and the template sent to the next layer.
The Titan XML codec will always generate namespaces in the root element:
<root xmlns:h="http://www.w3.org/TR/html4/" xmlns:f="http://www.w3schools.com/furniture">
<h:table>
<h:tr>
<h:td>Apples</h:td>
<h:td>Bananas</h:td>
</h:tr>
</h:table>
<f:table>
<f:name>African Coffee Table</f:name>
<f:width>80</f:width>
<f:length>120</f:length>
</f:table>
</root>
but when decoding will understand the equivalent form with the namespaces appearing on their relevant levels only:
<root>
<h:table xmlns:h="http://www.w3.org/TR/html4/">
<h:tr>
<h:td>Apples</h:td>
<h:td>Bananas</h:td>
</h:tr>
</h:table>
<f:table xmlns:f="http://www.w3schools.com/furniture">
<f:name>African Coffee Table</f:name>
<f:width>80</f:width>
<f:length>120</f:length>
</f:table>
</root>
In case of schemas that have been made extensible by using an any element, such as:
<xs:element name="person">
<xs:complexType>
<xs:sequence>
<xs:element name="firstname" type="xs:string"/>
<xs:element name="lastname" type="xs:string"/>
<xs:any minOccurs="0"/>
</xs:sequence>
</xs:complexType>
</xs:element>
the embedded opaque XML cannot be decoded , as the initial schema contains no structural information.
This will be returned as a string, which then can be subsequently decoded if the schema is known.
Often we see this kind of layering for messaging protocols where the outer layer is some kind of of a wrapper,
and the inner layer contains the actual protocol messages.
A good example for this is SOAP , see the previous topic https://www.eclipse.org/forums/index.php/t/1068103/.
Next we will continue with a practical example of XML encoding-decoding.
Best regards
Elemer
|
|
|
Powered by
FUDForum. Page generated in 0.02857 seconds
] 
Search
Help
Register
Login
Home
