dead link fixed in spec_initialValuePropagation.dox.

doc/spec_initialValuePropagation.dox

@@ -52,7 +52,7 @@ This specification goes beyond ApplicationCore. It has impact on other ChimeraTK
   1. Initial values can be written in `ApplicationModule::prepare()`, if the value does not depend on any input values (since input values are not available during `prepare()`). [ \ref testD7_1_InitialValue "T"]
   2. Alternatively, initial values can be written in `ApplicationModule::mainLoop()` before calling any `read` function, if they depend on initial values of the inputs. Typically, to propagate the initial values of its inputs, an `ApplicationModule` will run its computations and write its outputs first before waiting for new data with a blocking `read()` and the end of the processing loop. The application author needs to take into account that the `ApplicationModule::mainLoop()` will only start after all inputs have their initial values available, which might depend on the avaialbility of devices. [ \ref testD7_2_InitialValue "T"]
   3. Since in `ApplicationModule::prepare()` all devices are still closed, any writes to device variables at this point need to be delayed until the device is open. As the ExceptionHandlingDecorator takes care of this, the appciation module can just call write() on its output and does not have to do any special actions here (see \ref b_2_3 "Technical specification: Exception handling for device runtime errors B.2.3").
-8. \anchor InitialValuesInputsOfApplicationCore_D_8 Inputs of `ApplicationModule`s [\ref testInitialValuesInputsOfApplicationCore "T"]:
+8. \anchor InitialValuesInputsOfApplicationCore_D_8 Inputs of `ApplicationModule`s:
   1. Initial values are read by the framwork before the start of `ApplicationModule::mainLoop()` (but already in the same thread which later executes the `mainLoop()`).
   2. Initial values are read by calling `TransferElement::read()`, which *freezes* until the initial value has arrived, both with `AccessMode::wait_for_new_data` and without.
     1. \anchor initialValue_D_8_b_i For device variables the ExeptionHandlingDecorator freezes the variable until the device is available. [ \ref testInitialValue_D_8_b_i "T"]
@@ -62,7 +62,7 @@ This specification goes beyond ApplicationCore. It has impact on other ChimeraTK
   1. The fan outs have a transparent behaviour, i.e. an entity that receives an initial value through a fan out sees the same behaviour as if a direct connection would have been realised.
   2. \anchor initialValueThreaddedFanOut_D_9_b This implies that the inputs are treated like described in 8.b. [ \ref testInitialValueThreaddedFanOut_D_9_b "T for ThreadedFanOut"] [ \ref testInitialValueTriggerFanOut_D_9_b "T for TriggerFanOut"]
   3. \anchor initialValue_d_9_3 The initial value is propagated immediately to the outputs.  \ref initialValue_comment_d_9_3 "(*)"
-10. \anchor initialValue_d_10 Constants (`Application::makeConstant()`): [ \ref constantD10InitialValue_D_10 "T"]
+10. \anchor initialValue_d_10 Constants (`Application::makeConstant()`): [ \ref testConstantD10InitialValue_D_10 "T"]
   1. Constant accessors only have one value, which is propagates as the intitial value. They conceptually behave like a process array that is written exactly once by the framework.
     1. This implies that in case of `AccessMode::wait_for_new_data` the value can be read exactly once. This is enough to propagate the initial value. Any further read() to the variable will block infinitely.
   2. Values are propagated before the `ApplicationModule` threads are starting (just like initial values written in `ApplicationModule::prepare()`)