Ah. There probably was no design note about that. It probably just got discussed in email threads of the DFDL Workgroup email list at OGF.
Just start a new design note then. ________________________________ From: Sloane, Brandon <[email protected]> Sent: Wednesday, June 19, 2019 12:05:44 PM To: [email protected] Subject: Re: Proposal: Add choiceBranchKeyRanges annotation This doesn't really strike me as a refinement on the enum/typeCalc stuff. It is a refinement of the basic choiceDispatch feature borrowing an idea from the enum/typeCalc feature. This should go in the design note that added support for multiple choiceBranchKeys, but I cannot find that one. ________________________________ From: Beckerle, Mike <[email protected]> Sent: Wednesday, June 19, 2019 11:11:38 AM To: [email protected] Subject: Re: Proposal: Add choiceBranchKeyRanges annotation Seems sensible to add this then. It is effectively just a refinement on the prior enum/typeCalc feature's range support. Suggest you update the design note on the wiki to add this capability to the "proposal". ________________________________ From: Sloane, Brandon <[email protected]> Sent: Monday, June 17, 2019 4:23:10 PM To: [email protected] Subject: Re: Proposal: Add choiceBranchKeyRanges annotation I don't have a good survey of data formats to know how widespread the use is. My motivating usecase comes from Link16 (mil-std-6016e), where there are a number of large enumeration tables. Some of these tables (such as DFI 804 DUI 001 for those with access to such specifications) has a large number of "disused" entries spread out throughout the encoding space. Our current enum support is able to accomodate this as a many-to-one mapping, but, using that mechanism, the unparse would be lossy. The original thinking in the enum proposal is that a lossless unparse would be accomplished through use of a choice branch; which is not a good option when the logical value comes from a spread out encoding space. This would also simplify some of the dispatch logic in the link16 schema. Even in the normal cases where we can handle, every dispatch uses a non-trivial DPath expression, which should be replaceable by a trival { ../raw } expression. I think the usecases are, in principle, the same as with the multi-values choiceBranchKey we already have. Conceptually, in is just providing a shorthand specifying a large number of branch keys. ________________________________ From: Beckerle, Mike <[email protected]> Sent: Friday, June 14, 2019 11:53:25 AM To: [email protected] Subject: Re: Proposal: Add choiceBranchKeyRanges annotation Brandon, can you add to your proposal discussion of how many practical use-cases there are for this? We can add features to Daffodil of course if we want. I want to understand vis a vis influencing the DFDL standard in the future, how many cases there are of this situation. ________________________________ From: Sloane, Brandon <[email protected]> Sent: Wednesday, June 12, 2019 11:16:53 AM To: [email protected] Subject: Proposal: Add choiceBranchKeyRanges annotation The DFDL specification only allows for a choice branch to specify a single key value. Daffodil has expanded this to allow for a space delimiated list of keys. However, this does not support the case where a large number of contiguous integers are the key. Are standard advice there is to use a more complicated dispatch expression, such as: if( (10 le tag) and (tag le 512)) then 'a' else 'b') However, this approach breaks down where there area a large number of ranges (for exactly the same reason that this approach breaks down when there are a large number of single values), and is not particuarly declerative. We face a simmilar problem with the recent Enumeration support. There, we solved it by including a repValueRanges attribute to go along with the repValues attribute. I am proposing a simmiliar addition for choice branches. The daf:choiceBranchKeyRanges will be a whitelist delimiated list of integers, interperated as "min1 max1 min2 max2 ... minN maxN", which will be logically equivalent to including all of "min1 min1+1 ... max1 ... minN minN+1 ... maxN" in the dfdl:choiceBranchKey annotation; and can be used in conjucntion or instead of the choiceBranchKeyAnnotation. In addition to making the complex case of many ranges possible, this will also simplify (and make more efficient) the case of 1 or few ranges. Brandon T. Sloane Associate, Services [email protected] | tresys.com
