I'm hard at work on the whole "backpointers" problem and this could help decouple the runtime data objects.
I think there is an invariant we're not taking advantage of. Everything that goes onto a runtime data object (both the DPathCompileInfo object, and the RuntimeData objects) should be available without reference to that object, for use in the schema compiler, and should be accessed that way by the schema compiler. That will eliminate the coupling of things together that generates so many of these circularity problems, if the schema compiler decides to conveniently get some piece of data off the runtimeData objects that creates a dependency on every other thing that goes into that runtime data object, and these are what trip us up often. ________________________________ From: Sloane, Brandon <bslo...@tresys.com> Sent: Tuesday, June 25, 2019 12:33:42 PM To: dev@daffodil.apache.org Subject: Re: Missing typecalc functions I think I looked into that possibility previously. During the initial design phases, I was concerned about the implication for other implementations (since, this is a pretty substantial departure from how the rest of the type system works). More recently, I discovered that we were an implementation that would actually have difficulty dong this. https://issues.apache.org/jira/browse/DAFFODIL-2148?page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel&focusedCommentId=16858872#comment-16858872 The issue for us is that we seperate out DPathCompileInfo from the main compileInfo in order to prevent circular dependencies. Unfortunately, looking up a typeCalc by QName involves getting it through the corresponding simpleType's main runtime info (and possible others, depending on how much the lookup-table forces evaluation), which re-introduces the circular dependency. I didn't push too hard on this at the time, since it was just a quality-of-life error reporting improvement, so I can take another stab at it and see if I can get it to work. The recent work in cleaning up the factory/instance distinction in simpleTypes might make this problem easier then it was in my prior attempt. ________________________________ From: Steve Lawrence <slawre...@apache.org> Sent: Tuesday, June 25, 2019 12:17:08 PM To: dev@daffodil.apache.org Subject: Re: Missing typecalc functions 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 <bslo...@tresys.com> > Sent: Tuesday, June 25, 2019 11:44:03 AM > To: dev@daffodil.apache.org > 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 > > bslo...@tresys.com | tresys.com >
