<div dir="ltr">Hi Stephan:<div><br></div><div>I agree strongly with you, having seen similar issues from the POV of the netcdf-java library. It seems to be very common to confuse the reference library with the specification, whether it be file format, web service, OTW protocol, etc. Its so easy to fix something in the library. Im sure Ive done it myself. ;^(</div><div><br></div><div>Anyway, no sign it will happen here, but good reminder.</div><div><br></div><div>John</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 21, 2016 at 10:43 PM, Stephan Hoyer <span dir="ltr"><<a href="mailto:shoyer@gmail.com" target="_blank">shoyer@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">A custom attribute to identify netCDF4 files sounds perfectly reasonable as an iteration on the netCDF4 spec.</div><div class="gmail_quote"><br></div><div class="gmail_quote">But I'd like emphasize that it's important to continue to treat netCDF4 as a specification rather than merely whatever libnetcdf knows how to read and write. Doing so keeps you honest and forces more careful design.</div><div class="gmail_quote"><br></div><div class="gmail_quote">My project h5netcdf (<a href="https://github.com/shoyer/h5netcdf" target="_blank">https://github.com/shoyer/h5netcdf</a>) is one such reimplementation of netCDF4 on top of an HDF5 API, which has exposed a number of bugs and edge cases in the netCDF-C and Python netCDF4 libraries.</div><div><br></div><div>Cheers,</div><div class="gmail_quote">Stephan</div><div class="gmail_quote"><br></div></div></div>
</blockquote></div><br></div>