MIVOT implementor feedback 1: RESOURCE location

[CresitelloDittmar, Mark]

Markus,

Thanks for the report!

If I recall, it was originally that the annotation syntax would be in the
first RESOURCE of the VOTABLE, making it a simple insert with minimal
impact on the native VOTABLE.  When it moved into the 'results' RESOURCE, I
think we wanted it to retain that 'minimal impact' on the native VOTABLE,
so required it to be the first child.

I think that operationally it shouldn't matter where it resides within the
parent RESOURCE since there can be only 1 annotation block per 'results'
block.

Mark




On Wed, Dec 14, 2022 at 5:31 AM Markus Demleitner <
msdemlei at ari.uni-heidelberg.de> wrote:

> Dear DM,
>
> I'm currently implementing a (small) part of MIVOT into DaCHS.  While
> doing that, I stumbled into the regulation that
>
>   The mapping block: [...] MUST be the first child of the RESOURCE
>   containing the data to be annotated.
>
> Is there a strong reason for that requirement?
>
> For one, it conflicts (somewhat) with VOTable.  VOTable's content
> model for RESOURCE is:
>
>   DESCRIPTION?, INFO*, (COOSYS | TIMESYS | GROUP | PARAM)*, (LINK*,
>   (TABLE | RESOURCE), INFO*)*, {any}*
>
> So, this regulation would rule out DESCRIPTION, INFO, COOSYS,
> TIMESYS, GROUP, and PARAM on any RESOURCE annotated with MIVOT unless
> we change VOTable, and that would immediately preclude the use of
> MIVOT with DALI-compliant protocols, since DALI states:
>
>   The primary RESOURCE element must contain, before the TABLE
>   element, an INFO element with attribute name valued QUERY_STATUS.
>
> And, frankly, it's an implementational pain anyway; DaCHS has some
> logic to sort additional RESOURCE-s after the TABLE-s, mainly to keep
> tables with datalink tidy; sure, IIRC we could sort the datalink
> RESOURCE-s to near the top, too, but I try to avoid changes of this
> type unless there's a really good reason for them.  And treating
> datalink and MIVOT blocks differently is another uglification I'd
> prefer to avoid.
>
> So: can we drop that first-child requirement?  What would break if we
> did?
>
>            -- Markus
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dm/attachments/20221214/d9c2bfc2/attachment.htm>