Restating what Dave said, the wave document is not XML. A complete description of the model could be given without using the word "XML". However, doc ops do describe a serialised tree-structure of nodes and text which looks very much like a DOM. Even in a simplified server that does no introspection, schema constraints on the ops constrain the sequence of element start/end to make sense as a DOM-style tree.
For ease of understanding at a broad level we often represent a wave document into something that looks like XML on paper. But it's not XML. So yes, the Wave document model was invented specifically for Wave, but inspired by DOMs. The idea of using stand-off annotations for styling information is not unique to Wave, and I believe has been part of earlier document formats. We eventually arrived at that solution to solve problems like that illustrated by Torben On Mon, Jan 9, 2012 at 3:08 PM, Michael MacFadden < [email protected]> wrote: > David, > > Thanks for the answer. It does spawn a new question which is that before > I started working with Wave, I had never come across "Annotated XML > Documents". Is this something standard or something that was invented for > wave. I am still a little fuzzy on what an annotated XML document is. > > ~Michael > > On Jan 8, 2012, at 5:21 PM, David Hearnden wrote: > > > Hi Michael, > > > > I can answer that new question quickly. > > > > If you're looking for an object model that has the same structure as a > DOM > > (i.e., element nodes, text nodes, etc), then you won't find it on the > > server. Saying that the documents are "annotated XML" is an abstract > > description that conveys the kind of information stored in documents. > > While any document *can* be represented as XML and a set of annotations, > > that is not the form of the object model used by the server to represent > a > > document. Instead, the server uses a much more efficient representation: > > i.e., it represents a document as an operation. This is because there is > > nothing on the server that needs to inspect the DOM form of a document. > > All the server does is apply ops, and provide representations of entire > > documents at different points in history (as an op). > > > > On the client, however, there are use cases that wants a DOM style object > > model for the representation of a document. This is exposed by the > > MutableDocument type. MutableDocument is generic, and has a concrete > > version that covers most use cases, called Document. The API is not a > w3c > > DOM API, but is instead something that is essentially equivalent to it > that > > allows much more efficient implementations and is also more typesafe. > > Instead of an API like element.appendChild(node), you get > > document.appendChild(element, node). But apart from that stylistic > > difference, there's the DOM representation of a document. > > > > -Dave > > > > On Mon, Jan 9, 2012 at 5:00 AM, Michael MacFadden < > > [email protected]> wrote: > > > >> Thank, > >> > >> I think I have figured out everything except for my question #1, by > >> debugging the code. Still looking for an answer for that one. > >> > >> I do have a new question. It has been said that the conversation model > >> (specifically the blip documents) are represented as "annotated" XML > >> documents. I haven't actually seen an example of a blip document with > >> annotations. Nor does it appear that the documents actually live > anywhere > >> as XML. I see the object model of document floating around, and I see > that > >> they are serialized in a semi binary format to the delta file store, > but I > >> haven't actually seen them represented as annotated XML anywhere. > >> > >> Mainly I am interested in seeing an example of a blip document > represented > >> as XML with annotations. Does this exist anywhere? > >> > >> ~Michael > >> > >> On Jan 7, 2012, at 10:57 PM, Alex North wrote: > >> > >>> Hi Michael, > >>> > >>> I've been intending to send you some good answers to these questions. > I'm > >>> just struggling to carve out the time to drag up the memories and give > >> you > >>> the info you need. But I still intend to! Hassle me, and feel free to > >> send > >>> more questions as they come up. > >>> > >>> On Wed, Dec 28, 2011 at 3:24 AM, Michael MacFadden < > >>> [email protected]> wrote: > >>> > >>>> All, > >>>> > >>>> I have been trying to dig in to the CC and OT concept in wave, so I > can > >>>> start to work on that section of the code. It seems like we have been > >>>> focusing on the UI and I want to make sure we have coverage in the CC > >>>> stack. I have read all of the OT literature, so I am fairly well > >> versed in > >>>> OT in general, but some of the specifics of the WaiB implementation > are > >> a > >>>> little fuzzy. > >>>> > >>>> Right now I am working on understanding composition and how we infer > the > >>>> servers path. I have a few questions. > >>>> > >>>> 1) In order to compose operations I assume they don't have to have the > >>>> same document width (how could they for successive inserts for > example), > >>>> but I assume they would need to span the same line? Is that right? > In > >>>> other words you wouldn't compose operations from one paragraph with > >>>> operations from another? Is the desire to compose one of the driving > >>>> reasons for the retain operation? > >>>> > >>>> > >>>> 2) When we send out "first" operation over to the server and we are > in a > >>>> holding pattern buffering client operations, are these operations > always > >>>> composed together and then sent over as a single operation when we get > >> the > >>>> ACK from the server. It seems like we can only send one operation to > >> the > >>>> server at a time, however the on line material implies that when we > get > >> and > >>>> ACK we send over ALL buffered operations. This seems to be > >> contradictory. > >>>> If we have buffered 4 operations, it seems like we can send all of > them > >> as > >>>> four individual operations. > >>>> > >>>> > >>>> 3) Is there a run down of how the CurrencyControl class does point #2 > >>>> anywhere. I see the unacknowledged, the inferredServerPath, and the > >>>> clientOperationsQueue objects and get a lose impression of how these > are > >>>> managed but any help with regard to incoming server operations while > we > >>>> have an operation in flight would be appreciated. Specifically what > >>>> transformations are performed on which object structures when we get a > >> new > >>>> operation form there server, and where / when is composition > happening. > >>>> > >>>> > >>>> 4) How exactly are the hashed versions designed? There seems to be a > >>>> monotonic scalar version number and a hash? I want to make sure I > >>>> understand how both are generated and how both are used. > >>>> > >>>> > >>>> If any of this is well documented, please let me know where I could > find > >>>> it. If it is not, I would volunteer to document this as I work > through > >> it. > >>>> Thanks in advance. > >>>> > >>>> Michael > >> > >> > >
