Developers

64-bit data types

Should we add 64-bit integer datatypes to the DAP? Issue: 64-bit integers are going to be everywhere. Or are they? Adding this type will make writing clients harder because the clients will have to deal with types they may not be able to represent unless lots of extra work is done. But 64-bit is the future...

(Comment: If we will have to include 64 bit integers in the future and re-do the software, it's better to include it in the spec now so that future software is future- i.e. forward- compatible. -- PaulHemenway 18 Sept. 03)

Enumerations

Should we support enumerations? I noticed that ASN.1 does and I remember that their absence in Java was/is a big deal. There are good reasons to keep enums out of a general programming language (See Lakos, Large Scale C++ Software Design) but a transport system might really benefit from them. The flip side is that after 7+ years of using the DAP, we haven't needed them enough to make this exactly a top priority. Comments?

-- JamesGallagher - 19 Sep 2003

Time

How about adding a data type specifically for holding ISO 8601 date/times? I talked about this with Peter C., et al., and came to the conclusion that it's a pretty interesting idea. I think ASN.1 has a type for this (my ASN.1 book is at home...). It seems like time is pretty universal (for example a word processing doc needs time, so does an OS) and not just a 'science thing'.

-- JamesGallagher - 26 Sep 2003

Boolean

It seems a boolean type should be included. It's part of netCDF4 (See the UML for netCDF4 in AbstractModel).

-- JamesGallagher - 09 Oct 2003

64-bit Floating Point values

I realize this seems a bit far fetched, but most RDBMS systems support these big floats, as do some programming languages (at least Java has java.math.BigDecimal) Is there utility in this type? I have brought it up before and generally folks seemed to think it silly, but we might as well capture the arguments.

-- NathanPotter - 09 Oct 2003

My own inclinations on these issues:

• 64-bit ints (java longs) : Yes
• booleans : Yes
• date/time : Yes probably, but there are complicated issues with calendars. I think we should just use the standard Gregorian calandar, and anyone using a different calandar cant use the date/time type.
• enums : no, dont seem necessary
• BigDecimal: no, dont seem necessary

Some other questions:

1. HDF5 has "opaque" type, not sure why this isnt equivalent to "byte array", so im inclined not to use.
2. Are OpenDAP Strings ASCII, or do they have an encoding flag that would allow them to contain, eg Unicode? I think an (optional) encoding flag would be good.