At its beginnings, the founders of NeXus identified the Hierarchical Data Format (HDF), initially from the National Center for Supercomputing Applications (NCSA) at the University of Illinois at Urbana-Champaign (UIUC) and later spun off into its own group called The HDF Group (THG),^[16] as a multi-platform data storage format with capacity for conveying large data payloads and a substantial user community. HDF (now HDF5) was provided with software to read and write data (this is the application-programmer interface, or API) using a large number of computing systems in common use for neutron and X-ray science. HDF is a binary data file format that supports compression and structured data.

NeXus data structures map directly to HDF structures. NeXus groups are HDF4 vgroups or HDF5 groups, NeXus data sets (or fields) are HDF4 SDS (scientific data sets) or HDF5 datasets. Attributes map directly to HDF group or dataset attributes.

The only special case is the NeXus class name. HDF4 supports a group class which is set with the Vsetclass() call and read with VGetclass(). HDF-5 has no group class. Thus the NeXus class is stored as an attribute to the HDF-5 group with the name NX_class and value of the NeXus class name.

A NeXus link directly maps to the HDF linking mechanisms.

Perhaps the easiest way to view the implementation of NeXus in HDF5 is to view how the data structures look. For this, we use the h5dump command-line utility provided with the HDF5 support libraries. Short examples are provided for the basic NeXus data components:

See the sections NAPI Simple 2-D Write Example (C, F77, F90) and NAPI Simple 3-D Write Example (Python) in the Examples of reading or writing NeXus data files chapter of Volume II for examples that use the native HDF5 calls to write NeXus data files.

GROUP "entry" {
  ATTRIBUTE "NX_class" {
	 DATATYPE  H5T_STRING {
		   STRSIZE 7;
		   STRPAD H5T_STR_NULLPAD;
		   CSET H5T_CSET_ASCII;
		   CTYPE H5T_C_S1;
		}
	 DATASPACE  SCALAR
	 DATA {
	 (0): "NXentry"
	 }
  }
  # ... group contents
}

 DATASET "two_theta" {
	DATATYPE  H5T_IEEE_F64LE
	DATASPACE  SIMPLE { ( 31 ) / ( 31 ) }
	DATA {
	(0): 17.9261, 17.9259, 17.9258, 17.9256, 17.9254, 17.9252,
	(6): 17.9251, 17.9249, 17.9247, 17.9246, 17.9244, 17.9243,
	(12): 17.9241, 17.9239, 17.9237, 17.9236, 17.9234, 17.9232,
	(18): 17.9231, 17.9229, 17.9228, 17.9226, 17.9224, 17.9222,
	(24): 17.9221, 17.9219, 17.9217, 17.9216, 17.9214, 17.9213,
	(30): 17.9211
	}
	ATTRIBUTE "units" {
	   DATATYPE  H5T_STRING {
			 STRSIZE 7;
			 STRPAD H5T_STR_NULLPAD;
			 CSET H5T_CSET_ASCII;
			 CTYPE H5T_C_S1;
		  }
	   DATASPACE  SCALAR
	   DATA {
	   (0): "degrees"
	   }
	}
	# ... other attributes
 }

ATTRIBUTE "axes" {
   DATATYPE  H5T_STRING {
		 STRSIZE 9;
		 STRPAD H5T_STR_NULLPAD;
		 CSET H5T_CSET_ASCII;
		 CTYPE H5T_C_S1;
	  }
   DATASPACE  SCALAR
   DATA {
   (0): "two_theta"
   }
}

# NeXus links have two parts in HDF5 files.

# The dataset is created in some group.
# A "target" attribute is added to indicate the HDF5 path to this dataset.

ATTRIBUTE "target" {
   DATATYPE  H5T_STRING {
		 STRSIZE 21;
		 STRPAD H5T_STR_NULLPAD;
		 CSET H5T_CSET_ASCII;
		 CTYPE H5T_C_S1;
	  }
   DATASPACE  SCALAR
   DATA {
   (0): "/entry/data/two_theta"
   }
}

# then, the hard link is created that refers to the original dataset
# (Since the name is "two_theta" in this example, it is understood that
# this link is created in a different HDF5 group than "/entry/data".)

DATASET "two_theta" {
   HARDLINK "/entry/data/two_theta"
}

This takes a bit more work than HDF. At the root of NeXus XML file is a XML element with the name NXroot. Further XML attributes to NXroot define the NeXus file level attributes. An example NeXus XML data file is provided in the Introduction chapter as Example Example 1.1, “verysimple.xml: A very simple NeXus Data file (in XML)”

NeXus groups are encoded into XML as elements with the name of the NeXus class and an XML attribute name which defines the NeXus name of the group. Further group attributes become XML attributes. An example:

	<NXentry name="entry">
	</NXentry>

NeXus data sets are encoded as XML elements with the name of the data. An attribute NAPItype defines the type and dimensions of the data. The actual data is stored as PCDATA^[17] in the element. Another example:

	<mode NAPItype="NX_CHAR[7]">
		monitor
	</mode>
	<counts NAPItype="NX_INT32[4]">
		21 456  127876 319
	</counts>

Data are printed in appropriate formats and in C storage order. The codes understood for NAPItype are all the NeXus data type names. The dimensions are given in square brackets as a comma separated list. No dimensions need to be given if the data is just a single value. Data attributes are represented as XML attributes. If the attribute is not a text string, then the attribute is given in the form: type:value, for example: signal="NX_INT32:1".

NeXus links are stored in XML as XML elements with the name NAPIlink and a XML attribute target which stores the path to the linked entity in the file. If the item is linked under a different name, then this name is specified as a XML attribute name to the element NAPIlink.

The authors of the NeXus API worked with the author of the miniXML XML library to create a reasonably efficient way of handling numeric data with XML. Using the NeXus API handling something like 400 detectors versus 2000 time channels in XML is not a problem. But you may hit limits with XML as the file format when data becomes to large or you try to process NeXus XML files with general XML tools. General XML tools are normally ill prepared to process large amounts of numbers.

NeXus makes use of some special attributes for its internal purposes. These attributes are stored as normal group or data set attributes in the respective file format. These are: