<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Dear Bob and all,<br>
    <br>
    I have not had time to follow this thread in detail, but a remark
    (in the most recent email) that seemed unnecessarily sarcastic
    caught my eye, and impelled me to look into what might have led to
    this dip in our normally courteous, respectful discourse.  As Chair
    of the CF Governance Panel, I feel obliged to remind everyone that
    the success (and fun!) of our endeavor depends on enthusiastic
    engagement, which is only discouraged if what ought to be earnest
    debate and substantive argument is disrupted (however briefly and
    unintentionally) by remarks that could be interpreted as being even
    slightly derogatory.  There are no "supreme authorities" here
    (although some are much more knowledgeable than others).  We
    progress by consensus, and only respectful contributions to the
    discussion can be tolerated. <br>
    <br>
    Enough said about that.<br>
    <br>
    Addressing only the part of the "pre-proposal" that suggests there
    is a need to explicitly distinguish strings from characters (not the
    part of the proposal that deals with the flavor of the 7 or 8 bit
    representation of characters):<br>
    <br>
    1)  Note that the H.4 example being discussed was slightly modified
    (I think on 29th February 2016), and now includes "station_name" in
    the list of coordinates, thus explicitly linking it to the humidity
    and temp variables.  This along with the fact that station_name is
    *not* included as a dimension for these variables allows you to
    infer that this is a *single* station described by a character
    string of length 23, and not 23 stations with single character
    i.d.'s.  <br>
    <br>
    2)  If the coordinate dimension is *required* in this case (and
    currently it may not be), then software should be able to
    unambiguously interpret things.  [This requirement was suggestion 2
    (of 3), made my Jonathan in one of his earlier comments.]<br>
    <br>
    best regards,<br>
    Karl<br>
    <br>
    <br>
    <br>
    <div class="moz-cite-prefix">On 3/7/17 11:08 AM, Bob Simons - NOAA
      Federal wrote:<br>
    </div>
    <blockquote
cite="mid:CAG=jf3cVqLrmMjEVQhnxu4ss=ocHEuufU+8FbS6b_u0XKyn55w@mail.gmail.com"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html;
        charset=windows-1252">
      <div dir="ltr">
        <div>Jonathan, I believe that you place an unreasonable burden
          on general-purpose software readers of netcdf-3 files, which
          you expect to include AI-like code which completely
          "understands" all possible CF files, just so it can tell the
          difference between char variables meant to be interpreted as
          chars and char variables meant to be interpreted as strings
          (by collapsing the rightmost dimension). The supreme
          authorities, you and David Hassell (your own employee?!),
          couldn't even agree on whether H4 was a valid CF file. How can
          you then demand that software do better? </div>
        <div> <br>
        </div>
        <div>It is easy/trivial for software reading a netcdf-4 file (as
          defined in NUG) to distinguish char variables and String
          variables, why is it so wrong to ask for the same ease/clarity
          with netcdf-3 files? </div>
        <div>Part of my effort here was to start dealing with the
          massive rift between CF (which only covers netcdf-3 files) and
          NUG (which covers netcdf-3 and netcdf-4 files). Isn't that a
          reasonable goal? </div>
        <div><br>
        </div>
        <div>And even if you ignore the issue of distinguishing chars
          from strings, there is still no attribute in CF to specify the
          character set for char scalars and char arrays that are to be
          interpreted as chars.</div>
        <div>You can't say "_Encoding" because the default for _Encoding
          is "UTF-8", which is not a valid option for char scalars and
          char arrays because it may span multiple chars. The list of
          valid character sets for char scalars and char arrays (in
          netcdf-3 and netcdf-4 files) must be different from the list
          of valid _Encodings for strings. A different attribute, e.g.,
          charset, is needed for chars (as opposed to strings) in
          netcdf-3 and netcdf-4 files.</div>
        <div><br>
        </div>
        <div><br>
        </div>
      </div>
      <div class="gmail_extra"><br>
        <div class="gmail_quote">On Tue, Mar 7, 2017 at 9:03 AM,
          Jonathan Gregory <span dir="ltr"><<a
              moz-do-not-send="true"
              href="mailto:j.m.gregory@reading.ac.uk" target="_blank">j.m.gregory@reading.ac.uk</a>></span>
          wrote:<br>
          <blockquote class="gmail_quote" style="margin:0 0 0
            .8ex;border-left:1px #ccc solid;padding-left:1ex">Dear Chris<br>
            <br>
            > We need to be "clear" about what we mean by "the intent
            is clear". I think<br>
            > that much of the point of CF is to be as explicit as
            possible, -- i.e. the<br>
            > reader of a CF file should not have to know anything
            about how given data<br>
            > tends to be used in order to determine what data type
            an array should be<br>
            > (or what shape it should be).<br>
            <br>
            Yes, I agree with that. However, if you're reading a CF
            file, you aren't<br>
            just reading plain variables. If you're using/writing
            software which knows<br>
            how to interpret the file following the CF convention, it
            should know what<br>
            the "intent" is, in a CF context, of each of the variables
            of interest.<br>
            For example, you know that an auxiliary coordinate variable
            of char data must<br>
            be a vector of strings, and the trailing or only dimension
            is the max string<br>
            length. If you came across this variable when scanning all
            the variables in<br>
            a netCDF file, with no interest in CF, you wouldn't know
            that it was an array<br>
            of strings, but if you are using it as a CF aux coord var,
            you do know that,<br>
            so I don't think any further signal is needed - it would be
            redundant.<br>
            <br>
            Best wishes<br>
            <br>
            Jonathan<br>
            <br>
            ----- Forwarded message from Chris Barker <<a
              moz-do-not-send="true" href="mailto:chris.barker@noaa.gov">chris.barker@noaa.gov</a>>
            -----<br>
            <br>
            > Date: Mon, 6 Mar 2017 11:16:35 -0800<br>
            > From: Chris Barker <<a moz-do-not-send="true"
              href="mailto:chris.barker@noaa.gov">chris.barker@noaa.gov</a>><br>
            > To: Jonathan Gregory <<a moz-do-not-send="true"
              href="mailto:j.m.gregory@reading.ac.uk">j.m.gregory@reading.ac.uk</a>><br>
            > CC: "<a moz-do-not-send="true"
              href="mailto:cf-metadata@cgd.ucar.edu">cf-metadata@cgd.ucar.edu</a>"
            <<a moz-do-not-send="true"
              href="mailto:cf-metadata@cgd.ucar.edu">cf-metadata@cgd.ucar.edu</a>><br>
            > Subject: Re: [CF-metadata] Pre-proposal for "charset"<br>
            ><br>
            > On Mon, Mar 6, 2017 at 9:47 AM, Jonathan Gregory <<a
              moz-do-not-send="true"
              href="mailto:j.m.gregory@reading.ac.uk">j.m.gregory@reading.ac.uk</a>><br>
            > wrote:<br>
            ><br>
            > > Yes, we can reopen the ticket. I think the
            _Encoding for char is a good<br>
            > > idea,<br>
            > > especially if it's an NUG convention.<br>
            ><br>
            ><br>
            > so let's do that part at least.<br>
            ><br>
            > > Are there any files out in the wild that DO use ND
            arrays of NC_CHAR that<br>
            > > > are not intended to be interpreted as a
            (N-1)D array of Strings?<br>
            > ><br>
            > > That is the question. In particular, since this
            the CF convention we're<br>
            > > talking about, are there any char arrays which are
            part of CF,<br>
            ><br>
            ><br>
            > indeed.<br>
            ><br>
            ><br>
            > > where the<br>
            > > intent is not clear?<br>
            > ><br>
            > We need to be "clear" about what we mean by "the intent
            is clear". I think<br>
            > that much of the point of CF is to be as explicit as
            possible, -- i.e. the<br>
            > reader of a CF file should not have to know anything
            about how given data<br>
            > tends to be used in order to determine what data type
            an array should be<br>
            > (or what shape it should be).<br>
            ><br>
            > I saw this an an author of sometimes generic tools --
            the tool should be<br>
            > able to read the file, and produce the appropriate
            native array for the<br>
            > task at hand, without knowing something like: "ahh,
            this is the ID of a<br>
            > Acme-ocean-widget -- those use char IDs -- so this must
            be a char" --<br>
            > Humans can do that -- software can't (not easily
            anyway!)<br>
            ><br>
            > And clearly specifying whether a char array is a char
            array or a string<br>
            > array will better unify netcdf3 and netcdf4.<br>
            ><br>
            > netcdf4 can be explicit about it -- netcdf3 can't -- so
            it'd be nice if CF<br>
            > could fill that gap.<br>
            ><br>
            > Now that I think about it, this really should be a
            netcdf convention --<br>
            > like _FillValue, but this is a CF list....<br>
            ><br>
            > -CHB<br>
            ><br>
            > --<br>
            ><br>
            > Christopher Barker, Ph.D.<br>
            > Oceanographer<br>
            ><br>
            > Emergency Response Division<br>
            > NOAA/NOS/OR&R            <a moz-do-not-send="true"
              href="tel:%28206%29%20526-6959" value="+12065266959">(206)
              526-6959</a>   voice<br>
            > 7600 Sand Point Way NE   <a moz-do-not-send="true"
              href="tel:%28206%29%20526-6329" value="+12065266329">(206)
              526-6329</a>   fax<br>
            > Seattle, WA  98115       <a moz-do-not-send="true"
              href="tel:%28206%29%20526-6317" value="+12065266317">(206)
              526-6317</a>   main reception<br>
            ><br>
            > <a moz-do-not-send="true"
              href="mailto:Chris.Barker@noaa.gov">Chris.Barker@noaa.gov</a><br>
            <br>
            ----- End forwarded message -----<br>
            ______________________________<wbr>_________________<br>
            CF-metadata mailing list<br>
            <a moz-do-not-send="true"
              href="mailto:CF-metadata@cgd.ucar.edu">CF-metadata@cgd.ucar.edu</a><br>
            <a moz-do-not-send="true"
              href="http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata"
              rel="noreferrer" target="_blank">http://mailman.cgd.ucar.edu/<wbr>mailman/listinfo/cf-metadata</a><br>
          </blockquote>
        </div>
        <br>
        <br clear="all">
        <div><br>
        </div>
        -- <br>
        <div class="gmail_signature" data-smartmail="gmail_signature">
          <div dir="ltr">Sincerely,<br>
            <br>
            Bob Simons<br>
            IT Specialist<br>
            Environmental Research Division<br>
            NOAA Southwest Fisheries Science Center <br>
            99 Pacific St., Suite 255A      (New!)<br>
            Monterey, CA 93940               (New!) <br>
            Phone: (831)333-9878            (New!<span
              style="font-size:13.3333339691162px">)</span>
            <div>Fax:   (831)648-8440<br>
              Email: <a moz-do-not-send="true"
                href="mailto:bob.simons@noaa.gov" target="_blank">bob.simons@noaa.gov</a><br>
              <br>
              The contents of this message are mine personally and <br>
              do not necessarily reflect any position of the <br>
              Government or the National Oceanic and Atmospheric
              Administration.<br>
              <>< <>< <>< <><
              <>< <>< <>< <><
              <>< <br>
              <br>
            </div>
          </div>
        </div>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
CF-metadata mailing list
<a class="moz-txt-link-abbreviated" href="mailto:CF-metadata@cgd.ucar.edu">CF-metadata@cgd.ucar.edu</a>
<a class="moz-txt-link-freetext" href="http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata">http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>