Uploaded image for project: 'Daffodil'
  1. Daffodil
  2. DFDL-1518

dfdl:contentLength for complexType elements with internal alignment

XMLWordPrintableJSON

    • Icon: New Feature New Feature
    • Resolution: Fixed
    • Icon: Normal Normal
    • 2.0.0
    • None
    • None
    • None

      A complexType element can have an interior element with a non-unit alignment.

      This means that the length of that alignment region within the element depends on the alignment of the overall element.

      That depends on the starting position of the overall element.

      Hence, there is a class of complexType elements which you cannot determine the dfdl:contentLength of, until you know their starting position in the data stream.

      (The starting position in the data stream for unparsing is the absBitPos0b - absolute bit position zero based.)

      So you have to be able to block, and not compute the contentLength of something until you know its starting position.

      Hence, one must be able to block expression evaluation on an "infoset event" which determines the start position of an element. So this is one more thing that an expression can block on. That is, unparsing must be able to block (and split the data output buffer into current and subsequent, and continue unparsing the subsequent) on whether the absBitPos0b is known yet or not.

      There is a deadlock scenario when this event would never occur.

      An OVC element is variable length (e.g., is a text number, so its length depends on the number of digits needed to represent the value)

      The value of the OVC element is the dfdl:contentLength of a complexType element later in the infoset. This complex type element has an interior element with a non-unit alignment.

      The start position of the complexType element depends on the length of the OVC element (how many digits it is). Unless we know the start position we cannot determine the size of the interior alignment region; hence, we cannot determine the length of the complex type element.

      But the number of digits in the OVC element value depends on the length of the complexType element.

      So we're deadlocked.

      This is an obscure corner case and unlikely to appear in real formats, it exists as a corner case due to the composition properties of the DFDL language, where an OVC element can store the content length of a subsequent complex type element, and this can be expressed without consideration as to the specifc types or representations of the OVC element or of the complex type element being referenced.

              slawrence Steve Lawrence
              mbeckerle.dfdl Mike Beckerle
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Created:
                Updated:
                Resolved: