Page History

In general, no. The dfdl:assert statement annotation should be used to guide the parser. It should test things that must be true in order to successfully parse the data and create an Infoset from it.

But, it should not be used to insure validation of the values of the data elements.

By way of illustrating what not to do, it is tempting to put facet constraints on simple type definitions in your schema, and then use a dfdl:assert like this:

<dfdl:assert>{ checkConstraints(.) }</dfdl:assert>

so that the parser will validate as it parses, and will fail to parse values that do not satisfy the facet constraints.

Don't do this. Your schema will not be as useful because it will not be able to be used for some applications, for example, applications that want to accept well-formed, but invalid data and analyze, act,  or report on the invalid aspects.

In some sense, embedding checks like this into a DFDL schema is second-guessing the application's needs, and assuming the application does not even want to successfully parse and create an infoset from data that does not obey the facet constraints.

Use CDATA with expressions and regular expressions, and generally to stop XML editors from messing with your DFDL schema layouts

Most XML editors will wrap long lines. So your

<a>foobar</a>

just might get turned into

<a>foobar
</a>

Now most of the time that is fine. But sometimes the whitespace really matters. One such place is when you type a regular expression.

In DFDL this can come up in this way:

<dfdl:assert testKind="pattern"> *</dfdl:assert>

Now the contents of that element is " *", i.e., a single space, and the "*" character. That means zero or more spaces in regex language.

If you don't want your XML tooling to mess with the whitespace do this instead:

<dfdl:assert testKind="pattern"><![CDATA[ *]]></dfdl:assert>

CDATA informs XML processors that you very much care about this. Any decent XML tooling/editor will see this and decide it cannot line-wrap this or in any way mess with the whitespace.

Also useful if you want to write a complex DFDL expression in the expression language, and you want indentation and lines to be respected. Here's an example:

<dfdl:discriminator><![CDATA[{
    if (fn:trace((fn:trace(../../ex:presenceBit,"presenceBit") = 0),"pbIsZero")) then false()
    else if
    (fn:trace(fn:trace(dfdl:occursIndex(),"occursIndex") = 1,"indexIsOne")) then true()
    else if
    (fn:trace(fn:trace(xs:int(fn:trace(../../ex:A1[fn:trace(dfdl:occursIndex()-1,"indexMinusOne")],
                                       "occursIndexMinusOneNode")/ex:repeatBit),
                       "priorRepeatBit") = 0,
              "priorRepeatBitIsZero")) 
    then false()
    else true()  
}]]></dfdl:discriminator> 

If you get done writing something very deeply nested like this (and XPath style languages require this all the time), then you do NOT want anything messing with the whitespace.

About the xml:space='preserve' attribute: According to this thread on the stack overflow web site, xml:space is only about whitespace-only nodes, not nodes that are part whitespace. Within element-only content, the text nodes found between the elements are whitespace-only nodes. Unless you use xml:space='preserve', those are eliminated. None of the above discussion is about whitespace-only nodes. It's about value nodes containing text strings with surrounding whitespace.