http://www.waveprotocol.org/protocol/design-proposals/client...
To explain at greater length, WebSockets are much simpler. If you wanted to do something simple, like let your website's users chat with each other, you could whip something up with WebSockets. If you wanted to do something complicated, like a real-time cooperative game, you could use WebSockets as the basic structure that you would built a more complicated messaging system on top of. A WebSocket is a two-ended pipe, client to server, and if you want a more complicated network structure you have to create that yourself.
The Wave protocol is much more complicated and aimed at a more specific case. It is built on the idea of shared documents which is at a higher level than sockets. It contains specifications for things like cursors and deleting segments of text in documents. If you were building a system that did not have something akin to shared documents, it would probably not make sense to use the Wave protocol. But if you were building a system based on shared documents, like an EtherPad clone, then the Wave protocol might be perfect and save you a lot of work.
They are not really direct competitors like JSON vs XML. It is more like comparing HTTP to XML. You could operate the Wave protocol over WebSockets, just like you could send XML over HTTP.
The other is a high level protocol that sits on top of a socket and does all kinds of various presumably-wonderful things, but is not itself a socket. Trying to replace sockets with Wave would be a major step backwards; the reason we need websockets in the first place is that the high-level HTTP protocol embeds assumptions that are not always correct for a given application and therefore gets in the way; Wave would be even worse about that.
Google Wave is one of the many protocols that can be built on a socket. Wave and HTTP are peers, sockets are the foundation they both sit on, WebSockets are as close to sockets as the web will let us get.
(It should be pointed out that WebSockets still are not the ultimate in flexibility; the TCP that WebSockets sit on itself makes assumptions about applications that are not appropriate to all applications, which is why not every packet on the internet is a TCP packet. I've glossed over some other details too, which in my judgment would only confuse at this point.)