Filename of XLSForm export should be XML compliant about build HOT 15 CLOSED

I think exactly those restrictions are why I generate the name as described:

I prefix with build_ so that the leading character cannot be a number.
I postfix with the timestamp because aggregate chokes if multiple forms have the same ID and people were having problems with that.

If you'd prefer risking the user's own input I'm happy to go back to that behaviour.

from build.

I think my reference to the form ID confused things!

If you have a form name 1 Form and you export it, you get 1-Form-export. This XLSForm, when converted with pyxform will fail because 1-Form-export is used as the name of an XML node and nodes cannot start with a number.

Is it possible to add validation to form names?

from build.

I'm just going to prefix a _ if I see a leading number. Cool @yanokwa ?

from build.

Hmm. Why not use validation on the names?

from build.

1. Completely different part of the code.
2. A 100% valid Build=>XML=>Aggregate=>Collect filename would be rejected simply because Build=>XLSForm could theoretically fail.
3. Already-saved forms will load up and immediately flag red.
4. It's a really confusing limitation to explain; see 2.

from build.

@lognaturel had an alternate idea. Given that the form is valid, maybe we should file this as an issue against pyxform and it should handle numbers more gracefully.

from build.

I'm okay with either! This is a pretty simple change on this side, though. Just catch XLSForm files on their way out the door and subst the attachment meta name.

from build.

I'm happy with leading numbers being prepended by _.

from build.

I've filed this upstream: XLSForm/pyxform#130. I propose we hold off on a fix until the pyxform team has a chance to respond.

from build.

This is still a trivial one-line change on our side. I'm happy to do it or to do nothing; please advise! :)

from build.

I say do nothing for now. I'd rather fix this upstream.

from build.

Okay, removing from the milestone.

from build.

Just to document current behaviour, a form "Test040" will be exported by build2xlsform v1.6 as "Test040-export.

Leading with the (sanitised) form title seems OK now.

I could even live (better) without the "-export" postfix because 1. the file extension clarifies the form standard and 2. including the exported form in R packages throws an error and I have to manually remove the -export from each file. The latter is an edge case that probably not many users suffer from.

Update: PR #266 changes this to "Test040.xslx".
Update 2: PR #271 could include #267 which might resolve this issue here.

@yanokwa is this issue addressed?

from build.

To document current behaviour, a form named "290test4" exports to "290test4.xslx" (no errors) with an internal form title and form id of "290test4". Uploading that to ODK Central (1.3) throws no errors.
Converting the XLSForm back to XLS also seems to work, no errors are raised:

<?xml version="1.0"?>
<h:html xmlns="http://www.w3.org/2002/xforms" xmlns:ev="http://www.w3.org/2001/xml-events" xmlns:h="http://www.w3.org/1999/xhtml" xmlns:jr="http://openrosa.org/javarosa" xmlns:odk="http://www.opendatakit.org/xforms" xmlns:orx="http://openrosa.org/xforms" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
    <h:head>
        <h:title>290test4</h:title>
        <model odk:xforms-version="1.0.0">
  [...]
            </itext>
            <instance>
                <data id="290test4" version="1643329150">
...

Does that mean that form titles beginning with numbers are now handled well on the XLSForm side, and this issue here can be closed?

from build.

Ah yes indeed! The file name used to be used as the node name for the child of the instance. Now it's always data.

from build.