RFC period started for Obscore 1.1 [id, new: widths]

[Markus Demleitner]

Dear DM,

Not to belabor the point, but:

On Mon, Jun 27, 2016 at 03:12:23PM +0200, Laurent Michel wrote:
[on prescribing *_xel as 64 bit ints]
> The LSST camera has 3Gpixels, which requires a long int, thus it
> looks wise to me to encode *_xel on 64 bits.

Well, even with 3 GPixels, an axis has, assuming a square array,
about 55000 pixels, which would even fit into an unsigned short.
With a "normal" 32 bit int, cameras could still grow by a *factor*
for 1.6 billion (in number of pixels) before we'd be in trouble with
32 bit signed ints.

Assuming standard Moore's Law (#gates doubling time 1.5 years),
that'd give us until about 2050 with 32 bits (and I'm fairly sure
Moore's Law won't hold for image sensors until then).

> Now, the question to know whether database types must be specified within a
> DM is quite interesting but it shouldn't be quickly anwsered just at the end
> of the Obscore RFC period.
> The consequences of a loose database typing in models must be investigated carefully.
> For instance, having different types from an implemenation to another could
> break the interoperability. That could lead to see a query failing on one
> service and working on another one.
> 
> 	SELECT * FROM ivoa.obscore WHERE s_xel1 > 3000000000 e.g.

Interestingly, I cannot find anything on type promotion in
comparisons in the SQL 92 standard (but then I didn't look
carefully), but I'd be *very* surprised if there were a single RDBMS
that will get this wrong (not counting on failing on the literal in
the first place if it does not support integers of this size, but
that'll happen whatever you say in obscore), regardless of the
integral type of x_xel1.  In other words: I'm sure that's perfectly
safe to open up the integer and float sizes of the various columns.

The reason I'm skeptical about being too strict here is that we've
traditionally had oodles of invalid SCS services just because the
spec says the positions must be double-valued while the underlying
databases had simple floats.  Data providers hadn't noticed the rule
about doubles and handed through the floats.  Boom.  Of course,
nothing broke with these float-valued services -- they just failed
validation, and I would argue needlessly.

On the other hand, ok, I noticed this too late.  If nobody else
protests here, then at least for the next version I'd like to propose
toning down the type schema to "integral" and "real-valued".

Cheers,

        Markus