Current() in XPath predicate

[martijnr]

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.

<input ref="/data/crop">

    ....

</input>

<select1 ref="/data/group/options">

        <label>label</label>

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

             ....

             ....

        </itemset>

</select1>

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

[crobert]

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 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.

[Meletis]

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:

<select1 ref="/data/group/options">
<label>label</label>
<itemset nodeset="instance('crop_list')/root/item[name = current()]">
....
....
</itemset>
</select1>

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_S]

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]

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]

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]

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()":

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>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]

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]

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]

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]

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()":

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>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]

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]

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()":

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>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]

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]

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()":

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>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]

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]

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]

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()":

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>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]

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]

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, 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 >> >