Task #11982 (new)
Opened 10 years ago
Last modified 8 years ago
OME XML model and metadata packages
Reported by: | rleigh | Owned by: | rleigh |
---|---|---|---|
Priority: | minor | Milestone: | OME-Files |
Component: | General | Version: | 4.4.10 |
Keywords: | n.a. | Cc: | |
Resources: | n.a. | Referenced By: | n.a. |
References: | n.a. | Remaining Time: | n.a. |
Sprint: | n.a. |
Description
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.
Change History (15)
comment:1 Changed 10 years ago by jamoore
comment:2 Changed 10 years ago by 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.
comment:3 Changed 10 years ago by mlinkert
Referencing ticket #12181 has changed sprint.
comment:4 Changed 10 years ago by mlinkert
Referencing ticket #11981 has changed sprint.
comment:5 Changed 9 years ago by rleigh
- Milestone changed from 5.1.0 to 5.2.0-m1
comment:6 Changed 9 years ago by jamoore
- Milestone changed from 5.2.0 to OMERO-5.2.0
Splitting due to milestone decoupling.
comment:7 Changed 8 years ago by jburel
- Milestone changed from OMERO-5.2.1 to OMERO-5.2.2
Milestone OMERO-5.2.1 deleted
comment:8 Changed 8 years ago by jburel
- Milestone changed from OMERO-5.2.2 to OMERO-5.2.1
Milestone OMERO-5.2.2 deleted
comment:9 Changed 8 years ago by jburel
- Milestone changed from OMERO-5.2.2 to OME-Files
comment:10 Changed 8 years ago by jamoore
Referencing ticket #12181 has changed sprint.
comment:11 Changed 8 years ago by jamoore
Referencing ticket #12181 has changed sprint.
comment:12 Changed 8 years ago by jamoore
Referencing ticket #11981 has changed sprint.
comment:13 Changed 8 years ago by jamoore
Referencing ticket #11981 has changed sprint.
comment:14 Changed 8 years ago by jamoore
Referencing ticket #11981 has changed sprint.
comment:15 Changed 8 years ago by jamoore
Referencing ticket #11981 has changed sprint.
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.