We'd like to have a clear, coherent specification path to the odk-new-repeat case before any implementation begins. If you'd like to take on implementation of a subset of the spec we agree on, that would be fine.
I believe this case is already addressed by the default column in a repeat: if there's a dynamic expression in the column, pyxform generates a setvalue action.
Yes, after giving this some more thought, I still think this is our best bet out of the ideas considered so far. When we were first considering how to expose events and actions in XLSForm we discussed whether to expose the raw concepts or whether to try to expose something more related to users' end goals.
Like you mention, it's a tradeoff between ease of use and flexibility. We ultimately decided to try to capture the spirit of the specific problems an action is introduced to address. For example, setvalue is about setting defaults that users can override (we don't have things like user-specified buttons like W3C XForms and are unlikely to) and setgeopoint is about capturing locations in the background as a kind of metadata. If we introduce any other actions, we imagine they are likely to similarly have specific use cases that can be exposed as such.
That's how we ended up with start-geopoint and I continue to think bg-geopoint fits in nicely with that model.
Yes, I imagine bg-geopoint would require a reference in the trigger column and not allow values in any other column other than name. There would likely be an exception if we use bg-geopoint for the odk-new-repeat event case.
But what I wrote above about setvalue in repeats made me think that we could consider doing something similar for capturing background location at the start of a repeat. Instead of using the new bg-geopoint type, we could use the existing start-geopoint and say that if it's in a repeat, it captures the location when the repeat instance is created.
I think using bg-geopoint for this would also work -- if it's in a repeat, trigger would be optional. I don't currently have a strong preference between the two and feel satisfied that the general bg-geopoint approach would give us a path to the odk-new-repeat event case whenever that gets implemented.
@Lindsay_Stevens_Au I'd appreciate your sanity check on this thread! Maybe you see advantages to the action column that @Xiphware suggested that I'm missing? Or possible challenges with introducing a bg-geopoint type?