XML modifications in Google Wave and SCFX

So, a few of the technical bits of Google Wave remind me of some things I looked at briefly during my PhD a few years ago (but only a few, and solving a different problem -- I'm not claiming to have "invented Google wave" like those people who claim Harry Potter was really their idea).

A part of Google Wave's protocol is way of sending changes to an XML document, so that changes you make locally are reflected on the "canonical" server copy of the document and can be broadcast out to other viewers. This was something I looked at too -- albeit in a "good enough is good enough" sort of way -- so I was interested to see how the problems we faced differ, and what Google's solution looks like.

Well, Wave has to solve a few extra problems: their documents are edited by many people at once, so the change format has to be transformable, so that different people's changes can be reconciled. (In the Intelligent Book, even though pages are concurrently editable, exercises are usually worked on by students individually, so I could duck this issue.) They also have to deal with federated servers, security, etc. So, they've been looking at a much harder problem than I was with my little change format. And while their solution is still being refined, so far it looks pretty good.

However, from my very brief look, there was something that made me think "hmm, maybe you've missed a trick here". Google Wave's deltas are explicitly defined as an XML format. With SCFX (Simple Change Format for XML), which was my remote XML change API, I decided just to define function calls for each kind of modification -- including a "with" call for wrapping multiple calls into a transaction -- and to avoid defining a serialisation. In other words, I avoided specifying any particular XML schema. Why? Well, I realised that the function calls to my API were going to be made both locally and remotely. In the local case, it's inefficient to go writing and reading XML just to make a call to change a document. And in the remote case, whichever Web RPC format you use already defines a format for serialising a function call into text. If I use XML-RPC, then the XML-RPC stub itself will turn my function calls into a piece of XML to send over the Web. The same happens if I use SOAP. So, by refusing to define an XML format, I could just say "here are the functions, call them using any of the following RPC technologies". So, for instance, I could pass changes from the server back to the browser marked up as Javascript code if I liked. And I wasn't tied to this extra step of deserialising my own special XML format.

Apart from that -

• Wave's protocol looks like just a diff -- add and delete of content -- whereas SCFX also included larger operations such as move and copy, so that for instance an app that used a tree of complex GUI components to show a tree of XML elements could just move them rather than having to recreate them afresh if the XML element at the top was moved.
• Google Wave relies on a particular character layout of the XML -- for instance there must be no empty tags (<foo />), and all the clients need to treat whitespace identically. SCFX used XPaths to address content, so this wasn't so fragile. (But an XPath would be difficult to transform).