bind calculates do not work for nodesets with prefixed nodes for cached FormDef

[seadowg]

Software versions

JavaRosa v4.0.0-SNAPSHOT

Problem description

Form entry when using a "cached" (serialized then deserialized) FormDef won't result in calculates being populated if their target nodeset contains a node with a prefix (like /data/namespace:field).

Steps to reproduce the problem

Using the below form...

<?xml version="1.0"?>
<h:html xmlns="http://www.w3.org/2002/xforms" xmlns:h="http://www.w3.org/1999/xhtml" xmlns:odk="http://www.opendatakit.org/xforms" xmlns:example="http://example.com">
    <h:head>
        <h:title>Prefix calculate</h:title>
        <model odk:xforms-version="1.0.0">
            <instance>
                <data id="prefix-calculate" version="1">
                    <question/>
                    <example:calculate/>
                </data>
            </instance>
            <bind calculate="/data/question" nodeset="/data/example:calculate" type="string"/>
        </model>
    </h:head>
    <h:body>
        <input ref="/data/question">
            <label>Question</label>
        </input>
    </h:body>
</h:html>

1. Parse the form with XFormParser
2. Serialize and deserialize the FormDef using writeExternal/readExternal
3. Use the deserialized FormDef for form entry (with FormEntryController), filling out the single question with an answer and then finalizing and serializing the instance (with finalizeForm and XFormSerializingVisitor)

The serialized instance will contain <example:calculate /> rather than <example:calculate>...</example:calculate> with your answer. The calculate node is correctly populated when using a FormDef that comes from the parser directly.

Expected behavior

The node should be populated for a deserialized FormDef.

Other information

Discovered using Collect, so there is some risk that the bug might actually be there. My understanding is that calculates are handled in JavaRosa. It would be good to write a failing test to confirm the problem in JavaRosa.

[seadowg]

We need to more things before looking at a fix:

• Are we addressing namespaced nodes correctly in my example?
• A test that proves this is a problem in JavaRosa (and not a Collect issue)

[lognaturel]

Are we addressing namespaced nodes correctly in my example?

It looked a bit strange to me but I think it's just because example is a long prefix.

I can't quickly find a part of the spec that explains namespaces in queries but https://www.ibm.com/support/pages/how-use-xpath-namespaces-rit shows related examples.

[seadowg]

I can't quickly find a part of the spec that explains namespaces in queries but https://www.ibm.com/support/pages/how-use-xpath-namespaces-rit shows related examples.

These docs seem to suggest to me that our current thinking is incorrect and that XPath does not support paths with namespaces:

And there is no available syntax of this nature:

/my:root/my:child/my:grandchild/my:greatgrandchild/@name

Instead need this expression (normally formatted as a single line):

/*["root"=local-name()]
/*["child"=local-name()]
/*["grandchild"=local-name()]
/*["greatgrandchild"=local-name()]
/@name

This would suggest to me that the nodeset="/data/example:calculate" in my example is not valid. I'm assuming I'm missing something here though.

[seadowg]

It looks like the article linked by @lognaturel is misleading. This article shows an example of XPath queries with prefixes: https://learn.microsoft.com/en-us/dotnet/standard/data/xml/xpath-queries-and-namespaces.