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.

spec-scope does not have direct implementation equivalent on the JSF platform. Its specification could provide implementation hints.

It is simply a means of stating whether specifications, like formatting, validation, conversion, etc. pertain to the particular element or its instance on the current page. Or else, they could be applied to elements with identical bindings to domain objects.

Since on the JSF platform, the domain objects are exposed as inner objects of the backing beans, it might not be straight forward to derive this equivalence across the backing beans.

However, with the multiple options of implementing these specifications, like binding to method in backing beans, standard validators, named validators, etc, it is obvious that this specification could influence which option to be chosen. Specification that would be used across the pages would be better specified as standard or named validators.