Open eyelidlessness opened 10 months ago
One significant difference: Enketo serializes booleans as strings "true" and "false" which is consistent with xsd:boolean
but both are truthy in XPath.
We'd only have to deal with "true"/"false" serialized values when editing submissions from Enketo. We don't document using boolean
bind types and it's not in XLSForm so it's generally unlikely that will come up. We do use boolean binds for the Entities spec but we don't apply submission edits to Entities so I don't think it matters. I think all that means it's ok if we don't worry about "false" being deserialized as truthy.
There's another discrepancy identified in this forum thread: in XPath a nodeset of size 1 with an empty node is supposed to be True
whereas it's an empty nodeset that's supposed to be False
. JR treats an empty node as False
. I don't think this is very likely to come up and Web Forms should probably align with XPath and we can document that Collect is not spec-compliant on that front.
Another interesting forum thread on boolean expressions: https://forum.getodk.org/t/relevance-calculated-not-working-on-enketo/26587
For reference when we come back to this: there was a partial approach to a fix in https://github.com/getodk/web-forms/pull/154/commits/2a20d4f45fbe4f0f983831c5e4f0edf3075adc93 (causing some tests to pass as seen in https://github.com/getodk/web-forms/pull/154/commits/8176705ee0e343c08afe8968af4334148f92056e). Those changes were rolled back in #154, but I wanted to make sure there's an easy way to back reference them to revisit.
@lognaturel had mentioned differing behavior between Collect and Enketo, and linked https://github.com/kobotoolbox/enketo-express/issues/193 for context. My suspicion is the behavior will already be aligned, but it would be good to test just to be sure.