This page discusses XSLTForms' coverage of the XForms 1.1 specification, and mentions some 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.)
XSLTForms implements most of XForms 1.1 but is not a fully conformant processor, for two reasons:
- Some restrictions are imposed on XSLTForms by client-side limitations in Web browsers.
- Lack of time has led to the omission of some "minor" features in favor of extension functionality with higher priority for users (e.g. rich-text editors).
The sections below identify particular points on which XSLTForms may differ from the specification or from other implementations of XForms 1.1. The sections correspond to the organization of the XForms 1.1 spec and test suite; some headings have been changed for clarity. Unless otherwise specified, the version described is 1.0RC2 (2014). Some gaps may have been filled, and some limitations removed, in later versions. (This has been noted in some cases, but the absence of a note does not mean there has been no change.)
A fuller sense of current gaps in coverage 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.)
- 1 Differences between XForms 1.0 and XForms 1.1
- 2 Introduction to XForms
- 3 Document Structure
- 4 Processing Model
- 5 Datatypes
- 6 Model Item Properties
- 7 XPath Expressions in XForms
- 8 Core Form Controls
- 9 Container Form Controls
- 10 XForms Actions
- 11 The XForms Submission Module
- 12 Insert and Delete Action Patterns for Data Mutations
- 13 XForms and Styling
- 14 Complete XForms Examples
Differences between XForms 1.0 and XForms 1.1
Introduction to XForms
- In XSLTForms, the XHTML
srcattribute cannot be used to link to non-XML page-external resources. So XSLTForms does not support constructions like
<xf:label src="mylabel.txt"/>; the XSLT 1.0 processors in browsers cannot read non-XML resources.
- XML comments in instance are supported but they should not contain any greater-than signs (>).
- 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.
- [This was true in 2010; is it still true, or has the 'simple XForm' structure been implemented? Tests needed. Note that XSLTForms 1.0RC2 passes test 3.3.2.a.]
- XSLTForms can load at most one external schema document per namespace; attempts to load multiple schema documents for the same namespace will raise an XForms link exception.
- XSLTForms does not implement support for the
- In XSLTForms, event handling sometimes deviates from the letter of the spec. Cases include the following.
- Some tests written to trigger an
xf:messageaction when particular events occur do not in fact display a message. The events in question include: xforms-help and xforms-hint; in-range, out-of-range; scroll-first, scroll-last, xforms-binding-exception; xforms-enabled, xforms-disabled. (It is not clear from the test results whether this is a problem is a failure to raise the expected events or a failure of the xsl:message action to respond to them as expected.)
- Some tests written to trigger an
- N.B. in version r638, some of these tests produce the expected results, including tests for: scroll-first, scroll-last, xforms-binding-exception.
- In some tests, XSLTForms does not raise the expected exception but a different one.
- In some tests, errors in the form which should raise exceptions (e.g. xforms-compute-error or xforms-binding-error) raise none. (In later testing with version r638, XSLTForms passes these tests.)
- Some exceptions should be fatal errors but are not, in XSLTForms.
- In some cases, the browser freezes instead of XSLTForms raising the expected exception or a fatal error.
- Some events are signaled even when
incremental="false"entails that they should not be, or when they are unnecessary because a value has not changed.
- 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).
Model Item Properties
- 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
p3ptypeproperty is not implemented.
XPath Expressions in XForms
- 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. [This limitation may have been lifted in 2016; tests needed.]
- XSLTForms 1.0RC2 does not support the hmac() function, or the use of sha-256 in the digest() function. (Later versions support both).
- In some cases, XSLTForms calculates the wrong context size.
- XSLTForms is sometimes laxer in type validation that the spec prescribes.
- No error is raised when a
textareacontrol is bound to an element with a complex type. (Instead, the string value of the element is made available for editing in the control.)
- No error is raised when the parameters of a control do not obey the data binding restrictions.
- No error is raised when a
Unrecognized namespace prefixes
In some circumstances, XSLTForms will fail to evaluate XPath expressions correctly because it fails to recognize a namespace prefix, even though it has been correctly declared. The circumstances are:
- XSLTForms is running in Firefox or another Mozilla-based browser.
- The namespace prefix is not used on any element or attribute in the form itself. This may occur if the instance document using the namespace is external, and an XPath expression in the form refers to elements in that instance document.
The cause of this behavior is that the Mozilla XSLT engine does not support the
namespace axis; this has been reported as a bug, but has not been fixed.
A simple workaround is to insert a dummy element or attribute somewhere in the XForm which uses the namespace prefix in question. It is not uncommon to place these on the first tag of the XForms document, together with namespace declarations for all prefixes to be used in the document. (Making an XForms template with a relatively complete set of namespace declarations saves a good deal of debugging time later.)
<html xmlns="http://www.w3.org/1999/xhtml" xmlns:xf="http://www.w3.org/2002/xforms" xmlns:xi="http://www.w3.org/2001/XInclude" xmlns:ev="http://www.w3.org/2001/xml-events" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xhtml="http://www.w3.org/1999/xhtml" xsd:dummy="Help the poor user of Mozilla evade the Mozilla namespace curse" xhtml:dummy="Help the poor user of Mozilla evade the Mozilla namespace curse">
The local name and value of the dummy attribute are immaterial; the purpose of including the dummy attribute is to ensure that XSLTForms can create a table of namespace prefixes by traversing the ancestors of an element and noting all the namespace prefixes actually in use.
Core Form Controls
mediatypeis not supported on file uploads.
endattributes are required, not optional, on
rangecontrols in XSLTForms. The
incrementalattribute does not work as expected.
- On the
xf:alertelements, XSLTForms does not support the
refattribute. When multiple hint or alert messages are provided, XSLTForms assigns precedence to inline messages, rather than hints in the instance pointed to by single node binding attributes.
- When the
xf:setfocusaction is called to set the focus to a group, the focus is not set to the first control in the group; focus is cleared.
- XSLTForms 1.0RC2 does not support the
numberattributes of the
outputcontrol supports the values
.innerHTMLproperty of DOM nodes.
application/xhtml+xmlcan also be used for HTML tag soup (XSLTForms does not check whether the content is valid or not)
- The content is treated as serialized (X)HTML, i.e. just text (not CDATA) from the XML point of view, to be serialized with < and > entities for tags
- To be displayed with tags, an instance element has to be serialized with the XPath function
upload control has historically been difficult for XSLTForms to support (the very first message to the XSLTForms support mailing list was about gaps in the support of
upload. The XForms specification for the control requires more functionality than the AJAX libraries used by XSLTForms readily provide.
[Some discussion of using xf:upload, what does work out of the box and what doesn't, needed here or in separate page.]
A modified version of XSLTForms that supports the "form-data-post" submission method is available (February 2017) at https://github.com/Conal-Tuohy/Muscovy/tree/master/xsltforms
Container Form Controls
- The attributes repeat-model repeat-bind, repeat-nodeset, repeat-startindex, and repeat-number do not behave as expected.
xf:copyelement does not behave as expected.
- Events do not always behave as specified (see Processing Model, above).
- Resets and updates may be deferred instead of executed immediately; tests of various attributes on the
deleteactions sometimes work as expected and sometimes not.
The XForms Submission Module
- Several attributes of the
xf:submissionelement are not supported:
- A number of features of the XForms submission module cannot be supported owing to cross-domain restrictions in the browser.
Insert and Delete Action Patterns for Data Mutations
XForms and Styling
- The CSS pseudo-classes
disabledare supported; other pseudo-classes (
in-range) are not supported.
- The CSS pseudo-elements
repeat-indexare not supported.
See also the chapter on XSLTForms and CSS.
Complete XForms Examples
- XSLTForms does not support SVG as the host document language.