(updated August 2005)
The NEXUS file format is the format supported fully by Mesquite at present. Other file formats can be imported and exported.
The MesquiteFile class has methods to help parse a NEXUS file, returning the file block by block and command by command. These methods parse the file using the definitions of tokens, commands and blocks in the NEXUS standard. The module that makes use of these methods is currently the InterpretNEXUS module. It receives each block, and determines which module can read it.
When Mesquite starts up it queries each module to return (if it desires) an object of the class NexusBlockTest. Mesquite stores such objects associated with a record of the information about each module. When file reading, the InterpretNEXUS module first queries all currently instantiated modules (in the employee tree) to see if they can read a particular NEXUS block. It does this by passing the block name and the entire block to the method readsWritesBlock of the NexusBlockTest object. If the method returns true, the block is passed to the module for processing.
The module, after processing the block, returns an object of class NexusBlock. A list of NexusBlocks is stored in association with each file, so that when the file is rewritten, the system knows what components to write to the file. (Also, outside of the context of file reading, modules can invent NexusBlocks and register them as associated with a file, so that they will later be represented by a block of text when the file is written.)
If, after querying all instantiated modules, no reader for a block is found, InterpretNEXUS then examines the records for available but uninstantiated modules, calling the readsWritesBlock of any NexusBlockTests it finds. If it finds one that claims to read it, it hires the module and sends it the block to be read.
A series of special modules important in file reading and writing are the Managers. These include ManageTaxa, ManageCharacters, ManageTrees, and so on. Each one reads or coordinates the reading and writing of a major block in a NEXUS file, and manages the objects that each block creates (Taxa, CharacterData, TreeVector, and so on).
Some blocks in a NEXUS file are heterogeneous in composition. For instance, an ASSUMPTIONS block might contain stepmatrices, model sets, probability models, and so on. Each is defined by a particular command. What commands it might contain are not fixed at present: if new sorts of calculations are invented, they might need a new sort of command in the ASSUMPTIONS block. The Manager of the ASSUMPTIONS block must therefore find modules to read each command. It does this somewhat as does InterpretNEXUS for blocks. ManageAssumptionsBlock uses the objects of class NexusCommandTest returned by modules during Mesquite startup to determine which modules can read a particular command.
To write a NEXUS file, the InterpretNEXUS module cycles through the NexusBlock objects associated with the file. Each such object has a method that returns the text of the block (typically, the object knows what module manages it and asks the module to compose the text of the block on demand). Some modules, like the one managing the ASSUMPTIONS block, compose their blocks by harvesting commands by calling the getNexusCommands method of other modules.
^ Maddison, D.R., D.L. Swofford, and W.P. Maddison. 1997. NEXUS: An extensible file format for systematic information. Systematic Biology 46: 590-621
class