OME XML model and metadata packages

[rleigh]

Currently:

ome.xml.model
ome.xml.model.enums
ome.xml.model.primitives
ome.xml.meta

Thoughts:
In order to support models other than XML (example: HDF5), it would be nice to decouple the model interface from the logic used for serialisation. That is, for each model object, rather than having a single class, we could have an interface, with implementations for each serialisation type (which can also have their own interfaces). This could be, for example:

ome.model.primitives
ome.model.generic
ome.model.xml
ome.model.hdf5
ome.model.yaml
etc...

So what is now (for example) ome.xml.model.Image would become (as a concrete implementation) ome.model.xml.Image, which implements the ome.model.generic.Image interface as well as the ome.model.xml.Serializable interface.

Having the enums in their own namespace doesn't really give us much, so we could look at moving them into the same namespace as the regular model objects. Is there a reason to split them out? It's certainly not a namespace pollution issue since they are guaranteed not to clash with model object names. It would certainly simplify the code generation somewhat, particularly for C++, though we already paid the cost to implement it.

[jamoore]

yaml I can see. I'm a bit more skeptical about hdf5: I'd likely just embed the XML within the HDF5 file.

My primary concern with this is still that we will have to write our own upgrade/downgrade system.

[rleigh]

I would have the actual model data in ome.model.generic with the xml/hdf5/yaml classes containing only the logic for serialisation. So this isn't directly concerning itself with upgrades/downgrades--it can't since it's fixed to dealing with only one model version, the one from which the code was generated. That can't change, at least without further work.

I would suggest that, at least for the hdf5 case, we could support storage of both XML and native objects in the hdf5 file. For real-time data acquisition or interactive manipulation, the ome.model.xml object tree could be a direct view of the hdf5 structure, and altering the objects would make changes directly to the file. However, since we can't safely upgrade them, one possibility would be to also write an XML copy into the file when you close it, which would keep an XML copy in sync with the object tree. When you come to upgrading, you could upgrade the xml via the transforms, and write out a new object tree. We could even use a versioned path for the objects so that the old tree could be retained if needed.

But the hdf/yaml parts are currently just potential additions. The existing ome-xml package could be restructured without these being added; doing so would then make it possible to add these at a later date.

[mlinkert]

Referencing ticket #12181 has changed sprint.

[mlinkert]

Referencing ticket #11981 has changed sprint.

[jamoore]

Splitting due to milestone decoupling.

[jburel]

Milestone OMERO-5.2.1 deleted

[jburel]

Milestone OMERO-5.2.2 deleted

[jamoore]

Referencing ticket #12181 has changed sprint.

[jamoore]

Referencing ticket #12181 has changed sprint.

[jamoore]

Referencing ticket #11981 has changed sprint.

[jamoore]

Referencing ticket #11981 has changed sprint.

[jamoore]

Referencing ticket #11981 has changed sprint.

[jamoore]

Referencing ticket #11981 has changed sprint.