Make example NXreflection files more like base classes

[phyy-nx]

Should be merged concurrently with nexusformat/definitions#752

[prjemian]

No such base class: NXdials

      dials:NXdials
        @NX_class = NXdials

[prjemian]

hang on, those comments are from viewing content in master

[prjemian]

time to rename DETAILS.rst to README.txt. README is consistent with other directories. This is not restructured text format.

[prjemian]

from punx

hdf5 address	finding	test name	comment
/entry/experiment_0/dials	ERROR	known NXDL	NXdials: recognized NXDL specification
/entry/experiment_0/dials	ERROR	NeXus base class	unknown NeXus base class: NXdials
/entry/experiment_0/dials@NX_class	ERROR	attribute value	not a recognized NXDL class: NXdials

[phyy-nx]

Right, NXdials is something from a few years ago that didn't make the jump to NeXus itself. I think it's extra glue to help DIALS with NXreflections. I'm not sure if it is relevant anymore. I'll ask around in DIALS land but I don't think it matters for this PR.

[prjemian]

punx is also telling me (but I'm not certain I can trust it for this to be an error yet):

hdf5 address	finding	test name	comment
/entry/experiment_0@None	ERROR	NXDL field	NXmx:start_time not found
/entry/experiment_0@None	ERROR	NXDL field	NXmx:end_time not found

These fields are defined in the NXmx definition that appears in v2020.1rc2 which is used for validation. punx's validation of data files with application definitions needs serious work; this is an example.

[prjemian]

Those are optional fields and punx does not yet understand about that possibility. Ignore that finding, then.

[prjemian]

NXdials does matter. It is not allowed in a NeXus file. See the second bullet point after https://manual.nexusformat.org/datarules.html. Basically, you must only use the @NX_class attribute with the name of a NeXus base class, application definition, or contributed definition. NXdials is not in that list. You could change the name of the attribute to something that does not begin with NX (upper or lower case) and then NeXus would not care about it, it would be a group that NeXus would ignore. OR, you could find an existing base class...

[prjemian]

my imagination suggests @possible_NX_class

[phyy-nx]

Thanks @prjemian! I've created an issue here: dials/dials#1124.

Do you want to hold this PR though? Or create a separate issue about this? For me, the dials issue is sufficient.

[prjemian]

I believe that a quick decision is not so likely. Are you OK with delaying?

[phyy-nx]

Whatever it takes is fine, since isn't part of the NeXus release. I do think the NXdials thing and the intent of this pull request are being conflated. This pull request is just to sync with nexusformat/definitions#752.

[prjemian]

The only problem is adding a data file with a non-compliant component like that tempts others to follow the practice. Can you change that for the deposition here, then revise it after consideration from dials/dials?

[phyy-nx]

@prjemian @NX_class=NXdials now removed. Ready for re-review at your convenience. Thanks.