I actually stole a fair amount from prefixedLength (I moved the actual implementation to a common subclass to share with my quasi-element). The added complication for TypeCalc is that it is possible to refer to other elements of the infoset, and for TypeCalcs to be chained. If an inner TypeCalc tries to reference the infoset, it will need access to the actual infoset, not a dummy one. Since we don't have any type of previous-element function, I believe the approach of temporarily inserting an element should allow DPath to work without any suprises.
________________________________ From: Steve Lawrence <[email protected]> Sent: Tuesday, March 19, 2019 4:36:52 PM To: [email protected]; Beckerle, Mike Subject: Re: Multiple children of DIDocument 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 >
