Patrick,
Needless to say that I disagree strongly with your assessement. But this discussion does not seem to be going anywhere and the authors seem to have made up their minds, so I think I might as well give up on this argument.
Cheers,
Patrick Dowler wrote:
> 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.)
>
Arnold H. Rots Chandra X-ray Science Center Smithsonian Astrophysical Observatory tel: +1 617 496 7701 60 Garden Street, MS 67 fax: +1 617 495 7356 Cambridge, MA 02138 arots-at-head.cfa.harvard.edu USA http://hea-www.harvard.edu/~arots/ --------------------------------------------------------------------------Received on 2008-04-23Z16:21:06