ADQL versioning

[Markus Demleitner]

Hi Dave,

On Mon, Feb 19, 2018 at 04:19:24PM +0000, Dave Morris wrote:
> On 2018-02-08 14:46, Markus Demleitner wrote:
> > 
> > ... This is mainly because it was felt we cannot
> > introduce mandatory new features in a minor version.
> > 
> 
> This was not the criteria we used for deciding if something was mandatory or
> optional.
> 
> The primary criteria for accepting a feature or operator as mandatory is
> that it must be demonstrated, with working code examples, that it is
> possible to implement the new feature in an interoperable manner on all of
> the main platforms that are currently in use or in development for science
> data archives.

That's a reasonable policy, although I might have bargained harder to
keep a few RDBMSes out of the requried set if I had known that their
inclusion would lead to the (IMHO harmful) explosion of optional features.

> We would be happy to accept proposals to make any of the currently optional
> features mandatory. However, it is up to the proposer to do the work
> required to demonstrate, with working code, that the feature meets the
> minimum requirements for being considered as a mandatory feature.

...which is a really high bar, especially considering that quite a
few of the systems are proprietary software not necessarily easily
accessible -- even as regards their documentation.

> In contrast, the bar for accepting new optional features was deliberately
> set fairly low. This was because compared to adding a mandatory feature, the
> cost of getting it wrong with an optional feature is fairly low. The primary
> benefit of having optional features is that it provides a way to include new
> features to meet specific science use cases without having to meet the high
> bar required for a mandatory feature. On the other hand, if we accept
> something as optional and then it becomes widely adopted, and we can
> demonstrate it meets the criteria for a mandatory feature, then it is easy
> enough to make it mandatory in the next version of the specification.

However, this has to weighed against the fact that each optional
feature doubles the number of sub-languages users and validators have
to contend with.  If you have 30 optional features, you have defined
about a U.S. billion of different languages, and even if, in
principle, machines and humans can discover what concrete sublanguage
is in use where, that's still a huge burden for practical
interoperability (where I'd really like to be able to switch from one
service to another easily).

So -- regardless whether optional or not: I claim the
two-interoperable-implementations rule applies.  Since I won't bother
to implement the following features if nobody else does (as I'm not
convinced they should be in ADQL and they'd not go into the standard
anyway if I'm the only one to have them), please speak up if you have
implemented (or intend to implement before the end of RFC):

 * BOX with a POINT constructor
 * Common Table Expressions
 * boolean_value_expression and the accompanying literals
 * bitwise operators (rather than functions)

[I guess implemenation discussion can be off-list]

         -- Markus