DM Workshop wrap-up
Mark Taylor
m.b.taylor at bristol.ac.uk
Tue Aug 24 15:44:10 CEST 2021
Yes, I'd go along with that. If it was essential to modify the VOTable
standard/schema to accommodate VODML I wouldn't necessarily argue
against that, but I don't think that it is. As Gerard says, we can
just write in some standards text where the VODML MUST or SHOULD appear
in the RESOURCE structure without that being enforced by the XSD.
There are already many ways you can write a schema-valid but illegal
VOTable (otherwise votlint would be out of a job).
On Tue, 24 Aug 2021, Gerard Lemson wrote:
> Hi Laurent
> I thought the idea was not to have a change to the VOTable standard at all.
> Can we not "simply" have the mapping standard prescribe a particular *usage* of VOTable instead?
> Gerard
>
>
>
> > -----Original Message-----
> > From: dm-bounces at ivoa.net <dm-bounces at ivoa.net> On Behalf Of Laurent
> > Michel
> > Sent: Tuesday, August 24, 2021 9:35
> > To: Mark Taylor <m.b.taylor at bristol.ac.uk>
> > Cc: dm at ivoa.net
> > Subject: Re: DM Workshop wrap-up
> >
> > 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://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub
> > .com%2Fivoa-
> > std%2FVOTable%2F&data=04%7C01%7Cglemson1%40jhu.edu%7Cd09d00
> > c343c8470738eb08d9670411f9%7C9fa4f438b1e6473b803f86f8aedf0dec%7C0%
> > 7C0%7C637654089467731603%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wL
> > jAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&s
> > data=MGAAOsQZi6L1vSPj9gT%2FYNjLjLfU6JmlKrQJbMJmA48%3D&reserve
> > d=0 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://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.d
> > eepl.com%2Ftranslator&data=04%7C01%7Cglemson1%40jhu.edu%7Cd09
> > d00c343c8470738eb08d9670411f9%7C9fa4f438b1e6473b803f86f8aedf0dec%7
> > C0%7C0%7C637654089467731603%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM
> > C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&a
> > mp;sdata=iTPCLg%2B32dqm8welwoBgbJWyyLBuixcTO3UkTeOQ6lc%3D&re
> > served=0
> > >> --
> > >> 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
> > <https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.
> > unistra.fr%2F&data=04%7C01%7Cglemson1%40jhu.edu%7Cd09d00c343c8
> > 470738eb08d9670411f9%7C9fa4f438b1e6473b803f86f8aedf0dec%7C0%7C0%7
> > C637654089467731603%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM
> > DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=
> > %2FW30DazZEMs7c21i%2BSmQT1voyCpFDNDyrVnNUreOAUU%3D&reserv
> > ed=0>
> > >> 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
> > https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.st
> > ar.bristol.ac.uk%2F~mbt%2F&data=04%7C01%7Cglemson1%40jhu.edu%7
> > Cd09d00c343c8470738eb08d9670411f9%7C9fa4f438b1e6473b803f86f8aedf0de
> > c%7C0%7C0%7C637654089467731603%7CUnknown%7CTWFpbGZsb3d8eyJWIj
> > oiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C100
> > 0&sdata=Ln9%2FsHp%2BLq2cyTzjauKRK7UBZQ8GwTb7237zm0vsZfg%3D&
> > amp;reserved=0
> > >
> >
> > --
> > English version:
> > https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.d
> > eepl.com%2Ftranslator&data=04%7C01%7Cglemson1%40jhu.edu%7Cd09
> > d00c343c8470738eb08d9670411f9%7C9fa4f438b1e6473b803f86f8aedf0dec%7
> > C0%7C0%7C637654089467731603%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM
> > C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&a
> > mp;sdata=iTPCLg%2B32dqm8welwoBgbJWyyLBuixcTO3UkTeOQ6lc%3D&re
> > served=0
> > --
> > 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
> > <https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.
> > unistra.fr%2F&data=04%7C01%7Cglemson1%40jhu.edu%7Cd09d00c343c8
> > 470738eb08d9670411f9%7C9fa4f438b1e6473b803f86f8aedf0dec%7C0%7C0%7
> > C637654089467731603%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM
> > DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=
> > %2FW30DazZEMs7c21i%2BSmQT1voyCpFDNDyrVnNUreOAUU%3D&reserv
> > ed=0>
> > 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/
More information about the dm
mailing list