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

Compare with Current View Page History

« Previous Version 3 Next »

In order to support the full richness of DFDL including properties like dfdl:separatorSuppressionPolicy in all its variations, the Daffodil sequence implementation needed refactoring.


The UML diagram below shows the introduction of the SequenceChild class in the Gram object tree, and how it relates to the runtime classes derived from SequenceChildParser and SequenceChildUnparser.

This is the primary architectural change in this proposed refactoring. A sequence parser, for example, is a loop that drives a number of sequence child parsers, some of which are for scalars (elements or model groups that are not repeating/optional), others are for array/optional elements.

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.

.


Below is the mixin architecture for creating the various flavors of SequenceChildParser and SequenceChildUnparser. We have mixable traits for separated/unseparated, and for RepParser, RepUnparser which are for array/optional elements (there is no Scalar mixin. It is the absence of a Rep mixin that makes it scalar.)


  • No labels