[Nexus-developers] NeXus-2010 workshop
"V. Armando Solé"
sole at esrf.fr
Wed May 19 14:13:19 BST 2010
Carlos Pascual wrote:
>On Tue May 18 2010 15:32:39 freddie.akeroyd at stfc.ac.uk <http://lists.nexusformat.org/mailman/listinfo/nexus-developers> wrote:
>>/ Hi Mark,
/>>/
/>>/ I'm glad you had a productive meeting.
/>>/
/>>/ I agree with the idea of an NXsubentry (1.2.1), but I've been thinking
/>>/ if this is the best name. As it is related to an "application or domain
/>>/ specific definition" maybe the class name should reflect this? Something
/>>/ along the lines of NXappdef, NXapplication, ... However the counter
/>>/ argument is that application definitions already apply to NXentry so
/>>/ calling it "NXsubentry" fits more with the current model. I was
/>>/ wondering though if we were moving towards application definitions only
/>>/ applying to "subentries" and not to "entries" themselves in which case
/>>/ an NXappdef etc. class name could be a more appropriate.
/
>Actually, the name we used originally was NXApplication, but after some debate
>we considered that the class was actually just the same as an NXentry (only
>that it was within an NXentry). Hence NXsubentry.
>
>But I think everybody in the group who made the proposal would agree in that
>the name is non-important as long as the functionality is provided.
Well, in fact the obvious choice was NXapplication.
NXsubentry was just meant to keep the same feeling as previous NXentry in the sense that it was a group containing application definitions.
If we go towards Gerd's proposition having all applications at the NXentry level, then NXsubentry does loose its meaning and NXapplication reflects better what in fact it is (a group providing actual data or link to the actual data required to perform a certain type of analysis).
By other hand, I would find NXsubentry very appropriate for external links pointing to NXentries in other files. Something very likely to happen when dealing with large amounts of data.
Best regards,
Armando
More information about the NeXus-developers
mailing list