Table of Contents
"Still, what an arm! and I could alter it: But all the play, the insight and the stretch—Out of me, out of me!"
To wrap up this book, this chapter will delve into the ways that XForms can be extended. Conventional HTML forms, in contrast, offered hardly any methods of extensibility, other than script and some vague wording about how the object element could be used as a form control. With XForms, extensibility is a core part of the design, which will be a key asset as the focus shifts from Version 1.0 of XForms to later versions.
Extensibility is usually talked about as an obviously advantageous feature—but it has a dark side, too. The easier it is to extend a system, the harder it is to make two separate implementations of that system agree on how to behave. Perhaps this is why many standards have a tendency to have extremely complicated, feature-rich formulations in Version 1.0: fear that anything not present from the beginning will never come to pass. The customary behavior in XML applications is to ignore elements and attributes that are unknown. In many cases this works great, but other times the uncertainty of whether an element will be ignored can range from annoying to catastrophic.
XForms isn't the first technology to experience this dilemma. All of XML, to some degree, faces this set of design trade-offs. Different XML-based languages have adopted different attitudes towards extensibility. For example, XHTML 1.0 defines a strict set of elements and attributes that can't be expanded upon (at least without producing something that's not exactly XHTML—a later section discusses modularization techniques that can be used to produce new XML-based languages). SVG, in contrast, relaxes a strict content model within the foreignObject element, and W3C XML Schema allows foreign attributes anywhere. The general approach taken by the XForms specification is that XForms is a building block, to be used as a component in another language, which could have anything from a highly conservative to a highly liberal view of extensions. XForms includes a few tools to help language designers achieve the desired level of support for foreign elements.
XForms defines an official conformance level, setting the bar for the level of support This conformance level which, if you think about it, affects what's allowed in documents as well. XForms Processors are required to support the mustUnderstand attribute, which takes a value of xs:boolean. When the value is true, the element bearing the attribute is marked as something that the XForms Processor must be able to process, otherwise the form isn't even worth loading.
For example, a digital signature form control isn't defined in XForms 1.0, and would thus have to be from another namespace. As is the case with extensions, it's not guaranteed to be available. So, a prudent course for a form author would be to include a mustUnderstand attribute:
<vendor:signature ref="/doc/signdata" xforms:mustUnderstand="true"> ...
On the other hand, the Extension Module isn't required for even an XForms Basic Processor to recognize. The single element, extension, is included for compound document providers and compound document types. In function, it is similar to the SVG element foreignObject, serving as an indicator that new and unusual things might be happening inside.
Both of these tools may be an important factor to consider, both for extension designers and extension users.