11.1 The Cost of Extensibility

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.

11.1.1 Extension and mustUnderstand

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.



XForms Essentials
Xforms Essentials
ISBN: 0596003692
EAN: 2147483647
Year: 2005
Pages: 117
Authors: Micah Dubinko

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net