10.4 Troubleshooting | Xforms Essentials

10.4.1 Stubborn Read-only Controls

If all your form controls appear mysteriously read-only (or even completely missing, depending on style sheet configuration), check the namespace of instance to make sure it's not in the XForms namespace. For example, the following code looks innocent enough, but has an error.

<model xmlns="http://www.w3.org/2002/xforms">   <instance>     <purchaseOrder>       <item/>     </purchaseOrder>   </instance> </model>

The problem is subtle: the purchaseOrder element is appearing in the default (here XForms) namespace, which can't be right, since XForms doesn't define a purchaseOrder element. When declared this way, none of the binding expressions actually point into the instance data because of the difference in names. The result: all form controls behave as if they were read-only.

The correct thing to do is to put the purchaseOrder in the proper namespace with an xmlns declaration. Even if the instance data is not in a namespace, then the special declaration xmlns="" must be used to undeclare the default namespace, like this:

<model xmlns="http://www.w3.org/2002/xforms">   <instance>     <purchaseOrder xmlns="">       <item/>     </purchaseOrder>   </instance> </model>

Of course, if the instance data is in a specific namespace, then the code above would need to contain the namespace URI instead of an empty string.

10.4.2 Context Node Problems

Another problem that can cause individual form controls or groups of form controls to misbehave is forgetting what the XPath context node is in a given situation. The default rules for context nodes make the common cases the most straightforward, though more advanced work remains tricky. An incorrect assumption about what the context node is will typically cause an XPath expression to select an empty node-set, which is an invalid binding for a form control.

The basic rule is that the context node starts out at the top-level element node. If instance data resembles this:

<top-level>   <child>     <grandchild>   </child> </top-level>

then the proper way to bind to grandchild as the default instance is either of the following, using relative and absolute paths respectively:

bind="child/grandchild" bind="/top-level/child/grandchild"

The same goes for references using this instance( ) function. The default context node is the top-level element node. Thus, the way to bind to grandchild in a non-default instance is the following:

bind="instance('elsewhere')/child/grandchild"

Note that references to non-default instances don't have a direct analogue to an absolute path.

10.4.3 XForms Portion of Document Not Recognized

Another common situation can cause XForms readers to malfunction: most HTML (and even XHTML) documents are served with a media type of text/html, which is never appropriate for a document containing XForms. One workaround is to define a new file extension, .xhtml, for all XHTML documents, then configure the web server to deliver those files with a proper media type of application/xhtml+xml. On some web servers, this can be done by adding to (or creating, if necessary) a file named .htaccess in the root directory for documents, containing this line:

AddType application/xhtml+xml;charset=utf-8;qs=0.999 .xhtml

10.4.4 Schema or Validation Errors

In XForms 1.0, it is almost always an error to bind a form control to an element node that can have other element children. This mistake is easy to make in some XML vocabularies. For example, in UBL, the XML structure for containing line item part numbers is:

 <cat:OrderLine>     <cat:Item>       <cat:SellersItemIdentification>         <cat:ID>Enter part number here</cat:ID>

It is easy to mistakenly think that the element named SellersItemIdentification is a container for part number data when, in fact, the child element ID is. Thus, an erroneous UI binding expression like this:

  <xforms:input ref="cat:OrderLine/cat:Item/cat:SellersItemIdentification" ...>

will create mixed content, with text followed by the still empty ID element. This will cause either data loss, when a downstream process doesn't find the data where expected, or a more immediate Schema validation error, when text is detected in a location where it doesn't belong.