anchor.diff:  ----
   ====
   
  +[[appendix-valueextraction-extractorretrieval]]
   ==== Retrieval of extractors
   
   When detecting a type argument constraint or cascade, the applicable extractor is determined as follows:
   
  -* Select all those value extractors which handle a type parameter that maps to the type argument annotated with the constraint or `@Valid` annotation;
  +1. Select all those value extractors which handle a type parameter that maps to the type argument annotated with the constraint or `@Valid` annotation;
   Example:
   ** Given `List<@Email String> emails` and considering the default extractors listed above, only the extractors for `List` and `Iterable` are selected.
   The former handles the type parameter `T` of type `List`, which directly maps to the type argument annotated with `@Email`.
   The latter handles the type parameter `E` of type `Iterable` which (indirectly) maps to the annotated type argument (as `List` extends `Iterable` and binds its type parameter `T` to `E` from `Iterable`).
   Other extractors such as the ones for `K` and `V` of `Map` are dismissed, as they handle type parameters not mapping to the annotated type argument
  -* From the remaining candidate value extractors chose the one which is most specific to the container type declaring the annoted type argument.
  +** Given
  ++
  +[source,java]
  +----
  +interface ConfusingMap<K, V> extends Map<V, K> {}
  +----
  ++
  +[source,java]
  +----
  +ConfusingMap<@Email String, String> map;
  +----
  ++
  +And considering the default extractors listed above, only the extractor for the type parameter `V` of `Map` will be selected. This is because the `@Email` constraint is given for the type argument representing type parameter `K` of `ConfusingMap` which maps to type parameter `V` of `Map`.
  +
  +1. From the remaining candidate value extractors chose the one which is most specific to the container type declaring the annoted type argument.
   An extractor A is more specific than another extractor B if A extracts a subtype of the type extracted by B.
   Example:
  +** When obtaining the extractor for type parameter constraint validation, the declared type of the validated element is considered.
  +This is to be consistent with constraint validator resolution, which is based on the static type of elements, not the runtime type.
  +** When obtaining the extractor for cascaded validation, the runtime type of the cascasded element is considered.
  +This is to be consistent with the rules defined for property path construction which are based on the runtime type.
   ** From the two extractors above, the one for `List` is chosen as `List` is a subtype of `Iterable`.
  -* If there are several extractors which are equally specific (e.g. several extractors for `List`), an `UnexpectedTypeException` is raised.
  +
  +1. If there are several extractors which are equally specific (e.g. several extractors for `List`), an `UnexpectedTypeException` is raised.
   TODO: apply rules similar to "ConstraintValidator resolution algorithm" and further clarify wording
  -* When obtaining the extractor for type parameter constraint validation, the declared type of the validated element is used.
  -This is to be consistent with constraint validator resolution, which is based on the static type of elements, not the runtime type.
  -* When obtaining the extractor for cascaded validation, the runtime type of the cascasded element is used.
  -This is to be consistent with the rules defined for property path construction which are based on the runtime type.
   
   When detecting a regular element-level constraint (i.e. non type argument constraint) the applicable value extractor, if any, is determined as follows:
   
   1. If `@ConstraintsApplyTo(ANNOTATED_ELEMENT)` is given, don't apply any value extractor
   
  -1. Determine the set of uniquely mapping type parameters declared by the types in the element types type hiearchy; Examples:
  +1. Determine the set of uniquely mapping type parameters declared by the types in the element type's type hierarchy; Examples:
   ** element of type `java.lang.String`: () (empty set)
   ** element of type `java.lang.Iterable`: (T)
   ** element of type `java.lang.Map`: (K, V)
  
positive.code: private Map<String, String> emails;
  ----
  
  [source,java]
  ----
  // no type parameter
  @ConstraintsApplyTo(WRAPPED_VALUE)
  @Email
  private String email;
  ----
  
  ===== Invalid examples
  
  * No most specific extractor can be found unambiguously:
  
  [source,java]
  ----
  public interface CachedValue<V> {
      V getCachedValue();
  }
  ----
  
  [source,java]
  ----
  public interface RealValue<V> {
      V getRealValue();
  }
  ----
  
  [source,java]
  ----
  public class CachableValue<V> implements CachedValue<V>, RealValue<V> { ... }
  ----
  
  [source,java]
  ----
  public class CachedValueExtractor implements ValueExtractor<CachedValue<@ExtractedValue ?>> { ... }
  ----
  
  [source,java]
  ----
  public class RealValueExtractor implements ValueExtractor<RealValue<@ExtractedValue ?>> { ... }
  ----
  
  [source,java]
  ----
  private CachableValue<@Min(1) Integer> foo;
  ----
  
  Validation of `foo` will fail, as none of the two matching extractors is more specific than the other one.
  An extractor for `CachableValue` must be added, resolving the ambiguity.
  
  ==== XML based configuration
  
  TODO
  
negative.code: 	}
  }
  ----
  +
  [source,java]
  ----
  private Tuple<@NotNull @Email String, @NotNull @Min(1) Integer> tuple;
  ----
  
  ===== Examples for extractor retrieval
  
  * The most specific extractor matching the constrained type argument is chosen:
  +
  [source,java]
  ----
  private List<@Email String> emails;
  ----
  +
  Based on the algorithm described above and considering the mandated default extractors, only the extractor for `List` and `Iterable` are candidate extractors (all other extractors are defined for a type parameter not mapping to `T` of `List`). The extractor for `List` will be applied as it's more specific than the extractor for `Iterable` (`List` is a subtype of `Iterable`).
  
  * Constraints targeting wrapped values can be given on the wrapping element.
  Let there be these definitions:
  +
  [source,java]
  ----
  class StringWrapper {
      String wrapped;
  };
  ----
  +
  [source,java]
  ----
  @ConstraintsApplyTo(WRAPPED_VALUE)
  class StringWrapperExtractor implements ValueExtractor<@ExtractedValue StringWrapper> { ... }
  };
  ----
  +
  [source,java]
  ----
  private @Email StringWrapper email;
  ----
  +
  The `@Email` constraint will be applied to the wrapped string and can be validated as the extractor defines that element-level constraints should be applied to the wrapped value.
  +
  If the extractor were not decorated with `@ConstraintsApplyTo` an exception would be raised as there is no validator for `@Email` on `StringWrapper`.
  +
  Unwrapping could be mandated explicitly in this case:
  +
  [source,java]
  ----
  @ConstraintsApplyTo(WRAPPED_VALUE)
  