diff --git a/base_classes/NXsubentry.nxdl.xml b/base_classes/NXsubentry.nxdl.xml
index 5f45a76da3..3399bc54e5 100644
--- a/base_classes/NXsubentry.nxdl.xml
+++ b/base_classes/NXsubentry.nxdl.xml
@@ -52,27 +52,40 @@
 	</attribute>
 	
 	<doc>
-		Group of multiple application definitions for "multi-modal" (e.g. SAXS/WAXS) measurements.
+		Group to enable the combination of multiple application definitions for "multi-modal"
+		measurements (e.g. multi-technique methods like SAXS/WAXS).
 		
 		``NXsubentry`` is a base class virtually identical to :ref:`NXentry`
 		and is used as the (overlay) location for application definitions.
-		Use a separate ``NXsubentry`` for each application definition. 
+		Use a separate ``NXsubentry`` for each application definition.
+
+		To illustrate, consider the normal way to define a NeXus file::
+
+		  NXentry
+		    definition = name of application definition
+		    # all the structure of the application definition
+		    # Note, no use of NXsubentry
+
+		With NXsubentry, one can combine application definitions within a single NXentry::
 		
-		To use ``NXsubentry`` with a hypothetical application definition 
-		called ``NXmyappdef``:
+		  NXentry
+		    # no definition field required here
+		    NXsubentry
+		      definition = name of application definition
+		      # all the structure of the application definition
+		    NXsubentry
+		      definition = name of a second application definition
+		      # all the structure of the second application definition
+
+		Notes:
 
-		* Create a group with attribute ``NX_class="NXsubentry"``
-		* Within that group, create a field called ``definition="NXmyappdef"``.
 		* There are two optional attributes of definition: ``version`` and ``URL``
+		* Groups like NXinstrument can be included outside of NXsubentry under NXentry
+		  allowing them to be cited in mulitple NXsubentries
+		* An NXsubentry should not contain another NXsubentry
 
-		The intended use is to define application definitions for a 
-		multi-modal (a.k.a. multi-technique) :ref:`NXentry`. 
-		Previously, an application definition 
-		replaced :ref:`NXentry` with its own definition. 
-		With the increasing popularity of instruments combining 
-		multiple techniques for data collection (such as SAXS/WAXS instruments), 
-		it was recognized the application definitions must be entered in the NeXus
-		data file tree as children of :ref:`NXentry`. 
+		See rules for :ref:`NXsubentry or Multi-Method Data &lt;rules-subentry&gt;` for a
+		more in depth example.
 	</doc>
 	
 	<attribute name="IDF_Version">
diff --git a/manual/source/examples/hierarchy-subentry.txt b/manual/source/examples/hierarchy-subentry.txt
index a963678c47..2b53c3ea71 100644
--- a/manual/source/examples/hierarchy-subentry.txt
+++ b/manual/source/examples/hierarchy-subentry.txt
@@ -12,17 +12,18 @@
 		SAS:NXsubentry
 			definition = "NXsas"
 			instrument:NXinstrument
-				detector:NXdetector
-					data --> /entry/instrument/SASdet/data
+				detector -> entry/instrument/SASdet
 			data:NXdata
 				data --> /entry/instrument/SASdet/data
+			sample --> /entry/sample
 		Fluo:NXsubentry
 			definition = "NXfluo"
 			instrument:NXinstrument
-				detector --> /entry/instrument/fluordet/data
-				detector2 --> /entry/instrument/large_area/data
+				detector --> /entry/instrument/fluordet
+				detector2 --> /entry/instrument/large_area
 			data:NXdata
 				@signal = detector
 				@axes = [".", "."]
 				detector --> /entry/instrument/fluordet/data
+			sample --> /entry/sample
 		data:NXdata --> /entry/Fluo/data