fix x-refs

Author: rosemarymarano

documentation/1.9/content/_index.md

@@ -18,8 +18,8 @@ See the [Release Notes]({{< relref "/release-notes.md" >}}) for recent changes,
 
 This documentation includes sections targeted to different audiences. To help you find what you are looking for more easily, please consult this table of contents:
 
-* [Concepts]({{< relref "/concepts/" >}}) explains the underlying metadata model, files, and configurations.
-* The [User guide]({{< relref "/userguide/" >}}) contains detailed usage information, including how to install and configure WebLogic Deploy Tooling, and how to use the tools to .
+* [Concepts]({{< relref "/concepts/" >}}) explains the underlying metadata model, files, and configurations...
+* The [User guide]({{< relref "/userguide/" >}}) contains detailed usage information, including how to install and configure WebLogic Deploy Tooling, and how to use each tool.
 * The [Samples]({{< relref "/samples/" >}}) provide detailed example code and instructions that show you how to perform various tasks.
 * The [Developer guide]({{< relref "/developer/" >}}) provides details for people who want to understand how WDT is built, tested, and so on.
 

documentation/1.9/content/concepts/archive.md

@@ -10,6 +10,8 @@ The archive file is used to deploy binaries and other file resources to the targ
 
 Note that file resources that already exist on the target system need not be included in the archive, provided that the model specifies the correct location on the target system.
 
+### Contents
+
 - [Example](#example)
 - [Archive Structure](#archive-structure)
 - [Using Multiple Archive Files](#using-multiple-archive-files)

documentation/1.9/content/concepts/model.md

@@ -31,7 +31,7 @@ The model is written in YAML (or optionally, JSON).  The YAML parser, built into
 
 All assignment statements must have one or more spaces between the colon and the value.  All comments must have a space after the pound sign (also known as hash) to be considered a comment.  YAML doesn't allow comments in all locations.  While the YAML parser used by the framework does not try to enforce these restrictions, it is likely that putting comments in some locations may cause parse errors since YAML is a difficult language to parse due to its complex indention rules.
 
-#### Contents
+### Contents
 
 - [Top-Level Sections](#top-level-model-sections)
 - [Simple Example](#simple-example)
@@ -50,7 +50,7 @@ The tooling has five top-level model sections:
 - `appDeployments` - The location where shared libraries and applications are specified.
 - `kubernetes`     - The location where the WLS Kubernetes Operator domain configuration is specified.
 
-### Simple Example
+#### Simple Example
 Here is a simple example of a model to deploy an application and its data source:
 
 ```yaml
@@ -89,7 +89,7 @@ The above example shows two important features of the framework.  First, notice
 
 Second, notice that the `jsf#2.0` shared library `SourcePath` attribute value starts with `@@WL_HOME@@`. This is a path token that can be used to specify that the location is relative to the location of the WebLogic Server home directory on the target environment.  See [Model Tokens](#model-tokens) for more information and a list of available path tokens.
 
-The example above shows the attribute `SourcePath` of the `simpleear` application with a value of `wlsdeploy/applications/simpleear.ear`.  The prefix `wlsdeploy/` indicates that the resource is located in the archive file in the specified location, and will be deployed to that directory within the domain, in this case `<domain-home>/wlsdeploy/applications/simpleear.ear`. See [The Archive File](archive.md) for more details about using the archive file.
+The example above shows the attribute `SourcePath` of the `simpleear` application with a value of `wlsdeploy/applications/simpleear.ear`.  The prefix `wlsdeploy/` indicates that the resource is located in the archive file in the specified location, and will be deployed to that directory within the domain, in this case `<domain-home>/wlsdeploy/applications/simpleear.ear`. See [The Archive File]({{< relref "/concepts/archive.md" >}}) for more details about using the archive file.
 
 Users can create further directory structures underneath the above locations to organize the files and directories as they see fit.  Note that any binary that already exists on the target system need not be included in the archive provided that the model specified the correct location on the target system.
 
@@ -254,7 +254,7 @@ This feature can also remove items that were created by WebLogic Server template
                 ...
 ```
 
-This feature does not apply to named security providers within a realm. These items follow a special set of rules that are required to maintain their ordering. See [Modeling Security Providers](use_cases.md#modeling-security-providers) for detailed information.
+This feature does not apply to named security providers within a realm. These items follow a special set of rules that are required to maintain their ordering. See [Modeling Security Providers]({{< relref "/concepts/use_cases#modeling-security-providers" >}}) for detailed information.
 
 This feature cannot be use to un-deploy applications or remove libraries.
 

documentation/1.9/content/concepts/target_env.md

@@ -6,11 +6,11 @@ weight: 5
 ---
 
 
-The [Discover Domain]({{< relref "/discover.md" >}}) and [Prepare Model]({{< relref "/prepare.md" >}}) Tools allow you to customize the model and other files produced to be compatible with a specific target environment. Options for a target environment may include:
-- Using model tokens for some attributes in the model (see [Model Tokens]({{< relref "/model#model-tokens" >}}))
-- Using Kubernetes secrets for credentials in the model
-- Applying filters to the model (see [Model Filters]({{< relref "/tool_configuration#model-filters" >}}))
-- Creating additional configuration files for the target system
+The [Discover Domain]({{< relref "/userguide/tools/discover.md" >}}) and [Prepare Model]({{< relref "/userguide/tools/prepare.md" >}}) Tools allow you to customize the model and other files produced to be compatible with a specific target environment. Options for a target environment may include:
+- Using model tokens for some attributes in the model. See [Model Tokens]({{< relref "/concepts/model#model-tokens" >}}).
+- Using Kubernetes secrets for credentials in the model.
+- Applying filters to the model. See [Model Filters]({{< relref "/concepts/tool_configuration#model-filters" >}}).
+- Creating additional configuration files for the target system.
 
 ### Specifying a target environment
 
@@ -31,10 +31,10 @@ A target environment is configured in a JSON file at this location:
 $WLSDEPLOY_HOME/lib/target/<target-name>/target.json
 ```
 The `<target-name>` value corresponds to the value of the `-target` argument on the tool's command line. The WLS installation includes two pre-defined targets:
- - [Oracle Weblogic Server Kubernetes Operator](#the-oracle-weblogic-server-kubernetes-operator-target) (named `k8s`)
+ - [Weblogic Kubernetes Operator](#the-weblogic-kubernetes-operator-target) (named `k8s`)
  - [Verrazzano](#the-verrazzano-target) (named `vz`).
 
-You can define a new or extended target environment with a new `target-name` in the above location, or using a [Custom Configuration](../tool_configuration.md#custom-configuration) directory, such as `$WDT_CUSTOM_CONFIG/target/<my-target-name>/target.json`.
+You can define a new or extended target environment with a new `target-name` in the above location, or using a [Custom Configuration]({{< relref "/concepts/tool_configuration#custom-configuration" >}}) directory, such as `$WDT_CUSTOM_CONFIG/target/<my-target-name>/target.json`.
 
 Here is an example of a target environment file:
 ```
@@ -55,13 +55,13 @@ Each of the fields in this example is optional, and can be customized.
 
 #### `model_filters`
 
-This field specifies the filters to be applied to the resulting model. This follows the same format and rules as the [Model Filters](../tool_configuration.md#model-filters) configuration. The `discover` type should always be used here.
+This field specifies the filters to be applied to the resulting model. This follows the same format and rules as the [Model Filters]({{< relref "/concepts/tool_configuration#model-filters" >}}) configuration. The `discover` type should always be used here.
 
 The `@@TARGET_CONFIG_DIR@@` token can be used to indicate that the specified filter is in the same directory as the target configuration file.  
 
 #### `variable_injectors`
 
-This field specifies the variable injectors to be applied to the resulting model. This follows the same format and rules as the [Variable Injectors](../variable_injection.md) configuration.
+This field specifies the variable injectors to be applied to the resulting model. This follows the same format and rules as the [Variable Injectors]({{< relref "/userguide/tools/variable_injection.md" >}}) configuration.
 
 #### `validation_method`
 
@@ -77,7 +77,7 @@ In both these cases, the script to create the Kubernetes secrets is written to `
 
 #### `wls_credentials_name`
 
-This field specifies a name for use with the WDT_MODEL_SECRETS_NAME_DIR_PAIRS environment variable to identify administration credential Secrets for the domain. This is useful when those Secrets are stored in a directory that does not follow the `<directory>/<name>/<key>` convention. For more information about using the WDT_MODEL_SECRETS_NAME_DIR_PAIRS environment variable, see [Model Tokens](../model.md#model-tokens).
+This field specifies a name for use with the WDT_MODEL_SECRETS_NAME_DIR_PAIRS environment variable to identify administration credential Secrets for the domain. This is useful when those Secrets are stored in a directory that does not follow the `<directory>/<name>/<key>` convention. For more information about using the WDT_MODEL_SECRETS_NAME_DIR_PAIRS environment variable, see [Model Tokens]({{< relref "/concepts/model#model-tokens" >}}).
 
 #### `additional_output`
 

documentation/1.9/content/concepts/tool_configuration.md

@@ -9,9 +9,9 @@ weight: 4
 #### Contents
  - [Tool Property File](#tool-property-file)
  - [Model Filters](#model-filters)
- - [Target Environments](config/target_env.md)
+ - [Target Environments]({{< relref "/concepts/target_env.md" >}})
  - [Type Definitions](#domain-type-definitions)
- - [Variable Injection](variable_injection.md)
+ - [Variable Injection]({{< relref "/userguide/tools/variable_injection.md" >}})
  - [Custom Configuration](#custom-configuration)
 
  ### Tool Property File
@@ -266,8 +266,8 @@ def filter_model(model):
  - [Tool Property File](#tool-property-file)
  - [Model Filters](#model-filters)
  - [Type Definitions](#domain-type-definitions) (See the [example](#example-extending-a-type-definition) below.)
- - [Variable Injection](variable_injection.md)
- - [The Prepare Model Tool](prepare.md) (target environments)
+ - [Variable Injection]({{< relref "/userguide/tools/variable_injection.md" >}})
+ - [The Prepare Model Tool]({{< relref "/userguide/tools/prepare.md" >}}) (target environments)
 
  The WDT tools will look for each configuration file under `$WDT_CUSTOM_CONFIG` if specified, then under `$WLSDEPLOY_HOME/lib`.