ImageDM: what does extension mean?

[Matthew Graham]

Hi,

A tangentially-related question: I assume that this DM work is proceeding using the old way of doing UTypes. What effort will be required to adopt the new way down the line? What is the roadmap for such integration - ImageDM 2.0? Will this actually ever happen or will the argument be that we already have code out there using the "old" ImageDM for cubes and so the implementation cost is too high to use the new?

	Cheers,

	Matthew

On Oct 29, 2013, at 9:26 AM, CresitelloDittmar, Mark wrote:

> 
> On Fri, Oct 25, 2013 at 12:57 PM, Ray Plante <rplante at illinois.edu> wrote:
> 
> My question is, what does it mean technically for ImageDM to "extend"
> ObsCore?
> 
> One result we might expect is that the ImageDM would not be explicitly
> "re-defining" the ObsCore metadata and UTypes; rather it would point
> to the ObsCore document for its definition.  Is there more to it,
> though?  Is there something implied about the structure of UML models?
> How about serializations?  Should a client that is only ObsCore-aware
> be able to interpret the ObsCore portion of an ImageDM serialization?
> What does it mean for how we define the extension metadata?
> 
> 
> In my opinion, this is the way to go.
> 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.
> 
> Mark

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/dm/attachments/20131029/ff0caaaf/attachment.html>