Custom Query (124 matches)

Rich Signell has pointed out an error in the CF standard document by raising a trac ticket. I think we need rules for deciding to make corrections, or there's a danger they might not be implemented. I propose the following:

1. These rules apply to the CF conventions document, the conformance document, the standard name table and its guidelines.

2. Errors in these documents can be corrected under these rules if it is clear that the text as it stands isn't what was agreed, because of a typographical or some other error. These rules can't be followed for making substantive changes. Errors in the standard names can alternatively be pointed out on the CF email list, and implemented by the manager of CF standard names (Alison) as part of a regular update.

3. If someone thinks there is an error in a document, they should open a Trac ticket of type "defect" to point it out and to state what should be done to the text in order to correct the error.

4. The correction is held to have been agreed if three weeks pass without anyone disagreeing with it. After that period, the ticket should be closed by the manager of the CF conventions (Kyle) or the manager of CF standard names (Alison), who will make the change. No moderator is needed because there cannot be any substantive discussion under these rules.

5. If anyone disagrees that the correction should be made, because they think the document does have the intended meaning, then a correction cannot be made by these rules, the ticket should be closed, and the change should be proposed as an enhancement instead, following the rules for making changes to the CF standard, if the proposer wants to pursue the issue.

It feels a bit bureaucratic to have rules, but I think it may be necessary because experience shows that without rules we find it hard to reach conclusions. Please post your comments to this ticket.

Jonathan

Currently time coordinates must be stored as a number with units that are parsable by the udunits library (cf section 4.4).

I propose that we also allow time coordinates to be expressed as W3C/ISO 8601 formatted Strings. (Example: 2007-03-29T12:00:00Z) This format is widely used internationally, it is a profile by the W3C of the ISO standard. This page has a summary of the format and more links:

​http://www.unidata.ucar.edu/projects/THREDDS/tech/interfaceSpec/NetcdfSubsetService.html#Reference

Reasons:

• A string representation is human readable (compare with "348472938 secs since 2007-03-29 12:00:00Z")
• Independence from the udunits library when needed.
• May be easier to use for some.

Proposed change:

1) Change section 4.4 to start with:

"Date coordinates must either be of type char, formatted according to the W3C/ISO 8601 Date format, or of numeric type with a mandatory units attribute containing a udunit compatible date unit string."

2) Add an appendix that describes the W3C/ISO 8601 format, or simply point to an external link.

Note: I find it clearer to use "date" to refer to "calendar date", and "time" to mean a "unit of time duration" (eg 1500 secs). It might be worth looking through our usage to see where this meaning may be unclear.

This is a proposed correction for an error in the documents, not a change to the standard. According to the rules, it will be accepted if no-one objects to it in the next three weeks.

The table in Appendix A incorrectly states that flag_values is a string attribute. This is inconsistent with CF 3.5, which says, "The flag_values attribute is the same type as the variable to which it is attached." This error was pointed out by John Stark in April 2007 ​http://www.cgd.ucar.edu/pipermail/cf-metadata/2007/001614.html and this month by Philippe Poilbarbe on the netCDF email list.

The correction required is as follows:

• Add "D for the type of the data variable" to the sentence "The Type values are S for string, N for numeric" before the table in Appendix A.

• Change the type from S to D for flag_values in the table.

• In the conformance document, add a section:

  3.5 Flags
  Requirements:
  The flag_values attribute must have the same type as the variable to which it is attached.
  

Jonathan