utype for STC region in SIAP query response

[Douglas Tody]

Hi -

The extension mechanism used in the DAL services allows pass through of
arbitrary metadata so this is technically legal, and could work to pass
arbitrary STC metadata in cases where some feature is needed which is
not addressed by the standard protocol.  However in cases which are
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
this case the Char model which is used in all the DAL services (SSA,
ObsTAP/ObsCoreDM, SIAV2, and soon SED, TimeSeries) provides a mechanism
for describing coverage in the different measurement axes, and this is
what should be used for these protocols.

 	- Doug



On Mon, 5 Sep 2011, Markus Demleitner wrote:

> Dear Colleagues,
>
> On Thu, Sep 01, 2011 at 11:16:35AM +0200, Francois Bonnarel wrote:
>> Hi Thomas,
>>    To complete my answer to Markus
>>     we could have something like
>>        <FIELD name="fov" unit="deg" xtype="STC-s" datatype="char"
>> arraysize="*" utype="sia:Char.SpatialAxis.Coverage.Support.Area" >
>>           I think something like this can be proposed (if not yet the
>> case) in SIA2...
>>       this will be consistent with ObsTap... and could also be
>> included in the next version of SSA et al.
>
> Allow me to once again advertise the use of "standard" STC groups[1] --
> while it's fine (and indeed necessary in many cases) for
> protocol-specific data models have their own utypes for STC data,
> multiprotocol clients greatly benefit if fields containing STC
> information are marked up as such using the STC data model itself.
> And the current problem -- identifying which field in a SIAP response
> contains a region -- would be more or less solved just based on
> existing IVOA standards.
>
> So, I'd suggest to recommend including an STC group to SIAP responses
> (which, actually, is already implicitely done by the VOTable spec).
> For SIAP, this is pretty much boilerplate and looks like this for my
> SIAP services (fix the refs as necessary for you, and you may need to
> adapt the coverage's utype):
>
>      <GROUP utype="stc:CatalogEntryLocation">
>        <PARAM datatype="char"
>          utype="stc:AstroCoordSystem.SpaceFrame.CoordFlavor"
>          arraysize="*" value="SPHERICAL" name="CoordFlavor"/>
>        <PARAM datatype="char"
>          utype="stc:AstroCoordSystem.SpaceFrame.CoordRefFrame"
>          arraysize="*" value="ICRS" name="CoordRefFrame"/>
>        <PARAM datatype="char"
>          utype="stc:AstroCoordSystem.TimeFrame.TimeScale"
>          arraysize="*" value="TT" name="TimeScale"/>
>        <PARAM datatype="char" utype="stc:DataModel.URI" arraysize="*"
>          value="http://www.ivoa.net/xml/STC/stc-v1.30.xsd" name="URI"/>
>        <FIELDref utype="stc:AstroCoordArea.Polygon" ref="coverage"/>
>        <FIELDref utype="stc:AstroCoordArea.SpectralInterval.HiLimit"
>          ref="bandpassHi"/>
>        <FIELDref utype="stc:AstroCoordArea.SpectralInterval.LoLimit"
>          ref="bandpassLo"/>
>        <FIELDref utype="stc:AstroCoords.Position2D.Value2.C1"
>          ref="centerAlpha"/>
>        <FIELDref utype="stc:AstroCoords.Position2D.Value2.C2"
>          ref="centerDelta"/>
>        <FIELDref utype="stc:AstroCoords.Spectral.Value" ref="bandpassRefval"/>
>        <FIELDref utype="stc:AstroCoords.Time.TimeInstant" ref="dateObs"/>
>      </GROUP>
>
> To identify the column containing the region, you'd look for
> (probably in this sequence, xpath syntax):
>
> GROUP[@utype='stc:CatalogEntryLocation']/FIELDref[@utype="stc:AstroCoordArea.Polygon"]
> GROUP[@utype='stc:CatalogEntryLocation']/FIELDref[@utype="stc:AstroCoordArea.Convex"]
> GROUP[@utype='stc:CatalogEntryLocation']/FIELDref[@utype="stc:AstroCoordArea.Ellipse"]
> GROUP[@utype='stc:CatalogEntryLocation']/FIELDref[@utype="stc:AstroCoordArea.Circle"]
> GROUP[@utype='stc:CatalogEntryLocation']/FIELDref[@utype="stc:AstroCoordArea.Box"]
>
> -- not too simple, but still preferable to having to know every data
> model.
>
> Moral: The rotten substitution groups in STC-X again mess things up
> royally, and it would have been much nicer if STC-X had just defined,
> say, Region and an attribute shape (or something), but it's too late
> to cry over spilled milk now.  Since I can't see anybody moving to
> review STC and its serializations, I'd plea to use what we have
> rather than to invent new workarounds every time we encounter an
> STC-related problem.
>
> Cheers,
>
>            Markus
>
>
> [1] Ok, while the STC data model is a recommendation, the specific
> form of the group is just a note,
> http://www.ivoa.net/Documents/Notes/VOTableSTC/ (as is STC-X) -- but
> the note hopefully reflects a wide consensus among the interested
> parties.
>