incubator-wave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Hearnden <>
Subject Re: OT constraints on element nesting
Date Wed, 13 Apr 2011 00:23:28 GMT
Hi Andy,

1)  The problem being demonstrated is how to express style information.  It
is a requirement for a rich text editor to be able to apply and change
styles over arbitrary ranges of content.  If nested elements are used to
express style (e.g., <b>s, <i>s etc), then this means that applying and
changing styles involves complex tree structural mutations: taking regions
of content, breaking them apart, wrapping them in style elements, etc.  Then
when you add concurrency, you get issues when overlapping styles are
applied.  e.g., if I boldify "I like [my text] pretty", and you concurrently
greenify "I like my [text pretty]".  Trying to reach the desirable
resolution, where the word "text" is both bold and green, is quite difficult
to achieve if those operations involve tree structural mutations.  Instead,
Wave adopted a parallel structure of document annotations.  Abstractly, each
character, opening tag, and closing tag has its own map of key-value pairs.
 Setting a style only involves setting a key-value pair over a range of
characters and tags (e.g., "style/fontWeight" = "bold", or "style/color" =
"green"), so the concurrent style mutation scenario described above is
drastically simplified, since there is no conflict.

Nested elements, however, are completely supported.  e.g., the data model
for an image thumbnail is:
  <body><line/>Hello, here is a <image id=...><caption>nice
which has line elements in a body elements, caption in an image, and image
in a body.

2) It is a limitation of OT that the universe of mutations must have
resolution rules.  Complex mutations usually require complex resolution
rules, so a poor choice of mutation mechanism makes defining the OT hard.
 In its early days, Wave did use nested elements for styling, and had
operations to extract and wrap regions of the document in a new element
("wrap"), and the inverse operation to break apart an element and have its
parent adopt its children ("unwrap"), and OT rules were written to resolve
concurrent wraps and/or unwraps, including overlapping regions.  This was
greatly simplified when we shifted away from using structural elements to
represent mutable information that decorates other information (like

3) Nested elements are supported.  However, there are no primitive mutations
to wrap/unwrap structural regions of a document.  You can always do this
yourself, by deleting and creating copies of elements in a series of
mutations (and assuming that that document's schema allows it), but if there
are concurrent mutations going on in that same region, the concurrent
resolution is unlikely to be favourable.

In summary, XML does not provide a sufficient data model to have a language
of mutations that provides both rich-text editing as well as good concurrent
resolution from OT.  If you don't care about rich text editing, or you don't
care about resolving concurrent mutations in a good way, then XML may be
sufficient.  By adding a parallel structure of annotations to that XML, and
choosing wisely whether state should be stored as XML structure or as
annotations, we were able to significantly improve the range of rich-text
operations that resolve well with OT.


On Wed, Apr 13, 2011 at 3:03 AM, Hochhaus, Andrew <>wrote:

> Wave model deep dive [1] mentions that nested elements don't play well with
> OT.
> 1) Why is this? Does any documentation describe the limitations in
> greater detail?
> 2) Is this a limitation of OT in general, or is it specific to the
> wave implementation of OT?
> 3) If specific to wave, can anyone provide references or a description
> of what would need to change to supported nested elements?
> Thanks,
> Andy
> [1] starting 8:30 mins

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message