anchor.diff:        location="classpath:citrus/flightbooking/SmartAirlineSchema.xsd"/>
   ----
   
  -As you can see the schema repository is a simple XML component defined inside the Spring application context. The repository can hold nested schema definitions defined by some identifier and a file location for the xsd schema file. Schema definitions can also be referenced by its identifier for usage in several schema repository instances.
  -
  -By convention the default schema repository component is defined in the Citrus Spring application context with the id *schemaRepository* . Spring application context is then able to inject the schema repository into all message receiving test actions at runtime. The receiving test action consolidates the repository for a matching schema definition file in order to validate the incoming XML document structure.
  -
  -The connection between incoming XML messages and xsd schema files in the repository is done by a mapping strategy which we will discuss later in this chapter. By default Citrus picks the right schema based on the target namespace that is defined inside the schema definition. The target namespace of the schema definition has to match the namespace of the root element in the received XML message. With this mapping strategy you will not have to wire XML messages and schema files manually all is done automatically by the Citrus schema repository at runtime. All you need to do is to register all available schema definition files regardless of which target namespace or nature inside the Citrus schema repository.
  -
  -IMPORTANT: XML schema validation is mandatory in Citrus. This means that Citrus always tries to find a matching schema definition inside the schema repository in order to perform syntax validation on incoming schema qualified XML messages. A classified XML message is defined by its namespace definitions. Consequently you will get validation errors in case no matching schema definition file is found inside the schema repository. So if you explicitly do not want to validate the XML schema for some reason you have to disable the validation explicitly in your test with *schema-validation="false"* .
  +By convention there is a default schema repository component defined in the Citrus Spring application context with
  +the id *schemaRepository*. Spring application context is then able to inject the schema repository into all message
  +receiving test actions at runtime. The receiving test action consolidates the repository for a matching schema
  +definition file in order to validate the incoming XML document structure.
  +
  +The connection between incoming XML messages and xsd schema files in the repository is done by a mapping strategy which
  +we will discuss later in this chapter. By default Citrus picks the right schema based on the target namespace that is
  +defined inside the schema definition. The target namespace of the schema definition has to match the namespace of the
  +root element in the received XML message. With this mapping strategy you will not have to wire XML messages and schema
  +files manually all is done automatically by the Citrus schema repository at runtime. All you need to do is to register
  +all available schema definition files regardless of which target namespace or nature inside the Citrus schema
  +repository.
  +
  +IMPORTANT: XML schema validation is mandatory in Citrus. This means that Citrus always tries to find a matching schema
  +definition inside the schema repository in order to perform syntax validation on incoming schema qualified XML messages.
  +A classified XML message is defined by its namespace definitions. Consequently you will get validation errors in case
  +no matching schema definition file is found inside the schema repository. So if you explicitly do not want to validate
  +the XML schema for some reason you have to disable the validation explicitly in your test with
  +*schema-validation="false"*.
   
   [source,xml]
   ----
  
positive.code:     location="classpath:citrus/samples/sayHello.xsd"/>
  ----
  
  In the example above the tester explicitly sets a schema definition in the receive action (schema="helloSchema"). The attribute value refers to named schema bean somewhere in the application context. This overrules all schema mapping strategies used in the central schema repository as the given schema is directly used for validation. This feature is helpful when dealing with different schema versions at the same time where the schema repository can not help you anymore.
  
  Another possibility would be to set a custom schema repository at this point. This means you can have more than one schema repository in your Citrus project and you pick the right one by yourself in the receive action.
  
  [source,xml]
  ----
  
negative.code: [[schema-mapping-strategy]]
  ==== Schema mapping strategy
  
  The schema repository in Citrus holds one to many schema definition files and dynamically picks up the right one
  according to the validated message payload. The repository needs to have some strategy for deciding which schema
  definition to choose. See the following schema mapping strategies and decide which of them is suitable for you.
  
  [[target-namespace-mapping-strategy]]
  ==== Target Namespace Mapping Strategy
  
  This is the default schema mapping strategy. Schema definitions usually define some target namespace which is valid
  for all elements and types inside the schema file. The target namespace is also used as root namespace in XML message
  payloads. According to this information Citrus can pick up the right schema definition file in the schema repository.
  You can set the schema mapping strategy as property in the configuration files:
  
  [source,xml]
  ----
  