Is the value specified in an <output value="..."/> (ie to output a value within a <label> or <hint>) restricted to just referencing a (single) node in the instance, or can it in general be an arbitrary XPath expression? The ODK docs here about the body element seem to suggest that its the former - an instance node:
...used to display an instance value, inline, as part of the label, or hint text.
but it appears that I can put in a XPath expression (eg value="1+2+3"), and at least ODK Aggregate doesn't complain. And since a node can be considered a very simple XPath expression, I cant quite determine which.
Anybody happen to know if the value can be an XPath expression in ODK?
FYI for background reference, the W3C XForms spec indicate value='...' is used to output the result of an XPath expression, whereas ref='...' is used to output a specific instance value:
8.1.5 The output Element
Description: This form control renders a value from the instance data, but provides no means for entering or changing data. It is used to display values from the instance, and is treated as display:inline for purposes of layout. Element output can be used to display the value at a particular location in the instance by using a binding expression; it can also be used to display the result of evaluating an XPath expression by specifying the XPath expression to be evaluated via attribute value instead of ref. Note that attributes ref and value on element output are mutually exclusive.
It seems that in this case the spec is giving hints about intended usage rather than strictly defining behavior. I think it would be good to update the spec so it's more precise.
Hah! I'm also interested in greater compliance where possible and appreciate your verification and saying something when there's a mismatch. Let's right some historical wrongs!
In all seriousness, the fact <output value='...'/> can be an expression is significant, since it means you can perform calculations - involving multiple instance values - and output the result to the user directly, without having to 'store' the result in an instance property (unless of course you want to submit the result).
Yes, absolutely, that's a really important thing to be able to do.
As far as I know this is not exposed in XLSForm so most form creators don't have access to it. It might be worth eventually seeing if we can support it in some way.
I take that back... after some further investigation, it appears <output value='/data/foo'/> (ie what ${foo} will insert into your XML doc) is not actually a valid XPath expression (!), at least not to retrieve the current value of the XML instance element /data/foo. Rather, the XPath expression '/data/foo' just on its own references the entire XML element itself (ie including attributes); to get the value of the element the correct XPath expression is string(/data/foo). You can test the subtle-but-critical difference here
Which rather implies that ODK's (or should that be XLSForm's?) use of <output value='/data/foo'/> is not actually W3C compliant (D'oh!); instead it should be using <output ref='/data/foo'/> , or generating the equivalent valid XPath expression <output value='string(/data/foo)'/>
Now I'm really curious - how is javaRosa handling this discrepency? Treating value= as a ref= ? Certainly XLSForm is generates the output: <label>Sum = <output value=" /data/calculationgroup/sum "/></label>, which produces the desired result. But '/data/calculationgroup/sum' in-of-itself is not the correct XPath expression to return the instance value. So some level of re-interpretation of value='...' appears to be happening...
Scratch the above - not sure what I was doing wrong before, but now my (own) XPath expression evaluation is returning the desired instance value when evaluating <output value='/data/foo/'>. So explicitly typecasting with string(...) isnt necessary - the nodepath alone is sufficient.
The problem, it seems, is simply (haha) that raw XML in the label or hint column is escaped out on build.
If it was possible to include raw XML directly in a hint or label text, this wouldn't be a problem.
)
