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

  - 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.

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.

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

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.

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.

TAP capabilities resource content.

TAP capabilities resource content.

- empty file
- not a valid VOTable document

In such cases, the following error message is returned:
  "The input file is not a valid VOTable document!"
A cause with more detais (especially the line and column numbers)
may be appended.

Cases handled with no error:

  - If the VOTable document has no rows, an empty table
    is uploaded. No error has to be returned.

  - If a row has a different number of columns than the number
    of declared FIELDs, additional values are ignored and missing
    values are replaced by NULL. This is actually nicely handled by
    STIL.

Two comments:

- JDBCConnection.getDBMSName(String url) is now deprecated ; it may disappear
  in a next version of the ADQLLibrary.
- In case the DBMS name can not be retrieved (generally because of an
  incomplete JDBC driver implementation), NULL will be returned.

Few useless casts have also been removed.

It is also now recommended to make DBConnection.executeQuery(ADQLQuery)
return NULL if the query has been aborted (indeed, the DBConnection is
the only one that can reliably know that fact). JDBCConnection has been
adapted consequently.

apply a quick space replacement (by %20) for few URIs of the configuration file
and remove duplicated entry (encoding) from the Gradle build script.

A special test has also been added in getFile(...) in order to deliver
a clear error message for users using a former version with URIs in their
configuration file (only for file_root_path and metadata_file).

Two embedded DBMS are used: H2 and a little SQLite. JDBC drivers are provided
in the `lib` directory. The databases are created and deleted automatically
by the JUnit tests (see `test/tap/db_testtools/DBTools for more details`).

The ANT and Gradle build scripts have been updated to reflect all these test
modifications.

This issue has been raised with an H2 database.

ResultSetTableIterator (i.e. functions returning unknown numeric values
were not set with the right datatype but char* instead).