XSLTForms/XForms 1.1

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

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.)

Differences between XForms 1.0 and XForms 1.1[edit | edit source]

Introduction to XForms[edit | edit source]

Document Structure[edit | edit source]

  • In XSLTForms, the XHTML src attribute 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:instance to 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.]

Processing Model[edit | edit source]

  • 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 navindex or accesskey attributes.
  • In XSLTForms, event handling sometimes deviates from the letter of the spec. Cases include the following.
    • Some tests written to trigger an xf:message action 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.)
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.

Datatypes[edit | edit source]

  • 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[edit | edit source]

  • 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.)
  • The p3ptype property is not implemented.

XPath Expressions in XForms[edit | edit source]

  • XPath allows whitespace between tokens (so a/b/c[@x='y'] and 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 textarea control 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.

Unrecognized namespace prefixes[edit | edit source]

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.

For longer examples see the wikibook XSLTForms and eXist and the discussion of user-defined functions in this wikibook.

Core Form Controls[edit | edit source]

  • mediatype is not supported on file uploads.
  • Both start and end attributes are required, not optional, on range controls in XSLTForms. The incremental attribute does not work as expected.
  • On the xf:help, xf:hint, and xf:alert elements, XSLTForms does not support the ref attribute. 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:setfocus action 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 startindex or number attributes of the repeat element.

The output Element[edit | edit source]

  • The output control supports the values application/xhtml+xml, image/svg+xml, and image/* for its mediatype attribute.
  • The control is implemented in Javascript using the .innerHTML property of DOM nodes.
  • application/xhtml+xml can 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 serialize(node).

The upload Element[edit | edit source]

The 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[edit | edit source]

  • The attributes repeat-model repeat-bind, repeat-nodeset, repeat-startindex, and repeat-number do not behave as expected.
  • The xf:copy element does not behave as expected.

XForms Actions[edit | edit source]

  • 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 insert and delete actions sometimes work as expected and sometimes not.

The XForms Submission Module[edit | edit source]

  • Several attributes of the xf:submission element are not supported: indent, encoding, standalone, cdata-section-elements, invalid, separator.
  • 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[edit | edit source]

XForms and Styling[edit | edit source]

  • The CSS pseudo-classes enabled and disabled are supported; other pseudo-classes (required, optional; valid, invalid; read-only, read-write; out-of-range, in-range) are not supported.
  • The CSS pseudo-elements value, repeat-item, repeat-index are not supported.

See also the chapter on XSLTForms and CSS.

Complete XForms Examples[edit | edit source]

  • XSLTForms does not support SVG as the host document language.