You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@daffodil.apache.org by "Sloane, Brandon" <bs...@tresys.com> on 2019/03/19 19:24:18 UTC
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
bsloane@tresys.com | tresys.com
Re: Multiple children of DIDocument
Posted by "Sloane, Brandon" <bs...@tresys.com>.
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 <sl...@apache.org>
Sent: Tuesday, March 19, 2019 4:36:52 PM
To: dev@daffodil.apache.org; 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 <bs...@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
>
> bsloane@tresys.com | tresys.com
>
Re: Multiple children of DIDocument
Posted by Steve Lawrence <sl...@apache.org>.
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 <bs...@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
>
> bsloane@tresys.com | tresys.com
>
Re: Multiple children of DIDocument
Posted by "Beckerle, Mike" <mb...@tresys.com>.
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 <bs...@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
bsloane@tresys.com | tresys.com