To avoid hard-to-explain problems when designing and testing templates, the following advice may be of some use:
It is not necessarily a good idea to nest elements inside multiple-choice elements like this:
<multi>
<multi-enum value="1"/>
<multi-enum value="1"/>
<multi-enum value="1"/>
<nested value="x"/>
</multi>
The reason for this is that the number of multiple-choice values may vary within your application, and the nested elements will appear at a different position depending on how many such values have been inserted. Whilst this might not affect some applications, at least not to begin with, the usage of more advanced features (selectors, for example) will probably expose problems due to the way XSLForms reconstructs the XML document data from the input form data.
Since XSLForms templates essentially describe the presentation of an XML document, it is vital that the output form data structure agrees with the template - that is, the output structure can be properly processed by the template and that all parts of the template are displayed as expected. It is also very important to make sure that transformations on the input document produce all the necessary elements for the output document so that the resulting page gives the user the opportunity to specify data that is missing. Consider this section of an example template:
<p template:element="package">
<p template:element="author">
Name: <input template:attribute="name" name="{template:this-attribute()}" type="text" value="{$this-value}"/>
</p>
</p>
Here, if the author
element is not found in the
output structure, no field will be produced in the Web page, no
opportunity will be given for an author to be specified, and no author
information will subsequently be editable. One solution is to introduce
the author
element into the XML document when
creating the package
element - this should then
"bootstrap" the process and ensure that the author details will remain
editable as long as the package
element exists.