So I've had some stack-overflows while debugging of late.
This has lead to thinking about the reasons why. There are some principles of operation for the code-base of Daffodil that are not articulated, but that need to be followed to stay out of trouble. I am planning to add package.scala files describing these to the code base. For DSOM one is this: * DSOM components should be selected and constructed without reference to DFDL annotations, (including DFDL properties) carried on any schema component. This avoids a chicken/egg situation. The DSOM graph is needed in order to implement DFDL's property scoping rules; so you can't invoke those mechanisms in order to build the DSOM graph itself, or you will very likely end up with a circularity/stack-overflow. You can; however, look at the XML and its attributes. E.g., the XSD ref property, which is a QName for a global element/type/group. There are also some DFDL non-properties - cannot be put into scope - that are needed at the time DSOM objects are being constructed. One example is the dfdl:hiddenGroupRef "property" on xs:sequence XML elements. In general it is acceptable to look at, and even resolve global QName references at DSOM graph construction time. Coming back to the issue of unordered sequences... The above suggests a design flaw in DSOM currently, which is the UnorderedSequence class. In order to decide whether to construct this class or just a regular Sequence class instance, you have to examine the dfdl:sequenceKind property, which can be scoped. Hence, I claim, the UnorderedSequence class should not exist in current form, but an isUnordered attribute on Sequence should provide the information about whether the class is ordered or not, and that is determined only *after* the DSOM graph is constructed. Once the DSOM Sequence class has been constructed, then regular (usually lazy val) class members on Sequence can construct any helper objects that are needed for dealing with the complexity of compilation for unordered sequences. Comments?
