Introduction
This article discusses ETSI ES 201 873-9 [1] standard draft proposal.
While the final part of the title of the discussed document reads as "Part 9: Using XML Schema with TTCN-3", its actual scope of applicability is broader than what its name suggests. It effectively aims at defining a methodology for testing XML-based protocols, and it proposes to use XML Schema as a cornerstone technology on the XML side to achieve this goal. So while the document should have been more properly called "Using XML with TTCN-3", such approach to XML testing has certain serious limitations:
- XML Schema must exist for the protocol in order of it to be tested using the proposed methodology. XML Schema has its own limitations discussed in the following section. These limitations do not rule out the possibility of using alternative XML grammars like RELAX NG to describe a protocol when the expressive power of XML Schema is not enough.
- the proposed methodology does not define a harmonized and uniform framework for testing heterogeneous XML environments where multiple elements of the system may be described using multiple grammar schemes other than XML Schema, such as RELAX NG, DTD etc.
- the proposed mapping does not let the test suite writer define invalid, though well-formed XML documents that violate constraints of the XML Schema specification;
- the proposed conversion of XML Schema to TTCN-3 has certain serious limitations that may make its use unfeasible in many practical cases;
- delegation of XML encoding information to TTCN-3 encode and variant attributes may require implementation of a TTCN-3 encoder and decoder that may reach the complexity of a third-party XML Schema validator, use of which is proposed in the simpler approach to XML testing.
Note that some limitations from the above list are there by design, and they would not be an easy thing to fix by simply patching or amending the discussed document.
It the subsequent sections we discuss the above limitations and then propose a simple and uniform approach to XML testing that is free from these limitations.
XML Schema limitations
The primary disadvantage of W3C XML Schema compared to for example RELAX NG is its poor descriptive capabilities as far as complex XML document grammar rules possibly requiring lookahead are concerned. That is, RELAX NG provides better context-dependent rules over W3C XML Schema. If for example structure of content of an element is dependent on value of the element attribute (and content can be different for the same element name depending on its attribute value), there is a way to describe such dependency in RELAX NG, while the W3C XML Schema standard explicitly rules out possibility to describe such cases in a desired context-dependent way, and description can be done only in the most generic fashion that allows more relaxed grammar than its author possibly intended, allowing more cases of XML document content than desired. Thus W3C XML Schema has great potential for producing too weak grammars.
Here is an example that cannot be satisfactorily described by XML Schema:
<vehicles> <vehicle kind="car"> <wheels>4</wheels> </vehicle> <vehicle kind="ship"> <sails>3</sails> </vehicle> </vehicles>
There is no way to tell in XML Schema that vehicles of "ship" kind shall have no wheels, and that vehicles of "car" kind shall have no sails. The best you can do in XML Schema is to tell that "vehicle" elements of both kinds can have either wheels or sails, but not both, thus allowing cars to have sails in addition to wheels, and ships to have wheels in addition to sails. This is probably not what the original designer of the XML document format in the example above intended to convey. RELAX NG can handle this kind of context dependencies rather gracefully.
While the above deficiency of XML Schema is not so widely publicized, it may become rather annoying if you encounter it in practice.
Limitations of conversion of XML Schema to TTCN-3
While the fundamental limitation of XML Schema described in the previous section is a serious one, conversion to TTCN-3 proposed in the discussed document adds quite many other limitations to the pile. These limitations are described in the subsequent sections.
Collision of identifiers from different axes
Attributes and child elements of a particular element end up being in the same identifier scope as record fields after TTCN-3 conversion. This prevents joint use of attributes and child elements with colliding names. In addition to this limitation, merging attributes and child elements into the same data structure is generally not a good idea. This affects readability and maintainability of resulting TTCN-3 specifications, as the test suite maintainer may have hard time guessing whether a particular record field means an attribute or a child element. Here are examples that illustrate the issue:
/* Fragment of the original XML document, valid and well-formed */
<vehicle kind="car">
<wheels>4</wheels>
</vehicle>
/* Which field is an attribute, and which is a child element?
This TTCN-3 value mapping is not very self-descriptive, but
it is still OK. */
template Vehicle t :=
{
kind := "car",
wheels := 4
}
/* Fragment of the original XML document, valid and well-formed */
<entry id="1">
<id qualifier="internal"><value>102230125</value></id>
<quantity>25</quantity>
</entry>
/* Now try doing this in TTCN-3 */
template Entry t :=
{
id := 1,
id := /* colliding record field name */
{
qualifier := "internal",
value := 102230125
}
wheels := 4
}
In XML, attributes and child elements belong to different dimensions of the XML document (called axes in XPath), and hence they do not collide. In the proposed mapping, they belong to the same dimension (sibling fields in a record type definition), and hence a collision may occur.
Collision of identifiers from different namespaces
Since the proposed conversion does not take into account XML namespaces at the level of TTCN-3 data type mapping, elements and attributes from different namespaces with colliding identifiers cannot be properly represented in TTCN-3 after the conversion. Here is an example that illustrates the problem:
/* Fragment of the original XML document, valid and well-formed */
<vehicle ns1:kind="car" ns2:kind="diesel">
<ns1:wheels>4</ns1:wheels>
<ns3:wheels>standard</ns3:wheels>
</vehicle>
/* Now try doing this in TTCN-3 */
template Vehicle t :=
{
kind := "car",
kind := "diesel", // error: colliding field name
wheels := 4,
wheels := "standard" // error: colliding field name
}
Mismatch of BNF for names in TTCN-3 and XML
The BNF for names of elements and attributes in XML is defined by W3C in the form of the NT-NCName production. Here is its full definition taken from the W3C standard:
[4] NCName ::= (Letter | '_') (NCNameChar)* /* An XML Name, minus the ":" */ [5] NCNameChar ::= Letter | Digit | '.' | '-' | '_' | CombiningChar | Extender
Here is how identifiers are defined in the TTCN-3 BNF (curly brackets mean "zero or more"):
Identifier ::= Alpha {AlphaNum | Underscore}
And in English prose (taken from the TTCN-3 Core Language standard, revision 3.2.1 (2007-02)):
- TTCN-3 identifiers are case sensitive and may only contain lowercase letters (a-z) uppercase letters (A-Z) and numeric digits (0-9). Use of the underscore ( _ ) symbol is also allowed. An identifier shall begin with a letter (i.e. not a number and not an underscore).
So not only TTCN-3 prohibits use of leading underscore, not only it prohibits use of dots and dashes in identifiers. All this alone would make identifier conversion rules awkward already. But there is one more much bigger issue that makes generic conversion of XML names to TTCN-3 identifiers next to impractical. We discuss it in the next section.
Use of element and attribute names represented in Unicode
XML allows use of Unicode characters in names of attributes and elements, as the Letter production suggests. This alone completely rules out the possibility of devising a set of sensible generic rules for converting XML names to TTCN-3 identifiers. Here is an example:
/* Fragment of the original XML document, valid and well-formed */
<Город>
<Название>Петербург</Название>
<Население>5000000</Население>
</Город>
/* No way you can write the following in TTCN-3! Not at the moment, at least! */
template Город t :=
{
Название := "Петербург",
Население := 5000000
}
So because TTCN-3 does not support Unicode in identifier names, this truncates a very big class of XML documents and XML-based protocol interchanges that can be currently in use.
Other limitations and deficiencies
Use of anonymous type definitions
Use of anonymous type definitions is questionable, although it is understood that they are used only when the original XML Schema does not define a name for the corresponding complex type. It would have been much more convenient to have named typedef for every XML Schema grammar rule. Use of anonymous typedefs may make it a very inconvenient and awkward task to write a test suite, especially if you want to declare a variable or template of that anonymous type. Here is an example of the resulting TTCN-3 typedef taken from the discussed document, shortened for clarity:
type record Shiporder
{
XSD.String orderid,
XSD.String orderperson,
record /* anonymous typedefs are hard to use and hard to refer to */
{
XSD.String name,
XSD.String addressField
} shipto,
record /* anonymous typedef again */
{
XSD.String title,
XSD.String note optional
} item
}
Now if we want to declare a variable having the same type as shipto field or item field has, we may have hard time finding a proper named reference for type of the variable.
Case sensitivity
As XML is case-sensitive, this may become an issue if the original XML Schema defines two complex type names that differ only in case, for example:
<xs:complexType name="MyType">...</xs:complexType> ... <xs:complexType name="myType">...</xs:complexType>
According to proposed identifier conversion rules, names of both complex types map to the same type name in TTCN-3, MyType.
The same applies to conversion of simple types.
TTCN-3 reserved keywords
It is proposed to append the "Field" suffix to XML element and attribute names that happen to be TTCN-3 reserved keywords. This leaves an open question of what happens if the resulting identifier conflicts with any other existing XML element or attribute name. Here is an example:
/* Fragment of the original XML document, valid and well-formed */
<message>
<address>Planet Earth</address>
<addressField>Mexico City</addressField>
</message>
/* Now what happens after conversion to TTCN-3? */
template Vehicle t :=
{
addressField := "Planet Earth",
addressField := "Mexico City" // error: colliding field name
}
Simple and practical approach to XML testing
All the deficiencies of the proposed mapping discovered in the previous sections grow out of the fact that TTCN-3 was inconveniently burdened with some very unnatural task of representing a type system that is alien to it. In this section we present a more dynamic and simpler approach to representing XML data in TTCN-3 that lets you use not only XML Schema, but also other schemas as well.
The idea is to move the task of XML document validation outside of the scope of the TTCN-3 infrastructure and to delegate this task to the specialized non-TTCN-3 software that takes the original XML document grammar definition in the form of XML Schema or RELAX NG or any other grammar system as input and performs validation. Software that does this in a professional way already exists. This software can be integrated with the TCI-CD part of a TTCN-3 adapter. TTCN-3 adapter may indicate an error to the test execution if grammar rules are violated. The proposed delegation is performed instead of enforcing XML Schema grammar rules at the level of a TTCN-3 type system. TTCN-3 adapter and test suite should be merely responsible for defining, sending and receiving XML test material in some universally applicable fashion that is invariant of any particular grammar scheme rather than verifying XML test material validity, especially if this is done at a cost of seriously limiting the expressive power of TTCN-3 tests.
The solution itself it so simple that it would probably fit into a couple of pages of the Standard document. Here is how a TTCN-3 library of types used for XML testing should look like (file xmldefs.ttcn):
module XML
{
type union Node
{
Element elem,
Attribute attr,
Text text
}
type record of Node NodeList;
type record Element
{
universal charstring name,
universal charstring ns optional, /* namespace */
NodeList contained optional /* in document order */
}
type record Attribute
{
universal charstring name,
universal charstring ns optional, /* namespace */
universal charstring val
}
type universal charstring Text;
}
The ns ("namespace") field values should be in a fully-expanded form if present, not in an aliased form, because namespace aliases are not an authoritative source of the namespace information. If you want to preserve the concept of a namespace alias in TTCN-3, you can introduce a global constant with the alias name and fully expanded namespace value and then refer this global constant in your value definitions for ns fields, e.g.:
const universal charstring xsd := "http://www.w3.org/2001/XMLSchema";
...
{ name := "simpleType", ns := xsd, contained := { ... } },
...
Here is an example of how XML data can be defined in TTCN-3.
First comes the fragment of the original XML document:
<vehicle kind="car"> <wheels>4</wheels> </vehicle>
And here is its data representation (file xmlexample.ttcn):
module XMLExample
{
import from XML all;
template XML.Node t :=
{
elem :=
{
name := "vehicle", ns := omit,
contained :=
{
{
attr :=
{
name := "kind", ns := omit,
val := "car"
}
},
{
elem :=
{
name := "wheels", ns := omit,
contained :=
{
{
text := "4"
}
}
}
}
}
}
}
}
Verification of the document validity and its well-formedness is, again, delegated to a third-party tool and is performed against an XML document in an already encoded form.
While this is only a draft and not a complete proposal, it gives you an idea. The example above may indeed be more verbose than the notation in the discussed mapping, but it has the advantage of being free from all the limitations discussed in the previous sections. More compact value notation can be achieved by using TTCN-3 parameterized templates. And if you have tools that automatically generate TTCN-3 source code from XML input, verbosity may not be an issue.
Conclusions
While the proposed Part 9 of ETSI TTCN-3 standard discussed here represents an honest and diligent attempt to map XML Schema to TTCN-3, the devised mapping has so many limitations that we would like to ask: what is the practical value of the proposed mapping if it limits its potential user in so many ways? In the previous section we presented a much simpler approach that is free from all the limitations of the discussed mapping. We hope it gives a better alternative to a testing practitioner.
Have your say
You can share your views of this review on the article's discussion page.
References
- [1] ETSI ES/MTS-201 873-9 V0.3.0 (2007-08): Methods for Testing and Specification (MTS); The Testing and Test Control Notation version 3; Part 9: Using XML Schema with TTCN-3
