This provided unique identification for an element, across the specification artifact. Since an element can have multiple server as well as client identities, what is chosen for universal identification could vary for different platforms.

For dWebSpec specification the choices are between the "name" and "id" attributes of the corresponding HTML form elements. The earlier is preferable since it also represent the server side data identity for the element.

For Struts, the form element "name" attribute is logical as the identifier. Since the elements get their identities from their data binding, establishing this identities or binding early would allow proper identification throughout the development cycle.

This id could be used on the source content, and referred to in written specifications. Subsequently, the identities would be transferred to the descriptor, as the start of the dynamic specifications.

If we take for example an inputText element, bound to {employeeForm.surname}. The representation in the source content would be as follows:

  <input type="text" name="surname"/>
  

The implementation would be as follows.

  <html:text name="employeeForm" property="surname"/>
  

With an element enclosed by a form, the name defaults to the object bound to the enclosing form. As such, this could be expressed as shown below.

  <html:text  property="surname"/>
  

If in the alternative, "id" parameter is used for identification in the source content, this would be adequate as long as such usage is uniform across the application.

In this case, the source content representation for the example text box would be as follows.

  <input type="text" id="surname"/>
  

The implementation would be as follows.

  <html:text? styleId=="surname" property="surname"/>
  

This id attribute would translate to styleId attribute for Struts tags. For more explanation on this, please consult the Introduction and Guide, chapter 5, section 2, under the topic, Allowed Attributes and Pass Through.