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
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:instanceto 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
bindelements. XSLTForms raises an error if more than one
bindelement 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
- XPath allows whitespace between tokens (so
a /b /c [@x = 'y']are equivalent, and the blanks in the latter form can be replaced by newlines and more whitespace; the XPath parser in XSLTForms accepts whitespace only in very restricted locations, including predicates, but not within location paths.
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
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/xhtml. Forms served as
text/htmlwon'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
.htmldoesn't work, try
- 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
mynsto 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
pelements; use XHTML
divelements to wrap them, instead. (Reason: XSLTForms generates XHTML
divelements for alert messages and the like; these interact badly with containing