DM Workshop wrap-up
Mark Taylor
m.b.taylor at bristol.ac.uk
Tue Aug 24 15:38:39 CEST 2021
Gerard,
the xmlns:xxx namespacing attribute just has to be in scope wherever
the xxx namespace is used, so it's fine to put it in the root VOTABLE
element. Since this is at the level of XML syntax though, it may not
be wise to mandate that it goes there or for client software to rely
on its specific form or position.
I wouldn't want to add requirements to normal VODML usage that make
my "topcat session" usecase more convenient, since it's far from the
"normal" way that VODML is likely to be used, for which I guess a
single VODML element per document will be a good choice.
I'm happy to work round inconveniences; I'd just rather that what
I want to do isn't flat out illegal.
Mark
On Tue, 24 Aug 2021, Gerard Lemson wrote:
> Hi Laurent and Mark
> I think making RESOURCEs the containers of set of TABLEs all mapped as a group for a given (set of) model(s) makes sense.
> Also adds some nice semantics to the RESOURCE element.
>
> Would we need an explicit xmlns:dm-mapping declaration for the vo-dml-mapping schema's targetNamespace in each VODML element?
> Or could that go inside the root VOTABLE element? This could be used by parsers to infer that vo-dml-mapped elements may be encountered.
> Wherever it goes, is it a MUST to use the prefix 'dm-mapping'?
> I guess that would simplify Mark's use case of gathering a bunch of votables into one?
>
> Cheers
> Gerard
>
>
> > -----Original Message-----
> > From: dm-bounces at ivoa.net <dm-bounces at ivoa.net> On Behalf Of Mark
> > Taylor
> > Sent: Tuesday, August 24, 2021 8:47
> > To: Laurent Michel <laurent.michel at astro.unistra.fr>
> > Cc: dm at ivoa.net
> > Subject: Re: DM Workshop wrap-up
> >
> > 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.
> >
> > 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.
> >
> > 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%2Fgith
> > > ub.com%2Fivoa-
> > std%2FVOTable%2F&data=04%7C01%7Cglemson1%40jhu.edu%7
> > >
> > Ca6352f3d0b8545668f8e08d966fd5e41%7C9fa4f438b1e6473b803f86f8aedf0de
> > c%7
> > >
> > C0%7C0%7C637654060675797377%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM
> > C4wLjAwMD
> > >
> > AiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=JP
> > 4j
> > > r5NzNhlHYgwOTlet07FUzvjAwGWrDYCfq7gKWjs%3D&reserved=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.
> > >
> > deepl.com%2Ftranslator&data=04%7C01%7Cglemson1%40jhu.edu%7Ca6
> > 352f3
> > >
> > d0b8545668f8e08d966fd5e41%7C9fa4f438b1e6473b803f86f8aedf0dec%7C0%7
> > C0%7
> > >
> > C637654060675807368%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM
> > DAiLCJQIj
> > >
> > oiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=PtRNsWV
> > 9Vrq6
> > > 9%2BBUPjA7BlZoQEgSKurFo%2FbAXNtKxYQ%3D&reserved=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%7Ca6352f3d0b85
> > 4566
> > >
> > 8f8e08d966fd5e41%7C9fa4f438b1e6473b803f86f8aedf0dec%7C0%7C0%7C6376
> > 5406
> > >
> > 0675807368%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoi
> > V2luMzI
> > >
> > iLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ywbUMN0Km5tgk45
> > jBR0vv
> > > ZmyISyafdyPVdMBPim9%2BLc%3D&reserved=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
> > Ca6352f3d0b8545668f8e08d966fd5e41%7C9fa4f438b1e6473b803f86f8aedf0de
> > c%7C0%7C0%7C637654060675807368%7CUnknown%7CTWFpbGZsb3d8eyJWIj
> > oiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C100
> > 0&sdata=eiBaOQr5dtAQ5wPyzrPzibDQ7Kat4HKfS18sDAUMFEE%3D&r
> > eserved=0
>
--
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