I've always thought it seemed odd that we had typed functions. Instead of adding more functions, it seems like it might be worth rethinking how the functions work. For example, instead of taking a string, maybe they could take a QName, and the return type is going to be the type of the primitive type of the QName. This does provide less flexibility in that you can't have dynamic type calculators, but maybe that flexibility isn't necessary.
On 6/25/19 12:02 PM, Beckerle, Mike wrote: > Where Double is needed, one often finds that Decimal is needed. > > > Anywhere that base-10 rounding semantics is required one tends to need > Decimal. > > > For date/time.... > > > I know of one exception example that came up in the DFDL workgroup. They had > time expressed in units of measure not supported by the existing DFDL > properties. E.g., we support data in binary seconds and binary milliseconds. > Because those are both commonplace. > > > But what if you have time in hundredths of a second? An actual example of > this came up as a use case. Data from older IBM AS400 machines I think. > > > If typeCalc feature could cover this I'd definitely push back on yet more > DFDL properties to specify the time scaling factor used when converting > binary date/times. > > > That said. I have exactly and only 1 use case. Not sufficient IMHO to > motivate adding date/time support. > > ________________________________ > From: Sloane, Brandon <[email protected]> > Sent: Tuesday, June 25, 2019 11:44:03 AM > To: [email protected] > Subject: Missing typecalc functions > > The typeCalc functions are all specialized by their return type; and > currently support only Integer and String. It appears that there is a need to > at least add Double to this list. (My use-case here is VMF/Link-16 where, for > example, "degrees" is specified in units of 360/2^n making an Int->Double > mapping natural). > > > A complete solution should provide functions for all the primitive types, but > I struggle to think of a use-case where we would need, say, date functions. > > > Does anyone have any opinions on if we need to support types beyond string, > integer, and double for returning from typeCalc functions? > > > Brandon T. Sloane > > Associate, Services > > [email protected] | tresys.com >
