UI controls can be bound to an ADO.NET DataTable. The DataTable natively
understands XML, and can read and write to/from XML files directly:

http://msdn2.microsoft.com/en-us/library/system.data.datatable.readxml.aspx

http://msdn2.microsoft.com/en-us/library/system.data.datatable.writexml.aspx

If you are unfamiliar with ADO.NET, consider that a standard approach to
working with data is to query a database and load data into a DataSet or
DataTable via an ADO.NET DataAdapter instance. Note that a DataSet is
basically a container for DataTable objects. Data lives only in DataTables -
and never directly in a DataSet. To over simplify, you can pretty much think
of a DataSet as an in-memory relational database, as you can set up
DataRelations amongst contained DataTables. Anyway, you then bind your UI
components to the DataSet (specifying the particular DataTable) or a
DataView, or bind directly to a DataTable (DataTables are not required to
exist within a DataSet). The user can then update the data in the
DataTable(s) (perhaps via contained in a DataSet). You then persist the
changes back to the database with an ADO.NET DataAdapter instance.

Keep in mind that (1) DataTables have no clue as to where their data came
from. And (2) because DataTables natively store their data as in-memory XML,
they are capable of reading and writing directly to XML files on disk (no
need to get data from a typical database like MS Access or SQL Server). The
two links above have overloads you can use to read and write directly
to/from XML files on disk.

-HTH

This is only a heads-up.  I have not used this, although it's been
approved for use at my organization.  If you're definition of overkill
is a large footprint, maybe you should look into SQLite
(www.SQLite.org).  Draw your own conclusions, but if you try it,
please update us.

JT