Another attribute, src, has caused nearly as much controversy as its big brother in XHTML, href. The problem stems from tension with XLink 1.0, a W3C Recommendation, which asserts itself as the preferred technique to define any "explicit relationship between resources or portions of resources." Originally, this standard was envisioned by some as a solution that could apply to any XML, but the final solution worked only with an attribute named xlink:href (complete with a separate namespace).
The inflexibility of XLink causes problems in modularized documents, including XForms, since there are different kinds of links but only one allowed attribute name. As an example, an element might both serve as a launching point for a hyperlink, and at the same time link to external inline content, as in the following fragment that might result from a combination of XForms and SVG (which uses xlink:href):
<xforms:label src="label2.svg" xlink:href="homepage.html"/>
In this example, the src attribute from XForms points to a SVG file to be used as the label, and the xlink:href attribute from SVG makes the label a clickable hyperlink to homepage.html. It's a good thing that the XForms attribute is named src and not xlink:href, because a conflict would have resulted when trying to combine the languages, since an element can't have two attributes with the same name.
As an alternative to XLink, the HTML Working Group proposed another standard, called HLink, to annotate any XML with link descriptions. The proposal met with almost as little enthusiasm as XLink. The Technical Architecture Group (TAG) of the W3C is looking into the issue; the long term resolution remains to be seen. Controversies aside, in XForms, src consistently means one thing: that the URI in the attribute value is to be fetched as part of loading the document, and the contents rendered in place of whatever element contains the attribute (much like the img element in earlier versions of XHTML).