utype for STC region in SIAP query response

[Mark Taylor]

On Sun, 18 Dec 2011, Douglas Tody wrote:

> On Thu, 15 Dec 2011, Alberto Micol wrote:
> 
> > On 2 Sep 2011, at 01:40, Douglas Tody wrote:
> > 
> > > This would be a fine solution, considering only STC; however it is
> > > perfectly legal for a DM to be based upon other models (in a way defined
> > > by the new model such as Char or SIA) and define new, more
> > > application-specific Utypes.  There is an especially strong argument for
> > > this for essential elements of the new model so that we have a well
> > > defined and self consistent model.  "Falling through" to reference
> > > arbitrary elements of another model, with its own externally defined
> > > namespace, is fine for extension but could significantly expand the
> > > complexity of the new model as a client application might then need to
> > > fully understand multiple models to be able to deal with the data.
> > 
> > There are two kinds of clients: it seems to me that Doug here above
> > refers to client applications that deal with a specific data model,
> > while what I'm going to describe is the case of a generic client.
>    [...]
> > 
> > What is the magic bit that will allow Aladin to recognise a given FIELD as a
> > footprint?
> > 
> > It cannot be the UTYPE, if every data model uses a different UTYPE for a
> > footprint.
> 
> Well this is the key point; yes we can standardize the core model and
> the UTYPE used for this purpose and they do not need to be different
> despite being included in different models.  Yes the namespace (dataset
> class or context) may be different for different classes of data, but
> the UTYPE, minus the namespace prefix defining the context where it
> used, can be the same and can be defined to meant the same thing.  This
> is how UTYPEs have historically been used up to now, and we can
> formalize this further in the UTYPE spec (hopefully without
> over-complicating the mechanism).
> 
> So as Francois mentions we already have a UTYPE for the overall dataset
> footprint:
> 
>     Char.SpatialAxis.Coverage.Support.Area
> 
> This is currently what is used in Obscore, SSA, and Spectrum, and soon
> also in SpectralDM, SED, TimeSeries, SIAV2, etc.  So it already provides
> a consistent way to specify a simple footprint, or very nearly so.
> Obviously we do want this to be consistent across all these models,
> along with many other things.

This option seems to me to abuse the way that namespaces are intended
to be used, and lacks the flexibility and power of both Markus's and
Norman's suggestions.  It looks eminently comprehensible and easy to use
from both provider and consumer points of view though.  Gets my vote.

Mark

--
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
m.b.taylor at bris.ac.uk +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/