Let the bike shedding continue!
On Wed, Jan 15, 2014 at 1:14 PM, John Graybeal wrote:
> I don't think multiple use cases from different individuals and
> communities should be categorized as "no reason other than maybe taste".
> Just sayin'...
>
> multiple use-cases are examples not reasons -- "
John Graybeal wrote:
> This prompts me to observe that somehow, in this brave new age of computer
> programming, people are
> developing netCDF software that supports Unicode characters -- Unicode!! --
> in variable (attribute
> etc) names. There will be netCDF files in the wild, used by scientis
And I wasn't going to say anything else, but this crystallized an issue or two
from past mails. I promise to (try to) let it go after this.
On Jan 15, 2014, at 12:37, Chris Barker wrote:
> There is an existing rule about what charactors can be used for variable
> names, that's it -- and we've
On Wed, Jan 15, 2014 at 9:24 AM, Jim Biard wrote:
> The point is, the Conventions themselves state that there is *no standard*.
> People are all the time trying to add meaning to variable names, but the
> standard actually states that the meaning is to reside in the attributes.
>
but we aren't
On 1/15/2014 10:28 AM, John Graybeal wrote:
Perhaps a reference to the IETF RFC 2119 [1] (which defines these and a few
other related terms) should be added to the CF spec
Yes please, since discussion on this thread has already varied in its
understanding/application of those terms.
The ambi
I have two use cases:
MBARI has data from an underwater vehicle that contains hundreds of engineering
variables that are automatically logged using the onboard software's names for
the variables. Those variables include the '.' character. We tried to use our
existing NetCDF TDS/Hyrax infrastruc
> Perhaps a reference to the IETF RFC 2119 [1] (which defines these and a few
> other related terms) should be added to the CF spec
Yes please, since discussion on this thread has already varied in its
understanding/application of those terms.
The ambiguity in the sentence "No variable or dimen
Hi all,
The use of "should" may, by many, be interpreted as a recommendation
rather than as a requirement.
Though the terms "must", "should", and "may" are used throughout the CF
spec, I am not finding any text that defines those terms.
Perhaps a reference to the IETF RFC 2119 [1] (which defines
All,
Yes, that statement seems quite definitive and unambiguous, and for the
reasons stated in other emails, I support retaining it.
regards,
Karl
On 1/15/14 9:37 AM, Steve Hankin wrote:
On 1/15/2014 9:24 AM, Jim Biard wrote:
Chris,
The point is, the Conventions themselves state that ther
On 1/15/2014 9:24 AM, Jim Biard wrote:
Chris,
The point is, the Conventions themselves state that there is *no
standard*. People are all the time trying to add meaning to variable
names, but the standard actually states that the meaning is to reside
in the attributes. The variable names ar
Chris,
The point is, the Conventions themselves state that there is no standard.
People are all the time trying to add meaning to variable names, but the
standard actually states that the meaning is to reside in the attributes. The
variable names are just keys for differentiating the variable
On Wed, Jan 15, 2014 at 7:39 AM, jbiard wrote:
> I don't think we should use ease of mapping variable names to a
> programming language as a reason for allowing (or not allowing) any
> particular character in variable names.
>
Why not? maybe not a compelling reason, but I can't imagine a compell
Hi.
I don't think we should use ease of mapping variable names to
a programming language as a reason for allowing (or not allowing) any
particular character in variable names. CF has, as I understood it,
considered variable names as completely up to the producer, relying on
attributes to provi
There is another reason:
mapping CF variable names directly to programming language variable names
is pretty handy -- so it's nice if those are legal.
I'm sure not all programming languages have the same restrictions on names,
but there is surely a subset that's pretty common (i.e. none of the us
Hi John,
Philosophically I am aligned with Bryan: the purpose of the CF standard
is to constrain (simplify and make predictable) the use of a highly
general file creation toolkit like netCDF. The question of limitations
placed on name strings should be evaluated on this yard stick.
There
Not sure I am following you -- constraints are presumably there for a reason, I
wasn't sure what the reason was for these particular constraints, but thought
they might have simply echoed earlier netCDF constraints.
To your 'use case' question, we were thinking about alternatives to mx_ as
pref
Hi John
In the spirit of CF being *constrained* netCDF, it seems that we wouldn't,
unless we had a specific use case ... do you?
Cheers
Bryan
On 13 January 2014 18:54, wrote:
> As netCDF is growing to allow @, +, hyphen, and period in
> variable/dimension/attribute names, is there any likelih
17 matches
Mail list logo
