Doc fixes

FU/Validate.pm

@@ -419,15 +419,15 @@ parameters within Perl code. In fact, the correct answer to "how do I validate
 function parameters?" is "don't, document your assumptions instead".
 
 
-=head2 Validation API
+=head1 Validation API
 
 To validate some input, you first need a schema. A schema can be compiled as
 follows:
 
   my $validator = FU::Validate->compile($schema, $validations);
 
-C<$schema> is the schema that describes the data to be validated (see L</SCHEMA
-DEFINITION> below) and C<$validations> is an optional hashref containing
+C<$schema> is the schema that describes the data to be validated (see L</Schema
+Definition> below) and C<$validations> is an optional hashref containing
 L<custom validations|/Custom validations> that C<$schema> can refer to.  An
 error is thrown if the C<$validations> or C<$schema> are invalid.
 
@@ -443,10 +443,10 @@ An error is thrown if the input does not validate. The error object is a
 C<FU::Validate::err>-blessed hashref containing at least one key:
 I<validation>, which indicates the name of the validation that failed.
 Additional keys with more detailed information may be present, depending on the
-validation. These are documented in L</SCHEMA DEFINITION> below.
+validation. These are documented in L</Schema Definition> below.
 
 
-=head1 SCHEMA DEFINITION
+=head1 Schema Definition
 
 A schema is an arrayref or hashref, where each key is the name of a built-in
 option or of a validation to be performed and the values are the arguments to
@@ -473,7 +473,7 @@ Or to use the same validation multiple times:
 
   [ regex => qr/^a/, regex => qr/z$/ ]
 
-=head2 Built-in options
+=head1 Built-in options
 
 =over
 
@@ -730,7 +730,7 @@ reporting.
 
 =back
 
-=head2 Standard validations
+=head1 Standard validations
 
 Standard validations are provided by the module. It is possible to override,
 re-implement and supplement these with custom validations. Internally, these
@@ -855,7 +855,7 @@ given the year and month.
 =back
 
 
-=head2 Custom validations
+=head1 Custom validations
 
 Custom validations can be passed to C<compile()> as the C<$validations> hashref
 argument.  A custom validation is, in simple terms, either a schema or a
@@ -885,7 +885,7 @@ schema that contains the I<func> built-in option to do the actual validation.
   my $schema = { prefix => 'Hello, ' };
   my $result = FU::Validate->compile($schema, $validations)->validate('Hello, World!');
 
-=head3 Custom validations and built-in options
+=head2 Custom validations and built-in options
 
 Custom validations can also set built-in options, but the semantics differ a
 little depending on the option. First, be aware that many of the built-in
@@ -909,13 +909,13 @@ error:
 
 The I<func> option is validated separately for each custom validation.
 
-Multiple I<keys> and I<elems> validations are merged into a single validation.
-So if you have multiple custom validations that set the I<elems> option, a
-single combined schema is created that validates all array elements. The same
-applies to I<keys>: if the same key is listed in multiple custom validations,
-then the key must conform to all schemas. With respect to the I<unknown>
-option, a key that is mentioned in any of the I<keys> options is considered
-"known".
+Multiple I<keys>, I<values> and I<elems> validations are merged into a single
+validation.  So if you have multiple custom validations that set the I<elems>
+option, a single combined schema is created that validates all array elements.
+The same applies to I<keys>: if the same key is listed in multiple custom
+validations, then the key must conform to all schemas. With respect to the
+I<unknown> option, a key that is mentioned in any of the I<keys> options is
+considered "known".
 
 All other built-in options follow inheritance semantics: These options can be
 set in a custom validation, and they are inherited by the top-level schema.  If
@@ -924,7 +924,7 @@ inherited. The top-level schema can always override options set by custom
 validations.
 
 
-=head3 Global custom validations
+=head2 Global custom validations
 
 Instead of passing a C<$validations> argument every time you call C<compile()>,
 you can also add custom validations to the global list of built-in validations: