utype for STC region in SIAP query response

[Markus Demleitner]

Hi Doug, Hi list,

On Mon, Sep 05, 2011 at 04:16:02PM -0600, Douglas Tody wrote:
> directly addressed by the protocol, the standard protocol mechanisms
> should be used instead.  Otherwise we no longer have a standard protocol
> and a client application will not know what to look for (no existing
> clients will be able to use this feature of your service Markus).  In

The STC embedding has deliberately been designed to not clobber the
FIELD's utype attribute, so there's no technical reason for
"instead" (and, apart from a moderate amount of work, no other I can
see either).  

However, I still maintain there's a good reason to include standard
STC metadata whether or not a specific data model has mechanisms of
its own: Generic VOTable consumers do not need to know lots of data
models and utypes to make sense of coordinates.  That each
protocol/DM will have different utype prefixes doesn't help either.

That no client so far can make sense of, erm, "standard" STC metadata
is regrettable, but that's only going to change when the data
providers start embedding such metadata.  The situation right now is
that outside of some protocols, we only have a deprecated (and crude)
mechanism to communicate STC metadata in VOTables (COOSYS) -- don't
you agree that we should change this?

Cheers,

        Markus