Current() in XPath predicate

Mitch_S · November 13, 2015, 10:18pm

I think this is a bug.

But I don't know what the XForms standard says about this (frankly, my eyes
glaze over on the spec document, so I have played fast and loose with
compliance).

As a counter-example, attached is a form that uses current() inside a
calculation and an tag. In both those circumstances, current()/.
is the field and not the group containing the field.

So I think that the choice list reference is incorrect.
I think current()/. should point to the field, and not the group
containing the field when we try to resolve the choice list.

For the attached XLS file, if you work from the xls file, you need to
hand-edit the xml to change the tag to be what it needs to be.

Changing ${fieldname} to expand using current()/... syntax would be an
awesome contribution.

Not sure what impact it has on indexed-repeat().

Assuming it is a bug, we should change javarosa to have this reference the
field and not the enclosing group.
Not sure how to manage or coordinate deploying this bug fix.

*COMPATIBILITY NOTE: *

The ODK fork of javarosa ( https://bitbucket.org/m.sundt/javarosa ) has
enhanced syntax on current()/ w.r.t. the Dimagi / CommCare base repo (
https://bitbucket.org/javarosa/ ), at least as of the time I forked from
that repo. When this was forked, I added support for relative path
expressions -- in the javarosa Dimagi branch, current()/ did not support
relative path expressions (e.g., current()/../...). It only supported
absolute path expressions (i.e., current()/myform/group1/fieldname).

I don't know whether that change conforms to the XForms spec or if it is
divergent (but it is extremely useful and powerful).

NBiggestOfSet.xml (5.77 KB)

NBiggestOfSet.xls (31.5 KB)

···

On Fri, Nov 13, 2015 at 1:46 PM, Christopher Robert wrote:

Thanks, Martijn, for posting this.

For a bit of context, this came up because we've patched SurveyCTO's
pyxform branch to replace ${x} references in choice_filter columns with
expressions relative to current() so that users can refer to repeated
values (from within the current repeat context) in cascading selects. Our
solution seems to work with the current version of JR/Collect, but it
relies on this behavior that Martijn discusses.

If the behavior is judged stable and desirable, then we're happy to move
forward with a patched pyxform and also share that with the community.
Users will celebrate if the restriction on easily referencing in-context
repeat fields were lifted.

Thanks,

Chris

On Fri, Nov 13, 2015 at 4:38 PM Martijn van de Rijdt martijn@enketo.org wrote:
Hi,

I'd like to ask for a clarification about the current() node in an XPath
predicate. It seems JR considers this to be the parent node of the
current question. (Thanks to Chris for sharing this.)

E.g. in this question below, current() equates to /data/group and not to
/data/group/options. I would have expected it to be the latter.
....
    <label>label</label>

    <itemset nodeset="instance('crop_list')/root/item[name =
current()*/../*crop]">
         ....

         ....

    </itemset>
Is this by design? Or is it a bug?

We ran into this by realizing that the seemingly more intuitive predicate
[name = current()*/../../*crop] is not working.

See this form
https://docs.google.com/spreadsheets/d/1A74yEHRxQF1zbIcQSrwvZydggUU7m5T3ZAnlR6_TLA4/edit#gid=0
that illustrates the behaviour nicely. If current() is used in a
calculation (even if it makes no sense to do so) this extra step down is
not taken, but in a predicate it is. So it seems the behaviour is not
related to the current() function but to how predicates are handled in JR.

Thanks,
Martijn

--
Revolutionizing data collection since 2012.

Enketo https://enketo.org/ | LinkedIn
http://www.linkedin.com/company/enketo-llc | GitHub
https://github.com/enketo | Twitter https://twitter.com/enketo
| Blog http://blog.enketo.org/

--
You received this message because you are subscribed to the Google Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com

martijnr · November 13, 2015, 11:03pm

Thanks Mitch,

Indeed relative paths with current() are very useful. Pyxform ${syntax}
translation for choice-lists (as a start to use relative paths with
current() is very welcome indeed Chris!

I hadn't realized current() was part of XForms (just found XSLT
references), but I see this now in XForms 2.0:
http://www.w3.org/TR/xforms-xpath/#The_current.28.29_Function, so indeed it
is a bug.

I'll implement current() to be the current field then (in Enketo).

···

On Fri, Nov 13, 2015 at 3:18 PM, Mitch Sundt wrote:

I think this is a bug.

But I don't know what the XForms standard says about this (frankly, my
eyes glaze over on the spec document, so I have played fast and loose with
compliance).

As a counter-example, attached is a form that uses current() inside a
calculation and an tag. In both those circumstances, current()/.
is the field and not the group containing the field.

So I think that the choice list reference is incorrect.
I think current()/. should point to the field, and not the group
containing the field when we try to resolve the choice list.

For the attached XLS file, if you work from the xls file, you need to
hand-edit the xml to change the tag to be what it needs to be.

Changing ${fieldname} to expand using current()/... syntax would be an
awesome contribution.

Not sure what impact it has on indexed-repeat().

Assuming it is a bug, we should change javarosa to have this reference the
field and not the enclosing group.
Not sure how to manage or coordinate deploying this bug fix.

*COMPATIBILITY NOTE: *

The ODK fork of javarosa ( https://bitbucket.org/m.sundt/javarosa ) has
enhanced syntax on current()/ w.r.t. the Dimagi / CommCare base repo (
https://bitbucket.org/javarosa/ ), at least as of the time I forked from
that repo. When this was forked, I added support for relative path
expressions -- in the javarosa Dimagi branch, current()/ did not support
relative path expressions (e.g., current()/../...). It only supported
absolute path expressions (i.e., current()/myform/group1/fieldname).

I don't know whether that change conforms to the XForms spec or if it is
divergent (but it is extremely useful and powerful).

On Fri, Nov 13, 2015 at 1:46 PM, Christopher Robert <crobert@surveycto.com wrote:
Thanks, Martijn, for posting this.

For a bit of context, this came up because we've patched SurveyCTO's
pyxform branch to replace ${x} references in choice_filter columns with
expressions relative to current() so that users can refer to repeated
values (from within the current repeat context) in cascading selects. Our
solution seems to work with the current version of JR/Collect, but it
relies on this behavior that Martijn discusses.

If the behavior is judged stable and desirable, then we're happy to move
forward with a patched pyxform and also share that with the community.
Users will celebrate if the restriction on easily referencing in-context
repeat fields were lifted.

Thanks,

Chris

On Fri, Nov 13, 2015 at 4:38 PM Martijn van de Rijdt martijn@enketo.org wrote:
Hi,

I'd like to ask for a clarification about the current() node in an XPath
predicate. It seems JR considers this to be the parent node of the
current question. (Thanks to Chris for sharing this.)

E.g. in this question below, current() equates to /data/group and not to
/data/group/options. I would have expected it to be the latter.
....
    <label>label</label>

    <itemset nodeset="instance('crop_list')/root/item[name =
current()*/../*crop]">
         ....

         ....

    </itemset>
Is this by design? Or is it a bug?

We ran into this by realizing that the seemingly more intuitive predicate
[name = current()*/../../*crop] is not working.

See this form
https://docs.google.com/spreadsheets/d/1A74yEHRxQF1zbIcQSrwvZydggUU7m5T3ZAnlR6_TLA4/edit#gid=0
that illustrates the behaviour nicely. If current() is used in a
calculation (even if it makes no sense to do so) this extra step down is
not taken, but in a predicate it is. So it seems the behaviour is not
related to the current() function but to how predicates are handled in JR.

Thanks,
Martijn

--
Revolutionizing data collection since 2012.

Enketo https://enketo.org/ | LinkedIn
http://www.linkedin.com/company/enketo-llc | GitHub
https://github.com/enketo | Twitter https://twitter.com/enketo
| Blog http://blog.enketo.org/

--
You received this message because you are subscribed to the Google
Groups "ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com

--
You received this message because you are subscribed to a topic in the
Google Groups "ODK Developers" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/opendatakit-developers/nN8HTA5pUIM/unsubscribe
.
To unsubscribe from this group and all its topics, send an email to
opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Revolutionizing data collection since 2012.

Enketo https://enketo.org/ | LinkedIn
http://www.linkedin.com/company/enketo-llc | GitHub
https://github.com/enketo | Twitter https://twitter.com/enketo
| Blog http://blog.enketo.org/

crobert · November 14, 2015, 3:36am

Since there are literally thousands of devices in the field running current
and older versions of Collect -- and will be for a very long time yet -- we
cannot implement a change that will create forms incompatible with all of
those devices. In other words, if Collect/JR is "fixed" such that current()
in itemset predicates point to the field rather than one step back from the
field, then we can neither introduce a pyxform that relies on the fixed
version nor introduce a pyxform that relies on the broken version. Too many
devices would experience problems in both directions.

So, it seems our choices are: (1) fix the SurveyCTO pyxform to rely on the
current "broken" JR , maintain that flaw in SurveyCTO's JR branch, and live
with SurveyCTO's cascading selects breaking compatibility with Enketo; or
(2) leave things as they are so users are unable to refer to within-context
repeated values in cascading-select filters. An in-between option would be
to document the current() approach for people to hand-code the proper
XPaths into their XLSForms -- but even that is problematic if JR's
treatment of current() is going to change (and/or if Enketo's current() is
going to behave differently).

For what it's worth, "fixed" versions of Collect that change the nature of
current() in itemset predicates will break all forms for all users who have
taken the advice to use current() in their cascading-select filters. It
will be a pretty painful break, I imagine.

If anybody has an idea about how to resolve all of this without breaking
compatibility for thousands of devices and forms, I'm all ears.

Thanks!

Chris

···

On Fri, Nov 13, 2015 at 6:03 PM Martijn van de Rijdt wrote:

Thanks Mitch,

Indeed relative paths with current() are very useful. Pyxform ${syntax}
translation for choice-lists (as a start to use relative paths with
current() is very welcome indeed Chris!

I hadn't realized current() was part of XForms (just found XSLT
references), but I see this now in XForms 2.0:
http://www.w3.org/TR/xforms-xpath/#The_current.28.29_Function, so indeed
it is a bug.

I'll implement current() to be the current field then (in Enketo).

On Fri, Nov 13, 2015 at 3:18 PM, Mitch Sundt mitchellsundt@gmail.com wrote:
I think this is a bug.

But I don't know what the XForms standard says about this (frankly, my
eyes glaze over on the spec document, so I have played fast and loose with
compliance).

As a counter-example, attached is a form that uses current() inside a
calculation and an tag. In both those circumstances, current()/.
is the field and not the group containing the field.

So I think that the choice list reference is incorrect.
I think current()/. should point to the field, and not the group
containing the field when we try to resolve the choice list.

For the attached XLS file, if you work from the xls file, you need to
hand-edit the xml to change the tag to be what it needs to be.

Changing ${fieldname} to expand using current()/... syntax would be an
awesome contribution.

Not sure what impact it has on indexed-repeat().

Assuming it is a bug, we should change javarosa to have this reference
the field and not the enclosing group.
Not sure how to manage or coordinate deploying this bug fix.

*COMPATIBILITY NOTE: *

The ODK fork of javarosa ( https://bitbucket.org/m.sundt/javarosa ) has
enhanced syntax on current()/ w.r.t. the Dimagi / CommCare base repo (
https://bitbucket.org/javarosa/ ), at least as of the time I forked from
that repo. When this was forked, I added support for relative path
expressions -- in the javarosa Dimagi branch, current()/ did not support
relative path expressions (e.g., current()/../...). It only supported
absolute path expressions (i.e., current()/myform/group1/fieldname).

I don't know whether that change conforms to the XForms spec or if it is
divergent (but it is extremely useful and powerful).

On Fri, Nov 13, 2015 at 1:46 PM, Christopher Robert < crobert@surveycto.com> wrote:
Thanks, Martijn, for posting this.

For a bit of context, this came up because we've patched SurveyCTO's
pyxform branch to replace ${x} references in choice_filter columns with
expressions relative to current() so that users can refer to repeated
values (from within the current repeat context) in cascading selects. Our
solution seems to work with the current version of JR/Collect, but it
relies on this behavior that Martijn discusses.

If the behavior is judged stable and desirable, then we're happy to move
forward with a patched pyxform and also share that with the community.
Users will celebrate if the restriction on easily referencing in-context
repeat fields were lifted.

Thanks,

Chris

On Fri, Nov 13, 2015 at 4:38 PM Martijn van de Rijdt martijn@enketo.org wrote:
Hi,

I'd like to ask for a clarification about the current() node in an
XPath predicate. It seems JR considers this to be the parent node of
the current question. (Thanks to Chris for sharing this.)

E.g. in this question below, current() equates to /data/group and not
to /data/group/options. I would have expected it to be the latter.
....
    <label>label</label>

    <itemset nodeset="instance('crop_list')/root/item[name =
current()*/../*crop]">
         ....

         ....

    </itemset>
Is this by design? Or is it a bug?

We ran into this by realizing that the seemingly more intuitive
predicate [name = current()*/../../*crop] is not working.

See this form
https://docs.google.com/spreadsheets/d/1A74yEHRxQF1zbIcQSrwvZydggUU7m5T3ZAnlR6_TLA4/edit#gid=0
that illustrates the behaviour nicely. If current() is used in a
calculation (even if it makes no sense to do so) this extra step down is
not taken, but in a predicate it is. So it seems the behaviour is not
related to the current() function but to how predicates are handled in JR.

Thanks,
Martijn

--
Revolutionizing data collection since 2012.

Enketo https://enketo.org/ | LinkedIn
http://www.linkedin.com/company/enketo-llc | GitHub
https://github.com/enketo | Twitter
https://twitter.com/enketo | Blog http://blog.enketo.org/

--
You received this message because you are subscribed to the Google
Groups "ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google
Groups "ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com
--

You received this message because you are subscribed to a topic in the
Google Groups "ODK Developers" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/opendatakit-developers/nN8HTA5pUIM/unsubscribe
.
To unsubscribe from this group and all its topics, send an email to
opendatakit-developers+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
Revolutionizing data collection since 2012.

Enketo https://enketo.org/ | LinkedIn
http://www.linkedin.com/company/enketo-llc | GitHub
https://github.com/enketo | Twitter https://twitter.com/enketo
| Blog http://blog.enketo.org/

--
You received this message because you are subscribed to the Google Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Mitch_S · November 20, 2015, 3:35pm

Hi Meletis,

That's not the issue --

The issue is that if you use a filter condition in the nodeset
specification of a field "myfield", within that nodeset specification
"current()/.." refers to the parent of the group enclosing the "myfield"
field. It does not refer to the group enclosing the "myfield" field.

So if you have

<instance>
   <data id="myform">
        <group1>
             <filterfield/>
             <myfield/>
         </group1>
    </data>
    <data>
</instance>

<instance id="food">
   <root>
      <fooditem>
         <filtercriteria>a</filtercriteria>
         <code>4</code>
         <name>fish</name>
      </fooditem>
      <fooditem>
         <filtercriteria>b</filtercriteria>
         <code>14</code>
         <name>fish</name>
      </fooditem>
      ...
    </root>
 </instance>

and if you have:

<select1 ref="/data/group1/myfield">
   <itemset
nodeset="instance('food')/root/fooditem[filtercriteria=current()/../filterfield]">
            <value ref="code"/>
            <label ref="name"/>
    </itemset>
</select1>

This will currently be broken. Because current()/../filterfield,
when evaluated within the itemset nodeset specification, is resolved to:

/data/filterfield

instead of

/data/group1/filterfield

···

On Fri, Nov 20, 2015 at 1:58 AM, wrote:

Well, I think there is a fundamental issue here regarding current()
syntax. Please, let me remind you how JR works with "current()":

The expression "current()" looks like a function but it is not treated
like one; it is not handled by the XPathFuncExpr class, so, if you try to
use it alone you will get an error that the "function" is not supported. In
other words, you cannot use it alone in an expression in order to refer to
the "current" field.

When an expression includes "current()", then it ALWAYS needs to be
used in an XPath, actually, the expression needs to BE an XPath expression,
so that it can be handled with the XPathPathExpr class. For that reason the
expression NEEDS to contain at least one "/".

Taking 1 and 2 into consideration, the ONLY way to refer to the
"current" field (named "somefield") is to use "current()/." or
"current()/somefield". So, I looks like that the original implementation
was "okay" in the sense that the "current()" should only be used in XPaths.

If we wanted to have "current()" refer to the current field, I believe we
should introduce a new function handler in XPathFuncExpr class. Please let
me know if this would work:

A. Whenever the "current()" expression is used inside an XPath, then the
current code would be used as it is used right now (maintaining backwards
compatibility), so that it will still be referring to the enclosing group,
not the field itself.
B. Whenever the "current()" expression is used inside a non-XPath, then
the new code would be used (in XPathFuncExpr) and that would be evaluated
in a way that the current field would be returned/referenced, NOT the
enclosing group.

That way, the following code could work, because it wouldn't throw the
"unrecognized function" error:
label .... ....
What do you think about that approach?

Meletis

On Friday, November 13, 2015 at 11:38:15 PM UTC+2, Martijn van de Rijdt wrote:
Hi,

I'd like to ask for a clarification about the current() node in an XPath
predicate. It seems JR considers this to be the parent node of the
current question. (Thanks to Chris for sharing this.)

E.g. in this question below, current() equates to /data/group and not to
/data/group/options. I would have expected it to be the latter.
....
    <label>label</label>

    <itemset nodeset="instance('crop_list')/root/item[name =
current()*/../*crop]">
         ....

         ....

    </itemset>
Is this by design? Or is it a bug?

We ran into this by realizing that the seemingly more intuitive predicate
[name = current()*/../../*crop] is not working.

See this form
https://docs.google.com/spreadsheets/d/1A74yEHRxQF1zbIcQSrwvZydggUU7m5T3ZAnlR6_TLA4/edit#gid=0
that illustrates the behaviour nicely. If current() is used in a
calculation (even if it makes no sense to do so) this extra step down is
not taken, but in a predicate it is. So it seems the behaviour is not
related to the current() function but to how predicates are handled in JR.

Thanks,
Martijn

--
You received this message because you are subscribed to the Google Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com

yanokwa · November 15, 2015, 6:56am

Chris,

I think correct behavior is more important than keeping compatibility.
You can only carry technical debt for so long...

We can warn at on the first the form is loaded in release 0, that
folks should fix their forms. Then in release 1, warn every time the
form is loaded. Then release 2, we change the behavior.

Yaw

···

-- Need ODK consultants? Nafundi provides form design, server setup, in-field training, and software development for ODK. Go to https://nafundi.com to get started.

On Sat, Nov 14, 2015 at 10:36 AM, Christopher Robert crobert@surveycto.com wrote:

Since there are literally thousands of devices in the field running current
and older versions of Collect -- and will be for a very long time yet -- we
cannot implement a change that will create forms incompatible with all of
those devices. In other words, if Collect/JR is "fixed" such that current()
in itemset predicates point to the field rather than one step back from the
field, then we can neither introduce a pyxform that relies on the fixed
version nor introduce a pyxform that relies on the broken version. Too many
devices would experience problems in both directions.

So, it seems our choices are: (1) fix the SurveyCTO pyxform to rely on the
current "broken" JR , maintain that flaw in SurveyCTO's JR branch, and live
with SurveyCTO's cascading selects breaking compatibility with Enketo; or
(2) leave things as they are so users are unable to refer to within-context
repeated values in cascading-select filters. An in-between option would be
to document the current() approach for people to hand-code the proper XPaths
into their XLSForms -- but even that is problematic if JR's treatment of
current() is going to change (and/or if Enketo's current() is going to
behave differently).

For what it's worth, "fixed" versions of Collect that change the nature of
current() in itemset predicates will break all forms for all users who have
taken the advice to use current() in their cascading-select filters. It will
be a pretty painful break, I imagine.

If anybody has an idea about how to resolve all of this without breaking
compatibility for thousands of devices and forms, I'm all ears.

Thanks!

Chris

On Fri, Nov 13, 2015 at 6:03 PM Martijn van de Rijdt martijn@enketo.org wrote:
Thanks Mitch,

Indeed relative paths with current() are very useful. Pyxform ${syntax}
translation for choice-lists (as a start to use relative paths with
current() is very welcome indeed Chris!

I hadn't realized current() was part of XForms (just found XSLT
references), but I see this now in XForms 2.0:
http://www.w3.org/TR/xforms-xpath/#The_current.28.29_Function, so indeed it
is a bug.

I'll implement current() to be the current field then (in Enketo).

On Fri, Nov 13, 2015 at 3:18 PM, Mitch Sundt mitchellsundt@gmail.com wrote:
I think this is a bug.

But I don't know what the XForms standard says about this (frankly, my
eyes glaze over on the spec document, so I have played fast and loose with
compliance).

As a counter-example, attached is a form that uses current() inside a
calculation and an tag. In both those circumstances, current()/. is
the field and not the group containing the field.

So I think that the choice list reference is incorrect.
I think current()/. should point to the field, and not the group
containing the field when we try to resolve the choice list.

For the attached XLS file, if you work from the xls file, you need to
hand-edit the xml to change the tag to be what it needs to be.

Changing ${fieldname} to expand using current()/... syntax would be an
awesome contribution.

Not sure what impact it has on indexed-repeat().

Assuming it is a bug, we should change javarosa to have this reference
the field and not the enclosing group.
Not sure how to manage or coordinate deploying this bug fix.

COMPATIBILITY NOTE:

The ODK fork of javarosa ( https://bitbucket.org/m.sundt/javarosa ) has
enhanced syntax on current()/ w.r.t. the Dimagi / CommCare base repo (
https://bitbucket.org/javarosa/ ), at least as of the time I forked from
that repo. When this was forked, I added support for relative path
expressions -- in the javarosa Dimagi branch, current()/ did not support
relative path expressions (e.g., current()/../...). It only supported
absolute path expressions (i.e., current()/myform/group1/fieldname).

I don't know whether that change conforms to the XForms spec or if it is
divergent (but it is extremely useful and powerful).

On Fri, Nov 13, 2015 at 1:46 PM, Christopher Robert crobert@surveycto.com wrote:
Thanks, Martijn, for posting this.

For a bit of context, this came up because we've patched SurveyCTO's
pyxform branch to replace ${x} references in choice_filter columns with
expressions relative to current() so that users can refer to repeated values
(from within the current repeat context) in cascading selects. Our solution
seems to work with the current version of JR/Collect, but it relies on this
behavior that Martijn discusses.

If the behavior is judged stable and desirable, then we're happy to move
forward with a patched pyxform and also share that with the community. Users
will celebrate if the restriction on easily referencing in-context repeat
fields were lifted.

Thanks,

Chris

On Fri, Nov 13, 2015 at 4:38 PM Martijn van de Rijdt martijn@enketo.org wrote:
Hi,

I'd like to ask for a clarification about the current() node in an
XPath predicate. It seems JR considers this to be the parent node of the
current question. (Thanks to Chris for sharing this.)

E.g. in this question below, current() equates to /data/group and not
to /data/group/options. I would have expected it to be the latter.
....
    <label>label</label>

    <itemset nodeset="instance('crop_list')/root/item[name =
current()/../crop]">
         ....

         ....

    </itemset>
Is this by design? Or is it a bug?

We ran into this by realizing that the seemingly more intuitive
predicate [name = current()/../../crop] is not working.

See this form that illustrates the behaviour nicely. If current() is
used in a calculation (even if it makes no sense to do so) this extra step
down is not taken, but in a predicate it is. So it seems the behaviour is
not related to the current() function but to how predicates are handled in
JR.

Thanks,
Martijn

--
Revolutionizing data collection since 2012.

Enketo | LinkedIn | GitHub | Twitter | Blog

--
You received this message because you are subscribed to the Google
Groups "ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google
Groups "ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com

--
You received this message because you are subscribed to a topic in the
Google Groups "ODK Developers" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/opendatakit-developers/nN8HTA5pUIM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
opendatakit-developers+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.
--
Revolutionizing data collection since 2012.

Enketo | LinkedIn | GitHub | Twitter | Blog

--
You received this message because you are subscribed to the Google Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Meletis · November 20, 2015, 4:22pm

Hi Mitch,

I think I'm missing something but I think that nothing is broken and that
the only issue is that the expression current()/../filterfield in your
example above should be just changed to current()/filterfield. If you make
that change, everything should work because it will be resolved to:

/data/group1/filterfield

Why should a "../" be present there? We have used current()/somefield
successfully in one of our test forms and it works fine. And I think it
would also work great in your example. Wouldn't it? Or am I totally out of
context?

Meletis

···

On Friday, November 20, 2015 at 5:35:16 PM UTC+2, Mitch wrote: > > Hi Meletis, > > That's not the issue -- > > The issue is that if you use a filter condition in the nodeset > specification of a field "myfield", within that nodeset specification > "current()/.." refers to the parent of the group enclosing the "myfield" > field. It does not refer to the group enclosing the "myfield" field. > > So if you have > > > > > > > > > > > > > > > a > 4 > fish > > > b > 14 > fish > > ... > > > > and if you have: > > > nodeset="instance('food')/root/fooditem[filtercriteria=current()/../filterfield]"> > > > > > > This will currently be broken. Because current()/../filterfield, > when evaluated within the itemset nodeset specification, is resolved to: > > /data/filterfield > > instead of > > /data/group1/filterfield > > > On Fri, Nov 20, 2015 at 1:58 AM, <mel...@surveycto.com > wrote: > >> Well, I think there is a fundamental issue here regarding current() >> syntax. Please, let me remind you how JR works with "current()": >> >> 1. The expression "current()" looks like a function but it is not treated >> like one; it is not handled by the XPathFuncExpr class, so, if you try to >> use it alone you will get an error that the "function" is not supported. In >> other words, you cannot use it alone in an expression in order to refer to >> the "current" field. >> >> 2. When an expression includes "current()", then it ALWAYS needs to be >> used in an XPath, actually, the expression needs to BE an XPath expression, >> so that it can be handled with the XPathPathExpr class. For that reason the >> expression NEEDS to contain at least one "/". >> >> 3. Taking 1 and 2 into consideration, the ONLY way to refer to the >> "current" field (named "somefield") is to use "current()/." or >> "current()/somefield". So, I looks like that the original implementation >> was "okay" in the sense that the "current()" should only be used in XPaths. >> >> If we wanted to have "current()" refer to the current field, I believe we >> should introduce a new function handler in XPathFuncExpr class. Please let >> me know if this would work: >> >> A. Whenever the "current()" expression is used inside an XPath, then the >> current code would be used as it is used right now (maintaining backwards >> compatibility), so that it will still be referring to the enclosing group, >> not the field itself. >> B. Whenever the "current()" expression is used inside a non-XPath, then >> the new code would be used (in XPathFuncExpr) and that would be evaluated >> in a way that the current field would be returned/referenced, NOT the >> enclosing group. >> >> That way, the following code could work, because it wouldn't throw the >> "unrecognized function" error: >> >> >> label >> >> .... >> .... >> >> >> >> What do you think about that approach? >> >> Meletis >> >> >> >> On Friday, November 13, 2015 at 11:38:15 PM UTC+2, Martijn van de Rijdt wrote: >>> >>> Hi, >>> >>> I'd like to ask for a clarification about the current() node in an XPath >>> predicate. It seems JR considers this to be the *parent* node of the >>> current question. (Thanks to Chris for sharing this.) >>> >>> E.g. in this question below, current() equates to /data/group and not to >>> /data/group/options. I would have expected it to be the latter. >>> >>> >>> >>> .... >>> >>> >>> >>> >>> >>> label >>> >>> >>> >>> .... >>> >>> .... >>> >>> >>> >>> >>> >>> >>> Is this by design? Or is it a bug? >>> >>> >>> We ran into this by realizing that the seemingly more intuitive predicate >>> [name = current()*/../../*crop] is not working. >>> >>> >>> See this form >>> >>> that illustrates the behaviour nicely. If current() is used in a >>> calculation (even if it makes no sense to do so) this extra step down is >>> not taken, but in a predicate it is. So it seems the behaviour is not >>> related to the current() function but to how predicates are handled in JR. >>> >>> >>> Thanks, >>> Martijn >>> >>> >>> -- >> >> > > > -- > Mitch Sundt > Software Engineer > University of Washington > mitche...@gmail.com >

crobert · November 15, 2015, 7:13pm

Okay, since everybody seems bullish about changing the JavaRosa behavior
here, does anybody have ideas on how to do it safely? Making a change like
this seems at high risk for not only breaking forms that rely on behavior
judged improper ex post, but even forms that rely on correct behavior.
And since nobody seems 100% clear on what precisely correct behavior should
be in every circumstance, the risks of messing up seem even higher than is
usual for any JavaRosa intervention.

I'd like to empower users to refer to repeated values using XLSForm choice
filters, and this now seems fully within reach (in fact I have it working
nicely here already). But if that's going to require a major and risky
JavaRosa adventure, then I am far less sure that the benefits outweigh the
costs.

Yaw, do you understand that itemset/predicate evaluation code? Or Mitch,
since it sounds like you added this current current() support, can you
suggest where it might have gone wrong?

Thanks all,

Chris

···

On Sun, Nov 15, 2015 at 1:57 AM Yaw Anokwa wrote:

Chris,

I think correct behavior is more important than keeping compatibility.
You can only carry technical debt for so long...

We can warn at on the first the form is loaded in release 0, that
folks should fix their forms. Then in release 1, warn every time the
form is loaded. Then release 2, we change the behavior.

Yaw

Need ODK consultants? Nafundi provides form design, server setup,
in-field training, and software development for ODK. Go to
https://nafundi.com to get started.

On Sat, Nov 14, 2015 at 10:36 AM, Christopher Robert crobert@surveycto.com wrote:
Since there are literally thousands of devices in the field running
current
and older versions of Collect -- and will be for a very long time yet --
we
cannot implement a change that will create forms incompatible with all of
those devices. In other words, if Collect/JR is "fixed" such that
current()
in itemset predicates point to the field rather than one step back from
the
field, then we can neither introduce a pyxform that relies on the fixed
version nor introduce a pyxform that relies on the broken version. Too
many
devices would experience problems in both directions.

So, it seems our choices are: (1) fix the SurveyCTO pyxform to rely on
the
current "broken" JR , maintain that flaw in SurveyCTO's JR branch, and
live
with SurveyCTO's cascading selects breaking compatibility with Enketo; or
(2) leave things as they are so users are unable to refer to
within-context
repeated values in cascading-select filters. An in-between option would
be
to document the current() approach for people to hand-code the proper
XPaths
into their XLSForms -- but even that is problematic if JR's treatment of
current() is going to change (and/or if Enketo's current() is going to
behave differently).

For what it's worth, "fixed" versions of Collect that change the nature
of
current() in itemset predicates will break all forms for all users who
have
taken the advice to use current() in their cascading-select filters. It
will
be a pretty painful break, I imagine.

If anybody has an idea about how to resolve all of this without breaking
compatibility for thousands of devices and forms, I'm all ears.

Thanks!

Chris

On Fri, Nov 13, 2015 at 6:03 PM Martijn van de Rijdt <martijn@enketo.org wrote:

Thanks Mitch,

Indeed relative paths with current() are very useful. Pyxform ${syntax}
translation for choice-lists (as a start to use relative paths with
current() is very welcome indeed Chris!

I hadn't realized current() was part of XForms (just found XSLT
references), but I see this now in XForms 2.0:
http://www.w3.org/TR/xforms-xpath/#The_current.28.29_Function, so
indeed it

is a bug.

I'll implement current() to be the current field then (in Enketo).

On Fri, Nov 13, 2015 at 3:18 PM, Mitch Sundt mitchellsundt@gmail.com wrote:

I think this is a bug.

But I don't know what the XForms standard says about this (frankly, my
eyes glaze over on the spec document, so I have played fast and loose
with

compliance).

As a counter-example, attached is a form that uses current() inside a
calculation and an tag. In both those circumstances,
current()/. is

the field and not the group containing the field.

So I think that the choice list reference is incorrect.
I think current()/. should point to the field, and not the group
containing the field when we try to resolve the choice list.

For the attached XLS file, if you work from the xls file, you need to
hand-edit the xml to change the tag to be what it needs to be.

Changing ${fieldname} to expand using current()/... syntax would be an
awesome contribution.

Not sure what impact it has on indexed-repeat().

Assuming it is a bug, we should change javarosa to have this reference
the field and not the enclosing group.
Not sure how to manage or coordinate deploying this bug fix.

COMPATIBILITY NOTE:

The ODK fork of javarosa ( https://bitbucket.org/m.sundt/javarosa )
has

enhanced syntax on current()/ w.r.t. the Dimagi / CommCare base repo (
https://bitbucket.org/javarosa/ ), at least as of the time I forked
from

that repo. When this was forked, I added support for relative path
expressions -- in the javarosa Dimagi branch, current()/ did not
support

relative path expressions (e.g., current()/../...). It only supported
absolute path expressions (i.e., current()/myform/group1/fieldname).

I don't know whether that change conforms to the XForms spec or if it
is

divergent (but it is extremely useful and powerful).

On Fri, Nov 13, 2015 at 1:46 PM, Christopher Robert crobert@surveycto.com wrote:

Thanks, Martijn, for posting this.

For a bit of context, this came up because we've patched SurveyCTO's
pyxform branch to replace ${x} references in choice_filter columns
with

expressions relative to current() so that users can refer to repeated
values

(from within the current repeat context) in cascading selects. Our
solution

seems to work with the current version of JR/Collect, but it relies
on this

behavior that Martijn discusses.

If the behavior is judged stable and desirable, then we're happy to
move

forward with a patched pyxform and also share that with the
community. Users

will celebrate if the restriction on easily referencing in-context
repeat

fields were lifted.

Thanks,

Chris

On Fri, Nov 13, 2015 at 4:38 PM Martijn van de Rijdt martijn@enketo.org wrote:

Hi,

I'd like to ask for a clarification about the current() node in an
XPath predicate. It seems JR considers this to be the parent node of
the
current question. (Thanks to Chris for sharing this.)

E.g. in this question below, current() equates to /data/group and not
to /data/group/options. I would have expected it to be the latter.
....
    <label>label</label>

    <itemset nodeset="instance('crop_list')/root/item[name =
current()/../crop]">
         ....

         ....

    </itemset>
Is this by design? Or is it a bug?

We ran into this by realizing that the seemingly more intuitive
predicate [name = current()/../../crop] is not working.

See this form that illustrates the behaviour nicely. If current() is
used in a calculation (even if it makes no sense to do so) this
extra step
down is not taken, but in a predicate it is. So it seems the
behaviour is

not related to the current() function but to how predicates are
handled in

JR.

Thanks,
Martijn

--
Revolutionizing data collection since 2012.

Enketo | LinkedIn | GitHub | Twitter | Blog

--
You received this message because you are subscribed to the Google
Groups "ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it,
send

an email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google
Groups "ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com

--
You received this message because you are subscribed to a topic in the
Google Groups "ODK Developers" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/opendatakit-developers/nN8HTA5pUIM/unsubscribe
.

To unsubscribe from this group and all its topics, send an email to
opendatakit-developers+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
Revolutionizing data collection since 2012.

Enketo | LinkedIn | GitHub | Twitter | Blog

--
You received this message because you are subscribed to the Google
Groups

"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send
an

email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Mitch_S · November 20, 2015, 5:26pm

The issue is that there is a discrepancy in the meaning of '.' across the
different contexts of: calculate, relevant, <output>, and these itemset
nodeset expressions.

In other usages, you need to reference this other field with
current()/../filterfield; but in the nodeset expression, you would
reference it with current()/./filterfield

I.e., the notion of '.' is different when used within a nodeset expression
and when used within a constraint expression or an <output> field.

See the attached NBiggestOfSet form. For the label, it has:

        <select1 ref="/NBiggestOfSet/education/edu_level">
          <label>What is <output value="
*current()/../referred_attendee_name*"/>'s level of education?</label>
         ...

For a constraint, it has:

<bind calculate="/NBiggestOfSet/attendee/name[position(..)=int
*(current()/../referred_attendee)*]"
nodeset="/NBiggestOfSet/education/referred_attendee_name" readonly="true()"
type="string"/>

These each use the current()/../ to reference the group (
/NBiggesetOfSet/education ).

But, within the nodeset definition (if this form used one), you would need
to use current()/./referred_attendee_name to reference a field in that
group.

···

On Fri, Nov 20, 2015 at 8:22 AM, wrote:

Hi Mitch,

I think I'm missing something but I think that nothing is broken and that
the only issue is that the expression current()/../filterfield in your
example above should be just changed to current()/filterfield. If you make
that change, everything should work because it will be resolved to:

/data/group1/filterfield

Why should a "../" be present there? We have used current()/somefield
successfully in one of our test forms and it works fine. And I think it
would also work great in your example. Wouldn't it? Or am I totally out of
context?

Meletis

On Friday, November 20, 2015 at 5:35:16 PM UTC+2, Mitch wrote:
Hi Meletis,

That's not the issue --

The issue is that if you use a filter condition in the nodeset
specification of a field "myfield", within that nodeset specification
"current()/.." refers to the parent of the group enclosing the "myfield"
field. It does not refer to the group enclosing the "myfield" field.

So if you have
a 4 fish b 14 fish ...
and if you have:

This will currently be broken. Because current()/../filterfield,
when evaluated within the itemset nodeset specification, is resolved to:

/data/filterfield

instead of

/data/group1/filterfield

On Fri, Nov 20, 2015 at 1:58 AM, mel...@surveycto.com wrote:
Well, I think there is a fundamental issue here regarding current()
syntax. Please, let me remind you how JR works with "current()":

The expression "current()" looks like a function but it is not
treated like one; it is not handled by the XPathFuncExpr class, so, if you
try to use it alone you will get an error that the "function" is not
supported. In other words, you cannot use it alone in an expression in
order to refer to the "current" field.

When an expression includes "current()", then it ALWAYS needs to be
used in an XPath, actually, the expression needs to BE an XPath expression,
so that it can be handled with the XPathPathExpr class. For that reason the
expression NEEDS to contain at least one "/".

Taking 1 and 2 into consideration, the ONLY way to refer to the
"current" field (named "somefield") is to use "current()/." or
"current()/somefield". So, I looks like that the original implementation
was "okay" in the sense that the "current()" should only be used in XPaths.

If we wanted to have "current()" refer to the current field, I believe
we should introduce a new function handler in XPathFuncExpr class. Please
let me know if this would work:

A. Whenever the "current()" expression is used inside an XPath, then the
current code would be used as it is used right now (maintaining backwards
compatibility), so that it will still be referring to the enclosing group,
not the field itself.
B. Whenever the "current()" expression is used inside a non-XPath, then
the new code would be used (in XPathFuncExpr) and that would be evaluated
in a way that the current field would be returned/referenced, NOT the
enclosing group.

That way, the following code could work, because it wouldn't throw the
"unrecognized function" error:
label .... ....
What do you think about that approach?

Meletis

On Friday, November 13, 2015 at 11:38:15 PM UTC+2, Martijn van de Rijdt wrote:
Hi,

I'd like to ask for a clarification about the current() node in an
XPath predicate. It seems JR considers this to be the parent node of
the current question. (Thanks to Chris for sharing this.)

E.g. in this question below, current() equates to /data/group and not
to /data/group/options. I would have expected it to be the latter.
....
    <label>label</label>

    <itemset nodeset="instance('crop_list')/root/item[name =
current()*/../*crop]">
         ....

         ....

    </itemset>
Is this by design? Or is it a bug?

We ran into this by realizing that the seemingly more intuitive
predicate [name = current()*/../../*crop] is not working.

See this form
https://docs.google.com/spreadsheets/d/1A74yEHRxQF1zbIcQSrwvZydggUU7m5T3ZAnlR6_TLA4/edit#gid=0
that illustrates the behaviour nicely. If current() is used in a
calculation (even if it makes no sense to do so) this extra step down is
not taken, but in a predicate it is. So it seems the behaviour is not
related to the current() function but to how predicates are handled in JR.

Thanks,
Martijn

--
--
Mitch Sundt
Software Engineer
University of Washington
mitche...@gmail.com
--
You received this message because you are subscribed to the Google Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com

yanokwa · November 16, 2015, 2:13am

Chris,

It's been forever since I looked at the itemset code, so I'm not going
to be very useful here.

Yaw

···

-- Need ODK consultants? Nafundi provides form design, server setup, in-field training, and software development for ODK. Go to https://nafundi.com to get started.

On Mon, Nov 16, 2015 at 2:13 AM, Christopher Robert crobert@surveycto.com wrote:

Okay, since everybody seems bullish about changing the JavaRosa behavior
here, does anybody have ideas on how to do it safely? Making a change like
this seems at high risk for not only breaking forms that rely on behavior
judged improper ex post, but even forms that rely on correct behavior. And
since nobody seems 100% clear on what precisely correct behavior should be
in every circumstance, the risks of messing up seem even higher than is
usual for any JavaRosa intervention.

I'd like to empower users to refer to repeated values using XLSForm choice
filters, and this now seems fully within reach (in fact I have it working
nicely here already). But if that's going to require a major and risky
JavaRosa adventure, then I am far less sure that the benefits outweigh the
costs.

Yaw, do you understand that itemset/predicate evaluation code? Or Mitch,
since it sounds like you added this current current() support, can you
suggest where it might have gone wrong?

Thanks all,

Chris

On Sun, Nov 15, 2015 at 1:57 AM Yaw Anokwa yanokwa@nafundi.com wrote:
Chris,

I think correct behavior is more important than keeping compatibility.
You can only carry technical debt for so long...

We can warn at on the first the form is loaded in release 0, that
folks should fix their forms. Then in release 1, warn every time the
form is loaded. Then release 2, we change the behavior.

Yaw

Need ODK consultants? Nafundi provides form design, server setup,
in-field training, and software development for ODK. Go to
https://nafundi.com to get started.

On Sat, Nov 14, 2015 at 10:36 AM, Christopher Robert crobert@surveycto.com wrote:
Since there are literally thousands of devices in the field running
current
and older versions of Collect -- and will be for a very long time yet --
we
cannot implement a change that will create forms incompatible with all
of
those devices. In other words, if Collect/JR is "fixed" such that
current()
in itemset predicates point to the field rather than one step back from
the
field, then we can neither introduce a pyxform that relies on the fixed
version nor introduce a pyxform that relies on the broken version. Too
many
devices would experience problems in both directions.

So, it seems our choices are: (1) fix the SurveyCTO pyxform to rely on
the
current "broken" JR , maintain that flaw in SurveyCTO's JR branch, and
live
with SurveyCTO's cascading selects breaking compatibility with Enketo;
or
(2) leave things as they are so users are unable to refer to
within-context
repeated values in cascading-select filters. An in-between option would
be
to document the current() approach for people to hand-code the proper
XPaths
into their XLSForms -- but even that is problematic if JR's treatment of
current() is going to change (and/or if Enketo's current() is going to
behave differently).

For what it's worth, "fixed" versions of Collect that change the nature
of
current() in itemset predicates will break all forms for all users who
have
taken the advice to use current() in their cascading-select filters. It
will
be a pretty painful break, I imagine.

If anybody has an idea about how to resolve all of this without breaking
compatibility for thousands of devices and forms, I'm all ears.

Thanks!

Chris

On Fri, Nov 13, 2015 at 6:03 PM Martijn van de Rijdt martijn@enketo.org wrote:
Thanks Mitch,

Indeed relative paths with current() are very useful. Pyxform ${syntax}
translation for choice-lists (as a start to use relative paths with
current() is very welcome indeed Chris!

I hadn't realized current() was part of XForms (just found XSLT
references), but I see this now in XForms 2.0:
http://www.w3.org/TR/xforms-xpath/#The_current.28.29_Function, so
indeed it
is a bug.

I'll implement current() to be the current field then (in Enketo).

On Fri, Nov 13, 2015 at 3:18 PM, Mitch Sundt mitchellsundt@gmail.com wrote:
I think this is a bug.

But I don't know what the XForms standard says about this (frankly, my
eyes glaze over on the spec document, so I have played fast and loose
with
compliance).

As a counter-example, attached is a form that uses current() inside a
calculation and an tag. In both those circumstances,
current()/. is
the field and not the group containing the field.

So I think that the choice list reference is incorrect.
I think current()/. should point to the field, and not the group
containing the field when we try to resolve the choice list.

For the attached XLS file, if you work from the xls file, you need to
hand-edit the xml to change the tag to be what it needs to
be.

Changing ${fieldname} to expand using current()/... syntax would be an
awesome contribution.

Not sure what impact it has on indexed-repeat().

Assuming it is a bug, we should change javarosa to have this reference
the field and not the enclosing group.
Not sure how to manage or coordinate deploying this bug fix.

COMPATIBILITY NOTE:

The ODK fork of javarosa ( https://bitbucket.org/m.sundt/javarosa )
has
enhanced syntax on current()/ w.r.t. the Dimagi / CommCare base repo (
https://bitbucket.org/javarosa/ ), at least as of the time I forked
from
that repo. When this was forked, I added support for relative path
expressions -- in the javarosa Dimagi branch, current()/ did not
support
relative path expressions (e.g., current()/../...). It only supported
absolute path expressions (i.e., current()/myform/group1/fieldname).

I don't know whether that change conforms to the XForms spec or if it
is
divergent (but it is extremely useful and powerful).

On Fri, Nov 13, 2015 at 1:46 PM, Christopher Robert crobert@surveycto.com wrote:
Thanks, Martijn, for posting this.

For a bit of context, this came up because we've patched SurveyCTO's
pyxform branch to replace ${x} references in choice_filter columns
with
expressions relative to current() so that users can refer to repeated
values
(from within the current repeat context) in cascading selects. Our
solution
seems to work with the current version of JR/Collect, but it relies
on this
behavior that Martijn discusses.

If the behavior is judged stable and desirable, then we're happy to
move
forward with a patched pyxform and also share that with the
community. Users
will celebrate if the restriction on easily referencing in-context
repeat
fields were lifted.

Thanks,

Chris

On Fri, Nov 13, 2015 at 4:38 PM Martijn van de Rijdt martijn@enketo.org wrote:
Hi,

I'd like to ask for a clarification about the current() node in an
XPath predicate. It seems JR considers this to be the parent node of
the
current question. (Thanks to Chris for sharing this.)

E.g. in this question below, current() equates to /data/group and
not
to /data/group/options. I would have expected it to be the latter.
....
    <label>label</label>

    <itemset nodeset="instance('crop_list')/root/item[name =
current()/../crop]">
         ....

         ....

    </itemset>
Is this by design? Or is it a bug?

We ran into this by realizing that the seemingly more intuitive
predicate [name = current()/../../crop] is not working.

See this form that illustrates the behaviour nicely. If current() is
used in a calculation (even if it makes no sense to do so) this
extra step
down is not taken, but in a predicate it is. So it seems the
behaviour is
not related to the current() function but to how predicates are
handled in
JR.

Thanks,
Martijn

--
Revolutionizing data collection since 2012.

Enketo | LinkedIn | GitHub | Twitter | Blog

--
You received this message because you are subscribed to the Google
Groups "ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it,
send
an email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google
Groups "ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it,
send
an email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com

--
You received this message because you are subscribed to a topic in the
Google Groups "ODK Developers" group.
To unsubscribe from this topic, visit

https://groups.google.com/d/topic/opendatakit-developers/nN8HTA5pUIM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
opendatakit-developers+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.
--
Revolutionizing data collection since 2012.

Enketo | LinkedIn | GitHub | Twitter | Blog

--
You received this message because you are subscribed to the Google
Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send
an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google
Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send
an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Mitch_S · November 20, 2015, 5:27pm

And you see this in constraint expressions where you write:

. > 6

I.e., current()/. should refer to the field, and not the group containing
the field, as it currently does when evaluating expressions in the itemset
nodeset.

···

On Fri, Nov 20, 2015 at 9:26 AM, Mitch Sundt wrote:

The issue is that there is a discrepancy in the meaning of '.' across
the different contexts of: calculate, relevant, , and these itemset
nodeset expressions.

In other usages, you need to reference this other field with
current()/../filterfield ; but in the nodeset expression, you would
reference it with current()/./filterfield

I.e., the notion of '.' is different when used within a nodeset expression
and when used within a constraint expression or an field.

See the attached NBiggestOfSet form. For the label, it has:
    <select1 ref="/NBiggestOfSet/education/edu_level">
      <label>What is <output value="
current()/../referred_attendee_name"/>'s level of education?
...

For a constraint, it has:

These each use the current()/../ to reference the group (
/NBiggesetOfSet/education ).

But, within the nodeset definition (if this form used one), you would need
to use current()/./referred_attendee_name to reference a field in that
group.

On Fri, Nov 20, 2015 at 8:22 AM, meletis@surveycto.com wrote:
Hi Mitch,

I think I'm missing something but I think that nothing is broken and that
the only issue is that the expression current()/../filterfield in your
example above should be just changed to current()/filterfield. If you make
that change, everything should work because it will be resolved to:

/data/group1/filterfield

Why should a "../" be present there? We have used current()/somefield
successfully in one of our test forms and it works fine. And I think it
would also work great in your example. Wouldn't it? Or am I totally out of
context?

Meletis

On Friday, November 20, 2015 at 5:35:16 PM UTC+2, Mitch wrote:
Hi Meletis,

That's not the issue --

The issue is that if you use a filter condition in the nodeset
specification of a field "myfield", within that nodeset specification
"current()/.." refers to the parent of the group enclosing the "myfield"
field. It does not refer to the group enclosing the "myfield" field.

So if you have
a 4 fish b 14 fish ...
and if you have:

This will currently be broken. Because current()/../filterfield,
when evaluated within the itemset nodeset specification, is resolved to:

/data/filterfield

instead of

/data/group1/filterfield

On Fri, Nov 20, 2015 at 1:58 AM, mel...@surveycto.com wrote:
Well, I think there is a fundamental issue here regarding current()
syntax. Please, let me remind you how JR works with "current()":

The expression "current()" looks like a function but it is not
treated like one; it is not handled by the XPathFuncExpr class, so, if you
try to use it alone you will get an error that the "function" is not
supported. In other words, you cannot use it alone in an expression in
order to refer to the "current" field.

When an expression includes "current()", then it ALWAYS needs to be
used in an XPath, actually, the expression needs to BE an XPath expression,
so that it can be handled with the XPathPathExpr class. For that reason the
expression NEEDS to contain at least one "/".

Taking 1 and 2 into consideration, the ONLY way to refer to the
"current" field (named "somefield") is to use "current()/." or
"current()/somefield". So, I looks like that the original implementation
was "okay" in the sense that the "current()" should only be used in XPaths.

If we wanted to have "current()" refer to the current field, I believe
we should introduce a new function handler in XPathFuncExpr class. Please
let me know if this would work:

A. Whenever the "current()" expression is used inside an XPath, then
the current code would be used as it is used right now (maintaining
backwards compatibility), so that it will still be referring to the
enclosing group, not the field itself.
B. Whenever the "current()" expression is used inside a non-XPath, then
the new code would be used (in XPathFuncExpr) and that would be evaluated
in a way that the current field would be returned/referenced, NOT the
enclosing group.

That way, the following code could work, because it wouldn't throw the
"unrecognized function" error:
label .... ....
What do you think about that approach?

Meletis

On Friday, November 13, 2015 at 11:38:15 PM UTC+2, Martijn van de Rijdt wrote:
Hi,

I'd like to ask for a clarification about the current() node in an
XPath predicate. It seems JR considers this to be the parent node
of the current question. (Thanks to Chris for sharing this.)

E.g. in this question below, current() equates to /data/group and not
to /data/group/options. I would have expected it to be the latter.
....
    <label>label</label>

    <itemset nodeset="instance('crop_list')/root/item[name =
current()*/../*crop]">
         ....

         ....

    </itemset>
Is this by design? Or is it a bug?

We ran into this by realizing that the seemingly more intuitive
predicate [name = current()*/../../*crop] is not working.

See this form
https://docs.google.com/spreadsheets/d/1A74yEHRxQF1zbIcQSrwvZydggUU7m5T3ZAnlR6_TLA4/edit#gid=0
that illustrates the behaviour nicely. If current() is used in a
calculation (even if it makes no sense to do so) this extra step down is
not taken, but in a predicate it is. So it seems the behaviour is not
related to the current() function but to how predicates are handled in JR.

Thanks,
Martijn

--
--
Mitch Sundt
Software Engineer
University of Washington
mitche...@gmail.com
--
You received this message because you are subscribed to the Google Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com

--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com

Mitch_S · November 16, 2015, 8:15pm

Note that static selection <item>s that are inline in the XML are
maintained in a different data structure than are the dynamic <itemset>s
that reference named instance('...')... sections.

e.g.,

        <select1 ref="/NBiggestOfSet/attendee/gender">
          <label>What is your gender?</label>
          <item>

<label ref="jr:itext('/NBiggestOfSet/select_example/male:label')/>
            <value>male</value>
          </item>
          <item>

<label> ref="jr:itext('/NBiggestOfSet/select_example/female:label'</label>
            <value>female</value>
          </item>
        </select1>

vs.

<select1 ref="/data/PeopleQuestion/perName">
 <label ref="jr:itext('PeopleName')" />
 <itemset nodeset="instance('nam')/root/item[filtre =
position(current()/.)]">
 <value ref="name"/>
 <label ref="jr:itext(itextId)"/>
</itemset>
</select1>

Are handled and parsed differently.

There are several different things to test:

(1) the filter condition ( <itemset nodeset="..." ) on the dynamic itemsets
has the correct current()/. path. (known issue).

(2a) within an <itemset>, the <label ref="..."> has the correct current()/.
path. I believe these are abitrary xpath expressions relative to the
nodeset path. We just happen to use a simple leaf node expression and we
hack the jr:itext() using special parsing. We should be able to hand-code
something crazy like
ref="value/../alt[./name=current()/../otherChoice]/value"

(2b) within an <item> the only allowed label ref= is for a jr:itext() path.
That value may contain an tag, so the evaluation concern still
applies, but only w.r.t. (4) below. I.e., nothing to test here; handled
in testing (4).

(3a) within an <itemset>, the <value ref="..."> has the correct current()/.
path. I believe these are abitrary xpath expressions relative to the
nodeset path. We just happen to use a simple leaf node expression. See (2a)
for example of craziness.

(3b) within an <item> the <value> entry does not take a ref="..." attribute
and must be a string value. I.e., nothing to test here.

(4) <output ref="..."> tags within a <label> (either within an <item> or an
<itemset> entry, and either within a jr:itext or inlined) have the correct
current()/. path. I believe these are abitrary xpath expressions relative
to the nodeset path. We just happen to use a simple node reference.

(5) jr:choice-name() evaluates the filter condition, (1), above, correctly
for dynamic itemsets. This might have a bug with resolving <output> tags
-- not sure I've ever seen a form using them and using this function.

···

----------------- The function that does the parsing is XFormParser.parseItemset

https://bitbucket.org/m.sundt/javarosa/src/bf17fb749b74e53915f086ca3827c3c6fe73fd07/core/src/org/javarosa/xform/parse/XFormParser.java?at=default&fileviewer=file-view-default#XFormParser.java-1206

This may use the incorrect contextRef (e.g., line 1226) ? And maybe that is
the root of the problem?

The function that does the parsing is XFormParser.parseItem

https://bitbucket.org/m.sundt/javarosa/src/bf17fb749b74e53915f086ca3827c3c6fe73fd07/core/src/org/javarosa/xform/parse/XFormParser.java?at=default&fileviewer=file-view-default#XFormParser.java-1118

The function that does the evaluation is
FormDef.populateDynamicChoices

https://bitbucket.org/m.sundt/javarosa/src/bf17fb749b74e53915f086ca3827c3c6fe73fd07/core/src/org/javarosa/core/model/FormDef.java?at=default&fileviewer=file-view-default#FormDef.java-919

On Sun, Nov 15, 2015 at 6:13 PM, Yaw Anokwa yanokwa@nafundi.com wrote:

Chris,

It's been forever since I looked at the itemset code, so I'm not going
to be very useful here.

Yaw

Need ODK consultants? Nafundi provides form design, server setup,
in-field training, and software development for ODK. Go to
https://nafundi.com to get started.

On Mon, Nov 16, 2015 at 2:13 AM, Christopher Robert crobert@surveycto.com wrote:
Okay, since everybody seems bullish about changing the JavaRosa behavior
here, does anybody have ideas on how to do it safely? Making a change
like
this seems at high risk for not only breaking forms that rely on behavior
judged improper ex post, but even forms that rely on correct behavior.
And
since nobody seems 100% clear on what precisely correct behavior should
be
in every circumstance, the risks of messing up seem even higher than is
usual for any JavaRosa intervention.

I'd like to empower users to refer to repeated values using XLSForm
choice
filters, and this now seems fully within reach (in fact I have it working
nicely here already). But if that's going to require a major and risky
JavaRosa adventure, then I am far less sure that the benefits outweigh
the
costs.

Yaw, do you understand that itemset/predicate evaluation code? Or Mitch,
since it sounds like you added this current current() support, can you
suggest where it might have gone wrong?

Thanks all,

Chris

On Sun, Nov 15, 2015 at 1:57 AM Yaw Anokwa yanokwa@nafundi.com wrote:

Chris,

I think correct behavior is more important than keeping compatibility.
You can only carry technical debt for so long...

We can warn at on the first the form is loaded in release 0, that
folks should fix their forms. Then in release 1, warn every time the
form is loaded. Then release 2, we change the behavior.

Yaw

Need ODK consultants? Nafundi provides form design, server setup,
in-field training, and software development for ODK. Go to
https://nafundi.com to get started.

On Sat, Nov 14, 2015 at 10:36 AM, Christopher Robert crobert@surveycto.com wrote:

Since there are literally thousands of devices in the field running
current
and older versions of Collect -- and will be for a very long time yet
--

we
cannot implement a change that will create forms incompatible with all
of
those devices. In other words, if Collect/JR is "fixed" such that
current()
in itemset predicates point to the field rather than one step back
from

the
field, then we can neither introduce a pyxform that relies on the
fixed

version nor introduce a pyxform that relies on the broken version. Too
many
devices would experience problems in both directions.

So, it seems our choices are: (1) fix the SurveyCTO pyxform to rely on
the
current "broken" JR , maintain that flaw in SurveyCTO's JR branch, and
live
with SurveyCTO's cascading selects breaking compatibility with Enketo;
or
(2) leave things as they are so users are unable to refer to
within-context
repeated values in cascading-select filters. An in-between option
would

be
to document the current() approach for people to hand-code the proper
XPaths
into their XLSForms -- but even that is problematic if JR's treatment
of

current() is going to change (and/or if Enketo's current() is going to
behave differently).

For what it's worth, "fixed" versions of Collect that change the
nature

of
current() in itemset predicates will break all forms for all users who
have
taken the advice to use current() in their cascading-select filters.
It

will
be a pretty painful break, I imagine.

If anybody has an idea about how to resolve all of this without
breaking

compatibility for thousands of devices and forms, I'm all ears.

Thanks!

Chris

On Fri, Nov 13, 2015 at 6:03 PM Martijn van de Rijdt martijn@enketo.org wrote:

Thanks Mitch,

Indeed relative paths with current() are very useful. Pyxform
${syntax}

translation for choice-lists (as a start to use relative paths
with

current() is very welcome indeed Chris!

I hadn't realized current() was part of XForms (just found XSLT
references), but I see this now in XForms 2.0:
http://www.w3.org/TR/xforms-xpath/#The_current.28.29_Function, so
indeed it
is a bug.

I'll implement current() to be the current field then (in Enketo).

On Fri, Nov 13, 2015 at 3:18 PM, Mitch Sundt < mitchellsundt@gmail.com> wrote:

I think this is a bug.

But I don't know what the XForms standard says about this (frankly,
my

eyes glaze over on the spec document, so I have played fast and
loose

with
compliance).

As a counter-example, attached is a form that uses current() inside
a

calculation and an tag. In both those circumstances,
current()/. is
the field and not the group containing the field.

So I think that the choice list reference is incorrect.
I think current()/. should point to the field, and not the group
containing the field when we try to resolve the choice list.

For the attached XLS file, if you work from the xls file, you need
to

hand-edit the xml to change the tag to be what it needs to
be.

Changing ${fieldname} to expand using current()/... syntax would be
an

awesome contribution.

Not sure what impact it has on indexed-repeat().

Assuming it is a bug, we should change javarosa to have this
reference

the field and not the enclosing group.
Not sure how to manage or coordinate deploying this bug fix.

COMPATIBILITY NOTE:

The ODK fork of javarosa ( https://bitbucket.org/m.sundt/javarosa )
has
enhanced syntax on current()/ w.r.t. the Dimagi / CommCare base
repo (

https://bitbucket.org/javarosa/ ), at least as of the time I forked
from
that repo. When this was forked, I added support for relative path
expressions -- in the javarosa Dimagi branch, current()/ did not
support
relative path expressions (e.g., current()/../...). It only
supported

absolute path expressions (i.e.,
current()/myform/group1/fieldname).

I don't know whether that change conforms to the XForms spec or if
it

is
divergent (but it is extremely useful and powerful).

On Fri, Nov 13, 2015 at 1:46 PM, Christopher Robert crobert@surveycto.com wrote:

Thanks, Martijn, for posting this.

For a bit of context, this came up because we've patched
SurveyCTO's

pyxform branch to replace ${x} references in choice_filter columns
with
expressions relative to current() so that users can refer to
repeated

values
(from within the current repeat context) in cascading selects. Our
solution
seems to work with the current version of JR/Collect, but it relies
on this
behavior that Martijn discusses.

If the behavior is judged stable and desirable, then we're happy to
move
forward with a patched pyxform and also share that with the
community. Users
will celebrate if the restriction on easily referencing in-context
repeat
fields were lifted.

Thanks,

Chris

On Fri, Nov 13, 2015 at 4:38 PM Martijn van de Rijdt martijn@enketo.org wrote:

Hi,

I'd like to ask for a clarification about the current() node in an
XPath predicate. It seems JR considers this to be the parent node
of
the
current question. (Thanks to Chris for sharing this.)

E.g. in this question below, current() equates to /data/group and
not
to /data/group/options. I would have expected it to be the latter.
....
    <label>label</label>

    <itemset nodeset="instance('crop_list')/root/item[name =
current()/../crop]">
         ....

         ....

    </itemset>
Is this by design? Or is it a bug?

We ran into this by realizing that the seemingly more intuitive
predicate [name = current()/../../crop] is not working.

See this form that illustrates the behaviour nicely. If current()
is
used in a calculation (even if it makes no sense to do so) this
extra step
down is not taken, but in a predicate it is. So it seems the
behaviour is
not related to the current() function but to how predicates are
handled in
JR.

Thanks,
Martijn

--
Revolutionizing data collection since 2012.

Enketo | LinkedIn | GitHub | Twitter |
Blog

--
You received this message because you are subscribed to the Google
Groups "ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it,
send
an email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google
Groups "ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it,
send
an email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com

--
You received this message because you are subscribed to a topic in
the

Google Groups "ODK Developers" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/opendatakit-developers/nN8HTA5pUIM/unsubscribe
.

To unsubscribe from this group and all its topics, send an email to
opendatakit-developers+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
Revolutionizing data collection since 2012.

Enketo | LinkedIn | GitHub | Twitter | Blog

--
You received this message because you are subscribed to the Google
Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it,
send

an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google
Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send
an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google
Groups

"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send
an

email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com

Mitch_S · November 20, 2015, 5:29pm

The form was attached in one of my earlier replies.

···

On Fri, Nov 20, 2015 at 9:27 AM, Mitch Sundt wrote:

And you see this in constraint expressions where you write:

. > 6

I.e., current()/. should refer to the field, and not the group containing
the field, as it currently does when evaluating expressions in the itemset
nodeset.

On Fri, Nov 20, 2015 at 9:26 AM, Mitch Sundt mitchellsundt@gmail.com wrote:
The issue is that there is a discrepancy in the meaning of '.' across
the different contexts of: calculate, relevant, , and these itemset
nodeset expressions.

In other usages, you need to reference this other field with
current()/../filterfield ; but in the nodeset expression, you would
reference it with current()/./filterfield

I.e., the notion of '.' is different when used within a nodeset
expression and when used within a constraint expression or an
field.

See the attached NBiggestOfSet form. For the label, it has:
    <select1 ref="/NBiggestOfSet/education/edu_level">
      <label>What is <output value="
current()/../referred_attendee_name"/>'s level of education?
...

For a constraint, it has:

These each use the current()/../ to reference the group (
/NBiggesetOfSet/education ).

But, within the nodeset definition (if this form used one), you would
need to use current()/./referred_attendee_name to reference a field
in that group.

On Fri, Nov 20, 2015 at 8:22 AM, meletis@surveycto.com wrote:
Hi Mitch,

I think I'm missing something but I think that nothing is broken and
that the only issue is that the expression current()/../filterfield in your
example above should be just changed to current()/filterfield. If you make
that change, everything should work because it will be resolved to:

/data/group1/filterfield

Why should a "../" be present there? We have used current()/somefield
successfully in one of our test forms and it works fine. And I think it
would also work great in your example. Wouldn't it? Or am I totally out of
context?

Meletis

On Friday, November 20, 2015 at 5:35:16 PM UTC+2, Mitch wrote:
Hi Meletis,

That's not the issue --

The issue is that if you use a filter condition in the
nodeset specification of a field "myfield", within that nodeset
specification "current()/.." refers to the parent of the group enclosing
the "myfield" field. It does not refer to the group enclosing the
"myfield" field.

So if you have
a 4 fish b 14 fish ...
and if you have:

This will currently be broken. Because current()/../filterfield,
when evaluated within the itemset nodeset specification, is resolved to:

/data/filterfield

instead of

/data/group1/filterfield

On Fri, Nov 20, 2015 at 1:58 AM, mel...@surveycto.com wrote:
Well, I think there is a fundamental issue here regarding current()
syntax. Please, let me remind you how JR works with "current()":

The expression "current()" looks like a function but it is not
treated like one; it is not handled by the XPathFuncExpr class, so, if you
try to use it alone you will get an error that the "function" is not
supported. In other words, you cannot use it alone in an expression in
order to refer to the "current" field.

When an expression includes "current()", then it ALWAYS needs to be
used in an XPath, actually, the expression needs to BE an XPath expression,
so that it can be handled with the XPathPathExpr class. For that reason the
expression NEEDS to contain at least one "/".

Taking 1 and 2 into consideration, the ONLY way to refer to the
"current" field (named "somefield") is to use "current()/." or
"current()/somefield". So, I looks like that the original implementation
was "okay" in the sense that the "current()" should only be used in XPaths.

If we wanted to have "current()" refer to the current field, I believe
we should introduce a new function handler in XPathFuncExpr class. Please
let me know if this would work:

A. Whenever the "current()" expression is used inside an XPath, then
the current code would be used as it is used right now (maintaining
backwards compatibility), so that it will still be referring to the
enclosing group, not the field itself.
B. Whenever the "current()" expression is used inside a non-XPath,
then the new code would be used (in XPathFuncExpr) and that would be
evaluated in a way that the current field would be returned/referenced, NOT
the enclosing group.

That way, the following code could work, because it wouldn't throw the
"unrecognized function" error:
label .... ....
What do you think about that approach?

Meletis

On Friday, November 13, 2015 at 11:38:15 PM UTC+2, Martijn van de Rijdt wrote:
Hi,

I'd like to ask for a clarification about the current() node in an
XPath predicate. It seems JR considers this to be the parent node
of the current question. (Thanks to Chris for sharing this.)

E.g. in this question below, current() equates to /data/group and not
to /data/group/options. I would have expected it to be the latter.
....
    <label>label</label>

    <itemset nodeset="instance('crop_list')/root/item[name =
current()*/../*crop]">
         ....

         ....

    </itemset>
Is this by design? Or is it a bug?

We ran into this by realizing that the seemingly more intuitive
predicate [name = current()*/../../*crop] is not working.

See this form
https://docs.google.com/spreadsheets/d/1A74yEHRxQF1zbIcQSrwvZydggUU7m5T3ZAnlR6_TLA4/edit#gid=0
that illustrates the behaviour nicely. If current() is used in a
calculation (even if it makes no sense to do so) this extra step down is
not taken, but in a predicate it is. So it seems the behaviour is not
related to the current() function but to how predicates are handled in JR.

Thanks,
Martijn

--
--
Mitch Sundt
Software Engineer
University of Washington
mitche...@gmail.com
--
You received this message because you are subscribed to the Google
Groups "ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com
--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com

--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com

crobert · November 16, 2015, 10:57pm

Thanks, Mitch. This is super helpful. Maybe Meletis can figure it out from
here. We'll give it a shot!

Thanks again,

Chris

···

On Mon, Nov 16, 2015 at 3:15 PM Mitch Sundt wrote:

Note that static selection s that are inline in the XML are
maintained in a different data structure than are the dynamic s
that reference named instance('...')... sections.

e.g.,

What is your gender?

<label ref="jr:itext('/NBiggestOfSet/select_example/male:label')/>
male

ref="jr:itext('/NBiggestOfSet/select_example/female:label'
female

vs.

Are handled and parsed differently.

There are several different things to test:

(1) the filter condition ( <itemset nodeset="..." ) on the dynamic
itemsets has the correct current()/. path. (known issue).

(2a) within an , the has the correct
current()/. path. I believe these are abitrary xpath expressions relative
to the nodeset path. We just happen to use a simple leaf node expression
and we hack the jr:itext() using special parsing. We should be able to
hand-code something crazy like
ref="value/../alt[./name=current()/../otherChoice]/value"

(2b) within an the only allowed label ref= is for a jr:itext()
path. That value may contain an tag, so the evaluation concern
still applies, but only w.r.t. (4) below. I.e., nothing to test here;
handled in testing (4).

(3a) within an , the has the correct
current()/. path. I believe these are abitrary xpath expressions relative
to the nodeset path. We just happen to use a simple leaf node expression.
See (2a) for example of craziness.

(3b) within an the entry does not take a ref="..."
attribute and must be a string value. I.e., nothing to test here.

(4) tags within a (either within an or
an entry, and either within a jr:itext or inlined) have the
correct current()/. path. I believe these are abitrary xpath expressions
relative to the nodeset path. We just happen to use a simple node reference.

(5) jr:choice-name() evaluates the filter condition, (1), above, correctly
for dynamic itemsets. This might have a bug with resolving tags
-- not sure I've ever seen a form using them and using this function.

The function that does the parsing is XFormParser.parseItemset

https://bitbucket.org/m.sundt/javarosa/src/bf17fb749b74e53915f086ca3827c3c6fe73fd07/core/src/org/javarosa/xform/parse/XFormParser.java?at=default&fileviewer=file-view-default#XFormParser.java-1206

This may use the incorrect contextRef (e.g., line 1226) ? And maybe that
is the root of the problem?

The function that does the parsing is XFormParser.parseItem

https://bitbucket.org/m.sundt/javarosa/src/bf17fb749b74e53915f086ca3827c3c6fe73fd07/core/src/org/javarosa/xform/parse/XFormParser.java?at=default&fileviewer=file-view-default#XFormParser.java-1118

The function that does the evaluation is
FormDef.populateDynamicChoices

https://bitbucket.org/m.sundt/javarosa/src/bf17fb749b74e53915f086ca3827c3c6fe73fd07/core/src/org/javarosa/core/model/FormDef.java?at=default&fileviewer=file-view-default#FormDef.java-919

On Sun, Nov 15, 2015 at 6:13 PM, Yaw Anokwa yanokwa@nafundi.com wrote:
Chris,

It's been forever since I looked at the itemset code, so I'm not going
to be very useful here.

Yaw

Need ODK consultants? Nafundi provides form design, server setup,
in-field training, and software development for ODK. Go to
https://nafundi.com to get started.

On Mon, Nov 16, 2015 at 2:13 AM, Christopher Robert crobert@surveycto.com wrote:
Okay, since everybody seems bullish about changing the JavaRosa behavior
here, does anybody have ideas on how to do it safely? Making a change
like
this seems at high risk for not only breaking forms that rely on
behavior
judged improper ex post, but even forms that rely on correct behavior.
And
since nobody seems 100% clear on what precisely correct behavior should
be
in every circumstance, the risks of messing up seem even higher than is
usual for any JavaRosa intervention.

I'd like to empower users to refer to repeated values using XLSForm
choice
filters, and this now seems fully within reach (in fact I have it
working
nicely here already). But if that's going to require a major and risky
JavaRosa adventure, then I am far less sure that the benefits outweigh
the
costs.

Yaw, do you understand that itemset/predicate evaluation code? Or Mitch,
since it sounds like you added this current current() support, can you
suggest where it might have gone wrong?

Thanks all,

Chris

On Sun, Nov 15, 2015 at 1:57 AM Yaw Anokwa yanokwa@nafundi.com wrote:

Chris,

I think correct behavior is more important than keeping compatibility.
You can only carry technical debt for so long...

We can warn at on the first the form is loaded in release 0, that
folks should fix their forms. Then in release 1, warn every time the
form is loaded. Then release 2, we change the behavior.

Yaw

Need ODK consultants? Nafundi provides form design, server setup,
in-field training, and software development for ODK. Go to
https://nafundi.com to get started.

On Sat, Nov 14, 2015 at 10:36 AM, Christopher Robert crobert@surveycto.com wrote:

Since there are literally thousands of devices in the field running
current
and older versions of Collect -- and will be for a very long time
yet --

we
cannot implement a change that will create forms incompatible with
all

of
those devices. In other words, if Collect/JR is "fixed" such that
current()
in itemset predicates point to the field rather than one step back
from

the
field, then we can neither introduce a pyxform that relies on the
fixed

version nor introduce a pyxform that relies on the broken version.
Too

many
devices would experience problems in both directions.

So, it seems our choices are: (1) fix the SurveyCTO pyxform to rely
on

the
current "broken" JR , maintain that flaw in SurveyCTO's JR branch,
and

live
with SurveyCTO's cascading selects breaking compatibility with
Enketo;

or
(2) leave things as they are so users are unable to refer to
within-context
repeated values in cascading-select filters. An in-between option
would

be
to document the current() approach for people to hand-code the proper
XPaths
into their XLSForms -- but even that is problematic if JR's
treatment of

current() is going to change (and/or if Enketo's current() is going
to

behave differently).

For what it's worth, "fixed" versions of Collect that change the
nature

of
current() in itemset predicates will break all forms for all users
who

have
taken the advice to use current() in their cascading-select filters.
It

will
be a pretty painful break, I imagine.

If anybody has an idea about how to resolve all of this without
breaking

compatibility for thousands of devices and forms, I'm all ears.

Thanks!

Chris

On Fri, Nov 13, 2015 at 6:03 PM Martijn van de Rijdt martijn@enketo.org wrote:

Thanks Mitch,

Indeed relative paths with current() are very useful. Pyxform
${syntax}

translation for choice-lists (as a start to use relative paths
with

current() is very welcome indeed Chris!

I hadn't realized current() was part of XForms (just found XSLT
references), but I see this now in XForms 2.0:
http://www.w3.org/TR/xforms-xpath/#The_current.28.29_Function, so
indeed it
is a bug.

I'll implement current() to be the current field then (in Enketo).

On Fri, Nov 13, 2015 at 3:18 PM, Mitch Sundt < mitchellsundt@gmail.com> wrote:

I think this is a bug.

But I don't know what the XForms standard says about this
(frankly, my

eyes glaze over on the spec document, so I have played fast and
loose

with
compliance).

As a counter-example, attached is a form that uses current()
inside a

calculation and an tag. In both those circumstances,
current()/. is
the field and not the group containing the field.

So I think that the choice list reference is incorrect.
I think current()/. should point to the field, and not the
group

containing the field when we try to resolve the choice list.

For the attached XLS file, if you work from the xls file, you need
to

hand-edit the xml to change the tag to be what it needs to
be.

Changing ${fieldname} to expand using current()/... syntax would
be an

awesome contribution.

Not sure what impact it has on indexed-repeat().

Assuming it is a bug, we should change javarosa to have this
reference

the field and not the enclosing group.
Not sure how to manage or coordinate deploying this bug fix.

COMPATIBILITY NOTE:

The ODK fork of javarosa ( https://bitbucket.org/m.sundt/javarosa
)

has
enhanced syntax on current()/ w.r.t. the Dimagi / CommCare base
repo (

https://bitbucket.org/javarosa/ ), at least as of the time I
forked

from
that repo. When this was forked, I added support for relative path
expressions -- in the javarosa Dimagi branch, current()/ did not
support
relative path expressions (e.g., current()/../...). It only
supported

absolute path expressions (i.e.,
current()/myform/group1/fieldname).

I don't know whether that change conforms to the XForms spec or if
it

is
divergent (but it is extremely useful and powerful).

On Fri, Nov 13, 2015 at 1:46 PM, Christopher Robert crobert@surveycto.com wrote:

Thanks, Martijn, for posting this.

For a bit of context, this came up because we've patched
SurveyCTO's

pyxform branch to replace ${x} references in choice_filter columns
with
expressions relative to current() so that users can refer to
repeated

values
(from within the current repeat context) in cascading selects. Our
solution
seems to work with the current version of JR/Collect, but it
relies

on this
behavior that Martijn discusses.

If the behavior is judged stable and desirable, then we're happy
to

move
forward with a patched pyxform and also share that with the
community. Users
will celebrate if the restriction on easily referencing in-context
repeat
fields were lifted.

Thanks,

Chris

On Fri, Nov 13, 2015 at 4:38 PM Martijn van de Rijdt martijn@enketo.org wrote:

Hi,

I'd like to ask for a clarification about the current() node in
an

XPath predicate. It seems JR considers this to be the parent
node of

the
current question. (Thanks to Chris for sharing this.)

E.g. in this question below, current() equates to /data/group and
not
to /data/group/options. I would have expected it to be the
latter.
....
    <label>label</label>

    <itemset nodeset="instance('crop_list')/root/item[name =
current()/../crop]">
         ....

         ....

    </itemset>
Is this by design? Or is it a bug?

We ran into this by realizing that the seemingly more intuitive
predicate [name = current()/../../crop] is not working.

See this form that illustrates the behaviour nicely. If
current() is
used in a calculation (even if it makes no sense to do so) this
extra step
down is not taken, but in a predicate it is. So it seems the
behaviour is
not related to the current() function but to how predicates are
handled in
JR.

Thanks,
Martijn

--
Revolutionizing data collection since 2012.

Enketo | LinkedIn | GitHub | Twitter |
Blog

--
You received this message because you are subscribed to the
Google

Groups "ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it,
send
an email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google
Groups "ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it,
send
an email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com

--
You received this message because you are subscribed to a topic in
the

Google Groups "ODK Developers" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/opendatakit-developers/nN8HTA5pUIM/unsubscribe
.

To unsubscribe from this group and all its topics, send an email to
opendatakit-developers+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
Revolutionizing data collection since 2012.

Enketo | LinkedIn | GitHub | Twitter | Blog

--
You received this message because you are subscribed to the Google
Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it,
send

an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google
Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it,
send

an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google
Groups

"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send
an

email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google
Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send
an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com

--
You received this message because you are subscribed to the Google Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Meletis · November 20, 2015, 6:36pm

Hi Mitch,

Thank you for all the details, I guess I was missing some of the context of
the original issue.

We will give it a shot to see if we can come up with a few ideas how to fix
the evaluation content of the itemset nodeset. I just hope it will not be
like last year with the "form processing logic" in JR, otherwise I believe
that every Christmas will be a JR Christmas.

Meletis

···

On Friday, November 20, 2015 at 7:29:14 PM UTC+2, Mitch wrote: > > The form was attached in one of my earlier replies. > > On Fri, Nov 20, 2015 at 9:27 AM, Mitch Sundt <mitche...@gmail.com > wrote: > >> And you see this in constraint expressions where you write: >> >> . > 6 >> >> I.e., current()/. should refer to the field, and not the group containing >> the field, as it currently does when evaluating expressions in the itemset >> nodeset. >> >> On Fri, Nov 20, 2015 at 9:26 AM, Mitch Sundt <mitche...@gmail.com > wrote: >> >>> The issue is that there is a *discrepancy* in the meaning of '.' across >>> the different contexts of: calculate, relevant, , and these itemset >>> nodeset expressions. >>> >>> In other usages, you need to reference this other field with >>> current()/../filterfield ; but in the nodeset expression, you would >>> reference it with current()/./filterfield >>> >>> I.e., the notion of '.' is different when used within a nodeset >>> expression and when used within a constraint expression or an >>> field. >>> >>> See the attached NBiggestOfSet form. For the label, it has: >>> >>> >>> What is 's level of education? >>> ... >>> >>> For a constraint, it has: >>> >> nodeset="/NBiggestOfSet/education/referred_attendee_name" readonly="true()" >>> type="string"/> >>> >>> >>> These each use the *current()/../* to reference the group ( >>> /NBiggesetOfSet/education ). >>> >>> But, within the nodeset definition (if this form used one), you would >>> need to use *current()/./referred_attendee_name* to reference a field >>> in that group. >>> >>> >>> >>> >>> On Fri, Nov 20, 2015 at 8:22 AM, <mel...@surveycto.com > wrote: >>> >>>> Hi Mitch, >>>> >>>> I think I'm missing something but I think that nothing is broken and >>>> that the only issue is that the expression current()/../filterfield in your >>>> example above should be just changed to current()/filterfield. If you make >>>> that change, everything should work because it will be resolved to: >>>> >>>> /data/group1/filterfield >>>> >>>> Why should a "../" be present there? We have used current()/somefield >>>> successfully in one of our test forms and it works fine. And I think it >>>> would also work great in your example. Wouldn't it? Or am I totally out of >>>> context? >>>> >>>> Meletis >>>> >>>> >>>> On Friday, November 20, 2015 at 5:35:16 PM UTC+2, Mitch wrote: >>>> >>>>> Hi Meletis, >>>>> >>>>> That's not the issue -- >>>>> >>>>> The issue is that if you use a filter condition in the >>>>> nodeset specification of a field "myfield", within that nodeset >>>>> specification "current()/.." refers to the parent of the group enclosing >>>>> the "myfield" field. It does not refer to the group enclosing the >>>>> "myfield" field. >>>>> >>>>> So if you have >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> a >>>>> 4 >>>>> fish >>>>> >>>>> >>>>> b >>>>> 14 >>>>> fish >>>>> >>>>> ... >>>>> >>>>> >>>>> >>>>> and if you have: >>>>> >>>>> >>>>> >>>> nodeset="instance('food')/root/fooditem[filtercriteria=current()/../filterfield]"> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> This will currently be broken. Because current()/../filterfield, >>>>> when evaluated within the itemset nodeset specification, is resolved >>>>> to: >>>>> >>>>> /data/filterfield >>>>> >>>>> instead of >>>>> >>>>> /data/group1/filterfield >>>>> >>>>> >>>>> On Fri, Nov 20, 2015 at 1:58 AM, wrote: >>>>> >>>>>> Well, I think there is a fundamental issue here regarding current() >>>>>> syntax. Please, let me remind you how JR works with "current()": >>>>>> >>>>>> 1. The expression "current()" looks like a function but it is not >>>>>> treated like one; it is not handled by the XPathFuncExpr class, so, if you >>>>>> try to use it alone you will get an error that the "function" is not >>>>>> supported. In other words, you cannot use it alone in an expression in >>>>>> order to refer to the "current" field. >>>>>> >>>>>> 2. When an expression includes "current()", then it ALWAYS needs to >>>>>> be used in an XPath, actually, the expression needs to BE an XPath >>>>>> expression, so that it can be handled with the XPathPathExpr class. For >>>>>> that reason the expression NEEDS to contain at least one "/". >>>>>> >>>>>> 3. Taking 1 and 2 into consideration, the ONLY way to refer to the >>>>>> "current" field (named "somefield") is to use "current()/." or >>>>>> "current()/somefield". So, I looks like that the original implementation >>>>>> was "okay" in the sense that the "current()" should only be used in XPaths. >>>>>> >>>>>> If we wanted to have "current()" refer to the current field, I >>>>>> believe we should introduce a new function handler in XPathFuncExpr class. >>>>>> Please let me know if this would work: >>>>>> >>>>>> A. Whenever the "current()" expression is used inside an XPath, then >>>>>> the current code would be used as it is used right now (maintaining >>>>>> backwards compatibility), so that it will still be referring to the >>>>>> enclosing group, not the field itself. >>>>>> B. Whenever the "current()" expression is used inside a non-XPath, >>>>>> then the new code would be used (in XPathFuncExpr) and that would be >>>>>> evaluated in a way that the current field would be returned/referenced, NOT >>>>>> the enclosing group. >>>>>> >>>>>> That way, the following code could work, because it wouldn't throw >>>>>> the "unrecognized function" error: >>>>>> >>>>>> >>>>>> label >>>>>> >>>>>> .... >>>>>> .... >>>>>> >>>>>> >>>>>> >>>>>> What do you think about that approach? >>>>>> >>>>>> Meletis >>>>>> >>>>>> >>>>>> >>>>>> On Friday, November 13, 2015 at 11:38:15 PM UTC+2, Martijn van de Rijdt wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I'd like to ask for a clarification about the current() node in an >>>>>>> XPath predicate. It seems JR considers this to be the *parent* node >>>>>>> of the current question. (Thanks to Chris for sharing this.) >>>>>>> >>>>>>> E.g. in this question below, current() equates to /data/group and >>>>>>> not to /data/group/options. I would have expected it to be the latter. >>>>>>> >>>>>>> >>>>>>> >>>>>>> .... >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> label >>>>>>> >>>>>>> >>>>>>> >>>>>>> .... >>>>>>> >>>>>>> .... >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Is this by design? Or is it a bug? >>>>>>> >>>>>>> >>>>>>> We ran into this by realizing that the seemingly more intuitive >>>>>>> predicate [name = current()*/../../*crop] is not working. >>>>>>> >>>>>>> >>>>>>> See this form >>>>>>> >>>>>>> that illustrates the behaviour nicely. If current() is used in a >>>>>>> calculation (even if it makes no sense to do so) this extra step down is >>>>>>> not taken, but in a predicate it is. So it seems the behaviour is not >>>>>>> related to the current() function but to how predicates are handled in JR. >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Martijn >>>>>>> >>>>>>> >>>>>>> -- >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Mitch Sundt >>>>> Software Engineer >>>>> University of Washington >>>>> mitche...@gmail.com >>>>> >>>> -- >>>> >>>> >>> >>> >>> -- >>> Mitch Sundt >>> Software Engineer >>> University of Washington >>> mitche...@gmail.com >>> >> >> >> >> -- >> Mitch Sundt >> Software Engineer >> University of Washington >> mitche...@gmail.com >> > > > > -- > Mitch Sundt > Software Engineer > University of Washington > mitche...@gmail.com >

Mitch_S · November 20, 2015, 6:49pm

Yes, I think it should be a one-line change; just don't know where.

Mitch

(I do jar-updates over Christmas / New-Years. Tedious, but doesn't require
a whole lot of attention.)

···

On Fri, Nov 20, 2015 at 10:36 AM, wrote:

Hi Mitch,

Thank you for all the details, I guess I was missing some of the context
of the original issue.

We will give it a shot to see if we can come up with a few ideas how to
fix the evaluation content of the itemset nodeset. I just hope it will not
be like last year with the "form processing logic" in JR, otherwise I
believe that every Christmas will be a JR Christmas.

Meletis

On Friday, November 20, 2015 at 7:29:14 PM UTC+2, Mitch wrote:
The form was attached in one of my earlier replies.

On Fri, Nov 20, 2015 at 9:27 AM, Mitch Sundt mitche...@gmail.com wrote:
And you see this in constraint expressions where you write:

. > 6

I.e., current()/. should refer to the field, and not the group
containing the field, as it currently does when evaluating expressions in
the itemset nodeset.

On Fri, Nov 20, 2015 at 9:26 AM, Mitch Sundt mitche...@gmail.com wrote:
The issue is that there is a discrepancy in the meaning of '.'
across the different contexts of: calculate, relevant, , and these
itemset nodeset expressions.

In other usages, you need to reference this other field with
current()/../filterfield ; but in the nodeset expression, you would
reference it with current()/./filterfield

I.e., the notion of '.' is different when used within a nodeset
expression and when used within a constraint expression or an
field.

See the attached NBiggestOfSet form. For the label, it has:
    <select1 ref="/NBiggestOfSet/education/edu_level">
      <label>What is <output value="
current()/../referred_attendee_name"/>'s level of education?
...

For a constraint, it has:

These each use the current()/../ to reference the group (
/NBiggesetOfSet/education ).

But, within the nodeset definition (if this form used one), you would
need to use current()/./referred_attendee_name to reference a field
in that group.

On Fri, Nov 20, 2015 at 8:22 AM, mel...@surveycto.com wrote:
Hi Mitch,

I think I'm missing something but I think that nothing is broken and
that the only issue is that the expression current()/../filterfield in your
example above should be just changed to current()/filterfield. If you make
that change, everything should work because it will be resolved to:

/data/group1/filterfield

Why should a "../" be present there? We have used current()/somefield
successfully in one of our test forms and it works fine. And I think it
would also work great in your example. Wouldn't it? Or am I totally out of
context?

Meletis

On Friday, November 20, 2015 at 5:35:16 PM UTC+2, Mitch wrote:
Hi Meletis,

That's not the issue --

The issue is that if you use a filter condition in the
nodeset specification of a field "myfield", within that nodeset
specification "current()/.." refers to the parent of the group enclosing
the "myfield" field. It does not refer to the group enclosing the
"myfield" field.

So if you have
a 4 fish b 14 fish ...
and if you have:

This will currently be broken. Because current()/../filterfield,
when evaluated within the itemset nodeset specification, is resolved
to:

/data/filterfield

instead of

/data/group1/filterfield

On Fri, Nov 20, 2015 at 1:58 AM, mel...@surveycto.com wrote:
Well, I think there is a fundamental issue here regarding current()
syntax. Please, let me remind you how JR works with "current()":

The expression "current()" looks like a function but it is not
treated like one; it is not handled by the XPathFuncExpr class, so, if you
try to use it alone you will get an error that the "function" is not
supported. In other words, you cannot use it alone in an expression in
order to refer to the "current" field.

When an expression includes "current()", then it ALWAYS needs to
be used in an XPath, actually, the expression needs to BE an XPath
expression, so that it can be handled with the XPathPathExpr class. For
that reason the expression NEEDS to contain at least one "/".

Taking 1 and 2 into consideration, the ONLY way to refer to the
"current" field (named "somefield") is to use "current()/." or
"current()/somefield". So, I looks like that the original implementation
was "okay" in the sense that the "current()" should only be used in XPaths.

If we wanted to have "current()" refer to the current field, I
believe we should introduce a new function handler in XPathFuncExpr class.
Please let me know if this would work:

A. Whenever the "current()" expression is used inside an XPath, then
the current code would be used as it is used right now (maintaining
backwards compatibility), so that it will still be referring to the
enclosing group, not the field itself.
B. Whenever the "current()" expression is used inside a non-XPath,
then the new code would be used (in XPathFuncExpr) and that would be
evaluated in a way that the current field would be returned/referenced, NOT
the enclosing group.

That way, the following code could work, because it wouldn't throw
the "unrecognized function" error:
label .... ....
What do you think about that approach?

Meletis

On Friday, November 13, 2015 at 11:38:15 PM UTC+2, Martijn van de Rijdt wrote:
Hi,

I'd like to ask for a clarification about the current() node in an
XPath predicate. It seems JR considers this to be the parent
node of the current question. (Thanks to Chris for sharing this.)

E.g. in this question below, current() equates to /data/group and
not to /data/group/options. I would have expected it to be the latter.
....
    <label>label</label>

    <itemset nodeset="instance('crop_list')/root/item[name =
current()*/../*crop]">
         ....

         ....

    </itemset>
Is this by design? Or is it a bug?

We ran into this by realizing that the seemingly more intuitive
predicate [name = current()*/../../*crop] is not working.

See this form
https://docs.google.com/spreadsheets/d/1A74yEHRxQF1zbIcQSrwvZydggUU7m5T3ZAnlR6_TLA4/edit#gid=0
that illustrates the behaviour nicely. If current() is used in a
calculation (even if it makes no sense to do so) this extra step down is
not taken, but in a predicate it is. So it seems the behaviour is not
related to the current() function but to how predicates are handled in JR.

Thanks,
Martijn

--
--
Mitch Sundt
Software Engineer
University of Washington
mitche...@gmail.com
--
--
Mitch Sundt
Software Engineer
University of Washington
mitche...@gmail.com
--
Mitch Sundt
Software Engineer
University of Washington
mitche...@gmail.com
--
Mitch Sundt
Software Engineer
University of Washington
mitche...@gmail.com
--
You received this message because you are subscribed to the Google Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com

Meletis · November 23, 2015, 10:08am

Hi Mitch,

Please take a look at the code comment in line 31 here:

https://bitbucket.org/m.sundt/javarosa/src/bf17fb749b74e53915f086ca3827c3c6fe73fd07/core/src/org/javarosa/core/model/ItemsetBinding.java?at=default&fileviewer=file-view-default#ItemsetBinding.java-31

It clearly says: "ref of the control parent (group/formdef) of itemset
question"

So, for some reason, they wanted it to point to the parent. I also see
that when the dynamic choices are populated, the evaluation context is
wrapped around that parent (contextRef object), that's why current() refers
to the parent group when evaluating itemsets nodesets.

I will run a few tests by changing the contextRef field value, I just
wanted to mention that in case you remember a reason for that code comment.

Meletis

···

On Friday, November 20, 2015 at 8:49:12 PM UTC+2, Mitch wrote: > > Yes, I think it should be a one-line change; just don't know where. > > Mitch > > (I do jar-updates over Christmas / New-Years. Tedious, but doesn't > require a whole lot of attention.) > > > > On Fri, Nov 20, 2015 at 10:36 AM, <mel...@surveycto.com > wrote: > >> Hi Mitch, >> >> Thank you for all the details, I guess I was missing some of the context >> of the original issue. >> >> We will give it a shot to see if we can come up with a few ideas how to >> fix the evaluation content of the itemset nodeset. I just hope it will not >> be like last year with the "form processing logic" in JR, otherwise I >> believe that every Christmas will be a JR Christmas. :) >> >> Meletis >> >> >> On Friday, November 20, 2015 at 7:29:14 PM UTC+2, Mitch wrote: >>> >>> The form was attached in one of my earlier replies. >>> >>> On Fri, Nov 20, 2015 at 9:27 AM, Mitch Sundt wrote: >>> >>>> And you see this in constraint expressions where you write: >>>> >>>> . > 6 >>>> >>>> I.e., current()/. should refer to the field, and not the group >>>> containing the field, as it currently does when evaluating expressions in >>>> the itemset nodeset. >>>> >>>> On Fri, Nov 20, 2015 at 9:26 AM, Mitch Sundt wrote: >>>> >>>>> The issue is that there is a *discrepancy* in the meaning of '.' >>>>> across the different contexts of: calculate, relevant, , and these >>>>> itemset nodeset expressions. >>>>> >>>>> In other usages, you need to reference this other field with >>>>> current()/../filterfield ; but in the nodeset expression, you would >>>>> reference it with current()/./filterfield >>>>> >>>>> I.e., the notion of '.' is different when used within a nodeset >>>>> expression and when used within a constraint expression or an >>>>> field. >>>>> >>>>> See the attached NBiggestOfSet form. For the label, it has: >>>>> >>>>> >>>>> What is 's level of education? >>>>> ... >>>>> >>>>> For a constraint, it has: >>>>> >>>> nodeset="/NBiggestOfSet/education/referred_attendee_name" readonly="true()" >>>>> type="string"/> >>>>> >>>>> >>>>> These each use the *current()/../* to reference the group ( >>>>> /NBiggesetOfSet/education ). >>>>> >>>>> But, within the nodeset definition (if this form used one), you would >>>>> need to use *current()/./referred_attendee_name* to reference a >>>>> field in that group. >>>>> >>>>> >>>>> >>>>> >>>>> On Fri, Nov 20, 2015 at 8:22 AM, wrote: >>>>> >>>>>> Hi Mitch, >>>>>> >>>>>> I think I'm missing something but I think that nothing is broken and >>>>>> that the only issue is that the expression current()/../filterfield in your >>>>>> example above should be just changed to current()/filterfield. If you make >>>>>> that change, everything should work because it will be resolved to: >>>>>> >>>>>> /data/group1/filterfield >>>>>> >>>>>> Why should a "../" be present there? We have used current()/somefield >>>>>> successfully in one of our test forms and it works fine. And I think it >>>>>> would also work great in your example. Wouldn't it? Or am I totally out of >>>>>> context? >>>>>> >>>>>> Meletis >>>>>> >>>>>> >>>>>> On Friday, November 20, 2015 at 5:35:16 PM UTC+2, Mitch wrote: >>>>>> >>>>>>> Hi Meletis, >>>>>>> >>>>>>> That's not the issue -- >>>>>>> >>>>>>> The issue is that if you use a filter condition in the >>>>>>> nodeset specification of a field "myfield", within that nodeset >>>>>>> specification "current()/.." refers to the parent of the group enclosing >>>>>>> the "myfield" field. It does not refer to the group enclosing the >>>>>>> "myfield" field. >>>>>>> >>>>>>> So if you have >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> a >>>>>>> 4 >>>>>>> fish >>>>>>> >>>>>>> >>>>>>> b >>>>>>> 14 >>>>>>> fish >>>>>>> >>>>>>> ... >>>>>>> >>>>>>> >>>>>>> >>>>>>> and if you have: >>>>>>> >>>>>>> >>>>>>> >>>>>> nodeset="instance('food')/root/fooditem[filtercriteria=current()/../filterfield]"> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> This will currently be broken. Because current()/../filterfield, >>>>>>> when evaluated within the itemset nodeset specification, is resolved >>>>>>> to: >>>>>>> >>>>>>> /data/filterfield >>>>>>> >>>>>>> instead of >>>>>>> >>>>>>> /data/group1/filterfield >>>>>>> >>>>>>> >>>>>>> On Fri, Nov 20, 2015 at 1:58 AM, wrote: >>>>>>> >>>>>>>> Well, I think there is a fundamental issue here regarding current() >>>>>>>> syntax. Please, let me remind you how JR works with "current()": >>>>>>>> >>>>>>>> 1. The expression "current()" looks like a function but it is not >>>>>>>> treated like one; it is not handled by the XPathFuncExpr class, so, if you >>>>>>>> try to use it alone you will get an error that the "function" is not >>>>>>>> supported. In other words, you cannot use it alone in an expression in >>>>>>>> order to refer to the "current" field. >>>>>>>> >>>>>>>> 2. When an expression includes "current()", then it ALWAYS needs to >>>>>>>> be used in an XPath, actually, the expression needs to BE an XPath >>>>>>>> expression, so that it can be handled with the XPathPathExpr class. For >>>>>>>> that reason the expression NEEDS to contain at least one "/". >>>>>>>> >>>>>>>> 3. Taking 1 and 2 into consideration, the ONLY way to refer to the >>>>>>>> "current" field (named "somefield") is to use "current()/." or >>>>>>>> "current()/somefield". So, I looks like that the original implementation >>>>>>>> was "okay" in the sense that the "current()" should only be used in XPaths. >>>>>>>> >>>>>>>> If we wanted to have "current()" refer to the current field, I >>>>>>>> believe we should introduce a new function handler in XPathFuncExpr class. >>>>>>>> Please let me know if this would work: >>>>>>>> >>>>>>>> A. Whenever the "current()" expression is used inside an XPath, >>>>>>>> then the current code would be used as it is used right now (maintaining >>>>>>>> backwards compatibility), so that it will still be referring to the >>>>>>>> enclosing group, not the field itself. >>>>>>>> B. Whenever the "current()" expression is used inside a non-XPath, >>>>>>>> then the new code would be used (in XPathFuncExpr) and that would be >>>>>>>> evaluated in a way that the current field would be returned/referenced, NOT >>>>>>>> the enclosing group. >>>>>>>> >>>>>>>> That way, the following code could work, because it wouldn't throw >>>>>>>> the "unrecognized function" error: >>>>>>>> >>>>>>>> >>>>>>>> label >>>>>>>> >>>>>>>> .... >>>>>>>> .... >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> What do you think about that approach? >>>>>>>> >>>>>>>> Meletis >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Friday, November 13, 2015 at 11:38:15 PM UTC+2, Martijn van de Rijdt wrote: >>>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> I'd like to ask for a clarification about the current() node in an >>>>>>>>> XPath predicate. It seems JR considers this to be the *parent* >>>>>>>>> node of the current question. (Thanks to Chris for sharing this.) >>>>>>>>> >>>>>>>>> E.g. in this question below, current() equates to /data/group and >>>>>>>>> not to /data/group/options. I would have expected it to be the latter. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> .... >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> label >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> .... >>>>>>>>> >>>>>>>>> .... >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Is this by design? Or is it a bug? >>>>>>>>> >>>>>>>>> >>>>>>>>> We ran into this by realizing that the seemingly more intuitive >>>>>>>>> predicate [name = current()*/../../*crop] is not working. >>>>>>>>> >>>>>>>>> >>>>>>>>> See this form >>>>>>>>> >>>>>>>>> that illustrates the behaviour nicely. If current() is used in a >>>>>>>>> calculation (even if it makes no sense to do so) this extra step down is >>>>>>>>> not taken, but in a predicate it is. So it seems the behaviour is not >>>>>>>>> related to the current() function but to how predicates are handled in JR. >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Martijn >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Mitch Sundt >>>>>>> Software Engineer >>>>>>> University of Washington >>>>>>> mitche...@gmail.com >>>>>>> >>>>>> -- >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Mitch Sundt >>>>> Software Engineer >>>>> University of Washington >>>>> mitche...@gmail.com >>>>> >>>> >>>> >>>> >>>> -- >>>> Mitch Sundt >>>> Software Engineer >>>> University of Washington >>>> mitche...@gmail.com >>>> >>> >>> >>> >>> -- >>> Mitch Sundt >>> Software Engineer >>> University of Washington >>> mitche...@gmail.com >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "ODK Developers" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to opendatakit-developers+unsubscribe@googlegroups.com >> . >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > Mitch Sundt > Software Engineer > University of Washington > mitche...@gmail.com >

Meletis · November 23, 2015, 10:23am

Just for the history's sake, I found the time where the behavior changed.
It was at March 11, 2010:

Take a look only in the changes of the "populateDynamicChoices" method. The
context reference used to be the "current" field, but after the changes
above it started be the field's parent (by adding getParent()). Perhaps
there was a reason for that change, but perhaps not, but I think all of us
agree that this should be fixed, even after 5 and a half years.

Meletis

···

On Monday, November 23, 2015 at 12:08:47 PM UTC+2, mel...@surveycto.com wrote: > > Hi Mitch, > > Please take a look at the code comment in line 31 here: > > > https://bitbucket.org/m.sundt/javarosa/src/bf17fb749b74e53915f086ca3827c3c6fe73fd07/core/src/org/javarosa/core/model/ItemsetBinding.java?at=default&fileviewer=file-view-default#ItemsetBinding.java-31 > > It clearly says: "*ref of the control parent (group/formdef) of itemset > question*" > > So, for some reason, they *wanted* it to point to the parent. I also see > that when the dynamic choices are populated, the evaluation context is > wrapped around that parent (contextRef object), that's why current() refers > to the parent group when evaluating itemsets nodesets. > > I will run a few tests by changing the contextRef field value, I just > wanted to mention that in case you remember a reason for that code comment. > > Meletis > > On Friday, November 20, 2015 at 8:49:12 PM UTC+2, Mitch wrote: >> >> Yes, I think it should be a one-line change; just don't know where. >> >> Mitch >> >> (I do jar-updates over Christmas / New-Years. Tedious, but doesn't >> require a whole lot of attention.) >> >> >> >> On Fri, Nov 20, 2015 at 10:36 AM, wrote: >> >>> Hi Mitch, >>> >>> Thank you for all the details, I guess I was missing some of the context >>> of the original issue. >>> >>> We will give it a shot to see if we can come up with a few ideas how to >>> fix the evaluation content of the itemset nodeset. I just hope it will not >>> be like last year with the "form processing logic" in JR, otherwise I >>> believe that every Christmas will be a JR Christmas. :) >>> >>> Meletis >>> >>> >>> On Friday, November 20, 2015 at 7:29:14 PM UTC+2, Mitch wrote: >>>> >>>> The form was attached in one of my earlier replies. >>>> >>>> On Fri, Nov 20, 2015 at 9:27 AM, Mitch Sundt wrote: >>>> >>>>> And you see this in constraint expressions where you write: >>>>> >>>>> . > 6 >>>>> >>>>> I.e., current()/. should refer to the field, and not the group >>>>> containing the field, as it currently does when evaluating expressions in >>>>> the itemset nodeset. >>>>> >>>>> On Fri, Nov 20, 2015 at 9:26 AM, Mitch Sundt wrote: >>>>> >>>>>> The issue is that there is a *discrepancy* in the meaning of '.' >>>>>> across the different contexts of: calculate, relevant, , and these >>>>>> itemset nodeset expressions. >>>>>> >>>>>> In other usages, you need to reference this other field with >>>>>> current()/../filterfield ; but in the nodeset expression, you would >>>>>> reference it with current()/./filterfield >>>>>> >>>>>> I.e., the notion of '.' is different when used within a nodeset >>>>>> expression and when used within a constraint expression or an >>>>>> field. >>>>>> >>>>>> See the attached NBiggestOfSet form. For the label, it has: >>>>>> >>>>>> >>>>>> What is 's level of >>>>>> education? >>>>>> ... >>>>>> >>>>>> For a constraint, it has: >>>>>> >>>>> nodeset="/NBiggestOfSet/education/referred_attendee_name" readonly="true()" >>>>>> type="string"/> >>>>>> >>>>>> >>>>>> These each use the *current()/../* to reference the group ( >>>>>> /NBiggesetOfSet/education ). >>>>>> >>>>>> But, within the nodeset definition (if this form used one), you would >>>>>> need to use *current()/./referred_attendee_name* to reference a >>>>>> field in that group. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Fri, Nov 20, 2015 at 8:22 AM, wrote: >>>>>> >>>>>>> Hi Mitch, >>>>>>> >>>>>>> I think I'm missing something but I think that nothing is broken and >>>>>>> that the only issue is that the expression current()/../filterfield in your >>>>>>> example above should be just changed to current()/filterfield. If you make >>>>>>> that change, everything should work because it will be resolved to: >>>>>>> >>>>>>> /data/group1/filterfield >>>>>>> >>>>>>> Why should a "../" be present there? We have used >>>>>>> current()/somefield successfully in one of our test forms and it works >>>>>>> fine. And I think it would also work great in your example. Wouldn't it? Or >>>>>>> am I totally out of context? >>>>>>> >>>>>>> Meletis >>>>>>> >>>>>>> >>>>>>> On Friday, November 20, 2015 at 5:35:16 PM UTC+2, Mitch wrote: >>>>>>> >>>>>>>> Hi Meletis, >>>>>>>> >>>>>>>> That's not the issue -- >>>>>>>> >>>>>>>> The issue is that if you use a filter condition in the >>>>>>>> nodeset specification of a field "myfield", within that nodeset >>>>>>>> specification "current()/.." refers to the parent of the group enclosing >>>>>>>> the "myfield" field. It does not refer to the group enclosing the >>>>>>>> "myfield" field. >>>>>>>> >>>>>>>> So if you have >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> a >>>>>>>> 4 >>>>>>>> fish >>>>>>>> >>>>>>>> >>>>>>>> b >>>>>>>> 14 >>>>>>>> fish >>>>>>>> >>>>>>>> ... >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> and if you have: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> nodeset="instance('food')/root/fooditem[filtercriteria=current()/../filterfield]"> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> This will currently be broken. Because current()/../filterfield, >>>>>>>> when evaluated within the itemset nodeset specification, is >>>>>>>> resolved to: >>>>>>>> >>>>>>>> /data/filterfield >>>>>>>> >>>>>>>> instead of >>>>>>>> >>>>>>>> /data/group1/filterfield >>>>>>>> >>>>>>>> >>>>>>>> On Fri, Nov 20, 2015 at 1:58 AM, wrote: >>>>>>>> >>>>>>>>> Well, I think there is a fundamental issue here regarding >>>>>>>>> current() syntax. Please, let me remind you how JR works with "current()": >>>>>>>>> >>>>>>>>> 1. The expression "current()" looks like a function but it is not >>>>>>>>> treated like one; it is not handled by the XPathFuncExpr class, so, if you >>>>>>>>> try to use it alone you will get an error that the "function" is not >>>>>>>>> supported. In other words, you cannot use it alone in an expression in >>>>>>>>> order to refer to the "current" field. >>>>>>>>> >>>>>>>>> 2. When an expression includes "current()", then it ALWAYS needs >>>>>>>>> to be used in an XPath, actually, the expression needs to BE an XPath >>>>>>>>> expression, so that it can be handled with the XPathPathExpr class. For >>>>>>>>> that reason the expression NEEDS to contain at least one "/". >>>>>>>>> >>>>>>>>> 3. Taking 1 and 2 into consideration, the ONLY way to refer to the >>>>>>>>> "current" field (named "somefield") is to use "current()/." or >>>>>>>>> "current()/somefield". So, I looks like that the original implementation >>>>>>>>> was "okay" in the sense that the "current()" should only be used in XPaths. >>>>>>>>> >>>>>>>>> If we wanted to have "current()" refer to the current field, I >>>>>>>>> believe we should introduce a new function handler in XPathFuncExpr class. >>>>>>>>> Please let me know if this would work: >>>>>>>>> >>>>>>>>> A. Whenever the "current()" expression is used inside an XPath, >>>>>>>>> then the current code would be used as it is used right now (maintaining >>>>>>>>> backwards compatibility), so that it will still be referring to the >>>>>>>>> enclosing group, not the field itself. >>>>>>>>> B. Whenever the "current()" expression is used inside a non-XPath, >>>>>>>>> then the new code would be used (in XPathFuncExpr) and that would be >>>>>>>>> evaluated in a way that the current field would be returned/referenced, NOT >>>>>>>>> the enclosing group. >>>>>>>>> >>>>>>>>> That way, the following code could work, because it wouldn't throw >>>>>>>>> the "unrecognized function" error: >>>>>>>>> >>>>>>>>> >>>>>>>>> label >>>>>>>>> >>>>>>>>> .... >>>>>>>>> .... >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> What do you think about that approach? >>>>>>>>> >>>>>>>>> Meletis >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Friday, November 13, 2015 at 11:38:15 PM UTC+2, Martijn van de Rijdt wrote: >>>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> I'd like to ask for a clarification about the current() node in >>>>>>>>>> an XPath predicate. It seems JR considers this to be the *parent* >>>>>>>>>> node of the current question. (Thanks to Chris for sharing this.) >>>>>>>>>> >>>>>>>>>> E.g. in this question below, current() equates to /data/group and >>>>>>>>>> not to /data/group/options. I would have expected it to be the latter. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> .... >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> label >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> .... >>>>>>>>>> >>>>>>>>>> .... >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Is this by design? Or is it a bug? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> We ran into this by realizing that the seemingly more intuitive >>>>>>>>>> predicate [name = current()*/../../*crop] is not working. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> See this form >>>>>>>>>> >>>>>>>>>> that illustrates the behaviour nicely. If current() is used in a >>>>>>>>>> calculation (even if it makes no sense to do so) this extra step down is >>>>>>>>>> not taken, but in a predicate it is. So it seems the behaviour is not >>>>>>>>>> related to the current() function but to how predicates are handled in JR. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Martijn >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Mitch Sundt >>>>>>>> Software Engineer >>>>>>>> University of Washington >>>>>>>> mitche...@gmail.com >>>>>>>> >>>>>>> -- >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Mitch Sundt >>>>>> Software Engineer >>>>>> University of Washington >>>>>> mitche...@gmail.com >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Mitch Sundt >>>>> Software Engineer >>>>> University of Washington >>>>> mitche...@gmail.com >>>>> >>>> >>>> >>>> >>>> -- >>>> Mitch Sundt >>>> Software Engineer >>>> University of Washington >>>> mitche...@gmail.com >>>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "ODK Developers" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to opendatakit-developers+unsubscribe@googlegroups.com. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> >> >> -- >> Mitch Sundt >> Software Engineer >> University of Washington >> mitche...@gmail.com >> >

crobert · November 23, 2015, 1:59pm

So just to be clear, the "fix" we're testing here reverts the entire
context within that populateDynamicChoices() function, to be the field
instead of the parent -- so the effects are potentially much wider than
just what current() returns. Potentially anything and everything that
depends on context can change now, since the context will shift from parent
to field.

This means that we revert a change from 5 years ago and alter the context
from now on. Neither Meletis nor I feel terribly confident that we can
entirely predict the consequences to backward compatibility. We're testing
the things we can think to test, but honestly it's XML users in the broader
ODK community who face the greatest risks here; SurveyCTO users by and
large use XLSForm and thus the potential XPath syntax consequences are
sharply limited.

Are you guys very sure that you want to take this path? I can tell you now
that if we make this change and then there is some outcry after the next
ODK Collect release, SurveyCTO Collect will very likely stick with the new
change (since we will have changed pyxform and we'll then have too many
backward-compatibility concerns to then reverse the change).

Thanks,

Chris

···

On Mon, Nov 23, 2015 at 5:23 AM wrote:

Just for the history's sake, I found the time where the behavior changed.
It was at March 11, 2010:

https://bitbucket.org/m.sundt/javarosa/commits/b41875b2c23c9a21a868a5d2dc0ffc1f6b5b0b65#Lcore/src/org/javarosa/core/model/FormDef.javaT635

Take a look only in the changes of the "populateDynamicChoices" method.
The context reference used to be the "current" field, but after the changes
above it started be the field's parent (by adding getParent()). Perhaps
there was a reason for that change, but perhaps not, but I think all of us
agree that this should be fixed, even after 5 and a half years.

Meletis

On Monday, November 23, 2015 at 12:08:47 PM UTC+2, mel...@surveycto.com wrote:
Hi Mitch,

Please take a look at the code comment in line 31 here:

https://bitbucket.org/m.sundt/javarosa/src/bf17fb749b74e53915f086ca3827c3c6fe73fd07/core/src/org/javarosa/core/model/ItemsetBinding.java?at=default&fileviewer=file-view-default#ItemsetBinding.java-31

It clearly says: "ref of the control parent (group/formdef) of itemset
question"

So, for some reason, they wanted it to point to the parent. I also see
that when the dynamic choices are populated, the evaluation context is
wrapped around that parent (contextRef object), that's why current() refers
to the parent group when evaluating itemsets nodesets.

I will run a few tests by changing the contextRef field value, I just
wanted to mention that in case you remember a reason for that code comment.

Meletis

On Friday, November 20, 2015 at 8:49:12 PM UTC+2, Mitch wrote:
Yes, I think it should be a one-line change; just don't know where.

Mitch

(I do jar-updates over Christmas / New-Years. Tedious, but doesn't
require a whole lot of attention.)

On Fri, Nov 20, 2015 at 10:36 AM, mel...@surveycto.com wrote:
Hi Mitch,

Thank you for all the details, I guess I was missing some of the
context of the original issue.

We will give it a shot to see if we can come up with a few ideas how to
fix the evaluation content of the itemset nodeset. I just hope it will not
be like last year with the "form processing logic" in JR, otherwise I
believe that every Christmas will be a JR Christmas.

Meletis

On Friday, November 20, 2015 at 7:29:14 PM UTC+2, Mitch wrote:
The form was attached in one of my earlier replies.

On Fri, Nov 20, 2015 at 9:27 AM, Mitch Sundt mitche...@gmail.com wrote:
And you see this in constraint expressions where you write:

. > 6

I.e., current()/. should refer to the field, and not the group
containing the field, as it currently does when evaluating expressions in
the itemset nodeset.

On Fri, Nov 20, 2015 at 9:26 AM, Mitch Sundt mitche...@gmail.com wrote:
The issue is that there is a discrepancy in the meaning of '.'
across the different contexts of: calculate, relevant, , and these
itemset nodeset expressions.

In other usages, you need to reference this other field with
current()/../filterfield ; but in the nodeset expression, you would
reference it with current()/./filterfield

I.e., the notion of '.' is different when used within a nodeset
expression and when used within a constraint expression or an
field.

See the attached NBiggestOfSet form. For the label, it has:
    <select1 ref="/NBiggestOfSet/education/edu_level">
      <label>What is <output value="
current()/../referred_attendee_name"/>'s level of
education?
...

For a constraint, it has:

These each use the current()/../ to reference the group (
/NBiggesetOfSet/education ).

But, within the nodeset definition (if this form used one), you
would need to use current()/./referred_attendee_name to
reference a field in that group.

On Fri, Nov 20, 2015 at 8:22 AM, mel...@surveycto.com wrote:
Hi Mitch,

I think I'm missing something but I think that nothing is broken
and that the only issue is that the expression current()/../filterfield in
your example above should be just changed to current()/filterfield. If you
make that change, everything should work because it will be resolved to:

/data/group1/filterfield

Why should a "../" be present there? We have used
current()/somefield successfully in one of our test forms and it works
fine. And I think it would also work great in your example. Wouldn't it? Or
am I totally out of context?

Meletis

On Friday, November 20, 2015 at 5:35:16 PM UTC+2, Mitch wrote:
Hi Meletis,

That's not the issue --

The issue is that if you use a filter condition in the
nodeset specification of a field "myfield", within that nodeset
specification "current()/.." refers to the parent of the group enclosing
the "myfield" field. It does not refer to the group enclosing the
"myfield" field.

So if you have
a 4 fish b 14 fish ...
and if you have:

This will currently be broken. Because current()/../filterfield,
when evaluated within the itemset nodeset specification, is
resolved to:

/data/filterfield

instead of

/data/group1/filterfield

On Fri, Nov 20, 2015 at 1:58 AM, mel...@surveycto.com wrote:
Well, I think there is a fundamental issue here regarding
current() syntax. Please, let me remind you how JR works with "current()":

The expression "current()" looks like a function but it is not
treated like one; it is not handled by the XPathFuncExpr class, so, if you
try to use it alone you will get an error that the "function" is not
supported. In other words, you cannot use it alone in an expression in
order to refer to the "current" field.

When an expression includes "current()", then it ALWAYS needs
to be used in an XPath, actually, the expression needs to BE an XPath
expression, so that it can be handled with the XPathPathExpr class. For
that reason the expression NEEDS to contain at least one "/".

Taking 1 and 2 into consideration, the ONLY way to refer to
the "current" field (named "somefield") is to use "current()/." or
"current()/somefield". So, I looks like that the original implementation
was "okay" in the sense that the "current()" should only be used in XPaths.

If we wanted to have "current()" refer to the current field, I
believe we should introduce a new function handler in XPathFuncExpr class.
Please let me know if this would work:

A. Whenever the "current()" expression is used inside an XPath,
then the current code would be used as it is used right now (maintaining
backwards compatibility), so that it will still be referring to the
enclosing group, not the field itself.
B. Whenever the "current()" expression is used inside a
non-XPath, then the new code would be used (in XPathFuncExpr) and that
would be evaluated in a way that the current field would be
returned/referenced, NOT the enclosing group.

That way, the following code could work, because it wouldn't
throw the "unrecognized function" error:
label .... ....
What do you think about that approach?

Meletis

On Friday, November 13, 2015 at 11:38:15 PM UTC+2, Martijn van de Rijdt wrote:
Hi,

I'd like to ask for a clarification about the current() node in
an XPath predicate. It seems JR considers this to be the
parent node of the current question. (Thanks to Chris for
sharing this.)

E.g. in this question below, current() equates to /data/group
and not to /data/group/options. I would have expected it to be the latter.
....
    <label>label</label>

    <itemset nodeset="instance('crop_list')/root/item[name =
current()*/../*crop]">
         ....

         ....

    </itemset>
Is this by design? Or is it a bug?

We ran into this by realizing that the seemingly more intuitive
predicate [name = current()*/../../*crop] is not working.

See this form
https://docs.google.com/spreadsheets/d/1A74yEHRxQF1zbIcQSrwvZydggUU7m5T3ZAnlR6_TLA4/edit#gid=0
that illustrates the behaviour nicely. If current() is used in a
calculation (even if it makes no sense to do so) this extra step down is
not taken, but in a predicate it is. So it seems the behaviour is not
related to the current() function but to how predicates are handled in JR.

Thanks,
Martijn

--
--
Mitch Sundt
Software Engineer
University of Washington
mitche...@gmail.com
--
--
Mitch Sundt
Software Engineer
University of Washington
mitche...@gmail.com
--
Mitch Sundt
Software Engineer
University of Washington
mitche...@gmail.com
--
Mitch Sundt
Software Engineer
University of Washington
mitche...@gmail.com
--
You received this message because you are subscribed to the Google
Groups "ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
Mitch Sundt
Software Engineer
University of Washington
mitche...@gmail.com
--
You received this message because you are subscribed to the Google Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Mitch_S · November 23, 2015, 9:03pm

w.r.t. backward compatibility

I too am concerned.

A proposed solution:

Add a command line argument or other mechanism to request that XLSForm
inject a 'revision="2015-11-23"' attribute into the element. e.g.,

This is used to alter the behavior of the XForms engine to accommodate
backward-compatible bug behaviors.

We can't identify the bugs (e.g, 'legacy="itemset-parent"'), since that
would break older forms run on the new ODK Collect releases.
We have to advance the revision code as bugs are fixed.

I think an integer value is fine for this.

I don't anticipate making a lot of revisions, and I think the revisions
would be sequentially applied (you can't pick-and-choose what bugs you
include).

In the future, this would allow us to re-do the date-time behavior.

Modify the XLSForm tools (e.g., the online form generator) to enable the
user to select what revision they want to emit (much like we did last year
with the JR form eval choice setting within ODK Collect). We can default
to emitting the latest revision if the user does not make a choice.
Augment JR to look for this revision attribute and store/restore it in
the FormDef binary object.

Based upon this value, alter the behavior of the JR itemset evaluation to
fix the path bug.

Modify ODK Validate to scan for syntax that may be impacted by a
revision (to advise whether to change something). Not sure how complex
that might be. May not be always possible?

···

------------- *w.r.t. impacts of change*

Thank you Meletis for researching when this change occurred.

I will have to ponder what effect the parent/node change would have on
itemset copying. Hadn't thought that there was any relationship between
the two, but perhaps there is.

Yaw also reported that the Cascading Select itemsets on
opendatakit.appspot.com are not working with the 1.4.7 rev 1053 release
(and they work but give odd 'null' resolutions on 1057). This is in a
related area of this same code, so I will hopefully gain a better
understanding of dynamic itemsets as I uncover the causes of that problem.

Mitch

On Mon, Nov 23, 2015 at 5:59 AM, Christopher Robert crobert@surveycto.com wrote:

So just to be clear, the "fix" we're testing here reverts the entire
context within that populateDynamicChoices() function, to be the field
instead of the parent -- so the effects are potentially much wider than
just what current() returns. Potentially anything and everything that
depends on context can change now, since the context will shift from parent
to field.

This means that we revert a change from 5 years ago and alter the context
from now on. Neither Meletis nor I feel terribly confident that we can
entirely predict the consequences to backward compatibility. We're testing
the things we can think to test, but honestly it's XML users in the broader
ODK community who face the greatest risks here; SurveyCTO users by and
large use XLSForm and thus the potential XPath syntax consequences are
sharply limited.

Are you guys very sure that you want to take this path? I can tell you now
that if we make this change and then there is some outcry after the next
ODK Collect release, SurveyCTO Collect will very likely stick with the new
change (since we will have changed pyxform and we'll then have too many
backward-compatibility concerns to then reverse the change).

Thanks,

Chris

On Mon, Nov 23, 2015 at 5:23 AM meletis@surveycto.com wrote:
Just for the history's sake, I found the time where the behavior changed.
It was at March 11, 2010:

https://bitbucket.org/m.sundt/javarosa/commits/b41875b2c23c9a21a868a5d2dc0ffc1f6b5b0b65#Lcore/src/org/javarosa/core/model/FormDef.javaT635

Take a look only in the changes of the "populateDynamicChoices" method.
The context reference used to be the "current" field, but after the changes
above it started be the field's parent (by adding getParent()). Perhaps
there was a reason for that change, but perhaps not, but I think all of us
agree that this should be fixed, even after 5 and a half years.

Meletis

On Monday, November 23, 2015 at 12:08:47 PM UTC+2, mel...@surveycto.com wrote:
Hi Mitch,

Please take a look at the code comment in line 31 here:

https://bitbucket.org/m.sundt/javarosa/src/bf17fb749b74e53915f086ca3827c3c6fe73fd07/core/src/org/javarosa/core/model/ItemsetBinding.java?at=default&fileviewer=file-view-default#ItemsetBinding.java-31

It clearly says: "ref of the control parent (group/formdef) of itemset
question"

So, for some reason, they wanted it to point to the parent. I also
see that when the dynamic choices are populated, the evaluation context is
wrapped around that parent (contextRef object), that's why current() refers
to the parent group when evaluating itemsets nodesets.

I will run a few tests by changing the contextRef field value, I just
wanted to mention that in case you remember a reason for that code comment.

Meletis

On Friday, November 20, 2015 at 8:49:12 PM UTC+2, Mitch wrote:
Yes, I think it should be a one-line change; just don't know where.

Mitch

(I do jar-updates over Christmas / New-Years. Tedious, but doesn't
require a whole lot of attention.)

On Fri, Nov 20, 2015 at 10:36 AM, mel...@surveycto.com wrote:
Hi Mitch,

Thank you for all the details, I guess I was missing some of the
context of the original issue.

We will give it a shot to see if we can come up with a few ideas how
to fix the evaluation content of the itemset nodeset. I just hope it will
not be like last year with the "form processing logic" in JR, otherwise I
believe that every Christmas will be a JR Christmas.

Meletis

On Friday, November 20, 2015 at 7:29:14 PM UTC+2, Mitch wrote:
The form was attached in one of my earlier replies.

On Fri, Nov 20, 2015 at 9:27 AM, Mitch Sundt mitche...@gmail.com wrote:
And you see this in constraint expressions where you write:

. > 6

I.e., current()/. should refer to the field, and not the group
containing the field, as it currently does when evaluating expressions in
the itemset nodeset.

On Fri, Nov 20, 2015 at 9:26 AM, Mitch Sundt mitche...@gmail.com wrote:
The issue is that there is a discrepancy in the meaning of '.'
across the different contexts of: calculate, relevant, , and these
itemset nodeset expressions.

In other usages, you need to reference this other field with
current()/../filterfield ; but in the nodeset expression, you would
reference it with current()/./filterfield

I.e., the notion of '.' is different when used within a nodeset
expression and when used within a constraint expression or an
field.

See the attached NBiggestOfSet form. For the label, it has:
    <select1 ref="/NBiggestOfSet/education/edu_level">
      <label>What is <output value="
current()/../referred_attendee_name"/>'s level of
education?
...

For a constraint, it has:

These each use the current()/../ to reference the group (
/NBiggesetOfSet/education ).

But, within the nodeset definition (if this form used one), you
would need to use current()/./referred_attendee_name to
reference a field in that group.

On Fri, Nov 20, 2015 at 8:22 AM, mel...@surveycto.com wrote:
Hi Mitch,

I think I'm missing something but I think that nothing is broken
and that the only issue is that the expression current()/../filterfield in
your example above should be just changed to current()/filterfield. If you
make that change, everything should work because it will be resolved to:

/data/group1/filterfield

Why should a "../" be present there? We have used
current()/somefield successfully in one of our test forms and it works
fine. And I think it would also work great in your example. Wouldn't it? Or
am I totally out of context?

Meletis

On Friday, November 20, 2015 at 5:35:16 PM UTC+2, Mitch wrote:
Hi Meletis,

That's not the issue --

The issue is that if you use a filter condition in the
nodeset specification of a field "myfield", within that nodeset
specification "current()/.." refers to the parent of the group enclosing
the "myfield" field. It does not refer to the group enclosing the
"myfield" field.

So if you have
a 4 fish b 14 fish ...
and if you have:

This will currently be broken. Because current()/../filterfield,
when evaluated within the itemset nodeset specification, is
resolved to:

/data/filterfield

instead of

/data/group1/filterfield

On Fri, Nov 20, 2015 at 1:58 AM, mel...@surveycto.com wrote:
Well, I think there is a fundamental issue here regarding
current() syntax. Please, let me remind you how JR works with "current()":

The expression "current()" looks like a function but it is
not treated like one; it is not handled by the XPathFuncExpr class, so, if
you try to use it alone you will get an error that the "function" is not
supported. In other words, you cannot use it alone in an expression in
order to refer to the "current" field.

When an expression includes "current()", then it ALWAYS needs
to be used in an XPath, actually, the expression needs to BE an XPath
expression, so that it can be handled with the XPathPathExpr class. For
that reason the expression NEEDS to contain at least one "/".

Taking 1 and 2 into consideration, the ONLY way to refer to
the "current" field (named "somefield") is to use "current()/." or
"current()/somefield". So, I looks like that the original implementation
was "okay" in the sense that the "current()" should only be used in XPaths.

If we wanted to have "current()" refer to the current field, I
believe we should introduce a new function handler in XPathFuncExpr class.
Please let me know if this would work:

A. Whenever the "current()" expression is used inside an XPath,
then the current code would be used as it is used right now (maintaining
backwards compatibility), so that it will still be referring to the
enclosing group, not the field itself.
B. Whenever the "current()" expression is used inside a
non-XPath, then the new code would be used (in XPathFuncExpr) and that
would be evaluated in a way that the current field would be
returned/referenced, NOT the enclosing group.

That way, the following code could work, because it wouldn't
throw the "unrecognized function" error:
label .... ....
What do you think about that approach?

Meletis

On Friday, November 13, 2015 at 11:38:15 PM UTC+2, Martijn van de Rijdt wrote:
Hi,

I'd like to ask for a clarification about the current() node in
an XPath predicate. It seems JR considers this to be the
parent node of the current question. (Thanks to Chris for
sharing this.)

E.g. in this question below, current() equates to /data/group
and not to /data/group/options. I would have expected it to be the latter.
....
    <label>label</label>

    <itemset nodeset="instance('crop_list')/root/item[name
= current()*/../*crop]">
         ....

         ....

    </itemset>
Is this by design? Or is it a bug?

We ran into this by realizing that the seemingly more intuitive
predicate [name = current()*/../../*crop] is not working.

See this form
https://docs.google.com/spreadsheets/d/1A74yEHRxQF1zbIcQSrwvZydggUU7m5T3ZAnlR6_TLA4/edit#gid=0
that illustrates the behaviour nicely. If current() is used in a
calculation (even if it makes no sense to do so) this extra step down is
not taken, but in a predicate it is. So it seems the behaviour is not
related to the current() function but to how predicates are handled in JR.

Thanks,
Martijn

--
--
Mitch Sundt
Software Engineer
University of Washington
mitche...@gmail.com
--
--
Mitch Sundt
Software Engineer
University of Washington
mitche...@gmail.com
--
Mitch Sundt
Software Engineer
University of Washington
mitche...@gmail.com
--
Mitch Sundt
Software Engineer
University of Washington
mitche...@gmail.com
--
You received this message because you are subscribed to the Google
Groups "ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
Mitch Sundt
Software Engineer
University of Washington
mitche...@gmail.com
--
You received this message because you are subscribed to the Google Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com

Mitch_S · November 23, 2015, 10:45pm

And, if it isn't clear, to preserve backward-compatible operations, XLSForm
should not expand ${fieldname} with a relative path unless the revision
value is the newer one; if the revision is not specified, it would emit
absolute paths like it currently does.

I also switched to use a date value for the revision value ("2015-11-23")
which allows simple lexical comparisons.

···

On Mon, Nov 23, 2015 at 1:03 PM, Mitch Sundt wrote:

w.r.t. backward compatibility

I too am concerned.

A proposed solution:

Add a command line argument or other mechanism to request that XLSForm
inject a 'revision="2015-11-23"' attribute into the element. e.g.,

This is used to alter the behavior of the XForms engine to accommodate
backward-compatible bug behaviors.

We can't identify the bugs (e.g, 'legacy="itemset-parent"'), since that
would break older forms run on the new ODK Collect releases.
We have to advance the revision code as bugs are fixed.

I think an integer value is fine for this.

I don't anticipate making a lot of revisions, and I think the revisions
would be sequentially applied (you can't pick-and-choose what bugs you
include).

In the future, this would allow us to re-do the date-time behavior.

Modify the XLSForm tools (e.g., the online form generator) to enable
the user to select what revision they want to emit (much like we did last
year with the JR form eval choice setting within ODK Collect). We can
default to emitting the latest revision if the user does not make a choice.

Augment JR to look for this revision attribute and store/restore it in
the FormDef binary object.

Based upon this value, alter the behavior of the JR itemset evaluation to
fix the path bug.

Modify ODK Validate to scan for syntax that may be impacted by a
revision (to advise whether to change something). Not sure how complex
that might be. May not be always possible?

w.r.t. impacts of change

Thank you Meletis for researching when this change occurred.

I will have to ponder what effect the parent/node change would have on
itemset copying. Hadn't thought that there was any relationship between
the two, but perhaps there is.

Yaw also reported that the Cascading Select itemsets on
opendatakit.appspot.com are not working with the 1.4.7 rev 1053 release
(and they work but give odd 'null' resolutions on 1057). This is in a
related area of this same code, so I will hopefully gain a better
understanding of dynamic itemsets as I uncover the causes of that problem.

Mitch

On Mon, Nov 23, 2015 at 5:59 AM, Christopher Robert <crobert@surveycto.com wrote:
So just to be clear, the "fix" we're testing here reverts the entire
context within that populateDynamicChoices() function, to be the field
instead of the parent -- so the effects are potentially much wider than
just what current() returns. Potentially anything and everything that
depends on context can change now, since the context will shift from parent
to field.

This means that we revert a change from 5 years ago and alter the context
from now on. Neither Meletis nor I feel terribly confident that we can
entirely predict the consequences to backward compatibility. We're testing
the things we can think to test, but honestly it's XML users in the broader
ODK community who face the greatest risks here; SurveyCTO users by and
large use XLSForm and thus the potential XPath syntax consequences are
sharply limited.

Are you guys very sure that you want to take this path? I can tell you
now that if we make this change and then there is some outcry after the
next ODK Collect release, SurveyCTO Collect will very likely stick with the
new change (since we will have changed pyxform and we'll then have too many
backward-compatibility concerns to then reverse the change).

Thanks,

Chris

On Mon, Nov 23, 2015 at 5:23 AM meletis@surveycto.com wrote:
Just for the history's sake, I found the time where the behavior
changed. It was at March 11, 2010:

https://bitbucket.org/m.sundt/javarosa/commits/b41875b2c23c9a21a868a5d2dc0ffc1f6b5b0b65#Lcore/src/org/javarosa/core/model/FormDef.javaT635

Take a look only in the changes of the "populateDynamicChoices" method.
The context reference used to be the "current" field, but after the changes
above it started be the field's parent (by adding getParent()). Perhaps
there was a reason for that change, but perhaps not, but I think all of us
agree that this should be fixed, even after 5 and a half years.

Meletis

On Monday, November 23, 2015 at 12:08:47 PM UTC+2, mel...@surveycto.com wrote:
Hi Mitch,

Please take a look at the code comment in line 31 here:

https://bitbucket.org/m.sundt/javarosa/src/bf17fb749b74e53915f086ca3827c3c6fe73fd07/core/src/org/javarosa/core/model/ItemsetBinding.java?at=default&fileviewer=file-view-default#ItemsetBinding.java-31

It clearly says: "ref of the control parent (group/formdef) of
itemset question"

So, for some reason, they wanted it to point to the parent. I also
see that when the dynamic choices are populated, the evaluation context is
wrapped around that parent (contextRef object), that's why current() refers
to the parent group when evaluating itemsets nodesets.

I will run a few tests by changing the contextRef field value, I just
wanted to mention that in case you remember a reason for that code comment.

Meletis

On Friday, November 20, 2015 at 8:49:12 PM UTC+2, Mitch wrote:
Yes, I think it should be a one-line change; just don't know where.

Mitch

(I do jar-updates over Christmas / New-Years. Tedious, but doesn't
require a whole lot of attention.)

On Fri, Nov 20, 2015 at 10:36 AM, mel...@surveycto.com wrote:
Hi Mitch,

Thank you for all the details, I guess I was missing some of the
context of the original issue.

We will give it a shot to see if we can come up with a few ideas how
to fix the evaluation content of the itemset nodeset. I just hope it will
not be like last year with the "form processing logic" in JR, otherwise I
believe that every Christmas will be a JR Christmas.

Meletis

On Friday, November 20, 2015 at 7:29:14 PM UTC+2, Mitch wrote:
The form was attached in one of my earlier replies.

On Fri, Nov 20, 2015 at 9:27 AM, Mitch Sundt mitche...@gmail.com wrote:
And you see this in constraint expressions where you write:

. > 6

I.e., current()/. should refer to the field, and not the group
containing the field, as it currently does when evaluating expressions in
the itemset nodeset.

On Fri, Nov 20, 2015 at 9:26 AM, Mitch Sundt mitche...@gmail.com wrote:
The issue is that there is a discrepancy in the meaning of '.'
across the different contexts of: calculate, relevant, , and these
itemset nodeset expressions.

In other usages, you need to reference this other field with
current()/../filterfield ; but in the nodeset expression, you would
reference it with current()/./filterfield

I.e., the notion of '.' is different when used within a nodeset
expression and when used within a constraint expression or an
field.

See the attached NBiggestOfSet form. For the label, it has:
    <select1 ref="/NBiggestOfSet/education/edu_level">
      <label>What is <output value="
current()/../referred_attendee_name"/>'s level of
education?
...

For a constraint, it has:

These each use the current()/../ to reference the group (
/NBiggesetOfSet/education ).

But, within the nodeset definition (if this form used one), you
would need to use current()/./referred_attendee_name to
reference a field in that group.

On Fri, Nov 20, 2015 at 8:22 AM, mel...@surveycto.com wrote:
Hi Mitch,

I think I'm missing something but I think that nothing is broken
and that the only issue is that the expression current()/../filterfield in
your example above should be just changed to current()/filterfield. If you
make that change, everything should work because it will be resolved to:

/data/group1/filterfield

Why should a "../" be present there? We have used
current()/somefield successfully in one of our test forms and it works
fine. And I think it would also work great in your example. Wouldn't it? Or
am I totally out of context?

Meletis

On Friday, November 20, 2015 at 5:35:16 PM UTC+2, Mitch wrote:
Hi Meletis,

That's not the issue --

The issue is that if you use a filter condition in the
nodeset specification of a field "myfield", within that nodeset
specification "current()/.." refers to the parent of the group enclosing
the "myfield" field. It does not refer to the group enclosing the
"myfield" field.

So if you have
a 4 fish b 14 fish ...
and if you have:

This will currently be broken. Because
current()/../filterfield,
when evaluated within the itemset nodeset specification, is
resolved to:

/data/filterfield

instead of

/data/group1/filterfield

On Fri, Nov 20, 2015 at 1:58 AM, mel...@surveycto.com wrote:
Well, I think there is a fundamental issue here regarding
current() syntax. Please, let me remind you how JR works with "current()":

The expression "current()" looks like a function but it is
not treated like one; it is not handled by the XPathFuncExpr class, so, if
you try to use it alone you will get an error that the "function" is not
supported. In other words, you cannot use it alone in an expression in
order to refer to the "current" field.

When an expression includes "current()", then it ALWAYS
needs to be used in an XPath, actually, the expression needs to BE an XPath
expression, so that it can be handled with the XPathPathExpr class. For
that reason the expression NEEDS to contain at least one "/".

Taking 1 and 2 into consideration, the ONLY way to refer to
the "current" field (named "somefield") is to use "current()/." or
"current()/somefield". So, I looks like that the original implementation
was "okay" in the sense that the "current()" should only be used in XPaths.

If we wanted to have "current()" refer to the current field, I
believe we should introduce a new function handler in XPathFuncExpr class.
Please let me know if this would work:

A. Whenever the "current()" expression is used inside an XPath,
then the current code would be used as it is used right now (maintaining
backwards compatibility), so that it will still be referring to the
enclosing group, not the field itself.
B. Whenever the "current()" expression is used inside a
non-XPath, then the new code would be used (in XPathFuncExpr) and that
would be evaluated in a way that the current field would be
returned/referenced, NOT the enclosing group.

That way, the following code could work, because it wouldn't
throw the "unrecognized function" error:
label .... ....
What do you think about that approach?

Meletis

On Friday, November 13, 2015 at 11:38:15 PM UTC+2, Martijn van de Rijdt wrote:
Hi,

I'd like to ask for a clarification about the current() node
in an XPath predicate. It seems JR considers this to be the
parent node of the current question. (Thanks to Chris for
sharing this.)

E.g. in this question below, current() equates to /data/group
and not to /data/group/options. I would have expected it to be the latter.
....
    <label>label</label>

    <itemset nodeset="instance('crop_list')/root/item[name
= current()*/../*crop]">
         ....

         ....

    </itemset>
Is this by design? Or is it a bug?

We ran into this by realizing that the seemingly more
intuitive predicate [name = current()*/../../*crop] is not
working.

See this form
https://docs.google.com/spreadsheets/d/1A74yEHRxQF1zbIcQSrwvZydggUU7m5T3ZAnlR6_TLA4/edit#gid=0
that illustrates the behaviour nicely. If current() is used in a
calculation (even if it makes no sense to do so) this extra step down is
not taken, but in a predicate it is. So it seems the behaviour is not
related to the current() function but to how predicates are handled in JR.

Thanks,
Martijn

--
--
Mitch Sundt
Software Engineer
University of Washington
mitche...@gmail.com
--
--
Mitch Sundt
Software Engineer
University of Washington
mitche...@gmail.com
--
Mitch Sundt
Software Engineer
University of Washington
mitche...@gmail.com
--
Mitch Sundt
Software Engineer
University of Washington
mitche...@gmail.com
--
You received this message because you are subscribed to the Google
Groups "ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
Mitch Sundt
Software Engineer
University of Washington
mitche...@gmail.com
--
You received this message because you are subscribed to the Google
Groups "ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com

--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com