DE202015009277U1

DE202015009277U1 - Systeme zur Verwaltung von Bearbeitungsvorschlägen in einer Textbearbeitungsumgebung für kollaborative Dokumente

Info

Publication number: DE202015009277U1
Application number: DE202015009277.2U
Authority: DE
Original assignee: Google LLC
Current assignee: Google LLC
Priority date: 2014-06-24
Filing date: 2015-06-24
Publication date: 2017-01-20
Anticipated expiration: 2025-06-25
Also published as: WO2015200495A1; US20150370769A1; CN114564920A; CN114564920B; US10521498B2; EP3161663A1; CN106575287A

Abstract

System zum Verwalten von Bearbeitungsvorschlägen in einem kollaborativen Dokument, wobei das System Folgendes umfasst: Mittel zum Erzeugen einer Dokumentenvorlage, die dem kollaborativen Dokument zugewiesen ist; Mittel zum Empfangen eines ersten Bearbeitungsvorschlags am kollaborativen Dokument von einem ersten Benutzer; Mittel zum Zuweisen eines ersten Vorschlagsbefehls zum ersten Bearbeitungsvorschlag basierend auf einem Typ des ersten Bearbeitungsvorschlags und einem Typ der Dokumentenvorlage; Mittel zum Anwenden des ersten Vorschlagsbefehls auf die Dokumentenvorlage, um den ersten Bearbeitungsvorschlag innerhalb des kollaborativen Dokuments vorzulegen; Mittel zum Empfangen einer Annahmeanzeige für den ersten Bearbeitungsvorschlag; und Mittel zum Aktualisieren der Dokumentenvorlage mit dem ersten Vorschlagsbefehl als Reaktion auf die eingegangene Annahmeanzeige.

Description

Gebiet der Erfindung
Im Allgemeinen bezieht sich diese Offenbarung auf elektronische Dokumente, insbesondere auf Systeme und Verfahren zur Verwaltung von Bearbeitungsvorschlägen in einer Textbearbeitungsumgebung für kollaborative Dokumente.
Hintergrund
Während der Erarbeitung eines elektronischen Dokuments ist es häufig wünschenswert, mehrere Lektoren Änderungsvorschläge machen zu lassen und den Entwurf des elektronischen Dokuments kommentieren zu lassen. Ein Autor könnte beispielsweise einen ersten Entwurf eines elektronischen Dokuments erstellen und eine Kopie des elektronischen Dokuments zur Kommentierung an mehrere Lektoren schicken. Jeder Lektor kann im elektronischen Dokument unabhängig Änderungsvorschläge machen oder Kommentare einfügen und eine überarbeitete Version des elektronischen Dokuments zurück an den Autor schicken. Diese Schritte werden wiederholt, bis der Autor und die Lektoren mit einer Version des elektronischen Dokuments zufrieden sind. Diese Vorgehensweise ist jedoch zeitaufwendig und ineffizient.
Kurzdarstellung
Die in dieser Anmeldung offenbarten Systeme und Verfahren stellen eine Plattform zur Dokumentenbearbeitung bereit, um Bearbeitungsvorschläge in einem kollaborativen Dokument zu verwalten. Der Dokument-Editor kann eine Dokumentenvorlage erzeugen, die dem kollaborativen Dokument zugewiesen ist. Wenn ein erster Bearbeitungsvorschlag für das kollaborative Dokument eingeht, wird dem ersten Bearbeitungsvorschlag ein erster Vorschlagsbefehl basierend auf einem Vorbild des ersten Änderungsvorschlags und einem Vorbild der Dokumentenvorlage zugewiesen. Der Dokument-Editor kann den ersten Vorschlagsbefehl auf die Dokumentenvorlage anwenden, um den ersten Bearbeitungsvorschlag innerhalb des kollaborativen Dokuments vorzulegen. Wenn eine Annahmeanzeige für den ersten Bearbeitungsvorschlag eingeht, kann die Dokumentenvorlage als Reaktion auf die eingegangene Annahmeanzeige mit dem ersten Vorschlagsbefehl aktualisiert werden.
Kurze Beschreibung der Zeichnungen
Die oben genannten und weitere Eigenschaften der vorliegenden Offenbarung, einschließlich ihrer Besonderheiten und verschiedenen Vorteile, werden besser verständlich durch die folgende detaillierte Beschreibung zusammen mit den begleitenden Zeichnungen, in denen:
1 ist gemäß einer konkretisierenden Ausführungsform ein Blockschaltbild eines Computersystems 100 zum Integrieren von kollaborativ vorgeschlagenen Änderungen und zum Veröffentlichen eines elektronischen Dokuments.
2A–2B stellen ein exemplarisches Ablaufdiagramm bereit, das gemäß einer konkretisierenden Ausführungsform Merkmale der Verwaltung von Bearbeitungsvorschlägen innerhalb einer Dokumentenvorlage darstellt.
3 stellt ein exemplarisches Ablaufdiagramm bereit, das gemäß einer konkretisierenden Ausführungsform Merkmale von Vorgehensweisen bei der Vorschlagsfilterung für eine Dokumentenvorlage darstellt.
4A–4B zeigen ein exemplarisches Ablaufdiagramm 400, das das gemäß einer konkretisierenden Ausführungsform Merkmale der Zusammenführung von Bearbeitungsvorschlägen abbildet.
5 zeigt ein Ablaufdiagramm eines Verfahrens 500, das vom Rezensionsmanager 102 zur Verwendung der Priorisierungskategorien benutzt wird, um zu ermitteln, in welcher Reihenfolge die Vorschläge innerhalb eines Dokuments zusammengeführt werden sollen.
6 zeigt ein exemplarisches Ablaufdiagramm 600, das gemäß einer konkretisierenden Ausführungsform Merkmale zur Bestimmung einer Variante „Transformation nicht berücksichtigen“ für eine Dokumentenvorlage abbildet.
7 stellt ein exemplarisches Ablaufdiagramm 700 bereit, das gemäß einer konkretisierenden Ausführungsform Merkmale der Benachrichtigung von Redakteuren über Änderungen an einem kollaborativen Dokument durch andere Mitarbeiter darstellt.
8 stellt ein exemplarisches Ablaufdiagramm 800 bereit, das Merkmale des Umwandelns von Bearbeitungen in einen Vorschlag darstellt.
9 ist eine schematische Darstellung eines exemplarischen Computersystems, das in Übereinstimmung mit einer oder mehreren Implementierungen in dieser Offenbarung verwendet werden kann.
Ausführliche Beschreibung
Zum umfassenden Verständnis der in dieser Offenbarung beschriebenen Systeme und Verfahren werden im folgenden bestimmte Ausführungsformen beschrieben, einschließlich eines Systems und einer Methode zur Verwaltung von Bearbeitungsvorschlägen in einer Textbearbeitungsumgebung. Allerdings wird ein regulär geschulter Benutzer sehen, dass die hier beschriebenen Systeme und Methoden entsprechend abgeändert und angepasst werden können, um der jeweiligen Anwendung zu genügen, und ebenfalls, dass die hier beschriebenen Systeme und Methoden auch in anderen geeigneten Anwendungen eingesetzt werden können und dass diese Zusätze und Änderungen nicht aus deren Ausmaß abweichen. Im Allgemeinen können die hier beschriebenen computerisierten Systeme eine oder mehrere Treiber umfassen, die einen Prozessor oder Rechner, wie einen Computer, ein Logikgerät oder ein anderes Gerät oder einen Prozessor umfassen, der mit Hardware, Firmware und Software bestückt ist, um eine oder mehrere der hier beschriebenen computerisierten Methoden durchzuführen.
1 ist gemäß einer konkretisierenden Ausführungsform ein Blockschaltbild eines Computersystems 100 zum Integrieren von kollaborativ vorgeschlagenen Änderungen und zum Veröffentlichen eines elektronischen Dokuments. Das System 100 beinhaltet einen Server 104 und drei Benutzergeräte 109, 113 und 117, die über ein Netzwerk 120 miteinander verbunden sind. Der Server 104 beinhaltet eine elektronische Datenbank 103 und einen Rezensionsmanager 102, der Aktualisierungen in verschiedenen Versionen eines Zentraldokuments 106 verwaltet. Das Zentraldokument 106 kann in der elektronischen Datenbank 103 auf dem Server 104 gespeichert werden; oder auf einer getrennten Speichervorrichtung.
Um den Prozess der Zusammenarbeit an elektronischen Dokumenten effizienter zu gestalten, wird zur Integration von kollaborativ vorgeschlagenen Änderungen an einem elektronischen Dokument eine Textbearbeitungsumgebung für kollaborative Dokumente bereitgestellt. In der Textbearbeitungsumgebung für kollaborative Dokumente können Benutzer an verschiedenen Benutzergeräten gleichzeitig auf das Zentraldokument 106 zugreifen, um das Dokument zu rezensieren und Änderungen vorzuschlagen. Jedem Benutzer wird ein Benutzertypus zugewiesen (wie etwa ein Redakteur, Lektor oder Leser), der den Level der Zugangsberechtigung zu und Bearbeitungsmöglichkeiten von verschiedenen Versionen des Dokuments bestimmt. Wie in 1 dargestellt, kann ein Benutzer am Benutzergerät 109 über die Redakteur-Oberfläche 110 mit dem Zentraldokument 106 interagieren, ein Lektor am Benutzergerät 113 kann mit dem Zentraldokument 106 über die Lektoren-Oberfläche 114, und ein Leser am Benutzergerät 117 mit dem Zentraldokument 106 über die Leser-Oberfläche 118 interagieren.
Ein Lektor eines Dokuments kann das Dokument lesen, Bearbeitungsvorschläge machen und Kommentare bereitstellen, hat aber möglicherweise keine Erlaubnis, vorgeschlagene Änderungen anzunehmen oder abzulehnen. Der Lektor kann des Weiteren Bearbeitungsvorschläge und Kommentare von anderen Lektoren des Dokuments einsehen. Ein Redakteur hat für das Dokument eine höhere Berechtigungsstufe als der Lektor und kann Bearbeitungsvorschläge annehmen oder ablehnen und kann auch vom Lektor gemachte Kommentare löschen. Darüber hinaus besitzt der Redakteur auch die Zugangsberechtigung für Änderungen oder Kommentare am Dokument selbst. Die von einem Redakteur eingegangenen Änderungen können wie angenommene Änderungsvorschläge behandelt werden. Der Leser des Dokuments hat einen niedrigeren Zugangsberechtigungslevel als der Lektor und kann nur eine bereinigte veröffentlichte Version des Dokuments sehen, die keine Anzeigen von Bearbeitungsvorschlägen oder Kommentaren enthält. Wenn beispielsweise ein Redakteur das Dokument ansieht, kann der Redakteur einen Livestream kollaborativer Updates einsehen, die von verschiedenen Benutzern zur gleichen Zeit vorgenommen wurden, was die für die Erstellung des Dokuments benötigte Zeit signifikant verringert. Auf diese Weise bieten die hier offenbarte Systeme und Verfahren durch die Möglichkeit der effizienten Zusammenarbeit einer Gruppe von Benutzern, die Änderungsvorschläge zu einem Dokument machen, deutliche Vorteile gegenüber einem System, bei dem Lektoren unabhängig voneinander Änderungsvorschläge zu einem Dokument machen.
Anwendungen könnten es zulassen wollen, Änderungen als Vorschläge nachzuverfolgen, was es notwendig machen würde, dass sie vor ihrer Einarbeitung in das Dokument angenommen oder abgelehnt werden. Diese Vorgehensweise macht es erforderlich, diese Änderungen so darzustellen, dass sie von der zugrundeliegenden Vorlage des kollaborativen Dokuments unterscheidbar sind und es zulassen, dass unterschiedliche Änderungen demselben Vorschlag zugewiesen werden.
2A–2B zeigen ein exemplarisches Ablaufdiagramm, das verschiedene Merkmale der Verwaltung von Bearbeitungsvorschlägen innerhalb einer Dokumentenvorlage darstellt. Beginnend mit 201 kann eine Dokumentenvorlage unter Zuweisung zu einem kollaborativen Dokument erzeugt werden. Die Dokumentenvorlage kann beispielsweise an einem Server (z. B. 104 in 1) erzeugt werden, um einer Zentralkopie des elektronischen Dokuments zugewiesen zu werden. Änderungsvorschläge können von einem Benutzer über ein Benutzergerät eingehen (z. B. 109 in 1), bei 202. Die Dokumentenvorlage kann einen Dokumenten-Bearbeitungsmodus definieren, wobei Änderungen am Dokument als Vorschläge gekennzeichnet werden und von Redakteuren angenommen oder abgelehnt werden können. Die Dokumentenvorlage kann beispielsweise prüfen, ob ein Benutzer die Zugriffsberechtigung hat, einen Bearbeitungsvorschlag zu machen, z. B. ob der Benutzer ein Lektor, Redakteur oder Leser ist, bei 203, und einem Benutzer, der von einem Benutzergerät aus einen Bearbeitungsvorschlag machen darf, eine „Vorschlags“-Option bereitstellen. Dieser Modus kann den Modus „Nur Kommentieren“ ersetzen, und es Benutzern mit einer Kommentarberechtigung erlauben, sowohl Kommentare als auch Vorschläge zu machen. Im Allgemeinen sind von einem Redakteur durchgeführte Änderungen auch von einem vorschlagenden Benutzer machbar.

Bei 204 kann der Server die Semantik ermitteln, die auf der Basis der Bearbeitungsvorschläge anzuwenden ist. Vorschläge können beispielsweise auf modellspezifische Weise dargestellt werden. Im Allgemeinen werden sie dargestellt, indem vermerkt wird, welche Teile des Modells vorgeschlagene Einfügungen/Löschungen/Änderungen sind. Für ein Textfolgemodell werden zum Beispiel Bereiche von vorgeschlagenen Einfügungen und Löschungen vorgehalten. Man kann Befehle so betrachten, dass sie innerhalb eines bestimmten adressierbaren Bereichs agieren. Beispiele beinhalten eine Folge von Abstandshaltern oder Entitätszuordnung, eine Liste von Folien oder ein Formensatz für Präsentationen. In Anbetracht ihres adressierbaren Bereichs können Befehle, die in einen Vorschlag aufgenommen werden können, wie folgt in Tabelle 1 dargestellt werden: Tabelle 1: Beispielbefehle

Befehl	Semantik anwenden	Beispiele
Erstellen	Objekt in den Bereich einfügen.	InsertSpacersMutation InsertCommand

Löschen	Objekt aus Bereich löschen.	DeleteCommand DeleteSpacersMutation
Modifizieren	Die dem Objekt zugeordnete Eigenschaft modifizieren.	ApplyStyleMutation ShapePropertiesCommand
Verschieben	Objekt zwischen zwei Orten im Bereich verschieben.	MovePageCommand
Ersetzen	Objekt durch ein anderes innerhalb desselben Bereichs ersetzen.	Keine. Könnte möglicherweise einige ReplaceSpacersMutation enthalten

Ein Vorschlagsbefehl kann einem Bearbeitungsvorschlag bei 205 zugewiesen werden. Zur Unterstützung von Änderungsvorschlägen kann jeder Befehl einen entsprechenden Vorschlagsbefehl haben. Im Vorschlagsmodus wird anstelle der regulären Version des Befehls die Vorschlagsversion des Befehls ausgeführt. Semantikbeispiele für die Vorschlagsbefehle, die von den in Tabelle 1 aufgeführten Beispielbefehlen abgeleitet wurden, können unten in Tabelle 2 aufgeführt werden: Tabelle 2: Beispiele für Vorschlagsbefehle

Befehl	Semantik anwenden	Beispiele
Erstellen	Objekt einfügen	Objekt einfügen und als vorgeschlagene Einfügung markieren.
Löschen	Objekt löschen	Objekt als vorgeschlagene Löschung markieren.
Modifizieren	Die dem Objekt zugeordnete Eigenschaft modifizieren.	Die dem Objekt zugeordnete Eigenschaft in einem Parallelbereich ändern.
Verschieben	Objekt zwischen zwei Orten im Bereich verschieben.	Objekt mit neuer vorgeschlagener Position kennzeichnen.
Ersetzen	Objekt durch ein anderes innerhalb desselben Bereichs ersetzen.	Objekt einfügen und sowohl eingefügtes Objekt als auch ersetztes Objekt als vorgeschlagenen Ersatz des jeweils anderen markieren.

Wie oben dargelegt wurde, kann der Vorschlagsbefehl SuggestCreate das Objekt erstellen, er markiert es aber auch als vorgeschlagene Einfügung. Dies bedeutet, dass vorgeschlagene Einfügungen den adressierbaren Bereich genau wie reguläre Einfügungen beeinflussen – zukünftige Befehle gehen von der Existenz der Objekte aus. Im Gegensatz zu einer regulären Löschung löscht SuggestDelete das Objekt tatsächlich nicht, sondern markiert es für die Löschung. Dadurch kann das ursprüngliche Objekt adressiert und verändert werden, bis der Vorschlag angenommen oder abgelehnt wird. SuggestModify bewahrt eine Reihe von parallel vorgeschlagenen Eigenschaften für ein Objekt auf. Hinweis: keiner der Framework-Befehle benötigt Vorschlagsversionen. Die Dokumentenvorlage kann dann den Vorschlagsbefehl ausführen, um bei 206 den Bearbeitungsvorschlag vorzulegen.

Weiter mit 2B, nach der Vorlage des Änderungsvorschlags bei der Dokumentenvorlage bei 207 gibt es ähnlich wie bei den Vorschlagsbefehlen für jeden Befehl entsprechende Befehle zum Annehmen und Ablehnen. Wenn eine Benutzerrückmeldung als Reaktion auf den Bearbeitungsvorschlag bei 208 eingeht, und wenn die Annahme bei 209 angezeigt wird, kann die Dokumentenvorlage auf diese Weise den Bearbeitungsvorschlag in eine angenommene Bearbeitung bei 210 umwandeln und die Dokumentenvorlage bei 211 aktualisieren. Ein auf der Basis der angenommenen Bearbeitung aktualisiertes Dokument kann für die Benutzer bei 212 veröffentlicht werden. Wenn andererseits bei 209 eine Ablehnung angezeigt wird, kann der Bearbeitungsvorschlag bei 213 aus dem Dokument entfernt werden. Das Beispiel für das Annehmen oder Ablehnen der Semantik wird unten in Tabelle 3 dargestellt: Tabelle 3: Beispiel Semantik Annehmen/Ablehnen

Befehl	Semantik anwenden	Semantik vorschlagen	Semantik annehmen	Semantik ablehnen
Erstellen	Objekt einfügen	Objekt einfügen und als vorgeschlagene Einfügung markieren.	Markierung als vorgeschlagene Einfügung aufheben.	Objekt löschen.
Löschen	Objekt löschen	Objekt als vorgeschlagene Löschung markieren.	Objekt löschen.	Markierung als vorgeschlagene Löschung aufheben.
Modifizieren	Die dem Objekt zugeordnete Eigenschaft modifiziere n.	Objekteigenschaft in Parallelbereich ändern.	Eigenschaft in echtem Bereich ändern und Parallel-Änderung entfernen.	Änderung der Eigenschaft in Parallelbereich entfernen.
Verschieben	Objekt zwischen zwei Orten im Bereich verschieben.	Objekt mit neuer vorgeschlagener Position kennzeichnen.	Kennzeichnung entfernen und Objekt tatsächlich auf diese Position bewegen.	Kennzeichnung entfernen
Ersetzen	Objekt durch ein anderes innerhalb desselben Bereichs ersetzen.	Objekt einfügen und sowohl das eingefügte Objekt als auch das ersetzte Objekt als vorgeschlagenen Ersatz des jeweils anderen markieren.	Ersetztes Objekt löschen und Markierung als eingefügtes Objekt aufheben.	Eingefügtes Objekt löschen und Markierung als ersetztes Objekt aufheben.

In Tabelle 3 kann man sehen, dass AcceptCreate die Markierung des Objekts als vorgeschlagene Einfügung aufheben kann und es damit regulär eingefügten Objekten gleichstellt. RejectCreate kann das Objekt löschen. Ganz ähnlich löscht AcceptDelete das Objekt, und RejectDelete hebt seine Markierung als vorgeschlagene Löschung auf. AcceptModify verschiebt die parallelen Eigenschaften in die regulären Eigenschaften für dieses Objekt. Dies überschreibt die regulären Eigenschaften und entfernt die parallelen Eigenschaften. RejectModify kann die parallelen Eigenschaften entfernen.
Jeder Vorschlagsbefehl hat eine ID, so dass mehrere Befehle konzeptuell als ein einziger Vorschlag verlinkt werden können. Diese IDs werden in der Vorlage in der folgenden Form aufbewahrt:

• Wenn Objekte als vorgeschlagene Einfügung oder Löschung markiert sind, wird diesem Vorschlag eine ID zugewiesen. Objekte können mehrere IDs für vorgeschlagene Einfügungen oder Löschungen besitzen.
• Wenn Eigenschaften für ein Objekt vorgeschlagen werden, werden diese in einem parallelen Bereich modifiziert. Dieser Bereich ist mit einer ID verknüpft, so dass mehrere Eigenschaftsänderungen innerhalb eines einzigen Vorschlags zusammengehalten werden. Objekte können mehrere parallele Bereiche für Eigenschaftsmodifizierungen besitzen.
• Wenn Verschiebungen vorgeschlagen werden, bleibt das Objekt an seinem Platz und wird mit dem neuen vorgeschlagenen Index gekennzeichnet. Dieser Index ist mit einer Vorschlags-ID verknüpft, so dass mehrere Vorschlags-IDs verschiedene Verschiebe-Indices vorschlagen können.
• Wird ein Ersetzen vorgeschlagen, wird angrenzend an das ursprüngliche Objekt ein neues Objekt eingefügt, und beide werden als Ersatz für das jeweils andere gekennzeichnet. Diese Kennzeichnungen als Ersatz sind mit Vorschlags-IDs verknüpft.

Das folgende Beispiel liefert Beispiel-Befehle für SuggestCreate und SuggestDelete:

1. Das Einfügen von Text vorschlagen: a. SuggestlnsertSpacers(ID: „a", Kennung: 5, Abstandshalter: „hello")
2. Das Löschen von Text vorschlagen: a. SuggestDeleteSpacers(ID: "b", Start: 10, Ende: 20)
3. Den ersten Vorschlag annehmen: a. AcceptlnsertSpacers(ID: "a", Start: 5, Ende: 9)
4. Den zweiten Vorschlag ablehnen: a. RejectDeleteSpacers(ID: "b", Start: 10, Ende: 20)

In einem weiteren Beispiel kann eine Anwendung von SuggestModify in der folgenden Tabelle dargestellt werden: Tabelle 4. Beispiele für Vorschlagsfunktionen

Die Umkehrung der Befehle Vorschlagen, Annehmen und Ablehnen kann durchgeführt werden. Da es sich um reguläre Befehle handelt, brauchen die Befehle Vorschlagen, Annehmen und Ablehnen Umkehrungen zur Unterstützung des Rückgängig-Machens dieser Operationen. Die Vorschlags- und Ablehnungsbefehle sind Umkehrungen voneinander, da Vorschlagen einen Vorschlag kreiert und Ablehnen ihn löscht, wie in der folgenden Tabelle dargestellt: Tabelle 5. Beispiel Ablehnungs-Semantik

Befehl	Semantik anwenden	Beispiele
Erstellen	Objekt einfügen und als vorgeschlagene Einfügung markieren	Objekt löschen
Löschen	Objekt als vorgeschlagene Löschung markieren.	Markierung als vorgeschlagene Löschung aufheben.
Modifizieren	Die dem Objekt zugeordnete Eigenschaft in einem Parallelbereich ändern.	Änderung der Eigenschaft in Parallelbereich entfernen.
Verschieben	Objekt mit neuer vorgeschlagener Position kennzeichnen.	Kennzeichnung entfernen.
Ersetzen	Objekt einfügen und sowohl das eingefügte Objekt als auch das ersetzte Objekt als vorgeschlagenen Ersatz des jeweils anderen markieren.	Eingefügtes Objekt löschen und Markierung des ersetzten Objekts aufheben.

Anwenden hat dennoch möglicherweise keine natürliche Umkehrung. Dies bedeutet, dass neue Befehle möglicherweise das Übernehmen eines Vorschlags umkehren müssen. Diese Befehle haben keine Umkehrungen. Alternativ kann die Umkehrung einer Annahme als die Umkehrung des ursprünglichen Befehls plus einem Vorschlag des ursprünglichen Befehls abgebildet werden. Hier kann ein Kompromiss zwischen der Anzahl der Befehle beobachtet werden, wenn für diese Befehle eine gute OT-Semantik vorliegt. Die folgende Tabelle zeigt die Umkehrsemantik für jeden Annahme-Befehl und wie diese als die Umkehrung des ursprünglichen Befehls plus einem Vorschlag abzubilden ist. Tabelle 6. Exemplarische Umkehrung der Annahme-Semantik

Befehl	Semantik annehmen	Umkehrung der Annahme-Semantik	Umkehrung des ursprünglichen Befehls plus Vorschlag
Erstellen	Markierung als vorgeschlagene Einfügung aufheben.	Als vorgeschlagene Einfügung markieren.	Objekt entfernen (Delete). Objekt einfügen und als vorgeschlagene Einfügung markieren (SuggestCreate).
Löschen	Objekt löschen. Objekt einfügen und zum Löschen markieren.	Objekt einfügen (Create).	Zum Löschen markieren (SuggestDelete).
Modifizieren	Eigenschaft in echtem Bereich modifizieren und parallele Modifikation entfernen.	Ursprüngliche Eigenschaft in echtem Bereich wiederherstellen und parallele Modifikation wiederherstellen.	Ursprüngliche Eigenschaft wiederherstellen (Modify). Eigenschaft in parallelem Bereich modifizieren (SuggestModify).
Verschieben	Kennzeichnung entfernen und Objekt tatsächlich an diese Position verschieben	Objekt an seiner ursprünglichen Position wiederherstellen und vorgeschlagene Verschiebung wiederherstellen	Objekt an seiner ursprünglichen Position wiederherstellen (Move). Vorgeschlagene Verschiebe-Kennzeichnung wiederherstellen.
Ersetzen	Ersetztes Objekt löschen und Markierung des eingefügten Objekts aufheben.	Ersetztes Objekt wiederherstellen und ersetztes und ursprüngliches als vorgeschlagene Ersatzobjekte markieren.	Eingefügtes Objekt durch ursprüngliches Objekt ersetzen (Replace). Objekt wieder einfügen und Objekte als vorgeschlagene Ersatzobjekte kennzeichnen (SuggestReplace).

Wie oben gezeigt speichert SuggestModify im Allgemeinen die vorgeschlagenen Eigenschaften getrennt von den tatsächlichen Eigenschaften ab. Wenn die Eigenschaften jedoch einen geschachtelten adressierbaren Bereich beinhalten, wie etwa eine Liste, kann dies problematisch sein. er ParagraphStyle enthält beispielsweise in eine Reihe von Tabulatoren. Wenn jemand das Einfügen (oder Löschen) eines Tabulators vorgeschlagen hat, kann dasselbe Verhalten wie reguläres Erstellen/Löschen erforderlich sein, und zwar aus denselben Gründen. Das Vorschlagen des Einfügens eines Tabulators muss diesen also in die tatsächliche Liste einfügen und als eingefügt markieren. Das Vorschlagen der Löschung eines Tabulators muss diesen als Löschung markieren. Deshalb kann das Verwenden von SuggestModify die Eigenschaft in einem parallelen Bereich nur anwenden, wenn sie sich nicht innerhalb eines geschachtelten Bereichs befindet. Andernfalls verwendet sie die übergreifende Semantik. Tabelle 7. Beispiel – Tabulatoren
Wie alle Befehle werden Vorschlagsbefehle auf dem Client über das Bearbeitungssystem erstellt. Eines der Ziele dieser Integration ist es, dass einzelne Bearbeitungen nicht mit Vorschlägen in Verbindung stehen. Dies trägt zur Minimierung des Mehraufwands zur Unterstützung von Änderungsvorschlägen für neue Funktionen bei. Der Grundansatz ist es, jeden Befehl zu nehmen, der von der regulären Bearbeitung angewendet worden wäre, die Vorschlagsversion des Befehls zu erstellen und diese stattdessen zu übernehmen. Dies macht jedoch ein Problem sichtbar: Die Semantik des Vorschlagsbefehls ist nicht mit dem regulären Befehl identisch. Ein SuggestDelete löscht beispielsweise tatsächlich nicht das Objekt. Deshalb kann sich die Bearbeitung nicht auf die Verwendung von Befehlen verlassen, die bestimmte Änderungen am ModelState erzeugen. Um dies zu lösen, kann eine Kopie des ursprünglichen ModelState gemacht werden und die reguläre Bearbeitungsfunktion kann auf diese Kopie angewendet werden. Dies kann dafür sorgen, dass alle Annahmen der Bearbeitung darüber, wie sich der ModelState verändert, korrekt sind. Dann können diejenigen Befehle verwendet werden, die ursprünglich angewendet wurden, um die Vorschlagsversion eines jeden von diesen zu erzeugen. Jedoch kann aufgrund der unterschiedlichen Semantik jeder Vorschlagsbefehl auf der Basis von früheren Vorschlagsbefehlen angepasst werden. Befehle, die von einem DragDropEdit-Vorschlag erzeugt wurden, können beispielsweise beinhalten:

1. DeleteSpacers(5, 10)
2. InsertSpacers "hello" @ 50

Vorschlagsversionen dieser Befehle können beinhalten:

1. SuggestDeleteSpacers(5, 10)
2. SuggestlnsertSpacers "hello" @ 56

Um die Vorschlagsversion der Befehle zu erzeugen, kann folgendes durchgeführt werden:

1. SuggestDeleteSpacers(5, 10) aus DeleteSpacers(5, 10) erzeugen.
2. Aus SuggestDeleteSpacers den passenden Transformationsbefehl erzeugen.
3. SuggestlnsertSpacers "hello" @ 50 aus InsertSpacers "hello" @ 50 erzeugen.
4. SuggestInsertSpacers gegen den Transformationsbefehl transformieren, ergibt SuggestlnsertSpacers "hello" @ 56.

In einer Implementierung können exemplarische Objektklassen, die an einer Vorschlagsbearbeitungsumgebung für Dokumente beteiligt sind, eine ähnliche Form wie die folgenden Pseudo-Code-Segmente annehmen:
Das Annehmen und Ablehnen von Vorschlägen wird auch über Bearbeitungen vorgenommen: über AcceptEdit und über RejectEdit. Diese Bearbeitungen können nur von Redakteuren durchgeführt werden. Sie werden ausgelöst, wenn annehmen/ablehnen aus dem Vorschlagskommentar gewählt wird. Die Bearbeitung erhält die Vorschlags-ID zum Annehmen/Ablehnen, und überprüft dann die Vorlage, um zu ermitteln, welche Änderungen mit dieser ID verknüpft sind. Die entsprechenden Befehle zum Annehmen/Ablehnen können dann auf diese Änderungen angewendet werden. Beachten: da dies vom Überprüfen der Vorlage und vom Erzeugen von Befehlen zum Annehmen/Ablehnen abhängt, gibt es keine gemeinsame Implementierung dieser Bearbeitungen. Exemplarische Objektklassen, die an der Annahme oder Ablehnung eines Vorschlags beteiligt sind, können eine ähnliche Form wie die folgenden Pseudo-Code-Segmente annehmen:
Bei einer Implementierung können die Vorschlagenden SuggestDeletes anstelle von regulären Deletes ausgeben, so dass Objekte zum Löschen markiert werden und nicht tatsächlich gelöscht werden. Wenn es sich jedoch um ein Objekt handelt, das ursprünglich vom selben Benutzer vorgeschlagen wurde, darf der Benutzer es löschen. Wenn ein Benutzer zum Beispiel das Einfügen von „dei Katze“ vorschlägt, kann er auf den Vorschlag zugreifen und den Tippfehler korrigieren. Dies wird dadurch erreicht, dass der entsprechende Befehl auf der Basis des aktuellen Kontexts von getSuggestCommand zurückgegeben wird. Um stärker eingeschränkte Semantiken zuzulassen, kann eine eigener Befehl für Vorschlagende erstellt werden, eine Bewertung herauszugeben und dann zu verwenden, um sicherzustellen, dass sie keine beliebigen Objekte löschen können.
Bei einer Implementierung kann die Access Control List (ACL), die dem Dokument zugewiesen ist, auf Vorschläge überprüft werden. Benutzer haben beispielsweise in der Kommentatoren-Rolle bereits die Möglichkeit, Befehle auf die Vorlage anzuwenden, so dass sie Befehle ausführen können, die die Position ihrer Kommentare nachverfolgen. Dennoch gibt es Einschränkungen auf die Befehle, die ausgeführt werden können, und zwar über die Oberfläche CommandPermissionChecker. Mit dem Vorschlagen von Änderungen sollte es leicht sein, diese Überprüfung durchzuführen, da es eine eigene Reihe von Befehlen gibt, die Vorschlagende ausgeben können:

• Vorschlagsbefehle, so dass sie Vorschläge machen können.
• Befehle zum Ablehnen, so dass sie Vorschläge rückgängig machen können (und womöglich zum Ablehnen ihrer eigenen Bearbeitungen).
• Den besonderen Lösch-Befehl zum Löschen innerhalb von Vorschlägen.
• MultiCommands und ReverseCommand (enthalten nur andere erlaubte Befehle).
• NullCommand.

Dies verhindert, dass Vorschlagende tatsächliche Änderungen am Dokument vornehmen können. Dennoch ist ein stärker einschränkender ACL-Überprüfungsmechanismus vorstellbar, wobei Vorschlagende daran gehindert werden können, auf gegenseitige Vorschläge einzuwirken. Dieser stärker einschränkende Überprüfungsmechanismus wird zurzeit nicht bei Kommentaren ausgeführt – Kommentatoren dürfen Kommentare für Ankerkommentare anwenden, unabhängig davon, wer der Eigentümer dieses Kommentars ist. Die Ausführung dieses stärker einschränkenden Überprüfungsmechanismus wäre kompliziert, da es Kenntnis darüber erfordert, wer der Eigentümer jeder Vorschlags-ID ist, was nicht als Teil der Dokumentenvorlage abgespeichert wird. Stattdessen werden diese Befehle zuverlässig nicht vom UI ausgegeben, und die ACL-Überprüfungen können basierend auf der Rolle, und nicht basierend auf dem Individuum durchgeführt werden.
Vorschläge von verschiedenen Benutzern, Accounts und/oder Vorschlags-IDs können zusammengeführt werden. Im Vorschlagsmodus erzeugen nicht alle Bearbeitungen Befehle mit neuen Vorschlags-IDs. Das Tippen eines Satzes sollte beispielsweise in verschiedenen Bearbeitungen einen einzigen Vorschlag erzeugen. Dies wird „zusammengeführte Vorschläge“ genannt. Da Vorschläge pauschal angenommen oder abgelehnt werden müssen, ermittelt das Zusammenführen diese Granularität. Eine exemplarische Zusammenführung von Vorschlägen wird im folgenden Beispiel dargestellt:

1. Im Vorschlagsmodus ein Zeichen eingeben: a. SuggestlnsertSpacers(ID: „a", Kennung: 5, Abstandshalter: "h")
2. Ein weiteres Zeichen eingeben: a. SuggestlnsertSpacers(ID: „a", Kennung: 6, Abstandshalter: "i") i. Hinweis: die ID ist dieselbe. Beide Einfügungen sind nun Teil desselben Vorschlags.
3. Den Vorschlag annehmen: a. AcceptInsertSpacers(ID: "a", Start: 5, Ende: 6)
4. oder den Vorschlag ablehnen: a. RejectInsertSpacers(ID: "a", Start: 5, Ende: 6)

Vor der Ausführung eines Befehls kann die Vorlage überprüft werden, um zu ermitteln, mit welchem Vorschlag, falls überhaupt, dieser Befehl zusammengeführt würde. Wenn alle Befehle in einer Bearbeitung Vorschlags-IDs ergeben, deren Eigentümer der aktuelle Benutzer ist, dann können diese Vorschlags-IDs verwendet werden. Andernfalls kann eine neue Vorschlags-ID erzeugt werden. Werden IDs auf diese Weise überprüft, können Fälle wie etwa Drag/Drop und Finden über Vorschläge hinweg unterstützt und ersetzt werden. Die folgenden Beispiele stellen den Prozess der Zusammenführung dar: Tabelle 8. Beispiel: Zusammengeführte Vorschläge

Befehle in der Bearbeitung	Zusammenführungs-ID	Zusammenführen?	Ergebnis Vorschlagsbefehl
ApplyStyle innerhalb von Vorschlag A, dessen Eigentümer der aktuelle Benutzer ist	A	Ja	SuggestApplyStyle(A)
ApplyStyle innerhalb des regulären Textes	Null	Nein	SuggestApplyStyle(new ID)
ApplyStyle innerhalb von Vorschlag B, dessen Eigentümer jemand anderer ist	B	Nein	SuggestApplyStyle(new ID)
ApplyStyle auf Vorschlag A und normalen Text	Null	Nein	SuggestApplyStyle(new ID)
1) ApplyStyle innerhalb von Vorschlag A, dessen Eigentümer der aktuelle Benutzer ist 2) ApplyStyle innerhalb von Vorschlag B, dessen Eigentümer der aktuelle Benutzer ist	1) A 2) B	Ja	1) SuggestApplyStyle(A) 2) SuggestApplyStyle(B)

Ein Problem bei dieser Vorgehensweise ist, dass sie es erfordert, die zusammengeführten Vorschlagsdaten zu berechnen, während die ursprünglichen Bearbeitungen in der Kopie des ModelState umgesetzt werden. Die zusammengeführten Vorschlagsdaten werden berechnet, bevor jede entpackte Anweisung ausgeführt wird, wie Umkehrung. Die zusammengeführten Vorschlagsdaten müssten auch aus der ursprünglichen Bearbeitung heraus zurückgegeben werden, wie die Rückgängig-Befehle. Ein Mechanismus, der ein ähnliches Muster implementiert, wie für die Umkehrung verwendet, kann übernommen werden, um die zusammengeführten Vorschlagsdaten zu berechnen und zurückzugeben. Ein Befehls-Präprozessor kann beispielsweise für die Zusammenführung der Vorschläge verwendet werden, und der Präprozessor kann ebenfalls für die Umkehrung angepasst werden.
Ein weiteres Beispiel für die Anwendung der Vorschlags-Dokumentenvorlage ist die Verarbeitung von zusammengesetzten Vorschlägen. Zusammengesetzte Vorschläge sind Vorschläge, die innerhalb von anderen Vorschlägen erzeugt werden. Ein Benutzer schlägt beispielsweise die Einfügung eines Satzes vor, und ein anderer Benutzer schlägt die Einfügung eines Worts innerhalb dieses Satzes vor. Aus der Perspektive der Bearbeitungsvorlage sehen zusammengesetzte Vorschläge genau wie zwei reguläre Vorschläge aus: mit zwei unabhängigen, einmaligen Vorschlags-IDs. Wenn es kein spezielles UI für das Zusammensetzen gibt, dann werden diese Vorschläge einfach als zwei unterschiedliche Vorschläge in den Kommentaren angezeigt, aber als sich überschneidende Bereiche im kollaborativen Dokument, sehr ähnlich wie zurzeit die sich überschneidenden Kommentare. Redakteure hätten die Möglichkeit, den innersten Vorschlag unabhängig von dem äußersten Vorschlag anzunehmen. Dies verhält sich genau so, als ob die Redakteure die Änderungen selbst vornehmen würden. Wenn für die Zusammenführung von Vorschlägen ein eigenes UI verwendet wird, kann die Beziehung zwischen den Vorschlags-IDs an einem anderen Ort gespeichert werden. Das aktuelle UI schlägt beispielsweise vor, zusammengesetzte Vorschläge innerhalb eines einzelnen Kommentars anzuzeigen, also kann diese Beziehung in den Kommentaren gespeichert werden.
Um zu ermitteln, ob ein Bearbeitungsvorschlag mit einer weiteren Bearbeitung zusammengesetzt werden soll, kann ein Mechanismus, der dem oben erwähnten zur Bestimmung der Zusammenführung ähnelt, verwendet werden. Angesichts der Reihe der Vorschlags-IDs für jeden Befehl kann eine ähnliche Heuristik verwendet werden: Wenn alle IDs gleich sind, und der aktuelle Benutzer nicht der Eigentümer des Vorschlags ist, dann kann die spezielle Vorschlags-ID zusammengesetzt werden.
Ein weiteres Beispiel für die Verwendung der Vorschlags-Dokumentenvorlage ist es, Wechselvorschläge zu verarbeiten. Wechselvorschläge sind Vorschläge, die im Konflikt miteinander stehen. Wenn beispielsweise ein Benutzer die Löschung eines Satzes vorschlägt, während ein weiterer Benutzer die Einfügung eines Wortes in diesen Satz vorschlägt. Für Wechselvorschläge wird kein besonderer Speicherplatz bereitgestellt. Wenn ein eigenes UI für Wechselvorschläge gewünscht wird, können die Wechselvorschläge auf der Client-Seite erkannt werden, indem die Vorlage überprüft wird.
Die Dokumentenvorlage kann ein UI bereitstellen, um dem Benutzer Vorschläge zu präsentieren, z. B. einen „Ansichtsmodus“. Die Dokumentenvorlage kann im „Lesemodus“ den Status der Vorlagenvorschläge lesen und entsprechend wiedergeben. Sie kann beispielsweise ermitteln, dass bestimmte Abstandshalter vorgeschlagene Einfügungen sind, und sie in der Kollaborativ-Farbe für den Benutzer wiedergeben, der den Vorschlag gemacht hat. Alternativ kann sie ermitteln, dass bestimmte Abstandshalter vorgeschlagene Löschungen sind, und beide als durchgestrichen und in der entsprechenden Farbe wiedergeben.
Ein Vorschlag kann in den Kommentaren Begleitdaten haben, und ein Kommentar wird für jeden Vorschlag angezeigt. Die Kommentare speichern die folgenden Basisdaten abgekoppelt von der Vorschlags-ID:

1. Benutzer, der den Vorschlag gemacht hat.
2. Zeitstempel des Vorschlags.
3. Einige Metadaten, die erklären, worum es sich bei dem Vorschlag handelt.
4. Ob der Vorschlag angenommen oder abgelehnt wurde.

Benutzer dürfen Vorschläge kommentieren wie bei regulären Kommentaren. Zusätzlich dazu verfügen Vorschläge über Schaltflächen, die es den Redakteuren ermöglichen, sie anzunehmen/abzulehnen. Wenn dies passiert, wird der Befehls-Thread gekennzeichnet, sehr ähnlich dem Lösen und erneuten Öffnen von Kommentaren. Vorschlagskommentare enthalten Text, der erklärt, was der Vorschlag macht. Dies wird von den Metadaten abgeleitet. Die Metadaten sind strukturiert und spezifisch für die App, obwohl einige auch allgemeiner Natur sein können. Beispiele möglicher Metadaten können eine Form annehmen, die der folgenden ähnlich ist:
Zusätzliche Daten zur Unterstützung von zusammengesetzten Vorschlägen können eingegeben werden. Kopieren und Einfügen beachtet zusätzlich dazu, was mit den Kommentars-Daten geschieht.
Ein weiteres Anwendungsbeispiel für die Vorschlags-Dokumentenvorlage ist die Bearbeitung von Metadaten. Um die Metadaten eines Vorschlags zu generieren, kann die EditMetadata-Funktion aufgerufen werden, die diesem Zweck bereits dient, um Bearbeitungen für den Zugriff zu verbalisieren. EditMetadata gibt Details dazu an, was genau die Bearbeitung macht. Die Klasse pro Bearbeitung, die mit den Metadaten die entsprechenden Kommentare erzeugt, kann übernommen werden.
Reguläre Bearbeitungen in den Vorschlägen können über die Dokumentenvorlage ausgeführt werden. Benutzer im Bearbeitungsmodus dürfen alles, inklusive Vorschläge, beeinflussen. Wenn ein Redakteur einen Vorschlag ändert, wird diese Änderung sofort umgesetzt – sie wird nicht zusammengesetzt oder als Vorschlag erzeugt. Um die Autorenschaft darüber, wer tatsächlich was vorschlägt, nachverfolgen zu können, kann der Kommentar mit Text versehen werden, der erklärt, was der Redakteur getan hat. Dies kann dadurch erfolgen, dass die Metadaten für die Bearbeitung erzeugt und an den Kommentar-Thread für diesen Vorschlag angehängt werden.
Ein weiteres Anwendungsbeispiel für die Vorschlags-Dokumentenvorlage ist das Filtern von Vorschlägen. 3 liefert exemplarische Ablaufdiagramme, die Merkmale der Vorgehensweise beim Filtern von Vorschlägen für eine Dokumentenvorlage darstellen.
Die Dokumentenvorlage O 301 kann einen Modus bereitstellen, wobei Redakteure Vorschläge herausfiltern können. Diese Filter können nach Benutzer oder Vorschlagstyp (Einfügungen, Formatierungen etc.) organisiert sein. Um Flexibilität dabei zu gewähren, welche Filter genau unterstützt werden können, kann Filtern zugelassen werden, indem eine willkürliche Reihe von Befehlen ausgeführt wird und dann die Client- und Server-Befehle transformiert werden, während sie hin und zurückgesendet werden. Um einen Filter zu erstellen, kann ein Befehl C 302 auf die Vorlage O 301 angewendet werden. Dies erzeugt eine neue Vorlage M 303, die für Client-Ansicht und -Controller verwendet werden kann, und die dafür sorgt, dass die Client- und Steuerungs-Logik unabhängig von der Filterung unverändert bleiben.
Bei der Erzeugung der Filter-Anweisung C 302 kann auch die Umkehrung I(C) 304 erzeugt werden. Zusätzlich dazu können zwei Vorlagen, 301 und 303, behalten werden: die ursprüngliche Vorlage 301 vor dem Filtern und die neue Vorlage 303 nach dem Filtern. Diese beiden Vorlagen können es ermöglichen, beim Transformieren die entsprechenden Umkehrungen zu erzeugen.
Der Filter-Algorithmus kann auf ähnliche Weise wie im Folgenden dargestellt funktionieren (dargestellt in 3(a)):

1. Die Filter-Anweisung C 302 erzeugen.
2. Die Filter-Umkehrungsanweisung I(C) 304 durch reguläre Umkehrung erzeugen.
3. Vorlage kopieren und dabei die ursprüngliche O 301 und die Kopie M 303 behalten, die zur neuen Vorlage wird.
4. Befehl C 302 auf die neue Vorlage M 303 anwenden.

Jede vom Client-Controller erzeugte Anweisung kann direkt auf M angewendet werden. Um diese Befehle zum Server zu senden, müssen sie gegen I(C) transformiert werden. In einem Beispiel kann der volle Algorithmus wie folgt ausgeführt werden (dargestellt in 3(b)):

1. Befehl X 305 auf die Vorlage M 303 anwenden. Dies ergibt die neue Vorlage M‘ 307.
2. X 305 gegen I(C) 304 transformieren, was X‘ 309 und I(C)‘ 310 ergibt.
3. X‘309 auf die ursprüngliche Vorlage O 301 anwenden. Dies ergibt die neue ursprüngliche Vorlage O‘ 312.
4. X‘ 309 an den Server senden.
5. Der neue Filter-Umkehrungsbefehl ist jetzt I(C)‘ 310.
6. Den neuen Filter-Befehl durch Umkehren von I(C)‘ 310 erstellen.

301

303

302

3(c)

1. Befehl X 305 auf die ursprüngliche Vorlage O 301 anwenden. Dies ergibt die neue ursprüngliche Vorlage 0‘ 312.
2. X 305 gegen C 302 transformieren, was X‘ 309 und C‘ 315 ergibt.
3. X‘ 309 auf die Vorlage M 303 anwenden. Dies ergibt die neue Vorlage M‘ 307.
4. Der neue Filterbefehl ist jetzt C‘ 315.
5. Den neuen Filter-Umkehrungsbefehl durch Umkehren von C‘ 315 erzeugen.

Um den Vorschlagsfilter aufzuheben, kann I(C) 304 auf die Vorlage M 303 angewendet werden, was sie nun zu einem Äquivalent der ursprünglichen Vorlage O 301 macht. Hinweis: anstelle der Verwendung der Umkehrung kann stattdessen die Vorlage M 303 durch die ursprüngliche Vorlage O 301 ersetzt werden. Dies bedeutet, dass I(C) 304 möglicherweise nicht angewendet werden muss, und stattdessen Auslassungsbefehle anstelle von Umkehrungen verwendet werden können. Auf diese Weise kann der Transformationsschicht kein Zugriff auf die ursprüngliche Vorlage gegeben werden. Dennoch kann die ursprüngliche Vorlage auf dem neuesten Stand gehalten werden, da sie zur Stabilisierung verwendet werden kann.
Ein weiteres Beispiel für die Verwendung der Vorschlags-Dokumentenvorlage ist die Implementierung von Server-Änderungen. Vorschläge sind nur für Benutzer im Bearbeitungs- oder Kommentarmodus sichtbar. Ansichts-, Vorschau- und Veröffentlichungsmodi können keine Vorschläge anzeigen. Dies kann eine ähnliche Logik wie beim Filtern auf Server-Seite erforderlich machen. Der Server kann in der Lage sein, eine Vorlage zu produzieren, aus der die Vorschläge gestrichen wurden, und wann diese Vorlage anstelle der regulären Vorlage benutzt werden sollte. Beispiele, wobei Vorschläge entfernt werden können, beinhalten:

1. Ansichts-, Vorschau- und Veröffentlichungsmodi.
2. Export.
3. Indizierbaren Text und Thumbnails.

Hinweis: für einige der o.g. Fälle, wie etwa Export und indizierbaren Text, kann abhängig von der Zugriffsebene eine andere Logik implementiert werden, um einen Funktionalitätsverlust zu verhindern.
Vorgeschlagene Einfügungen werden dadurch dargestellt, dass ein Textbereich mit einer vorgeschlagenen Einfügungs-ID markiert wird. Einfügungen von Absätzen werden ähnlich dargestellt – die Absatzmarke wird für die Einfügung markiert. Nachstehend ein exemplarisches Pseudo-Code-Segment der Einfügung „hello“ als nachverfolgte Änderung in einem Extensible Markup Language (XML) Format.
Die Markierung w:ins wird verwendet um anzugeben, dass ihr Inhalt für die Einfügung nachverfolgt wird. Die Markierung enthält ID (w:id), Autor (w:author) und Datum (w:date) der Änderung. Im obigen Beispiel enthält die Einfügung eine Textausführung (w:r) mit „hello“ als Text (w:t). Nachstehend ein exemplarisches Pseudo-Code-Segment der Einfügung eines Zeilenumbruchs nach „hello“ als nachverfolgte Änderung in einem XML-Format:
Die Markierung w:ins ohne Inhalt wird verwendet, um anzuzeigen, dass der Zeilenumbruch für die Einfügung markiert ist. Die Markierung enthält ID (w:id), Autor (w:author) und Datum (w:date) der Änderung.
Ein weiteres Anwendungsbeispiel für die Vorschlags-Dokumentenvorlage ist die Verarbeitung von Löschungen im Text. Vorgeschlagene Löschungen werden dadurch dargestellt, dass ein Textbereich mit einer vorgeschlagenen Löschungs-ID markiert wird. Absatzlöschungen werden ähnlich dargestellt – die Absatzmarke wird für die Löschung markiert.
Nachstehend ein exemplarisches Pseudo-Code-Segment der Markierung von „hello“ als nachverfolgte Löschung ein einem XML-Format.
Die Markierung w:del wird verwendet um anzugeben, dass ihr Inhalt für die Löschung nachverfolgt wird. Die Markierung enthält ID (w:id), Autor (w:author) und Datum (w:date) der Änderung. Im obigen Beispiel enthält die Löschung eine Textausführung (w:r) mit „hello“ als Text (w:delText). Nachstehend ein exemplarisches Pseudo-Code-Segment der Markierung des Zeilenumbruchs nach „hello“ als nachverfolgte Löschung in einem XML-Format.
Die Markierung w:ins ohne Inhalt wird verwendet, um anzuzeigen, dass der Zeilenumbruch für die Löschung nachverfolgt wird. Die Markierung enthält ID (w:id), Autor (w:author) und Datum (w:date) der Änderung.
Vorgeschlagene Formatvorlagen werden über eine Zuordnung von der Vorschlags-ID zu den vorgeschlagenen Eigenschaften dargestellt. Diese Zuordnung wird auf einen Textbereich angewendet. Nachstehend ein exemplarisches Pseudo-Code-Segment der Anwendung von „bold“ als nachverfolgte Änderung in einem XML-Format. Dieses Wort ist bereits kursiv.
Es gibt eine Textausführung (w:r) mit einer Markierung für die Ausführungseigenschaften (w:Pr) und Text (w:t). Die Ausführungseigenschaften enthalten die aktuellen Eigenschaften einschließlich der nachverfolgten Änderung: fett (w:b) und kursiv (w:i). Sie enthalten auch eine Änderungsmarkierung für die Ausführungseigenschaften (w:PrChange), die die Eigenschaften vor der Anwendung des nachverfolgten Formats enthält, das nur kursiv ist (w:i). Die Markierung für die Eigenschaftsänderung enthält auch ID (w:id), Autor (w:author) und Datum (w:date) der Änderung.
Vorgeschlagene Absatzformate werden über eine Zuordnung von der Vorschlags-ID zu den vorgeschlagenen Eigenschaften dargestellt. Diese Zuordnung wird auf die Absatzmarke angewendet. Nachstehend ein exemplarisches Pseudo-Code-Segment der Anwendung von „center“ als nachverfolgte Änderung an einem Absatz, der „hello“ enthält, in einem XML-Format. Der Absatz enthielt bereits Zeilenabstandseinstellungen.
Es gibt eine Absatzausführung (w:p) mit einer Markierung für die Absatzeigenschaften (w:pPr) und einer Textausführung (w:r). Die Absatzeigenschaften enthalten die aktuellen Eigenschaften einschließlich der nachverfolgten Änderung: Zeilenabstand (w:spacing) und Ausrichtung (w:jc). Sie enthalten auch eine Änderungsmarkierung für die Ausführung der Eigenschaften (w:pPrChange), die die Eigenschaften vor der Anwendung des nachverfolgten Formats enthält, das nur Zeilenabstand ist (w:spacing). Die Markierung für die Eigenschaftsänderung enthält auch ID (w:id), Autor (w:author) und Datum (w:date) der Änderung.
Vorgeschlagene Listenformate werden über eine Zuordnung von der Vorschlags-ID zu den vorgeschlagenen Eigenschaften dargestellt. Diese Zuordnung wird auf die Absatzmarke angewendet. Änderungsvorschläge, die sich auf die Listen-Entität auswirken, werden ebenfalls über eine Zuordnung von einer Vorschlags-ID auf Eigenschaften dargestellt. Diese Zuordnung wird auf die Listen-Entität angewendet.
Nachstehend ein exemplarisches Pseudo-Code-Segment der Hinzufügung des Absatzes, der „hello“ enthält, zu einer Liste als nachverfolgte Änderung in einem XML-Format.
Es gibt eine Absatzausführung (w:p) mit einer Markierung für die Absatzeigenschaften (w:pPr) und einer Textausführung (w:r). Die Absatzeigenschaften enthalten die aktuellen Eigenschaften einschließlich der nachverfolgten Änderung: Anwendung des „ListParagraph“ genannten Formats (w:pStyle), und Hinzufügen des Absatzes zur Listen-ID „3“ (w:numId) auf Schachtelungsebene „0“ (w:i1v1). Sie enthalten auch eine Änderungsmarkierung für die Ausführungseigenschaften (w:pPrChange), die die Eigenschaften vor der Anwendung des nachverfolgten Formats enthält, das leer ist (w:pPr/). Die Markierung für die Eigenschaftsänderung enthält auch ID (w:id), Autor (w:author) und Datum (w:date) der Änderung.
Eine weitere hier beschriebene Ausführungsform beinhaltet Systeme und Verfahren zum Zusammenführen von Bearbeitungen innerhalb eines kollaborativ bearbeiteten Dokuments. Ein Dokument-Editor kann Benutzern erlauben, Bearbeitungen als Vorschläge durchzuführen, die nachverfolgt werden können und vor der Übernahme ins Dokument angenommen oder abgelehnt werden. Diese Vorschläge liegen als deutlich erkennbare Änderungen am Dokument vor, die unabhängig voneinander angenommen oder abgelehnt werden können. Während ein Benutzer einzelne Aktionen durchführt, um das Dokument zu bearbeiten, wie etwa das Eingeben von Zeichen, ist es nicht wünschenswert, dass jede dieser Aktionen einzeln einen separaten Vorschlag erzeugt. Insbesondere, wenn ein Lektor eines Dokuments das Dokument öffnet und Bearbeitungsvorschläge für das Dokument erzeugt, sollten nicht alle Bearbeitungen Befehle mit neuen Vorschlags-Kennungen erzeugen. Das Tippen eines Satzes sollte beispielsweise in verschiedenen Bearbeitungen einen einzigen Vorschlag erzeugen. Diese werden zusammengeführte Vorschläge genannt, da der einzelne Vorschlag aus mehrteiligen Bearbeitungen oder Varianten entstand. Da Vorschläge pauschal angenommen oder abgelehnt werden müssen, ermittelt das Zusammenführen die Granularität für Vorschläge.
Die Systeme und Verfahren der sechsten exemplarischen Ausführungsform der vorliegenden Offenbarung ermitteln, ob eine aktuelle Änderung an der Vorlage mit einem existierenden Vorschlag zusammengeführt werden soll, oder ob diese Änderung einen neuen Vorschlag erzeugen soll. Die Systeme und Verfahren der vorliegenden Offenbarung sind allgemein genug, um bei jeder beliebigen Änderung oder Änderungssammlung an einer Dokumentenvorlage gut zu funktionieren. Existierende Systeme berücksichtigen nicht die ganze Dokumentenvorlage und behalten weder Konsistenz noch Benutzerabsichten bei.
4A–4B zeigen ein exemplarisches Ablaufdiagramm 400, das Merkmale der Zusammenführung von vorgeschlagenen Bearbeitungen veranschaulicht. Beginnend bei 401, als Reaktion auf einen eingegangenen Bearbeitungsvorschlag (z. B. 202 in 2A), kann ein Dokument-Editor auf einem Server oder Benutzergerät ermitteln, ob der eingegangene Bearbeitungsvorschlag mit einem existierenden Bearbeitungsvorschlag zusammengeführt werden soll, oder ob ein neuer Vorschlag erstellt werden soll. Der Dokument-Editor kann eine oder mehr Varianten ermitteln, die dem Bearbeitungsvorschlag zugewiesen sind. Änderungen können beispielsweise an einer Dokumentenvorlage über eine Reihe von schrittweisen winzig kleinen Varianten beschrieben werden. In der Textbearbeitungsumgebung eines Dokuments, wie etwa einem Textbearbeitungsprogramm, können Varianten das Einfügen von Zeichen, das Löschen von Zeichen, das Anwenden von Formatvorlagen oder jede Andere Art von Änderung beinhalten, die an einem Textdokument vorgenommen werden kann. Ein einzelner Bearbeitungsvorschlag für ein Dokument kann in verschiedene Varianten resultieren, die auf die Vorlage angewendet werden.
Der Bearbeitungsvorschlag kann beispielsweise das Hinzufügen eines Wortes oder Satzes einschließlich mehrerer Zeicheneinfügungen beinhalten. In einem weiteren Beispiel kann der Bearbeitungsvorschlag das Ersetzen eines existierenden Satzes durch einen anderen Satz beinhalten. Dieser Bearbeitungsvorschlag würde mehrere Zeichenlöschungen und mehrere Zeicheneinfügungen beinhalten. In einem weiteren Beispiel kann der Bearbeitungsvorschlag das Einfügen eines oder mehrerer Zeichen und das Anwenden einer Änderung der Formatvorlage an den eingefügten Zeichen beinhalten. In jedem Beispiel beinhaltet der Bearbeitungsvorschlag mehrere Varianten am Dokument. Es ist allgemein wünschenswert, während des sequentiellen Eingangs von Varianten zu ermitteln, ob eine aktuelle Variante mit einer vorangegangenen Variante zusammengeführt werden soll, und zwar als Teil einer einzigen Bearbeitung, oder ob eine aktuelle Variante als Teil einer neuen Bearbeitung gekennzeichnet werden soll.
Hier werden Systeme und Verfahren bereitgestellt, die ermitteln, ob eine aktuelle Änderung an einem Dokument mit einem existierenden Bearbeitungsvorschlag zusammengeführt werden soll, oder ob ein neuer Bearbeitungsvorschlag auf der Basis der aktuellen Änderung erstellt werden soll. Ein Dokument-Editor verfügt über Logik zur Ermittlung, welche Varianten im Dokument auf der Basis der Aktionen des Benutzers und des aktuellen Status des Dokument-Editors umzusetzen sind.
Der Dokument-Editor kann dann, bei 402, eine Funktion für jede Variante definieren. Die Funktion ermittelt, mit welchen Vorschlägen eine Variante zusammengeführt werden kann. Diese Funktion kann für die besonderen Varianten und Dokumentenvorlagen in der Bearbeitungsanwendung definiert werden. Als Beispiel kann in einem Dokument-Editor die Variante, Zeichen einzufügen, zusammengeführt werden mit jedem vorgeschlagenen Text, der vor, nach oder um den eingefügten Text herum vorkommt.
Zusätzlich kann diese Funktion eine Zusammenführungs-Priorität für die Variante ermitteln. In einem Beispiel sind Varianten in einer Prioritäten-Reihenfolge sortiert, so dass einschneidendere Änderungen am Dokument vor weniger einschneidenden Änderungen berücksichtigt werden können. Wenn zum Beispiel ein Bearbeitungsvorschlag sowohl eine Einfügung von Text als auch eine Anwendung einer Formatvorlage beinhaltet, kann die Position der Einfügung ein wahrscheinlicherer Kandidat für die Zusammenführung sein als die Position der Anwendung der Formatvorlage. In diesem Fall kann die Einfügungsvariante vor der Änderung der Anwendung der Formatvorlage priorisiert werden.
Während Varianten auf die Vorlage angewendet werden, wird die Funktion ausgeführt, die eine Liste aller möglichen Zusammenführungsvorschläge und -prioritäten erkennt, bei 403. Dann kann die Dokumentenvorlage ermitteln, ob eine der Varianten aus der Liste herausgefiltert werden muss, bei 405. Alle Vorschläge, deren Eigentümer nicht der aktuelle Benutzer ist, können beispielsweise aus der Liste entfernt oder herausgefiltert werden, bei 406. Ein derartiges Filtern der Liste sorgt dafür, dass Vorschläge, die vom aktuellen Benutzer gemacht werden, nicht mit den Vorschlägen, die von anderen Benutzern gemacht werden, zusammengeführt werden, und erzeugt stattdessen neue Vorschläge, deren Eigentümer der aktuelle Benutzer ist. Alternativ kann die Funktion einen oder mehrere Filter beinhalten, so dass alle möglichen Prioritäten von Zusammenführungs-Vorschlägen in der Liste, die von der Funktion erkannt werden, nur dem aktuellen Benutzer zugewiesen werden und nicht anderen Benutzern.
Im Allgemeinen hat bei der Entscheidung, ob Bearbeitungsvorschläge zusammengeführt werden sollen, das Einfügen und Löschen von regulärem Text die höchste Priorität. Die Vorschläge, mit denen Einfügungen und Löschungen von Text zusammengeführt werden können, werden gemäß der vorgenannten Heuristik festgelegt. Insbesondere ergeben Einfügungen Vorschläge zur Zusammenführung von Einfügungen oder Löschungen vor oder nach der Einfügungsposition. Löschungen ergeben Vorschläge zur Zusammenführung für alle Löschungen oder Einfügungen vor, nach oder innerhalb des gelöschten Bereichs. Formatbezogene Änderungen sind von zweitrangiger Priorität. Dies beinhaltet beispielsweise Text- und Absatzformate, Änderungen an Listen und Links. Diese Bearbeitungen werden nur zusammengeführt, wenn der formatierte Bereich gänzlich in der Löschung oder Einfügung enthalten ist. Sie werden auch mit anderen Formatvorschlägen zusammengeführt, wenn der Bereich derselbe ist, oder sich innerhalb anderer Formatvorlagen befindet und dieselben Eigenschaften betrifft. Die Löschung von zweitrangigem Text hat zweitrangige Priorität und wird mit anderen Löschungen desselben Textes zusammengeführt. Zweitrangiger Text ist Text außerhalb des Haupttextteils des Dokuments, der sich im Allgemeinen auf das Dokument bezieht, wie etwa Kopfzeilen, Fußzeilen und Fußnoten. Die Einfügung von zweitrangigem Text hat die niedrigste Priorität und ergibt keine Vorschläge zur Zusammenführung. Dieser Text erzeugt immer einen neuen Vorschlag (wie etwa im Fall von Kopfzeilen und Fußzeilen), oder er bezieht sich auf Haupttext, wie zum Beispiel Fußnoten, und verwendet deswegen die Heuristik für die Zusammenführung von Haupttext.
Bei der Bestimmung, wie Bearbeitungsvorschläge zusammengeführt werden, kann das Verfahren der exemplarischen Ausführungsform ein Kategorien-Framework beinhalten, das die Priorität festlegt, die den Zusammenführungen, die in die entsprechende Kategorie fallen, zugewiesen ist. Jedem Vorschlag kann eine Kennung für einen Zusammenführungsvorschlag zugeordnet werden, die die vorgeschlagene Aktion identifiziert und ebenfalls die Prioritäten-Kategorie des Änderungsvorschlags. Diese Prioritäten-Kategorien sind in Beispielkategorien von erstrangigen, zweitrangigen und neutralen Zusammenführungen eingeteilt, abhängig von der Priorität, mit der der Bearbeitungsvorschlag zusammengeführt wird.
In einem Beispiel beinhaltet die erstrangige Prioritäten-Kategorie Vorschläge wie etwa Einfügungen und Löschungen von Nicht-Abschnitts-Abstandshaltern. Vorschläge der zweitrangigen Prioritäten-Kategorie beinhalten die Anwendung einer anderen Formatvorlage auf den Dokumententext, Tethering, Updaten oder Löschen einer Entität, oder Löschen eines Abschnitts. Vorschläge der neutralen Prioritäten-Kategorie beinhalten das Einfügen eines Abschnitts, das Hinzufügen einer Entität und verschiedene andere Vorschlagsbefehle.
Weiter mit 4B, nachdem die gefilterte Liste bei 407 ermittelt wurde, werden alle möglichen Zusammenführungs-Vorschläge der höchsten vorhandenen Priorität bei 408 überprüft, um festzustellen, ob bei 410 eine Zusammenführung stattfinden soll. Wenn alle Varianten dieser Priorität zusammenpassende Vorschläge haben, dann kommt es zur Zusammenführung. Andernfalls sollte es nicht zur Zusammenführung kommen, und ein neuer Vorschlag wird bei 411 erzeugt.
Wenn es zur Zusammenführung kommt, dann ermittelt das hier beschriebene System und Verfahren, welcher Vorschlag der möglichen Vorschläge in der gefilterten Liste für die Zusammenführung bei 415 verwendet werden soll. Etliche Methoden können ermitteln, welcher Vorschlag für die Zusammenführung verwendet werden soll, und die hier beschriebenen Beispiele dienen nur zur exemplarischen Veranschaulichung.
In einem Beispiel können häufigere Vorschläge bei der Verwendung für die Zusammenführung bevorzugt werden. Eine besondere Methode ist die Bevorzugung von häufigeren Vorschlägen. Mit einigen Schritten kann dies implementiert werden. Zuerst wird ein Histogramm erstellt, das angibt, wie oft jeder Vorschlag vorkommt. Zweitens werden die Varianten in der Reihenfolge von am häufigsten bis am wenigsten häufig berücksichtigt, und jede Variante, die mit einem bestimmten Vorschlag zusammengeführt werden kann, kann verwendet werden. Drittens wird für jede Variante, die keinen möglichen Zusammenführungsvorschlag besitzt, der am häufigsten vorkommende Vorschlag mit der höchsten Priorität verwendet. Nach dem Ermitteln, welcher Vorschlag für die Zusammenführung verwendet werden soll, können die Änderungsvorschläge bei 416 zusammengeführt werden.
Wie hier beschrieben, ist ein Ziel der vorliegenden Offenbarung, einen Mechanismus für die gemeinsame Zusammenführung von Vorschlägen über verschiedene Bearbeitungen hinweg zu definieren, und einen Mechanismus dafür zu ermitteln, diese Zusammenführungs-Daten zu sammeln, während die Bearbeitungsvorschläge auf die Dokumentenvorlage angewendet werden. Das nachstehende Beispiel zeigt eine Implementierung des Systems, wenn zwei Zeichen getippt werden, und das System ermittelt, dass die beiden Zeichen im gleichen Vorschlag zusammengehören:

1. Im Vorschlagsmodus ein Zeichen eingeben: a. SuggestlnsertSpacers(ID: „a", Kennung: 5, Abstandshalter: "h")
2. Ein weiteres Zeichen eingeben: a. SuggestlnsertSpacers(ID: „a", Kennung: 6, Abstandshalter: "i") i. Hinweis: die ID ist dieselbe. Beide Einfügungen sind nun Teil desselben Vorschlags.
3. Den Vorschlag annehmen: a. AcceptlnsertSpacers(ID: "a", Start: 5, Ende: 6)
4. Oder den Vorschlag ablehnen: a. RejectlnsertSpacers(ID: "a", Start: 5, Ende: 6)

Bevor eine Anweisung umgesetzt wird, kann die Dokumentenvorlage ermitteln, welcher Vorschlag, falls überhaupt, mit dieser Anweisung zusammengeführt würde (z. B. 415 in 4B). Wenn alle Befehle in einer Bearbeitung Vorschlags-Kennungen zugewiesen sind, deren Eigentümer der aktuelle Benutzer ist, dann können diese Vorschlags-Kennungen verwendet werden. Andernfalls kann eine neue Vorschlags-Kennung erzeugt und verwendet werden. Indem dies pro Kennung durchgeführt wird, können Änderungen, die Ausschneiden/Einfügen oder Finden/Ersetzen enthalten, wirksam umgesetzt werden.
In einem weiteren Beispiel beinhaltet, auf der Basis von Prioritäten-Kategorien, die Bearbeitungsvorschlägen zugewiesen sind, die zugrunde liegende Heuristik den Vollzug der Zusammenführung von Vorschlägen, und zwar bei einer Eingabe nach/vor/innerhalb einer Einfügung, einer Eingabe nach/vor/innerhalb einer Löschung, einer Eingabe vor einem Zeilenumbruch mit einer vorgeschlagenen Formatvorlage, bei einer Löschung vor/nach/innerhalb einer Löschung, einer Löschung vor/nach/innerhalb/um eine Einfügung herum, einer Eingabe innerhalb einer Löschung, einer Eingabe nach/vor/innerhalb einer Einfügung, bei der Änderung von Formatvorlagen innerhalb einer Einfügung, der Änderung von Formatvorlagen innerhalb einer Löschung, bei der Änderung von Formatvorlagen, die auf den genau gleichen Bereich angewendet werden wie eine andere Formatvorlage, bei der Änderung von Formatvorlagen innerhalb anderer Formatvorlagen, wenn die gleichen Eigenschaften betroffen sind, oder bei der Änderung von Formatvorlagen, die auf einen Zeilenumbruch nach einem Einfügungsvorschlag angewendet werden. Vorschläge werden nicht zusammengeführt bei einer Eingabe nach/vor/innerhalb von Formatvorlagen, bei einer Löschung vor/nach/innerhalb/um Formatvorlagen herum, einer Eingabe vor/nach einer Löschung, einer Eingabe vor/nach Ersetzen, einer Änderung von Formatvorlagen vor/nach Einfügung, einer Änderung von Formatvorlagen vor/nach einer Löschung, einer Änderung von Formatvorlagen, die sich mit Einfügungen überschneiden, einer Änderung von Formatvorlagen, die sich mit Löschungen überschneiden, oder einer Änderung der Formatvorlagen innerhalb, vor, nach oder sich überschneidend mit anderen Formatvorlagen, die sich nicht im selben Bereich befinden.
Zwei besondere Fälle sind bei Zeilenumbrüchen und Formatvorlagen zu berücksichtigen: Eingabe vor einem Zeilenumbruch mit einer vorgeschlagenen Formatvorlage, und Formatvorlagen, die nach einem Einfügungsvorschlag auf einen Zeilenumbruch angewendet werden. Diese Sonderfälle werden ähnlich wie oben beschrieben implementiert: die Zusammenführungslogik für Einfügungen prüft, ob sich die Einfügung vor einem Zeilenumbruch mit einer vorgeschlagenen Formatvorlage befindet, und die Zusammenführungslogik für Formatvorlagen prüft, ob die Formatvorlage nach einer vorgeschlagenen Einfügung auf einen Zeilenumbruch angewendet wird. Diese Fälle erzeugen eine Lösung für mehrere Probleme. In einem Beispiel ist das Beginnen eines neuen Absatzes mit einem nicht vorgeschlagenen Zeilenumbruch nicht problematisch. In einem zweiten Beispiel wendet das Drücken von „bold“ während des Vorschlagens einer Bearbeitung eine vorgeschlagene Formatvorlage auf den Zeilenumbruch an. In einem dritten Beispiel fügt das Eingeben eines Zeichens ein Zeichen vor dem Zeilenumbruch ein. Der Vorschlag, das Zeichen einzusetzen, wird mit dem vorangehenden Vorschlag zusammengeführt.
5 zeigt ein Ablaufdiagramm eines Verfahrens 500, das vom Rezensionsmanager 102 zur Verwendung der Priorisierungskategorien benutzt wird, um zu ermitteln, in welcher Reihenfolge die Vorschläge innerhalb eines Dokuments zusammengeführt werden sollen. Das Verfahren 500 beinhaltet die Schritte zum Ermitteln, ob es Vorschläge der erstrangigen Kategorie gibt (Entscheidungsblock 502), und zum Ermitteln, ob es ID-Befehle der zweitrangigen Kategorie gibt (Entscheidungsblock 506), und die entsprechende Zusammenführung von Bearbeitungsvorschlägen auf der Basis dieser Ergebnisse. Wenn es Vorschläge der erstrangigen Prioritäten-Kategorie gibt, werden diese Zusammenführungen ausgeführt (Schritt 504). Wenn es Zusammenführungen der zweitrangigen Prioritäten-Kategorie gibt, werden diese ausgeführt (Schritt 508). Alternativ werden keine weiteren Zusammenführungen durchgeführt, wenn es keine Vorschläge der zweitrangigen Prioritäten-Kategorie gibt (Schritt 510).
Das Zusammenführen von Bearbeitungsvorschlägen einschließlich Einfügungen wird nach mehreren Regeln durchgeführt. In einer Implementierung fügt das Drücken von ENTER im Kommentarmodus getrennte Anweisungen für jeden Zeilenumbruch ein. Das Eingeben von mehreren Absätzen ergibt eine zusammengeführte Bearbeitung, die die vorgeschlagenen Absätze beinhaltet.
In manchen Fällen können mehrere Benutzer verschiedene Bearbeitungen an einem Text vorschlagen, einschließlich von miteinander im Widerspruch stehenden Vorschlägen. In Fällen von miteinander im Widerspruch stehenden Vorschlägen für Formatvorlagen sollten die Vorschläge in einen einzigen Vorschlag zusammengeführt werden. Bei manchen Implementierungen können die Redakteure die Möglichkeit haben, die miteinander im Widerspruch stehenden Bearbeitungsvorschläge rückgängig zu machen, anzunehmen oder abzulehnen, und der Gebrauch dieser Möglichkeiten kann dazu führen, dass alle miteinander im Widerspruch stehenden Vorschläge verschwinden.
Die Bearbeitungsvorschläge an Formatvorlagen für Absätze werden getrennt von Bearbeitungen des Absatztextes bearbeitet. In einem Beispiel verändert das Ändern der vorgeschlagenen Fußzeile nicht die Formatvorlagen der Absatz-Entitäten. In einem weiteren Beispiel ist das System zum Zusammenführen der Bearbeitung dafür eingerichtet, Probleme zu bearbeiten, bei denen der Vorschlag „add entity“ nie zusammengeführt wird. In einem dritten Beispiel funktioniert das Ändern eines vorgeschlagenen Links nicht immer.
Im Allgemeinen wird das Verfahren zur Feststellung, ob Bearbeitungsvorschläge zusammenzuführen sind, entsprechend einer Reihe von Prinzipien bewerkstelligt. Einzelne Aktionen werden immer als einzelne Vorschläge angezeigt. Zusammenführungen werden für Änderungen von Formatvorlagen gänzlich innerhalb von Einfügungen ausgeführt, Änderungen von Formatvorlagen mit derselben Entität werden während der Eingabe eines zusammenhängenden Bereichs von vorgeschlagenem Text ausgewählt, während der Eingabe innerhalb von eingefügtem Text und für Objekte, die zusammengeführt werden können, einschließlich von Inlinebildern, Gleichungen, Autotext, Fußnoten und Lesezeichen. In manchen Einfügungen von Tabellen, positionierten Bildern, Kopfzeilen, Fußzeilen und Inhaltsverzeichnissen kann mit anderen Bearbeitungen nicht zusammengeführt werden.
Der hier beschriebene Lösungsansatz hat mehrere Vorteile. Erstens können Vorschläge, die von einem bestimmten Benutzer gemacht wurden, nur mit Vorschlägen zusammengeführt werden, die von demselben Benutzer gemacht wurden. Zweitens würde eine einzelne Aktion eines Benutzers nie mehr als einen Vorschlag erzeugen. Drittens wird die Konsistenz zwischen Varianten innerhalb einer Bearbeitung gewahrt. Mit anderen Worten: alle Varianten werden entweder mit existierenden Vorschlägen zusammengeführt oder einem neuen Vorschlag zugewiesen. Viertens wird die Konsistenz gewahrt, wenn eine einzelne Bearbeitung sich auf viele existierende Vorschläge auswirkt. Indem Vorschläge bevorzugt werden, mit denen jede Variante bevorzugt zusammengeführt wird, werden die konstituierenden Varianten von Bearbeitungen, die sich auf viele Vorschläge auswirken, mit den Vorschlägen zusammengeführt, auf die sie sich einzeln auswirken.
Eine weitere hier beschriebene Ausführungsform beinhaltet Projektionen, die auf eine Dokumentenvorlage angewendet werden. Auf die Dokumentenvorlagen von Client-Systemen oder Benutzergeräten können Projektionen angewendet werden. Projektionen können beispielsweise verwendet werden, um bestimmte Arten von Inhalten zu streichen oder um bestimmte Teile des Dokuments zu anonymisieren. Projektionen können als Varianten beschrieben werden, die auf die Vorlage angewendet werden. Wenn eine Projektion auf eine Vorlage angewendet wird, werden Varianten erzeugt, die, wenn sie umgesetzt werden, die Vorlage unter der Projektion erstellen. Eine Projektion, die Tabellen streicht, würde beispielsweise eine Tabelle-Löschen-Variante für jede Tabelle erzeugen, was eine Vorlage ohne Tabellen ergibt.
Um eine Variante an einen Mitarbeiter zu senden, dessen Vorlage einer Projektion unterliegt, sollte diese Variante gegen diejenigen Varianten transformiert werden, die die Projektion beschreiben. Das Senden einer Text-Einfügen-Variante erfordert beispielsweise an einer Vorlage, von der Text ausgefiltert wurde, dass der Einfügungstext gegen Text-Löschen-Varianten entsprechend dem herausgefilterten Text transformiert wird. [0097] Zusätzlich sollten manche Varianten gänzlich ausgelassen werden, wenn unter einer Projektion gesendet wird. Wenn eine Projektion beispielsweise Tabellen aus einem Dokument entfernt, sollte eine Variante zum Erstellen einer neuen Tabelle nicht an Clients mit dieser Projektion gesendet werden. Für einzelne Varianten ist dies einfach zu implementieren. Insbesondere sollten Varianten zur Auslassung für bestimmte Projektionen identifiziert werden, und die identifizierten Varianten sollten nicht gesendet werden.
Dennoch kann sich die Auslassung von bestimmten Varianten auf zukünftige Varianten auswirken, da zukünftige Varianten sich darauf verlassen oder davon ausgehen, dass ausgelassene Varianten vorhanden sind. Wenn beispielsweise zwei Varianten gesendet werden (z. B. [Text einfügen bei Index 100, Text einfügen bei Index 200]), kann die zweite Einfügung davon ausgehen, dass die erste Einfügung implementiert wurde. Auf diese Weise ist, wenn die erste Einfügung ausgelassen wird, und die zweite Einfügung ungeprüft gesendet wird, dann die gesendete Einfügung beim falschen Index.
Um dies zu lösen, werden Auslassungs-Transformationsvarianten festgelegt. Auslassungs-Transformationsvarianten sind Varianten, gegen die zukünftige Varianten transformiert werden müssen, um aufgrund der Auslassung sich unterscheidende Semantiken erfassen zu können. Im vorstehenden Beispiel ist die Auslassungs-Transformationsvariante für [insert text at 100] [delete text at 100]. Durch die Transformation von [insert text at 200] gegen die Löschen-Variante wird [insert text at 200] zurückgeschoben und befindet sich dann am richtigen Index. Auf diese Weise kann die Auslassungs-Transformationsvariante bei zukünftigen Varianten eine Projektion eines Dokuments erfassen und so entsprechend in geeigneter Weise angepasst werden.
6 zeigt ein exemplarisches Ablaufdiagramm 600, das Merkmale zur Bestimmung einer Auslassungs-Transformationsvariante für eine Dokumentenvorlage abbildet. Die Verfahrensweise kann wie folgt zusammengefasst werden.

– Einen leeren Satz von Varianten R erstellen, bei 601.
– Den Satz von Varianten S erstellen, die verwendet werden, um die Projektion auf die aktuelle Vorlage anzuwenden, bei 602.
– Für jede Variante M im Satz der zu sendenden Varianten: – M‘ und S‘ erstellen, indem M gegen S transformiert wird bei 603. – Falls M‘ ausgelassen wird aufgrund der Projektion bei 605: – Die Auslassungs-Transformationsvariante O für C‘ erstellen bei 606. – O zu S‘ hinzufügen bei 607. – Ansonsten: – C' zu R hinzufügen bei 608. – S' als das neue S bestimmen bei 609. – R ist das Ergebnis.

Zusammenfassung: beim Bestimmen einer Projektion kann man (1) mit einer angegebenen Vorlage bestimmen, welche Varianten die Projektion anwenden und (2), welche Varianten ausgelassen werden sollen, und was die Auslassungs-Transformationsvariante für diese bedeuten. Sobald diese festgelegt sind, können die Systeme und Verfahren der vorliegenden Offenbarung dazu verwendet werden, kollaborativ Varianten unter der Projektion zu versenden.
Das Problem auf diese Weise zu lösen hat einige Vorteile. Erstens lässt es die vorliegende Offenbarung zu, dass Projektionen gänzlich auf Server-Seite angewendet werden, was es erlaubt zu erzwingen, dass Clients bestimmten Projektionen unterliegen. Zweitens verwendet die vorliegende Offenbarung Semantiken bestehender operationaler Transformationen in Echtzeit-Kollaborationsanwendungen.
In einem Beispiel werden Projektionen angewendet, um Änderungsvorschläge aus einer Version des Dokuments, die Lesern zur Verfügung steht, herauszufiltern. Die vorliegende Offenbarung macht es möglich, dass Änderungen am Dokument in geeigneter Weise angewendet werden, so dass Lesern eine aktualisierte Version des Dokuments vorgelegt wird. Um die Anzeige von Änderungsvorschlägen und Kommentaren aus dem „Lesemodus“ des Dokuments, das für Leser sichtbar ist, zu entfernen, kann das Anwendungsmodul, das den Lesemodus eines Dokuments implementiert, jede Kombination der folgenden Schritte enthalten.
Das Konzept einer Projektion kann auf eine Dokumentenvorlage angewendet werden. Ein exemplarisches Pseudo-Code-Segment, das eine Objektklasse einer Projektion darstellt, kann einer der folgenden Form ähnliche Form annehmen:
Für die Verwendung dieser Projektionen wird ModelState wie folgt modifiziert:
Verwendungen werden durch die geeignete Projektion ersetzt, abhängig davon, ob Vorschläge immer gefiltert werden sollen.
Das Filtern auf Basis einer Access Control List (ACL) kann verwendet werden. Manche Verwendungen von Vorschlägen erfordern kontextuelles Filtern basierend darauf, ob der Benutzer Lese- oder Bearbeitungszugriff auf das Dokument hat. Um dies zu erreichen, kann zur Konstruktion des Rechts eine Zuordnungsinstanz verwendet werden. Ein exemplarisches Pseudo-Code-Segment, das eine Objektklasse einer ACL-basierten Filterung darstellt, kann einer der folgenden Form ähnliche Form annehmen:

Die Zuordnungsinstanz gibt Projection.FULL für Redakteure und Rezensenten (Kommentatoren) und Projection. WITHOUT_SUGGESTIONS für Leser zurück. Zusätzlich kann ein Standardwert für Projection eingegeben werden, der die Zuordnungsinstanz verwendet, um die richtige Projektion für den AccessLevel zurückzugeben.
In einer weiteren Ausführungsform kann Änderungsfiltern implementiert werden. In manchen Anwendungen kann das kontextuelle Filtern der Vorlage basierend auf AccessLevel nicht ausreichend sein. Verwendungen, die Änderungen laden oder übermitteln, müssen möglicherweise auch gefiltert werden. Die folgenden Schritte können zum Filtern von Befehlen für Benutzer verwendet werden:

1. Einen leeren Satz von Befehlen R erstellen.
2. Den Satz von Befehlen S erstellen, die verwendet werden, um die aktuellen Vorlagen-Vorschläge herauszufiltern.
3. Für jede Anweisung C in der Änderung: a. C‘ und S‘ erstellen, indem C gegen S transformiert wird. b. Wenn C‘ ein Vorschlagsbefehl ist: i. Die Auslassungs-Anweisung O für C‘ erstellen. ii. O zu S‘ hinzufügen. c. Ansonsten: i. C‘ zu R hinzufügen. d. S‘ als das neue S bestimmen.
4. R ist das Ergebnis.

Bei manchen Implementierungen kann das folgende Verfahren zum Erstellen von Filterbefehlen verwendet werden (die ein exemplarisches Pseudo-Code-Segment sein können und obenstehenden Schritt 2 zeigen). public interface Model<T extends Model<T>> {

Die Implementierung für Projection.FULL kann immer eine leere Liste zurückgeben. Implementierungen, die keine Vorschläge unterstützen, wie etwa Projection. WITHOUT_SUGGESTIONS, können einfach eine leere Liste zurückgeben. In manchen Implementierungen kann die Anwendung für die kollaborative Dokumentenbearbeitung Projection. WITHOUT_SUGGESTIONS implementieren, indem sie denselben Satz von Befehlen erzeugt, um alle aktuell in der Vorlage vorhandenen Vorschläge abzulehnen.
Bei manchen Implementierungen kann das folgende Verfahren zum Erzeugen von Auslassungsbefehlen verwendet werden (die ein exemplarisches Pseudo-Code-Segment sein können und obenstehenden Schritt 3.b.i. zeigen). public class ProjectionDetails<T extends Model<T>> {
Dies kann wie folgt implementiert werden:

1. AbstractCommand gibt null zurück.
2. WrapperCommands erzeugt Fehler, wenn diese aufgerufen werden, da die Details nicht ohne Entpacken berechnet werden können.
3. Vorschlagsbefehle geben die passenden Auslassungsbefehle zurück. Zum Beispiel: a. InsertSuggestedSpacers gibt ein DeleteSpacers für den eingefügten Bereich zurück. b. MarkSpacersForDeletion gibt ein UnmarkSpacersForDeletion für denselben Bereich zurück.

Bei manchen Implementierungen können Befehle vor der Verarbeitung entpackt werden, da jeder Befehl anders behandelt werden muss, abhängig davon, ob es sich um einen Vorschlagsbefehl handelt oder nicht. Bei manchen Implementierungen kann der Dokument-Editor eines kollaborativen Dokuments keinen Validierungs-Transformer für diesen Vorgang verwenden, da die Vorlage bei jedem Schritt nicht notwendigerweise valide ist. Bei manchen Implementierungen verwenden die Mitarbeiterauswahl-Änderungen die Vorlage bei der Überprüfung der Änderung, und speicherbare Änderungen verwenden die Vorlage bei der vorangehenden Überprüfung.
Bei manchen Implementierungen verlässt sich die vorliegende Offenbarung auf die Transformation, um Anweisung herauszufiltern, bevor sie an Leser gesendet werden. Bei dieser Herangehensweise ist die Leistung von Belang. Insbesondere kann sich die Transformation verlangsamen und kann bei jedem Speichern durchgeführt werden, wenn ein Dokument Vorschläge und Leser hat. Zur Lösung dieses Problems kann ein Leistungsdurchlauf für die Transformatoren durchgeführt werden. Da die allgemeine Herangehensweise n2 ist, kann der Gewinn begrenzt sein. Zur Vermeidung von Worst-Case-Szenarien kann die Anzahl der FilterBefehle, gegen die transformiert werden kann, begrenzt werden, und das Senden an Leser kann gestoppt werden, wenn diese Grenze erreicht ist.
Von Belang ist weiterhin, dass Senden zurzeit hinter der ModelState-Sperre durchgeführt werden kann. Zur Lösung kann eine separate Sperre verwendet werden, wobei die separate Sperre Sendungen befiehlt, aber nicht andere Operationen am ModelState blockiert.
In einer weiteren Ausführungsform kann die Erkennung der Zugriffsebene der Sitzung implementiert werden. Bei manchen Implementierungen sollte die Dokument-Editor-Anwendung für das kollaborative Dokument, um zu ermitteln, welche Sitzungen Browser-Kanal-Filterung brauchen, über Informationen verfügen, die angeben, welche Sitzungen Leser-Sitzungen sind. Es ist möglicherweise nicht ausreichend, den AccessLevel des Benutzers zu ermitteln, da die Zugriffsebene des Benutzers möglicherweise nicht unbedingt zum tatsächlichen Zugriff des Clients passt. Ein Redakteur kann beispielsweise anstelle eines Redakteurmodus eine Option zum Lesen des Dokuments in einem Lesemodus oder in einem Lektorenmodus wählen, oder ein Lektor kann eine Option zum Lesen des Dokuments in einem Lesemodus statt in einem Lektorenmodus wählen. Um dies zu implementieren, kann eine Funktion zum Erstellen von Sitzungen AppSessionManager so modifiziert werden, dass sie auch den AccessLevel der Sitzung erhält. Es kann auch einen Mechanismus zum Erkennen geben, welche Sitzungen einen bestimmten AccessLevel haben.
Bei manchen Implementierungen kann, um den AccessLevel zu füllen, eine Funktion SessionInitiationInterceptor den AccessLevel des aktuellen Benutzers einholen, die Sitzung wird erstellt. Wenn es @SessionInitiator Endpunkte gibt, die Sitzungen auf einer erzwungenen niedrigeren Zugriffsebene initiieren (wie /view), dann können diese manuell überschrieben werden. Zum manuellen Überschreiben kann ein Parameter zu @SessionInitiator hinzugefügt werden, und zwar zur Verwendung mit dem optionalen AccessLevel anstelle des gültigen. Alternativ können die Endpunkte, die erzwungene niedrigere Zugriffsebenen ergeben, entfernt werden, wobei sie den Client zum Aktualisieren zwingen, wenn sie zugreifen können.
Bei einer weiteren Ausführungsform können die Verwendungen gemäß dem Folgenden kategorisiert werden: Verwendungen von Projektion.
WITHOUT_SUGGESTIONS:

1. Thumbnails. Dies sollte allgemein über ModelThumbnailer bearbeitet werden.
2. Indizierung. Dies sollte allgemein über Indexer bearbeitet werden.
3. Sozialer Markup. Dies sollte allgemein über Snippeter bearbeitet werden.
4. Crawler.
5. Dokumentenkopien.
6. Vorschau und Veröffentlichung.

Verwendungen von Projection.FULL:

1. Rechtliche Ermittlungen und AbuseIAm.
2. Abläufe und Debug-Endpunkte.
3. Andere interne Verwendungen: Prüfen auf Vorgänger-Kommentare, Validierung, Rechtschreibprüfung, Transformation.

Verwendungen von Projection.fromAccessLevel:

1. Endpunkte nur für Redakteure verfügbar: Linkbearbeitung, Wiederherstellen, Maestro RPCs, Überarbeitungshistorie
2. Offline sync: ModelAction
3. Export. Dies kann allgemein über Exporter bearbeitet werden.

Manche Verwendungen können auf dem gültigen Zugang für die aktuelle Sitzung basieren. Mechanismen können vorhanden sein, die sicherstellen, dass die Sitzung und die Zugriffsebene übereinstimmend gehalten werden oder diese separat bearbeiten:

1. SessionInitiator Aktionen und ihr gültiger Zugang: a. vonAccessLevel: Bearbeiten, Kommentieren b. WITHOUT_SUGGESTIONS: Ansicht, NativeWebView
2. Verwendungen, die den gültigen Zugang für die Sitzung benötigen: a. Erstes Laden der Schriftarten der Vorlage. b. Drucken und Druckvorschau. c. Vorlagen-Catchup-Anfragen. d. Versenden von Befehlen.

Unten befinden sich einige Beispiele von Verfahrensweisen, die hier in der Praxis beschrieben sind:
Bei manchen Implementierungen können, anstelle der Verwendung von operationaler Transformation zum Transformieren von Befehlen, bevor sie zum Leser gesendet werden, die Befehle anonymisiert werden, bevor sie nach unten gesendet werden, und dann dem Client vertraut, sie richtig zu transformieren. Diese Implementierung kann unerwünscht sein, da sie mit einer größeren und komplizierteren Änderung einhergeht. Insbesondere kann die Anonymisierung sowohl den Befehl als auch die Vorlagen-Voranwendung des Befehls erforderlich machen, also müsste dies zur Zeit der Anwendung erfolgen. Zum Client in anderen Pfaden gesendete Befehle, wie etwa Delta-Änderungen, würden eine Anwendung erfordern. Außerdem müsste das Anonymisierungssystem erstellt werden, ohne die Semantik der operationalen Transformation des Befehls (und möglicherweise der Anwendung) zu zerstören. Dies kann eine negative Auswirkung auf die Leistung des Clients (einschließlich Mobile) haben. Insbesondere können Transformationen auf dem Client für die Benutzer eine noch schlechtere Auswirkung auf die Leistung haben, und Methoden dafür, dies auf Client-Seite sauber zu bearbeiten, können es erforderlich machen, den Offline-Speicher zu ändern.
Eine weitere Ausführungsform der hier beschriebenen Systeme und Verfahren beinhalten einen Benachrichtigungsmechanismus zur Benachrichtigung von Benutzern über Veränderungen am Dokument durch Mitarbeiter. In einer Online-Bearbeitungsumgebung für kollaborative Dokumente wünschen Redakteure im Allgemeinen, dass sie die Kontrolle über ihre Dokumente haben, und dass Mitarbeiter sie bearbeiten können. Redakteure möchten wissen, wer ihr Dokument geändert hat, wann es geändert wurde, und was geändert wurde. Die Systeme und Verfahren der vorliegenden Offenbarung sprechen dieses Problem an, indem sie eine Möglichkeit zur Benachrichtigung des Redakteurs (ebenso wie der Benutzer, die Benachrichtigungen abonniert haben) über Änderungen, die von Mitarbeitern an seinem Dokument vorgenommen wurden, zusammen mit einer Zusammenfassung der Änderungen.
7 stellt ein exemplarisches Ablaufdiagramm 700 bereit, das Merkmale der Benachrichtigung von Redakteuren über Änderungen an einem kollaborativen Dokument durch andere Mitarbeiter darstellt. Existierende Systeme können Änderungen nachverfolgen, die verschiedene Benutzer an einem Dokument vorgenommen haben, aber stellen keine Änderungsbenachrichtigungen oder Zusammenfassungen der Änderungen für die Benutzer bereit, bei 701. In einer Ausführungsform können Änderungen, die von Mitarbeitern vorgenommen wurden, basierend auf der Zeit, die seit den Änderungen vergangen ist, batchverarbeitet werden, bei 702. Eine E-Mail oder Nachricht wird an den Eigentümer des Dokuments und an Benutzer, die Benachrichtigungen abonniert haben, gesendet. Die E-Mail oder Benachrichtigung kann Änderungen von vielen Mitarbeitern während einer angegebenen Zeitspanne enthalten. Jede Änderung in der Nachricht kann verschiedene Daten enthalten, wie etwa den Autor, den Zeitpunkt, zu dem die Änderung vorgenommen wurde, und eine Beschreibung der Änderung. Änderungen können von anderen Redakteuren oder von Mitarbeitern vorgenommen werden, die nicht volle Bearbeitungsrechte haben, wie etwa Rezensenten. Die von Rezensenten vorgenommenen Änderungen können als „Vorschläge“ aufgenommen werden und benötigen die Zustimmung eines Redakteurs vor der Anwendung auf ein Dokument. In manchen Implementierungen können Redakteure diese Änderungen direkt von der E-Mail oder Benachrichtigung aus annehmen oder ablehnen, indem sie die entsprechende Option wählen.
In manchen Implementierungen wird, während jede Änderung an einem Dokument vorgenommen wird, die Änderung an ein Benachrichtigungs-Softwaresystem gesendet, das das Änderungsereignis nach Dokument und Empfänger nachverfolgt. Der Eigentümer des Dokuments ist standardmäßig Abonnent von Benachrichtigungen, und andere Mitarbeiter können die Benachrichtigungen auch abonnieren. Änderungen im selben Bereich des Dokuments oder gleichzeitige Änderungen können gruppiert werden. Das Benachrichtigungs-Softwaresystem wartet dann eine konfigurierbare Zeitspanne ab, die darauf basieren kann, ob der Empfänger aktuell das Dokument ansieht oder nicht, bei 703.
Sobald die entsprechende Zeit vergangen ist, bei 704, werden alle Benachrichtigungsereignisse als Batch zusammengefasst und verarbeitet, bei 705. Für jede am Dokument vorgenommene Änderung kann ein separater Eintrag erzeugt werden (bei 706), der den Autor, den Zeitstempel der Änderung, die zuletzt vorgenommen wurde, und eine Textbeschreibung der Änderung auflistet.
In manchen Ausführungsformen beinhaltet die vorliegende Offenbarung Funktionen, die sicherstellen, dass Redakteure nicht übermäßig benachrichtigt werden. Änderungen, die rückgängig gemacht wurden und/oder im Dokument nicht mehr vorhanden sind, können ignoriert werden, und die Benachrichtigung für diese Änderungen kann unterdrückt werden. Wenn beispielsweise ein Mitarbeiter eine Änderung am Dokument vornimmt und die Zeitspanne verstreicht, kann der Redakteur eine E-Mail erhalten, die die Änderung beschreibt. Die Benachrichtigung über die Änderung kann jedoch unterdrückt werden, wenn der Mitarbeiter die Rückgängig-Funktionalität verwendet, die Änderung manuell rückgängig macht, oder wenn der Dokumentenabschnitt, in dem sich die Änderung befindet, vom Redakteur gelöscht wurde.
Das Verwenden verschiedener Zeitspannen basierend darauf, ob ein Redakteur, der das Dokument ansieht, erlaubt es Redakteuren, die das Dokument aktiv ansehen, Aktionen an Bearbeitungen von Benutzern vorzunehmen, und verhindert, dass eine überflüssige Benachrichtigung versendet wird, während nach wie vor pünktliche Benachrichtigungen über Änderungen gesendet werden. Die Zeitspanne kann beispielsweise länger sein, wenn der Redakteur das Dokument aktiv ansieht, und kann kürzer sein, wenn der Redakteur das Dokument nicht aktiv ansieht.
Die hier beschriebenen Systeme und Verfahren stellen eine von Menschen lesbare Erklärung von an einem Dokument vorgenommenen Änderungen bereit und stellen dem Redakteur Informationen zur Verfügung, die verwendet werden können, um zu entscheiden, ob das Dokument jetzt, später, oder niemals angesehen wird. Diese Ermittlung ist möglicherweise nicht möglich, wenn dem Redakteur nur ein Zeitstempel zur Verfügung gestellt wird, der manuell überprüft werden muss, oder wenn der Redakteur sich darauf verlassen muss, dass die Mitarbeiter den Redakteur darüber informieren, dass Änderungen vorhanden sind, und was die Änderungen beinhalten.
Hier beschriebene Ausführungsformen bieten gegenüber existierenden Systemen einige Vorteile. Das hier beschriebene Benachrichtigungssystem bedeutet beispielsweise, dass Redakteure nicht von Mitarbeitern manuell benachrichtigt werden müssen, wenn die Mitarbeiter Änderungen vorgenommen haben. Ähnlich dazu müssen Redakteure nicht selbst aktiv werden, um von Änderungen zu erfahren, da die E-Mails oder Benachrichtigungen innerhalb von Minuten nach der Änderung durch den Mitarbeiter versendet werden. Darüber hinaus gibt das Einbinden einer Beschreibung der Änderung in die Benachrichtigung dem Redakteur Kontext bezüglich der Änderungen. Das einfache Zur-Verfügung-Stellen eines Zeitstempels ist nicht genügend Information für den Redakteur, um zu entscheiden, ob eine Untersuchung von Änderungen berechtigt ist. Die vorliegende Offenbarung stellt dem Redakteur Informationen bereit, die es zulassen, dass er seine Zeit zwischen vielfachen Aufgaben besser einteilen kann, einschließlich des kollaborativ bearbeiteten Dokuments.
In manchen Implementierungen kann die Benachrichtigung keine Textbeschreibung beinhalten, aber auch eine Wiedergabe der Änderung im Kontext des restlichen Dokuments. Wenn ein Mitarbeiter beispielsweise Text durch neuen Text ersetzt hat, würde die Beschreibung in der Benachrichtigung nicht zur lauten „Ersetze ‚end‘ durch ‚letzter Teil von etwas‘“, sondern die Benachrichtigung kann auch die wenigen umgebenden Zeilen, Worte, oder Sätze des Dokuments beinhalten.
In manchen Implementierungen kann die Benachrichtigung eine Zusammenfassung der Änderung beinhalten. Die folgende Beschreibung ist ein Beispiel für einen Vorgang zur Benachrichtigung von Redakteuren und Abonnenten über Änderungen in einem Dokument. Ein CommentNotificationListener kann auf Ereignisse prüfen, die immer dann auftreten können, wenn ein Kommentar oder eine Antwort erstellt, aktualisiert oder gelöscht wird. Die Ereignisse können verarbeitet werden, und eine Benachrichtigungs-Payload kann erstellt werden (wenn die Umstände zur Benachrichtigung berechtigen). Ein Benachrichtiger kann dann die Benachrichtigungs-Payload bündeln und sendet sie einem Benachrichtigungssystem, das die Nutzlast empfängt und zu einem Bucket von (Dokument, Empfänger) hinzufügt. Der Bucket kann eine konfigurierbare Zeitspanne lang gehalten werden (z. B. etwa 5 Minuten, wenn das Dokument geschlossen ist, 15 Minuten, wenn das Dokument vom Benutzer geöffnet ist, um benachrichtigt zu werden). Während mehr Kommentare oder Antworten hinzugefügt oder aktualisiert werden, werden sie demselben Bucket von (Dokument, Empfänger) hinzugefügt. Wenn die Zeitspanne verstrichen ist, nimmt das Benachrichtigungssystem alle Payloads in einem angegebenen Bucket und schickt diesen an einen Nachrichtenprozessor, der für die Bearbeitung des Buckets konfiguriert ist. Der Nachrichtenprozessor gibt den Bucket an einen Ereignisprozessor weiter, der die Benachrichtigungsereignisse verarbeitet, Ereignisse herausfiltert, die nicht gesendet werden sollen, die Ereignisse nach Kommentar-ID gruppiert, und die Ereignisse in HTML und Textnachrichtenkörper übersetzt.
Obwohl verschiedene hier beschriebene Ausführungsformen dargestellt wurden, ist es für Fachleute offensichtlich, dass diese Ausführungsformen nur beispielshalber bereitgestellt werden. Den Fachkräften werden zahlreiche Variationen, Abänderungen und Ersetzungen einfallen, ohne von der Veröffentlichung abzuweichen. Es sollte klar sein, dass diverse Alternativen zu den hier beschriebenen Ausführungen in der Praxis dieser Offenlegung angewandt werden können.
Eine weitere Ausführungsform der hier beschriebenen Systeme und Verfahren beinhaltet einen Benachrichtigungsmechanismus zur Benachrichtigung von Benutzern über Veränderungen am Dokument durch Mitarbeiter. Eine Dokument-Editor-Anwendung kann es Benutzern erlauben, Bearbeitungen als Vorschläge zu machen, die nachverfolgt werden, und angenommen oder abgelehnt werden müssen, bevor sie in das Dokument integriert werden. Dabei benötigt der Dokument-Editor einen Mechanismus zur Umwandlung jeder beliebigen Bearbeitung in eine Vorschlagsversion. Es ist wünschenswert, über einen automatischen Umwandlungsmechanismus zu verfügen, der allgemein existierende Bearbeitungen umwandeln kann, ohne Umwandlungslogik für jede Bearbeitung manuell implementieren zu müssen. So kann jede Controller-Ablaufregel wirksam eingesetzt werden, einschließlich jeder zukünftigen Regel, die geschrieben wird.
Wie in Verbindung mit 6 diskutiert, können Änderungen an der Dokumentenvorlage über eine Reihe von schrittweisen winzig kleinen Veränderungen beschrieben werden. In einem Textverarbeitungsprogramm können Varianten Zeicheneinfügungen, Zeichenlöschungen und die Anwendung von Formatvorlagen beinhalten. Eine einzelne Benutzerbearbeitung am Dokument kann zu vielfachen, auf die Vorlage angewendeten Variante führen. Ein Textverarbeitungsprogramm würde über Ablaufregeln verfügen, die ermittelt, welche Varianten auf die Vorlage angewendet werden, basierend auf der Aktion des Benutzers und dem aktuellen Status der Anwendung.
8 stellt ein exemplarisches Ablaufdiagramm 800 bereit, das darstellt, wie Bearbeitungen in einen Vorschlag umgewandelt werden. Beginnend bei 801, bestimmt die Anwendung Vorschlagsversionen ihrer Varianten, um vorgeschlagene Objekte in der Anwendungsvorlage bei 801 zu kennzeichnen. Ein Textverarbeitungsprogramm kann beispielsweise eine Zeichen-Einfügen-Variante und eine Vorgeschlagene-Zeichen-Einfügen-Variante haben. Dann muss die Anwendung Funktionen zur Umwandlung von der regulären Version in die Vorschlagsversion bestimmen. Im vorstehenden Beispiel wäre dies eine Funktion, die von Zeichen Einfügen in Vorgeschlagene Zeichen Einfügen umwandelt. Wenn die Vorschlagsvariante eine andere Anwendungssemantik als die ursprüngliche Variante hat, dann muss die Transformationsvorschlags-Variante auch bereitgestellt werden.
Diese Varianten werden zum Transformieren zukünftiger Varianten verwendet, um die sich unterscheidenden Semantiken zu erfassen. Ein Textverarbeitungsprogramm kann beispielsweise eine Zeichen-Löschen-Variante haben, deren Vorschlagsversion die Zeichenmarkierung zum Löschen ist. Das Markieren der Zeichen zur Löschung löscht sie aber nicht wirklich – es erzeugt nur einen Vorschlag, sie zu löschen. Der Benutzer führt beispielsweise ein Drag & Drop aus, das dargestellt wird als Zeichen Löschen bei Kennung 100 und Zeichen Einfügen bei Kennung 200. Eine ungeprüfte Umwandlung würde diese in Zeichen zur Löschung bei Kennung 100 und Zeichen Einfügen bei Kennung 200 umwandeln. Die Kennung der ursprünglichen Einfügung nahm jedoch an, dass die Zeichen bereits gelöscht wurden. Daher kann ein Zeichen Einfügen bei 100 als die Transformationsvorschlags-Variante definiert werden. Ein Transformieren des Zeichen Einfügen bei 200 gegen diese veranlasst es, sich nach vorne auf die korrekte Position für die Einfügung zu verschieben.
Sobald diese Semantiken für die angegebene Anwendungsvorlage bestimmt worden sind, kann ein Vorschlag auf der Basis der folgenden Schritte erzeugt werden:

1. M als aktuelle Anwendungsvorlage bestimmen (bei 802)
2. Eine Kopie von M erstellen, um M‘ zu erzeugen (bei 802)
3. Die Ablaufregel für die aktuelle Aktion des Benutzers auf M‘ ausführen. Die auf M‘ angewandten Varianten sammeln als ein Ergebnis dieser Logik in ein Feld A (bei 803).
4. Ein leeres Feld T definieren (bei 804).
5. Für jede Variante C in A: a. S erzeugen, die Vorschlagsversion von C, über die anwendungsspezifische Funktion b. F erzeugen, die Transformationsvorschlags-Variante für C, über die anwendungsspezifische Funktion c. S gegen T transformieren, um S‘ und T‘ zu erzeugen d. T = T‘ bestimmen e. F zu T hinzufügen f. S‘ auf M anwenden.

805

Bei der Bestimmung der Funktion für das Erzeugen von Varianten kann es nützlich sein, die Eigentümerschaft der betroffenen Objekte in Betracht zu ziehen. Wenn der Benutzer beispielsweise ein vorgeschlagenes Wort zurückgesetzt hat, sollte dieses Wort gelöscht werden, aber wenn ein nicht vorgeschlagenes Wort zurückgesetzt wurde, sollte es für die Löschung markiert werden. Um dies zu erreichen, das Konzept der Varianten-Eigentümerschaft bestimmen. Die Eigentümerschaft kann sich in einem von drei Status befinden: im Besitz, teilweise_im_Besitz oder nicht_im_Besitz. Während des Schritts (3) des vorstehenden Verfahrens wird die Eigentümerschaft jeder Variante auf der Basis der Objekte in der Vorlage, auf die sie sich auswirkt, berechnet. Eine Text löschende Variante wäre beispielsweise im Besitz, wenn der Text ein Vorschlag des aktuellen Benutzers ist, nicht_im_Besitz, wenn nicht, und teilweise_im_Besitz, wenn nur ein Teil des gelöschten Textes ein Vorschlag des aktuellen Benutzers ist. Dann kann, während des Schritts (5.a) die vorberechnete Eigentümerschaft während des Umwandlungsprozesses verwendet werden. Für eine Zeichen löschende Variante kann diese Eigentümerschaft verwendet werden, um eindeutig zu machen, ob in „Zeichen für die Löschung Markieren“ umzuwandeln ist, oder ob sie als „Zeichen Löschen“ belassen werden soll.
Die Eigentümerschaft kann auch über Varianten von ähnlichen Typen während Schritt (3) angesammelt werden. Beim Betrachten dieser Ansammlung von Eigentümerschaften kann man sich bei der Umwandlung für einen Querschnitt über besondere Varianten entscheiden. Dies kann beispielsweise nützlich sein, wenn die Anwendung eine unterbrochene Auswahl zulässt und es wünschenswert ist, den Text entweder durchgehend zu löschen oder zur Löschung zu markieren.
Das Problem auf diese Weise zu lösen, hat die folgenden Vorteile:

1. Es ist eine allgemeine Lösung, unabhängig von der anwendungsspezifischen Ablaufregel. Sie erfordert nur das Bestimmen von Umwandlungsfunktionen für die Varianten in der Anwendung. Dies minimiert die Implementierungskosten.
2. Da sie unabhängig von der anwendungsspezifischen Ablaufregel funktioniert, erfordert sie weniger Wartung, wenn die Anwendung erweitert oder mit neuer Geschäftslogik modifiziert wird.
3. Es ist einfach, Vorschläge auf neue Objekte in der Vorlage auszuweiten. Nur die Umwandlungsfunktionen für die Varianten müssen bestimmt werden, die Änderungen an diesen Objekten darstellen.

Um Vorschlagsbefehle zu erzeugen, kann eine Oberfläche SuggestCommandProvider eingeführt werden, die eine Registrierung über die CommandRegistry hat. Eine weitere Oberfläche SuggestTransformCommandProvider kann übernommen werden, die Befehle erzeugt, indem sie eine Zuordnung zwischen den Befehlen und Vorschlagsbefehlen bereitstellt. Die Darstellung eines exemplarischen Pseudo-Code-Segments SuggestCommandProvider und SuggestTransformCommandProvider kann eine dem Folgenden ähnliche Form annehmen:
Die Dokumentenvorlage kann eine Kopie des Kontexts erstellen, um die ursprüngliche Bearbeitung zu übernehmen, ohne den tatsächlichen ModelState zu modifizieren. Dazu kann eine für Änderungsvorschläge spezifische Oberfläche, die den Kontext kopiert, erstellt werden. Dies ist kein allgemeiner Kontext-Kopierer, da er Aktionen, die speziell für die Verwendung in Änderungsvorschlägen sind, wie etwa das Erstellen eines No-Op Wechselrichters.
Um die oben beschriebene SelectionModel-Kopie zu machen, werden SelectionTreeGenerator und SelectionDocumentSliceGenerator von SelectionModel entfernt und in eine Hilfsprogrammklasse verschoben:
Um ein SuggestEdit einzuführen, kann IdUtil von docs.text.util nach Docs.util verschoben werden. Im Folgenden ein Überblick über die zwei neuen Klassen:

Beachten, dass der Aufruf von applySelection in SuggestEdit.applylntemal "scroll into view" und den Grund der Auswahländerung nicht richtig übermittelt. Dies wird in einer zukünftigen Bearbeitung abgedeckt, zurzeit werden diese fallen gelassen.
Der SuggestEditProvider muss, immer wenn die Anwendung im Vorschlagsmodus ist, beim Verpacken des regulären EditProvider verwendet werden. Dies wird erreicht durch das Einführen eines SuggestEditApplier Wrapper:
Dies lässt das Abfangen aller angewendeten Edit Providers und deren adäquate Verpackung zu. Rückgängigmachen oder reguläres Wiederholen muss möglicherweise nicht abgefangen werden, da diese die Befehle aus dem SuggestEdit-Ergebnis korrekt anwenden. Zusätzlich muss das wunderbare Wiederholen möglicherweise nicht abgefangen werden, da der gespeicherte Provider bereits der richtige ist. Der SuggestEditApplier wird in kollaborativen Dokumenten hinter dem Änderungsvorschlags-Kennzeichen erzeugt. Wenn der Benutzer im Kommentarmodus ist, dann wird der setSuggestionsMode aktiviert.
9 ist ein Blockschaltbild, das ein exemplarisches Computersystem 900 veranschaulicht, mit dem das System zur Verwaltung von Bearbeitungsvorschlägen in einem Dokument und die Verwendung der 1–8 implementiert werden können. In bestimmten Aspekten kann das Computersystem 900 unter Verwendung von Hardware oder einer Kombination aus Software und Hardware, entweder auf einem dezidierten Server, oder integriert in eine weitere Entität, oder verteilt auf mehrere Entitäten implementiert werden.
Das Computersystem 900 beinhaltet einen Bus 908 oder einen anderen Kommunikationsmechanismus zum Übermitteln von Information, und einen Prozessor 902, der zur Informationsverarbeitung mit Bus 908 verknüpft ist. Das Computersystem 900 kann beispielshalber mit einem oder mehr Prozessoren 902 implementiert werden.
Das Computersystem 900 kann zusätzlich zur Hardware Code beinhalten, der eine Ausführungsumgebung für das betreffende Computerprogramm erzeugt, z. B. Code, der Prozessor-Firmware, ein Protokoll-Stack, ein Datenbankverwaltungssystem, ein Betriebssystem oder eine Kombination von einem oder mehreren davon darstellt, der in einem beinhalteten Speicher 904, wie etwa einem Direktzugriffspeicher (RAM), einem Flash-Speicher, einem Nur-Lese-Speicher (ROM), einem programmierbaren Nur-Lese-Speicher (PROM), einem löschbaren PROM (EPROM), Verzeichnissen, einer Festplatte, einer Wechselplatte, einer CD-ROM, einer DVD oder einer anderen geeigneten Speichervorrichtung, die zum Speichern von Informationen und Anweisungen, die durch Prozessor 902 auszuführen sind, mit Bus 908 verbunden sind. Der Prozessor 902 und der Speicher 904 können von einem logischen Schaltkreis ergänzt oder in einen logischen Schaltkreis eingebaut werden.
Die hier beschriebenen Verfahren und Systeme können teilweise oder in Gänze durch eine Maschine bereitgestellt werden, die Computersoftware auf einem Server, Client, Firewall, Gateway, Hub, Router, oder anderer derartiger Computer- und/oder Netzwerk-Hardware ausführt. Das Softwareprogramm kann mit einem Server verbunden sein, der einen Dateiserver, Druckerserver, Domainserver, Internetserver, Intranetserver und anderen Varianten wie Sekundärserver, Hostserver, verteilte Serverstrukturen und dergleichen beinhalten kann. Der Server kann einen oder mehrere Speicher, Prozessoren, computerlesbare Medien, Speichermedien, Ports (physische und virtuelle), Kommunikationsgeräte und Schnittstellen beinhalten, die fähig sind, auf andere Server, Clients, Maschinen und Geräte über ein kabelgestütztes oder kabelloses Medium und dergleichen zuzugreifen. Die Verfahren, Programme oder Codes, wie hierin und an anderer Stelle beschrieben, können von dem Server ausgeführt werden. Zusätzlich dazu können weitere, zur Ausführung der anmeldungsgemäßen Verfahren erforderliche Geräte als Bestandteil der mit dem Server verbundenen Infrastruktur erachtet werden.
Der Server kann eine Oberfläche für andere Vorrichtungen bereitstellen, die, ohne Einschränkung, Clients, andere Server, Drucker, Datenbankserver, Druckerserver, Fileserver, Kommunikationsserver, verteilte Server und ähnliches beinhaltet. Zusätzlich dazu kann diese Koppelung und/oder Verbindung die entfernte Ausführung von Programmen im gesamten Netzwerk begünstigen. Die Vernetzung einiger oder aller dieser Geräte kann die Parallelverarbeitung eines Programms oder Verfahrens an einem oder mehreren Orten begünstigen ohne vom Umfang des offenbarungsgemäßen Gegenstands abzuweichen. Zusätzlich kann jede der mit dem Server über eine Schnittstelle verbundenen Vorrichtungen mindestens ein Speichermedium beinhalten, das in der Lage ist, Verfahren, Programme, Code und/oder Anweisungen zu speichern. Eine zentrale Ablage Programmanweisungen zur Ausführung auf verschiedenen Geräten bereitstellen. In dieser Implementierung kann die Fernablage als Speichermedium für Programmcodes, Anweisungen und Programme dienen.
Die hier beschriebenen Verfahren und Systeme können teilweise oder in Gänze durch Netzwerkinfrastrukturen bereitgestellt werden. Die Netzwerk-Infrastruktur kann Elemente wie Computergeräte, Server, Router, Hubs, Firewalls, Clients, Personal Computer, Kommunikationsgeräte, Routinggeräte sowie andere aktive und passive Geräte, Module und/oder Komponenten wie in der Technik bekannt beinhalten. Die mit der Netzwerk-Infrastruktur verbundenen Computer- und Nicht-Computergeräte können außer anderen Komponenten ein Speichermedium wie Flash-Speicher, Puffer, Stapel, RAM, ROM und dergleichen beinhalten. Die hierin und an anderer Stelle beschriebenen Prozesse, Methoden, Programmcodes und Anweisungen können von einem oder mehreren Elementen der Netzwerk-Infrastruktur ausgeführt werden.
Die Computersoftware, Programmcodes und/oder Anweisungen können auf maschinenlesbaren Medien gespeichert und/oder verwendet werden, die beinhalten können: Computerkomponenten, Vorrichtungen und Aufzeichnungsmedien, die Digitale Daten speichern, die Berechnungen in einem Zeitintervall verwendet werden; Halbleiterspeicher, die als Direktzugriffspeicher (RAM) bekannt sind; Massenspeicher typisch für dauerhafteres Speichern, wie etwa optische Laufwerke, Formen von Magnetspeichern wie Festplatten, Bänder, Magnettrommeln, Karten und andere Arten; Prozessor-Register, Zwischenspeicher, flüchtiger Speicher, nicht-flüchtiger Speicher; optische Speicher wie etwa CD, DVD; Wechselmedien wie etwa Flashspeicher (z. B. USB-Sticks), Disketten, Magnetband, Lochstreifen, Lochkarten, eigenständige RAM-Platten, Ziplaufwerke, Wechsel-Massenspeichergeräte, Offline und Ähnliches; andere Computerspeicher wie etwa dynamischer Arbeitsspeicher, statischer Arbeitsspeicher, Lese-/Schreibspeicher, änderbare Speicher, schreibgeschützte Speicher, Speicher mit Direktzugriff, Speicher mit sequentiellem Zugriff, ortsadressierter, dateiadressierter, inhaltsadressierter Speicher, Network Attached Storage, Storage Area Network, Barcodes, magnetisierte Zeichen und Ähnliches.
Die hier beschriebenen und veranschaulichten Elemente, einschließlich in Ablaufdiagrammen und Blockschaltbildern in allen Figuren, setzen logische Grenzen zwischen den Elementen voraus. In Übereinstimmung mit Software oder Hardware betreffenden technischen Praktiken können die veranschaulichten Elemente und deren Funktionen dennoch über von Computern ausführbare Medien implementiert werden, die einen Prozessor haben, der in der Lage ist, Programmanweisungen auszuführen, die darauf als monolithische Softwarestruktur, als eigenständige Softwaremodule oder als Module abgespeichert sind, die externe Routinen, Code, Dienste und so weiter einsetzen, oder jede Kombination daraus, und all diese Implementierungen können innerhalb des Geltungsbereichs der vorliegenden Offenbarung sein.
Obwohl folglich die vorangehenden Zeichnungen und Beschreibungen funktionale Aspekte des offenbarten Systems darlegen, sollte keine besondere Softwareanordnung für das Implementieren dieser funktionalen Aspekte aus diesen Beschreibungen abgeleitet werden, außer ausdrücklich angegeben oder anders klar aus dem Kontext hervorgehend. Desgleichen versteht es sich, dass die verschiedenen hierüber bezeichneten und beschriebenen Techniken variiert werden können, und dass die Reihenfolge der Techniken an bestimmte Anwendungen der hierin offenbarten Techniken angepasst werden kann. Alle derartigen Varianten und Änderungen gehören zum Umfang dieser Offenbarung. Auf diese Weise darf die Darstellung und Beschreibung einer Reihenfolge für verschiedene Techniken nicht als spezifisch für die Ausführung dieser Techniken erforderliche Reihenfolge ausgelegt werden, es sei denn, diese ist für eine bestimmte Anwendung erforderlich, oder anderweitig angegeben, oder sie geht eindeutig aus dem Kontext hervor.
Die oben beschriebenen Verfahren und/oder Prozesse, und deren Techniken, können in Hardware implementiert werden, oder in jeder beliebigen Kombination aus Hardware und Software, die für eine besondere Anwendung geeignet ist. Die Hardware kann einen Allzweck-Computer und/oder dedizierte Computergeräte, oder spezifische Computergeräte oder bestimmte Aspekte oder Komponenten eines spezifischen Computergeräts beinhalten. Die Prozesse können in einem oder mehreren Mikroprozessoren, Mikrocontrollern, programmierbaren digitalen Signalprozessoren oder anderen programmierbaren Geräten zusammen mit internen und/oder externen Speichern ausgeführt werden. Die Prozesse können auch, oder stattdessen, in einen anwendungsspezifischen integrierten Schaltkreis, einen programmierbaren Universalschaltkreis, einen PAL oder jede beliebige andere Vorrichtung oder Kombination von Vorrichtungen eingebaut werden, die für das Verarbeiten der elektronischen Signale konfiguriert werden können. Es versteht sich weiterhin, dass ein oder mehrere Prozesse als computerlesbarer Code ausgeführt werden können, der auf einem maschinenlesbaren Medium ausgeführt werden kann.
Die Anweisungen können im Speicher 904 gespeichert werden und in einem oder mehreren Computerprogrammprodukten, d. h. einem oder mehreren Modulen mit Computerprogrammanweisungen, die in einem computerlesbaren Medium zur Ausführung durch oder zur Steuerung des Betriebs, des Dienstes, verschlüsselt sind, und gemäß jedem beliebigen, Fachleuten wohlbekannten Verfahren, einschließlich, jedoch nicht beschränkt auf Computersprachen wie etwa datenorientierte Sprachen (z.B. SQL, dBase), Systemsprachen (z. B., C, Objective-C, C++, Assembly), Architektursprachen (z.B. Java, .NET) und Anwendungssprachen (z.B. PHP, Ruby, Perl, Python) implementiert werden können.
Ein wie hier diskutiertes Computerprogramm entspricht nicht unbedingt einer Datei in einem Dateisystem. Ein Programm kann in einem Teil einer Datei gespeichert werden, der andere Programme oder Daten enthält (z. B. einen oder mehrere Skripte, die in einem Auszeichnungssprachen-Dokument gespeichert sind), in einer einzelnen Datei, die dem betreffenden Programm zugeordnet ist, oder in mehreren koordinierten Dateien (z. B. Dateien, die ein oder mehrere Module, Unterprogramme oder Codeabschnitte speichern). Ein Computerprogramm kann eingerichtet werden, um auf einem Computer oder mehreren Computern, die an einem Standort angeordnet oder verteilt über mehrere Standorte sind und über ein Kommunikationsnetzwerk miteinander verbunden sind, ausgeführt zu werden. Die in dieser Beschreibung dargestellten Prozesse und Logik-Abläufe können durch einen oder mehrere programmierbare Prozessoren durchgeführt werden, die ein oder mehrere Computerprogramme ausführen, um Funktionen durch das Arbeiten mit Eingabedaten und das Erzeugen von Ausgaben auszuführen.
Das Computersystem 900 beinhaltet des Weiteren eine Datenspeichervorrichtung 906 wie etwa eine Magnetplatte oder optische Platte, die zum Speichern von Informationen und Anweisungen mit Bus 908 verknüpft ist. Das Computersystem 900 kann über das Eingabe-/Ausgabemodul 910 mit verschiedenen Vorrichtungen verbunden werden. Das Eingabe-/Ausgabemodul 910 kann jedes beliebige Eingabe-/Ausgabemodul sein. Beispiele für Eingabe-/Ausgabemodule 910 beinhalten Datenanschlüsse wie etwa USB-Anschlüsse. Das Eingabe-/Ausgabemodul 910 ist so konfiguriert, dass es mit einem Kommunikationsmodul 912 verbunden werden kann. Beispiele von Kommunikationsmodulen 912 beinhalten Netzwerkschnittstellenkarten wie etwa Ethernet-Karten und Modems. In bestimmten Aspekten ist das Eingabe-/Ausgabemodul 910 so konfiguriert, dass es mit einer Vielzahl von Vorrichtungen, wie beispielsweise einer Eingabevorrichtung 914 und/oder einer Ausgabevorrichtung 916 verbunden werden kann. Beispiele von Eingabevorrichtungen 914 beinhalten eine Tastatur und eine Zeigevorrichtung, z. B. eine Maus oder einen Trackball, durch die ein Benutzer dem Computersystem 900 Eingaben bereitstellen kann. Ebenso können andere Arten von Eingabevorrichtungen 914 verwendet werden, um Wechselwirkung mit einem Benutzer bereitzustellen, wie beispielsweise eine taktile Eingabevorrichtung, visuelle Eingabevorrichtung, Audio-Eingabevorrichtung oder eine Gehirn-Computer-Schnittstellenvorrichtung. Dem Benutzer bereitgestellte Rückmeldung kann beispielsweise irgendeine Form sensorischer Rückmeldung, z. B. visuelle Rückmeldung, auditive Rückmeldung oder taktile Rückmeldung sein; und eine Eingabe vom Benutzer kann in irgendeiner Form empfangen werden, einschließlich als akustische, Sprach-, taktile oder Gehirnwelleneingabe. Beispiele von Ausgabevorrichtungen 916 beinhalten Anzeigevorrichtungen wie beispielsweise eine Kathodenstrahlröhre (Cathode Ray Tube, CRT) oder einen LCD-Monitor (Liquid Crystal Display, Flüssigkristallanzeige), um dem Benutzer Informationen anzuzeigen.
Gemäß einem Aspekt der vorliegenden Offenbarung kann das System für die Verwaltung von Bearbeitungsvorschlägen in einer Dokumentenvorlage wie in 2A–7 dargestellt, unter Verwendung eines Computersystems 900 als Reaktion auf Prozessor 902 implementiert werden, um eine oder mehr Sequenzen einer oder mehrerer Anweisungen, die im Speicher 904 enthalten sind, auszuführen. Diese Anweisungen können von einem anderen maschinenlesbaren Medium in Speicher 904, wie etwa Datenspeichervorrichtung 906, eingelesen werden. Die Ausführung von im Hauptspeicher 904 enthaltenen Anweisungssequenzen veranlasst den Prozessor 902, die hierin beschriebenen Verfahrensschritte auszuführen. Ein oder mehrere Prozessoren in einer Multiprocessing-Anordnung können auch verwendet werden, um die in Speicher 904 enthaltenen Anweisungssequenzen auszuführen. In alternativen Aspekten können festverdrahtete Schaltungen anstelle von oder in Kombination mit Softwareanweisungen verwendet werden, um verschiedene Aspekte der vorliegenden Offenbarung zu implementieren. Somit beschränken sich Aspekte der vorliegenden Offenbarung nicht auf eine spezifische Kombination von Hardwareschaltung und Software.
Verschiedene Aspekte des betreffenden in dieser Beschreibung beschriebenen Gegenstandes können in einem Computersystem implementiert werden, das eine Back-End-Komponente beinhaltet, z.B. als Datenserver, oder das eine Middleware-Komponente beinhaltet, z.B. einen Anwendungsserver, oder das eine Front-End-Komponente beinhaltet, z.B. einen Client-Computer mit einer grafischen Benutzeroberfläche oder einem Webbrowser, über die bzw. den ein Benutzer mit einer Implementierung des betreffenden und in dieser Beschreibung beschriebenen Gegenstandes interagieren kann, oder eine Kombination einer oder mehrerer dieser Back-End-, Middleware- oder Front-End-Komponenten. Die Komponenten des Systems können durch eine beliebige Form oder ein beliebiges Medium digitaler Datenkommunikation miteinander verbunden sein, z. B. ein Kommunikationsnetz. Das Kommunikationsnetzwerk kann beispielsweise einen beliebigen oder mehrere aus dem Personal Area Network (PAN), einem Local Area Network (LAN), einem Campus Area Network (CAN), einem Metropolitan Area Network (MAN), einem Wide Area Network (WAN), einem Broadband Network (BBN), dem Internet usw. beinhalten. Des Weiteren kann das Kommunikationsnetzwerk beispielsweise eine beliebige oder mehrere der folgenden Netzwerktopologien, einschließlich eines Busnetzwerks, eines Sternnetzwerks, eines Ringnetzwerks, eines Maschennetzwerks, eines Stern-Bus-Netzwerks, eines Baum- oder hierarchischen Netzwerks und dergleichen beinhalten, ist darauf aber nicht beschränkt. Die Kommunikationsmodule können beispielsweise Modems oder Ethernet-Karten sein.
Wie oben besprochen, kann das Computersystem 900 Clients und Server beinhalten. Ein Client und Server befinden sich im Allgemeinen ortsfern voneinander und interagieren typischerweise über ein Kommunikationsnetz. Die Beziehung zwischen Client und Server entsteht aufgrund von Computerprogrammen, die auf den jeweiligen Computern laufen und die eine Client-Server-Beziehung zueinander haben. Computersystem 900 kann beispielsweise und ohne Beschränkung ein Enterpreis Server oder eine Servergruppe, einer oder mehr Desktop-Computer, ein oder mehr Laptop-Computer etc. sein. Das Computersystem 900 kann auch in einer anderen Vorrichtung eingebettet sein, beispielsweise und ohne Beschränkung ein Mobiltelefon, einen Personal Digital Assistant (PDA), einen mobilen Audio-Player, einen GPS-Empfänger, eine Videospielkonsole und/oder eine Fernseher-Set-Top-Box.
Der Begriff „maschinenlesbares Speichermedium“ oder „computerlesbares Medium“, wie hierin verwendet, bezieht sich auf ein Medium oder Medien, die an der Bereitstellung von Anweisungen an einen Prozessor 902 zur Ausführung beteiligt sind. Solch ein Medium kann viele Formen annehmen, einschließlich, jedoch nicht beschränkt auf nichtflüchtige Medien, flüchtige Medien und Übertragungsmedien. Nichtflüchtige Medien beinhalten beispielsweise optische oder Magnetplatten wie beispielsweise Datenspeichervorrichtung 906. Flüchtige Medien beinhalten dynamische Speicher wie beispielsweise Speicher 904. Übertragungsmedien beinhalten Koaxialkabel, Kupferdraht und Faseroptik, einschließlich der Drähte, die Bus 908 umfassen. Verbreitete Formen maschinenlesbarer Medien beinhalten beispielsweise eine Floppy-Disk, eine flexible Platte, eine Festplatte, Magnetband, ein anderes magnetisches Medium, eine CD-ROM, eine DVD, ein anderes optisches Medium, Lochkarten, Lochstreifen, ein anderes physisches Medium mit Lochmustern, ein RAM, ein PROM, ein EPROM, ein FLASH-EPROM, einen anderen Speicherchip oder eine Speicherkassette oder ein anderes Medium, von dem ein Computer lesen kann. Das maschinenlesbare Speichermedium kann eine maschinenlesbare Speichervorrichtung, ein maschinenlesbares Speichersubstrat, eine Speichervorrichtung, eine Stoffzusammensetzung, die ein maschinenlesbares verbreitetes Signal bewirkt, oder eine Kombination aus einem oder mehreren davon sein.
Während diese Beschreibung viele Einzelheiten enthält, sollen diese nicht als Beschränkung des Umfangs dessen verstanden werden, was beansprucht wird, sondern vielmehr als Beschreibungen von bestimmten Implementierungen des betreffenden Gegenstands. Bestimmte Eigenschaften, die in dieser Spezifikation im Kontext gesonderter Implementierungen beschrieben sind, können auch in Kombination in einer einzelnen Implementierung implementiert werden. Umgekehrt können verschiedene, im Kontext einer einzelnen Implementierung beschriebenen Merkmale auch in mehreren Implementierungen gesondert oder in einer geeigneten Unterkombination implementiert werden. Außerdem können ein oder mehrere Merkmale einer beanspruchten Kombination in einigen Fällen aus der Kombination herausgelöst werden, auch wenn die Merkmale vorstehend als in gewissen Kombinationen funktionierend beschrieben oder gar als eine Kombination beansprucht werden, und die beanspruchte Kombination kann an eine Unterkombination oder eine Variation einer Unterkombination verwiesen werden.
Ebenso werden Tätigkeiten in den Zeichnungen zwar in einer bestimmten Reihenfolge dargestellt, aber dies sollte nicht als Anforderung verstanden werden, dass diese Tätigkeiten in der bestimmten gezeigten Reihenfolge oder in einer aufeinanderfolgenden Reihenfolge ausgeführt werden müssen oder dass alle dargestellten Tätigkeiten ausgeführt werden müssen, um erwünschte Ergebnisse zu erzielen. Unter bestimmten Umständen können Multitasking und eine Parallelbearbeitung vorteilhaft sein. Darüber hinaus sollte die Trennung verschiedener Systemkomponenten in den oben beschriebenen Aspekten nicht als solche Trennung in allen Aspekten erfordernd aufgefasst werden, und es versteht sich, dass die beschriebenen Programmkomponenten und Systeme im Allgemeinen zusammen in ein einziges Softwareprodukt integriert oder zu mehreren Softwareprodukten verkapselt werden können.
Der betreffende Gegenstand dieser Beschreibung wurde in Bezug auf besondere Aspekte beschrieben. Es können jedoch andere Aspekte implementiert werden und diese fallen in den Rahmen des Schutzumfangs der folgenden Ansprüche. Die in den Ansprüchen wiedergegebenen Aktionen können beispielsweise in einer anderen Reihenfolge durchgeführt werden und dennoch gewünschte Ergebnisse erzielen. Die in den beigefügten Abbildungen dargestellten Verfahren erfordern beispielsweise nicht notwendigerweise die gezeigte Reihenfolge oder sequentielle Reihenfolge, um erwünschte Ergebnisse zu erzielen. Bei bestimmten Implementierungen können Multitasking und eine Parallelbearbeitung vorteilhaft sein. Andere Variationen sind im Umfang der folgenden Ansprüche enthalten.

Claims

System zum Verwalten von Bearbeitungsvorschlägen in einem kollaborativen Dokument, wobei das System Folgendes umfasst: Mittel zum Erzeugen einer Dokumentenvorlage, die dem kollaborativen Dokument zugewiesen ist; Mittel zum Empfangen eines ersten Bearbeitungsvorschlags am kollaborativen Dokument von einem ersten Benutzer; Mittel zum Zuweisen eines ersten Vorschlagsbefehls zum ersten Bearbeitungsvorschlag basierend auf einem Typ des ersten Bearbeitungsvorschlags und einem Typ der Dokumentenvorlage; Mittel zum Anwenden des ersten Vorschlagsbefehls auf die Dokumentenvorlage, um den ersten Bearbeitungsvorschlag innerhalb des kollaborativen Dokuments vorzulegen; Mittel zum Empfangen einer Annahmeanzeige für den ersten Bearbeitungsvorschlag; und Mittel zum Aktualisieren der Dokumentenvorlage mit dem ersten Vorschlagsbefehl als Reaktion auf die eingegangene Annahmeanzeige.
Prozessorlesbares, nichtflüchtiges Medium, das die vom Prozessor ausführbaren Anweisungen zur Verwaltung von Bearbeitungsvorschlägen in einem kollaborativen Dokument speichert, wobei die vom Prozessor ausführbaren Anweisungen Folgendes umfassen: Anweisungen zum Erzeugen einer Dokumentenvorlage, die dem kollaborativen Dokument zugewiesen ist; Anweisungen zum Empfangen eines ersten Bearbeitungsvorschlags am kollaborativen Dokument von einem ersten Benutzer; Anweisungen zum Zuweisen eines ersten Vorschlagsbefehls zum ersten Bearbeitungsvorschlag basierend auf einem Typ des ersten Bearbeitungsvorschlags und einem Typ der Dokumentenvorlage; Anweisungen zum Anwenden des ersten Vorschlagsbefehls auf die Dokumentenvorlage, um den ersten Bearbeitungsvorschlag innerhalb des kollaborativen Dokuments vorzulegen; Anweisungen zum Empfangen einer Annahmeanzeige für den ersten Bearbeitungsvorschlag; und Anweisungen zum Aktualisieren der Dokumentenvorlage mit dem ersten Vorschlagsbefehl als Reaktion auf die eingegangene Annahmeanzeige.