anchor.diff:  }
   ----
   
  -The `@ExtractedValue` annotation must be specified exactly once for a value extractor type. Thus the following extractor definition is illegal as it specifies `@ExtractedValue` several times:
  +The `@ExtractedValue` annotation must be specified exactly once for a value extractor type.
  +Thus the following extractor definition is illegal as it specifies `@ExtractedValue` several times:
   
   [source,java]
   ----
   public class DoubleExtractor implements ValueExtractor<Multimap<@ExtractedValue ?, @ExtractedValue ?>> { ... }
   ----
   
  -When defined for a generic type, only wildcard type arguments may be annotated with `@ExtractedValue`. I.e. the following extractor definition is illegal:
  +When defined for a generic type, only wildcard type arguments may be annotated with `@ExtractedValue`.
  +I.e. the following extractor definition is illegal:
   
   [source,java]
   ----
  
positive.code: [NOTE]
  .Motivation for callback-style API
  ====
  Instead of returning the extracted values from the method call, implementations of `ValueExtractor` pass the extracted values to the given receiver callback. This helps to avoid object allocations and allows to handle the case of a single extracted value (`Optional<T>`) and multiple extracted values (`List<T>`) in a uniform fashion.
  ====
  
  ==== Default extractors
  
negative.code: 
  === Open questions
  
  * `ConstraintsApplyTo` only allows one behavior per annotated element. Should it be per constraint?
  E.g. for `@NotNull @Email StringProperty email` it may be desirable to apply `@NotNull` to the wrapper but `@Email` to the wrapped value. That's not possible currently.
  * Should a path node be added for type argument constraints of `Optional` and similar types?
  This proposal suggests to not do it, but Emmanuel is not convinced of this.
  * Should type argument constraints be validated when the container is null?
  * Should value extractors be discoverable via the service loader mechanism (i.e. by means of `META-INF/services/javax.validation.valueextraction.ValueExtractor` files)
  * What to return from `PropertyDescriptor#getElementClass()` if there is a field of type `Foo` but a getter of type `Optional<Foo>`.
  So far, BV assumed the types of field and getter to be the same and exposed a single property descriptor (which btw. also may fall apart as of BV 1.1 when the field is of a sub-type of the getter's type).
  What to return here?
  * Should the presence of type argument constraints alone trigger cascaded validation?
  It doesn't seem right, but it may be useful when e.g. considering the case of `Tuple` above.
  * Should we allow extractors to be defined for specific parameterizations of generic types, e.g.
  
  [source,java]
  