Are you saying then that we shouldn't look at sequenceKind variable, but rather
grab the sequenceKind directly from the XML?
So rather than:
lazy val isOrdered = sequenceKind match {
case SequenceKind.Ordered => true
case SequenceKind.Unordered => false
}
Do:
lazy val isOrdered = xml.attributes.get("sequenceKind") match {
case None => true // Ordered
case Some(order) => SequenceKind(order, this) match { // enum construction
unnecessary
case SequenceKind.Ordered => true
case SequenceKind.Unordered => false
}
}
________________________________
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?
