Groups make possible a number of conveniences, but also have a functional aspect. In nearly every respect, a group is another kind of form control, and thus model item properties such as relevant and required can apply to a group, and override those properties on any contained form controls. This is most useful when an entire section of a form needs to change based on some condition in the instance data. The switch element can provide similar functionality, though only based on explicit events to toggle one of several alternatives into view. The group approach works better when the dynamic behavior desired relates directly to the instance data.
Groups can also help authors with a couple of shortcuts:
The group element can be a convenient place to declare the XForms Namespace as the default namespace, to reduce the clutter of repeated prefixes or additional declarations. In languages like XHTML 2.0 that import the XForms elements into a common namespace, this is less of an issue.
Binding attributes can be declared, to set a new context node for any binding expressions that occur within the group. For example, if all the grouped form controls are to reference instance data underneath my:Envelope/my:ExcessivelyNestedElement, that portion of the XPath can be written only once on the group element, like this:
<xforms:group ref="my:Envelope/my:ExcessivelyNestedElement"> <xforms:input ref="my:Leaf"> ... </xforms:group>
In the example, the grouped input form control is spared from having to fully spell out the XPath expression to the desired node, which would be my:Envelope/my:ExcessivelyNestedElement/my:Leaf. When groups contain multiple form controls, the savings gained by avoiding needless repetition can be substantial.