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
