This shows you the differences between two versions of the page.
open:wp4:wp4techforum5:hackathon [2019/02/28 07:11] bonnarel |
open:wp4:wp4techforum5:hackathon [2019/03/04 09:51] (current) morten |
||
---|---|---|---|
Line 11: | Line 11: | ||
I ) ObsCore and other VO standards in the context of EST and solar data | I ) ObsCore and other VO standards in the context of EST and solar data | ||
- | Participants Morten Frantz, Marco Guenter, Thomas Hederer, François Bonnarel | + | Participants Morten Franz, Thomas Hederer, Carl Schaffer, François Bonnarel |
Discussion was about how Solar data can be described and discovered using an ObsCOre/EPNTAP strategy. | Discussion was about how Solar data can be described and discovered using an ObsCOre/EPNTAP strategy. | ||
Line 44: | Line 44: | ||
**Wednesday 27 th at 2 PM : Tme Series + time //Salle de réunion downstairs//** | **Wednesday 27 th at 2 PM : Tme Series + time //Salle de réunion downstairs//** | ||
- | Ada, Mireille, Laurent, Marco (?) , Markus (?),François, Dave (?) to discuss TimeSeries next steps. | + | 17 attendants: Carlos Rodrigo, Markus Demleitner, Marco Molinaro, Mark Taylor, Stelios Voutsinas, Margarida Castro Neves, François-Xavier Pineau, Matthieu Baumann, Mireille Louys, Francois Bonnarel, Sebastien Derriere, Zheng Meyer-Zhao, Thomas Boch, Laurent Michel, Gilles Landais, Dave Morris, Ada Nebot |
- | | + | |
- | Topics : | + | 2 topics discussed: Discovery and Data Model |
- | DAL access | + | {{:open:wp4:wp4techforum5:20190228-time-series-summary.pdf|20190228-time-series-summary}} |
- | | + | |
- | Mapping | + | |
- | + | 1 topic need for further discussion and didn't have the time | |
- | Utypes | + | {{:open:wp4:wp4techforum5:timeserieshackhaton.pdf| DM annotation and utypes (focusing on data part)}} |
- | + | ||
- | {{open:wp4:wp4techforum5:timeserieshackhaton.pdf| The slides you avoided on need for DM annotation ... and utypes}} | + | |
**Wednesday 27 th at 4 PM : Provenance next steps Salle de Cours** | **Wednesday 27 th at 4 PM : Provenance next steps Salle de Cours** | ||
Line 107: | Line 105: | ||
Francoise (not available during Tuesday 26 Hack-a-Thon), Marco + ... | Francoise (not available during Tuesday 26 Hack-a-Thon), Marco + ... | ||
+ | |||
+ | ** Tuesday 16: Transition to ADQL 2.1 ** | ||
+ | |||
+ | Participants: Markus D., Mark T., Grégory, Stelios, Dave + others | ||
+ | |||
+ | Topic: How should servers and clients behave with respect to | ||
+ | minor version-sharp LANG parameters in TAP queries? | ||
+ | |||
+ | There is now ADQL 2.1, and services want to accept LANG=ADQL-2.1 (as per | ||
+ | TAP). Should they accept LANG=ADQL-2.0, too. Should they declare | ||
+ | version 2.0 in TAPRegExt? | ||
+ | |||
+ | Should we care about minor versions at all? Mark's use case: Syntax | ||
+ | highlighting. There already is a language selector in TOPCAT, filled | ||
+ | from language/version from TAPRegExt. | ||
+ | |||
+ | But then there's people with hacked scripts not looking at TAPRegExt, | ||
+ | perhaps just passing in LANG=ADQL-2.0 as gleaned from TAP. Should this | ||
+ | work on a 2.1 only service? Yes, because there's no way it could | ||
+ | (regularly) fail (ADQL 2.0 is a strict subset of ADQL 2.1). | ||
+ | |||
+ | Should an ADQL-2.1 server declare support for 2.0 in TAPRegExt? Mark | ||
+ | thinks he'd not turn off syntax highlighting just because he doesn't | ||
+ | know a version. Mark would prefer no separate declaration if the | ||
+ | behaviour is actually the same; users would worry about a meaningless | ||
+ | decision. It's a different thing if there's actually a behavioural | ||
+ | difference. So: No 2.0 declaration unless there's actually different | ||
+ | parsers behind it. | ||
+ | |||
+ | Have a versioning explanation in the ADQL spec: If you're a client and a | ||
+ | service only declares support for a newer minor version than you know, | ||
+ | use the latest artefacts you know about and hope for the best. Also | ||
+ | advse to leave out the version completely unless there's a strong reason | ||
+ | to specify it (as in: when using new features in a cross-service query | ||
+ | to fail early -- perhaps).. | ||
+ | |||
+ | ADQL-2.2 to a ADQL-2.1 service: most likely it'd work because most | ||
+ | people won't use the new versions. Even if it fails, perhaps "I don't | ||
+ | support DISTINCT ON" might be more useful than "I don't support ADQL | ||
+ | 2.2". But then: people who do this kind of thing should be able to read | ||
+ | "Just cut away the version number" error message, and this concrete | ||
+ | information might be useful in other use cases. So: Fail with higher | ||
+ | versions. |