DM Workshop wrap-up

[Laurent Michel]

Mark et al.

Le 24/08/2021 à 14:47, Mark Taylor a écrit :
> Laurent,
> 
> I agree that it's a good idea to organise things so that for each
> TABLE there is a single VODML element to which it corresponds
> (avoid mappings from multiple models).  The spirit of your proposed
> resource location rules seems to underline that without forbidding
> multiple VODML elements in the same VOTABLE document, which suits me.

OK, can some expert assess the consequence of this approach on the VOTable standard?
- opt #1: Defining specific complexType for the VODML RESOURCE?
    - e.g. <RESOURCE type="mapping">
    - This would allow put any constraint on it without breaking the backward compatibility
    - Can we introduce such a new type ("mapping") for a minor version (extension of the RESOURCE at type enumeration)?

- opt #2: using  <RESOURCE type="meta">
    - no new item in the schema, just a constraint saying that <RESOURCE type="meta"> must be the first child of the upper 
RESOURCE. (no idea how to do it with XSD1.0)
    - Does this break the backward compatibility? (I thing so)


> 
> My usage for TOPCAT sessions would therefore be to make sure that
> the scopes of different VODML elements don't overlap (by isolating
> within container RESOURCEs).  I would prefer to avoid merging
> multiple VODML elements into a single one since (a) that requires
> parsing of the VODML, and (b) it may be necessary to disentangle
> them again later, for instance when saving another session later
> with only a few of the same tables.
I understand.
I'm not saying you have to merge VODML blocks, I'm just saying if you need to do it, it should be possible.
If Topcat session items are stored in separate RESOURCES, there is no longer issues, things are well isolated with 0 or one 
specific mapping block per RESOURCE

Laurent
> 
> Mark
> 
> On Tue, 24 Aug 2021, Laurent Michel wrote:
> 
>> Hello,
>>
>> Here is my take after having read this thread.
>> I'll open an issue on https://github.com/ivoa-std/VOTable/ for the follow-up
>>
>> VODML block
>> ===========
>> - follows a separate schema
>> - prefixed with a specific name space e.g. <dm_mapping:VODML>
>> - enclosed in a <RESOURCE type="meta">
>>
>> VODML resource location
>> =======================
>> My take is that there is no need to support multiple VODML blocks since the
>> mapping syntax is not model-dependant. Assuming that dealing with annotated
>> VOTables is an extra job for both data providers and client developers, let's
>> keep this job as simple as possible. Our first use-case is to improve the
>> meta-data representation and it look wise to keep this in mind and not to
>> bother our-self with more complex features e.g. involving mappings on multiple
>> models:
>>
>> - The VODML RESOURCE must be enclosed in another RESOURCE
>> - The VODML RESOURCE must be the first child of the host RESOURCE
>>    - thus maxOccur=1 by construction
>> - The scope of the mapping blocks covers the whole content of that host
>> RESOURCE
>>
>> QUESTION:
>> - What are the consequences of such rules on both VOTable schema and standard?
>>
>> The TOPCAT session issue
>> ========================
>> My take:
>> - The structure of the mapping should easily (*) support the merge of
>> different mapping blocks since it is based on TEMPLATES that are
>> table-specific.
>> - The GLOBALS contents can be merged
>> - The TEMPLATES from all tables can be stacked
>>
>> Let's take an example:
>>
>> Votable #1:
>> RESOURCE
>>    RESOURCE
>>     VODML
>>       GLOBALS
>>          globals_1
>>       TEMPLATE (tableref=1_1)
>>       TEMPLATE (tableref=1_2)
>>   TABLE (ID=1_1)
>>   TABLE (ID=1_2)
>>
>> Votable #2:
>> RESOURCE
>>    RESOURCE
>>     VODML
>>       GLOBALS
>>          globals_2
>>       TEMPLATE (tableref=2_1)
>>       TEMPLATE (tableref=2_2)
>>   TABLE (ID=2_1)
>>   TABLE (ID=2_2)
>>
>> Topcat session:
>>
>> RESOURCE
>>    RESOURCE
>>     VODML
>>       GLOBALS
>>          globals_1
>>          globals_2
>>       TEMPLATE (tableref=1_1)
>>       TEMPLATE (tableref=1_2)
>>       TEMPLATE (tableref=2_1)
>>       TEMPLATE (tableref=2_2)
>>   TABLE (ID=1_1)
>>   TABLE (ID=1_2)
>>   TABLE (ID=2_1)
>>   TABLE (ID=2_2)
>>
>> - Difficulties will arrive when the same IDs will be used by both VOTables;
>> but this is an issue even without VODML mapping.
>>
>>
>> Laurent
>>
>> (*): in theory at least
>>
>>
>> --
>> 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
>>
> 
> --
> Mark Taylor  Astronomical Programmer  Physics, Bristol University, UK
> m.b.taylor at bristol.ac.uk          http://www.star.bristol.ac.uk/~mbt/
> 

--
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