On 2008-4-17 11:08, Arnold Rots wrote:
> What is being proposed for ADQL at the moment is essentially its own
> implementation of the STC (mainly Region) model. In principle, there
> is nothing wrong with having multiple implementations (serializations)
> of the model, but there is the issue of versioning. If the model were
> completely contained in a limited set of functions, as I proposed, any
> changes in the model would be fully transparent to ADQL.
> As an outrageous example, if "Circle" were ever changed to "RoundThing",
> STC_S_contains would handle that without any changes to ADQL; if ADQL
> has its own STC implementation, it would need to change.
> It is especially this transparent containment of models that are not a
> native part of ADQL that prompted me to pursue this approach.
On the contrary, ADQL does not have any implementation of an STC model. That is why the <region> construct takes a string but the spec in no way says what the string is, as is the case in SQL for dates, times, binary (hex), etc. We intentionally made ADQL have the same amount of exactness (or lack thereof) as SQL.
As is the case with any RDBMS implementation (server) today, it is up to the server (eg TAP service I expect) to say what format it understands, which is also true of dates, times, binary, etc.
As for the primitive geometry constructs, they are defined independent of any other specification and that definition would not change if STC were to be changed in the future. If they are not well enough defined then that is an RFE against the document and should be dealt with. We explicitly kept to a few simple constructs (after examining the OpenGIS spec closely) because they allow for many (>90%) of the use cases quite directly; they are not intended to handle everything.
> There is a subtle but important difference between the use of literals
> and parameters: the question who determines the coordinate system.
> If the query specifies "Circle ICRS 12.3 45.0 0.6" it specifies the
> coordinate values and their coordinate system.
> But you cannot say "Circle ICRS b.ra b.dec 0.5", because it is the
Sure, but someone can also write Circle("foo", table1.x, table2.y, 123) as well. It is syntactically correct but obviously (probably) nonsense... but that is what ADQL (and SQL) allow for: syntax (not semantic correctness).
There is simply no way to make an SQL based language "semantically strong", woith or without the ADQL extensions. However, since the various geometry constructs are types, service providers a can declare columns to hold these types and users can use these columns directly and avoid many ways to make nonsensical queries. For example, a source catalog can have a single column with the position of the sources and queries can use that column to formulate a CONTAINS condition. An observation catalog can (should) have a column of type geometry (maybe explicitly polygon or region) for the spatial boundary; the users can use the single column in queries.
Practically speaking, if an existing database has multiple columns that specify a position (coordsys, ra, dec) they can easily accept ADQL queries where the user puts those three together. In the future, maybe they add a column and some db code with the position stored as a single value and users can use that. Or, maybe they just tell users they have that column but implement an ADQL parser to actually use the multiple columns of the implementation.
> The main issue is that entities where the client provides the
> values need to be handled differently from entities where the server
> provides the values: the server knows its coordinate system and
> reference point - the client cannot (and should not) force that on the
> server.
But that is simply not how SQL works and making ADQL fundamentally different from SQL is a huge amount of work that we cannot afford or justify.
-- 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.)Received on 2008-04-17Z21:03:06