anchor.diff:  
   === Solution
   
  -Value retrieval for cascaded validation and validation of type-level constraints is done via the `ValueExtractor` SPI:
  +Value retrieval for cascaded validation and validation of type argument constraints is done via the `ValueExtractor` API:
   
   [source,java]
   ----
  
positive.code: 
  [[appendix-value-extraction]]
  
  == Value extraction for cascaded validation and type-level constraints (BVAL-508)
  
  This appendix describes the current work-in-progress around the retrieval of values to be validated during cascaded validation and evaluation of type-level constraints. It is based on the original http://beanvalidation.org/proposals/BVAL-508/[proposals for BVAL-508].
  
  === Motivation
  
  Value extraction is needed when constraints are applied to the element(s) stored within a container type. There are two categories:
  
  * Cascaded validation of collections, maps and arrays as triggered via `@Valid`: `@Valid List<Order> orders`; in this case all the values stored in the list must be extracted so each can be validated
  * Validation of type-level constraints as enabled by Java 8: `Optional<@Email String> email` or `Property<@Min(1) Integer> value`; in this case, e.g. the wrapped `String` and `Integer` values must be extracted so the `@Email` and `@Min` constraints can be applied
  
  Both cases can also overlap: `List<@RetailOrder @Valid> retailOrders`.
  
  Type-level constraints and pluggable extractors will also make cascaded validation more flexible. As of BV 1.1, there was a fixed set of data types supported by cascaded validation mandated by the spec (`Iterable`, arrays, `Map` (only the values would be validated)). This excludes use cases such as custom collection types (e.g. Guava's multi-map), validation of map keys or collection types of other JVM languages (such as Ceylon's collection framework).
  
  Allowing to put `@Valid` on type parameters allows to express the subject of cascaded validation more specifically: `Map<@Valid AddressType, @Valid Address> addresses` would describe that both, map keys and values, should be validated.
  
  === Requirements
  
  1. Constraints can be applied to type parameters (of bean properties, but also method parameters etc.): `Property<@Min(1) Integer> value`
  1. Individual type parameters can be marked for cascaded validation: `Map<@Valid AddressType, Address> addresses`
  1. How values are retrieved must be customizable by means of a value extractor SPI, with a set of defined default extractors
  1. Sometimes constraints should apply to a value wrapped by a container type, but there is no type parameter to put the constraints to. JavaFX's `Property` hierarchy is the most prominent example: `@Email StringProperty emailProperty`. In such case the value should be implicitly extracted from the container if unambiguously doable.
  1. OPEN: Support for validation of nested collections: `List<Map<String, @NotNull String>> addressesByType`.
  1. Allow to configure type-level constraints and cascades via XML mappings
  1. Expose meta-data on type-level constraints and cascades in the constraint metadata API
  
  === Non-requirements
  
  
negative.code: 
  ==== Retrieval of extractors
  
  When detecting a type argument constraint or cascade or a non type argument constraint that is subject to value extraction, the applicable extractor is determined as follows:
  
  * Choose the most specific extractor matching the type parameter in question; an extractor A is more specific than another extractor B if A extracts a subtype of the type extracted by B.
  * If there are several extractors which are equally specific, an `UnexpectedTypeException` is raised. TODO: apply rules similar to "ConstraintValidator resolution algorithm".
  