I have reexamined this material from prior discussions in this group, and considering the experience of implementing this in Daffodil.
We're not yet converged on whether the dfdl:contentLength of a complex element, is allowed to be a function of its starting position due to variable-sized alignment regions interior to the complex representation.
This creates a situation where a element with dfdl:outputValueCalc can have variable-length itself, and hence a complex element after it, that it forward references, can't compute its content's length, because it can't know the start position due to the variable length OVC element preceding it. (Got that?)
All I can say is ..... gaaaak.
This scenario is possible due to the way that features compose in DFDL, which is trying to be fairly orthogonal to each other. Alignment causes representation lengths to break this orthogonality because length now depends on the length of previous things.
Our choices:
1) yup must detect this crazy deadlock. Runtime SDE.
2) rule it out by disallowing OVC elements that call dfdl:contentLength which reference complex elements that have interior alignment, to be variable length themselves. It's an SDE. (Gaaaaak)
3) rule it out by saying OVC elements can never be variable length (... .but I think I've seen prefix lengths in textual data before, and those are naturally variable length... and might not have been adjacent, so not lengthKind 'prefixed', but needs OVC..... double Gaaaaak)
4) punt it down the road by saying it's 'implementation dependent' behavior. Still have to say exactly what it is that is implementation behavior, but this could be a paragraph/subsection in the description of dfdl:contentLength, dfdl:valueLength, and a reference from the dfdl:outputValueCalc section.
Better options? Ideas?