There's no right or wrong answer to this without considering the requirements, but if you need to do anything except return to the client the entire XML blob -- based on some other criteria than the XML contents itself -- XML fields are not a good idea.
For searching, while XML indexes can mitigate some of the performance problems, there is a big storage penalty to pay for those. Since this question is tagged data-warehouse, this kind of solution (your option 2) is almost certainly inappropriate for all kinds of reasons.
The one thing you definitely want to do is shred the XML and put all commonly-used (searched, selected) attributes in relational fields. Depending on the structure of the XML, this could mean a single table, or it could mean multiple tables.
The only question is what to do with everything else that doesn't fit. The remaining fields could continue to live as XML if the schema has to be really flexible (probably a good idea to strip out everything else to save storage space). You could also consider implementing an architecture based on sparse columns (SQL Server 2008+) if the structure is more predictable.
If you need to put things back into XML for client applications,
FOR XML will likely be your best friend.