[NIAC 2018 Discussion] Messy specifications

[vasole]

I would like to draw your attention that by setting changing or free to interpret specifications you are cooking a messy format:

NX_CHAR:	any string representation All strings are to be encoded in UTF-8. Includes fixed-length strings, variable-length strings, and string arrays. Some file writers write strings as a string array of rank 1 and length 1. Clients should be prepared to handle such strings.

That clients should be ready to handle such strings does not mean that they are acceptable. I find legitimate that readers make the life of the users of such files difficult so that in turn they make sure the writers write proper files.

The NeXus API was writing things properly. At least I never encountered such discrepancies in old files (remember the 2010 workshop at the ESRF?). If people decide to use other things, they have to write correctly and not put the burden at the readers.

A specification can be bad, but a changing specification is even worse.

When I think about the lengthy discussion concerning auxiliary_signals that could have been avoided by allowing NXdata@signal to be a list of strings instead of a string I get really angry. It was said that allowing a list of strings could break code when reading the above specification the clients should have been already prepared!!!!

I really wonder how many NIAC members are actually developing software for other facilities because as a developer I cannot understand some decisions.

[vasole]

@prjemian

Proposal new text

NX_CHAR:	The preferred string representation is UTF-8. Use of fixed-length strings and variable-length strings is accepted. String arrays cannot be used where only a string is expected (title, start_time, end_time, NX_class attribute,...). Attributes requiring the use of string arrays will be clearly marked as such (like the NXdata attribute auxiliary_signals).

[vasole]

@zjttoefs @mkoennecke

Please can you check if you prefer the word accepted or tolerated

[rayosborn]

I would suggest replacing "Use of fixed-length strings and variable-length strings is accepted" with "Both fixed-length strings and variable-length strings are valid."

[zjttoefs]

With both options being in the same sentence I see no functional difference between accepted or tolerated. Ray's suggestion is more neutral and my preference.

[vasole]

OK then the proposal new text is

NX_CHAR:	The preferred string representation is UTF-8. Both fixed-length strings and variable-length strings are valid. String arrays cannot be used where only a string is expected (title, start_time, end_time, NX_class attribute,...). Attributes requiring the use of string arrays will be clearly marked as such (like the NXdata attribute auxiliary_signals).

[zjttoefs]

Last sentence should start with "Fields or attributes".

[vasole]

Thanks

NX_CHAR:	The preferred string representation is UTF-8. Both fixed-length strings and variable-length strings are valid. String arrays cannot be used where only a string is expected (title, start_time, end_time, NX_class attribute,...). Fields or attributes requiring the use of string arrays will be clearly marked as such (like the NXdata attribute auxiliary_signals).

[zjttoefs]

I'm happy with that!

[prjemian]

This text appears in <definitions>/nxdlTypes.xsd

[prjemian]

definitions issue created, so closing here