A concrete example of a component, a Pilatus1M detector is given by Figure 9.5. The component is built using groups (red), fields (blue), attributes (grey) and links (green). Groups contain groups, fields and links. They generate the hierarchical file structure. Groups have names, associated attributes and types like NXentry, NXinstrument or NXdetector. Fields contain data with their attributes: names, data type, shape and unit. Attributes are descriptive information for groups and fields Links refer to fields at different locations in the data tree. They are generally used to the NXdata group identifying those data fields required for easy plotting.
A hardware device is represented by a hierarchy of NeXus groups: NXentry, NXinstrument and NXdetector. The pathname is a concatenation of the group names. If NeXus files contain several scans, they have multiple entries in the NXentry level. The NXinstrument group collects all devices belonging to an experiment. Therefore, NeXus files have only one NXinstrument entry per NXentry.
Let's look at the detector from Figure 9.5 in more detail. The detector component is composed of several NeXus fields. Most of them are provided by the NXdetector class. Those fields not contained in the base class are stored in the NXcollection group. One of the NXdetector fields specifies the pixel size in x-direction. It has the NX_FLOAT64 type. Since this field contains static information, it has no data source assigned. In contrast, we see that the data field has a tag named FileDir, a string of the type NX_CHAR. The value of the string is a reference to the data source $datasources.P1M_fileDir. It is marked with the FINAL strategy tag. Therefore FileDir is resolved when the measurement ends.
Since components contain absolute path names, they can be merged to obtain the complete configuration. Figure 9.6 exemplifies the process with two components, a detector component representing a Pilatus camera and the default component containing the beamline description. The components are merged according to their group types and names. In practice, NeXus files are typically configured by 10 to 50 components.
When components are created, the data source fields are initially occupied by placeholders. The process of assigning actual references to the data sources can be considered as an instantiation of a component. The aim is to create generic components that can be used at various places.