We should reconsider why the new <name> element was selected in favor of
leveraging the id attribute on <faces-config> for faces-config.xml names. The
motivation is to allow JSF 2 applications to order faces-config.xml files using
the JSF 1.2 XML schema (perhaps in a bundled JAR file).
Somewhere along the way, an assumption was made that using the id attribute
would create a conflict. Here's what Bill Shannon wrote:
"Our deployment descriptors define "id" attributes of type "xsd:ID" on most
elements. Our specs currently make no use of these id attributes. The intent of
these id attributes was to allow tools to identify certain elements in the
standard descriptors so that they could reference those elements from elements
in vendor-specific deployment descriptors. Other similar uses are possible.
I bring this up here because there's some risk that this new use of id
attributes would conflict with the current use by vendor-specific tools. Is
anyone aware of any actual use of id attributes in existing tools?"
Based on the premise, a new element was introduced that would avoid any
conflicts. However, I don't see how identifying a faces-config.xml file to link
to vendor-specific descriptors is any different than identifying one
faces-config.xml file from another.
I don't think a valid defense was ever made that there is actually a risk of
conflict. Regardless, Ed stated that the platform EG, including Bill, now has
hardened their position on not using the id attribute. Thus, the <name>
attribute was forged.
I would like to call this decision into question and at least allow the id
attribute to be used as a fallback name.