I have no issues. The DIDocument is effectively a degenerate DIComplex node. Your suggested change makes it ever so slightly less degenerate, and only temporarily during the lifetime of the repType quasi-element.
Get Outlook for Android<https://aka.ms/ghei36> ________________________________ From: Sloane, Brandon <bslo...@tresys.com> Sent: Tuesday, March 19, 2019 7:24:18 PM To: dev@daffodil.apache.org Subject: Multiple children of DIDocument As you may have heard, I am working on the proposal to implement a TypeValueCalc feature, where a simple type can be defined by its representation type, describing how it appears in the bitstream, and some conversion functions to translate that to a logical type. To implement this, I am creating a quasi-element for the representation type that will get temporarilily inserted into the infoset for just long enough to parse and extract its value, before reverting the info set to its original state. When this feature is used on the root element, this approach means that we must temporarily add a second child to the DIDocument object that serves as the root of the infoset. However, DIDocument currently asserts that it only ever has 1 child. Does anyone forsee any issues in loosening this requirement to allow for a DIDocument to have mulitple children? (the root field will be left as the first child added). Regards, Brandon T. Sloane Associate, Services bslo...@tresys.com | tresys.com
