How to deal with standard names having a <space> character

[larsbarring]

Topic for discussion

In earlier versions of the standard name table a small number of standard names were accidentally defined with a space character in the name. This does not conform to the CF convention but was not easy to spot. Once this happened the corrected standard name was defined and in most cases the non-conformant standard names were aliased into the correct one (cf. here). See the table below for details.

Defined in version(s)	Standard name (black square = <space>)	Aliased to correct name in version(s)
8 -- 10	mole_fraction_of_chlorine■dioxide_in_air	11 -- 84
8 -- 10	mole_fraction_of_chlorine■monoxide_in_air	11 -- 84
8 -- 10	mole_fraction_of_dichlorine■peroxide_in_air	11 -- 84
8 -- 10	mole_fraction_of_hypochlorous■acid_in_air	11 -- 84
8	mole_fraction_of_methyl_chloride■_in_air	no alias, correct in 9 -- 84
28 -- 36	rate_of_■hydroxyl_radical_destruction_due_to_reaction_with_nmvoc	37 -- 84
10 -- 18	tendency_of_potential_energy_content_of_ocean_layer_due_to_diffusion■	no alias, correct 19 -- 84
12 -- 19	atmosphere_moles_of_acetic_acid■	no alias, correct 20 -- 84
12 -- 19	atmosphere_moles_of_alpha_hexachlorocyclohexane■	no alias, correct 20 -- 84
12 -- 19	tendency_of_atmosphere_mass_content_of_nitrogen_monoxide_due_to_emission■	no alias, correct in 20 -- 84

In the overhaul of all the already published versions of the standard name table (see here) it became clear that the xml syntax in combination with the xml schema definition used by CF does not allow a space in the standard name irrespective of whether it appears in a definition or as an alias. Thus, it is not obvious that common xml parsing tools are guaranteed to give the correct result. Because of the double problem of not conforming to CF rules and violating XML syntax I would like to suggest that standard names containing a space are not allowed in definitions or in aliases. This can be implemented with various degree of strictness (from minimal to maximal):

1. Leave all already published standard name tables as is, but do not include aliases in future versions.
2. Remove aliases in table version N and newer.
3. Only keep the first alias and remove all subsequent ones.
4. Correct the standard name definitions by removing the spurious space.

For alternative 1-3, to maintain the lineage between the wrong and the corrected names an alias should be added for those that do not already have one. This should be done only in the version where the correct version first appears.

[JonathanGregory]

Dear @larsbarring

Since it's not allowed in xml, I think we must disallow space in both standard names and their aliases. I suppose that this prohibition requires a statement in the CF convention, but it's never happened by intention, only as a typo, so it doesn't invalidate any past intended standard name. Option (4) is the most appealing to me, because it's the only one which is safe for software. It will produce a potential hazard, that some existing data will contain standard names that can't be found in the table. This would be an exceptional situation for CF. I would suggest that we could address it by compiling a list (such as yours above) of the corrections that have been made, and linking it prominently on the vocabulary page.

Best wishes

Jonathan

[davidhassell]

I think we already disallow whitespace in standard names in the conventions 3.3. Standard Name states:

A standard name contains no whitespace and is case sensitive.

[taylor13]

I also favor option (4). I think we'll have to live with any backward incompatibility introduced due to typos.

[ethanrd]

I agree that option 4 seems least problematic going forward. Some backward incompatibility for some existing data is probably better than hard to troubleshoot issues caused by "legal" spaces in standard names.

[sethmcg]

I agree with Jonathan, Karl, and Ethan.

[davidhassell]

And I'm for option 4, too..

[feggleton]

I agree, option 4.

[larsbarring]

I, too, agree. Thanks all for quick responses and the unanimous outcome.

[japamment]

I also agree with option 4. It will be the simplest to implement and means that all versions of the standard name table will be compliant with the XML standard.

The spaces were originally included accidentally. When they were discovered I removed them from the standard names and made the older versions into aliases, just as would be done when correcting a simple spelling mistake. I did so for reasons of backward compatibility as mentioned above, but hadn't appreciated the problems it would cause for automatic parsing of the table. Since that seems to be the most pressing concern, I'm in agreement now with removing the spaces altogether.

So far, the comments on this issue are unanimously in favour of option 4. Therefore, I think these changes can be accepted in 7 days unless any objections are received in the meantime.

Once accepted, the corrections to previous versions of the table will need to be applied manually. If agreed in time, this can be done at the same time as the next standard name table update which is planned for May 20th/21st.

[larsbarring]

@japamment : Excellent if you manage to also correct the previous version of the table this soon. But I think that it is better to wait republishing them until all xml and schema issues have been corrected.

[japamment]

I have created a issue 312 in the discuss repo from this discussion - it doesn't seem to have transferred the comments, only the issue itself.

[JonathanGregory]

Thanks for the opening the issue, Alison @japamment. It's a new experience to start an issue from a discussion! Maybe "→ Transfer this discussion" would have moved the entire thing? Anyway, "forking" an issue makes sense. I suppose we should assume that this discussion is now concluded here. Thanks for raising it, @larsbarring.

[larsbarring]

In the current standard name table aliases containing a space were removed, but still remain in previous versions, something that will be taken care in due course asa result of the preliminary work detailed in cf-convention/cf-convention.github.io#457.

I leave it to @japamment, @efisher008, @feggleton to decide whether this issue can be closed (as completed, I imagine)

[ChrisBarker-NOAA]

@japamment, @efisher008, @feggleton : can this be closed?