I like this variation where you make mixtures of lookup keys and lookup ranges work together smoothly, so I'll revise the proposal accordingly.
The reason repType and lookupKey/lookupRange don't have matching naming conventions is that repType is a general purpose hook that says "this logical element has as it's representation this other type", then there has to be a bi-directional way of connecting the logical value to the repType representation. lookupKey/range are more specific mechanisms which simplify creating this bi-directional mapping. In the specific case of lookupKey/Range this doesn't involve schema authors writing expressions/formulas, but we know that in some other cases there may in fact have to be some formulas. E.g., another thing repType is supposed to be for is units standardization, e.g., so that a logical element can be in meters, when the physical is in 25 foot increments. In this case repType is basically just providing a hiddenGroup that allows one to avoid the value-element problem of needing a complex type with a hidden group and a value element child in it, to represent what the schema author really thinks of as logically a simple type. My usual example of this has been a smart-string representation, where the string has an explicit length stored at the front which is either 1 byte long for short strings up to 254 long (0xFE), or 4 bytes long, with the first byte being 0xFF, and up to length 0xFFFFFF unsigned. This requires a complex type to describe, but logically the user really wants to think of it as a string, i.e., of simple type. the repType property effectively gives you a hidden-group hidden inside the simple type where this complex representation can hide, while the logical remains of simple type. The multi-dimensional thing I put into the proposal was a stab at trying to let you build a function used in these repType conversions where the function is richly parameterized by a static structure created by parsing some suitable syntax to get a logical structure. ________________________________ From: Steve Lawrence <[email protected]> Sent: Tuesday, April 3, 2018 1:16:32 PM To: [email protected]; Mike Beckerle Subject: Re: Feedback wanted on Proposal: DFDL Features to Support Table-Lookup I like this. One thing I might change, though I don't feel strongly, is what happens when both dfdl:lookupRange and dfdl:lookupKey are both provided. In this case, the proposal says only dfdl:lookupRange is used on parse, and dfdl:lookupKey is used on unparse. I can imagine cases where there are a bunch of individual keys unioned with a range of keys, for example, enum values for a string might be -10, 0, 2, 4, 6, 8, and 100-1000 If we wanted to support that and unparse to 6, we would need the following: dfdl:lookupKey="6" dfdl:lookupRange="-10 -10 0 0 2 2 4 4 6 6 8 8 100 1000" which is a bit more verbose than it needs to be. If instead both lookupKey and lookupRange were unioned for parse, and the first lookupKey was used for unparse, it could look like this: dfdl:lookupKey="6 -10 0 2 4 8" dfdl:lookupRange="100 1000" which is a little more readable, and is somewhat consistent with how dfdl:separator works (i.e. you can provide multiple separators for parse, and the first is used for unparse). This is also consistent with how you mention unions can be used for building up the dfdl:repType. Only other thing I'd think about changing is the names of the properties so that it is more clear that dfdl:repType and dfdl:lookupKey/Range are pairs, sortof like dfdl:choiceDispatchKey/Value clearly go together. I'm not sure what would be better, and it's just a name so probably not worth worrying about too much at this point, but maybe something worth thinking about as this proposal matures and we start implementation. The multi-dimensional lookup table is interesting, but I'm not sure I fully understand the use case. I assume it's converting key/value paris to something, but it's not exactly clear to me what/how. On 03/29/2018 04:10 PM, Mike Beckerle wrote: > > Feedback on this idea/proposal is welcome. We need to be able to deal with > enumerated constants, converting them from integers to/from strings in DFDL. > > The idea here would be to refine this proposal, then prototype in Daffodil > and try it out on some of the schemas that really need it. > > https://cwiki.apache.org/confluence/display/DAFFODIL/Proposal%3A+Features+to+Support+Table-Lookup >
