utype for STC region in SIAP query response

[Douglas Tody]

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.

I suggest that this is sufficient for simple "bounding box" type
footprints.  As I mentioned in the original email quoted above, it is
also possible with our current UTYPE mechanisms to pass-through bits of
external data models such as STC (note STC is also already the basis for
Char.SpatialAxis.Coverage.Support.Area although usage is somewhat
restricted to keep the compexity manageable).  This could possibly be
used as an extension mechanism to define more complex footprints if
desired; if so we might want to separate it out as a separate footprint
object as it is starting to get complicated.  Nonetheless the simpler
representation is already in use, should be provided if nothing else,
and can be standardized across all our dataset classes.

 	- Doug