WAP-238-WML-20010911-a, Version 11-Sep-2001 Page 12 (69)
2001, Wireless Application Protocol Forum, Ltd.
All rights reserved
5. User Agent Behaviour (Normative)
5.1. User Agent Behaviour and Features in WAE
The specification covers the elements of the language (see section 6), the use of style with WML (see section 7) and
other aspects of user agent behaviour necessary to implement WML as part of the Wireless Application Environment.
However WML2 depends on user agent behaviour and features described outside of this specification. To fully
understand, implement and use WML2, this specification must be considered in conjunction with the Wireless
Application Environment specification [WAE] and other specifications referenced in both this specification and
[WAE].
5.2. User Agent Context
The user agent context consists of variables and navigation history.
5.2.1. Variables
A WML variable is a name-value pair, where the value is any string in the document character set.
This section describes WML variables in the user agent context. The user agent MUST implement WML variables.
WML variables can be used in the place of strings and are substituted at run-time with their current value.
A variable is said to be set if it has a value not equal to the empty string. A variable is not set if it has a value equal to
the empty string, or is undefined in the current user agent context.
5.2.2. Navigation History
The navigation history is a logical stack of the resources in the navigational path the user traversed to arrive at the
current resource.
This section describes the navigation history maintained by the user agent. The user agent MUST implement the
navigation history model and support all the operations on it defined below.
WML2 includes a simple navigational history model that allows the author to manage backward navigation in a
convenient and efficient manner. The user agent history is modelled as a stack of entries that represent the resources in
the navigational path the user traversed to arrive at the current location. The stack is configured temporally, such that
the newest entry is at the top of the stack and the oldest entry is at the bottom of the stack. Three operations may be
performed on the history stack:
•
Reset - the history stack may be reset to a state where it only contains the current entry. See the
wml:newcontext attribute(section 6.2.1) and newcontext
attribute (section 6.2.3) for more information.
•
Push - a new entry is pushed onto the history stack as an effect of forward navigation.
•
Pop - the current entry (top of the stack) is popped as a result of backward navigation.
As each body/card is accessed via an explicitly specifiedURI, (e.g., via the href attribute in wml:go element,) an
entry for the body/card is added to the history stack even if it is identical to the most recent entry. At a minimum, each
entry must record the resource request information that comprises the absolute URI of the body/card, the method (get or
post) used to access the body/card, the value of any postfields, any XHTML form data name-value pairs, and any
request headers. Document content is not stored in the history. Variable references are never stored in the history. Any
variable references in the resource request information must be replaced with the current value of the variables before
the entry is added to the stack.
The user agent MUST return the user to the previous body/card specified in the history if a prev task is executed (see
section 5.3.2). The execution of prev task pops the current entry from the history stack.
If the body/card is part of a document that was originally fetched using an HTTP post method, and the user agent
MUST re-fetch the document to establish the body/card, then the user agent MUST reissue any post data associated