Remove References to Numbered Tables and Figures

Also added news and converted opendds_idl options from a table.

docs/building/index.rst

@@ -154,15 +154,15 @@ It requires the following libraries to be available:
 
           vcpkg install openssl:x64-windows xerces-c:x64-windows
 
-    * Configure OpenDDS by passing the openssl and xerces3 switches.
+    * Configure OpenDDS by passing the ``--openssl`` and ``--xerces3`` options.
       As a convenience, it can be helpful to set an environment variable to store the path since it is the same location for both dependencies.
 
       .. code-block:: batch
 
           set VCPKG_INSTALL=c:\path\to\vcpkg\installed\x64-windows
           configure --security --openssl=%VCPKG_INSTALL% --xerces3=%VCPKG_INSTALL%
 
-    * Compile with msbuild:
+    * Compile with ``msbuild``:
 
       .. code-block:: batch
 

docs/devguide/conditions_and_listeners.rst

@@ -18,7 +18,7 @@ Introduction
 
 The DDS specification defines two separate mechanisms for notifying applications of DCPS communication status changes.
 Most of the status types define a structure that contains information related to the change of status and can be detected by the application using conditions or listeners.
-The different status types are described in  :ref:`conditions_and_listeners--communication-status-types`.
+The different status types are described in :ref:`conditions_and_listeners--communication-status-types`.
 
 Each entity type (domain participant, topic, publisher, subscriber, data reader, and data writer) defines its own corresponding listener interface.
 Applications can implement this interface and then attach their listener implementation to the entity.

docs/devguide/content_subscription_profile.rst

@@ -70,7 +70,7 @@ This data reader is functionally equivalent to a normal data reader except that
 Filter expressions are first evaluated at the publisher so that data samples which would be ignored by the subscriber can be dropped before even getting to the transport.
 This feature can be turned off with ``-DCPSPublisherContentFilter 0`` or the equivalent setting in the ``[common]`` section of the configuration file.
 The behavior of non-default ``DEADLINE`` or ``LIVELINESS`` QoS policies may be affected by this policy.
-Special consideration must be given to how the "missing" samples impact the QoS behavior, see the document in ``docs/design/CONTENT_SUBSCRIPTION``.
+Special consideration must be given to how the "missing" samples impact the QoS behavior, see the document in :ghfile:`docs/design/CONTENT_SUBSCRIPTION`.
 
 .. note:: RTPS_UDP transport does not always do Writer-side filtering.
   It does not currently implement transport level filtering, but may be able to filter above the transport layer.
@@ -498,7 +498,7 @@ Next we have the IDL for the resulting data type:
 
 Based on this IDL, the following topic expression can be used to combine data from a topic ``Location`` which uses type ``LocationInfo`` and a topic ``FlightPlan`` which uses type ``PlanInfo``:
 
-::
+.. code-block:: sql
 
     SELECT flight_name, x, y, z AS height FROM Location NATURAL JOIN FlightPlan WHERE height < 1000 AND x <23
 

docs/devguide/dds_security.rst

@@ -337,8 +337,8 @@ Using OpenSSL Utilities for OpenDDS
 ..
     Sect<14.5.6>
 
-To generate certificates using the openssl command, a configuration file "openssl.cnf" is required (see below for example commands).
-Before proceeding, it may be helpful to review OpenSSL's manpages to get help with the file format.
+To generate certificates using the ``openssl`` command, a configuration file ``openssl.cnf`` is required (see below for example commands).
+Before proceeding, it may be helpful to review OpenSSL's man pages to get help with the file format.
 In particular, configuration file format and ca command's documentation and configuration file options.
 
 An example OpenSSL CA-Config file used in OpenDDS testing can be found here: :ghfile:`tests/security/certs/identity/identity_ca_openssl.cnf`

docs/devguide/getting_started.rst

@@ -980,8 +980,7 @@ The specification sets the default to 30 seconds.
 When the two above processes are started there may be up to a 30 second delay depending on how far apart they are started from each other.
 This time can be adjusted in OpenDDS configuration files and is discussed in :ref:`run_time_configuration--configuring-for-ddsi-rtps-discovery`.
 
-Because the architecture of OpenDDS allows for pluggable discovery and pluggable transports the two configuration entries called out in the ``rtps.ini`` file above can be changed independently with one using RTPS and the other not using RTPS (e.g.
-centralized discovery using ``DCPSInfoRepo``).
+Because the architecture of OpenDDS allows for pluggable discovery and pluggable transports the two configuration entries called out in the ``rtps.ini`` file above can be changed independently with one using RTPS and the other not using RTPS (e.g. centralized discovery using ``DCPSInfoRepo``).
 Setting them both to RTPS in our example makes this application fully interoperable with other non-OpenDDS implementations.
 
 .. _getting_started--data-handling-optimizations:

docs/devguide/internet_enabled_rtps.rst

@@ -77,7 +77,7 @@ Using the RtpsRelay
     Sect<15.2.1>
 
 Support for the RtpsRelay is activated via configuration.
-See :ref:`Table 7-5 RTPS Discovery Configuration Options <run_time_configuration--reftable12>` and :ref:`Table 7-17 RTPS_UDP Configuration Options <run_time_configuration--reftable24>`.
+See :ref:`RTPS Discovery Configuration Options <run_time_configuration--rtps-disc-config-options>` and :ref:`RTPS_UDP Configuration Options <run_time_configuration--reftable24>`.
 As an example:
 
 .. code-block:: ini
@@ -312,13 +312,13 @@ For OpenDDS, ICE can be used to potentially establish connectivity between SPDP
 SPDP is used as the side channel for SEDP and SEDP is used as the side channel for the ordinary RTPS endpoints.
 To this, we added two parameters to the RTPS protocol for sending general ICE information and ICE candidates and added the ability to execute the ICE protocol and process STUN messages to the RTPS transports.
 
-ICE is defined in `IETF RFC 8445 <https://www.rfc-editor.org/info/rfc8445>`__.
-ICE utilizes the STUN protocol that is defined in `IETF RFC 5389 <https://www.rfc-editor.org/info/rfc5389>`__.
+ICE is defined in :rfc:`8445`.
+ICE utilizes the STUN protocol that is defined in :rfc:`5389`.
 The ICE implementation in OpenDDS does not use TURN servers.
 
 ICE is enabled through configuration.
 The minimum configuration involves setting the ``UseIce`` flag and providing addresses for the STUN servers.
-See :ref:`Table 7-5 RTPS Discovery Configuration Options <run_time_configuration--reftable12>` and :ref:`Table 7-17 RTPS_UDP Configuration Options <run_time_configuration--reftable24>` for details.
+See :ref:`RTPS Discovery Configuration Options <run_time_configuration--rtps-disc-config-options>` and :ref:`RTPS_UDP Configuration Options <run_time_configuration--reftable24>` for details.
 
 .. code-block:: ini
 
@@ -395,18 +395,18 @@ OpenDDS includes the following features for mitigation:
 * Compare the source IP of the SPDP message to the locators.
   For most applications, the locators advertised by SPDP should match the source IP of the SPDP message.
 
-  * See CheckSourceIp in :ref:`Table 7-5 RTPS Discovery Configuration Options <run_time_configuration--reftable12>`
+  * See ``CheckSourceIp`` in :ref:`RTPS Discovery Configuration Options <run_time_configuration--rtps-disc-config-options>`
 
 * Use the participant lease time from secure discovery and bound it otherwise.
   By default, OpenDDS will attempt authentication for the participant lease duration specified in the SPDP message.
   However, this data can't be trusted so a smaller maximum lease time can be specified to force authentication or discovery to terminate before the lease time.
 
-  * See MaxAuthTime in :ref:`Table 7-5 RTPS Discovery Configuration Options <run_time_configuration--reftable12>`
+  * See ``MaxAuthTime`` in :ref:`RTPS Discovery Configuration Options <run_time_configuration--rtps-disc-config-options>`
 
 * Limit the number of outstanding secure discoveries.
   The number of discovered but not-yet-authenticated participants is capped when using secure discovery.
 
-  * See MaxParticipantsInAuthentication in :ref:`Table 7-5 RTPS Discovery Configuration Options <run_time_configuration--reftable12>`
+  * See ``MaxParticipantsInAuthentication`` in :ref:`RTPS Discovery Configuration Options <run_time_configuration--rtps-disc-config-options>`
 
 .. _internet_enabled_rtps--run-participants-in-a-secure-network:
 

docs/devguide/introduction.rst

@@ -233,14 +233,13 @@ Basic Concepts
 ..
     Sect<1.1.1>
 
-:ref:`Figure 1-1 <introduction--reffigure0>` shows an overview of the DDS DCPS layer.
-The following subsections define the concepts shown in this diagram.
+This is an overview of the DDS DCPS layer:
 
-.. _introduction--reffigure0:
+.. figure:: images/10000001000001C100000202637D36545E22157D.png
 
-**Figure  DCPS Conceptual Overview**
+  DCPS Conceptual Overview
 
-.. image:: images/10000001000001C100000202637D36545E22157D.png
+The following subsections define the concepts shown in the diagram.
 
 .. _introduction--domain:
 
@@ -336,7 +335,7 @@ Dynamic data readers are also type-safe, but type checking happens at runtime.
 
 .. _introduction--built-in-topics:
 
-Built-In Topics
+Built-in Topics
 ===============
 
 ..
@@ -348,11 +347,7 @@ While subscribed, the application receives samples indicating changes in the ent
 
 The following table shows the built-in topics defined within the DDS specification:
 
-.. _introduction--reftable0:
-
-**Table  Built-in Topics**
-
-.. list-table::
+.. list-table:: Built-in Topics
    :header-rows: 1
 
    * - Topic Name
@@ -630,15 +625,14 @@ Extensible Transport Framework (ETF)
 OpenDDS uses the IDL interfaces defined by the DDS specification to initialize and control service usage.
 Data transmission is accomplished via an OpenDDS-specific transport framework that allows the service to be used with a variety of transport protocols.
 This is referred to as *pluggable transports* and makes the extensibility of OpenDDS an important part of its architecture.
-OpenDDS currently supports TCP/IP, UDP/IP, IP multicast, shared-memory, and RTPS_UDP transport protocols as shown in :ref:`Figure 1-2 <introduction--reffigure1>`.
-Transports are typically specified via configuration files and are attached to various entities in the publisher and subscriber processes.
-See :ref:`run_time_configuration--transport-configuration-options` for details on configuring ETF components.
+OpenDDS currently supports TCP/IP, UDP/IP, IP multicast, shared-memory, and RTPS_UDP transport protocols as shown below.
 
-.. _introduction--reffigure1:
+.. figure:: images/10000001000002E50000018D97FADEED4445DDBB.png
 
-.. image:: images/10000001000002E50000018D97FADEED4445DDBB.png
+  OpenDDS Transport Framework
 
-**Figure  OpenDDS Extensible Transport Framework**
+Transports are typically specified via configuration files and are attached to various entities in the publisher and subscriber processes.
+See :ref:`run_time_configuration--transport-configuration-options` for details on configuring ETF components.
 
 The ETF enables application developers to implement their own customized transports.
 Implementing a custom transport involves specializing a number of classes defined in the transport framework.
@@ -681,11 +675,9 @@ The DCPSInfoRepo process needs to be running whenever OpenDDS is being used in a
 An RTPS configuration does not use the DCPSInfoRepo.
 The DCPSInfoRepo is not involved in data propagation, its role is limited in scope to OpenDDS applications discovering one another.
 
-.. _introduction--reffigure2:
-
-.. image:: images/100000010000045A0000025185A3A43482F62E3D.png
+.. figure:: images/100000010000045A0000025185A3A43482F62E3D.png
 
-**Figure : Centralized Discovery with OpenDDS InfoRepo**
+   Centralized Discovery with DCPSInfoRepo
 
 Application developers are free to run multiple information repositories with each managing their own non-overlapping sets of DCPS domains.
 
@@ -704,16 +696,15 @@ Peer-to-Peer Discovery with RTPS
 
 DDS applications requiring a Peer-to-Peer discovery pattern can be accommodated by OpenDDS capabilities.
 This style of discovery is accomplished only through the use of the RTPS protocol as of the current release.
-This simple form of discovery is accomplished through simple configuration of DDS application data readers and data writers running in application processes as shown in :ref:`Figure 1-4 <introduction--reffigure3>`.
-As each participating process activates the DDSI-RTPS discovery mechanisms in OpenDDS for their data readers and writers, network endpoints are created with either default or configured network ports such that DDS participants can begin advertising the availability of their data readers and data writers.
-After a period of time, those seeking one another based on criteria will find each other and establish a connection based on the configured pluggable transport as discussed in Extensible Transport Framework (ETF).
-A more detailed description of this flexible configuration approach is discussed in :ref:`run_time_configuration--transport-concepts` and :ref:`run_time_configuration--rtps-udp-transport-configuration-options`.
+This simple form of discovery is accomplished through simple configuration of DDS application data readers and data writers running in application processes as shown below.
 
-.. _introduction--reffigure3:
+.. figure:: images/10000001000003FC0000025E8CF71A4C4FCDEFF3.png
 
-.. image:: images/10000001000003FC0000025E8CF71A4C4FCDEFF3.png
+  Peer-to-peer Discovery with RTPS
 
-**Figure : Peer-to-peer Discovery with RTPS**
+As each participating process activates the DDSI-RTPS discovery mechanisms in OpenDDS for their data readers and writers, network endpoints are created with either default or configured network ports such that DDS participants can begin advertising the availability of their data readers and data writers.
+After a period of time, those seeking one another based on criteria will find each other and establish a connection using a transport.
+A more detailed description of this flexible configuration approach is discussed in :ref:`run_time_configuration--transport-concepts` and :ref:`run_time_configuration--rtps-udp-transport-configuration-options`.
 
 The following are additional implementation limits that developers need to take into consideration when developing and deploying applications that use RTPS discovery:
 
@@ -851,11 +842,7 @@ This profile adds the classes ``ContentFilteredTopic``, ``QueryCondition``, and
 
 In addition, individual classes can be excluded by using the features given in the table below.
 
-.. _introduction--reftable1:
-
-**Table : Content-Subscription Class Features**
-
-.. list-table::
+.. list-table:: Content-Subscription Class Features
    :header-rows: 1
 
    * - Class

docs/devguide/java_bindings.rst

@@ -50,11 +50,7 @@ Below is a description of the generated files and which tools generate them.
 In this example, ``Foo.idl`` contains a single struct ``Bar`` contained in module ``Baz`` (IDL modules are similar to C++ namespaces and Java packages).
 To the right of each file name is the name of the tool that generates it, followed by some notes on its purpose.
 
-.. _java_bindings--reftable34:
-
-**Table  Generated files descriptions**
-
-.. list-table::
+.. list-table:: Generated files descriptions
    :header-rows: 1
 
    * - File

docs/devguide/modeling_sdk.rst

@@ -35,23 +35,19 @@ This diagram includes any package structures to be included in the model along w
 Zero or more of the policy or data definition elements can be included.
 Zero or one DCPS elements definition can be included in any given model.
 
-.. _modeling_sdk--reffigure5:
+.. figure:: images/10000001000003BA000005345220EFBC3B2965C5.png
+  :scale: 50%
 
-.. image:: images/10000001000003BA000005345220EFBC3B2965C5.png
-   :scale: 50%
-
-**Figure  Graphical modeling of the data definitions**
+  Graphical modeling of the data definitions
 
 Creating separate models for QoS policies only, data definitions only, or DCPS elements only is supported.
 References to other models allows externally defined models to be included in a model.
 This allows sharing of data definitions and QoS policies among different DCPS models as well as including externally defined data in a new set of data definitions.
 
-.. _modeling_sdk--reffigure6:
-
-.. image:: images/10000001000003CA00000534AF32FC1EC2AA656B.png
-   :scale: 50%
+.. figure:: images/10000001000003CA00000534AF32FC1EC2AA656B.png
+  :scale: 50%
 
-**Figure  Graphical modeling of the DCPS entities**
+  Graphical modeling of the DCPS entities
 
 .. _modeling_sdk--code-generation:
 
@@ -116,12 +112,10 @@ Installation
 ..
     Sect<11.2.2>
 
-.. _modeling_sdk--reffigure7:
-
-.. image:: images/100000000000018A000001582B13D316CA761B88.png
-   :scale: 150%
+.. figure:: images/100000000000018A000001582B13D316CA761B88.png
+  :scale: 150%
 
-**Figure  Eclipse Software Installation Dialog**
+  Eclipse Software Installation Dialog
 
 #. From Eclipse, open the "Help" menu and select "Install New Software".
 
@@ -235,13 +229,9 @@ Generated Code
     Sect<11.3.2>
 
 The OpenDDS Modeling SDK generates model-specific code for use by an OpenDDS Modeling SDK application.
-Starting with a .codegen file (which refers to an ``.opendds`` model file), the files described in :ref:`Table 11-1 <modeling_sdk--reftable35>`.
+Starting with a .codegen file (which refers to an ``.opendds`` model file), the files described in the table below.
 The process of generating code is documented in the Eclipse help.
 
-.. _modeling_sdk--reftable35:
-
-**Table  Generated Files**
-
 .. list-table::
    :header-rows: 1