In order to store modules, module collections, and performance data in a software-neutral manner, a bespoke Integra file format was developed. XML was chosen as the basis for this since it is relatively human-readable, can be transformed for a variety of output targets, and has a number of excellent tools for parsing, reading and writing.
Rather than keeping all data needed to store an Integra collection in a single file we make use of the XML Linking language (XLink3) to link in relevant resources. This makes for more efficient parsing and helps to keep file sizes small.
Perhaps the most important part of the IXD specification is the module definition file. It is the XML representation of an Integra module (see ). These files are created and updated through the database interface and stored locally for offline access in a gzipped archive. Each file contains the class and module definitions of one unique module and a link to the parent class from which it inherits properties:
<Class> <ClassDefinition> <className>Sinus</className> <classParent ... xlink:href="Oscillator.xml"> Oscillator </classParent> ... </ClassDefinition> <ModuleDefinition> ... </ModuleDefinition> </ClassAll documents that are part of the Integra documentation system must have a class definition - it represents the super class of the Integra class hierarchy and it defines those attributes shared by all kinds of data - performance data, biographical data, etc. The module definition is specific to the notion of modules as defined in section
Each module and each of its attributes may also hold a documentation reference. This allows the implementing host for this module to make a call to the instance host to bring up on-line documentation, for a specific attribute or for the module itself. The link points to a file included in the local archive of module descriptions.
Once a module is defined and stored in an IXD file it may be instantiated. Instances of classes of modules along with their inter-connections are stored in a collection file which is the Integra equivalent of a PD or Max/MSP 'patch'.
In a collection file each module instance is represented by a locator that points to the definition of the class to which the instance belongs. Connections between ports are represented by arcs between resources (pointing to definitions of individual addresses) in the module definition file pointed to by the locator. Finally, it also holds references to performance data files.
To facilitate the conversion between flat XML files conforming to the IXD specification, and a memory-resident representation of the data, a serialization library component has been developed (see ). The serialization layer is the link between the database and the local file system (see figure
).
The serialization component provides functions for loading, saving and modifying XML, and is used by the instance host (see ), the database (see
) and/or any other application interfacing with the library. For example, on the database server, the serialization layer is made available to the python-based web interface via a SWIG-generated interface.
The IXD format is specified and documented in several XML Schemas4. The XML Schema for the module definition files is closely correlated to the database schema and they share the same versioning system. Any file conforming to the file format can be validated against a specific schema version and conditional actions may be performed on them as appropriate.
Finally, we are also working on an Integra specific XSL Transformation5 specification for automatic generation of XHTML and/or PDF documentation of a given module or collection of modules. In practice this means that once the user has created his or her own Integra collection for a project and uploaded it to the database, a documentation file for this collection is automatically generated.