NOTE: The netcdf-hdf mailing list is no longer active. The list archives are made available for historical reasons.
Hi all,
I've talked with Mike & Elena here about how to support these "zero-length"
attributes in HDF5 and we've come up with three approaches:
1 - Basically the idea that Russ mentioned (using a zero-length string) to
represent the attribute. This has problems with being able to be
distinguished from user-defined zero-length strings though and would
therefore probably require a prefix to be appended to the name (like
"__netcdf_boolean_") or some way to separate out these types of
attributes from the namespace that user's create attributes within.
(If the prefix idea is chosen, then it will need to be documented, etc.)
2 - A slightly more elegant solution might be to use a scalar dataspace (as
in option 1), but use a boolean datatype (like hbool_t) to store the
value, since that's really what's being stored here. This has the same
drawbacks about naming, etc.
3 - The most elegant solution is to add a "empty" ("nil", "null", anyone have
an opinion on the name? I like "empty") dataspace to HDF5. This would
just be a dataspace with no elements in it. Obviously, there would be
no way to perform I/O on it and it would use no storage space for the
raw data, etc.
I would lean toward solution #3 in the medium to long term (i.e. sometime
in the next few months) and would suggest solution #2 until we've implemented
the empty dataspace concept.
Quincey
> Mike Folk <mfolk@xxxxxxxxxxxxx> writes:
>
> > Ed,
> > Is a zero-length attribute in netCDF the same as a scalar, or is it
> > more like an empty array? I can't imagine a use for the latter, but
> > if it's needed it's needed.
> >
>
> It's more like an empty array, since a scalar would have one value to
> read/write, and an empty attribute has zero bytes to read and write.
>
> Of course if this was extremely difficult we could ask how much we
> really need it. Right now, it's "needed" in the sense that we have a
> requirement to support existing netcdf programs with a recompile, and
> they might be using zero length attributes.
>
> If there's an easy/elegant way to fake it, I'm certainly open to
> suggestions. I can't think of anything at the moment except to have a
> table of attribute names and lengths. We could store a zero in such a
> table, and store a byte of garbage in the actual attribute. The table
> entry could tell me that this attribute has length zero.
>
> But let's face it, that would be pretty cheesy! It would be a lot
> nicer all around if HDF5 allowed zero length attributes, if it's
> really easy for you to do so.
>
> Ed
>
netcdf-hdf archives: