Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Add unparser to TDML example. Corrected bugs.


First you should give a search of our JIRA tickets to see if the problem is already recorded.

Here's a list of all tickets about bugs, new features, and improvements, in reverse chronological order (most recent first). You may want to change the issue type, or status specifications to narrow down the list, but most commonly you would just put some search keywords into the search box.


By convention, a TDML file uses file extension ".tdml" or, more commonly now ".tdml.xml" which enables the TDML "tutorial" features to work.

Below is an annotated TDML file for a very simple example:

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. 
  suiteName="My suspected bugs"
  description="Illustrates issues found 2013-04-01. No fooling.?xml-stylesheet type="text/xsl" href="DFDLTutorialStylesheet.xsl"?>
  suiteName="Bug Report TDML Template" 
  description="Illustration of TDML for bug reporting."
    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
    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"/>
    <!-- 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 
                 schemaLocation="IBMdefined/GeneralPurposeFormat.xsd" /> 
      Now imagine we are reporting a bug with date/time functionality, and
      this element exercises the feature of concern./xmlns/dfdl/testData tdml.xsd"
  This example TDML file is for <xs:element name="myTestRoot" type="xs:dateTime"
a self-contained bug report. 
 dfdl:calendarPattern="MM.dd.yyyy 'at' HH:mm:ss ZZZZ"
   It shows a parse test, and similar unparse test.

  dfdl<tdml:lengthKinddefineSchema name="delimitedbug01Schema" dfdl:terminatorelementFormDefault="%NL;unqualified" />

<!-- That's it for the schema for this small example --> namespace="" 
  </tdml:defineSchema>   <!--
schemaLocation="IBMdefined/GeneralPurposeFormat.xsd" /> 
 Here is a test case
that exercises the above schema.
<dfdl:defineFormat name="myFormat">
    A single TDML<dfdl:format file can contain many test cases like the one below. This ref="gpf:GeneralPurposeFormat"
   example has only one.  representation="text" 
  You must give the name of theencoding="ASCII" model
(aka the schema), that can be the name ofinitiator="" a
   schema defined immediately in this fileterminator="" like
above, or a file name.    separator="" />
You must also give the</dfdl:defineFormat>
name of
the root element that the test will use.
 --><dfdl:format ref="ex:myFormat" />

    <tdml<xs:parserTestCaseelement name="dateTimeTestmyTestRoot" roottype="myTestRoot"xs:dateTime" 
      model="s1" description="date time issue"> <!-- description is optional -->dfdl:calendarPattern="MM.dd.yyyy 'at' HH:mm:ssZZZZZ" 
   The data for your test is given by the tdml:document element.
 dfdl:terminator="%NL;" />
  <tdml:parserTestCase name="dateTimeTest" root="myTestRoot" model="bug01Schema" 
   Notice specifically the use of the CDATA bracketing of the data. Thisdescription="A hypothetical bug illustration about parsing a date time.">
 insures that no<tdml:document>
unintended whitespace gets inserted around your data.<tdml:documentPart type="text" 
 -->     <tdml:document><replaceDFDLEntities="true"><![CDATA[04.02.2013 at 14:00:56 GMT-05:00%LF;]]></tdml:documentPart>

   The infoset element gives the expected infoset, expressed as an XML fragment.
  --> <tdml:infoset>

  <tdml:unparserTestCase name="unparseDateTimeTest"  Always need this extra tdml:dfdlInfoset element as well
 root="myTestRoot" model="bug01Schema" 
    description="Another bug illustration, this time unparsing direction.">

      Here is our actual expected result, where the date and time
now in XML's cannonical representation for these. <tdml:document>
     <tdml:documentPart    -->type="text" 
      </tdml:dfdlInfoset>replaceDFDLEntities="true"><![CDATA[04.02.2013 at 14:00:56-05:00%CR;%LF;]]></tdml:documentPart>
   <!-- end of the test
case -->  </tdml:parserTestCase>unparserTestCase>
<!-- end of the whole TDML file

Suppose you save the above out as a file "myDateTimeBug.tdml". You can then run it using the Daffodil Command Line Interface.