I don't see any reason why it they wouldn't be. It's explicit, generic and follows the xform way for doing things.
I honestly don't get why Dimagi chose pollsensor. Seems like something generic but their spec clearly says it's used to set geopoint value of the current location. I opt for the explicit name.
@LNsetlocation is the best name for this I've seen so far It's a good point though to maintain compatibility but it seems like Dimagi's spec doesn't support action nested inside the input element, does it?
If so, then potential compatibility would be only partial, right? Forms following Dimagi's spec would work in with ODK XForm implementations but forms following ODK XForm spec using nested actions wouldn't work with the Dimagi implementation. In such situation I think adding an alias as you suggested may be the best approach.
You're right. So maybe we shouldn't worry too much about compatibility there since we're going for a more complete implementation anyway.
I had another thought. Is introducing a new action really the right way to do this or would it make more sense to introduce a new function? That would be something like here() by analogy to now().
Very interesting and creative! That actually may make more sense than introducing a custom action which would be doing basically same thing as setvalue but limited to geopoint values. And could be used with conditional logic, mixed with other functions etc.
I agree this feature would be a welcome addition. I think the custom XForms action <orx:setlocation> is the way to go instead of an XPath function, because obtaining a location can be assumed to an asynchronous operation, which would be very problematic in an XPath evaluator (it would have to block until a response is received or timeout has passed).
We should also think about the value to return when it is not possible to obtain the location. This should be assumed to be quite likely to happen, due to technical issues, lack of user permission (in a browser, OS), or context (http instead of https in a browser). I haven't given this much thought yet, but "NaN NaN NaN NaN" (yeah, that's ugly) comes to mind following the error response of a Number Function in XPath.
Agreed, the here() concept was a bit of wishful thinking on my part! I could go either way on getlocation vs. setlocation. My argument for getlocation would be that this is also useful without a ref to trigger GPS in anticipation of a foreground reading (warming, basically).
That sounds good to me; I can't think of a better option.
There is a proposal for bringing this to XLSForm here.
I reviewed the @TAB call notes and saw that there was talk of changing the action name to setgeopoint for consistency with the geopoint type. That would be fine by me. I do like that it might leave space for introducing an alternate geo type with a different format as has previously been discussed.
I didn't listen to the call -- was it a done decision or more of an idea for another round of discussion?
Sounds like it may have been confusing all around. I'm really sorry I can't attend!
What do you think about changing the action name, @martijnr? I don't think anyone feels super strongly one way or the other. The most compelling argument for me is that we may eventually change the canonical "location" format and so setgeopoint keeps things more consistent in that case.
If you're on board, I think you can just issue another spec PR to change the name.
Presumably javaRosa/Validate will check the target element binding is a geopoint, and throw an error if not? Or are we just going to dump the geopoint string into whatever the ref happens to point to...?
I don't think the target element type should be enforced. I can see reasons to use geotrace or geoshape types and possibly even string, all of which would be valid. What do you think?
However, pyxform would only ever generate a geopoint node as the target.
I certainly dont see a reason to enforce checking it during runtime in Collect. At most maybe its something to add to Validates laundry list of checks, someday... As you say, getting pyxform to always generate a geopoint target will probbaly ensure 99% of the time its moot.