Use of valid_range to indicate unsigned integers

[Dave.Allured]

This responds to the recent request to add type short to the use of valid_range etc. to indicate unsigned integers.

Same as the proposed language in ticket #166, type short is included to document known usage. However, this proposal also suggests that this entire method for unsigned integers should be fully deprecated, in light of more straightforward and readily available storage methods.

The current CF 1.7 document, section 2.2 (Data Types) includes this sentence:

It is possible to treat the byte type as unsigned by using
the NUG convention of indicating the unsigned range
using the valid_min, valid_max, or valid_range attributes.

Text of new proposal. Insert paragraph break, consistent with new paragraph breaks in ticket #166. Replace the sentence with this paragraph:

2.2.1  Unsigned Integers

It is possible to treat the byte and short types as unsigned
by using the NUG convention of indicating the unsigned
range using the valid_min, valid_max, or valid_range
attributes.  This usage is deprecated as of CF version
1.8.  Unsigned integer data should be stored with a signed
numeric type of sufficient range and precision, or with native unsigned
integers in one of the newer netCDF file formats.

[zender]

Just adding myself to cc: list

[biard]

I don't think the second sentence "However, the translation between signed and unsigned values is not well defined, and subject to interpretation." is necessary. I think the actual problem is that the signature is subtle and easy to miss, but I don't think we need to justify ourselves in this paragraph, no matter what objections we may have to the old way.

[Dave.Allured]

I removed that sentence. However I feel that either there should be a warning about possible interpretation, or else a sufficient definition of "interpreted as unsigned" should be added. I would be okay dropping the issue if you think this is sufficient.

Please feel free to directly modify the ticket and insert your own language.