Russ Rew: Re: problem with []() in 3.4 version

> To: Russ Rew <address@hidden>
> From: "R. Bauer" <address@hidden>
> Subject: Re: problem with []() in 3.4 version
> Organization: Institut fuer Stratosphaerische Chemie (ICG-1)

Hi again Reimar,

> > The CDL name restrictions are not arbitrary, but rather are dictated by
> > the ability to write a grammar for a small language (CDL) that
> > unambiguously represents the structure of netCDF datasets.  For example,
> > currently the CDL declaration
> >
> >     float x(m);
> >
> > means "x" is a floating-point variable of rank 1 with dimension "m".  If
> > the characters "(" and ")" are permitted in variable names, then this
> > statement becomes ambiguous, since it could also mean that "x(m)" is a
> > scalar floating-point variable (of rank 0).  Similarly, the CDL
> > declaration
> >
> >     temp:units         = "celsius";
> >
> > means the "units" attribute of a variable named "temp" has the string
> > value "celsius".  If the character ":" were allowed in variable names,
> > this statement becomes ambiguous, since it could also refer to a variable
> > named "temp:units".  Such ambiguities are a real problem if a simple
> > parser based on yacc is to be implemented, and ncgen is such a parser.
> 
> I am understanding this.In this way it's reached the mostly directly
> understanding way of the CDL code.  If I suggest now to handle a mask
> sign for those probably ambigous signs e.g. <:> this makes the code
> not better readable.  All the people which are not using these
> probably ambigous signs would have the same CDL code without the mask
> signs.
> 
> The people using probably ambigous signs in netCDF have to accept the
> mask signs in the CDL.  I am not saying that's "<>" is the best mask
> sign. Many languages are having mask signs.  In idl it's "!". If you
> want to use "!" you have to write it twice "!!"  html is using "<>".
> 
> Is this a possible way in later versions?

Yes, it's a good idea, and I wish we had thought of it before
restricting the characters in names permitted by the library.  Since we
are already using the '\' character to escape occurrences of the '"'
character within CDL strings and requiring '\\' to represent a `\' in a
string, '\' seems like the natural choice for an escape character.  If
this could be implemented, a name containing ':' would appear like
foo\:bar in CDL.  It would require changes to ncdump and ncgen to
support this escape convention.  I don't know how difficult this would
be to implement, but it seems feasible.

> > I'm not sure there would be any problem with permitting any of "@#[]"
> > without modifying the grammar to try these out, but I'm also not sure
> > whether these would be of any use to you in a CDL that does not permit
> > "(" and ")" in names.  And there may be additional problems with adding
> > such characters for other existing language interfaces, such as perl,
> > Matlab, python, IDL, etc.  So I'm sorry, but I can't commit to such a
> > change without more research ...
> 
> It would be fine for me if I could use in future again "@#[]" In the
> actually idl5.03 Version and the new one idl5.1 is netcdf2.4
> implemented.  That is an old version where all these chars are
> allowed. I often use idl and that's the reason why I was surprised
> about the differences to netCDF Version3.4 I don't know which versions
> actually in perl, python and matlab are implemented.
> 
> We are using fortran and C interfaces too and I don't understand
> myself why we did'nt seen in this case what this changes are meaning
> to us.
> 
> I was interesting me myself for the Version 3.4 because of your
> development with the c interface and the better portability to CRAY or
> PC platforms.  So I missed all pages regarding to preliminary
> Versions. I am sorry that's a year has gone without the necessary
> response to you.

I have verified that it is possible to allow the characters "@#[]" in
CDL names with fairly minor changes to the library and ncgen.  But the
approach of allowing an escape character in CDL names seems like a
better, more general approach, since then names could also include
other characters.  If you want the changes needed to just support
"@#[]", I can send them, but I don't want to commit to such a change at
this time without further discussion here on the implications of this or
the escape solution.

Thanks for the suggestions.

--Russ