separate DataTypes model

[pdowler]

types extracted from CAOM and then imported
add double,int32, int64 primitive types

draft: DataTypes name and location TBD

[mcdittmar]

lets not forget to revisit the type names..
integer -> int32, int64 seems right
real -> (float), double

• also seems right from my perspective, but it doesn't follow the pattern used in the integer type
• the explicit size format enables 1-word type names and makes the definition more clear
  • i.e. no 'long long' or 'long double'
• but real64 isn't as common in my world (other than Fortran)
• float32, float64 seems more common, but I don't like the change from real -> floatN

I'd vote for int32, int64, real64

[pdowler]

I would want to look at the IEEE floating point standard for the correct names to use. A cursory glance says "single" and "double" (precision) are only common names, but no sane programming language would have used single as a data type :-)... that suggests that "double" could maybe be a poor choice

[pdowler]

https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=8766229

3.1.1 says:
Five basic formats are defined in this clause:
― Three binary formats, with encodings in lengths of 32, 64, and 128 bits.
― Two decimal formats, with encodings in lengths of 64 and 128 bits

3.6 the tables use binaryW and decimalW for different width (bits); since we use both binary and decimal (ascii) interchange, neither of those styles are really correct for what we are after... to specific to serialisation.

Note that while decimal32 is in the tables in 3.6, it is not considered a "basic format" (definition in 2.1)

I think we could get away with the ivoa base model having real (as-is: meaning width is implementation-specific) and double (meaning 64-bit) that can be used if a model really requires it for interoperable implementations. Maybe some day in the future someone else will need 128-bit FP... maybe not. Certainly no use cases right now.

So, I think double is as good as anything else.

[mcdittmar]

Comments on the Shape extractions.

1. If this goes outside CAOM, the descriptions should lose the context text.. "on the sky".
2. I had gotten into my head that Point was a Shape, but it is not... feels like it should be.
3. MultiShape is in the same boat as Polygon since it has an attribute with [1..*] Shape-s.
4. MultiShape is a collection of Shapes with no logic associating them? Maybe it's in the text, but what use case does that support? or is the logic imposed by the usage?

[pdowler]

1. yes
2. there is lots of prior art/design that says not to do that
3. yes, but that rule needs to relax
4. DALI now specifies xtype="multishape" which defines it as "union"; that is the intent here

Of course, with 4 we are doing things in the wrong order: specify serialization first and then the model, but the DALI thing is intended to exactly do what CAOM needs so I prefer to think of it as a two-point boundary value problem :-)