Remove the following requirements: MIVOT first child of the

[lmichel]

More flexible location of the MIVOT block.
It must enclosed in a RESOURCE@type=meta which must be enclosed in another RESOURCE.

[mcdittmar]

Looks good to me.

[msdemlei]

Hm – why do you keep the RESOURCE[type="meta"] wrapper at all? IIRC its only purpose was to not require changes to the VOTable schema when there was a single VO-DML block somewhere near the top of VOTABLE.

Now that VODML is a child of RESOURCE anyway: Why not write

...

directly? It's schema-ok, simpler, and gives VO-DML a more predictable location by schema (you can mix RESOURCE-s and TABLE-s, but foreign elements are always at the end).

Other than that, I'd use the opportunity to drop the line starting with "This extra feature" -- sure, it's always nice to motivate designs, but I think the "don't touch VOTable" thing is already mentioned in the introduction.

[Bonnarel]

Hi Markus,    This answer to be sure what you are proposing :    Adding the VODML block at the end of any RESOURCE (after the standard Sequence as stated in the  xsd schema) without creating a specific RESOURCE (type = meta) encompassing the VODML block and only it ????     In other words suppressing one level ? Cheers François Le 20/12/2022 à 08:15, msdemlei a écrit :

…

Hm – why do you keep the RESOURCE[type="meta"] wrapper at all? IIRC its only purpose was to not require changes to the VOTable schema when there was a single VO-DML block somewhere near the top of VOTABLE. Now that VODML is a child of RESOURCE anyway: Why not write ... directly? It's schema-ok, simpler, and gives VO-DML a more predictable location by schema (you can mix RESOURCE-s and TABLE-s, but foreign elements are always at the end). Other than that, I'd use the opportunity to drop the line starting with "This extra feature" -- sure, it's always nice to motivate designs, but I think the "don't touch VOTable" thing is already mentioned in the introduction. — Reply to this email directly, view it on GitHub <#174 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AMP5LTFS6C6TG3KFSFS6DVTWOFMJLANCNFSM6AAAAAATDMYEGM>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[Bonnarel]

Sorry Markus, I read again your email from December the 15th. It explains clearly what you want. So forget my previous answer below. Your answer to my question will obviously be "yes". Cheers François Le 20/12/2022 à 10:25, BONNAREL FRANCOIS a écrit :

…

Hi Markus,    This answer to be sure what you are proposing :    Adding the VODML block at the end of any RESOURCE (after the standard Sequence as stated in the xsd schema) without creating a specific RESOURCE (type = meta) encompassing the VODML block and only it ????     In other words suppressing one level ? Cheers François Le 20/12/2022 à 08:15, msdemlei a écrit : > > Hm – why do you keep the RESOURCE[type="meta"] wrapper at all? IIRC > its only purpose was to not require changes to the VOTable schema > when there was a single VO-DML block somewhere near the top of VOTABLE. > > Now that VODML is a child of RESOURCE anyway: Why not write > > ... > > directly? It's schema-ok, simpler, and gives VO-DML a more > predictable location by schema (you can mix RESOURCE-s and TABLE-s, > but foreign elements are always at the end). > > Other than that, I'd use the opportunity to drop the line starting > with "This extra feature" -- sure, it's always nice to motivate > designs, but I think the "don't touch VOTable" thing is already > mentioned in the introduction. > > — > Reply to this email directly, view it on GitHub > <#174 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AMP5LTFS6C6TG3KFSFS6DVTWOFMJLANCNFSM6AAAAAATDMYEGM>. > You are receiving this because you are subscribed to this > thread.Message ID: > ***@***.***> >

[lmichel]

The content of RESOURCE@type=meta is meant to be descriptive only (section 3.4).

Should we consider the MIVOT block as being descriptive only? I would say yes since it provides a model view on the data. This is certainly questionable however.
We can drop the type=meta requirement if this bothers the implementer job.

The other suggestion is to suppress the requirement for the MIVOT block to be into a specific RESOURCE.
This is feasible but one argument for this MR was not to force the MIVOT block to be in a mandatory location (the head of the host resource). If we drop the encompassing RESOURCE for MIVOT, we require the mapping block to be at the bottom of the host resource: Its location is forced again and therefore, we lose the flexibility we got from the actual MR.

I propose to merge the MR as it is in order to provide an uptodate document for the reviewers and to let both questions:

• encompassing RESOURCE or not open
• type=meta or not
  for a future PR