[NeXus-definitions-tickets] [NeXusDefinitions] #65: Points to consider for NXDL

[NeXus Base Classes and Instrument Definitions]

#65: Points to consider for NXDL
------------------------+---------------------------------------------------
Reporter:  Pete Jemian  |      Owner:     
    Type:  defect       |     Status:  new
Priority:  major        |   Keywords:     
------------------------+---------------------------------------------------
 == Points to consider for NXDL ==

  1. '''Application definitions''' will override the standard definition of
 (the base class) '''NXentry''' and provide fields and groups that
 '''must''' be present in a NeXus data file.  Other fields or groups from
 NXentry (or other base classes) are optional, as usual.

  2. Some mechanism needs to exist within the '''NXroot''' base class to
 identify the use of an application definition to use instead of the
 standard '''NXentry'''.
     * One suggestion is to add an optional ''NXDL'' attribute to the
 NXentry group entry where the value of the attribute is the name of the
 application definition.  This preserves Mark Koennecke's suggestion:
 ''[The reference to the defining NXDL] needs to be at a standard place
 across all files and it needs to live below NXentry as a NeXus file may
 contain different entries adhering to different definitions.''  For
 example:
 {{{
     <NXentry name="SCAN_0001" NXDL="NXmonopd">
       <!-- the NXmonopd data comes here -->
     </NXentry>
 }}}

   3. An application definition shall '''contain the minimum set of
 information necessary to do common processing like data analysis.'''
     * This also means that there is no space in the application definition
 for optional fields.
     * But of course, in a real NeXus data file the user is always
 permitted to add additional fields from the base classes.

   4. The original NeXus view was that a base class was just a dictionary
 of allowable terms (hence everything optional) and a definition said which
 base class terms were mandatory (with those not specified being treated as
 optional). Thus a definition did not need to add optional items as this
 was covered by the base class.

   5. Perhaps this was never written down, but may have been an implication
 that a definition could not mark a field as mandatory if it was not
 already listed in some base class as optional.

   6. A base class has a wide range of terms, some of which would make more
 sense in a particular instrument/application definition than others.
 Thus, there is some merit from the documentation point of view in having
 some optional items in a definition as ''things you might want to consider
 adding.''

-- 
Ticket URL: <http://trac.nexusformat.org/definitions/ticket/65>
NeXus Base Classes and Instrument Definitions <http://www.nexusformat.org/>
NeXus Base Classes and Instrument Definitions