Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Added motivation for SequenceChild

...

Array/Optional elements no longer have their own Parsers/Unparsers independent of the sequences that contain them. Rather, the OrderedSequenceParserBase class orchestrates the child parsing for all kinds of children, be they scalars, or occurrences of array/optional elements. That way they can deal with separators without special cases around array boundaries. So the iteration of recurring array/optional elements is driven from the OrderedSequenceParserBase's parse method. Each kind of sequence child provides a parseOne method designed to parse exactly one occurrence, driven by the framework.

This design also takes another step towards solving the Daffodil schema compiler space/time problem, and our inability to implement recursive types - both of which are due to the backpointers from every term to its point of use so that no term can be shared.

The SequenceChild is intended to eventually do all the calculations related to the sequence child instance, such as alignment, whether possibly trailing position in group, etc. Everything that depends on the context surrounding the child, when combined with characteristics of the child itself. This split allows the sequence child parser/unparsers to be shared. The complexities associated with use of  those parsers/unparsers within the context of a particular sequence, are handled by a SequenceChildParser (or Unparser) which delegates to the actual (sharable) child Parser/Unparser.

From the DSOM perspective.... the SequenceChild has a unique backpointer to the containing Sequence, and is effectively part of the Sequence object. The SequenceChild object does not own/contain its child object. It refers to it.

Hence, the DSOM object for the child itself does NOT have such a unique backpointer (eventually. Right now it still does.)

Similarly, in the runtime, eventually parsers won't have chains backpointing to the runtime data objects of their enclosing contexts. That information will be available for diagnostic purposes on a stack in the processor state, but the runtime data structures won't be bi-directionally linked, so that the runtime data objects, and associated parsers/unparsers for a sharable term (e.g., an element) can be shared.

.

draw.io Diagram
bordertrue
viewerToolbartrue
fitWindowfalse
diagramNameSequenceChild
simpleViewerfalse
width
diagramWidth1161
revision3

...