I don't think unit test framework would help you.
Unit test frameworks were designed to solve these things:
- Automatically register unit tests.
- Select which tests to run depending on command-line or other arguments.
- Simplify repeated initialization and deinitialization.
- Report values used in failed conditions.
Now I don't see how any of those would help you. You have one long list of tests, that you need to apply to the document, you need to run all tests, you don't want to initialize and deinitialize separately for each test and you need messages describing what is wrong with the document, not dump of some random objects you compared to check.
Especially this test isolation stuff and the fact, that unit test frameworks are generally not designed to be run on externally provided sets of data is probably going to get in your way more than anything else might help you. Because you have to write the tests themselves in the raw language anyway and that's almost all the work there is.
So I'd say just pick a language you know, a good XML parsing library, that will give you convenient access to the document tree and just write a simple application with that.
Ad edit: .NET has a compiler (you give it XSD and it spits out class definitions; it can go the other way too) to generate object representation corresponding to the document from it's XSD, which is by far most convenient method to access the document elements and will verify the document conforms to the XSD as side-effect. So I'd recommend using that for reading the document. That has nothing to do with unit test, of course.