The StAX parser is an XML parser that is able to process tree-like structured data as the data gets streamed-in. One of the features of this script is that it uses a look-back as it parses the XML string. This could be adapted for a real stream, perhaps, for example, in order to listen on some channel for messages and extract the desired information. The current function is at wasStAX_GetNodeValue and its converse function wasStAX_SetNodeValue and can be used independently based on the function parameters. The Wizardry and Steamworks StAX implementation is an ongoing process to implement a stream-based reader.

One of the applications I thought this would be useful for, were the notecard configurations which are hard to standardize and everybody seems to make up their own way of reading-in data. The StAX parser is sufficient to provide that layer of standardization and relies on very few syntactic restrictions.

The code is designed around the StAX concept. However, we do not implement all the features since we do not consider them useful in the context of Second Life.

The following is a list of symbols that are forbidden from being used as data (either as nodes, or content) in the xml-file:

• The smaller-than sign: <.
• The greater-than sign: >.
• The forward-slash: /.

There are no restrictions imposed on the content disposition in the notecard itself. For example:

<xml>
    <about>
        <description>
                            This is a StAX XML stream parser, 
                            with look-back and suitable for streams.</description>
</about>
                  <usage>
 
    wasStAX_GetNodeValue(string xmlStream, string node)
 
    where xmlStream is a a flat string containing the xml file and,
    node is a node containing the value you wish to extract.
</usage></xml>

Which, although it is badly tabulated and improperly aligned will still parse and will produce no errors when processed with wasStAX_GetNodeValue or wasStAX_SetNodeValue.

The StAX method of parsing an XML file, relies on pushing and pop-ing nodes off a stack (hence the funny name) till the last node in the stack. At the end, the expected result is that the stack will be empty or will contain unmatched nodes, in which case, the XML file is improperly formatted.

• So far, this implementation does not support attributes for tags and they may be implemented later. However, there is not much need for them at this point given limits imposed on notecards.
• Currently, the parser returns the empty string if the node is not a leaf of the XML tree. This may be changed, to return the sub-tree of that node, however at this stage that is not important.

wasStAX_GetNodeValue and wasStAX_SetNodeValue provide a nice way of maintaining configurations with multiple layers of nesting and in an organized format. Furthermore, with some changes to those getter and setter functions, it is possible to expand wasStAX_GetNodeValue to immediately return the value once it is found. The advantage over DOM style parsers is that StAX does not need the XML file to be complete and is thus a good solution where the next data chunk is unknown.

Based on those, a few scenarios come to mind:

• The most trivial, reading and writing configurations from and to notecards.
• Dynamic configurations: our population genetics and selection article uses more-or-less the same concept by using a typical format for message submission. One could use StAX instead to pass parameters between components and the advantage would be a clear, unified API that leaves no room for mistake. All the message and pattern matching done by the population genetics and selection Simulator is done manually every time in each script. Using an universal function, shared across all the scripts, that additionally parses and verifies the consistency of the messages is a great advantage.
• Any hierarchical tree-like data which needs to be kept track of, can use wasStAX_GetNodeValue and wasStAX_SetNodeValue to keep track of the nodes and their position in the hierarchy.