I've also put some thought into how we utilise the schema definitions - we can decide which output formats to offer for which schema definitions - as described in this table

Impementation of hierarchial schemas in plain documents mode (CouchDB) is based on introduction of new metadata field: trackType. It describes all data arrays which are stored in this track. For example: if we have 2d track, we have ‘x’ and ‘y’ data arrays. 3d track is extension of 2d track it has ‘x’, ‘y’ and ‘z’ data arrays.

For example if we have 2d track then we will have track document wih following json description: { “name” : “some track”, …. , “trackType” : [“x”, “y”], “x” : [1, 2, 3], “y” : [3,2, 1]} where x and y are separate arrays which store track coordinates. If we have 2d+timed track one more data array ‘time’ will be added to such track and its json description will be: { “name” : “some timed track”, …. , “trackType” : [“x”, “y”, “time”], “x” : [1, 2, 3], “y” : [3,2, 1], “time” : [Jan 01 2012, Jan 03 2012]}.

3d track is extension of 2d tracks and they have additional data-array ‘z’ so json description of 3d track is { “name” : “some track”, …. , “trackType” : [“x”, “y”, “z”], “x” : [1, 2, 3], “y” : [3,2, 1], “z” : [5, 5, 5] }

This format has two main pros:

• If we are interesting only in 2d tracks and 2d coordinates we just select ‘x’ and ‘y’ data arrays from track documents and don’t need any additional transformation from 3d and 6d format to 2d, because 3d and 6d formats are extensions of 2d format and also have ‘x’ and ‘y’ data arrays
• Because field trackType stores definition of every data array which some track has we can use it to emulate hierarchy. For example, if track in its trackType field has ‘x’ and ‘y’ this is 2d track including 3d tracks, 6d tracks, 2d+time tracks etc. If we are interesting in 3d+timed tracks we simply ask for tracks which have ‘x’, ‘y’, ‘z’, ‘time’ subset in theirs ‘trackType’ field and this will include 6d+time tracks because theirs ‘trackType’ field also contains this subset.