Say you have some arbitrary data entity out in the world. For this example, let’s say it’s a spreadsheet.
Let’s also say you have some way to get/infer schema/metadata for that data – that is, you can know types (e.g. double versus string) and relationships (e.g. this column means ‘salary’) and metadata (e.g. this sheet is for the June 2009 budget).
Type providers lets you code up a kind of ‘shim library’ that knows about some kind of data entity (e.g. a spreadsheet) and use that library as part of the compiler/IDE toolchain so that you can write code like
mySpreadsheet.ByRowAndColumn.C4
or something, and get Intellisense (autocompletion) and tooltips (e.g. describing cell C4 as Salary for Bob) and static typing (e.g. have it be a double or a string or whatever it is). Essentially this gives you the tooling affordances of statically-typed object models with the ease-of-use leverage of various dynamic or code-generation systems, with some improvements on both. The ‘cost’ is that someone has to write the shim library (the ‘type provider’), but many such providers are very general (e.g. one that speaks OData or Excel or WMI or whatnot) and so a small handful of type provider libraries makes vast quantities of the world’s data available in your programming language with static typing and first-class tooling support.
The architecture is an open compiler, where provider-authors implement a small interface that allows them to inject new names/types into the programming context. A type provider might be just another library you pass to the compiler (a reference in your project, -r-ed), with extra metadata that marks it as a type provider that participates in the compilation/IDE/codegen portions of development.
I don’t know exactly what a “custom mapper” is in your xml example to draw a comparison.