<div dir="ltr">Markus,<div><br></div><div>Thanks for the report!</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Mark</div><div><br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Dec 14, 2022 at 5:31 AM Markus Demleitner <<a href="mailto:msdemlei@ari.uni-heidelberg.de">msdemlei@ari.uni-heidelberg.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Dear DM,<br>
<br>
I'm currently implementing a (small) part of MIVOT into DaCHS.  While<br>
doing that, I stumbled into the regulation that<br>
<br>
  The mapping block: [...] MUST be the first child of the RESOURCE<br>
  containing the data to be annotated.<br>
<br>
Is there a strong reason for that requirement?<br>
<br>
For one, it conflicts (somewhat) with VOTable.  VOTable's content<br>
model for RESOURCE is:<br>
<br>
  DESCRIPTION?, INFO*, (COOSYS | TIMESYS | GROUP | PARAM)*, (LINK*,<br>
  (TABLE | RESOURCE), INFO*)*, {any}*<br>
<br>
So, this regulation would rule out DESCRIPTION, INFO, COOSYS,<br>
TIMESYS, GROUP, and PARAM on any RESOURCE annotated with MIVOT unless<br>
we change VOTable, and that would immediately preclude the use of<br>
MIVOT with DALI-compliant protocols, since DALI states:<br>
<br>
  The primary RESOURCE element must contain, before the TABLE<br>
  element, an INFO element with attribute name valued QUERY_STATUS.<br>
<br>
And, frankly, it's an implementational pain anyway; DaCHS has some<br>
logic to sort additional RESOURCE-s after the TABLE-s, mainly to keep<br>
tables with datalink tidy; sure, IIRC we could sort the datalink<br>
RESOURCE-s to near the top, too, but I try to avoid changes of this<br>
type unless there's a really good reason for them.  And treating<br>
datalink and MIVOT blocks differently is another uglification I'd<br>
prefer to avoid.<br>
<br>
So: can we drop that first-child requirement?  What would break if we<br>
did?<br>
<br>
           -- Markus<br>
</blockquote></div>