The field is used to delineate the scope of specification for the element. The entries here could be as follows.
            page
            object
            class.

The possible entries for this field are described below:

page:  specification for element only valid for the current page.

object: element on other pages could share the specifications for this element, if they have the identical object value binding.

class:  element on other pages could share the specifications for this element, in the same way as the object setting, except for the fact that a wider scope of sharing is allowed. The explanation for this is included in the general description of the essence of this scope. In short elements from the other pages that have identical binding to objects of the same class could share the element?s specification.

In general, data originating from the same source in the domain usually have similar or identical business rules. If a numeric field is designated as currency, the formatting should be the same irrespective of the page it shows up in. The means of sharing such specification is the spec-scope. Such data would usually be presented through proxy or transfer objects, which are declared in the application. By specifying object for the spec-scope, all elements that share the same property of the proxy object would inherit the specification. This would allow for centralized specification, which would be inherited in other pages. Proxy or transfer objects are declared and given global names within the application. Such specifications would be associated with global names. The class designation widens the scope for sharing specification to proxy object provided other names (handles) but derived from the same base class.

The intent of setting specification scope is clear; allowing specifications to be shared across multiple pages. There are many way to implement such specifications. For instance a global format could be specified for an element with specific value binding. Subsequently, one could apply this format by doing a global find or replace.

With these various custom possibilities available, what are being described here are facilities that are built into the Struts framework.

In terms of Struts framework, the specification that could be shared globally or declaratively, involve only validation specifications.

For this, the applicable scopes are listed below.

            page
            object

Object

The default for Struts is object scope. Whenever specification is provided for an element bound to a property of a form bean. That specification could be used by all pages using that property binding.

As such, any of the validation specifications that are declaratively implemented, in Struts configuration, would automatically be on the object level. This is because these specifications are entered in association with the form-bean and not the page.

Page

In the purest sense, there is no page scope validation specification for Struts. As mentioned earlier, Struts is action centric.

There is a means of making a page specification that is covered in the discussion of the group-id attribute of the element descriptor. However, this pertains to series of pages using the same object, like Wizards.

For a moment, we could pretend that each page uses a unique action; as such we shall use the term page scope and action scope interchangeably.

To implement based on the action scope, all entries that require the form bean name, shall carry the action path.

To make Struts use action scope, rather than form scope, there are special base classes that must be used.

See Base Form Object table for the mapping of base object to scope. By implication, this specification could not be made independently on an individual element basis, simply because it is based on the form-bean or action specification for the whole page.