Comments (21)
Dear @Dave-Allured and @sethmcg
Maybe I can help this along. One of the two outstanding things is to modify the conformance.adoc
. I think the required change is to insert the following:
ASCII period (".", decimal 46, Unicode U+002E) and ASCII hyphen ("-", decimal 45, Unicode U+002D) are also allowed in attribute names only.
as a second bullet in Sect 2.3 of the conformance document.
The other necessary change is to add a line at the top of the history of the working version in history.adoc
.
Cheers
Jonathan
from cf-conventions.
I support this proposal. Given the discussions in #237 and cf-discuss #244, it's clear that there is a need to provide support for localization, but also that there are many hazards to expanding the list of allowable characters. This approach seems the be the best way to provide that support while opening up the fewest cans of worms.
from cf-conventions.
Is there a reason to to extend it to a few more punctuation characters, e.g. the colon :
(Code Point U+003A). I believe that the colon was suggested as a separator in one version of the i18n proposal.
Once names are not longer legal as programming language identifiers, maye there's no reason to restrict them more than necessary maybe a couple more chars?
NOTE: I fully agree that full Unicode letters is a larger proposal that should be handled separately.
from cf-conventions.
I would oppose adding the colon.
Adding .
and -
can cause problems for programmatically creating variables in a program with names that are the same as the names of the variables/attributes in a netcdf file, but strategies for working around it seem pretty clear and straightforward to me.
However, there are also workflows that involve parsing the text output of ncdump, which uses :
as the delimiter between variable/attribute name and value. In my experience, it would be much, much harder to modify those to accommodate :
as an allowed character in a variable name.
I think we want to be very conservative when it comes to adding allowed characters, and not do it until and unless we have a clear and strong demand for it, and have had a long discussion about what could work and what problems it could cause. We've done that with .
and -
, but I don't think that's the case for :
.
from cf-conventions.
text output of ncdump, which uses : as the delimiter between variable/attribute name and value
Good point -- yes, that takes colon off the table.
from cf-conventions.
While I am in favor of the general direction this proposal is going, I also very much agree with what @sethmcg writes. Here I would like to approach this from slightly different angle.
The proposal lists the following benefits:
- Support desired new naming patterns for attributes.
- Enable the use of IETF BCP 47 language tags for attributes.
- Enable the use of other meaningful suffixes for attributes.
As the proposal now stands it will certainly support these benefits but it will also come with some possible drawbacks:
- Attribute names can have any combination of the allowed characters, of which some may not be desired (acknowledging that this is a value statement)
- it is not clear what a "suffix" is, and how to distinguish one from some other possible usage patterns involving period and hyphen.
I think that we need a deeper discussion on what we want to achieve by allowing the period and hyphen. In netCDF these are already allowed in attribute names, so the question is how CF wants to use them. For example:
- Is the period only going to be designated as marker between an attribute (CF meaning) and its suffix, as in
attribute.suffix
? - If not, how is the specific use case of IETF BCP47 language tags going to be identified in relation to all other possible attribute name patterns that will emerge?
- As a middle ground between these two, are there other specific uses of the period that may be impacted if it is used for demarcating a suffix?
Currently, we have one concrete use case and that is the need for localization, for which the requirements are pretty clear: to attach a language tag construct (language-
country) to attributes. From the conversation in discuss/#244 there is convergence towards using period as marker to indicate start of a language tag. This is a much more specific need than a general extension of the allowed character set.
from cf-conventions.
- it is not clear what a "suffix" is, and how to distinguish one from some other possible usage patterns involving period and hyphen.
"Suffix" here is a vague reference to possible future uses for the added characters. It is not part of the new text. It does not need further definition at this time.
I think that we need a deeper discussion on what we want to achieve by allowing the period and hyphen. In netCDF these are already allowed in attribute names, so the question is how CF wants to use them.
- Is the period only going to be designated as marker between an attribute (CF meaning) and its suffix, as in
attribute.suffix
?
This particular PR adds two characters without any directed usage. This will enable any desired future usage, public or private, without violating a CF name rule. Think of it as adding punctuation characters with equal status to the underscore.
- If not, how is the specific use case of IETF BCP47 language tags going to be identified in relation to all other possible attribute name patterns that will emerge?
I have not given it much thought. Simple pattern recognition should take care of most cases. BCP47 is highly recognizable. Hypothetically, the details would be negotiated if there was another "suffix" proposal that had potential conflicts with BCP47.
- As a middle ground between these two, are there other specific uses of the period that may be impacted if it is used for demarcating a suffix?
Possibly. I am not concerned about that at this time.
Currently, we have one concrete use case and that is the need for localization, for which the requirements are pretty clear: to attach a language tag construct (language
-
country) to attributes. From the conversation in discuss/#244 there is convergence towards using period as marker to indicate start of a language tag. This is a much more specific need than a general extension of the allowed character set.
Agreed. My intention is a general extension.
from cf-conventions.
it is not clear what a "suffix" is, and how to distinguish one from some other possible usage patterns involving period and hyphen.
In the*nix world (and pretty much everywhere other than the old DOS 8.3 system), a "suffix" is the part after the last dot in a filename. By convension, but not by fiat, that suffix is a short code indicating the file type. As chaotic as that seems, it actually works pretty well. I think that's the case here too.
Step one: allow "." and "-".
Step two: establish one or more conventions for how they can be used, I would think starting with the idea of a "suffix" similar to the above, and then one or more uses for that, e.g. the language spec proposed.
In short, I think it's OK to leave it kind of loosey-goosey.
from cf-conventions.
Hi all,
At @JonathanGregory's request, I've volunteered to moderate this proposal. It looks like we are in agreement that the proposal is acceptable as-is, and it has received a sufficient amount of support.
Unless anyone has any new concerns to raise, this proposal will be accepted in three weeks.
from cf-conventions.
Thanks, @sethmcg.
PR #478 needs a couple of additions:
- the conformance document needs updating
- the revision history needs an entry
I don't think that these changes require a clock reset, as long as they're done and agreed before merging. @Dave-Allured - could you possibly add these items?
Many thanks,
David
from cf-conventions.
In my earlier comment I had some concerns, but they were/are not strong enough. As no one else have expressed thought in the same direction I am happy to support this proposal (with the same comment as @davidhassell regarding additions). Thanks @Dave-Allured and @sethmcg!
from cf-conventions.
Three weeks have passed with no new concerns raised, so this proposal is now slated to be accepted.
@davidhassell is PR #478 ready to go?
from cf-conventions.
Hold until I find time for completions requested by Jonathan.
from cf-conventions.
Will do!
from cf-conventions.
@davidhassell @sethmcg @JonathanGregory Conformance and history docs are now updated as requested. Anything else?
from cf-conventions.
I have just added a couple of nitpicking comments in the PR.
from cf-conventions.
I think it's ready now, thanks @Dave-Allured.
Would you like to merge it, @sethmcg?
from cf-conventions.
@JonathanGregory Merged!
Note: the "For maintainers" section on the PR boilerplate says "After the merge remember to delete the source branch." The button to do that isn't showing up for me, but the branch also isn't showing up in the list of branches for the repo. Has the repo been set to automatically delete merged branches? If so, that reminder should probably be removed from the PR boilerplate.
from cf-conventions.
Note: the "For maintainers" section on the PR boilerplate says "After the merge remember to delete the source branch." The button to do that isn't showing up for me ...
No. This is another github thing. That reminder should be aimed at the requestor, not maintainers. "Source branch" is referring to the requestor's branch, not necessarily a branch in the CF repo. It is generally the requestor's duty to clean up their own branches.
Perhaps that reminder should be reworded to clarify. The way it is now, is good enough for me.
from cf-conventions.
To strictly conform with CF rules, I am considering Lars' last minute PR requests to restart the wait clock for another three weeks. You can leave this issue closed and merged the way it is now. However, it would be fair to reopen the issue if anyone thinks it is necessary. (Hint: I hope not.) Sorry I did not catch this technicality before merge.
Follow up here or in the PR #478, I do not care which.
from cf-conventions.
@Dave-Allured Dave -- Sorry for the late comment!
No need at all to reopen this issue, or to restart the clock. That would only be if there were some kind of material change to the proposal. And my comments was nothing of that kind. Clearly Seth and Jonathan did not think the comments needed to be considered, which I am fine with -- no problem. Thanks for your contribution Dave!
from cf-conventions.
Related Issues (20)
- Bulk change "http://..." to "https://..." HOT 15
- Small update to text in section 2.3 regarding character sets HOT 4
- Incorrect formating for some `<=` in Appendix D HOT 2
- Appendix F: 14 `geotiff.maptools.org` domain links redirecting HOT 4
- Introduce `units_metadata` attribute to clarify the meaning of quantities involving temperature HOT 5
- Add a missing author to the list HOT 1
- Fix affiliation for Dave Allured HOT 2
- Problems in the github document build process HOT 7
- Simple correction to Example 6.1.2 HOT 5
- corrections to `units_metadata` text HOT 2
- Formatting of local links in text; Lists of Figures, Tables and Examples HOT 1
- Clarification of the use of `long_name`, `standard_name`, `cf_role` and non-standard attributes HOT 4
- Persistent removal of trailing whitespace for clean `diff`s HOT 13
- Incorporating the CFA convention for aggregated datasets into CF HOT 3
- In exceptional cases allow a standard name to be aliased into two alternatives HOT 6
- Appendix B: New element in XML file header to record the "first published date" HOT 5
- Include DOI and License information in the conventions document HOT 20
- recommendation of `standard_name` or `long_name` HOT 4
- Update the XML format specification in Appendix B to provide a robust link to the XML schema file HOT 7
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from cf-conventions.