Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 6 Next »

Release 0.81

Unsupported features


This release contains only a parser. There is no unparser functionality in this release.

DFDL properties specific to unparsing are all unimplemented, and are generally ignored. These are:

  • outputNewLine
  • fillByte
  • textPadKind
  • textOutputMinLength
  • generateEscapeBlock
  • extraEscapedCharacters
  • truncateSpecifiedLengthString
  • outputValueCalc


The following types are unsupported. Their use will cause schema definition errors. Properties specific to them are also unimplemented.

  • decimal
  • integer
  • nonNegativeInteger
  • hexBinary
  • boolean
  • date - unimplemented for dfdl:representation='binary'
  • time - unimplemented for dfdl:representation='binary'
  • dateTime - unimplemented for dfdl:representation='binary'

XML Schema Features

Of the subset of features in XSD that DFDL uses, these are unimplemented, and are ignored by the Daffodil system unless otherwise noted:

  • fixed - property of element declarations
  • default - property of element declarations
  • attributeFormDefault (an attribute of the xs:schema element) - causes schema definition error (behaves as 'unqualified')

DFDL Features

These features of DFDL are broadly absent from the implementation in this release.

DFDL properties associated with these features will be validated, but beyond that may be entirely unrecognized or ignored.

  • Defaulting of values for required elements
  • All 'packed' binary number representation (packed, bcd, etc.)
  • All 'zoned' text number representations.
  • Advanced text number format properties
  • All bi-directional text
  • unordered sequences
  • floating elements in sequences
  • external variables
  • raw-byte entities
  • validation
  • alignment
  • the 'type' component of the DFDL Infoset
  • runtime-computed format properties (i.e., computing the value of dfdl:byteOrder at parse time based on data)
  • IANA standard encodings other than: utf-8, utf-16BE, utf-16LE, utf-32BE, utf-32LE, and ASCII. (Many IANA names will probably work. Only these are tested currently.)
  • expression language - qualified names are needed to reference elements. Unqualified elements do not work.

Daffodil-specific Features

These features are specified as part of the Daffodil API or Command-Line Interpreter, but are unsupported:

  • save/reload of a compiled parser

Properties and Property Enumerations

The following properties or property enumeration values are unsupported.

Their use in a DFDL schema will be validated.

These properties are implemented only for the value(s) specified. Any other value will cause a schema definition error.

  • ignoreCase="no"
  • utf16Width="fixed"
  • textNumberRep="standard"
  • binaryNumberRep="binary"
  • binaryFloatRep="ieee"
  • nilKind="literalValue"
  • lengthKind="delimited",  "pattern", "explicit", "fixed", or "implicit" (that leaves out "prefixed", and "endOfParent")
    • Note that when lengthKind='delimited' representation must be "text".
  • occursCountKind="fixed", "expression", "parsed", or "implicit" ("stopValue" is not supported)

The properties below are validated, but their values are subsequently ignored by Daffodil currently. Illegal or non-sensical values that are valid syntax will not cause a schema definition error (but should!). If they are undefined, Daffodil does not cause a schema definition error (but should!)

  • documentFinalTerminatorCanBeMissing (behaves as "no")
  • textNumberPattern
  • textNumberCheckPolicy
  • textNumberRoundingMode
  • textNumberRounding
  • textNumberRoundingIncrement
  • textStandardGroupingSeparator
  • textStandardDecimalSeparator
  • textStandardExponentCharacter
  • textStandardInfinityRep
  • textStandardNaNRep
  • textStandardZeroRep
  • textStandardBase (behaves as '10')
  • textZonedSignStyle
  • decimalSigned
  • textBooleanTrueRep
  • textBooleanFalseRep
  • textBooleanPadCharacter
  • textBooleanJustification
  • binaryBooleanTrueRep
  • binaryBooleanFalseRep
  • textBidi (behaves as "no")
  • textBidiTextOrdering
  • textBidiOrientation
  • textBidiSymmetric
  • textBidiTextShaped
  • textBidiNumeralShapes
  • alignment (behaves as "1")
  • alignmentUnits
  • leadingSkip (behaves as 0)
  • trailingSkip (behaves as 0)
  • prefixIncludesPrefixLength
  • prefixLengthType
  • binaryDecimalVirtualPoint
  • binaryNumberCheckPolicy
  • binaryPackedSignCodes
  • binaryCalendarRep
  • binaryCalendarEpoch
  • useNilForDefault
  • sequenceKind (behaves as "ordered")
  • floating (behaves as "no")
  • choiceLengthKind (behaves as "implicit")
  • choiceLength
  • occursStopValue

Deprecated Property Names

Both of these properties are supported.

  • separatorSuppressionPolicy (this is the new name, per the Errata)
  • separatorPolicy (name was changed from this in an Errata. This is the old name.)

If a schema uses separatorSuppressionPolicy, it will be respected and there wlll be no examination of separatorPolicy. If a schema does not use separatorSuppressionPolicy, then Daffodil will check for the former obsolete name separatorPolicy with its distinct enumeration values.


The following functions are unsupported in DFDL expressions:

  • dfdl:contentLength
  • dfdl:valueLength


The following DFDL annotations are unsupported:

  • dfdl:newVariableInstance

Some additional limitations:

  • File sizes are limited to 4Gigabytes due to underlying Java libraries using type int for offsets.
  • A Java 7 JVM is required as a number of its regular expression capabilities are passed through to Daffodil's DFDL implementation (as is required by the standard).
  • An expression enclosed in { ... } cannot have whitespace before or after the brace {, } characters. To work around this limitation, use CDATA, that is, as the body of an element, wrap expressions like this: <![CDATA[{...expression...}]]>
  • The expression language potentially accepts XPath constructs that are not allowed by DFDL. No attempt is made to identify such constructs and rule them out.
  • The expression language is based on XPath 1.0, not XPath 2.0 as required by the spec.

There is a list of bugs available in our JIRA tracking system.

  • No labels