MIVOT implementor feedback 1: RESOURCE location

[Laurent Michel]

Dear DM,

I confirm that the only (weak) requirement for this feature was to avoid mixing the MIVOT block with VOTable stuff.
No problem to drop it off.

LM

Le 14/12/2022 à 18:31, CresitelloDittmar, Mark a écrit :
> 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 <mailto: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
> 

--
English version: https: //www.deepl.com/translator
-- 
jesuischarlie/Tunis/Paris/Bruxelles/Berlin

Laurent Michel
SSC XMM-Newton
Tél : +33 (0)3 68 85 24 37
Fax : +33 (0)3 )3 68 85 24 32
Université de Strasbourg <http://www.unistra.fr>
Observatoire Astronomique
11 Rue de l'Université
F - 67200 Strasbourg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: laurent_michel.vcf
Type: text/vcard
Size: 406 bytes
Desc: not available
URL: <http://mail.ivoa.net/pipermail/dm/attachments/20221216/ff66957a/attachment.vcf>