diff --git a/manual/source/design.rst b/manual/source/design.rst
index 64cbdc5a90..ab472bb8c6 100644
--- a/manual/source/design.rst
+++ b/manual/source/design.rst
@@ -519,6 +519,20 @@ But there are some base classes which have special uses which need to be mention
 These groups can appear anywhere in the NeXus hierarchy, where needed. Preferably close to the component they
 annotate or in a ``NXcollection``. All of the base classes are documented in the reference manual.
 
+.. _inheritance:
+
+Inheritance in NeXus
+--------------------
+
+Single inheritance is supported in NeXus for both base classes and application definitions (which are
+described below).  Extending a base class or application definition inherits the properties and objects of the
+parent class or definition, such as groups, fields, attributes, and symbol tables. These properties and objects
+of the parent can then be overridden by the subclass.  Only single inheritance is allowed (you can only inherit
+from a single parent).
+
+Use the ``@extends`` attribute of a definition to indicate which definition is being subclassed. Base classes
+should extend from ``NXobject`` unless they are being subclassed.
+
 .. _NXdata-facilitates-TheDefaultPlot:
 
 ``NXdata`` Facilitates Automatic Plotting
@@ -645,7 +659,7 @@ Yet another way to look at a NeXus application definition is to understand it as
 between data files and the software which uses this file. Much like an interface in the Java or other modern
 object oriented programming languages.
 
-In contrast to NeXus base classes, NeXus supports inheritance in application definitions.
+Like base classes, NeXus supports :ref:`inheritance` in application definitions.
 
 Please note that a NeXus Application Definition will only define the bare minimum of data necessary to perform
 common analysis with data. Practical files will nearly always contain more data. One of the beauties of NeXus is
diff --git a/manual/source/faq.rst b/manual/source/faq.rst
index 1bd8da2895..1946cc4c29 100644
--- a/manual/source/faq.rst
+++ b/manual/source/faq.rst
@@ -232,19 +232,24 @@ This is a list of commonly asked questions concerning the NeXus data format.
    class within the definition are valid instances of
    the original class, but not vice-versa?
 
-   Keep in mind that NeXus is not specifically object oriented.
-   The putative super class might be either
-   :ref:`NXentry` (for single-technique data, such as SAXS)
-   or :ref:`NXsubentry` (for multi-technique data
-   such as SAXS/WAXS/USAXS/GIWAXS or SAXS/SANS).
-
-   If you are thinking of a new application definition that uses
-   another as a starting point (like a super class), then there
-   is an ``extends`` attribute in the definition element of the
-   NXDL file (example here from :ref:`NXarpes`)::
-
-       <definition name="NXarpes" extends="NXobject" type="group"
-
-   which describes this relationship. For most (?all?) all NXDL
-   files to date, they extend the :ref:`NXobject` base class
-   (the base object of NeXus).
+   Yes.  When writing an application definition, you can
+   add additional metadata to base classes that are not in the
+   base class definition. This essentially sub-classes the
+   original base class.
+
+   This is different than using the ``extends`` attribute, which
+   can be used to make new base classes that inherit the properties
+   of the parent classes, or new application definitions that use
+   another as a starting point. For example the
+   ``NXelectron_detector`` base class extends the ``NXdetector``
+   base class::
+
+     <definition category="base" name="NXelectron_detector" extends="NXdetector">
+
+   This is similar to how the application definition ``NXdirecttof`` extends
+   the ``NXtofraw`` application definition::
+
+     <definition category="application" name="NXdirecttof" extends="NXtofraw">
+
+   Most NXDL files extend the :ref:`NXobject` base class (the base object
+   of NeXus).