I think Steve is giving you the right way to "derive" the ultimate structure. Meaning - you may need to do this iteratively, while you determine all of the meaningful elements.

For "loosely"-structured, or fluid data structures, the XML type is ideal. That's what the 2005 team built it for. The advice put forth on the matter is to try to take a crack at figuring out what elements get a LOT of traffic/search/filter/select activity, and split them out of the XML into "real" data structures. If you find you need more specificity on something than what is physically defined, use your XML schema to approximate your way into the right fields, and once you have it right, then consider whether they need to be moved into the "real" structure.

I've successfully use this method when I just can't get a decently read on what might be "once in a blue moon" data, and what might get a lot more traffic.

Don't forget to INDEX your XML data. SQL2005 allows for some pretty darn good performance if you index things correctly, and XML datatypes are indexable as well. For occasional querying, you can get some fairly nice performance, with a primary XML index and possible another secondary one on the "heavier" nodes.