+=head1 PROFILE
+
+The profile is needed for mapping csv data to the accessors in the data object.
+
+The basic structure is:
+
+ PROFILE := [ CLASS_PROFILE, CLASS_PROFILE* ]
+ CLASS_PROFILE := {
+ profile => { ACCESSORS+ },
+ class => $classname,
+ row_ident => $row_ident,
+ mapping => { MAPPINGS* },
+ }
+ ACCESSORS := $field => $accessor
+ MAPPINGS := $alias => $field
+
+The C<ACCESSORS> may be used to map header fields to custom
+accessors. Example:
+
+ profile => {
+ listprice => 'listprice_as_number',
+ }
+
+In this case C<listprice_as_number> will be used to store the values from the
+C<listprice> column.
+
+In case of a One-To-One relationship these can also be set over
+relationships by separating the steps with a dot (C<.>). This will work:
+
+ customer => 'customer.name',
+
+And will result in something like this:
+
+ $obj->customer($obj->meta->relationship('customer')->class->new);
+ $obj->customer->name($csv_line->{customer})
+
+Beware, this will not try to look up anything in the database! You will
+simply receive objects that represent what the profile defined. If some of
+these information are unique, or should be connected to preexisting data, you
+will have to do that for yourself. Since you provided the profile, it is
+assumed you know what to do in this case.
+
+If no profile is given, any header field found will be taken as is.
+
+If the path in a profile entry is empty, the field will be subjected to
+C<strict_profile> and C<case_insensitive_header> checking and will be parsed
+into C<get_data>, but will not be attempted to be dispatched into objects.
+
+C<class> must be present. A new instance will be created for each line before
+dispatching into it.
+
+C<row_ident> is used to determine the correct profile in multiplexed data and
+must be given there. It's not used in non-multiplexed data.
+
+If C<mappings> is present, it must contain a hashref that maps strings to known
+fields. This can be used to add custom profiles for known sources, that don't
+comply with the expected header identities.
+
+Without strict profiles, mappings can also directly map header fields that
+should end up in the same accessor.
+
+With case insensitive headings, mappings will also modify the headers, to fit
+the expected profile.
+
+Mappings can be identical to known fields and will be prefered during lookup,
+but will not replace the field, meaning that:
+
+ profile => {
+ name => 'name',
+ description => 'description',
+ }
+ mapping => {
+ name => 'description',
+ shortname => 'name',
+ }
+
+will work as expected, and shortname will not end up in description. This also
+works with the case insensitive option. Note however that the case insensitive
+option will not enable true unicode collating.
+
+
+Here's a full example:
+
+ [
+ {
+ class => 'SL::DB::Order',
+ row_ident => 'O'
+ },
+ {
+ class => 'SL::DB::OrderItem',
+ row_ident => 'I',
+ profile => { sellprice => 'sellprice_as_number' },
+ mapping => { 'Verkaufspreis' => 'sellprice' }
+ },
+ ]
+