Difference: ADQL-2_0-Err-3 (1 vs. 2)

Revision 22020-05-12 - MarcoMolinaro

Changed:
<
<
META TOPICPARENT name="WebPreferences"
>
>
META TOPICPARENT name="ADQL-2_0-Errata"
 

ADQL-2.0 Erratum 3: Coordinate system argument as a string literal

Author: Grégory Mantelet

Changed:
<
<
Date last changed: 2020-05-11
>
>
Date last changed: 2020-05-12
 

Rationale

Changed:
<
<
While adapting the grammar of POINT, BOX, CIRCLE and POLYGON for an alternative function signature introduced in ADQL-2.1, it appeared that the grammar of the first argument of these functions was more permissive than expected (see the GitHub Issue #29). This argument represents the coordinate system of the geometry coordinates. The grammar of ADQL-2.0 lets it to be any string expression which means a string concatenation, column references, User Defined Functions (UDF), any other function returning a string, but also numerics. Considering that a coordinate system can not be represented by a numeric expression, this case should have already been excluded. Besides, allowing a non constant expression as coordinate system makes its interpretation very difficult by a parser (need a parsing and all transform functions on the database side), but also for the users who have no explicit way to know what kind of coordinate transformation is applied (and thus, an uncertainty about the query result).
>
>
It appears that the grammar of ADQL-2.0 is more permissive than intended for the first argument of the POINT, BOX, CIRCLE and POLYGON functions.
Added:
>
>
This alert has been raised while adapting the grammar of the functions above for an alternative function signature introduced in ADQL-2.1 (see the GitHub Issue #29). This argument represents the coordinate system of the geometry coordinates. The grammar of ADQL-2.0 lets it to be any string expression (<string_value_expression>) which means a string concatenation, column references, User Defined Functions (UDF), any other function returning a string, but also numerics. Considering that a coordinate system can not be represented by a numeric expression, this case should have already been excluded. Besides, allowing a non constant expression as coordinate system makes its interpretation very difficult by a parser (need a parsing and all transform functions on the database side), but also for the users who have no explicit way to know what kind of coordinate transformation is applied (and thus, an uncertainty about the query result).
 
Changed:
<
<
This Erratum aims to allow the expression of the coordinate system argument of POINT, BOX, CIRCLE and POLYGON only as a string literal.
>
>
This Erratum aims to allow the expression of the coordinate system argument of POINT, BOX, CIRCLE and POLYGON only as a string literal (<character_string_literal>).
 

Erratum Content

Changed:
<
<
This Erratum changes the BNF grammar of , in the Appendix A, p.25, from:
>
>
This Erratum changes the BNF grammar of ADQL-2.0, in the Appendix A, p.25, from:
 
<coord_sys> ::= <string_value_expression>

into:

<coord_sys> ::= <character_string_literal>
Changed:
<
<
The description of the first argument of BOX, CIRCLE, POINT and POLYGON is also changed in resp. section 2.4.3 (p.13), section 2.4.5 (p.14), section 2.4.12 (p.18) and section 2.4.13 (p.18), from:
>
>
The description of the first argument of the functions is also changed for:
Added:
>
>
  • BOX, section 2.4.3 (p.13),
  • CIRCLE, section 2.4.5 (p.14),
  • POINT, section 2.4.12 (p.18), and
  • POLYGON, section 2.4.13 (p.18),

from:

 
the coordinate system is a string value expression as defined in Section 2.4.1.

into:

the coordinate system is a string literal as defined in Section 2.4.1.

Impact Assessment

Currently, very few ADQL services are able to interpret the coordinate system argument and to perform appropriate coordinates transformations. Currently, such known services are able to do so only if the coordinate system is given as a string literal. So this Erratum will not impact them.

A possible impact would be for ADQL services that can interpret coordinate system and apply coordinates transformations system from a column reference (e.g. via an uploaded table). No such service is known at the present time. If anyway one exists, it is perfectly allowed to offer more features in an implementation as long as the recommended ADQL language is supported.

From ADQL-2.1, the coordinate system argument is deprecated and becomes optional. So, no impact expected in future versions of ADQL where this argument will likely be removed.

Revision 12020-05-11 - GregoryMantelet

 
META TOPICPARENT name="WebPreferences"

ADQL-2.0 Erratum 3: Coordinate system argument as a string literal

Author: Grégory Mantelet

Date last changed: 2020-05-11

Rationale

While adapting the grammar of POINT, BOX, CIRCLE and POLYGON for an alternative function signature introduced in ADQL-2.1, it appeared that the grammar of the first argument of these functions was more permissive than expected (see the GitHub Issue #29). This argument represents the coordinate system of the geometry coordinates. The grammar of ADQL-2.0 lets it to be any string expression which means a string concatenation, column references, User Defined Functions (UDF), any other function returning a string, but also numerics. Considering that a coordinate system can not be represented by a numeric expression, this case should have already been excluded. Besides, allowing a non constant expression as coordinate system makes its interpretation very difficult by a parser (need a parsing and all transform functions on the database side), but also for the users who have no explicit way to know what kind of coordinate transformation is applied (and thus, an uncertainty about the query result).

This Erratum aims to allow the expression of the coordinate system argument of POINT, BOX, CIRCLE and POLYGON only as a string literal.

Erratum Content

This Erratum changes the BNF grammar of , in the Appendix A, p.25, from:

<coord_sys> ::= <string_value_expression>

into:

<coord_sys> ::= <character_string_literal>

The description of the first argument of BOX, CIRCLE, POINT and POLYGON is also changed in resp. section 2.4.3 (p.13), section 2.4.5 (p.14), section 2.4.12 (p.18) and section 2.4.13 (p.18), from:

the coordinate system is a string value expression as defined in Section 2.4.1.

into:

the coordinate system is a string literal as defined in Section 2.4.1.

Impact Assessment

Currently, very few ADQL services are able to interpret the coordinate system argument and to perform appropriate coordinates transformations. Currently, such known services are able to do so only if the coordinate system is given as a string literal. So this Erratum will not impact them.

A possible impact would be for ADQL services that can interpret coordinate system and apply coordinates transformations system from a column reference (e.g. via an uploaded table). No such service is known at the present time. If anyway one exists, it is perfectly allowed to offer more features in an implementation as long as the recommended ADQL language is supported.

From ADQL-2.1, the coordinate system argument is deprecated and becomes optional. So, no impact expected in future versions of ADQL where this argument will likely be removed.

 
This site is powered by the TWiki collaboration platform Powered by Perl This site is powered by the TWiki collaboration platformCopyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback