Whenever the intent of the binding attributes is to select a single node, the ref attribute will be present. It contains an XPath path expression. In cases where the selected node-set happens to have more than one node, the first node rule applies, which removes all nodes other than the first, according to the order the nodes appear in the document.
In larger or more complex documents, it will be common to have multiple XForms Models. When this is the case, an additional attribute is needed to indicate to which XForms Model the binding attaches. The value of this attribute is of type IDREF, and so a model element in the same document must have an attribute of type ID with a matching value.
In some cases, such as when a graphic design professional who isn't concerned with XPath is laying out a form, it isn't desirable to have XPath strewn about on every set of binding attributes. The bind attribute, which takes precedence over any of ref, nodeset, or model, refers back to an already-defined node-set on a bind element. The value of this attribute is of type IDREF, and so a bind element in the same document must have an attribute of type ID with a matching value.
It's worth noting that the term binding, as used in XForms, can refer to two separate things. UI Binding occurs on an attribute of a form control element, and binds the form control to a particular model item. In dynamic forms, the association to a model item can jump around, causing the form control to be a window to different parts of the data at different times. The other use of binding, Model Binding, occurs on the element bind, selecting an entire node-set to which a set of model item properties gets applied. It is a serious problem to have a dynamic model binding expression, since that complicates life behind-the-scenes for an XForms Processor, which can cause difficult-to-detect errors.