calculate field type always stores data as string??

[mitchellsundt]

The "calculate" field type should be able to calculate integer or decimal values.
It appears to always store its result as type="string" which makes subsequent calculations problematic if they want to do arithmetic on the prior calculation. e.g., sum(${priorRepeatGroupCalc})

Is this a documentation oversight on the xlsform.org site, or a limitation of the converter?

[MartijnR]

Hi Mitch. I think that strictly speaking it's a limitation of pyxform, but I am wondering if it really matters in practice. A compliant XPath 1.0 evaluator, such as this one, has no knowledge of the data type of a node referred to in an XPath expression. Any paths are always automatically converted to either stringType, numberType, nodesetType or booleanType values, depending on the type of XPath function in which they are used according to the rules of that type of function (either Number, String, Boolean, Nodeset (or Date in OpenRosa)) or operator. So in your example an attempt should always be made to convert ${priorRepeatGroupCalc} to a numberValue because sum() is a Number Function.

I may very well be overlooking something in which having a datatype on a calculated item is useful though (datatype validation in some particular use case?).

Do you perhaps have a sample form that demonstrates an issue with sum()? I know javarosa has some bugs in (I think all) Number Functions with empty nodes, Infinity, -Infinity and NaN.

[mitchellsundt]

I don't have time to write up an example form, but, from my earlier ventures in this area, the javarosa code is broken in the areas of datatype conversions, and it does not rely on the XPath function to inform what conversion should be applied. And, a set of elements is treated differently from an individual reference. e.g., sum(/data/repeat/value) will break, but sum(/data/repeat[position(.)=1]/value, /data/repeat[position(.)=2]/value) may work. It is a mess.

Another concern is the impact of the assumption of a string type on downstream publishers. By always being a string type, this causes the publishers to publish them as a string value, rather than as the number / integer / date / geopoint / geoshape etc. Makes sharing of the data awkward.

[MartijnR]

on hold pending pyxform work

[MartijnR]

merged into #192