URL widget does not allow sites that has dash(-) on the URL

1. What is the problem? Be very detailed.
I have a form where I want to include URL where users can click and go to my site. The URL is included on default column and under default column if you include data with dash(-) it throws error when uploading the form to aggregate servers i.e ONA.
When I include a URL that does not have dashes(-) it works well.
Is there a way you can include an exception when using URL widget one can include a URL with dashes?
2. What app or server are you using and on what device and operating system? Include version numbers.

3. What you have you tried to fix the problem?

4. What steps can we take to reproduce the problem?
Upload the attached sample form and see the error.
Try to change the URL under default to a different URL like https://getodk.org/xlsform/ and upload again.t4 - Copy - Copy.xls (59 KB)
5. Anything else we should know or have? If you have a test form or screenshots or logs, attach below.

Thanks so much for reporting this! It's definitely a bug and it's documented at https://github.com/XLSForm/pyxform/issues/495.

1 Like

For the moment, you can wrap any value with a dash that you want to use as a default in a call on the string function. For example, string('https://some-url.com'). This will continue working once we fix the bug so you won't need to update your form again.

2 Likes

Perhaps get pyxform to wrap everything that is almost always a literal with string(...)? I'm not sure there is a general solution when the form input can (and should?) be being directly interpreted as a potential XPath expression (other than calling it out to form writers...) :man_shrugging:

Exactly, we've ended up here by attempting to deal with the problem in reverse. The single XLSForm default column handles static and dynamic defaults by converting them to very different XForms structures. In the static case, the literal value is written as the instance node value. In the dynamic case, there's a setvalue action triggered by odk-instance-first-load. We decided to go with a single default column because that's a lot easier for users to think about. Our heuristics for identifying static vs. dynamic expressions are fairly simplistic and particularly have trouble with - which can be a text separator, a numeric sign or an arithmetic operator.

Some additional cases that are currently incorrectly identified as dynamic expressions:

  • 1-1 as an select option name (yes, that's legal)
  • 623 / 5 as a literal string value
  • 12.371400 -1.519700 305 17.4 as a literal geopoint value

The url from this thread and the geopoint value we can probably detect as being static but the other two above are examples that probably aren't worth pursuing. We could use the field type to make a better guess but I think it's too much complexity to be worth it.

1 Like

If we can handle it upstream in the pyxform translation - eg wrapping things in string() - then perhaps we can throw some warnings as to assumptions being made. But, hopefully obviously, I'd be loath to push any such heuristics down into the XForm client/widget itself.

1 Like

This is already what's going on with the decision I described to treat a default as dynamic (XPath expression) or static (XPath literal). The string() solution is to handle cases that are mis-identified as dynamic and to force a literal value to be used. I think that has to be manually applied and the best we can do is provide documentation. I don't think it would make sense to provide a warning because many forms use many defaults without hitting this.

Thanks @LN string function works.
Let me know when the issue is solved

1 Like