Have reconsidered, and now lean towards using "shape" instead of "dimensions". This would be consistent with NcML, and prevent parsers from needing to implement context-sensitive definitions.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Also just noticed a potential omission from the current definition and implementation: record dimensions. Record dimensions are fundamental to the on-disk representation of data in netCDF, so the JSON format seems incomplete without a way to tag a dimension as a record dimension. Or is the property of being a record dimension just another "hidden attribute" like compression and byte-order that JSON need not know about since it does not affect the data values? Am considering modifying the dimension definition from a name-value pair to an object containing two name-value pairs: "length = int" and "isUnlimited = bool" (same keywords as XML). Opinions?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
hmm -- I'm inclined to think that the the record dimensions are an impiimentation detail. and adding it to the dimension object does add one more level of indirection, which is kind of ugly.
Though that isUnlimited flag would let you re-create essentially the same netcdf file from a JSON file -- which I'm sure is why ncML has it.
I guess it comes down to use case -- might we want to use JSON like CDL and ncML -- as a human-readable versiin of netcdf -- or is really just antoher way to express the same data model?
-CHB
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It is possible to do it both ways. Leave the default dimension as a name-length pair as now. Then for extreme pedantic mode make the dimension an object. The same way an attribute becomes an object in pedantic mode.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Have reconsidered, and now lean towards using "shape" instead of "dimensions". This would be consistent with NcML, and prevent parsers from needing to implement context-sensitive definitions.
I think consisentcy with ncML is good, too.
Also just noticed a potential omission from the current definition and implementation: record dimensions. Record dimensions are fundamental to the on-disk representation of data in netCDF, so the JSON format seems incomplete without a way to tag a dimension as a record dimension. Or is the property of being a record dimension just another "hidden attribute" like compression and byte-order that JSON need not know about since it does not affect the data values? Am considering modifying the dimension definition from a name-value pair to an object containing two name-value pairs: "length = int" and "isUnlimited = bool" (same keywords as XML). Opinions?
hmm -- I'm inclined to think that the the record dimensions are an impiimentation detail. and adding it to the dimension object does add one more level of indirection, which is kind of ugly.
Though that isUnlimited flag would let you re-create essentially the same netcdf file from a JSON file -- which I'm sure is why ncML has it.
I guess it comes down to use case -- might we want to use JSON like CDL and ncML -- as a human-readable versiin of netcdf -- or is really just antoher way to express the same data model?
-CHB
It is possible to do it both ways. Leave the default dimension as a name-length pair as now. Then for extreme pedantic mode make the dimension an object. The same way an attribute becomes an object in pedantic mode.