table_name syntax

[Mark Taylor]

On Tue, 28 Apr 2015, Markus Demleitner wrote:

> > I suspect in that case there are a number of TAP services out there
> > broken in this respect (taplint hasn't been looking for them up till
> > now), though disappointingly I can only find a couple of examples
> > at GAVO DC (vlastripe82.stripe82 column _ct, plus an empty schema
> > mwsc-e14a which maybe doesn't count).
> 
> _ct is ok -- that works as a regular identifier.  But:

I hesitate to trade BNF with you, but I see in sec 2.1.2 of ADQL 2.0:

   Both the identifiers and the keywords are case insensitive.
   They SHALL begin with a letter {aA-zZ}. Subsequent characters
   shall be letters, underscores or digits {0-9} as follows:

     <Latin_letter> [{ <underscore> | {<Latin_letter> | <digit>} }]

and in the appendix:

   <regular_identifier> ::=
      <simple_Latin_letter>...
         [ { <digit> | <simple_Latin_letter> | <underscore> }... ]

   <simple_Latin_letter> ::=
       <simple_Latin_upper_case_letter>
     | <simple_Latin_lower_case_letter>

   <simple_Latin_lower_case_letter> ::=
       a | b | c | d | e | f | g | h | i | j | k | l | m | n | o
     | p | q | r | s | t | u | v | w | x | y | z

   <simple_Latin_upper_case_letter> ::=
       A | B | C | D | E | F | G | H | I | J | K | L | M | N | O
     | P | Q | R | S | T | U | V | W | X | Y | Z

I must admit I don't know what that "..." means in the
<regular_identifier> production, but the text in the document body
at least appears to outlaw a leading underscore.

> > Supplementary question: does "form ready for usage" include
> > quoting to avoid collision with ADQL reserved words?
> > If so, I've got a few more GAVO column names I can beat you with
> > (distance, size, date, section).
> 
> Yes, that's what I suggest: "If an ADQL engine needs a column, table, or
> catalog to be referenced through a delimited identifier, it MUST be
> given in quotes in both TAP_SCHEMA and on the VOSI endpoint" (yes,
> that's a proposal for TAP 1.1 standards language -- where do I put
> it?)
> 
> And true, if that's the policy we adopt I'll have to fix DaCHS.  What
> a letdown that the problem didn't just go away when I so busily
> pressed my eyes shut.  Something must be wrong with this world.

It sounds OK to me, though it represents a change to what I have
been assuming up till now.  I can modify my TAP client and TAP
validation code accordingly, but I'll wait to see whether other
TAP service operators out there are in agreement before I do. 
TAPVizieR at least would need to adjust much of its TAP_SCHEMA
content.  There may also be implications for existing TAP clients
in coping with the changes to behaviour of existing TAP services
to comply with this reading/clarification of the standard.

Mark

--
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
m.b.taylor at bris.ac.uk +44-117-9288776  http://www.star.bris.ac.uk/~mbt/