Thank you everyone for your efforts with this!
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/243#issuecomment-698976288
This list forwards relevant notifications from
Closed #243 via #294.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/243#event-3806215352
This list forwards relevant notifications from Github. It is distinct from
Reopened #243.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/243#event-3705525148
This list forwards relevant notifications from Github. It is distinct from
Some final rewording agreed above
(https://github.com/cf-convention/cf-conventions/issues/243#issuecomment-597152790)
didn't get pushed to PR #244 before it was merged.
Reopening this issue and linking new PR (#294).
--
You are receiving this because you are subscribed to this thread.
Reply to
It looks like consensus has been reached on the text as it stands - I'm
starting the countdown and will merge this PR, barring objections or further
changes, on 2020-04-16.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@ethanrd : yes, dropping "assigned" is a good idea and I like your latest
reformulation.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/243#issuecomment-597187583
@graybeal @martinjuckes @JimBiardCics - Thanks for your input.
@martinjuckes : I agree the first sentence in the [Data Type
section](http://cfconventions.org/cf-conventions/cf-conventions.html#_data_types)
could be stronger. I would suggest simplifying your alternate sentence by
dropping
@ethanrd I like your verbiage. I think you could simplify it a bit by saying
In many situations, any integer type may be used.
When the phrase "integer type" is used in this document, it should be
understood to mean **`byte`**, **`unsigned byte`**, **`short`**, **`unsigned
short`**, **`int`**,
(Just an idea, take it or leave it.) I would add the following text after the
next-to-last sentence in the paragraph (which first uses the phrase "integer
types"): "In this document, the term "integer type" includes all of the
following types: …" Could be in parentheses, or not.
I think that
Expanding to
... When the phrases "an integer type" or "any integer type" are used ...
Anything else? Or again, better wording all around?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
I am adding the following sentences to the end of the first paragraph in
Section 2.2 "Data Types":
In many situations, any integer type may be used.
When the phrase "any integer type" is used in this document, it should be
understood to mean **`byte`**, **`unsigned byte`**, **`short`**,
While I agree with @Dave-Allured on keeping PRs focused, I can also see
@martinjuckes point that the "must be type integer" statements are linked to
this PR. It is also a pretty minimal change, so I will update the "must be type
integer" statements and push that change to this PR.
The
> perhaps you'd be interested in contributing those to @ethanrd 's PR?
No thank you. I believe that the original proposal is sufficient and elegant.
I would prefer to leave further tuning to those contributors who are
unsatisfied and have changes to offer.
--
You are receiving this because
I think readers of the document would probably want to understand "integer" to
mean any integer type (any number of bytes, signed or unsigned). There is one
reference to integer in regard to `flag_values` and `flag_meanings`, which must
be of the same type as the data variable (whatever that
As noted by @Dave-Allured, @ethanrd is attempting to remove restrictions on
data types in general. This has broad support. The concern of @martinjuckes is
that it would be possible to lift the current restriction on index variables,
as is used for ragged arrays. However, this could also be
# Summary
3 weeks have passed since any contribution and it seems we're pretty much at
consensus. Supporting voices, including some from the Conventions Committee:
- @ethanrd (Conventions Committee)
- @erget
- @Dave-Allured
- @czender
In my opinion one item should be addressed before this
I support this, it will be very welcome.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/243#issuecomment-584844080
This list forwards relevant notifications from
@ethanrd The CF documentation regarding constants of various types references
the NUG, which gives some examples of CDL syntax, but which is by no means a
rigorous description of how to represent each data type in an attribute. The
**ncgen** man page has a discussion of this, but that sure
@martinjuckes Notice that the examples where **`flag_values`** are given as 1b,
2b, etc, have the 'b' indicator because the variables in the examples are of
type **`byte`**. It would be good to change an example to use a different
integer type so that this is clearer. We should also make sure
I wholeheartedly approve of this proposal. @martinjuckes makes an excellent
point regarding "must have an integer type".
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Hi Ethan, I support this .. but we need to check other references to "integer".
There are 9 statements in the convention that something "must be type integer"
(e.g. "In this representation, the file contains an index variable , which must
be of type integer, and must have the sample dimension
@ethanrd I'm happy to moderate this if you like. I also support this proposal.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/243#issuecomment-584514450
This list
Me two.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/243#issuecomment-584438861
This list forwards relevant notifications from Github. It is distinct from
Meant to ping a few others involved in original discussions: @JimBiardCics
@Dave-Allured @rsignell-usgs (didn't find user names for all from email
discussion).
I wasn't involved in earlier discussions and happy to be moderator.
--
You are receiving this because you are subscribed to this
24 matches
Mail list logo
