Added clickable links for intenral references, issue WASdev#5

specification/src/main/asciidoc/batch_programming_model.adoc

@@ -1132,9 +1132,9 @@ model artifacts, then have values passed to them when a job is
 initiated. Batch properties are string values.
 
 Note batch properties are visible only in the scope in which they are
-defined (see Section 9.3.2). However batch properties values can be
+defined (see Section xref:_scope_of_property_definitions_for_batchproperty[9.3.2]). However batch properties values can be
 formed from other properties according to Job XML Substitution Rules.
-See section 8.8 for further information on substitution.
+See section xref:_job_xml_substitution[8.8] for further information on substitution.
 
 ==== @BatchProperty
 
@@ -1212,7 +1212,7 @@ corresponding property element with a matching name is specified in the
 JSL in the scope that applies to the batch artifact in question. If the
 JSL property value resolves to the empty string (either explicitly set
 to the empty string literal or resolving to an empty string via property
-substitution – see section 8.8), no assignment is made and the resulting
+substitution – see section xref:_job_xml_substitution[8.8]), no assignment is made and the resulting
 value is undefined by the batch specification. The resulting value might
 simply be the Java default value, however using various dependency
 injection technologies may produce different results. The resultant
@@ -1422,7 +1422,7 @@ See section 10.9.4 for details on the PartitionPlan result value type.
 The PartitionMapper, when defined, is invoked upon every execution,
 including restarted executions. For a full discussion of the behavior on
 restart, including how to override particular details of the
-PartitionPlan built by the previous execution, see section 10.8.5.
+PartitionPlan built by the previous execution, see section xref:_batchruntime[10.8.5].
 
 ==== PartitionReducer Interface
 
@@ -1562,7 +1562,7 @@ PartitionReducer {
 A partition collector provides a way to send data from individual
 partitions to a single point of control running on the parent thread.
 The PartitionAnalyzer is used to receive and process this data. See
-section 9.5.4 for further information about the PartitionAnalyzer. The
+section xref:_partitionanalyzer_interface[9.5.4] for further information about the PartitionAnalyzer. The
 PartitionCollector interface may be used to implement an
 PartitionCollector batch artifact:
 

specification/src/main/asciidoc/batch_runtime_spec.adoc

@@ -47,7 +47,7 @@ particular step within a job execution.
 |=======================================================================
 
 Note instanceId, executionId, and stepExecutionId are all globally
-unique values within a job repository. See section 7.4 for explanation
+unique values within a job repository. See section xref:_job_repository[7.4] for explanation
 of job repository.
 
 === JobOperator
@@ -83,7 +83,7 @@ an instance or null. +
 +
 The `batch.xml` file is packaged by the developer with the application under the '`META-INF`' directory ('`WEB-INF/classes/META-INF`' for .war files). +
 +
-See 10.7.1 for more about the `batch.xml` file.
+See xref:_job_parameters_on_restart[10.7.1] for more about the `batch.xml` file.
 
 3.  Thread Context Class Loader +
 +
@@ -110,7 +110,7 @@ from the `META-INF/batch-jobs` directory. +
 +
 Job XML documents may be packaged by the developer with the application under the '`META-INF/batch-jobs`' directory ('`WEB-INF/classes/META-INF`/batch-jobs' for .war files). +
 +
-See 10.7.2 for more about the `META-INF/batch-jobs`.
+See xref:_job_xml_substitution_during_restart[10.7.2] for more about the `META-INF/batch-jobs`.
 
 === Application Packaging Model
 The batch artifacts that comprise a batch application requiring no
@@ -123,7 +123,7 @@ method).
 
 ==== `META-INF/batch.xml`
 
-A batch application may use the archive loader (see section 10.5) to
+A batch application may use the archive loader (see section xref:_job_xml_loading[10.5]) to
 load batch artifacts. The application can direct artifact loading by
 supplying an optional `batch.xml` file. The `batch.xml` file must be stored
 under the `META-INF` directory. For .jar files it is the standard `META-INF`
@@ -149,7 +149,7 @@ batch artifact implementation.
 Notes:
 
 1. If an implementation-specific loader is used (see
-10.5) any artifact it loads takes precedence over artifacts specified in `batch.xml`.
+xref:_job_xml_loading[10.5]) any artifact it loads takes precedence over artifacts specified in `batch.xml`.
 
 2. Use of `batch.xml` to load batch artifacts requires the
 availability of a zero-argument constructor (either a default
@@ -158,7 +158,7 @@ constructor ).
 
 ==== `META-INF/batch-jobs`
 
-A batch application may use the archive loader (see section 10.6) to
+A batch application may use the archive loader (see section xref:_application_packaging_model[10.6]) to
 load Job XML documents. The application does this by storing the Job XML
 documents under the `META-INF/batch-jobs` directory. For .jar files the
 batch-jobs directory goes under the standard `META-INF` directory. For
@@ -175,7 +175,7 @@ specified on the JobOperator.start command.
 |.xml |Specifies required file type of a Job XML file under
 `META-INF/batch-jobs`.
 |=======================================================================
-Note if an implementation-specific loader (see 10.6) loads a Job XML
+Note if an implementation-specific loader (see xref:_application_packaging_model[10.6]) loads a Job XML
 document that document takes precedence over documents stored under
 `META-INF/batch-jobs`.
 
@@ -233,12 +233,12 @@ provided below.
 Upon restart, the job is processed as follows:
 
 [arabic]
-. Job XML Substitution is performed (see section 8.8).
+. Job XML Substitution is performed (see section xref:_job_xml_substitution[8.8]).
 . Start by setting the current position to the restart position. The restart position is either:
 .. the execution element identified by the <stop> elements "restart"
 attribute if that is how the previous execution ended; else
 .. the initial execution element determined the same as upon initial
-job start, as described in section 8.2.5 Step Sequence;
+job start, as described in section xref:_step_sequence[8.2.5] Step Sequence;
 . Determine if the current execution element should re-execute:
 .. If the current execution element is a COMPLETED step that specifies allow-restart-if-complete=false, then transition based on the exit status for this step from the previous completed execution. If the transition is a next transition, then repeat step 3 here with the value of next as the new, "current" execution element. Or, if the transition
 is a terminating transition such as end, stop, or fail, then terminate
@@ -254,11 +254,11 @@ exit status from the new step execution.+
 +
 Note if the step is a partitioned step, only the partitions that did not
 complete previously are restarted. This behavior may be overridden via a
-PartitionMapper (see section 10.8.5).  Note
+PartitionMapper (see section xref:_batchruntime[10.8.5]).  Note
 for a partitioned step, the checkpoints and persistent user data are
 loaded from the persistent store on a per-partition basis (this is not a
 new rule, but a fact implied by the discussion of checkpoints in section
-8.2.6 and the Step Context in section 9.4.1.1, which is summarized here
+xref:_step_partitioning[8.2.6] and the Step Context in section 9.4.1.1, which is summarized here
 for convenience).
 ..  If the current execution element is a decision, execute the decision
 (i.e. execute the Decider) unconditionally. The Deciders "decide" method
@@ -272,7 +272,7 @@ StepExecution(s) in the same array.
 execution element in the flow and perform step 3 with this as the
 current element. When restart processing of the flow has completed, then
 follow the same rules which apply during the original execution (see
-section 8.9) to transition at the flow level to the next execution
+section xref:_transitioning_rules[8.9]) to transition at the flow level to the next execution
 element, and repeat step 3 with that element as the current element. +
 +
 Note the same rules regarding transitioning within a flow during an

specification/src/main/asciidoc/domain_language.adoc

@@ -83,7 +83,7 @@ from where you left off'.
 Job parameters can be specified each time a job is started or restarted.
 Job parameters are keyword/value string pairs. The JobOperator start and
 restart operations support the specification of job parameters. See
-section 10.4 for further details on JobOperator.
+section xref:_joboperator_2[10.4] for further details on JobOperator.
 
 ==== JobExecution
 A JobExecution refers to the technical concept of a single attempt to
@@ -117,7 +117,7 @@ StepExecution will only be created when its Step is actually started.
 JobOperator provides an interface to manage all aspects of job
 processing, including operational commands, such as start, restart, and
 stop, as well as job repository related commands, such as retrieval of
-job and step executions. See section 10.4 for more details about
+job and step executions. See section xref:_joboperator_2[10.4] for more details about
 JobOperator.
 
 === Job Repository

specification/src/main/asciidoc/forward.adoc

@@ -1,2 +1,2 @@
-== Forward
+== Foreword
 This specification describes the job specification language, Java programming model, and runtime environment for batch applications for the Java platform. It is designed for use on both the Java SE and Java EE platforms. Additionally, it is designed to work with dependency injection (DI) containers without prescribing a particular DI implementation.