6 Base module

6.7.1 Value Reference

The attribute form value reference (valueref) associates attributes, an element's content, or an element itself, with referential attributes (or content) that can be used to refer to the effective value of the attribute, content, or element node. The referential attributes so named are referred to collectively as "value reference attributes".

NOTE 111 The "effective value" of an attribute is the value that an application or architectural processor needs, which is not necessarily limited to the types of data or objects that can be expressed through SGML's attribute value syntax. For example, an element type may represent an application-defined object class that has properties that are themselves structured. The "property-of" relationship can be indicated by making the property an attribute of the element type. The structure of the property can be represented by using additional elements to structure the value and using value reference to refer to those elements as the "real" value of the attribute (where the syntactic value of the attribute might be the reference itself).

NOTE 112 A "#ELEMENT" value reference allows one SGML element to act as a "placeholder" for another element held somewhere else (for example, as a subdocument). However, the element making the reference is still addressable. Addressing the element making the reference is equivalent, for the purposes of HyTime-specific processing, to addressing the effective element node.

The valueref attribute value is a list of name pairs. The first name of each pair may be an attribute name, the keyword "#CONTENT", or the keyword "#ELEMENT". It names the attribute, content ("#CONTENT"), or complete element ("#ELEMENT") for which the value is to be addressed by the attribute or content named by the second keyword. If the same attribute (or #CONTENT) is used for both names, the attribute or content refers to its own semantic value and never takes its semantic value directly (e.g., the exspec attribute of the event element form). The keywords "#CONTENT" and "#ELEMENT" may only appear once as the first keyword of a pair. The keyword "#CONTENT" may only appear once as the second keyword of a pair.

When the first name in a pair is "#CONTENT", the effective value of the content property of the element is the node list addressed by the attribute or content named by the second name in the pair.

NOTE 113 For example, to provide an attribute called "conloc" for referring to the content of an element, use a declaration of the form:

<!ATTLIST Para
   HyTime   NAME     #FIXED "HyBrid"
   valueref CDATA    #FIXED "#CONTENT conloc"

   -- Locate the content of the para --
   conloc   IDREF    #IMPLIED
>

The valueref attribute indicates that the content of the element Para will be located by reference using the referential attribute "conloc" (the conloc attribute is referential because it has a declared value prescription of "IDREF").

When the first name in a pair is "#ELEMENT", the effective element node is the single node addressed by the attribute or content named by the second name in the pair. When the object addressed is a document or subdocument entity, the effective element node is the document element of the addressed document. It is an RHE to address more than one node as the effective element node.

The objects located as the effective value of attributes, content, or elements need not satisfy the syntactic constraints defined in the referring document's document type declaration. However, they must satisfy any semantic constraints defined by the processing application. The mechanism for defining such constraints is outside the scope of the HyTime standard.

NOTE 114 Semantic constraints could include conformance to the lexical type of an attribute, the content model of the referring element, conformance to one or more architectural meta-content models, or other semantic constraints unrelated to SGML-defined constraints. Application designers can use the reference type control facilities of HyTime and the General Architecture to control the types and organization of elements referred to.

Value reference does not modify how an SGML document is parsed.

NOTE 115 Conceptually, the result of a value reference is maintained in the HyTime semantic grove, not the HyTime effective SGML document grove. This means in particular that a node addressed by value reference does not occur in any name spaces in the HyTime extended SGML document grove of the document from which the value reference is made if the node's origin is not already in that grove.

Thus, if an element in another document is made the content of an element by value reference, the referenced element can be addressed by name only by a inter-document address but can be addressed directly by tree location with respect to the referring element.

For the purposes of accessing attribute values and the content of elements via HyTime location addressing, the data addressed by value reference are always used even if there is a directly-specified value for the attribute or content. The only exception is property location addresses, which can, optionally, address the direct value of the attribute or element, rather than its referenced value.

NOTE 116 In other words, valueref serves to "redirect" location addresses from the direct value to the indirectly-addressed value.

Addresses resolved by means other than a HyTime engine (such as a DSSSL engine) need not respect the redirection performed by value reference attributes.

When the location addressing module is supported, any supported means of addressing may be used for value reference. If location addressing is not supported, value reference attributes must be declared as IDREF, IDREFS, ENTITY, or ENTITIES and content cannot be used for value reference.

An element that uses value reference to refer to its content may allow syntactic content. There is no requirement that elements that provide an attribute for value reference of their effective content declare that attribute with a default value of #CONREF -- any syntactic content will be ignored for HyTime processing when the value reference attribute is specified in any case (unless the content itself contains the reference).

NOTE 117 In the conloc example above, the Para element could have syntactic content, but HyTime location addresses that address the content of the Para element would address the objects addressed by the Para's conloc attribute, not the data in its syntactic content (except as provided by the proploc element form).

             <!-- Value Reference Attribute Namer -->
<![ %valueref; [
<!attlist
-- valueref --    -- Value reference attribute namer --
                  -- Clause: 6.7.1 --
   #ALL

   valueref       -- Value reference attribute namer --
                  -- Associates attributes (or element's content) with
                     referential attributes (or content) that can be
                     used to refer to the semantic value of the
                     attribute or content. --
      CDATA       -- Lextype: ((ATTORCON|"#ELEMENT"),ATTORCON)+ --
                  -- Note: The first ATTORCON is the attribute or
                     content for which the value is to be addressed,
                     the second ATTORCON is the attribute or content
                     by which the value reference is made. --
                  -- Constraint: second attribute in each pair must be
                     a referential attribute or content defined as
                     referential by the refloc facility. --
                  -- Constraint: "#ELEMENT" and "#CONTENT" may only
                     occur once as first keyword of pair.  "#CONTENT"
                     may only occur once as second keyword of pair. --
      #IMPLIED    -- Constant --
>
]]><!-- valueref -->

The following form is included for backward compatibility.

                      <!-- Content Location -->
<![ %conloc; [
<!attlist
-- conloc --      -- Content Location --
                  -- Clause: 6.7.1 --
   #ALL

   HyBase   NAME     #FIXED HyBrid
   valueref CDATA    #FIXED "#CONTENT conloc"

   conloc         -- Content location --
                  -- Location of the element's semantic content. --
      CDATA       -- Reference --
      #CONREF     -- Default: syntactic content --
>
]]><!-- conloc -->

6.7.2 Descriptive text

The descriptive text facility is an alternative form of value reference that allows elements that are frequently repeated in a document to be accessed by a descriptive name in a lookup table. The lookup table can also be thought of as providing a definition for the descriptive text, where the definition is the content and attributes of the element described.

6.7.3 Activity policy association

In interactive systems the data objects available for interaction have access policies associated with them, either implicitly or explicitly. In many systems, access policies are implicit in the design of the system or expressed through system facilities such as user-based access permissions. Policies may also be associated with objects explicitly by associating activity policy definitions with the objects to which the policies apply. Typically, the owners of information objects associate owner policies with them. For example, a policy to protect the ownership of a piece of intellectual property may require the purchase of a license before access is permitted.

The HyTime activity policy association facility is a standardized means of expressing the attachment ("association") of activity policies to information objects. Such policies take effect and are applied ("triggered") whenever users, authors and editors attempt to engage in defined classes of interaction with information objects. "Activity" is the generic term for all such interaction; each class of interaction is an "activity type". HyTime standardizes neither the expression nor the management of the details of activity policy specification and enforcement. The definition of activity policies is application specific and may consist of any combination of modes and manners of definition, including legal agreements expressed in natural language and interactive computer programs.

NOTE 121 A HyTime engine that supports the activity option may provide the service of managing the associations between the policies and the objects governed by such policies, but it may have no ability to understand or enforce the policies themselves. A complete HyTime system may make use of such an infrastructural policy association management service by distinguishing between classes of activity (e.g., access to the governed objects, versus modification of the governed objects), asking the HyTime engine for the policies that are applicable to the particular class of activity, and bringing those policies to bear in some way, perhaps even enforcing them. Alternatively, a HyTime engine may understand and even enforce certain kinds of policies, and the implementers of a complete HyTime system that incorporates such a HyTime engine may therefore not be required to develop activity policy triggering and enforcement features.

Activity policy association rules are associated with information objects in two ways: objects that are SGML elements can refer to the activity policy rules that govern them using the actrules attribute form, and activity policy rule (actrule) elements can refer to any information objects, including but not limited to SGML elements. In either case, the activity policy is automatically associated not only with the information object itself, but also with its metadata (that is, in the case of an SGML element, its attribute values) and with all of the components of its content.