MIVOT implementor feedback 1: RESOURCE location

[Markus Demleitner]

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