I would like to suggest another property to add to FF:
LO is also node annotation. It means the subtree which includes this
node is entirely concerned with one LOcal battle. As the endgame
approaches, battles may become independent of each other. The player
with sente might contest the battles in any order. LO serves to avoid
the tedium of duplicating the same responses to the same moves
depending on what order the sente side chooses. If a move is selected
outside the choices for a local battle, the program could back up to
the LO node and search among the siblings of that node (which would
also be labeled LO) for a battle which does contain that move. Here is
an example of how the nodes should be structured.
(;B[ec] ;W[gc] GW)
(;B[gc] ;W[ec] GW)
(;B[pq] ;W[po] GW)
(;B[po] ;W[pq] GW)
An LO node should never contain a move, even if there is only one
initial move possible for that battle. This restriction makes it
easier for software to deal with it. An LO node could have an N
property or a TP property. If it has a TP property, it should be a
leaf node in the file, and its target should be another LO node
which is listed earlier in the file and which is not an ancestor of
this TP node. LO itself should have no value. I suppose it could
contain the target name of a TP call, but that would complicate the
definition of TP. It would be simpler to always use N instead.
LO partitions siblings into subsets. When a specific subset battle is
entered, all the initial moves of the as yet uncontested battles
remain available to explore. If the user chooses to leave battle A for
battle B, the software could remember the progress in battle A, and
allow the user to resume battle A later on.
You might wonder, why bother with these moveless LO nodes? There are
two reasons. An LO marker would make it easier for a program to look
for responses to a move which is not a child of the current node.
Also, it is important for the program to know when different battles
are truly independent. So, LO tells the program when it can look
elsewhere, and where it should look.
When used in an LO node, TP means "this local battle is identical to
an earlier listed local battle." This can greatly reduce the file size
that would be necessary to provide a comprehensive list of responses.