Also, at what point is it safe to construct these helper objects? When is DSOM
done?
For instance, if you go to SequenceGrammarMixin you'll see that we have a bunch
of lazy evaluations concerning orderedSequenceContent and
unorderedSequenceContent.
lazy val unorderedSequenceContent = prod("unorderedSequenceContent") {
lazy val uoseq = self.unorderedSeq.get
UnorderedSequenceCombinator(this, uoseq.terms)
}
Should the above delay the reference to self.unorderedSeq until it's inside the
UnorderedSequenceCombinator? This would delay reference to SequenceKind and
any construction of the UnorderedSequence object until the 'parser' of
UnorderedSequenceCombinator is referenced/used.
Actually, this appears to be an issue for the grammar as well.
SequenceGrammarMixin references SequenceKind in order to determine which
'content' to use. Does this suggest then that really the UnorderedSequence
should use the SequenceCombinator? The only thing that differs would be the
'body' of the object we pass to the underlying parser. And at the time that
the Combinator is used, is only when the object needs to exist.
________________________________
From: Mike Beckerle
Sent: Friday, November 10, 2017 8:21:03 AM
To: [email protected]; Taylor Wise
Subject: Stack overflows, UnorderedSequences, DSOM
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?
