On 2008-4-23 07:19, Arnold Rots wrote:
> Patrick,
>
> Needless to say that I disagree strongly with your assessement.
Well, I am perfectly willing to change my mind in the face of a strong counter argument. Can you explain how my assessment (that the SQL base of ADQL is purely syntax and in no way enforces semantic correctness in the query) is wrong? If we have based ADQL on a fundamentally flawed idea then it would be good to know.
> Patrick Dowler wrote:
> > (hex), etc. We intentionally made ADQL have the same amount of exactness
> > (or lack thereof) as SQL.
Do you think this statement is incorrect? Did we make ADQL more or less exact than SQL?
Sincerely,
Patrick
> 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,
>
> - Arnold
>
> 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/
> --------------------------------------------------------------------------
-- 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-23Z18:29:03