XPath errors using `fr:date` in plain XForms

[avernet]

Most, if not all, fr:…() functions don't make sense outside of Form Runner, and sometimes fail if we try to call them. So one idea was to use the xxbl:keep-if-function-available and xxbl:keep-if-function-unavailable attributes to, say, have two versions of an xf:var, where one could use fr:…() functions, and one wouldn't.

The problem is that this mechanism is static and can't be used for xxbl:serialize-external-value, where we would like to use fr:…() functions, like fr:component-param-value('week-start-day') in the case of date.xbl. We could:

• Find a xxbl:keep-if-function-(un)available-like mechanism that works with xxbl:serialize-external-value. For instance, we could support having an element <xxbl:serialize-external-value value="…"/> in addition to the attribute, on which we could support the xxbl:keep-if-function-(un)available attributes.
• Make it so the fr:…() functions, or at least some of them, don't fail when running outside of Form Runner. For instance, fr:component-param-value() would behave like xxf:component-param-value(), and fr:mode() would return an empty sequence.

That second option seems simpler and would keep the code of the XBL lighter.

Also see #5533, where we made similar reflections for the fr:number.

+1 from customer

[avernet]

Test case: view.txt.

[avernet]

For the placeholder to work, we need to have an explicit xml:lang="en" in the document. It would be nice not to have such a requirement and to use a default language if no xml:lang is found. We already have an oxf.fr.default-language.*.* property, but we don't have an equivalent property at the XForms level. Using such a property could be done in XXFormsResource.scala, but I am not sure it is worth introducing an additional property for such a narrow use case. For now, we are just leaving things as they stand.