The basic assumption behind the use of contextual information during the
incremental monitoring strategy is that it only makes sense
to test whether a partial string, say 
, is ambiguous with respect to
a larger string which entails . Such a larger string will be
built by means of concatenation of and
some other already produced string, which we will call the
contextual string of .
Since revision will be performed before a passive item PL is used for reduction of an active item AL, this active item defines the domain of locality from which contextual information can be determined. Completion will be performed if PL and the selected element of AL can be unified. Therefore, only those elements of the body will be considered as possible contextual strings, that have already been deduced as subgoals of the active item.
Completion causes the removal of the completed elements from the body of a clause, so the elements of the body cannot be used directly. However, using the modified representation of derivation trees as already used in the non-incremental method, we are able to extract the corresponding strings of completed elements of an active lemma from the mother node of AL. Thus, we will determine the contextual string of PL on the basis of the derivation tree represented as part of the constraints of the head of the lemma of AL.
Note that the call of the incremental monitoring mechanism, i.e., the call of REVISION_P is performed in a completion rule before the new reduced item is computed but after unification of the passive item with the selected element of the active item has been done. This guarantees that monitoring is only performed on consistent structures. As a side effect of unification, the derivation tree of the passive item is unified into the derivation tree of the head of the lemma of the active item.
For example, assume that we have reduced the grammar rule
up to the point where we only need to complete the pp
in order to complete the vp. The corresponding active item would be of form
At that point the derivation tree represented as part of the constraints of vp is (making use of useful abbreviations):
rnvp3 stringremove,the,folderP sem... dtrsrnv5 stringremoveP1 semdots dtrs, rnnp3 stringthe,folderP2 semdots dtrs``its tree'', Tree
where the variable Tree is a pointer to the derivation tree of the selected element pp, which is still un-instantiated.
After successful unification of a passive item pp with the selected element, the derivation tree looks as follows:
rnvp3 stringremove,the,folder,with,the,toolsP sem... dtrsrnv5 stringremoveP1 semdots dtrs, rnnp3 stringthe,folderP2 semdots dtrs``its tree'', rnpp1 string with,the,toolsP semdots dtrs``its tree''
Now, we take this representation as the basis for determination of the contextual string of the pp's string ``with the tools'' making use of a look-back strategy as already informally described above.
Recall that the value of the feature is a sequence of the
derivations trees of the corresponding elements of the body. In this context,
we will call the value of the feature the sequence of sisters
of the node represented by the clause's head element.
Since we consider the sister nodes as totally ordered in a sequence, a look-back one strategy (written as look-back (1)) of the selected element, is just the choice of its left or right sister node. Thus, for the example above, we choose the node labelled np3. From this derivation tree we choose the value of the STRING feature as contextual string. Since, we assume that strings are represented as difference lists, it will be the case, that the string of the root node of the derivation tree of np already entails the string of pp. Thus, we can directly start parsing of this string, to test whether this string is ambiguous.
Note that in the above example we have implicitly assumed, that the elements of the body are processed in a left-to-right manner. Of course, in the case of generation this is not the general case. It might be possible, that for example, the pp is completed before the np is. In this case, we would have no (left) sister to be use-able as contextual string for the pp, because the derivation tree of the np still needs to be constructed, which means that the position of this derivation tree within the sequence of sisters is still occupied by an un-instantiated variable. If this is the case, we conclude that for the pp no statement about ambiguity can be made, and therefore, no revision should take place. After the np has been completed, monitoring for the np will eventually take place. But now, there is a choice point for the np either to choose its left or right sister as the base of contextual information, or both.
We can directly generalize the informal description of a look-back(1) strategy to a look-back(n) strategy, if we not only consider the left or right sister node of the selected element as context but the sequence of the n left or right sisters of the selected element. In order to do this we have to consider the following cases:
The first case means that there is a sister which derivation tree has still not been computed. This means that we cannot determine the whole contextual string corresponding to the n sisters, and we conclude that no contextual string exists. The second case means that the whole set of left or right sisters of the selected element can be used as contextual information by actually performing a look-back of less than n. In that case we use the corresponding contextual string spanned by the sisters and use it for the ambiguity check.
For a more readable definition of the look-back(n) strategy, we make use
of the notation subseq(i,j), which is a subsequence of elements
ranging form i to j. For example, subseq(3,5) denotes the subsequence
of the sequence 
.
Empty production will be handled so that
if the sequence contains the name of an empty production we just skip this
element. For example, if a and b are empty productions, then
the sequences 
and are considered
as being equal.
The notation ``the string of subseq(i,j)'' means the string built by
a left to right concatenation of the strings of the elements of the
subsequence (modulo empty productions).
We will say that a ``subseq(i,j)'' is instantiated if
for each element of the subsequence its derivation tree is instantiated.
Thus, the look-back(n) strategy can be expressed as follows:
Let 
be the sequence of sisters of the derivation tree
of a rule and let
be the derivation tree of the ``unified'' selected element
of the rule, and its string. Let ll be the length of
subseq(1,i-1) and rl be the length of subseq(i+1,m). If n ;SPMgt; ll then
let n be ll, and analogously let n be rl, if n ;SPMgt; rl. Then,
be the string of subseq(i-n,i-1);
let 
be the extended string; be the string of subseq(i+1,i+n);
let 
be the extended string; and 
respectively
then let 
be the extended string;
This definition is used inside the function GET_CONTEXT (which is called inside REVISION_P, see above) which receives as input an active and a passive item and returns either an extended string or false. To be more precise, we have:
get_context(AL,PL,n): dtrs := get_dtrs(AL); lsisters := get_left_sisters(AL,label(PL)); rsisters := get_right_sisters(AL,label(PL)); ``apply look-back(n) on lsisters and rsisters;'' if extended-string then return extended-string else return false.
We first extract the sisters of the derivation tree of the active item AL, i.e., the value of the path deriv,dtrs of the constraints of the active item's lemma's head. We then split this list into a left and right subsequence, where the passive item (which corresponds to the unified selected element of AL) serves as the splitting point. Next, we apply the look-back(n) strategy, and either return an extended string or false, if no such exists.