if the alias is not delimited in ADQL.

This commit fixes the GitHub issue #56

are translated: the table part (if a reference to an aliased table) should be
as declared in the DBTable (especially now that we have DBTableAlias to deal
nicely with table aliases).

this table is declared with an alias. Instead, the table alias must be used.

Note: This problem occurred only when ADQLParser was used with a DBChecker.

This commit fixes the GitHub issue #53

The order of its children was incorrect according to the XSD schema:
the 'fkColumn' must be written before 'description' and 'utype'.

A delimited identifier is any sequence of characters between a pair of
double quotes. For instance: "123 I am a delimited identifier!".

It is of course possible to have double quotes inside this kind of identifier,
but they have to be doubled in order to not be mistaken with the end of the
identifier. For instance: "Cool ""identifier""".

However, this escape option was not taken into account by the ADQL library,
though the same mechanism was already in place for string contants.

This commit also includes the 2 following points:

    - for (really really tiny) optimisation purpose, replace String by a
	  char when there is only one character to append to a StringBuffer

	- add a bit more details about Result.type in the Javadoc (it should be
	  a xlink:type and not a random custom type)

Until now, it was possible to destroy the job by posting ACTION=DELETE
with a URL like below:

    {root-uws}/{job-list}/{job-id}/foo/bar

That is completely wrong. The correct URL for this action must always be:

    {root-uws}/{job-list}/{job-id}

This commit fixes this error in UWSServlet and UWSService.

The configuration of the DestructionTimeController was never effective
in the UWSServlet with a configuration file: the wrong instance was set.

synchronized although the collection of observers is synchronized (Vector) ;
using an Iterator ensures the synchronization and avoids concurrency problems.

  - uws.service.UWS.VERSION  (static final)
  - tap.resource.TAP.VERSION (static final)

Dealing with several protocol versions in the same time is quite difficult and
may significantly alter the libraries API in an unstable way. That's why, for
the TAP and UWS libraries, only one version is implemented (i.e. the last one).
To use a older version of the protocol, one must use an older version of the
corresponding library.

About the versioning of the ADQL standard, there is no need to set any version
number somewhere because a different ADQL version implies a different grammar.
It means that a different parser is required for each ADQL version. For the
moment, there is only one version, so no need to change anything to the ADQL
library about ADQL version. Later, ADQLParser should become an interface and
a factory will have to be used in order to get the parser corresponding to the
desired ADQL version.

in TAP_SCHEMA.

RegTAP is detected successfully if the schema 'rr' exists (case sensitive)
and contains at least the following tables (names also case sensitive):
	- capability
	- interface
	- intf_param
	- relationship
	- res_date
	- res_detail
	- res_role
	- res_schema
	- res_subject
	- res_table
	- resource
	- table_column
	- validation

The table name can be prefixed by 'rr' (case sensitive) or not. For instance:
'rr.capability' and 'capability' are both detected successfully.

All these constraints (including the case sensitive one) are based on the
requirements of the RegTAP-1.0 standard document. They are set in order
to not declare the RegTAP DM by accident AND to provide a first low
validation of the RegTAP schema and tables. Low validation because
columns (as well as datatype, utypes, indices and UDF functions) are
never checked.

This commit resolves the GitHub issue #51

standard table. The same for the additional column
TAP_SCHEMA.columns.coosys_id.

coordinate system of coordinate columns.
  (see the HTML page src/tap/metadata/tap_coosys.html for more details)

This commit is a merge with the branch 'coosys'

in the TAP metadata.

This help will be later used in the complete documentation of the TAPLibrary.

This commit resolves partially the issue #28

Ideally, there should be an implementation of UWSLog and TAPLog working with
Log4j and another for SLF4J (and eventually for other logging mechanism).
Additionally, an implementation storing log messages in database would be
interesting. All these ideas may be implemented in UWSLib and TAPLib in a
future version.

_This commit aims to fix the issue #47_

reserved word is encountered instead of a column/table/schema name/alias.

On the contrary to the previous commit, this time a list of SQL reserved words
has been added into the ADQL grammar. In this way, the parser will ensure that
no word of this list is used in an ADQL query. The raised error is then enriched
of an HINT message stating that this word is part of SQL, is not supported
by ADQL and must be written between double quotes if used as an identifier.

The list of SQL reserved words comes from the ADQL-2.0 standard, after removal
of all potentially used ADQL words, in order to avoid a conflict with the
already existing tokens in the ADQL grammar.

reserved word is encountered instead of a column/table/schema name/alias.

No list of ADQL reserved words has been added into the ADQL grammar.

However, the ADQL grammar has been slightly changed in order to provide a more
precise location of the REAL wrong part of the query.

Before this commit, if an ADQL reserved word (e.g. 'point') was encountered
outside of its normal syntax (e.g. 'point' no followed by an opening
parenthesis), the next token was highlighted instead of this one. Hence a
confusing error message.

For instance, the following ADQL query:

```sql
SELECT point
FROM aTable
```

returned the following error message:

> Encountered "FROM". Was expecting: "("

Now, it will return the following one:

> Encountered "point". Was expecting one of: "*" <QUANTIFIER> "TOP" [...]
> (HINT: "point" is a reserved ADQL word. To use it as a column/table/schema name/alias, write it between double quotes.)

This error message highlights exactly the source of the problem and even provide
to the user a clear explanation of why the query did not parse and how it could
be solved.

with a different local charset, the error message will print differently the
incorrect character.

The idea is to get rid of special characters such as '-', '+' , '(', ...

This commit resolves a part of the Pull Request #14

and HashMap more generic by returning resp. a List and Map instead.

This commit resolves a part of the Pull Request #14

In the resulting SQL query, if there are an alias on the joined tables, these
aliases must be used in the ON clause (instead of the full table name).

For instance, the following ADQL query:

```sql
  SELECT *
  FROM tableA AS a NATURAL JOIN tableB AS b;
```

should be translated into the following SQL:

```sql
  SELECT *
  FROM tableA AS a
    INNER JOIN tableB AS b
      ON a.id = b.id
```

This commit complete the resolution of the Pull Request #16
(more details about the issue can be got in there)

In MS-SQLServer, the following functions return a value of the same
type as the given argument:
  - abs
  - ceiling
  - degrees
  - floor
  - radians
  - round.

Since ADQL requires that these functions return a DOUBLE
(i.e. a float in MS-SQLServer), it must be ensured that the given
argument is a float.

This commit partially fixes the Pull Request #16

when an incorrect character that can not be interpreted by
the JavaCC Token Manager is encountered.

Actually, the TokenMgrError thrown by JavaCC is caught by all
ADQLParser.parseQuery(...) functions, wrapped inside a ParseException
which is finally thrown instead of the TokenMgrError. In this way,
ADQL-Lib users just have to care about a single Throwable:
ParseException.

Besides the error message has been slightly modified from:

> Lexical error at line 1, column 10.  Encountered: "\u00e9" (233), after : \"\"

to:

> Incorrect character encountered at l.1, c.10: \"\\u00e9\" ('é'), after : \"\"

Thus, the error is more user-friendly, more easy to understand by users.
Additionally, the incorrect character is displayed, as before, in its unicode
expression, but also in its character form (instead of an integer value that
nobody can really understand).

This commit fixes the GitHub issue #17

The JUnit test should have been updated as well.

The previous fix was made against the ObsCore-DM 1.1 because the given
IVO-ID was rejected by EuroVO registry. Now that EuroVO registry has
fixed its IVO-ID rule, the IVO-ID of ObsCore 1.1 is accepted.
Hence this commit.

On the contrary to other DBMS, MySQL supports schemas, but as databases.
Which means that JDBCConnection gets from the JDBC driver that MySQL does
not support schemas and so it tries to access TAP_SCHEMA tables with a
'TAP_SCHEMA_' prefix instead of 'TAP_SCHEMA.' one. Since MySQL does
behave like it supports schemas, JDBCConnection.supportsSchema must be
set to 'true' if the DBMS is MySQL.

Besides, since no schemas are returned by the JDBC driver
(cf DatabaseMetadata.listSchema(...)), the function
JDBCConnection.isSchemaExisting(String, DatabaseMetaData) must always assume
that the specified schema exists if the DBMS is MySQL. This is particularly
important when the existence of 'TAP_UPLOAD' must be checked, because if the
function returns 'false' the library will attempt to create the database/schema
'TAP_UPLOAD' and will obviously fail due to a lack of permissions. Of course,
it means that the TAP implementor must create manually the schema/database
'TAP_UPLOAD' him-/her-self.

The second particularity of MySQL is the quote character for identifiers.
It is a back-quote (`) instead of a double quote ("). To reflect this
difference, JDBCTranslator.appendIdentifier(...) has been overwritten in a new
JDBCTranslator extension: MySQLTranslator.

The translation of all SQL types and mathematical functions have been adapted to
MySQL according to the online documentation. Few tests have been done locally
with a tiny database. This seems to work but further testing should be
performed in order to ensure the stability of this implementation.

'result_'.

Additionally when an XML document is submitted in an HTTP POST request
(i.e. with the Content-Type = (text|application)/(.+-)?xml), this is
immediately set as a jobInfo in the created job.

This infinite loop occured only when the replacement object is just
a wrapping of the matching object ; after replacement, the new object was
inspected for matching objects.

Example: infinite loop if we want to wrap all foo(...) functions with
         the function ROUND in the following query:
    SELECT foo(foo(123)) FROM myTable
	     Expected result:
    SELECT ROUND(foo(ROUND(foo(123)))) FROM myTable
	     But generated result was:
    SELECT ROUND(ROUND(ROUND(......foo(foo(123))))) FROM myTable

See the test case TestDBChecker.testClauseADQLWithNameNull() for more details.

Now, it is recommended to throw a DBCancelledException from any DBConnection
long processing. It is already done for the upload of a table, the execution
of an ADQL query and the setting of a whole TAP_SCHEMA. The flag
JDBCConnection#cancelled has now a bit different meaning: it is set even if
the Statement.cancel() fails so that any JDBCConnection function can see that
a cancellation has been requested.