FypML Version 8
Post date: Nov 15, 2011 8:23:03 PM
Applicable to: DataNav versions 3.0.0 (22 May 2008) through 3.0.3 (08 Sep 2008).
This schema version coincides with the initial release of DataNav's Figure Composer. DataNav versioning began at 3.0 to avoid overlap with Phyplot version numbers. There were significant changes and additions to the FypML schema with this release:
Two new data presentation nodes were added, raster and heatmap. These are specialized for the rendering of two new data set formats, described below. Introduced new attributes in support of these elements: nbins, cmap.
The storage and structure of datasets changed substantially:
Two new dataset formats were added: raster1d is a collection of 0 or more x-coordinate vectors, or rasters (typically used to store spike trains collected over multiple presentations of the same stimulus); and xyzimg is a 3D dataset in which one variable Z is a function of two independent variables X and Y. Z(X,Y) is "sampled" over the rectangle [x0..x1, y0..y1] in the XY-plane. It can be thought of as an image, and it is in fact rendered as such via a color lookup table in the heatmap element.
The series and mseries formats now include -- in addition to the sample interval dx -- a second parameter x0 specifying the x-coordinate for the first sample in the series.
The figure model entity encapsulating data sets was entirely rewritten for DataNav. In Phyplot, the "raw data" was a list of double-precision floating-point tuples which could (but usually didn't) have different lengths. Now, the raw data is generally interpreted as a matrix with a fixed number of rows (data "breadth") and columns (data "length") packed row-wise into a single-precision floating-point array. In addition, the data set entity is an immutable object.
The figure model no longer manages a "data store" as in schema versions 6 and 7. "Orphaned" data sets are no longer possible. Now, a data presentation element (trace, raster, or heatmap) stores a reference to the data set it uses, and such references can be shared because the data set object is immutable.
The definition of the set element changed substantially to support this new way of representating data sets. By far the biggest change was to store the raw data as base64-encoded binary. This decision sacrifices the flexibility to read or write a valid DataNav XML figure file using a simple text editor or a homespun script. But it provides a form that is much more precise (full single-precision float VS a numeric string with up to 6 decimal digits), compact, and opaque. The last two are important considerations given that data sets and figure models will eventually need to be transported over the Internet from a DataNav portal server to client machines that are viewing the portal's content.
The set element supports both the old "comma-separated tuples" and the new base64-encoded text content. This simplifies migration and puts off the task of parsing the old-style tuples until the data set entity is actually created (more efficient and easier than trying to parse the old-style tuples and converting them directly to the base64-encoded binary form). During migration a new attribute, v7, is explicitly set to true on each existing set element, which is otherwise left unchanged. The presence of this attribute informs the XML-to-model converter to expect the schema 7 version of the set element.
DataNav places additional restrictions on the identifier of a data set: (1) maximum length of 40 characters; (2) Only ASCII alphanumeric characters and selected punctuation marks $ _ [ ] ( ) { } + - ^ ! = are allowed. During schema migration, the id attributes of schema version 7 set elements are altered as necessary to meet these criteria. Of course, the src attribute of each trace element that references the set with the corrected id is likewise corrected.