I think you were not as clear as you could have been. How big are these files going to be? Would it make sense for the data layer to always keep the XmlDocument in memory and dump to harddisk on every update?
How often are updates going to occur, if at all? How are you going to handle concurrency? Are updates going to be transactional across multiple xml files? How are you going to handle consistency and transactional integrity? If there are no updates, your life will be much simpler.
Methods don't have to be static. The main thing to consider is that, in the future, you might want to change the DAL provider from XML to DB. To this end, the concrete implementation of the DAL interfaces should talk to an abstract data provider. For you, it would be an Xml provider initially, but you should be able to write a Sql Provider that implements the same interface and easily switch the implementation using dependency injection, config files or what-have-you.
One you have instances of the DAL implementations, you can just use those objects to talk to the data layer.
Hope this is a good start for you.