I thought the video gave a pretty good explanation anyway. Purist XML is pretty overrated anyway, it creates more problems than it solves. Consider the XHTML debacle. What if W3C had continued to be stubborn on that issue, and they hasn't listened to HTML5 crowd. There was an obsession with the idea of purist transformations XSLT and all that. But it is fairly clear that it would have been a nightmare for wave.
----- Original Message ---- From: David Hearnden <[email protected]> To: [email protected] Sent: Wed, 13 April, 2011 1:23:28 Subject: Re: OT constraints on element nesting 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 picture</caption></image><line/></body> 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 styles). 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. -Dave On Wed, Apr 13, 2011 at 3:03 AM, Hochhaus, Andrew <[email protected]>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] http://www.youtube.com/watch?v=6ZqpeFydq4A starting 8:30 mins >
