There's a Linq-to-XSD (it's now supposed to be hosted on codeplex, see this; with some minimal effort you can get your hands on it). I would try it out and asses the following, based on your specificrequirements:
- forward/backward compatibility;
- performance.
I've seen more people doing OO-like than straight DOM-like approaches, so if the two above don't matter, I would go with Linq to XSD or xsd.exe from generated schema.

It depends on whether you like programming against business domain objects or XML documents containing business data. Each approach has different merits, although it often comes down to how you want to think about the client and the service (types or documents?).

You should be aware though that sometimes people get into trouble when they try to have the best of both worlds. That is, they want to model their data as XSD schemas but program against that data as if it were domain types. They use all sorts of fancy features of XSD schema and end up creating something that is far to complex for a serializer to know what to do with.

So regardless of whether you choose to start with types or schema, my advice is to keep the ultimate data model as simple as possible. Your developers and customers will thank you!
-steve