Systems and methods for managing suggested edits in a collaborative document editing environment

CROSS-REFERENCES

0001This application is a non-provisional of, and claims priority to U.S. provisional application Nos. 62/016,259, 62/016,262, 62/016,280, 62/016,451, 62/016,456, and 62/016,466, all filed on Jun. 24, 2014.

0002This application is related to PCT international application Ser. No. ______, filed on the same date, entitled “Systems and Methods for Managing Suggested Edits in a Collaborative Document Editing Environment” (attorney docket no. GP-22098-00-WO|108827-1281-WO1).

0003The aforementioned applications are all herein expressly incorporated by reference.

FIELD OF THE INVENTION

0004In general, this disclosure relates to electronic documents, in particular, to systems and methods for managing suggested edits in a collaborative document editing environment.

BACKGROUND

0005During development of an electronic document, it is often desirable to have multiple reviewers propose changes to and comment on a draft of the electronic document. For example, an author may create an initial draft of an electronic document and send a copy of the electronic document to multiple reviewers for comments. Each reviewer may independently propose changes or make comments in the electronic document and return a revised version of the electronic document back to the author. These steps may be repeated until the author and the reviewers are satisfied with a version of the electronic document. However, this process is time consuming and inefficient.

SUMMARY

0006Systems and methods disclosed herein provide a document editor platform to manage suggested edits in a collaborative document. The document editor may instantiate a document model associated with the collaborative document. When a first editing suggestion is received for the collaborative document, a first suggestion command is associated with the first editing suggestion based on a type of the first editing suggestion and a type of the document model. The document editor may apply the first suggestion command on the document model to present the first editing suggestion within the collaborative document. When an acceptance indication for the first editing suggestion is received, the document model can be updated with the first suggestion command in response to the received acceptance indication.

BRIEF DESCRIPTION OF THE DRAWINGS

The above and other features of the present disclosure, including its nature and its various advantages, will be more apparent upon consideration of the following detailed description, taken in conjunction with the accompanying drawings in which:

<figref idref="DRAWINGS">FIG. 1</figref> is a diagram of a computerized system <b>100</b> for providing a collaborative document environment, according to an illustrative embodiment.

<figref idref="DRAWINGS">FIGS. 2A-2B</figref> provide an example logic flow diagram illustrating aspects of managing suggested edits within a document model, according to an illustrative embodiment.

<figref idref="DRAWINGS">FIG. 3</figref> provides example logic diagrams illustrating aspects of suggestion filtering procedures for a document model, according to an illustrative embodiment.

<figref idref="DRAWINGS">FIGS. 4A-4B</figref> show an example logic flow diagram <b>400</b> illustrating aspects of merging suggested edits, according to an illustrative embodiment.

<figref idref="DRAWINGS">FIG. 5</figref> shows a flow chart of a method <b>500</b> used by the review manager <b>102</b> to use the priority categories to determine the order in which to merge suggestions within a document.

<figref idref="DRAWINGS">FIG. 6</figref> shows an example logic flow diagram <b>600</b> illustrating aspects of defining an omit transform mutation for a document model, according to an illustrative embodiment.

<figref idref="DRAWINGS">FIG. 7</figref> provides an example logic flow diagram <b>700</b> illustrating aspects of notifying editors of changes to a collaborative document by collaborators, according to an illustrative embodiment.

<figref idref="DRAWINGS">FIG. 8</figref> provides an example logic flow diagram <b>800</b> illustrating aspects of converting edits into a suggestion, according to an illustrative embodiment.

<figref idref="DRAWINGS">FIG. 9</figref> is a schematic diagram of an exemplary computer system employed in accordance with one or more implementations of the disclosure.

DETAILED DESCRIPTION

0017To provide an overall understanding of the systems and methods described herein, certain embodiments will now be described, including a system and method for managing suggested edits in an editing environment. However, it will be understood by one of ordinary skill in the art that the systems and methods described herein may be adapted and modified as is appropriate for the application being addressed and that the systems and methods described herein may be employed in other suitable applications, and that such other additions and modifications will not depart from the scope thereof Generally, the computerized systems described herein may comprise one or more engines, which include a processing device or devices, such as a computer, microprocessor, logic device or other device or processor that is configured with hardware, firmware, and software to carry out one or more of the computerized methods described herein.

0018<figref idref="DRAWINGS">FIG. 1</figref> is a diagram of a computerized system <b>100</b> for providing a collaborative document environment, according to an illustrative embodiment. System <b>100</b> includes a server <b>104</b> and three user devices <b>109</b>, <b>113</b>, and <b>117</b> connected over a network <b>120</b>. The server <b>104</b> includes an electronic database <b>103</b> and a review manager <b>102</b>, which manages updates to various versions of a master document <b>106</b>. The master document <b>106</b> may be stored on the electronic database <b>103</b> on the server <b>104</b>, or in a separate storage device.

0019To make the process of collaborating on electronic documents more efficient, a collaborative document editing environment is provided for integrating collaboratively proposed changes of an electronic document. In the collaborative document editing environment, users at different user devices may simultaneously access the master document <b>106</b> to review the document and propose changes. Each user is associated with a user type (such as an editor, a reviewer, or a viewer for example), which defines a level of authority for access to and editing capabilities of various versions of the document. As is shown in <figref idref="DRAWINGS">FIG. 1</figref>, an editor at the user device <b>109</b> may interact with the master document <b>106</b> over the editor interface <b>110</b>, a reviewer at the user device <b>113</b> may interact with the master document <b>106</b> over the reviewer interface <b>114</b>, and a viewer at the user device <b>117</b> may interact with the master document <b>106</b> over the viewer interface <b>118</b>.

0020A reviewer of a document may view, make suggested edits, and provide comments on the document, but may not have permission to accept or reject any of the suggested edits. The reviewer may further view suggested edits and comments provided by other reviewers of the document. An editor has a greater level of authority for the document than the reviewer, and may accept or reject any suggested edit, and may also delete any comments made by the reviewer. Moreover, the editor also has access to make direct changes to the document by directly editing or making comments on the document. The edits received from an editor may be treated as accepted edits. A viewer of the document has a lower level of authority than the reviewer, and may only view a clean published version of the document, not including any indication of the suggested edits or comments. In an example, when an editor views the document, the editor may view a live stream of collaborative updates made by multiple reviewers at the same time, significantly reducing the amount of time to develop the document. In this manner, by allowing for efficient collaboration across a set of users proposing changes to a document, the systems and methods disclosed herein offer significant advantages over a system in which reviewers independently propose changes to a document.

0021Applications may want to allow changes to be tracked as suggestions, requiring them to be accepted or rejected before they are incorporated into the document. Doing so requires representing those changes in such a way where they are separable from the underlying model of the collaborative document, and allowing different changes to be associated with the same suggestion.

0022<figref idref="DRAWINGS">FIGS. 2A-2B</figref> provide an example logic flow diagram illustrating aspects of managing suggested edits within a document model. Starting at <b>201</b>, a document model can be instantiated associated with a collaborative document. For example, the document model can be instantiated at a server (e.g., <b>104</b> in <figref idref="DRAWINGS">FIG. 1</figref>) to be associated with a master copy of the electronic document. Suggest changes can be received from a user via a user device (e.g., <b>109</b> in <figref idref="DRAWINGS">FIG. 1</figref>), at <b>202</b>. The document model can introduce a document editing mode where document modifications are tracked as suggestions and can be accepted/rejected by editors. For example, the document model can verify whether a user has the authority level to make a suggested edit, e.g., whether the user is a reviewer, editor or viewer, at <b>203</b>, and provide a “suggest” option to a user who is eligible to make a suggested edit on the collaborative document from a user device. This mode can replace a comment-only mode, allowing people with comment access to both make comments and make suggestions. In general, edits done by an editor can be doable by suggestors.

0023At <b>204</b>, the server can determine semantics to apply based on the suggested edits. For example, suggestions can be represented in a model-specific manner. Generally, they are represented by annotating which parts of the model are suggested insertions/deletions/changes. For example, for a string text model, ranges of suggested insertions and deletions are kept. Commands can be thought of as acting within a certain addressable space. Examples include a spacer string or entity map, a list of slides or set of shapes for presentations. Given their addressable space, commands that can be included in a suggestor can be shown in Table 1 as below:

0000<tables id="TABLE-US-00001" num="00001"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center" /><thead><row><entry namest="1" nameend="1" rowsep="1">TABLE 1</entry></row></thead><tbody valign="top"><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Example Commands</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="42pt" align="left" /><colspec colname="2" colwidth="77pt" align="left" /><colspec colname="3" colwidth="98pt" align="left" /><tbody valign="top"><row><entry>Command</entry><entry>Apply semantics</entry><entry>Examples</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry>Create</entry><entry>Insert object into space.</entry><entry>InsertSpacersMutation</entry></row><row><entry /><entry /><entry>InsertCommand</entry></row><row><entry>Delete</entry><entry>Delete object from space.</entry><entry>DeleteCommand</entry></row><row><entry /><entry /><entry>DeleteSpacersMutation</entry></row><row><entry>Modify</entry><entry>Modify property attached</entry><entry>ApplyStyleMutation</entry></row><row><entry /><entry>to the object.</entry><entry>ShapePropertiesCommand</entry></row><row><entry>Move</entry><entry>Move an object between</entry><entry>MovePageCommand</entry></row><row><entry /><entry>two places in the space.</entry></row><row><entry>Replace</entry><entry>Replace an object with a</entry><entry>None. Potentially could have</entry></row><row><entry /><entry>different one within the</entry><entry>some ReplaceSpacersMutation</entry></row><row><entry /><entry>same space.</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0024A suggestion command can be associated with the editing suggestion at <b>205</b>. In order to support suggest changes, each command may have a corresponding suggestion command. When in a suggestions mode, the suggest version of the command is applied instead of the regular version of the command. Example semantics for the suggestion commands derived from the example commands shown in Table 1 can be shown in Table 2 below:

0000<tables id="TABLE-US-00002" num="00002"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center" /><thead><row><entry namest="1" nameend="1" rowsep="1">TABLE 2</entry></row></thead><tbody valign="top"><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Example Suggestion commands</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="42pt" align="left" /><colspec colname="2" colwidth="84pt" align="left" /><colspec colname="3" colwidth="91pt" align="left" /><tbody valign="top"><row><entry>Command</entry><entry>Apply semantics</entry><entry>Suggest Semantics</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry>Create</entry><entry>Insert object</entry><entry>Insert object and mark it as</entry></row><row><entry /><entry /><entry>a suggested insertion.</entry></row><row><entry>Delete</entry><entry>Delete object</entry><entry>Mark object as a suggested</entry></row><row><entry /><entry /><entry>deletion.</entry></row><row><entry>Modify</entry><entry>Modify property attached</entry><entry>Modify property attached to</entry></row><row><entry /><entry>to the object.</entry><entry>object in a parallel space.</entry></row><row><entry>Move</entry><entry>Move an object between</entry><entry>Annotate object with new</entry></row><row><entry /><entry>two places in the space.</entry><entry>suggested position.</entry></row><row><entry>Replace</entry><entry>Replace an object with a</entry><entry>Insert object and mark both</entry></row><row><entry /><entry>different one within the</entry><entry>inserted object and replaced</entry></row><row><entry /><entry>same space.</entry><entry>object as suggested replace-</entry></row><row><entry /><entry /><entry>ments of each other.</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0025As can be seen from the above, the suggestion command SuggestCreate can create the object, but also marks it as a suggested insertion. This means that suggested insertions affect the addressable space just like regular insertions—future commands assume the existence of the objects. Unlike regular deletion, SuggestDelete does not actually delete the object, but marks it for deletion. This allows for the original object to be addressed and modified until the suggestion is accepted or rejected. SuggestModify can keep around a set of parallel suggested properties for an object. Note that none of the framework commands need suggest versions. The document model may then apply the suggestion command to present the editing suggestion at <b>206</b>.

0026Continuing on with <figref idref="DRAWINGS">FIG. 2B</figref>, after presenting the editing suggestion with the document model at <b>207</b>, similarly to the suggestion commands, for each command there are corresponding accept and reject commands. Thus, when user feedback in response to the editing suggestion is received at <b>208</b>, if an acceptance is indicated at <b>209</b>, the document model can convert the suggested edit to accepted edit at <b>210</b>, and update the document model at <b>211</b>. An updated document based on the accepted edit can be published to the user at <b>212</b>. Otherwise, if a rejection is indicated at <b>209</b>, the editing suggestion can be removed from the document at <b>213</b>. The example accept or reject semantics can be shown in Table 3 below:

0000<tables id="TABLE-US-00003" num="00003"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="287pt" align="center" /><thead><row><entry namest="1" nameend="1" rowsep="1">TABLE 3</entry></row></thead><tbody valign="top"><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Example Accept/Reject Semantics</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="5"><colspec colname="1" colwidth="35pt" align="left" /><colspec colname="2" colwidth="56pt" align="left" /><colspec colname="3" colwidth="77pt" align="left" /><colspec colname="4" colwidth="63pt" align="left" /><colspec colname="5" colwidth="56pt" align="left" /><tbody valign="top"><row><entry>Command</entry><entry>Apply semantics</entry><entry>Suggest semantics</entry><entry>Accept semantics</entry><entry>Reject semantics</entry></row><row><entry namest="1" nameend="5" align="center" rowsep="1" /></row><row><entry>Create</entry><entry>Insert object</entry><entry>Insert object and mark</entry><entry>Unmark as</entry><entry>Delete object.</entry></row><row><entry /><entry /><entry>it as a suggested</entry><entry>suggested</entry></row><row><entry /><entry /><entry>insertion.</entry><entry>insertion.</entry></row><row><entry>Delete</entry><entry>Delete object</entry><entry>Mark object as a</entry><entry>Delete object.</entry><entry>Unmark as</entry></row><row><entry /><entry /><entry>suggested deletion.</entry><entry /><entry>suggested</entry></row><row><entry /><entry /><entry /><entry /><entry>deletion</entry></row><row><entry>Modify</entry><entry>Modify property</entry><entry>Modify property</entry><entry>Modify property</entry><entry>Remove property</entry></row><row><entry /><entry>attached to</entry><entry>attached to object</entry><entry>in real space and</entry><entry>modification in</entry></row><row><entry /><entry>the object.</entry><entry>in a parallel space.</entry><entry>remove parallel</entry><entry>parallel space.</entry></row><row><entry /><entry /><entry /><entry>modification.</entry></row><row><entry>Move</entry><entry>Move an object</entry><entry>Annotate object with</entry><entry>Remove annotation</entry><entry>Remove</entry></row><row><entry /><entry>between two</entry><entry>new suggested position.</entry><entry>and actually move</entry><entry>annotation</entry></row><row><entry /><entry>places in the</entry><entry /><entry>object to that</entry></row><row><entry /><entry>space.</entry><entry /><entry>position.</entry></row><row><entry>Replace</entry><entry>Replace an</entry><entry>Insert object and</entry><entry>Delete replaced</entry><entry>Delete inserted</entry></row><row><entry /><entry>object with a</entry><entry>mark both inserted</entry><entry>object and unmark</entry><entry>object and</entry></row><row><entry /><entry>different one</entry><entry>object and replaced</entry><entry>inserted object.</entry><entry>unmark</entry></row><row><entry /><entry>within the</entry><entry>object as suggested</entry><entry /><entry>replaced object.</entry></row><row><entry /><entry>same space.</entry><entry>replacements of</entry></row><row><entry /><entry /><entry>each other.</entry></row><row><entry namest="1" nameend="5" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0027As can be seen in Table 3, the AcceptCreate can unmark the object as a suggested insertion, making it the same as regularly inserted objects. The RejectCreate can delete the object. Similarly, AcceptDelete deletes the object and reject delete unmarks it as a suggested deletion. AcceptModify takes the parallel properties and moves them into the regular properties for that object. This overrides the regular properties and gets rid of the parallel properties. RejectModify can get rid of the parallel properties.

0028Every suggestion command has an id so that multiple commands can be conceptually linked together as a single suggestion. These ids are kept around in the model in the following form: <ul id="ul0001" list-style="none"><li id="ul0001-0001" num="0000"><ul id="ul0002" list-style="none"><li id="ul0002-0001" num="0029">When objects are marked as a suggested insertion or deletion, that suggestion has an id attached to it. Objects may have multiple suggested insertion or deletion ids.</li><li id="ul0002-0002" num="0030">When properties of an object are suggested, they are modified in a parallel space. This space is tied to an id, so that multiple property changes within a single suggestion are kept together. Objects may have multiple property modification parallel spaces.</li><li id="ul0002-0003" num="0031">When moves are suggested, the object stays in place and is annotated with the new proposed index. This index is tied to a suggestion id, so that multiple suggestion ids can propose different move indices.</li><li id="ul0002-0004" num="0032">When replacements are suggested, a new object is inserted adjacent to the original one and both are annotated as replacements for each other. These replacement annotations would be tied to suggestion ids. <br /> Additionally, commands for accepting and rejecting suggestions also have an id. This id allows a user to specify which suggestion is actually being accepted/rejected for the cases where there are multiple suggestions proposing the same deletion or same property change. Note that suggestion ids are sufficient to identify what is being accepted or rejected for application purposes. <br /> However, the full command data, such as the spacer ranges, may be needed in order to properly transform against these commands. </li></ul></li></ul>

0033The following example provides example commands, for SuggestCreate and SuggestDelete:

00341. Suggest the insertion of some text: <ul id="ul0003" list-style="none"><li id="ul0003-0001" num="0000"><ul id="ul0004" list-style="none"><li id="ul0004-0001" num="0035">a. SuggestInsertSpacers(id: “a”, index: 5, spacers: “hello”)</li></ul></li></ul>

00362. Suggest the deletion of some text: <ul id="ul0005" list-style="none"><li id="ul0005-0001" num="0000"><ul id="ul0006" list-style="none"><li id="ul0006-0001" num="0037">a. SuggestDeleteSpacers(id: “b”, start: 10, end: 20)</li></ul></li></ul>

00383. Accept the first suggestion: <ul id="ul0007" list-style="none"><li id="ul0007-0001" num="0000"><ul id="ul0008" list-style="none"><li id="ul0008-0001" num="0039">a. AcceptInsertSpacers(id: “a”, start: 5, end: 9)</li></ul></li></ul>

00404. Reject the second suggestion: <ul id="ul0009" list-style="none"><li id="ul0009-0001" num="0000"><ul id="ul0010" list-style="none"><li id="ul0010-0001" num="0041">a. RejectDeleteSpacers(id: “b”, start: 10, end: 20)</li></ul></li></ul>

0042In another example, an application of SuggestModify can be illustrated in the following Table:

0000<tables id="TABLE-US-00004" num="00004"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center" /><thead><row><entry namest="1" nameend="1" rowsep="1">TABLE 4</entry></row></thead><tbody valign="top"><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Examples of Suggest Functions</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="112pt" align="left" /><colspec colname="2" colwidth="105pt" align="left" /><tbody valign="top"><row><entry>Command</entry><entry>Resulting Model After Application</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row><row><entry>Apply font size 15:</entry><entry>TextStyle @ [5, 10] {</entry></row><row><entry>ApplyStyleMutation</entry><entry>properties: {</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="98pt" align="left" /><colspec colname="2" colwidth="105pt" align="left" /><tbody valign="top"><row><entry /><entry>1. type: “text”</entry><entry>size: 15</entry></row><row><entry /><entry>2. range: [5, 10]</entry><entry>}</entry></row><row><entry /><entry>3. properties:</entry><entry>suggested properties: { }</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="offset" colwidth="28pt" align="left" /><colspec colname="1" colwidth="84pt" align="left" /><colspec colname="2" colwidth="105pt" align="left" /><tbody valign="top"><row><entry /><entry>a. {size: 15}</entry><entry>}</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="112pt" align="left" /><colspec colname="2" colwidth="105pt" align="left" /><tbody valign="top"><row><entry>Suggest applying font size 20:</entry><entry>TextStyle @ [5, 10] {</entry></row><row><entry>SuggestApplyStyleMutation</entry><entry>properties: {</entry></row><row><entry>1. id: “a”</entry><entry>size: 15</entry></row><row><entry>2. type: “text”</entry><entry>}</entry></row><row><entry>3. range: [5, 10]</entry><entry>suggested properties: {</entry></row><row><entry>4. properties:</entry><entry>“a”: { size: 15 }</entry></row><row><entry>a. {size: 20}</entry><entry>}</entry></row><row><entry /><entry>}</entry></row><row><entry>Someone else suggests applying font</entry><entry>TextStyle @ [5, 10] {</entry></row><row><entry>size 10.</entry><entry>properties: {</entry></row><row><entry>SuggestApplyStyleMutation</entry><entry>size: 15</entry></row><row><entry>1. id: “b”</entry><entry>}</entry></row><row><entry>2. type: “text”</entry><entry>suggested properties: {</entry></row><row><entry>3. range: [5, 10]</entry><entry>“a”: { size: 15 },</entry></row><row><entry>4. properties:</entry><entry>“b”: {size: 10}</entry></row><row><entry>a. {size: 10}</entry><entry>}</entry></row><row><entry /><entry>}</entry></row><row><entry>Accept the first suggestion.</entry><entry>TextStyle @ [5, 10] {</entry></row><row><entry>AcceptApplyStyleMutation</entry><entry>properties: {</entry></row><row><entry>1. id: “a”</entry><entry>size: 20</entry></row><row><entry>2. type: “text”</entry><entry>}</entry></row><row><entry>3. range: [5, 10]</entry><entry>suggested properties: {</entry></row><row><entry>4. properties:</entry><entry>“b”: {size: 10}</entry></row><row><entry>a. {size: 20}</entry><entry>}</entry></row><row><entry /><entry>}</entry></row><row><entry>Reject the second suggestion.</entry><entry>TextStyle @ [5, 10] {</entry></row><row><entry>RejectApplyStyleMutation</entry><entry>properties: {</entry></row><row><entry>1. id: “b”</entry><entry>size: 20</entry></row><row><entry>2. type: “text”</entry><entry>}</entry></row><row><entry>3. range: [5, 10]</entry><entry>suggested properties: { }</entry></row><row><entry>4. properties:</entry><entry>}</entry></row><row><entry>a. {size: 10}</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0043Inversion of suggest, accept and reject commands can be performed. As they are regular commands, suggest, accept and reject commands need inverses to support undoing these operations. Suggest and reject commands are inverses of each other, since suggest creates a suggestion and reject gets rid of it, as shown in the following table:

0000<tables id="TABLE-US-00005" num="00005"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center" /><thead><row><entry namest="1" nameend="1" rowsep="1">TABLE 5</entry></row></thead><tbody valign="top"><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Example Reject Semantics</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="35pt" align="left" /><colspec colname="2" colwidth="91pt" align="left" /><colspec colname="3" colwidth="91pt" align="left" /><tbody valign="top"><row><entry>Command</entry><entry>Suggest semantics</entry><entry>Reject semantics</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry>Create</entry><entry>Insert object and mark it as a</entry><entry>Delete Object</entry></row><row><entry /><entry>suggested insertion</entry></row><row><entry>Delete</entry><entry>Mark object as a suggested</entry><entry>Unmark as suggested deletion</entry></row><row><entry /><entry>deletion</entry></row><row><entry>Modify</entry><entry>Modify property attached to</entry><entry>Remove property modification</entry></row><row><entry /><entry>object in a parallel space.</entry><entry>in parallel space.</entry></row><row><entry>Move</entry><entry>Annotate object with new</entry><entry>Remove annotation.</entry></row><row><entry /><entry>suggested position.</entry></row><row><entry>Replace</entry><entry>Insert object and mark both</entry><entry>Delete inserted object and</entry></row><row><entry /><entry>inserted object and replaced</entry><entry>unmark replaced object.</entry></row><row><entry /><entry>object as suggested replace-</entry></row><row><entry /><entry>ments of each other.</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0044However, apply may not have a natural inverse. This means that new commands may be needed to invert applying a suggestion. These commands do not have inverses. Alternatively, the inverse of an accept can be modeled as the inverse of the original command plus a suggest of the original command. Here a tradeoff between number of commands may be observed having good OT semantics for these commands. The following table shows the inverse semantics for each accept command and how to model it as the inverse of the original plus a suggest.

0000<tables id="TABLE-US-00006" num="00006"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="287pt" align="center" /><thead><row><entry namest="1" nameend="1" rowsep="1">TABLE 6</entry></row></thead><tbody valign="top"><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Example Inverse of Accept Semantics</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="4"><colspec colname="1" colwidth="35pt" align="left" /><colspec colname="2" colwidth="77pt" align="left" /><colspec colname="3" colwidth="91pt" align="left" /><colspec colname="4" colwidth="84pt" align="left" /><tbody valign="top"><row><entry /><entry /><entry /><entry>Inverse of original</entry></row><row><entry>Command</entry><entry>Accept semantics</entry><entry>Inverse accept semantics</entry><entry>plus suggest</entry></row><row><entry namest="1" nameend="4" align="center" rowsep="1" /></row><row><entry>Create</entry><entry>Unmark as suggested</entry><entry>Mark as suggested</entry><entry>Remove object (Delete).</entry></row><row><entry /><entry>insertion.</entry><entry>insertion.</entry><entry>Insert object and mark</entry></row><row><entry /><entry /><entry /><entry>it as a suggested</entry></row><row><entry /><entry /><entry /><entry>insertion (SuggestCreate).</entry></row><row><entry>Delete</entry><entry>Delete object. Insert</entry><entry>Insert object (Create).</entry><entry>Mark for deletion</entry></row><row><entry /><entry>object and mark for</entry><entry /><entry>(SuggestDelete).</entry></row><row><entry /><entry>deletion.</entry></row><row><entry>Modify</entry><entry>Modify property in real</entry><entry>Restore original property in</entry><entry>Restore original</entry></row><row><entry /><entry>space and remove</entry><entry>real space and restore</entry><entry>property (Modify).</entry></row><row><entry /><entry>parallel modification.</entry><entry>parallel modification.</entry><entry>Modify property in a</entry></row><row><entry /><entry /><entry /><entry>parallel space</entry></row><row><entry /><entry /><entry /><entry>(SuggestModify).</entry></row><row><entry>Move</entry><entry>Remove annotation and</entry><entry>Restore object to its original</entry><entry>Restore object to its</entry></row><row><entry /><entry>actually move object to</entry><entry>location and restore the</entry><entry>original location (Move).</entry></row><row><entry /><entry>that position.</entry><entry>suggested move</entry><entry>Restore the suggested</entry></row><row><entry /><entry /><entry /><entry>move annotation.</entry></row><row><entry>Replace</entry><entry>Delete replaced object</entry><entry>Restore replaced object and</entry><entry>Replace inserted</entry></row><row><entry /><entry>and unmark inserted</entry><entry>mark replaced and original</entry><entry>object with the original</entry></row><row><entry /><entry>object.</entry><entry>as suggested replacements.</entry><entry>object (Replace).</entry></row><row><entry /><entry /><entry /><entry>Insert object again and</entry></row><row><entry /><entry /><entry /><entry>annotate objects as</entry></row><row><entry /><entry /><entry /><entry>suggested replacements</entry></row><row><entry /><entry /><entry /><entry>(SuggestReplace).</entry></row><row><entry namest="1" nameend="4" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0045As can be seen above, generally SuggestModify stores the proposed properties separate from the actual properties. However, if the properties include a nested addressable space, such as a list, this may beproblematic. For example, the ParagraphStyle in contains an array of tab stops. When someone suggested the insertion (or deletion) of a tab stop, the same behavior as regular create/delete may be nedded, for the same reasons. So suggesting the insertion of a tab stop needs to insert it into the actual list and mark it as inserted. Suggesting the deletion of a tab stop needs to mark it as deletion. Therefore, applying SuggestModify can apply the property in a parallel space only if it's not within a nested addressable space. Otherwise it uses the overall semantics.

0000<tables id="TABLE-US-00007" num="00007"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center" /><thead><row><entry namest="1" nameend="1" rowsep="1">TABLE 7</entry></row></thead><tbody valign="top"><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Example - Tab Stops</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="98pt" align="left" /><colspec colname="2" colwidth="119pt" align="left" /><tbody valign="top"><row><entry>Command</entry><entry>Resulting Model After Application</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row><row><entry>Insert a regular tab stop:</entry><entry>ParagraphStyle @ 5 {</entry></row><row><entry>ApplyStyleMutation</entry><entry>properties: {</entry></row><row><entry>1. type: “paragraph”</entry><entry>tab_stops: [{offset: 50}]</entry></row><row><entry>2. paragraph index: 5</entry><entry>}</entry></row><row><entry>3. properties:</entry><entry>suggested properties: { }</entry></row><row><entry>b. insert into “TabStops”</entry><entry>}</entry></row><row><entry>c. index: 0</entry></row><row><entry>d. properties: {offset:50}</entry></row><row><entry>Suggest modifying the offset of</entry><entry>ParagraphStyle @ 5 {</entry></row><row><entry>that tab stop:</entry><entry>properties: {</entry></row><row><entry>SuggestApplyStyleMutation</entry><entry>tab_stops: [{offset: 50}]</entry></row><row><entry>1. id: “a”</entry><entry>}</entry></row><row><entry>2. type: “paragraph”</entry><entry>suggested properties: {</entry></row><row><entry>3. paragraph index: 5</entry><entry>“a”: [{offset: 100}]</entry></row><row><entry>4. properties:</entry><entry>}</entry></row><row><entry>a. modify “TabStops”</entry><entry>}</entry></row><row><entry>b. index: 0</entry></row><row><entry>c. properties: {offset: 100}</entry></row><row><entry>Suggest inserting a tab stop:</entry><entry>ParagraphStyle @ 5 {</entry></row><row><entry>SuggestApplyStyleMutation</entry><entry>properties: {</entry></row><row><entry>1. id: “b”</entry><entry>tab_stops: [“b”: {offset: 15},</entry></row><row><entry>2. type: “paragraph”</entry><entry>{offset: 50}]</entry></row><row><entry>3. paragraph index: 5</entry><entry>}</entry></row><row><entry>4. properties:</entry><entry>suggested properties: {</entry></row><row><entry>a. insert into “TabStops”</entry><entry>“a”: [{ }, {offset: 100}]</entry></row><row><entry>b. index: 0</entry><entry>}</entry></row><row><entry>c. properties: {offset: 15}</entry><entry>}</entry></row><row><entry>Accept tab stop insertion:</entry><entry>ParagraphStyle @ 5 {</entry></row><row><entry>AcceptApplyStyleMutation</entry><entry>properties: {</entry></row><row><entry>5. id: “b”</entry><entry>tab_stops: [{offset: 15}, {offset: 50}]</entry></row><row><entry>6. type: “paragraph”</entry><entry>}</entry></row><row><entry>7. paragraph index: 5</entry><entry>suggested properties: {</entry></row><row><entry>8. properties:</entry><entry>“a”: [{ }, {offset: 100}]</entry></row><row><entry>d. insert into “TabStops”</entry><entry>}</entry></row><row><entry>e. index: 0</entry><entry>}</entry></row><row><entry>f. properties: {offset: 15}</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0046Like all commands, suggestion commands are created on the client via the edit system. One of the goals of this integration is for individual edits not to be aware of suggestions. This helps minimize the overhead of supporting suggest changes for new features. The basic approach is to take each command that would have been applied by the regular Edit, produce the suggest version of the command and apply that instead. However, that exposes an issue: the semantics of the suggestion command are not equivalent to those of the regular command. For example, a SuggestDelete does not actually delete the object. Therefore, the Edit cannot rely on applying commands producing certain changes to the ModelState. To solve this, a copy of the original ModelState can be made and the regular editing function can be applied on that copy. This can provide that any assumptions by the Edit on how the ModelState changes will be correct. Then, the commands can be taken that were originally applied and produce the suggest version of each of them. However, due to the differing semantics, each suggestion command may be adjusted based on the previous suggestion commands. For example, commands produced by a DragDropEdit suggest can include:

00471. DeleteSpacers(5, 10)

00482. InsertSpacers “hello” @ <b>50</b>

0000Suggest version of these commands can include:

00491. SuggestDeleteSpacers(5, 10)

00502. SuggestInsertSpacers “hello” @ <b>56</b>

0000To produce the suggested version of the commands, the following may be performed:

00511. Produce SuggestDeleteSpacers(5, 10) from DeleteSpacers(5, 10).

00522. Produce the appropriate transform command from SuggestDeleteSpacers.

00533. Produce SuggestInsertSpacers “hello” @ <b>50</b> from InsertSpacers “hello” @ <b>50</b>.

00544. Transform the SuggestInsertSpacers against the transform command, yielding

0000SuggestInsertSpacers “hello” @ <b>56</b>.

0055In one implementation, example object classes involved for a suggest-edit document environment may take a form similar to the following pseudo-code segment:

0000<tables id="TABLE-US-00008" num="00008"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="266pt" align="left" /><thead><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>/** Provides suggest edits. */</entry></row><row><entry>class <b>SuggestEditProvider</b>(editProvider) {</entry></row><row><entry>Edit <b>provideEdit</b>(context) {</entry></row><row><entry>return new SuggestEdit(context, this.editProvider_.provide(context.copy( ))</entry></row><row><entry>}</entry></row><row><entry>boolean <b>canApply</b>(context) {</entry></row><row><entry>return this.editProvider_.canApply(context)</entry></row><row><entry>}</entry></row><row><entry>}</entry></row><row><entry>/** Applies the given edit as a suggestion. */</entry></row><row><entry>class <b>SuggestEdit</b>(context, edit) {</entry></row><row><entry>void <b>applyInternal</b>(args) {</entry></row><row><entry>var result = this.edit_.apply(args);</entry></row><row><entry>var id = String(Math.random( )); // Some random string.</entry></row><row><entry>var transformCommands = [ ];</entry></row><row><entry>for each command in result.getCommands( ) {</entry></row><row><entry>var suggestedCommand = this.commandSuggestor_.getSuggestedCommand(command, id);</entry></row><row><entry>var pair = this.transformer_.transformBoth([suggestedCommand], transformCommands);</entry></row><row><entry>transformCommands = pair.getCommands( );</entry></row><row><entry>suggestedCommand = pair.getCommandsToWin( );</entry></row><row><entry>transformCommands.push(</entry></row><row><entry>this.commandSuggestor_.getTransformSuggestCommand(suggestedCommand);</entry></row><row><entry>this.applyCommand(suggestedCommand);</entry></row><row><entry>}}</entry></row><row><entry>}</entry></row><row><entry>/** Creates suggestion commands out of regular commands. */</entry></row><row><entry>interface <b>CommandSuggestor </b>{</entry></row><row><entry>/**</entry></row><row><entry>* Gets the corresponding suggestion command for the given command, with the given</entry></row><row><entry>* suggestion id.</entry></row><row><entry>* <i>This would be use for steps (1) and (3) in the example above.</i></entry></row><row><entry>*/</entry></row><row><entry>Command <b>getSuggestCommand</b>(command, id, model)</entry></row><row><entry>/**</entry></row><row><entry>* Given a suggestion command, returns a command to be used to transform future</entry></row><row><entry>* suggestions within the same Edit. This command will account for differing semantics</entry></row><row><entry>* between commands and suggestion commands as returned by getSuggestCommand.</entry></row><row><entry>* <i>This would be used for step (2) in the example above.</i></entry></row><row><entry>*/</entry></row><row><entry>Command <b>getTransformSuggestCommand</b>(suggestCommand)</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0056Accepting and rejecting suggestions are also done via edits: the AcceptEdit and the RejectEdit. These edits can only be performed by editors. They are triggered when accept/reject is chosen from the suggestion comment. The edit will be given the suggestion id to accept/reject, then it will inspect the model to determine what changes are tied to that id. The appropriate reject/accept commands can then be applied for those changes. Note that since this depends on inspecting the model and generating accept and reject commands, there will be no common implementation for these edits. Example object classes involved for a suggest acceptance or rejection may take a form similar to the following pseudo-code segment:

0000<tables id="TABLE-US-00009" num="00009"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><thead><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>/** Accepts the suggestion with the given id. */</entry></row><row><entry>class <b>AcceptEdit</b>(context) {</entry></row><row><entry>void <b>applyInternal</b>(args) {</entry></row><row><entry>var id = args.getId( );</entry></row><row><entry>for each suggested insert with that id:</entry></row><row><entry>this.applyCommand(new AcceptInsertSpacersMutation(start, end, id));</entry></row><row><entry>for each suggested delete with that id (iterating backwards):</entry></row><row><entry>this.applyCommand(new AcceptDeleteSpacersMutation(start, end, id));</entry></row><row><entry>// Similarly for styles and entities.</entry></row><row><entry>}</entry></row><row><entry>}</entry></row><row><entry>/** Rejects the suggestion with the given id. */</entry></row><row><entry>class <b>RejectEdit</b>(context) {</entry></row><row><entry>void <b>applyInternal</b>(args) {</entry></row><row><entry>var id = args.getId( );</entry></row><row><entry>for each suggested delete with that id:</entry></row><row><entry>this.applyCommand(new RejectDeleteSpacersMutation(start, end, id));</entry></row><row><entry>for each suggested insert with that id (iterating backwards):</entry></row><row><entry>this.applyCommand(new RejectInsertSpacersMutation(start, end, id));</entry></row><row><entry>// Similarly for styles and entities.</entry></row><row><entry>}</entry></row><row><entry>}</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0057In one implementation, suggestors can issue SuggestDeletes instead of regular Deletes so that the objects will be marked for deletion rather than actually deleted. However, if it is an object that was originally suggested by the same user, they are allowed to delete it. For example, if a user suggests the insertion of “teh cat”, they can go in and fix their typo. This will be accomplished by returning the appropriate command from getSuggestedCommand, based on the current context. In order to allow for more restricted semantics, a separate delete command can be created for suggestors to issue and then use validation to ensure that they cannot delete arbitrary objects.

0058In one implementation, the access control list (ACL) associated with the document can be checked for Suggestions. For example, users in a comment role already have the ability to apply commands to the model, so that they can apply commands which track the location of their comments. However, there are restrictions on the commands that can be applied, via the CommandPermissionChecker interface. With suggest changes, it should be straightforward to maintain that check, since there is a specific set of commands which the suggestors can issue: <ul id="ul0011" list-style="none"><li id="ul0011-0001" num="0000"><ul id="ul0012" list-style="none"><li id="ul0012-0001" num="0059">Suggestion commands, so they can make suggestions.</li><li id="ul0012-0002" num="0060">Reject commands, so they can undo suggestions (and possibly so they can reject their own edits).</li><li id="ul0012-0003" num="0061">The special delete command for deleting within suggestions.</li><li id="ul0012-0004" num="0062">MultiCommands and ReverseCommand (only containing other allowed commands).</li><li id="ul0012-0005" num="0063">NullCommand.</li></ul></li></ul>

0064This will prevent suggestors from making any actual modifications to the document. However, one could imagine a more restrictive ACL checking mechanism where suggestors may be prevented from affecting each other's suggestions. This more restrictive check is not currently done for comments—commentors are permitted to apply commands for anchoring comments regardless of who actually owns that comment. Doing this more restrictive check would be complicated, since it would require knowledge of who owns each suggestion id, which is not stored as part of the document model. Instead, these commands can be relied upon not being issued by the UI and the ACL checks can be maintained based on the role rather than the individual.

0065Suggestions from different users, accounts, and/or suggestion ids, can be merged. When in suggestions mode, not all edits produce commands with new suggestion ids. For example, typing a sentence in multiple edits should produce a single suggestion. These are called merged suggestions. Since suggestions have to be accepted or rejected wholesale, merging determines that granularity. An example suggestion merger may be illustrated in the following example:

00661. Type a character in suggestion mode: <ul id="ul0013" list-style="none"><li id="ul0013-0001" num="0000"><ul id="ul0014" list-style="none"><li id="ul0014-0001" num="0067">a. SuggestInsertSpacers(id: “a”, index: 5, spacers: “h”)</li></ul></li></ul>

00682. Type another character: <ul id="ul0015" list-style="none"><li id="ul0015-0001" num="0000"><ul id="ul0016" list-style="none"><li id="ul0016-0001" num="0069">a. SuggestInsertSpacers(id: “a”, index: 6, spacers: “i”) <ul id="ul0017" list-style="none"><li id="ul0017-0001" num="0070">i. Note that the id is the same. Both insertions are now part of the same suggestion.</li></ul></li></ul></li></ul>

00713. Accept the suggestion: <ul id="ul0018" list-style="none"><li id="ul0018-0001" num="0000"><ul id="ul0019" list-style="none"><li id="ul0019-0001" num="0072">a. AcceptInsertSpacers(id: “a”, start: 5, end: 6)</li></ul></li></ul>

00734. or reject the suggestion: <ul id="ul0020" list-style="none"><li id="ul0020-0001" num="0000"><ul id="ul0021" list-style="none"><li id="ul0021-0001" num="0074">a. RejectInsertSpacers(id: “a”, start: 5, end: 6)</li></ul></li></ul>

0075Before applying a command, the model can be inspected to determine which suggestion, if any, that command would merge with. If all the commands in an edit yield suggestion ids owned by the current user, then those suggestion ids can be used. Otherwise a new suggestion id can be created. By examining each id in this way, cases such as drag/drop and find can be supported and replaced across suggestions. The following examples illustrate the merging process:

0000<tables id="TABLE-US-00010" num="00010"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center" /><thead><row><entry namest="1" nameend="1" rowsep="1">TABLE 8</entry></row></thead><tbody valign="top"><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Example Merged Suggestions</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="4"><colspec colname="1" colwidth="77pt" align="left" /><colspec colname="2" colwidth="28pt" align="left" /><colspec colname="3" colwidth="28pt" align="left" /><colspec colname="4" colwidth="84pt" align="left" /><tbody valign="top"><row><entry /><entry>Merge</entry><entry /><entry>Result Suggestion</entry></row><row><entry>Commands in the Edit</entry><entry>id</entry><entry>Merge?</entry><entry>command</entry></row><row><entry namest="1" nameend="4" align="center" rowsep="1" /></row><row><entry>ApplyStyle within</entry><entry>A</entry><entry>Yes</entry><entry>SuggestApplyStyle(A)</entry></row><row><entry>suggestion A owned</entry></row><row><entry>by the current user</entry></row><row><entry>ApplyStyle within</entry><entry>Null</entry><entry>No</entry><entry>SuggestApplyStyle(new id)</entry></row><row><entry>regular text</entry></row><row><entry>ApplyStyle within</entry><entry>B</entry><entry>No</entry><entry>SuggestApplyStyle(new id)</entry></row><row><entry>suggestion B owned</entry></row><row><entry>by someone else</entry></row><row><entry>ApplyStyle across</entry><entry>Null</entry><entry>No</entry><entry>SuggestApplyStyle(new id)</entry></row><row><entry>suggestion A and</entry></row><row><entry>normal Text</entry></row><row><entry>1) ApplyStyle within</entry><entry>1) A</entry><entry>Yes</entry><entry>1) SuggestApplyStyle(A)</entry></row><row><entry>suggest A owned by</entry><entry>2) B</entry><entry /><entry>2) SuggestApplyStyle(B)</entry></row><row><entry>the current user</entry></row><row><entry>2) ApplyStyle within</entry></row><row><entry>suggest B owned by</entry></row><row><entry>the current user</entry></row><row><entry namest="1" nameend="4" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0076An issue with this approach is that it requires calculating the merged suggestion data as the original edits are applied to the ModelState copy. The merged suggestion data is calculated before each unwrapped command is applied, like inversion. The merged suggestion data would also need to be returned out of the original edit, like the undo commands are. A mechanism implementing a similar pattern as used for inversion can be adopted to calculate and return the merged suggestion data. For example, a command pre-processor may be used for suggestion merger and the pre-processor can be adapted for inversion as well.

0077Another example implementation of the suggestion document model is to process compound suggestions. Compound suggestions are suggestions that are created within other suggestions. For example, one user proposes the insertion of a sentence and a different user proposes the insertion of a word within that sentence. From the editor model perspective, compound suggestions look just like two regular suggestions: with two independent, unique suggestion ids. If there is no special UI for compounding, then these suggestions will simply show up as two distinct suggestions in comments, but as overlapping regions in the Collaborative document, much like overlapping Comments currently. Editors would be able to accept the innermost suggestion independent from the outermost. This would behave the same as if editors just went ahead and made the changes themselves. When a special UI is used for compounding suggestions, the relationship between the suggestion ids can be stored in a different place. For example, the current UI proposes showing compound suggestion within a single Comment, so this relationship can be stored in the Comments.

0078To determine whether a suggested edit should compound with another edit, a mechanism similar to determining merging above can be used. Given the set of suggestion ids for each command, a similar heuristic can be used: if all the ids are the same and the suggestion is not owned by the current user, then the specific suggestion id can be compounded.

0079Another example implementation of the suggestion document model is to process alternate suggestions. Alternates are suggestions which conflict which each other. For example, if one user proposes the deletion of a sentence while another user proposes the insertion of a word within that sentence. No special storage for alternates is provided. If a special UI for alternates is desired, the alternates can be detected on client-side by inspecting the model.

0080The document model can provide a UI to present suggestions to a user, e.g., a “view” mode. The document model under the “view” mode can read the state of the model suggestions and render appropriately. For example, it might determine that certain spacers are suggested insertions and render them in the collaborator color for the user who made the suggestion. Alternatively, it might determine that certain spacers are suggested deletions and render them both as struck through and with the appropriate color.

0081A suggestion may have data associated in comments and a comment will be shown for each suggestion. Comments will store the following basic data keyed off of the suggestion id:

00001. The user who made the suggestion. <br /> 2. The suggestion timestamp. <br /> 3. Some metadata explaining what the suggestion is. <br /> 4. Whether the suggestion has been accepted or rejected.

0082Users are allowed to comment on suggestions just like on regular Comments.

0083Additionally, suggestions will have controls allowing editors to accept/reject them. When this happens the comment thread will be annotated much like resolve and reopening Comments. Suggestion comments will contain some text explaining what the suggestion did. This will be derived from the metadata. The metadata will be structured and app-specific, although some may be generic. Examples of possible metadata can take a form similar to the following:

0084{type: insert, text: “hello” }

0085{type: delete, text: “hello” }

0086{type: style, key: “font_size”, value: 15}

0087Additional data can be stored to support compound suggestions. Copy and paste has additional consideration for what happens to the Comment data.

0088Another example implementation of the suggestion document model is to edit metadata. In order to generate the suggestion metadata the EditMetadata function can be invoked, which already serves this purpose for verbalizing Edits for accessibility. The EditMetadata gives details on what exactly the edit did. Class per Edit can be adopted, which takes the EditMetadata and produces the appropriate Comments metadata.

0089Regular edits in suggestions can be performed via the document model. Users in edit mode are allowed to affect anything, including suggestions. When an editor makes a change to a suggestion, that change is immediately committed—it is not compounded or created as a suggestion. In order to keep authorship trace of who's actually suggesting what, the comment may be annotated with some text explaining what the editor did. This can be done by creating the metadata for the edit and appending that to the comments thread for that suggestion.

0090Another example implementation of the suggestion document model is to filter Suggestions. <figref idref="DRAWINGS">FIG. 3</figref> provides example logic diagrams illustrating aspects of suggestion filtering procedures for a document model.

0091The document model O <b>301</b> can provide a mode where editors can filter out suggestions. These filters may be by user or suggestion type (insertions, styles, etc). To allow for flexibility in what exact filters can be supported, filtering can be allowed by applying any arbitrary set of commands and then transforming the client and server commands as they are transmitted back and forth. In order to create a filter, a command C <b>302</b> can be applied to the model O <b>301</b>. This yields a new model M <b>303</b>, which can be used for the client view and controller, and can allow the view and controller logic to remain the same regardless the filtering.

0092When creating the filter command C <b>302</b>, the inverse I(C) <b>304</b> may also be created. Additionally, two models <b>301</b> and <b>303</b> can be maintained: the original model <b>301</b> before filtering and the new model <b>303</b> post filtering. These two models can facilitate to create the appropriate inverses when transforming.

0093The filtering algorithm may work in a manner similar to the following (shown at <figref idref="DRAWINGS">FIG. 3(</figref><i>a</i>)):

00941. Generate command the filter command C <b>302</b>.

00952. Generate the filter inverse command I(C) <b>304</b> via regular inversion.

00963. Copy the model, keeping the original O <b>301</b> and the copy M <b>303</b>, which will be the new model.

00974. Apply command C <b>302</b> to the new model M <b>303</b>.

0098Any commands generated by the client controller can be applied directly to M. In order to send those commands to the server, they need to be transformed against I(C). In one example, the full algorithm can be performed as follows (shown at <figref idref="DRAWINGS">FIG. 3(</figref><i>b</i>)):

00991. Apply command X <b>305</b> to model M <b>303</b>. This yields the new model M′ <b>307</b>.

01002. Transform X <b>305</b> against I(C) <b>304</b> to yield X′ <b>309</b> and I(C)′ <b>310</b>.

01013. Apply X′ <b>309</b> to the original model O <b>301</b>. This yields the new original model O′ <b>312</b>.

01024. Send X′ <b>309</b> to the server.

01035. The new filter inverse command is now I(C)′ <b>310</b>.

01046. Generate the new filter command by inverting I(C)′ <b>310</b>.

0105Similarly, any commands received from the server can be applied directly to O <b>301</b>. In order to apply these clients to M <b>303</b>, they may to be transformed against C <b>302</b>. In one example, the full algorithm can be performed as follows (shown at <figref idref="DRAWINGS">FIG. 3(</figref><i>c</i>)):

01061. Apply command X <b>305</b> to original model O <b>301</b>. This yields the new original model O′ <b>312</b>.

01072. Transform X <b>305</b> against C <b>302</b> to yield X′ <b>309</b> and C′ <b>315</b>.

01083. Apply X′ <b>309</b> to the model M <b>303</b>. This yields the new model M′ <b>307</b>.

01094. The new filter command is now C′ <b>315</b>.

01105. Generate the new filter inverse command by inverting C′ <b>315</b>.

0111To unfilter the suggestion, I(C) <b>304</b> can be applied to the model M <b>303</b>, which makes it now be equivalent to the original model O <b>301</b>. Note that instead of applying the inverse, instead the model M <b>303</b> can be replaced with the original model O <b>301</b>. This means that I(C) <b>304</b> may not need to be applied, and therefore omit commands can be used instead of inverses. In this way, the transformation layer may not be given access to the original model. However, the original model may be maintained up-to-date, as it can be used for unfiltering.

0112Another example implementation of the suggestion document model is to implement server changes. Suggestions are only visible to people in edit or comment mode. View, preview and published modes may not show suggestions. This may require logic similar to filtering on the server-side. The server may know how to produce a model with suggestions stripped out and when that model should be used instead of the regular model. Examples where suggestions may be stripped out include:

01131. View, preview and published modes.

01142. Export.

01153. Indexable text and thumbnailing.

0116Note that for some of the above, such as export and indexable text, different logic can be implemented depending on the access level, to prevent the loss of functionality.

0117Suggested insertions are represented by marking a range of text with a suggested insertion id. Paragraph insertions are represented similarly—the newline marker is marked for insertion.

0000Below is an example pseudo-code segment of inserting “hello” as a tracked change in an eXtensible Markup Language (XML) format.

0000<tables id="TABLE-US-00011" num="00011"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="49pt" align="left" /><colspec colname="1" colwidth="168pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry><w:ins w:id=“0” w:author=“AUTHOR”</entry></row><row><entry /><entry>w:date=“2013-09-12T10:58:00Z”></entry></row><row><entry /><entry><w:r></entry></row><row><entry /><entry><w:t>hello</w:t></entry></row><row><entry /><entry></w:r></entry></row><row><entry /><entry></w:ins></entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0118The w:ins tag is used to indicate that its contents are tracked for insertion. The tag contains the id (w:id), author (w:author) and date (w:date) of the change. In the example above, the insertion contains a text run (w:r) with “hello” as its text (w:t). Below is an example pseudo-code segment of inserting a newline after “hello” as a tracked change in an XML format:

0000<tables id="TABLE-US-00012" num="00012"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="21pt" align="left" /><colspec colname="1" colwidth="196pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry><w:p w:rsidR=“009F5AAA” w:rsidRDefault=“009F5AAA”</entry></row><row><entry /><entry>w:rsidP=“009F5AAA”></entry></row><row><entry /><entry><w:pPr></entry></row><row><entry /><entry><w:rPr></entry></row><row><entry /><entry><w:ins w:id=“0” w:author=“AUTHOR”</entry></row><row><entry /><entry>w:date=“2013-09-12T10:58:00Z”></entry></row><row><entry /><entry></w:rPr></entry></row><row><entry /><entry></w:pPr></entry></row><row><entry /><entry><w:r></entry></row><row><entry /><entry><w:t>hello</w:t></entry></row><row><entry /><entry></w:r></entry></row><row><entry /><entry></w:p></entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0119The w:ins tag with no contents is used to indicate that the newline is tracked for insertion. The tag contains the id (w:id), author (w:author) and date (w:date) of the change.

0120Another example implementation of the suggestion document model is to process textual deletions. Suggested deletions are represented by marking a range of text with a suggested deletion id. Paragraph deletions are represented similarly—the newline marker is marked for deletion.

0121Below is an example pseudo-code segment of marking “hello” as a tracked deletion in an XML format

0000<tables id="TABLE-US-00013" num="00013"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="49pt" align="left" /><colspec colname="1" colwidth="168pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry><w:del w:id=“1” w:author=“AUTHOR”</entry></row><row><entry /><entry>w:date=“2013-09-12T10:58:00Z”></entry></row><row><entry /><entry><w:r w:rsidDel=“00996D0B”></entry></row><row><entry /><entry><w:delText>hello</w:delText></entry></row><row><entry /><entry></w:r></entry></row><row><entry /><entry></w:del></entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0122The w:del tag is used to indicate that its contents are tracked for deletion. The tag contains the id (w:id), author (w:author) and date (w:date) of the change. In the example above, the deletion contains a text run (w:r) with “hello” as its text (w:delText). Below is an example pseudo-code segment of marking the newline after “hello” as a tracked deletion in an XML format.

0000<tables id="TABLE-US-00014" num="00014"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="28pt" align="left" /><colspec colname="1" colwidth="189pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry><w:p w:rsidR=“009F5AAA” w:rsidDel=“00635749”</entry></row><row><entry /><entry>w:rsidRDefault=“00635749” w:rsidP=“009F5AAA”></entry></row><row><entry /><entry><w:pPr></entry></row><row><entry /><entry><w:rPr></entry></row><row><entry /><entry><w:del w:id=“1” w:author=“AUTHOR”</entry></row><row><entry /><entry>w:date=“2013-09-12T10:58:00Z”/></entry></row><row><entry /><entry></w:rPr></entry></row><row><entry /><entry></w:pPr></entry></row><row><entry /><entry><w:r></entry></row><row><entry /><entry><w:t>Deleted</w:t></entry></row><row><entry /><entry></w:r></entry></row><row><entry /><entry></w:p></entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0123The w:del tag with no contents is used to indicate that the newline is tracked for deletion. The tag contains the id (w:id), author (w:author) and date (w:date) of the change.

0124Suggested text styles are represented via a map from suggestion id to the properties being suggested. This map is applied to a range of text. Below is an example pseudo-code segment of applying “bold” as a tracked change to “hello” in an XML format. That word is already italicized.

0000<tables id="TABLE-US-00015" num="00015"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="28pt" align="left" /><colspec colname="1" colwidth="189pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry><w:r w:rsidR=“006B2B93” w:rsidRPr=“006B2B93”></entry></row><row><entry /><entry><w:rPr></entry></row><row><entry /><entry><w:b/></entry></row><row><entry /><entry><w:i/></entry></row><row><entry /><entry><w:rPrChange w:id=“2” w:author=“AUTHOR”</entry></row><row><entry /><entry>w:date=“2013-09-12T15:14:00Z”></entry></row><row><entry /><entry><w:rPr></entry></row><row><entry /><entry><w:i/></entry></row><row><entry /><entry></w:rPr></entry></row><row><entry /><entry></w:rPrChange></entry></row><row><entry /><entry></w:rPr></entry></row><row><entry /><entry><w:t>hello</w:t></entry></row><row><entry /><entry></w:r></entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0125There is an text run (w:r), with a run properties tag (w:rPr) and some text (w:t). The run properties contains the current properties, including the tracked change: bold (w:b) and italic (w:i). It also contains a run properties change tag (w:rPrChange) which contains the properties before the tracked style was applied, which is just italic (w:i). The properties change tag also contains the id (w:id), author (w:author) and date (w:date) of the change.

0126Suggested paragraph styles are represented via a map from suggestion id to the properties being suggested. This map is applied to the paragraph's newline. Below is an example pseudo-code segment of applying “center” as a tracked change to a paragraph containing “hello” in an XML format. The paragraph already had line spacing set on it.

0000<tables id="TABLE-US-00016" num="00016"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="21pt" align="left" /><colspec colname="1" colwidth="196pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry><w:p w:rsidR=“00ED223B” w:rsidRDefault=“001243D1”</entry></row><row><entry /><entry>w:rsidP=“001E67D7”></entry></row><row><entry /><entry><w:pPr></entry></row><row><entry /><entry><w:spacing w:line=“240” w:lineRule=“auto”/></entry></row><row><entry /><entry><w:jc w:val=“center”/></entry></row><row><entry /><entry><w:pPrChange w:id=“4” w:author=“AUTHOR”</entry></row><row><entry /><entry>w:date=“2013-09-13T16:39:00Z”></entry></row><row><entry /><entry><w:pPr></entry></row><row><entry /><entry><w:spacing w:line=“240” w:lineRule=“auto”/></entry></row><row><entry /><entry></w:pPr></entry></row><row><entry /><entry></w:pPrChange></entry></row><row><entry /><entry></w:pPr></entry></row><row><entry /><entry><w:r></entry></row><row><entry /><entry><w:t>hello</w:t></entry></row><row><entry /><entry></w:r></entry></row><row><entry /><entry></w:p></entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0127There is a paragraph run (w:p), with a paragraph properties tag (w:pPr) and a text run (w:r). The paragraph properties contain the current properties, including the tracked change: line spacing (w:spacing) and alignment (w:jc). It also contains a run properties change tag (w:pPrChange) which contains the properties before the tracked style was applied, which is just line spacing (w:spacing). The properties change tag also contains the id (w:id), author (w:author) and date (w:date) of the change.

0128Suggested list styles are represented via a map from suggestion id to the properties being suggested. This map is applied to the paragraph's newline. Suggested changes that affect the list entity are also represented via a map from suggestion id to properties. This map is applied at the list entity.

0129Below is an example pseudo-code segment of adding the paragraph containing “hello” to a list as a tracked change in an XML format.

0000<tables id="TABLE-US-00017" num="00017"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="21pt" align="left" /><colspec colname="1" colwidth="196pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry><w:p w:rsidR=“006F3E3C” w:rsidRDefault=“006F3E3C”</entry></row><row><entry /><entry>w:rsidP=“006F3E3C”></entry></row><row><entry /><entry><w:pPr></entry></row><row><entry /><entry><w:pStyle w:val=“ListParagraph”/></entry></row><row><entry /><entry><w:numPr></entry></row><row><entry /><entry><w:ilvl w:val=“0”/></entry></row><row><entry /><entry><w:numId w:val=“3”/></entry></row><row><entry /><entry></w:numPr></entry></row><row><entry /><entry><w:pPrChange w:id=“6” w:author=“AUTHOR”</entry></row><row><entry /><entry>w:date=“2013-09-13T16:39:00Z”></entry></row><row><entry /><entry><w:pPr/></entry></row><row><entry /><entry></w:pPrChange></entry></row><row><entry /><entry></w:pPr></entry></row><row><entry /><entry><w:r></entry></row><row><entry /><entry><w:t>five</w:t></entry></row><row><entry /><entry></w:r></entry></row><row><entry /><entry></w:p></entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0130There is a paragraph run (w:p), with a paragraph properties tag (w:pPr) and a text run (w:r). The paragraph properties contain the current properties, including the tracked change: applying the “ListParagraph” named style (w:pStyle), and adding the paragraph to the list id “3” (w:numId) at nesting level “0” (w:ilvl). It also contains a run properties change tag (w:pPrChange) which contains the properties before the tracked style was applied, which is empty (w:pPr/). The properties change tag also contains the id (w:id), author (w:author) and date (w:date) of the change.

0131Another embodiment described herein include systems and methods to merge suggested edits within a collaboratively edited document. A document editor may allow users to make edits as suggestions, which may be tracked and are accepted or rejected before being incorporated into the document. These suggestions exist as distinct changes to the document which can be independently accepted and rejected. As a user makes individual actions to edit the document, such as typing characters, it is not desirable for those actions to each individually produce a separate suggestion. In particular, when a reviewer of a document opens the document and creates suggested edits to the document, not all edits should produce commands with new suggestion identifiers. For example, typing a sentence in multiple edits should produce a single suggestion. These are called merged suggestions because the single suggestion arose from multiple edits or mutations. Since suggestions have to be accepted or rejected wholesale, merging determines the granularity for suggestions.

0132The systems and methods of the sixth exemplary embodiment of the present disclosure determine whether a current change to the model should be merged with an existing suggestion, or whether such a change should create a new suggestion. The systems and methods of the present disclosure are generic enough to work well for any arbitrary change or collection of changes to a document model. Existing systems do not take the entire document model into account and do not maintain consistency and user intent.

0133<figref idref="DRAWINGS">FIGS. 4A-4B</figref> show an example logic flow diagram <b>400</b> illustrating aspects of merging suggested edits. Starting at <b>401</b>, in response to a received editing suggestion (e.g., <b>202</b> in <figref idref="DRAWINGS">FIG. 2A</figref>), a document editor on a server or a user device may determine whether to merge the received editing suggestion with existing editing suggestions, or to create a new suggestion. The document editor may determine one or more mutations associated with the editing suggestion. For example, changes to a document model may be described via a series of incremental atomic mutations. In a document editing environment, such as a text editor, mutations may include insert characters, deleting characters, applying styles, or any other type of change that may be made to a text document. A single suggested edit to the document may result in multiple mutations being applied to the model.

0134For example, the suggested edit may include adding a word or a phrase including multiple character insertions. In another example, the suggested edit may include replacing an existing phrase with a different phrase. Such a suggested edit would include multiple character deletions and multiple character insertion. In yet another example, the suggested edit may include inserting one or more characters, and applying a style change to the inserted characters. In each example, the suggested edit includes multiple mutations to the document. It is generally desirable, as mutations are received sequentially, to determine whether a current mutation should be merged with a previous mutation as part of a single edit, or whether a current mutation should be characterized as part of a new edit.

0135Systems and methods are provided herein for determining whether to merge a current change to a document with an existing suggested edit, or whether to generate a new suggested edit based on the current change. A document editor has logic for determining what mutations to apply to the document based on the user's action and the current state of the document editor.

0136The document editor may then define a function for each mutation, at <b>402</b>. The function determines which suggestions a mutation may merge with. This function may be defined for the particular mutations and document models in the editing application. As an example, in a document editor, the mutation to insert characters may merge with any suggested text that occurs before, after, or around the inserted text.

0137Additionally, this function may determine a merge priority for the mutation. In an example, mutations are sorted in an order of priority, so that more drastic changes to the document may be considered before less drastic changes. For example, if a suggested edit includes both insertion of text and application of a style, the location of the insert may be a more likely candidate for merging than the location of the style application. In this case, the insert mutation may be prioritized over the style application mutation.

0138As mutations are being applied to the model, the function is run to identify a list of any potential merging suggestions and priorities, at <b>403</b>. Then, the document model may determine whether any mutation needs to be filtered from the list, at <b>405</b>. For example, any suggestions that are not owned by the current user may be removed or filtered from the list, at <b>406</b>. Filtering the list in this manner ensures that suggestions made by a current user do not merge with suggestions made by other users, and instead create new suggestions owned by the current user. Alternatively, the function may include one or more filters so that any potential merging suggestions priorities in the list identified by the function are only associated with the current user and not other users.

0139In general, in determining whether to merge suggested edits, the insertion and deletion of regular text has the highest priority. The suggestions that insertions and deletions of text may merge with are defined according to the heuristics above. Specifically, insertions return suggestions to merge for inserts or deletes before or after the insert location. Deletions return suggestions to merge for any deletions or insertions before, after or inside the deleted range. Style related changes have secondary priority. This includes text and paragraph styles, modifications to lists and links, for example. These edits merge only if the styled range is fully contained within a deletion or insertion. They also merge with other suggested styles if the range is the same or if inside other styles and affecting the same properties. Deletion of secondary text has secondary priority and merges with other deletions of the same text. Secondary text is text outside the main body of the document, which is generally related to the document, such as headers, footers, footnotes, for example. Insertion of secondary text has the lowest priority and returns no merge suggestions. This text will always produce a new suggestion (such as in the case of headers and footers) or it is related to primary text, such as footnotes, and therefore will use the primary text merging heuristics.

0140In determining how to merge suggested edits, the method of the exemplary embodiment may include a framework of categories defining the priority associated with merges that fall within the category. Each suggestion can be assigned a merge suggestion identifier that identifies the suggested action as well as the priority category of the suggested change. These priority categories are divided into example categories of primary, secondary and neutral priority merges depending on the priority with which the suggested edit is merged.

0141In an example, the primary priority category includes suggestions such as insertions and deletions of non-section spacers. Secondary priority category suggestions include applying a different style to document text; tethering, updating or deleting an entity; or deleting a section. Neutral priority category suggestions include inserting a section, adding an entity and various other suggestion commands.

0142Continuing on with <figref idref="DRAWINGS">FIG. 4B</figref>, after the filtered list is determined at <b>407</b>, all potential merging suggestions of the highest existing priority are examined at <b>408</b>, to determine whether merging should happen at <b>410</b>. If all mutations at that priority have matching suggestions, then merging happens. Otherwise, merging should not happen and a new suggestion is created at <b>411</b>.

0143If merging happens, then the system and method described herein determine which suggestion of the potential suggestions in the filtered list should be used to merge at <b>415</b>. A number of ways may determine which suggestion should be used to merge, and the examples described herein are for illustrative example only.

0144In one example, suggestions that are more common may be preferred to be used to merge. One particular way is to prefer more common suggestions. Several steps may be used to implement this. First, a histogram indicative of how often each suggestion occurs is created. Second, the mutations are considered from most common to least common, and any mutations that may merge with a particular suggestion may be used. Third, for any mutation that does not have a potential merging suggestion, then the most commonly occurring suggestion with the highest priority is used. Upon determining which suggestion to be used to merge, the editing suggestions may be merged at <b>416</b>.

0145As described herein, one goal of the present disclosure is to define a mechanism to merge suggestions together across different edits, and to determine a mechanism of gathering this merge data as the suggested edits are applied to the document model. The below example provides an implementation of the system when two characters being typed, and the system determines that the two characters belong together in the same suggestion:

00001. Type a character in suggestion mode:

0146a. SuggestInsertSpacers(id: “a”, index: 5, spacers: “h”)

00002. Type another character:

0147a. SuggestInsertSpacers(id: “a”, index: 6, spacers: “i”) <ul id="ul0022" list-style="none"><li id="ul0022-0001" num="0000"><ul id="ul0023" list-style="none"><li id="ul0023-0001" num="0148">i. Note that the id is the same. Both insertions are now part of the same suggestion. <br /> 3. Accept the suggestion: </li></ul></li></ul>

0149a. AcceptInsertSpacers(id: “a”, start: 5, end: 6)

00004. Or reject the suggestion: <br /> a. RejectInsertSpacers(id: “a”, start: 5, end: 6)

0150Before applying a command, the document model may determine which suggestion, if any, that command would merge with (e.g., at <b>415</b> in <figref idref="DRAWINGS">FIG. 4B</figref>). If all the commands in an edit are associated with suggestion identifiers that are owned by the current user, then those suggestion identifiers may be used. Otherwise, a new suggestion identifier may be generated and used. By doing this per identifier, changes including cut/paste or find/replace may be efficiently implemented.

0151In another example, based on priority categories assigned to suggested edits, the basic heuristics include to complete the merging of suggestions when typing after/before/inside an insertion, typing after/before/inside a deletion, typing before a newline with a suggested text style, deleting before/after/inside/around a deletion, deleting before/after/inside/around an insertion, entering inside a deletion, entering after/before/inside an insertion, changing styles inside an insertion, changing styles inside a deletion, changing styles applied to the exact same range as another style, changing styles inside other styles, if affecting the same properties, or altering the text styles applied to a newline after a suggested insertion. Suggestions are not merged when typing after/before/inside styles, deleting before/after/inside/around styles, entering before/after delete, entering before/after replace, changing styles before/after an insertion, changing styles before/after a deletion, changing styles overlapping insertions, changing styles overlapping deletions, or altering the styles inside, before, after, or overlapping with other styles that are not within the same range.

0152There are two special cases to consider around newlines and text styles: typing before a newline with a suggested text style and text styles applied to a newline after a suggested insertion. These special cases are implemented in a similar manner as described above: the insertion merging logic checks whether the insertion is before a newline with a suggested text style and the style merging logic checks whether the style is applied to a newline after a suggested insertion. These cases produce a solution for several issues. In one example, starting an empty paragraph with a non-suggested newline is not problematic. In a second example, pressing “bold” while suggesting an edit applies a suggested style to the newline. In a third example, typing a character inserts a character before the newline. The suggestion to insert the character merges with the previous one.

0153<figref idref="DRAWINGS">FIG. 5</figref> shows a flow chart of a method <b>500</b> used by the review manager <b>102</b> to use the priority categories to determine the order in which to merge suggestions within a document. The method <b>500</b> includes the steps of determining if there are any primary category suggestions (decision block <b>502</b>) and determining if there are any secondary category ID commands (decision block <b>506</b>) and merging suggested edits appropriately based on these outcomes. If there are primary priority category suggestions, these merges are executed (step <b>504</b>). If there are secondary priority category merges, these are executed (step <b>508</b>). Alternatively, if there are no secondary priority category suggestions, no further merges are made (step <b>510</b>).

0154Merging suggested edits including insertions occur according to several rules. In one implementation, pressing ENTER in comment mode inserts separate comments for each newline. Typing multiple paragraphs result in a merged edit encompassing the suggested paragraphs.

0155In some cases multiple users may suggest various edits to a text, including suggestions which are conflicting. In cases of conflicting style suggestions, the suggestions should be merged into a single suggestion. In some implementations, editors may have the capability to undo, accept or reject the suggested conflicting edits and using these capabilities may cause all conflicting suggestions to disappear.

0156Suggested edits to paragraph styles are handled as separate from edits to the text of the paragraph. In one example, changing a suggested heading does not change the styles of the paragraph entities. In another example, the merge edits system is equipped to handle issues in which the suggestion to “add entity” never merges. In a third example, changing a suggested link does not always work.

0157In general, the method of determining whether to merge suggested edits is accomplished according to a series of principles. Single actions are always displayed as single suggestions. Merges are executed for style changes fully within insertions, style changes with the same entity selected, typing a continuous range of suggested text, typing inside of inserted text, and for objects which can be merged, including inline images, equations, autotext, footnotes, and bookmarks. In some insertions of tables, positioned images, headers, footers and tables of contents may not be merged with other edits.

0158The approach described herein has several advantages. First, suggestions made by a particular user may only merge with suggestions made by the same user. Second, a single user action would never create more than one suggestion. Third, consistency is maintained between mutations within an edit. In other words, all mutations either merge with existing suggestions or are assigned to a new suggestion. Fourth, consistency is maintained when a single edit affects multiple existing suggestions. By favoring suggestions that each mutation prefers to merge with, edits which affect multiple suggestions have their constituent mutations merge with the suggestions that they individually affect.

0159Another embodiments described herein include projections applied to a document model. Client systems or user devices may have projections applied to their document models. For example, projections may be used to strip out certain types of content or to anonymize certain parts of the document. Projections may be described in terms of mutations that are applied to the model. When a projection is applied to a model, mutations are produced which when applied generate the model under the projection. For example, a projection which strips out tables would produce a delete table mutation for each table, resulting a model with no tables.

0160In order to broadcast a mutation to a collaborator whose model is under a projection, that mutation should be transformed against the mutations which describe the projection. For example, broadcasting an insert text mutation to a model with some text filtered out requires transforming the insert text against delete text mutations corresponding to the filtered out text.

0161Additionally, some mutations should be entirely omitted when broadcasting under a projection. For example, if a projection removes tables from a document, then a mutation to create a new table should not be sent to clients with that projection. For individual mutations, this is simple to implement. In particular, those mutations to omit should be identified for certain projections, and the identified mutations should not be broadcasted.

0162However, omitting certain mutations may affect future mutations, since future mutations may rely on or assume the presence of the omitted mutations. For example, if two mutations are being broadcast (e.g., [insert text at index <b>100</b>, insert text at index <b>200</b>]), the second insertion may assume the first insertion was implemented. In this manner if the first insertion is omitted, and the second insertion is naively broadcasted, then the broadcasted insertion is at the wrong index.

0163To solve this, omit transform mutations are defined. Omit transform mutations are mutations against which future mutations need to be transformed to account for differing semantics due to the omission. In the example above, the omit transform mutation for [insert text at <b>100</b>] is [delete text at <b>100</b>]. By transforming the [insert text at <b>200</b>] against the delete mutation, the [insert text at <b>200</b>] is shifted back and will be at the right index. In this manner, the omit transform mutation allows for future mutations to take into account a projection of a document, and thus to be appropriately adjusted accordingly.

0164<figref idref="DRAWINGS">FIG. 6</figref> shows an example logic flow diagram <b>600</b> illustrating aspects of defining an omit transform mutation for a document model. The technique may be summarized as below.

0165Initialize an empty set of mutations R, at <b>601</b>.

0166Generate the set of mutations S used to apply the projection to the current model, at <b>602</b>.

0167For each mutation M in the set of mutations to broadcast: <ul id="ul0024" list-style="none"><li id="ul0024-0001" num="0000"><ul id="ul0025" list-style="none"><li id="ul0025-0001" num="0168">Generate M′ and S′ by transforming M against S at <b>603</b>.</li><li id="ul0025-0002" num="0169">If M′ should be omitted due to the projection at <b>605</b>: <ul id="ul0026" list-style="none"><li id="ul0026-0001" num="0170">Generate the omit transform mutation O for C′ at <b>606</b>.</li><li id="ul0026-0002" num="0171">Add O to S′ at <b>607</b>.</li></ul></li><li id="ul0025-0003" num="0172">Else: <ul id="ul0027" list-style="none"><li id="ul0027-0001" num="0173">Add C′ to R at <b>608</b>.</li></ul></li><li id="ul0025-0004" num="0174">Set S′ as the new S at <b>609</b>.</li></ul></li></ul>

0175R is the result.

0176To summarize, when defining a projection, one may define (1) given a model which mutations apply the projection and (2) which mutations should be omitted and what the omit transform mutations are for those. Once those are defined, then the systems and methods of the present disclosure may be used to collaborative broadcast mutations under the projection.

0177There are a few advantages to solving the problem in this manner. First, the present disclosure allows projections to be entirely applied server-side, allowing enforcing that clients to be under certain projections. Second, the present disclosure makes use of existing operational transformation semantics in real-time collaboration applications.

0178In an example, projections are applied to filter suggested changes from a version of the document available to viewers. The present disclosure enables for changes to the document to be applied appropriately so that viewers of a document are presented with and up-to-date version of the document. To remove the display of the suggested changes and comments from the “view mode” of the document that is shown viewers, the application engine that implements the view mode of a document may involve any combination of the following steps.

0179The concept of a projection may be applied to a document model. An example pseudo-code segment illustrating an object class of a projection may take a form similar to the following:

0000<tables id="TABLE-US-00018" num="00018"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><thead><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>public enum <b>Projection </b>{</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="203pt" align="left" /><tbody valign="top"><row><entry /><entry>// Represents the model as is.</entry></row><row><entry /><entry><b>FULL,</b></entry></row><row><entry /><entry>// Represents the model with suggestions filtered out.</entry></row><row><entry /><entry><b>WITHOUT</b>_—<b>SUGGESTIONS</b></entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><tbody valign="top"><row><entry>}</entry></row><row><entry>public interface Model<T extends Model<T>> {</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="203pt" align="left" /><tbody valign="top"><row><entry /><entry>...</entry></row><row><entry /><entry>/** Returns a deep copy of this object. Same as</entry></row><row><entry /><entry>copy(Projection.FULL) */</entry></row><row><entry /><entry>T copy( );</entry></row><row><entry /><entry>/** Returns a deep copy of this object with the given projection. */</entry></row><row><entry /><entry><b>T copy</b>(<b>Projection p</b>)<b>;</b></entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><tbody valign="top"><row><entry>}</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0180In order to use these Projections, the ModelState will be modified as follows:

0000<tables id="TABLE-US-00019" num="00019"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="203pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>public interface ModelState<T extends Model<T>> {</entry></row><row><entry /><entry>...</entry></row><row><entry /><entry>/** Returns a model at the specified revision. Includes suggestions. */</entry></row><row><entry /><entry>T getModel(int revision, <b>Projection projection</b>) throws IOException;</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><tbody valign="top"><row><entry>}</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0181Usages will be replaced with the appropriate Projection depending on whether suggestions should always be filtered.

0182Access control list (ACL)-Based Filtering may be used. Some usages of suggestions will require contextual filtering based on whether the user has view or edit access to the document. To achieve this, a factory may be used to construct the right. An example pseudo-code segment illustrating an object class of an ACL-based filtering may take a form similar to the following:

0000Projection based on the AccessLevel:

0000<tables id="TABLE-US-00020" num="00020"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><thead><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>public enum Projection {</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="203pt" align="left" /><tbody valign="top"><row><entry /><entry>// Represents the model as is.</entry></row><row><entry /><entry>FULL,</entry></row><row><entry /><entry>// Represents the model with suggestions filtered out.</entry></row><row><entry /><entry>WITHOUT_SUGGESTIONS</entry></row><row><entry /><entry><b>public static Projection fromAccessLevel</b>(<b>AccessLevel accessLevel</b>)<b>;</b></entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><tbody valign="top"><row><entry>}</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0183The factory will return Projection.FULL for editors and reviewers (commenters) and Projection. WITHOUT_SUGGESTIONS for viewers. Additionally, a default value may be injected for Projection, which will use the factory to return the right projection for the user's AccessLevel.

0184In another embodiment, change Filtering may be implemented. In some implementations, contextually filtering the model based on AccessLevel may not be sufficient. Usages which load or transmit changes may also need to be filtered. The following steps may be used to filter commands for viewers:

01851. Initialize an empty set of commands R.

01862. Generate the set of commands S used to filter out the current model suggestions.

01873. For each command C in the change: <ul id="ul0028" list-style="none"><li id="ul0028-0001" num="0000"><ul id="ul0029" list-style="none"><li id="ul0029-0001" num="0188">a. Generate C′ and S′ by transforming C against S.</li><li id="ul0029-0002" num="0189">b. If C′ is a suggestion command: <ul id="ul0030" list-style="none"><li id="ul0030-0001" num="0190">i. Generate the omit command O for C′.</li><li id="ul0030-0002" num="0191">ii. Add 0 to S′.</li></ul></li><li id="ul0029-0003" num="0192">c. Else: <ul id="ul0031" list-style="none"><li id="ul0031-0001" num="0193">i. Add C′ to R.</li></ul></li><li id="ul0029-0004" num="0194">d. Set S′ as the new S.</li></ul></li></ul>

01954. R is the result.

0196In some implementations, the following method may be used to generate the filter commands (which may be an example pseudo-code segment illustrating step <b>2</b> above).

0000<tables id="TABLE-US-00021" num="00021"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><thead><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>public interface Model<T extends Model<T>> {</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="203pt" align="left" /><tbody valign="top"><row><entry /><entry>...</entry></row><row><entry /><entry>/** Returns a deep copy of this object. Same as</entry></row><row><entry /><entry>copy(Projection.FULL) */</entry></row><row><entry /><entry>T copy( );</entry></row><row><entry /><entry>/** Returns a deep copy of this object with the given projection. */</entry></row><row><entry /><entry>T copy (Projection p);</entry></row><row><entry /><entry>/**</entry></row><row><entry /><entry>* Returns the set of commands that if applied to this model would</entry></row><row><entry /><entry>yield</entry></row><row><entry /><entry>* given projection. In other words, for some model M and projection</entry></row><row><entry /><entry>P:</entry></row><row><entry /><entry>* M.getProjectionCommands(P).apply(M) <img file="US2015370769A1_D0001.tif" />  M.copy(P)</entry></row><row><entry /><entry>*/</entry></row><row><entry /><entry><b>Iterable<Command<T>> getProjectionCommands</b>(<b>Projection p</b>)<b>;</b></entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><tbody valign="top"><row><entry>}</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0197The implementation for Projection.FULL may always return an empty list. Implementations that do not support suggestions, such as Projection. WITHOUT_SUGGESTIONS, may simply return an empty list. In some implementations, the collaborative document editing application may implement Projection. WITHOUT_SUGGESTIONS by producing the set of commands to reject all suggestions currently in the model.

0198In some implementations, the following method may be used to produce omit commands (which may be an example pseudo-code segment illustrating step 3.b.i. above).

0000<tables id="TABLE-US-00022" num="00022"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><thead><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>public class <b>ProjectionDetails</b><T extends Model<T>> {</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="203pt" align="left" /><tbody valign="top"><row><entry /><entry>...</entry></row><row><entry /><entry>/** Whether the Command is included in the Projection. If this is</entry></row><row><entry /><entry>false,</entry></row><row><entry /><entry>* then applying a Command to a Model with the Projection will result</entry></row><row><entry /><entry>in the 3 of 9</entry></row><row><entry /><entry>* Model no longer conforming to the Projection.</entry></row><row><entry /><entry>*/</entry></row><row><entry /><entry><b>boolean isIncludedInProjection</b>( )<b>;</b></entry></row><row><entry /><entry>/**</entry></row><row><entry /><entry>* If the Command is not included in the Projection, this is the</entry></row><row><entry /><entry>Command</entry></row><row><entry /><entry>* that should be used to transform future commands due to this</entry></row><row><entry /><entry>command</entry></row><row><entry /><entry>* being omitted.</entry></row><row><entry /><entry>*/</entry></row><row><entry /><entry><b>Command<T> getOmitTransformCommand</b>( )<b>;</b></entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><tbody valign="top"><row><entry>}</entry></row><row><entry>public interface Command<T extends Model<T>> {</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="203pt" align="left" /><tbody valign="top"><row><entry /><entry>...</entry></row><row><entry /><entry>/**</entry></row><row><entry /><entry>* Gets the details on how this Command behaves under the given</entry></row><row><entry /><entry>Projection.</entry></row><row><entry /><entry>*/</entry></row><row><entry /><entry>P<b>rojectionDetails getProjectionDetails</b>(<b>Projection p</b>)<b>;</b></entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><tbody valign="top"><row><entry>}</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables><br /> This may be implemented as follows: <ul id="ul0032" list-style="none"><li id="ul0032-0001" num="0000"><ul id="ul0033" list-style="none"><li id="ul0033-0001" num="0199">1. AbstractCommand will return null.</li><li id="ul0033-0002" num="0200">2. WrapperCommands will error on the calls to these, since the details may not be calculated without unwrapping.</li><li id="ul0033-0003" num="0201">3. Suggestion commands will return the appropriate omit command. For example: <ul id="ul0034" list-style="none"><li id="ul0034-0001" num="0202">a. InsertSuggestedSpacers will return a DeleteSpacers for the inserted range.</li><li id="ul0034-0002" num="0203">b. MarkSpacersForDeletion will return an UnmarkSpacersForDeletion for the same range. <br /> This may be implemented in ModelStateImpl and used to transform the commands in changes before the changes are broadcast, as well as to filter the LoadResult before it is returned. This may include the following change to an API change: </li></ul></li></ul></li></ul>

0000<tables id="TABLE-US-00023" num="00023"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><thead><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>public interface ModelState<T extends Model<T>> {</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="203pt" align="left" /><tbody valign="top"><row><entry /><entry>...</entry></row><row><entry /><entry>/**</entry></row><row><entry /><entry>* Returns a model at the specified revision with all suggestions</entry></row><row><entry /><entry>filtered</entry></row><row><entry /><entry>* out.</entry></row><row><entry /><entry>*/</entry></row><row><entry /><entry>LoadResult<T> load(int revision, <b>Projection projection</b>) throws</entry></row><row><entry /><entry>IOException;</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><tbody valign="top"><row><entry>}</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0204In some implementations, commands may be unwrapped before the process, since each command has to be treated differently depending on whether it's a suggestion command or not. In some implementations, the collaborative document editor may not use a validating transformer for this process, since the model at each step is not necessarily valid. In some implementations, collaborator selection Changes use the model at the Change's revision, and saveable Changes use the model at the revision prior.

0205In some implementations, the present disclosure relies on transformation in order to filter out commands before they are sent to viewers. One concern with this approach is performance. In particular, transformation may slow and may be performed on every save if a document has suggestions and viewers. To address this concern, a performance pass may be done on the transformers. However, since the general approach is n2, the gains may be limited. To avoid worst-case scenarios, the amount of filter commands that are transformed against may be limited, and broadcasting to viewers may be stopped if that limit is reached.

0206Another concern is that broadcasting may be currently done behind the ModelState lock. To address this, a separate lock may be used, where the separate lock orders broadcasts, but does not block other operations on the ModelState.

0207In another embodiment, identifying Session AccessLevel may be implemented. In some implementations, in order to determine which sessions need browserchannel filtering, the collaborative document editor application should have information indicative of which sessions are viewer sessions. It may not be sufficient to determine the user's AccessLevel, since the user's level of access may not necessarily match the client's effective access. For example, an editor may select an option to view the document in a view mode or in a reviewer mode rather than an editor mode, or a reviewer may select an option to view the document in a view mode rather than in a reviewer mode. To implement this, a session creation function AppSessionManager may be modified to also receive the session's AccessLevel. There may also be a mechanism to identify which sessions have a given AccessLevel.

0208In some implementations, in order to populate the AccessLevel, a function SessionInitiationInterceptor may fetch the current user's AccessLevel the session is created. If there are @SessionInitiator endpoints which initiate sessions at a forced lower access level (like/view), then those may be manually overridden. To manually override, a parameter may be added to @SessionInitiator with the optional AccessLevel to use instead of the effective one. Alternatively, the endpoints which result in forced lower access level may be removed, thereby forcing the client to refresh if they can access.

0209In another embodiment, usages may be categorized according to the following: Usages of Projection. WITHOUT_SUGGESTIONS: <ul id="ul0035" list-style="none"><li id="ul0035-0001" num="0000"><ul id="ul0036" list-style="none"><li id="ul0036-0001" num="0210">1. Thumbnailing. This should be handled generically via ModelThumbnailer.</li><li id="ul0036-0002" num="0211">2. Indexing. This should be handled generically via Indexer.</li><li id="ul0036-0003" num="0212">3. Social markup. This should be handled generically via Snippeter.</li><li id="ul0036-0004" num="0213">4. Crawler.</li><li id="ul0036-0005" num="0214">5. Document copies.</li><li id="ul0036-0006" num="0215">6. Preview and publish.</li></ul></li></ul>

Usages of Projection.FULL:

0000<ul id="ul0037" list-style="none"><li id="ul0037-0001" num="0000"><ul id="ul0038" list-style="none"><li id="ul0038-0001" num="0216">1. Legal discovery and AbuselAm.</li><li id="ul0038-0002" num="0217">2. Flumes and debug endpoints.</li><li id="ul0038-0003" num="0218">3. Other internal usages: checking for legacy comments, validation, spellcheck, transformation. <br /> Usages of Projection.fromAccessLevel: </li><li id="ul0038-0004" num="0219">1. Endpoints only available to editors: Link editing, Revert, Maestro RPCs, Revision history</li><li id="ul0038-0005" num="0220">2. Offline sync: ModelAction</li><li id="ul0038-0006" num="0221">3. Export. This may be handled generically via Exporter.</li></ul></li></ul>

0222Some usages may be based on the effective access for the current session. Mechanisms may be in place to ensure that the session and the access level are kept consistent or handle these separately:

02231. SessionInitiator actions and their effective access: <ul id="ul0039" list-style="none"><li id="ul0039-0001" num="0000"><ul id="ul0040" list-style="none"><li id="ul0040-0001" num="0224">a. fromAccessLevel: Edit, Comment</li><li id="ul0040-0002" num="0225">b. WITHOUT_SUGGESTIONS: View, NativeWebView</li></ul></li></ul>

02262. Usages which require the effective access for the session: <ul id="ul0041" list-style="none"><li id="ul0041-0001" num="0000"><ul id="ul0042" list-style="none"><li id="ul0042-0001" num="0227">a. Initial load model fonts.</li><li id="ul0042-0002" num="0228">b. Print and print preview.</li><li id="ul0042-0003" num="0229">c. Model catchup requests.</li><li id="ul0042-0004" num="0230">d. Command broadcasting.</li></ul></li></ul>

0231Below are some examples of the techniques described herein in practice:

0000<tables id="TABLE-US-00024" num="00024"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><thead><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry><b>Setup:</b></entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="203pt" align="left" /><tbody valign="top"><row><entry /><entry>Model and indices:</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="28pt" align="left" /><colspec colname="1" colwidth="189pt" align="left" /><tbody valign="top"><row><entry /><entry>Hello_awesome_world // “awesome_” is a suggestion</entry></row><row><entry /><entry>0123456789012345678</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="203pt" align="left" /><tbody valign="top"><row><entry /><entry>Viewer model and indices:</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="28pt" align="left" /><colspec colname="1" colwidth="189pt" align="left" /><tbody valign="top"><row><entry /><entry>Hello_world // Viewer doesn't see the suggestion.</entry></row><row><entry /><entry>01234567890</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><tbody valign="top"><row><entry><b>Example #1: Applying a regular command after a suggestion.</b></entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="203pt" align="left" /><tbody valign="top"><row><entry /><entry>Change:</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="28pt" align="left" /><colspec colname="1" colwidth="189pt" align="left" /><tbody valign="top"><row><entry /><entry>[Insert “!” @ 19] // Insert “!” after “world”</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="203pt" align="left" /><tbody valign="top"><row><entry /><entry>Steps:</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="offset" colwidth="28pt" align="left" /><colspec colname="1" colwidth="14pt" align="left" /><colspec colname="2" colwidth="175pt" align="left" /><tbody valign="top"><row><entry /><entry>1.</entry><entry>R = [ ]</entry></row><row><entry /><entry>2.</entry><entry>S = [Delete 6-13]</entry></row><row><entry /><entry>3.</entry><entry>Process the first command:</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="offset" colwidth="56pt" align="left" /><colspec colname="1" colwidth="14pt" align="left" /><colspec colname="2" colwidth="147pt" align="left" /><tbody valign="top"><row><entry /><entry>a.</entry><entry>C' = [Insert “!” @ 11]</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="70pt" align="left" /><colspec colname="1" colwidth="147pt" align="left" /><tbody valign="top"><row><entry /><entry>S' = [Delete 6-13]</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="offset" colwidth="56pt" align="left" /><colspec colname="1" colwidth="14pt" align="left" /><colspec colname="2" colwidth="147pt" align="left" /><tbody valign="top"><row><entry /><entry>b.</entry><entry>R = [Insert “!” @11] // C' isn't a suggestion, so</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="70pt" align="left" /><colspec colname="1" colwidth="147pt" align="left" /><tbody valign="top"><row><entry /><entry>add it to R.</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="203pt" align="left" /><tbody valign="top"><row><entry /><entry>Resulting editor model:</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="28pt" align="left" /><colspec colname="1" colwidth="189pt" align="left" /><tbody valign="top"><row><entry /><entry>Hello_awesome_world!</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="203pt" align="left" /><tbody valign="top"><row><entry /><entry>Resulting viewer model:</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="28pt" align="left" /><colspec colname="1" colwidth="189pt" align="left" /><tbody valign="top"><row><entry /><entry>Hello_world!</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><tbody valign="top"><row><entry><b>Example #2: Applying a suggested and a regular command after a</b></entry></row><row><entry><b>suggestion.</b></entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="203pt" align="left" /><tbody valign="top"><row><entry /><entry>Change:</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="28pt" align="left" /><colspec colname="1" colwidth="189pt" align="left" /><tbody valign="top"><row><entry /><entry>[</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="56pt" align="left" /><colspec colname="1" colwidth="161pt" align="left" /><tbody valign="top"><row><entry /><entry>SuggestInsert “,” @ 5, // Suggest inserting “,” after</entry></row><row><entry /><entry>“Hello”</entry></row><row><entry /><entry>Insert “!” @ 19 // Insert “!” after “world”</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="28pt" align="left" /><colspec colname="1" colwidth="189pt" align="left" /><tbody valign="top"><row><entry /><entry>]</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="203pt" align="left" /><tbody valign="top"><row><entry /><entry>Steps:</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="offset" colwidth="28pt" align="left" /><colspec colname="1" colwidth="14pt" align="left" /><colspec colname="2" colwidth="175pt" align="left" /><tbody valign="top"><row><entry /><entry>4.</entry><entry>R = [ ]</entry></row><row><entry /><entry>5.</entry><entry>S = [Delete 6-13]</entry></row><row><entry /><entry>6.</entry><entry>Process the first command:</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="offset" colwidth="56pt" align="left" /><colspec colname="1" colwidth="14pt" align="left" /><colspec colname="2" colwidth="147pt" align="left" /><tbody valign="top"><row><entry /><entry>a.</entry><entry>C' = [SuggestInsert “,” @ 5]</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="70pt" align="left" /><colspec colname="1" colwidth="147pt" align="left" /><tbody valign="top"><row><entry /><entry>S' = [Delete 6-13]</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="offset" colwidth="56pt" align="left" /><colspec colname="1" colwidth="14pt" align="left" /><colspec colname="2" colwidth="147pt" align="left" /><tbody valign="top"><row><entry /><entry>b.</entry><entry>O = [Delete 5-5] // C' is a suggestion, so omit it.</entry></row><row><entry /><entry>c.</entry><entry>S = S' = [Delete 6-13, Delete 5-5]</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="offset" colwidth="28pt" align="left" /><colspec colname="1" colwidth="14pt" align="left" /><colspec colname="2" colwidth="175pt" align="left" /><tbody valign="top"><row><entry /><entry>7.</entry><entry>Process the second command:</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="offset" colwidth="56pt" align="left" /><colspec colname="1" colwidth="14pt" align="left" /><colspec colname="2" colwidth="147pt" align="left" /><tbody valign="top"><row><entry /><entry>a.</entry><entry>C' = [Insert “!” @ 10]</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="70pt" align="left" /><colspec colname="1" colwidth="147pt" align="left" /><tbody valign="top"><row><entry /><entry>S' = [Delete 6-13, Delete 5-5]</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="offset" colwidth="56pt" align="left" /><colspec colname="1" colwidth="14pt" align="left" /><colspec colname="2" colwidth="147pt" align="left" /><tbody valign="top"><row><entry /><entry>b.</entry><entry>R = [Insert “!” @ 10] // C' isn't a suggestion, so</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="70pt" align="left" /><colspec colname="1" colwidth="147pt" align="left" /><tbody valign="top"><row><entry /><entry>add it to R.</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="203pt" align="left" /><tbody valign="top"><row><entry /><entry>Resulting editor model:</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="28pt" align="left" /><colspec colname="1" colwidth="189pt" align="left" /><tbody valign="top"><row><entry /><entry>Hello,_awesome_world!</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="203pt" align="left" /><tbody valign="top"><row><entry /><entry>Resulting viewer model:</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="28pt" align="left" /><colspec colname="1" colwidth="189pt" align="left" /><tbody valign="top"><row><entry /><entry>Hello_world!</entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0232In some implementations, instead of using operational transformation to transform commands before being sent to viewers, the commands may be anonymized before being sent down and then relying on the client to properly transform them. This implementation may be undesired because it may involve a larger and more complicated change. In particular, anonymization may require both the command and the model pre-application of the command, so it would have to be done at apply time. Commands sent to the client in other paths such as delta changes would require application. Furthermore, the anonymization system would need to be built without destroying the command's operational transformation (and possibly application) semantics. This may have a negative impact on client performance (including mobile). In particular, transforms on the client may have an even worse performance impact for users, and approaches for handling this cleanly on the client-side may require changing offline storage.

0233Another embodiment of the systems and methods described herein include a notification mechanism to notify users of changes to the documents by collaborators. In an online collaborative document editing application, editors generally wish to have control over their documents and for collaborators to work them. Editors want to know who has modified their document, when it was modified, and what was changed. The systems and methods of the present disclosure address this problem by providing a way for the editor to be notified (as well as users who have subscribed to notifications) about changes to their document that have been made by collaborators, along with a summary of the changes.

0234<figref idref="DRAWINGS">FIG. 7</figref> provides an example logic flow diagram <b>700</b> illustrating aspects of notifying editors of changes to a collaborative document by collaborators. Existing systems may track changes that different users have made to a document, but do not provide notifications of changes or summaries of the changes to the users, at <b>701</b>. In one embodiment, changes that have been made by collaborators can be batched based on amount of time passed since the change, at <b>702</b>. An email or message is sent to the document owner and users who have opted to subscribe to notifications. The email or message may contain changes from multiple collaborators during a given time period. Each change in the message may include various data, such as the author, the time the change was made, and a description of the change. Changes may be made by other editors or by collaborators who do not have full edit rights, such as reviewers. The changes made by reviewers may be recorded as “suggestions” and require approval by an editor before being applied to the document. In some implementations, editors may accept or reject these changes directly from the email or message by selecting the appropriate option.

0235In some implementations, as each change is made to a document, the change is sent to a notification software system that tracks the change event by document and recipient. The document owner is subscribed to notifications by default, and other collaborators may also subscribe to the notifications. Changes made in the same area of the document or at the same time may be grouped together. The notification software system then waits a configurable amount of time, which may be based on whether the recipient is currently viewing the document or not, at <b>703</b>.

0236Once the appropriate time has passed at <b>704</b>, all the notification events for that recipient and document are batched together and processed at <b>705</b>. For each change made to the document, a separate entry may be created (at <b>706</b>) that lists the author, the timestamp of the change that was last made, and a textual description of the change.

0237In some embodiments, the present disclosure includes features for ensuring editors are not over-notified. Changes that have been reverted and/or are no longer present in the document may be ignored, and the notification for such changes may be suppressed. For example, if a collaborator makes a change to the document and the time period passes, the editor may receive an email describing the change. However, the notification of the change may be suppressed if the collaborator uses the undo functionality, manually undoes the change, or if the section of the document the change resides in was deleted by the editor.

0238Using different time periods based on whether an editor who is viewing the document allows editors who are actively viewing the document to take action on edits by users and prevent a redundant notification to be sent out while still sending timely notifications of changes. In an example, the time period may be longer if the editor is actively viewing the document, and may be shorter if the editor is not actively viewing the document.

0239The systems and methods described herein provide a human-readable explanation of changes made to a document and provide the editor with information that may be used to decide whether to view the document now, later, or never. Such a determination may not be possible when the editor is only provided with a timestamp that must be manually checked, or when the editor must rely on collaborators to inform the editor that changes exist and what the changes include.

0240Embodiments described herein present several advantages over existing systems. For example, the notification system described herein means that editors do not need to be manually notified by collaborators when the collaborators have made changes. Similarly, editors do not need to take action themselves to find out about changes because the emails or messages are sent out in minutes after the collaborator's change. Moreover, including a description of the change in the message gives the editor context regarding the changes. Simply providing a timestamp update is not enough information for the editor to decide if investigation of changes is warranted. The present disclosure provides information to the editor to let him better manage his time between multiple tasks, including the document undergoing collaboration.

0241In some implementations, the message may not only include the textual description, but also a rendering of the change in context with the rest of the document. For example, if a collaborator replaced some text with new text, not only would the description in the message say “Replace ‘end’ with ‘a final part of something’”, but the surrounding few lines, words, or sentences of the document may also be included in the message.

0242In some implementations, a summary of the changes may be included in the message notification. The following description is an example of a process for notifying editors and subscribers of changes in a document. A CommentNotificationListener may listen for events, which may occur any time a comment or reply is created, updated, or deleted. The events may be processed, and a notification payload may be created (if the circumstances warrant notifying). A notifier may then package the notification payload and sends it a messaging system, which receives the payload and adds it to a bucket of (document, recipient). The bucket may be held for a configurable amount of time (e.g., such as 5 minutes if the document is closed, 15 minutes if the document is open by the user to be notified). As more comments or replies are added or updated, they get added to the same bucket of (document, recipient). When the time period has passed, the messaging system takes all the payloads in a given bucket and sends this to a message processor configured to handle the bucket. The message processor passes the bucket to an event processor, which processes the notification events, filters out events that should not be sent, groups the events by comment id, and translates the events into html and text message bodies.

0243While various embodiments described herein have been shown, it will be obvious to those skilled in the art that such embodiments are provided by way of example only. Numerous variations, changes, and substitutions will now occur to those skilled in the art without departing from the disclosure. It should be understood that various alternatives to the embodiments of the disclosure described herein may be employed in practicing the disclosure.

0244Another embodiment of the systems and methods described herein include a notification mechanism to notify users of changes to the documents by collaborators. A document editor application may allow users to make edits as suggestions, which are tracked and have to be accepted or rejected before they are incorporated into the document. In doing so, the document editor needs a mechanism to convert any arbitrary edit into a suggestion version. It is desirable to have an automatic conversion mechanism that can generically convert existing edits without having to manually implement conversion logic for each edit. This allows all existing controller business logic to be leveraged, including any future logic that is written.

0245As discussed in connection with <figref idref="DRAWINGS">FIG. 6</figref>, changes to the document model may be described via a series of incremental atomic mutations. In a word processor, mutations might include insert characters, deleting characters and applying styles. A single user edit to the document might result in multiple mutations being applied to the model. A word processor would have business logic determining what mutations to apply to the model based on the user's action and the current state of the application.

0246<figref idref="DRAWINGS">FIG. 8</figref> provides an example logic flow diagram <b>800</b> illustrating aspects of converting edits into a suggestion. Starting at <b>801</b>, the application defines suggest versions of its mutations in order to identify suggested objects in the application model at <b>801</b>. For example, a word processor might have an insert characters mutation and an insert suggested characters mutation. Then, the application needs to define functions to convert from the regular version to the suggest version. In the previous example, that would be a function converting from insert characters to insert suggested characters. If the suggest mutation has different application semantics from the original mutation, then the suggest transform mutation must also be provided.

0247These mutations will be used to transform future mutations, in order to account for the differing semantics. For example, a word processor might have a delete characters mutation whose suggest version is mark characters for deletion. However, marking the characters for deletion doesn't actually delete them-it just creates a suggestion to delete them. For example, the user performs a drag drop, which is represented as a delete characters at index <b>100</b> and insert characters at index <b>200</b>. A naive conversion would convert these into mark characters for deletion at index <b>100</b> and insert characters at index <b>200</b>. However, the index of original insertion assumed that the characters had already been deleted. Therefore, an insert characters at <b>100</b> as the suggest transform mutation can be defined. Transforming the insert characters at <b>200</b> against that causes it to shift forward to the correct location for the insertion.

0248Once these semantics have been defined for the given application's model, then a suggestion can be produced based on the following steps:

02491. Define M as the current application Model (at <b>802</b>)

02502. Make a copy of M to produce M′ (at <b>802</b>)

02513. Run the business logic for the user's current action on M′. Collect the mutations applied to M′ as a result of that logic into an array A (at <b>803</b>).

02524. Define an empty array T (at <b>804</b>).

02535. For each mutation C in A: <ul id="ul0043" list-style="none"><li id="ul0043-0001" num="0000"><ul id="ul0044" list-style="none"><li id="ul0044-0001" num="0254">a. Produce S, the suggest version of C, via the application-specific function</li><li id="ul0044-0002" num="0255">b. Produce F, the suggest transform mutation for C, via the application-specific function</li><li id="ul0044-0003" num="0256">c. Transform S against T to produce S′ and T′</li><li id="ul0044-0004" num="0257">d. Set T=T′</li><li id="ul0044-0005" num="0258">e. Add F to T</li><li id="ul0044-0006" num="0259">f. Apply S′ to M. <br /> This will apply the suggest version of the mutation to the current model (at <b>805</b>). After the method is complete, the current model will have had the suggest version of the user action applied to it. </li></ul></li></ul>

0260When defining the function to produce suggest mutations, it may be useful to consider the ownership of the objects being affected. For example, if the user backspaced a suggested word, that word should be deleted, but if a non-suggested word was backspaced, it should be marked for deletion. To achieve this, define the concept of mutation ownership. Ownership can be in one of three states: owned, partially owned or not owned. During step (3) of the method above, the ownership for each mutation is calculated based on the objects in the model that it affects. For example, a mutation deleting text would be owned if the text is a suggestion by the current user, not owned if not and partially owned if only some of the deleted text is a suggestion by the current user. Then, during step (5.a) the pre-calculated ownership can be used during the conversion process. For a mutation deleting characters, that ownership could be used to disambiguate whether to convert into a mark characters for deletion or leave it as a delete characters.

0261The ownership may also be aggregated across mutations of similar types during step (3). By looking at this aggregate ownership, one may make a decision cross-cutting particular mutations when converting. This may be useful, for example, if the application allows for discontinuous selection and it is desirable to either consistently delete the text or mark it for deletion.

0262Solving the problem in this manner has the following advantages:

02631. It is a generic solution regardless of the application-specific business logic. It only requires defining conversion functions for the mutations in the application. This minimizes the cost to implement.

02642. Since it works regardless of application-specific business logic, it requires less maintenance when the application is extended or modified with new business logic.

02653. It is straightforward to extend suggestions to new objects in the model. Only has to only define the conversion functions for the mutations representing changes to those objects.

0266In order to produce suggestion commands, an interface SuggestCommandProvider can be introduced having a registry via the CommandRegistry. Another interface SuggestTransformCommandProvider can be adopted, which will create commands providing a mapping between the commands and suggestion commands. Example pseudo-code segment illustrating SuggestCommandProvider and SuggestTransformCommandProvider can take a form similar to the following:

0000<tables id="TABLE-US-00025" num="00025"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><thead><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>/** Creates suggestion versions of commands. */</entry></row><row><entry>interface <b>docs.commands.SuggestCommandProvider </b>{</entry></row><row><entry>/**</entry></row><row><entry>* Gets the corresponding suggestion command for the given command,</entry></row><row><entry>with the given</entry></row><row><entry>* suggestion id.</entry></row><row><entry>*/</entry></row><row><entry>SuggestCommand <b>provideSuggestCommand</b>(command, id, model)</entry></row><row><entry>}</entry></row><row><entry>interface <b>docs.commands.SuggestTransformCommandProvider </b>{</entry></row><row><entry>/**</entry></row><row><entry>* Given a suggest command, returns a command to be used to transform</entry></row><row><entry>future</entry></row><row><entry>* suggestions within the same Edit. This command will account for</entry></row><row><entry>differing semantics</entry></row><row><entry>* between commands and suggestion commands as returned by</entry></row><row><entry>getSuggestCommand.</entry></row><row><entry>*/</entry></row><row><entry>Command <b>provideSuggestTransformCommand</b>(command)</entry></row><row><entry>}</entry></row><row><entry>class <b>docs.commands.CommandRegistry </b>implements</entry></row><row><entry>docs.commands.SuggestCommandProvider,</entry></row><row><entry>docs.commands.SuggestTransformCommandProvider {</entry></row><row><entry>/** @override */</entry></row><row><entry>Command <b>provideSuggestCommand</b>(command, id, model)</entry></row><row><entry>/** @override */</entry></row><row><entry>Command <b>provideSuggestTransformCommand</b>(command)</entry></row><row><entry>} PC</entry></row><row><entry>/** Registers a SuggestCommandProvider */</entry></row><row><entry>void <b>registerSuggestCommandProvider</b>(type, provider)</entry></row><row><entry>/** Registers a SuggestTransformCommandProvider */</entry></row><row><entry>void <b>registerSuggestTransformCommandProvider</b>(type, provider)</entry></row><row><entry>}</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0267The document model may make a copy of the context so as to apply the original edit without modifying the actual ModelState. To do so, a suggest changes specific interface that copies the context can be created. This is not a generic context copier since it will do things particular to the usage in suggest changes, such as creating a no-op inverter.

0000<tables id="TABLE-US-00026" num="00026"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><thead><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>/** Copies contexts. */</entry></row><row><entry>interface <b>docs.edits.ContextCopier </b>{</entry></row><row><entry>/**</entry></row><row><entry>* Creates a copy of the given context to be used by the SuggestEdit.</entry></row><row><entry>*/</entry></row><row><entry>Context <b>copy</b>(context)</entry></row><row><entry>}</entry></row><row><entry>/** Copies the docs/text context for use in the SuggestEdit. */</entry></row><row><entry>class <b>docs.textedits.SuggestContextCopier </b>implements</entry></row><row><entry>docs.edits.ContextCopier</entry></row><row><entry>(commandApplier, selectionTransformer) {</entry></row><row><entry>/** @override */</entry></row><row><entry>Context <b>copy</b>(context) {</entry></row><row><entry>var model = context.getModelState( ).getModel( ).copy( );</entry></row><row><entry>var selectionModel = new docs.text.model.SelectionModelImpl(</entry></row><row><entry>context.getErrorReporter( ), model);</entry></row><row><entry>selectionModel.setSelection(</entry></row><row><entry>context.getModelState( ).getSelectionModel( ).getSelection( ));</entry></row><row><entry>var modelState = new docs.text.edits.ModelState(</entry></row><row><entry>model,</entry></row><row><entry>selectionModel,</entry></row><row><entry>commandApplier,</entry></row><row><entry>new NoOpCommandInverter( ),</entry></row><row><entry>selectionTransformer);</entry></row><row><entry>return new docs.text.edits.Context(</entry></row><row><entry>modelState,</entry></row><row><entry>context.getLinkDefaults( ),</entry></row><row><entry>context.getErrorReporter( ));</entry></row><row><entry>}</entry></row><row><entry>interface <b>docs.text.model.Model </b>{</entry></row><row><entry>/** Copies this Model. */</entry></row><row><entry>Model <b>copy</b>( )</entry></row><row><entry>}</entry></row><row><entry>class <b>docs.text.model.ModelImpl </b>implements docs.text.model.Model {</entry></row><row><entry>/** @override */</entry></row><row><entry>Model <b>copy</b>( ) {</entry></row><row><entry>var newModel = new ModelImpl(</entry></row><row><entry>this.errorReporter_,</entry></row><row><entry>this.styleResolvers_,</entry></row><row><entry>this.concreteStyleUpdaters_,</entry></row><row><entry>this.entityConcreteStyleUpdaters_,</entry></row><row><entry>this.entityResolvers_,</entry></row><row><entry>this.enabledStyleTypes_,</entry></row><row><entry>this.contentClassifier_);</entry></row><row><entry>this.copyTo(newModel);</entry></row><row><entry>return newModel;</entry></row><row><entry>}</entry></row><row><entry>}</entry></row><row><entry>class <b>docs.text.model.ModelWrapper </b>implements docs.text.model.Model {</entry></row><row><entry>/** @override */</entry></row><row><entry>Model <b>copy</b>( ) {</entry></row><row><entry>return this.modelProviderFn_.copy( );</entry></row><row><entry>}</entry></row><row><entry>}</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0268In order to do the SelectionModel copy outlined above, SelectionTreeGenerator and SelectionDocumentSliceGenerator will be removed from the SelectionModel and moved to a helper class:

0000<tables id="TABLE-US-00027" num="00027"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><thead><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>class <b>docs.text.dom.DocumentSliceGenerator</b>(</entry></row><row><entry>selectionTreeGenerator, selectionDocumentSliceGenerator) {</entry></row><row><entry>/** Creates a document slice representing the given selection in the given</entry></row><row><entry>model. */</entry></row><row><entry>DocumentSlice <b>createDocumentSlice</b>(model, selection) {</entry></row><row><entry>var root = this.selectionTreeGenerator_.generateTree(</entry></row><row><entry>model.getSpacers( ), selection.getSelectedRanges( ));</entry></row><row><entry>return this.selectionDocumentSliceGenerator_.generate(</entry></row><row><entry>model, selection, root);</entry></row><row><entry>}</entry></row><row><entry>}</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0269In order to introduce a SuggestEdit, IdUtil can be moved from docs.text.util to docs.util. Below is an outline of the two new classes:

0000<tables id="TABLE-US-00028" num="00028"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="273pt" align="left" /><thead><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>/** Provides suggest edits. */</entry></row><row><entry>class <b>docs.edits.SuggestEditProvider </b>implements docs.edits.EditProvider(</entry></row><row><entry>editProvider,</entry></row><row><entry>commandTransformer,</entry></row><row><entry>selectionTransformer,</entry></row><row><entry>suggestCommandProvider,</entry></row><row><entry>suggestTransformCommandProvider,</entry></row><row><entry>contextCopier) {</entry></row><row><entry>Edit <b>provideEdit</b>(context) {</entry></row><row><entry>return new SuggestEdit(</entry></row><row><entry>context,</entry></row><row><entry>this.editProvider_.provide(</entry></row><row><entry>this.contextCopier_.copy(context)),</entry></row><row><entry>this.commandTransformer_,</entry></row><row><entry>this.selectionTransformer_,</entry></row><row><entry>this.suggestCommandProvider_,</entry></row><row><entry>this.suggestTransformCommandProvider_);</entry></row><row><entry>}</entry></row><row><entry>boolean <b>canApply</b>(context) {</entry></row><row><entry>return this.editProvider_.canApply(context)</entry></row><row><entry>}</entry></row><row><entry>}</entry></row><row><entry>/** Applies the given edit as a suggestion. */</entry></row><row><entry>class <b>docs.edits.SuggestEdit </b>extends docs.edits.AbstractEdit(</entry></row><row><entry>context, edit, commandTransformer, selectionTransformer, suggestCommandProvider,</entry></row><row><entry>suggestTransformCommandProvider) {</entry></row><row><entry>void <b>applyInternal</b>(args) {</entry></row><row><entry>var result = this.edit_.apply(args);</entry></row><row><entry>var id = docs.util.IdUtil.generateId(‘suggest’);</entry></row><row><entry>var transformCommands = [ ];</entry></row><row><entry>for each command in result.getCommands( ) {</entry></row><row><entry>// Have to unwrap because provideSuggestCommand takes in the model.</entry></row><row><entry>if (command.isWrapper( )) {</entry></row><row><entry>for each innerCommand in command.unwrap( ) {</entry></row><row><entry>this.applySuggestCommand_(innerCommand, transformCommands);</entry></row><row><entry>}</entry></row><row><entry>} else {</entry></row><row><entry>this.applySuggestCommand_(command, transformCommands);</entry></row><row><entry>}</entry></row><row><entry>}</entry></row><row><entry>this.applySelection(this.selectionTransformer_.transformSelection(</entry></row><row><entry>result.getSelectionAfter( ), transformCommands));</entry></row><row><entry>}</entry></row><row><entry>private void <b>applySuggestCommand</b>_(command, transformCommands) {</entry></row><row><entry>var suggestCommand = this.suggestCommandProvider_.provideSuggestCommand(</entry></row><row><entry>command, id, model);</entry></row><row><entry>var pair = this.transformer_.transformBoth([suggestCommand], transformCommands);</entry></row><row><entry>transformCommands = pair.getCommands( );</entry></row><row><entry>assert(pair.getCommandsToWin( ).length == 1);</entry></row><row><entry>var transformedSuggestCommand = pair.getCommandsToWin( )[0];</entry></row><row><entry>var newTransformCommand =</entry></row><row><entry>this.suggestTransformCommandProvider_.provideSuggestTransformCommand(</entry></row><row><entry>suggestCommand);</entry></row><row><entry>// Unwrap for performance since this newTransformCommand will often be a NullCommand.</entry></row><row><entry>var newTransformCommands = newTransformCommand.isWrapper( ) ?</entry></row><row><entry>newTransformCommand.unwrap( ) : [newTransformCommand];</entry></row><row><entry>goog.array.extend(transformCommands, newTransformCommands);</entry></row><row><entry>this.applyCommand(transformedSuggestCommand);</entry></row><row><entry>}</entry></row><row><entry>}</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables><br /> Note that the applySelection call in SuggestEdit.applylnternal is not properly propagating “scroll into view” and the selection change reason. This will be covered in future work, for now those will be dropped.

0270The SuggestEditProvider needs to be used wrapping the regular EditProvider whenever the app is in suggestions mode. This will be achieved by introducing a SuggestEditApplier wrapper:

0000<tables id="TABLE-US-00029" num="00029"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><thead><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>/** Provides suggest edits. */</entry></row><row><entry>class <b>docs.edits.SuggestEditApplier </b>implements</entry></row><row><entry>docs.edits.EditApplier(delegate,</entry></row><row><entry>commandTransformer, selectionTransformer, suggestCommandProvider,</entry></row><row><entry>suggestTransformCommandProvider, contextCopier) {</entry></row><row><entry>/** @override */</entry></row><row><entry>void <b>apply</b>(editProvider, args) {</entry></row><row><entry>if (this.suggestionsMode_) {</entry></row><row><entry>editProvider = new SuggestEditProvider(</entry></row><row><entry>editProvider,</entry></row><row><entry>commandTransformer,</entry></row><row><entry>selectionTransformer,</entry></row><row><entry>suggestCommandProvider,</entry></row><row><entry>suggestTransformCommandProvider,</entry></row><row><entry>contextCopier);</entry></row><row><entry>}</entry></row><row><entry>this.delegate_.apply(editProvider);</entry></row><row><entry>}</entry></row><row><entry>void <b>setSuggestionsMode</b>(enabled) {</entry></row><row><entry>this.suggestionsMode_ = enabled;</entry></row><row><entry>}</entry></row><row><entry>}</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0271This allows intercepting all edit providers being applied and wrap them as appropriate. The undo or regular redo may not need to be intercepted since those will correctly apply the commands from the SuggestEdit result. Additionally, the magic redo may not need to be intercepted since the saved provider will already be the correct one. The SuggestEditApplier will be created in collaborative documents behind the suggest changes flag. If the user is in comment mode, then setSuggestionsMode will be enabled.

0272<figref idref="DRAWINGS">FIG. 9</figref> is a block diagram illustrating an exemplary computer system <b>900</b> with which the system for managing suggested edits in a document and use of <figref idref="DRAWINGS">FIGS. 1-8</figref> can be implemented. In certain aspects, the computer system <b>900</b> may be implemented using hardware or a combination of software and hardware, either in a dedicated server, or integrated into another entity, or distributed across multiple entities.

0273Computer system <b>900</b> includes a bus <b>908</b> or other communication mechanism for communicating information, and a processor <b>902</b> coupled with bus <b>908</b> for processing information. By way of example, the computer system <b>900</b> may be implemented with one or more processors <b>902</b>.

0274Computer system <b>900</b> can include, in addition to hardware, code that creates an execution environment for the computer program in question, e.g., code that constitutes processor firmware, a protocol stack, a database management system, an operating system, or a combination of one or more of them stored in an included memory <b>904</b>, such as a Random Access Memory (RAM), a flash memory, a Read Only Memory (ROM), a Programmable Read-Only Memory (PROM), an Erasable PROM (EPROM), registers, a hard disk, a removable disk, a CD-ROM, a DVD, or any other suitable storage device, coupled to bus <b>908</b> for storing information and instructions to be executed by processor <b>902</b>. The processor <b>902</b> and the memory <b>904</b> can be supplemented by, or incorporated in, logic circuitry.

0275The methods and systems described herein may be deployed in part or in whole through a machine that executes computer software on a server, client, firewall, gateway, hub, router, or other such computer and/or networking hardware. The software program may be associated with a server that may include a file server, print server, domain server, internet server, intranet server and other variants such as secondary server, host server, distributed server and the like. The server may include one or more of memories, processors, computer readable media, storage media, ports (physical and virtual), communication devices, and interfaces capable of accessing other servers, clients, machines, and devices through a wired or a wireless medium, and the like. The methods, programs or codes as described herein and elsewhere may be executed by the server. In addition, other devices required for execution of methods as described in this application may be considered as a part of the infrastructure associated with the server.

0276The server may provide an interface to other devices including, without limitation, clients, other servers, printers, database servers, print servers, file servers, communication servers, distributed servers and the like. Additionally, this coupling and/or connection may facilitate remote execution of programs across the network. The networking of some or all of these devices may facilitate parallel processing of a program or method at one or more location without deviating from the scope of the disclosed subject matter. In addition, any of the devices attached to the server through an interface may include at least one storage medium capable of storing methods, programs, code and/or instructions. A central repository may provide program instructions to be executed on different devices. In this implementation, the remote repository may act as a storage medium for program code, instructions, and programs.

0277The methods and systems described herein may be deployed in part or in whole through network infrastructures. The network infrastructure may include elements such as computing devices, servers, routers, hubs, firewalls, clients, personal computers, communication devices, routing devices and other active and passive devices, modules and/or components as known in the art. The computing and/or non-computing device(s) associated with the network infrastructure may include, apart from other components, a storage medium such as flash memory, buffer, stack, RAM, ROM and the like. The processes, methods, program codes, instructions described herein and elsewhere may be executed by one or more of the network infrastructural elements.

0278The computer software, program codes, and/or instructions may be stored and/or accessed on machine readable media that may include: computer components, devices, and recording media that retain digital data used for computing for some interval of time; semiconductor storage known as random access memory (RAM); mass storage typically for more permanent storage, such as optical discs, forms of magnetic storage like hard disks, tapes, drums, cards and other types; processor registers, cache memory, volatile memory, non-volatile memory; optical storage such as CD, DVD; removable media such as flash memory (e.g. USB sticks or keys), floppy disks, magnetic tape, paper tape, punch cards, standalone RAM disks, Zip drives, removable mass storage, off-line, and the like; other computer memory such as dynamic memory, static memory, read/write storage, mutable storage, read only, random access, sequential access, location addressable, file addressable, content addressable, network attached storage, storage area network, bar codes, magnetic ink, and the like.

0279The elements described and depicted herein, including in flow charts and block diagrams throughout the figures, imply logical boundaries between the elements. However, according to software or hardware engineering practices, the depicted elements and the functions thereof may be implemented on machines through computer executable media having a processor capable of executing program instructions stored thereon as a monolithic software structure, as standalone software modules, or as modules that employ external routines, code, services, and so forth, or any combination of these, and all such implementations may be within the scope of the present disclosure.

0280Thus, while the foregoing drawings and descriptions set forth functional aspects of the disclosed systems, no particular arrangement of software for implementing these functional aspects should be inferred from these descriptions unless explicitly stated or otherwise clear from the context. Similarly, it will be appreciated that the various techniques identified and described above may be varied, and that the order of techniques may be adapted to particular applications of the techniques disclosed herein. All such variations and modifications are intended to fall within the scope of this disclosure. As such, the depiction and/or description of an order for various techniques should not be understood to require a particular order of execution for those techniques, unless required by a particular application, or explicitly stated or otherwise clear from the context.

0281The methods and/or processes described above, and techniques thereof, may be realized in hardware, or any combination of hardware and software suitable for a particular application. The hardware may include a general purpose computer and/or dedicated computing device or specific computing device or particular aspect or component of a specific computing device. The processes may be realized in one or more microprocessors, microcontrollers, embedded microcontrollers, programmable digital signal processors or other programmable device, along with internal and/or external memory. The processes may also, or instead, be embodied in an application-specific integrated circuit, a programmable gate array, programmable array logic, or any other device or combination of devices that may be configured to process electronic signals. It will further be appreciated that one or more of the processes may be realized as a computer executable code capable of being executed on a machine readable medium.

0282The instructions may be stored in the memory <b>904</b> and implemented in one or more computer program products, i.e., one or more modules of computer program instructions encoded on a computer readable medium for execution by, or to control the operation of, the service, and according to any method well known to those of skill in the art, including, but not limited to, computer languages such as data-oriented languages (e.g., SQL, dBase), system languages (e.g., C, Objective-C, C++, Assembly), architectural languages (e.g., Java, .NET), and application languages (e.g., PHP, Ruby, Perl, Python).

0283A computer program as discussed herein does not necessarily correspond to a file in a file system. A program can be stored in a portion of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to the program in question, or in multiple coordinated files (e.g., files that store one or more modules, subprograms, or portions of code). A computer program can be deployed to be executed on one computer or on multiple computers that are located at one site or distributed across multiple sites and interconnected by a communication network. The processes and logic flows described in this specification can be performed by one or more programmable processors executing one or more computer programs to perform functions by operating on input data and generating output.

0284Computer system <b>900</b> further includes a data storage device <b>906</b> such as a magnetic disk or optical disk, coupled to bus <b>908</b> for storing information and instructions. Computer system <b>900</b> may be coupled via an input/output module <b>910</b> to various devices. The input/output module <b>910</b> can be any input/output module. Example input/output modules <b>910</b> include data ports such as USB ports. The input/output module <b>910</b> is configured to connect to a communications module <b>912</b>. Example communications modules <b>912</b> include networking interface cards, such as Ethernet cards and modems. In certain aspects, the input/output module <b>910</b> is configured to connect to a plurality of devices, such as an input device <b>914</b> and/or an output device <b>916</b>. Example input devices <b>914</b> include a keyboard and a pointing device, e.g., a mouse or a trackball, by which a user can provide input to the computer system <b>900</b>. Other kinds of input devices <b>914</b> can be used to provide for interaction with a user as well, such as a tactile input device, visual input device, audio input device, or brain-computer interface device. For example, feedback provided to the user can be any form of sensory feedback, e.g., visual feedback, auditory feedback, or tactile feedback; and input from the user can be received in any form, including acoustic, speech, tactile, or brain wave input. Example output devices <b>916</b> include display devices, such as a CRT (cathode ray tube) or LCD (liquid crystal display) monitor, for displaying information to the user.

0285According to one aspect of the present disclosure, the system for managing suggested edits in a document model as shown in <figref idref="DRAWINGS">FIGS. 2A-7</figref>, can be implemented using a computer system <b>900</b> in response to processor <b>902</b> executing one or more sequences of one or more instructions contained in memory <b>904</b>. Such instructions may be read into memory <b>904</b> from another machine-readable medium, such as data storage device <b>906</b>. Execution of the sequences of instructions contained in main memory <b>904</b> causes processor <b>902</b> to perform the processes described herein. One or more processors in a multi-processing arrangement may also be employed to execute the sequences of instructions contained in memory <b>904</b>. In alternative aspects, hard-wired circuitry may be used in place of or in combination with software instructions to implement various aspects of the present disclosure. Thus, aspects of the present disclosure are not limited to any specific combination of hardware circuitry and software.

0286Various aspects of the subject matter described in this specification can be implemented in a computing system that includes a back end component, e.g., as a data server, or that includes a middleware component, e.g., an application server, or that includes a front end component, e.g., a client computer having a graphical user interface or a Web browser through which a user can interact with an implementation of the subject matter described in this specification, or any combination of one or more such back end, middleware, or front end components. The components of the system can be interconnected by any form or medium of digital data communication, e.g., a communication network. The communication network can include, for example, any one or more of a personal area network (PAN), a local area network (LAN), a campus area network (CAN), a metropolitan area network (MAN), a wide area network (WAN), a broadband network (BBN), the Internet, and the like. Further, the communication networks can include, but are not limited to, for example, any one or more of the following network topologies, including a bus network, a star network, a ring network, a mesh network, a star-bus network, tree or hierarchical network, or the like. The communications modules can be, for example, modems or Ethernet cards.

0287As discussed above, computing system <b>900</b> can include clients and servers. A client and server are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other. Computer system <b>900</b> can be, for example, and without limitation, an enterprise server or group of servers, one or more desktop computers, one or more laptop computers, etc. Computer system <b>900</b> can also be embedded in another device, for example, and without limitation, a mobile telephone, a personal digital assistant (PDA), a mobile audio player, a Global Positioning System (GPS) receiver, a video game console, and/or a television set top box.

0288The term “machine-readable storage medium” or “computer readable medium” as used herein refers to any medium or media that participates in providing instructions to processor <b>902</b> for execution. Such a medium may take many forms, including, but not limited to, non-volatile media, volatile media, and transmission media. Non-volatile media include, for example, optical or magnetic disks, such as data storage device <b>906</b>. Volatile media include dynamic memory, such as memory <b>904</b>. Transmission media include coaxial cables, copper wire, and fiber optics, including the wires that comprise bus <b>908</b>. Common forms of machine-readable media include, for example, floppy disk, a flexible disk, hard disk, magnetic tape, any other magnetic medium, a CD-ROM, DVD, any other optical medium, punch cards, paper tape, any other physical medium with patterns of holes, a RAM, a PROM, an EPROM, a FLASH EPROM, any other memory chip or cartridge, or any other medium from which a computer can read. The machine-readable storage medium can be a machine-readable storage device, a machine-readable storage substrate, a memory device, a composition of matter effecting a machine-readable propagated signal, or a combination of one or more of them.

0289While this specification contains many specifics, these should not be construed as limitations on the scope of what may be claimed, but rather as descriptions of particular implementations of the subject matter. Certain features that are described in this specification in the context of separate implementations can also be implemented in combination in a single implementation. Conversely, various features that are described in the context of a single implementation can also be implemented in multiple implementations separately or in any suitable subcombination. Moreover, although features may be described above as acting in certain combinations and even initially claimed as such, one or more features from a claimed combination can in some cases be excised from the combination, and the claimed combination may be directed to a subcombination or variation of a subcombination.

0290While operations are depicted in the drawings in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. In certain circumstances, multitasking and parallel processing may be advantageous. Moreover, the separation of various system components in the aspects described above should not be understood as requiring such separation in all aspects, and it should be understood that the described program components and systems can generally be integrated together in a single software product or packaged into multiple software products.

0291The subject matter of this specification has been described in terms of particular aspects, but other aspects can be implemented and are within the scope of the following claims. For example, the actions recited in the claims can be performed in a different order and still achieve desirable results. As one example, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In certain implementations, multitasking and parallel processing may be advantageous. Other variations are within the scope of the following claims.