A xref test

symmetric/src/docbook/administration.xml

@@ -49,7 +49,7 @@ where source_table_name = 'price_changes';
         <para>
             SymmetricDS examines the current configuration, corresponding database triggers,
             and the underlying tables to determine if database triggers need created or updated.
-            The change activity is recorded on the <xref linkend="trigger_hist" xrefstyle="select: title page"/> table with a reason for the
+            The change activity is recorded on the <xref linkend="table_trigger_hist" xrefstyle="select: title page"/> table with a reason for the
             change.  The following reasons for a change are possible:
 
             <itemizedlist>
@@ -158,8 +158,8 @@ where source_table_name = 'price_changes';
     <section id="registration">
         <title>Opening Registration</title>
         <para>
-        Node registration is the act of setting up a new <link linkend="node">node</link> and
-         <link linkend="node_security">node security</link> so that when the new node is brought online
+        Node registration is the act of setting up a new <xref linkend="node" xrefstyle="select: title page"/> and
+         <xref linkend="node_security" xrefstyle="select: title page"/> so that when the new node is brought online
          it is allowed to join the system.  Nodes are only allowed to register if rows exist for the
          node and the registration_enabled flag is set to 1.  If the <literal>auto.registration</literal>
          SymmetricDS property is set to true, then when a node attempts to register, if registration

symmetric/src/docbook/advanced-configuration.xml

@@ -14,38 +14,40 @@
         </para>    
         <para>
         After data is captured, the first event that occurs is the routing of the 
-        captured <link linkend="data">data</link>.  Data is routed by the <emphasis>Route Job</emphasis>.  It is a single background task that inserts into
-        <link linkend="data_event">data event</link> and <link linkend="outgoing_batch">outgoing batch</link>.  The Route Job determines which <link linkend="node">nodes</link>
+        captured <xref linkend="data" xrefstyle="select: title page"/>.  Data is routed by the <emphasis>Route Job</emphasis>.  It is a single background task that inserts into
+        <xref linkend="data_event" xrefstyle="select: title page"/> and <xref linkend="outgoing_batch" xrefstyle="select: title page"/>.  The Route Job determines which nodes
         data will be sent to, as well as how much data will be batched together for transport.  When the <literal>start.route.job</literal> SymmetricDS property is set to 
         <literal>true</literal>, the frequency that routing occurs is controlled by the <literal>job.routing.period.time.ms</literal>.  Each time data is routed, the 
-        <link linkend="data_ref">data_ref</link> table is updated with the id of the last contiguous data row to have been processed.  This is done so the query to find
+        <xref linkend="data_ref" xrefstyle="select: title page"/> table is updated with the id of the last contiguous data row to have been processed.  This is done so the query to find
         unrouted data is optimal. 
         </para>
         <para>
         After data is routed, it awaits transport to the target nodes.  Transport can occur when a client node is configured to pull data or when the host node is configured to push data.  These
         events are controlled by the <emphasis>Push</emphasis> and the <emphasis>Pull Jobs</emphasis>.  When the <literal>start.pull.job</literal> SymmetricDS property is set to 
         <literal>true</literal>, the frequency that data is pulled is controlled by the <literal>job.pull.period.time.ms</literal>.  When the <literal>start.push.job</literal> SymmetricDS property is set to 
         <literal>true</literal>, the frequency that data is pushed is controlled by the <literal>job.push.period.time.ms</literal>.  Data is extracted by channel from the source database's 
-        <link linkend="data">data</link> table at an interval controlled by the <literal>extract_period_millis</literal> column on the <link linkend="channel">channel</link> table.  The <literal>last_extract_time</literal> is 
-        always recorded, by channel, on the <link linkend="node_channel_ctl">node_channel_control</link> table for the host node's id.  When the Pull and Push Job run, if the extract period
+        <xref linkend="data" xrefstyle="select: title page"/> table at an interval controlled by the <literal>extract_period_millis</literal> column on the 
+        <xref linkend="channel" xrefstyle="select: title page"/> table.  The <literal>last_extract_time</literal> is 
+        always recorded, by channel, on the <xref linkend="node_channel_control" xrefstyle="select: title page"/> table for the host node's id.  When the Pull and Push Job run, if the extract period
         has not passed according to the last extract time, then the channel will be skipped for this run.  If the <literal>extract_period_millis</literal> is set to zero, data extraction will happen every time the jobs run.
         </para>
         <para>
-        SymmetricDS also provides the ability to configure windows of time when synchronization is allowed.  This is done using the <link linkend="node_group_channel_window">node group channel window</link>
+        SymmetricDS also provides the ability to configure windows of time when synchronization is allowed.  This is done using the
+        <xref linkend="node_group_channel_window" xrefstyle="select: title page"/> 
         table.  A list of allowed time windows can be specified for a node group and a channel.  If one or more windows exist, then data will only be extracted and transported if the time
         of day falls within the window of time specified.  The configured times are always for the target node's local time.  If the <literal>start_time</literal> is greater than the <literal>end_time</literal>, then the window crosses
         over to the next day.
         </para>
         <para>
         All data loading may be disabled by setting the <literal>dataloader.enable</literal> property to false.  This has the effect of not allowing incoming synchronizations, while allowing outgoing
         synchronizations.  All data extractions may be disabled by setting the <literal>dataextractor.enable</literal> property to false.  These properties can be controlled by inserting into the 
-        root server's <link linkend="parameter">parameter</link> table.  These properties affect every channel with the exception of the 'config' channel.  
+        root server's <xref linkend="parameter" xrefstyle="select: title page"/> table.  These properties affect every channel with the exception of the 'config' channel.  
         </para>
     </section>           
     <section id="multi-tier">
         <title>Multi-Tiered Synchronization</title>
         <para>
-            As shown <link linkedn="terminology-node-organization">previously</link>, at times there may be
+            As shown <link linkend="terminology-node-organization">previously</link>, at times there may be
             scenarios where data needs to flow through multiple tiers of nodes that
             are organized in a tree-like network with each tier requiring a different subset of data.  For example,
             you may have a system where the lowest tier may by a computer or device located in a store.  Those devices 
@@ -76,13 +78,13 @@
         <para>
             When deploying a multi-tiered system it may be advantageous to have only one registration server, even though the parent node of a registering node
             could be any of a number of nodes in the system.  In SymmetricDS the parent node is always the node that a child registers with.  The 
-            <link linkend="registration_redirect">registration_redirect</link> table allows a single node, usually the root server in the network, to
+            <xref linkend="registration_redirect" xrefstyle="select: title page"/> table allows a single node, usually the root server in the network, to
             redirect registering nodes to their true parents.  It does so based on a mapping found in the table of the external id (<literal>registrant_external_id</literal>) to the parent's node 
             id (<literal>registration_node_id</literal>).
         </para>
         <para>
             For example, if it is desired to have a series of regional servers that workstations at retail stores get assigned to based on their <literal>external_id</literal>, the store number, then
-            you might insert into <link linkend="registration_redirect">registration_redirect</link> the store number as the <literal>registrant_external_id</literal> and the <literal>node_id</literal> of
+            you might insert into <xref linkend="registration_redirect" xrefstyle="select: title page"/> the store number as the <literal>registrant_external_id</literal> and the <literal>node_id</literal> of
             the assigned region as the <literal>registration_node_id</literal>.  When a workstation at the store registers, the root server send an HTTP redirect to the <literal>sync_url</literal> of the node 
             that matches the <literal>registration_node_id</literal>. 
         </para>
@@ -274,9 +276,9 @@ insert into sym_trigger_router (TRIGGER_ID,ROUTER_ID,INITIAL_LOAD_ORDER,
             ]]></programlisting>     
             To publish JMS messages during routing
             the same pattern is valid, with the exception that the extension point would be the XmlPublisherDataRouter and the router 
-            would be configured by setting the <literal>router_type</literal> of a <link linkend="router">router</link> to the Spring bean
-            name of the registered extension point.  Of course, the router would need to be linked through <link linkend="trigger_router">trigger routers</link>
-            to each <link linkend="trigger">trigger</link> table that needs published.                  
+            would be configured by setting the <literal>router_type</literal> of a <xref linkend="router" xrefstyle="select: title page"/> to the Spring bean
+            name of the registered extension point.  Of course, the router would need to be linked through <xref linkend="trigger_router" xrefstyle="select: title page"/>s
+            to each <xref linkend="trigger" xrefstyle="select: title page"/>  table that needs published.                  
         </para>
     </section>     
     <section id="purge">
@@ -287,19 +289,19 @@ insert into sym_trigger_router (TRIGGER_ID,ROUTER_ID,INITIAL_LOAD_ORDER,
             delete statements by the <emphasis>Purge Job</emphasis>.  Only data that has been successfully synchronized will be purged.  Purged tables include:
             <itemizedlist>
                 <listitem>
-                    <link linkend="data">DATA</link>
+                   <xref linkend="data" xrefstyle="select: title page"/>
                 </listitem>
                 <listitem>
-                    <link linkend="data_event">DATA_EVENT</link>
+                    <xref linkend="data_event" xrefstyle="select: title page"/>
                 </listitem>
                 <listitem>
-                    <link linkend="outgoing_batch">OUTGOING_BATCH</link>
+                  <xref linkend="outgoing_batch" xrefstyle="select: title page"/>
                 </listitem>
                 <listitem>
-                    <link linkend="incoming_batch">INCOMING_BATCH</link>
+                    <xref linkend="incoming_batch" xrefstyle="select: title page"/>
                 </listitem>
                 <listitem>
-                    <link linkend="statistic">STATISTIC</link>
+                   <xref linkend="statistic" xrefstyle="select: title page"/>
                 </listitem>                
             </itemizedlist>
             The purge job is enabled by the <literal>start.purge.job</literal> SymmetricDS property.  The job runs periodically according to the 

symmetric/src/docbook/basic-configuration.xml

@@ -12,22 +12,22 @@
         automatically (auto creation can be disabled).  Basic configuration is described by inserting into the following tables:
             <itemizedlist>
                 <listitem>
-                    <para><link linkend="node_group">Node Group</link> - specify the tiers that exist in a topology</para>
+                    <para><xref linkend="node_group" xrefstyle="select: title page"/> - specify the tiers that exist in a topology</para>
                 </listitem>
                 <listitem>
-                    <para><link linkend="node_group_link">Node Group Link</link> - two nodes groups are linked together for synchronization</para>
+                    <para><xref linkend="node_group_link" xrefstyle="select: title page"/> - two nodes groups are linked together for synchronization</para>
                 </listitem>
                 <listitem>
-                    <para><link linkend="channel">Channel</link> - grouping to control synchronizations</para>
+                    <para><xref linkend="channel" xrefstyle="select: title page"/> - grouping to control synchronizations</para>
                 </listitem>
                 <listitem>
-                    <para><link linkend="trigger">Trigger</link> - specify tables, <link linkend="channel">channels</link> and conditions for which changes in the database should be captured</para>
+                    <para><xref linkend="trigger" xrefstyle="select: title page"/> - specify tables, channels, and conditions for which changes in the database should be captured</para>
                 </listitem>
                 <listitem>
-                    <para><link linkend="router">Router</link> - specify the <link linkend="node_group_link">node group link</link> to be used for synchronization, along with other routing details</para>
+                    <para><xref linkend="router" xrefstyle="select: title page"/> - specify the <xref linkend="node_group_link" xrefstyle="select: title page"/> to be used for synchronization, along with other routing details</para>
                 </listitem>
                 <listitem>
-                    <para><link linkend="trigger_router">TriggerRouter</link> - map <link linkend="router">routers</link> to <link linkend="trigger">triggers</link></para>
+                    <para><xref linkend="trigger_router" xrefstyle="select: title page"/> - map routers triggers</para>
                 </listitem>
             </itemizedlist>
         During start up, triggers are verified against the database, and database triggers

symmetric/src/main/torque/doc/docbook/table.vm

@@ -15,7 +15,7 @@
 ## specific language governing permissions and limitations
 ## under the License.
 
-<section id="$table.Name">
+<section id="table_$table.Name">
     <title>$table.Name.toUpperCase()</title>
     <para>$table.Description</para>
 	<table id="table-def-$table.Name">