ImageDM: what does extension mean?

[Douglas Tody]

On Tue, 29 Oct 2013, CresitelloDittmar, Mark wrote:

> The composite models (Image, Spectral) should 'refer' to the component
> models.
> They can include summary or semantic details, but should defer to the
> original
> for definition and detail.  This reduces the 'bloat' in models and these
> small variations
> we are struggling with due to migrations and 'simplifications'.
> 
> For the ObsCore extension, there are some details at the top level which
> need to be resolved (see the 'Convergence' thread).  But this question
> brings
> up a good point w.r.t. serialization.  Serializations include the model
> 'prefix'.
> For ObsCore serializations, this is 'obs'?, other models will have a
> different
> prefix.  Optimally, an ObsCore aware application should be able to ignore
> the
> prefix and recognize the content.  This would probably work, but only
> because
> it is a TOP level model.
> 
> This is similar to discussions which went on for lower level objects,
> where the
> practice of combining utype strings make it impossible for a generic
> utility
> to identify the axes (for example) within a model an plot them.

Things can get very complicated for a client application if they have to
be prepared for any version of any data model (noted by the DM prefix)
cropping up in a dataset instance.  That is what it means to open up the
DM namespace in a fundamental way in a top level composite model like
Observation, Image, Spectrum, etc.  Using a global "obs:" or "im:" for
the top level model, and defining this model to explicitly include
specified versions of the required referenced component models,
constrains what is defined as part of the standard top level model while
allowing re-use of standard component models.  It is still possible by
extension to include instances of other models, but anything required by
the specific DM application i.e. top level model (obstap, imagedm, etc.)
is explicilty integrated into the composite model.

This is enough to have a workable scheme, as we do now.  The next step
might be to, *external to a DM instance*, formally define the data
model, which would allow us to do things like note the relationship to
other models in a machine-readable fashion.  This would allow the more
advanced DM manipulations without complicating basic usage.  It is what
I have always hoped the new formalized Utype mechanism would permit, and
would be backwards compatible with our current models, addressing the
issue Matthew mentions.  Hopefully something like this can come along in
the future, but it is out of scope for what we are doing to get
something usable for image/cube access this fall.

 	- Doug