...
Code Block |
---|
<?xml version="1.0" encoding="ASCII"?> <!-- Example of a self-contained test described in a TDML file A TDML file is actually a test suite of tests, but this example includes only 1 test. Notice the namespace prefix definitions here. --> <tdml:testSuite suiteName="My suspected bugs" description="Illustrates issues found 2013-04-01. No fooling." xmlns:tdml="http://www.ibm.com/xmlns/dfdl/testData" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:dfdl="http://www.ogf.org/dfdl/dfdl-1.0/" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:ex="http://example.com" xmlns:gpf="http://www.ibm.com/dfdl/GeneralPurposeFormat"> <!-- Use defineSchema to include a DFDL schema directly inside the TDML file. You can alternatively put the DFDL schema in a separate file if you prefer. The target namespace of these named defineSchemas will be http://example.com. Each defineSchema has a name, so that one TDML file can contain tests which reference different DFDL schemas. To embed a schema inside the TDML you don't include the <xs:schema...> element from the schema file, nor do you need to wrap the top-level DFDL annotation objects with xs:annotation and xs:appinfo. In other words, inside a defineSchema you can directly put: dfdl:defineFormat, dfdl:defineEscapeSchema, dfdl:format (for the default format), xs:element, xs:simpleType, xs:complexType, xs:group, xs:import, or xs:include --> <tdml:defineSchema name="s1"> <!-- a named format definition - notice no surrounding xs:annotation nor xs:appinfo We reference a useful starting point format definition provided to the DFDL community by IBM. (It is built into the Daffodil software.) --> <dfdl:defineFormat name="myDefaults"> <dfdl:format lengthKind="implicit" representation="text" encoding="ASCII" initiator="" terminator="" separator="" ref="gpf:GeneralPurposeFormat"/> </dfdl:defineFormat> <!-- default format declaration --> <dfdl:format ref="myDefaults" /> <!-- include the format we reference from myDefaults. IBM provided this nice one as a good starting point. --> <xs:import namespace="http://www.ibm.com/dfdl/GeneralPurposeFormat" schemaLocation="IBMdefined/GeneralPurposeFormat.xsd" /> <!-- Now imagine we are reporting a bug with date/time functionality, and this element exercises the feature of concern. --> <xs:element name="myTestRoot" type="xs:dateTime" dfdl:calendarPattern="MM.dd.yyyy 'at' HH:mm:ss ZZZZ" dfdl:calendarPatternKind="explicit" dfdl:lengthKind="delimited" dfdl:terminator="%NL;" /> <!-- That's it for the schema for this small example --> </tdml:defineSchema> <!-- Here is a test case that exercises the above schema. A single TDML file can contain many test cases like the one below. This example has only one. You must give the name of the model (aka the schema), that can be the name of a schema defined immediately in this file like above, or a file name. You must also give the name of the root element that the test will use. --> <tdml:parserTestCase name="dateTimeTest" root="myTestRoot" model="s1" description="date time issue"> <!-- description is optional --> <!-- The data for your test is given by the tdml:document element. Notice specifically the use of the CDATA bracketing of the data. This insures that no unintended whitespace gets inserted around your data. --> <tdml:document><![CDATA[04.02.2013 at 14:00:56 GMT-05:00%LF;]]></tdml:document> <!-- The infoset element gives the expected infoset, expressed as an XML fragment. --> <tdml:infoset> <!-- Always need this extra tdml:dfdlInfoset element as well --> <tdml:dfdlInfoset> <!-- Here is our actual expected result, where the date and time is now in XML's cannonical representation for these. --> <myTestRoot>2013<ex:myTestRoot>2013-04-02T19:00:56Z</ex:myTestRoot> </tdml:dfdlInfoset> </tdml:infoset> <!-- end of the test case --> </tdml:parserTestCase> <!-- end of the whole TDML file --> </tdml:testSuite> |
Suppose you save the above out as a file "myDateTimeBug.tdml". You can then run it using the Daffodil Command Line Interface.
...