RE: Spec (BNF) changes parallel to the RFC

I agree -- the simpler the better

--Alex

-----Original Message-----
From: owner-voql-teg-at-eso.org [mailto:owner-voql-teg-at-eso.org] On Behalf Of Patrick Dowler
Sent: Wednesday, May 28, 2008 12:46 PM
To: Jeff Lusted
Cc: voqlteg
Subject: Re: Spec (BNF) changes parallel to the RFC

If side1 and side2 and the width and height (this needs to be specified in the
document) then this is consistent with STC and normal usage. I don't see the

need to introduce the extra <side1> and and <side2> though... why not just use <numeric_value_expression> directly?

Pat

On 2008-5-28 04:05, Jeff Lusted wrote:
> Hi Colleagues!
>
> My apologies if I've been a little slow in replying to the RFC comments.
> I've made a start this morning, replying to one of Bob's points.
>
> I've also been trying to adjust the syntax (minimally I hope) according
> to the comments which I think we accepted (eg: BOX, and our own internal
> discussion on the LATITUDE and LONGITUDE functions). Attached is a new
> HTML-based version of the BNF diagrams for you to examine. Here are the
> relevant points. I need your feedback...
>
> (1) I've changed RECTANGLE to BOX.
>
> <box> ::=
> BOX <left_paren> <coord_sys>
> <comma> <coordinates>
> <comma> <side1>
> <comma> <side2>
> <right_paren>
>
> <side1> ::= <numeric_value_expression>
> <side2> ::= <numeric_value_expression>
>
> BOX is now a reserved word. RECTANGLE is no longer a reserved word.
>
> (2) I've added ELLIPSE. This was brought up by Francois Ochsenbein, and
> I thought that it also came up in the discussions. In our efforts to
> show we do our best to accommodate STC, this is the definition...
>
> <ellipse> ::=
> ELLIPSE <left_paren> <coord_sys>
> <comma> <coordinates>
> <comma> <radius>
> <comma> <minor_radius>
> <comma> <position_angle>
> <right_paren>
>
> <minor_radius> ::= <numeric_value_expression>
> <position_angle> ::= <numeric_value_expression>
>
> _Please_ let me know if this is adequate, or too much!!!
> ELLIPSE would become a reserved word.
>
> (3) I've altered the name of <system_defined_function> to
> <geometry_function> and moved <centroid> into the list. I've made minor
> adjustments to the names for the sake of readability (basically I've
> only used "function" where the expansion is a list of functions, which
> fits in better with the definition of maths and trig functions, the one
> exception being <user_defined_function>)...
>
> <geometry_function> ::=
> <area>
>
> | <centroid>
> | <distance>
> | <latitude>
> | <longitude>
> | <region_function>
>
> I've moved <centroid> here from <geometry_value_expression> to make our
> approach to these functions more consistent. This also entails a small
> change to an important definition...
>
> <geometry_value_expression> ::= <geometry_expression> | <geometry_value>
>
>
> (4) Part of this consistency is a partial redefinition of the functions
> so they now _all_ use <geometry_value_expression>. For example,
>
> <centroid> ::=
> CENTROID <left_paren> <geometry_value_expression> <right_paren>
> <area> ::=
> AREA <left_paren> <geometry_value_expression> <right_paren>
> <distance> ::=
> DISTANCE <left_paren> <geometry_value_expression>
> <comma> <geometry_value_expression> <right_paren>
> <latitude> ::=
> LATITUDE <left_paren> <geometry_value_expression> <right_paren>
> <longitude> ::=
> LONGITUDE <left_paren> <geometry_value_expression> <right_paren>
>
> <region_function> ::= <contains> | <intersects>
>
> and so on.
>
> The result of this is that _all_ can use either <geometry_expression> or
> <geometry_value> as parameters, the latter of which is unchanged and
> defined as
> <geometry_value> ::= <column_reference>.
>
> This is consistent with other parts of the SQL definition, and makes the
> approach more extensible (eg: at some future date we could change
> <geometry_value> to be wider than a simple column reference, perhaps to
> include the result of a scalar sub-query). Of course, we cannot enforce
> full type safety with an SQL-like language (an inappropriate column
> reference could always be made; vetting this would be down to analysing
> metadata, which we don't pretend to cover). I think "inappropriate"
> geometry expressions could have suitable defaults (eg: the area of a
> point is zero) or simply fail like making an inappropriate column
> reference. To my understanding this is acceptable.
>
> Please Note. The effect of (3) and (4) is that all of these new
> functions are as flexible as the maths and trig functions, and can
> appear within a query in all the places maths/trig functions can also
> appear. This was _not_ the case before. I've tested by making changes
> within the parser, and it all seems to work.
>
> (5) I've changed the <coordinates> definition to be more neutral,
> from ...
>
> <coordinates> ::= <coord_lon> <comma> <coord_lat>
> to
> <coordinates> ::= <coord1> <comma> <coord2>
> <coord1> ::= <numeric_value_expression>
> <coord2> ::= <numeric_value_expression>
>
>
>
> Finally, some minor points on the Spec document....
>
> (6) Inaki, I've just fuly implemented the join syntax as outlined in the
> BNF diagrams in the spec...
>
> <qualified_join> ::=>
> <table_reference> [ NATURAL ] [ <join_type> ] JOIN
> <table_reference> [ <join_specification> ]
>
> I'm not sure this is the same as the text explanation, as the above
> makes <join_type> optional. It's a little ambiguous...
>
> "Among the different types of joins ADQL supports qualified ones only.
> These are INNER and OUTER ones (LEFT, RIGHT and FULL). All of these can
> be NATURAL or not."
>
> Perhaps a change to...
>
> "Among the different types of join, ADQL supports INNER and OUTER (LEFT,
> RIGHT and FULL) joins. If none is specified, the default is INNER. All
> of these can be NATURAL or not."
>
> (7) CONTAINS. I had a look at OpenGIS, and the intention in
> CONTAINS( x,y ) is that the test is for x containing y. I think we have
> implied it is the other way around in our examples, which makes the
> examples less intuitive.
>
> (8) One extra, minor point. Within Appendix A: "An easier to navigate
> version of the BNF grammar can be found here". The link in the spec does
> not seem to work.
>
> Well, we make progress (I hope)!
> Regards
> Jeff

-- 

Patrick Dowler
Tel/Tél: (250) 363-6914                  | fax/télécopieur: (250) 363-0045
Canadian Astronomy Data Centre   | Centre canadien de donnees astronomiques
National Research Council Canada | Conseil national de recherches Canada
Government of Canada                  | Gouvernement du Canada
5071 West Saanich Road               | 5071, chemin West Saanich
Victoria, BC                                  | Victoria (C.-B.)