Table of contents

Appendices

5.6 Behavior Attributes (

The behavior attributes are show and actuate. They Must, May, etc. be used on the simple- and arc-type elements. When used on a simple-type element, they signal behavior intentions for traversal to that link's single remote ending resource. When they are used on an arc-type element, they signal behavior intentions for traversal to whatever ending resources (local or remote) are specified by that arc.

The show and actuate attributes are not required. When they are used, conforming XLink applications Must, May, etc. give them the treatment specified in this section. There is no hard requirement ("must") for this treatment because what makes sense for an interactive application, such as a browser, is unlikely to make sense for a noninteractive application, such as a robot. However, all applications Must, May, etc. take into account the full implications of ignoring the specified behavior before choosing a different course.

Following is a non-normative attribute-list declaration for show and actuate on an element intended to be simple-type.

<!ATTLIST simplelink
  xlink:type      (simple)        #FIXED "simple"
  ...
  xlink:show      (new
                  |replace
                  |embed
                  |other
                  |none)          #IMPLIED
  xlink:actuate   (onLoad
                  |onRequest
                  |other
                  |none)          #IMPLIED
  ...>

Applications encountering arc-type elements in linkbase lists Must, May, etc. treat the behavior attributes as if they were specified as show="none" and actuate="onLoad", even if other values were specified.

show Attribute[top]

The show attribute is used to communicate the desired presentation of the ending resource on traversal from the starting resource.

If a value is supplied for a show attribute, it Must, May, etc. be one of the values new, replace, embed, other, and none.

Conforming XLink applications Must, May, etc. apply the following treatment for show values:

new

An application traversing to the ending resource Must, May, etc. load it in a new window, frame, pane, or other relevant presentation context. This is similar to the effect achieved by the following HTML fragment:

<A HREF="http://www.example.org" target="_blank">...</A>

replace

An application traversing to the ending resource Must, May, etc. load the resource in the same window, frame, pane, or other relevant presentation context in which the starting resource was loaded. This is similar to the effect achieved by the following HTML fragment:

<A HREF="http://www.example.org" target="_self">...</A>

embed

An application traversing to the ending resource Must, May, etc. load its presentation in place of the presentation of the starting resource. This is similar to the effect achieved by the following HTML fragment:

<IMG SRC="http://www.example.org/smiley.gif" ALT=":-)">

The presentation of the starting resource typically does not consist of an entire document; it would be the entire document only when the root element of the document is a simple link. Thus, embedding typically has an effect distinct from replacing.

Just as for the HTML IMG element, embedding affects only the presentation of the relevant resources; it does not dictate permanent transformation of the starting resource. Put another way, when an embedded XLink is processed, the result of styling the ending resource of the link is merged into the result of styling the resource into which it is embedded. By contrast, when a construct such as an XInclude element [xinclude] is resolved, the original XML is actually transformed to include the referenced content.

The behavior of conforming XLink applications when embedding XML-based ([rfc2376] or [draft-xmlmediatypes]) ending resources is not defined in this version of this specification.

The presentation of embedded resources is application dependent.

other

The behavior of an application traversing to the ending resource is unconstrained by this specification. The application Must, May, etc. look for other markup present in the link to determine the appropriate behavior.

none

The behavior of an application traversing to the ending resource is unconstrained by this specification. No other markup is present to help the application determine the appropriate behavior.

If the starting or ending resource consists of multiple non-contiguous locations, such as a series of string ranges in various locations in the resource, then application behavior is unconstrained. (See [xptr] for more information about selecting portions of XML documents.)

NOTE: 

Some possibilities for application behavior with non-contiguous ending resources might include highlighting of each location, producing a dialog box that allows the reader to choose among the locations as if there were separate arcs leading to each one, concatenating the content of all the locations for presentation, and so on. Application behavior with non-contiguous starting resources might include concatenation and rendering as a single unit, or creating one arc emanating from each contiguous portion.

actuate Attribute[top]

The actuate attribute is used to communicate the desired timing of traversal from the starting resource to the ending resource..

If a value is supplied for an actuate attribute, it Must, May, etc. be be one of the values onLoad, onRequest, other, and none.

Conforming XLink applications Must, May, etc. apply the following treatment for actuate values:

onLoad

An application Must, May, etc. traverse to the ending resource immediately on loading the starting resource. This is similar to the effect typically achieved by the following HTML fragment, when the user agent is configured to display images:

<IMG SRC="http://www.example.org/smiley.gif" ALT=":-)">

If a single resource contains multiple arcs whose behavior is set to show="replace" actuate="onLoad", application behavior is unconstrained by XLink.

onRequest

An application Must, May, etc. traverse from the starting resource to the ending resource only on a post-loading event triggered for the purpose of traversal. An example of such an event might be when a user clicks on the presentation of the starting resource, or a software module finishes a countdown that precedes a redirect.

other

The behavior of an application traversing to the ending resource is unconstrained by this specification. The application Must, May, etc. look for other markup present in the link to determine the appropriate behavior.

none

The behavior of an application traversing to the ending resource is unconstrained by this specification. No other markup is present to help the application determine the appropriate behavior.