Major Computer history has provided us with a growing number of numeric data types, and quite a few of them are reflected in Edm primitive types.
Integer types:
- Byte (0..2^8)
- SByte
- Int16
- Int32
- Int64
- Decimal Scale=0
Fixed-point types
- Decimal with VariableScale="false", see
ODATA-76
Floating-point types
- Decimal with VariableScale="true", see
ODATA-76 - Single
- Double
Especially for defining vocabularies it would be helpful to have an abstract type Edm.Number that can be applied to any of the numeric primitive types.
We can instead add
- Edm.Quadruple
- Edm.DecFloat16
- Edm.DecFloat34
to the Edm type system, although one can argue that this is the opposite of simplification.
In the SAP enterprise mobility space, we took a simple subset of XML schema types that has proven to be quite sufficient:
byte (signed)
short (Int16)
int (Int32)
long (int64)
integer ("lots" of digits, but no fraction)
decimal ("lots" of digits)
float
double
With this set of 8 types, we have had sucess in interopating across multiple client platforms (Java ME, Java SE, Windows CE, iOS) and I have not heard any reports of "missing" types causing any difficulty.
I recommend caution with any proposal to introduce quad precision binary floating point, or even decimal floating point for that matter. I do not believe that the support is there for such types across a sufficient number of the client types that may need to interoperate with OData services.
I should have added that I do not recommend the introduction of a basic Numeric type. It should be permissable to use facets on other types (Int32, Double etc) to specify valid ranges. Forcing the modeler to at least choose an initial type that is "close" to the range and precision of the target value is preferable to allowing the modeler to be "vague", which has folow-on effects for clients (e.g. Java clients being forced to use BigDecimal for all numeric values if the modeler is not careful enough).
Evan's list pretty closely matches what we currently have in OData, which is encouraging. Note that we used to be slightly closer (we recently got rid of "float", but have its synonym "single"). The only one missing is an integer larger than int64.
Is such a large integer required? Do we have examples where services need to store values that large? Are a sufficient number of clients prepared for such large values?
If so, I would propose we add an Edm.HugeInt (or some such). If we don't have requirements for such a type at this point, and examples of clients prepared to support them, I would propose we keep the primitive types as-is and consider adding larger int (and perhaps decimal) values in the future as required.
The latest proposal appears to be introducing an "abstract" type that can be applied in some places (i.e., vocabularies) but not others (i.e., properties). While I like the idea, the fact that we use ComplexType in both term definitions and models makes it difficult to enforce restrictions based on the usage.
There are other cases where we've recently added "abstract" typeslike Edm.PrimitiveType, Edm.ComplexType, and Edm.EntityType and had to define rules around what could be used in each of the different contexts.
Before adding more special-use types, I'd like to see if we can rationalize all of these with some easy to understand rules about what types can be used where.
I was going to enter this same issue, for tracking purposes, although I propose we NOT do this. Most implementations have the concept of a 16, 32, or 64 bit integer and it's actually simpler to have the discrete types that reflect those common types than to attempt to define through facets (i.e., MaxValue on a Double, are not straightforward to represent.)