open:wp4:wp4techforum2
Differences
This shows you the differences between two versions of the page.
|
open:wp4:wp4techforum2 [2016/03/18 18:00] noddle |
open:wp4:wp4techforum2 [2016/12/20 09:11] (current) genova |
||
|---|---|---|---|
| Line 3: | Line 3: | ||
| The Forums enable technology discussion involving the framework developers and ESFRI project staff, to develop technical collaboration and exchange good practice - establishing a European strategy for IVOA and RDA activities | The Forums enable technology discussion involving the framework developers and ESFRI project staff, to develop technical collaboration and exchange good practice - establishing a European strategy for IVOA and RDA activities | ||
| - | (Top level DADI page: [[open:wp4:start|WP4: Data Access and Data Interoperability]]) | + | (Top level DADI page: [[open:wp4:start|WP4: Data Access, Discovery and Interoperability (DADI)]]) |
| ==== Dates ==== | ==== Dates ==== | ||
| Meeting: 7 & 8 March, 2016 | Meeting: 7 & 8 March, 2016 | ||
| Line 20: | Line 21: | ||
| ==== Dinner ==== | ==== Dinner ==== | ||
| - | A conference dinner will be held Monday evening. This needs to be confirmed as soon as possible so please indicate whether you wish to attend. | + | A working dinner will be held Monday evening. This needs to be confirmed as soon as possible so please indicate whether you wish to attend. |
| ==== Agenda ==== | ==== Agenda ==== | ||
| Line 88: | Line 89: | ||
| | **3. GWsky discussion //(Notes author : Giuseppe)//** | | | **3. GWsky discussion //(Notes author : Giuseppe)//** | | ||
| + | | Interesting discussions on the possibility of implementing MOC - dedicated to the coverage manipulations - and HiPS to manipulate data (pixels, catalog, sources, etc.). This will be done using the Aladin script commands via SAMP. In particular, the HEALPix pixels contained in a certain probability will be considered for faster loading of catalogs or images. | | ||
| + | In addition, we have discussed to develop a graphical user interface (Tkinter?) | ||
| + | and to redirect the output of GWsky to a printable page. | ||
| + | In general, the use of SAMP has been highly appreciated and encouraged for any future development | ||
| | **4. ADQL //(Notes author : Dave)//** | | | **4. ADQL //(Notes author : Dave)//** | | ||
| Line 95: | Line 100: | ||
| | //**OFFSET/LIMIT**//\\ The current consensus on the mailing list is to accept OFFSET without LIMIT.\\ //**TODO - Dave**// : Write a page on the IVOA wiki summarising the OFFSET/LIMIT syntax for each of the main platforms, PostgreSQL, MySQL, SQLServer, Oracle etc.\\ If a database platform requires LIMIT, the proposed work around is to specify either (MAX_ROWS + 1) or (MAX_LONG).\\ However, many of the text books and online manuals describe using OFFSET with LIMIT.\\ //**TODO - Dave**// : Propose to the mailing list that we accept OFFSET with LIMIT, allowing LIMIT as a synonym for TOP.\\ The only reason for this is to make ADQL compatible with 90% of the text books and online manuals.\\ Hopefully this should be a short yes/no discussion and then accept the consensus for the v2.1 specification.\\ //**TODO - Dave**// : Update the text of the v2.1 specification to include OFFSET (with/without LIMIT as agreed) | | | //**OFFSET/LIMIT**//\\ The current consensus on the mailing list is to accept OFFSET without LIMIT.\\ //**TODO - Dave**// : Write a page on the IVOA wiki summarising the OFFSET/LIMIT syntax for each of the main platforms, PostgreSQL, MySQL, SQLServer, Oracle etc.\\ If a database platform requires LIMIT, the proposed work around is to specify either (MAX_ROWS + 1) or (MAX_LONG).\\ However, many of the text books and online manuals describe using OFFSET with LIMIT.\\ //**TODO - Dave**// : Propose to the mailing list that we accept OFFSET with LIMIT, allowing LIMIT as a synonym for TOP.\\ The only reason for this is to make ADQL compatible with 90% of the text books and online manuals.\\ Hopefully this should be a short yes/no discussion and then accept the consensus for the v2.1 specification.\\ //**TODO - Dave**// : Update the text of the v2.1 specification to include OFFSET (with/without LIMIT as agreed) | | ||
| | //**Hexadecimal literals**//\\ Adding hexadecimal literals to the BNF grammar has raised some issues.\\ The simple way to add them would be to extend numeric literal to allow both decimal and hexadecimal values.\\ If we follow a strict interpretation of the BNF, then allowing both decimal and hexadecimal values for numeric literals causes some odd side effects, particularly with scientific notation and exponents.\\ //**TODO - Dave**// : Write a page on the IVOA wiki detailing the issues.\\ //**TODO - Dave**// : Propose to the mailing list that we accept\\ a) Numeric literals may contain both decimal and hexadecimal values but there are places where hexadecimal values do not make sense, and developers should do the right thing.\\ and\\ b) The BNF grammar is not a definitive machine readable specification and there may be some unintended side effects in it.\\ //**TODO - Dave**// : If consensus is to accept a flexible interpretation of the BNF, update the text of the v2.1 specification to reflect this.\\ If consensus is for a strict interpretation of the BNF, then discussion on validating a strict BNF grammar will need to be continued at the May interop. | | | //**Hexadecimal literals**//\\ Adding hexadecimal literals to the BNF grammar has raised some issues.\\ The simple way to add them would be to extend numeric literal to allow both decimal and hexadecimal values.\\ If we follow a strict interpretation of the BNF, then allowing both decimal and hexadecimal values for numeric literals causes some odd side effects, particularly with scientific notation and exponents.\\ //**TODO - Dave**// : Write a page on the IVOA wiki detailing the issues.\\ //**TODO - Dave**// : Propose to the mailing list that we accept\\ a) Numeric literals may contain both decimal and hexadecimal values but there are places where hexadecimal values do not make sense, and developers should do the right thing.\\ and\\ b) The BNF grammar is not a definitive machine readable specification and there may be some unintended side effects in it.\\ //**TODO - Dave**// : If consensus is to accept a flexible interpretation of the BNF, update the text of the v2.1 specification to reflect this.\\ If consensus is for a strict interpretation of the BNF, then discussion on validating a strict BNF grammar will need to be continued at the May interop. | | ||
| + | | //**Crossmatch function**//\\ The mailing list has yet to agree on a consensus for the crossmatch function.\\ //**TODO - Marco**// : Write an email to the mailing list summarising the options and starting a new discussion thread.\\ //**TODO - Dave**// : If consensus is reached, update the text of the v2.1 specification to include the crossmatch function.\\ If no consensus is reached, then discussion of the crossmatch function can be continued at the May interop. | | ||
| + | | //**Specification review**//\\ The plan is to try to resolve the outstanding issues during March, and have an updated version of the specification ready for review in April.\\ If we are not able to reach consensus on an issue, then it should be deferred to the next version of the specification. | | ||
| | **5. Rendering plots server-side //(Notes author : Mark)//** | | | **5. Rendering plots server-side //(Notes author : Mark)//** | | ||
| Line 117: | Line 123: | ||
| | **7. pgSphere //(Notes author : Markus N.)//** | | | **7. pgSphere //(Notes author : Markus N.)//** | | ||
| - | | //minutes by Markus Nullmeier, draft to be checked with group.// | | + | | //minutes by Markus Nullmeier// | |
| | // Dave Morris, Keith Noddle, Markus Nullmeier, Mathieu Servillat, | | // Dave Morris, Keith Noddle, Markus Nullmeier, Mathieu Servillat, | ||
| Mike Sipior (via Skype), Paul Harrison, Stefano Zampieri, | Mike Sipior (via Skype), Paul Harrison, Stefano Zampieri, | ||
| Line 129: | Line 135: | ||
| | **8. SODA//(Notes author : François)//** | | | **8. SODA//(Notes author : François)//** | | ||
| + | |SODA is the last "open" element of the "multi-dimensional standard caravan", a top priority of the IVOA as well as ASTERICS. The debate on architecture for expanding the requirements beyond those defined by the IVOA Committee for Scientific Priorities continued during the Hack-A-Thon and it was not possible to reach a consensus at that time. | | ||
| + | |**NB** (added after the Cape Town Interop): The discussion continued in the IVOA DAL Working Group after the meeting and a consensus was finally reached on an incremental approach. It was presented in Cape Town and is the basis of SODA Proposed Recommendation. | | ||
| ==== Organisation ==== | ==== Organisation ==== | ||
| **Program Organising Committee:**Keith Noddle, Mark Allen (co-chairs) | **Program Organising Committee:**Keith Noddle, Mark Allen (co-chairs) | ||
open/wp4/wp4techforum2.1458320414.txt.gz · Last modified: 2016/03/18 18:00 by noddle
Page Tools
Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Share Alike 3.0 Unported
