Page History

...

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.

...

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.

.

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.)

...