XSLTForms/Known Restrictions

From Wikibooks, open books for an open world
Jump to: navigation, search

This page lists gaps in XSLTForms' coverage of the XForms 1.0 and 1.1 specifications, and other restrictions that may not be obvious to new users.

(In its current state the page is not at all complete or systematic, but a list of things that have caught the eye of some user or other, who has listed them here. Please help make the list more complete and more useful to new users of XSLTForms, by recording here any limitations you encounter and ways to work around them.)

Gaps and limits in coverage[edit]

These are cases where XSLTForms falls short of perfect conformance to the spec, so that forms which are strictly speaking legal and which work in other XForms processors may not work in XSLTForms.

  • XML comments in instance are supported but they should not contain any greater-than signs (>).
  • The built-in datatypes gYear, gYearMonth, date, and dateTime support only four-digit years beginning with the digit 1 or 2, so dates like (for example) 0800-12-25 (Christmas Day, AD 800, Charlemagne crowned emperor) are not accepted.
  • gYear, date, etc. do not accept time-zone information, so a date like 2010-08-01 (1 August 2010) is accepted as valid, but not 2010-08-01Z (the 24-hour period beginning at 00:00 on 1 August 2010 in UTC) or 2010-08-01-04:00 (the 24-hour period beginning at 00:00 on 1 August 2010 in Eastern Daylight Time).
  • The XForms spec allows the xf:instance to be omitted entirely from the model; a very simple flat XML structure is then assumed. XSLTForms requires an explicit instance.
  • The XForms spec says that "It is an error to attempt to set a model item property twice on the same node"; this can be read as allowing different model item properties to be set on a node from different bind elements. XSLTForms raises an error if more than one bind element affects the same node, even if they are setting different model item properties. (Workaround: set all model items properties for any node in a single bind element.)

A fuller sense of current gaps in conformance can be obtained by looking at the XForms 1.1 test suite results for XSLTForms. (Warning: that page is updated only infrequently and is not necessarily current.)

Quirks, idiosyncrasies, and things you might not expect[edit]

These are things that are not strictly speaking XForms conformance issues, but which may cause some head-scratching or which may work differently in different XForms processors.

  • Forms served from an HTTP server should have a MIME type of application/xml, text/xml, or application/xhtml. Forms served as text/html won't work (browsers don't apply XSLT stylesheets to HTML documents).
  • Forms loaded from a local file system will or won't work, depending on what MIME type the browser associates with the file extension. If .html doesn't work, try .xhtml or .xml.
  • As a workaround for FireFox not supporting namespace axis in its XSLT engine, there are some situations where a dummy element or attribute must be added somewhere in the XForms document to make it possible to extract the prefix / namespace binding. One example: If an external instance uses a namespace not used within the XForm document itself, it will be necessary to declare the instance's namespace and use it in the form, e.g. by adding xmlns:myns="http://example.org/foo" myns:dummy="it doesn't matter what goes in this attribute" on the root HTML element. (This allows XSLTForms to locate the binding of prefix myns to the namespace in question.) For longer examples see the wikibook XSLTForms and eXist and the discussion of user-defined functions in this wikibook.
  • Controls sometimes malfunction if placed within XHTML p elements; use XHTML div elements to wrap them, instead. (Reason: XSLTForms generates XHTML div elements for alert messages and the like; these interact badly with containing p elements.)