Figure json version number

[wmoore]

Need to add version number to the Figure files saved as json Original Files.
This will be in the json itself.

Probably just go for "version = 0" etc. since we only need to know if version is before a particular code change.

When any changes to version number occur, these should be documented somewhere (maybe just in the code initially) with date etc.

Also should link the Original File to every Image that is used in the figure and update this on each save.

[jamoore]

This is certainly the issue that causes me the most concern. Though adding a version number is a must (:thumbsup:), I don't know if it gets us everything we need. Similar to ROIs, we are essentially creating a file format here, and will have to support them for some time to come. What's the plan on handling bumped version numbers? Something like XSLT written in Javascript? Does anything like this exist?

Looking at the rest of our stack, the only "right" way to do this as far as I can tell is to model this with XSD and provide proper transforms. But that's, of course, a lot of overhead, for something that's quite light-weight and agile at the moment.

NB: depending on how far we go down the modeling route, there's also the question of providing a bridge to the other figure packages you mentioned, Will.

[ajpatterson]

I think there is a version of the Saxon XSLT processor that runs in the browser.

[ajpatterson]

​http://www.saxonica.com/ce/index.xml

There is a video about client side xslt from the Saxonica people from last years ​http://www.xmlprague.cz (likely to disappear soon as new conference is next month)

[wmoore]

A recent example was changing the dx and dy values I saved: Previously they weren't scaled by the zoom, now they are.
Assuming this change bumps the version number from 0 to 1, I would have code like this when opening a json file

// pseudocode
version = json.version
dx, dy, zoom = json.dx, json.dy, json.zoom
if (version < 2) {
  dx = dx * zoom
  dy = dy * zoom
}

Then, when I save the file I simply save the latest version number and the updated values of dx, dy.

I realise this makes for more complex file reading code, but it gets us what we need (along with plenty of docs)!

[wmoore]

Josh / Andrew - Unless you have any objections, I will go ahead with the simple versioning workflow outlined above? I have another example (pixel_size) to test this with just now, so you can see this implemented.

[jamoore]

Seeing how the simple versioning is going to work is probably not a bad idea, but before we go public with this, we'd need a wider discussion.

[wmoore]

See commit ​https://github.com/will-moore/figure/commit/411f0bd53993facb6fa6965041a764b10bc60950

Here I have bumped to version 1 and handled older files on opening to convert to version 1. Will then be saved as version 1.

[wmoore]

While I am quite happy with the workflow above (see commit) for handling changes to files, I'm also wondering if we want to Tag various releases of OMERO.figure (E.g. see webtagging ​https://github.com/dpwrussell/webtagging/releases). If so, are the release Tags completely separate from file versions, or do we make file changes in sync with releases?

[wmoore]

After discussion in yesterdays meeting: - ​https://www.openmicroscopy.org/site/community/minutes/minigroup/usability/2014-01-23
decided that release numbers will stay independent of file version numbers.