Is there any reason why ODK/javaRosa renamed the XPath substring() function to, presumably, substr() ? I'm trying to use a form with substring() in a calculation, which works fine under Enketo, but trying to deploy it under KoboToolbox/upload to ODK Aggregate, throws an error:
ODK Validate Errors: org.javarosa.core.log.WrappedException: Error evaluating field 'result': The problem was located in calculate expression for ${result} XPath evaluation: cannot handle function 'substring' => org.javarosa.xpath.XPathUnhandledException[The problem was located in calculate expression for ${result} XPath evaluation: cannot handle function 'substring'] org.javarosa.core.log.WrappedException: Error evaluating field 'result': The problem was located in calculate expression for ${result} XPath evaluation: cannot handle function 'substring' => org.javarosa.xpath.XPathUnhandledException[The problem was located in calculate expression for ${result} XPath evaluation: cannot handle function 'substring'] >> Something broke the parser. See above for a hint. Result: Invalid
I'm assuming this is simply because javaRosa appears to have renamed the (identical?) function to substr
I dont quite understand why - is this an intended (and undocumented?) XPath deviation? Could I make a sacrificial offering of some kind to add 'ing'..
Actually, to followup myself, it appears the javaRosa substr() is not functionally identical to XPath's substring() - in some cases it'll return a different result given the same arguments (!). As background, I'm trying to use some of the great ODK ecosystem tools - KoboToolbox for the form builder, ODK Aggregate to host forms and submissions - with a non ODK Collect client app (or more specifically, non-javaRosa based client). Hence my particular XForms client needs to use standard XPath's functions, like substring().
Revisiting substr, it seems like the incompatibility between javaRosa substr() and XPath substring() is quite deliberate; specifically
...Returns the substring beginning at the specified 0-based start index and extends to the character at end index - 1.
Whereas the standard XPath substring() uses 1-based start index. I realise 0-based string indexes predominant in programming languages, but I guess I still have the question as to why this deviation is specifically necessary in ODK/javaRosa, for which otherwise XPath is effectively the only language available/exposed for performing 'programming' within a form?
Can anyone shed historical light on this decision?
I find that for these sorts of issues, there isn't always great historical information. @martijnr or @clayton_sims might know why and so I'll let them respond.
Nice find! My best guess, is that it wasn't realized that there was an XPath equivalent when substr() was added. It's unfortunate but since the implementations differ, there doesn't seem much we can do about it now.
It'd be nice if javaRosa would support the XPath substring() - in addition to its own substr() - so as not to barf when persnickety-types like myself actually try to fastidiously follow W3C specs...
