[NeXus-tech] Proposed revision of handling of arrays of strings

[Tobias.Richter at diamond.ac.uk]

We haven't fully defined what "maintenance mode" means. My heard bled when nxbrowse crashed with a SEGV on a file with string array attributes. So I fixed that. That to me is close to the core of maintenance, fixing important bugs.

I didn't understand that decision in the way that we would actively stop or discourage further development. For me it was just a statement we as a group would not commit to devoting much time to NAPI because of the limited use of it in the community and our limited time.

But that was decided for NAPI, not for the tools. nxbrowse, nxvalidate and all the others should work with any valid file and gracefully handle anything else. Even if that requires work on NAPI. I strongly think we need commonly accepted code that writes and reads files to benchmark interoperability. Being able to say: "nxvalidate does not understand your file - you are doing it wrong!" is important. What we have at the moment only works on the lowest level. Ideally we should aim for more (like parsing geometry) but again limited resources are a problem.

Regards,

Tobias


-----Original Message-----
From: NeXus-tech [mailto:nexus-tech-bounces at nexusformat.org] On Behalf Of Wintersberger, Eugen
Sent: 17 June 2014 09:38
To: NeXus Technical sub-committee list
Subject: Re: [NeXus-tech] Proposed revision of handling of arrays of strings

I agree with Herbert

On Mon, 2014-06-16 at 22:31 +0000, Tobias.Richter at diamond.ac.uk wrote:
> I second that. Reading strings in HDF5 isn't as pretty as it could be, but having string parsing code everywhere isn't better.

yeah :D

> 
> NAPI doesn't currently allow writing attribute arrays. However on reading they are currently presented as a backward compatible comma delimited string. So 1. is a NO-OP for NAPI users.

Isn't NAPI in a maintenance-only state without further development? If I recall correctly this was agreed upon at the last NIAC meeting in Abington.

regards
  Eugen

> 
> Tobias
> 
> ________________________________________
> From: NeXus-tech [nexus-tech-bounces at nexusformat.org] on behalf of 
> Herbert J. Bernstein [yayahjb at gmail.com]
> Sent: 16 June 2014 18:16
> To: NeXus Technical sub-committee list
> Subject: [NeXus-tech] Proposed revision of handling of arrays of 
> strings
> 
> In at least 2 places in the NeXus format, various arrays of strings as 
> used.  In the @axes attribute of data arrays in NXdata base class, the 
> axes are listed as a "colon-delimited array".  In the group_names 
> field of the NXdetector_group base class, the names are part of a 
> "comma separated list of name [sic]".  I don't know if there are other 
> simulated arrays of strings in the format, but I propose that we start 
> a move from simulated arrays of strings to actual arrays of strings.
> 
> HDF5 supports arrays of strings both for data fields and for attributes.
> We are already using that capability in the NXmx examples.  While 
> there are limitations, overall it make for cleaner, simpler code than 
> working with colon-separated or comma-separated simulated arrays.
> 
> I suggest that the NeXus dcumentation be amended to
> 
> 1.  Permit immediate optional use of actual arrays of strings in all 
> cases where colon-delimited or comma-delimited simulations of arrays 
> have been specified; and 2.  That a discussion be started on the 
> possibility of deprecating the use of colon-delimited or 
> comma-delimited simulations of arrays in favor of actual arrays of 
> strings.
> 
> Regards,
>   Herbert
> _______________________________________________
> NeXus-tech mailing list
> NeXus-tech at nexusformat.org
> http://lists.nexusformat.org/mailman/listinfo/nexus-tech
>