5

The operational transform stuff used in Google Wave has a rather curious document format. A document is basically just an xml subset document - characters, start tags and end tags. In addition to that, the document has "annotations", which are meta-data associated with ranges, e.g. start position and end position. The white paper justifies their presence with:

Wave document operations also support annotations. An annotation is some meta-data associated with an item range, i.e., a start position and an end position. This is particularly useful for describing text formatting and spelling suggestions, as it does not unecessarily complicate the underlying structured document format.

I can certainly see how it would be somewhat difficult if an arbitrary range from a document would be selected and for example bolded - XML tag nesting is strict and that would cause a mess of open and close tag insertions.

However, is this really a problem in practise? I mean, does one necessarily have to support such operation, if not making an editor that basically mimics the years old word processing paradigm instead of being a structured editor? Would pure XML operational transform with the document structure as simply HTML5 be that terrible? Is it a performance issue that styles would be in the document as tags? Or does the operational transform model somehow produce unsatisfactory results on text formatting if they are represented with tags?

Also, a side question - how good would the pure "insert character, remove character, retain" operational transform model be on plain text representations? For example, editing HTML5 as text - or editing Wikipedia articles?

Nakedible
  • 4,067
  • 7
  • 34
  • 40

2 Answers2

2

There are fundamental problems with using a hierarchical markup language with OT. See below for a worked example:

Does operational transformation work on structured documents such as HTML if simply treated as plain text?

Community
  • 1
  • 1
jazmit
  • 5,170
  • 1
  • 29
  • 36
  • Thank you! Finally this question was answered properly! The example shows really simply why annotations are crucial. – Nakedible Sep 17 '12 at 18:18
2

This choice makes sense to me as an optimization on several fronts:

  • The underlying document remains as human readable and parse-able as possible
  • The algorithms to parse the underlying XML remain as simple as possible (useful for compatibility with non-google attempts at parsing the resulting documents, and for maintenance)
  • The extra collected garbage, after multiple edits, can lead to large performance hits - due to the sheer number of tags and/or additional passes on the document to attempt to simplify it.
blueberryfields
  • 45,910
  • 28
  • 89
  • 168
  • The rationale for all this is a bit unclear for me. The underlying document format gets especially obfuscated as styles cannot be seen from the document, but are separate ranges which a human can't really put together. Is HTML5 not human readable? Also, isn't the "algorithm" to parse the XML the same regardless of bolds an other stuff? I would expect the algorithm to be *more* complex when having to track the attributes separately. XML came in to fruition just because it was simple. And I'm not sure what extra garbage you are talking about? Every change is a recorded change to the document. – Nakedible Dec 11 '10 at 20:34
  • It makes sense to me to discount HTML5 as an option - it wasn't around when work on Wave probably began, for one. I assume that they would be using a customized parser in order to help clean up the extra tag noise that gets generated. The parser doesn't necessarily have to do that work though. The arbitrary ranges of the attributes are, I think, easier to manage when changes to them do not change the resulting parse tree. The garbage is "tag noise", resulting in a messier tree once parsed. – blueberryfields Dec 12 '10 at 00:09
  • HTML5 was just an example, XHTML/HTML4/whatever would've been just as suitable. – Nakedible Dec 12 '10 at 12:26