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. The library currently uses the libxml27 library to provide much of its XML processing functionality.
Rather than keeping all data needed to store an Integra collection in a single file we make use of the XML Linking language (XLink8) 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. (see section
A part of the body of the module definition IXD file containing the definition shown in Table , would contain the following construct (please note that only the freq-attribute is included):
<attributeUnitCodes> <index id="0"> <name>Hz</name> <description> The value in Hz (0 - INF). </description> </index> </attributeUnitCodes> <attributeMinima> <index id="0"> <value>0</value> </index> </attributeMinima> <attributeMaxima> <index id="0"> <value>INF</value> </index> </attributeMaxima> <attributeDefaults> <index id="0"> <value>440</value> </index> </attributeDefaults> ...
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 this attribute or for the module itself. The link points to a file included in the local archive of module descriptions.
<classAttributesDocumentationIDs> <index id="0" ... xlink:href="FrequencyDoc.xml"> </index> </classAttributesDocumentationIDs>
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.
The performance and preset data files store information about the current and previous N states of the instance stored at a specified time resolution, stored presets, and sequences of dynamic data. As was mentioned in section , this information is only available to instances, or a group of instances, which holds a reference to a special kind of data module, i.e. this file represents an instance of this data module which in turn is associated with a specific module instance or group of module instances.
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 Schemas9. 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 Transformation10 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 piece or a project, and uploaded it to the database a documentation file for this collection is automatically created.