You might also take a look at prefixed lengths and how they are implemented. It sounds somewhat similar. Prefixed lengths used the concept of a "DetachedElement" (you can grep for that). When parsing, we create a new Infoset element and overwrite the existing infoset, parse to that, pull out the value, and then restore the old infoset.
Grep for DetachedElement and PrefixedLengthParserMixin for where that's used. It may not be sufficient enough for the TypeValueCalc, but they probably have some ideas in common. - Steve On 3/19/19 4:08 PM, Beckerle, Mike wrote: > 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 <[email protected]> > Sent: Tuesday, March 19, 2019 7:24:18 PM > To: [email protected] > 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 > > [email protected] | tresys.com >
