Notice: In order to edit this ticket you need to be either: a Product Owner, The owner or the reporter of the ticket, or, in case of a Task not yet assigned, a team_member"

Task #11982 (new)

Opened 7 years ago

Last modified 5 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 7 years ago by 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.

comment:2 Changed 7 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 7 years ago by mlinkert

Referencing ticket #12181 has changed sprint.

comment:4 Changed 7 years ago by mlinkert

Referencing ticket #11981 has changed sprint.

comment:5 Changed 6 years ago by rleigh

  • Milestone changed from 5.1.0 to 5.2.0-m1

comment:6 Changed 6 years ago by jamoore

  • Milestone changed from 5.2.0 to OMERO-5.2.0

Splitting due to milestone decoupling.

comment:7 Changed 5 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 5 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 5 years ago by jburel

  • Milestone changed from OMERO-5.2.2 to OME-Files

comment:10 Changed 5 years ago by jamoore

Referencing ticket #12181 has changed sprint.

comment:11 Changed 5 years ago by jamoore

Referencing ticket #12181 has changed sprint.

comment:12 Changed 5 years ago by jamoore

Referencing ticket #11981 has changed sprint.

comment:13 Changed 5 years ago by jamoore

Referencing ticket #11981 has changed sprint.

comment:14 Changed 5 years ago by jamoore

Referencing ticket #11981 has changed sprint.

comment:15 Changed 5 years ago by jamoore

Referencing ticket #11981 has changed sprint.

Note: See TracTickets for help on using tickets. You may also have a look at Agilo extensions to the ticket.

1.3.13-PRO © 2008-2011 Agilo Software all rights reserved (this page was served in: 0.89182 sec.)

We're Hiring!